Пользователь
0,0
рейтинг
14 ноября 2013 в 19:52

Разработка → Отладка самолета? Это очень просто!

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

Сразу предупреждаю – вводная часть будет длинной, но без этого просто невозможно подойти к сути дела.

По целому ряду причин я не буду приводить названия конкретных производителей, модели самолета и прочих упомянутых в статье изделий. Если кто сможет идентифицировать самостоятельно – пожалуйста, но я здесь не при чем.

В данной статье не ставится задача дать читателю полный курс всех авиационных наук. Буду разъяснять только самое необходимое, причем чаще всего в упрощенном виде (упуская несущественные для понимания статьи детали).

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

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

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

Чтобы понять, можно ли с той или иной неисправностью эксплуатировать самолет, существует так называемый Minimum Equipment List (MEL) – документ, описывающий критичность обнаруженных неисправностей на возможность выполнения различных типов летной эксплуатации борта. Если какая-то конкретная неисправность не запрещает полностью производство полетов, то соответствующий пункт MEL описывает, какие именно ограничения накладываются на эксплуатацию самолета, и какие дополнительные меры нужно предпринять для выполнения полета (в случае с кофеваркой – повесить на нее табличку о запрете включения).

Возникает вопрос – а почему фактически неисправные самолеты вообще допускаются к полетам, ведь это опасно ?! Проблема в том, что если бы требовалась абсолютно 100% исправность, то подавляющее большинство самолетов просто вообще никогда не взлетело бы. Причем, опять таки в подавляющем большинстве случаев, MEL как раз обеспечивает необходимый уровень безопасности даже при наличии некоторых неисправностей за счет сужения допустимых диапазонов эксплуатации техники.

Рассматриваемый самолет только-только начал выпускаться, и конкретный экземпляр имеет серийный номер в первой десятке. Это значит очень много – например, то, что еще практически нет ни опыта эксплуатации, ни опыта техобслуживания, да и младенческие болезни проявятся во всей красе.

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

Мало того, это единственный из известных мне самолетов (сразу скажу – я не знаком детально с устройством последних Boeing и Airbus), на котором можно реализовать сюжет идиотского боевика о суперхакерах, которые удаленно захватили управление над самолетом. Чисто теоретически (ну очень теоретически, но все таки с какой-то степенью вероятности) возможно подключиться к бортовому WiFi (не тому, который для пассажиров, а предназначенному для некоторых служебных функций) и загрузить свою программу в блоки управления. Далее каждый может фантазировать на собственное усмотрение…

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

Итак, после пары дней изучения самолета на земле у нас сложилась какая-то картина. В принципе, летать можно. Да, найден ряд проблем, часть из которых будет исправлена в течении нескольких следующих дней, часть известна производителю и находится в работе, некоторые же вещи, похоже, потребуют принятия серьезных решений производителем и полной переделки соответствующих узлов в будущем. После подготовки самолета к полету и запуска двигателей на экране светится штук 5 информационных сообщений о разных несоответствиях тому, что, по мнению самолета, должно быть. Вообще-то кабина экипажа спроектирована по принципу “dark cockpit” – т.е. при нормальной работе всех узлов никаких сообщений вообще не должно быть, но ладно, на данном этапе это нормально.

В довершение ко всему, к самолету прилагался файл с FAQ, где объяснялось, почему неправильная работа тех или иных систем пока является совершенно нормальной, и что делать в ряде случаев, когда чтение руководства по летной эксплуатации (РЛЭ) не дает ответа на возникший вопрос. Если честно, нас всех смутило больше сотни позиций в данном FAQ, но делать было уже нечего.

Первый полет решаем сделать прямо на аэродроме, где расположен завод производителя. Взлетаем, убираем шасси и далее минут 10 выполняем команды диспетчера, прежде чем он направляет нас на посадку. После первой посадки решаем, что в целях экономии времени уйдем на соседний аэродром, где движение посвободнее. Перелетаем туда и начинаем процесс освоения самолета. После того, как все пилоты попробовали основные маневры под руководством летчика-испытателя производителя, начинается процесс «наматывания кругов» — взлет, короткий полет по кругу, посадка и снова взлет. Таким образом каждый пилот должен сделать десять взлетов-посадок. Обычно на самолетах такого класса подобные вещи не практикуются – считается, что тренажера вполне достаточно для получения необходимых навыков, а летное время такого борта стоит очень дорого (если интересно – себестоимость около 5 тысяч долларов в час). К счастью, владелец понимает, что такой подход в корне неправильный, и принимает решение дать возможность пилотам прочувствовать реальный самолет.

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

И снова обучающее отступление. На самолетах с турбореактивными двигателями реверс тяги осуществляется путем выпуска специальных створок на двигателе, которые отклоняют часть исходящих газов вперед. В результате эти газы создают тягу, направленную назад, и помогают замедлить самолет. Реверс тяги является вспомогательной системой, даже расчет длины требуемой полосы при посадке делается без учета работы реверса. Так что его отказ сам по себе особых проблем не вызывает, но возникает очень серьезный вопрос – что именно случилось?

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

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

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

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

Я понимаю, что процесс заходит в тупик. Мысль о необходимости более длительного проживания в гостинице меня расстраивает (а переезжать в другую просто лень), и я начинаю напрягать мозги, хотя понимаю всю смехотворность моих попыток по сравнению с людьми, которые всю свою жизнь проработали в авиационной отрасли. Тем не менее, меня внезапно посещает идея. Я прошу подготовить самолет к вылету и обещаю продемонстрировать первый полет по кругу без возникновения ошибки, а второй – уже с ошибкой. В чем смысл, пока никому не говорю, но при этом слегка нервничаю – а что, если моя догадка неправильна, и я буду выглядеть идиотом?

Взлет, уборка шасси, набор высоты, переход в горизонтальный полет – все нормально. Представители производителя начинают посматривать на меня с интересом и подозрением. Ну, только бы вторая часть тоже прошла бы, как запланировано! Итак, снова взлет, набор высоты и до боли знакомый звуковой сигнал. Все, полдела сделано – по крайней мере, понятно, как воспроизвести проблему.

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

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

Вот на FADEC стоит остановиться подробнее – ведь это уже прямо соответствует тематике сайта. Full Authority Digital Engine Control представляет собой специализированный компьютер, управляющий двигателем самолета. Для меня одним из самых впечатляющих параметров этой коробочки размером в пол кирпича является цена. Сказать, что устройство на вес золота – не сказать ничего. На мой взгляд, FADEC стоит раз в 100 дороже, чем должен, даже если принять во внимание все требования по надежности работы. Причем таких коробочек на каждом двигателе две, они работают по очереди, да еще и следят друг за другом в процессе работы, чтобы в трудную минуту (если одной из коробочек вдруг станет плохо) подставить товарищу плечо. Фактически, самолет просит FADEC произвести те или иные действия (запустить/остановить двигатель, установить определенную мощность и т.д.), а FADEC полностью (и довольно независимо от самолета) управляет необходимыми системами (стартер, топливный контроллер и т.д.), чтобы исполнить просьбу, если посчитает это возможным.

