工业资产模型和遥测 Schema 不应共享一个生命周期。资产模型回答“这是什么对象、归属哪里、与谁有关”，遥测 Schema 回答“某条事件有哪些字段、单位、时间和兼容规则”，两者通过独立的绑定契约关联。它们可以放在同一个代码仓库，也可以由同一平台界面维护，但不应因为资产搬线、设备换代或采样策略变化就被迫发布同一个模型版本。
最实用的判断标准不是看两个 JSON 能不能合并，而是看一次变化应该由谁批准、影响哪些消费者、怎样回滚。如果移动一台压缩机的产线归属会迫使时序写入器重新验证，或者新增一个可选温度点会触发权限和维护系统升级，说明模型边界已经把不相关的变化绑在一起。反过来，如果同一份资产关系和信号定义之间没有可审计绑定，平台又无法解释 bearing_temperature_c 到底属于哪台设备。合理设计不是彻底隔离，而是“分开版本、显式绑定、联合发布验证”。
从一个看似简单的换机问题开始
假设工厂有一台逻辑资产 compressor-C17。它属于 A 产线，维护责任归属动力班组，通过网关 gw-04 上报排气压力和振动。半年后，现场把压缩机移到 B 产线；随后更换网关，再增加轴承温度点，最后把振动采样率从 1 Hz 提升到 10 Hz。这四个动作看起来都在“改设备模型”，实际上分别触及组织关系、物理数据源、事件结构和交付容量。
如果平台把资产树、设备连接参数、信号字段、单位、采样率和消息主题放进一个 modelVersion，每次动作都像一次全量模型升级。维护路由、租户权限、流验证器、时序存储和告警规则无法从版本号判断自己是否真的受影响，只能全部重新验证。短期看只有一个文件，长期却把发布半径扩大到所有消费者。
本文的本地演练把七类消费者分成资产侧、遥测侧和交付策略侧，并对搬线、加点、换网关、提采样率四个场景计算重验证范围。在故意耦合的合同里，每次变化都要求七类消费者重新检查，共计 28 次；拆分后按真实依赖共计 13 次。这个数字只属于显式依赖清单，不是生产效率或故障率 benchmark。它证明的是边界能表达“不受影响”，而不是证明拆分一定节省某个百分比的成本。
资产模型保存稳定身份和业务关系
资产模型的核心是对象连续性。它应保存稳定 asset_id、资产类型、组织与空间归属、父子或组成关系、维护责任、生命周期状态，以及业务查询需要的少量慢变属性。它不应该把某次消息的 sourceTimestamp、当前采样频率或 MQTT payload 字段当成资产身份的一部分。
OPC UA 的 AddressSpace 用对象、类型和引用表达可被客户端浏览的对象模型；其建模最佳实践把 Information Model 描述为应用之间的合同。这个思路的重要价值不是要求平台照搬 OPC UA NodeSet，而是提醒架构师：对象类型、实例和关系具有语义连续性，版本变化会影响依赖这些语义的客户端。把压缩机从 A 线移到 B 线，是资产图关系变化；只要信号含义没有改变，遥测消费者不应被迫接受一个新的 payload 契约。
资产模型也不等于“所有最新状态的集合”。电机额定功率、安装日期和维护等级可以是慢变属性；每秒变化的电流、振动和温度更适合进入状态或时序层。把高速值回写到资产主记录，会让缓存、审计、权限与查询承担不必要的写入压力，还会让“当前配置”和“最后一次观测”难以区分。
遥测 Schema 定义事件证据，而不是设备目录
遥测 Schema 约束一类消息如何被解释。最低限度应说明事件类型或 schema ID、版本、信号字段、数据类型、工程单位、可空性、质量语义、源时间与接收时间，以及向后兼容规则。它可以引用稳定的 asset_id 或 source_id，但不应该重复整棵资产层级和全部组织属性。
JSON Schema 的 properties、required 和 additionalProperties 能验证对象结构，但验证通过不等于语义正确。一个 temperature: 72 的 JSON 同时可能表示摄氏度、华氏度、目标值或观测值。因此工业遥测合同除了结构，还需要信号标识、单位、时间来源与质量状态。W3C WoT Thing Description 也把 Thing 元数据、交互 affordance、事件数据 Schema 和协议 forms 分成不同层级；这说明“Thing 是什么”和“一次交互交换什么数据”虽然相关，却不是同一个问题。
遥测 Schema 还应与交付策略区分。采样从 1 Hz 提升到 10 Hz，可能不改变任何 payload 字段，却会改变带宽、队列、窗口、存储和告警计算的容量假设。如果采样率硬编码在资产模型版本里，容量团队看不到独立策略变化；如果硬编码在 payload Schema 里，则任何频率调整都可能被误判为数据结构不兼容。把 sampling_policy、保留期和路由 QoS 作为可独立发布的交付策略，通常更容易做容量审批和回滚。
绑定契约负责把逻辑资产与物理信号接起来
分开资产模型和遥测 Schema 后，系统仍需要回答一个关键问题：某个数据源为什么能代表某个资产的某个信号？这个答案属于绑定契约。绑定至少包含 asset_id、逻辑 signal_id、物理 source_key、采用的 telemetry schema/version、映射或换算版本、激活时间和停用时间。绑定应可审计、可回放，并能在换网关时保留逻辑资产连续性。
例如，compressor-C17.discharge_pressure 可以先绑定到 gw-04/modbus/40001，换机后绑定到 gw-09/opcua/ns=4;s=Pressure。资产 ID 和上层查询不变，物理 source key 改变；若数据类型和单位也变化，则同时发布新的 telemetry schema 或映射版本。平台能据此区分“资产没变、连接变了”和“信号语义也变了”，避免把设备替换误写成新资产，也避免把新单位伪装成旧时间序列。
flowchart LR
A("资产模型<br/>身份·类型·关系·责任"):::blue --> C("绑定契约<br/>asset + signal + source + version"):::orange
B("遥测 Schema<br/>字段·单位·时间·质量"):::cyan --> C
D("交付策略<br/>频率·路由·保留期"):::violet --> C
C --> E("可信状态与时序写入"):::green
C --> F("告警、分析与运维应用"):::slate
classDef blue fill:#EAF4FF,stroke:#3B82F6,color:#16324F,stroke-width:2px;
classDef cyan fill:#E9FBF8,stroke:#14B8A6,color:#134E4A,stroke-width:2px;
classDef orange fill:#FFF3E8,stroke:#F08A24,color:#7C3F00,stroke-width:2px;
classDef violet fill:#F4EDFF,stroke:#8B5CF6,color:#4C1D95,stroke-width:2px;
classDef green fill:#ECFDF3,stroke:#22C55E,color:#14532D,stroke-width:2px;
classDef slate fill:#F8FAFC,stroke:#64748B,color:#1F2937,stroke-width:2px;
图中不是四套彼此隔绝的微服务。它表达的是四个可独立判断的合同。小团队完全可以把它们保存在同一数据库、同一 Git 仓库或同一管理页面，只要每个合同有自己的版本、所有者、兼容策略和变更记录。物理部署可以合并，语义与发布边界不能因此消失。
四类变化如何验证真正的影响面
| 变化 | 应变化的合同 | 不应被迫变化的部分 | 主要验证对象 |
|---|---|---|---|
| 压缩机从 A 线移到 B 线 | 资产关系 | payload 字段、单位 | 资产搜索、维护路由、权限 |
| 新增轴承温度点 | 遥测 Schema 与绑定 | 资产父子关系 | 流验证、时序写入、告警 |
| 更换物理网关 | 绑定；必要时 Schema | 逻辑资产 ID | 映射、连续性、去重 |
| 采样率从 1 Hz 到 10 Hz | 交付策略 | 资产关系；字段不变时 Schema | 容量、窗口、保留期 |
这张表的价值在于让发布评审先问“哪个合同改变”，再决定谁需要回归。如果只是搬线，流验证器仍可记录绑定版本，但不需要把所有历史 payload 当作新格式解析。如果新增可选信号，维护系统可以继续使用原资产关系；遥测消费者则需要确认未知字段策略、时序表和告警默认行为。换网关最复杂，因为 source identity、时间语义和质量码可能同时变化，此时绑定与 Schema 可以联合发布，但联合发布不等于共享一个版本号。
现场核对的重点不是让两张表看起来一致，而是确认身份、信号语义、物理 source 和激活版本之间存在可审计证据。
版本和所有权应如何分配
资产模型通常由领域或资产治理负责人批准，因为变更会影响组织、权限、维护和业务查询。遥测 Schema 更接近协议接入与数据平台团队，因为它控制解析、验证、单位、质量和兼容。绑定由现场集成或设备接入流程生成，但生产激活应受到资产与数据合同的双重校验。交付策略则需要平台容量和业务实时性共同批准。
版本策略也应反映影响。资产模型新增可选慢变属性可以是兼容小版本；删除关系类型、修改稳定 ID 语义或收紧必填字段通常需要迁移计划。遥测 Schema 新增可选字段通常允许新生产者先发布，删除字段、改变类型、单位或时间语义则应采用新 major version 或新事件类型。绑定记录不是覆盖式配置，它需要生效区间，才能解释某个历史时间点的数据来自哪个物理点和哪套换算。
不要只在文档里写“向后兼容”。发布管道应实际运行 fixture：旧生产者对新消费者、新生产者对旧消费者、未知字段、缺失字段、单位变更、乱序和重复。资产侧则需要检查稳定 ID、孤儿节点、非法环、关系多重性和权限继承。最后再做联合验证，确认一个 telemetry event 的 asset_id + signal_id + schema_version + binding_version 能解析到唯一语义。
什么时候可以放在一份模型里
小型系统不必为了概念纯洁建立四个服务。如果设备类型很少、团队相同、变更频率相近、消费者数量有限，把资产、信号和连接定义放在一个仓库或一个声明文件中完全合理。但文件中仍应有清晰命名空间，例如 assetModelVersion、telemetrySchemaVersion、bindingVersion，并允许只发布其中一个合同。否则“同库”很容易滑向“同版本、同审批、同回滚”。
原型阶段也可以暂时合并，但要预留拆分点：稳定资产 ID 不使用 MQTT topic 生成，信号 ID 不使用数据库列名代替，物理 source key 不暴露给业务查询，采样率不被当作资产类型常量。这样从几十台设备扩大到多工厂时，拆分主要是发布流程调整，而不是重写历史身份。
如果平台只做短期采集，没有跨设备关系、维护责任、权限继承或长期历史连续性，那么完整资产图可能过重。此时保留一个最小设备注册表和严格 telemetry schema 更合适。反过来，如果主要目标是维护、空间关系和数字孪生，而实时数据量很小，也不要为了形式强行建设复杂流式 Schema 注册中心。边界应跟随真实消费者，而不是跟随流行架构名词。
从耦合模型迁移时不要一次性重写
第一步是冻结现有合同的解释，而不是立刻拆库。列出当前字段分别服务资产查询、消息解析、连接映射还是容量策略，并找出被多个职责共同使用的模糊字段，例如 deviceId、name、frequency 和 path。为现有数据建立显式兼容层，保留旧版本读取，避免拆分动作改变历史含义。
第二步先引入稳定 asset_id、逻辑 signal_id 和 binding_version。新消息可以在不改变业务语义的情况下携带这些标识，旧消息由适配器补齐。随后把资产关系变更和 telemetry schema 变更拆成两条发布记录，分别维护依赖清单。只有当双写、回放和查询对账通过后，才停止旧耦合合同。
第三步把变更场景写进持续验证。搬线不应触发 payload 版本变化；新增可选点不应改变资产 ID；换网关应能保持逻辑时间序列连续并保留 source provenance；提高采样率必须先通过容量与窗口检查。这些测试比“模型 JSON 能否通过语法校验”更接近生产风险。
如果还没有可靠的 Tag 身份与发布链，可以先阅读工业 Tag 模型与治理；若问题集中在数据从现场到平台的放置位置，参考工业遥测数据链路分层；对于接通后仍不可用的数据，参考Brownfield 工业数据质量治理。
最终判断
把资产模型与遥测 Schema 分开的目的不是制造更多文件，而是让不相关的变化不再共享爆炸半径。资产模型维护稳定对象和关系，遥测 Schema 维护事件结构和解释规则，交付策略维护频率与容量，绑定契约提供可审计连接。它们可以同库、同界面甚至同服务，但应独立版本、独立审批、独立回滚，并在生产发布前做联合验证。
当团队无法回答“这次变化究竟影响资产消费者还是数据消费者”时，先不要增加更多数字孪生字段。先建立三个版本号和一条绑定记录，再用搬线、加点、换机、提采样率四个场景验证边界。能够明确证明谁不受影响，才是一个可扩展工业模型真正的价值。
参考资料
- OPC UA Part 3: Node Model
- OPC UA Modelling Best Practices: Overview
- W3C Web of Things Thing Description 1.1
- JSON Schema: Object
- Microsoft Learn: DTDL models in Azure Digital Twins
FAQ
资产模型里完全不能出现实时状态吗？
可以保存少量派生的当前状态或慢变属性，但要标明它来自哪个 telemetry/binding version，并避免把资产主记录当作高频时序存储。
一个 DTDL 或 Thing Description 同时包含属性和数据 Schema，是否说明不必拆分？
不是。标准描述表达能力，不替你的组织决定版本、所有权和发布半径。即使序列化在同一文档，也可以把资产语义、交互数据和绑定策略作为独立合同管理。
什么时候必须引入 Schema Registry？
当生产者和消费者独立发布、事件类型多、兼容错误会污染状态或告警时，集中注册和兼容检查很有价值。设备少、团队单一的系统可以先用 Git 与 CI 管理版本化 Schema。
