Здравствуйте, А почему вы спрашиваете, Вы писали:

АПВ>Здравствуйте, Трурль, Вы писали:

Т>>Здравствуйте, AVC, Вы писали:

AVC>>>Из отчета, ссылку на который дал Cyberax (за что ему отдельное спасибо, хотя не помню, чтобы мы хоть раз совпали во мнениях ), очевидно, что первопричина — в недостаточности вычислительных ресурсов. Соответствующую цитату из отчета я уже приводил.

Т>>Нет, первопричина — в пресловутом кодреюзе.

АПВ>Неа. Перворичина совсем в другом.

АПВ>Очень интересно, что все участники дискуссии полностью проигнорировали этот фрагмент отчета. Собственно, ничего удивительного в этом нет, это типичное заблуждение, которое заключается в том, что ПО можно сделать свободным от дефектов и предусматривать какие-то меры восстановления от программных сбоев нет необходимости. И это-то при том, что именно программные ошибки занимают второе место среди причин отказов информационных систем (первое место — cockpit failure), а аппаратные сбои только на третьем.

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

АПВ>На самом деле задача должна формулироваться так — необходимо сделать функционирование программно-аппаратного комплекса надежным даже в присутствии систематических дефектов софта, которых полностью избежать невозможно.

Вот, в статье, ссылку на которую предоставил AVM Re: Что толку в Ада если Ариан 5 все равно упал

Автор: AVM
Дата: 21.06.05

:

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

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

Здравствуйте, eao197, Вы писали:

АПВ>>Очень интересно, что все участники дискуссии полностью проигнорировали этот фрагмент отчета. Собственно, ничего удивительного в этом нет, это типичное заблуждение, которое заключается в том, что ПО можно сделать свободным от дефектов и предусматривать какие-то меры восстановления от программных сбоев нет необходимости. И это-то при том, что именно программные ошибки занимают второе место среди причин отказов информационных систем (первое место — cockpit failure), а аппаратные сбои только на третьем.

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

Пардон. Видимо, я пропустил начало.

АПВ>>На самом деле задача должна формулироваться так — необходимо сделать функционирование программно-аппаратного комплекса надежным даже в присутствии систематических дефектов софта, которых полностью избежать невозможно.

E>Вот, в статье, ссылку на которую предоставил AVM Re: Что толку в Ада если Ариан 5 все равно упал

Автор: AVM
Дата: 21.06.05

:
E>

E>В данном же случае, возникла систематическая программная ошибка; "систематическая" – в том смысле, что при повторении тех же входных условий, она обязательно возникнет вновь, ибо – тавтология здесь уместна – запрограммирована.

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

Угу. Систематическая, все верно. Вот следующий абзац из отчета:

Although the failure was due to a systematic software design error, mechanisms can be introduced to mitigate this type of problem. For example the computers within the SRIs could have continued to provide their best estimates of the required attitude information. There is reason for concern that a software exception should be allowed, or even required, to cause a processor to halt while handling mission-critical equipment. Indeed, the loss of a proper software function is hazardous because the same software runs in both SRI units. In the case of Ariane 501, this resulted in the switch-off of two still healthy critical units of equipment.

Как правильно обрабатывать сбои: когда проигнорировать и продолжить как будто ничего не случилось, когда упасть с предсметрным воплем, а когда поправить положение и повторить операцию — вот интересная проблема и тема для дискуссии. А на каком языке писать, чтобы избежать переполнения, — нет.

Здравствуйте, А почему вы спрашиваете, Вы писали:

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

АПВ>Пардон. Видимо, я пропустил начало.

Это не удивительно, т.к. начало было в глубине знатного флейма про must-die-мость C++ в "Священых воинах"

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

АПВ>Угу. Систематическая, все верно. Вот следующий абзац из отчета:
АПВ>

АПВ>Although the failure was due to a systematic software design error, mechanisms can be introduced to mitigate this type of problem. For example the computers within the SRIs could have continued to provide their best estimates of the required attitude information. There is reason for concern that a software exception should be allowed, or even required, to cause a processor to halt while handling mission-critical equipment. Indeed, the loss of a proper software function is hazardous because the same software runs in both SRI units. In the case of Ariane 501, this resulted in the switch-off of two still healthy critical units of equipment.

АПВ>Как правильно обрабатывать сбои: когда проигнорировать и продолжить как будто ничего не случилось, когда упасть с предсметрным воплем, а когда поправить положение и повторить операцию — вот интересная проблема и тема для дискуссии.
+1

АПВ> А на каком языке писать, чтобы избежать переполнения, — нет.
Именно так, но начиналось все с обсуждения недостатков C++, поэтому такой уклон в сравнении надежности языков в теме присутствует.

Здравствуйте, А почему вы спрашиваете, Вы писали:

АПВ>На самом деле задача должна формулироваться так — необходимо сделать функционирование программно-аппаратного комплекса надежным даже в присутствии систематических дефектов софта, которых полностью избежать невозможно.

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

А вот еще один взгяд на проблему: Peter Amey, Logic Versus Magic in Critical Systems

Здравствуйте, Трурль, Вы писали:

Т>Здравствуйте, А почему вы спрашиваете, Вы писали:

АПВ>>На самом деле задача должна формулироваться так — необходимо сделать функционирование программно-аппаратного комплекса надежным даже в присутствии систематических дефектов софта, которых полностью избежать невозможно.

Т>Согласен. Но, боюсь, очень сооблазнительно перейти от тезиса "В наших программах нет ошибок, потому что наши программисты их не делают." к тезису "Да, в наших программах есть ошибки, но это неважно, потому что наша система работает надежно даже в присутствии ошибок".

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

Здравствуйте, eao197, Вы писали:

E> Поэтому то, что Oberon/Java/C# сгенерирует out of bound exception в run-time, имхо, ничем не поможет программе, в которой это исключение совершенно не ожидалось. А ведь в подавляющем большинстве случаев оно не ожидается

Не верно.

Если генерируется out of bound exception то правильно спроектированная программа знает, что произошла непридведенная ошибка и предпринимает какие-то разумные действия (запись в лог, перезапуск, запуск в безопасном режиме и т.п.)

Если происходит выход за границы массива в C/C++, то насколько я понимаю скорее всего произойдет вообще непонятно какой сбой или даже программа будет работать какое-то время вообще в непонятно каком состоянии. Естественно такая ситуация много хуже первой.

Здравствуйте, AVC, Вы писали:

AVC>Но давайте рассмотрим факты.
AVC>Основная часть ПО Ариан-5 была унаследована от ПО Ариан-4.
AVC>Траектория полета Ариан-5 отличалась от траектории полета Ариан-4.
AVC>Горизонтальная скорость Ариан-5 была значительно выше, чем у Ариан-4.
AVC>Именно поэтому 64-битное число с плавающей точкой (double?) оказалось
AVC>невозможным привести к 16-битному знаковому целому без потерь.
AVC>Это и вызвало исключение.
AVC>Данная переменная была незащищена (unprotected) от подобного исключения.
AVC>Ясно сказано, что решение не защищать данную переменную от исключения
AVC>было принято сознательно.
AVC>По-видимому, чтобы не превосходить указанный лимит ресурсов в 80%.
AVC>Дальше много говорится об "анализе, котрый проделали, перед тем как принять
AVC>такое решение" и прочей безответственной чуши. Пожалуйста, вот Вам цена
AVC>всех этих "верификаций"!
AVC>Что значит — переменная незащищена? Значит ли это, соответствующее исключение
AVC>было аппаратным (вроде исключения при делении на нуль)?
AVC>В Обероне, если присвоение значения переменной может привести к потере информации,
AVC>требуется явно указать допустимость этой потери информации, иначе
AVC>компилятор не пропустит данный оператор присвоения.
AVC>Если же программист явно указывает допустимость такой ситуации,
AVC>то, конечно, никакого исключения сгенерировано не будет (или оно обязательно
AVC>будет перехвачено, если имеет аппаратное происхождение).

А меня это наводит на другие мысли.
1. Системное тестирование комплекса с новым датчиком не проводилось.
2. Данные о "подавленных" исключениях не были задокументированы, и/или не были проверены во время разработки и модульного тестирования.
Высоконадежный софт, ептыть

Здравствуйте, Airat Burganov, Вы писали:

AB>Здравствуйте, eao197, Вы писали:

E>> Поэтому то, что Oberon/Java/C# сгенерирует out of bound exception в run-time, имхо, ничем не поможет программе, в которой это исключение совершенно не ожидалось. А ведь в подавляющем большинстве случаев оно не ожидается

AB>Не верно.

AB>Если генерируется out of bound exception то правильно спроектированная программа знает, что произошла непридведенная ошибка и предпринимает какие-то разумные действия (запись в лог, перезапуск, запуск в безопасном режиме и т.п.)
В системе реального времени? Запуск в безопасном режиме? Остановите ракету, мне надо перегрузиться.

AB>Если происходит выход за границы массива в C/C++, то насколько я понимаю скорее всего произойдет вообще непонятно какой сбой или даже программа будет работать какое-то время вообще в непонятно каком состоянии. Естественно такая ситуация много хуже первой.
Однако C++ ничего не предпринимает чтобы запретить тебе контролировать выход за границы. Пользуйся объектами.

С уважением, Gleb.

Здравствуйте, eao197, Вы писали:

E>Да и Ада применяется только на Западе

У нас тоже кое-что на ней пишут. Знакомый как раз сейчас устраивается на работу "адским" программистом (МО РФ)

Здравствуйте, prVovik, Вы писали:

V>Здравствуйте, eao197, Вы писали:

E>>Да и Ада применяется только на Западе

V>У нас тоже кое-что на ней пишут. Знакомый как раз сейчас устраивается на работу "адским" программистом (МО РФ)

Чего в жизни только не бывает

Здравствуйте, Mr. None, Вы писали:

MN>А вот что-то не умирает он и до сих пор носится по двору без башки... Или даже я сказал бы так — одну отрубили, а 2 выросло...

Ага, осталось только определиться с разрядностью счетчика голов

Здравствуйте, AVC, Вы писали:

AVC>Кстати, интересно, кто-нибудь задумался, чтобы случилось, если бы вследствие этого выхода за границы диапазона исключения бы не было? Имеем: ракету рядом с земной поверхностью, "руководствующуюся" совершенно неверными данными.

В случае с Арианом-5 ничего бы не было. Ничего. Исключение возникло в "мертвом" коде, который кочевал из проекта в проект и в 5-м Ариане был не нужен. Там в отчете всё есть.

Здравствуйте, GlebZ, Вы писали:

GZ> В системе реального времени? Запуск в безопасном режиме? Остановите ракету, мне надо перегрузиться.

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

GZ>Однако C++ ничего не предпринимает чтобы запретить тебе контролировать выход за границы. Пользуйся объектами.

Да, да. А опасные возмоности С++ не применяй. А для чего их сделали?

Кстати, в STL из VC в std::vector нет проверок выхода за границы массива даже в безопасном режиме. Т от

*((&array[0]) - 10) = 12345;

никто не спасет. И не рассказывайте мне, что в ваших программах нет подобного кода.

Здравствуйте, А почему вы спрашиваете, Вы писали:

АПВ>Как правильно обрабатывать сбои: когда проигнорировать и продолжить как будто ничего не случилось, когда упасть с предсметрным воплем, а когда поправить положение и повторить операцию — вот интересная проблема и тема для дискуссии. А на каком языке писать, чтобы избежать переполнения, — нет.

Я думаю, что Вы правильно сформулировали один из главных вопросов, на которые хотелось бы найти ответ.
Что делать с ошибками и сбоями (раз уж они случились)?
Как выстроить вторую (третью, четвертую, пятую) линию обороны в mission-critical системах?

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

