2. 升级迁移的驱动因素与目标定义

在AVEVA工业系统（如System Platform、InTouch、Historian、PI System等）的升级迁移项目中，最常见的失败模式并非技术不可行，而是"目标模糊"——项目启动时只笼统地说"把旧版本升到新版本"，却没有回答三个关键问题：为什么要升？升到什么程度算成功？谁的需求必须被满足？本章围绕驱动因素分析、迁移目标的量化定义、干系人识别与需求收集方法展开，帮助把一次升级从"技术动作"转化为"可验收的工程目标"。

一、驱动因素分析：先分清"必须"与"想要"

驱动因素是迁移项目的立项依据，也是后续优先级排序和资源投入的标尺。工业场景中常见的驱动因素可归为四类，它们往往同时存在，但权重不同：

• 业务驱动：产线扩产、新装置接入、MES/ERP集成需求、报表口径变更、多工厂数据集中。例如某化工企业新增一条产线，原有InTouch画面与标签命名无法覆盖新工位，必须扩展对象模型。
• 安全驱动：操作系统停止支持（如Windows Server 2012 R2、Windows 7/10 LTSC到期）、已知漏洞无法打补丁、老旧OPC DA依赖DCOM带来的暴露面、无审计日志。安全驱动通常具有"硬截止"性质。
• 合规驱动：等保2.0、GMP数据完整性（ALCOA+）、21 CFR Part 11电子记录与签名、IEC 62443分区与管道模型要求。合规驱动会直接约束架构，例如要求Historian具备不可篡改的审计追踪。
• 性能驱动：标签量增长导致历史查询变慢、画面切换卡顿、报警风暴、冗余切换时间超标。性能驱动最容易量化，也最容易在迁移后被验证。

实践中建议用一张"驱动因素—权重—验收关联"表来固化分析结果，避免后期争议。示例（数值为教学假设）：

权重不是拍脑袋，而是与干系人访谈、故障记录、审计发现项、性能监控数据对应。权重确定后，迁移方案的取舍就有了依据：若安全权重最高，则"就地升级+最小改动"可能优于"重构架构"；若性能权重最高，则必须评估Historian归档方式与查询索引。

二、迁移目标的量化定义

"功能对等、性能提升、架构现代化"是三类常见目标，但必须落到可测量、可验收的指标上，否则无法判断项目是否成功。

功能对等（Functional Parity）：不是"看起来一样"，而是"行为一致"。可量化的维度包括：标签数量与命名映射覆盖率、画面数量与可打开率、报警配置项数量、脚本/逻辑点数、报表数量、接口数量。例如：迁移前有12,480个标签、86幅画面、1,240条报警配置；迁移后要求标签映射覆盖率≥99.5%，画面可打开率100%，报警配置逐条比对差异≤0.5%。差异项必须登记并说明原因（如废弃标签、合并逻辑）。

性能提升（Performance Improvement）：必须定义测量方法、负载条件和阈值。示例指标：

• 历史趋势查询：在30天时间跨度、8条曲线条件下，P95响应时间从8.2s降至≤2.0s；
• 画面切换：典型画面（含200个动态对象）切换时间≤1.5s；
• 报警刷新：报警摘要页在500条活动报警下刷新≤2s；
• 冗余切换：主备切换时间≤5s，切换期间数据丢失≤1个采集周期。

注意：性能指标必须写明"在什么负载、什么数据量、什么客户端数量下测量"，否则数字没有意义。

架构现代化（Architecture Modernization）：可量化的方向包括：从OPC DA迁移到OPC UA的比例、从单机Historian迁移到冗余/分布式架构、从本地脚本迁移到集中式应用服务器、从手动部署迁移到版本化配置管理。例如：要求"80%以上数据源通过OPC UA接入""Historian具备冗余归档""应用对象模板化率≥70%"。这些指标直接决定迁移后的可维护性。

三、干系人识别与需求收集方法

工业系统迁移的干系人远不止IT部门。典型角色包括：

• 生产/工艺：关心画面可用性、报警准确性、操作习惯是否改变；
• 自动化/仪表：关心PLC/RTU通信、标签地址、采集周期、控制逻辑接口；
• IT/OT运维：关心OS版本、域策略、备份、补丁、账号权限；
• 安全/合规：关心审计追踪、电子签名、分区隔离、日志留存；
• 管理层：关心停机窗口、预算、投资回报、风险；
• 外部供应商/集成商：关心接口文档、测试环境、验收标准。

需求收集不能只靠开会。推荐组合使用以下方法：

1. 现场走查与操作观察：记录操作员实际使用的画面、频繁切换的流程、抱怨的卡顿点。这是发现"隐性需求"最有效的方式。
2. 系统清点（Inventory）：导出标签、画面、报警、脚本、接口、报表清单，形成迁移范围基线。
3. 结构化访谈：按角色设计问题，例如问运维"当前最担心的三个故障是什么"，问合规"上次审计的不符合项有哪些"。
4. 历史数据分析：调取报警日志、性能监控、故障工单，用数据验证需求优先级。
5. 需求工作坊：把冲突需求摆到桌面，例如生产要求"停机窗口≤4小时"与IT要求"完整回归测试≥8小时"之间的矛盾，需要当场形成折中方案。

需求收集后应形成"需求跟踪矩阵"（RTM），把每条需求映射到驱动因素、目标指标、验收方法和责任人。示例片段：

需求ID: REQ-014
来源: 生产部 / 操作观察
描述: 反应釜画面切换时间过长，影响紧急处置
驱动: 性能
目标: 切换时间 ≤ 1.5s（当前约4s）
验收: 在测试环境用典型画面实测10次取P95
责任人: 自动化工程师 + 画面开发
状态: 已确认

需要强调的是，需求收集的终点不是"清单越长越好"，而是"范围可控、优先级明确、验收可执行"。对于无法量化或无法验收的需求，应转为"观察项"而非"承诺项"，避免项目后期被无限扩大。

把驱动因素、量化目标、干系人需求三者对齐后，迁移项目才具备"可立项、可执行、可验收"的基础。下一阶段的技术方案设计、停机窗口规划、回滚策略，都应回到本章定义的目标指标上寻找依据。