一、背景

在以往的電動(dòng)車型上應(yīng)用層通信協(xié)議基本都是采用了私有協(xié)議，由于是自定義的，故而會(huì)存在諸如規(guī)范性、靈活性不高等問題，比如跟配件廠商進(jìn)行通信時(shí)需要雙方約定好協(xié)議格式等。為了解決這些問題，我們?cè)诮衲觐A(yù)研的新車型項(xiàng)目中嘗試引入了汽車行業(yè)標(biāo)準(zhǔn)的統(tǒng)一診斷服務(wù)協(xié)議UDS（Unified Diagnostic Services）。

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

圖1 三大件底層通信框架

二、UDS協(xié)議介紹

2.1 簡(jiǎn)介

UDS統(tǒng)一診斷服務(wù)協(xié)議（Unified Diagnostic Services）是一套針對(duì)于整車診斷的協(xié)議，標(biāo)準(zhǔn)是ISO-14229，不同于OBD（On-Board Diagnostics）只是針對(duì)排放類的ECU（Electronic Control Unit）的協(xié)議，其可以向整車內(nèi)所有ECU發(fā)送請(qǐng)求數(shù)據(jù)進(jìn)行診斷，比如自動(dòng)變速箱有沒有問題、防抱死系統(tǒng)有沒有問題等。

UDS提供的是一個(gè)診斷服務(wù)的基本框架，使用者如主機(jī)廠和零部件供應(yīng)商可以根據(jù)實(shí)際情況選擇實(shí)現(xiàn)其中的一部分或是自定義出一些私有化的診斷服務(wù)，靈活性很高。從軟件層面上來講，UDS遵循ISO七層模型，屬于是應(yīng)用層的協(xié)議，網(wǎng)絡(luò)層以下支持多種標(biāo)準(zhǔn)協(xié)議，如CAN協(xié)議、IP協(xié)議、LIN總線協(xié)議等，其框架模型如下圖 2 所示。

圖2 UDS協(xié)議框架

2.2 應(yīng)用層服務(wù)說明

應(yīng)用層服務(wù)通常被稱為診斷服務(wù)。應(yīng)用層服務(wù)用于基于客戶端 - 服務(wù)器的系統(tǒng)，以執(zhí)行諸如測(cè)試、檢查、監(jiān)控或診斷車載車輛服務(wù)器等功能。通常被稱為外部測(cè)試設(shè)備的客戶端使用應(yīng)用層服務(wù)來請(qǐng)求在一個(gè)或多個(gè)服務(wù)器中執(zhí)行診斷功能。

服務(wù)器通常是 ECU 的一部分，它使用應(yīng)用層服務(wù)將請(qǐng)求的診斷服務(wù)提供的響應(yīng)數(shù)據(jù)發(fā)送回客戶端。 客戶端通常是板外測(cè)試器，但在某些系統(tǒng)中也可以是板上測(cè)試器。 應(yīng)用層服務(wù)的使用與作為板外或板上測(cè)試器的客戶端無關(guān)。

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

圖3 服務(wù)格式

其中 type 類型共有六種，分別是請(qǐng)求Request、指示Indication、應(yīng)答Response、確認(rèn)Confirm、請(qǐng)求確認(rèn)Req_confirm、應(yīng)答確認(rèn)Res_confirm。每種服務(wù)原語類型格式都遵循上述服務(wù)格式，所帶參數(shù)基本雷同，如Request請(qǐng)求實(shí)際格式所帶參數(shù)如下圖4所示。

圖4 請(qǐng)求服務(wù)原語格式

其中參數(shù)A_Mtype代表是診斷類型還是遠(yuǎn)程診斷類型；A_SA代表源地址，記錄發(fā)起請(qǐng)求的一方地址信息；A_TA代表目的地址，表明接收者是誰；A_TA_type代表地址類型是物理功能還是通用功能；A_AE代表擴(kuò)展地址，可選；A_Length代表請(qǐng)求數(shù)據(jù)的長(zhǎng)度；A_Data代表的是具體的請(qǐng)求數(shù)據(jù)內(nèi)容。

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

