OneM2M中的执行器控制

Question

我阅读了有关在OneM2M中进行双向通信的文档。我知道一种方法是使用订阅和通知系统。假设我们有一个类似下图的示例。 IN-AE（智能手机）要打开ADN-AE2的灯。假定注册和资源创建已经完成，并且ADN-AE-2也已经订阅了ADN-AE-2中的一个灯光容器。

因此，oneM2M涵盖了IN-AE如何发送灯光控制请求以及ADN-AE-2或ADN-AE-1如何接收并执行来自IN-AE的请求的部分。但是，如果ADN-AE-2无法控制光并且在控制光时发生故障怎么办。应该是什么情况？已经使用IN-AE发送的请求创建了内容实例。

1- ADN-AE-2是否应该创建另一个内容实例，它是容器的先前状态

2- ADN-AE-2是否应删除未执行的contentinstance（然后其他接收通知并成功执行该通知的订户如何处理）

如果执行器无法执行操作，推荐的方法是什么？

http://www.onem2m.org/tr-0034/procedures/actuator-switch-control

Answer 1

这是异步通信中的一个普遍问题。当接收方从不接收命令或无法执行命令（由于某种原因（例如，它正忙于做其他事情或请求超出某些参数））时，会发生什么情况？

这两个选项均有效，但在ADN脱机时将不起作用，因此ADN-AE2无法执行该过程。同样，即使当ADN始终在线时，当还有多个要控制ADN-AE2的AE或IN-AE不耐烦地一次又一次地设置所需状态时，这两个过程也会出现问题。这通常可能导致比赛条件。

我建议重新考虑两个AE之间的通信方案，并将原始容器分为两个：一个用于 target 状态的容器，另一个用于状态的容器状态。除ADN-AE2之外，AE还使用 target 容器设置所需的状态。 ADN-AE2将收到有关新ContentInstance创建的通知，并据此采取行动。然后，它在 state 容器中创建一个反映新内部状态的新ContentInstance，这将通知IN-AE反映更改。

下图反映了此模式的示例资源结构：

AE ─┬─ Container_target ─── ContentInstances*   ◀═══ Container for desired state, set by other AEs
    │                                      
    └─ Container_state ─── ContentInstances*    ◀═══ Container for actual state, set only by this AE

这是异步通信中的一种常见模式，当节点之间的连接性不总是可靠时，或者状态转换请求的结果不总是得到保证时。 ADN-AE2负责执行请求，IN-AE负责重试失败次数或做出反应的策略。