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

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

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

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

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

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

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

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

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

Скрипты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: habr.com