简介：《DMLS协议中文版》是一份面向电能量数据采集终端开发者、电能表通讯调试人员及IEC62056/DLMS协议学习者的中文说明手册，主要用于解决采集器与电能表按DLMS协议族通讯时的协议理解、报文对照和调试参考问题。压缩包内共1个doc文件，约620KB，内容按协议三层模型组织，依次讲解物理层、HDLC链路层与应用层，并展开ASN.1语法、BER与AXDR编码、AARQ/AARE数据帧以及数据请求过程。文档还给出请求电量、瞬时量（电压、电流、功率）、负荷曲线和请求时间等实例数据包，便于读者对照字段理解帧结构与通讯流程。已有873人学习下载，适合需要查阅中文协议说明、梳理分层关系或排查报文问题的技术人员使用。

1. 一句话说清 DLMS 协议：电表和采集器之间怎么"对上话"

想象你家水表要和物业的采集终端聊天，一个说方言，一个说普通话，中间还隔着一条信号不太好的老电话线。DLMS 协议（不少资料里也写成 DMLS 协议）就是这套对话的普通话教材：它规定了电表和数据采集终端按什么顺序打招呼、怎么自报家门、怎么把一度电的数据原封不动送到对面。

说得正式一点，DLMS 是一套面向电能计量的通讯协议族，从下往上叠了三层——物理层、链路层、应用层，通讯双方的角色是固定的：主动问话的采集器叫 Client，被动应答的电表叫 Server。

它存在的理由很朴素：让不同厂家造出来的表，能被同一台采集设备读懂。搞懂它，你再看7e ... 7e这种十六进制报文就不会发懵，也能在一次读表失败时判断出来：到底是链路没连上，还是应用层参数压根没谈拢。

2. 为什么要有 DLMS：一块电表背后的三层楼分工

2.1 从"抄表"这件小事说起：为什么不能各说各话

在没有统一协议的年代，采集设备厂商最头疼的事不是算法，而是驱动。甲厂的表用一套帧格式，乙厂的表换一套，丙厂连校验算法都自己改了一版。每接一个新表型，采集终端里就多一份解析代码；每换一次表，现场就得升级一次固件。这种日子过久了，行业里自然会有人想做一件"标准化"的事。

DLMS 的思路是：把"说什么"和"怎么送"彻底拆开。上层的应用层只管定义数据的含义——这是一度电、这是一个电压值、这是一条负荷曲线；下面两层不管内容是什么，只负责把它安全送到。这样一来，底层换成串口、电话线还是载波，应用层那套描述数据结构的语法一个字都不用改。

打个比方，这就像快递行业的面单标准。面单上写什么（收件人、地址、物品）、怎么贴在箱子上、箱子怎么装车，是三件不同的事。标准化之后，任何一家快递公司都能处理任何一个人寄出的箱子，不需要提前认识对方。

这套拆分带来的直接好处很实际。采集终端厂商写一份应用层代码，就能适配多种物理介质；电表厂商只要遵守同一套数据模型，就不必为每个采集终端单独定制。对现场调试的人来说，同一个报文解析工具能在不同厂家的表上通用，省下的时间相当可观。

当然，拆分也有代价——理解门槛变高了。一个"读电量"的请求，在物理层是几个字节的收发，在链路层要建连接、对帧计数、做 CRC 校验，到了应用层还要先建立应用层连接、再按 ASN.1 描述组装请求。第一次接触这套协议的人，最容易在这里翻车：只盯着应用层报文看，却不知道底下链路压根没建起来。

2.2 三层模型：物理层、链路层、应用层各管什么

物理层躺在最底下，干的是最脏最累的活：打开端口、初始化端口、收发字节、关闭端口。对嵌入式设备来说，这一层通常对应芯片厂商提供的底层驱动，不归通讯协议管。所以很多讲 DLMS 的资料会把物理层一笔带过——不是它不重要，而是它太依赖具体硬件，写进协议里也没法通用。

链路层是承重墙。它的全部职责可以用一句话概括：把一串字节可靠地送过去，送错了要能发现，送长了要能拆开。具体来说，地址要校验（防止发给别的表）、帧长要校验（防止收到半截帧）、数据要做 CRC 校验（防止传输过程中翻转了几个 bit）、超长数据要拆包组包。DLMS 在这一层用的是 HDLC 协议，后面单独用一章讲。

