+1
Тут я-бы ещё про CRC (мой конёк) написал. ИМХО CRC прекрасно от случайных помех защищает. Против человека или вируса (за которым тот-же человек стоит) CRC бессильна!

Оно то конечно, дай бог... Но, как сказал один кэп - "не асилит ваша система противостоять пьяному матросу с топором", люди ведь всегда способ найдут...



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



Бывает. Подмели порошочек и дальше работаем. У нас случай был один... Баллоны с порошком на уровнях снаружи одного здания стояли, система управления - в соседнем, расстояние 20 метров. Кабеля на пиропатроны по металлической эстакаде со здания на здание шли. В процессе пусконаладки подключили кабеля к пиропатронам, на другой стороне - висят в воздухе возле приборов, в клемники не вкручены. Вечером уехали с объекта, а ночью гроза, куда долбануло - хз, но 5 тонн порошка насыпало. Выстрелили все пиропатроны. Утром приехали - а там уже все чистенько, все хорошо... Так что и без микропроцессорной аппаратуры бывает стреляет, а тут говорят - вот PC слетает )



Это "Радий" видимо. У них там мозг под WinCE катается. Знаем таких. Самое смешное, что требования по АЭС они может и выполнили, а вот требования именно по пожарным делам - еле асилили сертификацию, захода с третьего. И то, нет у меня твердой уверенности, что третий заход был без "оказания материальной помощи" нужным людям...

Меры против "пьяных матросов с топорами", "пьяных диспетчеров с ключами", "пьяных летчиков с самолетами", "и пьяных мотостелков в БМП" предпринимаются задолго до поступов к БЩУ и РЩУ.
На горизонте маячат кораблики, на ближлежайших горах зенитные батареи, вокруг ров с водой, немалое количество военизированной охраны регулярно устраивающей натурные тренировки. Здание энергоблока монолитом за один непрерывный процесс отлито из бетона. Железа тоже вбухано не меряно. Бетон качественный - не для строительства жилых домов - швейцарским ножем сколь-нибудь заметной царапины оставить не удалось. Топором - топром полагаю, можно, но только царапину.
Гермозона вообще сплошное железо.
В пределах Ядерного Острова человеческй фактор на контроле прохода сведен к минимуму, но на подходе к щитам управления техника несколько раз дублируется, но не заменяется, людьми. Сигнализация не только пожарная , видеонаблюдение, прослушивание разговоров....

Ага, подмели . Стойки с оборудованием, вентиляторы, кондиционеры, мягкая мебель....

Не в курсе - просто на БЩУ оборудование рядом стояло.

По пожарным? Все как обычно - здоровые баллоны, манометры, толстые шланги под потолок, трубы и форсунки на потолке, насколько понимаю все достаточно стандартное.



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

Знаете что мне это напомнило?
"За революцию 1917 отдельное спасибо русским. Весь мир стал жить лучше."
Перефразируя
"За Чернобль отдельное спасибо русским и украинцам, надёжность реакторов во всём мире значительно возросла."

Кстати техника там была не в ответе. Там её поотключали просто при испытании "на выбеге".

Обсуждение стало плодотворным, даже модератор втянулся, но, к сожалению, не совсем по теме.
Может кто-то из спецов подведет итог всем предложениям по защите кода с краткими комментариями конкретно по предложенным способам (кодам)? Так сказать ИТОГО в положительном балансе по (промежуточному?) результату обсуждения. мне кажется, что для простых смертных это было-бы полезно.

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

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

А в не жестких?Для обычных девайсов на чем-нить дешевом без всяких излишеств,зависон которых
не приведет к пожарам/взрывам,но которые тоже хочется как-нить защитить от слетов при ударах молнии,бросков питания и т.д?Я из треда пока уловил одну здравую мысль-сброс собаки делать в специальном самом низкоприоритетном потоке(я тупо сбрасывал до сих пор в системном таймере ).

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

такое решение применено еще в советской аппаратуре 80-х годов на 580вм80-внешний 555 таймер,выход которого сидит на сбросе проца и сбрасываемый портом процессора.Проверено-при бросках питания виснет очень даже хорошо.

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

ну в AVR собака тоже от отдельного генератора тактируется.

