國網(wǎng)湖北省電力公司檢修公司 戴 迪
三峽電力職業(yè)學(xué)院 王麗麗
國網(wǎng)湖北省電力公司檢修公司 黃瑤玲 劉 潯 鄭 華
葛站控保系統(tǒng)升級后PPR主機(jī)PCIA板卡頻繁故障原因分析
國網(wǎng)湖北省電力公司檢修公司 戴 迪
三峽電力職業(yè)學(xué)院 王麗麗
國網(wǎng)湖北省電力公司檢修公司 黃瑤玲 劉 潯 鄭 華
本文針對2016年葛洲壩換流站極控制保護(hù)主機(jī)換型改造中出現(xiàn)的問題,進(jìn)行了深入的研究和分析,發(fā)現(xiàn)了原有極控制保護(hù)主機(jī)軟件監(jiān)視邏輯存在的問題,通過完善監(jiān)視邏輯,徹底解決了極控主機(jī)改造后的遺留問題。
換流站;直流控制保護(hù)系統(tǒng);DSP
2016年葛洲壩換流站進(jìn)行了控制保護(hù)系統(tǒng)升級工作,將原采用Windows NT平臺(tái)的第一代PCS-9500系統(tǒng),全面升級為采用Windows XP+Intime的第二代PCS-9500系統(tǒng),工作包含全站27臺(tái)工控機(jī)的系統(tǒng)軟件升級,以及15臺(tái)主機(jī)的硬件換型。控保系統(tǒng)換型工作在大修期間全部完成,但換型后出現(xiàn)極保護(hù)主機(jī)PCIA板卡頻繁故障的情況。
目前,葛洲壩換流站雙極共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)場主機(jī)及控保系統(tǒng)未見其他報(bào)警。
極保護(hù)主機(jī)PCIA板卡DSP故障為瞬發(fā)性故障,且故障現(xiàn)象具有高度隨機(jī)性,所以無法確定故障原因是由軟件還是硬件造成,現(xiàn)場先后更換了P1PPRA、P1PPRB和P2PPRB主機(jī)的PCIA板卡,但更換后,以上主機(jī)均再次出現(xiàn)了PCIA的DSP故障,證明了故障原因和板卡硬件無關(guān)。初步懷疑板卡負(fù)載過高有可能導(dǎo)致此類故障,建議對極保護(hù)主機(jī)的PCIA板卡負(fù)載率進(jìn)行優(yōu)化。
2016年5月6號(hào),廠家到葛洲壩站現(xiàn)場執(zhí)行軟件修改工作,軟件修改后,極保護(hù)主機(jī)PCIA板卡負(fù)載率下降至60%。2016年5月10號(hào),報(bào)警再次發(fā)出,表明降低負(fù)載并不能解決上述問題。
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)檢測到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;
對以上程序進(jìn)行解讀,其DSP完整的監(jiān)視過程如圖3所示:
圖3 DSP故障檢測
根據(jù)DSP故障檢測過程,可以判斷葛站PCIA板卡DSP故障原因?yàn)?,PCIA板卡在單個(gè)執(zhí)行周期內(nèi)未檢測到DPM內(nèi)的對應(yīng)DSP計(jì)數(shù)器值變化。
由于已經(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)場故障情況比較接近。
對站內(nèi)DSP程序執(zhí)行周期進(jìn)行復(fù)核,情況如表2所示:
表2 DSP執(zhí)行周期
按照DSP程序?qū)懹?jì)數(shù)器的執(zhí)行周期與PCIA板卡讀計(jì)數(shù)器的周期不匹配的推論,DSP程序?qū)懼芷谠娇?,發(fā)生DSP故障的概率應(yīng)該越低,按照表2的統(tǒng)計(jì)結(jié)果來看,執(zhí)行周期最慢的DSP6發(fā)生故障最多,但DSP1執(zhí)行周期與DSP6完全一致確未發(fā)生任何故障。就目前的故障情況,還不能明確判斷故障具體原因。
從葛站充電至今,現(xiàn)場人員一直在與廠家技術(shù)人員保持密切溝通,但仍然無法完全弄清故障發(fā)生的根本原因。
在此背景下本文提出了一套解決方案,通過增加防抖機(jī)制來解決葛站DSP故障瞬發(fā)的問題。具體思路為,用多個(gè)執(zhí)行周期檢測計(jì)數(shù)器值,即由單周期檢測計(jì)數(shù)器值不變判DSP故障,改為多周期連續(xù)檢測計(jì)數(shù)器值不變判DSP故障。
現(xiàn)場對此項(xiàng)工作的可行性和正確性進(jìn)行了復(fù)核,發(fā)現(xiàn)了目前軟件的DSP監(jiān)視產(chǎn)生嚴(yán)重故障的邏輯配合方面,存在時(shí)序配合問題,原理圖如圖4所示:
圖4 現(xiàn)場的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)行對比,以龍泉站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í)序。
2016年5月19日,現(xiàn)場執(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)目測試了諧波保護(hù)、極母線差動(dòng)保護(hù)、欠壓保護(hù)、突變量保護(hù)、閥短路保護(hù),根據(jù)波形分析,保護(hù)邏輯動(dòng)作完全正確,驗(yàn)證了目前葛站PPR功能正常。