Самотестирование микроконтроллера в фоновом режиме Опции

[Grizzzly]

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

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

[Guest_TSerg_*]

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

[Grizzzly]

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

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

[iosifk]

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

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

[Grizzzly]

Вот это в общем виде...

Спасибо.

[Dog Pawlowa]

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

[Grizzzly]

В результате самодиагностика отказывала чаще основных узлов.

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

[CrimsonPig]

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

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

[Grizzzly]

А вы уже определились, с какими повреждениями собираетесь бороться-то ?

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

[zombi]

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

Если прилетит в ОЗУ или во флэш, то использовать другие их части.

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

[iosifk]

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

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

[bloody-wolf]

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

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

[Aner]

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

[Флюктуация вакку...]

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



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

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

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

[Ruslan1]

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

[AlexandrY]

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

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

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

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

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

[Grizzzly]

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

[Флюктуация вакку...]

Такие решения есть у всех серьезных производителей

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

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

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

[CrimsonPig]

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

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

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

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

[Флюктуация вакку...]

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

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

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

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

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

[jcxz]

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

[Флюктуация вакку...]

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

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

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

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

[zombi]

изменит IP (счетчик команд).

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

Поэтому в микропроцессорных системах с ЭКСТРЕМАЛЬНО высокими требованиями к надежности нужно предпринимать меры

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

[zombi]

существует ненулевая вероятность что проц "слетит со своей орбиты".

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

[Флюктуация вакку...]

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

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

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

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

[zombi]

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

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

[Флюктуация вакку...]

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

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

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

[zombi]

Вы вообще в теме?
Слышали как работает троирование?
В своих проектах юсали?

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

[Флюктуация вакку...]

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

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

[zombi]

Троирование - это вид резервирования.

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

Зато это позволит вовремя это обнаружить и избежать нехороших последствий.

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

[Флюктуация вакку...]

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

[zombi]

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

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

[jcxz]

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

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

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

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

[Флюктуация вакку...]

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

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