施春華
(同濟大學,上海 200092)
汽車作為一款機電一體化的設備,目前正在向智能化、網聯化快速發展,而其中汽車網絡的發展也是越來越快。其中CAN總線是被最廣泛使用的汽車總線,近幾十年來市場的占有率越來越高,但是因為CAN協議的特性,最多只能達到500kbit/s,限制了網絡通信速度的進一步提高,這一情況催生出了在CAN總線物理設備的基礎上,使用可變速率CAN通信的方式即CAN FD(CAN With Flexible Data-Rate)的出現。
汽車診斷的協議可以在不同的總線技術上實現,每一次汽車總線變革都會要求診斷協議進行相應的匹配。雖然支持CAN FD的車型以及產品越來越多,但是對于診斷在CAN FD總線上的實際使用,目前的研究還比較少。如:劉樂樂研究了在CAN FD總線的基礎上,通過使用CANoe軟件設計基于UDS協議的刷新系統,實現Bootloader的刷寫過程;PARK P Y開發了一套基于CAN FD的刷新設備以及網關,可實現CAN FD總線與CAN總線的切換,提高數據刷寫效率;TH Nguyen研究了CAN FD網絡的數據場結構,通過CANoe的模擬實現了CAN FD和CAN網絡的ECU刷新時間比較,說明支持CAN FD總線的優勢。
本文介紹在CAN FD網絡的基礎上,實現通用的UDS診斷協議,開發部分相關的測試功能,并在試驗臺架上進行通信診斷功能的驗證。
CAN FD為BOSCH公司在2012年推出的基于原有CAN總線物理層的高速通信技術。CAN FD在基本不改變物理設備硬件要求的基礎上實現部分數據的可變速率傳輸。通過CAN FD網絡傳輸的速率可達5Mbit/s,CAN FD總線與其他總線比較,在實現高速通信的前提下,可以運行在現有的CAN總線物理設備上,降低了硬件更新換代的費用,并適配目前大量使用的CAN總線物理設備場景,是下一代汽車總線技術的有力競爭者。
CAN FD實現可變速率傳輸的關鍵,在于數據幀中的不同部分實行兩種傳輸速度。與CAN一樣,CAN FD數據幀包括7個部分:幀起始、仲裁域、控制域、數據域、檢驗域、應答域、幀結束。以CAN擴展幀為例,圖1比較了CAN FD與CAN擴展幀的區別,CAN標準幀也是同樣的情況,CAN FD增加了一些標志位、更大數據域和校驗位。

圖1 CAN FD與CAN擴展幀報文結構比較
CAN FD幀結構與CAN比較,區別在以下幾個方面。
1)CAN FD替換增加了新的標志位。CAN FD幀起始和CAN一樣為一個顯性位(0),之后仲裁場中的Identifier和擴展ID保持不變,RTR位變更為RRS位(遠程請求取代位),總是顯性,因為CAN FD不支持remote frame遠程幀。控制場中,FDF(FD Format Indicator)位用于標識幀類型,FDF隱性標識幀為CAN FD幀;顯性則標識為CAN幀。增加了BRS(位速率轉換位),用于標識CAN FD的速率切換,只有在隱性時進行切換,顯性保持原有速率;ESI(錯誤狀態知識)位,主動錯誤節點為顯性,被動錯誤節點為隱性。
2)CAN FD支持兩種速率傳輸。當BRS位為1(隱性)時,從BRS位后到CRC界定符為止,采取數據段速率;其余位仍采取標準速率。兩種速率采取不同的時間定義寄存器,時間定義tQ。
3)CAN FD支持更高的帶寬。CAN FD數據域擴充到了64個字節,與CAN的8字節比較擴大了8倍,通過控制域中的DLC(數據長度控制)編碼方式的擴展實現。DLC的編碼方式1~8個字節同CAN,出現大于8個字節的數據場即9~64字節,編碼方式為非線性增長,見表1。對于CAN FD擴展的字節容量,分別為8,12,16,20,24,32,48以及64。

表1 CAN FD DLC編碼
4)檢驗域CRC計算方式擴展。CAN總線CRC檢驗域采用CRC_15,CAN FD增加了CRC_17,用于小于等于16字節的數據長度;CRC_21用于小于等于64的數據長度。其多項式定義見表2。

表2 CRC校驗多項式定義
對于診斷,CAN FD同CAN總線,在傳輸層定義了4種幀格式,即Single Frame、First Frame、Consecutive Frame、Flow Control。數據發送方式也與CAN類似,對于數據容量滿足單幀的數據直接發送;對于數據容量超過單幀承載能力的數據,按照協議進行分割重組,然后進行多幀的傳遞方式。CAN FD數據傳輸方式見圖2。

圖2 CAN FD數據傳輸方式
與CAN總線不同的是因為CAN FD幀數據承載量變大,對于Single Frame和First Frame的SF_DL和FF_DL進行了擴展,見表3。為了適應數據容量的增加,紅色圈出部分為CAN FD新增加的PCI定義。

表3 CAN FD N PCI信息
2006年ISO組織發布了ISO 14229標準UDS(Unified Diagnostic Services),不依賴于任何實際的總線技術,單獨定義的通用診斷服務標準。此協議獨立于具體的汽車總線之外,構建了應用層的診斷服務和標準。ISO 14229-1描述應用層的服務內容;ISO 14229-2描述會話層,對于診斷時間參數進行定義;其余部分為UDS協議在不同總線上的使用。針對于診斷在CAN上的使用,ISO發布了ISO 15765,其中ISO 15765-2在2015年增加CAN FD的網絡和傳輸層的內容,ISO 15765-3為UDS在CAN網絡上的使用。UDS診斷可以實現如下功能:模塊故障碼DTC讀取;模塊存儲信息(Data ID)讀取;模塊內存數據的上傳下載;模塊安全等級切換,I/O功能激活;診斷路由控制以及刷新模塊軟件或軟件下載等。
UDS協議通過請求-響應(C-S)模式實現診斷過程。外接測試設備作為客戶端對于服務器端模塊提出請求Request,模塊根據服務請求情況給出響應Response,見圖3。一般情況下請求響應應當成對出現,即客戶端提出請求時,服務器端應該給出回應,但UDS為了提高網絡傳輸效率,還定義了一種特殊情況,即服務Service ID的子服務最高位為響應抑制位(suppressPosRspMsgIndicationBit),當其值為1時,則服務器端無需給出響應答復。

圖3 UDS請求-響應模式
在CAN或者CAN FD總線上,總線的模塊都可以收到客戶端外接檢測設備發出的診斷報文。對于目標診斷模塊,UDS定義了兩種尋址方式,功能尋址和物理尋址。功能尋址為服務器端設備在總線上發出尋址ID,總線上一個或者多個模塊給出響應;物理尋址為服務器端設備對于某個固定的ECU ID請求診斷,固定模塊給出響應。兩種尋址幀的報文結構見圖4。

圖4 UDS服務請求、響應格式
UDS的 診 斷 報 文 請 求 格 式 為SID (+Sub function)+Parameter,SID為UDS定義的26種功能服務;Sub function為服務子功能,作為報文的可選項補充說明診斷服務的內容;Parameter為診斷參數。其中子服務的響應抑制位可以定義服務是否請求服務器端的反饋響應。
響應分為兩種情況,第1種為肯定響應即服務器端接受了服務內容,標志為請求服務Service ID+0x40以及診斷反饋參數;第2種為否定響應,否定響應服務的Service ID為0x7F,標識服務器端拒絕了響應請求,并給出否定響應的原因即反饋碼。
UDS協議定義的26種服務SID見表4:可以分為6個大類,分別為數據上傳下載、模塊內置程序函數調用、總線通信管理、輸入輸出信號控制、DTC處理、數據傳輸。

表4 ISO 14229 UDS服務Service ID
CAN FD部分診斷系統主要由3部分組成,分別為診斷應用模塊、數據處理模塊、數據通信模塊。使用Microsoft Visual Studio作為IDE,通過C++進行編寫,支持常用的部分診斷功能。
診斷應用模塊按照UDS協議應用層的定義,生成診斷報文,并解析響應服務內容,診斷應用模塊邏輯見圖5,系統定義結構體UDSSrvTx_SIDXX,通過請求-響應的流程實現診斷應用層的通信。

