EdgeX Foundry 关于/综述

原创
02/24 17:20
阅读数 68

本文提供了 EdgeX Foundry 定义、设计规范、工作原理、部署、实施、开源协议、服务层、版本发布和历史命名相关定义和内容。

EdgeX Foundry 在下面将统一简称为 EdgeX。

  • EdgeX Foundry 是什么
  • 用例
  • 架构原则
  • 实施/部署
  • 许可证 License
  • 服务层
  • SDK
  • 工作原理
  • 版本发布
  • 历史和命名

本文内容大部分来自官方文档:关于 EdgeX

EdgeX Foundry 是什么?

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

图像

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

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

该计划围绕一个共同目标:简化和标准化物联网市场中分层边缘计算架构的基础,同时仍然使生态系统能够提供显著的增值差异化产品和服务。

EdgeX Foundry 用例

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

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

EdgeX Foundry 架构原则

EdgeX Foundry 的构想遵循以下指导整体架构的原则:

  • EdgeX Foundry 必须与平台无关

    • 硬件(x86、ARM)
    • 操作系统(Linux、Windows、MacOS...)
    • 分配 (允许通过边缘、网关、雾中、云等处的微服务分配功能)
    • 部署/编排(Docker、K8s、自行部署,...)
    • 协议(北或南向协议)
  • EdgeX Foundry 必须极其灵活

    • 微服务化 - 平台的任何部分都可以通过其他微服务或软件组件进行升级、替换或增强
    • 灵活伸缩性 - 允许服务根据设备功能和用例进行扩展和缩减
  • EdgeX Foundry 应提供“参考实现”服务,但鼓励最佳解决方案

    • 设备驱动参考实现
    • 应用服务参考实现
  • EdgeX Foundry 必须提供存储和转发功能

    • 高度自治 - 支持断开连接/远程边缘系统
    • 断点续传 - 处理间歇性连接
  • EdgeX Foundry 必须支持并促进“智能”靠近边缘以解决

    • 驱动延迟问题
    • 带宽和存储问题
    • 远程操作问题
    • AI 集成问题
  • EdgeX Foundry 必须支持棕色和绿色设备/传感器现场部署

    • 棕色设备 - 边缘/物联网部署中的旧设备(节点、设备、传感器),通常使用旧协议
    • 绿色设备 -具有现代协议的新设
  • EdgeX Foundry 必须安全且易于管理

    • 独立安全模块 - 支持自身安全性管理
    • 零信任机制 - 适合于更多安全性高的场景

部署

EdgeX 最初由戴尔构建,用于在其物联网网关上运行。虽然 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 个服务层如下:

  • 核心服务层 - Core Services Layer
  • 支持服务层 - Supporting Services Layer
  • 应用服务层 - Application Services Layer
  • 设备服务层 - Device Services Layer

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

  • 安全 - Security
  • 系统管理 - System Management

核心服务层

图像

核心服务提供了 EdgeX 北向和南向之间的中介。正如这些服务的名称所暗示的,它们是 EdgeX 功能的“核心”。核心服务是关于哪些“事物”连接、哪些数据流经以及 EdgeX 如何配置的大多数固定知识都驻留在 EdgeX 实例中。核心由以下微服务组成:

  • 核心数据 - Core Data :持久存储库和相关管理服务,用于从南向对象收集的数据。
  • 命令 - Command :促进和控制从北向到南向的驱动请求的服务,这些命令存储在元数据中。
  • 元数据 - Metadata :有关连接到 EdgeX Foundry 的对象的元数据存储库和关联管理服务。元数据提供了配置新设备并将其与其拥有的设备服务配对的能力。
  • 注册表和配置 - Registry and Configuration :为其他 EdgeX Foundry 微服务提供有关 EdgeX Foundry 内关联服务和微服务配置属性(即初始化值存储库)的信息。

总结

核心服务提供事物 (OT) 与 系统 (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 主题和 HTTP REST 端点。

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

设备服务层

图像

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

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

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

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

EdgeX 附带多种设备服务,支持多种常见 IoT 协议,例如 Modbus、BACnet、MQTT、S7、ONVIF、SNMP 等。

系统服务层

安全基础设施

图像

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

EdgeX 有两个主要安全组件。

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

系统管理

图像

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

软件开发套件 (SDKs)

EdgeX 提供了两种类型的 SDK 来协助创建北向和南向服务,特别是创建应用程序服务和设备服务。用于北向和南向服务的 SDK 通过为开发人员提供负责服务基本操作的所有脚手架代码,使连接新事物或新的云/企业系统变得更容易。从而使开发人员能够专注于与南向或北向对象的连接细节,而无需担心微服务的所有原始管道。

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

  • Golang 设备服务 SDK(大部分设备服务
  • C 设备服务 SDK(少数设备服务
  • Golang 应用函数 SDK(目前有且只有 Golang 版本

EdgeX 的工作原理

传感器数据采集

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

  1. 将事件对象放在消息总线上(可以通过 Redis Streams 或 MQTT 实现)。消息总线上事件消息的订阅者可以是应用程序服务或核心数据或两者(参见下面的步骤 Step 1.1)。 图像

  2. 通过 REST 通信将事件对象发送到核心数据服务(请参阅步骤 Step 1.2)。 图像

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

  • 断点续传 - 边缘节点并不总是连接的。在断网运行期间,必须保存传感器数据,以便在连接恢复时可以向北传输。这称为存储和转发能力。
  • 历史参考 - 在某些情况下,传感器数据分析需要回顾历史,以便了解趋势并根据历史做出正确的决策。如果传感器报告现在温度为 30°C,您可能想知道十分钟前的温度是多少,然后再决定调整加热或冷却系统。如果温度为 40°C,您可能会认为十分钟前进行的降低室温的调整足以使房间降温。历史数据的背景对于本地分析决策非常重要。

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

图像

应用程序服务根据需要转换数据并将数据推送到端点。它还可以在将事件发送到端点之前对事件进行过滤、丰富、压缩、加密或执行其他功能(步骤 Step 3)。端点可以是 HTTP/S 端点、MQTT 主题、云系统(云主题)等。

图像

边缘分析和驱动

在边缘计算中,简单地收集传感器数据只是 EdgeX 等边缘平台工作的一部分。边缘平台的另一项重要工作是能够:

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

为什么边缘分析?本地分析很重要,原因有两个:

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

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

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

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

图像

分析包可以探索传感器事件数据并做出触发设备驱动的决定。例如,它可以检查发动机的压力读数是否大于 60 PSI。当确定这样的规则为真时,分析包会调用核心命令服务来触发某些操作,例如在某些可控设备上“打开阀门”(请参阅 ​​ 步骤 Step 5)。

图像

核心命令服务获取动作请求,并根据请求确定需要动作于哪个设备;然后调用所属设备服务来执行驱动(参见步骤 Step 6)。核心命令允许开发人员在启动之前采取额外的安全措施或检查。

图像

设备服务接收启动请求,将其转换为特定于协议的请求,并将请求转发到所需的设备(参见步骤 7)。

图像

项目发布节奏

通常,EdgeX 每年发布两次;一次在春天,一次在秋天。错误修复版本可能会更频繁地发生,请及时关注社区动态。每个 EdgeX 版本都有一个代号。代号遵循类似于 Android 的字母模式(代号按字母顺序排列: Barcelona, California, ...)。

每个版本的代号均以世界上的某个地理位置命名。命名 EdgeX 版本的荣誉授予被认为对该项目做出了重大贡献的社区成员。发行版也有版本号。发行版本遵循语义版本控制,以指示发行版的范围是主要还是次要。主要版本通常包含重要的新特性和功能,并且并不总是与先前版本向后兼容(例如:2.x 与 3.x 不完全兼容)。次要版本向后兼容,通常包含错误修复和较少的新功能。请参阅项目 Wiki,了解有关发布、版本和补丁的详细信息

下表是截止目前发稿时的版本情况:

版本发布 发布时间 版本
Barcelona Oct 2017 0.5.0
California Jun 2017 0.6.0
Delhi Oct 2018 0.7.0
Edinburgh Jul 2019 1.0.0
Fuji Nov 2019 1.1.0
Geneva May 2020 1.2.0
Hanoi November 2020 1.3.0
Ireland Spring 2021 2.0.0
Jakarta Fall 2021 2.1.0
Kamukura Spring 2022 2.2.0
Levski Fall 2022 2.3.0
Minnesota Jun 2023 3.0.0
Napa (当前最新版本) Nov 2023 3.1.0
Odessa (下一个版本) Apr 2024 3.2.0

注意

设备服务和应用程序服务(及其关联的 SDK)的次要版本可以单独发布。图形用户界面、命令行界面(CLI)等工具均可独立发布。

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

请参阅项目 Wiki,了解有关版本路线图

EdgeX 历史和命名

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

“Foundry”这个名称用于与 Cloud Foundry 进行比较。 EdgeX Foundry 旨在成为边缘解决方案的代工厂,就像 Cloud Foundry 是云中解决方案的代工厂一样。 Cloud Foundry 是由 VMWare 发起的(Dell Technologies 是 VMWare 的主要股东 - 回想一下,Dell Technologies 是 EdgeX 的原始创建者)。 EdgeX 中的“X”代表了平台的变革方面,允许将项目名称注册为商标并用于认证和认证标志等工作。

图像

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

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

图像

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部