明说·协议课 第 5 讲｜充电设备如何基于 GB/T 44130 接入云平台：从设备注册到交易记录确认

本讲依据：GB/T 44130.4-2025《电动汽车充换电服务信息交换 第 4 部分：充换电设备与服务平台信息交换》、GB/T 44130.5-2025《电动汽车充换电服务信息交换 第 5 部分：数据传输及安全》。两部分均于 2025 年 8 月 29 日发布，2026 年 3 月 1 日实施。核对时间为 2026 年 8 月。本文讨论标准规定的协议行为，不据此推断现网设备已经完成支持或迁移。

第四讲讨论了充电设备如何基于 YKC 协议接入云平台。这一讲仍在桩—云这一层，我们来看推荐性国家标准 GB/T 44130.4-2025 和 GB/T 44130.5-2025。

这套标准使用 MQTT 在设备与服务平台之间传递消息。Topic 区分功能类别、传输方向和设备编号，消息体采用 JSON。对接入层来说，订阅 Topic、解析通用消息主体，再按 messageName 把消息交给相应的处理器，确实比从 TCP 字节流中识别一帧二进制报文直观。也正因为报文形式熟悉，开发时反而容易把“消息已经收到”顺手写成“现场动作已经完成”，把本应分开保存的状态合并到一起。

下面这组状态，在同一次远程启动过程中完全可能同时出现在平台里：

MQTT 连接：已建立
DevLogin.s2c：允许登录
StartCharge.c2s：已经收到
StartChargeResult.c2s：尚未收到
最近一次充电中数据：未观察到能量增长
平台业务订单：充电中

前五项可以同时成立。MQTT 连接建立，说明本次连接已经按照当前安全策略完成相应认证，传输通道也已经成立；DevLogin.s2c 允许登录，表示设备可以发起后续业务流程；StartCharge.c2s 的消息体只有平台订单流水号和设备订单流水号，并没有启动成功或失败字段。设备报告的启动结果要看 StartChargeResult.c2s，能量是否已经传输，还要核对后续的交流或直流充电中数据。如果平台只掌握前五项事实，最后一项就没有足够的协议依据：仅凭 StartCharge.c2s，还不能把业务订单改成“充电中”。

开篇这条失败路径，是依据标准的消息结构和确认语义推演出来的，并不对应某个特定的现网故障。这种错误又很像平台开发中会发生的事：每条消息都收到了，字段也解析正确，单看每项记录似乎都能解释；可把它们放回同一次充电，平台给出的状态已经偏离事实。真正需要处理的，是每条消息描述哪个对象、能够确认到哪一步，以及两项订单流水号怎样逐步建立关联。

要把这个问题说明白，逐条翻译报文还不够。我们需要把这些消息放回设备接入和一次充电发生的全过程，弄清设备注册、连接认证、设备登录、启动应答、启动结果、运行数据和交易记录确认各自解决什么问题。整篇读完后，我们最终应该能够回答两个很具体的问题：为什么不能用一个“在线”概括设备的接入状态，又为什么不能用一个“成功”概括一次充电。

一、设备接入与一次充电，要分成两个过程来看

GB/T 44130.4-2025 规定的内容远不止启动和停止。时间同步、设备认证、状态与异常报告、服务交易、电能量测、能量互动、预约和运维，都在它的功能体系里。如果直接从第 9 章功能一览表往下读，很容易把“标准定义了哪些功能”误解成“每次充电都要按表格顺序执行哪些消息”。

我们设计平台状态时，需要先分开两个过程。一个围绕设备展开：设备完成注册，通过连接认证和登录进入可交互状态，此后还要维护心跳、设备状态与异常信息；另一个围绕某一次充电展开：它怎样开始、运行和结束，又怎样形成交易记录。两个过程会共享设备身份、当前连接、设备时间和计费方案等上下文，但描述的对象不同，不能共用一套状态。

把它们放在同一条业务时序上，可以看到两者在什么地方发生联系：

