KWP2000協議分析和基于CANoe的開發測試

KWP2000協議分析及基于CANoe的開發測試

摘 要：本文介紹了歐洲汽車領域廣泛采用的車載診斷協議KWP2000，針對KWP2000診斷服務在K線（ISO 14230）和CAN總線（ISO 15765）上的兩種實現方式，對協議的核心內容和發展歷史進行了較為深入的剖析和對比。本文還介紹了采用Matlab/Simulink/StateFlow進行協議開發的一般流程，以及該協議在Vector公司的CANoe軟硬件平臺上的應用實現和開過程。
關鍵詞：KWP2000，K線，CAN總線，開發，CANoe

1 前言

在汽車故障診斷領域，針對診斷設備和汽車ECU之間的數據交換，各大汽車公司幾乎都制訂了相關的標準和協議。其中，歐洲汽車領域廣泛使用的一種車載診斷協議標準是KWP2000（Keyword Protocol 2000），該協議實現了一套完整的車載診斷服務，并且滿足E-OBD（European On Board Diagnose）標準。KWP2000最初是基于K線的診斷協議，由于K線物理層和數據鏈路層在網絡管理和通訊速率上的局限性，使得K線無法滿足日趨復雜的車載診斷網絡的需求。而CAN網絡（Controller Area Network）由于其非破壞性的網絡仲裁機制、較高的通訊速率（可達1M bps）和靈活可靠的通訊方式，在車載網絡領域廣受青睞，越來越多的汽車制造商把CAN總線應用于汽車控制、診斷和通訊。近年來歐洲汽車領域廣泛采用了基于CAN總線的KWP2000，即ISO 15765協議，而基于K線的KWP2000物理層和數據鏈路層協議將逐步被淘汰。

在網絡協議開發和測試應用方面，美國MathWorks公司和德國Vector公司提供了功能強大的開發和測試工具，可分別用于協議棧源碼的開發和ECU測試。

2 基于K線的KWP2000協議

基于K線的KWP2000協議標準主要包括ISO/WD 14230-1～14230-4，各部分協議與OSI模型的對應關系如表1所示。

表1 KWP2000協議與OIS模型的對應關系

OSI模型	基于K線的KWP2000	基于CAN總線的KWP2000
應用層	ISO 14230-3	ISO 15765-3
表述層	N/A	N/A
會話層	N/A	N/A
傳輸層	N/A	N/A
網絡層	N/A	ISO 15765-2
數據鏈路層	ISO 14230-2	ISO 11898-1
物理層	ISO 14230-1，ISO9141-2	用戶選擇

ISO 14230-1規定了KWP2000協議的物理層規范（K線、L線），它在ISO 9141-2的基礎上把數據交換系統擴展到了24V電壓系統。ISO 14230-2規定了KWP2000的數據鏈路層協議，包括報文結構、初始化過程、通訊連接管理、定時參數和錯誤處理等內容。K線的報文包括報文頭、數據域和校驗和三部分，其中報文頭包含格式字節、目標地址（可選）、源地址（可選）和附加長度信息（可選），如表2所示。

表2 基于K線的KWP2000報文結構[3]

報文頭				數據域					校驗和
Fmt	Tgt1)	Src1)	Len1)	SId2)	. .	Data2)	. .		CS
最長4 字節				最長255 字節					1字節

1）可選字節，取決于格式字節Fmt的A1A0位
2）服務標識符（Service ID），數據域的第1個字節

在開始診斷服務之前，診斷設備必須對ECU進行初始化，通過ECU的響應獲取ECU的源地址、通訊波特率、支持的報文頭格式、定時參數等信息。ECU所支持的報文頭和定時參數信息包含在ECU返回的“關鍵字（Key Word）”中（這也是協議命名的由來）。關鍵字由兩個字節構成，如圖1所示，關鍵字的低字節中各位的含義如表3所示。

圖1 關鍵字格式[3]

表3 關鍵字低字節中各位的含義[3]

Bit	= 0	= 1
AL0	不支持格式字節中的數據長度信息	支持格式字節中的數據長度信息
AL1	不支持附加長度字節	支持附加長度字節
HB0	不支持一個字節的報文頭	支持一個字節的報文頭
HB1	不支持在報文頭中包含目標地址/源地址	支持在報文頭中包含目標地址/源地址
TP0*)	采用正常定時參數設置	采用擴展定時參數設置
TP1*)	采用擴展定時參數設置	采用正常定時參數設置

