На территории бывшего механического завода работают десятки арендаторов, а разница между показаниями счетчика на вводе и суммой показаний счетчиков арендаторов доходила до 15–20 тыс. кВт·ч в месяц. Что сделала управляющая компания, чтобы найти пропавшие киловатт-часы, где их обнаружила и как окупила затраты на систему, расскажем в статье.

«Где деньги, Зин?»
Объект — бывший механический завод. Производство здесь работало до 2011 года, после чего его перенесли в Колпино на новую площадку. Старую территорию, пока ее дальнейшая судьба не определена, использует управляющая компания «Стайл»: помещения сдают под склады, офисы и различные производства. Всего на площадке около 50–60 арендаторов. Площади сильно различаются: кто-то арендует около 10 м², кто-то — 1000 м².
Электроэнергию управляющая компания (УК) оплачивает по счетчику на вводе. На линиях питания каждого арендатора и самой УК установлены отдельные счетчики, по показаниям которых выставляют счета за потребленную электроэнергию. Приборы устанавливали в разное время, поэтому они различаются как по моделям, так и по способу получения телеметрии: часть имеет цифровой интерфейс, часть — импульсные выходы.
Взаиморасчеты вела бухгалтерия. Каждый месяц между суммой показаний счетчиков потребителей и показаниями счетчика на вводе оставалась заметная разница — порядка 15–20 тыс. кВт·ч. Около 3 тыс. кВт·ч приходилось на потери в трансформаторе, но оставшиеся 12–17 тыс. кВт·ч требовалось объяснить.
Дополнительную погрешность в расчеты вносило ручное снятие показаний. Сотрудник обходил всех арендаторов, но они не всегда находились на месте. При этом точно определить величину потерь можно только при более-менее одновременном снятии показаний со всех счетчиков.
Иногда арендаторы запрашивали дополнительную электрическую мощность. По собираемым вручную данным определить фактическую загрузку линий питания было невозможно, поэтому приходилось брать в аренду дорогостоящее оборудование и отдельно мониторить нагрузку. Это занимало время и стоило денег.
В результате УК решила создать систему телеметрии: получать все доступные данные со счетчиков, сохранять их и анализировать. Сделать это требовалось «малой кровью»: отдельно инвестировать в проект никто не собирался, система должна была окупить себя сама. Проектом занялся Алексей — главный энергетик УК.

Дополнительные фото

Архитектура системы
В качестве центрального устройства выбрали контроллер Wiren Board 8. Его штатное ПО получает данные со счетчиков, обрабатывает их с помощью скриптов, выводит информацию в веб-интерфейс и при необходимости может отправлять уведомления на мобильные устройства персонала.
К тому моменту на всей территории предприятия уже работала Ethernet-сеть: примерно годом ранее ее проложили для системы видеонаблюдения. Эту сеть использовали и для передачи показаний счетчиков.
На территории установили небольшие телекоммуникационные шкафы с Ethernet-коммутаторами, блоками питания и преобразователями интерфейсов WB-MGE v.3. От них к счетчикам развели локальные линии RS-485. Для Modbus-устройств шлюз поддерживает преобразование Modbus RTU в Modbus TCP, а для счетчиков с другими протоколами — прозрачную передачу данных через TCP.
Для счетчиков с импульсными выходами использовали WB-MCM8 — восьмиканальные модули счетных входов. Они подсчитывают импульсы и сохраняют значения счетчиков в энергонезависимой памяти, поэтому при отключении питания показания не теряются. В киловатт-часы значения пересчитывает скрипт на контроллере.
Почему не WB-MAP?
Изначально для учета планировали использовать 12-канальные счетчики WB-MAP12E. Но против выступили арендаторы: им важно иметь возможность подойти к своему счетчику и самостоятельно увидеть показания на дисплее. У WB-MAP дисплея нет.
Поэтому в системе использовали счетчики «Меркурий», а также «Энергомера» и Vector.
Для «Меркуриев» в ПО контроллера есть готовые шаблоны. Они подошли и для счетчиков Vector.

Дополнительные фото




Что измеряется?
Со счетчиков с интерфейсом RS-485 можно получать не только накопленную энергию, но и множество других параметров. Их тоже сохраняют в базе данных контроллера.

Глубина истории зависит от настроек группы: частоты записи и ограничений на количество записей.
Куда сохраняются данные
Для хранения используется сервис wb-mqtt-db, входящий в состав ПО контроллера. Для разных типов данных настроили разные правила хранения, чтобы не заполнять базу избыточными записями.

