Иммитация отказов., Кто как чем далает? Опции

[MegaVolt]

День добрый.

Подскажите кто как делает имитацию отказов для системы в PC - ПЛИС(проц+ периферия).
Например система не должна виснуть при отказе датчика телеметрии повешенного на I2C.

Один из путей через JTAG лазить переключать пины и прочие шалости творить. Есть ли у кого ещё какие то решения.

Что хотелось бы:
1. В идеале близкое к нулевым вмешательство в софт и железо. Например некий отдельный модуль который работает параллельно остальной системе который можно легко добавить или удалить из проекта.
2. Некоторая универсальность в порче чего бы то ни было.

Вообщем подскажите кто как делает.

[MegaVolt]

Господа. Имитация отказов, и тестирование на устойчивость к мощным помехам, это две большие разницы.... Тема про имитацию отказов.

[a123-flex]

Господа. Имитация отказов, и тестирование на устойчивость к мощным помехам, это две большие разницы.... Тема про имитацию отказов.

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

Если Вам так не нравится, тогда курите слово верификация и coverage из ПЛИС- и чипостроения. Смысл в том что в системе, покрытой тестами, ПО анализирует количество покрытого тестами кода, и ищет код непокрытый. Для этого правда нужно чтобы система была полностью HDL-ная.

В конечном итоге, пройдясь по всем этим мегагаграблям, вы и сами прийдете к мысли, что Вам нужно писать тесты для узлов Вашей системы(AVR ). Незамысловатые, в случае сдачи по ТУ, или с полным покрытием, если Вы собрались на Вашем устройстве лететь в космос, и это узел управления разгонным блоком "Бриз-М": судя по количеству проблем, coverage для него точно не делали)).

Единственное чего не знаю, как сделать анализ покрытия тестом программного продукта. Здесь полагаю, есть 2 пути: если в коде нет ОС, думаю возможно строить граф алгоритма, и исходя из него строить тест. Если есть, сливать воду и читать сертификаты)

А если все это фантазии заказчика - делайте имитатор бурной деятельности)

ЗЫ. По тестированию ПО много писал яндекс на хабре, о своем софте для больших машин, и в конфе была тема по автоматизации тестирования системы с микроконтроллером.

Вот крутаны

Вот тестирование РЛС Agilent

[MegaVolt]

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

Всё же есть нюанс. Задача не добиться сбоя любыми средствами. Само собой что всегда найдётся мощность выше которой устройство будет сбоить. Задача убедиться что ядро устройства продолжает жить пока отваливается периферия.

Если Вам так не нравится, тогда курите слово верификация и coverage из ПЛИС- и чипостроения. Смысл в том что в системе, покрытой тестами, ПО анализирует количество покрытого тестами кода, и ищет код непокрытый. Для этого правда нужно чтобы система была полностью HDL-ная.

Вот в этом и проблема. Как писать тесты для HDL я понимаю и они само собой есть. И тесты чаще всего поблочные. Т.е. каждый кубик оттестирован отдельно.

Проблема начинается при тестировании всех кубиков в сборе с залитым туда софтом. Т.е. масштаб модели резко увеличивается причём на порядки. И хотелось бы найти какие то промежуточные пути. Т.е. чтобы тестировалось несколько больше. А модель была не сильно сложнее.

В конечном итоге, пройдясь по всем этим мегагаграблям, вы и сами прийдете к мысли, что Вам нужно писать тесты для узлов Вашей системы(AVR ). Незамысловатые, в случае сдачи по ТУ, или с полным покрытием, если Вы собрались на Вашем устройстве лететь в космос, и это узел управления разгонным блоком "Бриз-М").

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

А если все это фантазии заказчика - делайте имитатор бурной деятельности)

Слава богу пока это моя инициатива

За ссылки большое спасибо

Ссылка на РЛС не рабочая (

Вот кстати из статьи на хабре как раз то про что я спрашивал.

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