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

Естественно, мы не способны в полной мере обсуждать всё то, что связано с пилотированием, матчастью и другой авиационной спецификой. Как давний любитель авиации я хоть и не являюсь полным профаном в этих вещах, но всё же остаюсь на уровне любителя. НО! Всё, что связано с логикой работы компьютерных программ - это уже моя профессиональная сфера. И здесь я при желании тоже мог бы обозвать оппонентов не имеющими практического опыта дилетантами и ни разу не сидевшими "за штурвалом программиста" ламерами.

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

И потом, разве программа вывела из строя реверс и выпустила самолёт в полёт? Разве программа вдруг "дала газ"? В чём, по мнению прокуратуры, была ошибка в этой самой программе? Что не спасла самолёт при нескольких предпосылках к катастрофе, к которым сама не имела никакого отношения? Что не сообразила, что никто взлетать и не собирался? А как тогда должен был компьютер эту ситуацию классифицировать? Как такой "use case" обозвать? "Разгон на пробеге"? Чем он отличается от попытки взлететь по тем или иным причинам? Где здесь чёткая грань, чёткие признаки на основе которых можно выработать алгоритм и написать программу? Это, мне кажется, очень даже не просто, и думать тут не одному человеку и не один день.

реагировали на это перемещение увеличением тяги до ~60%

увелечением оборотов двигателя до 60%. а не тяги.

Рекомендую
http://www.forumavia.ru/a.php? ...

пацак:

А вот я сам не программист, но приходится частенько с ними общаться.
Благодаря этому, я и сам понял, что наше потребительское понимание "компьютер" сформировано разного рода бездарными комментариями и околонаучнофантастическими боевиками, где компьютеры навроде джина из бутылки. Такая, знаете ли, полная автоматика для выполняемой работы "от и до": нажал на кнопку и, готово! - даже спина мокрая.
Бывало так: взрослый умный человек, а представление о возможностях компьютера - на уровне детсада. Отвечая незнакомке я, похоже, "поперек батьки (пацака) - полез", за что извиняюсь, но, не видя никакой реакции на такой пост...
Судя по пафосу, она(?) откуда-то из СМИ. Вот на примере ее возмущения можно было бы такое объяснение привести:
Если она "выдала техзадание" своему партнеру-программисту по части проведения взаимоприятного вечера И ТОЛЬКО, но в результате получила нежелательную беременность, то это - ошибка программиста. А вот если она кроме "хочу тебя" ничего не уточняла, то вышеупомянутый результат явится последствием некорректно составленного техзадания на программирование последовательных действий и выдачи предупреждающих сообщений, и никакой ошибки "программиста" здесь не будет. Шибко приземленно, но, думаю, суть понятна.

@tapi
Да нет, Вы как раз совершенно правильно написали. Всё так и есть. Если программист вовлечён в стадию концептуальной разработки, анализа задачи, возможных ситуаций и т.д., то есть не просто кодирует ТЗ, а участвует в его разработке, то тогда, естественно, он тоже несёт свою долю ответственности за логику программы. Если же он просто исполнитель/кодер, то тут его ошибками могут быть только чисто программистские "ляпы", и здесь всё будет зависеть от организации контроля качества как на стадии кодирования, так и на стадии тестирования / испытаний.

пацак:
Разве программа вдруг "дала газ"?
Что не сообразила, что никто взлетать и не собирался? А как тогда должен был компьютер эту ситуацию классифицировать? Как такой "use case" обозвать? "Разгон на пробеге"? Чем он отличается от попытки взлететь по тем или иным причинам? Где здесь чёткая грань, чёткие признаки на основе которых можно выработать алгоритм и написать программу? Это, мне кажется, очень даже не просто, и думать тут не одному человеку и не один день.

Что вывело левый двигатель на режим, мы вряд ли когда узнаем. Гораздо проще все на летчиков свалить.
И вообще что это за программа, которая взлет от пробега на посадке не может отличить. Четкая грань на земле это перекладка реверса , после чего программа о неготовности самолета к взлету должна успокоиться и заблокироваться до введения новых данных о полете.Чем не грань?

Дима Володин:
Что касается „как учат лётчиков иномарок” — Вы действительно уверены, что ВП выполнял процедуру так, „как учат лётчиков иномарок”? Потому как МАК в отчёте несколько другого мнения [опять цитаточка. а что делать, если оппоненты сами документ толком не читают]:

Вместо того, чтобы выяснить причину срабатывания сигнализации, экипаж выполняет достаточно длительные действия по очистке экрана ECAM, нажимая на кнопку CLR и RCL

[конец цитаты]

Как же так? Или Вы систему обучения „летчиков иномарок” лучше знаете, и их действительно учат тупо сброс жать на дисплее, а не причину срабатывания сигнализации выяснять?

У меня товарищ летает на А-320. Я сильно интересовался, как их учат действовать, когда срабатывает "Маster Caution" и ECAM выдает сообщения. Так вот ПАУ(PF) дает команду ПКУ(PNF): Выполнить ECAM. После чего PNF читает вслух сообщения и выполняет рекомендации. Если нужно, лезет в QRH. Если сообщения ECAM нелогичные как в этом случае, естественно пилот в недоумении и требуется время понять в чем собственно дело. Мы можем сколько угодно умствовать и разбираться тут часами, но на пробеге все решают секунды... Я еще раз повторю, не сразу, но они схватили ситуацию и принято было верное решение выключить двигатели...

Дим, ну дай бог тебе в такой ступор никогда не попасть, не говори гоп... А то у тебя на клаве всё очень складно получается , а будь ты в той кабине(не дай бог) - Не факт что справился бы...

Admin:
Рекомендую
http://www.forumavia.ru/a.php? ...

Там бы запретить всем писать кроме Олежки....
Вот был бы театр одного актера.......
(ЗЫ) Ну и запретить Олежке писать в другое эхи, кроме выделенных :))
А на выделенных клеймо ставить... "idiots permitted".

нормальная программа.
1)все случаи физически предусмотреть невозможно, поэтому защита от дурака поставлена в самых логичных местах. думаю ни тем кто писал тз ни тем кто проектировал систему такой случай и в голову придти немог.
2)прекрасно. а теперь представим себе что такиеже уникумы переложат один двигатель на реверс на взлете. и получим теже яйца. тут действительно нет четкой границы поэтому кодеры и предусмотрели стандартные процедуры - взлет посадка тач анд го.
3)при написании подобных программ подразумевается что с ней будет работать не дятел, а человек знающий как ей пользоваться. поэтому ставить защиту от дурака на каждый случай не нужно а кроме того долго, сложно и дорого.

пацак:
будет зависеть от организации контроля качества как на стадии кодирования, так и на стадии тестирования / испытаний.

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

Ну ну:
пилот в недоумении и требуется время понять в чем собственно дело. Мы можем сколько угодно умствовать и разбираться тут часами, но на пробеге все решают секунды... Я еще раз повторю, не сразу, но они схватили ситуацию и принято было верное решение выключить двигатели...

Вы читали отчет МАКа ?
Может тогда Вам стоило написать о десятках секунд ?
В течении которых квс держал машину на полосе, а второй игрался в тетрис.....
Простите Вы знаете что означает CLR+RCL ? Это тетрис чистой воды, очистка и перезапуск ECAM....
Тетрис и не работа.
Схватил ситацию (пользясь Вашей терминологией) квс за 7 (СЕМЬ !!!) секунд грубо говоря до забора, и куда ...схватил и кинул в воздух.....
Согласно регистратору в забор вошли с работающими двигателями.

ТО Australicus:
програмиисту ничео не нужно понимать. ему как и компьютеру глубоко пофиг летает это ездит или ползает. у него есть набор данных на входе из которого он должен сформировать набор данных на выходе. все это прописывается в ТЗ которое пишет не он а заказчик и теже пилоты.

Вот именно, только ТЗ пишет постановшик, а пилоты выразить что им нужно понятными для постановщика категориями не могут.
Уж поверьте, три моих крайних проекта в аэропорту поставленные и собранные с нуля, уже имеют 6 серьезных правок... шесть!
Полгода, год и заказчик считает что то, что он выразил год назад было неверно истолковано :) А он целый год этим не пользовался так ? ;)
Это было бы смешно, но поверьте.. как не напишите программу, конечный пользователь найдет возможность поставить ее в интересную позицию.....
Отсюда и разговор, Пилоты в кабине это не придатки компьютера, а Боги для этой железяки. (захотят выключат). Почему в некоторых случаях это не так.... вот вопрос....
Я уже говорил неоднократно, повторюсь и пусть в меня кидают камнями опять....
в одном из штатов Ау (NSW) для получения права вождения автобуса надо насидеть за рулем машины около 5000 (ПЯТИ ТЫСЯЧ) часов.....
Сколько надо навоза на певого пайлота не скажу - да и не знаю, у всех компаний свои критерии, но летчика ВВС (Королевских) с тысячами часами налета на копайлота для 737/320 ну никак не берут....

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

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

