OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 23 Октябрь, 2019 03:32

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 14 ] 
Автор Сообщение
 Заголовок сообщения: Arian-5
СообщениеДобавлено: Четверг, 25 Апрель, 2019 13:05 

Зарегистрирован: Пятница, 11 Январь, 2019 21:33
Сообщения: 30
Примерно с 13:30 про Arian-5 :
Дмитрий Дагаев писал(а):
Восемь смертных грехов профессиональных программистов
Дагаев Дмитрий Викторович, главный эксперт, АО «РАСУ», Росатом, Москва

https://youtu.be/5govjItgS3o


В ходе обсуждения, было признано полезным результаты "раскопок в стиле цифровой археологии" на январь 2019 ( https://stackoverflow.com/questions/527 ... 0#54345040 ) опубликовать в данном подразделе форума.


In short: it hasn't be pure programming problem, it's more complex problem

The defect on Ariane 5 was not caused by a single cause. Throughout the development and testing processes, there were many stages at which this defect could be identified.

  • The software module was reused in a new environment where operating conditions differed from the requirements of the software module. These requirements have not been revised.
  • The system has identified and recognized the error. Unfortunately, the specification of the error handling mechanism was inconsistent and caused final destruction.
  • An erroneous module has never been properly tested in a new environment — neither at the hardware level, nor at the system integration level. Therefore, the fallacy of development and implementation was not detected.

See diff with correct code:

Код:
--- LIRE_DERIVE.ads 000   Tue Jun 04 12:00:00 1996
+++ LIRE_DERIVE.ads   Fri Jan 29 13:50:00 2010
@@ -3,10 +3,17 @@
 if L_M_BV_32 > 32767 then
     P_M_DERIVE(T_ALG.E_BV) := 16#7FFF#;
 elsif L_M_BV_32 < -32768 then
     P_M_DERIVE(T_ALG.E_BV) := 16#8000#;
 else
     P_M_DERIVE(T_ALG.E_BV) := UC_16S_EN_16NS(TDB.T_ENTIER_16S(L_M_BV_32));
 end if;
 
-P_M_DERIVE(T_ALG.E_BH) :=
-  UC_16S_EN_16NS (TDB.T_ENTIER_16S ((1.0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH)));
+L_M_BH_32 := TBD.T_ENTIER_32S ((1.0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH));
+
+if L_M_BH_32 > 32767 then
+    P_M_DERIVE(T_ALG.E_BH) := 16#7FFF#;
+elsif L_M_BH_32 < -32768 then
+    P_M_DERIVE(T_ALG.E_BH) := 16#8000#;
+else
+    P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS(TDB.T_ENTIER_16S(L_M_BH_32));
+end if;



More detailed info:


A)
The “Operand Error” error occurred due to an unexpectedly large value of BH (Horizontal Bias) calculated by an internal function based on the value of the “horizontal speed” measured by the sensors on the Platform.

The value of BH served as an indicator of the accuracy of the Platform positioning. the BH value was much larger than expected because the flight path of the Ariane 5 at an early stage was significantly different from the flight path of the Ariane 4 (where this software module was used earlier), which led to a significantly higher "horizontal speed".

The final action, which had fatal consequences, was the termination of the processor. Accordingly, the entire Navigation System has ceased to function. It was technically impossible to resume her actions.


B)
However, Ariane 5, unlike the previous model, had a fundamentally different discipline for performing pre-flight actions - so different that the work of the fatal program module after the launch time did not make sense at all. However, the module was reused without any modifications .


The investigation revealed that there were as many as seven variables involved in type conversion operations in this software module. It turned out that the developers conducted an analysis of all operations that could potentially generate an exception for vulnerability.

It was their very conscious decision to add proper protection to four variables, and leave three - including BH - unprotected. The reason for this decision was the conviction that for these three variables the occurrence of an overflow situation is impossible in principle .

This confidence was supported by calculations showing that the expected range of physical flight parameters, on the basis of which the values of these variables are determined, is such that it cannot lead to an undesirable situation. And that was true - but for the trajectory calculated for the Ariane 4 model.

And the rocket of the new generation Ariane 5 was launched on a completely different trajectory, for which no evaluations were performed. Meanwhile, it (together with a high initial acceleration) was such that the “horizontal speed” exceeded the calculated (for Ariane 4) more than five times.

Protection for all seven (including BH) variables was not provided, because the maximum workload of 80% was declared for the IRS computer. Developers had to look for ways to reduce unnecessary computational costs and they weakened protection where a theoretically undesirable situation could not arise. When it arose, such an exception handling mechanism came into effect, which turned out to be completely inadequate.

This mechanism included the following three basic actions.

  • Information about the occurrence of an emergency situation must be transmitted via the bus to the onboard computer OBC.
  • In parallel, she - along with the entire context - was recorded in the reprogrammable EEPROM memory (which, during the investigation, it was possible to restore and read its contents).
  • The IRS processor was supposed to crash.

The last action turned out to be fatal - it was he who happened in a situation that actually was normal (despite the software exception generated due to an unprotected overflow), which led to the catastrophe.



C)
Velocity was represented as a 64-bit float
A conversion into a 16-bit signed integer caused an overflow
The current velocity of Ariane 5 was too high to be represented as a 16-bit integer
Error handling was suppressed for performance reasons

(
Protection for all seven (including BH) variables was not provided, because the maximum workload of 80% was declared for the IRS computer.
Developers had to look for ways to reduce unnecessary computational costs and they weakened protection where a theoretically undesirable situation could not arise.
)


According to a presentation by Jean-Jacques Levy (who was part of the
team who searched for the source of the problem), the actual source code
in Ada that caused the problem was as follows:

Код:
-- Vertical velocity bias as measured by sensor

L_M_BV_32 := TBD.T_ENTIER_32S ((1.0/C_M_LSB_BV) * G_M_INFO_DERIVE(T_ALG.E_BV));

-- Check, if measured vertical velocity bias ban be
-- converted to a 16 bit int. If so, then convert

if L_M_BV_32 > 32767 then
    P_M_DERIVE(T_ALG.E_BV) := 16#7FFF#;
elsif L_M_BV_32 < -32768 then
    P_M_DERIVE(T_ALG.E_BV) := 16#8000#;
else
    P_M_DERIVE(T_ALG.E_BV) := UC_16S_EN_16NS(TDB.T_ENTIER_16S(L_M_BV_32));
end if;

-- Horizontal velocity bias as measured by sensor -- is converted to a 16 bit int without checking P_M_DERIVE

P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS (TDB.T_ENTIER_16S ((1.0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH)));


The last line (shown here as two lines of text) caused the overflow,
where the conversion from 64 bits to 16 bits unsigned is not protected.
The code before is protected by testing before the assignment if the
number is too big.


The correct code would have been:

Код:
L_M_BV_32 := TBD.T_ENTIER_32S ((1.0/C_M_LSB_BV) * G_M_INFO_DERIVE(T_ALG.E_BV));

if L_M_BV_32 > 32767 then
    P_M_DERIVE(T_ALG.E_BV) := 16#7FFF#;
elsif L_M_BV_32 < -32768 then
    P_M_DERIVE(T_ALG.E_BV) := 16#8000#;
else
    P_M_DERIVE(T_ALG.E_BV) := UC_16S_EN_16NS(TDB.T_ENTIER_16S(L_M_BV_32));
end if;

L_M_BH_32 := TBD.T_ENTIER_32S ((1.0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH));

if L_M_BH_32 > 32767 then
    P_M_DERIVE(T_ALG.E_BH) := 16#7FFF#;
elsif L_M_BH_32 < -32768 then
    P_M_DERIVE(T_ALG.E_BH) := 16#8000#;
else
    P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS(TDB.T_ENTIER_16S(L_M_BH_32));
end if;


in other words, the same overflow check should have been present for the horizontal part of the calculation (E_BH) as was already present for the vertical part of the calculation (E_BV).


'Source:
http://moscova.inria.fr/~levy/talks/10e ... slongo.pdf
( On 2019-01-24 can be found at:
http://para.inria.fr/~levy/talks/10ensl ... slongo.pdf
)

https://habr.com/ru/company/pvs-studio/blog/306748/

----

prospero78 писал(а):
Не хотелось бы повторения даже на уровне "Ариан-5".
А там был даже не С++. Там была (. . .) Ада!!

В обощённом виде:
VM390 писал(а):
Всему виной дополнительным требования по загрузке компьютера на уровне 80% по мощности (хотя 100% загрузка бортового компьютера РН Ариан, в принципе тоже норма), из-за которых пришлось вводить ограничения на проверку параметров в коде. Плюс, грубая ошибка в использовании принципа «повторноиспользуемости кода», при отсутствии тестирования интеграции в условиях новых входных данных.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Негативные случаи в отрасли СУ
СообщениеДобавлено: Четверг, 25 Апрель, 2019 16:15 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 381
Откуда: Москва
А можно разбор Arian-5 в отдельную тему?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Arian-5
СообщениеДобавлено: Четверг, 25 Апрель, 2019 18:19 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 381
Откуда: Москва
Вот теперь можно и разобрать.
Во-первых, Ada тут не причем. "Дело было не в бобине, д..б сидел в кабине"

Вывод 1. Обработка ошибок.
Цитата:
The system has identified and recognized the error. Unfortunately, the specification of the error handling mechanism was inconsistent and caused final destruction

Разработчиков - направить на обучение (за их счет по коммерческим ценам) в Астрахань к В.В.Лаптеву, который им объяснит, что нужно проектировать обработку ошибок в ПО с самого начала. В.В. это объяснял на дне Оберона 2018. Иначе мы получили - final destruction.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Arian-5
СообщениеДобавлено: Четверг, 25 Апрель, 2019 18:33 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 381
Откуда: Москва
https://habr.com/ru/company/pvs-studio/blog/306748/
Цитата:
Это было их вполне сознательным решением добавить надлежащую защиту к четырем переменным, а три — включая BH — оставить незащищенными. Основанием для такого решения была уверенность в том, что для этих трех переменных возникновение ситуации переполнения невозможно в принципе.

Вот - этот код, в котором заблудились профессионалы
Код:
-- Horizontal velocity bias as measured by sensor -- is converted to a 16 bit int without checking P_M_DERIVE

P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS (TDB.T_ENTIER_16S ((1.0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH)));

Вот - эта функция TDB.T_ENTIER_16S (RealValue)
Она возвращает только INT-16-BIT, но где мы узнаем, что преобразование прошло корректно?
Почему не вернуть 2 параметра: INT-16-BIT и код завершения?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Arian-5
СообщениеДобавлено: Четверг, 25 Апрель, 2019 18:43 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 381
Откуда: Москва
Вот предлагается корректный код
Код:
L_M_BH_32 := TBD.T_ENTIER_32S ((1.0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH));

if L_M_BH_32 > 32767 then
    P_M_DERIVE(T_ALG.E_BH) := 16#7FFF#;
elsif L_M_BH_32 < -32768 then
    P_M_DERIVE(T_ALG.E_BH) := 16#8000#;
else
    P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS(TDB.T_ENTIER_16S(L_M_BH_32));
end if;

Но извините, если у нас входная величина C_M_LSB_BH = Nan, то мы получим исключение, только в другом месте.

Что делать? В таких системах все данные должны иметь коды качества и метки времени. Код качества (байт) имеет градации GOOD, BAD, UNKNOWN.
Перед преобразованием надо проверять коды качества
Код:
if GOOD(C_M_LSB_BH.Q) & GOOD(T_ALG.E_BH) then
  L_M_BH_32.V := TBD.T_ENTIER_32S ((1.0/C_M_LSB_BH.V) * G_M_INFO_DERIVE(T_ALG.E_BH.V));
  L_M_BH_32.Q := QGOOD;
else
  L_M_BH_32.Q := QBAD;
end;

Вывод 2. Не спроектирована обработка кодов качества сигналов.

Аналогично, в ветвях "if L_M_BH_32 > 32767 then" должен устанавливаться код качества типа BAD-MAX.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Arian-5
СообщениеДобавлено: Четверг, 25 Апрель, 2019 19:02 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 381
Откуда: Москва
Далее, обработчик исключений.
Надо правильно проектировать обработку исключений.

Например, берем активный объект A2. В конструктор вставляем инициализацию. А тело его с функцией старта делаем SAFE. И когда внутри возникает исключение, идет перехват и выполняется тело, начиная со старта. У меня такая штука трапилась 1 раз в полчаса, но стояла колом и памяти не жрала.

А тут не легковесный активный объект стартовал, а
Цитата:
termination of the processor
. Стало быть, сразу на перезагрузку.
Вывод 3. Не надо по всяким пустякам вырубать компьютер. Перезагрузка - операция небезопасная.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Arian-5
СообщениеДобавлено: Четверг, 25 Апрель, 2019 19:07 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 381
Откуда: Москва
Цитата:
При этом Бортовой Компьютер не мог переключиться на резервную систему IRS 1, так как она уже прекратила функционировать в течение предшествующего цикла (занявшего 72 миллисекунд) — по той же причине, что и IRS 2.

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

Вывод 4. Требования диверсификации проигнорированы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Arian-5
СообщениеДобавлено: Пятница, 26 Апрель, 2019 08:08 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1133
Откуда: СССР v2.0 rc 1
Я в ужасе.
Я думал, что я говнокод пишу, ан нет.
У меня гораздо приличней)) И сервер телемеханики работает неделями без падений (пока на новую версию не поменяю).
Как вообще у них ракеты летают?)))


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Arian-5
СообщениеДобавлено: Пятница, 26 Апрель, 2019 08:20 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 714
Откуда: Барнаул
Причем здесь говнокод? Были использованы блоки и по от Ариана-4, где это гарантированно работало. А в Ариан-5 оно уже не работало, но никто это не проверил и не протестировал, и вот результат. Ну это как в бб воткнуть чужой компонент, который когда-то отлично справлялся со своей задачей, но вот Инфо21 врубил массивы с нулевой длиной и фсё, взорвалась АЭС.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Arian-5
СообщениеДобавлено: Пятница, 26 Апрель, 2019 08:20 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 381
Откуда: Москва
Дмитрий Дагаев писал(а):
Например, берем активный объект A2. В конструктор вставляем инициализацию. А тело его с функцией старта делаем SAFE. И когда внутри возникает исключение, идет перехват и выполняется тело, начиная со старта. У меня такая штука трапилась 1 раз в полчаса, но стояла колом и памяти не жрала.

Вот даже кусочек кода
Код:
   Task* = OBJECT
      PROCEDURE &Init* (agent: Agent);
      BEGIN
         SELF.agent := agent; statrec.errcount := -1;
      END Init;
      
      PROCEDURE InitData;
      BEGIN
         agent.InitData; tAdvance := 0; tBefore := 0;
         IF statrec.errcount < 1000000000 THEN INC(statrec.errcount) END;
         Start
      END InitData;
      
      PROCEDURE Update*;
      BEGIN
      END Update;
      
   BEGIN {ACTIVE, SAFE}
      IF fin THEN
         BEGIN {EXCLUSIVE}
            dead := TRUE
         END
      ELSE
         InitData;
         LOOP
            BEGIN {EXCLUSIVE}
               AWAIT(fin OR (agent.tsp >= agent.start));
               IF fin THEN dead := TRUE; EXIT END;
            END;
            ...
            Update;
            ...
         END
      END
   END Task;

Если в Update унаследованного объекта возникал трап, то тело перезапускалось, начиная с InitData, увеличивая на единичку errcount.

Обработку ошибок нужно проектировать заранее.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Arian-5
СообщениеДобавлено: Понедельник, 29 Апрель, 2019 11:31 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1133
Откуда: СССР v2.0 rc 1
Kemet писал(а):
Причем здесь говнокод? Были использованы блоки и по от Ариана-4, где это гарантированно работало. А в Ариан-5 оно уже не работало, но никто это не проверил и не протестировал, и вот результат. Ну это как в бб воткнуть чужой компонент, который когда-то отлично справлялся со своей задачей, но вот Инфо21 врубил массивы с нулевой длиной и фсё, взорвалась АЭС.

У кода, как и у всего существующего под луной -- есть срок жизни. А ещё условия применимости, методы промышленной надёжности и т. п.
Поэтому:
1) Инфо21 может врубать что угодно, на атомную станцию, если Дагаев не стал полоумным -- это не попадёт. С учётом всех факторов -- вероятность нулевая.
2) Судя по тому, что всё отлично работало на Ариан-4, и ничего не менялось в Ариан-5 -- то, что взлетел Ариан-4 -- это просто удача. Но это также означает, что софт на Ариан-5 ровно такое же убожество, как и на Ариан-4.

8 миллиардов долларов коту под хвост.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Arian-5
СообщениеДобавлено: Понедельник, 29 Апрель, 2019 13:27 

Зарегистрирован: Пятница, 11 Январь, 2019 21:33
Сообщения: 30
prospero78 писал(а):
Kemet писал(а):
Причем здесь говнокод? Были использованы блоки и по от Ариана-4, где это гарантированно работало. А в Ариан-5 оно уже не работало, но никто это не проверил и не протестировал, и вот результат. Ну это как в бб воткнуть чужой компонент, который когда-то отлично справлялся со своей задачей, но вот Инфо21 врубил массивы с нулевой длиной и фсё, взорвалась АЭС.
. . .
2) Судя по тому, что всё отлично работало на Ариан-4, и ничего не менялось в Ариан-5 -- то, что взлетел Ариан-4 -- это просто удача. (. . .)


a) Другая траектория:
Цитата:
Ошибка произошла в компоненте ПО, предназначенном исключительно для выполнения «регулировки» Инерциальной Платформы. Причем этот программный модуль выдает значимые результаты только до момента H0+7 секунд отрыва ракеты со стартовой площадки. После того, как ракета взлетела, никакого влияния на полет функционирование данного модуля оказать не могло.

«Функция регулировки» действительно должна была (в соответствии с установленными для нее требованиями) действовать еще 50 секунд после инициации «полетного режима» на шине Навигационной Системы (момент H0-3 секунд), что она и делала.

Ошибка «Operand Error» произошла из-за неожиданно большой величины BH (Horizontal Bias — горизонтальный наклон), посчитанной внутренней функцией на основании величины «горизонтальной скорости», измеренной находящимися на Платформе датчиками.

Величина BH служила индикатором точности позиционирования Платформы. величина BH оказалась много больше, чем ожидалось потому, что траектория полета Ariane 5 на ранней стадии существенно отличалась от траектории полета Ariane 4 (где этот программный модуль использовался ранее), что и привело к значительно более высокой «горизонтальной скорости».


b) Похоже на некий "улучшатель" ( см. историю с тайным неотключаемым автопилотом фирмы B.),
слабо интегрированный в основной код:
Цитата:
При некотором маловероятном развитии событий взлет мог быть отменен буквально за несколько секунд до старта, например в промежутке H0-9 секунд, когда на IRS запускался «полетный режим», и H0-5 секунд, когда выдавалась команда на выполнение некоторых операций с ракетным оборудованием.

В случае неожиданной отмены взлета необходимо было быстро вернуться в режим «обратного отсчета» (countdown) — и при этом не повторять сначала все установочные операции, в том числе приведение к исходному положения Инерциальной Платформы (операция, требующая 45 мин. — время, за которое можно потерять «окно запуска»).


b.2) На практике, понадобилось один раз ( или близко к этому):
Цитата:
Однажды, в 1989 году, при старте под номером 33 ракеты Ariane 4, эта особенность была с успехом задействована.


Цитата:
Ариан-5
z) Посмотрите на WIKI историю запусков: 5 лет по запуску в год. ( И только потом . . .)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Arian-5
СообщениеДобавлено: Вторник, 30 Апрель, 2019 14:54 

Зарегистрирован: Пятница, 22 Март, 2019 07:50
Сообщения: 31
А интересно - нет никаких особо установленных правил (например, в атомной отрасли или авиации) по переиспользованию программных модулей в новой системе?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Arian-5
СообщениеДобавлено: Вторник, 30 Апрель, 2019 23:59 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8185
Откуда: Троицк, Москва
В Байкал.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 14 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB