第2章：系统架构设计
好，咱们进入正题。系统架构设计，说白了就是给整个监控系统搭骨架。我做了这么多年半导体工厂自动化，见过太多「先写代码再想架构」的项目，最后都改得面目全非。所以这一章，咱们把骨架搭结实了。
2.1 分层架构：设备层、控制层、管理层
半导体工厂的实时监控系统，我习惯把它分成三层。为什么是三层？你想想看，设备、控制、管理，这三个层面的职责天然不同，硬揉在一起只会让系统变得又臭又硬。
设备层（Equipment Layer）
设备层就是最底层的那些物理设备——光刻机、刻蚀机、清洗机、测量设备……说白了，就是那些直接跟晶圆打交道的家伙。这一层的核心任务是：采集数据、执行指令。
我在项目中遇到过一个问题：某台刻蚀机的传感器数据采集频率太高，导致上位机CPU直接跑满。后来我们做了个策略——设备层只做「轻量级采集」，不做任何数据处理。嗯，这个教训挺深刻的。
控制层（Control Layer）
控制层是承上启下的关键。它负责：
- 接收设备层的数据，做初步清洗和缓存
- 向下发送控制指令（比如调整工艺参数）
- 向上提供标准化的数据接口
我个人习惯在控制层做两件事：一是数据校验（防止设备层传来脏数据），二是心跳检测（判断设备是否在线）。这两件事做好了，管理层才能安心干活。
管理层（Management Layer）
管理层就是咱们的监控界面、报表系统、报警中心。它不关心设备的具体协议，只关心数据有没有、准不准、快不快。说白了，管理层是给人看的，控制层是给机器用的。
核心原则：每一层只做自己的事，不要越界。设备层不要做数据清洗，管理层不要直接控制设备。这是血的教训换来的。
2.2 数据流与通信协议
数据怎么在三层之间流动？这就涉及到通信协议了。半导体行业有两个主流协议：SECS/GEM 和 OPC UA。我分别说说。
SECS/GEM：半导体行业的「普通话」
SECS/GEM 是半导体设备通信的事实标准。它定义了设备与主机之间的消息格式和交互流程。说白了，就是设备跟控制系统之间怎么「说话」。
我曾经踩过一个坑：某台设备的SECS消息里，时间戳用的是本地时间，而控制系统用的是UTC。结果数据对不上，排查了整整两天。所以我现在做项目，第一件事就是统一时间基准。
SECS/GEM 的核心概念：
- HSMS：基于TCP/IP的通信协议，取代了老旧的RS-232
- SML：SECS消息语言，定义了消息的结构
- Collection Events：设备主动上报数据的事件机制
OPC UA：跨平台的「翻译官」
OPC UA 是工业4.0时代的明星协议。它比SECS/GEM更灵活，支持更丰富的数据模型。我建议在管理层和控制层之间使用OPC UA，因为它能很好地封装SECS/GEM的复杂性。
两种协议的对比：
| 特性 | SECS/GEM | OPC UA |
|---|---|---|
| 应用场景 | 设备层与控制层 | 控制层与管理层 |
| 数据模型 | 扁平化 | 面向对象 |
| 安全性 | 较弱 | 强（支持加密） |
| 实时性 | 高 | 中 |
我的建议：设备层用SECS/GEM，管理层用OPC UA。中间加一个协议转换网关，两边都舒服。
2.3 系统模块划分
一个完整的实时监控系统，我通常把它拆成这几个模块：
- 数据采集模块：负责跟设备层通信，采集原始数据
- 数据处理模块：数据清洗、格式转换、缓存管理
- 报警管理模块：阈值判断、报警分级、通知推送
- 可视化模块：实时看板、历史趋势、报表生成
- 配置管理模块：设备参数、报警规则、用户权限
每个模块之间通过消息队列解耦。我习惯用RabbitMQ或者Kafka，具体看数据量大小。小厂用RabbitMQ就够了，大厂嘛……你懂的，Kafka更稳。
2.4 架构总览图
下面这张图，是我自己画的系统架构总览。它把三层架构、通信协议、模块划分都串起来了。你仔细看看，应该能一目了然。
注意：这张图只是逻辑架构。实际部署时，控制层和管理层可能跑在不同的服务器上，甚至跨机房。网络延迟和可靠性一定要提前测试。
2.5 避坑指南
最后，分享几个我踩过的坑：
- 协议兼容性：不同厂家的设备，SECS/GEM实现细节可能不同。我曾经遇到过某台设备把「0」当作有效数据，另一台却当作空值。所以，设备接入前一定要做协议一致性测试。
- 数据风暴：设备故障时，可能会疯狂上报数据。控制层一定要做限流和熔断，不然整个系统都会被拖垮。
- 时间同步：所有设备、服务器必须使用NTP同步时间。否则数据对不上，排查起来想哭。
好了，架构设计就聊到这儿。下一章咱们会深入数据采集模块的实现细节，到时候再细聊。
公众号:蓝海资料掘金营，微信deep3321