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

[TAU]

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

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

специфические решения, реализуемые в АМС, не столь нужны в компьютерных технологиях массового распространения

Но при создании БВК АМС и вообще КА - нужны?  Мы собираемся строить космические корабли?

Виндовс содержит много ошибок, но завоевала мир

Просто кое-кто недоучившийся в университете был в нужное время знаком кое с кем. И вообще - гений маркетинга и бизнеса.

[Unispace]

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

Но при создании БВК АМС и вообще КА - нужны?  Мы собираемся строить космические корабли?

Просто кое-кто недоучившийся в университете был в нужное время знаком кое с кем. И вообще - гений маркетинга и бизнеса.

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

Нет, не просто. На одном маркетинге не уедешь в таких областях, были и конкуренты.

[bs]

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

Ну не стоит так критично. Между динамической и статической типизацией есть определенный баланс. При правильном подходе динамическая типизация не мешает разрабатывать надежный код.

По поводу Erlang. В целом то мысль интересная, однако много вопросов по применимости данного чуда. В первую очередь относительно его применимости в критичных ко времени исполнения системах реального времени.

Виртуальная машина, на первый взгляд, хорошо - дополнительный уровень защиты от непредвиденных проколов в ПО. Практика также показала, что ВМ не мешает добиться real time исполнения. Взять ту же Real Time Java, успешно отработавшую на марсоходах. Но, с другой стороны, тот же уровень защиты можно получить используя и дополнительные аппаратные средства (watchdog таймеры, защиту критического кода и данных от перезаписи глючащим процессом). ВМ в этом плане предъявляет меньше требований к аппаратной части, и как следствие может быть дешевле. Плюс все-таки более высокий уровень абстракции в фундаменте ПО систем управления.

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

ПРОЛ2 тоже интересен, но опять же, он все равно не дает 100% гарантии от ошибок в алгоритмах, а следовательно не позволяет исключить ни одну из обсуждаемых составляющих разработки надежного ПО. Да и задача у него другая была, если я правильно понял, - исключить "чистого" программиста из цикла разработки. Однако программист помимо тупого преобразования спецификаций в код попутно решает еще кучу задач (обработка ошибок, оптимизация, адаптация под аппаратную часть и т.п.), которые для "специалиста", составившего спецификацию, вообще не существуют.

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

[bs]

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

По сути тестировщик является "автоматизатором" процесса тестирования там, где более лучшие варианты автоматизации тестирования не доступны.

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

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

План тестирования - это совместный продукт разработчиков и конструкторов. Основная часть составляется на начальном этапе и потом постепенно корректируется по ходу эволюции системы и КИС.

Рабочая схема? Нужен тут супер-спец тестировщик? По-моему, ответы очевидны.

[zyxman]

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

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

Спасибо за ссылки.
Я про ОАО ИСС знаю и их уважаю. Но я считаю что они оазис в пустыне. РККЭ пока АМС не занимается. (или уже занимается?)

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

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

[Aleks1961]

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

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

Для формирования "главного ГОСТа" необходимы правила, которыми и руководствуются при разработке РКТ - РК-98-КТ и ГОСТами.

[LRV_75]

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

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

Для формирования "главного ГОСТа" необходимы правила, которыми и руководствуются при разработке РКТ - РК-98-КТ и ГОСТами.

Да в ГОСТах и в том же РК-98 все есть. Этими документами не руководствуются в процессе разработки, только в декларативной форме. Я почти уверен, что по проекту Фобос-Грунт была слабая стендовая база. Многое проектировалось "в темную", без возможности натурной отработки. У нас вообще заказчик не понимает зачем нужны стенды и что нормальный полноценный стенды будет стоить не меньше (если не больше) чем сам опытный образец. Заказчику не нужны стенды. Ему нужно летающее железо, а вот взаимосвязь этих двух компонент они не видят. Попробуйте заложить в процесс разработки в статьи затрат какого нибудь изделия пункт - создание испытательного стенда для этого изделия? Заказчик не поймет эти "дополнительные" затраты. Тут очень кстати, была информация про сгнившие полы в одном из НИПов. Мысль, сделать ремонт в голову никому не пришла

[zyxman]

По поводу Erlang. В целом то мысль интересная, однако много вопросов по применимости данного чуда. В первую очередь относительно его применимости в критичных ко времени исполнения системах реального времени.

Есть вопрос про реальное время.
Вы возможно в курсе, сейчас разделяют два уровня исполнения систем РВ:
1. hard real time - система гарантирует задержку исполнения не более заданной всегда.
2. soft real time - система гарантирует задержку исполнения не более заданной скажем в 90% случаев (в 10% случаев задержка может быть существенно больше).

Вопрос, какой именно уровень исполнения РВ вы считаете необходимым и какой достаточным для АМС и почему?

PS Собственно сейчас в Erlang обычно используется квант 1мс; в Erlang soft real time, то есть могут быть выбросы задержек.

[Unispace]

Для формирования "главного ГОСТа" необходимы правила, которыми и руководствуются при разработке РКТ - РК-98-КТ и ГОСТами.

Для формирования этого ГОСТа заново нужно перестать все в жизни измерять деньгами. Нам много лет внушали в СССр, что Запад - это мир чистогана. Оказалось, что им и не снился наш "чистоган".

[Aleks1961]

