Хабрахабр

Записки IoT-провайдера. Подводные камни опроса счетчиков ЖКХ

Здравствуйте, уважаемые любители Интернета Вещей. В этой статье я бы снова хотел поговорить о ЖКХ и опросе приборов учета.

Каждый раз при таких рассказах я думаю: «ребят, удачи!»
Вы даже не представляете, куда лезете. Периодически, очередной крупный игрок телекома рассказывает, как скоро он зайдет на этот рынок и всех подомнет под себя.

Той ее части, что отвечает за диспетчеризацию. Чтобы вы понимали масштаб проблемы, кратко расскажу небольшую часть нашего опыта по разработке платформы «Умный Город».

Общая идея и первые сложности

Если говорить не про индивидуальные приборы учета, а те, что стоят в подвалах, котельных и на предприятиях, то большая часть из них сейчас оснащена телеметрическим выходом. Реже импульсным, чаще — RS-485/232 или Ethernet. Как правило, самые «хлебные» приборы учета — те, что считают тепло. Именно за их диспетчеризацию готовы платить в первую очередь.
Я уже подробно останавливался в своей статье на особенностях RS-485. Если коротко — это просто интерфейс передачи данных. По сути — требования к электрическим импульсам и линии связи. Описание пакетов идет уровнем выше, в стандарте передачи данных, который работает поверх RS-485. А что там будет за стандарт — это отдано на откуп производителю. Часто Modbus, но не обязательно. Даже если и Modbus, он все равно может оказаться несколько модифицированным.

Значит, система диспетчеризации — это набор скриптов под каждый отдельный счетчик. По сути, для каждого прибора учета нужен свой скрипт опроса, который умеет с ним «разговаривать» и опрашивать его. И некий интерфейс пользователя, в котором он может сформировать нужный ему отчет. База данных, где все это хранится.

Дьявол, как всегда, кроется в деталях. Выглядит несложно.

Начнем с первой части.

Скрипты

Как их написать? Ну, очевидно, купить прибор учета, расковырять его, научиться с ним общаться и интегрировать его в общую платформу.

Как правило, у популярного счетчика есть несколько поколений, и скрипт для каждого поколения может отличаться. К сожалению, это решение покроет лишь часть наших потребностей. Покупая что-то, вы получаете последнее поколение. Иногда чуть-чуть, иногда значительно. Оно уже не продается в магазинах. У абонента же с высокой долей вероятности окажется нечто более древнее. А менять узел учета абонент не будет.

Написание таких скриптов — это жесткая связка разработчиков софта и инженеров «на земле». Отсюда первая проблема. Сделать такое в лаборатории нереально, только в ходе работы с живыми абонентами. Мы покупали последнее поколение, писали некий начальный шаблон и дальше модифицировали его уже на реальных устройствах.

Сейчас алгоритм отработан. У нас ушло немало времени на создание такой связки. Разумеется, абонента предупреждали, если вдруг именно его счетчик оказался чуть-чуть «не таким». Начальные шаблоны постоянно корректировались и дополнялись, в зависимости от того, что мы встречали в своей практике. На время интеграции абонент работает бесплатно. При появлении такого устройства, оно подключается по стандартной схеме и скрипт опроса модифицируется по ходу. Сам процесс интеграции — довольно непредсказуемая вещь. Его уведомляют, что он пока живет в тестовом режиме. Бывает сложный процесс с выездом на объект, перелопачиванием литературы и последовательным преодолением граблей. Бывает, что нужно внести минимум исправлений.

Итог — рабочий скрипт. Задача непростая, но решаемая. Чем больше библиотека скриптов, тем легче жить.

Вторая проблема.

Технологические карты подключения

Чтобы вы осознали сложность этой работы, приведу пример. Возьмем крайне популярный теплосчетчик ВКТ-7.

У ВКТ-7 есть несколько железных решений. Само по себе название нам еще ни о чем не говорит. Что за интерфейс у него внутри?

Может быть вывод в стандартной колодке DB-9 (это RS-232). Есть разные варианты. Может даже сетевая карта с RJ-45 (в этом случае ModBus упаковывается в Ethernet). Может быть просто клеммная колодка с контактами RS-485.

Просто голый прибор учета. А может вообще ничего. Главная беда — для его установки требуется вскрыть счетчик и сорвать пломбы. В него можно установить интерфейсный выход, он продается производителем отдельно и стоит денег. Ее уведомляют, что пломбы будут сорваны, назначается день и наш инженер в присутствии представителя ресурсников выполняет необходимые доработки, после чего прибор учета вновь пломбируется. То есть в этот процесс включается ресурсоснабжающая организация.

К примеру, мы решили подключить прибор учета по проводу. В зависимости от установленного интерфейса выполняется дальнейшая доработка. Проще кабелем в нашу сеть, в изолированный VLAN. Это наиболее простой вариант, если в 100-метровой доступности есть наш коммутатор, то мудрить с LoRa – это избыточно.

Многие сразу вспомнят МОХА, но это дорого. Для RS-485/232 нужен конвертор в Ethernet. Для наших решений мы подобрали китайское решение подешевле.

Если выход сразу Ethernet, то конвертор не нужен.

Допустим, мы сами устанавливаем интерфейсный выход. Вопрос. Может облегчить себе жизнь и сразу везде ставить Ethernet?

Надо смотреть на исполнение корпуса. Не всегда такое возможно. А счетчик, напомню, стоит у нас в подвале. У него может не оказаться нужной дырки, чтобы интерфейс встал как надо. Там высокая влажность, герметичность нарушать нельзя. Или в котельной. Лучше ставить что-то, что изначально не требует больших переделок. Допиливать корпус напильником — плохая идея. Часто — RS-485 – единственный выход.

