Задача
Энергетика крупного объекта состоит из тысяч связанных элементов: счётчиков, выключателей, реле, датчиков, ИБП, генераторов. Данные о них разложены по разным местам, а в каком состоянии оборудование, часто знает только конкретный инженер.
Из-за этого разрыва повторяется один и тот же набор проблем. Непонятно, где возникло отклонение. Тревога приходит без контекста и без истории актива, и оператор не знает, кто должен выполнить работу. Сервисная команда не видит актуальных электрических показателей, а результаты выезда не возвращаются в энергетическую модель. Плановое обслуживание не учитывает фактическую нагрузку. Одинаковые проблемы повторяются, потому что никто не разбирает причину. Текущей картины у руководства нет: отчёт приходит с задержкой.
Решение
Платформа замыкает цикл «измерение → выявление → решение → обслуживание → подтверждение».
Модель сети. Инфраструктура описана иерархией: организация → площадка → здание → ввод → трансформатор → главный щит → секция шин → выключатель → фидер → счётчик и нагрузка. У каждого узла свои номинальные параметры, положение на однолинейной схеме, датчики, документы и история обслуживания. Показатели агрегируются снизу вверх, а из сводного отклонения можно провалиться до конкретного устройства.
Сбор. На объекте стоит локальный шлюз, который говорит с оборудованием по промышленным протоколам — Modbus TCP/RTU, BACnet, OPC UA, IEC 61850 — и продолжает буферизовать данные при потере внешней связи. Центральная часть платформы принимает телеметрию, хранит временные ряды, рассчитывает состояния и формирует события.
Живая однолинейная схема. Оператор видит текущее состояние сети: обесточенные секции, положение выключателей, ток, напряжение и активную мощность, загрузку трансформаторов и фидеров. Там же отмечены свободная мощность ниже по схеме, резервные связи, блокировки на время обслуживания и качество связи с устройствами. Цвет и анимация появляются только там, где несут оперативный смысл: направление энергии, отключённый участок, перегрузка, неизвестное состояние. Из любого элемента открывается контекстный инспектор, и общая картина остаётся на экране.
Группировка тревог. Одна физическая причина обычно порождает десятки сигналов. Модуль качества питания собирает провалы и всплески напряжения, прерывания, переходные процессы, гармоники, перекос фаз и повторные срабатывания выключателя в один инцидент. Временная шкала показывает последовательность событий и помогает определить источник нарушения и направление его распространения. Критичную тревогу нельзя закрыть, не классифицировав результат.
Оценка состояния. Индекс состояния считается из возраста и стадии жизненного цикла, интенсивности нагрузки, числа операций выключателя, тепловых режимов, повторных срабатываний, отклонения от группы однотипного оборудования и результатов последних инспекций. Это разводит календарное ТО и обслуживание по состоянию: оборудование в тяжёлом режиме поднимается в приоритете. Если данных не хватает, система показывает это индикатором достоверности, а не молча занижает риск.
От тревоги к наряду. Отклонение становится инцидентом, инцидент — нарядом по шаблону, наряд — конкретным инженером, выбранным по квалификации, электрическому допуску, территории, смене, наличию инструмента и запчастей и критичности объекта. Связь инцидента и наряда сохраняется, поэтому позже видно, какое действие устранило проблему. Если детали нет, задача уходит в ожидание, а закупка получает запрос с привязкой к активу и планируемому окну работ.
Работа на месте. Инженер получает задачу в мобильном приложении и находит оборудование по QR-коду. На экране фрагмент однолинейной схемы вокруг актива, последние тревоги и документация. Инженер проходит чек-лист безопасности и подтверждение lockout/tagout, вводит измерения, снимает фото до и после, в том числе без связи. Критичный шаг нельзя пропустить без объяснения и разрешения. Отчёт собирается из фактических данных и возвращается в цифровой паспорт актива, в аналитику и при необходимости в ERP или CMMS.
Цена ошибки. Управляемое действие в электрической сети требует повторной усиленной аутентификации, проверки текущего состояния, блокировок, кода причины, для критичных операций — подтверждения вторым человеком. Команда запрещена, если телеметрия недостоверна. Просмотр данных, подтверждение тревоги, изменение уставки и удалённое управление — разные права, а всё сделанное пишется в аудит.
На платформе шесть ролей: энергоменеджер, руководитель объекта, оператор-диспетчер, руководитель сервиса, выездной инженер и руководство. У каждой свой срез одних и тех же данных.
Результат
Тревога стала началом маршрута данных. Событие в сети больше не оседает в журнале для разбора постфактум: оно доходит до конкретного инженера вместе с историей актива и критичностью.
Оператор видит электрический контекст события и то, что обесточится ниже по схеме. Инженер приезжает с показаниями, документацией, требованиями безопасности и историей устройства. У руководителя сервиса в одном месте очередь работ, риск нарушения SLA, плановые отключения и ожидаемые запчасти.
Результат выезда возвращается в энергетическую модель. Плановое обслуживание считается по фактической нагрузке и состоянию оборудования, а не по календарю, поэтому повторяющиеся отказы видны как закономерность. Аналитика отвечает на вопросы, которые раньше не с чем было сопоставить: снизилось ли число срабатываний после обслуживания, как замена оборудования повлияла на потери и качество питания, сколько стоит простой конкретного участка.
Руководство смотрит на текущую доступность объектов, энергоёмкость и риски. Раньше для этого был отчёт недельной давности. Энергоменеджмент и сервисная команда работают на одной модели оборудования и событий: телеметрия, риск, наряд, действия инженера и подтверждённый результат складываются в единую историю эксплуатации объекта.
