1. 迁移工程总览
在启动任何一条迁移实施路线之前，工程团队必须先回答四个问题：旧系统现在长什么样、为什么要迁、迁成什么样、怎样算迁成功。这四个问题分别对应典型架构、迁移驱动因素、迁移目标和成功标准。它们不是文档开头的套话，而是后续所有点位核对、通信改造、画面重建与切换方案的判断依据。本节把旧SCADA系统当作一个可拆解、可测量的工程对象来梳理。
一、典型架构：从现场设备到调度席位的四层链路
AVEVA旧SCADA系统（含早期 InTouch、System Platform 及配套 Historian 等形态）在多数工业现场呈现为四层结构。自下而上依次是：现场层、控制层、采集与数据层、监控与展示层。
现场层由变送器、执行机构、智能电表、保护装置等组成，输出 4–20 mA 模拟量、干接点开关量，或通过 Modbus RTU、IEC 60870-5-101 等串行规约上传数据。这一层通常不属于迁移改造范围，但它的信号类型和规约决定了上层采集方式。
控制层以 PLC、RTU、DCS 控制器为核心。它们承担逻辑联锁与闭环控制，是 SCADA 的数据源。迁移中最需要确认的是：控制器型号、固件版本、可用通信口数量、支持的规约（如 Modbus TCP、OPC DA、IEC 60870-5-104、DNP3），以及是否允许新增并发连接。
采集与数据层是旧系统的关键枢纽，通常由通信驱动（IO Server / DAServer）、实时数据库、历史数据库（Historian）和报警服务构成。旧架构常见的问题是驱动与操作系统强绑定、历史数据以私有格式存储、报警配置分散在多个工程文件中。
监控与展示层包括操作员站、工程师站、报警打印机、Web 发布服务器。画面、脚本、趋势、报警组态都集中在这一层，也是迁移工作量最直观的部分。
理解这条链路的意义在于：迁移不是“换一套软件”，而是沿着数据流逐段替换或桥接。任何一段的规约、地址、时标或量纲不一致，都会在画面上表现为坏点、跳变或报警误动。
二、迁移驱动因素：为什么必须动
迁移驱动因素通常分为三类，识别清楚才能确定优先级和验收口径。
技术性驱动最为紧迫。旧版 InTouch 或 System Platform 可能运行在 Windows Server 2008 / Windows 7 上，微软已停止安全更新；旧 DAServer 不支持 TLS，通信明文暴露；Historian 的私有格式难以被 MES、数据中台或云端平台直接消费。此外，硬件生命周期结束、备件停产、工程师退休导致的知识断层，也属于技术性驱动。
业务性驱动来自生产与管理需求。例如需要把多个分散厂区的 SCADA 数据汇聚到统一运营中心；需要把报警推送到移动端；需要按批次、班组、设备维度做能耗与产量分析。旧系统往往只能提供单机画面和有限趋势，无法支撑这些跨系统分析。
合规与安全驱动包括等保要求、行业安全规范、审计追溯要求。旧系统普遍缺少基于角色的细粒度权限、操作日志不完整、无法满足“谁在何时对哪个点位下发了什么指令”的追溯要求。
实际项目中，三类驱动往往同时存在。建议在启动阶段列一张驱动因素清单，为每条标注“紧迫度”和“影响范围”，作为后续迁移范围裁剪和切换顺序的输入。
三、迁移目标：迁成什么样
迁移目标必须具体到可验证的程度，避免“提升系统先进性”这类无法验收的表述。一个可落地的目标集合通常包含以下维度：
- 功能等价：原有监控、控制、报警、趋势、报表功能全部可用，点位覆盖率 100%，关键联锁逻辑不变。
- 数据连续：历史数据可查询、可回填，迁移切换点前后趋势曲线连续，时标统一到同一时区与精度。
- 性能达标：画面刷新周期、报警响应时间、数据采集周期满足工艺要求。例如模拟量采集周期 ≤ 1 s，报警从产生到显示 ≤ 2 s。
- 架构可持续：新系统支持标准规约（OPC UA、IEC 60870-5-104、MQTT 等），支持冗余、支持横向扩展，不再与特定操作系统版本强绑定。
- 安全合规：具备账号分级、操作审计、通信加密、边界防护能力。
目标之间可能存在冲突。例如“功能等价”要求保留旧脚本的特殊行为，而“架构可持续”要求改用标准组件。此时应在目标中明确取舍原则：优先保证生产连续与安全，其次保证数据完整，最后优化架构与界面体验。
四、成功标准：怎样算迁成功
成功标准是迁移项目的验收尺子，应在开工前与生产、设备、信息、安全各方共同确认。以下是一组可直接参考的示例指标（数值为示例，实际项目应按工艺与合同约定调整）：
| 维度 | 示例成功标准 | 验证方式 |
|---|---|---|
| 点位覆盖 | 迁移点位覆盖率 100%，坏点率 < 0.1% | 新旧系统点位对照表逐条核对，连续运行 72 h 统计 |
| 数据一致性 | 同一测点新旧系统读数偏差在量程 ±0.2% 以内 | 选取 20 个典型测点，同步记录 24 h 对比 |
| 报警正确性 | 报警产生、确认、恢复流程与旧系统一致，无漏报误报 | 按报警测试用例逐条触发验证 |
| 切换影响 | 单次切换窗口 ≤ 4 h，切换期间无工艺中断 | 切换方案演练 + 实际切换记录 |
| 历史数据 | 近 3 年历史数据可查，趋势连续无断点 | 抽查关键测点历史曲线 |
| 安全审计 | 所有控制操作可追溯到账号、时间、点位、值 | 审计日志抽样检查 |
五、把总览落到工程动作上
完成上述四项梳理后，应形成三份可直接使用的成果：一份旧系统架构与资产清单（含控制器型号、规约、点位数量、画面数量、脚本数量、历史数据年限）；一份迁移驱动因素与优先级表；一份目标与成功标准确认单。这三份文件是后续点位映射、通信改造、画面重建、测试与切换方案的共同基线。
需要特别提醒的是：迁移目标与成功标准一旦确认，就不应在实施中期随意扩大。旧系统迁移最常见的失控原因，是把“迁移”悄悄变成了“重新设计”——画面重做、逻辑优化、点位增删同时进行，导致范围蔓延、测试无法收敛。正确的做法是：先完成等价迁移并稳定运行，再在独立的需求变更流程中做优化。
下一阶段的工作，将围绕旧系统资产盘点与点位映射展开，把本节的总览判断转化为可执行的迁移清单。