PI Event Frame 到 AI 时代，这个问题终于被重新看见了｜TDengine IDMP 的事件化启示

工业系统不间断地生成时间序列数据，每一秒，传感器都在记载温度、压力、流量、振动等各类信号，在过去几十年间，这始终是工业数据系统以及工业实时数据库的根基：收集信号，高效储存，并借由可视化觉察它们随时间的变动。

这种方式是有效的，但它存在一个根本性的局限。

仅时间当作序列排列的数据，仅仅能够告知我们“出现或产生了改变”，然而却没有办法去告知我们“究竟发生了哪些具体的事情”。

于趋势图之上，或许能够见到一回压力蓦地提升，然而那却没办法阐释此番变化究竟发生在开机的这个阶段，还是稳定运行之阶段，又或者是不是处于异常工况之下。温度的降低，可能是正常的调节情形，也有可能是故障的初期信号。要是缺少工业方面的上下文，不同的工程师面对同一小段数据，极有可能得出全然不一样的判断。这便是数据跟理解之间所存在的鸿沟。

工程师思考问题并非依据“时序数据”，也不只是按照“趋势”来进行思考，他们反而更倾向于依据“事件”去领会系统情况，像开机、停机、批次运行、工况切换、异常发生这些情况，这些才属于工业运行的基本单位，同时也是最具意义的分析对象。

由时序数据朝着事件转变，工业实时数据库究竟达成了什么正确之事，然而现代数据平台又遗漏了什么呢？

数据跟理解二者之间存在的鸿沟，并非是近几年才冒出来的状况，也并非行业没察觉到这个状况。实际上，工业数据范畴早就给出了一个特重要的答案。

PI System 提出了 Event Frame 的概念，该概念从根本上改变了工程师使用时间序列数据的方式，它不再把数据视为无穷无尽的数值流，而是允许工程师定义有明确起止时间的“有意义区间”，像开机、停机、批次运行或者异常状态，并且将这些事件与设备、属性以及上下文关联起来。

这属于一种极其关键的进步，它认可工业运行并非单纯是信号的简单叠加，而是由一系列具备明确意义的事件所组成，它促使数据模型开始靠近工程师的思维模式，还使得工程师能够从“查看数据”转变为“理解运行进程”，对众多用户而言，Event Frame是PI System里极具价值的能力之中的一个。

从这个特定角度去看，那以 PI 作为显著代表的工业实时数据库，并非是对这个问题有所漠视，相反地，在极为早期的时候就给予了一个相当正确的建模导向，然而，真正能够引发人们去进行深入思考的却是后续所发生的那些事情。

前行至行业朝着现代数据基础设施逐步演进之时，诸如 Snowflake、Databricks 这般的系统于存储、计算以及扩展性这些方面达成了极大突破，它们能够去处理数量庞大的数据，给予复杂分析以支持，并且与现代数据生态系统达成高度集成。

但在这个过程中，一个关键能力被忽略了。

这些系统的核心抽象依旧是表、文件以及通用的数据处理模型，它们并未提供像 Event Frame 那样的原生概念，系统里不存在“开机”“批次”“异常”这类第一类实体，工程师只能借助 SQL、数据管道或者自定义逻辑去重构这些语义。

这就带来了一个明显的错位。

基础设施呈现出更为强大的态势，然而，在操作层面上，数据的可理解性却出现了下降，数据能够更轻易地被进行存储以及计算，可是，对于工程师切实关切的问题：究竟发生了什么？从何时起始？与其他类似情形相比较会怎样？要做出回答则变得更为困难了。

所以，就算有着强大并且能够扩展的基础设施，然而真正以事件当作核心的分析依旧是很难达成的。问题并非在于计算能力方面，而是在于缺少一个以操作语义作为核心的数据模型。

事件建模与事件分析之间的鸿沟

即便 Event Frame 是个极为强大的概念，然而它于实际系统里的落地形式，亦透露出了一些限制之处。

在PI System里，Event Frame是于Asset Framework中被定义以及管理的，它能够把事件跟设备、时间区间还有相关属性关联起来，给工业操作行为提供了结构化的建模方式，这一能力相当重要，它让工程师能够明确地定义出像批次、开停机过程或者异常工况等关键运行阶段。

然而，当真正进入“分析”环节时，情况就开始变得分散。

于多数情形之下，工程师借助 PI Vision 等工具，于选定的时间窗口当中查看数据变化。此项方式适用于基础的排查及可视化，然而对于更深层次的事件分析而言其能力是有限的。

于实际工业场景里，诸多关键分析根本上皆是围绕“事件”来开展的。就拿批次生产来讲，工程师常常得对多个批次予以对比，以此去明白什么才是“好样的运行状态”。他们会把不同批次依据开始时间对齐，进而生成所谓的“黄金曲线（golden profile）”，随后剖析某一个异常批次在各个阶段究竟是怎样偏离这一基准的。这般分析对于质量优化、根因定位以及工艺改进是至关重要的。

这些批次借助 Event Frame 得以清晰分明地被定义且组织妥当，然而，真正进行包含时间对齐、实行归一化处理、展开统计对比以及开展模式识别的分析过程，在核心系统里并未获得深入的有力支持。所以呀，好多企业不得不引入 Seeq、TrendMiner 等专门的分析工具，以此来完成这些围绕事件展开的分析任务。

这实际上揭示了一个非常关键的架构问题。

事件的一个情况是建模存在着，然而事件分析却不曾和它深度融合起来。事件被进行定义这一动作完成了，可它并未成为分析的核心单位哟。工程师在由事件里提取洞察的时候，常常需要跨越多个系统，去搬运数据，并且在不同工具之间反复构建分析逻辑呢。

倘若事件属于工业运行的基本单元，那么它同样应当成为分析的基本单元。

从资产结构到运行行为

上一篇讨论“以资产为核心的数据建模”时，我们关注的是结构，即数据围绕设备和系统怎样去组织，这把“系统是什么”的问题给解决了。

而事件建模，则是在此基础上引入“行为”。

要是讲资产描绘的是系统自身，那事件描绘的便是系统于时间范畴里的运行进程，开机进程、批次运转、异常状况，这些并非静态势结构所能呈现的内容，而是运行举动的展现。

两者结合，才能构成对工业系统更完整的表达。

以资产为核心的建模定义结构。

以事件为核心的建模定义行为。

若不存在事件，数据便是连续性的数值流，依旧得通过人工予以解释，而当有了事件，系统自身便已然开始拥有表达运行过程的能力。

为什么在 AI 时代，事件变得更加重要

在 AI 时代，事件的重要性被进一步放大。

存在着许多直接作用于时间序列数据的AI应用，然而，这样的方式存在着天然的局限，原始信号既缺乏清晰的边界，又缺乏上下文 的信息，要是不知道数据所处的运行状态，那么很难正确理解其中的模式。

事件为 AI 提供了一种天然的结构。

它把数据划分成有意义的单元，致使系统能够针对相似事件作出对比，依据事件起点让数据达成对齐，剖析正常与异常之间存在的差异。更为关键的是，它给予了AI理解数据所必备的上下文。

倘若有一个AI模型，它不清楚设备究竟处于开机状态，还是停机状态，亦或是稳定运行状态，只是单纯地去分析振动数据，那么就极容易得出错误的结论。然而要是在有着清晰定义的事件范围之内展开分析，便能够明显提高结果的准确性以及可解释性。

在不存在事件的情形下，AI所见到的是数据，而当有了事件之后，AI才能够对行为予以理解。

走向以事件为核心的工业数据底座

想要切实发挥工业数据的价值，事件得成为工业数据底座的一部分，而不该只是附加于上层的功能。正因如此，如今的工业数据平台不能光停留在“存储 + 计算”层面，而得同时拥有事件建模、事件分析以及AI理解能力。就拿 TDengine IDMP 来说，它现今正将数据目录，以及数据标准化、数据情景化，还有事件、分析与 AI 能力，放置于同一个平台框架之内，从而使得事件不再仅仅是依附于时序数据的标志，转而开始变成能贯穿数据治理、业务分析以及智能决策的关键对象。像这样的平台方向，才会更加贴近 AI 时代工业数据底座实际该有的样子。

这意味着，事件的定义，不应分散在各异系统内，存储亦不应如此，分析同样不应如此，而应与时间序列数据一道，还应与资产模型一道，共同构成统一的工业数据平台基础。

PI System所提出的Event Frame，是极为关键的一个起始点。然而在AI时代，此项能力得要进一步予以提升，从“重要功能”转变为“基础能力”。

事件，它并不是仅仅作为分析的一种方式存在，相反，它是构建智能工业系统时，所绝对必需不可或缺，的组成部分。

时序数据描述变化，资产描述结构，事件描述行为。

这三者相互结合之后，才能够真正地做到对于工业运行的理解，也才能够去支撑那下一代的、以AI作为驱动力量的工业系统。

相关标签： # 工业数据 # 事件化 # AI时代 # TDengineIDMP # 数据理解