基于圖形化熱工水力測(cè)控程序的解釋性加載設(shè)計(jì)

向友洪，廖芳芳，付 玉，程 杰，王建宇

(中國(guó)核動(dòng)力研究設(shè)計(jì)院，成都 610213)

0 引言

隨著計(jì)算機(jī)技術(shù)和編程技術(shù)的發(fā)展，圖形化編程語(yǔ)言憑借其操作簡(jiǎn)便、易讀性好等優(yōu)點(diǎn)，形成了一系列有代表性的產(chǎn)品，如NI公司的LabView平臺(tái)[1]和Wonderware公司InTouch等工控組態(tài)軟件。針對(duì)熱工水力測(cè)控系統(tǒng)，其一般具備測(cè)點(diǎn)眾多、功能重復(fù)使用率較高的特點(diǎn)，因此，為了實(shí)現(xiàn)測(cè)控軟件系統(tǒng)的快速搭建、運(yùn)行，基于模塊化思想的圖形化編程[2-3]方式成為了重要的實(shí)現(xiàn)手段。

在熱工水力測(cè)控領(lǐng)域中，不同測(cè)控程序之間往往具有分布式運(yùn)行的部署特點(diǎn)，程序的編制和程序的運(yùn)行一般處于不同的終端上。而將圖形化測(cè)控程序從程序開(kāi)發(fā)終端部署到程序運(yùn)行終端，需要經(jīng)歷代碼到跨平臺(tái)可執(zhí)行程序的編譯轉(zhuǎn)化過(guò)程[4-5]。不同運(yùn)行終端環(huán)境需要對(duì)應(yīng)的編譯器去進(jìn)行編譯操作，否則會(huì)影響程序的正確運(yùn)行[6]。在跨平臺(tái)程序部署的常規(guī)實(shí)現(xiàn)方式上，通常采用程序開(kāi)發(fā)終端上通過(guò)圖形化界面生成源代碼，然后在整體性能較好的開(kāi)發(fā)終端上動(dòng)態(tài)調(diào)用本地相應(yīng)運(yùn)行終端的交叉編譯工具去對(duì)程序文件進(jìn)行交叉編譯[7-8]，最終得到該運(yùn)行終端的可執(zhí)行測(cè)控程序。但該方式會(huì)帶來(lái)以下幾個(gè)弊端：

1)在測(cè)控程序開(kāi)發(fā)過(guò)程中，往往存在對(duì)于測(cè)控程序進(jìn)行反復(fù)修改和調(diào)試的工作需求，若采用實(shí)時(shí)代碼編譯的模式，每次編譯、部署，均會(huì)帶來(lái)較長(zhǎng)的時(shí)間成本，特別是在軟件代碼量大、第三方組件多的情況下，會(huì)嚴(yán)重影響整個(gè)測(cè)控系統(tǒng)的調(diào)試、運(yùn)行效率。

2)程序開(kāi)發(fā)終端和程序運(yùn)行終端之間通常是不同的平臺(tái)環(huán)境，程序開(kāi)發(fā)終端一般為工控機(jī)，采用基于x86架構(gòu)的windows環(huán)境，而程序運(yùn)行終端一般為現(xiàn)場(chǎng)可編程控制器，具體環(huán)境因現(xiàn)場(chǎng)終端而異，如MIPS架構(gòu)下的linux環(huán)境。因此，需要運(yùn)行終端平臺(tái)在windows上有對(duì)應(yīng)的交叉編譯器，但目前暫沒(méi)用可兼容所有目標(biāo)平臺(tái)的完善交叉編譯工具鏈。

3)為滿足實(shí)時(shí)編譯的設(shè)計(jì)需求，圖形化開(kāi)發(fā)工具會(huì)針對(duì)不同的目標(biāo)程序部署平臺(tái)，集成對(duì)應(yīng)的程序編譯環(huán)境，會(huì)造成編程工具整體組成極為臃腫。

