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

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

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

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


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

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


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



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

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

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

+1

Как можно программными методами отследить случайный переход на случайную точку программы?
Я от этого контролем данных защищаюсь - см. мой предыдущий пост. Подсчётом их CRC, сравнением с инверсией и т.д.
ИМХО в случае несанкционированного перехода, данные и в регистрах и в ОЗУ, несоответствующие программе будут.
Это не 100% конечно. Но и CRC у порченных данных тоже совпасть может!
А если программа хотя-бы диапазоны данных проверяет - то и больших бед не натворит. И восстановиться потом можно будет!

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

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

Я тут ещё старый анекдот вспомнил. Как раз в тему.
Один программист у другого спрашивает. Почему у тебя два одинаковых jmp подряд стоят? Тот отвечает. Это на случай того, что 1-й не сработает.
Однажды поймал себя на желании именно так и сделать! В смысле два одинаковых jmp подряд поставить!!!
Дон Амброзио и другие участники этой ветки, вы себя на таком желании не ловили? А может и ставили? Если так - значит я с вами одной крови.

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

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


Я в курсе.

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



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


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


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

Но ведь сравнение то у вас происходит на программом уровне а не на аппаратном! А если программа перескочит туда где нет проверки на совпадение CRC?
Потом проверка данных после каждой операции мне кажется несколько избыточной.


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

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

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


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

Разуметцо



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

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

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

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

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

А я далеко не на все данные их инверсию завожу. А только на важнейшие. Несанкционированное изменение которых разрушительно скажется. Например N сектора в файле в который писать буду. И их в основном цикле ещё тоже перепроверяю. По 1й переменной за цикл. Это совсем быстро. Срабатывало.
А ещё в основном цикле CRC32 всей программы считаю. По 1-му слову за цикл. Ни разу не срабатывало.
А ещё если байтная переменная может иметь только несколько значений (< 86), я их не последовательно, а через 3, 5 или 7 увеличиваю. И за запрещёнными состояниями слежу. Срабатывало.

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