Принципы написания самопроверяющихся программ

[Serg79]

код изначально ущербен
Что все таки произойдет по default?

Что значит ущербный, а если функции требуется реагировать только на три состояния из всех возможных.

а вопрос о замене оператора неверен по своей сути.
177a:   81 30          cpi   r24, 0x01   

add   r24, r25  // сложение двух регистров
двоичное представление какое?
сколько единиц, нулей будет изменено?

Определяют три вида операторов: линейный, управляющий и предикатный. Так вот, любой из этих типов операторов может быть легко заменен на оператор из другого тапи или оператором своего типа.
Например:
1. Замена одного линейного оператора другим
2. Замена линейного оператора управляющим
3. Замена линейного оператора предикатным
и т.д. всего 9 возможных вариаций.
Таким способом програмными способами имитируют аппаратные отказы.

если проводить тестирование узлов МК, то надо проводить тест АЦП, ЦАП, регистров прерываний,ОЗУ, ПЗУ, таймеров
но не выполнение команд.
Если стоит задача по обеспечению безопасности работоспособности МК, то надо и выбирать соответствующие МК-производителей, с отлаженным ядром и пр.

Прежде чем приступить к тестированию всех перечисленных выше модулей МК, сначало надо убедиться в коректности работы АЛУ МК.
Если взять большие вичислительные системы под управлением операционной системы, то при глюках процессора с вероятностью 99.99999... управление просто не дойдет до вашего преложения, зависнит операционка. А в МК находится только ваш код и все, и в этом случае глюки АЛУ могут позволять как-то работать вашему коду, но коректность этой работы будет под большим сомнением.

[Sla]

функции требуется реагировать только на три состояния из всех возможных.

Сколько таких сосотояний может быть? (о трех мы уже знаем, а еще?)
а если вдруг пришло ЧЕТВЕРТОЕ сосотояние, например, произошел сбой на шине данных? С ним что делать?
Какая реакция остального кода?

Замена типов опреаторов - это задача не самодиагностики. Это задача диагностики при изготовлении или приемке самого МК. А делать это в процессе эксплуатации - неизвестно как себя поведет готовое изделие.

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

Чтоб не зависла система, для этого и применяются watchdog, от которых вы отказываетесь. Reset произойдет в нужный момент, через заранее известное время. а если МК завис и нет watchdog, то к МК нужно дядю посадить чтоб он его сбрасывал.

[Sla]

Допустим, вы все-таки создали необходимые процедуры и разработали методику диагностики.
Как часто вы собираетесь "самодигностироваться"? Успеете вы облужить перефирию?
почему все же возникла необходимость в самодигностических тестах.

Имхо. "Софт" который используется, например при тестировании контроллера должен быть отдельным. И никак не должен пересакаться с работающим "софтом". (Замечание Если это не противоречит безопасности системы, вернее сложности. Если предусмотрены только "ручные" режимы входа в "дигностику".

[Serg79]

Т.к. система реагирует на команды из вне, процедуры диагностики (подсчет CRC flash, eeprom, тесты памяти и АЛУ и т.д.) выполняются во время простоя системы. Как только поступила команда все тесты прекращаются и выполняется поступившая команда. Таким образом повышается вероятность обнаружения каких бы то нибыло неисправностей до начала выполнения команды.

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

Получается, что из 100% кода, 60%-70% приходиться на функции контроля.

Суть всего этого в том, чтобы при обнаружении какой бы то нибыло аномалии переводить устройство в защитный отказ.

Данная задача действительно очень интересная. Вданном случае очень расширела мой кругозор на принципы написания "софта" и в частности к требованиям к программному обеспечению.

[Sla]

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

тесты прекращаются и выполняется поступившая команда.

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

[Alf]

Кстати, о проверке целостности управляющей программы.

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

То же самое относится и к оперативной памяти. Конечно, за счет отказа от встроенных ОЗУ и ПЗУ теряем в компактности, зато надежность существенно возрастет.

[levon]

Alf, простите пожалуйста, но Вы не подскажите где можно поискать более подробную информацию по VAX-11?

[Джон]

К сожалению Альф больше не является участником форума, так что может получится так, что он не прочтёт это сообщение.

[Dale]

levon, мне доводилось иметь дело с семейством VAX-11. И как системный программист, и наладкой-ремонтом занимался.

Документацию, само собой, не сохранил. Но основные моменты вроде помню. Уж больно красивая архитектура была у VAX, такую вряд ли забудешь. Так что если есть конкретные вопросы, попробую ответить.

[levon]

Dale, добрый вечер. По vax мне вот что хотелось бы узнать: какие такие там хитрости применены в самотестировании/самодиагностировании и т.д. Дело в том, что в ближайшее время мне предстоит заняться улучшением работы жд устройств, а конкретно построенных на МК и имеющих какие-то программы работы. И идеи, лежащие в построении работы vax возможно помогут. 

[Dale]

levon, я могу кое-что рассказать на эту тему, но она скорее относится к области оборудования, а этот раздел выделен под технологии разработки софта. Получится оффтоп.

Давайте создадим тему в более подходящем разделе (например, "Железо"), и я поделюсь тем, что помню о средствах диагностирования VAX-11.