ИНТЕРНЕТ ВЕЩЕЙ: ОБЗОР ЭТАЛОННЫХ АРХИТЕКТУРНЫХ МОДЕЛЕЙ

Полный текст

Введение Одна из основных проблем, связанная с техно- логическим аспектом развертывания систем Ин- тернета вещей 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].

Об авторах

А. В Росляков

Поволжский государственный университет телекоммуникаций и информатики

Email: arosl@mail.ru
Самара, РФ

А. А Кирьяков

ООО «Газпром трансгаз Самара»

Email: andrey.a.kiryakov@gmail.com
Самара, РФ

Список литературы

Дополнительные файлы