确定直接接入或控制接入模式
→ 首次接入时完成设备注册，取得平台分配的设备编号
→ 按预先配置的安全策略发起连接
   在 TLS/TLCP（如适用）与 MQTT 连接阶段完成相应认证
→ MQTT 连接建立，设备订阅平台下行 Topic
→ DevLogin.c2s / DevLogin.s2c 完成设备登录
→ [设备在线期间按需维护]
   时间同步、设备状态、异常信息和默认计费方案
→ 进入三种启动入口之一
   ├─ 平台远程启动
   │  StartCharge.s2c → StartCharge.c2s → StartChargeResult.c2s
   ├─ 设备发起，平台鉴权
   │  DeviceChargeAuth.c2s → DeviceChargeAuth.s2c
   │  → StartCharge.s2c → StartCharge.c2s → StartChargeResult.c2s
   └─ 设备本地鉴权
      启动阶段不与服务平台交换消息
→ [设备在线且处于充电状态]
   交流或直流充电中数据
→ [平台远程停机]
   StopCharge.s2c → StopCharge.c2s
→ OrderInfoUp.c2s → OrderInfoConfirm.s2c

这张关系图用来说明两个过程怎样衔接，并不是标准定义的一套状态机。为了把业务接入主线表示清楚，图中把“取得设备编号”放在 MQTT 业务连接之前；如果运营商采用 MQTT 在线注册，设备还会先进入一段由运营商定义的注册交互，取得 deviceNo 后再进入图中的业务接入过程。Part 4 允许离线注册，也允许通过 HTTP、HTTPS 或 MQTT 在线注册，但没有规定统一的在线注册接口。

设备首次接入时应完成注册；MQTT 心跳、状态和异常报告发生在设备在线期间；时间同步和默认计费方案则有各自的触发条件。三种启动方式分别代表不同入口，一次充电不需要把它们逐一串行执行。本地鉴权如果发生在离线期间，平台可能直到网络恢复、交易记录补传时，才第一次观察到这次充电。

对于传导式充电设备，标准规定的最小功能集还包括时间同步、异常保障、充电中和非充电中数据等内容。本文用一次充电组织叙述，并不意味着符合性要求可以缩减成一段启停时序；Part 4 涵盖的能量互动、换电、预约和运维等功能，也不在这一讲展开。设备注册、连接和登录，描述的是设备能否继续与平台交互；启动、运行和停止消息，描述的是某次充电。平台若把它们塞进一条从“离线”到“订单完成”的状态机，设备重新登录可能被误写成订单恢复，一笔订单结束也可能反过来改变整台设备的在线状态。

两个过程分开以后，还要确定标准中的“设备”究竟指谁。这个问题会影响设备编号怎样分配、Topic 怎样路由，也会决定 connectorID 在哪个对象下面解释。

二、平台接入的“设备”究竟是哪一个对象

GB/T 44130.4-2025 给出了直接接入和控制接入两种模式。直接接入时，充换电设备与服务平台交换信息；控制接入时，现场设备经过控制单元接入平台，控制单元可以承担消息路由或协议转换。因此，平台面对的接入主体可能是一台物理设备，也可能是控制单元代表的逻辑设备。即便手头的项目采用“一桩一连接”，建模时也不能把这种一对一关系当成所有设备形态的前提。

多接口设备还要看各接口的充放电控制逻辑是否独立。存在控制依赖时，标准要求服务平台在相关接口中确定一个主充电接口，其他接口只能适用监测类功能。附录 V 进一步给出了整机、独立接口和接口集合等示例。第一讲中那台群充设备之所以发生编号冲突，是因为平台丢掉了枪号所属的上级对象；在这套标准里，如果我们忽略接入模式和接口控制关系，同样可能把逻辑接入主体、现场设备和充电接口混成一张表。

接入主体确定以后，设备首次接入服务平台时应完成注册。设备编号由服务平台分配，最长 64 个字符，只要求在所接入的服务平台内唯一。这个编号还会出现在 MQTT Topic 中，因此标准明确规定其中不应包含 / 或 $。

