Резкое повышение возможностей процессоров, повсеместное применение облачных вычислений, активный рост объемов доступных данных и развитие аналитики породили лавину технологий цифровизации. Средства машинного обучения и искусственного интеллекта стали применяться повсеместно, в том числе в устройствах с ограниченными возможностями, например в мобильных телефонах. Эти изменения способствуют наступлению эпохи «программируемого мира», когда повседневные вещи оснащаются интерфейсами связи и возможностями выполнения ПО.

Интернет вещей — двигатель перехода к программируемому миру. Типичная архитектура системы Интернета вещей состоит из ряда компонентов, в том числе датчиков и приводов на периметре сети; шлюзов, соединяющих их с Интернетом; облачных сервисов, предоставляющих хранилище большой емкости; пользовательских приложений для доступа к данным, датчикам и приводам; масштабируемых систем аналитики, развернутых в облаке.

Рис. 1. Типичная архитектура комплексной системы Интернета вещей

Типичная общая архитектура системы Интернета вещей представлена на рис. 1. Сегодня при разработке таких систем используются разнообразные технологии, применяемые для реализации множества компонентов (рис. 2). Соответственно, различаются методы разработки и развертывания, что приводит к дополнительным затратам на интеграцию.

Рис. 2. Платформы Интернета вещей

Чтобы упростить задачу разработчиков, имеющих дело с сильно фрагментированными архитектурами Интернета вещей, нужен объединяющий программный слой, который позволит уменьшить сложность реализации. Концепция изоморфных систем опирается на идею динамичных программных архитектур, которые можно использовать на многих устройствах.

Изоморфное ПО

Слово «изоморфный» греческого происхождения, означает «имеющий одинаковую форму». Понятие изоморфизма многим знакомо из математики, но в контексте программного обеспечения его начали применять относительно недавно. К примеру, по отношению к веб-приложениям изоморфизм означает возможность выполнять один и тот же код как на серверной стороне — в облаке, так и на клиентской — в браузере. В более широком смысле изоморфные программные архитектуры состоят из элементов, которые не нужно менять для выполнения поверх разных аппаратных и программных компонентов. Примеры программного изоморфизма перечислены в таблице.

Изоморфные архитектуры Интернета вещей

Писать ПО для изоморфных архитектур гораздо проще в принципе, поскольку один и тот же код сможет работать на чем угодно. Поскольку работа с технологиями нижнего уровня происходит одинаково, программистам не нужно осваивать различные методики разработки — соответственно, уровень сложности существенно меньше.

Можно выделить несколько уровней изоморфизма. Первый — статический изоморфизм, использование одних и тех же технологий разработки для всех элементов системы. Следующий уровень — динамический изоморфизм: используется единый движок периода выполнения программы или механизм виртуализации, позволяющий без перекомпиляции выполнять на различных платформах один и тот же код. Высший уровень изоморфизма — система, в которой код можно динамически перемещать между разными исполняющими компонентами.

Что касается приложений Интернета вещей, то в идеале должна быть возможность одно и то же изоморфное ПО развертывать на любых компонентах системы, чтобы оно могло выполняться на периферийных устройствах, шлюзах, мобильных клиентах и в облачных сервисах. Однако существующие системы Интернета вещей далеки от этого. Разработчики приложений должны учитывать контекст развертывания кода, знать множество языков программирования, виртуальных сред выполнения и коммуникационных протоколов (рис. 2). Из-за многообразия платформ невозможно, к примеру, развернуть работающие на периферии компоненты в облаке, не переписав их заново.

Изоморфные архитектуры не только облегчат, ускорят и, возможно, удешевят разработку приложений и систем Интернета вещей, но и откроют возможности для появления новых видов динамических приложений, использующих развертывание в разных средах и миграцию между периферией и облаком.

Трудности разработки

Сегодня большинство программистов обучаются в основном мобильной и веб-разработке. Считается, что те же навыки можно применить и при реализации систем Интернета вещей, однако у них есть множество своих особенностей, отличных от мобильных и веб-приложений. Разработчикам нужно учитывать ряд факторов, с которыми не сталкиваются большинство их коллег по обычным приложениям: необходимо писать код для множества устройств, отличающихся платформами и т. д.; нужно принимать в расчет непостоянство и неустойчивость связи; система является распределенной и работающей в постоянном режиме; ПО должно характеризоваться высокой отказоустойчивостью.

