IoT архитектура — первый взгляд под капот
Понятие IoT (Internet of Things) давно вошло в лексикон IT-шников. Хотя я и не нашел такого хаба, но надеюсь это скоро будет исправлено :)
Однако до сих пор многие путают IoT архитектуру с архитектурой автоматизации, где главной задачей является получение информации с датчиков, и на их основе осуществляется управление исполнительными механизмами.
IT архитектура включает в себя две, на первый взгляд несовместимые вещи: с одной стороны — это большое число периферийных устройств с малыми вычислительными мощностями, низким энергопотреблением, высокой скоростью реакции на события, а с другой стороны — облачные сервера с высокой вычислительной мощностью для обработки большого массива данных, их хранения и классификации, часто с элементами машинного интеллекта и аналитики. Эти два мира используют совершенно разные принципы построения и внутренней архитектуры. Они выглядят несовместимыми и сегодня на рынке труда мало специалистов одинаково хорошо знающих Embedded и Cloud решения. Это своего рода «Full Stack». Но в этом знании кроется сила, объединяющая две, на первый взгляд совершенно не связанных технологии. От их интеграции мы получаем удивительный синергетический эффект. Это похоже на союз мужчины и женщины — грубого и сильного, утончённого и слабого. В этой статье я постараюсь описать базовую архитектуру IоT, рассматривая приложение «в целом».
На рисунке ниже представлена общая архитектура IoT решения. Весьма предсказуемо, что все начинается с датчиков. Более того, чем лучше подходит датчик для выполнения своей задачи, тем эффективней будет система дальше. Это своего рода «краеугольный камень» системы. Важно отметить, что датчик регистрирует изменение окружающей среды, а не ее статическое состояние. Датчики делятся на активные — излучающие сами сигналы и принимающие отражение; и пассивные — работающие только на прием. Естественно, что последние значительно выигрывают по параметрам энергопотребления. Большинство датчиков основано на приеме волн — звуковых, ультразвуковых, световых различного диапазона, тепловых. Однако есть категория датчиков, основанных на изменении их физических характеристик, таких как индуктивность, емкость, давление. Хорошие результаты получаются от комбинации нескольких датчиков, например PIR детектор и емкостной датчик для определения движения.
В любом случае, датчик формирует аналоговый сигнал, который необходимо перевести в цифру для дальнейшей обработки, чем и занимается AtoD преобразователь. После получения цифровой информации она должна быть обработана локальным процессором периферийного устройства. Главная его задача проставить таг полученной информации или попросту классифицировать ее. Таги могут быть простейшими, как например — есть движение, так и более сложными — движение+скорость. Иногда нужны многомерные таги — Движение, Машина. Чем более сложный таг, тем естественно больше мощность периферийного процессора и соответсвенно энергопотребление. С другой стороны, чем более информативен таг, тем меньше необходимое количество передаваемой информации в облако и соответсвенно нужна меньше полоса пропускания, а так же увеличивается скорость реакции на событие. Конечно все таги имеют метку таймстемпа.
Следующее звено может находиться как в облаке, так и на периферии, а иногда в обоих частях. Коммутатор перенаправляет полученную информацию в различные объекты, классифицируя таги. Этими объектами могут быть сервера, очереди, ламбда или просто хранилище. До сих пор работа велась с информацией от конкретного периферийного устройства и фактически ничем не отличалась от работы автоматизированных систем управления. Однако на следующем уровне — интеграции, начинается качественное отличие. Информация от различных переферийных устройств суммируется по однотипным тагам. При этом сами типы периферийных устройств могут быть даже различными. Важно, что таги попадают в единую точку, отвечающую за прием соответствующего события — тага.
В дальнейшем информация от всех объектов, суммирующих таги, систематизируется Аналитическим блоком. В нем заключается основная логика или, если так можно выразиться, мозги системы. Там находится AI, Machine Learning, и пр. Результат работы Аналитического блока передается в блок Презентации для отображения пользователю. Это может выглядеть, как отправка сообщения на мобильное устройство, график на WEB или иное.
Поскольку IoT система является распределенной и связана ненадежным каналом связи, приходится иметь механизмы гарантированной доставки информации. В том случае, если не удается передать информацию от переферийного устройства в облако, осуществляются повторные попытки передачи. То же должно происходить и в другую сторону. Для этих целей вводится блок Виртуального представления периферийного устройства, в который записывается информация для передачи периферийному устройству или новое его состояние. Часто это просто текстовый файл, но может быть и более точная модель представления. Примечательно, что изменения в модуле Виртуального представления могут быть инициализированы из различных модулей входной цепи, как показано на рисунке.
После того как мы разобрали физическую блок схему IoT архитектуры, можно рассмотреть ее логическую схему
Итак, все опять начинается с датчиков, регистрирующих изменение окружающей среды во времени. Следующий модуль тагирования производит первичное сегментирование на определенные события системы. В принципе разработка архитектуры IoT приложения и должна начинаться со списка этих событий. Суммирование Тагов производится по группе переферийных устройств с однотипными тагами. Модуль интегрирования предназначен для вынесения решения по аппроксимации (предсказанию последующих событий) или детерминированию (выявлению ситуации из множества вариантов). Эта информация служит своеобразным ключом-коэффициентом для модуля виртуальной модели периферийного устройства, в котором актуальная информация от самого периферийного устройства преобразуется на основании ключа-коэффициента в новое состояние периферийного устройства.
Теперь немного о том, что не попало в схему архитектуры описанной выше, но безусловно о чем стоит иметь ввиду:
- Хранение информации. Хранение информации должно происходить, как на уровне периферийного устройства, так и в облаке. Периферийное устройство сохраняет свою программу, настройки, состояние и временно хранит информацию от датчиков, пока она гарантированно не передана в облако. Облачное хранение информации очевидно и не требует разъяснений, по крайней мере в рамках данной статьи.
- Безопасность / авторизация. Каждое периферийное устройство должно авторизоваться в системе, причем индивидуально. Это отдельная тема, которая так же выходит за рамки данной статьи.
- Очереди и pipeline. Отдельная категория архитектуры — средства передачи информации по системе, как внутри периферийных устройств, так и в облаке и между ними.
Надеюсь, что этот краткий обзор будет полезен. В дальнейшем я планирую продолжить статьи и сделать из ник цикл, посвященный IoT решениям. Буду признателен всем за комментарии и темы, которые будут вам интересны.
