3. PI System架构交付物审查
架构交付物审查是PI System项目验收中最容易被“形式化通过”的一环。接口清单、拓扑图、高可用设计、网络分区和容量规划文档，往往在项目初期就已提交，但到验收阶段是否仍然与现场一致、是否覆盖了所有数据源和消费方、是否经得起故障切换和扩容的推演，才是审查的真正重点。本节按五类交付物分别说明验收要点，并给出可执行的核对方法。
一、接口清单：从“有列表”到“可追溯”
接口清单不是一张简单的Excel表，而应是一份可追溯的数据源台账。验收时重点核对四个维度：源系统、采集方式、接口类型、数据流向。一个合格的接口清单至少应包含以下字段：接口编号、源系统名称与版本、PI接口产品（如PI Interface for OPC DA、PI UFL、PI Web API、PI Adapter for OPC UA）、采集协议、扫描周期或订阅方式、点位数量、时间戳来源、断线缓存策略、责任人、投运日期。
验收时建议采用“抽样反查”方法：从PI Data Archive中随机抽取20～30个位号，反查其来源接口，再与接口清单比对。若出现位号无法归属到任何接口，或清单中某接口在PI中找不到对应位号，说明清单已失效。此外，要特别关注接口冗余配置是否在清单中体现——例如同一源系统配置了主备两个接口节点，清单中应分别列出并标注主备关系，而不是合并为一行。
二、PI Data Archive与PI AF服务器拓扑
拓扑审查的核心是确认“谁是谁、谁连谁、谁依赖谁”。PI Data Archive（简称PIDA）与PI AF Server可以同机部署，也可以分离部署。验收时需明确以下关系：PI AF Server通过PI AF Client或PI SQL连接PIDA；PI Vision、PI Web API、PI DataLink等消费端连接PIDA或AF；接口节点连接PIDA；AF分析服务依赖PIDA数据。任何一条连接关系缺失，都会导致上线后功能不可用。
拓扑图中应标注每台服务器的主机名、IP地址、角色、操作系统版本、PI产品版本、所属域。验收时需核对拓扑图与现场实际是否一致，尤其是主机名和IP。常见问题是拓扑图仍为设计阶段版本，现场已更换服务器或调整IP，但文档未更新。建议在验收现场执行一次“拓扑走查”：登录每台服务器，确认PI服务运行状态、连接目标、端口监听情况，并与拓扑图逐项对照。
三、高可用设计：验证“切换真的会发生”
高可用设计文档不能只写“采用主备模式”，必须明确切换机制、切换条件、切换时间和数据完整性保障。PI Data Archive的集体（Collective）支持成员间自动故障转移，验收时应确认：集体成员数量、各成员角色、成员间网络延迟、归档同步状态。PI AF Server的高可用通常依赖SQL Server Always On或故障转移集群，需确认AF数据库所在SQL实例的高可用配置。
接口层的高可用同样关键。对于OPC DA接口，常见做法是配置两个接口节点，通过PI ICU设置主备，并启用缓冲（Buffering）。验收时应实际执行一次切换测试：停止主接口节点服务，观察备节点是否在约定时间内接管，数据是否出现断档。若条件允许，还应测试PIDA主成员停止后，接口是否自动重连到备成员，以及AF分析是否继续正常计算。
四、网络与安全分区
PI System通常跨越控制网、生产管理网和办公网。验收时需核对网络分区图与防火墙策略是否一致。关键检查点包括：接口节点到源系统的端口（如OPC DA的135/TCP及动态端口、OPC UA的4840/TCP）；接口节点到PIDA的5450/TCP；PI AF Client到PIDA的5450/TCP；PI Vision到PIDA/AF的端口；PI Web API的443/TCP。每个连接方向都应有明确的源IP、目的IP、端口和策略编号。
安全分区还应关注单向隔离场景。若控制网与生产管理网之间部署了单向网关，接口节点的部署位置和缓冲策略需要特别说明：接口应部署在控制网侧，通过单向网关将数据推送到管理网侧的PIDA，还是采用其他方案。验收时需确认数据流向与隔离装置的方向一致，避免出现“数据能进不能出”或“反向连接被阻断”的问题。
五、容量规划文档：从“当前够用”到“可推演”
容量规划文档的验收要点是可推演、可验证。文档应包含：当前位号总数、每秒事件数（Event per Second）、归档文件大小与保留周期、磁盘剩余空间、PI AF元素与属性数量、PI Vision用户数与并发数。验收时可将文档中的预估值与实际运行值对比，偏差超过30%即需说明原因。
一个实用的容量核对表如下：
| 容量项 | 规划值（示例） | 验收核对方法 | 判断依据 |
|---|---|---|---|
| 位号总数 | 80,000 | PI SMT → Points 统计 | 实际不超过规划值110% |
| 事件速率 | 25,000 events/s | PI Performance Monitor 观察 | 峰值不超过规划值120% |
| 归档保留 | 3年 | 归档文件时间跨度与磁盘占用 | 剩余空间可支撑至少12个月 |
| AF元素数 | 15,000 | PI AF Explorer 统计 | 与规划偏差不超过20% |
| PI Vision并发 | 50 | 压力测试或日志分析 | 响应时间小于3秒 |
容量规划还应包含扩展余量说明。例如，若未来两年计划新增20,000点位，文档应说明现有服务器CPU、内存、磁盘IO能否支撑，是否需要提前扩容。验收时若发现文档只描述当前状态、未给出扩展判断，应要求补充。
六、五类交付物的交叉一致性检查
五类交付物不是孤立的。接口清单中的每个接口，都应在拓扑图中有对应节点；拓扑图中的每台服务器，都应在高可用设计中有角色说明；高可用设计中的每个连接，都应在网络分区中有对应策略；容量规划中的每个数值，都应与接口清单中的点位数、拓扑中的服务器规格相互印证。验收时建议做一次交叉检查：随机抽取一个接口，沿“接口清单→拓扑图→高可用设计→网络策略→容量规划”走一遍，若任一环节缺失或矛盾，即视为交付物不完整。
最后，所有交付物都应标注版本号、编制日期、编制人、审核人，并确认现场使用的是最新版本。架构交付物审查的目标不是“文档齐全”，而是“文档与现场一致、可支撑运维和扩容”。只有通过交叉核对和实际切换验证，才能确认PI System的架构交付物真正具备验收条件。