Всем привет!

За время работы в отрасли авиастроения у меня и коллег накопился большой опыт по разработке и созданию стендов полунатурного моделирования бортового оборудования самолётов (Hardware-In-the-Loop, HIL) и стендов быстрого прототипирования (Model-In-the-Loop, MIL). Данная публикация — это попытка свести наш опыт в одну публикацию. Получившийся текст оказался довольно подробным, но вырезать что-то рука не поднимается. К тому же при сокращении местами может пропасть причинно-следственная связь. Итак, здесь будет рассказываться:

• О применяемых инструментах автоматизации разработки стенда и его сопровождения;
• О программном обеспечении и аппаратуре имитационного комплекса;
• О подходах к построению стенда HIL и MIL стендов;
• О различных приемах, ускоряющих создание стенда и упрощающих его модернизацию и эксплуатацию.

Кому интересно — добро пожаловать под кат.

Предыстория вопроса

Мы — группа инженеров с большим опытом работы в гражданской авиастроительной отрасли.

У нас за плечами работа над созданием бортового оборудования, стендов, тренажеров для самолетов SSJ-100 Sukhoi Superjet, MC-21, ДА-42Т, Л-410УВП-Е20.

С самого первого стенда мы столкнулись с отсутствием методичек для тех, кто собирается построить испытательный стенд с десятками тысяч проводов, сотнями тысяч сигналов и постоянно меняющейся структурой. По причине той старой тоски по знаниям мы с коллегами и решили поделиться наработками — вдруг кто-то прямо сейчас идёт по нашим любимым граблям?

По нашим сегодняшним представлениям у любого стенда есть следующие особенности:

1. Стенды состоят из оборудования — объекта испытаний, кабельной сети, имитационного комплекса, программного обеспечения имитационного комплекса;
2. Опционально на стенде могут появляться такие устройства как макет кабины экипажа, система визуализации, системы загрузки органов управления и т.д.;
3. Объект испытаний постоянно меняется по мере развития продукта;
4. Требования к проводимым испытаниям постоянно меняются;
5. ТЗ на стенд содержит не все требования, бОльшую часть функционала придётся доделывать на ходу;
6. Для того, чтобы стенд действительно был полезен, он должен меняться быстрее, чем объект испытаний.

Столкновение с изменчивой сутью стнедов испытаний привело нас к пониманию, что:

1. Все «железные» части стенда (кабельная сеть, макет кабины экипажа и т.д.) должны быть легко дорабатываемыми;
2. Архитектура имитационного комплекса, структура моделей и имитаторов также должна быть легко модифицируемой и управляемой;
3. Без инструментов и среды разработки не обойтись;

Поэтому наше изложение мы начнём с описания инструментов разработки и архитектуры имитационного комплекса.

Часть 1. Инструменты разработки

В этом разделе мы опишем два из трёх основных инструментов: ПО dBricks и программную среду имитационного комплекса ADS2R4. Третий элемент цепочки инструментов — Simulink в представлении и описании, пожалуй, не нуждается. Также важно упомянуть, что эти три продукта при правильном подходе можно тесно друг с другом интегрировать и упростить большинство процессов разработки стендов.

1. dBricks – российский программный инструмент разработчика комплекса БРЭО, разработки ООО «ПИРСС»
2. ADS2R4 – среда имитационного комплекса, разработки компании TechSAT

dBricks применяется для:

1. Разработки протоколов информационного взаимодействия бортового оборудования — объекта испытаний;
2. Автоматизированного формирования архитектуры математических моделей;
3. Разработки конструкторской документации на кабельную сеть стенда;
4. Автоматизированной генерации конфигурационных файлов описания входов выходов в формате среды имитационного комплекса ADS2R4.

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

Про инструмент dBricks 

dBricks – это основной инструмент, который применяется для ускорения разработки и комплексирования сложного бортового оборудования. Инструмент представляет собой базу данных для обработки следующих проектных данных:

1. Протоколы информационного взаимодействия;
2. Структурные и принципиальные схемы;
3. Схемы и таблицы подключений;
4. Сборочные чертежи и таблицы жгутов;
5. Спецификации требований для разработчиков ПО.

Применение инструмента предоставляет следующие преимущества:

