Миграция SCADA без переучивания смены: мнемосхемы, теги, журналы

Заказчик, планирующий миграцию SCADA, обычно формулирует задачу техническими терминами - заменить контроллеры, перейти на российский софт, закрыть требования 187-ФЗ. Дежурная смена в эту формулировку не попадает, хотя именно от неё зависит, воспримут ли переход как штатное обслуживание или как аварию на ровном месте: смена полтора года смотрит на одни и те же мнемосхемы и знает, где на экране искать тревогу по третьему щиту.

«Переучивание» складывается из десятков мелких решений: сохранён цвет тревожного индикатора или нет, остался порядок вкладок в архиве событий, называется щит в новой системе так же, как в старой. Часть таких решений интегратор принимает по умолчанию, не проговаривая с заказчиком, - и именно тут расходится ожидание с результатом. Дальше - две разные по масштабу задачи, которые определяют, заметит ли смена переход: полная замена SCADA-пакета в здании банка в Туле и подключение действующей SCADA к централизованной системе мониторинга банка без замены пакета.

Что в SCADA видит оператор, а что видит только интеграция

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

Интерфейсный слой - мнемосхемы, цветовая индикация состояний, порядок и внешний вид журналов событий и трендов, последовательность действий при квитировании тревоги. Смена работает именно с ним, и любое изменение здесь требует обучения, повторной аккредитации персонала или того и другого сразу - зависит от регламента объекта.

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

Смешение этих слоёв в одном проектном решении - главная причина переучивания там, где его можно было избежать. Миграция интеграционного слоя иногда тянет за собой правку интерфейса просто потому, что так удобнее интегратору, а не потому, что это технически необходимо. Разделение задачи на два слоя с самого начала стоит зафиксировать в ТЗ на миграцию SCADA отдельным пунктом.

Сценарий 1: полная замена пакета SCADA

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

Показательный пример - здание банка в Туле, где прежний комплекс диспетчеризации целиком уступил место отечественному, без общей архитектуры с предыдущей связкой: другой изготовитель аппаратной части, другая среда верхнего уровня. Файлы визуализации одной платформы попросту не открываются в другой, поэтому семь автоматизированных подсистем здания (вентиляция, холодоснабжение, климатконтроль, электрика, ИБП, протечки, противопожарная защита) переносились содержательно, а мнемосхемы и структура тегов собирались заново под привычный для оператора вид. У заказчика на этом же объекте параллельно работала смежная система мониторинга, интегрированная со старым контуром автоматизации, - её лишь перенастроили на приём данных от новой АСУ, саму платформу не трогали. Изменение одного слоя не обязано менять соседний, если границу между ними спроектировать заранее.

Сценарий 2: обновление версии без замены пакета

Коротко: в кейсе подключения административного здания банка к централизованной системе мониторинга (ЦСМ) программный продукт не менялся вовсе - SCADA TRACE MODE осталась TRACE MODE, обновилась только её версия, а весь новый функционал лёг на отдельный шлюз.

Диспетчеризация на TRACE MODE с тремя щитами автоматизации уже работала на объекте, но существовала автономно и данные на верхний уровень банка не передавала. Заказчик поставил три условия: подключить объект к ЦСМ в режиме реального времени, привести параметры к единому справочнику зон и кодов банка, работающую логику SCADA и полевой уровень не трогать.

Решение разделило задачу ровно по границе интерфейсного и интеграционного слоя. Программную среду TRACE MODE обновили до версии 7 с поддержкой MQTT - шаг, нужный для передачи данных наружу и никак не влияющий на картинку локального АРМ. Проект сконвертировали в новой инструментальной версии без потери логики. Десятки электрощитов и приточных установок с историческими локальными именами вроде «ЩБП-1.1-ППК» или «ПВ-7» получили привязку к коду зоны из единого справочника банка - исключительно на уровне обмена данными с ЦСМ, мнемосхемы локальной SCADA этого вообще не почувствовали. Всю нагрузку взял отдельный шлюз - контроллер и брокер MQTT между локальной АСУ и выделенным каналом связи банка.

Результат этого разделения: локальная АСУ объекта продолжила работать в прежней архитектуре, операторская смена не переучивалась и регламент эксплуатации не менялся, при этом объект встроился в единый стандарт мониторинга банка с унифицированными кодами и протоколами.

Чем два сценария различаются технически

Коротко: у обоих сценариев общая цель - смена ничего не замечает, - но разный набор действий и разная зона риска, и путать их при планировании графика не стоит.

Параметр	Полная замена пакета	Обновление версии + шлюз
Что меняется физически	Контроллеры, среда верхнего уровня, лицензии	Только версия существующей среды и добавленный внешний узел
Судьба мнемосхем	Перерисовываются заново под привычный вид	Не трогаются вовсе
Судьба тегов	Перепривязка адресации с сохранением подписей	Формируются новые внешние идентификаторы параллельно старым, без правки локального проекта
Где основной риск для смены	В перерисовке интерфейса	В случайном проникновении внешних требований в локальный проект
Типичный триггер задачи	Снятие платформы с производства, конец поддержки лицензий	Требование внешнего заказчика (банка, головной организации) встроить объект в общий контур

Мнемосхема - зафиксированный алгоритм, а не картинка

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

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

Проверка укладывается в отдельный пункт программы приёмо-сдаточных испытаний: посадить дежурного оператора перед новым АРМ без предварительного инструктажа, дать типовую задачу - найти состояние узла, квитировать тестовую тревогу, открыть архив событий за прошлую смену. Справился самостоятельно - мнемосхема воспроизведена корректно. Понадобилось объяснение «это теперь здесь» - расхождение устраняется до подписания акта, а не остаётся рабочим моментом, к которому смена «привыкнет».

Теги и адресация: где расходятся ожидания заказчика и интегратора

Коротко: имя тега и его физический адрес в новой системе живут отдельно от картинки на экране оператора, и путаница между «переименовали для интеграции» и «переименовали на экране» - частая причина конфликта после сдачи объекта.

Что происходит с тегом	Видит ли это смена на экране	Пример из практики
Смена внутреннего адреса контроллера при замене оборудования	Нет, если мнемосхема привязана к прежнему логическому имени	Замена Modicon на ОВЕН - физическая адресация меняется, отображаемое имя узла на мнемосхеме - нет
Переименование тега под справочник зон внешней системы (ЦСМ, единый стандарт заказчика)	Нет, если переименование происходит на уровне шлюза или экспорта, а не в самой локальной SCADA	Кейс ЦСМ банка - топики MQTT формируются по коду зоны, локальные обозначения щитов на АРМ не менялись
Прямая правка подписи тега в проекте SCADA, отражающаяся на мнемосхеме	Да, всегда	Полная замена пакета, где новая система не поддерживает прежние обозначения технически

Правило для ТЗ: переименование тегов ради внешней интеграции не проникает на интерфейс смены без технической необходимости. При полной замене пакета, где необходимость есть, переименование выполняется один раз, согласуется с заказчиком до пусконаладки и фиксируется в передаваемой документации - иначе через полгода при разборе инцидента ищут несуществующий тег по старому названию.

Журналы и архивы трендов: непрерывность истории важнее удобства нового формата

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

Полный перенос архива тревог и трендов между несовместимыми пакетами - редкость: формат хранения истории у каждой платформы свой. Там, где перенос невозможен или экономически неоправдан, честное решение - формализовать разрыв: зафиксировать в акте передачи точную дату и время начала архива новой системы, договориться с заказчиком о сроке и форме доступа к архиву старой системы на переходный период. Смена должна знать точную границу - за данными до определённой даты идти в старый архив, а не подозревать систему в «потере истории».

Отдельного внимания заслуживает формат самого журнала событий - последовательность и состав полей записи: время, объект, тип события, приоритет, отметка о квитировании. Перестановка привычных столбцов в новой системе - мелочь на бумаге, но именно она замедляет разбор инцидента в первую неделю эксплуатации, потому что смена ищет глазами конкретную колонку на конкретном месте.

Что проверяют на приёмке, чтобы смена не заметила перехода

Коротко: формальные приёмо-сдаточные испытания подтверждают верность телеметрии и работу алгоритмов, а отдельная, часто пропускаемая часть приёмки - способность смены выполнять свои обязанности на новом АРМ без адаптационного периода.

