简介：面向电力行业开发人员的DL/T698.45规约源代码RAR压缩包，聚焦电能信息采集与管理系统主站、采集终端及电能表之间的互操作性数据交换，适用于点对点、多点共线及一点对多点通信方式。协议强调面向对象建模与标准化通信，适合从事智能电网、用电信息采集或协议栈移植的工程师参考学习。包内共288个文件，以C源文件（119个.c）和头文件（85个.h）为主，辅以工程文件（.project/.cproject）、配置文件（.cfg）、编译脚本与少量辅助数据文件，整体大小仅1.93MB，便于本地阅读和工程调试。已有680人浏览学习，属于轻量、可直接查阅的协议实现样本。读者可对照源码梳理698.45的数据链路层、应用层流程、接口类与对象标识组织方式，也可在此基础上完成模块裁剪、二次开发或移植验证，对理解电力通信协议落地具有切实帮助。 做电力采集终端开发这么多年，手里过的规约不算少，从DL/T 645、101/104到Modbus都有涉猎，但要说让人从零开始最头疼的，还是DL/T 698.45这套面向对象的数据交换协议。标题里的"dlt698.45规约源代码"，正是我去年一个集中器项目里从无到有落地的产物——没有现成完整库、网上资料零散、标准文档啃起来费劲，只能自己写帧解析、APDU编解码、对象读写和安全认证。这篇博文就把我当时的代码架构、核心实现和排坑过程拿出来晒一晒，适合正在做电能表采集、集中器调试，以及从645规约往698.45迁移的嵌入式或上位机开发同行参考。
1. 整体认识：698.45规约到底在解决什么问题
1.1 它和DL/T 645、101/104规约的本质区别
很多同行第一次接触698.45时，都会下意识拿它和645对比。645规约是典型的点表驱动模式，要抄什么数据，直接按表地址+数据标识去读，一个标识对应一个固定含义。这种方式简单直接，但扩展性很差——新加一个业务功能，就得新定义一个数据标识，前后台都要同步升级。
101/104规约主要用在变电站和调度端的远动通信，链路层基于串口或TCP/IP，强调可靠性传输，数据组织方式是信息体地址+类型标识，适合遥测遥信遥控这种离散点表。而698.45走的是另一条路：面向对象建模。它把电表里的数据抽象成"对象"——比如电能量对象、测量点对象、负荷记录对象，每个对象有属性、方法和事件，通信时通过对象标识（OAD）定位属性，用GET、SET、ACTION这些服务去操作。
这种设计的好处是业务逻辑和通信协议解耦。表计厂商新增一类数据时，不需要修改协议本身，只需按规范定义新对象，主站端用通用解析框架就能兼容。对开发者的实际影响是：写698.45代码时，本质上是在构建一个"对象访问引擎"+TLV编码解码器，而不是堆一堆含义固定的报文分支。
1.2 为什么需要自己动手写源代码
市面上有没有698.45的现成协议栈？有，但问题不少。一是商业授权成本高，很多集中器厂家预算有限；二是可裁剪性差，底层平台从Linux到裸机RTOS都有，商业栈未必适配；三是黑盒交付，出了问题无法深入定位。自己写的好处是可以按项目特性灵活裁剪，比如只保留TLV编解码和连接管理，把复杂路由层去掉；出问题也能直接进底层查。
当然，自己写的前提是对标准有足够理解。DL/T 698.45系列标准分好几份，最核心的通信协议部分规定了链路层和应用层。动手前建议先把这几份标准的大纲过一遍，重点理解帧结构、APDU组成、对象模型这几块，后面写代码才不会被绕晕。
2. 帧结构与报文格式：一切解析的起点
2.1 固定帧头与长度域处理
698.45的帧结构整体上沿用了IEC 62056系列的核心思想，链路层用0x68作为启动字符，后面跟2字节长度域，然后是控制域、地址域、应用层数据（APDU），最后是校验和与结束字符0x16。第一次接触时，很容易把它和645格式搞混——645长度域是1字节，698.45是2字节，而且698.45的长度计数方式和645也有差别。
这块我在代码里吃过亏。刚开始按标准里的格式写长度计算，总是差2个字节，后来对比了参考报文才搞明白：长度域的值是从控制域开始到校验和之前的所有字节数，并不包括启动字符、长度域本身和结束字符。也就是说，读取时先拿到L，再从缓冲区跳过帧头后取L个字节，最后校验结束字符0x16。
// 帧解析核心代码示意 int parse_frame(uint8_t *buf, uint16_t len, frame_t *frame) { if (buf[0] != 0x68) return -1; uint16_t frame_len = (buf[2] << 8) | buf[1]; // 小端模式 if (frame_len < 4 || frame_len > FRAME_MAX_LEN) return -2; if (buf[3 + frame_len] != 0x16) return -3; // 结束字符检查 frame->ctrl = buf[3]; // 地址域解析 int pos = 4; frame->addr_len = get_address_len(&buf[pos]); memcpy(frame->addr, &buf[pos], frame->addr_len); pos += frame->addr_len; // 应用层APDU frame->apdu_len = frame_len - 1 - frame->addr_len; // 减去控制域和CS frame->apdu = &buf[pos]; // 校验和 uint8_t cs = calc_cs(&buf[3], frame_len - 1); if (cs != buf[3 + frame_len - 1]) return -4; return 0; }提示：地址域在698.45里是可变长度的，不是固定几个字节。它采用类似TLV的方式描述地址类型和长度，解析时必须按这个规则走，直接按固定长度偏移会解析出乱码。
2.2 应用层APDU结构拆解
应用层APDU是整个报文的核心，它由APCI（应用层协议控制信息）+用户数据组成。APCI在代码里通常用一个字节或几个字节的字段标识服务类型，比如CONNECT请求、GET请求、SET请求、ACTION请求、REPORT上报等。
APDU的解析我建议用"先路由后分发"的方式：先解析出服务类型字段，再根据类型走不同的解析函数。这样代码清晰，也方便后续扩展新服务。有一个容易被忽略的点：698.45引入了"分段传输"和"窗口机制"，大块数据（比如冻结数据、负荷曲线）可能被拆成多个帧传输。处理时要维护会话状态——等所有分段收齐后再拼装成完整APDU。我最初的实现没考虑这个，结果抄读日冻结数据时经常只解出前半段。
// APDU分发：伪代码 int handle_apdu(uint8_t *apdu, uint16_t len, session_t *session) { uint8_t service = apdu[0]; switch (service) { case CONNECT_REQUEST: return process_connect_request(&apdu[1], len - 1, session); case GET_REQUEST: return process_get_request(&apdu[1], len - 1, session); case SET_REQUEST: return process_set_request(&apdu[1], len - 1, session); case REPORT: return process_report(&apdu[1], len - 1, session); // ... } }3. 面向对象模型与TLV编解码：代码里的灵魂
3.1 对象标识（OAD）与TLV格式理解
698.45最核心的概念就是OAD（Object Attribute Descriptor），由对象标识+属性标识组成。比如要读取某测量点的当前总电能，需要构造对应的OAD，然后在GET请求里带上这个OAD，服务端才能定位到具体数据。
数据编码则采用TLV（Tag-Length-Value）方式。Tag标识数据类型，Length表示Value长度，Value就是实际数据。写TLV编码器时，我维护了一张类型映射表，把标准里定义的数据类型（如octet-string、int32、date_time等）对应到代码里的处理函数。编解码时最怕的是Tag判断错误——类型多了，很容易把8位整型和8位字符串混在一起。建议在编解码器里做充分的数据类型检查和长度校验，宁可多报错，也不要产生半解析的脏数据。
// TLV解码示意 tlv_t *tlv_decode(uint8_t *data, uint16_t len, uint16_t *consumed) { if (len < 2) return NULL; tlv_t *tlv = malloc(sizeof(tlv_t)); tlv->type = data[0]; tlv->length = data[1]; if (tlv->length > len - 2) { free(tlv); return NULL; // 长度异常 } tlv->value = &data[2]; *consumed = 2 + tlv->length; return tlv; }注意：某些复杂对象（比如电能表数据对象）不是一个TLV就能表示的，它内部往往嵌套了多个TLV子项。递归解析时一定要设置深度上限，防止畸形报文导致栈溢出或死循环。
3.2 读数据、写参数、控制命令的实现路径
在数据交互层面，698.45的GET请求对应"主站读表计属性"，SET对应"主站写表计参数"，ACTION对应"触发表计特定行为（如对时、跳闸、冻结）"。三者实现逻辑基本一致：构建APDU -> 链路层发送 -> 等待响应 -> 超时重试。
这里面最需要注意的就是响应报文是否带错误码。表计端如果收到无法处理的请求，会返回一个带有错误状态码的响应。如果代码里只处理正常数据，不解析错误码，现场排查问题时就会一脸懵：为什么超时了？为什么数据全是0？其实错误码早在响应报文里放着。我后来在每次GET/SET解析时都强制检查响应状态字段，并打印对应的错误描述，定位效率至少翻了一倍。
3.3 安全认证与加解密模块的集成
698.45在数据安全上引入了国密算法（SM2/SM4），用于身份认证和加密传输。做集中器时，通常需要集成加密芯片或者软件加解密库。这部分给开发带来的最大挑战不是算法本身——算法库都是现成的——而是密钥管理和协商流程。
具体来说，主站和终端要建立安全会话，走的是类似"握手"的流程：先交换证书或公钥，再用SM2协商出会话密钥，之后的数据用SM4加密。代码实现上，要在会话结构体里加一个安全上下文（上下文保存协商状态、密钥等），每个连接实例独立维护。我一开始想省事，把安全上下文放到全局变量里，结果两个主站同时连接时，互相串了密钥，报文全部解密失败。后来改成每个连接独立的安全上下文才解决。
4. 实操过程：写一个最小可用的698.45通信模块
4.1 开发环境与工具选型
我当时的开发环境是：C语言在嵌入式Linux上运行，编译工具链用arm-linux-gnueabihf-gcc，调试时用一台模拟主站的PC上位机加上Wireshark抓包。如果你是在Windows下开发上位机软件，C#或Python都能做，核心逻辑不变，只要把底层套接字换成对应语言的实现即可。
这里推荐两个强力辅助工具：一个是协议报文解析工具（用于逐字节分析帧格式），另一个是虚拟表计模拟器（用于在没有真实电表时模拟服务端响应）。实测下来，先用模拟器打通基本收发流程，再连真实表验证兼容性，是最省时间的路径。
4.2 最小通信流程：TCP接入、连接建立、读数据
698.45最常见的承载通道是TCP/IP。最小流程如下：
- 集中器作为客户端，主动连接主站或采集器的服务端；
- 连续发送CONNECT请求，表计回复CONNECT_RESPONSE，建立应用连接；
- 发送GET请求读取某个OAD指定的属性（比如总电能）；
- 收到GET_RESPONSE后解析TLV数据；
- RL（发布）连接，结束会话。
这段流程里我踩过一个大坑：TCP连接建立后，如果长时间不发数据，某些表计端会把连接断开，而集中器侧没有感知。后续GET请求全都失败。解决方式是在应用层加心跳或自动重连机制，检测到读写失败后主动重建连接，而不是依赖TCP的keepalive。
// 读取指定OAD的GET请求组装 int build_get_request(uint8_t *apdu, uint16_t oad[3]) { int pos = 0; apdu[pos++] = GET_REQUEST; // 服务类型 apdu[pos++] = (uint8_t)(oad[0] >> 8); // 对象标识高字节 apdu[pos++] = (uint8_t)(oad[0] & 0xFF); apdu[pos++] = (uint8_t)(oad[1] >> 8); // 属性2 apdu[pos++] = (uint8_t)(oad[1] & 0xFF); apdu[pos++] = oad[2]; // 属性2 // 后续可带请求类型、调用方法等 return pos; }4.3 数据上报与参数下发：日常运维环节
除了主站主动读取，终端侧还经常要做主动上报（比如事件上报、周期数据上报）。上报服务端主动发出的，就是REPORT请求，服务端收到后返回确认。实现上报时要注意：REPORT的数据格式有时候包含多个对象的多组属性，解析时务必用循环读TLV，而不是一次性固定取值，否则遇到多块上报就会丢数据。
参数下发（SET）也是高频操作，典型场景是改表计费率时段、修改最大需量等。SET请求里会嵌套多个TLV子结构，每个子结构对应一个属性值。写这段代码时，建议对照标准里的具体对象模板，一遍遍核对字节顺序和长度。我当时因为某个日期时间字段的字节序写反，导致费率时段始终写入失败，日志又看不出具体原因，耗了整整一天。
5. 常见问题与排查技巧实录
5.1 报文抓到了但解析不出来，怎么办
拿到一帧原始报文，先用报文解析工具做"字节级过滤"。如果自己的协议栈解析失败，优先检查三处：
| 检查点 | 典型原因 | 处理方式 |
|---|---|---|
| 长度域 | 长度计算多算或少算了控制域 | 手动数一遍从控制域到CS的字节数 |
| 地址域 | 地址长度取错导致APDU偏移错误 | 按地址域TAG判断长度，不硬编码 |
| CS校验 | 某些厂商实现不按标准校验 | 加日志打出CS，比对手工计算结果 |
我遇到的问题多数集中在长度域和地址域。因为不同厂商表计的地址编码格式会有细微差异（尤其是扩展地址位的处理），标准的描述又比较模糊。最好用一台已知正常的设备对照抓包，反推厂商的实现细节。
5.2 同一份代码，连接A厂表计正常，连接B厂表计失败
这种兼容性问题在电力规约开发里太常见了。原因多半是厂商对标准的某些可选字段处理不一致。比如连接请求里的密码字段格式、认证类型选择、TLV里时间格式的时区字段等。
排查思路是"二分对比"：用相同场景分别对A、B两个设备抓包，把两条CONNECT帧逐字节对比，找出差异点。差异点就是需要兼容的对象。我在项目里就靠这个办法解决了三次兼容性问题，全是密码字段长度和默认值不同导致的。
5.3 嵌入式平台上手写协议栈的优化建议
如果你的目标平台是资源受限的MCU，不要一上来就写一个全功能的698.45协议栈。建议按需裁剪：只支持TCP承载、只支持GET/SET/REPORT这三种服务、安全模块用硬件协处理器、把TLV解码器做成不含malloc的静态内存版本。这样代码量能控制在几千行以内，RAM占用也能压到很小。
提示：如果项目工期紧，又想快速验证协议逻辑，可以先在PC上用Python把编解码和报文流转调通，再翻译成C。Python的动态特性在排查TLV嵌套问题时效率极高，等逻辑确认无误后再做C版移植，整体反而更快。
6. 实测总结：这套源代码后续还能怎么扩展
最后再聊一点扩展方向。698.45这套面向对象的协议栈写完后，不仅能用于集中器抄表，还能改造成通用物联网设备的数据采集框架——把OAD映射成设备数据点模型，把GET/SET映射成远程读写接口，对上层业务完全屏蔽底层通信细节，这就是一个轻量级设备接入网关的雏形。
我在做完集中器项目后，把协议核心里与电表无关的部分抽成了一个独立的"TLV编解码库+对象模型引擎"，先后复用到水表、气表的数据采集中。如果你手里也有类似的多设备接入需求，我强烈建议在写698.45时就保持编解码层和业务层分离，后面会省很多事。踩过几次坑之后，我的体会是：规约开发拼的不是多高深的技术，而是对标准的耐心、对字节级的敏感，以及对各种厂商"个性化实现"的包容度。这些经验和代码，才是真正值钱的东西。
本文还有配套的精品资源，点击获取
