Здравствуйте, уважаемые любители Интернета Вещей. Продолжаю свой цикл статей.
Первая часть → Вторая часть → Третья часть → Четвертая часть → Пятая часть
Итак, мы научились работать с импульсным выходом счетчиков и освоили шифрование. Какой шаг следующий? Ответ очевиден. RS-485.
Чуть-чуть теории. RS-485 (Recommended Standard) – это асинхронный интерфейс физического уровня. Получил огромную популярность в Промышленном Интернете, начиная от ЖКХ и заканчивая различными заводами и предприятиями.
В принципе, почти любой счетчик, который хочет передать нам не один, а несколько параметров, скорее всего, будет снабжен RS-485. Реже RS-232 или M-Bus, но их пока оставим в стороне и разберем самый показательный пример. Точнее проблемы в работе с ним.
Проблема скорости
RS-485 – проводной стандарт. LoRa – беспроводная. Логично, что должно быть некое устройство, способное их подружить.
Все верно. Почти у каждого производителя оконечки в линейке есть радиомодуль с поддержкой RS-485. Работает по принципу прозрачного канала. Все пакеты, которые ходят по проводу, упаковываются в качестве полезной нагрузки пакетов LoRaWAN и уходят на передачу. Либо принимаются и преобразовываются в электрические импульсы.
И тут первая проблема. RS-485 – весьма скоростной интерфейс. Пакеты по нему ходят со скоростями в несколько килобит/сек или даже несколько десятков. К примеру, одна из типовых скоростей Modbus – 9,6 кбит/сек.
LoRa, даже при лучшем SF=7 (125 кГц, 4/5) выжмет 5,5 кбит/сек. С более высокими SF будет еще меньше.
Это значит, что опрос значений какого-нибудь электросчетчика займет не секунды, и даже не десятки секунд. Счет пойдет на минуты. И это еще при правильно отрегулированном времени ожидания. Если оставить настройки по умолчанию, то ваш опрос, скорее всего, окончится ошибкой таймаута. Я уж молчу про ограничения в длине пакетов LoRaWAN. Там просто беда.
Проблема опроса
С импульсными выходами все просто. Мы считаем импульсы, умножаем их на цену деления и получаем показания счетчика. С этим справится любой простенький интерфейс. И такой интерфейс, помимо простоты, будет еще универсальным.
С RS-485 все куда хуже. Удивительно, но многие не понимают одной важной вещи.
RS-485 – это НЕ ПРОТОКОЛ ОБМЕНА! Он не оговаривает формат пакетов, которые ходят внутри него. По сути – это просто среда передачи. Оговорены лишь электрические и временные характеристики интерфейса. Все! Все, что сверху уже надо разбирать отдельно.
А разбирать есть что! Поверх нашей среды каждый производитель может накрутить, что душе угодно. Ну, или что оказалось удобно лично ему. К примеру, теплосчетчик ВКТ-7 будет общаться с нами через ModBus. А Энергомера – через ГОСТ Р МЭК 61107-2001.
Это все протоколы, которые накладываются на среду передачи сверху и имеют более высокий уровень. Каждый протокол имеет свой состав кадра, требует своих команд на выполнение тех или иных действий, предусматривает различное хранение (а значит и опрос) значений. Следовательно, для каждого устройства необходим свой скрипт опроса. Более того, даже в рамках одного протокола (тот же ModBus) этот скрипт будет отличаться от устройства к устройству.
Сами по себе протоколы не являются тайной и, по большей части, открыты. Более того, сайт каждого производителя зачастую содержит бесплатную утилиту, с помощью которой можно приборы опрашивать. Но эти утилиты не универсальны и заточены под одного производителя. А мы помним, что у нас почти всегда зоопарк устройств. И ставить клиенту на компьютер несколько программ одновременно… ну это не слишком удобно.
Выхода два. Либо писать что-то свое. Либо взять программу, в которой уже скомпилированы скрипты опроса самых популярных устройств. На рынке немало готовых решений, скажем «ЛЭРС-учет» или «ЯЭнергетик». Но они платные и стоят хороших денег. Как и разработка своего софта.
Кроме того, если мы говорим про Промышленный Интернет (то есть выходим за рамки ЖКХ) готовые универсальные решения вам уже не помогут. Как быть?
Никак.
Если вы все еще планируете опрашивать через LoRa по прозрачному каналу, вы все равно упретесь в ограничения скорости и таймауты. Может не сразу и не с первым устройством, но это произойдет.
Проблема стандарта
Помимо всех бед, у нас есть еще одна. Т.к. RS-485 подразумевает, что мы можем обратиться к устройству в любой момент, радиомодуль LoRa с его поддержкой должен быть класса С. То есть всегда слушать эфир и быть готовым ответить.
Напомню, что класс С не подразумевает батарейного питания, но тут беда не столь серьезная. Обычно, RS-485 находится там, где внешнее питание можно раздобыть.
Хуже другое.
По закону, мы можем работать в двух частотных диапазонах. Помните, ограничение в 864-865 МГц? Не более 0,1 % времени в эфире? Это значит, что каждое отдельно взятое устройство может находиться в эфире, допустим, не дольше 3,6 секунд в час. Но за это время, на SF=12 мы даже три пакета не пропихнем.
Можно попробовать выжать максимум из каналов 868,7-869,2. Однако тут вступает в силу уже другое ограничение региональных стандартов спецификации LoRaWAN – не более 1 процента времени в эфире для каждого оконечного устройства (duty cycle). ОК, уже полегче, 36 секунд. Только толку все равно не особо.
В какой-то момент, мы можем сказать – да ну их, эти глупости! Буду сидеть в эфире столько, сколько нужно! Но тут появляется:
Проблема емкости эфира
LoRa не зря обменивается короткими и редкими пакетами. По сути, вокруг этого построен весь стандарт. Нужно, чтобы каждое устройство занимало максимально мало времени в эфире. Тогда мы снизим риск коллизий и сможем достичь той самой фантастической плотности в несколько тысяч радимодулей на одну БС. Что же будет, если один радиомодуль строчит пакетами как из пулемета? Его частота занята в момент передачи. А в момент ответа заняты вообще все частоты, т.к. базовая станция ничего не слышит, когда передает сама.
Разумеется, никто не отменял заделы на увеличение емкости. Т.е. если в зоне действия одного радиомодуля будет две БС, отвечать будет все равно одна, а вторая может услышать какой-то другой пакет. Однако, эфир не резиновый. Если каждый радиомодуль будет занимать минуту на обмен пакетами, то в час на одну БС мы сможем повесить не более 60 оконечных устройств, это еще при условии отсутствия коллизий. Очень мало, особенно если вспомнить, что радиус действия каждой БС в городе – порядка 2 км, а может и больше.
Значит, нет?
Получается, что наша сеть LoRaWAN ограничена только устройствами с импульсным выходом и сторожевыми системами, где регистрируется факт сработки?
Нет.
Просто мы попытались использовать концепцию Интернета Людей там, где этого делать нельзя. Согласитесь, нам привычно избыточно использовать стабильный Интернет-канал. Например, открыть видео, прихватив запас в буфере, и не досмотреть. Т.е. трафик пройдет, но по факту не будет использован.
Однако, здесь все иначе. Скорости у нас мало, времени в эфире тоже. Надо использовать его экономно. Что можно придумать?
Ответ на поверхности. Не гонять через LoRa кучу служебного трафика протоколов поверх RS-485.
Скрипт опроса можно загрузить в сам радиомодуль. Он будет на месте опрашивать счетчик с определенной частотой и высылать нам только сухие, заранее оговоренные значения.
У этого метода два минуса:
- Такой радиомодуль требует определенных вычислительных ресурсов. Это не большая проблема на текущем уровне развития технологий.
- Такой радиомодуль потребляет больше энергии. Но в случае прозрачного канала мы вынуждены использовать класс С, который так же не от батарей живет. То на то и выходит.
Зато мы получаем всю необходимую нам информацию в 2-3 пакетах. А то и в один все поместится, если нужно буквально несколько параметров. Ведь часто бывает, что нам не нужно передавать ВСЁ, достаточно ограниченного набора значений.
Радимодуль может передавать данные, допустим, раз в час. А на стороне сервера мы будем складывать их в хранилище. Если потребуется обратиться к архиву, то серверу даже не придется опрашивать устройство.
Разумеется, что нужно иметь некий универсальный радиомодуль, в который загружаются различные скрипты. И интерфейс, способный такую информацию воспринимать. Это не простой путь, но только он отвечает всем требованиям и ограничениям.
В данный момент, к этому решению приходят все больше производителей. Готовятся подобные устройства у Веги, уже есть у icbcom, ОРИОН М2М и других.
Т.к. мы используем самописный интерфейс, то подобные разработки есть и у нас. В какой-то момент стало ясно, что если не полезем глубже, просто не сможем работать.
Помимо хитрости с экономией трафика, нам по-прежнему требуется хорошая сеть, в которой устройства работают на минимальном SF и максимальной скорости. Я подчеркну – не такая сеть, в которой все устройства с SF=7. Вы этого все равно не добьетесь.
Такая сеть, которая стремится к SF=7. Это значит грамотное планирование и ADR.
На выходе получим достаточные скорости для хождения пакетов, по-прежнему большое число радиомодулей на одну БС и возможность работать с интерфейсами уровня выше импульсного выхода. Что и требовалось.
P.S. Коллеги, я благодарен всем за обратную связь. Скажите, что вам еще интересно узнать про LoRaWAN или Интернет Вещей? Ответы можете писать мне в личку или в комментариях. По самым интересным или массовым запросам будут выходить статьи.
