[Don_Ambrosio 0]

Надо отделить мух от котлет. Ибо проблема надежности устройства не ограничивается только ПО микроконтроллера. Если у вас программные сбои происходят от разряда пьезозажигалки, то программа тут совершенно не причем- все проблемы решаются правильной трассировкой. Для этого и существуют испытания на ЭМС и разные группы жесткости устройств.

Я в курсе. Но повторю:

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

 

Ибо нафига мне "суперпупернадёжная" система, у которой происходит один сбой в год, но он НЕ ОБНАРУЖИВАЕТСЯ СИСТЕМОЙ. Я лучше возьму систему, у которой сбои происходят каждый день, ну у которой эти сбои НЕ ПРОХОДЯТ НЕЗАМЕЧЕННЫМИ СИСТЕМОЙ

Т.е. я предлагаю даже УХУДШАТЬ надёжность работы девайса если это позволит увеличить вероятность обнаружения всех сбоев

[DogPawlowa 0]

За темой следить не вижу ни малейшего смысла.

А как модератор?

Чем раньше будет заткнут очередной фонтан доктора Туамосеца, тем плодотворнее будет форум.

Пусть он лучше на порнушных сайтах пишет.

[Don_Ambrosio 0]

Как можно программными методами отследить случайный переход на случайную точку программы?

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

 

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

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

 

Ибо нафига мне "суперпупернадёжная" система, у которой происходит один сбой в год, но он НЕ ОБНАРУЖИВАЕТСЯ СИСТЕМОЙ. Я лучше возьму систему, у которой сбои происходят каждый день, ну у которой эти сбои НЕ ПРОХОДЯТ НЕЗАМЕЧЕННЫМИ СИСТЕМОЙ

 

 

Как мне кажется решение должно быть на уровне железа.. (внешние контролирующие устройства(тотже только внешний WDT), дублирующий контроллер(возможно выполняющий туже задачу) и т.п.) Это мое ИМХО.

Моё ИМХО такое же.. Но всё же лучше "соломки подстелить". Ибо лучше перебдеть, чем недобдеть

 

 

За темой следить не вижу ни малейшего смысла.

А я никого и не заставляю читать эту тему или чтото писать в ней. Так же как оставляю за собой право НЕ ЧИТАТЬ и НЕ ОТВЕЧАТЬ в неинтересных мне темах

[Schtirlitz 0]

Ибо нафига мне "суперпупернадёжная" система, у которой происходит один сбой в год, но он НЕ ОБНАРУЖИВАЕТСЯ СИСТЕМОЙ. Я лучше возьму систему, у которой сбои происходят каждый день, ну у которой эти сбои НЕ ПРОХОДЯТ НЕЗАМЕЧЕННЫМИ СИСТЕМОЙ

Т.е. я предлагаю даже УХУДШАТЬ надёжность работы девайса если это позволит увеличить вероятность обнаружения всех сбоев[/i]

А как быть с вероятностью сбоя программы обнаружения сбоев?

Не нужно изобретать велосипед: если нужна вероятность отказа устройства 10 в минус 9-й степени - применяйте резервирование, мажоритарные схемы итд.

[zltigo 0]

А как модератор?

А как Модератор - пусть пока обсуждают. Для неокрепших умов наивно предполагающих, что проблему

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

[galjoen 0]

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

 

Ибо нафига мне "суперпупернадёжная" система, у которой происходит один сбой в год, но он НЕ ОБНАРУЖИВАЕТСЯ СИСТЕМОЙ. Я лучше возьму систему, у которой сбои происходят каждый день, ну у которой эти сбои НЕ ПРОХОДЯТ НЕЗАМЕЧЕННЫМИ СИСТЕМОЙ

+1

 

Как можно программными методами отследить случайный переход на случайную точку программы?

Я от этого контролем данных защищаюсь - см. мой предыдущий пост. Подсчётом их CRC, сравнением с инверсией и т.д.

ИМХО в случае несанкционированного перехода, данные и в регистрах и в ОЗУ, несоответствующие программе будут.

Это не 100% конечно. Но и CRC у порченных данных тоже совпасть может!

А если программа хотя-бы диапазоны данных проверяет - то и больших бед не натворит. И восстановиться потом можно будет!

[Don_Ambrosio 0]

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

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

 

Просто в этой теме рассматривается маленькая часть огромного вопроса обеспечения надёжности систем(ведь нельзя в одной теме объять не объятное). А Вы ёрничаете

[galjoen 0]

Я тут ещё старый анекдот вспомнил. Как раз в тему.

Один программист у другого спрашивает. Почему у тебя два одинаковых jmp подряд стоят? Тот отвечает. Это на случай того, что 1-й не сработает.

Однажды поймал себя на желании именно так и сделать! В смысле два одинаковых jmp подряд поставить!!!

Дон Амброзио и другие участники этой ветки, вы себя на таком желании не ловили? А может и ставили? Если так - значит я с вами одной крови.

[mig2002 0]