Для формирования "главного ГОСТа" необходимы правила, которыми и руководствуются при разработке РКТ - РК-98-КТ и ГОСТами.

Для формирования этого ГОСТа заново нужно перестать все в жизни измерять деньгами. Нам много лет внушали в СССр, что Запад - это мир чистогана. Оказалось, что им и не снился наш "чистоган".

Деньги за хорошую работу в соответствии с ISO, и премии за качественную работу выполненную раньше срока контракта, и штрафы за невыполнение! Вот Запад. :lol: И репутация, зависящая только от результата

[bs]

Вопрос, какой именно уровень исполнения РВ вы считаете необходимым и какой достаточным для АМС и почему?

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

Но в зависимости от специфики не исключено, что провалы soft real time удастся компенсировать за счет изощренности СУ.  Главное чтобы эти сложности с лихвой компенсировались преимуществами, которые стоили нам soft real time'а.

[Aleks1961]

По поводу Erlang. В целом то мысль интересная, однако много вопросов по применимости данного чуда. В первую очередь относительно его применимости в критичных ко времени исполнения системах реального времени.

Есть вопрос про реальное время.
Вы возможно в курсе, сейчас разделяют два уровня исполнения систем РВ:
1. hard real time - система гарантирует задержку исполнения не более заданной всегда.
2. soft real time - система гарантирует задержку исполнения не более заданной скажем в 90% случаев (в 10% случаев задержка может быть существенно больше).

Вопрос, какой именно уровень исполнения РВ вы считаете необходимым и какой достаточным для АМС и почему?

PS Собственно сейчас в Erlang обычно используется квант 1мс; в Erlang soft real time, то есть могут быть выбросы задержек.

Извините, вставлю пятак. :lol: Любой, на выбор разработчика, при котором управляемый объект удовлетворял бы требованиям предъявляемым к нему, с допустимым (оптимальным) запасом устойчивости к внешним воздействиям и внутренним отказам объекта.

[TAU]

все равно стремиться к снижению значимости человеческого фактора стоит

На конвейере ширпотреба. Можно отчуждаться. А в специальных или передовых проектах - никак

Как.

100 середнячков не заменят одного талантливого

Это да.

[bs]

Извините, вставлю пятак. :lol: Любой, на выбор разработчика, при котором управляемый объект удовлетворял бы требованиям предъявляемым к нему, с допустимым (оптимальным) запасом устойчивости к внешним воздействиям и внутренним отказам объекта.

Совершенно верно! Увы природа soft real time затрудняет анализ этих параметров.

[TAU]

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

Ну не стоит так критично. Между динамической и статической типизацией есть определенный баланс. При правильном подходе динамическая типизация не мешает разрабатывать надежный код

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

Специфика функционального подхода тоже несколько настораживает

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

ПРОЛ2 тоже интересен, но опять же, он все равно не дает 100% гарантии от ошибок в алгоритмах

Хммм. Но он позволяет резко снизить количество возможных видов ошибок - подобная формулировка устроит? за счет подъема на "недоступную высоту" проблемно-ориентированного языка. Это причем как раз специально созданное с учетом специфики средство.

задача у него другая была, если я правильно понял, - исключить "чистого" программиста из цикла разработки. Однако программист помимо тупого преобразования спецификаций в код попутно решает еще кучу задач (обработка ошибок, оптимизация, адаптация под аппаратную часть и т.п.), которые для "специалиста", составившего спецификацию, вообще не существуют

Информации о ПРОЛ2 не столь много имеется. Почему бы не предположить, что создателям удалось решить все перечисленные задачи, переложив их на систему?

[TAU]

Вопрос, какой именно уровень исполнения РВ вы считаете необходимым и какой достаточным для АМС и почему?

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

[bs]

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

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

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

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

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

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

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

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

Хммм. Но он позволяет резко снизить количество возможных видов ошибок - подобная формулировка устроит?

Ну резко снизить количество ошибок могут и более традиционные методы, которые не так кардинально усложняют тот же контроль версий, к примеру. И там, и там главную роль играет отвественность разработчика. Но т.к. закладываться на нее на 100% не позволительно, то все равно придется прибегать ко всему арсеналу. Тогда в чем выгода?

за счет подъема на "недоступную высоту" проблемно-ориентированного языка. Это причем как раз специально созданное с учетом специфики средство.

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

Информации о ПРОЛ2 не столь много имеется. Почему бы не предположить, что создателям удалось решить все перечисленные задачи, переложив их на систему?

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

[Aleks1961]

Извините, вставлю пятак. :lol: Любой, на выбор разработчика, при котором управляемый объект удовлетворял бы требованиям предъявляемым к нему, с допустимым (оптимальным) запасом устойчивости к внешним воздействиям и внутренним отказам объекта.

Совершенно верно! Увы природа soft real time затрудняет анализ этих параметров.

Не со всем так, внешние воздействия на 90% известны, а внутренние в соответствии с вероятностью отказов СЧ объекта, полученной расчетным и экспериментальным путем. Необходимо адекватно парировать их воздействие на систему с помощью алгоритмов СПО.

[bs]

Имел в виду, что soft real time приводит к дискретному управлению с периодически падающей (существенно) частотой дискретизации. Как будет анализировать устойчивость?

[Aleks1961]

Имел в виду, что soft real time приводит к дискретному управлению с периодически падающей (существенно) частотой дискретизации. Как будет анализировать устойчивость?

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