Comments 350
Когда дело касается таких денег, нужно не лепить программы по кривым алгоритмам. Мы не сверхбогатые США, нет в наших карманах столько денег, чтобы такое оплачивать!
Я за такую работу из фирмы ссаными тряпками гоню, причём не за саму ошибку, а именно за баранье «никто не виноват». Может, поэтому у нас крупных провалов не бывает?
а включив двигатель и увидев по акселерометрам, что вместо разгона пошло торможение, не выключает двигатель для спасения миссии
Тут где-то уже обсуждалось, что если поворот в течение минуты не завершён, то выключай-не выключай двигатель — миссию всё равно не спасти.
И как они собирались довернуть на 175* при старте, если было меньше минуты на разворот. Всё равно неясно.
Кстати, это очень похоже на памятную историю с Арианом-5
По-моему, это больше похоже на такой случай:
11 февраля 2007 года 12 истребителей F-22 не смогли перелететь из США в Японию из-за возникших проблем с навигационным программным обеспечением (предположительно из-за пересечения линии смены дат посреди Тихого океана)
А ещё с нулевым меридианом (деление на ноль, все числа nan, полный отказ навигационной системы) и с нулевой широтой (экватором, кто бы мог подумать что синус знак меняет при пересечении оси y, как следствие самолеты попереворачивались и полетели кверху ногами)
При полёте над Мёртвым морем.
Над Астраханью они бы летали на высоте 10км и было бы все ОК. А то, что им было бы сложно делать там посадку — так может это дополнительный бонус.
А кто виноват тоже обозначено — не была проведена проверка имевшегося алгоритма с новыми условиями запуска. Но это уже вопрос интеграции, а не изначального проектирования\исполнения работы на местах, зоны ответственности разные.
Я за такую работу из фирмы ссаными тряпками гоню, причём не за саму ошибку, а именно за баранье «никто не виноват».
Типичная ошибка руководителя, который считает себя умнее подчинённых. У такого руководителя и в мыслях не может быть, что виноват он сам, потому что просто не сумел организовать работу. В итоге страдают ни в чём не повинные рядовые сотрудники, а руководитель выходит сухим из воды, ведь он нашёл виновных.
… увидев по акселерометрам, что вместо разгона пошло торможение ...А как это «увидеть» по одним только акселерометрам? Есть нехорошее подозрение, что для аппарата движение по траектории есть то же самое, что свободное падение, соответственно акселерометры изначально (после выключения ДУ блока И) показывают ноль (с точностью до шума). Тогда с точки зрения акселерометров после включения двигателя «Фрегата» в любом случае идёт разгон. Что-то подсказывает, что «увидеть» можно, только принимая во внимание пространственное положение вектора тяги, а с этим-то как раз и напортачили.
Может, поэтому у нас крупных провалов не бывает?Искренне рад за вашу фирму.
Тогда с точки зрения акселерометров после включения двигателя «Фрегата» в любом случае идёт разгон.
на самом деле нет, акселерометры же не жёстко привинчены к корпусу «Фрегата», а установлены на гиростабилизированной платформе, т. е. измеряют не продольное ускорение, а ускорение в инерциальной системе отсчёта.
Мне тоже совершенно не нравится примирительный тон этой статьи. Предположим, никто из подрядчиков не виноват. Типа, как в ТЗ написано, так и бахнули. К пуговицам претензии есть?
Но в любом проекте всегда есть генподрядчик — тот кто пилит основные деньги, но и отвечает за результат. Кто отвечает за пуск? Роскосмос и лично мсье Комарофф? Жирный вице-премьер? Где коммюнике ТАСС и розданных люлях?
Я вот тоже делаю проекты, и не надо спрашивать о масштабах, это не имеет никакого значения. Я — интегратор и отвечаю за результат. Я подбираю компоненты (хотя частенько мне их предлагают как состоявшийся факт) и я увязываю их в единый комплекс, выполняющий задачу. Самый частый вопрос к поставщикам компонентов: "Ребята, а вы вообще тестируете вашу продукцию?", настолько часто косяки лезут сразу после включения и видны невооружённым осциллографом взглядом. Но ничего, разбираемся, меняем оборудование, заставляем допилить прошивки, корректируем проект. Факапов, подобных этому не было никогда, хотя всяко бывало.
По данному инциденту можно сказать что прошли те времена когда для понимания причины глюка надо отстрелять десяток ракет. Для проверки интеграции компнентов в данном случае не надо даже строить дорогостоящий стенд, достаточно обычного настольного компьютера чтобы прогнать циклограмму полёта даже с реальными боркомпьютерами. И этот косяк вылез бы сразу. Да, пришлось бы отложить пуск, может быть и на месяцы, да пришлось бы вложиться в исправление "прошивок", но… дальше сами дополните…
По-моему, вместо попыток сгладить ситуацию надо признать уже очевидное: под управлением финансиста и патронажем журналиста Роскосмос скатывается в говно. И с этим надо что-то делать если, конечно, кто-то из начальства заинтересован в развитии русского космоса.
В результате, когда ракета повернулась на 174 градуса, они добавились к углу, на который собирался повернуть разгонный блок.Если мы ищем крайнего, то очевидно, что линчевать нужно человека, который рассчитывал полную траекторию полета ракетоносителя и фрегата. Именно он ошибся не учтя, что фрегат начнет работу с уже выполненным поворотом на 174 градуса. А учесть он это мог, если бы знал откуда запускается ракета и как работает ее ПО. Почему на оборудование с огромной стоимость не делается симуляторов — тоже загадка, либо симулятор есть и ошибка как раз-таки и была в этом симуляторе рассчитывающем траекторию. Тогда виновен создатель симулятора.
Фраза в статье не верна:
Так в чем же причина аварии? На этот вопрос отвечают два слова — «интеграционное тестирование».На самом деле — была ошибка в расчете траектории полета, и Мерфи здесь не причем :) А вот причина ошибки траектории имеет как минимум 2 возможные причины описанные выше.
ракетоносителя
ракеты-носителя.
Именно он ошибся не учтя, что фрегат начнет работу с уже выполненным поворотом на 174 градуса
Это-то как раз учтено. Не учтено, что РН и Фрегат захотят поворачиваться в разные стороны.
Если мы ищем крайнего, то очевидно, что линчевать нужно человека, который рассчитывал полную траекторию полета ракетоносителя и фрегата. Именно он ошибся не учтя, что фрегат начнет работу с уже выполненным поворотом на 174 градуса. А учесть он это мог, если бы знал откуда запускается ракета и как работает ее ПО.Не противоречит утверждению «Не учтено, что РН и Фрегат захотят поворачиваться в разные стороны». Так как если бы тот, кто рассчитывал траекторию, знал как работает Фрегат и как работает РН, то очевидно, он бы увидел, что при повороте РН на 174 градуса, Фригату придется выполнить заведомо обреченный поворот в 363 градуса.
По факту, реальная проблема при расчете траектории — в незнании как работает ПО + в отсутствии или не корректной работе симулятора. Иначе можно было бы задать курсы РН и РБ при которых бы они поворачивались в одну сторону и успешно вышли на орбиту (без какого-либо вмешательства в работу ПО РН и РБ).
Не противоречит утверждению «Не учтено, что РН и Фрегат захотят поворачиваться в разные стороны». Так как если бы тот, кто рассчитывал траекторию, знал как работает Фрегат и как работает РН, то очевидно, он бы увидел, что при повороте РН на 174 градуса, Фригату придется выполнить заведомо обреченный поворот в 363 градуса.
Всё же не совсем так. Сами траектории баллистиками просчитаны хорошо, и эти расчёты учитывают всё, что нужно, в том числе и поворот на 174 градуса — ведь по факту оказалось, что Фрегату после отделения нужно двоернуть всего на 3 градуса. Но в силу того, что бортовой алгоритм не учёл врашение РН и РБ в разные стороны, 3 градуса превратились в 363.
Сами траектории баллистиками просчитаны хорошо:) Ну как же они могут быть рассчитаны хорошо, если не учитывают реальный алгоритм поворота Фрегата?
Ошибка именно в расчете траектории, если бы тот, кто рассчитывал, знал как работает Фрегат, он бы не выбрал курсы РН и РБ при которых они начнут поворачиваться в разные стороны и завалят миссию. Повторюсь: он бы задап курсы РН и РБ при которых бы они поворачивались в одну сторону и успешно вышли на орбиту (без какого-либо вмешательства в работу ПО РН и РБ).
ведь по факту оказалось, что Фрегату после отделения нужно двоернуть всего на 3 градусаНе согласен.
Курсы РН и Фрегата при старте определяет тот, кто рассчитывает траекторию. Именно он и ошибся. Согласитесь, для того чтобы построить правильную траекторию нужно знать как работают устройства, которые выполняют маневры, если вы не знаете как устройство выполняет заданный маневр, вы не сможете построить правильную траекторию. Получается он не знал, как работает Фрегат, и что при выходе на курс, выбранный РН маневр поворота на 174 градуса окажется фатальным для маневра выбранного Фрегатом.
Тут проблема в том, что для такого дорогостоящего оборудование не проводится симуляция. Была бы симуляция, увидели бы этот косяк и подправили траекторию. Ведь проблема не в алгоритме, у РН и РБ автономный алгоритм работы (это разные устройства, РБ не может знать, что делается в РН), то что маневр Фрегата рассчитывается на земле, а не динамически в полете наверно не прихоть разработчика, а какое-то аппаратное или другое ограничение (не думаю, что в ракетостроении работают глупые люди).
Хотя есть вариант, что команды на маневр рассчитываются заранее в общей программе и потом просто копируются на отработку в РН и РБ, тогда да — ошибка действительно в алгоритме этой общей программы расчета, которая задала этим устройствам разные направления вращения.
Итого:
Если РН и РБ это автономные устройства, каждое из которых работает по своей программе, которой задается курс назначения для которого она рассчитывает маневр — то виноват тот, кто рассчитывал траектории.
Если маневры для РН и РБ рассчитываются за ранее в общей программе, и в устройства копируются не заданные курсы, а уже необходимые маневры — то виноват программист делавший программу. Но тут может быть проблема с тем, что программа была предназначена для запуска с другого космодрома и там всегда работала корректно… тогда получается виновен во всем человек, принявший решение использовать программу с другого космодрома без симуляции ее работы для условий нового космодрома.
Может эти все люди, которые принимали решения. уже давно на пенсии. А остались только люди, которые принимают НЕрешения — продлить, оставить в силе эти решения?
Вот я вам еще вариант подкину — все было проверено и промоделировано, только симулятор несовсем точный — не предусматривал, что кто-то повернет ракету на 360.
Проходят года, РБФ отлично летает, спасает огрехи ракет-носителей, и он торжественно уходит на пенсию.
И вот, новый запуск с нового космодрома. Все внимательно читают документацию и жмут кнопки калькуляторов.
«Ага! 1 секунда — 1 градус», торжественно говорят ракетчики.
«А когда он отделится от ракеты — у него всего 60 секунд до атмосферы» — рассчитывают баллистики.
«Хорошо», — говорят ракетчики: «мы выведем его не более чем на 10 градусов отклонения по курсу. Ну на 20 градусов вбок, в худшем случае».
«Ладно», соглашается программист РБФ, бережно выставляя руками уставку на первое срабатывание маршевого двигателя в 55 секунд. «Даже если эти артиллеристы на 40 градусов промахнутся, наш надежный РБФ будет иметь запас в 15 секунд и всех спасет», — втайне думает он.
Все документы подписаны, ключ на старт.
Разгонный блок ждет свою гироплатформу, после чего обсчитывает надобный курс на -175 (условно) градусов и готовится не пропустить свой выход.
Ракета стартует, делает поворот на свои 175 (условно) градусов, и прилетает в точку прощания с РБФ, с идеальным с их точки зрения курсом — даже меньше чем 10!
И только пассажиры самолетов над северной атлантикой полюбовались приветом всем от прерванной «бочки» РБФ…
Разумеется, баллистикам не всё позволено: траектория, которую они определяют, должна быть «проходимой» — т. е. тяги двигателей, запасов топлива, прочности конструкции и пр. должно хватить на все линейные и угловые ускорения. Но если траектория в принципе «проходима» — дальше это уже дело алгоритмистов правильно реализовать управление. Я считаю, что в этом вопросе баллистики не должны подстраиваться под особенности работы алгоритма без крайней необходимости. Тем более, что алгоритм может быть довольно сложным и запутанным, с большим числом ветвей. Я видел эти алгоритмы, там сам чёрт ногу сломит :) Совершенно не дело баллистиков в них разбираться.
Я считаю, что в этом вопросе баллистики не должны подстраиваться под особенности работы алгоритма без крайней необходимости.
Вот именно, и эта гибкость программистов должна быть не случайной, а сознательно развиваемым основным принципом работы.
Допустим, вы ответственны за развитие космической отрасли, что можно сделать, чтоб это было именно развитие?
— Отменить формулу Циолковского? Увы, не получится.
— Изобрести новое топливо и двигатель к нему? Это, конечно, нужно делать, но до серийного производства пройдут годы, если не десятилетия, и стоить будет миллиарды.
— IT? А вот в IT у нас с 70-х (полёты на Луну) прогресс просто колоссальный!
Вертикально посадить на баржу отработавшую ступень? Для человека ужас-ужас, а бортовой компьютер щёлкает такие задачи как семечки, даже с учётом ветра и дрейфа плавучей платформы.
Электронщики не могут надёжно защитить старый процессор от космических лучей? Так благодаря успехам микроэлектроники мы в тот же объём и энергопотребление уместим куб 3х3х3 из 27 микрокомпьютеров, которые сообща выдадут правильную команду при полном отказе половины из них. За последнее десятилетие человечество сделало огромный скачок в алгоритмах распределённых вычислений и установлении консенсуса при постоянно сбоящем железе.
Мегабайты и мегагерцы на ракете растут медленнее чем в потребительском секторе? Да, это так, но для наземеных испытаний можно купить кластер серверов с толстыми графическими карточками и за смешные по космическим меркам деньги получить терафлопсы для обработки данных испытаний и для численного моделирования.
Программисты живут в идеальном мире без физических ограничений, где, в отличии от производства двигателей, половину материала для работы можно за десять минут склонировать с GitHub. В случае неудачи программист просто откатывается к предыдущему коммиту, в то время как другим нужно заново строить разрушенный взрывом стенд. Было бы крайне глупо не использовать это преимущество и заставлять баллистиков подстраиваться под софт.
Так всё верно, но посмотреть прогресс методов управления ракет — такое чувство, что он нулевой со времён Спейс Шаттла.
Для Шаттлов разработали алгоритм, который решал задачу выхода на заданную орбиту с квазиоптимальным управлением, и всё это делалось полуаналитически, но при этом довольно точно. Подробнее алгоритм написан в книге «Баллистика и наведение летательных аппаратов» Сихарулидзе (доступна с сайта РФФИ) в районе 300 страницы. Но ограничение — профиль тяги со временем должен быть известен, т.е. времена включения-выключения двигателей жёстко зафиксированы.
Современные работы смотрю — предлагают делать на борту прямое численное решение задачи оптимизации по 32+ переменным. Получается правильно, но сложно, в десятки раз дольше шаттловской схемы управления и без такой физико-математической красоты.
С атмосферным участком ещё понятно, но вот оптимизировать промежуток времени между, скажем, отделением разгонного блока и его первым импульсом неужели нельзя как-то попроще на лету?
С атмосферным участком ещё понятно, но вот оптимизировать промежуток времени между, скажем, отделением разгонного блока и его первым импульсом неужели нельзя как-то попроще на лету?
Представьте себе картину: Вы разгонник, вы только что отделились от РН и понятие не имеете где вы находитесь.
И для начала надо как-то определить текущую орбиту. Для этого нам нужно время, пока мы получим достаточно количество фазовых векторов от навигационной системы.
Сколько ждем? Для точного определения желательно виток, ну ладно, хотя бы треть.
Что, 12 секунд? А почему? Как незамкнутая орбита? А, чтобы тонну топлива с собой не нести для лишней борьбы с атмосферой.
Так, постойте, если мы на незамкнутой орбите мне надо срочно поднимать перигей. Где это делать всего лучше — в апогее. Так, где у нас апогей, да он уже здесь, все включаемся!
Вух, подняли перигей. Так народ, а мы сейчас вообще где, нам надо определяться. Так, стойте, почему у нас аргумент перигея далек от целевого?! А, вектора были с большой ошибкой, понятно.
Ну ничего, сейчас все исправим. Так, где надо включаться — А вот тут, на 150 секунд раньше чем предполагали эти тупые человеки. Все народ, включаемся, полетели.
А в это время на земле тупые человеки изо всех сил пытаются обнаружить и войти в контакт с внеземным разумом, который они сами и запустили.
www.rfbr.ru/rffi/ru/books/o_1779714#1 (глава 7)
Из более новых:
arc.aiaa.org/doi/abs/10.2514/2.4712?journalCode=jgcd
arc.aiaa.org/doi/abs/10.2514/1.36084?journalCode=jgcd
то что маневр Фрегата рассчитывается на земле
Всё-таки нет: манёвр (конкретный угол поворота) рассчитывается уже после разделения с учётом фактически имевших место манёвров ракеты. На земле лишь принимается условное направление вращения: по сути мы лишь решаем, направление в каком вращении считать положительным (если бы РБ насчитал, что нужно повернуться на минус 5 градусов по часовой стрелке, то он был повернулся на 5 градусов против часовой).
То есть ошибка вот в чём: по умолчанию полагалось, что РН и РБ сделают эти большие развороты (примерно на 180 градусов) в одну и тут же сторону. Тогда из исходных 174 вычтут угол поворота ракеты (примерно 180), получат небольшой угол в несколько градусов, а его знак покажет, куда надо крутиться. Но РН неожиданно для РБ развернулась (в его обозначениях) на -180 градусов! И РБ рассчитал, что ему надо повернуться на 180-(-180)=360 (примерно; на самом деле вышло 363).
Кто же тут виноват? Сложный вопрос, и ответ на него, как я вижу, зависит от согласований между НПЦАП и НПОА. Допустим, если между двумя фирмами когда-то давно раз и навсегда было согласовано, что все повороты всегда делаются по часовой стрелке и на Байконуре так всегда и было, а на Восточном алгоритм НПОА развернул «Союз» против часовой, то это вина НПОА. Тогда моделирование, которое делалось в НПЦАП, не помогло бы вскрыть проблему, так как моделирование, исходя из этих договорённостей, повернуло бы РН по часовой, а в настоящем полёте она пошла разворачиваться против часовой.
Или другой вариант: никакого согласования направлений вращения нет, согласуется лишь конечная ориентация, в которой РН и РБ будут перед отделением РБ. Тогда это вина алгоритмистов НПЦАП, которые полагали направления вращения совпадающими: для Байконура это всегда было так, и можно было исходить из этого предположения, а вот на Восточном уже нельзя. Это как раз то, о чём Вы пишете:
Но тут может быть проблема с тем, что программа была предназначена для запуска с другого космодрома и там всегда работала корректно… тогда получается виновен во всем человек, принявший решение использовать программу с другого космодрома без симуляции ее работы для условий нового космодрома.
Какое-то моделирование полёта, безусловно, в НПЦАП делалось. Но в если оно недостаточно корректно и реалистично отображает манёвры носителя, то эту проблему на моделировании могли и не увидеть.
Т.е. определили в какую сторону поворачиваться меньше и запомнили результат.
2) На Байконуре и в Плесецке ракета вообще не поворачивается, она сразу в нужной ориентации.
2) Ок, спасибо за уточнение. Это все ракеты так, или только «Союз»?
2) Все ракеты в 50х так делали… Протон уже не крутят, он сам умеет.
То есть ошибка вот в чём: по умолчанию полагалось, что РН и РБ сделают эти большие развороты (примерно на 180 градусов) в одну и тут же сторону.Верно, вопрос только кем и почему так предполагалось по умолчанию? Ведь именно это предположение и не соответствовало реальности.
Какое-то моделирование полёта, безусловно, в НПЦАП делалось. Но в если оно недостаточно корректно и реалистично отображает манёвры носителя, то эту проблему на моделировании могли и не увидеть.1. Я все-таки отмету вариант «некомпетентности» наших ракетчиков и тоже 100% буду считать, что у них обязательно должна быть программа для моделирования и визуализации общей траектории движения всех модулей от старта до выхода на арбиту.
2. Второе утверждение тоже возьмем за 100% — это то, что «абстрактные» траектории сначала рассчитываются балистиками, а затем проверяются моделированием «конкретных траекторий» с отработкой уже конкретных маневров модулями.
А если так, то получается, что именно эта программа и сделала то самое ошибочное предположение дав зеленый свет аварийному пуску. Почему? Потому что в ней был забит алгоритм отличный от того алгоритма который реально прописан в модулях. Тогда тот, кто это допустил и есть виновник.
Но если всё так как я написал, то тут явно проблема в архитектуре. Не должно быть отдельной программы моделирования конечной траектории, а должен быть стенд с реальными модулями (которые завтра полетят) и программой симуляции выдающей на вход модулям параметры симулируемого полета. Тогда подобная проблема обнаружится неизбежно.
Собственно об этом и был мой самый первый комментарий:
Где симулятор полета? :)
Верно, вопрос только кем и почему так предполагалось по умолчанию? Ведь именно это предположение и не соответствовало реальности.
Очевидно, ноги растут со старых стартовых столов, где ракету вращали на земле и ей не нужно было совершать разворот в воздухе.
Ну а дальше «работает — не трогай»
:) Ну как же они могут быть рассчитаны хорошо, если не учитывают реальный алгоритм поворота Фрегата?
Ошибка именно в расчете траектории, если бы тот, кто рассчитывал, знал как работает Фрегат, он бы не выбрал курсы РН и РБ при которых они начнут поворачиваться в разные стороны и завалят миссию. Повторюсь: он бы задап курсы РН и РБ при которых бы они поворачивались в одну сторону и успешно вышли на орбиту (без какого-либо вмешательства в работу ПО РН и РБ).
Знаете, меня это всегда умиляет. Всегда к нам, к баллистикам приходят со словами:
«Мы тут нахреначили железку, а ты пойди учти все наши косяки и баги». Начинаешь разбираться: время включения двигателя +- лапать, длительность +- лапать, сила тяги +- пол-лапатя.
Проклиная все, начинаешь учитывать. Работаешь как проклятый. Приходят снова: знаешь, у нас по твоим расчетам система ориентации такую джигадрыгу отчебучит. Давай это учтем.
Ок, давай. Работаешь как проклятый. Но учел. Доволен, что даже с таким г. получается работать. И тут приходят главный конструктор с заказчиком. Первый сообщает, что целевики не справились и мы летаем ниже, а еще у нас мидель больше. А заказчик недоволен, что мы слишком часто включаем двигатель и для целевой задачи времени мало.
Занавес.
Из-за всех этих ± пол-лаптя имеет наведение с закрытым контуром реальные преимущества перед наведением с открытым контуром на атмосферном участке?
Конкретнее: терминальное наведение может так заоптимизировать атмосферный участок под номинальные тягу и УИ верхней ступени, что при небольшом отклонении их от номинала потеря массы будет такая же, как и потеря массы от использования открытого контура управления?
Могу сказать, что полетное задание РН разное в зависимости от месяца, т.к. в верхней атмосфере есть течения, зависящие от времени года. Знаю, что Союз имеет замкнутый контур управления.
Тут еще такой момент: РН должна вывести спутник в заданную точку в предсказанный момент времени, иначе мы можем не войти в связь. Так что, я думаю, замкнутый контур больше для точности вывкдения, чем для оптимизации по топливу.
Кто виноват?
С Orbiter я не работал, но VirSat гонял довольно активно на ноутбуке пару лет назад. Так что проблема скорее организационная, на мой взгляд. Если энтузиасты и студенты, полгода слушавшие спецкурс про спутники, могут промоделить полёт — уверен, в «Энергии» такие люди тоже есть.
Чтоб провести полноценную симуляцию тех алгоритмов, что написаны для Союза и Фрегата, нужно написать модели обеих систем со всеми датчиками, двигателями и прочим. В идеале они должны уметь загружать и исполнять непосредственно прошивки этих блоков. Эта задача несколько более масштабная чем просто ракету в Orbeter'е запустить. Но в целом подъемная и нужна, особенно с учетом стоимости ошибок.
При стоимости проектов и самих блоков в "охрениард денег", стоимость работ по созданию симулятора ничтожно мала и окупилась бы при первом же старте. Хотя, сомневаюсь, что у обеих систем (РБ И РН) отсутствуют свои симуляторы — никто не будет сразу на чистый лист прошивку писать. Просто надо было эти симуляторы "подружить" между собой и сделать пробный запуск на объединенном симуляторе.
И что вы собрались просчитывать на суперкомпьютер? Это не сворачиваемость белков считать. Симулятор вполне могли бы осилить, но никому там это не надо — даже камеры на ракету Союз не смогли установить, европейцы подсобили.
Мы не сверхбогатые США, нет в наших карманах столько денег, чтобы такое оплачивать!
Вообще-то есть, только не в наших с вами карманах, а из наших карманов.
Когда дело касается таких денег, нужно не лепить программы по кривым алгоритмам. Мы не сверхбогатые США, нет в наших карманах столько денег, чтобы такое оплачивать!
Вы сейчас сказали классическим анекдотом про армию: «не высыпаетесь? Это не проблема. Спите быстрее».
Когда я был маленьким, а Windows — глючным, у меня было впечатление, что я самый сильный на планете программист. И когда глюки винды (а по факту — мои мега кривые руки), совсем доставали, одолевала жуткая злость на Билли Гейтса: «Да я, да я щас все перепишу! Да где только таких тупых программистов берут?».
Каково же было мое удивление, когда я вырос и сам стал писать программы. Как оказалось, мне до уровня «кривоглючной» винды как до Китая на четвереньках.
Это я все к чему? Сказать «не ошибайся» — мало. Это не поможет. А вот что поможет — уже написали. Интеграционное тестирование.
может быть по традиции, когда был диапазон допустимых углов поворота рамок гироскопов
А сейчас его разве нет? ИНС-то до сих пор платформенные.
Ну и непонятно почему алгоритмы не на кватернионах (параметрах Родрига-Гамильтона)?
А может и на кватернионах, но РБ не запрограммирован был перед отделением пересчитать свою ориентацию и кратчайшую дугу.
На Байконуре и Плесецке её просто крутят вместе со стартовым столом, а тут научили поворачиваться после старта самостоятельно.
А ракеты любые всегда так летают, потому что (если сильно упрощать) выход на орбиту — это просто поворот по тангажу. Всегда. Чтобы изменять наклонение орбиты к этому повороту по тангажу добавляют еще один простой маневр — вращение на нужное кол-во градусов. И все. Два простейших маневра. А не «умеют летать только так». Шаттлы так летали, сатурны так летали, все так летают, потому что так проще и надежнее.
Причем хоть решение отчасти и красивое, но вскоре и получили недостатки метода. Пилюгин, при массе 8К71 в 270 тонн рассчитал СК на стартовую массу в 330 тонн. Но модификации «Семерки» быстро этот запас выработали.
youtu.be/6oadjbVV0uM?t=17s
А в Куру и Восточном действительно отказались :)
Распространённая проблема с легаси кодом.
Опыт Вояджера, Кассини, марсианских роверов, продление эксплуатаци Хаббла, показывают, что умение успешно работать со старым софтом на древнем «железе» может в разы повысить длительность и научную ценность космических проектов. В этом контексте вывод спутника на орбиту это еще идеальный случай в тепличных условиях — межпланетные исследования по определению длятся годами, если не десятилетиями.
Если Роскосмос не развивает культуру программирования, тестирования и поддержки «легаси» систем, и не считает её критически важной для работы, то это огромный организационный косяк.
Если это многоблочная и многосопловая компоновка, то выбирается плоскость между блоками или так, чтобы проще было создавать момент для тангажа при отклонении сопел ДУ(Зенит, Ангара).
Если посмотреть на Фалкон-9 который был самый первый, еще с квадратным расположением движков, так он вообще чуть оторвавшись начинает вращение — www.youtube.com/watch?v=NREJEZ5eluk
программа прекрасно работала для первоначальных условий, и надеяться, что ее сразу сделали под все возможные космодромы, не стоит
Аналогия примерно следующая, несколько грубая. Есть программа написанная 10 лет назад под WindowsXP, которая отлично работала. Но в Windows 10 нормально работать она перестала, так как, допустим, уже нет каких-то совсем уж древних библиотек от Windows 98, порезана политика прав доступа и всё такое. Это не означает, что разработчики криворукие кодеры, программа плохая и вся её предыдущая работа — случайность. Программа отлично работает в том окружении, для которого создавалась, тестировалась и отлаживалась, но изменились внешние условия, которые в изначальном ТЗ на программу были несколько другие.
Возможно условия работы разгонно блока должна была обеспечить работа предыдущей системы до него. И именно этим руководствовались разработчики блока. Это знаете, сейчас всем всё просто и понятно и возникает резонный вопрос типа «Да как такое можно не предусмотреть, ведь это даже мне очевидно, а там сидят спецы космической сферы». Когда пилишь сложную систему порой некоторые простые вещи, действительно могут упуститься. Потом сидишь и думашь: «Как я мог этого не учёсть?» Для этого и нужно моделирование и стыковочные испытания. Проблема в том, что не всегда удаётся построить полную модель или провести полноценные проверки и вот такие вот косяки вылазят уже в эксплуатации. Хотя, лично мне, удивительно, что в 2017 году нет общей модели поведения системы.
А у разгонного блока, между прочим, после отделения всего минута на всё определение ориентации, расчёт поворота и сам поворот. Оглядеться, чтобы понять, где он, он тоже не может, из органов чувств датчик угловой скорости, три акселерометра, часы и модель гравитационного поля Земли. И процессор с частотой 100 МГц.
Конечно, лучше всё решить час назад, когда времени навалом, а после отделения действовать быстро и решительно, на раздумья там просто нет времени.
Я могу предположить, что выбор направления поворота «на старте» является конструктивной особенностью, а не частью алгоритма. Т.е. он должен повернуть на +175, до этого «кто-то» его повернул на -174, он компенсирует и в итоге и выходит 175-(-174)=349. Для механических гироскопов очень гладенькая картина получается ;)
Я ж не знаю, как там разработка кода велась. Может, это было так:
— А у вас вот тут стоит проверка, не нужно ли вдруг повернуться больше, чем на 180°. В каком случае вообще может понадобиться такой поворот?
— Ну… Например, если с Байконура ракета уходит с курса более чем на 20°.
— И что, разгонный блок может такое выправить?
— Нет, при таком уходе в любом случае упадёт.
— Тогда убрать проверку, нет у нас после отделения на неё лишних 20 тактов.
Вполне же логичная история.
А рассуждать «как надо» обладая полной информацией об ошибке, это откровенный моветон. У любого человека в жизни можно найти ситуации, когда обладая послезнанием/всей полнотой информации становится ну совершенно очевидно, что так делать не надо.
И так, по идее со всем надо. Но ракету с нуля не стали же разрабатывать — вот и полезли наружу потенциально проблемные места. Так и не удивительно.
Даже в глубине души радуюсь — ни в чем реально обидном не произошло ошибок или работы спустя рукава. Автор поста прав — это сложно-комплексная ошибка. И вполне простительна при таком стечении обстоятельств (новый космодром, старая ракета, ТЗ исходно N-летней давности).
P.S. Я разрабатываю аппаратно-программный комплекс для диагностики и проверки качества веб-ПО (можно с натяжкой назвать «тестировщиком»).
Так у меня стабильно горит от того, какой степени кривожопсти делают драйвера в гугле. Порой просто лютый треш. Дерьмокодом только и называть тянет. А вы о ракетах и гораздо более сложный вещах.
И это при том, что в гугле явно платят по более, чем нашим в Роскосмосе на позициях «программист».
Ну а аналогия СУ сложным технологическим объектом с хомячковой ОС сама по себе опускает первую ниже плинтуса ;)
Вы удивитесь, но сложность создания СУ космическим аппаратом несравнимо ниже сложности написания современных ОС. Количество строк кода в современных ОС на пару порядков больше, чем в системах управления космеческими аппаратами.
Разница же в цене ошибки, а не сложности разработки.
Есть много вещей, о которых разработчику СУ КК думать не нужно совершенно (типа многопользовательского режима, конкуренции за ресурсы и изоляции производительности, информационной безопасности, зоопарка поддерживаемого железа и т.д.), т.к. он решает четкую частную задачу.
Скорее корректнее будет пример с использованием циклов в качестве задержек в дос, которые потом "внезапно" перестали работать.
Я просто не знаю условий и причин принятия решений. Поэтому голословно обвинять разработчиков не берусь. Допускаю, что было так как выше написал. Но вполне допускаю и то, что для запуска процедуры коррекции параметров впооне достаточно было перезапустить алгоритм по внешнему сигналу от РН, который не был предусмотрен, а когда об этом подумали, то уже все было сделано и КД выпущена, для сигнала не нашлось свободного пина в применяемом разъеме и пришлось бы сделать перекомпоновку ряда элементов и… на это просто забили, т.к. все нормально и так работало и никому в ум не пришло, что Россия откажется от космодрома, который, по сути, сама и построила.
Не знаю… мне кажется неправильно обвинять инженеров отрасли в 90-ые и 00-ые годы, которые работали там чуть ли не за хлеб.
Дороговатое «интеграционное тестирование» получается.
Хотя бы виртуальную эмуляцию бы запустили…
Вот мне интересно, те, кто говорят про ВИРТУАЛЬНУЮ ЭМУЛЯЦИЮ(вопрос о то, почему жирным шрифтом и тонкости отличия эмуляции от симуляции пока опустим) пробовали сами построить модель какого-нибудь физического процесса так, чтобы она адекватно отражала реальность? Правильно ли понимают сложность такой модели и то, что она все равно не выловит часть ситуаций?
Вы в матлабе когда-нибудь строили какую-нибудь модель физического процесса? Построишь, например, модель передатчика, а потом по факту оказывается что из-за нелинейности передающего тракта на определённых частотах конечный результат получается несколько не тот, который ожидаем. И SNR в приёмнике не тот и работает он со срывами… и приходится вводить всякие поправки. А потом, через 20 лет тебе говорят: «Мы тут PLL модулятора заменили, так как таких же больше нигде нет». Для модели не изменилось ничего. Этот PLL как генерил ХХХ МГц, так и генерит, а какие вводить новые поправки ты сам не знаешь — непонятно что будет с сигналом на новом железе. Datasheet это конечно сила, но там не всегда всё написано в части всяких тонких моментов. Для этого надо делать и сделать.
Отмоделировать и симулировать хорошо чистую цифру и простые алгоритмы. Реальность обычно сложнее и модель стараются строить наиболее приближенную к ней. Если система разрастается экспоненциально, то неудивительно, что в модели что-то упускается даже алгоритмически. Я не говорю, что это хорошо. Это плохо. Надо стараться делать хорошо)
Этому блоку уже 100500 лет, кто его делал давно уже не работают. Нынешний персонал разобрался что и где поправить надо. Поправил. Что-то недосмотрели — неудивительно, когда это софт/код/железка не твои, да ещё к ним и с ТО наверняка напряг, как это у нас традиционно бывает.
Другое дело, что сделать-то было сделано, но проверка в модели или на какой-то КПА не была проведена. Это вопрос не к штатному персоналу (горе-программисты), а к тем, кто планировал конкретно эту разработку, к системщикам.
Если вы это же имели ввиду, то извините — значит неправильно понял)
Но я не думаю, что вообще ничего не проверяли, совсем уж авось и так далее.
К тому же в данном случае ошибка была не с областью немоделируемой динамики связана, а с вполне себе обычными диапазонами входных и выходных величин. Т.е. грубо говоря тестить надо не только с околонулевыми начальными условиями, но и несколькими начальными условиями распределенными по заявленной области определения (и тем более в критических точках, таких как pi, pi/2, где еще и деление на ноль может внезапно вылететь со всеми вытекающими).
Угадайте с трех раз, кто составляет наиболее активное множество посетителей хабра, которое радостно перекрикивает количеством всех хоть сколько-то соображающих специалистов. А дальше простое проецирование.
Есть программа написанная 10 лет назад под WindowsXP, которая отлично работала. Но в Windows 10 нормально работать она перестала… Это не означает, что разработчики криворукие кодеры
Именно это (криворукие кодеры) это и означает. В Windows 10 работает даже Norton Commander 3.0. Учитывая сколько усилий прикладывает Микрософт для обеспечения совместимости работы с различным древним софтом написать программу для Windows XP чтобы она фатально перестала работать на Windows 10 нужно очень постараться.
PS Давайте в моем тексте не будем цепляться за даты, названия и обобщающее слово «ракета» — все все поняли ведь?
Если уж решения считаются отдельно и до старта (я даже не спрашиваю почему нет центрального управления всем этим), то они обязаны сверяться и в случае несовпадения до какого-то знака после запятой — выдавать предупреждения или вовсе блокировать запуск. Это основы защитного программирования.
На первой картинке углы по крену (ракета в стартовом сооружении).
А на второй картинке углы по тангажу (разворот связки РБ+КА).
Гироскоп сохраняет свою ориентацию в инерциальной системе координат. Соответственно, все повороты записываются относительно неё. Сразу после старта необходимый поворот является чистым поворотом по крену, т.к. ось поворота совпадает с продольной осью ракеты. Потом ракета поворачивается, и поворот вокруг оси, направленной из центра Земли на точку старта, уже будет не чистым поворотом по крену, а более сложным.
Пуск прошёл бы штатно, например, летом, либо в случае, если бы районы падения отделяемых частей ракеты-носителя лежали в стороне от выбранных.
Как время года играет роль?
А у нас принято всё упавшее аккуратно собирать и увозить для анализа.Жителей Алтая Ваша фраза несколько бы удивила. (фото не мои, а первое, что попалось в Интернете)
Но если вам от этого будет лучше, то пусть будет точка чуть правее: 02.% стран.
Все равно, для других стран, это как Интел: «мы столкнулись с проблемами при переходе на 5нм». Да, у всех остальных таких проблем нет. (Ну, может АМД им посочуствует). А у большинства — так и вообще никаких своих микросхем нет.
Что я не поняла. Если на разворот РБ отпущена минута при скорости вращения градус в секунду, то рассчитанные изначально до старта 175 градусов… Это как, типа ок?
И почему в программе поворот сам по себе, а разгон тоже сам. Никаких флагов типа ПВРТ_УСПШН :).
Если на разворот РБ отпущена минута при скорости вращения градус в секунду, то рассчитанные изначально до старта 175 градусов…
Там до старта было — у ракеты -175, а у разгонного блока (РБ) +175. В процессе набора высоты, ракета крутится на 175 (это заметно на видео с ракеты): -175+175=0, и РБ тоже крутится: 175+175 = 350. Это же всего лишь на 10 градусов в сторону. «Вам лететь по другой орбите, так что все в пределах нормы», — говорит формула.
И почему в программе поворот сам по себе, а разгон тоже сам.
насколько я понял "околоракетных пользователей ФНК", то там ограничение на время маневра — 55сек. Т.е. если вы не развернулись за это время, то все равно уже поздно — передавайте привет атмосфере.
Но если СУ ракеты-носителя и РБ не общаются, то откуда РБ знать, что останется всего 3°
По показаниям интегратора угловой скорости. Без датчика угловой скорости на разгонном блоке всё равно не обойтись, поэтому на этапе работы носителя он считает, на сколько связка уже успела развернуться.
Если угол всё равно определяется по датчикам углов колец — то как там вообще такая ошибка могла возникнуть и какая бы вообще была разница, задавать угол поворота до старта или после отделения?
Возможно, по угловым датчикам построение ориентации идёт дольше и потому делается заранее, а на активном участке только корректируется.
По показаниям интегратора угловой скорости
Я знаю, что есть интегратор ускорений. Но угловые скорости интегрировать? Зачем? Это в самом деле есть?
Надо Роскосмосу сделать свою игрушку типа KSP с реальным ПО. И популяризация, и пиар, и бесплатная армия фанатов-тестеров.
- монохромный (все грани защитного цвета) — для младшего комсостава;
- монолитный — для старшего комсостава.
caramboo.ru/images/products/84/1.jpg
«Для немедленного исправления ситуации будет проведена корректировка алгоритма системы управления пространственной ориентацией разгонного блока «Фрегат» и существующих регламентов, уже даны поручения по разработке новых современных комплексных методик имитации и контроля полетных характеристик средств выведения.»
Как я понимаю если бы КУРС РН был 354 а курс РБ был 344
В данном случае требуемый курс РН и РБ и были 354 и 344 соответственно.
РБ оценивает поворот на момент старта
Видимо, не сам поворот, а его направление. Конкретный угол, конечно, определяется уже после разделения, так как до старта точно неизвестно, на сколько повернёт ракета.
но разгонный блок перескочит нужный угол для разгонного блока, а тот продолжит вращаться в том же направлении
Не совсем понял Вашу мысль. Если РН и РБ будут вращаться в одном направлении, то требуемый угол доворота РБ будет сравнительно небольшим, а его знак подскажет направление. То есть если РБ решит вращаться по часовой стрелке, а требуемый угол доворота окажется, допустим, минус 5 градусов, то это будет означать 5 градусов против часовой стрелки.
В момент отделения ошибка составила 363° (174°+175°=349°, очевидно, прибавились не упомянутые маневры ракеты), однако, вместо того, чтобы пересчитать направление движения, разгонный блок пошел по длинному пути.Автоматика рассчитала, что надо сделать поворот на 363° и стала поворачивать на 363°? То есть полный оборот и еще 3°?
У меня когнитивный диссонанс от того, что я не могу понять процитированную фразу иначе, а далее по тексту написано, что с автоматикой все ОК на самом деле, так и надо.
рассчитала, что надо сделать поворот на 363° и стала поворачивать на 363°? То есть полный оборот и еще 3°
Я понял так же. А про автоматику в тексте нигде и не говорилось. Было сказано, что техника отработала правильно (т. е. не было отказов/нештатной работы двигателя, датчиков, бортового компьютера и т. п.).
и стала поворачивать на 363°?
Насколько я понял из поста и предыдущих обсуждений — нет. Автоматика вместо доворота на 3° пошла, как пишет lozga, по длинному пути — то есть начала поворот на 357 градусов (360-3).
по длинному пути — то есть начала поворот на 357 градусов (360-3)
Нормальные герои
всегда идут в обход!
Я проработал в НПЦАП, который делает СУ для этого самого «Фрегата», 5 лет. А потом надоело и я стал искать новую работу. Почему? Ну, условия работы не очень комфортные были. Например, окна у нас в комнате были на солнечную сторону, а кондиционер всё никак не ставили, рассказывая вместо этого про планы устройства волшебной централизованной системы кондиционирования. Так что когда летом температура в комнате переваливала за +30, становилось слегка некомфортно. Кстати, и мозги от этого хуже начинают соображать — это к вопросу об ошибках в алгоритмах. Справедливости ради, коллеги, которые остались, говорят, что сейчас кондиционер всё-таки поставили.
А, ещё у меня стул на колёсиках развалился, потому что был самый говенный, самый дешёвый — так я год не мог дождаться, пока новый купят. Сидел на обычном деревянном стульчике. Там, правда, обивка малость ободралась, но это ничего страшного, сидеть-то можно.
В принципе я человек достаточно аскетичный и могу все эти неудобства перетерпеть, только вот проблема тут глубже — все эти бытовые вопросы на самом деле показывают отношение предприятия к сотрудникам. И отношение это очень простое: предприятию на сотрудников насрать. Именно предприятию как бездушной организации: я верю, что лично наш Генеральный директор (и другие начальники) очень хороший человек и искренне радеет за то, чтобы предприятию и сотрудникам жилось как можно лучше, но в силу тех или иных причин процессы на фирме выстроены так, что мы имеем то, что имеем. И при таком отношении энтузиазм и желание работать на предприятии начиная с какого-то момента начинает угасать. Упомянутый Вами финансовый вопрос, да, тоже имеет некоторое значение. Например, на новом месте мне на новенького положили в 1,65 раза больше, чем было в НПЦАП (справедливости ради скажу, что там, когда я собрался уходить, тоже предложили существенную прибавку и повышение в должности).
В заключение скажу, что выставлять всё исключительно в негативном плане было бы неправильно — я должен отметить, что мне в целом повезло и с начальством, и с коллективом, и задачи были очень интересные. И конечно, я считаю, что за эти 5 лет я очень вырос как специалист в своей области. Увы, но перевесила противоположная сторона.
P.S. Этот опыт с осторожностью нужно обощать на весь Роскосмос — даже у нас внутри НПЦАП разные позразделения могли заметно отличаться по условиям работы, адекватности начальства и т. п. Тем более заметной будет разница между разными предприятиями. Например, я знаю, что на некоторых предприятиях Роскосмоса хозяйственные вопросы решаются гораздо лучше, чем я описал. В то же время, есть и некоторые симптомы, довольно характерные для всей отрасли в целом.
И отношение это очень простое: предприятию на сотрудников насрать. Именно предприятию как бездушной организации: я верю, что лично наш Генеральный директор (и другие начальники) очень хороший человек и искренне радеет за то, чтобы предприятию и сотрудникам жилось как можно лучше, но в силу тех или иных причин процессы на фирме выстроены так, что мы имеем то, что имеем.Предприятие, как неодушевленный объект, срать не умеет, и процессы в фирме выстраивают люди. Конечно, стул для Вас должен был обеспечить не генеральный директор, а какой-нибудь завхоз (или как его там называют), но то, что такие люди «сидят» (работой это назвать — язык не поворачивается) в фирме — виноваты именно люди, сделавшие такое отношение к работе нормой, видимо, в том числе, и гендир, что не мешает ему при этом быть очень хорошим человеком, но находящемся явно не на своем месте.
Кроме того, кадровые вопросы едва ли не самые сложные. Купить стул или повесить кондиционер легко. А вот уволить нерадивого завхоза и найти на его место хорошего куда сложнее. Ничего удивительного, что на фоне постоянной сильной загруженности до каких-то вопросов руки у руководства никак не доходят.
Я не то чтобы оправдываю сложившуюся ситуацию и не утверждаю, что наш директор был идеальный руководитель — в конце концов, мне и самому надоело всё это терпеть — но призываю к более глубокому анализу ситуации.
Представьте себя на месте директора огромной (>10 000 человек) фирмы с большим количеством проблемне буду, даже чисто умозрительно. Я прекрасно знаю свои сильные и слабые стороны и никогда и ни за что не согласился бы на такую работу. А человек согласился и работает, никто его не заставлял, надеюсь. Соответственно, ссылаться на «проблемы, многие из которых тянутся ещё с памятных 90-х годов, а многие обусловлены внешними обстоятельствами» — это лишь отговорки. Создать сотрудникам нормальные условия работы и требовать от них ее качественного выполнения — это его основная обязанность, это никак не должно сказываться на контрактах и сроках, а наоборот, способствовать их соблюдению. Поэтому я и говорю, что человек, видимо, не на своем месте. Это касается только его профессиональных качеств, применительно к занимаемой должности, я вовсе не хотел хоть в малейшей мере его или Вас задеть или обидеть.
не буду, даже чисто умозрительно. Я прекрасно знаю свои сильные и слабые стороны и никогда и ни за что не согласился бы на такую работу.
1:0 в Вашу пользу :) А в общем да, я соглашусь с Вами относительно профессиональных качеств директора. Хотя надо сказать, что для того же Роскосмоса это далеко не самый худший вариант.
Меня поразило, что когда IBM находилась на грани катастрофы, Герстнер работал размеренно и даже как-то расслаблено. Он пишет, что мне надо было подумать и я на пару дней поехал куда-то там отдохнуть. И этот человек сумел вывести гигантскую корпорацию из кризиса, в то время как его назначали с надеждой, что он всего лишь проведёт банкротство максимало мягко.
Прикол в том, что чувак (извини Лу) вообще не разбирался в компьютерах, а до этого руководил табачной компанией.
Так что «загруженность», «контракт», «сроки» и «руки не доходят» — плохие оправдания для руководителя.
«Когда в 6:45 я подъехал к зданию IBM и подошел к входной двери, оказалось, что она заперта. Рядом с дверью было устройство для считывания карточек, но служба безопасности еще не выдала мне такую. И вот я, новый генеральный директор IBM, стоял и барабанил в дверь в надежде на то, что кто-нибудь обратит на меня внимание и впустит. Через некоторое время появилась уборщица, с недоверием оглядела меня, потом открыла дверь.»
Нужно просто чтобы руки дошли рассмотреть возникающие вопросы.
Предприятие, как неодушевленный объект, срать не умеет, и процессы в фирме выстраивают люди.Не так всё просто: Андрей Лазарчук, Петр Лелик. «Голем хочет жить», далее немного Переслегина и далее сами найдёте если интересно…
Если парой слов — то «личные особенности» оргструктуры практически не зависят от личностных особенностей составляющих эту структуру людей — внутри структуры люди действуют по правилам этой структуры (писаным и не очень), а если не могут/не хотят — то либо перековываются, либо отторгаются.
Собственно «оргструктуры» (конторы, фирмы, церкви, государства, армии etc) — это наглядный массовый пример неэлектронных ИИ, давным давно живущих «поверх» людей как элементной базы.
А, ещё у меня стул на колёсиках развалился, потому что был самый говенный, самый дешёвый — так я год не мог дождаться, пока новый купя
Я бы его уже за это время сам починил :)
Да даже зарплату тоже можно самому себе выдавать, но если вы такой самодостаточный человек то зачем вам вообще работодатель?
Я бы его уже за это время сам починили тем самым создали бы прецедент, поощряющий бездельника и дальше так же относиться к своей работе.
Это работа менеджмента и руководства
Мое дело — отлично делать работу и создать себе хорошие условия
Так в чем же причина аварии? На этот вопрос отвечают два слова — «интеграционное тестирование».
А я не согласен, что тут виновато «интеграционное тестирование».
Во первых, если бы алгоритм повороты был бы чуточку умнее, проблем бы не было.
Во вторых, исходя из того, что работа РБ должны быть как можно надежнее, сам по себе РБ должен уметь выкручиваться как можно лучше из нештатных ситуаций.
В третьих, упомянуты «не упомянутые маневры ракеты», которые могут давать разные дополнительные углы.
В четвертых, никаких существенных условий при работе в связке по факту с РН не появилось.
Утверждение, что виноваты программисты, разрабатывавшие программное обеспечение «Фрегата» 20 лет назад, тоже неверное — программа прекрасно работала для первоначальных условий
С этим тоже не согласен. Многие программы с ошибками работают (во могут внезапно себя проявить), но это не значит, что программист, допустивший ошибки не виноват, или эти ошибки исправлять не нужно.
По описанному — виноват «программист», сделавший ненадежный алгоритм расчета угла поворота. А ошибка — типичная для модульной арифметики или арифметического переполнения.
А я не согласен, что тут виновато «интеграционное тестирование».
Во первых, если бы алгоритм повороты был бы чуточку умнее, проблем бы не было
А для чего еще интеграционное тестирование? Если бы все было «чуточку умнее» — то оно не нуно.
Если заранее знать — что тут нужно чуть умнее — тут чуть надежнее
А для чего еще интеграционное тестирование?… Если бы все было «чуточку умнее»...
Можно было бы согласиться, если бы не упомянутый пункт 2:
Исходя из того, что работа РБ должна быть как можно надежнее, сам по себе РБ должен уметь выкручиваться как можно лучше из нештатных ситуаций.
Полагаю, что ситуацию с нештатной ориентацией и оптимальную ее обработку можно было бы учесть и протестировать («модульным» тестом) по-умолчанию.
У разгонного блока не бесконечный запас возможностей.
Он сильно ограничен во времени, в запасе топлива и прочее.
С экономической стороны и стороны эффективности.
И тестировать его на все возможные случаи в отрыве от РН — глупо.
В том плане что есть рамки, что он заточен под определенные варианты.
В момент отделения ошибка составила 363°
А в интеграционном тесте было бы 174°+175°=349°, и все бы прошло без проблем. И, тогда, причем здесь интеграционные тесты?
Я думаю что у них в любом случае должен быть ( и есть возможно) стенд.
Стенд который эмулирует все условия для БК.
Датчики, положение. итд Котороый позволяет прогонять программу полета
Вот на этом стенде и сделать интеграционный тест с стендом для союза для конкретных условий ( космодром Восточный) — и вылезло бы СРАЗУ — как миленькая
Соответственно привезти актуальную версию системы управления ракеты на стенд второй — проблема.
Проблема в том что ракету делает одна организация, а РБ — другая.
Ну в данном случае, разве это имеет значение?
Разве трудно сделать алгоритм, вычисляющий более-менее оптимальные параметры поворота на требуемый курс?
Иначе, если бы Фрегат на старте зафиксировал 175 градусов, так и после любого разворота РН, фрегат бы стал поворачивать на 175.
Но это изначальное число 175 во время полета ведь меняется!
По моему мнению, у автора статьи запутанные объяснения про «слишком рано», «направление поворота» и т.п. И этим он еще путает читателей.
Притом надо понимать, что блок не поворачивает на какой-то угол.
У него алгоритм такой — «дал импульс движком ориентации — дождался пока показания с гироскопа совпадут с целевыми — дал контимпульс».
То и значит — все необходимые действия по крайней мере для первого включения вычисляются ещё на стартовом столе.
Ну нет же!
175 — это начальное значение «счетчика», которое меняется во время полета (может увеличиваться/уменьшаться/меняться). Каким оно будет после отделения, Фрегат может и не знать, и это правильно. А после отделения совершается доворот на остаток — остаточное значение в счетчике.
Притом надо понимать, что блок не поворачивает на какой-то угол.
У него алгоритм такой — «дал импульс движком ориентации — дождался пока показания с гироскопа совпадут с целевыми — дал контимпульс».
Вот если было бы так, то, наверное, и аварии последней бы не было.
Потому что в статье показано, что нужно было довернуть на 3 градуса в ту же сторону, что и «задумывалось изначально».
Фрегат стал поворачивать в нужном направлении, только вовремя не остановился.
то РБ будет вращаться, пока не накопится этот самый нужный угол в том виде, в котором он записан в памяти
Ну вот если он записан в памяти, а не приколочен гвоздями к железке, то вообще никаких проблем изначально сделать «по-уму» не было. И доработка ожидается минимальная.
А слова про интеграцию РБ и РН — это наоборот, лишнее и ненужное усложнение системы.
Ну вот если он записан в памяти, а не приколочен гвоздями к железке, то вообще никаких проблем изначально сделать «по-уму» не было.
Казалось бы, да. Но задним умом все крепки :) нужно понимать, что алгоритмы и программы достаточно объёмные, с большим количеством ветвей. За всеми особенностями их работы уследить трудно. Тем более, что для пусков с Байконура такой алгоритм вполне годился (там были такие углы, что РБ и РН всегда поворачивались в одну и тут же сторону, и результирующий угол всегда был сравнительно небольшим, лишних 360 градусов никак появиться не могло), а когда его стали адаптировать для Восточного, то за этим не уследили. Собственно, очень похоже на историю про то, как уронили Ариан-5. Казалось бы, тоже нет никаких проблем сделать «по уму» — выбрать такие масштабы/типы данных, чтоб никакие переменные не переполнялись. Однако вот не уследили же :(
И доработка ожидается минимальная.
Да, совсем простая. Гораздо сложнее было в принципе сообразить, что требуется доработка.
Казалось бы, да. Но задним умом все крепки :)
Ну мало ли что могло произойти в полете, куда бы что могло неожиданно повернуться. Наверное, сделать нормальную арифметику можно хотя бы из этих соображений: надежности и возможности исправления ошибок на предыдущих этапах пуска.
До этого ведь были случаи, что двигатели РН выключались раньше времени, и разгонный блок за счет запаса топлива и адаптивности исправлял ошибки РН.
Здесь, ведь, по-сути, тоже самое.
До этого ведь были случаи, что двигатели РН выключались раньше времени, и разгонный блок за счет запаса топлива и адаптивности исправлял ошибки РН.совершенно разное.
Здесь, ведь, по-сути, тоже самое.
В том случае, когда РБ исправлял ошибки РН по скорости — это значит, что направление было правильное, и адаптивность была по времени выключения двигателя. А в этом случае — неправильное направление плюс жесткость времени включения.
Касательно космических полётов в целом — если в конце активного участка РН ориентация правильная, но не хватает 10-50 м/с скорости — разгонный блок может это вытянуть. Если ракета ушла с курса на 1 градус — значит, вектор орбитальной скорости нужно повернуть на этот один градус, затратив VI*sin(1°) = 136 м/с (VI — первая космическая). Это на самом-самом пределе запасов, придётся использовать резервы, предназначенные на сход с орбиты / переход на орбиту захоронения. Если ракета сильно отклонилась от курса, то уже бессмысленно корректировать, всё равно не выйдет.
Плюс к этому, затраты на коррекцию тоже растут с течением времени. То есть включить двигатель на 10 минут позже — это привет, океан вне зависимости от ориентации.
Поэтому и оставили жёстко минуту до включения по принципу «если уход из расчётной ориентации больше, чем на 50 градусов — запуск так и так уже не спасти».
Если ракета сильно отклонилась от курса, то уже бессмысленно корректировать
Я в первую очередь имел ввиду не это, а, например, нештатное закручивание, заметное изменение ориентации разгонного блока при отделении. И, вот, ему что бы продолжить полет нужно принять правильную ориентацию.
БЦВМ и алгоритмы управления в ней заложенные — это не волшебная палочка, которая из любой ситуации за гарантированное время может найти выход, уложившись в запас топлива на разгонном блоке. Сам алгоритм наведения для общего случая гораздо сложнее, чем при заранее заданном времени включения двигателя, и при этом всё равно не факт, что нормальное решение существует при абсолютно любых начальных условиях.
Вот и приходится лезть в ненужные детали, чтобы систему сделать проще, надёжнее и удобнее для тестирования.
В момент отделения ошибка составила 363° (174°+175°=349°, очевидно, прибавились не упомянутые маневры ракеты), однако, вместо того, чтобы пересчитать направление движения, разгонный блок пошел по длинному пути.
В таком случае (поворот со 363° на 360°) не нужно менять направление, а (по факту) повернуть в том же направлении, как и было задумано изначально, но только на 3 градуса.
lozga, я прав?
Но конечно для этого нужна хорошая модель итд
Ну так толсто, что прям аж тонко.
Англичанка гадит?
23 сентября и 12 октября 1958 года были проведены первые пуски ракет Р-7 в лунном варианте. Оба пуска закончились однотипными авариями — разрушением пакета на конечном участке полета первой ступени.
Подобного вида аварии наблюдались впервые. Никаких производственных дефектов, конструкторских ошибок или «разгильдяйства» испытателей при подготовке ракет первый анализ не обнаружил. Возникли подозрения о непознанном принципиальном недостатке пакетной схемы. История поисков первопричины этих аварий очень поучительна.
Качество телеметрических записей было вполне достаточным для пристрастного поиска признаков возникновения отказов в системе управления или агрегатах двигательных установок. Однако многочисленные специализированные группы исследователей аварии 23 сентября явного криминала не обнаружили. Принимать решение о следующем пуске без объяснения причин аварии и проведения каких-либо мероприятий было недопустимо. Но Хрущеву было обещано попадание в Луну, поэтому долго размышлять и рассматривать телеметрические пленки и записи, не принимая решения, времени у нас не было.
Кто-то из потерявших надежду быстро раскрыть тайну разрушения ракеты мечтательно высказался, что если списать это на диверсию — типа незаметно приклеенной магнитной мины, то никаких мероприятий, кроме повышения бдительности, не потребуется и можно будет продолжать пуски.
Вопрос не о этом конкретном случае, а о алгоритмах вообще.
Хотя, подозреваю, что инсайда тут не будет ибо наказуемо.
Во-вторых — запас до «утонуть» на порядок больше и вообще не факт что был известен тем кто алгоритм вводил.
В-третьих — блок может и гораздо энергичней поворачиваться
Но пришел некто и сказал, что у РБФ есть много ограничений на угловую скорость, и в том числе гироплатформой: у нее есть приоритетные плоскости, по которым она может более энергично поворачиваться, чем по другим (ЕМНИП тангаж — быстро, а рыскание и крен — нет).
Я к тому, что "все сложно" :)
Но если бы компу поставили задачу «надо за минуту повернутся на 357 градусов»…
у РБФ есть много ограничений на угловую скорость, и в том числе гироплатформой:Из-за гиростабилизированной платформы есть ещё одна беда: по двум осям у неё вращение без ограничений, но вот по третьей — всего лишь ±40°
Вот и вопрос — что происходило с осями ГСП в процессе такого неожиданного (для РБ) поворота РН.
ГСП встала на упоры.Поскольку поворот на 50° происходил в зоне радиовидимости — должно было быть подтверждение в телеметрии (потеря готовности ГСП).
Однако же ни в одном из официальных заявлений на это нет даже намёков.
И с russianspaceweb фраза про «гироплатформа встала на упоры» тоже исчезла.
А ограничение в 40° — из угловой дальности активного участка проистекает?
блок может и гораздо энергичней поворачиватьсяПоворот по крену — только двигатели СОЗ.
А вот выполнять поворот по тангажу и рысканью можно ещё и смещением сопла МДУ (± 30 мм), причём это считается предпочтительным (нет расхода топлива ДУ СОЗ).
Возможно, на это и был расчёт — «через минуту включаем МДУ, заодно и на нужный вектор доворачиваем».
Кто на это деньги и людей выделит?
На минуточку — разгонный блок это часто либо последняя ступень с двигателями, либо последняя ступень с двигателями досточной дельта-в. В спутниках которые крепятся в РБ, часто топлива только на калиброку и ориентацию. РБ должен уметь парировать все косяки траектории на которую его вывела ракета-носитель и тут выясняется, что он не просто не может понять как ему быстрее открутиться, но и включает двигатели просто по таймеру, то есть безотносительно текущей ситуации.
Мне кажется, вина в аварии лежит исключительно на софте (прошивке) разгонного блока.
Объясняю чисто геометрически. Возьмём зарезервированные районы под приводнение 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°, при разборе этого пуска, единственно где я его самого углядеть — это азимут по земной поверхности от Восточного до зон в Атлантике, но рекеты же так не летают, не ориентируются. Похоже же на то, что тот кто назвал этот угол не в ладах с баллистикой.
Можно было обосновать за третью ступень и без симуляции, только из геометрии и элементарных соображений.
Орбита с i=98.57º проходящая по центру зоны приводнения в Атлантике пересекает широту Восточного на долготе 129.45ºE (разница 1.12º), т.е. гандикап — 269 секунд. Поскольку до момента отделения головного блока на 563 секунде, средняя скорость примерно раза в два меньше орбитальной, третья ступень может надёжно попасть в зоны приводнения.
А вот орбита i=98º проходящая по центру зоны приводнения пересекает широту Восточного на долготе 130.49ºE (разница 2.16º), т.е. гандикап — 518 секунд. Поэтому третья ступень с таким наклонением не имеет возможности приводниться в заданном районе. Она же не может зависнуть в пространстве на 100...150 секунд. ;)
Вывод, практически железо-бетонный, третью ступень планировалось направить по незамкнутой орбите с наклонением i=98.57º. А все домыслы, что в полётном задании (или до отделения) Фрегата планировалось корректировать азимут, как минимум, испорченый телефон.
P.S. Отличные иллюстрации, вы новый сценарий под условия сделали или нашли готовый?
На мой взгляд — проблема в системе. Система должна быть прозрачной и показывать затраты на оборудование и разработчиков. А показывает то какие-то мутные схемы с откатами на «барабаны страдивари» (сколько там на восточном украли), то больных кладовщиц с неправильно выданным припоем (не в данной цепочке конечно, но всё-же тот же роскосмос), то вот программистов, якобы не знавших азы геометрии (не ну серьезно доворот на 360?) и якобы это никто не проверял 20 лет.
На самом деле, да, я — верю — ошибки бывают, и стрелочник ее точно совершил, но это как раз нормально. Не нормально, что ее не обнаружили за 20 лет. Система должна быть заточена на поиск и исправление. И интеграционное тестирование — это лишь малая часть цикла разработки. Его не было. Видимо, не было симуляции и тестов устойчивости с рандомно изменяющимися параметрами. Ни разу минусовые градусы не были в рандоме. Один раз прогнали на симуляторе и типа всё ок?
А эти оставленные заглушки на фрегате, которые обнаружили перед стартом?
А предыдущее падение френата с двумя спутниками галилео? Там тоже речь была о програмном обеспечении фрегата.
А телеметрия, Карл? Где? С начала 90х поют одну и ту же песню про горизонт. Но с тех пор сколько уже группировок связных спутников выведено. Не было никакой возможности поставить телеметрию и передавать ее через эту группировку?
Что-то не похоже, что вице-премьер, по образованию журналист, стоящий во главе этого карнавала был грамотен в построении правильной системы.
А эти оставленные заглушки на фрегате, которые обнаружили перед стартом?
Вам больше нравится, когда их обнаруживают после старта?
А предыдущее падение френата с двумя спутниками галилео? Там тоже речь была о програмном обеспечении фрегата.
Не падение, а выход на нерасчётную орбиту. Тоже не сахар, но спутники сейчас всё же в строю. И основная причина там была в замораживании трубопроводов системы ориентации газом наддува основных баков при длительном манёвре. Какие-то недоработки в ПО вскрылись при расследовании, но не факт, что они бы вообще испортили миссию при нормальной работе системы ориентации.
Ну и чисто ради флейма: на днях ракету одной американской фирмы сняли со старта, т.к. нашли твёрдые частицы в топливной системе.
А в прошлом году эта же фирма решила попробовать ускоренный метод заправки ракеты, когда на ней уже стоял спутник, что привело ко взрыву носителя со спутником и разрушению стартового стола.
Собственно, все эти случаи показывают, что задачу разработки ПО надо рассматривать для связки носитель + РБ + космодром, при изменении чего угодно нужна ревизия и, возможно, тестовые запуски (если уж у нас не всегда получается написать софт с первого раза, что бы это не признать).
Я вот не считаю, что расчёт направления поворота до старта и потом тупое вычитание поворота носителя является однозначно ошибкой программиста. Всё зависит от ТЗ, по которому это делалось. Если в ТЗ было явно обозначено, что все углы заведомо меньше 180° — всё сделано верно, из критичной по времени части убрана проверка с заведомо известным результатом.
на днях ракету одной американской фирмы
А причем тут америка? Американцы по-вашему тоже при наличии проблем кивают на Россию, типа «там тоже»? Ведь нет же.
И основная причина там была в замораживании трубопроводов системы ориентации газом наддува основных баков
а тут пишут —
iz.ru/news/575880
«из-за некорректной работы системы управления, изготовленной московским ФГУП «Научно-производственный центр автоматики и приборостроения имени академика Пилюгина» (НПЦАП). По словам источника «Известий» в Роскосмосе, скорее всего, нештатная работа интегрированной системы управления стала результатом ошибки в программном обеспечении, заложенном на борт. В результате разгонный блок получил неправильное полетное задание»
задачу разработки ПО надо рассматривать для связки носитель + РБ + космодром
Я не понял ваших возражений. По-вашему это программисты должны были сами решить что нужно связывать разработки лавки и пилюги? или всё-таки система должна быть правильно построена и изначально связать эти две-три конторы более плотным образом. Во втором случае — и кто же ее построил неправильно и не предусмотрел такие связки?
а тут пишут —
А в более поздней статье тех же «Известий» пишут, что всё-таки замерзание гидразина.
А причем тут америка? Американцы по-вашему тоже при наличии проблем кивают на Россию, типа «там тоже»?
Охохо, посмотрели бы вы утром американское ТВ. Они кивают не «там тоже», а «всё оттуда». В отличие от этой страны, правда, по своим тоже проходятся.
Но вообще она тут при том, что дефекты перед стартом и неожиданное поведение космической техники — не исключительная прерогатива Роскосмоса, но на этом ресурсе почему-то принято Роскосмос втаптывать в грязь даже за отзыв потенциально дефектных блоков, а других хвалить «вот, молодцы, следят за качеством».
То, что ошибку в софте не углядели — ну ёлки-палки, новый космодром, там же столько всего нужно учесть. Про то, что в программе, отработавшей правильно уже больше 60 раз подряд, может быть недокументированный фатальный недостаток — как-то людям не подумалось (пить шампанское под «Славу России», пока с разгонного блока даже не получена ещё телеметрия, — это всё равно, конечно, свинство, тут спору нет).
или всё-таки система должна быть правильно построена и изначально связать эти две-три конторы более плотным образом
Надо связывать или надо оставить так — не берусь сказать. Но нужно понимать, что ракету с другого космодрома пустить — это не поезд перегнать с полустанка на полустанок. Что-то мне подсказывает, что наверху (возможно, даже и не в Роскосмосе) тупо не посчитали нужным выделить ещё денег и времени на интеграционное тестирование и нормальный анализ. Оно же как наверху думается — главное чтоб ракета со стола ушла, а там Байконур, Куру, Восточный — воздух везде одинаковый. И руководство Роскосмоса, я думаю, понимает в целом ситуацию, но не в том положении, чтобы сказать «мы не можем запустить с Восточного Союз с нормальной нагрузкой, дайте нам Союз под массогабаритный макет для тестирования» — в итоге взялись и лажанулись.
Охохо, посмотрели бы вы утром американское ТВ
Передергивать не нужно. Когда американцы свои неудачи в комосе покрывали фразами «а вот у них в России там»?
А телевидение — да, я его, американское, смотрю время от времени, радио слушаю каждый день по пути на работу и новости в и-нете читаю. Нигде там Маск или там НАСА или Бэзос не приводят в пример Россию что мол дескать да, у нас неудачи, а видели бы вы что в России.
Надо связывать или надо оставить так — не берусь сказать
Невозможно не связывать. Иначе оно не стыкуется. Каждый элемент в каком-то своем диапазоне работает, а вместе, как комплекс — нет. И, плюс к этому, как иначе вы проведете интеграционные тесты или симуляции?
тупо не посчитали нужным выделить ещё денег и времени на интеграционное тестирование и нормальный анализ
Наверняка так и есть, но это всё-таки догадки. А пока все обвинения, судя по статье — в адрес программистов, типа они сделали ошибку и в этом вся причина. Не провели интеграционное тестирование. Окей. А кто его должен был проводить? Программисты — это исполнители. Организаторы все сидят выше. Они и получают бабки за то, чтобы система в целом работала.
Нигде там Маск или там НАСА или Бэзос не приводят в пример Россию
Комаров тоже никого в пример не приводил, это лично моё напоминание. И что-то к Маску и НАСА нет такой лютой ненависти за любую неудачу (Безос пока не в счёт).
Невозможно не связывать. Иначе оно не стыкуется.
Речь вначале о предприятиях шла. У нас могут две конторы так плотно связать, что потом не развяжешь. То, что проверять работу нужно у изделия в целом — очевидно (по большому счёту, конечному заказчику даже и не важно, насколько там хорошо работает каждый элемент по отдельности, это для производителя блочное тестирование удобнее).
А пока все обвинения, судя по статье — в адрес программистов, типа они сделали ошибку и в этом вся причина.
В статье как раз написано «Утверждение, что виноваты программисты, разрабатывавшие программное обеспечение «Фрегата» 20 лет назад, тоже неверное».
Ответа на вопрос «как эта ошибка / особенность программы добралась до Восточного» в отчёте комиссии, к сожалению, нет. И главная проблема, собственно, в этой закрытости, а не в самой программной ошибке.
«мы не можем запустить с Восточного Союз с нормальной нагрузкой, дайте нам Союз под массогабаритный макет для тестирования»Зачем? Первый запуск с Восточного уже был, вполне успешный. Что ещё испытывать?
100% что массогабаритный макет улетел бы вполне штатно — как, собственно, штатно улетел и Фрегат. К Союзу-то претензий нет!
Вообще, ситуация с зоопарком «Союзов» и кучей площадок запуска для них сложилась какая-то патологическая. На Восточном как построили стол для «Союзов», так и вообще будто забыли, что к нему новая ракета вообще-то предполагалась. В итоге вся космическая промышленность, такое ощущение, клепает эти «Союзы», а КБ занимаются их адаптацией к новым условиям запуска вместо освоения новых технологий.
PS: хотя не, глянул Джемини 3 и 5, это бывает не только у меня.
С другой стороны, уже если она «сообразила», что надо куда-то доворачивать, значит система определения координат таки есть. Но тогда ошибка при «зашкале» на больше 180 градусов — это однозначно результат халтуры. Сколько было случаев, когда при запусках не всё шло гладко, то есть, аппарат мог оказаться непредвиденном положении, но потом какие-то ошибки частично компенсировались, пусть за счёт дополнительного расхода топлива… А такая компенсация ошибок должна предусматривать корректную работу в произвольном диапазоне углов и положений.
Знаю, что еще в нулевых в США верхние ступени весь матан считали сами, и пытались как-то вытянуть поближе к целевой траектории, но нужно освежить в памяти, конечно.
Во-вторых, речь в статье не о «Бризе», а о «Фрегате».
В-третьих, на «Фрегате» она тоже есть.
На земле же определяется лишь направление вращения
Вот поясните мне, что вы понимаете под этой фразой? Причем здесь направление вращения?
Потому что направление окончательного поворота РБ с положительным направлением оси никак не связано.
В РБ есть переменная, которая отвечает за угол на который надо повернуть, и при маневрах она постоянно пересчитывается. Но ее забыли «закольцевать» на 360 градусов — а потому 3 градуса и 363 оказались разными значениями. Ну а раз там написано 363 — то и поворот пошел на 363…
В РБ есть переменная, которая отвечает за угол на который надо повернуть, и при маневрах она постоянно пересчитывается. Но ее забыли «закольцевать» на 360 градусов
Ее нужно кольцевать на 180 градусов с соответствующей сменой направления положительной оси поворота.
Я говорил не о сдвиге ноля, а о сдвиге области значений.
Нормализация величины в таком случае будет задаваться формулой (x % 360 + 540) % 360 - 180
, где % — взятие остатка, это лишь на одну операцию сложнее обычной формулы (x % 360 + 360) % 360
(правда, если остаток считать по определению Кнута, то оказывается уже на 2 операции больше: (x + 180) % 360 - 180
против x % 360
).
А в случае 357 что было бы? Поворот на 357…
И кстати, а на момент отделения блок не закручен был? Может поэтому 270 в попутном выгоднее, чем -90?
В этом большом обсуждении мелькнул вопрос о быстродействии, мол, рассчитать направление поворота можно успеть только заранее, до старта, потом «мозги» заняты другими расчётами и к моменту отделения надо уже это знать.
А вот про то, что любая ветка алгоритма — это лишняя память, никто так и не вспомнил.
Как было интересно читать про вояджер, про марсианские миссии, мол там благодаря программистам наэкономили десяток ячеек памяти и удалось воткнуть ещё один эксперимент или прибор и подпрограмму для его применения.
Неужели эту часть оптимизации сейчас никто не делает и вот так взять и учесть новые ветки алгоритма это раз плюнуть и надо было просто это сделать?
А «Новые горизонты» только собранной информации десяток гигабайт передали
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
Там 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
Если надо больше — используют внешнюю память, там хоть гигабайты храни.
Только внешняя память подключается с коррекцией ошибок, а не просто так.
...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...
А когда на платформе появляется такой таймер — то исправленные при оперативном чтении данные становится уже не обязательно сразу же записывать обратно, эту операцию можно отложить до очередного обхода таймера. Такое решение одновременно упрощает процессор и делает работу с памятью стабильнее по времени.
К слову, ради интереса и для общего развития, вот лично вы обычно как скраббер делаете?
Допустим, его бы после отстрела еще бы закрутило. В принципе, программа полета должна предусматривать такую ситуацию.
Если состояние систематически выходит за эти рамки — тогда надо спрашивать с разработчиков носителя, почему не обеспечивают.
Если при анализе причин выясняется, что дешевле выправлять силами РБ — только тогда нужно менять программу РБ.
Здесь именно что при смене космодрома не прошло / неправильно прошло пересогласование состояния связки перед разделением.
"… только один раз, еще перед стартом, решил, в какую сторону ему поворачивать, и не обновлял алгоритм своих действий."
"… однако, вместо того, чтобы пересчитать направление движения..."
То есть, банальная техническая отсталость, увы… Вот так, на жестких предзаложенных установках, можно было летать в 20 веке (да и то в последнем его десятилетии уже стало некузяво). В 21 веке СУ должны все-таки обладать и оперативной situational awareness, и гибкой ее отработкой!
В «Роскосмосе» заявили, что полетное задание для ракеты-носителя «Союз-2.1а» готовили для запуска именно с Восточного, но рассчитать азимуты было «невозможно»
В «Роскосмосе» не согласились с вице-премьером Дмитрием Рогозиным, который обвинил специалистов компании в ошибке при настройке ракеты. Полетное задание для ракеты-носителя «Союз-2.1а» с разгонным блоком «Фрегат» было разработано без ошибок, сообщает «Интерфакс» со ссылкой на пресс-службу госкорпорации.
«Полетное задание прошло проверку именно для космодрома Восточный, что и было проверено специалистами в соответствии с существующими методиками», — заявили в «Роскосмосе». У аварийной комиссии и комиссии, специально назначенной вице-премьером Рогозиным, вопросов по этому направлению не выявлено, добавили в госкопорации.
Причиной аварии «Роскосмос» назвал сочетание нескольких возникших параметров на космодроме Восточный, а именно «азимут стартового стола космодрома, азимут полета ракеты-носителя и разгонного блока (именно солнечно-синхронной орбиты и именно для этого времени года)». Азимуты было «невозможно выявить существующими математическими моделями».
Все штатно сразботало- никто не в чем не виноват
Всем премии
Но ситуация разворачивается в реальном мире и в конкретной стране, и я исхожу из того, что любые чистки по инициативе сверху закончатся только заменой в госкорпорации ещё нескольких неудобных людей на удобных.
Глобально — конечно, надо выходить на безаварийность запусков (хехе, мыши — становитесь ежами). Но это же надо работать систематически, а не только после эпичных отказов бросать всё и разбираться (естественно, с требованием со всех отчётов, наказанием невиновных и награждением непричастных).
Окончательно разбираемся с градусами: причина аварии «Фрегата»