Применение зарубежного программного обеспечения в бортовых авиационных системах не только грозит технологической зависимостью, но и создает реальную угрозу национальной безопасности: в условиях санкционной политики такие решения могут попасть в зону ограничений. Кроме того, возникают риски внешнего вмешательства в работу критически важных систем. Положение может исправить разработка отечественных программных продуктов, отвечающих строгим международным стандартам для авиационной промышленности, что позволит в том числе исключить ситуацию, подобную истории с Boeing 737 MAX [1].

Комплексы бортового оборудования воздушных судов разрабатываются в авиационной промышленности в соответствии с концепцией интегрированной модульной авионики (ИМА) [2], используемой в том числе и в лайнерах Airbus А320, Boeing 787, Sukhoi Superjet 100 и МС-21. В основе архитектуры ИМА лежит объединение приборов и бортовых вычислителей в единую сеть реального времени, что дает возможность существенно снизить количество кабелей на борту, а значит, и уменьшить взлетный вес лайнера. В ИМА разделены функции сбора телеметрии от датчиков, ее отображения пилотам и передачи алгоритмам управления воздушным судном, реализуемым специализированным прикладным ПО в бортовых вычислительных модулях. Международный стандарт ARINC 653 описывает требования к операционной системе реального времени (ОСРВ) для таких модулей и к интерфейсам с прикладным авиационным ПО. В России ведется разработка ОСРВ JetOS, удовлетворяющей стандарту ARINC 653 [3].

Важная часть бортового оборудования воздушных судов — система отображения информации о состоянии всех систем самолета в удобном для восприятия пилотами виде.

