[image]

Patriot

и человеческий фактор
Теги:ПВО
 
LT Bredonosec #19.09.2019 20:14
+
+1
-
edit
 

Виктор Анисимов: Не обновили: как маленькая погрешность отправила в мир иной 28 американцев

Автор: ДаринаНи самые мощные вооруженные силы на планете, ни штат компьютерщиков, ни вооружение последнего поколения не защитят от гибели, если в дело вмешаются математические правила и нерадивый кодер! Американцы были вынуждены испытать это на личном опыте. Вечером 25.02.1991 г. незадолго до за? //  cont.ws
 

Вечером 25.02.1991 г. незадолго до завершения «Бури в пустыне» на авиационную базу ВВС США в Дахране упал иракский «Скад». На первый взгляд, округление дробей тут роли не играет. «Скад» попал в казарму 475-го отряда квартирмейстерской службы американских вооруженных сил, в задачу которого входила очистка воды. В результате взрыва погибло 28 солдат – 20% потерь США за все время проведения кампании. Около 100 военнослужащих были ранены.
 


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

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

Роковая математическая неточность

Ошибка оказалась элементарной: программистам и военным она была известна, но ее игнорировали, считая несущественной. Внутренний таймер комплекса представляет собой счетчик численности промежутков времени, истекшего с момента активации ЗРК. Продолжительность подобного временного промежутка составляет 0,1 сек. Для перевода численности данных интервалов в секунды, ее, разумеется, необходимо поделить на 10. С какой инициативой выступили программисты? Конечно, умножить на 0,1. В машинной математике деление нередко заменяли на умножение на обратное число. За счет этого было легче создавать вычислительные приспособления, и функционировали они шустрее.

Кстати, способ умножения на обратное число использовался еще в античном Вавилоне.

Потом следовала другая часть процесса кодирования. Дело в том, что числа представлены в двоичной системе. Точного выражения десятичной дроби 0,1 в двоичной форме нет – его можно сделать лишь примерным. В связи с этим сотрудники компании «Raytheon» число 0,1 решили представить как 0,00011001100110011001100. Данное число чуть меньше необходимой десятичной дроби – приблизительно на 0,0000001. На него и умножили, считая, что вопрос закрыт.
 


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

Неудачное улучшение

Летом 1990 г. войска иракского лидера оккупировали Кувейт. В распоряжении армии Ирака находились оперативно-тактические ракеты, самостоятельно улучшенные, а также химическое оружие. Все это несло нешуточную угрозу. Необходимо было быстро модернизировать ЗРК «Пэтриот» для Ближнего Востока, чтобы тот сумел перехватить баллистические ракеты, движущиеся на скорости 1700 м/с и выше. Корпорация-производитель стала срочно совершенствовать комплекс. Однако результат оказался прямо противоположным ожидаемому – система стала хуже.

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

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


Иначе говоря, в софте появилось 2 внутренних показателя времени, применяемых при вычислении различных характеристик. Чем дольше «Patriot» работал, тем ощутимее становилась разница. Но проблеме не уделяли должного внимания. Первой на данном вопросе зациклилась не Америка, а Израиль.

Какой дурак до такого додумался?

Первые «Скады» Ирак запустил по еврейскому государству 18.01.1991 г. Офицеры израильской армии не поленились изучить «логи». Уже 11.02.1991 г. они направили в Америку первый отчет, содержавший сведения о наличии ошибки: после нескольких часов бесперебойного функционирования комплекса наблюдается непонятное расхождение параметров во время перехода от режима выявления цели к ее сопровождению. Локатор при функционировании в режиме «на сопровождение» нацелен на определенную неширокую зону пространства, где должна находиться цель – т.н. «Рейндж Гейт Эриа» (RGA).

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

Позиция РГА вычисляется расчетом на опережение в зависимости от координат и быстроты перемещения цели. Данная математика имеет непосредственную связь с точным отсчетом времени. Вот здесь-то и скрывалась опасность, поскольку по вышеуказанным причинам ни о какой точности не могло идти и речи.
 


Час от часу расхождение во времени становилось все больше. Офицеры в Израиле обнаружили, что границы окна, установленные по неправильному времени, стали съезжать. Цель находилась уже не по центру «РГА», а ближе к краю. За 8 ч она сползала примерно на 20% в сторону от центра. Подсчитали и поняли, что спустя 20 ч бесперебойного функционирования цель покинет границы RGA, и тогда «Patriot» вообще не сможет захватывать цели на сопровождение, даже обнаружив их. Соответственно, комплекс потеряет возможность их сбить в полете.

