К Луне!

А чем бы тут помог дублирующий датчик?
 
А я всегда говорил, что этот мир погубят программисты!
Как и в большинстве проблем приписываемых программистам, тут виноваты составители ТЗ (isoace отдельно это подчеркнули, сказав, что хотя софт разрабатывала компания Draper, Ispace берет ответвеность за сбой на себя, так как ПО отработало а соответвии с ТЗ). Так что руки прочь от программистов
 
Ааа, так у них было ТЗ на софт!
С ТЗ и дурак сможет )))
 
Письба софта без requirements
- или никогда не кончается,
- или кончается плохо.
Да ладно, я сто раз так делал! Десятки из них нормально прокатило)))
Правда, я всегда с пиететом относился к людям, которые пишут код для бегающего, плавающего, летающего и т.д. У которых "ууупс" означает не "звони в бухгалтерию, пусть они там все откатят и руками проведут", а трахбабамс)))
 
Реакции: SDA
ТЗ составленное в голове, и даже прямо по ходу написания программы не перестает быть ТЗ как его не обзывай. "Хочу, чтобы при нажатии красной кнопки, в кофе добавлялся коньяк" - это ТЗ, А реализовать это в программе - это программирование. И если ТЗ у вас в голове и вы сами пишите программу, то вы, конечно, понимаете, что имеется в виду ваш кофе, а вот если вы то же ТЗ излагаете программисту, то потом не удивляйтесь, что коньяк льется в его кофе, а не в ваш
 
Программист не знает ничего(и не обязан) о компонетнах и порядке залива кофе в коньяк. это должны ему предоставить составители ТЗ, что, очевидно, японцы не сделали.
 
Да, не. Насколько я смог понять дело было так: разработчики зонда подумали: если откажет высотомер, в принципе сесть можно, примерно прикинув положение по расчетным данным и аккуратненько паркуясь до удара садясь пока не сядет. Но как понять, что высотомер показывает ерунду? Решили, сравнивать его показания с расчетным и если числа сильно отличаются, то считать высотомер врунишкой.
И вот в этом "сильно отличаются" и была загвостка: выбранная разница подходила для первоначального равнинного места посадки. И алгоритм прошел основную тщательную проверку. А затем поменяли место посадки на более пересеченную местность и тесты уже были не такими скурпулезными. И во время этих тестов разница в 5 км как я понял ни разу не попалась (видимо не прошерстили местность на предмет максимальных перепадов). А в реальном полете выпал блэк -джек наоборот - худший рельеф за границами протестированного. Такая вот невезуха.
 
Если я буду писать ТЗ с точностью до того, в чью кружку должен литься коньяк, то я буду молодец, но без работы.
Потому что илеалтное ТЗ нудно писать долгими месяцами.
А если пригласить толковых Программистов и дать им в ТЗ основные идеи, то дальше они сами всё расширят и углубят, напишут требования, и принесут мне на утверждение.
Таких мало... но они есть!
А те, кто отключает высотомер при любом алёрте, потому что в ТЗ чего-то там не дописали заказчики -- это кодеры, а не программисты.

По теме: Жалко девайс, разбили по глупости (
 
Зачем вы придумываете то,чего не было? Всё заказчики дописали. Просто после изменения места посадки указанное в ТЗ значение стало неверным. Никакой сколь угодно гениальный программист этого знать не мог. А вы хотите, чтобы программисты сами определяли значения физических величин от которых зависит поведение аппарата в полёте? Может программисты тогда будут и траекторию просчитывать, и научные задачи аппарату ставить и статьи в научные журналы писать по результатам исследований? Они у вас походу всезнайки
 
Это если программист в теме прикладной задачи. Не думаю, что на рынке много программистов, которые в теме полетов над Луной
 
какие данные стали неверными?
 
Вообще, конечно, интересный подход: считать датчик отказавшим, если данные кажутся нерасчетными. Чего бы тогда просто по расчётам не садиться... Второй датчик для сверки по массе не прошёл?
 
Чего бы тогда просто по расчётам не садиться.
похоже, что после отбраковки данных (датчик(и) корабля зафиксировали резкое изменение высоты, а ПО посчитало этот скачок аномалией) садились ориентируясья на высоту, рассчитанную в ходе симуляций.
 
ну вот и интересно, как они балансировали риск отказа датчика с риском ошибиться в расчетах. Вроде как датчик должен быть надежным достаточно, расчеты - хз. Короче, второй датчик зря зажали
 
Второй датчик показал бы тот же самый овраг.
Алгоритм пррверки входных данных оказался плохой.