1. 课程导入与工业资产建模全景

在工业物联网（IIoT）项目中，真正决定系统能否长期演进的，往往不是采集了多少个点位，而是这些点位背后有没有一套清晰的资产模型。ThingWorx 作为 PTC 面向工业场景的物联网平台，其核心价值之一就在于用统一的建模机制把设备、产线、工厂乃至产品抽象成可复用的数字对象。本课程围绕资产模型与 ThingModel 设计展开，而这一节先建立全景认知：ThingWorx 在工业物联网中处于什么位置，Thing、ThingTemplate、ThingShape、ThingModel 这几个高频概念各自承担什么职责，以及为什么本课程把资产模型与 ThingModel 设计作为主线。

ThingWorx 在工业物联网中的定位

典型的工业物联网系统可以分成四层：现场设备层（PLC、传感器、CNC、机器人）、边缘接入层（网关、Edge Agent、协议转换）、平台服务层（设备管理、数据存储、规则引擎、可视化、分析）以及应用集成层（MES、ERP、SCADA、移动端）。ThingWorx 主要落在平台服务层，同时通过 ThingWorx Edge 与 Kepware 等组件向下延伸到边缘接入层。它不直接替代 PLC 的控制逻辑，也不替代 MES 的工单管理，而是把来自不同协议、不同厂商的设备数据统一成“可被业务理解的对象”，再向上提供 REST API、Mashup 可视化、ThingWorx Flow 编排等能力。

理解这一点很关键：ThingWorx 的建模不是给设备“改名字”，而是给设备建立一套可被查询、可被订阅、可被复用的数字身份。例如一台注塑机，在 PLC 里可能只是 DB 块中的若干寄存器地址；在 ThingWorx 中，它应该成为一个名为 InjectionMoldingMachine_01 的 Thing，拥有温度、压力、锁模力、循环时间等属性，拥有启动、停机、切换配方等服务，还能被归入“注塑机”这一模板，从而让 20 台同型号设备共享同一套定义。

四个核心概念的分工

ThingWorx 的建模体系里，Thing、ThingTemplate、ThingShape、ThingModel 是最容易混淆的一组概念。可以用“实例—模板—能力片段—模型描述”来区分它们。

• Thing（事物）：模型的最小运行实例，代表一个具体对象，如某台设备、某条产线、某个传感器。它拥有属性（Property）、服务（Service）、事件（Event）和订阅（Subscription），是数据绑定和业务逻辑的实际载体。
• ThingTemplate（事物模板）：一类事物的抽象定义，规定这类对象“应该具备哪些属性、服务和事件”。例如 InjectionMoldingMachine 模板定义温度、压力、循环时间等属性。Thing 基于模板创建，继承模板的全部定义，并可在此基础上扩展。
• ThingShape（事物形态）：可复用的能力片段，用于横向组合。例如“可远程启停”“可上报能耗”“可进行 OEE 计算”都可以做成独立 ThingShape，再被多个模板或 Thing 混入（mixin）。它解决的是跨设备类别的共性能力复用问题。
• ThingModel（事物模型）：对资产建模结果的整体描述与设计产物，通常体现为模板、形态、Thing 及其关系、数据绑定、服务逻辑的组合。它回答的是“这套资产模型长什么样、如何组织、如何落地”。

四者关系可以概括为：ThingShape 提供能力片段，ThingTemplate 组合能力并定义一类资产，Thing 是模板的实例化落地，ThingModel 是对整套建模设计的统称。实际项目中，先设计 ThingModel，再落地为模板与形态，最后批量生成 Thing 实例。

为什么以资产模型与 ThingModel 设计为主线

很多初学者会先学 Mashup 拖拽、先学 REST 调用，结果项目一扩大就陷入混乱：同一个温度点位在三个页面里写了三遍，设备换型后所有绑定全部失效，新增一台设备要复制粘贴几十个配置。根因不是工具不熟，而是资产模型没有设计好。ThingWorx 的建模能力如果只被当作“建几个 Thing”，就浪费了它最核心的复用机制。

本课程把资产模型与 ThingModel 设计作为主线，是因为它决定了后续所有工作的质量：数据绑定是否稳定、服务逻辑是否可维护、可视化是否可复用、与 MES/ERP 的集成是否顺畅，都取决于模型设计。具体来说，一条合理的建模主线通常包含以下判断：

1. 资产识别：先梳理现场有哪些设备、产线、工位、产品，明确建模边界。例如“注塑车间”包含 12 台注塑机、2 台干燥机、1 条输送线。
2. 分类抽象：把同类资产归为一个模板，把跨类共性抽为形态。例如所有设备都“可启停、可报警”，就做成 EquipmentCommon 形态。
3. 属性与服务定义：为模板定义属性名、数据类型、单位、默认值、是否可写，以及服务入参出参。例如温度属性 barrelTemp，类型 NUMBER，单位 ℃，可读。
4. 实例化与命名规范：按统一规则生成 Thing 名称，如 IMM_01、IMM_02，便于批量管理和远程绑定。
5. 关系与层级：用 Thing 之间的关系表达“产线包含设备”“设备属于工厂”，为后续聚合计算和权限控制打基础。

本课程的学习路径

后续章节会沿着“概念—设计—落地—验证”的路径展开：先深入 Thing、ThingTemplate、ThingShape 的继承与混入规则，再讲属性、服务、事件、订阅的建模细节，然后进入 ThingModel 的组织方式、命名规范、版本管理与批量实例化，最后结合数据绑定、Mashup 展示和 REST 接口验证模型是否真正可用。每一节都会尽量给出可参考的配置样例、参数表和判断依据，而不是停留在概念复述。

需要提醒的是，ThingWorx 的建模没有唯一正确答案，但有明显的优劣之分。好的模型让后续开发越来越轻，坏的模型让后续维护越来越重。本节的全景图已经给出了四个核心概念的分工与落地路径，接下来就从最基础的 Thing 与 ThingTemplate 开始，把每一个概念真正落到可操作的配置上。