Готовый перевод Management and Internet of Things / Управление и Интернет вещей: Management and Internet of Things

Резюме

В тренде находятся исследование и разработка приложений Интернета вещей (Internet of Things, IoT), а также для веб и смартфонов. Приложений, работающих с данными, полученными из различных областей, таких как перевозки, умные дома, здравоохранение, социальные услуги, промышленность и многие другие. Предыдущие исследования сосредотачивались на управлении полученными данными. Однако управление разнородными ресурсами, которые получают те данные, является областью, которая требует большего внимания. Эта статья обращается к управлению ресурсами в Интернете вещей. Это достигается предложением слоя виртуального ресурса Edge, который разрешает доступ и конфигурацию к физическим ресурсам встроенных устройств. Архитектура представляет центры использования виртуальных ресурсов как концепцию управления и определяет разные подходы к оценке результатов эффективности вычислительных устройств. Используя протокол IoT CoAP, виртуальные ресурсы показывают границы сети edge. Представлена оценка Go CoAP виртуального ресурса.

Ключевые слова: Интернет вещей; Менеджмент IoT; Виртуальные ресурсы; CoAP

1. Введение.

В Интернете Вещей коммуникация и управление ресурсами реализуются на основе технологии, в которой создана сеть встроенных устройств. Каждый вендор убеждается в разработке его собственных инкапсулировано-совместимых и проприетарных коммуникационных стандартов. Приложения были поддержаны теми проприетарными стандартами, чтобы получить достоверную информацию эффективным и безопасным способом от среды встроенных устройств до облака. Это заставило пользователей, принять определенную технологию во всех реализациях, для упрощения режимов работы управления (ITU-T M.3400). Были некоторые исследования физических устройств IoT, но их основная цель состояла в том, чтобы упростить работу разработчиков.

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

Эта статья предлагает создание виртуальных ресурсов, выполняющихся на вычислительных устройствах Edge. Кроме того, это исследование предлагает Constrained Application Protocol (CoAP) для коммуникации виртуальных ресурсов и языка программирования Go, используемого для их построения. Это представление разрешает встроенным компонентам получать легкий доступ от третьих лиц. Непосредственная связь с физическими ресурсами разбита, введением слоев виртуальных ресурсов.

Далее статья структурирована следующим образом. Раздел 2 представляет определение наших ресурсов IoT. Раздел 3 объясняет экспериментальную установку. Раздел 4 представляет оценку результатов деятельности нашего прототипа, и завершается статья резюме в разделе 5.

2. Дизайн архитектуры виртуальных ресурсов IoT.

Мы определяем виртуальные ресурсы IoT как абстракцию других ресурсов, виртуальных или нет. Архитектурный проект виртуальных ресурсов IoT графически изображён на Рис. 1. Используя REST-функции CoAP (RFC7252), виртуальный ресурс представляет свое собственное состояние и методы, которые взаимодействуют с состояниями и могут разрешить взаимодействия между его составными ресурсами. Вся архитектура включает три главных уровня а именно: уровень абстракции представления (VAL), уровень аппаратной абстракции (HAL) и физический уровень. Физический уровень представляет датчики, работающие в среде. Эти два уровня, аппаратной абстракции и абстракции представления, являются приложением промежуточного программного обеспечения, размещенного на виртуальном edge-сервере и нацеленным на инкапсуляцию сложностей доступа и конфигурацию физических ресурсов. HAL представляет ассоциацию самого низкого уровня между физическим ресурсом и виртуальным ресурсом, приводящим к непосредственному отношению, см. Рис. 2.

Виртуальные ресурсы, размещенные в этом уровне, используют команды CoAP для приема заказов по выполнению операций обращения к физическим ресурсам. VAL действует как мост между конечными пользователями и датчиками. Это представляет объединение между одним или несколькими виртуальными ресурсами HAL и одним или несколькими виртуальными ресурсами VAL, приводящих к отношению "многие-ко-многим" (см. Рис. 3). Цель виртуальных ресурсов, помещенных в этот уровень, состоит в том, чтобы обеспечить динамические представления для разнородных пользователей с различными правами доступа.

Кроме того, этот уровень работает центром edge-обработки, в котором строки данных обрабатываются, не заходя в облако. На этом уровне виртуальные ресурсы разделены на две группы: виртуальные ресурсы, не имеющие состояния, и сохраняющие состояние. Виртуальные ресурсы, не сохраняющие состояние, представленные на рис. 4, применяют REST-паттерн CoAP, извлекающий состояние каждый раз, когда запрос получен. Виртуальные ресурсы, сохраняющие состояние, представленные на рис. 5, поддерживают состояние их составных ресурсов в базе данных и применяют паттерн проектирования CoAP для получения обновлений ресурсов, которые они наблюдают.

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

3. Экспериментальная установка

Этот эксперимент был выполнен с ресурсом VAL. Прототип включает сетевую инфраструктуру встроенных устройств, виртуальные ресурсы и эмулированные клиенты. Как только ресурс VAL получает CoAP-запрос от CoAP-клиента, он получает состояние своих ресурсов встроенных устройств и отправляет обработанную информацию в CoAP-сообщении. Одноплатный компьютер Raspberry Pi с языком Go и CoAP-протоколом использовался в качестве edge-вычислительного уровня для запуска виртуального ресурса, см. рис. 6. Нами создан виртуальный ресурс и клиенты, использующие каналы и подпрограммные функции на Go, см. рис. 7. Мы установили предложенную архитектуру на устройствами со следующими спецификациями: Raspberry PI 2 Model B с. процессор ARMv7, ЦП: Cortex-A7 quad core - 900 MHz, RAM: 1 Гбайт, Операционная система: Raspbian ОС. IMac с процессором: Core i7 Intel - 3.5 ГГц. RAM: 16 Гбайт, 64-битная операционная система. Клиенты соединялись с виртуальным ресурсом по специальному соединению WiFi.

4. Оценка

Для оценки полезной функциональности нашего виртуального ресурса, мы измеряли его пропускную способность и время отклика. Мы оценили поведение нашего виртуального ресурса, тестирующего два процесса Core Link Format (RFC6690), отыскивая службы посредством хорошо - известный интерфейса и получения текущего состояния. Эти оценки были выполнены с клиентской точки зрения. Кроме того, мы оценили время соединения с базой данных в сохраняющем состояние ресурсе VAL. Службы, предоставленные нашему виртуальному ресурсу, были размещены как службы CoAP REST. Сценарий заключался в запуске Go CoAP Virtual Resource на Raspberry Pi и одной тысяче из Go CoAP виртуальных клиентов, работающих на компьютере IMac. Этот эксперимент представлял время задержки клиентских запросов от 0 до 100 миллисекунд, с интервалами 50 миллисекунд, эмулируя разные уровни параллелизма.

Результаты для всей тысячи запросов в каждом сценарии задержки объясняются следующим образом. Среднее значение время на передачу и подтверждение для открытия службы (RTT) для трех случаев задержки, 0, 50 и 100 мс, составляет 2.24 мс, 2.40 мс и 2.33 мс соответственно, см. рис. 8.

В этом тесте рабочая нагрузка виртуального ресурса и его время отклика остается стабильной для трех случаев задержки. Среднее время RTT для получения текущего состояния виртуального ресурса для трех случаев задержки составляет 12.01 мс, 14.47 мс и 12.98 мс. В этом процессе увеличилось среднее время отклика, поскольку это - сохраняющий состояние виртуальный ресурс, который должен перейти к базе данных, чтобы получить текущее состояние ее ресурсов встроенных устройств, см. рис. 9. Среднее время, когда виртуальный ресурс обращается к базе данных для поиска состояния определенного ресурса встроенного устройства при трех задержках, составляет 7.53 мс, 8.29 мс и 8.07 мс, см. рис. 10. Во всех трех оценках были пики, которые могут быть объяснены сетевым трафиком и процессами резервного копирования, которые представляет общие аномалии. База данных работала в разделенной машине.

5. Выводы.

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

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

Внимание! Этот перевод, возможно, ещё не готов.
Его статус: идёт перевод

Переведено на Нотабеноиде
http://notabenoid.org/book/70062/374564

Переводчики: Urmia