Управление устройствами для устройств NonOneM2M?

Question

Управление устройствами для устройств NonOneM2M?

Я уже обсуждал, как управлять устройствами в OneM2M на эту тему, но заметил, что у меня все еще есть некоторые недоразумения.

Связь между MgmtObj и MgmtCmd. Какова точная корреляция между ними? Похоже, что MgmtObj сохраняет состояние, такое как текущее программное обеспечение или встроенное ПО в нем, батарея, информация об устройстве и т. Д. ObjectIds и ObjectPaths используются для отображения этой информации в стандарт управления устройствами, такой как LWM2M, TR-0069. Это правильно?
Я не понимаю, почему в Node есть несколько объектов перезагрузки?
Предположим, у нас есть несколько разных прошивок на узле. Каждая прошивка контролирует разные части оборудования. Тогда я думаю, что я должен создать MgmtCmd для каждой прошивки, но как MgmtCmd знает, с какой прошивкой (MgmtObj) она связана? Между ними нет никакой связи, когда мы смотрим на определение ресурса в OneM2M. На самом деле это указывает на мой первый вопрос, что отношения между MgmtObj и MgmtCmd, потому что каким-то образом, когда MgmtCmd запускается и завершает свою работу, то соответствующее программное обеспечение должно быть обновлено в связанном узле.
Предположим, что я не собираюсь внедрять какие-либо стандарты управления устройствами, такие как TR-0069, LWM2M и т. Д. Мы используем устройства не OneM2M, которые имеют собственный запатентованный способ управления устройствами. Тогда какой самый простой способ сделать это?

Мы подумали, что мы должны поместить некоторую логику управления устройствами в IPE(межпрокси-объект), который может подписаться на все события, которые происходят в любом связанном MgmtCmds для таких устройств, как обновление его состояния ExecEnabled и создание ExecInstance. Затем мы должны уведомить IPE с этим ExecInstance, тогда IPE управляет всей процедурой. Целесообразно ли использовать механизм подписки / уведомления для управления устройством?

Ресурс mgmtCmd представляет метод для выполнения процедур управления или для моделирования команд и удаленных вызовов процедур (RPC), требуемых существующими протоколами управления (например, BBF TR-069 [i.4]), и позволяет AE запрашивать выполнение процедур управления на удаленная сущность. Это также позволяет отменить отменяемые и инициированные, но незаконченные процедуры или команды управления.
Ресурс mgmtObj содержит данные управления, которые обеспечивают отдельные функции управления M2M. Он обеспечивает общую структуру для сопоставления с технологией внешнего управления, например, модели данных OMA DM [i.5], BBF TR-069 [i.4] и LWM2M [i.6]. Каждый экземпляр ресурса mgmtObj должен быть привязан к одной технологии внешнего управления.

-------------------------------- РАЗЪЯСНЕНИЕ ----------------- ---------------

Когда мы смотрим на xsd узла, он содержит дочерние ресурсы, такие как

Список прошивок
Список программ
Список перезагрузок
так далее...

На самом деле я только что привел пример, это не сценарий реального мира. Также я пытаюсь понять, почему узел имеет несколько таких ресурсов, как перезагрузка, программное обеспечение, даже если device info кажется странной. На что они ссылаются?

