Комплексная автоматизация испытаний газотурбинных двигателей. Часть 2: хранение и обработка данных Текст научной статьи по специальности «Компьютерные и информационные науки»

УПРАВЛЕНИЕ, ВЫЧИСЛИТЕЛЬНАЯ ТЕХНИКА И ИНФОРМАТИКА

УДК 621.452:004.4

Ю. А. Зеленков, В. Ю. Чувилин, В. Е. Журавлев

КОМПЛЕКСНАЯ АВТОМАТИЗАЦИЯ ИСПЫТАНИЙ ГАЗОТУРБИННЫХ ДВИГАТЕЛЕЙ.

ЧАСТЬ 2: ХРАНЕНИЕ И ОБРАБОТКА ДАННЫХ

Рассматриваются вопросы комплексной автоматизации процесса испытаний газотурбинных двигателей (ГТД), включая процессы сбора данных, хранения и постобработки данных, а также управления стендовыми системами. Приведено описание систем, реализованных в рамках проектов ОАО «НПО «Сатурн». Испытания газотурбинных двигателей; системы сбора данных; системы хранения данных; визуализация данных

В первой части статьи были рассмотрены вопросы автоматизации сбора данных и управления стендом во время испытаний ГТД. Вторая часть посвящена обсуждению системы хранения данных, а также средствам их постобработки и визуализации.

Увеличение числа каналов сбора данных и частот опроса ведет к резкому росту объема получаемой информации - общий объем данных опытных испытаний по одной модели нового двигателя может достигать 1 Пбайт, причем эти данные необходимо хранить на протяжении всего жизненного цикла изделия. Для управления получаемыми при испытаниях данными требуется специализированное программное обеспечение, позволяющее производить поиск, извлечение и постпроцессорную обработку результатов. Для этих целей на НПО «Сатурн» была разработана собственная система, предоставляющая базовые механизмы поиска, средства создания шаблонов документов (протоколы испытаний, отчеты), которые автоматически заполняются данными, и инструменты визуализации и постпроцессинга.

1. ИСПЫТАНИЯ В ПРОЦЕССЕ РАЗРАБОТКИ ГТД

Согласно рекомендациям работы [1] последовательно рассмотрим архитектуры бизнес-процессов, данных, приложений и технической архитектуры.

Модель бизнес-процессов опытных испытаний при разработке ГТД и используемых при этом данных представлена на рис. 1 в нотации ВРМЧ 1.2 [2].

Все опытные испытания проводятся на основании программы испытаний, которую разрабатывают конструкторские подразделения. Для каждого испытания формируется конкретная

конфигурация изделия, которая может включать специально препарированные детали (например, с наклеенными тензодатчиками). Данная конфигурация («как запланировано») вычисляется на основании сведений о применяемости деталей и передается в производство. В процессе производства формируется конфигурация «как изготовлено», включающая индивидуальные номера прослеживаемых деталей, данные об их изготовлении, а также документы, подтверждающие разрешение использовать детали с отклонениями от требований, заданных конструкторами. Готовое изделие передается на испытательную станцию.

Параллельно с изготовлением опытного изделия ведется подготовка испытательного стенда, включая приобретение и установку необходимого оборудования и систем для специспыта-ний, разработку технологии испытаний, конфигурирование и метрологическую поверку управляющего измерительно-вычислительного комплекса (УИВК).

В процессе испытаний по различным причинам могут быть заменены те или иные детали и узлы двигателя, данные замены фиксируются в конфигурации «как испытано». Соответственно, результаты испытаний (как «сырые» данные, так и сгенерированные на их основе отчеты) должны быть увязаны с конкретной конфигурацией «как испытано».

Кроме того, некоторые детали имеют ограничения по количеству циклов запуска, времени наработки и т. д. Необходимо обеспечить прослеживаемость этих деталей и фиксацию значений ограничиваемых параметров.

Согласно требованиям авиационных сертифицирующих органов все вышеперечисленные информационные объекты должны быть сохранены в форме, обеспечивающей прослеживае-мость. Диаграмма классов ИМЬ для описанных выше данных приведена на рис. 2.

Контактная информация: (4855) 296-174

Рис. 1. Модель бизнес-процессов испытаний ГТД

ГТД Программа испытаний

1 1.. *

1

Конфигурация " как спроектировано "

Конфигурация " как спланировано "

Детал ь

-Обозначение -Индивидуальный номер -Максимальная наработка -Фактическая наработка

* 1

Конфигурация УИВК

Технология испытаний

Конфигурация " как изготовлено "

Конфигурация "как испытано "

1.. * 1

Измерительный канал

-Обозначение

-Настройки

Данные испытаний

-В р е м я -К а н а л -З н а ч е н и е

1 .. *

1.. *

1 .. *

1 .. *

1.. *

Рис. 2. Диаграмма классов UML

2. АРХИТЕКТУРА ПРИЛОЖЕНИЙ

На основании вышеизложенного очевидно, что необходима виртуальная информационная среда [3], обеспечивающая структурированный доступ ко всем данным моделирования в рамках сложного мультидисциплинарного проекта, каким является создание нового ГТД (особенно если ставится также задача интеграции данных испытаний с трехмерными моделями САПР и результатами инженерного анализа). Следует отметить, что создание подобной среды на основе одного продукта управления данными (например TeamCenter Engineering [4] или MCS

SimManager [5]) невозможно. Каждый подобный продукт, так или иначе, накладывает ограничения на модель данных, а также предлагает свой подход к организации поддерживаемых бизнес-процессов.

Поэтому при создании систем был выбран прагматичный подход, согласно которому максимально используется функционал систем «из коробки», но в случае необходимости всегда рассматривается вариант альтернативной разработки.

Архитектура приложений, обеспечивающих работу пользователей НПО «Сатурн» с описан-

ными выше данными, и интерфейсов между приложениями представлена на рис 3. При этом каждый объект может создаваться и изменяться только в одном приложении, если необходимо его использование в другой системе, производится копирование через программный интерфейс. Идентификация объекта в различных системах обеспечивается уникальностью его обозначения, которое совпадает с обозначением чертежа детали или сборки.

Рассмотрение систем управления конфигурацией выходит за рамки данной работы, программные системы подготовки технологии испытаний и УИВК описаны в первой части статьи. Далее предметом обсуждения является система хранения и постобработки данных испытаний.

В процессе испытаний создаются и используются следующие виды данных:

• данные стационарных процессов (контрольные точки) в единицах физических величин;

• данные переходных процессов;

• данные динамических процессов;

• результаты предварительной обработки данных на стенде (редуцированные данные и отчеты в форматах MS Оffice, файлы в графических форматах и т. д.);

• любые файлы, имеющие отношение к испытаниям (например, программа испытаний в формате MS Word или конфигурационный файл УИВК в формате XML).

Особо необходимо остановиться на обработке данных динамических процессов. Современные стенды для опытных испытаний имеют до 250 измерительных динамических каналов с частотами опроса до 40 КГ ц, и объем данных, генерируемых за одно испытание, чрезвычайно велик. Поэтому предварительная обработка динамических данных производится с помощью стендовой системы во время испытаний или сразу после их окончания. Результаты обработки передаются в описываемую здесь систему управления данными, исходные данные переносятся на магнитную ленту и хранятся в течение жизненного цикла ГТД.

Так как рассматриваемая система должна поддерживать многопользовательский режим, ее разработку решено было выполнить в архитектуре «клиент - сервер». Минимальные требования к функциональности серверной части были сформулированы следующим образом:

• загрузка данных по локальной сети непосредственно со стендовых УИВК;

• централизованный архив данных с иерархической системой хранения, обеспечивающей перемещение неиспользуемых данных на магнитные ленты;

• хранение результатов испытаний в течение всего жизненного цикла двигателя;

• разграничение доступа к данным для различных групп пользователей (по двигателю, испытанию, группе измерительных каналов);

• интеграция каталога пользователей с внешними источниками по протоколу LDAP.

Рис. 3. Архитектура приложений

-Система управления данными-

Загрузчик

данных

Документы

Данные

Физическая структура хранения

Корневая папка Программа Программа Тип изделия Типизделия

Двигатель Двигатель Испытание Испытание

XML

Рис. 4. Техническая архитектура

Клиентское рабочее место должно обеспечивать удобный доступ к данным, а также набор базовых операций анализа, наиболее широко используемых при проектировании ГТД. Требования к клиентскому рабочему месту:

• средства сохранения индивидуальной настройки экранного интерфейса;

• поиск данных по любому атрибуту записи базы данных или комбинированному запросу (например, по дате испытаний, по названию параметра, по названию измерительной системы, с помощью которой получены эти данные и пр.);

• 2-мерная и 3-мерная визуализация;

• редактирование визуализируемых значений с обеспечением версионности наборов данных;

• просмотр текста и изображений;

• средства автоматизации процедур создания отчетов и графиков (АР1);

• функции передискретизации, в том числе адаптивной передискретизации (переход от временного представления сигнальных функций к угловому);

• средства построения дроссельных характеристик;

• открытый программный интерфейс для создания пользовательских функций обработки данных.

Отметим, что упомянутые выше системы общего назначения для управления инженерными данными Siemens ТеатСе^ег и MCS SimManager не обладают необходимой функциональностью. На рынке также имеется спе-

