Pull to refresh

Comments 350

«интеграционное тестирование» — может доказать наличие ошибок, но не их отсутствие.
Когда дело касается таких денег, нужно не лепить программы по кривым алгоритмам. Мы не сверхбогатые США, нет в наших карманах столько денег, чтобы такое оплачивать!
Из того, что в новых условиях алгоритм может работать неадекватно, не следует, что он «кривой». Новые условия могут быть несовместимы с исходными требованиями. При пусках с «Байконура» или «Куру» после отделения азимут был близок к нулю, необходимость пересчитывать его не было, и код работал полностью адекватно.
Ясно. «Никто ни в чем не виноват». Разгонный блок не может понять, в какую сторону довернуть надо, а включив двигатель и увидев по акселерометрам, что вместо разгона пошло торможение, не выключает двигатель для спасения миссии. Отличные алгоритмы (для сжигания денег)!
Я за такую работу из фирмы ссаными тряпками гоню, причём не за саму ошибку, а именно за баранье «никто не виноват». Может, поэтому у нас крупных провалов не бывает?
А Ваша фирма, простите, что делает? :)

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


Тут где-то уже обсуждалось, что если поворот в течение минуты не завершён, то выключай-не выключай двигатель — миссию всё равно не спасти.
Ну, справедливости ради, даже если бы направление поворота считалось перед включением двигателей РБ, всё равно возможна ситуация с максимальным углом поворота 180*. Да, в данном случае пару градусов. А если опять космодром где-нить построят… Т.е. получилось, что посчитали 60* (55*) достаточным для любого возможного поворота, а потом врубаем двигатели РБ. Ненадёжно как-то… Ну после драки, конечно, мне легко махать кулаками, но всё же…
И как они собирались довернуть на 175* при старте, если было меньше минуты на разворот. Всё равно неясно.
Возможно, из каких-то общих соображений 180 градусов быть не может — ведь это по сути означает, что РБ нужно развернуться в противоположную сторону относительно того, куда последнее время перед отделением двигалась ракета. Вроде бы это не очень целесообразная траектория. Но в целом я конечно согласен с тем, что при повторном использовании кода нужно быть очень осторожным с такими штуками. Кстати, это очень похоже на памятную историю с Арианом-5, когда код, идеально работавший на Ариане-5, сломался опять же на других условиях работы (там оказалась скорость, какой на Ариане-4 принципиально не могло быть, что вызвало переполнение переменной).
Ну по окончании вывода он как раз на 180 и должен повернуть, чтобы сойти с орбиты
Почему на 180? Вроде бы он должен немного по тангажу наклониться, чтобы с орбиты «вниз» улететь. Но даже если на 180, по окончании вывода у него уже нет такого жёсткого ограничения по времени (в виде минуты на разворот).
Нет, чтобы вниз полететь надо затормозиться.
Ограничение по времени было программное, «минуты хватит на всё». Реально до необратимого входа в атмосферу порядка десятка минут было, успел бы и на 357 повернутся.
Кстати, это очень похоже на памятную историю с Арианом-5

По-моему, это больше похоже на такой случай:

11 февраля 2007 года 12 истребителей F-22 не смогли перелететь из США в Японию из-за возникших проблем с навигационным программным обеспечением (предположительно из-за пересечения линии смены дат посреди Тихого океана)

А ещё с нулевым меридианом (деление на ноль, все числа nan, полный отказ навигационной системы) и с нулевой широтой (экватором, кто бы мог подумать что синус знак меняет при пересечении оси y, как следствие самолеты попереворачивались и полетели кверху ногами)

Нулевая высота ещё была.
При полёте над Мёртвым морем.
Это да, примерно помню все эти эксцессы… занятное дело, быть разрабом боевой авиации (я не про себя).
Там, насколько я помню, она была даже отрицательная. То есть, с точки зрения ПО, самолет бурил тоннель.
Насколько я помню — проблема была не в отрицательной, а именно в нулевой. Писали, что деление на ноль случилось.
Т.е. летать в Астрахань, Баку, Турменбашы и т.п. заведомо не предполагалось (в Т.З. такие варианты отсутствовали). Хорошо.
может, это была палубная океаническая авиация.
Над Астраханью они бы летали на высоте 10км и было бы все ОК. А то, что им было бы сложно делать там посадку — так может это дополнительный бонус.
Может. Но более логичное предположение — что никому в командах заказчика и разработчиков не хватило эрудиции вспомнить, что бывают места на планете с открытой поверхностью ниже уровня океана. (Кстати вполне допускаю что и радиовысотомер в таких местах — даже при нормальной, «плюсовой» высоте полёта — может систему загнать в ступор)
Вот когда какой-то из проектов вашей фирмы возьмут через 20 лет после сдачи, и запустят в условиях, про которые вы и догадываться не могли на момент проектирования, об этом можно будет говорить.
А кто виноват тоже обозначено — не была проведена проверка имевшегося алгоритма с новыми условиями запуска. Но это уже вопрос интеграции, а не изначального проектирования\исполнения работы на местах, зоны ответственности разные.
Я не говорил, что «никто ни в чем не виноват». Есть очевидная недоработка, которую можно было бы устранить. В то же время, мне не нравится идея ловить кого-нибудь и пускать ему кровь на потеху публике. Потому что ситуации бывают разные. Схватишь за жабры потенциального виновника, а он документами докажет, что годами просил построить стенд для тестирования, а ему на это ресурсов не дали. И так далее.
Я за такую работу из фирмы ссаными тряпками гоню, причём не за саму ошибку, а именно за баранье «никто не виноват».

Типичная ошибка руководителя, который считает себя умнее подчинённых. У такого руководителя и в мыслях не может быть, что виноват он сам, потому что просто не сумел организовать работу. В итоге страдают ни в чём не повинные рядовые сотрудники, а руководитель выходит сухим из воды, ведь он нашёл виновных.

… увидев по акселерометрам, что вместо разгона пошло торможение ...
А как это «увидеть» по одним только акселерометрам? Есть нехорошее подозрение, что для аппарата движение по траектории есть то же самое, что свободное падение, соответственно акселерометры изначально (после выключения ДУ блока И) показывают ноль (с точностью до шума). Тогда с точки зрения акселерометров после включения двигателя «Фрегата» в любом случае идёт разгон. Что-то подсказывает, что «увидеть» можно, только принимая во внимание пространственное положение вектора тяги, а с этим-то как раз и напортачили.

Может, поэтому у нас крупных провалов не бывает?
Искренне рад за вашу фирму.
Тогда с точки зрения акселерометров после включения двигателя «Фрегата» в любом случае идёт разгон.

на самом деле нет, акселерометры же не жёстко привинчены к корпусу «Фрегата», а установлены на гиростабилизированной платформе, т. е. измеряют не продольное ускорение, а ускорение в инерциальной системе отсчёта.
А, да! И то верно, про платформу-то я и забыл… :-(
К акселерометрам просто табличное ускорение свободного падения плюсуют АФАИР, так что реальное ускорение и скорость легко вычисляются. И растёт скорость или нет, легко видно.

Мне тоже совершенно не нравится примирительный тон этой статьи. Предположим, никто из подрядчиков не виноват. Типа, как в ТЗ написано, так и бахнули. К пуговицам претензии есть?
Но в любом проекте всегда есть генподрядчик — тот кто пилит основные деньги, но и отвечает за результат. Кто отвечает за пуск? Роскосмос и лично мсье Комарофф? Жирный вице-премьер? Где коммюнике ТАСС и розданных люлях?
Я вот тоже делаю проекты, и не надо спрашивать о масштабах, это не имеет никакого значения. Я — интегратор и отвечаю за результат. Я подбираю компоненты (хотя частенько мне их предлагают как состоявшийся факт) и я увязываю их в единый комплекс, выполняющий задачу. Самый частый вопрос к поставщикам компонентов: "Ребята, а вы вообще тестируете вашу продукцию?", настолько часто косяки лезут сразу после включения и видны невооружённым осциллографом взглядом. Но ничего, разбираемся, меняем оборудование, заставляем допилить прошивки, корректируем проект. Факапов, подобных этому не было никогда, хотя всяко бывало.
По данному инциденту можно сказать что прошли те времена когда для понимания причины глюка надо отстрелять десяток ракет. Для проверки интеграции компнентов в данном случае не надо даже строить дорогостоящий стенд, достаточно обычного настольного компьютера чтобы прогнать циклограмму полёта даже с реальными боркомпьютерами. И этот косяк вылез бы сразу. Да, пришлось бы отложить пуск, может быть и на месяцы, да пришлось бы вложиться в исправление "прошивок", но… дальше сами дополните…
По-моему, вместо попыток сгладить ситуацию надо признать уже очевидное: под управлением финансиста и патронажем журналиста Роскосмос скатывается в говно. И с этим надо что-то делать если, конечно, кто-то из начальства заинтересован в развитии русского космоса.

Тогда надо оплачивать возможности оттестировать всё от и до на земле. Напомнить вам сколько суперкомпьютеров стоит в США и сколько у нас? Очевидно же что проблема в том что «Фрегат» с «Восточного» никогда до этого не запускали и полностью исключить подобную аварию можно было разве что предварительным прогоном ПО в симуляторе которого нет.
Вот, и я об этом хотел написать. Где симулятор полета?
В результате, когда ракета повернулась на 174 градуса, они добавились к углу, на который собирался повернуть разгонный блок.
Если мы ищем крайнего, то очевидно, что линчевать нужно человека, который рассчитывал полную траекторию полета ракетоносителя и фрегата. Именно он ошибся не учтя, что фрегат начнет работу с уже выполненным поворотом на 174 градуса. А учесть он это мог, если бы знал откуда запускается ракета и как работает ее ПО. Почему на оборудование с огромной стоимость не делается симуляторов — тоже загадка, либо симулятор есть и ошибка как раз-таки и была в этом симуляторе рассчитывающем траекторию. Тогда виновен создатель симулятора.

Фраза в статье не верна:
Так в чем же причина аварии? На этот вопрос отвечают два слова — «интеграционное тестирование».
На самом деле — была ошибка в расчете траектории полета, и Мерфи здесь не причем :) А вот причина ошибки траектории имеет как минимум 2 возможные причины описанные выше.
Именно он ошибся не учтя, что фрегат начнет работу с уже выполненным поворотом на 174 градуса

Это-то как раз учтено. Не учтено, что РН и Фрегат захотят поворачиваться в разные стороны.
Дык,
Если мы ищем крайнего, то очевидно, что линчевать нужно человека, который рассчитывал полную траекторию полета ракетоносителя и фрегата. Именно он ошибся не учтя, что фрегат начнет работу с уже выполненным поворотом на 174 градуса. А учесть он это мог, если бы знал откуда запускается ракета и как работает ее ПО.
Не противоречит утверждению «Не учтено, что РН и Фрегат захотят поворачиваться в разные стороны». Так как если бы тот, кто рассчитывал траекторию, знал как работает Фрегат и как работает РН, то очевидно, он бы увидел, что при повороте РН на 174 градуса, Фригату придется выполнить заведомо обреченный поворот в 363 градуса.

По факту, реальная проблема при расчете траектории — в незнании как работает ПО + в отсутствии или не корректной работе симулятора. Иначе можно было бы задать курсы РН и РБ при которых бы они поворачивались в одну сторону и успешно вышли на орбиту (без какого-либо вмешательства в работу ПО РН и РБ).
Не противоречит утверждению «Не учтено, что РН и Фрегат захотят поворачиваться в разные стороны». Так как если бы тот, кто рассчитывал траекторию, знал как работает Фрегат и как работает РН, то очевидно, он бы увидел, что при повороте РН на 174 градуса, Фригату придется выполнить заведомо обреченный поворот в 363 градуса.


Всё же не совсем так. Сами траектории баллистиками просчитаны хорошо, и эти расчёты учитывают всё, что нужно, в том числе и поворот на 174 градуса — ведь по факту оказалось, что Фрегату после отделения нужно двоернуть всего на 3 градуса. Но в силу того, что бортовой алгоритм не учёл врашение РН и РБ в разные стороны, 3 градуса превратились в 363.
Сами траектории баллистиками просчитаны хорошо
:) Ну как же они могут быть рассчитаны хорошо, если не учитывают реальный алгоритм поворота Фрегата?
Ошибка именно в расчете траектории, если бы тот, кто рассчитывал, знал как работает Фрегат, он бы не выбрал курсы РН и РБ при которых они начнут поворачиваться в разные стороны и завалят миссию. Повторюсь: он бы задап курсы РН и РБ при которых бы они поворачивались в одну сторону и успешно вышли на орбиту (без какого-либо вмешательства в работу ПО РН и РБ).

ведь по факту оказалось, что Фрегату после отделения нужно двоернуть всего на 3 градуса
Не согласен.

Курсы РН и Фрегата при старте определяет тот, кто рассчитывает траекторию. Именно он и ошибся. Согласитесь, для того чтобы построить правильную траекторию нужно знать как работают устройства, которые выполняют маневры, если вы не знаете как устройство выполняет заданный маневр, вы не сможете построить правильную траекторию. Получается он не знал, как работает Фрегат, и что при выходе на курс, выбранный РН маневр поворота на 174 градуса окажется фатальным для маневра выбранного Фрегатом.

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

Итого:

Если РН и РБ это автономные устройства, каждое из которых работает по своей программе, которой задается курс назначения для которого она рассчитывает маневр — то виноват тот, кто рассчитывал траектории.

Если маневры для РН и РБ рассчитываются за ранее в общей программе, и в устройства копируются не заданные курсы, а уже необходимые маневры — то виноват программист делавший программу. Но тут может быть проблема с тем, что программа была предназначена для запуска с другого космодрома и там всегда работала корректно… тогда получается виновен во всем человек, принявший решение использовать программу с другого космодрома без симуляции ее работы для условий нового космодрома.

виноват, виновен, виновен, виноват

Может эти все люди, которые принимали решения. уже давно на пенсии. А остались только люди, которые принимают НЕрешения — продлить, оставить в силе эти решения?

Вот я вам еще вариант подкину — все было проверено и промоделировано, только симулятор несовсем точный — не предусматривал, что кто-то повернет ракету на 360.

все совпадения - случайны, все ситуации выдуманы
Т.е. проектировал разработчик РБФ, и там сделал, что все работает идеально для углов от -180 до 180. «В самом деле», думает разработчик, «зачем накручивать круги по орбите? Куда бы не был твой следующий курс, его угол всегда будет по кратчайшей дуге от текущего», — провозглашает он (картина «Папа Карло держит в руках Буратино»). И загодя в документации прописывает в ограничения угловой скорости 1 градус в секунду (ибо плеск топлива в баках, уход гироплатвормы, да мало ли что). А ориентацию она экономно считает после окончания маневра (или до старта ракеты), когда времени вагон, а потом только отслеживает положение по своей гироплатформе (добавляет-вычитает углы из рассчитанного, если что-то ее немного крутит. Будь-то ракета по своей траектории в полете, или диспенсер спутника на орбите).
Проходят года, РБФ отлично летает, спасает огрехи ракет-носителей, и он торжественно уходит на пенсию.

