Баги войны

Технический уровень определяет исход современной войны. В первой части цикла о багах в военной технике расскажем о багах в авиации и ПВО.

Патриот не видел цели

Международная коалиция во главе с США в начале 1991 года отправила массу войск на Ближний Восток, намереваясь нанести поражение исчадью ада — Саддаму Хусейну, который аннексировал Кувейт, нарушая все международные законы. Вокруг Ирака сосредоточилась крупнейшая группировка.

25 февраля одна из систем противовоздушной обороны на территории Саудовской Аравии, на берегу Персидского залива, не сумела перехватить иракскую ракету «Скад». Ракета достигла цели, поразив армейские бараки; погибли 28 американских военнослужащих. 

Причина: сбой в программе управления системы ПВО Пэтриот.

Компьютерная программа управления “Пэтриот” не сумела должным образом «отработать» подлетающую ракету. Баг в программе вызвал неточность отслеживания цели; неточность непрерывно увеличивалась; на момент «прихода» ракеты батарея работала уже 100 часов без перерыва и осмотра; из-за чего неточность определения координат вражеской ракеты достигла вышла за рамки допустимой.

До начала операции “Пэтриот” никогда не “работал” против ракет “Скад” в боевой обстановке. Никогда не функционировал непрерывно столь длительное время, и не был на это рассчитан изначально — предполагалось что батарея ПВО будет активно маневрировать, действуя где-то в Центральной Европе.

Интересно, что за две недели до инцидента Пентагон получил от Израиля своевременное уведомление о потере точности наведения на цель спустя 8 часов непрерывной работы.

Американцы, надо отдать должное, отреагировали: провели «рефакторинг» кода, пытаясь как-то удержать точность наведения. Однако, новую исправленную версию программы (на диске) не сумели вовремя доставить в саудовский Дахран. А с обновлением по интернету в те времена «все сложно».

Что такое Пэтриот

Система ПВО “Пэтриот” — мобильная ракетная система противовоздушной обороны. Ядро системы создано в середине 1960х, опыт войны во Вьетнаме. Находится на вооружении и сейчас, непрерывно обновляется и совершенствуется. Предназначена для поражения самолетов и крылатых ракет, позже и баллистических ракет. Изначально главный театр боевых действий — Европа (то есть знакомая местность, близость обслуживающего персонала, автобаны и маневренность). Предполагаемый противник изначально — очень мощная Советская Армия в ГДР, европейские союзники СССР с очень мощным вооружением; затем система дополнялась с учетом новых «изделий» советского/российского производства. 

Считалось, что “Пэтриот” будет эффективен против целей, идущих со скоростью до 2 Мах (две скорости звука, то есть около 600 метров/секунду). С самого начала систему предполагали очень мобильной. С одного места она должна была “работать” не более часа, максимум двух. Это-то и послужило одной из причин катастрофы в саудовской пустыне.

В составе стандартного ПВО-дивизиона коалиционных сил вторжения в Ирак в то время было обычно 6 (иногда 8) батарей “Пэтриот”; в каждой из батарей был радар для разведки и наведения на цель и отслеживания своей ракеты после запуска; станция управления для ручного/полуавтоматического управления ракетами; и машина для связистов. Ну, и собственно, самоходные платформы с ракетами.

Баг

Ракетами “Пэтриот” управлял достаточно мощный, в то время, компьютер. Однако он был разработан лет на 15 раньше, в 1970х. Поэтому с ограниченной вычислительной мощностью, что касается обработки вычислений с плавающей точкой, и длины регистров.

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

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

За ведение целей отвечал Range-Rate, специальный модуль в радаре. Когда радар находил воздушный объект с характеристиками, похожими на тактическую ракету «Скад», Range-Rate вычислял площадь в пространстве, на которую радар должен был “смотреть” в следующий момент времени. Алгоритм умел отфильтровывать «чужие» импульсы (то есть отраженные от воздушных объектов вне выделенной области и/или отправленные «чужой» батареей ПВО), и обрабатывал только данные, нужные для отслеживания, наведения и перехвата «своей» батарее. При появлении объекта с соответствующими характеристиками и в предполагаемой области, программа выдавала подсказку оператору.

