(西安中核核儀器有限公司,陜西 西安 710061)

1 背景概述

1.1 核電火警系統(tǒng)特殊性

核電火災報警系統(tǒng)依據GB 50116—2013火災自動報警系統(tǒng)設計規(guī)范，屬于控制中心火災報警系統(tǒng)，由火災報警控制器、操作員工作站、各種探測器、手動報警按鈕、聲光警報器燈等組成，其中火災報警控制器可通過聯(lián)網，對現(xiàn)場報警、聯(lián)動事件進行管理與控制，起到火災預防與消除的作用。核島主控室作為控制中心，核島火災報警控制器為系統(tǒng)核心主機，為了確保系統(tǒng)的健壯性，核島控制器由2臺火災報警控制器共同擔當，既可以分管所帶探測聯(lián)動回路，通過聯(lián)網也可以作為核電火災報警系統(tǒng)的冗余主機，單機出現(xiàn)故障或離線時，由另一臺完成對火災報警系統(tǒng)的管理控制。某典型核電火災報警控制系統(tǒng)示意圖如圖1所示，請注意圖中x(5或6)號核島控制器實際為2臺火災報警控制器，其余子項根據規(guī)模大小控制器數量不一。

圖1 核電火災報警控制系統(tǒng)示意圖Fig.1 Schematic of the fire alarm controlsystem of nuclear power plant

核電火災報警系統(tǒng)的特殊性在于聯(lián)動功能與DCS緊密相關，除自身聯(lián)動啟動消防設備之外，部分重要設備的啟動，如風機，需要由DCS啟動，部分重要設備的動作反饋信號，如新風閥，需要由DCS反饋，所以核島控制器需通過接口與協(xié)議與DCS保持通信。

1.2 冗余熱備

為了確保與DCS通信的可靠性，核電火災報警系統(tǒng)與DCS之間采取了雙主機雙鏈路的通訊連接模式，雙機保證了即使1臺主機檢修或故障，火災報警系統(tǒng)仍然能夠與DCS保持正常通信，雙鏈路則保證了，單一通道故障下，火災報警系統(tǒng)仍然能夠與DCS保持正常通信。而熱備的要求是，正常情況下僅使用某一通道的數據進行監(jiān)控，該鏈路通信失效時，自動切換去另一通道，但需實時在線監(jiān)測備用鏈路的有效性，防止鏈路切換時，才發(fā)現(xiàn)鏈路已故障。與之對應的，無檢測備用鏈路稱之為冷備。雙主機雙鏈路與DCS通訊鏈接示意圖如圖2所示。

圖2 雙主機雙鏈路DCS通訊示意圖Fig.2 Schematic of DCS communicationbetween dual host and dual link

2 設計實現(xiàn)

2.1 雙主機熱備

根據具體應用不同，可以把P2P(peer to peer)網絡大致分為集中式對等網絡，純分布式對等網絡，混合式對等網絡[1]。例如Napster、Gnutella、eDonkey、eMule、Maze、BT等，用戶可以直接從任意一臺安裝同類軟件的PC上下載或上傳文件，并檢索、復制共享的文件。其中集中式對等網絡(如Napster、QQ)基于中央目錄服務器，由它為網絡中各節(jié)點提供目錄查詢服務，傳輸內容則無需經過中央服務器。由于仍存在中央節(jié)點，容易形成傳輸瓶頸，集中式的擴展性比較差，不太適合大型網絡，但目錄集中管理，對于小型網絡的管理和控制上也是一種可行方案。典型的Napster架構如圖3所示。

圖3 Naspter集中式架構圖Fig.3 Naspter centralized architecture

集中型對等網絡中的節(jié)點都連接到一個中心目錄，在中心目錄發(fā)布或注冊自己共享的文件信息，在需要文件時，也連接到中心目錄查找索引。中心目錄接收到查詢請求時，在索引中選擇符合要求的最佳節(jié)點，如速度最快，距離最近，作為資源提供者。中心目錄模型圖如圖4所示。

圖4 中心目錄模型圖Fig.4 Central catalog model

火災報警系統(tǒng)網絡在核電工程應用中，規(guī)模不是太大，典型的核電應用場景中，通常由20～30臺火災報警控制器組成火災報警系統(tǒng)網絡，比較適用于集中式對等網絡，但是火災報警的重要性，又不能允許出現(xiàn)中央節(jié)點瓶頸，所以在集中型對等網絡的基礎上，輔以最小號推選機制，即正常監(jiān)控時，由最小號火災報警控制器擔任中央節(jié)點，維護同步列表，并發(fā)送至其他控制器保存，一旦最小號控制器因故障離線或與DCS失聯(lián)，立即由目前節(jié)點中的最小號，獲得虛擬系統(tǒng)維護令牌，接任中央節(jié)點，維護火災報警網絡信息的正常傳遞與記錄，如圖5所示。雙主機熱備可將核島主控室的2臺火災報警控制器主機分別設為1號與2號。

圖5 小號推選機制流程圖Fig.5 Flow chart of little number selection

