KWP2000診斷通訊協(xié)議

1、基于K線的KWP2000協(xié)議標準主要包括ISO/WD 14230-114230-4，各部分協(xié)議與OSI模型的對應關系如表1所示。表1 KWP2000協(xié)議與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規(guī)定了KWP2000協(xié)議的物理層規(guī)范（K線、

2、L線），它在ISO 9141-2的基礎上把數據交換系統(tǒng)擴展到了24V電壓系統(tǒng)。ISO 14230-2規(guī)定了KWP2000的數據鏈路層協(xié)議，包括報文結構、初始化過程、通訊連接管理、定時參數和錯誤處理等內容。K線的報文包括報文頭、數據 域和校驗和三部分，其中報文頭包含格式字節(jié)、目標地址（可選）、源地址（可選）和附加長度信息（可選），如表2所示。表2 基于K線的KWP2000報文結構3報文頭 數據域 校驗和 Fmt Tgt1) Src1) Len1) SId2) . . Data2) . . CS 最長4 字節(jié) 最長255 字節(jié) 1字節(jié) 1）可選字節(jié)，取決于格式字節(jié)Fmt的A1A0位2）服務標識符（

3、Service ID），數據域的第1個字節(jié)KWP2000（Keyword Protocol 2000）是歐洲汽車領域廣泛使用的一種車載診斷協(xié)議標準，該協(xié)議實現了一套完整的車載診斷服務，并且滿足E-OBD（European On Board Diagnose）標準。KWP2000協(xié)議僅對其中三個子層進行了定義說明，即：應用層(第七層)、數據鏈路層(第二層)和物理層（第一層)。物理層：這部分描述了基于IS09141用以實現診斷服務的物理層，用于配置硬件系統(tǒng)，指導接口電路的設計，同時將在IS09141-2中描述的物理層擴展成可以滿足提供12V或24V電壓的車輛的條款。數據鏈路層：這部分定義了數據的傳

4、送格式，描述了診斷服務的通用要求，允許1個診斷儀控制在1個隨車ECU(例如電子燃油噴射、自動變速箱及防抱死系統(tǒng)等)中的診斷功能。這些隨車ECU嵌于車輛中，通過串行數據鏈路相連接。應用層：這部分包含如下規(guī)范:服務標識符的字節(jié)編碼及其十六進制數值；診斷服務請求與響應參數的字節(jié)編碼；標準參數的十六進制數值。根據IS014230的規(guī)定，KWP2000通信消息基本格式如圖1所示。一條消息結構包括頭部(header)、數據字節(jié)(data-byte)、校驗和(checksum)等三部分。圖1 KWP2000的報文格式 Fmt格式字節(jié)(Format byte)Tgt目標地址字節(jié)(Target address

5、byte)Src源地址字節(jié)(Source address byte)Len長度字節(jié)(Length byte)Sid服務標志符字節(jié)(Sevice Identification byte)，分請求服務和響應服務兩類CS校驗和字節(jié)(Checksum byte)上標1表示可選，由格式字節(jié)(Fmt)決定上標2表明服務標識(Sid)是數據段的一部分(Data)在 開始診斷服務之前，診斷設備必須對ECU(發(fā)動機engine control unit)進行初始化，通過ECU的響應獲取ECU的源地址、通訊波特率、支持的報文格式、定時參數等信息。ECU所支持的 報文和定時參數信息包含在ECU返回的“關鍵字（Key

6、 Word）”中（這也是協(xié)議命名的由來）。關鍵字由兩個字節(jié)構成，如圖2所示，關鍵字的低字節(jié)中各位的含義如表1所示。圖2 關鍵字格式 表1 關鍵字低字節(jié)中各位的含義 測試器（診斷設備）可以采用兩種方式對ECU進行初始化，即5Baud初始化和快速初始化。對于這兩種初始化的時序在數據鏈路層協(xié)議中均有明確規(guī)定。完成初始化過程后，測試器和ECU方可進行應用層的診斷服務和響應。IS014230-3規(guī)定了應用層的服務規(guī)范，包括診斷管理功能組、數據傳輸功能組、診斷信息傳輸功能組、輸人輸出控制功能組、遠程啟動ECU例程功能組、數據上載下載功能組和擴展功能組。KWP2000 最初是基于K線的診斷協(xié)議。由于K線物理

7、層和數據鏈路層在網絡管理和通訊速率上的局限性，使得K線無法滿足日趨復雜的車載診斷網絡的需求。而 CAN（Controller Area Network）網絡由于其非破壞性的網絡仲裁機制、較高的通訊速率（可達1Mbps）和靈活可靠的通訊方式，在車載網絡領域廣受青睞。因此，近年來歐洲 汽車領域廣泛采用了基于CAN總線的KWP2000，即ISO15765協(xié)議，而基于K線的KWP2000物理層和數據鏈路層協(xié)議將逐步被淘汰。KWP2000協(xié)議分析和基于CANoe的開發(fā)測試摘 要：本文介紹了歐洲汽車領域廣泛采用的車載診斷協(xié)議KWP2000，針對KWP2000診斷服務在K線（ISO 14230）和CAN總線

8、（ISO 15765）上的兩種實現方式，對協(xié)議的核心內容和發(fā)展歷史進行了較為深入的剖析和對比。本文還介紹了采用Matlab/Simulink /StateFlow進行協(xié)議開發(fā)的一般流程，以及該協(xié)議在Vector公司的CANoe軟硬件平臺上的應用實現和開過程。關鍵詞：KWP2000，K線，CAN總線，開發(fā)，CANoe1 前言在汽車故障診斷領域，針對診斷設備和汽車ECU之間的數據交換，各大汽車公司幾乎都制訂了相關的標準和協(xié)議。其中，歐洲 汽車領域廣泛使用的一種車載診斷協(xié)議標準是KWP2000（Keyword Protocol 2000），該協(xié)議實現了一套完整的車載診斷服務，并且滿足E-OBD（Eu

9、ropean On Board Diagnose）標準。KWP2000最初是基于K線的診斷協(xié)議，由于K線物理層和數據鏈路層在網絡管理和通訊速率上的局限性，使得K線無法滿足日趨復 雜的車載診斷網絡的需求。而CAN網絡（Controller Area Network）由于其非破壞性的網絡仲裁機制、較高的通訊速率（可達1M bps）和靈活可靠的通訊方式，在車載網絡領域廣受青睞，越來越多的汽車制造商把CAN總線應用于汽車控制、診斷和通訊。近年來歐洲汽車領域廣泛采用了基 于CAN總線的KWP2000，即ISO 15765協(xié)議，而基于K線的KWP2000物理層和數據鏈路層協(xié)議將逐步被淘汰。在網絡協(xié)議開發(fā)和

10、測試應用方面，美國MathWorks公司和德國Vector公司提供了功能強大的開發(fā)和測試工具，可分別用于協(xié)議棧源碼的開發(fā)和ECU測試。2 基于K線的KWP2000協(xié)議基于K線的KWP2000協(xié)議標準主要包括ISO/WD 14230-114230-4，各部分協(xié)議與OSI模型的對應關系如表1所示。表1 KWP2000協(xié)議與OIS模型的對應關系OSI模型基于K線的KWP2000基于CAN總線的KWP2000應用層ISO 14230-3ISO 15765-3表述層N/AN/A會話層N/AN/A傳輸層N/AN/A網絡層N/AISO 15765-2數據鏈路層ISO 14230-2ISO 11898-1物理

11、層ISO 14230-1，ISO9141-2用戶選擇 ISO 14230-1規(guī)定了KWP2000協(xié)議的物理層規(guī)范（K線、L線），它在ISO 9141-2的基礎上把數據交換系統(tǒng)擴展到了24V電壓系統(tǒng)。ISO 14230-2規(guī)定了KWP2000的數據鏈路層協(xié)議，包括報文結構、初始化過程、通訊連接管理、定時參數和錯誤處理等內容。K線的報文包括報文頭、數據 域和校驗和三部分，其中報文頭包含格式字節(jié)、目標地址（可選）、源地址（可選）和附加長度信息（可選），如表2所示。表2 基于K線的KWP2000報文結構3報文頭數據域校驗和FmtTgt1)Src1)Len1)SId2). .Data2). .CS最長4

