Горячее резервирование

[KSergey]

Доброго времени суток, уважаемые форумчане!
Имеется проект, по условиям которого необходимо горячее резервирование.
Используем ПЛК110-60 2 штуки. Как сообразить на них горячее резервирование?
Допустим, будем использовать по одному выходу на контроллерах для мониторинга их работы: идут импульсы - всё нормально, нет - передаём управление на резервный контроллер, при этом отключая выходы основного.
Встаёт вопрос: предполагается использовать несколько модулей МВ110-32ДН. Как организовать их опрос с двух контроллеров? Как на резервном контроллере отключить ModbusMaster до тех пор, пока основной не выйдет из строя?
То есть в нормальном режиме мастером сети RS485 является контроллер №1, а в случае отказа мастером становится контроллер №2.

[ASo]

Используйте иные системы. Но это - не ОВЕН.

[KSergey]

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

[Николаев Андрей]

Это задача действительно для другого уровня систем...
Но уж если решились на костыли:
1. В Конфигурации при настройке обмена - можно выбирать обмен по команде, не постоянно. А в программе проверяете условие (если я должен опрашивать модуль) - даете команду на опрос.

Чтобы еще повысить в этой ситуации предсказуемость - можно поддержать работу ПЛК ModBus Master не из конфигурации, а в коде. Сложнее, но более гибко.

[Вольд]

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

Задача не тривиальная, но вполне реализуемая. Порты RS-485 ПЛК110 свободно программируемые. Используя библиотеки SysLibCom или UNM надо написать код мастера сети RS-485 для ПЛК-Primary и ПЛК-Backup. При запуске системы ПЛК-Primary начинает обмен по сети со Slave (К1 замкнуты). ПЛК-Backup стоит чисто на приеме и следит за обменом. Если обмен по сети идет нормально, то ПЛК-Backup ведет прием откликов от Slave синхронно с ПЛК-Primary. Если ПЛК-Primary вдруг прекратил обмен по сети, то
ПЛК-Backup фиксирует эту ситуацию, отключает ПЛК-Primary от линии связи и берет обмен по сети на себя.

[Вольд]

Вольд,
такая канитель вполне себе будет работать, если слейвом будет какая-нибудь панель оператора, которая в обычной эксплуатации почти не используется и не является ответственным звеном.
У меня в одной из систем (S-400H) была похожая тема, там Profibus переключался на тот контроллер, который становился Primary, на шине была панель OP9

Почему только панель, если ПЛК-Primary и ПЛК-Backup ведут синхронный прием от Slave ?

Резервированные системы ставятся как "ответственные решения", например на атомных станциях.

Я не думаю, что автор темы собрался ставить ПЛК110 на атомную электростанцию. Надо быть сумасшедшим чтобы решиться на такое.

Ну какое это ответственное решение? Иллюзия, усложненная нетривиальным программированием.

Никаких иллюзий, вполне рабочее, бюджетное решение.

И почему Вы ПЛК-Backup сделали "хозяином" реле?

А кто же может еще быть "хозяином" реле, если ПЛК-Primary вдруг откажет ?


То что я предложил вполне реально, а все ваши но возникли из-за невнимательного прочтения моего предыдущего поста ?

[Вольд]

Прочел я внимательно. Был бы рад поучаствовать в тестировании Вашего детища)

Ни о каких агрегатах, где критично управление и не допускается потеря связи - речи быть не может!
А если это так, то о каком резервировании в управлении ведется речь? Зачем?
Вы уверены что при переключении после длительного простоя ПЛК110 начнет обрабатывать шину?
У меня встречаются случаи что ПЛК110 работает, а шина не опрашивается, помогает перезагрузка...

Если Праймари откажет, то Бэкап должен превратиться в праймари, а при исправлении Бэкапа(бывшего праймари), должна быть возможность обратного переключения.
Попробуйте придумать условие при котором каждые 5 мин будет переключение с паймари на бэкап и наоборот (некий тик так).
А как насчет того, что код контроллера должен быть одинаковым для обоих ПЛК и при условии переключения функции у контроллеров должны меняться.
Вы должны понимать из чего увеличивается надежность...

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

Писанины много, толкового мало.

[Ryzhij]

Горячее резервирование процессоров, кроме переключения входов-выходов, и каналов связи подразумевает прежде всего синхронизацию внутренних данных - состояний таймеров, счётчиков, ПИД-регуляторов и прочих API.
Как это видится под CoDeSys?
/пошёл за попкорном/

[Дмитрий Артюховский]

Горячее резервирование процессоров, кроме переключения входов-выходов, и каналов связи подразумевает прежде всего синхронизацию внутренних данных - состояний таймеров, счётчиков, ПИД-регуляторов и прочих API.
Как это видится под CoDeSys?
/пошёл за попкорном/

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

[Ryzhij]

Да-да, особенно значения внутренних переменных ПИД и быстрых счётчиков по модбасу, ну-ну!
То-то солидные фирмы для этого оптические патч-корды в спец.модулях используют, да ещё спец наборы фирмваре применяют...
С дуру и с жиру, видать...

У Овен-овских ПЛК есть свой сегмент рынка.
Системы с горячим резервированием - это из другой оперы.