应用层负责"内容"。它要解决三个问题：数据怎么描述（用 ASN.1 这种抽象语法）、描述怎么变成字节（用 BER 和 AXDR 两种编码）、请求怎么发起和应答（AARQ/AARE 握手 + 各类请求帧）。

提示：三层之间不是简单的上下级，而是各有各的连接状态。物理层连上了，链路层未必连上；链路层连上了，应用层也未必连上。排查问题时按层往下剥，比对着整段报文猜要快得多。

这张表看着简单，实战里却非常有用。很多人一上来就抓应用层报文，结果发现连 SNRM 都没发出去——问题根本不在应用层。

2.3 Client 与 Server：谁问谁答的角色分配

DLMS 采用的是典型的请求—应答模型，没有"双方对等聊天"这回事。采集器永远是 Client，负责发起；电表永远是 Server，负责响应。方向反了，协议就不成立。

一次完整的数据通讯，严格按六步走：

第三步的"协商"值得多说一句。应用层连接建立的过程被称为 Negotiation，本质是双方交换配置参数：最大能收多大的数据包、支持哪些功能、协议版本是多少。这些参数谈不拢，后面发什么请求都是白搭。

第五步有个容易忽略的细节：数据请求结束后，不能直接甩一个 DISC 过去。标准做法是先发一个 RR 帧（准备接收帧），收到对方确认后，才能发 DISC 断开。当然也可以什么都不发，靠 Server 端的超时挂断机制自然结束——但原文明确建议用前一种，因为超时挂断会让电表在一段时间内拒绝新的连接请求，遇到密集采集任务时很容易踩坑。

3. 链路层怎么保证不丢包：HDLC 的帧、地址和帧计数

3.1 一帧数据的真实长相：两个 0x7e 之间装了什么

HDLC 帧的边界非常好认：一头一尾各一个0x7e。两个0x7e中间夹着的，就是这一帧的全部内容，长度由帧头里的帧长字段说明。

一段典型的建链请求帧长这样：

# Client 发给 Server 的 SNRM 帧，用于建立链路层连接 raw = bytes.fromhex( "7e" # 帧头，固定值 "a0 21" # 帧类型 A(1010) + S 位(0) + 帧长 0x021 "00 22 00 23" # 目的地址域：Server 地址，扩展编址占 4 字节 "03" # 源地址域：Client 地址，恒为 1 字节 "93" # 控制字：SNRM 是无编号帧，这里是固定编码 "0b 14" # 帧头校验 HCS，只覆盖前面这段帧头 "81 80 12 05 01 80 06 01 80" # 信息域：参数块开头 "07 04 00 00 00 01 08 04 00 00 00 01" # 信息域：两个窗口大小参数 "65 5e" # 帧校验 FCS，覆盖整个帧体 "7e" # 帧尾，固定值 .replace(" ", "") ) print(len(raw)) # 35：首尾各 1 字节 0x7e，中间帧体 33 字节 print(hex(raw[1] << 8 | raw[2])) # 0xa021：帧类型与帧长合成的一个字段 print(raw[3:7].hex(" ")) # 00 22 00 23：目的地址域 print(raw[7]) # 3：源地址域 print(raw[8]) # 147：控制字

先说帧类型与帧长这个字段，它正好占两个字节。最高 4 位恒为1010（也就是十六进制的 A），这是 DLMS 固定使用的帧类型编号；紧接着的 1 位是 S 位，标记这一帧是不是被分割过；剩下的 11 位是帧长，单位是字节，统计范围不包括首尾那两个0x7e。上面这个例子算出 0x021，也就是 33 字节，加上两个0x7e正好 35。

再说校验。这帧里出现了两次校验：0b 14是帧头校验，只保护帧头那一段；65 5e是帧校验，保护整个帧体。为什么要多一道？因为帧头里装着地址和长度，一旦帧头被干扰错了，后面所有的解析都会跟着错位，光靠帧尾校验发现得太晚。多加一道帧头校验，相当于给信封上的收件人地址单独贴了个防拆封条。

