葛站控保系统升级后PPR主机PCIA板卡频繁故障原因分析

国网湖北省电力公司检修公司 戴 迪

三峡电力职业学院 王丽丽

国网湖北省电力公司检修公司 黄瑶玲 刘 浔 郑 华

葛站控保系统升级后PPR主机PCIA板卡频繁故障原因分析

国网湖北省电力公司检修公司 戴 迪

三峡电力职业学院 王丽丽

国网湖北省电力公司检修公司 黄瑶玲 刘 浔 郑 华

本文针对2016年葛洲坝换流站极控制保护主机换型改造中出现的问题，进行了深入的研究和分析，发现了原有极控制保护主机软件监视逻辑存在的问题，通过完善监视逻辑，彻底解决了极控主机改造后的遗留问题。

换流站；直流控制保护系统；DSP

1.背景介绍

2016年葛洲坝换流站进行了控制保护系统升级工作，将原采用Windows NT平台的第一代PCS-9500系统，全面升级为采用Windows XP+Intime的第二代PCS-9500系统，工作包含全站27台工控机的系统软件升级，以及15台主机的硬件换型。控保系统换型工作在大修期间全部完成，但换型后出现极保护主机PCIA板卡频繁故障的情况。

2.故障情况

目前，葛洲坝换流站双极共4台极保护主机均出现了PCIA板卡DSP故障的情况，故障报文如图1所示：

图1 OWS事件报文

葛站换流变充电至2016年5月18日，共出现同类型故障14次，故障输出代码只出现过223、239和251三种，其中223代表DSP6故障，239代表DSP5故障，251代表DSP3故障，按照故障代码分类情况如表1所示：

表1 故障统计

DSP故障产生后，均在80ms内自动复归，现场主机及控保系统未见其他报警。

3.前期检查处理情况

极保护主机PCIA板卡DSP故障为瞬发性故障，且故障现象具有高度随机性，所以无法确定故障原因是由软件还是硬件造成，现场先后更换了P1PPRA、P1PPRB和P2PPRB主机的PCIA板卡，但更换后，以上主机均再次出现了PCIA的DSP故障，证明了故障原因和板卡硬件无关。初步怀疑板卡负载过高有可能导致此类故障，建议对极保护主机的PCIA板卡负载率进行优化。

2016年5月6号，厂家到葛洲坝站现场执行软件修改工作，软件修改后，极保护主机PCIA板卡负载率下降至60%。2016年5月10号，报警再次发出，表明降低负载并不能解决上述问题。

4.DSP故障检测原理分析

DSP故障监视软件页如图2所示：

图2 DSP监视

该图符的内部代码如下：

If dsp1_err=0FFH then

DSP_SUP_1=TRUE;

else DSP_SUP_1=FALSE;

If dsp2_err=0FFH then

DSP_SUP_2=TRUE;

else DSP_SUP_2=FALSE;

If dsp3_err=0FFH then

DSP_SUP_3=TRUE;

else DSP_SUP_3=FALSE;

If dsp4_err=0FFH then

DSP_SUP_4=TRUE;

else DSP_SUP_4=FALSE;

If dsp5_err=0FFH then

DSP_SUP_5=TRUE;

else DSP_SUP_5=FALSE;

If dsp6_err=0FFH then

DSP_SUP_6=TRUE;

else DSP_SUP_6=FALSE;

DSP故障判别基于PCI的周期。PPR/PCIA的周期为500us。PCIA/DSP_SUP页面中DSP_SUP符号读dspx_err信号，变化产生事件。dspx_err=1时,报故障，dspx_err=0时延时50ms报复归事件。由于页面执行周期为20ms，单次故障复归的时间应不超过80ms与葛站PCIA板卡故障复归时间基本一致。

按照以上分析，可得出以下两个结论：

1）葛站PCIA板卡故障是由于变量dspx_err突变为1所致。

2）葛站PCIA板卡故障都是在一个程序执行周期内检测到DSP故障后，在第二个周期马上就恢复正常。

截取DSP监视的相关处理代码，如下所示（由于6个DSP的处理过程相同，这里仅列举DSP1的处理程序）：

IF dsp1_started ＜＞ 00 then

do;

dsp1_status = dsp1(MSGR1);

IF (dsp1_status = old_dsp1_status) then

do;

err_dsp_nr = 1;

dsp1_err = 0ffH;

lastds = dsp1_status;

end;

else dsp1_err = 0;

old_dsp1_status = dsp1_status;

end;

对以上程序进行解读，其DSP完整的监视过程如图3所示：

图3 DSP故障检测

根据DSP故障检测过程，可以判断葛站PCIA板卡DSP故障原因为，PCIA板卡在单个执行周期内未检测到DPM内的对应DSP计数器值变化。

