Оператор жалуется: «после переключения на резервный ПЛК уставки 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 на объекте - отдельный сегмент для синхронизации пары, не общий с офисом.
Что прогонять на FAT: минимальный набор
Стенд максимально близок к объекту: те же модули 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, STOP и «мягкое» зависание
Аппаратный или программный watchdog на активном должен отличать «цикл идёт» от «задача зависла в одном блоке». На FAT симулируют не только обрыв питания, но и бесконечный цикл или блокировку задачи - standby должен перехватить управление в пределах времени из ТЗ.
Режим STOP на активном при живом standby - отдельный кейс: допустимо ли переключение, остаются ли выходы в last state, как ведёт себя аналог при останове цикла. Если в проекте safe state при STOP - «в ноль», а при failover - «удержать», оператор получит скачок. Это согласуют до пуска, не на первой аварии.
Резерв и верхний уровень: SCADA, OPC, журнал
SCADA часто опрашивает только «видимый» активный IP. После failover адрес может смениться или остаться виртуальным - зависит от схемы. На FAT проверяют: тренды не рвутся дольше допустимого, авария «переключение CPU» попадает в журнал с меткой времени, OPC-клиент переподключается без ручного рестарта службы.
Если уставки живут в SCADA с записью в ПЛК, сценарий failover включает шаг «записать актуальный набор в новый активный» или запрет записи до стабилизации роли. Иначе диспетчер «лечит» PID на экране, а в standby остаётся вчерашний gain.
Документация для эксплуатации после SAT
В паспорт объекта включают: схему резерва, время переключения по результатам 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. Перед первым пуском полезно зафиксировать в паспорте объекта версию проекта и чек-лист синхронизации уставок для смены наладчика.
Обсуждение