為了解決上述問(wèn)題，提出了一種基于解釋性加載機(jī)制的程序部署-運(yùn)行模式，在基于圖形化程序的分布式軟件系統(tǒng)應(yīng)用中，該模式有利于提高程序調(diào)試、部署和運(yùn)行的效率。

1 數(shù)據(jù)及邏輯關(guān)系建立及運(yùn)行規(guī)則設(shè)計(jì)

本文解釋性加載機(jī)制的設(shè)計(jì)實(shí)現(xiàn)所依托軟件對(duì)象為自主開(kāi)發(fā)的熱工水力圖形化測(cè)控程序編程平臺(tái)，該平臺(tái)基于Qt開(kāi)發(fā)，其主要系統(tǒng)及功能架構(gòu)如圖1所示。該平臺(tái)具備現(xiàn)場(chǎng)設(shè)備管理、圖形化程序開(kāi)發(fā)-調(diào)試-部署-運(yùn)行、分布式協(xié)同開(kāi)發(fā)等功能，可實(shí)現(xiàn)熱工水力測(cè)控程序完整的開(kāi)發(fā)、運(yùn)維流程。

圖1 圖形化編程平臺(tái)系統(tǒng)及功能架構(gòu)

在圖形化編程技術(shù)中，程序數(shù)據(jù)及邏輯關(guān)系的建立及運(yùn)行是一個(gè)十分重要的特征，即通過(guò)可視化建模技術(shù)[9]，來(lái)構(gòu)建圖形化程序的運(yùn)行邏輯。在自主開(kāi)發(fā)的圖形化編程平臺(tái)中，主要是通過(guò)標(biāo)準(zhǔn)化的圖形化編程控件和關(guān)系連線作為具象化元素，以控件拖拽、連線的交互方式，建立程序各編程功能控件之間的數(shù)據(jù)及邏輯關(guān)系。

在程序數(shù)據(jù)及邏輯關(guān)系建立及運(yùn)行機(jī)制中，按關(guān)系所屬范圍的不同，主要分為兩個(gè)層面：①單程序內(nèi)部圖形化編程元素(含編程控件和連線)之間的數(shù)據(jù)及邏輯關(guān)系；②多程序之間內(nèi)部圖形化編程元素(編程模塊)之間的數(shù)據(jù)及邏輯關(guān)系。

1.1 單程序內(nèi)部的數(shù)據(jù)及邏輯關(guān)系

單一圖形化測(cè)控程序中，編程控件之間數(shù)據(jù)及邏輯關(guān)系建立及運(yùn)行機(jī)制是程序編制、運(yùn)行的關(guān)鍵核心。根據(jù)對(duì)于控件之間等級(jí)關(guān)系的不同可劃分為兩類：①控件之間平級(jí)關(guān)系：在平級(jí)控件之間，其相互之間邏輯關(guān)系類似于順序關(guān)系，由源節(jié)點(diǎn)控件開(kāi)始，按照?qǐng)D形化“連線link”，順序依次運(yùn)行；②控件之間父子關(guān)系：由于“while”、“for”等結(jié)構(gòu)型編程控件的需求，導(dǎo)致屬于結(jié)構(gòu)控件內(nèi)部的編程控件運(yùn)行順序發(fā)生了變化，結(jié)構(gòu)型控件和其內(nèi)部所包含控件之間的關(guān)系類似于父子關(guān)系，運(yùn)行至結(jié)構(gòu)類控件時(shí)，進(jìn)入該控件內(nèi)部繼續(xù)執(zhí)行。

因此，單程序內(nèi)部編程控件之間的邏輯關(guān)系主要分為兩部分：①編程控件之間的連線關(guān)系；②編程控件之間的父子關(guān)系。

1.1.1 編程控件之間的連線關(guān)系

編程控件之間的連線關(guān)系為平級(jí)執(zhí)行關(guān)系，在同一層級(jí)中，其執(zhí)行關(guān)系為順序型執(zhí)行，其關(guān)系不僅適用于單個(gè)程序頂層的控件之間，也可適用于結(jié)構(gòu)型編程控件內(nèi)部的控件之間。

