autodiagnost (autodiagnost) wrote,
autodiagnost
autodiagnost

Categories:

Продолжение статьи Авария Boeing 737 Max глазами разработчика ПО.

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

Эти строки кода, несомненно, написаны людьми под управлением начальников. Ни программисты, ни их начальники не знакомы с особенной культурой и нравами авиационного мира настолько, насколько люди, работающие на фабриках, склёпывающие крылья, разрабатывающие управляющие скобы и устанавливающие посадочные шасси в фюзеляж. Эти люди обладают общей «отраслевой» памятью о том, что сработало в прошлом в авиации, а что пошло не так. Разработчики программного обеспечения — нет.

В 737 Max одновременно активен лишь один из полётных компьютеров — либо на стороне основного, либо на стороне второго пилота. Активный компьютер получает данные только с тех датчиков, что установлены на его стороне самолёта.

Если человек при пилотировании замечает, что данные компьютеров расходятся, он осматривает панель управления, оценивает показания других приборов и разбирается, что не так. В системе, установленной на Боинге, бортовой компьютер не «осматривает другие приборы». Он доверяет только приборам на своей стороне. Он не делает по-старинке. Он сверхсовременный. Он — ПО.

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

Хуже того. Существует несколько других приборов, которые прямым и косвенным способом позволяют определить угол атаки, например, трубки Пито, искусственный горизонт и так далее. Лётчик бы проверил все эти приборы, чтобы быстро диагностировать неисправный датчик угла атаки.

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

Как человек с нарциссическим расстройством личности, MCAS затмевает собой решения пилотов. И это в конце концов оказалось плохо для всех.



— HAL, подними нос.
— Прости, Дейв, боюсь, я не могу этого для тебя сделать.


Бортовой компьютер под управлением MCAS остается слепым к любым доказательствам, что он неправ, включая те, что пилот видит собственными глазами, а когда он отчаянно пытается выровнять самолёт и тянет до отказа роботизированный штурвал на себя, компьютер “кусает” лётчика и его пассажиров до смерти.

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

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

Тогда FAA предложила авиаконструкторам: «А что если ваши люди будут сами нам говорить, насколько проект безопасен?” Производители ответили: „Звучит неплохо.” А FAA: “И передайте привет Джо, мы скучаем.»

Так родилась концепция «Выделенных инженерных представителей» (“Designated Engineering Representative,” DER). Эти представители являются наемными лицами самолетостроительных компаний, производителей двигателей и разработчиков ПО, которые удостоверяют для FAA факт того, что всё безопасно и хорошо.

Это выглядит как явный конфликт интересов, однако это не совсем так, всё же никто не заинтересован в том, чтобы самолёты падали. Индустрия авиаперевозок полностью полагается на доверие публики, а каждая авиакатастрофа представляет для отрасли экзистенциальную угрозу. Никто из производителей не станет нанимать DER только для того, чтобы он подписывал любые бумаги. С другой стороны, после долгого трудового дня кто-то может на слово поверить парням из отдела разработки ПО, что “да всё там в порядке".

Поразительно, что кажется никто из разработчиков ПО для MCAS в 737 Max не поднял вопрос об использовании при определении развивающегося сваливания не одного, а нескольких источников данных, включая расположенный с другой стороны датчик угла атаки. Как пожизненный член братства разработчиков программного обеспечения, я не понимаю, какая гремучая смесь некомпетентности, высокомерия и отсутствия понимания авиационной культуры могла привести к такой ошибке.

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


Но я точно знаю, что это индикатор куда более глубокой проблемы в отрасли. Люди, которые писали код для оригинальной системы MCAS, были, очевидно, бесконечно далеки от того уровня профессиональной зрелости, что от них требовалась, и даже не подозревали об этом. Как можно теперь доверить им исправление этого ПО, да и вообще верить в надежность и безопасность остального ПО управления полётом?

Итак, Боинг создал аэродинамически нестабильный корпус летательного аппарата — 737 Max. Первая большая ошибка. Боинг затем попытался замаскировать возникшую проблему динамической нестабильности нового 737 с помощью ПО. Вторая ошибка. Наконец, ПО опиралось на показания систем, известных своей склонностью к отказам (сенсоры угла атаки), и не имела даже примитивных процедур перекрестных проверок не только с другими типами приборов, но и даже сверки с показаниями второго набора датчиков. Большая ошибка №3.

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

Это не просто большая проблема. Это политический, социальный, экономический и технический грех.

Так получилось, что в промежутке между первой и второй катастрофами 737 Max, мне пришлось установить новый цифровой автопилот для моего собственного самолёта. Это Cessna 172 1979 года, самый популярный самолёт в истории по количеству произведенных образцов. Он получил первый лётный сертификат почти на десятилетие раньше первого Боинга 737 (1955 год против 1967).

