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

[LRV_75]

а интерфейс к нему так же стандартизирован и способ, скорость передачи и хранения информации?

[Дем]

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

Конечно есть. От и до. Например минимальная ширина импульса двигателя ориентации станции New Horizons 5 миллисекунд.

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

Маниловщина какя-то.
А вы представляете себе хотя бы приблизительно объём работ по портированию CLR на другую ОС да ещё и ОС РВ и последующей сертификацией этого ПО? CLR - это ведь не только интерпретатор байткода, но и весь run-time. Несколько миллионов строк кода. И кто это это будет писать и отлаживать? Какой заказчик? НПОЛ? ВНИИЭМ? ИСС? И на какие деньги?

Во-первых - никакой "другой ОС". Вся ОС пишется на ЯВУ внутри CLR. На ассемблере только интерпретатор и классы работы с аппаратурой (прерывания, приём-передача байтов), вся более сложная логика - опять же на ЯВУ.
run-time опять же нужен весьма ограниченный, да и на ЯВУ он гораздо легче пишется и проверяется.

Вам приходилось наблюдать по ТМИ во время полёта, как тяжелые частицы выбивают ячейки памяти и искажают их содержимое? Зрелище не для слабонервных. При объеме ОЗУ 1-2 Мбайт еще можно обеспечить программную защиту от сбоев, ресурсов хватает. А при десятках мегабайт?

Применение ЕСС даёт неплохой результат. При чтении DVD ошибки в каждом секторе почти гарантированны, но это никому не мешает.

по косвенным сведениям мелькающим в сети, создается впечатление, что радиационно-стойкие комплекты чипов по возможностям находятся где-то в диапазоне 386-486 процессоров. А при таких параметрах о каких возможностях можно говорить.

Этого вполне достаточно. Самой тяжёлой части - обработки видео - от них не требуется.

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

Применение ЕСС даёт неплохой результат. При чтении DVD ошибки в каждом секторе почти гарантированны, но это никому не мешает.

Потеря одного фрейма в MPEG2 никому ничем не грозит. А искажение поля признаков подключения аппаратуры в нужное время может и бед наделать.

[zyxman]

то что используется во всем jаvа sсriрt, visuаl, стандарт xml, протоколы http и https с сертификатами (вот и передавайте по ним кадры Тми), базы sql servеr и пр. На этом работает весь мир.

Ну что вы так человеку крылья режете?
- Как по мне, так пусть использует xml, javascript итд!
- Только подальше от меня :lol:

[Дем]

Потеря одного фрейма в MPEG2 никому ничем не грозит. А искажение поля признаков подключения аппаратуры в нужное время может и бед наделать.

А как оно может исказиться, если или будет скорректировано по ЕСС или запрошено повторно за несовпадением контрольной суммы?

[TAU]

то что используется во всем jаvа sсriрt, visuаl, стандарт xml, протоколы http и https с сертификатами (вот и передавайте по ним кадры Тми), базы sql servеr и пр. На этом работает весь мир.

Можете привести примеры использования того, что Вы перечислили, в бортовых комплексах управления КА?

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

Но по сути, конечно, Вы правы.

[TAU]

По пунктам:

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

Зуб даете? Уверены? Если да - то напрасно.

Но не знаю, можно ли этих людей называть делитантами? Я думаю что нет

Назыавать дЕлИтантами точно нельзя.
Дорогие форумчане, ну давайте все же уважать немного наш язык. А то прямо глаз режет. "Делитанты", елки-палки... Сначала один написал, потом второй повторяет за ним. Правитльно: дИлЕтанты. Да и как писать правильно ТСЯ и ТЬСЯ в глаголах неплохо повторить.

[Дмитрий Виницкий]

Какая Java? С гвоздя упали? Там VxWorks 5.3.1 Mars Exploration Rovers Edition.

[TAU]

Не знаю как там сейчас в Самаре

Уже писали.
Кстати, я когда писал о средствах более высокого уровня, имел в виду вовсе не С#.

Красноярске

Модула-2+Спец.языки.

Москве

По-разному. :lol:

в NASA вопросам надежности бортового ПО уделяется первостатейное внимание

В перечисленных наших городах - абсолютно то же самое.

БПО проходит многоступенчатый процесс отладки. В том числе - с узлами реальной БА.

[TAU]

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

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

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

так и

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

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

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

[TAU]

Какая Java? С гвоздя упали? Там VxWorks 5.3.1 Mars Exploration Rovers Edition

