Архитектура систем управления самолётом

«Мы работаем для того, чтобы вы не боялись летать»

рис 1. Модель Bombardier BD 500 в аэродинамической трубе

Именно такой слоган я как-то придумал для своей работы. Он как нельзя лучше выражает саму суть разработки систем управления самолётом. И, если честно, я бы хотел, чтобы это стало девизом всех разработчиков систем управления современными самолётами по всему миру. Потому что, несмотря на то, что часто можно услышать, что самолёт — один из самых безопасных видов транспорта, тысячи людей по всему миру боятся летать, вцепляются в ручки кресел… А зачастую причина всех страхов — неизвестность. Когда надо доверится такой непрочной конструкции, болтающейся километры над землёй, таким хрупким сплетением проводов и битов кода, скрытой завесой улыбок стюардесс и тайн программного кода. И которую стоит приоткрыть.

К моему удивлению, моя предыдущая статья вызвала неожиданно большой резонанс как на Хабре, так и за его пределами. Мне задали ряд вопросов и высказали ряд недовольства, законно обозвав это «закрытой областью». Вопреки такому мнению, всё, о чём я рассказывал в статье и о чём речь пойдёт в этой, можно найти в интернете. Быть может по разрозненным кускам, быть может, на разных языках, но ни один факт не является ноу-хау. Задача моей статьи — познакомить читателя с замечательной областью авиации и классифицировать весь опыт и знания, которые мне удалось накопить. Что же касается проблемных тем и вопросов, затронутых мной, хочется вспомнить схожий случай, описанный г-ном Фейнманом в замечательной книжке «Какое тебе дело до того, что о тебе думают другие?». Если кто не читал, то обязательно прочтите. Там Ричард рассказывает о проблемах в НАСА. О проблемах, которые привели к крушению челнока. И о том, что не всегда бывает виновато оборудование, программы, программисты их писавшие, а часто виноватыми оказываются допуски, сокрытие фактов и принятые консервативные решения. И знаете что? НАСА из-за этого случая и огласки не стало хуже, а лишь научилось на своём хоть и печальном, но опыте. Престиж не только не упал, но вырос, НАСА показала себя организацией, которая умеет решать проблемы и признавать их. Потому что как космос, как и авиация — великолепные области, в которых работают великолепные компании и преданные люди. И не верьте тем, кто говорит, что после установки туалетов в самолётах небо перестало быть местом для романтиков.

Automation is great. It’s essential. It reduces fatigue, and enhances safety. But what if it breaks?

Все вы конечно знаете, что законы Мерфи работают, и один из них гласит, что всё, что может сломаться — сломается. Всё, что не может сломаться — тоже сломается. Каков бы не был низок процент отказа оборудования, вероятность отказа существует. Но существуют методы, позволяющие эти отказы минимизировать. И, в первую очередь, это архитектурные особенности программно-аппаратного комплекса.

рис 2. Т-4

Современный самолёт управляется так называемой ЭДСУ — Электро Динамической Системой Управления. На самом деле, это не такая уж новинка. Впервые такая система была установлена на советском самолёте «Максим Горький», управляющая поверхностями путём передачи электрического тока (аналоговая ЭДСУ). Позже в военной технике она появится в полностью цифровом виде на советском Т-4, а в гражданской авиации — на Airbus A320 и Ту-204. Тем не менее, ни что не стоит на месте и технологии совершенствуются, разрабатываются новые подходы и достигаются новые уровни безопасности.

ЭДСУ

Что представляет собой ЭДСУ? В первую очередь, это программно-аппаратный комплекс, состоящий из:

• Приводов управляющих поверхностей самолёта
• Датчиков контроля
• Системы управления
• Системы индикации и вспомогательных систем
• Системы коммуникации и силовой системы

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

рис 3. структурная схема ЭДСУ

