核心要点

物模型为遥测、属性、事件和命令创建有类型的契约；它应表达能力，而非抹除真实的设备差异。

物模型是一份机器可读契约，定义一类设备可以上报、暴露、发出和执行什么。它定义稳定标识符、数据类型、单位、约束、访问模式，通常还有事件或命令语义。模型为固件、平台、应用和集成提供共享语言。它应描述真实的能力和限制，而非将每个产品压平为一个虚构的通用设备。

物模型为何重要

没有模型，含义就会渗透到 UI 标签、代码分支和集成电子表格中。一个服务假设温度是摄氏度，另一个当作华氏度，第三个无法区分可写设定值和测量值。每台新设备都变成一个定制项目。

受管模型允许通用验证、UI 生成、规则配置、存储映射、文档和兼容性检查。它还使权限可见：平台可以知道哪个属性是只读的，哪个命令需要提升权限。

工作原理

模型通常将属性、遥测或观测、事件和动作分开。属性表示可读取有时可更改的状态。遥测表示随时间变化的观测。事件记录具有领域含义的发生。动作或命令请求行为，需要定义参数和结果。

每个元素需要一个独立于显示名称的稳定机器标识符。仅有类型不够。一个数值可能需要单位、范围、分辨率、枚举映射、Null 或未知语义、质量和时间戳规则。命令需要前置条件、过期机制、幂等性、授权范围、接受响应和完成证据。

模型可以是产品变体继承的模板，但组合必须保留实际差异。无法上报质量的传感器不应假装实现了与能上报质量的传感器相同的保证。可选能力应可被发现，而非仅从模型名称推断。

演进需要兼容性规则。添加可选字段可能是安全的；更改单位或为新的含义复用标识符则不是。模式版本、固件兼容性和迁移行为应显式定义。验证应在接入和命令边界进行，而非仅在 Web 表单中。

物模型解决了什么

它在设备和云端团队之间创建可复用的语义契约。它支持一致的解析、验证、存储、API 生成、规则配置和运维界面。当设备或平台发布其实际实现的能力时，它还可以支持发现。

W3C Web of Things Thing Description 等标准提供了描述属性、动作、事件、表单和安全元数据的词汇表。行业配套模型可以提供更具体的领域语义。

它没有解决什么

如果传输、安全、生命周期和行为不同，模型不能使设备互操作。两个产品都可以暴露 start 动作，但安全前置条件可能不兼容。JSON Schema 可以验证结构，但不能证明校准、物理效果或业务正确性。

模型不是设备影子。它定义契约；影子持有服务端状态表示。它也不是数字孪生，因为它本身不将模型和证据绑定到特定物理资产和决策。

适用场景——以及不适用的情况

当多个设备或消费方共享重复能力时使用物模型。保持模型小到可拥有和可版本化。领域特定模型通常比一个跨行业的巨型抽象更好。

不要为了简化仪表盘而将不相关的资产强行塞入同一形态。在影响安全、保真度或运营的地方保留厂商或型号特定约束。如果通用应用无法支持这种区分，那么太通用的可能是应用——而非设备模型。

相关技术

负载模式验证消息。设备影子存储期望状态和报告状态。数字孪生增加资产特定上下文和分析模型。OPC UA 信息模型表示有类型的节点和关系。Matter 簇和 Zigbee 簇在其生态中定义领域行为。语义词汇表可以在存在治理的前提下对齐跨模型术语。

常见误区

「一个 JSON 示例就是模型」省略了类型、约束、演进和权限。「一个模型消除所有适配器」忽略了传输和行为。「显示标签可以做 ID」破坏本地化和兼容性。「可选意味着消费方可以猜测」造成运行时意外。「模型应包含所有可能的字段」产生弱契约和不可用的界面。

为每个模型指定所有者，发布兼容性规则，并与固件、平台、应用、安全和领域专家一起审查变更。即使当前所有消费方都属于同一家公司，模型也是外部 API。