简介这是IEC62056协议族DLMS协议族的中文说明手册面向电能量数据采集终端研发与调试人员解决与DLMS电能表通讯时的协议理解与报文解析问题。手册按三层模型展开物理层负责底层硬件操作与连接建立链路层基于HDLC实现地址校验、CRC校验及长帧拆包组包应用层则深入讲解ASN.1语法、BER与AXDR编码、AARQ/AARE连接帧并完整描述请求电量、瞬时量、负荷曲线、时间等数据的具体流程。此外还提供多个请求数据的实际报文范例便于对照抓包验证。资源为单个doc文档压缩包约620KB结构清晰适合作为现场调试和开发时的速查手册。已有867人学习下载是了解DLMS协议族不可多得的实用中文资料。1. 从“读得懂协议”到“跑得通流程”DLMS中文手册到底解决什么问题做用电信息采集的人几乎都会撞上同一堵墙手里的电能表支持DLMS协议族也就是IEC 62056但当你打开英文原版协议想搞清楚“发什么帧能读到电量”时很快会被ASN.1、BER、AARQ这些词淹没。这份中文版DLMS手册的价值就在于它不追求覆盖全部IEC 62056内容而是把电能量采集终端最常用的场景——建链、读数据、拆链——按实际调试顺序讲透。它适合三类人刚接手采集终端开发的嵌入式工程师、要给电能表做协议适配的测试人员、以及想搞懂手握HDLC数据包里几个关键字节含义的技术支持。这篇笔记会把手册里的三层模型、HDLC帧结构和那几个绕不开的坑拉出来过一遍让你拿到报文就能对照着拆。2. DLMS三层模型与六步通讯流程物理层、链路层、应用层各自管什么2.1 Client-Server结构与三层职责划分DLMS协议族的通讯模型是典型的Client-Server结构。数据请求端称为Client通常是集中器、采集终端这类主站设备数据提供端称为Server是电能表。这个方向不要搞反因为在后面组帧时源地址和目的地址的填充顺序完全取决于你在哪一端。整个协议族分成物理层、链路层、应用层三层每层各管一段事物理层管底层通信硬件的操作包括串口或调制解调器的初始化、打开、关闭、收发原始字节。对嵌入式系统来说这一层通常就是底层驱动和协议交互不多。链路层用HDLC高速链路控制协议负责数据传输的可靠性包括地址校验、帧长校验、CRC校验以及长数据帧的拆包与组包。应用层处理用户真正关心的数据内容比如电量、电压、电流、功率、负荷曲线。应用层的数据帧用ASN.1语法描述用BER编码或AXDR编码落地到字节。2.2 一次完整通讯的六步流程手册里把一次通讯归成六个步骤这个顺序在写状态机时可以直接照搬每一步对应Client端的一个状态建立物理层连接打开物理端口初始化底层硬件。建立链路层连接Client发送SNRM帧Server回UA帧同时协商窗口大小和最大信息域长度。建立应用层连接Client发送AARQ帧做协商请求Server回AARE帧这一步叫Negotiation为后续数据通讯确定配置参数。进行数据通讯Client发数据请求帧Server回数据响应帧。请求不同数据时要带上对应的Class ID和OBIS标识。释放链路数据通讯结束后Client发DISC帧Server回UA或DM帧确认断开。解除物理层连接关闭物理端口从物理上结束通讯。这里有个细节值得注意第5步并不是必须的。手册明确提到一次通讯结束后也可以不发任何帧依靠Server端的超时挂断机制来结束。但工程上我一般建议主动发DISC帧把连接释放干净不然后一次建链时状态机容易出现残留状态。2.3 物理层服务的边界手册对物理层着墨不多理由是物理层服务在嵌入式系统里通常由底层驱动实现不受通讯规约控制。实际开发中确实如此用串口还是用网络PSTN拨号还是载波物理层做的事情不外乎“打开端口-初始化-收数据-发数据-关端口”这么几个原语。但有一个实际项目里的坑值得提醒物理层连接和链路层连接不是一回事。物理层通了比如串口能收到字节不代表链路层就通了。你必须走完SNRM/UA协商才能在应用层发数据。很多初学者在仿真调试时发现电表收到数据却不回帧第一反应是查物理层接线实际上可能是SNRM帧本身组错了Server根本不认为这是有效的建链请求。3. HDLC链路层帧格式、地址扩展编址与帧计数位3.1 HDLC帧格式逐字段拆解链路层是DLMS协议里最“见字节”的部分。无论上层交互什么内容最终在物理介质上跑的都是HDLC帧。一个不包含应用层数据的HDLC帧结构是这样0x7E | 帧类型与帧长(2字节) | 目的地址域 | 源地址域 | 控制域 | 帧校验(FCS) | 0x7E当帧里包含应用层数据时会多出三项0x7E | 帧类型与帧长 | 目的地址域 | 源地址域 | 控制域 | 帧头校验(HCS) | LLC帧头 | 用户数据信息 | 帧校验(FCS) | 0x7E逐字段说明帧类型与帧长字段共两个字节。Frame Type恒为A二进制1010对应手册里的Frame Type 3这是DLMS使用的帧类型。S位是分割位置1表示数据帧被分割在长数据帧传输时会用到。Frame Length Sub-field表示整个帧的长度单位是字节但不包括前后两个0x7E。注意这里算长度时要把帧类型与帧长字段本身也算进去这是新手最容易算错的地方。目的地址域和源地址域组成地址域。对于Client端目的地址是Server地址源地址是Client地址Server端正好相反。控制域负责帧计数和特殊数据帧标识。帧头校验HCS只对帧头部分做CRC校验增强可靠性。不是所有帧都带HCS是否带取决于帧是否包含用户数据信息。帧校验FCS是HDLC的16位CRC校验覆盖从帧类型字段到用户数据的全部内容。3.2 地址域与扩展编址技术地址这块是现场调试经常翻车的地方。HDLC使用扩展编址技术某个地址字节的最低位为0表示地址域还没结束后面还有字节属于同一地址域最低位为1表示地址域到此结束。这个最低位不参与实际地址值它只是“还有没有后续”的标记。Client端的地址永远是1字节最低位固定置1所以理论上只有128个可用地址。Server端的地址结构灵活一些分upper HDLC Address和lower HDLC Address两部分前者表示逻辑地址后者表示物理地址。手册以某型号电能表为例说明它在实践中可行的地址结构是Client端1字节、Server端4字节高位两字节加低位两字节。这个“可行”两个字特别关键。手册提到某些电表在测试中只有四字节Server地址结构可用两字节、一字节都不行。所以做设备适配时地址长度不能想当然按通用规则来必须以实际设备的协议说明或抓包结果为准。解析地址域时要注意字节序处理和终结位的判断下面是一段常见的地址解析逻辑def parse_hdlc_address(raw_bytes): parts [] tmp [] for b in raw_bytes: tmp.append(b 0x7F) # 去掉最低位的终结标记 if b 0x01: # 最低位为1说明地址域结束 parts.append(tmp) tmp [] if tmp: parts.append(tmp) return parts这段代码的逻辑是逐个字节扫描地址域每个字节先把最低位的“继续标记”清掉保留7位有效地址位一旦发现某字节最低位是1就把当前累积的字节收成一个完整的地址段。返回的parts列表里前几个元素是upper地址最后一个是lower地址如果存在的话。实际调试时先用它把你的地址域拆开再和你手里的电表地址配置对照能快速定位是地址填错还是封帧时少收了一个字节。3.3 帧控制字与RRR/SSS计数机制帧控制字是链路层状态机的一个关键状态量。字段结构里RRR是接收帧计数SSS是发送帧计数还有一位P/F标记。帧计数的规则在手册里描述得很具体链路层连接建立之后Client第一次发数据时RRR和SSS都置0Server收到后返回响应RRR置1SSS保持0Client再次请求时RRR和SSS各自加1Server响应时也各自加1。每次通讯两个计数器逐步递增直到数据全部取完。整个数据过程以I帧请求和响应数据取完后Client还要先发RR帧收到Server的确认后再发DISC帧结束链路。这里有个工程上值得注意的点RRR和SSS不是随便累加的它们的初值是建链后的第一个数据帧而不是使用帧的序号本身。实践中遇到“Server不回帧”的报文排查顺序应该是先看SNRM/UA是否正常建链再看控制字里的RRR/SSS是否和上次通讯衔接一致。P/F位的意义Poll bit由Client发送置1表示要求Server回应置0表示不允许回应Final bit由Server发送置1表示一次数据帧发送结束。注意Final bit只有在通讯窗口大于1时才有实际意义。当窗口大小为1时Server返回的每一帧P/F位都置1表示这就是当轮最后的帧。3.4 长数据帧的分割与重组普通数据帧的用户数据信息最大长度默认128字节超过这个长度就必须启动长数据帧链路控制流程。请求负荷曲线时几乎一定会碰到长数据帧。长数据帧传输的机制是发送端把大的数据包分割成多个短帧每个短帧的帧类型与帧长字段中S位置1表示“这是被分割的帧”接收端检测到S位后知道后面还有后续帧继续接收并缓存Client端通过发送RR帧来请求下一个被分割的数据帧。整个过程中接收端按顺序把所有分段重组为一个完整的应用层数据包。实现重组逻辑时一个常见做法是维护一个接收缓冲区收到S位置1的帧时先缓存用户数据等收到S位为0的帧即最后一个分帧后再把缓冲区整体交给应用层解析。当窗口大小为1时每收一个分帧就回一个RR帧请求下一帧直到收到结束帧这个交互节奏在抓包时非常容易识别I帧、RR帧、I帧、RR帧交替出现。4. 建链、参数协商与拆链SNRM/UA/DISC帧逐字节分析4.1 SNRM帧逐字节解读链路层连接建立在物理层之上Client发SNRM帧Server回UA表示建立成功回DM表示链路断开。手册给了一组16进制报文这种原始报文是排障必备的对照样本逐字节拆解如下7e a0 21 00 22 00 23 03 93 0b 14 81 80 12 05 01 80 06 01 80 07 04 00 00 00 01 08 04 00 00 00 07 65 5e 7e对照解释7eHDLC帧标志。a0 21帧类型与帧长。类型为AS位为0帧长度0x21即33字节。00 22 00 23目的地址域共4字节即Server地址。03源地址域Client端地址1字节。93控制字SNRM帧标识。0b 14帧头校验HCS。81 80 12SNRM标识和参数块标识。05 01 80transmit maximum information field length发送最大信息域长度值为128字节。06 01 80receive maximum information field length接收最大信息域长度值为128字节。07 04 00 00 00 01发送窗口大小值为1。08 04 00 00 00 07接收窗口大小注意这里低字节是0x07实际窗口值取决于具体电表配置。65 5e帧校验FCS。7e帧结束标志。这里的重点是0x81 0x80结构它是DLMS链路层参数协商的固定头后面跟着的每个XX YY 数据三元组是“参数标识-参数长度-参数值”。参数标识05/06表示信息域长度07/08表示窗口大小。如果SNRM帧里的用户信息部分可以不出现表示Client直接接受Server端已配置的参数。4.2 UA响应帧与四个协商参数Server收到SNRM后回UA帧携带的参数通常和SNRM中的协商一致。手册给出了对应的UA报文7e a0 21 03 00 22 00 23 73 28 f0 81 80 12 05 01 80 06 01 80 07 04 00 00 00 01 08 04 00 00 00 01 53 3b 7e对照需要特别注意的是源地址和目的地址互换03是源地址Server的地址00 22 00 23变成了目的地址Client的地址。控制字73表示UA帧。信息域同SNRM一样携带四个参数。当UA帧中这些参数与SNRM不一致时最终以UA帧为准Client后续组帧必须按UA返回的窗口和长度来发。这四个参数中MAXIMUM_INFORMATION_FIELD_LENGTH和WINDOW_SIZE是最容易踩坑的两个。默认值分别是128字节和1但某些电表会把窗口调大比如窗口为4允许连续发4帧再等待确认。你的状态机如果写死“发一帧等一个响应”在这种配置下就会等不到预期的逐帧响应。4.3 DISC拆链与DM响应建链之后的拆链比建链简单因为不需要携带参数。Client发DISC帧Server回UA表示正常断开回DM表示Server在此之前已经处于断开状态。手册给出了两组报文S: 7e a0 0a 00 22 00 23 03 53 06 c7 7e R: 7e a0 0a 03 00 22 00 23 1f 43 4c 7ea0 0a表示帧长10字节控制字53是DISC1f是DM。这里可以看到拆链帧的长度比建链帧短很多因为不需要信息域。工程上可以把这个特点用起来抓包时只要看到“短帧控制字53”就能快速判断这是一次拆链。5. 避坑DLMS联调中常见的五个坑5.1 帧头校验算错导致Server不回帧现象SNRM帧发出后终端一直等不到UA响应抓包看电表侧也没有回帧。原因SNRM帧带有HCS帧头校验帧头范围是从帧类型与帧长字段开始到控制域结束。很多人在实现时习惯只做FCS帧校验忽略了HCS或者HCS的计算范围不对。解决把HCS计算范围限定在“帧类型与帧长字段目的地址域源地址域控制域”并在CRC计算前确认使用的多项式是HDLC的16位CRC。建议用英文标准附录A里给出的参考实现先跑一遍拿手册里的报文做向量验证CRC计算结果对不上就别继续往下调。5.2 地址字节最低位方向搞反现象明明把地址配成4字节抓包看Server端一直没有响应。原因扩展编址时每个地址字节的最低位是“是否结束”的标记不是地址值本身。有些人在组装地址时把地址当成普通大端数据直接填进去忘了置最低位为1导致Server把地址域解析成“后面还有更多字节”整个帧结构就乱了。解决无论地址值是几字节组装时每一字节都要先左移一位再给最后一个字节的最低位或上0x01。反过来说解析地址时每个字节要右移一位恢复原始地址值。这个“先移位再或1”的逻辑最好封装成独立的函数建链和拆链都走同一个入口。5.3 帧计数位不配对现象数据通讯过程中某一次请求后Server返回FRMR帧或者干脆不回。原因RRR/SSS计数在Client和Server端是独立维护的但双方期望的值必须匹配。如果你在发AARQ时把RRR置成0、SSS置成0Server响应后RRR变1下一次发数据请求时对端期望你的RRR是1、SSS是1如果程序里没有累加这组计数值对端会认为帧失序。解决把RRR/SSS作为链路状态结构体的一部分维护每次收到帧时用帧里的RRR/SSS更新本地状态发送时再代入。断链重连后计数器要复位归0不能接着上次的计数继续加。5.4 长数据帧的S位与RR帧配合出错现象请求负荷曲线时收到的数据不完整应用层解析总是失败。原因长数据帧被分割后S位为1的帧后面还有后续帧接收端必须等S位为0的帧出现才算结束。有些实现把每个分割帧直接交给应用层解析导致应用层拿到半个ASN.1结构解析必然失败。解决在链路层做重组。收到S位为1的帧时把用户数据追加到缓冲区并回RR帧请求下一块收到S位为0的帧时追加后再把完整缓冲区向上提交。窗口大于1时RR帧的触发时机要按窗口大小批量处理不能每收一帧就机械回一个。5.5 AARQ被误当成数据请求帧处理现象链路层建链正常SNRM/UA都对但AARQ发出后Server端不回AARE。原因把AARQ和应用层数据请求帧混为一谈。链路层建链之后应用层还有一个独立的协商过程。AARQ里有protocol-version、application-context-name等字段其中application-context-name是OBJ ID形式和后续请求电量的Class ID/OBIS完全不同。如果状态机在链路建链后直接跳到“请求数据”状态AARQ就会被错误组装或错误发送。解决状态机必须严格区分“链路层已连”和“应用层已连”两个状态。链路建链成功只代表可以发AARQ了AARE收到并校验通过后才能发数据请求帧。抓包时看到帧结构符合HDLC但不是预期的数据请求优先检查是不是AARQ/AARE状态没走完。6. 把AARQ/AARE和数据请求实例串起来ASN.1、BER与AXDR编码再核对一遍6.1 ASN.1在DLMS里的实际角色应用层的数据帧描述全部用ASN.1语法。比如Get-Request-Normal这个请求电量时常用的数据结构定义如下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 }这里SEQUENCE表示数据帧内容是顺序排列的OPTIONAL表示该数据项可以省略。如果省略了access-selection-parameters请求的就是整个对象如果要带条件比如只读某段时间的负荷曲线就要把参数带上。注意GET-Request本身用了CHOICE类型标明当前帧是从Normal、Next、With-List三选一向电表请求数据时必须对应上。6.2 BER编码与AXDR编码的取舍BER编码每个数据元素都带“标识-长度-内容”三重信息解析时灵活但冗余。AXDR编码是XDR的扩展序列标识后面直接排数据值编码紧凑、效率高。DLMS中AARQ/AARE部分用BER绝大多数应用层数据通讯用AXDR。两种编码都要掌握因为你要读的文件可能是任一种。判断方法很简单看帧里是否存在成对的类型标识和长度前缀存在就是BER纯数值连续排布就是AXDR。6.3 用AARE帧做一次完整验证拿到一份AARE响应帧可以从“找61”入手快速验证解码61 //AARE应用层标签APPLICATION 1 42 //长度 A1 09 06 07 60 85 74 05 08 01 01 //COSEM应用上下文名 A2 03 02 01 00 //关联结果00表示接受 A3 05 A1 03 02 01 00 //结果来源诊断 88 02 07 80 //接收端ACSE需求 89 07 60 85 74 05 08 02 01 AA //机制名 8A 80 08 41 42 43 44 45 46 47 48 //认证信息 BE 04 0E ... //用户信息XDLMS部分从这里开始其中60 85 74 05 08 01 01就是应用上下文名是一个OID编码代表DLMS/COSEM标准上下文两点含义一是确认Server支持的标准版本二是AARE后面跟的用户数据将用AXDR编码解析。最后收尾时把这份AARE里拆出来的参数版本号、上下文名、协商结果做成打印日志每次联调先核对这三项能过滤掉大量后端盲目解析的无效工作。实际调试中我习惯了这种做法把协议手册里的每一组16进制报文做成测试向量放在自动化测试里跑一遍CRC、地址、帧计数对不上就亮红牌。从那以后我再也没在“刚调通了串口又被协议细节干翻”的状态里浪费时间。希望这份手把手的DLMS链路层解析笔记帮你在自己的采集终端项目上少走几程弯路。本文还有配套的精品资源点击获取