以资产为核心的数据建模：工业数据上下文的基础 | TDengine IDMP

数据在增长，但洞察并没有同步增长

当下，工业系统正以从未有过的速度生成数据，传感器不间断地从系统各环节收集高频信号，像温度、压力，乃至于振动、流量以及设备状态，差不多所有运行信息都被数字化且记录下来，因基础设施的发展，数据存储与吞吐早就不是瓶颈，大规模数据处理及分析能力也愈发容易获取。

可在这所有进步的背后，有一个更为本质的问题依旧存在着。数据的规模正处于快速增长的状态，然而我们对于数据的理解能力还有所获得的洞察，并未在同一时间得到提升。

很难承载真正意义的是一个孤立的数据点本身。85°C 的这个温度值，在某些具体得工况之下，有可能是完全正常的，然而在另外一些场景当中，却或许意味着严重的异常。要是不知道这个数据究竟属于哪一台设备，处于什么样的工艺流程，是在何种运行状态下产生的，那么这个数值自身就是模糊的，甚至是具有误导性的。这并非是由于数据数量不够多，同样也不是因为计算能力有所欠缺，而是因为数据缺少结构以及上下文。

以 测点为中心的模型及其局限

就在以往的几十年时间当中，绝大多数的工业系统，都是依据 Tag（测点）模型去组织数据的。每一个数据点，是由 Tag 名、时间戳以及值共同构成的。而系统从本质上来说，存储的是一组时间序列信号。这样的一种方式，在数据采集这个层面，是极为有效的，它结构简单，灵活性又高，并且还方便进行大规模的部署。

可这个模型打从一开始就并非是为了“理解系统”去做设计的。有工程师在剖析问题之际，并非会以Tag作为单位来思索，而是会以设备以及系统当作单位。像一个泵，或者一个锅炉，又或者一条生产线，并非是靠单一信号予以定义的，而是依靠一组彼此相关联的变量以及运行行为一块儿构建而成的。

当数据是以 Tag 的形式存在之时，工程师在分析进程之中不得不手动去重建这些关系，他们得要判断哪些信号归属于同一设备，要去理解不同信号相互之间的关联，并且是依靠前面这些去推断系统当下的运行状态。随着系统规模不断地扩展，这种借助“在脑子里面重建模型”的方式变得越发艰难，数据跟理解相互之间的鸿沟也跟着扩大了。

从信号到系统：以资产为核心的建模方式

以资产作为核心的数据建模，从本质上来说，改变了工业数据组织的起始点。它并非将单个信号当作最基础的对象，而是从设备、系统以及工艺单元着手，来组织并理解数据。也就是说，数据不再仅仅是“被采集到的一组值”，而是变成某个真实工业对象的一部分。温度不再单纯是一个tag，而是某台锅炉、某个反应釜、某台压缩机的温度；压力不再只是一个数值，而是某个工艺流程在特定位置、特定阶段时的运行状况。

这种变化看上去好似是数据组织方式的一种调整，然而实际上被它改变的却是整个系统针对数据的理解方式，在tag模型里，信号是彼此独立得以存在的，关系通常是隐含着的，得依靠工程师的经验或者外部的文档去进行补充，而在以资产为核心的模型当中，关系本身变成了模型的一部分，设备与设备之间的从属关系，某个资产所包含的哪些属性，这些属性之间是以怎样的方式去共同描述同一个运行对象，这些信息都并非停留在工程师的脑中，而是被系统明确地表达了出来。

这表明，数据模型首次切实开始靠近工业现场的实际世界。工程师在剖析问题之际，原本并非从一串tag着手思索，他们所见到的是一台泵，是一条产线，是一段工艺流程，以及这些对象于某个时间段里的行为。以资产作为核心的建模方式，将这种工程师固有的认知方式径直转化成数据结构，致使系统不再仅只是存有数据，而是能够呈现系统自身。

进一步深入去看，这种模型对工业软件的可扩展方式产生了改变，在传统tag模型的情形下，每当增添一套设备时，通常就意味着会增添一批全新的tag、图表、规则以及监控逻辑，系统规模越大，配置以及维护成本也就越高，而在以资产为核心的模型里，设备并非是零散配置所形成的集合，而是能够被抽象、复用以及继承的对象，一个泵的模型，一台锅炉的模型，一类压缩机的模型，都能够先将其结构、属性以及分析逻辑定义清晰，接着在多个实例当中进行重复应用。这样一来，系统扩展的不再只是数据量，而是模型能力本身。

这同样是为何以资产作为核心的数据建模，绝非仅仅是“将tag挂于设备之下”这般轻易。其切实达成的，乃是把工业数据从“信号集合”转变为“系统表达”。基于此基础之上，数据才起始拥有被理解、被复用、被分析、乃至被AI运用的可能性。缺少这一步骤，工业数据即便再多，也依旧不过是在系统中漂浮着的孤立数值；而有了这一步，数据才首次真正成为对工业系统运行状态的结构化描述。

PI 做对了什么，而现代数据平台又缺失了什么

需加以指出的是，这一思路并不是全新的概念，以有着代表性的PI System作为工业实时数据库，在很早以前就借助Asset Framework引入了以资产作为核心的建模方式，它让工程师能够从Tag的层面往上升到设备与工艺的层面，把数据和实际系统结构关联起来。

