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

Автор Lytnev., 17.11.2011 18:11:06

« назад - далее »

0 Пользователи и 1 гость просматривают эту тему.

zyxman

ЦитироватьДядя Вова - не у того спрашиваете  :D
Он сам писал, что его личный опыт - это отладка в дебаггере.
Не вырывайте слова из контекста.
Я сказал что В ОТРАСЛИ отлаживают в дебаггере и говорю это не по чьим-то словам а по личным наблюдениям.
Я отлаживаю разными методами. Наверное практически всеми встречающимися в природе, но у вояк мой опыт применения не нашел.
"Демократия, это когда царь умный, а также добрый и честный по отношению к своим холопам".
--
Удача - подготовленный успех!

Дядя Вова

Да, почитал это место в Вестнике :( Загрустил - зря читал.

avp

ЦитироватьЯ на данный момент знаю програмную систему Erlang/OTP, которая включает систему мер для высоконадежного программирования:
Это где главный лозунг "let him crash" ?

Erlang эти инструмент под одну задачу - массовый асинхронизм.

Цитировать1. а "чистый" функциональный язык с переменными с однократной записью вообще не позволяет изменять переменные и этим избавляет от сторонних эффектов.
Тем самым требует кардинального изменения стиля написания программ.  И переучивания.

Язык там обычный примитивный. Основная фича там это рантайм.

Цитировать1.б Язык с автоматическим распределением памяти.
Даёт сильный недетерминизм состояния программы.

Цитировать1.в язык построен так, что при разработке "автоматически" получается слабосвязанная система, которую легко изменять/дополнять
Связность  определяется предметной областью, а не языком.

Цитировать2.а программы функционируют в среде виртуальной машины.
Кто и как будет искать баги в этой ВМ ?

Цитировать2.б суперлегковесные процессы с полной изоляцией - просто в принципе нет разделяемой памяти, а взаимодействие между процессами только сообщениями.
Любой скриптовый язык это может.
Но в любом случае придётся писать кучу низкоуровневого кода для работы с железом.

Баги прежде всего возникают от недостаточной спецификации предметной области. Тут задача больше не программиста а аналитика.

Легковесные потоки и message passing есть много где. Но не любой конечный атомат допускает читабельное разбиение на всевдо параллельные задачи.  Если у нас система обработки массового количества однотипных запросов,  то Erlang тут может выстрелить. Если же у нас сильно связанный конечный автомат, то тут поможет только тщательно составленная спецификация.


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

Not

ЦитироватьВы представить научно-профессорской среды :)
- ведущий инженер в области декларативного ПО.  Таким образом половина вашего длинного изречения про инженеров-практиков вылетает в трубу - в моем активе миллионы строк кода.


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

Not

Цитировать
ЦитироватьУ Unihorna смешались в кучу кони, люди... Зарплата, абстракции, многозадачность, реклама, и еще бог знает что. Давайте так:

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

Я вам скажу пожестче. Когда вы получите опыт программно-аппаратной разработки цифровых систем управления и обработки реального времени, тогда и будем говорить дальше.
Еще один мастер литературного жанра. Пожестче он скажет  :D Персонально я писал ядро и набор драйверов для многозадачной ОСРВ. И портировал в эту ОСРВ бортовое навигационное приложение с архитектуры 68К в архитектуру x86. Будем дальше рассуждать о роли транзистора в научно-техническом прогрессе?  :wink:

zyxman

Цитировать
Цитировать1. а "чистый" функциональный язык с переменными с однократной записью вообще не позволяет изменять переменные и этим избавляет от сторонних эффектов.
Тем самым требует кардинального изменения стиля написания программ.  И переучивания.
"за всё приходится платить" (с) , и изучить еще один язык небольшая плата. По опыту изучение самого языка Erlang занимает пару недель.
Вот изучение OTP, версионной системы и отладчика и вообще специфики рантайма конечно может занять значительно больше, но код человек сможет писать очень быстро и очень быстро сможет присоединиться к живому проекту.
ЦитироватьЯзык там обычный примитивный. Основная фича там это рантайм.
Я вообще-то говорил комплексно про СИСТЕМУ Erlang/OTP, и она НЕВОЗМОЖНА в отрыве от языка.
Цитировать
Цитировать1.в язык построен так, что при разработке "автоматически" получается слабосвязанная система, которую легко изменять/дополнять
Связность  определяется предметной областью, а не языком.
В случае Erlang/OTP вы автоматически будете писать слабосвязанно, ибо запрещено почти всё что дает сильные связи.
Цитировать
Цитировать2.б суперлегковесные процессы с полной изоляцией - просто в принципе нет разделяемой памяти, а взаимодействие между процессами только сообщениями.
Любой скриптовый язык это может.
ПОЛНУЮ изоляцию НЕ ЛЮБОЙ.
Точнее проблема что вы читаете язык, а я пишу про СИСТЕМУ, в которой и ВМ и библиотеки и дебаггеры и даже собственная версионная система.
ЦитироватьБаги прежде всего возникают от недостаточной спецификации предметной области. Тут задача больше не программиста а аналитика.
Вообще-то правильно разделять программиста-математика-алгоритмиста и программиста-кодера.
Аналитик это вообще отдельный человек.
ЦитироватьЛегковесные потоки и message passing есть много где.
Но практически нигде нет полноценной изоляции процессов - в Erlang даже обращение к файлу отдельного процесса медленное, чтобы этот процесс этим обращением к файлу не забрал слишком много ресурсов у других процессов.
ЦитироватьНо не любой конечный атомат допускает читабельное разбиение на всевдо параллельные задачи.
По существу у Erlang задачи НЕ псевдо-параллельные, а реально параллельные асинхронные, потому что могут жить на физически разных машинах.
ЦитироватьЕсли у нас система обработки массового количества однотипных запросов,  то Erlang тут может выстрелить. Если же у нас сильно связанный конечный автомат, то тут поможет только тщательно составленная спецификация.
Что-то вы непонятное тут говорите. Такое впечатление что вам про Erlang "Рабинович напел" :D
ЦитироватьЧто касается софта для КА, то я бы затребовал ресурсы на состояние эмулятора аппарата, который бы делала отдельная группа людей. Вопрос сопряжения софта и эмулятора - вопрос чисто технический и вполне решаем.
В смысле создание эмулятора совсем отдельной группой? - Поддерживаю.
"Демократия, это когда царь умный, а также добрый и честный по отношению к своим холопам".
--
Удача - подготовленный успех!

sychbird

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

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

Мне представляются эти вопросы не праздными и в определенном смысле направляющими для дискуссии по технологическим проблемам собственно программирования ПО КА.
Ответил со свойственной ему свирепостью (хотя и не преступая ни на дюйм границ учтивости). (C)  :)

Unispace

ЦитироватьБудем дальше рассуждать о роли транзистора в научно-техническом прогрессе?  :wink:

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

Unispace

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

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

Мне представляются эти вопросы не праздными и в определенном смысле направляющими для дискуссии по технологическим проблемам собственно программирования ПО КА.

Надежность софта определяется:

1. Отсутствием ошибок компилятора
2. Корректными алгоритмами, в том числе обработки ошибок, диаграммами работы, структурами данных
3. Внимательным программированием
4. Аппаратной реализацией

Тестирование софта зависит от выбранной модели, платформы.
Отсюда вывод - если считать, что программисты не занимаются п.4., а п.1. выполнен, то остаются п.2,3, которые, по чести сказать, не сильно зависят от принятой идеологии, платформ и т.п. При обеспечении п.2,3 остаются лишь вариации надежности, связанные с особенностями поведения того или иного кода-исполнителя кода при наступлении аппаратного сбоя в памяти или процессоре. А уж аппаратные ухищрения для устранения или уменьшения сбоев шин данных/команд, счетчика команд и всего контекста процессора могут быть разнообразными. От специальных кристаллов, работающих на повышенных напряжениях, до параноидальных, с ECRC, с проверкой сигнатур, матрицей размножения кода и прочая...

ZOOR

Цитировать
ЦитироватьЧто касается софта для КА, то я бы затребовал ресурсы на состояние эмулятора аппарата, который бы делала отдельная группа людей. Вопрос сопряжения софта и эмулятора - вопрос чисто технический и вполне решаем.
В смысле создание эмулятора совсем отдельной группой? - Поддерживаю.
Кстати, господа программисты ....
А что, стенда (электромакета) для отработки ПО не предусматривается?
А то вы все о программном да о программном, а как же отлаживать и перезакладывать ПО на улетевшую АМС (пока она на Земле хоть на ней самой тренироваться можно было)?
Я зуб даю за то что в первом пуске Ангары с Восточного полетит ГВМ Пингвина. © Старый
Если болит сердце за народные деньги - можно пойти в депутаты. © Neru - Старому

belov2018


Feol

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

ZOOR

ЦитироватьНа НПОЛ до 10 комплектов БВК
К ним еще имитаторы датчиков и исполнительных органов привязать надо ИМХО.
Сам БВК - вещь в себе. Молотит программу и все для него пучком.
А вот выдать воздействие и потом оценить реакцию всей СУ - для этого стенд нужен
Я зуб даю за то что в первом пуске Ангары с Восточного полетит ГВМ Пингвина. © Старый
Если болит сердце за народные деньги - можно пойти в депутаты. © Neru - Старому

profan

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

PROTEUS ?  :D
А если серьезно, пмсм, проверять надо реальное железо на "аппаратных" имитаторах, обязательно. Люфты, дрейфы, забития оптики  и премного тракта ни одна модель не покажет.

Feol

Цитировать
ЦитироватьНа НПОЛ до 10 комплектов БВК
К ним еще имитаторы датчиков и исполнительных органов привязать надо ИМХО.
Сам БВК - вещь в себе. Молотит программу и все для него пучком.
А вот выдать воздействие и потом оценить реакцию всей СУ - для этого стенд нужен
В ИСС так и делают при отработке системы ориентации новых КА. Есть имитаторы Солнца, Земли, приводы поворота приборов относительно них, имитатор звёздного неба для ПЗВ, поворотники для датчиков угловых скоростей и гироскопов. Всё запускается в общем контуре для отладки логики и динамики системы. Но это для новых разработок. Доработки ПО и разного рода заплатки, насколько я знаю, сейчас в основном проверяются только на программном имитаторе. Это в части системы ориентации. Про другие системы утверждать не буду.
Всем пользователям нравится это сообщение.

zyxman

ЦитироватьЕсли наши представления о развитии аварии соответствуют реальности. Что не факт, на данный момент.
Вот именно что не факт.
Самое главное что я могу видеть из открытых источников, что за рубежом как правило организовывают связь с АМС на всех этапах полета, или по крайней мере на всех критических этапах.
И также из открытых источников я вижу, что Ф-Г спроектирован совершенно странным образом, что с ним крайне сложно организовать связь на первом критическом этапе полета. Я про то что на низкой орбите НЕлогично использовать X-band (ЕМНИС 8ГГц), а логично было-бы использовать какие-нибудь 600МГц, тк тарелкой на X-band очень тяжело отследить быстро двигающийся объект, и плюс эта тарелка почти совершенно нетраспортабельна.
То что "почти полностью отсутствуют релейные команды", которыми можно было перезагрузить компьютер итп, вобщем-то критично, но когда нет связи релейные команды не помогут.
ЦитироватьВ какой степени эта идеология соотносится с международным опытом в идеологии конструирования АМС и как это проецируется  на надежность наземной отработки железа и софта?  :roll:
Международный опыт такой, что вычисления всё более активно выносят на центральный компьютер.
Но это конечно требует глубокого изменения самой технологии разработки ПО, тк одно дело то что раньше центральная БЦВМ занималась только полетом а теперь ею например фотки обрабатывают.
"Демократия, это когда царь умный, а также добрый и честный по отношению к своим холопам".
--
Удача - подготовленный успех!

Feol

ЦитироватьPROTEUS ?  :D
Не знаю, что это такое.
Всем пользователям нравится это сообщение.

zyxman

ЦитироватьЛюфты, дрейфы, забития оптики  и премного тракта ни одна модель не покажет.
Модель всегда можно доработать и добавить все изменения и особенности реального аппарата. Вот доработать реальный аппарат обычно невозможно.
"Демократия, это когда царь умный, а также добрый и честный по отношению к своим холопам".
--
Удача - подготовленный успех!

profan

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

zyxman

Цитировать
ЦитироватьPROTEUS ?  :D
Не знаю, что это такое.
Протеус феноменален - на эмулируемых устройствах Линукс запускается :D
"Демократия, это когда царь умный, а также добрый и честный по отношению к своим холопам".
--
Удача - подготовленный успех!