数据在增长，但洞察并没有同步增长
当今工业系统正在以前所未有的速度产生数据。传感器持续不断地从系统的各个环节采集高频信号，从温度、压力，到振动、流量以及设备状态，几乎所有运行信息都被数字化并记录下来。随着基础设施的发展，数据存储与吞吐早已不再是瓶颈，大规模的数据处理和分析能力也变得越来越容易获得。
但在这一切进步的背后，一个更本质的问题仍然存在。数据的规模在快速增长，但我们对数据的理解能力以及获得的洞察，并没有同步提升。
一个孤立的数据点本身很难承载真正的意义。85°C 的温度值，在某些工况下可能完全正常，而在另一些场景中却可能意味着严重异常。如果不知道这个数据属于哪台设备、处于什么工艺流程、是在什么运行状态下产生的，那么这个数值本身是模糊甚至具有误导性的。这并不是因为数据不够多，也不是因为计算能力不足，而是因为数据缺乏结构和上下文。
以 测点为中心的模型及其局限
在过去几十年中，大多数工业系统都是基于 Tag （测点）模型来组织数据的。每一个数据点由 Tag 名、时间戳和值构成，系统本质上存储的是一组时间序列信号。这种方式在数据采集层面非常有效，结构简单、灵活性高，也便于大规模部署。
但这个模型从一开始就不是为“理解系统”而设计的。工程师在分析问题时，并不会以 Tag 为单位思考，而是以设备和系统为单位。一个泵、一个锅炉或一条生产线，并不是由单一信号定义的，而是由一组相互关联的变量和运行行为共同构成的。
当数据以 Tag 的形式存在时，工程师不得不在分析过程中手动重建这些关系。他们需要判断哪些信号属于同一设备，理解不同信号之间的关联，并在此基础上推断系统当前的运行状态。随着系统规模的扩大，这种“在脑中重建模型”的方式变得越来越困难，数据与理解之间的鸿沟也随之扩大。
从信号到系统：以资产为核心的建模方式
以资产为核心的数据建模，本质上改变了工业数据组织的起点。它不再把单个信号视为最基本的对象，而是从设备、系统和工艺单元出发，去组织和理解数据。换句话说，数据不再只是“被采集到的一组值”，而是成为某个真实工业对象的一部分。温度不再只是一个 tag，而是某台锅炉、某个反应釜、某台压缩机的温度；压力不再只是一个数值，而是某个工艺流程在特定位置、特定阶段下的运行状态。
这种变化看起来像是数据组织方式的调整，但实际上它改变的是整个系统对数据的理解方式。在 tag 模型中，信号彼此独立存在，关系往往是隐含的，需要靠工程师经验或外部文档去补充。而在以资产为核心的模型中，关系本身成为模型的一部分。设备与设备之间的从属关系、某个资产包含哪些属性、这些属性之间如何共同描述同一个运行对象，这些信息都不再停留在工程师脑中，而是被系统显式表达出来。
这意味着，数据模型第一次真正开始贴近工业现场的现实世界。工程师在分析问题时，本来就不是从一串 tag 开始思考的，他们看到的是一台泵、一条产线、一段工艺流程，以及这些对象在某个时间段内的行为。以资产为核心的建模方式，把这种工程师天然的认知方式直接转化为数据结构，使得系统不再只是保存数据，而是能够表达系统本身。
更进一步看，这种模型还改变了工业软件的可扩展方式。在传统 tag 模型下，每增加一套设备，往往意味着增加一批新的 tag、图表、规则和监控逻辑，系统规模越大，配置和维护成本越高。而在以资产为核心的模型中，设备不再是零散配置的集合，而是可以被抽象、复用和继承的对象。一个泵的模型、一台锅炉的模型、一类压缩机的模型，都可以先定义清楚其结构、属性和分析逻辑，然后在多个实例中重复应用。这样一来，系统扩展的不再只是数据量，而是模型能力本身。
这也是为什么以资产为核心的数据建模，远不只是“把 tag 挂到设备下面”这么简单。它真正完成的，是把工业数据从“信号集合”提升为“系统表达”。在这个基础上，数据才开始具备被理解、被复用、被分析、甚至被 AI 利用的可能性。没有这一步，工业数据再多，也仍然只是漂浮在系统中的孤立数值；而有了这一步，数据才第一次真正成为对工业系统运行状态的结构化描述。
任一设备都有与它关联的通用信息、属性、事件、分析等来为AI提供上下文
PI 做对了什么，而现代数据平台又缺失了什么
需要指出的是，这一思路并非全新的概念。以 PI System 为代表的工业实时数据库，在很早之前就通过 Asset Framework 引入了以资产为核心的建模方式。它使工程师能够从 Tag 的层面上升到设备与工艺的层面，将数据与实际系统结构关联起来。
这一步非常重要。它在很大程度上解决了工业数据缺乏上下文的问题，也正是很多用户在使用 PI 时真正感受到价值的地方。对许多工程师而言，真正有意义的分析，往往不是发生在 Data Archive，而是发生在 Asset Framework 之上。
但当我们把视角转向现代数据基础设施时，会看到另一种完全不同的情况。以数据湖、数据仓库以及流式处理平台为代表的系统，在计算能力、扩展性和分析灵活性方面都非常强大。它们可以处理海量数据，支持复杂的数据管道和分析任务。
然而，这类系统并不是为工业场景设计的。它们以通用数据模型为基础，将数据视为行、列或事件记录，并不具备对设备、工艺以及运行结构的内在理解。因此，数据一旦进入这些平台，原有的上下文往往会丢失，工程师不得不在系统之外重新构建资产结构和数据关系。
这就形成了一个明显的断层。一方面，传统工业实时数据库具备良好的上下文表达能力，但在开放性和扩展性上存在限制；另一方面，现代数据平台在计算和扩展能力上非常强大，却缺乏对工业系统的语义理解。
因此，无论单独依赖哪一类系统，都难以为 OT 工程师提供一个完整而高效的解决方案。
上下文才是核心价值
以资产为核心的数据建模，其真正价值并不在于层级结构本身，而在于它所提供的上下文能力。一旦数据被锚定到资产之上，系统不仅知道数据来自哪里，还能够理解不同信号在设备内部或工艺流程中的关系。
这种上下文能力，使得系统可以在更大范围内保持一致性。工程师不再需要为每一台设备单独构建分析逻辑，而是可以定义统一的模型，并在相似设备之间复用。例如，一个泵的模型可以包含其关键属性、计算逻辑以及监控规则，然后在整个工厂甚至多个工厂中统一应用。
这种一致性不仅提升了效率，更是系统可扩展性的基础。没有统一模型，每增加一个资产都会增加复杂度；有了统一模型，系统可以在规模扩大的同时保持清晰与可控。
任何一个属性都可以配置描述、计量单位、数据类型、限值等来为AI提供上下文
在 AI 时代，上下文变得更加关键
当 AI 被引入工业系统后，上下文的重要性被进一步放大。AI 并不仅仅依赖数据量，更依赖数据的结构和语义。如果信号是孤立存在的，AI 所看到的只是一些彼此独立的数值序列，很难判断哪些变化是正常的，哪些是异常的。
而当数据围绕资产组织时，系统能够为 AI 提供必要的上下文。不同信号之间的关系变得清晰，相似设备之间可以进行对比，运行模式可以被识别，异常也可以在正确的语境中被检测出来。
因此，以资产为核心的数据建模，并不是一种可选的设计方式，而是工业数据能够真正被 AI 利用的前提。
结构并不能完全描述行为
尽管如此，以资产为核心的建模仍然存在边界。它主要解决的是“系统是什么”的问题，即设备结构、属性以及它们之间的关系。但工业系统本质上是动态的，其价值更多体现在运行过程中的变化。
设备会启动和停止，工艺会发生切换，异常会出现并消失。这些都是时间维度上的变化，而这些变化并不能被一个静态的资产模型完全表达。
这也意味着，仅有结构并不足以理解工业系统。我们不仅需要知道系统的构成，还需要理解系统在不同时间段内的行为。
下一步：从结构走向行为
要真正理解工业运行，数据模型需要从“结构”走向“行为”。这意味着需要引入另一层抽象，用于描述系统在时间维度上的变化，例如运行阶段、状态切换以及异常过程。
这正是事件建模所要解决的问题。事件定义了什么事情发生了、在什么时间发生、以及它与资产之间的关系。它在原始数据与运行理解之间，建立起关键的桥梁。
工业数据并不仅仅是时间序列的集合，而是对一个系统在时间中运行过程的描述。以资产为核心的建模为理解系统提供了基础，而以事件为核心的建模，则进一步解释系统是如何运行的。
这也正是我们下一步要讨论的方向。