1. Единый инструмент для работы данными гарантирует совместимость всех результатов работы;
2. Многопользовательский интерфейс позволяет одновременно работать большой распределенной команде разработчиков;
3. Встроенный контроль подключений и конфигураций ПО;
4. Автоматизированный вывод данных в виде различных отчетов, таблиц, схем, документов и файлов в человеко-читаемом формате;
5. Автоматизированный вывод данных в машинно-читаемом формате в том числе для конфигурации системы ADS2, сетевого оборудования;
6. Взаимодействия с прочими CAD системами при необходимости.

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

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

Применение dBricks гарантирует разработчикам стендов:

1. Быстрое автоматизированное формирование конфигурационных файлов ADS2, в которых 100% не будут содержаться ошибки ручного копирования («человеческий фактор»);
2. Кабельная сеть стенда может быть разработана на основании данных о бортовой кабельной сети объекта (например, воздушного судна) хранящихся в dBricks.

Детали архитектуры инструмента dBricks

Про подключение оборудования в dBricks на физическом уровне 

Описание каждого устройства в dBricks включает коллекцию аппаратных портов.

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

1. Название;
2. Тип подключаемой шины, например, ARINC 429 или питание 27В;
3. Направление: выход, вход, дуплекс;
4. Привязка проводов порта к контактам соединителей (распиновка).

Рис. 1: Модель данных проводки

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

Рис. 2: Подключение портов и распределения контактов

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

1. Оперативно разработать конструкторскую документацию на изготовление кабельной сети;
2. Разрабатывать документацию на доработку кабельной сети.

Вторая функция, пожалуй, даже важнее первой т.к. по опыту в проекте летательного аппарата только до получения сертификата бывает два-три десятка «больших» итераций конфигурации кабельной сети.

Про модель информационного обмена dBricks

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

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

Функции могут содержать коллекцию параметров функций. Каждый параметр функции в первом приближении обладает следующими свойствами:

1. Название;
2. Направление – входной, выходной;
3. Единица измерения – определяет то, в каких единицах измеряется величина, передаваемого параметра, например, метры;
4. Тип данных – способ кодирования параметра, например, целое число, число с плавающей точкой и т.д.;

Наполнение порта – это описание способа передачи данных между устройствами посредством информационных портов. Структура наполнения существенно зависит от типа шины, используемого для передачи. Между тем, есть несколько свойств, общих для всех стандартов передачи данных (типов шин):

1. В инструменте dBricks хранятся наполнения передающих портов, как выходных в однонаправленных шинах, так и передающих в двунаправленных шинах;
2. Передаваемыми данными являются информационные выходы функций устройств, т.е. выходные параметры функций;
3. Данные передаются посредством структур данных, называемых контейнерами данных. В отличие от параметров функций, обладающих лишь свойствами единицы измерения и типа данных, контейнеры могут иметь описание, характерное для используемого стандарта передачи данных. К характерным свойствам контейнеров могут, например, относиться: адрес, точность, частота передачи и т.д;

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

4. Все контейнеры, используемые в информационном наполнении, ссылаются на параметры функций, которые должны передавать;
5. Определение потока данных осуществляется путем привязки параметров приёмника (входа) к параметрам источника (выхода). Каждое подключение содержит данные об используемой шине (физический слой) и используемом контейнере (транспортный слой).

Рис. 3: Обмен данными

Про имитационный комплекс на базе ADS2

ADS2 это комплексная, легко адаптируемая программная среда и аппаратная платформа реального времени для прототипирования, интеграции, тестирования, валидации и верификации бортового оборудования в аэрокосмической отрасли, разработанная компанией TechSAT.

Принципиальное устройство системы ADS2 включает в себя следующие компоненты: 

1. Аппаратная часть, которая включает в себя специализированные АРМ (на базе Windows или Linux), платы ввода-вывода, устройства коммутации линий связи (включая управление подключением ОИ) и т.д. 
2. Программная среда ADS2 Core – распределенная система реального времени, которая объединяет все компоненты ADS2.
3. Присущее системе низкоуровневое ПО поддержки аппаратуры, например, драйверы устройств, работающие на ядре ADS2.
4. Модуль графической оболочки ADS2 – сервис, который позволяет оператору в режиме реального времени управлять системой ADS2.

То есть минимальный обязательный состав системы ADS2 включает в себя программное ядро ADS2 (компьютер реального времени и АРМ управления), произвольный набор стандартных компонентов (таких как платы ввода-вывода и соответствующие драйверы к ним) и дополнительные модули и системы расширения необходимые заказчику. 

Про аппаратуру ADS2

Типовой состав системы ADS2 состоит из следующих основных компонентов:  

1. Одно или более АРМ системы ADS2 (на базе Windows или Linux). Данные АРМ выполняют функцию управления и конфигурирования системы ADS2, контроля данных, выполнения тестов, а также разработки и отладки пользовательских программ системы ADS2. 
2. Одна или более ПЭВМ под управлением операционной системы реального времени, позволяющая одновременное выполнение задач системы реального времени и большого количества задач по приему-передаче данных. Они состоят из: 
   • ПЭВМ реального времени (ядро ADS2) 
   • Дополнительных опциональных ПЭВМ реального времени для пользовательского моделирования 
   • Платы ввода-вывода для высокоскоростных линий связи оборудования БРЭО, таких как AFDX, CAN, ARINC 429, MIL-STD-1553 (МКИО), RS-485, Ethernet и т.д.

3. Одна или несколько программно-коммутируемых плат ввода-вывода (FAST) для обеспечения взаимодействия посредством аналоговых сигналов, разовых команд и цифровых линий связи с управлением по Ethernet (TCP/UDP).
4. Опциональная система точного времени «Timemaster» для обеспечения синхронизации нескольких систем ADS2.

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

Детали архитектуры среды ADS2R4

Про структуру программного обеспечения ADS2

На схеме показаны основные компоненты программного пакета системы ADS2.

Рис. 4: Архитектура ПО ADS2

Главные компоненты: 

1. ADS2 RT Core – компьютер реального времени, программное ядро ADS2. Ядро ADS2 содержит специальную «базу данных» текущих параметров (Current Values Table, CVT) реального времени и конфигурационную базу данных. Ядро ADS2 также отвечает за управление и мониторинг всех вычислительных задач, выполняемых под управлением ADS2 и подключение внешних приложений.
2. Драйверы ввода-вывода ADS2 – доступ к устройствам ввода-вывода обеспечивается через специализированные приложения, которые управляются по расписанию ядром ADS2. Для большинства наиболее популярных интерфейсов ввода-вывода драйверы уже разработаны и доступны вместе с системой ADS2.
3. ADS2 GUI Tools Suite – набор модулей графической оболочки ADS2, который позволяет оператору в режиме реального времени конфигурировать, управлять, визуализировать данные, собирать данные и имитировать данные клиентов системы ADS2. Под клиентами в данном случае понимаются: имитационный комплекс, коммутация линий, управление объектом испытаний и т.д.
4. ADS2 API – общий интерфейс API для внешних приложений и имитаторов, который также используется системой ADS2 для собственных целей и для управления драйверами плат ввода-вывода.

Как организован обмен данными посредством CVT в среде реального времени

CVT – таблица текущих значений, она определяет отдельные фрагменты данных, используемых различными частями системы, которыми в свою очередь обмениваются все приложения разного типа (пользовательские или внутренние приложения  ADS2). Точки CVT — это наборы переменных, где каждая отдельная переменная имеет определенный набор атрибутов, которые характеризуют переменную и отражают ее предполагаемое использование. CVT и точки CVT — единственные средства, с помощью которых приложения могут обмениваться данными между собой. Точки CVT имеют сквозные названия для всей системы, таким образом, каждая точка имеет одно определение в данный момент времени. Каждая точка имеет следующие атрибуты:

1. Тип данных – integer, floating point, string, массив данных;
2. Тип доступа к данным – sampling или queuing (FIFO);
3. Атрибуты данных – значение по умолчанию, минимальное и максимальное значение, единица измерения, формат, описание и соответствие между типом данных integer и strings.

Помимо имени, присвоенного точке CVT, она также может иметь дополнительные псевдонимы, по которым на нее можно ссылаться. Отдельные точки CVT могут быть связаны друг с другом таким образом, так точка A может быть объявлена источником точки B. Эта связь определяет путь данных между этими двумя точками, таким образом, всякий раз, когда что-либо записывается в точке A, точка B обновляется соответственно. В этом случае типы данных A и B не обязательно должны быть одинаковыми; выполняется неявное преобразование данных (что, однако, может привести к потере точности). В приложениях, принимаемые и передаваемые ими данные определяются с помощью точек CVT, то есть набора точек (соответственно имен точек) входов и набора точек выходов. Так получается типовая приёмо-передающая модель интерфейсов приложений. 

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

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