И вот, новый запуск с нового космодрома. Все внимательно читают документацию и жмут кнопки калькуляторов.
«Ага! 1 секунда — 1 градус», торжественно говорят ракетчики.
«А когда он отделится от ракеты — у него всего 60 секунд до атмосферы» — рассчитывают баллистики.
«Хорошо», — говорят ракетчики: «мы выведем его не более чем на 10 градусов отклонения по курсу. Ну на 20 градусов вбок, в худшем случае».
«Ладно», соглашается программист РБФ, бережно выставляя руками уставку на первое срабатывание маршевого двигателя в 55 секунд. «Даже если эти артиллеристы на 40 градусов промахнутся, наш надежный РБФ будет иметь запас в 15 секунд и всех спасет», — втайне думает он.
Все документы подписаны, ключ на старт.

Разгонный блок ждет свою гироплатформу, после чего обсчитывает надобный курс на -175 (условно) градусов и готовится не пропустить свой выход.
Ракета стартует, делает поворот на свои 175 (условно) градусов, и прилетает в точку прощания с РБФ, с идеальным с их точки зрения курсом — даже меньше чем 10!

И только пассажиры самолетов над северной атлантикой полюбовались приветом всем от прерванной «бочки» РБФ…
А, кажется, я понял Вашу мысль. Тут вопрос, что первично: траектория или алгоритмы. Полагаю, что первична траектория: баллистики говорят, «куда» (в каком направлении, с какой скоростью и ускорением) надо лететь, а алгоритмисты должны реализовать соответствующее управление ракетой и РБ. Следующий пуск, допустим, осуществляется немного в других условиях: скажем, спутники теперь надо вывести на другую орбиту. Значит, опять первое слово за баллистиками, а алгоритмисты теперь должны подправить свой алгоритм, чтобы он решал и эту задачу. Теперь третий пуск: на этот раз с другого космодрома. И опять: баллистики задают требуемую траекторию, алгоритмисты допиливают бортовые программы.

Разумеется, баллистикам не всё позволено: траектория, которую они определяют, должна быть «проходимой» — т. е. тяги двигателей, запасов топлива, прочности конструкции и пр. должно хватить на все линейные и угловые ускорения. Но если траектория в принципе «проходима» — дальше это уже дело алгоритмистов правильно реализовать управление. Я считаю, что в этом вопросе баллистики не должны подстраиваться под особенности работы алгоритма без крайней необходимости. Тем более, что алгоритм может быть довольно сложным и запутанным, с большим числом ветвей. Я видел эти алгоритмы, там сам чёрт ногу сломит :) Совершенно не дело баллистиков в них разбираться.
Я считаю, что в этом вопросе баллистики не должны подстраиваться под особенности работы алгоритма без крайней необходимости.

Вот именно, и эта гибкость программистов должна быть не случайной, а сознательно развиваемым основным принципом работы.

Допустим, вы ответственны за развитие космической отрасли, что можно сделать, чтоб это было именно развитие?
— Отменить формулу Циолковского? Увы, не получится.
— Изобрести новое топливо и двигатель к нему? Это, конечно, нужно делать, но до серийного производства пройдут годы, если не десятилетия, и стоить будет миллиарды.
— IT? А вот в IT у нас с 70-х (полёты на Луну) прогресс просто колоссальный!

Вертикально посадить на баржу отработавшую ступень? Для человека ужас-ужас, а бортовой компьютер щёлкает такие задачи как семечки, даже с учётом ветра и дрейфа плавучей платформы.

Электронщики не могут надёжно защитить старый процессор от космических лучей? Так благодаря успехам микроэлектроники мы в тот же объём и энергопотребление уместим куб 3х3х3 из 27 микрокомпьютеров, которые сообща выдадут правильную команду при полном отказе половины из них. За последнее десятилетие человечество сделало огромный скачок в алгоритмах распределённых вычислений и установлении консенсуса при постоянно сбоящем железе.

Мегабайты и мегагерцы на ракете растут медленнее чем в потребительском секторе? Да, это так, но для наземеных испытаний можно купить кластер серверов с толстыми графическими карточками и за смешные по космическим меркам деньги получить терафлопсы для обработки данных испытаний и для численного моделирования.

Программисты живут в идеальном мире без физических ограничений, где, в отличии от производства двигателей, половину материала для работы можно за десять минут склонировать с GitHub. В случае неудачи программист просто откатывается к предыдущему коммиту, в то время как другим нужно заново строить разрушенный взрывом стенд. Было бы крайне глупо не использовать это преимущество и заставлять баллистиков подстраиваться под софт.
Такая ода вычислительным машинам, я аж прослезился :)
Так всё верно, но посмотреть прогресс методов управления ракет — такое чувство, что он нулевой со времён Спейс Шаттла.
Для Шаттлов разработали алгоритм, который решал задачу выхода на заданную орбиту с квазиоптимальным управлением, и всё это делалось полуаналитически, но при этом довольно точно. Подробнее алгоритм написан в книге «Баллистика и наведение летательных аппаратов» Сихарулидзе (доступна с сайта РФФИ) в районе 300 страницы. Но ограничение — профиль тяги со временем должен быть известен, т.е. времена включения-выключения двигателей жёстко зафиксированы.
Современные работы смотрю — предлагают делать на борту прямое численное решение задачи оптимизации по 32+ переменным. Получается правильно, но сложно, в десятки раз дольше шаттловской схемы управления и без такой физико-математической красоты.
С атмосферным участком ещё понятно, но вот оптимизировать промежуток времени между, скажем, отделением разгонного блока и его первым импульсом неужели нельзя как-то попроще на лету?
А можете подсказать оные работы?

С атмосферным участком ещё понятно, но вот оптимизировать промежуток времени между, скажем, отделением разгонного блока и его первым импульсом неужели нельзя как-то попроще на лету?


Представьте себе картину: Вы разгонник, вы только что отделились от РН и понятие не имеете где вы находитесь.

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

Сколько ждем? Для точного определения желательно виток, ну ладно, хотя бы треть.
Что, 12 секунд? А почему? Как незамкнутая орбита? А, чтобы тонну топлива с собой не нести для лишней борьбы с атмосферой.

Так, постойте, если мы на незамкнутой орбите мне надо срочно поднимать перигей. Где это делать всего лучше — в апогее. Так, где у нас апогей, да он уже здесь, все включаемся!

Вух, подняли перигей. Так народ, а мы сейчас вообще где, нам надо определяться. Так, стойте, почему у нас аргумент перигея далек от целевого?! А, вектора были с большой ошибкой, понятно.

Ну ничего, сейчас все исправим. Так, где надо включаться — А вот тут, на 150 секунд раньше чем предполагали эти тупые человеки. Все народ, включаемся, полетели.

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

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

То есть ошибка вот в чём: по умолчанию полагалось, что РН и РБ сделают эти большие развороты (примерно на 180 градусов) в одну и тут же сторону. Тогда из исходных 174 вычтут угол поворота ракеты (примерно 180), получат небольшой угол в несколько градусов, а его знак покажет, куда надо крутиться. Но РН неожиданно для РБ развернулась (в его обозначениях) на -180 градусов! И РБ рассчитал, что ему надо повернуться на 180-(-180)=360 (примерно; на самом деле вышло 363).

Кто же тут виноват? Сложный вопрос, и ответ на него, как я вижу, зависит от согласований между НПЦАП и НПОА. Допустим, если между двумя фирмами когда-то давно раз и навсегда было согласовано, что все повороты всегда делаются по часовой стрелке и на Байконуре так всегда и было, а на Восточном алгоритм НПОА развернул «Союз» против часовой, то это вина НПОА. Тогда моделирование, которое делалось в НПЦАП, не помогло бы вскрыть проблему, так как моделирование, исходя из этих договорённостей, повернуло бы РН по часовой, а в настоящем полёте она пошла разворачиваться против часовой.

Или другой вариант: никакого согласования направлений вращения нет, согласуется лишь конечная ориентация, в которой РН и РБ будут перед отделением РБ. Тогда это вина алгоритмистов НПЦАП, которые полагали направления вращения совпадающими: для Байконура это всегда было так, и можно было исходить из этого предположения, а вот на Восточном уже нельзя. Это как раз то, о чём Вы пишете:
Но тут может быть проблема с тем, что программа была предназначена для запуска с другого космодрома и там всегда работала корректно… тогда получается виновен во всем человек, принявший решение использовать программу с другого космодрома без симуляции ее работы для условий нового космодрома.

Какое-то моделирование полёта, безусловно, в НПЦАП делалось. Но в если оно недостаточно корректно и реалистично отображает манёвры носителя, то эту проблему на моделировании могли и не увидеть.
1) Я не уверен что вообще рассчитывается угол поворота, а не поворот прекращается по достижении нужной ориентации.
Т.е. определили в какую сторону поворачиваться меньше и запомнили результат.
2) На Байконуре и в Плесецке ракета вообще не поворачивается, она сразу в нужной ориентации.
1) Это хороший вопрос, он тут уже всплывал. В посте сказано, что РБ стал врашаться в нужную сторону, только вместо 3 градусов пошёл на 363. Если бы он отслеживал ориентацию, а не угол поворота, то остановился бы после поворота на 3 градуса, и всё было бы ок. Из этого я делаю вывод, что в данном случае ориентация определялась датчиками угловой скорости, а не угла. Давайте попробуем уточнить у автора поста. lozga, Вы не могли бы нас проконсультировать: верно ли, что в данном случае ориентация РБ определялась ДУС и если да, то чем это предпочтительнее датчиков углов платформы?

2) Ок, спасибо за уточнение. Это все ракеты так, или только «Союз»?
1) Насчёт на 363 или 357 — показания разнятся… телеметрии тут никто не видел, а судить по словам начальников в новостях — дело дохлое.
2) Все ракеты в 50х так делали… Протон уже не крутят, он сам умеет.
Мне кажется, что поворот вызван сочетанием используемой инерциальной системы координат и того, что блок только перед стартом определял, в какую сторону вращаться. Из-за этого поворот по строительной оси крена воспринялся как поворот по азимуту, и СУ РБ, который запрограммирован обнулять азимут, «взвелся» как пружина в часах. Возможно, еще упущение в системе подсчета, когда не вычли 360 градусов из поворота на 363 (потому что в нормальных условиях это не нужно).
Возможно, еще упущение в системе подсчета, когда не вычли 360 градусов из поворота на 363

Ниже ведь было уже упомянуто:

А в случае 357 что было бы? Поворот на 357…
Собственно, о чем и речь. Нам недостаточно входной информации о том как и в каких модулях работают алгоритмы и кто и как рассчитывает траекторию, поэтому я и привел 3 варианта…

То есть ошибка вот в чём: по умолчанию полагалось, что РН и РБ сделают эти большие развороты (примерно на 180 градусов) в одну и тут же сторону.
Верно, вопрос только кем и почему так предполагалось по умолчанию? Ведь именно это предположение и не соответствовало реальности.

Какое-то моделирование полёта, безусловно, в НПЦАП делалось. Но в если оно недостаточно корректно и реалистично отображает манёвры носителя, то эту проблему на моделировании могли и не увидеть.
1. Я все-таки отмету вариант «некомпетентности» наших ракетчиков и тоже 100% буду считать, что у них обязательно должна быть программа для моделирования и визуализации общей траектории движения всех модулей от старта до выхода на арбиту.
2. Второе утверждение тоже возьмем за 100% — это то, что «абстрактные» траектории сначала рассчитываются балистиками, а затем проверяются моделированием «конкретных траекторий» с отработкой уже конкретных маневров модулями.

А если так, то получается, что именно эта программа и сделала то самое ошибочное предположение дав зеленый свет аварийному пуску. Почему? Потому что в ней был забит алгоритм отличный от того алгоритма который реально прописан в модулях. Тогда тот, кто это допустил и есть виновник.

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

Собственно об этом и был мой самый первый комментарий:
Где симулятор полета? :)
Верно, вопрос только кем и почему так предполагалось по умолчанию? Ведь именно это предположение и не соответствовало реальности.

Очевидно, ноги растут со старых стартовых столов, где ракету вращали на земле и ей не нужно было совершать разворот в воздухе.
Как понимаю, изначально так как компы были весьма тормозные — запрограммировали делать расчёт очередного манёвра не перед его началом, а по завершении предыдущего (а первый соответственно сразу по включении на стартовом столе)
Ну а дальше «работает — не трогай»
:) Ну как же они могут быть рассчитаны хорошо, если не учитывают реальный алгоритм поворота Фрегата?
Ошибка именно в расчете траектории, если бы тот, кто рассчитывал, знал как работает Фрегат, он бы не выбрал курсы РН и РБ при которых они начнут поворачиваться в разные стороны и завалят миссию. Повторюсь: он бы задап курсы РН и РБ при которых бы они поворачивались в одну сторону и успешно вышли на орбиту (без какого-либо вмешательства в работу ПО РН и РБ).

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

Проклиная все, начинаешь учитывать. Работаешь как проклятый. Приходят снова: знаешь, у нас по твоим расчетам система ориентации такую джигадрыгу отчебучит. Давай это учтем.

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

Занавес.

О, у меня вот в связи с методами терминального управления вопрос к человеку, работающему в этой области.

Из-за всех этих ± пол-лаптя имеет наведение с закрытым контуром реальные преимущества перед наведением с открытым контуром на атмосферном участке?
Конкретнее: терминальное наведение может так заоптимизировать атмосферный участок под номинальные тягу и УИ верхней ступени, что при небольшом отклонении их от номинала потеря массы будет такая же, как и потеря массы от использования открытого контура управления?
Увы, но для меня полет РН — это не моя специфика. Моя партия начинается с момента отделения РБ и самого спутника.

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

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

В таких условиях вообще никто — то, что хоть так летает, уже чудо.
Начальник, как раз потому что
Компьютера нет и не будет, софта нет и не будет.
Симуляторов орбитальных космических полётов нет? Opensource симуляторов не помню (поправьте если не прав), но есть вполне серьёзный Orbiter, в последней версии разделенный на сервер симулятора и графический клиент. Так что прогнать на сервере моделирование запуска Союза и Фрегата с Восточного было вполне возможно.
Более того, суперкомеьютеров он не требует, рабочей станции вполне хватает.

