# 本人声明：
# 1、翻译来自官方网站原文。仅做个人学习。
# 2、个人能力十分有限，借助了翻译工具并作了修改和备注【ps：xxx】，但仍只能满足个人理解使用，错误和漏洞百出，希望读者指正批评。
# 3、官网地址：[EdgeX Foundry Documentation](https://docs.edgexfoundry.org/2.4/)

介绍

边缘X 2.x

想知道 EdgeX 2.x 版本中有哪些新功能（爱尔兰/雅加达/等）？如果您已经熟悉 EdgeX，请在整个文档中查找 EdgeX 2.x 表情符号（- EdgeX 吉祥物），就像本页上概述最新 2.x 版本中新增功能的表情符号一样。这些部分将简要介绍文档每个区域中的新增功能。

EdgeX Foundry是一个开源，供应商中立，灵活，可互操作的软件平台。 网络边缘，与设备、传感器、执行器和其他物联网对象的物理世界进行交互。简单来说，EdgeX 是边缘中间件 - 服务于物理传感和执行“事物”与我们的信息技术 （IT） 系统之间。

EdgeX 平台支持并鼓励快速增长的社区、物联网解决方案提供商在可互操作的生态系统中协同工作 减少不确定性、加快上市时间的组件，以及促进规模化。

通过带来这种急需的互操作性，EdgeX 可以更轻松地监控物理世界项目、向它们发送指令、收集数据。 从他们那里，将数据穿过雾移动到可能所在的云中存储、聚合、分析并转化为信息、启动和采取行动。因此，EdgeX 使数据能够向北传输到云或企业，并返回设备、传感器和执行器。

该倡议围绕一个共同的目标保持一致：简化和分层边缘计算基础的标准化 物联网市场的架构，同时仍然支持 生态系统提供显著的增值差异化。

如果您不需要进一步说明并希望立即使用EdgeX Foundry使用此链接：入门指南

EdgeX Foundry用例

EdgeX 最初是为支持工业物联网需求而构建的，如今已用于各种用例，包括：

• 楼宇自动化 – 帮助管理共享工作空间设施
• 石油/天然气 – 供气阀的闭环控制
• 零售 – 多传感器对账，用于在销售点防止损失
• 水处理 – 监测和控制化学剂量
• 消费者物联网 - 开源HomeEdge项目正在使用EdgeX的元素作为其智能家居平台的一部分

EdgeX Foundry架构原则

EdgeX Foundry的构思遵循以下原则，指导 整体架构：

• EdgeX Foundry必须在以下方面与平台无关

  • 硬件（x86、ARM）
  • 操作系统（Linux，Windows，MacOS等）
  • 分配 （允许通过边缘、网关、雾中、云等的微服务分发功能）
  • 部署/编排（Docker，Snaps，K8s，自己滚动，...）
  • 协议（北侧或南侧协议）

• EdgeX Foundry必须非常灵活

  • 平台的任何部分都可以通过其他微服务或软件组件进行升级、替换或增强
  • 允许服务根据设备功能和用例进行扩展和缩减

• EdgeX Foundry应提供“参考实施”服务，但鼓励最佳解决方案

• EdgeX Foundry必须提供存储和转发功能

  • 支持断开连接/远程边缘系统
  • 处理间歇性连接

• EdgeX Foundry必须支持和促进“智能”向边缘靠拢，以解决

  • 致动延迟问题【ps:启动速度慢，导致延迟，边缘计算框架应该具有快速启动/重启，以实现快速从不可用状态，转换为可用状态】
  • 带宽和存储问题
  • 远程操作问题

• EdgeX Foundry必须支持棕色和绿色设备/传感器现场部署【ps:棕是指边缘/物联网部署中的较旧传统设备（节点、设备、传感器），通常使用较旧的协议。绿通常是指具有现代协议的新设备。】

• EdgeX Foundry必须安全且易于管理

部署

EdgeX最初由戴尔构建，用于在其物联网网关上运行。虽然 EdgeX 可以并且确实在网关上运行，但其平台不可知性和微服务架构支持分层分布式部署。换句话说，EdgeX 微服务的单个实例可以分布在多个主机平台上。一个或多个 EdgeX 微服务的主机平台称为节点。这使 EdgeX 能够利用计算、存储和网络资源，无论它们位于边缘的哪个位置。

其松散耦合的架构支持跨节点分布，以实现分层边缘计算。例如，物联网通信服务可以在可编程逻辑控制器 （PLC）、网关上运行，或者嵌入到更智能的传感器中，而其他 EdgeX 服务则部署在网络服务器甚至云中。因此，部署范围可能包括嵌入式传感器、控制器、边缘网关、服务器和云系统。

EdgeX 微服务可以部署在一系列计算节点上，以最大限度地利用资源，同时将更多的处理智能定位在更接近物理边缘的位置。部署在给定节点上的特定微服务的数量和功能取决于硬件和基础架构的用例和功能。

Apache 2 许可证

EdgeX在Apache基金会支持的Apache 2许可证下分发。Apache 2 许可对开放和商业利益非常友好（“宽容”）。它允许用户将该软件用于任何目的。它允许用户分发、修改甚至分叉代码库，而无需寻求创始项目的许可。它允许用户更改或扩展代码库，而无需为创始项目做出贡献。它甚至允许用户构建商业产品，而不必担心利润分享或版税回到Linux基金会或开源项目组织。

EdgeX Foundry服务层

EdgeX Foundry是开源微服务的集合。这些 微服务分为 4 个服务层和 2 个底层 增强系统服务。服务图层从 物理领域（从设备服务层）到 信息领域（应用服务层），以核心层和支持服务层为中心。

EdgeX Foundry的4个服务层如下：

• 核心服务层
• 支持服务层
• 应用服务层
• 设备服务层

EdgeX Foundry的2个底层系统服务如下：

• 安全
• 系统管理

核心服务层

核心服务提供 EdgeX 南北两侧之间的中介。正如这些服务的名称所暗示的那样，它们是 EdgeX 功能的“核心”。核心服务是将有关连接哪些“事物”、哪些数据流经以及如何配置 EdgeX 的大多数先天知识驻留在 EdgeX 实例中的地方。核心由以下微服务组成：

• 核心数据：从南侧对象收集的数据的持久性存储库和关联的管理服务。
• 命令：促进和控制从北侧到南侧的致动请求的服务。
• 元数据：有关连接到 EdgeX Foundry 的对象的元数据的存储库和关联的管理服务。元数据提供了预配新设备并将其与其拥有的设备服务配对的功能。
• 注册表和配置：为其他 EdgeX Foundry 微服务提供有关 EdgeX Foundry 和微服务配置属性（即初始化值存储库）中相关服务的信息。

核心服务提供事物和 IT 系统之间的中介通信。

支持服务层

支持服务包括广泛的微服务，包括边缘分析（也称为本地分析）。正常的软件应用程序职责，如调度程序和数据清理（在 EdgeX 中也称为清理）由支持服务层中的微服务执行。

这些服务通常需要一定数量的核心服务才能运行。在所有情况下，支持服务都可以被视为可选服务，也就是说，根据用例需求和系统资源，它们可以被排除在 EdgeX 部署之外。

配套服务包括：

• 规则引擎：参考实施边缘分析服务，根据 EdgeX 实例收集的传感器数据在边缘执行 if-then 条件驱动。此服务可以通过特定于用例的分析功能来替换或增强。
• 调度程序：一个内部 EdgeX“时钟”，可以在任何 EdgeX 服务中启动操作。在指定的配置时间，服务将通过 REST 调用任何 EdgeX 服务 API URL 以触发操作。例如，调度程序服务会定期调用核心数据 API，以清理已成功从 EdgeX 导出的旧检测事件。
• 警报和通知：为 EdgeX 服务提供发送警报或通知的中央设施。这些是发送到另一个系统或监视 EdgeX 实例的人员的通知（内部服务通信通常更直接地处理）。

应用服务层

应用程序服务是将检测到的数据从 EdgeX 提取、处理/转换并将发送到您选择的端点或进程的方法。如今，EdgeX 提供了应用程序服务示例，将数据发送到许多主要的云提供商（Amazon IoT Hub、Google IoT Core、Azure IoT Hub、IBM Watson IoT...）、MQTT（s） 主题和 HTTP（s） REST 端点。

应用程序服务基于“函数管道”的思想。函数管道是按指定顺序处理消息（在本例中为 EdgeX 事件消息）的函数集合。管道中的第一个函数是触发器。触发器开始执行函数管道。例如，触发器类似于消息队列中的消息。然后，每个函数对消息执行操作。常用功能包括过滤、转换（即转换为 XML 或 JSON）、压缩和加密功能。当消息通过所有函数并设置为接收器时，函数管道结束。将生成的消息放入要发送到 Azure 或 AWS 的 MQTT 主题中是接收器完成应用程序服务的示例。

设备服务层

设备服务将“事物”（即传感器和设备）连接到 EdgeX 的其余部分。

设备服务是与“事物”交互的边缘连接器，包括但不限于：警报系统、家庭和办公楼中的供暖和空调系统、照明、任何行业的机器、灌溉系统、无人机、当前自动化交通（例如某些铁路系统）、当前自动化工厂和家中的电器。未来，这可能包括无人驾驶汽车和卡车、交通信号灯、全自动快餐设施、全自动自助杂货店、从患者那里获取医学读数的设备等。

设备服务可以同时为一个或多个事物或设备（传感器、执行器等）提供服务。设备服务管理的设备可以是简单的单个物理设备以外的设备。该设备可以是另一个网关（以及该网关的所有设备）、设备管理器、充当 EdgeX Foundry 设备或设备集合的设备聚合器。

设备服务通过每个设备对象的本机协议与设备、传感器、执行器和其他 IoT 对象通信。设备服务将 IoT 对象生成和通信的数据转换为通用的 EdgeX Foundry 数据结构，并将转换后的数据发送到核心服务层，以及 EdgeX Foundry 其他层中的其他微服务。

EdgeX附带了许多设备服务，涉及许多常见的物联网协议，例如Modbus，BACnet，MQTT等。

系统服务层

安全基础架构 

EdgeX Foundry的安全元素保护由EdgeX Foundry管理的设备，传感器和其他物联网对象的数据和控制。基于EdgeX是“网络边缘的供应商中立开源软件平台”这一事实，EdgeX安全功能也建立在开放接口和可插拔、可更换模块的基础上。

有两个主要的 EdgeX 安全组件。

• 安全存储，用于提供保存 EdgeX 机密的安全位置。EdgeX 机密的示例包括其他服务和令牌用于连接到云系统的数据库访问密码。
• API 网关充当反向代理，用于限制对 EdgeX REST 资源的访问并执行访问控制相关工作。

系统管理 

系统管理设施为外部管理系统提供了中心联系点，以启动/停止/重新启动 EdgeX 服务、获取服务的状态/运行状况或获取有关 EdgeX 服务的指标（例如内存使用情况），以便可以监控 EdgeX 服务。

软件开发工具包 （SDK）

EdgeX 提供两种类型的 SDK 来帮助创建北侧和南侧服务，特别是创建应用程序服务和设备服务。北侧和南侧服务的 SDK 通过为开发人员提供负责服务基本操作的所有基架代码，使连接新事物或新的云/企业系统变得更加容易。因此，开发人员可以专注于他们与南侧或北侧对象的连接细节，而不必担心微服务的所有原始管道。

SDK 是特定于语言的;这意味着编写SDK是为了使用特定的编程语言创建服务。今天，EdgeX 提供以下 SDK：

• Golang 设备服务 SDK
• C 设备服务开发工具包
• Golang Application Functions SDK

EdgeX 的工作原理

传感器数据收集

EdgeX的主要工作是从传感器和设备收集数据，并将这些数据提供给北侧应用程序和系统。数据由说出该设备协议的设备服务从传感器收集。示例：Modbus 设备服务将在 Modbus 中进行通信，以获取来自 Modbus 泵的压力读数。设备服务将传感器数据转换为 EdgeX 事件对象。然后，设备服务可以：

1. 将事件对象放在消息总线上（可以通过 Redis 流或 MQTT 实现）。消息总线上事件消息的订阅者可以是应用程序服务或核心数据，也可以是两者（请参阅下面的步骤 1.1）。

   

2. 通过 REST 通信将事件对象发送到核心数据服务（请参阅步骤 1.2）。

   

当核心数据收到事件（通过消息总线或 REST）时，它会将传感器数据保留在本地边缘数据库中。EdgeX 使用 Redis 作为我们的持久性存储。有一个抽象允许您使用另一个数据库（过去允许使用其他数据库）。持久性不是必需的，可以关闭。数据在边缘的 EdgeX 中持久化有两个基本原因：

• 边缘节点并非始终连接。在断开连接的操作期间，必须保存传感器数据，以便在连接恢复时可以向北传输。这称为存储和转发功能。
• 在某些情况下，传感器数据分析需要回顾历史，以便了解趋势并根据该历史做出正确的决策。如果传感器报告现在是 72° F，您可能想知道十分钟前的温度是多少，然后再决定调整加热或冷却系统。如果温度为 85° F，您可能会决定降低十分钟前室温的调整足以冷却房间。历史数据的上下文对局部分析决策很重要。

当核心数据通过 REST 从设备服务接收事件对象时，它会将传感器数据事件放在发往应用程序服务的消息主题上。默认情况下，Redis 发布/订阅用作消息传递基础结构（步骤 2）。MQTT 或 NATS（在构建期间选择加入）也可以用作核心数据和应用程序服务之间的消息传递基础设施。

应用程序服务根据需要转换数据，并将数据推送到终结点。在将事件发送到终结点之前，它还可以对事件进行筛选、扩充、压缩、加密或执行其他功能（步骤 3）。终端节点可以是 HTTP/S 终端节点、MQTT 主题、云系统（云主题）等。

边缘分析和驱动

在边缘计算中，简单地收集传感器数据只是像 EdgeX 这样的边缘平台工作的一部分。边缘平台的另一个重要工作是能够：

• 在本地分析传入的传感器数据
• 根据该分析迅速采取行动 边缘或本地分析是对在边缘（“本地”）收集的传感器数据进行评估并根据其看到的内容触发驱动或操作的处理。

为什么选择边缘分析？本地分析很重要，原因有两个：

• 有些决策不能等待传感器收集的数据反馈到企业或云系统并返回响应。
• 此外，一些边缘系统并不总是连接到企业或云 - 它们具有间歇性的连接期。

本地分析允许系统独立运行，至少在一段时间内如此。例如：当船舶在海上时，集装箱的冷却系统必须能够在没有互联网连接的情况下在本地做出决策。本地分析还允许系统在对系统操作至关重要时以低潜在方式快速行动。作为一个极端的例子，想象一下，你的汽车的安全气囊是根据发送到云端并分析碰撞的数据而启动的。您的汽车具有本地分析功能，可防止在您的汽车中安全驱动的传递速度缓慢且容易出错。

EdgeX 旨在对从边缘收集的数据进行本地操作。换句话说，事件由本地分析处理，可用于触发传感器/设备上的操作。

正如应用程序服务准备数据以供北侧云系统或应用程序使用一样，应用程序服务可以处理 EdgeX 事件（及其包含的传感器数据）并将其获取到任何分析包（请参阅步骤 4）。默认情况下，EdgeX 附带一个简单的规则引擎（默认的 EdgeX 规则引擎是eKuiper——一个开源规则引擎，现在是 LF Edge 中的姊妹项目）。您自己的分析包（或 ML 代理）可以替换或扩充本地规则引擎。

分析包可以浏览传感器事件数据，并决定触发设备致动。例如，它可以检查发动机的压力读数是否大于 60 PSI。当确定此类规则为 true 时，分析包会调用核心命令服务来触发某些操作，例如在某些可控设备上“打开阀门”（请参阅步骤 5）。

核心命令服务获取致动请求，并确定需要对哪个设备执行请求操作;然后调用所属设备服务来执行启动（请参阅步骤 6）。核心命令允许开发人员在启动之前采取额外的安全措施或检查。

设备服务接收自动请求，将其转换为特定于协议的请求，并将请求转发到所需设备（请参阅步骤 7）。

项目发布节奏

通常，EdgeX 每年发布两次;春天一次，秋天一次。错误修复版本可能会更频繁地发生。每个 EdgeX 版本都有一个代码名称。代码名称遵循类似于 Android 的字母模式（代码名称按字母顺序排列）。

每个版本的代号都以世界上的某个地理位置命名。命名 EdgeX 版本的荣誉授予被认为对项目做出重大贡献的社区成员。版本还具有版本号。发布版本遵循语义版本控制，以指示版本在范围内是主要版本还是次要版本。主要版本通常包含重要的新特性和功能，并不总是向后兼容以前的版本。次要版本向后兼容，通常包含错误修复和较少的新功能。有关版本、版本和补丁的更多信息，请参阅项目 Wiki。

发行	时间	版本
Barcelona	2017年10月	0.5.0
California	2017 年 6 月	0.6.0
Delhi	2018年10月	0.7.0
Edinburgh	2019 年 7 月	1.0.0
Fuji	2019年11月	1.1.0
Geneva	2020年5月	1.2.0
Hanoi	2020年11月	1.3.0
Ireland	2021年春季	2.0.0
Jakarta	2021年秋季	2.1.0
Kamukura	2022年春季	待定
Levski	2022年秋季	待定

注意：设备服务和应用程序服务（及其关联的 SDK）的次要版本可以独立发布。图形用户界面、命令行界面 （CLI） 和其他工具可以独立发布。

EdgeX 社区成员在发布时召开会议，以计划下一个版本并规划未来版本的路线图。

有关发布和路线图的更多详细信息，请参阅项目 Wiki。

边缘X 2.0

爱尔兰发布

爱尔兰版本于 2021 年 6 月发布，是 EdgeX 的第二个主要版本。2.0 版本的亮点包括：

• 一组新的和改进的服务API，消除了大量的技术债务，并为EdgeX未来的新功能（例如允许更多基于消息的通信）做好准备
• 通过消息总线将设备服务直接连接到应用程序服务通信（如果需要，绕过核心数据或允许其成为辅助订阅者）
• 简化的设备配置文件
• 提高安全性
• 新的、改进的和更全面的图形用户界面（用于开发和演示目的）
• 针对 CoAP、GPIO 和 LLRP（RFID 协议）的新设备服务
• LLRP 库存应用程序服务
• 改进了应用程序服务能力和功能（包括新的过滤器功能）
• 更简洁/更简单的 Docker 映像命名和创建自定义 Docker 撰写文件的工具

EdgeX 2.0 为采用者提供了一个平台

• 具有改进的 API，可满足当今和未来的边缘应用程序需求
• 更高效、更轻便（取决于用例）
• 更可靠，提供更好的服务质量（更少的REST，更多的消息传递和合并许多错误修复）
• 消除了4年积累的大量技术债务

EdgeX 历史和命名

EdgeX Foundry最初是由戴尔物联网营销部门特许的一个项目，由首席技术官的戴尔客户办公室开发，于2015年7月作为一个名为Project Fuse的孵化项目。它最初创建的目的是作为物联网软件应用程序在戴尔的物联网网关入门系列上运行。 戴尔于 2017 年 4 月 24 日通过 Linux 基金会将该项目引入开源领域。 EdgeX在2017年汉诺威工业博览会上正式宣布并展示。汉诺威工业博览会是世界上最大的工业贸易展览会之一。在展会上，Linux基金会还宣布了50个创始成员组织（EdgeX生态系统）的协会，以帮助进一步推进项目和创建通用边缘平台的目标。

“Foundry”这个名字被用来与Cloud Foundry相提并论。EdgeX Foundry旨在成为边缘解决方案的代工厂，就像Cloud Foundry是云解决方案的代工厂一样。Cloud Foundry由VMWare发起（戴尔科技集团是VMWare的主要股东 - 回想一下，戴尔科技是EdgeX的原始创建者）。EdgeX 中的“X”代表了平台的转型方面，并允许项目名称注册商标并用于认证和认证标志等工作。

EdgeX Foundry徽标代表了其作为物理OT世界和数字IT世界之间转型引擎的角色的性质。

EdgeX社区在项目开始时选择章鱼作为该项目的吉祥物或“精神动物”。它的八个臂和臂上的吸盘代表传感器。传感器将数据带入章鱼。实际上，章鱼在某种程度上有九个大脑。它每只手臂都有数百万个神经元;在每个手臂中充当迷你大脑。章鱼的手臂充当“本地分析”，就像EdgeX提供的一样。吉祥物被社区亲切地称为“Edgey”。