Статья посвящена описанию опыта применения операционной системы (ОС) RTOS-32 в авиационной системе эксплуатационного контроля и аварийной регистрации (ЭКАР). Рассмотрены условия создания наземно-бортовых систем ЭКАР и особенности их программно-аппаратной реализации. Сформулированы принципы выбора программно-аппаратной реализации систем в целом и ОС в частности, позволяющие минимизировать стоимость жизненного цикла ЭКАР. Описаны новые функциональные возможности RTOS-32, реализованные в ЭКАР типа КАРАТ.
Системы эксплуатационного контроля и аварийной регистрации (ЭКАР) полётной информации занимают особое место среди бортового радиоэлектронного оборудования летательного аппарата (ЛА).
Современная система ЭКАР должна обеспечивать в режиме реального времени (РРВ) приём, обработку и контроль мультимедийной информации (параметрической, аудио и видео), её регистрацию на нескольких накопителях (эксплуатационный, защищённый, малогабаритный спасаемый) и техническое обслуживание своих блоков. Основной особенностью систем ЭКАР является наличие наземной части, которая обеспечивает считывание, обработку и воспроизведение зарегистрированной в полёте информации, а также управление и визуализацию результатов работы при техническом обслуживании бортовых блоков.
На рис. 1 представлен пример современной системы ЭКАР – комплекса анализа работы авиационной техники (КАРАТ).
Современная система ЭКАР является многоблочной, многофункциональной и обрабатывает большие потоки мультимедийной информации в РРВ. Программно-аппаратная реализация систем ЭКАР имеет следующие особенности:
Проектирование и эксплуатация систем ЭКАР осуществляется в следующих условиях:
Принимая во внимание требования к программно-аппаратной реализации систем ЭКАР и условиям их проектирования, при определении облика систем КАРАТ была выбрана стратегия использования имеющихся на рынке коммерческих программно-аппаратных компонентов. Основными требованиями к этим компонентам являются следующие:
Прежде чем приступить к анализу опыта применения конкретной ОС RTOS-32 в системах КАРАТ, авторы считают необходимым изложить принципы выбора программно-аппаратной реализации систем ЭКАР, которые были сформулированы в ходе дебатов с коллегами по этому вопросу.
15-летний опыт создания систем КАРАТ показывает, что стоимость жизненного цикла (ЖЦ) систем ЭКАР существенно зависит от выбранных при проектировании программно-аппаратных и технологических решений.
За время ЖЦ систем ЭКАР (25–32 года) согласно эмпирическому закону Мура число транзисторов на кристалле удваивается каждые 2 года и производительность цифровых систем экспоненциально возрастает. Вместе с электронными компонентами существенно меняются доступные на рынке информационные технологии. На протяжении ЖЦ системы приходится многократно осуществлять замену программно-аппаратных компонентов, выполнять повторную отладку и верификацию системы. Сложность и стоимость процесса повторной отладки напрямую зависят от архитектуры системы и совместимости применяемых при проектировании технологий с технологиями будущих реализаций. Чем более узкоспециализированными были технологии и правила взаимодействия компонентов системы в начале проектирования, тем выше вероятность, что они «разойдутся» с будущими технологиями и правилами, формируемыми рынком. Следствием этих отличий являются значительные усилия, которые необходимо приложить для сопряжения компонентов (рис. 2).
Для минимизации затрат на ЖЦ систем ЭКАР необходимо при проектировании следовать следующим принципам:
Первый принцип построения системы ЭКАР. Минимизация числа точек сопряжения и типов взаимодействия сопрягаемых компонентов в системе.
Второй принцип построения системы ЭКАР. Применение в точках сопряжения наиболее широко используемых открытых стандартов и технологий, доступных на рынке компонентов основного потока, то есть использование коммерческих аппаратных и программных средств, по возможности COTS-решений.
На рис. 3 приводятся графики стоимости ЖЦ систем ЭКАР ЛА для двух вариантов технологий – традиционной, базирующейся на узкоспециализированных авиационных правилах, и существующей технологии КАРАТ, базирующейся на COTS-решениях и открытых международных стандартах.
При проектировании системы по традиционной авиационной технологии начальные затраты ниже за счёт использования специализированных компонентов и авиационных правил. Это утверждение справедливо, если на момент начала проекта правила еще не успели устареть. Со временем необходимость в модификации системы приводит к экспоненциальному росту стоимости её ЖЦ, вызванному высокой трудоёмкостью сопряжения авиационных и неавиационных компонентов.
Стоимость модификации на протяжении ЖЦ системы, построенной на основе технологии КАРАТ, базирующейся на COTS-решениях и открытых международных стандартах, значительно ниже за счёт менее трудоёмкой модернизации системы. Низкая трудоёмкость модернизации системы обусловлена следующими причинами:
Из первого принципа следует правило минимизации числа адаптеров (аппаратных преобразований). На рис. 4 приведены для сравнения реализации бортовых межблочных интерфейсов – старого авиационного интерфейса ARINC 429 и современного стандартного Ethernet.
Общение двух современных процессоров по ARINC 429 по интерфейсу с 30-летней историей можно сравнить с переводом текста, написанного на одном из западноевропейских языков, на древнеегипетский язык и обратно. Так как в древнем языке нет ряда понятий современного языка, то такая конвертация данных неизбежно приводит к искажению семантики, а степень искажения зависит от разности языков и идеологий. И чем больше отличаются языки, тем дороже конвертация в процессе работы и более трудоёмка отладка взаимодействия при модернизации системы. Стоит также иметь в виду, что на сложные конвертации данных расходуются ресурсы процессора, что предъявляет повышенные требования к характеристикам вычислителя.
В нашем примере Ethernet – это язык, понятный современным процессорам и не требующий перевода на аппаратном уровне COTS-модуля.
Таким образом, при проектировании систем необходимо выбирать те языки (технологии), которые требуют минимальных преобразований на аппаратном уровне.
Аналогичное правило формулируется и для программного обеспечения – минимизация числа преобразований на программном уровне. В настоящее время для обеспечения адаптации ПО к смене программно-аппаратных компонентов в течение ЖЦ авиационных систем разрабатывается технология интегрированной модульной авионики (ИМА), схематически представленная на рис. 5.
Суть этой технологии в отделении приложений от среды выполнения (аппаратура, ОС, драйверы) и обеспечении общения приложений со средой выполнения по POSIX-стандарту. Тогда при переходе к новой реализации необходимо настроить интерфейсы между приложениями и средой выполнения. Такая технология не оправданна для систем ЭКАР, у которых 85–90% СПО составляют интерфейсы, а алгоритмическое обеспечение (приложение) составляет всего 10–15%. В этом случае для исполнения сравнительно небольшого приложения задействованы большая операционная система и сложная система драйверов, требующая много ресурсов.
Для систем ЭКАР следует проводить программную адаптацию к смене компонентов на уровне системы (приложение + ОС + драйверы как единое целое, генерируемое в ОС OnTime RTOS-32), схематически технология программной адаптации показана на рис. 6.
Такой подход позволит значительно снизить затраты на отладку системы в целом, он существенно менее требователен к ресурсам процессора в момент исполнения и не противоречит принятой процедуре тестирования и верификации системы при смене поколений аппаратуры.
Следующим правилом, вытекающим из первого принципа и позволяющим минимизировать стоимость ЖЦ наземно-бортовой системы ЭКАР, является применение технологии совместной разработки бортовой и наземной частей системы. Основой технологии стало использование совместимых платформ (процессор + ОС) бортовой и наземной частей комплекса и совместная разработка, отладка и сопровождение бортового и наземного программного обеспечения. Технология предполагает:
Применение перечисленных принципов позволило создать наземно-бортовую систему контроля и регистрации полётной информации нового поколения КАРАТ, реализующую:
На рис. 7 представлена история развития систем КАРАТ. В 90-х годах была создана наземная система АСОИ-64 для обработки информации с кассетного бортового накопителя самолётов Ил-62М. Система была реализована на персональном IBM PC/AT совместимом компьютере с ОС Microsoft DOS.
Опыт создания наземных систем обработки полётной информации позволил перейти к разработке наземно-бортового комплекса контроля и регистрации полётной информации. Работы начались в феврале 1996 года. К концу года был готов макетный образец комплекса, а в августе 1997 года МиГ-21-93, оснащённый КАРАТ-21, совершил первый полёт. Успех проекта – создание в сжатые сроки при ограниченном финансировании комплекса с расширенными функциональными возможностями – во многом определялся выбором архитектуры бортовых блоков комплекса. Вычислители бортовых блоков были реализованы на процессорах типа РС/104 с ОС DOS, а наземная часть комплекса на IBM PC/AT совместимом компьютере с ОС Microsoft DOS. ОС бортовых блоков была доработана для обеспечения режима реального времени. Такой выбор позволил проводить разработку и отладку ПО бортовых блоков на настольных компьютерах, максимально использовать опыт работы специалистов и обеспечить полный контроль параметрической информации бортовыми и наземными процессорами от момента приёма до анализа результатов. Работа над проектом продолжалась 5 лет, а после сдачи самолёта заказчику разработчики осуществляют сопровождение своей системы.
За пять лет работы над проектом большим коллективом специалистов была создана и реализована уникальная технология совместной разработки, отладки и сопровождения бортового и наземного ПО. Эта технология основана на опыте объединённой команды разработчиков из ФГУП «ГосНИИАС» (Москва), ОЗ «Прибор» (Санкт-Петербург), ОКБ «Авиаавтоматика» (Курск), МАПО МиГ (Москва), НАЗ «Сокол» (Нижний Новгород).
Ключевым условием для реализации технологии совместной разработки, отладки и сопровождения бортового и наземного ПО является правильный выбор ОС для бортовых и наземных компьютеров.
Для нового проекта (КАРАТ-25 для самолёта Су-25СМ/УБМ) было принято решение создать защищённый бортовой накопитель с расширенной памятью (256 Мбайт против 10 Мбайт), и встал вопрос о замене ОС. Замена ОС DOS была вызвана следующими причинами:
Если в первом проекте у нас не было времени для дискуссий по поводу выбора программно-аппаратной реализации комплекса КАРАТ и мы действовали интуитивно, то в новом проекте этому было уделено много внимания. Обсуждались два варианта аппаратной реализации. Это
В таблицах 1 и 2 приведены сравнительные характеристики этих вариантов.
Была выбрана универсальная РС-технология. Следующим шагом было определение конкретной ОС для применения в новом защищённом бортовом накопителе. Общие требования к ОС были следующие:
В наземной системе предполагалось использовать широко распространённую в то время ОС Microsoft Windows 98, которая в то время инсталлировалась на компьютер поверх DOS. Доработка функционального ПО в этом случае была незначительной.
К характеристикам ОС бортовой системы предъявлялись следующие требования:
Первоначально рассматривалось несколько десятков ОС. Для детального тестирования были выбраны три 32-разрядные ОС с известным и хорошо документированным интерфейсом с прикладным ПО: Microsoft Windows NT Embedded 4.0, Microsoft Windows CE 2.0 и On Time RTOS-32. Сравнительные характеристики этих ОС приведены в таблице 3.
По результатам тестирования была выбрана ОС On Time RTOS-32. В 2000 году мы купили лицензию и начали работать на RTOS-32 версии 3.06. Отдельно было приобретено ПО фирмы EBS, обеспечивающее обмен информацией по протоколу TCP/IP и совместимое с выбранной ОС.
Использование ОС On Time RTOS-32 позволило:
В следующем проекте – в четырёхблочной системе КАРАТ-29К для самолётов МиГ-29К индийских ВМС – OC On Time RTOS-32 была загружена во все блоки системы. Для межблочного обмена в системе была реализована бортовая сеть Ethernet, к которой подключается компьютер наземной системы.
К настоящему времени коллектив из 11 человек разработал и сопровождает ПО 6 проектов. Кроме перечисленных, это ещё четырёхблочный КАРАТ-29К серии 2 для сирийских самолётов
МиГ-29К, четырёхблочный КАРАТ-29К серии 1 для российских самолётов МиГ-29К, защищённый бортовой накопитель для корвета «Стерегущий», защищённый бортовой накопитель для самолётов Ту-204/214. Во всех этих проектах для бортовых блоков использовалась OC On Time RTOS-32. При сопровождении проекта периодически решаются следующие задачи:
За 14 лет работы с ОС On Time RTOS-32 мы использовали версии 3.06, 4.19, 5.14, 5.21 и 5.26.
Технология разработки систем ЭКАР предполагает комплексную адаптацию приложения, драйверов и ОС к смене программно-аппаратной реализации системы. В случае необходимости мы корректируем код ОС. Благодаря наличию хороших заготовок в коде ОС On Time RTOS-32 нами были реализованы следующие функции:
Технология замены версий ПО бортовых блоков с наземной системы КАРАТ-Н реализована следующим образом:
Навык ручной корректировки rtb-файлов и освоение технологии подмены rtb-файлов позволили нам реализовать динамическую загрузку исследовательского ПО в бортовые блоки.
Для реализации динамической загрузки ПО в бортовые блоки решены следующие задачи:
Для реализации динамической загрузки создаётся ПО виртуального облака (виртуальной машины, перенесённой по сети Ethernet). В бортовом блоке реализуется обмен данными старого и нового процесса.
Технология обмена данными между старым и новым процессами базируется на технологии создания виртуального диска, которая позволяет переносить все данные от старого процесса к новому. Виртуальный диск – это область памяти ОЗУ, создаваемая программными средствами для перенесения на него ПО и данных, в конкретном случае – нового процесса. Виртуальный диск создаётся в бортовом блоке.
Запуск нового ПО состоит из двух основных этапов:
Режим инициализации определяет создание виртуального диска в ОЗУ бортового блока и перенос на него данных для запуска нового процесса. Обмен производится по протоколу UDP. На виртуальный диск передаётся размер ПО и запрос о возможности его принятия. Если ответ на запрос положительный, то запускается следующий режим, если отрицательный, то пользователю выводится код ошибки.
Режим поблочной загрузки – это режим, при котором загрузка производится по 1 кбайт данных. В последнем килобайте данных находится служебная информация, которая включает, в том числе,контрольную сумму, флаги криптозащиты, проверку на наличие пользовательской лицензии.
Для проверки целостности программы используется 16-разрядный алгоритм расчёта контрольной суммы
CRC-16 (cyclic redundancy code). Алгоритм CRC базируется на свойствах деления с остатком двоичных многочленов. Если проверка прошла успешно, то программа переходит к проверке криптозащиты. В случае несовпадения контрольной суммы пользователю выводится код ошибки.
Криптозащита в программе производится по паролю (каждый байт данных защищён паролем). Если проверка криптозащиты прошла успешно, то программа переходит к проверке прав пользователя. Если проверка прав пользователя не прошла успешно, то выдаётся код ошибки.
Если все этапы проверки прошли успешно, то управление передаётся новому процессу, который использует данные старого. При передаче управления должны быть определены конфигурационные данные системы КАРАТ (градуировка, описатель параметров и системная информация). Конфигурационные данные могут быть наследованы из старого процесса или перекрыты конфигурационными данными нового.
Загруженное таким образом исследовательское ПО работает до выключения или перезагрузки бортовой системы регистрации и контроля. После выключения/перезагрузки все динамически загруженные данные стираются и виртуальный диск исчезает из ОЗУ.
Четырнадцатилетний опыт использования ОС On Time RTOS-32 подтвердил правильность выбора разработчиков. Всё это время ОС On Time RTOS-32 динамично развивалась в русле основных тенденций информационных технологий. Применение ОС On Time RTOS-32 позволяет обеспечивать длительный ЖЦ наземно-бортовых систем ЭКАР.
Предоставляемый код даёт возможность модернизировать реализованные в ОС функциональные задачи с учётом требований разрабатываемых систем.
Разработчики КАРАТ собираются создавать новые проекты с использованием ОС On Time RTOS-32. ●
E-mail: leopreo@gmail.com
Однофазные источники бесперебойного питания Systeme Electric
Почти все современные сферы промышленности, IT-инфраструктура, а также любые ответственные задачи и проекты предъявляют повышенные требования к питающей сети – электропитание должно быть надёжным, стабилизированным и обеспечивать бесперебойную работу. В данной статье мы рассмотрим решения по однофазному бесперебойному питанию от российской компании Systeme Electric. 28.12.2023 СТА №1/2024 874 0 0Однопроводный канал телеметрии по PLC
В статье рассматриваются методы реализации однопроводных каналов передачи данных по силовым электросетям в жилых зданиях, загородных и промышленных помещениях. В качестве информационного провода предлагается использовать проводник «нейтраль» электропроводки. Приводятся анализ возможных конфигураций каналов передачи данных этого типа и результаты экспериментальных проверок. Рассматриваются преимущества новых методов по сравнению с традиционными PLC и области возможного применения данной технологии. 28.12.2023 СТА №1/2024 922 0 0BioSmart Quasar 7 — мал да удал
Компания BIOSMART в пандемийном 2020 году весьма своевременно представила свой первый лицевой терминал Quasar (рис. 1) с диагональю экрана 10 дюймов. Уже в следующем, 2021 году был представлен бесконтактный сканер рисунка вен ладони PALMJET (рис. 2). Ну а в текущем 2023 году компания представила новую уменьшенную модель лицевого терминала Quasar 7 (рис. 3), который смог в компактном корпусе объединить обе передовые технологии бесконтактной биометрической идентификации. 28.12.2023 СТА №1/2024 891 0 0Открытые сетевые платформы — когда сети и вычисления в одном устройстве
Открытая сетевая платформа (ONP) – это мощное средство для реализации как простых, так и масштабных сетей, а также инструмент, который позволяет в одном высокопроизводительном устройстве реализовать целый вычислительный комплекс, объединяющий внутри себя коммутаторы, маршрутизаторы, межсетевые экраны, а также сам сервер обработки данных. Используя все преимущества данной архитектуры, компания AAEON разработала своё решение, сетевую платформу FWS-8600, на базе высокопроизводительных процессоров Intel Xeon Scalable 2-го поколения. В статье раскрыты детали и особенности ONP, характеристики FWS-8600, а также почему использование процессоров Intel Xeon Scalable 2-го поколения значительно увеличивает потенциал платформы. 28.12.2023 СТА №1/2024 846 0 0