Точка, где “Скад” должен был появиться в каждый следующий момент, вычислялась из комбинации данных о скорости цели и о предыдущей точке появления. Скорость “Скада” в системе выражалась как десятичное float-число с плавающей точкой (типа хххххххх.хххххххх миль/час). Время программа получала от отдельного модуля «внутренних часов» системы; изначально время выражалось в float, с точностью до десятых секунды (всего лишь — но это были Семидесятые), затем время переводилось в целое число (integer). Важный нюанс: чем дольше система работала, тем больше (длиннее) была переменная, выражающая время.

Для предсказания, где появится “Скад” в следующую секунду, обе переменных — и время, и скорость цели — должны были переводиться в число с плавающей точкой. Из-за особенностей компьютера “Пэтриота”, а именно того факта, что его регистры были (всего лишь) по 24 бита, преобразование времени из int-значения в float — не могло быть точнее, чем позволяли эти 24 бита. После инцидента в пустыне эти регистры сделали 64-битными.

Грубая программная ошибка на уровне проектирования вызывала потерю точности вычислений, а конкретнее потерю точности предсказания времени и места появления цели. Так называемое “окно”, в котором должна была появляться цель, система предсказывала с возрастающей ошибкой, и эта ошибка накапливалась пропорционально скорости цели, и времени от последнего включения компьютера «Пэтриота». 

Ошибка была известна разработчикам, но она почему-то не показалась им «критикал». Небольшой сдвиг “центра окна наведения”, точнее «несовпадение центра окна наведения с реальным центром цели» уменьшало вероятность успешного поражения. Ошибка составляла максимум 20%, в большинстве случаев. Это сочли несущественным.

Patriot Scad

Перед тем как разразилась “Буря в пустыне”, батареи “Пэтриотов” были отправлены в Саудовскую Аравию. Но сначала эти батареи повоевали в Израиле, который Саддам Хусейн усердно бомбил, считая не менее опасным противником чем США. Батареи размещались, в общем, на неподвижных позициях, для защиты важных объектов, американского персонала и союзников, также и гражданских объектов, от грозных в то время ракет “Скад” советского образца, которых у Ирака было уже очень много (более 1000).

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

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

Интересно, что Армия Обороны Израиля уже вовсю пользовалась дисками-”винчестерами” в своих “Пэтриотах”, и вовремя передавала американцам собранные данные. 

Нельзя сказать, что американское командование не знало о проблемах с наведением. Знал и производитель: центральный офис компании-подрядчика в “ракетной столице” США в Алабаме получил распоряжение исправить найденные/предполагаемые ошибки, а также подготовить систему к войне в пустынной местности. 

За время войны управляющие программы “Пэтриота” обновляли шесть раз.

Утром 11 февраля Армия США и производитель «Пэтриота» получили уведомление от Израиля об ошибке в 20% при определении цели после 8 часов непрерывной работы. А цель должна была быть всегда точно по центру «окна наведения», чтобы добиться высокой вероятности поражения (производителем заявлялось 80, а то и 90%).

В общих чертах, программа работала так: алгоритм проверял, является ли подлетающая ракета “Скадом, то есть совпадают ли характеристики; находится ли этот “Скад” в радиусе действия «своей» батареи; если оба условия — да, следовала команда-промпт запуска ракет.

Разработчик “Пэтриота” гарантировал в договоре с Армией США, что его система будет способна сбивать ракеты противника, если “окно наведения” по какой-то причине сдвинуто не более чем на 50%. Но поскольку ошибка быстро накапливалась со временем, то 20%-ный сдвиг за 8 часов суммарно «производил» явно больше чем 50% сдвига за 20+ часов. Спустя несколько суток непрерывной работы радар уже совсем не видел ни одной ракеты противника; точнее видел их, но в совершенно неправильной точке. Соответственно, батареям отдавалась некорректная команда.

Если время непрерывной работы компьютера достигало нескольких суток (что в боевых условиях было вполне реально), то ошибка времени могла превышать даже 1-2 секунды, а ошибка в расстоянии возрастала до 500-700 метров и более, что делало такую систему совершенно непригодной для перехвата «Скадов»; и это при баснословной стоимости «Пэтриота».

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

Роль сыграло еще то, что армейские чины почему-то с пренебрежением отнеслись к данным от Израиля, сочтя их «несущественными», а то и «случайными». Далее, командование почему-то не учло возможность того, что время боевого дежурства (то есть постоянной готовности батарей) почти наверняка будет превышать 8 часов.

Как оказалось, все же кто-то с запозданием, но принял во внимание израильские предупреждения, соответствующие распоряжения были отданы, и в программу срочно внесли правки, позволявшие компьютеру работать “несколько больше” чем 8 часов подряд; но эти обновления не были доставлены на все батареи вручную (и как мы знаем, интернета тогда не было).

Разработчик и владелец продукта, легендарная компания Raytheon, за неделю до инцидента отправила “клиентам” в саудовских пустынях уведомление: непрерывная работа приводит к некорректной работе компьютера, а следовательно непригодности всей батареи. И отправила “апдейт”. Но при этом не уточнила, какое время непрерывной работы все-таки допустимо; из-за чего у «клиентов» создалось ошибочное впечатление, что это время можно определять “на глазок”. 

Итак. Несколько батарей “Пэтриот” расположились в положенной точке, прикрывая аэропорт и морской порт. Нападения не исключали, но надеялись на совершенство американской техники (и отсталость советской). Батарея “Альфа” (у которой и возникли проблемы), прикрывала аэропорт. Эта батарея непрерывно работала более 100 часов. Как мы уже знаем, это приведело к потере точности; не позволило заметить и сбить запущенный по аэропорту “Скад”.

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

Неспособность сбить цель “сверхсовременной” системой ПРО, разрекламированной в американской прессе, представляемой американскому обывателю как «лучшая в мире, и конкурентов не предвидится», поражение от “древней” ракеты советского типа — разумеется это вызвало большой скандал в США. Лихорадочный рефакторинг кода в компьютерах “Пэтриотов” продолжался еще примерно полгода.

Небрежность

Итак, причиной катастрофы явилась пресловутая «ошибка округления». В последующие месяцы поступили уточненные данные. Вышла даже статья в главном американском научном журнале Nature. В статье говорилось, что “небольшая математическая ошибка позволила ракете пройти защиту ПРО”. Подробно объясняли обывателю, как внутренние часы компьютера “Пэтриота” выдавали небольшую ошибку при округлении в float-формат; что ошибка накапливалась пропорционально времени работы; всего лишь 0,0275 секунды за 8 часов — но уже 0,34 секунды за 100+ часов.

Подтвердились подозрения, что компьютер сверхсовременной системы ПРО, был явно устаревшим и недостаточно мощным, особенно что касается регистров для хранения критически важной, боевой информации. Из-за этого все переменные времени искажались на 0,0001%, что, как говорится в статье, “реально большое значение”. Время между импульсами радара также искажалось, почему “Пэтриот” и прошляпил удар, сокрушались учёные.

В прессе пылало возмущение: программы, в столь важной системе, как оказалось написаны на «каком-то» ассемблере начала 1970-х, и оставались, в целом, без особых изменений архитектуры вплоть до 1991 года. Вносились лишь «косметические» корректировки, в виде поправок, учитывающих возросшую скорость ракет предполагаемого противника.

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