Так вот, по каким-то, все еще непонятным для нас, причинам FADEC при определенных условиях принудительно переводил TR в состояние отказа, причем мы знали эти условия в самом общем виде (взлет без последующей уборки шасси), но как-либо связать их между собой не могли. Чтобы разобраться в проблеме детальнее, пришлось обратиться к производителю двигателей. На завод, произведший двигатели, были отосланы лог-файлы с FADEC, и довольно быстро (хотя к этому моменту мы уже переехали в другую гостиницу) был получен ответ. Оказывается, одна из ветвей логики FADEC предусматривает проверку работы тормозов. Если во время проверки FADEC решает, что тормоза на какой-то стороне самолета работают плохо, то реверс на противоположной стороне отключается. Причем даже больше того – нам пояснили, что, по показаниям FADEC, колеса самолета после взлета замедляют свое вращение с разной скоростью, что и вызвало соответствующую реакцию FADEC. Если же шасси убрать сразу после взлета, то колеса автоматически затормаживаются довольно энергично, и FADEC не обнаруживает в этом месте никаких проблем.
Для проверки этой теории мы сделали еще один полет, в ходе которого шасси не убирали, но сразу же после взлета затормозили колеса вручную. В принципе, полет подтвердил выдвинутую теорию – при принудительном торможении все было нормально, без него – стабильно появлялся отказ реверса.

Казалось, проблемная область наконец-то сузилась, и впереди забрезжил лучик надежды на скорое покидание уже до боли надоевшего аэродрома. Однако полная перестановка местами (слева направо и справа налево) всех систем и блоков, имевших отношение к шасси и тормозам, проблему и не решила, и не поменяла местами (на что мы очень надеялись).

К этому моменту на аэродроме появился представитель производителя двигателей, которого я и решил попытать на предмет того, как именно FADEC решает, что с тормозами что-то не в порядке. После длительных консультаций с офисом, получением разрешений на раскрытие конфиденциальной информации и просто попыток беспредметно отмазаться, он, наконец, предоставил мне требуемую информацию.
Оказывается, FADEC отслеживает скорость вращения колес как бы скользящем временном окне длительностью несколько секунд. Наверное, проще пояснить на примере. Допустим, это временное окно равно 4-ем секундам. Пускай на 10-ой секунде полета скорость одного колеса была 20 оборотов в секунду. В таком случае, если начиная от 8-ой до 12-ой секунды полета второе колесо хоть в какой-то момент тоже вращалось со скоростью 20 оборотов в секунду, то все хорошо. Если же отдельно взятые скорости вращения колес за промежуток в 4 секунды не совпали ни разу, FADEC делает вывод о неисправности тормозной системы.

Объяснение было довольно логичным (на самом деле, оно намного сложнее, но см. примечание по поводу упрощения в самом начале статьи), но возник классический вопрос – что делать? Сотрудники производителя самолета попытались доказать, что у них все в порядке, но производитель двигателя на эти заявления особо не реагировал. Вообще была возможность подключиться к бортовой системе самолета, чтобы записать нужный лог-файл, но это требовало формального оформления испытательного полета со всем сопутствующим (куча бумаг, летчики-испытатели и т.д.), поэтому быстро реализовать такой вариант не было ни времени, ни желания.

Пришлось снова напрячь мозги и вспомнить одну деталь, которую я увидел, изучая месяцем ранее небольшой документ размером в одиннадцать с чем-то тысяч страниц (краткая выдержка их техдокументации по самолету). Дело в том, что определенную информацию можно было вывести на один из штатных дисплеев в кабине пилотов. Проблема была в том, что информация обновлялась в реальном времени (2-5 отсчетов в секунду), а анализировать ее нужно было вручную. Ничего, к этому моменту лично я уже был готов даже тайно подключиться непосредственно к FADEC. Однако обошлось без таких крутых мер, просто в ближайшем большом хозяйственном магазине были закуплены необходимые материалы, и крутыми специалистами производителя самолетов была сооружена конструкция, закрепившая iPhone перед одним из экранов в кабине. Убедившись, что видео с iPhone позволяет увидеть необходимую информацию, мы сделали полет, в ходе которого засняли показания во время возникновения ошибки.

Дальше была веселая ночь, где 6 человек, каждый со своего iPad, вводил информацию из выделенного ему временного интервала в Excel. Причем, для надежности, временных интервалов было всего три – над каждым интервалом работало по два человека. Кластерные технологии и распараллеливание мощностей принесло свои плоды, и на следующий день мы уже держали в руках красиво оформленный файл с обработанной информацией, наглядно показывающий, что все параметры со стороны самолета находятся далеко в допустимых пределах.

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

Прежде, чем я выдам великое откровение, что же именно стало причиной всей этой нервотрепки, предлагаю ознакомиться со статьей, рассказывающей, как сложно, долго и тщательно разрабатывается ПО для авионики (и, очевидно, почему такие разработки должны стоить ну очень много денег – приблизительно двести тысяч долларов за пол кирпича FADEC) — habrahabr.ru/post/144686

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

Еще раз – вместо того, чтобы давать временное окно для выравнивания скоростей колес, FADEC выдавал ошибку сразу же, как только в любой момент времени скорость колес отличалась больше, чем на установленную величину. И все это произошло потому, что в жутко сертифицированном по всем возможным и невозможным стандартам процессе разработки ПО (а ПО для FADEC разрабатывается по самому строгому варианту стандарта, или как там это называется) кто-то просто закомментировал часть кода, и это попало в готовое изделие.

Комментировать я это не буду, потому что цензурные слова подобрать не могу, а нецензурные стараюсь не использовать. Думаю, читатели сами смогут сделать для себя выводы…

P.S. Спрашиваете, ну а что дальше, как летать? А все очень просто – в FAQ появилась очередная строчка, которая советует не допускать свободного вращения колес после взлета дольше минимально необходимого времени, а в случае возникновения ошибки TR – сбросить потом ошибку после приземления, и спокойно летать дальше.