Параллельная работа старой и новой системы в переходном окне - там, где это возможно технически, - чтобы сверить показания и убедиться, что расхождений нет ни по одному контролируемому параметру.
Тестовый прогон типовых сценариев смены на новом АРМ без предварительного инструктажа - поиск узла, квитирование тревоги, работа с архивом.
Сверка структуры и содержания журналов событий и трендов за контрольный период до и после переключения.
Проверка, что переименование тегов для внешней интеграции (если оно было) не отразилось на подписях мнемосхем.
Письменное подтверждение от начальника смены или ответственного за эксплуатацию, что регламент действий не меняется - отдельный документ, который стоит прикладывать к акту приёмки наравне с протоколами измерений.

Что заложить в ТЗ

Явное разделение задачи на интерфейсный и интеграционный слой с указанием, какие изменения допустимы в каждом.
Требование воспроизвести расположение элементов мнемосхем, цветовую индикацию состояний и структуру журналов «как было», а не «как удобнее в новом пакете».
Условие, что переименование тегов для внешней интеграции (ЦСМ, единый справочник заказчика) не должно менять отображаемые на АРМ подписи без отдельного согласования.
Порядок работы с историческими архивами тревог и трендов - переносятся, хранятся параллельно на переходный период или архивируются с фиксацией точки отсечения.
Пункт программы приёмо-сдаточных испытаний на проверку работы дежурной смены на новом АРМ без инструктажа интегратора.
Комплект эксплуатационной документации и обучение персонала по новой АРМ - даже при минимальных визуальных изменениях, формально фиксирующее факт передачи системы.

Частые вопросы

Всегда ли при импортозамещении SCADA приходится перерисовывать мнемосхемы? Нет. Если продукт остаётся прежним и меняется только версия или добавляется интеграционный слой снаружи - как в кейсе подключения к ЦСМ банка, - мнемосхемы локальной SCADA можно не трогать вовсе. Перерисовка неизбежна только при полной замене самого программного пакета.

Можно ли перенести архив тревог и трендов автоматически при замене SCADA-пакета? Редко: прямой перенос между несовместимыми платформами верхнего уровня требует отдельной конвертации. Экономически невыгодная конвертация заменяется формальной точкой отсечения архива и договорённостью о доступе к старой системе на переходный период.

Что делать, если у заказчика уже есть собственная система мониторинга, интегрированная со старой SCADA? Перенастроить её на приём данных из новой системы, саму платформу мониторинга не трогая - именно так поступили со смежной системой заказчика в проекте банка в Туле. Структура и адресация тегов новой АСУ должна остаться достаточной для того, чтобы верхняя система мониторинга продолжила работать без переделки.

Требует ли переименование тегов под ЦСМ банка переобучения смены на локальном объекте? Нет, при условии, что переименование происходит на уровне шлюза или экспорта данных, а не в проекте локальной SCADA. Так решили задачу унификации номенклатуры при подключении объекта к ЦСМ банка: десятки исторических локальных обозначений привязали к единому справочнику зон без изменения картинки на АРМ оператора.

Как проверить перед приёмкой, что смена действительно не будет переучиваться? Тестовый прогон типовых задач дежурного оператора на новом АРМ без инструктажа со стороны интегратора: поиск состояния узла, квитирование тестовой тревоги, работа с архивом событий. Справился самостоятельно - задача решена; понадобились пояснения - расхождения устраняются до подписания акта.

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

Источники

Замена системы автоматизации в здании банка в Туле - кейс - полная замена SCADA-пакета, перерисовка мнемосхем «как было», сохранение работы смежной системы мониторинга заказчика.
Подключение мониторинга инженерных систем к ЦСМ крупного российского банка - кейс - обновление TRACE MODE до версии 7, шлюз MQTT, унификация номенклатуры без изменения локальной SCADA.
Unity Pro на CODESYS: как оценить сложность своего проекта до запроса КП - про тот же принцип на уровне контроллера: встроенная в среду разработки визуализация переносится не так, как логика.
Услуга по импортозамещению контроллеров и SCADA Schneider на отечественные аналоги - подробные таблицы соответствия оборудования для полной замены комплекса.

Разница между переучиванием смены и незаметным для неё переходом решается разграничением задачи на этапе проектирования, а выбор конкретного пакета SCADA здесь вторичен. Запросить КП - расчёт миграции SCADA с сохранением интерфейса для дежурной смены; Помощь с ТЗ - формулировка требований к мнемосхемам, тегам и журналам до объявления закупки.