|
OSEK/VDX(簡稱OSEK)規(guī)范是歐洲汽車行業(yè)為滿足各種軟件間的兼容性和協(xié)作性而定義的一組帶有通用服務(wù)接口的開放式軟件規(guī)范。它主要由操作系統(tǒng)規(guī)范、通信規(guī)范[1]、網(wǎng)絡(luò)管理規(guī)范[2]和實(shí)現(xiàn)語言規(guī)范[3]4個(gè)部分組成。作為OSEK/VDX規(guī)范的一部分，OSEK COM[1]為汽車電控單元應(yīng)用軟件提供了一個(gè)統(tǒng)一的通信環(huán)境，它定義了獨(dú)立于所用通信協(xié)議之外的應(yīng)用軟件通信接口，規(guī)定了內(nèi)部通信(ECU內(nèi)部)和外部通信(ECU之間)時(shí)的行為方式。OSEK COM隱藏了底層協(xié)議和硬件細(xì)節(jié)，從而增強(qiáng)了應(yīng)用軟件模塊的可移植性和可重用性。此外OSEK COM 實(shí)現(xiàn)只需要很少的資源就可以在多個(gè)硬件平臺(tái)上運(yùn)行，不同級(jí)別的功能要求都可以滿足，體現(xiàn)了可裁減性。 目前隨著集成電路和單片機(jī)在汽車上的廣泛應(yīng)用，越來越多的ECU被應(yīng)用到汽車控制領(lǐng)域，如汽車剎車的防抱死系統(tǒng)、動(dòng)力設(shè)備的安全控制等。ECU內(nèi)部和ECU之間的通信已經(jīng)成為汽車電子控制系統(tǒng)開發(fā)的重要環(huán)節(jié)，在汽車電子和其他嵌入式領(lǐng)域均有明朗的應(yīng)用前景。因此對(duì)OSEK COM規(guī)范的研究與實(shí)現(xiàn)具有重要意義。 1 OSEK COM的通信機(jī)制 1.1 OSEK COM的通信模型[1,4] OSEK COM的通信模型分為3個(gè)層次：上層為應(yīng)用層；中間層為交互層；網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層、物理層統(tǒng)稱為“下層”。如圖1所示， 主要部分是交互層(IL)， 該層全權(quán)處理內(nèi)部通信，并通過調(diào)用下層服務(wù)協(xié)議處理外部通信。 本文基于OSEK COM規(guī)范3.03，是目前該規(guī)范的最新版本。在圖1中，OSEK COM覆蓋了全部的交互層和部分的網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層。這是因?yàn)樵谝?guī)范中交互層的使用被詳細(xì)地規(guī)定，而網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層沒有詳細(xì)的說明，僅僅定義了網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層支持交互層的所有特性的最低要求。 
圖1 OSEK COM及OSEK體系中位置模型 1.2 OSEK COM的通信過程 OSEK COM是基于消息對(duì)象的通信，消息及其屬性通過OSEK實(shí)現(xiàn)語言(OSEK Implementation Language, OIL)靜態(tài)配置。在內(nèi)部通信過程中（即發(fā)送內(nèi)部消息時(shí)），應(yīng)用層調(diào)用交互層提供的發(fā)送消息API，將發(fā)送方的數(shù)據(jù)傳給交互層的消息對(duì)象，消息對(duì)象直接被復(fù)制到接收消息對(duì)象；然后接收方調(diào)用接收消息API，從接收消息對(duì)象中讀取消息數(shù)據(jù)。在外部通信過程中（即發(fā)送外部消息時(shí)），發(fā)送方的一個(gè)或多個(gè)消息對(duì)象的數(shù)據(jù)按比特位對(duì)齊被映射到一個(gè)發(fā)送IPDU（交互層協(xié)議數(shù)據(jù)單元）的數(shù)據(jù)區(qū)上，交互層調(diào)用底層協(xié)議將數(shù)據(jù)發(fā)送出去；接收方的接收與發(fā)送方的過程相反，在一個(gè)接收指示請(qǐng)求后，底層PDU（協(xié)議數(shù)據(jù)單元）的消息根據(jù)底層協(xié)議收取數(shù)據(jù)到接收IPDU數(shù)據(jù)區(qū)，然后從IPDU數(shù)據(jù)區(qū)取出各接收消息對(duì)象的數(shù)據(jù)，完成接收過程。 2 通信系統(tǒng)的整體設(shè)計(jì)
圖2 通信系統(tǒng)的結(jié)構(gòu) 基于OSEK COM規(guī)范的通信系統(tǒng)主要由4個(gè)模塊組成（如圖2所示）： ① 由OSEK COM規(guī)范定義的各API函數(shù)的實(shí)現(xiàn)。為應(yīng)用程序提供用于消息傳輸服務(wù)的COM API。 ② 交互層和底層之間的調(diào)用接口函數(shù)的實(shí)現(xiàn)。消息從交互層傳輸給底層，以及消息從底層接收到交互層的接口函數(shù)的實(shí)現(xiàn)。 ③ 底層通信協(xié)議的實(shí)現(xiàn)。本通信系統(tǒng)選擇在汽車電子領(lǐng)域應(yīng)用最廣泛的控制器局域網(wǎng)(Controller Area Network，CAN)總線作為底層的通信協(xié)議。 ④ 系統(tǒng)的配置文件[3]。采用Freescale公司提供的完全支持OSEK OIL標(biāo)準(zhǔn)的OSEKBuilder工具生成配置文件，在根據(jù)系統(tǒng)實(shí)現(xiàn)的需求來配置消息的屬性等。 2.1 通信系統(tǒng)核心模塊的實(shí)現(xiàn) 通信系統(tǒng)主要是實(shí)現(xiàn)發(fā)送消息和接收消息功能，下面主要介紹ECU之間的通信，即外部消息的接收和發(fā)送過程的實(shí)現(xiàn)。 2.1.1 外部消息發(fā)送過程的實(shí)現(xiàn)[56] 發(fā)送外部消息時(shí)，在交互層消息對(duì)象依次通過過濾算法、字節(jié)順序轉(zhuǎn)化，最后根據(jù)其傳輸模式封裝到相應(yīng)的 IPDU。COM規(guī)范定義了3種不同的消息傳輸模式： 直接傳輸模式、周期傳輸模式和混合傳輸模式。下面以周期傳輸模式為例說明消息的傳輸過程。 當(dāng)消息具有周期傳輸模式時(shí)，將其封裝到具有周期傳輸模式特性的IPDU里。在周期傳輸模式下，每次調(diào)用API函數(shù)SendMessage()、 SendDynamicMessage()的服務(wù)更新傳輸?shù)南?duì)象，交互層每隔周期傳輸模式時(shí)間間隔（I_TMP_TPD）執(zhí)行一次周期傳輸請(qǐng)求，傳輸一個(gè)IPDU到底層，當(dāng)有傳輸請(qǐng)求時(shí)才執(zhí)行IPDU到底層的消息傳輸。周期傳輸模式忽略包含在IPDU里面的所有消息的傳輸特性。當(dāng)消息已經(jīng)發(fā)送到底層后，如果在規(guī)定的時(shí)間間隔內(nèi)，底層沒有返回傳輸確認(rèn)，那么立刻調(diào)用通知機(jī)制通知應(yīng)用層，消息的周期傳輸失敗。周期傳輸模式傳輸機(jī)制如圖3所示。
圖3 周期傳輸模式傳輸機(jī)制 在周期傳輸模式的具體實(shí)現(xiàn)過程中，首先判斷該消息是否具有周期傳輸模式的屬性，如果具有，則將周期傳輸模式的標(biāo)志位置1；進(jìn)入中斷后，判斷此時(shí)系統(tǒng)時(shí)鐘節(jié)拍和上次記錄的系統(tǒng)時(shí)鐘節(jié)拍的時(shí)間間隔是否大于或等于I_TMP_TPD，若大于時(shí)間間隔，則獲得傳輸請(qǐng)求，調(diào)用底層接口函數(shù)立刻傳輸消息到底層，同時(shí)記錄此時(shí)的系統(tǒng)時(shí)鐘節(jié)拍。若消息傳輸成功，底層返回傳輸確認(rèn)；若在規(guī)定時(shí)間內(nèi)沒有傳輸確認(rèn)，則調(diào)用通知機(jī)制，表明消息傳輸失敗。至此完成了消息從交互層發(fā)送到底層的傳輸過程。周期傳輸?shù)膶?shí)現(xiàn)流程如圖4所示。直接傳輸模式和混合傳輸模式消息的傳輸實(shí)現(xiàn)過程也類似。
圖4 周期傳輸實(shí)現(xiàn)流程 2.1.2 外部消息接收過程的實(shí)現(xiàn)[5] 在消息的接收過程中，首先底層接口函數(shù)將底層PDU里面的消息取出放入接收IPDU數(shù)據(jù)區(qū)，從底層向 OSEK COM傳遞成功或失敗的狀態(tài)信息。如果接收指示服務(wù)沒有產(chǎn)生錯(cuò)誤，表明消息已經(jīng)成功接收到IPDU。然后從IPDU數(shù)據(jù)區(qū)分別取出接收消息對(duì)象的數(shù)據(jù)，在經(jīng)過字節(jié)順序轉(zhuǎn)化和過濾算法后，放入消息接收對(duì)象。消息接收對(duì)象分為隊(duì)列消息和非隊(duì)列消息，接收到的動(dòng)態(tài)長度的消息都放入非隊(duì)列消息，接收到的靜態(tài)長度消息可以放入隊(duì)列或非隊(duì)列消息。隊(duì)列消息將收到的消息數(shù)據(jù)組合成一個(gè)隊(duì)列，接收時(shí)向隊(duì)尾添加新數(shù)據(jù)，讀取時(shí)從隊(duì)首移走舊數(shù)據(jù)，即FIFO(先進(jìn)先出)方式，隊(duì)列消息僅被讀取一次；非隊(duì)列消息可以被讀取多次，直接用新數(shù)據(jù)覆蓋舊數(shù)據(jù)。
圖5 ReceiveMessage（）實(shí)現(xiàn)流程 應(yīng)用層調(diào)用ReceiveMessage（）和ReceiveDynamicMessage（）API函數(shù)將隊(duì)列或非隊(duì)列消息中的消息傳遞給應(yīng)用層，實(shí)現(xiàn)消息的接收過程。ReceiveMessage（）函數(shù)的實(shí)現(xiàn)流程如圖5所示。 2.2 CAN模塊的實(shí)現(xiàn) 在汽車電子行業(yè)中，CAN總線以結(jié)構(gòu)簡單，成本低，可靠性高，實(shí)時(shí)性、抗干擾能力強(qiáng)等特點(diǎn)得到了廣泛的應(yīng)用。CAN總線是一種串行數(shù)據(jù)通信的多主總線。數(shù)據(jù)在節(jié)點(diǎn)間發(fā)送和接收時(shí)使用4種不同類型的幀，最基本的信息傳送載體是數(shù)據(jù)幀，它包括11或29位的報(bào)文標(biāo)識(shí)、0～8字節(jié)的數(shù)據(jù)域和校驗(yàn)以及控制信息。CAN總線的數(shù)據(jù)鏈路層和物理層協(xié)議已經(jīng)被集成到多個(gè)控制器芯片或單片處理機(jī)中，用戶只需定義上面的應(yīng)用層即可實(shí)現(xiàn)一個(gè)通信系統(tǒng)。 CAN驅(qū)動(dòng)軟件由 CAN初始化程序、CAN發(fā)送程序和CAN接收程序3部分組成。CAN初始化程序?qū)AN模塊的相關(guān)寄存器初始化。在CAN發(fā)送程序中，微處理器將要發(fā)送的數(shù)據(jù)寫入CAN模塊相應(yīng)的發(fā)送緩沖區(qū)中，與主機(jī)的ID地址一起組成信息幀按CAN報(bào)文結(jié)構(gòu)發(fā)送到CAN控制器的發(fā)送緩沖器中，并置位命令寄存器中的發(fā)送請(qǐng)求標(biāo)志， 接收到發(fā)送請(qǐng)求后發(fā)送過程由CAN控制器自動(dòng)完成。在檢測(cè)到接收緩沖器中存在有效報(bào)文后，中斷接收程序?qū)⒔邮站彌_區(qū)中的內(nèi)容讀入CPU的數(shù)據(jù)存儲(chǔ)區(qū)，接收完畢后檢查總線狀態(tài)及溢出情況等并做相應(yīng)處理。 3 通信系統(tǒng)的實(shí)現(xiàn) 3.1 通信系統(tǒng)的構(gòu)成 基于CAN總線的通信系統(tǒng)在軟件上使用CodeWarrior編譯器，硬件上選擇Freescale公司的16位單片機(jī) HCS12DP256B。 在Main()函數(shù)中調(diào)用CAN初始化程序和系統(tǒng)定時(shí)器的初始化程序，使用API函數(shù)startcom()來初始化各消息對(duì)象并啟動(dòng)通信。調(diào)用SendMessage()、SendDynamicMessage()、 ReceiveMessage()、ReceiveDynamicMessage()等API函數(shù)可以實(shí)現(xiàn)消息的發(fā)送和接收。 3.2 通信系統(tǒng)的測(cè)試界面 使用主機(jī)、周立功USB/CAN轉(zhuǎn)化器、HCS12DP256B開發(fā)板進(jìn)行連接，對(duì)消息發(fā)送和接收的情況進(jìn)行測(cè)試，并使用周立功ZLGCANTest測(cè)試軟件的界面來監(jiān)控消息發(fā)送和接收的情況。 圖6是在應(yīng)用層調(diào)用API函數(shù) SendMessage()發(fā)送直接傳輸消息底層接收消息的界面。SendMessage()通過調(diào)用底層接口函數(shù)將消息傳給開發(fā)板上的CAN模塊，再通過CAN模塊的輸出接口與周立功USB/CAN的工具相連，將應(yīng)用層發(fā)送的數(shù)據(jù)傳到上位機(jī)PC的USB接口，并通過ZLGCANTest軟件顯示消息的接收情況。在圖6中序號(hào)表示接收到的消息的條數(shù)，數(shù)據(jù)表示應(yīng)用層發(fā)送出去的消息的值。
圖6 底層接收消息的界面 測(cè)試的結(jié)果表明：該通信系統(tǒng)各API函數(shù)的功能均可以實(shí)現(xiàn)，數(shù)據(jù)傳輸準(zhǔn)確及時(shí)，經(jīng)過合理的參數(shù)配置，可以很好地實(shí)現(xiàn)消息的發(fā)送和接收功能。 結(jié)語 由于OSEK規(guī)范本身的優(yōu)點(diǎn)和許多國際嵌入式軟件公司的加盟，它逐漸占據(jù)了汽車電子軟件平臺(tái)的主導(dǎo)地位，并成為ISO國際標(biāo)準(zhǔn)。開發(fā)出具有自主知識(shí)產(chǎn)權(quán)的符合該標(biāo)準(zhǔn)的系統(tǒng)，加深對(duì)OSEK規(guī)范的認(rèn)識(shí)，并結(jié)合我國國情參與OSEK規(guī)范的制定，對(duì)我國汽車電子行業(yè)的發(fā)展有著重要意義。本文在基于OSEK COM規(guī)范的通信系統(tǒng)的研究和實(shí)現(xiàn)方面進(jìn)行了初步的嘗試，下一步將把該通信模塊應(yīng)用到RS485總線上，以增強(qiáng)通信模塊的可移植性。 參考文獻(xiàn) ［1］ OSEK/VDX Organization. OSEK/VDX communication specification 3.0.3[EB/OL]，20040720[200805]. http: //www.osekvdx.org. ［2］ OSEK/VDX Organization. OSEK/VDX network management specification2.5.3[EB/OL],20050201[200805]. http://www.osekvdx.org. ［3］ OSEK/VDX Organization.OSEK/VDX system generation,OIL:OSEK implementation language. Version2.5[EB/OL],20040701[200805].http: //www.osekvdx.org. ［4］ Joseph L．OSEK/VDX汽車電子嵌入式軟件編程技術(shù)[M]．羅克露，譯．北京：北京航空航天大學(xué)出版社，2004． ［5］ Labrosse Jean J．嵌入式實(shí)時(shí)操作系統(tǒng)μC/OS-II[M]．邵貝貝，等譯．第2版. 北京：北京航空航天大學(xué)出版社，2003． ［6］ Morton Todd D.嵌入式微控制器[M]．嚴(yán)雋永，譯．北京：機(jī)械工業(yè)出版社，2005. 作者：重慶郵電大學(xué) 李萍 蔣建春 來源：單片機(jī)與嵌入式系統(tǒng)應(yīng)用 2008 (9) |
