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

[TAU]

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

Уважаемый SOE! Крайне интересно. Можно поподробнее, пожалуйста?

И 90% проблем связаны с алгоритмическими ошибками на ранних стадиях разработки и ошибками в требованиях (технических заданиях)

В этом случае необходимо среди комплекса моделей, методов, языков необходимо разработать и использовать:

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

Кстати, перечисленные мною выше меры это подразумевают, а не противоречат.

Ну и, с оставшимися 10% бороться специфически "программистскими" заморочками.

[zyxman]

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

[avp]

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

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

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

[avp]

Анекдот про "неуловимого Джо" знаете? - Он неуловимый потому что никому не надо его ловить..
Ну так вот фирма Intel просто традиционно решает проблемы в своих процессорах улучшенным компилятором, а фирма AMD просто сделала такой процессор что там в таком серьезном вылизывании нет необходимости.
С 186 и VLIW ситуация аналогичная, но специфика чуть другая - просто этих процессоров настолько малое количество (в сравнении с Intel x86), что никто не хочет вкладываться в разработку оптимизатора.

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

[avp]

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

Я знаю, что эрланг нативно поддерживает ASN.1
Но, увы, в реальных протоколах связи с КА он не применяется. И я не знаю почему. Поэтому разбирать пакеты всё равно придётся ручками.

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

Вообщем вы сами признаёте что законченное решение будет в виде фарша из асма,  Си и эрланга.

[avp]

Итак, попробую обобщить.

Для построения высоконадежного ПО БВК АМС (и вообще ПО КА, РБ и РН а также наземных комплесов управления) нужен целый комплекс мер. Мое мнение:

1. Приведение заработной платы и престижа профессии программиста БВК к соответствующих значимости и сложности решаемых задач уровням. Это - необходимое условие! При этом - воспитание ответственности и аккуратности у разработчиков, поддерживаемое комплексом соответствующих организационных мер.

Тут пункт 0 забыт. Адекватная оценка количества человеко-часов и соотвественно создание коллектива с соответствующими возможностями.

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

И 90% проблем связаны с алгоритмическими ошибками на ранних стадиях разработки и ошибками в требованиях (технических заданиях).

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

[PIN]

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

Как правило, ошибки в требованиях (ТЗ, если хотите). Но сделать реализацию, несоответствующую требованиям с теми же проблемами тоже, конечно, можно. Что должно вылавливаться на этапе тестирования, охват которого тоже определяется сильно задолго для реализации. В итоге мы возвращаемся в тех самых 90% случаях к самым ранним этапам процесса. Где ни инструментальные средства, ни тем более язык программирования столь горячо обсуждаемые на этой ветке не фигурируют.  А фигурируют стандарты на сам процесс.

[bs]

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

И что сейчас происходит на передовой борьбы с такими проблемами?

[zyxman]

Я знаю, что эрланг нативно поддерживает ASN.1
Но, увы, в реальных протоколах связи с КА он не применяется. И я не знаю почему. Поэтому разбирать пакеты всё равно придётся ручками.

Насколько я понимаю, ASN.1 это стандарт описания протоколов, по сути то-же что BNF.
Не применяется вероятно потому что КА проектируют люди, которые не хотят далеко уходить от Си, и на Си все привыкли к BNF.

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

Вообщем вы сами признаёте что законченное решение будет в виде фарша из асма,  Си и эрланга.

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

Меня лично в Erlang/OTP (не сам язык, а язык+ВМ+библиотека OTP и прочий инструментарий и методология) больше всего радует технология всей работы.
А именно, что я могу сделать сначала всё так как мне быстрее разрабатывать или удобнее разрабатывать, а потом на ходу подменять модули например на оптимизированные или на лучше протестированные.
Я понимаю, это возможно жутковато выглядит, как для обсуждения ПО АМС, но реально как раз вся идеология Erlang/OTP буквально для того и сделана, чтобы дорабатывать программу прямо во время полета
И таким образом (СТАНДАРТНО поддерживая обновление ПО во время полета) идеология Erlang/OTP позволяет заметно увеличить доступное для разработки время.