12、 字節(jié)最長255 字節(jié)1字節(jié)1）可選字節(jié)，取決于格式字節(jié)Fmt的A1A0位2）服務標識符（Service ID），數據域的第1個字節(jié) 在開始診斷服務之前，診斷設備必須對ECU進行初始化，通過ECU的響應獲取ECU的源地址、通訊波特率、支持的報文頭格式、定時參數等信息。 ECU所支持的報文頭和定時參數信息包含在ECU返回的“關鍵字（Key Word）”中（這也是協(xié)議命名的由來）。關鍵字由兩個字節(jié)構成，如圖1所示，關鍵字的低字節(jié)中各位的含義如表3所示。圖1 關鍵字格式3表3 關鍵字低字節(jié)中各位的含義3Bit= 0= 1AL0不支持格式字節(jié)中的數據長度信息支持格式字節(jié)中的數據長度信息AL1不支持附加

13、長度字節(jié)支持附加長度字節(jié)HB0不支持一個字節(jié)的報文頭支持一個字節(jié)的報文頭HB1不支持在報文頭中包含目標地址/源地址支持在報文頭中包含目標地址/源地址TP0*)采用正常定時參數設置采用擴展定時參數設置TP1*)采用擴展定時參數設置采用正常定時參數設置 *) 只允許TP0,TP1 = 0,1 或者1,0診斷設備可以采用兩種方式對ECU進行初始化5Baud初始化和快速初始化，對于這兩種初始化的時序在數據鏈路層協(xié)議3中均有明確規(guī)定。完 成初始化過程后，診斷設備和ECU方可進行應用層的診斷服務和響應。ISO 14230-3規(guī)定了應用層的服務規(guī)范，包括診斷管理功能組、數據傳輸功能組、診斷信息傳輸功能組、輸

14、入/輸出控制功能組、遠程啟動ECU例程功能組、數 據上載/下載功能組和擴展功能組。在診斷服務請求/響應過程中，診斷設備和ECU必須遵循圖2所示的時序和相關定時參數。對于初始化和診斷服務過程中出現 的各種定時錯誤，在數據鏈路層和應用層協(xié)議里面都有相應的處理規(guī)范，診斷設備及ECU的應用程序都必須嚴格遵守。圖2 K線診斷服務時序圖33 基于CAN總線的KWP2000協(xié)議基于CAN總線的KWP2000協(xié)議實際上指的就是ISO/WD 15765-115765-4，該協(xié)議把KWP2000應用層的診斷服務移植到CAN總線上。數據鏈路層采用了ISO 11898-1協(xié)議，該協(xié)議是對CAN2.0B協(xié)議的進一步標準

15、化和規(guī)范化；應用層采用了ISO 15765-3協(xié)議，該協(xié)議完全兼容基于K線的應用層協(xié)議14230-3，并加入了CAN總線診斷功能組；網絡層則采用ISO 15765-2協(xié)議，規(guī)定了網絡層協(xié)議數據單元（N_PDU，如表4所示）與底層CAN數據幀、以及上層KWP2000服務之間的映射關系，并且為長報文 的多包數據傳輸過程提供了同步控制、順序控制、流控制和錯誤恢復功能。表4 網絡層協(xié)議數據單元（N_PDU）格式7地址信息協(xié)議控制信息數據域N_AI1)N_PCI2)N_Data3)1) 地址信息：包含源地址（SA）、目標地址（TA）、目標地址格式（TA_Type）和遠程地址（RA）2) 協(xié)議控制信息：包

16、含四種幀格式，見表53) 數據域：KWP2000服務標識符（Service ID） + 服務參數 應用層協(xié)議規(guī)定了四種服務數據結 構，.Request、.Indication、.Response 和.Confirm，分別用于診斷設備（Tester）的服務請求、ECU的服務指示、ECU的服務響應和 Tester的服務確認。這些數據結構中包含了地址信息、服務請求ID和服務請求參數等內容?；贑AN總線的KWP2000診斷服務流程如圖3所示。圖3 基于CAN總線的KWP2000診斷服務流程圖從上面的服務流程可以看出，基于CAN總線的KWP2000協(xié)議支持多包數據傳輸，并且多包數據的管理和組織是在網絡

17、層完成的，應用層不必關心數據的打包和解包過程。為實現這一功能，網絡層定義了四種PDU（以PCI類型進行區(qū)分，如表5所示）：單幀（Single Frame，SF） 數據域及PCI可在一個CAN數據幀中容納時，服務報文以單幀CAN報文進行發(fā)送。第一幀（First Frame，FF） 數據域及PCI不能在一個CAN數據幀中容納時，服務報文以多幀CAN報文進行發(fā)送，其中第一幀（FF）除傳送數據外，還包含了多包數據的長度信息。連續(xù)幀（Consecutive Frame，CF） 多包數據中除第一幀外的連續(xù)數據幀，除傳送數據外，還包含了多包數據的包序號。流控制幀（Flow Control，FC） 用于多包數