Ну ну, и надо думать, что экипаж F-OGYP именно так и действовал — PF дал команду, PNF стал читать ECAM и выполнять действия? А МАК следы их работы по технологии скрывает? Но Вы–то лучше знаете, что происходило на борту?

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

Боже мой, да Володин, по-моему, схлопотал маниакальный синдром на этой катастрофе. Просто жуть.

http://www.youtube.com/watch?v ...
Подюорка авиакатастроф. На предпоследнем эпизоже у самолёта отрывается хвост как на Ту-154 в фильме Экипаж.

2 пацак

никто - по крайней мере я - баллонов на программеров не катит. Программа работала в соответствии с техзаданием, крое выдали спецы в предметной области - самолетостроении.

Вина чисто их. Насчет того что "все предусмотреть нельзя" - х..ня. Эрбас знал о возможности "самопроизвольного и бесконтрольного" перемещения РУД, но вместо того чтобы переписать ПО разослал цыдулю на места. Т.е прикрыл задницу бумажкой.

Australicus:

...но летчика ВВС (Королевских) с тысячами часами налета на копайлота для 737/320 ну никак не берут


Кстати, на речку в Н-Йорке посадил бывший лётчик ВВС.
И КВС того "корейца", которого завалили на Дальнем Востоке - тоже из ВВС.
А в Израиле поголовно все пилоты ГА из ВВС.
Это то, что пришло на ум, не прибегая к своему архиву.
Так что ...

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

Господа хорошие, а попробуйте вместо того, чтобы какашками кидаться, взять да совместными усилиями подработать возможные изменения в работу бортового компьютера!
Ведь у каждого, кто летает даже другом, на "своем" типе, есть не только представление о реальных потребностях в участии компьютера в управлении конкретным самолетом, но и пожелания к неким общим принципам "компьютеризации": куда по вашему надо вмешиваться, а куда нет.
И какие должны быть "комплекты"? Если уж одна часть часть операций под контролем компьютера, то какая непременно должна быть под его контролем тоже, поскольку пилот расчитывает, что "сказав А, компьютер скажет Б", а не ё-к-л-м-н!
Дело в том, что человек, получив в руки такого помощника, как компьютер, довольно быстро (не то, чтобы привыкает) включает его в технологию работы не только по предписанным правилам, но и интуитивно расчитывая на его адекватное участие (точно так же, как КВС внутренне полагается на опытного второго пилота, даже не делая себе поблажек в работе).
Четкое представление о том, где компьютер помощник, а где нет, не всегда поможет в случае развития нештатной ситуации. Эти ситуации компьютер распознать не может, поскольку фантазии разработчиков на такое сочетание действующих факторов не хватило, да и пилот тоже может столкнуться с этим впервые. Вот тут-то и важно понять, угадать, если хотите, что можно и нужно доверить компьютеру, а что оставить летчику. Какой вид подсказки уменьшит дефицит времени на принятие решения, а какой наоборот - увеличит. Логика в такой связке должна быть настолько понятной, чтобы пилот не ломал голову над тем, что там ему сообщает компьютер в связи с возникшей ситуацией и имеет ли это сообщение отношение к возникшей проблеме вообще. Тем более отвлекаться на диалог с инфосистемой. Пусть это будут секунды, но и их может не хватить.
Принципы управления, вроде бы, одинаковые, а конструкторские школы, традиции и среда разные. Вспомните, даже "импортная" индикация авиагоризонта другая, хотя тоже показывает взаимное расположение самолета и горизонта.

tapi:

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

tapi, ну да, ну да. Эрбас с Боингом и прочими Ханивелами годы времени и миллионы денег на это тратят, а местные господа хорошие ща побыренькому так накидают ТЗ для бортовой автоматизации и информационного обеспечения.

2 tapi

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

Вот ткнет летчик кнопку GO тогда пусть летит на здоровье.

vladchan, а откуда автоматике знать — непроизвольно и бесконтрольно пилот ту кнопку нажал или действительно имел в виду на взлёт идти?

Голосовое оповещение, чего тоже в этой системе отсутствует

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

Ты русская ебздык понимать или как?

попробую по английски voice annunciator

vladchan, ага. Система скажет чего–нибудь типа „go around initiated”, КВС спросит: „Что такое?”, правак ответит: „go around сказала”, — и начнёт жать на CLR+RCL на ECAMе.