Плюс, Erlang/OTP технология действительно эффективно работает с большими распределенными системами, позволяя исключительно эффективно обновлять код на тысячах нод.

[zyxman]

Как правило, ошибки в требованиях (ТЗ, если хотите). Но сделать реализацию, несоответствующую требованиям с теми же проблемами тоже, конечно, можно. Что должно вылавливаться на этапе тестирования, охват которого тоже определяется сильно задолго для реализации. В итоге мы возвращаемся в тех самых 90% случаях к самым ранним этапам процесса. Где ни инструментальные средства, ни тем более язык программирования столь горячо обсуждаемые на этой ветке не фигурируют.  А фигурируют стандарты на сам процесс.

Я правильно понимаю, что на базе некачественного ТЗ получается сильносвязанная система, которую сложно изменить/дополнить потом?

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

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

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

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

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

Да как сказать. Правильный язык разработки сам поддерживает определенный стандарт разработки. Скажем, если он требует указать точность, с которой должна вычисляться переменная, или допустимые пределы значений, то программист вынужден будет спросить их у  составителя ТЗ, даже если они в ТЗ не указаны. А составитель ТЗ включить голову и подумать, какими они должеы быть, дополнить ТЗ. А если язык не требует, то составитель не указал, программист запрограммировал с какой-нибудь точностью и диапазоном (как получилось) а потом на поздних этапах или тестировании выясняется, что все это не годится и надо переделывать. И хорошо если не в полете.

[zyxman]

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

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

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

[Not]

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

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

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

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

Пусть берет. Большая точность это не страшно, проблема когда меньшая. Если обеспечивается большая точность, то все норм.

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

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

[Not]

протестировать уже не представляется возможным

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

Только при условии корректного программирования. Достаточно ошибочно привести к более узкому типу и вы огребли проблем. Компилятор будет молчать - ему заткнули рот явным приведением типа. Однако тестер обязан это найти.  

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

протестировать уже не представляется возможным

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

Только при условии корректного программирования. Достаточно ошибочно привести к более узкому типу и вы огребли проблем. Компилятор будет молчать - ему заткнули рот явным приведением типа. Однако тестер обязан это найти.  

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

И тестировать это все-таки уже не нужно. Все проверяется компилятором.

[zyxman]

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

И тестировать это все-таки уже не нужно. Все проверяется компилятором.

Тут проблема, что нужно будет заранее просчитать все допустимые для ширины типа диапазоны входных значений. И это ОЧЕНЬ рутинный трудоемкий процесс, который тоже может принести ошибок.
Например, для y=x*x тип X должен быть более узким чем тип y. И если для такого простого случая можно действительно компилятором автоматически посчитать диапазоны, то для автоматизации более сложных случаев нужно либо ИИ либо тестирование.

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

[Not]

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

Да вы маньяк   Вы сейчас говорили о каком то реальном языке, или о желаемом?

И как вы, например, будете приводить вещественыый тип к целочисленному и наоборот?

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

Тут проблема, что нужно будет заранее просчитать все допустимые для ширины типа диапазоны входных значений. И это ОЧЕНЬ рутинный трудоемкий процесс, который тоже может принести ошибок.

Все вполне считается компилятором. Но думать и писать действительно надо больше, нежли программирование "абы как". Это плата за надежное ПО. Альтернатива - ПО с багами.

Например, для y=x*x тип X должен быть более узким чем тип y. И если для такого простого случая можно действительно компилятором автоматически посчитать диапазоны, то для автоматизации более сложных случаев нужно либо ИИ либо тестирование.

Тестирование не гарантирует отсутсвие багов.Оно гарантирует их наличие

Ну а даже если у вас этот самый IF поймал выход за пределы диапазона, что вы будете делать?

Реагировать в зависимости от задачи. Условный пример. Допустим, гироскоп выдает значение угла поворота от 0 до 360 градусов. Если мы получили значение вне этого диапазона, значит он неисправен. Нужно пометить его как неисправный и работать дальше на оставщихся гироскопах. Если это невозможно, перейти на ориентацию на звездных датчиках. Если опять невозможно то перейти в закрутку на солнце. Ну вобщем идея понятна, надеюсь