企业官网建设流程全解析

简介：这份《DMLS协议中文版》面向电能量数据采集终端开发、电能表通信调试人员及IEC62056/DLMS协议自学者，提供协议族中文说明，帮助梳理采集器与电表之间基于Client-Server结构的通信流程。资料从三层协议模型入手，依次说明物理层对通信硬件的操作、基于HDLC的链路层在地址校验、帧长校验、CRC校验和长帧拆包组包中的作用，以及应用层从连接协商到数据请求、链路释放的报文组织。应用层部分重点讲解ASN.1语法、BER与AXDR编码、AARQ/AARE连接帧和典型请求过程，并配有请求电量、瞬时量（电压、电流、功率）、负荷曲线和时间等数据包实例。压缩包共1个doc文件，约620KB，内容集中，便于按协议层次查阅和联调时对照。已有873人学习，适合需要理解DLMS协议框架、字段含义与报文编码方式的技术人员参考。

1. DMLS 协议中文版到底解决什么问题：从一块电表读不到数据说起

DMLS 协议中文版这份资料，最适合在采集器已经能打开串口、却卡在 SNRM 发出去没 UA、AARQ 回了却读不到电量这种现场用。文件名写 DMLS，内文讲的是 DLMS/IEC62056 协议族，DMLS 协议这个叫法在工程现场也常被混用，别被一个字母吓住，按三层模型和 HDLC 帧去对就行。

它解决的不是“协议科普”问题，而是把采集器侧最常问的建链、寻址、编码、长帧拆包摊开讲清楚。适合刚接手电表通讯的嵌入式开发者，也适合测试人员拿报文逐字节对照。读法上不要从第一页硬啃，先盯住 SNRM/UA、AARQ/AARE、Get-Request、RR/DISC 这四段，现场排错会快很多。

2. 协议模型怎么落到采集链路：三层连接与 Client/Server 角色拆解

DLMS 协议族在这个资源里被拆成物理层、链路层、应用层，通讯双方是 Client-Server 结构。采集器是 Client，电表是 Server，请求由 Client 发起，Server 响应。这个角色划分不是纸面概念，抓包时先看源地址和目的地址，就能判断这一帧是谁发的、该不该回。现场最容易犯的错，是把应用层帧直接怼到串口上，忽略前面还要先建物理连接、再建 HDLC 链路、再走应用层协商。

三层之间不是并列关系，而是层层包裹。应用层的 AARQ 也要加上 LLC 头，再套 HDLC 帧，最后从物理口发出去。链路层没通，应用层帧再正确也到不了电表。排错顺序我一般按“物理口能不能收发原始字节 → HDLC 能不能 SNRM/UA → 应用层 AARQ/AARE 的 result 是不是 0 → Get-Request 有没有响应”往下切。切断层比盯着一整串十六进制猜要稳。

2.1 物理层不是协议重点但决定排错顺序

物理层在手册里被放在最低层，很多人直接跳过，现场最先坏的偏偏是它。DLMS 可以跑在多种物理介质上，串行通道、电话拨号、网络通道都有对应实现。物理层负责打开端口、初始化端口、收发数据、关闭端口，在嵌入式系统里通常对应底层驱动，不被通讯规约直接控制。也正因为这样，协议文档不会把串口波特率、数据位、停止位、校验位、流控、方向控制这些细节写全，得靠硬件手册和现场经验补。

我一般先让采集器发一帧 0x7E 开头的 SNRM，串口助手上能看到完整的 0x7E ... 0x7E，再谈协议。如果连 0x7E 都看不到，先查线序、电平转换、使能脚和波特率，别急着怀疑 CRC。如果能看到 0x7E，但电表不回 UA，再查地址和控制字。物理层还有一个常被忽略的点是超时：不同电表从收到 SNRM 到回 UA 的延迟不一样，采集器超时设得太短，会把正常响应截断，日志里看起来就像“没回”。

物理层排错可以按下面几步走，不用一上来就抓应用层：

1. 关闭流控，固定 8 数据位、1 停止位、偶校验或无以现场表计说明为准。
2. 用串口助手手动发一帧已知 SNRM，确认电表回 UA。
3. 换回采集器发同一帧，比较串口助手和采集器日志里的字节是否一致。
4. 如果采集器日志里的 0x7E 帧被拆成多段，先查发送缓冲和方向控制，不要改协议参数。

注意：物理层能收到 0x7E 不代表帧完整，半双工通道的方向切换慢一点，最后几个字节就可能被吃掉。

2.2 HDLC 链路层的地址、帧长与 CRC

