Фобос-Грунт, Yinghuo 1 – Зенит-2SLБ – Байконур 45/1 – 09.11.2011 00:16 ЛМВ

[alienethic]

Вы когда-нибудь пробовали написать программу управления ракетным двигателем с турбонасосом?

А вы :?:

[Александр Ч.]

Не для слабонервных!

Марс атакует [/size]

Почему упал «Фобос-грунт»?
Американский радар или инопланетный разум?
Что скажут эксперты и о чем говорил Нострадамус?
«Марс атакует» — в программе «ЧП. Расследование».

А чем в первоисточнике, сайте НТВ, видео не устроило?

 Suzeren, а вы там спите что ли? А ну марш в микроволновке "дублера" ФГ мучать! Руководство ждет жареных фактов :lol:

Кто-нибудь расслышал "название" РБ, которое произносит Серебров? А то у меня что-то со слухом видимо, да и больше двух минут я этот цирк смотреть не смог.

[X]

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

тем более что методология такого расчета представляет для меня - да и, я уверен, для многих других здесь - значительный интерес? Кстати как и методология сравнения результатов таких расчетов - если таковая существует.

Если у меня будет время,то я посчитаю несколько вариантов. Но  скажу без обиняков: я говорил о точности не для того, чтобы увеличить точность на 10%, применяя другую методологию. Посыл совсем другой: я хочу убедиться в том, что в принципе возможно найти приращение скорости (delta V), используя такой грубый пропагатор, как SGP4. Посмотрите результаты Асама: он снизил невязку орбит фрагмента и ФГ с 700 км до 10 метров, и получил оценку delta V порядка метров в секунду. Но если эта невязка (10 метров) связана с неточностью местоположения вдоль надира (по радиус-вектору), то ошибка в найденном delta V превысит 100%. Я примерно знаю, как это проверить, нужно только время.
Насчет того - прав я или нет, поговорим после моих выкладок. Я буду рад оказаться неправым, ибо тогда я стану использовать SGP4 в более широком спектре задач, что значительно ускорит расчеты.Но сейчас я,  увы, пессимист.

[Unispace]

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

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

[Agent]

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

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

И что? Только переменных в каком либо драйвере передатчика больше чем составных частей всей АМС. По вашей же "азбучной истине" драйвер будет самым слабым звеном. Соббсно так оно и было - видать подход к созданию ФГ в точности совпадал с вашим.

Есть надежные методы определения надежности железа. И нет надежных медотов определения надежности ПО.

[Зловредный]

А ну марш в микроволновке "дублера" ФГ мучать! Руководство ждет жареных фактов :lol:

   

[dmdimon]

Насчет того - прав я или нет, поговорим после моих выкладок.

подожду с большим интересом.
пс. неправоту я имел в виду не по методу расчета, а по позиции в дискуссии. Но это мое субъективное мнение конечно. Просто asam _уже_ дал мне возможность чему-то научиться, хотелось бы научиться чему-нибудь и от вас, а потом уже сравнивать.

[Unispace]

И что? Только переменных в каком либо драйвере передатчика больше чем составных частей всей АМС. По вашей же "азбучной истине" драйвер будет самым слабым звеном. Соббсно так оно и было - видать подход к созданию ФГ в точности совпадал с вашим.

Есть надежные методы определения надежности железа. И нет надежных медотов определения надежности ПО.

Любую технику и ПО в конечном счете создают люди и средства производства. Средства производства в конечном счете создаются людьми. Посчитайте количество людей и средств производства для железа и ПО. Далее посчитайте количество структурных единиц (которые и являются элементами со своей надежностью) во всей системе, в средствах производства и в ПО. Переменные..... драйверы..... Я по этому форуму могу сказать, кого точно и ни под каким видом нельзя допускать к созданию любой автономной техники  Косильщиков лужаек....    Есть такие, которые за всю свою деятельность не видели ничего, кроме дисплея, клавиатуры и мышки. Они пишут свои коды и совсем не думают, какова надежность вентиля в процессоре или домена на HDD, машины для установки BGA-кристаллов или лазера в головке считывания. И какие усилия нужно приложить, начиная с фундаментальной науки, сделав попутно открытия, чтобы все это работало с коммерчески успешным уровнем надежности. Для них программы - альфа и омега в их мире надежности и значимости  Никто не принижает значимости ПО, но усилиями кнопкодавителей и создателей ПО создан миф о том, что ПО дороже и сложнее в разработке, чем железо. В реальности такой вариант  возможен, например, в случае сильно ограниченных ресурсов железа, исполняющих код математически сложной нереалтаймовой обработки. Или в случае сложной распределенной системы, имеющей тысячи модулей обработки и строго заданное максимальное время отклика и количество откликов-результатов на входные события. Но обычно затраты на разработку и тестирование всего аппаратного комплекса (а не только процессора) куда выше, чем затраты на ПО + отладка-тестирование.

