1. 从零开始IEC104协议到底是什么如果你在电力自动化或者工业监控领域工作一定听过IEC104协议的大名。它就像电力监控系统里的“普通话”让调度中心的主站和遍布各地的变电站子站能够顺畅地对话。简单来说IEC104协议就是一套规定了“谁在什么时候、用什么格式、说什么话”的通信规则。我刚开始接触这个协议的时候也觉得那一串串十六进制报文像天书一样。但后来发现只要理解了它的设计思路一切就豁然开朗了。你可以把它想象成我们日常的快递系统主站是发货方子站是收货方TCP/IP网络就是高速公路而IEC104协议就是那个规定了包裹尺寸、运单格式、签收流程的“快递行业标准”。没有这个标准主站发出去的“遥控合闸”命令子站可能根本看不懂或者当成“遥测数据”给存起来了那可就出大乱子了。这套协议的全称是IEC 60870-5-104它是在经典的IEC 101协议基础上发展而来的。最大的变化就是从过去的串口通信比如RS485升级到了基于TCP/IP的网络通信。这个升级意义重大就像从乡间小路换成了高速公路不仅速度更快、容量更大还能借助成熟的网络设备和技术实现更稳定、更远距离的通信。现在无论是城市电网调度还是大型厂矿的能源管理IEC104都是远程监控和控制的核心支柱。2. 庖丁解牛IEC104协议报文结构全解析要玩转IEC104第一步就是得看懂它发的“电报”到底在说什么。每一帧IEC104报文都可以拆解成几个关键部分咱们一个一个来看。2.1 协议数据单元APDU报文的整体信封每一帧完整的IEC104报文专业术语叫APDU应用规约数据单元。它就像一个标准信封最外面有固定的格式。启动字符和长度域每帧报文都以0x68开头这是一个固定的“起始符”告诉接收方“注意一帧IEC104报文来了”紧接着的一个字节是“长度域”它指明了这帧报文从“控制域”开始到结束的总字节数。这里有个关键点ASDU应用数据的最大长度被限制在249字节以内所以一帧报文能携带的数据量是有限的传输大量数据时需要分多帧发送。应用规约控制信息APCI这是信封上最重要的“控制信息区”决定了这帧报文的根本类型和用途。APCI固定占4个字节根据其最低位的不同报文被分为三大类这也是IEC104协议可靠传输的核心机制所在。2.2 三种核心帧类型I帧、S帧与U帧这是理解IEC104交互逻辑的重中之重。你可以把它们类比成三种不同类型的对话方式。I帧信息帧这是干实活的“数据帧”。它里面既包含了要发送的应用数据ASDU也包含了两个至关重要的序号发送序号N(S)和接收序号N(R)。N(S)相当于说“这是我发的第几条消息”N(R)则相当于告诉对方“你发的第几条消息我已经收到了”。这种设计实现了可靠传输确保数据不丢、不乱。我们后续要讲的遥测、遥信、遥控等具体数据都是通过I帧来传送的。S帧监视帧这是专门用来“确认”的帧。它只有接收序号N(R)没有发送序号也不携带任何应用数据。它的作用很纯粹就是告诉对方“你发到第N(R)条的消息我都已经妥妥收到了”。在实际通信中为了平衡效率和可靠性不一定每收到一个I帧就回一个S帧可以设置成累计接收多个I帧比如8个后再统一用一个S帧确认这能有效减少网络流量。U帧无编号帧这是负责“链路管理”的帧。它没有序号只用于建立连接、启动/停止数据传输、测试链路是否存活等控制功能。比如连接建立后主站必须先发一个STARTDT启动数据传输U帧子站回复确认后双方才能开始用I帧传输业务数据。当网络空闲时也会用TESTFR测试帧来互相“喂你还在吗”防止连接被防火墙等设备误断开。2.3 应用服务数据单元ASDU数据的具体内容拆开APCI这个“信封”里面装着的就是真正的“信件内容”——ASDU。它包含了这次通信的具体意图和数据。类型标识Type ID一个字节定义了这帧数据是干什么的。比如0x01代表单点遥信一个开关的状态0x0D代表短浮点数格式的遥测一个模拟量如电压值0x2D代表单点遥控命令。这是解析数据的首要依据。可变结构限定词VSQ这个字节的高位bit7特别重要。如果它是1表示这帧报文里的多个数据点是地址连续的只有第一个数据点需要给出完整地址后面的地址依次加1。这在总召唤这种需要上传大量连续数据时能极大压缩报文长度。如果它是0则表示每个数据点都有自己的独立地址适合突发上传变化的数据。传送原因COT两个字节说明了这帧数据是“为什么”发送的。常见的有周期扫描1、突发3、初始化4、激活命令6、激活确认7、总召唤响应20国内常用等。通过COT接收方就能知道这数据是例行汇报还是紧急告警或者是对某个命令的回复。公共地址Common Address通常指子站变电站的站地址。在一个主站管理多个子站的网络中靠这个地址来区分数据是来自哪个变电站。信息对象这是数据的本体由“信息体地址IOA”和“信息元素值”组成。IOA就是我们在点表中定义的那个唯一的点号比如“1号线路的A相电流”可能对应地址0x4001。信息元素则是这个点的具体数值或状态其格式和长度完全由“类型标识”决定。3. 实战推演一次完整的总召唤交互流程光说不练假把式咱们现在就来模拟一次电力监控中最常见的交互场景主站启动后向子站发起“总召唤”获取全站所有实时数据。这个过程就像主站对子站说“把你家里所有开关的状态和电表读数都给我报一遍。”3.1 第一阶段TCP连接与链路启动任何通信开始前必须先建立物理通道。主站作为TCP客户端主动向子站TCP服务器默认端口2404发起连接。三次握手成功后TCP链路就通了但这还不够。接下来是IEC104应用层的“握手”。主站会发送一个U帧控制域为0x07这就是STARTDT act启动数据传输激活命令。子站收到后如果准备就绪就回复一个控制域为0x0B的U帧即STARTDT con启动数据传输确认。只有完成这个步骤双方才能开始传输承载实际数据的I帧。我调试时经常遇到双方TCP连上了但数据不通的情况十有八九就是忘了发或者没正确处理这个U帧启动过程。3.2 第二阶段总召唤命令下发与确认链路启动后主站通常会立即发起总召唤以刷新其数据库中的全站数据。这个过程非常标准。主站构造一个I帧发送给子站。这个I帧的ASDU中类型标识Type ID是0x64十进制100对应C_IC_NA_1总召唤命令。传送原因COT是6激活。在信息体里会有一个“召唤限定词QOI”通常固定填0x14十进制20代表召唤全站数据。子站收到这个命令后会先回复一个确认帧。这个回复帧的ASDU格式几乎和命令帧一样唯一的区别是把传送原因COT从6激活改为7激活确认。这等于子站在说“收到你的总召唤指令了我现在开始准备数据。”3.3 第三阶段子站分批上送数据确认之后子站就开始“报数”了。由于数据量通常很大它会分成很多个I帧来发送。这里面的学问很大。遥信数据上送子站首先会上送所有的状态量遥信。例如它会发送类型标识为0x01单点遥信的I帧。可变结构限定词VSQ的SQ位通常会置1因为遥信点地址往往是连续的这样可以节省大量报文空间。传送原因COT在国内规范中常用20表示“总召唤的响应”。一帧报文中可能包含几十甚至上百个遥信点的状态每个状态用一个字节表示如0x01表示合位0x00表示分位0x80表示无效。遥测数据上送送完遥信接着送模拟量遥测。这时类型标识变为0x0D短浮点遥测。每个遥测点占5个字节4字节的IEEE 754标准浮点数表示实际的电流、电压值加上1个字节的品质描述词表示该数据是否有效、是否被人工置数等。同样由于遥测点地址也常连续SQ位也置1一帧报文能传送几十个点的数据。子站会按照地址顺序一帧一帧地把所有遥测点发送完毕。在实际抓包中你会看到子站连续不断地发来一大堆I帧每一帧的发送序号N(S)都在递增而主站可能隔几帧才回复一个S帧进行确认这就是IEC104的流量控制和确认机制在起作用。3.4 第四阶段总召唤结束与后续通信当所有数据都发送完毕后子站会发送一个特殊的“结束帧”来告知主站。这个帧的类型标识可能还是0x64总召唤但传送原因COT变为10召唤结束。也有些实现会用一个不带信息体的ASDU来标识结束。收到结束帧后主站就知道本次总召唤流程圆满完成了。此后通信进入“稳态”。子站会周期性地比如每5秒上送变化了的遥测数据COT1或者一旦有开关变位就立即上送变位信息COT3突发。主站则可以在需要时随时下发遥控、遥调等命令。整个系统就这样有条不紊地运行着。4. 手把手解析遥控与遥测报文实例理论讲得再多不如直接看真实报文来得透彻。下面我带你逐字节拆解两个最典型的报文一个是遥控命令一个是遥测数据。准备好你的十六进制计算器咱们开始。4.1 遥控报文解析分步的安全操作遥控是电力系统中非常严肃的操作所以IEC104协议设计了“选择-执行”两步确认机制来防止误动。我们来看一组典型的报文交互。第一步主站下发“选择”命令假设主站要遥控地址为24581的开关分闸。它发送如下I帧68 0E 04 00 16 00 2D 01 06 00 F7 00 05 60 00 80APCI部分68起始符。0E表示APDU总长14字节。04 00 16 00是控制域计算可知这是一个发送序号N(S)2接收序号N(R)11的I帧。ASDU部分2D是类型标识对应45即C_SC_NA_1单点遥控命令。01是可变结构限定词表示有1个信息对象。06 00是传送原因6代表“激活”。F7 00是公共地址即站地址247。05 60 00是信息体地址IOA小端格式实际为0x006005即十进制24581。关键命令值最后一个字节0x80是单点命令信息。它的bit7为1表示这是“选择”阶段bit0为0表示命令是“分闸”。所以这整帧报文的意思是主站向247号站的24581号点发送了一个“分闸选择”命令。第二步子站回复“选择确认”子站收到选择命令后检查自身状态比如该点是否允许遥控、是否闭锁如果条件允许则回复确认68 0E 16 00 06 00 2D 01 07 00 F7 00 05 60 00 80这帧报文和命令帧高度相似。区别在于控制域变成了16 00 06 00这是子站发出的一个I帧N(S)11 N(R)3。最重要的是传送原因从06变成了07即“激活确认”。其他内容原样返回。这表示子站已准备好执行该操作。第三步与第四步主站收到选择确认后会在短时间内如10秒内下发“执行”命令其报文格式与选择命令几乎一致但命令字节变为0x01bit70执行bit01分闸。子站执行实际操作后会再次回复一个“执行确认”帧或者通过一个遥信变位报文类型标识0x01COT3来告知主站操作结果。通过这两步确认极大地提升了遥控操作的安全性。4.2 遥测报文解析海量数据的承载遥测数据量通常很大我们截取一帧典型的短浮点遥测报文来看68 D5 06 00 02 00 0D A8 14 00 01 00 01 40 00 00 00 C0 40 ... (后续大量数据)APCI部分68起始符。D5十进制213表示这帧报文非常长ASDU部分有209字节。06 00 02 00是控制域表示这是一个发送序号N(S)3接收序号N(R)1的I帧。ASDU部分0D是类型标识对应13即M_ME_NC_1短浮点遥测。A8是可变结构限定词二进制10101000最高位1表示地址连续低7位0101000十进制40表示本帧包含40个遥测点的数据。14 00是传送原因20表示是总召唤的响应。01 00是公共地址站地址为1。信息对象01 40 00 00是第一个信息体的地址小端格式为0x00004001即十进制16385。这是一个常见的遥测起始地址。接下来就是40组遥测数据每组5个字节前4个字节是一个IEEE 754标准的单精度浮点数第5个字节是品质描述词。例如紧接着地址后的00 00 C0 40四个字节按小端序解读为浮点数6.00x40C00000的浮点值品质词0x00表示数据有效。这一帧报文就一次性上传了从地址16385开始的40个遥测点的实时值。通过这样解析一堆看似杂乱无章的十六进制数字就变成了有明确意义的站地址、点号、实测值和数据品质。在实际调试中借助Wireshark配合IEC104解析插件或专业的规约分析软件可以自动完成这些解析极大提高效率。5. 开发与调试实战指南理解了协议原理和报文结构最终还是要落到开发和运维上。根据我多年的经验无论是自己实现一个IEC104的库还是调试现成的设备以下几个坑点需要特别注意。5.1 关键参数协商与配置在通信开始前主从站两端有几个关键参数必须达成一致否则通信必定失败。这些参数通常不在协议报文里交互而是需要双方在配置文件中预先设好。TCP连接参数主站要知道子站的IP地址和端口默认2404。此外TCP的Keep-Alive机制最好开启以便快速检测网络中断。APDU最大长度这决定了一帧能传多少数据。标准规定ASDU最大249字节但实际使用时双方会协商一个值比如203字节。这个值会影响总召唤时每一帧包含的点数。如果配置不一致可能导致一方发出的长报文被另一方拒绝。超时与重传参数这是保障可靠性的关键。主要包括t0连接建立超时、t1发送或测试APDU的超时、t2无数据链路时确认的超时、t3长期空闲发送测试帧的间隔以及k和w未经确认的I帧最大数目和最大字节数。这些参数需要根据网络质量和应用需求仔细 tuning。比如在网络延迟大的环境下t1和t2需要适当调大。公共地址与信息体地址公共地址站地址必须在两端一致。信息体地址点表更是重中之重主站和子站对同一个物理量如“1号主变高压侧电流”定义的IOA必须完全相同。点表的维护和同步是现场调试中最繁琐也最容易出错的一环。5.2 常见故障分析与排查在实际运行中通信中断或数据异常是家常便饭。我总结了一个快速排查的“四步法”。第一步检查物理层与网络层。这是基础。先用ping命令检查网络是否通畅用telnet或nc命令测试端口2404是否能连通。很多问题其实就出在网络线缆、交换机配置或防火墙策略上。第二步抓包分析交互流程。如果TCP能连上但数据不对一定要抓包。使用Wireshark在任意一端抓取流量过滤端口2404。然后重点看连接建立后是否有U帧的STARTDT68 04 07 00 00 00/68 04 0B 00 00 00交互没有就是链路没启动。主站发送总召唤命令TypeID100COT6后子站是否回复了确认COT7如果没有可能是子站未配置或忙。子站回复的I帧其发送序号N(S)是否连续主站回复的S帧确认序号N(R)是否及时如果发现序号不连续或长时间没有S帧确认可能是发生了丢包或一方处理不过来需要检查k、w和超时参数。解析具体的ASDU检查类型标识、传送原因、地址是否正确。经常有因为点表不一致导致数据解析错误的情况。第三步核对配置与点表。确保两端的站地址、APDU长度、各类超时参数完全一致。逐点核对点表确认IOA、数据类型是单点遥信0x01还是双点遥信0x03是整型遥测0x09还是浮点遥测0x0D是否匹配。第四步查看设备日志。主站和子站设备通常都有运行日志里面会记录更详细的错误信息比如“收到无法解析的ASDU”、“序列号错误”、“连接超时”等这些是定位问题的直接线索。5.3 性能优化与可靠性设计对于大型系统有成百上千个站对通信的稳定性和效率要求很高。这里分享几个实用的优化经验。连接管理与断线重连必须实现稳健的断线检测和自动重连机制。除了依赖TCP的机制还要在应用层利用IEC104的TESTFR测试帧进行保活。重连后要能自动重新发起总召唤同步全数据。数据分组与压缩上传在子站端对于总召唤响应尽量使用地址连续SQ1的方式打包数据能显著减少报文数量。对于变化数据上送可以设置合理的死区阈值只有变化量超过一定范围才上报避免网络拥塞。序号处理与流量控制务必严格维护发送和接收序号。发送窗口k值不宜设置过大防止网络延迟高时堆积太多未确认报文导致内存溢出。接收方如果处理不过来要及时通过S帧确认并可能通过TCP滑动窗口间接控制对端发送速度。异步处理与缓冲区设计无论是主站还是子站报文接收、解析、业务处理最好采用异步模式避免因为某个点的处理卡顿阻塞整个通信链路。接收缓冲区要设置得当防止报文被截断。调试IEC104协议是一个从协议文本到网络字节流再到实际业务理解的深化过程。最开始面对十六进制报文可能会头疼但当你成功定位一次通信故障或者亲手实现了一个稳定运行的104驱动时那种成就感是非常实在的。记住多抓包、多对比、勤查标准文档和厂家的补充规约大部分问题都能迎刃而解。