Ну мы просто совсем о разных вещах говорим. Человек написал про диаметр канала в десяток метров, я вспомнил про давление ударной волны в мегапаскаль, и понял что долбани такая в кремль, в пределах ТТК ни выживших, ни уцелевших зданий не осталось бы. О чем и написал.а именно короткий фронт вызывает сильное магнитное поле, которое в свою очередь наводит токи в любых контурах.
Но, как правило, обратимо.Ну так он сильней молнии электронику губит.
Я думаю, вы не понимаете, как уменьшать количество потенциальных багов в большом проекте. Да и в багах, связанных конкретно со временем, имеете немного опыта.Читаем по вашей ссылке: 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 каждую микросекунду. как уменьшишь до конца - крякни".
Так не "должно" плохеть-то. От NTP не плохеет, от PTP не плохеет, от прямого stime()/settimeofday() не плохеет - а от leap second плохеет. Плохеет потому, что баги.Вся беда в том, что hrtimer основаны на "разбуди меня в 4:20". И если после 4:19:59 будет 4:19:60 или 4:20:01 - им с большой вероятностью поплохеет.
Да точно так же, как ваш.Ну и как ваш мажоритарный контроль на потребителе пойдет по двум вычислителям? Ну вот третий отключили, что дальше? Рулетка? А если один в ногу, а два - не в ногу?
Вы, кажется, говорили про помеху на шине?Контроль на вычислителях основан на том, что сами вычислители - ломаются редко, а вот датчики часто врут.
Конкретно в MCAS - не может. "Потребитель" (FCC) "вычисленного" (на ADIRU) значения угла атаки может отключить функцию MCAS, если значения с разных ADIRU разные. "Потребитель" функций FCC (пилот) может переключить управление на другой FCC, если считет, что этот неисправен.Вот простой пример - MCAS. У каждого вычислителя - свой датчик атаки и скорости. Как потребитель может понять, MCAS какого борта права, правого или левого? А вот вычислители, имея всю информацию со своих датчиков и результат соседа - могут дать решение "мои датчики врут, я работаю неверно" или "я прав, а датчики соседа врут".
Алгоритм либо указан в спецификации, либо разность в алгоритмах намеренна - на случай наличия ошибки в одном из них - и система проектируеся так, чтобы с ней справляться.Ну не совсем отказ, а разность алгоритмов.
Ну, собственно, от отладочной платы и не требуется такая тщательность тестирования, как для железки, от которой зависят жизни людей.Так что контроль может проскочить баг любого размера. Этой плате сильно повезло, что полгода её использовали именно в том режиме, в каком она изначально была работоспособна.
вот тут вы неправы. Внешний контроль лучше. Доверять контроль себя потенциально глючному блоку - совсем не айс, где гарантия, что не глючит и контроль тоже, если уж блок пошел вразнос?самому вычислителю намного проще понять, что не не прав,
Э-э? Есть мнение, что в частности пробой переходов плохо обратим.Но, как правило, обратимо.
Известно, что стабилитроны работают в режиме электрического пробоя.Э-э? Есть мнение, что в частности пробой переходов плохо обратим.
мой ответ был в контексте воздействия ЭМИ от ВМГ на электронику.Известно, что стабилитроны работают в режиме электрического пробоя.
Если не загонять в область теплового пробоя, то процесс весьма обратимый.
несовпадение вектора состояния блока с двумя другими как метод контроля более надежно, чем внутренний контроль блока. Чистый тервер. Внутренний контроль блока может и сам заглючить, не забывайте. Не забывайте также, что целевая задача - не поотключать все подозрительные блоки, а обеспечить наибольшую вероятность получения достоверных данных на (условно) железе, которое в сумме весит N кг и потребляет M ватт.Просто если блок решил что он сам не прав - достаточно его решения. А вот для внешнего контроля надо несовпадение нашего решения с двумя блоками.
То это - проблема датчиков и их системы контроля работоспособности. Что конечно не отменяет необходимость отключения такого блока - если контроль датчиков не справился.Если опирается на неверные данные с датчиков
Проблема в том, что у блока мало опоры, чтобы понять, верные данные он дает или нет. А если опоры достаточно - то что мешает ему исправиться в случае некритических проблем типа сбоя в передаче данных? Зачем отключать-то его, тем более если у вас запас в вычислительных мощностях 4-10 раз?блок ложно решил, что он дает неверные данные
Спасибо за уточнение, однако "довольно много каналов" раскиданных по площади в 100 кв м. с т.з. воздействия на выступающие части (в т.ч. антенны) ни чем не отличается от сплошного воздействия на всю площадь. Разве только тем, что при "сплошном канале" ток протекающий по антенному кабелю окажется в десятки (или сотни) раз слабее, чем при прямом попадании одного из каналов. А "боковые" воздействия будут полностью идентичны.По поводу толщины канала в десяток метров это Вы загнули однако. Обычно канал не один, их может быть довольно много,
Ну хотя бы нет задачи выдержать ударную волну на уровне ядерного оружия. Уже полегче однако...Спасибо за уточнение, однако "довольно много каналов" раскиданных по площади в 100 кв м. с т.з. воздействия на выступающие части (в т.ч. антенны) ни чем не отличается от сплошного воздействия на всю площадь. Разве только тем, что при "сплошном канале" ток протекающий по антенному кабелю окажется в десятки (или сотни) раз слабее, чем при прямом попадании одного из каналов. А "боковые" воздействия будут полностью идентичны.
Таким образом Ваше уточнение ни разу не облегчает построение систем грозозащиты...
Вы провели очень серьёзный разбор различных вариантов систем самотестирования, с упором на теоретические возможности различных вариантов построения.Ну вот как пример - MCAS. Блок видит расхождение датчика скорости и показаний инерциалки. И не понимает, что случилось:
Вот в этой ситуации решение со второго блока помогает понять, что же произошло.
- врет датчик скорости?
- врет инерциалка?
- врут оба?
- никто не врет, просто самолет в штопоре?
- баг в алгоритме?
Если уж приняли решение "блок работает только со своими датчиками", то хотя бы уж дайте блоку решение с дублера. И довольно много таких ситуаций.
.... Кстати ранее я писал про глушилку (маленькая молния), которую купил, инженеры пробовали на А, виснет индикация, восстанавливается после отключения питания и вновь включения.
..... вроде как современную электронику проверяют на устойчивость к ЭМИ маленькими молниями, пока не зависнет, скажите, для бортовой электронике тоже проверяют на "зависание" или всё же НЕ ПРОВЕРЯЮТ ????
Кто нибудь знает, проверяют так от воздействия ЭМИ бортовую электронику на "зависание"..... Единственное что я могу попробовать сделать, это задать ему интересующие вопросы, когда мы в следующий раз будем на связи.
Безусловно.Кто нибудь знает, проверяют так от воздействия ЭМИ бортовую электронику на "зависание"
То есть получается PFD на эрбасе проверяли на ЭМИ при испытаниях, все было ОК,Безусловно.
Это один из этапов испытаний, точно так же как и ЭМС.
Вопрос (как всегда) в корректности этих проверок. Методики то же люди пишут..
Вариантов много, но если применить тервер, то окажется, что они значительно менее вероятны. Я напомню, целевая задача - наибольшая вероятность безотказной работы при заданных ограничениях на конструкцию.А если осталось только два блока? А если все 3 вразнобой? А если...
Самотестирование блоков никто и не предлагает отменить, однако скажем так стандарт де-факто для высоконадежных систем - мажоритирование кратных блоков. Реализовано может быть по разному, вплоть до физического перетягивания на силовых приводах. И причины для этого как-бы есть.То есть внешний контроль я не отрицаю, но применимость его меньше.
Теоретически красиво - на первый взгляд. На практике требует связей порядка "каждый с каждым", надежность которых тоже надо обеспечить. И данные с них обработать.в этой ситуации решение со второго блока помогает понять, что же произошло.
Если уж приняли решение "блок работает только со своими датчиками", то хотя бы уж дайте блоку решение с дублера.
Молния - снаружи, глушилка, небось, внутри. Спектр молнии - один, глушилки - совершенно иной.То есть получается PFD на эрбасе проверяли на ЭМИ при испытаниях, все было ОК,
НО от "глушилки" он виснет
Непонятно пока, что там найдут, не будем торопиться.Похоже, что проблема в концентраторе.
Нормально летает, а совершенство в принципе недостижимо в реальном мире. Достижима лишь определенная вероятность безотказной работы.насчёт несовершенства
Насчет "на порядок" я не писал. Доказательства этого рассматриваются в рамках курса "теория надежности" или как примеры в рамках курса "Теория вероятностей" в вузах соответствующего профиля.Ну так примените и докажите. Пока что не вижу разницы на порядок.
скажем так. Я почти уверен, что накладные расходы в вашем варианте выше. Ваш вариант сильно поднимает обмен данными и их обработку. Почему в традиционном варианте "после первого отказа - все" и тройной отказ при расхождении ДВУХ блоков - я не понял.Тогда мой вариант правилен - в нем есть и восстановление и вероятность избежать тройного отказа выше. А у вас после первого отказа - все, приплыли. Как 2 блока разошлись - так и тройной отказ.
С сигналом "у меня лажа" в целом никто и не спорит - это самотестирование в той или иной форме. прием чужих решений - это внесение аппарата мажоритирования непосредственно в контролируемые блоки. ОБЫЧНО так не делается. Скажем так - я не знаю, где так сделано. Насколько мне известно, так НЕ делает НАСА в частности. У нас так вроде бы тоже не делают. Привожу такой аргумент, т.к. считать надежность вот прямо здесь и сейчас нереально.Лишь дополняю стандартную схему сигналом "ой, у меня лажа". Ну и прием чужих решений.
наличие проводов не очень принципиально. У шины есть надежность, которую можно выразить в вероятности верной передачи сообщения. Количество сообщений растет - растет и вероятность сбоя. То-есть количество связей все равно ведь растет, просто не на уровне проводки. К тому-же у шины есть пропускная способность, латентность, в конце-концов даже отключение на момент помехи при высокой плотности сообщений приведет к потере гораздо большего количества данных.На практике по AXFD эта связь "каждый с каждым" и так есть. То есть никаких лишних проводов, надо лишь обеспечить сравнение чужих решений со своими.
так это и есть - каждый с каждым же. Вот в этом случае поток данных вырастает вЯ не про каждый с каждым (хотя на общей шине AXFD это и так есть), а про то, что каждый из 3х вычислителей должен принимать решения соседей.
Понятно, всё красиво расписано, НО, про "зависание" что-то не увидел, и в Вашей проф. полемике тоже только про сбои.Для обычной электроники - есть ГОСТ. Для бортовой - думаю, что тоже есть.
Ну вот один из таких ГОСТ.
То-есть ваш расчет показывает, что вероятность двойного отказа примерно на порядок ниже, чем одинарного.Вероятность, что откажет только один блок 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%
Вы забыли включить в расчет вероятность отказа вашей системы самодиагностики. Так что нет. По факту у вас блок состоит из двух компонент - расчетной и контроля состояния. Вот расчетной вы дали вероятность отказа 10%, давайте и контрольной тоже дадим 10%. Картинка сразу изменится.В моей схеме, в идеале - это только 0.1%
Вы собираетесь вещать "для всех" и на приемнике фильтровать, причем не на уровне контроллера интерфейса, а по содержимому?все блоки читают сообщения друг друга
поток обрабатываемых вычислительными блоками данных вырастет однозначно, что при сохранении заявленного вычислительного резерва потребует увеличения вычислительной мощности, что приведет к снижению надежности блока. Либо вы сольете вычислительный резерв, что приведет к снижению надежности системы в целом.Нет, не вырастет.
в смысле? двойной отказ - 24%, одинарный - 2,7, откуда в 3,7 раза?В 3.7 раза, то есть на полпорядка.
Какая разница, реализован блок аппаратно или программно? у него есть надежность. Более того, если контроль крутится на том-же железе, что и основные расчеты - это вам готовая единая точка отказа для системы расчет плюс контроль.Это просто программный код,
Так самодиагностику никто и не отвергает.вероятность, что самодиагностика исправит ситуацию
Хм. ну ок, я отстал от жизни ) В принципе, в этом может быть изящество - данный льются от всех источников одного типа всем приемникам этого типа данных... Если быстродействие шины позволяет разруливать всё это, конечно.Так что вещание всегда для всех, а фильтрация - на коммутаторе и контроллерах интерфейса.
Ну тогда я не согласен с конструкторами, хотя - кто я такой?Уж не означает ли это "между собой" и "между кабинетами", что я просто вычислил реальную схему?
Ну что Вы, сторожевой таймер (WatchDog) - это для разработчиков авионики слишком сложно, данными тайными знаниями обладаете только Вы!Да ничего сложно в зависании нету. Обычно используют WatchDog, то есть некий таймер, который, если досчитает до конца, вызывает перезапуск. Ну и программа периодически этот таймер взводит. Не взвела - опаньки, перезагрузка. Если этого мало - внешний контур watchdog на маленьком процессоре с низкой степенью интеграции. Если совсем мало - внешний watchdog на RC-цепочке. То есть конденсатор заряжается по командам процессора. Перестал процессор работать - разряжается. Разрядился до нуля - пошел рестарт.
У коллеги, на гаишном фоторадаре его разработки, после удара молнии зависло все. Отресетилось само по третьему контуру с периодом в час. Ну да, час они переживали, что придется в Сибирь лететь, на месте прибор поднимать. Через час - прибор вошел в инет, и дальше настройка по удаленке. Собственно этот коллега наши платы и делает.
Ну для самолета час - много, надо watchdogb c короткими временами делать. Но ничего сложного в этом нет.