圖5 26類具體服務(wù)名

有了上述所介紹的服務(wù)以及服務(wù)格式之后，具像化到軟件程序代碼層面上來實(shí)現(xiàn)時(shí)是

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

1、SID（內(nèi)容僅有SID，即服務(wù)ID，也就是上面26類具體服務(wù)的ID，如ECUReset

是0x11）

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

3、SID+DID（DID代表Data Identifer，即身份標(biāo)識(shí)，每個(gè)DID定義既可以使用UDS提供的固定代表值，如0xF18A代表系統(tǒng)供應(yīng)商名稱，也可以由各類車輛廠商自定義）

4、SID+SF+DID

客戶端或者服務(wù)器收到請(qǐng)求語句后UDS也提供了兩種對(duì)應(yīng)的響應(yīng)語句格式，如下：

1、積極響應(yīng)：請(qǐng)求語句其余內(nèi)容不變，只有SID變成了SID加上64后的值

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

UDS的請(qǐng)求語句內(nèi)容A_Data組裝填充好后變成了A_PDU（A代表應(yīng)用層的縮寫、PDU是Payload Data Unit），之后由實(shí)際的網(wǎng)絡(luò)層采用的通信協(xié)議進(jìn)行數(shù)據(jù)再次組裝后進(jìn)行傳輸，完成通信的功能，其通信模型按照七層ISO模型來說如下圖6所示。

圖6 UDS 通信模型

2.3 特點(diǎn)歸納

1、協(xié)議標(biāo)準(zhǔn)化，眾多車輛廠商共同遵循，無縫接入。 2、協(xié)議靈活性高，可擴(kuò)展性強(qiáng)，UDS除了定義好基本包含常用功能的協(xié)議框架外，還預(yù)留了許多字段可供廠商自定義。 3、協(xié)議兼容性好，UDS定義了一套通用應(yīng)用服務(wù)格式，網(wǎng)絡(luò)層下可以支持多種標(biāo)準(zhǔn)通信協(xié)議作為實(shí)際數(shù)據(jù)傳輸載體。

那UDS請(qǐng)求數(shù)據(jù)到達(dá)網(wǎng)絡(luò)層之后又是怎么再次組裝數(shù)據(jù)的呢？怎么提供數(shù)據(jù)的單幀、多幀的格式定義呢？這就是接下來要介紹的新項(xiàng)目中采用的標(biāo)準(zhǔn)CAN協(xié)議。

三、CAN協(xié)議介紹

CAN協(xié)議是控制器局域網(wǎng)總線的簡(jiǎn)稱，是一種用于實(shí)時(shí)應(yīng)用的串行通訊協(xié)議總線，它可以使用雙絞線來傳輸信號(hào)，是世界上應(yīng)用最廣泛的現(xiàn)場(chǎng)總線之一，常應(yīng)用于汽車電子各部件間通信、工業(yè)領(lǐng)域等。

其標(biāo)準(zhǔn)主要有CAN2.0A和CAN2.0B兩部分，A標(biāo)準(zhǔn)主要描述標(biāo)準(zhǔn)幀格式，B主要描述擴(kuò)展幀格式。實(shí)際物理層中采用兩根線（CAN_H，CAN_L）之間的差分信號(hào)進(jìn)行傳輸數(shù)據(jù)，抗干擾能力強(qiáng)，容錯(cuò)能力也強(qiáng)，速率可達(dá)1Mbps（通信距離小于40M）。其物理層定義和兩種協(xié)議幀格式如下圖7和圖8所示：

圖7 CAN協(xié)議物理層定義

圖8 CAN協(xié)議兩種幀格式定義