链路层是物理层和应用层之间的通道，DLMS 用的是 HDLC 高速链路控制协议。链路层里又分 LLC 子层和 MAC 子层。LLC 子层主要负责转发，Client 发应用层数据时加 LLC 帧头 0xE6、0xE6、0x00，Server 发应用层数据时加 0xE6、0xE7、0x00。这个方向别搞反，现场出现过 Client 帧加了 0xE6、0xE7、0x00，电表直接不回，抓包看 LLC 头就能定位。

MAC 子层负责地址检查、CRC 校验、长数据帧拆包组包。HDLC 帧以 0x7E 开头、0x7E 结尾，两个 0x7E 之间是链路用户数据。包含应用层数据时，帧里会多出帧头校验 HCS、LLC 帧头、用户数据信息和数据帧校验 FCS。帧类型与帧长占两个字节，DLMS 使用 Frame Type 3，帧类型高四位恒为 A，S 位表示是否分片，剩余部分是帧长度，长度按字节计，不包括首尾两个 0x7E。地址域用扩展编址，某个地址字节最低位为 0 表示后面还有地址字节，最低位为 1 表示地址域结束。Client 地址固定一个字节，最低位置 1，所以可用地址范围有限。Server 地址可以分 upper HDLC address 和 lower HDLC address，upper 表示逻辑地址，lower 表示物理地址，常见有一字节、两字节、四字节结构。

示例里 Client 地址 0x03，Server 地址 00 22 00 23，前三字节最低位都是 0，最后一字节 0x23 最低位是 1，地址域在这里结束。这个结构能用不代表所有表都能用，现场必须以表计说明书或点表为准。地址改完必须重算 HCS 和 FCS，否则抓包能看到完整 0x7E，电表仍然不回 UA，这种坑后面还会细说。

2.3 应用层协商：AARQ/AARE 把参数谈拢

链路层 UA 回来之后，不代表就能读数据。DLMS 还要建立应用层连接，这个过程叫 Negotiation。Client 发 AARQ 帧，Server 回 AARE 帧，双方把应用上下文、认证方式、DLMS 版本、一致性块、最大接收 PDU 尺寸这些参数谈拢。AARQ/AARE 是应用层里比较特殊的数据帧，只有这部分内容部分使用 DLMS 的 BER 编码，后面的 XDLMS 数据请求大多走 AXDR 编码。很多解析错位就出在这里：拿 BER 解析器去硬套 XDLMS，前面几个字段能读，后面全乱。

AARE 里先看 result。result 为 0 表示接受，非 0 就要查诊断值，不要继续发 Get-Request。application-context-name 是一个 OBJECT IDENTIFIER，常见值以 60 85 74 05 08 开头，后面不同后缀对应不同上下文。user-information 里包着 InitiateResponse，里面会带 negotiated-dlms-version-number、conformance、server-max-receive-pdu-size 等参数。这些参数决定后面一帧能带多少应用层数据，也影响长帧分片。现场如果 AARQ 发出去没 AARE，先查 LLC 头方向、HDLC 帧计数和 AARQ 的 application-context-name 是否被电表支持。

应用层协商的可执行步骤可以固定成四步：

1. 确认 HDLC 已经收到 UA，且 UA 里的窗口和最大信息域长度与 SNRM 一致。
2. 发 AARQ，抓包确认 LLC 头是 0xE6、0xE6、0x00，HDLC 控制字和帧计数连续。
3. 收 AARE，先读 result，再读 user-information 里的 InitiateResponse。
4. 记录 server-max-receive-pdu-size 和 conformance，后面发 Get-Request 时按这个尺寸控制帧长。

提示：AARE 的 result 为 0 只说明应用层连接建立成功，不代表某个 OBIS 对象一定可读，对象权限和属性索引还要单独查。

3. HDLC 帧怎么组：SNRM、UA、I 帧、RR 与 DISC 的实操拆解

链路层建立连接靠 SNRM 和 UA。Client 发 SNRM，Server 回 UA 表示链路建立，回 DM 表示链路断开或没建立。SNRM 里可以不带用户信息，表示 Client 接收 Server 的已配置参数；也可以带参数协商字段，把最大信息域长度和窗口大小谈清楚。默认 WINDOW_SIZE 为 1，默认 MAXIMUM_INFORMATION_FIELD_LENGTH 为 128 字节。这两个默认值能覆盖大多数小数据请求，但请求负荷曲线时一定会碰到长帧，窗口和分片处理不好就会翻车。

3.1 SNRM 与 UA 的参数协商字段

SNRM 的用户信息里常见四组参数：05 表示发送最大信息域长度，06 表示接收最大信息域长度，07 表示发送窗口大小，08 表示接收窗口大小。每组参数按“标识 + 长度 + 值”排列。下面这段报文把地址和参数位置摆出来，方便逐字节对照。

# SNRM：Client -> Server，地址和参数仅作字段位置示意 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 01 65 5e 7e # UA：Server -> Client，确认同样的参数 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 # DISC：Client -> Server，结束链路 7e a0 0a 00 22 00 23 03 53 06 c7 7e # DM：Server -> Client，表示已断开 7e a0 0a 03 00 22 00 23 1f 43 4c 7e

这几段报文的逻辑是：首尾 0x7E 是 HDLC 标志；a0 21 里 a0 表示帧类型 3 且未分片，21 是帧长度；00 22 00 23 是目的地址，03 是源地址；93 是 SNRM 的控制字，73 是 UA 的控制字；0b 14 和 28 f0 分别是帧头校验；81 80 12 是 SNRM 标识和组长度；05 01 80 表示发送最大信息域长度 128 字节，06 01 80 表示接收最大信息域长度 128 字节，07 04 00 00 00 01 表示发送窗口为 1，08 04 00 00 00 01 表示接收窗口为 1；最后的 65 5e、53 3b 是 FCS。

参数怎么改要看双方能力。把 128 改成 256，不是改一个字节就完事，SNRM 和 UA 要一致，电表要支持，应用层 PDU 尺寸也要跟着调。窗口从 1 改成大于 1，P/F 位和多帧确认逻辑都会变复杂，新手阶段不建议动。现场最稳的做法是先保持默认 128 和窗口 1，把建链和单帧读通，再考虑长帧优化。UA 里的参数如果和 SNRM 不一致，以 UA 为准重新记录，后面分片按 UA 的值算。

注意：上面示例里的 FCS 是按原帧算的，改动任何一个地址或参数字节都要重算 HCS 和 FCS，直接抄十六进制很容易出现“帧看起来完整但电表不回”。

3.2 控制字与帧计数：RRR/SSS/PF 怎么变

HDLC 控制字负责帧计数和特殊帧标识。RRR 是接收帧计数，SSS 是发送帧计数。链路建立后，第一次请求数据时，Client 侧包括发送 AARQ，RRR 置 0，SSS 置 0。Server 收到后返回响应，RRR 为 1，SSS 为 0。Client 再次请求时 RRR 加 1，SSS 加 1。Server 响应再 RRR 加 1，SSS 加 1，如此反复。这个计数不是随便填的，抓包时连续两帧计数对不上，电表可能直接回 FRMR 或不响应。

P/F 位里，Poll 由 Client 发送，置 1 表示要求 Server 回应，置 0 表示不允许回应。Final 由 Server 发送，置 1 表示一次数据帧发送结束，置 0 表示还没发完。Final 只有在窗口大于 1 时才有明显意义；窗口等于 1 时，Server 返回的数据帧里这一位通常总是置 1。现场如果窗口是 1，却按多帧窗口去等 Final 为 0 的后续帧，就会误判“数据没发完”。

请求数据结束后，还要再发 RR 帧，收到确认后才能发 DISC 结束链路。这个顺序别省。Client 的 RR 帧里 RRR 只需把 Client 的接收计数加 1 得到。有的实现读到最后一条响应就直接发 DISC，电表内部状态没释放，下一次通讯就可能超时或回 DM。血泪经验是：把 RR 当成“收尾确认”，不是可发可不发的可选帧。

3.3 长帧分片与 RR 请求：负荷曲线为什么总翻车

用户数据默认最大 128 字节，请求负荷曲线时应用层 PDU 往往超过这个长度，必须启动长数据帧流程。发送端把长帧拆成短帧，帧类型与帧长字段里的 S 位置 1，接收端检测到 S 位后知道这是分片，需要做相应处理。Client 通过发送 RR 数据帧请求被分割数据的其他部分。现场最常见的翻车现象是：只收到第一片，就把这一片当完整 APDU 去解析，结果字段错位，或者直接报“负荷曲线为空”。

正确做法是先看 S 位，再看控制字和帧计数，把每一片 HDLC 用户数据按顺序拼起来，拼完再交给应用层解析。如果窗口大于 1，Server 可能连续发多帧，Client 要用 RR 或窗口机制确认。窗口等于 1 时，交互简单一些，但 RR 循环不能省。请求负荷曲线时，还要注意 AARE 里协商的 server-max-receive-pdu-size，如果这个值很小，分片会更多，超时时间要相应放宽。

