Гетерогенные PLC/RF модемы для систем сбора данных +18


AliExpress RU&CIS

Эволюция плат модемов за 8 лет разработки
Эволюция плат модемов за 8 лет разработки

Умные счетчики стали реальностью в нашей жизни и главная их особенность – автоматический сбор данных. Как организовать сбор данных в многоквартирных домах и причем здесь гетерогенный PLC/RF модем? Как за 8 лет пройти путь от идеи до серийного производства, столкнуться с общими для области техническими ограничениями и разработать для их обхода собственное решение? Что лучше, передавать информацию по линиям питания (PLC) или использовать беспроводной радио канал (RF). На эти и другие вопросы постараюсь ответить в данной публикации!

Предыстория

Восемь лет назад (в 2013 году) мы вышли на рынок приборов учета, запустив в серийное производство счетчик электрической энергии Милур-104.

Первая версия счетчика электроэнергии
Первая версия счетчика электроэнергии

Со временем стало ясно, что общий тренд направлен не на отдельные приборы учета, а на создание автоматизированных систем учета энергоресурсов. Многие производители начали закладывать в свои приборы учета различные интерфейсы для снятия показаний и удаленного управления. В качестве интерфейсов можно было встретить различные решения, начиная от классического для промышленности RS-485, до различных реализаций радиочастотных и PLC трансиверов, были даже экзотические варианты вроде Ethernet.

В основу наших следующих счетчиков (Милур 105/305) легла модульная конструкция, позволяющая добавлять интерфейс передачи данных в виде отдельной печатной платы на этапе производства, что позволило унифицировать конструкцию модельного ряда приборов учета.

Основным недостатком большинства систем АСКУЭ различных производителей были проблемы с качеством связи. Часто о необходимости автоматизированного сбора данных задумываются уже на последнем этапе, когда протягивать дополнительные кабели (даже небольшие для RS-485) уже желания или возможностей нет, поэтому выбор делался в сторону использования беспроводных/радиочастотных интерфейсов, либо использования уже существующей кабельной сети распределения электроэнергии, посредством PLC интерфейса. Для обоих способов характерна повышенная чувствительность к внешним помехам. Также, учитывая растущий спрос к приборам, произведенным во всем известной соседней стране, которые к сертификации по радиочастотгому диапазону, уровню внеполосных помех (обычно вторая и третья гармоники) и электромагнитной совместимости относятся, мягко говоря, довольно вольно, мы получаем высокую зашумленность как радиоканала, так и электросетей, что отрицательно сказывается на надежности данных каналов связи.

Гетерогенная система

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

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

В 2014 году Международным Союзом Электросвязи был выпущена новая версия стандарта ITU-T G.9903, более известного под названием PLC-G3, который и лег в основу PLC части гетерогенного модема.

PLC интерфейс

Физический уровень PLC реализован программно на основе собственного ЦОС процессора 1967ВН044. Это младший брат процессора 1967ВН028, который часто используется в качестве основного вычислителя радарной продукции. ЦОС Процессор 1967ВН044 обладает вдвое меньшим объемом оперативной памяти и вдвое меньшей максимальной тактовой частой, но при этом фактически является не просто мощной числодробилкой, а оснащен широким набором периферии, что позволяет использовать его в качестве основного микроконтроллера для создания изделия. При этом наличие в его системе команд инструкций для ускорения ЦОС вычислений позволяет выполнять программный синтез и разбор сигналов, необходимых для реализации физического уровня PLC.

PLC сигнал в диапазоне CENELEC-B
PLC сигнал в диапазоне CENELEC-B

Сам стандарт PLC-G3 разрабатывался с учетом ненадежности проводки, используемой в качестве передачи данных и поэтому содержит широкий диапазон средств для снижения вероятности возникновения ошибок, уменьшения их влияния на передаваемые данные и коррекции в случае повреждения.

