📚 课程目录第2章 PI System事件框架核心概念

2. PI System事件框架核心概念

在 PI System 中，“事件”并不是一个孤立的报警记录，而是一套围绕时间、上下文和业务语义组织起来的数据结构。理解事件框架，关键在于分清六个层层递进的概念：事件、事件帧、事件类型、事件属性、事件模板，以及事件关联与事件生命周期。它们共同回答三个问题：发生了什么、在什么背景下发生、这件事如何被持续跟踪和复用。

事件与事件帧：从“一个点”到“一段时间”

事件（Event）是事件框架的最小业务单元，代表一次值得记录和关注的情况。它通常由开始时间、结束时间、持续时长、当前状态和一组属性构成。例如某台泵在 2024-06-11 08:12:30 出现“轴承温度高”报警，08:19:10 恢复，这就是一个事件。

事件帧（Event Frame）是 PI System 中对事件的正式承载对象。它把“事件”从抽象概念变成可存储、可查询、可关联的实体。事件帧的核心字段包括：

Name：事件帧名称，如 P-101_BearingTempHigh_20240611；
StartTime / EndTime：起止时间戳，决定事件的时间边界；
Duration：持续时长，可由结束时间减开始时间得到；
Template：所属事件模板，决定它拥有哪些属性；
Attributes：事件属性集合，如设备位号、报警值、峰值、处理人；
Referenced Elements：关联的 PI AF 元素，如泵、管线、机组。

事件帧与普通 PI 点最大的区别在于：PI 点记录的是连续时间序列上的数值，而事件帧记录的是“有始有终”的业务片段。一个事件帧可以引用多个 PI 点、多个 AF 元素，也可以嵌套子事件帧，从而表达“大事件中包含小事件”的层次关系。

事件类型、事件属性与事件模板

事件类型（Event Type）用于对事件做业务分类，例如“设备故障”“工艺越限”“质量异常”“计划停车”。类型决定了事件在分析视图中的分组方式，也影响后续统计口径。实际项目中，事件类型通常与事件模板绑定，避免同一类事件出现字段不一致。

事件属性（Event Attribute）是事件帧上承载具体信息的字段。属性分为静态属性和动态属性：静态属性如设备位号、所属装置、责任人；动态属性如触发值、峰值、恢复值、持续时长。属性值可以来自 PI 点、AF 属性、公式计算或人工填写。例如：

EventFrame: P-101_BearingTempHigh_20240611
  Template: Pump_Alarm_Event
  Attributes:
    EquipmentID      = P-101
    AlarmTag         = P-101.BearingTemp
    TriggerValue     = 78.5 °C
    PeakValue        = 83.2 °C
    Duration         = 6 min 40 s
    Operator         = 张工
    EventType        = 设备故障

事件模板（Event Template）是事件帧的“类型定义”，相当于一张表单模板。它规定了某一类事件必须包含哪些属性、属性的数据类型、默认值、是否必填，以及事件帧的命名规则。模板让事件从“随手记录”变成“结构化数据”。例如可以定义 Pump_Alarm_Event 模板，要求所有泵类报警事件都必须填写 EquipmentID、AlarmTag、TriggerValue、PeakValue、Operator 和 EventType。这样在后续做事件统计时，不会因为字段缺失而无法聚合。

事件关联与事件生命周期

事件关联（Event Correlation）解决的是“多个事件之间是什么关系”。常见关联方式包括：

时间关联：同一时间窗口内发生的多个事件，如“电机跳闸”与“电流归零”同时出现；
层级关联：父事件帧包含子事件帧，如“装置停车”包含“泵停机”“阀关闭”；
因果关联：一个事件是另一个事件的原因或结果，如“冷却水流量低”导致“轴承温度高”；
元素关联：多个事件帧引用同一个 AF 元素，如同一台泵的多次报警。

事件生命周期（Event Lifecycle）描述事件帧从产生到关闭的完整状态变化。典型状态包括：

Created：事件帧被创建，开始时间写入；
Active：事件正在进行，属性值持续更新；
Closed：事件结束，结束时间写入，持续时长确定；
Acknowledged：操作员已确认，记录确认人和确认时间；
Archived：事件进入历史归档，用于长期分析和审计。

生命周期状态不是必须全部出现，但“创建—活动—关闭”是基本链路。对于需要人工处理的事件，确认和归档环节决定了事件能否闭环。实际配置时，可以通过 AF 分析或 Event Frame 生成器自动创建事件帧，也可以由外部系统通过 PI Web API 写入事件帧。

实际配置中的关键判断

在 PI AF 中创建事件模板时，需要先明确三个问题：这类事件由什么触发、需要记录哪些字段、由谁负责关闭。触发方式通常有两种：一是基于 PI 点的条件分析，例如当 P-101.BearingTemp > 75 且持续 30 秒时创建事件帧；二是基于外部系统调用 PI Web API 写入。前者适合自动监测，后者适合工单、实验室结果等外部事件。

事件帧的命名规则建议包含设备位号、事件类型和时间戳，例如 {EquipmentID}_{EventType}_{yyyyMMddHHmm}。这样在 PI Vision 或 PI DataLink 中检索时，可以直接按名称过滤，而不必逐条打开属性。属性字段不宜过多，优先保留分析必需的字段：触发值、峰值、持续时长、责任人、处理状态。字段过多会导致录入负担增加，反而降低事件数据的完整性。

事件模板一旦投入使用，修改属性字段会影响已有事件帧的显示和查询。建议在模板设计阶段先小范围试用，确认字段和命名规则稳定后再批量推广。

事件关联和生命周期是事件框架从“记录”走向“分析”的关键。只有把同一设备、同一班次、同一原因的事件关联起来，才能回答“哪台设备报警最多”“哪个班次处理最慢”“哪类事件反复发生”。生命周期状态则让事件具备闭环管理能力：未确认的事件可以被筛选出来，已归档的事件可以用于月度复盘。理解这六个概念之间的层次关系，是后续使用 PI Event Frame 做生产事件分析的基础。