Глюк в голове произошёл.. с кем не бывает

Ну дык и как насчет предоставления "дезактевированного" варианта хранения таблиц
CRC16 ?
или за свои слова мы не очень отвечаем ?

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

Класс

Я уже весь в предвкушении


Пжалуста (блин, все свои Ноу-Хау задарма раздаю )

............................... Блок данных №1 ....................
$0F00: 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx
$0F08: 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx
$0F10: 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx
$0F18: 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx
$0F20: 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx
$0F28: 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx
$0F30: rjmp Crash
............
............................... Блок данных №4 ....................
$1000: 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx
$1008: 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx
$1010: 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx
$1018: 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx
$1020: 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx
$1028: 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx 3xxx
$1030: rjmp Crash
............

где вместо крестиков Вы и пишите свою данные (хоть таблицу, хоть... что хошь)

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

Кстати, еще хотелось бы услышать Ваше объяснение на тот случай если одновременно со сбоем
PC произойдет сбой при считывании данных из области флеш...


Ну а что бы Вам думалось веселее, давайте рассмотрим в заявленном
контексте две инструкции: ICALL и IJMP...
Никаких мыслей еще не появилось ?

Ага..Щаззз....А Вы потом этот код в свой проектик или в свою кандидатскую... А мне , как изобретателю кушиш с маслом

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


Давайте всё же не будем валить всё в одну кучу и будем "отделять мух от котлет". Здесь тема только про "ловлю" случайных джампов

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

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

А при чем здесь эмоции ?
Вы автор топика, и я Вам задал кучу вопросов, и ни на один из них вы толком не ответили...



Ну дык, как?
Инструкции AVR мы уже изучили ?
примеры применения будут ?

to Дон Амброзио:
Почитал ваши предложения. На мой взгляд, все они крайне запутанны, сложны, плохо расширяемы, непереносимы между процессорами, требуют полного знания ассемблера и "неподключаемы" к сторонним библиотекам. Т.е., если у вас есть прошивка, которая тиражируется на миллионы изделий, и относительно "проста", то в ней все это можно использовать. Однако если тираж небольшой, то все это крайне затруднительно...

Я Дон Амброзио за формат таблиц cpi Rd,K благодарен. Поэтому вам, 'singlskv', за него отвечу. Хотя 'Дон Амброзио' уж вам и так всё подробно расписал.

Вот как я бы написал (специально пишу не оптимально, а просто чтобы работало - оптимальный код он денег стоит):

Если кто это применять будет. При получении зарплаты прошу меня не забывать! (шутка)
С CRC всё элементарно ведь. Сам-то вы, 'singlskv', рассчёт CRC из аппноутов берёте что-ли? Или вы хитрее гораздо. Типа шпион промышленный? Секреты у всех выведываете...


Один д. может столько вопросов задать, что 100 умных не ответят.

Только без обид! 'singlskv' - заранее прощения прошу.

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

В принципе могу с вами и согласится. Т.к. сам всегда CRC32 FLASH в основном цикле считаю (по слову за раз - см. мои предыдущие посты). Но ни разу не сработало.

Насчёт защиты от несанкционированного запуска бутлоадера. Я бы предложил написать так:

Если предположить, что аварийно опасных команд 8 шт. А у R17, в остальных частях программы, значения от 0 до FF равновероятны. То вероятность "не попорчивания" FLASH при случайном прыжке для AVR с 128 кБайт памяти будет: (1-(8/65536)/256)*100%=99.9999523%. Что существенно выше, чем надёжность CRC16 с производящим многочленом 0x11021, которая составляет 99.9984% для пакетов данных длиной более 17 бит (Р.Л. Хаммел "Последовательная передача данных").

Если код во флеш разместить, то он и выполнятся медленно будет. Примерно с той-же скоростью, как у AVR. А у мелких АРМов разве защита кода есть? Я считал, что нет. Но м.б. у каких-то и есть - просветите.

Это Вы говорите как специалист по части применения поледних?(шутка)
Было бы интересней, если бы Вы привели код или пути решения поставленной задачи [deleted]

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



Задача сия точного решения не имеет. Можно только итерациями бесконечно приближаться, асимптотически, к прямой, которая есть "надежность 100%". Хотя полсотни резисторов, рассыпаные по плате имеют вероятность выхода больше, чем камень Рассмотрите необходимость решения данной задачи с точки зрения расчета надежности.

[deleted]

По теме ещё будут сообщения?
Или давайте закроем тему.

Модератор.

Кстати насчёт CRC. Если, например, иногда нужно бывает 1 слово в защищённом CRC блоке ОЗУ изменить. Я CRC всего блока не пересчитаваю - это долго. Я просто ещё одно слово завожу рядом. И его одновременно меняю, так чтобы CRC всего блока не изменился. Это хакерский приём конечно. И кусок программы которая так делает я принципиально демонстрировать не буду. Ток кто в CRC разбирается - сам запросто такое напишет. А тому, кто не разбирается - такое лучше и не знать.

Извините конечно но никогда не могу пройти мимо подобных заявлений -
"Ток кто в CRC разбирается - сам запросто такое напишет. А тому, кто не разбирается - такое лучше и не знать".
2 galjoen - НУ чтож гордитесь! Вы гениальный!
Не думаете , что если все так будут делать - но всё мы в конечном итоге деградируем ?

Можна ещё один маленький уточняющий вопрос?


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

Прошу прощения если меня не так поняли. Не хотел никого обидеть. Я имел в виду, что хакеров-крекеров и так хватает. Это они в программах (для компьютера) таким способом защиту кода с помощью CRC ломают. И мою защиту так сломали (когда-то давным-давно когда я еще молодой-неопытный был). И помогать им в этом я не хочу. В смысле тем, которые этого не знают (пока). А по моему мнению, хакеров со знаниями теории - мало.
Ещё раз простите - в следующий раз при написании поста буду осмотрительней.

Мда-с...

Как защититься от случайного выполнения записи в boot-loader.
Это не то,что приснопамятное засорение EEprom - тут у нас по питанию все ОК.
1. Заводим в основной программе себе нулевой регистр и не трогаем его ни при каких обстоятельствах. Только clr NullReg после сброса.
2. Кусок кода по записи в SPMCR не имеет точки входа.


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

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

_Pasha

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

WRITE_EN - это что за зверь? Код который в SPMCR пишется? Так "запись в младшие пять разрядов регистра SPMCR значений, отличных от 10001, 01001, 00101, 00011, 00001 не вызывает никакого эффекта". Т.е. команда spm и так не запустится. А если это код конкретной операции, и на каждую у вас своя команда spm - это не лучший вариант. ИМХО желательно, чтоб во всей FLASH всего 1 команда spm была - кол-во аварийно опасных при случайном изменении PC команд меньше будет.


Да. Там меньше 45ns нет. Но может и потом появиться - просто атмел приятный сюрприз сделать хочет. А если xmega с периферией на половинной работать будет - кому тогда она нужна? Неужто атмел это не понимает.

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


Это Вы мне ?

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

Дык, по теории - это уже конвеер..


Это фигня и в реальной жизни не спасет на самом деле.
Представьте, что в слуйчайный момент времени, в R16 находится случайное значение
и происходит случайный прыжек на sequence
OUT SPMCR, R16
SPM
и страница флеш отъехала.

Вывод - по настоящему защититься от слета флеш памяти можно:
1. удалив из кода все SPM команды.
2. проверять целостность программы и восстанавливать ее.

Часть темы вынес сюда:
http://electronix.ru/forum/index.php?showtopic=43447&hl=

Дык я поэтому такой оптимистичный, что R16 перед этим колбасили так, что правильной команды spmcr не дождется



Нет,понятно, что лучшее средство от седины - это лысина. Вопрос только о снижении вероятности налета на разрешенный spm. Т.е. юзать 4-х тактовый зазор.

Вот теперь понимаю свой просчет. Наверное, аукнется. Надо было, к примеру так:


Короче, жаль, что 1 такт съелся переходом
А еще можно привязаться, например, к тикающему таймеру. И пытаться код команды в SPMCR считать оттуда.

