Question

我已经在this topic上讨论了如何在OneM2M中管理设备，但是我仍然感到有些误解。

MgmtObj 和 MgmtCmd 之间的关系。它们之间的确切关系是什么？似乎MgmtObj保持其状态，如当前的软件或固件，电池，设备信息等。ObjectId和ObjectPath用于将这些信息映射到设备管理标准，例如LWM2M，TR-0069。正确吗？
我不明白为什么 Node 具有多个重启对象在里面？
让我们假设一个节点上有多个不同的固件。每个固件控制硬件的不同部分。然后我想我应该为每个固件创建一个MgmtCmd，但是MgmtCmd怎么知道它与哪个固件（MgmtObj）有关？当我们查看OneM2M中的资源定义时，它们之间没有链接。实际上，这指向了我的第一个问题，即MgmtObj和MgmtCmd之间的关系，因为无论如何，当MgmtCmd运行并完成其工作时，则应该在相关的Node中更新相关的固件。
让我们假设我不会实现任何设备管理标准，例如TR-0069，LWM2M等。我们正在使用具有自己专有的设备管理方式的nonOneM2M设备。那么最简单的方法是什么？

我们的想法是，我们应该将一些设备管理逻辑添加到IPE（内部代理实体），该逻辑可以预订在任何相关MgmtCmds中发生的所有设备事件，例如更新其ExecEnabled状态和创建ExecInstance。然后，我们应该使用该ExecInstance通知IPE，然后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时，它包含子资源，例如

固件列表
软件列表
重启列表
等...

实际上，我只是举了一个例子，它不是一个真实的场景。我也试图理解为什么节点具有多个资源，例如重新启动，软件，即使deviceinfo看起来很奇怪。他们指的是什么？

<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>

-----------更多澄清------------------- ----------

顺便说一句，已经有关于deviceinfo的讨论。然后我认为他们选择了每个节点多个deviceInfo的方式，因为当前版本的OneM2M支持每个节点多个deviceInfo。我还好奇每个节点多次重启或固件的含义是什么？

Answer 1

要一一回答您的问题：

的特殊化包含实际的管理信息，或表示要管理的设备或节点的一个方面。这些专长中的一些可以定义“触发”属性，这些属性可以在节点上执行本地操作。如果更新了这样的属性，则该动作将在关联的设备上执行。
表示一种在节点或设备上执行远程命令或操作的方法。它提供了一种方法来实现专业化所没有的管理功能。它也可以用于通过oneM2M建立隧道管理功能，而不是对其进行抽象。
根据TS-0001的表9.6.18-1“ 资源的子资源”，资源应仅具有0或1个重启专用的子资源。
实际上，您在问题中还引用的XSD似乎是不正确的，因为它不反映书面规范（对于某些其他属性）。
此处的假设是固件是设备的基本且非模块化的软件堆栈或操作系统。您可以使用[软件]专业化来支持模块化OS体系结构，在该体系结构中，您可以在设备上安装适用于各种应用的“驱动程序”或软件包。这些软件包中的每一个都可以独立于固件进行管理。例如，TR-0069支持这种管理。
节点可以支持多种固件的原因是，设备可以存储多种固件版本或世代，并且您要支持此功能。当然，一次只能激活一个固件。
通常，您要做的是为专有协议定义和实现管理适配器。这将是一个IPE，它实现逻辑以在oneM2M管理资源和专有方面之间进行映射，并实现本地协议以与专有设备进行通信。

关于使用订阅和通知的问题：这取决于您的具体部署体系结构，但是可以肯定的是，使用订阅/通知将是实现此目的的一种有效方法。另一种方法是管理IPE轮询相关资源的更改，这通常会占用更多资源。

NonOneM2M设备的设备管理？

1 个答案: