4. 现有系统资产盘点与基线建立
迁移项目最容易失控的地方，不是新系统装不上，而是旧系统里到底有什么没人说得清。CENTUM CS 3000、CENTUM VP 乃至更早的 CS 1000 系统，往往经过十几年的在线修改、临时旁路、试验性回路和人员更替，组态与现场实际之间已经存在大量“隐性差异”。如果不在迁移前完成一次系统性的资产盘点并冻结基线，后续的版本比对、功能验证和回退方案都失去参照物。本节的核心任务，就是借助 Yokogawa 工程工具把散落在各处的组态、数据库、图形和逻辑导出为一份可追溯、可比对、可冻结的资产清单。
盘点对象：四类资产，各有各的导出路径
Yokogawa 系统的工程资产大致分为四类，它们的存储位置、导出方式和追溯难度并不相同，必须区别对待。
- 组态数据库（FCS 侧）：包括 Function Block、Sequence Table、Regulatory Control、I/O 分配等，存放在现场控制站（FCS）的工程数据库中。这是迁移的“主资产”，通常通过 System View 的 Project 管理功能导出为项目文件（如
.gpr或对应版本的工程归档），也可借助 CI Server 做集中备份。 - HIS 图形与人机界面：包括流程图窗口、趋势组、报警画面、操作面板等，存放在 HIS 侧。图形资产数量大、引用关系复杂，是盘点中最容易被低估的部分。
- 逻辑与顺序控制：Sequence Table、Logic Chart、Batch 配方等，往往与工艺操作强相关，迁移时最需要逐条确认。
- 系统级配置：网络地址、域配置、安全策略、报警优先级定义、单位与量程约定等，属于“环境资产”，容易被忽略却直接影响迁移后的可用性。
这四类资产在 System View 中通常以树形结构呈现，但树形视图只反映“当前存在什么”，不反映“何时被谁改过”。因此盘点不能只做一次导出，而要结合 CI Server 的版本历史，形成带时间戳的资产快照。
用 System View 做结构化导出
System View 是盘点的起点。实际操作中，建议按“先整体、后局部”的顺序推进。首先在 System View 中打开目标项目，确认 FCS 与 HIS 的在线状态，避免在离线副本上操作导致导出内容与现场不一致。随后通过 Project 菜单执行工程导出，选择完整导出而非增量导出，确保 Function Block、I/O 分配、Sequence Table 等一并落盘。
导出完成后，不要急于关闭。应在 System View 中逐项核对导出清单与实际站点的对应关系，重点关注三类异常：一是存在但未分配 I/O 的“空回路”，二是被旁路或强制（Force）的位号，三是名称与注释不一致的位号。这些异常在迁移后极易变成“新系统里没有”或“行为不一致”的投诉来源。
用 CI Server 建立可追溯的版本基线
System View 解决的是“导出什么”，CI Server 解决的是“什么时候是什么”。CI Server 作为集中工程管理平台，能够对 FCS 与 HIS 的工程数据做定期或手动备份，并保留版本历史。盘点的正确做法是：在确认现场处于稳定工况后，通过 CI Server 对全部站点执行一次完整备份，并为其打上明确的版本标签，例如 BASELINE-2024Q2-PRE-MIG。
这个标签不是形式主义。它意味着此后任何一次比对，都以该标签为基准：新导出的组态与它比，迁移后的组态也与它比。没有标签，版本历史就只是一堆时间戳，无法回答“迁移前到底是什么样”。
CI Server 备份时需要注意两点。其一，备份应覆盖 FCS 与 HIS 两侧，只备份 FCS 会遗漏图形资产。其二，备份完成后应校验备份文件的完整性，并在另一台机器上尝试恢复验证，避免出现“备份成功但无法恢复”的假安全。
形成可追溯的资产清单
导出与备份只是原料，真正交付的成果是一份结构化的资产清单。清单不必追求字段繁多，但必须能回答四个问题：这个资产是什么、在哪里、属于哪个版本、迁移时如何处理。下表给出一个可直接参考的清单结构示例，字段可根据项目规模增减。
| 资产类别 | 标识/名称 | 来源站点 | 导出方式 | 基线版本标签 | 迁移处理建议 |
|---|---|---|---|---|---|
| FCS 组态 | FCS0101 工程库 | FCS0101 | System View 完整导出 | BASELINE-2024Q2-PRE-MIG | 整体迁移，逐回路核对 |
| HIS 图形 | 流程图窗口组 A | HIS0111 | CI Server 备份 | BASELINE-2024Q2-PRE-MIG | 图形重绘或转换，需人工确认 |
| 顺序逻辑 | SEQ-BATCH-03 | FCS0102 | System View 导出 | BASELINE-2024Q2-PRE-MIG | 逐条验证，重点测试 |
| 系统配置 | 网络与域配置 | 全局 | CI Server 备份 | BASELINE-2024Q2-PRE-MIG | 按新系统架构重新规划 |
清单中的“迁移处理建议”一列尤其重要。它把盘点从“记录现状”推进到“指导迁移”，使清单在后续阶段仍然可用，而不是归档后无人问津。
盘点中的常见陷阱
第一，只盘 FCS 不盘 HIS。图形资产的数量往往远超预期，遗漏后会在迁移后期造成大量返工。第二，忽略强制值与旁路。这些状态在正常运行时可能长期存在，导出时若不记录，迁移后会被当作“新系统丢失的功能”。第三，不做版本标签。没有标签的备份无法支撑比对，等于没有基线。第四，清单只列名称不列处理建议，导致盘点成果无法直接进入迁移计划。
完成上述工作后，项目组应当得到一份带版本标签的资产清单、一套完整的导出文件与 CI Server 备份，以及一份记录在案的异常项列表。这三者共同构成迁移的基线。此后所有迁移活动——无论是组态转换、图形重绘还是逻辑验证——都以这份基线为起点和比对依据。基线一旦冻结，任何变更都必须走变更记录，否则迁移前后的差异将无法归因，回退也将失去可靠参照。