上述物理信號(hào)中邏輯 0 代表顯性信號(hào)，優(yōu)先級(jí)最高，1 代表隱性信號(hào)，優(yōu)先級(jí)最低。數(shù)據(jù)幀中格式一般由 7 個(gè)段組成，分別是幀起始、仲裁段、控制段、數(shù)據(jù)段、CRC段、ACK段、幀結(jié)束。單幀最多能傳輸8個(gè)字節(jié)數(shù)據(jù)。

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

圖9 N_PDU格式

幀類型說明如下：

單幀：當(dāng)N_PCItype = 0時(shí)，表示此幀為單幀SF，SF_DL為此次單包傳輸?shù)臄?shù)據(jù)量，最大6字節(jié)。

首幀：當(dāng)N_PCItype = 1時(shí)，表示此幀為多幀數(shù)據(jù)中的首幀F(xiàn)F，F(xiàn)F_DL為此次多幀傳輸?shù)臄?shù)據(jù)量，F(xiàn)F_DL的最大值為4095。

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

流控幀：當(dāng)N_PCItype = 3時(shí)，表示此幀為流控幀F(xiàn)C，F(xiàn)S為數(shù)據(jù)流傳輸?shù)臓顟B(tài)信息，BS為接收方發(fā)送流控幀的間隔（以CF幀為單位），ST為發(fā)送方間隔發(fā)送序列幀的時(shí)間間隔。具體值代表如下圖10所示：

圖10 流控幀參數(shù)定義

其中單幀數(shù)據(jù)發(fā)送很簡(jiǎn)單，每幀發(fā)即可，多幀數(shù)據(jù)發(fā)送流程如下圖11所示：

圖11 多幀數(shù)據(jù)發(fā)送流程

簡(jiǎn)單來說，多幀發(fā)送數(shù)據(jù)流程就是：

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

通過上述二、三章節(jié)從應(yīng)用層到網(wǎng)絡(luò)層即自上而下的介紹完所用的UDS服務(wù)協(xié)議框架后，接下來介紹下基于此服務(wù)協(xié)議框架實(shí)現(xiàn)的具體軟件SDK（Software Development Kit，即軟件開發(fā)工具包）功能。

四、UDS SDK介紹

4.1SDK簡(jiǎn)介

UDS SDK設(shè)計(jì)的目的除了是引入汽車行業(yè)標(biāo)準(zhǔn)UDS服務(wù)協(xié)議以外，還為了避免重復(fù)造輪子，減少開發(fā)人力，提高效率。因?yàn)槟壳靶马?xiàng)目中的三大件VCU、MC、BMS都采用了UDS協(xié)議，那么就都可以通過此SDK接入，完成UDS協(xié)議的使用，理論上新項(xiàng)目中其余采用底層CAN通信的配件都可以采用此SDK完成UDS協(xié)議的通信交互。

本SDK在實(shí)現(xiàn)之前參考學(xué)習(xí)了一些通用的規(guī)范，如變量、函數(shù)和文件命名采用Linux小寫風(fēng)格還是大駝峰等風(fēng)格，因?yàn)閁DS協(xié)議里定義的一些變量名和服務(wù)名都是大駝峰，所以本SDK為了一致，在實(shí)現(xiàn)上也統(tǒng)一采用了大駝峰風(fēng)格；從軟件分層方面來說，主要考慮易用、易理解、高內(nèi)聚低耦合以及為了能遷移不同平臺(tái)等原則，采用了嵌入式系統(tǒng)里常用的三層結(jié)構(gòu)，自上而下分別是應(yīng)用層、網(wǎng)絡(luò)層、硬件移植層，層級(jí)結(jié)構(gòu)如下圖12所示。

圖12 UDS SDK軟件框架

應(yīng)用層：

1、此層主要映射實(shí)現(xiàn)的就是上述第二章節(jié)介紹的UDS協(xié)議里的所有服務(wù)功能

2、負(fù)責(zé)對(duì)網(wǎng)絡(luò)層第一次解析后透?jìng)鬟^來的UDS數(shù)據(jù)進(jìn)行再次解析

