Метеор-М №2-1 с попутчиками – Союз-2.1Б/Фрегат – Восточный 1С – 28.11.2017 08:41 ДМВ - авария

Serge V Iz · 17.12.2017 15:17:03

ЦитироватьВнутричерепного, что-ли?

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

opinion · 17.12.2017 17:18:16

ЦитироватьDenis Voronin пишет:

Потому что регулярный рефакторинг кода это норма. Как и обновления по железу. Такова жизнь в IT.

Далеко не всегда и никогда не самоцель. Только когда код изменяется.

По ПО: есть программы на COBOL, которые реально используются. Людей, которые знают язык, давно нет, а проги работают.
По железу - истории о серверах, замурованных в стенах во время ремонта много лет назад, весьма недалеки от реальности.

Denis Voronin · 17.12.2017 18:39:05

Цитироватьopinion пишет:
По ПО: есть программы на COBOL, которые реально используются. Людей, которые знают язык, давно нет, а проги работают.

Раньше делали всё весьма монолитно. Но последние два десятка лет стараются делать модульно и обновляемо.

Цитироватьopinion пишет:
По железу - истории о серверах, замурованных в стенах во время ремонта много лет назад, весьма недалеки от реальности.

Да реальны так-то, но это говорит о том что не было никакого развития. Если ит-инфраструктура предприятия не развивается, то это вызывает вопросы.

Lunatik-k · 17.12.2017 20:24:14

ЦитироватьDenis Voronin пишет:
Цитироватьopinion пишет:
По ПО: есть программы на COBOL, которые реально используются. Людей, которые знают язык, давно нет, а проги работают.
Раньше делали всё весьма монолитно. Но последние два десятка лет стараются делать модульно и обновляемо.
Цитироватьopinion пишет:
По железу - истории о серверах, замурованных в стенах во время ремонта много лет назад, весьма недалеки от реальности.
Да реальны так-то, но это говорит о том что не было никакого развития. Если ит-инфраструктура предприятия не развивается, то это вызывает вопросы.

Когда наступит осознание что процессом рулит не специалист, а кумы и сваты, то все вопросы сразу отпадают.

Штуцер · 17.12.2017 20:56:34

ЦитироватьLunatik-k пишет:
Когда наступит осознание что процессом рулит не специалист, а кумы и сваты, то все вопросы сразу отпадают.

Ну хватит уже. Мы осознали Вашу позицию.

Morin · 17.12.2017 21:11:13

ЦитироватьSGS_67 пишет:
ЦитироватьMorin пишет:

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

"Давно", - имеется в виду - вскоре после аварии, а не до нее. Если б знали ДО, то, конечно, как-нибудь довели до начальства. У меня были такие случаи. Без заявлений на стол. :-)

Morin · 17.12.2017 22:17:26

ЦитироватьDenis Voronin пишет:
ЦитироватьZOOR пишет:
Наконец понял, кто виноват. Это были 2 геодезиста
Точно 2?

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

Чем они руководствовались мы знать не можем, но, точно, не проектной документацией, которой не было. Может рельеф местности позволял уменьшить объем земляных работ, может подъезд удобнее было организовать...? Х.з. Справедливости ради надо сказать, что строители пытались выяснить, как же им расположить ПУ, но ответа не получили. Наверное, был неофициальный ответ типа: Мы щас умеем с любого азимута пускать.

Serge V Iz · 17.12.2017 21:21:16

Я видел испытательный стенд для МДУ, при строительстве которого использовался удачно подвернувшийся огромный овраг.

Denis Voronin · 17.12.2017 22:53:31

ЦитироватьMorin пишет:
Справедливости ради надо сказать, что строители пытались выяснить, как же им расположить ПУ, но ответа не получили.

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

Кубик · 18.12.2017 00:06:12

ЦитироватьMorin пишет: типа: Мы щас умеем с любого азимута пускать.

А раньше не умели? и что изменилось, кроме способа поворота ракеты вокруг продольной оси в начале? На любой азимут - говорить надо.. И то практически далеко не на любой.

Дем · 18.12.2017 00:22:25

