保护装置与信息子站通信异常问题的分析与研究

付庆钊 杨亚璞 李二玉

（许继电气股份有限公司 河南省许昌市 461000）

HCM3000 是许继研制的用于高压直流输电（High Voltage Direct Current，HVDC）控制保护的高性能工业控制平台系统，继电保护信息子站（以下简称保信子站）与保护装置HCM3000 之间通信是遵循TCP/IP 103 规约[4]，通过以太网接口连接。

某直流输电工程运行现场，保信子站重启或者网络异常中断后，多台HCM3000 保护装置与保信子站通信不能恢复，等待至48 小时后，除一台500kV 极2 换流变保护外，其他装置通信陆续恢复正常，这台换流变保护通信一直到3月后才恢复。如果正常通信过程中突然人为断开并且重连后，还会出现通信自动断开并再次重连的现象[5]。

1 问题复现

在实验室搭建了一套与现场相似的模拟环境，一台HCM3000保护装置通过HUB 与一台保信子站通信，软件版本与现场运行一致。另外，在现有HCM3000 程序中增加通信状态监视程序，方便问题复现后的定位分析。

1.1 复现通信不能恢复

对保信子站重启后，出现与现场一致的现象，保信子站与HCM3000 保护装置通信中断且不能恢复，此时的报文如图1 所示。

由图1中报文可知，保信子站（10.100.100.150） 分 别在NO.2702 Time124 和NO.4401 Time184 两次发起与保护装置（10.100.100.111）的握手请求[SYN]，但是两次都被保护装置在NO.2703 Time124 和NO.4402 Time184 以重置帧[RST,ACK]拒绝。

1.2 复现通信自动断开

在测试过程中成功复现问题现象：保信子站（10.100.100.150）与HCM3000 保护装置（10.100.100.111）通信过程中出现一次通信中断又恢复现象，此时物理通信网络正常，报文如图2 所示。

由图2 中报文可知，HCM3000 装置（10.100.100.111）通信中NO.8615 Time 20:17:56 突然发出主动关闭报文[FIN,ACK]，而此时通信网络完好无故障，保信子站也运行正常。

对关断前的交互报文进行分析后发现，从Time20:17:26 至Time20:17:56（关断前一帧）的这30s 时间内，无应用报文交互，而每200ms 一次的keep-alive 心跳报文的响应都正常，对于tcp 103规约通信中的空闲链路测试帧（TESTFR）也没有[6]。

2 问题的分析定位

2.1 通信不能恢复的问题分析

HCM3000 保护装置通信板卡使用以太网控制芯片为韩国WIZnet 公司生产的W5300，是一款0.18µm CMOS 工艺的单芯片器件，内部集成10/100M 以太网控制器，MAC 和TCP/IP 协议栈。设计人员在保护运行程序中添加芯片运行状态反馈管脚，用来监视芯片的实际运行状态，通信正常情况下芯片状态分别为：通信连接STA=17，通信未连接STA=14，而处于问题中的芯片状态为STA=18。通过查找W5300 产品手册中描述此状态为SOCKET 通信关闭但未完全关闭的中间状态，具体定义如图3 所示。

图1：通信不能恢复报文

图2：通信自动断开报文

图3：W5300 芯片状态定义

图4：全为0 的数据帧

此状态下的以太网芯片认为当前有效SOCKET 连接还未完全关闭，所以不会接受新的SOCKET 连接请求，这样就导致保信子站和HCM3000 保护装置的通信不上的问题。结合W5300 的内部通信控制策略分析可知，HCM3000 当超过30s 无应用报文交互时，就判断为通信连接异常，W5300 以太网控制芯片主动向保信子站发送FIN 关断请求，请求发送后此SOCKET 就进入SOCK_FIN_WAIT 状态，等接收到保信子站的ACK 报文后，进入SOCK_CLOSED 状态，至此才完成连接的完全关闭。

然而现场实际的工作状态为通信中断或者保信子站已经关闭，根本不能收到HCM3000 保护装置发送的FIN 报文，发送ACK 确认也就无从谈起，这样就导致了W5300 以太网控制芯片一致处于SOCK_FIN_WAIT 状态，而何时能从此状态解除也未知。

2.2 通信自动断开的问题分析

首先HCM3000 当超过30s 无应用报文交互时，就判断为通信连接异常，从而主动关闭当前连接，对于HCM3000 的控制逻辑是正确的。

通过对正常交互过程中的报文分析，发现保信子站的空闲链路测试报文发送时间间隔为10s 左右，而保信子站的TCP 103 规约通信中长达30s 没有空闲链路测试报文（TESTFR）则是不正常的。造成此现象的原因是什么呢，继续分析链路中断前的报文发现，在正常通信过程中，HCM3000 保护装置（10.100.100.111）会发送一帧内容全为0 的数据帧（NO.7994 Time 20:17:26），具体如图4 所示。

此报文为HCM3000（10.100.100.111）与保信子站（10.100.100.150）在103 规约通信交互过程中作为保信子站数据通信初始化请求（NO.7984 Time20:17:25）的响应，如图5 所示。

图5 保信子站数据通信初始化请求

通过对这帧数据进行分析，此帧为保信子站数据通信初始化请求帧，DATA:68 04 07 00 00，而根据103 规约，HCM3000 装置应该回复通信链路建立，DATA 应为68 04 0b 00 00，所以这帧内容全为0 的报文是不正确的，为无效数据帧。在正常的103 规约交互中是非法的，由于保信子站在通信中的容错能力不足，接收异常此报文后，103 应用报文交互就不能继续进行，也就不能发送空闲链路测试帧（TESTFR），30s 后，HCM3000 将当前链路进行关闭处理，等待保信子站重新连接[7]。

2.3 问题原因总结

所以造成当前问题的原因主要有以下三个：

（1）保信子站103 规约通信过程中容错能力不足，接收到异常数据帧后，就不能完成后续正常的数据交互。

（2）HCM3000 控制保护装置在103 规约通信链路建立过程中有发送非法数据帧的现象，这是导致此通信问题的根本原因。

（3）在极端巧合情况下，通信控制芯片W5300 会进入SOCK_FIN_WAIT 状态，一致处于等待保信子站的ACK 报文，在此过程中不会响应新的链路建立请求，且目前为止不会自动解除此状态，除非重启控制保护装置。

3 问题处理

针对定位分析出的三个问题，分别作出以下处理：

（1）将现场问题的定位分析结果反馈给保信子站厂家，建议其完善装置的通信容错能力；

（2）对HCM3000 保护装置程序进行相应修改，消除错误帧的发送；

（3）修改控制程序，监测芯片状态，一旦进入SOCK_FIN_WAIT 状态，就对其重置。

4 结语

以保护主机与信息子站现场典型的通信异常问题为例，进行了客观的分析和研究，查找到了根本原因并提供了处理方法，为现场继电保护人员在实际运行中能够尽快定位、处理此类通信问题提供了思路，为电网的安全稳定运行提供了有力保障[8]。