LINUX.ORG.RU

Катастрофа Boeing 737 MAX и обновление ПО

 , , ,


0

3

15.03.2019: New MCAS software should come out end of this month (FCC P12.1).

The software changes will include:

  • Limit stab trim MCAS commands
  • AOA comparison monitor (AOA>5.5deg = MCAS disabled)
  • Slower stab trim MCAS command speed
  • AOA Disagree will become standard (now is an option)

QRH for Speed Trim Fail will be revised but memory items will remain the same.

source

12.03.2019: Boeing to update 737 MAXs after delaying changes for months

Boeing plans to make major changes to the flight control systems on the 737 MAX aircraft — just months after delaying a similar software fix due to failed negotiations with the FAA, a report says.

The updates — which involve multiple sensors, or data feeds, being rolled out into the MAX’s stall-prevention system in place of its current single-sensor setup — were ordered up in the wake of the deadly Lion Air crash in Indonesia last October and were originally planned for early January.

source

30.11.2018: Boeing is reportedly planning 737 MAX software upgrade

Boeing is reportedly considering a software upgrade for its 737 MAX family following the deadly crash of Lion Air Flight JT610 last month. The move comes after a preliminary report by Indonesian investigators, released just a few days ago, put the U.S. plane maker’s new anti-stall system at the center of the search for the cause of the accident.

Reuters, citing two sources briefed on Boeing’s proposal, said the aircraft manufacturer could launch the software update over the next six to eight weeks and that it would help address a situation the flight crew on the doomed 737 MAX 8 experienced.

source

Страшно вспомнить какие ужасы были на заре массовой авиации.

Чёт у нас самолеты один за одним падать стали. Ой! А нельзя иллюминаторы делать прямоугольные! Усталость металла быстро копится и кирдык! (Забыл какая модель, но их штук 5 упало пока я нашли косяк)

dk- ()
Ответ на: комментарий от dk-

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

mandala ★★★★ ()
Ответ на: комментарий от mandala

Насколько я понимаю, проблема алгоритмов, а не датчика.

Ни разу не оправдаю Боинг. Но не ошибается лишь тот, кто ничего не делает.

dk- ()
Ответ на: комментарий от mandala

Прикол в том, что 737-й чуть ли не самый безопасный самолёт в мире. Поэтому и не шевелились. Извини, что ещё в одной теме встретились. Мы за вами не следим.

Tigger ★★★★★ ()

upd

15.03.2019: New MCAS software should come out end of this month (FCC P12.1).

The software changes will include:

  • Limit stab trim MCAS commands
  • AOA comparison monitor (AOA>5.5deg = MCAS disabled)
  • Slower stab trim MCAS command speed
  • AOA Disagree will become standard (now is an option)

QRH for Speed Trim Fail will be revised but memory items will remain the same. source

Edward_I ()
Ответ на: комментарий от mandala

Эта бюрократия занимается верификацией обновления. Без неё был бы fail fast, revert и try again.

Пускай уж лучше потонет немножко.

alpha ★★★★★ ()
Ответ на: комментарий от anonymous

Ил-14

Высота полёта не та, соответственно и нагрузки не те.

AS ★★★★★ ()
Ответ на: комментарий от dk-

Но не ошибается лишь тот, кто ничего не делает.

Вопрос в том, какова цена ошибки. Причем ошибки не только и не столько конкретного программиста-инженера, сколько всех участвующих в процессе.

Edward_I ()
Ответ на: комментарий от alpha

Эта бюрократия занимается верификацией обновления.
Пускай уж лучше потонет немножко.

А приостановить эксплуатацию на время верификации нельзя?

Edward_I ()
Ответ на: комментарий от alpha

Ну вот полёты им запретили, теперь зашевелятся. Всё же это разные категории: просто модернизация или исправление ошибок которые приводят к катастрофам.

mandala ★★★★ ()
Ответ на: комментарий от Edward_I

Клиенты с говном сожрут, там же убытки шо ппц. Современные самолеты работают как маршрутки останавливая полеты только на обслуживание.

mandala ★★★★ ()

Считаю неправильным, в любых бедствиях, искать персонально виноватых. (У нас доходит до маразма: если обрушился ураган, то виноватым назначают Васю/чиновника из жэка, который «вовремя» не спилил/не дал указание спилить, упавшее дерево (а то и вовсе человека, который посадил это дерево) и т.п.)

