Skip to Content
架构Overview

架构

IronFlock是一个分布式系统,具有两个层级:在运营现场运行应用程序的自主边缘设备,以及提供车队范围数据存储、仪表板、AI和协调的中央服务。实时消息代理连接所有组件。

这既不是纯边缘平台,也不是纯云平台。两者兼备 — 架构设计使每个层级都能发挥其最佳优势。

系统如何协同工作

┌─────────────────────────────────────────────────────────┐ ┌──────────┐ │ 中央服务 │ │ 虚拟 │ │ │ │ 设备 │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────┐ │ │┌────────┐│ │ │ FleetDB │ │ Backend │ │ AI │ │ Web │ │ ││ Custom ││ │ │ Cluster │ │ Service │ │ Service │ │ UI │ │ ││ Service││ │ │(Timescale│ │ │ │ │ │ │ │ │└────────┘│ │ │ DB) │ │ │ │ │ │ │ │ │ Agent │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ └───┬────┘ │ └────┬─────┘ │ │ │ │ │ │ │ │ └─────────────┴──────┬──────┴────────────┘ │ │ │ │ │ │ │ ┌───────┴───────┐ │ │ │ │ WAMP Message ├────────────────────────────┘ │ │ Broker │ │ │ └───────┬───────┘ │ │ │ │ └────────────────────────────┼────────────────────────────┘ ┌──────────────┼─────────────┐ │ │ │ ┌───────┴──┐ ┌───────┴──┐ ┌──────┴───┐ │ Edge │ │ Edge │ │ Edge │ │ Device 1 │ │ Device 2 │ │ Device 3 │ │┌────────┐│ │┌────────┐│ │┌────────┐│ ││ Apps ││ ││ Apps ││ ││ Apps ││ ││(Docker)││ ││(Docker)││ ││(Docker)││ │└────────┘│ │└────────┘│ │└────────┘│ │ Agent │ │ Agent │ │ Agent │ └──────────┘ └──────────┘ └──────────┘

三个层级

1. 边缘设备 — 自主应用运行节点

边缘设备是IronFlock的核心执行节点。每个设备运行一个轻量级代理和一个或多个容器化应用程序(Docker)。设备是自主的:即使与中央服务断开连接也能继续运行,网络恢复时自动重新连接。

边缘设备可以是任何支持Linux的硬件 — Raspberry Pi、工业PC、NVIDIA Jetson、x86网关或自定义ARM板。

边缘设备上运行的内容:

  • IronFlock代理 — 管理设备生命周期,处理OTA更新,运行容器,维护与消息代理的连接
  • 您的应用程序 — 以任何编程语言部署为Docker容器。这些应用从PLC和传感器收集数据,运行控制逻辑,提供本地HMI,执行AI模型,或执行Linux应用程序能做的任何其他事情

边缘设备默认发起所有出站连接 — 无需打开入站端口。但是,设备端口可以在需要时选择性打开,例如暴露本地HMI或API端点。详见边缘设备与代理

2. 中央服务 — 车队范围的数据、UI和智能

中央层提供需要车队范围视图或持久基础设施的能力。每个中央服务都可以独立扩展 — 服务可以水平扩展以处理不断增长的车队,而不会相互影响:

  • FleetDB — 存储从设备收集的所有遥测数据的PostgreSQL/TimescaleDB数据库集群。每个项目获得自己的隔离数据库实例,具有专用表和凭证。集群架构支持跨项目的水平扩展。FleetDB处理时间序列存储、定时聚合,并作为仪表板和AI查询的数据后端。
  • 后端服务 — 管理设备、项目、应用、用户账户、发行版和所有车队级别操作。公开Web API并处理业务逻辑层。水平扩展以处理不断增加的API负载和设备注册。
  • FleetDB服务 — 处理来自设备的传入数据流,处理数据转换,向前端提供实时仪表板数据,管理告警评估。独立扩展以匹配数据采集量。
  • AI服务 — 编排AI代理对话,随着对话的发展动态添加和删除专业代理。路由自然语言查询,通过消息代理调用设备端函数,实时生成图表和分析。扩展以支持跨项目的并发AI对话。
  • Web UI — 基于浏览器的控制平面,运营人员在此管理车队、查看仪表板、配置告警、开发应用并与AI助手交互。
  • 容器注册中心 — 存储所有应用的Docker镜像,支持OTA部署到车队中的任何设备。随着应用目录增长,独立扩展存储和吞吐量。

中央服务可以在IronFlock云(由IronFlock管理)或您自己的基础设施上运行,用于本地部署。详见中央服务

3. 虚拟设备 — 自定义中央计算节点

除了物理边缘设备外,IronFlock还允许您配置虚拟设备 — 与物理车队一起加入项目的云托管计算节点。虚拟设备运行与物理设备相同的IronFlock代理,参与相同的消息路由,可以运行任何容器化应用程序。

虚拟设备的常见用途:

  • 运行需要车队范围视角的中央车队服务,如Grafana、Node-RED、Netdata或Jupyter
  • 托管从多个物理设备聚合数据的数据处理管道
  • 运行对边缘硬件来说计算量过大的AI推理服务
  • 作为协议桥接连接外部系统(SAP、ERP、云API)到您的IronFlock项目

虚拟设备不是一个单独的功能 — 它们是项目的完整参与者。它们出现在设备列表中,接收OTA更新,其应用通过相同的消息代理与边缘设备应用通信。

详见虚拟设备

消息代理 — 粘合剂

IronFlock中的所有组件通过中央WAMP(Web Application Messaging Protocol)消息代理进行通信。代理提供:

  • 实时发布/订阅消息 — 设备发布遥测数据,仪表板订阅实时数据,应用双向通信
  • RPC(远程过程调用) — AI服务调用设备端函数,后端触发设备上的容器操作,运营人员发送命令
  • 项目隔离 — 每个项目-应用组合获得自己的加密隔离消息领域。一个项目中的设备无法看到另一个项目的消息
  • 认证 — 到代理的每个连接都需要有效的凭证

消息代理使IronFlock成为一个分布式系统,而不是一组断开的部分。在中央云中运行的AI代理可以调用工厂车间物理设备上的函数 — 并实时获取结果 — 因为两者都连接到同一个代理。

详见消息代理(WAMP)

可扩展性与零停机更新

IronFlock架构的每个组件都为水平扩展而设计。后端、FleetDB、AI服务、消息代理和容器注册表可以各自独立扩展,以处理不断增长的设备车队、日益增加的数据量和更多的并发用户——而不会影响系统的其他部分。

现在所有系统组件均支持近乎零停机更新——几乎不会中断活动连接或数据流即可升级到新版本。集群化的消息代理是最后一个完成此切换的组件,因此整个平台现在几乎可以在不中断任何服务的情况下进行更新。

架构 vs. 传统SCADA

传统SCADA平台(Ignition、WinCC、Wonderware)遵循以网关为中心的模型:一个中央服务器完成所有工作 — 标签采集、历史存储、画面显示、告警处理和脚本。“边缘”只是向该中央服务器提供数据的PLC。

IronFlock将此颠倒。边缘设备是具有完整计算能力的自主应用运行节点。中央服务处理需要车队范围视图的内容:持久数据存储、仪表板、AI编排和车队管理。两个层级都不从属于另一个 — 它们是互补的。

方面传统SCADAIronFlock
边缘角色简单数据源(PLC → 网关)运行完整应用的自主计算节点
中央角色做所有事情(网关服务器)车队范围的数据、UI、AI和协调
应用部署中央网关上的模块边缘设备上的Docker容器
离线行为没有网关边缘停止工作边缘设备继续自主运行
扩展添加更多网关服务器添加更多边缘设备
通信从网关到PLC的轮询/OPC实时双向消息(WAMP)

部署选项

IronFlock的中央服务可以在三种配置下运行:

模式中央服务边缘设备使用场景
(默认)IronFlock托管云通过互联网连接大多数部署
Appliance现场预配置设备——同时可作为边缘设备通过本地网络连接设备制造商 / OEM
私有云您的 DMZ / VPC / 数据中心通过本地网络连接气隙隔离、受监管环境

三种模式的完整对比请参见部署选项

Last updated on