INTERNET OF THINGS: OVERVIEW OF REFERENCE ARCHITECTURAL MODELS
- Authors: Roslyakov A.V1, Kiryakov A.A2
-
Affiliations:
- Povolzhskiy State University of Telecommunications and Informatics
- Gazprom Transgaz Samara Limited Liability Company
- Issue: Vol 19, No 4 (2021)
- Pages: 382-395
- Section: Articles
- URL: https://journals.eco-vector.com/2073-3909/article/view/112232
- DOI: https://doi.org/10.18469/ikt.2021.19.4.01
- ID: 112232
Cite item
Full Text
Abstract
For the Internet of Things to function, the it must connect billions or trillions of different objects over the Internet and other networks using different protocols and technologies. Thus, there is a critical need for a universal, flexible and multi-layered architecture. Currently, there is no single architectural reference model. Its creation is not an easy task despite many standardization efforts. The main challenge in creating an architectural reference model is the natural fragmentation of possible applications for IoT technologies. Each of the applications depends on many variables and requirements for the design characteristics and the wishes of the customer, and they often differ dramatically. In addition, there is another problem connected with the tendency of each supplier or manufacturer to offer their platform and solutions for similar applications of IoT technology. This article analyzes several approaches to creating reference architecture models that may prove useful in the ongoing standardization process for IoT technologies.
Full Text
Введение Одна из основных проблем, связанная с техно- логическим аспектом развертывания систем Ин- тернета вещей IoT (Internet of Things) [1], заклю- чается в определении эталонной архитектурной модели, поддерживающей текущие функции и будущие расширения. Такая архитектура должна обеспечивать [2]: масштабируемость - возможность управ- лять растущим количеством устройств и служб без ухудшения их работы; совместимость - устройства от разных про- изводителей могли взаимодействовать; распределенность - создание среды, в кото- рой данные собираются из разных источников и обрабатываются разными объектами; возможность работать с ограниченными ресурсами, поскольку интернет-вещи обычно имеют небольшую вычислительную мощность и объемы памяти; безопасность, предотвращение несанкцио- нированного доступа. В ближайшее время разнородные решения, скорее всего, будут обгонять в своем развитии развертывание IoT-решений, основанных на функционально совместимых стандартах [3-5]. Этот этап проходят все новые технологические решения. Две основные характеристики IoT- устройств, которые необходимо учитывать: это устройства с низкой мощностью и, соответствен- но, низким энергопотреблением (расчетное время работы месяцы и годы без подзарядки) и частый обмен небольшими блоками данных по сетям связи с потерей пакетов. Существующие стан- дартные протоколы сети Интернет являются не- оптимальными для решения этой задачи [7]. Если взглянуть более широко, то становится очевидным некоторый дисбаланс, который воз- никает из-за наличия огромного количества IoT- устройств, располагающихся в разных местах и генерирующих поток данных с большой скоро- стью, и применения облачных технологий, хра- нящих огромные массивы данных в небольшом количестве хранилищ. При этом скорость обнов- ления данных остается относительно невысокой. Для совместного использования и функциони- рования этих двух базовых подсистем Интерне- та вещей требуются определенные возможности от задействованных сетевых протоколов на всех уровнях архитектуры IoT. В области решения этих вопросов работают несколько международных организаций, ставя своей целью адаптировать и расширить прото- колы сети Интернет для поддержки функцио- нирования устройств IoT. В то время как суще- ствующие стандарты Интернета сделали IoT возможным, в ближайшем будущем вряд ли по- явится стек новых сетевых протоколов, которые дополнят или модифицируют существующие для сферы IoT. Как и множество других протоколов и технологий сети Интернет до этого, Интернет ве- щей будет какое-то время стихийно развиваться и совершенствоваться, постепенно выявляя жизне- способные технологии и протоколы [7]. Рисунок 1. Трехуровневая и пятиуровневая модели IoT В настоящее время известен ряд архитектур- ных моделей IoT различных международных организаций, которые во многом совпадают, но имеют и свои отличия. В статье проведен сравни- тельный анализ данных моделей. Трехуровневая модель IoT Самая простая - трехуровневая архитекту- ра, состоящая из уровней восприятия, сетевого уровня и уровня приложений (рисунок 1, а), была предложена на заре развития технологий IoT [8]. Уровень восприятия - физический уровень, на котором функционируют объекты (датчики) для обнаружения и сбора информации. Они из- меряют некоторые физические параметры окру- жающей среды или идентифицируют другие ин- теллектуальные объекты (смарт-объекты). Эти смарт-объекты, являющиеся фундаментальными блоками, на которых основан Интернет вещей, могут быть предметами повседневного обихода (холодильник, телевизор, автомобиль и т. д.) или простыми приборами, оснащенными датчиками и вычислительными возможностями, например на основе микроконтроллеров или микрокомпью- теров типа RaspberryPi, Arduino, BeagleboneBlack и т. п. Сетевой уровень выполняет задачу транспор- тировки данных, предоставляемых уровнем вос- приятия до прикладного уровня. Он включает в себя все технологии и протоколы, которые дела- ют это подключение возможным, и его не следу- ет путать с сетевым уровнем ISO/OSI, который маршрутизирует данные в сети. Наиболее часто используемые протоколы IoT, относящиеся к сетевому уровню данной модели, показаны в таблице 1 (сгруппированы по уров- ням модели ISO/OSI) [9]. Таблица 1. Основные протоколы, используемые в IoT Уровень приложений CoAP, MQTT, AMQP, XMPP, DSS Обнаружение услуг: mDMS, DNS-SD, SSDP Безопасность: TLS, DTLS Транспортный уровень TCP, UDP Сетевой уровень Адресация: IPv4/IPv6 Маршрутизация: RPL, CORPL, CARP Уровень адаптации 6LoWPAN, 6TiSCH, 6Lo Канальный уровень IEEE 802.15.4 (ZigBee) IEEE 802.11 (WiFi) IEEE 802.15.1 (Bluetooth) IEEE 802.3 (Ethernet) LPWAN (LoRaWAN) IEEE 1901 (PLC) RFID, NFC Z-Wave Физический уровень На канальном уровне особенно важны беспро- водные протоколы. Беспроводные датчики могут быть установлены в труднодоступных местах и требуют меньших материальных и человеческих ресурсов для их установки. Кроме того, в бес- проводной сети различные узлы могут быть лег- ко добавлены или удалены, а их расположение может быть изменено без пересмотра структуры всей сети. Однако в других приложениях может потре- боваться создание проводной сети, которая обла- дает более высокой надежностью и более высо- кими скоростями передачи. В качестве примера можно привести внутреннюю сеть автомобиля, которая соединяет различные электронные блоки управления, управляющие механическими ча- стями автомобиля (рулевое управление, тормоз и т. д.). В этом случае очень важно иметь надеж- ную и быструю сеть, потому что задержки или неисправности могут иметь серьезные послед- ствия для людей, находящихся в автомобиле. Уровень приложений включает в себя все про- граммное обеспечение, необходимое для предо- ставления конкретной услуги. На этом уровне данные, полученные с нижних уровней, хранят- ся, агрегируются, фильтруются и обрабатыва- ются, используются базы данных, программное обеспечение для анализа и т. д. В результате этого процесса обработки данные становятся до- ступными для реальных приложений Интернета вещей («умные» носимые устройства, «умные» автомобили и т. д.). Трехуровневая архитектура определяет основ- ную идею Интернета вещей, но этого недостаточно, потому что многие приложения часто фокуси- руются на более тонких аспектах. Пятиуровневая модель IoT Другой важной и очень распространенной мо- делью IoT является пятиуровневая архитектура (см. рисунок 1, б) [10], которая включает уровень восприятия, сетевой уровень, уровень промежу- точного программного обеспечения (ППО) (об- работки), уровень приложений и бизнес-уровень. Архитектура для IoT должна учитывать многие факторы, такие как масштабируемость, совмести- мость, надежность, QoS и др. В этом отношении архитектура Интернета вещей на основе ППО по- могает создавать приложения более эффективно; этот уровень действует как связь между приложе- ниями, данными и пользователями. Роль уровней восприятия и прикладного такая же, как и в трехуровневой архитектуре. Отметим функции остальных трех уровней. Уровень ППО имеет такие важные функции, как агрегирование и фильтрация полученных данных от аппаратных устройств. В общем слу- чае этот уровень обеспечивает абстракцию меж- ду технологиями IoT и приложениями. В ППО детали различных технологий скрыты, а стан- дартные интерфейсы позволяют разработчикам сосредоточиться на разработке приложений, не учитывая совместимость между приложениями и инфраструктурами. ППО получило большое значение в последние годы из-за его важной роли в упрощении разработки новых услуг и интегра- ции устаревших технологий в новые. Выделим главные преимущества использова- ния ППО: поддержка различных приложений; работа на различных операционных систе- мах и платформах; распределенные вычисления и взаимо- действие сервисов среди разнородных сетей, устройств и приложений; поддержка стандартных протоколов; предоставление стандартных интерфейсов с обеспечением переносимости и взаимодействия; важная роль в стандартизации; обеспечение стабильного высокоуровнево- го интерфейса для приложений. Вот некоторые программные технологии, ши- роко используемые в настоящее время для управ- ления огромным объемом данных, формируемых устройствами IoT: облачные вычисления, где предоставляются такие услуги, как хранение или обработка данных на базе ресурсов дата-центров, настраиваемых и доступных удаленно в форме распределенной вычислительной архитектуры; туманные вычисления, при которых обра- ботка данных частично распределяется на пери- ферийные узлы сети для увеличения производи- тельности систем IoT. Транспортный уровень передает данные дат- чиков от слоя восприятия к слою обработки и в обратную сторону через такие сети и техноло- гии, как сотовые сети 3G/4G/5G, LAN, Bluetooth, RFID, NFC и др. Бизнес-уровень управляет всей системой IoT, включая приложения, бизнес-модели, модели прибыли и конфиденциальность пользователей. Эталонная модель МСЭ-Т Эталонная модель IoT от Международного со- юза электросвязи (МСЭ-Т) представлена в Реко- мендации Y.2060 [1; 11]. В отличие от большин- ства других эталонных моделей, модель МСЭ-Т детализирует фактические физические компо- ненты экосистемы IoT, которые должны быть со- единены, интегрированы, управляемы и предо- ставлены приложениям. Важный аспект этой модели заключается в том, что IoT на практике не является сетью фи- зических вещей. Более подходящее описание IoT - сеть устройств, взаимодействующих с фи- зическими вещами, и прикладные платформы - компьютеры, планшеты и смартфоны, взаимо- действующие с этими устройствами. Эталонная модель IoT, согласно Рекоменда- ции МСЭ-Т Y.2060, включает следующие элемен- ты (рисунок 2): Вещь (Thing) - предмет реального физическо- го (физическая вещь) или информационного (вир- туальная вещь) мира, который может быть выде- лен, идентифицирован и подключен к сети связи. Устройство (Device) - элемент оборудования, который обладает обязательными возможностя- ми коммуникаций и дополнительными возмож- ностями измерения физических величин, вы- полнения определенных физических действий, а также ввода, хранения и обработки информации. Устройство переноса данных (Data-carrying Device) - подключается к физической вещи и не- прямым образом соединяет эту физическую вещь с сетями связи. Примерами могут служить активные метки RFID. Устройство сбора данных (Data-capturing Device) - считывающее и/или записывающее устройство, взаимодействующее с физически- ми вещами. Взаимодействие может быть непря- мым - с помощью устройств переноса данных, Рисунок 2. Типы устройств и их взаимосвязь с физическими вещами [11] или прямым - с использованием носителя дан- ных, подключенного непосредственно к физиче- ской вещи. Носитель данных (Data Carrier) - объект пе- реноса данных, не оснащенный элементами пи- тания, подключаемый к физической вещи и пре- доставляющий информацию в пригодном виде устройству сбора данных. Этот элемент модели включает в себя штрих-коды и QR-коды, нане- сенные на физические вещи. Сенсорное устройство (Sensing Device) -класс устройств, измеряющих параметры окружающей среды и преобразующих ее в цифровые сигналы, пригодные для передачи. Исполнительное устройство, актуатор (Actuating Device) - устройство, которое может преобразовывать электрические сигналы, посту- пающие из информационных сетей, в реальные физические действия. Устройство общего назначения (General Device) - устройство, обладающее возможностя- ми обработки данных и возможностями обмена данными с сетями связи с использованием раз- личных технологий. Этот класс устройств вклю- чает в себя различное оборудование и приборы из разных областей применения IoT. Например, станки, смартфоны, различные бытовые электро- приборы. Шлюз (Gateway) - элемент модели IoT, осу- ществляющий функцию соединения устройства с сетями связи. Он выполняет необходимую транс- ляцию между протоколами, используемыми в се- тях связи и в устройствах. В Рекомендации МСЭ-Т Y.2067 [13] опреде- лены требования, предъявляемые к IoT-шлюзам. Эти требования могут быть разделены на три больших категории: устройству шлюза необходимо поддержи- вать множество различных технологий для досту- па к устройствам, тем самым давая устройствам возможность взаимодействовать и обмениваться данными между собой и с сетью; шлюзу необходимо поддерживать сетевые технологии и протоколы локальных и глобаль- ных сетей; шлюз должен взаимодействовать с прило- жениями и поддерживать функции управления сетью и безопасности. Модель IoT от МСЭ-Т включает четыре уров- ня, а также связанные со всеми уровнями возмож- ностей управления и возможностей обеспечения безопасности (рисунок 3). Уровень приложения состоит из различных приложений IoT, взаимодействующих с устрой- ствами. Уровень поддержки услуг и приложений пре- доставляет возможности, которые необходимы приложениям. Различные приложения могут ис- пользовать общие возможности поддержки, на- пример общую обработку данных и управление базой данных. Специализированные возможно- сти поддержки - это конкретные возможности, которые необходимы именно данному конкрет- ному подмножеству приложений IoT. Уровень сети включает: возможности организации сетей - предо- ставляет соответствующие функции управления сетевыми соединениями, такие как функции управления доступом и ресурсом транспортиро- вания, управление мобильностью или аутенти- фикация, авторизация и учет AAA; возможности транспортировки - предна- значены для предоставления соединений с целью транспортировки информации в виде данных, от- носящихся к услугам и приложениям IoT, а также транспортировки информации контроля и управ- ления, относящейся к инфраструктуре IoT. Проще говоря, возможности уровня сети со- ответствуют сетевому и транспортному уровням модели ISO/OSI. Рисунок 3. Эталонная модель IoT МСЭ-Т [13] Уровень устройства. Возможности уровня устройства можно логически разделить на два вида возможностей: возможности устройства и возможности шлюза. Возможности устройства включают в себя: прямое взаимодействие с сетью связи: устройства способны собирать и закачивать ин- формацию непосредственно (т. е. без использова- ния возможностей шлюза) в сеть и могут непо- средственно получать информацию (например, команды) из сети; непрямое взаимодействие с сетью связи: устройства способны получать и закачивать ин- формацию в сеть с помощью возможностей шлю- за, на приемной стороне устройства могут полу- чать непрямым образом команды из сети; организацию специальных сетей: в ряде проектов, для которых требуются повышенная масштабируемость и быстрота развертывания, возможно строительство сети устройств произ- вольным образом; спящий режим и пробуждение: для эконо- мии энергии устройства поддерживают механиз- мы ухода в спящий режим и выхода из него. Шлюзы должны поддерживать следующие возможности: поддержку нескольких интерфейсов: шлюз должен поддерживать устройства, соединенные с использованием различных проводных и беспро- водных технологий, таких как Ethernet, Bluetooth, ZigBee или Wi-Fi. На уровне сети шлюз должен уметь обмениваться данными с использованием таких технологий, как сети подвижной связи по- колений 3G/4G/5G, Ethernet, хDSL. преобразование протокола: эта возмож- ность требуется в двух случаях: когда для связи на уровне устройства используются разные про- токолы (к примеру, ZigBee и Bluetooth) и когда разные протоколы применяются для связи между устройством и сетью (например, технология ZigBee на уровне устройства и технологии 5G на уровне сети). Возможности управления охватывают тради- ционные функции управления сетью, т. е. управ- ление устройствами, управление устранением неисправностей, управление конфигурацией и топологией сети, управление учетом, управление показателями работы и управление безопасно- стью, управление трафиком и перегрузками. Специализированные возможности управ- ления определяются требованиями конкретных приложений, например требованиями по контро- лю линии передачи электроэнергии в «умной» электросети SmartGrid. Возможности обеспечения безопасности включают в себя общие возможности и специ- ализированные возможности. Общие возможности не зависят от конкрет- ных приложений. В Рекомендации Y.2060 приве- дены следующие примеры общих возможностей обеспечения безопасности на соответствующих уровнях модели: на уровне приложения - авторизация, ау- тентификация, защита конфиденциальности, за- щита целостности данных приложения, антиви- русная защита; на уровне сети - авторизация, аутентифи- кация, а также защита целостности данных сиг- нализации; на уровне устройства - аутентификация, авторизация, управление доступом, проверка со- стояния и целостности устройства, защита и про- верка целостности данных. Специализированные возможности непосред- ственно связаны с требованиями конкретных приложений, к примеру, это безопасность мо- бильных платежей [8; 11]. Рисунок 4. Схема модели ARM проекта IoT-A [6] Эталонная модель IoT-A Основной задачей Европейского проекта IoT-A (Internet of Things - Architecture) была разработка архитектурной эталонной модели ARM (Architectural Reference Model) для взаи- модействия систем Интернета вещей, выработ- ка принципов и рекомендаций по техническому проектированию его протоколов, интерфейсов и алгоритмов, что позволило бы интегрировать разнородные технологии IoT в единую взаимо- связанную архитектуру. Последняя версия мо- дели IoT-A v3.0 была выпущена в 2013 году [6]. Участниками этого проекта являлись такие круп- нейшие компании, как Siemens AG, NEC Europe Ltd., Hitachi Europe Ltd., SAP AG, IBM Research GmbH и др. Архитектурная эталонная модель IoT состоит из нескольких моделей (рисунок 4). Стрелки на рисунке показывают, как концепции и аспекты одной модели используются в качестве основы для другой. Основой ARM является доменная модель IoT, которая определяет основные концептуальные положения модели IoT, такие как устройства, службы, виртуальные сущности и пользователи, а также устанавливает отношения между этими компонентами. На основе доменной модели была разработана информационная модель IoT, которая определяет структуру информации в системе на концепту- альном уровне без обсуждения того, как она бу- дет представлена. Функциональная модель IoT (рисунок 5) опре- деляет функциональные группы (уровни, слои), которые основаны на ключевых концепциях предметной области IoT. Совокупность соответ- ствующих функциональных групп коммуника- ций и безопасности в функциональной модели образуют коммуникационную модель IoT и модель безопасности IoT соответственно. Функциональная модель ARM имеет некото- рые отличия от эталонной модели МСЭ-Т (см. рисунок 2). Она также является иерархической, но состоит уже из семи горизонтальных уров- ней (функциональных групп), дополненных также двумя вертикальными слоями (управле- ние и безопасность), которые участвуют во всех процессах. Основные абстракции (устройства, службы, виртуальные сущности и пользователи), опреде- ленные в доменной модели IoT, располагаются на уровнях устройств, сервисов IoT, виртуальных сущностей и приложений соответственно. Требования в отношении возможностей созда- ния сервисов и приложений на основе IoT охва- тываются уровнями управления процессами IoT и организации сервисов. Сквозной вертикальный слой управления тре- буется для управления функциональными груп- пами и взаимодействия между ними. Эталонная модель IWF Комитет по архитектуре Всемирного фору- ма Интернета вещей IWF (IoT World Forum), со- ставленный из лидеров индустрии, включая IBM, Рисунок 5. Функциональная модель ARM проекта IoT-A [6] Рисунок 6. Эталонная модель IoT форума IWF [14] Intel и Cisco, в 2014 года опубликовал эталонную модель IoT (рисунок 6) [14]. Эта модель является полезным дополнением к модели МСЭ-Т. Документы МСЭ-Т делают упор на уровнях устройства и шлюза, описывая верх- ние уровни лишь в общих чертах и уделяя наи- большее внимание определению концепции для поддержки разработки стандартов взаимодей- ствия с устройствами IoT. IWF в своей работе основное внимание уделил более глобальным вопросам, а именно: разработ- ке приложений, промежуточного ПО и поддерж- ке для нужд корпоративного сегмента Интернета вещей. Исходя из этих целей и задач, получившаяся модель IWF отличается следующими свойствами и характеристиками [14]: упрощает задачу: помогает разделить сложные системы на части таким образом, чтобы каждая из этих частей стала более понятной; проясняет структуру: для этого предо- ставляет дополнительные сведения в целях более точной идентификации уровней IoT и выработки и применения общей терминологии; идентифицирует важные аспекты: помо- гает определить моменты, в которых те или иные типы обработки оптимизированы в системе; стандартизирует решения: это первый шаг к тому, чтобы производители, поставщики и инсталляторы могли создавать продукты и ре- шения IoT, способные взаимодействовать между собой; организует технологию: делает техноло- гию IoT реальной и доступной частью жизни людей, а не далекой от конкретного человека и абстрактной концепцией. Уровень 1 образуют физические устройства и группы устройств, управляемые одним кон- троллером. Он во многом соответствует уров- ню устройства вмодели МСЭ-Т. Как и в модели МСЭ-Т, элементы на этом уровне - не физиче- ские вещи как таковые, а устройства, взаимодей- ствующие с физическими вещами, такие как сен- сорные и исполнительные устройства. Уровень 2 модели IWF соответствует уровню сети модели МСЭ-Т. Основное отличие в том, что модель IWF относит шлюзы к уровню 2, в то время как в модели МСЭ-Т они относятся к уров- ню 1. Исходя из того, что шлюз является одно- временно и сетевым устройством, и устройством связи, более логично его отнесение к уровню 2. Уровень 3. В большинстве внедряемых систем IoT большие объемы данных генерируются рас- пределенной сетью датчиков. Как правило, все эти данные долгое время хранятся в централизо- ванном хранилище, доступном для приложений IoT. Однако часто более целесообразно выпол- нять большую часть обработки этих данных как можно ближе к сенсорам/датчикам. В [14] при- ведены следующие примеры операций на уровне периферийных вычислений: анализ данных на предмет того, необходи- ма ли им обработка на вышележащем уровне; форматирование данных перед обработ- кой на вышележащих уровнях; разархивирование (декодирование) зашиф- рованных или сжатых данных; дистилляция (сокращение): обработка дан- ных для того, чтобы сократить объем данных и трафик в сети и разгрузить системы обработки на более высоких уровнях; оценка того, представляют ли данные до- пустимое значение или аварийный сигнал; эта за- дача может включать функцию перенаправления данных дополнительным получателям. Функции устройств этого уровня соответ- ствуют устройствам общего назначения в модели МСЭ-Т. Обычно они располагаются физически на краю сети IoT, рядом с сенсорами и другими устройствами, генерирующими данные. Такую обработку данных на периферии назы- вают туманными вычислениями (Fog Computing). Туманные вычисления и соответствующие им службы являются характерной отличительной чертой IoT. В туманных вычислениях большое число отдельных интеллектуальных объектов осуществляют связь с туманными сетевыми структурами, которые реализуют вычисления и хранят данные рядом с периферийными устрой- ствами в IoT. Уровень 4. Уровень накопления данных. Дан- ные, поступившие с различных устройств, от- фильтрованные и обработанные уровнем перифе- рийных вычислений, помещаются в хранилище, где будут доступны для более высоких уровней. Функции этого уровня сильно отличаются от низко- уровневых (туманных) и от высокоуровневых (облачных) вычислений. Отличия заключаются в особенностях конструкции, требованиях и мето- дах обработки данных. Те данные, которые передаются через сеть, на- зывают «данными в движении». Скорость пере- мещения и организация таких данных опреде- ляются генерирующими их устройствами. Для сбора и обработки таких данных требуется реак- ция соответствующих устройств в реальном мас- штабе времени на их появление или изменение. В противовес этому у многих приложений высоких уровней нет потребности обрабатывать данные со скоростью их поступления из сети. Ре- ально облачная сеть и прикладные платформы не могут успевать обрабатывать те объемы данных, которые генерируются огромным количеством IoT-устройств. Приложения часто имеют дело с «данными в покое». Эти данные обычно располагаются в легкодоступном хранилище. Приложения мо- гут обращаться к ним при необходимости и не в реальном времени. Как вывод - верхние уровни оперируют транзакциями, а три нижних уровня работают по событиям. Операции, выполняемые на уровне накопле- ния данных, включают: преобразование «данных в движении» в «данные в покое»; преобразование данных из формата сете- вых пакетов в реляционные таблицы БД; переход от вычислений по событиям к вы- числениям по запросу; значительное снижение объема данных за счет фильтрации и выборочного хранения. Уровень 5. Уровень абстракции данных. Если уровень накопления данных собирает большое количество данных и помещает их в хранилище, практически не приспосабливая к потребностям конкретных приложений, то уровень абстракции данных может агрегировать и форматировать та- кие данные способами, которые делают доступ приложений более управляемым и эффективным. Задачи данного уровня: комбинирование данных из различных ис- точников; выполнение необходимых преобразований для обеспечения единообразной семантики дан- ных из разных источников; помещение отформатированных данных в соответствующую базу данных; оповещение приложений более высоко- го уровня о том, что получены определенные данные; Рисунок 7. Стек протоколов IETF для IoT [9] консолидация данных в одном месте либо предоставление доступа к нескольким источни- кам данных путем виртуализации данных; защита данных путем соответствующей ау- тентификации и авторизации. Уровень 6. Уровень приложений. На этом уров- не расположены любые приложения, использу- ющие на входе данные от системы IoT или управ- ляющие IoT-устройствами. Эти приложения взаимодействуют с уровнем абстракции данных и используют «данные в покое». Как следствие, функционирование на скоростях сети для них не обязательно. При упрощенном режиме приложе- ния могут миновать промежуточные уровни и на- прямую взаимодействовать с уровнями 2 или 3. Уровень 7. Уровень взаимодействия и процес- сов появился как результат признания того, что IoT - это технология прежде всего для людей и их пользы. На этом уровне функционируют прило- жения для обмена данными и управляющей ин- формацией через Интернет или корпоративную сеть. IWF считает свою эталонную модель IoT по- лезной как для производителей и поставщиков, разрабатывающих функциональные элементы, так и для заказчиков решений, помогая им вы- рабатывать свои требования и условия, а также оценивать предложения поставщиков [7]. Стек протоколов IETF Инженерный совет Интернета IETF (Inter- net Engineering Task Force), занимающийся раз- витием протоколов и архитектуры Интернета, пытается адаптировать стек протоколов TCP/IP в контексте Интернета вещей [9]. Из-за нехват- ки вычислительных ресурсов и неоднородности устройств и трафика были введены новые прото- колы, которые заменили или адаптировали про- токолы стека TCP/IP (рисунок 7). В частности, на уровне приложений использу- ется протокол ограниченных приложений CoAP (Constrained Application Protocol) [17], который представляет собой облегченную версию про- токола передачи гипертекста HTTP, подходя- щий для работы с устройствами и датчиками с ограниченными ресурсами. СоАР на транспорт- ном уровне использует протокол UDP, который по сравнению с протоколом TCP обеспечивает меньше возможностей, но более прост в обработ- ке. СоАР определяет ретрансляцию сообщений с подтверждением и без, поддержку «спящих» устройств, передачу блоков данных, поддерж- ку подписки и обнаружение сервисов. Наконец, в стек протоколов добавлен слой адаптации, в ко- тором заголовки пакетов IPv6 для передачи по- верх маломощных беспроводных персональных сетей 6LoWPAN [20] инкапсулируются и сжима- ются, чтобы с ними могли работать устройства с небольшой вычислительной мощностью. Другие модели IoT-систем Справедливости ради стоит отметить, что по- мимо работ международных организаций над эталонными моделями IoT имеют место и другие подходы к созданию моделей IoT-систем на ос- нове идей, отличных от классического уровнево- го подхода, а также для конкретной предметной области. Например, в работе [18] представлена архи- тектура получения данных с сенсоров как услуга S2aaS (Sensing as a Service) - это концепция рас- ширения возможностей существующих приложе- ний IoT путем использования мобильных теле- фонов в качестве источников сенсорных данных (рисунок 8). Современные смартфоны являются мощной и доступной платформой для множества при- ложений и обладают обширным массивом дат- Рисунок 8. Архитектура S2aaS Рисунок 9. Архитектура IoT-системы в проекте AUTOPILOT чиков, встроенных в большинство из них. При сегодняшней доступности смартфонов и плотно- сти населения в городских районах может быть достигнута очень высокая плотность датчиков на квадратный километр [19]. Поэтому логично предположить, что передача функций сбора ин- формации на смартфоны и организация общего доступа к ней являются разумной идеей. Среди проблемных вопросов данной архи- тектуры следует отметить следующие: формат использования смартфона с участием или без участия владельца; обеспечение безопасности устройства и неприкосновенности личных дан- ных и частной жизни; способы мотивации участ- ников и способы распределения вознаграждения за участие в подобной сети; повышенное энергопотребление во время работы смартфона и износ оборудования [15]. Другая модель IoT-системы разработана в рамках исследовательского проекта по бес- пилотному транспорту на основе технологий Интернета вещей - AUTOPILOT (AUTOmated driving Progressed by the Internet Of Things), кото- рый проводился с 2017 по 2020 год [21]. Проект AUTOPILOT направлен на объединение опыта, знаний и технологий в области автомобилестро- ения и Интернета вещей для разработки IoT- архитектуры, которая выведет автоматизирован- ное вождение на новый уровень. Архитектура IoT-системы в проекте AUTO- PILOT состоит из четырех уровней (рисунок 9): уровня вещей и внешних сервисов; сетевого уровеня; уровеня IoT; уровеня приложений AUTOPILOT. Первый уровень состоит из различных объек- тов (беспилотного транспорта, дорожной инфра- структуры и др.). На сетевом уровне реализуются различные виды сетевых соединений. На третьем уровне располагаются различные функциональ- ные блоки, выполняющие необходимые опера- ции в системе IoT (управление устройствами, процессами и сервисами, аналитика, идентифи- кация, безопасность и др.). Четвертый уровень представлен приложениями, которые будут раз- работаны для AUTOPILOT. Эта структура не накладывает ограничений на физическое представление, когда блоки обработ- ки или связи развертываются в разных местах в зависимости от потребностей. Например, блоки обработки могут быть расположены как в облаке, так и на границе. Данная модель во многом повторяет эталон- ные архитектурные модели МСЭ-Т и IoT-A, отли- чие заключается только в использовании специ- фических устройств и приложений, характерных для предметной области беспилотного транспорта. Выводы Согласно отчету McKinsey Global Institute [12], примерно 40 % экономического эффекта от IoT приходится на способность всех устройств взаимодействовать друг с другом, другими сло- вами, на совместимость. При ограничении со- вместимости потенциальная ценность IoT может снизиться и составить около $7 трлн. В то время как реализация развитой совместимости способ- на поднять экономический эффект от IoT для гло- бальной экономики до $11 трлн к 2025 году. Для раскрытия этого потенциала необходимо выра- ботать и придерживаться единых стандартов на всех уровнях функционирования технологии IoT. Проведенный анализ существующих эталон- ных архитектурных моделей IoT, разработанных различными международными организациями, а также применяемых в них технологий и протоколов позволяет сделать следующие выводы. Все модели и стеки протоколов имеют уровневую структуру, ставшую, по сути, стан- дартом «де факто» при разработке технических систем. Различаются количество уровней в каж- дой модели, их названия и реализуемые функции. Нижележащие уровни, отвечающие за физиче- ские устройства, во всех моделях имеют прак- тически одинаковые функции, хотя и тут есть нюансы, к примеру отнесение шлюзов в моделях МСЭ-Т и IWF к различным уровням, физическо- му и сетевому соответственно. Несмотря на имеющиеся различия, во всех моделях присутствует коммуникационный уро- вень, некоторая сеть коммуникации, осуществля- ющая доставку сообщений между устройствами. Другими словами, Интернет вещей невозможен без современных сетей передачи данных [22]. Что касается уровней, располагающихся выше уровня сетевого взаимодействия, то тут разные модели используют различный подход. Если трехуровневая и пятиуровневая модели, а также модель МСЭ-Т дают достаточно общее описание того, что должно быть на этих уровнях и мало уделяют внимания тому, как это должно функционировать, то модель IWF и стек протоко- лов IETF включают конкретные рекомендации и технологии. Этот факт, наверное, и не вызывает удивления, по той причине, что в работе фору- ма IWF и группы IETF участвуют разработчики решений, производители оборудования и опе- раторы, которым необходимо по этим стандар- там осуществлять промышленное производство, установку и эксплуатацию оборудования и про- граммного обеспечения IoT. Следует особо отметить, что функции управления и безопасности явным или неявным образом пронизывают большинство уровней во всех эталонных моделях. В некоторых из них, на- пример в моделях МСЭ-Т и IoT-A, эти функции непосредственно выделены в отдельные верти- кальные уровни, взаимодействующие со всеми горизонтальными уровнями моделей. В целом можно отметить, что, хотя эти подхо- ды пока еще далеки от единства и совершенства, рассмотренные архитектурные модели являются полезным базисом для дальнейших усилий по стандартизации Интернета вещей, которая про- должается в мире и в России [3-5].×
About the authors
A. V Roslyakov
Povolzhskiy State University of Telecommunications and Informatics
Email: arosl@mail.ru
Samara, Russian Federation
A. A Kiryakov
Gazprom Transgaz Samara Limited Liability Company
Email: andrey.a.kiryakov@gmail.com
Samara, Russian Federation
References
- Интернет вещей / А.В. Росляков [и др.]. Самара: ООО «Издательство Ас Гард», 2014. 342 с
- Abdmeziem M.R., Tandjaoui D., Romdhani I. Architecting the Internet of Things: State of the art // Robots and Senor Clouds. 2016. P. 55-75
- Стандартизация Интернета вещей / А.В. Росляков [и др.] // Электросвязь. 2013. № 8. С. 10-13
- Росляков А.В. Стандартизация интернета вещей в России // Стандарты и качество. 2020. № 7. С. 18-23
- Росляков А.В. Национальные стандарты Интернета вещей // Вестник связи. 2020. № 7. С. 29-32
- Internet of Things - Architecture. Final architectural reference model for the IoT v3.0. 2013. 482 p
- Stallings W. The Internet of Things: Network and security architecture // The Internet Protocol Journal. 2015. Vol. 18, no. 4. P. 2-24
- Internet of Things: A survey on enabling technologies, protocols, and applications / A.I. AlFuqaha [et al.] // IEEE Communications Surveys and Tutorials. 2015. P. 2347-2376
- Lombardi M., Pascale F., Santaniello D.Internet of Things: A general overview between architectures, protocols and applications // Information. 2021. Vol. 12, no. 87. P. 1-20. DOI: https://doi.org/10.3390/info12020087
- IoT middleware: A survey on issues and enabling technologies / A. Ngu [et al.] // IEEE Internet of Things Journal. 2017. Vol. 4, no. 1. P. 1-20
- ITU-T. Recommendation Y.2060. Overview of the Internet of Things. 2012. 14 p
- The Internet of Things: Mapping the Value Beyond the Hype // McKinsey Global Institute. URL: https://s3.amazonaws.com/midokura-marketing-materials/IIOT/McKinsey-Mapping-the-value-beyond-the-hype.pdf (дата обращения: 23.10.2021)
- ITU-T. Recommendation Y.4101/Y.2067. Global information infrastructure, Internet protocol aspect, next-generation networks, Internet of things and smart cities, 2017. 18 p
- Cisco Systems. The Internet of Things Reference Model, White Paper. 2014. 12 p
- Crowdsourcing to smartphones: incentive mechanism design for mobile phone sensing / D. Yang [et al.] // Mobicom’12: Proceedings of the 18th annual international conference on Mobile computing and networking. 2012. P. 173-184. DOI: https://doi.org/10.1145/2348543.2348568
- Sensing as a service model for smart cities supported by Internet of Things / C. Perera [et al.] // Transactions on Emerging Telecommunications Technologies. 2014. Vol. 25, no. 1. P. 81-93
- IETF. RFC 7252. The Constrained Application Protocol (CoAP), 2014. 111 p
- Sensing as a service: Challenges, solutions and future directions / Х. Sheng [et al.] // IEEE Sensors Journal. 2013. Vol. 13, no. 10. P. 3733-3741
- Cloud of things for sensing-as-a-service: Architecture, algorithms, and use case / S. Abdelwahab [et al.] // IEEE Internet of Things Journal. 2016. Vol. 3, no. 6. P. 1099-1112
- IETF. RFC 7252. Transmission of IPv6 packets over IEEE 802.15.4 networks, 2007. 112 p
- AUTOmated driving Progressed by Internet of Things. Initial specification of Communication System for IoT-enhanced AD. 2017. 140 p
- Трошин А.В. Методы машинного обучения для распознавания человеческой активности с использованием датчиков окружающей среды // Инфокоммуникационные технологии. 2021. Т. 19, № 1. С. 91-100
- Гребешков А.Ю., Дараев Д.М. Разработка интеллектуального сенсорного узла на базе технологии LоRа // Инфокоммуникационные технологии. 2021. Т. 19, № 2. С. 179-186
Supplementary files
![](/img/style/loading.gif)