Кроме того, приложения Интернета вещей обычно работают непрерывно и являются реактивными: в зависимости от показаний датчиков запускаются различные вычисления и могут выполняться альтернативные действия. Такие системы обычно являются асинхронными, параллельными и распределенными. Все эти особенности сильно отличают системы Интернета вещей от ПО для ПК, мобильных устройств и веб-приложений, которые обычно разрабатываются для одной клиентской платформы, нередко взаимодействующей лишь с одним сервером.

Фактически Интернет вещей восстанавливает потребность в навыках разработки встроенного ПО и в соответствующем образовании. Создание ПО для устройств Интернета вещей очень похоже на традиционную разработку встроенных систем, поскольку в обоих случаях требуется умение работать с малой емкостью памяти и скудным электропитанием. Потребность в соответствующем образовании особенно насущна, поскольку за последние 10–15 лет во многих университетах стало меньше курсов по встроенным системам и теории управления, так как веб- и мобильная разработка считаются более современными и востребованными.

В другой части спектра комплексных систем Интернета вещей — облачные компоненты, которые опираются на несколько уровней виртуализации. В частности, в современных архитектурах ПО на основе микросервисов последние чаще всего преобразуются в контейнеры Docker, а те, как правило, работают в кластере Kubernetes. Компоненты более низкого уровня обычно написаны на Python или JavaScript/Node.js, а для работы кода на них нужна виртуальная машина с соответствующей средой выполнения. Чаще всего при этом используются виртуальные машины, арендованные у операторов общедоступных облаков: Amazon, Microsoft и др.

В связи с контейнеризацией и использованием Kubernetes современные облачные программные системы, даже самые простые, в большинстве случаев работают поверх минимум четырех слоев виртуализации. Увеличение их числа не дает преимуществ, повышает непроизводительные издержки при разработке, замедляет выполнение приложений и усложняет отладку. Тем не менее виртуализованные программные среды активно начинают применять и на периферийных системах Интернета вещей, в том числе в шлюзах.

Слои виртуализации усложняют практически все этапы разработки. Приходится применять массу вспомогательного ПО, которое предположительно помогает справляться со сложностями, но в реальности нередко отвлекает разработчика от качественной реализации основной функциональности. И несмотря на широкое использование виртуализации, системы Интернета вещей характеризуются негибкой, фрагментированной архитектурой, в которой задачи нельзя легко переносить из одной среды выполнения в другую.

Пример из промышленной сферы

Проиллюстрируем разнообразие элементов систем Интернета вещей на примере промышленной контрольно-измерительной системы, состоящей из большого числа специализированных устройств для решения различных задач: приборы для контроля качества воздуха (температуры, влажности, давления и загрязнения), детекторы движения (на основе инерциальных датчиков и средств определения местонахождения внутри помещений) и системы измерения уровня шума и освещенности (в том числе детектор интенсивности инфракрасного света). Приборы соединены с сетью либо по W-Fi и с помощью других беспроводных технологий малого радиуса действия, либо с применением экономичных технологий для глобальных сетей, например NB-IoT или LTE-M. Загрузка данных и приведение в действие выполняются с использованием протокола MQTT.

Периодичность измерений и загрузки данных в системе не слишком высока — примерно раз в несколько минут. Это упрощает реализацию облачной части, поскольку нет потребности в обработке непрерывных потоков данных и в минимизации задержки. Общая схема системы изображена на рис. 3.

Рис. 3. Общая схема контрольно-измерительной системы, включая вспомогательные приложения

Измерительные приборы реализованы на базе доступного в продаже оборудования, для устройств с Wi-Fi используется платформа ESP32, для устройств NB-IoT/LTE-M — Nordic Semiconductor nRF91. Для обеих платформ ПО разрабатывается на Си, но интерфейсы программирования, библиотеки и инструменты сильно различаются, так как все они работают под управлением собственной ОС реального времени.

Поскольку данные передаются по Wi-Fi или сети сотовой связи, для системы не нужны специализированные шлюзы со стеками преобразования протоколов. Для настройки приборов на Java разработано приложение на Android, использующее библиотеки этой ОС.

Значительные усилия потребовались для облачной части, логические элементы которой изображены на рис. 3. Большинство из них реализовали на базе компонентов с открытым кодом.

