馬紅 張理成 鐘世平 徐正豐

摘 要 分析傳統(tǒng)組態(tài)軟件面臨的問題，結合組態(tài)軟件的技術特點與使用場景，提出一種針對傳統(tǒng)組態(tài)軟件Web化的設計方案，包括系統(tǒng)架構、Web前端界面和后臺程序。根據實際應用場景增加了線程池方案，提高了后臺程序的執(zhí)行效率。該設計方案應用在ECS?700neo工業(yè)控制系統(tǒng)組態(tài)軟件中，系統(tǒng)測試結果表明：達到了Web化預期效果。

關鍵詞 軟件Web化 組態(tài)軟件 Web前端 線程池 ECS?700neo

中圖分類號 TP273? ?文獻標志碼 B? ?文章編號 1000?3932（2024）01?0023?06

“組態(tài)”一詞最早源自于英文單詞configuration，指使用軟件工具對計算機和軟件資源進行配置，使其能夠按照預先設置完成特定的任務［1］。由于組態(tài)軟件的靈活性和可通用性，使其在工業(yè)控制領域占據了重要地位。隨著互聯網技術的飛速發(fā)展，Internet技術被廣泛應用于各個領域，Web應用（B/S架構）以其快捷、方便的特點深受喜愛，已深深影響著人們的工作和生活方式，所謂B/S（Browser/Server）架構即瀏覽器和服務器組成的一種框架模型［2］。在此結構中，瀏覽器作為客戶端用于完成用戶界面的操作與顯示，絕大多數的邏輯處理放在服務器端，極大地減輕了客戶端的運行壓力。這樣不僅方便用戶使用，而且無需安裝和維護各種不同版本的軟件。目前，基于Web的B/S架構已經成為當今應用軟件的首選體系結構。傳統(tǒng)組態(tài)軟件多是基于C/S模式設計或者是基于MFC框架的獨立桌面應用程序，無法通過Web端進行遠程操作。

1 組態(tài)軟件Web化的技術分析

1.1 傳統(tǒng)組態(tài)軟件面臨的問題

傳統(tǒng)組態(tài)軟件運行于Windows操作系統(tǒng)中，采用C++語言編寫，普遍基于微軟MFC框架，其基本結構如圖1所示。

傳統(tǒng)組態(tài)軟件分為顯示層、業(yè)務層和數據層，因為是單進程應用程序，地址空間中的數據很容易實現互相訪問，這一天然優(yōu)勢往往會導致顯示層與業(yè)務層無法完全解耦，即為了業(yè)務需要，會在顯示層中加入許多與顯示無關的業(yè)務代碼，增加了模塊間的耦合度。

除此之外，MFC程序只能運行于Windows操作系統(tǒng)中，無法跨平臺使用，并且有許多依賴的運行環(huán)境，必須先安裝完程序之后才能運行。

另外，MFC的類是由Win32 API接口經過層層封裝，使其復雜度更高，對于多樣性界面的開發(fā)來說比較復雜，尤其是需要修改界面特性時，需要重寫許多類方法才能實現部分功能，并且大多不具有通用性，給界面開發(fā)帶來很大的難度［3］。這也是傳統(tǒng)組態(tài)軟件界面單一的一大原因。

1.2 原生桌面軟件Web化帶來的優(yōu)勢

Web是一種基于HTML語言和HTTP協議的、全球性的、動態(tài)交互的、跨平臺的分布式圖形信息系統(tǒng)，是建立在Internet上的一種網絡服務，為瀏覽者在Internet上查找和瀏覽信息提供圖形化的易于訪問的直觀界面。

HTML5是由萬維網聯盟（W3C）制定的，是HTML經過第5次重大修改后的版本，是第1個將Web作為應用開發(fā)平臺的HTML標準。

Web應用相比于原生桌面軟件，具有以下優(yōu)勢：

a. 客戶端無需安裝其他軟件，只需一臺安裝有瀏覽器且可以聯網的設備便可以隨時隨地訪問系統(tǒng)，極大地提高了靈活性和便捷性，避免了客戶端升級困難的問題。

b. 減輕維護工作量，維護只需對服務器進行升級。傳統(tǒng)的基于C/S架構或基于MFC框架的獨立桌面應用程序的軟件，由于需要將軟件安裝在不同的PC機上，因此升級時需逐個進行，增加了維護難度。

c. 具有良好的跨平臺特性，基于B/S架構的軟件不受操作系統(tǒng)的限制，無論是Windows系統(tǒng)還是Linux系統(tǒng)甚至是Android/IOS等便攜式操作系統(tǒng)都可以訪問。而傳統(tǒng)的組態(tài)軟件依賴于操作系統(tǒng)，需要針對不同操作系統(tǒng)開發(fā)不同版本的軟件。

d. 開發(fā)難度降低，Web界面開發(fā)相較于基于MFC框架開發(fā)而言難度已明顯降低，這得益于HTML5和瀏覽器技術的發(fā)展。

e. 開發(fā)周期縮短，隨著Web技術的快速發(fā)展，成熟的技術方案以及優(yōu)秀的軟件庫能夠幫助開發(fā)人員加快開發(fā)速度。另外，得益于Web程序使用的是JavaScript腳本語言，無需編譯連接就能運行查看效果，相比于編譯型語言，無疑提高了開發(fā)效率。

2 組態(tài)軟件Web化的設計

針對傳統(tǒng)組態(tài)軟件所面臨的痛點，以及傳統(tǒng)組態(tài)軟件結構的特點，實現組態(tài)軟件Web化的設計，需進行Web前端設計和后臺程序設計。前端只需負責結果展示，沒有其他復雜的業(yè)務邏輯，故對于Web前端只需設計好框架即可。重點在于后臺程序的設計，由于大部分的業(yè)務邏輯都集中在后臺處理，需要考慮執(zhí)行效率，后臺設計可以分別從系統(tǒng)架構、網絡引擎、交互協議、請求路由設計、線程池五大方面進行。

2.1 總體框架設計

系統(tǒng)架構總體上分為Web前端（通過瀏覽器訪問的界面）和后臺程序（以服務形式運行在Windows系統(tǒng)中，對外提供網絡接口訪問），整體框架如圖2所示。

前端通過HTTP協議以RESTful形式的接口訪問后端數據，拿到數據后以預定的界面展示數據。后端數據的傳輸有兩種方式且都是以JSON格式為載體的自定義網絡協議：

a. 以回應HTTP請求的形式將數據傳輸給前端；

b. 前端與后端建立WebSocket后，后端通過WebSocket接口將數據傳輸給前端。

后臺程序采用C++11的新特性開發(fā)。模塊化設計，每個模塊都實現了一套觀察者模式，即每個模塊既可以是觀察者也可以是被觀察者，模塊內部需要對關鍵事件進行廣播，同時訂閱該模塊應該關注的其他模塊的事件，這樣可以做到每個模塊相互獨立，降低模塊間的耦合度。

2.2 前端界面設計

前端采用了比較經典的MVC（模型/視圖/控制器）3層架構模式，降低業(yè)務邏輯與數據接口的耦合度，增加了代碼的擴展性與可維護性。該模式劃分為3個核心模塊：模型（Model）、視圖（View）和控制器（Controller）［4］，MVC協作關系如圖3所示。

模型。事務邏輯模塊，是整個模型的核心，它封裝了所有業(yè)務邏輯以及功能，還有應用狀態(tài)信息以及程序運行期的數據。提供數據變更的訂閱接口、狀態(tài)查詢接口和功能接口。

視圖。用戶視圖模塊，負責與用戶交互，接收用戶的輸入，展示各種數據信息。當模型狀態(tài)發(fā)生變化時，視圖應該得到通知，以便更新視圖的變化。

控制器。控制模塊負責選擇合適的視圖用于展示，并接收來自視圖的操作請求來修改模型的狀態(tài)。修改后的狀態(tài)由模型負責通知到視圖進行狀態(tài)刷新。

2.3 后臺程序設計

后臺程序設計為一個無窗口程序，并且需要監(jiān)聽指定的HTTP端口與WebSocket端口，兩個端口相同。主線程啟動后初始化網絡引擎并設置好所有的網絡回調函數，用于監(jiān)聽HTTP網絡事件以及WebSocket網絡事件；創(chuàng)建線程池，加載各種相關邏輯模塊。后臺框架如圖4所示。

2.3.1 網絡引擎設計

網絡引擎采用WebSocketpp網絡庫實現，該網絡庫是由Peter Thorson開發(fā)的一款開源網絡庫，是基于C++11標準庫和Boost庫開發(fā)，支持HTTP協議與WebSocket協議，具有高性能、跨平臺及線程安全等特性。

WebSocketpp網絡核心是基于Boost.Asio網絡庫實現的，Boost.Asio是一個輕量級的用于網絡和底層I/O編程的跨平臺C++庫，在Windows平臺中采用了IOCP技術。Boost.Asio以良好的性能、靈活的用法、支持高并發(fā)的I/O處理以及強大的跨平臺支持，逐漸成為C++網絡庫的工業(yè)化標準，被越來越多的網絡作為基礎框架應用。