18、據傳輸過程中的流控制，不包含數據，只包含流控制狀態(tài)、數據塊大小和最小間隔時間等流控制信息。表5 15765協(xié)議網絡層四種PDU對應的PCI格式7N_PDU 名稱Byte #1Byte #2Byte #3Bit # 7-4Bit # 3-0N/AN/A單幀（SF）N_PCItype=0SF_DL1)N/AN/A第一幀（FF）N_PCItype=1FF_DL2)N/A連續(xù)幀（CF）N_PCItype=2SN3)N/AN/A流控制幀（FC）N_PCItype=3FS4)BS5)STmin6)1) 單幀數據中數據域的字節(jié)長度，PCI的長度不包括在內。2) 多包數據的數據域字節(jié)總長度。3) 多包數據的數

19、據包編號。4) 流控制狀態(tài)信息。5) 數據塊大小。6) 多包數據傳輸的最小時間間隔。 多包數據的傳輸流程如圖4所示。發(fā)送節(jié)點首先發(fā)送“第一幀”，告知接收節(jié)點將要發(fā)送的數據的總長度；接收節(jié)點分配好資源、準備接收數據，然后以一幀 “流控制幀”告知發(fā)送節(jié)點一次可以發(fā)送的數據包數目和時間間隔；發(fā)送節(jié)點接下來就根據接收節(jié)點的接收能力將編好序號的數據包依次發(fā)送過去。圖4 多包數據傳輸流程圖在數據傳送過程中，一個網絡層PDU被編排成一個CAN數據幀，它們之間的對應關系由尋址模式（Addressing mode）決定。基于ISO 15765協(xié)議規(guī)定了四種尋址模式：正常尋址模式（Normal）、正常固定尋址模式

20、（Normal fixed）、擴展尋址模式（Extended）和用于遠程診斷的混合尋址模式（Mixed）。其中，正常固定尋址模式必須采用CAN擴展幀，并且SAE J1939為該尋址模式下的KWP2000診斷服務保留了兩個專用參數組編號（PGN）：其中PF=218（PF的具體定義請參考SAE J1939數據鏈路層協(xié)議）的參數組用于物理尋址（phy），PF=219的參數組用于功能尋址（fcn）。正常固定尋址模式的PDU與CAN數據幀之間 的對應關系如表6所示。表6 正常固定尋址模式下N_PDU與CAN數據幀之間的對應關系7N_PDU類型CAN 29位標識符CAN數據域282625242316158

21、7012345678單幀（SF）011(bin)00218(dec)-phy219(dec)-fcnN_TAN_SAN_PCIN_Data第一幀（FF）011(bin)00218(dec)-phy219(dec)-fcnN_TAN_SAN_PCIN_Data連續(xù)幀（CF）011(bin)00218(dec)-phy219(dec)-fcnN_TAN_SAN_PCIN_Data流控制（FC）011(bin)00218(dec)-phy219(dec)-fcnN_TAN_SAN_PCIN/A 混合尋址模式與正常固定尋址模式類似，唯一的區(qū)別是CAN數據域的第一個字節(jié)用于填充遠程地址（RA），N_PC

22、I和診 斷服務數據的填充位置向后移動一個字節(jié)。混合尋址模式用于跨越網段進行遠程診斷，遠程診斷的機制如圖5所示。圖中CAN1和CAN2兩個不同的子網通過網 橋相連，網橋在子網1中的源地址為200，在子網2中的源地址為10，位于子網1中的診斷設備（源地址為241）可通過網橋對子網2中的ECU（源地址為 62）進行診斷。圖5 跨越網段的遠程診斷4 兩種協(xié)議的簡單比較從前面基于K線和基于CAN總線的KWP2000協(xié)議可以看出，兩種協(xié)議在物理層、數據鏈路層及網絡層（15765）上存在以下主要差別，這也是K線被CAN總線取而代之的主要原因所在：K線通訊速率較低，最大波特率僅為10400bps；CAN總線通

