с этими определениями нацизма и фашизма очень сложно, в общем случае это фашизм: "фашизм характеризуется централизованной автократией, милитаризмом, жёсткой социальной иерархией, силовым подавлением оппозиции и индивидуальных свобод, а также стремлением к мобилизации общества и к тотальному контролю над обществом и экономикой." Автократия в данном случае трансформированг в главенство одной партии конкретной страны над другими странами, подчинение этой партии общества и экономики других стран. Фашизм это краняя правая ветвь традиционном лево-правовом политическом спектре.
я абсолютно не в курсе, как проверятся бортовая аппаратура, но исходя из смысла программной модели миссии - в неё загружаются оригиналы программного обеспечения (в том виде, в котором они программируются в изделие), которые исполняются на программной модели блока (движке), программная модель блока взаимодействует через модели каналов связи и модели внешних воздействий с остальными элементами изделия. В целях обеспечения отработки различных вариантов изменяются внешние воздействия и состояния блоков (вплоть до эмуляции отказов, сбоев, ошибочного поведения). В случае если все варианты перебрать не возможно (а их действительно адски много) выполняется симуляция миссии со случайными (в пределах) параметрами входных воздействий (по сути метод Монте-Карло). Симуляций, к счастью, можно провести очень много, можно сохранять промежуточные результаты и повторять с любой точки, проводить симуляции параллельно или изолировано. Естественно в вариант симуляции в обязательном виде попадают отказы, сбои отдельных блоков.
Теперь возвращаясь почему ошибка указанная в статье 100% выявляется на симуляции и не является программной ошибкой, а является организационной ошибкой. Если бы в модель КПА загружались оригинальные коды, тогда при симуляции отказа блока "БИУС-Л" мы бы получили то, что случилось в реальности. В данном случае программист не виноват - ему дали неполный алгоритм, он его реализовал, потом сдал ВП, его прогнали на КПА в котором реализуются исключительно штатные ситуации - все ок, претензий к "карманам и пуговицам" нет, но пиджак не сидит...
этого нет, если я правильно понимаю как головной исполнитель работает по ЕСКД и ГОСТ, то есть пункты ТЗ и их сдают как они там они написаны, не запариваясь на то, что должно происходить в случае отклонения данных от смежников.
«Согласно протоколу, при подлёте «Луны-25» к Луне бортовой компьютер станции должен был подать на «БИУС-Л» команду на включение акселерометров. Программисты эту команду подали (это было видно по циклограмме), то есть, по сути, тоже все сделали правильно, за исключением одного. Их программное обеспечение не проанализировало ответную реакцию «БИУС-Л»
Теперь, как нужно было, на мой очень диванный взгляд проверять на программной модели (даже не стенде). Запускать 100500 реализаций и случайным образом в каждой реализации отключать програмные модули (а также менять внешние параметры) и оценивать результат и варианты нештаток. В данном случае цифровой модели небыло, так как смоделированный отказ БИУС-Л, сразу бы указал на ошибку в алгоритме работы бортового компьютера с последующим крушением (на любой стадии проектирования). Я уверен, что цифровой модели миссии у головного исполнителя нет(((
ps: и обратно уверен, что в миссиях китайцев она есть, в современном проектировании без модели никуда(
более всего удручает, что этот отказ/сбой (как и множество остальных) могли быть проверены на цифровой модели и далее стенде, и ошибка в программе была бы исключена(((( ошибка не программистов, а головного исполнителя и главного конструктора(((
извиняюсь за путаницу, да, скорее получается не троирование, но мажоритирование вполне применимо, принцип практического мажоритирования для примера описан на базе Virtex в статье ниже. Добавлю, к ответу Spaceoddity, что такие схемы мажоритирования позволяют парировать одиночные сбои в логике. Насколько я знаю, такие подходы к реализации отказоустойчивой техники есть и у ПЛИС производителей Actel, Altera, Xilinx и других...
" Таким образом, в ПЛИС Virtex фирмы Xilinx при реализации троирования (Triple Module Redundancy – TMR) с целью повышения радиационной стойкости используются встроенные схемы выбора 2 из 3-х или мажоритирования (голосования по большинству голосов – Majority Voter Circuit). Для выдачи мажоритированного сигнала на контакты ПЛИС Virtex используется функция минорити. При этом она реализуется в трёх LUT, причём единичный сигнал формируется только в случае отличия данного входа от двух других, что обеспечивает на выходе буферов, не находящихся в третьем состоянии, всегда 0 или 1 без «смешения» и без использования подтягивающего резистора, то есть конфликты исключены. "
чтобы не повредило, есть троирование, проблема, как мне видится, именно в зашоренности при проектировании на "жесткой логике", вместо полноценного функционального программирования, когда на каждом этапе результат сверяется с моделью, при этом не только исполнительным модулем, но и контрольным.
ps: про то, что наши до сих пор проектируют блоки управления на БМК, можете мне не рассказывать, как они решают вопрос модификации софта, мне не ведомо... видимо ориентируясь на выполнение циклограммы по табличке...
поймите, я не в укор, и вообще очень сильно переживаю за сложные миссии, сам учавствую в относительно сложных проектах, но намного проще, чем межпланетные, но даже на простых проектах можно заметить, как сложно заставить всё функционировать как единое изделие...
к сожалению, то как я вижу (могу и заблуждаться, но если бы не было предмета обсуждения) - "пиджак не сидит, к карманам и пуговицам претензий нет, но пиджак не сидит", потому как ошибка намного выше и над системная, чем отдельные составные части миссии. Всё что я тут написал имеет смысл в обсуждении будущих миссий (хотя это всё на уровне общения на кухне), чтобы изменить системный подход к проектированию и реализации таких миссий.
ps: вот бы подсмотреть у китайцев, как они проектируют... но это мечты-мечты...
pss: ну и спасибо за диалог, надеюсь, что он взаимно полезен (мне так точно)
а вам ещё раз скажу, что это ошибка не ДУ, не автоматики, а проектировщиков и общая системная ошибка. Та автоматика, которая произвела отсечку, должна была контролировать не только время, но и вектор импульса и терминировать, как только выйдет за пределы модели. Опять же "цифровой двойник" или как он называется в НПОЛ, должен был сразу показать, что в случае нештатки в этой фазе произойдет превышение импульса, и всё было бы исправлено ещё на этапе проектирования. Но цифрового двойника опять же нет.
Опять же это моё личное мнение, но по моему опыту - все нештатки в цифровой модели сразу четко выявляются, даже если цифровая модель не полная. Ну и миллион раз прогнать цифровую модель с разными параметрами вообще не проблема за пару часов или, может, ночей.
ps: да и в идеале цифровая модель должна "лететь" вместе на спутнике...
вообще не имею никакого отношения, я могу только прочитать Вестник НПОЛ и то, что я там вижу - меня очень сильно удручает. Более компетентных источников, чем журнал НПОЛ у меня нет.
К сожалению, я мог бы считать, что я искренне и полностью заблуждаюсь, но некоторое количество нештаток при выполнении маневров Фобос-Грунтом, Фрегата и последний с Луной, убеждают меня в том, что в организации работы динамических операций присутствует системная ошибка. Нет, ну можно сказать, что Луна-25 всё выполнила правильно, и мы можем планировать в рамках этих уже устоявшихся процедур и остальные проекты - но это не так. Не нужно обманывать себя, что ничего не нужно менять. Железо за последние десять лет подтянули, а вот программы и подход к разработке, как были 1989 года, так и, видимо, остались.
Да это чисто личное мнение, сильно гипертрофированное разочарованием от крайней миссии.
ps: про таймер акцентировал внимание не я, а Борисов:
"Вместо запланированных 84 секунд он отработал 127 секунд. Это явилось основной причиной аварии аппарата", - заявил глава "Роскосмоса".
судя по тому, что работа двигательной установки была прервана по времени, а не по несоответствию набранному импульсу - управление траекторными коррекциями выполняется не по оценке накопленного приращения скорости, а по таймеру. В противном случае маневр был бы прерван по расхождению модели и фактически набранному вектору... Ну и подтверждение, как программируется в НПО платформа с 1989 года, я выше привёл - это из их Вестника.
Раздел: "Реакция на ошибку" довольно показательная, то есть оценка производится после ненормального завершения команды, а не во время её выполнения. Что и наблюдалось на Луне-25, когда внешние процедуры не контролировали выполнение маневра, а просто выждали время около 127с.
когда Фрегат просто не успел повернуть платформу на нужный угол, так как без обратной связи следующая итерация просто началась по таймеру, хотя построение ориентации ещё не завершилось. Вектор импульса во время выполнения маневра скорректирован не был.
Повторюсь, что на текущем уровне развития, должен быть многоуровневый многопроцессный/многозадачный контроль выполнения операции. Когда операция производится отдельным процессом, одновременно отдельным процессом выполняется моделирование на борту по имеющимся данным телеметрии, и отдельным процессом производится сравнение модели и фактических данных и этот процесс должен иметь возможность и права на прерывание операции. Итого три независимых процесса (может быть даже на разных физических ядрах/платах). В любом случае видимый подход по открытым данным выглядит тупиковым, его обоснованность применения с 1989г по текущий день - не выглядит доказанной.
естественно не через Землю, но хотя бы в контур обратной связи включить интегратор импульса на борту, то, что у них сейчас реализовано, судя по их же статье - что-то типа релейного автомата выполнения команд, после этого изобрели уже функциональное программирование, операционные системы, многозадачность и даже (о ужас!) объектно-ориентированное программирование... и много чего ещё, а то, что я вижу по статьям Лавочкина - это 70е годы полёты к Луне на механическом таймере... (((
если они без обратной связи, по таймеру, как на Луне, продолжат выполнять маневры, то максимум на что можно рассчитывать - это выход на орбиту Марса (((
это типичное заблуждение, есть классический пример, более понятный в IT: когда сеть в конторе настроена - админа не видно, он может сидеть у себя в серверной и гонять д00ма или доту. Иногда, очень одаренные руководители в этот момент увольняют админа, и сеть начинает деградировать. С сеткой упрощенный вариант, но зато жизненный.
идеальный результат не достижим, к нему нужно стремиться, и работа руководителя в том и заключается - в настройке взаимосвязей доверенного ему коллектива, чтобы он функционировал как часы, но без вовлечения в процессы самого руководителя.
так хорошо начиналось... а потом эти ужасные эксельки, графики, встречи...
чтобы стать руководителем и не выгореть: привыкайте делегерировать. Задача так настроить процессы, чтобы вы в них не учавствовали, идеальный конечный результат - у вас должен быть пустой ежедневник с пометкой попить пива с коллегами и отдельно с директором/директорами. Если вы сами будете интенсивно учавствлвать в процессах - вы кончитесь.
ps: правило трех крючков - потенциальная засада, когда к вам придут в третий раз, то очень вероятно уже за результатом, а у вас ни у шубы рукава ))) или крючки просто отвалятся в какой-то момент под тяжестью навешанного. Рекомендовал бы принимать решения сразу, все что можно сделать в течении получаса - в приоритете, если это потенциально может занять больше дня - требую от заинтересованного в вопросе (менеджера) оформить задачу в систему и согласовать ведущего инженера, кто ее сможет выполнить.
верное замечание, МэВ, но это не это не исключает того факта, что частицы высоких энергий способствуют электронам в полупроводниках, для примера трек космической частицы, который зафиксировала недавно камера на телескопе. Частица прошла вдоль матрицы и выбила целую полосу, что эквивалентно сотням тысяч электрон. Если бы такая частица прошила ПЗУ, то часть бит могли бы изменить своё значение. В памяти SLC энергия требуемая для переключения значительно больше чем в MLC памяти и тем более QLC.
ps: да в флешках используется коррекция, но если, как на фото, частица неудачно прошила сразу много ячеек, то коррекция уже может не справиться (((
с этими определениями нацизма и фашизма очень сложно, в общем случае это фашизм: "фашизм характеризуется централизованной автократией, милитаризмом, жёсткой социальной иерархией, силовым подавлением оппозиции и индивидуальных свобод, а также стремлением к мобилизации общества и к тотальному контролю над обществом и экономикой." Автократия в данном случае трансформированг в главенство одной партии конкретной страны над другими странами, подчинение этой партии общества и экономики других стран. Фашизм это краняя правая ветвь традиционном лево-правовом политическом спектре.
я абсолютно не в курсе, как проверятся бортовая аппаратура, но исходя из смысла программной модели миссии - в неё загружаются оригиналы программного обеспечения (в том виде, в котором они программируются в изделие), которые исполняются на программной модели блока (движке), программная модель блока взаимодействует через модели каналов связи и модели внешних воздействий с остальными элементами изделия. В целях обеспечения отработки различных вариантов изменяются внешние воздействия и состояния блоков (вплоть до эмуляции отказов, сбоев, ошибочного поведения). В случае если все варианты перебрать не возможно (а их действительно адски много) выполняется симуляция миссии со случайными (в пределах) параметрами входных воздействий (по сути метод Монте-Карло). Симуляций, к счастью, можно провести очень много, можно сохранять промежуточные результаты и повторять с любой точки, проводить симуляции параллельно или изолировано. Естественно в вариант симуляции в обязательном виде попадают отказы, сбои отдельных блоков.
Теперь возвращаясь почему ошибка указанная в статье 100% выявляется на симуляции и не является программной ошибкой, а является организационной ошибкой. Если бы в модель КПА загружались оригинальные коды, тогда при симуляции отказа блока "БИУС-Л" мы бы получили то, что случилось в реальности. В данном случае программист не виноват - ему дали неполный алгоритм, он его реализовал, потом сдал ВП, его прогнали на КПА в котором реализуются исключительно штатные ситуации - все ок, претензий к "карманам и пуговицам" нет, но пиджак не сидит...
этого нет, если я правильно понимаю как головной исполнитель работает по ЕСКД и ГОСТ, то есть пункты ТЗ и их сдают как они там они написаны, не запариваясь на то, что должно происходить в случае отклонения данных от смежников.
Теперь, как нужно было, на мой очень диванный взгляд проверять на программной модели (даже не стенде). Запускать 100500 реализаций и случайным образом в каждой реализации отключать програмные модули (а также менять внешние параметры) и оценивать результат и варианты нештаток. В данном случае цифровой модели небыло, так как смоделированный отказ БИУС-Л, сразу бы указал на ошибку в алгоритме работы бортового компьютера с последующим крушением (на любой стадии проектирования). Я уверен, что цифровой модели миссии у головного исполнителя нет(((
ps: и обратно уверен, что в миссиях китайцев она есть, в современном проектировании без модели никуда(
датчики дублирования стараются делать на разных физических принципах, если один волоконно-оптический, то другой мемс и/или гироскопический
более всего удручает, что этот отказ/сбой (как и множество остальных) могли быть проверены на цифровой модели и далее стенде, и ошибка в программе была бы исключена(((( ошибка не программистов, а головного исполнителя и главного конструктора(((
не начинать маневр, остались бы на орбите, это мог быть сбой, а не отказ, тогда маневр бы выполнили на следующем витке
извиняюсь за путаницу, да, скорее получается не троирование, но мажоритирование вполне применимо, принцип практического мажоритирования для примера описан на базе Virtex в статье ниже. Добавлю, к ответу Spaceoddity, что такие схемы мажоритирования позволяют парировать одиночные сбои в логике. Насколько я знаю, такие подходы к реализации отказоустойчивой техники есть и у ПЛИС производителей Actel, Altera, Xilinx и других...
http://vestnik.rsreu.ru/images/archive/2017/1-59/11_.pdf
чтобы не повредило, есть троирование, проблема, как мне видится, именно в зашоренности при проектировании на "жесткой логике", вместо полноценного функционального программирования, когда на каждом этапе результат сверяется с моделью, при этом не только исполнительным модулем, но и контрольным.
ps: про то, что наши до сих пор проектируют блоки управления на БМК, можете мне не рассказывать, как они решают вопрос модификации софта, мне не ведомо... видимо ориентируясь на выполнение циклограммы по табличке...
поймите, я не в укор, и вообще очень сильно переживаю за сложные миссии, сам учавствую в относительно сложных проектах, но намного проще, чем межпланетные, но даже на простых проектах можно заметить, как сложно заставить всё функционировать как единое изделие...
к сожалению, то как я вижу (могу и заблуждаться, но если бы не было предмета обсуждения) - "пиджак не сидит, к карманам и пуговицам претензий нет, но пиджак не сидит", потому как ошибка намного выше и над системная, чем отдельные составные части миссии. Всё что я тут написал имеет смысл в обсуждении будущих миссий (хотя это всё на уровне общения на кухне), чтобы изменить системный подход к проектированию и реализации таких миссий.
ps: вот бы подсмотреть у китайцев, как они проектируют... но это мечты-мечты...
pss: ну и спасибо за диалог, надеюсь, что он взаимно полезен (мне так точно)
а вам ещё раз скажу, что это ошибка не ДУ, не автоматики, а проектировщиков и общая системная ошибка. Та автоматика, которая произвела отсечку, должна была контролировать не только время, но и вектор импульса и терминировать, как только выйдет за пределы модели. Опять же "цифровой двойник" или как он называется в НПОЛ, должен был сразу показать, что в случае нештатки в этой фазе произойдет превышение импульса, и всё было бы исправлено ещё на этапе проектирования. Но цифрового двойника опять же нет.
Опять же это моё личное мнение, но по моему опыту - все нештатки в цифровой модели сразу четко выявляются, даже если цифровая модель не полная. Ну и миллион раз прогнать цифровую модель с разными параметрами вообще не проблема за пару часов или, может, ночей.
ps: да и в идеале цифровая модель должна "лететь" вместе на спутнике...
вообще не имею никакого отношения, я могу только прочитать Вестник НПОЛ и то, что я там вижу - меня очень сильно удручает. Более компетентных источников, чем журнал НПОЛ у меня нет.
К сожалению, я мог бы считать, что я искренне и полностью заблуждаюсь, но некоторое количество нештаток при выполнении маневров Фобос-Грунтом, Фрегата и последний с Луной, убеждают меня в том, что в организации работы динамических операций присутствует системная ошибка. Нет, ну можно сказать, что Луна-25 всё выполнила правильно, и мы можем планировать в рамках этих уже устоявшихся процедур и остальные проекты - но это не так. Не нужно обманывать себя, что ничего не нужно менять. Железо за последние десять лет подтянули, а вот программы и подход к разработке, как были 1989 года, так и, видимо, остались.
Да это чисто личное мнение, сильно гипертрофированное разочарованием от крайней миссии.
ps: про таймер акцентировал внимание не я, а Борисов:
"Вместо запланированных 84 секунд он отработал 127 секунд. Это явилось основной причиной аварии аппарата", - заявил глава "Роскосмоса".
https://www.interfax.ru/russia/917157
Если вы знаете, как при динамических операциях может быть терминирование по таймеру, а не по ошибке набранного вектора импульса, то прошу рассказать.
судя по тому, что работа двигательной установки была прервана по времени, а не по несоответствию набранному импульсу - управление траекторными коррекциями выполняется не по оценке накопленного приращения скорости, а по таймеру. В противном случае маневр был бы прерван по расхождению модели и фактически набранному вектору... Ну и подтверждение, как программируется в НПО платформа с 1989 года, я выше привёл - это из их Вестника.
Раздел: "Реакция на ошибку" довольно показательная, то есть оценка производится после ненормального завершения команды, а не во время её выполнения. Что и наблюдалось на Луне-25, когда внешние процедуры не контролировали выполнение маневра, а просто выждали время около 127с.
предыдущая известная авария по таймеру:
https://habr.com/ru/articles/371065/
https://habr.com/ru/articles/409035/
когда Фрегат просто не успел повернуть платформу на нужный угол, так как без обратной связи следующая итерация просто началась по таймеру, хотя построение ориентации ещё не завершилось. Вектор импульса во время выполнения маневра скорректирован не был.
Повторюсь, что на текущем уровне развития, должен быть многоуровневый многопроцессный/многозадачный контроль выполнения операции. Когда операция производится отдельным процессом, одновременно отдельным процессом выполняется моделирование на борту по имеющимся данным телеметрии, и отдельным процессом производится сравнение модели и фактических данных и этот процесс должен иметь возможность и права на прерывание операции. Итого три независимых процесса (может быть даже на разных физических ядрах/платах). В любом случае видимый подход по открытым данным выглядит тупиковым, его обоснованность применения с 1989г по текущий день - не выглядит доказанной.
ещё из Вестника
естественно не через Землю, но хотя бы в контур обратной связи включить интегратор импульса на борту, то, что у них сейчас реализовано, судя по их же статье - что-то типа релейного автомата выполнения команд, после этого изобрели уже функциональное программирование, операционные системы, многозадачность и даже (о ужас!) объектно-ориентированное программирование... и много чего ещё, а то, что я вижу по статьям Лавочкина - это 70е годы полёты к Луне на механическом таймере... (((
если они без обратной связи, по таймеру, как на Луне, продолжат выполнять маневры, то максимум на что можно рассчитывать - это выход на орбиту Марса (((
это типичное заблуждение, есть классический пример, более понятный в IT: когда сеть в конторе настроена - админа не видно, он может сидеть у себя в серверной и гонять д00ма или доту. Иногда, очень одаренные руководители в этот момент увольняют админа, и сеть начинает деградировать. С сеткой упрощенный вариант, но зато жизненный.
идеальный результат не достижим, к нему нужно стремиться, и работа руководителя в том и заключается - в настройке взаимосвязей доверенного ему коллектива, чтобы он функционировал как часы, но без вовлечения в процессы самого руководителя.
кого не хватает?
так хорошо начиналось... а потом эти ужасные эксельки, графики, встречи...
чтобы стать руководителем и не выгореть: привыкайте делегерировать. Задача так настроить процессы, чтобы вы в них не учавствовали, идеальный конечный результат - у вас должен быть пустой ежедневник с пометкой попить пива с коллегами и отдельно с директором/директорами. Если вы сами будете интенсивно учавствлвать в процессах - вы кончитесь.
ps: правило трех крючков - потенциальная засада, когда к вам придут в третий раз, то очень вероятно уже за результатом, а у вас ни у шубы рукава ))) или крючки просто отвалятся в какой-то момент под тяжестью навешанного. Рекомендовал бы принимать решения сразу, все что можно сделать в течении получаса - в приоритете, если это потенциально может занять больше дня - требую от заинтересованного в вопросе (менеджера) оформить задачу в систему и согласовать ведущего инженера, кто ее сможет выполнить.
верное замечание, МэВ, но это не это не исключает того факта, что частицы высоких энергий способствуют электронам в полупроводниках, для примера трек космической частицы, который зафиксировала недавно камера на телескопе. Частица прошла вдоль матрицы и выбила целую полосу, что эквивалентно сотням тысяч электрон. Если бы такая частица прошила ПЗУ, то часть бит могли бы изменить своё значение. В памяти SLC энергия требуемая для переключения значительно больше чем в MLC памяти и тем более QLC.
ps: да в флешках используется коррекция, но если, как на фото, частица неудачно прошила сразу много ячеек, то коррекция уже может не справиться (((