2.2 雙鏈路熱備

在核島火災報警控制器1、2號機熱備的前提下，雙機分別以單獨的鏈路與DCS連接如圖6所示。

圖6 雙機數據流程圖Fig.6 Flow chart of dual host data

與冷備不同的是，此時DCS兩個端口均同時發(fā)送相同數據，首先以一條主鏈路A數據為準進行同步專用寄存器值的改查，主鏈路A、備用鏈路B同時回復應答；當主鏈路A出現(xiàn)故障后，由DCS進行判斷后，切換到以另一條鏈路B數據為準工作的模式。數據發(fā)送的時序關系如圖7所示。

圖7 雙機通訊時序圖Fig.7 Dual host communication sequence

2.3 設計要點

火災報警控制器與DCS之間通信為MODBUS協(xié)議，通過讀/寫專用寄存器列表來上傳報警信息與下達聯(lián)動/反饋指令。

MODBUS接口規(guī)范見表1。

表1 MODBUS接口表

正常情況下，由1號機負責接收DCS命令與向DCS報告事件，2～×號機的報警事件信息均通過火警網絡，傳送至1號機，由1號機主改寫專用寄存器列表值，等待DCS讀取，如果DCS下達聯(lián)動/反饋指令，由1號機主改寫專用寄存器列表值，通過火警網絡傳送至2～×號機，進行聯(lián)動行動或反饋顯示。此時專用寄存器列表由1號主機維護，并同步給2號機保存?zhèn)溆茫?號機只是應答DCS的查詢命令，表明鏈路熱備正常。非正常情況下，1號機與DCS因本身故障或鏈路故障，則利用小號推選機制，2號主機獲得虛擬維護令牌，主動作為火警系統(tǒng)的主機，利用備份寄存器列表與DCS開始通信。

但由于DCS指令可能為同步或異步發(fā)送的原因，雙主機接到命令或反饋可能有一定的時間差。在線巡檢命令與應答沒有問題，但因火警系統(tǒng)雙主機之間還有報警事件、聯(lián)動信息等需要同步，同一條命令/事件的寄存器讀寫將可能存在不一致問題。例如，發(fā)生報警事件后，在未完成寄存器列表同步之時，出現(xiàn)讀指令或鏈路切換，DCS會讀到不一樣的寄存器狀態(tài)，此時，需要DCS延時，待讀取寄存器狀態(tài)一致后讀取，或者是雙鏈路時默認主鏈路數據為準，單鏈路時以該鏈路數據為準。

2.4 可靠性分析

火災報警控制器雙主機冗余，既保證了火災報警系統(tǒng)的可靠性，也為與DCS通信雙鏈路冗余奠定了基礎?；馂膱缶刂破髦g的小號推選機制可以保證虛擬的系統(tǒng)維護令牌在火災報警控制器之間可靠傳遞，專用的DCS通信寄存器列表由系統(tǒng)維護令牌持有者維護，保證了寄存器列表的唯一性與正確性。與DCS通信雙鏈路熱備冗余，相對于冷備來講，可實時監(jiān)測鏈路的通訊狀態(tài)，防止故障于未然，避免了切換時，才發(fā)現(xiàn)備用鏈路故障的情況，極大地提高了火災報警系統(tǒng)與DCS之間通訊的可靠性，而由此帶來的，可能的應答數據不一致的問題，可以通過延時讀取，或確定數據通道來解決。

在實際項目通訊測試中的測試結果如表2所示。

表2 通訊測試結果

3 結 論

后續(xù)核電項目火災報警系統(tǒng)與DCS通訊，將以雙鏈路熱備冗余DCS模式為主，這樣才能最大程度地滿足核電設計可靠性要求。通過前期多個實際項目的冷備聯(lián)調，可以看到，DCS可以通過通信模塊，或設備多串口來實現(xiàn)冗余模式。由于位于通信發(fā)起的主動方，DCS可以識別通信鏈路的有效性，而熱備冗余通信的兩條鏈路會同時下發(fā)讀、寫請求，也可能異步下發(fā)，因此火災報警控制器需要實現(xiàn)可以獨立回應下發(fā)給自己的信息，還需要實現(xiàn)自己設備間的同步通信，同時需要防止數據震蕩，即始終同步不了。火災報警系統(tǒng)的控制器小號推選虛擬令牌傳遞輔以專用寄存器列表令牌維護的設計，實現(xiàn)了雙主機雙鏈路的熱備冗余。在虛擬測試中，基于工控機(Intel Atom N270，1.6 G主頻CPU，1 G DDR2 SRAM內存)為核心處理單元的火災報警控制器，通過網口，虛擬DCS雙串口，間隔3 s查詢的條件下，可以實現(xiàn)寄存器列表的同步，且滿足GB 4717—2005《火災報警控制器》中，控制器10 s內發(fā)出火災報警聲、光信號的要求，當模擬出現(xiàn)鏈路故障時，火災報警系統(tǒng)可以自動完成控制器虛擬令牌轉換，由熱備控制器依據備份專用寄存器列表與DCS進行通信。