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

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

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

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

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

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

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

рис 2. Т-4

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

ЭДСУ

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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 ^[13] или любой другой достаточно быстрой шине, такой как spacewire ^[14], 1394 ^[15] и пр… Главный критерий — скорость передачи данных.

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

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

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

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

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

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

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

• Init Mode – режим загрузки устройства, который обычно включает определение состояние устройства путём синхронизации и проведения встроенных и внешних тестов.
• Normal Mode – штатный режим, в котором процесс полёта контролируется основными компьютерами и команды пилота корректируются в соответствии с законами управления. Например, это позволяет запрещать недопустимые комбинации команд — запрещает критические углы атаки, крена, газа, запрещает недопустимые команды (например выпуск шасси в воздухе), а так же демпфирует поверхности в зависимости от внешних параметров (ветра, тяги двигателей, особенностей планера). В штатном режиме команды от PFC посылаются на безусловное выполнение ACE с оговоркой, что ACE проверяет валидность сигналов путём опроса статуса о PFC. Так же иногда разделяют нормальный режим на режим полёта (in air) и на режим на земле (weight on wheel), который может в свою очередь может быть разделён на режим стоянки, такси, взлётапосадки. По современной классификации некоторые системы управления в режиме Normal Mode могут быть отнесены к IFCS ^[22] (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 достигается различным пин-кодированием и различным расположением модулей в пространстве. Система в идеале защищена «от дураков». В первую очередь — от человеческого фактора. В последующие — от критических условий (режимов короткого замыкания, потери питания, высоких и низких температур), а так же от невозможного события по Мерфи. В коде это выливается, к примеру в пароноидальное программирование ^[23].

рис 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 ^[24] узнают выполнение обычных правил в этом коде. Вообще такой код не самый хороший и оптимальный, тем не менее он гарантирует исключение невозможных ситуаций:

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