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

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

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

Одной из такого рода задач авиакомпании-эксплуатанта АТ является мониторинг уровня безопасности полетов на основе оценки состояния трех составляющих: технического состония парка ВС, качественная работа летного состава и технических бригад, условия искусственной и естественной среды для производственной деятельности (осуществления авиаперевозок) и принятие на основе

Власов Иван Владимирович, руководитель проекта «Автоматизированная система прогнозирования и предотвращения авиационных происшествий».

анализа имеющихся данных, необходимых управленческих решений, направленных на снижение уровня рисков безопасности полетов.

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

Для решения этой задачи авиакомпания «Волга-Днепр» совместно с Ульяновским Государственным университетом инициировала инновационный проект по разработке автоматизированной системы прогнозирования и предотвращения авиационных происшествий при организации и производстве воздушных перевозок (АСППАП).

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

АВТОМАТИЗИРОВАННАЯ СИСТЕМА ПРОГНОЗИРОВАНИЯ

И ПРЕДОТВРАЩЕНИЯ АВИАЦИОННЫХ ПРОИСШЕСТВИЙ

Основными задачами при разработке автоматизированной системы прогнозирования и предотвращения авиационных происшествий (АС ППАП) являются:

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

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

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

• 3)    количественная оценка рисков для безопасности полетов в стоимостной и натуральной форме на основе анализа информации об эксплуатационной деятельности авиакомпании;

• 4)    мониторинг принятых в авиакомпании показателей уровня безопасности полетов и предотвращения авиационных происшествий (ПАП) с обеспечением автоматизированной процедуры расчета текущих и директивных уровней.

• 5)    формирование проектов управленческих решений по БП и ПАП, с оценкой их эффективности и создания информационной системы их учета и контроля.

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

Для выполнения одномоментного расчета по предлагаемой модели АС ППАП понадобилось решить задачу создания единого информационного пространства через разработку программного обеспечения модуля сбора и передачи данных, который обеспечивает интеграцию прикладных систем авиакомпании и сторонних организаций.

Для выдерживания основных требований к работе АС ППАП, зафиксированных в техническом задании, потребовалось решить следующие задачи:

• 1)    Обеспечить наличие в базах данных (БД) авиакомпании, и поддержание в актуальном состоянии данных, необходимых для оценок рисков по факторам «Человек», «Машина», «Среда».

• 2)    Разработать механизмы формирования данных в соответствии с требованиями к АС ППАП.

• 3)    Разработать механизмы передачи данных в АС ППАП.

ПОДСИСТЕМА СБОРА

И ПЕРЕДАЧИ ДАННЫХ ДЛЯ АС ППАП

Разработанная подсистема «Автоматизированной системы прогнозирования и предотвращения авиационных происшествий при организации и производстве воздушных перевозок» (далее по тексту – подсистема АС ППАП ) предназначен для целевого применения в авиакомпании (АК) «Волга-Днепр» для сбора, конвертации и передачи в АС ППАП исходных данных, необходимых для оценки рисков по факторам «Человек», «Машина», «Среда».

Цель разработки данного программного обеспечения (ПО) - автоматизация подготовки данных, создаваемых в производственных процессах авиакомпании «Волга-Днепр», для использования в АС ППАП через универсальные механизмы и форматы обмена данными (общие для авиакомпаний с различными информационными системами).

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

• -    База данных аэродромов с указанием координат и существующих взлетно-посадочных полос: БД «Operations/Аэродромы»;

• -    База данных полетных заданий с выполненными перелетами и списками экипажей: БД «Operations/Полетные задания»;

• -    База данных планируемых перелетов и списками экипажей (график движения ВС): БД «Operations/Расписание»;

• -    Статистическая база данных по отказам систем авиационной техники: БД «Надёжность» (ГосНИИГА, MS Access 2007);

• -    База данных по учету ресурсов ВС, двигателей и агрегатов: модуль ИС «ИКАР»;

• -    База данных с информацией о ремонте и уровне технического обслуживания ВС: БД «Бюллетени»;

• -    База данных полетной информации о техническом состоянии систем ВС, фиксируемой параметрическим бортовым самописцем;

• -    База данных полетной информации о качестве техники пилотирования, фиксируемой параметрическим бортовым самописцем;

• -    База данных по отклонениям при обработке речевой информации, фиксирующая переговоры экипажа в кабине ВС;

• -    База данных учета данных по персоналу авиакомпании: БД «Персонал»;

• -    База данных учета летного персонала: БД «FPersonal»;

• -    База данных учета медицинских показателей летного персонала: БД «MedInfo»;

