软件接口设计：中控系统的协议抽象与设备驱动
很多中控系统上线一两年就没人敢改，原因是设备协议散落在各处，换一台设备要翻遍代码。这篇文章讲怎么用统一的接口方法封装设备差异、把配置外置成文件、留好测试替身，让换设备只改一个文件，这也是判断中控软件是否工程化的标志。
换一台设备只改一个文件，是判断中控软件是否工程化的标志
中控软件最难维护的地方在哪
很多中控系统上线一两年后就没人敢改了，原因通常是：设备协议散落在各处，控制逻辑直接写着"往 1 号串口发这串十六进制"，换一台设备要翻遍所有代码。这类系统不是功能不行，而是结构没有把"设备差异"和"业务逻辑"分开。
把设备差异关在驱动里
设备驱动要做的事很单纯：对外提供统一的动作，对内处理该设备特有的协议细节。比如统一暴露"开机、关机、切换输入、查询状态"这几个动作，驱动内部去拼串口命令或发 HTTP 请求。业务逻辑只调用动作名，永远不出现十六进制和端口号。这样换设备时改动被限制在一个文件里。
统一接口的四个方法
连接：建立通道并完成握手，失败要能返回明确原因，而不是抛一个通用错误。
发送：下发动作，区分"已受理"和"已完成"两种结果。
订阅：注册状态变化通知，让上层可以被动接收而不是不停轮询。
查询：主动拉取当前状态，用于界面初次加载或状态校正。
四个方法定下来，上层代码对所有设备就长得一样，新增设备类型只是新增一个实现。
配置外置：设备表与点位表
哪台设备接在哪个端口、用什么参数、属于哪个区域，这些不应该写在代码里。把它们放进配置或数据库，现场调整就不需要改程序、不需要重新部署。这一点在施工阶段尤其重要——现场条件经常和设计不一致，能改配置解决的事就不要改代码。
版本与兼容
设备固件升级后协议微调的情况很常见。驱动应记录它适配的固件版本，并在启动时做一次能力探测，而不是假定所有设备都一样。对于同一型号的不同批次，宁可多写一个分支，也不要赌它们完全一致。
留好测试替身
中控系统很难在办公室里搭出完整现场，所以驱动最好能配一个模拟实现：不发真实命令，只按预定义规则回状态。这样上层逻辑、界面、联动可以在没有硬件的情况下开发和验证，现场调试的时间能缩短很多。这也是判断一套中控软件是否工程化的一个标志。