Особенности построения сетей IoT на базе протокола LoRaWAN

Введение

Для построения различных информационных систем мониторинга и контроля, объединяющих большое число датчиков, сенсоров и прочих «умных» устройств, в последние годы всё чаще используют вместо привычных и давно освоенных технологий широкополосной передачи данных - таких как Wi-Fi и GPRS/UMTS/LTE - специализированные технологии и протоколы, обеспечивающие выделение телеметрических данных из общего информационного потока. Это позволило не только разгрузить традиционные сети связи общего доступа, но и организовать для передачи телеметрических данных более приспособленную среду. Такое сочетание специализированных протоколов и специализированного оборудования получило название «Интернет Вещей».

Нужно заметить, что под «вещами» в данном случае подразумеваются разного рода электронные устройства, предназначенные для сбора в автоматическом режиме, т.е. без участия человека, различных данных, возможно, предварительной их обработки и дальнейшей передачи результата на некий сервер, где уже будет выполняться финальная обработка всех этих данных перед тем, как результат будет представлен человеку. Устройствам такого рода не нужны ни высокая скорость передачи большого объёма данных, ни постоянное подключение к серверу, ни одинаковые полосы для скачивания и выгрузки, так как чаще всего обмен идёт только в одну сторону: от устройства к серверу. При этом одним из главных требований к таким устройствам является максимальное время автономной работы – до одного года, а лучше, несколько лет от одного элемента питания. Этим основным требованием обусловлено несколько дополнительных: 

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

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

Обсуждаемый протокол LoRaWAN как раз и разрабатывался с учётом всех требований Интернета Вещей, которые перечислены выше, и является одним из нелицензируемых, т.е. бесплатных в использовании, протоколов. По различным оценкам, в некоторых регионах мира до половины всех текущих устройств из Интернета Вещей созданы именно на базе этого стандарта. Для работы с этим протоколом выпускается очень широкая номенклатура различных ЧИПов, а также доступно бесплатное ПО, обеспечивающее поддержку протокола в мобильных устройствах. 

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

Приказом от 22 декабря 2023 г. Росстандарт утвердил ГОСТ Р 71168-2023 «Информационные технологии. Интернет вещей. Спецификация LoRaWAN RU». Стандарт начнёт действовать с 1 июля 2024 года. Что это означает? Принятие этого ГОСТ фактически легализует применение устройств, созданных на базе LoRaWAN на территории России – разумеется, при условии соблюдения производителем локальных российских требований. Иными словами, теперь информационные системы на базе протокола LoRaWAN могут использоваться не только в отдельных коммерческих проектах, но при условии соответствия региональным требованиям протокола LoRaWAN RU могут применяться и в более ответственных проектах, вплоть до государственных.

Но даже для неискушённого в радиотехнике специалиста после ознакомления с вышеизложенными цифрами становится очевидным, что различия между обычным, если так можно выразиться, «Интернетом общего пользования» и Интернетом Вещей – разительны. И возникает вопрос: можно ли вообще в Интернете Вещей использовать что-то более сложное, чем датчики и сенсоры? Можно ли в принципе адаптировать для работы в среде Интернета Вещей те, условно говоря, «большие» умных устройств, которые свободно работают через Wi-Fi или Bluetooth, передавая при этом большой объём телеметрических и прочих данных? Говоря в общем, можно ли в принципе реализовать на базе Интернета Вещей некую информационно-насыщенную систему, обеспечивающую более высокую информативность, чем примитивные «температура-влажность-освещенность»?
В данной статье мы расскажем, как решали подобные вопросы при реализации одной из разработок нашей компании – системы мониторинга персонала на базе средства индивидуальной защиты (СИЗ) типа «строительная каска» под рабочим наименованием «К-СБиК» (Компонента – Система Безопасности и Контроля).

Краткое описание К-СБиКК-СБиК представляет собой программно-аппаратный комплекс, развёртываемый на территории предприятия Заказчика с повышенной опасностью, где действуют требования по обязательному использованию СИЗ, в частности, защитных касок (рис. 1).

Комплекс состоит из:

• интегрированных в строительную каску модулей kPoint, обеспечивающих сбор и предварительную обработку телеметрических данных с различных сенсоров с последующей передачей результатов по радиоканалу Интернета вещей по протоколу LoRaWAN;
• роутеров kHub, представляющих собой базовые станции стандарта LoRaWAN, обеспечивающие обмен информацией между модулями kPoint и сервером приложения kFace, а также сбор и передачу на сервер информацию о текущем атмосферном состоянии;
• автоматизированной Системы Управления Персоналом (АСУП) – программно-аппаратного комплекса, обеспечивающего как управление модулями kPoint, так и финальную обработку получаемых от них данных для выдачи её оператору АСУП через интерфейс программы kFace в удобном и лёгком для восприятия виде.

