Метеор-М №2-1 с попутчиками – Союз-2.1Б/Фрегат – Восточный 1С – 28.11.2017 08:41 ДМВ - авария

Автор zandr, 02.09.2017 20:54:00

« назад - далее »

0 Пользователи и 1 гость просматривают эту тему.

Разъём

ЦитироватьSerge V Iz пишет:
Цитироватьесли он крутнулся по рысканию на недопустимый угол
это для корпуса платформы было рыскание, а для платформы-то - все как на старте.
Ограничения гиростабилизатора РБ Фрегат:
при движении относительно инерциальной оси Хгсп - ограничения +/- 40 град, при движении относительно прочих осей ограничений не имеется. Таким образом когда надо ввести РБ в закрутку, физическую ось РБ Х выставляют по Yгсп, а потом закручивают.

Штуцер

ЦитироватьLRV_75 пишет:
Также не бывает идеальных тестовых стендов!
Проводя все необходимые виды проверок и виды тестирования мы лишь снижаем вероятность пропуска дефекта, но не до нуля.
Режим довыведения Скифа гоняли на стенде в Харькове, нов анализе этих прогонов плюху пропустили и убедились в этом, когда подняли документацию в Харькове.
Сергеев:

Цитировать Несколько позже вышел приказ по министерству, где некоторые руководители НПО "Полюс", включая Ананьева, были понижены в должности. Последняя точка во всей этой истории со "Скифом19-ДМ" была поставлена на совещании у А.Г.Андрущенко, после моего возвращения в Харьков. Он однозначно заявил В.Н.Горбенко: "Вы виноваты на 100%!", когда тот весьма неудачно пытался обвинить меня. Анатолий Григорьевич знал как никто другой, что и он частично был виноват в этой аварии. Дело в том, что еще лет пять-шесть тому назад я в свое отделение принял к разработке ряд объектов, космических кораблей Главного конструктора ОКБ им. Лавочкина Ковтуненко В.М. Это были однотипные, с точки зрения системы управления объекты: "Аракс" - спутник-разведчик, 71Х6 и 72Х6 - радиоразведчики и спутник для изучения Солнца "Спектр", разработки ОКБ-586 В.Ф.Уткина. Многое для их систем управления было позаимствовано из "Энергии-Бурана", в частности, полностью наземная проверочная аппаратура. К моменту пуска "Энергии" разработка этих объектов шла полным ходом. В мое отсутствие было принято решение о выделении этих работ в самостоятельное подразделение с передачей туда части моих работников. Инициаторами этой операции были В.Н.Горбенко и Г.И.Лящев, причем, ответственным за эти работы был назначен В.Н.Горбенко, на мой взгляд, человек совершенно неподготовленный и не имеющий опыта подобных работ. На него же была возложена задача и стендовой отработки системы управления "Скиф19-ДМ", так как основная группа моих испытателей, ведущих стендовую отработку объектов Ковтуненко, вела и этот стенд. Другие отделы, ведущие "Скиф", были задействованы на "Энергию", и таким образом, система управления "Скифа" была разорвана в части ее сопровождения, и вина за это целиком ложилась на Анатолия Григорьевича, который в этом вопросе положился на Горбенко. Владимир Николаевич подошел к работе формально, проводил оперативки, требуя выполнения сроков работ  не вникая в их техническое содержание. Все это сказалось на конечном результате. В.Я. Страшко, специалист по точным и жестким формулировкам, так комментировал руководство "Скифом" со стороны Горбенко: "Когда видишь, как спорится работа в руках опытного мастера, кажется, что и ты сможешь ее также сделать, но стоит взять в руки его инструмент, как оказывается, что ты даже не в состоянии его правильно держать в руках!"
Было обидно и жалко, что так бесславно завершилась эпопея комплекса "Алмаз" - первого космического корабля нашего предприятия, в который было вложено столько труда и энергии. Один из лучших моих испытателей, молодой и талантливый инженер Олег Лученко, который вел стендовые отработки системы управления "Скифа" в Харькове, не раз, уже гораздо позже, заходил ко мне, и мы с ним, чуть ли не со слезами на глазах обсуждали все подробности гибели нашего ТКС - "Скиф19-ДМ". Но вернуть ничего невозможно, и корабль покоится где-то на дне океана недалеко от второй ступени "Энергии". 
Было уже все... и все повторяется.
Но в виде обломков различных ракет
Останутся наши следы!