长帧处理可以按下面步骤落地：

1. 收到 I 帧后先看帧类型与帧长字段的 S 位，S=1 表示还有后续分片。
2. 把当前片的用户数据追加到缓冲区，不要立即解析成完整对象。
3. 按协商窗口发 RR 或等下一帧，RR 里的 RRR 按规则加 1。
4. 收到 S=0 的最后一帧后，检查拼接长度是否与 APDU 长度字段一致。
5. 拼接完成后再按 AXDR 解析负荷曲线条目，条目数、间隔、时钟信息逐项核对。

这里还有一个容易忽略的边界：分片是 HDLC 层的事，LLC 头只在第一片出现还是每片都出现，要看具体实现和帧结构。抓包时如果每片都带 LLC 头，拼接前要先剥掉；如果只在第一片带，后面直接拼用户数据。拿不准时对照手册里的帧格式图，别凭感觉删字节。

3.4 一次完整建链、读数据、断链的报文检查表

把一次正常通讯拆成检查表，比盯着日志从头看到尾有效。建链前先确认串口参数和地址，SNRM 发出后等 UA；UA 里看窗口和最大信息域长度；然后发 AARQ，等 AARE 看 result；result 为 0 再发 Get-Request；收到响应后如果需要下一片就发 RR；数据读完发 RR 确认，再发 DISC，等 UA 或 DM。

这张表在联调时可以直接当回归清单用。每次改地址、改窗口、改最大信息域长度，都从第一行重新走一遍，别只测 Get-Request。链路层的参数是全局的，改一个可能影响后面所有帧。

4. ASN.1、BER 与 AXDR 怎么读：AARQ/AARE 和 Get-Request 的字段定位法

DMLS 协议中文版把 ASN.1、BER、AXDR 单列成章，不是为了讲编译原理，而是因为现场解析错位十有八九出在这一层。ASN.1 是描述应用层数据帧的抽象语法，BER 和 AXDR 是实现这套语法的两种编码。DLMS 里用 ASN.1 描述的 DLMS 协议部分用 BER 编码，用 ASN.1 描述的 XDLMS 协议用 AXDR 编码。AARQ 和 AARE 只有部分内容使用 DLMS 的 BER 编码，绝大多数应用层数据通讯走 XDLMS 的 AXDR。分不清这两套编码，就会拿 BER 的“标签+长度+值”去套没有标签长度头的 AXDR，越解析越乱。

4.1 ASN.1 标签：Universal、Application、Context-specific 怎么区分

ASN.1 里一个数据帧可以写成 Name ::= [tag] IMPLICIT/EXPLICIT Data type，后面跟大括号里的数据项。tag 包含 class type 和一个数字。class type 有四种：Universal 表示在所有 DLMS 应用里含义唯一，Application 表示含义同具体应用有关，Private 表示厂商自定义范围，Context-specific 表示同上下文数据项有关，在不同结构里可能有不同含义。tag 里的数字是数据帧标号，作为句柄出现在应用数据单元里。IMPLICIT 改变父数据帧的 tag，EXPLICIT 不改变父数据帧的 tag，不注明 IMPLICIT 的项即为 EXPLICIT。

常见简单类型和 tag number 可以查表记，不必全背。INTEGER 是 2，BIT STRING 是 3，OCTET STRING 是 4，NULL 是 5，OBJECT IDENTIFIER 是 6，SEQUENCE 和 SEQUENCE OF 是 16，SET 和 SET OF 是 17。复合类型里 SEQUENCE 表示内容顺序排列，CHOICE 表示从几个数据帧里选一种。Get-Request 就是 CHOICE，下面有 get-request-normal、get-request-next、get-request-with-list 三个分支。看到 AARQ/AARE 里的 A1、A2、A3、BE 这些字节，先别急着当成长度，它们是 context-specific 标签，后面才跟长度和值。

4.2 BER 的 TLV 拆法与 AARE 逐字节示例

BER 常见结构是“数据标识 + 数据长度 + 数据内容”，数据内容里可以嵌套另一层 BER。数据标识由 class、constructed 位和 tag number 组成，长度字段有短形式和长形式。短形式一个字节直接表示长度，长形式第一位表示后面还有几个长度字节。拆 AARE 时先读外层 61，再读长度，然后按 A1、A2、A3、88、89、AA、BE 逐段往下走。下面这段 AARE 片段把字段位置摆出来，地址和认证值仅作结构示意。

