# 工业边缘网关 / SCADA 架构模板

> **代表产品 / 原型**:工厂 SCADA 监控系统、车间数采网关、EdgeX Foundry;协议代表 OPC UA、Modbus
> **一句话定位**:站在 OT(车间)与 IT(机房)的边界上,把物理世界翻译成数据送上云——同时保证**无论云怎么挂,产线都照转、报警都照响**。

---

## 1. 一句话定位

工业边缘 = **一个「两个世界的翻译官 + 断网也能自治的小脑」**。

它的左边是 OT 世界:PLC、传感器、仪表,协议古老(Modbus 诞生于 1979 年)、设备寿命 20 年、**稳定压倒一切**;右边是 IT 世界:云、大数据、AI 预测性维护,**快速迭代、拥抱变化**。这两个世界的价值观完全相反,边缘网关就是它们之间唯一的、被严格管制的过境口岸。

## 2. 业务本质:它在解决什么问题

工厂的痛:设备在赚钱,但**它们是哑巴**——产量多少、什么时候要坏、能耗去哪了,全靠老师傅巡检和 Excel。数字化的第一步永远是「把数据采上来」。

但工业的账和互联网不一样:**停产一小时 = 几十万真金白银;安全事故 = 人命**。所以任何数字化改造的第一约束是「**不能碰坏正在赚钱的东西**」。这决定了整个架构的姿态:对 OT 侧只读为主、轻拿轻放;智能和迭代都放在边缘及以上,离产线越远越自由。

## 3. 核心需求与约束

**功能性需求:**
- [ ] 南向采集:对接 PLC / 传感器 / 仪表的各种协议(Modbus、OPC UA、专有协议…)
- [ ] 协议归一:把异构数据翻译成统一模型(点位 → 测点 → 设备)
- [ ] 边缘实时处理:阈值报警、操作级响应、本地看板(安全联锁属 PLC / 安全仪表系统,不在网关,见第 5 节)
- [ ] 存储转发:断网时本地缓存,恢复后补传
- [ ] 北向上云:时序数据 → 云端分析 / 预测性维护
- [ ] (受控的)反向控制:远程调参、启停——带审批与联锁

**非功能性需求 / 质量属性:**
| 质量属性 | 目标 | 为什么对这类系统重要 |
|---|---|---|
| **产线无扰** | 采集不影响控制系统 | 把 PLC 问卡了 = 数字化项目变事故 |
| **报警实时性** | 毫秒~秒级,且不依赖云 | 超温报警等云绕一圈,炉子已经炸了 |
| **断网自治** | 断云数天照常运转 | 工厂网络不稳定是常态,不是异常 |
| **数据不丢** | 断网期间数据补传 | 能耗 / 质量数据断一段,报表和追溯就废了 |

**关键约束(不可逾越的边界):**
- 🔴 **OT 设备动不得**:PLC 程序是供应商的、改一次要停产验证;20 年老设备只有串口。
- 🔴 **协议极度异构**:一个车间十种协议、几套私有变种是常态。
- 🔴 **OT 网络与 IT 网络必须隔离**:这是安全红线(见第 10 节),连接只能由内向外发起、经 DMZ 受控通道。
- 🔴 **现场环境恶劣**:高温、粉尘、电磁干扰,边缘硬件必须工业级,还要无人值守。

## 4. 架构全景图

```
 IT / 云端            ┌────────────────────────────────┐
 (自由迭代区)          │ 云:时序数据湖 / 看板 / 预测性维护  │
                      └──────────────▲─────────────────┘
                                     │ 仅出站连接(边缘主动推)
 ═══════ DMZ / 受控边界(连接只出不进、控制难下)═══════════
                                     │
 边缘层               ┌──────────────┴─────────────────┐
 (断网自治区)          │ 边缘网关(工业级硬件,可集群)       │
                      │  · 统一数据模型(点位→测点→设备)   │
                      │  · 实时规则:阈值报警(本地闭环!)   │
                      │  · 本地时序缓存 + 断点续传         │
                      │  · 本地 HMI 看板(断云也能看)      │
                      └──┬────────┬────────┬────────────┘
                         │南向适配器(每协议一个插件)
                    ┌────┴───┐ ┌──┴─────┐ ┌┴─────────┐
 OT / 车间           │ OPC UA │ │ Modbus │ │ 私有协议… │
 (稳定压倒一切)       └────┬───┘ └──┬─────┘ └┬─────────┘
                         ▼        ▼        ▼
                    PLC / 传感器 / 仪表 / 机器人(物理世界)
```

> 灵魂在于:**报警在边缘本地闭环,云只做「事后聪明」**(分析、预测、优化)。凡是「晚了会出事」的逻辑,一律不许跨过那条 DMZ 边界。再往下还有一层:**真正的安全联锁 / 紧急停机在 PLC 和安全仪表系统(SIS)里,那是安全认证设备的地盘,数采网关无权也不应染指**——边缘的职责是「看得见、叫得响」,不是「替 PLC 踩刹车」。
>
> 另注:图中「边缘网关」画成一个盒子是教学简化;实际部署常拆两截——采集侧在控制 / 生产网(L2/L3),北向转发侧在 DMZ(L3.5),对应第 10 节的 Purdue 分层。

## 5. 组件职责

- **南向协议适配器**:每种协议一个插件,负责采集与(受控的)写入。*为什么需要*:异构协议是工业的宿命;插件化让「接一种新设备」不动核心,同 [AI 网关](../ai-gateway/README.md) 的多供应商适配器。
- **统一数据模型**:把「寄存器 40001 = 2350」翻译成「3 号炉温度 = 235.0℃」。*为什么需要*:没有语义层,上面所有应用都要懂每台设备的寄存器表——等于没有平台。
- **边缘规则引擎**:阈值报警、操作级响应建议、数据过滤降采样,全部本地执行。*为什么需要*:实时性和断网自治的落点;这是「小脑」——不聪明,但反应快、不依赖大脑。**边界要清楚**:安全联锁 / 紧急停机属于 PLC 与安全仪表系统(SIS,有安全认证、故障安全设计),边缘规则引擎只做非安全级的报警与工艺提示。
- **本地缓存 + 存储转发**:时序数据先落本地,北向按批推送,断网续传。*为什么需要*:「数据不丢」的实现;工厂断外网是月经事件。
- **本地 HMI(人机界面)**:车间看板、报警一览。*为什么需要*:操作工不能因为「云挂了」就变瞎子。
- **北向连接器**:主动向云推送(仅出站),管理传输批次与确认。*为什么需要*:只出不进的连接方向,是穿越 DMZ 的合规姿势。
- **边缘管理面**:远程配置、插件升级、健康监控。*为什么需要*:网关散布在几十个厂区、无人值守,不能靠人肉插 U 盘运维。

## 6. 关键数据流

**场景一:数采上行(主干道)**
```
1. 适配器按点位表轮询 PLC(频率有讲究:太快会把老设备问死)
2. 变化检测:值没变不上报(deadband 死区过滤,省 90% 流量)
3. 翻译成统一模型:测点 ID + 值 + 质量戳 + 时间戳
4. 双路分发:→ 本地规则引擎(实时判断) → 本地时序缓存
5. 北向连接器攒批推云;断网则本地堆积,恢复后按序补传
```

**场景二:一次超温报警(为什么必须本地闭环)**
```
炉温 250℃ 超过阈值 240℃:
  ✗ 云端判断:采集→上云→规则→下发──任何一环断/慢,报警就没了
  ✓ 边缘判断:规则引擎本地秒级内触发 → 声光报警 + 通知操作工
     同时把事件上报云端(晚到没关系,反正现场已经报出来了)
  ── 云是「事后分析师」,边缘是「现场值班员」;
     而超温自动停炉这种安全联锁,是 PLC/SIS 的活,比边缘更底层、更快
     (三层分工:PLC/SIS 保安全 → 边缘保看见 → 云保聪明)
```

**场景三:一次远程调参(反向控制的重重关卡)**
```
1. 云端工程师发起「把 3 号炉设定值调到 230」→ 进审批流
2. 审批通过 → 指令下发到边缘(经唯一受控通道,全程审计)
3. 边缘校验:值在安全范围内?设备在可写状态?联锁条件满足?
4. 校验通过才写 PLC;任一环节不过 → 拒绝并告警
   ── 「读」是日常,「写」是手术:默认禁止、逐条审批、边缘终审
```

## 7. 数据模型与存储选择

核心实体:`设备 / 资产树`(厂区→产线→设备→测点);`点位映射表`(协议地址 ↔ 测点语义);`遥测时序`;`报警事件`;`控制审计日志`。

| 数据 | 存储类型 | 为什么 |
|---|---|---|
| 资产树 / 点位表 | 关系型(边缘 + 云各一份) | 结构化、变更少、是一切语义的根 |
| 遥测时序(边缘) | 嵌入式时序库 / 环形存储 | 本地缓冲有限,按保留策略滚动覆盖 |
| 遥测时序(云) | 时序库 + 冷归档 | 长期趋势、跨厂区分析,同 [IoT 平台](../iot-platform/README.md) |
| 报警 / 控制审计 | 关系型,只增不删 | 事故追溯与合规,一条都不能少 |

## 8. 关键架构决策与权衡 ⭐

**决策 1:智能放边缘,还是放云端?⭐**
- 云端:算力无限、模型随时迭代;但受制于网络,断网即失能。
- 边缘:实时、自治;但算力有限、更新一次要走现场变更流程。
- **取向**:按「晚了会不会出事」切分——**报警和现场响应必须边缘,分析、预测、优化放云端**(安全联锁则在更底层的 PLC/SIS,根本不进这道选择题)。判断标准:断网 72 小时,工厂能不能正常生产?

**决策 2:IT 侧能不能反向写 OT?⭐**
- 全禁:最安全,但「远程调参 / 远程运维」的价值全丢,每次调整都要人去现场。
- 放开:效率高,但等于给了云端一只伸进产线的手——云被攻破 = 产线被攻破。
- **取向**:**默认只读;写操作白名单化**——限定测点、限定范围、审批 + 审计、边缘侧终审(联锁校验)。高危场景(安全仪表系统)物理上就不给写的通路。

**决策 3:老设备协议异构,归一层放哪?**
- 每个应用自己解协议:起步快,但点位语义散落各处,加一台设备改 N 个系统。
- 网关统一归一:所有协议在边缘翻译成统一模型,应用只见「测点」。
- **取向**:必须在边缘归一。**点位映射表是工业数字化最值钱的资产**——它是物理世界的字典,值得花大力气维护。

**决策 4:轮询频率怎么定?**
- 越快越「实时」,但老 PLC 的通信口性能孱弱,轮太猛会挤占它和控制系统的通信,**把产线问停**。
- **取向**:按测点重要性分级(报警类秒级、趋势类分钟级)+ 死区过滤;上线前在测试环境验证 PLC 负载。「无扰」优先于「实时」。

## 9. 规模化与瓶颈

工业的规模化 = **厂区数量 × 设备异构度 × 年限**:

- **第一个瓶颈:点位映射靠人手工配。** 一个厂几万点位,配置错误比代码 bug 更多。→ 破解:点位模板库(同型号设备复用)、导入校验工具、配置版本化管理。
- **第二个瓶颈:多厂区网关运维。** 几十个厂、上百台网关、无人值守。→ 破解:边缘管理面(远程配置 / 灰度升级 / 健康监控),把网关当「牲口」而不是「宠物」。
- **第三个瓶颈:云端时序存储成本。**(每厂每秒几万点)→ 破解:边缘死区过滤 + 降采样上云,明细留边缘按需调取。
- **第四个瓶颈:报警风暴。** 一次停机引发几千条连锁报警,真正的根因被淹没。→ 破解:报警分级、抑制规则(父设备停机则抑制子设备报警)、根因聚合。

## 10. 安全与合规要点

- **网络分层隔离(Purdue 模型)**:控制网(L0-L2)/ 生产管理(L3)/ DMZ(L3.5)/ 企业网(L4-L5)层层隔离,跨层只走受控通道。**车间网络直连公网 = 把产线挂在枪口上**。
- **连接方向只出不进**:边缘主动外连,云侧不能主动伸进来;需要下行的指令走边缘拉取或专用通道。
- **控制指令全程审计**:谁、何时、改了哪个测点、从几改到几——事故追溯的生命线。
- **老设备没有安全能力**:Modbus 无认证无加密(1979 年的协议),防护只能靠网络层包裹(隔离 + 白名单),而非指望设备自己。
- **合规**:关键基础设施(电力、水务、化工)有强制的等保 / 行业安全标准;安全事件可能有法定上报义务。

## 11. 常见误区 / 反模式

- ❌ **把车间网络直接连上互联网** → ✅ 分层隔离 + DMZ + 连接由内向外发起,这是红线不是建议(核电等极高安全场景还会上物理单向网闸)。
- ❌ **报警链路依赖云端** → ✅ 「晚了会出事」的逻辑全部边缘本地闭环。
- ❌ **用 IT 思维「快速迭代」OT 系统**(随时重启、灰度发布到 PLC)→ ✅ OT 侧一切变更走停产窗口 + 现场验证;迭代自由度留给边缘以上。
- ❌ **轮询频率一律拉满追求「实时」** → ✅ 分级采集 + 死区过滤;把 PLC 问死是数采事故的经典款。
- ❌ **点位映射散落在各应用里** → ✅ 边缘统一归一,点位表版本化管理。
- ❌ **断网数据直接丢弃** → ✅ 本地缓存 + 断点续传,报表与追溯才完整。

## 12. 演进路线:MVP → 成长期 → 成熟期(不同阶段怎么设置)

| 阶段 | 规模量级 | 怎么设置(具体) | 此时该操心什么 |
|---|---|---|---|
| **MVP / 单线试点** | 1 条产线 | 一台工业网关 + 现成采集软件,几百个关键点位,本地看板 + 简单上云 | 证明「采得上来、看得见、不影响生产」,赢得工厂信任 |
| **成长期 / 全厂** | 1 个厂,数万点位 | 网关集群、统一数据模型、边缘规则引擎、报警体系、DMZ 网络改造 | 点位治理、报警风暴、断网自治能力 |
| **成熟期 / 集团** | 几十厂区 | 边缘管理面统一运维、云端数据湖跨厂分析、预测性维护、受控反向控制 | 多厂标准化(资产模型统一)、安全体系、运维成本 |

## 13. 可复用要点

- 💡 **「翻译官 + 统一模型」是对付异构遗留系统的通用解**:先归一语义,再谈上层应用——对接银行老核心、医院 HIS 是同一战术。
- 💡 **按「晚了会不会出事」切分边缘与中心**:实时兜底下沉、聪明决策上浮——CDN 边缘计算、门店系统同理。
- 💡 **存储转发(store-and-forward)是弱网协作的标准姿势**:先落本地再补传,同 [移动 App](../mobile-app/README.md) 的离线优先。
- 💡 **对「写现实世界」的操作层层设卡**:白名单 + 审批 + 执行侧终审,任何有物理后果的系统(支付、医疗、机器人)通用。
- 💡 **两种价值观的系统对接,边界要窄、要受控、要审计**:稳定派和迭代派不能混居,只能设口岸。

## 🎯 随堂检验

<Quiz
  question="工厂超温报警的判断逻辑应该放在哪里?"
  :options="['云端规则引擎,方便统一管理和迭代', '边缘网关本地闭环,断网照常工作', '放 PLC 里,其他地方都不放']"
  :answer="1"
  explanation="报警是『晚了会出事』的逻辑,必须在边缘本地闭环——云挂了、网断了,报警照响。云只做事后分析。(PLC 内的安全联锁是另一层更底层的保护,两者并存,但数采平台的报警职责落在边缘。)"
/>

---

## 参考原型与延伸阅读

> 本模板基于以下**真实开源项目**与**权威文档**整理。

**🔧 开源原型(可直接读代码):**
- [edgexfoundry/edgex-go](https://github.com/edgexfoundry/edgex-go) — Linux 基金会的开源边缘平台:南向设备服务(协议插件)/ 核心数据 / 北向导出的分层,就是本模板全景图的开源实现。
- [open62541/open62541](https://github.com/open62541/open62541) — OPC UA 协议的开源实现;OPC UA 是工业「统一语义模型」的行业答案,读它理解「点位如何带上语义」。

**📖 权威文档:**
- [NIST SP 800-82 Rev.3:OT 安全指南](https://csrc.nist.gov/pubs/sp/800/82/r3/final) — 美国国家标准与技术研究院(NIST)的工控安全权威指南:Purdue 分层、OT/IT 隔离、纵深防御,对应本模板第 10 节。

---

> 📌 一句话记住工业边缘:**它是两个价值观相反的世界之间的口岸——对车间「轻拿轻放、只读为主」,对云端「数据尽管上、手别伸下来」,自己则要做到「断了云,产线照转、报警照响」。所有设计都在回答:『怎么既拿到数据,又绝不碰坏正在赚钱的产线?』**