汽車C A N總線診斷通信模塊的開發測試

申帥趙恬

（重慶郵電大學 自動化學院，中國 重慶 400065）

0 前言

隨著汽車電子技術的飛速發展，越來越多的電子器件應用到車輛內部，極大的提高了車輛的安全性、可靠性和舒適性。同時也帶來了新的問題，車身線束增多、車輛故障診斷困難增加[1]。為了減少車身線束、提高通信速率，車載總線技術應運而生。

CAN總線以其在高實時性、可靠性和抗干擾能力等方面的優勢，成為當前應用最為廣泛的車載總線技術之一。本文遵循國際診斷標準ISO 15765完成診斷通信模塊的開發，實現過程采取分層模塊化設計，提高通信模塊的通用性、重用性。

1 ISO 15765診斷協議體系

ISO 15765是2000年歐洲汽車廠商推出一種基于CAN總線的診斷系統通信標準，目前ISO 15765標準已被多數整車廠商采用，成為汽車行業的通用診斷標準[2]。ISO 15765根據開放系統互連（Open System Interconnection,OSI）7層參考模型，采用分層思想模塊化設計的方式，各模塊負責處理各自功能并提供標準接口[4]，各模塊間通過接口調用實現通信，以減低模塊間耦合度，增強協議棧的通用性和可靠性。

ISO 15765-3以ISO 14229為基礎定義診斷協議棧應用層的內容，對應于OSI模型應用層，主要包括應用層診斷服務格式、應用層接口、應用層時間參數等信息。ISO 15765-2定義了診斷協議棧網絡層的內容，對應于OSI模型網絡層和傳輸層，包括了網絡層單幀、多幀傳輸機制，以及多幀傳輸過程中的流控制、時間處理、錯誤處理等內容。

2 通信模塊的開發

網絡層的實現是整個通信模塊的主要內容[3]，其核心是多幀傳輸機制中ECU內部的狀態轉換、時間管理以及錯誤處理。

2.1 網絡層多幀傳輸機制

CAN總線數據傳輸以CAN數據幀為基本數據單元，每一個CAN數據幀最多可傳送8個字節的數據，而完成汽車診斷功能需要傳輸的數據往往大于8個字節，因此需要采用多幀傳輸機制。ISO 15765-2定義了4種網絡層協議數據單元N_PDU以完成單幀或多幀的數據傳輸，4種幀類型通過N_PCI（網絡層協議控制信息）區分[4]。其定義格式如表1所示：

表1 CAN總線報文格式定義

不同的幀類型由N_PCI第一個字節的高四位區別，N_PCItype的值0、1、2、3分別代表了單幀、第一幀、連續幀和后續幀。流控幀FS為流狀態參數，BS為連續幀塊大小，STmin為連續幀發送的最小時間間隔。

在多幀傳輸的過程中，網絡層的內部操作為解決對等實體間的數據同步通信問題，采用了數據傳輸流控制方法，通過流控幀實現對通信雙方的管理，是發送端適應接收端網絡層的接受能力。其傳輸過程如圖1所示：

圖1 多幀傳輸過程

2.2 狀態轉換機制

為了實現網絡層多幀傳輸機制的復雜邏輯，在程序編寫過程中設計狀態機，用枚舉類型定義了數據傳輸過程中ECU網絡層在某一時刻的所有可能狀態。

數據傳輸過程中ECU處理不同類型被定義為不同的外部事件，ECU在不同的狀態下將處理不同的CAN幀。ECU網絡層狀態定義是收斂的，因此在某一時刻一定會處于所有狀態中的其中一個，保證能夠對所有類型CAN幀都能夠響應；且ECU網絡層狀態是正交的，不會對同一類型CAN幀重復處理。

此外ECU根據當前網絡層狀態，對所收到的CAN幀處理，不僅取決于接收到的幀類型，還取決于不同幀類型的相對收發順序。當ECU網絡層處于某一狀態收到相應幀類型，且滿足特定的條件時，才能處理相應CAN幀并完成ECU狀態轉換。

2.3 時間管理

網絡層時間管理主要是超時處理和延時發送功能。ISO 15765定義的網絡層時間參數有 N_As，N_Bs，N_Ar，N_Br和 N_Cr。 超時處理通過對時間參數的控制，防止通信雙方中的一方因為潛在錯誤掛起時，另一方持續等待從而失去通信能力。延時發送功能用于多幀傳輸過程中連續多條后續幀的發送，連續兩條后續幀之間的發送間隔必須大于ISO 15765定義的最小時間間隔STmIn。

協議棧時間管理利用ECU的系統時鐘實現，通過配置每1ms產生一次系統中斷，在中斷處理函數中對定義的16位無符號計數器timeoutCounter進行減1操作。在通信過程中每接收或發送一條報文，則會更新計數器為相應時間參數的門限值，在進行下一步操作之前首先判斷計數器是否為0，若為0則說明超時，中斷當前接受或發送進入相應的超時處理。

2.4 錯誤處理

網絡層的錯誤包括了幀格式錯誤、幀參數錯誤。通信雙方必須按照ISO 15765規定的幀格式、幀間邏輯及時間參數收發報文，任何類型的錯誤都將導致當前通信中斷，并進入相應的超時處理。網絡層錯誤類型及處理方式如表2所示：

表2 網絡層錯誤處理描述

3 通信模塊的測試

診斷協議棧的測試采用德國Vector Informatik公司總線工具CANoe及其配套專用診斷測試工具CAN dela Studio、CANoe Option DiVa，作為測試儀。協議棧運行在采用NXP LPC 1768為控制器的開發板，作為下位機。測試儀和下位機通過標準的DB9接口連接，CAN總線的通信速率定義為500Kb/s，物理尋址請求報文ID定義為0x766，功能尋址請求報文ID定義為0x760，響應報文ID定義為0x7A6。

根據診斷需求使用CAN dela Studio配置生成診斷數據庫（CDD文件），將診斷數據庫導入CANoe Option DiVa中自動生成測試用例并通過CANoe運行，如圖2所示。

圖2 通信模塊測試結果

4 結論

測試結果表明，本文所述實現的診斷協議棧符合ISO 15765標準，能夠完成汽車故障診斷功能，且具有較強的可靠性和通用性。并且協議棧各模塊參考AUTOSAR架構設計實現，方便協議棧在不同硬件平臺的移植，具有較強的復用性和可移植性。

［1］郭剛，王勵明，盧明.基于 MVCI、ODX的診斷標準研究[J].制造業自動化，2010，（10）：15-16.

［2］李銳，王晶瑩，姚燕，等.基于ISO 15765的車載CAN網絡診斷設計[J].計算機工程，2012，(4):35-36.

［3］韓鑫，鮑可進.CAN總線網絡層協議棧開發測試[J].計算機工程，2011（08）：232-234.

［4］程安宇，趙國慶，馮輝宗，等.基于CAN總線的電子控制單元功能測試方法[J].計算機應用，2012(1):139-1.