核電廠全范圍模擬機DCS通訊設計與性能驗證

張 瀟，舒 海，王童生

（中廣核（北京）仿真技術有限公司，廣東 深圳 518028）

0 引言

隨著數字化儀控與仿真技術的不斷發展，具有高仿真度的虛擬DCS 逐漸成為核電廠全范圍模擬機主要開發方式。虛擬DCS 是將真實DCS 在非DCS 的計算機系統中以某種形式再現[1]，保留了實際DCS 的軟硬件系統結構、組態方法、算法模塊、系統管理等內容，能夠最大限度滿足操作員對各類機組故障培訓的需求[2]，因此受到了業主和操作員廣泛認可。虛擬DCS 與仿真支撐平臺的通訊接口開發是全范圍模擬機項目研制的關鍵技術之一，也是全范圍模擬機項目建設的關鍵路徑。

進入到三代核電時代，華龍1 號逐漸成為國內核電建設的主流。相比較于二代核電機組，其DCS 系統有著更為復雜的設計，特別是在系統多樣性設計原則下，IO 數據量有了成倍的增長，這對虛擬DCS 的通訊性能提出了很大挑戰。因此，DCS 通訊接口的穩定性與可靠性成為模擬機開發的重點任務，也是模擬機系統可用率的關鍵指標之一。

1 通訊原理

基于虛擬DCS 的核電廠全范圍模擬機參照了實際電廠機組DCS 系統采用的三層網絡架構，即Level 0，Level 1，Level 2。Level 0 層為現場控制層，主要以執行機構和傳感器為主的現場設備；Level 1 層為過程控制層，包括反應堆保護系統、T/G 控制系統和采集系統等；Level 2 層為操作監視層，包括用于主控室控制的KIC、BUP 等人機交互相關的操作。虛擬DCS 軟件由實際DCS 改造而成，并且根據用途的不同，分為非安全級與安全級。在保留原軟件的系統結構、組態方法、算法模塊、系統管理等內容功能的同時，還增加了模擬機軟件的專有功能，包括：仿真命令、數據處理、IC 存儲、故障模擬等。這些功能的實現與仿真模型的通訊接口有著緊密的聯系。虛擬DCS 與實際DCS 的邏輯結構如圖1。

圖1 邏輯結構Fig.1 Logic structure

仿真模型與虛擬DCS 系統間的通訊接口可以采用不同的技術解決方案，目前較為主流的通訊方案中以OPC 與TCP/IP 通信協議為主要實現方式。OPC 是一個工業通信標準，它定義過程控制數據如何在軟硬件應用中傳輸，為工業自動化軟件面向對象的開發提供了統一的標準[3]，采用OPC 技術作為虛擬仿真方案已經廣泛應用于仿真模擬機的開發應用中。TCP/IP 協議作為Internet 的基本的協議，主要由網絡層的IP 協議和傳輸層的TCP 協議構成[4]。TCP 是面向連接的通信協議，通過3 次握手建立連接。通訊結束時，需要主動與連接端斷開。協議自帶的傳輸再確認、重傳、阻塞控制機制，可以很好地解決系統間數據同步的可靠性。該協議也是目前CPR1000/ACPR1000 核電廠全范圍模擬機采用的虛擬DCS 通訊集成方案。

2 通訊架構

圖2所示，仿真模型與安全級、非安全級虛擬DCS 的Level 1 系統之間采用了基于C/S 架構的通訊方式。其中，虛擬DCS 軟件作為通訊服務端，負責監聽和響應仿真模型的通訊請求，仿真模型則作為通訊客戶端負責通訊連接與仿真指令的發起。DCS 接口程序基于仿真支撐平臺Genus 開發，采用C/C++語言實現，開發過程中需要利用DCS 廠家提供的通訊DLL 和通訊協議，它們是DCS 接口實現的基礎。DLL 基于Socket 的TCP/IP 協議封裝實現，負責通訊底層的收發與流量算法；通訊協議則規定了模擬機仿真指令與數據封包、解包的格式與方法等。

圖2 通訊架構Fig.2 Communication architecture

DCS 通訊接口開發需要解決通訊過程中的3 大類數據的傳輸問題：①仿真指令和仿真指令反饋數據，該類型數據是模擬機系統特有的仿真指令，包括：加載、凍結、復位IC、運行等數十種；②仿真模型與虛擬DCS Level 1非安全級、安全級的I/O 數據，這些數據是DCS 通訊的主要內容，包括AI、DI、DO、AO 以及故障模擬數據等；③非安全級與安全級DCS Level 1&Level 2 系統間的I/O 數據，既包括了Level1 層的數據，也包括了Level 2層的數據。如調屏網關指令等，該類型數據，仿真模型并不關注，但需要對其進行存儲轉發。