Мой новый автопилот состоит из нескольких сверхсовременных компонентов, включая резервный бортовой компьютер (с двумя Garmin G5s) и замысловатую коммуникационную шину (CAN, Controller Area Network), позволяющей разным компонентам системы общаться друг с другом вне зависимости от их расположения в корпусе самолёта. CAN шина была разработана в автомобильной промышленности для реализации технологии Drive-by-Wire (электронной цифровой системы управления автомобилем), но с точки зрения целей и реализации она схожа с шинами ARINC, соединяющими компоненты в 737 Max.

Мой автопилот также включает в себя электронные триммеры. Следовательно, он может вносить такие же поправки к конфигурацию полета моей 172, как и полётные компьютеры с системой MCAS в 737 Max. Помню, что после первой катастрофы 737 Max, во время установки автопилота, при разговоре с другом я отметил, что, вероятно, добавляю потенциальный источник опасности, схожей с той, что привела к гибели рейса Lion Air.

Наконец, мой новый автопилот также имеет «защитную оболочку” (ту самую защиту диапазона режимов полёта), где „оболочкой“ является график предельных эксплуатационных свойств самолёта. В то время, когда автопилот не управляет моей Cessna, система тем не менее продолжает контролировать состояние самолёта, чтобы удостовериться, что я не свалю его в штопор, не полечу вверх шасси или не сделаю массу других штук. Да, у него тоже есть режим „кусачая собака“.

Как видите, сходства между моим автопилотом за $20,000 и многомиллионным автопилотом в каждом 737 прямые, осязаемые и релевантные. В чём же различия?

Для начала, установка нового автопилота потребовала получения нового сертификата (“Supplemental Type Certificate,” STC). То есть и производитель автопилота, и FAA согласны, что моя Cessna 172 1979 года со встроенным автопилотом от Garmin настолько существенно отличается от того самолёта, что когда-то сошёл с конвейера, что это уже вовсе не та же Cessna 172. Это совсем другой самолёт.

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

Особенно следует отметить, что в этой документации, с которой должен ознакомиться любой собирающийся полетать на этом самолёте, подробно объясняется функционирование автопилота и как он управляет триммерами, а также описываются особенности работы защиты диапазона режимов полёта.

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

В этом и есть огромная разница между тем, что говорят лётчикам, собирающимся впервые сесть за штурвал моей Cessna, и теми, что садились в 737 Max.

От переводчика: Один из читателей оригинальной статьи указал, что несмотря на то, что у Боинга 737 Max два бортовых компьютера, переключиться с одного на другой в полёте нельзя. Более того, отключить MCAS можно, только вытащив предохранитель из гидравлического мотора, приводящего в движение триммеры оперения, но у лётчиков всё равно не хватает сил поменять положение триммеров без помощи гидравлики. А MCAS их уже установил в минимальное возможное положение…


Ещё одним отличием между моим автопилотом и системой с MCAS в 737 Max является то, что приборы, связанные CAN шиной постоянно коммуницируют и проводят перекрёстные проверки, чего, по-видимому, MCAS не делает. Например, автопилот постоянно опрашивает оба бортовых компьютера G5 для определения расположения. Если данные расходятся, то система оповещает пилота и отключается, переходя в режим ручного управления. Она не направляет самолёт в землю, если вдруг начинает считать, что он вот-вот начнёт сваливаться.

И, вероятно, самым большим отличием является сила, которую лётчик должен приложить, чтобы подавить команды автопилота на моем самолёте и на 737 Max. В моей 172 всё ещё есть тросы, напрямую соединяющие органы управления с аэродинамическими поверхностями. Компьютер вынужден нажимать на те же самые рычаги, что и я, причём он намного слабее меня. Случись, что компьютер неверно решит, что самолёт начинает сваливаться, я с лёгкостью смогу преодолеть его сопротивление.

В моей Cessna человек все ещё всегда выходит победителем из битвы с автопилотом. Точно такую же философию всегда исповедовал и Боинг при разработке своих самолётов, более того — использовал против своего заклятого конкурента Airbus, который действовал прямо наоборот. Однако с выходом 737 Max Боинг, похоже, никому ничего не говоря, решил поменять стратегию взаимоотношений человека и машины и так же тихо поменять инструкцию по эксплуатации.

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

Дефекты в устройстве техники и “железе”, будь то неудачно расположенные двигатели или уплотнительные кольца, рассыпающиеся на морозе, заведомо сложно исправить. Говоря „сложно“, я имею в виду „дорого“. С другой стороны, дефекты в программном обеспечении можно исправить быстро и дёшево. Всё, что требуется — просто опубликовать обновление и выпустить патч. Более того, мы добились того, что покупатели теперь считают всё это нормой — и обновления для операционной системы на компьютере, и патчи, автоматически устанавливаемые на мою Теслу пока я сплю.