23、訊速率較高，最大波特率可達1Mbps。K線采用單端信號傳輸，抗干擾能力較弱，可靠性較差；CAN總線采用差分信號傳輸，抗干擾能力強，信號傳輸的可靠性高。K線診斷在啟動應用層診斷服務之前必須對ECU進行初始化建立連接，并且初始化過程比較復雜；而基于CAN總線的診斷設備不需要對ECU進行初始化即可進行診斷服務。K線診斷應用程序開發(fā)者必須親自管理數據傳輸過程中的字節(jié)間定時，并處 理底層通訊錯誤；CAN數據幀以整幀報文的形式進行發(fā)送，應用程序開發(fā)者不必管理字節(jié)間定時，并且CAN總線物理層和數據鏈路層具備完善的錯誤檢測和錯誤 恢復機制，應用程序不必監(jiān)視和處理底層通訊錯誤。K線網絡結構單一，網絡管理功能很弱

24、；而利用CAN總線可構建復雜的網絡結構，可跨越網段進行遠程診斷。K線網絡采用破壞性的仲裁機制，當診斷設備采用功能尋址與多個ECU進 行通訊時，為避免總線沖突，ECU開發(fā)者必須采取措施保證多個ECU順序訪問總線；而CAN網絡采用非破壞性的仲裁機制，并且仲裁過程由數據鏈路層完成， 當診斷設備采用功能尋址與多個ECU進行通訊時，ECU開發(fā)者不必考慮總線訪問沖突問題。K線服務報文最大字節(jié)長度僅為255，無法滿足更長報文的傳輸要求，并 且在長報文的傳輸過程中用戶必須自己采取措施進行連接管理，可靠性和兼容性較差；而CAN總線診斷服務報文最大字節(jié)長度可達4096（12位），對于長報 文的傳輸，網絡層協(xié)議還具

25、備標準化和規(guī)范化的同步控制、順序控制、流控制和錯誤恢復等功能，具備很高的可靠性、兼容性。5 KWP2000協(xié)議棧的開發(fā)及測試從前面的協(xié)議分析可以看出，無論是基于K線還是CAN總線的KWP2000協(xié)議，都是邏輯非常復雜的系 統(tǒng)，并且具有嚴格的定時和錯誤處理規(guī)范。如果采用純手工的方式來進行KWP2000協(xié)議棧的開發(fā)，不僅要耗費大量的時間和人力，其通用性、完備性、可靠性 和可維護性都很難保證。而MATLAB/Simulink/StateFlow不僅具備方便快捷的上層實時仿真環(huán)境，還集成了高效的嵌入式代碼自動生成工 具，為協(xié)議棧的開發(fā)和維護提供了強大的支持平臺。此外，由德國Vector公司的CANoe

26、軟件和相關硬件板卡組成的應用開發(fā)平臺，可用于汽車網絡 （CAN，Lin等）的上層協(xié)議開發(fā)和系統(tǒng)測試，該平臺同時支持基于K線和CAN總線的KWP2000診斷協(xié)議，可作為ECU和診斷設備的測試標準。圖6是協(xié)議源碼開發(fā)過程示意圖。首先在MATLAB/Simulink/StateFlow中遵照協(xié)議 標準進行KWP2000協(xié)議棧開發(fā)，在仿真調試環(huán)境下實現通訊邏輯、定時控制和錯誤處理，待系統(tǒng)完善后利用StateFlow嵌入式代碼生成工具自動生成 協(xié)議棧C代碼，并與目標系統(tǒng)的底層驅動進行集成，然后植入目標系統(tǒng)形成應用程序，最后再利用CANoe作為標準進行系統(tǒng)集成測試。圖6 KWP2000協(xié)議棧開發(fā)及測試流程

27、在MATLAB/Simulink/StateFlow中進行協(xié)議棧仿真開發(fā)是協(xié)議棧開發(fā)過程中的關鍵 環(huán)節(jié)，在這一過程中必須嚴格遵照協(xié)議標準來實現通訊邏輯，往往需要經過多次“設計仿真修改”循環(huán)才能使系統(tǒng)最終趨于完善。MATLAB的圖形界面提供 了方便快捷的仿真輸入/輸出接口，可大幅度加快開發(fā)進度。協(xié)議棧開發(fā)完成后可利用CANoe作為標準進行系統(tǒng)集成測試，CANoe的KWP2000協(xié)議測試環(huán)境如圖7所示。圖7 CANoe的KWP2000測試環(huán)境示意圖CANoe中的KWP2000實際指的是基于CAN總線的KWP2000， 即15765協(xié)議。由于CANoe默認的硬件板卡是CAN卡，因此在建立仿真程序時，

