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

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

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

1 總體設計方案

通過上文的分析，此次設計的整車診斷程序主要可以實現讀取數據功能和設置命令功能。為了實現這兩部分功能，首先需要對診斷的結構進行設計，然后對網絡協議方面進行設計。

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

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

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

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

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

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

2 診斷功能模塊設計與實現

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

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

汽車下線檢測時，EOL工具首先會對車載終端進行在線測試，通過在線測試來了解車載終端是不是已經在線。本文所用的終端是北斗終端，此處為雙通道通訊，通道1為CAN1，或稱為PCAN，波特率為250kbps，通道2為CAN2，或稱為DCAN，波特率為500kbps。此程序中，報文間的間隔不超過50ms。應答超時為200ms，也就是說EOL發(fā)送命令后，終端必須在200ms內反饋。在確定車載終端在線后，即開始進行故障檢測，分別檢測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內反饋。通用錯誤反饋為02 7F XX 00 00 00 00 00，XX為錯誤原因。

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

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

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

3 EOL功能測試結果

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

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

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

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

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

4 結論

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

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

參考文獻：

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

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

[3]李銳，王晶瑩，姚燕，等.基于ISO15765的車載CAN網絡診斷設計[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診斷系統的研究與設計[D].天津：河北工業(yè)大學，2017.

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

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

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

[9]鮑李俊，朱志峰，姚勇，等.基于CAN協議的汽車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.