SPPA-T2000平臺(tái)通訊點(diǎn)重名故障技術(shù)難題及解決方案

文登宇，蘇 正，張啟飛，馮 明

（臺(tái)山核電合營有限公司 儀控部，廣東 臺(tái)山 529228）

0 引言

現(xiàn)階段核電廠建設(shè)規(guī)模和數(shù)量持續(xù)增加的新市場經(jīng)濟(jì)常態(tài)下，數(shù)字化技術(shù)的廣泛應(yīng)用在為行業(yè)發(fā)展注入新動(dòng)力的同時(shí)，也使其面臨著巨大挑戰(zhàn)[1]。目前，核電站已進(jìn)入第三代，對(duì)安全性提出了更高的要求，以往的控制部分大多采用硬接線模擬量控制，已經(jīng)不能滿足因工程原則、人類工程學(xué)原則，DCS系統(tǒng)（分散控制系統(tǒng)）都具有模擬量控制系統(tǒng)無法比擬的優(yōu)越性[2]。核電站DCS系統(tǒng)負(fù)責(zé)控制并監(jiān)測整個(gè)電廠生產(chǎn)的全過程[3]，臺(tái)山核電站采用目前國際最先進(jìn)的第三代核電EPR技術(shù)，采用了先進(jìn)的DCS系統(tǒng)，完全集成了DCS系統(tǒng)高可靠性、開放性、靈活性，易于維護(hù)和協(xié)調(diào)性控制功能齊全等優(yōu)點(diǎn)[4]。臺(tái)山DCS系統(tǒng)由非安全級(jí)的SPPA-T2000系統(tǒng)（以下簡稱T2000）和安全級(jí)TXS系統(tǒng)組成[5]。該系統(tǒng)已經(jīng)過核級(jí)安全認(rèn)證，是核電站DCS領(lǐng)域最穩(wěn)定、可靠的系統(tǒng)之一[6]。T2000系統(tǒng)分為兩個(gè)層級(jí)，分別是Level 1自動(dòng)控制層和Level 2人機(jī)界面層[7，8]，其中Level 2層：機(jī)組監(jiān)督控制層，由主控、技術(shù)支持中心、遠(yuǎn)程停堆站、工程師站組成；Level 1層：機(jī)組自動(dòng)化層，由SAS、PAS、SAS DEC-B組成；Level 0層：現(xiàn)場接口層，為現(xiàn)場設(shè)備，由執(zhí)行傳感器和執(zhí)行器組成[9]。臺(tái)山核電的DCS平臺(tái)組成如圖1。

圖1 臺(tái)山核電DCS平臺(tái)組成Fig.1 Composition of Taishan Nuclear Power DCS platform

作為EPR機(jī)組全球首堆，臺(tái)山公司機(jī)組在機(jī)組調(diào)試啟動(dòng)階段不斷發(fā)現(xiàn)問題并產(chǎn)生了相應(yīng)的設(shè)計(jì)變更，其設(shè)計(jì)變更的數(shù)量遠(yuǎn)超國內(nèi)其它核電站同時(shí)期的變更。其中，安全級(jí)DCS（TXS平臺(tái)）設(shè)計(jì)變更較少，絕大多數(shù)設(shè)計(jì)變更為非安全級(jí)DCS（T2000平臺(tái)）修改。T2000 DCS平臺(tái)是一個(gè)在全球范圍內(nèi)被廣泛使用的成熟平臺(tái)，但在臺(tái)山項(xiàng)目，由于巨大的邏輯修改疊加不斷迭代的設(shè)計(jì)變更，導(dǎo)致T2000平臺(tái)在臺(tái)山EPR機(jī)組的工程實(shí)踐過程中出現(xiàn)大量非預(yù)期缺陷，且其中許多缺陷是T2000平臺(tái)在全球范圍內(nèi)首次被發(fā)現(xiàn)。這些非預(yù)期的缺陷如不能快速定位根本原因以及提出解決方案，將對(duì)臺(tái)山EPR機(jī)組的工程進(jìn)度造成直接制約以及給后續(xù)采用相關(guān)平臺(tái)及技術(shù)的EPR機(jī)組的安全運(yùn)行生產(chǎn)留下隱患。