С Orbiter я не работал, но VirSat гонял довольно активно на ноутбуке пару лет назад. Так что проблема скорее организационная, на мой взгляд. Если энтузиасты и студенты, полгода слушавшие спецкурс про спутники, могут промоделить полёт — уверен, в «Энергии» такие люди тоже есть.
Суперкомпьютер конечно не требуется, но одним Orbiter'ом дело не ограничивается. Orbiter это только внешнее окружение, дающее влияние атмосферы, гравитации и прочих сил.
Чтоб провести полноценную симуляцию тех алгоритмов, что написаны для Союза и Фрегата, нужно написать модели обеих систем со всеми датчиками, двигателями и прочим. В идеале они должны уметь загружать и исполнять непосредственно прошивки этих блоков. Эта задача несколько более масштабная чем просто ракету в Orbeter'е запустить. Но в целом подъемная и нужна, особенно с учетом стоимости ошибок.

При стоимости проектов и самих блоков в "охрениард денег", стоимость работ по созданию симулятора ничтожно мала и окупилась бы при первом же старте. Хотя, сомневаюсь, что у обеих систем (РБ И РН) отсутствуют свои симуляторы — никто не будет сразу на чистый лист прошивку писать. Просто надо было эти симуляторы "подружить" между собой и сделать пробный запуск на объединенном симуляторе.

И что вы собрались просчитывать на суперкомпьютер? Это не сворачиваемость белков считать. Симулятор вполне могли бы осилить, но никому там это не надо — даже камеры на ракету Союз не смогли установить, европейцы подсобили.

Мы не сверхбогатые США, нет в наших карманах столько денег, чтобы такое оплачивать!

Вообще-то есть, только не в наших с вами карманах, а из наших карманов.
Когда дело касается таких денег, нужно не лепить программы по кривым алгоритмам. Мы не сверхбогатые США, нет в наших карманах столько денег, чтобы такое оплачивать!

Вы сейчас сказали классическим анекдотом про армию: «не высыпаетесь? Это не проблема. Спите быстрее».
Когда я был маленьким, а Windows — глючным, у меня было впечатление, что я самый сильный на планете программист. И когда глюки винды (а по факту — мои мега кривые руки), совсем доставали, одолевала жуткая злость на Билли Гейтса: «Да я, да я щас все перепишу! Да где только таких тупых программистов берут?».
Каково же было мое удивление, когда я вырос и сам стал писать программы. Как оказалось, мне до уровня «кривоглючной» винды как до Китая на четвереньках.

Это я все к чему? Сказать «не ошибайся» — мало. Это не поможет. А вот что поможет — уже написали. Интеграционное тестирование.
А можете не вдаваясь в подробности рассказать зачем вообще ракете вращаться? Она не симметричная, в том смысле что какая разница каким боком лететь вверх, даже если не совсем вверх?
Теоретически, по крену ракета может лететь в любом положении, и твердотельная гиростабилизированная платформа (в которой уже не осталось гироскопов в рамках) сможет это отрабатывать. По тангажу и рысканию так не получится, конечно, потому что улетим не туда. В то же время в реальности углом крена управляют — может быть по традиции, когда был диапазон допустимых углов поворота рамок гироскопов, а может быть потому, что у полностью детерминированного полета будет меньше неожиданностей, чем если лететь со случайным углом крена.
может быть по традиции, когда был диапазон допустимых углов поворота рамок гироскопов


А сейчас его разве нет? ИНС-то до сих пор платформенные.
На Союзах вроде как уже используют Неортогональные блоки ВОГ, но я не знаю в качестве основного измерителя угловой скорости или где-то в резервном канале. В Прогрессе не знаю как дела обстоят.
Ну и непонятно почему алгоритмы не на кватернионах (параметрах Родрига-Гамильтона)?
А может и на кватернионах, но РБ не запрограммирован был перед отделением пересчитать свою ориентацию и кратчайшую дугу.
Вроде на кватернионах, но это дело не спасает. Проблема-то не в математическом вырождении углов, а в том, как Вы справедливо пишете, что РБ не запрограммирован был перед отделением пересчитать кратчайшую дугу (ориентацию-то он знал).
Я в общем случае отвечал, и для других ракет.
А какие ракеты сейчас на БИНС летают?
Ну, например, на Falcon 9 стоит LN-200 с лазерными гироскопами и MEMS-акселерометрами.
Не думаю, что совсем в любом. Двигатели всё-таки расположены весьма характерным образом и диапазон отклонения сопел скорее всего не равный в разные стороны. Но с дискретностью в 90 гр., скорее всего, вполне можно.
Просто ракета, разработанная в 50х годах прошлого века, умеет летать только в таком положении. А если переделывать — то проще новую сделать, столько там всякого ещё что надо.
На Байконуре и Плесецке её просто крутят вместе со стартовым столом, а тут научили поворачиваться после старта самостоятельно.
Союз-2 наверное и на Байконуре и Плесецке не поворачивают со столом, нет?
Смотрю на фото запусков — поворачивают.
Эээм, я немножко был на Байконуре, не заметил там «вращающихся» столов.
А ракеты любые всегда так летают, потому что (если сильно упрощать) выход на орбиту — это просто поворот по тангажу. Всегда. Чтобы изменять наклонение орбиты к этому повороту по тангажу добавляют еще один простой маневр — вращение на нужное кол-во градусов. И все. Два простейших маневра. А не «умеют летать только так». Шаттлы так летали, сатурны так летали, все так летают, потому что так проще и надежнее.
Есть. И именно у семерки. При ее разработке в середине 50х, чтобы облегчить систему управления решили поворачивать всю ракету со столом по направлению азимута стрельбы. Тогда СУ нужно было удерживать заданное направления, отрабатывая тангаж.

Причем хоть решение отчасти и красивое, но вскоре и получили недостатки метода. Пилюгин, при массе 8К71 в 270 тонн рассчитал СК на стартовую массу в 330 тонн. Но модификации «Семерки» быстро этот запас выработали.
Кольцо имеет 18 метров в диаметре, а не видно оно потому-что им со времён снятия с дежурства Р-7 не пользуются, и по-моему уже и не проверяют (где-то видел фотографию где оно почти заросло, но найти не могу). А ненужным оно стало потому-что с переходом на цифровую систему управления ракета-носители выполняют разворот самостоятельно, так что пишут что на «Восточном» от поворотного кольца отказались.
Смотрим внимательно этот ролик на 20х секундах :)

youtu.be/6oadjbVV0uM?t=17s

А в Куру и Восточном действительно отказались :)
окей, как-то пропустил этот момент вообще. Спасибо.
Просто не осталось программистов, полностью разбирающихся в старом коде и знающих, что, зачем и в каком месте сделано. Подозреваю, что он уже поддерживается, как шайтан машина-сюда кидаешь барана, отсюда выходят 4 палки колбасы. Что внутри-хз. Распространённая проблема с легаси кодом. Это в порядке предположения.
Распространённая проблема с легаси кодом.

Опыт Вояджера, Кассини, марсианских роверов, продление эксплуатаци Хаббла, показывают, что умение успешно работать со старым софтом на древнем «железе» может в разы повысить длительность и научную ценность космических проектов. В этом контексте вывод спутника на орбиту это еще идеальный случай в тепличных условиях — межпланетные исследования по определению длятся годами, если не десятилетиями.

Если Роскосмос не развивает культуру программирования, тестирования и поддержки «легаси» систем, и не считает её критически важной для работы, то это огромный организационный косяк.

Все ракеты так летают. У каждой ракеты есть базовая плоскость, плоскость тангажа. Как правило это связано с расположением двигателей, либо с симметрией ракеты, и с моментами, чтобы ею проще было управлять. Если это односопловая и одноблочная ракета, то такая плоскость выбирается либо через опорные места(4 опоры), либо между ними. Так удобнее. Честно говоря не знаю ракет, у которых эта плоскость меняется от старта к старту в зависимости от азимута пуска.
Если это многоблочная и многосопловая компоновка, то выбирается плоскость между блоками или так, чтобы проще было создавать момент для тангажа при отклонении сопел ДУ(Зенит, Ангара).
Если посмотреть на Фалкон-9 который был самый первый, еще с квадратным расположением движков, так он вообще чуть оторвавшись начинает вращение — www.youtube.com/watch?v=NREJEZ5eluk

угу — но тут поворот по ощущениям не превышает 45 градусов.
Это другой вопрос) Новые флаконы вообще особо не вращаются. Но, вы вспомните эпический Roll-maneuver Спейс Шаттла. Можно было ведь тупо платформу другой стороной ставить, однако в итоге конструкторские решения имели приоритет, а плоскость поворачивали таким вот красивым креном.
На «Союзе-2.1б» уже цифровая система управления, ее крутить не надо. В то же время, там, где есть поворотные устройства, их используют, почему бы не упростить задачу СУ?
Добрый день. Я в космонтавтике «профан», но интересуюсь, ибо интересно… Вот поясните — разве перед запусками не проводят эмуляцию старта на компьютере (или что-то подобное) чтобы проверить как будет проходить старт в каждую секунду времени?
Если бы была такая полная эмуляция в данном случае, проблему бы там и обнаружили. На устройства и компоненты есть программы тестирования, и для разных ракет и блоков они бывают разные. Там есть отдельные интересные ситуации, например, когда в блоке два трубопровода, тестовый и реальный. В тестовом трубопроводе все ОК, а реальный не работает нормально. Из-за этого была авария «Зенита», когда бортовой источник мощности отказал. А реальные трубопроводы в монтажно-испытательном комплексе не проверишь, потому что нужен будет фактически стенд для запуска двигателей.
разве есть гарантии, что эмулятор отработает аналогично аппаратному решению? или там используется та же программа?
UFO just landed and posted this here
Да, наверное правильнее сказать «симулятор», а не «эмулятор». Имелся в виду стенд с реальными СУ, на которые подавались бы виртуальные параметры полета.
Возможно, при наличном тестировании такое совпадение ускользнуло. ИМХО, не истина.
Из этого описания следует, что предыдущие старты — счастливая случайность.
Некорректное утверждение:
программа прекрасно работала для первоначальных условий, и надеяться, что ее сразу сделали под все возможные космодромы, не стоит

Аналогия примерно следующая, несколько грубая. Есть программа написанная 10 лет назад под WindowsXP, которая отлично работала. Но в Windows 10 нормально работать она перестала, так как, допустим, уже нет каких-то совсем уж древних библиотек от Windows 98, порезана политика прав доступа и всё такое. Это не означает, что разработчики криворукие кодеры, программа плохая и вся её предыдущая работа — случайность. Программа отлично работает в том окружении, для которого создавалась, тестировалась и отлаживалась, но изменились внешние условия, которые в изначальном ТЗ на программу были несколько другие.
Если система управления что-то решила час назад, а потом вдруг начала действовать никак не обращая внимание на возможные изменения условий — то что-то глубоко не так в консерватории. Ну а аналогия СУ сложным технологическим объектом с хомячковой ОС сама по себе опускает первую ниже плинтуса ;)
На хомячковой ОС с некоторыми подпилками вполне успешно работает софт АСУТП. Не стоит совсем уж принижать ей)

Возможно условия работы разгонно блока должна была обеспечить работа предыдущей системы до него. И именно этим руководствовались разработчики блока. Это знаете, сейчас всем всё просто и понятно и возникает резонный вопрос типа «Да как такое можно не предусмотреть, ведь это даже мне очевидно, а там сидят спецы космической сферы». Когда пилишь сложную систему порой некоторые простые вещи, действительно могут упуститься. Потом сидишь и думашь: «Как я мог этого не учёсть?» Для этого и нужно моделирование и стыковочные испытания. Проблема в том, что не всегда удаётся построить полную модель или провести полноценные проверки и вот такие вот косяки вылазят уже в эксплуатации. Хотя, лично мне, удивительно, что в 2017 году нет общей модели поведения системы.
Какие все умные у себя дома на диване-то.
А у разгонного блока, между прочим, после отделения всего минута на всё определение ориентации, расчёт поворота и сам поворот. Оглядеться, чтобы понять, где он, он тоже не может, из органов чувств датчик угловой скорости, три акселерометра, часы и модель гравитационного поля Земли. И процессор с частотой 100 МГц.
Конечно, лучше всё решить час назад, когда времени навалом, а после отделения действовать быстро и решительно, на раздумья там просто нет времени.
РБ вполне мог получить от ракеты-носителя в момент отделения точные текущие параметры ориентации и пересчитать необходимые углы.
На самом деле нет, РН ничего не передаёт РБ, если не ошибаюсь. Но свою ориентацию РБ и сам знает.
Ну, ориентацию, скорость и местоположение к моменту отделения РБ уже знает, так как непрерывно интегрирует уравнения навигации с самого старта. А расчёт поворота — вроде там не настолько трудоёмкие вычисления, чтобы занимать много времени. У Бисера-6 среднее быстродействие 600 тысяч операций в секунду :)
Вы немного лукавите. Определить на какой именно угол осталось «довернуть» он как-то умудряется прямо на ходу. А вот выбрать направление нужно обязательно заранее на земле?
Я могу предположить, что выбор направления поворота «на старте» является конструктивной особенностью, а не частью алгоритма. Т.е. он должен повернуть на +175, до этого «кто-то» его повернул на -174, он компенсирует и в итоге и выходит 175-(-174)=349. Для механических гироскопов очень гладенькая картина получается ;)
Разве что самую малость.
Я ж не знаю, как там разработка кода велась. Может, это было так:
— А у вас вот тут стоит проверка, не нужно ли вдруг повернуться больше, чем на 180°. В каком случае вообще может понадобиться такой поворот?
— Ну… Например, если с Байконура ракета уходит с курса более чем на 20°.
— И что, разгонный блок может такое выправить?
— Нет, при таком уходе в любом случае упадёт.
— Тогда убрать проверку, нет у нас после отделения на неё лишних 20 тактов.

Вполне же логичная история.
Так как предыдущая версия ракеты после старта не поворачивалась — то было всё равно когда определять, в момент старта или в момент отделения.
Для того, чтобы говорить, что и как надо было сделать — надо обладать полным пониманием того, что делает система во время полёта. А заодно, неплохо бы знать историю разработки, потому что технические решения это всегда продукт условий и ограничений, в которых их создают.
А рассуждать «как надо» обладая полной информацией об ошибке, это откровенный моветон. У любого человека в жизни можно найти ситуации, когда обладая послезнанием/всей полнотой информации становится ну совершенно очевидно, что так делать не надо.
UFO just landed and posted this here
Только она летает на миллионах комьютеров каждый день. И тем не менее не далее как месяц назад наблюдал бсод в десятке.
Аптайм 54 дня, перезагрузка только для установки критических обновление, что я делаю не так?
Железо у вас современное или производители такового переписали драйвера под новые реалии (Windows 10). У меня вот тоже раз в несколько месяц на ноутбуке 10-ка БСОДит из-за кривого драйвера реалтековского вайфай адаптера. Драйвера для него под 10-ку никто даже не писал, работаем с тем что есть.
Ну так в чем претензии то? Для свежего софта — свежее и топовое железо. Нет? Ну тогда более старые ОС. Логично же.

И так, по идее со всем надо. Но ракету с нуля не стали же разрабатывать — вот и полезли наружу потенциально проблемные места. Так и не удивительно.

Даже в глубине души радуюсь — ни в чем реально обидном не произошло ошибок или работы спустя рукава. Автор поста прав — это сложно-комплексная ошибка. И вполне простительна при таком стечении обстоятельств (новый космодром, старая ракета, ТЗ исходно N-летней давности).

P.S. Я разрабатываю аппаратно-программный комплекс для диагностики и проверки качества веб-ПО (можно с натяжкой назвать «тестировщиком»).

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

И это при том, что в гугле явно платят по более, чем нашим в Роскосмосе на позициях «программист».
UFO just landed and posted this here
Ну а аналогия СУ сложным технологическим объектом с хомячковой ОС сама по себе опускает первую ниже плинтуса ;)

Вы удивитесь, но сложность создания СУ космическим аппаратом несравнимо ниже сложности написания современных ОС. Количество строк кода в современных ОС на пару порядков больше, чем в системах управления космеческими аппаратами.


Разница же в цене ошибки, а не сложности разработки.

Я не удивлюсь, я это отлично знаю. Равно как понимаю, что если из современной ОС выкинуть свистелки, перделки, набор иконок и графический интерфейс, то ОС *сильно* похудеет. Но вопрос, как вы совершенно верно заметили, в цели, которую перед собой ставят при создании продукта.
Похудеет, но все равно останется сложнее самой сложной специализированной программы в силу своего общего, универсального назначения.

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

Скорее корректнее будет пример с использованием циклов в качестве задержек в дос, которые потом "внезапно" перестали работать.

Ну типа того. «По хорошему тут нужно дожидаться ответа и анализировать коды ответов, но пока для простоты давайте поставим задержку на 1 мс… Что, 1 мс мало? Ну поставь 100, все равно никто не заметит. Потом сделаем нормально»
Да, очень просто рассуждать о поведении системы спустя пару десятилетий после ее разработки) Почему вы не рассуждаете так: «В целях упрощения системы управления считать, что стартовые корректные условия работы системы обеспечивает работа предыдущей системы». Причем для своего времени, когда не было современных микроконтррллеров или ПЛИСов, а код для БК на каком-нибудь ассемблере писался такое допущение сильно упрощало разработку и построение всей системы в целом. И это было объективно оправдано. Тем более раньше старались делать борт как можно более проще (как следствие — надежнее), а все сложное запихивалось в наземку.

Я просто не знаю условий и причин принятия решений. Поэтому голословно обвинять разработчиков не берусь. Допускаю, что было так как выше написал. Но вполне допускаю и то, что для запуска процедуры коррекции параметров впооне достаточно было перезапустить алгоритм по внешнему сигналу от РН, который не был предусмотрен, а когда об этом подумали, то уже все было сделано и КД выпущена, для сигнала не нашлось свободного пина в применяемом разъеме и пришлось бы сделать перекомпоновку ряда элементов и… на это просто забили, т.к. все нормально и так работало и никому в ум не пришло, что Россия откажется от космодрома, который, по сути, сама и построила.

Не знаю… мне кажется неправильно обвинять инженеров отрасли в 90-ые и 00-ые годы, которые работали там чуть ли не за хлеб.
Скорее следует разобраться с теми, кто взял старые наработки, не проверив их на применимость в новых условиях, и понадеялся на авось.
Дороговатое «интеграционное тестирование» получается.
Хотя бы виртуальную эмуляцию бы запустили…

Вот мне интересно, те, кто говорят про ВИРТУАЛЬНУЮ ЭМУЛЯЦИЮ(вопрос о то, почему жирным шрифтом и тонкости отличия эмуляции от симуляции пока опустим) пробовали сами построить модель какого-нибудь физического процесса так, чтобы она адекватно отражала реальность? Правильно ли понимают сложность такой модели и то, что она все равно не выловит часть ситуаций?

Опечатался. Конечно «симуляция».
В данном случае было бы достаточно простейшей модели. Цель — проверить что заданная траектория в принципе «проходима» для ракеты.

Простейшей. Гм. Ну, видимо, вам виднее.
А что не так? Есть множество возможных моделей, среди них есть простейшая — которая не учитывает ни возможных отказов оборудования, ни внешних условий, ни погрешностей датчиков.

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

Вы в матлабе когда-нибудь строили какую-нибудь модель физического процесса? Построишь, например, модель передатчика, а потом по факту оказывается что из-за нелинейности передающего тракта на определённых частотах конечный результат получается несколько не тот, который ожидаем. И SNR в приёмнике не тот и работает он со срывами… и приходится вводить всякие поправки. А потом, через 20 лет тебе говорят: «Мы тут PLL модулятора заменили, так как таких же больше нигде нет». Для модели не изменилось ничего. Этот PLL как генерил ХХХ МГц, так и генерит, а какие вводить новые поправки ты сам не знаешь — непонятно что будет с сигналом на новом железе. Datasheet это конечно сила, но там не всегда всё написано в части всяких тонких моментов. Для этого надо делать и сделать.

Отмоделировать и симулировать хорошо чистую цифру и простые алгоритмы. Реальность обычно сложнее и модель стараются строить наиболее приближенную к ней. Если система разрастается экспоненциально, то неудивительно, что в модели что-то упускается даже алгоритмически. Я не говорю, что это хорошо. Это плохо. Надо стараться делать хорошо)
То есть к автору статьи по поводу пункта «Защита от Мерфи» у Вас, коллега, нет вопросов?
Нет, естетственно) Я уже писал о том, что некорректно всё сваливать на обычных инженеров. Ошибка не технического уровня, а системного:
Этому блоку уже 100500 лет, кто его делал давно уже не работают. Нынешний персонал разобрался что и где поправить надо. Поправил. Что-то недосмотрели — неудивительно, когда это софт/код/железка не твои, да ещё к ним и с ТО наверняка напряг, как это у нас традиционно бывает.

Другое дело, что сделать-то было сделано, но проверка в модели или на какой-то КПА не была проведена. Это вопрос не к штатному персоналу (горе-программисты), а к тем, кто планировал конкретно эту разработку, к системщикам.

Если вы это же имели ввиду, то извините — значит неправильно понял)
Но я не думаю, что вообще ничего не проверяли, совсем уж авось и так далее.
Ну железную и алгоритмические просчеты стоит все-таки различать.
К тому же в данном случае ошибка была не с областью немоделируемой динамики связана, а с вполне себе обычными диапазонами входных и выходных величин. Т.е. грубо говоря тестить надо не только с околонулевыми начальными условиями, но и несколькими начальными условиями распределенными по заявленной области определения (и тем более в критических точках, таких как pi, pi/2, где еще и деление на ноль может внезапно вылететь со всеми вытекающими).
>> Да, наверняка, бывает и такое, но такое впечатление, что часть аудитории GT считают, что в космической сфере работают исключительно студенты-стажёры по типу эникейщиков в офисах.

Угадайте с трех раз, кто составляет наиболее активное множество посетителей хабра, которое радостно перекрикивает количеством всех хоть сколько-то соображающих специалистов. А дальше простое проецирование.
Есть программа написанная 10 лет назад под WindowsXP, которая отлично работала. Но в Windows 10 нормально работать она перестала… Это не означает, что разработчики криворукие кодеры

Именно это (криворукие кодеры) это и означает. В Windows 10 работает даже Norton Commander 3.0. Учитывая сколько усилий прикладывает Микрософт для обеспечения совместимости работы с различным древним софтом написать программу для Windows XP чтобы она фатально перестала работать на Windows 10 нужно очень постараться.
В плане Windows соглашусь) Давайте поправлю аналогию, чтобы пояснить что я имел ввиду. Замените Windows XР на Debian 6, а Windows 10 на Debian 9. То, что какая-то программа работавшая на 6-ке не заработает на 9-ке, так как зависимости пакетов «поехали» не означает криворукость её создателя.
Нет, изначальным требованиям же софт соответствует. С Байконура, Плесецка или Куру это же «Фрегат» улетел бы успешно. С Восточного не на полярную орбиту тоже бы улетел кстати — углы были бы другие.
Я могу лишь повторить, подобная реализация — это огромная идейная дыра в системе управления. То, что она «выстрелила» именно сейчас — случайность. Может в 57 году на Байконуре первый взявший в руки палку инженер и осознанно использовал подобное решение (отдавая себе отчет в том, что делает здесь и сейчас). Но то что спустя 50+ лет ракета улетала с Плесецка и Куру (а улетала? я не в курсе), и не улетела с Восточного — это уже «повезло».

PS Давайте в моем тексте не будем цепляться за даты, названия и обобщающее слово «ракета» — все все поняли ведь?
Лучше говорить «Гвианский космический центр» («Гвиана», ГКЦ, CSG etc), а не «Куру». «Союз» из Синнамари летает.
Перепутать космодромы — это раздолбайство. Не сверять решения двух независимых систем — некомпетентность.

Если уж решения считаются отдельно и до старта (я даже не спрашиваю почему нет центрального управления всем этим), то они обязаны сверяться и в случае несовпадения до какого-то знака после запятой — выдавать предупреждения или вовсе блокировать запуск. Это основы защитного программирования.
Что-то не бьётся…
На первой картинке углы по крену (ракета в стартовом сооружении).
А на второй картинке углы по тангажу (разворот связки РБ+КА).
Вы были бы правы, если бы использовалась связанная система координат, где оси привязаны к строительным осям блока. А в данном случае использовалась другая система координат, где поворот по вертикальной оси воспринимался как поворот по азимуту. Системы координат в космонавтике используются разные.
Разъясню немного подробнее верхний комментарий.
Гироскоп сохраняет свою ориентацию в инерциальной системе координат. Соответственно, все повороты записываются относительно неё. Сразу после старта необходимый поворот является чистым поворотом по крену, т.к. ось поворота совпадает с продольной осью ракеты. Потом ракета поворачивается, и поворот вокруг оси, направленной из центра Земли на точку старта, уже будет не чистым поворотом по крену, а более сложным.
То, есть, получается, основной доворот после отделения Ф от Союза производился по рысканью? (те самые пресловутые 363 градуса)
да именно так (тангаж при старте около 90 при отделении около 0, соотв оси поменялись)
На сайте www.roscosmos.ru/24451 есть такие строчки:
Пуск прошёл бы штатно, например, летом, либо в случае, если бы районы падения отделяемых частей ракеты-носителя лежали в стороне от выбранных.

Как время года играет роль?
Не претендую на истину, но — наклон Земли влияет?
Видимо, летом пускают по другому азимуту. Если пускать зимой по такому же, то в районы падения ступеней нельзя будет добраться на сухопутном транспорте. А у нас принято всё упавшее аккуратно собирать и увозить для анализа.
А у нас принято всё упавшее аккуратно собирать и увозить для анализа.
Жителей Алтая Ваша фраза несколько бы удивила. (фото не мои, а первое, что попалось в Интернете)
image
На «Восточном» хвалятся тем, что находят ступени вертолетами и беспилотниками, а потом вывозят.
Это, конечно, очень хорошо. Но для Восточного проблема не так остра, т.к. с него не производятся запуски носителей на гептиле.
Возможно, будут искать и увозить на первых порах — чтобы успокоить местных жителей и убедиться, что всё падает где надо, а потом перестанут.
Про вывоз ступеней — это я взял из фильма «Ступени цивилизации» от Роскосмоса. Про вторую ступень, видимо, они слегка слукавили, что всё находят и вывозят.
UFO just landed and posted this here
Очевидно, тогда были бы другие азимуты. Сектор, в котором происходит авария очень узкий, градусов 10, небольшое смещение в сторону, и обе СУ начнут разворачиваться в одну сторону.
Мне кажется, на последней картинке у Вас неточность. Правильно ли я понял, что РБ нужно было повернуться на 363° по часовой стрелке, чтобы занять нужное положение? Тогда зелёная стрелка, показывающая его ориентацию до начала поворота, должна смотреть на 3° левее бирюзовой. Соответственно, поворачиваться он начал в правильную сторону, вот только не сообразил, что 363° — это всё равно что 3°, и не нужно делать лишний полный оборот.
Да, спасибо, исправил
Статья выдержана в стиле сдержанного оптимизма: «если у вас падают ракеты из-за каких-то сложно обнаруживаемых ошибок при старте с новых космодромов, то значит вы принадлежите 0.2% стран у которых есть ракеты и больше одного космодрома»
Не сочтите за занудство, но на нашей планете более 500 стран?
хмм… НЯП в ООН где-то 180 стран. А сколько еще стран и территорий, считающих себя странами (вместе с правительствами в изгнании) — не считал.
Но если вам от этого будет лучше, то пусть будет точка чуть правее: 02.% стран.

Все равно, для других стран, это как Интел: «мы столкнулись с проблемами при переходе на 5нм». Да, у всех остальных таких проблем нет. (Ну, может АМД им посочуствует). А у большинства — так и вообще никаких своих микросхем нет.
Неужели никакой симуляции полета не выполняется?
Очевидно, выполняется только частичная для отдельных систем. Полная бы выявила проблему.

Что я не поняла. Если на разворот РБ отпущена минута при скорости вращения градус в секунду, то рассчитанные изначально до старта 175 градусов… Это как, типа ок?


И почему в программе поворот сам по себе, а разгон тоже сам. Никаких флагов типа ПВРТ_УСПШН :).

Если на разворот РБ отпущена минута при скорости вращения градус в секунду, то рассчитанные изначально до старта 175 градусов…

Там до старта было — у ракеты -175, а у разгонного блока (РБ) +175. В процессе набора высоты, ракета крутится на 175 (это заметно на видео с ракеты): -175+175=0, и РБ тоже крутится: 175+175 = 350. Это же всего лишь на 10 градусов в сторону. «Вам лететь по другой орбите, так что все в пределах нормы», — говорит формула.

И почему в программе поворот сам по себе, а разгон тоже сам.

насколько я понял "околоракетных пользователей ФНК", то там ограничение на время маневра — 55сек. Т.е. если вы не развернулись за это время, то все равно уже поздно — передавайте привет атмосфере.
Если бы блок после отделения еще раз подумал, в какую сторону крутиться, ему нужно было бы исправить ошибку всего 3° (363-360), на это времени с лихвой хватит.
Это-то понятно. Но если СУ ракеты-носителя и РБ не общаются, то откуда РБ знать, что останется всего 3°, он без тени сомнения собирался-то вращаться на 175°. На лицо плохое ПО. Каждая система за себя. «К пуговицам претензии есть. — К пуговицам претензий нет.»
Но если СУ ракеты-носителя и РБ не общаются, то откуда РБ знать, что останется всего 3°

