4. 设备建模与物模型设计

在物联网数字孪生平台中，设备建模是把物理世界中的真实设备抽象为平台可理解、可管理、可计算的数据对象。物模型（Thing Model）就是这种抽象的核心载体，它用统一的结构描述“设备是什么、能上报什么、能执行什么、会触发什么”。没有物模型，平台只能看到一串无意义的原始报文；有了物模型，平台才能把温度、开关、告警、指令等语义绑定到具体设备上，进而驱动数字孪生体的状态同步与可视化。

物模型的三类核心元素：属性、事件、服务

物模型通常由属性（Property）、事件（Event）和服务（Service）三类元素构成，它们分别对应设备的静态/动态状态、主动通知和可被调用的能力。

• 属性：描述设备当前可读取或可设置的状态量，如温度、湿度、开关状态、运行模式。属性具有数据类型、取值范围、读写权限和单位。例如温度属性可定义为 float，范围 -40~125，单位 ℃，只读。
• 事件：描述设备主动上报的通知，如高温告警、故障告警、离线通知。事件通常包含事件标识、事件级别和输出参数。例如“高温告警”事件可携带 currentTemp 和 threshold 两个参数。
• 服务：描述设备可被平台调用的能力，如重启、校准、设置阈值。服务包含输入参数和输出参数，调用后设备返回执行结果。例如“设置温度阈值”服务输入 threshold，输出 code 和 message。

这三类元素共同构成设备的“能力契约”。平台侧依据物模型解析数据、生成指令、判断告警；设备侧依据物模型组织上报报文和响应调用。双方只要遵循同一份物模型，就能实现语义一致。

用 JSON Schema 描述物模型

物模型在平台中通常以 JSON 文档存储和传输，而 JSON Schema 则用于约束这份 JSON 的结构与取值。JSON Schema 不是物模型本身，而是物模型的“元描述”——它规定物模型文档中必须有哪些字段、字段类型是什么、取值范围如何、哪些字段必填。这样平台在导入物模型时就能自动校验，避免因字段缺失或类型错误导致设备接入失败。

下面给出一个简化的温度传感器物模型示例，包含属性、事件和服务三类元素：

{
  "productKey": "PK_TEMP_001",
  "deviceType": "temperature_sensor",
  "properties": [
    {
      "identifier": "temperature",
      "name": "温度",
      "dataType": "float",
      "unit": "℃",
      "min": -40,
      "max": 125,
      "accessMode": "r"
    },
    {
      "identifier": "sampleInterval",
      "name": "采样间隔",
      "dataType": "int",
      "unit": "s",
      "min": 1,
      "max": 3600,
      "accessMode": "rw"
    }
  ],
  "events": [
    {
      "identifier": "highTempAlarm",
      "name": "高温告警",
      "level": "warning",
      "outputData": [
        { "identifier": "currentTemp", "dataType": "float" },
        { "identifier": "threshold", "dataType": "float" }
      ]
    }
  ],
  "services": [
    {
      "identifier": "setThreshold",
      "name": "设置温度阈值",
      "inputData": [
        { "identifier": "threshold", "dataType": "float", "min": -40, "max": 125 }
      ],
      "outputData": [
        { "identifier": "code", "dataType": "int" },
        { "identifier": "message", "dataType": "string" }
      ]
    }
  ]
}

对应的 JSON Schema 片段可约束 properties 数组中每个元素的 identifier 必须为字符串、dataType 必须属于枚举值集合、accessMode 只能为 r、w 或 rw。平台导入时先做 Schema 校验，再写入物模型库，后续设备上报数据时按 identifier 匹配属性并做类型转换。

设备影子机制：让数字孪生体与物理设备解耦

设备影子（Device Shadow）是物模型在平台侧的一份持久化状态副本。它保存设备最近一次上报的属性值、期望下发的属性值以及元数据（时间戳、版本号）。设备影子解决的核心问题是：设备可能离线、网络可能抖动，但平台和上层应用仍需要随时读取设备最新状态、下发期望状态，并在设备重新上线后自动同步。

设备影子通常包含三个部分：reported（设备上报的当前状态）、desired（平台期望设备达到的状态）、metadata（各字段的更新时间与版本）。当平台下发期望状态时，影子先更新 desired；设备上线后拉取影子，发现 desired 与 reported 不一致，便执行相应动作，再把新状态写入 reported。这样，数字孪生体始终以影子为数据源，而不必强依赖设备实时在线。

上图展示了物理设备、物模型、设备影子与数字孪生体之间的协同关系。设备通过物模型定义的能力上报属性、触发事件、响应服务；平台把设备状态写入影子；数字孪生体从影子读取状态并驱动可视化。当设备离线时，平台仍可向影子写入 desired 值，待设备重新上线后再完成同步。

建模实践中的关键判断

在实际项目中，物模型设计需要重点考虑以下几点。第一，标识符命名要稳定且唯一，一旦设备接入后修改 identifier，历史数据将无法关联，因此建议在项目初期就确定命名规范，如采用小驼峰、避免中文和特殊字符。第二，数据类型与取值范围要与设备实际能力一致，例如温度属性若设备只支持整数上报，就不应定义为 float，否则平台解析时会产生精度歧义。第三，读写权限要明确，只读属性不允许平台下发，可读写属性才支持期望值下发。第四，事件级别要合理，info、warning、error 三级可用于后续告警分级处理。

设备影子的使用也有边界。影子适合保存“最新状态”和“期望状态”，不适合保存高频时序数据。温度每秒上报一次，若每次都写入影子，会造成大量无效更新。通常做法是：影子只保留最新值，历史数据写入时序数据库；影子版本号用于并发控制，避免平台多次下发期望值时相互覆盖。当设备上报 reported 后，平台比较 desired 与 reported，若一致则清除期望标记，若不一致则保持等待或触发重试。

综合来看，设备建模与物模型设计是数字孪生平台从“连接设备”走向“理解设备”的关键一步。属性、事件、服务三类元素构成设备的能力描述，JSON Schema 保证描述的结构合法性，设备影子则让平台状态与物理设备解耦。掌握这三者的关系与配置方法，才能为后续的数据采集、规则引擎、可视化与远程控制打下可靠基础。