Для периметра безопасности и обратного прокси использовался веб-сервер NGINX, для сбора данных (показаний приборов) — Apache Kafka и RabbitMQ, для ведения журналов и мониторинга системы — Grafana, Graphite и Icinga. Аналитика данных вначале была реализована с помощью Apache Storm, но впоследствии этот компонент заменили на Apache Spark. Специализированные микросервисы реализовали на Node.js.

Весь бэкенд работает в контейнерах Docker; для каждого микросервиса используется отдельный контейнер. Вначале для развертывания системы применялись Ansible и OpenStack, но впоследствии ее целиком перенесли на кластер Kubernetes.

Помимо ПО устройств и облачной части, был разработан ряд веб- и мобильных приложений для визуализации данных, администрирования и мониторинга системы. Веб-приложения реализовали на базе фреймворка Angular.js, а мобильные — на Java в Android Studio.

Как можно видеть, разработка всей системы потребовала широкой палитры технологий, в том числе встроенных, мобильных, веб-приложений, а также использования целого ряда популярных компонентов для реализации облачной части. С учетом разнообразия технологий, один разработчик или небольшой стартап вряд ли смог бы освоить все из них, чтобы целиком реализовать такую систему. Кроме того, каждый из ее программных компонентов тесно привязан к конкретной платформе выполнения.

Катализаторы перемен

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

Традиционно вычислительные мощности, память и хранилище периферийных устройств были ограниченными. Но, ввиду роста вычислительных возможностей таких устройств и потребности в уменьшении сетевой задержки, интеллектуальные задачи постепенно переносятся на периферию — вначале на шлюзы, затем на конечные устройства. В числе таких задач — как стандартные программные функции, так и, что более важно, критичные ко времени механизмы ИИ и машинного обучения. Необходимость выполнения алгоритмов ИИ и аналитики на периферии делает еще более актуальной потребность в едином наборе технологий программирования для комплексных систем.

В системах Интернета вещей, состоящих из огромного количества устройств, топологии их взаимного соединения будут сильно динамичными, а это значит, что нужны технологии для работы с обширными группами устройств, постоянно меняющих не только свое расположение, но и функции. Растущий динамизм относится и к возможностям искусственного интеллекта. Например, при обучении с подкреплением могут возникать непредвиденные ситуации: функция, работавшая вчера, сегодня может быть недоступна. Кроме того, нужна возможность переноса соответствующих программных компонентов в среду, наиболее подходящую для их выполнения в конкретный момент.

Чтобы разработка, развертывание и долгосрочная эксплуатация стали проще, системы Интернета вещей будущего должны поддерживать механизмы гибкого распределения и изменения ролей устройств. Соответственно, необходима платформа, в рамках которой различные вычислительные ресурсы могли бы выполнять один и тот же код.

Развитие изоморфных систем Интернета вещей

В связи с растущей сложностью, динамизмом и разнообразием нынешнего ПО для систем Интернета вещей, их нынешнее развитие идет по опасному пути. Жесткие системные архитектуры, широкий спектр технологий, бездумное заимствование методов реализации у других применений, неразумное использование виртуализации, трудности управления пакетами и эксплуатации — все это ведет к увеличению сложности контроля систем Интернета вещей.

Пришло время изменить ситуацию.

Необходимы технологии, освобождающие от жесткого распределения задач и поддерживающие использование единого набора методов реализации. Нужна поддержка динамического развертывания компонентов, причем с учетом потребностей приложения в производительности и надежности, а не в связи с ограничениями, которые налагаются господствующими на рынке платформами и средствами разработки. Кроме того, определенные функции, особенно механизмы искусственного интеллекта и машинного обучения, могут потребовать возможности гибкого переноса кода и моделей между облаком и периферией в зависимости от доступности данных и требуемого времени отклика.

Перечисленные потребности в конечном счете приведут к созданию изоморфных архитектур систем Интернета вещей, в чем-то похожих на изоморфные веб-приложения, главная особенность которых — возможность использовать одни и те же технологии разработки и код как для серверной, так и для клиентской части. Соответствующая концепция зародилась именно в связи с фрагментированным технологическим ландшафтом, в котором для браузера и сервера использовались совершенно разные средства разработки.

Многие веб-разработчики еще помнят эпоху, когда серверную функциональность писали на PHP или Perl, а клиентскую — на других языках. Но когда JavaScript начали использовать на серверах, постепенно появилась возможность выполнять один и тот же код на обеих сторонах при условии, что использовались совместимые библиотеки и соблюдались ограничения, налагаемые в связи с требованиями изолированной среды.

