Глава Роскосмоса о провале проекта "Фобос-Грунт"..

[Семён Семёныч Гонтмахер]

это круто!!!, по мнению Поповкина во всем виноваты амеры или инопланетяне...

http://vpk.name/news/63081_Glava_Roskosmosa_ne_hochetsya_nikogo_obvinyat_no.html


 Плохому танцору вечно чего-то мешает

[Liss]

Хотел просто грохнуть тему, поскольку уже процитировано местах в трех. Но все-таки ответьте, где в первоначальном интервью "Известиям" сказано, что ФГ грохнули инопланетяне или американцы? По-моему, там очень откровенно сказано, что и почему запустили 9 ноября 2011 г.

[Grigory987]

Хотел просто грохнуть тему, поскольку уже процитировано местах в трех. Но все-таки ответьте, где в первоначальном интервью "Известиям" сказано, что ФГ грохнули инопланетяне или американцы? По-моему, там очень откровенно сказано, что и почему запустили 9 ноября 2011 г.

Отвечаю.

Вот исходный текст интервью Поповкина на официальном сайте "Известий":

http://www.izvestia.ru/news/511258

Цитата:

Сегодня
нет ясности, почему не запустилась двигательная установка «Фобос-Грунта». Непонятны также частые сбои с нашими аппаратами в тот период, когда они летят над теневой для России стороной Земли — там, где мы не видим аппарат и не принимаем с него телеметрию. Не хочется никого обвинять, но сегодня есть очень мощные средства воздействия на космические аппараты, возможности применения которых нельзя исключать.

[Семён Семёныч Гонтмахер]

Уважаемый Лисс, грохнуть тему - это ваше неотъемлемое право, только вряд ли это что-то изменит. В следующий раз ( а я очень боюсь он не заставит себя ждать)  манагеры типа Поповкина сошлются на  Бермудский треугольник, Египетские пирамиды или Атлантиду.

[Octopus Sapiens]

Уважаемый Лисс, грохнуть тему - это ваше неотъемлемое право, только вряд ли это что-то изменит. В следующий раз ( а я очень боюсь он не заставит себя ждать)  манагеры типа Поповкина сошлются на  Бермудский треугольник, Египетские пирамиды или Атлантиду.

Поповкин в одном прав, такие средства есть, а значит они могут и будут применены (иначе они не создавались-бы).

[LRV_75]

Отвечаю.

Вот исходный текст интервью Поповкина на официальном сайте "Известий":

http://www.izvestia.ru/news/511258

Цитата:

Сегодня
нет ясности, почему не запустилась двигательная установка «Фобос-Грунта». Непонятны также частые сбои с нашими аппаратами в тот период, когда они летят над теневой для России стороной Земли — там, где мы не видим аппарат и не принимаем с него телеметрию. Не хочется никого обвинять, но сегодня есть очень мощные средства воздействия на космические аппараты, возможности применения которых нельзя исключать.

И где тут про инопланетян?

[morpheus]

А ответ не долго заставил себя ждать:
Сезон глупостей: Россия обвиняет США в космическом заговоре ("Time", США)
http://www.time.com/time/health/article/0,8599,2104251,00.html (оригинал)
http://www.inosmi.ru/russia/20120112/182767362.html (перевод)

[Вован]

Хотел просто грохнуть тему, поскольку уже процитировано местах в трех. Но все-таки ответьте, где в первоначальном интервью "Известиям" сказано, что ФГ грохнули инопланетяне или американцы? По-моему, там очень откровенно сказано, что и почему запустили 9 ноября 2011 г.

Отвечаю.

Вот исходный текст интервью Поповкина на официальном сайте "Известий":

http://www.izvestia.ru/news/511258

Цитата:

Сегодня
нет ясности, почему не запустилась двигательная установка «Фобос-Грунта». Непонятны также частые сбои с нашими аппаратами в тот период, когда они летят над теневой для России стороной Земли — там, где мы не видим аппарат и не принимаем с него телеметрию. Не хочется никого обвинять, но сегодня есть очень мощные средства воздействия на космические аппараты, возможности применения которых нельзя исключать.

Какие сбои? Речь должна идти про отказы систем управления.

[LRV_75]

А ответ не долго заставил себя ждать:
Сезон глупостей: Россия обвиняет США в космическом заговоре ("Time", США)
http://www.time.com/time/health/article/0,8599,2104251,00.html (оригинал)
http://www.inosmi.ru/russia/20120112/182767362.html (перевод)

Однако, станции ЕКА наглядно показали, что воздействовать на ФГ можно  

[avteka]

"Над нами также смеялись, когда мы говорили, что над СССР летают шпионы. Пока одного не сбили..."

(с) не мое, взято с  иносми.ру

[Tiger]

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

[Agent]

Хотел просто грохнуть тему, поскольку уже процитировано местах в трех. Но все-таки ответьте, где в первоначальном интервью "Известиям" сказано, что ФГ грохнули инопланетяне или американцы? По-моему, там очень откровенно сказано, что и почему запустили 9 ноября 2011 г.

Отвечаю.

Вот исходный текст интервью Поповкина на официальном сайте "Известий":