本文選取T2000平臺(tái)在臺(tái)山EPR三代核電項(xiàng)目工程實(shí)踐過程中首次出現(xiàn)的技術(shù)難題——通訊點(diǎn)名重名故障進(jìn)行問題描述、原理說明、原因分析、解決思路、自主解決或聯(lián)合廠家最終給出最終解決方案。該技術(shù)難題的有效解決過程及思路，對(duì)全球范圍內(nèi)其它使用T2000平臺(tái)的機(jī)組具有直接的借鑒作用和參考價(jià)值。

1 通訊點(diǎn)名重名故障問題描述

臺(tái)山機(jī)組在熱態(tài)聯(lián)合調(diào)試期間發(fā)現(xiàn)，GCT（汽輪機(jī)旁路系統(tǒng)，邏輯分布在AP654中，AP：Automation Processor，自動(dòng)控制處理器的縮寫）在主控失去監(jiān)視。經(jīng)過調(diào)查發(fā)現(xiàn)，其直接原因?yàn)椋篜U01為主PU時(shí)（PU：Processing Unit，過程處理單元，用于連接Level 2監(jiān)控層和Level 1過程控制層），AP654與PU02（從PU）不能正常建立通訊連接，不能建立通訊的原因?yàn)椋篈P654與AP554出現(xiàn)通訊點(diǎn)（FC+Instance）重名。此時(shí)，疊加PU01進(jìn)程故障，PU01重啟，PU02變?yōu)橹鱌U。從而AP654與PU02/PU01的通訊全部失去，從而導(dǎo)致GCT在主控失去監(jiān)視。由于GCT在主控失去監(jiān)視，影響二回路正在進(jìn)行的AAD1510VL-調(diào)節(jié)能力試驗(yàn)，從而制約機(jī)組熱態(tài)測試主線工作。AP自動(dòng)控制器與PU過程處理單元在T2000系統(tǒng)結(jié)構(gòu)簡圖中的連接如圖2。

圖2 T2000系統(tǒng)結(jié)構(gòu)簡圖Fig.2 T2000 System structure diagram

2 通訊點(diǎn)名分配原理說明

在T2000平臺(tái)中，為了確保控制單元中每個(gè)信號(hào)功能塊的唯一性，所有AP代碼中的每個(gè)功能塊均被分配唯一的通訊實(shí)例名，實(shí)例名由FC+Instance組成（FC是Function Complex功能分區(qū)的縮寫，Instance是功能分區(qū)內(nèi)實(shí)體的編號(hào)），該通訊實(shí)例名在整個(gè)T2000平臺(tái)唯一。AP中的每個(gè)功能塊均通過唯一通訊實(shí)例名與PU（Processing Unit，過程處理單元）進(jìn)行通訊。在正常情況下，一個(gè)通訊實(shí)例名只會(huì)分配給AP代碼中的一個(gè)功能塊，如果在整個(gè)T2000平臺(tái)中出現(xiàn)兩個(gè)功能塊使用同一個(gè)通訊實(shí)例名，則會(huì)出現(xiàn)通訊沖突，導(dǎo)致存在重名功能塊的第二個(gè)AP在與PU通訊時(shí)存現(xiàn)通訊異常，從而使第二個(gè)AP無法與PU建立通訊。

3 通訊點(diǎn)名重名故障原因分析

3.1 直接原因分析

通過調(diào)查PU02的故障日志，日志中提示AP654中的通訊實(shí)例名FC45+ I No.（Instance number）7106已經(jīng)在AS（AP）554中存在，也意味著同一個(gè)FC+Instance number同時(shí)存在于AP554和AP654中，如圖3。

圖3 PU02故障定位日志信息Fig.3 PU02 Fault location log information

進(jìn)一步調(diào)查發(fā)現(xiàn)，該通訊點(diǎn)對(duì)應(yīng)的功能塊在ES680的數(shù)據(jù)庫中已經(jīng)刪除，但通訊點(diǎn)FC45+Instance 7106在AP554代碼中殘留，殘留在AP554中的代碼如圖4。

圖4 通訊點(diǎn)名FC45+Instance 7106殘留在AP554的代碼中Fig.4 Communication roll call FC45+Instance 7106 remains in the code of AP554

此外，由于該通訊點(diǎn)名FC45+Instance 7106在ES680數(shù)據(jù)庫中對(duì)應(yīng)的功能塊已經(jīng)不存在。因此，AP554中因刪除而閑置的通訊實(shí)例名（FC45+Instance 7106）被ES680重新分配給AP654新增的功能塊，如圖5。

圖5 通訊點(diǎn)名FC45+Instance 7106重新分配在AP654的代碼中Fig.5 The communication roll call FC45+Instance 7106 is reassigned in the code of AP654

AP654的功能塊被分配該通訊點(diǎn)名且其對(duì)應(yīng)的代碼編譯下裝后，AP654將刷新與PU的通訊連接。在AP654嘗試與PU02（從PU）刷新，重新建立通訊連接的過程中，PU02檢測到該通訊點(diǎn)名在AP554中已經(jīng)存在（PU02故障日志中顯示的內(nèi)容），從而導(dǎo)致AP654與PU02無法建立連接。

3.2 詳細(xì)原因分析

由于通訊實(shí)例名FC+Instance重名問題在T2000平臺(tái)首次被發(fā)現(xiàn)，相應(yīng)信息反饋德國SIMENS廠家后，SIEMENS研發(fā)人員在后臺(tái)無法復(fù)現(xiàn)通訊實(shí)例名FC+Instance重名現(xiàn)象，無法找到導(dǎo)致該問題出現(xiàn)的原因。但該問題如找不到根本原因和解決方案，現(xiàn)場隨時(shí)可能再出現(xiàn)相同問題。因此，在SIEMENS未能給出根本原因分析和解決方案的背景下，儀控人員通過把現(xiàn)場數(shù)據(jù)庫導(dǎo)入至模擬機(jī)，并進(jìn)行多場景復(fù)現(xiàn)測試，在通過模擬機(jī)50多個(gè)不同場景的測試和分析后，測試人員定位了故障原因?yàn)镾IEMENS的AP代碼編譯器存在Bug。在刪除模塊時(shí)，AP編譯器未調(diào)用實(shí)例表重新生成函數(shù)，導(dǎo)致被刪除模塊的原通訊實(shí)例名（FC+Instance）被保留在原AP代碼中，疊加設(shè)計(jì)修改的頻繁變更，大面積的邏輯變更導(dǎo)致該FC內(nèi)Instance資源耗盡，其它AP新增模塊時(shí)，將被迫使用相同F(xiàn)C內(nèi)其它模塊刪除閑置的Instance資源導(dǎo)致。TEC4功能圖進(jìn)行中修改邏輯圖到編譯成AP代碼，到最終形成通訊實(shí)例名沖突的流程如圖6。

圖6 通訊實(shí)例名重名沖突形成過程Fig.6 The formation process of the duplicate name conflict of the communication instance name

這里以一個(gè)刪除掉TEC4（TEC4：Technology Editor，EPR核電站過程控制組態(tài)工具）功能中的一個(gè)功能塊A進(jìn)行說明。一個(gè)功能塊在AP554的TEC4功能圖中刪除掉，從TEC4編譯到ES680的過程中，該功能塊A在ES680功能圖和數(shù)據(jù)庫中將同時(shí)被刪除掉，功能塊A對(duì)應(yīng)的通訊實(shí)例號(hào)（Instance Number）被釋放，隨后在ES680中編譯生成AP可下裝的代碼。如果在AP代碼編譯生成的過程中自動(dòng)調(diào)用了實(shí)例列表重新生成（regeneration instance list）功能，則編譯過程中將清除掉原AP代碼中所包含功能塊A對(duì)應(yīng)的通訊實(shí)例名。在這種情況下，即便是原功能塊A對(duì)應(yīng)的通訊實(shí)例名被ES680重新分配給其它AP的功能塊使用，也不會(huì)出現(xiàn)相同的通訊實(shí)例名。反之，如果在AP代碼編譯生成的過程中沒有自動(dòng)調(diào)用“regeneration instance list”功能，則編譯過程中將不清除原AP代碼中所包含功能塊A對(duì)應(yīng)的通訊實(shí)例名。

在該問題中，AP554的功能塊A被刪除后，在AP代碼編譯生成的過程中并沒有調(diào)用實(shí)例列表重新生成（regeneration instance list）功能。因此，功能塊A的通訊實(shí)例名殘留在AP554的運(yùn)行代碼中。而在AP654側(cè)，由于設(shè)計(jì)變更，增加了功能塊B，但FC45中的Instance資源由于頻繁的設(shè)計(jì)變更，Instance號(hào)碼資源已經(jīng)耗盡（Instance號(hào)碼資源使用只增不減，刪除掉一個(gè)功能塊后該功能塊的Instance號(hào)碼被廢棄，新增功能塊將采用新的Instance號(hào)碼）。所以在AP654增加新的功能塊B后，在AP代碼編譯的過程中，由于FC45中的按順序編碼的Instance資源已經(jīng)使用至最后一個(gè)編碼，數(shù)據(jù)庫將重頭開始重新檢索其它功能塊刪除后閑置的Instance資源，發(fā)現(xiàn)Instance7106由于AP554中的功能塊A在數(shù)據(jù)庫中被刪除后，處于閑置狀態(tài)，因此采用FC45+Instance7106作為新增功能塊B的通訊實(shí)例名。在AP654代碼編譯下裝后，與從PU建立通訊連接的過程中，PU檢測到出現(xiàn)重名FC45+Instance7106，從而拒絕與AP654建立連接。

綜上分析，可以得出結(jié)論：SIEMENS的AP代碼編譯工具中存在Bug（缺陷），在AP生成的過程中并不是每次均自動(dòng)調(diào)用“regeneration instance list”功能，從而導(dǎo)致被刪除功能塊A的通訊實(shí)例名在原AP代碼中殘留。疊加原FC中的Instance資源由于頻繁的設(shè)計(jì)變更，Instance號(hào)碼資源已經(jīng)耗盡。因此，被刪除的通訊實(shí)例名一旦被其它AP的新增功能塊B再次使用，則會(huì)造成通訊實(shí)例名FC+Instance出現(xiàn)重名，從而導(dǎo)致使用重名通訊實(shí)例的AP與PU的通訊失去。

另外從設(shè)計(jì)上而言，出現(xiàn)重名Instance只造成AP與從PU的連接故障，不影響與主PU的連接。這一點(diǎn)是合理的，一方面這樣的機(jī)制既然保障主PU與所有AP正常通訊，除了重名信號(hào)不可信外，不影響PICS顯示和操作；另一方面從PU持續(xù)不斷地檢測重名Instance，并不斷地嘗試與重名Instance的AP進(jìn)行重連，可確保一旦重名Instance消失后，可以有效建立與AP的連接，起到從PU的后備作用。且該過程中，該故障信息會(huì)持續(xù)在PU故障日記中進(jìn)行記錄，方便系統(tǒng)維護(hù)人員排查出現(xiàn)重名Instance的時(shí)間以及在哪些AP中的哪個(gè)功能塊出現(xiàn)了重名。

4 通訊點(diǎn)名重名故障解決方案

在通過模擬機(jī)的大量場景測試和重復(fù)試驗(yàn)后，初步分析、定位問題為SIEMENS AP代碼編譯軟件出現(xiàn)缺陷，疊加頻繁的設(shè)計(jì)變更導(dǎo)致FC內(nèi)Instance耗盡，并把分析結(jié)論反饋給SIEMENS廠家。隨后，SIEMENS廠家根據(jù)分析過程和結(jié)論，確認(rèn)AP代碼編譯器存在BUG，每次刪除功能塊并未強(qiáng)制調(diào)用“regeneration instance list”功能，從而導(dǎo)致ES680數(shù)據(jù)已經(jīng)刪除，但在AP代碼中仍然殘留，而編譯器在原FC的Instance資源耗盡后，將再次檢索使用之前刪除的Instance資源。

在SIEMENS確認(rèn)AP編譯器存在BUG后，答復(fù)從開發(fā)出可供現(xiàn)場使用的補(bǔ)丁之前，需要經(jīng)過代碼開發(fā)、代碼V&V測試、代碼兼容性測試等環(huán)節(jié)，才能釋放給現(xiàn)場，周期比較長。在該背景下，儀控人員經(jīng)過前期數(shù)據(jù)庫的分析和在模擬機(jī)多場景的驗(yàn)證，發(fā)現(xiàn)AP編譯器每次在增加功能塊的過程中都會(huì)調(diào)用實(shí)例列表重新生成（regeneration instance list）功能，給新增加的功能塊分配Instance。因此，在SIEMENS廠家未能給出安裝補(bǔ)丁前，現(xiàn)場采用以下臨時(shí)方案和措施進(jìn)行處理，避免再次出現(xiàn)通訊實(shí)例名重名造成通訊中斷，從而制約現(xiàn)場工作的開展。