Кубик

ЦитироватьПлейшнер пишет: Уточню, зачем 100м и недостаточно например 1000 м ?
Вопрос хоть и не ко мне, но пусть найдётся тот, кто назовёт реальную НОО в виде идеального эллипса/окружности с точностью в 100 м.:)
И бесы веруют... И - трепещут!

Serge V Iz

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

Но в оставшихся 99% случаев, такое тестирование, по самой своей сути - такой же метод тыка, как ковыряние кроманьонца палкой в земле в поисках сладкого батата. И чем более хитроумна система, которую тыкают, тем меньше эффекта от тыка и больше эффекта от изучения и выявления ее неотъемлемых свойств, на основании которых можно делать выводы на будущее. )

LRV_75

ЦитироватьSerge V Iz пишет:
Но в оставшихся 99% случаев, такое тестирование, по самой своей сути - такой же метод тыка, как ковыряние кроманьонца палкой в земле в поисках сладкого батата
Отлично сказано, Молодец! Садись, пока 2
))))
Главное не наличие проблем, главное способность их решать.
У каждой ошибки есть Имя и Фамилия

jerzz

jdvhb98asdcv876avg

Serge V Iz

ЦитироватьОтлично сказано, Молодец! Садись, пока 2
Хорошо, продолжу ) Етими скучными 99% приходится платить за право получить тот 1% джекпот ) А проблема все равно никуда не девается. Через некоторое время ряд регрессионных тестов просто теряет смысл, поевращаясь в тождество. Поэтому для развивающейся системы не получится создать волшебную тест-машину, получится лишь создать параллельный проект, который также будет в состоянии параллельной разработки. Всегда ) Изредка даже в состоянии неправильной работы )

Плейшнер

ЦитироватьSerge V Iz пишет:
ЦитироватьСтабилизация означает удержание текущих углов а не заданных
А по мне, так она даже больше озабочена угловыми скоростями.  :)
ДУСы являются датчиками, но задача стабилизировать именно углы. Просто, реагируя на углы а не на угловые скорости, будешь всегда опаздывать.
Цитировать Ну вот не удалось ей удержать идеально угол в цикле управления номер 100. и он поимел отклонение 0.1 градуса. Что, теперь автомат стабилизации всю дорогу будет решать задачу удержать именно этот угол?  :)  
Именно так.
А если наберется достаточна большая ошибка, то СУ или а) отключит на время автомат стабилизации, поправит угол и снова включит стабилизацию
или б) тупо пересилит автомат стабилизации. Как именно устроено у Фрегата мне к сожалению неизвестно
ЦитироватьНет, он будет решать задачу примерно так: "куда мы сейчас вертимся? в сторону от куда надо? а где мы сейчас? ой, и так далеко уже от этого куда надо! надо рулить!" С разными там коэффициентами важности отклонений и скорости отклонений, а может еще и более интегральных или более дифференциальных характеристик движения.
То что вы описали решает как раз основной контур управления а не автомат стабилизации
Не надо греть кислород!
Я не против многоразовых ракет, я за одноразовые!

Lunatik-k

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

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

Есть ли идейные генераторы нештатных ситуаций ?
Отсутствие генератора идей полностью останавливает работу.

Бывает и такое генератора идей сократили(или сам ушёл) остались одни родственники.
Ростки правды похоронят империю лжи.

Serge V Iz

Цитировать на тангажном развороте (практически) совместила продольную ось РБ с гироскопической осью В
у меня не складывается: послестартовый разворот добавил в оси В около полуоборота к тому полуобороту, который уже был. Следовательно, эта ось была направлена вверх или вниз. При этом корпусная СК повернулась так, что тангажная рамка все равно осталась тангажной рамкой, только с другим знаком. После тангажа на примерно четверть оборота РБ попытался отработать накопленный полный оборот в все той же оси В, которая все также вверх или вниз, но по отношению к корпусу прибора и самому РБ - к спине или к пузу. При этом РБ рыскает, а в ГСП поворачивпется только В, и не надо ничего складывать. Где не так?

Serge V Iz

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

Serge V Iz

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

ZOOR

ЦитироватьSerge V Iz пишет:
Где не так?
О, теперь сложилось. Спасибо.
Я зуб даю за то что в первом пуске Ангары с Восточного полетит ГВМ Пингвина. © Старый
Если болит сердце за народные деньги - можно пойти в депутаты. © Neru - Старому

