3. PI System 体系结构

PI System 并不是一个单一软件，而是一套围绕工业时序数据构建的分层平台。理解它的体系结构，关键在于看清数据从现场设备进入长期归档，再被资产模型组织、被可视化与接口服务消费的完整链路。本节围绕 PI Data Archive、PI Interface、PI Asset Framework、PI Vision、PI Web API 五个核心组件，梳理它们的职责边界与协作关系。

一、核心原理：从信号到洞察的分层

PI System 的体系结构可以概括为“采集层—归档层—建模层—消费层”四段式。每一层解决不同问题，层与层之间通过标准接口解耦，因此可以独立扩展和替换。

• 采集层（PI Interface）：负责与 DCS、PLC、SCADA、OPC Server、关系数据库等数据源通信，把原始信号转换为 PI 点位（PI Point）的时序值。
• 归档层（PI Data Archive）：系统的“时序心脏”，以高效压缩算法长期存储海量测点的时间戳与数值，并提供历史查询、插值、汇总等能力。
• 建模层（PI Asset Framework，AF）：把扁平的点位组织成有业务含义的资产树，附加属性、单位、层级和计算，使数据具备“设备—产线—工厂”的语义。
• 消费层（PI Vision、PI Web API）：PI Vision 面向人，提供趋势、仪表盘和画面；PI Web API 面向系统，以 REST 方式把数据与资产模型开放给第三方应用。

这四层的关系不是简单串联，而是“归档层被建模层引用、建模层被消费层引用”的引用关系。PI Data Archive 是唯一的数据权威源，AF 不复制时序数据，只保存对点位的引用和计算定义，这一点是理解整个架构的关键。

二、方法流程：一次数据请求的完整路径

以“操作员在 PI Vision 上查看某台泵的出口压力趋势”为例，数据流经的路径如下：

1. PI Interface 从 PLC 读取压力信号，按扫描周期写入 PI Data Archive 对应点位。
2. PI Data Archive 将值存入 Snapshot 供实时读取，并按压缩规则归档到历史。
3. PI Vision 画面中的元素绑定的是 AF 中的 Attribute，而非直接绑定点位。
4. AF Attribute 通过 Data Reference 指向 PI Data Archive 中的具体点位。
5. PI Vision 通过 PI Web API 向 AF 与 Data Archive 发起查询，取回趋势数据并渲染。

这条链路说明：AF 是“语义中间层”，它让画面和报表不必关心点位命名，而只需关心“哪台设备的哪个属性”。当设备改名或点位迁移时，只需调整 AF 映射，消费层几乎不受影响。

三、组件职责与关键参数对照

四、案例场景：从“点位思维”转向“资产思维”

某化工厂最初把所有测点直接绑定到 PI Vision 画面，点位命名如 FIC101.PV。随着装置扩建，画面数量激增，点位改名导致大量画面失效。引入 AF 后，工程师建立“工厂—装置—设备—属性”的资产树，把 FIC101.PV 映射为“反应釜 A 的进料流量”属性。此后画面只引用资产属性，点位调整只需修改 AF 映射。

AF 资产路径示例：
  \\Plant01\AreaA\Reactor_A|Feed_Flow
    └─ Data Reference: PI Point = FIC101.PV
    └─ UOM: m3/h
    └─ Analysis: Feed_Flow_Total = TimeEq('Feed_Flow', '*-1d', '*')

五、常见误区与复盘

• 误区一：把 AF 当成数据库。AF 不存储时序值，只存储模型与引用。删除 AF 不会删除归档数据，但会丢失业务语义。
• 误区二：所有计算都放在 Data Archive。复杂业务计算应放在 AF Analysis 或上层应用，避免归档层承担过多逻辑。
• 误区三：PI Web API 直接查点位。推荐通过 AF 路径查询，便于权限控制和模型复用。
• 误区四：忽视接口冗余。关键接口应配置冗余实例或缓冲，避免网络中断造成数据缺口。