多协议并存的现实
现场往往同时存在多种协议：不同年代的 PLC 使用厂商专有协议，仪表常用 Modbus，电力设备用 IEC 60870-5-104 或 DNP3，部分新设备支持 OPC UA。SCADA 采集架构要解决的是一致性问题：不同协议的数据如何统一建模、以什么频率采集、通信异常时如何标记数据质量，以及谁有权写入。常用分法是驱动层、采集服务层、数据模型层与应用层。
分层与职责
| 驱动层 | 按协议适配不同设备，含超时、重试与异常处理 |
|---|---|
| 采集服务层 | 调度采集任务、负载分配与故障切换 |
| 数据模型层 | 统一命名、单位、量程与质量码 |
| 应用层 | 画面、报警、趋势与报表 |
| 配置管理 | 点表版本与设备清单的集中维护与变更记录 |
设计要点
| 要点 | 要求 | 常见问题 |
|---|---|---|
| 协议解耦 | 驱动独立，新增设备不改动上层 | 把协议处理写进画面脚本 |
| 统一建模 | 名称、单位与量程保持一致 | 同一物理量在不同系统名称不同 |
| 采集频率 | 按重要性与链路余量分别设定 | 全点表同一频率导致链路拥塞 |
| 质量码 | 区分有效、陈旧、无效与超时 | 通信失败时沿用旧值 |
| 写权限 | 读取与写入分离，写入单独授权 | 采集账号同时具备写能力 |
| 时间戳 | 采集侧统一打时间戳并同步时钟 | 各站时间不一致导致趋势错位 |
落地建议
- 按重要性分级采集：关键回路数据提高频率，辅助数据放宽
- 为串行链路留出余量，避免采集负载占满带宽导致超时
- 为每个设备定义超时与重试策略，避免一次失败就整体置为无效
- 点表配置纳入版本管理，修改点表走变更流程
- 对不支持批量读取的设备评估影响，必要时调整分组与顺序
「采集到就是正确」是常见误解：协议层只能确认通信成功，无法确认现场测量是否可信。因此质量码与合理性校验，例如量程与变化率判断，是多协议采集架构的必要组成部分。
新增一类设备时若直接把驱动加载到现有采集主机上，很容易影响原有采集任务。新增驱动应先做资源与联调评估，并在测试环境验证后再上线。