28、只需將ECU的網絡模塊設置為kwp2000.dll即可進行CAN 總線的KWP2000服務測試。kwp2000.dll中包含15765應用層協(xié)議中規(guī)定的服務請求、服務指示、服務響應和服務確認接口函數，用戶調用這 些函數即可完成Tester端和ECU端的KWP2000診斷服務。此外，該模塊中的功能函數還可對ECU的源地址、目標地址、尋址模式等參數進行動態(tài)設 置。需要注意的是，kwp2000.dll目前只提供了部分KWP2000服務的接口函數，如果用戶需要進行其它的KWP2000服務測試，必須根據 KWP2000應用層協(xié)議構造服務報文數據，然后調用該模塊中的KWP_DataReq（）和KWP_Ge

29、tRxData（）函數進行報文的發(fā)送和接收。進行基于K線的KWP2000服務測試時，需要將KLineCPL.dll模塊加入CANoe仿真環(huán)境，并使用一個代理節(jié)點來實現CAN網絡和K線之間的報文轉發(fā)。此時CANoe使用計算機的串口，并通過一個串口/K線轉換器與實際的ECU相連，如圖8所示。圖8 CANoe中基于K線的KWP2000測試連接示意圖6 結束語KWP2000是一套非常完善的車載故障診斷協(xié)議標準，協(xié)議的分層結 構使得KWP2000診斷服務并不依賴于某種特定的網絡介質，其應用層可以移植到任何一種物理層和數據鏈路層協(xié)議之上。基于CAN總線的KWP2000順 應了目前車載網絡發(fā)展的大趨勢，將逐

30、步取代K線診斷協(xié)議，成為下一代車載診斷協(xié)議的主流之一。MATLAB/Simulink/Stateflow為協(xié)議棧開發(fā)提供了方便直觀的圖形用戶接口和功能 強大的仿真調試環(huán)境及代碼生成工具，為嵌入式開發(fā)開辟了一條高效快捷之路。Vector公司的CANoe和相關硬件板卡是一個功能強大的應用開發(fā)平臺，可 針對基于K線和CAN總線的KWP2000進行ECU和診斷設備的上層協(xié)議開發(fā)、測試及仿真。摘 要：結合國外汽車廠商廣泛采用的車載診斷協(xié)議KWP 2000，對LIN總線下的ECU在線編程進行研究和方法設計，并對具體的硬件設計與軟件實現進行了分析與闡述。 關鍵詞：KWP2000；ECU在線編程；LIN總線；

31、MC9S08AW60 HYPERLINK / 1. 引言在汽車故障診斷領域，針對診斷設備和汽車ECU之間的數據交換，各大汽車公司幾乎都制訂了相關的標準和協(xié)議。其中，國外 汽車廠商，包括大眾、通用、奔馳、戴姆勒-克萊斯勒、JEEP、三菱、道奇等廣泛使用的一種車載診斷協(xié)議標準是KWP2000(Key Word Protocol 2000)。該協(xié)議實現了較為完整的車載診斷服務，并且滿足OBDII診斷要求。LIN總線（Local Interconnection Network）是一種單線車載網絡，采用類似于標準串口的通訊格式，由于其協(xié)議簡單，通信可靠性好，實現成本低，近年來得到了迅速的發(fā)展。2基于KW

32、P2000的ECU在線編程研究ECU的在線編程指ECU處于工作狀態(tài)時通過網絡通信更新其中的應用程序，從而實現改善控制器性能、提高安全性、改善排放、改善燃油經濟性、提高用戶滿意度等目的，在設計和試制階段，該功能的實現為程序的更新提供極大的方便。與傳統(tǒng)的一對一的在線編程方式不同，由于KWP2000在網絡上傳輸，必須考慮其它控制器的反應，必須對目標控制器作出正確的識別，必須保證數據傳輸的完整性等等。基于KWP2000協(xié)議ECU在線編程包括以下步驟：1) 切換到擴展診斷狀態(tài)：該步驟用于將控制器切換到一個特別的診斷狀態(tài)，使得系統(tǒng)可以響應擴展診斷命令。2) 識別ECU：該步驟用于上位機識別特定ECU及相應