信息域里装的是应用层数据。注意区分两种帧：不含应用层数据的帧，信息域是空的；含应用层数据的帧，信息域前面还要多三个字节的 LLC 帧头——Client 发出时是e6 e6 00，Server 发出时是e6 e7 00。LLC 子层本身不做任何处理，只负责把数据从链路层转交给应用层，所以这三个字节更像是一个"标记来源"的标签，而不是什么功能字段。

3.2 地址域与扩展编址：物理地址和逻辑地址怎么叠

地址域是链路层最容易看走眼的地方，因为它长度不固定。

HDLC 用的是扩展编址技术：每个地址字节的最低位是一个"是否结束"的标志。最低位为 0，说明这个地址还没写完，后面还有字节；最低位为 1，说明地址到此结束。

拿上面那帧的00 22 00 23举例。前三个字节的最低位都是 0，只有最后一个字节0x23的最低位是 1，所以这四个字节合起来才是一个完整的 Server 地址。如果只看前两个字节就去匹配表号，永远对不上。

Client 端的地址永远只有一个字节，因为它的最低位必须置 1 表示结束。一个字节去掉最低位，剩下 7 位能表示 128 个地址，这个数量对采集器来说够用了。

Server 端就复杂一些。它把地址拆成两截：upper 表示逻辑地址，lower 表示物理地址。逻辑地址总是存在，物理地址在确认不需要的时候可以省略。这样设计的好处是，一块物理电表里可以挂多个逻辑设备，每个逻辑设备有自己的逻辑地址，采集端按逻辑地址访问不同的数据集。

常见的 Server 地址结构有三种：一字节（只有逻辑地址）、两字节（逻辑地址一字节 + 物理地址一字节）、四字节（逻辑和物理各两字节）。理论上还能更长，但实践中有上限。有些现场设备实测下来只认四字节结构，这时候用一字节地址去连，发多少帧都没人理你。反过来也成立，调试时先用最短的结构试探，不通再逐级加长，是比较省时间的做法。

另外还有一批保留地址，其中最重要的是广播地址——发给所有表，谁收到谁处理。这类地址在做校时、广播拉闸之类的批量操作时会用到。

3.3 帧计数与 P/F 位：每帧都要"对暗号"

链路层建好之后，每一帧 I 帧（信息传输帧）的控制字里都带着两个 3 位的计数器：接收帧计数和发送帧计数。这两个数字不是随便填的，双方靠它确认"你收到的是我第几次发的"。

规则很朴素。建链后的第一次请求，两个计数都从 0 开始：Client 发RRR=0, SSS=0，Server 回RRR=1, SSS=0。Client 下次请求时把自己的接收计数加 1、发送计数加 1，变成RRR=1, SSS=1；Server 应答时同样各加 1，变成RRR=2, SSS=1。如此往复，直到数据传完。

一旦某次计数对不上，接收方就会认为帧丢了或者重复了。这跟两个人对暗号差不多：我说"第三次"，你回"收到第三次"，中间漏了一次马上就能发现。

控制字里还有两位要单独说：P 位和 F 位。P 位由 Client 发，置 1 表示要求 Server 回应，置 0 表示不要求回应；F 位由 Server 发，置 1 表示这一轮发送结束了，置 0 表示后面还有。F 位只有在通讯窗口大于 1 的时候才有意义——窗口等于 1 时，Server 每帧都是单独回应，F 位自然总是 1。

这就引出了窗口大小这个参数。它描述的是双方一次能连续发几帧。默认值是 1，也就是严格的一问一答。窗口开大了，吞吐量能上去，但对端的处理能力跟不上时反而容易丢帧，属于典型的"调参数翻车现场"。

3.4 长帧分割：S 位和 128 字节的天花板

链路层默认一个帧里的用户数据最多 128 字节。这个数字在 SNRM 帧里可以协商，但要改大得双方都支持，实际部署中很少动它。

128 字节够不够？读一个电量值绰绰有余，读一条负荷曲线就完全不够了。负荷曲线是连续记录的一串数据，动辄几百字节，必然超限。

解决办法是把长帧切开。切开的每一个短帧，帧类型与帧长字段里的 S 位都置 1，接收端看到这一位，就知道"后面还有"。接收方通过发 RR 帧来请求剩下的部分，一帧一帧把整包数据凑齐，再交给应用层。

这个过程类似把一本书拆成几个信封寄出去，每封信上标个"第几封，共几封"。收信人只要能按顺序拼回去，内容和一次性寄过来是一样的。麻烦的地方在于，只要中间任何一封信丢了，整本书就得重来或者补寄，所以长帧传输对链路的稳定性要求更高。

