Вопросы грозозащиты ВС (по катастрофе SSJ)

[dmdimon]

Взрывомагнитный генератор

 

[Антон К.]

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

Ну мы просто совсем о разных вещах говорим. Человек написал про диаметр канала в десяток метров, я вспомнил про давление ударной волны в мегапаскаль, и понял что долбани такая в кремль, в пределах ТТК ни выживших, ни уцелевших зданий не осталось бы. О чем и написал.
А то что наводки молнии могут жуткие создавать, я и не спорю. Для этого особой энергетики не нужно, Вы правы.
[automerge]1558263516[/automerge]

Ну так он сильней молнии электронику губит.

Но, как правило, обратимо.

 

[Kit.]

Читаем по вашей ссылке: These servers had almost ground to a halt after failing to properly accommodate the "leap second" that was added to the world's atomic clocks on Saturday night, as June turned into July. leap second - это високосная секунда.
Нет, неправильно. С високосными секундами и днями все, что угодно бывает.

Я думаю иное - вы не понимаете, чем монотонное время отличается от календарного, UTC - от астрономического (UT0/UT1/UT2), а измерение времени - от измерения интервалов.

Я думаю, вы не понимаете, как уменьшать количество потенциальных багов в большом проекте. Да и в багах, связанных конкретно со временем, имеете немного опыта.

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

В смысле, должны использоваться.

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

Вся беда в том, что hrtimer основаны на "разбуди меня в 4:20". И если после 4:19:59 будет 4:19:60 или 4:20:01 - им с большой вероятностью поплохеет.

Так не "должно" плохеть-то. От NTP не плохеет, от PTP не плохеет, от прямого stime()/settimeofday() не плохеет - а от leap second плохеет. Плохеет потому, что баги.

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

Да точно так же, как ваш.

Контроль на вычислителях основан на том, что сами вычислители - ломаются редко, а вот датчики часто врут.

Вы, кажется, говорили про помеху на шине?

Вот простой пример - MCAS. У каждого вычислителя - свой датчик атаки и скорости. Как потребитель может понять, MCAS какого борта права, правого или левого? А вот вычислители, имея всю информацию со своих датчиков и результат соседа - могут дать решение "мои датчики врут, я работаю неверно" или "я прав, а датчики соседа врут".

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

Ну не совсем отказ, а разность алгоритмов.

Алгоритм либо указан в спецификации, либо разность в алгоритмах намеренна - на случай наличия ошибки в одном из них - и система проектируеся так, чтобы с ней справляться.

Так что контроль может проскочить баг любого размера. Этой плате сильно повезло, что полгода её использовали именно в том режиме, в каком она изначально была работоспособна.

Ну, собственно, от отладочной платы и не требуется такая тщательность тестирования, как для железки, от которой зависят жизни людей.

 

[dmdimon]

самому вычислителю намного проще понять, что не не прав,

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

Но, как правило, обратимо.

Э-э? Есть мнение, что в частности пробой переходов плохо обратим.

 

[SDA]

Э-э? Есть мнение, что в частности пробой переходов плохо обратим.

Известно, что стабилитроны работают в режиме электрического пробоя.
Если не загонять в область теплового пробоя, то процесс весьма обратимый.

 

[dmdimon]

Известно, что стабилитроны работают в режиме электрического пробоя.
Если не загонять в область теплового пробоя, то процесс весьма обратимый.

мой ответ был в контексте воздействия ЭМИ от ВМГ на электронику.

Просто если блок решил что он сам не прав - достаточно его решения. А вот для внешнего контроля надо несовпадение нашего решения с двумя блоками.

несовпадение вектора состояния блока с двумя другими как метод контроля более надежно, чем внутренний контроль блока. Чистый тервер. Внутренний контроль блока может и сам заглючить, не забывайте. Не забывайте также, что целевая задача - не поотключать все подозрительные блоки, а обеспечить наибольшую вероятность получения достоверных данных на (условно) железе, которое в сумме весит N кг и потребляет M ватт.

Если опирается на неверные данные с датчиков

То это - проблема датчиков и их системы контроля работоспособности. Что конечно не отменяет необходимость отключения такого блока - если контроль датчиков не справился.

блок ложно решил, что он дает неверные данные

Проблема в том, что у блока мало опоры, чтобы понять, верные данные он дает или нет. А если опоры достаточно - то что мешает ему исправиться в случае некритических проблем типа сбоя в передаче данных? Зачем отключать-то его, тем более если у вас запас в вычислительных мощностях 4-10 раз?

 

[Sergey-nn]

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

Спасибо за уточнение, однако "довольно много каналов" раскиданных по площади в 100 кв м. с т.з. воздействия на выступающие части (в т.ч. антенны) ни чем не отличается от сплошного воздействия на всю площадь. Разве только тем, что при "сплошном канале" ток протекающий по антенному кабелю окажется в десятки (или сотни) раз слабее, чем при прямом попадании одного из каналов. А "боковые" воздействия будут полностью идентичны.
Таким образом Ваше уточнение ни разу не облегчает построение систем грозозащиты...

 

[Антон К.]

Спасибо за уточнение, однако "довольно много каналов" раскиданных по площади в 100 кв м. с т.з. воздействия на выступающие части (в т.ч. антенны) ни чем не отличается от сплошного воздействия на всю площадь. Разве только тем, что при "сплошном канале" ток протекающий по антенному кабелю окажется в десятки (или сотни) раз слабее, чем при прямом попадании одного из каналов. А "боковые" воздействия будут полностью идентичны.
Таким образом Ваше уточнение ни разу не облегчает построение систем грозозащиты...

Ну хотя бы нет задачи выдержать ударную волну на уровне ядерного оружия. Уже полегче однако...

 

[Sergey-nn]

Ну вот как пример - MCAS. Блок видит расхождение датчика скорости и показаний инерциалки. И не понимает, что случилось:

• врет датчик скорости?
• врет инерциалка?
• врут оба?
• никто не врет, просто самолет в штопоре?
• баг в алгоритме?

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

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

В результате написали (что знают), проверили по своим же алгоритмам - и в серию.
Поэтому "боинги" падают при отказе всего одного датчика.

 

[ads]

.... Кстати ранее я писал про глушилку (маленькая молния), которую купил, инженеры пробовали на А, виснет индикация, восстанавливается после отключения питания и вновь включения.

..... вроде как современную электронику проверяют на устойчивость к ЭМИ маленькими молниями, пока не зависнет, скажите, для бортовой электронике тоже проверяют на "зависание" или всё же НЕ ПРОВЕРЯЮТ ????

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

Кто нибудь знает, проверяют так от воздействия ЭМИ бортовую электронику на "зависание"

 

[Sergey-nn]

Кто нибудь знает, проверяют так от воздействия ЭМИ бортовую электронику на "зависание"

Безусловно.
Это один из этапов испытаний, точно так же как и ЭМС.
Вопрос (как всегда) в корректности этих проверок. Методики то же люди пишут..

 

[ads]

Безусловно.
Это один из этапов испытаний, точно так же как и ЭМС.
Вопрос (как всегда) в корректности этих проверок. Методики то же люди пишут..

То есть получается PFD на эрбасе проверяли на ЭМИ при испытаниях, все было ОК,
НО от "глушилки" он виснет, тогда надо глушилку для проверки на ЭМИ брать у русских умельцев, и будет корректная методика.
Да..... , я всё крепче задумываюсь.

 

[TIMER]

Одно непонятно : как это сонмище летает в то время как умы форума чешут репы насчёт несовершенства в вопросах грозозащищённости данных девайсов ?

Карта авиамаршрутов в реальном времени

ÐÑедлагаем вам понаблÑдаÑÑ Ð² ÑеалÑном вÑемени за ÑамолеÑами ÑазлиÑнÑÑ Ð°Ð²Ð¸Ð°ÐºÐ¾Ð¼Ð¿Ð°Ð½Ð¸Ð¹, коÑоÑÑе наÑодÑÑÑÑ Ð¿ÑÑмо ÑейÑÐ°Ñ Ð² воздÑÑе.

aeronavtika.com

#ay#

 

[dmdimon]

А если осталось только два блока? А если все 3 вразнобой? А если...

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

То есть внешний контроль я не отрицаю, но применимость его меньше.

Самотестирование блоков никто и не предлагает отменить, однако скажем так стандарт де-факто для высоконадежных систем - мажоритирование кратных блоков. Реализовано может быть по разному, вплоть до физического перетягивания на силовых приводах. И причины для этого как-бы есть.

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

Теоретически красиво - на первый взгляд. На практике требует связей порядка "каждый с каждым", надежность которых тоже надо обеспечить. И данные с них обработать.
Т.е. с точки зрения надежности такая система очень быстро провалится при росте количества блоков и датчиков, т.к. кол-во связей сидит на факториале кол-ва узлов. То-же касается обработки данных, входящих по всем этим каналам связи и уходящих по ним.
[automerge]1558348890[/automerge]

