问题标签 [onem2m-device-management]

OneM2M 将设备管理分为两种不同的方法。

1-服务层上的设备管理

2-使用外部管理技术的设备管理

我想了解如何使用每种方法进行固件更新。但是，我只找到非常基本的示例，例如获取内存资源对象作为设备管理的示例。但是使用 <mgmtCmd> 和 <execInstance> 的用例是什么？有什么具体的例子可以分享吗？

我知道节点是实际的硬件设备，管理对象是代表管理功能和实体的资源。但我不明白 <mgmtCmd> 和 <mgmtObj> 之间的相关性。

假设我有一个设备(AE & Node)。它有一个固件信息，我将其作为 <mgmtObj> 保存在节点本身上。它还具有更新固件的 <mgmtCmd>。（我假设 MgmtCmd 是由 AE 创建的。我也不确定谁应该创建 <mgmtCmd>？我猜是相关的 AE。）

我应该如何通过选择上面描述的每种方法来运行 <mgmtCmd> ？我应该使用 TR-069 或 OMA-DM 或 LWM2M DM 之类的外部管理服务吗？或者，oneM2M 服务层上的设备管理是否足以做到这一点？

OneM2M 说 <execInstance> 资源是 <mgmtCmd> 的一个实例。如果我更新 <gmtCmd> 的execEnable属性，那么与该 <mgmtCmd> 相关的应该创建一个 <execInstance> 作为子资源。然后应该对该 <execInstance. 我对那部分也有一些困惑。更新 <mgmtCmd> 的 <execInstance> 属性是什么意思？我应该怎么做？如果我更新一次，如果我多次运行相同的命令，如何使用相同的值更新相同的属性。

如你所见，我真的很困惑。您能否简要解释一下并举一个明显的示例如何在 OneM2M 上进行设备管理（例如固件更新）？

我已经在这个主题上讨论了如何在 OneM2M 中管理设备，但我注意到我仍然存在一些误解。

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

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

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

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

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

mgmtCmd资源代表一种执行管理程序或对现有管理协议（例如 BBF TR-069 [i.4]）所需的命令和远程程序调用 (RPC)建模的方法，并使 AE 能够请求在其上执行管理程序一个远程实体。它还可以取消可取消和已启动但未完成的管理程序或命令。

mgmtObj资源包含启用单个 M2M 管理功能的管理数据。它提供了映射到外部管理技术的通用结构，例如 OMA DM [i.5]、BBF TR-069 [i.4] 和 LWM2M [i.6] 数据模型。mgmtObj资源的每个实例 都应映射到单一的外部管理技术。

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

当我们查看节点的 xsd 时，它包含子资源，例如

• 固件列表
• 软件列表
• 重启列表
• ETC...

其实我只是做了一个例子，它不是真实世界的场景。我还试图理解为什么节点有多个资源，比如重启、软件，即使 deviceinfo 看起来很奇怪。他们指的是什么？

------------------------ 更多说明 ------------------------- ----

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

我有一个将数据发送到 FTP 服务器的设备。在 OM2M 中，我想实现一个 IPE 来访问这些数据并将其发送到 MN-CSE。

目前我对 oneM2M 标准比较陌生，根据下面的参考资料，我找到了这个任务的 2 个替代方案。

1. ftp 服务器通知您的 AE（限制我们不对 FTP 服务器配置进行任何更改，因此我们无法采用这种方法）

2. 您的 AE 实现了 ftp 服务器，然后能够直接对新的数据事件做出反应。

在这里，我只想采用第二种方法，因此如果可能的话，我可以获得任何参考，以便我可以继续进行，因为我在 Internet 上找不到这样的文档。或者请提及是否有任何其他方法最适合此问题的 oneM2M 标准。

我只是想确认一下，如果我们定期监视 FTP 服务器以获取传入的输入文件，然后处理它们并将它们发送到 MN-CSE，那么这种方法是否适合 oneM2M 标准？

OneM2M：定期从 FTP 服务器获取设备数据的 IPE

在各种软件操作（ 、、& ）期间，software.installStatus和software.activeStatus应该如何表现？installuninstallactivatedeactivate

我可以看到，规范中绝对没有讨论这些字段，也没有迹象表明它们应该具有什么值，或者这些值应该何时改变。