Assembler в авиапроме: Интервью с разработчиком автопилотов на ASM для самолётов и беспилотников
Человек веками мечтал о небе. Братья Уилбур и Орвилл Райт, Альберто Сантос-Дюмон и братья Вуазен подарили его людям. И человек с каждым десятилетием поднимался всё выше и выше, увеличивал скорости, манёвренность, предельные перегрузки, преодолевал звуковой барьер, сталкивался раз за разом с труднейшими инженерными вызовами.
Авиация изменила мир — и его современный облик во многом сформировался за счёт быстрых авиасообщений, когда достижение другого континента или удалённой страны перестало быть трудным и опасным путешествием длиной в несколько недель, а то и месяцев.
Но с ростом скоростей и расстояний повысились требования к управляющим системам летательных аппаратов — микроконтроллерам, прошивкам, автопилотам.
Мне повезло познакомиться с отечественным разработчиком Владом Гордеевым, который занимается как разработкой систем дистанционного управления полетом самолётов, так и систем автоматического управления полетом ЛА. Я задал ему несколько вопросов — и оказался на пару часов в мире, где всё решают миллисекунды, такты, алгоритмы и нет права на ошибку.
Как вы выбрали профессию? Почему именно разработчик, как призвание? Какой ВУЗ закончили?
Я окончил МАИ в 2007 году по специальности «Системы управления ЛА». Думаю, что скорее профессия выбрала меня, а не я ее. (смех)
В детстве с папой пошли на МАКС, тогда один из первых, и там очень стало интересно, что внутри кабины самолета происходит. Кстати, интересно и до сих пор. Интересна работа летчика. Но о летном деле вообще не думал. Пошел в МАИ, потому что вообще не представлял, куда можно ещё пойти. И когда думал куда идти после радиотехнического колледжа, моя хорошая знакомая сказала: «А иди к нам в МАИ».
В профессию инженера попал после окончания института, хотя не думал, что буду работать по специальности. По сути, в своей компании остался после дипломной практики и защиты диплома. И не думал, что попаду на такую интересную работу. В этой работе всегда виден четкий результат — либо работает как надо, либо не как надо, либо вообще не работает. Значит надо сделать, чтобы работало, причем как надо.
Я попал в профессию в тот момент, когда авиационная техника переходила на цифровые системы управления полетом самолетом. Цифровые системы позволяют уменьшить массо-габаритные характеристики систем управления и упростить изготовление и дальнейшее сопровождение в эксплуатации, а также саму эксплуатацию. Также позволяют упростить корректировку ошибок, выявляемых в процессе испытаний путем корректировки ПО, а не выпаиванием и пайкой элементов платы, как было на аналоговой технике.
Как шёл ваш профессиональный путь, прежде чем вы начали программировать микроконтроллеры для автопилотов?
Я писал диплом на тему верификации программного обеспечения для самолётов.
Изначально создаётся проект написания ПО. Все процедуры описаны в официальной документации, в ГОСТах. Там много, очень много: требования, согласование требований к ПО, просмотры требований, просмотры ПО.
Проверка после написания кода многоэтапная. Сначала просмотры ПО на соответствие требованиям, потом проверка ПО по контрольным примерам, после этого производится установка ПО на целевой вычислитель (прошивка). Аппаратура прошивки тоже своя. Все ПО, а точнее логика работы, алгоритмы работы ПО в системе проверяются на стендах. Если выявляются ошибки, то по спецпроцедуре они исправляются.
Потом снова проверяется этот кусок кода. Снова стенд — и так по кругу, пока головной заказчик не получит то поведение системы и взаимодействия с другими системами, которое требуется по техническому заданию.
Я начал с написания ПО для проверки ПО по контрольным примерам. Потом с этим ПО сам ездил на различные стенды. Проводил установку, проверку. Ну, для примера, автоматической системы торможением колес самолета. Дальше отработка, корректировка, снова проверки. После этого взаимодействие системы с другими системами. Другое ПО, написанное другими программистами. Опять же просмотр, установка на стенды, проверка, корректировка. После этого, когда вся система проверена несколько десятков раз, производится установка на самолёт.
Проверяется работа ПО на самолёте: нет ли отказов. Ну и дальше — в полет. После полетов, если есть необходимость производится корректировка ПО и процедура повторяется в соответствии с документацией. Ну, а после того, как получил опыт проверки системы и корректировки ПО на различных подсистемах одной системы получил задание писать код для части одной подсистемы. И так по чуть-чуть…
Дальше дошло дело и до настройки самих микроконтроллеров. Они же приходят «голые». Для высококритичных областей применения ПО необходимо писать самим даже самые простые функции типа вычисления экспоненты, определения минимума или максимума. Не говоря уже об операционной системе. Распределение временного выполнения тех или иных функций на различных частотах работы одного или двух процессоров. Потому как в микроконтроллерах сейчас используются и процессоры с двумя ядрами — RISC-процессоры (производят целочисленные вычисления) — и процессор для вычислений с плавающей точкой. И это все может и должно работать параллельно и правильно. Должны быть настроены прерывания так, чтобы сначала посчитать в одном процессоре, забрать посчитанные данные и передать их в другой процессор. И чтобы все улеглось в частотный пакет. Это отслеживается с помощью осциллографов на начальном этапе
Asm — это вершина, как по мне. Высокое искусство. Я ещё помню времена, когда на нём программировали. Экономия ресурсов и времени исполнения операций. С высокопроизводительными системами современные языки программирования не так тщательно следят за используемыми ресурсами, как мне кажется. Asm в автопилотах и беспилотниках — почему такой выбор? Максимальная эффективность?
Программирование на ассемблере является очень трудоёмкой и энергоёмкой задачей. И требует от программиста очень больших временных ресурсов для написания программ. Потому что каждую операцию умножения, сложения, деления нужно расписывать фактически на уровне машинного кода. Языки высокого уровня содержат всё это внутри себя. И программисту не приходится задумываться, какие команды, например, дать процессору при операции деления. Которая выполняется сложением и сдвигом фактически.
С точки зрения применения в авиационной технике… Конечно же, это верно с точки зрения экономии ресурсов. На обычных компьютерах ОЗУ уже измеряется гигабайтами, а ПЗУ даже терабайтами. А у нас, в авиационных системах ПЗУ исчисляется мегабайтами, ну может десятками мегабайт. Потому нужно всё чётко и структурировано расписывать, чтобы не было превышения по ресурсам. Это очень важно — что по ресурсам ПЗУ, что по ресурсам ОЗУ.
Почему выбор падает на ассемблер в авиастроении, ясен. Когда идёт разработка системы, нужно понимать — какой-то блок в системе или подсистеме он же разрабатывается на каком-то микроконтроллере. И для этой подсистемы достаточно работы в целых числах. Для этой работы подходит процессор, который работает в целых числах. Масса, габарит, микроконтроллер определённого типа — всё это согласуется. Сначала он ставится в подсистему, затем под него пишется код — в той среде, которую он может воспринимать. Поэтому здесь ассемблер — это просто данность при работе с определёнными микроконтроллерами.
Какой у вас сложился стек технологий за время профессиональной деятельности. Какие языки вам знакомы? Какие профессиональные этапы вы можете выделить?
Авиационная отрасль достаточно консервативна и новые технологии вводятся медленно, с осторожностью и большим количеством проверок.
Так как для того, чтобы эти технологии вводить, надо изучить их суть, посмотреть как они работают сами по себе и во взаимодействии с другими. Изучить — подходят или не подходят.
Переход на цифровые технологии в системах управления ЛА начался очень давно. Где-то в середине-конце 90-х годов прошлого века. И вот только 10 лет назад сделали полностью цифровую систему управления и ее ввели в эксплуатацию в составе одного из типов новых самолётов.
И в разработке самих самолётов цифровые технологии начали вводить достаточно давно и постепенно — и вот сейчас все делается в «цифре». Вы знаете, начиная от разработки 3d модели ЛА, до разработки ПО практически всех систем самого самолёт — все в цифровом виде. Точно также постепенно вводятся системы для обработки и хранения данных, архивов документации. Но все постепенно.
Я по роду работы занимаюсь только языком C и C++. Сейчас есть потребность и желание детально погружаться в ассемблер, чем собственно и занимаюсь.
Вы занимаетесь разработкой систем дистанционного управления полетом самолётов так и систем автоматического управления полетом ЛА. Получается ваши системы могут полностью управлять ЛА в воздухе? От взлёта и до посадки? Какие части процесса ещё остались за человеком-пилотом и с чем пока автоматизированные системы справляются хуже? Или уже во всём превосходят?
Совершенно верно: и СДУ, и САУ.
На данном этапе, когда есть потребность в системах именно автоматического управления, без участия человека, летчика, практически все задачи стараются перевести в зону САУ: от момента взлета, до момента посадки — все хотят сделать в автоматическом режиме.
И постепенно все к этому и идёт. Посмотрите, постепенно ведётся работа по автоматизации уже не только полета самолёта, его посадки, но и руление самолёта по рулежкам до места стоянки в аэропорту. Постепенно работают над тем, чтобы изменить категории автоматической посадки ЛА.
В гражданской авиации очень большое количество самолётов садится по категории IIIC (категория IIIC — точный заход на посадку и посадка по приборам без ограничений по относительной высоте принятия решения и дальности видимости на ВПП). Но, естественно, это зависит и от аэродромного оборудования, и от оборудования на борту.
Все современные самолёты в процессе полета переходят на управление от САУ. Даже управление на самолётах Airbus, Sukhoi Superjet, производимого от джойстика летчика всего-лишь задаёт необходимые значения параметров полета — углов тангажа, крена, скольжения, а автоматическая система сама парирует все внешние возмущения типа ветра, турбулентности и прочего. И только при определенных отказах автоматики самолёт переходит в полностью ручное управление, ну на пример режим «Direct Mode» на самолёте SuperJet, в котором он становится похож на Боинг 737 в ручном управлении.
Если вы посмотрите новости от Минобороны, то они пестрят заголовками о полетах беспилотников. А что значит беспилотник? Это самолёт, летающий полностью в автоматическом режиме — от взлета и до посадки.
Вот руление на земле пока до сих пор происходит только с помощью летчика-оператора. Ну и соответственно, при отказе автоматики, управление на себя берет летчик-оператор. Вот здесь человек всё-таки необходим — контроль за работой автоматики.
Знаете анекдот-присказку? Что в экипаже Боинга 777 должен быть только один пилот. И собака. Которая будет смотреть за действиями летчика и рычать и лаять на него, если он вдруг задумает нажать не ту кнопку.
Поэтому человек в этой системе управления все ещё очень даже нужен.
В чем разница программирования автопилотов ЛА с людьми и беспилотников? Предельные перегрузки? Больше дублирующих подсистем?
В программировании систем с лётчиками и без лётчиков различий нет. Есть разница только в критичности системы, которая работает на том или ином самолёте. В любом случае системы критичные. Ошибки в подсистеме могут привести к катастрофе. Хуже, конечно же, если это самолёт с пассажирами. Но и беспилотник, особенно крупный, можно упасть на голову ничего не подозревающим людям. В любом случае это потеря объекта управления, в любом случае это катастрофа. В любом случае это плохо — так что разницы нет никакой.
Разница только в параметрах полётов определённых типов летательных аппаратов. Например, Боинг, именно сам самолёт, предположим рассчитан на перегрузку 2–3 G — и при высокой перегрузке будет просто разваливаться. Если посмотреть на боевые наши СУ-27, Миг-29, они рассчитаны на перегрузку 9 G. Если брать беспилотники, то скорее всего параметры, как у гражданских самолётов, если беспилотник не рассчитан на высокоманёвренную работу. Потому что беспилотники по большей части — это разведчики и бомбардировщики, платформы для запуска ракет. И потому там высокие перегрузки не нужны.
Разница может быть в предельных перегрузках, в скорости набора высоты, вертикальных скоростях, боковых и продольных перегрузках, максимальной высоте, минимально опасных высотах. Да здесь разница есть — она обусловлена конструкцией летательного аппарата. Пассажирский лайнер при всём желании пилота не сможет выполнять манёвры боевого летательного аппарата.
В любом случае при разработке применяются требования, как для критичных систем.
Расскажите, по внутренним ощущениям, в чём разница между программированием на asm и высокоуровневыми языками? Другой подход и стиль мышления? Всё же обычным программистам не приходится бороться за каждый байт.
Для программирования на asm необходимо четко представлять, как работают сами процессоры, на базе которых и строится микроконтроллер. И хорошо изучить документацию по процессору и микроконтроллеру. Это понимание необходимо для корректного написания кода на asm.
Синтаксис asm одинаков, но работа самого процессора, его настройки, принципы обращения к кэш-памяти процессора, взаимодействие с внешними относительно процессора устройствами, такими как память, например. Эти принципы и настройки могут отличаться в зависимости от ядра самого процессора и производителя.
Среды разработки ПО, к примеру, Code Composer от Texas Instrumensts и не только, содержат внутри так называемые дизассемблеры, то есть это функционал, позволяющий посмотреть в процессе отладки кода на симуляцию его работы или через эмуляцию работы ПО непосредственно на целевом вычислителе, как и какие asm-команды сложения, пересылки, записи в аккумулятор, используются при выполнении той или иной команды или функции, написанной на языке высокого уровня.
Поэтому, конечно, писать код на ассемблере очень трудоемко и долго. Прописывать все пересылки, включать-отключать прерывания процессора, копировать полученные данных в ОЗУ — это все вручную. И много чего ещё. А программистам, работающим на высокоуровневых языках, вообще об этом заботиться не приходится. Тем более, вы знаете, что написание ПО для любого компьютера ограничено его ресурсами. В современных домашних и промышленных рабочих станциях эти ресурсы по производительности процессоров и памяти ну очень большие. У бортовых систем для любых ЛА они в разы ограничены.
С точки зрения программиста, как пользователя средами разработки ПО, все среды и языки отходят все дальше от машинного языка. То есть, по сути, программисту при написании своего кода можно абсолютно не задумываться от том, как и сколько asm-команд необходимо для выполнения функции. А в нашем ПО мы четко следим за тем, чтобы в коде было как можно меньше операций деления, стараясь заменять их везде, где можно операциями умножения. Потому как деление на в asm-командах выполняется гораздо дольше.
Говоря о дальнейшем развитии сред разработки ПО именно для критичного ПО, есть среды, которые позволяют набирать функционал системы в схематичном виде. Протягивая связи от одного «квадратика» к другому, можно получить необходимую функцию системы для ее выполнения. Ну например, режим полета самолёта с поддержанием конкретно заданной высоты, можно прорисовать в виде схемы — и после сборки и компиляции получить код на «си». Но эти среды и кодогенераторы должны быть полностью сертифицированы для проведения таких работ с точки зрения их работы для высококритичных систем. Так что все так не просто.
Ваша компания занимается разработкой железа (микроконтроллеров), алгоритмов, ПО по алгоритмам. А также настройкой микроконтроллеров для корректной работы ПО в системе. Как у вас всё устроено организационно? Это отдельные подразделения? Как они взаимодействуют?
Касательно подразделений. На самом деле всё очень просто организационно. Есть подразделение, которое занимается разработкой самих вычислителей для летательных аппаратов. Они берут за базу какой-то микроконтроллер. Какой именно микроконтроллер выбрать — они обсуждают с нами, с программистами, согласовывая технические возможности микроконтроллера и наши потребности для написания программного кода по объёмам ПЗУ, по скорости работы, по наличию двухпортового ОЗУ, в общем куча параметров.
После согласования с нами они начинают разработку печатных плат, точнее электрических соединений. Дальше всё переходит в конструкторский отдел, где уже непосредственно по этим соединениям конструктора делают конструктив печатной платы, учитывая все соединения, которые им дал предыдущий отдел. Конструктора делают электронный чертёж с разводкой дорожек. Потом все чертежи отдаются в цех производства. Вместе с этим конструктора разрабатывают «внешние шкафы» — коробки, в которые будут вставляться эти платы. Соответственно, там разводятся питание, «земли», сигнальные провода.
В цеху это паяется. В цеху и у конструкторов своё программное обеспечение, к которому мы прямого отношения не имеем. Но результаты выкладываются в общую глобальную систему нашего предприятия, в которой мы можем посмотреть чертежи. Если есть необходимость.
Затем мы получаем изделие — саму печатную плату или блок, куда мы можем уже прошить подготовленное ПО. Или блок для отработки обеспечения, для настройки микроконтроллеров. И смотрим, как всё работаем. На этом этапе отладки мы тестируем, настраиваем, перенастраиваем — с точки зрения микроконтроллеров.
Когда всё железо работает вместе с кодом по настройке железа, тогда мы в код настроечный добавляем алгоритмы. С временным диспетчером, с распределением выполнения алгоритмов по тактовым частотам. Если вылезают какие-то косяки или неточности в работе железа, то мы вместе с разработчиками железа обсуждаем это — и дальше они корректируют свою техническую документацию, передают в цех. И так по кругу. Пока нормально не заработает.
Уверен, вам известна печальная история с авариями Boeing 737 Max. Погибли сотни человек. Как вы видите причины таких критических ошибок в автопилотах Боингов? Как такое в принципе могло произойти?
Я не могу точно ответить за компанию Боинг, как они это все пропустили на всех этапах. Очень часто в спешке разработки или выпуска системы или самого самолёта, для того чтобы уложиться в установленные планами сроки, бывают случаются такие ошибки, приводящие к подобным катастрофам.
К сожалению, все это воздействие человеческого фактора. Его, как отдельное направление в изучении причин авиационных инцидентов, начали изучать после инцидента 10 июня 1990 года с рейсом номер 5390 компании British Airways, когда на высоте 5 км из кабины пилотов вырвало левое ветровое стекло, и капитан наполовину оказался за бортом самолёта, зацепившись коленями за ремни и приборную доску, потеряв сознание. Благо тогда все кончилось благополучно.
Касательно этого эпизода, для меня удивительно, что автоматическая система MCAS для перекладки стабилизаторов самолёта берет данные только с одного датчика угла атаки при наличии двух, по обоим сторонам борта. Боинг сам снизил отказобезопасность своей системы. Это очень странно.
В алгоритмах, которыми занимаемся мы, данные берутся со всех датчиков, относящихся к системе. Причем, датчики более чем двукратно резервированы. Каналы связи тоже. Применяются определенные алгоритмы получения корректного сигнала в систему. Там целая логика, которая обсуждается с разработчиками и заказчиками системы, производителями ЛА. Которая тоже многократно проверяется. Там целая большая процедура. Вообще, отказобезопасность — это очень большая глава в разработке систем управления, для обеспечения безопасности полетов и безотказности работы системы управления.
Наши отечественные производства микроконтроллеров и программ для автопилотов насколько застрахованы от появления такой технической ошибки?
На самом деле никакая система не застрахована от ошибок человека, ее разрабатывающего, или группы людей. Тот же самый пресловутый «человеческий фактор».
Подобные «ошибки» — это не до конца продуманные логика и алгоритмы работы системы. И это труд не одного человека — это работа отделов, департаментов компании.
И здесь дело не только в работе программиста. Ему какой алгоритм дали, такой он и запрограммировал. Что тоже, кстати, не очень верно. Но это принцип разделения труда. И он тоже работает. Каждый отвечает за свой кусок работы. Не каждый «кодер» обязан, может и хочет быть инженером, разработчиком — человеком, вникающим, понимающим, как работает то, что он пишет, не только в рамках своего «куска», но и в рамках системы. А это уже другой уровень подготовки и самого специалиста.
Есть такое понятие «полнота покрытия кода». Это понятие, отражающее насколько можно проверить или проверены все возможные ветки кода и все возможные комбинации событий, происходящих в системе в соответствии с работой этого ПО. Очень объемная, трудоёмкая и времязатратная часть проверки, верификации кода. Но это про ПО.
А что если в самой логике работы системы, в ее алгоритмах уже изначально не заложены определенные ситуации, «защита от дурака»? Это же не всегда возможно. Я бы даже сказал — невозможно. Невозможно предусмотреть абсолютно всё. Но ставить в обработку сигнал только с одного датчика угла атаки, когда на борту их два — вот этого я вообще не понимаю. Но опять же — это вопрос к разработчикам системы MCAS для компании Boeing и Airbus.
Так что для выявления ошибок, неточностей, нестыковок, неверной логики, неверных алгоритмов, ошибочной реализации этого в коде, ошибок в настройках железа, ошибок в компиляторах (поверьте, и такое тоже бывает) — для этого всего и существуют все процедуры проверки, верификации, а также испытания, заключения и прочее.
Также нельзя исключать и временной фактор, когда нужно все сделать быстрее. За время своей профессиональной деятельности на моей памяти были несколько инцидентов (даже с потерями ЛА) из-за того, что надо «быстрее, быстрее, быстрее». Так что система «человек-машина» очень многогранное поле для исследований, практики и опыта.
Вопросы от Павла Селиванова, архитектора Southbridge, спикера Слёрма, Certified Kubernetes Administrator
Интересно получается, вы разработчики, и мы вроде как разработчики. Но миры абсолютно разные. Используете ли вы какие-то инструменты и подходы из мира веб-разработки? Например, как вы храните и версионируете код, используется ли Git? Есть ли у вас понятие автоматического тестирования и различных типов тестов? Unit, интеграционное тестирование и так далее. Это как раз к вопросу о проверке всех возможных вариантов действия системы и всех возможных «дураков» с ней взаимодействующих. Есть ли какие-то процессы автоматизации релизов и тестирования? Автоматический запуск тестов, автоматическая заливка кода на контроллер.
На данный момент мы работаем над вопросом автоматизации тестирования нашего ПО, и различные типы тестовых примеров — это как раз залог максимального покрытия разработанного кода.
Под интеграционным тестированием я понимаю тестирование всех модулей ПО для системы, когда после тестирования и проверки каждого модуля ПО в отдельности, все модули проекта собираются в один и запускаются либо тестовые примеры, либо симулируется работа процессора во встроенном в среду разработки инструментарии. Если просто, то собирается весь проект целиком и начинают прощелкивать все возможные варианты работы ПО. Далее ПО устанавливается на несколько стендов и начинается проверка всевозможных режимов работы ПО в системе управления.
К сожалению автоматическая заливка кода у нас в компании не разрешена, а точнее — запрещена нашей службой контроля качества. Единственное, что мне известно, это разрешено при работе с БПЛА для смены координат маршрутных точек. Автоматическая заливка ПО в вычислитель запрещена. Хотя в США, насколько я знаю, исполняемый код вычислителя может заливаться в ПЗУ самого вычислителя по штатным информационным сигнальным проводам. А само прошиваемое ПО передается на ЛА по защищённым спутниковым каналам связи. У нас этого нет. Не буду оценивать хорошо это или плохо — у нас просто нет.
Павел, отвечаю на Ваш вопрос улыбаясь. Вот Ваша фраза «вы разработчики, и мы вроде как разработчики»…
Мы разработчики и вы, если занимаетесь разработкой ПО. А насколько я знаю, вы этим и занимаетесь, то и вы — разработчики. Но задачи разрабатываемого нами и вами ПО абсолютно разные. Системы различные, критичность различная, применение ПО различное. Цель одна — чтобы все работало, как задумано, без сбоев.
А для хранения рабочих, официальных версий ПО, а также всей необходимой документации, мы используем plm-систему, написанную на JAVA и работающую в интернет-браузере нашей внутренней сети и являющуюся программным обеспечением управления жизненным циклом продукта.
В своей работе мы не используем ПО, находящееся в открытом доступе. Это для нас непозволительная роскошь. (улыбка)
В этой plm-системе мы отслеживаем всю версионность ПО, трассируя ее в соответствии с нашей документацией по управлению конфигурацией ПО. Мы четко знаем и понимаем какие версии ПО должны официально устанавливаться на те или иные вычислители самой системы управления. Все это отслеживается нашей очень строгой системой контроля качества.
Возможны ли в вашей области какие то подвижки в сторону гибких методологий разработки? Agile, Scrum и так далее. Вы же наверняка сталкиваетесь с проблемой, когда на этапе проектирования сделали проект, чертежи, потом изготовили все платы, а потом на этапе программирования оказывается, что делать нужно было не так, или планы в процессе изменились, или тестирование выявило нечто, что требует переделывать довольно крупный кусок работы.
Конечно возможны. Как я говорил, в принципе у нас имеется общая система для производства, куда входят и циклы разработки чертежей инженерами-конструкторами, и изготовление печатных плат по этим чертежам, и заказ материалов для изготовления изделий по этим чертежам, управление складами, заказами, приходами на склад, выдачей в производство. Даже экономические аспекты. Все это учитывается в основной системе, может даже скорее базе данных, самого предприятия, производства.
А ситуации, когда всю документацию разработали, пустили в производство, сделали, получили и… «не то», бывают, ещё как бывают. Но это скорее вопрос к организации производственного цикла на самом предприятии, к управлению бизнес-процессами в компании, нежели к разработке кода для системы управления ЛА на «си» или asm.
