一、背景

在以往的電動車型上應用層通信協議基本都是采用了私有協議，由于是自定義的，故而會存在諸如規范性、靈活性不高等問題，比如跟配件廠商進行通信時需要雙方約定好協議格式等。為了解決這些問題，我們在今年預研的新車型項目中嘗試引入了汽車行業標準的統一診斷服務協議UDS（Unified Diagnostic Services）。

新車型主要有三大核心部件，如整車控制器VCU（Vehicle Control Unit）、電機控制器MC（Motor Control）、電池管理系統BMS（Battery Management System）。三者之間底層通信沿用舊車型上采用的標準控制器局域網總線CAN（Controller Area Network）協議，如下圖1所示。下面介紹下什么是UDS協議以及根據此協議編寫的軟件SDK，供VCU、MC、BMS使用，避免重復造輪子。

圖1 三大件底層通信框架

二、UDS協議介紹

2.1 簡介

UDS統一診斷服務協議（Unified Diagnostic Services）是一套針對于整車診斷的協議，標準是ISO-14229，不同于OBD（On-Board Diagnostics）只是針對排放類的ECU（Electronic Control Unit）的協議，其可以向整車內所有ECU發送請求數據進行診斷，比如自動變速箱有沒有問題、防抱死系統有沒有問題等。

UDS提供的是一個診斷服務的基本框架，使用者如主機廠和零部件供應商可以根據實際情況選擇實現其中的一部分或是自定義出一些私有化的診斷服務，靈活性很高。從軟件層面上來講，UDS遵循ISO七層模型，屬于是應用層的協議，網絡層以下支持多種標準協議，如CAN協議、IP協議、LIN總線協議等，其框架模型如下圖 2 所示。

圖2 UDS協議框架

2.2 應用層服務說明

應用層服務通常被稱為診斷服務。應用層服務用于基于客戶端 - 服務器的系統，以執行諸如測試、檢查、監控或診斷車載車輛服務器等功能。通常被稱為外部測試設備的客戶端使用應用層服務來請求在一個或多個服務器中執行診斷功能。

服務器通常是 ECU 的一部分，它使用應用層服務將請求的診斷服務提供的響應數據發送回客戶端。 客戶端通常是板外測試器，但在某些系統中也可以是板上測試器。 應用層服務的使用與作為板外或板上測試器的客戶端無關。

通過上面2.1小節的介紹，可以知道 UDS 只是一套協議規范，網絡層以下可以支持多種不同類型的協議，那么它是怎么做到的呢？方法就是UDS定義了一種通用的服務格式，屬于描述性語言，所有應用層服務都采用了這種格式，具體如下圖3所示。

圖3 服務格式

其中 type 類型共有六種，分別是請求Request、指示Indication、應答Response、確認Confirm、請求確認Req_confirm、應答確認Res_confirm。每種服務原語類型格式都遵循上述服務格式，所帶參數基本雷同，如Request請求實際格式所帶參數如下圖4所示。

圖4 請求服務原語格式

其中參數A_Mtype代表是診斷類型還是遠程診斷類型；A_SA代表源地址，記錄發起請求的一方地址信息；A_TA代表目的地址，表明接收者是誰；A_TA_type代表地址類型是物理功能還是通用功能；A_AE代表擴展地址，可選；A_Length代表請求數據的長度；A_Data代表的是具體的請求數據內容。

那實際中UDS提供了什么樣的診斷協議框架呢？從軟件層面上來說，UDS提供了6大類共26類服務協議框架，基本包含了眾多車輛廠商需要使用的功能，分別是診斷和通信管理功能單元、數據傳輸功能單元、存儲數據傳輸功能單元、控制功能單元、常規功能單元、上傳下載功能單元。26類服務中每種具體的服務功能如下圖5所示。

圖5 26類具體服務名

有了上述所介紹的服務以及服務格式之后，具像化到軟件程序代碼層面上來實現時是

怎么樣的呢？也就是上述介紹的服務格式里的A_Data內容格式是怎么樣的呢？拿請求Request類來說（其它服務原語相似），UDS提供了四種原型語句，如下：

1、SID（內容僅有SID，即服務ID，也就是上面26類具體服務的ID，如ECUReset

是0x11）

2、SID+SF（SF代表子函數，即每一類服務里面再細分的功能定義）

3、SID+DID（DID代表Data Identifer，即身份標識，每個DID定義既可以使用UDS提供的固定代表值，如0xF18A代表系統供應商名稱，也可以由各類車輛廠商自定義）

4、SID+SF+DID

客戶端或者服務器收到請求語句后UDS也提供了兩種對應的響應語句格式，如下：

1、積極響應：請求語句其余內容不變，只有SID變成了SID加上64后的值

2、否定響應：固定格式為0x7F+SID+NRC（NRC代表否定代碼，UDS定義了通用的否定代碼供使用者使用）

UDS的請求語句內容A_Data組裝填充好后變成了A_PDU（A代表應用層的縮寫、PDU是Payload Data Unit），之后由實際的網絡層采用的通信協議進行數據再次組裝后進行傳輸，完成通信的功能，其通信模型按照七層ISO模型來說如下圖6所示。

圖6 UDS 通信模型

2.3 特點歸納

1、協議標準化，眾多車輛廠商共同遵循，無縫接入。 2、協議靈活性高，可擴展性強，UDS除了定義好基本包含常用功能的協議框架外，還預留了許多字段可供廠商自定義。 3、協議兼容性好，UDS定義了一套通用應用服務格式，網絡層下可以支持多種標準通信協議作為實際數據傳輸載體。

那UDS請求數據到達網絡層之后又是怎么再次組裝數據的呢？怎么提供數據的單幀、多幀的格式定義呢？這就是接下來要介紹的新項目中采用的標準CAN協議。

三、CAN協議介紹

CAN協議是控制器局域網總線的簡稱，是一種用于實時應用的串行通訊協議總線，它可以使用雙絞線來傳輸信號，是世界上應用最廣泛的現場總線之一，常應用于汽車電子各部件間通信、工業領域等。

其標準主要有CAN2.0A和CAN2.0B兩部分，A標準主要描述標準幀格式，B主要描述擴展幀格式。實際物理層中采用兩根線（CAN_H，CAN_L）之間的差分信號進行傳輸數據，抗干擾能力強，容錯能力也強，速率可達1Mbps（通信距離小于40M）。其物理層定義和兩種協議幀格式如下圖7和圖8所示：

圖7 CAN協議物理層定義

圖8 CAN協議兩種幀格式定義

上述物理信號中邏輯 0 代表顯性信號，優先級最高，1 代表隱性信號，優先級最低。數據幀中格式一般由 7 個段組成，分別是幀起始、仲裁段、控制段、數據段、CRC段、ACK段、幀結束。單幀最多能傳輸8個字節數據。

CAN協議標準較多，其中新項目中采用的是ISO-15765，文檔定義了數據傳輸（單幀和多幀）的標準，所有數據域（即上圖8里的Data段）格式命名為N_PDU（N代表網絡層縮寫，PDU同A_PDU），有三部分組成，第一部分是N_AI（地址信息，類型包括目的地址、源地址等，大部分是目的地址，例如寶馬車系統上就是目的地址），N_PCI（協議控制信息，一般集中在前三個字節里，此部分就是定義了數據是單幀還是多幀），N_Data（數據域，使用者自己定義的），如下圖9所示：

圖9 N_PDU格式

幀類型說明如下：

單幀：當N_PCItype = 0時，表示此幀為單幀SF，SF_DL為此次單包傳輸的數據量，最大6字節。

首幀：當N_PCItype = 1時，表示此幀為多幀數據中的首幀FF，FF_DL為此次多幀傳輸的數據量，FF_DL的最大值為4095。

連續幀：當N_PCItype = 2時，表示此幀為多幀數據中的連續幀CF，也叫序列幀，SN為序列幀的計數，用于數據的有序傳輸，第一次發送SN的值為1（即多幀的第二幀起始值就是固定的0x21），當SN的值溢出時，SN從0開始計數。

流控幀：當N_PCItype = 3時，表示此幀為流控幀FC，FS為數據流傳輸的狀態信息，BS為接收方發送流控幀的間隔（以CF幀為單位），ST為發送方間隔發送序列幀的時間間隔。具體值代表如下圖10所示：

圖10 流控幀參數定義

其中單幀數據發送很簡單，每幀發即可，多幀數據發送流程如下圖11所示：

圖11 多幀數據發送流程

簡單來說，多幀發送數據流程就是：

1、發送方先發送首幀(FF)，告訴對方我要發送FF_DL長度的數據及N-2字節的數據
2、接收方收到首幀后，發送流控幀（FC），告訴發送方流控的狀態（FS）以及接收數據的能力（ST）和下一次發送流控幀的間隔（BS）
3、發送方接收到流控幀后，就按照ST的時間間隔發送按SN計數的序列幀（CF），每幀序列幀有N-1 字節的數據
4、發送方發送BS數量的序列幀（CF）后，等待流控幀，如果BS等于零，則此步驟省略
5、發送方如果最后發送的序列幀數量小于BS，則不用等待流控幀，傳輸結束