*) 只允許TP0,TP1 = 0,1 或者1,0

診斷設備可以采用兩種方式對ECU進行初始化——5Baud初始化和快速初始化，對于這兩種初始化的時序在數據鏈路層協議[3]中均有明確規定。完成初始化過程后，診斷設備和ECU方可進行應用層的診斷服務和響應。ISO 14230-3規定了應用層的服務規范，包括診斷管理功能組、數據傳輸功能組、診斷信息傳輸功能組、輸入/輸出控制功能組、遠程啟動ECU例程功能組、數據上載/下載功能組和擴展功能組。在診斷服務請求/響應過程中，診斷設備和ECU必須遵循圖2所示的時序和相關定時參數。對于初始化和診斷服務過程中出現的各種定時錯誤，在數據鏈路層和應用層協議里面都有相應的處理規范，診斷設備及ECU的應用程序都必須嚴格遵守。

圖2 K線診斷服務時序圖[3]

3 基于CAN總線的KWP2000協議

基于CAN總線的KWP2000協議實際上指的就是ISO/WD 15765-1～15765-4，該協議把KWP2000應用層的診斷服務移植到CAN總線上。數據鏈路層采用了ISO 11898-1協議，該協議是對CAN2.0B協議的進一步標準化和規范化；應用層采用了ISO 15765-3協議，該協議完全兼容基于K線的應用層協議14230-3，并加入了CAN總線診斷功能組；網絡層則采用ISO 15765-2協議，規定了網絡層協議數據單元（N_PDU，如表4所示）與底層CAN數據幀、以及上層KWP2000服務之間的映射關系，并且為長報文的多包數據傳輸過程提供了同步控制、順序控制、流控制和錯誤恢復功能。

表4 網絡層協議數據單元（N_PDU）格式[7]

地址信息	協議控制信息	數據域
N_AI1)	N_PCI2)	N_Data3)

1) 地址信息：包含源地址（SA）、目標地址（TA）、目標地址格式（TA_Type）和遠程地址（RA）
2) 協議控制信息：包含四種幀格式，見表5
3) 數據域：KWP2000服務標識符（Service ID） + 服務參數

應用層協議規定了四種服務數據結構，.Request、.Indication、.Response和.Confirm，分別用于診斷設備（Tester）的服務請求、ECU的服務指示、ECU的服務響應和Tester的服務確認。這些數據結構中包含了地址信息、服務請求ID和服務請求參數等內容?；贑AN總線的KWP2000診斷服務流程如圖3所示。

圖3 基于CAN總線的KWP2000診斷服務流程圖

從上面的服務流程可以看出，基于CAN總線的KWP2000協議支持多包數據傳輸，并且多包數據的管理和組織是在網絡層完成的，應用層不必關心數據的打包和解包過程。為實現這一功能，網絡層定義了四種PDU（以PCI類型進行區分，如表5所示）：
單幀（Single Frame，SF） － 數據域及PCI可在一個CAN數據幀中容納時，服務報文以單幀CAN報文進行發送。
第一幀（First Frame，FF） － 數據域及PCI不能在一個CAN數據幀中容納時，服務報文以多幀CAN報文進行發送，其中第一幀（FF）除傳送數據外，還包含了多包數據的長度信息。
連續幀（Consecutive Frame，CF） － 多包數據中除第一幀外的連續數據幀，除傳送數據外，還包含了多包數據的包序號。
流控制幀（Flow Control，FC） － 用于多包數據傳輸過程中的流控制，不包含數據，只包含流控制狀態、數據塊大小和最小間隔時間等流控制信息。

表5 15765協議網絡層四種PDU對應的PCI格式[7]

N_PDU 名稱	Byte #1		Byte #2	Byte #3
	Bit # 7-4	Bit # 3-0	N/A	N/A
單幀（SF）	N_PCItype=0	SF_DL1)	N/A	N/A
第一幀（FF）	N_PCItype=1	FF_DL2)		N/A
連續幀（CF）	N_PCItype=2	SN3)	N/A	N/A
流控制幀（FC）	N_PCItype=3	FS4)	BS5)	STmin6)

1) 單幀數據中數據域的字節長度，PCI的長度不包括在內。
2) 多包數據的數據域字節總長度。
3) 多包數據的數據包編號。
4) 流控制狀態信息。
5) 數據塊大小。
6) 多包數據傳輸的最小時間間隔。

多包數據的傳輸流程如圖4所示。發送節點首先發送“第一幀”，告知接收節點將要發送的數據的總長度；接收節點分配好資源、準備接收數據，然后以一幀“流控制幀”告知發送節點一次可以發送的數據包數目和時間間隔；發送節點接下來就根據接收節點的接收能力將編好序號的數據包依次發送過去。

圖4 多包數據傳輸流程圖

在數據傳送過程中，一個網絡層PDU被編排成一個CAN數據幀，它們之間的對應關系由尋址模式（Addressing mode）決定?；贗SO 15765協議規定了四種尋址模式：正常尋址模式（Normal）、正常固定尋址模式（Normal fixed）、擴展尋址模式（Extended）和用于遠程診斷的混合尋址模式（Mixed）。其中，正常固定尋址模式必須采用CAN擴展幀，并且SAE J1939為該尋址模式下的KWP2000診斷服務保留了兩個專用參數組編號（PGN）：其中PF=218（PF的具體定義請參考SAE J1939數據鏈路層協議）的參數組用于物理尋址（phy），PF=219的參數組用于功能尋址（fcn）。正常固定尋址模式的PDU與CAN數據幀之間的對應關系如表6所示。

表6 正常固定尋址模式下N_PDU與CAN數據幀之間的對應關系[7]

N_PDU類型

CAN 29位標識符

CAN數據域

28~26

25

24

23~16

15~8

7~0

1

2

3

4

5

6

7

8

單幀（SF）

011(bin)

0

0

218(dec)-phy 219(dec)-fcn

N_TA

N_SA

N_PCI

N_Data

第一幀（FF）

011(bin)

0

0

218(dec)-phy 219(dec)-fcn

N_TA

N_SA

N_PCI

N_Data

連續幀（CF）

011(bin)

0

0

218(dec)-phy 219(dec)-fcn

N_TA

N_SA

N_PCI

N_Data

流控制（FC）

011(bin)

0

0

218(dec)-phy 219(dec)-fcn

N_TA

N_SA

N_PCI

N/A

混合尋址模式與正常固定尋址模式類似，唯一的區別是CAN數據域的第一個字節用于填充遠程地址（RA），N_PCI和診斷服務數據的填充位置向后移動一個字節?；旌蠈ぶ纺Ｊ接糜诳缭骄W段進行遠程診斷，遠程診斷的機制如圖5所示。圖中CAN1和CAN2兩個不同的子網通過網橋相連，網橋在子網1中的源地址為200，在子網2中的源地址為10，位于子網1中的診斷設備（源地址為241）可通過網橋對子網2中的ECU（源地址為62）進行診斷。

圖5 跨越網段的遠程診斷

4 兩種協議的簡單比較

從前面基于K線和基于CAN總線的KWP2000協議可以看出，兩種協議在物理層、數據鏈路層及網絡層（15765）上存在以下主要差別，這也是K線被CAN總線取而代之的主要原因所在：

• K線通訊速率較低，最大波特率僅為10400bps；CAN總線通訊速率較高，最大波特率可達1Mbps。
• K線采用單端信號傳輸，抗干擾能力較弱，可靠性較差；CAN總線采用差分信號傳輸，抗干擾能力強，信號傳輸的可靠性高。
• K線診斷在啟動應用層診斷服務之前必須對ECU進行初始化建立連接，并且初始化過程比較復雜；而基于CAN總線的診斷設備不需要對ECU進行初始化即可進行診斷服務。
• K線診斷應用程序開發者必須親自管理數據傳輸過程中的字節間定時，并處理底層通訊錯誤；CAN數據幀以整幀報文的形式進行發送，應用程序開發者不必管理字節間定時，并且CAN總線物理層和數據鏈路層具備完善的錯誤檢測和錯誤恢復機制，應用程序不必監視和處理底層通訊錯誤。
• 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診斷服務并不依賴于某種特定的網絡介質，其應用層可以移植到任何一種物理層和數據鏈路層協議之上?；贑AN總線的KWP2000順應了目前車載網絡發展的大趨勢，將逐步取代K線診斷協議，成為下一代車載診斷協議的主流之一。

MATLAB/Simulink/Stateflow為協議棧開發提供了方便直觀的圖形用戶接口和功能強大的仿真調試環境及代碼生成工具，為嵌入式開發開辟了一條高效快捷之路。Vector公司的CANoe和相關硬件板卡是一個功能強大的應用開發平臺，可針對基于K線和CAN總線的KWP2000進行ECU和診斷設備的上層協議開發、測試及仿真。