DLMS协议电表通讯详解：三层模型、HDLC帧与ASN.1编码

简介《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 握手 各类请求帧。提示三层之间不是简单的上下级而是各有各的连接状态。物理层连上了链路层未必连上链路层连上了应用层也未必连上。排查问题时按层往下剥比对着整段报文猜要快得多。层次主要职责典型失败表现物理层打开/关闭端口收发字节完全没反应一个字节都收不到链路层地址校验、帧长校验、CRC、拆包组包收到乱码或收到帧但校验不过应用层数据描述、编码、连接协商、请求应答链路正常但返回错误码或直接拒绝这张表看着简单实战里却非常有用。很多人一上来就抓应用层报文结果发现连 SNRM 都没发出去——问题根本不在应用层。2.3 Client 与 Server谁问谁答的角色分配DLMS 采用的是典型的请求—应答模型没有双方对等聊天这回事。采集器永远是 Client负责发起电表永远是 Server负责响应。方向反了协议就不成立。一次完整的数据通讯严格按六步走步骤做什么关键帧1建立物理层连接初始化端口无底层驱动行为2建立链路层连接Client 发 SNRMServer 回 UA3建立应用层连接协商参数Client 发 AARQServer 回 AARE4数据通讯Client 发请求帧Server 回响应帧5释放链路Client 发 DISCServer 回 UA 或 DM6关闭物理端口无底层驱动行为第三步的协商值得多说一句。应用层连接建立的过程被称为 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 00Server 发出时是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 发RRR0, SSS0Server 回RRR1, SSS0。Client 下次请求时把自己的接收计数加 1、发送计数加 1变成RRR1, SSS1Server 应答时同样各加 1变成RRR2, SSS1。如此往复直到数据传完。一旦某次计数对不上接收方就会认为帧丢了或者重复了。这跟两个人对暗号差不多我说第三次你回收到第三次中间漏了一次马上就能发现。控制字里还有两位要单独说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 里每个数据项都带一个 tagtag 由两部分组成类别和编号。类别分四种可以按这个名字的适用范围有多大来理解——Universal 是全局通用谁都不能改它的含义Application 跟具体应用绑定Private 是厂家自定义Context-specific 则是跟着上下文走同一个 tag 在不同结构里含义可能不同。大括号里每一项后面还能跟 IMPLICIT 或 EXPLICIT。这两个词描述的是子结构跟父结构的关系IMPLICIT 会改掉父结构的 tagEXPLICIT 保留不写默认就是 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编码方式字节序列字节数BER30 08 02 02 12 34 02 02 56 7810AXDR11 12 34 56 785BER 里那两个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. 什么时候该翻这份中文手册几个典型场景与边界这份手册的定位很明确它是一份中文说明面向做电能量数据采集终端的人讲清楚采集端怎么跟使用这套协议族的电表通讯。它不是标准的完整翻译原文档自己也说了只覆盖应用里可能出现的大多数情况。判断要不要用它看两件事就够了。适合翻它的场景第一次接触这套协议需要从整体上搞清楚三层模型怎么协作手上有一堆十六进制报文想知道每一段字节是干什么的要写采集端的通讯模块需要知道建链、请求、断链的完整顺序带新人时想找一份能按图索骥的中文材料。不适合指望它的场景想找某个芯片的寄存器配置——那是硬件手册的事想找某个厂家私有扩展的完整定义——手册明确说了不覆盖全部想直接抄一段代码跑起来——手册给的是帧结构和编码规则不是可编译的实现。手册里最实用的部分其实是那几个请求实例请求电量、请求瞬时量电压、电流、功率、请求负荷曲线、请求时间。这几类请求覆盖了日常采集的绝大部分需求而且每个都给了实际的报文字节。对照着自己抓的包一行行比比看十页抽象描述管用得多。你手上的问题该翻哪部分报文开头那些字节是什么链路层帧格式、地址解析为什么读一半就断了长帧分割、S 位、RR 帧连上了但读不到数据应用层建链、AARQ/AARE 协商结果不知道某个字段什么含义ASN.1 语法定义、数据类型 tag 表报文字节数对不上BER 与 AXDR 编码规则的区别有个习惯我保持了挺久拿到任何一份协议材料先翻到它自己声明没有包含什么的那一段。这份手册开头就写明了不覆盖全部这句话比目录还有用——它提前告诉你哪些问题别在这本书里找答案省得你在目录里来回翻三遍。从那以后我每次接手新的通讯协议都强制先把边界声明和实例章节过一遍再决定要不要深读正文。希望帮到你。本文还有配套的精品资源点击获取