science-review.ru
Бортовой комплекс управления самолетом должен отвечать высоким требованиям по безопасности. Это достигается соблюдением нормативных требований и внешним контролем сертифицирующих органов [1]. При этом весь процесс разработки программного обеспечения строго регламентирован и отступление от него влияет на процесс сертификации, а значит, на возможность дальнейшего использования.
Выполнение целевых функций в комплексах бортового оборудования воздушных судов обеспечивается строгим соблюдением протоколов информационного взаимодействия между отдельными системами и/или функциональными программными приложениями. В связи с этим при появлении новых систем и/или функций возникает проблема обновления протоколов информационного взаимодействия [2] и их согласованности.
Разработка и квалификация новых функциональных программных приложений и систем является сложной, затратной процедурой, поэтому усилия направляются на реализацию возможности повторного использования уже квалифицированных приложений: новый функционал может достигаться, к примеру, за счет их комбинации. В этом случае протоколы информационного взаимодействия не будут совпадать с исходными.
Отсюда возникает проблема не просто обновления протоколов (что потребует изменения приложений), а их унификации [3, 4], чтобы формат сообщений мог быть адаптирован под любые взаимодействующие приложения.
При условии неизменности приложений требуется разработка дополнительного программного средства, которое будет трансформировать сообщения необходимым образом.
В связи с этим была изучена практика подхода консорциума FACE [5], разрабатывающего стандарт, который направлен на упрощение интеграции повторно используемого программного обеспечения, как в новые проекты, так и в существующие рабочие проекты [6, c. 1–12].
В рамках данной работы рассматривался бортовой комплекс интегрированной модульной авионики и взаимодействие между приложениями [7–9].
Для моделирования процессов использовались архитектурные решения, предложенные FACE [6, c. 4–12], в рамках которых предлагается выделить сегмент транспортных служб, отвечающий за передачу сообщений [3; 6, c. 49–81]. Основываясь на этих данных и учитывая выбор стандарта ARINC 653 [10, c. 49–75], были сформулированы требования на разработку программного обеспечения, которое позволит реализовать унификацию протоколов информационного взаимодействия [11].
Программное обеспечение было реализовано, а затем включено в комплекс-демонстратор, позволяющий оценить работу программного обеспечения на моделируемых входных и выходных данных и проводить тестирование информационного взаимодействия функциональных программных приложений.
Данная работа направлена на поиск решения по адаптации обмена сообщениями между функциональными приложениями в условиях сертификационных ограничений на модификацию уже квалифицированных программных модулей. В условиях узкоспециализированной среды поиск решения ограничен, однако, анализируя опыт консорциума [5], а также опыт смежных специалистов [3; 4; 12], решение по унификации формата сообщений посредством специального программного обеспечения представляется наиболее логичным.
Следовательно, целью данной работы стала разработка программного обеспечения, которое служило бы для устранения имеющихся различий в форматах передаваемых/принимаемых сообщений. Для достижения данной цели разработано специальное программное обеспечение, которое включено в комплекс-демонстратор [13].
Материалы и методы решения
В программировании наиболее широко используемым способом организации данных является структура, которая включает в себя логически связанные наборы данных, в том числе и другие структуры. Для обмена информацией между приложениями чаще всего используются сообщения, представляющие собой структуры данных, где смысл данных обычно определяется местом в структуре [9, 12].
Порты передачи данных определяются ARINC 653 [10, c. 4–12], который был выбран для моделирования за удобство формирования сообщений.
Стандарт FACE требует, чтобы все структуры, которыми обмениваются приложения, строго соответствовали определенной модели данных [6, c. 82–86]. Реализация такого подхода требует либо создания приложений с учетом стандарта [6, c. 57–81], либо внесения изменений в уже созданные приложения.
В рамках данной работы требуется увязка уже существующего и квалифицированного функционального программного обеспечения, что накладывает существенные ограничения на возможность изменения этих модулей [1; 2].
Таким образом, необходимо обеспечить преобразование содержимого передаваемых сообщений так, чтобы оно соответствовало ожиданиям принимающего приложения без изменения самого приложения.
Данная задача решается, благодаря разработке специального программного обеспечения – Адаптера [3; 4; 12], который циклически получает и выдает информацию через порты ARINC 653 [10, c. 4–12], используя сервисы операционной системы реального времени [13] и обеспечивает трансформацию сообщений, не затрагивая структуру самого функционального программного обеспечения.
Таким образом, основным методом, используемым для решения поставленной задачи, является преобразование [3; 6, c. 49–73].
Возможными вариантами преобразований являются:
1. Преобразование размещения данных. Данный тип преобразования является наиболее очевидным при обмене структурами. Для реализации этого решения необходимо располагать информацией о порядке расположения данных внутри сообщений. Возможен вариант, когда необходимые выходные данные могут быть получены с помощью нескольких входных или быть частью сообщения, т.е. нет прямого соответствия между выходными и входными сообщениями и/или их частями.
2. Преобразование порядка выдачи данных.
3. Преобразования формата представления данных у источника и приемника. Различия могут быть существенными. Например, часто различается представление вещественных чисел – как по занимаемому размеру, так и по внутренней структуре представления мантиссы и порядка. Стандарт FACE полагает, что все вещественные числа должны быть представлены в формате IEEE 754 [14, c. 6–14] одинарной точности (32 разряда), двойной точности (64 разряда) или расширенной точности (80 разрядов). Может различаться и представление целых чисел в части числа занимаемых разрядов.
4. Преобразование единиц измерения в случае различных представлений данных на выход и прием.
5. Линейное преобразование чисел.
6. Преобразование начала и направления отсчета.
7. Преобразование кодировки (например, в случае обмена текстовыми данными).
8. Преобразование пересчета. Например, пересчет электрических показаний датчика в физические значения.
9. Преобразование систем отсчета (для систем координат или географических данных).
Все необходимые преобразования для настройки корректного информационного взаимодействия Адаптер будет исполнять, используя конфигурационные данные, сформированные заранее.
Адаптер должен допускать изменение значительного объема своих рабочих параметров – в первую очередь размера и числа портов и их характеристик, периодичность процессов, предназначенных для преобразования сигналов, а также состава структур, типов данных переменных в указанных структурах и алгоритмов преобразования [3; 6, c. 49–73]. Изменение рабочих параметров должно осуществляться без изменения исходного кода, с помощью конфигурационного файла.
Кроме декларации единого формата модели данных, стандарт FACE [5; 6, c. 63] определяет требование к обеспечению адаптации между собой различных способов передачи пакетов: Publish/Subscribe (Публикация/Подписка) и Request/Response (Запрос/Ответ), что также требует рассмотрения.
Результаты исследования и их обсуждение
В концепции FACE [6, c. 4–12] предлагается следующая архитектура:
− сегмент операционной системы (Operating System Segment – OSS),
− сегмент перемещаемых компонентов (Portable Components Segment – PCS),
− сегмент служб, специфичных для платформы (Platform-Specific Services Segment – PSSS),
− сегмент транспортных служб (Transport Services Segment – TSS),
− сегмент ввода/вывода (I/O Services Segment – I/O SS).
В настоящее время в российской авиационной промышленности отсутствует стандарт, аналогичный FACE, и разрабатываемые приложения учитывают только стандарт ARINC 653 [9; 10]. Поэтому предложено реализовать задачи преобразования информации от/для устройств ввода/вывода, решаемые в PSSS и TSS с помощью Адаптера [3; 8].
На данном этапе специальная программа-Адаптер берет на себя функции унификации и адаптации, что позволяет на данном этапе иметь адаптеру требуемый функционал без создания дополнительных программных средств.
В зависимости от задач, которые планируется решать с помощью Адаптера, необходимо формирование расписания вызова и определение порядка обслуживания портов. В частном случае, Адаптер, привязанный к конкретному приложению, может быть вызван непосредственно перед самим приложением для обработки его входящих сообщений.
Входные и выходные порты Адаптера увязываются с входными и выходными портами функциональных приложений, так же как входные порты одного функционального приложения и выходные порты другого увязываются через Адаптер.
Для апробации возможностей Адаптера решено встроить его в процесс информационного обмена между функциональным программным обеспечением «автопилота» (AFA), системой самолетовождения (Flight Management System – FMS) и внешним окружением [3; 8; 9]. Стоит отметить, что Адаптер позволяет работать и с другими функциональными приложениями. Для этого необходимо произвести настройку конфигурационных файлов.
Программное обеспечение Адаптера реализовано для запуска под операционной системой реального времени (ОСРВ) JetOS [9; 11; 13], разработанной ФАУ «ГосНИИАС» и используемой для моделирования других компонентов.
При подготовке запуска информационного обмена с использованием адаптера необходимо включить в состав интеграционного проекта те модули, между которыми должен быть настроен обмен, а также подготовить и настроить конфигурационные и настроечные файлы.
Важной особенностью реализации является возможность реализовать наличие внешней среды, что является актуальным на этапе включения моделей в комплекс-демонстратор.
Для упрощения создания нового проекта информационного обмена на основе шаблона разработан скрипт, заполняющий изменяемые данные на основе пользовательского ввода и дающий дальнейшие инструкции по заполнению конфигурационных и настроечных файлов.
Процесс работы скрипта в окне терминала представлен на рис. 1. Настройка производится в соответствии с рекомендационными материалами, доступными пользователям.
В частности, вводятся имена взаимодействующих модулей (приложения, участвующие в обмене), ограничения на размер сообщения без очереди, длительность, задается файл с заголовками функций трансформации, добавляется файл с определением функций трансформации, где функции соответствуют определенным сигнатурам, подключается библиотека поддержки функций, обновляется, если необходимо, атрибут процесса «Период».
При запуске такой конфигурации информационного взаимодействия функционального программного обеспечения системы FMS и системы AFA в терминале может отслеживаться процесс информационного обмена.
Пример отладочной печати приведен на рис. 2.
Дальнейшим развитием данного решения является его работа в рамках демонстратора информационного обмена, где устанавливается взаимодействие с внешней средой. При этом оценивается корректность работы Адаптера и приложений, запущенных в операционной системе реального времени JetOS.
Рис. 1. Интерфейс создания нового проекта информационного обмена
Рис. 2. Пример отладочной печати информационного обмена
Заключение
В работе рассмотрен подход к унификации формата сообщений, которыми обмениваются авиационные функциональные приложения.
В рамках данного проекта:
1. Обоснована необходимость разработки адаптера информационного обмена.
2. Определена среда реализации проекта.
3. Рассмотрены сообщения, передаваемые моделями модулей системы FMS и системы AFA.
4. Разработаны форматы конфигурационных и настроечных файлов.
5. Создан адаптер, обеспечивающий:
− автоматическую транспортировку сообщений между приложениями;
− автоматическое преобразование содержимого сообщений;
− наличие функций, облегчающих реализацию преобразования.
6. Апробирован адаптер для обмена сообщениями между системами FMS и AFA.
7. Адаптер включен в состав демонстратора информационного обмена унифицированных программных компонентов на базе операционной системы JetOS.