По показаниям интегратора угловой скорости. Без датчика угловой скорости на разгонном блоке всё равно не обойтись, поэтому на этапе работы носителя он считает, на сколько связка уже успела развернуться.
Кстати, а там именно ДУС? Можно ведь определять ориентацию просто по датчикам углов колец платформы. Как на практике в платформенных системах делают?
Честно говоря, это только моё предположение из таких соображений:
Если угол всё равно определяется по датчикам углов колец — то как там вообще такая ошибка могла возникнуть и какая бы вообще была разница, задавать угол поворота до старта или после отделения?

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

Я знаю, что есть интегратор ускорений. Но угловые скорости интегрировать? Зачем? Это в самом деле есть?
Интегрируя линейные ускорения, вы получаете линейные же скорости. Интегрируя второй раз — координаты. Аналогично, интегрируя угловые скорости, вы получаете углы, т. е. ориентацию объекта.
Ну я понял. Только гироскоп сам по себе уже угол показывает, без необходимости что-то интегрировать.
В БИНС у нас вообще нет гироскопов — только датчики угловой скорости (которые часто тоже называют гироскопами, что не совсем корректно — никакого быстро вращающегося твёрдого тела там нет). В платформенных же системах, действительно, можно снимать углы с осей карданова подвеса. Как именно на практике делается, честно говоря, точно не знаю. Чуть выше я уже задал этот вопрос Pand5461 — надеюсь, он прояснит.
Ок, спасибо за пояснение.
Да нет же! СУ Фрегата с самого старта самостоятельно решает задачу ориентации. Так что Фрегат знает, что он вместе с РН повернул на эти 363°-175°=188°.

Надо Роскосмосу сделать свою игрушку типа KSP с реальным ПО. И популяризация, и пиар, и бесплатная армия фанатов-тестеров.

Мдяяяя… Варгаминг со своим Wolrd of Tanks для популяризации военной техники и истории сделала в разы больше)
Ну, так эти игрушки — для прапорщиков.
Рекомендуемая возрастная группа, а так же минимально необходимое воинское звание и учетная военная специальность, увы, на сайте не указаны.
Говорят, лет 30 назад предлагалось выпускать армейские модели кубика Рубика:

  • монохромный (все грани защитного цвета) — для младшего комсостава;
  • монолитный — для старшего комсостава.
Моей жене на один из дней рождения подарили кубик Рубика 2*2. Мы шутили, что если она с ним не справится, то следующий будет 1*1 :)
По моему, у Вас неверные сведения. Мне этот анекдот буквально 2 дня назад рассказал наш инженер, там говорилось о монохромном для офицеров и монолитном для прапорщиков. Поскольку он сам бывший старший прапорщик, то информацию можно считать инсайдерской и нет оснований сомневаться в ее достоверности.
Ага. На движке SpaceEngine. Ябпоиграл :)
ecoruspace.me/inews_7682.html
«Для немедленного исправления ситуации будет проведена корректировка алгоритма системы управления пространственной ориентацией разгонного блока «Фрегат» и существующих регламентов, уже даны поручения по разработке новых современных комплексных методик имитации и контроля полетных характеристик средств выведения.»
Вот, хорошо что дочитал до вашего коммента. Плохо, конечно, что об этом подумали только сейчас, но хорошо, что мысль в правильном направлении.
UFO just landed and posted this here
Как я понимаю если бы КУРС РН был 354 а курс РБ был 344

В данном случае требуемый курс РН и РБ и были 354 и 344 соответственно.

РБ оценивает поворот на момент старта

Видимо, не сам поворот, а его направление. Конкретный угол, конечно, определяется уже после разделения, так как до старта точно неизвестно, на сколько повернёт ракета.

UFO just landed and posted this here
но разгонный блок перескочит нужный угол для разгонного блока, а тот продолжит вращаться в том же направлении


Не совсем понял Вашу мысль. Если РН и РБ будут вращаться в одном направлении, то требуемый угол доворота РБ будет сравнительно небольшим, а его знак подскажет направление. То есть если РБ решит вращаться по часовой стрелке, а требуемый угол доворота окажется, допустим, минус 5 градусов, то это будет означать 5 градусов против часовой стрелки.
Да. Проблема в том, что СУ РБ решает, куда крутиться только перед стартом. Если бы он еще раз подумал после разделения, то нужно было бы исправить всего 3° ошибки.
что вообще-то странно, ибо при разделении может иметь место и вращение по крену (нештатное, конечно же) — которое блок в общем может парировать одновременно с докруткой куда надо, а не порознь (сейчас он вроде вначале стабилизируется, потом доворачивает и снова стабилизируется — чисто что б не умножать сущностей и не усложнять алгоритмы, что исторически, конечно, правильно, но ёлы-палы, 2017-й год на дворе, народ на ардуинах алгоритмы уже посложнее реализует)
Объясните, пожалуйста, тупому (мне, то есть) эту фразу:
В момент отделения ошибка составила 363° (174°+175°=349°, очевидно, прибавились не упомянутые маневры ракеты), однако, вместо того, чтобы пересчитать направление движения, разгонный блок пошел по длинному пути.
Автоматика рассчитала, что надо сделать поворот на 363° и стала поворачивать на 363°? То есть полный оборот и еще 3°?
У меня когнитивный диссонанс от того, что я не могу понять процитированную фразу иначе, а далее по тексту написано, что с автоматикой все ОК на самом деле, так и надо.
рассчитала, что надо сделать поворот на 363° и стала поворачивать на 363°? То есть полный оборот и еще 3°

Я понял так же. А про автоматику в тексте нигде и не говорилось. Было сказано, что техника отработала правильно (т. е. не было отказов/нештатной работы двигателя, датчиков, бортового компьютера и т. п.).
и стала поворачивать на 363°?

Насколько я понял из поста и предыдущих обсуждений — нет. Автоматика вместо доворота на 3° пошла, как пишет lozga, по длинному пути — то есть начала поворот на 357 градусов (360-3).
Если в переменной просто хранилось число без преобразований и вычитаний 360°, то автоматика вполне могла насчитать 363°
по длинному пути — то есть начала поворот на 357 градусов (360-3)

Нормальные герои
всегда идут в обход!

Как так получается, что высококлассные профессионалы сверхширокого профиля, знающие ответы на любые вопросы науки, техники, политики, экономики и пр.пр., так грамотно комментирующие любые публикации на хабре и гиктаймсе, в большинстве своём не относятся к тем, кто принимает непосредственное участие в тех событиях, которые комментируют? Вы же знаете — как надо правильно делать. Сделайте. Или опять финансовый вопрос?
За всех я Вам не скажу, но за себя готов ответить. Хотите?

Я проработал в НПЦАП, который делает СУ для этого самого «Фрегата», 5 лет. А потом надоело и я стал искать новую работу. Почему? Ну, условия работы не очень комфортные были. Например, окна у нас в комнате были на солнечную сторону, а кондиционер всё никак не ставили, рассказывая вместо этого про планы устройства волшебной централизованной системы кондиционирования. Так что когда летом температура в комнате переваливала за +30, становилось слегка некомфортно. Кстати, и мозги от этого хуже начинают соображать — это к вопросу об ошибках в алгоритмах. Справедливости ради, коллеги, которые остались, говорят, что сейчас кондиционер всё-таки поставили.

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

В принципе я человек достаточно аскетичный и могу все эти неудобства перетерпеть, только вот проблема тут глубже — все эти бытовые вопросы на самом деле показывают отношение предприятия к сотрудникам. И отношение это очень простое: предприятию на сотрудников насрать. Именно предприятию как бездушной организации: я верю, что лично наш Генеральный директор (и другие начальники) очень хороший человек и искренне радеет за то, чтобы предприятию и сотрудникам жилось как можно лучше, но в силу тех или иных причин процессы на фирме выстроены так, что мы имеем то, что имеем. И при таком отношении энтузиазм и желание работать на предприятии начиная с какого-то момента начинает угасать. Упомянутый Вами финансовый вопрос, да, тоже имеет некоторое значение. Например, на новом месте мне на новенького положили в 1,65 раза больше, чем было в НПЦАП (справедливости ради скажу, что там, когда я собрался уходить, тоже предложили существенную прибавку и повышение в должности).

В заключение скажу, что выставлять всё исключительно в негативном плане было бы неправильно — я должен отметить, что мне в целом повезло и с начальством, и с коллективом, и задачи были очень интересные. И конечно, я считаю, что за эти 5 лет я очень вырос как специалист в своей области. Увы, но перевесила противоположная сторона.

P.S. Этот опыт с осторожностью нужно обощать на весь Роскосмос — даже у нас внутри НПЦАП разные позразделения могли заметно отличаться по условиям работы, адекватности начальства и т. п. Тем более заметной будет разница между разными предприятиями. Например, я знаю, что на некоторых предприятиях Роскосмоса хозяйственные вопросы решаются гораздо лучше, чем я описал. В то же время, есть и некоторые симптомы, довольно характерные для всей отрасли в целом.
И отношение это очень простое: предприятию на сотрудников насрать. Именно предприятию как бездушной организации: я верю, что лично наш Генеральный директор (и другие начальники) очень хороший человек и искренне радеет за то, чтобы предприятию и сотрудникам жилось как можно лучше, но в силу тех или иных причин процессы на фирме выстроены так, что мы имеем то, что имеем.
Предприятие, как неодушевленный объект, срать не умеет, и процессы в фирме выстраивают люди. Конечно, стул для Вас должен был обеспечить не генеральный директор, а какой-нибудь завхоз (или как его там называют), но то, что такие люди «сидят» (работой это назвать — язык не поворачивается) в фирме — виноваты именно люди, сделавшие такое отношение к работе нормой, видимо, в том числе, и гендир, что не мешает ему при этом быть очень хорошим человеком, но находящемся явно не на своем месте.
Не разделяю Вашей категоричности. Представьте себя на месте директора огромной (>10 000 человек) фирмы с большим количеством проблем, многие из которых тянутся ещё с памятных 90-х годов, а многие обусловлены внешними обстоятельствами, на которые Вы фактически повлиять никак не можете (законодательная база, директивы Роскосмоса и т. п.). А фирма делает сложнейшую технику, процесс запущен и его не остановить — есть контракты, есть сроки, есть неустойки за их нарушение… Задачи сложные и требуют большого количества согласований как внутри фирмы, так и со смежниками, которые тоже далеко не ангелы… Если у Вас в такой ситуации будет получаться хоть что-то — это уже неплохо :)

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

Я не то чтобы оправдываю сложившуюся ситуацию и не утверждаю, что наш директор был идеальный руководитель — в конце концов, мне и самому надоело всё это терпеть — но призываю к более глубокому анализу ситуации.
Представьте себя на месте директора огромной (>10 000 человек) фирмы с большим количеством проблем
не буду, даже чисто умозрительно. Я прекрасно знаю свои сильные и слабые стороны и никогда и ни за что не согласился бы на такую работу. А человек согласился и работает, никто его не заставлял, надеюсь. Соответственно, ссылаться на «проблемы, многие из которых тянутся ещё с памятных 90-х годов, а многие обусловлены внешними обстоятельствами» — это лишь отговорки. Создать сотрудникам нормальные условия работы и требовать от них ее качественного выполнения — это его основная обязанность, это никак не должно сказываться на контрактах и сроках, а наоборот, способствовать их соблюдению. Поэтому я и говорю, что человек, видимо, не на своем месте. Это касается только его профессиональных качеств, применительно к занимаемой должности, я вовсе не хотел хоть в малейшей мере его или Вас задеть или обидеть.
не буду, даже чисто умозрительно. Я прекрасно знаю свои сильные и слабые стороны и никогда и ни за что не согласился бы на такую работу.

1:0 в Вашу пользу :) А в общем да, я соглашусь с Вами относительно профессиональных качеств директора. Хотя надо сказать, что для того же Роскосмоса это далеко не самый худший вариант.
Когда-то читала такую книжку «И слоны умеют летать». Это IBM в середине 90-х годов, когда она была в предбанкротном состоянии. Позвали гендиректором Луи Герстнера (он и автор этих мемуаров).

Меня поразило, что когда IBM находилась на грани катастрофы, Герстнер работал размеренно и даже как-то расслаблено. Он пишет, что мне надо было подумать и я на пару дней поехал куда-то там отдохнуть. И этот человек сумел вывести гигантскую корпорацию из кризиса, в то время как его назначали с надеждой, что он всего лишь проведёт банкротство максимало мягко.

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

Так что «загруженность», «контракт», «сроки» и «руки не доходят» — плохие оправдания для руководителя.

Отличная история! И спасибо за наводку на книжку. Как будет время, обязательно прочитаю. На всякий случай уточню, что не летать, а танцевать :)
Мне вот это нравится из книги про первый рабочий день Луи Герстнера:

«Когда в 6:45 я подъехал к зданию IBM и подошел к входной двери, оказалось, что она заперта. Рядом с дверью было устройство для считывания карточек, но служба безопасности еще не выдала мне такую. И вот я, новый генеральный директор IBM, стоял и барабанил в дверь в надежде на то, что кто-нибудь обратит на меня внимание и впустит. Через некоторое время появилась уборщица, с недоверием оглядела меня, потом открыла дверь.»
Уволить нерадивого завхоза на самом деле очень просто — нужно просто взять и сказать «ты здесь больше не работаешь». Лично такую ситуацию наблюдал, прямо на каком-то совещании начальников отделов так произошло.
Нужно просто чтобы руки дошли рассмотреть возникающие вопросы.
Предприятие, как неодушевленный объект, срать не умеет, и процессы в фирме выстраивают люди.
Не так всё просто: Андрей Лазарчук, Петр Лелик. «Голем хочет жить», далее немного Переслегина и далее сами найдёте если интересно…

Если парой слов — то «личные особенности» оргструктуры практически не зависят от личностных особенностей составляющих эту структуру людей — внутри структуры люди действуют по правилам этой структуры (писаным и не очень), а если не могут/не хотят — то либо перековываются, либо отторгаются.
Собственно «оргструктуры» (конторы, фирмы, церкви, государства, армии etc) — это наглядный массовый пример неэлектронных ИИ, давным давно живущих «поверх» людей как элементной базы.
А я разве хоть раз сказал, что все просто?
Верно. Хороший человек это не профессия. Можно быть хорошим человеком и отвратительным руководителем. Вообще бытовым вопросам у нас традиционно уделяется мало внимания.
Большие организации — все такие… Чтоб решить маленькую проблему уходит куча времени
А, ещё у меня стул на колёсиках развалился, потому что был самый говенный, самый дешёвый — так я год не мог дождаться, пока новый купя

Я бы его уже за это время сам починил :)

Да даже зарплату тоже можно самому себе выдавать, но если вы такой самодостаточный человек то зачем вам вообще работодатель?

