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

[Frontm]

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

Простые юзеры будут управлять КА? :shock:

[LRV_75]

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

Простые юзеры будут управлять КА? :shock:

Да, брат мой! И не только ими, но и нами с тобой. Ты этого еще не замечаешь?

[Frontm]

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

Простые юзеры будут управлять КА? :shock:

Да, брат мой! И не только ими, но и нами с тобой. Ты этого еще не замечаешь?

Ах, вот почему всё так криво :shock:
Оказываются мы юниты в комьютерной игре, а нами рулят ламеры-геймеры

[Morin]

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

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

В каких вузах изучают вновь проектируемые КА? ;-) А если к моменту окончания вуза этот проект закроют, а начнут новый? А если выпускник поедет в другой город и в другое КБ? :-)
Вы, наверное, имели в виду изучают КА - вообще, абстрактно. Это да! В некоторых вузах изучают, но не будущие программисты. :-( Да им такие знания и не помогут, разве что помогут быстрее изучит конкретный новый КА.

[Morin]

Или ..., тыкая мышкой по сайту

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

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

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

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

[ITop]

В тему можно ещё вспомнить системы управления промышленными объектами, производственными линиями, станками, роботами и т.д.

Большая часть из них пишется либо на языках низкого уровня, наподобие asm (с современными оболочками для разработки) с применением специальных языков высокого уровня, а точнее языков функциональных блоков.

Часто такие системы управления разграничивают:

Собственно атоматическое управление - на низком уровне.
Визуализация - на высоком (хоть С++, хоть Бэйсик)

Знание конкретного языка для программиста СУ - не самое важное. Важнее обычно знание объекта управления, опыт проектирования и отладки СУ. Часто бывает, что программист лучше всех знает объект  :wink:

Зная 3-4 языка и столько же сред разработки и сделав несколько проектов, изучить ещё одну среду и язык - дело даже не недель, а дней. Реальные случаи - проект делался за 2-3 недели вместе с изучением нового языка, новых стандартов ПО, не считая собственно нового оборудоавния.

Обычным же, "оффисным" программистам, могу посоветовать не спорить с СУ-шниками, предварительно не сделав хотя бы один рабочий проект.  :wink:

[JoJo]

Или ..., тыкая мышкой по сайту

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

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

... Все будет наглядно и осизаемо для простого юзера

Такого не будет никогда :-) ...

А ведь к этому потихоньку  и идет, посмотрите хотя бы на это:
(это про спутник за шесть дней - не нашел здесь топика)
http://www.ll.mit.edu/HPEC/agendas/proc08/Day1/4-Lyke-Presentation.pdf
И про междупланетный интернет - тема была, но на всякий случай:
http://www.ipnsig.org/reports/DTN_Tutorial11.pdf

[zyxman]

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

Простые юзеры будут управлять КА? :shock:

Конечно будут, но см выделенный кусочек :wink:

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

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

[Дем]

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

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

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

Не следует путать "управление процессами в реалтайме" и "управление реалтаймовыми процессами". Если первое действительно сложно (хотя про онлайн-игры через интернет я думаю всем известно), то второе проблем не представляет.

[Morin]

Знание конкретного языка для программиста СУ - не самое важное. Важнее обычно знание объекта управления, опыт проектирования и отладки СУ. Часто бывает, что программист лучше всех знает объект  :wink:

  :wink:

А вот это очень верно. Часто молодые программисты, приходя в контору, свысока смотрят на опытных разработчиков. Потому что те не знают современных языков и сред программирования и, вообще, занимаются написанием каких-то непонятных-ненужных бумажек. Молодые программисты не хотят изучать матчасть: "Зачем? Ведь я же ПРОГРАММИСТ?"
Насчет того, что программист лучше всех знает объект.  Бывает, но не часто. Обычно такой программист изначально не был программистом, а был обычным инженером-механиком, -электриком, -управленцем. Программирование он осваивал уже зная объект и в приложении к объектам. Хотя бывают и исключения. Знаю программиста изначально совершенно не знавшего, не только КА. но и вообще, любые железки. Но в процессе работы досконально изучившим матчасть и теперь могущий подсказывать не только программистам, но и инженерам системщикам. Даже  более опытным. Но такие случаи - исключение. Обычно инженеры говорят: "Проще самому изучить язык и написать программу, чем объяснить программисту, что от него требуется".