http://www.izvestia.ru/news/511258

Цитата:

Сегодня
нет ясности, почему не запустилась двигательная установка «Фобос-Грунта». Непонятны также частые сбои с нашими аппаратами в тот период, когда они летят над теневой для России стороной Земли — там, где мы не видим аппарат и не принимаем с него телеметрию. Не хочется никого обвинять, но сегодня есть очень мощные средства воздействия на космические аппараты, возможности применения которых нельзя исключать.

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

[ZOOR]

Ну чего копья ломать ...
Надо через пару месяцев посмотреть, что там с кадровыми перестановками в ГРУ (или СВР) - и все сразу станет понятно  :lol:

[pkl]

Да что там говорить! Оконфузились - так оконфузились, но зачем себя перед всем миром шутами гороховыми выставлять? А "Тайм" оттянулся знатно.

[LRV_75]

Да что там говорить! Оконфузились - так оконфузились, но зачем себя перед всем миром шутами гороховыми выставлять? А "Тайм" оттянулся знатно.

Ага

Может, сбои и непонятны, но причина должна быть ясна.

Это как это?

[zyxman]

Это как это?

Это начальственный диалект русского языка - чтоб его понимать и не сойти с ума, нужно быть начальником в русскоязычной стране, причем уровнем не ниже сказавшего

[sas]

Ну а что, шведы же гундосили про рЮсские подводные лодки в ихних водах. Дошло до того, что наши адмиралы стали на шведов орать, чтобы они эти "лодки" бомбили глубинными бомбами.

Вот и мы теперь "гундосим".

[Дмитрий Виницкий]

Угу, правда, сначала, советская подлодка села на мель в миле от базы ВМФ Карлскруна в 1981-м. Так что все последующие видения имели железобетонные причины...

[pkl]

А потом началась шиза. Наши адмиралы уже, наверное, раз десять прокляли тот день, когда послали ту подлодку. :lol:

[Lamort]

Может, сбои и непонятны, но причина должна быть ясна.

Это как это?

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

 Но непонятно как это применить к Фобос-Грунту, который не может быть подвержен целенаправленным воздействиям.

[LRV_75]

Может, сбои и непонятны, но причина должна быть ясна.

Это как это?

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

Скажите пожалуйста, на каком витке Вы проводили эти эксперименты по локализации неисправности, известные всем тестировщикам?

Но непонятно как это применить к Фобос-Грунту, который не может быть подвержен целенаправленным воздействиям.

Ах вот оно что, ну надо же  

[Lamort]

Скажите пожалуйста, на каком витке Вы проводили эти эксперименты по локализации неисправности, известные всем тестировщикам?

С АМС Фобос-Грунт, разумеется, ничего подобного не было проделано, так как умерла она, практически сразу, а вот с MSL недавно были проблемы с ПО, которые, вроде бы, удалось решить, посмотрите в соответствующей теме, причём работали, похоже, старым добрым "методом тыка".

[Дмитрий Виницкий]

Никакого метода тыка с MSL не было, а проблемы подобного рода возникают и решаются в рабочем порядке. Есть стенд, в конце-концов.

[Семён Семёныч Гонтмахер]

А потом началась шиза. Наши адмиралы уже, наверное, раз десять прокляли тот день, когда послали ту подлодку. :lol:

Они не посылали ее в воды Швеции. Просто на этой старенькой лодке 613 проекта не работала половина навигационного оборудования, штурман был дилетантом - даже не мог определить место по звездам. Поэтому они плыли ( вернее как говорят моряки шли ) сами не зная куда... И это на Балтике.  Традиционное русское рас-3.14-здяйство

[Lamort]

Никакого метода тыка с MSL не было, а проблемы подобного рода возникают и решаются в рабочем порядке. Есть стенд, в конце-концов.

Если это не "метод тыка", то что тогда "метод тыка".

http://www.jpl.nasa.gov/news/news.cfm?release=2012-004

Diagnostic work continues in response to the reset triggered by use of star-identifying software on the spacecraft on Nov. 29.  In tests at JPL, that behavior has been reproduced a few times out of thousands of test runs on a duplicate of the spacecraft's computer, but no resets were triggered during similar testing on another duplicate. The spacecraft itself has redundant main computers. While the spacecraft is operating on the "A side" computer, engineers are beginning test runs of the star-identifying software on the redundant "B side" computer to check whether it is susceptible to the same reset behavior.

Перевод:

Продолжается диагностика, связанная с перезагрузкой из-за ПО распознавания звезд на аппарате, произошедшей 29 ноября. В тестах в JPL это поведение было воспроизведено несколько раз из тысяч прогонов на одном (наземном) аналоге БВК КА, но при таком же тестировании на другом аналоге перезагрузок выявлено не было. У КА есть резервирование БВК. Когда КА работает на БВК "стороны А", инженеры начинают тестовые прогоны на резервном БВК "стороны Б", чтобы проверить, подвержен ли он такому же дефекту (перезагрузке из-за ПО звездного датчика).[/size]

Тьфу-тьфу-тьфу.

[Дмитрий Виницкий]

