核電廠全范圍模擬機(jī)DCS通訊設(shè)計與性能驗證

張 瀟，舒 海，王童生

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

0 引言

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

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

1 通訊原理

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

圖1 邏輯結(jié)構(gòu)Fig.1 Logic structure

仿真模型與虛擬DCS 系統(tǒng)間的通訊接口可以采用不同的技術(shù)解決方案，目前較為主流的通訊方案中以O(shè)PC 與TCP/IP 通信協(xié)議為主要實現(xiàn)方式。OPC 是一個工業(yè)通信標(biāo)準(zhǔn)，它定義過程控制數(shù)據(jù)如何在軟硬件應(yīng)用中傳輸，為工業(yè)自動化軟件面向?qū)ο蟮拈_發(fā)提供了統(tǒng)一的標(biāo)準(zhǔn)[3]，采用OPC 技術(shù)作為虛擬仿真方案已經(jīng)廣泛應(yīng)用于仿真模擬機(jī)的開發(fā)應(yīng)用中。TCP/IP 協(xié)議作為Internet 的基本的協(xié)議，主要由網(wǎng)絡(luò)層的IP 協(xié)議和傳輸層的TCP 協(xié)議構(gòu)成[4]。TCP 是面向連接的通信協(xié)議，通過3 次握手建立連接。通訊結(jié)束時，需要主動與連接端斷開。協(xié)議自帶的傳輸再確認(rèn)、重傳、阻塞控制機(jī)制，可以很好地解決系統(tǒng)間數(shù)據(jù)同步的可靠性。該協(xié)議也是目前CPR1000/ACPR1000 核電廠全范圍模擬機(jī)采用的虛擬DCS 通訊集成方案。

2 通訊架構(gòu)

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

圖2 通訊架構(gòu)Fig.2 Communication architecture

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

3 功能設(shè)計

3.1 指令與狀態(tài)模式

全范圍模擬機(jī)系統(tǒng)的數(shù)據(jù)交換由仿真指令驅(qū)動，仿真指令由仿真模型發(fā)起，不同的指令會引起不同的系統(tǒng)狀態(tài)變化，DCS 系統(tǒng)狀態(tài)轉(zhuǎn)換必須與仿真模型保持一致，這是系統(tǒng)間通訊的前提。全范圍模擬機(jī)系統(tǒng)狀態(tài)大致可分為4種。

準(zhǔn)備模式：系統(tǒng)內(nèi)各軟件初始化完成后的狀態(tài)。這種狀態(tài)下，系統(tǒng)內(nèi)邏輯都處于不運算狀態(tài)，僅有通訊端口保持監(jiān)聽，等待指令的喚醒。

凍結(jié)模式：此時系統(tǒng)內(nèi)各軟件已完成通訊建立或者IC存儲/復(fù)位相關(guān)操作，系統(tǒng)軟件處于掛起狀態(tài)，等待新的指令。

運行模式：系統(tǒng)內(nèi)各軟件完成運行指令后的狀態(tài)。此時模擬機(jī)系統(tǒng)內(nèi)部的仿真模型與虛擬DCS 開始周期性地進(jìn)行數(shù)據(jù)包交換，所有軟件的功能、邏輯與算法都開始實時運算。

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

3.2 數(shù)據(jù)格式與點表

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

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

圖3 通訊點轉(zhuǎn)換Fig.3 Communication point conversion

3.3 通信時序

仿真模型與虛擬DCS 間的通訊由仿真模型發(fā)起，DCS系統(tǒng)應(yīng)答響應(yīng)，所有仿真指令的發(fā)送與應(yīng)答總是一個接一個地傳輸。

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

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

上述的指令時序?qū)儆谥芷诎噶睿ǔＧ闆r下DCS 會立即返回，但如果仿真指令與IC 操作相關(guān)，如存儲IC，則反饋數(shù)據(jù)可能需要等待較長的時間才能收到，具體的時間取決于虛擬DCS 執(zhí)行所消耗的時間。因此，為了保證系統(tǒng)的正常運轉(zhuǎn)，DCS 接收指令后會單獨開啟一個IC 存儲相關(guān)的線程任務(wù)在后臺執(zhí)行，而不影響主線任務(wù)，直到完成任務(wù)后再反饋給仿真模型。

3.4 超時控制

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

3.5 異常反饋機(jī)制

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

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

4 性能測試

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

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

表1 測試數(shù)據(jù)Table 1 Test data

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

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

圖6 丟包率Fig. 6 Packet loss rate

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

5 結(jié)論

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