Для передачи данных используется фазовая модуляция (BPSK/QPSK/8PSK), что накладывает меньшие требования к мощности передатчика по сравнению с решениями на основе частотной модуляции и позволяет работать при более низком соотношении сигнал/шум за счет увеличения вычислительных затрат на устройстве. Данные передаются одновременно по нескольким поднесущим посредством ортогонального мультиплексирования (OFDM).

Структура физического уровня PLC
Структура физического уровня PLC

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

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

Радиоканал

В качестве дополнительного интерфейса, а также для связи с устройствами, подключенными к изолированным электросетям или не подключенными к ним вообще, используется радиоканал в диапазоне 868МГц. Поскольку короткие волны диапазона 2.4ГГц хуже распространяются внутри помещений, а также еще на этапе начала разработки в нем уже было "довольно тесно" (а сейчас в городской черте там стало совсем печально) то выбор стоял в основном между 433 и 868МГц. Оба диапазона позволяли использование устройств общего назначения, так что делить эфир с китайской продукцией всевозможного назначения пришлось бы в любом случае, но 868МГц казался на тот момент более перспективным и в результате мы выбрали его, и как со временем оказалось — не ошиблись.

В отличии от PLC части, радиоканал на данный момент у нас реализован на готовом трансивере CC1200, производства Texas Instruments, но в будущем предполагается разработка собственной радиочастотной ИС в том числе и для данного применения.

Спектр радиосигнала PLC/RF модема
Спектр радиосигнала PLC/RF модема

После принятия соответствующего решения ГКРЧ в ПО модемов была добавлена поддержка десятка низкоскоростных (1.2-9.6 Кб/c) каналов в диапазоне 868,7-869,2МГц для передачи данных и двух высокоскоростных (125 Кб/c) канала в диапазоне 866-868МГц для настройки и обновления самих устройств.

Для передачи данных на физическом уровне в радиоинтерфейсе используется модуляция 2GFSK, для уменьшения ширины спектра и снижения внеполосных излучений. На физическом уровне используется FEC из стандарта IEEE 802.15.4 для повышения надежности работы канала связи. Систему каналов можно использовать как для сосуществования различных сетей на одном объекте, так и для локального разделения подсетей для снижения утилизации эфира и повышения общей пропускной способности сети.

Развертывание и проблемы

Все описанное выше разрабатывалось и тестировалось с положительными результатами на территории компании Миландр, но все самое интересное началось после установки пробных партий на реальные объекты.

В конце 2017 года была собрана первая опытная партия из нескольких PLC/RF модемов для установки в 17-этажный многоквартирный жилой дом в г. Томск. На момент отправки были некоторые опасения, касательно совместной работы с модемами квартирных радиомодулей, но реальность показала, что сложностей может оказаться больше, чем изначально предполагалось.

PLC

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

  2. Любой реальный объект — он "живой", на нем присутствуют люди, которые могут включать и выключать различное оборудование, и состояние среды передачи данных может значительно меняться в течении суток.

  3. Наибольшую проблему для PLC сигнала представляют не помехи от использования бытовых приборов, а поглощение сигнала за счет входных емкостей импульсных блоков питания. В электрической сети с большим количеством ИИП уровень PLC сигнала довольно быстро опускается до отрицательных значений SNR, в таких условиях полезный сигнал еще можно вытащить (за счет использования PSK) и восстановить (за счет кодов коррекции), но даже при этом доля поврежденных пакетов начинает довольно быстро составлять более 50%.

  4. Электрическая сеть имеет распределенную структуру и сигнал отлично без искажений проходящий бухту кабеля 300м может легко не пройти по стояку из подвала до 10 этажа обычного многоквартирного дома.

  5. В электрической сети объекта уже могут быть PLC устройства, использующие различные диапазоны спектра и типы модуляции (например S-FSK).

Спектры PLC сигнала и помех на различных объектах (можно открыть в новой вкладке для увеличения)
Спектры PLC сигнала и помех на различных объектах (можно открыть в новой вкладке для увеличения)

RF

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

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

Состояние эфира в диапазоне 868МГц на одном из объектов

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

