АСУ ТП начинается не с контроллера, а с архива

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

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

Но на действующем объекте я бы начал с другого вопроса:

Что именно мы собираемся автоматизировать — и откуда это известно?

На столе у инженера обычно лежит не единый актуальный проект. Там могут быть PDF со сканами, несколько Excel разных лет, паспорта оборудования, схемы шкафов, P&ID, архивы тревог, конфигурации PLC и HMI, фотографии после ремонтов и письма прошлых подрядчиков.

Каждый источник может быть полезен. Но источники не обязаны совпадать.

В паспорте указано одно обозначение, на схеме — другое, в SCADA существует третий тег, а на участке тот же агрегат называют четвёртым именем. Если просто перенести всё это в новую систему, неопределённость не исчезнет. Она переедет в новую SCADA, EAM, ERP или цифровой двойник — вместе с красивым интерфейсом и высокой стоимостью исправления.

Где реально начинается модернизация

На greenfield-объекте проект можно строить от утверждённой документации к реализации. Есть спецификация, перечень сигналов, принятая архитектура, согласованные обозначения и версии программного обеспечения.

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

Типовой входной комплект включает:

• проектные схемы АСУ ТП;
• P&ID и перечни оборудования;
• паспорта, руководства и каталоги производителей;
• перечни I/O и кабельные журналы;
• Excel с тегами, параметрами и историческими пометками;
• выгрузки SCADA, historian, EAM или ERP;
• доступные конфигурации PLC и HMI;
• журналы ремонтов и материалы реконструкций;
• фотографии шкафов, панелей и шильдиков.

Проблема не в количестве документов. Проблема в том, что один объект может быть описан в них разными словами, а один параметр — иметь несколько значений без ясного указания, какое из них действует сейчас.

Поэтому до выбора способа миграции полезно ответить на четыре вопроса:

1. Какие источники относятся к выбранной системе или участку?
2. Какие версии документов и конфигураций доступны?
3. Какие объекты, сигналы и связи подтверждаются несколькими источниками?
4. Где требуется решение инженера, потому что источники расходятся или отсутствуют?

Почему OCR недостаточно

OCR решает узкую задачу: превращает изображение текста в машиночитаемый текст.

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

объект
→ атрибут или сигнал
→ значение и единица измерения
→ связь с документом, шкафом, PLC или SCADA
→ точное место в источнике
→ статус проверки

Допустим, в выгрузке SCADA есть тег PMP_007. Сам по себе он почти ничего не объясняет. Нужно установить:

• относится ли он к отдельному физическому объекту или к уже известному агрегату;
• каким именем объект указан в P&ID, паспорте и EAM;
• какие сигналы и каналы I/O к нему относятся;
• какая версия документа подтверждает эту связь;
• есть ли источники, которые ей противоречат.

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

Подробнее о работе с разными обозначениями одного объекта — в материале «Нормализация тегов SCADA, PLC и EAM».

Что нужно восстановить до модернизации

1. Реестр объектов

Оборудование, шкафы, приборы, контроллеры, исполнительные механизмы и технические места нужно собрать в одну структуру.

Для каждой записи полезно хранить:

• исходное наименование;
• известные альтернативные обозначения;
• тип объекта;
• источник и точное место в нём;
• связи с другими объектами;
• статус проверки;
• список конфликтов и открытых вопросов.

Главная задача реестра — не придумать единообразные названия, а установить, какие записи действительно относятся к одному физическому объекту. Похожие строки нельзя объединять автоматически: за ними могут стоять разные агрегаты, контуры или версии системы.

2. Карта сигналов и тегов

При миграции SCADA или замене PLC недостаточно перенести список тегов. Каждый сигнал нужно связать с физическим объектом, функцией, каналом, источником и документацией.

Рабочая запись может включать:

• идентификатор сигнала в PLC;
• тег в SCADA;
• тип и адрес канала I/O;
• единицу измерения и диапазон;
• аварийные границы и уставки — только при наличии подтверждённого источника;
• связанный прибор или исполнительный механизм;
• экран HMI;
• файл и позицию, подтверждающие связь;
• статус инженерной проверки.

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

3. Связи между объектами и системами

В старом инженерном архиве значительная часть связей существует только на схеме, в конфигурации или в знаниях конкретного сотрудника.