Использование ЭДСУ в первую очередь обеспечивает значительное уменьшение веса системы управления, что на больших самолётах имеет критическую важность. Так же даёт более гибкие возможности компоновки, часто позволяет расположить систему управления практически в любом доступном месте самолёта. Кстати говоря, поэтому управление по проводам (fly-by-wire) всё ещё является наиболее популярным, т. к. является не столь сложным и капризным, как fly-by-light (с использованием оптики ) или fly-by-wireless (с использованием беспроводных технологий). Уменьшение веса и упрощение компоновки позволяет ввести дополнительные контуры, обеспечивающие нормальное управление самолётом в состоянии отказа одного из работавших ранее контуров. Позволяет по возможности уменьшить человеческий фактор, контролируя параметры полёта в автоматическом режиме и корректируя команды пилотов. Контролирует состояние критических систем самолёта в режиме реального времени, что позволяет обнаружить, отследить и по возможности исправить ошибку в минимально возможное время.

рис 4. функциональная схема ЭДСУ

Тем не менее, в процессе проектирования таких систем критически важно создать правильную архитектуру. Это — наиболее уязвимое место ЭДСУ. Наиболее классическими случаями ошибок являются:

• зависимость системы от электропитания, что в случае механического управления является катастрофой, но не ведёт к потере управления всем самолётом (посадка Ту-154).
• неверное дублирование системы управления (инцидент с Ан-148)
• «глупые» ошибки ПО, например такие, как смена знака при пересечения экватора, возможность отрицательной скорости на гражданском самолёте и пр.

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

• дублирование управления
• наличие ответного сигнала (feedback)
• система самоконтроля (разделение на управляющую и контролирующую часть).

К сожалению, не имею представления о технологиях, которые были применены в советских самолётах, но думаю, он схож с современным подходом, который справедлив и для иностранных, и для российских проектов.

Система управления

Типичная система управления состоит из:

• PFC – Primary Flight Computer — центрального компьютера управления, в который включены все законы управления и который умеет анализировать все поступающие данные от датчиков и feedback и отдавать данные на исполнение электроникой. PFC в самолётах бывает как 1 (в наиболее либо простых, либо дешевых системах), как 2, так и 3. PFC работают в штатном режиме сообща и одновременно.
• ACE – Actuator Control Electronic — исполнительные модули контроля актуаторами (приводами). Включают в себя часть логики управления поверхностью на случай отказа основного компьютера. Передают непосредственно команды на исполнения актуаторами. В зависимости от типов как бывают спроектированы как для управления электроприводами, так и гидравлическими. Любой ACE так же в зависимости от архитектуры дублируется.ACE при наличие дублёра работают попеременно.
• Ручек управления (штурвалручка (sidestick), педали и пр.).
• Индикаторов информационных экранов.
• Актуаторов.
• Силовой электроники (если не включена в модули управления).

рис 5. ЭДСУ Boeing 777

В зависимости от сложности системы могут быть добавлены дополнительные устройства разделены существующие. В любом случае, при правильном дублировании и проектировании системы главный принцип — это соблюдение принципа «различия» (dissimilarity), что означает, что для каждого элемента работающего в режиме дублирования дожна быть применены различные электронные компоненты, процессоры, языки программирования, написан разный код, а соединяющие провода проложены независимо разными путями.

Электроника управления

Компьютеры управления (PFC) и исполнительные модули (ACE) состоят в свою очередь из нескольких независимых каналов. В простейшем случае они состоят из канала управления, который вычисляет команду к исполнению (Control Channel) и канала контроля, который проверят правильность команд (Monitor Channel). Для простоты можно сказать, что первый должен выдавать наиболее точные данные, рассчитанные с использованием сложных законов управления, базирующихся на динамических моделях поведения самолёта, а второй — давать правильную оценку на основе оценки окружающей обстановки, поступающей от датчиков с принимая и допуская некий «усреднённый вариант», но делая это быстрее канала управления, имея возможность заблокировать новый неверный сигнал до того, как пройдёт команда к исполнению и обработать ошибку.

рис 6. архитектурная схема PFC для Boeing 777