# AARE 片段：61 外层，42 长度，后面按 BER TLV 逐段读 61 42 a1 09 06 07 60 85 74 05 08 01 01 a2 03 02 01 00 a3 05 a1 03 02 01 00 88 02 07 80 89 07 60 85 74 05 08 02 01 aa 0a 80 08 41 42 43 44 45 46 47 48 be 04 0e 08 00 06 5f 1f 04 00 00 08 1d 21 34 00 07 00 07

这段报文的逻辑是：61 是 AARE 外层标签，42 是后面内容的长度；a1 09 表示 application-context-name 占 9 字节，06 07 表示 OBJECT IDENTIFIER 占 7 字节，60 85 74 05 08 01 01 是上下文 OID 的值；a2 03 02 01 00 表示 association-result，02 01 00 是 INTEGER 值 0，表示接受；a3 05 是诊断结构，a1 03 02 01 00 是诊断值；88 02 07 80 是 ACSE requirements；89 07 是 mechanism-name；aa 0a 是认证值；be 04 0e 表示 user-information 是 OCTET STRING，长度 14 字节，里面 08 00 06 5f 1f 04 00 00 08 1d 21 34 00 07 00 07 属于 XDLMS 的 InitiateResponse 内容，按 AXDR 继续读，不要再套 BER。

参数说明上，a2 的 result 是第一个要看的字段，非 0 就查 a3 诊断。a1 的 application-context-name 决定应用上下文，不同后缀对应不同认证和引用方式。be 里的 user-information 是 BER 的 OCTET STRING 外壳，里面是 XDLMS 数据，外壳和内容要分开解析。现场如果 AARE 能收到但 result 非 0，先查认证方式和 application-context-name，不要先怀疑 OBIS。

4.3 AXDR 与 BER 的差异：为什么 XDLMS 不能用 BER 解析器硬套

AXDR 是对 XDR 的扩展，编码思路和 BER 不一样。BER 每个值带标签和长度，AXDR 很多地方按 ASN.1 定义的类型顺序直接排列，序列本身可能只有一个序列标识，里面的整数、布尔、位串按定义的长度和顺序紧挨着放。拿两个整数 0x1234 和 0x5678 对比，BER 会写成 30 08 02 02 12 34 02 02 56 78，外层 SEQUENCE，里面每个 INTEGER 都带标签和长度；AXDR 更接近 12 34 56 78，序列标识之后直接是值。这个差异决定了 XDLMS 的 Get-Request、Get-Response 不能直接丢给通用 BER 解析器。

解析 XDLMS 时先确定 APDU 类型，再按对应 ASN.1 结构逐字段读。Get-Request-Normal 是 SEQUENCE，里面依次是 invoke-id-and-priority、cosem-attribute-descriptor、access-selection-parameters 可选。cosem-attribute-descriptor 里再依次是 class id、instance id、attribute id。instance id 就是 OBIS 六字节，不要按 ASCII 字符串读。attribute id 是属性索引，不同对象类型含义不同，查对象模型表，不要背死。

4.4 Get-Request-Normal 的 class id、OBIS 与属性索引

Get-Request-Normal 是现场读电量、电压、电流、功率、负荷曲线、时间最常用的请求。它的字段定位法可以固定成：先看 APDU 类型，再读 invoke-id-and-priority，再读 class id 两字节，再读 OBIS 六字节，再读 attribute id 一字节，最后看有没有 access selection。class id 标识对象类型，寄存器类、负荷曲线类、时钟类各不相同；OBIS 标识具体数据项，比如有功总电能、A 相电压、当前时间；attribute id 决定读值、读单位、读 scaler 还是读其他属性。

读负荷曲线时，class id 和 OBIS 只是入口，后面还要处理 selective access，按时间范围或条目范围取数据。读瞬时量时，attribute id 通常指向 value，但单位、scaler 可能在别的属性里，要分多次请求或按对象模型一次取结构。现场如果 Get-Response 回来了但数值明显不对，先查 attribute id 和 scaler，再查 OBIS 是否对应错相别。OBIS 六字节里每一位都有含义，别把 A 相电压的 OBIS 抄成 B 相，这种错在联调初期很常见。

5. 避坑与排查：中文手册看得懂但报文对不上的五类现场问题

DMLS 协议中文版里给的是字段顺序和报文示例，现场对不上往往是地址、计数、分片这些链路细节。下面五类问题按“现象、原因、解决”拆开写，都是联调时能直接对照抓包排查的。每类问题都别

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