циализированная система для управления данными испытаний Intespace DynaWorks [6], практически удовлетворяющая перечисленным требованиям. Однако анализ данной системы показал, что она разработана с использованием несовместимых технологий (например, одна часть экранных форм реализована с использованием X-сервера и протокола X11, другая - на платформе Java), что резко повышает требования к аппаратному обеспечению и усложняет поддержку. Поэтому было принято решение о собственной разработке.

3. ТЕХНИЧЕСКАЯ АРХИТЕКТУРА

Техническая архитектура системы представлена на рис. 4. В системе предусмотрен загрузчик данных, который по команде оператора загружает все данные с жестких дисков УИВК. Отметим, что и система хранения данных, и УИВК разработки НПО «Сатурн» используют единый формат хранения данных на основе языка разметки XML, который описан ниже. При загрузке данных с измерительных систем других поставщиков используются конвертеры в указанный формат данных.

Внутренняя физическая структура хранения данных реализована на основе файловой системы, доступ ко всем данным, как со стороны загрузчика, так и со стороны пользователя, осуществляется по протоколу FTP. Для обеспечения безопасности используется изоляция различных сегментов сети при помощи VPN.

; СЗ CF6 Г*~1 ChartZoom

5 □ Evjl3

1

•^3lwn^_82_04 Q] NetMonitor В Cl Pictures Й С] trial

J

-i

fQ Idx_20061119, л}Их„2006!119, *Jldx_20061120. *Jldx_2QQ6ll20. ЙМх.гОО&ПМ,

i*]ldx_2006!l ( j«jldx^2006112G] jfOldxJOOGIlZO. [*|ldxJJ006il20. *}ldx_2006I120.

ЙИх_гообпго.

.]75942.xml .18005J.xml 083446.xml ,Q92230.xml

xml

IhTiI i.xml 11193®. xml 113020. xml 113323.xml 114604.xml

j*}ldx_2QC JiJldx^OC *]]dx_20C *} Idx„20C *Jldx_20C [ajldx_20C *]ldx_20C i*Jldx_20C *Jldx_20C л] Idx_20C л} ldx_20C

jJ

Hb<x]

001)0:00 06:0S:<n 12:00:00 16:00:00 00:00:00 »В:00:Ю 12 00:00 18:00:00 05 10:00 08:00:00 1230:00 13:00:00 ОО.ООЛО

Печатные отчеты :D:\Stend\Eva4i.DataMiric’'Per sona!: =ta\bR 20061Z04 092255..<rnl

НмСчг.кЛХ'» |wm

нг Гта^даГ TV

HI ЗИМ .!№ ■ 1У

б*гю ода ■ I4J

о 0«л ■ )U

16 «ЮЫХ1 ■ 1U

17Л4Я ..41

1?_5M ■ 1Ы

Ortwi згзая» *14

ПЕРсаыьарку п протокол |

Ж*>

14

иг f нч» Щ

N1 | ч.чп,-« не* ГМ

п j ЧТООЙЙЗ — в ГУ

с* ] ОЙ» «••ГУ