Тут много разговоров про программирование, но не сказало одной важной вещи - а умеет ли компьютер и компилятор вообще реагировать на прерывания.
В описании языка "Дракон" я по крайней мере такого не вижу.
Т.е. можно запустить расчёт манёвра по включении, но нельзя по отделении РБ от носителя.
Можно поставить паузу в минуту между началом поворота и включением маршевого движка, но нельзя узнать когда РБ достигнет требуемой ориентации.

ЦитироватьMorin пишет:
Справедливости ради надо сказать, что строители пытались выяснить, как же им расположить ПУ, но ответа не получили. Наверное, был неофициальный ответ типа: Мы щас умеем с любого азимута пускать.

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

Serge V Iz · 17.12.2017 22:29:42

Цитироватьумеет ли компьютер и компилятор вообще реагировать на прерывания

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

Кубик · 18.12.2017 00:55:33

ЦитироватьДем пишет: Учитывая что ПУ расположено почти как надо, только наоборот - какую-то цифру про
азимут всё же сказали. Но теперь тому кто сказал и ошибся на 180 стыдно признаться.

Вот уж как проблемно всё оказалось..Да установите вы ракету на ПУ с поворотом на 180, оси переименуйте, ну и живите счастливо..

Если топлива на разворот по крену жаль, а виноватых найти надо..

Serge V Iz · 17.12.2017 23:13:59

ЦитироватьДа установите вы ракету на ПУ с поворотом на 180,

Так ведь КЗМ куда-то подводить-отводить надо. Автомать.ика )

Кубик · 18.12.2017 01:21:53

ЦитироватьSerge V Iz пишет:
ЦитироватьДа установите вы ракету на ПУ с поворотом на 180,
Так ведь КЗМ куда-то подводить-отводить надо. Автомать.ика )

Блин, всю ПУ тогда перемонтировать...

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

Serge V Iz · 17.12.2017 23:28:57

Цитировать болгарками и кувалдами могёт

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

Кубик · 18.12.2017 01:52:52

Занятно, что использование для запуска Союза-2 старых ПУ с поворотным кругом усложняет операции по подготовке.. Вот и чеши тут репу..

Дем · 18.12.2017 04:50:49

ЦитироватьSerge V Iz пишет:
Вопрос не совсем того... Дракон слишком высокоуровневый для детализации того, как на уровне системного ПО этой машины реализовать механизмы доставки асинхронных событий.

А Скратч что круто низкоуровневый? Однако умеет.

mind22 · 18.12.2017 03:42:43

ЦитироватьДем пишет:
Тут много разговоров про программирование, но не сказало одной важной вещи - а умеет ли компьютер и компилятор вообще реагировать на прерывания.
В описании языка "Дракон" я по крайней мере такого не вижу.

Если писать программу с применением подхода, как в ПЛК (Программируемый логический контроллер), то на уровне прикладной программы никаких прерываний и не нужно.

Программирование ПЛК имеет отличие от традиционного программирования. Это связано с тем, что ПЛК исполняют бесконечную последовательность программных циклов, в каждом из которых:

считывание входных сигналов, в том числе манипуляций, например, на клавиатуре оператором;
вычисления выходных сигналов и проверка логических условий;
выдача управляющих сигналов и при необходимости управление индикаторами интерфейса оператора

Так же можно заметить, что ПЛК на C/C++ никто особо и не программирует. Для программирования используется стандартизированные языки МЭК (IEC) стандарта IEC61131-3:

Языки программирования (графические)

LD (Ladder Diagram) — Язык релейных схем — самый распространённый язык для PLC
FBD (Function Block Diagram) — Язык функциональных блоков — 2-й по распространённости язык для PLC
SFC (Sequential Function Chart) — Язык диаграмм состояний — используется для программирования автоматов
CFC (Continuous Function Chart) — Не сертифицирован IEC61131-3, дальнейшее развитие FBD

Языки программирования (текстовые)

IL (Instruction List) — Ассемблеро-подобный язык
ST (Structured Text) — Паскале-подобный язык
C-YART — Си-подобный язык (YART Studio)

opinion · 18.12.2017 08:00:00

ЦитироватьДем пишет:
Тут много разговоров про программирование, но не сказало одной важной вещи - а умеет ли компьютер и компилятор вообще реагировать на прерывания.
В описании языка "Дракон" я по крайней мере такого не вижу.

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

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

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