Очевидно вы не понимаете разницы между перебором вариантов и ковырянием в носу.
Манёвр успешно выполнен.

[PIN]

Если это не "метод тыка", то что тогда "метод тыка".

Это никак не "метот тыка", а испытания на стенде. И уже понятно. что проблема воспроизводится не гарантированно. Что не значит того, что она не будет локализована. С аналогичным лично сталкивался, в итоге либо производитель, либо мы сами находили условия, при которых пролема стабильно воспроизводится. И "лечили" либо обновлением ПО, либо вводом дополнительных ограничений на эксплуатацию.

[Старый]

Поэтому они плыли ( вернее как говорят моряки шли ) сами не зная куда... И это на Балтике.  Традиционное русское рас-3.14-здяйство

Главное что они плыли прямо. А в Балтике если всё время плыть прямо то обязательно куда-нибудь попадёшь.

[Lamort]

Если это не "метод тыка", то что тогда "метод тыка".

Это никак не "метот тыка", а испытания на стенде. И уже понятно. что проблема воспроизводится не гарантированно. Что не значит того, что она не будет локализована. С аналогичным лично сталкивался, в итоге либо производитель, либо мы сами находили условия, при которых пролема стабильно воспроизводится. И "лечили" либо обновлением ПО, либо вводом дополнительных ограничений на эксплуатацию.

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

[Дмитрий Виницкий]

Гм. Т.е. по вашему, программисты JPL не занимались анализом, а просто, крутили одну и ту же операцию? А в чём, позвольте спросить, смысл, тогда?

[LRV_75]

Если это не "метод тыка", то что тогда "метод тыка".

Это никак не "метот тыка", а испытания на стенде. И уже понятно. что проблема воспроизводится не гарантированно. Что не значит того, что она не будет локализована. С аналогичным лично сталкивался, в итоге либо производитель, либо мы сами находили условия, при которых пролема стабильно воспроизводится. И "лечили" либо обновлением ПО, либо вводом дополнительных ограничений на эксплуатацию.

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

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

[Lamort]

Гм. Т.е. по вашему, программисты JPL не занимались анализом, а просто, крутили одну и ту же операцию? А в чём, позвольте спросить, смысл, тогда?

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

[Старый]

"Аналитический тык" это метод при котором не просто тыкают наугад а после каждого тыка анализируют что получилось.

[Lamort]

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

Любой метод применяется осознанно, а что касается взлома сейфов, то вы даже себе не представляете как осознанно действуют взломщики.
 Разница в том, что в одном случае делается попытка выявить и устранить причину, а в другом случае путём какого-то подбора воздействий на объект получается нужный результат.

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

[Дмитрий Виницкий]

А кто вам сказал, что в случае с MSL, это долго, дорого или невозможно?

[LRV_75]

"Аналитический тык" это метод при котором не просто тыкают наугад а после каждого тыка анализируют что получилось.

Да, если при каждом последующем тыке возвращаемая ошибка изменяется, а если постоянно одна и таже и нет версий о причине неисправности, то аналитика переходит в ранг философии  

[Lamort]

А кто вам сказал, что в случае с MSL, это долго, дорого или невозможно?

Сделать анализ кода ПО и найти причину почему оно именно таким образом нештатно работает?

[Дмитрий Виницкий]

Переведите.

[LRV_75]

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

Да, меня не устраивает метод о котором Вы говорите, потому, что я знаю как тестируются сложные системы, которые находятся в боевом режиме. Методом "научного тыка" они не тестируются или скажем так ... тестируются очень аккуратно  

[Старый]

Да, если при каждом последующем тыке возвращаемая ошибка изменяется,

То надо ткнуть в другое место, дальше или ближе от места выхода ошибки.

а если постоянно одна и таже и нет версий о причине неисправности,

То опять же надо ткнуть в другое место.
 Главное ничего не перепутать.

то аналитика переходит в ранг философии  

Дык не зря ж в технических вузах диамат учат.

[Lamort]

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

Да, меня не устраивает метод о котором Вы говорите, потому, что я знаю как тестируются сложные системы, которые находятся в боевом режиме. Методом "научного тыка" они не тестируются или скажем так ... тестируются очень аккуратно  

Когда КА работает на БВК "стороны А", инженеры начинают тестовые прогоны на резервном БВК "стороны Б", чтобы проверить, подвержен ли он такому же дефекту[/size] (перезагрузке из-за ПО звездного датчика).

А теперь сформулируйте свои возражения по сути, в данном случае вообще выясняется существование такого же дефекта на втором компьютере.
 У вас есть сомнения, что MSL "в боевом режиме"?

[Дмитрий Виницкий]

Это моделирование отказа. при чем тут "тык"?

[LRV_75]

Когда КА работает на БВК "стороны А", инженеры начинают тестовые прогоны на резервном БВК "стороны Б", чтобы проверить, подвержен ли он такому же дефекту[/size] (перезагрузке из-за ПО звездного датчика).

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

Ага, только после того, как Вы сформулируете, что они имели ввиду под тестовыми прогонами  :wink:

[Lamort]

Ага, только после того, как Вы сформулируете, что они имели ввиду под тестовыми прогонами  :wink:

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

[Wishbone]

У меня недостаточно информации,

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

"Тык" есть поиск разнообразных дефектов путем случайного отбора точек в пространстве входов, а здесь мы имеем дело с тестированием, есть ли ЗАРАНЕЕ ИЗВЕСТНЫЙ дефект на данном ("Б") образце техники. Мы не знаем, проявляется ли дефект с перезагрузкой недетерминированно или же увязан с какими-то значениями входных параметров.

[LRV_75]

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

Ну вот, это Ваше предположение. А я считаю, что там шло обдуманное тестирование  :wink:
На самом деле, метод научного тыка - это крайняя точка безисходности

[Lamort]

У меня недостаточно информации,

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

"Тык" есть поиск разнообразных дефектов путем случайного отбора точек в пространстве входов, а здесь мы имеем дело с тестированием, есть ли ЗАРАНЕЕ ИЗВЕСТНЫЙ дефект на данном ("Б") образце техники. Мы не знаем, проявляется ли дефект с перезагрузкой недетерминированно или же увязан с какими-то значениями входных параметров.

Вы просто называете "тыком" поиск неизвестных дефектов, а я называю так любое исследование объекта путём исследования его реакции на некоторый набор входов с неизвестным заранее результатом.

[Lamort]

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

Ну вот, это Ваше предположение. А я считаю, что там шло обдуманное тестирование  :wink:
На самом деле, метод научного тыка - это крайняя точка безисходности

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

[LRV_75]

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

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

[Lamort]

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

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

Всё это было бы здорово, если бы объект был простой, ПО также было простое и всё это, в таком сугубо идеальном случае, делала небольшая группа людей от примитивных комплектующих до готового изделия.
 Не знаю как относительно АМС Фобос-Грунт, но думаю, что тот же MSL настолько сложная система, что даже при желании абсолютно детерминированный анализ алгоритма просто невозможен.
 Зато можно найти способ как его заставить работать не вникая во внутренние причины проблемы.
 Это то же самое, что бывает когда вы принимаете таблетку от головной боли и она проходит, но только для описания механизма возникновения этой боли потребуется хорошая научная работа.

 Один вопрос к вам, что это за объекты у вас на работе, которые вы аккуратно щупаете?

[LRV_75]

Всё это было бы здорово, если бы объект был простой, ПО также было простое и всё это, в таком сугубо идеальном случае, делала небольшая группа людей от примитивных комплектующих до готового изделия.
 Не знаю как относительно АМС Фобос-Грунт, но думаю, что тот же MSL настолько сложная система, что даже при желании абсолютно детерминированный анализ алгоритма просто невозможен.
 Зато можно найти способ как его заставить работать не вникая во внутренние причины проблемы

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

Один вопрос к вам, что это за объекты у вас на работе, которые вы аккуратно щупаете?

Распределенная информационная система. А раньше и борт ракета-носителя щупали и по таким же принципам  :wink:  На земле, естесственно   А перед тем как идти на борт РН, щупают имитатор борта  :wink:

[Agent]

А кто вам сказал, что в случае с MSL, это долго, дорого или невозможно?

Сделать анализ кода ПО и найти причину почему оно именно таким образом нештатно работает?

Перегрузка компьютера при подключении периферии означает ровно одно - данные от периферии отсутствуют(контрольная сумма не совпадает) или не имеют смысла (сами данные или их диффернциал ). С ПО все нормально. Это на 99% железо.
Все что можно сделать - попробовать переключить эту периферию на второй компьютер. Если он тоже перезагрузится, то далее (при возможности вычленить из ерратик данных полезный сигнал без перезагрузки), ставиться программная заплатка в виде дополнительного входящего фильтра.
Для выработки алгоритма фильтра и нужны сотни и тысячи прогонов.

[Lamort]

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

Замечательно, а откуда, например, вы знаете критичные места не имея длительного опыта тестирования системы и откуда у вас уверенность в том, что вы всё, что надо протестировали?
 Да и вообще это случай отладки в процессе разработки когда ещё доступна или вообще существует вся рабочая информация разработчика, а после сдачи ПО заказчику этой информации просто может не быть.

Один вопрос к вам, что это за объекты у вас на работе, которые вы аккуратно щупаете?

Распределенная информационная система. А раньше и борт ракета-носителя щупали и по таким же принципам  :wink:  На земле, естесственно   А перед тем как идти на борт РН, щупают имитатор борта  :wink:

Слово "щупать" вызывает определённые ассоциации.

[LRV_75]

Замечательно, а откуда, например, вы знаете критичные места не имея длительного опыта тестирования системы и откуда у вас уверенность в том, что вы всё, что надо протестировали?

Длительный опыт тестирования системы должен иметься, иначе спутники не запускают, ИМХО

Да и вообще это случай отладки в процессе разработки когда ещё доступна или вообще существует вся рабочая информация разработчика, а после сдачи ПО заказчику этой информации просто может не быть.

Правильно, в процессе разработки.
А Вы считаете, что ПО спутника надо тестировать в процессе полета?

Слово "щупать" вызывает определённые ассоциации.