vladchan, а чем голосовое оповещение лучше того табло, которое пилоты и так увидели? Ну продублировалась бы информация, так они её и так приняли. Только вот не поняли.

Хе, мы тут тоже, похоже, дублируем :-)

На экране было написано "Flaps not in t.o. config, slats not in t.o. config, pitch trim not in t.o. range"

А самой главной информации что у них врубился режим взлета у них и не было.

Видишь ли Дима, игнорировать сообщение о том что включился Go around будет только очень большой чудак, типа тебя.

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

Дима Володин:
Ну ну, и надо думать, что экипаж F-OGYP именно так и действовал — PF дал команду, PNF стал читать ECAM и выполнять действия? А МАК следы их работы по технологии скрывает? Но Вы–то лучше знаете, что происходило на борту?

Откуда мне знать что происходило на том борту. Материалы самописцев недоступны для меня. Информацию собираю по клочкам здесь. На основании моего личного опыта 16-ти лет работы в авиации предполагаю что версия МАК о непреднамеренном движении РУД пилотом 3-ех этапно до 59% в течение 16-ти сек. и необнаружение этого экипажем, шита белыми нитками. Вот и все что хочу сказать. Зацепило то, что в очередной раз нашли крайних, свалили всю вину на них и успокоились. Так проще, закрыл глаза на проблему, и живи дальше пока на те же грабли не наступишь. Мы попытались рассмотреть проблему в комплексе, максимально объективно. На основании информации полученной здесь можно сделать выводы:
1) Вдвоем летать непросто, а в нештатной ситуации получается что на пределе возможностей человека.
2)К работе вдвоем пилот должен быть готов не только по знаниям и навыкам, но и психологически заряженным на точнейшее выполнение требований технологии работы и взаимодействия экипажа (SOP), шаг влево шаг вправо нельзя.
3)Работая с программным обеспечением пилоту необходимо быть психологически готовым к нелогичным закидонам этого обеспечения
4) MEL нарушает границу безопасности полетов, если им пользоваться бездумно как индульгенцией.

vladchan, а расскажите нам, что я где игнорировал. А то мне уже скучно пересказыать отчёт МАК про как правак на F-OGYP проигнорировал _все_ (а не одно) свидетельства того, что ероплан был выведен из конфигурации на пробеге. И как он стал после этого жать неотносящиеся к делу кнопки.

Программист свою работу сделал: программа работает. А вот кто поставил ему задачу на программирование именно таких действий и в таком порядке?

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

А как тогда должен был компьютер эту ситуацию классифицировать? Как такой "use case" обозвать?

вот не надо только ля-ля про такой "use case". Чай не игрушки со стрелялками программируете. Делаешь элементарный контроль по ДВУМ рудам, а не одному. Можно в лучших традициях Виндоус спросить- пилот, а ты уверен, что ты собираешься взлетать? Убрать спойлера?

Ну ну, плохо собираете, не научили Вас, видать, эти 16 лет работать с информацией по специальности. Тут уже несколько раз был указан первоисточник этих клочков: http://makfree.mak.ru/russian/ ... В котором первоисточнике подробно расписано, как правак клал с пробором на все эти технологии с обучением, а КВС и не переживал по этому поводу.

Ну ну, ну вот в Мадриде в августе автоматика и не вмешивалась на взлёте. 154 трупа.

вранье, в Мадриде как раз и был отложенный по МЕЛу отказ какого-то теплового датчика. И пилот 2 раза отказывался взлетать из-за этого дефекта. А что именно там техник отключил, и какие последствия это сыграло на выпуск закрылков - дело очень темное. Пока не было никакой достоверной информации.

тестер - враг программиста, говно ты, а не тестер. Учи, сцуко, матчасть: http://www.fomento.es/MFOM/LAN ...

Перемещение РУД левого двигателя в положение более 10º (по лимбу), в соответствии с заложенной логикой работы, вызвало автоматическую уборку спойлеров, что совпало с моментом достижения максимальной тяги реверса правого двигателя. Уборка спойлеров привела к отключению режима автоматического торможения.
...........

В 22ч 44мин 21с экипаж (наиболее вероятно второй пилот) попытался повторно применить реверс правого двигателя, для чего перевел РУР двигателя на максимальную обратную тягу, однако, в соответствии с конструкцией системы, нахождение РУД левого двигателя на режиме выше 22° по лимбу (более 55° по FDR) вызвало срабатывание блокировки и створки реверса не снялись с замков убранного положения. Правый двигатель остался на прямой тяге малого газа.

кто ж такое программирует???

тестер - враг программиста, где ты там, придурок, программы нашёл в блокировке реверса?

Дима Вoлодин:

tapi, ну да, ну да. Эрбас с Боингом и прочими Ханивелами годы времени и миллионы денег на это тратят, а местные господа хорошие ща побыренькому так накидают ТЗ для бортовой автоматизации и информационного обеспечения.

Да, фирмы серьезные, но возводить их в ранг богов? И там работают там люди. Причем, люди, которые в разработке и производстве учитывают параметр стоимости изделия в условиях конкурентного рынка. Они стремятся получить продукт хороший, надежный, но в определенных пределах и по разумной цене. Есть такой принцип: лучшее - враг хорошего. Он, в частности, относится к моменту проектирования самолета. За время работы над конструкцией планера могут произойти изменения в производстве его "начинки". Можно бесконечно долго перепроектировать самолет под нечто лучшее. Надо вовремя остановиться. Но понимать, что с момента запуска модели в серию она может оказаться уже не "супер-пупер". При этом, как верно подметил "тестер - враг программиста": "Программисты, которые писали клд доя А320 скорее всего давным-давно там не работают, экспертов по старым программам днем со огнем не найти." По меньшей мере наивно полагать, что появляющиеся в процессе эксплуатации недостатки программы (если только они не относятся к ошибкам программирования) будут немедленно учитываться и исправляться. Да и то, может наступить момент, когда проблемы со "старым" компьютером будут решаться всего лишь появлением указания: впредь им в таком-то режиме не пользоваться или присылкой "патча", блокирующего "провинившуюся" функцию.
Не надо столь высокомерно и презрительно относиться к своим коллегам! И передергивать все сказанное на свой манер.
Никто не говорит о том, что здесь "побыренькому(?) так накидают..." ТЗ.
Ценность практического опыта коллег не сравнить с высокооплачиваемыми раздумьями составителей ТЗ по поводу потребностей пилота в различных ситуациях и своих возможностях их реализовать. Если бы перечисленные производители самолетного ПО знали о возможности расширить свой кругозор потребностей пилотов в функциях ПО, они бы с радостью посадили человека вычитывать все замечания и предложения, чтобы иметь возможность реализовать их у себя.

tapi, а мужики–то и не знают…

Симмеры-ламмеры ужо 8 страницу доканчивают. В отчёте всё подробно разжёвано, когда-зачем и почему, нет бляха-муха будут всякую чушь пороть. Даже РЕВЕРС не встревает. Все эти прибамбасы в виде вычислителей и автоматики лишь дополняют человека и помогают ему работать. Замкнуло мозги, и никакой компьютер не поможет. Даже беспилотником человек управляет.

Иногда возникает ощущение, что дискуссия на этой ветке отражает ТЗ на программирование.
Единственный внятный критерий: узнать правду.
А вот из каких этапов она состоит?
Правда о способнотях автоматики адекватно помочь пилоту в стрессовой ситуации?
Правда о перечне решаемых ею задач и полноте их решения?
Правда о способности пилота в стрессовый момент взаимодействовать с автоматикой и понимать ее сообщения?
Правда о необходимом уровне подготовки пилота для обеспечения скорости взаимодействия с автоматикой?
Правда об "особенностях национального восприятия" взаимодействия с автоматикой?
Правда о причинах вмешательства автоматики в конкретной ситуации?
Правда о причинах действий пилотов, загнавших автоматику в режим действий, зафиксированный регистратором?
Правда о том, почему непреднамеренные действия пилота могут повториться подряд ТРИЖДЫ?
Правда о том, почему летчик (ИМХО вполне возможно) в подобной аварийной ситуации думает не столько об остановке самолета путем немедленного выключения двигателей, сколько о последствиях того, с какой "колокольни" будут расценивать его действия в АК, если он встанет на ВПП или окажется на БПБ?
Правда о том, насколько "обросший" отложенными неисправностями самолет воздействует на психику экипажа в течение пятичасового полета ожиданием "еще чего-нибудь"?
Правда о том, как отличается уровень жизни пилотов в сранах, эксплуатирующих ВС иностранного производства, и условия предполетного отдыха?

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

Не буду комментировать прочитанное здесь, поскольку не занимался анализом приведенных фактов и их точностью. Возможно, среди вас есть знающие эту тему лучше.
http://www.avicopress.ru/books ...