Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Переходим на https. Просьба писать обо всех замеченных неисправностях.
  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 [2]  Все   Вниз
  Печать  
Автор Тема: Принципы написания самопроверяющихся программ  (Прочитано 34165 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Serg79
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #30 : 18-09-2006 04:10 » 

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

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

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

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

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #31 : 18-09-2006 06:33 » 

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

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

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

Мы все учились понемногу... Чему-нибудь и как-нибудь.
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #32 : 18-09-2006 12:45 » 

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

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

Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
Serg79
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #33 : 19-09-2006 04:34 » 

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

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

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

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

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

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #34 : 19-09-2006 06:24 » 

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


Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
Alf
Гость
« Ответ #35 : 19-09-2006 06:40 » 

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

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

То же самое относится и к оперативной памяти. Конечно, за счет отказа от встроенных ОЗУ и ПЗУ теряем в компактности, зато надежность существенно возрастет.
Записан
levon
Гость
« Ответ #36 : 04-09-2009 13:41 » 

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

de
Offline Offline
Пол: Мужской

« Ответ #37 : 04-09-2009 13:48 » 

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

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #38 : 05-09-2009 14:25 » 

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

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

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
levon
Гость
« Ответ #39 : 05-09-2009 17:10 » 

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

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #40 : 05-09-2009 21:26 » 

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

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

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Страниц: 1 [2]  Все   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines