基于ISO15765的整車診斷程序軟件設計研究

摘 要：為了確保交付到用戶手中的汽車安全質(zhì)量達標，EOL診斷測試必不可少。目前，市面上很多的車企都使用的是ISO14230協(xié)議，是基于K線檢測的。但是因為診斷系統(tǒng)完全獨立于汽車內(nèi)部CAN網(wǎng)絡系統(tǒng)，這使得汽車的成本上升，汽車內(nèi)部網(wǎng)絡也變得更加復雜。所以本文采用基于ISO15765協(xié)議設計的EOL整車診斷程序能夠利用目前大部分車輛的CAN總線，使用現(xiàn)成的汽車CAN總線做檢測，這樣就能夠減少車輛的成本，并且提高汽車CAN總線的負載。本文提出的基于ISO15765的整車診斷程序經(jīng)過測試代碼運行正常，可以滿足EOL的基本功能，可以為整車診斷測試提供建議。

關鍵詞：CAN總線 ISO15765 診斷程序

隨著汽車行業(yè)的日益發(fā)達，車輛上的電子設備也愈來愈多，人們對車輛的舒適、安全的需求愈來愈高。為了確保交付到用戶手中的汽車安全質(zhì)量達標，EOL診斷測試必不可少。本文基于ISO15765協(xié)議設計了一套EOL診斷程序。ISO15765以ISO14229—1所定義的服務為基準，規(guī)范了基于CAN總線的診斷業(yè)務（UDS on CAN），包含了網(wǎng)絡管理、網(wǎng)絡定時、應用層定時等詳細內(nèi)容，使該協(xié)議的適用范圍和操作性更強[2]。通過采用CAN總線通道對汽車控制器網(wǎng)絡進行故障診斷，可以為故障診斷技術在車輛的電控系統(tǒng)中產(chǎn)生廣泛應用提供了有利條件。ISO15765協(xié)議順應著現(xiàn)代汽車網(wǎng)絡總線技術的發(fā)展趨勢，并逐漸被更多的車企所采用。

1 總體設計方案

通過上文的分析，此次設計的整車診斷程序主要可以實現(xiàn)讀取數(shù)據(jù)功能和設置命令功能。為了實現(xiàn)這兩部分功能，首先需要對診斷的結(jié)構(gòu)進行設計，然后對網(wǎng)絡協(xié)議方面進行設計。

如圖1所示，本文選用的是客戶端（診斷設備）與服務器（ECU）在同一個網(wǎng)絡，客戶端與服務器直接相連的診斷結(jié)構(gòu)[3]。當診斷設備與ECU在同一個車載網(wǎng)絡中時，診斷設備與ECU直接相連，系統(tǒng)功能設計及車載終端診斷軟件各功能模塊之間的關系與參數(shù)傳遞如圖所示。本文主要介紹診斷功能模塊軟件方面的設計。

EOL軟件主要包括讀取數(shù)據(jù)和設置終端參數(shù)兩方面功能。由于診斷協(xié)議的實施涉及診斷設備與被診斷網(wǎng)絡ECU之間的診斷通信，因此，診斷協(xié)議的設計涵蓋了診斷設備軟件的設計和被診斷ECU的設計。在系統(tǒng)功能設計中，診斷設備的診斷協(xié)議實現(xiàn)即為車載終端診斷軟件協(xié)議的實現(xiàn)。

如圖2所示，將ISO15765協(xié)議映射成OSI架構(gòu)，ISO15765規(guī)定的服務要劃分為三個部分：ISO15765—3定義的診斷服務對應著應用層，ISO15765—2定義的網(wǎng)絡層服務對應著網(wǎng)絡層，以及ISO11898—1定義的CAN通信服務對應著數(shù)據(jù)鏈路層間的數(shù)據(jù)傳輸。應用層業(yè)務必須符合ISO14229—1和ISO15031—5等國際診斷協(xié)議，并且ISO15765—3協(xié)議也要和國家標準以及為汽車廠商所定制的規(guī)范相一致。網(wǎng)絡層能夠獨立于物理層實現(xiàn)，而且只用于通用車載診斷（OBD）的物理層，對于其他應用領域，如ISO15765協(xié)議能夠使用到所有CAN物理層。

在設計診斷軟件診斷協(xié)議時，考慮了診斷協(xié)議中否定響應的可能情況，在與被診斷ECU進行診斷通信發(fā)生否定響應狀況時，上位機會給以否定響應種類和原因的提示。此處以安全訪問服務的診斷協(xié)議實現(xiàn)執(zhí)行流程為例，見圖3所示。

ECU進行非默認模式會話請求，然后，進行安全等級選擇并請求種子，根據(jù)接收到的種子及安全訪問算法發(fā)送密鑰，收到ECU正定響應后則ECU被解鎖。

