Рынок гражданских авиаперевозок растет сегодня невиданными темпами — в ближайшие 20 лет ему понадобится более 35 тыс. новых лайнеров, причем почти 25 тыс. из них придется на узкофюзеляжные самолеты вместимостью свыше 90 пассажиров. Именно в этой нише сейчас разгорается борьба между Airbus и Boeing, однако движение вперед в ряде случаев сдерживается необходимостью поддержки унаследованных систем.
Первый полет узкофюзеляжного А320 был совершен в 1987 году, положив начало серийному производству этих авиалайнеров, которых уже произведено свыше 5 тыс. штук, и спрос на них не уменьшается. Конечно, такое крупное и наукоемкое производство не может обойтись без информационного обеспечения соответствующего уровня, однако со времени разработки и внедрения A320 прошло более 20 лет, за которые ИТ-оснастка самолета существенно устарела. Цикл разработки таких сложных изделий, как авиалайнер, длится не менее десяти лет — например, разработка новейшей модели Airbus A350 заняла более девяти лет и проводилась с применением всех имеющихся современных компьютерных средств проектирования и производства, чего нельзя сказать о рубеже 70-х и 80-х годов, когда А320 был в стадии разработки.
На сегодняшний день в промышленности сформировался подход к проектированию на основе использования таких систем, как CAD/CAE/CAM, PDM (Product Data Management) и PLM (Product Lifecycle Management), подразумевающий непрерывную информационную поддержку жизненного цикла изделия на всех его стадиях. Как известно, вычислительная техника конца 80-х годов не имела той вычислительной мощности, какая есть сегодня, а аппаратное обеспечение стоило очень дорого и обладало ограниченными возможностями по хранению и обработке информации. Кроме того, все перечисленные программные комплексы тогда еще только зарождались, и разработчики A320 использовали такие системы, как: CATIA CADAM Drafting — одна из первых систем автоматизированного проектирования Dassault Systemes, позволяющая выполнять двухмерные чертежи и строить объемные примитивы (2.5D); GILDA/TAKSY — терминальное консольное приложение, относящееся к семейству систем PDM компании Clustria.
Бурное развитие ИТ привело к тому, что многие программные продукты, бывшие актуальными еще несколько лет назад, сегодня устарели, однако сами изделия, созданные с их помощью, например А320, до сих пор конкурентоспособны. Данная ситуация получила название проблемы унаследованных систем, возникающей, когда время жизни технической системы намного превосходит время жизни программных средств, с помощью которых она создавалась [1]. Внедрив мощную по меркам 80-х годов систему, концерн Airbus не может сегодня от нее отказаться — это означало бы остановку производства. Как следствие, концерну приходится тратить серьезные средства только на поддержку работоспособности устаревшей системы, данные из которой, однако, в условиях большого спроса на А320 требуются постоянно. Попутно приходится искать специалистов, имеющих опыт работы с устаревшей системой, а также развертывать специальные системы связующего уровня (middleware) для интеграции унаследованной системы с современными платформами. Однако очевидно, что введение дополнительных уровней в любую информационную систему неизбежно сказывается на ее общей надежности.
Упрощенно фюзеляж А320 представляет собой цилиндр диаметром 4 м и длиной почти 40 м, изготовленный из листов дюралюминия толщиной несколько миллиметров. Изнутри эти листы подкреплены продольными профилями («стрингерами»), идущими он носа к хвосту самолета, а также через каждые полметра труба изнутри усилена шпангоутами. На сегодня технологически невозможно изготовить фюзеляж целиком как одно целое, поэтому его делят на секции и производят по отдельности и даже в разных странах. К примеру, носовую секцию А320 изготавливают во Франции (Сен-Назер), центральную — в Германии (Гамбург), а хвостовую — в Испании. Затем все они грузятся в транспортный самолет Airbus «Белуга» и доставляются на линию окончательной сборки в Тулузе.
Теперь допустим, что инженер получил задание проанализировать прочность стыка двух секций фюзеляжа, который представляет собой сложную в инженерном плане конструкцию, состоящую из нескольких сотен деталей и нескольких тысяч крепежных элементов. Для того чтобы сделать анализ прочности, требуется собрать массу данных: достать чертежи и снять нужные размеры; выяснить механические свойства деталей на основе сведений о составе алюминиевого сплава, формы заготовки или полуфабриката, параметрах термообработки. Все эти данные требуется найти в документах, экспортированных из PDM-системы 80-х (рис. 1).
.png "Рис. 1. Образец спецификации экспортированного документа") |
| Рис. 1. Образец спецификации экспортированного документа |
Деньги сегодня экономят все, и Airbus здесь не исключение — на каждую работу выделяется строго определенное время, и в случае его превышения исполнитель должен доделывать ее за счет своего личного времени. А ведь, кроме сбора данных о деталях конструкции, инженеру нужно еще провести собственно расчет и оформить его результаты по строгому шаблону, принятому в Airbus. Механизация труда, предполагающая выполнение с помощью ПК тех же действий, что и вручную (поиск документа в архиве, выписывание искомых данных и т. п.), реализованная в системе подготовки А320 и вполне отвечающая уровню развития вычислительной техники конца прошлого века, уже не позволяет эффективно работать в современных условиях. Концерну требовалось иное решение поддержки задачи сопровождения лайнера А320.
Решение
На базе массива имеющихся спецификаций (текстовых документов) можно организовать поиск нужных для расчетов данных, написав процедуру синтаксического разбора и отбора ценных данных с их последующим размещением в предварительно развернутой базе. После чего можно пользоваться всеми преимуществами централизованного хранения, управления данными и современных интерфейсов. В Airbus для оформления инженерной документации используется пакет Microsoft Office 2010 for Windows, поэтому для обеспечения наилучшей совместимости использовалась платформа .NET Framework 4.0.
Данное решение можно охарактеризовать как «PDM наоборот», и в отличие от «прямого», когда имеется цифровая модель технической системы (самолета), из которой можно получить нужную информацию, здесь идут от обратного: из имеющейся разрозненной информации воссоздается модель технической системы (пусть и не полная, поскольку политика информационной безопасности Airbus очень строгая и доступ ко всему изделию предоставляется только ограниченному кругу специалистов). Далее воссозданная модель готова для получения из нее требуемой инженерной информации, которую можно разделить на два основных типа.
- Внутренняя иерархия изделия. Для этого выстраивается дерево технологического членения конструкции для вычисления вхождения деталей в сборки разного уровня, вплоть до финальной сборки всего самолета. После чего можно получить граф, состоящий из сотен узлов, по которому прослеживается, в каких агрегатах самолета используется конкретная деталь.
- Спецификация деталей. Для найденной в дереве иерархии детали можно получить всю информацию о ее физических свойствах, геометрических размерах, особенностях исполнения, поставщике и др.
Конечно, в результате была получена модель из «отсоединенных» данных, не позволяющая оперативно отслеживать изменения оригинала, однако для проекта A320 скорость изменений невелика или близка к нулю.
Поскольку разработчик сам выбирает инструментальную платформу, то можно заранее позаботиться о многих полезных функциях, таких как: интеграция с расчетными модулями и средствами их автоматизации; автоматизация процесса создания отчета, например средствами Microsoft Office; минимизация потерь времени на поиск вручную, что особенно актуально для работы в команде, когда возможны потери времени из-за дублирования; исключение ошибок, сделанных по невнимательности.
Для практической реализации предложенного подхода (рис. 2) был разработан программный комплекс на базе платформы .NET, имеющей встроенный обработчик регулярных выражений, который выполняет поиск с возвратом для регулярных выражений и реализует традиционный недетерминированный конечный автомат (НКА), аналогичный используемым в языках высокого уровня Perl и Python, а также в приложениях Emacs и Tcl. При использовании логики НКА поиск управляется регулярным выражением: производится проверка на совпадение с текстом для каждой части регулярного выражения и, в случае неудачи, происходит возврат и проверка очередного подвыражения. Недетерминированность автомата проявляется в том, что из одного состояния по одному и тому же сигналу возможны переходы в различные состояния.
.png "Рис. 2. Схема комплекса восстановления информационной модели") |
| Рис. 2. Схема комплекса восстановления информационной модели |
Суть работы синтаксического разборщика состоит в переборе заданных регулярных выражений для выделения из слабоструктурированного текста ценных данных. Определение ценности производится по метаданным, представленным в формате шаблонов регулярных выражений, заданных пользователем. На рис. 3 показана часть спецификации A320, с упоминанием даты выпуска в формате:
«DATE<пробел>:<пробел>День(ХХ)<пробел>Месяц(ХХ)<пробел>Год(ХХХХ)», тогда шаблон регулярного выражения будет иметь вид:
DATEs:sd{2}sd{2}sd{4},
где: s — метасимвол, описывающий пробел; d — цифровой символ; {n} — оператор квантификации, определяющий, сколько раз может встречаться предшествующее выражение.
.png "Рис. 3. Обнаружение даты выпуска в экспортированном документе") |
| Рис. 3. Обнаружение даты выпуска в экспортированном документе |
После анализа текста, проводимого с использованием необходимого набора шаблонов регулярных выражений, осуществляются проверка на целостность и непротиворечивость данных путем выполнения процедур поиска дублируемых данных, проверка доступности данных о деталях, на которые есть ссылки в сборках и т. д. В случае удовлетворительного результата выполняется трансформация данных.
Назначение этапа трансформации состоит в приведении типов отобранных из текстового документа данных к типам данных, поддерживаемых СУБД Microsoft SQL Server.
Для сохранения в целевой базе данных формируется SQL-запрос типа INSERT, где аргументом выступает подготовленный набор данных, поддерживаемый целевой базой данных.
Доступ к данным
В качестве основы интерфейса взаимодействия конечного пользователя и системы служит библиотека Microsoft ActiveX Data Objects 6.0 Library (ADO), предоставляющая прикладным системам набор функций для прямой работы с используемой в настоящей разработке базой данных Microsoft SQL Server. Потенциальными пользователями библиотеки являются системы инженерных расчетов, офисные приложения пакета Microsoft Office, системы электронного документооборота, системы CAD/CAM/CAE, PDM, PLM, ERP, САРР, MES и т. д. Именно у этих систем возникает необходимость прямого взаимодействия с данными об изделии для получения первичной информации о конструкторском проекте и ее обновления.
Основное назначение модуля ADO — обеспечить программистам-разработчикам прикладных систем доступ к любому источнику данных, поддерживающему СОМ-интерфейс. Данные, хранящиеся в восстановленной информационной модели, становятся, таким образом, доступными многим популярным современным приложениям, которые, в свою очередь, пополняются новым инструментарием. Например, Microsoft Excel позволяет проводить научные, инженерные, экономические и статистические расчеты, пользуясь встроенной библиотекой функций. Имеется возможность манипулировать данными, используя, в том числе, доступ к удаленным базам. Набор инструментов Visual Studio позволяет создавать приложения для платформы .NET Framework, расширяющие пакет Microsoft Office, — например, в проекте для A320 использовалась библиотека Microsoft.Office.Interop.Excel, содержащая набор интерфейсов для обеспечения взаимодействия между объектной моделью COM приложения Excel и сторонними приложениями. На рис. 4 показан результат работы надстройки Excel. Входными данными здесь являются набор номеров чертежей нескольких конструктивных элементов (выделено рамкой), а выходными — наименование детали, материал, заготовка, термообработка, ссылка на чертеж и др.
.png "Рис. 4. Результат работы с надстройкой Excel") |
| Рис. 4. Результат работы с надстройкой Excel |
***
Опытная эксплуатация программного комплекса позволила ускорить поиск нужных данных (геометрических размеров деталей, материалов и т. д.), повысить удобство работы по сравнению с «ручным» методом поиска в слабоструктурированном массиве файлов и папок, упростить процесс проверки корректности данных и исключить дублирование при поиске нужного документа. Решение оказалось достаточно универсальным, что позволило применять его для решения таких задач, как: автоматизация инженерных расчетов, основанная на мгновенном получении физических свойств анализируемой детали, ее геометрических параметров (2D-чертеж или 3D-модель); автоматизированное построение иерархической схемы деталей и сборок изделия; автоматизированное создание альбома чертежей в формате Word по указанному списку чертежных номеров с заданным форматированием.
Вместе с тем у подхода имеется ряд ограничений — например, работа возможна с изолированными данными, а обновления, хотя и нечастые, происходят с запозданием, что повышает риск получения устаревшей информации.
В целом предложенный подход может быть использован при работе с унаследованными информационными системами, позволяющими получать текстовые документы, предназначенные для печати (спецификации). Если получен массив таких документов, то настройка на работу с другой унаследованной информационной системой будет заключаться в составлении нового набора шаблонов регулярных выражений для отбора ценных данных и их последующего сохранения.
Литература
- Стефан Бургер, Оливер Хуммел, Маттиас Хейниш. Программы для Airbus // Открытые системы. — 2013. — № 3. — С. 51–53.
Никита Калуцкий (nikita.kalutsky@progresstech.ru) — инженер, компания «Прогресстех-Дубна» (Дубна).
