Airbus A350-941
Некоторые модели авиалайнеров Airbus A350 по-прежнему приходится полностью перезагружать каждые 149 часов, несмотря на предупреждение агентства авиационной безопасности ЕС (EASA) о недопустимости такой ситуации, выпущенное ещё два года назад.
На этой неделе EASA повторно выпустило «директиву лётной годности» (airworthiness directive, AD), с указанием для авиакомпаний обязательно выключать и снова включать самолёты A350, чтобы предотвратить «частичную или полную потерю некоторых систем или функций авионики».
Обновлённая директива вступает в силу с сегодняшнего дня (26 июля) и относится к новым самолётам A350-941, на которых установлено старая заводская прошивка, пишет The Register. Судя по всему, для предыдущих самолётов действует аналогичная прошлая директива, которая тоже указывает обязательно выключать и включать самолёт до того, как электроника отработала 149 часов в непрерывном режиме.
Изначальная директива 2017 года упоминает «проблемы в эксплуатации, когда произошла потеря связи между некоторыми системами и сетью авионики». Последствия сбоев варьировались от «потери избыточности» до «полной потери конкретной функции на общем удалённом концентраторе данных и основных модулях обработки ввода/вывода».
Другой производитель самолётов Boeing сильно пострадал в 2015 году от похожей проблемы с его авиалайнерами 787 Dreamliner. Она тоже была связана с конкретным временем непрерывной работы: тогда была обнаружена ошибка переполнения памяти, из-за которой генераторы 787 Dreamliner отключались после 248 дней непрерывной работы. Было обнаружено, что программный счётчик в прошивке генераторов переполнялся конкретно после этого точного промежутка времени. И это не единственная программная ошибка, которую нашли в 787 Dreamliner за последние годы.
Обычно авиалайнеры оставляют включёнными на стоянке у гейтов аэропорта, чтобы обслуживающий персонал мог провести обычные проверки систем между рейсами, особенно если самолет подключён к наземному питанию.
Решение проблемы для A350-941 довольное простое: нужно установить обновления прошивки самолёта или продолжать включать и выключать самолёт.
Технические детали бага в прошивке A350
В маркетинговой брошюре компании Airbus от 2013 года объясняется, что блоки общего удалённого концентратора данных (Common Remote Data Concentrator, CRDC) A350 позволяют «значительно упростить проводку», а отраслевой журнал аэрокосмической индустрии более подробно описывает конструктивные нововведения авиалайнера Airbus: это 29 концентраторов CRDC, которые «распределены по самолёту». Они работают совместно с 21 модулем обработки данных ввода/вывода (Core Processing Input Output Module, CPIOM), взаимодействуя с различными системами и датчиками.
Модули CRDC принимают входные данные, например, точное положение плоскости управления полётом (flight control surface) — и преобразуют их в цифровой сигнал, совместимый со стандартом компьютерной шины ARINC 429 для передачи по внутренней сети A350 в CPIOM. Эта сеть работает по разработанному Airbus протоколу под названием AFDX, или Avionics Full-Duplex Switched Ethernet. По сути, CPIOM — это мини-компьютер; а в A350 на модулях CPIOM работают дискретные «приложения» авионики. Сами CRDC не размещают и не запускают приложения. Таким образом, условие сбоя, описанное в директиве EASA, может означать потерю связи с конкретным приложением на CPIOM после переполнения буфера.
Учебное пособие авиакомпании Delta Airlines на Scribd объясняет, что такое приложения CPIOM A350. Среди них:
- система определения количества и оптимизации расхода топлива, которая сообщает пилотам количество израсходованного топлива;
- система контроля давления в кабине;
- система защиты от обледенения и атмосферных осадков;
- система отбора воздуха из двигателя, которая, среди прочего, поставляет кислород для дыхания в пассажирский салон;
- система выдвижения и втягивания шасси.
Модель A350-941 в последние годы купили многие авиакомпании, включая Air France, American Airlines, Delta Air Lines и Lufthansa, а также Air China и тайваньская China Airlines. Как British Airways, так и Virgin Atlantic закупали модель A350-1041, которая отличается от пострадавших A350-941.
hottabxp
arkamax
С Boeing 787 Dreamliner те 248 с небольшим дней — это (внезапно) близко к 2^31 сотым долям секунды. Signed vs. unsigned? Хотя даже если сделали бы его unsigned, пришлось бы через 496 дней перезагружать, что не решает проблему в корне.
tmin10
А 149 часов это 2^29 милисекунд, куда-то ещё 3 бита ушли.
Ivanii
Наверно в математику, яб в высоко-ответственной системе делал перезагрузку ПЕРЕД каждым полетом — подготовка к полету начинается с перезагрузки всего и самотестирования.
Inanity
Это не спасёт от буфера, переполняющегося за 6 часов полёта. Тут скорее нужно именно в архитектуре софта и железа закладывать необходимость максимально сокращать длительность любого рабочего цикла и принудительно сбрасываться в нули. Проектировать так, чтобы периодический запланированный «горячий» сброс был естественной рабочей процедурой, а не чем-то экстраординарным, что нужно делать только в исключительных ситуациях, которые по идее никогда не должны происходить.
Но и у этого подхода есть минус — он маскирует ошибки. Допустим, что в софте/железе есть баг, который через 6 часов приведёт к переполнению, но модуль архитектурно устроен так, что сбрасывается каждые 500мс и всё работает как надо. Т.е. баг в коде есть, но сброс спасает. А если считать, что баги так или иначе нужно искать не полагаясь ни на какую страховку, то эта логика горячего сброса должна сыграть всё же положительную роль.
Ivanii
Спасет от большинства проблем возникающих через 149 — 1193 часов после загрузки.
Но само собой не освобождает от нормальной проектировки оборудования.
Если есть циклы и абсолютно безопасные периоды для перезагрузки то почему этим не воспользоваться.
В авиации, даже в пассажирской, почему-то не приняты меры резервирования как в нормальной космической технике.
Wesha
А пользы от резервирования, если одновременно перезагрузятся все три резервированных компьютера? :)
khim
Нормальное резервирование базируется не на двух одинаковых блоках, которые также одинаково сбойнут, а на двух разных железках от разных фирм (соответственно с разными программами)
Однако в эпоху Open Source и это может не помочь…
chapter_one
Чего это не приняты? Даже такие штуки, как дублирующие друг друга по функционалу блоки, которые схемотехнически реализованы по-разному и работают на разном софте — это есть.
Ivanii
Ага, особенно заметно по www.svoboda.org/a/29863429.html есть 2 датчика и 2 компьютера но они работают ПО ОЧЕРЕДИ! один полет левый, следующий правый…
drWhy
И раз попеременность работы компьютеров, очевидно, не помогает — переполнение счётчиков, возможно, происходит не в них, а в промежуточных контроллерах.
Ivanii
Много глупее — на основании данных 1го датчика 1 компьютер(второй датчик и компьютер исправно работали, грели воздух) поборол пилота и разбил самолет, и так 2 раза, погибло 346 человек.
habr.com/ru/post/449564
Fedorkov
Может, fixed-point number с шагом 1/8 секунды.
А может, в битовом пакете выделили 29 бит, чтобы хватило на какое-нибудь взятое с потолка требование. В таких системах всё часто очень консервативно и низкоуровнево.
sergeyns
вообще тик в милисекунду, имхо, — это очень много для самолета. Должно быть ближе к микросекундам. Хотя кто из знает…
Nick_Shl
Реактивный двигатель может изменять мощность с микросекундной скоростью? А может сервопривод могут двигать управляющие площади с микросекундной точностью? Какую конкретно задачу вы собираетесь решать в самолете с таким тиком?
Nick_Shl
Конвертация. Реальный счетчик может считать быстрее, а нам надо в милисекундах, функция GetMs() внутри делает конвертацию. Самое поганое, что даже если есть проверка на переполнение — она не сработает. Потому что при конвертации переполнение происходит раньше, до реального переполнения типа данных.
Например при таймере типа uint32 и интервале 1 us и счетчик в ms будет обунляться каждые 4294967 ms, когда вы будете ожидать переполнение на 4294967295.
NetBUG
У меня один вопрос — почему в сетевом оборудовании ещё XX века нет таких косяков? Почему Ethernet-хаб за $5 не надо перезагружать каждый месяц, а у роутера аптайм в год?
tvr
Они недостаточно умны, поэтому им приходится работать.
AC130
В добавление к предыдущему комментарию: по той же причине их проще протестировать и отладить.
roscomtheend
Потому что роутер проще.
И что значит "не надо", достаточно на каком-нибудь TP-Link запустить большое число потоков с суммарной скоростью мегабит в 80 и переполнит какую-то таблицу внутри и перестанет пропускать трафик, любой (но к нему можно приконнектиться и рестартовать). Не каждые 149 часов, конечно, но если трафик появится снова, то они и 49 секунд не проживёт (считая время, необходимое для повторных соединений и роста скорости соединения). ASUS в той же ситуации перегреется, начнёт глючить и даже свой интерфейс отдавать кусками (вместо содержимого фрейма — содержимое вложенного в него, например, вообще не понятно как такое получается).
HardWrMan
Ethernet Hub перегружать действительно не надо — это же тупой повторитель. А вот Ethernet Switch — иногда надо. Особенно, если он управляемый и особенно до L3. А ещё, я получал случайное кольцо и хаб клал сегмент мгновенно, а свитч держался несколько секунд (за счёт кеша таблиц адресов).
chapter_one
Я просто отмечу, что эти 248 дней относятся не к генераторам (они никогда, вообще ни при каких условиях, не могут работать столько беспрерывно), а к GCU — generator control unit, который таки запитан всегда, когда на самолете включено питание. Эти же блоки выполняют еще ряд функций, к примеру, они задействованы в процессе запуска двигателей.
И все равно, я не могу себе представить ситуацию, в которой самолет не обесточивается больше 8 месяцев подряд. Сдается мне, что это чисто гипотетическая возможность, которой на практике просто не бывает, потому что такого быть не может никогда. Те же техники на дейли-чеках регулярно питание дергают.
khim
Точно также и Patriot'ы должны были регулярно перезагружаться…
chapter_one
787 — это не ракета на боевом дежурстве. Ну не бывает в природе ситуаций, когда на самолете ни разу не выключили питание за 8 месяцев. Это физически невозможно.
То есть у нас есть баг. Но этот баг не проявит себя никогда, если только самолет эксплуатируется обычным способом. Теоретически можно представить себе ситуацию, когда кто-то с очень большим кошельком купил себе 787 в варианте BBJ (не, это не то, о чем вы подумали, это Boeing Busines Jet) и по какой-то своей придури всегда держит свой самолет включенным. Если плевать на расходы от слова совсем, а так же на здравый смысл, а так же на регулярное обслуживание — то это чисто теоретически возможно. Регулятор отплевался от такой ситуации, выпустив AD.
Если почитать любые сайты, где ведется учет всех, даже самых ничтожных происшествий в авиации, то вы не найдете ни одного случая с 787, где бы проявился этот глюк.
corvair
То есть, это не баг, а фича.
HardWrMan
Принуждающая ребутить систему не дольше определённого периода?
TimsTims
Если бы самолёты стояли после перелётов по несколько дней в аэропортах, то аэропорты были бы ими забиты. К тому же парковка самолётов в аэропортах — довольно дорогое удовольствие, которое просто кушает деньги, но не приносит прибыли. Лучше самолёт отправить лететь, возить пассажиров и приносить деньги.
chapter_one
Даже если предположить, что самолет работает на рейсе, где всегда есть ровная загрузка (а таких рейсов не бывает в природе, существует как минимум сезонность), то есть действительно может летать с оборотами по часу в течении 8 месяцев по 24 часа в сутки, то линейное обслуживание все равно никуда не делось. Приличное количество вполне рутинных операций, которые техники проводят на борту, требует отключения питания. Нередко бывает, что самолет по неисправности встает под забор на сутки-двое пока логистика притащить нужную деталь: снова выключаем питание. Примерно раз в месяц делается А-чек и раз в 3-4 месяца B-чек. Там тоже дергают питание.
Откройте статистику налета по бортам любой авиакомпании, даже у самых агрессивных лоукостеров самолеты не летают больше 15-16 часов в сутки.
Вот как раз в авиакомпаниях абсолютно невозможна ситуация, чтоб на самолете за 8 месяцев ни разу питание не дернули. Это может быть только придурь какого-нибудь частного владельца.
old_bear
Как и обычно — сток глючит, приходится кастом накатывать.
Andrey_Rogovsky
Старый глюк лучше новых двух
Superkotik
Добрый день! У нас самолёт не взлетает. Перезагружать пробовали?
chapter_one
Будете смеяться, но с Эмбраерами действительно помогает.
OvO
Одна из моих любимых ошибок. Лет 10 назад я делал эмулятор для coldfire c периферией и одной из проблем было зависание программы внутри эмулятора через каждые 5 дней работы. Внутренний и внешний отладчики ничего внятного не показали, внутри все работало, но на вторые 5 дней стало ясно, что зависание происходит через фиксированный интервал времени, с точностью до минуты. После анализа интервала стало ясно, что он упирается в частоту сэмплирования звука для 32бит счетчика. Оказалось, что программа внутри эмулятора ждала прерывания от DMA звуковой карты которое не генерировалось, потому что счетчик загруженных сэмплов эмулятора звуковой карты за 5 дней переполнялся и становился меньше счетчика проигранных. А это являлось условием отсутствия и данных в буфере и необходимости в генерировании прерывания. Как можно догадаться, решением было увеличение счетчика до 64бит.
Am0ralist
И теперь он переполняется через сколько лет непрерывной работы?)
OvO
~220 лет, к тому времени я хочу увеличить счетчик до 128бит
drWhy
128 бит будет неактуально из-за прорыва в геронтологии и перехода на троичную систему счисления.
Vitalley
Ну так это не решение, вы просто отдалили проблему, очень сильно отдалили, но не решили.
OvO
Это называется баланс, я не сбиваю pipeline, не трачу ценные такты процессора, не ломаю архитектуру ради события, вероятность наступления которого ничтожно мала.