幾乎所有的ECU，都要做CAN方面的測試，BCM、EMS、VCU、BSG、BMS、TCU、EPS、ADAS等，只要帶CAN埠，都需要做這樣的測試，幾乎所有OEM都要求供應商CAN測試。

診斷通訊定義

對於絕大多數車企而言，診斷通訊的定義沿用的是UDS框架，只是所定義內容各自略有不同。

讀故障請求示意圖

假如診斷通訊所用的ID分別為0x703（CANoe→被測ECU）和0x723，那麼：

CANoe讀取被測ECU的故障值的方式為：發資料 “03 22 DE 62”，然後被測ECU返回ID 0x723，資料區首先包含返回的估值位元組數，然後按照類似dbc的Multiplexer的定義方式，用滾動ID的方式，返回各個ECU的故障值

CANoe讀清除被測ECU的故障值的方式為：發資料 “04 14 ”，然後被測ECU返回ID 0x723，資料區包含清除結果，或成功清除，或者需要等待，正在清除中。

清除故障命令，所返回的結果，要麼成功，要麼等待中，但是讀取故障，返回的值比較複雜，需按照類似dbc的Multiplexer的定義方式，將結果拼接成一個長資料，再根據故障位置的定義，從對應的位置去索引故障狀態結果的值。

一般而言，由於整車功能規劃和通訊協議矩陣的變化，對於被測ECU，所接收的ID是不固定的，不同專案、不同車型平臺之間很容易出現變動。但是所接收的ID來自於哪些ECU，是比較固定的，再加上ID的數量要遠多於ECU的數量，所以，被測ECU返回的“拼接陣列”，在全行業看，是以傳送方控制器為基本單元進行索引的，而不是以傳送方傳送的ID。換句話說，被測ECU所接收的其中2個ID，如果來自同一個控制器，則它們兩個分別掉線之後從被測ECU返回的診斷故障資料，是完全一樣的。

CAN故障診斷測試包含哪些項？

假如被測ECU接收了15個ID，每個ID都有自己的週期，那麼，如果某一個ID掉線了（包括長期掉線和短暫掉線），ECU應該怎麼處理？報什麼故障值？如果是短暫掉線，報文又恢復了，又該報什麼故障值？

整車一般有一個總控模組，當它發的某個訊號為1的時候，其他模組才能啟用故障記錄功能，如果發0，其他模組禁止記錄故障，這個總控模組一般為BCM或者閘道器。那麼，就需要檢查一下，它發0的時候，其它是不是真的沒有記錄，它發1的時候，是不是真的記錄了，有沒有做到“令行禁止”？

當CAN匯流排被CANstress持續干擾（比如RTR位被幹擾），被測ECU busoff了，之後再取消干擾，被測ECU有沒有自動bus off recovery，且正常工作？再檢測到故障時（比如某個ID掉線了），有沒有正常記錄掉線故障值？能不能正常返回故障？

當所接收的報文的DLC和定義的不一樣時，被測ECU應對其拋棄，認為沒有接收到正確報文，按照掉線處理。讀取故障時，應能返回正確的故障。它實際上有沒有做到這樣？

當被測ECU持續接收不到ACK時，應當報傳送錯誤，但不應當有錯誤幀，也不應當bus off，而是該怎麼工作還怎麼工作。它實際上有沒有實現這個要求？

測試方案設計

PC：需要安裝LabVIEW和CANoe，且CANoe需要能正常呼叫框圖中所有Vector體系內的硬體。即CANoe的CAPL語言要能正常呼叫這些硬體。

VN1640：在本系統的功能為記錄匯流排資料。

CAN卡：用於和被測ECU之間收發報文，是上圖測試方案的核心部件。因為牽涉到多週期報文的傳送，在CAPL中實現非常繁瑣，而且需要按照Multiplexer的定義方式拼接資訊陣列，所以需要該CAN卡能夠較好地支援底層呼叫。

可程式設計電源：用於給被測ECU供電，如果公司內部有Vector系列的可程式設計電源，可通過CAPL呼叫，那可以直接應用。如沒有，可以採購更便宜的可程式設計電源，通過LabVIEW呼叫亦可。

CANstress：給被測ECU製造匯流排干擾，屬於關鍵裝置，建議採用Vector的。

案例說明

假設要測試VCU控制器，VCU控制器共接收25個ID（見圖1），測試讓ID逐個掉線，然後讀取被測物件返回的故障值，再使掉線的ID恢復，然後再清除故障，掉線時長分別為：T1，T2，T3，T4，相應返回故障值的期望也會有區別，然後把所有ID輪一遍。

1. LabView呼叫電源，重啟被測物件
2. 按照定義好的ID，週期，DLC，向被測ECU傳送報文
3. 執行for迴圈，對所有ID執行四次掉線，時長分別為：T1，T2，T3，T4，並分別讀取故障、核對故障、清除故障

LabView和CANoe之間，可以通過軟體之間的呼叫關係來挖出，這些引數載CAPL中以變數形式存在，可以充分挖掘CAPL高階功能。可以把CAPL做出標準化功能模組，用LabView靈活呼叫即可。

圖1