简介：这是面向电力行业电能量数据采集终端开发者的 DMLS（即 DLMS，IEC62056 协议族）中文协议说明手册，旨在为采集终端与 DMLS 协议族电能表的通讯提供协议理解与实现参考。资源包约 620KB，共 1 个 doc 文档，内容系统覆盖 DMLS 协议模型、物理层协议、链路层 HDLC 通讯机制、应用层协议、ASN.1 语法、BER 编码与 AXDR 编码、AARQ/AARE 连接建立数据帧以及数据请求过程描述，并给出请求电量、请求瞬时量（电压/电流/功率）、请求负荷曲线、请求时间等实际请求范例的数据包格式。相比零散英文标准，这份中文版按采集器（Client）与电表（Server）的交互流程梳理了从物理层连接到数据通讯结束的完整过程，便于研发或调试人员快速建立整体认知。目前已有 866 人浏览学习，适合电能表通讯协议栈开发、电能量采集终端联调及电力自动化运维人员作为参考。
1. DMLS协议是什么：一个拼写混乱背后的智能电表数据规范
先声明一个多数人都会踩的坑：你在搜索引擎里输入“DMLS协议”，十条结果里八条是DLMS，DLMS/COSEM，Device Language Message Specification，设备语言报文规范。DMLS是在微信群、采购单和产品规格书里流传最广的笔误，但大家真正想找的，就是智能电表、充电桩、分布式光伏采集器用来与主站通信的那套协议。它解决的从来不是“怎么把报文编出来”，而是“两台设备如何建立可信会话，安全地读出电能量、电压、状态等对象”。
这个方向适合谁？如果你正打算把自己的物联网网关、电力采集终端或测试工具接入电网主站，或者需要读懂一份DDL（设备描述文件），那么DMLS协议的中文版资料就是你绕不开的垫脚石。接下来我按自己落地的顺序，从分层模型到仿真联调，最后回踩五个最容易翻车的细节，把这条路走通给你看。
2. 协议分层与对象模型：读懂DMLS最需要攻克的四个概念
2.1 从物理层到应用层：DMLS协议栈里各层的职责
第一次看DLMS规范的人，容易直接翻到“帧格式”然后一头雾水。正确的打开方式是先承认它是一个协议栈，而不是一个单层协议。物理层上，它既能跑串口（常见的是IEC 62056-21），也能跑TCP/IP（用IEC 62056-47中的Wrapper帧），还能跑PLC、无线电等介质。数据链路层，绝大多数有线场景用HDLC，负责帧同步、地址透明传输和差错校验。再往上还有传输层和应用层，应用层用xDLMS APDU表达“读、写、调用”三种动作，并使用ASN.1 BER编码。
为什么要分这么多层？因为一个用电信息采集项目里，主站可能在机房通过TCP访问远方的集中器，而集中器又通过RS-485把多块电表挂在一根总线上。物理介质变了，业务动作不能变。分层之后，“读正向有功电量”这个应用动作，无论在串口还是TCP下，报文的业务语义是一致的，变的只是链路层的封装方式。
这个思路时刻提醒我：排查DMLS协议问题时，先看它是物理层、链路层还在应用层。同样是“连不上”，TCP握手不通、HDLC地址不匹配、AARQ的认证参数不匹配，三者的解决手段完全不同。
2.2 对象模型：为什么DMLS不叫“报文格式”而叫“对象”
DMLS/DLMS最劝退新人的概念是“对象模型”。传统Modbus是按寄存器地址读数据，地址表塞在文档里，双方约定好就行。DLMS不这么干，它把电表里的每个可访问点定义成一个COSEM对象，对象用OBIS代码标识，通过类ID和属性索引来区分同一对象的不同数据。
一个计量对象的完整地址形如“1-0:1.8.0.255”。其中“1-0”是逻辑设备与通道，可以简单理解为供电回路；“1.8.0”是量测类型，表示正向有功电能累计值；最后的“255”表示它是默认存储版本。你在电表里看到的一长串数字，并不是随意的寄存器地址，而是一套有规律的语义编码。
属性索引也很关键。设备铭牌对象“0-0:0.0.0.0.255”的属性和“1-0:1.8.0.255”的属性完全不同。前者第一属性是制造商名，后者第一属性也可能是描述信息，但第二属性才是真正的电量值。如果调用时把属性索引设为3，或错用两个属性，读回来的字节长度可能对，数值却完全不对。
对我来说，理解对象模型最大收益是：处理国产表和国外表时，我可以直接套用同一个对象访问接口，差别只在数据单位、小数位数、时区等参数上。这是DMLS协议最有价值的地方，也是中文版手册里最难翻译的部分——因为每一个中文词背后都是一套类与实例的关系。
2.3 三个高频操作：读标称值、读注册值、调用方法
拿我做过的一个光伏采集器项目举例，核心操作就三类：
Get（读属性）是最常用的。读累计电量，实际是GET-Request，访问“1-0:1.8.0.255”对象的属性2。读电压，访问“1-0:32.7.0.255”这类瞬时量对象的属性2。SET（写属性）用于修改电表的参数，例如设置最大需量、校时或写一个显示模式。Action（调用方法）用于执行一次操作，例如“清除最大需量”或“发起一次校相”。
一个容易忽视的点是，DMLS协议支持在一次应用层请求里携带多个AccessRequest，把十几个对象打包在一个APDU里传。这个能力在集中器场景下非常实用，能显著减少握手次数。我见过不少工程师把几十个读请求一个一个发，结果在低速电力线载波链路上等得心急。学会AccessRequest数组后，一次会话可能从两分钟缩短到十秒。
2.4 认证与加密等级：从最低成本到优先级高的加固方案
DMLS协议定义了几档认证方式，大家在联调时经常疑惑“为什么我这密码都填对了还是连不上”。常见选项包括None、Low、High和HighGMAC。None就是“裸奔”，适合自己开发环境；Low会在建立关联时发送密码，密码明文走链路，安全性很低，适合局域网仿真；High采用双方挑战应答机制，密码不直接出现在报文中；HighGMAC则在High基础上叠加AES-GCM加密，数据内容和认证信息都被保护。
选择哪一档，取决于项目推进阶段。仿真阶段用None或Low可以省掉很多调试烦恼；到了现场测试，至少用High；涉及计费数据可信要求时，必须上HighGMAC。一个重要做法是：把认证等级作为配置项而不是硬编码。我吃过亏——测试时把High写死在代码里，结果客户现场电表固件版本较低，不支持AES-GCM，整个项目硬生生卡了两天。
| 认证方式 | 安全强度 | 适用阶段 | 报文影响 |
|---|---|---|---|
| None | 无 | 功能验证 | 报文可读，调试方便 |
| Low | 弱 | 局域网/测试 | APP层多出密码字段 |
| High | 中 | 现场批量 | 握手阶段多两次挑战 |
| HighGMAC | 高 | 计费、合规场景 | APDU体明显变长，需要管理密钥 |
3. 用仿真服务端跑通一次DMLS读取：最小实现与参数选择
3.1 准备工作：仿真服务端、客户端与抓包工具
动手第一步，永远不要直接拿实物电表调。电表在上电后通常有几十秒甚至几分钟的“安全窗口”，连接失败次数太多，可能暂时拒绝后续会话，而仿真服务端可以随意重启、重置连接状态。我一般用Gurux社区提供的DLMS仿真服务端，它有一个带界面的模拟器，可以配置服务器地址、认证方式、密码和要暴露的对象列表。
客户端方面，如果你只想验证服务端是否正常，用Gurux自带的客户端工具即可。但为了后续能写进自己的程序，通常还是会拉一份官方Gurux库的源码，或者从PyPI上搜索与DLMS相关的包，注意确认它支持你需要的HighGMAC等级，不要只看star数。
抓包工具则优先安Wireshark。启动后设置抓包过滤为tcp.port==4059，这样你看到的就只是DMLS会话流量，而不是满屏的背景噪音。
3.2 跑通一次读取的六步操作
仿真环境下的完整流程可以拆成几步，每一步用表格说明关键点。
第一步，启动仿真服务端。选择“直连模式”，监听TCP/IP，端口保持默认4059，设置Server Address为1，Client Address为16。这里的Server Address指的是电表侧地址，不是主站地址。
第二步，启动Wireshark并设置过滤器。如果你发现端口是别的，比如某个项目中台转发了另一个端口，就改成对应端口。
第三步，打开客户端工具，填写服务端IP地址、端口4059、Client Address=16、Server Address=1，认证方式选NONE或者LOW。如果你的服务端默认要求LOW，就把密码填成服务端设定的值，通常为空或“123456”。
第四步，建立连接。先看Wireshark，正常会话会出现四组关键帧：SNRM/UA、AARQ/AARE、GET-Request/GET-Response。SNRM/UA完成链路层握手，AARQ/AARE完成应用层关联，GET-Request/GET-Response才真正读数据。
第五步，读取一个OBIS对象，比如“1-0:1.8.0.255”的属性2。仿真服务端会返回一个带单位的值。最后断开连接。
3.3 连接参数表与选择说明
| 参数 | 推荐值 | 作用 | 误填后果 |
|---|---|---|---|
| TCP Port | 4059 | DMLS over TCP的默认服务端口 | 找到不服务端 |
| Server Address | 1 | 电表地址（服务器端） | 握手地址不匹配 |
| Client Address | 16 | 主站地址（客户端） | 报文被服务端忽略 |
| Authentication | None/Low | 关联认证策略 | 密码不符直接AARE失败 |
| Invoke ID | 每次+1 | 关联请求序号 | 重传撞号导致响应错乱 |
通俗理解：Server Address和Client Address相当于双方“门牌号”。你拿着自己的地址拜访别人，别人只认自己的门牌号，两个地址搞反，表现为链路层握手成功后，应用层迟迟拿不到正确响应。
4. 五个DMLS落地常见坑：现象、原因、解决
4.1 连接总超时：Client Address与Server Address填反
现象：仿真服务端启动正常，客户端连接TCP成功，但发送SNRM后，服务端没有任何UA响应，或响应被客户端判为无效。反复重试，最后报“Transaction timed out”。
原因：两种常见情况。第一种最简单：配置界面里把Client Address填成了1，Server Address填成了16，方向正好颠倒。DLMS的地址字段是写在HDLC帧头里的，客户端地址是源地址，服务器地址是目标地址，调换后服务端认为这个帧不是发给自己的，会丢帧不回。
解决：把配置中两个地址互换即可。建议把地址做成配置项，并在日志里打印“source address:16 destination address:1”这样的信息，一目了然。
4.2 响应帧读出来了，但数据解析不出来
现象：客户端能正常建立关联，GET-Request发出去了，也收到了GET-Response，但把返回的十六进制字节转成十进制后数值明显不对，或者出现一个大到离谱的负数。
原因：读取对象时只看了OBIS代码，没看属性类型。同样一个属性，可能是int32、uint64、float64或Octet String字符串。各厂商表计对小数的缩放也不一致，有的电量值除1000才是kWh，有的除10000。
解决：读之前先通过对象描述文档确认数据类型与单位，再用编码工具按类型解析。不要看一眼打印就下结论。我习惯在程序里设计一个“类型映射表”，按Access Descriptor返回的类型自动转成浮点数。
4.3 串口能通，TCP不通
现象：同一套DMLS协议，用RS-485接电表一切正常，换成集中器走TCP连仿真服务端，客户端报“帧校验错误”或迟迟收不到数据。
原因：链路层帧封装方式不同。串口场景使用HDLC的分割与重组，帧里有HCS/FCS校验；TCP/IP场景常用Wrapper帧，把HDLC的“地址+控制+LLC”塞进一个TCP包，但通常不再重复做HDLC的FCS校验。如果客户端库里强制开启了HDLC CRC，就会把服务端返回的有效帧误判成损坏帧。
解决：查询你的库或服务端是否支持“wrapper模式”，并在TCP场景下关闭HDLC FCS校验。能不用自己手拼帧就不要手拼，交给封装库处理。
4.4 读取数据偶尔成功、偶尔失败
现象：10次会话里6次成功，4次单体超时。日志显示前一次会话刚结束，下一次关联就失败。重启客户端后又能好一阵。
原因：DMLS会话是有状态的。上一次关联如果没有正常关闭（如网络异常断开），服务端可能保留残留会话状态；新请求的Invoke ID与上次重复，服务端认为收到“旧请求”，丢弃或返回异常。
解决：每次新建关联时保证Invoke ID单调递增，并且明确区分“重传”和“新会话”。如果必须在短时间反复连接，则每次主动发送ReleaseRequest，或等待服务端空闲窗口。对集中器场景，我建议建立长连接而不是频繁开关会话。
4.5 升级HighGMAC后连不上
现象：设备在Low认证下一切正常，把认证方式改成High或HighGMAC后，客户端发送AARQ后服务端返回AARE，但状态码不是“成功”，而是报“安全上下文错误”。
原因：HighGMAC涉及安全套件协商。客户端和服务端的System Title（系统标题）、Global Key、Dedicated Key不一致，或算法标识冲突，都会导致握手失败。这不是密码错误，而是密钥/证书协商没对上。
解决：先从Low切到High，不带加密，验证挑战应答逻辑；再逐步切到HighGMAC，逐项核对System Title与密钥。很多开源库的默认密钥只适合测试，不要指望它能和多个厂家的电表都兼容。
5. 花一个下午整理自己的“DMLS中文版”：术语表与OBIS代码工具
5.1 高频术语中英文对照
做DMLS相关开发时，最影响沟通效率的不是代码，而是术语。评审会上说“对象”可能指数据库对象，说“属性”可能指界面字段。我自己维护过一份对照表，前几行最有价值：
| 英文缩写 | 中文建议 | 说明 |
|---|---|---|
| DLMS | 设备语言报文规范 | 整个协议家族的统称 |
| COSEM | 能源计量配套规范 | 对象模型与接口定义 |
| OBIS | 对象标识系统 | 用来标识对象的“门牌” |
| xDLMS | 应用层报文协议 | 真正在电线上传的数据格式 |
| HDLC | 高级数据链路控制 | 底层帧封装与差错校验 |
| ACSE | 关联控制服务元素 | 建立和释放应用层连接 |
| APDU | 应用层协议数据单元 | 一次请求/响应的具体内容 |
| GET | 读取属性 | 最常用的操作 |
| Attribute | 属性 | 对象里的一个数据字段 |
| Action | 方法 | 电表可执行的一个动作 |
这张表不需要背，但建议放在项目Wiki最显眼的位置。越是多团队协作，越要约束同一个中文词对应同一个英文缩写，不然“属性”和“对象”可以来回吵半小时。
5.2 OBIS代码解析脚本：把1.0.1.8.0.255翻译成人话
以下这段脚本，是每个DMLS项目里我都会保留的“查表工具”。它不依赖任何第三方DLMS库，只做字符串解析和字典替换，你可以直接复制扩展。
# obis_explain.py # 用法: python obis_explain.py "1-0:1.8.0.255" import sys # 按项目实际需要补充，这里只放最常见的几个 OBIS_ALIAS = { "1-0:1.8.0.255": "正向有功电能(kWh,累计值)", "1-0:2.8.0.255": "反向有功电能(kWh,累计值)", "1-0:32.7.0.255": "L1相电压(V,瞬时值)", "0-0:0.0.0.0.255": "设备铭牌对象", } def normalize(obis: str) -> str: # 兼容 "1.0.1.8.0.255" 与 "1-0:1.8.0.255" 两种写法 work = obis.replace("-", ":").replace(".", ":") parts = work.split(":") if len(parts) == 6: # 统一成业界常见展示格式 return f"{parts[0]}-{parts[1]}:{parts[2]}.{parts[3]}.{parts[4]}.{parts[5]}" return "" def main(): if len(sys.argv) != 2: print("请传入OBIS代码，例如: python obis_explain.py 1-0:1.8.0.255") return raw = sys.argv[1] norm = normalize(raw) if not norm: print("格式无法识别") return print("标准化OBIS:", norm) print("说明:", OBIS_ALIAS.get(norm, "未登记，请查阅标准")) if __name__ == "__main__": main()逻辑很简单：输入一段OBIS字符串，先把两种写法统一成中间格式，再查字典输出中文说明。这里的normalize函数把“-”和“.”统一转成冒号再重组，所以无论用户粘贴的是“1.0.1.8.0.255”还是“1-0:1.8.0.255”，都能得到标准结果。
实际使用时，你还需要把项目涉及的所有量测点按照厂家提供的DDL文件填进OBIS_ALIAS。相比查几百页PDF，命令行秒回体验好得多。代码很容易扩展成Web服务，丢给现场工程师用。
5.3 文档结构建议：面向现场工程师的DMLS中文版模板
一份让现场工程师愿意看的中文资料，不该是按章节翻译规范，而应该按问题组织。我见过太多“第一章概述、第二章帧格式”的翻译稿，最后落灰。我的模板结构是：
- 第一章：连接参数表，写清楚IP、端口、Server Address、Client Address、认证方式。
- 第二章：常用对象表，OBIS代码、中文名称、属性索引、单位、缩放系数。
- 第三章：典型报文字节级注释，把一次GET请求和响应的hex逐字节拆开，标出每个字节范围对应哪个字段。
- 第四章：异常排查表，按“现象-原因-做法”列二十行。
- 附录：术语对照表。
这样写的一个额外好处是，你可以直接拿对象表和异常表去和设备厂家核对，减少扯皮。
6. 验证自己是否真正理解DMLS：三个不必接实物表也能做的实验
如果你已经跑通了上面的仿真连接，再做三个实验，才能真正说对这个协议脱了盲。
实验一，故意让服务端掉线。仿真服务端正在和你客户端保持会话时，直接杀掉进程，再重启。观察客户端是否能在下一次请求时正确重连。很多实现失败就卡在“重连时没有重新走SNRM握手，而是复用旧会话ID”。正确的做法是检测链路断开后，重置应用层状态，重新发起关联。
实验二，抓包对比None和HighGMAC的APDU长度。用Wireshark分别保存两段会话，过滤同一个读请求。你会看到HighGMAC模式下，GET-Request的APDU体明显变长，多出的部分就是认证和加密开销。理解这一点，你在规划低功耗设备时就不会对报文长度掉以轻心。
实验三，把认证方式改成Low，密码故意填错，观察AARE返回的状态。正常协议栈会在日志里输出一个非零状态码，同时释放连接。如果你的客户端表现是“卡死不超时”，那说明断代逻辑有问题，这比读不到数据更危险。
做这些验证时，我习惯每次只改一个变量，改完立刻看协议栈日志。这个习惯帮我少排查了一堆玄学问题。DMLS协议给人感觉像个黑匣子，但当你把SNRM、AARQ和GET这三板斧抓稳，它就没有想象中那么神秘。希望这些血泪经验能帮你省下几个加班的晚上。
本文还有配套的精品资源，点击获取
