一種適用于核電站應急指揮系統的軟件架構

北京廣利核系統工程有限公司 由玉偉，傅春霞，胡俊，趙慧麗

1 概述

核事故是指大型核設施（例如核燃料生產廠、研究堆、核電廠、核動力艦船及后處理廠等）發生的意外事件，可能造成廠內人員受到放射損傷和放射性污染。嚴重時，放射性物質泄漏到廠外，污染周圍環境，對公眾健康造成危害。

核事故應急是針對可能發生的核事故，進行控制、緩解、減輕核事故后果而采取的緊急行動。

核電站核事故應急涉及國家、地方政府、核電站等各個層面的核應急單位，為了將各級單位完善地整合起來，實現不同應急狀態下有效地應急聯動與應急處理，國家從法律、法規、導則、國標等方面進行了詳細的規定。

核電站是核事故處理的主體，當事故發生時，往往面臨時間緊，任務重的情況，為了更加有效地對事故進行處理，電站需要建設自己的應急系統。設計良好的核電站應急系統，能夠緊密貼合應急計劃，有效接收、存儲、分析、處理和發布來自不同區域的核電站的各種信息，并在事故突發期間快速形成準確的應急指揮指令，為應急管理和指揮決策提供強有力的技術支持，提高應急管理和指揮決策的科學性和時效性。如何設計一個良好的架構模型，是系統設計的關鍵問題。

2 業務模型

依照《核電廠核事故應急管理條例（HAF002）》以及《GB-T 17680核電廠應急計劃與準備準則》，核電站核事故應急主要處理過程概括來說為：

當應急情況發生時，核電廠應按照應急計劃中的基本程序，立即啟動應急響應活動。在應急響應過程初期，判斷應急響應等級，經相關部門批準，立即啟動應急響應，應急過程中，間隔一定時間根據所搜集數據重新評估應急狀態等級，并向上級報告，并在經過批準后，實施相應應急預案。當核事故已得到控制，而且幾乎恢復到安全狀態，并且滿足相應條件，可以終止應急響應。應急終止后，需要對應急過程中的資料進行整理、總結及評價，必要時修訂國家核應急預案。應急狀態終止后，各有關部門和單位按有關規定及時做出書面總結報告。

當發生嚴重事故，需要進入場外應急（總體應急）狀態時，核電廠營運單位向省核應急組織及時提出進入場外應急狀態的建議；省核應急組織向國家核應急協調委提出請求批準進入場外應急狀態報告；國家核應急協調委審批進入場外應急狀態。在事故情景十分危急時，省核應急組織可先決定進入場外應急狀態，而后立即向國家核應急協調委報告。國家核應急協調委及時向國務院報告進入場外應急狀態，必要時請求協調應急響應。

針對上述分析，核電站應急響應過程的業務模型可以分為三個部分，如圖1所示。

圖1 應急響應過程業務模型

第一部分：應急信息監督，主要是數據通訊、數據存儲和管理、人機界面顯示等功能。

第二部分：應急輔助分析，主要涉及到電站事故分級、堆芯狀態判斷、操作干預水平判斷、環境事故后果評價判斷等專業的算法模塊，各個模塊之間需要互相通訊。

第三部分：應急響應支持，主要涉及核事故狀態下的應急干預行動處理。

但是對于不同的核電站，應急業務還具有如下特點：

不同核電站具有不同的應急計劃，系統所需功能及功能實現細節并不完全相同；

不同核電站具有不同的應急組織架構，使用人員數量及角色不確定；

應急系統通常用作數據采集與監控，僅在應急情況或應急演習時才啟動響應；

3 技術環境

應急系統的技術環境有如下特點：

系統需要與核電站眾多第三方系統進行通訊，這些第三方系統實時性要求不同，程序接口不同，數據類型多種多樣；

系統常常需要集成一些專家系統，如堆芯損傷、機組診斷等，并與其進行數據交互；

系統通常運行在應急專用網，同時與核電站外部網、廠內專用數據網絡（如生產網和KNS網等）進行通信；

系統一般規模不大，大多為幾十臺操作站（秦山約為20臺、紅沿河約30臺），網絡通常與廠級辦公網隔離；

系統的軟件架構設計必須針對上述特點進行考慮。

4 軟件架構五視圖

應急軟件架構是實現功能需求的關鍵，多視圖方法是業界廣泛認同的一種架構設計思路，具體的多視圖方法種類繁多：

SEI的3視圖法：涉及視圖為模塊視圖、組件-連接器視圖、分配視圖；

西門子的4視圖法：涉及視圖為概念視圖、模塊視圖、代碼視圖、執行視圖；

RUP的4+1視圖法：涉及視圖為用例視圖、邏輯視圖、開發視圖、進程視圖、物理視圖；

其他…

本文采用的五視圖方法是由溫昱先生基于Philippe Kruchten于1995年提出的4+1視圖方法而來[5]，包括五個方面，如圖2所示。

邏輯架構：根據功能及非功能需求，對系統進行劃分。

物理架構：描述系統軟硬件之間的關系。

運行架構：描述系統軟件的控制流。

數據架構：描述系統軟件的數據存儲方式。

開發架構：描述系統軟件最終形成的軟件單元模塊，采用的編譯語言及依賴關系。

4.1 邏輯架構

應急系統在不同的核電站常常要面對不同種類的操作系統，不同的第三方應用軟件，不同的業務流程以及不同的組織架構。一個設計良好的系統應該能對這些變化做出快速的反應。

三層SOA（面向服務架構）具有松耦合的特性，可以按照模塊化的方式來添加新服務或更新現有服務，以解決新的需要，并可以支持把企業現有的或已有的應用軟件作為服務，能夠比較好地滿足應急系統需求，如表1所示。