Рис. 5: Обмен данными через CVT

Про организацию информационного обмена плат ввода-вывода и их конфигурацию

Архитектура системы ADS2 позволяет развязать между собой приложения (в т.ч. модели) и аппаратуру ввода-вывода (I/O channels). То есть приложения никогда не взаимодействуют непосредственно с физическим интерфейсом платы. Приложения общаются только с точками CVT. Взаимодействие точек CVT с физическими входными-выходными параметрами происходит автоматически под управлением ADS2. Настройка взаимодействия осуществляется с помощью конфигурационных таблиц (I/O map configuration). ADS2 поддерживает следующие виды плат ввода/вывода:

1. ARINC 429, AFDX, CAN, MIL-STD-1553 (МКИО), и т.д. ;
2. Последовательные протоколы RS-232, RS-485, RS-422 и т.д.;
3. Входные и выходные разовые команды;
4. Аналоговые входы и выходы;
5. Любые устройства измерения с поддержкой Ethernet.

Драйверы ввода-вывода выполняют две основные операции в процессе обработки определений отображения:

1. Преобразование технических единиц (например, перевод значений 16-битного регистра из аналого-цифрового преобразователя в логическую единицу: напряжение в температуру в градусах Цельсия);
2. Декомпозиция и формирование сообщений (например, указание местоположения параметров в сообщении шины и непосредственное извлечение значения в точку CVT или запись значения, полученного из точки CVT, в это место в сообщении).

Рис. 6: Доступ к оборудованию через схему ввода-вывода (таблица конфигурации)

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

1. AFDX (ARINC 664);
2. ARINC 429;
3. CAN (ARINC 825);
4. MIL-STD-1553 (МКИО);
5. Аналоговые сигналы;
6. Разовые команды;
7. Последовательные протоколы (RS232, RS422, RS485);
8. RVDT/LVDT;
9. СКВТ;
10. Некоторое количество нестандартных устройств, изготовленных по отдельным требованиям.

Как применяется dBricks для конфигурации ADS2

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

1. Перечень точек CVT;
2. Связи точек CVT;
3. Конфигурационная таблица входов-выходов.

Перечень точек CVT формируется на основе соответствующих параметров функции оборудования в dBricks. 

Точки CVT генерируются для всех входных и выходных параметров функции. 

Пример: Функция «Flight Warning Application» блока «СС1» имеет три входных параметра и один выходной параметр:

• In_IRU1_Roll (данные крена от инерциальной навигационной системы №1)
• In_IRU2_Roll (данные крена от инерциальной навигационной системы №2)
• In_IRU3_Roll (данные крена от инерциальной навигационной системы №3)
• Out_Excessive_Roll_Warning (выходной сигнал опасного превышения угла крена)

Рис. 7: Пример конфигурации CVT

Связи точек CVT формируются на основе связей между параметрами функций в dBricks. Например, входной параметр «In_IRU1_Roll» приложения «Flight Warning Application» связан с выходным параметром «Out_Roll_Angle» функции «Main» блока «IRU1»:

Рис. 8: Связи точек CVT

Конфигурационные таблицы ввода/вывода генерируются на основании «наполнения портов» в dBricks. Например, параметр Out_Roll_Angle передаётся посредством шины ARINC429 в слове 325, типа BNR (фиксированная точка), с младшим разрядом контейнера 11, размером контейнера 14, ценой старшего разряда 90, со знаком, время обновления 10мс. Такого описания достаточно для формирования файла конфигурации входов-выходов.

Рис. 9: Пример подключения объекта испытаний

Таким образом, на основании данных в dBricks пользователь может сформировать набор настроечных файлов, необходимых для создания конфигурации ADS2, которая будет состоять из сотен моделей и каналов входов-выходов, менее чем за 1 час.

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

Как применяется Simulink в ADS2

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

Детали интеграции Simulink и ADS2

Широкое совместное применение Simulink и ADS2 возможно на основании следующих фактов:

1. Вся общая память ADS2 со всеми точками CVT доступна во всех узлах системы ADS2, включая ПЭВМ под управлением Windows;
2. Любая точка CVT доступна с любого устройства системы ADS2;
3. В системе ADS2 доступен интерфейс API для C++;
4. Simulink позволяет подключить внешний код C++ как отдельный блок (S-функцию);
5. Блок S-функции позволяет изменить состояние своего входного-выходного параметра по внешней команде;
6. Код S-функции может быть автоматически заменен другим кодом при использовании генератора кода Simulink.

Данная возможность необходима, поскольку код C++, который работает в среде Windows, не будет работать в системе реального времени в среде Linux. Таким образом, код в среде Windows должен быть заменен на код в среде Linux, если требуется генерация кода математической модели в среде реального времени.

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

1. Открываем пустую модель Simulink;
2. Вставляем две (одну для входа и одну для выхода) S-функции в пустую модель Simulink;
3. Конфигурируем входные-выходные параметры S-функции с помощью специального скрипта. Скрипт использует конфигурационные файлы ADS2 как источник перечня параметров для добавления в блок S-функции;
4. Создаём модель системы в Simulink. Параметры, которые обмениваются данными с другими моделями, должны быть подключены к блокам S-функции;
5. Проводим тест нашей модели с подключенной средой ADS2 прямо в среде разработки Simulink;
6. Завершение разработки модели;
7. Генерация кода на C++ с применением генератора кода в Simulink;
8. Компиляция C++ кода в среде реального времени Linux;
9. Сохранение финальной модели реального времени в соответствующий репозиторий для дальнейшего использования.

Пример. Допустим, что мы разрабатываем систему воздушных сигналов (СВС) и хотим провести испытания в замкнутом контуре совместно с реальным индикатором (объект испытаний) и моделью воздушного судна реального времени. Модель СВС получает данные о воздушной скорости из модели воздушного судна, производит с ними действия (конвертирует единицы измерения, вносит задержки, ошибки и т.д.) и передаёт их далее на индикатор. Для проведения испытания мы запускаем среду ADS2 с моделью воздушного судна реального времени и включаем реальный индикатор. Переводим ручку управления двигателем на максимум, воздушное судно начинает набирать скорость. Модель Simulink подключена к ADS2, поэтому одновременно с увеличением модельной скорости входной параметр воздушной скорости также начинает увеличиваться. Выходной параметр воздушной скорости из модели Simulink выдаётся в ADS2, затем конвертируется в ARINC 429 и доставляется в реальный индикатор. Таким образом, мы можем наблюдать рост индицируемой воздушной скорости, передаваемой моделью СВС, на реальном оборудовании (ОИ). Это означает, что мы имеем возможность создавать и испытывать модели, используя инструмент Simulink в среде ADS2. Конечно, Simulink работающий в среде Windows, не обеспечивает функционал реального времени, но для разработки и отладки модели этого, как правило, и не требуется.

Рис. 10 Пример подключения модели Simulink к ADS2

Часть 2. Стенды

Стенд полунатурного моделирования комплекса бортового оборудования (HIL Testing)

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

1. Поддержка разработки БРЭО;
2. Проведение комплексных испытаний бортового оборудования, включая испытания в замкнутом контуре с пилотом, взаимодействие с имитаторами бортового оборудования, имитация динамики полета летательного аппарата и внешних условий;
3. Проведение первоначальной оценки работы бортового оборудования летным составом;
4. Сертификационные испытания, включая испытания на устойчивость БРЭО к возможным отказам; работа в режимах взлет и посадка в условиях минимальной видимости, отработка режимов приближения к земле и т.д.;
5. Отработка эксплуатационной документации;
6. Тренировка линейных пилотов на техническом средстве обучения, соответствующем, скажем FTD level 4.

Какой имитационный комплекс применять

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

1. Однородная аппаратная и программная среда, которая легко масштабируется под изменяющиеся в ходе разработки требования;
2. Проверенный функционал реального времени;
3. Простота разработки компьютерных моделей комплектующих изделий в среде Simulink в замкнутом контуре;
4. Удобный способ подключения к оборудованию стенда. Все АРМ системы объединяются в общую сеть и имеют возможность доступа к объектам испытаний;
5. Мощные возможности графической оболочки оператора;
6. Встроенный функционал регистрации данных и их последующей обработки;
7. Возможность проведения формального тестирования на базе скриптов.

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

