📚 课程目录第2章现状评估与资产盘点

2. 现状评估与资产盘点

迁移与升级项目最容易失控的地方，不是技术难度，而是“不知道自己有什么”。在动手迁移之前，必须把现有 PI System 的资产完整清点一遍，形成一份可核对、可追溯的基线清单。这份清单既是迁移范围的依据，也是升级后验证“有没有丢东西”的对照标准。本节按六类资产分别说明清点对象、获取手段和判断要点。

一、PI Data Archive：从点数与标签入手

PI Data Archive 的清点核心是“标签（Tag）与点数（Point）”。需要统计的总量指标包括：Point 总数、按 Point Source 分组的数量、按 Point Type 分组的数量、压缩开关（Compression）开启比例、异常标签（如无数据、长期不更新、质量码长期 Bad）数量。

获取方式主要有三种。第一种是通过 PI SMT 的 Points 列表导出，适合中小规模；第二种是使用 PI OLEDB / PI SQL 查询 PI Points 表，适合批量统计；第三种是通过 PI Web API 的 /dataservers/{webId}/points 接口分页拉取。以下是一段典型的 PI SQL 统计示例：

SELECT pointsource, pointtype, COUNT(*) AS cnt
FROM [PI Points]
GROUP BY pointsource, pointtype
ORDER BY cnt DESC;

清点时特别要关注三类“隐性负担”：一是历史归档文件（Archive）的数量与大小，它直接决定迁移的数据量和停机窗口；二是接口写入频率极高的标签，迁移时容易造成数据堆积；三是已废弃但仍保留的标签，应在迁移前决定是清理还是保留。建议为每个标签记录：Tag 名、描述、Point Source、Point Type、扫描周期、是否压缩、所属接口、业务归属。

二、PI AF：结构比数量更重要

PI AF 的清点不能只看“有多少元素”，而要看结构。需要盘点：AF Server 数量、AF Database 数量、Element Template 数量、Element 数量、Attribute 数量、Analysis 数量、Notification 规则数量、AF 与 PI Data Archive 的映射关系。

关键判断点是“AF 是否被真正使用”。有些现场 AF 只建了模板和少量元素，实际计算仍靠接口或外部脚本；有些现场 AF 承载了大量 Analysis 和 Notification，是业务逻辑的核心。这两类在迁移策略上完全不同。清点时应导出每个 Analysis 的表达式、触发方式（事件触发或周期触发）、输出 Attribute，以及它依赖的输入标签。若 Analysis 之间存在级联，还要记录依赖顺序，否则迁移后会出现计算顺序错乱。

三、接口：按协议与数据源分类

接口清点要回答三个问题：有哪些接口、它们连什么、以什么频率写数据。常见接口包括 OPC DA/UA、PI Interface for Modbus、PI Interface for OPC DA、PI UFL、PI RDBMS Interface、CSV 文件接口等。对每个接口记录：接口名称、运行节点、协议类型、数据源地址、扫描周期、写入的 Point Source、健康状态（是否长期报错、是否有数据丢失）。

接口是迁移中最容易出问题的环节，因为很多接口运行在老旧 Windows 服务器上，依赖特定版本的驱动或 DCOM 配置。清点时建议同时记录接口所在主机的操作系统版本、PI 接口版本、是否使用 PI Buffer Subsystem（缓冲子系统）。如果接口带缓冲，还要确认缓冲文件路径和当前积压量，避免迁移时把积压数据一起带过去。

四、用户与权限：谁在用、怎么用

用户清点包括 PI Data Archive 的 PI Identity、PI Mapping、PI Trust，以及 AF 的 Windows 组映射。需要统计：活跃用户数、只读用户数、管理员账号、服务账号、映射到哪些 PI Identity、对应哪些数据权限。特别要识别“服务账号”——接口、报表、第三方系统使用的账号往往不是真人，迁移时如果漏掉，会导致接口或报表在升级后无法连接。

五、报表与第三方集成：最容易被忽略的依赖

报表清点要覆盖 PI DataLink、PI ProcessBook、PI Vision、以及外部 BI 工具（如 Excel、Power BI、Tableau）通过 PI OLEDB 或 PI Web API 取数的场景。对每个报表记录：名称、使用工具、取数方式、依赖的标签或 AF 元素、刷新频率、使用部门。第三方集成则包括 MES、ERP、LIMS、SCADA 等系统与 PI 的接口方向（读或写）、协议、数据量级。

报表和第三方集成往往没有集中登记，建议采用“反向追踪”方法：从 PI Data Archive 的连接日志、PI Web API 的访问日志、以及接口节点的网络连接中反查调用方，再逐一确认。

六、清点结果的组织方式

六类资产清点完成后，应汇总为一份资产基线表，并标注每项资产的迁移优先级和风险等级。下图展示了六类资产的清点对象、获取手段与输出物之间的关系，可作为盘点工作的组织框架。

盘点不是一次性动作，而应形成可重复执行的流程。建议在迁移前、迁移中、迁移后各执行一次：迁移前建立基线，迁移中核对进度，迁移后逐项验证。对于数量庞大的标签和元素，不必逐条人工核对，但必须保证“总量一致、关键项可追溯”。例如，迁移前 Point 总数为 120000，迁移后应为 120000（或按清理计划减少），若出现明显缺口，就要定位是哪些 Point Source 或 Point Type 丢失。

清点时不要只依赖文档和台账。很多现场的接口、报表、第三方集成从未登记在册，必须结合运行日志、网络连接和实际访问记录反查，否则迁移后会出现“系统看起来正常，但某个报表或 MES 接口悄悄失效”的情况。

最后，把六类资产的清点结果统一编号，形成资产 ID 体系，并与迁移任务一一对应。这样在升级后的验证阶段，可以按资产 ID 逐项确认：数据是否完整、接口是否恢复、用户是否可登录、报表是否可刷新、第三方集成是否正常通信。盘点做得越扎实，迁移和升级的不可控因素就越少。