李繼偉，李雪強(qiáng)，遲海龍，李亦凡

（北京中水科水電科技開(kāi)發(fā)有限公司，北京 100085）

0 引言

隨著智能化水電站、一體化平臺(tái)的不斷建設(shè)，計(jì)算機(jī)軟件、硬件性能的提高，業(yè)主對(duì)水電站監(jiān)控系統(tǒng)人機(jī)交互的需求越來(lái)越復(fù)雜，不同業(yè)務(wù)之間的交互功能要求也越來(lái)越高，運(yùn)行人員希望在一體化平臺(tái)中獲取更多的業(yè)務(wù)展示。水電站業(yè)務(wù)數(shù)據(jù)主要分水調(diào)、電調(diào)兩類(lèi)，其中水調(diào)業(yè)務(wù)專(zhuān)業(yè)性較強(qiáng)，成果展示手段非常豐富，而電調(diào)業(yè)務(wù)實(shí)時(shí)性較強(qiáng)，數(shù)據(jù)也比較全。一體化平臺(tái)的建設(shè)需要深入融合水調(diào)和電調(diào)業(yè)務(wù)，雙方的業(yè)務(wù)數(shù)據(jù)需要實(shí)時(shí)交互；同時(shí)為了支持、簡(jiǎn)化第三方應(yīng)用的接入以及為滿(mǎn)足未來(lái)擴(kuò)展的需要，保護(hù)業(yè)主已有投資，需支持后續(xù)業(yè)務(wù)的無(wú)縫接入，最終實(shí)現(xiàn)多業(yè)務(wù)模型與數(shù)據(jù)在跨平臺(tái)、跨主機(jī)上數(shù)據(jù)展示層的集中統(tǒng)一展示。

在現(xiàn)有的水電一體化平臺(tái)中，普遍采用中間庫(kù)的方式實(shí)現(xiàn)數(shù)據(jù)交換，存在數(shù)據(jù)實(shí)時(shí)性不高、交互邏輯組態(tài)復(fù)雜的困難，因此本文基于數(shù)據(jù)信息流模型，設(shè)計(jì)了一套水電站多業(yè)務(wù)一體化人機(jī)交互模型框架，為水電站復(fù)雜業(yè)務(wù)交互提供了一種簡(jiǎn)單、有效的集成手段。本框架通過(guò)對(duì)信息流數(shù)據(jù)的構(gòu)建、接口轉(zhuǎn)換、后臺(tái)引擎驅(qū)動(dòng)、集成展示等多項(xiàng)技術(shù)，使得水電調(diào)一體化平臺(tái)可以簡(jiǎn)單有效地進(jìn)行水電調(diào)業(yè)務(wù)組態(tài)、數(shù)據(jù)集成，支持不同業(yè)務(wù)之間的復(fù)雜交互需求，滿(mǎn)足了新平臺(tái)多業(yè)務(wù)數(shù)據(jù)在統(tǒng)一平臺(tái)內(nèi)共享的要求。

1 系統(tǒng)總體架構(gòu)

水電站多業(yè)務(wù)人機(jī)交互框架主要有模型建立、信息數(shù)據(jù)流化、數(shù)據(jù)處理、腳本引擎驅(qū)動(dòng)、模型展示、信息交互等多方面，其整體設(shè)計(jì)圖如圖1所示。其中模型建立負(fù)責(zé)確定業(yè)務(wù)之間交互的接口，信息數(shù)據(jù)流化按照固定的協(xié)議規(guī)則負(fù)責(zé)接口數(shù)據(jù)與流數(shù)據(jù)之間的相互轉(zhuǎn)換，數(shù)據(jù)處理是指在數(shù)據(jù)到達(dá)業(yè)務(wù)服務(wù)端后，業(yè)務(wù)端對(duì)業(yè)務(wù)請(qǐng)求分析后的響應(yīng)。腳本引擎驅(qū)動(dòng)是利用腳本引擎驅(qū)動(dòng)交互腳本，實(shí)現(xiàn)數(shù)據(jù)的獲取及業(yè)務(wù)交互展示，是整個(gè)框架的核心。模型展示以及信息交互主要負(fù)責(zé)對(duì)業(yè)務(wù)返回?cái)?shù)據(jù)的統(tǒng)一展示，以及在數(shù)據(jù)修改后的數(shù)據(jù)回存。

圖1 水電站多業(yè)務(wù)交互框架設(shè)計(jì)圖

2 交互模型建立及展示

交互模型是不同業(yè)務(wù)之間數(shù)據(jù)轉(zhuǎn)換、交互的核心。為整合不同業(yè)務(wù)之間的異構(gòu)數(shù)據(jù)源，簡(jiǎn)單地將多個(gè)應(yīng)用系統(tǒng)連接起來(lái)是遠(yuǎn)遠(yuǎn)不夠的，軟件的數(shù)據(jù)交換標(biāo)準(zhǔn)化才是業(yè)務(wù)融合的前提條件。因此在人機(jī)交互框架中，本平臺(tái)設(shè)計(jì)并提供了統(tǒng)一的數(shù)據(jù)建立接口、數(shù)據(jù)流化接口，同時(shí)為滿(mǎn)足多編程語(yǔ)言使用、跨平臺(tái)調(diào)用的需求，提供標(biāo)準(zhǔn)的C語(yǔ)言庫(kù)接口函數(shù)，提高了接口使用的易用性，降低了第三方集成人員的使用難度。

3 模型建立

在水電站業(yè)務(wù)平臺(tái)中，不同業(yè)務(wù)應(yīng)用平臺(tái)多由不同廠家開(kāi)發(fā)，相互之間直接調(diào)用的難度很大，增加了一體化平臺(tái)適配的難度。借鑒微服務(wù)及SOA的架構(gòu)，不同業(yè)務(wù)模型間應(yīng)該盡量解耦合，服務(wù)之間通用接口實(shí)現(xiàn)弱耦合調(diào)用，服務(wù)提供方與調(diào)用者只依賴(lài)于接口定義描述。根據(jù)服務(wù)接口定義文件，集成工具可以生成框架代碼，服務(wù)方負(fù)責(zé)提供具體的響應(yīng)實(shí)現(xiàn)，客戶(hù)端代碼只需要根據(jù)接口直接調(diào)用即可，數(shù)據(jù)轉(zhuǎn)換、目標(biāo)獲取等統(tǒng)一由平臺(tái)內(nèi)部的數(shù)據(jù)服務(wù)總線統(tǒng)一提供，應(yīng)用系統(tǒng)只需要基于被動(dòng)響應(yīng)合理、合法的請(qǐng)求返回對(duì)應(yīng)數(shù)據(jù)，不需要關(guān)心數(shù)據(jù)請(qǐng)求來(lái)自哪個(gè)系統(tǒng)，也不用了解該系統(tǒng)的連接協(xié)議等信息。業(yè)務(wù)使用方只需要使用標(biāo)準(zhǔn)接口進(jìn)行調(diào)用即可，故而對(duì)數(shù)據(jù)應(yīng)用系統(tǒng)是透明的。

為支持跨語(yǔ)言調(diào)用的需要，接口定義的數(shù)據(jù)類(lèi)型只支持簡(jiǎn)單類(lèi)型及由簡(jiǎn)單類(lèi)型的樹(shù)狀結(jié)構(gòu)組合，即int、long、double、string及這些簡(jiǎn)單類(lèi)型構(gòu)成的數(shù)組，以及這些簡(jiǎn)單類(lèi)型的組合。業(yè)務(wù)雙方交互時(shí)只需要設(shè)計(jì)具體的服務(wù)交互接口、相關(guān)參數(shù)（輸入、輸出參數(shù)），形成業(yè)務(wù)交互的協(xié)議（交互協(xié)議主要由服務(wù)交互接口名，由不同數(shù)據(jù)類(lèi)型組合構(gòu)成的輸入、輸出參數(shù)）。交互參數(shù)設(shè)計(jì)圖如圖 2所示，復(fù)雜結(jié)構(gòu)體之間支持嵌套，但是不允許結(jié)構(gòu)體之間的循環(huán)嵌套，在生成接口協(xié)議時(shí)支持對(duì)循環(huán)嵌套的接口定義做合理性檢查，以避免運(yùn)行時(shí)錯(cuò)誤。

圖2 交互參數(shù)設(shè)計(jì)圖

3.1 信息數(shù)據(jù)流化

對(duì)具體的業(yè)務(wù)協(xié)議，經(jīng)過(guò)標(biāo)準(zhǔn)的打包拆包操作，最終轉(zhuǎn)換為跨平臺(tái)的C數(shù)據(jù)結(jié)構(gòu)，實(shí)現(xiàn)信息的數(shù)據(jù)流化。

序列化格式為:固定消息格式的消息頭加上消息內(nèi)容。

消息頭主要包括消息類(lèi)型（請(qǐng)求還是回應(yīng)），消息長(zhǎng)度以及消息校驗(yàn)和；消息內(nèi)容按又細(xì)分為服務(wù)名字段、服務(wù)請(qǐng)求名字段、參數(shù)打包字段集合序列化內(nèi)容。

具體打包某一字段時(shí)又包括字段類(lèi)型、字段名、字段數(shù)據(jù)等，同時(shí)在數(shù)據(jù)流化時(shí)，為提高傳輸效率，對(duì)int、long數(shù)值型數(shù)據(jù)采用變長(zhǎng)方式流化。

3.2 數(shù)據(jù)展示與交互

在人機(jī)交互配置界面中可以配置界面交互圖元點(diǎn)擊后的交互邏輯，以及服務(wù)取得的數(shù)據(jù)展現(xiàn)到展示圖元。對(duì)每一類(lèi)型的顯示圖元，統(tǒng)一定義圖元數(shù)據(jù)源數(shù)據(jù)格式，以標(biāo)準(zhǔn)輸出流格式由圖元自身動(dòng)態(tài)解析服務(wù)交互結(jié)果，并展示成合適的格式。對(duì)圖元間可以關(guān)聯(lián)二級(jí)圖元，支持?jǐn)?shù)據(jù)間聯(lián)動(dòng)，支持model/view模型，一個(gè)數(shù)據(jù)源可以關(guān)聯(lián)多個(gè)數(shù)據(jù)視圖，在數(shù)據(jù)有變化時(shí)支持多個(gè)數(shù)據(jù)源的同時(shí)更新，有修改后支持?jǐn)?shù)據(jù)結(jié)果的回存。

3.3 數(shù)據(jù)處理

不管是客戶(hù)端還是服務(wù)端，交互的數(shù)據(jù)都需要處理方能使用，對(duì)于服務(wù)端業(yè)務(wù)，只需要根據(jù)服務(wù)協(xié)議動(dòng)態(tài)解析信息流數(shù)據(jù)，并將服務(wù)響應(yīng)結(jié)果按照服務(wù)協(xié)議打包返回到客戶(hù)端即可，服務(wù)端框架里核心內(nèi)容是如何支持多客戶(hù)端訪問(wèn)的線程安全及負(fù)載均衡。對(duì)客戶(hù)端平臺(tái)，需要考慮接續(xù)的是不同業(yè)務(wù)之間的交互模型，尤其是后續(xù)第三方業(yè)務(wù)的集成，故必須支持后續(xù)業(yè)務(wù)的無(wú)限擴(kuò)展需求。設(shè)計(jì)時(shí)考慮了對(duì)序列化消息支持腳本動(dòng)態(tài)解析，在協(xié)議擴(kuò)展時(shí)實(shí)現(xiàn)消息內(nèi)容的動(dòng)態(tài)獲取，這些功能必須依賴(lài)可靠的腳本引擎才具可行性。

4 腳本引擎驅(qū)動(dòng)

相對(duì)于編譯型語(yǔ)言(C++、Java、C#等)，腳本語(yǔ)言存在著計(jì)算性能低的先天不足，以前在電力SCADA系統(tǒng)里也僅在性能要求不高的系統(tǒng)綜合計(jì)算等非核心邏輯中使用，而且其驅(qū)動(dòng)引擎也多采用自研腳本語(yǔ)言，以提高性能，但也同時(shí)犧牲了腳本語(yǔ)言的靈活性。隨著計(jì)算機(jī)計(jì)算水平的提高，分布式應(yīng)用在網(wǎng)絡(luò)帶寬足夠大的情況下引入腳本語(yǔ)言，利用腳本語(yǔ)言提供的靈活性?xún)H需要工程人員簡(jiǎn)單的配置能夠?qū)崿F(xiàn)復(fù)雜的交互功能，這在以前依賴(lài)編譯型語(yǔ)言實(shí)現(xiàn)的系統(tǒng)里必須要研發(fā)人員依據(jù)客戶(hù)的需求定制，增加了工程集成的難度。

4.1 腳本語(yǔ)言之選擇

當(dāng)前主流的腳本語(yǔ)言有JS、Python、Lua等，其中JS主要使用于前端開(kāi)發(fā)，Python作為強(qiáng)大的腳本語(yǔ)言，其依賴(lài)眾多的第三方庫(kù)可實(shí)現(xiàn)非常復(fù)雜的功能，也比較重量級(jí)，而Lua語(yǔ)言一方面具有性能高、與其他語(yǔ)言黏合性好的特點(diǎn)，在游戲領(lǐng)域應(yīng)用較多，目前初步應(yīng)用在了水電站監(jiān)控系統(tǒng)中，擴(kuò)大了腳本的應(yīng)用范圍；另一方面，當(dāng)前SCADA系統(tǒng)普遍采用性能較高的C/C++語(yǔ)言開(kāi)發(fā)，而Lua作為純C開(kāi)發(fā)的腳本語(yǔ)言，同樣具有較強(qiáng)的跨平臺(tái)特性，在對(duì)腳本性能有特殊要求時(shí)還可以采用LuaJIT的方式。

在水電調(diào)一體化平臺(tái)人機(jī)交互框架中，在業(yè)務(wù)執(zhí)行多個(gè)服務(wù)請(qǐng)求、響應(yīng)分析的同時(shí)，還需要保證常規(guī)畫(huà)面的正常刷新，故必須要選擇一種能支持大量腳本引擎可同時(shí)運(yùn)行、執(zhí)行性能高的語(yǔ)言，對(duì)比JS、Python，Lua作為框架人機(jī)交互語(yǔ)言是不二之選。

4.2 畫(huà)面腳本引擎之?dāng)?shù)據(jù)驅(qū)動(dòng)

水電站多業(yè)務(wù)人機(jī)交互主要體現(xiàn)在不同業(yè)務(wù)模型在統(tǒng)一展示平臺(tái)的數(shù)據(jù)展示、方案制作、保存等，主要由前期服務(wù)數(shù)據(jù)的工程配置和運(yùn)行時(shí)的動(dòng)態(tài)獲取解析兩部分構(gòu)成，都需要腳本引擎對(duì)配置文件的解析功能，前者屬于腳本文件的靜態(tài)解析，后者屬于腳本文件的運(yùn)行解析。

為屏蔽不同圖元交互時(shí)的配置差異，集成工具提供了一套統(tǒng)一的界面以實(shí)現(xiàn)數(shù)據(jù)源的統(tǒng)一配置，由腳本語(yǔ)言動(dòng)態(tài)存取，對(duì)保存后的配置，圖元解析功能設(shè)計(jì)時(shí)選擇用腳本引擎解析圖元的自定義配置，利用腳本語(yǔ)言解析的靈活性實(shí)現(xiàn)圖元屬性的易擴(kuò)展性，降低了模型間的耦合，圖元數(shù)據(jù)源配置有服務(wù)名、服務(wù)函數(shù)名、服務(wù)請(qǐng)求參數(shù)集合、服務(wù)結(jié)果數(shù)據(jù)集綁定、請(qǐng)求類(lèi)型（周期、發(fā)布/訂閱等）。

腳本引擎作為人機(jī)交互業(yè)務(wù)的腳本語(yǔ)言解釋器和執(zhí)行器,其支持的腳本類(lèi)似于高級(jí)編程語(yǔ)言,在具體應(yīng)用時(shí)還需要針對(duì)特殊用途擴(kuò)展特定的接口，以實(shí)現(xiàn)與平臺(tái)內(nèi)其他應(yīng)用的實(shí)時(shí)交互。腳本引擎的常規(guī)工作流程是：①腳本引擎的解釋器將一定格式的腳本程序翻譯成中間代碼,這些中間代碼主要由組態(tài)中其他模塊的訪問(wèn)接口和相應(yīng)的數(shù)據(jù)結(jié)構(gòu)組成；②系統(tǒng)投入運(yùn)行時(shí),系統(tǒng)根據(jù)工程配置，主動(dòng)加載相應(yīng)的腳本程序,交給引擎執(zhí)行器動(dòng)態(tài)解析并執(zhí)行。

當(dāng)前人機(jī)交互界面的刷新，多采用發(fā)布/訂閱技術(shù)或周期刷新技術(shù)，取決并依賴(lài)于數(shù)據(jù)源數(shù)據(jù)的刷新方式，發(fā)布/訂閱技術(shù)比較靈活，實(shí)現(xiàn)技術(shù)也較為復(fù)雜；而周期刷新技術(shù)數(shù)據(jù)通常來(lái)自實(shí)時(shí)內(nèi)存庫(kù)，性能很高，但需要提前定義固定的數(shù)據(jù)結(jié)構(gòu)，適用有其局限性?？蚣茉谠O(shè)計(jì)時(shí)同時(shí)支持上述兩種刷新方式，對(duì)實(shí)時(shí)性能要求較高的服務(wù)調(diào)用，采用實(shí)時(shí)庫(kù)周期刷新的方式，對(duì)每個(gè)控件綁定唯一的數(shù)據(jù)源ID，多個(gè)數(shù)據(jù)展示圖元（曲線、棒圖、表格等）支持綁定同一數(shù)據(jù)源；對(duì)采用發(fā)布/訂閱機(jī)制的數(shù)據(jù)源刷新方式，一般具有請(qǐng)求響應(yīng)的數(shù)據(jù)量比較大、計(jì)算周期較長(zhǎng)、刷新不頻繁、響應(yīng)結(jié)果展示復(fù)雜的特點(diǎn)，還需要支持同一數(shù)據(jù)源不同的展示方式，支持?jǐn)?shù)據(jù)源的model/view展示機(jī)制，以提高刷新顯示性能。

框架對(duì)展示圖元（曲線、棒圖、表格等）、交互圖元（按鈕等）的包裝，采用封裝開(kāi)源控件庫(kù)的方式實(shí)現(xiàn)，以支持控件事件的觸發(fā)，但控件操作一般是不可重入的，相應(yīng)操作也必須在GUI主線程完成。為不影響界面的正常刷新，對(duì)發(fā)布訂閱的請(qǐng)求，必須支持異步調(diào)用的方式，其實(shí)現(xiàn)時(shí)主要分為以下3個(gè)步驟：

（1）對(duì)待刷新的控件，在GUI主線程中讀取對(duì)應(yīng)的控件數(shù)據(jù)，并將取得的數(shù)據(jù)打包發(fā)到統(tǒng)一的子線程池；

（2）每一個(gè)子線程對(duì)應(yīng)一個(gè)獨(dú)立的腳本引擎，并由腳本引擎負(fù)責(zé)對(duì)服務(wù)請(qǐng)求內(nèi)容進(jìn)行統(tǒng)一打包并執(zhí)行；

（3）對(duì)異步返回結(jié)果的處理分兩種情況，周期刷新的數(shù)據(jù)只需要將數(shù)據(jù)保存到全局緩存中，由界面刷新定時(shí)取用即可；對(duì)發(fā)布訂閱的數(shù)據(jù)，需要將返回的執(zhí)行狀態(tài)/實(shí)際數(shù)據(jù)打包發(fā)送信號(hào)到主線程，由主線程對(duì)返回結(jié)果進(jìn)行統(tǒng)一分析處理。

4.3 平臺(tái)交互

腳本引擎作為通用的解釋性語(yǔ)言，與其他語(yǔ)言交互時(shí)一般也只提供了較為簡(jiǎn)單的庫(kù)函數(shù)，特殊應(yīng)用使用時(shí)必須依賴(lài)語(yǔ)言提供的標(biāo)準(zhǔn)API進(jìn)行封裝。腳本引擎與一體化平臺(tái)的交互，既需要腳本引擎對(duì)平臺(tái)功能的正向調(diào)用/交互，也需要平臺(tái)功能對(duì)腳本引擎函數(shù)的逆向調(diào)用。

與一體化平臺(tái)交互時(shí)，必須注冊(cè)相應(yīng)的函數(shù)到腳本引擎，腳本動(dòng)態(tài)解析時(shí)方能識(shí)別，對(duì)Lua引擎，所有注冊(cè)給Lua的C函數(shù)具有typedef int (*lua_CFunction) (lua_State *L)的原型；框架設(shè)計(jì)時(shí)，已針對(duì)公用需求，將一體化平臺(tái)內(nèi)的常規(guī)平臺(tái)交互函數(shù)注冊(cè)到腳本引擎，主要分為以下幾種功能：

（1）實(shí)時(shí)庫(kù)操作：腳本可以調(diào)用實(shí)時(shí)庫(kù)中的讀寫(xiě)函數(shù)，并調(diào)用消息總線接口實(shí)現(xiàn)數(shù)據(jù)的實(shí)時(shí)同步；

（2）歷史庫(kù)服務(wù)操作：實(shí)現(xiàn)歷史數(shù)據(jù)的寫(xiě)庫(kù)以及數(shù)據(jù)查詢(xún)；

（3）日志分析：記錄服務(wù)請(qǐng)求、讀取的處理流程，對(duì)數(shù)據(jù)的關(guān)鍵路徑，記錄其執(zhí)行流程，供日后查詢(xún)、日志統(tǒng)計(jì)及分析以及在請(qǐng)求異常后的故障分析；

（4）平臺(tái)權(quán)限管理：在腳本引擎里的操作，可調(diào)用平臺(tái)權(quán)限的統(tǒng)一判斷函數(shù)，對(duì)用戶(hù)操作進(jìn)行判斷并記錄，并通過(guò)一體化系統(tǒng)的數(shù)據(jù)總線同步操作判斷結(jié)果；

（5）高級(jí)應(yīng)用功能：為其他高級(jí)應(yīng)用功能提供邏輯運(yùn)算支撐，以及復(fù)雜邏輯功能的組態(tài)。

平臺(tái)功能對(duì)腳本引擎的解析調(diào)用，采用固定功能key的方式，平臺(tái)讀取腳本數(shù)據(jù)時(shí)，按照對(duì)象名、特定功能key的方法讀取腳本中的數(shù)據(jù)，當(dāng)前系統(tǒng)定義的功能key主要有以下幾個(gè)：PlatFormName(平臺(tái)名)、ServiceName(服務(wù)名)、FuncName(函數(shù)名)、InputParas(輸入?yún)?shù)集合配置)、OutputParas(輸出參數(shù)集合配置)、bPeriodRefresh(是否周期刷新)、FreshPeriod(刷新周期)等。

5 結(jié)語(yǔ)

一體化人機(jī)交互模型滿(mǎn)足了多業(yè)務(wù)數(shù)據(jù)在水電調(diào)一體化平臺(tái)中數(shù)據(jù)共享和集成展示的要求。在水電調(diào)一體化SOA平臺(tái)架構(gòu)中，基于服務(wù)總線提供的統(tǒng)一數(shù)據(jù)傳輸機(jī)制，結(jié)合自身業(yè)務(wù)特點(diǎn)，對(duì)人機(jī)交互界面提供了一套操作簡(jiǎn)單的配置、顯示畫(huà)面，利用腳本驅(qū)動(dòng)引擎驅(qū)動(dòng)復(fù)雜業(yè)務(wù)的交互邏輯，滿(mǎn)足了不同業(yè)務(wù)間的復(fù)雜交互需求，為水電調(diào)一體化平臺(tái)多業(yè)務(wù)數(shù)據(jù)在統(tǒng)一平臺(tái)內(nèi)數(shù)據(jù)共享、集中展示、平臺(tái)的可靠運(yùn)行提供了技術(shù)支撐。