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

[TAU]

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

И все равно "рулоны" блок-схем составляются. Учитывающие все ветви.
Это входит в обязательное документирование критических приложений.
Почему бы не сделать их сами программами?
Кстати, бороться с "площадью бумажки" позволяет декомпозиция (иерархия) в какой-то степени.

В любом случае логика в графическом представлении виднее, нежели в пачках текстов.

[ITop]

Вообще странно:

2 независимых антенных входа на приём (с разных полусфер) и 2 не зависимых выхода на передачу (правда через 2 делителя).

Но уж на приём то резерв есть.

Либо до прямых команд (кроме запроса на ТМИ) ещё не дошли (не получается пока или боятся), либо оба входа не работают (тогда всё).

[Разъём]

Всё вышеперечисленное сходится на отказе включения МДУ.

Не по програмной причине, а по какой-то тупой и железной.

А если ФГ не смог из за отказа или программного глюка построить астроориентацию и до включения МД дело не дошло?

Тогда бы МДУ (о нём жеречь?) без проблем бы сегодня трудился в составе СОиС, чего как мы все видим по падающему перигею - он делать так же не желает.

Логично?

Поток сознания... Самые жаркие споры бывают только у дилетантов. задолбал....

[ksm15]

Предполагаю, что сигнал на включение МДУ прошёл, но она не включилась. Следовательно, сейчас станция по логике думает, что летит с опорной орбиты (поддерживает ориентацию). ТМИ пишется, когда память переполнится предположительно должен быть сброс информации. Можно ли прикинуть когда произойдёт момент переполнения памяти. И каковы могут быть дальнейшие последствия?

[Wishbone]

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

И все равно "рулоны" блок-схем составляются. Учитывающие все ветви.
Это входит в обязательное документирование критических приложений.
Почему бы не сделать их сами программами?
Кстати, бороться с "площадью бумажки" позволяет декомпозиция (иерархия) в какой-то степени.

В любом случае логика в графическом представлении виднее, нежели в пачках текстов.

Проходили. Да, ГОСТы требуют. Проехали. Кто рулоны читает? Пишите комментарии в коде и называйте идентификаторы по-человечески, будет проще жить Вам и тому, кто прочитает код.

[Старый]

Выпав в защитный режим аппарат включает приёмник и ждёт команд.
 Получает команду передать телеметрию и тогда только включает передатчик и передаёт её.

Это только ваше имхо или имеются документальные подтверждения?

Так делают все известные космические аппараты.

Со стороны разработчиков было бы странно заставить аппарат только ожидать команды, если заранее известно, что никаких команд на этом этапе не может быть принято  в принципе.

Я думаю разработчикам прийдётся долго и мучительно объясняться за столь "странное" решение. Не за то что аппарат ждёт а за то что команд невозможно передать в принципе.
 О причинах таких решений я уже высказывался выше.  

Что мешает, к примеру, при срабатывании значительного таймаута на прием команды передать короткую ТМИ с кодами состояния основных систем? Ничего не мешает.

Мешает например отсутствие в зоне видимости приёмной станции. Которых на весь мир толи две толи три а для опорной орбиты ажно одна. То есть реально это будет пустопорожняя разрядка аккумуляторов.

У вас, как мне кажется, привратное представление о том, что есть "защищенный режим".

Ну ясное дело... Конечно превратное...

Никаких фундаментальных препятствий для такой операции, как передача ТМИ, там нет.

И тут нет никаких фундаментальных препятствий. Подай команду и качай телеметрию...
 Кстати даже не в безопасном а даже и в обычном режиме так делается.

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

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

А разве где то были доказательства того, что роверы в этом режиме не отправляли ТМИ, пусть и в сильно упрощенной форме? Откуда тогда вообще узнали о том, что они выпали в сейф-моде?

Ну во первых один только Спирит. А узнали оттуда что он вообще пропал. Его уже начали хоронить но удалось откачать передаваемыми командами. И тоже пока не удалось включить и считать телеметрию не могли понять в чём дело и что делать. Поначалу давали команды на перезагрузку БЦВМ и только усугубляли ситуацию.

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

Для того чтобы получить телеметрию надо её не только передать но и принять. Как вы таким способом обеспечите включение передатчика в зоне приёмной станции где аппарат находится ажно 7 минут в сутки?

 

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

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

[Штуцер]

Понятно. Наверное у меня просто не совсем верное суждение о работе орбитальных СТИ. На основе работы СТИ РН, у которых передатчик ТМИ врубается еще задолго до КП, гонит весь поток и работает до упора, до отделения орбитального блока

Ну правильно, РН живет 10 минут, параметров измеряемых СТИ меньше, чем у КА, но они в основном быстропеременные. Массив информации гонится практически в реальном времени. У КА тоже так бывает, но не всегда.

[Запойлов]

Предполагаю, что сигнал на включение МДУ прошёл, но она не включилась. Следовательно, сейчас станция по логике думает, что летит с опорной орбиты (поддерживает ориентацию). ТМИ пишется, когда память переполнится предположительно должен быть сброс информации. Можно ли прикинуть когда произойдёт момент переполнения памяти. И каковы могут быть дальнейшие последствия?

Не знаю какая логику управления но  по идее на ФГ датчик ускорения какой-нибудь должен быть

Интересно а ионные датчики как на Салюте-3 нельзя использовать для ориентации аппарата по вектору скорости ?

[Not]

1. Тестирование ПО в ПРИНЦИПЕ неспособно гарантировать его корректность просто из-за астрономического количества возможных вариантов его исполнения. Конечно же, это не означает, что от тестирования надо отказываться.

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

3. Метод, который использовал Хольцманн - так называемая проверка моделей программ или model checking - страдает серьезнейшим указанным недостатком - сначала строится МОДЕЛЬ программы, а затем она проверяется. Кстати, фактически методом "прогона" скорее, а не логическим, но это уже детали. Самая же главная проблема - в гарантии АДЕКВАТНОСТИ этой построенной модели самой программе.
Кроме того - сформулировать проверяемые свойства не столь просто, и проверяются только НЕКОТОРЫЕ свойства системы.

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

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

Это возможно только при условии контролируемого пространства состояний, достигаемого применением жестко лимитированных языков программирования. Языки типа С/С++ с их гибкостью такой возможности не предоставляют, к сожалению.

А еще лучше - удалось бы построить методы, позволяющие АВТОМАТИЧЕСКИ строить гарантированно правильную программу, на 100% соответствующую спецификации.

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

[ОАЯ]

Вопрос:
Предположим каким-то чудом сейчас прошел запуск МД и аппарат ушел с опорной орбиты. Просто ушел. По какому датчику БЦВМ узнает, что теперь нужно включить приемник,  который может принять команду на выход из safe mode? Или он будет продолжать думать, что он на опорной орбите?

[Dude]

Не знаю :roll: , но некоторые бы не отказались от поездки с правом вето в Хантсвилл. :twisted:

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

Да, насавские отставники, как патриоты, скорее мечтают намылить шею своим родным палкостроителям.

[Старый]

Вопрос:
Предположим каким-то чудом сейчас прошел запуск МД и аппарат ушел с опорной орбиты. Просто ушел. По какому датчику БЦВМ узнает, что теперь нужно включить приемник,  который может принять команду на выход из safe mode? Или он будет продолжать думать, что он на переходной орбите?

Ни по какому. Из сейф-мода аппарат сам не выходит.

[Santey]

К вопросу о возможности передачи ТМИ в защищенном режиме. Вот что сообщается насчет вываливания MRO в этот режим в 2009:

Safe mode is a way of running the spacecraft where all of the science instruments are turned off and quiet. We still receive engineering telemetry so we can monitor temperatures and voltages. There are also "survival" heaters that prevent HiRISE from getting too cold in this mode.

Т.е. в случае с MRO, передача ТМИ в защищенном режиме велась

[Santey]

ссылку указать забыл: http://hirise.lpl.arizona.edu/HiBlog/2009/12/17/returning-to-normal/#more-647

[ОАЯ]

Вопрос:
Предположим каким-то чудом сейчас прошел запуск МД и аппарат ушел с опорной орбиты. Просто ушел. По какому датчику БЦВМ узнает, что теперь нужно включить приемник,  который может принять команду на выход из safe mode? Или он будет продолжать думать, что он на переходной орбите?

Ни по какому. Из сейф-мода аппарат сам не выходит.

Но БЦВМ же на опорной орбите сама отключила приемник. А на переходной должна включить. По какому параметру?

[Make_Pic]

Больше, не в этом суть.
см. http://www.155la3.ru/k1890.htm

1890ВМ2Т посерьезней камушек, но где то слышал, что он глючный.
И вроде как в ЦВМ-30 эта архитектура

[Старый]

К вопросу о возможности передачи ТМИ в защищенном режиме. Вот что сообщается насчет вываливания MRO в этот режим в 2009:

Safe mode is a way of running the spacecraft where all of the science instruments are turned off and quiet. We still receive engineering telemetry so we can monitor temperatures and voltages. There are also "survival" heaters that prevent HiRISE from getting too cold in this mode.

Т.е. в случае с MRO, передача ТМИ в защищенном режиме велась

Где здесь написано что непрерывно и без команды?

[Запойлов]

Вопрос:
Предположим каким-то чудом сейчас прошел запуск МД и аппарат ушел с опорной орбиты. Просто ушел. По какому датчику БЦВМ узнает, что теперь нужно включить приемник,  который может принять команду на выход из safe mode? Или он будет продолжать думать, что он на переходной орбите?

Ни по какому. Из сейф-мода аппарат сам не выходит.

А не предусмотрена автоматическая перезагрузка БЦВМ в том случае если время нахождения в безопасном режиме слишком затянулось ?

[Старый]

Но БЦВМ же на опорной орбите сама отключила приемник. А на переходной должна включить. По какому параметру?

С чего вы решили что в безопасном режиме приёмник выключен?

[Make_Pic]

ЦВМ-22, гуглите по ЦВМ-20

К стати в описании ЦВМ-20 сказано :
Программирование выполняется на языках программирования ""С" и Ассемблер.

А на чем еще старый добрый PC AT? - На Borland C!!! И без плюсов.