Решения для учета воды в «умном городе»: Что сейчас делают по-другому глобальные коммунальные предприятия?

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

Решения для учета воды в «умном городе» сочетают в себе точные счетчики, АМИ-коммуникация, облачные платформы, правила тревоги, интеграция биллинга, и рабочие процессы на местах. Главное изменение — не только удаленное чтение. Улучшена видимость по всему Северному Рейну-Вестфалии., жалобы клиентов, инженерные решения, и платежные данные.

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

Роль счетчиков воды в умных городах?

Умный город не может управлять невидимой водой. Если счетчиковый парк слеп, Северный Рейн-Вестфалия, выставление счетов, и жалобы остаются реактивными.

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

Почему я рассматриваю счетчик как узел данных

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

Бытовой ультразвуковой интеллектуальный счетчик может выполнять эту роль, поскольку он использует технологию статических ультразвуковых измерений и может быть интегрирован с технологиями Интернета вещей для интеллектуальных коммунальных предприятий и приложений «умного города».. Некоторые интеллектуальные ультразвуковые счетчики также поддерживают обнаружение утечек., обнаружение сухой трубы, двунаправленное измерение расхода, дисплей тревоги, и варианты связи, такие как беспроводной M-Bus и NB-IoT..

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

Для улавливания при низком расходе, Я всегда отделяю начальный расход от Q1.. Упомянутый ультразвуковой расходомер имеет заявленный сверхнизкий пусковой расход до 0.001 м³/час. Начальный расход означает точку, в которой счетчик начинает регистрировать объем.. Q1 означает минимальный расход в заявленном диапазоне метрологической точности.. Это не то же самое.

Если пример жилого дома DN15 имеет Q3 = 2.5 м³/ч и R = 400, затем:

Этот пример является расчетным предположением., не универсальная ценность. Я бы проверил окончательный третий квартал, Ведущий, 1 квартал, и запуск потока из спецификации выбранного продукта до утверждения тендера.

От чтения мануалов до AMI и не только?

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

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

Что меняется после развертывания AMI

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

Я не говорю, что AMI предоставляет данные в реальном времени, если цикл отчетности действительно не поддерживает это.. Многие проекты используют ежедневную загрузку., ежечасные загрузки, или сигналы тревоги на основе событий. Цикл отчетности влияет на срок службы батареи, стоимость сети, и объем данных платформы. В руководстве к системе YOUNIO NB-IoT, установщик может установить начальный период чтения и загрузки, и облачная платформа фиксирует тех, кто устанавливает рекорды. Это показывает, почему важен контроль конфигурации..

Я также проверяю связь перед принятием установки. Руководство NB-IoT включает процесс мобильной CRM для проверки счетчиков., проверить сигнал NB-IoT, и проверьте онлайн-журналы устройства. Он также отмечает, что тестирование сигнала может занять около одной минуты.. Это практичная деталь. Если проверка сигнала пропущена, проект может позже получить «не читать»” жалобы, которые на самом деле являются проблемами сети или настройки.

AMI также меняет ответственность команды. Команда замерщиков по-прежнему заботится о точности. ИТ-специалисты заботятся об идентификаторах устройств, облачные записи, кибербезопасность, и устойчивость платформы. Биллинг заботится о сопоставлении учетных записей клиентов. Полевые бригады заботятся об установке и сигнале. Если одна команда работает одна, проект становится хрупким.

Как данные меняют NRW и структуру жалоб?

Традиционные жалобы NRW часто бывают эмоциональными и запоздалыми.. Данные «умного города» делают их более конкретными, но также выявляет больше операционных пробелов.

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

Почему умные утилиты видят разные жалобы

В традиционных коммунальных услугах, клиент может жаловаться только тогда, когда счет слишком высок, слишком низко, или отсутствует. Затем утилита проверяет счетчик., запись чтения, а иногда и труба. Жалоба носит широкий характер. Это можно назвать «проблемой счетчика».” даже если основной причиной является утечка, неверные данные аккаунта, незаконное соединение, расчетный счет, или плохой монтаж.

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

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

Для земли Северный Рейн-Вестфалия, Я не рассматриваю счетчик как единственное решение. NRW включает реальную утечку, очевидная потеря, недорегистрация счетчика, незаконные связи, ошибки при выставлении счетов, ошибки в базе данных клиентов, и несвоевременный ремонт. Решения по измерению воды в «умных» городах могут способствовать сокращению NRW за счет улучшения улавливания низкого расхода., удаленный сбор данных, сигналы тревоги, и видимость района. Счетчик поддерживает работу, но это не заменяет управление давлением, ремонт утечки, незаконный контроль соединения, или очистка данных.

Межведомственное сотрудничество (Инженерное дело, ЭТО, Биллинг)?

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

Для измерения умного города требуется инженерное обеспечение, ЭТО, выставление счетов, обслуживание клиентов, и полевые группы для обмена данными об устройствах, записи об установке, правила тревоги, логика выставления счетов, и процессы рассмотрения жалоб. AMI – это операционная модель, не только покупка счетчика.

Департаменты должны поделиться одной версией правды

Во время планирования ОИМ я обычно задаю один простой вопрос.: кому принадлежат данные после загрузки счетчика? Если ответ неясен, проект не готов.

Инженерным разработкам могут потребоваться данные, связанные с давлением., тенденции потребления, районный дисбаланс, и сигналы утечки. Некоторые ультразвуковые интеллектуальные счетчики могут дополнительно включать датчик давления., в зависимости от конфигурации. ИТ-специалистам нужна безопасность устройств, доступ к серверу, Стабильность API, резервное копирование базы данных, и статус связи. Биллинг требует подтвержденных показаний, сопоставление аккаунтов, тарифная логика, и обработка исключений. Служба поддержки требует четких объяснений для пользователей.

Рабочий процесс установки NB-IoT показывает, почему это сотрудничество важно. Установщик может использовать мобильное CRM-приложение для проверки счетчика воды., тестовый сигнал, проверить онлайн-логи, установить начальное чтение, и установите период загрузки. Если установщик установил неправильное начальное показание, биллинг получает неверные данные. Если ИТ-специалист не подтверждает журналы устройства, при выставлении счетов могут отсутствовать показания. Если облачная платформа фиксирует изменения настроек, тогда утилите нужны правила, определяющие, кто может изменять параметры и как эти изменения проверяются..

Я предпочитаю определить общий рабочий процесс рассмотрения жалоб до развертывания.. Например, «высокий счет»” жалоба должна привести к пересмотру кривой потребления, обзор тревог, проверка данных счетчика, проверка платежного счета, и выездной осмотр при необходимости. «Читать нельзя” жалоба должна привести к проверке журнала сигналов перед заменой счетчика. Это позволяет избежать ненужной замены и помогает коммунальному предприятию определить, является ли проблема метрологической., коммуникация, платформа, или данные клиента.

Тематические исследования: Города, совершившие скачок?

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

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

Что я вижу в успешных проектах

Я буду описывать их как шаблоны полей, а не как конфиденциальные имена клиентов.. Первый шаблон — это утилита «сначала пилотный проект».. Эта утилита не устанавливается 100,000 метров сразу. Он выбирает несколько зон с разными зданиями., давление воды, типы клиентов, и условия сигнала. Команда проверяет показания счетчиков, сигнал, журналы устройства, период загрузки, импорт счетов, и работа с жалобами клиентов. Это более надежно, чем предположение, что один результат применим везде..

Второй шаблон — утилита прозрачности данных. Эта утилита позволяет проектировать, ЭТО, выставление счетов, и службу поддержки клиентов, чтобы увидеть тот же статус счетчика. Когда клиент жалуется, команда проверяет историю чтения, статус тревоги, онлайн-журналы, и платежные записи. Руководство по системе NB-IoT поддерживает этот тип операций, поскольку оно включает проверку журнала устройства и запись изменений настроек в облако..

Третий образец — утилита, ориентированная на NRW.. Он не ожидает, что счетчики устранят NRW.. Он использует интеллектуальные счетчики для поддержки анализа района., ночные проверки, улавливание при низком расходе, сигнализация утечки, и более быстрая реакция поля. Умный ультразвуковой счетчик с обнаружением утечек, обнаружение сухой трубы, двунаправленный поток, и IoT-коммуникации могут стать полезным вкладом в этот рабочий процесс..

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

Эти коммунальные предприятия не покупают «больше технологий».” ради самого себя. Они меняют операционную модель данных.

Архитектура: IoT, Облако и клиентские порталы?

Умный счетчик без архитектуры — это всего лишь электронный счетчик. Система должна безопасно перемещать данные с поля на место принятия решения..

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

Как я картографирую систему

Прежде чем утвердить список счетчиков, я рисую архитектуру. Метр - это только первый слой. Он может включать в себя измерительный корпус, электронный модуль, батарея, отображать, память, сигналы тревоги, клапан при необходимости, и модуль связи. Упомянутый ультразвуковой интеллектуальный счетчик поддерживает такие коммуникационные технологии, как беспроводной M-Bus и NB-IoT.. Это дает варианты, но проект должен выбрать вариант, соответствующий местному охвату, расходы, и потребности платформы.

Для NB-IoT, счетчик обычно зависит от зоны покрытия оператора, Настройка SIM-карты или связи, регистрация устройства, период загрузки, и обработка облачной платформы. В руководстве YOUNIO описано тестирование сигнала NB-IoT., проверка онлайн-журналов устройства, настройка начального чтения, и настройка периода загрузки через мобильное приложение CRM. Эти шаги показывают, что интеллектуальные измерения требуют ввода в эксплуатацию на месте., не только заводская доставка.

Для систем LoRa или LoRaWAN, Я проверяю размещение шлюза, источник питания, обратная связь, препятствия, подземные камеры, и подключение платформы. Для M-Bus или RS485, Я проверяю конструкцию кабеля, мощность концентратора, регистрация адреса, и доступ для обслуживания. Я не говорю, что один метод связи лучше всего подходит для каждого города..

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

Практическая дорожная карта для коммунальных предприятий, запускающих проекты «умного города»?

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

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

Мой пошаговый метод проекта

Я начинаю с постановки задачи. Утилита пытается уменьшить расчетные показания, поддержка сокращения NRW, улучшить прозрачность для клиентов, сократить время рассмотрения жалоб, или модернизируйте биллинг? Ответ влияет на тип счетчика, метод связи, частота передачи данных, дизайн платформы, и полевой рабочий процесс.

Затем я определяю границу измерения. В тендере должен быть указан размер метра., Q3, Значение R, 1 квартал, начальный расход, положение установки, температурный класс, условия давления, уровень защиты, срок службы батареи, метод связи, цикл отчетности, функции сигнализации, интерфейс платформы, и тестовые документы. Iso 4064-2 подключен к ISO 4064-1 и OIML R49-1 для метрологических и технических требований к счетчикам воды.. Он также охватывает тестирование всего счетчика воды и отдельное тестирование измерительного преобразователя и калькулятора, где это применимо..

Следующий, Я запускаю пилотный проект. Пилотный проект должен включать в себя различные здания, материалы труб, палаты, зоны давления, и условия сигнала. Я проверяю установку, точность считывания в определенных условиях, уровень сигнала, журналы устройства, период загрузки, импорт счетов, отображение клиентского портала, и реакция на тревогу. Тест сигнала, указанный в руководстве NB-IoT, журнал устройства, и этапы настройки периода загрузки являются хорошим напоминанием о том, что необходимо проверить в полевых условиях..

Я также определяю, что означает успех. Успешный проект учета воды в «умном городе» — это не только высокая скорость считывания показаний.. Это должно сократить количество посещений вручную, которых можно избежать., быстрее диагностировать жалобы, улучшить качество платежных данных, поддержка анализа NRW, и создайте общее представление данных для всех отделов.

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

Заключение

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