1 марта 2012 в 16:20

Алгоритмическая ошибка привела к аварии самолёта из песочницы

Недавно, 19 декабря 2011г, Австралийское бюро по безопасности на транспорте выпустило отчёт об авиационном происшествии с самолётом А-330 (б/н VH-QPA) авиакомпании Qantas, которое произошло 7 октября 2008г.

image
(фотография Stefan Roesh planepictures.net)

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

История полёта


7 октября 2008г. самолёт с 303 пассажирами на борту выполнял рейс Qantas72 Singapore — Perth, Western Australia. Полёт проходил в дневное время, в ясную погоду.

Через 3 часа после взлёта, когда самолёт находился в крейсерском полёте, неожиданно сработало автоматическое отключение автопилота, на табло стали появляться различные аварийные сообщения, одновременно срабатывали сирены сваливания и превышения скорости, на экране капитана стали отображаться нереальные параметры полёта.
Через 5 минут после отключения автопилота, когда капитан пытался разобраться с ситуацией, самолёт неожиданно перешёл в пикирование, достигнув значения тангажа в 8.4 градуса. Пилот сразу же потянул ручку на себя, чтобы исправить положение. Вертикальная перегрузка при этом достигала 1.5g в обоих направлениях. Многие пассажиры в этот момент были не пристёгнуты, и их швырнуло в потолок. Ещё через 3 минуты ситуация повторилась, но с меньшей амплитудой.

Командир принял решение посадить самолёт в ближайшем аэропорту. Определить причину отказов на борту не удалось, остаток полёта командир пилотировал самолёт в режиме альтернативного управления (alternate law), ориентируясь по резервным индикаторам. Дальнейший полёт прошёл без происшествий, самолёт произвёл посадку в аэропорту Learmonth.

В результате инцидента 119 пассажиров/членов экипажа получили ранения, из них 12 тяжёлые.


анимация события

imageimage
повреждения в салоне

Расследование


Самолёт А-330, как и любой другой современный лайнер, имеет электродистанционную систему управления. Непосредственное управление осуществляется бортовым компьютером, который получает сигналы по проводам. Для обеспечения должного уровня безопасности на самолёте установлено три компьютера (FCPC). Компьютеры, в свою очередь, получают данные от трёх инерциально-навигационных систем (ADIRU).

image

Для предупреждения выхода самолёта за критические режимы полёта, в нём существует автоматическая защита от выхода на критические углы атаки, а также защита от аэродинамического кабрирования на высоких числах Маха. При их срабатывании, самолёт автоматически переводится на пикирование и не слушается ручки управления в течение 2с. Срабатывание одной из этих защит и стало непосредственной причиной резкого уменьшения тангажа в полёте. Следствием были демонтированы и изучены модули ADIRU LTN-101 от Northrop Grumman Corporation и модули FCPC производства Airbus.

В результате изучения информации с бортовых самописцев было установлено, что одна из ADIRU периодически выдавала резкие скачки по нескольким параметрам, в частности по углу атаки и числу М. После проведения испытаний было выяснено, что в ADIRU произошёл аппаратный сбой в процессоре Intel, наиболее вероятно, из-за производственного брака. Сбой выражался в том, что вместо, к примеру, угла атаки, выдавалось значение высоты и т.д. Более точно природу сбоя определить не удалось.
Однако, по действующим стандартам, сбой в одной из систем самолёта никак не должен приводить к аварийным последствиям. Как же получилось, что бортовой компьютер «проглотил» неверное значение угла атаки и выдал команду на пикирование?

Ниже представлена блок-схема алгоритма обработки угла атаки (АОА):

image

Для вычисления угла атаки используется среднее значение с двух сенсоров АОА1 и АОА2. Если значение сильно отличается от среднего, алгоритм использует крайнее валидное значение на протяжении 1.2 секунды. Если на протяжении секунды ситуация не меняется – этот вход отключается и больше не используется. Ниже показаны возможные сценарии с отклонениями параметров.

image

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

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

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

