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

в чем вопрос то.как работает резервированная система или....

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

Значит - как запрограммируешь?
Вопрос был: "зарезервированный" контроллер 1) спит, или 2) параллельно работает, не участвуя в процессе.

во первых надо бы назвать производителя железа.во вторых резерв бывает софтовый и на уровне железа.это важно.программируется если рассматривать абстрактный аппарат просто-как обычно 1 из тех что находится в рабочем режиме а не в Standby.при аварии прога из рабочего переливается в резервный.тут много особенностей у разных производителей реализация имеет особенности.Правильно реализовано у SIEMENS, MITSUBISHI ,OMRON- у них на уровне железа .разница в быстродествии ну и в способе организации с переферией.сетки там разные и как правило свои.смотри на табличке все расписано.удачи

Old, а откуда табличка взята?
Просто, в ней какие-то не совсем достоверные данные представлены.

это презентация одного из представленных производителей.а что не совсем так.скажи посмотрим.я так понимаю про омрон

Понятненько, на лицо добросовестная конкуренция
Претензии не только по Омрону, просто по еще одному лень скачивать документацию и рыться в ней для полной уверенности.
По омроновскому блоку:
Optional memory: 48 Mb (в действительности 512 Mb)
Switchover time: 520 ms (это время первичной инициализации при подачи питания на сборку): в действительности время переключения между процами 0,5 мс, кроме ошибок связаных с WDT там 0,5 мс +время на диагностику неисправности.
I/O Device point: 5K : в действительности 5120 точек это только память для дискретных модулей размещенных в корзинах контроллера, у аналоговых и удаленных вх/вых свои области память (кстати у Сименса и GE это почему-то указано).

НУ не сильно то и обманули.

Ну, да совсем чуть: 520 мс и 0,5 мс - разница не существенная для систем резервирования.
Кстати, какой смысл приводить в качестве доказательства старую (выпущенную в момент выхода серии) спецификацию, не содержащую обсуждаемых данных?
Могу по новее подкинуть: CS1D Manual

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

Да же не заглянув в него.

Первый, второй, третьий - это решать должен сам клиент на основании предоставленных ему достоверных данных.

Последние сомнения в авторстве этого сравнения начинают исчезать. Можно было бы вспомнить об уважении к клиентам и понятии недобросовестная конкуренция. Но видимо кризис. Да и не в первый раз на этом ловим.

откуда дровишки? из штаб квартиры Омрон или М.?

Ну, хоть на этом спасибо.

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

Последние сомнения в авторстве этого сравнения начинают исчезать. Можно было бы вспомнить об уважении к клиентам и понятии недобросовестная конкуренция. Но видимо кризис. Да и не в первый раз на этом ловим.

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

Возвращаясь к истокам.

Для болей-менее серьезного управления нужна предистория, на пример, для того же ПИД регулятора. Исходя из этого есть два варианта как это обеспечить:
1) второй контроллер (процессор) работает в том же режиме что и основной, но не выдает управляющие сигналы до определенного момента.
2) второй контроллер (процессор) гоняет только самодиагностику и синхронизирует определенные данные с активной станцией. при обнаружении сбоя запускает программу, которая начинает работать с синхронизированными данными.
"Какой из вариантов" зависит от большого количества "если" при реализации самого "железа".

Именно так. Это реализуется довольно просто на любых ПЛК.

Да не все так просто, как хотелось бы. На уровне КОНТРОЛЛЕРОВ организовать "горячее резервирование" ОЧЕНЬ НЕПРОСТО!!!! Простой пример - необходимо организовать доступ к элементам в/в, причем ОДНИМ и ТЕМ ЖЕ. Думаю, (без учета КОНФИГУРАЦИОННЫХ проблем с одними и теми же модулями в/в) с элементами ВЫВОДА это ПРАКТИЧЕСКИ НЕВОЗМОЖНО (со входными элементами, если ОЧЕНЬ постараться, то как-то можно). Возможно, вместо КОНТРОЛЛЕРА имелся ввиду ПРОЦЕССОР, т.е. двухпроцессорный контроллер имеет возможность РЕЗЕРВИРОВАНИЯ. Это совсем не сложно, но не обеспечивает резервирование ввода/вывода. При процессорном резервировании используются РАЗНЫЕ методики, включая и резервирование памяти. "Гарвардская схема" допускает разные подходы к копированию/дублированию команд/данных, обсуждать которые нет никакого смысла, т.к. они хорошо описаны в литературе.

Именно так. Это реализуется довольно просто на любых ПЛК.

это не так просто как заявляется-первое.

На уровне КОНТРОЛЛЕРОВ организовать "горячее резервирование" ОЧЕНЬ НЕПРОСТО!!!! Простой пример - необходимо организовать доступ к элементам в/в, причем ОДНИМ и ТЕМ ЖЕ.

это ваще просто.доступ то осуществляет контроллер который не спит.нет тут никаких засад.так что вы о чем.

Уважаемый Old !
Контроллер - это не только ПРОЦЕССОР, это еще и система Ввода/вывода. Если она "на борту контроллера", то Вам ПРИДЕТСЯ дублировать ВСЕ входа/выхода, и ОПЕРАТИВНО переключаться на работающий Вход/Выход. Я не думаю, что существуют (в ШИРОКОМ доступе) контроллеры, которые АВТОМАТИЧЕСКИ переключаются на рабочий вход/выход (прозрачно для программиста), причем коммутация ДОЛЖНА быть такая, чтобы данные ОДНОВРЕМЕННО поступали/уходили с рабочего входа/выхода. Вы хоть прикиньте схему коммутации-то....
Если контролер имеет модули в/в на ВНУТРЕННЕЙ шине, то тут вообще ТРАНДЕЦ - организовать доступ одного к модуля другого - НЕРЕАЛЬНО, можно только НАВОРОТИТЬ схему внешней переброски данных, ПРИЧЕМ ВСЕХ !!!! Нереально это...
Если модули висят на общей шине (типа ЛОН или RS-485), то тут встают КОНФИГУРАЦИОННЫЕ проблемы, которые ПРАКТИЧЕСКИ НЕРЕШАЕМЫ.
Так что говорить можно о резервировании CPU и памяти внутри ОДНОГО контроллера. Тут проблем НЕТ, но это не РЕЗЕРВИРОВАНИЕ контроллеров,
т.к. НЕ РЕШАЕТСЯ проблема резервирования в/в, отказы которого и составляют 90% от отказов системы.

Информации маловато, для чего это делается.
Может есть смысл посмотреть в сторону SafetyPLC?

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

Может книга Ю.Н. Федорова, "Основы построения АСУТП взрывоопасных производств." т.1, Вам поможет? Там подробненько все описано.