3、數(shù)據(jù)解析后負(fù)責(zé)調(diào)用對(duì)應(yīng)的UDS服務(wù)、完成具體應(yīng)用功能

4、按照規(guī)范實(shí)現(xiàn)對(duì)外的API（Application Programming Interface）供SDK使用者使用，完成SDK的運(yùn)轉(zhuǎn)

網(wǎng)絡(luò)層：

1、此層映射的就是上述第三章節(jié)介紹的CAN協(xié)議，主要實(shí)現(xiàn)協(xié)議的單幀、多幀數(shù)據(jù)的相關(guān)處理

2、負(fù)責(zé)對(duì)硬件底層收到的數(shù)據(jù)按照ISO-15765-2協(xié)議標(biāo)準(zhǔn)進(jìn)行解析以及對(duì)應(yīng)用層傳遞過來的UDS數(shù)據(jù)協(xié)議進(jìn)行組裝處理并傳遞到硬件底層進(jìn)行數(shù)據(jù)傳輸

3、負(fù)責(zé)底層數(shù)據(jù)解析后按照ISO-15765-2協(xié)議進(jìn)行數(shù)據(jù)往上層應(yīng)用層通知及回復(fù)發(fā)送者等交互邏輯

4、數(shù)據(jù)異常處理，包括超時(shí)、協(xié)議格式錯(cuò)誤、數(shù)據(jù)長(zhǎng)度錯(cuò)誤等

硬件層：

1、此層主要是為了實(shí)現(xiàn)SDK的平臺(tái)兼容性，可以遷移不同平臺(tái)環(huán)境而約定好的一些功能接口

2、需要各SDK使用者針對(duì)使用的平臺(tái)環(huán)境如單片機(jī)MCU（Microcontroller Unit）類型進(jìn)行移植實(shí)現(xiàn)

3、主要有CAN的初始化、反初始化、發(fā)送數(shù)據(jù)、接收數(shù)據(jù)、1ms頻率的定時(shí)計(jì)數(shù)、操作系統(tǒng)平臺(tái)統(tǒng)一接口CMSIS（Cortex Microcontroller Software Interface Standard）的實(shí)現(xiàn)，主要有任務(wù)創(chuàng)建、互斥鎖等

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

圖13 SDK代碼目錄結(jié)構(gòu)說明

所以SDK的使用上也比較簡(jiǎn)單，使用者先配置自身的使用環(huán)境，之后再移植實(shí)現(xiàn)硬件層SDK要求的對(duì)應(yīng)功能，最后就是重寫實(shí)現(xiàn)具體使用的UDS服務(wù)功能即可。

SDK的主要特點(diǎn)：

1、支持標(biāo)準(zhǔn)UDS協(xié)議解析（ISO-14229）

2、支持單幀及多幀數(shù)據(jù)協(xié)議（ISO15765-2）

3、支持隊(duì)列循環(huán)處理及數(shù)據(jù)異常處理

4、支持CAN標(biāo)準(zhǔn)幀協(xié)議

5、支持裸機(jī)和RTOS環(huán)境

6、支持遷移不同嵌入式平臺(tái)，只需移植對(duì)應(yīng)的硬件層功能

2.SDK落地

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

五、結(jié)語

本文主要是介紹了新車型項(xiàng)目中首次引入的汽車行業(yè)標(biāo)準(zhǔn)中的UDS服務(wù)協(xié)議，從UDS的協(xié)議框架中自上而下的從應(yīng)用層到網(wǎng)絡(luò)層支持的協(xié)議之一CAN協(xié)議整體介紹了何為UDS協(xié)議以及在實(shí)際中的使用。相信隨著此次新項(xiàng)目的首次嘗試，未來我們兩輪車自研能力會(huì)越來越強(qiáng)，標(biāo)準(zhǔn)會(huì)越來越趨于國(guó)標(biāo)，引領(lǐng)行業(yè)。

審核編輯：湯梓紅