Да, знаю. Используются оба. В разных задачах сбрасываются. Тот, который внешний, требует сброса с определенным интервалом, не быстрее, не медленнее определенных ворот. Такого плана WDT, кстати, в XMega. Для SL45 (ядро C166) и S75 (ядро ARM9) могу завтра код продемонстрировать соответствующий (есть просто .idb, хорошо мною разобранные), у любого другого в течении часа по отладочной печати найду.

Да нет, я верю.

На то он и внешний, дабы быть продвинутым.

А в нежёстких - продуманный алгоритм + WDT. Ничего другого пока не придумали.
И посмотри там один из первых моих постов, - я там по пунктам. Там я уже говорю, что сброс в прерывании (без ОС) равно как и сброс в сист. таймере - некоректный подход (равно как и тупое вставляние WDR во все циклы). Так как в Вашем случае могут загинуть все процессы, а таймер будет весело щёлкать. То же самое с циклами, - по сбою вы попадаете в цикл где весело щёлкаете WDR и глухо висите.

Чтобы этого не происходило число WDR должно быть минимальным, период - подобран, в цикле где стоит WDR должен осуществляться контроль важнейших параметров режима работы программы. (В вашем случае - специальный низкоприоритетный процесс). К числу параметров - разрешение прерывания, наличие работы всех процессов), возможные другие.

Cпасибо,Саша.
А на практике все таки,как убедиться,что все процессы живы,а не
весело щёлкаете WDR и глухо висите

Например, завести набор флажков. При WDR сбрасывать. А в каждом критичном месте программы - взводить свой флажок. При очередном сбросе WDR - проверить, все ли флажки взведены. Если не все, то висим.
Можно усложнить, ждать взвода флажков несколько циклов.

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

а на практике, делаем примерно так:
при загрузке определяем источник ресета, если было не от power on , то регестрируем ошибку.,
делаем заглушки на все незадействованные прерывния(если есть связь с верхом то предаем это на верх ), запускаем автомат контроля использования стека/рам, запускаем автомат контроля
использования текущего размера системного тика....

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

Тогда флажка не хватит, нужен счётчик. При получении флажка от такой задачи счётчик сбрасываем. При неполучении - увеличиваем. Когда значение счётчика превысит порог - висим.

Ну, недостаток сброса в системном таймере неоднократно обсуждался (например, получение команды HALT. Не знаю правда, есть ли она в AVR - уже привито ). Я обычно использую достаточный минимум - в системном прерывании взводится флаг, в основном кольце по этому флагу непосредственно сбрасывается WDT.

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



Зачем же? На практике можно продолжить работу - подумаешь, сброс прошел?
Работать! Вернуться на то же место. Не под ОС, конечно

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

Согласен...Мог и R16 сбитцо..Мог и SREG_Z... Была ещё такая тестовая прога:

; Зажечь светодиод
ldi R16 , 0b11011111
out PortC , R16
;------------------
Loop:
cli
wdr
rjmp Loop
;---------------
Crash:
; Погасить светодиод
ldi R16 , 0b11111111
out PortC , R16
rjmp Loop
;---------------------------
rjmp Crash
rjmp Crash
rjmp Crash
rjmp Crash
.....
rjmp Crash
rjmp Crash
rjmp Crash
rjmp Crash
;------------------------------