Одна из наиболее трудоемких задач при разработке стенда БРЭО это конфигурация моделей систем и плат ввода-вывода. С помощью dBricks эта задача решается в течение часа. Единственное, что необходимо будет сделать — это назначить, какая из плат ввода-вывода системы ADS2 будет отвечать за какой канал имитируемого оборудования. После все необходимые конфигурационные файлы могут быть сформированы автоматически.

Про интеграцию сторонних имитаторов

Некоторые поставщики систем обеспокоены своим ноу-хау и отказываются предоставлять данные, необходимые для создания моделей их систем. Хороший пример — двигателисты. Обычно поставщики двигателей предоставляют свои имитаторы для обеспечения работы стенда. Эти имитаторы, как правило, подключаются к центральной системе моделирования стенда через Ethernet или в худшем случае через некоторые специальные интерфейсы, такие как «Reflective Memory». В любом случае ADS2 может поддержать любой интерфейс. 

При проектировании стенда следует обратить внимание на то, какая именно послепродажная поддержка покрывается контрактом на поставку имитаторов. Поскольку разработчик стенда не может дорабатывать или ремонтировать эти имитаторы, то необходимо заручиться долгосрочным (10-15 лет) послепродажным обслуживанием и поддержкой поставляемых моделей (включая модернизацию, доработки и т.д.). Эта поддержка должна также учитывать такие проблемы, как стоимость запасных частей, стоимость и сроки ремонта, управление устареванием использованного оборудования, возможность обеспечить удаленную техническую поддержку, выезд полевого представителя, наличие системы обращений заказчика и т.д..

Как разработать кабельную сеть стенда полунатурного моделирования

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

• Кабельная сеть стенда не предполагается для использования в полете, таким образом, не требуется 100% соответствие конструкции проводки стенда и КД на проводку воздушного судна. Более того, применение кабельной сети воздушного судна может значительно увеличить сроки разработки стенда, поскольку:
  — Проводка летательного аппарата и документация на неё появляются слишком поздно и остаётся совсем мало времени для проведения результативных испытаний;
  — Кабельная сеть воздушного судна очень сложна для внесения изменений и сопровождения в ходе эксплуатации на стенде;
• Устройства разрыва цепи (разрывные коробки) должны применяться на стенде для каждой шины. У этого решения есть свои преимущества:
  — Топология всех жгутов сводится к примитивной;
  — Каждая шина может быть проверена или изменена пользователем стенда с применением простейшего инструмента в течение 5 минут;
  — В общей сложности структура проводки стенда становится легко дорабатываемой и простой в обслуживании.

Рис. 11: Жгут стенда в сборе

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

Мы советуем применять в качестве разрывных коробок простейшие широко распространённые клеммные колодки WAGO 2002-1871 (или аналогичные с возможностью разрыва линии) с возможностью монтажа на DIN рейку.

Рис. 12: РК на базе клеммных колодок WAGO

Решение на базе клеммных колодок позволяет просто размножать соединения если объединить несколько  клеммных колодок WAGO в группу как показано ниже:

Рис. 13.а: Пример конфигурации РК с применением колодок WAGO

Рис. 13.б: Пример конфигурации РК с применением колодок WAGO

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

Рис. 14: Пример подключения имитационного комплекса к двум типам разрывных коробок

• Разработка и сопровождение КД на КС стенда может быть выполнена в специальном программном модуле инструмента dBricks. Функционал модуля включает следующие функции:
  — Простой интерфейс для конфигурации структуры стенда, расположения оборудования в стеллажах, расстояние между местами установки оборудования и т.п.;
  — Возможность использовать данные, которые были внесены в dBricks в ходе разработки протоколов информационного взаимодействия, что на 100% предотвращает появление ошибок при ручном переносе («человеческий фактор»);
  — Автоматизированную генерацию документации на кабельную сеть стенда.

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

Как создать макет кабины экипажа

Макет кабины экипажа, как правило, должен:

1. Обеспечить место для установки оборудования объекта испытаний, штатно располагаемого в кабине экипажа;
2. Обеспечить удобный (по возможности) доступ к объекту испытаний, проводке этого оборудования, механизмам и т.п.;
3. Повторять компоновку кабины экипажа;
4. Повторять обзор окружающего пространства из кабины экипажа.

Компоновка кабины экипажа подвергается частым изменениям, особенно до момента совершения первого вылета воздушного судна, поэтому мы начинаем разработку БРЭО с макета кабины экипажа и затем переходим к финальному решению.

Первоначальный макет кабины экипажа

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

Рис. 15: Первоначальный макет кабины экипажа

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

1. Установка некоторых систем визуализации требуют свободного места под полом кабины. Для применения цилиндрической системы визуализации обычно требуется поднять макет кабины на высоту 1.2-1.5 метра. Коллиматорная, сферическая проекционная или система визуализации на базе простых мониторов не требует этого.
2. В случае применения педальных постов или других механических органов управления как же требуется некоторое пространство под полом кабины. В этом случае макет кабины так же требуется устанавливать на высоте около 50 сантиметров от уровня пола.

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

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

Окончательный макет кабины должен соответствовать размерам реальной кабины экипажа для соответствия сертификационным требованиям. В зависимости от состава проверок и подхода властей может возникнуть необходимость в создании дополнительного «окончательного» макета кабины экипажа, воспроизводящего реальную кабину. Для этой задачи рекомендуется применение реальных частей фюзеляжа с реальными местами установки оборудования, креслами пилотов и т.д. Например, для стенда «Электронная птица» программы SSJ-100 был применен образец реальной кабины экипажа, первоначально использовавшийся для отладки сборочной линии. Его невозможно было применить в реальном самолете, поскольку он не отвечал формальным требованиям производства, но полностью подходил для задач испытательного стенда.

Рис. 16: Макет кабины экипажа SSJ-100 на стенде «Электронная птица»

Какую систему имитации внешней визуальной обстановки использовать

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

1. Применение стенда в качестве тренажёра (например, уровня FTD level 4),
2. Некоторые сертификационные испытания.

CFR 60 Table B1A section 6.a определяет: «The FTD may have a visual system, if desired, although it is not required. If a visual system is installed, it must meet the following criteria…». Таким образом, нет никакой необходимости в применении системы имитации внешней визуальной обстановки для FTD Level 4. Даже если в качестве системы визуализации будет установлен простой монитор, то он будет соответствовать требованиям, изложенным в разделах 6.a.1-6.a.7 CFR 60. 

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

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

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

1. Поле с обзором 120×60 градусов.
2. Умеренную первоначальную стоимость системы и стоимость её эксплуатации.

Как размещать объекты испытаний на стенде

Мы предлагаем применять коммерчески доступные телекоммуникационные стойки (серверные стойки) для размещения оборудования, которое штатно располагается вне кабины экипажа. Единственная сложность может быть вызвана необходимостью размещения оборудования, требующего принудительного охлаждения. Эта проблема может быть решена несколькими путями:

1. Разработкой специальной системы охлаждения, которая представляет собой вентилятор высокого давления со звукопоглотителем и воздуховодами;
2. Установкой простых вентиляторов низкого давления в специальных рамах под охлаждаемым устройством. Однако вентиляторы низкого давления не всегда обеспечивают нужную производительность;
3. Установкой вентиляторов высокого давления в специальных рамах под охлаждаемым устройством. Такое решение имеет высокую производительность, но производит много шума;
4. Установкой специальной двери со встроенным кондиционером на телекоммуникационную стойку, например, Rittal SK.

Как создать систему распределения энергии

Система распределения энергии предназначена для распределения электропитания ОИ. Она копирует систему СЭС установленную на летательном аппарате.

Преобразование 115В переменного тока в 28В постоянного и 115В 400 Гц не представляет сложности, поскольку на рынке доступно большое количество готовых решений. Поэтому это не является предметом данного описания.

Мы применяем следующий подход:

1. Первоначально используется специальный макет системы распределения;
2. Перед началом сертификационных испытаний макет заменяется на реальную систему распределения.