1с 1 (Win •«■rw

Ри J 10VM ~"tU

РМ1 j и 323 ^*гу

1 ■mm Ги

I пимнч/.Д:( На

lUtKclniHini а пГ’пшкй1||

Отобразить индексные файпы | Докупент : D:\5tend\Evd4‘i Dat aMme г\Personaft)a,,

1Логтооги>чы

Дроссельная характеристика

I Event messages__________________

No cfgfilename defined in cfg file Dale loading

Рис. 5. Пользовательский интерфейс системы

Поверх физической структуры хранения реализованы виртуальные пути доступа («стенд - тип изделия - двигатель - испытание» и «вид испытания - тип изделия - двигатель - испытание»), которые позволяют совершать навигацию альтернативным способом. Перечисленные атрибуты означают следующее:

• программа - программа разработки нового изделия, например SaM146 или АЛ-55;

• тип изделия - опытное, сертификационное, серийное и т. д.;

• двигатель - индивидуальный номер двигателя;

• сборка - вариант конфиграции данного двигателя;

• стенд - номер (наименование) испытательного стенда;

• вид испытания - определяет назначение данного испытания (например, тензометри-рование лопаток вентилятора или длительная нароботка);

• испытание - время проведения испытаний.

Организация хранения на основе файловой системы позволила предоставить пользователям интуитивно понятный интерфейс, совместимый с традиционными файловыми менеджерами. Графический интерфейс системы представлен

на рис. 5, где цифрами обозначены: 1 - область выбора папки, содержащей данные испытаний, 2 - область выбора файлов данных, 3 - область отобранных файлов данных, 4 - график изменения параметров, записанных в отобранных файлах, в зависимости от времени, 5 - результаты обработки отобранных данных (в данном случае построена дроссельная характеристика), 6 - окно, куда выводятся сообщения системы.

4. ФОРМАТ ХРАНЕНИЯ ДАННЫХ

Для УИВК и системы хранения данных был разработан единый формат хранения данных на основе языка разметки XML. Файл данных в формате XML является структурированным текстовым файлом, имеющим иерархическую структуру, состоящую из корневого списка узлов, каждый из которых детализируется списком следующего уровня. Корневой список содержит следующие узлы:

Info - справочная информация;

Cell - конфигурация ПО измерительной системы;

Template - шаблон отчета;

Names - имена параметров;

DataSS - срезы данных;

DataTr - записи переходных режимов;

Picture - графические изображения;

DataTable - таблицы данных.

Узел «Info» содержит атрибуты справочной информации (изделие, сборка, стенд, время испытаний и т. д.), по которым осуществляется поиск в системе хранения данных. Узел «Template» содержит XML описание шаблона отчета, что позволяет представлять данные в различных форматах печатного протокола. Узел «Names» содержит имена каналов, значения которых представлены в записях переходных режимов (узел «DataTr»). Узел «DataSS» (срезы данных) может содержать один или несколько срезов данных испытаний (все каналы, записанные в определенный момент времени). Узел «DataTr» может содержать одну или несколько записей переходных режимов. Узел «Picture» может содержать одно или несколько графических изображений (поддерживается работа с изображениями в форматах BMP, JPG, GIF, PNG).

Узел «DataTable» (Таблицы данных) может содержать одну или несколько таблиц с данными переходных процессов испытаний в формате «отметка времени» - «показание канала А» -«показание канала В» - ...

ВЫВОДЫ

В результате выполнения описанных в обеих частях данной статьи работ были созданы системы, обеспечивающие комплексную автоматизацию всех процессов испытаний ГТД, включая управление стендом, сбор, хранение и обработку данных. Данные системы интегрированы в единую виртуальную среду с системами управления конфигурацией, цифровым макетом и результатами расчетов [3], что обеспечивает структурированный безопасный доступ ко всем данным проекта. При этом значительно сокращены затраты как на создание и эксплуатацию описанных здесь систем, так и в итоге на разработку новых изделий с их помощью.

В заключение авторы статьи хотели бы выразить глубокую благодарность своим коллегам

Мазаеву Н. Н., Гаврилову А. В., без участия которых данная работа не была бы выполнена.

СПИСОК ЛИТЕРАТУРЫ

1. Зеленков Ю. А. Формировапие ИТ-стратегии предприятия: архитектура, проекты, орга-пизация // Вестпик РГАТА им. П. А. Соловьева. 2010. № З(18). С. 190-198.

2. Business Process Model and Notation (BPMN). Version 1.2 [Электронный ресурс] URL: http:// www.omg.org/spec/BPMN/1.2/PDF (дата обращения 10.10.2010).

3. Виртуальная среда проектирования / Ю. А. Зелепков [и др.] // Открытые системы. 2010. № 7. С. 42-45.

4. Teamcenter: Product Lifecycle Management

(PLM) [Электронный ресурс] URL: http://www.

plm.automation. siemens.com/ru_ru/products/teamcenter/ (дата обращения 11.10.2010).

5. MSC SimManager [Электронный ресурс]

URL: http://www.mscsoftware.com/Products/Virtual-

Build-And-T est-Management/SimManager. aspx (дата

обращения 11.10.2010).

6. DynaWorks [Электронный ресурс] URL: http://dynaworks.intespace.fr/english/ (дата обращения

11.10.2010).

ОБ АВТОРАХ

Журавлев Валерий Евгеньевич, пач. сектора ОАСУТП ОАО «НПО «Сатурн». Дипл. ипжепер по конструированию и производству РЭА (РАТИ, 1974). Иссл. в обл. автоматическ. методов измерения и управления.

Чувилин Владимир Юрьевич, пач. отдела АСУТП ОАО «НПО «Сатурн». Дипл. ипжепер по конструированию и производству РЭА (РАТИ, 1981). Иссл. в обл. автоматическ. методов измерения и управления.

Зеленков Юрий Александрович, дир. по ипф. технологиям ОАО «НПО «Сатурн». Дипл. ипжепер по газотурбинным двигателям (РАТИ, 1986). Капд. физ.-мат. паук по механике деформируемого твердого тела (СПбГУ, 1998). Иссл. в обл. АСУ, методов матем. моделирования и оптимизации.