在上一篇解密工业本体中我们阐述了本体的概念。那么，本体到底能干什么？
其实本体就是让工业数据从“字段名和数值”转变为“可理解、可计算、可决策”的结构——设备身份、事件含义、规则依据，都能被系统和软件直接识别与执行。
传统本体的构建方法，在天理层（物理公式、化学方程）和法理层（行业标准、法规）能起到很好的作用。但到了人理常变的工业现场，设备在增减、工艺在调整、产线在重组、订单在波动，传统方法往往成本过高、维护困难，难以持续跑通。
这正是我们研发DIKube™要解决的问题，从传统先建完整本体的方式，转向实例优先、自底向上的方式，这是工程方法上的根本转变。
一、DIKube™的定义
DIKube™（Data-Information-Knowledge Cube）是一个张量体，用来描述任何工业实体（从设备到产线、从车间到工厂……）的数据、信息、知识所对应的元数据。
这里的“张量”不是严格数学意义上的张量，而是在“借用其多维组织思想”后，表达工业元数据在多维语义坐标中的组织方式，可理解为“多维数据立方体”。例如：如同一个拥有“设备ID、时间、温度、振动、工序”等多个坐标轴的多维数据立方体，我们可以沿着任意坐标轴对数据进行“切片”（查看某时间点的温度）或“聚合”（计算某设备一周的平均振动）。
传统数据模型以二维表（行、列）组织，DIKube™围绕工业对象，在多个语义维度上形成可切片、可聚合、可投影的结构。例如，设备“运行状态”由ID、时间戳、温度、振动、当前工序等维度共同定义。
DIKube™只存储元数据、唯一标识符和数据指针，不存原始数据。原始数据保留在数据湖或源端。
DIKube™分为实例态DOI（DIKube™ Ontology Instance）和定义态DOS（DIKube™ Ontology Schema）。DOI可以以临时类型、弱语义的形式先存在——现场数据流入而尚无合适语义定义时，DOI 以临时类型积累；当同类实例达到一定数量，系统从中归纳出 DOS，从而实现“实例优先、自底向上”。
一个车间例子：新来一台焊接机，型号未录入。工程师录入“焊接机_07”并记录温度、电流、报警——此时只有 DOI，没有 DOS。而当焊接机录入后，系统发现它与“焊接机_03”“焊接机_05”属性结构高度相似（温度范围、电流阈值、报警代码），自动建议新建 DOS“焊接机通用模型”。工程师确认后，三台设备共享同一 DOS。这就是从 DOI 到 DOS 的完整演化。
这意味着在运营层的动态管理中，系统可以先跑起来，再逐步定义、补全规则。 这是工业本体能否存活的关键。
二、DIKube™的初衷
工业数据治理长期存在三个困难：多源异构难融合、产业链上下游难共享、开放数据难获取。
数据湖、数据空间、数据编织等架构各有价值，但在MES/MOM层有共性问题：假设知识域稳定，要求先建完整模型再谈应用，但工业现场显著特点是动态变化，往往本体还没建完，现场已经变了。
DIKube™不要求一次性全局建模，允许从最小工作域（一台设备、一道工序、一个业务问题）开始，边运行边演化。DIKube™真正降低的是每次设备变更、工艺调整、产线重组时，那种“改一点、重写一片”的系统性成本。
三、DIKube™的结构
1. DOS / DOI分离
-
DOS（定义态）：定义实体类型、关系、属性约束、生命周期规则及后文的 SECP 投影规则，形成可演化、非冻结的语义蓝图。
-
DOI（实例态）：在 DOS 约束下承载具体工业对象的数据指针和元数据。若 DOS 未定义，DOI 可先以临时类型存在。
这种分离使“定义”与“实例”解耦。现场变化时只需演化DOS或增加DOI，无需修改已开发的软件逻辑。
2. D/I/K三层语义架构
按DIKW认知阶梯将语义内容分为三层：
-
D层（Data）：实体及关系，回答“有什么”——名词层。
-
I层（Information）：事件、流程、派生指标，回答“发生了什么、状态如何、结果怎样”——将孤立的名词串联成事实描述。
-
K层（Knowledge）：约束规则、机理、标准，回答“依据什么”——语法规则层。
三层边界清晰，修改互不干扰。
你可以想象：D层是车间里有哪些设备，I 层是它们经历了什么、当前状态如何、产出了哪些结果（例如：设备A过去一小时报警3次，当前正在运行第2道工序，良品率为98%），K层是允许怎么干。
3. SECP投影与Data Shape
DIKube™是高维语义空间，工业软件和AI需要更明确的维度契约。SECP投影将DIKube™元数据字段按语义归属分配到四个工程维度：
-
S（结构） → D层
-
E（事件） 和 P（流程） → I 层
-
C（配置） → K层
一般情况下，S主要来自D层，E与P主要来自I层，C主要受K层约束；C的具体参数值可能存在于实例态，K层定义其约束、规则与合法边界，G/R/A不在DIKube™的D/I/K三层中直接投影，它们通过场景定义（⟨S,E,C,P,G,R,A⟩）中的业务语义层与DIKube™关联。
换句话说：
-
哪些东西存在 → D 层
-
发生了什么 → I 层
-
什么被允许 → K 层
这就像给每个数据贴个标签：它是结构件，还是事件流，还是配置参数？标签不同，用法就不同。
投影后形成包含实体拓扑、事件模式、参数约束、状态机的四维结构契约，被称作Data Shape。Data Shape就像工业数据的“USB接口协议”——只要符合协议，不管什么设备的数据，软件和AI都能即插即用。
Data Shape是DIKube™对外提供的最小可计算结构：任何遵循该Shape的数据，其数据中可能包含的事件与规则模式都是预先可知的，也可以支持相同的计算模式。因此，一个通用异常检测算法可直接消费“设备温度异常”的Data Shape，无需为新设备重写代码。
4. 闭环回流与演化
上层应用（数字孪生、人工智能、所有工业App等）运行产生的新知识（如预测结果、优化建议）作为新元数据写回DIKube™中的恰当层级。当多台设备的DOI都出现相同临时类型标签（如“碳排放实时强度”），系统自动建议将该属性加入对应 DOS。管理员确认后完成演化。自动建议需经工程师确认后生效，避免误归纳。
DIKube™由此实现数据驱动的持续演化，而非一次性冻结。DIKube™的演化是在版本、权限、兼容性和人工确认约束下的受控演化。
四、DIKube™对工业软件和工业 AI 的价值
对工业软件：传统工业软件的问题不是代码写得差，而是把逻辑直接焊死在数据库表结构上，导致软件无法跟上业务的演进速度。DIKube™通过DOS/DOI分离，把逻辑架在稳定的“语义契约”上。 现场变化时多数结构性变化可通过演化DOS和适配映射解决，显著减少软件逻辑重写。
对工业AI：目前工业AI模型高度依赖特定数据集的格式。换一条产线，模型往往需要重新训练。DIKube™通过Data Shape为AI提供统一输入契约。在Data Shape一致或可映射的前提下，同一类异常检测模型可在不同设备、产线间复用。工业AI不该吞食原始数据集，而应消费带有明确Data Shape的语义语料。
基于Data Shape可进一步定义ABC（原子业务能力，即最小可复用的业务逻辑单元）——输入、输出、行为约束均由Data Shape严格定义，多个ABC编排形成完整工业应用，形成从DIKube™到SECP到Data Shape到ABC最后到到App的业务价值完整路径。
五、时间的考验
2023年6月，我们提交了两项专利申请；
同年9月，发表了IEEE论文，后被EI收录。
2026年5月，两项专利正式授权，同月，白皮书完成。
*注：所有成果正式名称见文末 点击下方链接阅读全文：
陈刚直言｜DIKube™：用三年锻造而成的实用工业本体
①IEEE论文：Towards Industry Data Governance: Construction of An Industrial Data Decentralized Distributed Symbiotic Sharing Space Based on Tensor.
②专利1：CN 116775763 B，一种去中心化分布式共生共享的数据编织
③专利2：CN 116775605 B，一种基于人工智能的产业数据管理和共享平台