2 bodja74: Спасибо, мне все ясно.

2 all: Вот я считаю, что при соблюдении вышеозначенного порядка действий и достаточной сложности (вопрос открытый) инициализации вероятность налета на грабли можно снизить. Конкретнее скажу после инъекций забытой теории вероятности.

P.S. Насчет безопасного формата данных cpi Rd,K - отдельное спасибо. Вот в пиках, например, такая фича архитектурой задана.

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

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


А я случайные джампы ловил.. Достаточно потрыкать пьезозажигалкойс присоединённым в её "жалу" проводом


Писал же уже выше...Но Вы видно не читатель..Повторю для Вас:

OUT R17 , SPMCR
;---------------
SBRS R16 , 7 ; Проверяем флаг запроса на запись
RJMP CRASH
;-----------------
SPM

Дык Вы тоже не читатель, получается. BTW, интересно Ваше мнение по поводу написанного мной чуть выше.

когда девайс слетает, и стоишь перед фактом ехать в командировку в мухосранск , оптимизм быстро пропадает...
На удачу в таких случаях лучше не надеяться, шанс получить "правильное" значение для spmcr ничуть не меньше шанса "неправильного" значения.

1. А если мы попадем уже после этой самой проверки?
2. Команду на запись страницы во FLASH не запись в регистр SPMSR даёт, а команда spm. Запись в регистр SPMSR влияет только на то, что по spm делаться будет.

Вот:

Пример кода там-же.
Конечно если вы вероятность срабатывания защиты в 99.9999523% и в грош не ставите - тогда я пас.

А если подумать головой?

RJMP CRASH
;--------------
Input_in_Code_Writing :
OUT R17 , SPMCR
;---------------
SBRS R16 , 7 ; Проверяем флаг запроса на запись
RJMP CRASH
;-----------------
SPM


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

А его выставляет совсем другой поток. И он(этот флаг) автоматом сбрасывается по тайм-ауту..

Так что....Ещё раз повторю: думать надо прежде чем писать программу


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

Вот именно, думайте, думайте и еще раз думайте. Ваш код тоже не дает 100% гарантии защиты от перетирания флеша.
При случайном прыжке расклад регистров тоже случайный! Вы почему-то это упускаете из виду.

вероятность того что программный флаг при случайном прыжке взведен - 50%.

В принципе согласен. Только я бы переписал это так:
RJMP CRASH
;--------------
Input_in_Code_Writing :
OUT R17 , SPMCR
;---------------
CPI R16 , 1<<7 ; Проверяем флаг запроса на запись
BRNE CRASH
;-----------------
SPM
В этом случае вероятность срабатывания защиты в 128 раз повышается. См. мой предыдущий пост. А тактов - столько-же.

А если проверять перед записью не один регистр, а два, то вероятность случайной записи можно уменьшить в 65536 раз

Пример код

RJMP CRASH
;----------------
OUT SPMCR , R16
;----------------------
; Проверяем, а допустима ли запись
CP R17, R18 ; 2 контрольных регистра разрешения записи
BREQ PC+0x02
RJMP CRASH
;-----------------
SPM

Вот и посчитаёте: какова вероятность, что в обоих регистрах R17 и R18 будет записано одно и тоже число


Т.е. из-за 99,99% Вы и напрягаться не будете , чтоб подумать?


Это как написать программу, можно вообще сделать 100%. А у меня это вероятность менее 1%


Вот вот... И я про тоже.... Как замаячит такая перспектива я лучше "сломаю голову" над программой сидя дома за письменным столом, чем потом кайфовать где-нибудь на Таймыре или Чукотсуом полуострове срочно исправляя глючащее устройство


Потому что заказчику не объянишь, что это мол я не сделал ни каких программных защит-ловушек из -за того, что это: "слижком сложно", что "СИ-компилятор не поддерживает такие конструкции"

Но зато "счастливого" владельца глючящего девайса можете утешить тем, что программа написана на языке высокого уровня СИ (во крута ) и что она переносима и не привязана к конкретным архитектурным особенностям данного процессора

Не успеем - там 4 такта всего. А две проверки по 1 такту и два brne тоже по 1 такту =4 такта.
Можно только добавить ещё один sbrc перед самим spm, и этим уменьшить вероятность ещё в 2 раза.

Вообще-то вероятность абсолютно такая-же, как и у того, что в один регистр будет записано какое-то определённое число.

+1
А я вообще считаю, что для АВР смысла нет на C писать. В программах управления чем-либо (ИМХО АВР только в таких применениях с АРМ конкурентоспособен) переносимости это не добавит т.к. всё к регистрам ввода-вывода привязано. Как встроенные функции C (сделанные такими для переносимости) например с USART работают - знаете. Неужели кого-то они устраивают! Всё равно нормальные люди сами пишут. Ну и где после этого переносимость?

Подскажите, пожалуйста, как Вы определили, что сбился PC, а не R16?

PC - это священная корова!!!

Ну ещё мог сбиться бит Z из регистра SREG. Для проверки чисто сбоя PC всего 1 команда нужна rjmp сам на себя. Собака есно при этом запрещена д.б.
Но это ничего не меняет. Если предположить, что это R16 сбивался, то сбой регистра R30=ZL или R31=ZH перед ijmp или icall к тем-же результатам приведёт, что и сбой PC. Как и сбой в ОЗУ перед командой ret. Или сбой указателя стека.
Я считаю, что тема эта гораздо шире стала, чем просто сбои PC. Тут защита от сбоев вообще рассматривается. Неправильно написал. Д.б. так - минимизация последствий аппаратных сбоев. Или минимизация вероятности того, что аппаратный сбой тяжелый урон нанесёт.
Да, ещё добавить забыл, что АВР всего-лишь как пример рассматриваю. Так сказать - виртуальный микроконтроллер.

0. Перестаете думать, как работать со сбоящим дерьмом, так, чтобы скрыть от пользователей, что они имеют дело с дерьмом.
Ознакамливаетесь c приложением. По результатам ознакомления возможны два варианта
1. Привлекаете фирму Atmel за выпуск сбоящего дерьма не соответсвующего заявленным характеристикам.
2. Собираетесь с умом и думаете о том, как вам удалось создать сбоящее дерьмо.

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

А обеспечить отсутствие последствий сбоев чисто программными методами невозможно. Гораздо дешевле и надежней аппаратные средства (внешние и внутренние блокировки).

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

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

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


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

А какие проблемы бывают на объектах здесь могут многие рассказать. Так что тема актуальна.

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

+1000
Очень помогает.

Понимаете в чем проблема - чтобы кого-то утешить, надо еще этого кого-то иметь. Если я буду писать прошивку год и а потом каждой пожелание клиента вносить в нее месяц - то утешать просто некого будет. Мои девайсы не будут продаваться...

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

Я отчетливо понимаю, что есть области, где необходим такой подход, как описываете вы. Но их сравнительно немного...




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



offtopic
Кстати, что это за фольклорный персонаж "Дохтур туамосец" - тут его пару раз упоминали. Гугл выдал только пару ссылок на телесисы...

Пока народ разогрет всем этим бредом... прошу отнестись серьезно к тому, что я хочу сказать.
Хочу детально проработать вопрос по spm и целостности флеша, для чего сваять простенькую модель:


*) 0xFFFF вариант для меги 64. Для более мелких - надо учесть размер шины адреса

Методика:
1. забили весь флеш, чтобы 0xFF было минимум.
2. Запомнили CRC
3. ставим эту байду на несколько часов
4. Отвечаем 2 defunct

ВОПРОС О СОСТОЯТЕЛЬНОСТИ МОДЕЛИ:
покакит ли это все с псевдослучайными числами с нормальным распределением?
Очень жду комментариев.

Устойства "сглюкивающие" раз в день не имею права на существование в принципе. Должна-же быть какая-то нижняя планка качества. Ни одно из микроконтроллерных устройств работающих в нормальной для контроллера среде не должно глючить, чаще, чем наработка на отказ отнормированная производителем. Если указанные условия не приемлимы, или не приемлимо вообще само слово отказ, то эта проблема решается совершенно другими способами. Высасывание из пальца одной из множества гипотетически возможных причин сбоя и мужественная борьба с ней софтовыми методами с принесением в жертву качества, надежности и сопровождаемости кода совершенное умопомрачение.
Тут поминалась Ядерная Энергетика? Так получилось, что я с ней сталкивался. Ядерный реактор это именно тот случай, когда последствий от отказов быть не должно. Подчеркиваю - последствий а не отказов, кои нормируются. Сделать это тяжело и безумно дорого. Что касается софта, то написанного в рекламируемом здесь стиле софта там не будет близко и на пушечный выстел. Причина проста - софт должен быть верифицирован, как минимум по формальным признакам - написан с использованием инструментальных средств минимизирующих вероятность ошибки человека, в конструкциях языка не должны быть использованы выражения могущие вызывать потенциальные неоднозначности, данные должныбыть четко структурированы, инструментальные средства должны быть в свою очередь проверены временем и достаточно консервативны, разработчики софта должны, извините, соответствовать определенному образовательному цензу...

При всем этом совершено очевидным является тот факт, что устройство может не выполнить свою функцию в нужный момент времени. Посему резервирование прежде всего. неезервированных вещей на энергоблоке всего несколько, практически корпус реактора и кусок трубы с клапанами до насосов и прочего уже резервированного оборудования. Это нерезервированное оборудование и является основным ноухау, стоит сумашедших денег, защищается от внешних воздействий а внешняя среда защищается от него...
Со всем остальным проще - собирается почти по месту насосы можно взять на Украине, двигатели к ним во Франции, систему управления в Германии.... На уникальное оборудование никто старается не закладываться. Только вот резервировние там не шуточное. Например (намеренно подальше от электроники, дабы избежать скатывания в часности), для работы реактора в штатных режимах достаточно одного Главного Циркуляционного Насоса. Во всех нештатных - двух. Там их четыре. Три работают всегда, один стоит в холодном резерве, на регламентном обслуживании.... Двигатели насосов надо питать - начинаем резервировать электропитание - к энергоблоку подходят две линии электропередач от других электростанций (это не считая соседних своих энергоблоков), при каждом энергоблоке три собственных аварийных дизельгенератора (размером с дом), но для останова реактора хватит одного. Если все это хозяйство вдруг отказало, то снаружи энергоблока есть штепсель для подключения предвижного дизельгенератора, которого хватит на питание РЩУ и заглушение реактора. Если вдруг соляку из всех подвижных слили , то на ГЦНах стоят многодесятитоные маховики - совсем уже реактор не расплавится даже при сверхаварийном останове. А если расплавится, то он стоит в Гермозоне, которая в свою очередь расплавившись стечет на 27 метров вниз в выложенный керамикой бассейн и будет там доооолго кипеть.

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

И это правильно, - поставьте себя на место директора. Людей и поставщиков тоже надо резервировать. На одного сложно полагаться.

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

А надо сказать, что сейчас я бы в 10 раз лучше написал. Изменились и подходы и аппаратная часть.

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

И, тем не менее, если человеку очень захочется свалить такую систему - он ее свалит. Пример - ЧАЭС.

А вообще, если кого интересует, есть у меня исходные технические требования (украинские, правда) к оборудованию пожарной безопасности на АЭС. Могу дать почитать, документ не секретный, может оттуда почерпнете, чего надо делать, и чего не надо...

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

Интересует. Правда я и свои (Российские) имею, поскольку оборудование иcпользуется на трех AЭС, в том числе на Южноукраинской и на одну проектируется. Но не систем пожаротушения. Интересует.
Ну а к системам пожаротушения, правда не на энергоблоке а вообще даже за пределами Ядерного Острова я претензии имею - ложно сработала задув газом и порошком полэтажа здания, где стояло мое оборудование. Но там что-то достаточно общепромышленное стояло. На энергоблоках совсем другие, по крайней мере управление не пласмассовая коробочка со светодиодиками на стене, а стойка высотой под метра два с немерянной красы Windows GUI.