В изоморфной системе Интернета вещей устройства, шлюзы, пользовательские приложения и облачные сервисы написаны с помощью одних и тех же технологий и в идеале могут применять одни и те же программные компоненты, что дает возможность гибкой миграции кода. Для реализации не нужно осваивать многочисленные несовместимые друг с другом платформы разработки — в изоморфной архитектуре достаточно одной базовой технологии, которая охватит все этапы разработки, а одними и теми же инструментами можно пользоваться при создании ПО для всех вычислительных ресурсов в системе (рис. 4).

Рис. 4. Традиционная и изоморфная архитектура Интернета вещей

Основные технические элементы, которые нужны для реализации таких систем, — единый API для доступа к функциям различных подсистем и универсальная среда выполнения. Она должна быть быстрой, достаточно компактной для встроенных применений, но в то же время мощной для обеспечения работы легких контейнеров — чтобы можно было переносить действующие в них приложения. Кроме того, понадобится система оркестровки, которая предоставит механизмы развертывания и миграции разных подсистем.

Единый API наиболее важен для Интернета вещей: он должен будет предоставлять функции обнаружения устройств, получения данных, доступа к ним, приведения устройств в действие, управления ими, обновления кода, отладки и т. д. При этом он должен быть доступным для устройств любого назначения и производителя, а также поддерживать все необходимые механизмы безопасности. Вопрос о том, появится ли такой универсальный API, представляется спорным, но можно рассчитывать на то, что через 5–10 лет произойдет значительная конвергенция интерфейсов программирования различных устройств. Кроме того, к тому времени на базе существующих IP-сетей и экосистемы веб-приложений, скорее всего, будет построена необходимая инфраструктура.

Изоморфные системы Интернета вещей на основе веб-технологий

Поиск конкретных технологий, с помощью которых можно было бы реализовать изоморфизм, приводит к стандартам WWW с учетом того, что они во многих отношениях уже сыграли объединяющую роль. Что касается универсального API, то наиболее перспективный кандидат сегодня — «Паутина вещей» (Web of Things, WoT), набор стандартов, призванный обеспечить интероперабельность различных платформ Интернета вещей, предназначенных для разных задач. WoT делает каждую «вещь» в Интернете вещей частью WWW, назначая ей URI-идентификатор, который можно использовать для связи с ней. Для поддержки связи предусмотрены единая модель данных и универсальный API, распознаваемый любыми «вещами».

В качестве фундамента среды выполнения для Интернета вещей можно рассмотреть два варианта: JavaScript/ECMAScript [3] и WebAssembly (WASM). Первый стал фактическим стандартом языка для браузеров и облачной части (Node.js) и сейчас представляется главным кандидатом на реализацию статического изоморфизма, то есть языка, на котором можно писать ПО для всех компонентов системы. WASM — язык низкого уровня, выполняемый на стековой виртуальной машине, который может пользоваться возможностями современного аппаратного обеспечения [2]. Он представляется оптимальным вариантом для поддержки динамического изоморфизма, то есть возможности использовать единую среду выполнения, отличающуюся достаточной мощностью и компактностью для выполнения на устройствах Интернета вещей с ограниченными возможностями (рис. 5). Оба варианта не исключают друг друга, то есть можно реализовать архитектуру, в которой WASM используется как единая среда выполнения, а JavaScript — в качестве языка программирования для всей системы.

Рис. 5. Использование веб-технологий для реализации статичного (а) и динамичного (б) изоморфизма

У обоих вариантов есть свои плюсы и минусы для изоморфных приложений Интернета вещей. Для JavaScript существует колоссальный набор библиотек (более миллиона NPM-модулей) и имеются высокопроизводительные виртуальные машины, плюс с этим языком знакомы большое количество разработчиков. Но поскольку это динамический язык, возможно, для изоморфных приложений в нем понадобится поддержка их упаковки в контейнеры.

Программы на WASM оформлены в виде модулей, каждый из которых имеет свой набор значений и определений типов. С отдельным модулем можно выполнять операции компиляции, загрузки и развертывания. С учетом этого WASM-приложения представляются естественными кандидатами для формирования легких контейнеров. Писать такие приложения можно на различных языках, но компилируются они в текстовый или двоичный код WASM. На сегодня, правда, эта технология еще недостаточно развита для применения вне браузеров. И JavaScript, и WASM можно использовать для реализации модели, в рамках которой новые приложения инициализируются там, где они требуются, и которая также поддерживает динамически переносимые приложения.