Итак, непротестированный код стал причиной гибели десятков солдат. Ошибка по времени, крайне малого порядка, но накопленная за 100 часов непрерывной работы, создавала ошибку на серьезную величину в авиации — 0,34 секунды. За это время “Скад” успевал пролететь более полукилометра!

В процессе нашлись и другие грубые программные ошибки, из-за чего имидж “Пэтриотов” был подорван.

Падение “Чинука”

2 июня 1994 года вертолет “Чинук” Королевских Военно-Воздушных Сил Великобритании, перевозивший некий «важный персонал» на базу Форт-Джордж, разбился в тумане в горной местности Шотландии.

Погибли 29 человек, среди них 25 офицеров британской службы MI-5, армейские чины, а также видные специалисты по борьбе с терроризмом, работавшие в Северной Ирландии. Из-за этого поначалу не исключали версию теракта ИРА, тем более что после гибели специалистов “почти все контртеррористические операции в Северной Ирландии были вынужденно прекращены”.

Ошибка пилотов — причина крушения была названа с поспешностью, которая возможно и вызвала подозрения общественности. Авторитетный ИТ-журнал того времени “Компьютер Викли” поставил под сомнение вердикт. Собственное расследование журнала показало, что “скорее всего причиной был сбой компьютера, управляющего двигателем вертолета”. 

Характерно, что ситуация начала проясняться лишь спустя месяцы и годы после катастрофы, и лишь под давлением общественности. Палата Лордов прислушалась к аргументам прессы, посчитав их достаточными для проведения дополнительного расследования. Далее этот случай привёл к значительному улучшению качества управляющих ИТ-систем воздушной техники НАТО.

Оказалось, что армейское расследование по горячим следам было проведено халатно, даже несмотря на то что в катастрофе погибли “очень важные лица”.

Гражданское расследование “Компьютер Викли” продолжалось три года, и в 1997 журнал обнародовал доказательства, “в полной мере убедительные”, как признала Палата Лордов: не виноваты ни пилоты, ни ирландские/арабские террористы, были неправы те, кто обвинял пилотов, которые якобы «не освоили сложную технику», «любили лихачить», и “не умели летать в шотландском тумане”.

Палата Лордов, оценив весомость аргументов прессы, фактически заставила правительство «обнулить» выводы первой, внутренней военной, комиссии. “Непростительная неаккуратность пилотов RAF в обращении со сложной техникой” оказалась ложью, возмутились лорды, “мы имеем дело с крайне некачественным менеджментом ИТ-проектов в министерстве обороны”. Более того, было сделано внушение высшим чинам министерства, которые “халатно провели исследование причин катастрофы, огульно обвинили опытнейших пилотов с большим стажем, и не обратили внимание на плохое качество программного обеспечения и менеджмента”.

Нашлись ошибки и в программной, и в аппаратной части системы управления вертолетов “Чинук”. Проблемы, которые определились при расследовании второй комиссии: рычаги управления и кнопки, неудобные даже для опытных пилотов; несвязность управляющих ИТ-систем между собой; особое внимание лордов было обращено на “нестабильность работы двигателя из-за большого количества проблем в компьютерной системе управления двигателем — FADEC».

Код FADEC был таков, что даже после того как всем стало известно о проблемах, систему долгое время (месяцы) не удавалось исправить, она буквально кишела багами, и её фактически переписывали «с ноля».

Сыграло роль и то, что производитель/генеральный подрядчик “Чинуков”, могучий влиятельный “Боинг”, был, разумеется, не заинтересован в принятии вины на себя, и продолжал упорствовать, рассказывая о «человеческом факторе» и воспетом поэтами густом шотландском тумане. Моделирование катастрофы, проведенное “Боингом” в 1995 году, позволило компании ещё раз возложить вину, в целом, на пилотов; командование ВВС сейчас же согласилось снова, и это несмотря на гибель высших армейских чинов и нестыковки.