注意：读负荷曲线时几乎必然触发长帧流程。如果调试时发现只收到了前 128 字节就没了下文，先检查自己有没有正确地发 RR 帧去要后续数据，而不是怀疑电表没响应。

4. 应用层怎么描述数据：ASN.1、BER 与 AXDR 的三层关系

4.1 ASN.1 是语法，不是编码

第一次看到 ASN.1 的人，很容易把它当成某种编码格式。其实它只是"描述结构"的语言，一个纯粹的语法约定，本身不产生任何字节。

它长这样：

Get-Request-Normal ::= SEQUENCE { invoke-id-and-priority Invoke-Id-And-Priority, cosem-attribute-descriptor Cosem-Attribute-Descriptor, access-selection-parameters Selective-Access-Descriptor OPTIONAL }

读法是：这个叫 Get-Request-Normal 的数据帧，由三项按顺序组成，最后一项是可选的。每一项又可以指向另一个结构定义，层层嵌套下去，直到最底层的整数、字符串这些简单类型。

为什么不直接画张表格，规定第 1 到 3 字节是什么、第 4 字节是什么？因为表格描述不了一层套一层的结构。DLMS 的报文嵌套很深——一个请求里套一个属性描述符，属性描述符里再套对象标识，对象标识里再套数字。用表格写清楚这种嵌套，画出来的图能铺满一面墙；换成语法描述，十几行就说明白了，而且改一个字段不用重画整张表。

ASN.1 里每个数据项都带一个 tag，tag 由两部分组成：类别和编号。类别分四种，可以按"这个名字的适用范围有多大"来理解——Universal 是全局通用，谁都不能改它的含义；Application 跟具体应用绑定；Private 是厂家自定义；Context-specific 则是"跟着上下文走"，同一个 tag 在不同结构里含义可能不同。

大括号里每一项后面还能跟 IMPLICIT 或 EXPLICIT。这两个词描述的是子结构跟父结构的关系：IMPLICIT 会改掉父结构的 tag，EXPLICIT 保留，不写默认就是 EXPLICIT。

至于 SEQUENCE 和 CHOICE，前者表示内容按顺序排列，后者表示从几个选项里挑一个填。这两种复合类型撑起了整个协议的结构描述。

4.2 BER 编码：标签、长度、内容三段式

语法定好了，得变成字节才能发出去。DLMS 里用 ASN.1 描述的那部分，用 BER 编码实现。

BER 的结构极其规整：数据标识、数据长度、数据内容，三段依次排开，内容部分还能再嵌一层同样的三段式。数据标识本身是一个 16 位的位串，拆开来看：最高 2 位是类别（正好对应 ASN.1 里那四种），第 3 位标记这是简单类型还是复合类型，剩下 13 位放长度。

看一段实际的 AARE 帧编码就明白了：

61 AARE 的 tag，对应 [APPLICATION 1] 42 AARE 整体长度 A1 应用上下文名称这个字段的 tag 09 该字段长度 06 OBJECT IDENTIFIER 类型的 tag 07 该字段长度 60 85 74 05 08 01 01 内容：一段对象标识 A2 协商结果字段的 tag 03 02 01 00 长度和内容 A3 诊断信息字段的 tag 05 A1 03 02 01 00

一层套一层，每一层都自带"我是什么、我多长"，接收方照着读就行，不需要提前知道对方会发什么。这种自描述特性是 BER 最大的优点，也是它最大的缺点——每个字段都要额外花两三个字节说明自己和自己的长度，报文一大，冗余就上去了。

4.3 AXDR 编码：把冗余砍掉的紧凑写法

DLMS 里还有另一套编码，叫 AXDR，用在 XDLMS 上。它对 XDR 做了扩展，思路上跟 BER 相反：靠双方预先约定好的结构，把"我是什么、我多长"这些说明全省掉，只留值本身。

用两个整数对比最直观。假设要编码 0x1234 和 0x5678：

BER 里那两个02是在说"我是整数"，两个02是在说"我占两字节"，序列本身还有30和08标明结构和总长。AXDR 只留了一个序列标记11，后面直接铺上两个值，长度信息完全依赖事先知道结构。