То есть получается PFD на эрбасе проверяли на ЭМИ при испытаниях, все было ОК,
НО от "глушилки" он виснет

Молния - снаружи, глушилка, небось, внутри. Спектр молнии - один, глушилки - совершенно иной.
[automerge]1558349065[/automerge]

Похоже, что проблема в концентраторе.

Непонятно пока, что там найдут, не будем торопиться.

 

[dmdimon]

насчёт несовершенства

Нормально летает, а совершенство в принципе недостижимо в реальном мире. Достижима лишь определенная вероятность безотказной работы.

 

[dmdimon]

Ну так примените и докажите. Пока что не вижу разницы на порядок.

Насчет "на порядок" я не писал. Доказательства этого рассматриваются в рамках курса "теория надежности" или как примеры в рамках курса "Теория вероятностей" в вузах соответствующего профиля.

Тогда мой вариант правилен - в нем есть и восстановление и вероятность избежать тройного отказа выше. А у вас после первого отказа - все, приплыли. Как 2 блока разошлись - так и тройной отказ.

скажем так. Я почти уверен, что накладные расходы в вашем варианте выше. Ваш вариант сильно поднимает обмен данными и их обработку. Почему в традиционном варианте "после первого отказа - все" и тройной отказ при расхождении ДВУХ блоков - я не понял.

Лишь дополняю стандартную схему сигналом "ой, у меня лажа". Ну и прием чужих решений.

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

На практике по AXFD эта связь "каждый с каждым" и так есть. То есть никаких лишних проводов, надо лишь обеспечить сравнение чужих решений со своими.

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

Я не про каждый с каждым (хотя на общей шине AXFD это и так есть), а про то, что каждый из 3х вычислителей должен принимать решения соседей.

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

 

[ads]

ads сказал:
Кто нибудь знает, проверяют так от воздействия ЭМИ бортовую электронику на "зависание"

Для обычной электроники - есть ГОСТ. Для бортовой - думаю, что тоже есть.
Ну вот один из таких ГОСТ.

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

 

[dmdimon]

Вероятность, что откажет только один блок 3*k*(1-K)*(1-k) = 0.243 = 24.3%
Вероятность, что откажут два блока 3*k*k*(1-K) = 0.027 = 2.7%

То-есть ваш расчет показывает, что вероятность двойного отказа примерно на порядок ниже, чем одинарного.

Таким образом, шанс полного отключения - 2.7%+0.1% - 2.8%

что примерно втрое ниже вероятности отказа одиночного блока, никаких откровений пока не вижу.

В моей схеме, в идеале - это только 0.1%

Вы забыли включить в расчет вероятность отказа вашей системы самодиагностики. Так что нет. По факту у вас блок состоит из двух компонент - расчетной и контроля состояния. Вот расчетной вы дали вероятность отказа 10%, давайте и контрольной тоже дадим 10%. Картинка сразу изменится.

все блоки читают сообщения друг друга

Вы собираетесь вещать "для всех" и на приемнике фильтровать, причем не на уровне контроллера интерфейса, а по содержимому?

Нет, не вырастет.

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

Не вполне понимаю, честно, зачем мы с вами спорим )

 

[dmdimon]

В 3.7 раза, то есть на полпорядка.

в смысле? двойной отказ - 24%, одинарный - 2,7, откуда в 3,7 раза?

Это просто программный код,

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

вероятность, что самодиагностика исправит ситуацию

Так самодиагностику никто и не отвергает.

Так что вещание всегда для всех, а фильтрация - на коммутаторе и контроллерах интерфейса.

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

Уж не означает ли это "между собой" и "между кабинетами", что я просто вычислил реальную схему?

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

 

[MMIC]

Да ничего сложно в зависании нету. Обычно используют WatchDog, то есть некий таймер, который, если досчитает до конца, вызывает перезапуск. Ну и программа периодически этот таймер взводит. Не взвела - опаньки, перезагрузка. Если этого мало - внешний контур watchdog на маленьком процессоре с низкой степенью интеграции. Если совсем мало - внешний watchdog на RC-цепочке. То есть конденсатор заряжается по командам процессора. Перестал процессор работать - разряжается. Разрядился до нуля - пошел рестарт.

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

Ну для самолета час - много, надо watchdogb c короткими временами делать. Но ничего сложного в этом нет.

Ну что Вы, сторожевой таймер (WatchDog) - это для разработчиков авионики слишком сложно, данными тайными знаниями обладаете только Вы!