Здравствуйте всем, для управление отсечным клапаном и расходом газа используется два плк110-224-32Р.
Как можно реализовать горячая резервирование если 1 плк выходит из строя второй брал на себя управления без остановки производства
Вид для печати
Здравствуйте всем, для управление отсечным клапаном и расходом газа используется два плк110-224-32Р.
Как можно реализовать горячая резервирование если 1 плк выходит из строя второй брал на себя управления без остановки производства
Через сетевые переменные по UDP плюс физический вход/выход чтобы обозначить ведущий и ведомый ПЛК.
релейные выходы в параллель.
з.ы. Овен и горячее резервирование это колхоз, имхо....
что бы не мучится с выходами плк поставил модуль МУ110-16Р связь по RS485 интерфейсу.На вход дискретных и аналоговых тоже модули подключены, теперь как можно сделать горячая резервирование
А где используете? Какие есть к этому требования?
Если залип релейный выход, если подвирает аналоговый вход или датчик, если произошла ошибка в вычислениях, например из-за переполнения при делении, да мало ли таких ситуаций - как вы диагностируете ошибку? Как вы переключитесь на резервный ПЛК в случае залипания реле? Если результат вычислений двух контроллеров разный - кто врет? А судьи кто? Третий ПЛК? Истину устанавливаем большинством голосов по мажоритарной системе?
Первый плк управляет реле через модуль МУ110-16Р а второй тупо должен следить за состоянием 1 плк если он зависает берет на себя управление и все других резервировании не требуется
Это что, чисто для отмазки, для успокоения совести и начальства?
Если первый ПЛК зависнет и не освободит шину, то...?
Eugene.A, при чем тут отмазка ? есть два вида резервирования, на уровне ПЛК и на уровне дублирования модулей ввода вывода.
1-й вариант используется тогда, когда модули ВВ имеют функции диагностики, если с ними что-то случается, то вся система будет остановлена независимо какой из ПЛК управляет. Овену до такого уровня несколько далековато. Полное дублирование можно сделать на любом производителе но это всего по два, в том числе и датчики.
Видов резервирования гораздо больше двух. Существует целая дисциплина на эту тему, называется теорией надежности. Так вот она утверждает, что резервирование путем дублирования практически не влияет на надежность. И проблема именно в диагностировании неполадки. Вот как второй контроллер определит, что с первым что-то не так? Зависание - лишь одна причина неполадки, и с ней зачастую может справиться обычный вотчдог. А если контроллер просто начинает выполнять неверные действия, например, у него слетели ретэйны? Уставки приняли значения по умолчанию, и кто решит, кто из контроллеров задурил? Одному втемяшилось одно, другому - другое. Кто их рассудит?
Да мало ли таких ситуаций? Все их никогда не предугадать. Иначе тестирование программных средств просто не требовалось бы.
"В производственной практике встречаются случаи, когда требования к резервированию отдельных элементов системы, сделанные в ожидании улучшения качественных характеристик и получения системы с высокой надежностью, оборачиваются высокой интенсивностью отказов в системе, что вызывает рост объема работ обслуживающего персонала и требует увеличения затрат на приобретение большого количества запасных элементов (ЗИП). "
.........
"В настоящей статье рассмотрены следующие вопросы:
1) показатель надежности – «вероятность безотказной работы»;
2) показатель надежности – «среднее время безотказной работы»;
3) решаемая задача определяет требования к показателям надежности;
4) повышение надежности системы путем резервирования наиболее ненадежных элементов;
5) время восстановления в системах с дублированием элементов оказывает существенное влияние на надежность системы;
6) обоснованность требований на резервирование отдельных элементов системы с кратностью три. "
http://isup.ru/articles/6/1505/
2 ПЛК, 1 набор модулей
2 ПЛК, 2 набора модулей
Где вы увидели больше вариантов ДУБЛИРОВАНИЯ от слова ДВА собственно ????
что касается дублирования на Овен, тут все будет программно и придется попыхтеть для качественной реализации.
Есть системы, где все придумано за нас.
Отказоустойчивость из двух элементов не хуже, зависти от реализации.
Например 2 БП в параллель лучше, чем один.
2 ПЛК, если умеют синхронизироваться лучше, чем один (не про Овен к сожалению)
Если мощности одного БП не хватает и включают два в параллейную работу, то в случае с Овен это не лучший вариант, я бы предпочёл распределить нагрузку между несколькими БП в случае Овен! А так существуют специально предназначенные для целей параллейной работы, умеющие равномерно нагружаться!
Сергей0308, так я и не говорил, что это делается на любых БП. Банальный пример, БП Schneider (не помню точно какие), включили в параллель, при вылете одного БП, так как выходы объединены были, индикатор выходного напряжения горит и на неисправном. Явно БП не предназначены для такой работы.
Когда ПЛК постоянно обмениваются между собой данными. В случае неверных данных управление передается другому ПЛК, при замене неисправного ПЛК на новый из ЗИП программа копируется из рабочего в новый и передается управление новому, если тот был ведущим или не передается и ведущим остается ранее ведомый.
На Овен такой механизм не реализовать.
Вольд это понятно, в БП, у которых указана возможность использования в параллель все учтено в схеме.
Точнее у тех, которые для этого предназначены изначально. У остальных, у которых такая возможность допускается, требуется установить диоды.
БП с возможностью параллельной работы, например, у Mean Well, начинаются с мощности 500 Вт. Сомневаюсь, что кто-нибудь будет применять их для питания ПЛК.
Так кроме ПЛК есть еще модули ВВ
Господа про БП в данный момент не в приоритете можете подсказать как можно реализовать два плк горячего резервирование в случае если зависнить или выйдет из строя один из них
Могу.
По секрету:
Для построения систем с заданной надежностью как минимум следует использовать элементы и архитектурные решения с известной (сертифицированной) надёжностью.
Иначе никуда не уйдёте от сомнений типа: "А как резервировать систему резервирования? И надо ли? Достаточно или мало?"
Ryzhij если перестать пялиться только на Овен то придет озарение, что ПЛК бывают и без входов выходов и даже страшно подумать, без интерфейсов для модулей, а просто с сетевым портом.
Да и модули бывают такие, что сами начинают верещать, что с ними произошло ЧП
Оно конечно, всё бывает ;)
Но кто-то (знать бы кто - уши бы надрал) написал про модули В/В вроде как подключенные к ЦПУ, но удивительным образом невходящие в состав ПЛК.
Это что за "сферический конь в вакууме"?
А те, которые "умеют верещать" они куда "верещат"?
А если им настолько по-плохело, что они уже "ни бе, ни ме сказать не могут"?
У нас DAQ, HMI или SCADA ? Это я к тому, что в DAQ обычно ничего не резервируется. Незачем. И только в DAQ попадаются модули В/В, живущие сами по себе и запросы на которые шлёт виндусовый комп.
Ryzhij, блин, стоят 2 ПЛК в параллель, ведущий-ведомый и один набор модулей ВВ. Один из ПЛК всегда в работе, если что-то случается с ВВ, все останавливается.
Модули ВВ могут диагностировать самих себя, если неполадки с датчиками например, то сообщают об этом в ПЛК. То есть весь контроль работоспособности модуля кроме ессно связи с ПЛК отслеживается самим модулем.
Если отваливается один ПЛК, то второй об этом знает. ПЛК можно заменить на горячую без остановки программы вообще, причем можно воткнуть пустой ПЛК, в него программа будет загружена автоматически.
Никаких SCADA систем, ничего больше, кроме ПЛК и модулей.
а как можно это написать в кодесисе
Возможно автору темы сойдет и примитивное программное резервирование. Если резервный ПЛК хотя бы определит, что программа основного ПЛК перестала выполнять цикл, подаст об этом аварийный сигнал, обесточит основной ПЛК и сам включится в работу вместо основного ПЛК, то это уже что-то. Дьявол кроется в деталях и надо смотреть что там в конкретной задаче творится.
Если ПЛК, конечно, раз в минуту щёлкает релюшкой, то задачу с грехом пополам можно решить. Резервный ПЛК следит за контактом релюхи, прошло две минуты - не щёлкнула, пора брать вожжи в свои руки. Только релюху тоже бы резервировать не мешало. Одной дополнительной релюхой отключать её пригоревшие контакты, а другой начинать щёлкать. А если релюх несколько десятков, и щёлкают они когда ни попадя, в зависимости от погоды и курса маррокканской валюты? А если плюс ко всему куча аналоговых сигналов с нехилой математической обработкой? А основной контроллер не тупо завис, а начал дурака валять? Вот было недавно - сименсовский контроллер перестал отслеживать несколько аналоговых величин, отображал какие-то старые значения, пока не выключили питание. После чего сообщил об авариях датчиков. Вы это всё как собираетесь диагностировать?
Вот вы потратились финансово, проделали большую работу, наладили-запустили, и вдруг сбой. Представляю себе укоризненный взгляд начальника.
Eugene.A написал же в самом начале - при помощи использования сетевых переменных все делается., а там не важно, сколько раз и как клацают релюхи.
Если резервный ПЛК видит отсутствие, неправильные данные в сети, значит надо принимать решение о перехвате задачи.
Как реализовывать, это уже второй вопрос, но точно не по слежке о состоянии реле.
И да, аппаратные решения, точнее сделанные на уровне Firmware контроллеров лучше, так как претензии можно к производителю потом направить.
интересно услышать, как вы представляете запуск резервного плк с того же места технологического процесса, который шел на момент поломки в основном, если сетевые переменные то значит и второй контроллер должен параллельно выполнять программу или как
capzap да, выполняя задачу одновременно синхронизируясь всегда с ведущим и не управляя исполнительными механизмами. Тогда он точно знает в каком положении все исполнительные механизмы. на момент ошибки.
з.ы. а вообще это задача не для Овен.... лучше переплатить и поставить нормальное оборудование для этого.
Значит разобрались и на Овен ни кто систему резервирования делать больше не будет только из-за того что дешевле