В то время как устройства IoT объединяются вокруг IP, многие подходы на уровне приложений должны быть разрешены, если разработчики носимых устройств должны максимизировать свою полезность
Автор Патрик Маннион, Редактор
В быстро развивающемся Интернете Things поставщики технологий работают над согласованием модели данных, которая позволит миллионам устройств с ограниченными ресурсами подключаться и общаться с пользой. В то же время разработчики носимых устройств - для фитнеса, медицинского, отслеживания местоположения, доступа к зданию или других приложений - продолжают сталкиваться с необходимостью выбирать стороны, снижая функциональную совместимость и ограничивая полезность устройств.
Существует почти так много причин, чтобы не быть интероперабельными, поскольку они должны быть совместимы, особенно если устройство должно быть ультранизким энергопотреблением, как в случае с носимыми. В то время как совместимость на уровне протокола позволяет большему количеству устройств взаимодействовать друг с другом, недостатком является «тяжелый» протокол со слишком большими издержками, который пытается учесть слишком много типов устройств и моделей использования, которые занимают слишком много памяти и потребляют слишком много энергии во время коммуникации. Это также добавляет стоимость.
Для производителей есть определенные стратегические преимущества, которые можно получить, используя собственный подход, включая полный контроль над интерфейсом, пользовательский интерфейс и безопасность. Apple Home Kit - классический пример. Однако для конечных пользователей конечный результат - это устройство, которое может выполнять свою явную функцию, например, определять частоту сердечных сокращений и уровень потоотделения, но не может повлиять на какие-либо изменения в окружающей среде, чтобы помочь устранить крайности, потому что может быть неспособно общаться его атрибуты к уже установленной системе климат-контроля.
Однако преимущества интероперабельности для разработчиков также включают в себя лучшую будущую проверку конструкций, общую экосистему совместимых устройств и лучшую общую поддержку экосистем на этапах разработки.
Это не означает, что еще не было предпринято существенных усилий для обеспечения интероперабельности. Лучший способ оценить, как это развивается, - это взглянуть на модели связи OSI и TCP / IP (рис.1).
Рисунок 1: В то время как различные интерфейсы исторически были несовместимы, IoT обеспечил интероперабельность в сети и транспортные уровни вокруг IP. Теперь акцент переключается на определение моделей данных для прикладного уровня. Источник изображения: Стив Ивесон, www.networkstuff.eu.
В то время как Wi-Fi имеет IP-адреса, обычные беспроводные интерфейсы, такие как Bluetooth и zigbee, должны были работать над ним. Оба теперь поддерживают IPv6, используя 6LoWPAN для сквозной поддержки IP на сетевом и транспортном уровне, а также Thread, который также подчеркивает сетевую сеть и безопасность.
Конвергенция в основном связана с протоколом ограниченного приложения (CoAP) по протоколу дейтаграмм пользователя (UDP) с использованием сжатия объектов JavaScript (JSON) и сжатого представления двоичных объектов (CBOR). В отличие от более зрелого телеметрического транспорта очереди сообщений (MQTT) CoAP поддерживает как синхронные, так и асинхронные сообщения. Кроме того, он представляет собой протокол передачи репрезентативного состояния (REST) для доступа к веб-службам и поддерживает безопасность уровня транспортного потока данных (DTLS). Другие характеристики CoAP, которые делают его привлекательным для приложений с малой мощностью, включают в себя быстрый цикл передачи и меньшее количество типов сообщений.
По сравнению со старым XML-зависимым протоколом простого доступа к объектам (SOAP) протоколы RESTful легче и могут использовать URL-адреса непосредственно для веб-служб. REST может фактически использовать несколько глаголов напрямую - например, GET, POST, PUT и DELETE - для выполнения задач.
Все они хороши для носимых устройств, которые должны взаимодействовать асинхронно с минимальным шумом. Однако, более или менее решив интероперабельность на сетевом и транспортном уровнях, акцент теперь переключился на прикладной уровень и модель данных, которые еще не согласованы. Однако Альянс IPSO изложил некоторые фундаментальные требования на уровне приложений для интеллектуального объекта, стремясь достичь определенного уровня консенсуса (рис.2).
Рисунок 2: Альянс IPSO создал некоторые базовые требования к прикладному уровню и модели данных в целях достижения консенсуса, чтобы интеллектуальные объекты могли общаться более эффективно. Источник изображения: Centero.
Как уже упоминалось, Home Kit от Apple - это один из подходов. Другие включают Google Weave, Open Connectivity Foundation (OCF), Z-Wave, а альянс zigbee объединил кластер профилей и наложил его на dotdot, чтобы позволить устройствам IoT общаться независимо от базовой сети. Все адреса или устройства с низким энергопотреблением, с низким ресурсом, от носимых до лампочек и попытки определить рабочие модели данных на уровне приложений, которые помогут различным устройствам обмениваться данными.
Однако есть несколько вещей, которые требуют более четкого определения. Одним из них является описание объекта и его возможностей, и это буквально вопрос семантики.
По словам Джеффа Маллигана, учредителя и члена Совета директоров Альянса IPSO, «теперь речь идет о модели данных, семантике данных IoT». Например, если датчик температуры на носимом или в комнате говорит «40, "Это горячий или холодный? Фаренгейта или Цельсия? Получает ли устройство количество, даже знаю, что оно исходит от датчика температуры? «Вы не можете отправить полный словарь, чтобы сказать, что означает 40, и сказать, что это от датчика температуры», - сказал Маллиган. Трюк заключается в нахождении модели данных, которая дает достаточную информацию об интеллектуальном объекте, не выходя за борт.
С точки зрения Маллигана, библиотека кластеров zigbee (ZCL) получила модель неправильно. «Модель интеллектуальных объектов IPSO (SO) отделяет глагол от объекта; Зигби положил их вместе », - сказал он. Например, «ZCL ставит 70 вместе с« устанавливает температуру в », поэтому вам нужно больше привязки между источником и пунктом назначения. Это связывание создает очень сложную систему, которая рискует быть неуправляемой и нерациональной ». Вместо этого IPSO SO отправляет сообщение с сообщением« Temp - 70 градусов C или F », а затем SO определяет контекст.
IPSO Smart Objects находится поверх открытого M2M-протокола Open Mobile Alliance (OMA) (LWM2M) и может работать хорошо по потоку (рис.3). Тем не менее, он будет конкурировать с dotdot.
Рисунок 3: Thread - это четко определенный и безопасный IP-сетчатый сетевой протокол, на котором может сидеть прикладной уровень. Тем не менее, определение приемлемой, совместимой модели данных для прикладного уровня помещает dotdot zigbee в конкуренцию с интеллектуальными объектами IPSO. Источник изображения: Centero.
«Мы хотим, чтобы система была несвязана с любым более низким уровнем», - сказал Маллиган. «IPSO SO будет работать отлично над zigbee, но в настоящее время они преследуют dotdot».
По крайней мере, dotdot и IPSO SO прилагают усилия для определения совместимого подхода. Другие, такие как LONWorks, являются строго проприетарными и популярными в системах управления зданием. Тогда есть Siemens и Emerson, которые также замалчиваются. «Каждый определяет энергетические характеристики запатентованным способом, - сказал Маллиган. Это обеспечивает классическую блокировку поставщика. «Wi-Sun более открыта, но даже многие открытые стандарты имеют закрытый набор моделей данных, поэтому вы заперты в их решении».
Метамодель моделей: Вы с ума сошли?
Закрытый и зашумленный подход имеет много недостатков. Среди них, по словам Скипа Эштона, вице-президента по программному обеспечению Silicon Labs, заключается в том, что с точки зрения пользователя различные устройства не могут взаимодействовать друг с другом и усиливать друг друга. С точки зрения разработчика, общий доступный рынок для устройства искусственно ограничен.
Конечно, организации строят мосты между сетями, поэтому устройство zigbee может попасть в сеть Apple Home Kit, но в целом его возможности масштабирования ограничены. Кроме того, разработчики опасаются разработки для сети, ориентированной на смартфонов и контролируемой одной или двумя компаниями (Apple Home Kit и Google Weave). Система безопасности Apple Home Kit не будет разговаривать с дверным замком Android.
Для точки объектной модели Эштон видит, что многочисленные подходы рушится до двух или трех, и он смещен к dotdot поверх Thread. Тем не менее, он борется с моделированием в целом. С одной стороны, он видит необходимость абсолютной ясности в описаниях атрибутов объекта, например, связанных с лампочкой. Тем не менее, описание этого слишком окончательно препятствует интероперабельности до тех пор, пока все не сходится по универсальному описанию «Что должен выглядеть объект лампочки как каноническая истина»?
Эштон слышал о решении, которое могло бы решить головоломку: метамодель моделей. «Семантически это поднимает слой, и поэтому вы можете сопоставить все из них (другие протоколы)», - сказал Эштон. «Это звучит неплохо, но если я пойду к лампочке или изготовителю дверных замков и предложим это, они подумают, что я сумасшедший». С их точки зрения метамодель моделей только увеличивает стоимость. Стоимость небольшая, но когда они перевозят миллионы, пенни быстро складываются. «Поэтому они не хотят семантически моделировать что-либо; они хотят, чтобы это было очень специфично ».
Вывод
То, как моделирование объектов будет развиваться в ближайшие годы, существенно повлияет на эффективность и полезность носимых устройств. Очевидно, что существует много подходов и веских оснований для этих подходов, но работа Альянса IPSO (Smart Objects) и zigbee (dotdot), в то время как конкуренция, может оказаться взаимовыгодным решением, которое поможет дизайнерам расширить доступный рынок для их продукции.