基于ISO 15765的發(fā)動機防盜診斷服務開發(fā)

崔書超， 馮少嬋， 王魯蛟， 王東生

(北京汽車研究總院，北京 101300)

隨著技術的進步，汽車防護等級越來越高，2010年國家新出法規(guī)規(guī)定，民用車輛必須具備發(fā)動機防盜功能才能上市，發(fā)動機電子防盜系統(tǒng)是指發(fā)動機必須在經(jīng)過認證的情況下，才能正常啟動發(fā)動機，否則發(fā)動機將不能啟動.發(fā)動機防盜系統(tǒng)包括防盜線圈、防盜芯片、以及發(fā)動機防盜控制器.防盜系統(tǒng)的線圈通過磁場與鑰匙中的防盜芯片進行加密認證，第一步認證通過后，發(fā)動機防盜控制器與發(fā)動機控制單元通過網(wǎng)絡總線進行認證，二者認證通過后，整個發(fā)動機防盜系統(tǒng)認證完成，發(fā)動機允許啟動.

目前，ISO 14229 是許多汽車廠商采用的診斷通信應用層標準，是通過一種專用的診斷通信系統(tǒng)來形成一套較為獨立的診斷網(wǎng)絡，ISO 15765中規(guī)定了具體的傳輸方式.然而，發(fā)動機防盜系統(tǒng)牽涉到整車安全，如果相關診斷服務和其他控制器通用，就有被破解的風險，這樣就能通過診斷服務讀取IMMO控制器中的PIN碼和SK(Secret Key)碼，從而模擬發(fā)動機防盜控制系統(tǒng)啟動車輛，這大大增加了車輛不確定的安全隱患.

1 ISO 15765協(xié)議解析

ISO 15765協(xié)議是采用基于CAN總線的車載診斷標準，它是被ISO和SAE制訂的符合OBD的故障診斷通信協(xié)議[1]，并且在歐洲早已被廣泛采用.ISO 15765基于開放互連7層系統(tǒng)，其中：數(shù)據(jù)鏈路層協(xié)議遵循ISO 11898-1；網(wǎng)絡層遵循ISO 15765-2，為應用層提供服務，數(shù)據(jù)分割方法，流控制傳輸機制，以及數(shù)組重組的方法，它允許傳輸最大字節(jié)可達4 095字節(jié)；應用層的診斷服務參考ISO 14229-1與ISO 15031-5，并加入了CAN總線診斷功能組，兼容了一些汽車廠商規(guī)范中定義的診斷服務，具有測試、檢查、監(jiān)控、診斷管理等功能.網(wǎng)絡層中規(guī)定了4種數(shù)據(jù)服務結(jié)構：單幀(SF N_PDU)、首幀(FF N_PDU)、連續(xù)幀(CF N_PDU)和流控制，它為應用層提供數(shù)據(jù)接口，分別用于診斷設備(Tester)的服務請求、ECU的服務指示、ECU的服務響應和Tester的服務確認，這些數(shù)據(jù)結(jié)構中包含了地址信息、服務請求ID和服務請求參數(shù)等內(nèi)容.這4種數(shù)據(jù)單元在同一個網(wǎng)絡層中通信，交換數(shù)據(jù)參數(shù)，傳遞用戶數(shù)據(jù)等內(nèi)容[2].

發(fā)動機防盜診斷服務通過數(shù)據(jù)協(xié)議單元(N_PDU)與發(fā)動機控制器之間通過單幀或多幀的方式傳遞數(shù)據(jù).協(xié)議控制信息包括：N_PCI類型、流控制狀態(tài)、塊大小、最小操作時間，控制信息如表1所示.

表1 協(xié)議控制信息

當需要傳遞的信息比較少時，采用一幀就可把所有數(shù)據(jù)信息都傳遞完畢時，用單幀方式進行傳輸，由上表分析可知單幀中的幀長度參數(shù)由SF_DL決定，它規(guī)定了單幀的數(shù)據(jù)域字節(jié)最大為7個字節(jié).當需要傳遞的信息比較多時，采用一幀數(shù)據(jù)不能所有數(shù)據(jù)信息都傳遞完畢時用多幀幀方式進行傳輸.多幀包括首幀，連續(xù)幀，以及流控制幀，首幀中包括有多幀的總長度大小FF_DL,連續(xù)幀中的SN是連續(xù)幀標號，流控制幀是多幀的控制幀，它的設置是為了解決通信雙方的同步問題，其中規(guī)定了流控制的狀態(tài)FS：0繼續(xù)發(fā)送、1等待、2超過規(guī)定數(shù)目，BS為塊大小，也就是發(fā)送連續(xù)幀每包的數(shù)目大小.這幾個參數(shù)都是故障診斷協(xié)議標準ISO 15765中重要的參數(shù)，在多幀傳輸方式中，他們共同決定多幀流控制幀的工作方式，如圖1為多幀流控制具體工作機制.