Решения

Одним из лучших решений в плане радиоканала считалось решение на основе LoRa. Для наших устройств дальность стабильной связи на открытом пространстве достигала 5-7 км, максимальная была около 10 км, для LoRa заявлялись сходные характеристики. Но поскольку специфика систем АСКУЭ в большинстве случаев предполагает установку приемопередающих устройств в помещениях, то было проведено сравнение работы радиоканала для нашей системы, состоящей из УСПД Milan IC 02 и квартирного радиомодуля и системы на основе LoRa+LoraWAN, где в качестве шлюза использовался Tektelic KONA Micro, с датчиком Tektelic KONA Home Sensor. Мощность шлюза и УСПД была установлена на +25dBm, а обоих датчиков на +14dBm, трансиверы LoRa были настроены на режим SF7/125кГц, в нашей сети использовался канал 9.6Кб/c шириной 25кГц.

Сравнение качества сигнала RF части модема и LoRa
Сравнение качества сигнала RF части модема и LoRa

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

Многие производители систем учета предлагают следующие способы в качестве решения проблем качества каналов:

  1. Установка дополнительных шлюзов и базовых станций.

  2. Установка ретрансляторов PLC или RF сигнала.

  3. Использование датчиков или приборов учета в качестве ретрансляторов.

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

В качестве альтернативны было выбрано решение с честной маршрутизацией пакетов через модемы, установленные в приборы учета. Это позволяло аккуратно и надежно настроить маршруты пакетов до устройств, прямая связь с которыми была недостаточно стабильна или полностью отсутствовала. Для 17-этажного одноподъездного дома, служившего тестовым объектом, максимальная цепочка составила три промежуточных устройства между УСПД и опрашиваемым прибором. Добавление маршрутизации позволило почти полностью решить проблемы со связью с дальними от УСПД устройствами. Конфигурация модемов проводилась при помощи УСПД удаленно, постепенно записывая дерево маршрутов от ближних устройств к дальним.

Окно конфигурации дерева маршрутов PLC/RF сети
Окно конфигурации дерева маршрутов PLC/RF сети

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

Поэтому параллельно с испытаниями в компании Миландр, совместно с компанией Астрософт велась разработка обновленной версии системы, основанной на отечественной ОСРВ и использующей динамическую маршрутизацию. В качестве алгоритма маршрутизации стандартом 6LoWPAN (который мы в том числе начали реализовать) предлагалось использовать алгоритм реактивной маршрутизации LOADng. Классические алгоритмы проактивной маршрутизации, применяемые в компьютерных сетях требуют регулярного обмена пакетами между каждой парой связанных устройств в сети. Поскольку сейчас реализация компьютерных сетей связи в домах уже почти однозначно ассоциируется с технологией Ethernet и витой парой, а также типом связи устройств точка-точка (порт-порт), то кажется что что проблем с поддержкой регулярного обмена пакетами не будет. Но если вспомнить, что оба используемых нами интерфейса представляют из себя общую среду передачи данных, разделяемую между всему устройствами в зоне видимости (в том числе и не принадлежащими к нашей системе), то возникает закономерный вопрос — не превысит ли трафик накладных расходов на поддержание сети трафик полезных пакетов с опросом приборов учета.

Пакеты в PLC линии и работа алгоритма CSMA/CA - Широковещательный запрос к четырем приборам
Пакеты в PLC линии и работа алгоритма CSMA/CA - Широковещательный запрос к четырем приборам

Одной из дополнительных задач для автоматизации было добавление приборов учета и датчиков в УСПД для периодического опроса. В большинстве систем АСКУЭ это возможно сделать только вручную, занеся в базу данных информацию о приборе, месте его установке, параметрах, и т. д. В нашей системе была добавлена возможность для автоматической регистрации и обнаружения устройств в сети. После включения модем запрашивает у связанного с ним прибора учета его параметры (название, тип, серийный номер) и начинает активное сканирование эфира, отправляя на выбранном канале (или каналах) запросы поиска соседних устройств. После чего происходит попытка подключения к каждой из обнаруженных сетей. При совпадении ключей и прохождении фильтрации по белым/черным спискам устройств на УСПД устройство получает логический адрес в сети и привязывается к УСПД как к координатору. При этом на УСПД появится вся информация о приборе учета и оператору будет нужно только привязать его в ручном режиме к реальному месту установки и потребителю при необходимости.

