Я не упомянул про логи, потому что считал ведение логов само собой разумеющимся... Результаты POWER_ON-теста и самотестирования и самодиагностики во время работы девайса разумеется должны быть так или иначе донесены до человека (или выодом на экран или записью в энергонезависимый архив)

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

Могу сделать вывод, что диагностика работы обязательна, но без фанатизма.

Для устройств которые обеспечивают надёжность 99.9(9)% надо использовать какой-нибудь ПЛК с горячим резервированием, а не городить огород из МК.

Особенно если учесть тот факт, что стоимость младших моделей МК опустилась ниже 1$, а стоимость средних 32-ух битников ниже 10$. При этом стоимость оборудования обычно превышает 100, а при высоком требовании к надёжности будет от 1000 и выше.

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

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

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

Стиральная доска всегда надёжнее чем стиральная машина. Чем сложнее система, тем она менее надёжна. Это относится и к программному обеспечению, хотя и в меньшей степени.

А вот как раз и нет. Сбой оборудования не должен вызывать сбоя в программе, иначе это ПЛОХАЯ программа.

Под оборудованием я имел ввиду весь комплекс, а если он сбоит, то заказчику будет все равно, почему у него не работает его устройство- потому, что МК повис, или потому, что провод оборвался.

Да? А случайный джамп не вызовет сбоя в программе? И искжение данных в ОЗУ? Почитайте тут
http://electronix.ru/forum/index.php?showt...mp;#entry365890


Согласен..А к чему Вы это сказали?



Да Вы мне прям Америку открыли


Повторяю. Нормально написаннная программа без ошибок просто так не сбоит. Если программа сбоит (ПРАВИЛЬНАЯ ПРОГРАММА) значит железо сбойнуло


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

Абсолютно правильные слова - подпишусь под каждым. Неуклонно следую принципу, что в правильно написанной системе кода, который занимается разборками с нештатными ситуациями должно быть как минимум сопоставимое количество с рабочим кодом. Watchdоg, для защиты от программых ошибок это вообще абсолютный моветон. Однако, весь, извинте, буду грубым, бред, который в соседней ветке и тут выплескивается не соответствует первым-же словам Вашего постулата "если алгоритм корректный" - ну нет корекных алгоритмов работы программ в неисправных машинах. И "кодирование без ошибок" - занимаясь всей этой надуманной фигней написать код без ошибок становится невероятной задачей, для сколь-нибудь РЕАЛЬНОГО приложения, а не кунштюковской демки.

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

Что Вы имеете в виду под железом? Если только МК то согласен, если весь комплекс,то нет!

Соглашусь, что этот пример хорош, но только в том случае, если эта константа вообще не меняется. Если она периодически меняется - я буду её в ОЗУ хранить. Но и её инверсию тоже. И при "заглядывании" их ксорить и на FFFFFFFF проверять.

Если при разработки Embedded-программы, предназначенной для использования в устройствах, которые может быть годами должны работать без вмешательства человека Вы в коде программы не предусмотрели реакции на отказы тех или иных узлов, то, ИМХО, это программа не правильная и устанавливать её на девайс, ИМХО, преступление


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

Скажем так, я с этим не согласен. Ниже объясню почему. Это, кстати не относится к словам zltigo. Здесь я соглашусь. ВСЕ исключительные ситуации должны быть обработаны. Это очевидно. Более того именно программист и видит все эти ситуации. Иначе в его программе будут необработанные ветки либо упрощённый алгоритм.

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

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

По поводу проверок, я тоже согласен с подходом "анализ исправности чипа чипом исправность которого вызывает сомнения - нонсенс" Ну понимаю - сделать самодиагностику до старта и блокирнуться, хотя нет никакой гарантии что это произойдёт. Но теория вероятности такова, что для вас, к примеру, выход одного изделия из тысячи - 0.1%, а для клиента, который купил одно ваше изделие - 100%. Это я к тому что если от вашего изделия может взорваться снаряд (принципиально может), и вероятность этого события 0.1%, то это уже недопустимо потому, что кому-то это может стоить жизни. А значит здесь надо применять другие методы. Такие, чтобы выход из строя вашего изделия ЛЮБЫМ СПОСОБОМ не приводил к этому взрыву. Это только резервирование.

У меня время жизни объектов без их регенерации сравнительно короткое. Иногда ставлю низкоприоритетный тред, который пересчитывает кое-какие "константы". И вот почему:
Сколько можно гонять/тестировать девайс? Новая ли разработка, либо просто выходной контроль - чем короче можно сделать этот процесс, тем лучше. В случае периодической калькуляции



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


Нет, я в такое не лезу. Зубками не вырос.