Зенит-3SLБ и Наземный старт

[Salo]

А Вы вспомните причину задержки пуска Амоса в апреле.

[Вован]

Конечно, как я не подумал, там же не было блока ДМ. Но остальное не совсем понятно - из ваших предыдущих сообщений понятно, что была изменена методика работы в связи с автоматизацией рабочих мест. Но как с "тяжёлым" железом "в поле", его серьёзно обновили/заменили или местами чуть-чуть?

Латали дыры у тяжелого железа. Одной дыре не придали значения и получили отмену пуска с Амосом 3.

[SpaceR]

Латали дыры у тяжелого железа. Одной дыре не придали значения и получили отмену пуска с Амосом 3.

Такое ощущение, что вся байконуровская инфраструктура обречена только на "латание дыр"...
Было ли сделано что-нибудь реально новое на Байконуре после 2000 года ? Мелочёвку не считать.

[Вован]

Мы, испытатели, будучи еще военными, мечтали использовать для управления наземным оборудованием СК компьютеры вместо контактно-релейных систем. Даже писали исходные данные и алгоритмы работы для персональных ЭВМ. Высшим пилотажем были автоматические алгоритмы выхода из нештатных ситуаций. Наши доморощенные программисты делали программы, мы их проверяли вхолостую без подключения к реальным системам. Часть разработок мы делали темами дипломных проектов студентов филиала «Восход» МАИ. Так были подготовлены программы для НППК, системы управления ПГС РН, управления стартовым оборудованием. Специалисты СК по другим системам управления не верили в хорошие перспективы и ничего не разрабатывали.
И вот для «Наземного старта» наши мечты начали реализовываться. Головной разработчик КРК «Зенит» (ГКБ «Южное») разработал системы управления на базе ПЭВМ для ПГС РН, НППК, создал автоматизированное рабочее место РР, появился компьютер для управления запуском и работой компрессоров системы 11Г369 для воздушного термостатирования отсеков РН, КА и термостатирования горючего на СК. Жаль, что алгоритмы выхода из нештатных ситуаций были всего лишь текстами из инструкций.
С большим интересом мы начали испытания новых систем управления. И тут начались сюрпризы: система управления ПГС РН в МИКе работала очень плохо, даже однажды ошибочно выдала команду на подрыв пиропатронов подачи огнетушащего состава в ХО-1 штатной ракеты. И патроны сработали! Позже пришлось их заменить.
Система управления ПГС РН на СК работала чуть лучше. Зато НППК старта глючил постоянно.
Довести до ума программно-математическое обеспечение новых систем управления украинские коллеги смогли только через год.

[yos]

Так год это ещё хорошо. Особенно, если это всё чуть ли не впервые внедряется. Говорю вам отвественно, как инженер ПО Подобные задачи очень сложные и без специальных методов не сделать в них ошибки очень сложно.

[SpaceR]

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

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

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

[Вован]

Компьютеры позволяют быстро устранять ошибки и сбои, но дело затягивается из-за монопольного права на это украинского ГКБЮ. А приезжают они не сразу и за отдельную плату.

[zyxman]

Компьютеры позволяют быстро устранять ошибки и сбои, но дело затягивается из-за монопольного права на это украинского ГКБЮ.

Спасибо! Очень интересно!

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

А приезжают они не сразу и за отдельную плату.

А вот это не совсем понятно - я когда-то наблюдал со стороны за разработкой ответственных систем, и если нельзя было работать присылая обновления удаленно, в таких случаях заранее оговаривают период поддержки с определенным количеством экстренных выездов, и это входит отдельной статьей в общий бюджет; я как-то не могу поверить чтобы с вашей стороны не понимали что в любом ПО будут какое-то время уже после сдачи находить и исправлять ошибки.
Есть правда еще вариант когда исполнитель навязывает заказчику свои условия, но мне еще сложнее поверить, что это могло иметь место в данном случае.

Впрочем, это уже сугубо мои ИМХО. Еще раз огромное вам спасибо!

[yos]

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

[Ярослав]

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

наверное, чтоб некий шпиен не сламал svn и не запостил какую ошибку в по, которая потом привела бы к аварии

[yos]

Ну svn здесь не очень к месту. Подобные системы вообще-то предназначены для внутреннего использования. Заменить на расстоянии части программного комплекса довольно просто, хотя бы по такому сценарию: пересылаем например через ssh новые файлы, местный "програмёр-помошник" устанавливает их на конкретные ЭВМ, чтобы те не цеплять в интернет.
Хотя, могу себе представить, что этот последний шаг очень важен и его могут не доверить кому-то не из своей конторы. Вот вам и экслюзив.

[Dude]

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

[yos]

Что-то непонятно насчёт "нелегально".

[Ярослав]

Ну svn здесь не очень к месту. Подобные системы вообще-то предназначены для внутреннего использования. Заменить на расстоянии части программного комплекса довольно просто, хотя бы по такому сценарию: пересылаем например через ssh новые файлы, местный "програмёр-помошник" устанавливает их на конкретные ЭВМ, чтобы те не цеплять в интернет.
Хотя, могу себе представить, что этот последний шаг очень важен и его могут не доверить кому-то не из своей конторы. Вот вым и экслюзив.

а чем плох вариант - кбю комитит в свн очередную версию, на байке месный спец выгребает, жмакает и все =)

инсталляцию/обновление можно в мейкфайл прописать - шоб ниче больше не трогать

одна проблема - комп, подключенный к ракете, подключен и к инету

с другой стороны, можно на байке выделить комп для обновлений, и с него флешкой переносить софт на остальные компы - простым копированием

[yos]

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

[Dude]

Что-то непонятно насчёт "нелегально".

Это значит, что матобеспечение передать можно легко мылом и прошить за пару минут на объекте местными спецами, только потом отгребешь по полной от тех босов, кто кормится на этой теме. Сужу по личному опыту в разработке АРМов и АСУ ТП в 90-х. Думаю, что ничего за это время не поменялось.

[yos]

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

[Вован]

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

[vekazak]

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

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

[Salo]

Интересно, рисунок из буклета ЦЭНКИ со схемой выведения, выложенный Вованом 29 апреля, появился до запуска или после?

Естественно до пуска. Представленные на рисунке параметры целевой орбиты полностью сходятся с данными, размещенными на сайте МИДа до попытки пуска 24 апреля.

План - 0.0°, 35786