4. ThingWorx数据建模方法论
在ThingWorx中做工业数据建模，最容易走偏的做法是“看到设备就建Thing，看到测点就加属性”。这样在单台设备演示时没问题，一旦扩展到产线、车间、多工厂，模型数量会迅速膨胀，命名混乱、关系断裂、复用困难。本节要解决的核心问题是：如何从物理资产出发，设计出可复用、可扩展、可维护的数字孪生模型体系。
一、从物理资产到数字孪生的映射思路
物理资产有明确的层级：工厂→车间→产线→设备→部件→传感器。数字孪生不是简单地把每个物理对象都建一个Thing，而是先识别“哪些对象需要独立建模”。判断依据有三条：是否具有独立身份标识（如设备编号）、是否承载独立业务语义（如需要单独统计OEE）、是否会被其他模型引用（如被多个产线共用）。满足其中一条，就值得建为独立Thing；否则可以作为属性或子组件存在。
以一台数控机床为例。机床本身建为Thing，类型为CNC_Machine；主轴、进给轴、冷却系统作为其子组件，可以用ThingTemplate中的属性组表达，也可以建为独立Thing并通过关系连接。如果主轴需要单独做健康评估，就独立建Thing；如果只是采集温度、振动，则作为机床Thing的属性即可。这个判断过程决定了模型的粒度和后续复用能力。
二、实体关系设计的三种核心模式
ThingWorx中的实体关系不是数据库外键，而是通过ThingTemplate、ThingShape和Thing之间的引用与继承来表达。实际建模中，最常用的关系模式有三种：
第一种是“类型-实例”关系。用ThingTemplate定义一类设备的通用属性、服务和事件，具体设备Thing继承该模板。例如CNC_Machine_Template定义了主轴转速、进给速率、报警代码等属性，所有数控机床Thing都基于它创建。当模板新增一个“刀具寿命”属性时，所有实例自动获得该属性，无需逐个修改。
第二种是“整体-部件”关系。用ThingShape表达可复用的能力单元，再通过Thing的组合或关系连接表达整体与部件。例如Spindle_Shape包含温度、振动、转速三个属性，可以挂到机床Thing上，也可以挂到磨床Thing上。如果主轴需要独立做预测性维护，则单独建Spindle_Thing，再通过PartOf关系指向机床Thing。
第三种是“引用-被引用”关系。当多个设备共用同一套参数或同一份物料清单时，用关系指向共享Thing。例如多条产线共用同一台空压机，空压机Thing被多条产线Thing通过Uses关系引用，避免重复建模和数据不一致。
三、命名规范：让模型可读、可查、可维护
命名规范不是形式主义，而是模型复用和团队协作的基础。推荐采用“类型前缀_区域_编号_功能”的四段式结构，用下划线连接，全部大写或首字母大写保持一致。例如：
CNC_SHOP1_M001_SpindleTemp
CNC_SHOP1_M001_SpindleVib
ROBOT_SHOP1_R012_JointAngle
LINE_SHOP1_L003_OutputCount属性命名要避免使用中文、空格和特殊字符，因为ThingWorx的REST API和Mashup绑定对特殊字符支持有限。服务命名用动词开头，如CalculateOEE、ResetCounter；事件命名用“对象_动作”结构，如Machine_AlarmTriggered。ThingTemplate命名加_Template后缀，ThingShape命名加_Shape后缀，关系类型命名用帕斯卡命名法如PartOf、Uses。
CNC_M001_Temp和CNC_M001_Temperature两个含义相同的属性。
四、模型复用策略：从模板到实例的完整链路
模型复用的核心是“一次定义，多处使用”。具体落地分四层：
第一层：ThingShape定义能力单元。把“温度采集”“振动采集”“报警管理”“OEE计算”分别做成独立的ThingShape。每个Shape只包含该能力相关的属性、服务和事件，保持单一职责。
第二层：ThingTemplate组合Shape。根据设备类型，把需要的Shape组合成模板。例如CNC_Machine_Template组合了Temperature_Shape、Vibration_Shape、Alarm_Shape、OEE_Shape。模板本身不绑定具体数据源，只定义结构和默认行为。
第三层：Thing实例化并绑定。基于模板创建具体设备Thing，绑定实际的ThingWorx Edge、OPC UA或MQTT数据源。实例可以覆盖模板中的默认值，也可以增加模板中没有的个性化属性，但新增属性应评估是否值得回写到模板。
第四层：关系连接形成网络。用PartOf表达设备与产线、产线与车间的关系；用Uses表达设备与共享资源的关系；用Implements表达设备与标准接口的关系。关系连接让模型从“孤立Thing”变成“可导航的数字孪生网络”。
五、一个可参考的建模检查清单
在实际项目中，完成一轮建模后，建议用以下清单做一次自检。清单中的字段和判断依据来自ThingWorx建模的常见实践，可根据项目规模调整：
| 检查项 | 判断标准 | 常见问题 |
|---|---|---|
| Thing粒度 | 每个Thing有独立身份和业务语义 | 把传感器全部建成独立Thing，导致数量爆炸 |
| 模板复用率 | 同类设备复用同一ThingTemplate | 每台设备单独建模板，属性重复定义 |
| 命名一致性 | 符合四段式规范，无中文和空格 | 同一属性出现多种拼写 |
| 关系完整性 | 设备能通过关系导航到产线和车间 | 只有Thing没有关系，形成信息孤岛 |
| 数据源绑定 | 每个采集属性有明确的Edge/OPC UA/MQTT来源 | 属性建了但未绑定，数据为空 |
| 变更影响评估 | 修改模板前评估对实例的影响范围 | 直接改模板导致大量实例行为异常 |
建模不是一次性的工作，而是随着产线改造、设备新增、指标调整持续演进的过程。好的模型体系应该让新增一台设备只需要“选模板、填参数、绑数据源、连关系”四步，而不是重新设计一遍结构。从物理资产到数字孪生的映射思路、实体关系的三种模式、命名规范和四层复用策略，共同构成了ThingWorx数据建模的方法论骨架。掌握这套骨架后，后续的指标体系开发、Mashup可视化和数据分析才有稳定的数据基础。