Системы управления и БЦВМ советских и российских МБР, РН, РБ и КА

[thunder26]

Старый пишет:

SOE пишет:

Старый пишет:
А какую функциональность добавляет компьютерная техника в штатной ситуации?

Старый, кончайте флудить.

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

Формулировка "снижение массы и энергопотребления" вас устроит?

[Старый]

thunder26 пишет: 
Формулировка "снижение массы и энергопотребления" вас устроит?

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

[thunder26]

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

Иногда бывает, что каждый килограмм на счету. Дело же не в цифровых или аналоговых системах, дело в замене аппаратной реализации (цифровой или аналоговой) на программную.
Раньше у нас, например, был такой прибор как БУ СОС, который принимал аппаратные данные от датчиков СОС и реализовывал ориентацию КА. Сейчас алгоритмы управления реализованы в БПО СОС в БЦВК, а датчики передают данные по одному кабелю 1553 и БЦВК "управляет" маховиками и двигателями ориентации. Итог - минус один прибор и ворох кабелей. Кроме этого, при орбитальных проверках, перед сдачей КА, достаточно просто программно "покачать" аппарат по тангажу и крену для проверки ЭИИМ ПН в зоне покрытия. Не знаю насколько просто это было сделать при аппаратной ориентации и можно было бы вообще.
Это только для примера.

[dmitryskey]

С другой стороны, Старый прав вот в каком смысле. Несмотря на повальную компьютеризацию, мы не получаем прорывов в авиационной и космической технике. Сколько там дало прироста ПН терминальное управление в Протоне-М - 10%? И так везде - огромные средства тратятся на бортовое ПО и суперкомпьютеры для той же аэродинамики - и где прорыв от, скажем DC-3 к Boing-707 и потом к Конкорду?

Разве что посадки первой ступени Falcon-a в голову приходят - тут целиком заслуга бортового ПО.

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

[Not]

opinion пишет:
Из статьи на kholeg я понял, что команда в НАСА сильна тем, что использует систему управления версиями, баг-трекер, перекрестную проверку кода и хорошее тестовое покрытие. То есть всё то, что есть у проектов с открытым кодом. Разница только в том, что у НАСА 100 тестеров, а у обычного ПО - сто миллионов. Отсюда и разница в количестве обнаруженных ошибок.

Статья пафосная и бестолковая, равно как и бестолковые ваши выводы о ней. Управление версиями, баг-трекеры и прочее тестирование есть у любой промышленной фирмы, это как набор напильников у слесаря. А вот методы и инструменты более серьезные могут позволить себе немногие, поскольку они предполагают значительно более высокую квалификацию инженеров, все равно что слесаря обучить работе на установке ядерно-магнитного резонанса, для поиска микродефектов. Речь о формальном анализе кода, о котором в вышеупомянутом опусе ни слова, но который тем не менее широко но без особого шума применяется в NASA, в частности в JPL.

Качество открытого кода - типичное заблуждение. Сто миллионов глаз не способны разглядеть баг в сложном коде, поскольку зачастую лишь единицы в состоянии его понять, если он достаточно запутан. Классический пример из недавних - дефект Heart Bleed в библиотеке openssl. Критическую ошибку допустил один из разработчиков под новый год, и, в течении двух лет ее никто не замечал. Где были ваши 100 миллионов глаз? Когда наконец на нее наткнулись, прослезились, поскольку пришлось заменить ПО на сотнях тысяч серверов, перевыпустиь миллионы кредитных карточек и т.д.

[opinion]

Not пишет:

opinion пишет:
Из статьи на kholeg я понял, что команда в НАСА сильна тем, что использует систему управления версиями, баг-трекер, перекрестную проверку кода и хорошее тестовое покрытие. То есть всё то, что есть у проектов с открытым кодом. Разница только в том, что у НАСА 100 тестеров, а у обычного ПО - сто миллионов. Отсюда и разница в количестве обнаруженных ошибок.

Статья пафосная и бестолковая, равно как и бестолковые ваши выводы о ней. Управление версиями, баг-трекеры и прочее тестирование есть у любой промышленной фирмы, это как набор напильников у слесаря. А вот методы и инструменты более серьезные могут позволить себе немногие, поскольку они предполагают значительно более высокую квалификацию инженеров, все равно что слесаря обучить работе на установке ядерно-магнитного резонанса, для поиска микродефектов. Речь о формальном анализе кода, о котором в вышеупомянутом опусе ни слова, но который тем не менее широко но без особого шума применяется в NASA, в частности в JPL.

