Отказоустойчивость ПО

[kison]

но если частично повреждена область памяти где нах-ся подпрограмма расчета CRC?

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

[testerplus]

Тогда где хранить CRC и как проверить её достоверность?

Хранится чаще всего либо в ROM вместе с кодом (если вычисляется на этапе компиляции), либо в EEPROM, если вычисляется в ходе работы. Иногда при вычислении в рантайме - пишется во Flash, но операция небезопасная, требует разных защит.

Достоверность проверяется пересчетом. Если не сходится - значит недостоверна. Часто в ответственных системах держат несколько ЦРЦ для различных участков кода.

CRC нужно посчитать, но если частично повреждена область памяти где нах-ся подпрограмма расчета CRC? Получается на каждого "проверяльщика" нужен свой "проверяльщик".

Насчет повреждения программы расчета: почему-то часто этот аргумент выдвигают в пользу вообще его не проверять ROM. Типа, фиг ли, если сбой там?

Но во-первых, например, на 64К кода нужен проверяльщик, скажем, размером 0.5К, т.е. область уязвимости сужается более чем в 100 раз. Во-вторых, сами проверяльщики пишутся с особыми требованиями (контроль стека, контроль сигнатур и пр.) и являются гораздо более устойчивыми к сбоям. Наконец в-третьих, и в самом проверяльщике не в любом месте сбой приведет к фатальным последствиям. Т.е. вероятность страшного сбоя, например в адресе команды GOTO, не так велика по отношению ко всем остальным вероятностям, вроде сбоя поля данных или арифметической инструкции. Но она не нулевая. Абсолютной защиты в 100% не будет, но снизить вероятность отказа с 10^-6 до 10^-8 - это хорошо.

[testerplus]

Сложнее с выбором действий после получения битой CRC ROM...

В системах с повышенными требованиями по отказоустойчивости следует хранить минимум две копии подпрограммы безопасного режима и держать ЦРЦ для каждой из них. (причем размещать и надо в разных фрагментах ROM)

[testerplus]

Проверяется вся память вместе с загрузчиком. Проверяет сам загрузчик, так что гарантия не 100%. Это рассчитано не на сбой в памяти, а в основном контроль работы загрузчика.

100% никогда не достигнем
А как же с data retention быть? Да и при работе бутлоадера могут сбои быть (сбои бутлоадера - вообще отдельная тема, там на несколько страниц писанины получится)

Я думал извне это UART/SPI/I2C и т.п. Кстати и они оказывается не всегда проверяются - например время из RTC читаю как есть и понятия не имею как его проверить.

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

[kison]

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

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

[realid]

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

А почему бы и нет?

[kison]

Обычно RTC содержат облать RAM общего назначения. тут после установки времени прописывается сигнатура (чем длиннее, тем лучше), которая каждый раз при чтении времени проверяется.

Не все RTC содержат. Но вот некоторые... Я очень хорошо знаю непредсказуемость суждения о правильном времени по состоянию ОЗУ. В DS1302/1307. Если записать данные в ОЗУ, затем просадить батарейное питание до 1,0-1,2В, естественно сняв основное, то после подачи питания время собьется, а содержимое ОЗУ - нет. Я это проверял неоднократно.

[testerplus]

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

Кстати, так и делается . Называется аппаратное резервирование (троирование). Часто делается с мажоритарным сравнением.

А почему ядерный реактор? Есть более простые устройства, например у стиральной машины есть блокировка дверцы во время стирки. И по 60730 (американский аналог для бытовухи UL1998 ) такие устройства должны выполнять функцию проверки памяти. Хотя, я знаю, некоторые просто выдают "1" на выходе и несложная схема переводит девайс в безопасный режим (блокирует всякие ответственные узлы и мигает лампочкой). Т.е. вся программа безопасного режима - выдать единичку и зациклиться.

[testerplus]

Не все RTC содержат. Но вот некоторые... Я очень хорошо знаю непредсказуемость суждения о правильном времени по состоянию ОЗУ.

Это слабое место всех RTC (да и вообще любой ОЗУ). Остается только внутри программы сравнивать времена. Некоторые часы имеют бит контроля батарейки (не совсем необычный триггер, там что-то другое), поищу, у меня было описание такой микросхемы. Т.е. если бит рухнул, то нельзя говорить о достоверности, а по сигнатуре хотя бы можно судить, что была предустановка времени.

[kison]

А почему ядерный реактор? Есть более простые устройства, например у стиральной машины есть блокировка дверцы во время стирки.

Я вообще не понимаю как это работает После окончания стирки дверь разблокируется не сразу, причем не зависимо от питания. Можно выдернуть стиралку из розетки, но все равно придется ждать. Разбирать не хочется, да и жена не поймет..