架构
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编排和车队管理。两个层级都不从属于另一个 — 它们是互补的。
| 方面 | 传统SCADA | IronFlock |
|---|---|---|
| 边缘角色 | 简单数据源(PLC → 网关) | 运行完整应用的自主计算节点 |
| 中央角色 | 做所有事情(网关服务器) | 车队范围的数据、UI、AI和协调 |
| 应用部署 | 中央网关上的模块 | 边缘设备上的Docker容器 |
| 离线行为 | 没有网关边缘停止工作 | 边缘设备继续自主运行 |
| 扩展 | 添加更多网关服务器 | 添加更多边缘设备 |
| 通信 | 从网关到PLC的轮询/OPC | 实时双向消息(WAMP) |
部署选项
IronFlock的中央服务可以在三种配置下运行:
| 模式 | 中央服务 | 边缘设备 | 使用场景 |
|---|---|---|---|
| 云(默认) | IronFlock托管云 | 通过互联网连接 | 大多数部署 |
| Appliance | 现场预配置设备——同时可作为边缘设备 | 通过本地网络连接 | 设备制造商 / OEM |
| 私有云 | 您的 DMZ / VPC / 数据中心 | 通过本地网络连接 | 气隙隔离、受监管环境 |
三种模式的完整对比请参见部署选项。