平級(jí)控件的執(zhí)行邏輯：控件通過(guò)連線接收上游控件數(shù)據(jù)，當(dāng)目標(biāo)控件的所有輸入端口全部收到數(shù)據(jù)后，會(huì)啟動(dòng)執(zhí)行控件內(nèi)置的運(yùn)行邏輯，執(zhí)行完畢后，控件會(huì)將執(zhí)行的值發(fā)送到該控件的各指定輸出端口上的連線，再通過(guò)該連線轉(zhuǎn)發(fā)給下游控件，以此類推，逐級(jí)轉(zhuǎn)發(fā)下去。

1.1.2 編程控件之間的父子關(guān)系

對(duì)于結(jié)構(gòu)型控件，由于其本身沒(méi)有固定的運(yùn)行邏輯，只是一個(gè)容器性質(zhì)的元素。因此，當(dāng)結(jié)構(gòu)型控件收到上游發(fā)送過(guò)來(lái)的運(yùn)行信號(hào)之后，其會(huì)阻塞該控件同一層級(jí)的運(yùn)行邏輯，然后按照平級(jí)關(guān)系之間的執(zhí)行邏輯去啟動(dòng)結(jié)構(gòu)內(nèi)的控件運(yùn)行；等到結(jié)構(gòu)內(nèi)的控件按照容器的規(guī)則(比如，條件結(jié)構(gòu)就運(yùn)行指定分支的邏輯，循環(huán)則重復(fù)運(yùn)行指定次數(shù))運(yùn)行完成，這時(shí)容器就會(huì)解除阻塞狀態(tài)，將所需結(jié)果從結(jié)構(gòu)內(nèi)輸出并轉(zhuǎn)發(fā)到下一級(jí)繼續(xù)運(yùn)行。

由于上述父子關(guān)系運(yùn)行流程的通用性，針對(duì)父子關(guān)系中不同結(jié)構(gòu)型控件多層嵌套的特殊情形，其運(yùn)行機(jī)制為逐級(jí)阻塞，執(zhí)行后再逐級(jí)解除。假設(shè)存在一個(gè)“for循環(huán)”嵌套一個(gè)“條件結(jié)構(gòu)”的情形，如圖2所示，當(dāng)運(yùn)行邏輯來(lái)到for循環(huán)時(shí)，for循環(huán)會(huì)先阻塞L1層邏輯，啟動(dòng)循環(huán)內(nèi)部邏輯；當(dāng)運(yùn)行流程走到條件結(jié)構(gòu)時(shí)，條件結(jié)構(gòu)同樣阻塞L2層邏輯，進(jìn)入條件結(jié)構(gòu)內(nèi)部；等到條件結(jié)構(gòu)運(yùn)行完成，解除L2層阻塞，繼續(xù)往下運(yùn)行；當(dāng)for循環(huán)內(nèi)部邏輯運(yùn)行完成之后，會(huì)通知for循環(huán)主體，然后for循環(huán)會(huì)根據(jù)循環(huán)次數(shù)決定是否繼續(xù)新一輪內(nèi)部邏輯運(yùn)行。

圖2 結(jié)構(gòu)型控件嵌套運(yùn)行流程示例

編程控件之間的父子關(guān)系在測(cè)控程序中的圖形化實(shí)現(xiàn)依托于圖形化編程平臺(tái)。自主開(kāi)發(fā)的圖形化編程平臺(tái)通過(guò)構(gòu)建視圖(view)-場(chǎng)景(scene)-元素(Item)三層架構(gòu)的圖形化編程體系模型，利用信號(hào)與槽機(jī)制實(shí)現(xiàn)對(duì)象之間的通信[10-11]。其中，視圖(view)作為交互層，用來(lái)展示場(chǎng)景中的元素，實(shí)現(xiàn)編程元素的可視化；場(chǎng)景(scene)作為一個(gè)抽象的元素管理容器；元素(Item)作為圖形元素的基本單位，是各類圖形編程元素功能代碼的實(shí)現(xiàn)的基礎(chǔ)類。