Каким образом ОС может мешать языку?
Учите матчасть.

Слышал я, что именно Java. Нельзя, конечно, исключить полностью, что это было какое-то искажение журналамерское.
Вот, кстати, можно интересненькое почитать по теме:
http://ti.arc.nasa.gov/m/profile/dimitra/publications/sei2003.pdf

[TAU]

И к сожалению в ближайшие годы изменений не предвидется

Смотря с какой точки зрения смотреть...  Кстати, правильно пишется: предвидИтся, простите.

ИМХО Самарские не серийные КА уходят в историю

Не дождутся (С).

[KBOB]

то что используется во всем jаvа sсriрt, visuаl, стандарт xml, протоколы http и https с сертификатами (вот и передавайте по ним кадры Тми), базы sql servеr и пр. На этом работает весь мир.

Можете привести примеры использования того, что Вы перечислили, в бортовых комплексах управления КА?

да я по наземке такого не встречал, а Вы воворите КА! Сидим все в каменном веке. Не используються современные технологии. Кодируют, декодируют ТМИ кадр. Во! Орбиту еще придумали! Почему его кадр тми нельзя прямым кодом передать кай нттрs запрос? Потому что используем убогие программно аппаратные средства, не поддерживающие современне стандарты

Если ТМИ кадр будет передан с ошибками, что произойдет?  :wink:

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

Ничего не вернется  :lol: в протоколе http даже передачи контрольной суммы нет. Ошибочный тми кадр по протоколу hhtp будет воспринят как правильный. Уныло вообщем дело обстоит.

[zyxman]

Какая Java? С гвоздя упали? Там VxWorks 5.3.1 Mars Exploration Rovers Edition

Каким образом ОС может мешать языку?
Учите матчасть.

Слышал я, что именно Java.

Очень может быть что Java применяется на наземном сегменте в некритичных частях (с которых мы регулярно наблюдаем обработанные картинки, и регулярно-же материмся насчет задержки этих картинок), а для компьютера ровера Java тяжеловата, да и недостаточно надежна - там Модула-2 самое-то.

[zyxman]

Ничего не вернется  :lol: в протоколе http даже передачи контрольной суммы нет. Ошибочный тми кадр по протоколу hhtp будет воспринят как правильный. Уныло вообщем дело обстоит.

Все с http нормально - вообще TCP/IP рассчитан на вероятность искажения бита не хуже 10^-6 (одна миллионная), а соответственно уже для http вероятность искажения вообще не нормируется.
А если хочется надежной передачи, то можно кроме проверки целостности данных и исправления ошибок на канальном уровне просто использовать https или какой-то другой протокол с шифрованием и/или с жесткой проверкой - там уже очень строгая проверка и по искажению данных и по искажению идентификатора передающей стороны.

[KBOB]

Ничего не вернется  :lol: в протоколе http даже передачи контрольной суммы нет. Ошибочный тми кадр по протоколу hhtp будет воспринят как правильный. Уныло вообщем дело обстоит.

Все с http нормально - вообще TCP/IP рассчитан на вероятность искажения бита не хуже 10^-6 (одна миллионная), а соответственно уже для http вероятность искажения вообще не нормируется.
А если хочется надежной передачи, то можно кроме проверки целостности данных и исправления ошибок на канальном уровне просто использовать https или какой-то другой протокол с шифрованием и/или с жесткой проверкой - там уже очень строгая проверка и по искажению данных и по искажению идентификатора передающей стороны.

Вообще http согласно модели OSI протокол уровня приложения, а TCP/IP протоколы транспортного и сетевого уровней. Приложение у нас передает кадры ТМИ, но раз уж было предложено использовать для их передачи http как протокол уровня приложения, то вы решили  на транспортном и сетевом уровне использовать TCP/IP.
Вы за одно опишите что у вас за протоколы будут работать на канальном уровне и на физическом и посмотрим как все это заработает в в сети из 4-х узлов (два марсохода, один марсианских орбитер, наземная станция связи).

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

Ничего не вернется  :lol: в протоколе http даже передачи контрольной суммы нет. Ошибочный тми кадр по протоколу hhtp будет воспринят как правильный. Уныло вообщем дело обстоит.

Все с http нормально - вообще TCP/IP рассчитан на вероятность искажения бита не хуже 10^-6 (одна миллионная), а соответственно уже для http вероятность искажения вообще не нормируется.
А если хочется надежной передачи, то можно кроме проверки целостности данных и исправления ошибок на канальном уровне просто использовать https или какой-то другой протокол с шифрованием и/или с жесткой проверкой - там уже очень строгая проверка и по искажению данных и по искажению идентификатора передающей стороны.

Вообще http согласно модели OSI протокол уровня приложения, а TCP/IP протоколы транспортного и сетевого уровней. Приложение у нас передает кадры ТМИ, но раз уж было предложено использовать для их передачи http как протокол уровня приложения, то вы решили  на транспортном и сетевом уровне использовать TCP/IP.
Вы за одно опишите что у вас за протоколы будут работать на канальном уровне и на физическом и посмотрим как все это заработает в в сети из 4-х узлов (два марсохода, один марсианских орбитер, наземная станция связи).

Добавьте к этому еще специфические каналы связи, с весьма несиметричными полосам пропускания.

[Not]

Какая Java? С гвоздя упали? Там VxWorks 5.3.1 Mars Exploration Rovers Edition

Каким образом ОС может мешать языку?
Учите матчасть.

Слышал я, что именно Java.

Очень может быть что Java применяется на наземном сегменте в некритичных частях (с которых мы регулярно наблюдаем обработанные картинки, и регулярно-же материмся насчет задержки этих картинок), а для компьютера ровера Java тяжеловата, да и недостаточно надежна - там Модула-2 самое-то.

Выдержка из интервью с Гослингом о роли Java в ПО марсоходов:

The Mars Mission Continues

In this Q&A with James Gosling, find out more about the role of Java in the Mission to Mars and download your own version of the Maestro application or go to java.com to learn more.

Friday Jan 16, 10:00 AM PT

Q:What exactly is Java's role in the Mars Rover mission?

A: The places where NASA scientists have used Java for this mission is all on the ground side right now. They have created this collaborative command and control system called Maestro, which does this combination of data visualization, collaboration, command and control. It lets them look at images and create 3-D reconstructions of terrain. It allows various experimenters to look at the scenes and topography, browse the image databases and take part in all the participation they need to do. And to do it in a remote, distributed and collaborative kind of way - so they could actually have scientists at institutions all over the world who are not only looking at the data, but also collaboratively deciding on the way the mission should proceed. One of the nice things that the JPL guys have done is that they've made a "cleaned up for civilians" version of this application available that's called Maestro.

И далее:
http://www.sun.com/aboutsun/media/features/mars.html

[Not]

то что используется во всем jаvа sсriрt, visuаl, стандарт xml, протоколы http и https с сертификатами (вот и передавайте по ним кадры Тми), базы sql servеr и пр. На этом работает весь мир. Придшего молодого программиста можно сразу обучать особенностям КА, а не каким то неведомым языкам низкого уровня

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

Вообще, всем любителям Java и JVM, C# и CLR и им подобным интерпретиреуемых языков и виртуальных машин, я бы рекомендовал в первую очередь задуматься над двумя вопросами - 1. почему именно интерпретируемый язык? и 2. сколько это будет стоить?

Ответы типа "весь мир пишет на C# (или на Java)" не принимаются. Вы будет удивлены, но большая часть программ в мире написана на Коболе.

In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually

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

Таким образом, единственно принимаемый аргумент в пользу Java или С# - концептуальная чистота объектно - ориентированного языка, плюс некоторые достоинства интерпретируемой программы, такие как динамическая идентификация операторов и т.д. Однако, давайте разберемся, какой ценой мы получим эту чистоту? Интерпретация предполагает наличие интерпретатора между кодом и процессором. т.е. количество тактов процессора, требуемых для исполнения того или иного оператора вашего кода нужно умножить на некоторый коэффициент. Вот величина этот коэффициента и есть та цена, которую вы заплатите. Поскольку увеличение количества тактов процессора отражается в увеличенном потреблении ценнейшего ресурса на борту КА - энергии. Известно, что хорошие интерпретируемые программы исполняются в 5-10 раз медленнее хороших компилируемых. т.е. вы потратите в 5-10 раз больше энергии того же скудно освещаемого марсохода, или энергии радиоизотопного термоэмиссионного генератора АМС.

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

[LRV_75]

Ничего не вернется  :lol: в протоколе http даже передачи контрольной суммы нет. Ошибочный тми кадр по протоколу hhtp будет воспринят как правильный. Уныло вообщем дело обстоит.

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