|
引言： 隨著汽車電子控制單元功能的增加及升級換代的需要，診斷功能已經成為ECU不可或缺的重要組成部分，因此，深入研究診斷協議及其實現非常必要。基于K線的ISO14230和基于CAN總線的ISO15765是業內廣泛采用的兩種診斷標準【1】，K線是ISO9141定義的診斷通信總線，ISO14230在ISO9141的基礎上將K線電壓擴展到24V，并擴展了診斷服務。相比較于CAN總線，K線診斷既能滿足要求，又能節約成本，在國產車上得到大規模應用。不同于CAN總線有專門的協議驅動器，用戶直接進行應用程序的編寫而不用管理底層的通信，K線沒有專門的協議驅動器，一般要在SCI模塊的基礎上用軟件實現其底層通信管理，筆者為某國產車設計了一款帶K線診斷功能的車身控制模塊，結合ISO14230規范，首先分析K線診斷協議驅動器的功能，然后介紹協議驅動器的關鍵設計技術，最后用CANoe進行測試。 1 協議驅動器功能 ISO14230-1定義了K線物理層協議，ISO14230-2定義了數據鏈路層協議，ISO14230-3定義了應用層協議【2】，其與OSI模型對應關系如表1所示。
表1 ISO14230與OSI模型的對應關系 物理層定義了邏輯位與物理電平的對應關系，同時定義了信號位的上升時間和下降時間，數據鏈路層協議定義了K線數據格式、診斷報文格式、定時參數及通信錯誤判定及處理機制，應用層協議定義了基于請求/響應的診斷過程及各項診斷服務。做為待診斷ECU節點，K線協議驅動器實現的主要功能包括： 1、診斷報文的封裝和發送、接收和解析，根據報文格式填充/提取SID和數據； 2、通過初始化過程建立與診斷儀之間的診斷通信； 3、保持正確的幀間定時、字節間定時，檢測診斷儀報文的定時錯誤及其它通信錯誤； 4、根據診斷儀的診斷請求和ECU當前狀態返回相應的診斷響應，管理診斷會話； 下面結合數據鏈路層的協議分析及其數據結構、驅動程序的設計介紹下K線診斷協議驅動器的原理及實現。 2 協議驅動器設計 K線基于異步串行通信接口，在底層傳輸上采用8N1格式的SCI串行數據鏈路格式：8個數據位+1個停止位、無奇偶校驗，由于K線在物理層上是單根線，在發送時也會觸發接收中斷，所以K線報文的發送和接收解析統一在SCI接收中斷處理函數中以狀態機的形式實現【3】。下面從報文收發及解析、初始化、定時管理三個方面介紹下數據鏈路層的實現。 2.1 報文收發及解析 K線診斷報文結構如表2所示：
表2 K線診斷報文結構 K線報文由報文頭、數據字段及校驗和組成。報文頭包含格式字節Fmt、目標地址Tgt、源地址Src和可選附加長度信息Len，Fmt指定目標地址的形式（物理地址/功能地址），當報文頭中不包含可選Len字段時指定數據字段的長度；數據字段包括服務標識符Sid和數據Data，其長度由Fmt和Len決定；CS為單字節校驗和。設計報文結構體如下： typedef struct { k_state state; uchar fmt; uchar tgt_addr; uchar src_addr; uchar datalen; uchar sid; uchar *data; uchar checksum; uchar msgdatalen; uchar done; }k_msg; typedef enum{ k_FMT=0, k_TGTADDR, k_SRCADDR, k_DATALEN, k_SID, k_DATA, k_CS }k_state; 成員變量state表示當前K線通信數據是報文中的哪個組成部分，msgdatalen用于數據字段字節數的統計，done表示該報文是否發送或接收完成，其它成員變量與報文結構組成部分一一對應。 void k_ifc_rx(void) { k_u8 ch,SciSr1; SciSr1=Kline_periph[SCISR1]; ch=Kline_periph[SCIDRL]; TimerStop(k_TP4); switch(k_curmsg.state){ case k_FMT: if(k_REP==k_drvhandle.mode){ if(ch==k_curmsg.fmt){ k_curmsg.state=k_TGTADDR; k_SendChar(k_curmsg.tgt_addr); } }else{ k_curmsg.state=k_TGTADDR; k_curmsg.fmt=ch; } break; case k_TGTADDR: ... break; case k_SRCADDR: ... break; case k_DATALEN: if(k_REP==k_drvhandle.mode){ if(ch==k_curmsg.datalen){ k_curmsg.msgdatalen=0; k_curmsg.state=k_SID; k_SendChar(k_curmsg.sid); } }else{ k_curmsg.msgdatalen=0; k_curmsg.datalen=ch; free(k_curmsg.data); k_curmsg.data=malloc(k_curmsg.datalen); k_curmsg.state=k_SID; } break; case k_SID: if(k_REP==k_drvhandle.mode){ if(ch==k_curmsg.sid){ k_curmsg.msgdatalen++; if(k_curmsg.msgdatalen==k_curmsg.datalen){ k_curmsg.state=k_CS; k_SendChar(k_curmsg.checksu); }else{ k_curmsg.state=k_DATA; k_SendChar(k_curmsg.data[0]); } } }else{ k_curmsg.sid=ch; k_curmsg.msgdatalen++; if(k_curmsg.datalen==k_curmsg.msgdatalen){ k_curmsg.state=k_CS; }else{ k_curmsg.state=k_DATA; } } break; case k_DATA: ... break; case k_CS: k_curmsg.state=k_FMT; if(k_REP==k_drvhandle.mode){ if(ch==k_curmsg.checksum){ k_curmsg.done=1; } }else{ k_curmsg.checksum=ch; k_curmsg.done=1; } break; } if((k_REQ==k_drvhandle.mode)&&(k_FMT!=k_curmsg.state)){ TimerStart(k_REP_P4MS,k_TP4,0,1); } } 2.2 初始化 在開始診斷服務之前，診斷儀必須對ECU進行初始化，通過ECU的響應獲取ECU支持的報文頭格式和定時參數，建立診斷通訊【4】。初始化過程如圖1所示，診斷儀發送一個25ms ’0’、25ms’1’的WuP(WakeUp Pattern)，然后發送STC(StartCommunication) Request，ECU檢測出WuP并接收到正確的STC Request后返回STC Response，該報文的Data字段為由兩個字節構成的“關鍵字（Key Word）”，指定了ECU所支持的報文頭和定時參數信息，如Key Word指定為0x8fea即表示在報文頭中采用附加長度信息Len表示數據字段長度，同時采用默認的定時參數。 
圖1 初始化過程 初始化之前K線處于空閑狀態，ECU禁止SCI功能并使能SCI的RXD引腳為IO模式，檢測到下降沿時通過定時器統計RXD引腳的IO低電平的持續時間，檢測到上升沿時開始統計RXD引腳的IO高電平持續時間，判斷是否為有效的WuP；也可以設置SCI的波特率為200bps，判斷是否能接收到數據0xf0（0xf0在總線上表現為5個0，5個1），檢測出正確的WuP后，使能SCI功能，設置波特率為10400bps，等待診斷儀發送的STC Request，接收到請求后返回STC Response肯定響應，建立診斷通訊。 2.3 定時管理 ISO14230定義了4個定時參數管理字節間定時和報文間定時，診斷儀和ECU需要共同遵守這些定時約束以保證正常的診斷通訊，表2給出了這4個定時參數的含義及取值區間。
P1和P4是報文內字節間定時，P2和P3為報文間定時。診斷儀在初始化完成后或接收到診斷響應后需要在P3時間內發送診斷請求，否則ECU端退出診斷會話，斷開診斷通訊，K線協議驅動器重啟，等待診斷儀發出下一個WuP和STC Request。ECU在接收到診斷請求后，需要在P2時間內返回診斷響應， P2由ECU控制，通常采用25ms的固定值，當診斷請求報文中的Fmt字段指定目標地址為“功能地址”時，P2的取值需要用一個隨機數發生器來產生，因為對于功能尋址的診斷儀請求來說，可能多個ECU都會返回響應，如果采用固定的P2參數的話，可能會因為多個ECU競爭總線而出現總線沖突問題，P2采用隨機數，ECU不會在同一時間返回響應，從而避免了總線競爭問題。 3 協議驅動器測試 協議驅動器在Vector公司的CANoe軟硬件平臺上進行測試，進行基于K線的KWP2000服務測試時，將KWP2000.dll和KLineCPL.dll模塊加入CANoe仿真環境，CANoe模擬診斷儀節點，并使用一個代理節點來實現CAN網絡和K線之間的報文轉發，此時CANoe使用計算機的串口，并通過串口/K線轉換器與ECU相連，診斷實現框架如圖2所示。
圖2 K線診斷框架 與CAN總線診斷不同的是，K線診斷需要診斷儀通過初始化過程和ECU建立診斷通訊，診斷通訊的建立如圖3所示。建立診斷通訊后便可以像CAN診斷一樣進行診斷服務了，這方面論文很多，在此不再贅述。
圖3 建立診斷通訊 結語 本文實現的K線協議驅動器模塊經過嚴格測試, 能夠高效完成K線診斷，性能和穩定性達到預期設計要求。驅動器獨立于處理器和操作系統，具有良好的通用性和靈活性，可以方便得集成到應用程序中，具有很高的實用價值和借鑒意義。 來源：網絡 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