При испытаниях вначале светодиод горел... Пять минут...После того как я потрыкал пьёзозажигалкой светодиод погас... Трыкал ещё...И один раз (за целый день "издевательств" мне удалось обратно зажечь светодиод


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

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


Ещё один мне "Америку открывает" Повторяетесь , Господа.. По кругу уже начинаем топтаться.

Повторяю для "не четателей а писателей": я ниразу не отрицал необходимости впервую очередь аппаратных решений для обеспечения надёжности



А Вам за что платят деньги? За то, что Вы штампуете посредственные программы? Зато быстро?
А что? Для Вас очень затруднительно написать прогу с обнаружением и разруливанием сбоев? Тогда я вообще не понимаю за что Вам платят деньги


А реалии рынка - эта гнать вал? Т.е. не нормальные программы, а, простите, посредственное фуфло? И что? Есть люди, которые за это фуфло ещё готовы платить деньги?



Если для Вас это всё слишком сложно, то почему Вы вообще работаете в области эмбедерства? Может лучше носками торговать?


Вот поэтому я "соломки подстелю" в виде спец. организации проги, чтобы сбои были по максимуму обнаружены и устранены их отрицательные последствия... Ибо какой бы у Вас супернадёжный девайс не был, лучше перебдеть, чем недобдеть. Да, "программные методы" не дают 100% гарантии обнаружения сбоя. А из-за 99,99% Вы и "мараться не будете"?


Во-во.... Я бы инженеров с таким подходом на версту бы не подпустил к разработке..Пусть лучше трусами торгуют..


А если подумать? Или Вы задаёте этот вопрос, просто чтоб продемонстрировать, что "против лома нет приёма"?. И что? Да..Это действительно тот случай, когда "против лома нет приёма".. Я же Вам уже говорил..И не один раз.. Что программа не может обнаружить 100% всех возможных сбоев.. Тогда к чему Ваш вопрос?


Вот например Вы если будете знать, что Вам 100% на голову свалиться или плита или кирпич. От кирпича Вас может спасти каска, а от плиты..уж извините...Ничего не поможет... И что? Вы даже каску не оденете следуя Вашей логике, которую Вы тут всем пытаетесь навязать.. Да?

Вы удивительно догадливы, именно за это За одним мааааленьким исключением: пока еще никто на качество моей работы не жаловался. А вот на скорость - да, бывает говорят, нужно быстрее.

См. выше

Да вот, виноват мозгами вышел, скучно мне носки продавать.

Лааадно! Пора спать

Не покатит. После первого же IJMP, возврата в while(1) не будет, а к сожалению генератор псевдо-случайных чисел будет давать всегда одно и то же число, с высокой долей вероятности - безопасное.

Поэтому модель лучше сделать такой:
1. random'ом или перебором заполнять регистры.
2. делать ICALL внутрь функции в которой выполняется SPM

Результат могу сразу сказать - рано или поздно - свалится

Была ещё такая тестовая прога:

; Зажечь светодиод
ldi R16 , 0b11011111
out PortC , R16
;------------------
Loop:
cli
wdr
rjmp Loop
;---------------
Crash:
; Погасить светодиод
ldi R16 , 0b11111111
out PortC , R16
rjmp Crash
;---------------------------
rjmp Crash
rjmp Crash
rjmp Crash
rjmp Crash
.....
rjmp Crash
rjmp Crash
rjmp Crash
rjmp Crash
;------------------------------


Максимум на 10 "трыке" пьзозажигалки светодиод гас. Если "удачно" подключить к корпусу девайса проводок, идущий от "земли" пьезозажигалки и "удачно" приложить точку приложения искры.


Вот и говорите после этого, что порча PC маловероятна

Спасибо, уже дошло.
Остановлюсь на чуть исправленном
варианте

А еще интересно, как это Доктор так лихо чиркает пьезоспичкой, что у него все стабильно сбивается.
Вчера вечером чиркал-чиркал -- все нормально.
Доктор, Вы случаем эти киловольты на корпус не наводите ?
Блин, пока писал, Доктор уже сам ответил.
Так вот, когда нормы ESD sensitivity нарушаются, то к чему камлания?
Явно же ж кто-то виноват. А подвиг одного, как известно, - это преступление другого.
И что самое печальное - паранойя не только профессиональная болезнь, она еще и заразная.

По проге:
1 .А вы там случаем DDRC не забыли проинициализировать?
2. И ещё зачем там в цикле CLI? Понятно было бы перед циклом, но в цикле не очень понятно. Это тоже с каким то тестированием связано?

Просто эти мелочи позволяют соменению закрасться.

По поводу защиты от "случайных" jump:
Допустим наша программа состоит из блоков Check - это всяческие проверки о которых тут писалось и блока Run - в этом блоке выставляются управляющие сигналы, действия которых нельзя отменить(ну к примеру "Пуск ракеты" это всё конечно утрировано).
В итоге получим

В результате случайного джампа мы попали в Run....

Конструкция

не покатит в силу специфики применения. Т.е. в этом случае задача всё таки нерешаемая или я не прав?

Конечно если программа будет на 99,(9) % состоять из Check, а оставшаяся часть будет Run всё равно будет ненулевая вероятность пуска ракеты.

P.S.
Дон Аброзио, если не составит большого труда и это не является большим секретом могли бы показать стандартную обвязку вашего MCU(цепи питания, резета, развязка входов выходов)? Eстесно готовые схемы не надо. Просто в общем виде типа как в апп ноте рисуют. А то получается вы всегда приводите программу без схемы и говорите что сбоит программа, а может дело то и не в бобине.

На основании этх тестов я понял, что всё же лучше попытаться обнаруживать в программе эти случайные джампы. После этого я решил проверить "а как же с ОЗУ? Оно не портиться?" И модифицировал прогу так, что она у меня непрерывно совершала тест ОЗУ. "А как же порча ячеек FLASH?" - подумал я. Короче, сделал и непрерывный тест флэшь. Короче у меня крутились 2 потока и ядро RTOS. Один поток непрерывно тестил ОЗУ, другой флэшь. И плюс оба потока были "сконструированы" так, что обнаруживали (разумеетцо не со 100% вероятностью) случайные дампы.

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


Хотя конечно нельзя утверждать со 100%-й уверенностью, что переход на соотвествующий обработчик сбоя был вызван соответствующей ему причиной. Например переход на обработчик порчи ОЗУ запросто мог быть вызван случайным джампом. Хоть это и менее вероятно (за счёт того, что у меня программа организована специальным образом + некоторые аксиомы по вероятности, которыми я руководствовался), но исключить такую вероятность нельзя


А что? Реальные помехи просто обязаны подчиняться нормам ESD А то их в тюрьму посадят если они нарушат нормы ESD?




Не забыл.. Иначе бы светодиод не зажёгся... Кстати , да... Погасание светодиода в конкретно этой программе могло быть вызвано и случайным изменением PortC, ddrC... А вообще у меня была куча различных тестовых программ (всех вариантов и не упомнишь) . Поэтому я в своих примерах на форуме пишу только часть кода, из которой можно понять основную идею теста



Может это и паранойа (как некоторые выражаются) но для надёжности. Я всегда так пишу когда мне нужен гарантированный программный СТОП. И написать однц 1-тактовую команду меня не сильно затрудняет. Так же как процессор не сильно затрудняет её выполнить


А если подумать?
У меня "запуск ракеты" от одной команды невозможен. Ибо у меня железо выполено таким образом, что релюшка, запускающая "ядерную ракету" ( ) включается как минимум 2-мя пинами, сигналы на которых устанавливаются в разных точках программы. Так что даже если на один из пинов в результате сбоя будет подан сигнал "Enable RUN", то на другом-то пине такого сигнала не будет. И Америку не придётся с карты стирать ластиком

1. На реальные помехи - реальная экранировка подсобного хозяйства и реальные техусловия
2. Пример решения на уровне архитектуры: см. MC68HC908MR08(freescale) понятие "WRITE-ONCE REGISTER"

Нормы эти, как и пайка солдатская, выработаны годами изучения вопроса. С достаточной степенью точности они описывают реальный мир. Кроме того, испытания в соответствии с данными нормами (испытания должны быть проведены соответствующей структурой, на соответствующем оборудовании, закончены выдачей соответствующих документов, подтверждающих соответствие) дают Вам полное право при наезде на Вас плана "у Вас устройство глючит из-за помех" замерить эти помехи непосредственно на объекте и при превышении просто послать заказчика на йух или, например, снять с него дополнительные деньги за доработку устройства под условия заказчика. Обычно заказчики идут на второй вариант, им спокойней.

Но хотел я не то сказать. Я уже писал про полсотни резисторов выше, видимо никто не прочитал пост. Хочу поставить вопрос так - на плате есть камень с надежностью, ну, 1e-5 и 50 резисторов с надежностью 1e-6 (это близкие к реальности цифры). Возникают 3 вопроса:
1. Какова общая надежность?
2. Что будет с результирующей надежностью, если надежность камня будет 1e-7 (например, программными методами)
3. (Задается после получения ответов на вопросы 1, 2) Стоит ли овчинка выделки?

Ведь PC не из особого теста леплен и если он сбивается, то сбиваются и все остальные регистры.

А если у нас без случайного джампа на Run произошло изменение DDRC и PORTC таким образом, что эти два сигнала выставвились. Ластик в руки и вперёд Конечно тут пора вспомнить, что мы не говорим о 100% ловле сбоев и говорим только о случайных джампах Но тут та собака и порыта:
1. Во многих применениях интересна 100% работа без сбоев, а сбоящие поделки быстро потеряют долю рынка.
2. Вероятность того что в случае помехи сбойнул только PC близка к нулю. А значит тема о случайных джампах бессмыслена.


p.s.
1. Про корпус это сильно, если на реальном объекте на корпус фазу подать или не заземлить, то будет уже не до вашей программы, если она конечно не ракеты пускает. А если она ракеты пускает, то такая ситуация с корпусом невозможна ибо думаю тама проверок на эту тему тьма.
2. Если резет оставить в воздухе и вашу тестовую программу загрузить в MCU, то зажигалку и на корпус вешать не прийдётся Вот где поле непаханное светодиод будет то зажигаться, то гаснуть.

Ну про 100% эт я погорячился - ничто не вечно под луной, но думаю понятно что я имел ввиду

Вот вот. Но эта точность - не 100%. Поэтому всегда сущестует вероятность ситуации, которая "бывает и хуже....Но реже ."...Т.е. проскочит например такая помеха раз в месяц. Ваш девайс глюканет и запустит "ядерную ракету". А Вы придёте измерять помеху. Неделю произмеряете и ничего не найдёте. А наследующий день бах. Опять такая помеха. Поэтому я не понимаю, почему многие из ответивших здесь на форуме так упорно сопротивляются против того, чтобы добавить надёжности девайсу (надёжности в смысле не предотвращения сбоев, а их своевременного обнаружения и устранения). Упираются ногами, руками, рогами и прочими частями тела. Почему?


Писал же уже Вы не четатиль, чтоли?

"А если подумать?
У меня "запуск ракеты" от одной команды невозможен. Ибо у меня железо выполено таким образом, что релюшка, запускающая "ядерную ракету" ( ) включается как минимум 2-мя пинами, сигналы на которых устанавливаются в разных точках программы. Так что даже если на один из пинов в результате сбоя будет подан сигнал "Enable RUN", то на другом-то пине такого сигнала не будет. И Америку не придётся с карты стирать ластиком "


Зачем спрашивать если Вы заранее знаете какой будет ответ при такой формулировке задачи?
Нет. Не стоит.

Но тут есть один нюанс. Что Вы понимаете под надёжностью MCU. Если вероятность выхода из строя какого-то его аппаратного узла, то это одно. А если вероятность сбоя из-за помех - это другое


Дык с точки зрения теории вероятности вероятность любого мыслимого события больше нуля. Весь вопрос в том, насколько больше

Прибор или выполняет свои функции или не выполняет. На самом деле пофиг - отпал резистор или сбойнул камень.

Все-таки, подумайте над расчетом надежности Ваших устройств.



А с точки зрения квантовой теории и немыслимого

Я бы сказал, судя по теме, надежность камня где-то 1е-4



Пробовали. Случайно,конечно. А Вы что подумали?
И ничего страшного не происходит. Если нет свободных ног в Hi-Z состоянии, опять же.



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

Кой-чего вспомнил.
Прошлым летом один мой привод (кстати, движимый тривиальной мегой-8) залило водой. 380!!!
И что? И ничего: аппаратная защита от КЗ не дала начаться безобразию, проц рабочий, флеш целый, eeprom(!) целый, хотя возможность записи в программе есть. Нога какая-то второстепенная выгорела, не помню. Короче, ПРОСУШИЛ - ПОМЕНЯЛ ПРОЦ - ВПЕРЕД! Все живы по сей день.

Вот на это Вам ответит теория надежности.




Ничего подобного. Весь математический аппарат есть. Соответствующий раздел форума недалеко.

Ну кто ещё не "четатиль" это большой вопрос!

Я ж писал в предыдущем своём посте :



Вы читаете, что пишет Rst7? Похоже не всё!

А по поводу стороны проблемы затронутой Rst7 вот есть полезная статейка

Классика теории вероятности -
У блондинки спрашивают:
- Какая вероятность, что ты встретишь на улице динозавра?
- 50%. То ли встречу, то ли нет.

А по статейке выходит, что программа+проц = последовательное соединение блоков?

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

Почему вы считаете что вероятность случайного джампа выше чем выставление одновременно двух сигналов на порте? Ведь возможно ситуация когда вы всё проверили выставили первый сигнал и в этот же момент помеха выставила второй! Всё тупик.


Ну например если на корпус шкафа электроавтоматики попадёт фаза соприкосновение с ним радости не доставит


Неа мы ж тута обсуждаем безошибочные проги, которые ещё к тому же и исправляют баги глючных MCU:) Т.ч. надо брать надёжность MCU и надёжность MCU c меганадёжной прогой, которая ловит баги MCU

Согласен.. Просто надёжность в с смысле отсутствия необнаруженных сбоев от помех и постоянные (в смысле, не временные) отказы отдельных аппаратных узлов MCU - это другое.
Если 2-й параметр MCU и имеет такой же примерно порядок величины как , например, резистор. То первый хуже в 100 000 раз и более. Так что применение описанных мной методов обоснованно





А вы, Господа хорошие, вообще понимаете разницу между надёжностью программ и надёжностью железа? И что теория надёжности программ имеет свою специфику? Мне кажется что нет. Ибо тогда бы Вы знали, например, что понятие износа/старения , применяемое сплошь и рядом в теории надёжности железа, для программ не применимо.


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




Во-во.. И я про тоже... Некоторые Господа пытаются перенести все методики рассчёта надёжности железа и на программу. Забывая о том, что программа не имеет такого понятия как износ/старение

Ну вот приплыли
Мы же обсуждаем так сказать идеальные программы в которых всё предусмотрено(имеются ввиду все ситуации с бессбойным MCU) и каким образом не допустить, чтобы глюки MCU не испортили нам программной идеальности. Т.е как программным способом отловить аппаратный сбой, нарушающий ход выполнения программы или искажающий регистры или ОЗУ. Или я уже что-то не понимаю?


Мне кажеться это финиш.

Дык на всякую хитрую ж..у найдётся х..й с винтом... Это я к тому, что всегда существует верояность такой ситуации, когда уже ничего не поможет. И что? Если помогает в 99,99% случаев, а в 0,01% случаев не поможет. То такая защита не нужна?

Т.е. от ответа на вопрос Вы уклоняетесь. Значит разницу между надёжностью программ и надёжностью железа не понимаете. Тогда о чём тогда вообще вести речь?

Опять же, дело в цене вопроса. И если не трогать CALL / JMP, то остается проблема избавления от LDS/STS. Тоже, имхо, решаемая за счет использования LDD/STD. Но,блин, асм...

Исправил.

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

Откуда такая цифра? Пожалуйста, опишите методику ее получения.

А вот Вам полезная статейка http://www.referatik.com.ua/subject/67/30320/?page=2

Цитата оттуда:"Предварительные исследования показали, что для элементной базы
среднего качества (надежность 0.999 - “три девятки после запятой”) при
оптимальном сочетании скорости получения результата на его надежность в
вычислительной среде теоретически достижима достоверность получения
правильных результатов машинного счета в “двести девяток после запятой” при
замедлении темпа их получения в 300-400 раз [1], что эквивалентно
увеличению надежности до 200 порядков величины при введении сравнительно
небольшой вычислительной избыточности, приводящей к потере
производительности не более чем на 2-3 порядка, что уже на современном
уровне может компенсироваться подбором компьютеров требуемой
производительности."


Моя программа инсталлирована более чем на 11000 девайсах. За 2,5 года эксплуатации сетей с моими девайсами было программами, зашитыми в них, было обнаружено порядка 170 000 сбоев, которые были программой же устранены (эту цифру взял из логов, которые регулярно раз в неделю смотрит обслуживающий персонал и заносит эту инфу в спец.журнал). За это же время вышло из строя 5 девайсов. Но в них вышел из строя не процессор. Из чего и следует эта цифра "более 100 000"


Причём это сбои именно из-за ЭМС. Потому что у нас в лаборатории постоянно гоняется уже 2,5 года таже сеть из 87-ми девайсов, но только "на столе" без воздействия ЭМС. За 2,5 года было только 13 сбоев, обнаруженных системой... Так что программная защита от незамечания сбоев реально работает


Разумеетцо велось и взаимо тестирование девайсов, когда девайс не отвечал другому девайсу (например кварцевый генератор в девайсе от мороза не запустился) или отвечал не правильно. Для этого случая тоже велись свои логи и они в цифру "170 000" не вошли

Итак от LDS/STS избавились!!! (исправил - спасибо '_Pasha')
CALL / JMP - тоже исправимо!!!
Заменой на rjmp. Не реже, чем через каждые 4 кслова (чтоб rjmp дотягивался) ставим ещё один rjmp. И переходим через последовательность rjmp. Например так:
rcall m2proc ;(proc-PC)>4096, а вот (m2proc-PC)<4096
....;
m2proc: rjmp m1proc ; (m1proc-m2proc)<4096
....;
m1proc: rjmp proc ; (proc-m1proc)<4096
....;
proc:
...
ret
На асме это можно сделать с помощью макрокоманд с условной трансляцией. А компилятор C - переделать так, чтоб он про CALL / JMP "забывал". В смысле опцию компилятора такую создать.
Всё это шутка конечно, но в каждой шутке...

