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

[TAU]

Факт в том, что 99% программистов программируют кодом, а не рисуют и для этого есть причины. И причина вовсе не в том, что производители КА прогрессивнее, чем коммерческий мейнстрим

Причина в том числе - именно в этом.

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

Всего лишь ваша личная субъективная точка зрения.

Кстати самый известный алгоритмист – Дональд Кнут писал алгоритмы на MIX/МMIX ассемблере – язык, который он создал специально для обучения алгоритмам в своей серии книг Искусство программирования и он в предисловии писал почему он решил так, а не использовал языки выокого уровня или блоксхемы

Не напомните? И, кстати, какое это имеет отношение к БПО для КА?

[LRV_75]

Мужики, а можно вопрос? Вы для каких КА ПО разрабатываете (разрабатывали). Ну там, для Персоны? Или АМС Фобос-Грунт?

[jettero]

Всего лишь ваша личная субъективная точка зрения.

Разумеется
а вы что, претендуете на то, что ваша точка зрения не субъективна?

[jettero]

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

P.S. Современные графические нотации типа UML - это не просто блок-схемы. Их функционал гораздо шире.

Согласен с тем, что диаграммы иллюстрирующие концептуальный уровень и структуру полезны в ООП (наследование, зависимости). Я писал об этом на прошлой странице и про системы документирования кода типа javadoc/doxygen, где это используется.

Но тут дискуссия идет не про эти диаграммы, а про именно программирование только блоксхемами (язык Дракон). TAU утверждает, что это самый прогрессивный способ программирования, я не согласен.

[zyxman]

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

Вам уже ответили ;-)

Спасибо, но это не совсем то что я хотел услышать.

Если БВС используется для решения задач управления БА, и почти не используется для вычислений - то вполне хватает скромных показателей.

Насколько скромных?
- Можно выразиться в байтах и операциях в секунду?

И интересны не чисто задачи включения/выключения оборудования по времени, а именно какие-то вычислительные задачи.

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

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

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

[TAU]

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

Не надо демагогией заниматься - приписывать оппоненту то, чего он не говорил. Это первое.

Второе - идет разговор, вообще-то, не только о графическом программировании, еще есть кое-какие прогрессивные методы, используемые при создании БПО для КА.

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

[TAU]

Насколько скромных?
- Можно выразиться в байтах и операциях в секунду?

Внимательнее смотрите Была же ссылка на ЦВМ-101, применяемую на "Союзе" и "Прогрессе".

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

Неверное впечатление. Логика не примитивная. Кстати, будучи "помноженной" на время, она становится вообще даже сложной.

[jettero]

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

Не надо демагогией заниматься - приписывать оппоненту то, чего он не говорил. Это первое.

Да неужели? Значит мне приснилось

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

например?

Графическое программирование в системе ГРАФИТ-ФЛОКС, в НПЦ АП. Которое даже его автор В.Д. Паронджанов называет несколько провокационно "программированием без программистов".

Факт в том, что 99% программистов программируют кодом, а не рисуют и для этого есть причины. И причина вовсе не в том, что производители КА прогрессивнее, чем коммерческий мейнстрим

Причина в том числе - именно в этом.

Исходя из ваших сообщений сложно не понять, что для вас графическое программирование самое прогрессивное. Так что про демагогию не надо )

Второе - идет разговор, вообще-то, не только о графическом программировании, еще есть кое-какие прогрессивные методы, используемые при создании БПО для КА.

Не знаю о чем вы думаете идет разговор, но когда я спросил, что вы имеет в виду под "ну даже очень современные средства разработки" вы сказали только про ГРАФИТ-ФЛОКС (сиречь язык Дракон)

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

Ага и несмотря на это большинство пишет код, а не рисует блоксхемы и вы даже не замечаете тут логической нестыковки. А, я знаю – вместо того, чтобы подумать почему так, вы для себя объяснили это тем, что мейнстрим "отсталый".
Тогда можно задать следующий вопрос, допустим мейнстрим такой отсталый, почему же тогда большинство разработчиков КА не используют Дракон, а пишут "по старинке" – кодом? Насколько я помню историю Дракона, его разработка ведется порядка 10 лет, если не больше, так что времени на переход на него было предостаточно.
Сейчас еще вспомнилось, мне эта дискуссия напоминает тему – что лучше: командная строка или графическая оболочка. Почему-то начинающие пользователи предпочитают окна, а сисадмины командную строку, наверное потому что они тоже отсталые, а нубы прогрессивнее

[jettero]

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

Примерно так и есть, в этой ветке несколько раз были ссылки на примеры программ для КА, в том числе ЕМНИП я постил ссылки на листинги программ лунных модулей.
Логика простая, вычисления простейшие, ну это и понятно – это вытекает из требований по надежности ПО.

[jettero]

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

Неверное впечатление. Логика не примитивная. Кстати, будучи "помноженной" на время, она становится вообще даже сложной.

Не очень понятно, что значит "логика помноженная на время"? Вы имеете в виду время работы программы? Вот у меня один вебсервер 3 года без перезагрузки работает, из этого следует, что там очень сложная логика?

[ДалекийГость]

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

Примерно так и есть, в этой ветке несколько раз были ссылки на примеры программ для КА, в том числе ЕМНИП я постил ссылки на листинги программ лунных модулей.
Логика простая, вычисления простейшие, ну это и понятно – это вытекает из требований по надежности ПО.

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

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

[jettero]

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

Да не вопрос, эта задача можно сказать классическая, давно изученная. Я даже нашел книжку Токаря за 78 год с формулами управления гиродинами.
Какова оплата и на чем требуется написать? Раз мы серьезно подошли к делу, давайте я серьезно напишу, только оплата часа работы у меня по европейским расценкам, предупреждаю сразу
PS Кстати, если вы не поняли, то "простейшие вычисления и логика" относились к итоговой программе которая на борту (и это требование надежности - чем проще программа, тем меньше в ней багов), а не к матаппарату, на котором строится алгоритм.
Например сильно утрируя, но управление можно реализовать и на тупой и простой машине состояний – и тогда там даже процессора может не быть. А все сложные расчеты и решения будут сделаны заранее и в машине состояний будут уже готовые решения на все случаи.
По-любому как ни старайся сложную логику и серьезный матапарат в 2 мегабайта бортового ЗУ не вместишь  :wink:

[ДалекийГость]

эта задача можно сказать классическая, давно изученная. Я даже нашел книжку Токаря за 78 год с формулами управления гиродинами.

А гравитация "давно изученна" Галилеем. Ньютону и Энштейну уже ничего не осталось.

Какова оплата и на чем требуется написать? Раз мы серьезно подошли к делу, давайте я серьезно напишу, только оплата часа работы у меня по европейским расценкам, предупреждаю сразу

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

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

[Not]

По-любому как ни старайся сложную логику и серьезный матапарат в 2 мегабайта бортового ЗУ не вместишь  :wink:

Ну да, после того как вы туда впихнете CLR, для прикладного ПО мало что останется  :lol:

[JoJo]

По-любому как ни старайся сложную логику и серьезный матапарат в 2 мегабайта бортового ЗУ не вместишь  :wink:

[MikeP]

По-любому как ни старайся сложную логику и серьезный матапарат в 2 мегабайта бортового ЗУ не вместишь  :wink:

А как Вам система управления воздушным движением авиаполка на Аргоне-10М? Не серьезно?
32К команд.

А на двух Аргонах-15А тоже по 32К каждый КДП "Бурана"?

[jettero]

эта задача можно сказать классическая, давно изученная. Я даже нашел книжку Токаря за 78 год с формулами управления гиродинами.

А гравитация "давно изученна" Галилеем. Ньютону и Энштейну уже ничего не осталось.

Какова оплата и на чем требуется написать? Раз мы серьезно подошли к делу, давайте я серьезно напишу, только оплата часа работы у меня по европейским расценкам, предупреждаю сразу

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

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

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

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

[ДалекийГость]

И я не говорил, что это "несерьезная работа"

Вы согласились с тем, что в ПО КА нет " серьезной работы для программиста-математика".

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

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

а теперь сравните с объемом кода в современной ОС

Любая работа занимает все отведенные под нее ресурсы. Кто-то говорит - "Заговор!", а я говорю - "Фундаментальный закон природы!"

Я же привел пример с машиной состояний

Я деликатно промолчал, но если Вы настаиваете...

Посчитаем количество состояний в предложенной мной задаче. Для плоскости "крен-курс" имеем два угла, две проекции угловой скорости, две проекции накопленного кин. момента - 6 скаляров. Это минимум. Для простоты примем, что для каждого ткущего состояния нет влияния прошлых состояний. Ограничимся очень скромными двумя десятичными разрядами для каждого скаляра. Получаем количество состояний равным 10 в 12-й степени.

в машине состояний будут уже готовые решения на все случаи"

Ага, миллион миллионов готовых решений.

[TAU]

Посчитаем количество состояний в предложенной мной задаче. Для плоскости "крен-курс" имеем два угла, две проекции угловой скорости, две проекции накопленного кин. момента - 6 скаляров. Это минимум. Для простоты примем, что для каждого ткущего состояния нет влияния прошлых состояний. Ограничимся очень скромными двумя десятичными разрядами для каждого скаляра. Получаем количество состояний равным 10 в 12-й степени

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

Ну и теперь добавим время - поясню для jettero, что я имел в виду.

Надо теперь число полученных состояний помножить на число различимых БЦВМ моментов времени. Ну, скажем, допустим, тактовый генератор на борту с частотой так раз 100 в секунду. И все переменные, отражающие состояние бортовых систем, внешней среды, памяти, и пр., могут в общем случае принимать в каждый из этих моментов разные значения.
И надо помножить число состояний еще на число всех тактов за все время активного существования КА.

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

[ITop]

На тему графического представления:

Пытался ли хоть один Web-программист отладить программу, которую нельзя остановить, потому что она уже управляет множеством непрерывных процессов ? Как отладить работу системы управления без объекта управления ? - писать эмулятор объекта, его матмодель и т.п. Удовольствие не из дешёвых.

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

Касательно сложности программ управления:

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

Я писал и обычные приложения, по типу офисных программ (диагностическая часть для обычного ПК) и программы управления роботизироваными сварочными комплексами. И ответственность в этих случаях просто несравнимая. Единственная ошибка в коде управления модет привести к поломке дорогостоящего оборудования (сотни тысяч евро) или даже к травмам и смерти рабочего персонала.

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

Угробить КА, думаю, нисколько не сложнее чем другое сложное оборудование, только вот возможности починить не будет.