这一步极为关键，它在相当大的程度上化解了工业数据欠缺上下文的难题，并且这恰恰是许许多多用户于运用PI之际切实感悟到价值的所在之处。对于众多工程师来讲，真正具备意义的分析，常常并非在Data Archive发生，而是在Asset Framework之上展开。

然而，当我们将目光投向现代数据领域里的数据基础设施之时，便会察觉到另外一种截然不同的状况。像以数据湖、数据仓库还有流式处理平台作为代表的那些系统，在计算能力方面、扩展性方面以及分析灵活性方面，均展现出极为强大的特性。它们能够对海量数据进行处理操作，还能够为复杂的数据管道以及分析任务提供有力支持。

然而，这类系统并非是为工业场景去设计的，它们是以通用数据模型作为基础的，把数据看成是行、列或者事件记录的，并不拥有对设备、工艺以及运行结构内在理解的，所以，数据一旦进入这些平台，原有的上下文常常会丢失的，工程师不得不于系统之外重新构建资产结构和数据关系的。

这便造就了一个显著的断层，一方面，传统工业实时数据库有着不错的上下文表达本领，然而在开放性以及扩展性方面存有局限，另一方面，现代数据平台于计算和扩展方面的能力极为强盛，却欠缺对工业系统的语义领会，所以，不管单独依靠哪一种系统，都难以给OT工程师供给一个完备且高效的解决办法。

恰恰是基于此，工业场景切实所需的，并非是一味专长于存储与计算的通用数据平台，而是一个能够一并承接时序数据底座、承载资产上下文表达、展开事件分析以及容纳AI应用的数据管理平台。TDengine IDMP 的设计思路，是顺着这个方向去展开的，它是在建于时序数据库能力的基础上，进一步去提供数据目录，数据标准化，数据情景化，事件，分析，通知以及 AI 原生能力，从而让工业数据不是仅仅被存起来，而是能够被组织成可理解，可分析且可行动的数据资产。也就是说，它想要补上的，正是现代数据平台在工业场景里最容易缺失的那一层，即对设备，业务语义以及运行上下文的系统化表达。

上下文才是核心价值

围绕资产展开的数据建模，其实际关键价值并非是层级结构自身，而是在于它所给予的上下文关联能力。一旦数据被固定到资产之上，系统不但清楚数据源自何处，而且还能够明白不同信号于设备内部或者工艺流程里的关系。

具备这样的上下文能力，致使系统能够于更大范畴内维持一致性，工程师无需再为每一台设备逐个构建分析逻辑，而是能够定义统一起来的模型，并在相似的设备之间进行复用，比如，一个泵的模型能够涵盖其关键属性、计算逻辑以及监控规则，随后在整个工厂乃至多个工厂内统一予以应用。

这种一致性，不但提升了效率，而且还是系统可扩展性的基础。要是没有统一模型，那么每增加一个资产，都会致使复杂度增加；而一旦有了统一模型，系统在规模扩大之际能够与此同时保持清晰以及可控。

在 AI 时代，上下文变得更加关键

当人工智能被引入到工业系统里之后，上下文具备的重要性被进一步地放大了。人工智能并非仅仅依靠数据量，而是更加依赖数据的结构以及语义。要是信号处于孤立存在的状态，那么人工智能所看到的仅仅是一些相互独立的数值序列，很难去判断哪一些变化属于正常的，哪一些是异常的。

每当数据围绕资产予以组织之际，系统便能够给AI供给所需的上下文。不同信号相互之间的关系会变得明晰，相似的设备彼此之间能够展开对比，运行模式能够被识别出来，异常情况同样能够在恰当的语境当中被检测发觉。

所以，围绕资产展开的数据建模，并非是那种可被选用的设计途径，而是工业数据得以切实被AI运用的必要条件的前提。

结构并不能完全描述行为

依旧如此，围绕资产构建的模型存在边界，它着重解决的是“系统是怎样的”问题，也就是设备的结构、属性连同其彼此间的关系，然而工业系统本质处于动态，其价值大多反映于运行当中的变动。

设备会开启与终止，工艺会进行转换，异常会呈现且隐没。这些均为时间层面的变动，然而这些变动无法被一个静态的资产模型全然表述。

这同样表明，单单只有结构，是没办法去理解工业系统的。我们不但得清楚系统的组成，还得明白系统于不同时间段当中的行动。

下一步：从结构走向行为

数据模型得从“结构”迈进“行为”，才能真切领会工业运行，这表明要引入另一重抽象，用来刻画系统于时间方面的变动，像运行时期、状态转换以及异常进程。

这恰恰是事件建模需要去攻克的那种问题，事件界定了出现的是什么事，在何时出现的，以及它跟资产之间存在的那种关系，它于原始数据跟运行理解之间，搭建起至关重要的桥梁。

工业数据并非单纯是时间序列的聚合，而是针对一个系统于时间里运行进程的阐述。以资产作为核心的建模给理解系统奠定了基础，而基于事件作为核心的建模，更进一步诠释系统是怎样运行的。

这也正是我们下一步要讨论的方向。

相关标签： # 以资产为核心的数据建模 # 工业数据上下文 # 数据理解能力 # AI应用 # 事件建模