佴威至,劉 越,姚 鵬
(北京理工大學(xué)光電學(xué)院,北京100081)
隨著計(jì)算機(jī)對圖形圖像處理與顯示能力的快速發(fā)展,基于虛擬現(xiàn)實(shí)技術(shù)[1]的車輛模擬器得到了越來越廣泛的應(yīng)用。一些發(fā)達(dá)國家將車輛模擬器系統(tǒng)應(yīng)用于產(chǎn)品設(shè)計(jì)開發(fā)、交通評價(jià)以及駕駛員培訓(xùn)等方面[2-4],國內(nèi)也已有多家科研單位設(shè)計(jì)了針對不同車輛的用于科研或訓(xùn)練的車輛模擬器,包括挖掘機(jī)模擬[5]、消防車模擬[6]等。
在車輛模擬器系統(tǒng)座艙中使用真實(shí)的車輛硬件設(shè)備,可讓模擬器的操作員獲得更加真實(shí)的操作體驗(yàn),而這樣的模擬器系統(tǒng)中常包含大量操控及反饋設(shè)備。車輛模擬器座艙內(nèi)硬件設(shè)備數(shù)量增多,常常也使得硬件設(shè)備通信類型增多,因?yàn)椴煌O(shè)備可能分別使用不同的電氣接口,使用不同的通信協(xié)議,沒有統(tǒng)一的“總線”,對每種設(shè)備的數(shù)據(jù)處理方式常常需有很大的不同,這不僅增大了數(shù)據(jù)通信管理的規(guī)模,也增大了數(shù)據(jù)通信管理的復(fù)雜程度。種類繁多的底層設(shè)備通信類型,對于系統(tǒng)的上層功能設(shè)計(jì)者是很不方便的,容易造成系統(tǒng)上層結(jié)構(gòu)也變得復(fù)雜繁瑣。在這種情況下,車輛模擬器系統(tǒng)的數(shù)據(jù)通信管理方式需經(jīng)過更精心設(shè)計(jì),才能讓系統(tǒng)的整體結(jié)構(gòu)更加清晰,上層與底層設(shè)計(jì)更加獨(dú)立,讓系統(tǒng)調(diào)試與維護(hù)更加容易。
本文以某型車輛模擬器系統(tǒng)為依托,設(shè)計(jì)了一種多類型通信的管理方法,可簡化系統(tǒng)的設(shè)計(jì)、維護(hù)和擴(kuò)展等工作。
本設(shè)計(jì)所依托的車輛模擬器系統(tǒng)整體結(jié)構(gòu)包含以下四部分(見圖1)。
①含多種硬件設(shè)備的模擬艙子系統(tǒng)。該模擬艙是一簡易座艙,包含許多在實(shí)際車輛座艙中使用的操控與顯示設(shè)備,并按實(shí)際車輛座艙布局,是模擬器的操作平臺。
②通信管理子系統(tǒng)。該子系統(tǒng)負(fù)責(zé)座艙中各操控設(shè)備的數(shù)據(jù)采集,各反饋設(shè)備的數(shù)據(jù)驅(qū)動(dòng),是信號仿真子系統(tǒng)與真實(shí)座艙設(shè)備間數(shù)據(jù)通信的橋梁。
③信號仿真子系統(tǒng)。該模塊負(fù)責(zé)車輛模擬所必需信號的模擬仿真,包括本車參數(shù)與車外環(huán)境的模擬。
④控制臺子系統(tǒng)。該模塊負(fù)責(zé)系統(tǒng)運(yùn)行控制與運(yùn)行監(jiān)控。
圖1 模擬器系統(tǒng)整體結(jié)構(gòu)Fig.1 Simulator system structure
模擬艙子系統(tǒng)內(nèi)包含多種操控與顯示設(shè)備,每種操控設(shè)備均以數(shù)據(jù)流的形式對外提供操控?cái)?shù)據(jù),每種顯示設(shè)備均需要數(shù)據(jù)流驅(qū)動(dòng)。多種操控與顯示設(shè)備使用多種不同的電氣接口,且數(shù)據(jù)協(xié)議各不相同,沒有統(tǒng)一的“總線”與一致的通信協(xié)議。在這種情況下,為了獲得更清晰的系統(tǒng)結(jié)構(gòu),設(shè)計(jì)一個(gè)獨(dú)立的通信管理子系統(tǒng)專門負(fù)責(zé)模擬艙子系統(tǒng)與其他子系統(tǒng)間的信息交互是必要的。且為了更好地管理座艙內(nèi)各設(shè)備的數(shù)據(jù)通信,通信管理子系統(tǒng)需要經(jīng)由良好的設(shè)計(jì),才能保證設(shè)備間數(shù)據(jù)通信、座艙與仿真子系統(tǒng)間數(shù)據(jù)通信的清晰性、易擴(kuò)展性、易維護(hù)性和易使用性。
通信管理子系統(tǒng)被設(shè)計(jì)為模擬艙子系統(tǒng)與其它子系統(tǒng)間信息交互的唯一通道。座艙內(nèi)所有設(shè)備均應(yīng)僅連接到通信管理子系統(tǒng),由通信管理子系統(tǒng)負(fù)責(zé)其數(shù)據(jù)的收發(fā)。
通信管理子系統(tǒng)結(jié)構(gòu)設(shè)計(jì)如圖2所示。在該子系統(tǒng)中,每一個(gè)硬件接口均有一個(gè)對應(yīng)的接口底層模塊。每一個(gè)接口底層模塊包含實(shí)現(xiàn)該接口通信的底層硬件與軟件。顯然,不同硬件接口的接口底層模塊無論在硬件上還是軟件上都是大不相同的。每一個(gè)硬件接口均有一個(gè)唯一的識別號。
圖2 通信管理子系統(tǒng)結(jié)構(gòu)Fig.2 Communication manager subsystem structure
通信管理子系統(tǒng)的數(shù)據(jù)流圖如圖3所示。每一個(gè)接口底層模塊都與一個(gè)接口協(xié)議模塊一一對應(yīng),接口協(xié)議模塊負(fù)責(zé)調(diào)用接口底層模塊完成數(shù)據(jù)的收發(fā)及組包、解包工作。對于接收到的數(shù)據(jù)幀,接口協(xié)議模塊將其根據(jù)協(xié)議解析為結(jié)構(gòu)清晰、含義明確的消息,提供給上層模塊。對于需要發(fā)送的消息,接口協(xié)議模塊將其組織為協(xié)議規(guī)定的底層數(shù)據(jù)幀格式,并控制接口底層模塊完成數(shù)據(jù)幀的輸出。
圖3 通信管理子系統(tǒng)數(shù)據(jù)流圖Fig.3 Data flow diagram of the subsystem
消息是各設(shè)備數(shù)據(jù)信息的統(tǒng)一表達(dá)格式,包含數(shù)據(jù)來源標(biāo)識、數(shù)據(jù)去向標(biāo)識、數(shù)據(jù)類型標(biāo)識、數(shù)據(jù)名稱標(biāo)識、數(shù)據(jù)屬性標(biāo)識等。不同通信類型的硬件設(shè)備收發(fā)的數(shù)據(jù)流,經(jīng)過相應(yīng)接口協(xié)議模塊的組包與解包后,都轉(zhuǎn)化為格式一致的消息,對于上層模塊是無區(qū)別的。
所有接口協(xié)議模塊之上是消息管理模塊,該模塊統(tǒng)一管理各接口的消息收發(fā)任務(wù),是與功能層模塊直接交互的模塊,為功能層模塊提供方便簡單的調(diào)用接口。每一個(gè)硬件接口通過“登記”的方式與消息管理模塊建立聯(lián)系,在登記的過程中,消息管理模塊記錄下接口的識別號,以及哪些功能層模塊需要該接口接收的數(shù)據(jù)。當(dāng)來自某硬件設(shè)備的一條消息產(chǎn)生時(shí),消息管理模塊將其派送給需要它的功能層模塊。同時(shí),功能層模塊需要發(fā)送一條消息時(shí),只需將其交給消息管理模塊,消息管理模塊跟據(jù)接口標(biāo)識決定將該消息派送給哪些硬件接口。
在上述結(jié)構(gòu)下,功能層模塊設(shè)計(jì)不再需要顧慮繁多的數(shù)據(jù)通信類型與互異的數(shù)據(jù)流處理方法,從不同的硬件接口讀入或輸出數(shù)據(jù)都使用相同的方法,僅需通過不同的識別號區(qū)分不同的硬件接口,從而實(shí)現(xiàn)與底層硬件管理的分離,只需專注于功能邏輯,完成模擬艙子系統(tǒng)、信號仿真子系統(tǒng)與控制臺子系統(tǒng)間必要的信息交互。
該通信管理方法具有以下優(yōu)點(diǎn)。
①使系統(tǒng)的硬件設(shè)備管理更清晰。該方法對各種不同類型的硬件通信經(jīng)底層封裝后進(jìn)行上層統(tǒng)一管理,使各種類型的通信管理不再散亂分立。
②使系統(tǒng)底層設(shè)計(jì)與上層設(shè)計(jì)相互更獨(dú)立。對系統(tǒng)設(shè)計(jì)者而言,繁多的通信類型不再干擾系統(tǒng)上層功能設(shè)計(jì),系統(tǒng)功能層設(shè)計(jì)者不需關(guān)心通信的底層實(shí)現(xiàn),只需專注于功能邏輯的設(shè)計(jì)。同時(shí),各種硬件通信的底層實(shí)現(xiàn)設(shè)計(jì)者只要按照規(guī)范將數(shù)據(jù)流轉(zhuǎn)化為消息,并提供消息內(nèi)容解釋說明,不需再分別單獨(dú)考慮如何與上層功能設(shè)計(jì)更好配合的問題。
③使系統(tǒng)開發(fā)與維護(hù)更容易。這是該通信管理方法具有的最核心優(yōu)點(diǎn)。在車輛模擬器系統(tǒng)開發(fā)過程中,經(jīng)常會(huì)遇到各級設(shè)計(jì)的修改與反復(fù),例如修改座艙中某個(gè)操控設(shè)備的硬件接口,修改座艙中某個(gè)操控設(shè)備的通信協(xié)議,更換某個(gè)底層硬件的型號,修改幾個(gè)設(shè)備間邏輯主從關(guān)系等。每一項(xiàng)修改通常只需修改結(jié)構(gòu)中的相關(guān)層,而與其它層無關(guān)。例如,若要修改座艙中某個(gè)操控設(shè)備的通信協(xié)議,只需用新的接口協(xié)議模塊替換原來對應(yīng)模塊,并保持識別號與原來相同,而接口底層模塊和其他上層模塊不需改動(dòng)。
本文所研究的車輛模擬器系統(tǒng)包含模擬艙、通信管理計(jì)算機(jī)、信號仿真計(jì)算機(jī)以及控制臺計(jì)算機(jī)等。其中,信號仿真計(jì)算機(jī)組、控制臺計(jì)算機(jī)和通信管理計(jì)算機(jī)通過以太局域網(wǎng)相連,模擬艙內(nèi)的多種操控設(shè)備通過不同種類的硬件接口與通信管理計(jì)算機(jī)相連,包括CAN總線接口、RS232接口,RS485接口,RS422接口,TCP以太網(wǎng)通信接口和UDP以太網(wǎng)通信接口。
通信管理計(jì)算機(jī)是前一節(jié)通信管理子系統(tǒng)設(shè)計(jì)的實(shí)現(xiàn)。該計(jì)算機(jī)中安裝了多種硬件接口卡。通信管理計(jì)算機(jī)上運(yùn)行通信管理軟件,通信管理軟件基于Microsoft.NET Framework 2.0平臺,采用C#語言編寫。
通信管理軟件的面向?qū)ο蠼Y(jié)構(gòu)設(shè)計(jì)對應(yīng)前一節(jié)所述的通信管理子系統(tǒng)結(jié)構(gòu)設(shè)計(jì)。程序核心包括一個(gè)接口底層父類、一個(gè)接口協(xié)議父類、一個(gè)消息管理類和一個(gè)模擬功能父類,分別對應(yīng)通信管理子系統(tǒng)結(jié)構(gòu)設(shè)計(jì)的四個(gè)主要模塊。
對每一個(gè)硬件接口,都從接口底層父類和接口協(xié)議父類派生出相應(yīng)的子類,接口底層子類對象實(shí)現(xiàn)硬件接口數(shù)據(jù)收發(fā)的底層細(xì)節(jié),接口協(xié)議子類對象根據(jù)各設(shè)備的通信協(xié)議完成數(shù)據(jù)幀的組織與收發(fā)。每個(gè)接口協(xié)議子類對象內(nèi)各運(yùn)行一個(gè)獨(dú)立的線程,用于主動(dòng)接收數(shù)據(jù)幀,并按照協(xié)議將收到的數(shù)據(jù)幀經(jīng)拼包、校驗(yàn)、轉(zhuǎn)義等程序組織成為消息交給消息管理類對象。程序中有惟一一個(gè)消息管理類對象,負(fù)責(zé)消息在上層模塊與底層模塊間的傳遞。模擬功能類對象實(shí)現(xiàn)程序的上層邏輯。
部分功能層模塊只需要與一個(gè)硬件接口相關(guān)聯(lián),同時(shí)也有一些功能層模塊需要與多個(gè)硬件接口相關(guān)聯(lián),即需要從多個(gè)硬件接口收發(fā)數(shù)據(jù)。為此,消息管理類中存放了一個(gè)模擬功能子類與硬件接口的關(guān)系表,用來記錄各個(gè)模擬功能子類所需要使用的硬件接口。在程序初始化時(shí),各模擬功能子類對象需登記聲明需要使用的硬件接口,這樣當(dāng)這些硬件接口接收到數(shù)據(jù)并組織成為消息后,消息管理類會(huì)將消息傳送給這些子類對象。
控制臺子系統(tǒng)與信號仿真子系統(tǒng)通過以太網(wǎng)通信與通信管理計(jì)算機(jī)交互信息。對于通信管理子系統(tǒng),控制臺子系統(tǒng)與信號仿真子系統(tǒng)雖然不屬于模擬艙內(nèi)的設(shè)備,但可使用一致的方式進(jìn)行數(shù)據(jù)通信,即將網(wǎng)絡(luò)通信也視為一類硬件接口,將其封裝并接受與消息管理類同等的管理。這種方式強(qiáng)化了通信管理子系統(tǒng)對各類通信統(tǒng)一管理的思想。
本文提出的通信管理方法在某型車輛模擬器系統(tǒng)中得到應(yīng)用(見圖4)。該車輛模擬器系統(tǒng)的設(shè)計(jì)與研發(fā)過程中,時(shí)常遇到與座艙設(shè)備相關(guān)的設(shè)計(jì)修改與反復(fù)。該通信管理方法在其中的應(yīng)用使得這些修改與反復(fù)通常比較容易處理,且每次處理后很少直接引起其它已正常工作的模塊出現(xiàn)新的問題。
圖4 座艙示意圖Fig.4 The cabin
一些艙內(nèi)使用的硬件設(shè)備與該模擬器同步研發(fā),因此時(shí)常更改通信協(xié)議,通信管理軟件對此做出相應(yīng)的更改時(shí),只修改該硬件設(shè)備的接口協(xié)議子類的程序,與其它程序模塊的開發(fā)并行完成,未打斷或影響其它程序模塊的開發(fā)進(jìn)度。一些硬件設(shè)備具有多個(gè)版本,且都會(huì)在不同批次的模擬器系統(tǒng)中使用,針對這一種硬件設(shè)備多個(gè)版本分別同時(shí)使用的情況,該硬件設(shè)備的接口底層子類與接口協(xié)議子類也設(shè)計(jì)派生出多種版本,使通信管理軟件可根據(jù)用戶的指令在線選擇使用其中某個(gè)版本,啟用相應(yīng)的軟件模塊,由此避免在安裝新批次系統(tǒng)及維護(hù)舊批次系統(tǒng)時(shí)再調(diào)整程序。還有一些硬件設(shè)備在系統(tǒng)中的數(shù)量時(shí)常被調(diào)整,其接口底層子類及接口協(xié)議子類實(shí)例化為對象的數(shù)量則需做出相應(yīng)調(diào)整,并收發(fā)同樣的消息,僅是識別號不同,亦未對上層程序開發(fā)造成額外影響。
在該車輛模擬器系統(tǒng)運(yùn)行過程中,通信管理子系統(tǒng)工作穩(wěn)定,未觀察到丟失通信信息的現(xiàn)象。當(dāng)某些硬件設(shè)備的工作狀態(tài)或通信狀態(tài)出現(xiàn)異常時(shí),很少對其它無關(guān)硬件設(shè)備的正常工作造成影響。通信管理子系統(tǒng)為座艙內(nèi)各操控與顯示設(shè)備提供了穩(wěn)定的驅(qū)動(dòng)。
本文提出一種車輛模擬器系統(tǒng)中硬件設(shè)備通信的管理方法,將不同的硬件接口進(jìn)行底層封裝后用統(tǒng)一的方式管理,使不同的硬件接口對上層功能來說具有一致性。將該通信管理方法設(shè)計(jì)應(yīng)用于某型車輛模擬器系統(tǒng),使該系統(tǒng)的設(shè)計(jì)、維護(hù)與擴(kuò)展工作變得容易,并為該系統(tǒng)的運(yùn)行提供了良好的支撐。
[1]Bryson S.Approaches to the successful design and implementation of vr applications[C]∥SIGGRAPH 94,Orlando,1994.
[2]Norfleet D,Wagner J.Automotive driving simulators: research,education,and entertainment[J].SAE Int J Passeng Cars-Electron Electr Syst,2009,2(1):186-193.
[3]Arjona J T,Menendez JM.Virtual reality devices in driving simulators:state of the artand ongoing developments at UPM[R].FP6-Prio 2:Information Society Technologies,2005.
[4]王晶,劉小明,李德慧.駕駛模擬器現(xiàn)狀及應(yīng)用研究[J].交通標(biāo)準(zhǔn)化,2008(11):160-163.
Wang Jing,Liu Xiao-ming,LiDe-h(huán)ui.Driving simulator status quo and application research[J].Communications Standardization,2008(11):160-163.
[5]王東,陳明宏,鐘冠,等.某型挖掘機(jī)模擬操作艙和信號采集電路設(shè)計(jì)[J].建筑機(jī)械,2010(19):97-100.
Wang Dong,Chen Ming-h(huán)ong,Zhong Guan,etal.Design of simulated cockpit and signal acquisition circuit for a kind of excavator[J].Construction Machinery,2010 (19):97-100.
[6]王立文,李洪帥.機(jī)場消防車輛模擬器的視景系統(tǒng)研究[J].計(jì)算機(jī)工程與應(yīng)用,2012,48(7):238-241.
Wang Li-wen,LiHong-shuai.Visual simulation research on pumper simulator of airfield[J].Computer Engineering and Applications,2012,48(7):238-241.