[Agent]

И какие усилия нужно приложить, начиная с фундаментальной науки, сделав попутно открытия, чтобы все это работало с коммерчески успешным уровнем надежности.

Перечислите ка фундаментальщину, открытия и прочие высокие материи при создании ФГ. Или вы за все человечество тут расписываетесь начиная с изобретения колеса? Дак тогда нада было заказать ФГ целиком в JPL.

[zyxman]

Вы когда-нибудь пробовали написать программу управления ракетным двигателем с турбонасосом?

А вы :?:

Я пробовал.
И поэтому я согласен с Агентом, что УНИВЕРСАЛЬНАЯ таковая программа будет иметь огромное количество возможных состояний, а какая-то суперузкоспециализированная (и ЭТОЙ УЗКОСПЕЦИАЛИЗАЦИЕЙ ограничивающая возможности железа) конечно может быть очень простой и потому дешевой.

Далее я там писал про возможность упрощения программы ОБЩЕГО управления путем выноса частей центрального СУ в индивидуальные управляющие блоки. - Например, для работы с упомянутым РД нужно контролировать обороты турбины (и некоторые другие параметры), так можно измерять эти обороты подпрограммой центрального СУ (например по периоду между импульсами от датчика Холла) а можно отдельным блоком-тахометром - этим мы по сути делаем декомпозицию системы на отдельные более простые блоки и ПО становится проще и надежнее, но введение дополнительного электронного блока совсем не обязательно увеличит общую надежность всей системы.

[Vladimir]

Честно говоря, читать все это словоблудие, на ночь глядя, довольно утомительно. Можно, конечно, продолжать всем этим заниматься, ведь надо же дотянуть до 1000 страниц.
Разумеется, процесс создания КА сложен и многообразен. Но, если отбросить словесную шелуху, во всем этом многообразии можно вычленить для примера три составных и основополагающих элемента. Это электрические интерфейсы, по которым выпускаются протоколы электрического сопряжения, информационные интерфейсы, по которым выпускаются протоколы информационно-логического взаимодействия, и, наконец, логика функционирования бортовых систем, включающая все типовые полетные операции и основные нештатные ситуации. Электрические испытания КА проводятся для проверки как раз этих элементов, причем ПО пишется, в первую очередь, для последних двух элементов, а все, что не относится к ним должно проверяться на стендах.
Ну а теперь взглянем на Фобос-грунт. Если кто внимательно следил за сообщениями СМИ, то, наверное обратил внимание на высказывание Поповкина о возможности перепрограммирания борта. Если сбросить пелену, то выяснится, что за эттим скрывалось признание того печального факта, что ФГ стартовал, не имея в составе ПО ряда типовых полетных операций, включая посадку на Фобос. Я, можно сказать, не первый год замужем, но по-моему в истории отечественной и мировой космонавтики еще не было КА, который запускался бы, не имея изначально возможности выполнить основную целевую задачу. Что это, как не профанация всей космонавтики. Да за одно только это надо всем, кто поставил свою подпись на разрешение пуска, оторвать я..ца.
Второй момент пока еще не слишком известен, но именно он стал последней каплей, погубившей Фобос-грунт. Из сообщений СМИ известно, что 23 ноября удалось включить передатчик и получить сигнал с ФГ. Но мало кто знает, что выключить ПРД не довелось, а бортовыми алгоритмами по сигналу Umin это не предусматривалось. В результате энергобаланс на борту стал отрицательным, а при наличии теней сначала разрядилась аккумуляторная батарея. Затем автоматика СЭС переключилась на ХИТ, но и он скоро разрядился до нуля, после чего, скореее всего, взорвался в конце ноября.
Вот я и спрашиваю, надо ли быть гением программирования, чтобы разработать алгоритм отключения лишней нагрузки по Umin. Так все эти разговоры про сложность ПО есть лишь попытки навести тень на плетень и запудрить мозги общественности. К этой же категории относятся и разговоры про солнечные вспышки, плазмоиды и американский радар.