В зависимости от проекта применяется разное число модулей и разные комбинации каналов внутри них. В Boeing-777, например, три главных компьютера по три канала в каждом. Причём каждый канал может исполнять разные роли, но неизменно один из них — канал управления, а два других — контроля. В Boeing, к примеру, популярна схема с 1 MC, 1 CC и 1 канал горячей замены (standby). В других компоновках так же могут быть отдельно вынесен канал для управления силовой электроникой, или для целей наладки и проектирования — платы расширения функциональности (Extender Board) или внедрения ошибок (Fault Insertion Board). Общение между каналами обычно происходит по шине CAN или любой другой достаточно быстрой шине, такой как spacewire, 1394 и пр… Главный критерий — скорость передачи данных.

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

рис 7. Упрощённая схема типичной реализации системы управления

Так же используются непосредственно аналоговые и цифровые сигналы. Классической компоновкой является применение ADC DAC (аналого-цифровых и цифро-аналоговых конвертеров) внутри ACE для опроса датчиков и для командования приводами, а так же с использованием Resolver'ов для их чуткого управления. Использования дискретных сигналов — для синхронизации (в т.ч. от тактовых генераторов), пин-кодинга (определения положения и роли модуля) модулей. Модули, как правило, знают о состоянии друг друга и во многих случаях архитектура подразумевает «горячий» старт, когда резервный модуль подхватывает состояние главного и переходит в режим активного, заменяя прошлый главный модуль в течение пары секунд. ACE и PFC являются модулями LRU (Line Replaceable Unit), т. е. модулями линейной замены, что подразумевает собой возможность заменить один модуль (как плату расширения) на подобный без необходимости замены (модификации) всей связной системы. Схожая архитектура используется и для компоненов системы в отдельности, для таких система управления шасси, гидравликой, люками.

Принятие решения на основе совместной работы различных устройств — это сложный вопрос, на который нельзя ответить однозначно. Есть разные пути решения: синхронизация, решение методом среднего с использованием данных о состоянии (об ошибках), пути обнаружить неисправные модули и отключить их, сценарии работы. К примеру, при использовании трёх PFC при наличии двух одинаковых команд и одной отличной — отличная будет отбракована. При трёх разных — система будет отключена, как и при разных показания в системе, использующей только два PFC. Различных логик может быть много, как и включая алгоритмы работы при дублировании ЭДСУ механической системой управления. В последнем случае вероятность отказа возрастает, т. к. при сбое механической системы управления должна быть информирована ЭДСУ об отказе и среагировать на это переходом в аварийный режим.

рис 8. Схема парного исполнения ACE для электрогидравлической системы

Режимы работы.

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

