Комментарии 45
когда лётчик пытается запросить от базы освобождение ресурсов
Серьезно, "driver" теперь как летчик переводят?
Кейс №1. В 1996м году не было валюты "евро".
Раздолбайство, пофигизм, потеря чувства ответственности со светящимся над головой нимбом при виде на бездонную финансовую бочку... такой вот сказ про дырявый таз.
Про Боинг, конечно, кривое проектирование ПО, которое не способно отработать одну возможную неисправность. Однако, все многократно усугубилось нежелением официально объявить о существовании самой такой систем, так как это усложнило бы сертификацию и потребовало бы дополнительного обучения пилотов (а это деньги). В руководстве по эксплуатации изначально даже не было упоминания об этой системе. И, вроде, не было возможности отключить ее. То есть у пилотов не было даже теоретической возможности исправить ситуацию.
Упоминание MCAS в FCOM (Flight Crew Operation Manual) было. А в FCTM (Flight Crew Training Manual) было описано более подробно.
Отключить MCAS нельзя, но можно отключить приводы перекладки стабилизаторов. Это действие входит в ситуацию Runaway Stabilizer (самопроизвольная перекладка стабилизатора), симптомы которой и действия в ней пилоты должны знать наизусть.
перед второй катастрофой Б разъяснили
про то что МКАС отключается: при включении автопилоты, при выпуске закрылок/предкрылок, при включении автомата тяги
Катастрофы, связанные с MCAS, были в 2018 и 2019 годах, а приведённая страница FCTM от 2017.
Имхо, это не так важно как то, что информацию не довели, и это привело к крушению нескольких самолётов.
То есть могли где то в толстой книге дописать пару строк про MCAS и никому об этом не сказать. Юридически вроде защитились, жизни под угрозу поставило, а до пилотов не довели.
А до пилотов ничего особенного и не надо было доводить. Ситуация вполне укладывалась в древний сценарий Runaway Stabilizer, который пилоты должны были знать наизусть. Почему пилоты этого не знали - вопрос к руководству авиакомпании по качеству обучения и тестирования пилотов.
В предпоследнем полёте индонезийского борта MCAS тоже пытался загнать самолёт в землю, но экипаж вовремя отключил приводы перекладки стабилизаторов.
Главная проблема в первом пункте: "Определить ситуацию".
А про упоминание, то, например, Денис Окань, как и некоторые другие авторы, утверждает, что MCAS до первой аварии упоминался только в списке сокращений.
имеете ввиду "перекомпенсацию руля высоты" или что-то все же другое?
stabilizer runaway было описано в еще 60х годах
но даже так то ко перед второй катастрофой Б расписали логику работы
Но рекомендации всё равно были кривые. При прямом следовании рекомендациям после сильной перекладки стабилизатора на пикирование, отключения электропривода и удержания штурвала на себя пилотам просто физически не хватало сил провернуть колесо ручного триммирования стабилизатора. Хотя алгоритм работы MCAS вполне позволял сначала с кнопок штурвала вернуть стабилизатор в нейтраль, а уже затем отключать электропривод.
С боингом ситуация немного хитрее. 737max не имеет "аппаратных" проблем, которые потребовалось решать MCAS'ом. То, что двигатели расположены дальше от крыла не делает аэродинамику какой-то не такой и плохой. Это отличный самолёт.
Проблема в том, что управление этим самолётом (без MCAS) несколько отличалось от управления всей предыдущей 737 серией как раз из-за немного другого расположения двигателей. То есть, пилот, привыкший летать на, например, 737-800 обнаруживал, что новый самолёт откликается на управление немного иначе. И тут было два варианта: либо делать долгий (а значит дорогой) курс по "доучиванию" пилотов 737 до 737-max, либо с помощью ПО сделать так, чтобы 737-max управлялся настолько же привычно, как и предыдущие самолёты этой серии. Вот это вот и делал MCAS.
Проблема в том, что управление этим самолётом (без MCAS) несколько отличалось от управления всей предыдущей 737 серией
Управление не отличалось. Другие размер и расположение двигателей приводило к тому, что при больших углах атаки обшивка двигателей создавала дополнительную подъёмную силу, увеличивающую кабрирующий момент и, соответственно, и без того большой угол атаки. Эффект проявлялся в определённом диапазоне скоростей и углов атаки. MCAS как раз должен был следить, чтобы самолёт не попадал в этот диапазон, заранее перекладывая стабилизатор на пикирование, опуская нос самолёта, соответственно уменьшая угол атаки. В нормальных режимах полёта MCAS вообще никак не влиял.
Из FCTM:
The MCAS only operates at extreme high speed pitch up conditions that are outside the normal operating envelope.
Хм.. я вот этого дядьку слушал, а FCTM не читал. Но, кажется, что противоречий нет https://youtu.be/ue400BhW0aY?si=_IpKeMD9kHNlZb9r (первые 17 минут можно пропустить).
В 20:30 он говорит, что разница в том, что вот в этой особенной ситуации (низкая скорость и большой угол атаки) ощущение на штурвале легче/слабее, чем на предыдущих версиях 737. В то время как в статье говорится буквально о некоей внутренней нестабильности, которую следовало бы устранить аппаратным образом.
Вообще непонятно зачем они стали исправлять "проблему" другой аэродинамики, если у них и так восьмисотки, девятисотки и прочие четырёхсотки довольно заметно отличаются по поведению, и это никогда не смущало пилотов. Да и, например, пилоты Эйрбаса спокойно могут сегодня сделать рейс на коротком А319, а завтра на длинном А321, и это тоже их никак не смущает.
А потому что не надо запускать 16 битную Сегу в космос ))
Теоретически, 128
Чтобы не столкнуться с числовым лимитом. Но им виднее...
Вот бы шутку сейчас в серьез разбирать ))
Видимо, неверно я истолковал "16-битные целые могут находиться в диапазоне от -32 768 до 32 767. При этом числа с плавающей запятой создаются для отслеживания более широкого диапазона значений, используя то же количество битов между -1.8e+308 и -2.2e-308. Если вы попытаетесь сохранить такое значение в 16-битном целом числе, то оно значительно выйдет за его допустимые границы. По итогу в программном обеспечении ракеты произошло хорошо известное целочисленное переполнение." - получается здесь о разрядности чисел, а не процессора. И неясно, почему ими была выбрана тогда именно такая разрядность. Не могли потенциально просчитать, какой диапазон мог быть задействован?
Парень, поинтересуйся на досуге хотя бы характеристиками “Apollo Guidance Computer.” Это бортовой компьютер, который астронавтов на Луну доставлял. И мне кажется, что ты либо не поверишь, либо охренеешь :) Ну, если ты, конечно, не из числа убеждённых сторонников версии, что Луна и астронавты — продукт Голливуда.
Глянул. Ну, почему не поверю? Поверю. Там же не единым компьютером все решается - он, как я понимаю, модуль внутри более сложной системы и должен выполнять максимально простые операции. Для этого не нужны огромные характеристики. Тем более годы-то какие?
Предлагаю попробовать осилить для начала хотя бы статью на wikipedia, чтобы не делать столь далёких от истины предположений о “исполняющем максимально простые операции модуле в составе более сложной системы.” AGC — единственный (на лунном модуле ещё был AGS, способный поднять модуль с Луны и пристыковать к командному модулю в случае отказа основного) и главный компьютер в каждом из двух модулей миссий “Apollo.” И его работа — не “максимально простые операции”, а полностью полёт, навигация и управление.
Если бы у NASA в те времена была упомянутая тобой Sega с её Motorola 68000 и 72KB RAM, то она бы астронавтам ещё и кофе в полёте варила, и в Super Mario давала бы резаться. Проблемы не в разрядности, не в гигагерцах и гигабайтах. Проблемы в программистах.
"максимально простые операции" - здесь я подразумевал, что операции сложные, но не настолько, чтобы тащить на борт процессор для кодирования видео в H.265 или AV1. И, да, проблема в программистах: сейчас бы не было такой гонки за процессорами, видеокартами и объемами ПЗУ, если бы все было грамотно оптимизировано, а не представляло "связку программного нагромождения". В свое время программы под DOS вполне себе справлялись со многими задачами и не надо было сегодняшних мощностей. Но я это уже другая тема.
Ещё не читая ждал один и тот же набор набивших оскомину кейсов: Ариана, Therac, Боинг. И набор советов: тестируйте по, будьте внимательны, какую-то там культуру отстаивайте (как будто инженер "за $9 в час" из далёкой страны имеет какое-то влияние на культуру стомиллиардной американской монополии, лол).
Но можно на это и с другой стороны посмотреть: за десятки лет существования отрасли даже сотня катастрофических кейсов не нашлась, чтобы их в статьях ротировать, значит может не всё так плохо в целом? Все вокруг компьютеры конечно привычно глючат по мелочам, но в том что касается жизней и сложных миссий -- фатальные ошибки редки.
Вместо того чтобы устранить внутреннюю нестабильность в дизайне 737 MAX, компания Boeing решила прибегнуть к программному «исправлению», которое внесло новые уязвимости.
Если я правильно понял суть той истории - двигатели бОльшего размера создавали бОльший опрокидывающий момент, приводящий к тому, что при резкой подаче "газа" самолет стремился задрать нос, что на взлете могло вызвать сваливание в штопор с последующей практически неминуемой катастрофой. Вот эта система и была призвана помочь летчикам и при подаче газа и превышении угла атаки она самостоятельна давала "руль от себя", что-бы избежать сваливания.
Конечно было-бы правильнее переделать планер, что-бы уменьшить этот момент силы, но это стоило бы очень дорого, по факту потребовало бы разработки нового самолета. А система, при нормальной ее реализации вполне бы справилась с этой проблемой. Да, в принципе, и летчики бы справились, только им надо было довести информацию о существующей опасности и натренировать на ее устранение.
Там и летчики показали себя не очень хорошо, систему можно (и нужно) было просто отключить, после чего самолет спокойно бы долетел до аэродрома и без нее. Но они то-ли не знали о ней, то-ли не знали что ее надо отключить..
Там проблема была не в тяге, а в подъёмной силе от обтекателя двигателя. Двигатель стал крупнее (больше площадь обтекателя) и больше вынесен вперёд (больше момент силы). В результате дополнительная подъёмная сила на больших скоростях и углах атаки вызывала излишний кабрирующий момент и могла привести к неконтролируемому росту угла атаки с последующим срывом потока и сваливанием.
Например, в мире аэрокосмонавтики ставки невероятно высоки, и программные сбои могут вести к катастрофическим последствиям.
А если резистор или конденсатор впаять не того номинала или того пуще их перепутать, не кондицию пропустить сбоя не будет что-ли? Ставки высоки только для программных сбоев, другие ошибки не ведут, что ли к катастрофическим последствиям в мире аэрокосмонавтики?
того пуще их перепутать
Когда у тебя небольшое количество железа можно разориться хоть на поэлементную проверку, рентген, оптический контроль и тп.
Не знаю, за какой мир Вы серчаете, но к примеру в IAI (Israel Aerospace Industries) никогда не попадает на склад ширпотреб от дядюшки Ху и ему подобных производителей. Подход к производителям компонентов сродни медицинским препаратам, которые прошли тщательный отбор и всевозможные клинические испытания на разрешение их к применению.
Что касается сбоев софта и его дальнейшей эволюции, к примеру Маск в своих космических проектах со времен Space X взял на вооружение IDE визуального программрования на языке G (LabView), вся бортовая телеметрия и это не прихоть, а продиктованные требования, когда ошибки в транскрипции кода, априори отсутствуют, при этом разрабы все свои усилия направляют на оптимизацию применения набора тулсов.
Добавлю, почти аналогичную первому случаю, ошибку в коде системы наведения ракет ЗРК "Patriot". Читал о нем давно на уже умершем сайте, но нашел на другом источнике https://tech.onliner.by/2019/10/03/zrk-patriot
Забавно было читать, что на первых порах, когда вояки узнали про этот баг они просто перегружали систему на регулярной основе, чтобы минимизировать погрешность расчета, и в какой-то момент забыли это сделать. И промахнулись...
Как программные ошибки приводят к катастрофическим последствиям