在上述模型中，不同層級(jí)之間的消息傳遞，通過(guò)事件穿透機(jī)制實(shí)現(xiàn)。視圖(view)接收用戶產(chǎn)生的鼠標(biāo)點(diǎn)擊、拖拽、懸停等操作；然后將事件傳遞給場(chǎng)景(scene)；最后再將事件傳遞給元素(Item)進(jìn)行指定控件功能的處理。

三層架構(gòu)每一層都有屬于自己的坐標(biāo)系，其中，設(shè)計(jì)視圖(view)和場(chǎng)景(scene)的坐標(biāo)系均采用左上角作為坐標(biāo)原點(diǎn)。而針對(duì)元素(Item)，為了控件內(nèi)部的繪圖方便，設(shè)計(jì)控件內(nèi)部的坐標(biāo)系采用其中心點(diǎn)為坐標(biāo)原點(diǎn)。在三層架構(gòu)的事件穿透中，就需要注意不同坐標(biāo)系下的坐標(biāo)轉(zhuǎn)換，不然會(huì)導(dǎo)致坐標(biāo)混亂。

因此，在結(jié)構(gòu)型控件和結(jié)構(gòu)內(nèi)的控件拖動(dòng)時(shí)進(jìn)行了聯(lián)動(dòng)移動(dòng)設(shè)計(jì)，一旦建立了控件間的父子關(guān)系，在父控件產(chǎn)生移動(dòng)操作時(shí)，其所有子控件均會(huì)收到父控件移動(dòng)的信號(hào)，而該信號(hào)里面包含偏移量參數(shù)值，通過(guò)該參數(shù)實(shí)現(xiàn)同步。

1.2 多程序之間的數(shù)據(jù)及邏輯關(guān)系

1.2.1 MQTT概述

MQTT(message queuing telemetry transport，消息隊(duì)列遙測(cè)傳輸協(xié)議)是一種基于發(fā)布/訂閱(publish/ subscribe)模式的“輕量級(jí)”通訊協(xié)議，其最大的特點(diǎn)是，以極少的代碼和有限的帶寬，為連接遠(yuǎn)程設(shè)備提供實(shí)時(shí)可靠的消息服務(wù)。MQTT協(xié)議的實(shí)現(xiàn)需要客戶端和服務(wù)器端，而在MQTT協(xié)議中有3種身份：發(fā)布者(Publish)、代理(Broker)、訂閱者(Subscribe)。其中，消息的發(fā)布者和訂閱者都是客戶端，代理是服務(wù)器，消息發(fā)布者也可以同時(shí)是訂閱者。

MQTT傳輸?shù)南⒎譃椋褐黝}(Topic)和負(fù)載(payload)兩部分。Topic為消息的類型，訂閱者(Subscribe)訂閱后，就會(huì)收到該主題具體的消息內(nèi)容(payload)[12-13]。

1.2.2 共享變量機(jī)制

在多測(cè)控程序的分布式應(yīng)用時(shí)，設(shè)計(jì)共享變量遠(yuǎn)程傳輸機(jī)制，實(shí)現(xiàn)不同測(cè)控程序之間的數(shù)據(jù)交互。該機(jī)制從功能設(shè)計(jì)上，通過(guò)變量管理器和共享變量編程控件兩部分實(shí)現(xiàn)，其中，共享變量管理器作為隱性的全局性變量容器，其中的變量可被網(wǎng)絡(luò)域中所有程序進(jìn)行訪問(wèn)，采用Tag機(jī)制[14]設(shè)計(jì)；共享變量控件作為顯性的圖形化程序編程控件，存在“讀取”、“寫入”兩種執(zhí)行邏輯，實(shí)現(xiàn)圖形化編程。

共享變量底層實(shí)現(xiàn)通過(guò)MQTT服務(wù)完成，MQTT服務(wù)在遠(yuǎn)端服務(wù)器上部署，由遠(yuǎn)端服務(wù)進(jìn)行管理，MQTT服務(wù)器作為共享變量中轉(zhuǎn)服務(wù)器。

