Event Frames:工业数据领域最精彩的设计之一,在 AI 时代为什么更重要?
这么多年来,PI System 里有一个概念一直让我印象非常深刻:Event Frames(事件框架)。对于处理工业运营数据的人来说,这个想法既简单又非常强大。传统上,我们往往只是看连续的时序数据信号。但 Event Frames 的思路是:把连续的数据流转换成离散的运营事件。 一个 Event Frame 通常包含: 例如: 这种结构把原始的传感器信号转换成了具有业务语义的生产运营上下文。一旦有了这些事件,很多问题就变得容易回答: 从某种意义上说,Event Frames 把信号变成了关于生产运营的故事。 今天,很多企业开始采用现代实时数据技术,比如 Spark 或 Flink 来做流式分析。这些系统非常强大,但它们主要是为数据工程师(Data Engineers) 设计的,而不是为 OT 工程师设计的。理论上,你完全可以在这些流处理系统里实现事件检测。但在实际工程中,通常需要: 在传统 OT 系统里的一条简单规则,在现代流处理框架中,往往会变成上百行代码。对于制造现场的工程师来说,这就带来了一个明显的问题:技术虽然更强大了,但使用门槛却变高了。 在 AI 时代,仅仅有原始的时序数据是不够的。AI 系统更擅长处理结构化、有语义、有上下文的数据。 例如,与其把模型训练在大量原始信号上: 很多时候更有价值的是这样的结构化事件: 这些事件成为运营智能的重要基础单元。它们可以用于: 换句话说,Event Frames 实际上是连接原始数据与运营洞察之间的桥梁。这也是为什么我认为,在 AI 时代,这个概念反而比当年刚提出时更加重要。 PI System 在 Event Frames 的设计上做得非常出色,并且让 OT 工程师能够非常容易地使用它。但很多传统的数据 Historian 架构并不是为今天的 AI 和现代数据生态设计的。今天我们需要的平台,能够同时结合: 在 TDengine 中,我们采用了一种稍微不同的方式。TDengine 内置了流处理引擎,并提供了图形化界面(GUI)用于配置规则和表达式,可以直接从实时的时序数据流中生成 Event Frames。 在 大语言模型(LLM) 的帮助下,TDengine 甚至可以根据数据的上下文自动生成事件检测规则,或者自动识别异常。在很多情况下,用户还可以用自然语言描述自己的需求,系统就可以将其转换成底层的规则。我们的一个核心设计原则是:OT 工程师不应该需要编写流处理代码。 用户只需要在运营层定义规则和逻辑,而系统会自动处理: 最终的用户体验与工程师在 PI System 中熟悉的方式类似,但底层架构则建立在现代基础设施之上,并且从一开始就是 AI-ready 的工业数据平台。 工业数据平台正在快速演进。但很多时候,最有价值的想法并不是最新的,而是那些真正解决问题的设计。 Event Frames 就是这样一个理念。它把原始传感器信号转换成有意义的运营事件——既能被工程师理解,也能被 AI 系统利用。随着 Industrial AI 的发展,我相信以事件为中心的业务运营数据模型(event-centric operational data model) 会变得越来越重要。 未来,AI Agent 不只是分析时序信号。它们会理解事件、流程和运营上下文。 而这一切的起点,就是把数据变成事件。
现代数据基础设施带来的挑战
为什么 Event Frames 在 AI 时代更重要
传统 Data Historian 的局限

TDengine 的设计思路

展望未来