Но в данном случае возникает вопрос. А не построен ли у них (в Boeing) так производственный процесс, что все инженеры сделали всё точно в рамках своих инструкций и обязанностей. Джон написал, Гарри протестировал, Майкл по-результатам тестов согласовал. Т.е. каждый вроде сделал свою работу, однако результат общей работы на выходе оказался не очень. И как быть? При том, что результат и не может, и не должен зависеть от одного человека.

Edward_I ()
Ответ на: комментарий от Edward_I

Быстро и нормально сделаешь мало заплатят. Надо делать херова и долго, что-бы бабла больше выделяли.
Теперь, после пары падений инженерам должны много денег дать.

Int0l ★★ ()
Ответ на: комментарий от dk-

Вот тоже интересно https://flying-elk.livejournal.com/46084.html

Это к тому, насколько сложная система – современный самолёт. Но в 99% вся сложность «прячется» автоматикой. И пилоты расслабляются, и как выскакивает 1% – не все готовы. https://flying-elk.livejournal.com/45444.html

https://arabskiy-pilot.livejournal.com/68641.html

Ни фига. Снова те же грабли. Это я говорю в принципе без обязательной связи с эфиопской катастрофой. Много раз до этого я с удивленияем слышал, что, к примеру, многие пилоты А330 даже не знают, что конкретно, в нюансах произошло с французским А330 над Атлантикой. Как они в это положение попали, что видели на приборах, как при этом летел самолет. Не знают. Им не интересно. Они могут хорошо летать в стандартных условиях. И в стандартных нестандартных на тренажере. За этими границами их ничего не интересует. Это раньше не укладывалось в моей голове.

greenman ★★★★★ ()
Последнее исправление: greenman (всего исправлений: 2)
Ответ на: комментарий от mandala

Заклёпки…

Заклёпки обеспечивают деформируемые соединения не теряющие при этом прочность. От них ещё долго не уйдут в авиации и кораблестроении.(Пока на композит не перейдут.)
В приведённом примере, проблема не в заклёпках, а в конструкционном решении.
p.s. Для тех, кто начнёт гнать про сварку в судостроении: там в любом случае есть деформационные швы на заклёпках.

anonymous ()
Ответ на: комментарий от anonymous

а в конструкционном решении.

Которое на заклёпках. Там же на свеженьких проверили: прям с завода с дефектами.

Ну и потом: переделали, они еще несколько десятков лет летали.

в любом случае есть деформационные швы на заклёпках.

Ну это немного друго.

mandala ★★★★ ()
Ответ на: комментарий от mandala

Ну и потом: переделали, они еще несколько десятков лет летали.

Конструкцию переделали, или заклёпки убрали?

Ну это немного друго.

Да это я, чтобы не начали писать, что корабли уже 80 лет, как на сварке.

anonymous ()
Ответ на: комментарий от anonymous

Судя по фото на Comet 4 остались те же прямоугольные иллюминаторы, т.е. что-то таки там сделали именно по креплению. Хотя там до фига чего изменили вообще.

mandala ★★★★ ()
Ответ на: комментарий от anonymous

Ты собрался хаскель водрузить на оборудование самолета? Или там жабу с ее сборщиком мусора? Ты о чем, вообще?

dave ★★★★★ ()
Ответ на: комментарий от dave

На петушином Coq пошем кодогератор для мужланского Haskell, который генерит код для женственной Ada, которая генерит бездушный машинный код. Ох тут есть много чего, за что можно засудить: от зоофилии до рабовладения.

anonymous ()
Ответ на: комментарий от Edward_I

виноватым назначают Васю/чиновника из жэка, который «вовремя» не спилил/не дал указание спилить, упавшее дерево

А ты пройдись по улицам и вверх посмотри.

den73 ★★★★★ ()
Ответ на: комментарий от dimon555

хаскель он для do178b утверждён?

На жалость давишь? Недавно посмотрел фильм «Авиатор», так себе киношка...

anonymous ()
Ответ на: комментарий от Edward_I

Если интересны не собственные домыслы, то. ПО в авиации тестируется согласно do178b/c, можешь почитать как на самом деле организован процесс.

178B переведен на русский, поищи КТ 178В.

aiqu6Ait ★★★ ()
Последнее исправление: aiqu6Ait (всего исправлений: 1)
Ответ на: комментарий от Edward_I

А не построен ли у них (в Boeing) так производственный процесс, что все инженеры сделали всё точно в рамках своих инструкций и обязанностей

Для этого есть всякие независимые сертификационные компании. Но к сожалению в реальной жизни я только о таком слышал.