Я и работаю сам.
Или сказать так -я работаю в другой модели — где нужно быть очень изобретательным и уметь делать все по максимуму.
Починить стул это такая ерунда — я их много починил будучи CTO. — Никогда не считал что это вообще какая- то задача
Я бы его уже за это время сам починил
и тем самым создали бы прецедент, поощряющий бездельника и дальше так же относиться к своей работе.
Это не моя работа лечить или исправлять всех бездельников.
Это работа менеджмента и руководства
Мое дело — отлично делать работу и создать себе хорошие условия
Я с Вами абсолютно согласен и поступаю так же. Именно поэтому прекрасно знаю последствия такого подхода. Одно дело — разовый ремонт стула, и совсем другое — постепенное перекладывание всех «бытовых» проблем на сотрудника: стал подвывать куллер при включении — ну, пойди купи, принеси чек, мы все оплатим, сдохла батарея в UPS — то же самое и т.д… С некоторых пор стал замечать, что «отлично делать работу» и «создать себе хорошие условия» своими руками начинают конкурировать за мое время. Естественно, я выбираю первое, поэтому работаю со «сдохшим» UPS, а это уже — мои нервы, которые, как говорится в народе, не восстанавливаются.
Все верно. Вопрос в том что вы повышаете свою ценность — и можете требовать повышения з.п.
Не здесь. так в другом месте!
Ну, у меня в какой-то момент появилась мысль купить себе стул самому — своя спина-то дороже. Но примерно одновременно с ней появилась и другая мысль: пора менять работу. Так что покупка стула потеряла актуальность :)
Тоже верная мысль — если сть альтернатива- то новое место работы может принести больше!
Так в чем же причина аварии? На этот вопрос отвечают два слова — «интеграционное тестирование».

А я не согласен, что тут виновато «интеграционное тестирование».

Во первых, если бы алгоритм повороты был бы чуточку умнее, проблем бы не было.

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

В третьих, упомянуты «не упомянутые маневры ракеты», которые могут давать разные дополнительные углы.

В четвертых, никаких существенных условий при работе в связке по факту с РН не появилось.

Утверждение, что виноваты программисты, разрабатывавшие программное обеспечение «Фрегата» 20 лет назад, тоже неверное — программа прекрасно работала для первоначальных условий

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

По описанному — виноват «программист», сделавший ненадежный алгоритм расчета угла поворота. А ошибка — типичная для модульной арифметики или арифметического переполнения.
А я не согласен, что тут виновато «интеграционное тестирование».
Во первых, если бы алгоритм повороты был бы чуточку умнее, проблем бы не было

А для чего еще интеграционное тестирование? Если бы все было «чуточку умнее» — то оно не нуно.
Если заранее знать — что тут нужно чуть умнее — тут чуть надежнее
А для чего еще интеграционное тестирование?… Если бы все было «чуточку умнее»...

Можно было бы согласиться, если бы не упомянутый пункт 2:

Исходя из того, что работа РБ должна быть как можно надежнее, сам по себе РБ должен уметь выкручиваться как можно лучше из нештатных ситуаций.

Полагаю, что ситуацию с нештатной ориентацией и оптимальную ее обработку можно было бы учесть и протестировать («модульным» тестом) по-умолчанию.
В том то и дело что это не программирование.
У разгонного блока не бесконечный запас возможностей.
Он сильно ограничен во времени, в запасе топлива и прочее.
С экономической стороны и стороны эффективности.
И тестировать его на все возможные случаи в отрыве от РН — глупо.
В том плане что есть рамки, что он заточен под определенные варианты.
Ну смотрите, в статье написано, что:

В момент отделения ошибка составила 363°

А в интеграционном тесте было бы 174°+175°=349°, и все бы прошло без проблем. И, тогда, причем здесь интеграционные тесты?
Ой, я выше фигню написал про 349 и «без проблем», прошу не отвечать :-)
Я понял. Спасибо что написали.
Я думаю что у них в любом случае должен быть ( и есть возможно) стенд.
Стенд который эмулирует все условия для БК.
Датчики, положение. итд Котороый позволяет прогонять программу полета
Вот на этом стенде и сделать интеграционный тест с стендом для союза для конкретных условий ( космодром Восточный) — и вылезло бы СРАЗУ — как миленькая
Стенд быть должен, интеграционное и системное тестирование быть должно, но я все равно считаю, что данный дефект — чрезмерное упрощение такой важной функции, как оптимальная ориентация в пространстве. Для того, что бы ее отладить никакие специальные интеграционные тесты проводит не надо.
Проблема в том что ракету делает одна организация, а РБ — другая.
Соответственно привезти актуальную версию системы управления ракеты на стенд второй — проблема.
Проблема в том что ракету делает одна организация, а РБ — другая.

Ну в данном случае, разве это имеет значение?

Разве трудно сделать алгоритм, вычисляющий более-менее оптимальные параметры поворота на требуемый курс?
Ну так он и вычисляет. Только как оказалось слишком рано — теперь ракета поворачивается после вычислений, а не до них.
Ну, вот, что значит слишком рано? На всем протяжении полета Фрегат вычисляет, на сколько нужно повернуть.

Иначе, если бы Фрегат на старте зафиксировал 175 градусов, так и после любого разворота РН, фрегат бы стал поворачивать на 175.

Но это изначальное число 175 во время полета ведь меняется!

По моему мнению, у автора статьи запутанные объяснения про «слишком рано», «направление поворота» и т.п. И этим он еще путает читателей.
То и значит — все необходимые действия по крайней мере для первого включения вычисляются ещё на стартовом столе. Когда ракета всегда развёрнута по азимуту — так тоже можно — плюс удобней посмотреть что он там навычислял, пока кабеля не отключили.

Притом надо понимать, что блок не поворачивает на какой-то угол.
У него алгоритм такой — «дал импульс движком ориентации — дождался пока показания с гироскопа совпадут с целевыми — дал контимпульс».
То и значит — все необходимые действия по крайней мере для первого включения вычисляются ещё на стартовом столе.

Ну нет же!

175 — это начальное значение «счетчика», которое меняется во время полета (может увеличиваться/уменьшаться/меняться). Каким оно будет после отделения, Фрегат может и не знать, и это правильно. А после отделения совершается доворот на остаток — остаточное значение в счетчике.
Притом надо понимать, что блок не поворачивает на какой-то угол.
У него алгоритм такой — «дал импульс движком ориентации — дождался пока показания с гироскопа совпадут с целевыми — дал контимпульс».

Вот если было бы так, то, наверное, и аварии последней бы не было.

Потому что в статье показано, что нужно было довернуть на 3 градуса в ту же сторону, что и «задумывалось изначально».

Фрегат стал поворачивать в нужном направлении, только вовремя не остановился.
Смотря как там математика сделана. Если он сравнивает ориентацию с целевой — тогда да, через 3 градуса он остановит вращение. А если он именно выполняет поворот на требуемый угол (при этом текущий угол поворота вычисляется как интеграл от показаний датчиков угловой скорости), то РБ будет вращаться, пока не накопится этот самый нужный угол в том виде, в котором он записан в памяти: 363 градуса — значит, 363. Видимо, был реализован второй вариант.
то РБ будет вращаться, пока не накопится этот самый нужный угол в том виде, в котором он записан в памяти

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

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

Казалось бы, да. Но задним умом все крепки :) нужно понимать, что алгоритмы и программы достаточно объёмные, с большим количеством ветвей. За всеми особенностями их работы уследить трудно. Тем более, что для пусков с Байконура такой алгоритм вполне годился (там были такие углы, что РБ и РН всегда поворачивались в одну и тут же сторону, и результирующий угол всегда был сравнительно небольшим, лишних 360 градусов никак появиться не могло), а когда его стали адаптировать для Восточного, то за этим не уследили. Собственно, очень похоже на историю про то, как уронили Ариан-5. Казалось бы, тоже нет никаких проблем сделать «по уму» — выбрать такие масштабы/типы данных, чтоб никакие переменные не переполнялись. Однако вот не уследили же :(

И доработка ожидается минимальная.

Да, совсем простая. Гораздо сложнее было в принципе сообразить, что требуется доработка.
Казалось бы, да. Но задним умом все крепки :)

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

До этого ведь были случаи, что двигатели РН выключались раньше времени, и разгонный блок за счет запаса топлива и адаптивности исправлял ошибки РН.

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

Здесь, ведь, по-сути, тоже самое.
совершенно разное.
В том случае, когда РБ исправлял ошибки РН по скорости — это значит, что направление было правильное, и адаптивность была по времени выключения двигателя. А в этом случае — неправильное направление плюс жесткость времени включения.
Ну а в чем принципиальная разница скорости и ориентации?
Ну, опуская очевидный ответ (про с точки зрения физики\математики и логики), в данном случае — что они принимались, рассчитывались и управлялись двумя разными системами.
Ну понятно, что разными системами.

Но в чем принципиальное отличие? Почему при недоборе скорости ее компенсировать — это нормально, a при неправильной ориентации ее исправление — это какой-то «особый случай»?
В контексте именно этого случая — скорость не представляет собой многозначную функцию, т.е. если скорость V и V+x — это одно и то же, то x точно равен нулю.
Касательно космических полётов в целом — если в конце активного участка РН ориентация правильная, но не хватает 10-50 м/с скорости — разгонный блок может это вытянуть. Если ракета ушла с курса на 1 градус — значит, вектор орбитальной скорости нужно повернуть на этот один градус, затратив VI*sin(1°) = 136 м/с (VI — первая космическая). Это на самом-самом пределе запасов, придётся использовать резервы, предназначенные на сход с орбиты / переход на орбиту захоронения. Если ракета сильно отклонилась от курса, то уже бессмысленно корректировать, всё равно не выйдет.
Плюс к этому, затраты на коррекцию тоже растут с течением времени. То есть включить двигатель на 10 минут позже — это привет, океан вне зависимости от ориентации.
Поэтому и оставили жёстко минуту до включения по принципу «если уход из расчётной ориентации больше, чем на 50 градусов — запуск так и так уже не спасти».
Если ракета сильно отклонилась от курса, то уже бессмысленно корректировать

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

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

Оказался разгонный блок в космосе один одинешенек, все, дальше путь рулит сам, как хочет.
Система с меньшим зацеплением — это, например, когда двигатель и турбонасосный агрегат стоят на разных столах и не мешают друг другу резонансами. Да, проще разрабатывать и тестировать, но лететь-то им собранными в один блок.
БЦВМ и алгоритмы управления в ней заложенные — это не волшебная палочка, которая из любой ситуации за гарантированное время может найти выход, уложившись в запас топлива на разгонном блоке. Сам алгоритм наведения для общего случая гораздо сложнее, чем при заранее заданном времени включения двигателя, и при этом всё равно не факт, что нормальное решение существует при абсолютно любых начальных условиях.
Вот и приходится лезть в ненужные детали, чтобы систему сделать проще, надёжнее и удобнее для тестирования.
В статье написано неправильно:

В момент отделения ошибка составила 363° (174°+175°=349°, очевидно, прибавились не упомянутые маневры ракеты), однако, вместо того, чтобы пересчитать направление движения, разгонный блок пошел по длинному пути.


В таком случае (поворот со 363° на 360°) не нужно менять направление, а (по факту) повернуть в том же направлении, как и было задумано изначально, но только на 3 градуса.

lozga, я прав?

Ну и на этой картинке тогда тоже ошибка, зеленый вектор должен быть левее бирюзового направления, а не правее:

image

И -да. По опыту — гораздо сложнее и менее эффективно выдумывать сложные тестовые случаи — чем пользоваться реальными — когда есть интеграция- как случай использования.
Но конечно для этого нужна хорошая модель итд
Хреново с безопасностью в Россиянской Федерации, скорей всего кто-то спецом внес коррективы чтобы ракета упала. Нужно искать крота
Все он праильно говорит — кроты есть.
Только искать их не нужно
ИХ все часто по телеку видят :)
Они хитро замаскировались :)
Этот «баг» с поворотом на больше 180 градусов специально был заложен- вдруг Потенциальный Противник ракету скомуниздит, да со своей старт-площадки шмальнуть решит? А координаты-то отличаются от «привычных» системе управления- тут она понимает, что ее хотят использовать не по назначению и разворачивает ракету обратным курсом.
Еще в мемурах Чертока рассказывалось про искушение объявить аварию диверсией, чтобы не искать причину. И было это лет 50 назад. Не стоит давать волю паранойе и выключать мозги.
А какой конкретно случай имеется в виду, не помните?
Книга 2, глава 4
23 сентября и 12 октября 1958 года были проведены первые пуски ракет Р-7 в лунном варианте. Оба пуска закончились однотипными авариями — разрушением пакета на конечном участке полета первой ступени.

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

Качество телеметрических записей было вполне достаточным для пристрастного поиска признаков возникновения отказов в системе управления или агрегатах двигательных установок. Однако многочисленные специализированные группы исследователей аварии 23 сентября явного криминала не обнаружили. Принимать решение о следующем пуске без объяснения причин аварии и проведения каких-либо мероприятий было недопустимо. Но Хрущеву было обещано попадание в Луну, поэтому долго размышлять и рассматривать телеметрические пленки и записи, не принимая решения, времени у нас не было.

Кто-то из потерявших надежду быстро раскрыть тайну разрушения ракеты мечтательно высказался, что если списать это на диверсию — типа незаметно приклеенной магнитной мины, то никаких мероприятий, кроме повышения бдительности, не потребуется и можно будет продолжать пуски.
Спасибо! Прочитал эту главу. Очень поучительная история.
Безотносительно причин аварии, получается, перед импульсом РБ не проверяет свою ориентацию, и, возможно, вообще выдает его по таймеру? Вроде как уже давно верхние ступени набортно, в реальном времени рассчитывают свою траекторию и автономно пытаются подогнаться под рассчётную, нет?
РБ на незамкнутой траектории деваться некуда. Либо включаешь двигатели, авось успеешь довернуть, либо гарантированно падаешь. Небольшие шансы лучше никаких.

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