• Init Mode – режим загрузки устройства, который обычно включает определение состояние устройства путём синхронизации и проведения встроенных и внешних тестов.
• Normal Mode – штатный режим, в котором процесс полёта контролируется основными компьютерами и команды пилота корректируются в соответствии с законами управления. Например, это позволяет запрещать недопустимые комбинации команд — запрещает критические углы атаки, крена, газа, запрещает недопустимые команды (например выпуск шасси в воздухе), а так же демпфирует поверхности в зависимости от внешних параметров (ветра, тяги двигателей, особенностей планера). В штатном режиме команды от PFC посылаются на безусловное выполнение ACE с оговоркой, что ACE проверяет валидность сигналов путём опроса статуса о PFC. Так же иногда разделяют нормальный режим на режим полёта (in air) и на режим на земле (weight on wheel), который может в свою очередь может быть разделён на режим стоянки, такси, взлётапосадки. По современной классификации некоторые системы управления в режиме Normal Mode могут быть отнесены к IFCS (Intelligent Flight Control System – Умным Системам Управления). Как повод для гордости, могу отметить, одна из первых и лучших в гражданской авиации, чтобы обеспечивать полёт как по рельсам разработана для Sukhoi Superjet, а не в более именитых её собратьях. В будущем, надеюсь, такие системы будут использовать вс мощ искуственного интеллекта под своим контролем.
• Alternative Secondary law – особый режим, позволяющий комбинировать логику ACE и PFC, либо замещать нормальные законы управления заранее откалиброванными. Это особый режим(ы), который типичен для самолётов Airbus Boeing в случае когда надо добиться нетипичного поведения самолёта либо в особых, но некритичных случаях (в режиме пониженного энергопотребления, дефекта поверхностей).
• Direct mode — режим прямого управления. Этот режим управления без использования PFC, путём передачи прямых команд от органов управления к ACE. В действительности он является виртуально прямым, т. к. если ACE функциональны, то они имеют ограниченные законы управления и трансформации получаемых от пилотов сигналов. В случае потери ACE, теряется так же и полностью поверхность.
• Mechanical law – режим механического управления. Возможен в случае наличия резервной механической системы управления. Его всё реже можно встретить на самолётах, но, тем не менее, обеспечивает управление некоторыми поверхностями даже в случае потери ACE.
• Failsafe mode – режим отказа, сигнализирующий об отказе устройства или критичных систем, которые к нему относятся. Обычно является следствием отказа как внутри оборудования (аппаратного или программного), либо подконтрольних устройств. Тем не менее, может быть разделён на критичный — когда выход возможен только путём наземного обслуживания иили замены оборудования, и на исправимый отказ, который может быть возвращён в рабочий режим (Direct, Normal, Alternative – в зависимости от логики) путём диагностики системы или её полётного перезапуска.
• Rigging (Calibration) Mode – режим обслуживания, калибровки оборудования на земле — изменение калибровочных параметров самолёта (к примеру в зависимости от геометрии или имевших ранее отказов на самолёте). Обычно инициируется на земле в регулярном порядке (тех. обслуживание) или после ошибки (падения в Failsafe mode). Обслуживание производится как со снятием модуля и считывания данных через внутренние порты (RS232, USB), так и непосредственно на самолёте с использованием терминала (RS232, LAN), либо OMS (Onboard Maintenance System) через USB, COM, LAN.

рис 9. схема работы с четыремя PFC

Ещё раз про дублирование и защиту

Чтобы не вдаваться в технические подробности и конкретные реализации, кратко подытожу: каждая система дублируется. Так, помимо модулей управления, дублируются цепи питания (три и более), магнитные замки, датчики, сообщения от устройств, ручки управления. Каждая информация требует подтверждения. Так, для диагностирования ошибки в зависимости от её критичности требуется время для её подтверждения (чтобы не отключить систему раньше времени из-за помехи), обычно с разных устройств сразу. Даже в случае отказа или даже множественных отказов есть возможность осуществлять управление в альтернативном режиме. Это достигается путём использования различных аппаратных и программных средств. Так, для одного и того же устройства используются различные процессоры и схема платы для разных каналов. Например, для Control Channel — процессор от Motorola, а для Monitor – от Infineon, для другого LRU – от Texas Instruments и т.п… Используются различные компиляторы, пишется разный код. В идеале для разных PFC ACE должны быть так же разные программно-аппаратные решения, но в простом случае (это не всегда возможно и целесообразно как в техническом, так и финансовом плане) dissimilarity достигается различным пин-кодированием и различным расположением модулей в пространстве. Система в идеале защищена «от дураков». В первую очередь — от человеческого фактора. В последующие — от критических условий (режимов короткого замыкания, потери питания, высоких и низких температур), а так же от невозможного события по Мерфи. В коде это выливается, к примеру в пароноидальное программирование.

рис 10. четыре PFC разбиты на пары

Код