33、軟硬件和數據的版本信息，上位機由此可決定能否執(zhí)行FLASH在線編程。3) 關閉網絡上所有控制器的故障碼識別和存儲功能：該步驟禁止控制器在接下來的編程期間檢測和記錄故障。4) 關閉常規(guī)信息傳遞：該步驟禁止所有控制器的常規(guī)信息傳送，使網絡上只有診斷和網絡管理消息收發(fā)，為在線編程讓出足夠的總線帶寬。5) 啟動在線編程模式：將控制器切換到代碼保護區(qū)運行Bootloader程序，該模式關閉了中斷，因此具有較快的響應速度。 HYPERLINK / 6) 開啟安全限制：允許在線編程過程中的安全功能，開啟這些安全功能后使得ECU可以執(zhí)行特定的過程。7) 下載軟件鎖：上位機將關鍵代碼下載到ECU，執(zhí)行這些代碼可

34、完成FLASH的擦除和重寫。8) 擦除FLASH：ECU執(zhí)行上一步驟收到的關鍵代碼，擦除完成后，ECU將清除該段關鍵代碼。9) 下載數據：該過程下載新的程序到ECU的FLASH。 HYPERLINK / 10) 校驗數據：在此過程中ECU檢查下載的數據，如果判斷為正確，則在FLASH中寫入識別碼和代碼校驗數據。11) 復位ECU：ECU執(zhí)行復位，恢復到正常工作狀態(tài)。12) 開啟常規(guī)信息傳遞：重新開啟網絡上其它控制器上的常規(guī)信息傳遞。13) 開啟故障碼識別和存儲功能：重新開啟網絡上其它控制器的故障碼識別和存儲功能。3基于KWP2000的ECU在線編程設計與實現3.1硬件設計系統(tǒng)CPU采用Free

35、scale公司的MC9S08AW60，該芯片內部集成了標準串口控制器，LIN總線驅動器采用了PHILIPS公司的TJA1020，驅動部分電路如圖1，由硬件部分實現了通信協(xié)議的物理層和數據鏈路層。圖1. LIN總線驅動部分電路圖3.2軟件設計與實現3.2.1 內存地址分配MC9S08AW60的存儲空間分配如圖2：圖2. 存儲空間分配示意圖以下代碼實現了上述的芯片配置。/*設代碼保護區(qū)為 0 xfc000 xffff */const volatile NVPROTSTR _NVPROT0 x0000ffbd = 0 xfa;/*關閉芯片后門鎖，打開中斷向量表重映射，新的中斷向量表地址為0 xfbc

36、00 xfbff */const volatile NVOPTSTR _NVOPT0 x0000ffbf = 0 x3e; HYPERLINK / 3.2.2 軟件實現ECU程序的狀態(tài)切換流程圖如圖3：圖3. 程序狀態(tài)切換流程圖說明：1）根據上位機的KWP2000指令，程序在以下5種工作狀態(tài)中切換，如表1：表1 程序工作狀態(tài)表2）通信中用到以下KWP2000命令，如表2:命令對應代碼切換到擴展診斷過程命令10 92查詢目標ECU識別碼命令查詢ECU ID1a 87查詢應用代碼ID1a 9c查詢Bootloader程序ID1a 9e查詢數據區(qū)ID1a 9d禁止故障碼記錄命令85 02 ff 00

37、 01 01禁止常規(guī)通信數據收發(fā)命令28 02開啟安全限制命令請求密碼種子27 05回復安全密碼27 06切換到編程模式命令10 85數據傳送命令請求下載數據34 xx數據傳送36 xx請求結束下載37 xx 數據校驗31 e1 01開啟常規(guī)通信數據收發(fā)命令29 02開啟故障碼記錄命令85 02 ff 00 02復位命令11 01表2: 命令說明表3）由于芯片結構的原因，程序在寫flash時必須跳到RAM中執(zhí)行，以下代碼定義了用于存儲關鍵代碼的RAM空間和指向該空間的函數CriticalProcess()。volatile unsigned char criticalProcess100; /* 定義RAM空間用于存儲關鍵代碼 */#define CriticalProcess (void(*)(void)( criticalProcess) /*定義函數指向RAM*/在線編程過程中程序將接收到的目標代碼放入RAM中，接收完成后調用Crit