5.故障原因分析

由于已经排除了PCI板卡硬件故障的可能，若单从软件角度考虑，根据故障瞬时复归的特性，以下推论为一种可能的原因，即DSP程序写计数器的执行周期与PCIA板卡读计数器的周期不匹配。

若DSP程序写执行周期大于或接近于PCIA板卡的读执行周期，就可能出现PCIA板卡两次读取结果，落在DSP的同一个写周期内，从而导致PCIA读DSP计数器两次结果均相同，发出DSP故障。这类故障会在PCIA的下一个读周期内复归，与现场故障情况比较接近。

对站内DSP程序执行周期进行复核，情况如表2所示：

表2 DSP执行周期

按照DSP程序写计数器的执行周期与PCIA板卡读计数器的周期不匹配的推论，DSP程序写周期越快，发生DSP故障的概率应该越低，按照表2的统计结果来看，执行周期最慢的DSP6发生故障最多，但DSP1执行周期与DSP6完全一致确未发生任何故障。就目前的故障情况，还不能明确判断故障具体原因。

6.解决方案的确定

从葛站充电至今，现场人员一直在与厂家技术人员保持密切沟通，但仍然无法完全弄清故障发生的根本原因。

在此背景下本文提出了一套解决方案，通过增加防抖机制来解决葛站DSP故障瞬发的问题。具体思路为，用多个执行周期检测计数器值，即由单周期检测计数器值不变判DSP故障，改为多周期连续检测计数器值不变判DSP故障。

现场对此项工作的可行性和正确性进行了复核，发现了目前软件的DSP监视产生严重故障的逻辑配合方面，存在时序配合问题，原理图如图4所示：

图4 现场的DSP监视告警过程

图4中DSP的监视逻辑放在20ms的执行周期内，然后送入主CPU，经过10ms延时后发出严重故障将主机退出运行。但实际上每次DSP瞬发故障后，告警均瞬时产生，10ms的延时没有起到应有的防抖作用。

导致这个问题的原因，是由于DSP的监视逻辑放在了一个20ms执行周期的软件页面内，该页面所有变量的刷新速率为20ms，长于延时10ms。当DSP瞬时故障后，DSP监视逻辑的故障变量变为1，这时即使DSP故障已经消失，故障变量也必须等到下一个执行周期，也就是20ms后才能复归，从而使得原程序逻辑内的10ms延时防抖失去意义。将上述逻辑与其他换流站进行对比，以龙泉站MC1主机为例，其原理图如图5所示：

图5 龙泉站MC1主机PCIA板卡DSP监视告警过程

龙泉站的DSP监视逻辑放在了7.5ms执行周期内，短于延时20ms，故20ms延时能够起到防抖作用。另外，龙泉站阀短路保护未使用DSP监视故障进行闭锁。核查其他换流站的DSP监视逻辑，均设计了防抖延时，且防抖延时能够正常发挥作用。

查看葛站PPR主机的PCIB板卡，发现PCIB板卡也设计了10ms的防抖延时，但PCIB内的DSP监视功能放置在3ms的执行周期上，所以10ms的防抖功能可以发挥作用，这也是为何葛站PPR主机仅PCIA板卡出现DSP故障，而其余PCP，PPR的PS801板卡未发生DSP故障的原因。

另外，葛洲坝换流站使用DSP监视故障闭锁阀短路保护出口，也存在一定问题，DSP监视功能放置在20ms的执行周上，而阀短路保护执行周期为500微秒，远快于DSP监视功能。若DSP发生故障，DSP监视功能要在下一个执行周期，也就是20ms后，才能将故障闭锁信号送往阀短路保护，而这时阀短路保护已经动作出口，起不到应有的防误动作用。

总结以上分析结论，结合原葛站程序的设计意图，在恢复防抖延时作用的同时，应尽量保持现有软件其他时序逻辑和功能不变。根据这一思路，最终确定修改方案，其修改原理如图6所示：

图6 修改方案

新软件将DSP监视逻辑移至1ms执行周期内，通过增加4ms的延时防抖来产生严重故障，同时不改变现有阀短路保护时序。

7.小结

2016年5月19日，现场执行了软件修改联系单，从软件修改至今，葛站未发生一起PPR主机DSP故障退出运行的情况，证明该问题已经解决。葛站PPR主机PCIA板卡因DSP故障频繁退出的原因为：原防抖延时与软件执行周期配合不当导致防抖延时失效，通过恢复防抖延时的方式，已经解决该问题。

2016年5月24日至5月29日，葛南直流启动调试工作，双极直流带负荷试验成功。试验项目测试了谐波保护、极母线差动保护、欠压保护、突变量保护、阀短路保护，根据波形分析，保护逻辑动作完全正确，验证了目前葛站PPR功能正常。