[Don_Ambrosio 0]

Насчёт тестов считаю, что они полезны, но не особо. Хотя сам во время работы CRC32 программы всё время считаю (в фоновом режиме).

Но вот то, что интересно:

Никто из авторов про ЛОГ-и даже и не упомянул! А без логов все эти тесты - фикция.

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

Ну так вот - произошло что-то во время работы . Тест там что-то накопал, или просто процессор по собаке перезапустился, и снова все работает. Никто об этом и не узнал! Ну, может оператор нецензурно выругался, питание выключил-включил и забыл об этом. В худшем случае питание само выключилось (может по всему городу). И всё - все концы в воду!

Некоторые горе-разработчики этому даже рады будут! Они ничего не докажут - мы ни в чём не признаемся!

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

 

Но насчёт логов - это уже другая тема. Может организуем? Я бы поддержал.

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

[Getmanov 0]

Как говорится: лучше перебдеть, чем недобдеть

 

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

 

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

 

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

[SapegoAL 0]

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

 

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

 

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

[Don_Ambrosio 0]

Перебдеть то может и лучше, если это не будет вызывать сбоев оборудования

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

[DogPawlowa 0]

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

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

[SapegoAL 0]

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

[Getmanov 0]

Скорее наоборот, сбой оборудования может вызвать сбой в программе

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

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

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

[Don_Ambrosio 0]

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

Да? А случайный джамп не вызовет сбоя в программе? И искжение данных в ОЗУ? Почитайте тут

http://electronix.ru/forum/index.php?showt...mp;#entry365890

 

 

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

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

 

 

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

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

 

будет сбоить именно при диагностическом тестировании.

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

 

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

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

[zltigo 1]

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

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

[_Pasha 0]

По поводу надежности программы.

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

[Getmanov 0]

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

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

[galjoen 0]

По поводу надежности программы.

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

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

[Don_Ambrosio 0]

не соответствует первым-же словам Вашего постулата "если алгоритм корректный" - ну нет корекных алгоритмов работы программ в неисправных машинах.

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

 

не предусмотрели реакции на отказы тех или иных узлов

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

[SapegoAL 0]

По поводу надежности программы.

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

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

 

Теперь возвращаясь к цитате.

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

 

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

 

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

[_Pasha 0]

Теперь возвращаясь к цитате.

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

 

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

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

 

С момента, когда программа начинает жить своей жизнью - её надо просто переписывать заново.

 

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

 

Такие, чтобы выход из строя вашего изделия ЛЮБЫМ СПОСОБОМ не приводил к этому взрыву.

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