3. PI System架构与事件数据流

在 PI System 中，一个生产事件从“发生”到“被看见”，并不是由单一组件完成的，而是由 PI Data Archive、PI AF、PI Vision 和 PI Web API 四个核心组件分工协作、逐层传递的结果。理解它们各自的角色和相互之间的数据流方向，是后续做事件框架设计、事件检测和事件分析的基础。很多初学者容易把 PI AF 和 PI Vision 混为一谈，或者认为 PI Web API 只是“给 PI Vision 用的接口”，这些理解都会影响事件方案的设计质量。

四个组件的核心定位

PI Data Archive 是 PI System 的时序数据底座。它存储的是带时间戳的原始测量值，例如某台泵在 2024-06-01 08:15:00 的出口压力为 1.82 MPa，08:15:10 为 1.79 MPa。它本身不理解“什么是事件”，只负责高效写入、压缩、查询时间序列。事件产生阶段，PI Data Archive 提供的是“事实来源”——所有判断都基于它里面的时间序列。

PI AF（PI Asset Framework） 是语义与计算层。它把 PI Data Archive 中的标签（Tag）组织成有业务含义的资产模型，例如“1号锅炉给水泵”这个元素（Element）下挂“出口压力”“轴承温度”“运行状态”等属性（Attribute），属性通过数据引用（Data Reference）指向 PI Data Archive 中的具体 Tag。更重要的是，PI AF 支持分析（Analysis），可以基于属性做计算、条件判断和事件触发。事件框架中的“事件定义”“事件条件”“事件属性”通常都落在 PI AF 这一层。

PI Vision 是面向操作人员和工程师的可视化层。它把 PI AF 中的元素、属性和事件以图形、趋势、表格、事件列表等形式展示出来。PI Vision 本身不做事件计算，它展示的是 PI AF 和 PI Data Archive 已经准备好的数据与事件结果。

PI Web API 是面向外部系统和 Web 应用的 REST 接口层。它把 PI Data Archive、PI AF、PI Vision 的能力以 HTTP/JSON 方式暴露出来，供第三方系统、报表平台、移动端或自定义前端调用。在事件数据流中，PI Web API 既是“读取通道”，也可以是“写入通道”——例如外部系统通过它把事件确认、事件注释写回 PI AF。

事件数据流的方向与分工

把四个组件串起来看，事件数据流可以概括为：PI Data Archive 产生原始时序 → PI AF 做语义绑定与事件计算 → PI Vision 做事件展示 → PI Web API 做对外交换。这个方向不是单向死板的，PI Web API 也可以反向把外部事件写回 PI AF，PI Vision 也可以通过 PI Web API 读取数据。但作为教学主线，先掌握正向流，再理解反向写回，是最稳妥的路径。

关键理解：谁负责“事件”，谁负责“数据”

从上面的数据流可以看出，PI Data Archive 只负责“数据”，不负责“事件”。它不知道 1.95 MPa 意味着什么，也不知道这个值是否构成事件。真正把“数据”变成“事件”的是 PI AF。PI AF 中的 Analysis 可以按固定周期（例如每 10 秒）或按事件触发方式运行，读取属性值，执行表达式，当条件满足时生成事件记录。事件记录本身可以存储在 PI AF 的事件框架中，也可以作为属性值写回 PI Data Archive 的某个 Tag，供其他系统读取。

PI Vision 的角色是“让事件被看见”。它通过 PI AF 的元素层级和事件列表，把事件按设备、按时间、按严重程度组织起来。操作员在 PI Vision 画面上看到的“事件列表”，其数据来源通常是 PI AF 的事件属性或 PI Data Archive 中的事件状态 Tag。PI Vision 不重新计算事件，它只是展示。

PI Web API 的角色是“让事件被交换”。当事件需要推送到企业微信、短信平台、MES 或自研报表系统时，通常不直接连 PI Data Archive，而是通过 PI Web API 以 REST 方式读取 PI AF 的事件属性或 PI Data Archive 的时序值。反过来，外部系统的确认动作也可以通过 PI Web API 写回 PI AF 的事件属性，形成闭环。

一个可参考的事件数据流配置示例

假设我们要为“1号给水泵出口压力高”设计一条完整的事件数据流，可以按以下方式落地。以下参数均为教学示例，实际项目中需根据设备铭牌和工艺要求调整。

在这个示例中，PI Data Archive 每秒写入一个压力值；PI AF 每 10 秒运行一次 Analysis，检查最近 30 秒内是否持续超过 1.90 MPa；如果满足条件，就在 PI AF 中生成一条事件记录，并把事件状态写回一个名为 Pump01_Event_Status 的 Tag；PI Vision 的事件列表读取这个 Tag 或 PI AF 事件属性，显示“1号给水泵 出口压力高 08:16:00 持续中”；外部系统通过 PI Web API 读取该事件，并在操作员确认后通过 POST 把确认状态写回 PI AF，PI Vision 随即刷新显示“已确认”。

常见误区与排障方向

第一个常见误区是“在 PI Vision 上直接配事件条件”。PI Vision 是展示工具，不具备事件计算能力，事件条件必须落在 PI AF 或 PI Data Archive 中。第二个误区是“PI Web API 只用于读”。PI Web API 支持写入，事件确认、事件注释、事件状态回写都可以通过它完成。第三个误区是“PI AF 只是给 PI Vision 做画面用的”。PI AF 是事件框架的核心，事件定义、事件属性、事件触发逻辑都在这里，PI Vision 只是它的一个消费者。

排障时，可以按数据流方向逐段检查：先在 PI Data Archive 中确认 Tag 有正常写入的值；再在 PI AF 中检查 Attribute 的 Data Reference 是否指向正确的 Tag，Analysis 是否处于运行状态、表达式是否正确；然后在 PI Vision 中检查事件列表的数据源是否指向正确的 PI AF 元素或属性；最后用 PI Web API 的测试工具（如 Swagger）验证接口能否正常返回事件数据。按这个顺序排查，大多数事件“不产生、不显示、不交换”的问题都能快速定位到具体组件。

理解这四个组件的分工与数据流方向，是后续设计事件框架、配置事件检测、实现事件闭环的前提。事件不是某一个组件单独完成的，而是 PI Data Archive 提供事实、PI AF 赋予语义并计算、PI Vision 负责呈现、PI Web API 负责交换的协同结果。