1）通過ES680數(shù)據(jù)庫提取每個(gè)AP代碼中的FC+Instance信息，并進(jìn)行整合，確保所有AP中的FC+Instance信息在整個(gè)數(shù)據(jù)庫中唯一。同時(shí)，通過PU的日志提取通訊實(shí)例名重名錯(cuò)誤的關(guān)鍵字，確保當(dāng)前主從PU與所有AP的通訊進(jìn)程中，無通訊實(shí)例名重名出現(xiàn)。

2）在出現(xiàn)設(shè)計(jì)變更，必須進(jìn)行功能塊邏輯修改的情況下，通過查看AP代碼生成過程記錄，確保調(diào)用了實(shí)例列表重新生成（regeneration instance list）功能。如果沒有調(diào)用記錄，則人為刪除/增加強(qiáng)制功能塊，再次編譯生成代碼，“強(qiáng)迫”系統(tǒng)重新生成實(shí)例列表。

3）在AP下裝后，T2000平臺(tái)系統(tǒng)管理員檢查在PU故障日志檢查是否出現(xiàn)重名Instance情況，并做好記錄。如果出現(xiàn)重名，將對(duì)該AP進(jìn)行重新編譯，通過步驟2）的技術(shù)手段觸發(fā)實(shí)例列表重新生成，從而消除Instance重名。

通過實(shí)施以上臨時(shí)方案和措施后，所有AP與主從PU的連接均正常，現(xiàn)場未再出現(xiàn)通訊實(shí)例名重名沖突從而導(dǎo)致通訊中斷問題。

5 總結(jié)

EPR機(jī)組龐大的通訊邏輯設(shè)計(jì)，本身占用了T2000大量的系統(tǒng)通訊點(diǎn)名資源。且臺(tái)山EPR機(jī)組是全球首個(gè)EPR機(jī)組，在臺(tái)山EPR機(jī)組調(diào)試的過程中，機(jī)組設(shè)計(jì)組態(tài)的頻繁變更，使得T2000 DCS系統(tǒng)中所有的通訊點(diǎn)名資源被耗盡，從而出現(xiàn)了通訊點(diǎn)名資源重利用現(xiàn)象。

在通訊點(diǎn)名資源重利用的過程中，由于AP編譯器本身的缺陷，通訊點(diǎn)名資源刪除后，在數(shù)據(jù)庫中得到釋放，但在數(shù)據(jù)庫向AP代碼編譯過程中，未能刪除掉殘余通訊點(diǎn)名代碼，從而導(dǎo)致了通訊點(diǎn)名出現(xiàn)重名。

通過分析通訊點(diǎn)名的分配原理，通訊點(diǎn)名的資源使用方式，并對(duì)AP代碼編譯器編譯后的代碼進(jìn)行分析。最后，在模擬機(jī)平臺(tái)成功復(fù)現(xiàn)了通訊點(diǎn)名重名現(xiàn)象，找到通訊點(diǎn)名重名的根本原因，反饋給供應(yīng)商，并在供應(yīng)商的正式補(bǔ)丁下發(fā)前，采用自主分析的臨時(shí)方案對(duì)該缺陷進(jìn)行管控，有效地避免了通訊點(diǎn)重名故障在機(jī)組上再次出現(xiàn)，為機(jī)組后續(xù)的調(diào)試及商運(yùn)奠定基礎(chǔ)。對(duì)于采用T2000平臺(tái)技術(shù)的機(jī)組，在存在邏輯變更增量的條件下，其它T2000平臺(tái)的機(jī)組遲早會(huì)面臨資源耗盡重用問題，如果AP編譯器的缺陷未能得到解決，那么通訊重名導(dǎo)致通訊中斷問題必然會(huì)出現(xiàn)。因此，該技術(shù)難題的分析過程及有效解決處理過程及思路，對(duì)全球范圍內(nèi)其它使用T2000平臺(tái)的機(jī)組具有直接的借鑒作用和重要參考價(jià)值。