Информация о приборах учета в УСПД
Информация о приборах учета в УСПД

В гетерогенной сети помимо устройств с PLC/RF модемами могут также присутствовать устройства только с RF интерфейсом и с автономным или низковольтным питанием, как например квартирные радиомодули (счетчики импульсов, подключаемые к счетчикам воды, газа и тепла с импульсным выходом), датчики температуры и влажности, газосигнализаторы и т. д.

Для устройств с автономным питанием основной задачей, помимо собственно учета, является сохранение заряда батарей. Это накладывает ограничения на время работы радиомодуля даже в режиме приема, поэтому большую часть времени радио трансивер устройства находится в спящем режиме и включается только раз в определенный период для опроса показаний. Такой режим работы накладывает дополнительные требования к синхронизации времени между устройствами, так как оно неизбежно будет «уплывать» из-за погрешностей кварцевых резонаторов и сбиваться при замене элементов питания. Для решения данной задачи на канальном уровне был добавлен протокол MTP, являющийся легковесном аналогом общеизвестного алгоритма PTP. Каждое устройство раз в определенный интервал времени делает широковещательные рассылки со своим текущим временем и отдаленностью часов от координатора (stratum). Узлы сети, выбирают устройство с наименьшими удаленностью и разбросом времени и добавляются в дерево после них, становясь следующим слоем источников времени.

Пример построения дерева алгоритмом MTP
Пример построения дерева алгоритмом MTP

В обычном режиме система работает под управлением УСПД, который поочередно по графику опрашивает все датчики и приборы учета, но иногда устройствам необходимо асинхронно передать информацию к координатору, например о превышении допустимых значений, вскрытии корпуса устройства или снижении уровня заряда батарей. Можно было бы использовать выбранный ранее подход с реактивной маршрутизацией, но это добавило бы дополнительную задержку перед отправкой пакета и увеличило накладные расходы на асинхронный поиск маршрута. Но ведь в результате работы MTP у нас же уже фактически есть в каждом устройстве запись о следующем «прыжке» до координатора, которую можно использовать. Таким образом мы приходим к используемому в текущей версии модемов алгоритму ARRDP. При обращении от УСПД к устройствам используется реактивная маршрутизация, которая одновременно находит устройство по его логическому адресу (аналог ARP) и строит маршрут для него с учетом состояния PLC и RF сред. При обратном обращении, от устройств к УСПД, используется пассивная проактивная маршрутизация, использующая данные синхронизации времени для быстрой отправки пакетов, но возможно не по самому оптимальному маршруту. Применение данного подхода позволило решить большую часть проблем с надежностью каналов связи до устройств, удаленных от УСПД. Данное решение хорошо работает при плотном покрытие объекта устройствами учета, как например в жилых домах или бизнес центрах. Таким образом мы не изобрели «серебряную пулю», но создали стабильное решение для применения на большей части объектов требующих автоматизированных систем сбора данных.

Сетевой стек PLC/RF модема
Сетевой стек PLC/RF модема

Поскольку разработка системы и ее развертывание на объектах происходили параллельно, то был реализован механизм обновления модемов устройств без физического доступа к прибору и повреждения пломбировки. Так как модем является отдельным модулем, взаимодействующим с прибором учета, то его ПО не относится к метрологической части и изменение его версии (с изменением контрольной суммы) не требует повторной поверки прибора учета. Обновить ПО можно двумя способами: или используя протокол удаленной настройки и управления самого модема, посредством отправки маршрутизируемых IPv6 пакетов по гетерогенной PLC/RF сети или с использованием протокола управления канального уровня и отправки прошивки по одному из широких радиоканалов, что значительно быстрее, но требует физического нахождения рядом с обновляемым модемом.