Первоначальный макет СЭС выполняется с использованием коммерчески доступных элементов, таких как зажимы WAGO, реле, предохранители и т.д. Все эти устройства монтируются на DIN рейку или аналогичные легкодоступные поверхности. Схемы для всех подключений должны повторять «настоящую» СЭС летательного аппарата. Твердотельные распределительные устройства можно использовать с самого начала. СЭС реального летательного аппарата, как правило, подвержена множественным изменениям и обновлениям, особенно на ранних стадиях проектирования. Все эти изменения могут быть реализованы намного проще при использовании легомодифицируемого макета, чем «реальных» компактных авиационных распределительных устройств.
Перед началом сертификационных испытаний макет распределительной системы может быть заменен настоящим образцом.

Стенд быстрого прототипирования бортового оборудования (MIL Testing)

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

1. Оценка законов управления полетом;
2. Предварительная оценка или компоновка приборных панелей (индикаторы, органы управления);
3. Отладка потоков информационного обмена оборудования;
4. Оценка требований к оборудованию до их передачи подразделениям, ответственным за производство аппаратуры и разработку ПО;
5. Проведение ранней оценки и проверок отказоустойчивости системы.

Какой имитационный комплекс применять

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

Как разрабатывать математические модели 

Любой испытательный стенд развивается по мере продвижения проекта. Следовательно, никто не может предложить «полный» или «лучший» набор моделей для разработки. Чтобы стенд быстрого прототипирования был полезен на протяжении всего срока проекта и при этом требовал разумных трудовых вложений, надо проявить гибкость и попытаться использовать подход в стиле принципа Парето. Тем не менее, мы попытаемся привести примеры «начального» и «расширенного» набора моделей, чтобы проиллюстрировать усредненный случай.

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

1. Разработка и проверка законов тестирования систем управления;
2. Демонстрация и проверка первоначальной компоновки индикатора PFD.

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

«Продвинутый» набор моделей должен поддерживать следующие работы:

1. Продвинутые проверки законов управления полетом, включая резервирование, задержку, отработку неисправностей и т. д.;
2. Возможность проверки законов и логики управления автопилота,;
3. Полное моделирование и оценку окружающей информационной среды в кабине экипажа, включая сообщения PFD, ND, FMS, CAS, синоптические страницы и органы управления;
4. Отладка потоков информационного обмена оборудования, включая анализ пути прохождения каждого параметра от источника к конечному потребителю;
5. Анализ последствий отказов;
6. Валидация требований к ПО перед переходом к трудоемкой фазе разработки ПО в соответствии с DO-178.

В результате список финальных моделей намного длиннее. Приведенный ниже список не является ни полным, ни точным. Однако мы считаем, что он может дать представление о том, что предстоит сделать.

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

1. Масштабируемая архитектура систем моделирования;
2. Использование инструментов для управления конфигурацией потоков данных;
3. Автоматизированная генерация конфигураций моделей интерфейсов. Должна включать в себя в основном части ввода-вывода моделей Simulink и части кода ввода-вывода моделей, разработанных на C++ или Python;
4. Наличие системы контроля конфигурации.

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

Как создать макет кабины

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

1. Вся авионика, включая индикаторы, пульты управления и т.д. моделируются на базе коммерчески доступных мониторов с сенсорным управлением. Функционал сенсорного управления в основном нужен для взаимодействия с пультами;
2. Первичные органы управления, а именно боковые ручки управления (или штурвалы), педали, ручка управления тягой моделируются с использованием похожих игровых устройств;
3. Все индикаторы устанавливаются на монтажной стойке со стандартным креплением мониторов типа VESA.
4. Первичные органы управления закрепляются на специальных металлических поверхностях.

Рис. 17 Концепция макета кабины

Итог

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

Прямо сейчас мы активно участвуем в создании стенда полунатурного моделирования для небольшого летательного аппарата. Для данного проекта в качестве основы имитационного комплекса было предложено использовать новую отечественную разработку РИТМ производства одноименной компании. Опыта работы с РИТМ у нас нет, но ведь всё бывает впервые.
Вот что нам известно на текущий момент об этом решении:

• Стоимость РИТМ гарантированно ниже чем у ADS2 от TechSAT;
• Отсутствует готовое решение на случай масштабирования системы, но у нас уже есть идеи как это быстро сделать в случае необходимости;
• Неизбежные детские болезни компенсируются оперативной технической поддержкой разработчика.

По результатам нашей работы мы обязательно поделимся своим опытом применения РИТМ в реальном проекте.