📚 课程目录第3章 PI系统概述

3. PI系统概述

PI System 是 OSIsoft（现属 AVEVA）推出的工业实时数据基础设施，其核心价值在于把分散在 DCS、PLC、SCADA、仪表和第三方系统中的过程数据，以统一的时间序列模型长期存储，并通过资产模型、接口层和 Web 服务对外提供访问能力。理解 PI System，不能只记住几个产品名称，而要看清“数据从哪里来、存在哪里、如何被组织、又怎样被消费”这条完整链路。

从工程视角看，PI System 可以概括为四层：接入层负责采集，存储层负责长期归档，建模层负责语义组织，服务层负责对外发布。PI Interfaces、PI Connectors 属于接入层；PI Data Archive 是存储层核心；PI Asset Framework（AF）是建模层；PI Web API 则是服务层的重要出口。

一、整体架构：从现场信号到业务应用

PI System 的典型架构是一条自下而上的数据流。最底层是现场设备与控制系统，包括 DCS、PLC、RTU、智能仪表和 SCADA 历史库；其上是接口与连接器，负责把不同协议、不同厂商的数据转换为 PI 可识别的标签值和时间戳；再往上是 PI Data Archive，它以时间序列方式存储每个测点的历史数据；PI Asset Framework 在数据之上建立设备、装置、管线、机组等资产层级和属性关系；最终由 PI Web API、PI Vision、PI DataLink 等工具向 MES、ERP、报表平台和 Web 前端提供数据服务。

二、PI Data Archive：时间序列的“主仓库”

PI Data Archive 是 PI System 的存储核心，其基本存储单元是 PI Point，也就是常说的“标签”或“位号”。每个 PI Point 包含名称、描述、工程单位、量程、点类型、压缩参数等属性，并按时间顺序保存数值、时间戳和质量码。它采用专有的压缩算法，在保证趋势形态不失真的前提下大幅降低存储量，因此可以保存数年甚至数十年的秒级数据。

PI Data Archive 的典型访问方式包括 PI SDK、PI API、AF SDK 以及通过 PI Web API 间接访问。工程中常见的操作包括创建标签、回填历史数据、查询归档值、计算平均值和统计量。例如，使用 PI DataLink 或 AF SDK 读取某标签一段时间内的归档值，通常需要指定时间范围和采样方式：

Tag: BA_101_FLOW
Start: 2024-06-01 00:00:00
End:   2024-06-01 08:00:00
Mode:  Average
Interval: 1h
Result: 08 个归档统计值

需要注意的是，PI Data Archive 只负责“存”和“取”，不负责业务语义。一个标签叫 BA_101_FLOW，系统并不知道它属于哪条产线、哪台泵、哪个工段。这正是 PI Asset Framework 要解决的问题。

三、PI Asset Framework：给数据加上“业务语义”

PI Asset Framework 是建立在 PI Data Archive 之上的资产建模层。它把孤立的标签组织成有层级、有属性、有关系、有计算逻辑的资产模型。例如，一个“锅炉给水泵”资产可以包含入口压力、出口压力、流量、电流、振动等属性，这些属性分别映射到不同的 PI Point；同时，泵又隶属于某个“给水系统”，给水系统隶属于某台“机组”。这样，上层应用就可以按设备、装置、产线来查询数据，而不是按标签名硬编码。

AF 的核心能力包括：元素模板（Element Template）实现同类设备复用；属性映射（Attribute）把 PI Point 或计算表达式绑定到资产属性；关系（Relationship）描述设备之间的连接和从属；分析（Analysis）支持在 AF 中直接定义计算、触发和回写；事件框架（Event Frame）用于记录批次、报警、停机等有时间边界的业务事件。

在 PI 项目中，AF 建模质量往往决定项目成败。标签命名规范、模板设计、层级划分和权限策略，应在实施初期统一规划，避免后期“标签能查到、资产找不到”的尴尬。

四、PI Interfaces 与 PI Connectors：接入层的两条路线

PI Interfaces 是传统接入方式，通常以 Windows 服务形式部署在采集节点上，支持 OPC DA、OPC HDA、Modbus、RDBMS、SNMP、CSV 等多种协议。它的优势是成熟稳定、协议覆盖广、可精细控制采集频率和异常处理；缺点是配置相对繁琐，部分接口需要单独安装和授权，且对 OPC UA 等新协议的支持依赖版本。

PI Connectors 是新一代接入方式，强调“开箱即用”和自动建模。以 OPC UA Connector 为例，它可以在连接数据源后自动发现节点、创建 PI Point，并同步生成 AF 资产结构，大幅减少手工配置。对于新建项目或云边协同场景，Connectors 通常更易维护；对于老旧 DCS 和特殊协议，Interfaces 仍然不可替代。

对比维度	PI Interfaces	PI Connectors
典型协议	OPC DA、Modbus、RDBMS、SNMP	OPC UA、AVEVA 原生、云数据源
部署方式	采集节点独立服务	集中管理，支持自动发现
建模能力	以标签为主，AF 需另行配置	自动创建标签与 AF 资产
适用场景	老旧系统、特殊协议、精细控制	新建项目、OPC UA、快速上线
运维复杂度	较高，需逐点核对	较低，但需关注自动命名规范

五、PI Web API：面向 Web 与微服务的数据出口

PI Web API 是 PI System 对外提供 RESTful 服务的关键组件。它把 PI Data Archive 和 AF 的能力封装为 HTTP 接口，返回 JSON 数据，支持流式读取、批量查询、OData 过滤和跨域访问。前端看板、移动应用、数据中台和第三方系统，都可以通过 PI Web API 获取实时值、历史趋势、资产属性和事件框架数据。

一个典型的实时值查询请求如下：

GET /piwebapi/streams/{webId}/value
Accept: application/json

{
  "Timestamp": "2024-06-01T08:00:00Z",
  "Value": 125.6,
  "UnitsAbbreviation": "t/h",
  "Good": true
}

工程中需要重点关注：WebId 的稳定性、认证方式（Kerberos / Basic / OAuth）、跨域策略、批量请求上限以及缓存设计。若把 PI Web API 直接暴露给高并发前端而不做缓存和限流，容易造成 PI Data Archive 压力过大。

六、常见误区与复盘要点

把 PI Data Archive 当数据库用：它擅长时间序列读写，不适合复杂关联查询和事务处理，业务语义应放到 AF 或外部数据库。
标签命名随意：后期 AF 建模和 Web API 查询都会变得困难，建议在接入前统一命名规范。
忽视接口与连接器的边界：不是所有协议都能用 Connectors 替代，选型前要确认数据源类型和版本。
Web API 无缓存直连：高频查询应加缓存、限流和批量合并，避免打爆归档层。
AF 模型与现场不一致：设备改造后未同步更新 AF 层级，会导致看板数据错位，应建立变更同步机制。

总体而言，PI System 不是单一软件，而是一套从现场接入、时间序列存储、资产建模到 Web 服务发布的完整数据链路。PI Interfaces 与 PI Connectors 解决“数据进得来”，PI Data Archive 解决“数据存得住”，PI Asset Framework 解决“数据看得懂”，PI Web API 解决“数据用得上”。只有把这四层关系理清，后续的接口开发、OPC 接入和数据消费才能有稳定的架构基础。