Сети интернет вещей: архитектурные особенности и требования к городской инфраструктуре
Фонарь, который включается при приближении человека, выглядит простой городской услугой. За ней, однако, стоит целая система: датчик обнаруживает движение, передаёт сообщение по радиоканалу, платформа обрабатывает его, а контроллер меняет режим освещения.
Для такого сценария важна не абстрактная скорость всей сети, а то, чтобы каждый участок работал в пределах, подходящих конкретной задаче. Датчик уровня воды может передавать показания с интервалом, тогда как управление освещением требует более оперативной реакции. Сети LPWAN при этом не обещают доставку за миллисекунды: задержка зависит от технологии, настроек, качества связи и маршрута данных.
Сети интернет вещей в городе состоят из конкретных устройств и служб: датчиков в ливнёвках, счётчиков потребления, радиошлюзов, каналов связи и платформ, которые превращают телеметрию в решения. Архитектура определяет, насколько надёжно показания попадут к диспетчеру, кто заметит потерю связи и можно ли заменить оборудование одного поставщика без перестройки всей системы. Городской сервис начинается не с красивой карты датчиков, а с этих инженерных связей.
Многоуровневая архитектура: что стоит между датчиком и решением
У городской IoT-системы нет единственной обязательной схемы. Часть устройств связывается со шлюзом, часть напрямую с сетью мобильного оператора, а некоторые решения обрабатывают данные локально. Но основные функции обычно распределены между несколькими уровнями. Это разделение помогает понять, где именно возникла проблема: в датчике, радиоканале, передаче данных или программной платформе.
Устройства и исполнительные механизмы
На нижнем уровне находятся датчики и устройства, которые выполняют команды. Датчик может измерять вибрацию конструкции моста, уровень воды в колодце или расход ресурса. Контроллер освещения принимает решение о включении светильника, а исполнительный механизм меняет его режим.
Именно здесь задаются частота измерений, точность и требования к питанию. У датчика, который фиксирует редкие изменения уровня воды, один профиль работы; у устройства, передающего тревожное сообщение, другой. Чем чаще радиомодуль просыпается и передаёт данные, тем выше расход энергии. Поэтому периодичность связи нельзя выбирать только по удобству последующей аналитики: её сопоставляют с тем, как быстро система должна заметить изменение.
Многие датчики питаются от батареи, особенно если размещены в подвалах, колодцах или на конструкциях, к которым трудно подвести кабель. Но автономное питание не всегда оказывается лучшим решением. Там, где есть постоянное электроснабжение, подключение к сети может упростить обслуживание и позволить чаще передавать данные. Выбор зависит от места установки и режима работы устройства.
Радиосеть, шлюзы и каналы связи
В LoRaWAN оконечные устройства передают сообщения радиошлюзам. Шлюз принимает пакеты и передаёт их дальше по каналу связи, например через проводную сеть или мобильное подключение. Между датчиком и приложением нет одного универсального маршрута: в других архитектурах устройство может связываться с сетью оператора напрямую, как это предусмотрено для NB-IoT.
Шлюз не следует путать с узлом, который по своему усмотрению перенаправляет любой радиотрафик. В LoRaWAN один пакет может быть принят несколькими шлюзами, если устройство находится в зоне их радиопокрытия. Сетевой сервер затем обрабатывает полученные копии. Если один шлюз перестал работать, система продолжит получать данные через другой лишь в том случае, если тот тоже слышит устройство и подключён к сети. Агрегатор не может восстановить радиопакет, который не принял ни один шлюз.
Отсюда следует практическое требование к размещению оборудования. Важны не только число и высота шлюзов, но и проверка связи в конкретных точках: за стенами, в подвалах, внутри колодцев, за плотной застройкой. Радиус, указанный для открытого пространства, сам по себе не описывает городское покрытие. Бетон, металл, рельеф и взаимное расположение зданий меняют условия распространения сигнала.
Сетевая и вычислительная части
После радиосети данные проходят через транспортную инфраструктуру к сетевым серверам и платформам обработки. Здесь могут удаляться дубли, проверяться форматы, сопоставляться показания разных датчиков. Важно отделять техническую доставку сообщения от его смысла: платформа может получить значение, но ещё должна определить, нормально ли оно для конкретного объекта и не противоречит ли соседним измерениям.
Часть обработки размещают в облачной платформе, часть — ближе к источнику данных, на периферийном сервере. Локальная обработка полезна, когда системе нужно быстро отреагировать или продолжить работу при временной потере связи с внешней платформой. Например, контроллер может выполнять заранее заданный сценарий независимо от того, доступна ли центральная аналитика. Для отчётности и сравнения показаний по всему району, напротив, может понадобиться централизованное хранилище.
Сбой одного шлюза и сбой платформы — разные ситуации. Резервирование может предусматривать дополнительные радиошлюзы, альтернативный канал их подключения, резервирование серверов и буферизацию сообщений на устройствах или промежуточных узлах. Каждый механизм закрывает свой риск. Наличие двух серверов не компенсирует отсутствие радиопокрытия, а несколько шлюзов не помогут, если все они подключены к одной отказавшей линии связи.
Прикладной уровень и протоколы обмена
На прикладном уровне работают сервисы для диспетчеров, инженеров и городских служб: панели мониторинга, уведомления, отчёты и интерфейсы управления. Здесь решается, кто увидит тревогу, как она будет связана с объектом и что произойдёт, если сообщение не обработано вовремя. Даже исправная сеть мало полезна, если данные не попадают в рабочий процесс службы эксплуатации.
Протоколы MQTT и CoAP относятся к прикладному уровню. MQTT использует модель публикации и подписки: устройство или сервис публикует сообщение, а заинтересованные системы получают его через брокер. CoAP рассчитан на взаимодействие с ограниченными по ресурсам устройствами и напоминает модель запрос-ответ. UDP и TCP, в свою очередь, относятся к транспортному уровню и отвечают за передачу данных между узлами. Какой набор применяется, зависит от сети, оборудования и требований к доставке.
Нельзя свести выбор к правилу, будто один протокол всегда экономичнее другого. Значение имеют размер сообщений, частота передачи, подтверждения доставки, повторные попытки и настройки сна радиомодуля. Для маломощного датчика дополнительный обмен служебными сообщениями тоже расходует энергию. Поэтому оптимизацию оценивают на уровне всей конфигурации, а не по названию одного протокола.
Надёжность городской IoT-системы складывается из отдельных решений. Радиопокрытие, канал до платформы и обработка тревог требуют собственных мер защиты.
LoRaWAN против NB-IoT: две логики покрытия
При выборе между LoRaWAN и NB-IoT город сравнивает не только дальность связи. Различаются модель владения инфраструктурой, участие оператора, затраты на эксплуатацию и возможности размещения устройств. Одна технология не обязана вытеснять другую: в одной системе могут сосуществовать разные сети для разных типов объектов.
LoRaWAN работает в нелицензируемых диапазонах, доступных для соответствующего региона и при соблюдении местных правил использования радиочастот. В Европе часто используют диапазон около 868 МГц, в Северной Америке около 915 МГц. Город или его подрядчик может развернуть собственную сеть шлюзов, но вместе с контролем получает ответственность за их размещение, подключение, обслуживание и мониторинг.
NB-IoT использует лицензируемый сотовый спектр и инфраструктуру оператора. Для заказчика это может избавить от необходимости строить собственную сеть радиошлюзов, но наличие обычного сотового сигнала в конкретной точке не доказывает, что там доступен NB-IoT. Покрытие зависит от того, развернул ли оператор эту технологию, как настроена сеть и как радиосигнал проходит в конкретное помещение. Для подвала или колодца связь проверяют на месте, а не выводят из карты обычного мобильного покрытия.
| Параметр | LoRaWAN | NB-IoT |
|---|---|---|
| Модель сети | Собственные или предоставляемые сторонним оператором шлюзы и серверная часть | Сеть мобильного оператора |
| Радиочастоты | Нелицензируемые диапазоны, применимые в регионе | Лицензируемый сотовый спектр |
| Покрытие | Зависит от размещения шлюзов, застройки и радиопланирования | Зависит от развертывания NB-IoT оператором и условий приёма |
| Подключение устройства | Через радиошлюз | Через сеть оператора |
| Эксплуатация | Нужны обслуживание шлюзов, каналов связи и сетевой платформы | Требуется учитывать условия подключения и тарифы оператора |
| Работа в помещениях | Определяется конструкцией здания и расположением шлюзов | Может быть рассчитана на глубокое проникновение, но требует проверки в конкретной точке |
| Расходы | Нет регулярной платы оператору за передачу данных в собственной сети, но остаются расходы на эксплуатацию | Возможны регулярные платежи за подключение и передачу данных |
| Автономность устройства | Зависит от класса устройства, частоты передачи и условий радиосвязи | Зависит от модема, режима сети, качества сигнала и профиля использования |
Собственная сеть не означает бесплатную связь. Даже если город не платит оператору за каждое устройство, ему нужно оплачивать обслуживание шлюзов, электропитание там, где оно требуется, каналы подключения, мониторинг, замену оборудования и работу специалистов. У NB-IoT часть этой инфраструктуры обслуживает оператор, но условия доступа и регулярные платежи зависят от договора. Сравнивать следует полную стоимость эксплуатации, а не только строку с тарифом.
Гибридная архитектура может быть оправдана, если у разных устройств разные условия размещения. Одни датчики удобно подключать к собственной LoRaWAN-сети, другие — через сеть оператора. Но добавление второй технологии увеличивает число систем, которые нужно интегрировать и поддерживать. Решение стоит принимать по результатам обследования площадок и оценки жизненного цикла, а не по принципу разнообразия ради разнообразия.
Энергоэффективность и радиопокрытие: требования к автономности датчиков
Срок работы батареи зависит не от одной характеристики протокола. На него влияют частота измерений и передач, мощность радиосигнала, качество покрытия, температура, особенности батареи, приём команд и количество повторных попыток. При плохом радиоканале устройство может тратить больше энергии на передачу одного и того же сообщения. Поэтому расчёт автономности без оценки покрытия часто оказывается слишком оптимистичным.
Для некоторых городских датчиков ориентиром при проектировании могут служить восемь–десять и более лет автономной работы. Это не универсальная обязанность для всех устройств и не гарантия, которую автоматически даёт класс сети. Такой срок зависит от режима эксплуатации, модели устройства и условий на объекте. Датчик, которому нужно часто сообщать показания или принимать команды, будет расходовать энергию иначе, чем устройство с редкими передачами.
В LoRaWAN устройства класса A большую часть времени находятся в режиме ожидания и открывают окна приёма после собственной передачи. Такой режим помогает экономить энергию, но ограничивает возможность немедленно доставить устройству команду в любой момент. Если приложению нужно часто обращаться к устройству или быстро менять его состояние, это следует учитывать при выборе класса и архитектуры. NB-IoT тоже поддерживает режимы, рассчитанные на снижение энергопотребления, однако итог зависит от конфигурации сети и доступности сигнала.
Планирование радиопокрытия начинают с карты объектов, а не с абстрактного радиуса действия. Датчик на открытой опоре и счётчик за несколькими слоями бетона находятся в разных условиях. Для проверки полезно учитывать:
- материал стен, перекрытий и крыш, а также наличие металлических конструкций;
- положение датчика относительно шлюзов или базовых станций;
- качество приёма внутри колодцев, подвалов и технических помещений;
- возможность установки дополнительного шлюза или внешней антенны;
- частоту сообщений и требования к их подтверждению;
- доступность объекта для замены батареи и обслуживания.
Полевое обследование особенно важно там, где потеря данных имеет практические последствия. Карта покрытия помогает на этапе планирования, но не заменяет измерения в точках установки. А если сеть строится с резервом, нужно проверить, слышит ли конкретное устройство больше одного шлюза. Само наличие нескольких шлюзов в районе ещё не означает, что каждый датчик имеет альтернативный маршрут.
Экономика автономности тоже не сводится к цене элемента питания. Замена батареи требует доступа к датчику, планирования работ и проверки, что устройство вернулось в сеть. В труднодоступных местах эта операция может оказаться дороже самой батареи. С другой стороны, более крупный элемент питания или дополнительный модуль связи увеличивает размер и стоимость устройства. Оптимальный режим ищут для конкретного сценария: измерения должны быть достаточно частыми для задачи, но не избыточными.
Кибербезопасность и стандартизация городской инфраструктуры
Городские датчики передают сведения о состоянии объектов, а некоторые устройства могут влиять на работу оборудования. Поэтому безопасность нужно закладывать на всём пути данных: от устройства и радиоканала до сервера, приложения и учётной записи оператора. Одного шифрования радиопередачи недостаточно, если устройство использует слабую аутентификацию, ключи хранятся без защиты или доступ к платформе не разграничен.
В спецификациях LoRaWAN предусмотрено применение AES-128 для защиты сетевого и прикладного обмена. Практический уровень защиты зависит от того, как реализованы управление ключами, ввод устройств в эксплуатацию и их вывод из сети. Для NB-IoT используются механизмы защиты сотовой инфраструктуры, но это не отменяет требований к безопасности приложения, серверов и учётных записей. Защита сети оператора не предотвращает ошибочную настройку городской платформы и не заменяет контроль доступа.
Кибербезопасность связана и с устойчивостью сервиса. Для критичных функций важно определить, что произойдёт при потере связи, как долго устройство сможет хранить данные локально и какой сценарий оно выполнит без команды с платформы. Система контроля ливнёвки и датчик, который передаёт показания для аналитического отчёта, могут требовать разных режимов аварийной работы. Универсальный ответ здесь опасен: поведение задают для конкретного процесса и проверяют испытаниями.
Стандартизация помогает соединять оборудование разных поставщиков, но сама по себе не гарантирует совместимости всех компонентов. В российской нормативной базе появились ГОСТ Р 71866-2024 и ГОСТ Р 71870-2024, относящиеся к автоматизированным системам управления зданиями и используемым в них устройствам. При применении этих документов важно смотреть на область действия и конкретные требования, а не считать, что любой городской IoT-проект автоматически подпадает под них.
Для закупки полезно заранее описывать интерфейсы обмена, формат данных, требования к обновлению программного обеспечения и порядок передачи настроек при смене подрядчика. Тогда оборудование можно оценивать не только по отдельным характеристикам, но и по тому, как оно войдёт в существующую систему. Это снижает риск зависимости от одного поставщика, хотя полностью не устраняет его: совместимость всё равно нужно подтверждать документацией и испытаниями.
Городская сеть начинается с условий эксплуатации
В мастер-плане умного города датчики легко разместить на каждом квартале. В реальности каждый объект требует ответа на более приземлённые вопросы: где будет стоять устройство, откуда оно получит питание, кто проверит качество связи, как система отреагирует на потерю данных и кто заменит батарею. Именно эти решения превращают набор оборудования в инфраструктуру, которой можно пользоваться годами.
Если сигнал не проходит в подвал, нельзя исправить это одной настройкой облачной платформы. Если шлюз отключился, наличие резервного сервера не поможет принять пакет, который больше никто не слышит. Если датчик передаёт данные слишком часто, обещанный срок автономности может не выдержаться. Каждая проблема относится к своему уровню, поэтому архитектуру проектируют целиком, но проверяют по отдельным участкам.
Сети интернет вещей становятся частью городской инфраструктуры тогда, когда радиопокрытие, питание, безопасность, обслуживание и программная совместимость рассматриваются вместе. Выбор между LoRaWAN и NB-IoT в таком случае не сводится к поиску победителя. Он зависит от объектов, покрытия и модели эксплуатации. Для горожанина качество этой работы проявляется просто: показания доходят, тревога попадает к нужной службе, а датчик не исчезает из системы после первой же трудной зимы.