IOCP又稱I/O完成端口，是微軟提供的用于Windows上高效處理各種設備I/O的一種機制［5］，與計算機執(zhí)行的其他操作相比，設備I/O是最慢最不可預知的操作之一。IOCP撇開不同設備I/O的各自特點，抽象出了一種機制，使非I/O處理與I/O處理能重疊并行操作，使CPU的利用率得到極大程度的提高。IOCP采用了重疊I/O技術，比起阻塞的I/O操作，重疊I/O最大的優(yōu)勢是應用程序投遞了一個發(fā)送或接收請求后就直接返回，由系統(tǒng)底層負責處理I/O的實際過程，這樣可以大量縮短CPU在I/O操作上花費的等待時間。IOCP提供了一個高效復雜的內核對象，該對象通過指定一定數量的工作線程，對完成的重疊I/O操作進行處理，這樣使得系統(tǒng)資源能夠被更有效地利用［6］。

WebSocketpp網絡庫的使用比較簡單，通過模板類定義的一個服務對象來設置關注的幾個回調函數，包括HTTP請求事件回調與WebSocket請求事件回調，之后便可以指定一個端口啟動網絡服務。值得注意的是，WebSocketpp網絡庫對于回應HTTP消息，默認有一個5 s的限制，如果超過5 s還沒有返回就會強制斷開本次HTTP連接。由于組態(tài)軟件存在一些比較耗時的操作，如批量刪除、批量修改、編譯等操作，都可能會超過5 s后完成?？梢酝ㄟ^調用連接對象的defer_http_response（）方法將本次請求設置成延時回應模式，用于取消這個限制，等待所有業(yè)務處理完成之后需要回應時，只需調用連接對象的send_http_response（）方法即可完成一次HTTP回應。

對于耗時太久的操作，需要與前端有一個交互，否則前端會認為后臺程序很久沒有給出響應，可能已經不再工作，造成極其不友好的體驗。筆者的解決方案是通過WebSocket鏈路實時通知前端處理的進度信息，前端可以通過進度條的方式展示出來，一方面提高了用戶體驗，另一方面可以防止用戶在此期間有其他不相關的操作而帶來的一些不可預知的后果。如用戶在執(zhí)行一個批量刪除的動作（耗時比較久）時，在等待期間，用戶通過刷新界面的方式，對剛剛執(zhí)行了刪除操作的資源再次進行修改的話可能會出現非法訪問的問題，雖然后臺可以對這一操作進行保護，但仍然會帶來許多不必要的副作用。

2.3.2 交互協議設計

后臺程序與Web前端的交互協議是基于RESTful/HTTP的網絡接口框架設計的。REST是由HTTP、URI等Web協議的設計者Roy Fielding博士提出的一種現代軟件架構思想。REST的核心思想是將網絡中可被管理的信息抽象成資源，并通過統(tǒng)一的接口對資源進行操作。目前，REST已經成為最受歡迎的Web服務設計模型，它不僅讓人們對HTTP協議的本質有更加深入的理解，同時也提供了一種新的Web應用開發(fā)思維［7］。接口規(guī)范主要有4個特征：資源的可標識性、無狀態(tài)性、連通性和接口統(tǒng)一性［8］。

前端通過RESTful接口訪問或操作后臺組態(tài)數據，其中交互數據格式采用JSON格式化。為了統(tǒng)一接口，全部接口都采用HTTP的POST方法，也為后期對數據加密做了鋪墊。由于HTTP協議無法做到反向通知，即只能Web前端向后臺程序發(fā)出請求，后臺程序才可以給Web前端回應消息。而不能反過來由后臺程序主動給Web前端發(fā)出請求或者通知。組態(tài)軟件中存在后臺程序需要向Web前端主動發(fā)通知的場景，如調試模式下，后臺程序主動向Web前端推送實時數據、比較耗時的操作中，后臺程序需要向Web前端實時通知處理的進度等。傳統(tǒng)的解決方案是采用輪詢機制，即在特定的時間間隔（如每隔1 s），由Web前端向服務器發(fā)出HTTP請求，然后由服務器返回最新的數據給Web前端，這種模式的缺點很明顯，即Web前端需要不斷地向服務器發(fā)出請求，然而HTTP請求可能包含比較長的頭部，其中真正有效的數據可能只有很少的部分，顯然這樣會浪費很多帶寬資源。HTML5中定義了WebSocket協議，由于協議是全雙工的，所以服務器可以隨時主動給Web前端下發(fā)數據，相對于HTTP請求需要等待Web前端發(fā)起請求服務端才能響應，延遲明顯更少。這種技術剛好符合軟件需求。因此，在Web前端與后臺程序的交互過程中又增加了一個WebSocket鏈路，方便后臺程序隨時向前端通知消息。

2.3.3 請求路由設計

網絡后臺程序必然會有一套請求的路由邏輯，通過URL區(qū)分不同的請求，通常采用字符串比較的方式，此種方式一般有兩種實現方式：

a. 采用if/else if語句對后臺支持的所有請求命令都一一比較的方式，這種方式執(zhí)行效率非常低下，而且代碼的可讀性也非常差，在代碼中的表現是一長排的if/else if語句，雖然可以使用宏來做一定的簡化，但是其本質沒有變化，而且if/else if語句不能嵌套得太多，否則會出現編譯不通過的情況，給后期維護帶來困難。

b. 將后臺支持的所有URL請求命令與唯一的索引號按照key?value組合保存到map表里，然后通過字符串key進行搜索，映射到對應的索引號，再由switch/case語句進行路由。此種方式解決了方式a的問題，但是可讀性仍然不夠理想，代碼中會積累很多case語句，影響美觀。

為了避免以上實現方式存在的問題，本設計采用URL請求命令與處理函數地址按照key?value組合保存到map表里，再通過宏的方式定義URL與處理函數的綁定，提高執(zhí)行效率的同時，對代碼的可讀性和可維護性都有一定的提高。

2.3.4 線程池設計

為了提高后臺的執(zhí)行效率，設計了一款基于C++11新特性的線程池作為整個框架的關鍵模塊。根據需要，僅開放一個投遞任務的接口，所謂任務就是可執(zhí)行函數。投遞完成之后返回該任務的future對象（參見C++11標準庫），投遞者就可以用這個future對象獲取到將來執(zhí)行的結果。

線程池內部管理著多個線程組，每個線程組有一個任務隊列，線程組中的線程會循環(huán)讀取該組隊列中的任務，有任務會立即取出并執(zhí)行，無任務會阻塞等待。非本線程池中的線程投遞任務會被指定投遞到線程組0的任務隊列中，本線程池中的某個線程投遞任務，則會被指定投遞到當前線程組的下一個線程組的任務隊列中。這樣設計的初衷是為了防止鏈式投遞任務而導致線程死鎖的問題。線程池總體設計如圖5所示。

該線程池模型雖然解決了鏈式投遞任務問題，但是無法解決環(huán)形投遞任務帶來的問題，即一個線程把任務A投遞到線程池TP中執(zhí)行，任務A把任務B投遞到TP，任務B又把任務A投遞到TP中（所有的任務投遞形成了一個閉環(huán)）。這種投遞方式會造成線程池TP創(chuàng)建出很多無用線程，最終會將系統(tǒng)資源耗盡。想要避免環(huán)形投遞任務，需要將含有環(huán)形任務的第1個任務交給非本線程池的線程執(zhí)行，如把任務A交給專門的線程T執(zhí)行，任務A在線程T中把任務B投遞到TP，任務B又把任務A投遞到線程T中執(zhí)行，即保證任務A與其他任務不在同一個線程池中執(zhí)行即可。

3 方案應用

根據筆者提出的組態(tài)軟件Web化設計方案，對現有組態(tài)軟件進行全面設計，完成了ECS?700neo控制系統(tǒng)中的組態(tài)軟件的全部功能，并對其中的各項功能點和穩(wěn)定性進行了全方位測試。測試結果表明，對傳統(tǒng)組態(tài)軟件的Web化設計達到了預期效果，并且可以保證其運行的穩(wěn)定性。

4 結束語

通過對傳統(tǒng)組態(tài)軟件Web化的技術分析，結合組態(tài)軟件特有的功能特點、使用場景和技術要求，提出了一種針對傳統(tǒng)組態(tài)軟件Web化的設計方案。采用該方案設計的組態(tài)軟件與傳統(tǒng)組態(tài)軟件相比，提高了軟件使用的靈活性和便捷性、增加了跨平臺特性、降低了開發(fā)成本以及開發(fā)難度、減輕了維護工作量，同時界面的美觀度和操作的友好性也得到一定提升，對今后的工業(yè)控制類軟件向Web化轉型有著積極的參考作用。

參 考 文 獻

［1］ 劉耀.基于組件技術的組態(tài)軟件的研究與設計［D］.長沙：中南大學，2004.

［2］ 戴國峰.客戶機服務器模式和瀏覽器服務器模式的對比分析［J］.硅谷，2011（8）：184-199.

［3］ 白喬，左飛.把脈VC++［M］.北京：電子工業(yè)出版社，2009：148-153.

［4］ 張俊.構建REST風格的Web應用程序［D］.北京：北京郵電大學，2009.

［5］ 蔣姝霞，王悅.IOCP在服務器開發(fā)中的應用［J］.信息安全與通信保密，2010（3）：72-75.

［6］ 吳克松，陳浩然，董建平.基于IOCP的Boost.Asio的研究及在高清MCU中的應用［J］.數據通信，2015（2）：12-14.

［7］ 董龍華.基于REST風格的網絡管理平臺研究與實現［D］.北京：北京郵電大學，2015.

［8］ 朱斌，林帆.基于RESTful面向資源的站內管控平臺設計［J］.數字通信世界，2019（9）：5-12.