Здравствуйте, уважаемые поклонники Интернета вещей.
В этой статье мне бы снова хотелось поговорить о ЖКХ и обследовании приборов учета.
Время от времени очередной крупный игрок в сфере телекоммуникаций говорит о том, что скоро он выйдет на этот рынок и подомнет всех под себя.
Каждый раз, когда слышу подобные истории, думаю: «Ребята, удачи!» Ты даже не знаешь, куда идешь.
Чтобы вы понимали масштаб проблемы, кратко расскажу небольшую часть нашего опыта разработки платформы «Умный город».
Та его часть, которая отвечает за диспетчеризацию.
Общая идея и первые трудности
Если речь идет не об индивидуальных приборах учета, а о тех, которые есть в подвалах, котельных и на предприятиях, то большинство из них сейчас оборудовано телеметрическим выходом.Реже импульсный, чаще — 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. Многие сразу вспомнят MOHA, но это дорого.
Для наших решений мы выбрали более дешевое китайское решение.
Если на выходе напрямую Ethernet, то преобразователь не нужен.
Вопрос.
Допустим, мы устанавливаем вывод интерфейса самостоятельно.
Можете ли вы облегчить себе жизнь и сразу везде установить Ethernet? Это не всегда возможно.
Надо смотреть на конструкцию кузова.
Возможно, у него нет необходимого отверстия для правильной установки интерфейса.
Напомню, что стойка находится у нас в подвале.
Или в котельной.
Там высокая влажность, пломбу невозможно нарушить.
Дорабатывать корпус напильником – плохая идея.
Лучше установить то, что изначально не требует серьезных переделок.
Часто RS-485 является единственным выходом.
Дальше.
Подключен ли счетчик к гарантированной мощности? Если нет, то он работает от аккумулятора.
В этом режиме он рассчитан на ручной опрос раз в месяц в течение трёх минут. Постоянное обращение к ВКТ-7 приведет к разрядке его аккумулятора.
Это значит, что нужно обеспечить гарантированное питание и установить преобразователь напряжения.
Модуль питания различен у каждого производителя счетчика.
Это может быть внешний блок на DIN-рейке или встроенный преобразователь.
Получается, что на нашем складе всегда должен храниться набор различных интерфейсов и модулей питания для каждого счетчика.
Ассортимент там впечатляет. Разумеется, все это в конечном итоге будет оплачено абонентом.
Но он не будет ждать месяц, пока придет нужное устройство.
И ему нужна смета на подключение здесь и сейчас.
Так что технологический задел ложится на наши плечи.
Все, что я описал, превращается в четкую карту технических подключений, чтобы местные инженеры не думали о том, с каким зверем они столкнулись в соседнем подвале и что им нужно, чтобы оно работало.
Техническая карта примыкает к общим правилам подключения.
Ведь недостаточно включить счетчик в нашу сеть; нам еще нужно подключить ту же VLAN к порту свитча, нужно провести диагностику, сделать тестовый опрос.
Мы стремимся максимально автоматизировать весь процесс, чтобы избежать ошибок и не привлекать лишних инженеров.
Окей, мы написали технические карты, регламенты, автоматизацию.
У нас налажена логистика.
Где еще есть скрытые подводные камни?
Данные считываются и передаются в базу данных.Эти цифры не делают абонента ни горячим, ни холодным.
Ему нужен отчет. Желательно в том виде, в котором он привык.
Еще лучше, если это будет сразу в виде понятного ему отчета, который он сможет распечатать, подписать и сдать.
Это значит, что нам нужен простой и понятный интерфейс, отображающий информацию на счетчике и умеющий автоматически формировать отчет. Здесь наш зоопарк продолжается.
Дело в том, что существует несколько форм отчетов.
По своей сути они отражают одно и то же (потребляемое тепло), но по-разному.
Одни абоненты отчитываются в абсолютных значениях (то есть в графе потребления тепла пишутся значения, начиная с установки счетчика), другие в дельтах (это когда мы пишем потребление за период времени без привязки к начальные значения).
Фактически они используют не единые стандарты, а устоявшуюся практику.
Бывали случаи, когда абоненты видят все нужные им значения (количество потребляемого тепла, объем подаваемого и отводимого теплоносителя, разность температур), но столбцы в отчете расположены не в правильной последовательности.
Отсюда следующий шаг – отчет должен быть настраиваемым.
То есть подписчик сам выбирает, что и в какой последовательности идти и какие ресурсы есть в его документе.
Здесь есть интересный момент. Все хорошо, если наш счетчик установлен правильно.
Но бывает, что монтажная компания при установке ИТП допустила ошибку и неправильно установила время счетчика.
Нам попадались устройства, которые думают, что сейчас 2010 год. В нашей системе это будет выглядеть как нулевые показания на текущую дату и как реальное потребление, если мы выберем 2010 год. Здесь очень помогают дельты.
То есть мы говорим, что за последние 24 часа произошло столько всего.
Казалось бы, почему такие трудности? Неужели так сложно завести часы? Именно с ВКТ-7 это приведет к полному сбросу счетчика и удалению с него архивов.
Абонент будет вынужден доказать сотрудникам ресурса, что он установил ИТП не вчера, а пять лет назад. И, наконец, вишенка на торте.
Сертификация
У нас есть счетчик и отчет. Между ними находится наша система, которая формирует этот отчет. Вы ей верите? Я делаю.Но как нам доказать, что внутри нас ничего не меняется, что мы не искажаем смысл.
Это уже вопрос сертификации.
Система опросов должна иметь сертификат, подтверждающий ее беспристрастность.
Подобный сертификат имеют все крупные системы, такие как LRS, I Energy и другие.
Мы его тоже получили, хотя это дорого и занимает много времени.
Конечно, всегда можно сэкономить и купить что-то готовое.
Но за это придется заплатить застройщику.
Причем разработчик может запросить не только вступительный взнос, но и абонентскую плату.
То есть мы будем вынуждены разделить с ним часть своего пирога.
Почему все это?
Это не главная проблема.Разработка собственной системы также очень дорога и гораздо сложнее.
Однако это дает важное преимущество.
Мы четко понимаем, как это работает. Мы легко его масштабируем, можем модифицировать, если вдруг возникнет такая необходимость.
Абонент получает более полное обслуживание, а с нашей стороны 100% контроль над процессом.
Поэтому мы выбрали второй путь.
В него мы вложили год жизни наших разработчиков и инженеров-экспертов.
Но теперь мы четко понимаем работу всей цепочки.
Оглядываясь назад, я понимаю, что без полученных знаний я бы просто не смог правильно интерпретировать аномальное поведение того или иного счетчика.
Кроме того, на базе диспетчерской системы можно построить нечто большее.
Сигнализация превышения потребления, отчет об авариях.
В ближайшее время готовимся выпустить мобильное приложение.
Мы пошли еще дальше и добавили в нашу платформу (по-другому это не назовешь) возможность получать запросы от жильцов, возможность управлять нашими «умными домофонами», управлять уличным освещением и еще несколько проектов, о которых я не писал.
примерно еще.
Все это сложно, мозголомно и отнимает много времени.
Но результат того стоит. Подписчики получают готовый комплексный продукт. Каждый оператор, планирующий выход в сферу ЖКХ, обязательно пойдет по этому пути.
Пройдет ли это? Вот вопрос.
Дело даже не в деньгах.
Как я писал выше, здесь необходимо сочетание полевой работы и развития.
Не все крупные игроки к этому привыкли.
Если ваши разработчики находятся в Москве, а подключения производятся в Новосибирске, то время получения готового продукта у вас существенно продлевается.
Время покажет, кто останется на этом рынке, а кто скажет – ну и черт с ним! Но одно я знаю точно: прийти и занять долю рынка исключительно за деньги не получится.
Этот процесс требует нестандартных подходов, хороших инженеров, вникания в регуляторы, общения с ресурсными сотрудниками и подписчиками, постоянного выявления и преодоления проблем.
P.S. В этой статье я намеренно сосредоточил внимание на тепле и не упомянул электричество или воду.
Также описываю кабельное соединение.
Если у нас импульсный выход, то есть свои нюансы, например, обязательная проверка после установки.
Возможно, до провода невозможно дотянуться, тогда в дело вступает LoRaWAN. Описать всю нашу платформу и этапы ее развития в одной статье просто нереально.
Теги: #iot #Интернет вещей #ИТ-инфраструктура #ИТ-законодательство #стандарты связи #ЖКХ #приборы учета
-
Игра World Of Tanks — Сложное Приложение
19 Oct, 24 -
Как Создать Проект Django Из Шаблона
19 Oct, 24 -
Achi — Замена Моп
19 Oct, 24 -
Создание Мира. Взгляд Айтишника
19 Oct, 24