Телеметристов называют гинекологами ракет  :wink:

[Suzeren]

А Вы считаете, что ПО спутника надо тестировать в процессе полета?

В том числе. Именно для этого предусматривается этап ЛКИ :wink: Наземные средства отработки при всем желании не позволяют проверить все.

Телеметристов называют гинекологами ракет  :wink:

Один умный человек как-то сказал мне: "Если все работает штатно, то телеметрия не нужна" Конечно, это абстракция, но в чем-то он очень прав.
Более того, телеметрия аппаратов дальнего космоса (ведь о них речь в этой теме, а не о ракетах?) в условиях существенных ограничений по скорости передачи (ну например 4 или 16 Бит/сек) это совсем не телеметрия ракет. Попробуйте "дотащить" такой аппарат куда нужно...
Приходится ужаться в ТМ параметрах до минимума минимурного.

[LRV_75]

В том числе. Именно для этого предусматривается этап ЛКИ :wink: Наземные средства отработки при всем желании не позволяют проверить все.

Согласен, но есть такое понятие -Готовность к ЛКИ. Т.е. когда на земле провели все возможные проверки и тестирование, которое можно провести на земле и результаты этих проверок - положительные. Все, принимается решение, что дальнейшее тестирование надо переносить в космос - начинается ЛКИ

Более того, телеметрия аппаратов дальнего космоса (ведь о них речь в этой теме, а не о ракетах?)

А я уже запутался. Мы про Фобос-Грунт или про MSL ?  

[PIN]

Перегрузка компьютера при подключении периферии означает ровно одно

У этого может быть великое множество причин...

[zyxman]

А кто вам сказал, что в случае с MSL, это долго, дорого или невозможно?

MSL очень сложная система - в теме про программирование АМС упоминалось что по заявлению разработчиков в MSL ЕМНИП 3.5млн строк кода на С++ и разработчиков 30 человек..
- В ядре Линукс цифры где-то того-же порядка, кроме одного исключения, что ядро Линукс разрабатывают/тестируют миллионы людей.
Миллион против 30 означает что при нахождении проблемы вероятность что кто-то сразу может надежно воспроизвести проблему для Линукса в 10000 раз выше чем для MSL, и это конечно сильно но всё равно проблемы с Линуксом как известно устраняются не мгновенно, и проблемы находят тоже не всегда достаточно рано.
При этом для Линукса в многих случаях можно либо откатить на предыдущую версию ядра, либо вообще перенести систему на другую ОС, а для MSL нужно решить проблему здесь и сейчас.
Вот по совокупности и выходит, что MSL просто в принципе и так летит весь в заплатках, а сейчас наложат еще несколько заплаток и полетят дальше.. Конечно, продолжат искать корень проблемы, и когда найдут, вероятно сделают заплатки поаккуратнее.

[Дмитрий Виницкий]

А при чем тут Линукс? MSL использует VxWorks с многолетними наработками JPL для роверов, и сравнивать с настольной ОС самого широкого назначения, не то что бессмысленно, а смешно.

[Agent]

Перегрузка компьютера при подключении периферии означает ровно одно

У этого может быть великое множество причин...

Для перезагрузки RTOS? А ну перечислите

[PIN]

Не собираюсь заниматься обучением забесплатно в данном случае. И перечислять миссии и случаи перезагрузки бортового ПО из-за вылезших проблем самого разного уровня при, например, начале обмена с включаемыми в ходе LEOP датчиками или научными приборами или при пропуске acquisition из-за совершенно некритичных причмн.
 
Тем более, это все не для широких масс.

[zyxman]

А при чем тут Линукс? MSL использует VxWorks с многолетними наработками JPL для роверов, и сравнивать с настольной ОС самого широкого назначения, не то что бессмысленно, а смешно.

Виницкий, может вы перестанете кичиться своей ограниченностью?
- Специалисты знают, что для выявления недостатков конструкции есть (не для всех конечно случаев, но для многих) способ распараллеливания времени, то есть буквально, если у вас есть например жесткий диск, то вы можете его тестировать одну штуку тысячу лет, а можете включить одновременно тысячу штук одинаковых жестких дисков и параллельно их все вместе использовать, и получите одинаковый результат поиска недостатков конструкции с учетом конечно замечания выше.
- Собственно, для софта этот метод умножения времени работает отлично.
Причем тут важный нюанс, что для тестирования лучше чтобы оно происходило одновременно в разных условиях - в разных организациях, в разном климате итд.
И вот собственно я и с VxWorks сталкивался, и я вам ответственно заявляю, что оно более глючное чем Линукс, как раз потому что Линукс очень эффективно использует миллионы бесплатных тестеров для нахождения недостатков, и такое количество тестеров для VxWorks держать невозможно по финансовым причинам.

[Дмитрий Виницкий]

Но в JPL сидят ограниченные олухи и упорно не хотят использовать бесплатный и такой безглючный линукс. Жалкие, ничтожные люди, бесстыже пилящие бюджеты! :mrgreen:

[zyxman]

