Оператор жалуется: «после переключения на резервный ПЛК уставки PID другие, каскад ведёт себя странно». Наладчик показывает, что на FAT переключение прошло - лампочка «активный» перескочила за две секунды. Но на FAT не проверяли загрузку проекта с изменёнными RETAIN, не гоняли сценарий «активный умер в середине записи рецепта», не сравнивали версии уставок в паре CPU. Резерв есть в схеме и в опросе SCADA, а по факту - два контроллера с похожими, но не синхронными данными.
Разбираем резервирование ПЛК на уровне, который нужен интегратору: горячий и тёплый резерв, что должно совпадать между активным и standby, как ведут себя уставки и retain при отказе, что обязательно прогнать на FAT до выезда на объект. Не маркетинг «пят девяток» и не обзор всех вендорных режимов redundancy - практика стенда и пуска.
Горячий резерв - два контроллера (или пары CPU/I/O), один активный, второй принимает управление при отказе с минимальным простоем. Критично: одинаковая версия проекта, согласованные retain и уставки, определённое поведение выходов при переключении и при рассинхроне. Синхронизация уставок - либо общая база с записью с обеих сторон по регламенту, либо механизм redundancy с передачей данных производителя, либо жёсткое правило «источник истины - активный, standby только копирует».
На FAT проверяют не только «переключилось», а сценарии: отказ активного под нагрузкой, отказ связи между парой, рассинхрон после online-изменения, восстановление бывшего активного, поведение при потере питания на одном CPU. Без этих тестов резерв - декорация в однолинейной схеме. Watchdog и время цикла влияют на момент переключения не меньше, чем надпись «hot standby» в паспорте.
Не каждая насосная нужна 2oo2. Но где простой линии измеряется часами выручки или где удалённый объект без круглосуточного наладчика, закладывают резерв CPU или полный дубль шкафа. Уровни: холодный резерв (ЗИП на складе, переключение вручную), тёплый (standby загружен, но не в цикле), горячий (оба в работе, синхронизация, автоматическое переключение).
Инженер выбирает не «как у всех», а по допустимому времени восстановления и по тому, кто будет менять проект после пуска. Если уставки меняют с HMI каждую смену, а retain не синхронизируется - горячий резерв без процедуры обновления standby хуже, чем осознанный тёплый с понятным ручным переключением за пять минут.
В простейшем виде - два одинаковых ПЛК, перекрёстное подключение I/O или разделение по критичным выходам, связь между CPU для heartbeat и обмена служебными данными. Производитель может давать лицензию redundancy, отдельный кабель синхронизации, требования к версии firmware.
Что должно совпадать в паре: программа (версия, checksum), таблица уставок оператора, retain-переменные (счётчики, состояния клапанов, шаги последовательности), при необходимости - часы и метки для журнала. Что часто забывают: рецепты в отдельной области памяти, константы, загруженные с USB, параметры PID не в RETAIN, а в «обычных» переменных.
Политика Download и переменные RETAIN/PERSISTENT: online change на активном без обновления standby - классический источник рассинхрона. Versionирование проектов помогает не путать, какая сборка на каком CPU; в as-built фиксируют список retain-переменных и результат теста power cycle для пары.
Три модели на объектах. Первая: уставки только в проекте, оператор на HMI не меняет - синхронизация сводится к одинаковому проекту на обоих CPU. Вторая: уставки в retain/PERSISTENT, оператор меняет с панели - нужно правило, как изменение попадает на standby (автоматически по redundancy link, по событию «сохранить», при каждом переключении активного). Третья: уставки в SCADA с записью в ПЛК - риск, что SCADA пишет только в активный; standby остаётся со старыми числами.
На мнемосхеме оператор видит одно значение; физически в паре может быть два разных float до следующей синхронизации. После переключения каскад «прыгает» - не мистика, а математика. Решение: матрица «какие теги синхронизируются, как часто, кто master», тест на FAT с изменением уставки за минуту до принудительного failover.
Граница HMI и ПЛК для аварий и уставок - в материале про панель и SCADA: резерв не отменяет правила, где живёт критичный параметр.
При отказе активного standby должен: подхватить цикл, выставить выходы в состояние, согласованное с алгоритмом (часто безопасный кратковременный бумплесс не гарантирован на дискретных), продолжить последовательность с корректного шага или безопасно остановить по процедуре. Документируют: допустим ли скачок аналогового выхода, сколько циклов допускается «неопределённость», срабатывает ли общий аварийный останов.
Когда «лечат» бывший активный и возвращают в пару - не всегда он снова master. Режимы: автоматический failback, ручное переключение, «оставаться на standby до планового окна». Без регламента наладчик вручную копирует проект на отремонтированный CPU, забывает retain - и через неделю снова сюрприз.
Watchdog на активном, мониторинг связи redundancy, диагностика I/O - всё это должно давать понятную аварию на HMI, а не молчаливое зависание. Ethernet на объекте - отдельный сегмент для синхронизации пары, не общий с офисом.
Стенд максимально близок к объекту: те же модули I/O, та же схема резерва, симуляция полевых сигналов или реальные датчики. SCADA и HMI подключены как на площадке.
Обязательные сценарии: нормальная работа на активном, наблюдение heartbeat; принудительное отключение питания активного - переключение за время не хуже ТЗ; отказ связи redundancy при живом активном - нет ложного переключения или есть по проекту; изменение уставки на HMI - проверка на standby до и после failover; online download на активный - процедура обновления standby; потеря одного модуля I/O если резерв по I/O; восстановление бывшего активного и ввод в пару; длительная работа на standby (нагрев, память, журнал).
Протокол FAT фиксирует: версия проекта, время переключения, состояние выходов, расхождение уставок до/после. FAT и SAT без сюрпризов - общая дисциплина приёмки; для резерва добавляют отдельный лист сценариев.
Холодный резерв - второй комплект на складе или в соседнем шкафу без питания. Время восстановления - часы, зато нет постоянной синхронизации и споров «кто master». Подходит для некритичных узлов и когда персонал умеет переключать клеммы по инструкции.
Тёплый резерв - standby под питанием, проект загружен, в цикл не входит или в режиме listen. Переключение - минуты: команда оператора или наладчика, проверка состояния. Дешевле горячего по лицензиям и кабелю синхронизации, но на FAT всё равно нужен сценарий «переключили за N минут без неверного выхода».
Горячий оправдан, когда N измеряется секундами и простой дорог. Цена - двойная нагрузка на инженерную дисциплину: любое изменение уставки и любой download становятся процедурой для пары, а не для одного CPU.
Аппаратный или программный watchdog на активном должен отличать «цикл идёт» от «задача зависла в одном блоке». На FAT симулируют не только обрыв питания, но и бесконечный цикл или блокировку задачи - standby должен перехватить управление в пределах времени из ТЗ.
Режим STOP на активном при живом standby - отдельный кейс: допустимо ли переключение, остаются ли выходы в last state, как ведёт себя аналог при останове цикла. Если в проекте safe state при STOP - «в ноль», а при failover - «удержать», оператор получит скачок. Это согласуют до пуска, не на первой аварии.
SCADA часто опрашивает только «видимый» активный IP. После failover адрес может смениться или остаться виртуальным - зависит от схемы. На FAT проверяют: тренды не рвутся дольше допустимого, авария «переключение CPU» попадает в журнал с меткой времени, OPC-клиент переподключается без ручного рестарта службы.
Если уставки живут в SCADA с записью в ПЛК, сценарий failover включает шаг «записать актуальный набор в новый активный» или запрет записи до стабилизации роли. Иначе диспетчер «лечит» PID на экране, а в standby остаётся вчерашний gain.
В паспорт объекта включают: схему резерва, время переключения по результатам FAT, процедуру ручного switchover, список retain-переменных, правило обновления проекта на паре, контакты поддержки. Паспорт объекта после пуска - про передачу заказчику; раздел redundancy не должен быть пустым абзацем «по стандарту производителя».
Плановый proof test резерва - раз в квартал или после каждого вмешательства в проект: принудительное переключение в окно, сравнение ключевых тегов, запись в журнал. Без планового теста первая реальная авария становится экзаменом.
| Сценарий отказа | Ожидаемое поведение | Тест на стенде (FAT) |
|---|---|---|
| Питание активного CPU пропало | Standby активируется за время ≤ по ТЗ, авария «переключение» в журнал | Выключить 24 V активного под нагрузкой, замер времени, проверка выходов |
| Зависание цикла активного (watchdog) | Watchdog переводит на standby, безопасное состояние по матрице | Симуляция STOP или блокировка задачи, наблюдение failover |
| Обрыв кабеля синхронизации | По проекту: переключение или удержание активного + авария связи | Отключить patch-cord redundancy, убедиться в отсутствии двойного master |
| Рассинхрон retain после online change | Процедура: блокировка failover или принудительная синхронизация | Download только на активный, failover без sync - должно быть запрещено или безопасно |
| Изменение уставки оператором | На standby те же значения до переключения | Изменить SP, сравнить теги в обоих CPU, затем failover |
| Отказ одного модуля DO активного | Резерв I/O или переход на пару по архитектуре | Отключить модуль, проверить цепь и аварию |
| Восстановление отремонтированного CPU | Ввод в standby без захвата master без команды | Загрузка проекта, синхронизация retain, тест без failback |
| Потеря питания обоих CPU поочерёдно | После восстановления - предсказуемый старт, retain по паспорту | Два цикла power cycle, проверка уставок и шага SEQ |
| SCADA пишет только в активный | После failover значения на новом активном актуальны | Запись с SCADA, failover, сравнение с операторской панелью |
| Длительная работа 24 ч на standby | Нет переполнения журнала, дрейфа синхронизации | Прогон сутки, сравнение checksum retain или ключевых тегов |
Резерв в схеме, один проект только на активном. Standby с устаревшей логикой.
FAT «нажали кнопку - переключилось». Без нагрузки, без уставок, без download.
Уставки в SCADA, retain в ПЛК не согласованы. После failover разные миры.
Общий свитч с офисом для heartbeat. Broadcast шторм - ложные отказы.
Failback автоматически без проверки отремонтированного CPU. Второй сбой за смену.
Достаточно ли двух одинаковых ПЛК без лицензии redundancy?
Зависит от среды и механизма синхронизации. Самодельная пара без документированной процедуры - риск. Уточнять у производителя допустимую схему.
Как часто синхронизировать уставки?
По событию изменения, по таймеру или при каждом переключении - зафиксировать в as-built. Оператор не должен помнить «нажать sync».
Нужен ли резерв панели оператора?
Отдельная тема; ПЛК может переключиться, а HMI показывает старый активный. Индикация роли CPU обязательна.
Cold start влияет на пару?
Да. Retain и PERSISTENT после полного сброса питания обоих - проверить по паспорту и тесту.
На объектах с требованием непрерывности закладывают пару контроллеров одной линейки с документированной процедурой обновления и тестом failover на стенде до SAT. Среда разработки (CODESYS или MasterSCADA) не определяет схему резерва - определяют архитектура проекта, политика retain и дисциплина FAT. Перед первым пуском полезно зафиксировать в паспорте объекта версию проекта и чек-лист синхронизации уставок для смены наладчика.