«Летайте. Это безопаснее».
Это факт. Шансы в вашу пользу по сравнению с автомобильными путешествиями. Даже близко не стояли, часто напоминаем мы боящимся летать путешественникам.
Тем не менее, двое самых умных людей, которых я знал, отказываются летать, несмотря на согласие с этой статистикой. Я думаю о них каждый раз, когда сажусь в самолет. Ничего не изменилось, когда я возвращался из отпуска рейсом JetBlue, который прошел по части маршрута, которым несколькими неделями ранее летел другой рейс JetBlue.
Рейс, о котором идет речь, вероятно, также был полон отпускников. Аэробус A320 совершал перелет из Международного аэропорта Канкуна в Мексике в Международный аэропорт Ньюарк Либерти 30 октября 2025 года. Как сообщала на следующий день New York Times, пассажиры рейса 1230, вероятно, дремали через два с половиной часа полета из мексиканского курорта, когда их резко разбудило внезапное снижение высоты. Когда нежелательный акробатический маневр закончился, 15 или более пассажиров вынужденно продлили свой отпуск в больницах Тампы, куда пилотам JetBlue удалось успешно совершить экстренную посадку.
Представители JetBlue заявили, что самолет выведен из эксплуатации для проверки.
Иногда случаются сбои в коммерческой авиации, а также редкие катастрофы. Для летающей публики сообщения об этих сбоях достаточно регулярны, чтобы такая новость, как эта, могла быть спокойно отложена до тех пор, пока не проявится более широкая закономерность. Понятно, что если бы история закончилась на этом, особенно учитывая, что именно самолеты Boeing подвергались такому нежелательному волнению с начала проблем с 737 Max. Самолет, участвовавший в этом рейсе JetBlue, а также тот, в котором я теперь занимал место 23A, был Аэробусом, который, как полагают, в меньшей степени подвержен тому, что экспертная группа FAA в феврале 2024 года назвала «пробелами в обеспечении безопасности Boeing».
Это *этот* самолет, подумал я про себя. Что выявило последующее расследование? Механический сбой? Программное обеспечение, возможно, даже вредоносное ПО (хотя и очень маловероятно)?
«Причина»
The Times добросовестно сообщила о результатах этого расследования в статье, опубликованной 28 ноября 2025 года, в тот же день моего обратного рейса в JFK. Статья, частично адаптированная из пресс-релиза Airbus, начиналась так:
Европейский производитель самолетов заявил, что недавний инцидент показал, что «интенсивное солнечное излучение может повредить данные, критически важные для функционирования систем управления полетом».
Последствия для парка самолетов Airbus A320 и авиакомпаний, которые их эксплуатируют, будут широкомасштабными. Потенциально могут быть затронуты 6 000 самолетов, некоторые из которых потребуют аппаратных изменений, сообщила The Times, изучив масштабы выбора A320 авиакомпаниями по всему миру.
Это серьезное последствие, подумал я. А затем я прочитал:
В большинстве случаев проблема может быть решена относительно быстро путем возврата к предыдущей версии программного обеспечения.
Постойте.
«Сбой единичного события»
Итак, как часто происходит это воздействие излучения? Какова лежащая в основе физика?
Оказывается, здесь есть история, которую можно рассказать. Лауреат Нобелевской премии Виктор Гесс открыл существование космических лучей, измеряя уровни радиации на больших высотах во время полетов на воздушном шаре. Это было до Первой мировой войны. К 1960-м годам это стало проблемой для здоровья экипажа в космической программе. В статье 1975 года аномалия спутника была определена как «сбой единичного события» (SEU), вызванный излучением, а к 1979 году стало понятно, что электроника может быть нарушена на уровне моря.
К 1990 году FAA признала, что существует риск для авиапассажиров. Airbus A320, самолет с электронной системой управления (fly-by-wire), в большей степени полагающийся на компьютеры, был разработан в то время, когда это явление было хорошо изучено в сообществе авиационных инженеров.
Как понимали бы инженеры-программисты того времени, устранение SEU требовало бы аппаратных и программных функций. Например, памяти с коррекцией ошибок (ECC). Проверки на допустимость, тоже, на случай, если перевернутый бит приведет к выработке совершенно неверных инструкций.
Функции. Так почему же откат к более ранней версии программного обеспечения должен быть решением для A320 в конце 2025 года? Разве функции для устранения SEU от радиации в текущем выпуске не присутствовали бы и в более ранних выпусках? Или, возможно, существовал какой-то новый, инновационный способ устранения SEU, который заменил бы подходы, принятые в более ранних выпусках?
Основы управления жизненным циклом программного обеспечения
В этот момент инженер по качеству программного обеспечения во мне встрепенулся. Каким-то образом вся радиационная часть истории казалась любопытно нерелевантной.
Я был не единственным, кто задавал вопросы.
Тони Фернандес — основатель AirAsia Aviation Group. Текущие операции AirAsia включают значительное количество самолетов Airbus, и у компании есть заказы еще почти на 400 самолетов Airbus. Фернандес выразил свою обеспокоенность в недавнем интервью.
«Это кажется немного странным; это то, что [Airbus] должен рассмотреть, очевидно, это не было протестировано», — сказал Фернандес South China Morning Post. Фернандес предположил, что Airbus может испытывать давление из-за обязательств по достижению своей текущей цели производства 820 самолетов в 2025 году.
Помимо бросающейся в глаза истории о радиации, поверхностной причиной была названа проблема в программном обеспечении компьютера элеронов-стабилизатора (ELAC 2), который управляет тангажом и креном самолета, передавая команды с боковой ручки пилота на рули высоты в его задней части. Откат программного обеспечения включал восстановление версии под названием «L103», заменяющей «L104». Thales, разработчик аппаратного обеспечения ELAC, заявил Reuters, что задействованное программное обеспечение не входит в его компетенцию.
Внезапное движение носом вниз, испытанное пассажирами JetBlue, направлявшимися в Ньюарк, могло затронуть широкий спектр моделей Airbus, не только A320: затронуты также различные варианты серий A319 и A321. По одной из оценок, около 3000 самолетов A320 находились в воздухе примерно во время объявления Airbus. Представьте себе этих пассажиров 28 ноября, многие из которых имели доступ к Wi-Fi на борту, читающих об этой уязвимости программного обеспечения и мысленно пересчитывающих свои расчеты безопасности.
4 урока SDLC. 2 неотъемлемых риска непоколебимы
Помимо сенсационных разговоров о «солнечной радиации» или «космических лучах», существует серьезный разговор о жизненном цикле разработки программного обеспечения (SDLC) в Airbus. Я бы выделил эти четыре основных вывода, все они знакомы:
- Тестирование
- CI/CD и качество конвейера
- Наблюдаемость
- Цепочка поставок
Обратите внимание, что «кодирование» не входит в число выводов. Действительно, L104 мог ввести ошибку упаковки сборки или ошибку кодирования, такую как случайно удаленный вызов службы, неправильно настроенные или неправильно понятые параметры API, или даже синтаксическую ошибку в исходном коде. Все это нормально; здоровый SDLC их устраняет.
- Тестирование. Хороший тестовый фреймворк мог бы имитировать внешнюю телеметрию, которая должна была вызвать проверки диапазона для ELAC. Тестовые фреймворки должны разрабатываться и создаваться одновременно с программным обеспечением, а не как отдельный этап.
- CI/CD и качество конвейера. Вы можете добавить сюда управление изменениями или конфигурацией. Независимо от того, использовал ли Airbus CI/CD в своем конвейере SDLC в L104, он будет двигаться в этом направлении. Что-то сломалось в конвейере SDLC, что позволило этой фундаментальной функции «регрессировать». Причина, вероятно, не будет единичным случаем.
- Наблюдаемость. Я добавляю это отчасти потому, что являюсь членом небольшой рабочей группы в IEEE, работающей над новой версией стандарта DevOps, которая будет включать принципы наблюдаемости. SEU является отличным примером для наблюдаемости, поскольку инженер по тестированию не может ждать, пока ударит космический луч, но должен гарантировать, что отказ реагировать на критическое событие SEU может быть наблюдаем. Это включает в себя более тщательную разработку требований и понимание телеметрии, необходимой для критически важных функций.
- Цепочка поставок. Хотя Thales, возможно, не участвовала в проблемном выпуске L104, платформа Airbus включает программное и аппаратное обеспечение от многих поставщиков. Интеграция в цепочке поставок вычислительных систем представляет собой проблемы, усугубляемые как требованиями безопасности, так и желаемой долговечностью продукта. Очевидный ответ Thales «Не наша проблема» может указывать на проблемы с совместным использованием информации и решением проблем, или даже на ограниченную видимость для команды управления рисками третьих сторон.
Ситуация может ухудшиться, значительно ухудшиться. Пробелы в любой из этих четырех областей SDLC создают возможности для вредоносного ПО, что является кошмарным сценарием для авионики.
ИИ спешит на помощь?
Я опасаюсь, что два неотъемлемых риска остаются в значительной степени неустраненными: *сложность* и *специализация*. Управление всем набором функций A320, или даже его программным перечнем (SBOM / API-BOM), является нетривиальной задачей. Учитывайте, что это продукт, выпущенный в 1987 году, с необходимостью поддержки устаревшего оборудования и программного обеспечения для большой установленной базы. Как сложность, так и специализация будут неуклонно двигаться к большей непрозрачности, бросая вызов попыткам прослеживаемости, прозрачности и управляемости.
Несомненно, Airbus, как и все остальные, привлечет ИИ, чтобы помочь — возможно, в L105. Это увеличит как необходимые специальности, так и общую сложность самолета. Учитывая общее опасение по поводу ИИ, в какой момент большее количество путешественников почувствует, что шансы больше не в их пользу?
Эта статья опубликована в рамках сети экспертных авторов Foundry.
Хотите присоединиться?
Автор – Mark Underwood
