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

[zyxman]

Да эти утопические рассуждения не ведут никуда.

Именно эти что вы комментировали действительно никуда не ведут.
Потому что они есть не что иное как вариант "раньше трава была зеленее".

Если так пойдет, то единственным логичным эволюционным исходом станет внедрение все более современных технических средств, которые позволят иметь и окошки, и реальное время  одновременно. И проблема будет решена. Не идеально, но реально :lol:

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

[bs]

Проблема в том, что окошки тут обсуждаете вы.

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

[avp]

По поводу Си же можно лишь пожалеть.

Тут можно ответить известным афоризмом:

"There are only two kinds of programming languages: those people always bitch about and those nobody uses."

[bs]

The Mars Science Laboratory (MSL), to be launched in 2011. MSL is a compact car size rover, developed at the Jet Propulsion Laboratory. It is programmed in more than 3 million lines of code (including auto-generated code), more than the combined code onboard all previous Mars missions together. This trend in software growth is expected to continue also for future Mars missions, making it a challenge to apply traditional formal methods. The system is highly multi-threaded with approximately 160 threads. It is programmed in C by a team of 30+ programmers. The system is tested by a team of 10+ testers. Testing is complicated by the fact that the programming team has little time for activities not directly related to development of new software, and hence cannot be disturbed too much by a testing effort. This prevents for example an approach based on new test-specific code instrumentation, be it automated or not. In addition, the system is difficult to execute due to its tight connection with hardware. This makes test-input generation and multiple automated re-runs a challenging task.

Источник: "Runtime Verification: 9th International Workshop, RV 2009"

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

[Wishbone]

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

Сколько человек из числа разработчиков СПО в НПОЛ ездило на международные конференции по верификации ПО и другим формальным методам?  :roll:

[avp]

Один из самых важных моментов:

It is programmed in C by a team of 30+ programmers. The system is tested by a team of 10+ testers.

С таким коллективом можно действительно серьёзно развернуться.

[Vladimir]

Сколько человек из числа разработчиков СПО в НПОЛ ездило на международные конференции по верификации ПО и другим формальным методам?  :roll:

Не задавайте глупых вопросов, поскольку ответ очевиден: они выше этого.

[bs]

Сколько человек из числа разработчиков СПО в НПОЛ ездило на международные конференции по верификации ПО и другим формальным методам?  :roll:

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

И смысл не в том, что в НПОЛ делали так или не так - у них свои проблемы и ограничения. Смысл в том, что это логичное направление развития в разработке таких систем. Пора уже отложить ставшие родными циклограммы в сторону :wink:

С таким коллективом можно действительно серьёзно развернуться.

Тут можно поспорить, а упоминание "серебряной пули" было бы наконец к месту

[Ded]

bs пишет:
 

И смысл не в том, что в НПОЛ делали так или не так - у них свои проблемы и ограничения. Смысл в том, что это логичное направление развития в разработке таких систем. Пора уже отложить ставшие родными циклограммы в сторону :wink:

С таким коллективом можно действительно серьёзно развернуться.

Тут можно поспорить, а упоминание "серебряной пули" было бы наконец к месту

Хорошо, отложили "родные" циклограммы, и что?

[Ded]

Wishbone , извитите, я удалил больше чем хотел. Это вопрос к  bs.

[Vladimir]

Хорошо, отложили "родные" циклограммы, и что?

Как что? "Мы пойдем другим путем". Ну и получили искомый результат. К слову сказать, циклограмма участка выведения на отлетную траекторию в КИСе ни разу не прошла без замечаний. А мы еще удивляемся, почему это ФГ не улетел к Марсу, и все ссылаемся: то двигатель не включился (как будто он сам включается), то короткое замыкание (наверно, от сырости), то проблемы в системе электроснабжения. "Чем кумушек считать трудиться..."
Да, конечно, технические решения могут быть самыми разными, но технология создания и отработки КА нарабатывалась десятилетиями, и еще никто не смог ее опровергнуть. Вот и создателям ФГ это не удалось, как они ни старались доказать, что старый опыт надо выбросить, а у них есть новые подходы.
Первый такой подход мы наблюдаем благодаря NORAD. Надеюсь, что второго подхода им не дадут, иначе новых российских АМС наше поколение просто не дождется.

[zyxman]

Эмм. Вообще-то это был первый раз, когда я упомянул окошки.

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

[bs]

технология создания и отработки КА нарабатывалась десятилетиями, и еще никто не смог ее опровергнуть.

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

[TAU]

Могу поздравить себя, т.к. я все-таки был ближе всего к реальности  

К какой? Действительность - она везде разная.

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

Кстати, по поводу действительности

Пора уже отложить ставшие родными циклограммы в сторону :wink:

Что за бред?

Циклограммы убрать в космической отрасли?

Вы сами понимаете, что пишете?

[TAU]

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

Настоятельно просим подробности в студию!

[Unispace]

Вся мишура, которая тут выдается высокими программистами, лакмусируется очень просто. Спрашиваем у них - вы ГОТОВЫ написать ПО для ФГ так, как вы считает правильным, считая, что вознаграждение вас достойно, а не трендеть ? И все. Очень много воды, но реальность состоит в том, что написать сложное embedded  ПО с RTOS - это не рассказывать басни про эрланги, это намного сложнее. Если мне скажут судьи кто, и зададут такой же вопрос, то я был бы готов не стушеваться и поучаствовать в проекте, технически. Но организационно  -  нет.

[TAU]

Тут можно ответить известным афоризмом:

"There are only two kinds of programming languages: those people always bitch about and those nobody uses."

А я позволю себе повторить ранее высказанное:
в отрасли применялись и применяются с успехом и другие языки программирования высокого и сверхвысокого уровней, в частности:
- Ада
- Java
- Модула-2
- HAL/S
- ПРОЛ2
- ГРАФИТ-ФЛОКС
Могу высказать предположение, что и Джовиаль используется/использовался.

[bs]

Что за бред?

Циклограммы убрать в космической отрасли?

Вы сами понимаете, что пишете?

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

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

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

По отдельным факторам Си будет бесспорно проигрывать. Но в стройной методологии разработки он может быть и не самым плохим выбором.

[TAU]

VDM тоже чистый функциональный подход

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

[zyxman]

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

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