Комментарии (161)

  • +2
    Вот поэтому от инженеров, программистов и главное от сборщиков зависят жизни людей. Надо быть внимательней в работе.
    • +15
      К сожалению реальность чаще звучит «взлетаем, вчера, хоть как-нибудь, проект должен быть уже сдан». Надеюсь, в авиации такого менеджмента нет :)
      • +5
        там очень ЖЕСТКИЕ test case. Но, иногда код подгоняют к test case.
        • 0
          Так вроде так и должно быть.
          Test case — это эталон, которому должен соотвествовать код. Нет?
          • +12
            Test case — это частный случай, один из или несколько из, но не все возможные ситуации.
          • +4
            Разберем на примере: есть у нас какой-нибудь массив, и есть к нему тест кейс, что при добавлении нового элемента размер массива увеличивается на единицу, подгоняя его под тест можем дойти до такого кода:

            def add(element) {
                size++;
            }
            <pre>
            
            Тест кейс проходит на ура, но от реальности далековато.
            • +4
              Это называется плохое покрытие.
              То есть покрыт побочный функционал, но главный не покрыт.
              Естественно, абсолютно все не покроешь, но все ключевые моменты должны быть оттестированы.
              • +3
                Покрытие, я уверяю вас, тут будет 100%. Тут дело в том, что данный код, подогнан под данный тест кейс и точка.

                Уверяю вас, что в разработке случается такое, когда некоторые личности, несмотря на то, что на один и тот же юнит (класс\метод\строчку кода и т.д) могут быть десятки тест кейсов, все равно умудряются подогнать кусок кода для того, что бы он проходил тесты.

                В итоге получаем 100500 тест кейсов, близкое к 100% покрытие кода, но открываешь некоторые методы и от ужасаешься от количества костылей. А некоторые еще и с комментариями // for blaBlabalaBlablabla test
                • +12
                  нет, проблема в том, что нет второго тест кейса.

                  Вот обратите внимание:
                  — формулировка задачи: «нужно сделать добавление элемента в массив»
                  — тест-кейс: «при добавлении элемента длина массива увеличится на единицу».

                  Видите разницу?
                  Там обязательно должен быть тест на то, что этот элемент попал в массив, а вместо этого проверяется увеличение длины.

                  Вот за это мне нравится схема BDD и записи как в том же RSpec или Cucumber.
                  Вы описываете задачу почти на русском языке и это становится тестом. Здесь сразу было бы видно, что написана фигня, не имеющая отношения к делу.
                  • +2
                    думаю, что проблема в том, что для реальной задачи (сложнее, чем добавление элемента в массив) не так-то просто подобрать все возможные тест-кейсы. Закрадется какой-нибудь маленький нюанс, который просто никому не придет в голову, и ни описание на человеческом языке, ни проверки другими специалистами ничего не выявят, пока не случится реальность.
                    • –1
                      Для самых критических систем вам еще нужно будет собрать покрытие кода по MC/DC. Это снижает вероятность вами описанного практически до нуля.
                      • 0
                        Вот это практическивсегда остается, и чем сложнее система, тем оно шире.
                • +1
                  Разработка авиационного софта не допускает таких выкрутасов. Изменение кода будет проверено как минимум еще 1-2 инженерами, которые будут проверять только соотвествие кода требованиям, но не тесту. Если код не будет соответсвовать требованиям — он не пройдет. Если будут изменены требования, то в процесс ревью будут втянуты как минимум еще 2 человека: специалист по верификации и специалист по безопасности.
                  • 0
                    Никто с этим не спорит. Думаю, что в боинге или аирбасе такое вряд ли допустимо, там на каждом уровне перепроверяют все раз по двадцать. Да и менеджера нет который подбегает и кричит: «Бросай все, тут надо вот заплить XXX еще вчера надо было, ты почему с работы вообще вовремя ушел?! Запиливай давай прямо сейчас».
                    • 0
                      Такое есть везде:)
                      Просто в боинге и аэрбасе нельзя ничего запилить втихаря — все равно это должно пройти полный цикл проверок.
                  • +2
                    Может немного не в тему, но мне вспомнился один анекдот:

                    Преподаватель студентам-программистам:
                    — Код программы надо писать так, чтобы не бояться за его работоспособность. Представьте, что вы разработали систему автопилота самолета. Проходит некоторое время и вы собираетесь лететь в другой город. Садитесь в самолет, выходит стюардесса и объявляет, что этот самолет оборудован новейшей системой автопилота, разработанной компанией %company_name%. Вы понимаете, что это ВЫ ее писали. Какова будет ваша реакция?

                    Все в аудитории, кроме одного парня, сказали, что откажутся лететь на этом самолете и немедленно покинут борт самолета.
                    Только один парень сказал, что останется. Потому что, если систему писал именно он, то самолет вообще с места не тронется и бояться нечего.
                    • +2
                      А я бы с удовольствием полетал бы на тех самолетах, руку к которым приложил.
                      • +1
                        Особенно если разработка еще продолжается. Почувствовать, как система ведет себя «в поле», понять, во что реально воплотилось запрограммированное поведение, а заодно и попытаться угадать, какие куски кода сейчас работают, и что и почему они делают — должно быть интересно.
                        Правда, когда я смотрел фильм, про который было известно, что в создании использовался наш сканер, то почти не следил за сюжетом, а пытался увидеть характерные артефакты на элементах пейзажа. Не увидел — художники поработали хорошо :)
                      • 0
                        Я всё же предпочитаю использовать для этих целей тренажёры )
                    • 0
                      кусок анекдота:
                      Повар: я всегда пробую все новые блюда первый.
                      Архитектор мостов: я всегда стою под мостом когда по нему первый раз едет поезд.
                      Программист: нууу, я могу рядом постоять…
          • +1
            Представьте, что у Вас написана уйма тест кейсов. Затем Вы начинаете генерировать случайные строки текста до тех пор пока одна из них не скомпилируется в программу, которая пройдет все Ваши тесты.

            Представляете что оно Вам там нагенерит? Осмелитесь ли Вы сесть в самолет, в который «зашита» такая программа?
            • +3
              2 варианта:
              — тесты предусматривают действительно 100% покрытие всех ситуаций — что нереально — но можно безопасно садиться в самолет
              — нет, потому что там халтура.
              • 0
                Это реально.
            • +1
              А давайте я чуть по-другому сформулирую. У нас есть тест-кейсы, которые описывают все возможные ситуации, которые могут произойти, и то, что должно происходить при них, а потом constraint solver генерирует код, удовлетворяющий этим параметрам. Почему бы и нет?
              • 0
                Конечно, для задач с конечным множеством решений это можно проделать. А вот какую-нибудь непрерывную функцию Вы же не покроете всю тестами.
                • +2
                  «Тестами». Constraint solver не будет хорошо работать на тестах с фиксированными данными; ему нужны параметрические тесты ≅ уравнения, которыми непрерывную функцию задать элементарно.
      • 0
        Есть, только звучит чуть иначе: «Всю ночь кормить — утром зарезать».
      • +4
        Участвую в разработке софта для авиации. Ваш комментарий веселит меня и печалит одновременно.
        • 0
          Можете рассказать, как происходит контроль безотказности, отказоустойчивости и других простых и комплексных показателей надежности?
          • +1
            Ничего сверхъестественного.
            Требования описывают поведение системы в нештатных ситуациях. Инженеры групп верификации пишут миллион тест кейсов по ним. Пишутся тесты для нештатной нагрузки, прогоняются сначала на эмуляторе, потом на реальном железе. Реальное железо при этом тоже находится под управлением виртуальной машины, ибо самолет нам никто не даст.
            Слабых мест достаточно: на что-то не было требования, какое-то требование неполно покрылось тестами, какие-то тесты проседают от недостатка соответствия окружения реальному железу. Поверьте, сертификация действительно весьма сурова, но сроки срываются сплошь и рядом.
      • +4
    • +3
      А учитывая, что программный код имеет тенденцию быть использованным бесчестное количество раз и, будучи написанным единожды, может всплыть в абсолютно неожиданных проектах, быдлокодерство даже в самой завалящей никому-не-нужной-кроме-нашей-фирмы программе это преступление.
      • +1
        *бессчётное
      • НЛО прилетело и опубликовало эту надпись здесь
        • +2
          Ух ты. Комикс, в котором Уолли работает.
          • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Видимо, здесь и заработал бабки, чтобы потом не работать.
      • 0
        Реюз кода в авионике это нормально: считается (и абсолютно заслуженно), что код, имеющий большое количество часов налета, безопаснее полностью нового. Другое дело, что реюз должен быть крайне аккуратным
    • +4
      На это есть класс софта (точнее систем), называемый life-critical (навигация, реанимация, аэс и аналогичные), к которому подпускаются только команды уровней эдак CMM4-CMM5.

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

      Если это про.б команды уровня CMM5, то казнить либо сертификатора, давшего недакватный уровень команде, либо ответственных на строне подрядчика, сфальсифицировавших сертификацию в придачу к «преступной халатности».

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

      Виновный (не крайний) всегда существует.

      Но это всё касается life-critical.

      Остальные системы не так опасны и там можно применять прогрессивные методици разработки ;-)
    • +3
      Преподователь в университете не уставал нам повторять «вот потеряете вы байт и все, упал самолет». Задумался.
    • +2
      И зарплату платить не как дворникам в мск…
  • –1
    Управление компьютером может быть вдвойне ненадежным, потому что программу пишет человек или группа людей. Это если говорить о «классическом» программировании. В ответственных применениях программное обеспечение верифицируется с помощью специальных математических средств. Но, к сожалению, пока не всегда есть возможность использовать верификацию, а иногда и просто невозможно.
    • +1
      Верифицировать можно не только при помощи математических средств.
      Есть несколько стандартов, которые помогают при помощи различных мер снизить интенсивность отказов до некоторого определенного значения.
      • –2
        Да, возможно. Но для программного обеспечения, используемого в ответственных применениях, недопустимо иметь шанс отказа, по крайней мере в программе. Она либо работает, либо нет. А использование отладки или других подходов/стандартов показывает наличие ошибок, а не их отсутствие.
        • +3
          Не бывает продуктов без ошибок :)
          Вопрос тут в допустимом и недопустимом риске. Если отказала программа — плохо, но не страшно, если не привело к страшным последствиям.
          Есть целое направление, в котором исследуются подобные вопросы — функциональная безопасность. Основная идея в том, что мы не можем сделать абсолютно надежный продукт, но можем снизить интенсивность отказов до определенного уровня (не абстрактного, а заданного в самом начале создания продукта) при помощи конкретного набора мер.
          • –3
            Продуктов без ошибок не бывает, так это комплексное устройство (если мы говорим о электронном изделии). А программы без ошибок бывают. Еще раз скажу, что если мы говорим в контексте «классического» программирования, где постоянно отлавливаем ошибки в приложении — тут да, можно каких угодно вероятностей насчитать. Но если говорим о логическом управлении — тут ошибок не должно быть. Например, сейчас активно развивается направление автоматного программирования, для которого существуют различные методики верификации.
            • +1
              > Но если говорим о логическом управлении — тут ошибок не должно быть

              А как это можно подтвердить, что нет ошибок? :)
              К тому же — они все равно будут. Есть занятная работа у QXN про гейзенбаги, где утверждается, что когда несколько потоков работает, программа (на практике) получается недетерминированной. Теоретически, доказать отсутствие ошибок можно, но на практике — маловероятно.
              • –1
                В автоматном программировании это подтверждается с помощью верифицирующего инструмента на основе заданной спецификации.
                • 0
                  Про автоматное программирование не изучал. А можете кинуть пример верифицирующего инструмента?
                  • –2
                    Вот здесь is.ifmo.ru/verification/ можно почитать на эту тему.
                  • –1
                    en.wikipedia.org/wiki/List_of_model_checking_tools — вот достаточно полный список средств верификации, на мой взгляд

                    навскидку,
                    http://spinroot.com — тут можете писать модели на c-подобном языке, и проверять их корректность. в принципе, ничего вам не мешает рассматривать потом эти модели как программы, и просто запускать их

                    http://research.microsoft.com/en-us/projects/slam — используемое в Микрософте средство верификации драйверов

                    http://www.prismmodelchecker.org — верификация вероятностных моделей. можете попробовать закодировать там вероятностный протокол (например, Zeroconf или CSMA-CA) и проверить его корректность

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

                    и да, за каждым из этих средств стоит много-много теории :)
                  • 0
                    система спин например.
                    наса ее юзает с небольшой доработкой по слухам.
                    есть еще куча подобных штук
                • 0
                  Это доказывается для машины тьюринга? А как быть для реального компьютера, где ячейка памяти может поменять бит? Или сбой вычислений из-за того, что в корпус самолета ударила молния?
              • +1
                Можете найти мне эту работу? Было бы интересно почитать.
              • –1
                Есть способ устранения таких проблем — полное исключение общей памяти (чтобы процессы не могли портить данные другу), стандартизированные способы коммуникаций между процессами (чтобы не передать управление в случайную точку процедуры), отсутствие побочных эффектов функций (исключение ситуации гонки).
                Это реализовано в Erlang`e — в итоге миллионы процессов работают параллельно, управляют сложными системами с аптаймом 99.999999999%.
                • +3
                  Чёт вы явно с девятками пошутили. Каждая девятка увеличивает стоимость системы раз в пять-десять. Да и то ваш животворящий ерланг не вытянет надёжность целой системы выше надёжности рейда или хаба, в некоторых находящихся вне зоны полномочий ответственных за систему, но влияющих на неё.
                  • 0
                    Да, перестарался с девятками :)
                    их всего 99.9999999% :)
                • НЛО прилетело и опубликовало эту надпись здесь
                  • 0
                    У вас хорошо получается. Не думали заняться переводами?
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • 0
                        Я имел в виду переводами комиксов, для души :-)
                • 0
                  Впервые слышу об измерении времени (аптайма) в процентах. Возникает вопрос: в процентах от чего?
                  • 0
                    У хостеров публичная информация о надёжности их сервиса предоставлена в таких единицах. Предполагается, что система должна работать бесперебойно (в отношении хостинг-серверов так и есть), соответственно, процент показывает, насколько хорошо это предположение удалось воплотить.
                    • 0
                      Тогда это должно называться относительным или средним аптаймом. Странно, что термин используют сразу в двух разных значениях.
                  • 0
                    В % от общего времени работы.
                    Вот работала у вас железяка из 100 минут ровно 99 — значит аптайм 99%.

                    Если вы скажете, что ваша система работала 99 часов, то это еще ни о чем не говорит — может она проработала 99 часов из 1000 — значит заказчику нужно 10 таких систем, чтобы закрыть все это время.

                    Я понимаю, откуда возник ваш вопрос — скорее всего вы привыкли видеть строку вида
                    «2:06PM up 63 days». Я говорю про аптайм — какую часть ожидаемого времени она проработала.
        • +1
          Недопустимо? Это как? Это где существуют системы с нулевой вероятностью отказа?
        • +1
          Таки допустимо. Стандарт Do-178 чётко оговаривает допустимую вероятность отказа для каждого типа систем, в том числе и программных. Собственно, чтобы снизить вероятность ошибок, используется резервирование и использование компонентов от разных производителей.
    • +3
      А как бы это помогло в данном случае? Ведь в этом случае как раз дело было в том, что проблема была в самом алгоритме, а не в реализации.
    • +1
      Подобные системы для бортовых компьютеров, как я слышал, пишутся различными компаниями на различных языках программирования, чтобы исключить пересечение ошибок. Те. вероятность ошибки (могу оказаться нубом в теорвере, сорри):
      1-(1-X1)*(1-X2)*(1-X3), где Хn — вероятность ошибки в какой-либо с систем.
      • 0
        *сорри, наоборот, Xn — вероятность отсутствия ошибки в строке кода. Грубо говоря сколько процентов кода разработчик пишет без багов.

        Например, будем считать разработчиков таких систем очень надёжными, делающими ошибки лишь в 5% кода (много это или мало?), тогда:
        1-(1-0.95)^3=0.000125 (1 ошибка на 10000 строк кода).
      • 0
        Не поверите, но в основном только C и assembler.
        • 0
          Поверю, это и слышал :). Но это уже 2 языка, может ещё что-то есть?
          • 0
            Крайне редко. Один раз видел pearl. Технология достаточно консервативна: даже C++ нежелателен на самом деле
            • 0
              Или не pearl а python. По сути это не сильно меняет расклад сил;)
              • 0
                У вас большие проблемы с двойным нажатием :).
                • 0
                  Нет, это проблемы с обновлением комментариев. Простите. У меня все сообщения ваши подгрузились по 2-3 раза.

                  В общем даже если есть 2 системы на асме и одна на С — мои расчёты верны.
            • 0
              SAAB JAS-39 Gripen запрограммирован, как я слыхал, на ADA.
  • +1
    Тут еще повезло, что без жертв, есть примеры похлеще
    • 0
      по-моему 3 катастрофы подтверждают надежность компьютера как центрального элемента управления летательным аппаратом.
      А вот вам список авиакатастроф на территории СНГ, где в 95% случаев виной есть человек
      http://www.mak.ru/russian/investigations/investigations.html

      Техника очень редко подводит, поэтому задача авиации ныне — как только возможно минимизировать участие человека в процессе управления, оставить ему лишь контролирующую роль.
    • 0
      Скандинавы забодали своим «восьминогим конём, везёщим в потустороннее царство».

      Я бы такое двусмысленное имя системам не давал, если бы они не возили туда специально по замыслу ТЗ.

      МБР назвал бы слейпниром, да.

      А они слейпниром называют чуть ли не каждое второе достижение или повозку.
  • +1
    >> Катастрофы из-за человеческого фактора происходят гораздо чаще
    Эта ошибка, вроде как, тоже из-за человеческого фактора :-)
    • +2
      Ну я имел ввиду непосредственный человеческий фактор — т.е. управление пилотом )
  • +1
    При их срабатывании, самолёт автоматически переводится на пикирование и не слушается ручки управления в течение 2с.

    Но зачем?
    • +14
      Имеет место масса случаев, когда лётчик, не следя за углом атаки, выводит самолёт на сваливание, при этом не понимая что происходит.
    • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Одно из принципиальных отличий эйрбаса от боинга в том, что в эйрбасе компьютер первичен, т.е. пилот не просто физически не может делать многие вещи — компьютер ему не даст и отключить его нельзя. В этом компьютере еще много таких «прикольных» процедур, когда пилот не в состоянии повлиять на ситуацию.
      • +3
        Это отражает общий тренд.
        Пилоты все больше летают на самолете как на симуляторе — тем самым теряют летные навыки. А значит их полет на компьютере может оказаться более безопасным.
        • +7
          Кто-то несогласен?
          Кстати, могу порекомендовать очень классный журнал — бывший военный летчик, сейчас гражданский пилот и очень хорошо пишет — читается на одном дыхании: letchikleha.livejournal.com/
          Эта фраза как раз у него взята — а он человек в теме.
          • 0
            О, знакомый ник. На фуршетах у Лебедева, по-моему, на вопросы толково отвечал.
      • 0
        Ну это понятно — слишком дорого учить пилота авиалайнера, как пилота истребителя. Когда стоимость подготовки боевого пилота чуть ли не догоняет стоимость истребителя. Ну хорошо, пусть не истребителя, но штурмовика.

        Десяток лет обучения и нехилый отсев… Слишком дорогое удовольствие ;)
      • 0
        По моему мнению это вполне оправданный подход. Управление в эйрбасе требует несколько меньшей нагрузки а экипаж.
  • –4
    Страшновато как то самолетами летать всегда было, а после таких статей и подавно.
    • +23
      А на дорогах рыщут джигиты на тазах, это даже опаснее несовершенных алгоритмов. Как страшно жить.
    • +14
      Вас должен успокаивать факт, что погибнуть, путешествуя в какой-нибудь там Египет автотранспортом, куда как вероятнее, чем при перелете самолетом.
    • 0
      Да уж, очень не хочется пробить головой потолок, багажную ячейку, или еще чего похуже.
      • +7
        Оставайтесь пристегнутым во время всего полета, а не только при взлете/посадке. Головой багажную полку можно пробить не только из-за ошибки системы, но и скажем из-за попадания в воздушную яму.
        • 0
          Там в отчёте, кстати, есть целое исследование на тему как пристёгивать ремень, на какое место и насколько туго.
          Некоторые пассажиры, несмотря на то что были пристёгнуты, умудрялись вылететь из кресла.
          • +18
            Я кстати выработал в себе привычку оставаться прстегнутым в полете, после того как прочитал "Раздумья ездового пса" Ершова.

            На юге посветлело. Фронт кончался, проглянула полоска вечерней зари, и мы приняли решение идти домой по трассе Канск — Красноярск.

            Где-то в районе Заозёрного дорогу нам ещё преграждал небольшой хвост, как раз на нашей высоте, и мы запросили снижение с 1200 до 900 м, норовя поднырнуть. Уже прямо по курсу виден был закат, и только этот хвост, южная оконечность фронта, вуаль, вроде бы ничем не угрожающая нам, тянулась на юг ещё километров на полсотни.

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

            Какой-нибудь километр пути. Десять секунд — и мы на свободе: дальше чисто, оранжевый закат на полнеба; а на севере…но мы уже убежали.

            Хорошо, что мы выработали привычку в полёте быть всегда пристёгнутыми. Самолёт выдернуло из-под нас так резко, что мелочь из незастёгнутого кармана рубашки фонтаном брызнула в потолок и разлетелась по кабине. Грузный командир пушинкой взлетел под потолок, выпустив штурвал, но удержался не слишком затянутым ремнём; я пристегнулся потуже и усидел, а вот слабо затянувший ремень бортмеханик от рывка растянул поясницу. Вдобавок ещё два амбарных замка — от входной двери и двери пилотской кабины, — болтающиеся на трубке его сиденья, сгуляли в потолок и оттуда рикошетом проехались ему по лысине. Радист не пострадал, упёршись ногами в перегородку своей тесной каморки.

            Самолёт провалился всего-то метров на пятьдесят. Акселерометра на нем не было, и не известно, какую отрицательную перегрузку выдержало его толстое крыло.

            И все. Радист сходил в салон. Пассажиры сидели очень смирно. Глаза у всех были круглые, а лица мокрые от пота и очень грязные: от броска сорвало и перевернуло панели пола, и вся грязь и пыль, взлетевшая с них, медленно оседала на лица разом взмокших людей. Парень на последнем кресле засунул руку под ремень своей подруги и до посадки не отпускал.

            Этим уже ничего насчёт ремней объяснять не надо.


            Кстати очень хорошо человек про авиацию пишет, всем рекомендую, кто не знаком.
            • +5
              >>Кстати очень хорошо человек про авиацию пишет, всем рекомендую, кто не знаком.
              Это точно. Взахлеб читал. Отлично описывает теоретическую часть, перемежжая все это историями из своей практики.
              • 0
                +1 читал с большим удовольствием. На всю жизнь запомнил понятие «Рубеж». Это граница, которую рассчитывается до взлета, не помню уже, штурман или второй пилот вычисляют. При разгоне самолета, после того, как сказано слово «Рубеж», чтобы не случилось, хоть взрыв в салоне, хоть отказ двигателя, будут взлетать, так как это означает, что для остановки полосы уже не хватит. До этого момента при ЧП будут тормозить.
                • +2
                  А это не «точка принятия решения»?
                  • 0
                    Вы, вероятно, путаете с ВПР — высота принятия решения. Такая действительно есть, но не при взлёте, а при посадке: на ВПР командир корабля обязан принять и озвучить решение — продолжать ли посадку, или уходить на второй круг.
                  • 0
                    Перед каждым взлётом рассчитываются три скорости: V1, Vr и V2. V1 — это скорость принятия решения о взлёте, как описано выше, Vr — скорость подъёма передней стойки шасси и V2 — скорость отрыва самолёта
              • +2
                Автор достаточно спорный. Пишет он, безусловно, интересно, но иногда воспевает методы работы, за которые в западных авиакомпаниях отрывают яйца.
                • +1
                  Да, но летал он еще с 60-х на советской технике и в СССР, это необходимо учитывать.
                • 0
                  Например?
                  • +2
                    Летание по интуиции, нестрогое выполнение правил, советский CRM, «профессионализм» (излишняя уверенность в собственных умениях, которая приводит к катастрофам).

                    В конце концов, насколько я помню (читал много лет назад), он пишет, что сам несколько раз чуть не попадал в катастрофу, но каждый раз проносило.
      • 0
        А я как-то пробил в детстве в тралике :) прыгали на спящем полицейском. Очнулся — надо мной люди и дырка в потолке, прям как на картинке в топике.

        Вот так я стал программистом…
    • +1
      По этому поводу есть хорошая русская пословица — волков бояться в лес не ходить :)
    • +11
      Проехать по городу на чем угодно на порядки опаснее, чем пролететь пару тысяч миль на самолете. :)
    • +1
      Это — практически уникальный случай. В подавляющем большинстве катастроф виноваты люди. И этих катастроф не так уж и много.
  • +3
    Ещё где-то читал про случай, когда бортовой компьютер неожиданно перегружался. Причина оказалась проста: при полёте в низинах, в районе уровня моря, датчик высоты иногда возвращал высоту ноль. Эта высота далее использовалась в каких-то тригонометрических вычислениях, и на неё что-то делили. Возникала ошибка деления на ноль, и система крэшилась полностью.
    • +15
      Это было на истрибителе с аппаратурой от Мотороллы в районе Мертвого моря(уровень которого ниже уровня океана), программистам просто в голову не могло прийти что истрибитель будет летать ниже уровня океана.
      • +8
        Значит хреново была поставлена задача.
        В требованиях к самолету должно было быть написано:
        — допустимый диапазон высоты полета над уровнем моря, м: от –420… до 15000
        • +12
          Все мы умные задним числом, это все равно что предположить что подводная лодка будет плавать выше уровня океана.
          • 0
            По шлюзам разве не сможет пройти? В теории?
            • 0
              Ага, еще и скрытно.
          • 0
            В озере, например, при каких-нибудь ходовых испытаниях и пр.?
          • 0
            Вобще-то нет.
            Максимальная высота полета всегда оговаривается. Почему не подумать про минимальную?
        • 0
          Не знаю, как там кто ставит задачи и пишет код, а я всегда проверяю входные данные на допустимость. Тем более, когда на входные данные нужно делить. И это я пишу банальный код для микроконтроллеров, управляющих безделушками типа сервомашинок, LCD, SD-карточки и пр. Если бы я писал жизненно важный код, у меня, пожалуй, код проверок был бы больше по объёму, чем основной.
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Это должно быть предусмотрено в требованиях
            • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Например, пуск торпед.
            • 0
              Как минимум, продолжение полёта. Естественно, я сейчас не могу сказать, чтобы именно я бы написал в такой ситуации, потому уже что знаю, что означает -100 метров.
      • 0
        Не в качетве «вот надо было сделать так», а просто для информации: существуют языки, не позволяющие делить на 0 (и не только, разумеется).
    • 0
      Какой то зарубежный истребитель.
      • +5
        Это F-16, серию не помню.

        +
        Первые версии F-22 при пересечении экватора переворачивались на спину.
        В дальнейшем F-22 не смог из САСШ в Жапонию пересечь линию дат.

        Ощущение, что в Пятногоне болезнь 21 века — «ранний релиз, фидбэк вместо альфатеста, скрам, аджайл и весь тот цирк с коняшками».
    • НЛО прилетело и опубликовало эту надпись здесь
      • +10
        Компенсируется тем, что находящиеся там люди гораздо более high, чем в среднем по миру :)
        • +1
          А для чего «высокие» по-английски написано?
          • +17
            high значит не только высокий, но ещё и укуренный.
            — К.О.
  • +1
    Да, часто при доработке проектов в режиме постоянной нехватки времени говорил коллегам что-то типа «хорошо, что мы не самолеты строим».
  • +9
    Не зря говорят всегда — не выпендривайтесь, оставайтесь пристегнутыми в течение всего полета. Часто попадаются соседи по креслу, которые демонстративно отстегивают ремень, как только гаснет табло «пристегните ремни»…
    • +7
      Они просто не могут представить, как это — их таких всех из себя и в багажную полку головой при неудачном манёвре.
  • –3
    Блок-схема и графики в JPG? Мне внезапно покажется страшным летать на современных самолётах, если так сохранил кто-то, занимающий высокие места в авиации.
    • +5
      Здесь должна быть картинка про JPG vs. PNG
      • 0
        стандартный ответ №32
  • 0
    Напросилось
    www.youtube.com/watch?v=L2zqTYgcpfg
    • 0
      Дада, это мой любимый ролик про самолёты )))
  • 0
    Устранили в новой версии прошивки? Сразу ассоциации: перепрошивка самолета, получение рута, делаем джейлбрейк, устанавливаем кастомные обои и т.д.))
    • 0
      … и нескучные лётные карты!
      • 0
        Пасьянс на EFIS :)
  • +6
    Как человек, занимающийся разработкой и верификацией авиационного софта, испытываю крайнюю степень изумления от комментариев людей, которые пытаются проецивать разработку энтерпрайз систем на разработку life-critical систем.
    Поверьте, процесс разработки этого софта гарантирует крайне высокие показатели по отказоустойчивости бортовых систем. Почему произошел этот отказ — наверное надо разбираться, хотя виновного нам не назовут, естественно.
    Могу сказать только одно: по официальным данным начиная с 90х благодаря введению квалификационных требований к процессу разработки бортового ПО ни одной аварии по вине сбоя ПО не произошло.
    • +1
      Напишите топик, было бы интересно почитать :).
      • +2
        Регулярно порываюсь, оцениваю объем и скисаю. Надо как-то себя побороть.
        • –3
          Хотите стимул? Вышлите мне пароль от банковского аккаунта, если в течении недели не напишете, то я сниму все деньги :D.

          Или просто напишите здесь «я обещаю написать статью до ...» :). Обещания мотивируют сами по себе.
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Главный докуент — DO-178B, но его вы вряд ли сможете найти в открытом доступе. Он собственно описывает цели, которые должны быть достигнуты в процессе разработки.
            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                А вот методы как таковые не описаны нигде. Это — одна из проблем компаний, которые только начинают по этому стандарту работать: там и так много бюрократии, да еще и непонятно как эту бюрократию реализовывать.
          • 0
            Недавно кстати вышел DO-178C — может сделаю над собой усилие ещё про него статейку накатаю
  • 0
    Не понимаю. О какой ошибке речь?
    Алгоритм, проверяющий данные от реальных датчиков, и принимающий решения в терминах «случайный сбой/частые сбои/вообще неисправный датчик» только на основе этих данных, по своей природе является эвристическим. Он использует какую-то оценку вероятностей тех или иных сценариев (или классов сценариев), которые смогли предусмотреть разработчики. Как и всякую эвристику, этот алгоритм можно обмануть. И даже заставить отключить исправный датчик, если неисправный его хорошо обдурит своими данными. Эвристический алгоритм может быть более или менее надежным, но абсолютно надежным он не будет. И более того, чем лучше он работает в типичных ситуациях, тем более катастрофическим будет результат, когда ситуация выходит за пределы его применимости. Так что какие тесты? Какие проверки? Они, конечно, необходимы, но описанных в статье ситуаций они не исключат. И то, что «в новой версии прошивки эта проблема была устранена», оптимизма у меня не вызывает. Потому что могла появиться другая, более вероятная ситуация, при которой новый алгоритм (являющийся, как и старый, правильным), приведет к столь же непредсказуемому поведению.
    • 0
      Напишите более полный и запостите на хабре под моим комментом. Родина Вас не забудет.
  • 0
    Это тоже человеческий фактор, просто человек не в кабине ошибся.
  • 0
    о, я не зря всегда сижу пристегнутым =)
  • 0
    Напомнило видео:
    www.youtube.com/watch?v=UZq4sZz56qM

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.