Возвращаясь к первоначальному вопросу могу посоветовать применить при написании программы теорию графов.

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

На практике ввести переменную STATE, задавать ей значение только перед переходом в новое состояние.

[Don_Ambrosio 0]

А как быть с вероятностью сбоя программы обнаружения сбоев?

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

 

Не нужно изобретать велосипед: если нужна вероятность отказа устройства 10 в минус 9-й степени - применяйте резервирование, мажоритарные схемы итд.

Я в курсе.

 

Но даже если Вы грамотным проектированием железа сделаете вероятность сбоя 10 в минус 15-й, то всё равно используя программые методы можно ещё увеличить такой параметр надёжности как вероятность обнаружения имевших места сбоев

 

Как можно программными методами отследить случайный переход на случайную точку программы?

 

И как же ? По вашему мнению?

 

 

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

 

Возвращаясь к первоначальному вопросу могу посоветовать применить при написании программы теорию графов.

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

На практике ввести переменную STATE, задавать ей значение только перед переходом в новое состояние.

Спасибо... Что-то подобное и делаю, только использую не STATE а регистр кода доступа к логическому сегменту

[adc 0]

Как можно программными методами отследить случайный переход на случайную точку программы?

Я от этого контролем данных защищаюсь - см. мой предыдущий пост. Подсчётом их CRC, сравнением с инверсией и т.д.

ИМХО в случае несанкционированного перехода, данные и в регистрах и в ОЗУ, несоответствующие программе будут.

Но ведь сравнение то у вас происходит на программом уровне а не на аппаратном! А если программа перескочит туда где нет проверки на совпадение CRC?

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

 

И как же ? По вашему мнению?

Есть предложение в начале каждой операции(подпрограммы) загружать в озу константы , а в конце считать контрольную сумму этих чисел и записывать также в озу. Далее по прерыванию от таймера(включенного при инициализации) проверять соответствие текущих констант в озу и их контрольной суммы. Если не соответствует принимать меры.

Конечно тоже не 100% метод... но всеже.. :)

[mig2002 0]

В принципе, однозначного решения данного вопроса быть не может

Решение нужно выбирать для конкретной задачи. Можно ипользвать и программные методы, и аппаратные. Нужно только определиться с приоритетами: быстродействие или надежность. Хотя понятие надежности тоже относительное. А степень надежности должна определяться стоимостью обрабатываемой информации.

[Don_Ambrosio 0]

В принципе, однозначного решения данного вопроса быть не может

Оно и понятно. А Вы как решаете проблему обнаружения в программе несанкционированных переходов?

 

А степень надежности должна определяться стоимостью обрабатываемой информации.

Оно и понятно .. Нет смысла применять супер-пупер методы увеличения надёжности для управления ёлочной гирляндой

 

Можно ипользвать и программные методы, и аппаратные.

Разуметцо

 

 

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

А что Вам MCU жалко? Да бростье Вы..Он же железный... Пусть работает

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

[Don_Ambrosio 0]

Вообще сейчас скажу крамольную мысль (только чур не бить ногами)

 

Чем более чувствительна программа к аппаратным сбоям тем лучше

 

Т.е. если правильно и грамотно разработанная программа начинает ЗАМЕТНО глючить от каких либо помех, то это здорово. Потому что гораздо хуже если в программе чего-то глюкануло, а мы этого не заметили и считаем что всё ОК

[galjoen 0]

Но ведь сравнение то у вас происходит на программом уровне а не на аппаратном! А если программа перескочит туда где нет проверки на совпадение CRC?

Как я и писал там-же, я это делаю в основном цикле (не RTOS). По 1-му байту за цикл. На это меньше 20 тактов уходит. Из них сам подсчёт CRC16 - 10 тактов. А ухожу на восстановление только если два раза подряд CRC не совпало. А команда wdr у меня только в основном цикле стоит. Если я туда попадать перестану - собака сработает. Но ни разу ещё не срабатывала! У меня все логи пишутся.

А вот проверка CRC данных бывало срабатывала.

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

А я далеко не на все данные их инверсию завожу. А только на важнейшие. Несанкционированное изменение которых разрушительно скажется. Например N сектора в файле в который писать буду. И их в основном цикле ещё тоже перепроверяю. По 1й переменной за цикл. Это совсем быстро. Срабатывало.

А ещё в основном цикле CRC32 всей программы считаю. По 1-му слову за цикл. Ни разу не срабатывало.

А ещё если байтная переменная может иметь только несколько значений (< 86), я их не последовательно, а через 3, 5 или 7 увеличиваю. И за запрещёнными состояниями слежу. Срабатывало.

 

А вообще, всё это у меня началось после того, как я испытания на ЭМС прошел. Со 2й попытки. Всего лишь класс B. Но жесткость была максилальная. На наносекундных импульсах проблеммы были.

А у вас как с ЭМС? С наносекундными импульсами? Если скажете, что от них не сбивается (класс A) - не поверю!!!