徐萌飛, 周艷紅
?
一種應用于推進系統的開放式通訊調測平臺
徐萌飛, 周艷紅
( 武漢船用電力推進裝置研究所,武漢 430064 )
在船用電力推進系統中,控制系統常由多個部件組成。通過部件之間的通訊,指令下發、信息采集、故障告警等多種功能才得以實現。由于各部件之間的通訊接口多種多樣,如CAN、485、以太網等。可采用的通訊協議也很多樣,標準協議和自定義協議都存在,所以通訊功能調測也變得重要且復雜。在調測通訊接口的過程中,采用輕量級的開放式測試平臺,比起等所有部件開發完畢后集中調試要更為便利。本文介紹了一種開放式通訊調測平臺的設計方案。此調測平臺可直接運行于各種pc或便攜機上,具有測試接口多樣、測試腳本可定制的優點。在實際應用中,已取代了plc和觸摸屏等多種部件進行通訊功能的調測,給開發人員帶來了很大便利。
通訊調測平臺 軟件架構設計 UML
在船用電力推進系統中,控制系統一般由多個部件組成,如上位機、集控設備、遠程監控設備、帶通訊功能的觸摸屏、PLC、控制器等。各個部件之間需要進行指令、運行信息、模擬量、數字量、報警、故障等多種信息的通訊。通訊采用的接口形式也多種多樣,例如485、can、以太網等。采用的通訊協議也會根據實際情況采用標準協議(如modbus)或自定義協議。通過通訊接口,指令下發、信息采集、故障告警等多種功能得以實現。
由于控制系統中包含的各個部件開發進度不同,如果沒有方便的調測工具,先完成的部件將不得不等待其他部件開發完畢后才能通過雙方的通訊接口調試功能,從而影響了調試進度。
此外,在調試時,很多部件體積較大,連接線較多,攜帶不方便,每次要進行集成安裝后再調試會比較麻煩。
最后,不同的項目使用不同的通訊協議內容,既有通用參數,也有本項目專用參數。而且在實際的測試過程中,通訊協議字段會根據實際需要做臨時變化,導致陪試部件要針對新的協議重新修改,編譯,調試。很容易影響調測效率。
為解決以上問題,開發了一種開放式通訊調測平臺,此平臺具有以下特點。1) 支持自定義消息腳本,通訊協議字段和內容變化都可通過直接修改修改腳本文件實現,無需二次開發。支持通用標準協議如modbus協議等,也支持自定義協議;2) 支持多種通訊接口,包括485、can、以太網等;3) 軟件運行于win/PC平臺,pc和便攜機上均可運行,攜帶方便;4) 通訊過程可記錄日志,便于分析定位問題,支持定時調測。
要完成此通訊調測平臺系統架構設計,首先要根據功能,質量和需求,規劃平臺需要解決的關鍵問題,形成概念性架構設計。
在本項目中,主要對象包含三個部分,使用者,調測平臺以及被測對象。三者之間的關系是:使用者操作用戶界面,讓調測平臺發送符合測試要求的測試指令給被測對象,這些指令可以預先定義在消息腳本文件中,也可以通過界面實時創建。發送也可以定時或實時發送。同時,調測平臺接收到被測試對象反饋回的消息后,根據通訊參數配置定義(用戶通過人機界面加載參數定義文件),將消息解析、顯示。
整個系統采用的分層架構見圖1。由于涉及到通訊協議的解析,所以在接口管理層中,采用了常見的管道過濾器模式。在業務層為實現定時消息的有序發送和接收,采用了常用的生產者/消費者模式。
隨著UML(統一建模語言)的誕生,采用UML來描述4+1視圖模型也成為業界常用方法。4+1視圖模型主要采用邏輯視圖、開發視圖、進程視圖、物理視圖以及場景和動作序列來對軟件系統架構進行表達,本次通訊調測平臺的架構也采用這種方式。
用例視圖描述了對軟件架構設計起關鍵作用的需求子集,是對問題領域的模擬抽象,建立了最終軟件系統的功能范圍,描述了參與者和系統之間的交互作用。
經過對通訊調測平臺的需求分析,調測平臺主要通過人機界面和用戶交互,通過消息接口和被測系統進行交互。調測平臺需要支持以下主要功能:
1)選擇和配置通訊接口,并標識接口狀態(是否可用);
2)可根據需要選擇和配置通訊協議;
3)可通過調測平臺加載消息腳本文件,然后實時或實時發送消息;
4)支持在隨時自定義消息發送;
5)平臺接收到被測系統回復后,可根據用戶加載的參數定義文件,將接收到的消息按配置參數,系統狀態,告警和故障信息等分類顯示在界面上;
6)可通過平臺通訊功能下發配置參數給被測系統,也可以將從被測系統獲取的配置參數上傳到本地保存。
以上功能以用例圖形式展現,見圖2。
邏輯視圖描述的是設計的對象模型,包含整個軟件系統中最重要的設計類、包和子系統,最終將不同的職責分配給功能模塊、類等不同粒度的邏輯單元。一般采用協作圖來描述邏輯視圖,協作圖見圖3
在圖中可以看到,整個系統架構采用了較多的factory設計模式,使用通用接口工廠類,屏蔽了對外接口的多樣性,便于以后支持的新的通訊接口。使用通用協議工廠類,屏蔽了通訊協議的多樣性,使得系統能支持各種標準通訊協議和自定義協議的消息封裝和解包。
此外,將推進系統中常用的通訊書劃分為三大類:配置參數、狀態參數、故障和告警。
使用Facade模式,為內容解析服務提供統一的接口。從而用戶可根據需要,使用自定義或他人已定義的參數文件,對消息進行解析,無需重復開發代碼。當協議內容或字段變化時,也不用修改軟件,直接修改配置文件,使得開發工作量降低為配置工作量。從而將研發人員在測試中的重點集中于協議參數內容和被測試對象的業務流程處理和響應上,進一步提高了效率。
實現視圖描述了開發環境中軟件的靜態組織結構,包含了按模塊劃分為包和層的模型組織。描述了將邏輯視圖中的包和類分配到實現過程中的包和類。本系統構件圖見圖4。從實現視圖可知,概念架構設計中的分層原則已經落地于構件群中。窗體界面構件體現了概念架構中的展現層,包括收發消息的顯示,實時消息的修改,配置參數的配置,定時間隔的設置,接口的選擇和參數配置等功能。概念架構設計中的業務層,主要由參數內容解析服務組件,消息隊列管理組件,消息發送服務組件,消息接收服務組件構成,實現參數解析,消息發送和接收,消息隊列管理功能。而日志處理、參數定義處理和消息腳本處理三個組件,共同構成了概念架構設計中的數據管理層。最后,接口類組件和協議類組件實現了概念架構設計中接口管理層的功能。
進程視圖包含所涉及任務(進程和線程)的描述以及任務的交互、配置, 關注的不僅僅是構件靜態的依賴關系,而是體現了整個系統的運行架構。進程視圖關注進程和線程等對象運行時的并發、同步、通信,并關注他們之間的交互。因篇幅限制,此處不過多描述。
部署視圖描述了軟件到硬件的映射,包含對平臺的實際運行節點的描述。本次調測平臺為了方便使用,只需要部署在一臺pc或者便攜機上,部署非常簡單,所以此處不再贅述。
軟件體系架構描述了軟件系統中的最基本的結構組織,通常提供了一組已定義好的子系統或者構件,指定其職責,并給出把他們組織在一起的描述和表達。通過軟件體系架構設計,可以清晰表達系統的功能和運作特性,從概念上清晰分析,從而能將一些常用的設計模式應用其中,減少設計遺漏和重復代碼,避免系統包含過多隱含缺陷和累贅。
本文通過4+1視圖表示法,描述了應用于推進系統的開放式通用通訊調測平臺的實現機制,展示了平臺通用性和靈活性。此平臺在實際應用中,也取得了良好的效果。未來在此基礎上,將進一步擴展接口的靈活性,爭取實現接口定義插件化,讓更多的應用者能夠在此基礎上獨立擴展接口。同時,對消息性能測試,也是新版本實現的方向之一。期待此軟件在未來的推進系統通訊測試中發揮更大功效。
[1] 杜育根. IBM RUP方法實踐 . 機械工業出版社, 2013.
[2] 溫昱. 軟件架構設計. 電子工業出版社, 2010.
[3] Gamma&Helm&Johnson&Vlissides. 設計模式. 機械工業出版社, 2000.
[4] 佚名. UML教程. www.ChinaPub.com .
An Open Communication Test Platform for Marine Electric Propulsion System
Xu Mengfei, Zhou Yanhong
(Wuhan Institute of Marine Electric Propulsion , Wuhan 430064 , China)
TP202
A
1003-4862(2014)09-0018-04
2014-07-15
國家科技支撐計劃項目(2012BAG03B01)
徐萌飛(1976-), 男,高級工程師。研究方向:控制工程、軟件工程。