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

K

Kit.

Старожил
А что мешает самолету возомнить себя терминатором и начать пикировать на Кремль Белый Дом?
По сути, только теория вероятности.

Нету этого в алгоритме.
Что-то я не ожидал услышать такое от программиста.
 
Реклама
K

Kit.

Старожил
Ну если чего-то в алгоритме нету - оно там не появится.
Во-первых, вы, строго говоря, не знаете что этого нету в алгоритме.

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

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

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

Короче, по-видимому, не ваше это.
 
D

dmdimon

Новичок
Будьте любезны, приведите пруф.
Вы правы, я неправ. Я неправомерно перенес на РТОС чужие определения )

Расскажите, как вы обеспечите синхронизацию допустим N идентичных блоков вот в этой красивой ситуации? чтобы они решения принимали одновременно?
Блок 1 принимает решения от блоков 2 и 3. Блок 1 ложно(!!!!) считает, что его решение совпадает с 2, но не совпадает с 3, при этом реально 2 и 3 совпадают, 1 отличается. Блок ложно выдает решение на отключение блока 3. Блоки 2 и 3 видят истинную картину (2 и 3 совпадают, 1 ложно) и отключают блок 1.
Выбирается с запасом в 4-10 раз и более
Вот Григорий Васильевич Кисунько об этом не знал... Разбаловались программисты. Факт.
 
Последнее редактирование:
K

Kit.

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

Как же это не учитываю?
Извините, не дочитал.

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

Точнее - не ваше, раз в простых алгоритмах не разбираетесь. Моя система - 15 лет 365 на 24 без видимых снаружи сбоев. То есть все сбои, что были, она верно отработала и исправила. А что они были - я по логам вижу.
То есть всего-то 1e5 часов? А чем были вызваны сбои? А чем ваш код управлял?

Так что извините - я практик. Мои идеи подтверждены опытом. А ваши?
Да вот только вчера нашёл очередной баг в ASIL D коде. Хотя, казалось бы...
 
D

dmdimon

Новичок
Давайте начнём сначала: кто обеспечивает то, что неверный результат, выданный блоком, не доходит до потребителя? Раз уж он доходит до других блоков.
Это возможно - с потерей тактов. Т.е. сначала результаты - в буфер, потом - сравнение и мажоритирование блоков, потом авторизованные блоки результат из буфера - потребителю. Предполагая абсолютную надежность буфера и запас по быстродействию в четыре-десять раз ) ну и отсутствие ситуации, о которой вы упомянули
Вы опять же не учитываете отказ, при котором блок себя не отключает.
потому, что возможен отказ, когда вот это
Если блок выдал неверный результат и не отключил себя - его отключат другие блоки.
не сработает или сработает ложно. Блин, получается путано, количество букв растет... Короче, если блок отключает сам себя - он может не отключиться, если блок отключает соседа - он точно так-же может не отключить его или ложно отключить. При этом возникнет паритет между рабочими и нерабочими блоками, если их три. А три - это, в общем-то, стандарт.

А в чем проблема?
в расхождении таймеров блоков

Я понял, почему у нас возникают разногласия. Вы рассматриваете системы с большим запасом по вычислительным (и, как следствие, временным) ресурсам, я - наоборот.
 
Последнее редактирование:
D

dmdimon

Новичок
сейчас - понятия не имею. Я уже 25 лет как другим совершенно занимаюсь.
 
Sergey-nn

Sergey-nn

