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

[Дядя Вова]

Кста, они же БОКЗ и делали - http://ofo.ikiweb.ru/p_phobos.php

Безумно кошмарный ИКИшный софт у этого стенда. Тихий ужас.

Ну, вот! О чем и говорилось - стенд есть и делал его производитель.
Использовался ли он для (или что-то подобное) для разработки - опять вопрос.
А то, что софт кошмарный - это выглядит пока как субъективное мнение. И скорее всего он не реализует обратную связь двигателей АМС (ну, не надо оно разработчику, если не вменено свыше). Т.е. как и говорили здесь - отдельная песня для отдельного хора.

[Feol]

Использовался для разработки БОКЗ, потом был куплен Геофизикой для своего прибора. Софт стенда написали свой от начала до конца.

[zyxman]

"за всё приходится платить" (с) , и изучить еще один язык небольшая плата. По опыту изучение самого языка Erlang занимает пару недель.

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

Вы бумом функциональных считаете LISP? - Не смешно?

Я вообще-то говорил комплексно про СИСТЕМУ Erlang/OTP, и она НЕВОЗМОЖНА в отрыве от языка.

Реализацию рантайма ещё надо написать и отладить. При этом скорее всего ещё ОС придётся делать. Для новой железки это неподъёмная задача. Компиляторы и ВМ вылизываются и отлаживаются десятилетиями. Такое возможно только на долгоиграющей стабильной платформе типа PC.

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

Связность  определяется предметной областью, а не языком.

В случае Erlang/OTP вы автоматически будете писать слабосвязанно, ибо запрещено почти всё что дает сильные связи.

С чего бы это бы? Что мешает всю ключевую логику вбухать в один большой процесс, а вспомогательные сделать только для IO?

Можно и на сверхнадежной Аде все сделать через Ж.
Но разница в том, что на Erlang/OTP в отличие от Java/Modula/Ada УДОБНО писать слабосвязанно.
И в случае соблюдения УМЕРЕННО сложной технологии Erlang/OTP ГАРАНТИРУЕТ стабильные приложения. - У других сверхнадежных систем сложность технологии буквально концлагерная, почему они и не распространились, и почти никто не в состоянии полноценно соблюдать.

Я всё более убеждаюсь, что вы сами ничего на Erlang/OTP не делали, а ориентируетесь на том что "Рабинович напел".

[ZOOR]

С соседней ветки

При наземных испытаниях бортовая машина работала не более 6 часов, а потом зависала. Последнее изменение ПО произходило уже на Байконуре.

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

Дело в том что в бортовой машине вообше нет ОС

Получается, на ФГ нет? Синхронная схема организации вычислительного процесса? Выделенные интервалы времени на каждый пакет задач?

Что-то не верится, что при таком процессе возможно программное зависание.

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

Что не так я мыслю?

[avp]

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

Это не так. Помимо особенностей платформы, ещё большая вероятность изменения прикладных требований, под которые придётся всё адаптировать.  Разные ОС, или их вообще нет. Разные стратегии управления ошибками, выделением памяти и т.п. Код с PC придётся сильно переписывать.

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

Ничего она не переносится. Проблема в вводе-выводе, под которые придётся писать дрова, вникая во все тонкости ОС.

И в случае соблюдения УМЕРЕННО сложной технологии Erlang/OTP ГАРАНТИРУЕТ стабильные приложения. -

Ничего оно не гарантирует. Только делает код управляемым. Так это любой интерпретатор сделает. От логических ошибок спасает только что то типа DSL да и то не 100%

[zyxman]

avp, все-же вам "Рабинович напел".. Вы сами Erlang/OTP не пробовали.

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

Это не так. Помимо особенностей платформы, ещё большая вероятность изменения прикладных требований, под которые придётся всё адаптировать.  Разные ОС, или их вообще нет. Разные стратегии управления ошибками, выделением памяти и т.п. Код с PC придётся сильно переписывать.

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

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

Ничего она не переносится. Проблема в вводе-выводе, под которые придётся писать дрова, вникая во все тонкости ОС.

Вы сами себя понимаете? Если у нас уже есть микроядерная ОС, то во первых её тонкости минимизируются, а во вторых при переносе никаких новых тонкостей со стороны ОС не возникает.

И в случае соблюдения УМЕРЕННО сложной технологии Erlang/OTP ГАРАНТИРУЕТ стабильные приложения. -

Ничего оно не гарантирует. Только делает код управляемым. Так это любой интерпретатор сделает.

Нет. Не любой интерпретатор. Только ВМ заточенная на надежность позволяет управлять надежностью, и фактически кроме ВМ Erlang таковая только одна Enterprise Java.

От логических ошибок спасает только что то типа DSL да и то не 100%

Функциональные языки максимально близки к декларативным DSL, а конкретно Erlang использует синтаксис очень близкий к Prolog, который самый лучший для логики, тк самый новый и в разработке учли предыдущий опыт при этом не привязываясь к совместимости с более старыми образцами. Например известные проблемы Lisp, которые и породили точку зрения про закат интереса к функциональному подходу.

[kroton]

С соседней ветки

При наземных испытаниях бортовая машина работала не более 6 часов, а потом зависала. Последнее изменение ПО произходило уже на Байконуре.

Ну просто страшные слова вы говорите.

[belov2018]

Пускай источник "zorro" расскажет (если сможет), кто ездил на Байконур прожигать программы на собранном и принятом Заказчиком образце БВК.

[Not]

С соседней ветки

При наземных испытаниях бортовая машина работала не более 6 часов, а потом зависала. Последнее изменение ПО произходило уже на Байконуре.

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

[Unispace]

С соседней ветки

При наземных испытаниях бортовая машина работала не более 6 часов, а потом зависала. Последнее изменение ПО произходило уже на Байконуре.

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

Слова истинно рафинированного тестера, изолированного от железа, и не знающего, что такое процесс разработки этого железа, вместе с софтом. В курсе, что такое система remote patching, которая применяется даже на аппаратуре, от работы которой зависит в миллион раз больше, чем от ФГ ? Какие там формальные верификации, заседания и визирования, когда нужно на лету, срочно внести изменения в код, а необходимость такого изменения понимает прежде всего разработчик ? Все не ангелы, бывают ошибки, и бывает так, что ошибку, связанную с железом или софтом, заметили прямо у стапелей. Или в процессе работы техники. И которую нужно срочно исправить, скорректировав ПО. А тут вываливается хор импозантных тестеров и говорит "не трожь, мы еще формальную верификацию не завершили".  Это не игрушки и картинки, это АМС, которой отправляться в космос через час. И при разработке железа, имеющего на борту софт, программист-разработчик всегда по иерархии выше, чем хоть миллион тестеров. Тестируйте дальше, только при чем тут космос и приборы ?

[Aleks1961]

С соседней ветки

При наземных испытаниях бортовая машина работала не более 6 часов, а потом зависала. Последнее изменение ПО произходило уже на Байконуре.

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

Слова истинно рафинированного тестера, изолированного от железа, и не знающего, что такое процесс разработки этого железа, вместе с софтом. В курсе, что такое система remote patching, которая применяется даже на аппаратуре, от работы которой зависит в миллион раз больше, чем от ФГ ? Какие там формальные верификации, заседания и визирования, когда нужно на лету, срочно внести изменения в код, а необходимость такого изменения понимает прежде всего разработчик ? Все не ангелы, бывают ошибки, и бывает так, что ошибку, связанную с железом или софтом, заметили прямо у стапелей. Или в процессе работы техники. И которую нужно срочно исправить, скорректировав ПО. А тут вываливается хор импозантных тестеров и говорит "не трожь, мы еще формальную верификацию не завершили".  Это не игрушки и картинки, это АМС, которой отправляться в космос через час. И при разработке железа, имеющего на борту софт, программист-разработчик всегда по иерархии выше, чем хоть миллион тестеров. Тестируйте дальше, только при чем тут космос и приборы ?

Пора менять все ГОСТы ЕСПД и Информационная технология под программиста-разработчика :lol:

[Wishbone]

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

Мда. Unispace, Вы прям-таки Коноплёв современности. Нет, я не пытаюсь угадать, что Вы курите.

[ZOOR]

Рискну напомнить, что ПО предполагалось дописывать в полете совершенно официально - http://phobos.cosmos.ru/index.php?id=315&tx_ttnews[tt_news]=1954&cHash=41734d22a5896097386cc68c6b042e21

"27 сентября будет заседание госкомиссии и 29 сентября мы собираемся отправить его ("Фобос-Грунт") на космодром", - сказал Поповкин в кулуарах Второго международного форума "Арктика - территория диалога".

По словам главы Роскосмоса, окно запуска - период, в течение которого может стартовать космический аппарат - с 5 по 20 ноября. Однако, по словам Поповкина, все планы строятся с расчетом на запуск 5 ноября.

"Потому что спутник уникальный, если возникнут какие-то замечания - чтобы мы в это окно поместились", - пояснил глава Роскосмоса. Он добавил, что следующее окно "открывается" только через два года.

"Сегодня есть уверенность, что он стартует в это окно (до 20 ноября)", - сказал глава космического агентства.

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

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

Что такое "начальный этап полета" можно понимать по-разному  :roll:

[zyxman]

А я пожалуй "вступлюсь" за Unispace.
Я считаю что он прав с одной оговоркой - при использовании классической методологии, называемой в последнее время на жаргоне "водопад" так оно обычно и происходит: сначала идут пол года-год или даже больше проектирование ТЗ, возможно с неспешным кодингом, потом начинаются активные работы в режиме с 9 до 18, и за пару недель до сдачи обычно оказывается что ничего не готово и начинаются круглосуточные авральные работы, и всё равно сроки срываются и что-то кое-как работающее сдается в последний момент :lol:

Я лично работал практически со всеми известными методологиями, и реально скажу что "водопад" иначе быть просто не может - практически обязательно будет хоть самый минимальный аврал и уход сроков направо, либо очень жесткое урезание функциональности с потерей существенной части почти готовой работы, либо очень сырой ненадежный проект.
Очевидно что Rapid Application Development (быстрая разработка, например практикуется в разработке сайтов и десктопных приложений) в случае высоконадежных систем не пойдет.
А вот всякие разные Agile (Гибкие) методологии (похоже на идеологию современных телекомов - брать готовую систему и кусочками переделывать под новую задачу) вполне могут сработать если инструментарий достаточно для них подходит - конкретно Erlang/OTP с гибкими реально хорошо работает и получается высоконадежно.

Даже если честно, с Erlang/OTP гибкие методологии получают новый импульс для развития - практически только Erlang/OTP и Enterprise Java поддерживают возможность буквально заменять работающие блоки без перезагрузки всей системы, и на больших системах это выглядит феноменально - самое разрекламированное достижение Erlang/OTP это телефонный коммутатор British Telecom у которого за несколько лет эксплуатации было аж 0.3 секунды необслуживания клиентов - я думаю ни одна АМС до такой цифры не дотягивает.

[Unispace]

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

Мда. Unispace, Вы прям-таки Коноплёв современности. Нет, я не пытаюсь угадать, что Вы курите.

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

[Unispace]

Пора менять все ГОСТы ЕСПД и Информационная технология под программиста-разработчика :lol:

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

[Дем]

Вот датчики

Ну условно, компьютер IBM RAD 6000 стоит 200000-300000$, промышленный компьютер такого уровня стоит ну пусть 2000$, а если делать совсем уникальный компьютер с такими дополнительными защитами, он будет стоить еще на пару порядков дороже чем RAD 6000.

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

[Unispace]

А я пожалуй "вступлюсь" за Unispace.
Я считаю что он прав с одной оговоркой - при использовании классической методологии, называемой в последнее время на жаргоне "водопад" так оно обычно и происходит: сначала идут пол года-год или даже больше проектирование ТЗ, возможно с неспешным кодингом, потом начинаются активные работы в режиме с 9 до 18, и за пару недель до сдачи обычно оказывается что ничего не готово и начинаются круглосуточные авральные работы, и всё равно сроки срываются и что-то кое-как работающее сдается в последний момент :lol:

Да, у нас так часто и есть. К сожалению!  Финальная часть работ может быть скомкана, по разным причинам. Могут выпростаться всевозможные мелкие, средние проблемы, начинается дергание. Если бы все делалось четко, согласно тем же инструкциям и правилам, то лавинообразного увеличения суеты было бы поменьше. Однако даже все инструкции не могут предусмотреть всего, поэтому и на АМС есть режим изменения кода, и такие же возможности есть на многих сложных системах. Здесь как-то уж много уделяют внимания не процессу (создание), а последующей обработке (тестирование). А при создании таких устройств, как АМС, нельзя эти процессы разделить так же лихо, как при создании прикладного ПО для компьютеров, не имеющего своей основой сложные математические алгоритмы.

[zyxman]

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

Вы имеете в виду, что в каждом исполнительном устройстве будет дешифратор этих кодовых последовательностей?

[Not]

С соседней ветки

При наземных испытаниях бортовая машина работала не более 6 часов, а потом зависала. Последнее изменение ПО произходило уже на Байконуре.

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

Слова истинно рафинированного тестера, изолированного от железа, и не знающего, что такое процесс разработки этого железа, вместе с софтом.

Я не тестер. Я ведущий разработчик, который по долгу службы имеет дело с людьми, тестирующими мой продукт. Если для вас такой подход к делу внове - значит вы никогда не работали в большой фирме, ОТВЕЧАЮЩЕЙ за качество выпускаемой продукции. Приведу вам пример: представьте, что токарь подбегает к готовому изделию, прошедшему ОТК и стоящему на старте, выкручивает болт и бежит его перетачивать, уточняя (например) качество поверхности или посадку. Это именно то, что вы предлагаете.

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

В курсе, уважаемый. Remote patching ничем не отличается от обычной разработки и проходит такой же путь как и обычное изделие, через тестеров и ЛПР.

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

Вы сумасшедший. Вас на десять километров нельзя подпускать к ответственной работе. Если вы (и ваша фирма) действительно ТАК подходите к делу, то очень маловероятно что у вас что-то вообще летало дальше чем за бугор.  Но в реальности я честно говоря сомневаюсь, что вы вообще имеете какое либо отношение к разработке ответственного (mission critical) ПО, поскольку понятия не имеете о технологическом процессе разработки оного. Журналист, или мечтатель?