Комментарии 73
Тут в общем два вопроса возникают с точки зрения логики. Во-первых, если заранее было известно, что работать надо ровно 84 секунды, то зачем же ставить будильник на 127, и к чему тогда нужны показания акселерометра? И во-вторых, почему там не было продублировано как на обычном гражданском самолёте, когда показания двух датчиков (ула атаки, к примеру) перекрёстно обрабатываются двумя компьютерами? И хотя даже наличие двух датчиков не всегда спасает (вспомним MCAS), но тем не менее. Кстати, в заголовке речь идёт о единственном акселерометре, а в статье - о несольких.
Вот как надо отказоустойчивые системы разрабатывать:
84 секунды — это время на номинальном режиме работы двигателя. Но что, если двигатель по каким-то причинам не выдаёт полную тягу? Поэтому штатно выключение производится когда акселерометр покажет, что аппарат прожёг нужную дельту.
А 127 секунд может соответствовать работе двигателя на нижнем пределе дросселирования.
Для манёвра перехода на более низкую орбиту, это совершенно не критично.
Перенесут манёвр на следующий виток, зато не угробили бы аппарат.
А для посадки не имеет смысла, т.к. если двигатель не выдаёт нужную тягу, то привет поверхность.
127 секунд не "показывает" вообще ничего. В данном случае после обнаружения отказа первого комплекта (БИУС-Л) перешло переключение на второй (что ранее уже происходило). Но акселерометры второго то ли не включились, то ли тоже выдавали нули, эту подробность пока не "слили". В итоге импульс завершился по таймеру в бортовом ПО, это и были те самые бесполезные в случае данной коррекции 127 секунд.
Мне кажется они не ставили дополнительный "будильник" на 127 секунд, это число похоже на 7-битный счетчик сторожевого таймера.
Плюс дополнительный компьютер это минус полезная нагрузка.
"Лишний" компьютер, это вопрос того станет ли нагрузка полезной или бесполезным мусором.
На орбите или в искусственном кратере.
Не надо лозунгов. Плюс один комп это +10 кг и минус один полезный прибор, закинуть который на Луну будет стоит ещё 200 млн. баксов.
При чём здесь лозунги. Все в здравом уме делают резервирование для космических аппаратов.
В первую очередь это компьютеры, электропитание и связь. Вот основной двигатель редко резервируют, т.к. это действительно существенно скажется на ПН.
Те же Вояджеры до сих пор работают, благодаря продуманности конструкции и софта.
Почему не включился акселерометр, мы детально разбираемся. У нас существует 16 версий, 11 мы уже проверили», - пояснил Борисов.
А самую простую версию: «потому, что не поставили копеечный по сравнению со стоимостью потерянной системы, резервный акселерометр» они не рассматривают?
Это так не работает.. Хорошо постфактум, видя в чем проблема рассказывать о том, что необходимо было сделать. Но в момент проектирования, если все дублировать, то можно надублировать на еще несколько модулей по запчастям и затянуть разработку в несколько раз, так как работа с каждым следующим дублем это кратное время как минимум на обработку показаний, синхронизацию, дополнительная логика работы.. А чем больше логики, тем больше багов. Тем больше шансов, что, что-то пойдет не так.. Не говоря уж о том, что имеются ограничения на вес, на объем, на стоимость..
Все эти "а самую простую версию" напоминает классическое - "не пишите код с багами".
Можно индусов нанять писать код...
Дублировать нужно все критичные системы, без которых миссия будет потеряна.
А смысл? Если один датчик не работает - то и два или три аналогичной конструкции скорее всего то-же не сработают. Ну например - сгорел от скачка напряжения.
Ну так точно так-же и 3 и 33 аналогичных в этот момент сгорят.
Теперь расскажите, как уместить удвоенное количество систем в такую же суммарную массу.
«потому, что не поставили копеечный по сравнению со стоимостью потерянной системы, резервный акселерометр»
Ну тут непонятно. Вот тут же написано:
Согласно протоколу, при подлёте «Луны-25» к Луне бортовой компьютер станции должен был подать на «БИУС-Л» команду на включение акселерометров
То есть их вроде бы больше одного
Пацаки, вы почему пепелац из гаража без резервной гравицапы выкатываете?
Хорошо еще, что датчики угловых скоростей на этот раз поставили правильно. Осталось научиться вовремя отключать ДУ.
Их программное обеспечение не проанализировало ответную реакцию «БИУС-Л», по сути, просто не убедилось, что блок измерения угловых скоростей запущен в работу. А дублирование команды для проверки запуска модуля в программе не было», - рассказали источники СМИ.
Противоречивая информация. Даже если отдельно не проверять работоспособность датчиков, мне сложно представить, что модулю, который принимает и обрабатывает сигнал с датчиков, пофиг на неадекватный сигнал (или отсутствие сигнала). Должна же быть элементарная проверка граничных условий? Ну и резервирование предполагает автоматическое возникновение сигнала ошибки в случае неисправности. Имхо, проблема более тонкая и возможно возникла где-то на стыке низкоуровнего и высокоуровневого программного обеспечения. В то, что отсутствовало резервирование, слабо верится, скорее всего возникла какая-то неочевидная несогласованность.
Когда здесь обсуждали падение боингов, насколько помню, там на низком уровне бортовой компьютер всё же "видел" проблему с датчиками, но не сообщил о проблеме пилотам (вроде там эта опция предлагалась за отдельные деньги).
Но повторюсь, я бы не стал делать выводы по данным от журналистов, без знания всех деталей в этом нет смысла.
«Согласно протоколу, при подлёте «Луны-25» к Луне бортовой компьютер станции должен был подать на «БИУС-Л» команду на включение акселерометров. Программисты эту команду подали (это было видно по циклограмме), то есть, по сути, тоже все сделали правильно, за исключением одного. Их программное обеспечение не проанализировало ответную реакцию «БИУС-Л», по сути, просто не убедилось, что блок измерения угловых скоростей запущен в работу. А дублирование команды для проверки запуска модуля в программе не было», - рассказали источники СМИ.
Звучит буквально как ошибка наподобие вызова malloc() без проверки на NULL.
И как всегда возникает вопрос - что делать дальше, если malloc() вернул NULL?
Если без работоспособных акселерометров сесть на Луну все равно не возможно, стоит ли проверять, запустились они или нет. Если по итогу все равно провал...
не начинать маневр, остались бы на орбите, это мог быть сбой, а не отказ, тогда маневр бы выполнили на следующем витке
И что-бы поменялось на следующем витке?
Если это программный косяк, то перепрошивка и новая проверка.
Да и аппаратный сбой мог быть одиночным, из за радиации к примеру регулярно бывают.
Ну, например, смена "дня" и "ночи" - это серьёзная смена тепловых режимов, которая могла как привести к потере электрического контакта где-то в цепях, так и к его появлению обратно. Или, как уже написали, радиационные проблемы - мог защёлкнуться транзистор от пролетевшей частицы, тогда можно пытаться восстановить сбросом электропитания. В общем, повторные попытки имеют смысл.
В конце-концов, можно оставить аппарат на орбите - всё больше пользы.
С malloc вопрос непростой, но в случае акселерометров, как минимум, можно было попытаться повторить команду запуска.
Но мы не знаем, что там было на самом деле, а на журналистское описание нельзя ориентироваться.
Не использовать malloc) В ембеддеде malloc - очень плохой тон, как раз потому, что один и тот же malloc может работать месяцами корректно, а потом сломаться. В ембеддеде это реальная проблема, т к памяти мало, менеджера виртуальной памяти нет, фрагментация физической памяти, и т.п. Так что кучу либо вообще не используют, либо выделают все на старте программы, когда все относительно детерминировано.
Спасибо за ссылку! Прочитал статью, там упоминается теоретическая оценка минимального размера кучи, при которой "катастрофическая фрагментация" (что бы это не значило) невозможна. Если я правильно понял, это 2 * (максимальный необходимый приложению размер кучи) * (1+log(максимальный размер аллокации)), т.е. больше половины кучи всегда пустует, что на мой взгляд, является довольно большой ценой за гарантированную аллокацию.
Ну и не могу не заметить, что отраслевые стандарты в целом негативно относятся к куче, например, MISRA использование кучи прямо запрещает (что конечно не отменяет применимости детерминированных алгоритмов)
MISRA C:2004, 20.4 - Dynamic heap memory allocation shall not be used.
MISRA C++ 2008, 18-4-1 - Dynamic heap memory allocation shall not be used.
Приостановить процедуру, чтобы разработчики на земле могли разобраться в чем дело и подумать. Так хотя бы есть шанс придумать решение. Представьте себе, что вместо того, что вышло, было бы так: инженеры поняли, что не работает акселерометр, стали думать, поняли, что можно кое-как вычислять ускорение по изображению с камер, удаленно перепрошили аппарат и успешно прилунились. Тогда это был бы не просто успех, а ещё и красивая история, вызывающая дополнительное восхищение, хотя вообще-то произошла такая же поломка.
А это для меня значит:
плохая документация
доки есть, но не встроены в IDE
> аналогично, нет статического анализа
И не надо объяснять плохой UX для разработчика тем, что де "неопытный сидел". Когда дока есть и на отдалении одного клика - вероятность этой ситуации (лени) близится к нулю. Ну да, ну да, ревью. А доки встроены в те же Github/Gitlab PR ревью (или кто там чем пользуется)?
Понятно, что тут нужен досканальный аудит каждой строчки. Но имхо, обычная проверка кода устроена так, что в основном держится на опыте и внимании/бдительности проверяющего. От того и поверхостные замечания, а там LGTM.
И минутка скепсиса: списать чей-то крупный факап на человеческий фактор.
А напомните, что в Луне-25 пришлось заменить из-за разрыва сотрудничества с ЕКА?
Зато все сами.
Так я без задней мысли, честно, просто не помню. Этот блок, о котором идёт речь в новости, и есть та самая замена?
более всего удручает, что этот отказ/сбой (как и множество остальных) могли быть проверены на цифровой модели и далее стенде, и ошибка в программе была бы исключена(((( ошибка не программистов, а головного исполнителя и главного конструктора(((
Это всё есть, не думайте что всё так уж плохо в разработке.. и модели делают, и стендовые испытания. Испытания со смежниками плюс под контролем ВП, и по каждому пункту ТЗ. Тут сложно лажу сдать, всё это долго, нудно, каждый сто раз подумает перед подписью любой бумажки.
Я жду итогового отчёта.
этого нет, если я правильно понимаю как головной исполнитель работает по ЕСКД и ГОСТ, то есть пункты ТЗ и их сдают как они там они написаны, не запариваясь на то, что должно происходить в случае отклонения данных от смежников.
«Согласно протоколу, при подлёте «Луны-25» к Луне бортовой компьютер станции должен был подать на «БИУС-Л» команду на включение акселерометров. Программисты эту команду подали (это было видно по циклограмме), то есть, по сути, тоже все сделали правильно, за исключением одного. Их программное обеспечение не проанализировало ответную реакцию «БИУС-Л»
Теперь, как нужно было, на мой очень диванный взгляд проверять на программной модели (даже не стенде). Запускать 100500 реализаций и случайным образом в каждой реализации отключать програмные модули (а также менять внешние параметры) и оценивать результат и варианты нештаток. В данном случае цифровой модели небыло, так как смоделированный отказ БИУС-Л, сразу бы указал на ошибку в алгоритме работы бортового компьютера с последующим крушением (на любой стадии проектирования). Я уверен, что цифровой модели миссии у головного исполнителя нет(((
ps: и обратно уверен, что в миссиях китайцев она есть, в современном проектировании без модели никуда(
Вы абсолютно не в курсе как проверяются бортовая аппаратура спутников. Модели каждого борта имеются. Уж не один десяток лет по модели и работает контрольно-проверочная аппаратура. Но никто не отменял человеческий фактор. Кто вам скажет что модель борта на 100% соответствует и в ней нет ошибок? Но поверка всегда идёт по модели!
я абсолютно не в курсе, как проверятся бортовая аппаратура, но исходя из смысла программной модели миссии - в неё загружаются оригиналы программного обеспечения (в том виде, в котором они программируются в изделие), которые исполняются на программной модели блока (движке), программная модель блока взаимодействует через модели каналов связи и модели внешних воздействий с остальными элементами изделия. В целях обеспечения отработки различных вариантов изменяются внешние воздействия и состояния блоков (вплоть до эмуляции отказов, сбоев, ошибочного поведения). В случае если все варианты перебрать не возможно (а их действительно адски много) выполняется симуляция миссии со случайными (в пределах) параметрами входных воздействий (по сути метод Монте-Карло). Симуляций, к счастью, можно провести очень много, можно сохранять промежуточные результаты и повторять с любой точки, проводить симуляции параллельно или изолировано. Естественно в вариант симуляции в обязательном виде попадают отказы, сбои отдельных блоков.
Теперь возвращаясь почему ошибка указанная в статье 100% выявляется на симуляции и не является программной ошибкой, а является организационной ошибкой. Если бы в модель КПА загружались оригинальные коды, тогда при симуляции отказа блока "БИУС-Л" мы бы получили то, что случилось в реальности. В данном случае программист не виноват - ему дали неполный алгоритм, он его реализовал, потом сдал ВП, его прогнали на КПА в котором реализуются исключительно штатные ситуации - все ок, претензий к "карманам и пуговицам" нет, но пиджак не сидит...
Я 15 лет занимаюсь комплексной валидацией (космический + наземный сегмент) и совершенно точно могу сказать, что множество сбоев и отказов либо не воспроизводятся на инженерных моделях или SVF аппаратов в силу их крайней маловероятности и отсутствия из-за этого соответствующих испытаний, либо их вообще невозможно адекватно воспроизвести. "Прививка" от подобного - многоуровневый и систематичный подход к обеспечению автономности и живучести КА. Это означает годы опыта и извлечения уроков из предыдущих миссий. У НПОЛ этого нет. Собственно, ни у кого в РФ по АМС нет такого наследия и школы соответствующей.
Недавно же на хабре писали, что изначально акселерометров и планировалось несколько. Но поставки осуществлены не были и их пришлось импортозамещать. А наше изделие получилось таким громоздким, что продублировать не получилось по размеру/весу. Программное обеспечение тоже пришлось переделывать
Не смог найти ссылку. Даже зная ключевые слова, найти на хабре что то еще та задача.
Не используйте поиск Хабра, он крайне убог. Не ищет порой даже по точной фразе из заголовка.
Используйте любой внешний поиск, тот же гугл или яндекс.
Хотя публикацию могли и удалить.
А наше изделие получилось таким громоздким, что продублировать не получилось по размеру/весу.
На конкурсе компактных компьютеров компьютер из Советского Союза занял все место.
По части резервирования это не так. БИУС-Л функционально эквивалентен Astrix 1090. 4 канала ВОГ, 3 акселерометра. И 2 таких прибора на борту. Даже размеры посадочной плошадки те же, 265 мм, насеолько помню. Надёжность, да, другая. Но он делался для снарядов РСЗО калибра 300, там время работы суммарное - минуты.
Легко быть умным после проблемы, но есть такие мысли:
1) хорошо бы не просто наличие сигнала смотреть, а правдоподобность, что отклик акселерометра в допустимых пределах при работе двигателя (при этом проверять и корректировать модель двигатель-акселерометр) или переходить в безопасное состояние, если акселерометр не реагирует на двигатель
2) при проверке на стенде надо было отрабатывать и возможные неисправности, чем больше, тем лучше, и в автоматическом режиме. Я понимаю, что всё "ИТ тестирование" началось с методологий для авиации-космоса, но раз не помогло отследить проблему - надо искать и устранять причины.
Глобально, думаю, что дело в спешке. Понятно, что времени никогда не бывает достаточно, но все-таки сделать тестирование как положено, и дать инженерам выспаться и дать время на "подумать и уложить в голове" нужно было обязательно.
Новый кратер надо назвать "Понадеялись на авось". Или сокращенно, "Авось". Хотя, наверное, такие кратеры там уже есть и много..
Сколько лет проект делали? Дело не в спешке. Не было нормального тестирования вот и всё.
1) хорошо бы не просто наличие сигнала смотреть, а правдоподобность, что отклик акселерометра в допустимых пределах при работе двигателя (при этом проверять и корректировать модель двигатель-акселерометр) или переходить в безопасное состояние, если акселерометр не реагирует на двигатель
Не уверен что ограничения по массе, энергопотреблению, производительности космических микросхем, запасу топлива на тестовые запуски двигателей позволяют осуществить все хотелки.
Я имею ввиду код. Просто некоторое полезное усложнение логики.
Вопрос к тому будет ли отдельный участок кода полезным. Ну ок мы получили неадекватный отклик акселерометра(или адекватный но неадекватную работу двигателя), перевели в безопасный режим. А дальше одни вопросы есть ли датчик количества топлива, есть ли датчик работы двигателя. Что вообще за двигатель, умеет ли он надёжно многократно запускаться. Можем ли после такой аварийной остановки двигателя потом рассчитать положение аппарата и новую траекторию посадки. Если хоть один ответ - нет, то усложнение кода как минимум бессмысленно.
Опыт "Скиапарелли" ничему не научил. Там исправность работы высотного посадочного высотомера определяли по наличию показаний от него. Буквально - "если есть замер, значит прибор работает". А то что соседние измерения отличались друг от друга на километры, причём как вниз, так и вверх - не важно. А резервный высотомер был. Вот только критерий перехода на него был ущербен.
Ну и включение третьего, прецизионного маловысотного высотомера, который должен был включится на высоте 250 метров так и запрограммировали "если высота равна 250 метрам, то включить". С формальной точки зрения - всё правильно. Если высота снижения меньше метра в секунду, а вы делаете 6 замеров в секунду, то то высоту вы никак не проскочите.
Но что- то пошло не так. И среди кучи случайных высот с высотного высотомера высота 250 метров так и не попалась.
Печально.
Одно из правил, которое вбивал нам в головы препод на промавтоматике звучало -"прежде чем использовать данные с критически важного датчика, убедитесь что его не открутили бомжи и не сдали на металлолом, а кабель от датчика не ловит сигналы из космоса".
Основной опыт "Шрапнелли" - организационно-управленческий. К нему отнеслись как к вторичной полезной нагрузки, с соответствующим бюджетом и тезническим контролем заказчика. Если коротко - пустили многое на "самотёк". К Луне-25 это не относится, другая проблематика и другие причины как технические (верное или ложное обнаружение отказа первого комплекта, невключение акселерометров второго), так и на уровне управления проектом (там большой "букет", часть из него наверняка будет в публичном заключении комиссии)
Акселерометр сделан в НИИ Физических Измерений? Это направление там возглавляла бабушка Тоня. Она - как бы доктор технических наук, но всю жизнь наполнение для своих диссеров и технические решения по электронике она шакалила у других специалистов. А последние 10-20 лет с этим большие напряги.
«Роскосмос»: по предварительной версии крушение станции «Луна-25» произошло из-за невключившегося акселерометра