圖5 診斷應用模塊邏輯圖
數據處理模塊用于生成組織數據報文,對于從診斷模塊收集到的數據進行分段重組,以及對于收到的響應數據報文進行解析。發送流程邏輯見圖6,本模塊通過結構體CANFD_REQUEST_STRUCT定義實現。

圖6 數據處理模塊發送流程邏輯圖
數據處理模塊接收流程見圖7,通過函數CANFD_DATA_CONSTRUCTION實現診斷報文的重組構建。

圖7 數據處理模塊接收流程邏輯圖
通信模塊由兩個數據存儲隊列組成,分別為發送隊列和存儲隊列。工作時通過兩個線程完成數據的發送和接收工作。通信模塊發送接收進程邏輯見圖8,發送線程為主線程,接收線程為次線程。發送線程根據發送隊列中的數據幀PCI信息處理數據幀的發送工作,即單幀直接發送,多幀根據流控幀的要求分步發送。接收線程處理從總線上收到的存儲隊列數據幀,首先判斷是否是反饋給測試設備地址的有效數據,再根據數據幀的類型,把幀信息傳遞給發送線程或者是數據處理模塊。

圖8 通信模塊發送接收進程邏輯圖
檢測系統在為某款車型搭建的測試臺架上進行驗證,網絡拓撲結構見圖9,其中,有部分模塊ECU支持CAN FD通信診斷。

圖9 某款車型支持CAN FD的網絡拓撲圖
測試檢測設備上位機電腦通過VCI卡與車載DLC口相互連接。DLC口定義了支持CAN總線的報文發送針腳等物理媒介,作為整車系統對外通信的媒介,所有的物理信號都會匯集到車輛的中央網關。診斷報文就經由中央網關模塊路由至相應的CAN FD模塊。
測試時,通過第三方軟件記錄總線上的報文,驗證系統的診斷功能。部分測試報文如圖10所示。

圖10 部分測試報文
1)診斷系統通過SID 0x22命令,讀取CAN ID:94DA58F1,DID為0xF0 CD的數據。以0x03標識CAN FD單幀,封裝3個字節的診斷指令,其余部分以0x55填充。
2)模塊反饋時因為數據量較大,首先反饋First Frame,以0x10標識,0xED標識傳遞的數據總長度為237。數據起始為SID的肯定響應0x22+0x40=0x62,DID的echo 0xF0 CD以及DID部分數據信息。
3)診斷系統發送流控幀0x30 00 00,FS為0x00同意接收連續幀,并以STmin 0x00標識以默認的時間間隔接收連續幀。
4)連續幀的第1幀以0x21標識,后接部分DID數據內容。
5)連續幀第2幀以0x22標識,后接部分DID數據內容。
6)連續幀第3幀以0x23標識,后接部分DID數據內容。雖然連續第3幀中不需要占滿64字節的數據量就可以傳遞完237字節的全部數據,但因為CAN FD數據場的大小為固定的幾個可選值,所以64字節的數據場多余部分填充0x00組成完整的CAN FD數據幀。
測試驗證了CAN FD系統的部分診斷功能,按照預先設計的流程,從支持CAN FD功能的模塊上讀取了相關診斷參數,實現了基于CAN FD的UDS診斷通信。
CAN FD網絡實現了在原有CAN物理設備基礎上,進行更高速的數據通信,而CAN FD結合ISO標準的通用診斷協議UDS的使用,是汽車診斷領域重要的研究課題。本文以CAN FD網絡通信以及UDS診斷協議為理論基礎,比較了CAN FD為實現高速診斷的幀結構變更內容以及編碼形式的更新;同時對UDS診斷實現的流程進行了闡述,并對診斷服務進行了說明。本文開發了一套在CAN FD網絡中,使用UDS診斷協議進行診斷通信的系統,支持部分常用的診斷功能,使用時結合系統的其他硬件,對診斷功能進行了臺架測試驗證。系統也為支持CAN FD完整UDS診斷的開發提供了擴展可能,可以在工程實踐中進一步完善更新。