На скриншоте выше показаны настройки группы каналов «Мощность в моменте». Каналом здесь называется один сохраняемый параметр.
Для всей группы в базе данных выделено 355 800 записей. Когда лимит исчерпан, каждая новая запись заменяет самую старую. Дополнительно действует ограничение для каждого отдельного канала — 4320 записей.
Значения записываются в базу раз в 30 минут, то есть каждые 1800 с. Данные со счетчиков приходят чаще, но не пропадают: в течение этого интервала сервис рассчитывает среднее, максимальное и минимальное значения, которые затем сохраняет.
Если мощность не меняется, опорное значение записывается раз в час — каждые 3600 с. Во время пауз в записи сервис постепенно накапливает возможность сохранять внеочередные значения — максимум 30. При поступлении новых данных он использует этот запас для записи без ожидания обычного интервала.
Такие групповые настройки позволяют по-разному хранить историю различных сигналов. В данном случае настроили четыре группы.
Что показал анализ данных
После того как накопились данные, Алексей начал анализировать таблицы и графики.

Ошибки монтажа
Первым делом Алексей обратил внимание на аномальные значения коэффициента мощности: встречались отрицательные и просто неправдоподобные значения.
Причиной оказалось неправильное подключение измерительных трансформаторов. Часть трансформаторов была подключена не к тем фазам, часть установили задом наперед. На трансформаторе есть стрелка, которая должна быть направлена в сторону нагрузки.
Ошибки исправили, и результат проявился сразу: учитываемое потребление одного из арендаторов выросло примерно в 2,5 раза. Именно этот арендатор давал основную часть расхождения между общим счетчиком и суммой внутреннего учета.
Арендатор новым показаниям не поверил и провел независимую проверку. Результаты подтвердились.
Реактивная мощность
Помимо активной энергии УК контролирует реактивную мощность и соблюдение установленных для объекта требований. Нарушение допустимого соотношения реактивной и активной мощности может привести к повышающему коэффициенту к плате за услуги по передаче электроэнергии.
Для контроля УК предоставляет энергоснабжающей организации почасовой профиль реактивной мощности. Раньше такой отчет формировали вручную по данным, которые тоже снимали вручную. Теперь данные для него собираются автоматически.
Когда завод работал как единое предприятие, для его электрических потребителей были установлены установки компенсации реактивной мощности — УКРМ, которые поддерживали требуемый коэффициент мощности PF.
После того как помещения начали сдавать в аренду, характер нагрузки сильно изменился. У арендаторов работают металлообрабатывающие станки, сварочные посты, электродвигатели, вальцы, гибочное оборудование. Часть оборудования устарела.
Теперь УК видит PF каждого арендатора и может проследить, как он меняется во времени.

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

Если ночью потребление оказывается выше обычного, можно проверить, не осталось ли включенным оборудование. А это и пустые потери, и угроза пожара.
Так УК обнаружила самодельный термопот, который добавлял арендатору около 10 000 рублей расходов в месяц. В другом случае нашли нагреватель, который сотрудники арендатора оставляли включенным, хотя делать это было запрещено.
Пока такой анализ специалист УК выполняет вручную. В дальнейшем его, возможно, автоматизируют и добавят рассылку уведомлений.
Лучше знать, чем предполагать
Теперь у УК есть инструмент, который показывает фактическую нагрузку на линиях питания арендаторов. Это позволяет арендаторам экономить. Как?
Пример 1. У арендатора работает производство с расчетной мощностью потребителей около 100 кВт. В цехе установлены плазменный резак и другое оборудование. Потребовалось дополнительно поставить покрасочную камеру и компрессор мощностью 22 кВт.
Расчет показывал, что потребуется дополнительная мощность и соответствующие электромонтажные работы. Но накопленная статистика показала, что пиковое потребление не достигает даже 40 кВт. Существующей мощности оказалось достаточно.
Пример 2. Кабель, идущий к арендатору, требовал замены. Сечение жил существующего кабеля составляло 50 мм². Статистика показала, что фактическая мощность арендатора существенно ниже расчетной, поэтому сечение нового кабеля можно уменьшить вдвое. При длине линии 170 м разница в стоимости получилась существенной. Чему арендатор был очень рад.
Сама УК теперь также знает фактическую загрузку трансформатора и электросети и видит доступный резерв мощности для подключения новых арендаторов.

Дополнительные фото

«Куда бы еще сходить с этим тортиком?»
Инфраструктура системы телеметрии позволяет развивать ее дальше, в том числе в сторону автоматизации. К любому сегменту RS-485 можно подключать дополнительные Modbus-модули, а в любой точке Ethernet-сети — установить еще один WB-MGE и добавить новый сегмент RS-485. После этого на контроллере остается сконфигурировать устройства и написать необходимую логику.
Например, так автоматизировали освещение в длинном коридоре офисного корпуса. В рабочее время там включается основное освещение, а в нерабочее — только дежурное.
Для этого добавили компактный релейный модуль WB-MRM2-mini v.2 и написали простой скрипт.
Текст скрипта
defineVirtualDevice("lighting_automation", { title: "Lighting automation", cells: { auto: { type: "switch", value: false }, relay1_k1: { type: "switch", value: false }, relay1_k2: { type: "switch", value: false }, relay2_k1: { type: "switch", value: false }, relay2_k2: { type: "switch", value: false } } }); var relays = { relay1: "wb-mrm2-mini_33", relay2: "wb-mrm2-mini_207" }; function isWeekend() { var d = new Date().getDay(); return d === 0 || d === 6; } function desiredState(cellName) { var hour = new Date().getHours(); if (isWeekend()) { return cellName.indexOf("k1") !== -1; } if (hour >= 8 && hour < 19) { return cellName.indexOf("k2") !== -1; } return cellName.indexOf("k1") !== -1; } function setRelay(groupName, k1State, k2State) { var devName = relays[groupName]; dev[devName + "/K1"] = k1State; dev[devName + "/K2"] = k2State; dev["lighting_automation/" + groupName + "_k1"] = k1State; dev["lighting_automation/" + groupName + "_k2"] = k2State; } function syncAutoState() { if (!dev["lighting_automation/auto"]) return; setRelay("relay1", desiredState("relay1_k1"), desiredState("relay1_k2") ); setRelay("relay2", desiredState("relay2_k1"), desiredState("relay2_k2") ); } defineRule("lighting_automation_auto_sync", { whenChanged: "lighting_automation/auto", then: function () { syncAutoState(); } }); defineRule("lighting_automation_timer", { when: cron("*/1 * * * *"), then: function () { syncAutoState(); } }); // Ручное управление через виртуальные ползунки defineRule("lighting_automation_manual_relay1_k1", { whenChanged: "lighting_automation/relay1_k1", then: function (newValue) { if (dev["lighting_automation/auto"]) return; dev["wb-mrm2-mini_33/K1"] = !!newValue; } }); defineRule("lighting_automation_manual_relay1_k2", { whenChanged: "lighting_automation/relay1_k2", then: function (newValue) { if (dev["lighting_automation/auto"]) return; dev["wb-mrm2-mini_33/K2"] = !!newValue; } }); defineRule("lighting_automation_manual_relay2_k1", { whenChanged: "lighting_automation/relay2_k1", then: function (newValue) { if (dev["lighting_automation/auto"]) return; dev["wb-mrm2-mini_207/K1"] = !!newValue; } }); defineRule("lighting_automation_manual_relay2_k2", { whenChanged: "lighting_automation/relay2_k2", then: function (newValue) { if (dev["lighting_automation/auto"]) return; dev["wb-mrm2-mini_207/K2"] = !!newValue; } });
Теперь подобное управление планируют сделать и на других участках.
Заключение — экономика
После подключения счетчиков к контроллеру управляющая компания получила возможность удаленно и одновременно получать показания. Это упростило ежемесячное сведение общего учета с внутренними счетчиками арендаторов и дало возможность отдельно смотреть потери между высокой и низкой сторонами трансформатора.
Все затраты на систему составили около 300 тыс. рублей. Экономический эффект оценили в 1,5–2 млн рублей в год. Все довольны.
zatim
Еще из заголовка стало понятно, что основная причина расхождений - реактивная мощность. Для крупных потребителей она учитывается, для мелких и бытовых потребителей - нет.
Непонятно, а в чем проблема была оставить УКРМ для централизованной компенсации? Это всяко проще чем считать отдельно активную и реактивную мощности для каждого арендатора, постоянно пинать их, как то заставлять принимать меры по компенсации.
Еще непонятно, как именно изменился характер нагрузки? До этого там было производство и потом также производство. Производства обычно всегда генерируют индиктивную составляющую.
nemen
В большей степени основной причиной расхождений в показаниях были не правильно собранные учёты с косвенным трансформаторным подключением. (Провода одного цвета в пучке, и замаркерованны А1, А2, но на самом деле не соответствовали клеммам) Такие аномалии сразу стали видны в интерфейсе по отрицательному и не симметричному показателю косинуса фи (pf). И якобы энергией отдачи, а не потребелнием. Что и стало поводом для переборки шкафов учёта.
По УКРМ. Эффективно ставить компенсаторы под конкретный потребитель и его параметры, такие как колличество кВар , колличество ступеней, и при наличии больших гармоник защиту УКРМ.
Если оставить УКРМ на вводе, они буду не очень точно и вовремя переключать ступени. Так как тип нагрузки может меняться в одном цеху металлообработки значительно. В зависимости от того, какой станок в работе. Ранее когда стояли только трёхфазные моторы на вытяжные камеры и работали ровно и весь рабочий день, просчитать можно было общую укрм на ввод.
Арендаторы так же часто переезжают, расширяются , меняется тип оборудования и производства, и тд., а электроустановка остаётся. Вся сеть на заводе была проложена и построена под конкретные потребности, которые сейчас совсем не совпадают с фактическими нагрузками и подключенным оборудованием.
Есть помещения где работают только трёхфазные электро моторы и там скомпенсировать не сложно. Но большинство помещений и потребителей имеют смешанные нагрузки. К оплате представляется превышение допустимого коэффициента ( тангенс фи,) в нашем случае это 0.4 по высокой стороне и 0.35 по низкой для арендаторов. Иначе придется делить общую реактивку на всех арендаторов, даже тех кто ее не генерирует. Поэтому очень удобно точечно мониторить каждого потребителя в отдельности.