Модуль kPoint позволяет собирать следующие типы информации:

1. данные акселерометра/магнитометра, позволяющие получать информацию об уровне активности работника;
2. данные с модуля GPS/GLONASS – геоданные и точное время;
3. температура внутри модуля kPoint;
4. информацию с датчика приближения - надета ли каска на голову;
5. состояние и текущий режим работы аккумулятора.

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

Оптимизация К-СБиК под LoRaWAN

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

Использование поля «Port»

В каждом сообщении протокола LoRaWAN всегда присутствует поле «Port». Это поле может иметь значение от 0 до 255. Исключая т.н. служебные порты, свободными для программирования сообщений остаются более 230 разных значений. Они нужны для того, чтобы можно было сообщения разного формата и с разным содержимым направлять на различные порты. Это чрезвычайно упрощает декодирование для систем со сложной информационной структурой, такой как у К-СБиК, например. Благодаря разбиению на порты не нужно закладывать в само сообщение какую-то дополнительную информацию о том, какие данные заложены в данное конкретное сообщение и как его нужно декодировать.

Адаптивная скорость передачи – ADR

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

Снижение числа сообщений, требующих подтверждения

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

Дополнительная оптимизация

Перечисленные меры, конечно, способствуют разгрузке эфира от лишних сообщений, но их явно недостаточно. Чтобы реально и значительно сократить время вещания каждого из модулей kPoint внутри системы К-СБиК, потребовалось значительно модернизировать внутреннюю логику работы модуля, добавив в неё большой объём предварительной обработки информации и заложив в систему гораздо бо́льший, если так можно выразиться, «интеллектуальный» потенциал.
Первый шаг в оптимизации работы К-СБиК под стандарт LoRaWAN заключался в разделении всех сообщений на два типа:

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

Также в системе «К-СБиК» существуют служебные сообщения, которыми модуль kPoint обменивается с сервером в самом начале работы, но в рамках данной статьи их можно не рассматривать.

Если с аварийными сообщениями всё очевидно: произошло некое важное событие – направляем уведомление о нём, то с периодическими сообщениями как раз начинается основная работа по оптимизации.

Так как каждая каска выдаётся конкретному работнику, то мы заранее знаем должность этого работника, поэтому можем предположить и характер его деятельности. На текущем этапе в системе К-СБиК используются следующие профили для работников:

• «Рабочий» – подразумевает высокий уровень активности и более строгий контроль за перемещениями по рабочей площадке;
• «Оператор» механизма или транспортного средства – средний уровень активности, вполне может находится на одном и том же месте весь рабочий день;
• «Руководитель».

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

Схожая ситуация с профилем «Оператор». Такой работник, как правило, находится на своём рабочем месте весь рабочий день, поэтому для него тоже нет необходимости постоянно обновлять геоданные и следить за его уровнем активности. А вот покидать пределы рабочей зоны он не должен. Поэтому для такого работника тоже можно резко сократить число передаваемых сообщений и увеличить интервал между их отсылкой.

Самая сложная ситуация с профилем «Рабочий». Здесь надо корректно отслеживать и его перемещение по рабочей зоне, и анализировать уровень активности. Причём делать это надо регулярно. Например, если рабочий пропадает большую половину дня в «курилке» с крайне низким уровнем активности, то об этом стоит уведомить его начальника. Как и о факте, что такой рабочий вообще покинул рабочую зону. Но даже и в этом случае есть возможность оптимизировать передаваемые сообщения: если работник нормально активно трудится в одном и том же месте, нет необходимости постоянно передавать одни и те же геоданные; достаточно подтверждать актуальность ранее переданных.

Периодичность принимаемых сообщений от каждого из работников отслеживается АСУП и сверяется с заданным профилем работника. Если пропущено несколько (2 или 3) сеансов связи, то оператор АСУП получает уведомление о том, что модуль kPoint в каске такого-то работника скорее всего неисправен, т.к. с ним давно не было связи, и эту каску предлагается заменить.

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

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

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

Обработка данных акселерометра

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

Поэтому эти данные проходят два этапа статистической обработки: на первом этапе встроенная в модуль нейросеть принимает решение о характере текущей активности работника за ближайшее прошедшее время – до минуты, а затем, уже на основании накопленных данных от нейросети, вычисляется индекс средней активности работника за время, прошедшее с момента последней передачи данных (рис. 2).

