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

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

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

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

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

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

Цитата:

---

Сообщение от KSergey

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

---

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

Цитата:

---

Сообщение от krollcbas

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

---

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

Цитата:

---

Сообщение от krollcbas

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

---

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

Цитата:

---

Сообщение от krollcbas

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

---

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

Цитата:

---

Сообщение от krollcbas

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

---

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


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

Цитата:

---

Сообщение от krollcbas

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

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

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

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

---

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

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

Цитата:

---

Сообщение от Ryzhij

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

---

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

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

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

Надо у автора темы узнать, что он понимает под горячим резервированием и какая у него задача. Может это совсем не то о чем пишет Ryzhij. Пытаться сделать горячее резервирование по типу SIEMENS на оборудовании ОВЕН не получится. У SIEMENS горячее резервирование сделано прекрасно, но цены там заоблачные.

Пока народ бился над резервированием ПЛК отвалился МВ110-32ДН. И што ?

Цитата:

---

Сообщение от Валенок

Пока народ бился над резервированием ПЛК отвалился МВ110-32ДН. И што ?

---

Ничего особенного. МВ110-32ДН можно то же зарезервировать.

Цитата:

---

Сообщение от Ryzhij

Да-да, особенно значения внутренних переменных ПИД и быстрых счётчиков :D по модбасу, ну-ну!

---

У ПЛК110 есть Ethernet. можно через него вести межпроцессорный обмен. Не хило получится.

С самого начала, на уровне ТЗ, определяются с объёмом и целями резервирования в системе управления
Само резервирование подразделяется на:
- резервирование ЦПУ;
- резервирование периферии (I/O);
- резервирование каналов управления периферией;
- резервирование HMI и баз данных;
- резервирование каналов связи с верхним уровнем.

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

Вот автор темы и должен прояснить эту ситуацию.

Цитата:

---

Сообщение от Вольд

У ПЛК110 есть Ethernet. можно через него вести межпроцессорный обмен. Не хило получится.

---

Нет, того Ethernet-а, каким располагает Овен, не хватит :(

Цитата:

---

Сообщение от Вольд

Ничего особенного. МВ110-32ДН можно то же зарезервировать.

---

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

Цитата:

---

Сообщение от Ryzhij

Нет, того Ethernet-а, каким располагает Овен, не хватит :(

---

Это смотря какая задача у автора темы.

Цитата:

---

Сообщение от Валенок

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

---

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

Цитата:

---

Сообщение от Вольд

Это смотря какая задача у автора темы.

---

Совершенно согласен. Разумеется так.

Цитата:

---

Сообщение от Ryzhij

Простите, но давайте всё-таки различать "надёжность" и "безопасность"..

---

Давайте. Только вот какая конечная цель надёжности ? Надёжность ради надёжности ? Смысл ?
Зачем нужно надёжное непрерывное управление ? Чтоб просто было ?

Цитата:

---

Сообщение от KSergey

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

---

Вы собираетесь примитивным Watch Dog'ом диагностировать отказ контроллера? Это никак не повлияет на надёжность системы. Да ещё не охватывая дублированием периферию? Вы считаете контроллер самым слабым звеном - на каком основании? Выход из строя любого модуля расширения сведёт всё на нет. А датчики? Нередко именно они - слабое звено. Даже если вы полностью продублируете систему вместе с периферией, это нисколько не повлияет на статистику отказов. Простой пример - у вас одна система измерила температуру и получила 100°С, другая получила 120°С. Какая из них врёт? Ваш Watch Dog сможет определить? Нет? Тогда это влечёт за собой включение третьей системы, арбитра. Которая будет полностью повторять вычисления первых двух, основываясь на данных от собственных датчиков, и по мажоритарной системе определять слабое звено. Т.е. три системы молотят одновременно, в случае совпадения результатов всё ОК, работаем дальше, если результаты разошлись, определяем виновника путём голосования, отключаем его и продолжаем работу, сигнализируя сервисной службе об отказе системы, если все три результата не совпали - запускаем на арбитре программу аварийного завершения работы оборудования.
Потом обнаруживаем недостатки и у этой системы. Добавляем четвёртый контроллер. Потом пятый.
Теперь представим себе стоимость подобной системы. Это у вас управление атомным реактором? Самолётом? Может быть, стоит отказаться от этой затеи? Кстати, ведь надёжность системы зависит ещё и от количества звеньев системы, и их увеличение отнюдь не увеличивает надёжность. Вот намедни рухнул ТУ-95, отказ трёх двигателей. На какие мысли это наводит? Может быть, например, что отказал клапан переключения топливных баков? Смысл тогда в таком резервировании?
А вообще лучше начать с изучения теории надёжности. Всё уже придумано до нас. Очень поучительна в этом смысле история завершения полётов Spase Shattle, в особенности результаты расследования крушений челноков. Весьма занимательно об этом описано Фейнманом, нобелевским лауреатом по физике, участником комиссии. Там как раз речь шла о бортовых вычислительных системах. К концу программы они весьма устарели, а их модернизация влекла за собой полный цикл испытаний, стоимость которого приближалась к затратам на разработку с нуля совершенно нового корабля.

Цитата:

---

Сообщение от Ryzhij

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

---

Цитата:

---

Сообщение от Валенок

Давайте. Только вот какая конечная цель надёжности ? Надёжность ради надёжности ? Смысл ?
Зачем нужно надёжное непрерывное управление ? Чтоб просто было ?

---

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

Цитата:

---

Сообщение от Ryzhij

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

---

Вот тута соглашусь.
Тока не всегда резервирование приводит к снижению издержек.
Где-то близко : Как-то летел на ПНР. Со мной туда же летели коллеги на "параллельный" ПНР. Поговорили. Когда узнали что у меня автоматика на овне - сниходительно посмеялись. У них было на Ми-си. После рассказали куда они обычно там ходят на ужин..

Цитата:

---

Сообщение от Eugene.A

Вы собираетесь примитивным Watch Dog'ом диагностировать отказ контроллера? Это никак не повлияет на надёжность системы. Да ещё не охватывая дублированием периферию? Вы считаете контроллер самым слабым звеном - на каком основании? Выход из строя любого модуля расширения сведёт всё на нет. А датчики? Нередко именно они - слабое звено. Даже если вы полностью продублируете систему вместе с периферией, это нисколько не повлияет на статистику отказов. Простой пример - у вас одна система измерила температуру и получила 100°С, другая получила 120°С. Какая из них врёт? Ваш Watch Dog сможет определить? Нет? Тогда это влечёт за собой включение третьей системы, арбитра. Которая будет полностью повторять вычисления первых двух, основываясь на данных от собственных датчиков, и по мажоритарной системе определять слабое звено. Т.е. три системы молотят одновременно, в случае совпадения результатов всё ОК, работаем дальше, если результаты разошлись, определяем виновника путём голосования, отключаем его и продолжаем работу, сигнализируя сервисной службе об отказе системы, если все три результата не совпали - запускаем на арбитре программу аварийного завершения работы оборудования.
Потом обнаруживаем недостатки и у этой системы. Добавляем четвёртый контроллер. Потом пятый.
Теперь представим себе стоимость подобной системы. Это у вас управление атомным реактором? Самолётом? Может быть, стоит отказаться от этой затеи? Кстати, ведь надёжность системы зависит ещё и от количества звеньев системы, и их увеличение отнюдь не увеличивает надёжность. Вот намедни рухнул ТУ-95, отказ трёх двигателей. На какие мысли это наводит? Может быть, например, что отказал клапан переключения топливных баков? Смысл тогда в таком резервировании?
А вообще лучше начать с изучения теории надёжности. Всё уже придумано до нас. Очень поучительна в этом смысле история завершения полётов Spase Shattle, в особенности результаты расследования крушений челноков. Весьма занимательно об этом описано Фейнманом, нобелевским лауреатом по физике, участником комиссии. Там как раз речь шла о бортовых вычислительных системах. К концу программы они весьма устарели, а их модернизация влекла за собой полный цикл испытаний, стоимость которого приближалась к затратам на разработку с нуля совершенно нового корабля.

---

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

То о чем написал автор темы в своем первом посте не является классическим горячим резервированием. То что он хочет (если один ПЛК отказал, то управление берет на себя резервный ПЛК) легко реализуется на оборудовании ОВЕН. Не понятно из-за чего весь сыр-бор вдруг разгорелся. krollcbas, вы первый пост в теме внимательно читали ?:eek:

Дьявол, как всегда, в деталях.
Что топик-стартер подразумевает под "управление берет на себя резервный ПЛК"?
А что происходит с технологическим объектом во время перехода?
У термина "горячее резервирование" есть вполне определённое содержание, так же как и у понятия "тёплый резерв".
Так что ХЗ, что имеет ввиду топик-стартер.

Все намного проще. Автор темы использовал выражение горячее резервирование для солидности и кое кто на это повелся.:D