[摘要]本文根據(jù)類網(wǎng)關(guān)模塊對一種典型診斷問題進行原因分析及措施優(yōu)化，同時對于AUTOSAR架構(gòu)下CAN通信邏輯進行簡單總結(jié)，為后續(xù)類似問題提供分析參考，以及為類似模塊開發(fā)提供設(shè)計參考。

[關(guān)鍵詞] CAN總線；AUTOSAR架構(gòu)；診斷故障

中圖分類號：U463.6 " 文獻標(biāo)志碼：A " " "文章編號：1003-8639（2023）07

收稿日期：2023-03-03

作者簡介：張小霞（1992—），女，工程師，碩士，目前主要從事BCM/VDM模塊設(shè)計發(fā)布方面的工作。

隨著CAN總線在汽車工業(yè)的普及應(yīng)用以及越來越快的總線傳輸速率，安全娛樂、數(shù)據(jù)上傳等性能對于CAN總線通信品質(zhì)的要求越來越高。本文提供一種針對總線診斷類問題的解決思路，為類似問題的處理和類似模塊開發(fā)設(shè)計提供參考。

汽車OEM制造商針對整車下線管理使用汽車下線檢測系統(tǒng)，即EOL（End Of Line），整車廠EOL的主要目的是軟件下載、電路檢測及參數(shù)校驗，即軟件版本控制、對生產(chǎn)信息及特定信息進行改寫、對故障碼進行診斷，確?？傃b完成后不會存在電路問題以及針對特定功能進行參數(shù)學(xué)習(xí)；EOL基于UDS診斷協(xié)議實現(xiàn)，在此過程中，電子模塊需要確保CAN通信功能正常，對于上位機的診斷指令及時響應(yīng)，否則大大降低EOL的通過率。

1 "問題描述

某OEM在新車型試造時，EOL產(chǎn)線上多次報出某模塊刷新失敗，具體問題為對$27 $02/$85 $02/$10 $03/$19 $01等診斷指令偶發(fā)性無響應(yīng)，使得上位機報出故障，中斷EOL。

2 "原因分析

問題出現(xiàn)后，總體分析造成總線通信故障的各類可能原因。首先是整車環(huán)境影響，該模塊正常的工作電壓是9～16V，如果上電后整車電壓異常，會影響模塊的正常工作，實際問題出現(xiàn)時，經(jīng)持續(xù)測量，整車電壓正常，排除整車環(huán)境的影響。同時也要考慮是否是模塊硬件故障引起，觀察問題出現(xiàn)時對于總線A上的診斷報文，偶發(fā)性出現(xiàn)部分診斷無相應(yīng)的問題，從時間上來看也并非在某一段時間內(nèi)無相應(yīng)問題。如果是硬件問題導(dǎo)致，會出現(xiàn)整條總線診斷報文均無相應(yīng)的現(xiàn)象，所以也排除硬件故障，考慮該問題是軟件故障導(dǎo)致，接下來進行進一步的分析。

模塊在交付OEM之前，供應(yīng)商家對刷新進行測試，并未出現(xiàn)問題，所以需要對比模塊在EOL產(chǎn)線刷新以及供應(yīng)商家進行模塊刷新測試的區(qū)別。供應(yīng)商家進行模塊刷新時只有1個節(jié)點，整車CAN總線連接多個節(jié)點，可能是總線負載率引起的差別。首先對于整車刷新環(huán)境下的負載率進行測算，具體見表1。由表1可得出，OEM產(chǎn)線上問題發(fā)生時的網(wǎng)絡(luò)負載率遠遠大于供應(yīng)商家測試時的網(wǎng)絡(luò)負載率。在2種總線負載率的情況下對比測試模塊的CPU負載，發(fā)現(xiàn)相差不大?；谝陨蠑?shù)據(jù)分析，初步懷疑是部分診斷報文在傳輸過程中出現(xiàn)丟失，未傳遞到APP，使得偶發(fā)出現(xiàn)診斷報文無響應(yīng)的問題。

表1 "類網(wǎng)關(guān)模塊在OEM和供應(yīng)商家測試數(shù)據(jù)對比

基于以上懷疑方向，需要對CAN報文傳輸過程中是否存在問題進行排查。首先梳理下CAN報文通信邏輯，本模塊使用的是AUTOSAR通信協(xié)議棧，AUTOSAR通信協(xié)議棧是由BSW通信服務(wù)、通信硬件抽象和通信驅(qū)動程序組成。本文提到的模塊使用CAN總線協(xié)議，具體AUTOSAR CAN通信協(xié)議棧見圖1。

CAN模塊是底層的一部分，主要執(zhí)行硬件訪問，并向上層提供與硬件無關(guān)的API，只有上層模塊CANIF模塊能夠唯一訪問CAN模塊。CAN模塊為發(fā)起傳輸，并調(diào)用CANIF模塊的回調(diào)函數(shù)來通知事件提供服務(wù)，它獨立于硬件。此外，它還提供控制屬于同一CAN硬件單元（CAN Hardware Unit）的CAN控制器（CAN Controller）的行為和狀態(tài)的服務(wù)。多個CAN控制器可以由1個CAN模塊控制，只要它們屬于同1個CAN硬件單元。而CAN硬件單元由1個或多個CAN控制器組成。這些控制器可以位于芯片上，也可以作為同一類型的外部獨立設(shè)備，具有公共或單獨的硬件對象（Hardware Objects）。在本文類網(wǎng)關(guān)模塊中，解釋2條總線上報文時，CAN硬件單元由2個CAN控制器連接2個物理通道組成，具體如圖2所示。

CAN IF位于底層CAN驅(qū)動 （CAN DIVER）、CAN收發(fā)器（CAN TRCV）和上層通信服務(wù)層（CAN SM、CAN NM）、CAN傳輸協(xié)議（CAN TP）、PDUR之間，它表示上層通信層CAN驅(qū)動程序服務(wù)接口。CAN IF提供了獨特的接口來管理不同CAN硬件，如CAN控制器和收發(fā)器，同時基于CAN通道相關(guān)的CAN狀態(tài)管理器模塊（CAN SM）可以控制多個底層內(nèi)部和外部CAN控制器或CAN收發(fā)器。CAN IF由與CAN硬件無關(guān)的任務(wù)組成，屬于ECU CAN通信驅(qū)動程序，CAN IF滿足PDDR和AUTOSAR COM棧上層通信模塊的控制流和數(shù)據(jù)流要求：發(fā)送請求處理、發(fā)送確認(rèn)、接收指示和CAN控制器的啟動停止，從而喚醒或參與網(wǎng)絡(luò)，它的數(shù)據(jù)處理和通知接口基于CAN L-SDU，在發(fā)送請求時，CAN IF用相應(yīng)的參數(shù)完成L-PDU的傳輸，并通過對應(yīng)的CAN DRV將CAN L-PDU轉(zhuǎn)發(fā)給CAN控制器；在接收端，CAN IF將收到的I-PDU作為I-SDU分發(fā)到上層模塊，在傳輸確認(rèn)時，CAN IF負責(zé)向上層發(fā)送傳輸成功的信息。

CAN TP是AUTOSAR通信棧中負責(zé)網(wǎng)絡(luò)解析的模塊，從上到下，CAN TP負責(zé)對CAN I-PDU進行分段和重新組裝；從上到下，負責(zé)接收CAN IF層傳輸?shù)腘-PD數(shù)據(jù)解析成I-PDU數(shù)據(jù)，并傳遞給PDUR模塊；CAN TP只處理傳輸協(xié)議幀，即單幀、首幀、連續(xù)幀、流控幀，同時對于CAN TP層，只接收事件觸發(fā)模式。

AUTOSAR COM是AUTOSAR通信的重要組成部分，它是從OSEK COM標(biāo)準(zhǔn)的基礎(chǔ)上發(fā)展而來的，它提出了一個不同速率的總線網(wǎng)絡(luò)之間進行數(shù)據(jù)交換的方法，為內(nèi)部和外部通信定義了公共的軟件通信接口和行為，增強了應(yīng)用軟件模型的可移植性。COM模塊是位于上層模塊RTE和下層模塊PDUR之前的服務(wù)層模塊，主要用于與RTE之間的信號交互，對信號進行打包和解包，另外在COM模塊中還可以配置IPDU的通信周期、通信周期偏移量、IPDU Group等。對于具體的信號收發(fā)，在發(fā)送過程中，應(yīng)用層調(diào)用COM層提供的信號發(fā)送函數(shù)，根據(jù)配置，信號的數(shù)據(jù)經(jīng)過字節(jié)序轉(zhuǎn)換后被更新到I-PDU相應(yīng)位置；在接收過程中，當(dāng)?shù)讓邮盏絀-PDU時，底層將調(diào)用COM層的指示函數(shù)Com_RxIndication（），將I-PDU的數(shù)據(jù)從底層拷貝到COM中，調(diào)用信號的接收函數(shù)后，該I-PDU的信號將經(jīng)過字節(jié)順序轉(zhuǎn)換、擴展轉(zhuǎn)換和接收過濾后，數(shù)據(jù)被拷貝到應(yīng)用層。

