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

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

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

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

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

Спасибо.

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

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

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

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

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

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

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

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

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



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

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

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

Читайте на тему https://en.wikipedia.org/wiki/Lockstep_(computing)
Такие решения есть у всех серьезных производителей:
Freescale - Qorivva
TI - TMS570
Infineon - AURIX

Но по логике сначала надо доказать необходимость "постоянного тестирования как аппаратной, так и программной части в фоновом режиме"
для этого анализируют риски. Можно проводить анализ по аналогии с другими отраслями - https://en.wikipedia.org/wiki/Automotive_Sa...Integrity_Level

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

Спасибо за ссылки. Как раз именно это хотелось увидеть.
Да, придется переосмыслить подход.

Это, мягко говоря, неправда.
А говоря прямо, это откровенное враньё.
На самом деле НИКТО из "серьёзных производителей" процессоров НИКОГДА не заморачивается поддержкой фонового софтваре run-time тестирования потока исполнения. НИКТО не задумывался НИКОГДА о том, что какая-нибудь случайно залетевшая альфа-частица может изменить значение регистра IP и программа можете улететь неизвестно куда.

Более того.
Не один из производителей компиляторов об этом тоже НИКОГДА не задумывался

Вот ведь козлы! Чтоже делать-то теперь, дядь Мить ?



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

Таки именно "пионеры".
У меня есть знакомые, участвовавшие в проекте.
И говорят, что проект "отдали на откуп" "молодым да ранним/перспективным".
Ну и они сказали: "Вы старичьё! Не фейхуа не понимаете в современной разработке. Вы все сделаем по своему"

Но и обосрались по полной.

Дублирование/троирование тоже нужно ведь делать с умом.
А то ведь можно не улучшить, а напротив, ухудшить надежность системы

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

jcxz
Вы зря иронизируете. Я сам лично наблюдал как программа улетала в никуда из-за "трыканья" пьезожигалкой для газовых плит рядом с процем.
Я спецциально забил флеш процессора специальными тестовыми кусками на которые программа не может попасть НИКОГДА в нормальном режиме работы.
И может попасть только в случае если "пролетающая альфа-частица" изменит IP (счетчик команд).
И IP менялся. Случайным образом из-за "трыканья" пьезозажигалки

К чему это я?
А к тому, что существует ненулевая вероятность что проц "слетит со своей орбиты".
Поэтому в микропроцессорных системах с ЭКСТРЕМАЛЬНО высокими требованиями к надежности нужно предпринимать меры, чтобы этого вовремя обнаружить и предпринять соответствующие меры

Т.е. нужно контролировать, что проц не сошел со штатной вычислительной траектории

счетчик команд вроде PC называется (program counter)

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

вот и надо уменьшать эту вероятность как только возможно

Дублирование, троирование, пятирирование....А может вообще штук 100 МК поставить на плату и пусть следят друг за другом? ВОТ


На заре моей туманной юности он назывался IP.
От слова "Instruction Pointer"

Да хоть миллионирование!
Это абсолютно не уменьшит вероятность "схода с орбиты" первого МК.

Зато это позволит вовремя это обнаружить и избежать нехороших последствий.
Вы вообще в теме?
Слышали как работает троирование?
В своих проектах юсали?

Нет. Не юсал. Не было такой необходимости.
Расскажите про троирование.

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

О, теперь понятно.


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

На следующем же такте

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

Если все эти МК будут разведены так же, как и тот, который сходит с ума от зажигалки, то это просто приведёт к "Дублирование, троирование, пятирирование...." количества этих сбоев.
Лечить надо проблему (кривую разводку платы и её разработчика), а не придумывать кривые костыли и подпорки.


Существует ненулевая вероятность, что в ваш счётчик команд попадёт пучок позитронов и он аннигилирует.
Как планируете защищаться от этого??

Троирование рудид