Я так понимаю, что речь идет не о том, что устройство должно при обнаружении отказа продолжать нормально работать, а, скорее, лучше пусть отрубается совсем, или выдает error на ножку, которая, в свою очередь, отрубит например силовое питание клапанов или движков. Как-то так. То есть не "делай во чтобы то ни стало" а "не можешь делать - лучше отрубись". Не знаю как это по ГОСТ звучит =)

+1. Если ты не Боинг, или, на худой конец, НАСА - они тебя просто не замечают. С дистрибуцией была таже фигня.

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

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

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

Вообще многие приблуды Hercules ориентированы на снижение рисков в процессе разработки, а не в процессе эксплуатации.
Соответственно гаражным разработчикам будут непонятны и неприемлемы.

Вы сферического коня в вакууме обсуждаете, впрочем как и я. По Вашей логике - стоп-краны в поездах не нужны, кнопки Стоп красные на механизмах - это только для гаражей. Лучше скажите, что делает Техас при обнаружении fault на одном из ядер ? Если передает управление другому, то какие вопросы ? Это именно мера повышения надежности в процессе эксплуатации. Причем в случае , допустим, станка - лучше и остановить процесс по возможности. В случае стимулятора - работать на другом, выбора нет. Всем понятно, что надо проектировать девайса так, чтобы (длинный список ляляля, удовлетворить который, надо полагать, могут только процессоры от одного известного производителя в комплекте с софтом от него же + полная смена разработчиков на кошерных) Причем тут разработка вообще неясно - второе ядро как датчик ЕМС что-ли работает ? Мажорирование ячеек в радиационно-стойких ПЛИС Актеля - тоже для комфорта разработчиков ?

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




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

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

Так вот, в этом случае можно сделать этот вентиль на одном микроконтроллере и 2-х последовательных вентилях (а не какая нибудь троированная система). Процедура открытия будет состоять из трех фаз. 1- открытие перового вентеля, 2- диагностика системы и 3 фаза - открытие второго вентиля. Таким образом при нормальной работе без сбоев оба вентиля откроются, и функция выполнена правильно. При сбое, PC шагнул на команды открытия первого вентиля не регламентировано, например. То первый вентель откроется, но на этапе диагностики сбой будет обнаружен и второй вентиль не откроется. А у системы будет внутренний сигнал ошибки. Обычно в этом случае самолет уже сажают на ближайший. Если в результате сбоя шагнули на открытие второго вентиля, и открыли его - то первый вентиль закрыт, опять таки аварии не устроим.
Так вот локстеп позволяет сократить время диагностики до единиц тактов, вместо более сложный процедур самодиагностики
и подтверждения на более высоком уровне. Кроме того самодиагностика позволяет обнаружить отказы, а сбои она не показывает. А интенсивность сбоев примерно в 1000 раз больше чем интенсивность отказов на земле.

Эээ.. но различные контроли ECC - не позволяет определить кто сбойнул ? Хотя вообще мне это сильно напоминает историю а ватчдоге - вечный спор - нужен он или нет.

На схеме их инвертора выход ошибки идет сразу на сброс и никаких там самодиагностик.
Самодиагностика там отдельная тема.

Lock-step, ИМХО, не мера повышения надежности, а средство идентификации места возникновения ошибки (CPU или шина например ).
Благодаря этому в частности TI могут определить уровень SIL системы куда входит контроллер и прикинуть риски.

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

А сценарий с вентилем мне кажется надуманным.

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

"Есть работы где обычная схемотехника защищается ECC" - перл!

http://www.cs.york.ac.uk/rts/docs/DAC-1964...FILES/P0705.PDF

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

впринцыпе можно сгенерить коды для сумматоров и умножителей (АЛУ), я про это не слышал, ну и скажем так - я не академический деятель, а практикующий инженер, да и эта тематика не такая открытая, как ARM архитектура

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