摘要 OSEK/VDX規范在汽車電子控制系統開發中具有重要地位，其中OSEK/VDX通信規范（OSEK COM）為汽車電子通信系統的構建提供了依據和參考。本文介紹了OSEK COM 3.03規范基于消息的通信機制，設計并實現了一種基于CAN總線的通信系統,并對該系統的功能進行了測試。測試表明，該通信系統可以很好地實現消息的發送和接收功能。

關鍵詞? 嵌入式實時操作系統? OSEK/VDX規范? OSEK COM? 傳輸機制

引言

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

　　目前隨著集成電路和單片機在汽車上的廣泛應用，越來越多的ECU被應用到汽車控制領域，如汽車剎車的防抱死系統、動力設備的安全控制等。ECU內部和ECU之間的通信已經成為汽車電子控制系統開發的重要環節，在汽車電子和其他嵌入式領域均有明朗的應用前景。因此對OSEK COM規范的研究與實現具有重要意義。

1? OSEK COM的通信機制

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

　　OSEK COM的通信模型分為3個層次：上層為應用層；中間層為交互層；網絡層、數據鏈路層、物理層統稱為“下層”。如圖1所示， 主要部分是交互層(IL)，? 該層全權處理內部通信，并通過調用下層服務協議處理外部通信。

　　本文基于OSEK COM規范3.03，是目前該規范的最新版本。在圖1中，OSEK COM覆蓋了全部的交互層和部分的網絡層和數據鏈路層。這是因為在規范中交互層的使用被詳細地規定，而網絡層和數據鏈路層沒有詳細的說明，僅僅定義了網絡層和數據鏈路層支持交互層的所有特性的最低要求。

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

1.2? OSEK COM的通信過程

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

2? 通信系統的整體設計

圖2? 通信系統的結構

　　基于OSEK COM規范的通信系統主要由4個模塊組成（如圖2所示）：

　　① 由OSEK COM規范定義的各API函數的實現。為應用程序提供用于消息傳輸服務的COM API。
　　② 交互層和底層之間的調用接口函數的實現。消息從交互層傳輸給底層，以及消息從底層接收到交互層的接口函數的實現。
　　③ 底層通信協議的實現。本通信系統選擇在汽車電子領域應用最廣泛的控制器局域網(Controller Area Network，CAN)總線作為底層的通信協議。
　　④ 系統的配置文件[3]。采用Freescale公司提供的完全支持OSEK OIL標準的OSEKBuilder工具生成配置文件，在根據系統實現的需求來配置消息的屬性等。

2.1? 通信系統核心模塊的實現

　　通信系統主要是實現發送消息和接收消息功能，下面主要介紹ECU之間的通信，即外部消息的接收和發送過程的實現。

2.1.1? 外部消息發送過程的實現[56]

　　發送外部消息時，在交互層消息對象依次通過過濾算法、字節順序轉化，最后根據其傳輸模式封裝到相應的IPDU。COM規范定義了3種不同的消息傳輸模式： 直接傳輸模式、周期傳輸模式和混合傳輸模式。下面以周期傳輸模式為例說明消息的傳輸過程。

　　當消息具有周期傳輸模式時，將其封裝到具有周期傳輸模式特性的IPDU里。在周期傳輸模式下，每次調用API函數SendMessage()、SendDynamicMessage()的服務更新傳輸的消息對象，交互層每隔周期傳輸模式時間間隔（I_TMP_TPD）執行一次周期傳輸請求，傳輸一個IPDU到底層，當有傳輸請求時才執行IPDU到底層的消息傳輸。周期傳輸模式忽略包含在IPDU里面的所有消息的傳輸特性。當消息已經發送到底層后，如果在規定的時間間隔內，底層沒有返回傳輸確認，那么立刻調用通知機制通知應用層，消息的周期傳輸失敗。周期傳輸模式傳輸機制如圖3所示。

圖3? 周期傳輸模式傳輸機制

　　在周期傳輸模式的具體實現過程中，首先判斷該消息是否具有周期傳輸模式的屬性，如果具有，則將周期傳輸模式的標志位置1；進入中斷后，判斷此時系統時鐘節拍和上次記錄的系統時鐘節拍的時間間隔是否大于或等于I_TMP_TPD，若大于時間間隔，則獲得傳輸請求，調用底層接口函數立刻傳輸消息到底層，同時記錄此時的系統時鐘節拍。若消息傳輸成功，底層返回傳輸確認；若在規定時間內沒有傳輸確認，則調用通知機制，表明消息傳輸失敗。至此完成了消息從交互層發送到底層的傳輸過程。周期傳輸的實現流程如圖4所示。直接傳輸模式和混合傳輸模式消息的傳輸實現過程也類似。

圖4? 周期傳輸實現流程

2.1.2? 外部消息接收過程的實現[5]

　　在消息的接收過程中，首先底層接口函數將底層PDU里面的消息取出放入接收IPDU數據區，從底層向OSEK COM傳遞成功或失敗的狀態信息。如果接收指示服務沒有產生錯誤，表明消息已經成功接收到IPDU。然后從IPDU數據區分別取出接收消息對象的數據，在經過字節順序轉化和過濾算法后，放入消息接收對象。消息接收對象分為隊列消息和非隊列消息，接收到的動態長度的消息都放入非隊列消息，接收到的靜態長度消息可以放入隊列或非隊列消息。隊列消息將收到的消息數據組合成一個隊列，接收時向隊尾添加新數據，讀取時從隊首移走舊數據，即FIFO(先進先出)方式，隊列消息僅被讀取一次；非隊列消息可以被讀取多次，直接用新數據覆蓋舊數據。

圖5? ReceiveMessage（）實現流程

　　應用層調用ReceiveMessage（）和ReceiveDynamicMessage（）API函數將隊列或非隊列消息中的消息傳遞給應用層，實現消息的接收過程。ReceiveMessage（）函數的實現流程如圖5所示。

2.2? CAN模塊的實現

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

　　CAN驅動軟件由CAN初始化程序、CAN發送程序和CAN接收程序3部分組成。CAN初始化程序將CAN模塊的相關寄存器初始化。在CAN發送程序中，微處理器將要發送的數據寫入CAN模塊相應的發送緩沖區中，與主機的ID地址一起組成信息幀按CAN報文結構發送到CAN控制器的發送緩沖器中，并置位命令寄存器中的發送請求標志， 接收到發送請求后發送過程由CAN控制器自動完成。在檢測到接收緩沖器中存在有效報文后，中斷接收程序將接收緩沖區中的內容讀入CPU的數據存儲區，接收完畢后檢查總線狀態及溢出情況等并做相應處理。

3? 通信系統的實現

3.1? 通信系統的構成

　　基于CAN總線的通信系統在軟件上使用CodeWarrior編譯器，硬件上選擇Freescale公司的16位單片機HCS12DP256B。

　　在Main()函數中調用CAN初始化程序和系統定時器的初始化程序，使用API函數startcom()來初始化各消息對象并啟動通信。調用SendMessage()、SendDynamicMessage()、 ReceiveMessage()、ReceiveDynamicMessage()等API函數可以實現消息的發送和接收。

3.2? 通信系統的測試界面

　　使用主機、周立功USB/CAN轉化器、HCS12DP256B開發板進行連接，對消息發送和接收的情況進行測試，并使用周立功ZLGCANTest測試軟件的界面來監控消息發送和接收的情況。

　　圖6是在應用層調用API函數SendMessage()發送直接傳輸消息底層接收消息的界面。SendMessage()通過調用底層接口函數將消息傳給開發板上的CAN模塊，再通過CAN模塊的輸出接口與周立功USB/CAN的工具相連，將應用層發送的數據傳到上位機PC的USB接口，并通過ZLGCANTest軟件顯示消息的接收情況。在圖6中序號表示接收到的消息的條數，數據表示應用層發送出去的消息的值。

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

　　測試的結果表明：該通信系統各API函數的功能均可以實現，數據傳輸準確及時，經過合理的參數配置，可以很好地實現消息的發送和接收功能。

結語

　　由于OSEK規范本身的優點和許多國際嵌入式軟件公司的加盟，它逐漸占據了汽車電子軟件平臺的主導地位，并成為ISO國際標準。開發出具有自主知識產權的符合該標準的系統，加深對OSEK規范的認識，并結合我國國情參與OSEK規范的制定，對我國汽車電子行業的發展有著重要意義。本文在基于OSEK COM規范的通信系統的研究和實現方面進行了初步的嘗試，下一步將把該通信模塊應用到RS485總線上，以增強通信模塊的可移植性。

參考文獻

［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汽車電子嵌入式軟件編程技術[M]．羅克露，譯．北京：北京航空航天大學出版社，2004．
［5］? Labrosse Jean J．嵌入式實時操作系統μC/OS-II[M]．邵貝貝，等譯．第2版. 北京：北京航空航天大學出版社，2003．
［6］ Morton Todd D.嵌入式微控制器[M]．嚴雋永，譯．北京：機械工業出版社，2005.

李萍(碩士研究生)，研究方向為嵌入式系統設計開發。

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