О фатальных программных ошибках и т.п.

При поиске информации по причинам катастрофы Ариан-5 нашёл пару интересных ссылок, и решил кинуть в отдельный топик:

Мифы о безопасном ПО: уроки знаменитых катастроф
_http://win.www.osp.ru/os/1998/06/21.htm



Разработка боевых программ в НИИ-5
_http://kis.pcweek.ru/year1999/N40/CP1251/Opinions/chapt1.htm

Большое спасибо за предложенные материалы. Особенно по Ариану и облучательной установке. Липаева-то я и так знал ... .
С программными ошибками мне приходилось сталкиваться в своей жизни, но нельзя, сказать, что часто. Я имею в виду действительно редкие и серьёзные ошибки, а не всякую шелуху, которая вычищается в первый месяц испытаний.
Запомнился один случай, он чем-то напоминает историю с облучательным аппаратом.
В комплексе "Строй-П" был реализован автоматизированный предстартовый контроль и пуск ДПЛА "Пчела". При подготовке ДПЛА к пуску двигатель (поршневой) автоматически заводился стартёром. Делалось три попытки прокрутки по 15 (?) секунд с перерывами по 30 (?) секунд. Если за три прокрутки двигатель не заводился, то диагностировался его отказ.
Так вот, на технической позиции проводили какие-то работы с двигателем (чего-то не ладилось с самим двигателем). ЭВМ выполнила две прокрутки. Двигателист дал команду оператору у пульта "Хватит". Оператор нажал кнопку "Отмена". Лампочка на кнопке не загорелась! Но никто не обратил внимания. Двигателист полез чего-то смотреть в карбюратор, как вдруг стартёр начал крутить двигатель! А на валу воздушный винт! А в карбюраторе - нос двигателиста! Двигателист оказался очень проворным и отскочил с неутраченным носом. Стартёр покрутил свои секунды, двигатель не завёлся, ЭВМ зафиксировала отказ и всё обошлось.
Оказалось, что в цикле работы программы для обработки чего-то очень важного каждую секунду на 20 мс запрещались прерывания. Оператор ткнул в кнопку именно в этот период. Поэтому и лампочка не зажглась. И команда "Отмена", естественно, не прошла... Ну, исправили, ясно дело. В ту же ночь...
А Вы спрашиваете, почему я программы сам пишу.

=KRoN=>При поиске информации по причинам катастрофы Ариан-5 нашёл пару интересных ссылок, и решил кинуть в отдебный топик:

=KRoN=>*Мифы о безопасном ПО: уроки знаменитых катастроф*
=KRoN=>http://win.www.osp.ru/os/1998/06/21.htm

Не там искал Я уже кидал это все в этот форум еще в мае...
Вот Мифы о безопасном ПО: уроки знаменитых катастроф

muxel>Не там искал Я уже кидал это все в этот форум еще в мае...
muxel>Вот Мифы о безопасном ПО: уроки знаменитых катастроф

Блин! Я точно помнил, что было на Авиабазе, но искалка ничего не нашла. Ни по одному из базовых ключевых слов! Ну ладно, слава Богу, всё нашлось

Про Amazon

Гнусная ошибочка. Я на 100% уверен, что ошибка не в процедуре составления уведомления. Просто она там проявляется. Найти будет трудно, особенно, если если программа многопотоковая.

Ch>Большое спасибо за предложенные материалы. Особенно по Ариану и облучательной установке. Липаева-то я и так знал ... .
Ch>С программными ошибками мне приходилось сталкиваться в своей жизни..

Соль в том, что (статью эту я давно читал -тоже из профессионального интереса, но не про Ариан )в случае с Арианом ОШИБКИ НЕ БЫЛО. Вернее не было ее в программе, она образовалась из свойств совершенно правильных подпрограмм.
мне собенно понравилась фраза "Собственно пуск Ариан-5 и был масштабной проверкой ПО"

Ник

Amazon снимает со счетов клиентов миллиарды долларов

Как сообщается на сайте www.theregister.co.uk, британское отделение интернет-магазина Amazon ведет борьбу со странными ошибками в системе обработки покупок, выражающимися в огромных счетах, выставляемых пользователям при покупке товаров по вполне обычным ценам.

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

Общая сумма: 14,58 фунта Стоимость доставки: 3,34 фунта Итого: 3 268 640,44 фунта

Обеспокоенные клиенты Amazon с облегчением узнали, что сумма в три миллиона долларов на самом деле не снимается с их кредитной карты - ошибка происходит только при создании уведомления о покупке. Еще один клиент Amazon сообщил The Register о получении им счета на 21 миллион фунтов. В другом уведомлении содержалась информация о покупке на сумму минус 922 триллиона фунтов. Пользователь, приславший данное уведомление, в отличие от других, пожалел, что на самом деле с его кредитной карты было снято 40 фунтов, а вышеозначенная сумма не была начислена.

// Компьюлента
// PC News, 11:44 14.06.2002

Продолаем разговор:

✂

В Американском космическом агентстве (NASA) объяснили причину неполадок в работе марсохода Spirit, контроль над которым не удается восстановить с 21 января. По словам менеджера программы Дженнифер Троспер (Jennifer Trosper), бортовому компьютеру марсохода не хватило памяти, чтобы сохранить и обработать весь объем информации, собранной на Красной планете и по пути к ней, сообщается на сайте газеты Los Angeles Times.

...

За семь месяцев полета марсохода и почти три недели работы на поверхности Марса память оказалась переполнена. В результате бортовой компьютер запустил бесконечный цикл перезагрузки.

✂

//

Марсоходу Spirit поставили память от цифровой фотокамеры

В Американском космическом агентстве объяснили причину неполадок в работе марсохода Spirit, контроль над которым не удается восстановить с 21 января. Как сообщила менеджер программы Дженнифер Троспер, бортовому компьютеру марсохода не хватило памяти, чтобы обработать весь объем информации, собранной на Красной планете и по пути к ней. По словам Троспер, Spirit оснащен 128-мегабайтным модулем памяти RAM и 256-мегабайтной флэш-картой. // lenta.ru

 

Что-то кто-то говорил некоторое время назад про то, что программированию обезьян удалось научить. Вот, наверное, они и писали.

По некотрым сведениям, в СССР, раньше программист, составлявший программы для космоса или оборонки лично отвечал за "каждый байт" своего творчества. Ошибки, конечно были, но не в таком объеме как сейчас.
А интересно, если написано что:

Nick_Crak, 14.06.2002 16:34:00:

Вернее не было ее в программе, она образовалась из свойств совершенно правильных подпрограмм.

 

не следует ли из этого, что применялось ООП? Вроде у простых подпрограмм побочных эффектов не должно наблюдаться?

Centuriones, 28.01.2004 00:43:31:

Вроде у простых подпрограмм побочных эффектов не должно наблюдаться?

 

Как раз у простых подпрограмм побочных эффектов выше крыши. Например, потому что простые подпрограммы направо и налево использую (обычно) глобальные переменные

Balancer, 28.01.2004 01:06:41:

Как раз у простых подпрограмм побочных эффектов выше крыши. Например, потому что простые подпрограммы направо и налево использую (обычно) глобальные переменные

 

Это невнимательность программиста, а не свойство подпрограмм.

2 Centuriones:
подпрограммой (от англ. subroutine, ещё со дней goto) обычно называют процедуры, у которых основной смысл - это побочные эффекты, в отличие от функций, под которыми подразумевают в большей или меньшей степени математические функции, т.е. отсутствие побочных эффектов. Это вопрос терминологии, но ИМХО Роман именно это имел ввиду.

Интересный инцидент произошёл с миссией Pathfinder в 1997-м году (взято с Embedded Systems, Conference, development,real-time, programming, emulators, multitasking, debugging, software,optimization, engineer, RTOS, chips, tools, microcontrollers,DSP,operating systems,kernel,microprocessors,object-oriented,single board,ada,C++,vi). В общих словах, имела место инверсия приоритетов в многопоточной программе управления этим средством.

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

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

В современных операционных системах как общего назначения, так и реального времени, инверсия приоритетов решается подьёмом (бустингом) низкоприоритетного потока до того момента, пока тот не отпустит конфликтный ресурс. Многие коммерческие юниксы и винды работают таким образом.

Мне кажется что программы в КА не должны быть многопоточными т.к. это неистощимый источник глюков.

Rada, 28.01.2004 05:07:05 :

подпрограммой (от англ. subroutine, ещё со дней goto) обычно называют процедуры, у которых основной смысл - это побочные эффекты, в отличие от функций, под которыми подразумевают в большей или меньшей степени математические функции, т.е. отсутствие побочных эффектов. Это вопрос терминологии, но ИМХО Роман именно это имел ввиду.

 

Это все так, но все эти побочные эффекты видны как на ладони, общеизвестны. Это камни, но не подводные. А вот в ООП многие камни подводные. Хотя вряд ли для программирования КА применяют ООП...

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

Centuriones, 28.01.2004 02:49:27:

Это невнимательность программиста, а не свойство подпрограмм.

 

Все программные ошибки - следствия невнимательности программиста (в широких смыслах этих терминов)

2 Centuriones:

А вот в ООП многие камни подводные.

 

Приведите примеры.

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

 

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

2 TEvg:

Мне кажется что программы в КА не должны быть многопоточными т.к. это неистощимый источник глюков.

 

На КА имеем кучу асинхронно работающих приборов и систем в реальном времени. Что будем делать?

Rada, 28.01.2004 19:22:42:

2 TEvg:

Мне кажется что программы в КА не должны быть многопоточными т.к. это неистощимый источник глюков.

 

На КА имеем кучу асинхронно работающих приборов и систем в реальном времени. Что будем делать?

 

Делаем все приборы синхронными и отрываем ноги инженерам!

А вообще-то заявление о том, что не надо многопоточности есть прямой отрыв от действительности. Программировать в терминах параллелизма намного сложнее. Профессионализм надо поднимать.

Rada, 28.01.2004 19:22:42:

>А вот в ООП многие камни подводные.
Приведите примеры.

 

C++:
a = b + c;
что оно делает?

C++:
a = b + c;
что оно делает?

 

Скажи мне что есть b и c, и я скажу тебе что такое a.

Rada, 28.01.2004 21:04:17:

C++:
a = b + c;
что оно делает?

 

Скажи мне что есть b и c, и я скажу тебе что такое a.

 

csStreamClass a;
csPipe b;
csAnyDrop c;

Описание каждого класса - на несколько экранов текста, со ссылкой на другие описания классов. Приводить тут лень

То что из внешнего вида операции не всегда можно понять её смысл не есть исключительный недостаток ОО языков. Например a = add(b, c), или (define a (+ b c)). Так что - не в тему. Жду примеры подводных камней именно ОО подхода, а именно - сокрытие информации, наследование, полиморфность - таково, насколько мне известно, определение ОО подхода.