通用半實物仿真資源管理器的設計

金鵬飛, 李曉明

(浙江理工大學機械工程學院, 浙江 杭州 310018)

1 引言(Introduction)

模塊化、通用化、可擴展是虛擬儀器[1]的重要特征,一臺虛擬儀器系統的不同功能模塊可能是由不同的儀器廠家生產的。如果想確保市場上各種各樣不同功能、不同廠家生產的儀器模塊能夠相互組合成為一臺完整的儀器系統并能正常運行,那么對這些儀器模塊進行管理就起到了關鍵性的作用。雖然各類管理軟件產品類型及數量眾多,但是仍主要采取各自的體系架構,在技術內部融合及接口一致性處理方面面臨的技術難度比較大[2-5]。

針對上述問題,楊浩前的研究實現了設備資源的自我控制和自我管理,使用戶擺脫了煩瑣的底層硬件接口驅動命令,但是楊浩前的方案卻沒有包含所有的數據類型,并且在數據傳輸的過程中會出現中斷的錯誤[6];趙俊設計的IVI(互換虛擬儀器)設備驅動分成儀器類驅動和專用驅動兩層,更改函數時,只需要改變其配置文件,而不需要改變上層程序,但是趙俊的方案沒有實現相同儀器間的互換,沒有實現各個儀器之間的通用[7]。為了解決上述設備管理器方案中存在的缺點,本文設計出一種資源管理器的方案,包括資源管理器的功能,前端模塊[8]資源的設計和與之對應的XML[9]配置文件,以及前端模塊和主機模塊的通信協議,實現了半實物仿真的標準化和通用化[10]。

2 資源管理器的設計內容(Design content of resource manager)

本文研究的內容是通用半實物仿真平臺資源管理的設計。這些資源的主要目的是作用于大部分前端設備。其中,需要實現的功能包含設備樹的自動生成、設備運行狀況的實時監測和前端設備的管理。通過該資源管理系統可以在開發平臺對前端硬件進行查看、監測數據文件傳輸及更新前端設備。因此,需要一套符合整個管理軟件開發平臺的前端設備管理器,用于在開發時對當前所連接的前端設備進行管理和狀態監控。基于此,課題的研究內容主要包括以下兩點。

(1)前端模塊管理功能:本系統具備硬件模塊化的特點,主機模塊是系統的控制中心。管理軟件運行于主機模塊之上,對前端模塊進行控制,與前端模塊進行信息交互,實現平臺的測試測量和監測功能。該管理軟件還需要對當前系統內的前端模塊及其運行狀態信息進行管理。

(2)狀態記錄功能:系統中存在很多的特性或狀態需要量化表達。這些狀態有些用于前端模塊的管理,例如模塊的ID、生產廠家ID等;有些狀態用于配置硬件參數,控制平臺系統的運行,例如與總線相關的前端模塊地址濾波器值及基本時間周期值等;有些狀態與總線等硬件狀態密切相關;有些狀態僅用于底層的功能調整或者表達軟件的運行狀態;有些狀態表征系統的運行狀態,需要實時更新獲取,例如某個前端模塊的總線丟幀情況等。因此,需要建立一套標準機制記錄整個系統的狀態運行參數。

3 資源管理器的實現(Implementation of resource manager)

3.1 前端模塊的建模

對于以上需要實現的功能,整個資源管理器中關鍵的部分就是對其設備的管理,而設備管理器系統中最主要管理的對象之一就是形形色色的前端模塊。因此,針對該系統建立了相應的模型圖,如圖1所示。

圖1 設備管理器前端模型Fig.1 Front-end model of the device manager

前端模塊[10]是組合式儀器平臺里的一個組成部分,由DSP(數字信號處理)控制板、總線板和外部接口模塊組成,其中總線板實現了前端模塊與主機及其他前端模塊之間的通信,總線板里的總線是系統內置的儀器總線;DSP控制板主要是一個DSP控制系統,包括DSP和存儲系統等;外部接口模塊是前端模塊與被測實物之間的信號交流接口,例如RS232[11]、1553B總線接口[12]及CameraLink接口[13]等。

