«Известные события» привели к ожесточенным спорам в русскоязычных соцсетях, а также к интересу публики к военной технике — ведь уровень техники определяет исход современной войны. В первой части нашего цикла о багах в военной технике мы расскажем о багах в авиации и ПВО, наиболее известных к настоящему времени.
“Патриот” не видел цели
Международная коалиция во главе с США в начале 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%, в большинстве случаев.
Перед тем как разразилась “Буря в пустыне”, батареи “Пэтриотов” были отправлены в Саудовскую Аравию, но сначала в Израиль, который Саддам Хусейн усердно бомбил, считая не менее опасным противником чем США. Батареи размещались, в общем, на неподвижных позициях, для защиты важных объектов, американского персонала и союзников, и мирных жителей, от грозных ракет “Скад” советского образца, которых у Ирака было много (более 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 “мог неправильно управлять двигателем”, вызывая “внезапное и резкое повышение” оборотов, что “осложняло действия пилотов”.
Дублирование критически важной системы управления двигателем (было две “линии управления”, работавшие параллельно) — не помогло, поскольку проблема была “уровнем выше”, то есть на “центральном программном уровне». Интересно, что изначально производитель планировал сделать “почти аналоговой” резервную линию управления, но позже от этого решили отказаться, сделав обе линии “полностью цифровыми”, поддавшись веяниям моды на «все цифровое».
Как заявила британская комиссия, софт вообще-то проходил тестирование при приемке военными в США (и что характерно — прошёл это тестирование!), а далее британские военные приняли в эксплуатацию этот софт вообще не тестируя, слепо доверяя американской «экспертизе».
Где был баг
Проще сказать, где багов не было. Отчаявшись, ВВС Великобритании наняли независимых ИТ-экспертов, которые, проверив лишь 18% кода, нашли в нем 486, как сказано в отчете, “аномалий” (то есть четыреста восемьдесят шесть багов в проверенных 18% кода), “и на этом прекратили анализ”, видимо исчерпав терпение. Когда комиссия задала вопрос экспертам, «можно ли доверять этому коду» в целом, то эксперты ответили, что не знают, поскольку «не сумели прочитать этот код».
Эта же команда внешних специалистов определила, что из-за огромного количества багов поступали “постоянные ложные уведомления об ошибках в системе”; на это всегда жаловались пилоты “Чинуков” (а командование не обращало внимания). Но самыми опасными «программными» неисправностями были непредсказуемые и резкие повышения/понижения оборотов двигателей, особенно в момент взлета и посадки. Что очень опасно для такого технически сложного устройства как вертолет, тем более с двумя несущими винтами. Так что катастрофы были, судя по всему, неминуемы, исходя даже из количества «чинуков» на вооружении США и их союзников.
Конечно, софт с таким диким количеством багов был официально признан “совершенно неработоспособным”. Оказалось также, что подрядчик, создавший этот софт для “Боинга”, уже выплачивал компенсацию $3 миллиона за несоблюдение контракта; опять же неправильный код управления двигателем вызывал сильнейшие вибрации, что приводило к повреждению корпуса вертолета, причем это было еще во время наземных испытаний. Эту проблему как-то исправили, но оставались другие.
Всплыло также, что даже опытные пилоты отказывались летать на “чинуках”, по крайней мере пока производитель не приведет в порядок систему управления двигателем, и подавали соответствующие рапорты (на которые никто не обращал внимания).
Кроме того, отдельный модуль системы жизнеобеспечения, предназначенный как раз для отработки критических ситуаций, даже не проходил проверку соответствующего отдела в министерстве, и не получал сертификат пригодности — что отнюдь не помешало военным принять эти вертолеты в эксплуатацию.
Нашли также программные ошибки в модуле определения высоты, например в момент «контакта вертолета с землей» зафиксированное значение высоты «по приборам» составляло 143 м. И так далее.
Выводы?
Небрежность разработчиков и тестировщиков способна погубить большое количество военнослужащих, и «окирпичить» военную технику миллиардной стоимости.
***
Возможно, будет интересно также:
О чем спрашивают на собеседовании QA Junior: Selenium
