Не пропатчили: как один маленький баг угробил 28 американцев

via

Ни самая сильная армия в мире, ни штат программистов, ни новейшее вооружение не спасут от смерти, если в дело вмешаются математика и невнимательный кодер! Американцам пришлось прочувствовать эту истину на собственной шкуре.

Вечером 25 февраля 1991 года, уже под самый конец операции «Буря в пустыне», на американскую авиабазу в саудовском Дахране свалился иракский «Скад». Вот, казалось бы, причём здесь округление дробей?

Ракета разнесла казарму 475-го отряда квартирмейстерской службы армии США, ответственного за очистку воды. Взрыв убил 28 человек — это пятая часть всех погибших американцев за всё время войны в Заливе. Ещё около сотни получили ранения.

«Скад» был обнаружен радаром дежурной батареи зенитного ракетного комплекса Patriot, прикрывавшей Дахран. Ракету засекли… и ничего не сумели сделать. Осталось только наблюдать, как она валится на казарму.

Как выяснилось, вину за смерть 28 человек взял на себя софт зенитного комплекса.

Последствия от попадания "скада"

Давай округлим это по-быстрому

Баг в нём был простой, как кирпич. Не баг даже, а математическая фича: разработчики и военные о ней знали, и все на неё плевали, как на чепуховину ничего не значащую.

Внутренний таймер ЗРК Patriot устроен как счетчик количества интервалов времени, прошедшего с момента включения системы. Длина такого интервала — 0,1 секунды. Чтобы перевести количество этих отрезков в секунды, его, понятное дело, нужно разделить на 10. Что для этого предложили разработчики? Естественно, умножить на 0,1.

В машинной арифметике деление часто подменялось умножением на обратное число, так было проще проектировать вычислительные устройства и работали они быстрее. Метод умножения на обратное число, к слову, стар, как сама математика: его применяли ещё в древнем Вавилоне.

Теперь вторая часть Марлезонского кодирования. Числа-то двоичные.

Поэтому бодрые наследники древнего Вавилона из корпорации Raytheon вместо десятичного 0,1 загнали в систему двоичное число 0,00011001100110011001100. Оно немногим меньше требуемых 0,1 — примерно на одну десятимиллионную. Вот на это число радостно и умножили, полагая, что проблема решена.

Кодеры действительно были правы, когда клеили этот «лейкопластырь». При расчёте параметров движения цели система оперирует близкими значениями времени с единой и очень небольшой систематической погрешностью. Поэтому никаких проблем быть не должно. Ситуацию признали нормальной для использования в реальных условиях — и забили. В таком виде комплекс и приняли на вооружение в 1982 году.

Если вчера война

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

Весь этот арсенал создавал проблему. Потребовалось срочно переделывать батареи Patriot для Ближнего Востока, чтобы те могли перехватывать баллистические цели, идущие со значительной скоростью — 1700 м/с и больше. А это, считай, гиперзвук; и среди аэродинамических целей, под которые первые версии Patriot рассчитывались, такие скорости не встречаются. Им больше самолёты подавай или крылатые ракеты.

Raytheon начал спешно улучшать систему. И, как оно бывает, доулучшался. Некое кодирующее туловище невыясненного системно-аналитического образования придумало устранить баг с неточным определением 0,1 и написало новую процедуру умножения.

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

Теперь погрешности в математике ЗРК уже начали что-то решать, но об этом никто не думал. Потому что штатные проверки комплекса после переделки показывали, что всё ОК. Согласно программе испытаний: «Пункт 1: включили систему. Пункт 2: выставили режимы. Пункт 3: всё работает. Пункт 4: выключили. Переходим к следующему разделу».

Но никто не проводил «endurance test»: проверку на длительное дежурство на одном месте да против скоростных целей. А оно и зачем, если Patriot — это мобильный войсковой ЗРК для прикрытия боевых порядков? На одном месте ему по всем наставлениям стоять не следует, в том числе, в интересах собственной выживаемости.

Первыми за аномалию в работе комплекса зацепились не в США, а в Израиле. Развёртывающиеся боевые порядки страна прикрывать особо не собиралась, а вот собственная территория Израиль интересовала. Ну и по причине обычной национальной запасливости.

У ЗРК Patriot нет своих собственных накопителей для «логов» работы, поэтому комплексам полагались внешние. Но в армии США накопители не любили. Ходило вполне обоснованное мнение, что их софт какая-то очередная вавилонская ключница делала, и накопители периодически вешают всю систему. Поэтому операторы американских ЗРК на Ближнем Востоке их обычно не подключали, а вот в ЦАХАЛе всё сделали по инструкции.

Какой шлемазл это сделал?

Первые иракские «Скады» стартовали в сторону Израиля 18 января 1991 года. Израильские офицеры, однако, нашли время отсмотреть «логи». Уже 11 февраля от них в США прилетел первый «багрепорт»: после нескольких часов непрерывной работы ЗРК наблюдается необъяснимый дрейф параметров при переходе от режима обнаружения к сопровождению цели.

Радар при работе «на сопровождение» смотрит во вполне определенную узкую область пространства, где должна быть цель — так называемую «Range Gate Area», RGA. А ракета «Скада» быстрая, и надо чётко понимать, где она будет на следующем такте работы. Положение RGA определяется опережающим расчётом в зависимости от координат и скорости цели. А эта математика прямо завязана на точный отсчёт времени. А время у нас отсчитывается… ну, вы уже видели, как.

Это сообщение отредактировал УрусШайтанъ - 21.01.2018 - 10:53

И с каждым часом отсчитывается всё косячнее. Израильтяне увидели, что границы окна, обсчитанные на этом косячном времени, начали ехать. Цель уже не посередине RGA, а ближе к краю, за 8 часов смещение процентов на 20 от центра окна.

«Да ну, фигня, — отмахнулись генералы в Штатах. — У системы нормальный аптайм всего несколько часов. Зачем её вообще держать включённой постоянно? Ладно, по мере сил всё пропатчим и заапдейтим».

Надо заметить, что софтину ЗРК Patriot за тот нервный период с осени 1990 года перепатчивали уже аж шесть раз. Причем в пожарном порядке: надо было обучить аппарат противостоять иракским «Скадам» и «Аль-Хусейнам», и какая-то идиотская проблема многочасовой работы никого не волновала. Тем более, что накатывался один такой патч пару часов минимум, и всё это время комплекс должен стоять мёртвым куском железа. Кому это надо прямо во время войны?

Но 16 февраля патч таки написали и начали помаленьку ставить на комплексы. 21 февраля военное начальство, испытав нехорошее предчувствие в области собственных кресел, дополнительно разослало дежурную инструкцию для операторов ЗРК. Она состояла из одной фразы: не держите систему включённой «слишком долго», а то будут проблемы с захватом цели.

Но сколько это — «долго» — до разъяснений не снизошли.

Потом, после Дахрана, начальство оправдывалось, что полагало такое мудрое руководящее указание достаточным: догадаются, мол, сами. И вообще, война уже кончалась, все немного подрасслабились.

… Дежурная батарея «Альфа», принадлежавшая батальону, что прикрывал авиабазу Дахран, на вечер 25 февраля 1991 года имела аптайм больше четырёх суток. За этот период накопленная ошибка составляла уже 0,343 секунды. Для баллистической цели типа «Скада» это означало смещение центра RGA почти на 700 метров относительно реального положения ракеты. И это при габарите самого RGA около 300 метров.

Ракета «Скад» своё дело сделала.

А утром 26 февраля на Дахран приехали совершенно ничего не подозревавшие офицеры с накопителями. Они привезли… патч, исправляющий ошибку. Ну, просто по планам командования именно 26 февраля батарея «Альфа» должна была получить обновку. Раньше было никак: все борта на Ближний Восток забиты — всем что-то надо.

Борьба с дятлами

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

Во-первых, если вы склеили софт слюнями, и он заработал, отдавайте себе в этом отчёт. Умейте видеть пределы прочности ваших заплаток.

Во-вторых, если ваш костыль не создаёт проблем сейчас, никто не поручится, что это навсегда. Побольше думайте о режимах, в которых система может работать, и поменьше — о тех, в которых якобы должна.

В-третьих, когда вы что-то исправляете в уже работающей системе, посмотрите на её устройство сверху и подумайте, как ваши действия отразятся на том, что она ДО ВАС делала ВРОДЕ БЫ нормально.

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

Конец

В тему про кодеров:

Буратино дали три яблока. Два он съел. Сколько яблок осталось у Буратино? Думаете одно? Ничего подобного. Никто не знает сколько у него уже было яблок до этого. Мораль — всегда обнуляйте переменные!

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

Математика - она такая...

да у всех такое распиздяйство может быть.

28 американцев угробил не баг, а охуевание их правительства. Влезая в войну нужно чётко осознавать, что на войне есть жертвы.

Ошибки в программах часто приводят к отказам. Вот, например:

https://geektimes.ru/company/mailru/blog/285672/

Это сообщение отредактировал Zeitplan - 21.01.2018 - 11:06

Тема известная, но написано прикольно.

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

и поделом.

Отправлено с мобильного клиента YAPik+

Ну как бы всегда на ряды раскладывали, к примеру x/10 = x/16+x/32+x/256... и до необходимой точности...
Что-то я сомневаюсь в этом баге-фиче....

Это сообщение отредактировал Azazelius - 21.01.2018 - 11:18

Помню, тогда писали, на перехват одного СКАДа расход Пэтриотов - 3-4 шт.

С-300 тоже сразу парой ракет по одной цели шмаляет. И вероятность поражения цели при этом 0.8 что ли. Могу ошибаться.

ну так баг в том, что точность времени разная оказалась нескольких в компонентах ПО.
тут сами алгоритмы не причем.

Ну так израильтяне сами виноваты. Если о баге было известно и избавиться очень просто: перезагружай комплекс раз в 4 часа, то почему они держали его четверо суток включенным? Он же не один там на дежурстве стоял. Поочередная перезагрузка и всё пучком.

русских хакеров уже обвиняли? :)

какая модификация С-300? "П" , " В" или "Ф"?
расxод ЗУР от типа цели назначается

согласен полностью.
это не вина прогера - свою задачу он выполнил по поставленному ТЗ.

у меня недавно была схожая ситуация, когда сопрягались двумя железяшками (а на одной из них было мой код) - счетчик тактов 12 бит и он гарантированно переполнится через 48 часов работы. этот счетчик мной передается еще многим вышестоящим. 100% будет у кого-нибудь ошибка перехода через 0.
так всегда бывает - опыт имеется соответственный.
Заказчик сказал - "похер, протокол утвержден, изделие должно работать по ТУ 24 часа".

и кто тут дятел? я или заказчик?