注册可以离线完成，也可以通过 HTTP、HTTPS 或 MQTT 在线完成。在线注册使用什么 URL、请求字段和返回结构，由运营商提供；Part 4 没有定义一套全国统一的在线注册接口。标准还允许运营商提供设备注册码、授权码等附加信息，用于增强登录安全性，但没有把其中任何一项指定为唯一认证凭据。

这一步至少要分开四个名称：

• deviceNo 是服务平台分配的设备编号，在当前接入平台内唯一，并进入 MQTT Topic。

• DevLogin.c2s 中的 devSn 是出厂编号，注册前可作为设备唯一识别码使用。

• Part 5 还定义了“设备编码”（device serial number）。

• 平台内部通常还会为接入主体建立稳定的 protocolEndpointId，并为能够确认的物理设备建立 equipmentInstanceId，再由平台模型维护两者与运营资产之间的关系。

这些值在某个项目里可以恰好使用同一个字符串，语义却不会因此变成同一件事。设备编号由服务平台分配，devSn 来自制造环节，protocolEndpointId 和 equipmentInstanceId 则分别表示平台内部的逻辑协议端点与物理设备实例。我们需要按来源、作用范围和变更历史分别保存，再用明确的关系把它们关联起来。设备编号只要求在所接入的服务平台内唯一，因此身份绑定还要带上服务平台的范围，不能拿一段 deviceNo 在所有环境中直接定位端点或资产。

设备注册关系：(servicePlatformId, deviceNo) → protocolEndpointId
制造信息关系：devSn / 经核实的设备序列信息 → equipmentInstanceId
当前连接关系：(servicePlatformId, deviceNo) → currentConnectionSessionId
接口从属关系：(servicePlatformId, deviceNo, connectorID) → connectorAssetId

这些是平台内部关系，不是国标字段。protocolEndpointId 表示能够按协议认证、连接和收发消息的逻辑主体，equipmentInstanceId 表示带有制造与硬件生命周期的物理设备；控制单元代下级设备接入时，两者尤其不能合并。设备迁移到另一服务平台时，deviceNo 可能变化；设备更换控制部件后，物理实例及制造信息也可能变化；当前连接则会随着断线和重连不断替换。如果只用一列“设备标识”承担全部含义，其中任何一项变化都会影响消息路由、资产管理和历史订单。

设备编号进入 Topic，解决的是消息属于哪个接入主体。当前连接方是否可信，要由 MQTT 连接阶段的认证判断；认证通过以后，设备能否进入后续业务流程，还要等待 DevLogin 的结果。编号、认证和登录前后相接，在平台里却必须分别记录。

三、MQTT 连接成功以后，为什么还要 DevLogin

设备与服务平台之间使用三层 MQTT Topic：

CONFIG | CONTROL | MONITOR
/
C2S | S2C
/
<设备编号>

一级 Topic 表示配置、控制或监测功能；二级表示设备到平台（C2S）或平台到设备（S2C）的方向；第三级是平台分配的设备编号。例如，设备 CN-TAC-EVYB-0511 上送登录消息时，使用的 Topic 是：

CONTROL/C2S/CN-TAC-EVYB-0511

平台不能因为 Topic 最后一段出现了这个编号，就直接更新相应设备的状态。消息到达以后，还要核对该 deviceNo 是否属于当前 MQTT 连接、消息方向是否与 Topic 一致，以及消息中的 connectorID 是否从属于这个接入主体。Topic 是路由信息，不代替身份认证，也不代替对象归属校验。MQTT Client ID 是否与 deviceNo 采用相同取值，同样属于项目配置关系，标准没有把两者定义成同一个字段。

连接认证由 GB/T 44130.5-2025 规定。设备是 MQTT 客户端，服务平台是服务端，双方需要在通信开始前配置安全策略。同一时刻只能使用一种策略；双方使用的策略不一致时，接收方应终止连接。