В 1990-х я как-то написал статью, в которой сравнивал относительную сложность процессоров Intel Pentium, выраженную в количестве транзисторов на чипе, со сложностью новой ОС Microsoft Windows, выраженную в строках исходного кода. Оказалось, что они были сравнительно одинаково сложными.

Примерно в тоже самое время выяснилось, что ранние версии процессоров Pentium были подвержены багу, названному ошибкой FDIV. Лишь небольшое количество пользователей Pentium (прим. пер.: учёные и математики) могли испытывать какие-либо проблемы в связи с ней. В Windows были найдены аналогичные дефекты, также затрагивавшие лишь незначительную часть пользователей ОС.

Однако последствия для компаний Intel и Microsoft оказались в корне разными. Для Windows планомерно выпускались небольшие программные заплатки, Intel же пришлось в 1994 году отозвать все бракованные процессоры. Это обошлось компании в 475 миллионов долларов — более 800 миллионов в сегодняшних ценах.

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

Каждый раз, когда выходит новое обновление для моей Tesla, полётного компьютера Garmin в моей Cessna, термостата Nest или телевизора у меня дома, я лишний раз понимаю, что ни одна из этих вещей не была выпущена с фабрики по-настоящему готовой. Потому что их создатели осознали, что это вовсе необязательно. Работу можно будет закончить когда-нибудь потом, выпустив очередное обновление.
»Я — сетевой инженер, бывший программист, писавший ПО для авионики самолётов. Всегда было любопытно, что нам приходилось изворачиваться изо всех сил, чтобы поставить новую плату в сертифицированный компьютер, а ПО не требовало никакой сертификации (кроме общих ограничений типа «не может работать под Windows» или «должно быть написано на С++»). Правда, это было около 10 лет назад, надеюсь, что сейчас дела обстоят иначе."
— Анонимно, из личной переписки
В настоящее время Боинг устанавливает новое обновление для бортового компьютера и MCAS 737 Max. Не знаю точно, но полагаю, что это обновление будет в основном направлено на две вещи:

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

Второе — отказаться от стратеги «сначала стреляй, вопросы потом задавать будешь», то есть начать смотреть на разные источники вместо одного.

Хоть убей, не понимаю, каким образом получилось, что эти два базовых принципа авиационной промышленности, основы мышления, верно служившие индустрии до сих пор, могли быть забыты при разработке MCAS. Я не знаю и не понимаю, какой процесс в работе DER настолько сломался, что он допустил такой фундаментальный дефект в проекте.

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

Упор на необходимость разрабатывать максимально простые системы хорошо показан у Чарльза Пэрроу, социолога Йельского университета, автора книги «Нормальные аварии: жизнь с высокорискованными технологиями» (Normal Accidents: Living With High-Risk Technologies(англ.)) 1984 года. Вся суть книги содержится уже в названии. Пэрроу утверждает, что системный сбой является нормальным результатом работы любой сложной системы с тесно связанными компонентами, когда поведение одного компонента непосредственно отражается на поведении другого. Несмотря на то, что по отдельности такие ошибки могут казаться вызванными той или иной неисправностью техники или сломанным процессом, на самом деле они должны рассматриваться как неотъемлемые особенности самой системы. Это «ожидаемые» аварии.

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

Именно об этом нам говорит и старый инженерный принцип проектирования — «Чем проще, тем лучше» (“Keep it simple, stupid”, KISS), и его авиационный вариант: «Упрости, потом добавь лёгкости» (“Simplify, then add lightness”).

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

Не могу выкинуть из головы параллели между катастрофами 737 Max и космического челнока Челленджер. Авария с Челленджером произошла потому, что люди следовали инструкциям, а не наоборот — ещё одна иллюстрация «нормальных» катастроф. Правила говорили, что перед запуском челнока требуется провести конференцию, чтобы убедиться в полной готовности к полёту. Никто не говорил, что при вынесении решения нельзя придавать слишком большой вес возможным политические последствиям, которые могли бы возникнуть из-за переноса запуска. Все вводные данные были тщательно взвешены согласно установленному процессу, большинство согласилось на запуск. И семь человек погибло.

В случае с 737 Max всё тоже делалось по всем правилам. Правила говорят, что тангаж самолёта не должен слишком сильно изменяться при изменении мощности двигателя и что назначенный инженер (DER) вправе подписать любые изменения, направленные на решение этой проблемы. В правилах нет ничего о том, что DER не должен руководствоваться деловыми соображения при принятии решения. И вот уже 346 человек мертвы.

Весьма вероятно, что система MCAS, разрабатываемая с расчетом на повышение безопасности полётов, убила больше людей, чем могла бы когда-либо спасти. Не надо пытаться исправлять её дальнейшим повышением сложности, дополнительным ПО. Её нужно просто убрать.
Tags: общество, полеты
Subscribe
  • Post a new comment

    Error

    default userpic
    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 0 comments