более всего удручает, что этот отказ/сбой (как и множество остальных) могли быть проверены на цифровой модели и далее стенде, и ошибка в программе была бы исключена(((( ошибка не программистов, а головного исполнителя и главного конструктора(((
извиняюсь за путаницу, да, скорее получается не троирование, но мажоритирование вполне применимо, принцип практического мажоритирования для примера описан на базе 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: да в флешках используется коррекция, но если, как на фото, частица неудачно прошила сразу много ячеек, то коррекция уже может не справиться (((
ну если флешка не SLC, а MLC... или даже TLC/QLC... то при меньшей энергии происходит изменение состояния ячейки памяти... а я так слышал, что в космосе энергии частиц измеряются мегавольтами... Да, не вся энергия передаётся при взаимодействии, но влияние на SLC - менее значительное...
так что модель роялит...
ps: в SLC в одной ячейке один бит и энергия для переключения значительная, в MLC - два бита, в TLC - три, а в QLC - четыре...
датчики дублирования стараются делать на разных физических принципах, если один волоконно-оптический, то другой мемс и/или гироскопический
более всего удручает, что этот отказ/сбой (как и множество остальных) могли быть проверены на цифровой модели и далее стенде, и ошибка в программе была бы исключена(((( ошибка не программистов, а головного исполнителя и главного конструктора(((
не начинать маневр, остались бы на орбите, это мог быть сбой, а не отказ, тогда маневр бы выполнили на следующем витке
извиняюсь за путаницу, да, скорее получается не троирование, но мажоритирование вполне применимо, принцип практического мажоритирования для примера описан на базе 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: да в флешках используется коррекция, но если, как на фото, частица неудачно прошила сразу много ячеек, то коррекция уже может не справиться (((
ждём... уже три часа как...
Кстати, а как вы решаете вопрос сброса лишнего/статического заряда со спутника? ведь заземления нет...
ну если флешка не SLC, а MLC... или даже TLC/QLC... то при меньшей энергии происходит изменение состояния ячейки памяти... а я так слышал, что в космосе энергии частиц измеряются мегавольтами... Да, не вся энергия передаётся при взаимодействии, но влияние на SLC - менее значительное...
так что модель роялит...
ps: в SLC в одной ячейке один бит и энергия для переключения значительная, в MLC - два бита, в TLC - три, а в QLC - четыре...