Подключен ли счетчик к гарантированному питанию? Дальше. В таком режиме он рассчитан на ручной опрос раз в месяц на три минуты. Если нет, то он живет от батарейки. Значит, нужно тянуть гарантированное питание и ставить преобразователь напряжения. Постоянное обращение к ВКТ-7 высадит его батарейку.

Это может быть внешний блок на DIN-рейку или встроенный преобразователь. Для каждого производителя счетчиков модуль питания отличается.

Номенклатура там внушительная. Получается, что на нашем складе всегда должен храниться набор различных интерфейсов и модулей питания под каждый счетчик.

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

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

Ведь счетчик мало включить в нашу сеть, на порт коммутатора еще нужно накинуть тот самый VLAN, нужно провести диагностику, сделать пробный опрос. Техкарта соседствует с общим регламентом по подключению. Весь процесс мы стремимся максимально автоматизировать, чтобы избежать ошибок и не привлекать лишние силы инженеров.

Наладили логистику. Хорошо, написали техкарты, регламент, автоматизацию.

Где еще притаились подводные камни?

Данные считываются и льются в базу.

Ему нужен отчет. Абоненту от этих цифр не жарко ни холодно. Еще лучше, если сразу в виде понятного ему отчета, который он может распечатать, поставить подпись и сдать. Желательно в том виде, в котором он привык. Значит, нужен простой и понятный интерфейс, который показывает информацию по прибору учета и может автоматически сформировать отчет.

Дело в том, что форм отчета несколько. Тут наш зоопарк продолжается. По своей сути они отражают одно и то же (потребленное тепло), но разными путями.

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

Все хорошо, если наш прибор учета установлен правильно. Тут интересный момент. Мы встречали устройства, которые думают — на дворе 2010 год. Но бывает, что монтажная организация, при установке ИТП накосячила и неправильно выставила время прибору учета. Здесь очень выручают дельты. В нашей системе это будет выглядеть как нулевые показания на текущую дату, а реальное потребление — если выбрать 2010 год. То есть мы говорим, что за прошедшие сутки натикало столько-то.

Так трудно подвести часы? Казалось бы, зачем такие сложности?

Вот именно с ВКТ-7 это приведет к полному обнулению счетчика и удалению архивов с него.
Абонент будет вынужден доказывать ресурсникам, что поставил ИТП не вчера, а уж лет пять как.

И, наконец, вишенка на торте.

Сертификация

У нас есть прибор учета, есть отчет. Между ними наша система, который этот отчет формирует. Вы ей верите?

Но как доказать, что у нас внутри ничего не изменяется, что мы не искажаем значения. Я — да. Система опроса обязательно должна иметь сертификат, который подтверждает ее непредвзятость. Это уже вопрос сертификации. Получили его и мы, хотя это стоит дорого и занимает много времени. Все крупные системы, такие как ЛЭРС, Я Энергетик и прочие подобный сертификат имеют.

Но за это придется платить разработчику. Конечно, всегда можно срезать угол и купить нечто готовое. То есть мы будем вынуждены делиться с ним частью нашего пирога. И разработчик может попросить не только вступительный взнос, но и абонплату.

Зачем оно все?

Главная проблема не в этом. Разработка своей системы — это тоже очень дорого и в разы тяжелее. Однако, она дает важное преимущество. Мы четко понимаем как это работает. Мы легко ее масштабируем, мы можем ее модифицировать, если вдруг появилась такая нужда. Абонент получает более полный сервис, а с нашей стороны стопроцентный контроль за процессом.

В него мы вложили год жизни наших разработчиков и полевых инженеров. Именно потому мы и выбрали второй путь. Зато теперь мы четко понимаем работу всей цепочки.

Оглядываясь назад я понимаю, что без полученных знаний просто не смог бы правильно интерпретировать нештатное поведение того или иного счетчика.

Алармы по превышениям потребления, отчет об авариях. Кроме того, на основе системы диспечеризации можно построить нечто большее. У нас скоро готовится выход мобильного приложения.

Мы пошли еще дальше и в нашу платформу (а иначе это уже не назовешь) добавили возможность принимать обращения от жителей, возможность управления нашими «умными домофонами», тут же контроль уличного освещения и еще несколько проектов, о которых я пока не писал.

Но результат того стоит. Все это сложно, мозгосломно и долго. Абоненты получают готовый всеобъемлющий продукт.

Пройдет ли?
Тут вопрос. Каждый оператор, который планирует идти в ЖКХ, обязательно встанет на этот путь. Как я писал выше, тут нужна именно связка работы в поле и разработки. Дело даже не в деньгах. Если ваши разрабы сидят в Москве, а подключения делаются в Новосибирске, то ваше время на готовый продукт значительно растягивается. Не все крупные игроки привыкли к подобному.

Но одно я знаю четко — прийти и занять долю рынка исключительно деньгами не получится. Время покажет, кто удержится на этом рынке, а кто скажет — да ну его куда подальше! Этот процесс требует нешаблонных подходов, хороших инженеров, копания в регуляторике, общения с ресурсниками и абонентами, постоянного выявление и преодоления граблей.

S. В этой статье я сознательно сосредоточился на тепле и не упоминаю электричество или воду. P. Если у нас импульсный выход — там свои нюансы, вроде обязательных сверок после установки. Так же я описываю подключение по кабелю. Описать всю нашу платформу и этапы ее разработки в одной статье просто нереально. Может быть такое, что проводом не дотянуться, тогда в ход идет LoRaWAN.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»