耦合的典型症状
- 想换通讯库，发现界面、报警、存储代码全要改
- 通讯一卡，整个界面卡死
- 同一个读 PLC 的逻辑，在三个窗口里复制了三遍
- 设备离线时，业务层拿到一堆异常却不知道怎么处理
这些都是通讯层和应用层没分开导致的。
解耦后的三层结构
通讯层：只负责连接、读写、重连，对外提供“当前值”和“写入命令”，不关心界面和业务。
数据模型层：维护一份统一的“点位实时值缓存”，带时间戳和质量戳（好/坏/不确定）。
应用层：界面、报警、存储只跟数据模型层打交道，根本不知道底层是什么协议。
关键：用“实时值缓存”做中间媒介
通讯线程按周期把读到的值写进缓存，应用层只读缓存、不直接触发通讯。这样：
- 界面刷新再频繁，也不会重复打 PLC
- 通讯中断时，缓存里的值带“坏质量”标记，界面据此显示灰色状态灯
- 换协议只改通讯层，应用层零感知
状态质量为什么重要
工业现场不能只有“值”，还要有“质量”。一个温度点显示 85℃，但如果通讯已中断，这个 85℃ 是过期数据，必须用质量戳标出来，避免误判。这也是状态灯分绿/黄/红/灰的原因：
- 绿：正常运行
- 黄：待机/告警
- 红：故障
- 灰：通讯中断（数据不可信）
解耦带来的长期收益
- 通讯库可整体替换（比如从厂商 SDK 换成开源 OPC UA）
- 可以用“模拟驱动”在没有 PLC 时开发调试界面
- 多人协作不冲突：一人写驱动，一人做界面
- 单元测试可针对数据模型和业务逻辑独立进行
落地最小动作
哪怕项目不大，也建议先做两件事：一是建一个全局点位缓存字典，二是把所有通讯收进独立模块/线程。这两步成本不高，却决定了项目三年后还能不能轻松迭代。