宋志剛,蔡偉周,李劍波,胡 陽,陳 佳,張 昆
隨著計算機技術、通訊技術及軟件技術的發展,大量采用不同通訊協議的智能設備或系統被廣泛應用于工業現場。為了實現這些使用不同通訊協議的設備或系統之間信息互聯互通,人們設計了多種協議轉換方法,如:比特型固定格式數據協議通用轉換方法[1]、參考編譯原理的通訊協議轉換方法[2]、基于特征關鍵字的協議轉換方法[3]、基于通用協議模版的協議轉換方法等[4]。文獻[5]設計了一種基于WEB的數據采集與監控系統。本文設計了一種基于組件式[6-7]軟件平臺架構的通用協議轉換器,具有良好的靈活性、可維護性和擴展性。為敘述方便本文將以MODBUS協議為例介紹該協議轉換器的軟件設計。
通用協議轉換器的硬件使用嵌入式工業計算機MOXA UC系列來實現,具有2個10/100M LAN口和8個RS232/422/485可配置串口。CPU選用IXP-422,板上配置128MB DRAM和32MB FLASH。操作系統選用嵌入式uC?Linux[8]。
協議轉換模塊的軟件系統應滿足如下功能需求:
(1)適用于多種標準協議,包括但不限于MODBUS/RTU、MODBUS/TCP、IEC104等;
(2)支持用戶自定義協議;
(3)支持多個通道同時進行通訊;
(4)可以適應各種對接設備的不同通訊速率,且不同通訊通道不會互相拖慢處理速度;
(5)可以通過遠程工具配置端口通訊參數,配置文件可以上傳下載;
(6)可以在遠程監視到各個通訊通道的報文收發,并可記錄系統日志;
(7)預留開發接口,允許用戶使用編程語言針對特定協議進行自主開發;
(8)部分通訊端口故障不影響整體運行;
(9)支持對用戶身份及權限的校驗和管理。
為了使協議轉換器具有良好的可擴展性,通用協議轉換器的軟件系統采用組件式架構,包括:協議轉換器主服務程序(下簡稱主服務程序)、協議通訊組件(下簡稱通訊組件)和遠程監視及配置工具(下簡稱監視配置工具)。主服務程序與監視配置工具構成客戶端/服務器(C/S)結構。
主服務程序運行于協議轉換器的uCLinux系統之下,隨操作系統自啟動,負責根據配置文件加載通訊組件,并提供協議轉換服務。同時,主服務程序也負責響應監視配置工具的命令請求,完成系統配置的上傳、下載、備份以及對各個端口通訊狀態的監視功能。為了節約系統資源,主服務程序采取單一進程多個線程的方式提供通訊及系統管理服務。
通訊組件采用動態鏈接庫(.SO文件)方式實現,用于實現與協議轉換器某一端口所連接的設備實現數據通訊。在主服務程序啟動后被動態加載。
監視配置工具運行于與協議轉換器處于同一網絡下的某臺工作站上。該工作站操作系統采用WINDOWS系列。監視配置工具與協議轉換器之間的命令交互及通訊監視功能采用TCP協議實現。
協議轉換器件系統軟件邏輯結構如圖1所示。

圖1 協議轉換器件系統軟件邏輯結構
監視配置工具作為客戶端運行于同一網絡內的某WINDOWS系統計算機上。監視配置工具與協議轉換器之間通過TCP協議傳遞配置命令及被監視端口的實時通訊數據。
監視配置工具采用分層式架構、模塊化設計,使用C++語言進行開發。
2.2.1 邏輯結構設計
如圖2所示,監視配置工具軟件分為三個邏輯層次,分別為界面層、業務層、通訊服務層。業務層劃分為三個功能模塊,包括用戶管理模塊、器件配置管理模塊、端口通訊監視模塊。

圖2 監視配置工具邏輯結構
業務層的用戶管理模塊主要實現用戶登錄驗證,用戶權限判斷,新用戶創建,用戶身份配置,用戶密碼修改等功能。
器件配置管理模塊用于對端口的配置,包括端口的通訊參數、通訊協議、數據點表、點位映射關系表等。配置信息可以存儲為文件并予以保存。配置信息的收發采用命令報文實現。
端口通訊監視模塊用于接收協議轉換器上報的通訊報文及設備警告信息。
通訊服務模塊封裝了TCP報文的收發。在該模塊內對于業務層下發的命令報文采用緩沖隊列進行緩存并逐一發送。
2.2.2 通訊報文設計
監視配置工具與協議轉換器之間的通訊報文基本結構如圖3所示。0XFFFF為報文起始標志,0XEEEE為報文結束標志。FC為報文功能類別碼。PT為端口類型,用數字0表示串口,用數字1表示網口。PI為端口ID,用于區分同類別的不同端口。LEN為后續內容到報文結束標志之前的數據的長度。DIRC為報文傳遞方向,進入協議轉換器的方向設為0,離開協議轉換器的方向設為1。
定義 2[9] Hom-Jordan李代數(L,[·,·]L,α,δ)由空間L,一個二元雙線性運算L×L→L滿足

圖3 監視配置工具與協議轉換器的通訊報文結構設計
參見表1,根據報文功能,將報文分為如下幾類,分別用FC的不同數值表示。

表1 監視配置工具與協議轉換器的通訊報文類型
協議轉換器中的主服務程序和通訊組件共同完成協議轉換功能。主服務程序作為單一進程跟隨系統啟動,啟動后將根據端口所使用的通訊協議類型加載對應的動態鏈接庫。
2.3.1 程序設計
如圖1所示,協議轉換器軟件邏輯上包括配置管理服務模塊、通訊監視服務模塊、用戶管理服務模塊和數據通訊服務模塊。
配置管理服務模塊在主線程運行,負責響應監視配置工具的配置命令,接收端口配置文件或上傳端口配置文件。配置發生更改后系統將重新啟動,并重新載入配置文件。端口配置文件內容包括:端口通訊參數設置、端口通訊協議、端口所連接的設備的地址或標識、端口所連接設備的數據點位等。每個通訊口上所連接的設備個數多于1個時通過設備地址或標識予以區分。
通訊監視服務模塊以主線程的子線程運行,負責轉發端口通訊報文、端口警告信息給監視配置工具。在該模塊內部維護了一個循環緩沖隊列,用于存儲需要轉發的通訊報文或警告信息。使用互斥鎖來防止對緩沖隊列的數據訪問沖突。同時,在該模塊內部設置一個客戶端列表,記錄每個客戶端具體訂閱了哪些端口的通訊或警告消息。
用戶管理服務模塊功能在主線程實現,負責響應監視配置工具的用戶操作命令。用戶配置信息以文件的形式存儲于主服務程序的工作目錄,并進行加密。
數據通訊服務模塊以單獨的工作線程運行,用于管理每個端口上的數據通訊。該線程啟動后,根據各個端口的名字找到對應的端口配置文件,并根據配置文件中所配置的通訊協議,加載對應的通訊組件,隨后開啟該端口的通訊線程。通訊組件在發現數據出現更新時,調用主服務程序中的回調函數OnPortDataChange,通知主服務程序本端口上某個數據點位已發生變化。主服務程序通過查配置表找到該數據點位的對端端口點位,并將該點位的更新信息發送給對端端口的通訊組件。對端端口的通訊組件將對應點位的數值更新到數據緩存區,并通過通訊報文,將對端端口的數據緩沖區中的數據變化信息傳遞給對端所連接的設備。
協議轉換器對不同協議進行轉換的數據處理流程如圖4所示。

圖4 端口協議轉換處理流程
2.3.2 組件設計
協議轉換器通訊組件采用動態鏈接庫實現。協議通訊組件對應于某個特定的通訊協議,如MODBUS-RTU主站、MODBUS-RTU從站、MODBUS-TCP主站、MOD?BUS-TCP從站、IEC104主站、IEC104子站等。
通訊組件對外需提供一組接口函數用于與主服務程序的交互。StartComm接口函數用于協議轉換器主服務程序控制端口通訊的啟動過程。SetDataBuf用于設置該端口對應的數據緩存區,數據緩存區由主服務程序根據設備的配置信息從內存池獲取,并把申請到的內存地址傳遞給通訊組件,通訊組件使用該段內存緩存數據,并把數據變化信息通過回調函數OnPortDataChange通知給主服務程序,主服務程序調用對端端口通訊組件的SetDataExchange函數將數據變化更新到對端端口的數據緩存區并通過通訊報文同步到對端所連設備。對于某些主動上報型通訊協議如(IEC104子站),SetDataExchange函數需要將數據變化主動發送給所連設備,而對于輪詢類型的通訊協議(如MOD?BUS-RTU從站)只需要等待本端口外接的設備發起數據輪詢。
由于采用了組件式架構,對于該協議轉換器暫未支持的工業標準通訊協議或某些設備廠家的自定義協議,只需按照通訊組件接口規范來開發出相應的通訊組件即可予以支持。對于文獻1、文獻3等文獻中所介紹的種種協議轉換算法,也均可以通訊組件的方式予以實現。
設計了一種通用協議轉換器的軟件系統,該軟件系統以組件式架構實現,具有較好的靈活性,可以適應復雜的通訊協議轉換需求。同時,該軟件系統提供了開發接口,方便于協議轉換器的功能擴展和升級。