2. 从物理设备到数字资产
在上一节中我们已经明确：ThingWorx 中的“资产”并不是设备本身，而是设备在平台中的数字化表示。要建立这种表示，第一步不是打开建模工具，而是沿着一条真实的数据链路，把物理世界里“发生了什么”逐层翻译成平台可以承载的属性、事件、服务和关系。本节以一台典型的工业设备——例如一台带变频驱动的离心泵机组——为例，完整走一遍从传感器到云平台的数据链路，并从中识别出需要建模的资产要素。
一、先看清物理侧：这台泵机组上有什么
假设这是一台用于循环水系统的离心泵，配套一台 7.5 kW 三相异步电机，由一台小型 PLC 控制，现场配有若干传感器。物理侧的典型配置如下（参数为教学示例，非实测值）：
- 振动传感器：安装在泵轴承座，输出 4–20 mA 信号，量程 0–20 mm/s，对应振动烈度。
- 温度传感器：PT100 贴装于电机绕组，测量范围 0–150 ℃。
- 压力变送器：泵出口，4–20 mA，量程 0–1.6 MPa。
- 流量计：电磁式，输出脉冲或 Modbus 寄存器，量程 0–200 m³/h。
- PLC：采集上述模拟量与数字量，执行启停联锁，并通过 Modbus TCP 对外提供寄存器。
- 网关：现场边缘网关，通过 Modbus TCP 轮询 PLC，再以 MQTT 上报到云平台。
这里有一个关键认识：传感器和 PLC 只产生“信号”，不产生“资产”。振动 4–20 mA 只是一个电流值，PLC 寄存器里的 32767 也只是一个整数。只有当平台知道“这个寄存器代表泵轴承振动、单位是 mm/s、量程是 0–20”时，它才成为有意义的属性。这正是资产建模要解决的问题。
二、数据链路：从 4–20 mA 到平台属性
这条链路可以拆成五段，每一段都发生一次“语义转换”：
- 物理量 → 电信号：轴承振动 8.5 mm/s 被传感器转换为约 13.6 mA（按 4–20 mA 线性对应 0–20 mm/s 计算：4 + 16 × 8.5/20 = 10.8 mA，此处仅示意换算关系）。
- 电信号 → PLC 原始值：PLC 模拟量模块 12 位分辨率，0–20 mA 对应 0–27648，则 10.8 mA 对应约 14930。
- PLC 原始值 → 网关数值：网关读取寄存器，按配置的缩放公式还原为工程量：
value = raw / 27648 × 20，得到 10.8 mm/s 附近的振动值。 - 网关 → 云平台：网关以 MQTT 主题
pump/line1/vibration发布 JSON 报文，包含时间戳与数值。 - 平台报文 → 资产属性：ThingWorx 通过工业连接或 MQTT 订阅接收报文，将其映射到“泵机组”Thing 的
vibration属性上。
注意第 3 步的缩放公式：如果网关配置错误，把 0–27648 直接当作 0–20 使用，平台收到的振动值就会偏差一个数量级。这类“链路正确、语义错误”的问题，在建模阶段必须通过属性定义中的单位、量程、缩放来显式约束，而不是靠事后猜。
三、从链路中识别四类建模要素
沿着上面这条链路，我们可以把需要建模的内容归为四类，它们恰好对应 ThingWorx 中 Thing 的四个核心组成：
| 建模要素 | 在本例中的具体内容 | 判断依据 |
|---|---|---|
| 属性 Property | 振动、绕组温度、出口压力、流量、运行状态、累计运行小时 | 随时间变化、需要被监测或参与计算的状态量 |
| 事件 Event | 振动超限、温度超限、干转、启停动作 | 需要被记录、告警或触发后续动作的瞬时发生 |
| 服务 Service | 启动、停止、复位报警、生成健康报告 | 需要由平台或用户主动发起的动作 |
| 关系 Relation | 泵机组—电机、泵机组—变频器、泵机组—产线、泵机组—网关 | 资产之间需要被追溯、聚合或联动的连接 |
这里要特别强调“判断依据”一列。很多初学者会把所有采集到的量都建成属性，把所有报警都建成事件，结果模型臃肿且难以维护。更稳妥的做法是：属性回答“现在是什么状态”，事件回答“刚刚发生了什么”，服务回答“能对它做什么”，关系回答“它和谁在一起”。四者职责不重叠，模型才清晰。
四、一个容易忽略的环节：网关本身也是资产
在上面的链路中，网关往往被当作“透明管道”。但在实际运维中，网关的在线状态、缓存积压量、最后上报时间，直接决定了平台数据是否可信。如果网关离线 10 分钟，平台上的振动属性会停留在旧值，此时若基于该值触发告警，就会产生误判。因此，网关应当被建模为一个独立资产，至少包含 online、lastReportTime、bufferCount 三个属性，并通过关系与泵机组关联。这样，平台在判断泵机组健康度时，可以先检查数据新鲜度，再决定是否采信属性值。
五、从链路到模型：一次完整的映射练习
把上面的分析落成一张建模清单，可以按下面的顺序推进：
- 列出物理设备上的所有测点与执行机构，标注信号类型与量程。
- 确认每个测点在 PLC 中的寄存器地址与缩放公式。
- 确认网关的 MQTT 主题命名与报文结构。
- 在平台侧为每个测点定义属性：名称、数据类型、单位、量程、默认值、是否记录历史。
- 为需要告警或触发的状态定义事件，并写明触发条件与阈值来源。
- 为需要远程下发的动作定义服务，并明确输入参数与返回结果。
- 梳理资产之间的包含、连接、引用关系，确定父子层级与关联方向。
以振动为例，最终在平台上的属性定义可以写成：名称 vibration，类型 NUMBER，单位 mm/s，量程 0–20，历史存储开启，数据来源为 MQTT 主题 pump/line1/vibration。对应的事件 HighVibration 触发条件为 vibration > 11.2（ISO 10816 中该功率段泵的报警阈值示例），持续 5 秒。对应的服务 Stop 则向 PLC 写入停机指令。三者通过同一个 Thing 聚合，形成完整的数字资产。