Почти год назад я начал публиковать серию статей по архитектуре IoT решений. (Ссылка на первую статью habr.com/ru/post/420173). И вот наконец вторая статья серии отдается на ваш суд.
Проекты IoT выглядят похожими друг на друга, и это правда, что они имеют общие компоненты. Но в то же время, у проектов IoT есть фундаментальные отличия, начинающиеся с запроса рынка и классов решаемых задач.
Очевидно, что разрабатывать каждое решение “с чистого листа” крайне не эффективно. Многие компоненты могут быть переиспользованы по принципу паттернов программирования.
В этой статье мы проанализируем различные классы IoT решений и их соответствующие реализации. В итоге, будут даны рекомендации по шагам реализации IoT архитектуры и мы попытаемся выделить общие тенденции IoT решений.
Также мы попробуем сформулировать основные проблемные области, с рассмотрения которых, стоит начинать построение архитектур конкретных IoT решений и возможные проблемные зоны архитектур.
На сегодняшний день существует деление на три основных географических региона применения IoT решений:
IoT рынок Европы рассматривает проекты связанные с экономией использования природных ресурсов. Типичным примером является дневное / ночное освещение, автоматизация отопления помещений, управление использованием воды, пожарная сигнализация.
На этом рынке первым приоритетом применения IoT решений является безопасность. Типичным применением служат камеры, обнаруживающие нестандартные ситуации на дороге, транспорте, дома. Второй большой областью являются решения безопасности и предупреждения стихийных бедствий, таких как сейсмическая активность, ураганы, тайфуны, цунами.
На этом рынке в основном представлены проекты IoT, направленные на оптимизацию бизнес-процессов, таких как оптимизация перевозок, эффективная доставка товаров, а также элементы умных домов и городов.
Конечно, решения IoT проникают с одного на другой рынок и не являются исключительными прерогативами. В каждом регионе мы можем найти все классы IoT решений. Для нас важно классифицировать эти классы IoT продуктов, существующие сегодня на мировых рынках. Ниже приводиться список таких классов решений IoT:
На рисунке ниже представлена уровневая архитектура IoT решений. Топология IoT отличается от обычной уровневой модели, такой как OSI. Это не линейный и более сложный граф потоков. Некоторые компоненты являются необязательными и могут отсутствовать в конкретном классе решений. Могут присутствуют два типа логики — M2M (от машины к машине) и M2P (от машины к человеку), а также более частные случаи такие как С2С (от автомобиля к автомобилю, как правило в одной соте мобильной связи LTE).
IoT решение имеет два физических местоположения — первое это конечные (периферийные) устройства, а второе — в центре обработки данных Backend на серверах или в облаке. В то же время, это не классическая архитектура клиент-серверного приложения, как мы будем видеть далее.
Ниже мы разберем каждый уровень в отдельности и сопоставим его особенности с фактическими классами решений IoT.
Этот уровень представляет два типа операций — сбор информации (Датчики) и осуществление механической работы (Исполнительные механизмы).
Датчики можно разделить на следующие категории:
В решениях IoT физические элементы имеют определенные общие требования:
Исполнительные механизмы IoT решений открывают замки входных дверей, приводят в действие двигатели, сельсины, включают/выключают свет, отопление, воду, газ и пр. Сильных изменений в реализации исполнительных механизмов не произошло. Поэтому эта часть IoT решения не будет освещаться в этой статье.
Ниже приведена таблица физического уровня в различных классах IoT решений:
Мы можем суммировать две проблемы для требований физического уровня:
Этот уровень обычно подключается к одному датчику или исполнительному механизму. Он обеспечивает минимальную функциональность для преобразования аналоговой информации в цифровую и/или наоборот. Для подключения датчиков существуют те же требования по цене и потребляемой мощности. Многие производители, выпускающие эти типы устройств, не имеют единого стандарта для модели данных, конфигурации и эксплуатации, что создает отдельные проблемы интеграции.
Для снижения энергопотребления периферийные устройства обычно имеют четыре режима работы:
Ниже представлена блок-схема периферийного устройства.
Ниже приведена таблица уровня периферийного вычисления в различных классах IoT решений:
Итак, основное требования уровня периферийного вычисления:
Низкое энергопотребление. Это может быть достигнуто с помощью аппаратного обеспечения с низким энергопотреблением и алгоритмов Sleep / WakeUp. Часто наличие локального элемента искусственного интеллекта.
Передача данных является самой энергоемкой частью периферийного устройства, т.к. большинство периферийных устройств не подключены к электросети и проводным средствам связи. Кроме того, периферийные устройства могут быть расположены довольно далеко от Шлюза (в пределах нескольких километров). С другой стороны, количество передаваемой информации обычно довольно мало. Следующие протоколы используются на уровне периферийной коммуникации:
Для увеличения расстояния и надежности связи Ad Hoc и Mesh широко используются сегодня на этом уровне.
Для целей конфигурации также может использоваться протокол NFC. В процессе первой установки и / или технического обслуживания сервисный инженер с мобильным приложением может подключаться к периферийному устройству через уровень периферийной коммуникации. Иногда Q-код, напечатанный на периферийном устройстве, также используется для аутентификации.
Ниже приведена таблица уровня периферийной коммуникации в различных классах IoT решений:
В IoT-решении существует несколько причин наличия уровня шлюза:
Шлюз должен обеспечивать следующий основной функционал:
В некоторых случаях функциональность AI / ML (искусственный интеллект / машинное обучение) должна присутствовать на уровне шлюза. Шлюзовое устройство в основном питается от электросети или имеет большую встроенную батарею, но в некоторых решениях также требуется низкое энергопотребление. В такой ситуации возникает дополнительная проблема — протокол синхронизации для связи с периферийным устройством. Один из них (шлюз или периферийное устройство) должен передавать сообщение «Готов к общению» чаще, чем другое устройство готово выйти на связь. Выбор будет зависеть от общего энергопотребления каждого устройства и требуемого времени без обслуживания.
Сегодня у нас растет количество приложений с источником информации в виде видеокамеры. В этих конкретных решениях устройство Gateway и Edge могут быть интегрированы вместе. Функциональность AI / ML в таких приложениях становится весьма востребованной. С новыми ускорителями машинного интеллекта для встроенных систем такое решение стало реальностью.
Отдельно надо сказать о шлюзах для решений умного дома. Шлюз в таком классе решений часто объединяют с устройствами STB — телевизионных адаптеров или с блоком управления домашней безопасностью. Для первой интеграции уже существует открытая платформа RDK-V. В ближайшем будущем надо ожидать дальнейшую интеграцию всех трех компонент — шлюз+STB+безопасность в одно устройство. В нем также вероятно будут присутствовать сервисы NAS (локального хранения файлов) и AI/ML для машинного видео / аудио распознавания. Устройства аудио распознавания, такие как Alexa, базируются на Cloud инфраструктуре, но вероятно первичное распознавание будет переноситься на периферийный уровень.
Ниже приведена таблица уровня шлюза в различных классах IoT решений:
Этот слой разделяет периферийную и BackEnd части общего решения. Шлюз в основном подключен к BackEnd с использованием мобильной беспроводной связи, такой как 4G / 5G, но иногда используется проводной доступ в Интернет. Логический уровень внешней связи имеет стандартизированный протокол для решений IoT, который называется LvM2M. Протокол LvM2M был разработан для доступа к каждому периферийному устройству, но поскольку многие поставщики периферийных устройств не поддерживают интерфейсы LvM2M, шлюзовое устройство может решить эту проблему и создать обертку для связи с периферийными устройствами.
Уровень внешней связи содержит также коммуникационные сервисы и модели ISO внутри себя. Он включает службы балансировки и определения местоположения, основанные на DNS сервисе, транспортный протокол COAP, шифрование DTLS и многие другие компоненты, которые выходят за рамки данной статьи.
Один важный комментарий, который мы должны сделать здесь. Протокол LvM2M использует протокол шифрования DTLS. Протокол DTLS — это протокол с ключами безопасности и сессией установления соединения — handshake. Он работает по схеме точка-точка. Для расшифровки пакетов DTLS мы должны использовать тот же экземпляр Back End, который был у нас во время сессии соединения. Это создает проблему для балансировщика нагрузки (Load Balancer), который является частью уровня безопасности на нашей схеме. Балансировщик нагрузки, в свою очередь, необходим для автоматического масштабирования при высокой загрузке системы. Чтобы избежать этого ограничения, служба DNS используется в качестве балансировщика нагрузки. Каждые N DNS-запрос получает новый IP-адрес экземпляра уровня безопасности.
Ниже приведена таблица уровня внешней связи в различных классах IoT решений:
Этот уровень обеспечивает функции AAA (Authentication, Authorization and Accounting — аутентификация, авторизация и учет) и шифрование / дешифрование вместе с другими услугами, связанными с Интернетом. Все Cloud имеют свои собственные реализации безопасности, но функционально они все построены на принципе ролей и разрешений. Как было отмечено в параграфе выше, этот уровень выполняет также функции терминатора шифрованного соединения DTLS.
Подключение конечного пользователя к Backend также имеет компонент уровня безопасности.
Ниже приведена таблица уровня безопасности в различных классах IoT решений:
Этот слой обеспечивает внутреннюю Cloud функциональность балансировки нагрузки, очереди сообщений и передачи потоковой информации. Компоненты этого слоя должны быть дублированы и автоматически масштабироваться. Уровень реализуется в основном на основе микросервисов или PaaS от Cloud провайдеров. Такое требование вытекает из парадигмы скачков и провалов объема данных. Автоматическое масштабирование снижает стоимость Backend реализации. Фактическая реализация сервиса может быть разной, но общий принцип остается одним — обеспечить асинхронную передачу сообщений с буферизацией и перераспределением нагрузки. Таким образом различные компоненты Backend могут выполнять свою работу независимо и горизонтально масштабироваться в зависимости от нагрузки.
На рисунке представлена схематическая блок диаграмма паттернов внутрисерверной связи. Load Balancer предназначен для распределения нагрузки между разными сервисами. Queue — очереди обеспечивают промежуточную буферизация для реализации асинхронной работы последовательных сервисов. Subscribers — получатели, подписываются на соответствующие их логике очереди чтобы получать последовательно сообщения после обработки предыдущих сообщений.
Ниже приведена таблица уровня внутри серверной связи в различных классах IoT решений:
Внутренний уровень ETL (извлечение, преобразование и загрузка) является третьей операцией ETL. Первый был в периферийном устройстве, второй — в шлюзе. Back End ETL накапливает данные со всех периферийных устройств и шлюзов и отвечает за следующие операции:
Общая схема реализации этого слоя представлена на рисунке. Операция сбора данных (Extract) включает в себя чтение информации из релевантных очередей. Операция трансформации может выполняться специализированными сервисами Cloud, такими как Ламбда, или вычислительными средствами внутри контейнеров и просто виртуальными машинами. Каждый из вышеперечисленных методов имеет свои положительные и отрицательными свойствами. Так например, Ламбда сервис удобен почти полной автоматизацией, но имеет существенное время создания и потому не применим, если требуется быстрая реакция на появившиеся события. Также Ламбда плохо подходит для постоянных обработок, поскольку тарифицируется по времени использования. Наиболее часто применимая служба — контейнеризированные вычисления. Они удобно масштабируются и легко переносятся на различные BackEnd. Основная задача этой операции — произвести приведение данных к удобному для хранения, сортировки и поиску виду. Для этого часто данные объединяются из разных сообщений и даже очередей.
Операции хранения (Load) предназначены для сохранения, сортировки и последующего поиска информации. В зависимости от типа информации и вариантов ее использования, применяются различные инструменты. Если данные не имеют строгой схемы (колонок таблицы), то они хранятся в NoSQL базах. Однако, если данные могут быть систематизироваться фиксированной схемой, то используются SQL типы баз данных. Последние, в свою очередь имеют 2 типа — OLTP (Online Transactional Processing) и OLAP (Online Analytic Processing). Как следует из названия, первый тип более подходит для самого процесса ETL — записи в базу новых значений, в то время как второй удобнее для поиска и анализа данных. Поэтому часто после загрузки в OLTP базу, в фоновом режиме, данные копируются в OLAP. Встречаются ситуации, когда данные не удобно или не возможно хранить в базах данных, например виде записи, Эти данные записывают в Bucket, а метаданные записей хранят в базах данных. Для сокращения расходов на хранение, устаревшие данные архивируются или удаляются. И последним компонентом этого уровня является внутренняя нотификация о наличии новых сохраненных данных для представления клиентам и для сервисов анализа.
Ниже приведена таблица уровня сбора, обработки и хранения в различных классах IoT решений:
Зависит от конкретного приложения IoT. Большие данные и аналитический уровень будут извлекать ситуативную информацию из всего набора периферийных устройств. Эта часть менее стандартизирована, потому что она сильно отличается от одного приложения к другому в силу различных задач решений. Алгоритмы AI / ML также широко используются в этом слое.
Отдельной категорией является предсказание будущих событий, таких как необходимые части на складе, потребление будущих ресурсов, погода и пр.
Ниже приведена таблица уровня аналитики в различных классах IoT решений:
На этом уровне может существовать несколько компонент, но все они имеют алгоритм уведомления по подписке. Клиентское приложение подписывается на необходимые события и, когда это происходит, получает информационный сигнал — уведомление. В основном это приложения электронной почты и мобильные клиенты, меньше телефонные звонки (используется для экстренного оповещения). Мобильное приложение вынуждено переходить в спящий режим для энергопотребления, но ОС iOS и Android имеют механизм уведомлений, указывающий на прибытие новых данных.
Ниже приведена таблица уровня уведомления в различных классах IoT решений:
Приложение IoT может иметь два потока: M2M (от машины к машине) и M2P (от машины к человеку). Уровень представления, связанный с потоком M2M, где Back End обрабатывает информацию и предоставляет ее клиенту или инженеру службы поддержки. Сегодня не существует стандартизированного UI / UX представления для этого уровня, но я надеюсь, что в ближайшем будущем он появиться.
Уровень представления также отвечает за обслуживание, конфигурацию и изменения состояния системы включая периферийные устройства и шлюзы. В нем представлены и команды на управляющие исполнительными механизмами периферийных устройств.
Ниже приведена таблица уровня представления в различных классах IoT решений:
Этот уровень относится к обоим потокам — M2M и M2P и работает как хранилище для трех типов статусов периферийных устройств:
Периферийное устройство и даже шлюз могут иметь только короткое время подключения к Backend. Мы обсуждали это ранее. Любое изменение статуса от клиента или системы, хранятся в этом уровне, и в течение времени связи отправляется на шлюз или периферийное устройство.
Чтобы такая логика работала, обычно реализуется следующий процесс коммуникации:
Если шлюз присутствует в схеме передачи информации, то большая часть информации от периферийных устройств отправляется на серверную часть в виде пакетов данных, собранных с нескольких периферийных устройств.
Ниже приведена таблица уровня конфигурации в различных классах IoT решений:
Подводя итог вышесказанному. Следующие тенденции развития наблюдаются в IoT решениях:
С чего начинать строить архитектурное решение IoT? Нет единого подхода к ответу на этот вопрос. И здесь я приведу свое персональное мнение:
Надеюсь эта статья будет полезной, хотя бы для первого занкомства с IoT проектами. В дальнейшем я постараюсь привести конкретные реализации IoT решений.
Проекты IoT выглядят похожими друг на друга, и это правда, что они имеют общие компоненты. Но в то же время, у проектов IoT есть фундаментальные отличия, начинающиеся с запроса рынка и классов решаемых задач.
Очевидно, что разрабатывать каждое решение “с чистого листа” крайне не эффективно. Многие компоненты могут быть переиспользованы по принципу паттернов программирования.
В этой статье мы проанализируем различные классы IoT решений и их соответствующие реализации. В итоге, будут даны рекомендации по шагам реализации IoT архитектуры и мы попытаемся выделить общие тенденции IoT решений.
Также мы попробуем сформулировать основные проблемные области, с рассмотрения которых, стоит начинать построение архитектур конкретных IoT решений и возможные проблемные зоны архитектур.
Области применения IoT
На сегодняшний день существует деление на три основных географических региона применения IoT решений:
Европа
IoT рынок Европы рассматривает проекты связанные с экономией использования природных ресурсов. Типичным примером является дневное / ночное освещение, автоматизация отопления помещений, управление использованием воды, пожарная сигнализация.
Дальневосточный регион
На этом рынке первым приоритетом применения IoT решений является безопасность. Типичным применением служат камеры, обнаруживающие нестандартные ситуации на дороге, транспорте, дома. Второй большой областью являются решения безопасности и предупреждения стихийных бедствий, таких как сейсмическая активность, ураганы, тайфуны, цунами.
Североамериканский рынок
На этом рынке в основном представлены проекты IoT, направленные на оптимизацию бизнес-процессов, таких как оптимизация перевозок, эффективная доставка товаров, а также элементы умных домов и городов.
Конечно, решения IoT проникают с одного на другой рынок и не являются исключительными прерогативами. В каждом регионе мы можем найти все классы IoT решений. Для нас важно классифицировать эти классы IoT продуктов, существующие сегодня на мировых рынках. Ниже приводиться список таких классов решений IoT:
- Умный Город. Главные задачи — управление и регулирование автомобильного движения, ночное / дневное уличное освещение, уведомление об опасности для пешеходов, определение нестандартных и опасных ситуаций в городе.
- Умный дом. Главные задачи — Безопасность, интеллектуальный дверной звонок, управление телевизором и кухней, автоматические системы полива и освещения, сигнализация пожара, газа, утечки воды, температуры дома.
- Погода и стихийные бедствия. Метеорологическая информация, сейсмическая активность, противопожарный контроль. Прогнозирование погодных данных.
- Оптимизация использования ресурсов в доме, городе, стране. Освещение, потребление электричества, отопления, оптимизация и прогнозирование использования, например топлива на электростанциях.
- Оптимизация перевозок, доставок, хранения и сортировки. Такие компании, как DHL, FedEx использует решение для построения оптимальных транспортных маршрутов. Терминалы хранения и сортировки грузов в крупных аэропортах.
- Заводской мониторинг и контроль, управление конвейерной линией. Управление роботами. Сортировка товаров, сырья и тестирование готовой продукции.
- Сложные механизмы, высокотехнологичные устройства, такие как современные автомобили, самолеты и пр. Автоматизированная система управления, защита от угона, контроль агрегатов системы. Распознавание лица и тела водителя для предотвращения сна, потери внимания. Прогнозирование обслуживания и замены компонентов системы.
IoT архитектура
Общая топология IoT решения
На рисунке ниже представлена уровневая архитектура IoT решений. Топология IoT отличается от обычной уровневой модели, такой как OSI. Это не линейный и более сложный граф потоков. Некоторые компоненты являются необязательными и могут отсутствовать в конкретном классе решений. Могут присутствуют два типа логики — M2M (от машины к машине) и M2P (от машины к человеку), а также более частные случаи такие как С2С (от автомобиля к автомобилю, как правило в одной соте мобильной связи LTE).
IoT решение имеет два физических местоположения — первое это конечные (периферийные) устройства, а второе — в центре обработки данных Backend на серверах или в облаке. В то же время, это не классическая архитектура клиент-серверного приложения, как мы будем видеть далее.
Ниже мы разберем каждый уровень в отдельности и сопоставим его особенности с фактическими классами решений IoT.
Physical Layer — физический уровень
Этот уровень представляет два типа операций — сбор информации (Датчики) и осуществление механической работы (Исполнительные механизмы).
Датчики можно разделить на следующие категории:
- Сенсоры:
- Световые: Фото диоды/транзисторы/резисторы, PIR детекторы
- Звуковые: Микрофоны, ультразвуковые сенсоры
- Выключатели, в частности концевые выключатели, регистрирующие крайние точки механического движения. Измерители угла поворота или скорости вращения.
- Электромагнитные сенсоры измеряющие изменение физических характеристик, таких как электрическая емкость, индуктивность, сопротивление.
- Сложные или составные сенсоры. К ним относятся специализированные датчики, например газа, спектра и пр., а также отдельный вид устройств сбора информации получающий все большее применение — Видео камеры.
В решениях IoT физические элементы имеют определенные общие требования:
- Как можно более низкую цену из-за большого количества в решении IoT.
- Питание от батарейки, что в свою очередь требует низкого энергопотребления. Сегодняшний запрос рынка — работа периферийных устройств без обслуживания от 1 до 10 лет.
- Часто расположение в труднодоступных и удаленных местах с минимальными затратами на установку и обслуживание.
- В случае использования видеокамер, первичная обработка изображения с принятием решения на основе искусственного интеллекта
Исполнительные механизмы IoT решений открывают замки входных дверей, приводят в действие двигатели, сельсины, включают/выключают свет, отопление, воду, газ и пр. Сильных изменений в реализации исполнительных механизмов не произошло. Поэтому эта часть IoT решения не будет освещаться в этой статье.
Ниже приведена таблица физического уровня в различных классах IoT решений:
| Physical Layer types | Requirements | |
| Умный город | Датчики света, звука. Видеокамеры. Датчики пешехода и автомобиля. Устройства управления светом. Громкоговорители. | Низкая цена |
| Умный дом | Датчики движения, освещения, температуры, пожара, газа, утечки воды, открытия окон и дверей. Видеокамеры. Микрофоны. Устройства открытия дверей, управления светом, климат контроль. |
Низкий уровень электропотребления датчиков. |
| Погода / Катаклизмы | Пьезосенсоры, датчики влажности, скорости ветра, температуры. Как правило, нет исполнительных устройств. | Очень низкое потребление энергии. Уличное исполнение |
| Экономия ресурсов | Датчики освещенности, температуры, воды. Сигнализация утечек воды, газа, наличие дыма. Устройства регулирования воды, температуры и света. | Низкое энергопотребление |
| Транспортная оптимизация | GPS трекеры, Видеокамеры, баркод ридеры. | Нет специальных требований |
| Заводы | Датчики присутствия, механические ограничители. Видеокамеры. Роботизированные элементы. | Заводское исполнение с защитой от пыли, вибрации |
| Сложные механизмы | Видеокамеры, специализированные датчики. Исполнительные механизмы. | Высокая надежность |
Мы можем суммировать две проблемы для требований физического уровня:
- Низкое энергопотребление. Требуется высокий уровень интеграции с верхними слоями.
- Применение видеокамер. Это также требует высокой степени интеграции с верхними уровнями и встроенными функциями AI / ML, реализованными в периферийном устройстве.
Edge Layer — уровень периферийного вычисления
Этот уровень обычно подключается к одному датчику или исполнительному механизму. Он обеспечивает минимальную функциональность для преобразования аналоговой информации в цифровую и/или наоборот. Для подключения датчиков существуют те же требования по цене и потребляемой мощности. Многие производители, выпускающие эти типы устройств, не имеют единого стандарта для модели данных, конфигурации и эксплуатации, что создает отдельные проблемы интеграции.
Для снижения энергопотребления периферийные устройства обычно имеют четыре режима работы:
- Режим сна
- Режим измерения и сбора информации с датчиков
- Режим связи, передачи и получения информаци
- Режим установки и подключения
Ниже представлена блок-схема периферийного устройства.
Периферийное устройство обычно объединяет три уровня: физический, периферийного вычисления и коммуникационный. Основная функциональность уровня периферийного вычисления- локальная ETL (Extract, Transformation and Load) — получение, преобразование и сохранение информации с датчиков. Этот уровень ответственен не только за сбор информацию с датчика, но также и за приведение ее к стандартному виду, фильтрацию помех, предварительный анализ и локальное сохранение.
Ниже приведена таблица уровня периферийного вычисления в различных классах IoT решений:
| Edge Layer type | Requirements | |
| Умный город | SoC модули, такие как Raspberry Pi. Встроенные системы машинного интеллекта. | Низкая цена |
| Умный дом | SoC или Arduino модули. | Низкий уровень электропотребления. |
| Погода / Катаклизмы | Arduino и SoC модули, Модули с программируемой логикой PLC. | Очень низкое потребление энергии. Уличное исполнение |
| Экономия ресурсов | SoC или Arduino модули. | Низкое энергопотребление |
| Транспортная оптимизация | Tablet PC, Промышленные компьютеры. | Нет специальных требований |
| Заводы | Arduino, PoC, Промышленные компьютеры. Встроенные системы машинного интеллекта. | Заводской тип исполнения |
| Сложные механизмы | Специализированные контроллеры. Встроенные системы машинного интеллекта. | Высокая надежность. Присутствие функционала гипервизоров. |
Итак, основное требования уровня периферийного вычисления:
Низкое энергопотребление. Это может быть достигнуто с помощью аппаратного обеспечения с низким энергопотреблением и алгоритмов Sleep / WakeUp. Часто наличие локального элемента искусственного интеллекта.
Local Network Layer — уровень периферийной коммуникации
Передача данных является самой энергоемкой частью периферийного устройства, т.к. большинство периферийных устройств не подключены к электросети и проводным средствам связи. Кроме того, периферийные устройства могут быть расположены довольно далеко от Шлюза (в пределах нескольких километров). С другой стороны, количество передаваемой информации обычно довольно мало. Следующие протоколы используются на уровне периферийной коммуникации:
- ZigBee/ Zwave
- BLE
- LoRa
- Proprietary low band
Для увеличения расстояния и надежности связи Ad Hoc и Mesh широко используются сегодня на этом уровне.
Для целей конфигурации также может использоваться протокол NFC. В процессе первой установки и / или технического обслуживания сервисный инженер с мобильным приложением может подключаться к периферийному устройству через уровень периферийной коммуникации. Иногда Q-код, напечатанный на периферийном устройстве, также используется для аутентификации.
Ниже приведена таблица уровня периферийной коммуникации в различных классах IoT решений:
| Local Network Layer types | Requirements | |
| Умный город | PLC, WiFi, BLE, LoRa. | Поддержка Ad Hoc, Mesh |
| Умный дом | BLE, WiFi, ZigBee, LoRa, Ethernet. | Низкий уровень энергопотребления. Технологии Mesh. |
| Погода / Катаклизмы | Lora или похожие радио протоколы. LTE. | Очень низкий уровень энергопотребления. Небольшая скорость передачи данных. Большие расстояния для передачи (до 10км). |
| Экономия ресурсов | BLE, ZigBee, LoRa | Низкий уровень энергопотребления.Возможно технологии Mesh и Ad Hoc. |
| Транспортная оптимизация | LTE | Нет специальных требований |
| Заводы | PLC, BLE, WiFi, ZigBee, LoRa, Ethernet. | Возможно технологии Mesh и Ad Hoc. |
| Сложные механизмы | CAN. |
Gateway Layer — уровень шлюза
В IoT-решении существует несколько причин наличия уровня шлюза:
- Если Backend будет получать необработанную информацию, это увеличит его мощность и затраты будут очень велики.
- Работа Backend не может гарантировать реакцию в реальном времени для большого количества периферийных устройств.
- Из-за ограничений безопасности некоторая информация не может быть отправлена в Backend и не может постоянно контролироваться человеком. К такой информации относятся данные камер уличного наблюдения, медицинская информация, и пр.
Шлюз должен обеспечивать следующий основной функционал:
- Осуществлять второй уровень ETL от своих периферийных устройств.
- Фиксировать критическую ситуацию и выдавать локальную реакцию, даже без связи с BackEnd. Это можно сравнить с сигналами сердцебиении человека или дыхании легких без участия головного мозга.
- Коммуницировать с BackЕnd. Отправляет на сервер обработанную информацию с периферийных устройств и получает данные конфигурации для периферийных устройства.
- Сохранять информацию о статусе периферийных устройств, и данные ими собранные.
В некоторых случаях функциональность AI / ML (искусственный интеллект / машинное обучение) должна присутствовать на уровне шлюза. Шлюзовое устройство в основном питается от электросети или имеет большую встроенную батарею, но в некоторых решениях также требуется низкое энергопотребление. В такой ситуации возникает дополнительная проблема — протокол синхронизации для связи с периферийным устройством. Один из них (шлюз или периферийное устройство) должен передавать сообщение «Готов к общению» чаще, чем другое устройство готово выйти на связь. Выбор будет зависеть от общего энергопотребления каждого устройства и требуемого времени без обслуживания.
Сегодня у нас растет количество приложений с источником информации в виде видеокамеры. В этих конкретных решениях устройство Gateway и Edge могут быть интегрированы вместе. Функциональность AI / ML в таких приложениях становится весьма востребованной. С новыми ускорителями машинного интеллекта для встроенных систем такое решение стало реальностью.
Отдельно надо сказать о шлюзах для решений умного дома. Шлюз в таком классе решений часто объединяют с устройствами STB — телевизионных адаптеров или с блоком управления домашней безопасностью. Для первой интеграции уже существует открытая платформа RDK-V. В ближайшем будущем надо ожидать дальнейшую интеграцию всех трех компонент — шлюз+STB+безопасность в одно устройство. В нем также вероятно будут присутствовать сервисы NAS (локального хранения файлов) и AI/ML для машинного видео / аудио распознавания. Устройства аудио распознавания, такие как Alexa, базируются на Cloud инфраструктуре, но вероятно первичное распознавание будет переноситься на периферийный уровень.
Ниже приведена таблица уровня шлюза в различных классах IoT решений:
| Gateway Layer types | Requirements | |
| Умный город | Специализированные компьютеры с компонентами машинного интеллекта. | Должен иметь логику для работы без поддержки со стороны Backend. |
| Умный дом | Mini PC с элементами машинного интеллекта. | Из-за требований безопасности должны присутствовать антивандальные компоненты. |
| Погода / Катаклизмы | Редко востребован в этих задачах. | |
| Экономия ресурсов | SoC или Tiny компьютеры | Низкий уровень энергопотребления. |
| Транспортная оптимизация | Не применяется в этом классе задач | Нет специальных требований |
| Заводы | Компьютеры заводского исполнения с элементами машинного интеллекта. | Должен иметь логику для работы без поддержки со стороны Backend. |
| Сложные механизмы | Не применяется в этом классе задач |
Wide Network Layer — уровень внешней связи
Этот слой разделяет периферийную и BackEnd части общего решения. Шлюз в основном подключен к BackEnd с использованием мобильной беспроводной связи, такой как 4G / 5G, но иногда используется проводной доступ в Интернет. Логический уровень внешней связи имеет стандартизированный протокол для решений IoT, который называется LvM2M. Протокол LvM2M был разработан для доступа к каждому периферийному устройству, но поскольку многие поставщики периферийных устройств не поддерживают интерфейсы LvM2M, шлюзовое устройство может решить эту проблему и создать обертку для связи с периферийными устройствами.
Уровень внешней связи содержит также коммуникационные сервисы и модели ISO внутри себя. Он включает службы балансировки и определения местоположения, основанные на DNS сервисе, транспортный протокол COAP, шифрование DTLS и многие другие компоненты, которые выходят за рамки данной статьи.
Один важный комментарий, который мы должны сделать здесь. Протокол LvM2M использует протокол шифрования DTLS. Протокол DTLS — это протокол с ключами безопасности и сессией установления соединения — handshake. Он работает по схеме точка-точка. Для расшифровки пакетов DTLS мы должны использовать тот же экземпляр Back End, который был у нас во время сессии соединения. Это создает проблему для балансировщика нагрузки (Load Balancer), который является частью уровня безопасности на нашей схеме. Балансировщик нагрузки, в свою очередь, необходим для автоматического масштабирования при высокой загрузке системы. Чтобы избежать этого ограничения, служба DNS используется в качестве балансировщика нагрузки. Каждые N DNS-запрос получает новый IP-адрес экземпляра уровня безопасности.
Ниже приведена таблица уровня внешней связи в различных классах IoT решений:
| Wide Network Layer types | Requirements | |
| Умный город | PLC, Ethernet, LTE, LvM2M, FOTA/SOTA. | Связь LTE может использовать коммуникацию в пределах одной соты без доступа к Backend. |
| Умный дом | Ethernet, LTE. | Часто интегрировано с провайдерами Интернет и видео контента. |
| Погода / Катаклизмы | LTE, Radio, LvM2M. | Низкая скорость передачи большая дальность передачи. |
| Экономия ресурсов | PLC, Ethernet, LTE, LvM2M, FOTA/SOTA. | Чаще мобильная связь для сокращения затрат на установку. Но может использовать существующую низкоточную и энергетическую инфраструктуру. |
| Транспортная оптимизация | LTE. | Только мобильная связь. |
| Заводы | Ethernet, LTE, LvM2M, FOTA/SOTA. | В основном Ethernet. |
| Сложные механизмы | LTE, FOTA/SOTA. | Только мобильная связь |
Security Layer — уровень безопасности
Этот уровень обеспечивает функции AAA (Authentication, Authorization and Accounting — аутентификация, авторизация и учет) и шифрование / дешифрование вместе с другими услугами, связанными с Интернетом. Все Cloud имеют свои собственные реализации безопасности, но функционально они все построены на принципе ролей и разрешений. Как было отмечено в параграфе выше, этот уровень выполняет также функции терминатора шифрованного соединения DTLS.
Подключение конечного пользователя к Backend также имеет компонент уровня безопасности.
Ниже приведена таблица уровня безопасности в различных классах IoT решений:
| Security Layer types | Requirements | |
| Умный город | В основном реализовано в Cloud. AWS имеет более 50% использования. В AWS используются 2 базовых сервиса: R53 and IAM. Так же EC2 для терминации DTLS. | Требуется много разных ролей, вертикальных по департаментам (полиция, администрация, обслуживание, место жительства) и горизонтальных (положение в организации) |
| Умный дом | Многие вендоры имеют свои Cloud. | Требуются механизмы Cloud-to-Cloud безопасности. SSO авторизация. |
| Погода / Катаклизмы | Azure Cloud может быть востребован, иза за хороших средств аналитики | Очень большое количество подключений |
| Экономия ресурсов | Часто используются физические сервера и легаси ACL безопасность, но может быть и Cloud решения. | Дополнительное требование к безопасности — региональное хранение данных в пределах страны. |
| Транспортная оптимизация | В основном AWS IAM сервисы | Нет специальных требований |
| Заводы | Часто используются физические сервера и легаси ACL безопасность, но может быть и Cloud решения. | Интеграция с внутренними службами доступа, такими как ERP. SSO востребовано |
| Сложные механизмы | В основном AWS IAM сервисы | Нет специальных требований |
Middleware Layer — уровень внутри серверной связи
Этот слой обеспечивает внутреннюю Cloud функциональность балансировки нагрузки, очереди сообщений и передачи потоковой информации. Компоненты этого слоя должны быть дублированы и автоматически масштабироваться. Уровень реализуется в основном на основе микросервисов или PaaS от Cloud провайдеров. Такое требование вытекает из парадигмы скачков и провалов объема данных. Автоматическое масштабирование снижает стоимость Backend реализации. Фактическая реализация сервиса может быть разной, но общий принцип остается одним — обеспечить асинхронную передачу сообщений с буферизацией и перераспределением нагрузки. Таким образом различные компоненты Backend могут выполнять свою работу независимо и горизонтально масштабироваться в зависимости от нагрузки.
На рисунке представлена схематическая блок диаграмма паттернов внутрисерверной связи. Load Balancer предназначен для распределения нагрузки между разными сервисами. Queue — очереди обеспечивают промежуточную буферизация для реализации асинхронной работы последовательных сервисов. Subscribers — получатели, подписываются на соответствующие их логике очереди чтобы получать последовательно сообщения после обработки предыдущих сообщений.Ниже приведена таблица уровня внутри серверной связи в различных классах IoT решений:
| Middleware Layer types | Requirements | |
| Умный город | В этом классе не так много данных с пиковой нагрузкой. Здесь важнее потоковое видео и коррелированный поиск ситуационных данных. | Никаких особых запросов. Обычный балансировщик нагрузки с механизмом очередей. Однако требуется реализация потокового видео с использованием медиа серверов. |
| Умный дом | Пик видеопотоков от камеры умного звонка во время Хэллоуина и других событий. | Для потокового видео требуются медиа сервера и временное хранение видео. |
| Погода / Катаклизмы | Нет специальных требований | Нет специальных требований |
| Экономия ресурсов | Очереди и распределение нагрузки | Нет специальных требований |
| Транспортная оптимизация | Нет специальных требований | Нет специальных требований |
| Заводы | Очереди и распределение нагрузки | Нет специальных требований |
| Сложные механизмы | Нет специальных требований | Нет специальных требований |
Etl layer — уровень сбора, обработки и хранения данных
Внутренний уровень ETL (извлечение, преобразование и загрузка) является третьей операцией ETL. Первый был в периферийном устройстве, второй — в шлюзе. Back End ETL накапливает данные со всех периферийных устройств и шлюзов и отвечает за следующие операции:
- Сбор информации
- Приведение информации к стандартному виду
- Сохранение информации для дальнейшего использования
- Управление жизненным циклом информации включая архивирование и уничтожение
- Уведомление других сервисов о поступлении новых данных
Общая схема реализации этого слоя представлена на рисунке. Операция сбора данных (Extract) включает в себя чтение информации из релевантных очередей. Операция трансформации может выполняться специализированными сервисами Cloud, такими как Ламбда, или вычислительными средствами внутри контейнеров и просто виртуальными машинами. Каждый из вышеперечисленных методов имеет свои положительные и отрицательными свойствами. Так например, Ламбда сервис удобен почти полной автоматизацией, но имеет существенное время создания и потому не применим, если требуется быстрая реакция на появившиеся события. Также Ламбда плохо подходит для постоянных обработок, поскольку тарифицируется по времени использования. Наиболее часто применимая служба — контейнеризированные вычисления. Они удобно масштабируются и легко переносятся на различные BackEnd. Основная задача этой операции — произвести приведение данных к удобному для хранения, сортировки и поиску виду. Для этого часто данные объединяются из разных сообщений и даже очередей. Операции хранения (Load) предназначены для сохранения, сортировки и последующего поиска информации. В зависимости от типа информации и вариантов ее использования, применяются различные инструменты. Если данные не имеют строгой схемы (колонок таблицы), то они хранятся в NoSQL базах. Однако, если данные могут быть систематизироваться фиксированной схемой, то используются SQL типы баз данных. Последние, в свою очередь имеют 2 типа — OLTP (Online Transactional Processing) и OLAP (Online Analytic Processing). Как следует из названия, первый тип более подходит для самого процесса ETL — записи в базу новых значений, в то время как второй удобнее для поиска и анализа данных. Поэтому часто после загрузки в OLTP базу, в фоновом режиме, данные копируются в OLAP. Встречаются ситуации, когда данные не удобно или не возможно хранить в базах данных, например виде записи, Эти данные записывают в Bucket, а метаданные записей хранят в базах данных. Для сокращения расходов на хранение, устаревшие данные архивируются или удаляются. И последним компонентом этого уровня является внутренняя нотификация о наличии новых сохраненных данных для представления клиентам и для сервисов анализа.
Ниже приведена таблица уровня сбора, обработки и хранения в различных классах IoT решений:
| ETL Layer types | Requirements | |
| Умный город | RabbitMQ, MQTT, Kafka. Docker containers, Lambda/Function. SQL, NoSQL, Bucket storages. | Большой объем информации. Необходимо обращать внимание на дизайн, чтобы не попасть в чрезмерные платежи Cloud |
| Умный дом | MQTT, Containers, SQL, NoSQL, Bucket storages. | Данные создаются устройствами различных производителей. Для интеграции необходимо тщательно разрабатывать общую модель данных |
| Погода / Катаклизмы | Kafka, SQL, Containers | Огромное число источников информации |
| Экономия ресурсов | MQTT, Lambda/Function, SQL | Нет специальных требований |
| Транспортная оптимизация | MQTT, Containers, SQL | Нет специальных требований |
| Заводы | MQTT, Containers, SQL | Нет специальных требований |
| Сложные механизмы | Мало релевантно | Нет специальных требований |
Big Data and Analytic Layer — уровень аналитики
Зависит от конкретного приложения IoT. Большие данные и аналитический уровень будут извлекать ситуативную информацию из всего набора периферийных устройств. Эта часть менее стандартизирована, потому что она сильно отличается от одного приложения к другому в силу различных задач решений. Алгоритмы AI / ML также широко используются в этом слое.
Отдельной категорией является предсказание будущих событий, таких как необходимые части на складе, потребление будущих ресурсов, погода и пр.
Ниже приведена таблица уровня аналитики в различных классах IoT решений:
| Big Data / Analyti Layer types | Requirements | |
| Умный город | Распознавание аномальные события. Предупреждение катастроф | Нет специальных требований |
| Умный дом | Анализ потребительских запросов клиентов | Нет специальных требований |
| Погода / Катаклизмы | В основном приложения Big Data для предсказания погоды и природных катаклизмов | Нет специальных требований |
| Экономия ресурсов | Предсказания потребности ресурсов | Нет специальных требований |
| Транспортная оптимизация | Построение оптимальных маршрутов и процессов | Нет специальных требований |
| Заводы | Предсказание технического обслуживания и склада | Нет специальных требований |
| Сложные механизмы | Рекомендации по времени замены элементов системы | Нет специальных требований |
Notification layer — уровень уведомления
На этом уровне может существовать несколько компонент, но все они имеют алгоритм уведомления по подписке. Клиентское приложение подписывается на необходимые события и, когда это происходит, получает информационный сигнал — уведомление. В основном это приложения электронной почты и мобильные клиенты, меньше телефонные звонки (используется для экстренного оповещения). Мобильное приложение вынуждено переходить в спящий режим для энергопотребления, но ОС iOS и Android имеют механизм уведомлений, указывающий на прибытие новых данных.
Ниже приведена таблица уровня уведомления в различных классах IoT решений:
| ETL Layer types | Requirements | |
| Умный город | Уведомление через мобильное приложение. Звонок в экстренном случае. | Нет специальных требований |
| Умный дом | Уведомление через мобильное приложение | |
| Погода / Катаклизмы | Уведомления через электронную почту и звонок в экстренном случае. | Нет специальных требований |
| Экономия ресурсов | Уведомления через электронную почту и звонок в экстренном случае. | Нет специальных требований |
| Транспортная оптимизация | Слабо применимо | Нет специальных требований |
| Заводы | Уведомления через электронную почту, мобильное приложение и звонок в экстренном случае. | Нет специальных требований |
| Сложные механизмы | Мало релевантно | Нет специальных требований |
Presentation Layer — уровень представления
Приложение IoT может иметь два потока: M2M (от машины к машине) и M2P (от машины к человеку). Уровень представления, связанный с потоком M2M, где Back End обрабатывает информацию и предоставляет ее клиенту или инженеру службы поддержки. Сегодня не существует стандартизированного UI / UX представления для этого уровня, но я надеюсь, что в ближайшем будущем он появиться.
Уровень представления также отвечает за обслуживание, конфигурацию и изменения состояния системы включая периферийные устройства и шлюзы. В нем представлены и команды на управляющие исполнительными механизмами периферийных устройств.
Ниже приведена таблица уровня представления в различных классах IoT решений:
| Presentation Layer types | Requirements | |
| Умный город | Оповещение пешеходов об опасности на дороге. Экстренные сигналы полиции, скорой и пожарным. Рекомендации водителям. | Необходим единый городской WiFi интернет HotSpot и приложение на мобильном. |
| Умный дом | Оповещение владельца и управление элементами дома | Сложность в интеграции устройств от различных производителей |
| Погода / Катаклизмы | WEB приложения для аналитики данных | Нет специальных требований |
| Экономия ресурсов | В основном для обслуживающего персонала мобильные приложения. | Нет специальных требований |
| Транспортная оптимизация | Приложения на планшетах с картой и маршрутом. | Нет специальных требований |
| Заводы | Интеграция с системами ERP. | Нет специальных требований |
| Сложные механизмы | Не применимо | Нет специальных требований |
Configuration Layer — уровень конфигураций
Этот уровень относится к обоим потокам — M2M и M2P и работает как хранилище для трех типов статусов периферийных устройств:
- Актуальное состояние периферийного устройства
- Новое состояние периферийного устройства, которое будет загружено.
- Промежуточный статус периферийного устройства — указывает на процесс обновления от старых состояний к новым. Часто этот статус отсутствует.
Периферийное устройство и даже шлюз могут иметь только короткое время подключения к Backend. Мы обсуждали это ранее. Любое изменение статуса от клиента или системы, хранятся в этом уровне, и в течение времени связи отправляется на шлюз или периферийное устройство.
Чтобы такая логика работала, обычно реализуется следующий процесс коммуникации:
Если шлюз присутствует в схеме передачи информации, то большая часть информации от периферийных устройств отправляется на серверную часть в виде пакетов данных, собранных с нескольких периферийных устройств.
Ниже приведена таблица уровня конфигурации в различных классах IoT решений:
| Configuration Layer types | Requirements | |
| Умный город | Shadowing, twin pair, etc. | Нет специальных требований |
| Умный дом | Shadowing, twin pair, etc | Нет специальных требований |
| Погода / Катаклизмы | Слабо применимо | Нет специальных требований |
| Экономия ресурсов | Shadowing, twin pair, etc | Часто использует три состояния: старое, новое и в процессе |
| Транспортная оптимизация | Слабо применимо | Нет специальных требований |
| Заводы | Слабо применимо | Нет специальных требований |
| Сложные механизмы | Слабо применимо | Нет специальных требований |
Итоги и как строить архитектуру IoT решений.
Подводя итог вышесказанному. Следующие тенденции развития наблюдаются в IoT решениях:
- Датчики разделяются на 2 группы:
- Простые, дешевые, с максимально низким потреблением энергии. Низкой скоростью и высокой дальностью передачи информации. Это фактически разовые устройства, которые не подлежат обслуживанию.
- Основанные на видеокамере. Устройство интегрировано с периферийным компьютером. Имеет встроенные механизмы распознавания образов и принятия базовых решений.
- ETL процессы происходят на нескольких уровнях — периферийных устройств, шлюзов и в backend. Пока нет единого подхода, что должно делаться на каждом уровне, но идеология такова — все что можно обработать должно быть обработано на возможно более низком уровне.
- Основным, универсальным средством передачи информации является беспроводной интернет. Но фактические протоколы отличаются на разных уровнях. Логический уровень связи — протокол LvM2M.
- Backend в большей степени Cloud. Большинство решений на сегодняшний день используют AWS.
- В качестве устройства отображения фактической информации используется мобильное приложение, а аналитическая информации представляется WEB приложениями. Экстренное оповещение через мобильный звонок с предустановленным голосовым сообщением. Электронной почтой получаются в основном отчеты.
С чего начинать строить архитектурное решение IoT? Нет единого подхода к ответу на этот вопрос. И здесь я приведу свое персональное мнение:
- Определить модель данных, которую мы можем получить от шлюза, т.е. передаваемую в Backend.
- Проверить какие именно периферийные устройства могут собрать данные и как их надо обработать для приведение к модели передаваемой шлюзом.
- Проверить требования к периферийным устройствам — расстояния, объем информации, энергопотребление и пр.
- Выбрать соответствующее периферийное вычислительное устройство, его расположение по отношению к датчикам, протокол их работы.
- Решить архитектуру Cloud части, включая:
- Безопасность
- Распределение нагрузки
- Асинхронность передачи данных внутри Cloud
- Элементы хранение, форму и жизненный цикл данных
- Построить граф передачи информации по системе
- Построить аналитические модели, AI/ML компонент
- Разработать типы и содержание уведомлений
- Настроить резервирование и авто масштабируемость сервисов
- Оценить стоимость и провести оптимизацию
- Дизайн UI/UX для мобильных клиентов
- Построить обратную связь передачи данных в периферийное устройство
Надеюсь эта статья будет полезной, хотя бы для первого занкомства с IoT проектами. В дальнейшем я постараюсь привести конкретные реализации IoT решений.