SOA架構可以利用JAVA平臺和.NET平臺下的Web service或消息中間件的方式實現。

（1）JAVA平臺

JAVA平臺下實現SOA的技術有：JMS、EJB，JCA、RM I以及JBI模型，利用這些技術結合，可以在JAVA平臺下開發出靈活強大的SOA架構，如圖3所示。

（2）.NET架構

圖3 JAVA平臺下的SOA架構

微軟對SOA的支撐技術有ASP.net、Enterprise Service、WCF等，其中WCF是最優的技術。它是由微軟發展的一組數據通信的應用程序開發接口，是.NET框架的一部分，由.NET Framework3.0開始引入。WCF是一個統一的程序開發模型，對于數據通信提供了最基本最有彈性的支持。

從功能角度看，WCF可以看作是ASMX，.NET Remoting，Enterprise Service，WSE，MSMQ等技術的并集。利用WCF，可以解決包括安全、可信賴、互操作、跨平臺通信等需求。開發者不需要再去分別了解.NET Remoting，ASMX等各種技術。WCF具有以下特點：

統一性：WCF是對于ASMX，.Net Remoting，Enterprise Service，WSE，MSMQ等技術的整合。由于WCF完全是由托管代碼編寫，因此開發WCF的應用程序與開發其它的.Net應用程序沒有太大的區別。

互操作性：WCF最基本的通信機制是SOAP，只要支持標準的Web Service，可以跨進程、跨機器甚至于跨平臺的通信，例如J2EE應用服務器。

安全與可信賴：添加到SOAP消息中，以用于用戶認證，數據完整性驗證，數據隱私等多種安全因素。

兼容性：WCF充分地考慮到了與舊有系統的兼容性。安裝WCF并不會影響原有的技術如ASMX和.Net Remoting。即使對于WCF和ASMX而言，雖然兩者都使用了SOAP，但基于WCF開發的應用程序，仍然可以直接與ASMX進行交互。

從技術的角度講，JAVA和.NET沒有優劣之分，根據Evans數據公司的調查結果，這兩種技術在SOA總用量中“實際上不分勝負”，且采用JAVA和采用.NET開發的SOA均能夠實現跨平臺和跨系統的支持。

圖4為基于.NET的SOA架構技術方案。

4.2 物理架構

圖4 基于.NET的SOA架構技術方案

物理架構最重要的就是解決系統的部署問題，對于不同電站來說，其設備、網絡等要求往往也不相同，例如有的要求雙網通訊，有的要求單網通訊，有的要求服務器熱備，有的要求服務器冷備等，基于三層SOA架構，一個典型的部署如圖5所示：

圖5 基于三層SOA架構的典型

每部分針對的功能如表2所示：

4.3 運行架構

基于三層SOA架構的應急系統活動流圖如圖6所示：

表2 典型部署中每部分針對的功能

圖6 基于三層SOA架構的應急系統活動流程圖

系統流程為：

（1）工程師組態

系統在工程師站進行數據庫、算法、流程圖等的配置，并將配置結果下裝到web服務器與數據服務器。

（2）系統服務啟動

web服務啟動

web服務主要包含接口程序以及相關服務程序，部署在web服務器，系統啟動后，IIS服務啟動，服務端口開啟監聽，隨時處理來自于客戶端的請求。

數據服務啟動

數據服務分關系數據庫服務和實時數據庫服務，部署在數據服務器，系統啟動后，啟動相關服務程序，接收客戶端以及通訊程序的請求。

通訊服務啟動

通訊服務主要負責與應急支持系統通訊，部署在通訊服務器上，系統啟動后，與應急支持系統持續進行通訊，獲取相關數據。

（3）客戶端應用

客戶端提供主要的人機界面應用程序，其應用過程如下：

在瀏覽器中輸入地址，打開登錄窗口，輸入用戶名和密碼，web服務通過監聽來自客戶端的請求對其進行處理，如果是域用戶，則連接域服務器進行驗證，否則登錄驗證服務程序從數據庫中讀取數據，對用戶名和密碼進行驗證，將驗證結果返回客戶端。

通過驗證后，應急用戶可以進行應急設施設備管理、應急組織管理、應急演習管理、應急培訓管理、應急文檔管理、應急行動水平查詢及應急狀態輔助判斷操作，管理員可以進行維護及設置工作。

操作完成后，用戶退出。

4.4 數據架構

數據架構要解決的是數據的存儲問題，對于應急系統來說，它分為實時數據與非實時數據，需要根據情況分別保存在實時數據庫與關系數據庫。

4.5 開發架構

在開發架構層面，需要解決從用戶需求到系統開發技術選擇的問題，主要內容如下：

“邏輯職責”與“程序單元”的映射：將用戶的業務需求分配到相應的程序單元上。

開發技術選型：根據業務需求及組織現狀，確定開發語言、開發工具等。

“程序單元”間關系，確定系統架構，對公共部分進行整合，保證整體最優。

5 結束語

核電站應急系統在設計時面臨接口眾多，數據類型復雜，業務流程各有不同等特點，廣利核公司基于上述架構設計方法設計的Em InfoSys應急指揮系統，具有易于組態、易于維護、易于修改、操作簡便等優點，較好地滿足了不同核電站的應用需要，并已經應用到福清核電站，還將應用到海陽、臺山等，為應急狀態下應急管理以及指揮決策提供有力的支持。

[1] HAF102,國家核安全局核電站設計安全規定 [S].

[2] HAF002/01,國家核安全局核電站營運單位的應急準備和應急響應[S].

[3] HAF002,國務院核電站核事故應急管理條例[S].

[4] GB-T 17680,核電廠應急計劃與準備準則[S].

[5] 溫昱,軟件架構設計[M].北京:電子工業出版社 2007.