Локальная нейросеть представляет собой специфический набор фильтров, обеспечивающий статистическую обработку переданных на его вход данных с выдачей решения в заданном формате. Такой нейросети не нужно какое-либо подключение к публичной сети Интернет, она работает совершенно автономно в составе внутреннего программного обеспечения модуля kPoint. Предварительная настройка фильтров выполняется на стадии проектирования путём обучения, т.е. при помощи предварительно отобранных и классифицированных данных. В дальнейшем, в процессе работы никакое дополнительное обучение данной нейросети не выполняется.
Как уже было упомянуто чуть раньше, на стороне АСУП каждому из профилей работников соответствует некий средний индекс активности. Если у кого-то из работников индекс активности слишком сильно отличается от заданного в профиле, то оператору АСУП выводится соответствующее предупреждение.

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

Обработка геоданных 

Работа с данными со спутников GPS/GLONASS на небольших мобильных устройствах всегда сопряжена с целым рядом трудностей:

1. Сам по себе модуль GPS/GLONASS во время работы потребляет ощутимый объём электроэнергии от батареи. По этой причине держать его постоянно в активном состоянии на устройстве с автономным питанием нецелесообразно и большинство современных модулей GPS/GLONASS поддерживают режим работы «по расписанию», когда через заданные интервалы времени модуль сам активируется, обновляет текущие координаты, после чего снова уходит в режим ожидания. Такой режим достаточно экономичен, но требует отслеживания времени, когда были получены последние координаты.
2. Текущие координаты – это числа, состоящие из большого количества цифр. Чтобы полностью передать всю информацию о текущих координатах, требуется не менее 8 байт. Для сообщений LoRaWAN, где буквально «на счету каждый байт», это много. Передавать такое число байт при каждом обновлении данных как минимум не рационально.

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

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

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

Но самым эффективным решением этого вопроса является передача не самих координат, а информации об их актуальности. Имеется ввиду, что модуль kPoint в первых сеансах связи передаёт данные о текущих координатах целиком, а затем может только подтверждать их актуальность. С учётом того, что погрешность определения местоположения у гражданских модулей может доходить до 10 метров, а, например, Оператор может целый день находиться на одном месте, то смысла передавать каждый раз даже нулевую разницу в координатах нет; гораздо проще передать один байт, имеющий значение «данные актуальны/данные не актуальны».

Выход за пределы рабочей зоны

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

Для отслеживания случаев самовольного покидания работником заданной рабочей зоны, в К-СБиК предусмотрен алгоритм отслеживания выхода работника за её пределы с соответствующим уведомлением оператора АСУП о факте такого нарушения. Реализован этот алгоритм на базе внутренних возможностей использованного в kPoint модуля GPS/GLONASS: он имеет возможность сравнивать полученные текущие координаты с заранее заданными границами; если текущие координаты находятся вне заданных границ, модуль формирует соответствующее сообщение, которое пересылается на сервер АСУП в формате аварийного (срочного) сообщения.
Самым сложным в этой задаче является передача нескольких координат, обозначающих периметр рабочей зоны, от сервера АСУП на устройство kPoint для соответствующей настройки модуля GPS/GLONASS. Модуль может одновременно анализировать до 8 отдельных таких зон, перекрывающих друг друга или нет. Таким образом это может быть объём информации вплоть до 256 байт – 8 байт на каждую точку × 4 точки у одной зоны × 8 зон. Для сети LoRaWAN это очень большой объём. Причём крайне важно удостоверится, что все эти данные были полностью приняты kPoint – об этом может свидетельствовать возвращаемая на АСУП контрольная хэш-сумма полученных координат.

Первоначально координаты передаются в kPoint сразу после её инициализации и подготовке к работе. Сохраняются эти координаты в энергонезависимой памяти центрального процессора kPoint. Всё остальное время между модулем kPoint и сервером АСУП сверяется только хэш.

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

Синхронизация времени

Одной из важнейших задач kPoint является фиксация точного времени произошедшего события. Так как передача сообщений через сеть LoRaWAN осуществляется не мгновенно, а занимает несколько секунд, а в случаях, если передача сообщения с подтверждением с первого раза не удалась, и попытки передачи будут повторяться снова и снова – время, прошедшее между самим событием и получением сообщения об этом будет значительно больше. В связи с этим возникает необходимость к каждому сообщению, содержащему важную информацию о некоем важном событии, прикладывать т.н. «штамп времени» – TimeStamp. Особенно важной фиксация времени будет для событий из разряда чрезвычайного происшествия: «удар», «падение», «снятие каски» и т.п.

Возникает вопрос: а как синхронизировать точное время между сервером АСУП и модулем kPoint? В микроконтроллере, использованном в качестве Центрального Процессора, присутствует блок «Часы реального времени» – RTC, позволяющий сохранять и отсчитывать точное время, но как внести в него значение времени в самом начале работы?

В стандарте LoRaWAN RU, как и в исходном международном стандарте, присутствуют специальные команды для синхронизации времени, но предлагаемый алгоритм синхронизации времени является недостаточно гибким: нужно либо синхронизировать время специальной командой от сервера, причём, устройство само должно изначально запросить эту команду, либо устройство должно использовать время от модуля GPS/GLONASS, но в этом случае оно не должно запрашивать время от сервера приложений.

В К-СБиК использован более гибкий алгоритм синхронизации времени. Для управления процессом синхронизации используется специальный индикатор: «Статус синхронизации времени».

При начальном запуске модуля kPoint в работу этот статус имеет значение «Время не установлено» – этот статус наряду с другой служебной информацией о состоянии kPoint передаётся на сервер АСУП в начале работы. 
Как только сервер АСУП получает такой статус от устройства, он в ответ направляет сообщение, содержащее время, установленное на сервере. После получения такого сообщения и установки RTC в соответствии с полученными данными, kPoint устанавливает статус синхронизации времени «Время не достоверно», то есть некое время от сервера получено, но из-за задержек в сети LoRaWAN, оно имеет большую погрешность установки и требует дальнейшей синхронизации с более точным источником.

Более точным источником «на борту» kPoint является модуль GPS/GLONASS, но придётся ожидать момента первого получения текущих координат. Только тогда, когда текущие координаты будут получены со спутников, этот модуль сможет выдать в RTC реальное точное время. После получения данных о текущем времени от модуля GPS/GLONASS, статус синхронизации времени устанавливается в состояние «Синхронизировано».
В дальнейшем, не менее одного раза в сутки kPoint снова выполняет синхронизацию времени по данным от модуля GPS/GLONASS. Значение статуса синхронизации времени при этом не меняется.

Также на сервере АСУП предусмотрен механизм для случая, если сам сервер обнаруживает, что получаемые таймстампы от модуля kPoint слишком отличаются от текущего серверного времени – на час и более. Такая ситуация может возникнуть в случае перезаписи информации в RTC некорректными данными. В этом случае сервер также направляет устройству сообщение, содержащее текущее серверное время, после чего само устройство уже должно выполнить синхронизацию времени по данным GPS/GLONASS заново.

Заключение

Подводя итог всему вышесказанному, можно с уверенностью утверждать, что хотя сам по себе Интернет Вещей и предназначен для обмена очень короткими сообщениями с малой скоростью, это ещё не означает, что на подобных протоколах нельзя строить информационно-насыщенные системы с широким спектром возможностей. Об этом свидетельствует решение “К-СБиК” нашей компании, по которому уже успешно завершены стадии макетирования и прототипирования, собран и запущен демонстрационный стенд, на котором проводятся отладочные испытания прототипов модулей касок и всей системы в целом. Этап проверки принципиальной реализуемости и доступных функциональных возможностей давно и успешно завершён, и теперь ведутся работы по подготовке решения к выходу на рынок.

При этом нельзя утверждать, что проект «К-СБиК» уникален и не имеет конкурентов. Подобные решение класса «Умная каска» на рынке уже представлены, но мы абсолютно уверены, что наш проект значительно превосходит их прежде всего в плане заложенных в него информационных возможностей: помимо передачи ситуативных данных с уровнем активности и авариных состояний, передаются и обрабатываются данные геолокации с привязкой к рабочей зоне и уведомлениями о выходе за её пределы. При этом вся беспроводная сетевая инфраструктура строится исключительно в рамках отечественного стандарта LoRaWAN RU.

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

А если говорить в общем, то модульность, заложенная в проект «К-СБиК» является продолжением общей концепции системы kSense – масштабируемой и адаптируемой под каждую конкретную задачу, работа над которой идет в компании уже много лет. Гибкость kSense, вкупе с возможностями Интернета Вещей, позволяет реализовывать самые разнообразные информационные проекты в тех, ранее не охваченных автоматизацией, областях, в которых еще недавно автоматизация и телеметрия были просто немыслимы: животноводство, аграрный сектор, транспортно-логистический и т.п.

Проект “К-СБиК” убедительно доказывает, что популярный протокол LoRaWAN, имеющий теперь статус российского отраслевого стандарта, вполне пригоден для построения самых разнообразных информационных систем.