[Frontm]

Обычно инженеры говорят: "Проще самому изучить язык и написать программу, чем объяснить программисту, что от него требуется".

Зачастую самому просто банально дешевле. При нашем скудном финансировании заказать что-то на стороне нереально.
Так что не от хорошей жизни всё это. Часто бывает что вместо долгой разработкти ТЗ и согласований - быстрее самому.
Но одно но, всё это касается наземки. Для борта ПО должны писать только профессиональные программисты.

[LRV_75]

Обычно инженеры говорят: "Проще самому изучить язык и написать программу, чем объяснить программисту, что от него требуется".

Зачастую самому просто банально дешевле. При нашем скудном финансировании заказать что-то на стороне нереально.
Так что не от хорошей жизни всё это. Часто бывает что вместо долгой разработкти ТЗ и согласований - быстрее самому.
Но одно но, всё это касается наземки. Для борта ПО должны писать только профессиональные программисты.

надеюсь их у Вас еще осталось! Кстати, внутреннее ТЗ еще никто не отменял

[TAU]

В тему можно ещё вспомнить системы управления промышленными объектами, производственными линиями, станками, роботами и т.д. Большая часть из них пишется либо на языках низкого уровня, наподобие asm (с современными оболочками для разработки) с применением специальных языков высокого уровня, а точнее языков функциональных блоков

Ну, МЭК включает целый набор языков подобного программирования, не только "функциональных блоков" - Functional Block Diagram, FBD - кстати, неплохо бы еще отметить, что этот язык - графический, то есть речь идет о визуальном программировании, т.е. на уровне выше, чем ЯВУ, те же Си или Ада. LD - тоже графический.

Да и для написания на ассемблере, скажем, для контроллеров Atmel существует система графического программирования Algorithm Builder.

[TAU]

Обычно инженеры говорят: "Проще самому изучить язык и написать программу, чем объяснить программисту, что от него требуется"

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

Например, именно такова система ГРАФИТ-ФЛОКС, созданная В. Паронджановым и его коллегами в НПЦ АП имени Пилюгина и успешно примененная, например, в проекте "Морской старт".

[TAU]

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

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

Не надо обманывать студентов

Я, вообще-то, об объеме программ на Коболе говорил.

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

Как раз таки "обычно" - т.е. если не притягивать "за уши" результаты и не пользоваться специальными приемчиками, то и будет 10 раз.

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

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

Вы неправы. Хотите поспорить - приведите пример "удаленной модернизации скриптового ПО" на КА.

[TAU]

посмотрите хотя бы на это:
(это про спутник за шесть дней - не нашел здесь топика)
http://www.ll.mit.edu/HPEC/agendas/proc08/Day1/4-Lyke-Presentation.pdf

Нда. Сначала воспринимается, как чистая фанастика, потом читаешь дальше - и удивляешься.

Правда, пока это только "игрушки"-малышки. Но принцип...

[zyxman]

Правда, пока это только "игрушки"-малышки. Но принцип...

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

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

[Not]

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

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

[zyxman]

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

И да и нет.

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

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

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

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

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

Кстати, если можно, скажите, в каких областях вы сейчас видите явную потребность в увеличении квалификации программистов от переделки ПО на параллельные алгоритмы?
В смысле где оно требует серьезных усилий?

[LRV_75]

Обычным же, "оффисным" программистам, могу посоветовать не спорить с СУ-шниками, предварительно не сделав хотя бы один рабочий проект.  :wink:

обычный оффисный программист как Вы меня верно назвали в бытность свою работы в РКО написал АСУ ТП включения и контроля Системы Измерения РН ТОПОЛЬ-М (ШАХТНЫЙ ВАРИАНТ) И РН СОЮЗ-2. Которые до сих пор эксплуатируются