3 功能設計

3.1 指令與狀態模式

全范圍模擬機系統的數據交換由仿真指令驅動，仿真指令由仿真模型發起，不同的指令會引起不同的系統狀態變化，DCS 系統狀態轉換必須與仿真模型保持一致，這是系統間通訊的前提。全范圍模擬機系統狀態大致可分為4種。

準備模式：系統內各軟件初始化完成后的狀態。這種狀態下，系統內邏輯都處于不運算狀態，僅有通訊端口保持監聽，等待指令的喚醒。

凍結模式：此時系統內各軟件已完成通訊建立或者IC存儲/復位相關操作，系統軟件處于掛起狀態，等待新的指令。

運行模式：系統內各軟件完成運行指令后的狀態。此時模擬機系統內部的仿真模型與虛擬DCS 開始周期性地進行數據包交換，所有軟件的功能、邏輯與算法都開始實時運算。

回放模式：該模式與之前的運行模式基本一致，只是將模擬機切換至之前的某個時間點運行，所有的教員操作與學員操作都會反映到模擬機系統中。該模式下系統依然保持運算，并實時進行數據交換。

3.2 數據格式與點表

仿真模型與虛擬DCS 通訊的數據包格式采用了包頭+包體的形式，包頭部分包含了模擬機的專有字段信息，如：仿真時間、仿真指令、IC 編號等。包體部分則與實際機組的通訊結構保持一致。數據的打包需要嚴格按照通信協議規定的數據結構進行，否則會造成數據的解析失敗，因此仿真模型與DCS 系統間共享了相同的I/O 數據。

圖3所示，虛擬DCS 的I/O 數據由實際DCS 的組態數據生成，文件中包含了與I/O 變量相關的信息，這是通訊雙方數據一致的基礎。為了確保仿真模型與虛擬DCS 系統間通訊數據的匹配，DCS 系統會提供自己的I/O 數據供仿真模型解析轉換，形成仿真平臺可識別的數據庫格式，仿真平臺再通過共享內存機制，建立起仿真模型變量與DCS 變量間的對點映射。

圖3 通訊點轉換Fig.3 Communication point conversion

3.3 通信時序

仿真模型與虛擬DCS 間的通訊由仿真模型發起，DCS系統應答響應，所有仿真指令的發送與應答總是一個接一個地傳輸。

一個通訊周期由兩個仿真周期組成，如圖4。其為一個完整的DCS 通信周期的指令運行時序。當仿真模型與虛擬DCS 系統完成好通訊連接、復位IC、運行狀態同步后，系統開始執行第一個仿真周期。首先仿真模型側的通訊程序執行接收功能，由于DCS 系統還沒有數據發送，因而接收函數在此時將無數據接收。接收函數阻塞超過設定時間后執行發送函數，該過程需要將指令連同模型的輸入數據一同打包，再由DLL 發送給DCS。DCS 接收到數據后，會立即向仿真模型返回應答指令與數據。進入第二個仿真周期，仿真模型繼續運算，DCS 通訊接口程序則處于等待狀態，直到第二個仿真周期結束，即第一個DCS 通訊周期結束。進入第二個通訊周期，重新執行收發流程，此時仿真模型的DCS 接口程序才能接收到上一個通訊周期DCS 系統發來的應答指令和數據，仿真模型在確認接收成功后會立即發送新的指令與數據到DCS，隨后進入等待狀態，直到第二個通訊周期結束，如此周而復始。在這種機制下，仿真模型的DCS 通訊發送與接收并不在同一個通訊周期內完成，即仿真模型每次接收的數據都是DCS 系統上一個周期發送的。

圖4 指令運行時序Fig.4 Command execution sequential

上述的指令時序屬于周期包指令，通常情況下DCS 會立即返回，但如果仿真指令與IC 操作相關，如存儲IC，則反饋數據可能需要等待較長的時間才能收到，具體的時間取決于虛擬DCS 執行所消耗的時間。因此，為了保證系統的正常運轉，DCS 接收指令后會單獨開啟一個IC 存儲相關的線程任務在后臺執行，而不影響主線任務，直到完成任務后再反饋給仿真模型。

3.4 超時控制

實時性是仿真系統重要的性能指標之一，全范圍模擬機系統的實時性由仿真模型決定。在諸多的影響模擬機實時性的因素中，通訊實時性是其中的關鍵。DCS 通訊接口編程采用Socket 同步調用模式開發，這種通訊方式需要合理地設置好接收函數的超時時間，避免發生通訊阻塞延遲造成的平臺運行超時與死鎖問題，但同時也要確保仿真模型能夠完整地接收到數據。為了解決這個問題，針對不同的仿真指令設置不同的接收超時時間非常必要。通常不同仿真指令的超時設置從幾毫秒到幾十秒不等，時長取決于指令在后臺執行的時間，例如通訊連接、IC 相關的仿真指令會設置較長的超時等待時間，從而確保系統雙方的狀態同步。

3.5 異常反饋機制

DCS 通訊接口需要能精準地反饋通訊過程中的異常信息，從而及時向模擬機教員和運維人員反饋運行過程中發生的問題。因此，仿真模型與DCS 會針對每一個通訊周期進行數據包的檢測和判斷，如果內容與預期不符，需要及時返回錯誤代碼，并主動記錄在通訊日志中，必要時會終止通訊，確保仿真數據的準確性。

異常信息分為3 類：①指令執行異常，該類型錯誤主要表現為DCS 系統對數據包解析的異常，包括：指令執行超時、指令執行失敗、I/O 數據不一致等；②以Socket TCP 封裝的通訊動態庫定義的報錯信息，這些報錯信息通常定義在DLL 中，如內存溢出，緩存區異常，對端強制斷開等情況時，錯誤代碼會及時反饋給仿真模型；③特定的DCS 應用服務異常，該類型信息會針對具體的異常服務故障進行提示，如：計算服務器故障、歷史服務器故障等。

4 性能測試

衡量通信系統的性能主要歸納為兩個指標，即通訊有效性和通訊質量：①通訊有效性反映為通訊執行的速率，最直接的觀測指標是DCS 接口程序在一個仿真周期所持續的時間，其計算方法是利用兩次通訊周期運算所用的時鐘頻率計數之差求得；②網絡通訊質量反映為數據收發過程中產生的丟包率，通訊丟包率的算法公式如下：丟包率=（應發包數-實際收包數）/應發包數×100%。

本次測試，采用了ACPR1000 全范圍模擬機的數據與環境，其中仿真模型服務器選用聯想SR650，CPU 主頻3.4 GHz，操作系統為Window server 2016，千兆網絡設備。虛擬DCS 軟件包括：非安全級系統HOLLIAS_MACS、安全級系統FirmSys 以及基于SpeedHold 開發的多樣化系統（KDS）、嚴重事故系統（KDA）、P-GU 系統[5]。測試數據見表1，仿真模型需要向5 個虛擬DCS 系統依次發起通訊請求，并且在規定的通訊周期時間內完成5 次的數據發送與5 次的數據接收。

表1 測試數據Table 1 Test data

為了防止其他運算模塊對測試數據的影響，測試過程中僅保留與通訊和傳值相關的模塊。圖5 展示了仿真模型與虛擬DCS 通訊過程的周期執行時間，其曲線維持在47ms ～48ms，趨勢平穩，實時性滿足全范圍模擬機系統的運行周期要求。圖6 展示了仿真模型與虛擬DCS 通訊過程產生的丟包率，趨勢基本為0，且曲線平滑，反映出系統間的數據交換質量良好，無丟包現象。

圖5 通訊實時性Fig.5 Real time communication

圖6 丟包率Fig. 6 Packet loss rate

全范圍模擬機系統為了確保仿真的精度，會嚴格地按照設定的仿真周期調度系統內的運算，即實時模式。如果啟用非實時模式，系統有可能會出現“有多快，算多快”的快時模式，引起系統的全局加速，仿真模型的DCS 通訊數據發送也會加快。由于受限于DCS 邏輯運算的負荷[6]，會造成虛擬DCS 系統無法及時響應計算，導致明顯的數據丟包和延時問題，甚至通訊異常，因而需要謹慎使用快時模式。

5 結論

TCP 協議是一個面向連接的高可靠性通訊協議，作為全范圍模擬機虛擬DCS 集成的通訊方案具有很好的優勢，協議自帶的傳輸再確認、重傳、阻塞控制機制可以有效地實現仿真模型與虛擬DCS 系統間的數據交換。實踐證明，基于TCP 協議開發的DCS 通訊接口方案能夠滿足核電廠全范圍模擬機大數據、多系統通訊的功能與性能指標，并且其設計理念上與實際DCS 系統非常類似，兩者之間具有天然的可融合性，未來具備向DCS 半實物閉環驗證領域升級與拓展的能力。