static bool_t CANInterface_StripStatusData (CanMsgFrm_t * CanRxMsg_ip)
{
/*#FUNCTION_SIGNATURE# CANInterface_StripStatusData */
bool_t bSuccess = TRUE;

    /* Extract data from message ID 0xN using following layout:                              */
    /* ------------------------------------------------------------------------------------- */
    /* |  Layout  |  Range |       Name        | Unit Ident | Description                  | */
    /* |-----------------------------------------------------------------------------------| */
    /* | Byte 0   | 0, 1   | ConsNgWow         | 1, 2       | Consolidated Nose Gear       | */
    /* | Bit 0    |        |                   |            | Weight on Wheel              | */
    /* |-----------------------------------------------------------------------------------| */

/* If data is send trough valid pointer */
if (CanRxMsg_ip EQU_C NULL_C)
{
bSuccess = FALSE;
}
else
{
/* Process, only if unit is valid */
/* There is no data clipping and loss, we extracting only actual bits from message. */
if (cUnitIdent_g EQU_C UNIT_IDENT_UNIT1_E)
{
bConsNgWow_g = (bool_t)(CanRxMsg_ip->Message.cUint8_a[ZERO_C]
& BITMASK_ONE_BIT_C);
/* … */
/* Other bits are spare here, not used in this message */
}
else if (cUnitIdent_g EQU_C UNIT_IDENT_UNIT2_E)
{
bConsNgWow_g = (bool_t)(CanRxMsg_ip->Message.cUint8_a[ZERO_C]
& BITMASK_ONE_BIT_C);
}
else
{
bSuccess = FALSE;
}
}
return(bSuccess);
/*#end ACD# CANInterface_StripStatusData */
}

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

1. функция не может вызваться с нулевым указателем, т. к. ей передаётся адрес объекта. Тем не менее есть проверка на отличие указателя от нуля. На моей практике встречались ошибки с невалидным указателям не раз, которые могли проявляться на одной машине даже при нормальной работе стека, а на другой никогда и ни при каких обстоятельствах.
2. Все магические номера заменены константами на случай, что если когда-то изменится архитектура, не нужно будет отслеживать изменения, а так же оттого, что сложнее что-то поломать выполнив случайную контекстную замену.
3. обязательное приведение типов, это MISRA-правило, которое наряду со своей частой неоправданностью позволяет отловить signedunsigned conversion и sign loss.
4. битмаска на один бит выглядит идиотством, ибо bool в данном случае может быть только true или false. Но, тем не менее, при последующем изменении кода можно гарантировать, что даже если в эту область памяти будет записано что-то другое, это останется ожидаемой 0 или 1, да и при сдвиге на несколько бит актуальной позиции — это изоляция от прочих значимых битов.
5. возврат статуса, даже если функция не делает вообще ничего и её работа не влияет на систему позволяет диагностировать возникшую проблему с точностью до функции.
6. описание всех вариантов, даже если это дублирующий код. Помимо требования к софту A, из-за особенностей компиляторов код с использованием одной инструкции if-else может интерпретироваться не так, как ожидается, тем более при внесении изменений может быть допущена ошибка или не отработана ситуация с невозможным идентификатором PFC. В случае если код дублирующий, обычно оптимизации компилятора его компонуют сами. Dead Code же напротив, следует избегать всеми возможными средствами, за исключением deactivated conditional (projectbuild-specific) кода.
7. стандартные типы не должны использоваться, чтобы предотвратить ошибки связанные с особенностями платформ и компиляторов
8. должна соблюдаться венгерская нотация, чтобы обеспечить достаточный уровень ясности кода даже без использования специальных IDE.
9. код должен содержать ясные комментарии
10. код должен быть быстрым и не требовательным к ресурсам

              /* convert label */
              nTmp = (uint16_t)ArincData.Octet.nByte0;
              nTmp = ((nTmp & 0x55U) << ONE_U_C)  | ((nTmp & 0xAAU) >> ONE_U_C);
              nTmp = ((nTmp & 0x33U) << TWO_U_C)  | ((nTmp & 0xCCU) >> TWO_U_C);
              nTmp = ((nTmp & 0x0FU) << FOUR_U_C) | ((nTmp & 0xF0U) >> FOUR_U_C);
              /* write converted label back */
              ArincData.Octet.nByte0 = nTmp;

Инвертирование бит с алгоритмом Уоррена.

Выводы

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

P.S. кстати говоря, во время написания этой статьи выяснилось, что ПО управления Boeing 777 написано на ada.

Автор: wwakabobik