診斷協(xié)議的核心實施是在診斷裝置與被診斷網(wǎng)絡ECU之間進行診斷信息的交流。因此，診斷協(xié)議的設計包括對診斷裝置程序和被診斷ECU的診斷協(xié)議進行開發(fā)。同時，在系統(tǒng)功能設計中，診斷設備的診斷協(xié)議實現(xiàn)即是診斷應用協(xié)議的執(zhí)行。

2 診斷功能模塊設計與實現(xiàn)

診斷功能模塊主要包括讀取數(shù)據(jù)功能和設置終端參數(shù)兩項功能模塊。程序中CAN.c和CAN.h為ISO15765協(xié)議部分。Basic_logic為時鐘函數(shù)。EOL診斷相關的代碼在eol.c和eol.h中，所有代碼在main中執(zhí)行。Usart_debug代碼部分的代碼主要功能為使用usart3作為調(diào)試輸出串口并進行串口通信。（圖4）

本文的診斷結(jié)構(gòu)設計選用的是診斷設備與被診斷ECU在同一個網(wǎng)絡，無需直接連接網(wǎng)關客戶端與服務器。診斷上位機與被診斷ECU連接到同一網(wǎng)絡，形成了車載網(wǎng)絡診斷系統(tǒng)。（圖5）

汽車下線檢測時，EOL工具首先會對車載終端進行在線測試，通過在線測試來了解車載終端是不是已經(jīng)在線。本文所用的終端是北斗終端，此處為雙通道通訊，通道1為CAN1，或稱為PCAN，波特率為250kbps，通道2為CAN2，或稱為DCAN，波特率為500kbps。此程序中，報文間的間隔不超過50ms。應答超時為200ms，也就是說EOL發(fā)送命令后，終端必須在200ms內(nèi)反饋。在確定車載終端在線后，即開始進行故障檢測，分別檢測GPS/北斗定位模塊，GPS/北斗定位天線，通訊模塊等是否能正常工作。

當更換終端時，ECU可能是綁定狀態(tài)，新終端未綁定。此時需要新終端發(fā)送不控制命令，判斷ECU是否正常反饋，反饋正常ECU綁定，終端自動進入綁定模式。如果反饋錯誤，則不再綁定。該程序的流程圖如圖6所示。

當EOL發(fā)送命令后，會讀取設備的綁定狀態(tài)。若為綁定狀態(tài)，則反饋給EOL失敗01；若為未綁定狀態(tài)，則會直接發(fā)心跳到ECU，若ECU心跳反饋失敗，則反饋給EOL失敗02，若ECU心跳反饋成功，則設備進入綁定狀態(tài)，開啟正常的循環(huán)心跳，反饋給EOL成功00。此處同樣報文間的間隔不超過50ms。應答超時為200ms，也就是說EOL發(fā)送命令后，終端必須在200ms內(nèi)反饋。通用錯誤反饋為02 7F XX 00 00 00 00 00，XX為錯誤原因。

在診斷中典型故障有發(fā)動機超速。發(fā)動機超速是指發(fā)動機的速度達到了所允許的速度的最大值以外。因此在設置終端參數(shù)的時候可以設置發(fā)動機超速門限來保護發(fā)動機。

設置發(fā)動機轉(zhuǎn)速超速門限命令ID為2E11，Byte類型字節(jié)（高字節(jié)在前，低字節(jié)在后）。轉(zhuǎn)速超速門限最高可以配置到5000，高于5000 則返回錯誤應答。轉(zhuǎn)速超速門限不可為零，如果為0，則返回錯誤應答。

如果ACC接通后，可以讀取P文件號，則按照P文件號來重新配置轉(zhuǎn)速超速門限，并保存，如果不能提取P文件號，則按照掉電保存的參數(shù)來判斷轉(zhuǎn)速超速。如果提取的轉(zhuǎn)速超過5500轉(zhuǎn)，則判斷為異常轉(zhuǎn)速，不觸發(fā)轉(zhuǎn)速超速報警。如果掉電保存的轉(zhuǎn)速超速門限超過5000，則將轉(zhuǎn)速超速門限賦值為2600。

3 EOL功能測試結(jié)果

進行EOL功能測試時，默認終端在線、ECU反饋心跳正常，并設置了各狀態(tài)的默認值。EOL發(fā)送請求數(shù)據(jù)的命令，終端進行回復，其中對于多幀數(shù)據(jù)還需要等待EOL發(fā)送流控幀再進行回復。數(shù)據(jù)信息統(tǒng)一存儲在結(jié)構(gòu)體vehicle_data中。若接收的數(shù)據(jù)與正確反饋的數(shù)據(jù)一致，則代碼測試正常，可以滿足EOL基本功能。