Де-факто сложился стандарт отображения информации в так называемой стеклянной кабине, когда в кабине пилотов вместо множества механических указателей используются дисплеи (рис. 1). Детали изображений в разных лайнерах отличаются, а пилоты имеют возможность выбрать для своего дисплея информацию, которая будет визуализироваться в каждый момент времени. В современной панели самолета МС-21 форма представления данных модернизировалась, но общий подход сохранился, что объясняется как стремлением к стандартизации, так и тем, что в большинстве случаев приложения для визуализации информации в системах бортового оборудования воздушных судов генерируются с помощью системы SCADE (Safety-Critical Application Development Environment, www.ansys.com/products/embedded-software). Визуализация в SCADE выполняется средствами библиотеки OpenGL, удовлетворяющей стандартам OpenGL SC (Safety Critical, https://www.khronos.org/registry/OpenGL/index_sc.php). В свою очередь, применение ОСРВ, удовлетворяющей стандарту ARINC 653, накладывает ограничения как на библиотеку OpenGL, так и на приложения на ее основе, работающие в критически важных для безопасности системах.

Рис. 1. Панели кабин Airbus А320, Sukhoi Superjet 100 и МС-21 (сверху вниз)

Существуют два действующих стандарта OpenGL SC: 1.0.1 и 2.0.1. Они представляют собой подмножество стандартов OpenGL 1.3 и OpenGL ES 2.0, разработанное для бортовых графических систем. Из этих стандартов удалены возможности, не соответствующие требованию детерминированности поведения. Например, для исключения фрагментации памяти и необходимости сборки мусора исключена возможность удаления объектов. В стандарте ARINC 653 вообще отсутствует функция освобождения памяти, а функции выделения памяти могут использоваться только на этапе инициализации приложения (для авиалайнера — только на земле). В режиме «NORMAL mode» (самолет в воздухе) функция выделения памяти запрещена.

Стандарт ARINC 653 регламентирует также разделение ресурсов во времени и пространстве в соответствии с принципами ИМА для обеспечения защиты одного приложения от ошибок в другом. Так, при переключении процессора с выполнения одного приложения на выполнение другого в обязательном порядке очищается содержимое регистров и кэш-памяти. В ОСРВ такие переключения выполняются часто, что снижает производительность.

Для сертификации библиотеки OpenGL для работы на борту, процесс ее разработки должен соответствовать авиационным стандартам DO-178C/КТ-178С [3] с предоставлением полного доступа к исходным кодам. Важным требованием является независимость от платформы: ядро библиотеки не должно содержать кода, специфического для конкретной программной архитектуры или аппаратной платформы. На рынке имеются OpenGL-драйверы для графических процессоров, однако их сертификация обычно невозможна без привлечения разработчиков графических процессоров, поэтому программная реализация библиотеки OpenGL оказывается единственно возможным решением при создании отечественной графической системы в составе комплекса бортового оборудования воздушных судов. Конечно, программная реализация библиотеки уступает по производительности аппаратной, однако ее существенно проще оптимизировать для специальных приложений. Именно этот подход и был использован при реализации программной библиотеки OpenGL для авионики, полностью удовлетворяющей стандарту OpenGL SC 1.0.1.

Существует множество алгоритмов для программных библиотек OpenGL, реализация которых на современных архитектурах (например, Intel i7-4770/3,4 ГГц) позволяет получить приемлемую производительность для типичных авиационных приложений — 50 кадров в секунду, что сравнимо с показателями драйвера для Nvidia Quadro 410. Однако такие прямые и простые реализации библиотеки OpenGL не обеспечивают требуемой производительности для широко используемых авиационных компьютеров на платформах PowerPC e500mc или i.MX6. Типичное авиационное приложение «Пилотажно-навигационный дисплей» (Primary flight display, рис. 2, а) будет работать со скоростью около одного кадра в секунду, а более современная версия (рис. 2, б) — со скоростью два кадра в секунду, что неприемлемо. Для авиационных приложений минимально допустимая скорость визуализации составляет пять кадров в секунду, а для критичных — не менее 20 кадров.

Рис. 2. Две версии пилотажно-навигационного дисплея

Решением может быть оптимизация программной реализации OpenGL SC с учетом специфики авиационных приложений, большинство которых используют визуализацию только двумерных объектов: показаний приборов в цифровом и аналоговом виде, данных о положении воздушного судна в пространстве, индикаторов состояния оборудования, метеорологической информации и пр. Профилирование таких приложений показало, что основное время при их работе расходуется на алгоритмы построения изображения (растеризацию). Кроме того, для визуализации в этих приложениях используется достаточно ограниченное число сочетаний вызовов команд OpenGL. С учетом этих допущений можно увеличить производительность визуализации примерно вдвое [4] для авиационных приложений при сохранении полного покрытия спецификаций стандарта OpenGL SC 1.0.1. Оптимизация алгоритмов растеризации позволила ускорить визуализацию пилотажно-навигационного дисплея (рис. 2, а) до 7,4 кадра в секунду, а дисплея (рис. 2, б) — до 14,5 кадра. Однако этого недостаточно для ряда случаев, особенно с учетом того, что на этом же процессоре могут работать и другие приложения.

Следующий шаг в сторону ускорения визуализации — использование многоядерности. Типичный для применения в авиации процессор PowerPC (P3041) имеет четыре ядра, а PowerPC (P4080) включает восемь ядер, однако стандартный интерфейс в ARINC 653 не предусматривает работу с несколькими ядрами, поскольку это противоречит требованиям безопасности для критически важных систем. К счастью, ОСРВ JetOS поддерживает возможность запуска нескольких независимых экземпляров ОС (модулей) на одном устройстве. Асимметричная многопроцессорная обработка (Asymmetric MultiProcessing, AMP), предусмотренная в JetOS, и была использована для ускорения работы программной версии OpenGL SC.

Схема работы библиотеки OpenGL при синтезе одного кадра включает три основных этапа:

  • обработка инструкций OpenGL, поступающих из приложения;
  • построение изображения во внутреннем буфере;
  • копирование внутреннего буфера в память экрана.

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

Для параллельной генерации нескольких последовательных кадров используется соответствующее число экземпляров JetOS (логически — это серверы). Один экземпляр JetOS работает как клиент — в нем реализуются первый и третий этапы, а второй этап выполняется параллельно на серверных экземплярах JetOS для нескольких кадров одновременно. Однако в отличие от многопоточности здесь нельзя запустить произвольное количество экземпляров JetOS — их не может быть больше числа ядер процессора. Поэтому, например, для PowerPC (P3041) одно ядро задействуется под клиента, обрабатывающего инструкции OpenGL для каждого кадра и выводящего кадры на экран, а три сервера параллельно занимаются построением кадров изображений. Описание многоядерной реализации OpenGL SC приведено в [5].

Ключевая проблема при разработке ПО, использующего модули, работающие на разных ядрах процессора, — передача данных между модулями и синхронизация их работы, обеспечиваемые ОСРВ. В JetOS средствами AMP поддерживаются блоки памяти с доступом от различных модулей, которые используются для передачи сгенерированных изображений. Для синхронизации применяются небольшие (16 байт) блоки памяти, доступ к которым от разных модулей реализован с помощью атомарных операций (аtomic operations). Использование всех ядер процессора позволило добиться скорости визуализации пилотажно-навигационного дисплея 21,8 кадра в секунду (в версии рис. 2, а) и 28,4 кадра в секунду (в версии рис. 2, б), что уже соответствует требованиям к графическим системам в авионике.

В создании оборудования для кабин современных авиалайнеров наметилась тенденция применения больших дисплеев, что хорошо заметно при сравнении панелей МС-21 и Superjet 100 (рис. 1). Число дисплеев в кабине МС-21 уменьшилось по сравнению с кабиной Superjet 100, но дисплеи стали шире, что позволило на одном экране выводить изображения из нескольких бортовых систем. В современных ОС это решается путем применения многооконного интерфейса, где одно окно соответствует одному приложению. В простом случае можно позволить каждому приложению открывать окно, не перекрывающее другие, что ускоряет визуализацию, но требует дополнительных усилий при реализации в системах, критичных для безопасности. В случае программной реализации OpenGL наиболее естественным способом является использование компоновщика [5]. Для каждого приложения и для компоновки изображений на экране можно использовать свой экземпляр JetOS, работающий на отдельном ядре. Однако в этом случае не всегда удается добиться необходимой производительности визуализации, поскольку для четырехъядерного процессора нельзя завести достаточное число серверов. В примерах на рис. 3 для пилотажно-навигационного дисплея (левая половина) была достигнута скорость только 10,3 кадра в секунду, а для визуализации состояния дверей и для навигационного дисплея — 21,7 кадра. Таким образом, скорость многооконной визуализации пилотажно-навигационного дисплея на четырехъядерном процессоре не удовлетворяет требованиям, предъявляемым к бортовым графическим системам.

Рис. 3. Визуализация двух приложений на одном дисплее

К сожалению, возможности дальнейшего ускорения визуализации для программной реализации OpenGL на этом исчерпываются. Далее можно применять специализированные графические процессоры, для большинства которых сегодня имеются версии Linux с пакетом MESA — открытой реализацией API OpenGL и Vulkan (кросс-платформенный API для 2D- и 3D-графики), где закрыты обычно только коды драйверов для некоторых графических процессоров. Однако портирование открытого кода на ОСРВ JetOS — нетривиальная задача, поскольку необходимо реализовать функции, отсутствующие в JetOS (например, связанные с использованием динамической памяти).

Тесты, проведенные для одноплатного компьютера Wandboard на базе процессора i.MX6 и GPU Vivante, широко используемых в бортовых системах гражданской авиации, показали, что графический процессор в 2–8 раз ускоряет работу библиотеки OpenGL. Таким образом, применение GPU под управлением JetOS перспективно, однако отсутствие отечественных графических процессоров затрудняет сертификацию такого решения.

***

Если при разработке операционной системы реального времени JetOS обеспечить функциональные требования и требования, связанные с сертификацией платформы по стандарту DO-178C, то данная система может применяться в современной отечественной авионике гражданских воздушных судов. Это даст возможность решить проблемы импортозамещения, технологической независимости и кибербезопасности авиационных систем, сведя к минимуму риски несанкционированного вмешательства в работу авионики. Предлагаемая программная реализация библиотеки OpenGL SC для JetOS позволяет достигнуть требуемой производительности при выполнении приложений, отвечающих за визуализацию информации в кабине пилотов авиалайнера. Эта реализация — неотъемлемая часть среды, сертифицируемой для работы в составе критически важных систем. Дисплеи кабины пилотов, работающие на данной системе визуализации, демонстрировались на авиасалонах МАКС-2017 и МАКС-2019.

Литература

1. Дмитрий Волков. Программист и собака // Открытые системы.СУБД. — 2019. — № 2. — С. 1. URL: https://www.osp.ru/os/2019/02/13054956 (дата обращения: 21.03.2020).

2. Е.А. Федосов, В.В. Косьянчук, Н.И. Сельвесюк. Интегрированная модульная авионика // Радиоэлектронные технологии. — 2015. — № 1. — C. 66–71.

3. Ю.А. Солоделов, Н.К. Горелиц. Сертифицируемая бортовая операционная система реального времени JetOS для российских проектов воздушных судов // Труды ИСП РАН. — 2017. — Том 29, выпуск 3. — C. 171–178. DOI: 10.15514/ISPRAS-2017–29 (3) –10.

4. Б.Х. Барладян, А.Г. Волобой, В.А. Галактионов, В.В. Князь, И.В. Ковернинский, Ю.А. Солоделов, В.А. Фролов, Л.З. Шапиро. Эффективная реализация OPENGL SC для авиационных встраиваемых систем // Программирование. — 2018. — № 4. — С. 3–10.

5. B.Kh. Barladian, L.Z. Shapiro, K.M. Mallachiev, A.V. Khoroshilov, Y.A. Solodelov, A.G. Voloboy, V.A. Galaktionov, I.V. Koverninskiy. Multi-windows rendering using software OpenGL in avionics embedded systems // CEUR Workshop Proceedings, V. 2485, Proc. of the 29th International Conference on Computer Graphics and Vision, 2019. P. 28–31.

Борис Барладян (bbarladian@gmail.com), Алексей Волобой (voloboy@gin.keldysh.ru), Владимир Галактионов (vlgal@gin.keldysh.ru), Лев Шапиро (pls@gin.keldysh.ru)  —  сотрудники, Институт прикладной математики им. М.В. Келдыша РАН (Москва).

DOI: 10.26295/OS.2020.99.87.002