EdgeX 工作原理
大致过程
边缘计算平台EdgeX的传感器数据收集和边缘分析驱动的过程大致如下：
在传感器数据收集方面，EdgeX通过设备服务从传感器和设备中收集数据，并将其提供给应用程序和系统。设备服务根据设备协议与传感器通信，并将传感器数据转换为EdgeX事件对象。这些事件对象可以通过消息总线（如Redis流或MQTT）发布给订阅者，也可以通过REST通信发送给核心数据服务。核心数据服务接收到事件后，将传感器数据保存在本地边缘数据库中，以实现存储和转发功能，并提供历史数据的上下文供分析决策使用。
在边缘分析和驱动方面，EdgeX能够在本地对传入的传感器数据进行分析，并根据分析结果迅速采取行动。本地分析的重要性在于某些决策不能等待数据传输到企业或云系统并返回响应，以及一些边缘系统具有间歇性的连接期。通过本地分析，系统可以在边缘独立运行，并能够快速作出关键决策。EdgeX支持应用程序服务处理事件，并可以使用内置的规则引擎（如eKuiper）或自定义的分析包来进行本地分析。分析包可以根据传感器事件数据触发设备操作，例如根据压力读数来打开阀门。核心命令服务接收到触发请求后，确定需要执行请求操作的设备，并调用相应的设备服务来执行启动。
总的来说，EdgeX 通过传感器数据收集和边缘分析驱动的方式，实现了对边缘节点的数据处理和决策能力，从而提高了边缘计算的效率和灵活性。
稍微详细点如下
EdgeX 的主要工作是从传感器和设备收集数据，并将这些数据提供给上层应用程序和系统。数据的收集由设备服务负责，根据设备的协议与传感器进行通信。通过这个工作流程，EdgeX 实现了从设备到应用程序的数据流动和处理，使得边缘计算环境下的数据收集、存储和应用变得更加灵活和可扩展。
以下是传感器数据收集方面的总结：
设备服务收集传感器数据并将其转换为EdgeX事件对象。
设备服务可以通过消息总线（如Redis流或MQTT）将事件对象发布到消息总线上，供应用程序服务或核心数据服务订阅（步骤1.1）。另外，设备服务也可以通过REST通信将事件对象发送给核心数据服务（步骤1.2）。
核心数据服务接收到事件后，将传感器数据存储在本地边缘数据库中（默认使用Redis作为持久性存储）。这样做的原因包括边缘节点可能断开连接，需要存储数据以便在连接恢复时传输，以及某些情况下需要回顾历史数据进行分析和决策。
核心数据服务将传感器数据事件发布到消息主题上，以便发送给应用程序服务。默认情况下，使用Redis发布/订阅作为消息传递基础设施，但也可以选择使用MQTT或NATS。
应用程序服务根据需要对数据进行转换、过滤、扩充、压缩、加密等处理，并将数据推送到终端节点。终端节点可以是HTTP/S终端节点、MQTT主题、云系统等。
在边缘计算中，除了简单地收集传感器数据外，边缘平台如EdgeX还具备本地分析的能力。本地分析是指对在边缘收集的传感器数据进行评估，并根据分析结果触发相应的处理或操作。
选择进行边缘分析的原因有两个：
某些决策需要即时采取行动，不能等待传感器数据传输到企业或云系统并返回响应。
某些边缘系统具有间歇性的连接，不总是与企业或云系统保持连接。
本地分析允许系统在一定时间内独立运行。例如，在海上的船舶上，集装箱的冷却系统必须能够在没有互联网连接的情况下做出决策。本地分析还使得系统能够快速采取行动，特别是在对系统操作至关重要的情况下。举个例子，想象一下，如果您的汽车的安全气囊需要等待数据发送到云端并进行分析才能触发，那么启动安全气囊的速度可能会很慢，容易出错。
EdgeX旨在对从边缘收集的数据进行本地分析和操作。换句话说，事件由本地分析处理，并可用于触发传感器或设备上的操作。
应用程序服务可以处理EdgeX事件和其中包含的传感器数据，就像它们为北侧云系统或应用程序准备数据一样。EdgeX默认附带一个简单的规则引擎（eKuiper），您也可以替换或扩展使用自己的分析包（或机器学习代理）。
分析包可以浏览传感器事件数据，并根据需求触发设备操作。例如，它可以检查发动机的压力读数是否超过60 PSI。当满足这样的规则时，分析包可以调用核心命令服务来触发某些操作，例如在可控设备上"打开阀门"。
核心命令服务接收到触发请求后，确定需要对哪个设备执行操作，并调用相应的设备服务来执行操作。
设备服务接收到触发请求后，将其转换为特定协议的请求，并将请求发送到目标设备。
官网翻译
传感器数据收集 Sensor Data Collection
EdgeX的主要工作是从传感器和设备收集数据，并将这些数据提供给北侧应用程序和系统。数据由说出该设备协议的设备服务从传感器收集。
示例：Modbus 设备服务将在 Modbus 中进行通信，以获取来自 Modbus 泵的压力读数。设备服务将传感器数据转换为 EdgeX 事件对象。然后，设备服务可以：
将事件对象放在消息总线上（可以通过 Redis 流或 MQTT 实现）。消息总线上事件消息的订阅者可以是应用程序服务或核心数据，也可以是两者（请参阅下面的步骤 1.1）。
通过 REST 通信将事件对象发送到核心数据服务（请参阅步骤 1.2）。
当核心数据收到事件（通过消息总线或 REST）时，它会将传感器数据保留在本地边缘数据库中。EdgeX 使用 Redis 作为我们的持久性存储。有一个抽象允许您使用另一个数据库（过去允许使用其他数据库）。持久性不是必需的，可以关闭。
数据在边缘的 EdgeX 中持久化有两个基本原因：
边缘节点并非始终连接。在断开连接的操作期间，必须保存传感器数据，以便在连接恢复时可以向北传输。这称为存储和转发功能。
在某些情况下，传感器数据分析需要回顾历史，以便了解趋势并根据该历史做出正确的决策。如果传感器报告现在是 72° F，您可能想知道十分钟前的温度是多少，然后再决定调整加热或冷却系统。如果温度为 85° F，您可能会决定降低十分钟前室温的调整足以冷却房间。历史数据的上下文对局部分析决策很重要。
当核心数据通过 REST 从设备服务接收事件对象时，它会将传感器数据事件放在发往应用程序服务的消息主题上。默认情况下，Redis 发布/订阅用作消息传递基础结构（步骤 2）。MQTT 或 NATS（在构建期间选择加入）也可以用作核心数据和应用程序服务之间的消息传递基础设施。
应用程序服务根据需要转换数据，并将数据推送到终结点。在将事件发送到终结点之前，它还可以对事件进行筛选、扩充、压缩、加密或执行其他功能（步骤 3）。终端节点可以是 HTTP/S 终端节点、MQTT 主题、云系统（云主题）等。
边缘分析和驱动 Edge Analytics and Actuation
在边缘计算中，简单地收集传感器数据只是像 EdgeX 这样的边缘平台工作的一部分。边缘平台的另一个重要工作是能够：
在本地分析传入的传感器数据
根据该分析迅速采取行动 边缘或本地分析是对在边缘（“本地”）收集的传感器数据进行评估并根据其看到的内容触发驱动或操作的处理。
为什么选择边缘分析？本地分析很重要，原因有两个：
有些决策不能等待传感器收集的数据反馈到企业或云系统并返回响应。
此外，一些边缘系统并不总是连接到企业或云 - 它们具有间歇性的连接期。
本地分析允许系统独立运行，至少在一段时间内如此。例如：当船舶在海上时，集装箱的冷却系统必须能够在没有互联网连接的情况下在本地做出决策。本地分析还允许系统在对系统操作至关重要时以低潜在方式快速行动。作为一个极端的例子，想象一下，你的汽车的安全气囊是根据发送到云端并分析碰撞的数据而启动的。您的汽车具有本地分析功能，可防止汽车中安全致动器的速度可能缓慢且容易出错。
EdgeX 旨在对从边缘收集的数据进行本地操作。换句话说，事件由本地分析处理，可用于触发传感器/设备上的操作。
正如应用程序服务准备数据以供北侧云系统或应用程序使用一样，应用程序服务可以处理 EdgeX 事件（及其包含的传感器数据）并将其获取到任何分析包（请参阅步骤 4）。默认情况下，EdgeX 附带一个简单的规则引擎（默认的 EdgeX 规则引擎是 eKuiper —— 一个开源规则引擎，现在是 LF Edge 中的姊妹项目）。您自己的分析包（或 ML 代理）可以替换或扩充本地规则引擎。
分析包可以浏览传感器事件数据，并决定触发设备致动。例如，它可以检查发动机的压力读数是否大于 60 PSI。当确定此类规则为 true 时，分析包会调用核心命令服务来触发某些操作，例如在某些可控设备上“打开阀门”（请参阅步骤 5）。
核心命令服务获取致动请求，并确定需要对哪个设备执行请求操作;然后调用所属设备服务来执行启动（请参阅步骤 6）。核心命令允许开发人员在启动之前采取额外的安全措施或检查。
设备服务接收致动请求，将其转换为特定于协议的请求，并将请求转发到所需设备（请参阅步骤 7）。
