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

[zyxman]

Циклограмма по определению - точное расписание комманд. От этого и плясал

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

Блок управления двигателем должен иметь свой контроллер который имеет собственные часы реального времени периодически подстраиваемые с бортовыми часами. Борт просто должен указать блоку управления двигателем в какой момент времени его запустить и через сколько остановить. Отдельный контроллер с детской памятью (меньше 4кБ) и смешной тактовой (8МГц) сможет отработать циклограмму с микросекундной точностью.
 :!:

Было уже такое в истории больших компьютеров.
Собственно, PIC, который потом стал выпускать Микрочип, вначале был универсальным сопроцессором ввода/вывода в мейнфрейме.
Правда цель была чуть другая - разгрузить центральный процессор от выполнения задач управления периферией, но фактически это направление постепенно привело к интеллектуальным периферийным устройствам, таким как например контроллер жесткого диска, который по сути работает в риалтайме по жесткой циклограмме, но с ЦП общается абстракциями - командами примитивизированными почти до уровня ОЗУ ("считать блок информации по адресу"; "записать блок информации по адресу").

Только одно отличие, что в гражданских компьютерах в результате развития периферийных сопроцессоров вместо УНИВЕРСАЛЬНЫХ периферийных процессоров появилось множество СПЕЦИАЛИЗИРОВАННЫХ периферийных процессоров, жестко заточенных на какие-то задачи и без возможности перепрограммирования.

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

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

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

Точно!

[belov2018]

Artemkad писал(а):

Блок управления двигателем должен иметь свой контроллер который имеет собственные часы реального времени периодически подстраиваемые с бортовыми часами. Борт просто должен указать блоку управления двигателем в какой момент времени его запустить и через сколько остановить. Отдельный контроллер с детской памятью (меньше 4кБ) и смешной тактовой (8МГц) сможет отработать циклограмму с микросекундной точностью.

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

[zyxman]

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

Можно действительно встроить в БВК универсальный периферийный контроллер.

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

[Aleks1961]

Смотря для каких режимов - например время выдачи ВКИ и время выдачи команды ДМТ в ПСО и ИНО для ФГ имеют наверно разный приоритет и важность.

И что? Система должна быть настроена на поддержку самого "жесткого" из возможных режимов.

Не обязательно, но "жесткий", например, считать в режиме "двойной точности"

[bs]

Не может быть! Вы нашли "серебряную пулю"! Немедленно поделитесь!

Так, спокойствие! Ничего я не нашел

Я просто окинул взором прогресс в области разработки ПО за последние 20 лет, не говоря уже о том, что точка отсчета в предыдущем моем сообщении уходила намного глубже в колодец времени.

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

Заметьте, что я упомянул лишь технологические новшества. А ведь соотвественно адаптировались и методы разработки, да и новых появилось не мало.

Так что "серебряная пуля" не при чем.

Просто это определяется путем баллистических расчетов - сколько должен отработать двигатель. Летит оно...

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

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

Циклограмма по определению - точное расписание комманд. От этого и плясал

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

Блок управления двигателем должен иметь свой контроллер который имеет собственные часы реального времени периодически подстраиваемые с бортовыми часами. Борт просто должен указать блоку управления двигателем в какой момент времени его запустить и через сколько остановить. Отдельный контроллер с детской памятью (меньше 4кБ) и смешной тактовой (8МГц) сможет отработать циклограмму с микросекундной точностью.
 :!:
ЗЫ. Кстати, при этом борт может закладывать циклограмму блоку управления двигателем абсолютно асинхронно.

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

[Not]

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

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

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

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

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

Это ничего не меняет. В вашей версии БВК также обязан работать в рилтайме.

[Not]

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

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

Это ничего не меняет. В вашей версии БВК также обязан работать в рилтайме.

Да на здоровье. Выдал команды в буфер контроллера UART и пошел себе дальше. А уже контроллер UART отвечает за их передачу. Латентность безусловно будет, но если, напримет, 10 миллисекунд нас устроит - пусть себе будет.

[zyxman]

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

А вы не могли-бы указать примерные требования по задержкам по каждой из приведенных управляемых систем?
- Сколько допустимая задержка выключения по дельта-V, сколько по аварийной ориентации, сколько руления маршевым двигателем, сколько за уровнем топлива?

И второй вопрос: насколько там сложные вычисления?

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

PS Я понимаю что тут многие не всё могут сказать. Поэтому я попробую сообразить примеры сам, но всё-же подсказки не помешают.

[Not]

(напомню, что у чисто функциональных языков вообще нет никаких сторонних эффектов - всё происходящее определяют только входные параметры)

Когда ваша функциональная программа управляет сфероконем в вакууме - да. А в реальности есть шина и другие общие ресурсы. В этот момент заканчивается красивая функциональная модешь и начинаются некрасивые сторонние эффекты  

[bs]

