Хотелось бы узнать побольше про процесс создания космического софта и его отличия от софта обычного. Так, в порядке удовлетворения естественного любопытства :)
Особенно интересно почитать про обеспечение надежности, программно-аппаратные средства обнаружения отказов, резервирования и пр. а также методики отладки и верификации программ, в частности в контурах управления реального времени.
Буду особо признателен за ссылки на PDFы со всякими там протоколами, стандартами, спецификациями и пр. (люблю иногда почитать на сон грядущий) :)
Могу сказать несколько слов о софте наземном. Лет 18 назад отвечал от промышленности за математику одного из изделий на Байконуре. Перед этим участвовал в его создании.
Это частный случай, но видимо типичный для данной отрасли.
1. Допускается использование в составе изделия только вычислительных машин, имеющих соответствующую приемку. Реальная надежность вычислителей очень высокая. Это было практически единственное изделие из десятков, входивших в комплекс, по которому не вызывались гарантийщики.
2. «Начиняется» «голая» машина. Никаких операционных систем. Абсолютно все (в том числе весь обмен с внешним миром) делается «ручками».
3. Пишется на ассемблере. В нашем случае на ЕС был сделан имитатор вычислителя, там же писались программки и в итоге получались перфоленты для прошивки вычислителя.
4. Математика «зашивается» в вычислители намертво. Какие либо изменения могут быть сделаны только в заводских условиях перепрошивкой блоков памяти.
5. Для отладки вместо прошиваемых блоков используются наладочная память, связанная с ЕС либо закачиваемая с перфолент, по габаритам раз в десять превышающая сам вычислитель. Создается стенд с максимально возможным подключением к вычислителю внешних устройств.
6. Вычислитель имеет тестовую программу, прогоняемую при его включении. Проверяются все операции, результат сверяется с эталоном. Проверяется оперативная память несколькими видами тестов. «Прошитая» программа проверяется контрольным суммированием. При работе идет постоянный аппаратный тест на четность.
7. Обязательное «горячее» резервирование, когда две машины параллельно решают одну задачу. Весь ввод идет одновременно в обе машины. Вывод – из текущей выбранной. Переключение вывода происходит либо при обнаружении сбоя аппаратно, либо вручную с пульта управления системой. Кроме «горячего» резерва, естественно имеется «холодный» на всю аппаратуру.
8. Конечно, очень аккуратное программирование. Очень бережное отношение к памяти программной и оперативной, максимальное использование командных возможностей и методов адресации.
9. На каждое внешнее устройство, с которым взаимодействует вычислитель, с его разработчиками согласуется протокол информационного обмена. Далее - строжайшее следование протоколам.
10. Унификация программ, построение системы документирования. Алгоритм каждого программного модуля, его вход-выход, переменные описываются в «шапке». Никаких регламентаций этого процесса сверху не было. Все решалось и согласовывалось в своем коллективе. В итоге листинги программ были самой лучшей документацией в течение нескольких лет.
11. В результате, после нескольких лет разработки коллективом из пары десятков людей, на полигоне программы пошли с первого раза, прошли все испытания и практически в неизменном виде работали в «штатном» полете.
12. Наверное, самое главное в процессе создания математики большим коллективом людей и при «обширных» связях вычислителя с «внешним миром» – грамотный руководитель. Ну тут нам повезло.
С уважением, Михаил
Спасибо, Михаил.
Понятно. 18 лет - это все-таки много, тогда трава была зеленее, компьютеры проще а софт - надежнее :)
Аах перфолента, ах телетайп... (скупая непрошенная слеза :) )
Что конкретно интересует:
Существуют тонны всяких стандартов (ISO/ANSI/MIL-STD), методологий, рекомендаций и пр. призванных обеспечить качество софта. Из того что я видел на бумаге все это выглядит весьма разумно и поначалу приносит хорошие результаты. Но чем дальше в лес тем хуже, количество макулатуры и народу ее пищущее возрастает экспоненциально а потом наступает момент когда важные детали просто теряются в океане документации. Вот любопытно как люди выходят из положения.
Потом про тестирование и верификацию. Тут в соседнем топике народ мерялся у кого больше тестеров в команде :) А что они делают конкретно? Есть вещи которые принципиально нельзя протестировать, можно только доказать, типа отсутствие race conditions или гарантии на верхний предел времени выполнения функции при наличии прерываний. Применяются ли языки формальной верификации и какие?
Про железо. Если на земле машина вываливается по ошибке четности значит железо глючит. В космосе насколько я понимаю сбои отдельных битов - нормальное явление даже при абсолютно исправном железе. Как с этим боротся? Примерно понятно, код Хемминга, контрольные суммы, дублирование, контрольные точки, сторожевые собаки там всякие а еще что? Интересно например про реконфигурируемое железо.
Рекомендую вот эту книгу: http://www.ozon.ru/context/detail/id/1575081/
Хоть это и учебное пособие, но написано оно на примерах реальных систем, летающих в настоящее время. Разработки середины и конца 90-х г.г. Кроме того, эти разработки продолжаются и сейчас, так как в современных условиях задача полного перепрограммирования бортовых вычислительных систем - задача, пусть не тривиальная, но, тем не менее, уже почти рутинная.
Сходил по ссылке.
ЦитироватьС этим товаром часто покупают
Б. Акунин, Г. Чхартишвили
Кладбищенские истории
Том Питерс
Представьте себе! Превосходство в бизнесе в эпоху разрушений
Мрачный юмор какой-то....
тоже сходил...
Левадный В.С.
Прудовое разведение рыб и раков
хай-тек, мля :?
http://www.drofa.ru/index.php?show=catalog&name=167+%C0%E2%E8%E0%F6%
по этой ссылке книга "Полвека в авиации. Записки академика"
Написал Гендиректор ГосНИИАС акдемик Федосов Е.А.
Вопросами ПО, верификацией и т.д. он и занимался для ракет и авиации.
ЦитироватьСходил по ссылке.
ЦитироватьС этим товаром часто покупают
Б. Акунин, Г. Чхартишвили
Кладбищенские истории
Том Питерс
Представьте себе! Превосходство в бизнесе в эпоху разрушений
Мрачный юмор какой-то....
Честно говоря, я тоже не всегда понимаю логику "Озона", дающего такую, с позволения сказать, рекламу. Но в целом, магазин хороший. И книга, о которой я говорил, весьма пристойная. :)
Кое-что можете найти здесь:
http://www.cta.ru/RUBRIKI_KOSMOS.HTM
Вообще подход к конкретным решениям зависит от цены вопроса :D Например мы при разработке и изготовлении микроспутника остановились на банальной трехканальности с мажоритированием (правда с некоторыми ухищрениями - дополнительный независмый обмен между каналами с анализом отказов). Естественно была изготовлена КПА и написана программа испытаний, содержащая некий набор штатных и нештатных ситуаций , от которой не было отступлений ни на йоту :D
ИМХО, джентельменский набор должен состоять в первом случае из распределенной сети независимых устройств, позволяющих при отказе одного (или даже нескольких) устройств перераспределить его функции между оставшимися может быть с некотрой потерей быстродействия/функциональности (правда этот подход требует довольно большой избыточности).
Во втором случае система может состоять из двух или более каналов (может быть даже некоторые в холодном резерве), управляемыми (вкл/выкл) внешним диспетчером, реализованным на более простой (надежной) элементной базе, в задачу которого входит определение отказавшего канала и его выключение или замену на канал, находящийся в холодном резерве.
Есть еще решения, содержащие еще дополнительные каналы управления с ограниченной/минимальной функциональностью (но и повышенной надежностью), которые могут быть задействованы в случае отказа основной системы.
Ну, и на закуску, бывает особо впечатлительные ставят ко всему этому простейший резервный аналаговый контур управления :lol:
А на Буране стояла синхронная трехканальная система и четвертый канал в холодном резерве, но перевязки аппаратными мажоритарами по всем линиям (адреса, данных, управления) были после каждого функционального блока (ЦПУ, ОЗУ, Вв/Выв, ПЗУ).
Еще была такая старая книга:
http://proxy.math.rsu.ru/cgi-bin/library/card.ru?code=0000000000001S6&udk=&bbk=В681.3.06_а10&
Ага, вот поновее, того же автора:
http://books.dore.ru/bs/f1bid1748.html
А это - техника: http://www.computer-museum.ru/histussr/13.htm
Наша была А15А :D
Я припоминаю, в конце девяностых нам зарубежная фирма предлагала БЭВМ. Железо i386, i486 (это ещё ладно). Под управлением Windows :shock: :shock: :shock:
А кому это - "нам"? Какой организации?
ЦитироватьЯ припоминаю, в конце девяностых нам зарубежная фирма предлагала БЭВМ. Железо i386, i486 (это ещё ладно). Под управлением Windows :shock: :shock: :shock:
Для сведения: на американском сегменте МКС все бортовые управляющие компьютеры MDM используют процессоры i80386 20 МГц. И это НОРМАЛЬНО.
ЦитироватьА кому это - "нам"? Какой организации?
А Вы, часом, не шпиён будете?
ЦитироватьДля сведения: на американском сегменте МКС все бортовые управляющие компьютеры MDM используют процессоры i80386 20 МГц. И это НОРМАЛЬНО.
Естественно, это было не бытового исполнения, (хотя DEC'овская архитектура в данном девайсе мне представляется более уместной). Но вот WINDOWS...
ЦитироватьЕстественно, это было не бытового исполнения, (хотя DEC'овская архитектура в данном девайсе мне представляется более уместной). Но вот WINDOWS...
Какой такой DEC в конце девяностых? :) Вы Альфу имеете в виду, VAX или PDP/11? :) Intel конечно далеко не подарок для подобных вещей, у него ЕМНИП соотношение производительность/потребляемая мощность одно из худших в индустрии (по этому параметру ARM рулит) да и система команд и внешний интерфейс чересчур наворочены. Тогда уж скорей RISC какой-нибудь, MIPS или SPARC например.
Ну а про Windows - слов нет.
DEC загнулся намного позже. В это время мы ещё успели AlphaStation прикупить. И ничего машинка пахала. На своих 466 МГц делала П-3(1200) как стоячего.
Alpha и есть RISC. Для космоса она, конечно жарковата. Но вот какую-нибудь реинкарнацию VAX спец исполнения было бы здорово увидеть. Но не встречал.
Почему же у нас не использовали МСЦТ для меня тоже остаётся загадкой...
ЦитироватьЦитироватьНо вот WINDOWS...
Ну а про Windows - слов нет.
Гыгы :D А что Windows - гыг есть анекдот про клаву, кривые руки и винды. Не далеше 5 метров от меня стоит корневой сервак - проинстален в 2001 и что работает - пережил 2 блока питания и пару дисков - один из них загрузочный :D ( восстановили ради хохмы прямым копированием с битого - пару дополнительных манипуляций и заработал ...). Другое дело винды не годятся для систем реального времени...
Очень интересный материал по БЦВМ. Коротко и ясно. http://aviapanorama.narod.ru/journal/2003_2/bort.htm
А что Windows? Чем вам не нравится, скажем, Ebedded NT?
Если почитать литературу, представленную на ПЕРВОЙ странице данного топика, то вопросы, типа "чем не нравиться Windows?" отпадут сами собой. :wink:
Ещё одна странность, которая мне непонятна. Буржуи активно используют VxWorks, приспосабливая его к различному железу. У нас же (в России) каждый раз на практически идентичном железе занимаются осестроительством. Мне лично были известны три такие реализации (хотя это и не совсем моя специализация).
ЦитироватьЕсли почитать литературу, представленную на ПЕРВОЙ странице данного топика, то вопросы, типа "чем не нравиться Windows?" отпадут сами собой. :wink:
Ещё одна странность, которая мне непонятна. Буржуи активно используют VxWorks, приспосабливая его к различному железу. У нас же (в России) каждый раз на практически идентичном железе занимаются осестроительством. Мне лично были известны три такие реализации (хотя это и не совсем моя специализация).
Потому что ума много, да по делу использовать не можем...
И как результат - российские аппараты теряются по дороге, а буржуи успешно перепрограммируют заглючивший марсоход...
ЦитироватьЕсли почитать литературу, представленную на ПЕРВОЙ странице данного топика, то вопросы, типа "чем не нравиться Windows?" отпадут сами собой. :wink:
Ещё одна странность, которая мне непонятна. Буржуи активно используют VxWorks, приспосабливая его к различному железу. У нас же (в России) каждый раз на практически идентичном железе занимаются осестроительством. Мне лично были известны три такие реализации (хотя это и не совсем моя специализация).
На РС МКС VxWorks - штатная операционная система бортового комплекса управления.
Спасибо, Вы меня обнадёжили.
Кстати, и главные бортовые компьютеры там - трехканальные транспьютеры с процессорами архитектуры SPARC.
А кто автор изделия?
ЦитироватьА кто автор изделия?
EADS
Всё же буржуи... Жаль... А ведь могли же...
Софт в основном наш. Буржуйский только firmware и часть низкоуровневого софта.
ЦитироватьМогу сказать несколько слов о софте наземном. Лет 18 назад отвечал от промышленности за математику одного из изделий на Байконуре. Перед этим участвовал в его создании.
Это частный случай, но видимо типичный для данной отрасли.
Похоже, очень похоже на правду :) При всём уважении к авторам успешных проектов, всё описанное за исключением укладывающегося в инженерный здравый смысл -- это голос из могилы. Всё делается так, что система "кашлянуть боится". Всё на ассемблере, все протоколы для всего уникальные, компы допотопные даже на момент разработки, т.к. делались такими же методами. Это тихий ужас. Вполне недавние достижения этих методов -- марсоходы, которым не доверяли самим ездить ПО ПУСТЫНЕ, причём сам марсоход вполне способен переехать практически любое вообразимое в пустыне препятсвие. На каждые 10 проеханных метров собирается консилиум и изучаются фотки всего вокруг чтобы детище каким-то макаром не споткнулось о непредвиденную "софтом" песчинку. Управление электротележкой в пустыне производится по сложному радиоканалу с Земли!... вот они достижения и повод для профессиональной гордости :) Всё это к тому, что не стоит смотреть на это как на хрестоматийный образец. Этот подход пережил свою мотивацию на не один десяток лет, но людей переучить иногда просто невозможно, особенно при власти.
Статья (http://www.fastcompany.com/online/06/writestuff.html) о методике создания софта для шаттла.
ЦитироватьСтатья (http://www.fastcompany.com/online/06/writestuff.html) о методике создания софта для шаттла.
ЦитироватьThe most important things the shuttle group does -- carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code -- are not expensive.
Ха! "Не надо лохматить бабушку" (с) :)
Подскажите, ест ли подобной софт для Андроид или IOS?
https://software.nasa.gov/software/GSC-17177-1
Цитата: STC от 18.05.2005 15:17:50http://www.drofa.ru/index.php?show=catalog&name=167+%C0%E2%E8%E0%F6%
по этой ссылке книга "Полвека в авиации. Записки академика"
Написал Гендиректор ГосНИИАС акдемик Федосов Е.А.
Вопросами ПО, верификацией и т.д. он и занимался для ракет и авиации.
Как бы почитать с экрана можно здесь
Н (https://homeread.net/read/polveka-v-aviacii-zapiski-akademika-evgeniy-fedosov?page=10#tx)е по делу, но для моделирования (модели ракет) есть страница NASA
https://www1.grc.nasa.gov/beginners-guide-to-aeronautics/rocketmodeler/
Не знаю - толковый или нет. По рекомендации:
https://www.instructables.com/Make-Your-Own-Model-Rocket/
Цитата: ДмитрийК от 22.05.2005 12:08:20The most important things the shuttle group does -- carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code -- are not expensive.
"никаких изменений без вспомогательных чертежей" ? ? ?
Бррр... Какие еще "вспомогательные чертежи" у ПО ? Блок-схемы что-ли ?
Цитата: au от 22.05.2005 10:50:15Вполне недавние достижения этих методов -- марсоходы, которым не доверяли самим ездить ПО ПУСТЫНЕ, причём сам марсоход вполне способен переехать практически любое вообразимое в пустыне препятсвие.
Ага нужно " Cybertruck" тесловский со стандартным шоссейным авто-пилотом послать...
(Ирония если что) Да кто-же против ! Как только получиться доставлять Марс марсоходы хотя-бы десятками в год так сразу и доверят и самим пустыне ездить и по горам лазить. А пока каждый марсоход на Марсе будет по цене "своего веса в калифорнии"(
стоимость одного грамма калифорния примерно 27 млн долларов ) все так и останется.
Цитата: Алексей Кириенко от 11.08.2025 23:01:07Цитата: ДмитрийК от 22.05.2005 12:08:20The most important things the shuttle group does -- carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code -- are not expensive.
"никаких изменений без вспомогательных чертежей" ? ? ?
Бррр... Какие еще "вспомогательные чертежи" у ПО ? Блок-схемы что-ли ?
Ответить на сообщение 2005 года в 2025-м - это ли не некропостинг? ;D
Цитата: Наименьший квадрат от 15.08.2025 17:12:52Цитата: Алексей Кириенко от 11.08.2025 23:01:07Цитата: ДмитрийК от 22.05.2005 12:08:20The most important things the shuttle group does -- carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code -- are not expensive.
"никаких изменений без вспомогательных чертежей" ? ? ?
Бррр... Какие еще "вспомогательные чертежи" у ПО ? Блок-схемы что-ли ?
Ответить на сообщение 2005 года в 2025-м - это ли не некропостинг? ;D
Чудеса движка и происки роскомпозора. Бывает при просмотре непрочитанных сообщений отправляет в прошлое. ;D
Цитата: Алексей Кириенко от 11.08.2025 23:01:07Цитата: ДмитрийК от 22.05.2005 12:08:20The most important things the shuttle group does -- carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code -- are not expensive.
"никаких изменений без вспомогательных чертежей" ? ? ?
Бррр... Какие еще "вспомогательные чертежи" у ПО ? Блок-схемы что-ли ?
Интересно, что я данную тему в прошлом не видел.
Если кому интересно, могу просветить. Для начала есть презентация.
https://www.youtube.com/watch?v=5ZmSnqZUl9Y
И публикация http://ubs.mtas.ru›upload/library/UBS3914.pdf
Цитата: TAU от 16.08.2025 12:20:56Цитата: Алексей Кириенко от 11.08.2025 23:01:07Цитата: ДмитрийК от 22.05.2005 12:08:20The most important things the shuttle group does -- carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code -- are not expensive.
"никаких изменений без вспомогательных чертежей" ? ? ?
Бррр... Какие еще "вспомогательные чертежи" у ПО ? Блок-схемы что-ли ?
Интересно, что я данную тему в прошлом не видел.
Если кому интересно, могу просветить. Для начала есть презентация.
https://www.youtube.com/watch?v=5ZmSnqZUl9Y
И публикация http://ubs.mtas.ru›upload/library/UBS3914.pdf
М-да, «как всё запущено»! «Система визуального программирования «Дракон» — нет слов! Нет, во времена «Бурана» это была футуристическая по самое не могу разработка из будущего... Но сейчас? (И даже в 2014-м) Вспоминать эту поделку?? Серьезно????! Народ, у меня нет слов!
У еще бы HiASM вспомнили (https://hiasm.com), кстати, ХайАсм на два порядка свежее, и то уже загибается от старости. Но главное там то, что всё, что генерируется по «коду-схеме», часто совершенно нестабильно и не слишком предсказуемо.
Нет, получить приемлемый результат можно.
(Пример рабочей программы-схемы на ХайАсме)
(https://img.novosti-kosmonavtiki.ru/384957.jpg) (https://ibb.co/5NrxwRk)
Но гарантий нет, и это врожденное свойство подобных систем.
(Дело в том, что у них полно нигде не документированных причуд и крайне неявных особенностей, и да, схемы «супер-визуальных» сред разработки — это близко не алгоритм.)
P. S.
Кстати, вроде уже когда-то обсуждал тут (на форуме) что-то подобное.
P. S. P. S.
"И публикация.." Не открывается .
Цитата: Наименьший квадрат от 15.08.2025 17:12:52Ответить на сообщение 2005 года в 2025-м - это ли не некропостинг? ;D
Упс ! Не заметил . Но тема интересная и поднять ее будет неплохо.
Например в свете использования ИИ и прочих нейросетевых технологий .
Цитата: Алексей Кириенко от 18.08.2025 11:08:121. М-да, «как всё запущено»!
2. «Система визуального программирования «Дракон» — нет слов! Нет, во времена «Бурана» это была футуристическая по самое не могу разработка из будущего... Но сейчас? (И даже в 2014-м)
Вспоминать эту поделку?? Серьезно????! Народ, у меня нет слов!
3. У еще бы HiASM вспомнили (https://hiasm.com)
4. (Дело в том, что у них полно нигде не документированных причуд и крайне неявных особенностей, и да, схемы «супер-визуальных» сред разработки — это близко не алгоритм.)
5. "И публикация.." Не открывается .
1. Вы просто не в теме. В порядке инструменты и в штатной эксплуатации. Уже на протяжении долгих лет.
2. См. пункт первый. И если есть претензии к языку - высказывайте по существу.
3. HiAsm - что приятно, наша отечественная система. В моей книге по визуальным языкам упоминается. Но к космосу отношения не имеет. Вот поэтому в ней и присутствуют "странности". В система "на космос" все жестко контролируется и отлаживается, включая инструменты. Никакого непредсказуемого поведения.
4. Схема алгоритма его вполне себе задает. Будете спорить?
5. Здесь попробуйте https://cyberleninka.ru/article/n/puti-povysheniya-nadezhnosti-i-kachestva-programmnogo-obespecheniya-v-kosmicheskoy-otrasli
Цитата: TAU от 18.08.2025 17:10:011. Вы просто не в теме. В порядке инструменты и в штатной эксплуатации. Уже на протяжении долгих лет.
Надеюсь что вы правы. (Просто я несколько лет назад стакивался с "Драконом", то что он надежнее того-же HiАsm-а несомненно, но уровень разработки в плане поддержки современных инструментов и методик показался мне чудовищно низким )
Основная суть проблемы "супер-визуального" программирования и прочих кейс-сред разработки что их внешняя наглядность иногда достигается крайне непрозрачными методами.
Например HiАsm внутри сильно напоминает Lisp то есть по сути это прямо-таки идеальное воплощение идей функционального программирования (бесконечный ряд вложенных вызовов функций и внутри других функций передаваемых в качестве параметра ) Пока схема относительно проста это вполне работает но стоит ей прейти некую границу сложности, как моментально возникают совершенно дикие фокусы (вроде "неявного кольцевания" (со срывом стекка ) и сбоя последовательности выполнения операций ) Особую драматичность ситуации придает то что обычно о подобных проблемах и сложностях в документации нет не слова. (все примеры успешно работают, а то что это не будет работать в действительно сложной программе никто разумеется не проверит )
Нет если набраться опыта то преодолеть особенности "зеро-кодинга" и супер-визуального программирования частично возможно, но гарантий того, что сложная программа не будет "зависеть от фазы Луны и отраженного света Венеры " гораздо меньше чем при классическом программировании.
(у "классики" существенно меньше "зазор" между кодом, алгоритмом его реализаций и скрытыми неявными условиями эксплуатации )
Зы
Сейчас я не более чем "кустарно практикующий программирование любитель-дилетант". Так что разумеется ни на какую истину любой инстанция я претендовать не могу
Цитата: TAU от 18.08.2025 17:10:014. Схема алгоритма его вполне себе задает. Будете спорить?
Тут разумеется спорить не о чем. Но во первых я писал о другом, а во вторых если честно слабо представляю как можно показать в "классической схеме алгоритма" например множественное наследование классов или дженерики. (Хотя признаю что это немного "уход в сторону" от поставленного вопроса ) Вообщем я пытался сказать что сейчас часто входит так что или "схема-не-алгоритм"(отображение объектов, классов,потоков данных очень трудно засунуть в каноническую схему ) или "алгоритм-не-схема" ( как минимуму не "одномерная разветвленная последовательность на плоскости " ).
Суть в том в наше время часто даже простое описание чисто математической методики приходится сопровождать не схемой или математической формулой , а такой странной сущностью как пресловутый "псевдо-код" бо иначе ничего описать невозможно .
Цитата: Алексей Кириенко от 19.08.2025 02:20:49Цитата: TAU от 18.08.2025 17:10:014. Схема алгоритма его вполне себе задает. Будете спорить?
Тут разумеется спорить не о чем. Но во первых я писал о другом, а во вторых если честно слабо представляю как можно показать в "классической схеме алгоритма" например множественное наследование классов или дженерики. (Хотя признаю что это немного "уход в сторону" от поставленного вопроса ) Вообщем я пытался сказать что сейчас часто входит так что или "схема-не-алгоритм"(отображение объектов, классов,потоков данных очень трудно засунуть в каноническую схему ) или "алгоритм-не-схема" ( как минимуму не "одномерная разветвленная последовательность на плоскости " ).
Суть в том в наше время часто даже простое описание чисто математической методики приходится сопровождать не схемой или математической формулой , а такой странной сущностью как пресловутый "псевдо-код" бо иначе ничего описать невозможно .
Ваши "множественное наследование" и "дженерики" в программировании "на космос" практически не применяются. Из-за излишней сложности и связанных с ней опасностей. Просто - значит надежно!
А дополнительная информация в самых разных видах, само собой, при визуальном программировании в космической отрасли используется. Даже изначальный ГРАФИТ-ФЛОКС состоит из двух частей в названии не случайно.
Цитата: Алексей Кириенко от 19.08.2025 00:36:56Цитата: TAU от 18.08.2025 17:10:011. Вы просто не в теме. В порядке инструменты и в штатной эксплуатации. Уже на протяжении долгих лет.
Основная суть проблемы "супер-визуального" программирования и прочих кейс-сред разработки что их внешняя наглядность иногда достигается крайне непрозрачными методами.
Нет если набраться опыта то преодолеть особенности "зеро-кодинга" и супер-визуального программирования частично возможно, но гарантий того, что сложная программа не будет "зависеть от фазы Луны и отраженного света Венеры " гораздо меньше чем при классическом программировании.
1. Для космоса стараются не доводить до слишком "сложных" программ. Используется декомпозиция.
2. Инструменты для разработки "на космос" сами по себе проходят более качественную проверку, нежели в коммерческом ширпотребе.
3. Построенные программы проходят многостадийную отладку на НОК.