Ситуацию спасла свободная пресса. “Как можно полностью доверять одному подрядчику? Это приводит к катастрофам. Когда обычная ИТ-компания делает какой-то продукт, этот продукт тщательно тестируется. Сейчас же мы видим, что здесь вообще нет возможности установить истину, а следовательно исправить ошибки”. И далее, “производитель скрывает причины катастрофы, не говорит о проблемах в своих процессах и в управлении ИТ-продуктами. А ведь только у производителя есть доступ к внутренней кухне проекта, тем более проекта военного, с ограниченным доступом”. 

“А что если программная ошибка в системе наведения баллистических ракет приведет к разрушению города с мирным населением?”, вопрошал журнал “Компьютер Викли”, требуя допуска независимых экспертов. Под давлением общественности “Боинг” провел дополнительные симуляции последних секунд полета. Оказалось, что все-таки в “экстремальных случаях” компьютер FADEC “мог неправильно управлять двигателем”, вызывая “внезапное и резкое повышение” оборотов, что “осложняло действия пилотов”. 

Дублирование критически важной системы управления двигателем (было две линии управления, работавшие параллельно) — не помогло, поскольку проблема была “уровнем выше”, то есть на “центральном программном уровне». Интересно, что изначально производитель планировал сделать “почти аналоговой” вторую — резервную — линию управления, но позже от этого решили отказаться, сделав обе линии “полностью цифровыми”, поддавшись веяниям моды 1990х на «цифру».

Как заявила британская комиссия, софт вообще-то проходил тестирование при приемке военными в США (и что характерно — успешно прошёл тестирование!), а далее британские военные приняли в эксплуатацию этот софт вообще не тестируя, слепо доверяя американской «экспертизе».

Где таился баг

А проще сказать, где багов не было. Отчаявшись, ВВС Великобритании наняли независимых ИТ-экспертов, которые, проверив лишь 18% кода, нашли в нем 486, как сказано в отчете, “аномалий” (то есть четыреста восемьдесят шесть багов в проверенных 18% кода), “и на этом прекратили анализ”, видимо исчерпав терпение. Когда комиссия задала прямой вопрос собравшимся экспертам, «можно ли доверять этому коду» в целом, то эксперты ответили, что не способны компетентно ответить, поскольку «не сумели дочитать этот код».

Эта же команда внешних специалистов определила, что из-за огромного количества багов поступали “постоянные ложные уведомления об ошибках в системе”; на это всегда жаловались пилоты “Чинуков” (а командование не обращало внимания). Но самыми опасными программными неисправностями были непредсказуемые и резкие повышения/понижения оборотов двигателей, особенно в момент взлета и посадки. Что очень опасно для такого технически сложного устройства как вертолет, тем более с двумя несущими винтами. Так что катастрофы были, судя по всему, неминуемы, исходя даже из количества «чинуков» на вооружении США и их союзников.

Разумеется, софт с таким диким количеством багов был официально признан “совершенно неработоспособным”. На суде всплыло, что подрядчик, создававший этот софт для “Боинга”, уже когда-то платил компенсацию $3 миллиона за несоблюдение контракта; там дело было в том, что опять же неправильный код управления двигателем вызывал сильнейшие вибрации корпуса, что приводило к «усталости» и повреждению корпуса, причем такое случалось еще во время наземных испытаний. Проблему вибрации как-то исправили, но оставались другие.

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

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

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

Выводы?

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


Возможно, будет интересно также:

О чем спрашивают на собеседовании QA Junior: Selenium

Как ускорить тесты Selenium — полный гайд

Что ждет тестировщиков в этом году (спойлер: все хорошо)

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

1 КОММЕНТАРИЙ

Подписаться
Уведомить о
guest

1 Комментарий
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
елена
елена
17 дней назад

Да уж..человеческий фактор…айтишники лишают людей жизни.Ладно уж денег,но жизней…Мы движемся к апокалипсу и в этом нам поможет ИИ,созданный нашими руками.

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

? Популярное

? Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас