简介面向需要与电能表开展串口通信开发的Java工程师这份源码实现了DLT645-2007电力行业标准协议的数据帧解析、命令编解码、CRC校验与应答处理适用于远程抄表、用电信息采集与设备监控等典型场景可帮助开发者快速落地串口通信模块并缩短联调周期。压缩包共11个文件包含3个Java源文件、3个class编译文件、2个properties配置文件、1个xml工程配置、1个iml模块文件与1个jsp页面包大小约20KB整体结构精简导入工程后即可对照源码学习。目前已有2461人学习下载。通过阅读和调试这套源码可以重点掌握协议中地址域、控制域、数据域的拆分技巧大端与小端字节序的转换方法以及RXTX、JSerialComm等串口库的选型与异常处理思路同时源码中完整的命令对应关系和应答帧处理逻辑也为移植到其他采集系统提供了便利适合电力计量领域的Java开发者以及初次接触DLT645协议的读者作为参考。1. Java 解析 DLT645-2007先搞清这个协议值不值得折腾第一次接触 DLT645-2007 的时候我手里只有一个 USB 转 485 的调试线、一块多功能电能表和一沓打印出来的协议文档花了一个多星期才把第一帧完整报文读出来。Java 版 DLT645-2007 电能表协议解析源码解决的核心问题是把串口上那串十六进制字节流换算成可用的电能量、电压、电流和功率数据适用于集中抄表、能耗监测平台、边缘采集网关这类场景。协议本身不复杂真正耗时间的永远是串口接线、地址域字节序和超时重试这些细碎问题代码只占三成调试占七成。2. DLT645-2007 帧结构从字节流里抠出电表地址和电能数据2.1 帧头和地址域0x68 之后地址是反着读的DLT645-2007 的帧结构很固定每帧从起始符 68H 开始到结束符 16H 结束中间依次是地址域、控制码、数据域长度、数据域和校验和。把帧结构列成一张表后面所有解析代码都围绕这张表展开帧成分字节数说明起始符1固定 0x68地址域6表号BCD 码低字节在前控制码1区分读、写、广播校时等操作数据域长度 L1数据域总字节数数据域L数据标识 DI 加实际数据校验和 CS1从起始符到校验和前一字节累加取低 8 位结束符1固定 0x16起始符 68H 在报文中会出现两次第一次是帧起始第二次是地址域结束后的再确认很多解析代码直接把第二个 68 当作地址域的终止标志。地址域是最大的坑电表铭牌上的表号是一串十进制数字但协议要求按 BCD 码编码并且低字节在前发送。比如表号 123456789012先按 BCD 拆成 12 34 56 78 90 12 六个字节再倒序放到帧里所以报文里的地址域实际是 12 90 78 56 34 12。解析时要把这 6 字节倒过来拼字符串才能得到人眼认识的表号。如果表号不足 12 位协议规定地址域高位补 AA这一点很容易被忽略。我见过有人把补位字节当作用户数据解析最后表号字符串里多出 4 个 A和数据库里的台账永远匹配不上。地址域长度不足 6 字节时按协议补 AA 而不是补 00记住这个前提后面排查地址对不上会省很多时间。从报文里提取表号代码很直接// 从完整报文帧中提取电表地址 public static String parseAddress(byte[] frame) { StringBuilder sb new StringBuilder(); for (int i 6; i 1; i--) { // 地址域在帧中的索引是 1-6传输顺序低字节在前 sb.append(String.format(%02X, frame[i])); } String address sb.toString(); // 表号不足12位时协议规定高位补AA解析时去掉 while (address.startsWith(AA)) { address address.substring(2); } return address; }逻辑说明地址域从索引 1 开始占 6 字节倒序遍历即完成高低字节反转String.format(%02X)把每个字节转成两位大写十六进制。因为补位只出现在正序字符串的开头用while循环持续去掉开头的 AA直到遇到真正的表号数字。这里注意只能判断 AA不能去掉以数字开头的正常表号。2.2 控制码和数据标识C0 读数据、D0 写数据DI 才是真正要的东西控制码决定这一帧要干什么主站请求时常见控制码值如下表控制码功能使用场景0xC0读数据读取电能量、电压、电流等0xC1读后续数据数据长度超过单帧上限时续读0xD0写数据下发费率、表计参数0xD6广播校时对全表计统一校时表端正常应答时控制码会按协议组合出应答值常见是 0x81 开头具体映射以协议附录为准。解析时不要写死「控制码等于 C0 才是读数据」因为同一帧从不同厂商表计回来可能带应答位判断读写方向要看最高位判断功能要看低 5 位这样才能兼容不同厂家的实现差异。数据标识 DI 是更关键的东西它决定数据域里装的是什么。DI 由 4 个字节组成DI0 到 DI3传输时同样低字节在前。常用数据标识的映射关系如下数据项DI0DI1DI2DI3报文字节序组合有功总电能0000000000 00 00 00正向有功总电能0100000000 00 00 01反向有功总电能0200000000 00 00 02A 相电压0001010202 01 01 00A 相电流0002020202 02 02 00比如要读 A 相电压DI 逻辑值是 02010100组帧时按低字节在前实际发送顺序是 00 01 01 02数据长度 L 就是 4。看不懂 DI 之前报文就是一堆十六进制数字看懂 DI 之后每一帧都能对应到具体业务数据这一步绕不过去。控制码和数据标识的解析放一起写因为在报文中它们紧挨着一个字节是操作类型紧接着的 4 字节是操作对象public static FrameInfo parseFrameHeader(byte[] frame) { FrameInfo info new FrameInfo(); // 帧索引: 0起始符, 1-6地址域, 7第二个68, 8控制码, 9长度 info.controlCode frame[8]; int length frame[9] 0xFF; // 数据域从索引10开始前4字节是DI info.di0 frame[10] 0xFF; info.di1 frame[11] 0xFF; info.di2 frame[12] 0xFF; info.di3 frame[13] 0xFF; info.hasMore (info.controlCode 0x20) ! 0; // D5位1表示有后续帧 return info; }逻辑说明从固定偏移量取出控制码和数据长度再取 4 字节 DI。length 0xFF是必须的因为数据长度最大 255Java 的 byte 会把它当负数。hasMore用到控制码的 D5 位这一位在长数据拆分场景里非常关键后面讲多帧拼接时会再次用到。2.3 校验和 CS从第 2 字节加到倒数第 2 字节取低 8 位校验和算法在协议里写得很明确但实现时翻车率极高。规则是从帧的第一个 68H 开始到校验和前一字节为止所有字节做累加结果只取低 8 位。覆盖范围包括起始符、地址域、第二个 68、控制码、数据长度、数据域总共 9 加 L 个字节不包含结束符 16H。很多初写解析的人在校验和这里踩坑核心原因是 Java 的 byte 是有符号类型。一个字节 0x80 在 Java 里转成 int 是 -128直接累加就会把整个校验和带偏所以每个字节参与累加前都要先做 0xFF转成无符号整数。// 计算校验和frameBody 是从起始符68到数据域结束的完整区间 public static byte calcChecksum(byte[] frameBody) { int sum 0; for (byte b : frameBody) { sum (b 0xFF); // 消除Java有符号字节的影响 } return (byte) (sum 0xFF); }逻辑说明sum是 int 类型累加过程中可能超过 255但只要在最后取 0xFF高位溢出自然丢弃结果就是协议规定的低 8 位。返回时强转回 byte后续和帧尾的校验和字节直接比较即可。实际校验一帧报文时我习惯把「算出的 CS」和「帧里的 CS」都打印出来做对比而不是只给一个 true/false 结果。差距为 0 说明帧结构正确差距不为 0 时打印值能直接告诉你偏了多少排查效率高很多。这个习惯在做串口调试时极其有用因为很多电表固件对校验和的处理有细微差别光看布尔结果根本不知道是算错还是收错。另外要注意计算起点是帧头 68H前面如果有 FE 前导字节不要一起加进去。前导字节是通信时序用的不属于帧内容加了之后校验和必错。3. 串口层实战用 jSerialComm 把报文发出去并收回来3.1 串口参数波特率 2400、数据位 8、校验位偶校验、停止位 1DLT645-2007 的物理层参数是协议写死的默认 2400bps8 数据位偶校验 EVEN1 停止位。这几个参数在串口通信里属于「必须一致才能通信」的硬条件两端任何一项不一致收到的就是乱码或者干脆没响应。有些老电表可以手动改成 9600但现场如果没有特殊要求保持协议默认值最稳妥。Java 侧操作串口我一般用 jSerialComm比 RXTX 维护活跃、API 也更简洁Windows 和 Linux 下都能跑。打开一个串口的完整配置如下import com.fazecast.jSerialComm.SerialPort; SerialPort port SerialPort.getCommPorts()[0]; // 实际项目要按名称匹配 port.setBaudRate(2400); port.setNumDataBits(8); port.setNumStopBits(SerialPort.ONE_STOP_BIT); port.setParity(SerialPort.EVEN_PARITY); port.setReadTimeout(1000); if (!port.openPort()) { throw new RuntimeException(串口打开失败检查权限和占用); }参数说明波特率 2400 是协议默认不建议轻易改动数据位 8、偶校验、停止位 1 三项必须和电表侧一致。openPort()返回 false 时原因基本只有三个端口被其他进程占用、Linux 下当前用户没有 dialout 组权限、设备不存在。Linux 下排查权限问题最快的方式是执行ls -l /dev/ttyUSB0看所属组然后用sudo usermod -aG dialout 当前用户名把自己加进 dialout 组再重新登录。选择串口不建议写死端口名。Windows 下 COM3 可能因为插拔换了编号Linux 下/dev/ttyUSB0也可能变成/dev/ttyUSB1。我一般的做法是遍历SerialPort.getCommPorts()把每个端口的名字打印出来启动时用配置文件指定避免每次换环境都改代码重新编译。3.2 发送读数据命令组帧、发送、等响应的完整代码组帧是协议解析的第一步。完整读数据请求帧包含前导字节、起始符、地址域、第二个 68、控制码、长度、数据标识、校验和、结束符。前导字节 FE 建议发 4 个有些表 2 个就能响应4 个是兼容性最好的选择但不要发太多发多了有的表反而会判定为帧错误。// 组一帧读数据请求addressHex是表号字符串di是4字节数据标识 public byte[] buildReadFrame(String addressHex, int[] di) { ByteBuffer buf ByteBuffer.allocate(32); for (int i 0; i 4; i) { buf.put((byte) 0xFE); // 前导字节 } buf.put((byte) 0x68); // 起始符 byte[] addr new byte[6]; int addrLen addressHex.length() / 2; for (int i 0; i 6; i) { if (i addrLen) { addr[i] (byte) Integer.parseInt( addressHex.substring(i * 2, i * 2 2), 16); } else { addr[i] (byte) 0xAA; // 不足12位补AA } } buf.put(addr); // 地址域6字节 buf.put((byte) 0x68); // 第二个起始符 buf.put((byte) 0xC0); // 读数据请求 buf.put((byte) 0x04); // L 4DI占4字节 for (int i 3; i 0; i--) { buf.put((byte) di[i]); // DI低字节在前 } byte[] body Arrays.copyOfRange(buf.array(), 4, buf.position()); byte cs calcChecksum(body); // 校验和从68开始算 buf.put(cs); buf.put((byte) 0x16); byte[] frame new byte[buf.position()]; System.arraycopy(buf.array(), 0, frame, 0, frame.length); return frame; }逻辑说明表号字符串按两位一组解析成十六进制字节不足 6 字节时高位补 AA。DI 数组传入的是逻辑顺序发送时for (int i 3; i 0; i--)完成低字节在前反转。校验和计算起点是整个帧的第 4 个字节也就是起始符 68H不包含前面的 FE 前导字节所以这里把Arrays.copyOfRange(buf.array(), 4, buf.position())作为校验和入参而不是从头开始。发送和接收要配合好。发送用port.writeBytes(frame, frame.length)写入后立刻进入读响应阶段。这里有个经验不要发送后马上 sleep 再读而是直接进入带超时的读循环让内核缓冲区自然积累数据。很多电表的响应时间在 20 到 200 毫秒之间如果固定 sleep 200ms一部分表响应慢就会漏掉。3.3 拆帧和重发机制超时重试的边界条件串口读响应最大的坑是数据会分片到达。一次readBytes可能只读到半个帧也可能读到一个半帧绝不能假设一次 read 就是完整报文。收到数据后要先把所有字节拼进一个缓冲区然后反复找结束符 0x16 判断帧是否完整。public byte[] readFullFrame(SerialPort port, long timeoutMs) throws IOException { ByteArrayOutputStream buffer new ByteArrayOutputStream(); long deadline System.currentTimeMillis() timeoutMs; while (System.currentTimeMillis() deadline) { byte[] chunk new byte[128]; int n port.readBytes(chunk, chunk.length); if (n 0) { buffer.write(chunk, 0, n); // 从缓冲区里找帧头68和帧尾16帧尾存在即认为完整 byte[] all buffer.toByteArray(); int start findFrameStart(all); // 找第一个0x68 int end findLastFrameEnd(all); // 找最后一个0x16 if (start 0 end start) { return Arrays.copyOfRange(all, start, end 1); } } Thread.sleep(20); } return null; // 超时返回null上层决定是否重发 }逻辑说明外层用System.currentTimeMillis()做整体截止时间内层每次最多等 20 毫秒再循环既不会忙等导致 CPU 空转也不会因为单次 read 超时丢数据。findFrameStart从第一个 0x68 开始找帧头不固定读第 0 字节因为串口缓冲区里可能有上一次的残留数据。超时重发策略我从实践中总结出来的经验是重试 3 次第 1 次间隔 200ms之后每次递增 300ms。每次重发前把接收缓冲区的残留字节读干净不然上一次的帧尾会干扰本次的帧头识别。重发的触发条件只有两个超时未收到完整帧、校验和错误。如果是表端返回了异常应答帧说明通信链路是通的问题是数据标识或命令本身这时候重发没有意义应该直接记录错误日志。完整的一条读数据流程应该是组帧、发送、读完整帧、校验和检查、解析数据域、超时则重发。把这几步封装成一个readMeterData(address, di)方法上层调用时只需要关心表号和 DI不用关心串口细节后续做批量采集会省很多事。4. 完整解析从裸报文到业务数据的一条龙处理4.1 数据域解析电能量、电压电流、功率数据的标识映射收到响应帧且校验和通过之后真正有价值的是数据域。DLT645-2007 的数据域结构是DI 4 字节加上实际数据再加 1 字节数据格式标识。数据格式标识高 4 位表示小数位数低 4 位表示倍率和单位这一字节决定了 BCD 码数据要移动几位小数点。以电能量数据为例响应帧的数据域类似00 00 00 00 12 34 56 03其中前面 4 字节是 DI中间12 34 56是 BCD 码表示的电能量原始值 123456最后一个字节03的高 4 位是 0表示没有小数位不对高 4 位是 0 的话说明这个表计把格式字节定义成低 4 位表示小数位不同厂商实现有差异。为了兼容各种表计我在解析时会把格式字节完整打印出来先观察几帧数据再定标。电价数据的解析我一般这样做// 解析BCD码数据并处理小数位 public static BigDecimal parseBcdValue(byte[] data, int valueStart, int valueLen) { StringBuilder sb new StringBuilder(); for (int i valueStart; i valueStart valueLen; i) { sb.append(String.format(%02X, data[i])); } // 格式字节紧跟在数据后面高4位是小数位数 int scale (data[valueStart valueLen] 4) 0x0F; return new BigDecimal(sb.toString()).movePointLeft(scale); }逻辑说明先把 BCD 字节按十六进制拼成字符串比如12 34 56拼成 123456再根据格式字节高 4 位移动小数点。假设格式字节是 0x03高 4 位是 0低 4 位是 3表示无小数位最终值是 123456如果格式字节是 0x33高 4 位是 3那结果就是 123.456单位 kWh。实际项目中电压电流这类瞬时量有的表返回 2 字节 BCD有的返回 3 字节解析前先看数据长度 L 减去 4 再减 1剩下才是真正的数据字节数。电压电流这类数据不需要格式字节处理同样需要只是单位不同。A 相电压数据标识 02010100 对应的数据域可能是02 01 01 00 22 05 01其中22 05是 BCD 值 2205格式字节 0x01 最低位表示 1 位小数解析结果就是 220.5V。不同协议版本对格式字节的编码略有差别但「BCD 拼串移小数点」这个思路是通用的。4.2 异常应答表端返回的报错帧要单独处理电表收到不认识的 DI、写操作被拒绝、表内数据异常时返回的应答帧不是正常数据帧。这类帧的数据域第一个字节通常以 0xEE 开头后面跟错误信息字节。如果不加判断直接走正常解析流程结果就是解析出乱码数据甚至把错误码当成电能量入库。处理异常应答的代码逻辑很简单但很多人都忘了写public static boolean isErrorFrame(byte[] frame) { // 响应帧数据域从索引10开始检查第一字节是否是0xEE if (frame.length 11) return true; return (frame[10] 0xFF) 0xEE; }收到的帧先过这个判断是错误帧就直接记录表号、DI 和错误码不进入业务解析。错误码本身也是信息比如 0xEE 加后续字节表示不同错误原因记录到日志里查现场问题时会非常有用。这个判断放在校验和之后、数据域解析之前位置别放错。4.3 数据长度超过单帧上限时多帧数据和后续读命令单帧数据域长度 L 只有 1 字节最大值 255但实际场景里一次读几十个数据项很常见。协议的处理方式是拆帧首帧数据域塞满后控制码的 D5 位置 1 表示还有后续帧主站收到后发读后续数据命令 C1表端再返回下一段数据。拼接逻辑的伪代码如下Listbyte[] frames new ArrayList(); byte[] first readMeterData(address, di); frames.add(first); while ((first[8] 0x20) ! 0) { // D51 说明还有后续 byte[] next sendContinueRead(address, di); // 发C1读后续 if (next null) break; // 超时就停 frames.add(next); first next; // 看这帧是否还有后续标志 } // 数据域拼接每帧去掉帧头帧尾只拼数据域部分 ByteArrayOutputStream dataStream new ByteArrayOutputStream(); for (byte[] f : frames) { int len f[9] 0xFF; dataStream.write(f, 10, len); // 从数据域开始追加 } byte[] fullData dataStream.toByteArray();拼接时注意每帧的数据域都要去掉 DI不对协议规定后续帧的数据域要么带相同 DI要么只带长度不带 DI不同厂商实现不一样。我见过一种表后续帧数据域从第 10 字节开始直接是数据不带 DI这时候每帧长度 L 比首帧少 4。稳妥的做法是收到后续帧先看 L 和首帧 L 的差值差 4 说明该帧没带 DI拼接时跳过前 4 字节。多帧拼接最容易出错的地方是字节偏移。每帧的最小长度是 12 字节但带不同长度数据时总帧长不一样拼接时不要把帧头地址域这些也算进数据区。建议拼完后打印一下fullData.length和首帧 L、后续帧 L 加总的结果对一下对不上说明偏移算错了。5. 避坑指南串口通信和协议实现里的五个典型翻车现场5.1 现象发了 FE FE FE FE 68 地址 68 C0 04 DI 之后表完全没响应这大概是我见过最多的现场问题。排查步骤按优先级排先确认 RS-485 的 A、B 两根线没有接反这是电气层最常见的低级错误用万用表量空闲态电压正常应该在 1.5V 到 5V 之间接反时量出来是负值或者接近 0。然后确认波特率和校验位是不是偶校验很多调试工具默认是 NONE 校验而协议要求 EVEN。最后确认地址域补位字节是不是 AA07 版协议对不足 12 位表号的规定是补 AA不是补 00这地方的错误会让表直接丢弃整帧。解决方式是用串口调试助手手动发一帧最简单指令排除代码因素后再把同样的字节流放到 Java 程序里发逐步收窄问题范围。5.2 现象读回来的帧总是校验和错误而且每次错的位数还不一样大概率是 Java 有符号数处理问题。直接sum b会把 0x80 以上的字节当成负数累加比如校验和实际是 0x50代码算出来却是 0xFFFFFF50 或别的值。这是协议解析里最容易自我怀疑的问题因为很多人会觉得自己算法写错了反复排查帧结构其实只是漏了 0xFF。解决方式简单粗暴累加前统一b 0xFF算完再 0xFF截断低 8 位。建议把这个逻辑抽成工具方法不要在每个组帧的地方重复写漏一处就是一个 bug。5.3 现象地址域从报文里解析出来总是反的对不上表号地址域低字节在前这个「反」是协议规定的不是设备坏了。表号 123456789012报文里地址域是 12 90 78 56 34 12解析时倒序遍历才是正序。还有个隐藏坑有的表号不足 12 位地址域里高位补了 AA解析后字符串开头会出现 AA不处理就拼接进数据库台账匹配永远失败。解决方式是在地址解析方法里加一个循环把开头连续的 AA 全部吞掉。我见过最夸张的案例是某现场表号只有 8 位地址域是 12 34 56 78 AA AA倒序后变成 AA AA 78 56 34 12处理掉 AA 后表号才是 78563412这个顺序搞错会让你误以为换了一块表。5.4 现象帧结构看起来完整但按长度字段截取数据时总多或者总少数据域长度 L 的语义是「从 DI 开始到格式字节结束」的总长度包含 DI 的 4 字节、数据本体和格式字节。很多人把 L 理解成「数据本体的长度」于是截取时少截 5 字节解析结果自然不对。另外组帧时 L 填错也会引发联动错误L 错了校验和覆盖范围就错了帧尾 CS 对不上表端直接不响应。解决方式是建立一个帧长度自检公式总帧长等于 1 起始符加 6 地址域加 1 再确认符加 1 控制码加 1 长度加 L 加 1 校验和加 1 结束符即 12 加 L 字节。收帧后先用这个公式验总长度对不上就直接丢弃不要硬解析。5.5 现象程序运行一段时间后偶发无响应线程栈卡在串口读上这是串口编程最常见的稳定性问题。jSerialComm 的 readTimeout 如果设置时机不对或者设备被系统挂起readBytes 会一直阻塞不返回外层超时逻辑完全失效。我自己的处理方式是读操作不进阻塞模型改为固定截止时间加轮询读取配合一个看门狗线程超过 5 秒没有任何数据就强制关闭串口重新打开。重开时注意先 closePort 再创建新对象不要复用旧实例旧对象的内部状态已经乱了复用只会越搞越糟。这个兜底逻辑放在生产环境的采集程序里尤其重要没有它一个串口异常能让整个采集服务挂掉。这些坑有一个共性都在协议文档之外靠读文档读不出来只能在实际调试中逐个踩过才知道。把这五个现象贴到代码注释里作为排查清单后来维护这个项目的人会感激你。这个清单现在也是我每次换新表型做适配时必查的前五项问题。6. 进阶广播校时和长数据读取能顺手做的就别省6.1 广播校时没有业务数据的报文广播校时是 DLT645-2007 里最特殊的报文地址域固定为 6 个 AA控制码 D6数据域是 6 字节 BCD 码的日期时间依次是年、月、日、时、分、秒比如 20240815103045 编码成24 08 15 10 30 45。这个报文发出去后表端不回响应主站也不需要等直接每隔一段时间发一次即可。校时这个功能很容易被忽略但表内时钟偏差超过一定范围后冻结电量数据的时标会乱后续做分时计费统计时对不上账。建议每天零点后对所有表做一次广播校时成本极低收益是数据时标干净。6.2 长数据读取C1 后续帧的边界条件前面提到数据超过 255 字节时会拆帧这里补充一个边界C1 读后续命令的数据域可以只带 DI也可以带 DI 加序号不同厂商对序号字段的定义不同。我接触过的表里有的表对 C1 命令必须在数据域带上首帧的 DI 才会响应有的表不带也能响应。遇到不响应的情况先用串口工具手动发一帧 C1 到表端观察返回的是正常数据帧还是错误帧再微调数据域内容这个过程只能靠试没有文档能覆盖所有厂商的差异。6.3 把解析器做成无状态服务的习惯解析代码和串口通信代码一定要拆开。通信层负责收发字节流解析层只接收一个完整的 byte[] 帧输出一个MeterData对象不持有任何串口状态。这样做的最大好处是并发采集多台表时不会串数据多线程环境下每个线程各持一个 SerialPort 实例但解析器只有一个静态入口帧数据不会互相污染。另外无状态的解析器很容易做单元测试预先构造几帧正确的报文和几帧错误的报文跑一遍用例就知道解析逻辑对不对不用每次改代码都接真实硬件验证。从那以后我每次改协议解析代码都强制先跑一遍「预置报文比对期望结果」的用例通过后再碰真实串口这个习惯帮我挡掉了至少一半的回归问题。希望这套思路对你的 DLT645 接入工作也有帮助项目源码里把串口封装和协议解析拆成了两个独立模块下载下来对着实际报文跑一遍比看任何文档都直观。本文还有配套的精品资源点击获取
简介面向需要与电能表开展串口通信开发的Java工程师这份源码实现了DLT645-2007电力行业标准协议的数据帧解析、命令编解码、CRC校验与应答处理适用于远程抄表、用电信息采集与设备监控等典型场景可帮助开发者快速落地串口通信模块并缩短联调周期。压缩包共11个文件包含3个Java源文件、3个class编译文件、2个properties配置文件、1个xml工程配置、1个iml模块文件与1个jsp页面包大小约20KB整体结构精简导入工程后即可对照源码学习。目前已有2461人学习下载。通过阅读和调试这套源码可以重点掌握协议中地址域、控制域、数据域的拆分技巧大端与小端字节序的转换方法以及RXTX、JSerialComm等串口库的选型与异常处理思路同时源码中完整的命令对应关系和应答帧处理逻辑也为移植到其他采集系统提供了便利适合电力计量领域的Java开发者以及初次接触DLT645协议的读者作为参考。1. Java 解析 DLT645-2007先搞清这个协议值不值得折腾第一次接触 DLT645-2007 的时候我手里只有一个 USB 转 485 的调试线、一块多功能电能表和一沓打印出来的协议文档花了一个多星期才把第一帧完整报文读出来。Java 版 DLT645-2007 电能表协议解析源码解决的核心问题是把串口上那串十六进制字节流换算成可用的电能量、电压、电流和功率数据适用于集中抄表、能耗监测平台、边缘采集网关这类场景。协议本身不复杂真正耗时间的永远是串口接线、地址域字节序和超时重试这些细碎问题代码只占三成调试占七成。2. DLT645-2007 帧结构从字节流里抠出电表地址和电能数据2.1 帧头和地址域0x68 之后地址是反着读的DLT645-2007 的帧结构很固定每帧从起始符 68H 开始到结束符 16H 结束中间依次是地址域、控制码、数据域长度、数据域和校验和。把帧结构列成一张表后面所有解析代码都围绕这张表展开帧成分字节数说明起始符1固定 0x68地址域6表号BCD 码低字节在前控制码1区分读、写、广播校时等操作数据域长度 L1数据域总字节数数据域L数据标识 DI 加实际数据校验和 CS1从起始符到校验和前一字节累加取低 8 位结束符1固定 0x16起始符 68H 在报文中会出现两次第一次是帧起始第二次是地址域结束后的再确认很多解析代码直接把第二个 68 当作地址域的终止标志。地址域是最大的坑电表铭牌上的表号是一串十进制数字但协议要求按 BCD 码编码并且低字节在前发送。比如表号 123456789012先按 BCD 拆成 12 34 56 78 90 12 六个字节再倒序放到帧里所以报文里的地址域实际是 12 90 78 56 34 12。解析时要把这 6 字节倒过来拼字符串才能得到人眼认识的表号。如果表号不足 12 位协议规定地址域高位补 AA这一点很容易被忽略。我见过有人把补位字节当作用户数据解析最后表号字符串里多出 4 个 A和数据库里的台账永远匹配不上。地址域长度不足 6 字节时按协议补 AA 而不是补 00记住这个前提后面排查地址对不上会省很多时间。从报文里提取表号代码很直接// 从完整报文帧中提取电表地址 public static String parseAddress(byte[] frame) { StringBuilder sb new StringBuilder(); for (int i 6; i 1; i--) { // 地址域在帧中的索引是 1-6传输顺序低字节在前 sb.append(String.format(%02X, frame[i])); } String address sb.toString(); // 表号不足12位时协议规定高位补AA解析时去掉 while (address.startsWith(AA)) { address address.substring(2); } return address; }逻辑说明地址域从索引 1 开始占 6 字节倒序遍历即完成高低字节反转String.format(%02X)把每个字节转成两位大写十六进制。因为补位只出现在正序字符串的开头用while循环持续去掉开头的 AA直到遇到真正的表号数字。这里注意只能判断 AA不能去掉以数字开头的正常表号。2.2 控制码和数据标识C0 读数据、D0 写数据DI 才是真正要的东西控制码决定这一帧要干什么主站请求时常见控制码值如下表控制码功能使用场景0xC0读数据读取电能量、电压、电流等0xC1读后续数据数据长度超过单帧上限时续读0xD0写数据下发费率、表计参数0xD6广播校时对全表计统一校时表端正常应答时控制码会按协议组合出应答值常见是 0x81 开头具体映射以协议附录为准。解析时不要写死「控制码等于 C0 才是读数据」因为同一帧从不同厂商表计回来可能带应答位判断读写方向要看最高位判断功能要看低 5 位这样才能兼容不同厂家的实现差异。数据标识 DI 是更关键的东西它决定数据域里装的是什么。DI 由 4 个字节组成DI0 到 DI3传输时同样低字节在前。常用数据标识的映射关系如下数据项DI0DI1DI2DI3报文字节序组合有功总电能0000000000 00 00 00正向有功总电能0100000000 00 00 01反向有功总电能0200000000 00 00 02A 相电压0001010202 01 01 00A 相电流0002020202 02 02 00比如要读 A 相电压DI 逻辑值是 02010100组帧时按低字节在前实际发送顺序是 00 01 01 02数据长度 L 就是 4。看不懂 DI 之前报文就是一堆十六进制数字看懂 DI 之后每一帧都能对应到具体业务数据这一步绕不过去。控制码和数据标识的解析放一起写因为在报文中它们紧挨着一个字节是操作类型紧接着的 4 字节是操作对象public static FrameInfo parseFrameHeader(byte[] frame) { FrameInfo info new FrameInfo(); // 帧索引: 0起始符, 1-6地址域, 7第二个68, 8控制码, 9长度 info.controlCode frame[8]; int length frame[9] 0xFF; // 数据域从索引10开始前4字节是DI info.di0 frame[10] 0xFF; info.di1 frame[11] 0xFF; info.di2 frame[12] 0xFF; info.di3 frame[13] 0xFF; info.hasMore (info.controlCode 0x20) ! 0; // D5位1表示有后续帧 return info; }逻辑说明从固定偏移量取出控制码和数据长度再取 4 字节 DI。length 0xFF是必须的因为数据长度最大 255Java 的 byte 会把它当负数。hasMore用到控制码的 D5 位这一位在长数据拆分场景里非常关键后面讲多帧拼接时会再次用到。2.3 校验和 CS从第 2 字节加到倒数第 2 字节取低 8 位校验和算法在协议里写得很明确但实现时翻车率极高。规则是从帧的第一个 68H 开始到校验和前一字节为止所有字节做累加结果只取低 8 位。覆盖范围包括起始符、地址域、第二个 68、控制码、数据长度、数据域总共 9 加 L 个字节不包含结束符 16H。很多初写解析的人在校验和这里踩坑核心原因是 Java 的 byte 是有符号类型。一个字节 0x80 在 Java 里转成 int 是 -128直接累加就会把整个校验和带偏所以每个字节参与累加前都要先做 0xFF转成无符号整数。// 计算校验和frameBody 是从起始符68到数据域结束的完整区间 public static byte calcChecksum(byte[] frameBody) { int sum 0; for (byte b : frameBody) { sum (b 0xFF); // 消除Java有符号字节的影响 } return (byte) (sum 0xFF); }逻辑说明sum是 int 类型累加过程中可能超过 255但只要在最后取 0xFF高位溢出自然丢弃结果就是协议规定的低 8 位。返回时强转回 byte后续和帧尾的校验和字节直接比较即可。实际校验一帧报文时我习惯把「算出的 CS」和「帧里的 CS」都打印出来做对比而不是只给一个 true/false 结果。差距为 0 说明帧结构正确差距不为 0 时打印值能直接告诉你偏了多少排查效率高很多。这个习惯在做串口调试时极其有用因为很多电表固件对校验和的处理有细微差别光看布尔结果根本不知道是算错还是收错。另外要注意计算起点是帧头 68H前面如果有 FE 前导字节不要一起加进去。前导字节是通信时序用的不属于帧内容加了之后校验和必错。3. 串口层实战用 jSerialComm 把报文发出去并收回来3.1 串口参数波特率 2400、数据位 8、校验位偶校验、停止位 1DLT645-2007 的物理层参数是协议写死的默认 2400bps8 数据位偶校验 EVEN1 停止位。这几个参数在串口通信里属于「必须一致才能通信」的硬条件两端任何一项不一致收到的就是乱码或者干脆没响应。有些老电表可以手动改成 9600但现场如果没有特殊要求保持协议默认值最稳妥。Java 侧操作串口我一般用 jSerialComm比 RXTX 维护活跃、API 也更简洁Windows 和 Linux 下都能跑。打开一个串口的完整配置如下import com.fazecast.jSerialComm.SerialPort; SerialPort port SerialPort.getCommPorts()[0]; // 实际项目要按名称匹配 port.setBaudRate(2400); port.setNumDataBits(8); port.setNumStopBits(SerialPort.ONE_STOP_BIT); port.setParity(SerialPort.EVEN_PARITY); port.setReadTimeout(1000); if (!port.openPort()) { throw new RuntimeException(串口打开失败检查权限和占用); }参数说明波特率 2400 是协议默认不建议轻易改动数据位 8、偶校验、停止位 1 三项必须和电表侧一致。openPort()返回 false 时原因基本只有三个端口被其他进程占用、Linux 下当前用户没有 dialout 组权限、设备不存在。Linux 下排查权限问题最快的方式是执行ls -l /dev/ttyUSB0看所属组然后用sudo usermod -aG dialout 当前用户名把自己加进 dialout 组再重新登录。选择串口不建议写死端口名。Windows 下 COM3 可能因为插拔换了编号Linux 下/dev/ttyUSB0也可能变成/dev/ttyUSB1。我一般的做法是遍历SerialPort.getCommPorts()把每个端口的名字打印出来启动时用配置文件指定避免每次换环境都改代码重新编译。3.2 发送读数据命令组帧、发送、等响应的完整代码组帧是协议解析的第一步。完整读数据请求帧包含前导字节、起始符、地址域、第二个 68、控制码、长度、数据标识、校验和、结束符。前导字节 FE 建议发 4 个有些表 2 个就能响应4 个是兼容性最好的选择但不要发太多发多了有的表反而会判定为帧错误。// 组一帧读数据请求addressHex是表号字符串di是4字节数据标识 public byte[] buildReadFrame(String addressHex, int[] di) { ByteBuffer buf ByteBuffer.allocate(32); for (int i 0; i 4; i) { buf.put((byte) 0xFE); // 前导字节 } buf.put((byte) 0x68); // 起始符 byte[] addr new byte[6]; int addrLen addressHex.length() / 2; for (int i 0; i 6; i) { if (i addrLen) { addr[i] (byte) Integer.parseInt( addressHex.substring(i * 2, i * 2 2), 16); } else { addr[i] (byte) 0xAA; // 不足12位补AA } } buf.put(addr); // 地址域6字节 buf.put((byte) 0x68); // 第二个起始符 buf.put((byte) 0xC0); // 读数据请求 buf.put((byte) 0x04); // L 4DI占4字节 for (int i 3; i 0; i--) { buf.put((byte) di[i]); // DI低字节在前 } byte[] body Arrays.copyOfRange(buf.array(), 4, buf.position()); byte cs calcChecksum(body); // 校验和从68开始算 buf.put(cs); buf.put((byte) 0x16); byte[] frame new byte[buf.position()]; System.arraycopy(buf.array(), 0, frame, 0, frame.length); return frame; }逻辑说明表号字符串按两位一组解析成十六进制字节不足 6 字节时高位补 AA。DI 数组传入的是逻辑顺序发送时for (int i 3; i 0; i--)完成低字节在前反转。校验和计算起点是整个帧的第 4 个字节也就是起始符 68H不包含前面的 FE 前导字节所以这里把Arrays.copyOfRange(buf.array(), 4, buf.position())作为校验和入参而不是从头开始。发送和接收要配合好。发送用port.writeBytes(frame, frame.length)写入后立刻进入读响应阶段。这里有个经验不要发送后马上 sleep 再读而是直接进入带超时的读循环让内核缓冲区自然积累数据。很多电表的响应时间在 20 到 200 毫秒之间如果固定 sleep 200ms一部分表响应慢就会漏掉。3.3 拆帧和重发机制超时重试的边界条件串口读响应最大的坑是数据会分片到达。一次readBytes可能只读到半个帧也可能读到一个半帧绝不能假设一次 read 就是完整报文。收到数据后要先把所有字节拼进一个缓冲区然后反复找结束符 0x16 判断帧是否完整。public byte[] readFullFrame(SerialPort port, long timeoutMs) throws IOException { ByteArrayOutputStream buffer new ByteArrayOutputStream(); long deadline System.currentTimeMillis() timeoutMs; while (System.currentTimeMillis() deadline) { byte[] chunk new byte[128]; int n port.readBytes(chunk, chunk.length); if (n 0) { buffer.write(chunk, 0, n); // 从缓冲区里找帧头68和帧尾16帧尾存在即认为完整 byte[] all buffer.toByteArray(); int start findFrameStart(all); // 找第一个0x68 int end findLastFrameEnd(all); // 找最后一个0x16 if (start 0 end start) { return Arrays.copyOfRange(all, start, end 1); } } Thread.sleep(20); } return null; // 超时返回null上层决定是否重发 }逻辑说明外层用System.currentTimeMillis()做整体截止时间内层每次最多等 20 毫秒再循环既不会忙等导致 CPU 空转也不会因为单次 read 超时丢数据。findFrameStart从第一个 0x68 开始找帧头不固定读第 0 字节因为串口缓冲区里可能有上一次的残留数据。超时重发策略我从实践中总结出来的经验是重试 3 次第 1 次间隔 200ms之后每次递增 300ms。每次重发前把接收缓冲区的残留字节读干净不然上一次的帧尾会干扰本次的帧头识别。重发的触发条件只有两个超时未收到完整帧、校验和错误。如果是表端返回了异常应答帧说明通信链路是通的问题是数据标识或命令本身这时候重发没有意义应该直接记录错误日志。完整的一条读数据流程应该是组帧、发送、读完整帧、校验和检查、解析数据域、超时则重发。把这几步封装成一个readMeterData(address, di)方法上层调用时只需要关心表号和 DI不用关心串口细节后续做批量采集会省很多事。4. 完整解析从裸报文到业务数据的一条龙处理4.1 数据域解析电能量、电压电流、功率数据的标识映射收到响应帧且校验和通过之后真正有价值的是数据域。DLT645-2007 的数据域结构是DI 4 字节加上实际数据再加 1 字节数据格式标识。数据格式标识高 4 位表示小数位数低 4 位表示倍率和单位这一字节决定了 BCD 码数据要移动几位小数点。以电能量数据为例响应帧的数据域类似00 00 00 00 12 34 56 03其中前面 4 字节是 DI中间12 34 56是 BCD 码表示的电能量原始值 123456最后一个字节03的高 4 位是 0表示没有小数位不对高 4 位是 0 的话说明这个表计把格式字节定义成低 4 位表示小数位不同厂商实现有差异。为了兼容各种表计我在解析时会把格式字节完整打印出来先观察几帧数据再定标。电价数据的解析我一般这样做// 解析BCD码数据并处理小数位 public static BigDecimal parseBcdValue(byte[] data, int valueStart, int valueLen) { StringBuilder sb new StringBuilder(); for (int i valueStart; i valueStart valueLen; i) { sb.append(String.format(%02X, data[i])); } // 格式字节紧跟在数据后面高4位是小数位数 int scale (data[valueStart valueLen] 4) 0x0F; return new BigDecimal(sb.toString()).movePointLeft(scale); }逻辑说明先把 BCD 字节按十六进制拼成字符串比如12 34 56拼成 123456再根据格式字节高 4 位移动小数点。假设格式字节是 0x03高 4 位是 0低 4 位是 3表示无小数位最终值是 123456如果格式字节是 0x33高 4 位是 3那结果就是 123.456单位 kWh。实际项目中电压电流这类瞬时量有的表返回 2 字节 BCD有的返回 3 字节解析前先看数据长度 L 减去 4 再减 1剩下才是真正的数据字节数。电压电流这类数据不需要格式字节处理同样需要只是单位不同。A 相电压数据标识 02010100 对应的数据域可能是02 01 01 00 22 05 01其中22 05是 BCD 值 2205格式字节 0x01 最低位表示 1 位小数解析结果就是 220.5V。不同协议版本对格式字节的编码略有差别但「BCD 拼串移小数点」这个思路是通用的。4.2 异常应答表端返回的报错帧要单独处理电表收到不认识的 DI、写操作被拒绝、表内数据异常时返回的应答帧不是正常数据帧。这类帧的数据域第一个字节通常以 0xEE 开头后面跟错误信息字节。如果不加判断直接走正常解析流程结果就是解析出乱码数据甚至把错误码当成电能量入库。处理异常应答的代码逻辑很简单但很多人都忘了写public static boolean isErrorFrame(byte[] frame) { // 响应帧数据域从索引10开始检查第一字节是否是0xEE if (frame.length 11) return true; return (frame[10] 0xFF) 0xEE; }收到的帧先过这个判断是错误帧就直接记录表号、DI 和错误码不进入业务解析。错误码本身也是信息比如 0xEE 加后续字节表示不同错误原因记录到日志里查现场问题时会非常有用。这个判断放在校验和之后、数据域解析之前位置别放错。4.3 数据长度超过单帧上限时多帧数据和后续读命令单帧数据域长度 L 只有 1 字节最大值 255但实际场景里一次读几十个数据项很常见。协议的处理方式是拆帧首帧数据域塞满后控制码的 D5 位置 1 表示还有后续帧主站收到后发读后续数据命令 C1表端再返回下一段数据。拼接逻辑的伪代码如下Listbyte[] frames new ArrayList(); byte[] first readMeterData(address, di); frames.add(first); while ((first[8] 0x20) ! 0) { // D51 说明还有后续 byte[] next sendContinueRead(address, di); // 发C1读后续 if (next null) break; // 超时就停 frames.add(next); first next; // 看这帧是否还有后续标志 } // 数据域拼接每帧去掉帧头帧尾只拼数据域部分 ByteArrayOutputStream dataStream new ByteArrayOutputStream(); for (byte[] f : frames) { int len f[9] 0xFF; dataStream.write(f, 10, len); // 从数据域开始追加 } byte[] fullData dataStream.toByteArray();拼接时注意每帧的数据域都要去掉 DI不对协议规定后续帧的数据域要么带相同 DI要么只带长度不带 DI不同厂商实现不一样。我见过一种表后续帧数据域从第 10 字节开始直接是数据不带 DI这时候每帧长度 L 比首帧少 4。稳妥的做法是收到后续帧先看 L 和首帧 L 的差值差 4 说明该帧没带 DI拼接时跳过前 4 字节。多帧拼接最容易出错的地方是字节偏移。每帧的最小长度是 12 字节但带不同长度数据时总帧长不一样拼接时不要把帧头地址域这些也算进数据区。建议拼完后打印一下fullData.length和首帧 L、后续帧 L 加总的结果对一下对不上说明偏移算错了。5. 避坑指南串口通信和协议实现里的五个典型翻车现场5.1 现象发了 FE FE FE FE 68 地址 68 C0 04 DI 之后表完全没响应这大概是我见过最多的现场问题。排查步骤按优先级排先确认 RS-485 的 A、B 两根线没有接反这是电气层最常见的低级错误用万用表量空闲态电压正常应该在 1.5V 到 5V 之间接反时量出来是负值或者接近 0。然后确认波特率和校验位是不是偶校验很多调试工具默认是 NONE 校验而协议要求 EVEN。最后确认地址域补位字节是不是 AA07 版协议对不足 12 位表号的规定是补 AA不是补 00这地方的错误会让表直接丢弃整帧。解决方式是用串口调试助手手动发一帧最简单指令排除代码因素后再把同样的字节流放到 Java 程序里发逐步收窄问题范围。5.2 现象读回来的帧总是校验和错误而且每次错的位数还不一样大概率是 Java 有符号数处理问题。直接sum b会把 0x80 以上的字节当成负数累加比如校验和实际是 0x50代码算出来却是 0xFFFFFF50 或别的值。这是协议解析里最容易自我怀疑的问题因为很多人会觉得自己算法写错了反复排查帧结构其实只是漏了 0xFF。解决方式简单粗暴累加前统一b 0xFF算完再 0xFF截断低 8 位。建议把这个逻辑抽成工具方法不要在每个组帧的地方重复写漏一处就是一个 bug。5.3 现象地址域从报文里解析出来总是反的对不上表号地址域低字节在前这个「反」是协议规定的不是设备坏了。表号 123456789012报文里地址域是 12 90 78 56 34 12解析时倒序遍历才是正序。还有个隐藏坑有的表号不足 12 位地址域里高位补了 AA解析后字符串开头会出现 AA不处理就拼接进数据库台账匹配永远失败。解决方式是在地址解析方法里加一个循环把开头连续的 AA 全部吞掉。我见过最夸张的案例是某现场表号只有 8 位地址域是 12 34 56 78 AA AA倒序后变成 AA AA 78 56 34 12处理掉 AA 后表号才是 78563412这个顺序搞错会让你误以为换了一块表。5.4 现象帧结构看起来完整但按长度字段截取数据时总多或者总少数据域长度 L 的语义是「从 DI 开始到格式字节结束」的总长度包含 DI 的 4 字节、数据本体和格式字节。很多人把 L 理解成「数据本体的长度」于是截取时少截 5 字节解析结果自然不对。另外组帧时 L 填错也会引发联动错误L 错了校验和覆盖范围就错了帧尾 CS 对不上表端直接不响应。解决方式是建立一个帧长度自检公式总帧长等于 1 起始符加 6 地址域加 1 再确认符加 1 控制码加 1 长度加 L 加 1 校验和加 1 结束符即 12 加 L 字节。收帧后先用这个公式验总长度对不上就直接丢弃不要硬解析。5.5 现象程序运行一段时间后偶发无响应线程栈卡在串口读上这是串口编程最常见的稳定性问题。jSerialComm 的 readTimeout 如果设置时机不对或者设备被系统挂起readBytes 会一直阻塞不返回外层超时逻辑完全失效。我自己的处理方式是读操作不进阻塞模型改为固定截止时间加轮询读取配合一个看门狗线程超过 5 秒没有任何数据就强制关闭串口重新打开。重开时注意先 closePort 再创建新对象不要复用旧实例旧对象的内部状态已经乱了复用只会越搞越糟。这个兜底逻辑放在生产环境的采集程序里尤其重要没有它一个串口异常能让整个采集服务挂掉。这些坑有一个共性都在协议文档之外靠读文档读不出来只能在实际调试中逐个踩过才知道。把这五个现象贴到代码注释里作为排查清单后来维护这个项目的人会感激你。这个清单现在也是我每次换新表型做适配时必查的前五项问题。6. 进阶广播校时和长数据读取能顺手做的就别省6.1 广播校时没有业务数据的报文广播校时是 DLT645-2007 里最特殊的报文地址域固定为 6 个 AA控制码 D6数据域是 6 字节 BCD 码的日期时间依次是年、月、日、时、分、秒比如 20240815103045 编码成24 08 15 10 30 45。这个报文发出去后表端不回响应主站也不需要等直接每隔一段时间发一次即可。校时这个功能很容易被忽略但表内时钟偏差超过一定范围后冻结电量数据的时标会乱后续做分时计费统计时对不上账。建议每天零点后对所有表做一次广播校时成本极低收益是数据时标干净。6.2 长数据读取C1 后续帧的边界条件前面提到数据超过 255 字节时会拆帧这里补充一个边界C1 读后续命令的数据域可以只带 DI也可以带 DI 加序号不同厂商对序号字段的定义不同。我接触过的表里有的表对 C1 命令必须在数据域带上首帧的 DI 才会响应有的表不带也能响应。遇到不响应的情况先用串口工具手动发一帧 C1 到表端观察返回的是正常数据帧还是错误帧再微调数据域内容这个过程只能靠试没有文档能覆盖所有厂商的差异。6.3 把解析器做成无状态服务的习惯解析代码和串口通信代码一定要拆开。通信层负责收发字节流解析层只接收一个完整的 byte[] 帧输出一个MeterData对象不持有任何串口状态。这样做的最大好处是并发采集多台表时不会串数据多线程环境下每个线程各持一个 SerialPort 实例但解析器只有一个静态入口帧数据不会互相污染。另外无状态的解析器很容易做单元测试预先构造几帧正确的报文和几帧错误的报文跑一遍用例就知道解析逻辑对不对不用每次改代码都接真实硬件验证。从那以后我每次改协议解析代码都强制先跑一遍「预置报文比对期望结果」的用例通过后再碰真实串口这个习惯帮我挡掉了至少一半的回归问题。希望这套思路对你的 DLT645 接入工作也有帮助项目源码里把串口封装和协议解析拆成了两个独立模块下载下来对着实际报文跑一遍比看任何文档都直观。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
