Как IoTctivity plus AllJoyn может сформировать «лучшую в своем роде» платформу IoT

IoTctivity и AllJoyn имеют много общего, в том числе способность устройств находить и взаимодействовать друг с другом, не требуя облачных сервисов.

На апрельской конференции по встраиваемым Linux-технологиям исполнительный директор Open Connectivity Foundation (OCF) Майк Ричмонд завершил свое выступление о потенциале взаимодействия между IoT-инфраструктурой OCF и спецификацией AllJeen AllSeen Alliance, пригласив на сцену главного архитектора Greg Burns. AllJoyn.
Бернс вкратце поделился своим мнением о том, что не только не было никаких серьезных технических препятствий для объединения этих двух основных спецификаций IoT с открытым исходным кодом, но и, что, взяв лучшее из обоих стандартов, может появиться гибрид, улучшающий оба.

Позже в тот же день Бернс дал технический обзор того, как такой гибрид мог быть создан в «Развитии IoT-инфраструктуры лучшего в своем классе» (см. Видео ниже.) В обоих выступлениях Бернс заявил, что его мнение никоим образом не отражает официальная позиция OCF или AllSeen Alliance.
Во время выступления на ELC в апреле Бернс недавно оставил свою должность вице-президента по инженерным разработкам в Qualcomm и председателя технического руководящего комитета в AllSeen Alliance, чтобы занять должность главного технолога программного обеспечения IoT в Технологическом центре с открытым исходным кодом в Intel Corp.

Некоторые из предложенных Бернсом слияний с функциями AllJoyn уже активно оцениваются в IoTctivity.
Позже в этом году IoTctivity 2.0 представит первый уровень совместимости с AllJoyn, а последующие выпуски, вероятно, будут включать больше изменений, вдохновленных AllJoyn.
Также в ELC глава Intel Vijay Kesavan, который является председателем целевой группы Iotivity Security, представил обзор IoTctivity 2.0 .

Общие сильные стороны и интересные различия

В своем выступлении Бернс объяснил, что у IoTtivation и AllJoyn много общего.
Сходства включают стандартизированные проводные протоколы, определения схем и модели данных, а также схему проксимального обнаружения на основе многоадресной IP-рассылки, которая позволяет устройствам находить и связываться друг с другом, не требуя облачной службы.
Обе структуры также поддерживают транспорт и независимость от ОС, а также совместную разработку с открытым исходным кодом, добавил он.

Бернс признал, что многие термины и понятия, используемые этими двумя структурами, различны.
Тем не менее, многие из этих концепций отображаются напрямую, добавил он.
Например, URI в IoTctivity переводится как «имя шины плюс путь к объекту» в AllJoyn.
Точно так же ресурс IoTctivity - это, по сути, объект AllJoyn, коллекция - это дочерний объект, ссылка - это локальный путь к объекту, а наблюдение - это дополнение.
«Я действительно не вижу проблемы в том, чтобы сделать эти концепции более похожими», - сказал Бернс.

Есть также несколько уникальных концепций с каждой стороны.
Бернс предлагает использовать как минимум два из них: «интерфейс» IoTctivity и «самоанализ ресурсов» AllJoyn.



Слайды 1-6 презентации Бернса

(нажмите на картинку, чтобы увеличить; скачать полный PDF здесь )

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

  • Модель программирования - IESTive RESTful с Notify против D-Bus AllJoyn, RMI (индикация удаленного сообщения) и PubSub:

    «Честно говоря, это не имеет значения.
    Все, что вы можете выразить в одном, вы можете выразить в другом.
    Так что придерживайтесь RESTful.
    Это работает и широко применяется.
    У нас были проблемы с попыткой заставить людей принять подход AllJoyn, потому что он был незнакомым.
    Взаимодействие с такими группами, как W3C, действительно ценно для любого стандарта IoT, а архитектура D-Bus - непростая задача.
    Это битва, в которой не стоит сражаться ».

  • Схема - полезная нагрузка ISON от JSON с двоичной сериализацией CBOR и RAML (язык моделирования RESTful API) против двоичной полезной нагрузки AllJoyn с сериализацией XML и D-Bus:

    «XML-решение AllJoyn основано на D-Bus, но со временем оно стало богаче и эволюционировало, чем JSON.
    Поскольку AllJoyn использует сигнатуры типа D-Bus, это более точно.
    JSON необходимо расширить, чтобы точно указать, как данные сериализуются путем добавления типов данных, которые являются расширенными обозначениями в схеме специально для генерации кода.
    Возможность автоматически генерировать код из модели данных чрезвычайно мощна.

    «Нам нужна однозначная сериализация - в обоих направлениях.
    Прямо сейчас IoTctivity может сериализоваться как число с плавающей запятой, целое число и другими способами, поэтому приемные устройства должны обрабатывать несколько типов сериализации.
    Это не большая проблема, чтобы исправить это.
    Также было бы полезно добавить «события и действия» из AllJoyn: поддержка нескольких универсальных типов, дополнительных метаданных, значений перечисления и удобочитаемых строк.

    «CBOR немного компактнее, чем D-Bus, но в значительной степени эквивалентен.
    С AllJoyn вы должны знать, насколько велики данные, прежде чем сможете их сериализовать, но CBOR имеет хороший механизм для потоковой передачи, который позволяет идентифицировать последовательные блоки.

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

  • Транспорт - UDP IoTctivity (IPv4 и 6) и многоадресная передача UDP против UDP и TCP AllJoyn (IPv4 с 6 пришедшими):

    «Я не думаю, что IoTctivity уже существует.
    Прямо сейчас это реализация только для COAP ».

  • Обнаружение услуг - CoAP IoTctivity против MDNS AllJoyn:

    «Они в основном одинаковы: многоадресная IP-рассылка с одноадресными ответами и разными одноадресными адресами».

  • Топология сети - точка-точка и точка-многоточка IoTctivity против «сетки звезд» AllJoyn с листовыми и маршрутными узлами:

    «В целом, подход IoTctivity предпочтительнее, но сетка звезд AllJoyn имеет свои преимущества.
    В AllJoyn конечные узлы [конечные точки] полагаются на узлы маршрутизации для передачи сообщений, а также для объявления и обнаружения услуг.
    Сначала он выглядел как D-Bus, но стал более распространенным.
    Подход AllJoyn позволяет использовать легкие и простые устройства на конечных узлах, но их необходимо подключить к узлу маршрутизации под управлением Linux или Windows.
    У вас не может быть двух листовых узлов, говорящих друг с другом.
    Поэтому, если узел маршрутизации не работает на точке доступа, вы удвоите пропускную способность вашей сети ».

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

  • Безопасность и разрешения - канальный уровень ILS от DTo с разрешениями ACL и ресурсом, интерфейсом, подстановочными знаками и CRUDN против прикладного уровня AllJoyn и ACL плюс «возможность» с интерфейсом, объектом, свойством, методом и т. Д. »

    «Базовые технологии безопасности похожи, и в них используются ECC, AES и X509, но подход AllJoyn лучше.
    С AllJoyn пакеты шифруются на уровне приложения, поэтому не имеет значения, как они попадают в пункт назначения.
    С помощью шифрования канального уровня IoTctivity вы пересекаете границы, перемещаясь по разным уровням, поэтому вам нужны надежные отношения между конечной точкой и каждой граничной точкой.
    Если вы переходите от COaP к серверу, который затем подключается к XMPP, вам нужны доверительные отношения с сетью.
    Но добавить слой приложения не так сложно ».

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

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

Дальнейшая информация

Посмотрите полное видео ниже и загрузите слайд презентации в формате PDF здесь .

Развитие лучшей IoT-инфраструктуры

Дополнительные видео с ELC 2016 и OpenIoT Summit доступны здесь (требуется бесплатная регистрация).

Эта статья защищена авторским правом © 2016 Linux.com и была первоначально опубликована здесь .
Он был воспроизведен этим сайтом с разрешения его владельца.
Пожалуйста, посетите Linux.com для получения последних новостей и статей о Linux и open source.