FlexContainer, контейнер и SDT в OneM2M

Question

Когда мы должны использовать вместо ? Я видел несколько примеров использования , они использовали для устройства SDT. Используется ли только для устройств SDT?

Представьте, мы создаем <контейнер>, и он предназначен для хранения значений датчика температуры. Фактические значения устройства хранятся в , а тип температуры (в градусах Цельсия или Фаренгейта) определяется полем семантического дескриптора ресурса . Однако мы также можем определить значение и его тип в поле [customAttribute] в . Итак, в этой ситуации, почему я должен определять тип данных в поле семантического дескриптора , или почему я должен использовать вместо ?

SDT определены для некоторых устройств в документе TS-0023. Если производитель устройства не определил SDT и если мы хотим использовать это устройство, как мы можем создать для него файл SDT/XML?

Answer 1

во многом отличается от обычного ресурса :

• Ресурс не хранит фактические значения в самом ресурсе. Дочерние ресурсы <контейнера>, т.е. или другие ресурсы , делайте. Напротив, специализация содержит сами фактические значения.
• Сам не может быть непосредственно создан, он является только логической основой для дальнейшей специализации (очень похоже на базовый класс в ООП). Он определяет ряд атрибутов, которые поддерживают эти специализации, например, атрибут containerDefinition содержит идентификатор, который определяет фактический тип конкретного ресурса . Специализация затем определяет четко определенную структуру, которая может содержать довольно сложную структуру точек данных. Упомянутые устройства и классы модулей из TS-0023 являются такими специализациями, например, температура. Эти специализации имеют четко определенную структуру с семантикой, ограничениями и т. Д.
• Большим преимуществом является то, что его можно обновлять, а в можно только добавлять или удалять. Это также означает, что, если приложению требуется только текущий статус устройства и его не интересуют более старые значения данных, одна специализация - это (более или менее) все, что нужно приложению.
• Все точки данных, содержащиеся в специализации , считываются и записываются одновременно. В некоторых случаях это снижает нагрузку на связь и снижает вероятность возникновения гонки при чтении или записи большого количества точек данных.

К SDT: шаблон смарт-устройства - это метод спецификации для определения функциональных блоков "Lego", так называемых "ModuleClasses". Эти ModuleClasses могут тогда быть взяты, чтобы построить прототип "Устройства". Упомянутая спецификация oneM2M "TS-0023: информационная модель и отображение бытовой техники" определяет ряд этих классов и устройств ModuleClass и устройств, а также соответствие специализациям . Это означает, что для определения функциональности "температура" /ModuleClass существует ресурс oneM2M .

Если вы хотите создать новое определение устройства с использованием SDT, я бы посоветовал вам сначала взглянуть на список уже определенных ModuleClasses и Devices в TS-0023. Если нужная вам функциональность недоступна, вы можете определить свой собственный ModuleClass и Device, написав свой собственный файл SDT.

Определение SDT доступно по адресу https://git.onem2m.org/MAS/SDT.

Последняя версия SDT для ModuleClasses и устройств, определенных в TS-0023, доступна по адресу https://git.onem2m.org/MAS/Home-Appliances.

Инструмент для генерации необходимого XSD из вашего определения SDT можно найти по адресу https://github.com/Homegateway/SDTTool.

Еще две заметки:

• Допускает ли CSE самостоятельную специализацию , зависит от реализации и политик CSE.
• На момент написания статьи (апрель 2019 г.) oneM2M работает над новой версией SDT, которая поддерживает, например, определения продуктов, лучшее наследование и дальнейшую семантическую поддержку. oneM2M также работает над новой версией спецификации TS-0023 для поддержки междоменных сценариев и устройств IoT, а не только домашнего домена.