摘要 OSEK/VDX規(guī)范在汽車電子控制系統(tǒng)開發(fā)中具有重要地位，其中OSEK/VDX通信規(guī)范（OSEK COM）為汽車電子通信系統(tǒng)的構(gòu)建提供了依據(jù)和參考。本文介紹了OSEK COM 3.03規(guī)范基于消息的通信機(jī)制，設(shè)計并實(shí)現(xiàn)了一種基于CAN總線的通信系統(tǒng),并對該系統(tǒng)的功能進(jìn)行了測試。測試表明，該通信系統(tǒng)可以很好地實(shí)現(xiàn)消息的發(fā)送和接收功能。

關(guān)鍵詞? 嵌入式實(shí)時操作系統(tǒng)? OSEK/VDX規(guī)范? OSEK COM? 傳輸機(jī)制

引言

　　OSEK/VDX(簡稱OSEK)規(guī)范是歐洲汽車行業(yè)為滿足各種軟件間的兼容性和協(xié)作性而定義的一組帶有通用服務(wù)接口的開放式軟件規(guī)范。它主要由操作系統(tǒng)規(guī)范、通信規(guī)范[1]、網(wǎng)絡(luò)管理規(guī)范[2]和實(shí)現(xiàn)語言規(guī)范[3]4個部分組成。作為OSEK/VDX規(guī)范的一部分，OSEK COM[1]為汽車電控單元應(yīng)用軟件提供了一個統(tǒng)一的通信環(huán)境，它定義了獨(dú)立于所用通信協(xié)議之外的應(yīng)用軟件通信接口，規(guī)定了內(nèi)部通信(ECU內(nèi)部)和外部通信(ECU之間)時的行為方式。OSEK COM隱藏了底層協(xié)議和硬件細(xì)節(jié)，從而增強(qiáng)了應(yīng)用軟件模塊的可移植性和可重用性。此外OSEK COM 實(shí)現(xiàn)只需要很少的資源就可以在多個硬件平臺上運(yùn)行，不同級別的功能要求都可以滿足，體現(xiàn)了可裁減性。

　　目前隨著集成電路和單片機(jī)在汽車上的廣泛應(yīng)用，越來越多的ECU被應(yīng)用到汽車控制領(lǐng)域，如汽車剎車的防抱死系統(tǒng)、動力設(shè)備的安全控制等。ECU內(nèi)部和ECU之間的通信已經(jīng)成為汽車電子控制系統(tǒng)開發(fā)的重要環(huán)節(jié)，在汽車電子和其他嵌入式領(lǐng)域均有明朗的應(yīng)用前景。因此對OSEK COM規(guī)范的研究與實(shí)現(xiàn)具有重要意義。

1? OSEK COM的通信機(jī)制

1.1? OSEK COM的通信模型[1,4]

　　OSEK COM的通信模型分為3個層次：上層為應(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ù)鏈路層。這是因為在規(guī)范中交互層的使用被詳細(xì)地規(guī)定，而網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層沒有詳細(xì)的說明，僅僅定義了網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層支持交互層的所有特性的最低要求。

圖1? OSEK COM及OSEK體系中位置模型

1.2? OSEK COM的通信過程

　　OSEK COM是基于消息對象的通信，消息及其屬性通過OSEK實(shí)現(xiàn)語言(OSEK Implementation Language, OIL)靜態(tài)配置。在內(nèi)部通信過程中（即發(fā)送內(nèi)部消息時），應(yīng)用層調(diào)用交互層提供的發(fā)送消息API，將發(fā)送方的數(shù)據(jù)傳給交互層的消息對象，消息對象直接被復(fù)制到接收消息對象；然后接收方調(diào)用接收消息API，從接收消息對象中讀取消息數(shù)據(jù)。在外部通信過程中（即發(fā)送外部消息時），發(fā)送方的一個或多個消息對象的數(shù)據(jù)按比特位對齊被映射到一個發(fā)送IPDU（交互層協(xié)議數(shù)據(jù)單元）的數(shù)據(jù)區(qū)上，交互層調(diào)用底層協(xié)議將數(shù)據(jù)發(fā)送出去；接收方的接收與發(fā)送方的過程相反，在一個接收指示請求后，底層PDU（協(xié)議數(shù)據(jù)單元）的消息根據(jù)底層協(xié)議收取數(shù)據(jù)到接收IPDU數(shù)據(jù)區(qū)，然后從IPDU數(shù)據(jù)區(qū)取出各接收消息對象的數(shù)據(jù)，完成接收過程。

