行业资讯
DL/T 698.45协议深度解析：从报文拆解到实战应用
1. 项目概述从“黑盒”到“白盒”的通信协议认知之旅在智能电表、集中器、能源数据采集这些领域里摸爬滚打过的工程师对“698”这个数字一定不会陌生。它不像TCP/IP那样家喻户晓也不像MQTT那样在物联网圈子里被频繁讨论但在电力行业尤其是在国内的电能量信息采集与管理系统里DL/T 698.45协议我们通常简称为698协议就是那个“普通话”是终端设备与主站系统之间对话的基石。我最初接触它时面对动辄几百页的协议文档和一堆十六进制的报文感觉就像在看天书工具软件点一下“召测”数据就回来了但中间发生了什么完全是个黑盒。这种“知其然不知其所以然”的状态在遇到复杂问题排查、协议对接调试甚至是自主开发采集模块时会变得非常被动。因此我花了相当长的时间从一个使用者的角度去拆解、理解、甚至“把玩”这个协议目的就是把黑盒打开搞清楚每一帧报文里每一个字节的意义以及它们是如何协同工作来完成一次成功的数据交换的。这个过程就是我对“698通信标准”从模糊到清晰的理解之旅。这篇文章我想把这些理解梳理出来它不适合协议标准的起草者而是写给那些和我一样需要在实际项目中应用、调试、甚至基于此进行二次开发的工程师们。我们会绕过那些晦涩的官方定义直接从一次最简单的数据读取请求出发看看698协议到底是怎么“说话”的。2. 协议框架与核心思想拆解2.1 分层模型与“服务”导向的设计哲学698协议不是一个单一的规范而是一个系列标准。我们最常打交道的是面向对象的数据交换协议部分。理解它的第一个关键是跳出OSI七层模型或TCP/IP四层模型的惯性思维。698协议自己定义了一套清晰的应用层通信模型你可以把它粗略地类比为“客户端-服务器”模式但它的术语更精准主站Master和终端Slave。主站发起请求终端响应请求这个模式贯穿始终。更核心的是它的“服务”思想。协议将所有的交互抽象为一系列的服务原语比如“连接管理服务”、“数据读写服务”、“事件报告服务”等。我们程序员最熟悉的“读数据”Get和“写数据”Set在698里只是众多服务中的两种。这种设计的好处是扩展性极强。当需要增加一种新的交互方式比如透明转发、文件传输时不需要动底层的数据帧结构只需要定义一个新的服务原语及其参数即可。这就像我们设计API接口先定义好GET /api/data和POST /api/data这样的语义至于具体传输用什么格式JSON/XML是另一个层面的问题。注意很多新手会混淆“协议”和“规约”。在电力行业我们常说“698规约”这里的“规约”更偏向于指一整套包含物理层、链路层、应用层甚至业务数据模型的约定集合。而我们日常调试时说的“698协议”通常特指其应用层的数据报文格式和交互流程。本文讨论的重点是后者。2.2 报文结构像拆解俄罗斯套娃一样理解APDU协议文档里最让人头疼的往往是那一大堆缩写APDU、ASDU、PIID……我们换个方式理解。把一次完整的通信数据包想象成一个快递包裹。最外层包装链路层帧包含了收发地址主站地址、终端地址、帧起始结束标志、校验码等。这确保了包裹能从正确的发货方送到正确的收货方并且途中没被损坏。这部分通常由硬件模块如通信模块或底层驱动处理我们应用层不太关心。快递单应用层协议数据单元 - APDU这是我们需要重点关注的“包裹内容”。APDU本身又是一个套娃结构它由两部分组成服务头控制域相当于快递单上的“服务类型”。是到付件请求还是已付件响应是普通件确认还是加急件非确认这个头里最重要的信息就是服务标识它告诉对方“我这是一个‘读数据’的请求”或者“这是我对于你‘读数据’请求的响应”。服务数据单元ASDU这才是真正的“货物”。对于“读数据”请求ASDU里装的就是“我想读哪个对象”的详细描述对于响应ASDU里装的就是“你要读的对象的数据值”。PIID协议标识符是这个机制里的精华它像一个会话ID。主站发起一个请求时会生成一个PIID。终端在回应这个请求时必须原样返回这个PIID。这样主站就能在可能并发的多个请求中准确地将响应和请求配对起来。想象一下主站同时向一个终端问了两个问题比如“当前电压是多少”和“当前电流是多少”终端回答“220V”和“10A”。如果没有PIID主站就分不清哪个答案对应哪个问题。有了PIID一切就清晰了。2.3 对象模型与OBIS码给每个数据点一个“身份证”理解了怎么“说话”报文结构接下来要理解“说什么”数据内容。698协议采用面向对象的思想来管理数据。电表里的所有信息如电压、电流、功率、电量、事件记录等都被建模为一个一个的“对象”。每个对象都有一个全球唯一的“身份证号”这就是OBIS码对象标识码。OBIS码是一组6个数字例如1-0:32.7.0.255A相电压。这组数字有明确的含义第一个数字A组通常表示介质或抽象对象组如“电能”是1“电气参数”是7。第二个数字B组通常表示通道或计量点如“总”是0“A相”是1。第三、四、五、六组C, D, E, F进一步细化对象类型、属性等。在协议报文中我们不是直接传输这个字符串格式的OBIS码而是将其编码为紧凑的二进制形式如07 00 20 07 00 FF。理解OBIS码的编码规则是手动解析或构造报文的基础。对象不仅有值还有属性。比如一个“电能量”对象它有“当前值”属性2、“单位”属性3、“量纲”属性4等。读数据时你需要指定读哪个对象的哪个属性。这种设计非常灵活你可以只读当前值也可以同时读取它的单位和描述信息。3. 核心交互流程深度解析3.1 一次标准的“读”操作全流程拆解让我们抛开工具用“脑补”和“报文”的方式走完一次最简单的单点数据读取。假设主站要读取终端电表的A相电压OBIS: 1-0:32.7.0.255的当前值属性2。步骤1主站构建请求APDU确定服务这是一个“读取请求”对应的服务标识是0x01GetRequestNormal。生成PIID假设本次会话ID是0x01。构建ASDU货物放入“读”的标识。放入目标对象的描述这里需要指定OBIS码和属性ID。将OBIS码1-0:32.7.0.255转换为二进制序列例如07 00 20 07 00 FF。属性ID为2。可能还需要指定一个“时间标签”可选用于数据时标对齐。组装APDU将服务头包含0x01和PIID0x01和ASDU拼接起来形成完整的请求报文。例如简化示意68 ... L ... 68 (帧头) | 01 01 (服务头) | ... 07 00 20 07 00 FF 02 ... (ASDU) | CS (校验) | 16 (帧尾)。步骤2终端处理与响应终端解析收到报文后终端先校验帧完整性然后解析APDU。看到服务标识0x01知道这是个读请求。提取PIID0x01保存。查找对象根据ASDU中的OBIS码和属性ID在自己的对象字典里找到对应的A相电压数据对象。获取数据读取该对象属性2当前值的数值假设是220.0V。构建响应APDU服务标识对于成功的读取响应标识是0x81GetResponseNormal。PIID必须原样返回0x01。构建ASDU放入“读响应”标识然后放入“读取结果”。这个结果是一个“数据”结构里面包含了数据类型这里是浮点数32、数据值220.0的二进制表示以及可能的数据质量描述如00表示数据有效。发送响应组装响应APDU并发回给主站。步骤3主站解析响应主站收到响应帧校验后解析。根据服务标识0x81知道是读响应根据PIID0x01找到对应的请求上下文。解析ASDU中的“数据”结构提取出浮点数值220.0完成本次读取。这个过程看似繁琐但每一步都保证了通信的可靠性和明确性。所有现代采集工具或协议库底层都是在自动化地完成这些步骤。3.2 “写”操作与安全认证机制“写”操作SetRequest流程与“读”类似但方向相反且通常涉及安全控制。写操作可能用于设置参数如费率时段、下发控制命令如远程合闸等敏感操作。698协议的安全机制主要体现在身份认证和数据加密两个层面通常通过“安全服务”来实现。一个典型的带认证的写操作流程如下主站发起写请求报文中会携带一个“服务序号”和需要写入的数据。终端返回挑战码终端收到请求后如果判断该操作需要认证会返回一个响应其中包含一个随机生成的“挑战码”Challenge。主站计算MAC并重发主站使用预置的密钥、挑战码和请求报文数据通过特定的算法如SM4计算出一个消息认证码MAC。然后重新发起写请求这次在报文中附上这个MAC。终端验证并执行终端使用相同的密钥和算法进行验证。如果MAC匹配则证明主站是合法的随后执行写操作并返回成功响应否则返回认证失败。实操心得在现场调试中90%的“写操作失败”问题都出在安全认证环节。务必确认主站和终端使用的密钥是否一致。认证算法和模式是否匹配是单向认证还是双向认证加密算法是SM1还是SM4。挑战码-响应的交互流程在代码中是否正确实现。很多协议库封装后这一步对用户是透明的但如果库本身有bug或配置错误这里就是重灾区。3.3 事件上报与主动上报模型除了主站主动查询698协议也支持终端主动上报数据这主要通过“事件上报”机制实现。终端内可以定义各种事件如过压、失压、开盖等并为其设置上报条件。当事件触发时终端会主动构造一个“事件上报”的APDU服务标识如0x0C将事件信息发送给主站。主站需要持续监听链路以接收这些上报报文。为了可靠性协议通常要求主站对收到的事件上报进行确认。这种“主动上报”模型对于实时监控告警场景至关重要它避免了轮询带来的延迟和带宽浪费。在系统设计时需要合理配置终端的事件上报参数并确保主站的上报处理模块稳定可靠。4. 协议解析与调试实战技巧4.1 必备工具从串口助手到专业分析仪工欲善其事必先利其器。理解698协议离不开对实际报文的观察。串口调试助手/网络调试助手最基础的抓包工具。将主站或终端设备通过串口或网络连接到电脑用调试助手监听并显示所有原始字节流十六进制格式。你可以清晰地看到每一帧的68 ... 68起始结束符以及中间的内容。这是最“原始”也最可靠的方式。协议分析软件如一些商业或开源的698协议分析仪。它们能自动识别698帧并将十六进制报文解析成树状结构或表格直观地展示出服务标识、PIID、OBIS码、数据值等。这极大提高了调试效率尤其是在分析复杂交互或排查问题时。Wireshark如果通信走的是TCP/IP网络如698.45 over TCPWireshark是神器。你可以编写或使用现有的698协议解析插件Dissector让Wireshark直接解码应用层报文像分析HTTP一样分析698协议。4.2 手动解析报文一个真实的案例假设我们收到一串响应报文十六进制68 1A 00 43 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 16这看起来杂乱无章我们按照698帧结构来拆帧起始符68。长度L1A换算成十进制是26。注意698协议的长度L通常指从起始符68之后到校验和之前或之后根据版本的字节数。这里需要根据具体版本确认。控制域C00。这里需要查协议00可能表示这是一个确认帧ACD或其他含义。地址域A43 00 00 00 00 00 00 01。这是终端的地址通常是7字节或8字节低位在前。43 00 00 00 00 00 00 01可能表示地址是01 00 00 00 00 00 00 43反转后具体含义需结合规约。帧头校验HCS00。帧数据APDU从00开始到00结束的一大段。这里看起来很多00可能是一个简短的响应或心跳。帧校验FCS00。帧结束符16。这个例子中APDU内容全是00可能是一个链路层的心跳或确认响应没有实际的应用层数据。一个携带数据的响应APDU会更复杂例如81 01 02 00 09 06 00 00 00 01 00 FF 02 00 02 04 00 00 00 00。81服务标识Get响应。01PIID。02 00可能表示后续数据域长度或特定标识。09 06 00 00 00 01 00 FFOBIS码1-0:1.0.0.255正向有功总电能的二进制编码。02 00属性2当前值。02 04 00 00 00 00数据02表示数据类型为long32位有符号整数04表示数据长度为4字节00 00 00 00就是值0。通过这样手动解析你对报文的每一个字节都会变得非常敏感这是快速定位通信问题的核心能力。4.3 常见通信故障排查思路当通信失败时可以按照以下层次进行排查物理层/链路层检查串口线、网线是否接好波特率、数据位、停止位、校验位是否匹配用调试助手看是否有任何数据收发如果发送后毫无反应问题大概率在此层。发送最简单的测试帧如链路测试请求68 04 00 00 00 00 C3 16看终端是否有回复。应用层连接物理连通后发送“应用连接请求”如68 1A ... C3 16具体帧根据协议版本终端应回复“应用连接确认”。如果没确认检查终端地址、主站地址、密码等参数是否正确。数据交互层连接成功后读一个简单的、确定存在的对象如电表地址0-0:96.1.0.255。问题1无响应。检查PIID是否匹配终端是否支持该服务对象OBIS码是否正确问题2响应错误。解析返回的错误码在响应APDU中。常见错误如“对象不存在”错误码02、“属性不可读”05等。根据错误码调整请求。问题3数据解析错误。响应正常但解析出的数据乱码。检查数据类型的解析方式是否正确如4字节浮点数、8字节双精度、BCD码等。698协议的数据类型非常丰富务必对照协议附录的数据类型表逐一核对。5. 协议库的选择与自主开发考量5.1 第三方协议库的优缺点分析对于大多数应用开发我们不会从零开始实现698协议而是使用成熟的协议库即“698协议库”。市面上有商业库和开源库可供选择。商业库优点通常功能完整、稳定可靠、文档齐全、提供技术支持。经过了大量现场项目的验证在兼容性、性能和处理各种边缘情况如不同厂商的终端差异方面有优势。缺点需要付费授权可能带来额外的成本。有时库的接口设计比较封闭定制化灵活性稍差。开源库优点免费源代码可见可以根据自身需求进行修改和定制。是学习和理解协议实现的绝佳材料。缺点功能完整性、稳定性和技术支持无法保证。可能需要投入较多精力进行代码阅读、调试和二次开发。不同开源库的质量和协议版本支持度参差不齐。选择时需要权衡项目预算、时间要求、技术能力和长期维护成本。对于产品化、要求高可靠性的项目商业库往往是更稳妥的选择。对于研究、学习或内部工具开发开源库是很好的起点。5.2 自主实现核心模块的挑战与价值尽管使用库很方便但我强烈建议即使在使用库的同时团队里也应该有人能深入理解协议甚至尝试实现一个简化版的核心解析/组帧模块。这有不可替代的价值深度排错当库出现问题时你能快速定位是库的bug、配置错误还是终端不兼容。你能看懂日志里打印的原始报文而不是两眼一抹黑。性能优化理解协议细节后你可以针对特定场景优化交互。例如批量读取多个对象时是发多个单点读请求还是组合成一个“读取请求列表”GetRequestList后者能显著减少交互次数和网络开销。这些优化策略建立在透彻理解协议服务的基础上。应对非标终端现场总会遇到一些不完全符合标准的终端设备。它们可能在某个数据项的编码上用了自定义方式或者对某个服务的响应略有不同。此时一个可修改的自主解析模块比一个黑盒的商业库更能快速适配。自主实现可以从最简单的部分开始APDU的解析与组装。先实现Get和Set两种最基本服务的请求/响应帧构造与解析。实现过程中你会被迫去弄清楚每一个字节的含义这是任何文档和教程都无法替代的学习过程。5.3 协议版本差异与兼容性处理DL/T 698协议本身也有多个版本如2009版、2013版、2018版等不同版本在帧结构、服务定义、数据编码上可能存在差异。此外各电表厂商在遵循国标的基础上也可能有各自的“扩展”或“自定义”项。在实际项目中兼容性处理是一个大头。一个好的协议库或自主实现方案应该能够通过配置来适配不同版本和不同厂商的差异。常见的做法包括版本配置在建立连接或初始化时指定使用的协议版本。厂商配置模板为不同的终端厂商预定义一套配置包括特殊的OBIS码映射、非标准的数据类型处理、特定的安全认证流程等。动态适配有些高级库能通过前期的“协议探测”交互自动识别终端支持的协议版本和特性。在调试新品牌或新型号的终端时第一件事就是获取其配套的协议说明书或称为通信规约仔细对比其与标准698的差异点并在你的采集程序中做好相应的适配。6. 性能优化与高级应用场景6.1 连接管理与心跳保活在TCP/IP网络环境下698协议通常运行在长连接之上。稳定的连接是可靠通信的前提。需要实现自动重连机制当连接异常断开时能够自动尝试重新建立连接。心跳保活定期如每60秒发送链路测试请求或应用层心跳包以维持连接并探测对端状态。长时间无数据交互中间的网络设备如防火墙、NAT可能会断开连接。连接池管理对于主站需要同时管理成千上万个终端的情况需要设计高效的连接池复用TCP连接避免频繁创建销毁连接带来的开销。6.2 数据采集策略优化如何高效地采集海量终端的数据是系统设计的核心挑战。并发与异步采用多线程或异步IO模型同时与多个终端通信避免因等待单个终端响应而阻塞整个采集进程。批量读取优先使用GetRequestList读取请求列表服务将多个需要读取的对象OBIS码打包在一个请求中发送。终端在一个响应里返回所有数据。这比循环发送多个GetRequestNormal请求效率高一个数量级。增量采集对于像电能量这种累积量如果每次全量读取历史数据数据量会非常大。可以利用协议中的“时间标签”和“档案记录”相关服务只读取上次采集时间点之后的新增数据。分级采集将数据按实时性要求分级。如电压、电流等需实时监控的数据采用较高的采集频率日冻结电量等数据可以每小时或每天采集一次。6.3 与上层系统的集成数据模型转换采集到的698协议原始数据二进制格式的OBIS码和值需要转换成上层业务系统如SCADA、能源管理平台能够理解的数据模型。这通常需要一个“协议解析与数据转换”层来完成OBIS码映射建立一个映射表将标准的或厂商扩展的OBIS码映射到业务系统内部统一的数据点标识如Meter01.Voltage_A。数据类型与单位转换将698协议中各种数据类型整型、浮点、BCD码、时间日期等转换为系统内部使用的标准类型如双精度浮点数。同时处理单位换算如协议返回的电量单位可能是kWh而系统需要MWh。数据质量标记698协议响应中带有数据质量位如无效、替代值、被修改等需要将这些信息传递给上层系统供其判断数据的可信度。事件与告警转换将协议上报的事件如开盖告警、失压告警转换为业务系统的标准告警事件并触发相应的通知和处理流程。这一层的稳定性和准确性直接决定了数据采集系统的最终价值。它需要处理各种边缘情况比如终端返回的数据格式与预期不符、映射表遗漏了某个OBIS码等。理解698通信标准远不止于看懂一份文档。它是一个从二进制比特流到业务价值数据的完整翻译和搬运过程。从手动解析第一帧报文时的困惑到能够设计高效稳定的采集系统这个过程充满了挑战但也正是工程师价值的体现。当你不再依赖黑盒工具能够从容地通过报文分析定位一个诡异的通信故障或者设计出一个将采集效率提升数倍的批量读取方案时你会觉得那些啃协议文档的夜晚都是值得的。这个协议就像一座桥桥的这边是冰冷的硬件与数据桥的那边是鲜活的业务与应用而我们的工作就是确保这座桥坚固、通畅且高效。
郑州网站建设
网页设计
企业官网
![[具身智能-181]：PC+服务器+具身机器人：构建具身智能从仿真到量产的闭环迭代混合架构](http://pic.xiahunao.cn/yaotu/[具身智能-181]：PC+服务器+具身机器人：构建具身智能从仿真到量产的闭环迭代混合架构)
![[具身智能-181]：大分布式通信模型对比：看懂为什么 DDS 是 ROS2 底层通信最优解](http://pic.xiahunao.cn/yaotu/[具身智能-181]：大分布式通信模型对比：看懂为什么 DDS 是 ROS2 底层通信最优解)