Все же тема языка должна навести нас и на другую тему: предотвращение ошибок.
Вот здесь-то я и загрустил.
Я понял, что недостаточно разбираюсь в самом понятии ошибки.
До тех пор я настаивал (и сейчас настаиваю, хотя в голове у меня завелись тараканы беспокойства), что программа (вроде ПО Ариана) должна быть корректной, а не просто "надежной".
Но что такое корректность? Соответствие спецификациям?
Я думаю, такая корректность в принципе достижима.
Но как удостовериться, что сами спецификации полностью соответствуют объективной реальности и не оставляют "щели" для катастрофы?
Такая задача кажется мне невыполнимой.
Выясняется, что сама борьба с ошибками — творческое дело. Надо уметь думать о том, о чем ты думать не можешь, так как не знаешь этого, или оно просто не приходило тебе в голову.
Творчество — это хорошо, но оно, в отличие от рутины, всегда связано с ошибками, а значит — с риском.

Другая причина для беспокойства в том, что, возможно, не существует абсолютных решений даже одной единственной проблемы.
Вероятно, именно это имел в виду Трурль, когда говорил, что "причина в пресловутом кодреюзе".
Я тогда не оценил эту мысль и ответил примерно так, что, если бы программа была корректной, то Ариан бы не упал.
Но между самой совершенной моделью и реальностью всегда существует некоторая дистанция.
Поэтому надо каждый раз заново проверять применимость вчерашних решений.
Выбор рабочей модели похож на попытку укрыться коротким одеялом: укутаешь плечи, высунутся ноги.

Здравствуйте, A.Lokotkov, Вы писали:

AVC>>Кстати, интересно, кто-нибудь задумался, чтобы случилось, если бы вследствие этого выхода за границы диапазона исключения бы не было? Имеем: ракету рядом с земной поверхностью, "руководствующуюся" совершенно неверными данными.

AL>В случае с Арианом-5 ничего бы не было. Ничего. Исключение возникло в "мертвом" коде, который кочевал из проекта в проект и в 5-м Ариане был не нужен. Там в отчете всё есть.

Мне кажется, если в коде возникло исключение, то он не "мертвый".
Почему-то вспоминается ехидная фраза Пуанкаре: "Логистика (=матлогика теперь) более не бесплодна: она порождает ошибки!"

Здравствуйте, AVC, Вы писали:

AVC>Но что такое корректность? Соответствие спецификациям?
AVC>Я думаю, такая корректность в принципе достижима.
AVC>Но как удостовериться, что сами спецификации полностью соответствуют объективной реальности и не оставляют "щели" для катастрофы?
AVC>Такая задача кажется мне невыполнимой.

Теоретически это так и есть. Но на практике имеются способы повысить уверенность в соответствии спецификации тому, что мы на самом деле имели в виду. Рекомендую в связи с этим посмотреть систему PVS. Это — система именно для нахождения "дыр" в спецификациях.

Вкратце идея такова. Спецификация описывается на формальном языке PVS в виде аксиом, предположений и т.п. Эти аксиомы и соответствуют спецификации на программу. Затем мы начинаем выдвигать различные "теоремы", т.е. предположения о поведении программы в тех или иных ситуациях. Если эти предположения верны, т.е. выводятся строго формально из наших аксиом, уверенность в том, что эти аксиомы полны и непротиворечивы, повышается. Абсолютной гарантии это не дает, но по крайней мере позволяет выявлять неочевидные ошибки еще на стадии проектирования.

PVS использовался для верификации IEEE 854 floating point specification. Для подробного знакомства нужно посмотреть сайт или почитать хотя бы первю главу вот этого учебника: http://www.csl.sri.com/papers/wift-tutorial/

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, GlebZ, Вы писали:

GZ>> В системе реального времени? Запуск в безопасном режиме? Остановите ракету, мне надо перегрузиться.

VD>В любой системе. Подумай что было бы если этот Ариан взорвался от ошибки в С++-программе? Попортили память... логов нет... Программа закончилась аварийно... Запускаем еще один спутник в отдалочный целях... а вось когда он грохнет мы поймем, что было тому причиной.

