Много разговоров о неудачном пуске ракеты (РН) "Союз-2.1б" с разгонным блоком (РБ) "Фрегат" с космодрома Восточный в последние дни. "Роскосмос" уже опубликовал (12 декабря) причины неудачи, но для многих все равно остается непонятно, в чем заключается реальная суть, и кто виноват в привальном запуске. Предлагаю разобраться "на пальцах", что же все-таки произошло, и можно ли это было предотвратить.
Старт РН
Для разбора полетов будем оперировать теми данными, которыми поделился заместитель генерального директора "Роскосмос" Александр Иванов. Итак, что произошло при запуске:
Замглавы "Роскосмоса" пояснил, что азимут (угол между направлением на север и на какой-либо объект) старта на Восточном составляет 168,8 градуса. "Союз" после взлета должен был повернуться на азимут 354 градуса, а "Фрегат" после отделения от третьей ступени ракеты - еще на 10 градусов, на азимут 344. Перед запуском система управления "Союза" вычислила для себя кратчайший путь до азимута 354 через вращение от азимута космодрома против часовой стрелки на 174 градуса, а разгонный блок, вместо того, чтобы рассчитать вращение до азимута 344 также против часовой стрелки, вычислил свой поворот в другую сторону - по часовой стрелке на 175 градусов.
Для того, чтобы пояснить сказанное более наглядно, предлагаю взглянуть на рисунок (углы вращения, что указаны в комментарии, отсчитываются, если смотреть на ракету снизу, мы же будем смотреть на них сверху - так удобнее).
Собственно, я постарался изобразить ровно то, что сказано представителем "Роскосмос". Поясню схему. Смотря на "Союз", кажется, что он симметричен и ему без разницы, в каком положении относительно поворота вдоль продольной оси лететь. Но это не так. Приборы (в частности, навигационные), лучше работают в определенном положении ракеты. Теоретически, им должно быть без разницы, но практически, могут быть сложности с диапазонами измерения углов. Поэтому РН после старта "переворачивается" в нужное положение. Это называется поворотом по крену, когда ракета поворачивается вокруг вертикальной оси при старте. Пример такого поворота можно увидеть на видео ниже (первый запуск с Восточного).
Надо отметить, что в большинстве случаев для выведения на одну и ту же орбиту, можно использовать два азимута наведения, поэтому при запуске по другому направлению эта ошибка не проявилась бы. Кстати, наклонение орбиты (угол между плоскостью орбиты и плоскостью экватора) не может быть меньше, чем широта точки старта. Эта одна их двух причин (помимо дополнительной скорости), почему точки запуска стараются делать ближе к экватору.
Азимут старта - это начальное положение, куда, грубо говоря, смотрит система отсчета РН. Для нормальной работы это направление надо развернуть на азимут наведения РН, то есть выставить приборы в 0. Раньше это делалось на стартовом столе: он вращался, и РН сразу наводили на нужный азимут. Сейчас все упростилось, и РН выполняет этот маневр после старта.
У "Фрегат" немного смещенная (на 10 градусов) система отсчета, поэтому он разворачивается на дополнительные 10 градусов после отделения.
Что произошло
Смотрим на схему. Для РН угол разворота будет: 354 - 168.8 = 185.2 градуса. И тут встает вопрос, почему говорят про 174 градуса. Возможно, есть дополнительные компенсации или это уже данные с учетом вращения Земли. Думаю, здесь серьезной ошибки нет.
Теперь самое интересное. "Союз" принимает совершенно верное решение: для поворота до 354 градусов, разворот по часовой стрелке на 174 (185) градуса. По каким-то непонятным причинам, РБ "Фрегат", перед стартом, принимает решение, что кратчайший поворот до 344 градусов будет против часовой стрелки на 175. Что на старте выглядит верным решением. Теперь что происходит в процессе разворота "Союз": РБ "Фрегат" фиксирует этот разворот РН и пропорционально увеличивает требуемый угол поворота со 175 до 363 градусов - все в том же (теперь уже неверном) направлении против часовой стрелки. То есть проблема в том, что "Фрегат" не осознал, что надо изменить направление поворота после того, как его угол требуемого поворота вырос больше 180 градусов. Видимо, при старте он жестко зафиксировал направление поворота. Это подтверждает "Роскосмос":
Когда ракета после взлета - с 5 по 22 секунду - начала поворачиваться против часовой стрелки на азимут 354, рассчитанный компьютером РБ поворот в другую сторону начал увеличиваться и вырос до 363 градусов.
Ну а дальше что произошло - всем известно:
Он успел повернуть на 55 градусов (из 363), затем включилась двигательная установка, дальше - неконтролируемая потеря ориентации и падение.
Стоить отметить: разговоры о том, что РБ "Фрегат" стоило удостовериться в правильном положении и только потом включать двигатели - абсурдны. Он был выведен на низкую разомкнутую орбиту, поэтому включение двигателей должно быть произведено сразу же. В противном случае он все равно упал бы.
Почему работало раньше
Как бы страшно это не звучало - везение. Раньше очень сильно везло. До этого "Союз" с "Фрегат" на других точках страта (Байконур, Плесецк, Куру) не делал такие сильные развороты и они всегда оба поворачивали в правильную сторону. Это особенность точки старта на Восточном при стрельбе в сторону севера.
Можно ли было предотвратить
Думаю, многие задают этот вопрос. Мое мнение - да, можно было. И вот почему.
- Если направление разворота в РБ "Фрегат" задается через полётное задание (ПЗ) и "Фрегат" его обязан послушно исполнить, то налицо явный косяк тех людей на земле, кто это ПЗ составлял. Зная логику работы "Союз", эти вещи должны быть проимитированы, тем более даже не нужен "Фрегат" в железе, достаточно симулятора. Явные проблемы кооперации разных коллективов.
- Если решение о направлении разворота РБ "Фрегат" принимает самостоятельно, то это косяк его. Потому что фиксировать направление поворота, не зная, куда развернется РН - неправильно. В данном случае при разработке РБ "Фрегат" не было уделено должное внимание тестированию.
Как видно, неудачный пуск - это результат халатности или неправильно поставленного процесса разработки. Такие вещи должны отлавливаться и отлаживаться на земле до старта. Более того, у таких вещей должен быть исполнитель, который должен быть привлечен к ответственности (на не в Facebook Рогозина).
Вообще, на такие вещи (проведение пуска в новых условиях), обычно выделяют деньги и открывают этап. Видимо, эти деньги в данном случае успешно освоили. То ли стенда нет нормального, то ли вообще не заморачивались с тестированием. В общем, грустно это.
Комментарии
Не алгоритмическая, а ошибка проектирования. На выполнение маневра разворота до включения двигателей у РБ было "от 5 до 22 секунд". Если учесть, что измерение ориентации и угловых скоростей занимают практически несколько миллисекунд, то совершенно непонятно, почему развороты выполняются вслепую.
Вот черт. А я все гадал, зачем разворачивать ракету после старта? Она-ж "круглая"!
А нельзя-ли приборы сразу установить в нужном положении? Это-ж "дешевле" чем потом разворачивать двухсоттонную ракету...
Вам ракету в любом случае надо доворачивать на азимут стрельбы. Механизм надежный и отработанный. Изменение положения приборов внутри - это куча работы, от документации до переделки коммуникаций.
Ракету, в принципе, можно было бы заранее повернуть вертикальной осью вдоль азимута, но, скорее всего, это невозможно сделать из-за того, что на стартовый стол она устанавливается, словно лампа в панельку. Но даже и в этом случае можно было бы "панельку" сделать вращающейся.
Да-да... Не разгонным блоком доворачивать, а создать вращающийся космодром ! Сэр, признайтесь, по чести, вы не их команды Медведева по "оптимизации" производств и ведомств ?
На самом деле поворотные стартовые столы существовали.
Это какой-то позор. Вместо поворота на требуемый целевой угол по результатам текущих измерений, они просто поворачивают на какой-то определенный угол от исходного, не измеряя того, куда все таки же довернули.
Годный срач. Ахтунг - пахнет трольчатиной! Автор, нет ли в обсуждении упырей? Сим повелеваю - внести запись в реестр самых обсуждаемых за день.
Ну хоть кто-то из людей близких к теме, способный говорить по человечески !
Агромадное спасибо. Терь я хоть понял, что там к чему. А то до вашей статьи даже тот факт, что я инженер по эксплуатации радиоэлектронного оборудования ВС не спасал !
т.е. просто тупо распили деньги
Не сделав элементарного
Спасибо тебе, Рогозин за благополучную жизнь распильщиков
Он же даже поблагодарил за результат, что характерно....
Мне больше понравилось это (не знаю, насколько правда, но не удивлюсь):
Если и правда, то это внутрикорпоративное творчество - сделали заранее (что правильно)
Интересно, что примерно похожие причины были и у французов с их Ариан-5.
https://ru.wikipedia.org/wiki/%D0%90%D0%B2%D0%B0%D1%80%D0%B8%D1%8F_%D1%80%D0%B0%D0%BA%D0%B5%D1%82%D1%8B-%D0%BD%D0%BE%D1%81%D0%B8%D1%82%D0%B5%D0%BB%D1%8F_%C2%AB%D0%90%D1%80%D0%B8%D0%B0%D0%BD-5%C2%BB_(4_%D0%B8%D1%8E%D0%BD%D1%8F_1996_%D0%B3%D0%BE%D0%B4%D0%B0)#Причины_аварии
Но, в основном причины раскрыты и описаны Мейером. В самом общем виде. Карлингтон же - просто "отмазывал конторы".
Имея собственный опыт разработки систем управления в данной отрасли, могу сказать, что таких ошибок ПО ВСЕМУ МИРУ (не только в России!) будет всё больше и больше! Особо тревожно, что это связано с системами обороны или обеспечения безопасности или бесперебойности работы жизненно важных, для общества, систем.
Но ошибки - БУДУТ. В немалой степени, из-за начавшейся в конце 80-х-начале 90-х "заморозки" развития отрасли, фиксации на совершенно ограниченном круге способов и подходов к проектированию ПО и выбора языков реализации (да - что там! практически на единственном языке, который в принципе не годится для построения сколь-нибудь надёжных систем).
До тех пор, пока проектированием подобных систем занимаются "под присмотром" менеджеров, а не технических специалистов - БУДУТ ВОПИЮЩИЕ просчёты, ошибки, аварии и катастрофы.
Ещё статья интересная: https://www.osp.ru/os/1998/06/179592/
Можно считать, что Вы подвели итоги дискуссии. Хорошо сказано:
"могу сказать, что таких ошибок ПО ВСЕМУ МИРУ (не только в России!) будет всё больше и больше! "
К сожалению это так. Полность согласен. Утеряно искусство контроля над сложными системами. Вот внедрят искуственный интеллект, и совсем будет Гарлингтон.
Хотел только спросить, а на каком языке программирования "в данной отрасли" реализуют обсуждаемые здесь системы? Конечно, если это не государственная тайна. Я предполагал, что на С.
И что Вы имеете в виду в качестве замены?
Вопросы чисто прагматические.
Вы правы, конечно на Си.
И - борются, как и всякие глупцы, не с причинами болезни, предупреждая её, а - с последствиями и симптомами. Ну, то есть, внедряют юнит-тестирование вместо построения программ соответствующим образом.
Рецепт - прост и о нём известно уже не один десяток лет: Или Эйфель того же Мейера взять (не только сам язык, но и технологию и методологию проектирования), или - на Аде последних версий стандарта (SPARK и Ровенскаровские ограничения).
Но - нет, как в том анекдоте про мышей с кактусом, упоротость с недостатком кругозора и образования будут тупо быдлячить на Си (хотя бы и - с крестами)... Несчастные люди из несчастного мира самообмана в погоне за сиюминутными "простыми" решениями погубят цивилизацию...
Ваша информация интересная.
Она как бы возвращает меня на лет 30 назад. Тогда считалось, что Ada почила в Бозе из-за своей перегруженности. (Замечу, что вовремя появился Н.Вирт со своим простым учебным языком Паскаль.)
Книгу Майрса (так тогда его фамилия была у нас переведена) пытался читать, но книга показалась академической тематики. Если не изменяет память, на операторы надо выписывать логические предикаты...
Направление верификации (ПО) не отслеживал с тех пор. Допускаю, что многое изменилось к лучшему. Тогда возникает вопрос, а помогли бы указанные Вами технологии в ситуации, подобной с разведением РН и ускорителя. Допустим, предикаты (как формализованное ТЗ) на тестировании (тестирование же сохраняется?) были все выполнены. Т.е. штатные ситуации все проверили, но остаются варианты нештатных ситуаций. Встает во весь рост проблема полноты предикатной модели. Ну, а модель никогда не бывает полной по определению. Или я не прав?
А где гарантия, что нет ошибки на уровне базового программного обеспечения? Никто не даст гарантии...
Приверженность С, как мне кажется, обусловлена человеческим стремлением к простоте и проверенности готовых решений.
Но Вы правы, хотя программные системы стали очень сложными и многослойными, не так все печально. Это, как говорят американцы, вызов для цивилизации и решение найдет какой-нибудь новый Вирт.
2 наблюдения из Linux-a в догонку к написанному:
1-ое
dbn-VAK:~$ gcc --version
gcc (Debian 4.7.2-5) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Пояснение: с помощью gcc компилируется все ядро Linux и встраиваемые модули.
2-ое
"общая размерность имён ядра (/proc/kallsyms) приближается к 100000, из которых до 10000 — это экспортируемые имена ядра. Рассмотреть описательно такой объём не представляется возможным..." О. Цилюрик
Господа, коллеги, товарищи, куда мы идем?
Она как бы возвращает меня на лет 30 назад. Тогда считалось, что Ada почила в Бозе из-за своей перегруженности.
Перегруженности - в чём? Народ попался на удочку непонимания, что язык программирования - не столько средство для написания формулок для транслятора, сколько - средство фиксации и описания проектных решений.
(Замечу, что вовремя появился Н.Вирт со своим простым учебным языком Паскаль.)
Если вы про "тридцать лет назад, то Паскаль уже лет 20, как к тому времени существовал. Уже и Модула-2 существовали и Оберон родился, если кому-то сложность Ады представлялась непреодолимым минусом...
Книгу Майрса (так тогда его фамилия была у нас переведена) пытался читать, но книга показалась академической тематики. Если не изменяет память, на операторы надо выписывать логические предикаты...
Я такого варианта написания его фамилии не встречал. Была, по-моему, Андерсона книга "Доказательство правильности программ". Но Мейера всегда Мейером переводили. :)
Кстати, Мейер одно время у Ершова в Академгородке стажировался (еще, по-моему, в конце 60-х-начале 70-х), поэтому в его Эйффеле так много веяний и идей ершовскойшколы и советского языкостроения (роднит с идеями того же Эль-76).
помогли бы указанные Вами технологии в ситуации, подобной с разведением РН и ускорителя.
Безусловно. Другое дело, что постановщики задач, проектировщики и алгоритмисты - тоже люди...
Допустим, предикаты (как формализованное ТЗ) на тестировании (тестирование же сохраняется?) были все выполнены. Т.е. штатные ситуации все проверили, но остаются варианты нештатных ситуаций. Встает во весь рост проблема полноты предикатной модели. Ну, а модель никогда не бывает полной по определению. Или я не прав?
Мне кажется вы путаете вместе два понятия: корректность и устойчивость.
Последнее подразумевает, что понятия нормальной и аварийной ситуации всегда относительны по отношению к заданной спецификации; ситуация аварийна, если она выходит за рамки спецификации. Если расширить спецификацию, аварийные случаи становятся нормальными - даже если они соответствуют нежелательным событиям.
А где гарантия, что нет ошибки на уровне базового программного обеспечения? Никто не даст гарантии...
Так - нигде, вообще-то гарантии нет ничему. Но методы и способы доказательств (и их средств) расширяются и развиваются. Также и сам "понятийный аппарат". Кроме того, одним из путей преодоления системной сложности является развития средств формального разбиения задач на и систем на более простые и верифицируеме куски. + верификация актов взаимодействия этих кусков ("протоколы" взаимодействия и корректность состава сообщений). Здесь - тоже подвижки есть. Медленно - с одной стороны. С другой, пока общая масса проектной и программистской быдлоты ещё не дочухала что - к чему, - есть возможность, особо не напрягаясь достигать успеха, результатов и приятного шуршания в карманах. А у интеллектуальной быдлоты - пусть и дальше ракеты рвутся и суперсовременные истребители, при пересечении линии перемены дат, становятся кучей железок.
Приверженность С, как мне кажется, обусловлена человеческим стремлением к простоте и проверенности готовых решений.
Да - Боже меня упаси от этого идиотизма! Я - вообще как-то кактусы не люблю! Даже - рядом постоять...
"общая размерность имён ядра (/proc/kallsyms) приближается к 100000, из которых до 10000 — это экспортируемые имена ядра. Рассмотреть описательно такой объём не представляется возможным..." О. Цилюрик
Олег Иванович - знатный специалист. Но и он смирился с тем, что в современных условиях зарабатывание денег - более актуальная задача, чем быть упёртым приверженцем ПРАВИЛЬНЫХ решений и систем, при том, что быдлота из менеджмента, проектировщиков и программистов даже не разумеет, с какого рода глубинными проблемами человеческого мышления и проектирования сложных систем, они имеют дело и чем обусловлены их постоянные трудности при проектировании систем класса выше интернет-магазина.
Господа, коллеги, товарищи, куда мы идем?
Известно - куда: к границе способностей интеллекта осознания сложности мира.
Должен констатировать, что Вы по всем пунктам правы:
1. Н,Вирт вышел из комитета по "Algol-68" и в начале 70-х у него был готов Pascal.
2. Бертрана Мейера я спутал с Гленфордом Дж. Майерсом. Глубоких же академических знаний у меня нет;-) В программирование пришел из инженерии после студенческой скамьи. Поэтому предметную область знал хорошо.
и т.д.
Да, в деталях все так, как Вы пишите, а в общем...прямиком "к границе способностей интеллекта осознания сложности мира".
Напомню первоначальную суть дискуссии. Не скрою, что я пытался замолвить слово о "бедных гусарах"-прикладных программистах. Не помню, где читал, что программисты (скорее всего прикладные) находятся в области семантического разрыва предметной области и "computer science". По-моему, это называлось даже "щелью". Жизненный опыт говорит, что эта метафора справедлива.
Но если раньше я думал, что прикладной программист испытывает основное давление со стороны предметников, то в нашей беседе я впервые остро ощутил разрыв и с противоположной стороной, хотя я и работал некоторое время в академической среде.
Наверное, для меня это главный результат затянувшейся дискуссии.
Сейчас наступили времена, когда мейнстрим-программер даже не слышал о тех вещах и людях, их создавших, которые закладывали и развивали основу отрасли.
Под давлением сиюминутных (на тот момент) "задач", отрасль стала закукливаться не только в области набора типичных задач, но и постулировала интеллектуальные схемы и подходы к их решению.
Как только в той или иной отрасли появляются стандарты - развитие закончено.
В нашей отрасли это проявляется наиболее ярко.
"Прорывные" решения и вещи - это всё - до середины 80-х - начала 90-х. Дальше - беганье по кругу... Причём - во всех подразделениях ИТ (от протоколов взаимодействия и - до семантики и синтаксических конструкций в языках программирования).
Мы перестали, через развитие программирования, изучать свой мозг, способы и законы своего мышления.
Никто не спорит, что процессы в любом производстве необходимы, но взрывоподобное их появление в последние несколько лет, напоминает больше крыловских пересаживающихся музыкантов (ну, или перестановку кроватей в публичном доме - кому что понятней). При этом внимание каким-то непостижимом образм было убрано с собственно инструментария, с которым работает программист. И здесь даже вопрос - не о тулзовинах и утилитах, средах разработки и отладчиках. Тормознуто развитие новых направлений в разработке собственно формализмов, предназначенных для выражения идей и решений, сформировавшихся в головах разработчиков программ(ных систем).
Здесь я с Вами полностью согласен.
Как то лет 10 тому назад я сказал одному неофиту от программирования, что в отрасли с конца 70-х годов принципиально нового ничего не изобретено. Он не согласился со мной и готов был поспорить, но смысла в этом не было, так как фактологическим материалом он не владел и все бы вылилось в беспредметный спор, а я уже, наверное, старый, и этого всячески избегаю.
Мне довелось поработать во многих лавках, конторах и присутствиях... Жизнь покидала и по зарубежным гадючникам тоже. Есть с чем сравнивать.
Так вот, я скажу, что разницы, особой, нету. Конечно, ТАМ оглушает фантастическая оснащённость разработчика разнообразнейшим контрольно-поверочным оборудованием (для меня это важно, я разрабатываю большие системы, где вовлечены и стадии разработки "железяк").
Но.
Снижение уровня программистов - повсеместное.
Скажу так, нашу с вами беседу смогут сейчас понять (о чём, собственно, идёт речь) где-то порядка 7-15% разработчиков. Половина из них поймёт, но отнесётся к этой беседе, как к праздному занятию, зудежу, бубнению и бесполезной игре ума двух старых пердунов...
Самый Ужас предстоящей катастрофы в области ИТ - по большому счёту - в переносе ценности со знания принципов на знание инструментария и замыкания на последнем. Без знания принципов, пользователи инструментария просто не смогут адекватно оценить и понять, почему же инструментарий, предлагая грандиозные, по красивости и удобству, решения на каждом из этапов разработки, ВСЁ-ТАКИ, не позволяют получить адекватные решения.
Я - хоть и не ярый сторонник теорий заговоров, но, складывается такое впечатление, что, в след за космической отраслью и физикой, в области ИТ, кто-то очень старательно "развесил красные флажки" вокруг строго очерченных и разрешённых "полянок". И дальше, за них, - НИ-НИ! Вплоть до каких-то карательных мер, которые на поверхности проявляются в виде "вдруг нахлынувшей волны и периода непрухи и топтания на месте по каким-то заморочкам". Повторяю: это - не только с пространством бывСССР связано.
Я думал, что тема беседы завершилась, но Вы затронули какие-то тайные струны...
От "майн-стримов" отошел, когда уволился больше 30 лет назад из системы Средмаша. (Там все было очень круто, но предопределенно.) Ушел в АН, тогда еще СССР. Академическая система после оборонки оказалась еще тем гадюшником. Ушел... и жизнь пошла по непредсказуемой траектории. В результате заполнены две трудовые книжки. Многое видел изнутри без "презентационного" гламура, много испытал и пережил. Не жалею. В результате, наверное, стал более терпимым к окружающим.
Сейчас хочу вернуться к своей изначальной специальности и заинтересовать руководство направлением вихревых теплогенераторов. Физика явления не раскрыта до сих пор (явно не кавитация, как утверждают некоторые специалисты, но наиболее близко подошел к ее разгадке лесничий по образованию Виктор Шаубергер: дилетанты двигают прогресс.) Хочу одну установку поставить у себя дома, а все остальное высокое и духовное - "суета сует" по Экклезиасту.
сорри,Уважаемые, так и не понял каким образом вращение по крену привело к тому что аппарат развернулся по тангажу так что движки его затормозили...
Это действительно хороший вопрос. В этом плане Роскосмос молчит. Моя версия следующая. Маневр по крену нужен был для корректной "инициализации" системы навигации в 0 (аналогично, как делается у РН), после чего, видимо, был маневр и по рысканию/тангажу.
Если обратить внимание на эту фразу Роскосмоса:
То можно предположить, что потеряв ориентацию из-за неправильного разворота по крену, он кувыркался по тангажу и рысканию не пойми как. При включении двигателей мучения закончились.
Не думаю, иначе получается что ситуация ещё веселее, аппарат на момент разделения с носилками бултыхается неизвестно как , а времени на стабилизацию в связи с незамкнутый орбитой не хватает, такой косяк слишком груб...
О, на авантюре нашел более менее понятную версию от Нале-"Возможно, там ограничение по углам прокачки рамок кардана гиростабилизированной платформы. Тогда делают весьма сложный пространственный поворот по всем трем каналам (тангаж, рыскание, вращение) только для того, чтобы в итоге развернуться на 1800 только по тангажу, например. Такая фишка есть на 15А18(18М) после отделения СН (СР) от второй ступени и запуска ДУ."
Страницы