[Bell]

Про невыключение передатчика и дальнейшие события в принципе известно. Интересно - с чего же все началось? И что было в ТМИ?

[X]

Вот я и спрашиваю, надо ли быть гением программирования, чтобы разработать алгоритм отключения лишней нагрузки по Umin.

Вообще говоря, как правило, в бортовую аппаратуру не закладывают возможность самостоятельно что-либо отключать или даже переводить на резерв. По крайней мере, по моему опыту. Логика здесь очень простая: система телеметрии не обладает абсолютной надежностью, и может вызвать ложное срабатывание подобного алгоритма. В результате есть шанс потерять или весь полностью исправный спутник или основной канал какого-либо прибора из-за отказавшего телеметрического датчика. Аппарат управляем? Получаем телеметрию, анализируем, отдаем команду на изменение конфигурации включенного оборудования. Или, не смотря на данные об отказе в телеметрии, ничего не трогаем, если аппарат функции выполняет. Ну а если аппарат не управляем, и подавно нечего там тогда ничему автоматически переключаться.

Строго говоря, даже если бы передатчик Ф-Г и отключился бы по таймеру или просадке бортового, то счастья бы это никакого не принесло. Ну приняли бы телеметрию еще разок-другой, может, стрелочника бы нашли повернее. Толку-то?

[Брабонт]

Владимир, а можно ли объяснить, что происходило с аппаратом в первые десять суток полёта - насколько состоятельны версии о самостоятельной работе двигателей малой тяги либо утечке газа, приведшей к неестественным изменениям орбиты ФГ?

[dmdimon]

Толку-то?

то-есть какбы смысла в живом аппарате, который _какие-то_ команды все-же исполняет и даже иногда пытается телеметрию передать в течении еще полутора месяцев вы не видите? типа померла так померла?

[zyxman]

Вот я и спрашиваю, надо ли быть гением программирования, чтобы разработать алгоритм отключения лишней нагрузки по Umin.

Я, также "не первый раз замужем", отвечаю, что для того чтобы в отсутствие санкции руководства предусмотреть в программе "зависание" Ф-Г на опорной орбите и продавить у руководства разрешение эту часть программы вставить и отлаживать в рабочее время, то есть фактически на нижнем исполнительском уровне исправить ошибку проектирования верхнего уровня, нужно быть не только гением программирования но также гением внутрипроектной политики

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

[Unispace]

И какие усилия нужно приложить, начиная с фундаментальной науки, сделав попутно открытия, чтобы все это работало с коммерчески успешным уровнем надежности.

Перечислите ка фундаментальщину, открытия и прочие высокие материи при создании ФГ. Или вы за все человечество тут расписываетесь начиная с изобретения колеса? Дак тогда нада было заказать ФГ целиком в JPL.

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

[ОАЯ]

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

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

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

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

[Salo]

Можно побывать на докладе и задать вопросы:
24-27 января в МГТУ им. Н.Э.Баумана состоятся ХXXVI Академические чтения по космонавтике.
http://www.ihst.ru/~akm/36t18.htm

ИСПЫТАНИЯ БОРТОВОГО КОМПЛЕКСА УПРАВЛЕНИЯ КОСМИЧЕСКОГО АППАРАТА «ФОБОС-ГРУНТ»

Н.С.Парцевский, Д.В.Дмитриев, В.Е.Шмагин

 (ФГУП «НПО им. С.А. Лавочкина)

КА «Фобос-Грунт» является первым аппаратом для дальнего космоса после длительного перерыва в данной области Российской космонавтики. Для обеспечения миссии была разработана новая операционная система реального времени (ОСРВ). Она обеспечивает необходимую скорость реакции на события, и функционирование научных и навигационных приборов. Данную ОСРВ планируется использовать в целой серии следующих аппаратов НПО им. С.А. Лавочкина.

В связи с важностью задания, к БКУ предъявляются повышенные требования в части функционирования и надёжности. Основной проблемой проверки БКУ является ограниченное время работы с лётными приборами. Вследствие таких условий невозможно обеспечить полный цикл проверок ОСРВ БКУ на штатных образцах приборах. Была поставлена задача разработать такой цикл проверок, который бы обеспечивал максимально возможный объём проверок.