CAN報文傳輸至應(yīng)用層后，應(yīng)用層進行處理響應(yīng)的報文在網(wǎng)絡(luò)層一層一層傳遞至CAN模塊，從而傳遞至CAN總線上，即在總線上可以看到模塊對于診斷報文的具體響應(yīng)。

梳理清楚CAN網(wǎng)絡(luò)層傳輸邏輯后，需要判斷CAN報文丟失發(fā)生在網(wǎng)絡(luò)層的哪條傳輸路徑中。簡單整理可能存在的問題點，具體如下。

1）該類網(wǎng)關(guān)模塊診斷功能僅存在總線A上，所以可能是從總線A接收報文進CAN模塊的過程中發(fā)生了報文丟失的問題，即相應(yīng)報文沒有從CAN收發(fā)器接收進MCU。

2）報文正常收進MCU，但是在向上層傳輸過程中發(fā)生了丟失，使得無法傳遞至APP層進行處理。

3）報文正常進入應(yīng)用層，應(yīng)用層進行處理后，響應(yīng)報文向下傳輸過程中發(fā)生了丟失，使得總線上無該模塊發(fā)送的響應(yīng)報文。

以上列出可能的問題點需要debug調(diào)試來確認(rèn)。首先對于總線A上報文是否正常收進MCU進行判斷，和相應(yīng)代碼處打斷點，編寫debug程序進行調(diào)試，發(fā)現(xiàn)收進MCU的報文數(shù)量小于總線上接收的報文數(shù)量。正向分析這一部分代碼邏輯，發(fā)現(xiàn)CAN模塊主函數(shù)邏輯如下：模塊接收總線信號是通過網(wǎng)絡(luò)中斷觸發(fā)方式，接收到報文觸發(fā)網(wǎng)絡(luò)中斷后，會將總線的相關(guān)報文信息（包括診斷報文及應(yīng)用報文）放在一個長度為60的Buffer中，軟件內(nèi)部會通過輪詢的方式從Buffer中取得數(shù)據(jù)，傳遞到CANIF層；總線A上診斷報文及應(yīng)用報文數(shù)量較多，在沒有做過濾的前提下，使得短時間接收較多報文，超出Buffer的長度，使得出現(xiàn)總線報文丟失的現(xiàn)象，無法將部分診斷報文傳輸至APP層，從而出現(xiàn)診斷無響應(yīng)的問題。

3 "解決方案

明確問題根本原因后，在報文收進CAN模塊中的Buffer前，增加報文過濾，僅允許VDM需要接收的診斷報文和應(yīng)用報文進入Buffer，減少進入Buffer的報文數(shù)量，確保需要接收的報文接收進CAN模塊。

4 "方案驗證

軟件更改后，在問題發(fā)生時的整車環(huán)境下（總線負載48%）進行診斷測試，模塊響應(yīng)的診斷報文無丟失現(xiàn)象，然后總線負載加載到80%進行診斷測試，模塊響應(yīng)的診斷報文也無丟失現(xiàn)象，確認(rèn)方案有效。

5 "結(jié)語

本文以類網(wǎng)關(guān)模塊為例，介紹了該模塊開發(fā)過程中出現(xiàn)的一種典型總線診斷故障類問題，同時對AUTOSAR架構(gòu)下CAN報文通信邏輯進行了簡單匯總，為其余模塊面對類似問題提供了分析思路，同時對模塊開發(fā)提供設(shè)計指導(dǎo)，以確保模塊CAN通信開發(fā)的穩(wěn)健性。

參考文獻：

[1]朱福成. 汽車CAN總線系統(tǒng)故障診斷技術(shù)淺析[J]. 吉林化工學(xué)院學(xué)報，2018，35（1）：76-80.

[2]何曄. CAN總線報文丟失故障及其判定方法[J]. 科技視界，2015（33）：126.

（編輯 "凌 "波）