<xs:schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.onem2m.org/xml/protocols"
    xmlns:m2m="http://www.onem2m.org/xml/protocols" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    elementFormDefault="unqualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">

    <xs:include schemaLocation="CDT-commonTypes-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-memory-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-battery-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-areaNwkInfo-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-areaNwkDeviceInfo-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-firmware-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-software-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-deviceInfo-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-deviceCapability-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-reboot-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-eventLog-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-cmdhPolicy-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-activeCmdhPolicy-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-subscription-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-semanticDescriptor-v3_9_0.xsd" />
    <xs:include schemaLocation="CDT-transaction-v3_9_0.xsd"/>
    <xs:include schemaLocation="CDT-schedule-v3_9_0.xsd"/>

    <xs:element name="node" substitutionGroup="m2m:sg_announceableResource">
        <xs:complexType>
            <xs:complexContent>
                <!-- Inherit common attributes for announceable Resources -->
                <xs:extension base="m2m:announceableResource">
                    <!-- Resource Specific Attributes -->
                    <xs:sequence>
                        <xs:element name="nodeID" type="m2m:nodeID" />
                        <xs:element name="hostedCSELink" type="m2m:ID" minOccurs="0" />
                        <xs:element name="hostedAELinks" type="m2m:listOfM2MID" minOccurs="0" />
                        <xs:element name="hostedServiceLinks" type="m2m:listOfM2MID" minOccurs="0" />
                        <xs:element name="mgmtClientAddress" type="xs:string" minOccurs="0" />              
                        <xs:element name="roamingStatus" type="xs:boolean" minOccurs="0" />
                        <xs:element name="networkID" type="xs:string" minOccurs="0" />

                        <!-- Child Resources -->
                        <xs:choice minOccurs="0" maxOccurs="1">
                            <xs:element name="childResource" type="m2m:childResourceRef" minOccurs="1" maxOccurs="unbounded" />
                            <xs:choice minOccurs="1" maxOccurs="unbounded">
                                <xs:element ref="m2m:memory" />
                                <xs:element ref="m2m:battery" />
                                <xs:element ref="m2m:areaNwkInfo" />
                                <xs:element ref="m2m:areaNwkDeviceInfo" />
                                <xs:element ref="m2m:firmware" />
                                <xs:element ref="m2m:software" />
                                <xs:element ref="m2m:deviceInfo" />
                                <xs:element ref="m2m:deviceCapability" />
                                <xs:element ref="m2m:reboot" />
                                <xs:element ref="m2m:eventLog" />
                                <xs:element ref="m2m:cmdhPolicy" />
                                <xs:element ref="m2m:activeCmdhPolicy" />
                                <xs:element ref="m2m:subscription" />
                                <xs:element ref="m2m:semanticDescriptor" />
                                <xs:element ref="m2m:transaction" />
                                <xs:element ref="m2m:schedule" />
                            </xs:choice>
                        </xs:choice>
                    </xs:sequence>
                </xs:extension>
            </xs:complexContent>
        </xs:complexType>
    </xs:element>

----------------------- БОЛЬШЕ УТОЧНЕНИЯ ------------------------- ----

Кстати, уже есть обсуждение device info. Тогда я думаю, что они выбрали способ множественного deviceInfo на узел, потому что текущая версия OneM2M поддерживает несколько deviceInfo на узел. Мне также любопытно, что означает множественная перезагрузка или прошивка на узел?

4

onem2m onem2m-device-management

Источник

user735259 21 май '19 в 09:34

1 ответ

Решение

Другие вопросы по тегам onem2m onem2m-device-management

user4799 22 май '19 в 16:51 2019-05-22 16:51 · Accepted Answer · 2019-05-22 16:51

Чтобы ответить на ваши вопросы по одному:

Специализация содержит фактическую информацию управления или представляет аспект устройства или узла, которым нужно управлять. Некоторые из этих специализаций могут определять атрибуты "триггера", которые могут выполнять локальное действие на узле. Если кто-то обновит такой атрибут, то действие будет выполнено на соответствующем устройстве.
представляет метод для выполнения удаленной команды или действия на узле или устройстве. Он предлагает способ реализации функций управления, которые не предоставляются специализациями . Его также можно использовать для туннелирования функций управления через oneM2M, а не для его абстрагирования.
Согласно TS-0001, таблице 9.6.18-1 "Дочерние ресурсы ресурса <узел>", ресурс <узел> должен иметь только 0 или 1 дочерний ресурс специализации перезагрузки.
На самом деле кажется, что XSD, который вы также цитируете в своем вопросе, неверен, потому что он не отражает письменную спецификацию (также для некоторых других атрибутов).
Здесь предполагается, что прошивка - это базовый и немодульный программный стек или операционная система устройства. Вы можете использовать специализацию [программного обеспечения] для поддержки модульных архитектур ОС, где вы устанавливаете "драйверы" или пакеты для различных устройств на устройстве. Каждый из этих пакетов программного обеспечения может управляться независимо от прошивки. TR-0069, например, поддерживает этот вид управления.
Причина, по которой узел может поддерживать несколько прошивок, заключается в том, что устройство может хранить несколько версий или поколений прошивок, и вы хотите поддерживать эту функцию. Конечно, одновременно активна только одна прошивка.
В общем, вам нужно определить и внедрить адаптер управления для вашего проприетарного протокола. Это может быть IPE, в котором реализована логика для сопоставления между ресурсами управления oneM2M и собственными аспектами, а также для реализации локального протокола для связи с собственными устройствами.

На вопрос об использовании подписки и уведомлений: это зависит от конкретной архитектуры развертывания, но, безусловно, использование подписок / уведомлений будет эффективным способом реализации этого. Другой метод заключается в том, что IPE управления запрашивает изменения соответствующих ресурсов, что в целом является более ресурсоемким.