С целью решения данной задачи был создан и отлажен испытательный стенд, который является аналогом лётного аппарата. Были сделаны технологические образцы лётных приборов, являющихся точными копиями по аппаратной и габаритной части. Все испытания штатной машины проводились, только после полной проверки БКУ на стенде.

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

Полученные на стенде результаты позволяют, проводить испытания лётных образцов приборов, без значительных затрат их времени наработки. Разработанный стенд позволил проверить функционирование ОСРВ в условиях максимально приближенных к настоящим. Полученные результаты позволили выявить нюансы и исправить их. С концом испытаний стенд не утратил свою значимость, так как в ходе миссии все команды перед отправкой на борт проверяются на стенде.[/size]

[Suzeren]

Честно говоря, читать все это словоблудие, на ночь глядя, довольно утомительно. Можно, конечно, продолжать всем этим заниматься, ведь надо же дотянуть до 1000 страниц.
Разумеется, процесс создания КА сложен и многообразен. Но, если отбросить словесную шелуху, во всем этом многообразии можно вычленить для примера три составных и основополагающих элемента. Это электрические интерфейсы, по которым выпускаются протоколы электрического сопряжения, информационные интерфейсы, по которым выпускаются протоколы информационно-логического взаимодействия, и, наконец, логика функционирования бортовых систем, включающая все типовые полетные операции и основные нештатные ситуации. Электрические испытания КА проводятся для проверки как раз этих элементов, причем ПО пишется, в первую очередь, для последних двух элементов, а все, что не относится к ним должно проверяться на стендах.
Ну а теперь взглянем на Фобос-грунт. Если кто внимательно следил за сообщениями СМИ, то, наверное обратил внимание на высказывание Поповкина о возможности перепрограммирания борта. Если сбросить пелену, то выяснится, что за эттим скрывалось признание того печального факта, что ФГ стартовал, не имея в составе ПО ряда типовых полетных операций, включая посадку на Фобос. Я, можно сказать, не первый год замужем, но по-моему в истории отечественной и мировой космонавтики еще не было КА, который запускался бы, не имея изначально возможности выполнить основную целевую задачу. Что это, как не профанация всей космонавтики. Да за одно только это надо всем, кто поставил свою подпись на разрешение пуска, оторвать я..ца.
Второй момент пока еще не слишком известен, но именно он стал последней каплей, погубившей Фобос-грунт. Из сообщений СМИ известно, что 23 ноября удалось включить передатчик и получить сигнал с ФГ. Но мало кто знает, что выключить ПРД не довелось, а бортовыми алгоритмами по сигналу Umin это не предусматривалось. В результате энергобаланс на борту стал отрицательным, а при наличии теней сначала разрядилась аккумуляторная батарея. Затем автоматика СЭС переключилась на ХИТ, но и он скоро разрядился до нуля, после чего, скореее всего, взорвался в конце ноября.
Вот я и спрашиваю, надо ли быть гением программирования, чтобы разработать алгоритм отключения лишней нагрузки по Umin. Так все эти разговоры про сложность ПО есть лишь попытки навести тень на плетень и запудрить мозги общественности. К этой же категории относятся и разговоры про солнечные вспышки, плазмоиды и американский радар.

Владимир, ну зачем писать о том, о чем слышали только, а сами не участвовали? Ну на худой конец поговорили бы вначале о том что было и что не было, прежде чем писать... А то получается, что Вам верят, а вы говорите неправильные вещи.
Я например принципиально не пишу ничего в теме о Спектре и Электро, потому что не занимался оными. Хотя в курсе всего происходящего.

Во-первых, посадка отрабатывалась, пожалуй, больше всего остального. В этом заслуга ИПМ РАН, которым была передана ЦВМ и которые с ее помощью построили у себя математический стенд. Имитировали все приборы на МКО платами, а штатная математика шла на ЦВМ под управлением штатной операционной системы и т.п. всего прилагающегося.
Далее, это все в обязательном порядке прогонялось на стенде, и на аппарате. Более того, с учетом НШС по отказам измерительных приборов. Кроме того, все это делалось еще раз на заключительном этапе в присутствии ЦНИИмашевцев и специалистов ИКИ.
Откуда вы взяли такой бред что посадки не было - не пойму.

Передатчик по Umin отключается. Не надо фантазировать. Если хотите - зайду и расскажу как устроен КАС и сигнальные датчики Umin. Что бы было понятнее как и на что реагировал аппарат.