Для перемещения по дереву справки используйте строки заголовка.

Сетевые технологии
Интернет вещей
Общие принципы построения IoT

Интернет вещей (Internet of Things, IoT) — общее название для целой совокупности технологий, объединённых задачей построения систем автоматизированного мониторинга и управления. Эти системы могут:

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

Разнообразие подобных решений чрезвычайно велико, поэтому IoT ещё не очень близок к тому, чтобы прийти к единому знаменателю. Едва ли это вообще когда-либо произойдёт, поскольку практика больше подбрасывает новые задачи, с новыми вариациями в каждом из перечисленных аспектов, нежели стремится к клонированию типовых наработок. Вместе с тем, в середине второго десятилетия текущего века в данной области стали проявляться некоторые общие тенденции и принципы построения этих систем; именно они наполнили выражение "Интернет вещей" некоторым смыслом, помимо маркетингового, и позволили рассматривать его как нечто относительно единое и универсальное.

Архитектура сети IoT

Современное решение из класса "Интернета вещей" содержит, в том или ином виде, порознь или комбинированно, следующие компоненты:

  1. Датчики и исполнительные элементы (иногда называемые по-инглишу "актуаторами"). С вышестоящими контроллерами они связываются, как правило, по некоторому узкоспециализированному протоколу. Это могут быть унаследованные проводные протоколы (RS–232/485, 1–Wire, USB, CAN), беспроводные протоколы малой дальности (Bluetooth, ZigBee и т.п.) или современные протоколы сетей LP-WAN (Low-power Wide-area Network) с низким энергопотреблением и большой дальностью. Именно технологии LPWAN стали одной из важнейших компонент, определяющих облик современного IoT.
    Использование IP на этом уровне также не исключается (поверх Ethernet, сотовых сетей или Wi-Fi), но датчики на базе специализированных локальных протоколов, как правило, получаются проще, функциональнее и дешевле, чем полноценные IP-хосты — а цена имеет в данном случае первостепенное значение. С другой стороны, по мере расширения выпуска готовых встраиваемых компьютеров в формате System-on-Chip (SoC) и System-on-Module (SoM) и снижения их стоимости доля "чистых" IP-решений может увеличиться. (В частности, NSG предлагает в данном классе вычислительное ядро NSG UltraLite для построения разнообразных систем автоматизации, в т.ч. IoT.)
  2. Контроллеры датчиков. В общем случае, они терминируют соединения с датчиками на физическом уровне, а протокол канального уровня либо также терминируют и преобразовывают данные в какой-либо из стандартных протоколов IP-стека (как правило, UDP, но теоретически не исключён и, например, TCP), либо инкапсулируют поверх стандартных протоколов (в этом случае он деинкапсулируется и терминируется уже на следующем уровне архитектуры — на сервере IoT). Далее контроллер соединяется с сервером IoT уже посредством IP-сети поверх любой доступной среды передачи (Ethernet, сотовой сети и т.п.).

    Применительно к технологии LoRa, контроллер принято называть ретранслятором пакетов (packet forwarder).

    В других реализациях IoT используются также термины "шлюз" или "мост", в зависимости от сочетания их функций и фантазии автора. Возможно, в будущем для них выработается какая-то единая терминология (например, в зависимости от протокола обмена с сервером: UDP, IoT-over-UDP, или вообще совмещение функций контроллера и сервера в одном устройстве), но пока все они используются довольно волюнтаристски.
  3. Сервер IoT непосредственно работает с датчиками: регистрирует их в системе, аутентифицирует (при необходимости), опрашивает, принимает показания, отсылает команды исполнительным элементам. Дальнейший обмен с прикладным сервером также идёт по сети IP. При этом могут использоваться разнообразные прикладные протоколы поверх TCP или UDP — например, SNMP или Zabbix. Современная тенденция состоит в использовании для этой цели механизма MQTT (Message Queue Telemetry Transport), как наиболее подходящего для поставленной задачи. Именно он строит общую крышу, под которую ныне становится возможным подвести самые разнородные решения и их компоненты. Это вторая ключевая компонента, отличающая IoT от разрозненных систем предыдущих поколений.
  4. Прикладной сервер работает уже не с датчиками, а исключительно с данными, полученными от них: накапливает, хранит, обсчитывает какую-то статистику и аналитику, генерирует отчёты в разных формах... Наконец, сервер замыкает контур управления между датчиками и исполнительными элементами, если на нём задан какой-либо детерминированный алгоритм, по принципу "щёлкни кобылу по носу — она махнёт хвостом". Если же такой алгоритм не задан, то контур управления остаётся открытым и замыкается уже на пользовательском устройстве или вручную самим пользователем: получил данные — подумал головой — отправил команду.
  5. Клиентские устройства и приложения позволяют пользователю видеть информацию от сервера и отдавать команды серверу (а через него — исполнительным элементам). Как частный случай, алгоритм для автоматического управления может быть задан на клиентах, а не на сервере.

    Клиенты IoT могут быть наиболее разнообразными: стационарные компьютеры, мобильные устройства, специализированные пульты, со стандартными или специализированными приложениями. С прикладным сервером они могут взаимодействовать посредством HTTP, MQTT, электронной почты, сервисов мгновенного обмена сообщениями, консольных команд и многого другого, что можно придумать для этой цели сейчас или в будущем. Плюс средства, выходящие за рамки стека IP: SMS, USSD, голосовой телефонный интерфейс.

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

Например, как уже сказано выше, датчик IoT может объединяться с контроллером в "интеллектуальный датчик" с встроенной поддержкой IP-стека; контроллер в этом случае если и сохраняется, то вырождается в обычный коммутатор Ethernet или маршрутизатор IP, безо всякой специфики IoT. Контроллер может объёдиняться с сервером IoT, а сервер — с прикладным сервером. С другой стороны, функции прикладного сервера могут быть частично или полностью переданы клиентам. Серверы MQTT могут располагаться и на сервере IoT, и на прикладном сервере, и на отдельном хосте. И так далее. Именно такая гибкость позволяет, с одной стороны, модифицировать архитектуру в соответствии с практическими требованиями, а с другой стороны — рассматривать её как универсальный шаблон, пригодный для самых разных задач.

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

Отдельные наиболее важные компоненты IoT и их реализация в изделиях NSG рассмотрены в последующих статьях данной главы.


© Network Systems Group 2015–2022 Отдел документации