2. ThingWorx基础架构与核心概念

ThingWorx 的建模体系围绕“把物理设备抽象成可编程对象”展开。理解 Thing、ThingTemplate、ThingShape、属性、服务、事件与订阅这七个术语，以及它们之间的组合关系，是后续搭建生产设备监控平台的前提。本节先建立术语之间的结构关系，再说明每个术语在设备监控场景中承担什么职责。

一、平台组成与术语分层

ThingWorx 平台由若干层次组成：最底层是连接层，负责与 PLC、网关、OPC UA 服务器、MQTT Broker 等数据源通信；中间是建模层，用 Thing 及其模板、形状描述设备；上层是服务与事件层，负责业务逻辑和状态响应；最上层是可视化层，用 Mashup 呈现数据。本节聚焦建模层与服务事件层。

可以把术语分成三组来理解：

• 对象定义组：Thing、ThingTemplate、ThingShape，回答“设备是什么、具备哪些能力”。
• 数据与行为组：属性、服务，回答“设备有哪些数据、能执行什么动作”。
• 响应机制组：事件、订阅，回答“数据变化后系统如何自动反应”。

下面这张图展示了七个术语之间的结构关系：ThingShape 定义能力，ThingTemplate 组合形状并作为模板，Thing 由模板实例化；属性、服务、事件都挂在 Thing 上，订阅则把事件与处理服务连接起来。

二、Thing：设备在平台中的数字代表

Thing 是 ThingWorx 中最基本的建模单元，代表一个具体的物理对象或逻辑对象。在设备监控场景中，一台 CNC 机床、一台 AGV、一条产线的温控单元，都可以建成一个 Thing。Thing 不是数据库表，而是一个可编程对象：它拥有属性（数据字段）、服务（可调用的方法）和事件（可被监听的状态变化）。

创建 Thing 时，需要指定它基于哪个 ThingTemplate。例如，为车间 8 台同型号注塑机建模，可以先建一个名为 InjectionMoldingMachine 的模板，再基于该模板创建 IMM-01 到 IMM-08 八个 Thing。每个 Thing 共享模板定义的结构，但属性值各自独立，例如 IMM-01 的 currentTemperature 为 215.3，IMM-02 为 218.7。

三、ThingTemplate 与 ThingShape：复用与组合

ThingTemplate 是模板，用于定义一类设备的公共结构。它可以包含多个 ThingShape，也可以直接定义属性、服务和事件。ThingShape 则是更细粒度的能力集合，例如“温度采集能力”可以定义为一个 ThingShape，包含 temperature 属性、readTemperature 服务和 temperatureExceeded 事件。另一个“电机控制能力”ThingShape 包含 startMotor、stopMotor 服务。

一个 ThingTemplate 可以同时组合“温度采集能力”和“电机控制能力”两个 ThingShape，从而让基于该模板创建的 Thing 同时具备两种能力。这种设计的好处是：当需要给所有设备增加“能耗统计”能力时，只需新建一个 EnergyMonitoring ThingShape，并把它加入相关模板，所有基于该模板的 Thing 自动获得该能力，无需逐个修改。

四、属性、服务与事件

属性（Property）是 Thing 的数据字段，用于存储设备状态。属性有数据类型（NUMBER、STRING、BOOLEAN、DATETIME 等）、默认值和当前值。在监控场景中，常见属性包括 temperature（NUMBER）、runningState（STRING，取值 Running/Idle/Fault）、alarmActive（BOOLEAN）。属性可以设置为“可记录”，这样历史值会写入 Value Stream，供趋势图查询。

服务（Service）是 Thing 上可被调用的方法，用 JavaScript 编写。服务可以读取和写入属性、调用其他服务、访问数据库或外部接口。例如，一个 updateTemperature 服务接收外部传入的温度值，写入 temperature 属性，并判断是否超过阈值：

// Thing: IMM-01 上的服务 updateTemperature
var newTemp = me.temperature; // 当前值
me.temperature = newTemp;
if (newTemp > 230) {
    me.alarmActive = true;
    // 触发事件，通知订阅者
    me.temperatureExceeded(newTemp);
}

事件（Event）是 Thing 对外发出的通知信号，通常由服务在特定条件下触发。事件可以携带参数，例如 temperatureExceeded 事件携带当前温度值。事件本身不执行逻辑，它只是“广播”；真正执行响应逻辑的是订阅。

五、订阅：事件驱动自动响应

订阅（Subscription）把事件与处理逻辑连接起来。当 Thing 触发某个事件时，所有订阅了该事件的订阅者会被调用。订阅者可以是同一个 Thing 上的服务，也可以是另一个 Thing 的服务，甚至可以是平台级的工作流。

以温度报警为例：IMM-01 的 temperatureExceeded 事件被触发后，订阅可以调用 AlarmManager Thing 上的 createAlarm 服务，写入报警记录；同时调用 NotificationService 上的 sendSMS 服务，向值班人员发送短信。整个过程无需轮询，事件发生即响应。

六、建模时的实际判断

在实际项目中，判断“什么该做成 ThingShape、什么该做成 ThingTemplate”有一个实用原则：如果一段能力会被多个不相关的设备类型复用，就做成 ThingShape；如果它只服务于某一类设备，直接放在 ThingTemplate 里即可。例如“温度采集”几乎每类设备都需要，适合做成 ThingShape；“注塑机合模压力控制”只属于注塑机，放在 InjectionMoldingMachine 模板中更合适。

另一个常见问题是属性该放在 Thing 上还是模板上。原则是：所有实例都有的字段放在模板或形状上；只有个别实例才有的字段放在 Thing 上。例如 temperature 每台注塑机都有，放在模板上；moldId 只有部分设备需要记录，可以放在具体 Thing 上。