Но руководство американской армии к отчету израильских военных отнеслось без должной ответственности. Понадеялись на русский «авось».

Следует сказать, что ПО системы «Пэтриот» за время, начиная с осени 1990 г., исправляли целых 6 раз. Причем в авральном порядке: требовалось научить комплекс бороться с иракскими «Аль-Хусейнами» и «Скадами». Какое-то глупое расхождение во времени никого не беспокоило. Вдобавок установка патча длилась не меньше 2 ч, в течение которых ЗРК превращался в обычную груду металлолома. Для чего это нужно, когда идут активные боевые действия?

Однако 16.02.1991 г. патч все же написали и стали постепенно устанавливать его на «Patriot». Через 5 дней после этого военное руководство, интуитивно предчувствуя надвигающуюся катастрофу, дополнительно отправило инструкцию для операторов «Patriot». Она включала единственную фразу, рекомендующую не держать ЗРК в рабочем состоянии чересчур длительное время, иначе возникнут сложности с перехватом цели. Конкретного допустимого периода бесперебойной работы не указали. …
 


У дежурной батареи «Альфа», относящейся к батальону, что защищал авиационную базу в Дахране, на вечер 25.02.1991 г. «Patriot» функционировал больше 96 ч. За данный срок разница во времени достигла 0,343 сек. Для баллистической ракеты она означала смещение центральной части «Range Gate Area» почти на 0,7 км относительно действительного местонахождения «Скада». И это при размере самого РГА примерно 0,3 км.

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

Таковы причины трагедии, унесшей жизни 28 человек. На следующее утро в Дахран прибыли ничего не знающие о случившемся офицеры, доставившие…патч, устраняющий баг.
   68.068.0
RU Zenitchik #28.09.2019 13:48  @Bredonosec#19.09.2019 20:14
+
-
edit
 

Zenitchik

втянувшийся

Боянище.

Проблема была в том, что в программе использовалось одновременно два разных алгоритма деления. Ну, что поделаешь, люди тогда ещё только учились, как не надо программировать.

А по существу - мне вообще непонятно, нахрена было делить. Чем их не устраивало время в десятых секунды? Для корректной работы алгоритма необходимо, чтобы время во всех его частях измерялось в одинаковых единицах, а секунды это или десятые от секунды... По хорошему вообще нужно стремиться к тому, чтобы выражать всё в целочисленных типах данных.
   74.0.3729.15874.0.3729.158
LT Bredonosec #28.09.2019 14:37  @Zenitchik#28.09.2019 13:48
+
-
edit
 
Zenitchik> Боянище.
так не спорю )
но почему-то здесь не освещалось.

Zenitchik> Проблема была в том, что в программе использовалось одновременно два разных алгоритма деления. Ну, что поделаешь, люди тогда ещё только учились, как не надо программировать.
и тут не спорю, собсно,об этом и написано )
Просто настойчиво лепится некий образ "суперлюдей", а люди там обычные, со своими проёпами, местами фееричными. :D
Хоть в данном случае - косяк классический: совершенствуя что-то, весь код проследить крайне мучительно, и потому где-то оставлены хвосты.

Zenitchik> А по существу - мне вообще непонятно, нахрена было делить.
в других случаях удобнее вычисление в секундах, как понимаю. Потому или тут или там, но менять размерность таки надо
   57.057.0
+
+1
-
edit
 

keleg
Владимир Потапов

опытный

Bredonosec> в других случаях удобнее вычисление в секундах, как понимаю. Потому или тут или там, но менять размерность таки надо
Там еще от внутреннего таймера сильно зависит. Не знаю, какое там железо, но точные таймеры в тех же IBM-совместимых компах появились совсем не сразу.
   68.068.0
+
+1
-
edit
 

Unix

опытный

Zenitchik> Ну, что поделаешь, люди тогда ещё только учились, как не надо программировать.

Чаавоооо?!?!? Это в 1990-91 году то "ещё только учились" ?!?!? :eek:

У них уже был "кровью написанный" милстандарт на всю эту область программирования.
Да почитай хотя бы как для Апполонов софт писали - а это, на секундочку, начало-середина 1960-х!!!

Zenitchik> А по существу - мне вообще непонятно, нахрена было делить.
А они и не делили, сюрпрайЗ! Они умножали. Почему так - объяснять?

Zenitchik> Чем их не устраивало время в десятых секунды? Для корректной работы алгоритма необходимо, чтобы время во всех его частях измерялось в одинаковых единицах, а секунды это или десятые от секунды...
Ну дык сам же себе ответил! Видимо только таймер выдавал не в секундах, вот и привели к общему знаменателю.