Когда ваша функциональная программа управляет сфероконем в вакууме - да. А в реальности есть шина и другие общие ресурсы. В этот момент заканчивается красивая функциональная модешь и начинаются некрасивые сторонние эффекты  

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

[Feol]

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

А вы не могли-бы указать примерные требования по задержкам по каждой из приведенных управляемых систем?
- Сколько допустимая задержка выключения по дельта-V, сколько по аварийной ориентации, сколько руления маршевым двигателем, сколько за уровнем топлива?

И второй вопрос: насколько там сложные вычисления?

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

PS Я понимаю что тут многие не всё могут сказать. Поэтому я попробую сообразить примеры сам, но всё-же подсказки не помешают.

В системе ориентации, по современным масштабам вычислительной техники, ни насколько не сложные вычисления. Машина в 400 Кгц (Салют-4) вполне успешно справлялась (Сесат, например) и справлялась бы на новых КА. 10 - 20 Мгц (причем, среди них и импортная 16-ти разрядная!) прекрасно справляются сейчас. Причём, ПО системы ориентации по вычислениям - самое сложное после баллистики . Но там время совсем уж некритично. Помниться, при первом же запуске нашего ПО системы ориентации на Салют-32 сразу нашли аппаратный косяк с плавающей точной. Раньше этого никто просто не использовал. А разработчики не тестировали, как обычно в отрасли, нах*й никому ничего не надо. Когда проблема появится, тогда и будем её решать.. В сущности, ПО системы ориентации сейчас - это простой контроллер и любой программист с практическим опытом работы, например, на Си/Си++, который на хорошем счету в любой современный конторе, сделает за предоставляемые сроки эту задачу предоставляемыми средствами в совершенно безупречном виде по сравнению с тем, как оно делается и в каком виде выходит в лёт сейчас. А вот обратное совершенно невернО. Нужны в этой области и специальные знания, конечно, но это не относится к программированию, да и можно работать в тандеме. Все имеющиеся проблемы, которые я видел на практике, надуманы, обусловлены технологией разработки 50-ых годов и социальными факторами. Сказанное относится только к бортовому ПО системы ориентации и только к тем КА, к которым имел отношение. Про иное не знаю. Любопытно еще, что мощность вычислителя, например, одного известного мне звездного датчика (не БОКЗ), как минимум, в 4-8 раз больше мощности всего бортового компьютера

[PIN]

Пример из реальной жизни. КА, с очень высокой централизацией, почти все вычислительные задаци на процессоре БЦВМ, некоторые телеметрические параметры собираются на 100 герцах, общее их количество - порядка 10 тысяч.

При этом наихудшая загрузка 20-мегагерцового ERC32 - 44%
Типичная - менее 20%

[bs]

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

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

Любопытно еще, что мощность вычислителя, например, одного известного мне звездного датчика (не БОКЗ), как минимум, в 4-8 раз больше мощности всего бортового компьютера

Хм. А за счет чего? И как с надежностью?

[Feol]

Хм. А за счет чего? И как с надежностью?

За счет этого (кажется, к железу прямого отношения не имею): http://www.module.ru/ruproducts/proc/nm6403.shtml. 2 штуки в вычислителе, не резерв, задействованы обе.

Как с надёжностью? Поживём - увидим.. Переживём - учтём

[Feol]

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

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

Совершенно верно.

[bs]

2 штуки в вычислителе, не резерв, задействованы обе.

Как с надёжностью? Поживём - увидим.. Переживём - учтём

Характеристики не плохие, но как же рад. стойкость и все такое?

[Feol]

2 штуки в вычислителе, не резерв, задействованы обе.

Как с надёжностью? Поживём - увидим.. Переживём - учтём

Характеристики не плохие, но как же рад. стойкость и все такое?

Не знаю. Занимаюсь только реализацией мат. модели (не автор модели!) оптики прибора, алгоритмов и ПЗС.

[TAU]

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

Похоже, что технологии разработки в  других отраслях ушли далеко вперед

Совершенно верно.

Позволю себе высказать следующее замечание.

У каждой методологии есть своя область применения. Не стоит пытаться перевозить пассажиров на БелАЗах.

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

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

Еще что хочу сказать. Безусловно, последствия реформ для отрасли стали весьма тяжелыми.
Но не следует считать, что все аюсолютно беспросветно, на разных предприятиях ситуация своя.
Мне кажется, что и графическое программирование языков ГРАФИТ-ФЛОКС ( http://store.oberoncore.ru/lib/image/drakon/list2.png ), и декларативное ПРОЛ2 ( http://mywebs.su/blog/soft/4346.html ), и  бортовые интерпретаторы ДКД и СЕАНС - "бортовые экспертные системы реального времени" ( http://www.laspace.ru/rus/cmi04_10.pdf ) являются в определенном смысле "передовыми" решениями, "ушедшими далеко вперед".

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