На чем пишется софт для КА?

[zur]

Как тут много умных вещей (это не ирония) написано, блин. Вот 20 лет пишу ПО для авиации и космонавтики, а многих слов таких и не слышал :-(

[ssb]

Вот 20 лет пишу ПО для авиации и космонавтики...

На чём?  

[zur]

Вот 20 лет пишу ПО для авиации и космонавтики...

На чём?  

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

И насколько проще делать под ДОС, чем под QNX - отличные компиляторы, отладчики и редакторы, полно документации, почти всё можно отладить на бытовых компах, а для доступа к памяти выше мегабайта есть несколько вполне приемлемых способов.
А работа с QNX напомнила мне VAX/VMS конца 80-х годов... весьма надежно, но поистине, прошлый век.

[zur]

Вот 20 лет пишу ПО для авиации и космонавтики...

На чём?  

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

[А.Коваленко]

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

Возможность то есть, писать не многие могут. А те кто могут, по большей части, бортами  не занимаются.
А по поводу СИ, в Самаре все уже очень весело, до слёз.
Не возможно грамотно закодить новый борт на новом языке, когда годами от изделия к изделию ВЕСЬ!!! софт писался в основном copy + paste с минимальными доработками.  Конечно есть очень грамотные специалисты-энтузиасты, но их крайне мало. И к сожалению в ближайшие годы изменений не предвидется. ИМХО Самарские не серийные КА уходят в историю.
кто-то очень умный сказал :"В болоте лилии не растут..."

Тут вы преборщили, конечно, :-( "ВЕСЬ!!! софт писался в основном copy + paste с минимальными доработками", далеко не все можно скопировать со старых изделий.
Беда с программированием в СИ не в этом. Практически невозможно будет найти причины ошибок ПО в полете. А ошибки неизбежны даже у самых квалифицированных программистов. А сейчас таковые в большом недостатке (те которые не просто умеют программировать, но и знают ЧТО программировать). Так вот, сейчас все достаточно прозрачно - такие-то данные кладутся в такую-то ячейку, а такие-то в такую... И всегда можно посмотреть почему в такой-то ячейке не то число, что надо. При программировании в СИ такой возможности не будет. И очень вероятно, что исправные КА будут выходить из строя по вине ПО и программисты ничего исправить не смогут.

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

Верно. Есть примеры успешной реализации и многолетней лётной эксплуатации сложнейшего бортового ПО для КА, написанного на C.

[Morin]

Я не брежу :-) . Я, вообще, - непрограммист. Я транслирую отзывы людей, которые этим делом занимаются много лет. Им, полагаю, виднее.

 Не хочу показаться грубым, но быть может ваши знакомые программисты слишком много лет занимаются программированием и отстали от жизни? Ведь перестраиваться, как известно, никто не любит...
С СИ дела обстоят совершенно не так, как Вы написали. Все целиком и полностью зависит от квалификации разработчика. Впрочем, как и при использовании ЛЮБОГО языка.

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

[ssb]

Спасибо zur за ответ!

В защиту Morin'а скажу что он вовсе не бредит а говорит прописную истину -- есть эффективные, пригодные для написания ядра операционной системы (и при этом небольшие, в отличие от ada/java/c#) языки программирования в которых целый класс Сишных ошибок просто невозможен за отсутствием арифметики указателей и доступа в память по произвольному адресу вообще, например Oberon.

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

[Not]

Спорить можно бесконечно, давайте посмотрим на факты:

Приложение ............................... Кол.во строк ....... Язык
----------------------------------------------------------------------
Mars Reconnaissance Orbiter.............. 545 тыс. .............. С
F-22 ............................................. 2.5 млн ................ Ада
Б-777............................................ 4 млн ................... Ада
Б-787............................................ 7 млн ................... Ада
F-35 ............................................. 19 млн...................С/С++


Всякую древность типа Вояджеров приводить смысла нет, прогресс давно уже ушел вперед от ассемблера. Не знаю как там сейчас в Самаре, Красноярске или Москве, а в NASA вопросам надежности бортового ПО уделяется первостатейное внимание. Бортовое ПО КА находится в той же категории что и ПО атомных станций, хим. заводов, военных систем раннего предупреждения, самолетов. Соответственно и отношение к программированию. Формальная верификация сейчас один из основных инструментов. Можно сколько угодно приводить в пример опыт прошлых лет, где все было в ДОСе, медленно, неторопливо и последовательно, но времена изменились.

[zur]

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

[А.Коваленко]

Ну хорошо, написали и отладили на Паскале. А есть компиляторы Паскаля для бортовых машин? Или используете кросс-компиляцию?

[Not]

Ну хорошо, написали и отладили на Паскале. А есть компиляторы Паскаля для бортовых машин? Или используете кросс-компиляцию?

В принципе (безотносительно к работе zur-а) существуют трансляторы из Паскаля в Си. Другое вопрос, существуют ли сертифицированные трансляторы?

[A. Petrov]

Ну хорошо, написали и отладили на Паскале. А есть компиляторы Паскаля для бортовых машин? Или используете кросс-компиляцию?

Странный вопрос. Только кросс-компиляцию. Не будете же вы запускать транслятор на бортовой машине? Так же, как и для всех DSP и/или микроконтроллеров.

[A. Petrov]

Формальная верификация сейчас один из основных инструментов

Вот это правильно! Только вот, как Вы сами заметили, для многих задач/языков эта задача в принципе неразрешаемая. Но это всегда хорошо всё проверить в статике.

Другой путь - unit testing. Функциональность критического бортового ПО достаточно ограничена - всегда можно поддерживать батарею юнит-тестов, покрывающую всю фукциональность.

[Werno]

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

Естественно. Программировать надо на том языке, на который имеются специалисты. Реализация системного софта возможна и на ассемблере, и на паскале, и на СИ и на прочих. Просто очень страннослышать, когда кто-то обязательно говорит что-то такое: "А вот этот язык лучше чем этот"   Сразу виден непрофессианализм... Просто кто-то умеет работать в одной среде, а кто-то умеет в другой. Если конечным результатом является софт с требуемым качеством, то какие вообще могут быть вопросы? И как можно утверждать, как в последних сравнениях, что вот  для этого Паскаль лучше чем СИ? Понятно еще, если человек скажет: на СИ я этого не делал, мне он кажется неудобным для этого, я привык в Паскале, где все у меня работает.
А то получается что говорит косвенно, что вот все дураки в организациях, где на СИ пишут, давно бы на Паскаль надо...
Это очередной берд и необъективный подход к вопросу. Если имеется личный опыт, так и надо говорить про личные предпочтения, а не обощать сразу.

[А.Коваленко]

Что-то меня смущает вот этот пассаж:

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

Это что, в самом деле?

[Not]

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

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

Реализация системного софта возможна и на ассемблере, и на паскале, и на СИ и на прочих.

А где вы видели драйверы на Паскале? А с указателями в Паскале работать приходилось? Понравилось?

Сразу виден непрофессианализм...

ПрофессиОнализм, с вашего позволения

Просто кто-то умеет работать в одной среде, а кто-то умеет в другой. Если конечным результатом является софт с требуемым качеством, то какие вообще могут быть вопросы? И как можно утверждать, как в последних сравнениях, что вот  для этого Паскаль лучше чем СИ? Понятно еще, если человек скажет: на СИ я этого не делал, мне он кажется неудобным для этого, я привык в Паскале, где все у меня работает. обощать сразу.

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

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

[LRV_75]

а не пробуют еще переходить на С шарп из Visiаl studio 2008? По моему очень удобный инструмент

[A. Petrov]

а не пробуют еще переходить на С шарп из Visiаl studio 2008? По моему очень удобный инструмент

Ага, и весь CLR с собой на орбиту тащить? И как вам сборка мусора, которая запустится в самое неподходящее время? Да и вообще эта штука летает только на Intel-e и под Windows. А как же наши ЦВМ-101 и прочие R-500, E2K, 1879ВМ2, 1892ВМ4Я?

[LRV_75]

а не пробуют еще переходить на С шарп из Visiаl studio 2008? По моему очень удобный инструмент

Ага, и весь CLR с собой на орбиту тащить? И как вам сборка мусора, которая запустится в самое неподходящее время? Да и вообще эта штука летает только на Intel-e и под Windows. А как же наши ЦВМ-101 и прочие R-500, E2K, 1879ВМ2, 1892ВМ4Я?

а может нафиг наши цвм и проче p500. Современные микро рс работают на проссорар интел и имеют достарочные ресурсы для установки ос хр и даже 7. Шарп очень удобен для разработке и фактически залючается в правильной настройке классов и ни какого гемора с памятью, указателями и проче, да и все общение с внешним миром идет через езернет, usв в крайнем случае ком порт. Для общения с ними давно все сделано и отлажено на уробне классов языков. Не нужно напрямую никаких портов, адресов, прерываний. Т.е. Давно не надо лезть на низкий уровень - это первопричина сбоев

[Not]

а не пробуют еще переходить на С шарп из Visiаl studio 2008? По моему очень удобный инструмент

Ага, и весь CLR с собой на орбиту тащить? И как вам сборка мусора, которая запустится в самое неподходящее время? Да и вообще эта штука летает только на Intel-e и под Windows. А как же наши ЦВМ-101 и прочие R-500, E2K, 1879ВМ2, 1892ВМ4Я?

а может нафиг наши цвм и проче p500. Современные микро рс работают на проссорар интел и имеют достарочные ресурсы для установки ос хр и даже 7. Шарп очень удобен для разработке и фактически залючается в правильной настройке классов и ни какого гемора с памятью, указателями и проче, да и все общение с внешним миром идет через езернет, usв в крайнем случае ком порт. Для общения с ними давно все сделано и отлажено на уробне классов языков. Не нужно напрямую никаких портов, адресов, прерываний. Т.е. Давно не надо лезть на низкий уровень - это первопричина сбоев

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

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