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

[bs]

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

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

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

[zyxman]

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

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

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

Конкретно ВМ Erlang на 2 Мбайтах запускали точно.

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

Да, это меня и смущает.

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

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

Функциональный язык там вроде в основе. Но основная модель разработки - это асинхронные агенты и обмен сообщений между ними. Последнее позволяет реализовать произвольное состояние (с небольшой помощью от ран-тайма по сохранению/восстановлению данных). Тут я не спец и рассуждаю, исходя из общих соображений. Может zyxman прольет свет на этот аспект.

Обязательно. Только сейчас ищу/придумываю достойную задачу.

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

Состояния реализуются хитро, используя асинхронность, легковесность процессов и сообщения.
Плюс есть несколько уровней БД:
1. Простейшая система ключ-значение внутри каждого процесса
2. Несколько вариантов таблиц вроде классических хешей и массивов, работающие внутри ВМ
3. Распределенная СУБД с оптимистичным названием Mnesia :wink: - должна тут всем понравиться - её можно запустить на нескольких ВМ, и она будет автоматически поддерживать горячую синхронизацию всех собственных копий, то есть если у вас какая-то нода по какой-то причине отключилась от сети, то при последующем подключении она автоматически засинхронизирует свои таблицы с другими нодами.

Ок, попробую сразу к делу.

Я сейчас напишу упрощенный эмулятор ракетного двигателя на сжатом газе.
Двигатель имеет состояния: on; off; offToOn; onToOff
двигатель управляется сообщениями: on, off.

Код Выделить Развернуть

-module(eng).
-export([mstart/0]).

mstart() ->
 off().
%% end.

off() ->
receive
on -> offToOn();
_Other -> {error, unknown_msg}
end.

on() ->
receive
off -> onToOff();
_Other -> {error, unknown_msg}
end.

offToOn() ->
receive
after 1000 -> on()
end.

onToOff() ->
receive
after 1000 -> off()
end.


after это таймаут в миллисекундах.
Дальше можем попробовать сделать автомат состояний бака и доработать двигатель чтобы он регулярно сообщал баку что откушал у того сколько-то топлива, ну и "наверх", что тяга столько-то :wink:

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

Я так не считаю, но параллельная работа сборзика мусора не гаратирует, что мусор будет собран к тому моменту как понадобится динамическая память.

Но средняя и максимальная задержка в таком крайнем случае все-же поддается расчетам.

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

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

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

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

Не может ВМ ничего исключить. Она может лишь отловить эту ситуацию и застрелиться. Потому как что делать, если стек переполнился один хрен никто не знает.

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

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

То что любое число может интерпретироваться как указатель.

Если 0 - это любое число, то да

0 любое, и любое другое число тоже любое.

Куда же подевалась жесткая типизация? Не забываем, что С++ - это язык со строгой типизацией.

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

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

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

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

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

[Unispace]

Или там тоже у нас победил принцип либерализма,

Ну за что боролись...

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

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

Это не в пользу микроконтроллеров, это вообще и просто  - в пользу    И зря вы думаете, что стандартизация за рамками программистов и разработчиков. Как раз эти разработчики и основывают такие институты и документы стандартизации. Кому, как не им, понимать важность этого дела, чтобы избежать изобретения очередного велосипеда по заданию начальства. Что у нас меняется в звездном небе ? Ничего. Сенсоры принципиально иные ? Нет. Значит, по моему мнению, уже мог быть стандарт с условным названием ICS45, описывающий алгоритм системы звездной ориентации, математически выверенный и на уровне мета-языка. Бери и реализуй. То же самое с аппаратной частью, датчик такой-то, исполнительный механизм такой-то ? Для него стандартизован такой-то интерфейс, бери и реализуй, повышай модульность всей платформы.

[zyxman]

Взять одну троированную ЦВМ

Про троированную ЦВМ было бы интересно почитать, например на ту которая на КК Союз применяется. Что там представляет одельный модуль и на каком уровне производится "голосование" со сравнением результатов. И что делает тот модуль, который в голосовании "остался в меньшинстве".

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

[Unispace]

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

Их было бы побольше, по крайней мере на одного, если бы у нас поняли, что кроме денег и работы еще и окружение нужно создать хорошее, для отдыха и той же работы  Вот в Сколково там кого-то зовут. Представьте, человек живет в Швейцарии, на берегу озера, чисто, красиво, несуетливо, небыдливо, цивилизованно. Все условия для труда и отдыха. Тут ему говорят, езжай к нам, мы тебе денег дадим в 3 раза больше. Какой идиот найдется ехать из Швейцарии в Москвабад, где просто не понимают, что такое комфорт и набор параметров нормального уровня жизни ? Там этот набор трансформировался в сингулярность монеты. Цивилизованный человек существовать в этой сингулярности не сможет.

[zyxman]

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

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

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

Когда-то мне давали пример сложной системы, где получилось ЕМНИС около 1.5млн строк кода на С++, но надежной работы добиться не удалось; параллельно успешно сделали систему выполнявшую ту-же задачу на Erlang и она успешно пошла в работу.

[zyxman]

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

Я видел и Modula и Ada. Собственно я немножко с VHDL имел дело, который по сути подмножество Ada.
Так вот по-моему чуть не Дейкстра шутил, что Ada это как программирование видят военные Перебор вобщем - нормального программиста сложно заставить в такой формальной среде корректно работать.

[Unispace]

Когда-то мне давали пример сложной системы, где получилось ЕМНИС около 1.5млн строк кода на С++, но надежной работы добиться не удалось; параллельно успешно сделали систему выполнявшую ту-же задачу на Erlang и она успешно пошла в работу.

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

[zyxman]

Ну вы просто как рекламный агент этого Эрланга или Эрикссона, или человек, получивший корочку по программированию на этом Эрланге  

Эрикссон уже давно Эрлангом не занимается.
А мне лично обидно что высоконадежные большие системы сейчас делаются чаще всего на Enterprise Java, которая намного менее элегантна чем Erlang мягко говоря.

Даже чуть по другому скажу: хотя я всей душой за либеральную демократию, мне очень нравится, как иногда красиво решали задачи в СССР - показывали действительно системный подход.
А эти самые Enterprise Java, Modula, Ada неоригинальны и как раз по-западному - вот решили что нужно ужесточить типизацию и закрутили её по самое нехочу, ну и вобщем и с остальным там то же самое - заставили вобщем программиста - творческого человека строем ходить.
Я думаю что можно такой-же надежности достичь и без такой строгости.

[Unispace]

Я думаю что можно такой-же надежности достичь и без такой строгости.

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

[TAU]

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

Вы не правы. Как раз наоборот. В основе управления КА лежит циклограмма. Т.е. по классификации систем реального времени на "управляемые событиями" (асинхронные) и "управляемые временем" (синхронные) система управления КА как раз синхронная

[TAU]

резко снизить количество ошибок могут и более традиционные методы

Ну я уже выше писал про "И". Для повышения надежности ПО БВС КА необходимо применять по возможности ВСЕ известные методы. Цена вопроса слишком велика  

Тогда в чем выгода?

Выгода от чего? От "программирования без программистов"?

Сроки разработки систем, в которых использовался ПРОЛ2 не то, чтобы маленькие. То что они работают, это факт. Но далеко не факт, что их нельзя было разработать с применением современных технологий за более короткие сроки, и задействуя меньшие ресурсы

Факт - увы! - в том, что программа Буран закрыта много лет назад.  
Можно ли было без ПРОЛ2 быстрее и проще сделать?
Думаю, нужно все-таки относиться к создателям его (неглупым весьма и весьма людям) с большим доверием. Вообще говоря, декларировалось, что им удалось повысить производительность труда при создании комплекса программ для Бурана в 10 раз!

[TAU]

Решались чуть ли не на х286 процессоре :lol:

Вы полагаете, это смешно?

[TAU]

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

Простите, можно вопрос? "Мы" - это кто?

[TAU]

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

Вот! А я о чем!

Кстати, по поводу того что ООП - "гигантский скачок", не все согласны. В том числе - не последние люди в программировании.

[Aleks1961]

Решались чуть ли не на х286 процессоре :lol:

Вы полагаете, это смешно?

Через 20 лет - да, глядя на некоторые события сегодення! :lol: Там было еще - А то! Но решались! Задачи на борту КА :!:
Например КА Океан-О http://ruscosmos.narod.ru/KA/okean/okean10.htm

[belov2018]

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

Простите, можно вопрос? "Мы" - это кто?

Группа специалистов в НИИ Аргон

[avp]

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

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