А вообще тут уместно будет басню Крылова вспомнить. Лиса и виноград называется. ИМХО многие на методы защиты, здесь поднятые потому ополчились - что сами этого не делают. И базу подводят - мол это я не делаю не потому, что не могу (не додумался, лень, руки кривые). А из идейных соображений!!! И намёками понять дают, что тем кто что-то такое использует - стыдно за это должно быть.

* LDS/STS. Исправьтесь, пока не поздно, а то запинают.
Короче, кривое выпрямляется, становится подобно пикам. Но получше, получше...
З.Ы. А с длинными джампами - проблема. На больших программах - сплошной изврат.
Я вот думаю, если все крутится под многопотоком, проще переделать выход из потока, чем совать rjmp куда ни попадя

Да, есть такая проблема и называется она безопасность программного обеспечения. Способы ее решения зависят от работы девайса.

На данный момент, мы вчастности работаем над этой проблемой. Но сразу оговарюсь, доказательство безопасности мы еще не прошли, но предварительные слушанья показывают, что данные принципы имеют право на жизнь :-) .

Чтобы было понятно, опишу немного пинцип работы девайса. Девайс висит на линии связи и ждет команды. По приходу команды он ее выполняет и отсылает ответ со своим состоянием. Вроде бы, что может быть проще. А нет, у заказчика возникает вопрос, а если ваша система сойдет с ума и начнет немного шалить, т.е. ей приходит команда сделай шаг вперед а она, собака такая, берет и делает два шага назад или наоборот ничего неделает, а в линию связи, эта скотина, отсылает ответ что выполнила команду правильно. Вы можете утверждать с пеной у рта, что этого не может происходить потому что это из области фантастики, НО ВЫ НИКОГДА НЕ ДОКАЖЕТЕ ЭТО СО 100 ПРОЦЕНТНОЙ ВЕРОЯТНОСТЬЮ (случаи перерубания топором проводников питания не расматриваются :-) ). Кстати, заказчик тоже технически грамотный и знает, что со 100 процентной вероятностью этого никто не докажет, поэтому он требует, чтобы вероятность того что система сойдет с ума а со стороны будет казаться что она вполне даже разумна была не выше 10 в -8 степени.

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

Теперь, как работает эта система:
1 - по линии связи приходит команда.
2 - процессор проводит тестирование внутрених узлов микропроцессора (из первого набора функций).
3 - производится межпроцессорный обмен.
4 - выполняется команда.
5 - процессор проводит тестирование внутрених узлов микропроцессора (из второго набора функций).
6 - отсылается ответ в линию связи.

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

