Опыт использования LoRaWAN в системе АСКУЭ в реальных городских условиях

В этой статье изложены результаты опытной эксплуатации системы коммерческого поквартирного учёта энергоресурсов (далее АСКУЭ) в реальных городских условиях на базе отечественного оборудования LoRaWAN.

Наша компания с 2010 г. занимается созданием систем коммерческого и технического учета в ЖКХ. Мы давно и успешно используем «классические» каналы связи и оборудование для создания систем учета. Одним из знаковых проектов компании было создание крупнейшей на тот момент в РФ системы коммерческого общедомового и поквартирнгого учета на 1200 многоквартирных домов в г. Саранске в 2014 году.

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

Что нам понравилось в технологии LoRaWAN?

  • Во-первых, в 10-ки раз большая заявленная дальность передачи радиосигнала по сравнению с другими беспроводными технологиями, используемыми для телеметрии ( RF433, ZigBee, Z-Wave), что на практике позволяет сократить количество базовых станций.
  • Во-вторых, технология позволяет устанавливать на приборы учёта и датчики маломощные радиомодемы, запитанные от батареи, при этом срок автономной работы устройств составит 5-10 лет. Например, квартирные водосчётчики всегда были для нас проблемой при подключении. А в случае LoRaWAN можно организовать сбор данных в санузле квартиры не испортив ремонт, без подведения сигнальных и питающих линий. Причём батареи, в случае LoRaWAN, хватит до следующей замены прибора учета.
  • В-третьих, использование собственных базовых станций и нелицензируемых частот. Нет оплаты за передачу данных, в отличие от использования GSM и ее NB-IoT инкарнации.

Постановка задачи и описание тестовой системы учета


Итак, мы хотели проверить работу оборудования LoRaWAN. Нам, в некотором смысле, повезло сразу встретить коллег из Новосибирской компании «Вега-Абсолют» на IoT конференции. Немного изучив доступные в начале 2017 года решения мы поняли, что доступно либо западное оборудование, либо то, что делает «Вега-Абсолют» и несколько стартапов. Было выбрано оборудование «Вега-Абсолют» и сформулированы задачи опытной эксплуатации. Решили провести ее в г. Пенза.

Мы использовали:

  • Модемы СИ-13-485 для работы по RS485 в режиме «прозрачного канала»;
  • Модемы со счетчиками импульсов Вега СИ-11;
  • Базовую станцию Вега БС-1;

Задачи опытной эксплуатации были сформулированы следующим образом:


  1. Провести испытания информационного обмена с «ходовым» прибором учёта электроэнергии по RS-485 через радиомодем СИ-13-485, изучить особенности опроса;
  2. Построить систему учета с квартирных приборов учета электроэнергии и воды и провести долговременную опытную эксплуатацию в городских условиях.

Архитектура системы учета выглядела так:



Информационный обмен с электросчетчиком Меркурий-206 по RS-485 через «прозрачный канал связи»


Для тестирования использовался следующий стенд:
  • Сервер АСКУЭ, который подключается к серверу LoRaWAN IOT Vega Server;
  • Каналообразующее оборудование базовой станции (БС) LoRaWAN — Модем СИ-13-485;
  • Электросчётчик Меркурий-206 PLNO (подключение по RS485).



Для организации прозрачного канала связи на тестовом стенде было установлено и настроено специальное ПО, организующее «прозрачный канал» связи с подключенным по радиоканалу LoRaWAN прибором. Анализ трафика показал, что обмен с прибором происходит очень медленно, как правило, ответ прибора приходит с задержкой 11 сек. При такой задержке итоговый период опроса прибора очень сильно зависит от количества опрашиваемых параметров прибора учета, это обусловлено особенностями протокола обмена LoRaWAN (сколько параметров прибора учета можно получить за один запрос) и от необходимости чтения исторических данных из архива прибора учета.

Так, при чтении 15 оперативных параметров с прибора Меркурий-206, общий период обновления данных в среднем составил 70 секунд, однако итоговый период опроса сильно зависит от выбранного состава параметров(тегов) и в худшем случае период опроса 15 тегов составил 160 секунд.

При чтении исторических данных время получения суточного архива активной энергии по одной точке учета по тарифу составило 11 секунд, скорость получения профиля мощности составила 48 «получасовок» каждые 70 секунд.

Дополнительно для анализа стабильности обмена был организован длительный прогон на 3-е суток, в ходе которого производился непрерывный опрос параметров подключенного счетчика с целью выявления возможных проблем. В результате возникли проблемы с опросом и нам рекомендовали производить опрос значительно реже. В результате опрос параметров прибора драйвером был настроен на опрос раз в 1 час и работал в течении 5 дней. За период такого прогона наблюдалась сравнительно устойчивая связь (примерно 0 — 3 обрывов в сутки). При этом, в течении времени прогона было зафиксировано однократное получение некорректных данных по одному параметру. Скорее всего, это произошло из-за спутывания пакетов ответов устройства (в протоколе обмена Меркурий 206 отсутствует возможность валидации пакета ответа).

Можно сделать следующие выводы по результатам испытаний:

  1. Учитывая большие задержки канала связи, информационный обмен с приборами должен вестись не часто, для задач диспетчеризации тестируемая технология опроса по прозрачному каналу и со стандартными протоколами обмена ПУ не применима.
  2. При настройке чтения архивов не рекомендуется опрашивать с прибора архивы, предполагающие большой объем данных (профили мощности и т.п.).

Кроме того, основываясь на нашем опыте работы с протоколами других приборов учета, наблюдаемые задержки в «прозрачном канале» связи LoRaWAN — RS-485 могут сделать невозможным чтение архивов с некоторых других типов приборов (теплосчетчики ТЭМ-106, ТЭМ-104, чтение профилей мощности с Меркурий 230 и некоторые другие).

Эти испытания дали теоретически ожидаемые результаты и наглядно показали почему в IOT устройствах уходят от классического для систем АСКУЭ режима запрос-ответ и переходят к режиму опроса на стороне «умного» счетчика и инициативной отправке данных с ПУ на сервер по расписанию или событию.

Испытания системы сбора данных с приборов учёта с импульсным выходом


Эксперимент проводился на объектах г. Пензы. Целями эксперимента являлись:

  1. Определение реальной зоны покрытия одной базовой станции в городских условиях и на открытой местности (пригород);
  2. Проверка уровня сигнала внутри многоквартирных домов в зоне покрытия (влияние стен и перегородок на уровень сигнала);
  3. Подбор антенны и места установки антенны базовой станции, определение влияния антенны на покрытие и уровень сигнала.

Первый этап. Проверили зону покрытия вне помещений c антенной 4.5 dBi


Нашим отделом внедрения была установлена базовая станция Вега БС-1 и антенна 4,5 dBi, которая, на тот момент, шла в комплекте с БС. Провели предварительное тестирование зоны покрытия вне помещений. На карте ниже показаны результаты нашего первого тестирования: зеленым отмечен успешный прием сигнала БС, красным — нет.



Выводы: Зона покрытия с комплектной антенной далека от максимальной для LoRaWAN и, в нашем случае, составила 2 км. Стало понятно, что надо тщательней подходить к установке базовой станции, заявленные 10 км без хорошей антенны и минимального радиопланирования, даже на открытой местности, получить нельзя.

Второй этап. Проверили зону покрытия внутри зданий с антенной 4.5 dBi


На той же инсталляции БС решили сразу проверить работу счетчика импульсов Вега СИ-11 внутри жилого дома на расстоянии 422 метров от БС. Точки учета были внутри жилого дома, на 1 этаже. Мы ожидали другого, но испытания показали, что сигнал приема отсутствует!

Связались с тех. поддержкой Веги, обновили ПО, но связь так и не удалось установить. Провели анализ результатов и повторно провели тестирование в предполагаемых местах установки приборов. Наконец удалось получить передачу пакетов с места не закрытого капитальной стеной от направления на БС. В итоге, удалось получить положительный результат и передача пакетов прошла успешно. Кроме того, мы поместили СИ-11 непосредственно на первый этаж того же дома, на кровле которого установлена БС, передача пакетов также прошла успешно (хотя не рекомендуется размещать модемы под БС).



Выводы по результатам второго этапа: можно использовать существующее решение при съеме данных в том же МКД, на котором установлена БС, а также в МКД и объектах, расположенных в радиусе 300-400 м от места установки БС, но в каждом случае необходимо предварительное тестирование радиопокрытия. Кроме того, не рекомендуется устанавливать модемы за капитальной стеной более 500 мм по направлению к БС.

Результаты были явно ниже наших ожиданий, провели консультации со специалистами Веги и пришли к очевидному теперь выводу: нужна хорошая антенна БС с большим коэффициентом усиления, надо корректно смонтировать БС вдали от БС сотовых операторов и других помех, грамотно разместить ее на кровле и повторить испытания.

Третий этап испытаний с антенной 10 dBi


Установили новую антенну 10 dBi Московской компании «Радиал» на 868 МГц, место установки БС — на крыше 12 этажного дома. К сожалению, «жизнь внесла коррективы» и нам разрешили установить антенну и БС на кровле дома на торце тех. постройки здания только таким образом:



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



Таким образом, можно ожидать прохождение сигнала от модемов, размещенных, например, в частном секторе, на удалении максимум до 5-6 км от БС с антенной 10 dBi, размещенной на крыше 10-12 этажного МКД.

Долговременные испытания и статистика прохождения пакетов


Затем мы провели долговременное испытание со сбором статистики прохождения пакетов счетчиков импульсов СИ-11 с ПУ Меркурий. В испытаниях было задействовано 4 точки учета ( 679м ,422м, 243м, 126м от БС ), показанных ниже:



Отметим, что в точке на расстоянии 422 м за капитальной стеной в 600 мм, в которой с антенной 4,5 dBi связи раньше не было, с новой антенной 10 dBi связь появилась, но с потерями 10% пакетов. Таким образом, в радиусе примерно 700 м уровень сигнала достаточно высокий ( RSSI ~115), что позволяет устанавливать модемы в данной зоне внутри МКД и надежно передавать данные.

На фото ниже показано типичное место установки прибора учета на лестничной клетке в этажном щитке для приборов учета ЭЭ, к которому подключен модем:



Отображение данных с прибора учета Энергомера СЕ101 в системе. Передача данных осуществляется через Модем СИ-11-1. На графике Видно данные по активной энергии (D,H):



За период первичных испытаний, длительностью 144 часа, с передачей пакетов раз в час в феврале 2018 года были получены следующая статистика по передаче данных:

  • количество успешно полученных пакетов — 132 из 144 что составляет 91,6% ;
  • количество неудачных попыток — 12, из них по ошибкам:
  • TOO_LARGE_GW_PING_ERR (слишком большой пинг до БС) — 8 шт.;
  • LATENCY_ERR (задержка БС-сервер) — 4 шт.

Если посмотреть статистику за более длительный период времени с 21.02.2018 по 18.03.2018, было потеряно 142 пакета из 624 ~ 23% с настройками модема по умолчанию. В связи с этим, параметр модема «Количество переповторов пакета» был увеличен до 5 (то есть столько раз модем будет отправлять пакет, пока не получит подтверждение от базовой станции). В результате удалось почти полностью исключить потери пакетов. Считаем, что данный параметр надо выставлять от 3 до 5, в зависимости от требований к расходу батареи.

Тестирование скорости разряда встроенного элемента питания счетчиков импульсов LoRaWAN СИ-11


В течение трех месяцев было проведено тестирование встроенных элементов электропитания модемов СИ-11:

Период тестирования: 19.03.2018 — 07.06.2018 (почти 3 месяца):

  1. Условия тестирования: модемы установлены в щитах на лестничной площадке МКД, постоянная плюсовая температура (по данным с термодатчика внутри модема от +26 до +29 гр.С);
  2. Частота опроса: СИ-11 №383336384B368A0F — 1 раз в час, СИ-11 №3530373550376114 — раз в 6 часов.

Таблица с данными по оставшемуся заряду батареи:



Выводы: учитывая полученные результаты, можем оценить время работы в аналогичных условия до 100% разряда батареи:

  • при опросе 1 раз в час — 45 месяцев или 3,7 года
  • при опросе 1 раз в 6 часов — 135 месяцев или 11,2 года

Общие выводы по результатам испытаний


Технология «рабочая». Оборудование на лето 2018 уже коммерчески доступно в ассортименте и отечественного производства. Технология должна применяться с учетом ее особенностей:

  1. оборудование LoRaWAN надежно работает в радиусе 1 км от БС внутри зданий и до 5-6 км вне помещений если ее «правильно приготовить»;
  2. отлично работает с устройствами, специально спроектированными под LoRaWAN, и плохо(медленно) работает в режиме прозрачного канала RS-485 из-за больших задержек в канале;
  3. требует грамотной установки БС, впрочем как и любое оборудование радиосвязи. Правильное размещение БС и хорошая антенна — залог успеха;
  4. заявленные 6-10 лет работы от батареи вполне достижимы при правильной настройке периодичности сбора данных.
  5. технология идеально подходит для монтажа внутри квартир для учета ХВС и ГВС, а также ЭЭ, но там есть альтернатива в виде PLC
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 18

    0
    технология идеально подходит для монтажа внутри квартир для учета ХВС и ГВС, а также ЭЭ, но там есть альтернатива в виде PLC

    Как человек, который наладил over9000 (в прямом смысле) точек учёта по PLC — могу сказать — весьма так себе альтернатива. Даже современные PLC решения, вроде DLMS, сильно забиваются помехами. Особенно эпично выглядят китайские люминесцентные лампочки, когда один такой саботажник может «погасить» весь подъезд. И фиг её найдёшь. Плюс проблемы организационного характера, когда делается межфидерный ВЧ объединитель, а его отключают чуваки, занимающиеся контролем качества электроэнергии, потому что «через него ж помехи прут». Ну и совсем чудесные вещи вроде передачи PLC сигнала через высоковольтный трансформатор через высокую сторону на другую подстанцию О_о
      0
      Согласен, есть такие проблемы. Надо знать куда и какие УСПД и ПУ ставить. Но опять же это только ЭЭ.
      С другой стороны у наших коллег 150 тыс точек учета поквартирного на PLC Меркурия и Энергомеры в пропорции 70% на 30% стабильно работает на задачах коммерческого учета. Опрос 97-100% точек учета хотя бы раз в месяц. Схема такая «родной» УСПД Меркурия или Энергомеры с PLC на МКД и квартирные ПУ в щитках по этажам.
        0
        150К точек учёта на меркурии? Это где такое? По моему опыту — меркурий не работает от слова совсем. Neuron работает. Iskraemeco — ну так. Если бы не дебильные концентраторы — хорошо бы работала (я её налаживал). А меркурий и энергомера, по крайне мере в 2010 году были днищем. В 2013-14 годах наши коллеги на них пытались сделать город — смонтировано 3500 точек учёта, опрашиваются 300… Ну, так себе результат.
        Опять же — опрос «раз в месяц» — это как? Когда получится? Тогда такой учёт не получится свести. Нужны же срезы на конкретное число. Чтобы правильно ОДН рассчитать.
          0
          Самарская область. все работает без проблем в МКД. PLC ПУ Меркурия и ПУ Энергомеры в пропорции 70% на 30% как я писал выше. Еще смежная сетевая организация использует Матрицу, по ним отзывы неоднозначные. Работает это значит надежно снимают показания для начисления в биллинге.
      +1

      Интересное исследование, спасибо!


      при опросе 1 раз в 6 часов — 135 месяцев или 11,2 года

      Я бы на вашем месте не стал делать такую интерполяцию фактически по двум точкам. Если честно посчитать погрешность такого вычисления, то получится ±50 месяцев :) Да и в первой колонке видно, что зависимость нелинейная.

        0
        В целом, все верно и очень похоже на правду. за одним исключением.
        1) Батарея имеет неприятную особенность стареть. И потихоньку разряжаться с течением времени.
        2) Батарейным замерам Веги доверять нельзя. В связи с рядом конструктивных особенностей СИ-11 считает разряд батареи статистически.
        Т.е. Вега считает, допустим, что ее модуль может отправить n-пакетов до разряда. Модуль знает, что он отправил m-пакетов. Исходя из этого, модуль рассчитывает свой заряд батареи.
        По факту, разряжаются они так — 99 ->98->97->...->64->63->5 и модуль умер.
          0
          Батарея имеет неприятную особенность стареть. И потихоньку разряжаться с течением времени

          Тионил-хлорид. Саморазряда практически нет. Там другая опасность есть, если на ней нет нагрузки или она маленькая (до 500 мА хотя бы кратковременно) батарея пассивируется (контакты покрываются оксидной плёнкой) и в один прекрасный момент она просто перестаёт быть источником питания.
          Батарейным замерам Веги доверять нельзя. В связи с рядом конструктивных особенностей СИ-11 считает разряд батареи статистически.

          В силу особенностей работы того-же тионил-хлорида других способов измерить остаточный заряд нет. Другой вопрос, что алгоритм расчёта остаточного заряда может быть реализован некорректно.
          0
          А какая скорость передачи данных?
            0
            По скорости нет однозначного ответа, поскольку поток данных прерывистый. И технология рассчитана на такой режим работы: накопил немного данных измерений, отправил в определенное окно времени и потом «молчим в эфире». Максимум чего можно достичь это примерно 200 байт в секунду.
            0
            Крайне интересно, спасибо! Скажите по секрету — нет ли планов потестировать оборудование других отечественных производителей? Очень интересно было бы почитать (не реклама, с компанией никак не аффилирован) про тест стрижей и их протокол xnb. У себя они описывают все очень вкусно, было бы здорово увидеть независимые тесты в реальных условиях.
              0
              Сейчас конкретных планов нет, Стриж позволяет работать только через их облако поэтому мы пока не рассматривали их как альтернативу, хотя если будет потребность у заказчика мы проведем интеграцию.
              +2
              Использование антенны с 10 dBi это хорошо, но по разрешению на 868 МГц Эффективная излучаемая мощность мощность должна быть не более 25 мВт. Значит придется уменьшить мощность передатчика, чтобы вписаться в разрешение. А это приведет к уменьшению радиуса действия БС.
                0
                Да, нужно компенсировать усиление антенны мощностью передатчика. В БС даже настройка такая есть. Однако на прием то она все равно лучше будет работать. И как правило проблема со слабым сигналом с датчиков. И тут как раз важен прием на БС
                0
                Скажите, а это все работает на каком SF?
                  0
                  Здравствуйте. Не понял вопрос, что такое SF?
                    +1
                    Добрый день из прошлого года)

                    SF — spreading factor. Коэффициент расширения спектра, важнейший параметр работы сетей LoRaWAN. От него зависит время пакета в эфире и максимальный размер полезной информации в пакете. Так же к нему привязана помехоустойчивость. Некий аналог MCS в wi-fi.

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

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

                Самое читаемое