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

Подскажите, пожалуйста, литературу или ссылки по данной тематике. UART можно проверить путем приема/передачи соответствующих сообщений, код во флэши можно проверить, сравнивая контрольные суммы страниц, ... Хотелось бы подробнее узнать о дополнительных проверках и, возможно, лучших решениях их осуществления. Прочитал про Power-on self-test (POST). С этим более менее понятно, а вот как эффективно проводить мониторинг именно работающей программы, не нарушая временные диаграммы, пока не очень ясно.

Кое-кто делает троированные системы.

Спасибо, читаю. Вещь сУрьезная.
Видимо, на одном MCU нормальную систему не сделать при заданных степени контроля и надежности.

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

Спасибо.

Когда-то делали устройство на 8080, наставили самодиагностики, и контрольная сумма ПЗУ, и контрольная сумма ОЗУ, и тестирование последовательных интерфейсов.
В результате самодиагностика отказывала чаще основных узлов.

Ценное замечание, подкрепленное непосредственным опытом. Да, как-то не задумывался над этим вопрос. Действительно, очень и очень вероятно подобное.

А вы уже определились, с какими повреждениями собираетесь бороться-то ?
А то, вот, например, прилетит высокоэнергетичная частица в триггер, выполнит bit flip, ну и процессор выполнит jz вместо jnz. Что будем делать ?

Если прилетит в ОЗУ или во флэш, то использовать другие их части. Что касается ASIC, то не использовать поврежденные каналы.
Ну, если процессор, то кранты. Вырубать нафиг модуль Пока как-то так.

Вы не поняли.
проц, флеш и/или озу вполне рабочие , речь о том что во время дешифрации команды (из за пролетающей частицы) процессор выполнит не верное действие!
Что делать? кого и как вырубать?

Вот, вспомнил. У НЕК в памяти команд был сделан внутренний контроль четности...
А у TI есть процессоры с троированием прямо на кристалле...
А вообще, прежде чем брать "что подешевле", лучше выбрать производителя который в большинстве продукции нацелен на автомобильный рынок. Т.к. там поголовная проверка, а не выборочная, как для ширпотреба...
Ребята из ADI на семинаре рассказывали, что если есть брак на коммерческой "вафле", то выкидывается только один бракованный чип. А если на "автомобильной", то кроме бракованного выкидываются еще чипы, которые к нему примыкают. Чтобы получить НУЛЕВОЙ брак в автомобильных исполнениях...

например перейти на ARM Cortex-R4, вроде как, ядро как раз заточено для задач, в которых требуется повышенная надежность и отказоустойчивость исполнения кода, типа вдруг 1+1 = 3. например от Тексаса.
это помимо наличия всяческих корректоров ошибок памяти и тактирования.

Сообщение отредактировал bloody-wolf - Dec 12 2015, 23:20

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

Лучше использовать троирование. Пятирирование и т.п. Чем заморачиваться с софтом. Это будет гораздо проще. Да и дешевле. Сейчас микроконтроллеры стоят копейки. Можно в одну плату хоть 20 штук их напихать



А так я тоже по молодости извращался с "самотестированием" в Run-Time.
Вплоть до того что контролировал что проц прошел все точки вычислительной траектории и контролировал длительность выполнения отдельных участков кода. К примеру если проц выполнил участок кода не за 100 мкС, а за 50 или 150, то фиксировался сбой, "вызванный залетевшей в проц альфа-частицей"©.

Но все эти извращения требуют расчетов времени выполнения участков кода и работать чисто на ассемблере.
Ни о каком Си и тем более С++ и речи не было.

Сообщение отредактировал Флюктуация ваккума - Dec 13 2015, 07:39

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