Паспортизация оборудования и тегов: Как избежать хаоса при масштабировании АСУ ТП на новые участки
Naming convention, каталог активов, связь тегов с оборудованием и документами, паспорт узла без лишней табличной формы
Масштабирование АСУ ТП на новые линии и площадки почти всегда начинается с хорошего намерения: «скопируем проект и быстро подключим». Через полгода выясняется, что один и тот же сигнал назван по-разному, в каталоге нет владельца, а в документации на шкаф и в SCADA разные обозначения узла. Дальше растет стоимость сопровождения: каждый инцидент превращается в расследование «что это за тег».
Ниже - практический подход к паспортизации оборудования и тегов: как договориться об именах, как устроить каталог активов, как связать тег с железом и документами, и как оформить паспорт узла без бюрократической простыни.
Короткий ответ
Чтобы масштабирование не превратилось в хаос, нужны три опоры: жесткая naming convention, единый каталог активов с владельцами и паспорт узла, где каждый тег связан с физическим активом, версией проекта и регламентом обслуживания. Без этого масштабирование ускоряет не автоматизацию, а технический долг.
Почему «просто добавим теги» не работает
Типовые последствия слабой паспортизации:
·дубли и «почти одинаковые» имена в historian и SCADA;
·невозможность быстро понять, какой датчик отвечает за тревогу;
·потеря связи между однолинейной схемой, клеммником и HMI;
·долгий онбординг новых инженеров и подрядчиков;
·риск ошибочных изменений при пусках и модернизациях.
Naming convention: минимальные правила
Согласуйте шаблон имени тега заранее и не отступайте без MOC (управление изменениями). Шаблон должен быть коротким, повторяемым и читаемым для человека, который открывает тег в три часа ночи.
Пример шаблона (адаптируйте под предприятие):
<PLANT>_<AREA>_<LINE>_<UNIT>_<SIGNAL>_<ATTR>
Практика, которая реально экономит нервы:
·латиница в машинных именах, кириллица - только в описаниях для людей;
·фиксированный словарь для SIGNAL (PV, SP, CMD, ALM, STS);
·запрет свободных сокращений без записи в глоссарий;
·в метаданных тега фиксируйте версию каталога и дату последнего согласованного изменения.
Если команда не может за 10 минут объяснить новому инженеру правило именования, правило слишком сложное.
Каталог активов: что в нем должно быть
Каталог - это не «список Excel ради списка», а связная модель: от площадки до конкретного сигнала. Минимально достаточная лестница такая: площадка или цех (код, ответственный, понятные границы OT-сегмента), линия или участок (где заканчивается автоматизация одного контура и начинается другой), узел или агрегат (стабильный ID, привязка к P&ID), устройство (модель, серийник, прошивка, место установки, ссылка на поставку), сигнал или тег (имя по convention, единицы, источник, частота опроса, владелец данных).
Главное правило: у каждого тега есть владелец данных и источник истины по значению. Если владелец не назначен, тег со временем станет «сиротой» и начнет жить своей жизнью в отчетах.
Связь тега с оборудованием и документацией
Минимальная связка для промышленного узла выглядит как цепочка:
Тег -> Устройство -> Узел -> Документы -> Регламенты
Документы можно хранить где угодно - DMS, Confluence, Git LFS. Важно другое: один ID узла должен совпадать в схеме, в паспорте, в тикете и в перечне тегов. Тогда расследование инцидента не превращается в квест «найди правильное обозначение».
Что обычно привязывают к тегу словами, а не таблицами:
·P&ID или функциональная схема - чтобы понимать физику и границы ответственности;
·электрическая или клеммная схема - чтобы дойти до датчика или исполнителя;
·программа ПЛК и HMI - где тег читается, пишется, какие защиты завязаны;
·FAT, SAT, пусковые протоколы - подтверждение, что при вводе все было согласовано;
·регламент ТО - периодичность, допуски, риски при обслуживании.
Паспорт узла: что внутри (оборудование, сигналы, обслуживание)
Паспорт узла - это одна «карточка» на агрегат, которую можно оформить в любом редакторе. Ниже - содержание по блокам, без табличной сетки: просто последовательно заполните разделы.
Блок 1 - идентификация и границы. Укажите ID узла, площадку, линию, человекочитаемое имя, класс критичности (A/B/C), владельца процесса и владельца АСУ ТП. Если границы узла размыты, дальше неизбежны споры, кто отвечает за теги и изменения.
Блок 2 - состав оборудования (BOM). Для каждой позиции: тип устройства, модель, серийный номер, место установки, ссылка на документ поставки. Не обязательно перечислять весь шкаф, достаточно того, что реально влияет на измерение и управление по этому узлу.
Блок 3 - сигналы и теги. Для каждого тега коротко: имя по convention, текст для оператора, единицы измерения, источник (ПЛК, модуль, канал), частота или мертвая зона, владелец данных. Если тегов много, начните с критичных и расширяйте по мере ввода.
Блок 4 - обслуживание и изменения. Отдельно опишите виды работ (осмотр, калибровка, обновление прошивки): периодичность, кто допущен, какой чек-лист, когда последний раз выполняли. Рядом - журнал изменений: что меняли, когда, в какой версии проекта, кто согласовал, ссылка на тикет или MOC.
Такой паспорт можно копировать в Тильду секциями: каждый блок - отдельный абзац или список.
Внедрение на новом участке: короткий чек-лист
·Утвердить naming convention и глоссарий до первого тега в historian.
·Создать ID узлов и запретить «свободные» имена вне шаблона.
·Завести паспорт узла до начала ПНР, не после.
·Провести сверку «схема - клеммник - тег - HMI» выборочно по критичным цепям.
·Зафиксировать владельцев данных и процедуру изменения тегов.
Типовые ошибки
1.Разные команды называют одно и то же по-разному без реестра.
2.Каталог ведут в Excel без версионности и без связи с тикетами.
3.Паспорт есть на бумаге, но не отражен в цифровых системах.
4.Нет контроля единиц измерения и шкалы (bar vs Pa).
5.При копировании проекта не чистят «наследие» старых тегов.
Где уместен СТАБУР
Паспортизация легче выдерживается в стандартизированной архитектуре АСУ ТП: единые шаблоны узлов, повторяемые структуры тегов и предсказуемая интеграция между уровнями. На практике это проще масштабировать в платформенном подходе, включая проекты на базе решений СТАБУР.
FAQ
С чего начать, если уже есть 10 лет истории без каталога?
С критичных узлов и топ-50 тегов по инцидентам, затем расширять по зонам.
Нужен ли отдельный софт для паспортов?
Желательно, но старт возможен в связке CMMS/DMS + дисциплина ID и ссылок.
Как бороться с сопротивлением «нам некогда»?
Привяжите паспорт к пуску и к доступу подрядчиков: без ID узла нет выдачи удаленки.
Как часто пересматривать naming convention?
При каждом значимом расширении линии и не реже раза в год для глоссария.
Кто владелец каталога тегов?
Обычно роль data steward в OT совместно с владельцем АСУ ТП.