Zenitchik> По хорошему вообще нужно стремиться к тому, чтобы выражать всё в целочисленных типах данных.
Ну да, в конце СССР, на ЕС ЭВМ ещё, йуные проггеры тоже за это топили (это был я :) ). Это казалось очень обалденной идеей выражать деньги копейками и хранить в INT ...
А потом СССР и ЕС ЭВМ кончились и пришли писюки. А в 16-bit INT аж 650 рублей влазило, причём даже не советских деревянных, а уж совсем фантикоффф :D
Ну или посмотри на работу со временем в libc :eek:
... и вечная боротьба с Y2K, теперь вот с 2038 ...
Не надо всё в инты закатывать, надо понимать что там в реальном мире :)
   60.060.0
+
-
edit
 

Zenitchik

втянувшийся

Zenitchik>> Ну, что поделаешь, люди тогда ещё только учились, как не надо программировать.
Unix> Чаавоооо?!?!? Это в 1990-91 году то "ещё только учились" ?!?!? :eek:

Читайте полностью.
>учились, как не надо программировать.
жирный здесь не лишний.

Unix> А они и не делили, сюрпрайЗ! Они умножали. Почему так - объяснять?
А Вы читать, что там написано пробовали? Они решали задачу деления на 10. Старый алгоритм делал это с помощью умножения на 0.1, а новый - делал честное деление. Отсюда и проблема


Unix> Ну дык сам же себе ответил! Видимо только таймер выдавал не в секундах, вот и привели к общему знаменателю.
Там написано, что в двух разных алгоритмах использовалось время этого таймера, делённое на 10.

Unix> Ну да, в конце СССР, на ЕС ЭВМ ещё, йуные проггеры тоже за это топили (это был я :) ). Это казалось очень обалденной идеей выражать деньги копейками и хранить в INT ...
Эм... Простите, но вы с этим в конце СССР опоздали лет на 30. Штаты тогда свои деньги считали в сотых долях цента и выражали в типах с фиксированной запятой (считай тех же целых).

Unix> А потом СССР и ЕС ЭВМ кончились и пришли писюки. А в 16-bit INT аж 650 рублей влазило, причём даже не советских деревянных, а уж совсем фантикоффф :D

Unix> Ну или посмотри на работу со временем в libc :eek:
Unix> ... и вечная боротьба с Y2K, теперь вот с 2038 ...
Ой, не рассказывайте этих сказок про боротьбу с форматами времени. Судя по Y2K, подобные проблемы перестают быть проблемами обычно лет за 10 до названной даты.

Всё влезает куда надо и с нужной точностью. Пользоваться надо уметь.
   77.0.3865.9377.0.3865.93
+
0 (+1/-1)
-
edit
 

Unix

опытный

Zenitchik> Читайте полностью.
>>учились, как не надо программировать.
Ещё раз - цифровые управляющие компы у них появились за почти 30 лет до этого. Так что и опыт и методы и рукдоки - уже были. А лет так через 7 они их даже рассекретили. Читайте полностью ©.

