Pull to refresh

Comments 16

Хорошая статья, познавательно.
Интересно было бы почитать о подобных случаях у нас. Особенно о принципах работы ПО Бурана, ведь у него был полностью автоматизирован вообще весь цикл полёта.
Если под «случаями» понимаются отказы, — Буран в своем первом и последнем космическом полете, к счастью, отработал как надо, если и были невыявленные проблемы в ПО, вряд ли мы теперь о них узнаем. Если под «случаями» понимается разработка сложных систем управления, то на сайте buran.ru есть некоторые данные.
Система управления Бурана — в источниках ссылки как раз на buran.ru
«У нас» было все куда хуже, судя по отзывам очевидцев.
buran.ru/htm/memory.htm
Я конечно понимаю, что это художественная литература (более того написанная англичанином об Америке:)), но как какая-то точка опоры:
«С плохо скрываемым раздражением он сказал:
– Вот уже сколько лет разбираю “фольксвагены”. И, черт возьми, качество всегда отменное.
Бретт кивнул в знак согласия:
– Хотелось бы, чтобы и о нашей продукции можно было сказать то же самое.
– Мне тоже хотелось бы, мистер Дилозанто. Но не получается. По крайней мере здесь» — Артур Хейли. Колеса.
Это я к тому, что вся авиация и космос не склонны верить, что качество их продукции идеально, поэтому все тестируется и проверяется.
Еще хотелось бы напомнить о катастрофе Челленджера в 1986, цитата из вики: «Комиссия пришла к выводу, что определяющими факторами, приведшими к катастрофе, послужили корпоративная культура и процедура принятия решений НАСА», по-моему очень хорошо коррелируется с информацией по вашей ссылке. Поэтому, чтобы сказать «куда хуже», нужно как минимум более детально рассмотреть кухню «у них».
В расчетное время на высоте 193 км аппарат включил двигатели на торможение. Через 5 минут MCO запланировано ушел за Марс и больше никаких сигналов с него не поступало. Из анализа данных было предположено, что аппарат прошел над поверхностью Марса на высоте 57 км вместо расчетных 110 км и распался в атмосфере. Столь большое отклонение было вызвано ошибкой в программном обеспечении миссии: команды по тяге двигателя в программном обеспечении Mars Climate Orbiter использовали единицу измерения силы ньютон (международная система единиц (СИ)), в то время как программное обеспечение на Земле, которое создавало эти команды, использовало британскую единицу измерения (фунт-сила).

Неудача упоминается как одна из возможных причин окончательного и полного перехода NASA на метрическую систему, объявленного в 2007 году.


Mars Climate Orbiter
Рано или поздно мы доживем до протоколов космической связи с системами типов, тогда можно будет явно указывать единицы измерения :)
100500 разных систем мер ненужны. От этого одни проблемы, а профита никакого.
Во всяких САПРах уже явно указываются единицы измерения, перерасчет в другие автоматически. Можно писать давление в мегапаскалях, а получить фунты на квадратный фут автоматически, без возможности ошибиться.
Спасибо за статью.

Отличная подборка проблем, которую должен знать и помнить каждый уважающий себя программист и тестировщик. В дополнение к каноничным историям про TERAC-25, и многочисленным проблемам на воде и в воздухе (последняя ссылка уже по всему инету лежит, взял первый попавшийся источник).
Пожалуйста, рад что понравилось:)
Спасибо за статью.

Я когда-то пытался в Педивикии Википедии создать статью о программных ошибках с названием что-вроде вроде «Хроника происшествий, аварий и катастроф, связанных с программными ошибками», но ее тут же выпилили за «орисность», и вот что от этого осталось (сорри за жуткий урл), а развивать дальше как-то стало сильно лениво

wiki.laser.ru/index.php/%D0%A5%D1%80%D0%BE%D0%BD%D0%B8%D0%BA%D0%B0_%D0%BF%D1%80%D0%BE%D0%B8%D1%81%D1%88%D0%B5%D1%81%D1%82%D0%B2%D0%B8%D0%B9,_%D0%B0%D0%B2%D0%B0%D1%80%D0%B8%D0%B9_%D0%B8_%D0%BA%D0%B0%D1%82%D0%B0%D1%81%D1%82%D1%80%D0%BE%D1%84,_%D1%81%D0%B2%D1%8F%D0%B7%D0%B0%D0%BD%D0%BD%D1%8B%D1%85_%D1%81_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D1%8B%D0%BC%D0%B8_%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B0%D0%BC%D0%B8

UFO just landed and posted this here
Дешевле, чем создание новой ракеты взамен взорвавшейся по причине выхода из строя непродублированного компонента.
И тем более, что тут речь идет о безопасности не только ракеты, но и экипажа.
Кусок все из той же статьи Джона Гармана: «Мысль о том, что такой баг в момент высокодинамичной стадии полета выведет из строя одновременно четыре, идеальные в остальных случаях, компьютерные системы и превратит космический аппарат в инертный каркас с горой плиток и проводов, была страшнее, чем проект мог вынести. Таким образом в 1976 г. родилась идея размещения альтернативного ПО на пятом бортовом компьютере». Т.е. мы говорим о дублировании дублированной системы ради безопасности.
Sign up to leave a comment.

Articles