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

[yos]

Блииин, ну при чём всякие явы, xml, и другие вещи к ПО КА? Я уже давно заметил, что многие люди пытаются распространить мир персональных ЭВМ в мир космонавтики, авиации и т.д. Это совершенно разные вещи, которые связаны лишь очень общими принципами, суть которых лишь в том, что и там и там -- ЭВМ и они "работают на программах". И всё.
Идеи "использовать" в бортовых ЭВМ, например, javascript, c# и проч. так же, как они были задуманы и реализованы в мире ПЭВМ (а главное для чего!), необдуманные и просто наивные (без обид). О том, почему это так, можно столько говорить, что я даже не знаю где начать... Хорошее начало -- осознать, что мир ПО персональных ЭВМ и мир бортовых ЭВМ это совсем разные области.

[yos]

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

Значит это не классические факультеты, а ПТУ... То что вы назвали, а также многие другие "специфические методы математики" на самом деле совсем не специфические, а стандартные части науки информатики. К тому же ещё и довольно банальные (динамическое программирование), по сравнению с другими темами (теоретической) информатики. Впрочем, этот вопрос уже обсуждался в этой теме.

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

Ну наконец-то пошли здравые мысли!  

[LRV_75]

Блииин, ну при чём всякие явы, xml, и другие вещи к ПО КА? Я уже давно заметил, что многие люди пытаются распространить мир персональных ЭВМ в мир космонавтики, авиации и т.д. Это совершенно разные вещи, которые связаны лишь очень общими принципами, суть которых лишь в том, что и там и там -- ЭВМ и они "работают на программах". И всё.
Идеи "использовать" в бортовых ЭВМ, например, javascript, c# и проч. так же, как они были задуманы и реализованы в мире ПЭВМ (а главное для чего!), необдуманные и просто наивные (без обид). О том, почему это так, можно столько говорить, что я даже не знаю где начать... Хорошее начало -- осознать, что мир ПО персональных ЭВМ и мир бортовых ЭВМ это совсем разные области.

так вы наверняка правы! Вот и объясните почему?

[Дем]

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

Контрольная сумма там на канальном (tcp) уровне

Ответы типа "весь мир пишет на 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

Дистрибутив Вин7 в распакованном виде - 10 гигабайт бинарников. если одна строка кода компилируется в 100 байт бинарного - то это 100 млрд строк. Один продукт равен половине всей коблятины.

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

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

вы потратите в 5-10 раз больше энергии

Основную часть энергии жрёт не процессор, а передатчики и прочие моторы

Обсуждать XML вообще не имеет смысла, вследствие его совершенно безумной избыточности.

Про Binary XML слышал? Фича XML в стандартизации передачи данных - переданный блок понятен без каких-либо дополнительных усилий, вся информация о содержимом находится в нём же.

[jettero]

Смешались в кучу кони, люди...
Что-то читаю и никак не пойму, почему тут на полном серьезе обсуждают javascript и http для КА. Оба этих зверя не имеют применения за пределами вебстраниц чуть менее, чем полностью. Или кто-то предлагает поднять на спутнике вебсервер и управлять им через веб интерфейс, тыкая мышкой по сайту
Тогда да, яваскрипт (кстати никакого отношения к яве не имеющий) может пригодится для анимации меню например
Я бы еще мог понять если бы речь шла только про TCP/IP (хотя тоже не совсем в тему, вроде пока задача строить сеть на спутниках не актуальна), но HTTP???  :?  :shock:

[zyxman]

Ну наконец-то пошли здравые мысли!  

А меня это заумное рассуждение просто веселит. Поэтому иногда "подкидываю дровишек" :lol:

[PyKaB]

Я конечно в космосе нифига не понимаю - зарегистрировался почитать, но свои пять копеек сюда вставлю про яву.
1. Во-первых Java ооочень быстрая http://kano.net/javabench/data
2. Позволяет очень удобно реализовывать изолированные процессы
3. Как уже было замечено, язык всего лишь инструмент в существующих технологиях написания ПО и Java подходит для написание устойчивого ПО больше, чем большинство языков
4. Java никогда не запустят в роли жизнено важной системы, т.к. для начала надо полностью доверится пока еще динамично развивающийся среде выполнения

[TAU]

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

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

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

Точно, я об этом и писал.

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

Блестяще сказано и по сути!

[yos]

так вы наверняка правы! Вот и объясните почему?

А что именно интересует? А то так много было сказано.

[zyxman]

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

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

[jettero]

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

[LRV_75]

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

воооот!!! я вот так хотел бы а почему бы и нет? Очень красиво и наглядно будет! Так в  итоге кстати и будет . . . У них

[PyKaB]

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

Блестяще сказано и по сути!

Не надо обманывать студентов. Разница есть, но обычно меньше 5-10 раз и актуально это для первого запуска программы.
А вот проблемы удаленной модернизации ПО скриптовые языки позволяют решить намного легче

[Morin]

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

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

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

ампанского, вы верите? :-(

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

Я рад, что еще не везде победил воинствующий дилетантизм :-(
А СШГЭС - это пример победы дилетантов над специалистами.

[Morin]

LRV_75 писал(а):

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

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

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

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

Что разработчик БПО должен еще хорошо знать сам КА, а этому, уж точно ни в каких вузах не учат.

Вообще-то учат.

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

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

воооот!!! я вот так хотел бы а почему бы и нет? Очень красиво и наглядно будет! Так в  итоге кстати и будет . . . У них

Управление процессами в реальном времени через web-сервер? Выдаете желаемое (вами) за действительное. Уже даже и не смешно  :cry:

[LRV_75]

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

воооот!!! я вот так хотел бы а почему бы и нет? Очень красиво и наглядно будет! Так в  итоге кстати и будет . . . У них

Управление процессами в реальном времени через web-сервер? Выдаете желаемое (вами) за действительное. Уже даже и не смешно  :cry:

весь мир идет по пути коммерциализции и удобства пользования. Примеров даже приводить не надо. Подойдите к терминалу в москве и купите билет в Большой театр и Вам покажут место где вы будете сидеть. Вот Вам и wеb сервис. Тоже самое и здесь. Все будет наглядно и осизаемо для простого юзера

[Frontm]

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

Спасибо за то, что сказали про этот нюанс