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

Artemkad · 22.11.2011 21:31:00

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

Осталась мелочь - как проверить проверяющего?

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

Может не стоит так извращаться из-за желание запихнуть весь софт в один процессор. Обычно подобное складывание всех яиц хорошо не заканчивается. :twisted: Вместо того, что-бы для выполнения одной задачи делать отдельный поток в (RT)ОС разумнее для этой задачи сделать отдельный контроллер под размер задачи (естественно с отдельной программой). Физическая разделение памяти до сих пор наиболее эффективный способ ее защиты

. Как бонус к этому - каждая задача будет меньше, понятнее и портабельнее.

zeaman · 22.11.2011 22:30:51

Цитировать
ЦитироватьИмел в виду, что soft real time приводит к дискретному управлению с периодически падающей (существенно) частотой дискретизации. Как будет анализировать устойчивость?
В зависимости от критичности процесса к быстроте реакции на воздействие или выдачи управляющего воздействия, необходимой точностью выполнения - по приоритетам. Например - точность направления ВКИ и точность удержания направления на Солнце в ПСО. Первая задача решается каждый цикл, вторая - каждый сотый (абстрактно). Точность соответственно пропорциональна.

Просто напрашивается разделение алгоритмов по одному/(связанной группе) на отделъный CPU. (Всего лишь мое мнение, этот метод частично использовался при разработке авионики).

Кроме того, отработанные алгоритмы можно "запечатать" и забыть..
Короче, иерархический дизайн.

Aleks1961 · 22.11.2011 22:39:32

Цитировать
Цитировать
ЦитироватьИмел в виду, что soft real time приводит к дискретному управлению с периодически падающей (существенно) частотой дискретизации. Как будет анализировать устойчивость?
В зависимости от критичности процесса к быстроте реакции на воздействие или выдачи управляющего воздействия, необходимой точностью выполнения - по приоритетам. Например - точность направления ВКИ и точность удержания направления на Солнце в ПСО. Первая задача решается каждый цикл, вторая - каждый сотый (абстрактно). Точность соответственно пропорциональна.

Просто напрашивается разделение алгоритмов по одному/(связанной группе) на отделъный CPU. (Всего лишь мое мнение, этот метод частично использовался при разработке авионики).

Кроме того, отработанные алгоритмы можно "запечатать" и забыть..
Короче, иерархический дизайн.

ОПЫТ КОНСТРУКТОРА, НАПРАВЛЕНИЕ ПРОЕКТА И ВЫБОР МАТЧАСТИ ДЛЯ РЕАЛИЗАЦИИ, ПОТОМ СПО.

belov2018 · 22.11.2011 23:26:20

Цитировать
Цитировать
ЦитироватьИмел в виду, что soft real time приводит к дискретному управлению с периодически падающей (существенно) частотой дискретизации. Как будет анализировать устойчивость?
В зависимости от критичности процесса к быстроте реакции на воздействие или выдачи управляющего воздействия, необходимой точностью выполнения - по приоритетам. Например - точность направления ВКИ и точность удержания направления на Солнце в ПСО. Первая задача решается каждый цикл, вторая - каждый сотый (абстрактно). Точность соответственно пропорциональна.

Просто напрашивается разделение алгоритмов по одному/(связанной группе) на отделъный CPU. (Всего лишь мое мнение, этот метод частично использовался при разработке авионики).

Кроме того, отработанные алгоритмы можно "запечатать" и забыть..
Короче, иерархический дизайн.

Таким методом и строили КБО самолетов раньше: МИГ-29, СУ-27.
Там было до 20 вычислителей. И без резервирования: на дублирование уже не было места.
Впечатляет?

Aleks1961 · 22.11.2011 23:35:49

Цитировать
Цитировать
Цитировать
ЦитироватьИмел в виду, что soft real time приводит к дискретному управлению с периодически падающей (существенно) частотой дискретизации. Как будет анализировать устойчивость?
В зависимости от критичности процесса к быстроте реакции на воздействие или выдачи управляющего воздействия, необходимой точностью выполнения - по приоритетам. Например - точность направления ВКИ и точность удержания направления на Солнце в ПСО. Первая задача решается каждый цикл, вторая - каждый сотый (абстрактно). Точность соответственно пропорциональна.

Просто напрашивается разделение алгоритмов по одному/(связанной группе) на отделъный CPU. (Всего лишь мое мнение, этот метод частично использовался при разработке авионики).

Кроме того, отработанные алгоритмы можно "запечатать" и забыть..
Короче, иерархический дизайн.

Таким методом и строили КБО самолетов раньше: МИГ-29, СУ-27.
Там было до 20 вычислителей. И без резервирования: на дублирование уже не было места.
Впечатляет?

п/я 1001 :lol:

bs · 22.11.2011 23:36:34

ЦитироватьТаким методом и строили КБО самолетов раньше: МИГ-29, СУ-27.
Там было до 20 вычислителей. И без резервирования: на дублирование уже не было места.
Впечатляет?

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

belov2018 · 22.11.2011 23:43:12

По такому пути продолжают идти и на Т-50. Следите за прессой до 2013 г. - Путину обещали поставить Т-50 в учебные центры.

Вадим Семенов · 23.11.2011 00:39:34

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

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

Aleks1961 · 23.11.2011 00:44:01

Цитировать
Цитировать
ЦитироватьДело не просто в надежности. Динамическая типизация - ненужный расход ресурсов. На борту они ограничены (характерны, к примеру, показатели ОЗУ 2 Мбайта).
2 Мбайта это не так уж мало, а оверхед динамической типизации по памяти не очень большой, скажем, 1 байт на примитивные типы или 1 слово на типы, определяемые пользователем. Тут больше страдает производительность из-за неявных преобразований несоответствующих типов. Но этот аспект в большей части в руках разработчика.
Больше всего страдает надежность, поскольку в результате буйного преобразования типов получается неизвестно что. Скажем преобразование вещественного в целое дробная часть отбрасывается. Возможно, в данной задаче подобная потеря точности недопустима, но компилятор/интерпретатор этого не заметит. Так же автоматическое управление памятью вносит непредсказуемые временные задержки, если куча закончилась и надо собирать мусор. А так же потенциальный отказ из-за полного исчерпания динамической памяти. Статическое распределение памяти гарантирует временные задержки и достаточность памяти при компиляции. Многозадачность вносит негарантированный доступ каждой задачи к процессору плюс возможные дедлоки в результате синхронизации задач.

Круто, но КА замкнутый объект, с конечным числом, как задач, так и параметров. Можно добиться приведения к 2-3 типам без потери точности и устойчивости объекта

bs · 23.11.2011 00:55:24

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

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

В общем думаю только практика покажет какое решение более удачно. Но для этого нужно больше практики. Я лично склоняюсь к тому, что одна ЦВМ упрощает задачу и обеспечивает большую гибкость.

Если все-таки пытаться обеспечить надежную работу системы на базе soft real time ОС, то можно попробовать рассмотреть два подхода:

1) Разделение ядра на виртуальную машину и "драйвера", имеющие более высокий приоритет, чем ВМ, и решающие отдельные задачи управления/контроля, по мере необходимости.

2) Вынос критичных задач управления в отдельные контроллеры, по возможности минимизируя их количество.

belov2018 · 23.11.2011 01:06:57

Проект 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. Формирование эфемеридной информации для АС.

Aleks1961 · 23.11.2011 01:15:14

ЦитироватьПроект 1992 года - несостоявшийся Алмаз-2

Класс задач контроля и управления бортовой аппаратурой КА:
...
3.11. Формирование эфемеридной информации для АС.

34 задач, непрерывные, периодические и циклические. Решались чуть ли не на х286 процессоре :lol:

bs · 23.11.2011 01:18:03

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

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

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

Здесь не могу ничего сказать, так как нет опыта в работе с автоматическим управлением памятью в ОС РВ. Хотя очевидно, что в этом направлении работы тоже активно ведутся: http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Real-time_garbage_collection

В общем же, ВМ не обязательно подразумевает автоматическое управление памятью. Основная задача, как мне кажется - это упростить реализацию защиты от серьезных непредвиденных ошибок за счет возможности контроллировать корректность каждой операции на уровне байт кода. Это не мешает реализовать неавтоматическое распределение памяти, если язык позволяет (например компилировать С/С++ в байт-код ВМ).

ЦитироватьМногозадачность вносит негарантированный доступ каждой задачи к процессору плюс возможные дедлоки в результате синхронизации задач.

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

bs · 23.11.2011 01:22:41

Цитировать34 задач, непрерывные, периодические и циклические. Решались чуть ли не на х286 процессоре :lol:

Ну так в 1992-м году x286 и был почти пределом совершенства

belov2018 · 23.11.2011 01:22:50

Мы НПО Маш предлагали решать их на R-3000 под VxWorks

belov2018 · 23.11.2011 01:24:41

Предполагалась совместная работа с Американцами или с Французами

Aleks1961 · 23.11.2011 01:29:06

Цитировать
Цитировать34 задач, непрерывные, периодические и циклические. Решались чуть ли не на х286 процессоре :lol:
Ну так в 1992-м году x286 и был почти пределом совершенства

А то! Но решались!

bs · 23.11.2011 01:32:40

ЦитироватьМы НПО Маш предлагали решать их на R-3000 под VxWorks

Предполагалась совместная работа с Американцами или с Французами

Эх, хороший был бы опыт.

belov2018 · 23.11.2011 01:37:02

Но полетел 186 со 187. И на Ямал-100. И только в 2000-м.

Вадим Семенов · 23.11.2011 01:40:47

Цитировать
Цитировать
Цитировать
ЦитироватьДело не просто в надежности. Динамическая типизация - ненужный расход ресурсов. На борту они ограничены (характерны, к примеру, показатели ОЗУ 2 Мбайта).
2 Мбайта это не так уж мало, а оверхед динамической типизации по памяти не очень большой, скажем, 1 байт на примитивные типы или 1 слово на типы, определяемые пользователем. Тут больше страдает производительность из-за неявных преобразований несоответствующих типов. Но этот аспект в большей части в руках разработчика.
Больше всего страдает надежность, поскольку в результате буйного преобразования типов получается неизвестно что. Скажем преобразование вещественного в целое дробная часть отбрасывается. Возможно, в данной задаче подобная потеря точности недопустима, но компилятор/интерпретатор этого не заметит. Так же автоматическое управление памятью вносит непредсказуемые временные задержки, если куча закончилась и надо собирать мусор. А так же потенциальный отказ из-за полного исчерпания динамической памяти. Статическое распределение памяти гарантирует временные задержки и достаточность памяти при компиляции. Многозадачность вносит негарантированный доступ каждой задачи к процессору плюс возможные дедлоки в результате синхронизации задач.
Круто, но КА замкнутый объект, с конечным числом, как задач, так и параметров. Можно добиться приведения к 2-3 типам без потери точности и устойчивости объекта

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