То, что ПО для Ариан-а было написано не на C++, сильно смягчило потерю полумиллиарда долларов
Сразу стало легче на душе.

GZ>>Однако C++ ничего не предпринимает чтобы запретить тебе контролировать выход за границы. Пользуйся объектами.

VD>Да, да. А опасные возмоности С++ не применяй. А для чего их сделали?

Для возможности выжать максимум производительности.

VD>Кстати, в STL из VC в std::vector нет проверок выхода за границы массива даже в безопасном режиме. Т от
VD>

VD>*((&array[0]) - 10) = 12345;
VD>

VD>никто не спасет. И не рассказывайте мне, что в ваших программах нет подобного кода.

Таки нет.

Здравствуйте, AVC, Вы писали:

AL>>В случае с Арианом-5 ничего бы не было. Ничего. Исключение возникло в "мертвом" коде, который кочевал из проекта в проект и в 5-м Ариане был не нужен. Там в отчете всё есть.

AVC>Мне кажется, если в коде возникло исключение, то он не "мертвый".
AVC>Почему-то вспоминается ехидная фраза Пуанкаре: "Логистика (=матлогика теперь) более не бесплодна: она порождает ошибки!"

Как было сказано в одном постов этого треда, проблема ариана-5 -- проблема управления конфигурациями ПО. 99% остальных сообщений в этом треде, касающихся языков программирования, с проблемой ариана-5 не связаны. Хотя, конечно, можно очень постараться и связать их, например, высказав утверждение, что современные широко используемые языки программирования общего применения, в которых явно не представлен координационный слой, заведомо не приспособлены для создания сложных программных систем, особенно реального времени и, не дай Бог, распределенных. Явное и неявное приведение типов, исключения, синтаксический сахар и прочие механизмы, удачные и не очень, -- детский лепет по сравнению с реальными проблемами, возникающими при создании систем управления вроде той, что летает на арианах.

Здравствуйте, VladD2, Вы писали:

GZ>> В системе реального времени? Запуск в безопасном режиме? Остановите ракету, мне надо перегрузиться.

VD>В любой системе. Подумай что было бы если этот Ариан взорвался от ошибки в С++-программе? Попортили память... логов нет... Программа закончилась аварийно... Запускаем еще один спутник в отдалочный целях... а вось когда он грохнет мы поймем, что было тому причиной.
Ага. Только наверняка там стоял DrWatson, пдбешки и все заключено в ATLTrace и ему подобное. Главное чтобы драйвера от видео-карты не подкачали.

GZ>>Однако C++ ничего не предпринимает чтобы запретить тебе контролировать выход за границы. Пользуйся объектами.
VD>Да, да. А опасные возмоности С++ не применяй. А для чего их сделали?
Производительность vs Надежность.

VD>Кстати, в STL из VC в std::vector нет проверок выхода за границы массива даже в безопасном режиме. Т от
VD>

VD>*((&array[0]) - 10) = 12345;
VD>

VD>никто не спасет. И не рассказывайте мне, что в ваших программах нет подобного кода.
Не-а. На С++ у меня другой код с другими подобными фичами и в большом количестве. Есть некоторые правила которые я выполняю (типа smart pointers и т.д.). Сверх того не собираюсь. Ну не полетят мои программы в космос. А если бы и полетели, то на фиг они там кому-то сдались.
Мне значительно проще и легче контролировать именно себя чем активно реализовывать программы чтобы контролировать ошибки которые я мог бы сделать. А в космосе нужны меры именно предупреждающего контроля. Как-то слыхал какую вероятность отказа высчитывали наши для каждой подсистемы ракет. Цифру не помню, но она впечатляла. Достичь ее наверняка можно даже если пишешь на машинных кодах. Просто это будет дольше по времени и дороже.

С уважением, Gleb.

Здравствуйте, A.Lokotkov, Вы писали:

AL>Явное и неявное приведение типов, исключения, синтаксический сахар и прочие механизмы, удачные и не очень, -- детский лепет по сравнению с реальными проблемами, возникающими при создании систем управления вроде той, что летает на арианах.

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