оборудование → шкаф → контроллер → модуль I/O → канал
→ сигнал → тег SCADA → экран HMI → документ-источник

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

4. Версии источников

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

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

5. Конфликты и пробелы

Самый опасный результат обработки — гладкая таблица, в которой исчезли признаки неопределённости.

Если паспорт и P&ID дают разные характеристики, нужно сохранить оба значения с источниками. Если в перечне есть сигнал, но исходная схема не найдена, это следует обозначить. Если конфигурация PLC отсутствует, нельзя делать вид, что она восстановлена по косвенным сведениям.

Как выглядит подготовка данных

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

исходные файлы и выгрузки
→ инвентаризация форматов и версий
→ извлечение объектов, значений и связей
→ нормализация обозначений
→ сопоставление записей между источниками
→ устойчивые идентификаторы и карта связей
→ источники и статус проверки для каждого значения
→ реестр конфликтов и пробелов
→ согласованная структура передачи

На входе могут быть PDF и сканы, схемы, P&ID, паспорта, Excel и CSV, выгрузки EAM и ERP, конфигурации PLC и HMI, тег-листы и материалы legacy-систем.

На выходе — данные, которые можно проверить. Упрощённая запись может выглядеть так:

{
  "id": "устойчивый идентификатор объекта",
  "source_name": "наименование из источника",
  "aliases": ["другие подтверждённые обозначения"],
  "type": "оборудование | шкаф | прибор | сигнал | документ",
  "source_file": "имя файла",
  "source_position": "лист, страница, строка или позиция",
  "confidence": "high | medium | low | blocked",
  "verification_status": "confirmed | review_required",
  "links": []
}

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

Подробно метод показан на странице «Метод RD[AI]».

Как подготовленные данные используются в проекте

Проверяемая структура может стать входом для:

• обследования и модернизации АСУ ТП;
• миграции SCADA;
• инвентаризации PLC, HMI и шкафов;
• подготовки и проверки перечня I/O;
• разработки технического задания;
• оценки объёма работ интегратором;
• внедрения EAM/CMMS и ТОиР;
• нормализации НСИ оборудования;
• подготовки данных для ERP и MDM;
• СУИД и инженерной базы знаний;
• цифрового двойника, BI и AI-сценариев;
• технического обследования перед тендером или реконструкцией.

О роли исходных данных в цифровой модели объекта читайте в статье «Готовность данных для цифрового двойника». О применении AI при анализе конфигураций и документации — в материале «AI в реверс-инжиниринге».

Где проходит граница ответственности

RD[AI] подготавливает данные, но не заменяет проектировщика, интегратора или эксплуатационную команду.

Мы можем инвентаризировать источники, извлечь и нормализовать данные, сопоставить обозначения, восстановить подтверждаемые связи, выявить конфликты и пробелы, подготовить реестры и сохранить происхождение каждого существенного значения.

Мы не заявляем по умолчанию, что выбираем архитектуру АСУ ТП, назначаем уставки и функции безопасности, проектируем систему под ключ, выполняем пусконаладочные работы, автоматически объединяем спорные записи или подтверждаем сведения, которых нет в доступных источниках.

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

Варианты применения результата для АСУ ТП, ТОиР, НСИ, СУИД и цифрового двойника собраны на странице «Применение».

С чего начать

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

Пилот должен ответить на конкретные вопросы:

1. Какие документы и выгрузки относятся к выбранному контуру?
2. Какие объекты, атрибуты и сигналы можно извлечь с указанием источников?
3. Какие связи подтверждаются доступными материалами?
4. Где есть конфликт, пробел или отсутствующая версия документа?
5. В каком формате передать результат проектировщику, интегратору или в целевую систему?

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

Актуальные условия ограниченного пилота, состав результата и критерии приёмки опубликованы на странице «Метод RD[AI]».

Вместо вывода

Контроллер, SCADA и цифровой двойник — важные части проекта. Но они не исправляют автоматически неполный архив, разные обозначения, утраченные схемы и конфликтующие версии документов.

На действующем объекте модернизация АСУ ТП начинается с источников.

Сначала нужно восстановить то, что можно подтвердить. Затем явно показать то, что не подтверждено. И только после этого принимать решения о миграции, интеграции и автоматизации.

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