none-oneM2M 设备的设备管理?

Device Management for none-oneM2M Devices?

我已经在 上讨论过如何在 OneM2M 中管理设备,但我发现我还有一些误解。

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

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

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

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

我们的想法是,我们应该将一些设备管理逻辑放入 IPE(Inter proxy entity)中,IPE 可以订阅在设备的任何相关 MgmtCmds 中发生的所有事件,例如更新其 ExecEnabled 状态和创建 ExecInstance .然后我们应该用那个 ExecInstance 通知 IPE,然后 IPE 管理所有过程。是否适合使用Subscription/Notification机制进行设备管理?

The mgmtCmd resource represents a method to execute management procedures or to model commands and remote procedure calls (RPC) required by existing management protocols (e.g. BBF TR-069 [i.4]), and enables AEs to request management procedures to be executed on a remote entity. It also enables cancellation of cancellable and initiated but unfinished management procedures or commands.

The mgmtObj resource contains management data which enables individual M2M management functions. It provides a general structure to map to external management technology e.g. OMA DM [i.5], BBF TR-069 [i.4] and LWM2M [i.6] data models. Each instance of mgmtObj resource shall be mapped to single external management technology.

-------------------------------- 澄清------ ------------------------

当我们查看节点的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的讨论了。然后我认为他们选择了每个节点多个设备信息的方式,因为当前版本的 OneM2M 支持每个节点多个设备信息。我也很好奇每个节点多次重启或固件的含义是什么?

一一解答您的问题:

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

  2. 根据 TS-0001,Table 9.6.18-1 "Child resources of <node> resource", 资源应只有 0 或 1 个重新引导特化的子资源。
    实际上,您在问题中也引用的 XSD 似乎不正确,因为它没有反映书面规范(也适用于其他一些属性)。

  3. 这里假设固件是基本的 non-modular 软件堆栈或设备的操作系统。您可以使用 [software] 专业化来支持模块化 OS 架构,您可以在其中安装 "drivers" 或设备上各种 apsects 的软件包。这些软件包中的每一个都可以独立于固件进行管理。比如TR-0069就支持这种管理。
    一个节点可能支持多个固件的原因是一个设备可以存储多个固件版本或世代,而你想要支持这个特性。当然,一次只能激活一个固件。

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

关于使用订阅和通知的问题:这取决于您的具体部署架构,但可以肯定的是,使用 subscriptions/notification 将是实现此目的的有效方法。另一种方法是管理IPE轮询相关资源的变化,一般来说是比较耗资源的。