Специально для тех кто в танке объясняю, что JPL нужен ПРОДУКТ, то есть ОС вместе со средствами разработки и с поддержкой.
Плюс JPL как вы верно заметили уже имеет наработки для VxWorks, и перенос этих наработок на другую ОС тоже будет стоить недешево.
В третьих железо роверов несколько отличается от железа на котором работает мейнстримный Линукс - сейчас пока еще очень мало Линукс работают не на х86, и в стороне от х86 уже нет таких масштабов тестирования.
По совокупности получается, что видимо ПОКА никто не предлагает JPL нормальное для них решение на базе Линукс, сравнимое с VxWorks, и они используют VxWorks.

PS В конце концов они могут и MSDOS использовать - главное чтобы миссии были успешны

[Дмитрий Виницкий]

К чему весь этот поток умностей?
Показать, что вы знаете такие слова? Я давно уже знаю о том, что вы подобное знаете?
При чем DOS??? Кстати, знаете ли вы, на каком процессоре работал Sojourner Rover? Думаю, вас изумлю: 80C85.
А линукс давным давно портирован на PowerPC 750, уже сто лет.

[Agent]

Не собираюсь заниматься обучением забесплатно в данном случае. И перечислять миссии и случаи перезагрузки бортового ПО из-за вылезших проблем самого разного уровня при, например, начале обмена с включаемыми в ходе LEOP датчиками или научными приборами или при пропуске acquisition из-за совершенно некритичных причмн.
 
Тем более, это все не для широких масс.

У меня в RTOS около 10 лет опыта. Причем в системах куда более сложных чем среднестатический КА. И более ответственных - при сбоях могут быть трупы.

[Lamort]

Замечательно, а откуда, например, вы знаете критичные места не имея длительного опыта тестирования системы и откуда у вас уверенность в том, что вы всё, что надо протестировали?

Длительный опыт тестирования системы должен иметься, иначе спутники не запускают, ИМХО

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

Да и вообще это случай отладки в процессе разработки когда ещё доступна или вообще существует вся рабочая информация разработчика, а после сдачи ПО заказчику этой информации просто может не быть.

Правильно, в процессе разработки.
А Вы считаете, что ПО спутника надо тестировать в процессе полета?

В случае АМС всё время сообщают о проблемах которые выявляются и устраняются уже в полёте.

Слово "щупать" вызывает определённые ассоциации.

Телеметристов называют гинекологами ракет  :wink:

Однако, мне-то пришли на ум куры.

[zyxman]

А линукс давным давно портирован на PowerPC 750, уже сто лет.

Мало ли чего куда портировано? - У Линукса модель такая, что разработчики в подавляющем большинстве случаев на малом бюджете, и конечно-же экономия на тестировании, и поэтому ВСЕГДА сначала спортированное страшно сырое и глюкавое, и после портирования всегда есть значительное время, когда тратятся СОТНИ ЕСЛИ НЕ ТЫСЯЧИ человеко-лет народа уровня студентов на тестирование, отладку и доработку.

И только после этих многих-многих человеко-лет Линукс на х86 стала стабильной и надежной, а на паверах и прочих рисках оно до сих пор сырое, но так уж сложилось что на АМС х86 практически не встречается.

[Дмитрий Виницкий]

А при чём тут Х86?

[morpheus]

А вот уже и имена антигероев ищут...  http://twitter.com/rogozin

Amb. Dmitry Rogozin
Жду от Роскосмоса обещанный доклад о причинах аварий, имена антигероев, а также взгляд на перспективы развития космической отрасли до 2030г.
9 ч назад с помощью web

[X]

https://twitter.com/VRSoloviev

[Дмитрий Виницкий]

Почему вы спорите с бабами? :mrgreen:

[zyxman]

А при чём тут Х86?

А при том, что Линуксовая модель хорошо работает только на х86 (ввиду его огромной распространности), а на других процессорах ввиду малого размера сообщества нужны другие подходы, вроде того что реализован Wind River.

[Дмитрий Виницкий]

А мне казалось, что железок с Embedded Linux в мире, на порядок больше, всех АМС, ПК и серверов, вместе взятых.

[PIN]

Правильно казалось.
Посмотрел вокруг - только в одной комнате 3 устройства с Linux. И внутри нет процессоров с архитектурой/системой команд x86

[zyxman]

А мне казалось, что железок с Embedded Linux в мире, на порядок больше, всех АМС, ПК и серверов, вместе взятых.

Но людей программирующих Embedded Linux на порядки меньше, а баги фиксят не железки а люди.

PS А у я кроме пары непрограммирующих знакомых, у которых андроидофоны, больше практически и не встречал не-х86 Linux..

[X]

А мне казалось, что железок с Embedded Linux в мире, на порядок больше, всех АМС, ПК и серверов, вместе взятых.

Но людей программирующих Embedded Linux на порядки меньше, а баги фиксят не железки а люди.

PS А у я кроме пары непрограммирующих знакомых, у которых андроидофоны, больше практически и не встречал не-х86 Linux..

Роутеров на мипс море. Телевизоров современных. Спутниковых ресиверов. Медиаплейеров. Просто мало кто знает на чем оно работает.

А для фикса багов важно именно кол-во пользователей так как баг репорты составляют именно они как напрямую так и опосредованно (например через форумы производителей).

[zyxman]

Роутеров на мипс море. Телевизоров современных. Спутниковых ресиверов. Медиаплейеров. Просто мало кто знает на чем оно работает.

А я как раз знаю на чем работает. И я дейстивительно НАДЕЖНО знаю, что ни у кого из моих знакомых нет НИЧЕГО под Линуксом кроме андроидофонов.
- Есть даже у некоторых роутеры на Cisco IOS, и на VxWorks, и куча оборудования на совсем малоизвестных ОС, но Линукса нет.
Я сам лично несколько месяцев искал себе "для препарирования и экспериментов" железку на ARM или MIPS (я сам электронщик и программист с опытом Embedded, так что чего у них внутрях знаю более чем достаточно), но так ничего приличного не нашел.

А для фикса багов важно именно кол-во пользователей так как баг репорты составляют именно они как напрямую так и опосредованно (например через форумы производителей).

Лицензия на Линукс БЫЛА прописана так, что до определенной версии производитель мог оставлять багофиксы у себя и давать пользователям ТОЛЬКО двоичные патчи, поэтому эти море роутеров на ядро Линукса на НЕ-х86 влияли очень слабо.
Кстати, надо будет исследовать вопрос подробнее - возможно в Андроиде древнее ядро 2.4 как раз ввиду перехода современного ядра на другую, более жесткую лицензию :wink:

[X]

Роутеров на мипс море. Телевизоров современных. Спутниковых ресиверов. Медиаплейеров. Просто мало кто знает на чем оно работает.

А я как раз знаю на чем работает. И я дейстивительно НАДЕЖНО знаю, что ни у кого из моих знакомых нет НИЧЕГО под Линуксом кроме андроидофонов.
- Есть даже у некоторых роутеры на Cisco IOS, и на VxWorks, и куча оборудования на совсем малоизвестных ОС, но Линукса нет.
Я сам лично несколько месяцев искал себе "для препарирования и экспериментов" железку на ARM или MIPS (я сам электронщик и программист с опытом Embedded, так что чего у них внутрях знаю более чем достаточно), но так ничего приличного не нашел.

А для фикса багов важно именно кол-во пользователей так как баг репорты составляют именно они как напрямую так и опосредованно (например через форумы производителей).

Лицензия на Линукс БЫЛА прописана так, что до определенной версии производитель мог оставлять багофиксы у себя и давать пользователям ТОЛЬКО двоичные патчи, поэтому эти море роутеров на ядро Линукса на НЕ-х86 влияли очень слабо.
Кстати, надо будет исследовать вопрос подробнее - возможно в Андроиде древнее ядро 2.4 как раз ввиду перехода современного ядра на другую, более жесткую лицензию :wink:

Купите себе почти любой dlink - там линукс на мипсе - цена от 900 рэ.
Это если у вас денег на нормальную отладочную плату на например арме нет.
И поменьше гонору.
В андройде кстати уже давно ядро 2.6.38 и задержка с переходом там была связана совсем не с типом процессора.
Производители железа кстати очень активно трудятся над ядром и дровами то что вы не в курсе ситуации не меняет.
Лицензия свежая запрещает только тивоизацию - вот и все отличие от старой.
Про то ко я сам в отличии от вас писать не буду - будем скромнее.

[Вал]

Роутеров на мипс море. Телевизоров современных. Спутниковых ресиверов. Медиаплейеров. Просто мало кто знает на чем оно работает.

А я как раз знаю на чем работает. И я дейстивительно НАДЕЖНО знаю, что ни у кого из моих знакомых нет НИЧЕГО под Линуксом кроме андроидофонов.
- Есть даже у некоторых роутеры на Cisco IOS, и на VxWorks, и куча оборудования на совсем малоизвестных ОС, но Линукса нет.
Я сам лично несколько месяцев искал себе "для препарирования и экспериментов" железку на ARM или MIPS (я сам электронщик и программист с опытом Embedded, так что чего у них внутрях знаю более чем достаточно), но так ничего приличного не нашел.

А для фикса багов важно именно кол-во пользователей так как баг репорты составляют именно они как напрямую так и опосредованно (например через форумы производителей).

Лицензия на Линукс БЫЛА прописана так, что до определенной версии производитель мог оставлять багофиксы у себя и давать пользователям ТОЛЬКО двоичные патчи, поэтому эти море роутеров на ядро Линукса на НЕ-х86 влияли очень слабо.
Кстати, надо будет исследовать вопрос подробнее - возможно в Андроиде древнее ядро 2.4 как раз ввиду перехода современного ядра на другую, более жесткую лицензию :wink:

Откройте для себя BusyBox. А андроид уж сто лет в обед на ядре 2.6

[Athlocatle]

Я ничего не понимаю. Какие-то линуксы тут обсуждаются, ещё какая-то хрень, кроме интервью Поповкина...

[Дмитрий Виницкий]

Я не вижу в этом интервью ничего, достойного обсуждения.

[Athlocatle]

Я не вижу в этом интервью ничего, достойного обсуждения.

Так и не обсуждайте. Кто-то принуждает?

[Дмитрий Виницкий]

Ну, вы же переживаете, почему-то?

[Athlocatle]

Ну, вы же переживаете, почему-то?

1. Вас расстраивают мои переживания?
2. Я вижу несоответствие темы обсуждения теме ветки. Это не переживание.
3. Вы слишком часто пользуетесь запятыми, читать сложно.

[Дмитрий Виницкий]

А разве, там, запятые не нужны??? :mrgreen:

[zeaman]

А что народ думает про RTEMS?   Маленькое ядро (что значит после сброса грузится быстро), поддерживает POSIX и  ITRON. Работает без MMC, все в одном ринге  (что может быть и хорошо для критических применений)

[Veganin]

Бразильская аномалия могла погубить "Фобос-Грунт", заявил эксперт

"Если запуск осуществляется с Байконура, то трасса полета ракеты-носителя с космическим аппаратом проходит над зоной Бразильской магнитной аномалии. Это, по сути, огромная геомагнитная "дыра". За два дня до пуска станции "Фобос-Грунт" была зафиксирована мощная вспышка на Солнце, которая, создав волну ионизации в верхних слоях атмосферы, могла вызвать сбой в работе электронной аппаратуры станции, вследствие чего управлять им не представлялось возможным", — сказал эксперт.

В частности, мощные вспышки на Солнце и выбросы плазмы могли повлиять на работу аппаратуры спутников "Гео-ИК-2", трех спутников "Глонасс" в 2010 году и космического аппарата "Экспресс АМ-4" в августе 2011 года, а также грузового космического корабля "Прогресс М-12М" в августе 2011 года", — сказал эксперт.

http://ria.ru/space/20131127/980091169.html

Наконец-то кто-то сказал правду! Правда, не всю: все бяки с Бризами-М и ДМ-ми также происходили из-за повышенной солнечной активности. Более того, Советский Союз рухнул после мощной вспышке на Солнце    

РИА Новости, как не стыдно!    Читайте хоть свои сообщения http://ria.ru/science/20130702/947021354.html
или Википедию. Вся статья - ахинея полная.
PS
Надеюсь, пресс-службы РКК Энергия и ЦиХа решительно опровергнут домыслы неизвестного эксперта и заявят во всеуслышание, что причина упомянутых неудач - в браке их продукции и в плохо построенной работе ОТК, а не в солнечных вспышках    Или кто-то с радостью заносит в блокнотик еще одну отмазку, наряду с облучением вражеским радаром, пролетом около Земли астероида и т.п. бред  

[PIN]

Треш полный.

[Старый]

Первый ДМ-03 перезаправили тоже из-за вспышки на Солнце, и из-за неё же поставили задом наперёд датчики в Протон со вторым ДМом-03. 
А фамилия "эксперта" осталась неизвестной? Это часом не Иван Моисеев идевается над РИАН? По стилю похоже...

[АниКей]

УДК 629.78.054
 ЧТО ПОГУБИЛО «ФОБОС - ГРУНТ»? ВЛИЯНИЕ ПЛАЗМЫ НА КОСМИЧЕСКИЕ АППАРАТЫ .
Ю . В . Кубарев Докт. физ. - мат. наук, профессор, вице - президент и действительный член Академии инженерных наук им. А.М. Прохорова, лауреат Государственной премии СССР, заслуженный деятель науки РФ, член Международной ассоциации авторов научных открытий, почетный профессор Шанхайской аэрокосмической академии Ю.В. Кубарев (МГУПИ) В статье ученый - физик, автор научного открытия в области физики плазмы излагает собственную версию причин гибели космического аппарата «Фобос - Грунт». Его выводы основаны на открытом им законе и результатах лабораторных и натурных экспериментов «Куст» (1977 – 1979 гг.) и «Старт» (1987 г.), проведенных в различных регионах Земли в верхней атмосфере, ионосфере и магнитосфере с магнитоплазмодинамическими ускорителями, установленными на метеорологических ракетах. Для повышения надежности функционирования будущих высокоорбитальных и межпланетных пилотируемых космических полетов представляют интерес предложенные автором способы и устройства плазменной нейтрализации электростатических зарядов на ПКА с помощью маломощных МПДУ . Ускорители большой мощности могут являться основой ЭРД мегаваттного класса. Ключевые слова: магнитоплазмодинамический ускоритель (МПДУ), плазма, плазменный нейтрализатор, Бразильская геомагнитная аномалия , «Фобос - Грунт»

  http://www.gctc.ru/media/files/Periodicheskie_izdaniya/Magazine.10.pdf   http://www.gctc.ru/media/files/Periodicheskie_izdaniya/ppk_2014_2_total_11.pdf

[PIN]

"Бортовая вычислительная машина сбилась"...гениально.

[Notfound]

Ю . В . Кубарев Докт. физ. - мат. наук, профессор, вице - президент и действительный член Академии инженерных наук им. А.М. Прохорова, лауреат Государственной премии СССР, заслуженный деятель науки РФ, член...

Стоит добавить: "родился 11 сентября 1936 г.". Это может объяснить появление указанных выше текстов данного автора