Миграция SCADA при модернизации АСУ ТП: что перенести кроме тегов

Коротко: список тегов — только один слой проекта миграции SCADA. Если перенести имена и адреса, но потерять единицы измерения, диапазоны, приоритеты алармов, задержки, deadband, настройки архивирования, качество данных, экранные связи и скрипты, новая система может показывать значения, но не воспроизводить рабочее поведение старой. RD[AI] подготавливает проверяемый комплект исходных данных для интегратора, но не проектирует целевую SCADA, не выполняет перенос и ПНР.

Почему экспорта тегов недостаточно

Типовая ситуация выглядит просто: предприятие планирует замену SCADA, у службы АСУ ТП есть резервная копия проекта и экспорт тегов, а интегратор готов оценивать перенос.

Проблема обнаруживается позже. Один тег участвует сразу в нескольких частях системы: получает значение из PLC, масштабируется, записывается в архив, вызывает аларм, выводится на мнемосхему, используется в тренде, отчёте или скрипте. Если перенести только имя тега и адрес, эти зависимости останутся в старой платформе.

Особенно опасен внешне успешный перенос. Значение отображается на экране, поэтому тег считают перенесённым. Но архив может записываться с другим интервалом, аларм — не учитывать задержку, тренд — использовать другую шкалу, а скрипт — ссылаться на старое имя.

Общий принцип подготовки объекта разобран в статье «АСУ ТП начинается не с контроллера, а с архива». Здесь рассматривается более узкий слой: какие сущности и настройки нужно извлечь именно из старой SCADA.

Какие данные нужны для модернизации АСУ ТП

До проектирования целевой системы нужен не один файл, а согласованный комплект данных. Его состав фиксируют до массового извлечения, чтобы заказчик, RD[AI] и интегратор одинаково понимали ожидаемый результат.

Документация SCADA: что собрать до миграции

Одна настройка может находиться в нескольких источниках. Имя тега хранится в проекте SCADA, физический адрес — в конфигурации PLC, единица измерения — в P&ID или паспорте прибора, а фактическая применимость подтверждается на объекте.

Мы работаем с исходным языком документов и конфигураций. Языковое покрытие расширяется по мере роста проектов.

Каких данных обычно не хватает

• Неизвестно, какая резервная копия соответствует работающей системе.
• Отсутствует исходный проект части экранов или PLC.
• Экспорт тегов не содержит параметров алармов и архивирования.
• Схемы шкафов не отражают поздние изменения.
• Физический канал не связан с технологическим обозначением.
• Экран ссылается на тег, отсутствующий в экспорте.
• Неизвестно, где выполняется масштабирование.
• Не зафиксированы часовой пояс и правила обработки времени.
• Скрипт обращается к отсутствующей базе или сетевому ресурсу.
• Нет перечня функций, критичных для эксплуатации.

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

Семь стадий подготовки данных

1. Зафиксировать состав и версии

Без подготовки: в проект попадает папка с копиями `final`, `final2`, `actual` и `backup_old`. Версию выбирают по имени или дате.

Что извлекается: имя источника, тип, размер, дата, версия, контрольная сумма, владелец и предполагаемая применимость.

Результат: реестр источников и кандидатов на актуальную версию. Служба АСУ ТП подтверждает применимость.

2. Собрать карту тегов и каналов

Без подготовки: теги переносятся плоским списком, а связь с PLC, I/O и оборудованием остаётся в памяти инженера.

Что извлекается: имя, тип данных, адрес, источник связи, единица, диапазон, описание, качество, алиасы и связанные объекты.

Результат: карта `объект → канал → PLC → SCADA` с источниками. Инженер подтверждает связи, влияющие на физический объект.

Сопоставление обозначений подробно разобрано в материале «Нормализация тегов SCADA, PLC и EAM».

3. Восстановить реестр алармов

Без подготовки: переносятся текст и уставка, но теряются приоритет, задержка, возврат, квитирование, блокировка или связь с режимом.

Что извлекается: идентификатор, тег, условие, порог, гистерезис, задержка, приоритет, класс, текст, квитирование, подавление и связанный экран.