2? 通信系統(tǒng)的整體設(shè)計

圖2? 通信系統(tǒng)的結(jié)構(gòu)

　　基于OSEK COM規(guī)范的通信系統(tǒng)主要由4個模塊組成（如圖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ā)送外部消息時，在交互層消息對象依次通過過濾算法、字節(jié)順序轉(zhuǎn)化，最后根據(jù)其傳輸模式封裝到相應(yīng)的IPDU。COM規(guī)范定義了3種不同的消息傳輸模式： 直接傳輸模式、周期傳輸模式和混合傳輸模式。下面以周期傳輸模式為例說明消息的傳輸過程。

　　當(dāng)消息具有周期傳輸模式時，將其封裝到具有周期傳輸模式特性的IPDU里。在周期傳輸模式下，每次調(diào)用API函數(shù)SendMessage()、SendDynamicMessage()的服務(wù)更新傳輸?shù)南ο?，交互層每隔周期傳輸模式時間間隔（I_TMP_TPD）執(zhí)行一次周期傳輸請求，傳輸一個IPDU到底層，當(dāng)有傳輸請求時才執(zhí)行IPDU到底層的消息傳輸。周期傳輸模式忽略包含在IPDU里面的所有消息的傳輸特性。當(dāng)消息已經(jīng)發(fā)送到底層后，如果在規(guī)定的時間間隔內(nèi)，底層沒有返回傳輸確認(rèn)，那么立刻調(diào)用通知機(jī)制通知應(yīng)用層，消息的周期傳輸失敗。周期傳輸模式傳輸機(jī)制如圖3所示。

圖3? 周期傳輸模式傳輸機(jī)制

　　在周期傳輸模式的具體實(shí)現(xiàn)過程中，首先判斷該消息是否具有周期傳輸模式的屬性，如果具有，則將周期傳輸模式的標(biāo)志位置1；進(jìn)入中斷后，判斷此時系統(tǒng)時鐘節(jié)拍和上次記錄的系統(tǒng)時鐘節(jié)拍的時間間隔是否大于或等于I_TMP_TPD，若大于時間間隔，則獲得傳輸請求，調(diào)用底層接口函數(shù)立刻傳輸消息到底層，同時記錄此時的系統(tǒng)時鐘節(jié)拍。若消息傳輸成功，底層返回傳輸確認(rèn)；若在規(guī)定時間內(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)生錯誤，表明消息已經(jīng)成功接收到IPDU。然后從IPDU數(shù)據(jù)區(qū)分別取出接收消息對象的數(shù)據(jù)，在經(jīng)過字節(jié)順序轉(zhuǎn)化和過濾算法后，放入消息接收對象。消息接收對象分為隊列消息和非隊列消息，接收到的動態(tài)長度的消息都放入非隊列消息，接收到的靜態(tài)長度消息可以放入隊列或非隊列消息。隊列消息將收到的消息數(shù)據(jù)組合成一個隊列，接收時向隊尾添加新數(shù)據(jù)，讀取時從隊首移走舊數(shù)據(jù)，即FIFO(先進(jìn)先出)方式，隊列消息僅被讀取一次；非隊列消息可以被讀取多次，直接用新數(shù)據(jù)覆蓋舊數(shù)據(jù)。

圖5? ReceiveMessage（）實(shí)現(xiàn)流程

　　應(yīng)用層調(diào)用ReceiveMessage（）和ReceiveDynamicMessage（）API函數(shù)將隊列或非隊列消息中的消息傳遞給應(yīng)用層，實(shí)現(xiàn)消息的接收過程。ReceiveMessage（）函數(shù)的實(shí)現(xiàn)流程如圖5所示。

2.2? CAN模塊的實(shí)現(xiàn)

　　在汽車電子行業(yè)中，CAN總線以結(jié)構(gòu)簡單，成本低，可靠性高，實(shí)時性、抗干擾能力強(qiáng)等特點(diǎn)得到了廣泛的應(yīng)用。CAN總線是一種串行數(shù)據(jù)通信的多主總線。數(shù)據(jù)在節(jié)點(diǎn)間發(fā)送和接收時使用4種不同類型的幀，最基本的信息傳送載體是數(shù)據(jù)幀，它包括11或29位的報文標(biāo)識、0～8字節(jié)的數(shù)據(jù)域和校驗以及控制信息。CAN總線的數(shù)據(jù)鏈路層和物理層協(xié)議已經(jīng)被集成到多個控制器芯片或單片處理機(jī)中，用戶只需定義上面的應(yīng)用層即可實(shí)現(xiàn)一個通信系統(tǒng)。

　　CAN驅(qū)動軟件由CAN初始化程序、CAN發(fā)送程序和CAN接收程序3部分組成。CAN初始化程序?qū)AN模塊的相關(guān)寄存器初始化。在CAN發(fā)送程序中，微處理器將要發(fā)送的數(shù)據(jù)寫入CAN模塊相應(yīng)的發(fā)送緩沖區(qū)中，與主機(jī)的ID地址一起組成信息幀按CAN報文結(jié)構(gòu)發(fā)送到CAN控制器的發(fā)送緩沖器中，并置位命令寄存器中的發(fā)送請求標(biāo)志， 接收到發(fā)送請求后發(fā)送過程由CAN控制器自動完成。在檢測到接收緩沖器中存在有效報文后，中斷接收程序?qū)⒔邮站彌_區(qū)中的內(nèi)容讀入CPU的數(shù)據(jù)存儲區(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)定時器的初始化程序，使用API函數(shù)startcom()來初始化各消息對象并啟動通信。調(diào)用SendMessage()、SendDynamicMessage()、 ReceiveMessage()、ReceiveDynamicMessage()等API函數(shù)可以實(shí)現(xiàn)消息的發(fā)送和接收。

3.2? 通信系統(tǒng)的測試界面

　　使用主機(jī)、周立功USB/CAN轉(zhuǎn)化器、HCS12DP256B開發(fā)板進(jìn)行連接，對消息發(fā)送和接收的情況進(jìn)行測試，并使用周立功ZLGCANTest測試軟件的界面來監(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中序號表示接收到的消息的條數(shù)，數(shù)據(jù)表示應(yīng)用層發(fā)送出去的消息的值。

圖6? 底層接收消息的界面

　　測試的結(jié)果表明：該通信系統(tǒng)各API函數(shù)的功能均可以實(shí)現(xiàn)，數(shù)據(jù)傳輸準(zhǔn)確及時，經(jīng)過合理的參數(shù)配置，可以很好地實(shí)現(xiàn)消息的發(fā)送和接收功能。

結(jié)語

　　由于OSEK規(guī)范本身的優(yōu)點(diǎn)和許多國際嵌入式軟件公司的加盟，它逐漸占據(jù)了汽車電子軟件平臺的主導(dǎo)地位，并成為ISO國際標(biāo)準(zhǔn)。開發(fā)出具有自主知識產(chǎn)權(quán)的符合該標(biāo)準(zhǔn)的系統(tǒng)，加深對OSEK規(guī)范的認(rèn)識，并結(jié)合我國國情參與OSEK規(guī)范的制定，對我國汽車電子行業(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í)時操作系統(tǒng)μC/OS-II[M]．邵貝貝，等譯．第2版. 北京：北京航空航天大學(xué)出版社，2003．
［6］ Morton Todd D.嵌入式微控制器[M]．嚴(yán)雋永，譯．北京：機(jī)械工業(yè)出版社，2005.

李萍(碩士研究生)，研究方向為嵌入式系統(tǒng)設(shè)計開發(fā)。

（收修改稿日期：2008-06-06）