dem ★★ ()

самое интересное, что скорость можно померять например тензометрическими датчиками на крыльях - там силовые элементы будут «тянуться» от набегающего потока.

example_cat ()
Ответ на: комментарий от aiqu6Ait

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

example_cat ()
Ответ на: комментарий от Edward_I

У нас доходит до маразма: если обрушился ураган, то виноватым назначают Васю/чиновника из жэка

Этот Вася там всю жизнь сидит и получает зарплату именно за то чтобы организовать работу и проверку что когда и где нужно спилить. И если выясняется что он для этого не сделал ничего, то да, он несет за это ответственность.

Точно так же менеджмент компании, это его обязанность выстроить процессы, не забыть про тестирование, следить чтобы Джон и Гарри работали в неизмененном состоянии сознания... И если этот процесс фейлится, менеджер несет за это ответственность.

Как в том анекдоте где «мы платим 100500 долларов за один удар - нет, вы платите за то что я знаю как и куда его нанести» так и здесь: вина не в том что однажды случилось неожиданное и кто-то пострадал, а в том что ты не выстроил процесс и не знаешь зачем тут сидишь.

alpha ★★★★★ ()
Ответ на: комментарий от alpha

Я не понял смсысл написаного. Ответственность за процесс или за результат? «Война - фигня, главное - маневры»?

anonymous ()
Ответ на: комментарий от aiqu6Ait

ПО в авиации тестируется согласно do178b/c

Спасибо. Просмотрел.

Если исходить из описанных там процессов, то однозначно получается, что в процессе разработки на очередном этапе кто-то подал на вход ошибочные данные и кто-то их принял (допустил к принятию). Причем эту ошибку допустили или в команде, или же сама команда получила ошибочные/неполные исходные данные (данные о девайсе, ТЗ, требования к тестам, сами тесты и т.д.).

Т.о. локализовать ошибку/ответственного можно всегда?

Edward_I ()
Ответ на: комментарий от dk-

Страшно вспомнить какие ужасы были на заре массовой авиации.

скорее страшно сравнить с современными самолётами, в которых гарантировано выживших не будет, если что-то пойдёт не так

anonymous ()
Ответ на: комментарий от anonymous

В случае катасторофы это касается любого самолета в принципе. Гравитация-с. А так... ну вот в А380 вся гидравлика резервирована по четыре раза. Вся. И на одном из двух двигателей большинство самолетов может спокойно продолжать полет. Некторые, даже взлетать. А уж долететь до ближайшего - любой.

dk- ()

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

Это поднимает вопрос об ответственности программиста за продукты своей жизнедеятельности, которой сейчас, по сути, нету и в помине. Самолёт упал из-за софтварной ошибки, люди гробанулись? Начальство само собой, но и автора (ов) - в тюрьму надолго. И заставить до конца жизни деньги семьям погибших выплачивать из кармана виновного. Может тогда будут думать наперёд и тестировать тщательней.

anonymous ()
Ответ на: комментарий от alpha

Этот Вася там всю жизнь сидит и получает зарплату именно за то чтобы организовать работу и проверку что когда и где нужно спилить.

Привел аналогию не полностью. Согласен, что если дерево находилось последние N дней в состоянии "вот-вот упадет", а Вася ничего не предпринял, хотя согласился на то, что будет действовать в таких случаях (и получать за это зп), то тогда да, можно с него спросить. Просто часто приходиться слышать обвинения из-за любого аврального события. И начинается рассуждения: они поставлены блюсти наш покой и благополучие, зп получают, а тут такое!

вина не в том что однажды случилось неожиданное и кто-то пострадал, а в том что ты не выстроил процесс и не знаешь зачем тут сидишь

С одной стороны так. Однако, можно выстроить процессы (=делать свою работу), получить unexpected event и остаться виноватым. Эта несколько порочная практика «ответственного за участок/коллектив». Строго говоря, человек может и должен отвечать только за самого себя. Всё остальное не в его (полной) власти, чтобы нести за это (полную) ответственность. Поэтому вообще глупо на кого-то надеяться и винить, даже если тот взял на себя какие-либо обязательства. Впрочем это всё оффтоп.

Edward_I ()
Ответ на: комментарий от alpha

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

Вот кстати в требованиях МАК по проектированию ПО сказано:

Примечание: Современный уровень технологии программирования не позволяет установить количественную связь между сложностью ПО и удовлетворением требований к безопасности.

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

Edward_I ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.