在含共享變量控件的圖形化程序中，每次該控件運(yùn)行時(shí)，會(huì)創(chuàng)建一個(gè)臨時(shí)的MQTT客戶端，用于發(fā)布/接收最新的共享變量值。通過(guò)在MQTT服務(wù)上訂閱某個(gè)共享變量，通過(guò)該變量的32位VariantUuid在項(xiàng)目管理器中進(jìn)行查找，當(dāng)該共享變量的值發(fā)生變化，就會(huì)收到MQTT服務(wù)發(fā)送的消息信號(hào)。

因此，多程序之間的數(shù)據(jù)交互通過(guò)共享變量遠(yuǎn)程傳輸機(jī)制實(shí)現(xiàn)，數(shù)據(jù)進(jìn)入具體程序內(nèi)部后，再由單一程序內(nèi)部數(shù)據(jù)及邏輯關(guān)系規(guī)則管理，即實(shí)現(xiàn)從不同程序之間到單一程序內(nèi)部的完美接入。

2 解釋性加載機(jī)制原理設(shè)計(jì)

2.1 解釋性加載原理及規(guī)則

在圖形化程序數(shù)據(jù)及邏輯關(guān)系建立及運(yùn)行規(guī)則的基礎(chǔ)上，需要特定的解釋性規(guī)則來(lái)執(zhí)行圖形化程序的運(yùn)行解釋，其解釋性規(guī)則主要表現(xiàn)在圖形化程序的保存功能和恢復(fù)功能上，兩者都是解釋性規(guī)則的體現(xiàn)。由于各編程控件功能代碼相對(duì)固定，程序編制主要是配置程序包含哪些控件以及控件之間的邏輯關(guān)系，因此，本文所研究的解釋性加載機(jī)制，采用模塊化思想，將編程控件固定的功能代碼與程序非固定的配置關(guān)系相互分離，針對(duì)圖形化測(cè)控程序的發(fā)布、運(yùn)行，提出了一種新的設(shè)計(jì)思路：以終端程序模板(編譯后的終端程序模板)對(duì)程序文件(配置信息文件)進(jìn)行解釋性加載。

終端程序模板是一個(gè)通用的程序配置解析器，提前針對(duì)編程平臺(tái)所需兼容的目標(biāo)環(huán)境，將各功能控件的內(nèi)部實(shí)現(xiàn)代碼編譯完成并集成于圖形化編程平臺(tái)中，由于在實(shí)際程序部署過(guò)程中沒(méi)有編譯步驟，因此，此方法可避免實(shí)時(shí)編譯帶來(lái)的時(shí)間成本較大的問(wèn)題；同時(shí)，同一目標(biāo)環(huán)境下，該環(huán)境對(duì)應(yīng)的終端程序模板對(duì)部署至該目標(biāo)環(huán)境的所有測(cè)控程序具有通用性。

程序文件(配置信息文件)是解釋性加載機(jī)制中，程序配置信息的輸入。圖形化程序的執(zhí)行邏輯為：程序啟動(dòng)時(shí)，編程平臺(tái)的程序運(yùn)行管理模塊首先會(huì)遍歷查找圖形化程序中的所有運(yùn)行起點(diǎn)，判斷運(yùn)行起點(diǎn)的條件是：①該控件沒(méi)有輸入端口；②該控件沒(méi)有父節(jié)點(diǎn)。遍歷成功后，按照平級(jí)關(guān)系之間的執(zhí)行邏輯和父子關(guān)系之間的執(zhí)行邏輯，按照具體的程序設(shè)計(jì)邏輯完成運(yùn)行。因此，程序文件(配置信息文件)其主要包含三部分內(nèi)容：控件配置信息、連線配置信息和共享變量配置信息，前兩項(xiàng)實(shí)現(xiàn)單程序內(nèi)部的數(shù)據(jù)及邏輯關(guān)系的配置，第三項(xiàng)進(jìn)行多程序之間數(shù)據(jù)及邏輯關(guān)系的配置。

程序發(fā)布過(guò)程中，圖形化編程平臺(tái)會(huì)將適應(yīng)目標(biāo)環(huán)境的程序模板和用戶編程產(chǎn)生的程序文件一起發(fā)布至運(yùn)行終端。程序本地/遠(yuǎn)程部署運(yùn)行主要由以下兩個(gè)模塊支撐：1)程序運(yùn)行管理模塊；2)場(chǎng)景與配置文件保存恢復(fù)模塊。當(dāng)用戶啟動(dòng)程序或程序自啟動(dòng)時(shí)，程序模板通過(guò)加載程序文件來(lái)恢復(fù)用戶的編程邏輯，將其加載到場(chǎng)景中，再配合程序運(yùn)行管理模塊，實(shí)現(xiàn)程序的運(yùn)行。解釋性加載機(jī)制基本原理如圖3所示。

圖3 解釋性加載機(jī)制基本原理

2.2 程序保存及恢復(fù)邏輯

基于解釋性加載原理及規(guī)則的設(shè)計(jì)基礎(chǔ)，對(duì)圖形化程序的保存和恢復(fù)機(jī)制進(jìn)行了具體設(shè)計(jì)，確定圖形化程序文件的生成保存、加載恢復(fù)邏輯，分別如圖4～5所示。

圖4 圖形化程序保存邏輯設(shè)計(jì)

圖5 圖形化程序恢復(fù)邏輯設(shè)計(jì)

3 解釋性加載機(jī)制應(yīng)用設(shè)計(jì)

3.1 程序文件設(shè)計(jì)

程序文件作為配置型文件，包含用戶所編寫程序的控件配置信息、連線配置信息和共享變量配置信息，因此，根據(jù)配置項(xiàng)信息，將程序文件按結(jié)構(gòu)化數(shù)據(jù)模式進(jìn)行設(shè)計(jì)。

在常規(guī)結(jié)構(gòu)化數(shù)據(jù)中，一般采用XML和JSON作為具體文件形式，相較于XML，JSON具有更加簡(jiǎn)潔性、序列化和反序列化時(shí)的速度高和處理占用CPU資源更少等特點(diǎn)[15-16]。在滿足圖形化程序解釋性加載程序文件設(shè)計(jì)的基礎(chǔ)上，采用了JSON格式作為程序文件的具體格式，保證了程序文件輕量級(jí)、易讀性、運(yùn)行效率等方面均要具有較好的特性。

程序文件的內(nèi)容設(shè)計(jì)中，按JSON格式對(duì)具體的配置項(xiàng)信息進(jìn)行了設(shè)計(jì)。其中，“控件配置信息(Items)”包含BackObjectName、BackPosotionX/Y、Title、InputCount、OutputCount等通用參數(shù)和不同控件的特有參數(shù)，在解釋性加載時(shí)復(fù)原用戶對(duì)于控件的編程信息；“連線配置信息(Lines)”包含RranchUUID、SourceObject、TargetObject、SourceLinkedPointID、TargetLinkedPointID等參數(shù)，在解釋性加載時(shí)復(fù)原用戶對(duì)于連線的編程信息，其中通過(guò)SourceObject(源控件身份標(biāo)識(shí))、TargetObject(目標(biāo)控件身份標(biāo)識(shí))、SourceLinkedPointID(源控件連線端口ID)、TargetLinkedPointID(目標(biāo)控件連線端口ID)4個(gè)參數(shù)，實(shí)現(xiàn)了圖形化編程單條連線關(guān)系的唯一性和方向性；“共享變量配置信息(Progarm)”包含SharedVariant、MqttServerIp、LibSharedVariant等參數(shù)，在解釋性加載時(shí)復(fù)原用戶對(duì)于共享變量的編程信息。

典型程序文件的結(jié)構(gòu)示意如下：

{

"Items": [

{

控件1配置信息 //此處為For、While等

"ChildItems":[ //此處控件1嵌套控件2

{

控件2配置信息

}

},

{

控件n配置信息

},

],

"Lines": [

{

連線1配置信息

},

{

連線2配置信息

},

{

連線n配置信息

},

],

"program": [

{

"LibSharedVariant"配置信息

},

{

"SharedVariant":[

{

共享變量1配置信息

},

{

共享變量2配置信息

},

{

共享變量n配置信息

},

]

},

{

"MqttServerIp"配置信息

}

]

}

3.2 終端程序模板設(shè)計(jì)

終端程序模板為一種編譯后的產(chǎn)物類型，針對(duì)不同終端目標(biāo)環(huán)境，其對(duì)應(yīng)有不同的終端程序模板的具象化實(shí)參。不同的終端程序模板可通過(guò)交叉編譯器或者在各自目標(biāo)環(huán)境中通過(guò)本地編譯獲得，集成到圖形化編程平臺(tái)的安裝文件中，即可實(shí)現(xiàn)多目標(biāo)平臺(tái)終端程序模板的同步兼容。在程序部署時(shí)，由編程平臺(tái)中的識(shí)別模塊對(duì)目標(biāo)環(huán)境進(jìn)行自適應(yīng)識(shí)別，并進(jìn)行決策，最終執(zhí)行程序部署操作。

圖6 多程序模板兼容的實(shí)現(xiàn)機(jī)制

4 解釋性加載機(jī)制驗(yàn)證

4.1 典型程序運(yùn)行驗(yàn)證

以驗(yàn)證解釋性加載機(jī)制的有效性為目的，利用圖形化編程平臺(tái)編制實(shí)現(xiàn)“循環(huán)加法”功能的應(yīng)用程序，該應(yīng)用程序的具體實(shí)現(xiàn)邏輯為：通過(guò)For循環(huán)，執(zhí)行循環(huán)5次，首次循環(huán)時(shí)，接受循環(huán)外“初始值”和循環(huán)內(nèi)“加數(shù)”執(zhí)行加法操作；后續(xù)四次循環(huán)，通過(guò)For循環(huán)移位寄存器模式，將上一次循環(huán)“加”運(yùn)算的輸出結(jié)果和“加數(shù)”執(zhí)行加法操作，最終For循環(huán)結(jié)束后通過(guò)“和”控件顯示輸出。

該程序“和”控件運(yùn)行顯示結(jié)果為5，與預(yù)期結(jié)果一致，表明解釋性加載機(jī)制，可實(shí)現(xiàn)圖形化程序的加載恢復(fù)并正確運(yùn)行。其中，測(cè)試程序文件片段如圖7所示。

圖7 For循環(huán)加法測(cè)試程序文件片段

4.2 熱工水力試驗(yàn)臺(tái)架驗(yàn)證試驗(yàn)

4.2.1 回路運(yùn)行試驗(yàn)

為了進(jìn)一步驗(yàn)證解釋性加載機(jī)制對(duì)于熱工水力測(cè)控系統(tǒng)的分布式適應(yīng)性，利用圖形化編程平臺(tái)中的各類型圖形編程控件，對(duì)熱工水力試驗(yàn)臺(tái)架測(cè)控系統(tǒng)進(jìn)行測(cè)控程序開(kāi)發(fā)，具體涉及熱工回路監(jiān)控、測(cè)點(diǎn)曲線顯示、預(yù)熱器控制、本體加熱等試驗(yàn)業(yè)務(wù)功能。

以自主研發(fā)的多總線兼容可編程終端控制器和現(xiàn)場(chǎng)總線控制系統(tǒng)[17-18]為依托，該控制器CPU采用龍芯3A3000高性能4核通用處理器[19]，基于linux3.0內(nèi)核的國(guó)產(chǎn)支持Loongnix操作系統(tǒng)，通過(guò)背板高速通信總線和總線插槽板卡實(shí)現(xiàn)多總線信號(hào)的板卡兼容[20]。本熱工水力試驗(yàn)測(cè)控系統(tǒng)中，包含CAN、Profibus PA、MODBUS RTU三種常用現(xiàn)場(chǎng)通信總線以及AIO、DIO信號(hào)。

本次測(cè)試中，測(cè)控程序部署目標(biāo)環(huán)境包含上位機(jī)(x86-windows)、下位機(jī)(MIPS-linux)兩種環(huán)境，進(jìn)行了熱工水力試驗(yàn)臺(tái)架的本體升溫、測(cè)點(diǎn)監(jiān)控等功能的回路運(yùn)行試驗(yàn)，其中，采集、存儲(chǔ)、顯示、數(shù)據(jù)處理等程序均正常運(yùn)行。

4.2.2 測(cè)量精度試驗(yàn)

通過(guò)標(biāo)準(zhǔn)信號(hào)源設(shè)備給現(xiàn)場(chǎng)儀表輸入標(biāo)準(zhǔn)信號(hào)，記錄CAN通信、Profibus PA通信、MODBUS RTU通信、AIO的現(xiàn)場(chǎng)信號(hào)值和上位機(jī)程序的顯示信號(hào)值，并計(jì)算出每一組試驗(yàn)數(shù)據(jù)所對(duì)應(yīng)的誤差，試驗(yàn)數(shù)據(jù)如表1～5所示。

表1 CAN試驗(yàn)數(shù)據(jù)及誤差

表2 Profibus PA試驗(yàn)數(shù)據(jù)及誤差

表3 MODBUS RTU試驗(yàn)數(shù)據(jù)及誤差

表4 AI試驗(yàn)數(shù)據(jù)及誤差

表5 AO試驗(yàn)數(shù)據(jù)及誤差

通過(guò)現(xiàn)場(chǎng)短接DI通道，記錄并查看DI的現(xiàn)場(chǎng)輸入狀態(tài)和上位機(jī)程序的顯示狀態(tài)是否一致；通過(guò)上位機(jī)設(shè)定DO輸出狀態(tài)，測(cè)量并查看DO的現(xiàn)場(chǎng)輸出狀態(tài)和上位機(jī)程序的設(shè)定狀態(tài)是否一致，具體試驗(yàn)結(jié)果如表6所示。

表6 DIO狀態(tài)試驗(yàn)數(shù)據(jù)

試驗(yàn)結(jié)果進(jìn)一步證明，該解釋性加載機(jī)制具有多目標(biāo)運(yùn)行終端環(huán)境兼容性的特點(diǎn)，同時(shí)可實(shí)現(xiàn)熱工水力試驗(yàn)測(cè)控系統(tǒng)圖形化程序的動(dòng)態(tài)加載與運(yùn)行，滿足熱工水力試驗(yàn)測(cè)控系統(tǒng)的開(kāi)發(fā)要求。

5 結(jié)束語(yǔ)

針對(duì)圖形化測(cè)控程序編制過(guò)程中，實(shí)時(shí)編譯帶來(lái)的編譯時(shí)間長(zhǎng)、編譯環(huán)境復(fù)雜等問(wèn)題，通過(guò)對(duì)圖形化程序數(shù)據(jù)及邏輯關(guān)系的分解與重構(gòu)，提出了終端程序模板+輕量級(jí)配置文件的工作機(jī)制，通過(guò)程序模板對(duì)該配置信息文件進(jìn)行解釋性加載，實(shí)現(xiàn)圖形化測(cè)控程序的快速部署與運(yùn)行。通過(guò)開(kāi)展測(cè)試程序以及熱工水力試驗(yàn)臺(tái)架的測(cè)試驗(yàn)證，試驗(yàn)結(jié)果表明，該機(jī)制真實(shí)、有效，可實(shí)現(xiàn)圖形化熱工水力測(cè)控程序的快速部署與加載運(yùn)行。

同時(shí)，該方案具有較好的可擴(kuò)展性，現(xiàn)階段本圖形化編程平臺(tái)已實(shí)現(xiàn)x86-windows、x86-linux、MIPS-linux三種環(huán)境架構(gòu)的支持，后續(xù)可通過(guò)編譯不同的終端程序模板并集成于圖形化編程平臺(tái)安裝文件中，實(shí)現(xiàn)更多目標(biāo)環(huán)境的擴(kuò)展兼容。