基于K線/CAN總線的KWP2000協議分析及協議棧的開發測試
K線網絡結構單一,網絡管理功能很弱;而利用CAN總線可構建復雜的網絡結構,可跨越網段進行遠程診斷。
K線網絡采用破壞性的仲裁機制,當診斷設備采用功能尋址與多個ECU進行通訊時,為避免總線沖突,ECU開發者必須采取措施保證多個ECU順序訪問總線;而CAN網絡采用非破壞性的仲裁機制,并且仲裁過程由數據鏈路層完成,當診斷設備采用功能尋址與多個ECU進行通訊時,ECU開發者不必考慮總線訪問沖突問題。
K線服務報文最大字節長度僅為255,無法滿足更長報文的傳輸要求,并且在長報文的傳輸過程中用戶必須自己采取措施進行連接管理,可靠性和兼容性較差;而CAN總線診斷服務報文最大字節長度可達4096(12位),對于長報文的傳輸,網絡層協議還具備標準化和規范化的同步控制、順序控制、流控制和錯誤恢復等功能,具備很高的可靠性、兼容性。
5 KWP2000協議棧的開發及測試
從前面的協議分析可以看出,無論是基于K線還是CAN總線的KWP2000協議,都是邏輯非常復雜的系統,并且具有嚴格的定時和錯誤處理規范。如果采用純手工的方式來進行KWP2000協議棧的開發,不僅要耗費大量的時間和人力,其通用性、完備性、可靠性和可維護性都很難保證。而MATLAB/Simulink/StateFlow不僅具備方便快捷的上層實時仿真環境,還集成了高效的嵌入式代碼自動生成工具,為協議棧的開發和維護提供了強大的支持平臺。此外,由德國Vector公司的CANoe軟件和相關硬件板卡組成的應用開發平臺,可用于汽車網絡(CAN,Lin等)的上層協議開發和系統測試,該平臺同時支持基于K線和CAN總線的KWP2000診斷協議,可作為ECU和診斷設備的測試標準。
圖6是協議源碼開發過程示意圖。首先在MATLAB/Simulink/StateFlow中遵照協議標準進行KWP2000協議棧開發,在仿真調試環境下實現通訊邏輯、定時控制和錯誤處理,待系統完善后利用StateFlow嵌入式代碼生成工具自動生成協議棧C代碼,并與目標系統的底層驅動進行集成,然后植入目標系統形成應用程序,最后再利用CANoe作為標準進行系統集成測試。

圖6 KWP2000協議棧開發及測試流程
在MATLAB/Simulink/StateFlow中進行協議棧仿真開發是協議棧開發過程中的關鍵環節,在這一過程中必須嚴格遵照協議標準來實現通訊邏輯,往往需要經過多次“設計-仿真-修改”循環才能使系統最終趨于完善。MATLAB的圖形界面提供了方便快捷的仿真輸入/輸出接口,可大幅度加快開發進度。
協議棧開發完成后可利用CANoe作為標準進行系統集成測試,CANoe的KWP2000協議測試環境如圖7所示。

圖7 CANoe的KWP2000測試環境示意圖
CANoe中的KWP2000實際指的是基于CAN總線的KWP2000,即15765協議。由于CANoe默認的硬件板卡是CAN卡,因此在建立仿真程序時,只需將ECU的網絡模塊設置為kwp2000.dll即可進行CAN總線的KWP2000服務測試。kwp2000.dll中包含15765應用層協議中規定的服務請求、服務指示、服務響應和服務確認接口函數,用戶調用這些函數即可完成Tester端和ECU端的KWP2000診斷服務。此外,該模塊中的功能函數還可對ECU的源地址、目標地址、尋址模式等參數進行動態設置。需要注意的是,kwp2000.dll目前只提供了部分KWP2000服務的接口函數,如果用戶需要進行其它的KWP2000服務測試,必須根據KWP2000應用層協議構造服務報文數據,然后調用該模塊中的KWP_DataReq()和KWP_GetRxData()函數進行報文的發送和接收。
進行基于K線的KWP2000服務測試時,需要將KLineCPL.dll模塊加入CANoe仿真環境,并使用一個代理節點來實現CAN網絡和K線之間的報文轉發。此時CANoe使用計算機的串口,并通過一個串口/K線轉換器與實際的ECU相連,如圖8所示。

圖8 CANoe中基于K線的KWP2000測試連接示意圖
6 結束語
KWP2000是一套非常完善的車載故障診斷協議標準,協議的分層結構使得KWP2000診斷服務并不依賴于某種特定的網絡介質,其應用層可以移植到任何一種物理層和數據鏈路層協議之上。基于CAN總線的KWP2000順應了目前車載網絡發展的大趨勢,將逐步取代K線診斷協議,成為下一代車載診斷協議的主流之一。
MATLAB/Simulink/Stateflow為協議棧開發提供了方便直觀的圖形用戶接口和功能強大的仿真調試環境及代碼生成工具,為嵌入式開發開辟了一條高效快捷之路。Vector公司的CANoe和相關硬件板卡是一個功能強大的應用開發平臺,可針對基于K線和CAN總線的KWP2000進行ECU和診斷設備的上層協議開發、測試及仿真。
評論