Особенности программирования БВК АМС

[avp]

Не пора ли прошивку научных КА переводить на open source ?

[belov2018]

Правильно! Пора! Поставить на БВК ФГ ОС Linux с ядром в 2 МБ. Там как раз столько оперативной памяти.

[bs]

Если мы посмотрим за рубеж - увидим, что и у них космические предприятия используют проблемно-ориентированные языки (HAL/S), графическое программирование (Grafcet http://www.cours.polymtl.ca/ele4202/PDF/grafcetIEEE.pdf ) и формальную верификацию программ (Spin http://spinroot.com/gerard/pdf/gluck_holz.pdf )- что относится, безусловно, к "передовым методологиям".

Про FEAVER для SPIN интересный доумент, надо будет покурить его в менее спешной манере.

В остальном сказать сложно. Что конкретно из себя представлял ПРОЛ2 и ФЛОКС, пока разобраться не смог. Информации не густо.

[bs]

Правильно! Пора! Поставить на БВК ФГ ОС Linux с ядром в 2 МБ. Там как раз столько оперативной памяти.

Ну шутки шутками, а идея, на мой взгляд, не лишенная смысла.

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

[Artemkad]

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

Затраты энергии на подобный блок - 100мкА без ухищрений. Хотя я бы смог вписать и в 10мкА. Что касается резервирования... Тогда уж и двигатель надо обязательно резервировать! Уж он-то вряд-ли более надежен чем эта электроника.

[zyxman]

Правильно! Пора! Поставить на БВК ФГ ОС Linux с ядром в 2 МБ. Там как раз столько оперативной памяти.

"Это неправильные пчелы и у них неправильный мёд" (с)

Во первых, в 2Мб вполне втискиваются не только ядра open source ОС, а и достаточно полноценные системы - во всяких разных домашних роутерах и WiFi точках доступа обычно как раз столько ресурсов, и чаще всего применяется как раз MIPS (я имею в виду не старые компьютеры а маленькие коробочки, массово производимые в Азии).
Во вторых, кроме Linux есть еще несколько веток BSD (FreeBSD - самая распространенная, NetBSD - поддерживает больше всех архитектур), которые намного лучше Linux по качеству кода и по продуманности системы; а также есть микроядерная ОС Minix.

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

[Artemkad]

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

С акселерометров дельта-V точно получить сложно т.к. выдают они ускорение которое надо еще интегрировать. Естественно любая ошибка датчика при интегрировании будет накапливаться. Но и тут никаких проблем быть не должно. Борт вполне может до отсечки давать блоку управления двигателем ожидаемую поправку времени отключения. Т.е. по текущим показателям датчиков и требуемому импульсу бортом ведется расчет требуемого момента отсечки. Плюс именно коррекции(в дополнении к заложенной циклограмме) - даже если в критический момент времени борт накроется медным тазом(будет занят чем-то еще) двигатели отработают по последним корректным данным.
Касаемо потери ориентации... А что мешает его таки аварийно отключить? Этот момент полностью асинхронный и не суть важно при аварии на сколько он опоздает. Более того, имея классический способ обмена а-ля CAN-шина все двигатели могут начать отработку аварийной циклограммы одновременно.

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

Не надо. Современный контроллер эти две задачи способен делать одновременно - и стробы и прием ведется параллельно достаточно простой периферией без участия ядра контроллера. Ядро работает по событиям прерываний уже пришедших символов или корректирует величину в компараторе таймера.
ЗЫ. Кстати тут ИМХО больше подходит не UART, а CAN. http://ru.wikipedia.org/wiki/Controller_Area_Network

[Вадим Семенов]

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

С акселерометров дельта-V точно получить сложно т.к. выдают они ускорение которое надо еще интегрировать. Естественно любая ошибка датчика при интегрировании будет накапливаться. Но и тут никаких проблем быть не должно. Борт вполне может до отсечки давать блоку управления двигателем ожидаемую поправку времени отключения. Т.е. по текущим показателям датчиков и требуемому импульсу бортом ведется расчет требуемого момента отсечки. Плюс именно коррекции(в дополнении к заложенной циклограмме) - даже если в критический момент времени борт накроется медным тазом(будет занят чем-то еще) двигатели отработают по последним корректным данным.
Касаемо потери ориентации... А что мешает его таки аварийно отключить? Этот момент полностью асинхронный и не суть важно при аварии на сколько он опоздает. Более того, имея классический способ обмена а-ля CAN-шина все двигатели могут начать отработку аварийной циклограммы одновременно.

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

[Вадим Семенов]

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

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

[bs]

С динамической памятью есть еще одна засада: При статическом распределении памяти значение любой переменной при необходимости можно поменять в полете простой командой с земли - "записать по такому-то адресу такое-то значение".

Интересный и серьезный аргумент. Но думаю при желании можно реализовать достаточно простой механизм и в динамике. На вскидку - состояние системы сериализуется. На выходе компактная последовательность параметров, структура которой известна. Удобно для получения диагностического дампа, а также для коррекции произвольной переменной состояния системы путем: сериализации состояния на борту, внесения изменения в последовательность по относительному адресу, десериализации с обновлением состояния измененными данными.

[Вадим Семенов]

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

[PIN]

Не пора ли прошивку научных КА переводить на open source ?

RTEMS используется в БЦВК уже нескольких летающих аппаратов

[Artemkad]

Это тем не менее не снимает необходимости для центрального компьютера работать в реальном масштабе времени чтобы постоянно корректировать таймер.

Зачем? Все основные вычисления делаются еще до запуска двигателя. После - только коррекция. По большому счету борт может вообще после запуска ничего не считать и аппарат тем не менее с некоторой точностью будет на траектории. Расчеты после запуска это желательно, но не обязательно (изначально в космонавтике траекторные расчеты аппаратов производились на земле). Это-же и относится к двигателям ориентации - компенсирующий возмущение импульс (по сути - время включения двигателя) может быть вычислен еще до запуска двигателя.
Все коррекции работы двигателей нужны только как результат изменений параметров работы двигателей и параметров аппарата (к примеру массы). Но это не реалтаймовые величины.

[Cyberax]

Правильно! Пора! Поставить на БВК ФГ ОС Linux с ядром в 2 МБ. Там как раз столько оперативной памяти.

А почему так мало? Могли бы и побольше воткнуть, чай память нынче недорогая - даже космического исполнения защищённая от радиации.

Но в 2Мб вполне войдёт vxWorks, который использует NASA и который доступен коммерчески (с исходниками). Не хочется vxWorks - есть QNX, который делают канадцы и который стоит внутри бортовых компьютеров многих автомобилей. Обе жёстко-realtime'овые с очень хорошими показателями латентности.

Вот тут список клиентов vxWorks: http://www.windriver.com/customers/customer-success/aerospace-defense/

Не нравятся оба варианта? Есть L4 Microkernel - это ядро с формально математически доказаной корректностью поведения.

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

[zyxman]

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

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

Суть в том, что с системой с более высоким уровнем абстракции ВСЯ работа ведется не с машинными словами а с более высокоуровневыми сущностями - с ячейками СУБД, с сообщениями, с скомпилированными модулями.

[Unispace]

Правильно! Пора! Поставить на БВК ФГ ОС Linux с ядром в 2 МБ. Там как раз столько оперативной памяти.

А почему так мало? Могли бы и побольше воткнуть, чай память нынче недорогая - даже космического исполнения защищённая от радиации.

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

[Unispace]

Правильно! Пора! Поставить на БВК ФГ ОС Linux с ядром в 2 МБ. Там как раз столько оперативной памяти.

А почему так мало? Могли бы и побольше воткнуть, чай память нынче недорогая - даже космического исполнения защищённая от радиации.

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

Про ассемблер. Все как в этом мире. Чтобы чему-то научиться, нужно начинать с азов, с основ. Человек, начинавший программировать на асме, всегда будет программировать намного тщательнее, умнее и оптимальнее на любом языке, чем младой кодировщик, разговаривающий на языке очень высокого уровня  Я лучше взял бы человека лет 40, начинавшего на МК-61, чем 25летнего, не видевшего ничего глубже окошек VC  

[zyxman]

Чтобы чему-то научиться, нужно начинать с азов, с основ.

Правильно, основа всего математика.

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

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

[Unispace]

Не согласен. Тут как раз нередко "специалист подобен флюсу" - слишком сильная ориентация на ассемблер приводит к однобокости - ибо человеческий мозг ограничен и за деревьями человек перестает видеть лес..

Да какой специалист и однобокость. Я про другое говорю. Учиться надо на основах, а не обязательно работать на них дальше. Кто знает основы, тот и все остальное освоит без проблем. Почему это нас учили сначала в машинных кодах программировать, когда уже были и языки высокого уровня ? Потому что так нужно. А потом и до высоких дело дошло. Еще такое дело. Если человек витает в окошках и ничего не знает о том, как на самом деле все происходит, он свою же программу или подобную не сможет даже в дебаге низкоуровневом изучать. Например, при реверсе из соседнего источника, поиске проблем. Нет листинга - и привет. Пусть это разделение труда, но не всегда оно возможно. Много пены нынче, нахватаются, книжечку прочитают - уже программисты Вот до чего довела всеобщая компьютеризация  

[zyxman]

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

А как насчет увеличения сложности миссий?

- Я тут упоминал задачу коммутатор АТС на несколько миллионов абонентов.
Сложность в том, что в отличие от НЫНЕШНИХ АМС коммутатор должен не просто включиться и постепенно подключать к себе абонентов с нуля, а должен как можно быстрее перебрать на себя старых абонентов с других систем, которые строились постепенно десятилетиями.

То есть там наверное уже нет чисто аналоговых АТС, но есть несколько поколений цифровых, работающие на собственных стандартах.
И соответственно, есть ОГРОМНЫЙ зоопарк самого разнообразного оборудования, которого настолько много что быстро его заменить невозможно чисто физически. Точнее, старое оборудование постепенно заменяется по мере выработки ресурса, но система должна работать непрерывно и при этом риалтаймово.

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