先说句大实话做电力抄表好些年的人听到 DL/T 645 就像看到老邻居听到 DL/T 698.45 则是一副“听说过但没深交”的表情。这两套协议说到底都是电表和数据采集系统之间的“对话规则”但一个是串口时代的“账本式”抄表一个是面向对象时代的“数据库式”通信。别看它们名字像一家人实际用起来差别大到会让你在调试现场怀疑人生。这篇文章就跟你把两套协议的结构差异、适用场景、选型思路和现场踩坑讲透哪怕你之前完全没接触过报文看完也能对着表格自己判断我这项目到底该用哪个。1. 两种协议的身世从串口账本到对象模型1.1 DL/T 645串口时代的“一页纸账本”DL/T 645 诞生得比较早现在主流用的是 1997 版和 2007 版。它最初就是为 RS-485 这种串行总线设计的主站通过一问一答的方式读写电表数据。你把电表想象成一个只有“电话号码本”的老式电话机主站想查电量先拨通这个表地址然后告诉它“我要读正向有功总电量”电表按固定格式把数据返回来。整个过程非常固定请求命令帧、应答数据帧没有多余的花样。这种设计的优势一个靠“简单”吃饭。帧格式紧凑字段固定一个不懂协议细节的工程师对着报文也能很快把数据解出来。电表端几乎不需要多少内存和计算能力单片机成本低通信速度快在窄带宽的 RS-485 总线上也能跑得很稳。正因如此从居民表到台区总表国网、南网早年的大量现场终端到表计之间几乎清一色是 DL/T 645。但它的问题也藏在“简单”里。因为所有数据都靠“数据标识”去索引而数据标识本身是二维平面的“菜单编号”业务一变就得重新扩充菜单比如要加一个非侵入式负荷识别数据就得多定义一堆标识。换句话说这套协议更像一本写满条目的固定账本能查什么、怎么查全看菜单里有没有这一项不容易扩展也没有内置“对象管理”的概念。1.2 DL/T 698.45带数据库和 API 的智能终端DL/T 698.45 的全称是《电能信息采集与管理系统 第4-5部分通信协议——面向对象的数据交换协议》2017 年发布在设计思路上参考了 IEC 62056 / DLMS/COSEM 的面向对象模型。它不再把电表当成一个只有固定菜单的账本而是把电表里的数据、功能抽象成一个个“对象”。每个对象有属性有方法还有事件你可以像操作数据库一样去查、去改、去订阅通知。举一个类比645 像你拿着一张有索引的纸质电话簿想找哪个号码都得去查目录698.45 则像一套带 RESTful API 的业务系统每个数据项都有明确的“对象 ID 属性 ID”你想取数据直接调接口系统还能主动推送告警。正因为设计了对象模型698.45 支持的通信链路也宽得多。它虽然可以在 RS-485 上跑也适配载波、微功率无线、以太网甚至蜂窝网络应用层的报文用 TLV 编解码数据表达更灵活还能定义复杂的请求和响应流程。很多新上的用电信息采集终端、能源控制器已经开始用 698.45 做主站到终端之间的规约而终端到电表这一级仍然保留 645形成一种“上层对象化、底层帧紧凑”的分层格局。1.3 为什么很多现场还在用 645说了 698.45 这么多优势你可能会问既然更先进为什么不一刀切换掉 645核心原因是存量和成本。全国在运的智能电表和采集终端数量以亿计绝大多数表计硬件和集中器固件按 645 设计直接上 698.45 意味着大规模换表、换主站、换终端投入不是一般大。另外用 645 做简单的“周期抄读费率冻结”本来就很成熟浪费资源去迁移未必划算。所以现实情况是新建的采集主站、省级计量中心或大型园区能源管理平台倾向直接用 698.45而低层设备、老旧台区、数据量稳定的定值抄读场景645 依然会长期存在。理解这个背景之后再去比较协议细节会发现很多差异其实是两种设计哲学的产物。2. 报文底层差异定长帧 vs TLV 编码2.1 645 的固定帧是怎么拼出来的我们先把 DL/T 645 的报文结构过一遍。一帧数据一般由这几个段组成帧起始符68H、地址域、帧起始符再次出现、控制码、数据域长度、数据域、校验和、结束符16H。注意地址域是 6 字节每字节又是压缩 BCD 码而且发送时低字节在前。只这一点新手在解析表地址时就很容出错。举个例子某表地址在表壳上印的是 001122334455你在报文里看到的地址域顺序却是 55 44 33 22 11 00。如果你直接按 00 11 22 33 44 55 去匹配设备档案大概率会串号。以前我在现场碰到过好几个“抄不回数据”的工单最后查下来都是主站软件把地址字节顺序搞反了。可以说645 的固定帧本身就隐藏了不少字节序、BCD 编解码的细节初学时要多留个心眼。读数据时主站发送一个读请求数据帧控制码为 01H数据域里放数据标识电表收到后回一帧控制码为 81H 的应答帧把目标数据和附加信息一起带回来。写数据时控制码对应 04H 等。这样的固定交互机制非常直白但真正动手解析时所有字段都要按文档核对长度、校验算法任何一个字节的偏移算错都会导致解析失败。优点是出错可排查缺点是扩展性弱。2.2 698.45 的“应用层 TLV”结构DL/T 698.45 在报文设计上和 645 完全不同。它把通信过程分成了应用层、传输层和链路层报文主体是 APDU应用层协议数据单元内部不再是一堆定长字段排排坐而是采用 TLVTag-Length-Value这种自描述结构。也就是说每个数据单元前面都有标签、长度和值解析程序看到一个 Tag就知道后面是什么数据、有多长遇到不认识的数据段也能跳过而不是直接卡死。这和 645 那种“哪个位置放什么字段全靠约定”的方式比起来最大的好处是可扩展。你要往 698.45 里新加一类数据对象只需要定义好对象的属性和编码规则不用去改动整个报文结构。有点类似 JSON 相比 CSV 的进化CSV 每一列的顺序和格式都必须提前约定好而 JSON 每个键值对天然自带名字和格式新增字段不影响老解析器。在 698.45 里你要读某个数据不是发一个“数据标识”然后等返回而是构造一个“GET 请求”服务里面带上 OAD对象属性描述符明确指向某类对象的某个属性。比如你要读电表里的正反向有功电能就是通过相应的类 ID 和属性 ID 去定位。整个过程更像调用接口而不是查菜单。2.3 编码风格差异带来的现场表现两种编码风格直接影响现场调试效率。645 的十六进制报文短小精悍逻辑分析仪抓包后肉眼能看到 68、16 这种边界符对照文档很快能还原数据698.45 的 APDU 因为带 Tag、Length还要处理嵌套结构报文整体变长尤其在窄带载波链路下半双工传输占用的时间明显增加。如果你在一个只支持窄带载波的老台区里硬推 698.45可能会发现采集成功率反而不如 645这不是协议本身不如人而是信道条件和报文开销不匹配。不过698.45 对产品的规范能力更强。因为协议内置了连接管理、异常响应、对象列表读取等机制设备通信状态更容易被自动化监测。645 如果走得不好很多时候只能靠主站去猜“是不是超时了”“是不是帧格式挂掉了”排障手段偏原始。3. 一张速查表看懂两者的关键差异3.1 核心差异速查表既然题目说“一张图帮你选对协议”我用一张速查表把这几年积累的经验归纳出来。这张表更多是指方向不是穷举标准具体参数要以最新版标准文本为准。对比维度DL/T 645DL/T 698.45发布时间1997 初版/2007 修订版2017 版面向对象协议设计思想固定帧、数据标识菜单面向对象、TLV 自描述主从关系典型主-从问答支持问答和主动上报帧结构68H 地址域 控制码 数据域 CS 16HAPDU 内 TLV 嵌套格式不固定数据寻址数据标识DI 组合对象属性描述符OAD扩展性弱需不断加菜单强新增对象即可扩展链路适配RS-485 为主载波模块也能承载支持 RS-485、载波、无线、以太网等报文长度短开销小相对长开销大事件上报一般不主动靠主站查询支持数据通知和主动上报主站开发难在各类标识解析和兼容难在对象建模和协议分层典型场景传统表计、存量台区、简单抄读新建采集系统、能源控制器、复杂业务3.2 怎么看这张表先看传输通道再看业务复杂度这张表用起来有两条主线。第一你的传输通道是什么。如果物理层只能提供低速 RS-485 或窄带载波链路本身带宽有限645 这个“瘦”协议明显更适应因为同样采一圈数据645 报文短、占用时隙少、成功率更容易做高。如果已经有了以太网或者 4G/5G 这样的宽带链路698.45 的报文较长就不算什么短板反而能通过对象化带来更强的数据管理能力。第二你的业务复杂度是什么。如果只是按周期读几个电量、电压、电流数据再算一下线损和台区考核645 从安装到维护都更省事。如果你要频繁调取负荷曲线、设置分时费率、订阅异常事件上报或者未来可能接入光伏、储能这类新设备698.45 的对象模型会让你省掉大量私有扩展工作。3.3 决策优先级建议我的建议很简单别把协议选择当成技术炫技要从项目全生命周期的角度考虑。做过现场的人都知道协议越复杂现场问题越隐蔽所以不是越“先进”就越好。你要做的是回答三个问题第一底层用什么通道第二要不要长期扩展新业务第三现有主站和终端是不是已经大量在用某一套协议若是存量设备占大头我只推荐 645若是全新系统、有机会做规划优先考虑 698.45如果既有存量又有新增需求就用下文说的分层兼容方案而不是硬选一边。4. 选型策略存量改造、新建项目与混合组网4.1 纯抄表、存量设备645 仍然是性价比之王很多园区、物业、工矿企业核心诉求就是把表底读回来放到计费系统里出账单。这种项目没有复杂的互动需求用 698.45 属于“杀鸡用牛刀”。我见过一个项目前期被人推销了高性能采集器满口都是“面向对象”“可扩展”结果现场上百块老表只支持 645 协议采集器反而要在内部做一次 698.45 到 645 的转换既增加开发成本又添了一层故障点。后来换了台普通 645 采集器半年多都稳得很费用还省了一大截。所以如果预算有限、需求清晰设备的生命周期也接近尾声我不建议折腾。645 方案成熟、工程人员熟悉、故障排查工具也多换一个人也能很快接手。4.2 新建能源管理平台、原厂数据深化应用698.45 是正确姿势如果是新小区、新园区或者数字化配电房要从底层就支持灵活的智能电表和能源控制器那 698.45 的优势就体现出来了。它把电表能力抽象成对象主站侧不再为每类设备单独开发解析程序只要有对象模型清单就能完成接入。尤其是现在光伏、充电桩、储能、非侵入式负荷识别这类业务越来越多用 698.45 新增数据类型要方便很多。我还比较推荐在大型能源管理平台建设时把主站与终端之间的规约直接定为 698.45终端到表计层保留 645。主站侧能拿到一致的、对象化的数据模型业务扩展时不用改底层表计底层表计又能用 645 的低开销稳定抄读。很多省级主站就是这么做的也算是一种工程上的最优解。4.3 混合场景用双协议采集终端做转换现实项目中最常遇到的情况是现场既有支持 698.45 的新表又有不支持的老表。这种时候我不建议把压力全部抛给主站去兼容主站同时维护两套规约会让问题复杂度成倍增加。更稳妥的做法是选一台支持双规约的采集终端由终端对上用一种协议对下切换到对应表计类型的协议把协议差异收敛在终端内部。要注意“双规约”不是简单地在程序里写两个解析函数它还涉及设备档案管理、通道调度、重发策略等。选型时我会格外看几个方面终端下行端口支持几路 RS-485、每路是否支持级联是否支持通过主站远程切换单表通道的协议类型以及调试日志能不能把“上层报文”和“下层报文”同时打出来。后面这一点在现场排障时极其重要否则你会对着一个“请求超时”干瞪眼。5. 现场实操与常见坑5.1 645 报文调试地址翻转与 BCD 编码如果你要从零开始调 645 的串口报文建议按这个顺序来先用串口助手直接连电表配置好波特率常见 2400、4800、9600然后手动发送读数据帧验证表地址是否正确。表地址发送顺序一定要反转这是第一条要记住的规则。假设表地址是 130000002451你面对的是 12 位十进制数每两位拆成一个字节得到 13 00 00 00 24 51实际发送时要把这组字节倒过来51 24 00 00 00 13。电表返回的数据一般也是压缩 BCD 码。比方说返回 4 字节数据 12 34 56 78可以理解成十进制数 12345678而不是十六进制数 0x12345678。具体是整数还是带小数点位要看被读对象的单位和倍率。很多新手把 BCD 码当成普通十六进制转换出来的电量突然大了几万倍就是在这里翻车的。另外645 的校验和是前面所有字节的算术和取低 8 位不包括起始符和结束符写程序时注意按字节累加再 0xFF。5.2 698.45 用 OAD 定位数据对象上手 698.45 的第一件事不是找帧头而是先理解“对象类—属性—属性值”的关系。你去看文档时会遇到一堆术语接口类、对象标识、属性描述符。不要被吓到你可以把某个 OAD 想成“数据表的路由地址”。请求数据时你发出的 GET 请求里包含了这个 OAD电表就能知道要返回哪个对象里的哪个属性值。实操上我建议先用官方的模拟器或开发套件把“读对象目录”“读对象属性”“订阅上报”这几个基本流程跑一遍。因为 698.45 有连接管理和会话概念不是简单发一帧就完事。你要是第一次接触先不要纠结复杂业务把“注册”或“连接”流程走通再说。抓包时优先使用支持 698.45 解析的工具否则你看到的只是一堆难辨的 TLV 字节靠肉眼很难分析。5.3 我在现场踩过的几个坑第一个坑是 698.45 报文太长导致通信超时。项目用的是低速载波链路主站和终端跑 698.45每天固定时段抄表成功率总差一点。后来发现是采集策略里同时请求了大量数据项APDU 长度很大在载波环境下重传概率变高。最后把一次请求拆成多个更短请求避开高峰期成功率才上来。想省事可以但得看懂信道的真实吞吐。第二个坑是协议转换器维护不当。当时为了兼容老表在采集器里做了 698.45 到 645 的转换但采集器的下行表地址配置还是 698.45 那边的“逻辑地址”结果一直抄不回数据。后来才发现转换器的下行通道必须按 645 的规则来配置表地址两个协议的地址模型不是一一对等的不能想当然直接复制。第三个坑是 645 广播校时。很多人会忽视广播帧的特殊性广播地址的地址域是全 AA意味着所有表都会执行命令。如果程序里误把广播帧发成了单点帧还好最多个别表没校时但如果把单点地址的读写帧错写成了广播可能带来整个台区批量数据错乱。曾经有个现场凌晨做校时程序一个 bug 把单点命令发成了广播第二天一查历史曲线好几十张表的时间偏移被改乱了。从那以后我写校时程序一定是先严格过滤地址域再执行写操作。最后再分享一个心得协议终究是工具选 645 还是 698.45说白了是成本、链路、业务扩展性和团队熟悉度之间的权衡。再先进的协议放到了配套跟不上的现场也照样会拖后腿。真正让你在现场少加班的是对协议设计思路的理解是排障时对链路和报文细节的敏感而不是死记报文模板。希望这篇内容能让你少走几步弯路。
DL/T 645与DL/T 698.45对比：电力抄表协议选型与现场排障指南
先说句大实话做电力抄表好些年的人听到 DL/T 645 就像看到老邻居听到 DL/T 698.45 则是一副“听说过但没深交”的表情。这两套协议说到底都是电表和数据采集系统之间的“对话规则”但一个是串口时代的“账本式”抄表一个是面向对象时代的“数据库式”通信。别看它们名字像一家人实际用起来差别大到会让你在调试现场怀疑人生。这篇文章就跟你把两套协议的结构差异、适用场景、选型思路和现场踩坑讲透哪怕你之前完全没接触过报文看完也能对着表格自己判断我这项目到底该用哪个。1. 两种协议的身世从串口账本到对象模型1.1 DL/T 645串口时代的“一页纸账本”DL/T 645 诞生得比较早现在主流用的是 1997 版和 2007 版。它最初就是为 RS-485 这种串行总线设计的主站通过一问一答的方式读写电表数据。你把电表想象成一个只有“电话号码本”的老式电话机主站想查电量先拨通这个表地址然后告诉它“我要读正向有功总电量”电表按固定格式把数据返回来。整个过程非常固定请求命令帧、应答数据帧没有多余的花样。这种设计的优势一个靠“简单”吃饭。帧格式紧凑字段固定一个不懂协议细节的工程师对着报文也能很快把数据解出来。电表端几乎不需要多少内存和计算能力单片机成本低通信速度快在窄带宽的 RS-485 总线上也能跑得很稳。正因如此从居民表到台区总表国网、南网早年的大量现场终端到表计之间几乎清一色是 DL/T 645。但它的问题也藏在“简单”里。因为所有数据都靠“数据标识”去索引而数据标识本身是二维平面的“菜单编号”业务一变就得重新扩充菜单比如要加一个非侵入式负荷识别数据就得多定义一堆标识。换句话说这套协议更像一本写满条目的固定账本能查什么、怎么查全看菜单里有没有这一项不容易扩展也没有内置“对象管理”的概念。1.2 DL/T 698.45带数据库和 API 的智能终端DL/T 698.45 的全称是《电能信息采集与管理系统 第4-5部分通信协议——面向对象的数据交换协议》2017 年发布在设计思路上参考了 IEC 62056 / DLMS/COSEM 的面向对象模型。它不再把电表当成一个只有固定菜单的账本而是把电表里的数据、功能抽象成一个个“对象”。每个对象有属性有方法还有事件你可以像操作数据库一样去查、去改、去订阅通知。举一个类比645 像你拿着一张有索引的纸质电话簿想找哪个号码都得去查目录698.45 则像一套带 RESTful API 的业务系统每个数据项都有明确的“对象 ID 属性 ID”你想取数据直接调接口系统还能主动推送告警。正因为设计了对象模型698.45 支持的通信链路也宽得多。它虽然可以在 RS-485 上跑也适配载波、微功率无线、以太网甚至蜂窝网络应用层的报文用 TLV 编解码数据表达更灵活还能定义复杂的请求和响应流程。很多新上的用电信息采集终端、能源控制器已经开始用 698.45 做主站到终端之间的规约而终端到电表这一级仍然保留 645形成一种“上层对象化、底层帧紧凑”的分层格局。1.3 为什么很多现场还在用 645说了 698.45 这么多优势你可能会问既然更先进为什么不一刀切换掉 645核心原因是存量和成本。全国在运的智能电表和采集终端数量以亿计绝大多数表计硬件和集中器固件按 645 设计直接上 698.45 意味着大规模换表、换主站、换终端投入不是一般大。另外用 645 做简单的“周期抄读费率冻结”本来就很成熟浪费资源去迁移未必划算。所以现实情况是新建的采集主站、省级计量中心或大型园区能源管理平台倾向直接用 698.45而低层设备、老旧台区、数据量稳定的定值抄读场景645 依然会长期存在。理解这个背景之后再去比较协议细节会发现很多差异其实是两种设计哲学的产物。2. 报文底层差异定长帧 vs TLV 编码2.1 645 的固定帧是怎么拼出来的我们先把 DL/T 645 的报文结构过一遍。一帧数据一般由这几个段组成帧起始符68H、地址域、帧起始符再次出现、控制码、数据域长度、数据域、校验和、结束符16H。注意地址域是 6 字节每字节又是压缩 BCD 码而且发送时低字节在前。只这一点新手在解析表地址时就很容出错。举个例子某表地址在表壳上印的是 001122334455你在报文里看到的地址域顺序却是 55 44 33 22 11 00。如果你直接按 00 11 22 33 44 55 去匹配设备档案大概率会串号。以前我在现场碰到过好几个“抄不回数据”的工单最后查下来都是主站软件把地址字节顺序搞反了。可以说645 的固定帧本身就隐藏了不少字节序、BCD 编解码的细节初学时要多留个心眼。读数据时主站发送一个读请求数据帧控制码为 01H数据域里放数据标识电表收到后回一帧控制码为 81H 的应答帧把目标数据和附加信息一起带回来。写数据时控制码对应 04H 等。这样的固定交互机制非常直白但真正动手解析时所有字段都要按文档核对长度、校验算法任何一个字节的偏移算错都会导致解析失败。优点是出错可排查缺点是扩展性弱。2.2 698.45 的“应用层 TLV”结构DL/T 698.45 在报文设计上和 645 完全不同。它把通信过程分成了应用层、传输层和链路层报文主体是 APDU应用层协议数据单元内部不再是一堆定长字段排排坐而是采用 TLVTag-Length-Value这种自描述结构。也就是说每个数据单元前面都有标签、长度和值解析程序看到一个 Tag就知道后面是什么数据、有多长遇到不认识的数据段也能跳过而不是直接卡死。这和 645 那种“哪个位置放什么字段全靠约定”的方式比起来最大的好处是可扩展。你要往 698.45 里新加一类数据对象只需要定义好对象的属性和编码规则不用去改动整个报文结构。有点类似 JSON 相比 CSV 的进化CSV 每一列的顺序和格式都必须提前约定好而 JSON 每个键值对天然自带名字和格式新增字段不影响老解析器。在 698.45 里你要读某个数据不是发一个“数据标识”然后等返回而是构造一个“GET 请求”服务里面带上 OAD对象属性描述符明确指向某类对象的某个属性。比如你要读电表里的正反向有功电能就是通过相应的类 ID 和属性 ID 去定位。整个过程更像调用接口而不是查菜单。2.3 编码风格差异带来的现场表现两种编码风格直接影响现场调试效率。645 的十六进制报文短小精悍逻辑分析仪抓包后肉眼能看到 68、16 这种边界符对照文档很快能还原数据698.45 的 APDU 因为带 Tag、Length还要处理嵌套结构报文整体变长尤其在窄带载波链路下半双工传输占用的时间明显增加。如果你在一个只支持窄带载波的老台区里硬推 698.45可能会发现采集成功率反而不如 645这不是协议本身不如人而是信道条件和报文开销不匹配。不过698.45 对产品的规范能力更强。因为协议内置了连接管理、异常响应、对象列表读取等机制设备通信状态更容易被自动化监测。645 如果走得不好很多时候只能靠主站去猜“是不是超时了”“是不是帧格式挂掉了”排障手段偏原始。3. 一张速查表看懂两者的关键差异3.1 核心差异速查表既然题目说“一张图帮你选对协议”我用一张速查表把这几年积累的经验归纳出来。这张表更多是指方向不是穷举标准具体参数要以最新版标准文本为准。对比维度DL/T 645DL/T 698.45发布时间1997 初版/2007 修订版2017 版面向对象协议设计思想固定帧、数据标识菜单面向对象、TLV 自描述主从关系典型主-从问答支持问答和主动上报帧结构68H 地址域 控制码 数据域 CS 16HAPDU 内 TLV 嵌套格式不固定数据寻址数据标识DI 组合对象属性描述符OAD扩展性弱需不断加菜单强新增对象即可扩展链路适配RS-485 为主载波模块也能承载支持 RS-485、载波、无线、以太网等报文长度短开销小相对长开销大事件上报一般不主动靠主站查询支持数据通知和主动上报主站开发难在各类标识解析和兼容难在对象建模和协议分层典型场景传统表计、存量台区、简单抄读新建采集系统、能源控制器、复杂业务3.2 怎么看这张表先看传输通道再看业务复杂度这张表用起来有两条主线。第一你的传输通道是什么。如果物理层只能提供低速 RS-485 或窄带载波链路本身带宽有限645 这个“瘦”协议明显更适应因为同样采一圈数据645 报文短、占用时隙少、成功率更容易做高。如果已经有了以太网或者 4G/5G 这样的宽带链路698.45 的报文较长就不算什么短板反而能通过对象化带来更强的数据管理能力。第二你的业务复杂度是什么。如果只是按周期读几个电量、电压、电流数据再算一下线损和台区考核645 从安装到维护都更省事。如果你要频繁调取负荷曲线、设置分时费率、订阅异常事件上报或者未来可能接入光伏、储能这类新设备698.45 的对象模型会让你省掉大量私有扩展工作。3.3 决策优先级建议我的建议很简单别把协议选择当成技术炫技要从项目全生命周期的角度考虑。做过现场的人都知道协议越复杂现场问题越隐蔽所以不是越“先进”就越好。你要做的是回答三个问题第一底层用什么通道第二要不要长期扩展新业务第三现有主站和终端是不是已经大量在用某一套协议若是存量设备占大头我只推荐 645若是全新系统、有机会做规划优先考虑 698.45如果既有存量又有新增需求就用下文说的分层兼容方案而不是硬选一边。4. 选型策略存量改造、新建项目与混合组网4.1 纯抄表、存量设备645 仍然是性价比之王很多园区、物业、工矿企业核心诉求就是把表底读回来放到计费系统里出账单。这种项目没有复杂的互动需求用 698.45 属于“杀鸡用牛刀”。我见过一个项目前期被人推销了高性能采集器满口都是“面向对象”“可扩展”结果现场上百块老表只支持 645 协议采集器反而要在内部做一次 698.45 到 645 的转换既增加开发成本又添了一层故障点。后来换了台普通 645 采集器半年多都稳得很费用还省了一大截。所以如果预算有限、需求清晰设备的生命周期也接近尾声我不建议折腾。645 方案成熟、工程人员熟悉、故障排查工具也多换一个人也能很快接手。4.2 新建能源管理平台、原厂数据深化应用698.45 是正确姿势如果是新小区、新园区或者数字化配电房要从底层就支持灵活的智能电表和能源控制器那 698.45 的优势就体现出来了。它把电表能力抽象成对象主站侧不再为每类设备单独开发解析程序只要有对象模型清单就能完成接入。尤其是现在光伏、充电桩、储能、非侵入式负荷识别这类业务越来越多用 698.45 新增数据类型要方便很多。我还比较推荐在大型能源管理平台建设时把主站与终端之间的规约直接定为 698.45终端到表计层保留 645。主站侧能拿到一致的、对象化的数据模型业务扩展时不用改底层表计底层表计又能用 645 的低开销稳定抄读。很多省级主站就是这么做的也算是一种工程上的最优解。4.3 混合场景用双协议采集终端做转换现实项目中最常遇到的情况是现场既有支持 698.45 的新表又有不支持的老表。这种时候我不建议把压力全部抛给主站去兼容主站同时维护两套规约会让问题复杂度成倍增加。更稳妥的做法是选一台支持双规约的采集终端由终端对上用一种协议对下切换到对应表计类型的协议把协议差异收敛在终端内部。要注意“双规约”不是简单地在程序里写两个解析函数它还涉及设备档案管理、通道调度、重发策略等。选型时我会格外看几个方面终端下行端口支持几路 RS-485、每路是否支持级联是否支持通过主站远程切换单表通道的协议类型以及调试日志能不能把“上层报文”和“下层报文”同时打出来。后面这一点在现场排障时极其重要否则你会对着一个“请求超时”干瞪眼。5. 现场实操与常见坑5.1 645 报文调试地址翻转与 BCD 编码如果你要从零开始调 645 的串口报文建议按这个顺序来先用串口助手直接连电表配置好波特率常见 2400、4800、9600然后手动发送读数据帧验证表地址是否正确。表地址发送顺序一定要反转这是第一条要记住的规则。假设表地址是 130000002451你面对的是 12 位十进制数每两位拆成一个字节得到 13 00 00 00 24 51实际发送时要把这组字节倒过来51 24 00 00 00 13。电表返回的数据一般也是压缩 BCD 码。比方说返回 4 字节数据 12 34 56 78可以理解成十进制数 12345678而不是十六进制数 0x12345678。具体是整数还是带小数点位要看被读对象的单位和倍率。很多新手把 BCD 码当成普通十六进制转换出来的电量突然大了几万倍就是在这里翻车的。另外645 的校验和是前面所有字节的算术和取低 8 位不包括起始符和结束符写程序时注意按字节累加再 0xFF。5.2 698.45 用 OAD 定位数据对象上手 698.45 的第一件事不是找帧头而是先理解“对象类—属性—属性值”的关系。你去看文档时会遇到一堆术语接口类、对象标识、属性描述符。不要被吓到你可以把某个 OAD 想成“数据表的路由地址”。请求数据时你发出的 GET 请求里包含了这个 OAD电表就能知道要返回哪个对象里的哪个属性值。实操上我建议先用官方的模拟器或开发套件把“读对象目录”“读对象属性”“订阅上报”这几个基本流程跑一遍。因为 698.45 有连接管理和会话概念不是简单发一帧就完事。你要是第一次接触先不要纠结复杂业务把“注册”或“连接”流程走通再说。抓包时优先使用支持 698.45 解析的工具否则你看到的只是一堆难辨的 TLV 字节靠肉眼很难分析。5.3 我在现场踩过的几个坑第一个坑是 698.45 报文太长导致通信超时。项目用的是低速载波链路主站和终端跑 698.45每天固定时段抄表成功率总差一点。后来发现是采集策略里同时请求了大量数据项APDU 长度很大在载波环境下重传概率变高。最后把一次请求拆成多个更短请求避开高峰期成功率才上来。想省事可以但得看懂信道的真实吞吐。第二个坑是协议转换器维护不当。当时为了兼容老表在采集器里做了 698.45 到 645 的转换但采集器的下行表地址配置还是 698.45 那边的“逻辑地址”结果一直抄不回数据。后来才发现转换器的下行通道必须按 645 的规则来配置表地址两个协议的地址模型不是一一对等的不能想当然直接复制。第三个坑是 645 广播校时。很多人会忽视广播帧的特殊性广播地址的地址域是全 AA意味着所有表都会执行命令。如果程序里误把广播帧发成了单点帧还好最多个别表没校时但如果把单点地址的读写帧错写成了广播可能带来整个台区批量数据错乱。曾经有个现场凌晨做校时程序一个 bug 把单点命令发成了广播第二天一查历史曲线好几十张表的时间偏移被改乱了。从那以后我写校时程序一定是先严格过滤地址域再执行写操作。最后再分享一个心得协议终究是工具选 645 还是 698.45说白了是成本、链路、业务扩展性和团队熟悉度之间的权衡。再先进的协议放到了配套跟不上的现场也照样会拖后腿。真正让你在现场少加班的是对协议设计思路的理解是排障时对链路和报文细节的敏感而不是死记报文模板。希望这篇内容能让你少走几步弯路。
