Именование тегов и инженерные шаблоны для крупных проектов SCADA

Какую цену позже платят за хаос в именах тегов

• Дубли и столкновения: две станции несут Pump1_Run, отчёты смешиваются, и по событию нельзя понять, с какого объекта оно пришло
• Экраны и теги расходятся: подпись на HMI переписали, а сам тег остался сокращением электрика, поэтому поиск неисправности требует двух словарей
• Текст аварии нельзя получить из имени тега: каждое сообщение набрано вручную, и переименование на стороне процесса не доходит до аварийного списка
• Расширение копирует хаос: следующий участок клонируют с первого вместе с плохими именами, и стоимость наведения порядка растёт с каждой линией
• Передача становится устной традицией: только исходный инженер знает, что T12 — температура нагнетания насоса A, и этого человека уже нет на площадке

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

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

Схема именования — не вопрос вкуса. Это договор, из которого выводятся каждый тег, каждый текст аварии и каждый объект на экране. Если поле пропущено, поздние скрипты не фильтруют по зоне, не собирают текст аварии и не отличают технологическое значение от команды.

Четыре поля ниже — нижняя граница, которую нужно решить до создания первого тега. Разделитель, длина и набор символов входят в ту же схему: смешанный парк ПЛК и поздние выгрузки в базу наказывают вольную орфографию. В рамках одного проекта у нас реализован сбор почти 80 000 переменных с 366 единиц оборудования в одной сети. Эта цифра описывает конкретную работу. Это не типичный объём проекта и не потолок, который мы ставим в каждый договор. Она показывает, что правило должно держаться при большом числе точек, а не только когда на пилотной линии несколько сотен тегов.

• Зона (площадка, линия или корпус): географическая принадлежность актива — завод, цех, линия или код насосной. Без этого одинаковые машины в разных залах сталкиваются именами
• Оборудование (агрегат, блок, машина): сам актив — компрессор, конвейер, насосная группа — чтобы сигналы одной машины стояли рядом
• Сигнал (измерение или функция): что читают или пишут — обратная связь по работе, давление нагнетания, авария, уставка
• Тип (класс): аналоговый вход, аналоговый выход, дискретный вход, дискретный выход, расчёт, авария, уставка — чтобы архив, экраны и аварийный движок обрабатывали точку по её природе
• Разделитель, длина и набор символов: один разделитель (подчёркивание — распространённый приём), длина, которую принимают и самый короткий ПЛК, и архив, без пробелов и локальных знаков, ломающих выгрузку

Инженерные шаблоны, которые должны быть до первого экрана

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

Помимо указанного масштаба сбора, мы выполняли инженерную проработку аварийной сигнализации на проекте почти с 30 000 аварийных точек. Эти числа — факты конкретных работ, а не размер, который мы ждём от каждой площадки, и не рекламное обещание, сколько тегов платформа «возьмёт» в любом договоре. Верхний предел числа точек на сегменте сети следует из полосы, периода опроса и запаса сервера; его записывают в шаблоны ниже, а не обнаруживают на пусконаладке.

• Таблица распределения I/O: шкаф, слот, канал, тип сигнала, инженерный диапазон и имя тега-приёмника, замороженные до начала адресации ПЛК
• Перечень точек (точечная ведомость): эталон — имя тега, описание, зона, оборудование, адрес, тип данных, класс опроса, единица, признак аварии. Одна строка на точку, один владелец файла
• Спецификация HMI / экранов: какие экраны есть, какие теги они связывают, навигация и представление аварий — пишется до графики, а не после
• Карта адресов и сети: какой контроллер владеет каким диапазоном, сколько устройств на сегменте, и верхний предел числа точек, который сегмент несёт при согласованном периоде опроса

Плохое имя, проблема, которую оно создаёт, и рекомендуемая структура

Таблица ниже — рабочий чек-лист, а не универсальный стандарт. Шаблон в третьем столбце: AREA_EQ_SIGNAL_TYPE. Четыре поля заполняют по своему объекту, затем фиксируют орфографию, разделитель и длину, чтобы каждый поздний импорт шёл по тому же договору.

Рекомендуемая структура — стартовый шаблон. Набор символов, длину и конкретные коды зоны и оборудования согласовывают с площадкой по фактическим маркам ПЛК и архиву.

Аварийные и технологические точки ведут как два списка

Технологическая точка отвечает, каково значение. Аварийная — нужно ли кому-то действовать. Смешивать их в одном теге кажется экономным на нескольких сотнях точек и перестаёт управляться на нескольких тысячах. Аварийный список тогда наследует все сокращения технологической ведомости, и поздняя рационализация не получает чистого перечня.

Приоритеты, подавление и архивирование сброса — отдельная конструкция. Мы разобрали её в колонке по рационализации аварий SCADA; этот раздел тот учебник не повторяет. Здесь нужна развилка, без которой та работа не стартует: две совокупности, два владельца, один договор именования, из которого текст аварии собирается из зоны, оборудования и сигнала.

• Разные совокупности: каждому технологическому тегу, которому нужна авария, ставят парный аварийный тег или запись аварии, связанную именем — не точку двойного назначения
• Текст аварии собирают из полей имени: зона, оборудование и сигнал дают читаемое сообщение, поэтому переименование обновляет и тег, и текст
• Разные владельцы: технологические теги ведут с I/O и архивом; аварийные — эксплуатация, с приоритетом и правилом закрытия; два списка пересматривают с разной периодичностью
• Класс аварии не копируют в каждое технологическое имя: класс живёт в записи аварии. Проставить HH, H, L, LL в тысячи технологических тегов превращает позднюю переоценку приоритетов в массовое переименование

На проекте почти с 30 000 аварийных точек удержалась именно эта развилка, а не более крупная графика. Большинство площадок до такого числа не дойдёт. Разделять совокупности всё равно стоит уже на нескольких сотнях аварий: в этот момент работа ещё недорогая.