• -    База данных психофизиологических показателей летного состава: БД «Психофизиология»;

• -    База данных показателей тренажерной подготовки: БД «Тренажер»;

• -    Статистическая база данных авиационных событий и предвестников, произошедших в авиакомпании.

Подсистема АС ППАП представляет собой комплекс модулей, алгоритмов и процедур, обеспечивающих:

• 1 ) формирование выходных данных в форматах XML-документов, описанных в технической документации к АС ППАП;

• 2 ) передачу сформированных XML-документов в АС ППАП через единый согласованный механизм обмена данными.

Структура XML-документа состоит из общей части (тип документа, дата, действие, автор) и части передаваемой сущности, в соответствии с типом документа (рис.1).

Программное обеспечение состоит из серверной части, работающей на платформе СУБД Oracle 10G:

• -    Процедуры активации по событиям (триггеры);

• -    Процедуры активации по расписанию (jobs);

• -    Очередь сообщений;

• -    Процедуры для работы с очередью сообщений;

• -    Процедуры для работы с веб-сервисом;

• -    Процедура передачи данных из очереди веб-сервису;

• -    Процедуры первоначальной загрузки данных;

• -    Процедуры формирования данных;

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

• -    Интерфейс формирования данных из базы данных ИС «Надёжность»;

• -    Модуль передачи данных из базы данных ИС «Монстр».

Для реализации программного обеспечения были использованы языки программирования:

• -    PL/SQL;

• -    Object Pascal (В редакции для Borland Delphi 7);

• -    VBA (MS Access 2007).

Среда разработки Borland Delphi 7.0 c обновлениями SOAP протокола, PL/SQL Developer v.7.1.5 (Allaround Automations), СУБД Oracle 10G редакции не ниже Standard.

МЕТОД ПОСТРОЕНИЯ МЕЖПРОГРАММНОГО ВЗАИМОДЕЙСТВИЯ

Передача данных из баз данных авиакомпании в АС ППАП активируется автоматически сервером баз данных по событию (триггером), по расписанию (планировщиком заданий СУБД) или явным действием пользователя в интерфейсе ручной передачи данных.

При этом, в случае автоматической активации данные выбираются из баз данных авиакомпании процедурой формирования данных и преобразуются в текст в формате XML. Далее через асинхронный механизм передачи сообщений (единую очередь сообщений) передаётся на вход процедуры передачи данных из очереди веб-сервису (рис. 2).

Общая часть для всех -<	HME_AIRPORTS 2011-06-01T23:05:22 insert
документов
	UWLW ВОСТОЧНЫЙ 77 54,40166667 48,80500000 РФ Civil
Структура	N
передаваемой
сущности V (Аэродром) \	02
	5000 5150 5000 5000
	20 5150

Рис.1. Структура передаваемого веб-сервису XML-документа (на примере данных об аэродроме)

Рис. 2. Схема интеграции АС ППАП с базой данных авиакомпании

При невозможности передать данные вебсервису из-за его недоступности, процедура передачи данных ожидает в течение заданного в настройках интервала времени и пытается отправить накопившиеся сообщения повторно. При отказе сервиса принять сообщение данные могут быть высланы на e-mail или переданы в очередь ошибочных сообщений с регистрацией информации о событии в журнале ошибок.

В случае ручной активации предполагается, что пересылаемый документ подготовлен вне Подсистемы АС ППАП и передан Подсистеме АС ППАП через интерфейс ручной передачи данных путём выбора файла, содержащего текст XML-документа или путём вставки текста в интерфейс ручной передачи данных через буфер обмена Windows. В данном случае не задействована СУБД Oracle и результат взаимодействия с веб-сервисом АС ППАП контролируется пользователем визуально.

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

Для взаимодействия процедур с очередью сообщений и с веб-сервисом реализованы пакеты процедур, являющиеся неотъемлемой частью Подсистемы АС ППАП (рис. 3).

ВЫБОР ТЕХНОЛОГИИ ИНТЕГРАЦИИ ИС

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

К моменту реализации проекта АС ППАП опыт использования технологий для построения межпрограммных связей для обмена между системами в авиакомпании можно представить 3 типа взаимодействия:

• 1)    Непосредственная связь с базами данных через различные механизмы (DBLink, ODBC, DOA, ActiveX, COM, Oracle AQ) механизмы;

Данному типу взаимодействия между программным обеспечением можно присвоить следующие характеристики:

• -    высокая скорость обмена данными;

• -    отсутствие необходимости программировать адаптеры для обмена данными;

• -    сомнительные перспективы масштабируемости;

• -    сложная архитектура и тесная увязка программного обеспечения и «железа».

• 2)    Обмен файлами через файловую систему, локальные сети, ftp и http серверы, база данных XML DB;

Для этого типа характерны следующие черты:

• -    легкость реализации, многие системы поддерживают выгрузки, в том или ином формате;

• -    асинхронная передача, при этом отсутствие гарантии доставки файла;

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

• -    полное отсутствие стандартов по структуре файлов обмена данными.

• 3)    Веб-сервисы, построенные на поставляемой с СУБД Oracle веб-платформе (Apache DSO);

К положительным моментам использования

Рис. 3. Схема инструментов для работы с очередью и веб-сервисом

механизма веб-сервисов, стоит отнести:

• -    информация о доставке, которая обеспечивает как синхронное, так и асинхронное взаимодействие между программным обеспечением;

• -    наличие стандартов по передаче данных и описанию веб-сервисов (WSDL);

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

Обобщив, полученные на основании имеющегося опыта интеграции, характеристики разработчиками АС ППАП был проведен анализ различных механизмов построения межпрограммных связей по следующим критериям и существующим условиям:

• -    наличие как синхронных, так и асинхронных механизмов;

• -    гетерогенная среда;

• -    возможность загрузки данных, как в автоматическом, так и в ручном режиме;

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

• -    наличие механизмов разбора/извлечения данных;

• -    универсальность;

• -    низкая зависимость от устаревающих технологий.

Наиболее оптимальным для решения задачи создания единого информационного поля АС ППАП был выбран подход с использованием веб-сервисов и обмен данными в формате XML-документов.

Формат XML-документов, в том числе обладает рядом преимуществ:

• -    легкость преобразования между форматами XML (XSLT);

• -    простота формирования;

• -    структурированность, и как следствие, простота разбора;

• -    фактический стандарт для обмена данными;

• -    поддерживается большинством современных платформ.

Стоит отметить, как уже было указано выше в описании метода, что программное обеспечение для интеграции АС ППАП и прикладных систем предприятия основано на совмещении двух механизмов: очереди сообщений и веб-сервиса.

ПЕРСПЕКТИВЫ РАЗВИТИЯ СЕРВИС-ОРИЕНТИРОВАННОЙ АРХИТЕКТУРЫ

В АВИАКОМПАНИИ

Основой сервис-ориентированной архитектуры SOA (service oriented architecture) являются сервисы. Сервис – это программа, которая умеет выполнять какое-то действие по внешнему запросу и при необходимости может возвращать результат, для разработки подходит абсолютно любой язык программирования, умеющий работать с TCP/IP протоколом. Для взаимодействовия с сервисом внешних программ, существует стандартный протокол SOAP (Simple Object Access Protocol, простой протокол доступа к объектам), который основан на HTTP запросах.

Стоит отметить, что протокол SOAP базируется на двух открытых стандартах XML и HTTP. Эти стандарты независимы от платформы, что обеспечивает работу сервисов на любых платформах при наличии поддержки протокола TCP/IP. А TCP/IP протокол присутствует практически во всех современных устройствах и операционных системах, что расширяет границы архитектуры SOA.

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

Данный подход использования веб-сервисов и создаваемой архитектуры SOA полностью совпадает с процессным подходом при управлении организацией, внедреннный в авиакомпании.

Архитектура, построенная на выбранных принципах позволяет легко контролировать межпрограммное взаимодействие и обеспечивать требуемый для системы уровень надёжности. Опыт, полученный специалистами авиакомпании в ходе интеграции АС ППАП с прикладными системами, в сочетании с внедрением процессного подхода в управлении организации, создает плодотворную почву по дальнейшему развитию сервис-ориентированного подхода в авиакомпании, создания соответствующей ему архитектуры взаимодействия информационных систем (SOA), и в том числе, предпосылки по внедрению системы управления бизнес-процессами предприятия (BPMS) на базе этой платформы.

ЗАКЛЮЧЕНИЕ

С каждым годом конкуренция на рынке производителей ПО для авиа отрасли возрастает и разработчикам программного обеспечения авиакомпании придется решать все больше задач интеграции, при этом средства интеграции должны обладать свойствами универсальности, для их использования в любой другой системе и надежности (на примере реализации АС ППАП: направление - безопасность полетов существенно зависит от точности и достоверности данных). Сервисно-ориентированный подход, в достаточной мере удовлетворяет этим требованиям и может быть использован в реализации перспективных проектах авиакомпании, таких как внедрение системы управления бизнес-процессами и создание интеграционной шины (ESB) предприятия.