葛站控保系統(tǒng)升級(jí)后PPR主機(jī)PCIA板卡頻繁故障原因分析

國網(wǎng)湖北省電力公司檢修公司 戴 迪

三峽電力職業(yè)學(xué)院 王麗麗

國網(wǎng)湖北省電力公司檢修公司 黃瑤玲 劉 潯 鄭 華

葛站控保系統(tǒng)升級(jí)后PPR主機(jī)PCIA板卡頻繁故障原因分析

國網(wǎng)湖北省電力公司檢修公司 戴 迪

三峽電力職業(yè)學(xué)院 王麗麗

國網(wǎng)湖北省電力公司檢修公司 黃瑤玲 劉 潯 鄭 華

本文針對(duì)2016年葛洲壩換流站極控制保護(hù)主機(jī)換型改造中出現(xiàn)的問題，進(jìn)行了深入的研究和分析，發(fā)現(xiàn)了原有極控制保護(hù)主機(jī)軟件監(jiān)視邏輯存在的問題，通過完善監(jiān)視邏輯，徹底解決了極控主機(jī)改造后的遺留問題。

換流站；直流控制保護(hù)系統(tǒng)；DSP

1.背景介紹

2016年葛洲壩換流站進(jìn)行了控制保護(hù)系統(tǒng)升級(jí)工作，將原采用Windows NT平臺(tái)的第一代PCS-9500系統(tǒng)，全面升級(jí)為采用Windows XP+Intime的第二代PCS-9500系統(tǒng)，工作包含全站27臺(tái)工控機(jī)的系統(tǒng)軟件升級(jí)，以及15臺(tái)主機(jī)的硬件換型。控保系統(tǒng)換型工作在大修期間全部完成，但換型后出現(xiàn)極保護(hù)主機(jī)PCIA板卡頻繁故障的情況。

2.故障情況

目前，葛洲壩換流站雙極共4臺(tái)極保護(hù)主機(jī)均出現(xiàn)了PCIA板卡DSP故障的情況，故障報(bào)文如圖1所示：

圖1 OWS事件報(bào)文

葛站換流變充電至2016年5月18日，共出現(xiàn)同類型故障14次，故障輸出代碼只出現(xiàn)過223、239和251三種，其中223代表DSP6故障，239代表DSP5故障，251代表DSP3故障，按照故障代碼分類情況如表1所示：

表1 故障統(tǒng)計(jì)

DSP故障產(chǎn)生后，均在80ms內(nèi)自動(dòng)復(fù)歸，現(xiàn)場(chǎng)主機(jī)及控保系統(tǒng)未見其他報(bào)警。

3.前期檢查處理情況

極保護(hù)主機(jī)PCIA板卡DSP故障為瞬發(fā)性故障，且故障現(xiàn)象具有高度隨機(jī)性，所以無法確定故障原因是由軟件還是硬件造成，現(xiàn)場(chǎng)先后更換了P1PPRA、P1PPRB和P2PPRB主機(jī)的PCIA板卡，但更換后，以上主機(jī)均再次出現(xiàn)了PCIA的DSP故障，證明了故障原因和板卡硬件無關(guān)。初步懷疑板卡負(fù)載過高有可能導(dǎo)致此類故障，建議對(duì)極保護(hù)主機(jī)的PCIA板卡負(fù)載率進(jìn)行優(yōu)化。

2016年5月6號(hào)，廠家到葛洲壩站現(xiàn)場(chǎng)執(zhí)行軟件修改工作，軟件修改后，極保護(hù)主機(jī)PCIA板卡負(fù)載率下降至60%。2016年5月10號(hào)，報(bào)警再次發(fā)出，表明降低負(fù)載并不能解決上述問題。

4.DSP故障檢測(cè)原理分析

DSP故障監(jiān)視軟件頁如圖2所示：

圖2 DSP監(jiān)視

該圖符的內(nèi)部代碼如下：

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符號(hào)讀dspx_err信號(hào)，變化產(chǎn)生事件。dspx_err=1時(shí),報(bào)故障，dspx_err=0時(shí)延時(shí)50ms報(bào)復(fù)歸事件。由于頁面執(zhí)行周期為20ms，單次故障復(fù)歸的時(shí)間應(yīng)不超過80ms與葛站PCIA板卡故障復(fù)歸時(shí)間基本一致。