Нет, не в этом дело! Просто они напортачили. Так бывает, увы. :(
А уж в сложных и долгих проектах, когда начинали\придумывали одни, делали другие, переделывали\добавляли фичи третьи, а убились вообще непричастные - сплошь и рядом :(

Unix>> Это казалось очень обалденной идеей выражать деньги копейками и хранить в INT ...
Zenitchik> Эм... Простите, но вы с этим в конце СССР опоздали лет на 30. Штаты тогда свои деньги считали в сотых долях цента и выражали в типах с фиксированной запятой (считай тех же целых).
Му-ха-ха, ну где ты такого упорина надыбал?! Каждое слово - "Это шедевр!" © С. Светлаков :D

Unix>> ... и вечная боротьба с Y2K, теперь вот с 2038 ...
Zenitchik> Ой, не рассказывайте этих сказок про боротьбу с форматами времени.
Сказок?! :eek: Y2K всего то 19 лет назад был ... Хммм ... Упс! Палишься же! :D
Zenitchik> Судя по Y2K, подобные проблемы перестают быть проблемами обычно лет за 10 до названной даты.
Правда? Ну Ок, следующая будет в 2038 - вот и посмотрим ...
Zenitchik> Всё влезает куда надо и с нужной точностью. Пользоваться надо уметь.
Ну извини! Вокруг то все - обычные, один только ты - умный.
"Предупреждать надо!" © Обыкновенное чудо :)
   60.060.0
+
-
edit
 

Zenitchik

втянувшийся

Zenitchik>> Читайте полностью.
>>>учились, как не надо программировать.
Unix> Ещё раз - цифровые управляющие компы у них появились за почти 30 лет до этого. Так что и опыт и

И что с того? Как НЕ НАДО программировать - это очень большая тема. Плохие практики обнаруживались и изучались вплоть до первого десятилетия нынешнего века. Не исключено, что до сих пор этот процесс идёт.
В 80-х же годах, существовал опыт только небольших проектов - измеряющихся килобайтами исходников. На таком объёме недостатки подходов практически не выявляются.

Unix> Сказок?! :eek: Y2K всего то 19 лет назад был ... Хммм ... Упс! Палишься же! :D

В том-то и прикол, что её не было. Только журналисты трепались, будто бы она есть, а она была уже чуть не 10 лет как решена.

Unix> Правда? Ну Ок, следующая будет в 2038 - вот и посмотрим ...

О подходах к её решению уже сейчас слышно. А уж за 19-то лет, не только проблема будет решена, но и все устройства, к ней уязвимые, выйдут из эксплуатации.

Unix> Ну извини! Вокруг то все - обычные, один только ты - умный.

Ну, это вы хватили "один". Целая отрасль, вообще-то.
   77.0.3865.9377.0.3865.93
+
-
edit
 

Unix

опытный

Zenitchik> >>>учились, как не надо программировать.
Unix>> Ещё раз - цифровые управляющие компы у них появились за почти 30 лет до этого. Так что и опыт и
Zenitchik> И что с того?
Ну ты же сам сказал, "оне же маленькие, они тогда только учились"!
А теперь внезапно: - "нет у революции конца!" ... или крест или трусы © народная мудрость

Zenitchik> В 80-х же годах, существовал опыт только небольших проектов - измеряющихся килобайтами исходников.
Посмотри софт для Appolo-11, только лишь два модуля выложили и это уже 1.2М в ZIP. А оно в 1969г уже летало.

Unix>> Y2K Сказок?!
Zenitchik> В том-то и прикол, что её не было.
Ну значит у меня старческий маразм, помню то, чего не было! :D:D:D
Zenitchik> Только журналисты трепались, будто бы она есть, а она была уже чуть не 10 лет как решена.
Да-да-да-д ©
Безобидная классика жандра [показать]
А не безобидную джапы засекретили :p

Unix>> Правда? Ну Ок, следующая будет в 2038 - вот и посмотрим ...
Zenitchik> О подходах к её решению уже сейчас слышно. А уж за 19-то лет, не только проблема будет решена, но и все устройства, к ней уязвимые, выйдут из эксплуатации.
Я это всё, один-в-один уже слышал 19 лет назад :)
Правда 2038 затронет только Unix-based да и то самых маленьких.
Но очень бы не хотелось, чтобы забыли какой нить грёбанный контролер на армолинуксе, замурованный в стену где нить в кишках АЭС :(

Zenitchik> Ну, это вы хватили "один". Целая отрасль, вообще-то.
Ну так на каком же семействе машин, эта целая отрасль американских финансов, "уже 30 лет как" к развалу СССР гоняли деньги, выраженные в сотых долях цента и хранимых в INT ?
Простой ведь вопрос, детский даже ;)
   60.060.0
+
+1
-
edit
 

tarasv

аксакал

Zenitchik> В 80-х же годах, существовал опыт только небольших проектов - измеряющихся килобайтами исходников.

Вы на несколько порядков ошибаетесь. Автоматизированная система ПВО США и Канады SAGE - 500тыс строк кода включая инструментарий, в основном на ассемблере. И это в 50е годы. Если брать бортовые системы то оригинальный софт Space Shuttle это больше 400тыс строк кода. Борт A320, "весил" в том-же районе. Это конец 70х - начало 80х. Так что опыт разработки больших систем к 80м был изрядный. Причем я бы оценил функциональную "плотность" строк того кода намного выше современного - не было тогда библиотек на полмиллиона строк только для рисования красивых картинок на дисплее в которые можно пальцем тыкать.
   77.0.3865.9077.0.3865.90

tarasv

аксакал

Zenitchik>> Только журналисты трепались, будто бы она есть, а она была уже чуть не 10 лет как решена.
Unix> Да-да-да-д ©

Ну скажем так - основную проблему представляли "специалисты по проблеме Y2K". Работал я на тот момент в ИТ финансового учреждения и был назначен ответственным за все что с Y2K связано. Группа работавшая над Y2K тратил больше своего рабочего времени на заполнение опросников от контрагентов как мы решаем эту проблему и посылание в правильном направлении "специалистов по Y2K" предлагавших свои услуги. То есть в моем случае отсутствие "специалистов по Y2K" как класса (все эти опросники, а заполнили мы их десятки, они-же и выдумывали) уменьшало бюджет потребный для реального решения проблемы если не в двое, то на треть точно.
   77.0.3865.9077.0.3865.90
