3. 迁移可行性评估

在完成旧SCADA系统的资产盘点与现状梳理之后，下一步不是立刻动手迁移，而是回答一个更关键的问题：这套系统到底能不能迁、值不值得迁、先迁哪一部分。可行性评估的本质，是把“迁移”这个笼统目标拆解为技术、业务、成本、风险四个可判断的维度，并据此给出迁移优先级。缺少这一步，项目很容易在中期陷入“改不动、停不下、算不清”的被动局面。

一、四个维度的评估定位

四个维度并非并列打分那么简单，它们之间存在明确的约束关系。技术可行性决定“能不能做”，业务可行性决定“该不该做”，成本可行性决定“划不划算”，风险可行性决定“能不能承受失败”。其中技术是门槛，业务是方向，成本是约束，风险是底线。任何一个维度出现硬性否决项，都应重新审视迁移范围，而不是强行推进。

二、技术可行性：先看“接口”再看“逻辑”

技术可行性评估应从最底层的数据通道开始。旧SCADA常见的通信方式包括Modbus RTU/TCP、OPC DA、DNP3、专有串口协议等。迁移到新平台时，首先要确认新系统是否原生支持这些协议，或是否需要增加协议网关。例如，旧系统通过OPC DA采集现场RTU数据，而新平台仅支持OPC UA，则必须部署DA到UA的转换网关，并验证标签映射是否完整。

其次是点表与逻辑的转换难度。旧系统的点表往往存在命名不规范、量程不统一、工程单位缺失等问题。评估时应抽取10%～20%的典型点表进行试转换，统计可直接映射、需人工修正、需重新组态三类比例。若需人工修正的比例超过40%，技术可行性就应标记为“中等偏低”。

第三是脚本与自定义逻辑。旧SCADA中大量使用VBScript、C脚本或专用计算模块，这些逻辑在新平台中可能没有等价实现。评估时要逐条列出脚本功能，判断是“可平移”“需重写”还是“可废弃”。这一步直接决定后续工作量。

三、业务可行性：停机窗口与业务连续性

业务维度的核心问题是：生产能不能停、能停多久、停了之后谁受影响。对于连续生产行业，SCADA停机往往意味着整条产线停摆。评估时需要与生产部门确认可接受的停机窗口，并判断迁移工作能否在该窗口内完成。如果单次停机不足以完成全部迁移，就必须设计分阶段切换方案。

另一个关键点是关键工艺逻辑的依赖程度。某些旧SCADA中嵌入了多年积累的联锁、顺控和优化逻辑，这些逻辑可能没有完整文档。迁移前必须确认这些逻辑是否已被PLC或DCS覆盖，还是仅存在于SCADA层。若仅存在于SCADA层且无文档，业务可行性应下调，并优先安排逻辑逆向梳理。

此外，报表、MES接口、历史数据查询等外围功能也需纳入评估。这些功能往往由不同团队维护，迁移时容易遗漏，导致上线后业务部门无法正常取数。

四、成本可行性：算清“显性”与“隐性”

成本评估不能只看软件授权费。完整的成本项应包括：新平台软件许可、服务器与网络硬件、协议网关、组态与脚本重写工时、现场调试差旅、停机损失、并行运行期间的额外运维投入，以及培训费用。其中停机损失和重写工时往往是最容易被低估的两项。

建议用“单位点成本”作为横向比较指标。例如，某项目旧系统约8000个点，新平台组态重写平均每点耗时约15分钟，则仅组态一项就需约2000工时。若按每人月22个工作日、每天6小时有效工时计算，约需15人月。这个数字可以直接用于判断项目周期与人力投入是否匹配。

五、风险可行性：回退方案是底线

风险维度要回答的是：如果迁移失败，能不能退回去。旧SCADA迁移最怕的是“切过去回不来”。因此评估时必须确认旧系统在迁移期间是否保持可用状态，历史数据是否已备份，旧硬件是否保留，以及回退操作需要多长时间。

常见风险包括：数据丢失、控制误动、通信中断、新平台性能不足、并行运行期间两套系统数据不一致。对于每一项风险，都应给出发生概率、影响程度和缓解措施。若某项风险的影响程度为“高”且缓解措施不可行，则该部分应暂缓迁移。

六、优先级判定：用矩阵代替拍脑袋

四个维度评估完成后，可以用“可行性—价值”矩阵确定优先级。将每个子系统或功能模块按“迁移可行性”和“业务价值”两个轴打分，分为高、中、低三档。高可行且高价值的模块优先迁移；高价值但低可行的模块先做技术攻关或改造；低价值且低可行的模块可以考虑废弃或延后。

七、评估输出物

可行性评估的最终输出不应只是一份结论，而应包含：四维评估打分表、否决项清单、优先级排序表、初步迁移范围建议，以及需要进一步验证的技术问题清单。其中“需要进一步验证的问题”尤其重要，它把评估从纸面判断推进到可执行的验证动作，例如“下周用测试网关验证OPC DA到UA的标签映射完整率”。

只有把可行性评估做成可追溯、可复核、可更新的工程文档，后续的迁移计划才有可靠依据。否则，迁移项目很容易变成边做边改、越做越大的无底洞。