定义
Thing Model（物模型）是物联网设备的数字化描述，定义设备的 Property（属性）、Event（事件）、Service（服务）等能力。不同协议的数据经 Protocol Adaptation 映射为统一的物模型，上层应用无需关心底层协议差异。
核心组成
- Property：设备可读写的状态属性，如温度、湿度
- Event：设备上报的离散事件，如告警、故障码
- Service：设备可调用的服务，如重启、参数设置
与数据流的关系
Property 对应 Telemetry 遥测数据的上报与 Device Shadow 设备影子的读写；Event 对应事件消息，可触发 Rule Engine 规则引擎；Service 对应 Downstream Command 下行指令的调用。物模型是设备与平台、应用之间的契约，不同协议（MQTT、LwM2M、Modbus 等）经 Protocol Adaptation 映射为统一物模型，上层应用无需关心协议差异。
物模型管理
物模型通常按产品维度定义，支持版本管理、继承与扩展。平台提供物模型编辑器或 JSON/DSL 导入，定义属性数据类型、取值范围、单位、事件参数、服务入参出参等。物模型变更需考虑兼容性，避免影响已上线设备与应用的解析。
属性、事件、服务三类契约不可混用
物模型是同一产品下设备与平台之间的契约，分成三种不同的交换。属性是可读取的状态或测量，可能被周期上报，也可能被写入期望值。事件是发生一次就应该被记下的通知，带有发生时刻和参数，不适合拿来画连续曲线。服务是平台请求设备做一件事，必须有入参、出参和完成与否的回执。把“重启”定义成一个可写属性，平台只看见值被改成了真，却不知道设备是否接受、是否执行完。
命名在产品内要稳定，单位和取值范围写在模型里，而不是写在每个应用的解析代码里。同一物理量只保留一个属性标识。协议侧的寄存器、对象节点和资源路径通过映射指到这个标识，映射可以变，标识不变。上层的接口和存储都引用标识。这样更换现场协议时，历史和规则不必跟着地址改。枚举值要列出含义，未列出的值应视为未知并保留原值，不能在入库时丢弃，否则新固件增加的状态会变成空。
版本升级时旧设备仍要能解析
模型可以出新版本，但已经出厂的设备仍在使用旧版本。新增可选属性、新增事件，一般可以兼容：旧设备不上报这些项，平台按缺失处理。删除属性、改变类型、改变单位、改变枚举含义，都不兼容。不兼容的变更应使用新标识或明确的新版本，并让规则和报表声明自己依赖哪一版。不能在同一标识上把“摄氏度的整数”改成“毫度的小数”，旧点新点会接成一条无法阅读的曲线。
发布顺序应先让平台认识新模型，再让设备升级后按新模型上报。若设备先升级，平台还按旧模型拒绝未知字段，升级后的数据会在接入层被丢掉。服务的入参同样如此：新版本增加必填参数时，旧的调用方会全部失败，新增参数在过渡期应有默认值。一个产品的模型不要按单个项目复制出无法合并的私有版本；项目差异用少量扩展属性表达，并在文档中标明哪些是通用、哪些是扩展。时序存储按属性标识落点，见时序库的标签设计，模型标识不稳定会直接变成新的序列。
为每个寄存器单独建一个服务
现场点表很长时，容易把每一个寄存器都建成一个服务，或者都建成一个事件。服务数量膨胀后，调用方无法分辨哪些是人可以触发的动作，哪些只是内部读数。读数应是属性，由采集周期或影子读取负责；只有需要设备执行并回执的动作才是服务。报警发生是事件，报警的当前是否存在也可以另有一个属性，两者不要互相替代。
另一类错误是用一个无结构的字符串属性装下所有数据，把模型退化成透传通道。这样平台无法做类型校验、单位换算和单项权限。个别尚未建模的诊断信息可以暂时用结构化的扩展字段，但进入常规监控的量应升格为正式属性。复制模型时若连同试验字段一起复制到新产品，正式环境会出现从未有设备上报的项，报表把缺失算成零。发布前应删掉没有设备会实现的项，并标明每个服务是否允许批量调用。允许批量的服务必须能承受重复请求，因为批量重试比单台更常见。
模型评审时逐项询问：这一项是持续可读的量、一次发生的通知，还是需要回执的动作。归类不确定的先不要发布。发布说明里给出与上一版的差异：新增、废弃、含义是否变化。废弃项在平台侧标记为只读历史，新设备的接入校验不再要求它出现。测试夹具按模型生成一份合法样本和一份故意缺字段的样本，接入校验必须拒绝缺必填项的那一份。没有这项测试，不兼容变更会在生产设备升级后才被发现。