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

[zyxman]

На каждый таймер собаки найдется цикл, который будет его сбрасывать :wink:

Поэтому по всей видимости нужна иерархическая система контроля.
Уж извините, но сами знаете где и на эту проблему обратили внимание и сделали механизм задач-супервизоров: есть задачи-работники, которые выполняют работу, и есть задачи-супервизоры, которые выполняют какую-то логику обработки сбоев задач-работников.
Как тут уже отмечалось, принципиально отвергается хранение внутри кода состояний (для хранения состояний есть СУБД), и также важное правило что при всех не заложенных в ТЗ ситуациях просто идем на исключение, а дальше обрабатывает соответствующий супервизор (система иерархическая, то есть супервизор сам может быть воркером для другого, вышестоящего супервизора). Плюс в той самой библиотеке OTP заложены два момента:
1. заложено понимание и обработка того, что какие-то воркеры должны запускаться в строго определенной последовательности.
2. сама библиотека имеет встроенный механизм подсчета частоты исключений, что при слишком большом количестве исключений в единицу времени отключается механизм автоматического перезапуска и переходит на обработку особой ситуации. Соответственно, если обработчик на этом уровне не предусмотрен то идем по исключению на уровень выше и так хоть до самого верхнего уровня.

PS Насчет Erlang и ООП: одна из первых реализаций ООП в Smalltalk как раз была реализована через передачу сообщений, без разделяемой памяти.

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

Зато количество выделяемых на стеке данных не фиксировано. Улавливаете?

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

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

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

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

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

0 любое, и любое другое число тоже любое. Вот такая в С++ жеская типизация. Я ж говорю, языки "общего назначения" оставляют желать лучшего. А С++ и подавно.

Абсурд! Произвольное число (кроме 0, и то уже в С++0x есть nullptr) без явного приведения к указателю в С++ невозможно. Похоже, что про С++ вы знаете лишь по наслышке.

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

Сомнительно что это так, объяснять почему лень. И вообще я бы предпочел не домыслы, а ссылку на реальную информацию.

История появления бортовых ЭВМ ряда "АРГОН"

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

Еще советую книгу "БСУ КА" МОКБ "Марс".

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

[bs]

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

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

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

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

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

Ну уж нет, не съезжайте. Этот разговор был в контексте преобразования типов. А индексация указателя и преобразование произвольного числа в указатель - это две разные вещи.

Спасибо за ссылку, тем более что она опровергает то что вы ранее писали Wink Никакой троированной логики на кристалле там нет, есть 3 независимых канала с одинарной логикой. Но вообще интересно.

Пожалуйста. Ну я дал первое, что попалось по этой тематике. Троирование на низком уровне реально применялось. В частности такое решение использовалось в ЦВМ БИУС НК, но это военная аппаратура с другими критерями (те, которые я изучал и про кристаллы родом не слышали ). Я по доброте душевной экстраполировал и на космическую аппаратуру. Но видимо в Аргоне решили, что троирования по шине будет достаточно. Судя по результатам, не ошиблись.

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

Попробуйте здесь.

[eng. Alex]

Сорок лет прошло, а темы не меняются.  :roll:

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

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

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

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

Уж скорее он спрогнозирует переполнение стека (при условии, что нет рекурсии), т.к. размеры передаваемых данных и вложенность вызовов известны на этапе компиляции.

И это тоже. Отсутсвие рекурсии вполне проверяется при компиляции. На таких условиях можно даже стек разрешить  

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

Да хватит уже мечтать Компилятор не может анализировать семантику.

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

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

Ну уж нет, не съезжайте. Этот разговор был в контексте преобразования типов. А индексация указателя и преобразование произвольного числа в указатель - это две разные вещи.

Вы сами выдумываете некие утверждения (приписывая их мне почему-то) и сами же опровергаете. Извините, ваши утверждения я отстаивать не буду  

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

Попробуйте здесь.

Спасибо.

[TAU]

не надо забывать как давно это было и относительно какого уровня (доисторического) производительности была успешна решена задача!

Производительность - имелась в виду производительность труда программистов. Она за эти годы чудесным образом не возрастала.

[TAU]

Попробуйте здесь.

bs, спасибо большое!

Как жаль, что они ничего практически про ПО не написали в этой ценнейшей книге.  :cry:

[TAU]

Подкиньте указатель на эти монументальные труды - с удовольствием ознакомлюсь

К сожалению, пока в электронном виде "монументальных трудов" не нашел.
Но, может, эта ссылка поможет начать?

http://blogerator.ru/page/oop_why-objects-have-failed

В частности, приводится мнение вроде не последних людей в мире программирования - Ричарда Столлмэна, Александра Степанова, Никлауса Вирта.
В бумажном виде читал мнение Святослава Лаврова - человека, кстати, одновременно "своего" и для космической отрасли, и для программирования.

Вот небезынтересное исследование:
http://www.csm.ornl.gov/~v8q/Homepage/Papers%20Old/spetep-%20printable.pdf

[Wishbone]

Для интересующихся теорией и практикой
http://sunnyday.mit.edu/ :twisted:

[TAU]

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

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

[Aleks1961]

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

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

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

[Artemkad]

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

Что такое система с миллиардами возможных вариантов состояний и "менеджер виртуальной памяти"? Ни в какое сравнение. Вылизать последний реально и не сложно.

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

ЗЫ. А вообще - таймер горячей  собаки великолепно решает эту проблему...

На каждый таймер собаки найдется цикл, который будет его сбрасывать :wink:

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

[Artemkad]

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

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

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

[bs]

Производительность - имелась в виду производительность труда программистов. Она за эти годы чудесным образом не возрастала.

Ну тут я склонен не согласиться, ибо учитываю не только космическую отрасль.

bs, спасибо большое!

Как жаль, что они ничего практически про ПО не написали в этой ценнейшей книге.

Не за что. Увы про ПО там действительно мало, и это о чем-то говорит.

К сожалению, пока в электронном виде "монументальных трудов" не нашел.
Но, может, эта ссылка поможет начать?

Спасибо! На монументальные труды можно сослаться и в бумажном варианте.

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

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

[TAU]

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

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

[TAU]

Производительность - имелась в виду производительность труда программистов. Она за эти годы чудесным образом не возрастала.

Ну тут я склонен не согласиться, ибо учитываю не только космическую отрасль

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

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

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

[Artemkad]

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

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

[Дем]

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

ИМХО, тут не надо путать...
Время включения - рассчитывается заранее и вполне может быть рассчитано на основе показаний датчиков. Коррекция как правило проводится определённой точке орбиты (например в апогее) - и надо просто вычислить когда она. И соотвествующе установить таймер включения.
А вот время работы - вполне можно и слегка менять прямо в процессе, учитывая показания акселерометров.

[belov2018]

Поддерживаю TAU: Не может быть! Вы нашли "серебряную пулю"! Немедленно поделитесь!
Еще раз советую Всем прочитать bruks_frederik_mificheskii_chelovekomesyac_ili_kak_sozdayutsya_programmnye_sistemy.
Это должна быть настольная книга разработчиков больших систем. Актуальность книги - история разработки программного обеспечения фирмой IBM. Уже больше 25-лет ее перечитываю перед началом сложных проектов или в запутанных ситуациях при разработке.
И еще раз по поводу Циклограмм
Проект 1992 года - несостоявшийся Алмаз-2

Класс задач контроля и управления бортовой аппаратурой КА:
1.1. Контроль и управление аппаратурой БРТК-АС,
1.2. Контроль и управление аппаратурой БРТК-МС,
1.3. Контроль и управление аппаратурой БРТК-МК,
1.4. Контроль и управление аппаратурой БК,
1.5. Контроль и управление аппаратурой БКЖ (служебные системы),
1.6. Контроль и управление комплексами КА и формирование и выдача на НКУ информации телесигнализации КА,
1.7. Прием от НКУ и исполнение КПИ,
1.8. Управление коррекцией положения КА,
1.9. Ведение бортовой шкалы времени (БШВ) и привязка БШВ к БШВ соседних КА и СЕВ НКУ.

Класс задач управления функционированием КА, как узла сети связи системы "МАКСИМУМ":
2.1. Управление доступом абонентов в служебный канал,
2.2. Контроль качества каналов связи,
2.3. Поддержание соединений абонентов с КА (переключение между подзонами),
2.4. Управление функционированием связной аппаратуры БРТК-АС,
2.5. Контроль качества каналов связи, поддержание соединений
абонентов и управление функционированием связной аппаратуры БРТК-МС,
2.6. Управление доступом ШС в радиоканал,
2.7. Контроль качества каналов связи,
2.8. Поддержание соединений с ШС,
2.9. Обеспечение связи с НКУ по радиоканалу БРТК-МК,
2.10. Обеспечение связи с РЦО по радиоканалу БРТК-МК,
2.11. Функциональная задача управления коммутацией в БК,
2.12. Установление соединений абонентов сети,
2.13. Поддержание соединений абонентов сети,
2.14. Обеспечение функционирования КА в качестве абонента служебной сети связи.

Класс задач балистико-навигационного обеспечения:
3.1. Определение местоположения АС,
3.2. Определение дальности до соседних КА,
3.3. Определение радиальных скоростей относительно соседних КА,
3.4. Определение дальности до ШС-реперов,
3.5. Определение радиальных скоростей относительно ШС-реперов,
3.6. Определение текущей ориентации КА,
3.7. Определение текущего положения КА,
3.8. Расчет параметров движения КА,
3.9. Прогнозирование сеансов ВТИ по ШС-реперам, интервалов отсутствия связи в радиоканалах БРТК-МС и интервалов разгрузки маховиков СОС,
3.10. Расчет целеуказаний для антенн БРТК-МС,
3.11. Формирование эфемеридной информации для АС.

Распределение такого объема задач по циклограмме наверно плохо поддается автоматизации.

[belov2018]

И весь этот комплекс задач предполагалось решать на аппаратуре, аналогичной сегодняшнему БВК ФГ.