Причём тут незамкнутость траектории? Тебя отделили от носителя и дальше — давай сам: смотри, где находишься, в каком положении, и по сигналу ошибки (отклонения траектории/положения от расчётной) давай импульс. А то получается: ну-ка прикинем ещё на старте, куда рулить, когда отцепят, и будем считать градусы до того… А зачем? Вот когда отцепят или перед этим — вот тогда и нужно определять, в каком ты положении.
при том, что если через минуту не дашь импульс — то утонешь однозначно, без вариантов, а если дашь «вслепую» — то даже при нештатной закрутке — 33%, что кривая вывезет (а без неё — вообще близко к 1) — пусть на нерасчётную, но всё же замкнутую орбиту, а там уже срок жизни недели-месяцы, а не минуты — пусть Земля по телеметрии разбирается, что не так и как исправить. Очень грамотное решение, ибо у системы ориентации очень много шансов заглючить (гироскопы с их рамками-упорами и складыванием плоскостей, астродатчики. слепнущие от солнца, акселерометры, вычислитель с алгоритмами на пределе по выч. мощности (реал-тайм ос вообще-то)), много больше, чем у третьей ступени в конце пути иметь слишком неправильный вектор. даже без ориентации вообще, тупо по таймеру дать импульс — лучше, чем не дать.
Вы написали про то, что делать, если информации — ноль. Но ведь это — не тот случай.
«Заглючить» включает в себя и «выдаёт неверные/невалидные данные». (кто-то датчик кверх ногами прикрутил ага) Если систему ориентации говрит что мы едем ж. вперёд — то есть два варианта на самом деле — что действительно едем и надо крутиться, и что она сдурела и надо её игнорировать. Опыт предыдущих поколений показывал, что механика надёжнее электроники, сейчас это не так, но даже сейчас наоборот — не всегда.
Исправить всё равно никак, ибо приёма команд не предусмотрено.
Во-вторых — запас до «утонуть» на порядок больше и вообще не факт что был известен тем кто алгоритм вводил.
В-третьих — блок может и гораздо энергичней поворачиваться
я не специалист, а только почитал ФНК, там тоже посчитали что по формулам он теоретически может быстрее крутиться.
Но пришел некто и сказал, что у РБФ есть много ограничений на угловую скорость, и в том числе гироплатформой: у нее есть приоритетные плоскости, по которым она может более энергично поворачиваться, чем по другим (ЕМНИП тангаж — быстро, а рыскание и крен — нет).
Я к тому, что "все сложно" :)
Ограничения само собой есть, и бачок с топливом для ориентации не бесконечный.
Но если бы компу поставили задачу «надо за минуту повернутся на 357 градусов»…
… и в конце остановить вращение и стабилизироваться, включая успокоение плещущегося в баках топлива (там как раз четыре раза по полбака)… всё сложно
А никто и не говорит что просто… топливо в баках теми же движками ориентации вниз поджимают.
Речь не о вниз, а о том, что оно плещется. Вот раскачайте воду в ванной — гравитация её вниз получше движков поджимает, однако это не мешает ей плескаться. А плещется там почти полторы тонны, при массе ПН чуть меньше трёх и всей связки меньше пяти. И плещется вразнобой в разных баках да ещё по-разному по всем осям. Поэтому большие-длительные угловые ускорения нельзя.
Ну чтобы не плескалось — внутри перегородки-успокоители должны быть…
Они есть и уменьшают. Но не устраняют. Ибо весят.
Да, а вот кстати — при быстром повороте его не начнёт мотать непонятно куда из-за эффекта Джанибекова или несовпадения оси вращения с главными осями эллипсоида инерции?
у РБФ есть много ограничений на угловую скорость, и в том числе гироплатформой:
Из-за гиростабилизированной платформы есть ещё одна беда: по двум осям у неё вращение без ограничений, но вот по третьей — всего лишь ±40°
Вот и вопрос — что происходило с осями ГСП в процессе такого неожиданного (для РБ) поворота РН.
Зак, на которого ссылка в начале статьи, пишет, что как раз примерно через 50° ГСП встала на упоры.
ГСП встала на упоры.
Поскольку поворот на 50° происходил в зоне радиовидимости — должно было быть подтверждение в телеметрии (потеря готовности ГСП).
Однако же ни в одном из официальных заявлений на это нет даже намёков.
Да, логично.
И с russianspaceweb фраза про «гироплатформа встала на упоры» тоже исчезла.
А ограничение в 40° — из угловой дальности активного участка проистекает?
Нет, это конструктивное ограничение именно ГСП, применённой на Фрегате.
Пруфа, к сожалению, дать не могу (по оборудованию Фрегата публикаций вообще крайне мало).
блок может и гораздо энергичней поворачиваться
Поворот по крену — только двигатели СОЗ.
А вот выполнять поворот по тангажу и рысканью можно ещё и смещением сопла МДУ (± 30 мм), причём это считается предпочтительным (нет расхода топлива ДУ СОЗ).
Возможно, на это и был расчёт — «через минуту включаем МДУ, заодно и на нужный вектор доворачиваем».
Сильно сомневаюсь, что расчёт был, скорей заложили как в прошлый раз.
Для этого надо переписать весь алгоритм управления с нуля.
Кто на это деньги и людей выделит?
так вроде не за бесплатно спутники запускают
Дык если бы у нас совпадали те кто деньги получает и кто работает…
Довольно странно, что разгонный блок не согласует время включения двигателей с собственной ориентацией. Черт с ним, с углом поворота, это правда сложно реализовать правильно когда пишешь все на ассемблере или каком-нибудь модула-2. Но почему старт двигателям разрешен в нештатном положении блока относительно траектории?

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

Мне кажется, вина в аварии лежит исключительно на софте (прошивке) разгонного блока.
Насчёт «Окончательно», это Вы зря. Вот, поясните этот градус: «курсом 354°». Учитывая то, что все известные карты траекторий выведения с Восточного и зон падения отделяемых частей говорят, что траектория должна быть с i=98° (азимут 346°). Да и азимут на Вилюйскй улус тоже 346...347°. Ну не может, ни РН в целом, ни третья ступень в частности, идти курсом 354°.

Объясняю чисто геометрически. Возьмём зарезервированные районы под приводнение 3-й ступени в Атлантическом океане (NOTAM A0558/17, A1711/17, A0574/17) и построим орбиты i=98° и i=98.57° (наклонение Метеора):

Теперь взглянем на эти орбиты в момент старта Союза:

Видим, что незамкнутая траектория третьей ступени должна иметь наклонение i=98.57±1.5°, т.е. азимут 344±1.5°. А «курсом 354°» это что-то нездешнее, собственно к курсу отношения не имеющее.

Второй момент, Вы пишите что разгонный блок после отделения должен был изменить наклонение орбиты (азимут). Но это похоже не так. Похоже, что третья ступень что бы попасть в зоны в Атлантике уже должна была встать на нужный курс. Пробуем, пускаем Союз сразу на орбиту i=98.57° с апогеем 788,9 км (после второго формирования орбиты он должен был стать перегреем Метеора-М):

Попали.

Пробуем на орбиту i=98° с апогеем 788,9 км:

Увы, не попали, угол не тот.

P.S.
А насчёт угла 354°, при разборе этого пуска, единственно где я его самого углядеть — это азимут по земной поверхности от Восточного до зон в Атлантике, но рекеты же так не летают, не ориентируются. Похоже же на то, что тот кто назвал этот угол не в ладах с баллистикой.
P.P.S.
Можно было обосновать за третью ступень и без симуляции, только из геометрии и элементарных соображений.

Орбита с i=98.57º проходящая по центру зоны приводнения в Атлантике пересекает широту Восточного на долготе 129.45ºE (разница 1.12º), т.е. гандикап — 269 секунд. Поскольку до момента отделения головного блока на 563 секунде, средняя скорость примерно раза в два меньше орбитальной, третья ступень может надёжно попасть в зоны приводнения.

А вот орбита i=98º проходящая по центру зоны приводнения пересекает широту Восточного на долготе 130.49ºE (разница 2.16º), т.е. гандикап — 518 секунд. Поэтому третья ступень с таким наклонением не имеет возможности приводниться в заданном районе. Она же не может зависнуть в пространстве на 100...150 секунд. ;)

Вывод, практически железо-бетонный, третью ступень планировалось направить по незамкнутой орбите с наклонением i=98.57º. А все домыслы, что в полётном задании (или до отделения) Фрегата планировалось корректировать азимут, как минимум, испорченый телефон.
Вращение Земли не забыли?
За время полёта третьей ступени (около 20 минут, так?) наша планета успевает повернуться примерно на 5°.
Не забыли :) Заметим, вот если про него забыть, то тогда и вылезет это пресловутое «должна была лететь курсом 354°» ;)
Дело в том, что ракета после отделения первой ступени выполняет маневр по азимуту. Именно там может быть переход с курса 354° на курс 344°.

P.S. Отличные иллюстрации, вы новый сценарий под условия сделали или нашли готовый?
Всё это похоже на типичную российскую проблему под названием «поиски стрелочника».
На мой взгляд — проблема в системе. Система должна быть прозрачной и показывать затраты на оборудование и разработчиков. А показывает то какие-то мутные схемы с откатами на «барабаны страдивари» (сколько там на восточном украли), то больных кладовщиц с неправильно выданным припоем (не в данной цепочке конечно, но всё-же тот же роскосмос), то вот программистов, якобы не знавших азы геометрии (не ну серьезно доворот на 360?) и якобы это никто не проверял 20 лет.
На самом деле, да, я — верю — ошибки бывают, и стрелочник ее точно совершил, но это как раз нормально. Не нормально, что ее не обнаружили за 20 лет. Система должна быть заточена на поиск и исправление. И интеграционное тестирование — это лишь малая часть цикла разработки. Его не было. Видимо, не было симуляции и тестов устойчивости с рандомно изменяющимися параметрами. Ни разу минусовые градусы не были в рандоме. Один раз прогнали на симуляторе и типа всё ок?
А эти оставленные заглушки на фрегате, которые обнаружили перед стартом?
А предыдущее падение френата с двумя спутниками галилео? Там тоже речь была о програмном обеспечении фрегата.
А телеметрия, Карл? Где? С начала 90х поют одну и ту же песню про горизонт. Но с тех пор сколько уже группировок связных спутников выведено. Не было никакой возможности поставить телеметрию и передавать ее через эту группировку?
Что-то не похоже, что вице-премьер, по образованию журналист, стоящий во главе этого карнавала был грамотен в построении правильной системы.
А эти оставленные заглушки на фрегате, которые обнаружили перед стартом?

Вам больше нравится, когда их обнаруживают после старта?
А предыдущее падение френата с двумя спутниками галилео? Там тоже речь была о програмном обеспечении фрегата.

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

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

Собственно, все эти случаи показывают, что задачу разработки ПО надо рассматривать для связки носитель + РБ + космодром, при изменении чего угодно нужна ревизия и, возможно, тестовые запуски (если уж у нас не всегда получается написать софт с первого раза, что бы это не признать).

Я вот не считаю, что расчёт направления поворота до старта и потом тупое вычитание поворота носителя является однозначно ошибкой программиста. Всё зависит от ТЗ, по которому это делалось. Если в ТЗ было явно обозначено, что все углы заведомо меньше 180° — всё сделано верно, из критичной по времени части убрана проверка с заведомо известным результатом.
на днях ракету одной американской фирмы

А причем тут америка? Американцы по-вашему тоже при наличии проблем кивают на Россию, типа «там тоже»? Ведь нет же.
И основная причина там была в замораживании трубопроводов системы ориентации газом наддува основных баков

а тут пишут —
iz.ru/news/575880
«из-за некорректной работы системы управления, изготовленной московским ФГУП «Научно-производственный центр автоматики и приборостроения имени академика Пилюгина» (НПЦАП). По словам источника «Известий» в Роскосмосе, скорее всего, нештатная работа интегрированной системы управления стала результатом ошибки в программном обеспечении, заложенном на борт. В результате разгонный блок получил неправильное полетное задание»

задачу разработки ПО надо рассматривать для связки носитель + РБ + космодром

Я не понял ваших возражений. По-вашему это программисты должны были сами решить что нужно связывать разработки лавки и пилюги? или всё-таки система должна быть правильно построена и изначально связать эти две-три конторы более плотным образом. Во втором случае — и кто же ее построил неправильно и не предусмотрел такие связки?
а тут пишут —

А в более поздней статье тех же «Известий» пишут, что всё-таки замерзание гидразина.
А причем тут америка? Американцы по-вашему тоже при наличии проблем кивают на Россию, типа «там тоже»?

Охохо, посмотрели бы вы утром американское ТВ. Они кивают не «там тоже», а «всё оттуда». В отличие от этой страны, правда, по своим тоже проходятся.
Но вообще она тут при том, что дефекты перед стартом и неожиданное поведение космической техники — не исключительная прерогатива Роскосмоса, но на этом ресурсе почему-то принято Роскосмос втаптывать в грязь даже за отзыв потенциально дефектных блоков, а других хвалить «вот, молодцы, следят за качеством».
То, что ошибку в софте не углядели — ну ёлки-палки, новый космодром, там же столько всего нужно учесть. Про то, что в программе, отработавшей правильно уже больше 60 раз подряд, может быть недокументированный фатальный недостаток — как-то людям не подумалось (пить шампанское под «Славу России», пока с разгонного блока даже не получена ещё телеметрия, — это всё равно, конечно, свинство, тут спору нет).
или всё-таки система должна быть правильно построена и изначально связать эти две-три конторы более плотным образом

Надо связывать или надо оставить так — не берусь сказать. Но нужно понимать, что ракету с другого космодрома пустить — это не поезд перегнать с полустанка на полустанок. Что-то мне подсказывает, что наверху (возможно, даже и не в Роскосмосе) тупо не посчитали нужным выделить ещё денег и времени на интеграционное тестирование и нормальный анализ. Оно же как наверху думается — главное чтоб ракета со стола ушла, а там Байконур, Куру, Восточный — воздух везде одинаковый. И руководство Роскосмоса, я думаю, понимает в целом ситуацию, но не в том положении, чтобы сказать «мы не можем запустить с Восточного Союз с нормальной нагрузкой, дайте нам Союз под массогабаритный макет для тестирования» — в итоге взялись и лажанулись.
Охохо, посмотрели бы вы утром американское ТВ


Передергивать не нужно. Когда американцы свои неудачи в комосе покрывали фразами «а вот у них в России там»?
А телевидение — да, я его, американское, смотрю время от времени, радио слушаю каждый день по пути на работу и новости в и-нете читаю. Нигде там Маск или там НАСА или Бэзос не приводят в пример Россию что мол дескать да, у нас неудачи, а видели бы вы что в России.

Надо связывать или надо оставить так — не берусь сказать

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

тупо не посчитали нужным выделить ещё денег и времени на интеграционное тестирование и нормальный анализ


Наверняка так и есть, но это всё-таки догадки. А пока все обвинения, судя по статье — в адрес программистов, типа они сделали ошибку и в этом вся причина. Не провели интеграционное тестирование. Окей. А кто его должен был проводить? Программисты — это исполнители. Организаторы все сидят выше. Они и получают бабки за то, чтобы система в целом работала.
Нигде там Маск или там НАСА или Бэзос не приводят в пример Россию

Комаров тоже никого в пример не приводил, это лично моё напоминание. И что-то к Маску и НАСА нет такой лютой ненависти за любую неудачу (Безос пока не в счёт).
Невозможно не связывать. Иначе оно не стыкуется.

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