打个比方，BER 像每件行李都挂着详细标签，写清楚物品类别、重量、归属；AXDR 像按清单顺序装箱，第几格放什么早就说好了，箱子上什么都不用写。前者到哪都能拆，后者只有拿到清单的人才会拆。

这也解释了为什么 DLMS 和 XDLMS 用两套编码分工：AARQ 和 AARE 这两个建链帧只有一部分内容用 DLMS，其余绝大多数应用层数据通讯都走 XDLMS。日常读表时你抓到的报文，绝大部分是 AXDR 编码的，BER 编码基本只在握手阶段露脸。

4.4 AARQ 与 AARE：应用层连接的握手礼

链路层连上之后，还不能立刻读数据，中间还差一步应用层连接。这一步由 Client 发 AARQ、Server 回 AARE 完成。

AARQ 里装的是"我想怎么谈"：协议版本、应用上下文名称、我支持哪些功能、我最大能收多大的包。AARE 里装的是"我同意哪些、不同意哪些"，以及协商结果。这个过程被称为 Negotiation，字面意思是协商，实际就是双方交换配置。

为什么非得有这么一步？因为链路层只保证字节送到了，但双方对"一包数据最大多少""哪些功能可用"还没有共识。不先谈好，后面 Server 收到一个超出自己处理能力的请求，只能直接拒绝，白白浪费一次往返。

AARE 里有个字段值得留意：协商结果。它明确告诉 Client 这次连接是成功了还是被拒了。调试时如果链路层一切正常（SNRM 有 UA 回应，帧计数也对得上），但业务数据一直读不到，先去看看 AARE 里的这个结果字段——很多"连上了却读不出数据"的情况，根子在这一步就谈崩了。

连接建好之后，读什么数据靠两个标识定位：class id 说明这是哪一类对象（比如寄存器、曲线、时钟），OBIS 说明具体是哪一个量（比如有功总电量、A 相电压）。两个标识组合起来，才能唯一确定一个数据点。这也解释了为什么不同类型的请求帧格式差不多，但 class id 和 OBIS 完全不同。

5. 常见误区与易混概念：这几个词最容易搅在一起

5.1 DLMS 和 XDLMS 不是两套并行的协议

易混点：看到文档里一会儿说 DLMS，一会儿说 XDLMS，直觉上会认为这是两个互相独立的协议族，各管各的。

为什么混：名字上只差一个字母 X，而且两者确实用着不同的编码方式，看起来像是两套东西。更麻烦的是，同一个报文里可能前半段是 DLMS，后半段就切到 XDLMS 了。

怎么区分：把它们理解成"同一套协议的两个部分"更准确。用 ASN.1 描述、BER 编码的那部分叫 DLMS，主要出现在 AARQ 和 AARE 这两个建链帧里；用 ASN.1 描述、AXDR 编码的那部分叫 XDLMS，承担几乎所有实际的数据通讯。也就是说，一次完整的读表过程，开头几步走的是 DLMS，真正读数据时走的是 XDLMS，两者是接力关系，不是二选一。

判断依据也很直接：看编码。报文里到处是"标签 + 长度 + 值"的三段式，多半是 BER，属于 DLMS；报文紧凑、字段直接铺开、靠预先约定的结构解析，那是 AXDR，属于 XDLMS。

5.2 ASN.1 不等于某种编码格式

易混点：把 ASN.1 当成和 BER、AXDR 并列的第三种编码方式，认为三者随便挑一个用。

为什么混：这三者在文档里总是挨着出现，讲完 ASN.1 紧接着就讲 BER 和 AXDR，很容易被读成同一层级的东西。

怎么区分：ASN.1 是语法层面的描述，回答"这个结构由哪些字段组成、每个字段是什么类型"；BER 和 AXDR 是编码层面的实现，回答"这些字段怎么变成字节"。前者是图纸，后者是施工方式。同一张图纸可以用两种施工方式盖出来，这就是为什么同一份 ASN.1 定义能对应两套编码。

实际影响在于排查思路。如果报文结构解析不出来，先看 ASN.1 定义有没有理解错（字段顺序、可选字段在不在）；如果结构对了但字节对不上，那是编码方式搞错了，该用 AXDR 解析的地方拿着 BER 的规则去套，怎么套都不对。

5.3 链路层连上了不等于能读数据

易混点：SNRM 发出去了、UA 也收到了，就认为通讯已经通了，直接开始发读数据请求。

为什么混：链路层建链的成功反馈太明显了——有明确的 UA 回应帧，帧计数也对得上，给人一种"已经连上了"的错觉。

怎么区分：建链有两层，链路层和应用层各建一次。链路层的 SNRM/UA 只证明"两边的物理通道和帧格式对上了"，应用层的 AARQ/AARE 才证明"两边对数据格式和功能范围达成了一致"。少了后面这一步，Server 收到读数据请求会直接丢弃或者返回错误。

排查顺序建议固定下来：先确认 SNRM 有 UA 回应，再确认 AARQ 有 AARE 回应且协商结果是成功，最后才看数据请求。跳过中间任何一步，都会让你在错误的方向上耗费大量时间。

5.4 物理地址不等于表号

易混点：把 Server 的 lower 地址当成电表编号，或者把 upper 地址当成设备唯一标识。

为什么混：两者都是数字，都能在文档里被称作"地址"，而且实际配置时确实要填一个数字进去。

怎么区分：Server 地址是两层叠起来的，upper 是逻辑地址，lower 是物理地址。逻辑地址标识的是一组数据集，物理地址才更接近"这块表本身"。一字节地址结构里只有逻辑地址，压根没有物理地址；四字节结构里两个都有，各占两字节。

更实际的一点是，扩展编址会把多个字节拼成一个地址。看到00 22 00 23这样的序列，不能拆开当成四个独立的地址看，只有最低位为 1 的那个字节才是地址的结尾。判断错结束位置，后面所有字段的偏移全都会错位，解析出来的东西自然全是乱的。

5.5 帧计数和 invoke-id 不是一回事

易混点：看到链路层控制字里有收发计数，应用层请求帧里又有个 invoke-id，觉得这是同一个东西在两层的不同叫法。

为什么混：两者都是递增的序号，都用来匹配请求和响应，功能描述听起来高度重合。

怎么区分：帧计数归链路层管，作用域是"这一条链路"，用来发现帧级别的丢失和重复，一旦链路断开重连，计数就重置了。invoke-id 归应用层管，作用域是"这一次请求"，用来把响应和对应的请求配对，即使中间穿插了别的请求也不会搞混。

层次不同带来的直接影响是：帧计数对不上，说明链路层出了问题，得回去查 CRC 和重传；invoke-id 对不上，说明应用层出了问题，可能是并发请求处理错了，也可能是响应被丢弃后重发了。找错层次，等于找错了科室。

6. 什么时候该翻这份中文手册：几个典型场景与边界

这份手册的定位很明确：它是一份中文说明，面向做电能量数据采集终端的人，讲清楚采集端怎么跟使用这套协议族的电表通讯。它不是标准的完整翻译，原文档自己也说了，只覆盖应用里可能出现的大多数情况。

判断要不要用它，看两件事就够了。

适合翻它的场景：第一次接触这套协议，需要从整体上搞清楚三层模型怎么协作；手上有一堆十六进制报文，想知道每一段字节是干什么的；要写采集端的通讯模块，需要知道建链、请求、断链的完整顺序；带新人时想找一份能按图索骥的中文材料。

不适合指望它的场景：想找某个芯片的寄存器配置——那是硬件手册的事；想找某个厂家私有扩展的完整定义——手册明确说了不覆盖全部；想直接抄一段代码跑起来——手册给的是帧结构和编码规则，不是可编译的实现。

手册里最实用的部分，其实是那几个请求实例：请求电量、请求瞬时量（电压、电流、功率）、请求负荷曲线、请求时间。这几类请求覆盖了日常采集的绝大部分需求，而且每个都给了实际的报文字节。对照着自己抓的包一行行比，比看十页抽象描述管用得多。

有个习惯我保持了挺久：拿到任何一份协议材料，先翻到它自己声明"没有包含什么"的那一段。这份手册开头就写明了不覆盖全部，这句话比目录还有用——它提前告诉你哪些问题别在这本书里找答案，省得你在目录里来回翻三遍。从那以后我每次接手新的通讯协议，都强制先把"边界声明"和"实例章节"过一遍，再决定要不要深读正文。希望帮到你。

本文还有配套的精品资源，点击获取