華東桐柏抽水蓄能電廠機組LCU主備CPU異常切換研究

徐衛中，陳勤

(華東桐柏抽水蓄能發電有限責任公司，浙江天臺317200)

1 項目背景及問題的提出

1.1 項目背景

桐柏電廠計算機監控系統以冗余雙光纖環交換式工業以太網為工作平臺，以IEC870-5-104為通信規約。所有現地控制LCU都采用冗余的CPU(分別為C2和C4)和冗余網卡分別掛在雙光纖環網上，實現如下任務:

(1)實現真正的雙機冗余，保證任何一套LCU的主用CPU或主用網卡發生故障時，均能快速可靠地切換至另一套熱備用的CPU或網卡，保證控制任務能平穩無擾動的無縫切換。

(2)實現現地控制單元LCU之間、LCU與電廠控制級之間、LCU與保護、勵磁、調速器、機組在線監測、SIS等設備之間的以太網冗余通信。

因此，監控系統機組LCU的冗余主備CPU和冗余主備網卡的快速可靠平穩無縫切換對于桐柏電廠的機組安全穩定可靠運行具有極其重要的安全意義和極其重大的經濟意義。

1.2 問題的提出

從2005年12月中旬桐柏電廠計算機監控系統投產以來，在4臺機組的發電、抽水啟動過程中，每年均頻繁出現以下問題:

(1)桐柏電廠機組LCU的主備CPU會異常切換。

(2)機組LCU的主備CPU切換時間過長，長達50多s。

以上兩個原因最終導致機組開機啟動失敗，多次被上級調度部門考核，對桐柏電廠抽蓄機組的安全穩定運行和電廠的安全、經濟考核指標均造成了嚴重的影響。

2 問題的研究和分析

2.1 對抽水和發電啟動過程中，機組LCU的主備CPU異常切換問題的分析和研究

桐柏電廠機組LCU所配的兩塊冗余CPU分別為C2和C4，其分別帶有獨立的以太網卡。

機組LCU主備CPU的冗余工作原理為:主備CPU分別通過內部總線實時檢測自身和所有外圍板件(包括所配網卡)的工作狀態，并通過內部總線交換數據狀態；冗余CPU將各自檢測到的自身和所有外圍板件(包括所配網卡)的健康值匯總之后進行比較，健康狀況好的作為主用CPU運行工作，備用CPU則通過內部總線和主用CPU保持數據狀態實時同步。根據這一原理，結合機組LCU的冗余CPU主備切換控制邏輯程序RED_SWT.GPS，我們采用溯源的方法對機組LCU主備CPU(C2和C4)的切換邏輯進行了分析和研究:

(1)CPU主備切換控制邏輯中:GB-_C2_ACTIVE_C或GB-_C4_ACTIVE_C分別為切換激活機組LCUCPUC2(當CPUC4為主用時)或CPUC4(當CPUC2為主用時)的最終出口命令，根據邏輯可倒推出:產生GB-_C2_ACTIVE_C或GB-_C4_ACTIVE_C命令的條件是:命令LB-_activate_C2或LB-_activate_C4激活。

(2)命令LB-_activate_C2或LB-_activate_C4是由機組LCUCPUC2或CPUC4的相應三部分健康值通過算術和運算及大小比較而產生，這三部分健康值分別為:

1)CPU本身健康值:LA_Res_C2、LA_Res_C4；其由CPU本身自檢產生。

2)網卡健康值:LA_Res_C2_128、LA_Res_C4_128；其由對應的CPU實時檢測產生。

3)外圍板(指DI、DO、AI、AO板)健康值:LA_Res_C2_MPE1、LA_Res_C2_MPE2、LA_Res_C2_MPE3、LA_Res_C4_MPE1、LA_Res_C4_MPE2、LA_Res_C4_MPE3(MPE1、MPE2、MPE3分別指CPU所帶的三條外圍總線)；其由對應的CPU實時檢測產生。

系統對健康值的定義為:物理部件(如CPU、網卡、外圍板件)越健康(工作狀態越佳、故障越少越輕)，其相應的健康值越小。因此，可以推導出:當機組LCUCPUC2或CPUC4的總健康值(CPU本身健康值+網卡健康值+外圍板健康值)越大，表明該CPU當前的工作狀態越差，則系統邏輯會產生LB-_activate_C2或LB-_activate_C4的切換命令，命令系統切換到當前工作狀態更佳(總健康值更小)的CPU上去工作。

(3)至此，我們可以得出一個初步結果:導致機組LCU的主備CPU和主備網卡異常切換的原因是:當前主用CPU的總體健康值變大(大于備用CPU的當前健康值)。CPU的總體健康值是由三部分組成:CPU本身健康值+網卡健康值+外圍板健康值。因此，針對桐柏電廠的情況，進一步研究分析出究竟是哪一些健康值異常變大。

我們采用了在線動態實時監測法進行進一步的分析和研究:在機組發電、抽水的啟動過程中，我們將裝有實時監測軟件的筆記本電腦在線聯到機組LCU的主用CPU上，對邏輯中的CPUC2和CPUC4的三部分健康值進行實時監測。通過對各臺機組的長期在線實時監測，發現:在機組發電、抽水啟動過程中，每次機組LCU發生主用CPU切換至備用CPU之前的瞬間，其對應的網卡健康值LA_Res_C2_128或LA_Res_C4_128均不同程度的變大，使得當前主用CPU的總健康值大于備用CPU的總健康值，最終導致CPU切換。因此，可以認為:在機組發電、抽水啟動過程中，機組LCU主用CPU的網卡健康值異常變大，是導致CPU異常切換的原因。

(4)機組發電、抽水啟動過程中，機組LCU主用CPU的網卡健康值異常變大原因分析:

主用CPU的網卡健康值異常變大表明主用CPU的網卡工作狀態和性能下降，通過分析和歸納，導致網卡工作狀態和性能下降的原因不外乎以下幾種:

1)網卡本身軟、硬件損壞或存在軟、硬件性能下降缺陷；

2)該網卡所接的交換機相應端口工作不穩定，導致網卡通信異常；

3)連接該網卡的網線和RJ-45接頭工作不穩定(接觸不良)，導致網卡通信異常；

4)外界因素(如溫度、濕度、網卡網口通信流量等)的影響。

對于1)、2)、3)三種懷疑的原因，我們采用了替換法進行排查:

1)用新的網卡進行更換；

2)將該網卡所接的交換機端口更換至其它空閑的端口，甚至更換相應的交換機；

3)重新制作網線和RJ-45接頭并進行更換；

上述所有替換完成后，再次進行在線動態開機啟動測試，結果仍然為主用CPU的網卡健康值異常變大。由此，可排除1)、2)、3)這三種原因。

這樣，外界因素如溫度、濕度、網卡網口通信流量等則成為下一步的排查目標。通過采用紅外測溫儀和濕度儀對機組LCU盤柜內的溫度和濕度進行多次檢測，其溫度和濕度均在電子設備正常工作的范圍內，不可能導致CPU的網卡健康值異常變大。

因此，我們將排查分析重點放在網卡網口通信流量上。背景資料:

1)桐柏電廠機組為300MW的大型抽水蓄能機組，單臺機組的信號量要比同類常規水電廠機組的信號量多很多，接近5000點。

2)桐柏電廠的計算機監控系統采用VATECH公司特有的海王星(NEPTUN)系統，監控系統、保護系統、勵磁系統以及調速器系統均統一接入雙光纖環網的監控網絡平臺，現地控制單元LCU之間、LCU與電廠控制級之間、LCU與保護、勵磁、調速器、機組在線監測、SIS等設備之間均通過IEC60870-5-104規約實現以太網冗余通信。

基于上述兩點，我們分析認為:在機組開機過程中，機組LCU與保護系統、勵磁系統、調速器系統等外圍系統會有大量數據通過網絡進行交換，同時機組LCU還有大量數據要通過網絡上送到監控系統上位機，有可能會造成機組LCU的當前主用CPU自帶的網卡需處理的瞬時數據流量(負荷)過大，而目前所用的網卡SM-2554其緩存堆棧僅為50K，有可能會造成網卡緩存堆棧溢出，導致網卡死機。為驗證這一分析，我們用HERSIMAN交換機(桐柏監控系統網絡系采用HERSIMAN交換機)管理軟件對機組開機過程和穩態運行過程中的網卡端口(通過IP地址定位)流量進行實時監測，發現:在開機過程中，主用CPU自帶網卡的網口流量達到900kb/s，而在機組穩態運行過程中，其網口流量僅為30kb/s。這樣就證實了我們上述分析:在機組開機過程中，主用CPU自帶網卡所需處理的瞬時數據流量(負荷)確實相對過大。

查看機組LCU的冗余CPU主備切換控制邏輯程序RED_SWT.GPS中生成網卡健康值LA_Res_C2_128或LA_Res_C4_128的邏輯模塊:GB_P00_C2_128至GB_P15_C2_128(GB_P00_C4_128至GB_P15_C4_128)這16個中間量用來表示本網卡通過104規約與網上其它站點的通信狀態(由104規約進行通信判斷)，其賦值公式為GB_Pn_C_128=2n，其中GB_P15_C_128=215=32768代表本網卡死機，與全網所有的其它站點104通信全部中斷。這16個中間量通過多選一邏輯對LA_Res_C_128進行賦值，參與CPU總健康值累加和比較。為進一步證實我們的判斷，我們做了以下比較試驗:

1)在機組開機過程中，實時監視邏輯中的LA_Res_C_128變量的賦值，我們發現:每次切換發生時，LA_Res_C_128的賦值均為32768。

2)在機組開機過程中，人為拔出主用CPU網卡的網線，并實時監視邏輯中的LA_Res_C_128變量的賦值，發現:每次拔出網線時，LA_Res_C_128的賦值也均為32768。

這樣，就完全驗證了我們的判斷。

至此，我們可以得出結論:在抽水和發電啟動過程中，因桐柏機組LCU與保護系統、勵磁系統、調速器系統等外圍系統會有大量數據通過網絡進行交換，同時機組LCU還有大量數據要通過網絡上送到監控系統上位機，就造成機組LCU的當前主用CPU自帶的網卡需處理的瞬時數據流量(負荷)過大(達900kb/s)，而目前所用的網卡SM-2554其緩存堆棧僅為50K，這樣就極可能造成網卡緩存堆棧溢出使網卡死機，在邏輯上導致主用CPU的總體健康值變大(性能下降)，最終發生主備CPU異常切換。

2.2 對機組LCU的主備CPU切換時間過長導致開機失敗的問題的分析和研究

通過上述2.1對機組LCU的主備CPU異常切換的原因的分析，我們知道:對于桐柏機組LCU主備CPU異常切換的情況，在主備CPU冗余切換的邏輯程序RED_SWT.GPS中，CPU網卡健康值LA_Res_C2_128變量是啟動主備CPU冗余切換邏輯程序RED_SWT.GPS的源頭，只要LA_Res_C2_128變量發生變化，其后續的邏輯程序的執行(直至最終切換激活命令GB-_C2_ACTIVE_C的產生)是無延時的，因此，我們初步判定:從主用CPU網卡死機(即網卡的IEC870-5-104通訊全部中斷)到主用CPU網卡健康值LA_Res_C2_128變量被附值為32768的時間應是主備CPU切換時間過長的主要原因。

通過查閱研究IEC870-5-104通信規約的相關協議文件和規定，我們知道:IEC870-5-104通信規約判定網絡通信中斷一般是采用在連續一段時間(T104)內收不到有效的報文為依據的。當桐柏機組LCU的主用CPU網卡因死機通信中斷，且在連續一段時間(T104)內收不到有效的報文，則判斷104通信確實中斷，并產生激活GB_P15_C_128這一變量，由其對主用CPU網卡健康值LA_Res_C2_128賦值32768。因此，我們分析認為:桐柏電廠計算機監控系統IEC60870-5-104通信規約中對時間參數T104的設置較大會導致CPU切換時間過長。而在開機過程中，機組LCU順控程序需要間斷地(間隔時間較短，加延時共約15～25s左右)與外圍系統(如勵磁、調速器系統)進行信息交互(接受它們的狀態信息和向它們發出相關指令)，CPU切換時間過長(在這一切換時間段內，CPU與外界的通信是中斷的)則會導致機組LCU順控程序接受不到外圍系統的狀態信息，也無法向它們發出相關指令，從而會導致順控程序執行超時，使開機失敗。為驗證這一分析和判斷，我們做了如下試驗:

將裝有實時監測軟件的筆記本電腦在線聯到試驗機組LCU的主用CPU上，打開冗余CPU主備切換控制邏輯程序RED_SWT.GPS中生成網卡健康值LA_Res_C2_128或LA_Res_C4_128的邏輯模塊，人為拔出主用CPU網卡上的網線(為了準確地定義104通信開始中斷的時刻)，此時用秒表開始計時，當LA_Res_C2_128或LA_Res_C4_128被賦值32 768時，停止計時，秒表顯示的時長為49s。多次重復上述試驗，結果均為49s左右。

由此，我們可以得出結論:桐柏電廠計算機監控系統IEC60870-5-104通信規約中對通信中斷判斷時間參數T104的設置較大(約為49s左右)應是機組LCU的主備CPU切換時間過長并導致開機失敗的原因。

3 問題解決方案的研究和制定

3.1 抽水和發電啟動過程中，機組LCU的主備CPU異常切換問題解決方案的研究和制定

該問題的主要原因是:在機組抽水和發電啟動過程中，主用CPU自帶的網卡需處理的瞬時數據流量(負荷)過大(達900kb/s)和網卡上的緩存堆棧容量過小(僅為50K)。經初步研究，解決方案有二:

(1)通過修改提高送給機組LCU的各類模擬量(如溫度、震動、擺度)的自發上送門檻值來降低開機過程中的瞬時數據流量。

(2)通過加大網卡上的緩存堆棧容量來提高網卡的數據通信和處理能力。

經過進一步分析和研究，我們認為:

方案(1)盡管可以降低開機過程中的瞬時數據流量，但提高各類模擬量的自發上送門檻值后，會降低模擬量的精度，必然會降低監控系統對相關目標的測控精度。方案(1)不可行。

經過與VATECH公司的工程師聯系，得知:VATECH公司已有新版本的網卡SM-2556，該網卡有2M的緩存，其中用于緩存數據的存儲有1M，能保存更多的臨時數據，可極大的提高網卡的數據通信和處理能力。因此，決定采用方案(2)。

3.2 機組LCU的主備CPU切換時間過長導致開機失敗問題解決方案的研究和制定

該問題的主要原因是:桐柏電廠計算機監控系統IEC60870-5-104通信規約中對通信中斷判斷時間參數T104的設置較大(約為49s左右)。初看，解決方案很簡單:只要將T104時間常數改小(小于15s)即可。但事實卻并非如此:VATECH公司在當初編程時，將T104設為不可修改的常數，沒有向用戶和VATECH公司北京的工程技術人員提供任何可以修改T104的界面和程序，必須通過VATECH公司奧地利總部的編程工程師才能修改。通過VATECH公司北京的工程技術人員與VATECH公司奧地利總部聯系，答復為:無法修改。此方案被否。

通過對主備CPU冗余切換的邏輯程序RED_SWT.GPS進一步的研究和分析，我們構思了一套創新的方案:采用一種新的網卡通信狀態即時判斷(脈沖判斷)和CPU即時切換機制。具體介紹如下:

如圖1所示:我們在監控網絡中不同地點的交換機上增加2套冗余的實時網絡通訊狀態監測裝置，分別同時向4臺機組的現地控制LCU發送2路周期為1s的脈沖信號，作為監測機組LCU網卡工作是否正常的信號源。

圖1

4臺機組LCU的主備CPU通過各自的網卡同時接收來自2臺監測裝置的脈沖信號，并將其送入主備CPU冗余切換的邏輯程序RED_SWT.GPS的相關模塊(需新加更新)用于監測判斷其網卡通信狀態是否正常，當2路脈沖信號均丟失時，則即時判斷該網卡通信中斷。

基于上述構思，我們相應地對主備CPU冗余切換的邏輯程序RED_SWT.GPS中的相關模塊進行了更新設計，具體如下:

設計原則:在原來僅通過104規約判斷機制來測定網卡健康值的基礎上，增加通過檢測來自外部冗余的網絡通信檢測裝置的2路脈沖信號來即時測定健康值的邏輯，并將通過104規約判斷機制測定的網卡健康值和通過檢測2路脈沖測定的網卡健康值之和作為網卡的總健康值，參與主備CPU的切換邏輯運算，以實現快速切換。

設計更新后的相關邏輯共有4個，具體分別說明如下:

(1)脈沖檢測邏輯，其中GB_PULS1為來自于網絡通信監測裝置1的脈沖信號，GB_PULS2為來自于網絡通信監測裝置2的脈沖信號。

其邏輯功能是:當2路脈沖信號同時丟失超過5s，則立即判網卡通信中斷(LBX_PULSE_FAULT輸出信號躍變為高電平)。具體介紹如下:

當GB_PULS1和GB_PULS2兩路周期為1s的脈沖信號均正常時，4個延時為5s的延時器輸出均為低電平，通過隨后的“或”、“與”運算后，LBX_PULSE_FAULT信號也為低電平(表示網卡工作正常)；

當GB_PULS1和GB_PULS2兩路周期為1s的脈沖信號1路正常，另1路丟失(相應的端口電平表現為持續高或持續低)超過5s，通過后續相應的2個延時為5s的延時器和“或”運算后，輸出電平分別為一高一低，再通過“與”運算后，LBX_PULSE_FAULT信號也仍為低電平(表示網卡工作正常)；

當GB_PULS1和GB_PULS2兩路周期為1s的脈沖信號均丟失(相應的端口電平表現為持續高或持續低)超過5s時，通過后續相應的2個延時為5s的延時器和“或”運算后，輸出電平全為為高電平，再通過“與”運算后，LBX_PULSE_FAULT信號為高電平(表示網卡通信中斷)。

(2)網卡健康值計算邏輯以及切換閉鎖邏輯

其邏輯功能為:完成當前主用CPU的網卡健康值邏輯計算和切換閉鎖邏輯的任務。具體介紹如下:

當LBX_PULSE_FAULT信號為高電平后會觸發切換命令LBC_CPU_SWITCH，LBC_CPU_SWITCH命令表明當前主用CPU的網卡工作不正常，需要進行切換，將此信號和當前主用、備用CPU的狀態信號GB-_C2_ACT、GB-_C4_ACT進行邏輯“與”運算之后觸發激活備用CPU命令LBC_C2_ACT、LBC_C4_ACT，該命令通過MUX模塊將健康值32768累加到當前主用網卡健康值上，產生當前主用網卡健康值中間變量LA_C2_128_PRIORITY、LA_C4_128_PRIORITY，將該健康值送往邏輯用以判斷CPU的健康狀態。

另外，LBC_CPU_SWITCH命令還通過R-S(置位復位)觸發器確保在120s內不會被再次觸發，即在120s內將會閉鎖再次切換。此功能是為了防止CPU切換之后通訊沒有穩定造成的CPU頻繁切換。

(3)CPU總健康值計算及比較邏輯

其邏輯功能為:完成主備CPU的總健康值計算及比較邏輯的任務。具體介紹如下:

CPU的健康值由三部分組成:CPU本身健康值(LA_Res_C2或LA_Res_C4)+網卡健康值(LA_C2_128_PRIORITY或LA_C4_128_PRIORITY)+外圍板健康值(LA_Res_C2_MPE1、LA_Res_C2_MPE2、LA_Res_C2_MPE3或LA_Res_C4_MPE1、LA_Res_C4_MPE2、LA_Res_C4_MPE3)。

正常情況下，在沒有故障的時候，主用CPU和備用CPU健康值都為0(健康值越小越好，說明沒有故障，健康值會隨著故障程度的增加而增加)，所帶外圍版健康值也相同。如果主用CPU所帶網卡健康值LA_C2_128_PRIORITY、LA_C4_128_PRIORITY因為通訊故障而增大，經過“和”運算后，主用CPU的總健康值也會增大，與備用CPU的總健康值經過COMPARATOR模塊進行比較，并經過防抖濾波之后產生激活備用CPU的命令LB-_activate_C2、LB-_activate_C4。如果兩個CPU健康值相同，則激活當前CPU保持命令LB-_keep_CPU。

(4)最終主備CPU切換命令出口邏輯

其邏輯功能為:完成對主備CPU進行切換的任務。具體介紹如下:

當有切換命令LB-_activate_C2、LB-_activate_C4或者保持信號LB-_keep_CPU，將會產生CPU激活命令GB-_C2_ACTIVE_C、GB-_C2_ACTIVE_C，從而完成最終主備CPU的切換或者保持當前主用CPU的工作狀態。

對本方案可靠性的分析:

本方案的核心是通過快速判斷送往主用CPU網卡的兩路脈沖信號的同時丟失來實現對主備CPU的快速切換。我們分析認為:以下幾種情況會導致送往主用CPU網卡的兩路脈沖信號的同時丟失:

1)2套網絡通信監測裝置同時下電檢修

2)2套網絡通信監測裝置本體同時故障

3)2套網絡通信監測裝置的網卡同時故障

4)1套網絡通信監測裝置本體故障另外1套下電檢修

5)1套網絡通信監測裝置本體故障另外1套網卡故障

6)1套網絡通信監測裝置下電檢修另外1套網卡故障

7)機組LCU主用CPU網卡故障，通信中斷。

我們認為，1)、2)、3)、4)、5)、6)出現的概率非常低，這種小概率事件可以忽略不計。因此在正常情況下，只要送往主用CPU網卡的兩路脈沖信號同時丟失，我們可以判定是機組LCU主用CPU網卡故障，通信中斷，從而進行正常切換。

再者，我們還設計了將網絡通信監測裝置的故障信號實時上送到監控系統的上位機。即使出現極端的情況:上述、2)、3)、4)、5)、6)幾種狀況萬一出現，運行人員也能及時從監控系統的上位機讀到該故障信息，從而進行人工干預，以避免頻繁切換事件的發生。因此，本方案的可靠性是極高的。

所以，我們確信:采用這一新的方案，可以有效的實現我們的目標:當主用CPU的網卡通信中斷時，可以實現主備CPU的快速切換。

4 方案的實施和效果試驗驗證

4.1 網卡更新方案的實施和試驗驗證

(1)將一號機組LCU主備CPU的網卡SM-2554升級為新網卡SM-2556,并在相關數據庫里面完成相應的參數更新。

(2)進行多次重復開機試驗，觀察:是否會產生更換網卡之前的異常切換現象。結果:重復開機二十幾次，均未發生異常切換現象，且與各系統通訊也均正常。

(3)進行兩個星期的正常開停機觀測，結果:均未發生異常切換現象，且與各系統通訊也均正常。

(4)更換二號機組網卡，重復上述試驗，結果:均未發生異常切換現象，且與各系統通訊也均正常。

(5)對一、二號機組進行半年時間的監測，結果:均未發生異常切換現象，且與各系統通訊也均正常。

(6)將三、四號機組網卡全部更新為SM-2556，重復上述試驗和監測，結果:均未發生異常切換現象，且與各系統通訊也均正常。

4.2 新的網卡通信狀態即時判斷(脈沖判斷)和CPU即時切換機制方案實施和效果試驗驗證

(1)在中控樓公用LCU7現地控制柜內安裝第一套網絡通信監測裝置AMC1703(以下簡稱一號監測裝置)，硬件配置為:雙CPU、雙網卡和雙電源。

(2)在地下公用控制LCU5現地控制柜內安裝第二套網絡通信監測裝置AMC1703(以下簡稱二號監測裝置)，硬件配置為:雙CPU、雙網卡和雙電源。

(3)編寫上述邏輯程序模塊并下載，對原來的冗余CPU主備切換控制邏輯程序RED_SWT.GPS進行更新。

(4)進行網絡通信故障模擬試驗

分別對4臺機進行了網絡通信故障模擬試驗，以驗證所實施方案的有效性和可靠性。

模擬方式為:拔掉機組LCU主用CPU網卡的網線、一套網絡通信監測裝置下電、網絡通信監測裝置同時下電。以下是試驗結果:

1)拔掉機組LCU主用CPU網卡網線模擬主用CPU網卡故障。試驗記錄見表1:

表1 模擬主用CPU網卡故障

表1試驗數據表明:采用新的網卡通信狀態即時判斷(脈沖判斷)和CPU即時切換機制之后，主備CPU切換時間大幅度縮短，從原來的接近1min縮短到8s之內。且所有切換均平穩快速完成，從未發生因切換造成機組開機流程超時而導致開機啟動失敗或者停機現象。

2)將一套網絡通信監測裝置下電，模擬一路脈沖信號丟失。試驗記錄見表2:

表2 模擬一套網絡通信監測裝置故障

表2試驗數據表明:當一套網絡通信監測裝置發生故障時，不會導致機組CPU誤切換。

3)將兩套網絡通信監測裝置同時下電，1min之后再上電。模擬兩路脈沖信號同時丟失，1min后再恢復。試驗記錄見表3:

表3 模擬兩路脈沖信號同時丟失，1min后再恢復

以上試驗數據表明:當兩套監測裝置同時故障后，機組CPU能正確切換，并且在120s內不會發生二次切換，避免了主備CPU在短時間內的頻繁切換。

5 結論

本項目對華東桐柏抽水蓄能電廠4臺抽蓄機組在發電、抽水啟動過程中，頻繁出現的機組LCU的主備CPU異常切換，且切換不成功，導致機組開機啟動失敗的原因進行了研究和分析并闡述了解決方案的研究制定和實施、驗證。

通過試驗驗證和實際運行檢驗，本項目的研究是成功的，取得了理想的效果，有效地提高了桐柏電廠抽蓄機組的安全穩定運行水平和電廠的安全、經濟考核指標。研究成果對其他同類電廠也具有較強的借鑒意義。