В статье как раз написано «Утверждение, что виноваты программисты, разрабатывавшие программное обеспечение «Фрегата» 20 лет назад, тоже неверное».
Ответа на вопрос «как эта ошибка / особенность программы добралась до Восточного» в отчёте комиссии, к сожалению, нет. И главная проблема, собственно, в этой закрытости, а не в самой программной ошибке.
«мы не можем запустить с Восточного Союз с нормальной нагрузкой, дайте нам Союз под массогабаритный макет для тестирования»
Зачем? Первый запуск с Восточного уже был, вполне успешный. Что ещё испытывать?
100% что массогабаритный макет улетел бы вполне штатно — как, собственно, штатно улетел и Фрегат. К Союзу-то претензий нет!
Называется, поленишься один раз написать «связку Союз-Фрегат» — потом будешь писать ещё больше.
Вообще, ситуация с зоопарком «Союзов» и кучей площадок запуска для них сложилась какая-то патологическая. На Восточном как построили стол для «Союзов», так и вообще будто забыли, что к нему новая ракета вообще-то предполагалась. В итоге вся космическая промышленность, такое ощущение, клепает эти «Союзы», а КБ занимаются их адаптацией к новым условиям запуска вместо освоения новых технологий.

Ещё "Прогрессы" клепает. А что ей ещё клепать? Хрун уничтожен, шепелявый мэр расстарался. А это значит что Ангары не будет. Более того, Протона не будет, по крайней мере длительное время. Скоро военным да ГСОшникам надо будет Флаконы арендовать для пострелять своими гаджетами.

Все-таки азимут в данном случае равен 351 градусам. (направление стрельбы 354). Север от плоскости I-III повернут на 9 град
Это ж если б Земля не вращалась бы. А так да, азимут на область падения третьей ступени, скажем центр зоны NOTAM A0558/17 9°18'С 46° 8'З, действительно был 354º ;)
Так стартовый комплекс вместе с Землей вращается. Если мы берем инерциальную систему координат, которая в центре Земли находится. В момент старта эти оси направлены именно так, как на рисунке, и в момент старта ракеты система замораживается в точке старта, а ракета уже относительно нее летит.
Судя по тексту получается, что на «Бризе» нет системы определения координат (пространственных и угловых), а система управления включает двигатели по данным, заложенным ещё до момента старта — это вместо того, чтобы делать это по сигналу ошибки — по разнице между заданным и текущим положениями? Иначе почему она «решает», куда поворачивать ещё до старта?

С другой стороны, уже если она «сообразила», что надо куда-то доворачивать, значит система определения координат таки есть. Но тогда ошибка при «зашкале» на больше 180 градусов — это однозначно результат халтуры. Сколько было случаев, когда при запусках не всё шло гладко, то есть, аппарат мог оказаться непредвиденном положении, но потом какие-то ошибки частично компенсировались, пусть за счёт дополнительного расхода топлива… А такая компенсация ошибок должна предусматривать корректную работу в произвольном диапазоне углов и положений.
Вот да. Поэтому и возникли вопросы о алгоритмах СУ за которые почему-то влепили минус. Очень уж интересно было бы посмотреть на них, тем более, что даже набортное железо сейчас много чего реализовать позволяет.
Знаю, что еще в нулевых в США верхние ступени весь матан считали сами, и пытались как-то вытянуть поближе к целевой траектории, но нужно освежить в памяти, конечно.
Во-первых, на «Бризе» такая система есть.
Во-вторых, речь в статье не о «Бризе», а о «Фрегате».
В-третьих, на «Фрегате» она тоже есть.
А, ну да, извиите, перепутал «Бриз» с «Фрегатом», уж не знаю почему… Ну, а по существу — есть мнение?
Тут вопрос не мнений, а фактов. Конкретный угол поворота СУ определяет уже после отделения РБ с учётом актуальных данных об ориентации. Перечитайте статью внимательно, пожалуйста: то, что вместо расчётных (на земле) 349° оказалось 363° — это как раз уточнение по результатам измерений в полёте. На земле же определяется лишь направление вращения исходя из примерных априори известных значений этих углов. Зачем так делается — не очень понятно, но так уж вот.
На земле же определяется лишь направление вращения

Вот поясните мне, что вы понимаете под этой фразой? Причем здесь направление вращения?
Попробую так: на земле принимается условное направление вращения: мы решаем, направление в каком вращении считать положительным. Это не значит, что поворот будет именно в эту сторону: например, если РБ насчитает, что нужно повернуться на минус 5 градусов по часовой стрелке, то он повернётся на 5 градусов против часовой.
Согласен, положительное направление оси — это более корректная формулировка, чем «направление вращения».

Потому что направление окончательного поворота РБ с положительным направлением оси никак не связано.
Ага. Ну то есть в случае РН речь идёт именно о фактическом направлении вращения, а в случае РБ — именно об условном положительном направлении, которое определяется перед стартом так, чтобы поворот из исходного положения в расчётное требуемое осуществлялся по кратчайшему пути. То есть если бы никакой РН не было, а с самого начала поворот делал бы «Фрегат», то для него это как раз было бы направлением фактического вращения.
Такое ощущение, что правильное объяснение еще более простое чем «на земле определяется направление поворота». Если цифра в 363 градуса — правда.

В РБ есть переменная, которая отвечает за угол на который надо повернуть, и при маневрах она постоянно пересчитывается. Но ее забыли «закольцевать» на 360 градусов — а потому 3 градуса и 363 оказались разными значениями. Ну а раз там написано 363 — то и поворот пошел на 363…
Всё верно. Но возникает другой вопрос — почему в этой переменной вообще оказалось 363 градуса? А вот ответ на него как раз и заключается в том, что РН и РБ приняли для себя разные направления поворота.
В РБ есть переменная, которая отвечает за угол на который надо повернуть, и при маневрах она постоянно пересчитывается. Но ее забыли «закольцевать» на 360 градусов

Ее нужно кольцевать на 180 градусов с соответствующей сменой направления положительной оси поворота.
Проще на 360, но с нулем посередине.
Не думаю, что сдвигать ноль на 180 проще. Я бы даже сказал, опасно.

Я говорил не о сдвиге ноля, а о сдвиге области значений.


Нормализация величины в таком случае будет задаваться формулой (x % 360 + 540) % 360 - 180, где % — взятие остатка, это лишь на одну операцию сложнее обычной формулы (x % 360 + 360) % 360 (правда, если остаток считать по определению Кнута, то оказывается уже на 2 операции больше: (x + 180) % 360 - 180 против x % 360).

Ok, понял, что имелось в виду.
Нет, зачем? Направление положительной оси менять не надо, это просто математическая абстракция. Проще всего действительно вычитать составляющую, кратную 360.
Если бы сделали закольцовывание на 360, то при случает в 363 было бы все ок, поворот на 3 градуса.

А в случае 357 что было бы? Поворот на 357…
Поэтому надо закольцовывать не [0, 360), а [-180, 180).
Да, я был неточен. Короче, нужно вычитать 360 столько раз, чтобы результирующий угол лежал в пределах от -180 до 180. Видимо, Вы имели в виду то же самое :)
Короче, нужно вычитать 360 столько раз,
а потом РН закрутят в обратную сторону, спутник приводнится и добавят «и добавлять 360 столько раз»
Уж не говоря о том, что поворот должен быть +-180, а не 0-360.
И кстати, а на момент отделения блок не закручен был? Может поэтому 270 в попутном выгоднее, чем -90?
Вот интересно, а в современных вычислительных комплексах уже решена проблема жесточайшей нехватки ресурсов памяти?
В этом большом обсуждении мелькнул вопрос о быстродействии, мол, рассчитать направление поворота можно успеть только заранее, до старта, потом «мозги» заняты другими расчётами и к моменту отделения надо уже это знать.
А вот про то, что любая ветка алгоритма — это лишняя память, никто так и не вспомнил.
Как было интересно читать про вояджер, про марсианские миссии, мол там благодаря программистам наэкономили десяток ячеек памяти и удалось воткнуть ещё один эксперимент или прибор и подпрограмму для его применения.
Неужели эту часть оптимизации сейчас никто не делает и вот так взять и учесть новые ветки алгоритма это раз плюнуть и надо было просто это сделать?
Уже даже в микроконтроллерах за доллар памяти сколько надо.
А «Новые горизонты» только собранной информации десяток гигабайт передали
А сколько памяти в микроконтроллерах за доллар?
Нашел какой-то STM8L051F3 за доллар. ОЗУ — 1 килобайт. Чего-то как-то мало, мягко говоря.

Memories
– 8 Kbytes of Flash program memory and
– 256 bytes of data EEPROM with ECC
– Flexible write and read protection modes
– 1 Kbyte of RAM
Ну это мелкий, надо типа STM32F030CC смотреть
Там 256к флеш и 32 озу, не считая прочего.
А вообще в этой серии бывают 2М флеш и 384 озу. Ну и выше — на полноценном 400 мгц ядре.
Для большинства применений достаточно именно такого соотношения код программы+константы/рабочие данные
Если надо больше — используют внешнюю память, там хоть гигабайты храни.
Уже даже в микроконтроллерах за доллар памяти сколько надо.
А «Новые горизонты» только собранной информации десяток гигабайт передали

Нашел информацию, что каждый процессор в компьютере Новых горизонтов стоит $20-$40 тыс. долларов:

Mongoose-V: The Mongoose-V is a radiation hardened and enhanced version of the venerable MIPS R3000 processor running at 15MHz made by Synova. As of August 2012 Mongoose-V processors are $20,000-$40,000

И, видимо, имеет пару мегабайт SRAM на борту.

www.mips.com/blog/mips-in-space-inside-nasa-new-horizons-mission-to-pluto
На борту там возможно только кэш, а не всё кучей.
Ну да, указано, что там 2 кб. кэша данных и 4 кб. кэша для инструкций.

Если надо больше — используют внешнюю память, там хоть гигабайты храни.

Только внешняя память подключается с коррекцией ошибок, а не просто так.
Вот, блин. Процессор стоит $40000, а там такое:

...If a single bit error has occurred, it is
corrected and passed to the processor and the
EDAC Cerror{ XE «csEDAC Cerror» } bit is set in
the Status Register{ XE «rStatus Register» }.
The corrected data is not written back to memory
and software scrubbing is responsible for this
function
...
Все правильно. Нельзя позволять накапливаться ошибкам в данных только потому что эти данные редко читаются. Поэтому обязательно нужен таймер, который будет периодически пробегаться по памяти и исправлять ошибки пока их еще можно исправить.

А когда на платформе появляется такой таймер — то исправленные при оперативном чтении данные становится уже не обязательно сразу же записывать обратно, эту операцию можно отложить до очередного обхода таймера. Такое решение одновременно упрощает процессор и делает работу с памятью стабильнее по времени.
Ну на самом деле не так уж и усложнит процессор соответствующая фича, но в целом вы правы — при работающем скраббере это not mandatory. Другое дело, что при обнаружении ошибки появляется категорический императив — взять и исправить, прям вот руки чешутся, хотя бы на уровне софта. А такой возможности практически нет (то есть конечно есть, но придется голову между ног просовывать). Я это к тому, что например когда я делал скраббер однажды (софтовый, аппаратный сделать мы могли, но не стали), причем для весьма малого объема ОЗУ, то из-за высокой интенсивности основных операций период контроля был адский, что-то типа четверти часа. Правда это было не космическое оборудование и по расчетной интенсивности потока отказов мы проходили.

К слову, ради интереса и для общего развития, вот лично вы обычно как скраббер делаете?
Интеграционное тестирование здесь не причем. Проблема в недостаточной величине окна времени от момента разделения до включения двигателей. Всегда может что-то случиться и разворачиваться придется долго. Программа полета должна была быть рассчитана на наихудший вариант кинематического состояния РБ после отделения.
Допустим, его бы после отстрела еще бы закрутило. В принципе, программа полета должна предусматривать такую ситуацию.
Программа полёта рассчитана на то, что кинематическое состояние РБ после отделения находится в пределах, оговоренных при согласовании процедуры разделения с разработчиками носителя.
Если состояние систематически выходит за эти рамки — тогда надо спрашивать с разработчиков носителя, почему не обеспечивают.
Если при анализе причин выясняется, что дешевле выправлять силами РБ — только тогда нужно менять программу РБ.
Здесь именно что при смене космодрома не прошло / неправильно прошло пересогласование состояния связки перед разделением.
Так состояние связки было в пределах нормы.
Просто не учли, что раньше ракета разворачивалась на азимут до включения и расчёта, а теперь — после.
Я бы все-таки сказал, что основная, фундаментальная причина аварии изложена в следующих двух коротких цитатах:

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

То есть, банальная техническая отсталость, увы… Вот так, на жестких предзаложенных установках, можно было летать в 20 веке (да и то в последнем его десятилетии уже стало некузяво). В 21 веке СУ должны все-таки обладать и оперативной situational awareness, и гибкой ее отработкой!
Не техническая — а административная.
Какой приказали алгоритм закодировать — по тому и работали.
В этом тексте ВСЕ ПРЕКРАСНО!
В «Роскосмосе» заявили, что полетное задание для ракеты-носителя «Союз-2.1а» готовили для запуска именно с Восточного, но рассчитать азимуты было «невозможно»

В «Роскосмосе» не согласились с вице-премьером Дмитрием Рогозиным, который обвинил специалистов компании в ошибке при настройке ракеты. Полетное задание для ракеты-носителя «Союз-2.1а» с разгонным блоком «Фрегат» было разработано без ошибок, сообщает «Интерфакс» со ссылкой на пресс-службу госкорпорации.

«Полетное задание прошло проверку именно для космодрома Восточный, что и было проверено специалистами в соответствии с существующими методиками», — заявили в «Роскосмосе». У аварийной комиссии и комиссии, специально назначенной вице-премьером Рогозиным, вопросов по этому направлению не выявлено, добавили в госкопорации.

Причиной аварии «Роскосмос» назвал сочетание нескольких возникших параметров на космодроме Восточный, а именно «азимут стартового стола космодрома, азимут полета ракеты-носителя и разгонного блока (именно солнечно-синхронной орбиты и именно для этого времени года)». Азимуты было «невозможно выявить существующими математическими моделями».
Знаете, тут я поддержу «Роскосмос» даже зная, что они лукавят. Просто чтобы Рогозин не стоял умный один в белом пальто красивый.
Да, конечно — именно так и надо
Все штатно сразботало- никто не в чем не виноват
Всем премии
Так не надо — в идеальном мире.
Но ситуация разворачивается в реальном мире и в конкретной стране, и я исхожу из того, что любые чистки по инициативе сверху закончатся только заменой в госкорпорации ещё нескольких неудобных людей на удобных.
Глобально — конечно, надо выходить на безаварийность запусков (хехе, мыши — становитесь ежами). Но это же надо работать систематически, а не только после эпичных отказов бросать всё и разбираться (естественно, с требованием со всех отчётов, наказанием невиновных и награждением непричастных).

Articles