按照以上分析，可得出以下兩個(gè)結(jié)論：

1）葛站PCIA板卡故障是由于變量dspx_err突變?yōu)?所致。

2）葛站PCIA板卡故障都是在一個(gè)程序執(zhí)行周期內(nèi)檢測(cè)到DSP故障后，在第二個(gè)周期馬上就恢復(fù)正常。

截取DSP監(jiān)視的相關(guān)處理代碼，如下所示（由于6個(gè)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;

對(duì)以上程序進(jìn)行解讀，其DSP完整的監(jiān)視過程如圖3所示：

圖3 DSP故障檢測(cè)

根據(jù)DSP故障檢測(cè)過程，可以判斷葛站PCIA板卡DSP故障原因?yàn)椋琍CIA板卡在單個(gè)執(zhí)行周期內(nèi)未檢測(cè)到DPM內(nèi)的對(duì)應(yīng)DSP計(jì)數(shù)器值變化。

5.故障原因分析

由于已經(jīng)排除了PCI板卡硬件故障的可能，若單從軟件角度考慮，根據(jù)故障瞬時(shí)復(fù)歸的特性，以下推論為一種可能的原因，即DSP程序?qū)懹?jì)數(shù)器的執(zhí)行周期與PCIA板卡讀計(jì)數(shù)器的周期不匹配。

若DSP程序?qū)憟?zhí)行周期大于或接近于PCIA板卡的讀執(zhí)行周期，就可能出現(xiàn)PCIA板卡兩次讀取結(jié)果，落在DSP的同一個(gè)寫周期內(nèi)，從而導(dǎo)致PCIA讀DSP計(jì)數(shù)器兩次結(jié)果均相同，發(fā)出DSP故障。這類故障會(huì)在PCIA的下一個(gè)讀周期內(nèi)復(fù)歸，與現(xiàn)場(chǎng)故障情況比較接近。

對(duì)站內(nèi)DSP程序執(zhí)行周期進(jìn)行復(fù)核，情況如表2所示：

表2 DSP執(zhí)行周期

按照DSP程序?qū)懹?jì)數(shù)器的執(zhí)行周期與PCIA板卡讀計(jì)數(shù)器的周期不匹配的推論，DSP程序?qū)懼芷谠娇欤l(fā)生DSP故障的概率應(yīng)該越低，按照表2的統(tǒng)計(jì)結(jié)果來看，執(zhí)行周期最慢的DSP6發(fā)生故障最多，但DSP1執(zhí)行周期與DSP6完全一致確未發(fā)生任何故障。就目前的故障情況，還不能明確判斷故障具體原因。

6.解決方案的確定

從葛站充電至今，現(xiàn)場(chǎng)人員一直在與廠家技術(shù)人員保持密切溝通，但仍然無法完全弄清故障發(fā)生的根本原因。

在此背景下本文提出了一套解決方案，通過增加防抖機(jī)制來解決葛站DSP故障瞬發(fā)的問題。具體思路為，用多個(gè)執(zhí)行周期檢測(cè)計(jì)數(shù)器值，即由單周期檢測(cè)計(jì)數(shù)器值不變判DSP故障，改為多周期連續(xù)檢測(cè)計(jì)數(shù)器值不變判DSP故障。

現(xiàn)場(chǎng)對(duì)此項(xiàng)工作的可行性和正確性進(jìn)行了復(fù)核，發(fā)現(xiàn)了目前軟件的DSP監(jiān)視產(chǎn)生嚴(yán)重故障的邏輯配合方面，存在時(shí)序配合問題，原理圖如圖4所示：

圖4 現(xiàn)場(chǎng)的DSP監(jiān)視告警過程

圖4中DSP的監(jiān)視邏輯放在20ms的執(zhí)行周期內(nèi)，然后送入主CPU，經(jīng)過10ms延時(shí)后發(fā)出嚴(yán)重故障將主機(jī)退出運(yùn)行。但實(shí)際上每次DSP瞬發(fā)故障后，告警均瞬時(shí)產(chǎn)生，10ms的延時(shí)沒有起到應(yīng)有的防抖作用。

