EdgeX Foundary 2.1Jakarta版官方文档中文翻译
基于机器翻译，部分翻译有修订，不清楚的地方请参阅官方文档。
引言
EdgeX Foundry是一个开源的、供应商中立的、灵活的、可互操作的、位于网络边缘的软件平台，与设备、传感器、执行器和其他物联网对象的物理世界进行交互。
简单地说，EdgeX是边缘中间件——服务于物理传感和驱动“事物”与我们的信息技术(IT)系统之间。
EdgeX平台能够并且鼓励快速增长的物联网解决方案提供商社区，在可互操作的组件生态系统中，合作，以减少不确定性，加快上市时间，以及促进规模。
通过引入这种急需的互操作性，EdgeX可以更容易地监控物理世界的终端设备，向它们发送指令，从它们收集数据，将数据跨雾（fog）移动到云，在云中，数据可以被存储、被聚合、被分析和被转换为信息，并被驱动、被执行执行。
因此，EdgeX可以使数据向北传输到云或企业，并返回到设备、传感器和执行器。
该倡议围绕着一个共同的目标:简化和标准化物联网市场中分层边缘计算架构的基础，同时仍能使生态系统提供显著的差异化增值。
如果你不需要进一步的描述，并想立即使用EdgeX，进入这个链接:入门指南。
用例
EdgeX Foundry最初是为支持工业物联网需求而构建的，如今已被用于各种用例，包括:
- 楼宇自动化——帮助管理共享的工作空间设施
- 石油/天然气-一个气体供应阀的闭环控制
- 零售-多传感器协调，以防止损失在销售点
- 水处理-监测和控制化学药剂投加
- 消费者物联网——开源HomeEdge项目正在使用EdgeX的元素作为其智能家庭平台的一部分
架构原则
EdgeX Foundry的整体架构遵循以下原则:
- EdgeX Foundry必须与平台无关，包括：
- 硬件(x86架构、ARM架构)
- 操作系统(Linux, Windows, MacOS，…)
- 分布(基于微服务，边缘、网关、雾、云， …)
- 部署/编排(Docker, Snaps, K8s, roll-your-own，…)
- 协议(北向或南侧协议)
- EdgeX Foundary必须非常灵活，体现在：
- 平台的任何部分都可以通过其他微服务或软件组件进行升级、替换或增强
- 允许服务根据设备能力和用例向上和向下扩展
- EdgeX Foundry应该提供“参考实现”服务，但鼓励最好的解决方案
- EdgeX Foundry必须提供存储和转发能力，体现在：
- 支持不连接/远程边缘系统
- 处理间歇性的连接
- EdgeX Foundry必须支持并促进“智能”向边缘移动，以为了解决：
- 驱动延迟问题
- 带宽和存储问题
- 远程操作问题
- EdgeX Foundry must support brown and green device/sensor field deployments
- EdgeX Foundary必须是安全的，易于管理
部署
EdgeX最初由戴尔(Dell)构建，用于在其物联网网关上运行。
虽然EdgeX可以在网关上运行，但它的平台无关性质和微服务架构，使它支持分层且分布式部署。
换句话说，EdgeX微服务的一个实例可以分布在多个主机平台上。
一个或多个EdgeX微服务的主机平台（host platform）称为节点。
这使得EdgeX可以利用边缘任何位置上的计算、存储和网络资源。
EdgeX Foundary的松耦合结构支持跨节点分布，从而支持分层边缘计算。
例如，物联通信服务可以在可编程逻辑控制器(programmable logic controller)、网关上运行，或者嵌入到更智能的传感器中，而其他EdgeX服务则部署在服务器甚至云上。
因此，部署位置可能包括嵌入式传感器、控制器、边缘网关、服务器和云系统。
EdgeX微服务可以在多个计算节点中选择部署，以最大化资源使用，同时将更多的处理智能放在靠近物理边缘的位置。
在给定节点上，部署特定微服务的数量和功能取决于实际用例、硬件能力、基础设施。
Apache 2 License
EdgeX是在Apache基金会支持的Apache 2许可证下发布的。
Apache 2许可对开放和商业利益都非常友好(“允许”)，允许用户为任何目的使用该软件。
架构
EdgeX Foundry是一组开源微服务的集合。
这些微服务被划分为四个服务层和两个底层系统服务。
四个服务层分别为：设备服务层、核心服务层、支撑服务层、应用服务层。
两个底层系统服务为：安全、系统管理。
设备服务层 （Device Services Layer）
设备服务将“物”（thing）——即传感器和设备——连接到EdgeX的其余部分。
设备服务是与“物”交互的边缘连接器，“物”包括但不限于: 警报系统，家庭和办公大楼的供暖和空调系统，任何工厂的灯和机器，灌溉系统，无人机，目前自动化的交通系统，如一些铁路系统，目前自动化的工厂，和家用电器。
未来，这可能包括无人驾驶汽车和卡车、交通信号、全自动快餐设施、全自动自助杂货店、从病人那里获取医疗数据的设备等。
设备服务可以同时服务一个或多个物体或设备(传感器、执行器等)。设备服务管理的设备可能不是简单的单个物理设备。
设备可以是另一个网关(以及该网关的所有设备)，一个设备管理器，一个作为设备的设备聚合器，或设备集合。
设备服务通过每个设备对象的本地协议与设备、传感器、执行器和其他物联网对象通信。
设备服务将物联网对象产生和通信的数据转换为公共的EdgeX Foundry数据结构，
并将转换后的数据发送到核心服务层，以及EdgeX Foundry其他层中的其他微服务。
EdgeX附带了许多设备服务，涉及许多常见的物联网协议，如Modbus、BACnet、MQTT等。
核心服务层 （Core Services Layer）
核心服务为EdgeX的南北向提供中间服务。
正如这些服务的名称所暗示的那样，它们是EdgeX功能的“核心”。
核心服务是EdgeX实例中保存大部分固有信息的地方，这些信息包括连接了什么“物”、流经了什么数据以及EdgeX是如何配置的。
核心由以下微服务组成:
- Core data: 用于保存从南侧对象收集的数据的持久化存储库，和相关管理服务。
- Command: 一种促进和控制从北侧向南侧的驱动请求的服务。
- Metadata: 连接到EdgeX Foundry的对象的元数据存储库，和相关管理服务。Metadata提供了供应新设备并将其与其所属的设备服务配对的功能。
- Registry and Configuration: 为其他EdgeX Foundry微服务提供信息，包括EdgeX Foundry中相关服务的信息、微服务配置属性(即初始化值)等。
核心服务提供事物和IT系统之间的中间通信。
支撑服务层 （Supporting Services Layer）
支持服务包括广泛的微服务，包括边缘分析(也称为本地分析)。
一般软件应用程序的职责，如调度程序、数据清理(在EdgeX中也称为scrubbing)，是由支持服务层中的微服务执行的。
这些服务通常需要一些核心服务才能正常工作。
在所有情况下，支持服务都可以被认为是可选的，也就是说，根据用例需求和系统资源，它们可以被排除在EdgeX的部署之外。
支持服务包括:
- 规则引擎（Rules Engine）: 边缘分析服务的参考实现，基于EdgeX实例收集的传感器数据，在边缘执行if-then条件驱动。该服务可被具体应用的分析功能所取代或增强。
- 调度器（Scheduler）: 一个内部的EdgeX“时钟”，可以启动任何EdgeX服务中的操作。在配置指定的时间，该服务将通过REST调用任何EdgeX服务API URL来触发一个操作。例如，调度器服务会周期性地调用核心数据api来清理已经成功导出出EdgeX的旧的感知事件。
- 警报和通知（Alerts and Notifications）: 为EdgeX服务提供一个中央设施来发送警报或通知。这些通知被发送到另一个系统或监视EdgeX实例的人员(内部服务通信通常被更直接地处理)。
应用服务层（Application Services Layer）
应用服务是一种从EdgeX提取、处理/转换和发送传感器收到的数据到用户选择的端点或进程的方法。
当前，EdgeX提供的应用服务示例可以将数据发送到许多主要的云提供商(Amazon IoT Hub、谷歌IoT Core、Azure IoT Hub、IBM Watson IoT…)，和MQTT(s)主题以及HTTP(s) REST端点。
应用程序服务基于“函数管道（function pipeline）”的思想。
函数管道是按指定顺序处理消息(即EdgeX中的事件消息)的函数的集合。
管道中的第一个函数是触发器。
触发器启动函数的流水线执行。
例如，触发器类似于消息队列中的消息着陆。
然后，每个函数对消息进行操作。
常用的函数包括过滤、转换(即转换为XML或JSON)、压缩和加密函数。
当消息通过所有函数并被设置为sink时，函数管道结束。
最好将产生的结果消息放入MQTT主题，以发送到Azure或AWS。
系统管理（System Management）
系统管理工具为外部管理系统提供中心点，以启动/停止/重新启动EdgeX服务，获取服务的状态，或获取EdgeX服务的指标(例如内存使用)，从而可以监视EdgeX服务。
安全（Security）
EdgeX Foundry的安全组件保护设备、传感器和其他由EdgeX Foundry管理的物联网设备的数据和控制。
EdgeX是一个“位于网络边缘的与供应商无关的开源软件平台”，基于这一事实，EdgeX的安全特性也建立在开放接口和可插拔、可更换模块的基础上。
有两个主要的EdgeX安全组件。
- 一个安全存储部件，用来提供一个安全的地方来保存EdgeX的机密，例如其他服务使用的数据库访问密码和和连接到云系统时的令牌。
- API网关作为反向代理来限制对EdgeX REST资源的访问，并执行访问控制相关的工作。
软件开发组件（Software Development Kits，SDKs）
EdgeX提供了两种类型的sdk来帮助创建南北向服务，特别是用于创建应用服务和设备服务。
北侧和南侧服务的sdk都为开发人员提供了处理服务基本操作的所有代码，从而使连接“物”或新的云/企业系统变得更容易。
因此，开发人员可以专注于他们与南侧或北侧对象的连接细节，而不用担心微服务的所有原始管道。
sdk是指定语言的;这意味着SDK是用来用特定的编程语言创建服务的。
当前，EdgeX提供了以下sdk:
- Golang Device Service SDK
- C Device Service SDK
- Golang Application Functions SDK
EdegeX 是如何工作的
感知数据收集
EdgeX的主要工作是收集来自传感器和设备的数据，并将这些数据提供给北部的应用程序和系统。
通过相应传感器设备的协议，数据由设备服务从传感器收集。
例如:一个Modbus设备服务将使用Modbus协同进行通信，从而从Modbus泵中获得压力数据。
设备服务将传感器数据转换为EdgeX事件对象，然后可以:
- 将事件对象放到消息总线上(通过Redis Streams或MQTT实现)，消息总线上事件消息的订阅者可以应用服务或Core data服务
- 通过REST通信将事件对象发送到Core data服务
当Core data接收到事件(通过消息总线或REST)时，它将传感器数据保存在本地边缘数据库中。
EdgeX使用Redis作为持久性存储。
这里有一个抽象允许用户使用另一个数据库。
持久性不是必需的，可以关闭。
数据被持久化在EdgeX的边缘有两个基本原因:
- 边缘节点并不总是连接的。在断开连接的操作期间，必须保存传感器数据，以便在连接恢复时可以向北传输。这被称为存储和转发能力。
- 在某些情况下，传感器数据的分析需要回顾历史，以便了解趋势并根据历史做出正确的决定。
当Core data通过REST从设备服务接收到事件对象时，它将把传感器数据事件放到一个消息主题上，发送给应用程序服务。
默认情况下，Redis Pub/Sub被用作通信基础设施。MQTT或ZMQ也可以用作核心数据和应用程序服务之间的通信基础设施。
应用服务根据需要转换数据，并将数据推送到端点。
在将事件发送到端点之前，它还可以对事件进行过滤、充实、压缩、加密或执行其他功能。
端点可以是HTTP/S端点、MQTT主题、云系统(云主题)等。
边缘分析和制动
在边缘计算中，简单地收集传感器数据只是边缘计算平台工作的一部分。边缘计算平台的另一个重要工作是:
- 在本地分析输入的传感器数据，即边缘分析
- 基于边缘分析，尽快根据所看到的情况触发操作
边缘分析非常重要，有两个原因:
- 有些决策不能等待传感器收集的数据反馈给企业或云系统并返回响应。
- 此外，一些边缘系统并不总是连接到企业或云，它们有间歇性的连接期。
局部分析允许系统独立运行，至少在一段时间内是这样。
例如:当船舶在海上时，集装箱的冷却系统必须能够在没有互联网连接的情况下进行本地决策。
当对系统操作至关重要时，局部分析还允许系统可以低时延地行动。
EdgeX的构建，是为了对从边缘收集的数据进行本地操作。
换句话说，事件是由本地分析处理的，可以用来触发传感器/设备上的动作。
因为应用服务需要准备数据以供北侧云系统或应用程序使用，应用服务可以处理和获取EdgeX事件(以及它们包含的传感器数据)到任何分析包。
默认情况下，EdgeX附带一个简单的规则引擎(默认的EdgeX规则引擎是eKuiper——一个开源的规则引擎，现在是LF Edge的一个姊妹项目)。
您自己的分析包(或ML代理)可以替换或扩充本地规则引擎。
该分析包可以探索传感器事件数据，并作出决定，以触发设备的驱动。
例如，它可以检查发动机的压力读数是否大于60 PSI。
当确定这样一个规则为真时，分析包调用核心命令服务来触发某些动作，比如在某些可控设备上“打开阀门”。
核心命令服务获取驱动请求，并确定需要对该请求进行操作的设备;然后调用自己的设备服务来执行驱动。核心命令允许开发人员在驱动之前放置额外的安全措施或检查。
设备服务接收驱动请求，将其转换为特定于协议的请求，并将请求转发到所需的设备。
项目发布节奏（Project Release Cadence）
项目历史和命名
