3. ThingWorx建模基础
ThingWorx 的建模体系可以理解为“用可复用的模板和形状，批量生成可运行的数字化对象”。在平台里，Thing 是最终被实例化、被绑定、被调用的实体；Thing Template 是生成 Thing 的蓝图；Thing Shape 是可被多个模板复用的能力片段；而网络与事物模型则决定这些实体之间如何连接、如何组织层级、如何被统一管理。理解这四者的关系，是后续做设备接入、数据建模和服务编排的前提。
一、Thing：最小可运行实体
Thing 是 ThingWorx 中最基本的可操作对象。一个 Thing 通常对应一台设备、一个网关、一条产线、一个工位，甚至一个虚拟计算单元。它拥有三类核心成员：属性（Property）、服务（Service）、事件与订阅（Event & Subscription）。属性描述状态，服务定义行为，事件与订阅负责在状态变化时触发响应。
例如，为一个温度传感器建立 Thing，命名为 Thing_TempSensor_01。它至少需要：属性 Temperature（NUMBER，单位 ℃）、属性 OnlineStatus（BOOLEAN）、服务 ReadTemperature()、事件 TemperatureChanged。当 Temperature 被远程写入或由服务更新时，事件被触发，订阅该事件的监听者即可执行后续逻辑。这里的关键是：Thing 不是静态数据表，而是“属性 + 服务 + 事件”三件套同时具备的运行单元。
二、Thing Template：批量实例化的蓝图
如果现场有 200 台同型号温度传感器，逐台创建 Thing 并手工添加属性、服务、事件，既低效又容易出错。Thing Template 解决的就是这个问题：它把一类设备的公共属性、服务、事件、订阅和配置预先定义好，然后通过“基于模板创建 Thing”批量生成实例。
模板中定义的内容会继承到每个 Thing 实例。实例可以覆盖默认值，也可以增加自己特有的属性或服务，但模板层面的修改会同步影响所有实例。因此，模板适合放“共性”，实例适合放“个性”。例如模板 TT_TempSensor 中定义 Temperature 默认值 25、OnlineStatus 默认 false、服务 ReadTemperature() 和事件 TemperatureChanged；实例 Thing_TempSensor_01 只需覆盖 DeviceId = "TS-001"、Location = "A线" 即可投入使用。
三、Thing Shape：可组合的能力片段
Thing Shape 是比模板更细粒度的复用单元。它不直接生成 Thing，而是被 Thing Template 或 Thing 引用，用来“拼装”能力。一个 Thing 可以同时实现多个 Thing Shape，从而获得多个能力集合。这种机制类似“接口 + 默认实现”的组合，使建模不必把所有能力都塞进一个庞大的模板。
典型做法是定义 TS_Connectivity（含 OnlineStatus、LastHeartbeat、服务 Ping()）、TS_Measurement（含 Temperature、Humidity、服务 ReadMeasurement()）、TS_Alarm（含 AlarmActive、事件 AlarmRaised）。温度传感器模板同时实现这三个 Shape，就自然拥有连接、测量和报警能力。若某类设备不需要报警，只实现前两个 Shape 即可。Shape 的价值在于“按需组合、避免重复定义”。
四、网络与事物模型：从单点走向体系
当 Thing 数量增多，必须回答“谁属于谁、谁连接谁、谁向谁上报”。ThingWorx 通过网络（Network）和事物模型（Thing Model）来组织这种关系。网络通常用于表达设备与网关、网关与平台之间的连接拓扑；事物模型则用于表达层级归属，例如“企业—工厂—产线—设备”的树状结构。
在建模时，建议先画一张拓扑草图：边缘层是传感器/PLC，接入层是网关，平台层是 Thing 实例，应用层是 Mashup 或服务。每个 Thing 通过 RemoteThing 或 EdgeThing 与真实设备绑定，再通过 ThingTemplate 统一管理。这样，当现场新增一台设备时，只需在对应网络节点下创建实例并绑定，而不必改动整体结构。
五、属性、服务、事件与订阅的协作方式
属性是 Thing 的状态载体，分为可读写、只读、持久化等类型。服务是 Thing 的行为入口，可以用 JavaScript 编写，也可以调用外部 REST 接口。事件是“状态变化的信号”，订阅是“对信号的响应绑定”。三者协作的典型链路是：服务读取设备数据 → 更新属性 → 属性变化触发事件 → 订阅执行后续动作。
以温度采集为例，服务 ReadTemperature() 从边缘设备读取 26.5，写入属性 Temperature；若该属性配置了 TemperatureChanged 事件，则事件被触发；订阅该事件的处理器判断 26.5 是否超过阈值 30，若未超过则仅记录，若超过则调用 AlarmRaised 并发送通知。整个过程不需要轮询，而是由属性变化驱动，响应更及时。
六、建模顺序与常见判断
实际建模时，建议按“先 Shape、再 Template、后 Thing”的顺序推进。先梳理设备共性能力，拆成若干 Thing Shape；再用 Template 组合 Shape 并定义默认属性、服务和事件；最后基于 Template 批量创建 Thing 实例，并绑定真实设备地址。若某类设备只有一台，也可以直接创建 Thing 并引用 Shape，不必强行建模板。
判断建模是否合理，可以看三个信号：新增同类设备时是否只需创建实例而无需重复定义属性与服务；修改公共逻辑时是否只需改模板或 Shape 而无需逐台修改；事件触发后是否能在订阅端稳定拿到属性值并执行预期动作。若这三点都满足，说明 Thing、Template、Shape 的分层是清晰的，网络与事物模型也能支撑后续扩展。