P.P.S. А производитель двигателей сказал, что они, конечно, немедленно выпустят обновленную версию ПО, только займет это год – полтора, так как такое ПО проходит через строгие и длительные процессы разработки и сертификации (и это не шутка).
@curiousGeorge
карма
243,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

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

  • –5
    А у нас датчики направления силой в ракеты суют, аж следы остаются. В любой системе слабое звено — человек
  • +3
    Вы умеете управлять самолетом?
    • +41
      Да
      • 0
        Почтенно! А где учились? Слышал летные права получать долгая песня и дорогое удовольствие.
        • +4
          Это довольно длинная история, и я не уверен, что здесь правильное место обсуждать данную тему.

          Насчет сроков и денег — в зависимости от типа пилотского свидетельства и полученных рейтингов, стоимость и время, затраченные на это, могут отличаться в десятки раз.
        • 0
          Как раз в начале осени узнавал про права на самолет. Обучение для получения свидетельства пилота любителя стоит 190000 рублей (обучение идет на самолете Бекас Х32). Налетать надо не менее 17 часов для сдачи экзамена.
          • 0
            Минимальный требуемый налет для полноценного свидетельства частного пилота — 42 (40) часа, реально занимает обычно около 50-60 часов.
      • 0
        А какой именно пилот? Частный, коммерческий или линейный?
        • +4
          Линейный
          • 0
            Требования к линейным пилотам в России (ФАВТ-СЛП)

            1. Пилот должен иметь налёт не менее 1500 часов, в который засчитывается не более 100 часов налёта на тренажёре. Для пилота вертолёта требования по налёту установлены в размере 1000 и 100 часов соответственно.
            2. Пилот самолёта должен иметь не менее 500 часов налёта в качестве командира воздушного судна (КВС) под наблюдением (только для самолётов). Или 250 часов налёта в качестве КВС. Или 70 часов налёта в качестве КВС и 180 часов — в качестве КВС под наблюдением.
            3. Пилот самолёта должен иметь 200 часов налёта, выполняя полёты по маршруту. Из них 100 часов — в качестве командира воздушного судна или в качестве КВС под наблюдением.
            4. Пилот должен иметь не менее 75 часа налёта по приборам из которых не более 30 часов — на тренажёре (для самолётов). Для пилотов вертолётов 30 и 10 часов соответственно.
            5. Пилот должен иметь 100 часов налёта ночью (для самолётов) или 50 часов (для вертолётов) в качестве КВС или второго пилота.

            Почет.
            • 0
              а как налетать 250-500 часов в качестве КВС, если на регулярных рейсах КВС, как правило, уже должен быть линейным пилотом?
              В америке даже второй пилот на регулярных рейсах — обязательно ATPL.
  • +3
    Это круто. Убойная бюрократия и жесточайший вотерфол… — я бы застрелился.
  • –3
    Эпическая сила… Спасибо Вам за мою новую фобию — летать самолётами.
    • +7
      Спасибо мне за мою привычку сначала читать несколько комментов, а потом статью.
    • +4
      Да не переживайте так — в авиации такое количество уровней защиты, то нарушение одного-двух из них практически не снижает общий уровень безопасности.
      • +6
        Что мешало в этом вашем FADEC'е быть закомментированным другому куску коду — на этот раз критическому? Чем бы помогло то что этих FADEC'ов по 2 штуки на двигатель, если прошивки у них одинаковые?
        • +5
          Понятно, что 100% гарантии не даст вообще никто. Но даже в таком случае (если очень важный кусок кода закомментирован, и при этом проблема не проявила себя на более ранних этапах) есть большая вероятность, что FADEC перейдет в особый режим (такое в нем предусмотрено) и будет обеспечивать минимальную функциональность работы двигателя.

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

          А вообще — кто его знает, я не считаю себя знатоком всех нюансов работы ПО FADEC, просто более-менее представляю все это с точки зрения «продвинутого пользователя».
          • –4
            Более того, даже если один двигатель перестанет работать, то самолет легко сможет долететь до аэродрома и приземлиться.

            Да даже если два двигателя откажут, то у самолета есть третий :) вспомогательный (научно: вспомогательная силовая установка). И тогда с ним спокойно долетит до аэродрома

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

            Да даже если…

            Короче, чтобы разбить современный самолет, это надо очень и очень постараться.
            • +7
              Скажите, насчет ВСУ и планирования несколько часов — Вы это серьезно ???
              • +1
                Про несколько часов перестарался.

                Но случаи успешной посадки с отказавшими двигателями есть: Планер Гимли
                • +6
                  Очень надеюсь, что насчет ВСУ тоже пошутили. На всякий случай — ВСУ предназначена, в первую очередь, для обеспечения самолета электричеством и сжатым воздухом (для кондиционеров) на земле, чтобы не использовать для этого двигатели. Ну, еще как вспомогательный источник того же самого (электрика и воздух) в полете, не более того. Тяги ВСУ недостаточно даже для ничтожного изменения поведения самолета в полете.
        • 0
          Вот поэтому ПО должно сертифицироваться гораздо жестче, чем железо. Ведь в основе резервиорования заложено функционирование в случае апаратного отказа в одном из блоков. А если случается лажа по причине багов в ПО (например деление на 0), то при переключении на резервный блок такая же лажа случится и в нем с очень большой вероятностью.
          • 0
            Ну кроме жестких 100% повторяемых ошибок, есть еще «плавающие» ошибки и накапливающиеся ошибки. High Availability системы, как раз такие же, со вторым резервным сервером, такие ошибки «подавляют». Пока первый сервер в дауне, перегружается, второй отвечает на запросы.
          • +6
            Было бы интересно если бы для этого управляющий софт писался бы сразу в двух независимых друг от друга версиях, которые бы разговаривали по общему протоколу. Тогда была-бы какая-то надежда, что тупой баг в одной из версий не воспроизведется в другой.
            • +1
              Мне кажется невероятным, чтобы для достаточно сложного софта удавалось поддерживать соответствие обеих версий одним и тем же требованиям — при этом сохраняя независимость этих версий.
              Посмотрите для примера на «совместимость» MSO и OOo
              • +2
                Тем не менее, так работает в хороших системах. Системы Airbus/Boeing полностью удовлетворяют требованиям dissimilarity.
            • +2
              Вообще в ответственных местах так и делается. И не в двух а в трех. Притом что различается не просто версия а используемый язык программирования и аппаратная начинка. При этом, коллективы, пишущие эти части, так же не пересекаются.
            • 0
              Применяется иногда.
              Например в одном из самолетов стоит 5 дисплеев, два из кторорых разрабатываются по уровню A, остальные по уровню B (как менее критические).
              Железо там тоже разное.
              Но требования… хоть документы и разные, они пересекаются почти 100% и все обновления ПО делаются параллельно в обоих ветках, причем зачастую одновременно и одними и теми же людьми.
              Т.е. если будет придуман некий глючный алгоритм, то с вероятностью 99% он попадет в обе ветки ПО.

              Причина такого разделения именно в том самолете мне не ясна.
              Или хотели как лучше, а получилось — как всегда. Или пытались сэкономить на железе уровня A. Или от того, что дисплеев 5 (а не 4), не хватило каналов Arinc чтоб все их подключить с доблированием линий.
      • 0
        А вот именно после этого и у меня фобия начала где-то зарождаться… :)
  • +9
    практически всегда в любом более-менее большом самолете что-то неисправно

    Года три назад летел на MD 80. Достаточно древнее изобретение. Сидел как раз над крылом. Практически сразу после взлета на крыле из под лючка с надписью Fuel Pump стала подтекать жидкость. Ручеек со временем только усиливался. Вызвали стюардессу, на мои замечания что у нас течет топливо, она отморозилась, сказав что это конденсат. Ага, из под герметичного лючка. Ну а что она еще могла сказать? А тем временем ручеек достиг конца крыла и стал распыляться в воздухе… Затем кол-во ручейков увеличилось. В процессе полета стюардесса еще пару раз подходила с каким-то членами экипажа, показывая им происходящее, потом подходил командир экипажа, просил не разводить панику, «Ничего страшного, это не топливо, долетим нормально»… Перед снижением, как только сбросили обороты двигателей, ручеек сразу иссяк, будто перекрыли кран, все в момент высохло, только остался след на крыле и осадочек в душе.
    • +2
      лючка с надписью Fuel Pump

      А зачем лючку с надписью «топливный насос» быть герметичным?
    • +27
      Думаю, что с очень большой вероятностью это действительно был конденсат. Для начала, лючки, о которых Вы говорите, не герметичные. Под ними действительно скапливается конденсат, это совершенно нормально.

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

      Поверьте — подавляющее большинство вещей, которые во время полета для не-авиационных людей кажутся странными или опасными, на самом деле являются совершенно обыденными, нормальными и безопасными. Мало того, даже для людей, имеющих авиационное образование, но не обладающих в ей полнотой информации, очень часто невозможно достоверно решить, что именно происходит в том или ином случае — то ли самолет вот-вот взорвется в воздухе, то ли через мгновенье совершит нормальную посадку. Именно поэтому я всегда не любил некоторых великих авиационных деятелей-экспертов, которые для попадания на экран телевизора или газетную страницу с умным видом несут разную чушь и собственные измышления по поводу событий, о которых они не имеют никакой достоверной информации.
      • +4
        Ок, пусть не топливо, но почему при сбросе оборотов двигателя течь сразу прекратилась? И почему оно текло весь полет, а это чуть более чем 3,5 часа перелета.
        В инете нашел описание этого явления, мол, если баки полны (топлива больше какого-то там объема) то на высоте из-за низкого давления топливо может (не знаю как правильно перевести с англ.) подсасывать из бака и оно может стекать по крылу «пугая пассажиров». www.pprune.org/archive/index.php/t-340199.html
        Ну и со второго крыла оно не текло. Вообщем не претендую на то, что это именно топливо, просто описал как все было. Хотя зная положение дел в авиации у нас в Украине и компанию Роза Ветров…
      • +1
        А у меня другой случай недавно был: у Embraer при снижении из края крыла начал струиться белый дым. Причем не из двигателя, а именно из крыла. Никогда такого раньше не видел — что это могло быть?
        • НЛО прилетело и опубликовало эту надпись здесь
          • +1
            Спасибо, что за меня ответили. Я очередной раз собирался с мыслями, чтобы снова попытаться разъяснить то, что уже делал здесь — многие вещи не-авиационным людям кажутся совсем не тем, чем они есть на самом деле.
        • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      «и остался влажный след в морщине
      старого MD80»
      а вообще поздравляю, что все обошлось
  • +11
    А вот страшилка на тему разработки встраиваемых систем в автомобилях: Качество встраиваемого ПО или погром всё-таки случился.
    • +3
      ещё один пример который показывает, что ПО отвечающее за безопасность должно быть с открытым исходным кодом.
      (даю дословный перевод) «это позорный образец проектирования и разработки ПО».

      какой то школяр под маркой проприетарного ПО делает позор, который гробит не одну жизнь, компания платит многомиллионные штрафы и иски, а нужно было всего лишь открыть код и им бы сразу эту рецензию выдали. Жаль, что через одно место пишется софт отвечающий за достаточно серъёзное оборудование и проверить то это могут только после серъёзного разбирательства…
      • +4
        не могу не дописать, дабы народ ленящийся ходить по ссылкам понимал о чём я
        экспертиза выявила… одиннадцать тысяч глобальных переменных. Код реализации firmware назван хорошо знакомым всем программистам словом «spaghetti». Анализ цикломатической сложности программы выдал 67 не пригодных для тестирования функций, а ключевая функция определения угла дроссельной заслонки в ходе этого анализа показала какую-то удивительную оценку, при которой не только тестирование, но и вообще какое-либо сопровождение программы невозможно. Соблюдение отраслевого стандарта кодирования (для автомобильной промышленности такой есть, даже целое семейство, совокупно называемое MISRA) характеризуется выявленным числом его нарушений — их набралось 80 тысяч (в Toyota принят свой внутренний стандарт, который заимствует из MISRA всего 11 правил, при минимально требованных во время написания кода 93-х). По ходу дела было выявлено, что в такой сложной системе полностью отсутствует учёт сбоев и ошибок. При всём этом великолепии все связанные с безопасностью функции контроллера в его «прошивке» оказались реализованными одним единственным процессом.
        • +1
          Прочитав про 11 тысяч глобальных переменных, стал сомневаться в том, что статья основана на реальных событиях. Ибо уж слишком это как-то, особенно для в общем-то простого блока. Попахивает жареным.
          • +2
            Так как я в части автомобилей являюсь всего лишь непродвинутым пользователем, то не собирался это комментировать. Но сейчас не удержался и решил добавить — мне тоже очень сильно кажется, что тут совсем не так все на самом деле, как преподносится. Скорее всего, это просто самое банальное вымогательство денег из крупной компании, которой проще откупиться, чем спорить. Если я не ошибаюсь (хотя вполне мог что-то перепутать), то весь этот процесс возглавлял некий юрист, который специализируется на подобных исках. Причем он сам стал жертвой одной из этих 11 тысяч переменных. Только вот перед тем, как пожертвовать собой, он (очевидно, предчувствуя неладное), назначил небольшую пресс-конференцию, к началу которой он как раз справился с внезапно разбушевавшимся автомобилем. И еще представляет интерес запись его разговора со службой 911 во время того, как он «пытался» остановить мчащийся сам по себе автомобиль — например, почему-то он так и не выполнил рекомендации службы, оператор которой просил нажать на педаль тормоза (ну и т.д.).
        • 0
          грешным делом, не могли ли выдать на экспертизу какую-нибудь обфусцированную версию? Из серии «лучше потерять лицо, чем алгоритмы»?
        • +2
          Текст по ссылке слишком желтый.

          Например, "немаленький pdf-файл" на деле — 6ти страничный документ.

          Далее, в цитируемой статье:
          Что подтверждается здоровенным прошлогодним тематическим документом от самой Toyota (большой pdf-файл, только для любителей hardcore подробностей, он интересен потому что демонстрирует прошлогодние объяснения).

          Ссылка в цитате соответствует таковой на сайте статьи. Это официальный отчёт по анализу firmware (http://pressroom.toyota.com/article_download.cfm?article_id=3597).

          Упоминания 11 тысяч глобальных переменных там не обнаружил. Результаты анализа кода firmware не то чтобы ужас-ужас, но даже не ужас. Может быть, уважаемый SVlad, активно пиарящий эту ссылку (раз, два, три) после того, как она была приведена в этой ветке и в соседней до него, приведет цитату из данного pdf, указанного, как первоисточник?
          • 0
            Но это же блог PVS Studio. А в их компетентности сомневаться не приходится, они свою репутацию заслужили.

            В ином случае я бы тоже сказал про желтый заголовок.
            • +1
              Прошу обратить внимание, что мы просто переопубликовали статью. Мы не имеем к ней никакого отношения. Да, она с оттенком жёлтого цвета. Но нам показалась уместно, чтобы такой материал был на нашем сайте. :)
  • 0
    Этот пример даёт мне большее осознание того, для чего я вот как раз на авиастроительном изучаю программирование, хотя я софт писать и не собирался :-)

    Спасибо, интересно было почитать.
    • НЛО прилетело и опубликовало эту надпись здесь
  • –1
    Это вообще нормально, что блок управления двигателем выключает реверс в зависимости от состояния тормозов. По-моему, это как если бы база данных сайта не стала выполнять запрос, потому что решила что пароль пользователя скомпрометирован. Какая странная архитектура.

    А если блок выключит реверс на земле, после того, как он уже был включен, и только для половины двигателей на одном из крыльев?
    • +5
      Ну это логично. Если тормоза слева не работают, то справа надо отключить реверс, чтобы скомпенсировать усилие.
      • 0
        Нелогично то, что блок управления реверсом вообще никак не связан с реальными тормозами, а смотрит в случайное время на скорость вращения колёс. Было бы правильнее, если бы он отслеживал ту самую скорость, например, не когда ему вздумается, а по сигналу «активирован тормоз».
      • +2
        Вопрос был в том, почему блок управления двигателем вообще занимается состоянием тормозной системы. Это решение должно приниматься уровнем выше. Собственно в программировании, такие вот межблочные «горизонтальные» связи означают т.н. «code smell». Так же как и с тем, что какие то системы проверяют датчик в шасси, чтоб узнать на земле самолет или нет, они у центрального компьютера должны были спросить «на земле мы или нет», а не «какой сигнал дает датчик id=XXX».
        • +12
          Ох, не нужно мне было это вообще начинать… В статье я специально написал, что «буду разъяснять только самое необходимое, причем чаще всего в упрощенном виде», а также упомянул о «небольшом документ размером в одиннадцать с чем-то тысяч страниц (краткая выдержка их техдокументации по самолету)».

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

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

          Либо поверьте мне на слово, либо (если действительно ОЧЕНЬ интересно) попробуйте найти в интернете что-то типа «aircraft operational manual — systems description» для любого современного самолета транспортной категории, и попробуйте внимательно его прочитать — узнаете много любопытного и неожиданного.

          Вообще у меня самого раньше (когда изучал первые более-менее сложные самолеты) мысль работала приблизительно в такой последовательности (по мере понимания какого-то решения):

          1. Зачем они так сделали?
          2. А, все понятно, нормально!
          3. Не, подождите, а если вот такое произойдет?
          4. Секунду, зачем это вообще нужно было ???
          5. Не может быть, чтобы и это учли!
          6. Ну ничего себе… Как вообще можно было это все так тщательно и глубоко продумать ???

          Сейчас уже немного привык, и стараюсь не делать скоропалительных выводов — пытаюсь вникнуть в самую суть решений, а не в их легко видимую «пользовательскую» сторону.
          • +3
            Из под Вашего пера, 11 тысяч страниц можно было бы прочитать за пару вечеров :-)

            Вы название самолета просто не приводите, из-за того, что это просто не важно или это запрещено?
            • +2
              Спасибо за комплимент, но я не уверен, что готов породить 11 тысяч страниц даже за пару лет, не говоря уже о паре вечеров…

              Считаю, что название производителя в данном случае совершенно несущественно — данный случай не является особенностью конкретной компании, у других я видел вещи намного похлеще, просто они не соответствуют тематике Хабра.
            • +2
              По-моему, название самолёта совершенно очевидно и так любому, кто хоть чуть-чуть интересуется авиацией. Бьюсь об заклад, что это начинающийся на S.
              • 0
                К разработке самолета на S привлекались специалисты Boeing, потому отступление про «не знаю как на последних A и B» либо деза, либо странно.
                • 0
                  ru.wikipedia.org/wiki/SaM146
                  там новый двигатель, сильно отличающийся от Boeng и Airbus
              • –3
                Сухой СуперДжет шоли? Та неужто он стоит десятки миллионов долларов?

                UPD Согласно Вики он $35,4 млн стоит. Однако и цены.
                • 0
                  SSJ 100 не бизнес-джет. При желании можно сделать ему кастомный крутой салон «под шейха», но вроде бы пока его никто для таких целей не покупал.
          • +4
            Оно и видно, насколько «все так тщательно и глубоко» продумано, что логи вам пришлось снимать на видеокамеру и вручную переписывать.
            • +1
              Одним из решающих факторов было время, вернее — его отсутствие. Можно было потерять лишний день — два, дождаться соответствующих специалистов, которые выгрузили бы всю эту информацию правильным способом. Либо вообще получили бы прямо из недр самолета уже готовый ответ.
              Мне это время терять не хотелось, поэтому пришлось придумать такой корявый обходной путь.
              • 0
                Вот что гостиница животворящая делает!
          • +4
            Недавно летел на А320 в аварийном ряду — специально продуманы даже такие детали как:
            1. Крепеж откидного столика — вращающаяся ручка фиксируется в вертикальном положении, упираясь в штырь, дополнительно зацепляясь за маленький выступ. Чтобы при эвакуации никто локтем вперед не толкнул и столик не открылся.
            2. Инструкция по открыванию аварийного люка наклеена так, что часть на защитном лючке, часть на самой двери. Если сорвать лючок — останется видна ровно та часть картинки, которая нужна уже после срывания лючка.

            Везде бы так все проектировали))
    • 0
      В автомобиле БК тоже управляет двигателем в зависимости от тормозов и от пробуксовки колес и от кучи других параметров.
      • 0
        Во во!!!
        И тупит при этом некисло.
        Так в повороте на снегу с пробуксовкой он всегда отрубает подачу топлива и обороты падают и как итог машину несет в отбойник. Хотя мне вот например пробуксовка и нужна была ну и т д.
        Просто получается что он как бы знает лучше как управлять и помогает тебе в этом, но в реальности как правило от помощи этой только хуже.
        • +2
          Потому что производитель рассчитывает на обычного водителя, который не входит в повороты боком ;)
          Хорошо, если производитель предусматривает кнопки отключения антибукса, курсовой устойчивости и других систем, оставляя для «продвинутых» водителей большую свободу действий, но в глобальном масштабе «домохозяйке» за рулем — нужно спокойно доехать из дома в магаз и обратно.

  • +3
    А если их два, то как они решают кто не прав? Если три то понятно, а с двумя вообще не понятно. Ну разные показания у них получились, и?
    • +3
      Round Robin… эээ, то бишь камень-ножницы-бумага :)
    • +1
      Где-то слышал старинную, кажется, голландскую поговорку: «Выходя в море, бери или один хронометр, или три».
      Знакомый, служивший на каком-то ракетном комплексе, типа С300 в его первые годы эксплуатации, рассказывал, что там как раз использовалось 3 БК, работали параллельно, и если у кого-то результаты обсчета не совпадали, то он тупо исключался из работы, не знаю, временно или постоянно.
      Здесь же, как я понял, второй вычислитель тупо на подхвате, видимо, считается, что и одного вполне достаточно и вполне надежно, а второй просто потому, что резерв обязателен.
      • 0
        Поговорка норвежская, слышать вы ее могли в «Мистическом человеко-месяце».
      • 0
        Вспомнились компьютеры Evangelion с именами трёх волхвов:
        image
    • 0
      Снимает показания всегда один, а второй следит за тем, что у первого все ок. Скорее всего контролирующий заберет управление, только если у первого нарушится его работа (а не работа двигателя)
    • +1
      В случае двух блоков должна быть схема контроля, которая сама ( а не блоки ) принимает решение, кто неправ. Либо используется вариант, что второй блок висит в горячем резервировании и по сигналу error от первого подхватывает управление. Хотя я бы поставил три блока и схему мажоритарного резервирования — тупее и намного надежнее.
  • +1
    себестоимость около 5 тысяч долларов в час

    А из чего складывается такая величина? И это постоянно, или в тестовый период она больше, чем будет при нормальной эксплуатации?
    • 0
      Наверное, в обычной жизни меньше, т.к. не нужно дополнительное слежение и присутствие лётчика-испытателя.
      • +3
        Цифра была очень приблизительная, причем для штатных полетов. В зависимости от ряда параметров, она может плавать раза в два. Стоимость работы пилотов близка к ошибке округления.
        • 0
          Как-то всё равно не стыкуется.
          Пассажирский перелёт со ста пассажирами дешёвой авиакомпанией — это порядка $150 за пару часов с каждого, т.е. $15K за полёт, т.е. $7.5K / час.
          Эта сумма включает зарплаты пилотов, стюардесс, всех сотрудников аэропорта, затраты на маркетинг и т.п. — на всё про всё остаётся $2.5K?
          А ведь наверняка эксплуатация «Боингов» ещё дороже, чем вашего бизнес-джета: как минимум он тяжелее, значит и топлива больше сжигает.
          • 0
            Но «боинги» везут больше пассажиров, что и делает их более экономически выгодными при полной загрузке.
          • 0
            Во-первых, экономика регулярных пассажирских перевозок — вещь настолько загадочная, что ее не понимают даже в самих авиакомпаниях. Именно поэтому практически все авиакомпании рано или поздно банкротятся и/или реструктуируются.

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

            P.S. Стоимость топлива составляет 20% — 40% в стоимости летного часа.
            • +1
              Читаю Ваши ответы и не могу сдержаться:
              Какой же Вы терпеливый! Достойно уважения и подражания.
    • 0
      Топливо, ГСМ, преиодическое обслуживание узлов (каждые XX часов полета).
      А также, каждая посадка стоит денег. Например, если самолет рассчитан на X посадок (рассчетная величина и на шасси, и на планер), то каждая посадка стоит <стоимость самолета>/X.

      Я думаю, что экипаж там — самое дешевое.
  • 0
    Кто-то на YAC2012 заливал о взломе систем самолёта через гражданский ethernet в кресле. Есть подробности на тему?
    • +1
      Хотя могу что-то путать, возможно речь была о незащищённости системы приёма команд с земли, но и про сеть что-то было. Напомните, если кто в курсе.
    • +1
      Недавно летел в A340-600 и там на LCD вделанных в спинку кресла была картинка загрузки ПО. Так вот, грузилось всё по протоколу XModem (думаю, многие тут ещё застали это чудо ;) на скорости 115к на COM1.
      Так что наверное где-то есть Ethernet в креслах, но далеко не везде.
      Копирайт на софт стоял 2002-2004. И A340-600 далеко не самый старый самолёт…
  • +28
    Прекрасная статья и отличный пример применения смекалки.

    Если абстрагироваться от авиационной тематики, то у меня была немного похожая история.
    Внезапно, на боевом хостинге одного из рабочих проектов (скучная система анкетирования для гос. организаций) внезапно проявилась странная ошибка — не прикреплялись некоторые файлы (жалобы поступали в основном на .doc файлы).
    Размер значения не имел. Например архив в 8 Мб загружался, а хлюпенький.doc из одной странички — не хотел и падал по «connection lost».
    Позже выяснилось, что PHP выдавал–таки ошибку 3, UPLOAD_ERR_PARTIAL, что значит — файл недозакачался.
    В движке конечно ковырялись. У нас Zend Framework. Но он тут не причём. Mime типы не фильтровали и вообще собранный на коленке скрипт аплоада файлов, который не использовал фреймворки выдавал ту же ошибку. Естественно, поглядели в репозиторий на предмет последних изменений кода, который мог бы повлиять на загрузку файлов. Но в последнее время никто ничего связанного загрузкой файлов не трогал.
    Следующим под подозрения попал сам сервер. Но и с ним в принципе было всё как обычно и никто не трогал настроек mime-типов или настроек веб-сервера. Далее под подозрения попал suhosin. Но и он оказался не при делах.
    Мистика. Так подумал не только я, но и все, с кем я делился этой напастью.
    И тут я от досады начал искать, какие же файлы не заливаются, и что у них общего. Появилась мысль, что происходит поиск некоей сигнатуры в файле, и если она встречается, то всё. Connection lost.
    Обрезал у файла хвост. А он не льётся. Отрезал начало. Всё так же. А он уже 600 байт весит.
    Посмотрел на эти 600 байт — и вижу, куча нулей (тех самых, которые \0) среди кучи байтов. Взял, сгоряча 75 байт нулей скормил. И опять не прошло. И вот тут то я и понял, в нулях дело. Отправляю 64 нуля подряд — всё окей, 65 и больше — не идёт. И тут я приклеил к хорошему.jpeg, который легко заливался, эти 65 байт нулей сзади. И файл перестал заливаться.
    И вот теперь самое интересное. На хабре я читал статейку про атаку на dns, в которой специально сформированные tcp-пакеты запросов возвращали намного более длинные пакеты ответов, что в свою очередь дико напрягало трафик.
    Возникла мысль, что всё это от излишне параноидальной настройки сетевого оборудования на стороне хостера. И трафик попросту фильтруется.
    Хостеру в ТП конечно отписали. А пока он отвечал, я воспользовался услугой создания триального аккаунта у хостера (на этот раз хостинг был виндовый) и с радостью обнаружил косвенное подтверждение своей догадке. Тестовый скрипт возвращал ту же ошибку и рвал соединение при попытках загрузки файла с нулями. Однако, если загрузить файл через защищённое соединение, естественно, всё прокатывало.
    Вообщем, история завершилась хэппи эндом. На следующий день всё неожиданно заработало, а спустя ещё пару дней хостер отписался, что проблема была с их стороны и уже решена.
    • 0
      У меня была история, когда компьютер намертво зависал при попытке скопировать с сети xls файл. Вылечилось заменой сетевой карты. Казалось бы…
  • +3
    Эх, работая в разработке бортового ПО уже много лет могу сказать, что тенденции не самые хорошие.
    Причем идут и послабления со стороны стандартов (которые пишут в США), и массовая передача самого процесса разработки в Индию и Китай.
    Последние хоть и живут в современном мире, голова у них всё еще в деревне.
    Как результат, качество ПО сильно падает. Причем они даже пытаются проектные стандарты править так, что они перестают соответсовать «библии» DO-178.
  • +12
    После статьи о тестировании самолёта QA и отладка веб-сайтов почему-то кажется детским садом. Как теперь хабр дальше читать?
    • +1
      :))
      Я вот занимаюсь отладкой насосных станций, пищевого/химического производства, энергетических установок. Иногда индустриальной археологией занимаюсь.

      Средства разработки — кондовый ANSI C (это ещё неплохо), ассемблер (специфический, не x86, и иногда даже Visual — релейная логика), иногда VBA. Дебаг доставляет, это факт :) Хоть и не самолёт.
  • +1
    Когда-то слышал что критически важные системы в авиации троируются, чуть ли не до того, что каждый «третькомплект» реализован на разном железе и со своим ПО. Это правда или байки? Еще очень интересно какие протоколы используются в современных самолетах, какой-нибудь CAN/RS485/ или что-то специализированное?
    • +1
      ARINC 429
      • 0
        Основной — да.
        Но и более привычные RS-422 и Ethernet (возможно чуть модифицированный) тоже встречаются.
  • +2
    мысли вслух — каждый наступает на теже грабли. Из описания мне видно что архитектура становиться похожа на таковую у телефонных коммутаторов предыдущей реинкарнации ( до NGN ). Что стоило сделать системный анализ и найти похожие системы и учесть накопленный опыт? В частности система дабага должна работать со всей сетью, что позволило бы понять сразу что отказ TR инициирован FADEC. Логи же отдельного узла должны быть достаточно полными что бы эмулировать его эволюцию и ясно увидеть производителю почему это произошло.
    Конструкция с айфонами в полностью цифровом окружении — это вообще эпик. По идее это нижний уровень взаимодействия с железом и он мало того что должен быть вылизан, но вследствие этого еще и залоггирован как надо. В нормальных системах такое делается поднятием флагов и скачиванием полного лога после теста.

    В общем вашей конкретной экосистеме еще взрослеть и взрослеть.
  • 0
    Угу, напомнило пару вещей:

    Качество встраиваемого ПО или погром всё-таки случился

    Это про Toyota, в чьей машине блок управления двигателем как-то убил одну невинную женщину, и покалечил другую. Аудит кода показал наличие 11 тысяч глобальных переменных, отсутствие учета сбоев и ошибок, проверок результатов вызова функций RTOS, и прочую «красоту».

    Ну и нетленка про американский сайт healthcare.org — на всякий случай, бюджет разработки — 93 миллиона долларов, в процессе вырос по разным оценкам до 300-400 миллионов, и при запуске он тут же упал. Нагрузочное тестирование то ли проводилось из рук вон, то ли не проводилось вообще (!), пентест выполнялся в день, предшествующий запуску (сейчас не могу найти пруфлинк, но весь интернет пестрел матами на эту тему месяц назад). Кто читает на английском — рекомендую заметки из «штаба», который разбирался с этим факапом. Там феерия почти на каждом шагу:

    www.computerworld.com/s/article/9243855/_War_Room_notes_describe_IT_chaos_at_Healthcare.gov?mm_ref=http%3A%2F%2Fm.slashdot.org%2F
    • 0
      Ох, ну рефер бы утрали из сылки…
  • +1
    А вот если бы еще кто-нибудь написал о том, как отлаживают ПО на атомных электростанциях…
    • +1
      А Вы точно хотите это знать? Почитайте lib.ru/MEMUARY/CHERNOBYL/dyatlow.txt_with-big-pictures.html, неплохо мозги вправляет, хотя не совсем чтобы по теме отладки ПО, но по теме поиска причины «проблемы»…
    • +1
      За атомные не знаю, а с газотурбинными (и немного паровыми) работал. И с химическим процессом (взрывоопасные, легковоспламеняющиеся, сильнодействующие ядовитые вещества) работал. Я, собственно, промышленной автоматикой занимаюсь.
      Понял, что Чернобыль — вполне обычное (если не сказать, закономерное) явление, выходящее из ряда вон только по масштабам.

      Как ни странно, писаться по ночам не стал. Только знакомых пугаю разными байками.
  • +9
    А я как-то руководил группой по верификации (DO-178, тогда еще B) ПО на одном джете. Тоже было много анекдотов, в частности на радаре не отрисовывались три строчки, потому что (как потом выяснилось) программист переписал часть автоматически сгенерированного кода и оставил комментарий в духе «тут кажется не оптимально сработал кодогенератор», ну и налепил ошибок.
    • 0
      Из Simulink генерили?
  • +8
    Хотя максимум веселья был, как мне рассказывали, когда на испытательном полете оказалось, что одну часть системы оповещения о неисправностях сделали по новой версии спецификации, другую — по старой. Сразу после взлета полетели такие ошибки, что пилоты поседели, отключили автоматику и сели вручную.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      по сравнению с парой недель ожидания в тайге среди медведей
      Ого, а вы что там отлаживали?
      • НЛО прилетело и опубликовало эту надпись здесь
      • +1
        отлаживать — ещё цветочки, некоторые там работают месяцами)
      • 0
        А что там запускают? Новые объекты на месторождениях. А там есть всё. Сами новые объекты и куча вспомогательных систем. Тоже, бывало, как уеду — так на полтора-два месяца.
  • +3
    Скажите одно — за такой отличный и находчивый дебаг нового самолета деньги кто кому платил, вы поставщику самолета или они совесть поимели и Вам компенсировали что-то?
  • 0
    Наша сторона осталась не очень довольной предложениями производителя по урегулированию данной ситуации.

    Хотя на ситуацию, как всегда, можно взглянуть с разных точек зрения, так что лично у меня нет даже четко сформировавшегося мнения, что было бы правильным и справедливым.
  • 0
    Буду подсовывать эту статью заказчикам, которых возмущает неправильные значения суммарников колонок в конце смены ;-)
  • –8
    В прошивку FADEC нужно добавить строку условие:
    IF( самолет в воздухе)
    {
    пропустить анализ разности вращения колесиков…
    }

  • –1
    Дело в том, что определенную информацию можно было вывести на один из штатных дисплеев в кабине пилотов. Проблема была в том, что информация обновлялась в реальном времени (2-5 отсчетов в секунду), а анализировать ее нужно было вручную

    А какой смысл выводить debug-информацию в таком режиме? Неужели от нее есть какой-то толк для пилота? Слабо представляю, чтобы пилот, которому и так есть чем заняться в кабине, будет каждую секунду смотреть в дисплей на эти отсчеты и искать тенденции. Почему не логировать эту информацию для последующего анализа на земле? Понимаю, что вопросы не к автору, ну уж очень непонятно…
  • +1
    Удивительная история. Оказывается, отладка самолёта — не только очень просто, но и безумно интересно!
    Два вопроса, если можно.
    Когда определяют Мinimum Equipment List исходят из штатной ситуации на борту, когда всё работает так, как должно работать. Не может ли случиться, что в аварийном режиме Мinimum перестанет быть допустимым, и ошибка с отсутствие воды в кофейнике окажется критической?
    Второй вопрос. Предположим, фантастика стала явью и компьютерами самолёта управляют извне. Или компьютер по каким-то причинам отказывается работать, или работает некорректно, или ситуация такая, с которой он заведомо не сможет справиться. Предусмотрен ли для таких случаев переход на ручное управление?
    • 0
      Предположим, фантастика стала явью и компьютерами самолёта управляют извне

      Это уже явь.
    • +1
      Естественно, в случае наступления какой-то аварийной ситуации наличие неработающего, но отвечающего требования MEL оборудования может эту ситуацию дополнительно усугубить. Именно поэтому разработка MEL — вопрос очень не простой (и не дешевый), и при его разработке стараются ввести такие ограничения на допустимые типы/режимы полетов, чтобы свести к минимуму возможность такого влияния. Тем не менее, понятно, что все предусмотреть невозможно. Если какая-то позиция MEL реально может снизить безопасность полетов, то первым ограничением будет запрет на наличие пассажиров на борту. Т.е. будет разрешен перегон самолета экипажем к месту ремонта, и все. Опять таки, это очень упрощенное объяснение.

      Большинство самолетов с системой Fly-By-Wire (где контроль над управляющими поверхностями и двигателями осуществляется с помощью электронных систем, в настоящее время — специализированных компьютеров) не предусматривают возможности перехода на непосредственное управление. Грубо говоря, даже теоретически невозможно напрямую соединить штурвал и рули — штурвал всегда будет всего лишь просить у компьютера выполнить то или иное действие, а компьютер уже будет посылать управляющие воздействия на приводы рулей.
      • 0
        Спасибо большое.
        По первому вопросу всё предельно ясно, по второму тоже, хоть и жутковато немного.
        Не знаю почему, но вероятность человеческой ошибки пугает меньше, чем полная зависимость от компьютера.
        Но если люди не могут ничего исправить и изменить, может они и не нужны особо?
        Есть же беспилотный гугломобиль, возможно, на очереди самолёты, которые оснащены только автоматическими системами управления?
        • +3
          Насчет полностью беспилотного пассажирского самолета я даже сам себе ответить не могу. Мне кажется, что помимо вопросов пилотирования, на самолете есть еще очень большое количество функций, выполнить которые автоматы не смогут еще очень долго.

          Я также прекрасно понимаю, что надежность современных электронных систем намного выше, чем классических. Также понимаю, что даже с классическими системами при определенных видах отказов человек тоже ничего не сможет сделать (в т.ч. чисто физически). И человек я технический, с вроде довольно неплохим пониманием многих аспектов как самолетостроения, так и пилотирования. И все равно на уровне эмоций у меня приблизительно такие же ощущения, как у Вас…
        • 0
          Беспилотный гугломобиль есть пока только на закрытых треках и на дорогах общего пользования он появится ой как не скоро.

          Не вдаваясь в подробности, приведу пример. Железная дорога (и метро, как разновидность) автоматизирована и весьма (я имею в виду не подвижный состав, а полотно и инфраструктуру). В этом плане автомобильная дорога просто в каменном веке. И, тем не менее, в кабине всегда есть машинист — даже если часть пути поезд ведёт автоматика.
          • 0
            Беспилотный гугломобиль есть пока только на закрытых треках и на дорогах общего пользования он появится ой как не скоро.

            Вы уверены?
            Дата статьи по ссылке 8 мая 2012, если что. Так что думаю уже вовсю катаются машинки на дорогах общего пользования. Конечно может и с водителем пока за рулём, но сами.
            • +1
              Значит, пора мне собирать чемоданы в Калифорнию… Ещё б мотоциклы такие сделали :)))
  • 0
    Интересно, почему система Unit тестов для ПО FADEC не отловила закомментированный кусок кода?
    Судя по описанию проблемы, похоже это самое окно никто не тестировал…
    • 0
      Если у разработчиков этого контроллера всё так же, как у Тойоты с её контроллером двигателя, то тестов там никогда и не было.
    • +2
      Несмотря на все тяжкие процессы сертификации, качество верификации ПО часто оставляет желать лучшего. И к бизнес-джетам это относится наверное даже в большей мере, чем к остальным бортам.
      Возможно, что:
      — этот участок кода вообще не проверялся автоматическими тестами
      — проверялся, но недостаточно хорошо (пара стандартных наборов данных), поэтому факт комментирования кода не был отловлен
      — были fail'ы в тестах, но проблему прохлопали/посчитали несущественной и она прошла сертификацию
      — этот «умный код» иногда глючил, и решили на текущей сертификации его убрать (отразив это в требованиях). Но, как видите, что-то забыли.

      Разновидность последнего вариант разгребал лично несколько лет назад как раз на бизнес-джете. Правда тогда это был испытательный полет и кривой код к заказчикам не попал (но там и «эффект» гораздо круче был :))
      • +1
        Не расскажете подробнее про «эффект» и причины? Если не NDA, конечно.
        • +1
          Сообщение об ошибке было вида «во время полета 4 раза гасли все мониторы»
          Речь шла о больших мониторах (DU)
          Вспомогательные (DCP) и head-up видимо продолжали работать (если не попадали по другим причинам :)), так что не всё так фатально.
      • 0
        Как именно могли провтыкать тесты я отлично представляю, меня скорее интересует вопрос надежности работы и контроля ПО в авиации. Достоверно извесно, что в авиации массово используются системы дублирования.
        Я был почти уверен, что с тестами дело обстоит аналогичным образом (один кусок кода покрыт несколькими независимыми тестами).
        Выходит что-то не так!?
        • +1
          Нет, тест пишется один на некую логически-связанную часть кода.
          Стараются это максимально декомпозировать на мелкие куски, чтобы тест долго не ходил (хотя некоторые ходят неделю).

          Качество написания тестов контроллируется теми же людьми. В зависимости уровня критичности, к каждому куску кода имеют отношения от 1 до как минимум 6 человек.
          Автоматом контроллируется только покрытие всех веток кода, но это тоже не дает гарантий, т.к. некоторую ситуацию можно создать, но не проверить результат работы.
          А также бывает, что всё покрыто, всё проверено, но тем не менее опасную ситуацию создать можно.
  • +4
    Не могу удержаться, уж не о Sukhoi Superjet 100-ли статья?
    • +1
      Может быть, конечно, но… что-то тут не складывается. С одной стороны написано, что «самолет только-только начал выпускаться, и конкретный экземпляр имеет серийный номер в первой десятке» и «нет ни опыта эксплуатации, ни опыта техобслуживания». С другой стороны, написано что речь идет о «бизнес-джете». Да, есть версия SSJ-100 в виде бизнес-джета (так-то это пассажирский региональник), но первый экземпляр был выпущен буквально этим летом, а этим летом бортовые номера SSJ уже перевалили за 50 и безусловно есть уже и опыт эксплуатации и техобслуживания и у наших и у иностранных заказчиков. Да и детская болезнь типа описываемой должна была уже давно быть обнаружена и как минимум внесена в документацию — уж при десятке-то вылетов в день, который делает каждый борт в той же Interjet. Не думаю что бизнес-версия настолько отличается от региональной что прямо там внезапно появляются такие вот баги которые за несколько лет не были обнаружены в региональнике. Да и не слышал я о конкретно этой детской болезни у SSJ.
      • 0
        Да, я тоже хотел прямо спросить не суперджет ли это, но засомневался. С другой стороны у них есть временные рег. номера, и вроде как последний самолет переданный по контракту для Мексики имеет номер 97008. Более, чем подходит для «первой десятки».

        Видимо пока curiousGeorge не раскроет тайну, так и будем гадать :-)
      • 0
        Он как бы не бизнес-джет, но подобного уровня проблемы с первыми экземплярами тоже были.
  • 0
    Поставил плюс собрату.
    1. Чисто интересно, мы с вами не общались?
    2. Бюрократия и жесткости процессов — это специфика индустрии. Мне больше интересно то, когда современными методами, которые никоим образом не нарушают стандарты разработки, разрешат пользоваться официально. А то совсем же грустно без CVS и CI-фреймворков.
    3. Мне любопытно, насколько сейчас с мёртвой точки сдвинулся ГОСНИИАС и Иркут?
    4. Люди, курирующие авиационные проекты, увы, старой закалки, что отзывается на всём процессе. Если честно, то моё мнение, что у молодых специалистов куда больший потенциал и куда быстрее и лучше может получиться, если их допустить до управления и экспертизы. Но здесь вам не тут, и поэтому свободное небо и космос, пока что удел энтузиастов и мелких проектов.
    • 0
      Куда оно там сдвинулось, народ отделами бегал ИЛ-НИИАС-Иркут, благо все рядом друг с другом — где есть работа, туда и бегут.
  • +1
    Хоть это и крайне нереально, но очень уж хочется посмотреть код прошивки FADEC.
    Особенно сделать вид, что хоть что-то в этом коде пойму :))))
    • +1
      Да, не. Будет как у автора статьи :-)

      1. Зачем они так сделали?
      2. А, все понятно, нормально!
      3. Не, подождите, а если вот такое произойдет?
      4. Секунду, зачем это вообще нужно было ???
      5. Не может быть, чтобы и это учли!
      6. Ну ничего себе… Как вообще можно было это все так тщательно и глубоко продумать ???
    • 0
      Приходите работать туда, где это дело разрабатывают, и посмотрите ))
  • +1
    Спасибо за статью, читается на одном дыхании. Конечно, как вы логи снимали… из всех слов, которые приходят на ум по этому поводу, цензурным является только слово «смекалка» :)
  • 0
    Спасибо за Вашу статью!
    В голове не укладывается, что FADEC получает такую информацию. Я уже не говорю о последствиях :)
    Очень удивила концепция «центрального компьютера». Ни в Аэробусах, ни в Боингах такого нет.
    • +1
      Опять таки, из-за упрощенного объяснения у кого-то могло сложиться неверное впечатление о структуре бортовой управляющей системы, поэтому добавлю пару слов.

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

      Хотя снаружи это функционирует, как единая система, но внутри нет одного места, при выходе из строя которого все остальное тоже прекращает работать.
      • +1
        Все таки, из-за упрощенного объяснения, не уверен, что я Вас понимаю :) Поэтому прошу объяснить.

        Возьмем А320. Сигнал от рычага закрылок поступает на компьютер SFCC (slats flaps control computer), который с помощью гидравлики выпускает закрылки. Да, это тоже упрощенно — на самом деле там задействовано где-то 7 разных компьютеров. Так же как Вы и описали SFCC продублированы, их 2 штуки. То есть, сигнал идет так: рычаг --> компьютер SFCC --> закрылки. Но мы не можем сказать, что это центральный компьютер, потому что для выпуска шасси, например, сигнал идет так: рычаг --> LGCIU --> шасси. И хотя LGCIU и SFCC обмениваются информацией, это абсолютно независимые компьютеры.

        Из Вашего же описания я понял, что (на примере A320) сигнал идет так:
        рычаг закрылок --> центральный компьютер (сложная система из разных блоков, которые дублируются) --> SFCC --> закрылки
        рычаг шасси --> тот же самый центральный компьютер --> LGCIU --> шасси

        Я правильно понял?

        PS. На А320 есть ECAM, как бы центральный компьютер мониторинга. Самолетный Nagios что-ли :) Или Zabbix. Но, все же, я уверен, Вы не это имели ввиду.

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