陈刚直言｜解密工业本体

前面的文章中，我没用过“解密”这个词，今天第一次用，因为有两个密，确实值得解：

第一，为什么“本体”的价值，几十年前业界就已经认识到了，但在工业领域真正落地的很少，创造出可量化工程价值的更少？

第二，为什么Palantir 已经证明了Ontology的巨大价值，但绝大多数企业很难复制？

一、本体不新，问题在“落不下去”

工业本体不是新东西。

从20世纪80年代Protégé原型工具开始，到ISO 15926、ISA-95、OPC UA，再到 IOF，本体在“如何表达工业世界”这件事上，已经讲得足够清楚。所以问题从来不是：有没有方法、有没有工具。

为什么这些方法，没有变成制造企业日常可用的能力？答案很简单：传统本体工程太重了。

它默认一个前提：一开始就要把对象、分类、关系、规则全部定义清楚。这个前提在学术上成立，在工业现场不成立，车间不是相对静态的知识库，设备在变、工艺在调、产线在重组、人员在轮换、订单在波动，MES/MOM面对的不是“稳定系统”，而是：人理常变的运行现场。

在这样的环境里，要求先建一个“完整本体”，再谈应用，本身就是错位。

二、Palantir：方向对，但路径很难复制

Palantir证明了一件事：Ontology是企业数字化的核心语义基础。

本体让数据不再只是数据，而是可理解、可计算、可决策的结构。但必须看清另一面。Palantir为什么难复制？不是因为它太先进，而是因为它太“重”。

在本体构建中，绝大多数工作在数据获取、清洗、连接和规范化，真正用于分析与洞察的比例极低，Palantir的项目模式具有以下特点：

• 依赖长期驻场的高水平工程师（FDE） 

• 依赖数月甚至数年的项目周期

• 依赖把企业隐性知识一条一条人工编码进系统

这种模式对绝大多数企业而言成本过高且不可复制。

Palantir验证了本体的价值，但同时也证明只要本体还依赖“专家工程 + 一次性全建模”，它就不可能成为制造业的基础设施。

三、不是观点，而是已经被验证的路径

需要强调的是，这并不是一个“事后总结”的观点。

早在2023 年，我们团队已经在IEEE International Conference on Automation and Computing上发表论文，系统提出了工业数据空间iDS3架构，并在其中明确给出了DIKube（data–information–knowledge cube）这一语义结构模型。

DIKube不是一个被创造出的新概念，是在多个制造场景中经过工程验证和总结，得出的一被实践检验过的路径。

四、真正的问题：本体方法从一开始就“错位”

工业本体为什么用不起来？核心在于三个断层：

断层一：方法论与工业现场脱节

现有方法默认知识域稳定，但制造现场却充满变数，设备在增减、工艺在调整、产线在优化。 

更关键的是大量本体系统设计中，不处理高频时序数据、不覆盖生命周期演化、不回答如何与ERP / MES / SCADA对接，导致方法论与工业现场实际情况存在致命缺口。

断层二：工具链与人的认知路径相悖

几乎所有本体工具遵循先定义类，再填实例的顺序，但工业现场的认知顺序是反的，大量情况下是先有了某台设备、某批物料、某个岗位后，再去定义其分类、关系和规则。

当要求工业企业先构建抽象体系，再填现实数据时，项目就已经失败了一半。

断层三：本体与应用之间断开

很多本体项目的结局是一个漂亮图谱或一套无人使用的模型。

但这些图谱或模型没有被应用消费，不能驱动App、不能约束系统、不能支撑决策的本体，只是文件。

五、核心矛盾（必须说透）

四十年下来，问题已经非常清晰：工业本体的障碍，从来不是“有没有用”，而是“做不动、做不起、活不长”。特别是在MES/MOM 层。

因为这里遵循的是三种机理：

• 天理（不变）：物理公式、化学方程、热力学定律，不可违背。CAD/CAE、PLC/DCS 工作在此层，语义结构稳定，传统本体方法尚可应对。

• 法理（缓变）：国家法规、行业标准、财务准则，人为制定但相对稳定。ERP/SCM 工作在此层，变化周期以年为单位，传统本体可通过定期升级维持。

• 人理（常变）：车间现场的工艺路线、设备布局、人员排班、物料流动、订单组合。这些规则由特定工厂的管理者、工艺师、班组长在特定工作域内确定，会随产品切换、产线重组、工艺变更、需求波动而频繁调整——可能几天、几周就会变化。

传统本体工程假设知识域稳定，要求“一次性将实体、活动、规则全部收集齐备”。这种模式在天理层、法理层尚可运行，但在人理常变的MES/MOM 层，等你把本体建完，车间现场已经变了。

不是方法不对，而是方法的底层假设与现场现实根本错位。

六、DIKube：关键不是三层，而是“反过来”

DIKube的关键不是把本体建得更完整，而是把起点从“抽象分类”转向“现场事实”，再沉淀为可被应用消费的DOS（DIKube Ontology Schema）定义。

DIKube的关键，不在于D/I/K三层，而在于一个根本性的翻转：

• 传统本体：从“类”出发构建世界，从“应该是什么”开始

• DIKube：从“实例”出发还原世界，从“现在是什么”开始

七、三层结构（只是承载，不是本质）

DIKube用三层来组织语义：

• D（Data层）：有什么

• I（Information层）：发生了什么

• K（Knowledge层）：允许什么

三层逐步递进、互链的同时，确保边界清晰，这里的边界划分，并非随意约定，而是来源于 DIKube 架构中的SECP统一语义协议。SECP将任意工业场景分解为四个基本维度：S（结构）、E（事件）、C（配置）、P（流程）。

这四个维度向DOS三层投影时，遵循明确的映射规则：

• S（结构）→ DOS-D 层（实体类型与关系）

• E（事件）和 P（流程）→ DOS-I 层（事件、活动、时序、指标）

• C（配置）→ DOS-K 层（参数边界、约束规则

这一投影规则直接决定了三层之间的边界原则：

三层逐步递进、互链的同时，确保边界清晰，最终形成工程实现上的工业本体表达：DOS（DIKube Ontology Schema）。

整个过程中，本体并不是在全局一次性构建完成，而是以“工作域（Working Domain）”为单位逐步建立——可以围绕某一类设备、某一道工序或某一类业务问题，独立定义并持续演化，最终形成本体定义语义（Schema），知识图谱承载实例（Instance）的完整结构。

八、为什么它只在MES/MOM成立

DIKube不是通用本体方案，仅关注制造运营层为什么用不好本体的核心问题。因为这里只有一个特征：人理常变。

在CAD/CAE（天理）或 ERP（法理）领域，传统方法是成立的。

需要说明的是，这条路径并不处在“概念阶段”，但也还远未进入“规模化阶段”

DIKube已经完成方法论定义与多行业工程验证，但距离成为产业级基础设施，还需要一个过程。 点击下方链接阅读全文： 陈刚直言｜解密工业本体