導(dǎo)致這個(gè)問題的原因，是由于DSP的監(jiān)視邏輯放在了一個(gè)20ms執(zhí)行周期的軟件頁面內(nèi)，該頁面所有變量的刷新速率為20ms，長于延時(shí)10ms。當(dāng)DSP瞬時(shí)故障后，DSP監(jiān)視邏輯的故障變量變?yōu)?，這時(shí)即使DSP故障已經(jīng)消失，故障變量也必須等到下一個(gè)執(zhí)行周期，也就是20ms后才能復(fù)歸，從而使得原程序邏輯內(nèi)的10ms延時(shí)防抖失去意義。將上述邏輯與其他換流站進(jìn)行對(duì)比，以龍泉站MC1主機(jī)為例，其原理圖如圖5所示：

圖5 龍泉站MC1主機(jī)PCIA板卡DSP監(jiān)視告警過程

龍泉站的DSP監(jiān)視邏輯放在了7.5ms執(zhí)行周期內(nèi)，短于延時(shí)20ms，故20ms延時(shí)能夠起到防抖作用。另外，龍泉站閥短路保護(hù)未使用DSP監(jiān)視故障進(jìn)行閉鎖。核查其他換流站的DSP監(jiān)視邏輯，均設(shè)計(jì)了防抖延時(shí)，且防抖延時(shí)能夠正常發(fā)揮作用。

查看葛站PPR主機(jī)的PCIB板卡，發(fā)現(xiàn)PCIB板卡也設(shè)計(jì)了10ms的防抖延時(shí)，但PCIB內(nèi)的DSP監(jiān)視功能放置在3ms的執(zhí)行周期上，所以10ms的防抖功能可以發(fā)揮作用，這也是為何葛站PPR主機(jī)僅PCIA板卡出現(xiàn)DSP故障，而其余PCP，PPR的PS801板卡未發(fā)生DSP故障的原因。

另外，葛洲壩換流站使用DSP監(jiān)視故障閉鎖閥短路保護(hù)出口，也存在一定問題，DSP監(jiān)視功能放置在20ms的執(zhí)行周上，而閥短路保護(hù)執(zhí)行周期為500微秒，遠(yuǎn)快于DSP監(jiān)視功能。若DSP發(fā)生故障，DSP監(jiān)視功能要在下一個(gè)執(zhí)行周期，也就是20ms后，才能將故障閉鎖信號(hào)送往閥短路保護(hù)，而這時(shí)閥短路保護(hù)已經(jīng)動(dòng)作出口，起不到應(yīng)有的防誤動(dòng)作用。

總結(jié)以上分析結(jié)論，結(jié)合原葛站程序的設(shè)計(jì)意圖，在恢復(fù)防抖延時(shí)作用的同時(shí)，應(yīng)盡量保持現(xiàn)有軟件其他時(shí)序邏輯和功能不變。根據(jù)這一思路，最終確定修改方案，其修改原理如圖6所示：

圖6 修改方案

新軟件將DSP監(jiān)視邏輯移至1ms執(zhí)行周期內(nèi)，通過增加4ms的延時(shí)防抖來產(chǎn)生嚴(yán)重故障，同時(shí)不改變現(xiàn)有閥短路保護(hù)時(shí)序。

7.小結(jié)

2016年5月19日，現(xiàn)場(chǎng)執(zhí)行了軟件修改聯(lián)系單，從軟件修改至今，葛站未發(fā)生一起PPR主機(jī)DSP故障退出運(yùn)行的情況，證明該問題已經(jīng)解決。葛站PPR主機(jī)PCIA板卡因DSP故障頻繁退出的原因?yàn)椋涸蓝堆訒r(shí)與軟件執(zhí)行周期配合不當(dāng)導(dǎo)致防抖延時(shí)失效，通過恢復(fù)防抖延時(shí)的方式，已經(jīng)解決該問題。

2016年5月24日至5月29日，葛南直流啟動(dòng)調(diào)試工作，雙極直流帶負(fù)荷試驗(yàn)成功。試驗(yàn)項(xiàng)目測(cè)試了諧波保護(hù)、極母線差動(dòng)保護(hù)、欠壓保護(hù)、突變量保護(hù)、閥短路保護(hù)，根據(jù)波形分析，保護(hù)邏輯動(dòng)作完全正確，驗(yàn)證了目前葛站PPR功能正常。