Архитектура облачных платформ Интернета вещей становится все более сложной. Для дальнейшего развития необходимо вводить унифицированные принципы и подходы, что мы видим уже сейчас: Cloud Native[i], Edge Computing[ii], OpenAPI[iii] и т.п. Еще одним из таких подходов является концепция цифровых двойников устройств (ЦДУ), о которых мы поговорим сегодня.
Представьте ситуацию: Вам нужно поехать по делам в другую страну, языка и обычаев которой Вы не знаете. Хорошо бы с такой ситуации иметь в друзьях местного жителя, который говорит и на Вашем языке. Он знает, к кому обратиться по тому или иному вопросу, а также может позвонить по местной связи (дешевой, без роуминга) и даже договориться о встрече (для обмена метаданными).
Примерно то же самое происходит с устройством IoT, когда оно начинает взаимодействовать с платформой. Появляется несколько противоречий:
потребители данных устройств хотят работать со структурированными метаданными, а устройства не могут их отправлять в силу ограничений по трафику и разницы в структуре;
владельцы устройств хотят бесшовно подключать их к различным платформам;
некоторым сервисам иногда необходимо оперативно получить статус устройства или последнее состояние, а устройство выходит на связь периодически по расписанию (здесь хотя бы можно предположить, когда это произойдет) или по событию (здесь полная непредсказуемость);
то же самое, но в другую сторону – от платформы к устройству, особенно это касается обновления прошивки;
устройство хочется наделить новыми свойствами, например, делегировать принятие каких-то решений, но оно не способно это делать физически;
устройство перемещается по распределенной инфраструктуре, подключаясь к разным его граничным точкам (Edge): растет транзитный трафик внутри платформы, необходима возможность автономной работы при отключении от остального облака.
Что происходит у MNO?
Мобильные операторы одними из первых предложили связь для IoT в лице NB-IoT (Narrow Band IoT) – узко-спектральных протокол связи. Данный протокол из класса LPWAN, то есть призван экономно расходовать ресурсы устройств. Для обращения к устройствам применяется транспортный протокол NIDD (Non-IP Data Delivery), так как обращение по IP-стеку слишком громоздко для LPWAN-сценариев. Это потребовало применения нового компонента для сохранения удобства обращения к устройствам по сети – SCEF[iv] (service capability exposure function), своего рода API обращения с устройствами. Одним из важнейших изменений в схеме взаимодействия AS (сервера приложений) с устройствами при работе через SCEF является появление универсального идентификатора. Теперь вместо телефонного номера (MSISDN) или IP адреса, как это было в классической сети 2G/3G/LTE, идентификатором устройства для сервера приложений становится «external ID». Он определен стандартом в привычном для разработчиков приложений формате «<Local Identifier>@<Domain Identifier>».
SCEF решает такие задачи:
привязка идентификатора сим-карты (IMSI) к external ID;
передача non-IP трафика (Non-IP Data Delivery, NIDD);
групповые операции, с использованием external group ID;
поддержка режима передачи данных с подтверждением;
буферизация данных;
аутентификация и авторизация устройств и серверов приложений;
одновременное использование данных одного UE (User Equipment – устройства) несколькими AS;
поддержка специальных функций контроля состояния UE (MONTE – Monitoring Events);
триггеринг устройств;
обеспечение роуминга non-IP данных.
Архитектура облачных сервисов
Обычно архитектура нижнего уровня (специфичного устройствам) облачных сервисом представлена так:
Отдельные слои являются сервисами, необходимыми для взаимодействия с устройствами: получения данных, отправки команд, обслуживания и пр. При этом каждый такой слой выполняет типовые функции для всех устройств или какой-то группы. Иными словами, мы имеем функциональное разделение сервисов. Если отвлечься от специфики телекома, архитектурно и по составу функций это похоже на SCEF.
Плюсы такого решения:
каждый слой может быть оптимизирован по выполняемой функции, то есть выбран наиболее подходящий технологический стек;
-
логически понятное для разработчиков и инженеров разделение, возможность декомпозировать задачи разработки и поддержки по функциям.
Минусы:
каждый слой получается монолитным – трудно горизонтально масштабировать;
вся разработка ведется вендором платформы, производители устройств в этом никак не участвуют;
устройства IoT обладают сильным разнообразием, так что технические решения в каждом слое не могут быть оптимальными для всех классов устройств.
Цифровые двойники устройств
Снять имеющиеся противоречия и обеспечить дальнейшее гибкое развитие платформ IoT могут цифровые двойники устройств:
ЦДУ будут теми самыми «умными» представителями устройств на платформе, имея тот же или больший набор констант и переменных (состояние), что и его устройства, синхронизируя их при возможности.
Проводя другую аналогию, можно назвать ЦДУ умным драйвером устройства на платформе: так же как сейчас мы покупаем какой-либо компонент для ПК с набором драйверов для основных ОС, так и в будущем мы сможем подключать IoT устройства к известным платформам.
Подход с ЦДУ взяли на вооружение ведущие провайдеры IoT платформ: AWS Device Shadow[v] и MS Azure Device Twins[vi]. Сейчас для этого применяется JSON, который является легкой и независимой от платформы конструкцией, но не дает достаточной изоляции. Более перспективным выглядит решение на WASM (Web Assembly)[vii], которое представляет собой сверхлегкую виртуальную машину, на которой можно запускать микросервис (правильнее было бы сказать наносервис).
Стоит также отметить, что у такого подхода будет свой оверхэд, ведь однотипные сервисы для одинаковых устройств должны работать в облаке в огромном количестве копий. Это с одной стороны выглядит проблемой, которая имеет решение. Дело в том, что образ у ЦДУ может быть один на множество однотипных устройств, а разница лишь в контексте (состояние, секреты, данные). Такой подход можно сравнить с дедупликацией в хранилищах данных. С этим можно эффективно работать – не обязательно постоянно держать контекст в памяти. И важно отметить, что ресурсы облака достаточно дешевы, и их можно наращивать почти бесконечно, чего не скажешь о ресурсах устройства.
Еще одним интересным эффектом является то, что запущенному ЦДУ можно обеспечить максимальный уровень защиты, особенно если ему не надо ходить за секретами во внешние источники, а область памяти надежно шифруется (см. следующую статью об AMD SEV - coming soon).
Что ЦДУ дают уже сегодня:
Интероперабельность: владелец устройства может легко его переносить от одной платформы к другой, что снимает замкнутость экосистем отдельных вендоров (Vendor-lock);
Бинарный протокол (быстрый, простой, с малым оверхэдом) до устройства и обогащенные данные (структурированные, откорректированные, нормализованные) для платформы;
Вовлечение в интеграцию с платформами разработчиков устройств (через разработку ЦДУ), что даст мощное ускорение этого процесса;
Полное соответствие микросервисной архитектуре;
Гранулированная безопасность: проблемы с одним устройством не повлияют на работу остальных;
Моментальная инвентаризация устройств.
Что ЦДУ готовы дать в перспективе:
● Edge computing. Если сделать ЦДУ подвижными по инфраструктуре, это позволит им исполняться наиболее близко к своему устройству, что имеет плюсов: низкая задержка, отсутствие транзитного трафика и, самое важное, способность исполняться на граничных узлах – роутерах, базовых станциях и даже смартфонах. Это важно как с точки зрения автономной работы (при разрыве связи с облаком), так и с точки зрения конфиденциальности (не все заказчики могут передавать свои первичные данные в чужое облако). В качестве примера можно привести проект KubeEdge[viii], который позволяет контейнерам двигаться по инфраструктуре (похоже на VMware vMotion).
Более того, такая гибкость позволяет реализовывать новые сценарии, когда роль Edge назначается динамически устройству.
Пример 1: самоорганизация группы морских буев. Дрейфующие морские метеорологические буи могут назначить из своего состава буй, который будет выполнять роль шлюза для всех остальных, выбрав в качестве критерия заряд батареи. Затем эта роль может быть переназначена другому бую.
Пример 2: управление умным домом на смартфоне. В случае аварийного отключения электричества активными остаются устройство, имеющие автономное питание. Такими являются смартфоны и часть устройств умного дома. В этом случае ЦДУ могут исполняться прямо на смартфоне, сохранить связь с устройствами и обеспечить минимальные функции умного дома.
● "Тяжелые" задачи, ИИ. Нагружать ЦДУ ресурсоемкими задачами: прогнозированием, принятием решений с нечеткой логикой и т.п. При этом само физическое устройство остается неизменным, его не надо заменять и даже не нужно обновлять прошивку.
Пример: IoT на блокчейне. Существуют решения, где устройства взаимодействуют друг с другом и с людьми посредством технологии блончейна, могут заключать смарт-контракты, как самостоятельные акторы (как на платформе Vodafone Economy of Things). Тогда блокчейн-клиент будет исполняться на ЦДУ, не нагружая само устройство.
● Составные ЦДУ. ЦДУ могут собираться в цифровые двойники изделий.
Пример 1: подключенный автомобиль. Если каждый электронный компонент имеет ЦДУ, будет несложно создать цифровой двойник всего автомобиля.
Пример 2: умное сельское хозяйство. ЦДУ могут быть не только у устройств, но и у сервисов, в частности, сервис прогноза погоды. Теперь представим, что мы сделали составной ЦДУ из ЦДУ датчика температуры и влажности и ЦДУ прогноза погоды, которое принимает решение о поливе. Учет прогноза погоды позволит более точно поддерживать целевые показатели влажности при экономии воды. Такое решение будет принято на составном ЦДУ, который может работать прямо на базовой станции LPWAN, обслуживающей данное поле.
● Стандарты. Стандартизация подсистемы ЦДУ в 3GPP позволит сделать ее общим компонентом 5G или 6G и снизить почти до нуля время go-to-market для производителей устройств и платформ. Сделать это можно, стандартизировав внутреннюю архитектуру SCEF, описав среду исполнения и API ЦДУ наверх к серверам приложений. Это позволит MNO/MVNO запустить VAS, а производителям устройств и платформ снять барьеры интеграции. Такой подход полностью укладывается в концепцию Open RAN.
Заключение
Мы увидели в этой статье, что применение подхода ЦДУ позволяет уже сейчас решить насущные задачи IoT, а также обеспечить гибкое адаптивное развитие в перспективе нескольких лет. Одновременно он лежит в русле современных технологических трендов и не требует переработки значительной части инфраструктуры мобильных операторов, облачных сервисов или других провайдеров IoT-сервисов.
Олег Гурин, BDM
Кирилл Лебедев, CEO
Основатели SIBlink
[ii] https://en.wikipedia.org/wiki/Edge_computing
[iii] https://www.openapis.org/
[iv] https://www.gsma.com/iot/wp-content/uploads/2019/07/201906-GSMA-NB-IoT-Deployment-Guide-v3.pdf
[v] https://docs.aws.amazon.com/iot/latest/developerguide/iot-device-shadows.html
[vi] https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-device-twins