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

[zyxman]

Здесь как-то уж много уделяют внимания не процессу (создание), а последующей обработке (тестирование).

Ну собственно суть гибких методологий в том, что вместо одного длинного цикла "проектирование->создание->доводка" делается много таких-же но коротких циклов длительностью от недели до месяца (каждый коллектив по опыту выбирает удобный период), и каждый раз в середине цикла производится уточнение ВСЕГО ТЗ (в сторону упрощения или усложнения) с учетом опыта очередной решенной задачи.
А тесты только уже инструмент, как для отладки так и для оценки (тесты позволяют судить сколько есть багов и оценивать сколько их еще осталось, и главное измерять, как меняется количество багов от сложности задачи). А главное все-же методология.

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

Ну вы же не хотите сказать, что ПО АМС принципиально сильносвязанная система, части которой нельзя разрабатывать по отдельности? Я думаю что насчет возможности оценки сложности (и времени создания) вы спорить не будете

[Дем]

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

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

[zyxman]

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

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

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

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

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

Вобщем идея конечно имеет право на жизнь, но только если у нас совсем плохо с вычислительными мощностями, что они не позволяют использовать микроядерную ОС и соответствующие программные проверки, то есть использовать для проверок НАДЕЖНЫЕ И ПРОВЕРЕННЫЕ ресурсы БВК - ОЗУ и защиту памяти.

[Unispace]

Ну вы же не хотите сказать, что ПО АМС принципиально сильносвязанная система, части которой нельзя разрабатывать по отдельности? Я думаю что насчет возможности оценки сложности (и времени создания) вы спорить не будете

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

[Unispace]

Перенервничали ?    Душ холодный примите. У меня ничего не летало, потому что я работал не в космической области. Просто работало, то железо и софт, которое было создано мной. И работает по сей день. Одна из фирм, в которой я трудился, на сегодня имеет больше 100 тысяч персонала по всему миру. Одним из важнейших условий моей работы на этой фирме было не трендеть, а обеспечивать то самое тестирование и запуск систем. На тот момент времени людей, обученных этому, было у нас в стране человек 50. Вы рассуждаете о вещах, в которых у вас просто нет опыта, это я вам уже написал. И это видно за те самые 10 км. У меня нет опыта разработки систем космических аппаратов, поэтому я тоже могу ошибаться в умозаключениях, выводах или предположениях. Но есть многие вещи, одинаковые для разработчиков любых систем, сходных с системами АМС. Мне интересно побеседовать об этом аппарате, поразмышлять о технических причинах провала миссии, а не спорить о фетише программирования и тестирования. Поэтому прошу впредь не засылать мне свой снобизм пакетами, они будут  сброшены. Благо в виртуальном мире для этого не нужно тратить пакеты настоящие, мусорные.

[Not]

Перенервничали ?    

Не расхохотался, увидев вот это:

Это не игрушки и картинки, это АМС, которой отправляться в космос через час.

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

[zyxman]

Ну вы же не хотите сказать, что ПО АМС принципиально сильносвязанная система, части которой нельзя разрабатывать по отдельности? Я думаю что насчет возможности оценки сложности (и времени создания) вы спорить не будете

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

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

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

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

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

[Unispace]

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

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

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

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

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

[zyxman]

Unispace, так извините, телеметрия, радиосвязь, ориентация на Солнце это очень простые с программной точки зрения устройства - там совершенно примитивная логика которая легко решается чуть ли не на отдельных транзисторах, так что и нормально что они отдельные; насчет БОКЗ вопрос сложнее но вобщем тоже там уже готовое устройство лучше по надежности, да и вероятно дешевле, чем тратить ресурсы на интегрировать это всё в центральную ЦВМ

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

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

[TAU]

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

Характерная ошибка мышления - искусственное противопоставление.
Надо выучить конструкцию "И": И правильный выбор языка, И правильный выбор подхода, И правильный выбор платформы, И правильное тестирование, И человеческий фактор.

В этом случае, возможно, до Марса долетим и даже назад вернёмся.

Разработка АМС -  не та сфера, которая двигает компьютерное железо и софт

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

[TAU]

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

В целом все правильно написано. Позволю себе также процитировать книгу Д.И.Козлова, Г.П. Аншакова, Я.А. Мостового, А.В. Соллогуба "Управление космическими аппаратами зондирования Земли:Компьютерные технологии " (М.:Машиностроение, 1998).

На борту современного космического аппарата на выбор принципа организации вычислительного процесса в БВС влияют такие основные особенности, как:

[TAU]

шаг на пути автоматизированного программирования, когда человек с помощью компьютера ОДНОЗНАЧНО ставит задачу, а компьютер, используя некоторую базу знаний оптимально строит программу для имеющегося в наличии железа

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

[TAU]

Уважаемые, можете просветить: какая аппаратура сейчас применяется для отладки ПО БВК?

Судя по тому что я читаю на этом форуме и по моему личному опыту общения с разработчиками ПО из военки, отлаживается всё это на дремучем кустарном уровне - в обычном дебаггере на ПК

Ну хватит глупости городить :!:

Могу посоветовать почитать, кроме уже процитированной выше, еще книгу Е.А. Микрина из "Энергии" "Бортовые комплексы управлеия космическими аппаратами и проектирование их программного обеспечения" (М.:МГТУ, 2003).
Или вот еще А.А. Колташёва из ОАО ИСС: "Особенности переноса бортовых программ"
http://old.osp.ru/os/2004/04/184172/_p1.html

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

БПО проходит многоступенчатую отладку: автономную (перевожу на жаргон программистов "общего назначения": unit testing), совместную ("интеграционное"), комплексную.

При этом активно используются средства автоматизации тестрования.

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

Естественно, на всех стадиях разрабатывается специальная стандартизованная документация: "Программа и методика испытаний".

[TAU]

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

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

Надежность БПО определяется:
1. Процессом/методологией/технологией его разработки на всех стадиях жизненного цикла
2. Личностью разработчика (ков)
3. Взаимопониманием в команде разработчиков между специалистами по аппаратным сресдствам, логике управления и программистами
4. Используемыми языками
5. Устойчивостью к некорректному поведению аппаратуры
6. Возможностью коррекции/замены ПО в процессе полета
7. Отсутствием ошибок в инструментальных программных средствах - компиляторах, системах автоматизированного тестирования, и пр.
8. Многоэтапным тестированием и испытаниями - в том числе в комплексе с моделями, а затем "настоящим" железом
9. Формальными методами верификации - ну, это наше светлое будущее в основном пока  

[avp]

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

Без комментариев. Вы ничего не опровергли из того что я говорил про  Erlang.

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

Вы бесконечно далеки от реальной жизни. Одно дело архитектура x86 и другое дело какой нибуть ARM.  Виртуальная машина какой бы она не была не может абстрагироваться от низкоуровневых особенностей конкретного железа и ввода-вывод.

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

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

Ещё раз повторяю. HAL кто будет переписывать и тестировать? Кто будет кодировать низкоуровневый ввод вывод??? Всё это даёт  нехилый abstraction penalty. Толку от этой микро ОС будет около нуля при ограниченности памяти и других ресурсов. Такая ОС должна создаваться и вылизываться десятилетиями при более менее стабильной аппаратной платформе.

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

Что значит "управлять надёжностью"?
Сносить криво ведущий себя код.
Упадёт ваш процесс на Erlang и может быть перезапустится. Возможно и дальше заработает. Но целевая функция будет не выполнена, состояние будет потеряно.

На Яве у вас тупо вылетит исключение и всё. Да ВМ будет жива, но в сейф мод придётся перейти.

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

Функциональные языки максимально близки к декларативным DSL,

Бесконечно далеки. Например SQL близок к функциональному, но ни на каком существующем функциональном языке его не выразишь адекватно без макросов.
Есть например варианты декларативного описания конечных автоматов. Вполне себе DSL.  Генерируют высоконадёжный код.

а конкретно Erlang использует синтаксис очень близкий к Prolog,

Может хватит про Erlang? Это язык программирования с динамической типизацией. Этого достаточно чтобы выбросить его в топку. Только жёсткая статическая типизация с случае КА будет приемлимой.

[Дем]

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

1. Ну что поделать? Но бездействие как правило менее фатально, чем действие.
2. Не факт. Добавляя одно звено - другие можно убрать.
3. Нет, дрова те же. Идея-то в чём? Чтобы все важные "кнопки" были с предохранителями. Т.е. в драйвер это вносить нельзя. Должно быть два вызова, притом разных функций.

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

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

[PIN]

Я на прошлой странице привёл фото звёздных датчиков - и там видно, что за 15 лет интерфейс не поменялся. Т.е. - он фактически "черный ящик", выдающий весьма ограниченную информацию. Возможности например слить картинку с сенсора и отправить для анализа на Землю - нет.

Даже в Интернет есть примеры кадров с "Ямалов". Так что, заблуждаетесь. А интерфейс там, скорее всего, особо и не менялся - более-менее стандартный (для _любого_ звездного датчика) набор команд и информационных сообщений. Разница только в деталях - у кого-то направляющие косинусы, у кого-то кватернионы на выходе. У кого-то последовательный интерфейс, у кого-то (БОКЗ) - шина.

[Дем]

А интерфейс там, скорее всего, особо и не менялся - более-менее стандартный (для _любого_ звездного датчика) набор команд и информационных сообщений. Разница только в деталях - у кого-то направляющие косинусы, у кого-то кватернионы на выходе. У кого-то последовательный интерфейс, у кого-то (БОКЗ) - шина.

То, что было нормальным 15 (а то и больше) лет назад - сейчас совершенно ненормально.

[PIN]

Что конкретно "ненормально", поясните, пожалуйста.
Есто опыт работы с современными датчиками других производителей? Поделитесь тогда.

[Unispace]

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

Характерная ошибка мышления - искусственное противопоставление.
Надо выучить конструкцию "И":

Разработка АМС -  не та сфера, которая двигает компьютерное железо и софт

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

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