Качество открытого кода - типичное заблуждение. Сто миллионов глаз не способны разглядеть баг в сложном коде, поскольку зачастую лишь единицы в состоянии его понять, если он достаточно запутан. Классический пример из недавних - дефект Heart Bleed в библиотеке openssl. Критическую ошибку допустил один из разработчиков под новый год, и, в течении двух лет ее никто не замечал. Где были ваши 100 миллионов глаз? Когда наконец на нее наткнулись, прослезились, поскольку пришлось заменить ПО на сотнях тысяч серверов, перевыпустиь миллионы кредитных карточек и т.д.

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

В ПО шаттла могут оставаться незамеченными десятки ошибок типа Heart Bleed просто потому, что никто не вызывал уязвимых функций с неправильными параметрами.

Статический анализ кода используется не только в JPL.

[Dude]

>Сколько там дало прироста ПН терминальное управление в Протоне-М - 10%?

ещё БЦВМ позволили использовать большие "надкалиберные" ГО для "Союзов-2" и "Протона-М". В принципе, могут позволить резко сократить площади выделяемые под падение ОЧ  или переместить районы падения, если бы у руководства хватило мозгов, то управлять ступенями после отделения и сократить расходы на РП было возможно после небольших модификаций, ещё задолго до всеобщей "маскофилии", т.е. без возвращения ступеней.

[TAU]

Старый пишет:

thunder26 пишет:
Формулировка "снижение массы и энергопотребления" вас устроит?

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

Господи, какой дебил...

[TAU]

Max Andriyahov пишет:

Разраб, писавший софт для бортового и наземного оборудования, поведал истинные причины того, почему космические аппараты имеют обыкновение не взлетать, взрываться, падать, и тонуть в океанах:
Хотелось бы рассказать вам немного о разработке ПО для космических аппаратов «у нас», в отличие о того, что мы наблюдаем «у них».
 http://kholeg.wordpress.com/2006/11/20/они-пишут-правильную-вещь/
Для начала немного о себе: я работал в этой отрасли несколько лет 
Все мои наблюдения оформлю в виде небольших тезисов:

Статья полностью https://ebanoe.it/2016/05/04/bad-software-fallen-rocket/

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

Читаем, думаем, например:
http://elibrary.ru/item.asp?id=9169553&
http://www.kik-sssr.ru/download/V.D._Anisimov_Bortovye_kompleksy_upravlenija_KA_svjazi_i_navigacii.pdf
http://www.iis.nsk.su/history/iss-reshetnev
http://www.slideshare.net/IosifItkin/automated-software-development-and-verification-technologies-in-the-aerospace-industry
http://cyberleninka.ru/article/n/sredstva-izmereniya-bortovogo-programmnogo-obespecheniya
http://cyberleninka.ru/article/n/osnovnye-printsipy-sistemnogo-testirovaniya-i-podtverzhdeniya-bortovogo-programmnogo-obespecheniya-sputnikov

[opinion]

TAU пишет:


Читаем, думаем, например:
 

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

[dmitryskey]

Dude пишет:
>Сколько там дало прироста ПН терминальное управление в Протоне-М - 10%?

ещё БЦВМ позволили использовать большие "надкалиберные" ГО для "Союзов-2" и "Протона-М". В принципе, могут позволить резко сократить площади выделяемые под падение ОЧ или переместить районы падения, если бы у руководства хватило мозгов, то управлять ступенями после отделения и сократить расходы на РП было возможно после небольших модификаций, ещё задолго до всеобщей "маскофилии", т.е. без возвращения ступеней.

Согласен, ещё и можно вспомнить довольно сильные экологические улучшения при падении первой ступени Протона-М за счет максимального выжигания топлива при применении терминального управления.

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

Как только компьютеры к концу 60-ых достигли минимально необходимой производительности и компактности (что было тесно связано с применением интегральных схем, первыми крупными заказчиками коих были ВВС США для Minuteman II и НАСА для Apollo), преимущества аналоговых вычислителей стали несущественны.

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

[Not]

dmitryskey пишет:
Но нет ничего такого, что в принципе нельзя сделать на аналоговых вещах, но можно осуществить на цифровой технике

АВМ невозможно перепрограммировать в полете, поскольку программа в нее зашивается жестко.

[dmitryskey]

Not пишет:

dmitryskey пишет:
Но нет ничего такого, что в принципе нельзя сделать на аналоговых вещах, но можно осуществить на цифровой технике

АВМ невозможно перепрограммировать в полете, поскольку программа в нее зашивается жестко.

Я имел ввиду алгоритмические вещи - по типу тезиса Чёрча. Собственно, Старый про это же говорит. Разумеется, в инженерном плане АВМ жестко настраиваются и ЦВМ гораздо удобнее - если только программу не прошивают в ПЗУ - что тоже практикуется, так надежнее гораздо в полете. Кстати, видимо поэтому Старый и ругается на современную авионику - слишком уж настраиваемая стала - много что можно поломать. И я могу себе представить - что такое обслуживание на аэродроме в -35 без рукавиц.

[TAU]

opinion пишет: 
Часть ссылок блокируется антивирусом, остальная посвящена водке

Не понял - пошутить хотелось? Или перепил?

[TAU]

dmitryskey пишет: нет ничего такого, что в принципе нельзя сделать на аналоговых вещах, но можно осуществить на цифровой технике

Нужно делать не "в принципе", а на практике. И вот такого - на что АВМ практически (а не теоретически) неспособны, а БЦВМ - пожалуйста - сколько хочешь.

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

[Старый]

Not пишет:

dmitryskey пишет:
Но нет ничего такого, что в принципе нельзя сделать на аналоговых вещах, но можно осуществить на цифровой технике

АВМ невозможно перепрограммировать в полете, поскольку программа в нее зашивается жестко.

Зачем АВМ? Обычное программное устройство и автоматическое управление.

[Старый]

TAU пишет:

Старый пишет:

thunder26 пишет:
Формулировка "снижение массы и энергопотребления" вас устроит?

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

Господи, какой дебил...

Ну ты то умный. Расскажи. Ну допустим доля автопилота в массе и энергопотреблении самолёта.

[Старый]

TAU пишет: 
 http://www.kik-sssr.ru/download/V.D._Anisimov_Bortovye_kompleksy_upravlenija_KA_svjazi_i_navigacii.pdf 

Легенда № 1 Приехал как-то президент США Рейган в СССР. И вот во время встречи с Брежневым ему потребовалась какая- то консультация с Вашингтоном. Тут же кто-то из свиты вытащил из внутреннего кармана телефонную трубку и подал ему. А он совершенно спокойно переговорил с Вашингтоном. Прямо из Кремля!! В то время!!! Эффект был потрясающим. В кратчайшие сроки были развернуты работы по созданию подобной системы у нас. И создали! Сделали! Правда при этом отключались более 1000 телефонных каналов и вся мощность одного из стволов ретранслятора спутника «Молния» использовалась для обеспечения работы только одного этого канала. 

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

Я, кстати, лично видел как американцы разговаривали с Госдепом из нашего штаба. Антенну им приходилось лепить на присоске к стеклу окна. 

[Старый]

Ну допустим на Радуге (Грань) не было БЦВМ, на Радуге-1 (Глобус) она вроде появилась. Как это сказалось на функциональности аппарата? 
Я понимаю что во многих случаях автоматического управления требующих реализации сложных законов управления в реальном времени без БЦВМ не обойтись, например при управлении гиродинами. Но это же простейшие случаи автономного автоматического управления. Откуда все эти страсти о которых говорит автор обсуждаемой статьи?

[opinion]

TAU пишет:

opinion пишет:
Часть ссылок блокируется антивирусом, остальная посвящена водке

Не понял - пошутить хотелось? Или перепил?

Да какие уж шутки.

http://elibrary.ru/item.asp?id=9169553&
Попытка соединения не удалась
http://www.kik-sssr.ru/download/V.D._Anisimov_Bortovye_kompleksy_upravlenija_KA_svjazi_i_navigacii.pdf
http://www.iis.nsk.su/history/iss-reshetnev -
Дикий бред про не имеющую аналогов систему, которая в стандартных терминах заключается в том, что вместо написания программ пишутся интерпретаторы p-кода, и потом на этом p-коде пишутся программы. Плюс рассуждения про то, как правильно пить водку.
http://www.slideshare.net/IosifItkin/automated-software-development-and-verification-technologies-in-the-aerospace-industry
Заблокирован опасный веб-сайт
http://cyberleninka.ru/article/n/sredstva-izmereniya-bortovogo-programmnogo-obespecheniya
Статья о статическом анализе кода без подробностей. Основной посыл - вот мы какие молодцы.
http://cyberleninka.ru/article/n/osnovnye-printsipy-sistemnogo-testirovaniya-i-podtverzhdeniya-bortovogo-programmnogo-obespecheniya-sputnikov
Примерно то же самое, с красивыми графиками, не несущими никакой смысловой нагрузки.