Redundancy Management (RM) System

[i-mir]

С точки зрения надежности, дублирование исполнительного механизма
вполне достаточно для большинства приложений
(проекты на космос делаются с 5х резервированием).
Если в цифрах, то сбой контроллера планируем 10Е-6.

4MasterMushi:
Для трех контроллеров ваша идея подходит, когда определяется один "враг". Для схем с большим количеством контроллеров - такой подход мне кажется потенциально опасным (возможность зависания всей системы при рассинхронизации). Опыт американских
коллег (Space Shuttle) говорит об этом (у них один контроллер при старте подвесил всю систему из-за сбоя внутренних часов - остальные четыре контроллера ждали пятого, когда он засинхронизируется).

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

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

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

На счет варианта последнего контроллера, который доводит "самолет/пароход/поезд/химию/газ" на "полосу/причал/вокзал/емкость/Украину" - был такой вариант на Буране - если осталось "в живых" только два, и при этом они начинали расходится во мнениях - тогда наугад вырубали питание одному - и с вероятностью 50% Буран долетал до аэродрома. Случай, надо сказать эксклюзивный, но !!! имеет право на существование.

[alexgap]

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

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

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

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

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

[alexgap]

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

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

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

[alexgap]

Но тут одна тонкость, если два начнут говорить одно, а два других другое - то будет коллизия.

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

[i-mir]

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

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

Но лучше использовать для "4-х мозгов" отдельные каналы связи каждый-с-каждым. Тогда в случае временных коллизий целостность данных сохраняется и надежность повышается.

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

PS. Есть еще люди, знающие как сделать фототранзистор из МП39Б с помощью напильника.

[alexgap]

Но лучше использовать для "4-х мозгов" отдельные каналы связи каждый-с-каждым. Тогда в случае временных коллизий целостность данных сохраняется и надежность повышается.

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

Есть еще люди, знающие как сделать фототранзистор из МП39Б с помощью напильника.

С помощью кусачек получается намного быстрее Шляпка "снимается" за секунды.

[MasterMushi]

i-mir, Для этого и есть в моей схеме регистр готовности. Никто никого не ждет. В работу пускаются только те контроллеры которые подтвердили делом свою готовность. Синхронизация происходит только между источником данных и контроллерами.
Только новый, который вставлен в слот ждет пуска и пакета ОЗУ от живого соседа. Остальные работают сами по себе. Ожидание пуска как раз и надо именно для того чтобы потом быть в плавающем такте приближенном к соседним контроллерам.

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

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

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

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

Но и тут есть подводный камень - вышли из строя 3 из 4 причем так что контрольные задачи решаются но входящие данные обрабатываются неверно. Из-за этого любой верный ответ от рабочего контроллера ими будет понят как неверный. Вот тут и "Ценный пушной зверь с синим мехом" всему.

Хотя по сути - пятая плата активизирующаяся по watchdog таймеру ой как не помешала бы ))))

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

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

--------------------------
Еще одна мысль по тестированию - одну из 4х плат назначать ответственной за тесты остальных. Пока остальные занимаются обработкой пакета данных, эта плата ставит задачу. Как только остальные справились с данными и решили задачу, ответственная за тестирование плата меняется.
Если остается 2 платы и по результатам тестов та плата, которая тестировала, забраковала вторую. То последняя плата считается перманентно актуальной.

alexgap, Кусачки убирают боковую юбку. А она служит защитой для кристалла!

[i-mir]

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

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

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


PS. Вижу тема фототранзистора до сих пор актуальна из-за отсутствия налаженной процедуры изготовления !!! Следует отметить что эта технология всегда держалась в секрете профессионалами .....

[MasterMushi]

i-mir,
По поводу "Ведущего" я имел в ввиду плату с которой обработанные данные считаются актуальными.

Так, хорошо. Идем в одноранг.

- Средства само тестирования ставим на каждой плате свои отдельные.

- Данные обрабатываем пакетом. В два прохода по исходным данным. Чтобы исключить ошибку вычисления

- На каждой плате ставим два контроллера разной архитектуры.
После обработки данных сравнивается результат и только потом выдается принятое решение.

- Ответственность за верную обработку возлагаем на сами же платы. Двойной проход по исходным данным со сравнением результата.

- Решение считается принятым как только одна из плат завершила обработку (первый успел значит прав)

- После принятия решения ВСЕ платы получают новый пакет данных.

И все по новой
получить пакет, два раза прогнать по двум процессорам, сравнить результат, выдать результат наружу или совершить действие.


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

[i-mir]

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

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

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

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