Небольшой оффтоп об обновлении

На самом первом объекте мы столкнулись с ситуацией, когда после установки нашей системы учета управляющей компанией поставщиком электроэнергии были установлены вводные приборы учета, также использующие PLC в диапазоне CENELEC A, но с другой модуляцией (S-FSK) и с высокой утилизаций канала (более 50%). На тот момент ПО модемов не поддерживало изменение диапазона работы PLC, поэтому единственным решением было обновление прошивки всех приборов учета на объекте по каналам со скоростью в 1-10 Кб/с. Дополнительной сложностью было то, что при смене частотного диапазона PLC терялась совместимость с предыдущей версией, поэтому обновление было необходимо устанавливать, двигаясь от самых дальних приборов (с точки зрения маршрутов) к ближним. В целом процесс прошел успешно, но для сотни с небольшим приборов занял чуть более месяца.

Со стороны УСПД модем на уровне драйвера интегрирован в ОС Linux. Для обращения к устройствам на используются IPv6 адреса, включающие в себя серийный номер прибора. В УСПД модем представляется как сетевой адаптер, на который можно открыть обычный UDP сокет для обмена данными с устройствами. Для анализа сети можно использовать стандартные утилиты вроде traceroute, tcpdump, а настройки самого модема вынесены в sysfs.

Работа с модемом в системе УСПД
Работа с модемом в системе УСПД

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

Бонус для дочитавших
Щит с УСПД перед отправкой на объект
Щит с УСПД перед отправкой на объект
Тестирование взаимодействия приборов учета
Тестирование взаимодействия приборов учета
Обновление модемов на объекте через радиоканал: иногда ближайшая к обновляемому устройству точка может выглядеть так
Обновление модемов на объекте через радиоканал: иногда ближайшая к обновляемому устройству точка может выглядеть так
Памятник модемам не прошедших испытания
Памятник модемам не прошедших испытания




Комментарии (40):

  1. divanus
    /#23042486

    В 2012 применил на объектах систему Матрица — тогда уже они активно по стране продавались. А вот о вашей продукции только сегодня узнал.

    • Thar0l
      /#23042534

      На тот момент у нас еще не было этой системы, мы тогда только начинали заниматься приборами учета, а о интерфейсах передачи данных задумались где-то к 2014 году.

      • divanus
        /#23042830

        Я же верно понял — основное у вас, это производство микросхем АРМ?

        • Thar0l
          /#23043020

          Основное — направление — да, производство интегральных схем, но не только ARM, же DSP процессоры, упомянутые в статье, различные интерфейсные микросхемы — CAN, RS-232/485, АЦП/ЦАПы, память…
          Из микроконтроллеров помимо ARM ведем разработки в направлении RISC-V, недавно была статья об МК для счетчиков электроэнергии.

          • divanus
            /#23043084

            Планируете ли выходить в массмаркет? У вас же вроде есть аналоги atmega, stm32. Уж очень «китайский» хлам надоел. Может какие проекты есть интересные?

            • analog_design
              /#23043184

              из ходовых микроконтроллеров серийно выпускается К1986ВЕ92QI (один из самых ходовых коммерческих микроконтроллеров у нас). Если нужно помощнее, то скоро планируется выход 1986ВК018, также будет вариант в пластике. Если интересно, можете прочитать презентацию с экспо.

              • Make_Pic
                /#23044322

                Все это хорошо, но уже спрашивал у вас в другой статье на хабр про разработку аналога низкопотребляемой серии STM32L с током потребления хотя бы 40мКА на мегагерц — ответа не получил :( Нет у нас российских микроконтроллеров с низким потреблением, не считая почти аналога утопично старого PIC16C84 и всяких заказных масочных КМОП поделок аля кредитные карты, RFID с узкой специфичной применяемостью и фантасмагорных всяких «Кроликов» от 100 тыс. штук в одни руки, не меньше… :(

                • analog_design
                  /#23044356

                  В паланах отдела микроконтроллеров есть данная работа, однако пока не хватает на это направление ресурсов.

            • Thar0l
              /#23043234

              Del (коллега выше уже частично ответил)
              UPD Верну часть комментария, т.к. ниже уже ответили на него…
              Тут было упоминание, что восьмибитники уже отмирают и atmega интересны лишь за счет ардуино и накопившейся кодовой базы.

              • divanus
                /#23043242

                Встречаю atmega в куче бытовых приборов. Буквально на каждом шагу присутствуют. Стоит только приглядеться, поэтому и интересуюсь.
                А есть какой новый, интересный чип для любителей? :) Именно под массмаркет.

                • Thar0l
                  /#23044202

                  Да, есть такое, но последнее время вижу все больше и больше stm32f103 на их месте. Может быть под массмаркет зайдет что-то из линейки RISC-V, но точно угадать нельзя. В ARM-ах же (Cortex M3/M4) состязаться с тем же ST или его китайскими копиями почти невозможно.

  2. shadrap
    /#23043002

    небольшой офф — я всегда думал, что PLC траффик из моей квартиры отделяется первым попавшимся на пути трансформатором, типа электросчетчика — нет? я «фоню» на весь дом?

    • Thar0l
      /#23043068

      Чем выше частота, тем хуже проходит сигнал через трансформатор. PLC, использующийся для развертывания интернет канала вроде HomePlug работает в диапазоне десятков МГц и очень быстро затухает и поглощается, но не полностью и все равно частично фонит на весь дом :) Мы же используем низкоскоростный протокол с частотами в районе 30-200 кГц, скорости сильно ниже (до десятков Кб/с), но распространение лучше.
      И да, счетчик не содержит разделительного трансформатора, в нем есть шунт и/или трансформатор тока, но они на PLC сигнал влияния не оказывают.

      • shadrap
        /#23043228

        вроде HomePlug работает в диапазоне десятков МГц и очень быстро затухает и поглощается,

        быстро да не очень, у меня на даче расстояние в 80 метров HomePlug преодолевает довольно шустро и стабильно…
        счетчик не содержит разделительного трансформатора, в нем есть шунт и/или трансформатор тока, но они на PLC сигнал влияния не оказывают.

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

        • Thar0l
          /#23043256

          Ну трафик все-таки шифруется у всех нормальных производителей PLC устройств т.к. среда передачи то общая (у нас тоже используется AES-EAX), так что это не совсем дыра. Wi-Fi то тоже всем виден в общем эфире и не экранируется полностью стенами квартиры.

          • shadrap
            /#23043312

            в отличие от wifi у PLC есть «пэйр» и если кто-то с вами вместе из соседней квартиры «за-пэйрится», то он уже в сети…

  3. hooperer
    /#23043400

    давным давно была, да есть сейчас компания -mobixchip.
    они делают(делали( учёт с plc_RF гетерогенно, hibridmesh.
    году примерно в 2014 в системном интеграторе мы через делали пилотный проект в Конаково на 5000 точек с их системой.
    Ну да, компания видимо под сколково сделанная и этим всё сказано, но показания даже(иногда D)) собирались.
    Могу напутать, но у них Максимум по протоколу 16 транзакций в реальности больше 4-х не видел. И смен среды может быть не так много как кажется на первый взгляд. Да, оби ещё обещали всё положить на один кристалл ))) сколково ))) В итоге встраивали в Неву свои модемы.

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

    • Thar0l
      /#23044190

      Мы на всех объектах стараемся добиться собираемости в 95% и выше. Первые тестовые объекты вели более года в плане поддержки именно чтоб выявить сезонные проблемы.

      • hooperer
        /#23044966

        Если судить по тогдашним временам, 2014 года —
        Когда я спрашивал тогдашнего руководителя деп.учета мрск (холдинга) — он/они ставили 95% как планку ниже которой можно не подходить.
        Причем как я помню на «пилотных больших проектах » которые делали по задаче тогдашних Мрск в Перми редко кто в 2013 году дошел до 70% и вообще все попали на штрафы.
        а там были и рим и меркурий и нзиф и остальные. со своими бригадами.

        Скорее всего конечно шагнули вперёд технологии. Опять же кое кого уже тогда Сильно интересовали гармоники вплоть до 21-й. По вполне понятным причинам.
        Но шагнули они — технологии,
        не всегда качественно и (мнение со стороны)… у грандов.

  4. ioccy
    /#23044120

    А 1967ВН044 в серийных устройствах у вас стоит? Она ж стоит как крыло от самолета.

    • Thar0l
      /#23044172

      Да, в серийных стоит и в модемах и в радарах. В первых версиях был голый кристалл разварен под компаунд, а потом выпустили пластиковый корпус. Как крыло от самолета она она стоит в металлокерамике с пятой приемкой.

  5. Petrpureshka
    /#23045508

    В 85% случаях жители либо сами отправляют показания с счетчика в УК или поставщику электричества, либо по подъезду ходит специальная тётя и собирает показания самостоятельно. Считаю что переход к цифровизации и интернета вещей у нас в стране идет достаточно туго и стоило бы как-то более инициативно и смелее подходить к подобным вещам.

  6. man55
    /#23045850

    есть ли в планах реализация G3 Hybrid в соответствии с не так давно принятым в G3 Alliance стандартом, а не проприетарное радио?

    • Thar0l
      /#23046530

      Задумываемся об этом, но стандарт пока не принят, он еще на стадии draft-а, причем не опубликованного…

      • man55
        /#23046910 / +1

        у Вас устаревшая информация, стандарт принят, сертификационные лаборатории готовы (как минимум TUV и LANPARK)
        даже не для членов альянса доступна информация о сертифицированных платформах:
        ST и Microchip

        Для информации: ST де-факто полностью переключились в части разработки гибридного стека со своей проприетарщины, на которой в частности работают счетчики Матрица, на это стандарт, апдейты выходят только на него, чего и Вам желаю.
        Проприетарщина — путь в никуда, использовать проприетарный стек кроме Милура вряд ли кто из производителей будет в здравом уме

        • Thar0l
          /#23048018

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

  7. jaha33
    /#23046316

    Так у вас меш сеть "сама" выстраивается или на каждом объекте надо напильником допиливать маршруты?

    Пробовали собирать данные по СПОДЕС (именно честный сподес, а не костыли, как это делают лартехи и прочие)? Какие размеры сети при этом можно ожидать?

    • Thar0l
      /#23046416

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

      • DmitrySerebro
        /#23047982

        А на каких объектах это реализовано? Какое количество ПУ установлено на каждом объекте и сколько УСПД?
        Можно уточнить — какая структура сети должна быть чтобы производить опрос ПУ на среднем уровне? Какое оборудование используется?

        • Thar0l
          /#23047984

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

          • DmitrySerebro
            /#23051600

            Какое оборудование вы использовали для организации опроса и планируется ли тест на объектах, где на 1 УСПД будет по 150-200 ПУ?
            Если ПУ будет подключен к уже существующей сети на объекте — он сам даст знать, что он появился в сети или его нужно прописывать в УСПД вручную?

            • Thar0l
              /#23051762

              Опрос приборов учета производится УСПД Милан IC 02 (pdf). Опыт опроса объектов с 100-200 ПУ на один УСПД конечно есть, но там была еще предыдущая версия ПО, не поддерживающая саморганизующуюся сеть. Есть объект со 120 приборами учета на 1 УСПД в подвале. В УСПД устанавливается PLC/RF модем с шестью PLC каналами для обслуживания сразу двух трехфазных вводов. С точки зрения именно УСПД нет проблем опрашивать и несколько тысяч приборов, лишь бы хватало скорости и надежности канала, чтоб вытаскивать показания со всех за сутки.
              УСПД опрашивает ПУ по Modbus или DLMS (СПОДЭС) и отдает данные по DLMS или JSON.
              При этом УСПД — это не «шлюз», а самостоятельное устройство, хранящее показания подключенных к нему и опрошенных ПУ.
              При включении (перезагрузке) прибор заново регистрируется в сети и далее все зависит от настроек УСПД. Можно настроить автоматический опрос всех добавленных приборов (с учетом их типа, который вынимается при регистрации или первом опросе), можно использовать белые или черные списки, чтоб могли зарегистрироваться в сети только приборы уже, добавленные вручную в УСПД и т.д.

              • DmitrySerebro
                /#23051824

                УСПД Милан IC 02 не добавлен в перечень оборудования, материалов и систем, допущенных к применению на объектах ПАО «Россети». Планируется ли его аттестация и в какие сроки?

                • Thar0l
                  /#23054136

                  Да, планируется, прямо в данные момент идет доработка УСПД под требования ПАО Россети (в очередной раз изменившиеся). Сразу после этого будет приступать к аттестации, надеемся закончить в этом году.

      • hobogene
        /#23051084

        AlexFTF Видите, IRL возня с изводами DLMS всегда выливается в возню с HDLC. Это к нашему старому спору…

        • AlexFTF
          /#23052516

          Нет не вижу. HDLC это один из протоколов, с помощью которого передаются кадры DLMS, и применяется он, как правило, для передачи данных по интерфейсу RS-485. В СПОДЭС он используется на интерфейсе RS-485.


          Для LPWAN и PLC есть другие коммуникационные профили, где HDLC не используется, некоторые из них указаны в последней редакции СПОДЭС.

  8. Thar0l
    /#23047978

    DEL Промахнулся веткой.

  9. hobogene
    /#23051068

    трансиверы LoRa были настроены на режим SF7/125кГц


    Наверное, стоило ADR включить. В помещении так точно.

    LoRa, несмотря на более надежную CSS модуляцию и большую ширину канала, фактически сталкивается с теми же проблемами переотражения и затенения


    Некоторые считают, что в переотражении ее сила :-) А вообще с ней больше на SNR имеет смысл смотреть. С SF12 все было бы получше с demodulation margin. Но это, естественно, не значит, что LoRa — панацея, или радикально лучше вашего решения, или что-нибудь еще в этом духе.

    • Thar0l
      /#23051782

      Может конечно в этом и сила, но переотражение всегда приводит к интерференциии и неравномерному покрытию. И если для датчиков например еще можно подвигать приборы в некотором радиусе вокруг точки установки, то для приборов учета с этим сложнее, т.к. места в щитках и лючках обычно не предполагают смещение от стандартной точки установки.
      SNR для разных типов модуляции сравнивать еще менее корректно, чем RSSI, т.к. он может считаться абсолютно по разному в двух разных аппаратных трансиверах (TI CC1200 и Semtech 1276 (вроде, уже точно не помню)).
      Сравнивали именно чтоб проверить, правда ли LoRa — такое волшебное решение, как рекламируется… Но физику так просто не обманешь и общие проблемы с радиоканалом у них присутствуют те же, что и у нас и у всех остальных. Не помню точно почему, но с SF12 не получилось тогда настроить связку шлюз+датчик на совместную работу.

      • hobogene
        /#23052292

        Без (пере)отражения были бы большие проблемы со связью «из-за угла».

        Я и не предлагал сравнивать SNR, я предлагал сравнить «запас по прочности». Link budget-то разный у разных модуляций. Но для LoRa, кстати, еще имеет смысл брать не RSSI, а effective RSSI. Т.е. при отрицательном SNR прибавлять его к RSSI. И вот в вашей табличке для некоторых точек цифры для LoRa будут хуже, чем кажется на первый взгляд.

        с SF12 не получилось тогда настроить связку шлюз+датчик на совместную работу.


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