基于MQTT和Sparkplug B的UNS系统的元数据管理

一个基于 MQTT + Sparkplug B 的 UNS（Unified Namespace）统一命名空间 要真正发挥作用，相关的元数据（metadata）管理系统 必须设计得清晰、层次化、且可自动维护。

我们可以从三个层面来分析和设计：

一、明确元数据（Metadata）的作用与范围

在 MQTT + Sparkplug B 的 UNS 中，元据数管理的核心目的是：

"让数据的语义、来源、结构、单位、质量状态等信息在全网内被一致地理解。"

因此元数据不仅是描述"名字"，更包括：

元数据类别	说明	典型来源
结构元数据	设备层级、节点、群组、指标（Tag）层次	Sparkplug B Topic 结构
语义元数据	变量含义、单位、精度、工程上下限、类别	工程数据库、ISA-95模型
状态元数据	数据质量（Good/Bad）、时间戳、设备状态、触发类型	Sparkplug payload + MQTT message header
上下文元数据	设备所属生产线、工段、工厂、资产编号	来自资产管理系统（AMS/EAM）或配置中心

二、MQTT Topic 层面的元数设计

Sparkplug B 已定义了严格的 Topic 结构：

复制代码

spBv1.0/<Group_ID>/<Message_Type>/<Edge_Node_ID>/<Device_ID>

但这个结构只是通信语义的"骨架"。要让它成为 UNS 的"语义命名空间"，需要在此基础上拓展一层 命名规则元数据。

推荐做法：

定义统一的命名空间映射规范
- 例如：
  复制代码
```
spBv1.0/SITE_A/DBIRTH/LINE1_ROBOT1/ARM_MOTOR
```
  其中：
  - SITE_A → 工厂
  - LINE1_ROBOT1 → 生产线 + 设备
  - ARM_MOTOR → 子模块（可对应资产清单）

在中央配置库维护Topic命名规则元数据

建立一个 JSON/YAML 格式的命名空间注册表，例如：

复制代码

namespace:
  SITE_A:
    description: "Plant A Main Site"
    line:
      LINE1_ROBOT1:
        device:
          ARM_MOTOR:
            topic: "spBv1.0/SITE_A/LINE1_ROBOT1/ARM_MOTOR"
            tags:
              speed:
                unit: "rpm"
                datatype: "float"
                source: "PLC_Tag_101"
              torque:
                unit: "Nm"
                datatype: "float"
                source: "PLC_Tag_102"

命名空间注册表应可被MQTT Broker或UNS服务动态加载
- 可以在 EMQX / HiveMQ 等 broker 的 retained message 中发布元数信息；
- 或者在 UNS 管理端（例如 Node-RED、n8n、或自研配置中心）维护一套 Topic--元数据映射表 并对外提供 REST/GraphQL 接口。

三、Sparkplug B Payload 层面的元数管理

Sparkplug B payload 是二进制格式（ProtoBuf），其中的 Metric 结构支持元数据字段：

复制代码

message Metric {
  string name = 1;
  DataType datatype = 2;
  bytes value = 3;
  MetaData metadata = 8;
}

而 MetaData 可包含：

units
description
displayName
format
engLow / engHigh
step
scaling
customMetaData

四、元数据的集中管理与可视化机制

为避免多源定义混乱，应设置一个 UNS 元数管理中心，可以是：

一个数据库（如 PostgreSQL + JSONB）；
一个轻量级服务（如 Flask / FastAPI）；
或者直接在 MQTT Broker 上发布元数Topic，如：
复制代码
```
$UNS/meta/<Group>/<Node>/<Device>
```

这些Topic可以存放元数据快照，供可视化和分析系统调用。

元数管理中心的功能：

功能	描述
命名空间注册表	定义和校验 Topic 命名规则
元数据存储	从 DBIRTH 抽取的 Metric 元信息集中管理
版本与历史	记录设备/变量的元数据变更历史
验证与一致性检查	检测Topic命名、单位、数据类型是否与标准一致
可视化浏览	提供UNS命名树视图（如：厂区 → 产线 → 设备 → 信号）

五、总结：UNS元数管理体系架构图

复制代码

 ┌──────────────────────────────┐
 │         上层系统 (MES/BI/AI) │
 └──────────────┬───────────────┘
                │ 通过语义接口访问
 ┌──────────────┴───────────────┐
 │     UNS 服务层（Metadata Registry） │
 │  • Topic规则管理                  │
 │  • Metric元数据提取/同步         │
 │  • 命名空间树结构维护            │
 └──────────────┬───────────────┘
                │ 订阅DBIRTH/DEATH
 ┌──────────────┴───────────────┐
 │        MQTT Broker (EMQX等)    │
 │  • Sparkplug B协议管理          │
 │  • Retained Message元数缓存     │
 └──────────────┬───────────────┘
                │
 ┌──────────────┴───────────────┐
 │   Edge Node / Device          │
 │  • 发布DBIRTH含Metric元数据    │
 │  • 定期发布DDATA实时值         │
 └──────────────────────────────┘

基于MQTT和Sparkplug B的UNS系统的元数据管理

一、明确元数据（Metadata）的作用与范围

二、MQTT Topic 层面的元数设计

推荐做法：

三、Sparkplug B Payload 层面的元数管理

推荐策略：

四、元数据的集中管理与可视化机制

元数管理中心的功能：

五、总结：UNS元数管理体系架构图