mind22

ЦитироватьLRV_75 пишет:
Или же, из за неполного объема входных данных, который был при модульном тестировании и который не позволил проверить все ветки функционала системы
Если в модульном тесте не получается в достаточной мере проверить код, то в интеграционном/системном его тем более не проверить.

Допустим, у нас 3 модуля, нужно проверить 5 состояний в каждом (провести модульные тесты). Итого, нужно провести 5+5+5 = 15 тестов.
Если же мы делаем интеграционный тест, то по правилам комбинаторики нужно провести уже 5*5*5 = 125 тестов.

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

LRV_75

ЦитироватьSerge V Iz пишет:
Хорошо, продолжу ) Етими скучными 99% приходится платить за право получить тот 1% джекпот ) А проблема все равно никуда не девается. Через некоторое время ряд регрессионных тестов просто теряет смысл, поевращаясь в тождество.
Нещадно, нещадно расстреливать )))
Главное не наличие проблем, главное способность их решать.
У каждой ошибки есть Имя и Фамилия

Serge V Iz

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

vadimr

ЦитироватьКубик пишет:
ЦитироватьПлейшнер пишет: Уточню, зачем 100м и недостаточно например 1000 м ?
Вопрос хоть и не ко мне, но пусть найдётся тот, кто назовёт реальную НОО в виде идеального эллипса/окружности с точностью в 100 м.  :)
Орбиты космических аппаратов, разумеется, не имеют форму идеального эллипса, однако точность их лучше 100 метров.

Serge V Iz

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

LRV_75

Цитироватьmind22 пишет: 
Если в модульном тесте не получается в достаточной мере проверить код, то в интеграционном/системном его тем более не проверить.

Вся магия в том, что можно и достаточно просто ))

ЦитироватьДопустим, у нас 3 модуля, нужно проверить 5 состояний в каждом. Итого, нужно провести 5+5+5 = 15 тестов.
Если мы делаем интеграционный тест, то по правилам комбинаторики нужно провести 5*5*5 = 125 тестов.
В реальной жизни из-за большого числа модулей и комбинаций количество требуемых интеграционных тестов становится просто огромным и не может быть реализовано физически.
А теперь забудьте про все эти страшилки ))
В первом приближении в модели интеграционных тестов ВООБЩЕ не надо придумывать никаких хитрых тестов.
Например, у нас есть 2 системы А и Б. Каждая система проверила локально свой функционал. 
Теперь разворачиваем интеграционный стенд (да, возможно в этом "разворачиваем интеграционный стенд" сидит пару миллионов денег). Настраиваем интеграцию, "снимаем" с систем А и Б все заглушки и имитаторы входящих сигналов и просто запускаем, например в системе А все ее функциональные тесты.
 В тех точка где стояли "заглушки" и начнется магия тестирования ЖИВОЙ интеграции.

Вот здесь и всплывет все рассогласование спецификаций и неполноценность локальных проверок. Уверяю вас, 99% вскрытых интеграционных дефектов будут до смешного простые. Как, например, та ошибка, из за которой Фрегат в океан улетел.

 
Главное не наличие проблем, главное способность их решать.
У каждой ошибки есть Имя и Фамилия

Serge V Iz

ЦитироватьА теперь забудьте про все эти страшилки ))
В первом приближении в модели интеграционных тестов ВООБЩЕ не надо придумывать никаких хитрых тестов.
Например, у нас есть 2 системы А и Б. Каждая система проверила локально свой функционал.
Теперь разворачиваем интеграционный стенд (да, возможно в этом "разворачиваем интеграционный стенд" сидит пару миллионов денег). Настраиваем интеграцию, "снимаем" с систем А и Б все заглушки и имитаторы входящих сигналов и просто запускаем, например в системе А все ее функциональные тесты.
В тех точка где стояли "заглушки" и начнется магия тестирования ЖИВОЙ интеграции.
так это пройдено на сухом вывозе. наземные аппаратуры, бортовые аппаратуры участников сказали, что все ок, хоть сейчас летим. А дальнейшая "живая интеграция без заглушек" означала бы необходимость налить быстренько керосина с кислородом, прочих жиж и газов и поднести к соплам эти замечательные березовые спички :)

что и было сделано в следующий раз. вот такие натурно-интеграционные ЛКИ с котятами. )