为什么还需要配套规范
基础规范提供的是一套通用工具箱：如何建节点、如何读写、如何加密。它不规定一台泵该有哪些变量，也不规定温度该用什么单位。配套规范由行业组织与厂商共同制定，在独立命名空间里定义对象类型、必选与可选组件、工程单位与状态语义，从而让不同品牌设备在信息模型层面互认。选择设备时把是否支持对应配套规范写成明确要求，能显著降低后续集成工作量。
基本信息
| 基础规范 | 定义地址空间、服务、传输与安全，不定义行业语义 |
|---|---|
| 配套规范 | 定义行业对象类型、组件、单位与状态机 |
| 命名空间 | 每个规范一个独立命名空间，避免名称冲突 |
| 组件约束 | 区分必选与可选，便于上位机按最小集解析 |
| 版本管理 | 规范版本与设备声明版本需对齐 |
| 获取方式 | 规范组织公布的目录与规范文档为准 |
典型使用场景
- 选型阶段：把支持某类设备规范列为招标要求，避免后期硬编码适配
- 上位机开发：按规范类型解析，一套界面适配多个品牌的同类设备
- 设备建模：直接复用规范里定义的类型，减少自定义字段
- 互操作测试：用规范里的必选组件清单做验收检查
- 跨系统集成：设备规范与上层系统规范之间的映射有据可依
- 版本升级：规范换代时按差异清单逐项确认，而不是整体重写
选用思路
| 判断项 | 说明 | 注意点 |
|---|---|---|
| 领域是否已有规范 | 先查规范组织目录再动手建模 | 同领域可能有多套并存 |
| 设备是否声明支持 | 看设备文档与地址空间中的命名空间 | 声明支持不代表结构完整 |
| 上位机类型库 | 确认组态软件是否内置该规范类型 | 否则仍需自建类型 |
| 结构完整性 | 必选组件是否齐备、类型是否可浏览 | 只有标签列表说明未真正实现 |
| 版本一致性 | 两侧规范版本需对齐 | 跨版本差异要逐项核对 |
接入前的检查清单
接入前的检查清单
# 1 浏览设备命名空间，确认声明了哪些规范命名空间
# 2 抽样检查对象类型是否为规范类型，而不是仅有变量清单
# 3 核对必选组件：缺少必选组件说明实现不完整
# 4 记录规范版本，与上位机类型库版本比对
# 5 无对应规范时：自定义命名空间并定义类型，避免扁平标签表没有配套规范可用的场合，自定义类型远好过堆标签：类型定义一次，之后新增同类设备只需实例化，客户端界面与逻辑都不用改。
把某厂商的私有扩展当成行业通用标准使用，换品牌时适配成本会远超预期；扩展字段应单独记录并做好缺失兜底。