Результат: реестр алармов с зависимостями и вопросами. RD[AI] не назначает уставки и функции безопасности.

4. Описать архивирование и временные ряды

Без подготовки: графики старой и новой системы расходятся из-за периода записи, deadband, масштаба, качества или времени.

Что извлекается: источник, режим записи, период, deadband, единица, диапазон, quality code, часовой пояс, глубина хранения и связанные тренды.

Результат: реестр архивных рядов и правила контрольного сравнения.

5. Разобрать HMI и навигацию

Без подготовки: экраны перерисовываются как изображения, а динамические свойства, команды, режимы и связи с faceplate теряются.

Что извлекается: экран, объект, тег, тип динамики, команда, условие видимости, переход, роль пользователя и библиотека.

Результат: карта экранов и операторских сценариев. Критичные сценарии подтверждают операторы и инженер АСУ ТП.

6. Найти скрипты, отчёты и интерфейсы

Без подготовки: проект открывается, но отчёт не формируется, рецепт не загружается или данные не поступают во внешнюю систему.

Что извлекается: триггер, входные теги, выходные действия, файлы, таблицы, узлы, форматы обмена и зависимости.

Результат: реестр скрытых зависимостей. Пароли и токены не включаются в открытый реестр.

7. Сформировать маппинг и критерии проверки

Без подготовки: после переноса невозможно понять, существовало ли расхождение раньше или появилось при миграции.

Что извлекается: соответствия `старое → новое`, преобразования типов, правила единиц, неподдержанные функции, статус и сценарий проверки.

Результат: матрица миграции и проверяемый вход для согласованных испытаний. Интегратор реализует перенос, заказчик принимает результат.

Что проверить при импортозамещении АСУ ТП

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

• Поддержку исходных типов данных и адресации.
• Правила масштабирования и качества сигнала.
• Модель алармов, приоритетов, квитирования и подавления.
• Форматы historian и возможность переноса истории.
• Работу faceplate, шаблонов и динамических свойств.
• Скриптовые языки и библиотечные зависимости.
• OPC, Modbus, SQL, файловые и другие интерфейсы.
• Пользователей, роли, журналирование действий и аудит.
• Часовые пояса, синхронизацию времени и обработку архивных меток.
• Лицензионные и технические ограничения целевой платформы.

Выбор целевой архитектуры и способа реализации выполняет интегратор. RD[AI] подготавливает нейтральное описание исходного состояния, зависимостей и пробелов.

Как связать SCADA с физическим оборудованием

Ниже приведён учебный пример, а не данные проекта заказчика.

SCADA tag: PT_2214_BAR
PLC variable: DB22.DBD18
I/O source: AI module 4, channel 6
SCADA description: Pump 07 discharge pressure
P&ID tag: PT-2214
Equipment alias: P-07A
EAM object: EQ-2847

После разбора источников карточка становится проверяемой:

Master ID: INST-PT-2214
Object: датчик давления на напорной линии P-07A
Data type: REAL
Engineering unit in SCADA: bar
Range in SCADA: 0…16 bar
Archive mode: on change
Logging deadband: 0.1 bar
Trend: TREND_PUMP_07
Alarm HI: 12.0 bar
Alarm delay: 3 s
HMI faceplate: FP_PRESSURE_STD
Source 1: scada_tags.csv, row 418
Source 2: historian_config.xml, node PT_2214_BAR
Source 3: unit_3_pid_revB.pdf, sheet 12
Source 4: equipment_export.xlsx, Assets, row 923
Verification status: review_required
Conflict: P&ID показывает kPa, SCADA — bar
Question: где выполняется преобразование единиц

Решение по конфликту не принимает алгоритм. Инженер устанавливает, является ли `kPa` другой единицей представления, ошибкой документа или признаком дополнительного преобразования.

Экспорт и подготовленный комплект

Что нельзя установить только по архиву

• Соответствует ли резервная копия текущей работающей системе.
• Подключён ли физический прибор к указанному каналу сейчас.
• Правильно ли назначены технологические и защитные уставки.
• Какие неописанные действия оператора фактически применяются.
• Почему в historian появился конкретный разрыв.
• Допустимо ли переносить старую архитектуру без изменений.
• Как поведёт себя целевая SCADA под реальной нагрузкой.

Эти вопросы попадают в журнал проверки и закрываются обследованием, интервью, испытанием или проектным решением уполномоченной команды.

Кто за что отвечает

RD[AI] делает

• Инвентаризирует файлы, базы, выгрузки и версии.
• Извлекает теги, алармы, архивные настройки и зависимости.
• Связывает SCADA, PLC, I/O, документы и физические объекты.
• Нормализует обозначения и единицы без потери исходного значения.
• Сохраняет файл, лист, строку или узел источника.
• Выявляет конфликты и неподтверждённые версии.
• Формирует открытые реестры для интегратора.

Заказчик делает

• Подтверждает фактический состав и критические функции.
• Предоставляет доступные версии и историю изменений.
• Назначает специалистов для проверки спорных связей.
• Утверждает критерии приёмки исходного комплекта.

Интегратор делает

• Выбирает и проектирует целевую архитектуру.
• Определяет способ переноса и преобразования.
• Разрабатывает проект на новой SCADA.
• Адаптирует экраны, скрипты и интерфейсы.
• Проводит испытания, ПНР и ввод в эксплуатацию.

RD[AI] готовит проверяемые инженерные данные. Решения по архитектуре, безопасности, уставкам и вводу системы принимает заказчик и профильная проектная команда.

Что получает интегратор

• Реестр источников и версий.
• Карту тегов и алиасов.
• Соответствия SCADA ↔ PLC ↔ I/O ↔ оборудование.
• Реестр алармов.
• Реестр архивирования и трендов.
• Карту экранов и faceplate.
• Реестр скриптов, отчётов и рецептов.
• Матрицу ролей без раскрытия секретов.
• Реестр интерфейсов.
• Журнал конфликтов, пробелов и вопросов.
• Критерии проверки комплектности.

Формат согласуется до начала работ: Excel, CSV, JSON, XML, Markdown, DOCX или согласованная схема API.

Сценарии применения собраны на странице «Применение». Принципы хранения источников, статусов и конфликтов показаны на странице «Метод». Если требуется связать программный объект с конкретным исполнением оборудования, используется паспортная идентификация.

С чего начать

Необязательно передавать весь проект сразу. Для первого этапа можно выбрать один сервер SCADA, один контроллер и связанные экраны, одну группу из 100–300 тегов, один класс алармов или один архивный контур.

Выборка должна содержать не только экспорт тегов, но и связанные источники: проект SCADA, PLC-экспорт, несколько P&ID, I/O-лист, архивный интервал и перечень известных изменений.

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

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

Какие данные нужны для модернизации АСУ ТП?

Для выбранного контура нужно собрать актуальные версии проектов SCADA и PLC, архитектуру, I/O, теги, алармы, настройки архивирования, экраны HMI, скрипты, права, интерфейсы и связи с физическим оборудованием. Каждый критичный параметр должен иметь источник и статус проверки.

Можно ли мигрировать SCADA только по экспорту тегов?

Экспорт тегов подходит для первичной оценки, но обычно не содержит полный набор зависимостей. Отдельно нужно проверить алармы, настройки архивирования, тренды, экраны HMI, скрипты, права, отчёты и внешние интерфейсы.

Нужно ли переносить всю историческую базу?

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

Как понять, какая резервная копия SCADA актуальна?

Имя файла и дата изменения недостаточны. Сравнивают версию проекта, состав тегов, экраны, конфигурации связи и контрольную выборку с работающей системой. Применимость подтверждает служба АСУ ТП заказчика.

Может ли RD[AI] выполнить саму миграцию SCADA?

Нет. RD[AI] инвентаризирует, извлекает, связывает и подготавливает исходные данные. Архитектуру, перенос, разработку, испытания, ПНР и ввод в эксплуатацию выполняет интегратор или проектная команда заказчика.