Теперь постораюсь каждый пункт описать более подробно:
1) По приходу команды происходит проверка адреса в заголовке пакета (на одной линии висит несколько девайсов). Происходит проверка команды на пренадлежность ее ко множеству всех допустимых команд. Проверяется контрольная сумма пакета. Если все условия выполняются, то команда передается дальше по цепочке.
2) Происходит тестирование внутренних узлов микроконтроллера. К тестам внутренних узлов микроконтроллера относятся (в порядке выполнения): тест безусловных переходов (команды 'jmp', 'call' и т.д.), тест условных переходов и регистра 'SREG' ('brcs' и все ему подобные, также включает в себя проверку всех команд оперирующих с битами регистра 'SREG', 'clz' и все ему подобные), тест первой половины регистров общего назначения (РОН) (к ним относятся те регистры, которые компилятор GCC позволяет изменять при вызове функций без востанавления их первоначального состояния "r18-r27", "r30-r31"), тест второй половины регистров общего назначения ("r0-r17", "r28-r29"), тест оперативной памяти, проверка 'CRC' flash-памяти содержашей код программы, тест группы команд логических операций, тест группы команд арифметических операций, тест групы команд пересылки данных, тест АЦП (на двух точках контрольного напряжения), тест таймеров (удостоверямся что они шелкают в соответствии с установлеными делителями).
3) При межпроцессорном обмене происходит обмен поступившей командой, а также флагами прохождения тестов узлов микроконтроллера.
4) Выполняем команду.
5) Все тоже самое что в пункте 2, только вторым набором функций тестирования. Это сделано для того что бы, если по какой то причине тест из первого набора даст ложное 'OK' на ошибку, то тест из второго набора сможет зафиксировать данную ошибку (звучит глупо, но иногда это срабатывает :-) ).
6) Вот сдесь мы можем утверждать, что у нас все хорошо с заданной вероятностью. О чем и попытаемся сказать в линию связи. :-)

Сделаю несколько замечаний:
1 - Не прохождение тестов из пункта 2 и 5 приводит к переводу устройства в защитный отказ (это такой отказ из которого система недолжна выходить даже при сбросе и востановлении питания).
2 - Не следует сразу же входить в защитный отказ при непрохождении какого то одного из тестов (например: тест оперативной памяти), мы используем счетики непрохождения тестов и если они переполняются то уже переводим устройство в защитный отказ. Это обусловленно тем что микропроцессору свойственно изредка подглючивать, особенно в сложной электромагнитной обстановке. И еще, удачное прохождение теста не должно сразу сбрасывать данный счетчик в нуль, мы обычно делаем так: при ошибки счетчик увеличивается на два, при прохождении теста счетчик уменьшается на один. До скольки расти счетчику, решать Вам.
3 - Если представленная выше цепочка пунктов не выполняется в течении 'n-го' времени то система переводится в безопасное состояние. Выход из безопасного состояния в рабочее происходит по выполнению всех пунктов данной цепочки. Обычно это происходит если одна из линий связи обрывается и соответственно один из процессоров не получает команды, это обнаруживается на межпроцессорном обмене.
4 - По возможности все данные программы которые сохраняют свои значения между вызовами функций должны формироваться динамически. Например, флаги прохождения тестов формируются динамически и если какой то из тестов не прошел, то это будет отловленно на межпроцессорном обмене. Так же в пакет команды и ответа по линии связи надо вводить постоянно изменяемое поле для того, что бы это приводило к изменению контрольной суммы. Да и вообще статические данные склонны к накоплению ошибок.

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

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

И еще, прежде чем что либо доказывать, проводиться привязка программного продукта к классу который напрямую связан с тяжестью состояния оказа. Вот например какое разделение по классам производится стандартом для сертификации бортового авиационного ПО согласно RTCA DO-178B (или его европейского аналога EUROCAE ED-12B):
A ) Катастрофическое - состояние, не совместимое с безопасным полетом и посадкой.
B ) Опасное - состояние, при котором функциональные способности летательного аппарата (ЛА) или способности экипажа справляться с неблагоприятными условиями управления достигают нижних пределов безопасности. Экипаж не может выполнять свои задачи аккуратно и полностью.
C ) Существенное - состояние, при котором функциональные способности ЛА или способности экипажа справляться с неблагоприятными условиями управления снижены до существенных пределов. Имеет место существенное увеличение нагрузки на экипаж или ухудшение эффективности работы экипажа.
D ) Несущественное - состояние, не приводящее к значительным потерям безопасности управления ЛА.
E ) Не влияющее - состояние, никак не влияющие на способности управления ЛА.

Уже начинаете чувствовать, что не все так просто :-) . Так что на этом фоне все высказывания типа: "'watchdog' панацея от всех твоих проблем", в самом общем случае вызывает улыбку.