【问题标题】:Approaches on ingesting IoT data from cloud gateway从云网关摄取物联网数据的方法
【发布时间】:2017-07-19 07:35:46
【问题描述】:

我想听听您对 IoT 数据摄取案例的见解。在 AWS IoT 中心,事物影子是物理影子的虚拟表示。我从下图中了解到,每当事物通过消息代理向平台发送数据时,事物影子和规则引擎部分都会同时获取相同的传感器数据并进行处理。

我的结论正确吗?

  • Things 影子系统订阅了消息代理并获取传感器数据,更新其影子演员。影子端还负责存储传感器数据,例如事件溯源机制。
  • Thing Shadow 系统不执行任何规则,它仅用于执行事件溯源并在虚拟事物 Actor 中保持最后已知状态。
  • 相同的传感器数据也是规则引擎的入站数据。规则引擎只是处理流数据并决定如何处理流数据的 ECA(事件条件操作)类型系统。这意味着每个传入的数据最终都将在规则引擎部分进行处理。

【问题讨论】:

    标签: iot aws-iot stream-processing event-stream-processing


    【解决方案1】:

    以下是我对你的结论的看法。

    我从下图中了解到,每当一个事物发送一个 通过消息代理、事物影子和规则引擎将数据传输到平台 部分同时获取相同的传感器数据并进行处理。

    事物影子的变化可以触发在规则引擎中注册的动作。 specific topics 与您可以订阅规则引擎的事物影子相关联,以便执行一个或多个操作作为响应。

    Things shadow 系统订阅消息代理并获取传感器 数据,更新他们的影子演员。影子方也负责 存储传感器数据,例如事件溯源机制。

    您可以使用REST APIdedicated MQTT topics 更新设备影子以发布特定影子主题。正如您所说,影子本身并不构成事件源系统,而是与物理设备关联的数据模型的表示。

    但是,您可以创建一个规则来侦听一个或多个影子实例上的更改,并以时间序列方式将更改注册到 DynamoDB 中。然后,您将拥有一个事件源系统,允许您存储设备在任意时间内发送的先前状态或更改。

    事物影子系统不执行任何规则,它只是为了 执行事件溯源并在虚拟中保持最后已知状态 事物演员。

    Thing Shadow 将物理设备的所需状态和报告状态保留在云中。它不执行规则,而是在影子内发生事件时发出有关 MQTT 主题的消息。然后规则引擎可以捕获这些消息以执行操作。

    同样的传感器数据也是规则引擎的入站数据。规则 引擎只是和ECA(事件条件动作)类型的系统, 处理流数据并决定如何处理它们。这 意味着每个传入的数据最终都将在规则引擎中处理 部分。

    默认情况下,规则引擎不会侦听 MQTT 主题,因此不会侦听设备发送到设备网关的数据。您必须在规则引擎中注册您想收听的主题及其相关操作。

    除此之外,规则引擎允许您在ANSI SQL 中描述您的规则,这意味着您可以指定数据的来源(SQL 语句中的FROM)、JSON 中的特定字段您有兴趣捕获的有效负载 (SELECT),以及指定在什么条件下触发规则的可选条件 (WHERE)。

    侦听虚构主题 device/+/telemetry 并有兴趣捕获接收到的有效负载中的所有字段的规则示例如下:

    SELECT * FROM device/+/telemetry
    

    注意+ 可以用作例如任何设备标识符的占位符。

    【讨论】:

    • 感谢您的详细回答。我想知道如何存储规则 SQL 的一件事。在他们的影子里还是在规则引擎里?我假设所有 SQL 都保存在它们相关的事物阴影中。当影子接收到事件时,它会使用规则 SQL 向规则引擎发出事件。这是正确的吗?
    • 规则由 AWS 管理,它们的存储位置在此上下文中并不真正相关。规则其实跟影子没什么关系,跟 MQTT 主题有关,就是和规则引擎通信的接口。而影子恰好会针对这些主题发出事件,这就是您可以将影子与规则引擎集成的方式。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2023-04-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多