2. ThingWorx核心概念与架构

ThingWorx 的交付能力，本质上建立在一组彼此咬合的核心概念之上。如果把这些概念混为一谈，项目很容易在“模型该建在哪一层”“逻辑该写在哪里”“界面数据从哪里来”这些问题上反复返工。理解它们的分工与依赖关系，是后续建模、开发、部署和排障的基础。

可以把 ThingWorx 的模型体系理解为一条从“抽象定义”到“具体实例”的链路：ThingTemplate 定义一类设备的通用能力，ThingShape 提供可复用的能力片段，Thing 是真正代表一台设备、一条产线或一个业务对象的实例，服务承载可被调用的逻辑，订阅负责对事件做出响应，数据表保存结构化数据，Mashup 则把数据与操作呈现给用户。它们不是并列的七个名词，而是有明确依赖方向的整体。

ThingTemplate 与 ThingShape：定义“一类”与“一片”

ThingShape 是最小的能力复用单元，它把一组属性、服务和事件打包在一起。例如可以定义一个“运行状态上报”ThingShape，包含 RunningState 属性、ReportState 服务和 StateChanged 事件。它的价值在于跨设备类型复用：注塑机、空压机、传送带都需要状态上报，就都挂载同一个 ThingShape，而不是各写一遍。

ThingTemplate 描述“一类对象应该长什么样”，它通过组合一个或多个 ThingShape 来形成完整能力集合。例如“注塑机模板”可以组合“运行状态上报”“工艺参数采集”“报警管理”三个 ThingShape。模板本身不保存具体设备的实时值，它只规定结构与默认行为。交付中常见的错误是把某台设备的特殊逻辑直接写进模板，导致同类设备被迫继承不需要的行为。

Thing：真正承载数据的实例

Thing 是模板的实例化结果，代表一台具体设备、一条产线或一个业务对象。它继承模板的全部属性、服务和事件，并保存自己的实时值。例如基于“注塑机模板”创建 IMM-01、IMM-02 两个 Thing，它们结构相同，但 RunningState、MeltTemperature 等属性值各自独立。

交付时建议遵循“模板定结构、Thing 存数据”的原则。设备编号、所属产线、通信地址这类实例级信息放在 Thing 上；采集周期、报警阈值这类同类设备共用的参数放在模板上。这样新增设备只需实例化并填写少量实例参数，而不是复制整套逻辑。

服务与订阅：逻辑的两种触发方式

服务（Service） 是可被调用的逻辑单元，有明确的输入参数和输出结果。它既可以由 Mashup 按钮触发，也可以被其他服务调用，还可以被订阅触发。例如 CalculateOEE 服务接收 startTime、endTime，返回 oeeValue。服务应保持职责单一，避免一个服务同时做数据采集、计算和写库。

订阅（Subscription） 是事件驱动的响应机制。当某个属性变化、某个事件触发或某个定时条件满足时，订阅会自动执行指定的服务。例如订阅 IMM-01 的 RunningState 属性变化，一旦由 Running 变为 Stopped，就触发 RecordDowntime 服务写入停机记录。订阅把“什么时候做”和“做什么”解耦，是设备联动和自动记录的关键。

数据表与 Mashup：存储与呈现

数据表（DataTable） 用于保存结构化数据，适合存放报警历史、停机记录、班次产量等需要按行查询和统计的数据。它由字段定义和记录组成，可以通过服务进行增删改查。交付中要区分“实时值”和“历史数据”：实时值放在 Thing 属性上，历史记录写入数据表，避免用属性保存大量历史行。

Mashup 是面向用户的界面容器，它把 Thing 属性、服务返回值和数据表查询结果绑定到可视化组件上。例如一个设备监控 Mashup，可以绑定 IMM-01 的 RunningState 显示状态灯，绑定 CalculateOEE 服务显示 OEE 数值，绑定停机记录数据表显示历史列表。Mashup 不直接访问数据库，而是通过绑定 Thing 和服务获取数据，这保证了权限和逻辑的统一。

在交付中的角色分工

理解这七个概念的关键，不是记住定义，而是记住它们之间的依赖方向：ThingShape 被 ThingTemplate 组合，ThingTemplate 被实例化为 Thing，Thing 上定义服务与订阅，服务读写数据表，Mashup 绑定 Thing、服务和数据表。交付中只要沿着这条链路检查每一层的职责是否清晰，就能在早期发现模型设计问题，而不是等到联调阶段才暴露。