3.2 前端模塊資源的設計

前端模塊資源用戶管理前端應用擴展模塊的屬性信息和狀態,記錄模塊的屬性狀態,提供獲取和配置屬性狀態的接口。需要針對前端模塊的硬件特征和測試系統的軟件特征,抽象模塊特性,在總線驅動中量化表達。對屬性特征進行分類,不同類型的屬性有著不同的獲取和配置方式。結合前端模塊的特性,將屬性分為靜態屬性和動態屬性,靜態屬性包含前端模塊的廠家ID等所有前端模塊都具有的屬性,而動態屬性是某些前端模塊獨有的,就需要專門的代碼實現,進而實現資源管理的通用化。現階段對前端模塊資源屬性的分類見表1。

表 1 前端模塊屬性分類表Tab.1 Classification table of front-end module property

3.2.1 XML的設計

通用化設計的標準就是設計有標準的接口,能夠讓所有的其他組件在使用這個數據傳輸組件時,只要根據標準的接口進行設計就能完成數據的傳輸。那么,對于各式各樣的組件,傳輸的數據格式和要求是不一樣的,那么至于這些參數的傳入就可以使用XML文檔進行配置[9-10]。XML可配置的參數有數據類型、數據屬性、輸入端口及輸出端口等。本文用XML語言描述前端模塊提供的資源與功能,包括基礎屬性、配置參數、命令列表、通道列表。因此,為了實現數據標準化,設計了對應的XML文檔,具體實現代碼(節選)如下:

16路輸出口、32路輸入口

3.2.2 JavaBean的設計

數據經過XML文檔傳輸之后會被相應的解析器解析,而數據經過解析后應該有其進行標識,這樣可以在之后的數據處理中提供映射。基于此,設計了對應的JavaBean作為數據的載體,解析數據字段表述見表2。

表 2 解析數據字段表述表Tab.2 Parsing data field description table

3.3 前端模塊與主機模塊的通信協議設計

3.3.1 協議需求分析

為了滿足以上兩種工作模式的需求,設計了前端設備與應用軟件之間的傳輸層協議。該協議主要是根據傳輸的數據類型與功能指定的。傳輸的內容大致可以分為兩大類(圖2):一是工作模式,這種模式下可以與主機模塊一對一地通信、進行模塊注冊、接收資源查詢和配置命令、接收狀態查詢命令、接收DSP應用安裝命令及接收DSP程序信息查詢命令。二是用戶模式,在該模式下能接收消息日志、數據和退出用戶模式的命令。當前端模塊執行DSP程序后會自動進入用戶模式。

圖2 數據傳輸圖Fig.2 Data transmission diagram

3.3.2 通信協議的制定

通信協議的數據鏈路層幀結構如圖3所示,主要包含仲裁場和數據場。仲裁場的功能是首先根據數據的優先級進行判斷,然后判斷該數據是否可以被接收。數據場主要是發送數據,用戶在數據場中可以撰寫自己需要的協議,之后形成TLV(Tag、Length、Value)格式。對于在前端模塊上傳輸的數據,將仲裁場定義為數據幀頭,將數據場定義為數據體。數據的數據場是一個長度為1 024字節的字符數組,消息的數據場是由3個無符號整型數構成的,長度為12字節。

圖3 總線數據鏈路層幀結構Fig.3 Layer frame structure of bus data link

根據資源管理器分析的協議需求和通信特性,將不同功能、不同類型的數據和消息按照不同的通信方式和優先級發送。針對前端模塊的應用情況,對仲裁場和數據場進行定義。對仲裁場的定義如圖4所示,圖4中的type部分是提供給用戶的應用軟件使用的,實現了通用化和標準化。

圖4 消息和數據仲裁場協議Fig.4 Message and data arbitration field protocol

根據仲裁場中的協議規定,數據和消息的優先級主要是依靠協議中的前7位來決定(31—25位)。在仲裁場的協議中,信息的類別class和優先程度degree共同影響著數據的優先權。盡管低位的值可能會對優先權產生影響,但它的影響力不及高位的值,因此最后選擇前7位作為重要的評估標準。數據信息的優先傳輸級一般來自數據信息大類class,但是通過改變degree的方式,也能夠有效地調整默認數據類型的優先程度。將數據信息大類class和degree創新性地結合起來,促使它們之間的關系變得平衡,從而取得最佳的效果。class的取值范圍能夠從0到F不等,它能夠支持16種消息類型和16種數據類型,這樣能夠允許低優先級的數據類型在某些情況下,具有更高的優先權,從而使數據傳輸更為便捷,更具有層次感。

仲裁場中的under字段用來判斷通信是上位機管理軟件(上層)還是虛擬儀器嵌入式系統(底層)。1代表底層通信,0代表上層通信。tag用來指定底層通信中的指令類型,type用來指定上層通信中的指令類型。用戶可以在type中根據自身的需求,設置對應的協議。instr_addr(10—6位)和sessn_id(5—1位)分別是底層通信和上層通信的地址,取值范圍是0—F(Hex)。retry用來顯示數據的發送是否發生了丟幀,正常情況下數字為0,當從0變成1時,就表示出現了丟幀,前端模塊通信就會對數據丟幀進行檢測。如果檢測后發現有數據丟失或者出現錯誤,前端模塊驅動會自動進行重發。

數據場的具體設計如圖5所示。其中,包含關于消息的數據和前端模塊采集的數據。消息總線數據場的首半個字節為消息長度,其余為消息內容;數據總線數據場的前兩個字節為數據長度,其余為數據內容。在數據內容的最后會跟著一個編號,它是一個遞增數,用于丟幀檢測。每當數據傳輸成功后,這個編號就會自動加1,當接收端接收到的數據是斷斷續續的,說明出現了數據丟失,就需要通知發送端重新發送丟失的數據幀。

圖5 消息和數據總線數據場協議Fig.5 Message and data bus data field protocol

3.3.3 通信協議的設計

設備管理器連接到主機模塊,通過主機模塊接口調用VISA(虛擬儀器軟件結構)接口,連接到前端模塊進行獲取。需要與前端模塊通過儀器總線進行交互,按照前文對協議進行分析和制定,前端模塊與主機通信協議節選見表3。

表 3 前端模塊與主機通信協議節選Tab.3 Excerpts from the communication protocol between the front-end module and the host

4 實例演示(Example demonstration)

本文所提軟件是基于浙江大學課題組研發的通用測試儀器系統,實物如圖6所示。

圖6 儀器系統實物圖Fig.6 Physical diagram of instrument system

通過前端模塊和上位機軟件進行通信后,運行上位機管理軟件,可以實時展示前端設備的數據,能夠對前端設備進行管理。如圖7所示,界面左側能夠顯示前端設備的可用狀態,界面右側是對單個前端設備具體信息和數據的展示,界面的下方是日志的輸出。

圖7 上位機管理軟件界面展示Fig.7 PC management software interface display

5 結論(Conclusion)

本文分析了資源管理器技術的研究現狀,針對浙江大學課題組研發的多功能儀器組件前端設備的復雜性,設計相對應的資源管理器方案。對前端模塊進行抽象建模,設計前端模塊的資源管理應用程序,并模擬實際測試案例,驗證通用半實物仿真資源管理器及通信協議標準化方案的可行性,可以實現軟件中關于各種前端模塊中設備樹的自動生成、IO通信、屬性管理、事件通知等全部功能,滿足了資源管理器的應用需求。最重要的是,本設計方案只要配置對應的XML文檔,就可以對前端模塊即插即用,應用程序開發非常簡單,具備標準化、通用性、避免軟件重復開發的特點。