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