День добрый.

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

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

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

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

Что-то вроде BIST. На входе стоит схема и портит сигналы. Но сам так не делал. Чисто умозрительно.

Не совсем оно. Сейчас речь идёт не про самоконтроль. Проверять целостность и правильность работы есть кому. Задача как раз про блок который портит сигналы. Т.е. как наиболее просто портить сигналы.

Т.е. простейший вариант это некий блочёк висящий на шине между процем и периферией и подменяющий данные при обращениях к неким адресам.

Внешний управляемый стенд. Обычно просят наоборот - докажите, что ваш прибор адекватно реагирует на все ПРАВИЛЬНЫЕ внешние воздействия.

Стенд проверяет плату целиком. Т.е. проблемы которые возникнут на плате никак не проверить. Если мы говорим про надёжность то важным становиться не умение железа бегать без глюков по проторенной дорожке. Это то как раз программеры легко делают. А задача в том чтобы он так же хорошо бегал если начнутся проблемы. Т.е. мне нужно убедиться что я получу ошибку в телеметрии а не намертво зависший блок потому что программеры ждут в бесконечном цикле некий флаг...

Т.е. задача имитации неисправностей на уровне платы.

Инвертировать 'нужные' или случайные биты. Отключать интерфейсы целиком. Процедура вроде нехитрая.

Это да... вопрос скорее как это организовать. Если брать плис в >1000 ножками то инверсия каждой ножки да с выделенным управлением уже не хилая задача. Плюс не во все интерфейсы так легко будет влезть.

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

Теоритезирую - не бывает проблем на плате, которые никак не проявляются снаружи. Если только проблемные узлы совсем не нужны.

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


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

Предположим что отказал датчик. И соответственно обмен с ним идёт не штатно. Например если датчик I2C то обмена нет как такого.

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

Вот и спрашивается как должен быть подключён стенд так чтобы обеспечить имитацию отказа датчика извне?

Это должен тот самый BIST обнаружить.

Вопрос как проверить работу самого BIST? Вдруг он всегда Okey выдаёт. Т.е. как проверить алгоритмы которые условно можно отнести к BIST?

Э-э... это работа программистов. Один раз напрячься, сочинить, проверить. Вы же хотите железо проверять, в каждом изделии. Это разные сущности.

Я хочу проверять программу подсовывая ей более менее реальные неисправности.

Я понимаю. Для того, чтобы изредка проверить работу программы, можно залезть пинцетом в самые интимные места. Или проводом, подключенным к чему-нибудь... Потом в файл записать, что куда совали и какова реакция была. А если делать некий специальный стенд, так по мне, хватит подключения ко всем входным и выходным разъемам, и уже на них подавать всяко-разно. И если тесты не проходят, тогда уже можно и через JTAG подключиться, и еще через какие-нибудь тестовые разъемы.
Если я вижу, что прибор не работает, как надо, обычно можно с большой вероятностью предположить неисправное место.
Те же аналоговые цепи никакими программами не исследовать. Только по результатам работы.

Да всё верно. Но опыт показывает что те ветви программы которые не проверяются регулярно имеют тенденцию переставать работать после очередной правки/оптимизации.
И получается что хорошо бы иметь автоматизированный пинцет который так же автоматизированно замыкает эти самые интимные места. Причём можно замыкать реально входы. А можно выдавать данные аналогичные работе с неисправными входами.

Т.е. по сути задача увеличить покрытие тестами ветвей программы которые заточены под гипотетические ситуации.

Ничего универсального и простого не просматривается.
Нужно наработать какой-то toolbox с разными проставками для шин и интерфейсов. И какой-то объединяющий автомат/софтпроцессор или интерфейс для внешнего управления стратегией тестирования. Так вижу.
И это долго и дорого

Да... по этому и ищу чего то простого.

Пока вырисовывается некий блок стоящий на шине между процем и периферией который может портить данные по заданным условиям.

Если я правильно понял.
То обычно беру иголочку и тыкаю во все выводы поочередно. Что-то вроде помехи создаю. Но надо помнить, что не все выводы могут такое пережить. Ещё статикой проверял. Ногами по линолиуму пошоркаю и через неонку на корпус прибора. Или на полигон земли или на корпус заземленного разъема, например, USB. Так обычно находятся забытые висящие входы, не совсем корректно обрабатывыемые аналоговые сигналы т.д.

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

Другое дело, если повиснут блоки ПЛИС, но я в это слабо верю. Скорее залипнет логика, а логику тестируют в HDL-симуляторах, что касается ПЛИС.

Прошу прощения, автор темы указал как у него связан PC и ПЛИС? PC = personal computer?



Сомнительная практика, честно говоря, какая-то не конкретная без внятных цифр.

Какая есть Например, двунаправленная шина данных в какой-то момент находится в высокоимпедансном состоянии. Не попортятся ли данные если в этот момент наведётся помеха?
А какие цифры вы бы хотели увидеть? Количество ошибок отловленных в тексте программ, исправлений в схеме с помощью такого метода? Ну так это не сертификация на помехоустойчивость. Зато из оборудования только булавка, да неонка

Помеха какая - ну очень большая, просто жуть? Или так, слегка? Это серьезно?
Допустим испортились данные - какая защита от этого? Полагаемся на авось?

Симулить логику и программу в HDL симуляторе можно... но мееедленно же будет. Да и сгенерить полные тесты уровня платы это та ещё задача.А на что это влияет? Есть некий канал. Его детальная реализация мало на что влияет.

А в железе как тестировать ?
Ну хорошо, допустим часть сигналов Вы в каком-нибудь сигнал-тапе посмотрите.
Или какие-то данные сможете отправить через терминал на компьютер.
Но если словили сбой, и система повисла. Как Вы будете искать проблемный блок ?

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

Я чувствую что не спроста такой вопрос возник - вижу попытку повышения отказоустойчивости своего изделия. Если логика в ПЛИС сложна, но не могу посоветовать ничего иного, кроме BIST и медленных тестов на HDL-симуляторе. От этого не уйти.


Всё что является частью проекта - всё важно.

Тест на котором блок перестал отвечать известен. Найти место отвечаютщее за его работу дело 5 минут. Плюс опять же тест нужен скорее для создания блока чем для его тестирования. Т.е. это тесты разработчика а не сдаточные тесты.


Да так привильнее в теории. Но есть практика, сроки и местная бюрократия... Т.е. фирма ещё не доросла до этого. Моих силёнок да и знаний для всего этого не хватит Важно для проекта. Вопрос как это важно в данном вопросе?

засуньте все в свч печь

Так на плате нет аккумулятора. Заряжать нечего )))))

ТС были нужны проблемы на плате.

Пусть сует в свч, и по мере желания и необходимости поднимает мощность)

Странно, что про рашпиль как в datasheet на MC33298 никто не вспомнил.

Взято из песочницы.

Уровень платы это интерфейсы. Прекрасно тестируются.

А я вот вроде как в первый раз видел. Кланяюсь Алексею Кузнецову:

>Q: Как имитировать мощные помехи ?

A:Алексей Кузнецов

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

Ноне трудов великих нету кому хошь посёрфить в Интернете и нарыть десяток - другой загранишных машинок, специяльно всякими премудрыми хитрознатцами сотворенными на предмет испытания на помеху. Кои машинки попросче, кои позакрутистей, ин каждая поди фунт сухих рублей стоит, а то и поболее. А трудовым рублем зазря разбрасывать не следоват, лутше на него гостинцы дитю купить.

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

Много чего тут можно было б полезного в пример привесть, и релюшки самогенеряшшие, и пьзо-зажигалки от газовых плит приспособленные искру давать, и т.д. Одако ж по справедливости уделим внимание, братие, незатейливой, но жуть какой ядреной поделке из напильника. Для начала берешь изолируюший сетевой трансформатор, все ж какая-никакая а защита. Хорошо б ему еще фильтрок какой на вход присобачить, а то ведь как пойдет машинка помеху пускать, так в округе все приборы и протчие компунтели и коньки отбросить могут. Еще нужна индуктивная нагрузка, моторчик там, или ЛАТР, в обсчем чего под рукой будет.

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

Работать с ним так. Перво-наперво встаешь на изолирующий коврик, суешь одну руку в карман свой (обычно пустой и с дыркой, но енто к делу не отностится), и пока тестируешь руку из кармана не вынай, дабы ненароком ею за что не ухватиться. Ежели устройство проверяемое питание от сети получает то включаешь его во вторичную ентого изолирующего транса. Кладешь свое устройство неподалеку от напильника, включаешь сеть и начинаешь отверткой об напильник шваркать. ЛАТР икает, из-под отвертки искры летят, но бледные такие, посколь чрез индуктивную нагрузку ток невелик. Однако ж спектр у помех от искр от ентих - ого-го. И по эфиру машинка излучает, и в сеть пускает. А ежели ЛАТР помощнее - то машинка и форму сетевой синусоиды сбивает порой так что пересечение сети через ноль скачет как ошалелое на пару миллисекунд от свово законного месту. Ежели какой вентилятор заместо ЛАТРа пользовать то сеть не калечится, зато высокочастотные помехи бывают и покруче чем от ЛАТРа.

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

А уж на реальном объекте пахать все будет без сучка и задоринки.

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

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

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

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

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

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

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

Вот крутаны

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

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

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

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

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

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

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

мне очень жаль, это голимая реклама - все на агиленте. Но Вы можете экстраполировать)

http://www.unitest.com/pdf/5990-7036ru.pdf
http://www.intermera.ru/news/agilent-techn...-i-sredstv-reb/


может быть Вы вообще тогда цели путаете ? может Ваши ключевые слова: "надежность" "резервирование" "мажоритирование" ?


ну знаете. Любишь кататься...
Хотя несложно представить себе инжекцию шума в разделительный конденсатор Pcie через еще один конденсатор. Хуже если шины параллельные.


Я думаю лучше всего об этом и спрашивать у самих ядровцев. Например я с интересом читал общение Tosha1984 с iiv, где Tosha1984 рассказывал, как прикидывать на пальцах допустимую длину несогласованной линии для корректной передачи быстрых сигналов .


только вот так не делайте)

Благодарю Это мои родные слова )) И резервирование есть в полном объёме. Резервом накрыт уровень выше. А вот уровень ниже работает сам по себе сколько может. И отказ некой мелкой периферии это ещё не повод включать резерв. Т.е. по сути то что я делаю это попытка выжать из аппаратуры больше чем может дать просто резервирование.

Т.е. можно например заменять человека если у него порезан палец. А можно в принципе работать дальше даже с этим повреждением. Т.е. по сути получаем систему способную пережить не один отказ а больше

Не не не Плату менять и править точно низя. Т.е. любые методы уровня плис и софта.

Так я думал они тут и обитают.


Вот всеми силами стараюсь сделать чтобы так не было... но силы не равные ))

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

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

Я вот сейчас над чем работаю - именно что мне нужно не просто отладить проект в FPGA, а тупо устранить все возможные сбои. Если задача критическая, то и меры особые. В соседнем разделе можно видеть, что я осваиваю UVM для этого. Инициатива хорошая.

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

Это идея!!! Спасибо. Я так масштабно не задумывался.

Решает. Но это слишком низкоуровневый уровень. А как следствие трудозатратный.