RU mico_03 #08.10.2019 16:12  @Zenitchik#28.09.2019 13:48
+
-
edit
 

mico_03

аксакал

Zenitchik> А по существу - мне вообще непонятно, нахрена было делить. Чем их не устраивало время в десятых секунды?...

Ну например, если бы у них была синхронизация по СЕВ с чем то, ну и на экране отсчет в более крупных единицах с иногда более комфортен.

Zenitchik>... Для корректной работы алгоритма необходимо, чтобы время во всех его частях измерялось в одинаковых единицах,...

Для системного алгоритма сложного радиоэлектронного изделия это мечт без вариантов.

Zenitchik>... а секунды это или десятые от секунды...

Для того времени классикой жанра были термостабильные кварцевые генераторы (используемые в электронных датчиках времени) с гармоникой на выходе на 5 и 10 мГц, это период 200 нс и 100 нс. Поэтому для получения в единицах с всегда необходимо было преобразование.
   66
+
-
edit
 

Zenitchik

втянувшийся

Unix> Ну так на каком же семействе машин, эта целая отрасль американских финансов, "уже 30 лет как" к развалу СССР гоняли деньги, выраженные в сотых долях цента и хранимых в INT ?

На любом, тянущем COBOL.
Не в INT, а в типе с фиксированой точкой.

Вы вот лучше скажите, если Вам INTа не хватало, а типа покрупнее не было, то почему сами длинную арифметику не написали?
   77.0.3865.9377.0.3865.93
LT Bredonosec #10.10.2019 00:04  @Zenitchik#07.10.2019 16:09
+
-
edit
 
Zenitchik> В том-то и прикол, что её не было. Только журналисты трепались, будто бы она есть, а она была уже чуть не 10 лет как решена.
насчет 10 лет вы явно лишка хватили.
принципиальный путь решения был очевиден, конечно, задолго до прихода - увеличивать битность или считать вообще в секундах от некоего события (что тоже потребует роста битности)
А вот практическая реализация, с учетом наличия на руках большого числа систем, подверженных проблеме, - совсем другое дело. Потому и лепили патчи на что вспоминали и где вспоминали, и всё равно местами косяки вылезали.
   57.057.0
RU Zenitchik #16.10.2019 22:17  @Bredonosec#10.10.2019 00:04
+
-
edit
 

Zenitchik

втянувшийся

Bredonosec> принципиальный путь решения был очевиден, конечно, задолго до прихода - увеличивать битность или считать вообще в секундах от некоего события (что тоже потребует роста битности)

А ещё - интерпретировать годы меньше 50 как больше 100.
   77.0.3865.9377.0.3865.93
LT Bredonosec #16.10.2019 22:24  @Zenitchik#16.10.2019 22:17
+
-
edit
 
Zenitchik> А ещё - интерпретировать годы меньше 50 как больше 100.
кстати да, хоть оно и чревато багами, если хоть где-то забудут, и произведут арифметические операции как с нормальным числом.
   57.057.0
+
+1
-
edit
 

OAS

опытный

Bredonosec> А вот практическая реализация, с учетом наличия на руках большого числа систем, подверженных проблеме, - совсем другое дело. Потому и лепили патчи на что вспоминали и где вспоминали, и всё равно местами косяки вылезали.
Были и тогда "нормальные" системы. Взаиморасчёты между операторами связи по учёту входящих/исходящих звонков/трафика. Рядом банковская сфера по учёту переводов и обслуживанию счетов.
   69.069.0
AD Реклама Google — средство выживания форумов :)
+
-
edit
 
OAS> Были и тогда "нормальные" системы. Взаиморасчёты между операторами связи по учёту входящих/исходящих звонков/трафика. Рядом банковская сфера по учёту переводов и обслуживанию счетов.
хм... про банковскую - мягко говоря, не всегда )))
имел когда-то дела с софтом от местных банков, у каждого своя система, очень чувствительная к каждой запятой, и практически .... ну, скажем так, часто, приходилось потом на телефоне с уже хорошо знакомыми девочками из каждого общаться, улаживать вопросы на тему, где именно косяк..
А сейчас хоть и не имею с ними дел, но в курсе, что один очень большой европейский банк всё еще пользует некий софт где-то 10-летней давности, который почти столько же никем не поддерживается, и имеет некоторые конфликты с новыми осями, из-за чего приходится или держать старый комп, или как-то еще камлать в бубен )))
   68.068.0

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru