4. 目标平台选型
旧 SCADA 迁移最忌讳“先买平台、再想怎么搬”。目标平台选型不是挑一个功能最多的产品，而是判断旧系统的哪些职责应当由哪个新组件承接。AVEVA 体系里最常被拿来对比的三类目标是：System Platform（面向对象、分布式、可扩展的监控与信息平台）、Edge（边缘侧数据采集、协议转换与本地可视化）、Historian（历史数据存储与查询分析）。它们不是互相替代关系，而是分工关系；选型的本质是判断旧 SCADA 的每一项能力落在哪一层，以及哪些能力需要被拆分或重建。
先拆旧 SCADA 的职责，再谈匹配
一套典型旧 SCADA 通常同时承担五类职责：现场设备通信与协议驱动、实时画面与报警、控制逻辑与联锁、历史数据归档与趋势、以及报表与对外数据接口。迁移时如果把这五类职责整体映射到单一新产品，往往会出现“边缘协议支持不足”或“历史查询能力过剩”的错配。更合理的做法是先做职责分解，再逐项判断承接方。
以某水厂旧 SCADA 为例，其现场有 12 台 Modbus RTU 流量计、8 台 Profibus 泵组控制器、4 套 IEC 60870-5-104 电力综保，上位机运行旧版 InTouch，历史数据存在本地 SQL Server，报表由第三方工具生成。这个系统的职责分布是：协议驱动集中在串口服务器与旧驱动，画面与报警在 InTouch，联锁在 PLC，历史在 SQL Server，报表在外挂工具。迁移时，协议驱动和本地可视化适合下沉到 Edge，历史归档适合交给 Historian，而跨站点、跨专业的统一画面、报警管理和对象模型则适合由 System Platform 承担。
三类平台的匹配度判断要点
AVEVA Edge 的匹配点在于协议覆盖和边缘自治。旧 SCADA 若依赖大量串口、现场总线或私有协议，Edge 的驱动库通常能直接承接，且支持在边缘侧完成数据采集、报警判断和本地画面显示。它的短板是跨站点统一建模能力弱，不适合作为全厂唯一监控平台。判断是否选用 Edge，可以看三个条件：现场协议是否超过 5 种、站点是否超过 3 个且网络不稳定、是否需要断网续传。若三项中有两项为“是”，Edge 应作为边缘层首选。
AVEVA System Platform 的匹配点在于对象模型和统一管理。旧 SCADA 若存在大量重复设备（如 20 台同型号泵、15 个同类阀门），System Platform 的模板与实例机制可以显著减少画面和脚本的重复工作量。它的代价是部署复杂度和授权成本较高，且需要重新设计对象命名与层级。判断是否选用 System Platform，可以看：设备类型是否超过 10 类、是否需要跨站点统一报警、是否有集中运维团队。若旧系统只是单站小规模，强行上 System Platform 会造成过度设计。
AVEVA Historian 的匹配点在于历史数据的长期存储与查询。旧 SCADA 若历史数据仅保留 3 个月、报表依赖外挂工具、趋势查询缓慢，Historian 的压缩存储和内置查询能直接改善。它的前提是数据源已经通过 Edge 或 System Platform 完成标准化采集，否则 Historian 会变成“垃圾进、垃圾出”。判断是否选用 Historian，可以看：历史数据保留期是否要求超过 1 年、每秒采集点数是否超过 5000、是否需要批次或事件数据。
选型决策表（示例）
下表以某水厂旧 SCADA 为例，给出职责与目标平台的对应关系。表中“匹配度”为示例评估，实际项目需结合现场调研结果调整。
| 旧 SCADA 职责 | 推荐承接平台 | 匹配度 | 关键判断依据 |
|---|---|---|---|
| Modbus RTU 流量计采集 | AVEVA Edge | 高 | Edge 内置 Modbus 驱动，支持串口转以太网 |
| Profibus 泵组控制 | 保留 PLC + Edge 采集 | 中 | Profibus 需经网关转 OPC UA 后接入 Edge |
| IEC 104 电力综保 | AVEVA Edge | 高 | Edge 支持 IEC 60870-5-104 驱动 |
| InTouch 画面与报警 | System Platform | 高 | 对象模板可复用，报警统一管理 |
| SQL Server 历史数据 | AVEVA Historian | 高 | 压缩存储，支持长期归档与趋势查询 |
| 第三方报表工具 | Historian + 报表接口 | 中 | 需评估报表逻辑是否可迁移至 Historian 查询 |
| 多站点分散管理 | System Platform | 高 | 统一命名空间与集中报警 |
组合部署与迁移顺序
实际工程中，三类平台往往组合使用：Edge 负责现场采集与边缘自治，System Platform 负责中心监控与对象建模，Historian 负责历史归档与查询。迁移顺序建议从 Edge 开始，因为协议驱动和现场数据采集是基础，且 Edge 可以独立运行，不影响旧系统继续工作。待 Edge 数据稳定后，再逐步将画面和报警迁移到 System Platform，最后将历史数据接入 Historian。这样做的原因是：如果先迁移 Historian，数据源尚未标准化，历史数据质量无法保证；如果先迁移 System Platform，现场协议驱动尚未就绪，画面会缺少实时数据。
- 现场协议种类是否超过 5 种？是 → Edge 优先。
- 站点数量是否超过 3 个且网络不稳定？是 → Edge 边缘自治。
- 重复设备类型是否超过 10 类？是 → System Platform 对象模板。
- 是否需要跨站点统一报警与安全策略？是 → System Platform。
- 历史数据保留期是否超过 1 年？是 → Historian。
- 每秒采集点数是否超过 5000？是 → Historian 压缩存储。
- 旧系统是否单站小规模？是 → 优先 Edge，避免过度设计。
总结来说，目标平台选型的核心不是比较产品功能列表，而是判断旧 SCADA 的每一项职责由谁承接、以什么顺序迁移、以及组合部署后是否形成完整的数据链。Edge 解决“采得到、控得住”，System Platform 解决“看得全、管得统一”，Historian 解决“存得久、查得快”。三者各司其职，才能让迁移后的系统既覆盖旧功能，又具备可持续扩展的基础。