讀取GPRS工作狀態(tài)測試結(jié)果如圖7所示，以讀取GPRS工作狀態(tài)為例，PC軟件端發(fā)送請求代碼02 01 04 00 00 00 00，請求代碼基于ISO15765協(xié)議發(fā)送到被診斷網(wǎng)絡后，被診斷的ECU回復反饋代碼03 01 04 01 00 00 00 00。之后車載終端解析報文，在顯示屏中顯示GPRS工作正常。

但由于在ISO15765協(xié)議定義中，報文最大字節(jié)數(shù)為8個字節(jié)，但實際情況中可能8個字節(jié)無法顯示全部數(shù)據(jù)，這時就需要在ECU回復首幀后，再發(fā)送一個流控制幀，隨后ECU會將剩下的報文發(fā)送過來。此處以讀取設備的版本號為例，PC軟件端發(fā)送請求代碼02 01 07 00 00 00 00，請求代碼基于ISO15765協(xié)議發(fā)送到被診斷網(wǎng)絡后，被診斷的ECU反饋首幀代碼10 11 01 07 41 42 43 44，隨后我們需要發(fā)送流控制幀30 00 32 00 00 00 00 00。之后ECU便會將剩余的報文都發(fā)送到車載終端，在車載終端解析報文后，在顯示屏中顯示設備的版本號。

特定工具對某一數(shù)據(jù)發(fā)送設置信息，終端成功接收信息后反饋，并將數(shù)據(jù)存儲在結(jié)構(gòu)體函數(shù)termin_para中。測試過程與讀取數(shù)據(jù)功能測試過程類似，若接收的數(shù)據(jù)與前文中正確反饋的數(shù)據(jù)一致，則代碼測試正常，可以滿足EOL基本功能。

同步時間測試結(jié)果如圖9所示，以同步時間為例發(fā)送命令07 2E 0B 18 01 09 10 07后。當PC軟件端將代碼請求發(fā)送到衛(wèi)星模塊ECU后，ECU便會通過衛(wèi)星將時間反饋給車載終端。車載終端便可更新時間。若衛(wèi)星無授時功能，則會將PC軟件端的時間同步到車載終端。

4 結(jié)論

本次文開發(fā)了一套基于ISO15765協(xié)議的EOL整車線下診斷程序。利用目前大部分車輛的CAN總線，使用現(xiàn)成的汽車CAN總線做檢測，采用客戶端與服務器直接相連的診斷結(jié)構(gòu)，對診斷功能模塊進行設計，既利于減少車輛的成本，又可以提高汽車CAN總線的負載。最后對程序進行了測試，結(jié)果表明：本文提出的基于ISO15765的整車診斷程序經(jīng)過測試代碼運行正常，可以滿足EOL的基本功能。該系統(tǒng)性能穩(wěn)定，可靠性高，性能穩(wěn)定，具有良好的適用性，在今后的市場中有著廣闊的發(fā)展空間。

課題名稱：車用永磁同步電機耦合故障機理及智能診斷方法研究（課題編號：Y2022002）。

參考文獻：

[1]王瑋，楊法松.CAN診斷協(xié)議在生產(chǎn)線EOL系統(tǒng)中的應用[J].汽車實用技術，2016，8（60）：187-189.

[2]張慧忠.基于整車控制器的純電動汽車故障診斷系統(tǒng)開發(fā)[D].湖南大學，2016.

[3]李銳，王晶瑩，姚燕，等.基于ISO15765的車載CAN網(wǎng)絡診斷設計[J].計算機工程，2012，38（04）：35-36+39.

[4]周紅英，陶龍龍.基于ISO15765CAN總線診斷測試方法研究[J].汽車實用技術，2016，（10）：140-142.DOI：10.16638/j.cnki.1671-7988.2016.10.045.

[5]李亞運.電動汽車VCU診斷系統(tǒng)的研究與設計[D].天津：河北工業(yè)大學，2017.

[6]寧天楓.北斗/GPS雙模定位的輕型電動物流車遠程監(jiān)控終端研制[D].北京：中國科學技術大學，2016.

[7]裴軍偉，韓可強，丁健，等.基于EOL的下線診斷寫配置系統(tǒng)開發(fā)[J].設計研究，2019，01（12）：30-32.

[8]李亞運，孫耀杰.基于ISO15765的電動汽車診斷系統(tǒng)設計[J].計算機測量與控制，2017，25（1）：24-31.

[9]鮑李俊，朱志峰，姚勇，等.基于CAN協(xié)議的汽車ECU刷寫的診斷程序設計[J].電聲技術，2020，44（1）：93-96.

[10]Sun Y， Shen J，Yang Z. A Security Reinforcement Technology of Telematics Box Based on Secure Element[C].ICA3PP， GUANG ZHOU， 2018.ICA3APP， GUANG ZHOU：Springer Nature Switzerland AG，2018：101-116.

[11]Matej K， Patrik B. Realization of communication via the CAN bus [C].13th International Scientific Conference， Slovak，2019. Elsevier B.V. Slovak：ScienceDirect，2019：332-337.