CC BY
85
УДК 004.624, 65.011.56
ПОСТРОЕНИЕ ИНТЕГРИРОВАННОЙ ПОЛИВЕНДОРНОЙ ЦИФРОВОЙ СРЕДЫ, ОБЕСПЕЧИВАЮЩЕЙ ПОДДЕРЖКУ ЖИЗНЕННОГО ЦИКЛА ВОЗДУШНОГО СУДНА НА ОСНОВЕ СЕРВИС-ОРИЕНТИРОВАННОГО ПОДХОДА
© 2013 Д.Ю. Шабалкин, С.В. Липатова
Ульяновский государственный университет
Поступила в редакцию 10.06.2013
В статье рассматриваются вопросы интеграции на базе сервис-ориентированного подхода автоматизированных информационных систем, обеспечивающих информационную поддержку жизненного цикла конструкторско-технологической подготовки производства и изготовления воздушного судна. Ключевые слова: интеграция приложений, интеграция данных, сервис-ориентированная архитектура, сервисы, жизненный цикл воздушного судна, конструкторско-технологическая подготовка производства.
ВВЕДЕНИЕ
Конкурентоспособность современного авиастроительного предприятие диктует необходимость обеспечения непрерывной информационной поддержки бизнес-процессов и потоков работ жизненного цикла конструкторско-технологической подготовки производства и изготовления воздушного судна.
Для обеспечения автоматизации работ на этапах жизненного цикла привлекаются такие системы как система инженерных расчетов (CAE), система управления данными об изделии (PDM), система конструкторского проектирования и моделирования (CAD/CAM), система автоматизированного проектирования технологических процессов (CAPP), система управления ресурсами (ERP/MRP), система взаимодействия с клиентами (CRM) и другие.
В современном зарубежном и отечественном авиастроении применяется большинство упомянутых систем. Это позволяет достичь повышения эффективности на каждом этапе конструкторс-ко-технологического и производственно-эксплуатационного цикла. Однако, совокупный эффект внедрения И ПИ-технологий во многом определяется степенью интеграции автоматизированных подсистем в условиях требования непрерывности информационной поддержки реализуемых бизнес-процессов.
В силу ряда причин [1] актуальной является задача интеграции поливендорных подсистем (CAD, PDM, CAPP, ERP и др.) в единую информационную среду поддержки жизненного цикла изделия. В силу причин объективного и субъек-
Шабалкин Дмитрий Юрьевич, кандидат физико-математических наук, заместитель директора Центра компетенцией "Авиационные технологии и авиационная мобильность ". E-mail: [email protected] Липатова Светлана Валерьевна, кандидат технических наук, доцент кафедры ТТС. E-mail: [email protected]
тивного характера, большинство предприятий используют указанные системы разных производителей (поливендорные системы), внедрённые в разный период времени. Как правило, данные системы оптимизированы под существующие на предприятиях бизнес-процессы и переход на программные продукты другого производителя сопряжён со значительными организационными интеллектуальными, материально-техническими, финансовыми и иными затратами. В ряде случаев выбор той или иной системы диктуется внешними факторами: требованиями поставщиков/потребителей, корпоративными стандартами и др.
Наличие единой интегрированной информационной системы играет определяющую роль в снижении ресурсных затрат (временных, трудозатрат, финансовых, материальных), повышении качества и как следствие конкурентоспособности продукции. Наличие эффективной интегрированной системы управления данными об изделии является одним из необходимых условий формирования модели Цифровой Фабрики (Digitale Fabrik)
В работе рассматриваются известные подходы к обеспечению единого цифроого пространства за счёт интеграции систем. Показывается преимущество сервис-ориентированного подхода к интеграции автоматизированных систем и рассматриваются особенности построения интегрированной поливендорной системы, обеспечивающей поддержку жизненного цикла воздушного судна.
ВЫБОР ПОДХОДА К ИНТЕГРАЦИИ СИСТЕМ
ПОДДЕРЖКИ ЖИЗНЕННОГО ЦИКЛА ВОЗДУШНОГО СУДНА
Построение поливендорной системы сводится к задаче интеграции систем и данных предприятия. Существует несколько подходов к интеграции [2]: интеграция "каждый с каждым", интег-
рация на уровне пользовательских интерфейсов, интеграция на уровне данных, интеграция на уровне корпоративных приложений, интеграция на безе сервис-ориентированной архитектуры.
Первые два подхода не применимы для большого количества поливендорных систем, так как устанавливают попарные связи между системами. Количество возможных связей между системами можно вычислить с помощью формулы N(N-1)/2 [3]. Поэтому уже при 10 системах, таких связей будет 45 и такая система требует значительных ресурсов для управления и модификации.
Задача интеграции данных имеет ограниченную ценность, поскольку существенное значение имеет разная на различных этапах жизненного цикла логика их обработки, определяемая логикой бизнес-процессов. Поэтому интеграция только данных приведет к тому, что логика обработки должна будет прописываться заново или адаптироваться под интегрированное информационное поле, что требует дополнительных ресурсов. Поэтому для построения поливендорной системы следует использовать интеграцию на уровне приложений или на базе сервисов.
Интеграция на уровне приложений обеспечивается технологией EAI (Enterprise Application Integration), предполагающей совместное использование исполняемого кода, а не внутренних данных приложения, при этом программы разбиваются на компоненты, которые интегрируются с помощью стандартизованных программных интерфейсов и специального связующего программного обеспечения [4]. При этом одной из практических целей настоящего исследования является разработка гибкой системы интеграции, позволяющей в режиме «горячей замены» переход переход на программные продукты другого производителя, одновременное использование нескольких систем одной функциональности.
Интеграция на уровне сервисов реализуется на сервис-ориентированной архитектуре (SOA -Service-oriented architecture) и дополняется технологией сервисной шины предприятия(ESB, Enterprise Service Bus). Подход основан на обеспечении стандартного для Web-служб интерфейса доступа к приложениям и данным, они могут работать всюду, где можно использовать WWW-технологии. Интеграция на уровне сервисов является развитием EAI (сервисную шину или систему обработки сообщениями (Message-oriented Middleware) можно рассматривать как развитие идеи брокера сообщений в EAI, например см. описание брокера в [5]).
Предприятиям приходится дополнять EAI бизнес-сервисами и гибким методом доступа к результирующей, интегрированной прикладной системе [6]. Успешное использование сервис-ори-
ентированной архитектуры подтверждается практикой. В России SOA используют банках: BNP Paribas, HSBC, Банк Интеза, Еврофинанс Моснарбанк, Ренессанс Кредит, Русфинанс Банк, Сбербанк, управляющая компания «Ренессанс Управление Инвестициями» [7]. По данным Gartner 82% экспертов в области СОА полагают, что сервис-ориентированная архитектура станет ведущим подходом для новых программных приложений уже к концу 2013 года [8].
Поэтому использование именно сервис-ориентированного подходя для построения интегрированной поливендорной системы представляется целесообразным.
Построение системы требует определения основных проектных решений, таких как метод интеграции, модели бизнес-процессов, модели представления данных, архитектура системы.
ПРОЕКТИРОВАНИЕ ИНТЕГРИРОВАННОЙ
ПОЛИПЛАТФОРМЕННОЙ СИСТЕМЫ
Обеспечение интеграции поливендроных систем будет проводиться по следующей схеме:
1) Определение, описание и формализация логики бизнес-процессов жизненного цикла воздушных судов;
2) Выделение ключевых рабочих процессов (workflow) с учётом соответствующих средств автоматизации (автоматизированных систем);
3) Определение и описание сервисов, обеспечивающих информационное взаимодействие автоматизированных систем в формируемом интегрируемом пространстве;
4) Описание данных автоматизированных систем, необходимых для обеспечения интеграции;
5) Применение сервис-ориентированной архитектуры для реализации интеграции.
ПОСТРОЕНИЕ МОДЕЛИ БИЗНЕС-ПРОЦЕССОВ
Интеграция поливендорных систем на основе сервис-ориентированной архитектуры должна осуществляться с учётом бизнес-логики. Необходимо описать бизнес-процессы, выделить в них рабочие процессы и определить используемые средства автоматизации (определить их принадлежность к внедренным системам, обеспечивающих их выполнение). Воспользуемся описанием этапов построения моделей бизнес-процессов [9]:
1) этап подготовки:
- определить границы процесса;
- определить конечного потребителя процесса;
- установить состав участников;
2) этап разработки модели процесса:
- определить инициирующее событие;
- определить результат процесса;
- создать диаграмму процесса;
- определить исключения.
3) этап проверки (валидации):
- проверить соответствие диаграммы процесса действительности;
- определить исключения.
Результатом построения является модель,
описанная в рамках выбранной методологии моделирования (напримерUML, BPMN, ARIS, IDEF и т.д.).
Для обеспечения общности решения была рассмотрена типовая организация бизнес-процесса, отвечающая требованиям следующих стандартов: ГОСТ Р 50995.3.1-96 Технологическое обеспечение создания продукции. Технологическая подготовка производства, ГОСТ РВ 15.3012003 Система разработки и постановки продукции на производство. Военная техника. Постановка на производство изделий. Основные положения; ГОСТ РВ 15.002-2003 Система разработки и постановки продукции на производство. Военная техника. Системы менеджмента качества. Основные требования; ГОСТ 2.6012006 Единая система конструкторской документации. Эксплуатационные документы; ГОСТ 2.051 - 2006 Единая система конструкторской документации. Электронные документы. Общие положения; ГОСТ 2.052 — 2006 Единая система
конструкторской документации. Электронная модель изделия. Общие положения.
Основными этапами жизненного цикла производства изделий авиационной техники являются:
- управление производством (планирование производства, сбор и анализ данных о ходе подготовки и производства, реализация управленческих решений),
- проектирование (разработка конструкторской документации, разработка директивных технологических материалов, создание электронной конструкторской документации на базе немашинных носителей),
- подготовка производства (приемка и проработка конструкторской документации, проектирование и конструирование оснастки, проектирование технологических процессов изделия и оснастки, программирование технологических процессов, изготовление средств технологического оснащения),
- производство (закупка материалов, изготовление, подготовка эксплуатационной документации),
- сопровождение (послепродажное обслуживание, ремонт, утилизация).
Данные этапы поддерживаются следующими типами систем (рис. 1, для построения модели использована методология IDEF0) и программное средство BPWin):
а) информационная систем управления, осуществляющая функции планирования, мониторинга
Рис. 1. Диаграмма первого уровня обобщённой модели, характеризующая основные этапы ЖЦИ
и управления производственными процессами;
б) CAD-система;
в) информационная система управления данными, обеспечивающая информационное сопровождение конструкторской информации, включая геометрические модели, созданные в CAD-системе, ведение полного комплекта конструкторской и организационно-сопроводительной информации;
г) информационная система разработки технологических процессов;
д) информационная система управления изготовлением и сборкой.
Совокупный функционал по информационной поддержке указанных процессов обеспечивается CAD-, PDM-, CAPP- и ERP-системами.
Каждая из систем выполняет свой набор операций или функций (например см. рис. 2). Каждая из операций реализуется некоторый элементарный бизнес-процессом (рис. 3). В данном случае, для описания функциональных возможностей
Управление рабочими графиками
Получатель данных
Рис. 2. Диаграмма прецедентов использования ERP-системы
Рис. 3. Управление нормативно-справочной информацией
типовых систем и элементарных действий выбраны диаграммы прецедентов использования и диаграммы действий UMLи программное средство IBM Rational Software Architect.
Диаграммы UML являются наиболее популярным моделями, т.к. они могут использоваться при моделировании на разных уровнях и поддерживаются основными методологиями управления информационными проектами (RUP, ARIS, ICONIX и т.д.).Для моделирования бизнес-процессов часто в SOA-проектах используют ВРМ^достоинством которой является совместимость с языком описания бизнес-процессов BPEL (Business Process Execution Language), входящего в стек протоколов SOA.
В качестве элемента интегрированной системы в сервис-ориентированной архитектуре рассматривается web-сервис или web-служба - идентифицируемая веб-адресом программная система со стандартизированными интерфейсами, реализующая одну или несколько функций обработки данных, т.е. web-сервис соответствует некоторой функции и использует такие протоколы как WSDL (Web Services Description Language) и SOAP (Simple Object Access Protocol). За счет применения BPEL на базе web-сервисов можно строить исполняемые бизнес-процессы.
Модель бизнес-процесса позволяет провести оптимизацию производственного бизнес-процесса, определить функциональные системы интеграционной поливендорной системы, выделить категории пользователей, определить список функций и перечень данных, необходимых для обеспечения взаимодействия программных системы в рамках единого информационного поля.
ПОСТРОЕНИЕ МОДЕЛЕЙ ДАННЫХ
Для обеспечения информационной поддержки всех этапов жизненного цикла и непрерывности потоков работ необходимо обеспечить не только возможность взаимодействия отдельных систем, но и единое пространство данных. Для этого требуется:
а) провести анализ и выявить все данные, которыми обмениваются системы;
б) построить модели представления этих данных в рамках автономных систем (как они хранятся в источниках данных и потребителях, формат модели задан разработчиком системы);
в) построить единую модель представления данных всей поливендорной системы (формат модели должен отвечать требованиям интеграционных решений).
Необходимый перечень данных (сообщений и документов) определяется при построении модели бизнес-процессов и представлен, например, входны-
ми и выходными сообщениями для действий в диаграммах деятельности (рис. 3). Данные документы циркулируют между системами. Кроме этого, существуют данные, используемые внутри систем и данные используемые всеми системами (например нормативно-справочная информация). Поэтому данные поливендорной системы целесообразно разделить на три класса: локальные (используемые одной системой), совместные (используемые двумя и более системами) и инвариантные (используемые всеми системами и редко изменяемые).
Для интеграции требуются инвариантные и совместные данные. В информационных системах они чаще всего представлены в виде реляционной модели представления данных (например PDM Team Center Engineering, САПР ТП «ТЕМП2», PLM Windchill и т.д.) либо в виде отдельных файлов (например САПР CATIA, Unigraphics). Поэтому рекомендуется выбрать модель «сущность-связь» для построения модели представления данных для автономных систем и для инвариантных данных.
Для единой модели данных поливендорной системы рекомендуется выбрать формат XML, т.к.Б8Виспользует XMLформат для передаваемых сообщений, позволяет поддерживать такие функции как преобразование данных, маршрутизация по содержанию. Кроме того, XML позволяет изменять (дополнять) модель данных, при этом позволяя работать разным приложениям по старой и новой моделям, не вызывая ошибок.
Поэтому целесообразно построить единую XML-модель данных, описывающую единую базу (данные будут храниться в разных источниках и разных форматах, но подключаемая система будет обращаться к единой модели представления данных), содержащую наборы данных из всех подключенных систем. Фрагмент такой модели представлен на рис. 4 и описывает данные EPR-системы в графическом представлении формата XSD.
Язык XMLпозволяет описать и реляционные и нереляционные данные, представить их в виде, пригодном для обеспечения таких функций ESBкак преобразование сообщений и маршрутизация по содержанию. Данная функциональность дает возможность представить данные из разнородных источников в виде единой виртуальной базы данных, к которой системы посылают запросы (в виде сообщений к шине). В случае если прикладные системы, взаимодействуют между собой посредством сообщений, формат которых не поддерживается ESB, то для их интеграции могут быть использованы дополнительные компоненты - адаптеры. Адаптер (рис. 5) пересылает сообщения между прикладной системой и ESB, преобразуя сообщения из формата прикладной системы в формат, совместимый с ESB и обратно.
Рис. 4. ХтксЬетаЕКР
Прикладная Система 1
Формат, совместимый с Б8Б
Прикладная Система 2
Формат 2
I
Формат, совместимый с Б8Б
Адаптер прикладной системы2
Рис. 5. Схема подключения внешних систем к Е8В
Схема изменения взаимодействия систем после внедрения Е8В, приведены на следующем рисунке 5. Системы взаимодействуют при этом не напрямую друг с другом, а через цепочку система! - адаптер системы1-Е8В-адаптер систе-мы2- система2. Формат входящих/исходящих для исходных систем остается прежним, а между адаптерами и шиной передаются сообщения в формате, совместимом с Е8В (XML-документы).
АРХИТЕКТУРА ПОЛИВЕНДОРНОЙ СИСТЕМЫ
Выбранный интеграционный подход определяет архитектуру поливендорной системы. Каж-
дая информационная система, включаемая в по-ливендорную систему, имеет свою архитектуру. Наиболее распространенной является клиент-серверная. Для интеграции информационных систем используется сервисная шина, к которой подключаются используемые системы. Подключение производится через интеграционные средства самой системы, если она использует такие ■№еЬ-сервисы (например 1С имеет сервис загрузки и выгрузки данных) или через адаптеры, разработанные для системы.
Так как инвариантные данных могут находится в разных источниках и занимать большие объемы информации для поливендорной системы необходимо кроме интеграции приложений
Рис. 6. Совместное использование сервисной шины и шины данных [10]
обеспечит интеграцию разнородных источников данных (рис.6).
Системе требуется хранилище для инвариантных данных. Требования к хранилищу следующие:
а) должно обеспечиваться распределенное хранения данных в разных СУБД (Postgre SQL, MSSQL, Orac^ т.д.)
б) должно обеспечиваться представление данных в единой модели данных;
в) должна обеспечиваться поддержка распределенных запросов к хранилищу данных;
г) должен быть организован доступ к XML-источникам данных;
д) должна осуществляется поддержка сервис-ориентированной архитектуры.
Данным требованиям удовлетворяет OGSA-
DAI (Open Grid Services Architecture Data Accessand Integration),так как поддерживает те же функции и использует сервис-ориентированную архитектуру. Предлагается использовать его в роли шины данных.
OGSA-DAI - это промежуточного программного обеспечения для помощи в интеграции данных с раздельных источников через GRID. Контейнер сервисов OGSA-DAI обеспечивает доступ к ресурсам данных, например реляционным или XML-базам данных через веб-сервисы. Сервисы OGSA-DAI позволяют запрашивать, изменять и перемещать данные между контейнерами и клиентским приложением.
При интеграции только данных рекомендуется использовать только OGSA-DAI, при интег-
Рис. 7. Архитектура поливендорной системы
рации приложений только ESB, но для задач поддержки жизненного цикла воздушного судна необходим гибридный подход: интеграция и данных и приложений. Поэтому в качестве архитектуры поливендорной системы предлагается их совместное использование (рис. 7).
К сервисной шине подключаются информационные системы, к GRID-хранилищу базы данных. Шина рассматривает GRID-хранилище в качестве подключенного клиента (для конечного пользователя каждый DAI ресурс представляется веб сервисом, которому могут направляться SOAP сообщения). Сервисная шина для GRID-хранилища - клиент отправляющий запросы.
В состав комплекса OGSA-DAI входит система OGSA-DQP, реализованная как надстройка над базовой частью и выполняющая интеграцию БД реляционного типа. OGSA-DQP дает более высокий уровень работы с данными: поддерживаются декларативные запросы, соответствующие стандарту SQL-92 с некоторыми ограничениями[11].OGSA-DQP эффективно задействует инфраструктуру вычислительных ресурсов, адаптируя методы параллельных БД - конвейерный параллелизм и параллельное выполнение независимых фрагментов плана. Подобная оптимизация существенно улучшает временные характеристики выполнения запросов [12].
Предлагаемый подход к построению позволяет обеспечить интеграцию данных и приложений, обеспечивающих информационную поддержку бизнес-процессов жизненного цикла воздушного судна, обеспечить взаимодействие поливендорных информационных систем, повысить качество управления, мониторинга и контроля бизнес-процессов.
Для проверки предлагаемых решений были выполнены следующие работы:
- построены модели бизнес-процессов (конструкторской подготовки производства изделия на заводе-изготовителе, централизованной технологической подготовки производства, проектирования, изготовления и эксплуатации СТО, восстановления источников геометрической информации (конструктивных плазов) и средств технологического оснащения изделий авиационной техники, строительной мастер-геометрии, технологической подготовки в цехах сборочного производства, управление комплектацией сборочного производства ВС, мониторинга и анализа состояния конструкторского, технологического, производственного процессов, взаимодействие с предприятиями-кооперантами);
- построены модели обобщенных данных для типовых систем (ERP, CAPP, CAD, PDM), выделены инвариантные и совместные данные, построена модели представления данных единой базы;
- разработаны проектные решения по построению платформы массовой интеграции на базе ESB и OGSA-DAI;
- реализован экспериментальный образец платформы массовой интеграции и проведено экспериментальное исследование его функциональных возможностей;
- определены требования к реализации поли-вендорной системы.
В дальнейшем планируется апробация полученных решений и оценка полученных результатов. Результаты работы могут использоваться на авиастроительных предприятиях.
Работа выполнена при частичной финансовой поддержке Минобрнауки России в рамках Государственного контракта № 07.514.11.4131.
СПИСОК ЛИТЕРАТУРЫ
1. Шабалкин Д.Ю. Интеграция полиплатформенных автоматизированных подсистем различной функциональности в единое информационное пространство жизненного цикла изделия авиационной техники// Известия Самарского научного центра РАН. 2012. Т. 14. № 4(2). С. 545-549.
2. Кусов А.А. Проблемы интеграции корпоративных информационных систем // Управление экономическими системами: электронный научный журнал. 2011. № 28. С. 103-109.
3. Шаппелл, Д.А. ESB - Сервисная Шина Предприятия. БХВ-Петербург, 2008. 370 с.
4. Свиридова Е.А., Ананьев С.А. Современный подход к интеграции корпоративных приложений // Студенческая аудитория. 2006. №1. URL: http://editory.ru/ publikacii/2006/vypusk-1-1/absovremennyi-podhod-k-integracii-korporativnyh-prilozheniibb/Editory1-12-2006-Sviridova%20 Ananev.pdf (дата обращения 10.04.2013).
5. Биггс М. Щедрая награда разработчикам систем EAI // Computerworld Россия. 1999. № 37. URL: http:// www.osp.ru/cw/1999/37/37546/ (дата обращения 10.04.2013).
6. Кокерет Р. Выбор технологии для интеграции прикладных систем предприятия (EAI) - JCA, JMS или Web-сервисы? // developerWorks Россия. 2008. URL: http: //www.ibm.com / developerworks/ru/library/ws-jcajms/ (дата обращения 11.04.2013).
7. Сайт компании «Неофлекс». URL: http:// www.neoflex.ru/products_solutions/ (дата обращения 11.04.2013).
8. Волкова А. СОА ждет перерождение в "облаках" // CNews Аналитика. 2012. URL: http:// www.cnews.ru/reviews/free/infrastructure2012/ articles/articles18.shtml (дата обращения 12.04.2013).
9. Хедж А. Построение модели бизнес-процесса. URL: http://www.bpmsoft.org/article/a-14.html (дата обращения 12.04.2013).
10. Черняк Л. SOA и сервисы данных// Открытые системы. 2008. № 2. С. 30-34.
11. Бежин А.А., Коваль Е.О. Доступ к базам данных с помощью OGSA-DAI и OGSA-DQP. // Материалы XVI Всероссийской научно-методической конференции «Телематика 2009». URL: http://tm.ifmo.ru/ tm2009/db/doc/get_thes.php?id=72 (дата обращения
12.04.2013). исследования в науке и образовании. 2012. № 1 Sp;
12. Дорошенко А.В. Доступ к базам данных с помощью URL: www.es.rae.ru/mino/157-670 (дата обращения
OGSA-DAI и OGSA-DQP // Междисциплинарные 12.04.2013).
CREATION OF THE INTEGRATED POLYVENDOR DIGITAL ENVIRONMENT PROVIDING AIRCRAFT LIFECYCLE SUPPORT ON THE BASIS OF SERVICE-ORIENTED APPROACH
© 2013 D.Yu. Shabalkin, S.V. Lipatova,
Ulyanovsk State University
In the article integration questions of the automated information systems on the base of service-oriented approach providing information lifecycle support of design and technology preparation of production and production of the aircraft are considered
Key words: application integration, data integration, service-oriented architecture, services, aircraft lifecycle, design and technology preparation of production and production
Dmitriy Shabalkin, Candidate of Physics and Mathematics, Deputy Director at the Center of Competence «<Aviation Technologies and Aviation Mobility». E-mail: [email protected]
Svetlana Lipatova, Candidate of Technics, Associate Professor at the Telecommunication Technologies and Networks Department. E-mail: [email protected]
