none-oneM2M 设备的设备管理？

Question

我已经在this topic 上讨论过如何在 OneM2M 中管理设备，但我注意到我仍然存在一些误解。

1. MgmtObj 和 MgmtCmd 之间的关系。它们之间的确切相关性是什么？ MgmtObj 似乎保留了当前软件或固件、电池、设备信息等状态。ObjectIds 和 ObjectPaths 用于将这些信息映射到 LWM2M、TR-0069 等设备管理标准。对吗？

2. 我不明白为什么 Node 有多个重启对象 在里面？

3. 假设我们在一个节点上有多个不同的固件。每个固件控制硬件的不同部分。 然后我想我应该为每个固件创建一个 MgmtCmd 但是 MgmtCmd 如何知道 与哪个固件（MgmtObj）相关？当我们查看 OneM2M 中的资源定义时，它们之间没有联系。实际上，这指向了我的第一个问题，即 MgmtObj 和 MgmtCmd 之间的关系，因为不知何故，当 MgmtCmd 运行并完成其工作时，相关的固件应该在相关的 Node 中更新。

4. 假设我不打算实施任何设备管理标准，如 TR-0069、LWM2M 等。我们使用的是具有自己专有设备管理方式的 nonOneM2M 设备。那么最简单的方法是什么？

我们的想法是，我们应该将一些设备管理逻辑放入 IPE（Inter proxy entity），它可以订阅任何相关 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

一一回答你的问题：

1. 的特化保存实际管理信息或表示要管理的设备或节点的一个方面。其中一些特化可以定义可以在节点上执行本地操作的“触发器”属性。如果更新此类属性，则该操作将在相关设备上执行。
   表示在节点或设备上执行远程命令或操作的方法。它提供了一种实现 专业化不提供的管理功能的方法。它还可以通过 oneM2M 用于隧道管理功能，而不是对其进行抽象。

2. 根据 TS-0001，表 9.6.18-1“ 资源的子资源”， 资源应仅具有重新启动专业化的 0 或 1 个子资源。
   实际上，您在问题中也引用的 XSD 似乎不正确，因为它不反映书面规范（也适用于其他一些属性）。

3. 这里假设固件是设备的基本和非模块化软件堆栈或操作系统。您可以使用 [software] 专业化来支持模块化操作系统架构，您可以在其中安装“驱动程序”或设备上各种apsect 的软件包。这些软件包中的每一个都可以独立于固件进行管理。例如，TR-0069 就支持这种管理。
   一个节点可能支持多个固件的原因是一个设备可以存储多个固件版本或代，并且您希望支持此功能。当然，一次只有一个固件处于活动状态。

4. 一般来说，您要做的是为您的专有协议定义和实现一个管理适配器。这将是一个 IPE，它实现在 oneM2M 管理资源和专有方面之间映射的逻辑，以及实现与专有设备通信的本地协议。

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