В проекте SCADA резерв часто описывают одной строкой: «второй сервер». Но отказ — это не только железо. Это потеря сети, канала связи, питания, синхронизации и доверия к данным. Резерв должен покрывать конкретные сценарии, а не просто существовать.
Зачем резервировать SCADA
Диспетчерская система управляет процессом, который нельзя остановить на время перезагрузки. Если основной сервер недоступен, оператор теряет картину: не видит состояния, не может отдать команду, не понимает, что происходит с объектом. Резерв сокращает это окно.
Резервирование нужно проектировать вместе с моделью данных. Если резервный контур не видит те же события, не знает те же адреса и не сохраняет тот же журнал, он не поможет.
Пять сценариев отказа
- Отказ сервера SCADA. Основной узел недоступен, резервный должен принять управление.
- Обрыв канала связи. Пропадает связь с ТПП или шлюзом; нужно переподключение и сохранение событий.
- Отказ контроллера или шлюза. Часть сигналов становится недостоверной; система должна показать качество, а не «ноль».
- Проблема питания. ИБП, второй ввод, корректное завершение работы и восстановление.
- Сетевая авария. Отказ коммутатора, дублирование адресов, шторм широковещательных пакетов.
Для каждого сценария должен быть описан ожидаемый результат: что видит диспетчер, какие команды доступны, что происходит с журналом и сколько длится переключение.
Горячий и холодный резерв
Горячий резерв держит данные и соединения в готовности, переключение занимает секунды. Холодный резерв запускается вручную или скриптом, данные могут отставать. Для энергетики и непрерывных процессов чаще нужен горячий резерв, но он дороже и сложнее в сопровождении.
Отдельно решите, что происходит с командами: запрет на время переключения, подтверждение оператором или повтор. Это вопрос безопасности, а не только удобства.
Как проверить переключение
Проверка «второй сервер включается» недостаточна. Нужен протокол испытаний:
- отключить основной сервер и замерить время переключения;
- проверить, что резерв видит те же ТС, ТИ и события;
- отправить команду и убедиться, что она дошла до оборудования;
- оборвать канал связи и проверить восстановление и очередь событий;
- отключить питание и проверить корректное завершение и старт;
- сверить журналы основного и резервного контура.
Типичные ошибки
- Резервный сервер есть, но база и события не синхронизируются.
- Переключение проверяли только на стенде, не на объекте.
- Резервный канал связи не тестировали в реальной аварии.
- Нет регламента: кто переключает, когда и что делает оператор.
- Резерв не входит в обслуживание и обновления.
- Команды на резерве не имеют подтверждения и блокировок.
Чек-лист
- Описаны сценарии отказа и ожидаемое поведение.
- Определён тип резерва: горячий или холодный.
- Данные, события и журналы синхронизируются.
- Переключение проверено на объекте, а не только в теории.
- Команды и блокировки работают на резервном контуре.
- Есть регламент переключения и обучения операторов.
- Резерв включён в поддержку, обновления и бэкапы.
Посмотреть, как это устроено на распределённом объекте, можно в кейсе «Славянка». О проектировании — в АСУ ТП под ключ и статье МЭК-104 в SCADA.
Вопросы
Частые вопросы
Чем горячий резерв SCADA отличается от холодного?
Горячий резерв держит данные и соединения в готовности и переключается за секунды. Холодный запускается вручную или скриптом и может отставать по данным.
Как часто проверять переключение на резерв?
При пусконаладке, после изменений в системе и затем по регламенту обслуживания. Проверка должна включать не только запуск сервера, но и команды, события и журнал.
Что важнее — второй сервер или резервный канал связи?
Оба, потому что это разные сценарии отказа. Второй сервер не поможет, если потерян канал до объекта, а резервный канал не заменит упавший сервер.