В конечном счете определение единой изоморфной платформы Интернета вещей будет зависеть от стандартизации. Исследователи смогут сделать свой вклад в развитие такой платформы, но необходимо и взаимодействие крупнейших участников отрасли, чтобы можно было прийти к согласию по поводу общих принципов и методов. Кроме того, крупные компании, которым удалось построить успешный бизнес на решениях для Интернета вещей, безусловно, смогут установить фактические стандарты в новой области.

Важно отметить, что не все программное обеспечение должно быть изоморфным. Недорогие устройства Интернета вещей, например датчики температуры или качества воздуха, нередко реализованы вообще без операционной системы. Аппаратные возможности развиваются стремительно (еще 15 лет назад никому бы и в голову не пришло, что микроконтроллеры будут основаны на 32-разрядных архитектурах и иметь мегабайты памяти), но вряд ли на подобных устройствах в ближайшие годы появится поддержка контейнеров или сложных механизмов виртуализации. Аналогично, средства визуализации и облачные компоненты для мониторинга общего состояния системы обычно не требуют возможности переноса на периферийные устройства. Со временем, благодаря прогрессу в области оборудования, виртуализацию можно будет обеспечить практически на всех видах устройств, но в конечном счете выбор между изоморфными и другими технологиями будет определяться конкретными задачами — вряд ли имеет смысл пытаться создавать универсальный код для всего подряд.

***

В разработке программных систем простые вещи должны быть простыми, а сложные — возможными, однако похоже, что простота в современной разработке утрачена. Нынешние системы характеризуются избыточным использованием виртуализации, сторонних программных компонентов, в том числе из неизвестных источников, и обилием частично пересекающихся технологий реализации, применяемых для разных компонентов комплексных систем.

Что касается создания систем Интернета вещей, то сейчас практически нет согласованности между многочисленными методами разработки и развертывания. А появление крупных конфигураций создает новые проблемы, особенно если стоит задача обеспечить единство управления миллионами устройств. На данный момент мы очень далеки от воплощения в жизнь концепции программируемого мира, в котором все предметы вокруг нас будут действовать как один. В этой связи крайне важно прекратить практику программирования, установки и эксплуатации крупномасштабных систем Интернета вещей с использованием всей мешанины применяемых сегодня технологий.

Интернету вещей нужны изоморфные программные архитектуры, подсистемы которых можно программировать с помощью одного и того же набора технологий, что позволило бы статично или динамично распределять приложения, обеспечивать их оркестровку и гибко перемещать между компонентами. Полностью изоморфные системы появятся не завтра, но со временем они могут размыть границы между облаком и периферией благодаря возможности динамического переноса задач на ресурсы, обеспечивающие оптимальное сочетание производительности, емкости, пропускной способности, времени отклика и энергоэффективности. В числе самых перспективных кандидатов для реализации изоморфизма — технология WoT для интерфейсов программирования и языки JavaScript либо WASM для реализации гибко развертываемой, переносимой логики приложений.

Литература

1. K. Arnold, J. Gosling, D. Holmes. Java Programming Language, 4th ed. Reading, MA: Addison-Wesley, 2005. ISBN:978-0-321-34980-4. doi: https://dl.acm.org/doi/book/10.5555/1051069.

2. D. Bryant. WebAssembly outside the browser: A new foundation for pervasive computing. In Proc. Keynote at ICWE'20, Helsinki, Finland, June 9–12, 2020.

3. ECMAScript 2020 Language Specification, Standard ECMA-262, June 2020. URL: https://www.ecma-international.org/publications/standards/Ecma-262.htm (дата обращения: 05.03.2021).

Томми Микконен (tommi.mikkonen@helsinki.fi)  —  профессор, Хельсинкский университет; Чезаре Паутассо (c.pautasso@ieee.org)  —  старший научный сотрудник IEEE; Антеро Тайвалсаари (antero.taivalsaari@nokia-bell-labs.com)  —  научный сотрудник Nokia Bell Labs.

Tommi Mikkonen, Cesare Pautasso, Antero Taivalsaari, Isomorphic Internet of Things Architectures With Web Technologies, IEEE Computer, July 2021, IEEE Computer Society. All rights reserved. Reprinted with permission.