1. 从“黑盒”到“白盒”为什么我们需要理解IEC-104报文在工业自动化特别是电力、能源、轨道交通这些领域我们经常听到“远动”这个词。简单来说远动就是“远方监控与控制”它让调度中心能实时看到几百公里外变电站的电压、电流、开关状态也能远程合上一个断路器。这套系统就像整个工业大网的神经系统而IEC-104规约就是这套神经系统里最通用、最核心的“语言”。我刚入行那会儿对接一个变电站的监控数据调试工具上显示“通信正常”但就是收不到任何数据变化。当时第一反应是怀疑通道、怀疑对端设备折腾了大半天。后来抓了个包用十六进制一看才发现对端设备发上来的报文里类型标识Type ID字段填了个我们系统完全不认识的数值。那一刻我才深刻体会到仅仅知道“通信通了”是远远不够的。如果你不懂这套“语言”的语法和词汇当数据“哑巴”或者“说胡话”的时候你连问题在哪都找不到。IEC-104规约全称是IEC 60870-5-104它定义了在TCP/IP网络之上控制站主站如调度中心和受控站子站如变电站之间如何高效、可靠地交换监控信息。理解它的报文结构就相当于拿到了这套语言的“语法手册”和“词典”。无论是进行协议开发、系统集成、故障排查还是性能优化这份理解都是最底层、最不可或缺的能力。它能帮你精准排障当通信中断或数据异常时能快速定位是链路问题、对端问题还是规约解析本身的问题。深度集成与不同厂商设备对接时能看懂对方“方言”对标准的不同实现并找到兼容方案。性能优化理解报文交互机制从而优化扫描策略、平衡网络负载。安全审计能识别异常或恶意的规约报文为系统安全增加一道防线。接下来我们就抛开那些枯燥的标准文档从一个实践者的角度把IEC-104报文一层层剥开看看它到底是怎么工作的。2. IEC-104报文框架APCI与APDU的清晰分野很多人刚开始看IEC-104报文容易懵因为它看起来就是一串字节。其实它的结构非常清晰遵循一个核心的分层思想传输层负责把数据包可靠地送到应用层负责定义包里面信息的含义。对应到报文上就是APCI应用规约控制信息和APDU应用规约数据单元。你可以把一次IEC-104通信想象成寄一封挂号信。APCI就是信封和快递单它负责确保这封信能准确无误地从A地送到B地并且告诉对方“我寄出了第几封信”、“我期待收到你的第几封回信”。而APDU就是信纸里面的具体内容比如“1号开关现在是合闸状态”。2.1 APCI确保对话不乱的“信封”APCI固定为6个字节它不关心数据内容是什么只关心传输的秩序。这6个字节定义了三种类型的控制报文I格式报文信息传输格式这是主力军用于传输实际的监控信息如遥测、遥信和控制命令。它的APCI里包含两个至关重要的序号发送序号Send Sequence Number, N(S)占2个字节。发送方每发出一个I格式报文这个序号就加1。它告诉接收方“这是我发出的第N封信。”接收序号Receive Sequence Number, N(R)占2个字节。它告诉对方“我已经正确收到了你发来的第N封信及之前的所有信我期待你的第N1封信。”这是一个确认机制意味着当A收到B发来的一个I格式报文其N(R)等于A上次发出的N(S)1时A就知道B已经成功收到了那个报文。S格式报文确认格式这是一个“纯确认”信号。当接收方收到了一批I格式报文但又暂时没有新的I格式信息需要发送时就发一个S格式报文。它只包含N(R)意思是“你发到第N条的消息我都收到了请继续。” 这避免了通信双方在没有业务数据时也要频繁发送I格式报文来确认节省了带宽。U格式报文未编号控制格式用于建立和释放TCP连接以及测试链路是否活跃。比如著名的**STARTDT启动数据传输和STOPDT停止数据传输**命令就是U格式。它没有序号因为这是在建立正式对话之前的“握手”或“告别”。注意APCI的起始字节是固定的0x68作为报文开始的标志。紧接着一个字节表示APDU的总长度包括APCI的6个字节。所以一个完整的APDU长度 这个长度字节的值 20x68和长度字节本身。2.2 APDU承载业务信息的“信纸”APCI之后的部分就是APDU的应用层数据了。对于I格式报文这部分才是我们关心的核心。它的结构同样规整主要由三部分组成类型标识Type Identification, 1字节这是报文的“灵魂”它直接定义了后面跟着的数据是什么“类型”的信息。比如0x01: 单点遥信一个开关/刀闸的状态1位表示0x09: 测量值规一化值一个模拟量如电流、电压常用2字节整数表示0x2D: 双点遥控命令控制一个双位置设备如断路器的合/分0x64: 召唤全数据主站向子站请求发送所有数据 不同厂商的兼容性问题十有八九就出在对这个字段的理解或使用上。可变结构限定词Variable Structure Qualifier, 1字节这个字节的高位bit7很关键。如果为1表示这是一个顺序信息元素后面的信息对象地址是连续的只需要给出起始地址。如果为0则表示这是非顺序的每个信息对象都有自己的独立地址。低位bit0-bit6表示本帧APDU中包含的信息对象数量。传送原因Cause of Transmission, 2字节说明这个信息是“为什么”被发送的。常见的有0x03: 突发变化传送—— 设备状态自己变了主动上报。0x05: 被请求响应总召—— 子站响应主站的“召唤全数据”命令。0x06: 激活—— 一个遥控/设点命令的开始。0x07: 激活确认—— 子站确认收到了激活命令。0x0A: 激活终止—— 命令被取消。 通过传送原因主站能区分这是一个自发上报的告警还是一个对命令的响应这对于逻辑处理至关重要。公共地址Common Address, 2字节通常指子站受控站的站地址。在一个TCP连接可能服务多个逻辑子站比如一个通信管理机带多个保护装置时用它来区分信息来自哪个源头。信息对象Information Object这是数据本体由一个或多个“信息对象体”组成。每个信息对象体至少包含信息对象地址IOA, 3字节这是数据的“身份证号”全网唯一。比如0x000001可能代表“1号主变高压侧A相电流”。信息元素Information Elements数据的值。对于遥信可能是1个比特合1分0对于遥测可能是2字节或4字节的整数/浮点数对于遥控则包含双命令状态合、分、非法和选择/执行标志。时标可选7字节当报文带时标时会包含毫秒、分钟、小时、日、月、年等信息用于记录事件发生的精确时刻。理解了这个框架再看抓包数据你就不会再觉得那是一串乱码了。你会清晰地分辨出哪里是信封APCI哪里是信的内容APDU并能读懂信的核心类型和目的。3. 核心信息类型解析遥信、遥测与遥控掌握了报文框架我们来看看最常打交道的三种信息类型在报文里具体长什么样。这是协议解析和调试中最实用的部分。3.1 遥信通信变位报文解读遥信反映的是开关、刀闸、保护信号等状态量0/1。我们以一个最常见的单点遥信变位类型标识0x01为例假设是突发上传传送原因0x03。假设我们抓到这样一帧报文16进制68 14 02 00 12 00 01 03 00 01 00 01 00 00 00 81我们来拆解一下68: 起始符。14: APDU总长度 20字节0x14 20。总长度 长度字节值 2所以APDU从68开始共20字节。02 00: 发送序号N(S) 2。12 00: 接收序号N(R) 18。说明本端已经正确收到了对端发来的前17个I格式报文。01: 类型标识 1代表单点遥信。03: 可变结构限定词。0x03二进制是00000011最高位为0表示非顺序低7位为3表示本帧有3个信息对象。03 00: 传送原因 3突发。01 00: 公共地址 1站地址。接下来是3个信息对象第一个对象地址01 00 00IOA1值81。81二进制是10000001最低位bit0为1表示状态为合/开/动作取决于点表定义。注意在IEC-104中一个字节的遥信值通常只有最低位有效其他位可能用于表示品质如是否被取代、是否无效等这里81表示状态为1且品质正常。第二个对象地址02 00 00IOA2值01状态为1。第三个对象地址03 00 00IOA3值00状态为0。所以这帧报文的意思是站地址为1的子站主动上报了3个开关的状态变位其中地址1和2的开关为合位地址3的开关为分位。实操心得解析遥信时一定要注意字节序低字节在前。IOA01 00 00实际值是0x000001。另外单点遥信值通常看最低位但有些老设备或特殊点表可能用整个字节表示多个状态务必对照点表说明。3.2 遥测测量值报文解读遥测反映的是电流、电压、功率等模拟量。常用类型标识0x09规一化值或0x0D短浮点数。我们以0x09为例它传输的是一个2字节的整数需要乘以一个系数如0.001才能得到实际工程值。假设报文片段如下仅展示APDU数据部分... 09 01 00 03 00 01 00 01 00 00 10 00 ...09: 类型标识 9规一化值。01: 可变结构限定词非顺序1个对象。00 03: 传送原因 3突发。01 00: 公共地址 1。信息对象地址01 00 00IOA1值10 00。值10 00按低字节在前解析为0x0010即十进制16。假设该点IOA1的系数是0.1则实际工程值为16 * 0.1 1.6可能是1.6kV或1.6A等。对于0x0D短浮点数IEEE 754标准则会占用4个字节直接解析为浮点数即可无需系数转换精度更高是现代系统更推荐的方式。3.3 遥控命令报文交互流程遥控是双向的、有确认的流程比单纯的数据上传要复杂。它遵循“选择-执行”或“直接执行”模式。我们以最常见的“选择-执行”双点遥控类型标识0x2D为例看一次成功的合闸操作交互主站发送“选择”命令激活主站发送I格式报文类型标识0x2D传送原因0x06激活信息对象中包含遥控地址、双命令状态0x81通常代表“合闸选择”、0x80选择标志。这相当于主站对子站说“我准备合上1号开关请做好准备。”子站回复“选择确认”激活确认子站回复I格式报文类型标识0x2D传送原因0x07激活确认信息对象中的双命令状态和地址回显。子站回答“收到1号开关可以合闸已准备好。”主站发送“执行”命令激活主站再发送I格式报文类型标识0x2D传送原因0x06激活信息对象中双命令状态变为0x82合闸执行0x00执行标志。主站下令“现在执行合闸”子站回复“执行确认”激活确认子站回复类型标识0x2D传送原因0x07激活确认回显执行状态。子站确认“合闸命令已执行。”子站上送“遥控返校”或变位信息随后子站会通过遥信变位报文类型标识0x01或0x03将1号开关的状态从“分”变为“合”完成整个闭环。踩坑记录遥控失败很多时候问题出在“品质位”或“附加信息”上。有些设备要求遥控对象必须处于“非闭锁”、“非检修”状态这些状态会体现在信息元素的品质描述里。如果主站发送的命令中忽略了这些状态或者子站回送的确认报文中携带了“拒绝”的原因遥控就会失败。解析时一定要看全信息元素的所有字节不能只看命令状态。4. 协议交互流程与关键机制剖析理解了静态的报文结构我们再把它们串起来看看主站和子站在一次完整的通信会话中是如何“对话”的。这有助于我们在调试时判断通信状态是否健康。4.1 连接建立与数据传输启停IEC-104基于TCP所以第一步是三次握手建立TCP连接。连接建立后并不会立即传输业务数据而是要先进行规约层面的“握手”启动连接U格式报文TCP连接建立后通常由主站主动发送一个U格式的STARTDT启动数据传输激活帧。其控制域通常为0x07二进制00000111表示STARTDT激活。连接确认子站收到后回复一个U格式的STARTDT确认帧控制域为0x0B00001011。数据传输开始只有交换了STARTDT确认后双方才开始用I格式和S格式报文传输业务数据遥信、遥测、遥控等。停止连接当主站需要暂停数据交换如维护时会发送U格式的STOPDT停止数据传输激活帧控制域0x13。子站确认后双方停止发送I格式业务数据但TCP连接可能保持。测试帧在空闲时段为防止连接被防火墙或中间设备断开双方会定期如默认30秒发送U格式的TESTFR测试帧并确认以保持链路活跃。4.2 序号管理与流量控制这是IEC-104可靠性的核心完全由APCI中的N(S)和N(R)实现。发送窗口与接收窗口协议规定发送窗口和接收窗口大小K, W默认为12和8。这意味着在未收到对方确认的情况下发送方最多可以连续发送12个I格式报文。接收方最多可以缓存8个未处理的报文。确认机制显式确认接收方通过发送I格式或S格式报文其N(R)字段来确认已正确收到N(R)-1及之前的所有报文。超时重发发送方发出一个I格式报文后启动计时器如果在一定时间t1通常15秒内未收到包含相应N(R)的确认则会重发该报文。流量控制当接收方处理不过来时它可以延迟发送确认N(R)不增长发送方看到N(R)未更新达到发送窗口上限后就会停止发送从而实现流量控制。在实际抓包中你可以通过观察连续报文中的N(S)和N(R)是否连续、递增来判断是否有报文丢失、重传或通信卡顿。如果发现N(S)跳跃或N(R)长时间不变很可能意味着对端处理异常或网络有丢包。4.3 总召唤与时钟同步流程这是两个重要的周期性或初始化过程。总召唤总查询主站上电或需要刷新全数据时发送C_IC_NA_1召唤全数据命令类型标识通常为0x64传送原因为0x06激活或0x05请求。子站回复激活确认。随后子站开始将内存中的所有通信、遥测等静态数据以“被请求”传送原因0x05的形式分批发送给主站。全部发送完毕后子站发送一个召唤终止报文类型标识0x64传送原因0x0A激活终止。注意事项总召会瞬间产生大量数据对网络和系统处理能力是一次冲击。在生产环境尤其是网络条件不佳时要合理安排总召时机和周期避免影响正常的变化数据上传。时钟同步主站发送C_CS_NA_1时钟同步命令类型标识通常为0x67其中包含主站当前的系统时间。子站收到后将自己的内部时钟调整至该时间并回复一个时钟同步确认报文回显调整后的时间。 这个功能对于保证事件顺序记录SOE的准确性至关重要。5. 实战使用Wireshark抓包与深度解析理论说得再多不如动手抓一包看看。Wireshark是网络分析的瑞士军刀它对IEC-104有很好的内置解析支持。5.1 抓包配置与过滤器技巧选择正确的网卡如果你主站/子站是台物理机选择对应的物理网卡。如果是虚拟机选择虚拟网卡。如果设备在另一台机器你可能需要在网关或通过端口镜像来抓包。使用捕获过滤器为了不抓取海量无关数据可以在开始捕获前设置过滤器。IEC-104通常使用TCP端口2404。捕获过滤器可以设为tcp port 2404。使用显示过滤器抓包后在Wireshark顶部的过滤栏输入iec60870_104可以只显示IEC-104协议报文。要更精确可以用iec60870_104.type_id 0x01来只看遥信报文。5.2 解码与分析关键字段用Wireshark打开一个包含IEC-104的抓包文件找到一条I格式报文点击。Wireshark会将其分层解析Frame, Ethernet, IP, TCP层这些是底层网络信息确认源IP、目标IP和端口是否正确。IEC 60870-5-104层这是展开分析的重点。首先看到APCI部分清晰标出 Start Byte (0x68), Length, N(S), N(R), Type (I-frame)。在这里可以直观看到序号是否连续。接着是APDU部分TypeID会直接翻译成可读名称如M_SP_NA_1(Single-point information)。VSQ会分解出Number of Information Objects和Sequence标志。COT(Cause Of Transmission)显示为可读原因如spontaneous (3)。Common Address。信息对象列表每个对象会展开显示IOA(信息对象地址) 和Value。对于遥信会显示状态ON/OFF对于遥测会显示规一化值或浮点数值。排查案例假设主站收不到某个遥测数据。首先过滤iec60870_104查看通信是否正常是否有I格式报文交互。检查是否有总召过程TypeID0x64子站是否回复了激活确认和大量带cotrequested (5)的数据。如果总召数据里有这个点但后续变化没有检查该点的变化上传报文cotspontaneous (3)是否被正确发送。可能子站未配置变化上传或变化死区设置过大。如果连总召数据里都没有检查点表配置。在子站发送的数据中搜索特定的IOA地址看是否以其他TypeID比如浮点数0x0D发送了。5.3 常见故障的报文层定位通信完全中断抓包只能看到TCP握手包没有0x68开头的104报文。问题可能在于TCP连接成功后一方未发送STARTDT。检查主站/子站的规约配置是否启用了传输连接。数据不更新能看到S格式报文确认帧在交互但没有I格式业务数据。可能是STOPDT已发送数据传输被暂停。或者对方无数据变化且未到总召周期。遥控失败跟踪遥控命令的交互流程。常见问题主站发出“选择”命令后未收到子站的“激活确认”而是收到了“激活终止”cotactivate-termination (10)说明子站拒绝了命令需要查看子站返回的附加信息通常包含拒绝原因代码。收到了“激活确认”但执行后没有状态变位回报文。检查子站是否配置了遥控返校或对应的通信点号是否正确。序号不连续发现N(S)或N(R)出现跳变。这通常意味着有报文丢失触发了重传机制。结合TCP层的重传[TCP Retransmission]标记可以判断是网络丢包还是应用层处理超时。6. 开发与调试中的核心注意事项最后结合我这些年开发和调试的经验分享几个容易踩坑的地方。6.1 字节序与位序问题这是跨平台、跨语言开发中最常见的问题。字节序EndiannessIEC-104标准规定多字节整数采用小端序Little-Endian即低字节在前。这在x86架构的PC上是自然的但在一些嵌入式设备可能采用大端序或使用Java默认大端序开发时必须手动进行转换。IOA3字节、测量值2/4字节、时标7字节等都需要注意。开发检查清单在代码中对任何从字节流中读取的多字节整数确认使用了正确的字节序转换函数如C/C的ntohs/ntohl或手动拼接。位序Bit Order在解析一个字节表示多个状态或标志时如品质描述字要明确协议中每个比特位的定义是从左到右MSB first还是从右到左LSB first。IEC-104标准文档中通常会定义。6.2 超时与重发参数配置这些参数配置不当轻则导致通信效率低下重则导致通信中断。t0, t1, t2, t3 超时t1发送超时发送I格式报文后等待确认的超时时间默认15秒。如果网络延迟大可以适当调大。t2无数据确认超时收到数据后如果暂时没有数据要发最长可以等t2时间再发S格式确认帧默认10秒。调小可以加快确认但增加报文数量。t3信道空闲测试周期发送测试帧TESTFR的间隔默认20秒。用于保持连接。K, W 窗口大小发送窗口K默认12和接收窗口W默认8。在高速网络和高性能系统中适当调大可以提高吞吐量。但在网络不稳定或对端处理能力弱时调小窗口可以避免报文堆积和重传风暴。6.3 与不同厂商设备的兼容性实践标准是统一的但实现是多样的。对接新设备时兼容性调试是重头戏。首先获取对方的“规约说明书”这是最重要的文档里面会说明对方支持哪些类型标识、IOA的编排规则是否从0开始是否分块、是否支持带时标、遥测值的系数、遥控采用哪种模式等。使用“黑盒”测试工具在自研程序对接前先用一些成熟的商业或开源IEC-104测试工具如像一些模拟主站/子站的软件与对方设备对接测试。用工具可以快速验证基本通信、数据收发是否正常排除对方设备的基础故障。“抓包对比”法用测试工具和对方设备正常通信时抓取通信报文。然后让你的程序模仿测试工具发出的报文格式从APCI到APDU的每个字节发送。这是解决兼容性问题最直接有效的方法——对方设备认什么格式你就发什么格式。关注“可选字段”和“默认值”有些厂商会使用标准中保留的位或字段或者对某些字段有特殊的默认值要求。例如遥控命令中的“附加信息”字段有些设备要求必须为0有些则要求填充特定值。分步验证不要想一次性把所有功能都调通。先调通TCP连接和STARTDT再调通总召和遥信遥测上传最后再调试遥控。每一步都通过抓包确认报文交互符合预期。理解IEC-104报文结构就像拿到了打开工业远动通信大门的钥匙。它不仅仅是开发者的必修课也是运维、调试人员快速定位问题的利器。从看懂一个简单的遥信变位报文开始逐步深入到复杂的交互流程和排障分析这个过程本身就是在积累宝贵的现场经验。当你再遇到“通信正常但数据不对”的问题时第一反应不再是重启服务或检查配置而是淡定地说“抓个包看看。”这份从容就来自于对协议细节的扎实掌握。