Местный
КМК Молния и есть результат взаимодействия разных потенциалов и внутри плазменного канала течет именно ток. Так что все через что проходит разряд - все это пропускает ток. Самолет, как кусок железа, прекрасно проводит ток, а самому току куда сподручнее пройти по корпусу, чем лезть в радиостанцию через антенну. Но приборы на борту могут быть выведены не прямым током молнии, а наведенным ею электромагнитным импульсом. Думаю для тех кто не сильно вникал в школе в эти разделы физики (не вас конкретно имею в виду, а вообще обычных обывателей) эти два воздействия необходимо разделять. Кузмича в чистом поле убивает ток, а его Айфон в его руке наведенный импульс.
Извините что отвечаю с большим опозданием - возможно уже ответили до меня. Но "пусть будет"
Самая распространенная ошибка люде молнией особо не интересовавшихся считать, что молния подобна уколу иголкой или на худой конец удару копья. Здесь вошла - там вышла.
Однако молния - весьма широкий плазменный канал, который может достигать в толщину десятки метров. Если посмотреть на снимки грозы, и попытаться прикинуть пропорции, то это можно увидеть.
Связана такая особенность с тем, что даже сильно ионизированный воздух обладает ограниченной проводимостью, а токи очень велики.
Таким образом молния бьёт не только в корпус самолёта, а еще и во все элементы попавшие в толщину ее разряда (плазменного канала). А диаметр плазменного канала определяется только силой разряда. К тому же ионизация, и ток присутствуют не только в самом плазменном канале, а и вокруг него.
Однако если от наведенных воздействий, и даже от "боковых" токов защититься можно, то прямой удар молнии - задача та еще. К примеру попадание молнии в телевизионную антенну приводит к полному выгоранию антенного кабеля. Совсем полному. В труху. Вместе со всеми оплётками.
 
Последнее редактирование:
D

dmdimon

Новичок
Думаю, что даже сейчас по 9 приемке это где-то на уровне между 150 и 90 нм, если мы говорим о интеграции уровня процессоров. По комплексу причин.Ну и от скорости протекания контролируемых процессов зависит, хватает или нет. Точно знаю, что даже сейчас приходится применять каскадирование кое-где, так что ваш допуск на значительный резерв вычислительных мощностей актуален не везде. Пруф не дам )
 
K

Kit.

Старожил
Гм, что вы называете "сбоем" и в чем критичность? Я вижу такие варианты:
- отказ таймера вызывает отказ блока (если нет резерва)
- нестабильность таймера - корректируется, чуть выше описал.
Речь шла о том, что результатом какого-то сбоя является искажение и принятого сигнала, и представления модуля о текущем времени (или даже искажение представления модуля о текущем времени приводит к неправильной интерпретации сигнала), в результате 2 пакета посылаются сразу друг за другом, а не с секундной задержкой, как ожидалось.

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

То есть наши 15 лет - это 50-60 лет полета самолета.
В смысле, 15 лет полёта трёх-четырёх самолётов?

Сбои - в основном программные, я умудрился защититься от ненайденных собственных багов. Мой код ничем не управлял - это такой черный ящик, который обеспечивал запись всех переключений управляющих контроллеров.
Ааа... код чёрного ящика у нас в ASIL QM, поскольку на скорость не влияет сам по себе ущерба ни здоровью, ни собственности не наносит.

Их надежность изначально была сильно ниже (час простоя в месяц),
Тоже показатель.
 
Реклама
D

dmdimon

Новичок
Последнее редактирование:
D

dmdimon

Новичок
см. выше, поправил. Цен там нет, по вашей ссылке - отк1, как я и написал.
 
N

nowhow

Местный
Про отладку самолета и закомментированный код в FADEC читали?
Вы упорно тащите ссылку на рассказ, который прошел через 3-4 итерации интерпретаций. Код никто не видел, так что говорить о чужих багах преждевременно. Рассказывайте о своих). Самое простое объяснение, почему изменился алгоритм - разработчику выдали такое задание.
 
Элерон хвоста

Элерон хвоста

Новичок
Вы упорно тащите ссылку на рассказ, который прошел через 3-4 итерации интерпретаций. Код никто не видел, так что говорить о чужих багах преждевременно. Рассказывайте о своих).
Мне что, цитаты из библии приводить надо, чтобы вы поняли, что такое "притча"? Или, как для детсадовцев, написать, какую мораль я имею ввиду?

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

Причиной нештатного полёта ракеты-носителя «Протон-М» явилось превышение массы разгонного блока ДМ-03 вследствие конструкторской ошибки в формуле расчета дозы заправки жидкого кислорода в инструкции по эксплуатации системы контроля заправки (разработчик системы ОАО «РКК «Энергия»).

Это вот ровно "разработчику выдали такое задание". Вот только задание, отличное от документации - это тоже баг.

Рассказывайте о своих).
Свои - это какие? Те, которые нашел или те, которые сделал? Ну вот последний (вчера исправление получили) найденный чужой - ровно как в FADEC, в сентябре закомментарили строчку в конфиге, в итоге 3 недели убеждали разработчика, что у него не работает. Убедили. Устраивает? Подробней не буду - не хочу портить репутацию. Но прибор вполне космический.

Мораль (раз уж нужно писать мораль) простая - все меры сертификации не спасают от дурацких ошибок. Они лишь уменьшают их вероятность.
 
Элерон хвоста

Элерон хвоста

Новичок
Речь шла о том, что результатом какого-то сбоя является искажение и принятого сигнала, и представления модуля о текущем времени (или даже искажение представления модуля о текущем времени приводит к неправильной интерпретации сигнала), в результате 2 пакета посылаются сразу друг за другом, а не с секундной задержкой, как ожидалось.
Гм, у меня была миллисекундная задержка. И перепосылка со стороны датчика, а не блока расчета.

Ну крайне маловероятно это, на мой взгляд. То есть вы исходите из того, это ЭМИ повредило датчик. А я исхожу из других предпосылок - ЭМИ вызывает срабатывание защиты, защита вызывает искажение сигнала, передаваемого по линиям связи.Не помню точной терминологии ГОСТ, но там есть несколько "классов" защит. Самая лучшая - не мешающая работе, чуть хуже - мешающая работе только на время ЭМИ, ещё хуже - сбой до перезагрузки, самая худшая - изделие переносит ЭМИ лишь в выключенном состоянии.

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

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

---------- Добавлено ----------

КТ-178 и ГОСТ 51904 с вами не согласны.
Знаете, уголовный кодекс не запрещает убийства. Он лишь устанавливает за них цену. Вот так и ГОСТ - он ничего не запрещает, лишь намекает, что при нарушениях возможно посадят.

---------- Добавлено ----------

КТ-178 и ГОСТ 51904 с вами не согласны.
ГОСТ - СКАЗОЧНЫЙ. Цитаты

3.10 заплата: Исправление, вносимое непосредственно в объектную программу, а не в текст, на языке программирования.

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


Мда... Последний раз в жизни я делал заплату в 1991 году. Ну просто много заплатили за внесение в чужой бинарный код нужной заказчику функции. И уже тогда заплаты были анахронизмом.
 
Последнее редактирование:
Sergey-nn

Sergey-nn

Местный
КТ-178 и ГОСТ 51904 с вами не согласны.
Такишо, найдены способы божественного озарения написания программ вообще не содержащих ошибок. Даже ошибок а ТЗ?

Я скромно молчу, что тестов которые гарантируют 100% проверку не существует по определению.
 
S

SDA

Старожил
Sergey-nn, от ошибок в ТЗ указаные мной документы не защищают никак. Здесь другая наука нужна -- генетика ;)
 
Элерон хвоста

Элерон хвоста

Новичок
  • Спасибо
Reactions: SDA
Реклама
K

Kit.

Старожил
Ну крайне маловероятно это, на мой взгляд.
То есть вот это, например, на ваш взгляд, "крайне маловероятно"?

То есть вы исходите из того, это ЭМИ повредило датчик.
Нет, я исхожу из того, что любая подсистема, в том числе подсистема защиты, имеет свои собственные failure modes, а определение списка failure modes системы по failure modes её компонентов - это задача экспоненциальной сложности даже для абсолютных эрудитов.

И что даже подсистема, впихнутая с единственной целью борьбы с ЭМИ, вполне может иметь ложноположительные срабатывания (опять же, c причинами экспоненциальной сложности), и надо следить за тем, чтобы такие срабатывания не вывели из строя систему в целом.

А получатель в этом случае получает уже практически готовое решение. Точнее 3 решения, которых надо лишь сложить. А в вашем случае - ещё и оценит на достоверность по, возможно, сложным алгоритмам.
Я не вижу, чем мажоритарный контроль по значениям сложнее мажоритарного контроля по "посылкам контроля". И в любом случае это проще (а главное - надёжнее) решения, требующего обмена информацией между источниками.

И главное - при оценке потребителями, одни потребители могут принять одно решение, другие - другое. В итоге - потеряем консистентность.
Если консистентность требуется - то вы фактически описываете отказ потребителя. Да, потребители тоже могут отказывать по своим внутренним причинам, и не соответствующая спецификации реализация мажоритарного контроля входов (при наличии нормально поставленного тестирования) - далеко не главная причина. Для вас это новость?
 
Последнее редактирование: