先给结论
做设备数据采集，不要一上来就写代码连 PLC。正确顺序是：先盘清楚设备和协议 → 决定采集架构（直连还是网关解耦）→ 选网关/连接软件 → 选数据存储 → 最后才写上位机业务。架构顺序错了，后期每加一台设备都是灾难。
第一步：盘设备和协议（决定一切的前提）
把现场清单列成表：每台设备是什么品牌、什么型号、走什么协议、能提供哪些接口（网口/串口）、点位有多少、数据变化多快。
常见协议对应关系：
- 三菱 Q/FX 系列：MC 协议（TCP/串口）
- 西门子 S7-1200/1500：S7 协议或 OPC UA
- 通用仪表/变频器：Modbus TCP/RTU 最常见
- 跨系统标准对接：OPC UA
这一步的产出是一张点位表，它同时是网关变量表、数据库表、上位机画面的共同源头，务必一次规划好命名。
第二步：决定架构——直连还是网关解耦
- 上位机直连：设备少（1-3 台）、协议单一、只有一个系统用数据时最简单，代码里直接用通讯库读取。
- 网关解耦（推荐中大型场景）：设备多、协议杂、多个系统（上位机/MES/大屏/AI）都要用数据时，加一个独立采集网关，南向统一采集、北向标准转发。这样通讯问题不会拖垮业务系统，新增消费方也不用重复连设备。
判断标准很简单：当「第二个系统也要用同一份设备数据」时，就该上网关解耦了。
第三步：选网关/连接软件
| 方向 | 代表 | 适合 |
|---|---|---|
| 商业 OPC 服务器 | KEPServerEX | 预算足、协议极杂、要商业兜底 |
| 开源边缘网关 | ThingsGateway、Neuron、EdgeX | 自主可控、零授权费、有二开能力 |
| 自研 | Go/C# 通讯库 | 协议固定、需要深度定制 |
选型看四个维度：协议是否覆盖、点位规模能否扛住、运行平台（Windows/Linux/ARM）、团队是否能维护。
第四步：选数据存储
- 只做实时监控、不存历史：内存 + 实时转发即可。
- 需要历史趋势、报表、回溯分析：用时序数据库（如 TDengine、InfluxDB），不要用关系库硬扛高频写入。
- 要做业务关系（用户、工单、项目）：关系库（PostgreSQL）与时序库分工，别混为一谈。
第五步：再写上位机业务
通讯和存储稳定后，上位机只负责「消费数据 + 展示 + 业务逻辑」。这也是未来 Web HMI 的方向：前端用 Vue/TypeScript，通过标准 API 或实时消息拿数据，和底层协议彻底解耦。
一张判断清单
- 点位表和协议清单是否已经列全？
- 是否有两个以上系统要用同一份数据？是 → 网关上。
- 软件运行平台有没有 Linux/国产化要求？
- 历史数据要不要长期留存、要不要高频写入？要 → 时序库。
- 通讯层和业务层是否做到了可独立替换？
把这五个问题回答清楚，采集架构基本不会走弯路。后续本站会针对每一步给出带代码的实战教程。