如上圖所示，流控制機制允許節(jié)點發(fā)動機防盜IMMO控制器通知發(fā)送節(jié)點tester，接收節(jié)點的接受能力，那么發(fā)送節(jié)點將自動選擇以單幀或者多幀的方式傳遞數(shù)據(jù)，這樣將大大提高了通信效率問題，而且數(shù)據(jù)同步也不會出錯.

圖1 多幀流控制工作機制

2 診斷服務和故障代碼DTC定義

在對IMMO控制器下線匹配或者在診斷過程中,診斷設備通向IMMO控制器進行服務請求,當網(wǎng)絡中IMMO控制器接收信息后返回服務響應,與診斷設備建立通信連接.診斷設備每個單元在應用層數(shù)據(jù)域的第一個字節(jié)中都有它的服務ID(SI)，不同的響應信息通過服務ID(SI)返回.為了保障通訊服務不被破解，參照ISO 14229 診斷服務ID，編制IMMO和EMS診斷服務ID(只展示部分重要服務)，如表2所示.

表2 診斷服務實現(xiàn)

在ISO 15765協(xié)議中診斷信息中包含DTC高字節(jié)，DTC低字節(jié)，DTC計數(shù)字節(jié)和DTC狀態(tài)，里面沒有全面的DTC定義，但是協(xié)議允許汽車制造廠商使用自己的定義.故障診斷代碼DTC總長度為4字節(jié)(32bit)，它包括：可疑參數(shù)組SPN(19bit)、故障類型代碼FMI(5bit)、故障發(fā)生頻率OC(7bit)、SPN轉(zhuǎn)算方法CM(1bit).一般而言，所定義的故障代碼要涵蓋主要和重要的故障，已達到及時定位故障的目的，參照ISO 15765中DTC格式[3]，如表3所示.

表3 DTC格式

基于以上分析，另外，在ISO 15765協(xié)議中，U代表CAN通訊系統(tǒng)[4]，如表4為本系統(tǒng)制定的部分故障代碼.

表4 定義的故障代碼

3 下線匹配軟件開發(fā)

文中采用CANoe進行下線匹配軟件開發(fā)，CANoe是德國Vector公司開發(fā)的專門用于仿真和測試CAN通訊的軟件，主機廠大部分采用CANoe進行汽車電子系統(tǒng)開發(fā)[5].在使用時會用到CANoe的CAPL編程，這是一種類C語言的編程語言，屬于一種面向?qū)ο蟮恼Z言，里面配套有豐富的內(nèi)置函數(shù)和API接口,利用CAPL編程，具體匹配界面如下，通過CANoe軟件設置好波特率、采樣點等信息，如圖2為程序運行流程圖，部分原始程序如圖3.軟件最終界面如圖4.

圖2 程序運行流程圖

圖3 軟件原始程序

圖4 診斷服務實現(xiàn)界面

4 試驗驗證

為了驗證系統(tǒng)的可靠性通信與穩(wěn)定性，我們搭了試驗臺架驗證診斷服務系統(tǒng)的穩(wěn)定性，當我們在診斷軟件和寫入診斷服務的IMMO控制器相連接的時候，我們進行一下試驗驗證，利用所定義的服務寫入PIN碼和ESK來驗證所定義的服務是否符合要求，寫入ESK碼為16個byte11，PIN碼為byte1234，下表(表4)為所記錄的數(shù)據(jù).

表4 試驗數(shù)據(jù)

通過上表數(shù)據(jù)分析，設備利用所定義的診斷服務正確發(fā)送了請求，IMMO控制器能夠肯定響應進行回復，表明診斷系統(tǒng)開發(fā)可靠有效.

5 結(jié) 論

文中研究的發(fā)動機防盜診斷技術，通過試驗驗證是安全可靠的，它是基于ISO 15675協(xié)議來制定的.基于安全需求，在參考ISO 15765的基礎上，能夠?qū)刂破鬟M行數(shù)據(jù)讀寫操作，同時在遇到故障時,可以很方便定位故障和解決故障.通過驗證分析，該系統(tǒng)對車輛故障的排除指明了方向,并在實際的運用中表明,該方法具有實際意義.