通過上述二、三章節從應用層到網絡層即自上而下的介紹完所用的UDS服務協議框架后，接下來介紹下基于此服務協議框架實現的具體軟件SDK（Software Development Kit，即軟件開發工具包）功能。

四、UDS SDK介紹

4.1SDK簡介

UDS SDK設計的目的除了是引入汽車行業標準UDS服務協議以外，還為了避免重復造輪子，減少開發人力，提高效率。因為目前新項目中的三大件VCU、MC、BMS都采用了UDS協議，那么就都可以通過此SDK接入，完成UDS協議的使用，理論上新項目中其余采用底層CAN通信的配件都可以采用此SDK完成UDS協議的通信交互。

本SDK在實現之前參考學習了一些通用的規范，如變量、函數和文件命名采用Linux小寫風格還是大駝峰等風格，因為UDS協議里定義的一些變量名和服務名都是大駝峰，所以本SDK為了一致，在實現上也統一采用了大駝峰風格；從軟件分層方面來說，主要考慮易用、易理解、高內聚低耦合以及為了能遷移不同平臺等原則，采用了嵌入式系統里常用的三層結構，自上而下分別是應用層、網絡層、硬件移植層，層級結構如下圖12所示。

圖12 UDS SDK軟件框架

應用層：

1、此層主要映射實現的就是上述第二章節介紹的UDS協議里的所有服務功能

2、負責對網絡層第一次解析后透傳過來的UDS數據進行再次解析

3、數據解析后負責調用對應的UDS服務、完成具體應用功能

4、按照規范實現對外的API（Application Programming Interface）供SDK使用者使用，完成SDK的運轉

網絡層：

1、此層映射的就是上述第三章節介紹的CAN協議，主要實現協議的單幀、多幀數據的相關處理

2、負責對硬件底層收到的數據按照ISO-15765-2協議標準進行解析以及對應用層傳遞過來的UDS數據協議進行組裝處理并傳遞到硬件底層進行數據傳輸

3、負責底層數據解析后按照ISO-15765-2協議進行數據往上層應用層通知及回復發送者等交互邏輯

4、數據異常處理，包括超時、協議格式錯誤、數據長度錯誤等

硬件層：

1、此層主要是為了實現SDK的平臺兼容性，可以遷移不同平臺環境而約定好的一些功能接口

2、需要各SDK使用者針對使用的平臺環境如單片機MCU（Microcontroller Unit）類型進行移植實現

3、主要有CAN的初始化、反初始化、發送數據、接收數據、1ms頻率的定時計數、操作系統平臺統一接口CMSIS（Cortex Microcontroller Software Interface Standard）的實現，主要有任務創建、互斥鎖等

本SDK為了使用者使用簡單，見名知義，在軟件代碼層面上提供了使用詳細說明文檔、參考例子、代碼目錄結構以及文件夾命名采用通俗易懂、高內聚低耦合的原則，整體分為五個文件夾、一份說明文檔、一個配置文件，具體如下圖13所示。

圖13 SDK代碼目錄結構說明

所以SDK的使用上也比較簡單，使用者先配置自身的使用環境，之后再移植實現硬件層SDK要求的對應功能，最后就是重寫實現具體使用的UDS服務功能即可。

SDK的主要特點：

1、支持標準UDS協議解析（ISO-14229）

2、支持單幀及多幀數據協議（ISO15765-2）

3、支持隊列循環處理及數據異常處理

4、支持CAN標準幀協議

5、支持裸機和RTOS環境

6、支持遷移不同嵌入式平臺，只需移植對應的硬件層功能

2.SDK落地

目前SDK已落地在預研的新項目中、VCU、MC、BMS三大核心部件都在使用。SDK的版本也在隨著協議的增加而迭代，目前已迭代到V3.0版本。

五、結語

本文主要是介紹了新車型項目中首次引入的汽車行業標準中的UDS服務協議，從UDS的協議框架中自上而下的從應用層到網絡層支持的協議之一CAN協議整體介紹了何為UDS協議以及在實際中的使用。相信隨著此次新項目的首次嘗試，未來我們兩輪車自研能力會越來越強，標準會越來越趨于國標，引領行業。

審核編輯：湯梓紅