0 序言
在之前工作過程中,進(jìn)行測試時,如果單板有故障,習(xí)慣性地會去找軟件同事幫忙讀一下故障碼。很多時候,這個故障碼會提示我的排查方向。如果沒有軟件的診斷支持,我也能一步一步去逼近問題,但效率比較低。
前司的產(chǎn)品,各個模塊都是自研的,所以其故障診斷的邏輯可以自行定制。新的項目里說要加一個診斷功能,只要硬件在設(shè)計上做支持,軟件添加相應(yīng)代碼即可。但對于汽車這種復(fù)雜產(chǎn)品而言,在前期分布式架構(gòu)階段,整車廠更像一個集成商的角色,買各家供應(yīng)商的ECU。行業(yè)只要有分工,就必須要有規(guī)范,這樣才能提高生產(chǎn)效率,實現(xiàn)收益最大化。于是,各家遵循統(tǒng)一的診斷標(biāo)準(zhǔn)就是必然的事。即使后期EEA發(fā)展成中央集成架構(gòu),OEM自己研發(fā)所有的控制器,這種診斷標(biāo)準(zhǔn)應(yīng)該也會沿襲下來。
越是復(fù)雜的系統(tǒng)越是需要完善的故障診斷系統(tǒng),否則問題定位的代價會很大,售后成本會很高。此外,智能化是汽車的發(fā)展趨勢之一,智能化的本質(zhì)就是將人做的是交給車自己來做。人根據(jù)五官收集的信息做出綜合判斷,然后進(jìn)行相關(guān)操作。如果要車去做決策,首先就需要讓車能夠獲得足夠多的信息。自動駕駛的感知和定位模塊,是車對外界環(huán)境的感知。另一方面,車還需要對自身內(nèi)部有足夠強(qiáng)的感知能力,那就需要有監(jiān)測和診斷系統(tǒng)。如果一個傳感器或執(zhí)行器損壞了,而系統(tǒng)不自知,那么這是一個不穩(wěn)定的開環(huán)系統(tǒng),遲早要翻車。另外,根據(jù)我個人的感受,一個產(chǎn)品的診斷系統(tǒng)做得是否完善,很大程度上反應(yīng)了這個產(chǎn)品的成熟度。因為只有一個產(chǎn)品的其他主要功能都搞好了,穩(wěn)定了,工程師們可能才會有余力著重去提升產(chǎn)品的其他部分。
? 1 UDS概述
說到車的診斷,就要引出今天的主角,即UDS協(xié)議。UDS(Unified Diagnostic Services)是ISO 14229定義的一種汽車通用診斷協(xié)議,位于OSI模型中的應(yīng)用層,它可在不同的汽車總線(如CAN、LIN、Flexray、以太網(wǎng))上實現(xiàn),用于車輛電子系統(tǒng)的故障診斷和通信。它提供了一組標(biāo)準(zhǔn)化的診斷服務(wù),允許診斷工具與車輛的電子控制單元(ECU)進(jìn)行通信,以診斷和解決故障。
說點UDS具體的場景應(yīng)用:
(1)ECU開發(fā)過程要用到它來構(gòu)建bootloader,上傳和下載數(shù)據(jù),即軟件刷寫,控制器Reset;
(2)測試時要用它來讀寫存儲,控制外設(shè);
(3)產(chǎn)線上,要用它來校準(zhǔn)機(jī)械件,控制例程,進(jìn)行下線執(zhí)行器測試,刷新軟件,配置防盜,讀取號碼,下線配置等;
(4)在行駛過程中,要用它來監(jiān)測各種故障,并記下故障碼;
(5)4S店里,技師需要讀取當(dāng)前故障、歷史故障,讀取故障發(fā)生時刻環(huán)境信息狀態(tài),清除故障,判斷故障發(fā)生點,還可以用來升級ECU程序。
JTAG是針對MCU或者SOC這種芯片的調(diào)試接口協(xié)議,而UDS更像是針對整個ECU的調(diào)試接口。UDS簡單來說是一種Client/Server的通信服務(wù),即Tester(診斷儀)向ECU發(fā)送診斷服務(wù)請求(Request),ECU則向Tester發(fā)送對應(yīng)服務(wù)請求的響應(yīng)(Response)。
UDS在OSI模型中的位置如下所示。ISO14229有中文版本,可以搜索《道路車輛 統(tǒng)一診斷服務(wù)(UDS)》
從上圖中可知ISO 14229-1定義了UDS的規(guī)范和要求。上面講到了,UDS可以在不同的總線上實現(xiàn),于是下面的ISO14229-3定義了UDSonCAN,即UDS在CAN上的具體實現(xiàn),ISO14229-3還是屬于應(yīng)用層的。同理,ISO14229的其他部分標(biāo)準(zhǔn)分別規(guī)定了UDS在不同總線上的實現(xiàn)細(xì)節(jié)。其中UDSonIP規(guī)定的是基于IP實現(xiàn)的UDS,常用的IP網(wǎng)絡(luò)其實就是以太網(wǎng)了。ISO 14229-2定義了會話層的相關(guān)標(biāo)準(zhǔn)。
在學(xué)習(xí)過程中,有看到這樣的說法:“UDS(Unified Diagnostic Services)是ISO 15765和ISO 14229定義的一種汽車通用診斷協(xié)議”,這說的不嚴(yán)謹(jǐn),這說的其實是UDS在CAN總線上的實現(xiàn),其網(wǎng)絡(luò)模型如下。ISO15765-2可以用ISO 14229-2加上ISO14229-3替代。
以太網(wǎng)可以確定會成為未來車輛內(nèi)的主干總線,當(dāng)10base-T1標(biāo)準(zhǔn)完善,以太網(wǎng)可能會完全取代CAN總線。因此本文關(guān)注UDS在CAN和以太網(wǎng)上的實現(xiàn)。
在剛學(xué)習(xí)的時候,會對UDSonCAN和DoCAN有疑問,不知道二者有什么區(qū)別。DoCAN的全稱是Diagnosis on CAN。UDSonCAN和DoCAN是在通信模型不同層中的不同叫法,其規(guī)定了不同層的技術(shù)標(biāo)準(zhǔn)。UDSonCAN僅存在于應(yīng)用層,而DoCAN只適用于網(wǎng)絡(luò)層和傳輸層。
這里要說下OBD,因為在看診斷的時候,也有看到OBD的概念,這也是UDS下面的一個分支。
OBD(全稱:On Board Diagnostics),即車載自動診斷系統(tǒng),是汽車排放和驅(qū)動性相關(guān)故障的標(biāo)準(zhǔn)化診斷規(guī)范,有嚴(yán)格的排放針對性,其實質(zhì)就是通過監(jiān)測汽車的動力和排放控制系統(tǒng)來監(jiān)控汽車的排放。當(dāng)汽車的動力或排放控制系統(tǒng)出現(xiàn)故障,有可能導(dǎo)致一氧化碳(CO)、碳?xì)浠衔?HC)、氮氧化合物(NOx)或燃油蒸發(fā)污染量超過設(shè)定的標(biāo)準(zhǔn),故障燈就會點亮報警。
OBD與UDS的區(qū)別是:
(1)OBD是關(guān)注車輛實時排放的理念形成的行業(yè)規(guī)范,而UDS是診斷服務(wù)的統(tǒng)一化規(guī)范。電動車不需要滿足這個標(biāo)準(zhǔn),因為沒有尾氣排放。燃油車通常既要滿足OBD,又要滿足UDS。診斷服務(wù)下面才會講到,看完診斷服務(wù)可以回頭看這里。UDS的診斷服務(wù)代碼是從0x10開始的,小于0x10的代碼則被OBD用了。
(2)UDS是面向整車所有ECU的,而OBD是面向排放系統(tǒng)ECU的。既然UDS可以用于所有的ECU,那是否能把OBD完全取代呢?這點不太清楚。
本文不關(guān)心OBD,只關(guān)心UDS。
2 基于CAN總線實現(xiàn)的UDS
ISO 14229-1定義了UDS的所有服務(wù)規(guī)范。UDS在CAN上的應(yīng)用,相對于在其他總線上應(yīng)用上可能有一些差別,把這部分摘出來形成標(biāo)準(zhǔn)就是ISO 14229-3,這是為了將UDS的主體部分摘出來,盡量和具體的總線解耦,便于后期標(biāo)準(zhǔn)各部分的擴(kuò)展。ISO 14229-3的內(nèi)容不是很多,主要是會話層的內(nèi)容,定義了數(shù)據(jù)傳輸和接收的一些時間參數(shù),如果不是深入做協(xié)議棧的開發(fā),這部分甚至可以直接跳過。
在網(wǎng)絡(luò)層和傳輸層,遵循的是ISO 15765-2的標(biāo)準(zhǔn)。這里主要是為了解決應(yīng)用層數(shù)據(jù)長度與CAN總線數(shù)據(jù)長度不統(tǒng)一的問題。UDS并不僅僅是為了CAN總線設(shè)計的,其最大容量可以達(dá)到4095字節(jié),而經(jīng)典CAN總線的數(shù)據(jù)長度是8個字節(jié)。如何科學(xué)、快捷、安全地將多個字節(jié)通過CAN總線傳輸出去,就成了一個需要解決的問題,這就需要用到ISO 15765-2。所以下面主要從ISO 14229-1和ISO 15765-2兩個方面來看基于CAN總線實現(xiàn)的UDS。
2.1 ISO14229-1是什么
ISO14229-1描述的是與診斷相關(guān)的服務(wù)需求,并未涉及通信機(jī)制,所以它可以在不同的汽車總線上實現(xiàn)。實際應(yīng)用中,測試人員同步外部的診斷儀和車相連,而所謂的診斷服務(wù),是指車能夠提供哪些信息反饋。
比如ECU接受特定的命令,進(jìn)行重啟;又或者,ECU根據(jù)某個指令反饋某個存儲器某個地址的數(shù)據(jù)。這些都是已經(jīng)約定好了的一些服務(wù),這些服務(wù)的集合就是ISO14229-1標(biāo)準(zhǔn)。還是上面那句話,IS014229-1規(guī)定了要提供哪些服務(wù),至于在具體總線協(xié)議上怎么實現(xiàn),它不管。
UDS診斷包括6大類,26種服務(wù),每種服務(wù)都有自己獨立的ID,即SID(Service Identifier)。
? ? 2.2 ISO14229-1請求/響應(yīng)機(jī)制
在應(yīng)用層,UDS的通信機(jī)制很簡單。診斷方發(fā)送服務(wù)請求,ECU返回響應(yīng)。診斷服務(wù)的請求和響應(yīng)根據(jù)是否具有Subfunction(子功能)分為兩類。什么是Subfunticon呢?以0x10這個服務(wù)為例,其服務(wù)種類是Diagnostic Session Control,即診斷會話控制。其實就是控制ECU進(jìn)入不同的會話權(quán)限。這個服務(wù)常用的有三個子功能,服務(wù)子功能的代號是01-03。其中01是指默認(rèn)會話;02是指編程會話;03是擴(kuò)展會話。上電后ECU初始狀態(tài)是默認(rèn)會話,這個狀態(tài)下,ECU能支持的診斷服務(wù)是有限的,如果想要ECU把更多的診斷服務(wù)開放出來,就需要申請其他子功能,比如進(jìn)入擴(kuò)展會話模式。關(guān)于0x10這個服務(wù),下面細(xì)講。
2.2.1 不帶Subfunction的機(jī)制
下圖是不具有Subfunction的UDS診斷服務(wù)請求和響應(yīng)機(jī)制。
(1)診斷方(Tester)向ECU發(fā)送指定的請求數(shù)據(jù)(Request),這條數(shù)據(jù)中需要包含SID,且SID處于該應(yīng)用層數(shù)據(jù)的第一個字節(jié)。
(2)ECU接收到請求數(shù)據(jù)(Request)后會返回響應(yīng),可返回肯定響應(yīng)或者否定響應(yīng)。肯定響應(yīng)是指正常回應(yīng)服務(wù)請求,而否定響應(yīng)是指由于某種原因沒有回應(yīng)服務(wù)請求。在否定響應(yīng)中,會有一個否定響應(yīng)碼,即NRC,會表明否定響應(yīng)的原因。有些地方也將肯定響應(yīng)翻譯成正響應(yīng),否定響應(yīng)翻譯成負(fù)響應(yīng)。
(3)肯定響應(yīng)(Positive Response)格式為:(SID+0X40)+數(shù)據(jù)。例如,請求0X10服務(wù),肯定響應(yīng)第1個字節(jié)為0X50;請求0X22服務(wù),肯定響應(yīng)第1個字節(jié)為0X62。
(4)否定響應(yīng)(Negative Response)格式為:0X7F+SID+NRC。例如,請求0X10服務(wù),否定響應(yīng)第1個字節(jié)為固定的0X7F,第2個字節(jié)為0X10,第3個字節(jié)為NRC。NRC是否定響應(yīng)碼,可以根據(jù)返回的NRC判斷是什么原因?qū)е碌姆穸憫?yīng)。下圖是常見的一些NRC碼,需要看全的NRC碼,可以去查看標(biāo)準(zhǔn)原文。
舉兩個例子,比如否定響應(yīng)碼0x11表示的是ECU不支持診斷方請求的服務(wù),診斷方想讀取某個數(shù)據(jù),但是ECU就沒有這個數(shù)據(jù);0x78表示請求已經(jīng)收到,但可能ECU正忙,無法回復(fù)請求。其余的NRC碼就不展開了,標(biāo)準(zhǔn)里都說明了對應(yīng)的NRC碼的功能。
2.2.2 帶Subfunction的機(jī)制
下圖是有Subfunction的UDS診斷服務(wù)請求和響應(yīng)機(jī)制。與不帶Subfunction的請求響應(yīng)相比,其實也就是多了個Subfunction的編碼。
? 2.2.3 根據(jù)數(shù)據(jù)標(biāo)識符讀寫
除了SID,SID+SF兩種請求命令的構(gòu)成方式以外,還有SID+DID,SID+SF+DID兩種。其中DID是Data Identifier,即數(shù)據(jù)標(biāo)識符。DID表示存儲數(shù)據(jù)的地方,一般存儲整車廠和零件供應(yīng)商定義的數(shù)據(jù),包括模擬輸入和輸出信號(比如轉(zhuǎn)速信號),數(shù)字輸入和輸出信號(比如車門信號),內(nèi)部數(shù)據(jù)和系統(tǒng)狀態(tài)信息等。根據(jù)DID就可以知道需要調(diào)取哪些數(shù)據(jù),而不必知道具體的內(nèi)存位置。
2.3 診斷服務(wù)示例
2.3.1 診斷會話控制服務(wù)-0x10
UDS涉及26個服務(wù),這里只試著講其中幾個,一個個講就是翻譯標(biāo)準(zhǔn)了,沒啥意義。先來看下診斷會話控制服務(wù),上文在講Subfunction的時候其實就有提到0x10。
診斷會話控制服務(wù)被用來使能服務(wù)端中的不同診斷會話模式,診斷會話模式分為兩大類:默認(rèn)會話和非默認(rèn)會話,其中非默認(rèn)會話又包括編程會話和擴(kuò)展會話,如下圖所示。
這里分為三種會話模式,主要考慮的是服務(wù)的使用權(quán)限問題,不同會話模式下能使用的服務(wù)有區(qū)別,如下圖所示。
?
默認(rèn)會話是指ECU在剛上電時保持的會話狀態(tài),其服務(wù)的使用權(quán)限小,即可操作的功能單元服務(wù)少,比如不能使用27,28,83,84等服務(wù);編程會話是僅使用與刷寫程序相關(guān)的診斷服務(wù),比如27,31,34,36,37等服務(wù);而擴(kuò)展會話相較于默認(rèn)會話,其使用服務(wù)的權(quán)限大,即可操作的功能單元服務(wù)多,默認(rèn)會話模式下不能使用的服務(wù),在擴(kuò)展模式下都能使用。
模式切換遵循以下規(guī)則:
(1)當(dāng)ECU上電時,ECU總是從默認(rèn)會話模式開始。
(2)當(dāng)ECU上電后,非默認(rèn)會話沒被激活時,ECU會一直處于默認(rèn)會話模式。
(3)當(dāng)進(jìn)入非默認(rèn)會話后,如果服務(wù)端的S3定時器超時或請求了默認(rèn)會話,將進(jìn)入默認(rèn)會話;
(4)當(dāng)進(jìn)入非默認(rèn)會話后,如果控制服務(wù)端的S3定時器不超時,比如使用待機(jī)握手服務(wù)($3E),則即可進(jìn)行編程會話與擴(kuò)展會話切換。
這里解釋以下S3參數(shù),S3參數(shù)可分為S3server和S3client。前者是服務(wù)器的定時參數(shù),通常取5000ms,僅用于非默認(rèn)會話模式。在該模式下,如果在S3server時間內(nèi),服務(wù)端沒有接受到任何診斷請求服務(wù),則退出非默認(rèn)會話,返回默認(rèn)會話。S3client是客戶端的定時參數(shù),通常取4000ms。客戶端為了保持非默認(rèn)會話的連接,可以通過發(fā)送3E請求(待機(jī)握手服務(wù))來保持連接,但必須在S3server的時間內(nèi)發(fā)送一次。相當(dāng)于每4000ms,客戶端告訴服務(wù)端它還在,不要退出非默認(rèn)會話。
下面來看下0x10的請求和響應(yīng)格式。0x10是有多個子功能的,所以其請求格式為SID+SF。比如請求默認(rèn)會話模式,客戶端會發(fā)送10 01;編程會話模式,則發(fā)送10 02,其他以此類推。需要說明的是上面提到了0x10的三個子功能,其實0x10的子功能不止三個,其他的子功能如下圖,這里不展開。
以客戶端發(fā)送了10 01為例,服務(wù)器端應(yīng)回復(fù)50 01 xx xx xx xx。這里的xx是響應(yīng)的相關(guān)參數(shù),如下圖所示。
參數(shù)通常是會話參數(shù),即P2Server和P2*Server,如下圖所示。
這里來解釋一下P2Server和P2*Server。
P2Server的定義如下,表示從服務(wù)器端接收到請求消息到開始發(fā)送響應(yīng)消息的時間。通常取值為50ms。
P2*Server的定義如下,表示從服務(wù)器端接收到請求消息到開始發(fā)送響應(yīng)消息的時間。通常取值為5000ms。
P2*Server的定義如下,表示從ECU發(fā)送了NRC為0x78的否定響應(yīng)消息到開始發(fā)送下一個響應(yīng)消息之間的additional max.time,通常取5000ms。
如果設(shè)置P2server_max=50ms,P2*server_max=5000ms,則肯定響應(yīng)就是50 01 00 32 01 F4。
需要說明的是,時間參數(shù)不止以上兩個。會話層,即ISO 14229-2還定義了其他時間參數(shù),有需要的可以查找標(biāo)準(zhǔn)。
當(dāng)客戶端發(fā)送診斷服務(wù)請求,服務(wù)端需要回復(fù)否定響應(yīng)時,這時否定響應(yīng)格式為?7F+SID+NRC,0x10服務(wù)支持的部分NRC如下圖所示。
比如客戶端發(fā)送請求10 05,但服務(wù)端未定義05,即不支持該子功能,則產(chǎn)生否定響應(yīng)7F 10 12;比如請求10 01 01,不符合請求格式SID+SF的長度,則產(chǎn)生否定響應(yīng)7F 10 13。
2.3.2 安全訪問服務(wù)-0x27
訪問數(shù)據(jù)服務(wù)和某些診斷服務(wù)需要考慮保密或安全等原因,比如下載/上傳診斷服務(wù)例程或數(shù)據(jù)進(jìn)入ECU并從其讀取特定的內(nèi)存位置,或者下載到ECU中的不正確例程或數(shù)據(jù)可能會損壞電子設(shè)備或其他車輛部件,或危及車輛的排放和安全標(biāo)準(zhǔn)。為了解決這些情況,就定義了安全訪問服務(wù)。
安全服務(wù)的實現(xiàn)過程如下圖所示。
上圖中請求種子使用的格式是27 2n-1,原因是ECU需要解鎖情況有多種,比如擴(kuò)展會話模式下讀寫數(shù)據(jù)前需要解鎖,比如采用27 01;編程會話模式下刷寫程序前也需要解鎖,比如采用27 03;當(dāng)然可能還包括其他情況,故上圖采用27 2n-1就更具有概括性,可適用多種情況。2n-1具體對應(yīng)解鎖什么服務(wù),由整車廠自己定義。
當(dāng)請求種子后,ECU就需要響應(yīng),發(fā)送種子。當(dāng)客戶端收到種子后,通過某種算法獲得密鑰后,客戶端發(fā)送密鑰給ECU。發(fā)送密鑰的子功能代碼都是偶數(shù)。
舉個例子,假設(shè)擴(kuò)展會話模式下,讀寫數(shù)據(jù)前需要先解鎖,比如約定好了,這種場景下解鎖采用的是27 01命令。我們發(fā)送27 01請求種子;ECU發(fā)送67 01 36 57,其中36 57是種子。密鑰是種子的二進(jìn)制補(bǔ)碼,于是客戶端計算出密鑰是C9 A9;隨后通過27 02 C9 A9發(fā)送密鑰給ECU;ECU驗證正確后,回復(fù)67 02,表明解鎖成功。解鎖成功后,就可以讀寫數(shù)據(jù)了。
如果在解鎖狀態(tài)下,重復(fù)發(fā)送解鎖請求,比如發(fā)送27 01的命令,則ECU會回復(fù)67 01 00 00,表明ECU已解鎖。
27 01解鎖的是數(shù)據(jù)讀寫的功能,如果要解鎖刷寫程序的功能,假設(shè)刷寫程序解鎖的子功能代碼是03,則需要重復(fù)上面的,使用27 03等指令取解鎖刷寫程序的功能。
0x27服務(wù)支持的否定響應(yīng)碼如下。舉個例子,如果客戶端給服務(wù)端發(fā)送的密鑰不對,那么服務(wù)端將會發(fā)送否定響應(yīng),即7F 27 35。
? 2.3.3 根據(jù)標(biāo)識符讀數(shù)據(jù)-0x22
0x22是根據(jù)DataIdentifier(即DID)去請求讀取數(shù)據(jù),其請求格式為SID+DID。這里請求的DID可以是一個,也可以是多個。其肯定響應(yīng)的格式為(SID+40)+DID+Data,看一個例子。其中22是SID,響應(yīng)時SID+40=62。F1 90為DID,紫色部分則為具體的數(shù)據(jù)。
再看請求兩個DID的情況。其中01 0A和01 10為兩個DID。A6-7E這部分?jǐn)?shù)據(jù)為01 0A這個DID的數(shù)據(jù),8C為DID=01 10的數(shù)據(jù)。
? ? 2.3.4 根據(jù)標(biāo)識符讀數(shù)據(jù)-0x2E
0x2E是根據(jù)DataIdentifier(即DID)去請求寫入數(shù)據(jù),其請求格式為SID+DID+Data.
注意這里一次只寫一個DID的數(shù)據(jù),不像讀取數(shù)據(jù)服務(wù)可以一次讀取多個DID的數(shù)據(jù)。通過該服務(wù)可以:寫入一些配置信息到ECU(比如VIN碼,即車輛識別碼),清除非易失性數(shù)據(jù),重置學(xué)習(xí)值,設(shè)置一些可選內(nèi)容。
需要注意的是,2E服務(wù)需要ECU解鎖了才能執(zhí)行,默認(rèn)會話模式不支持該服務(wù),所以要先進(jìn)入非默認(rèn)會話模式,然后解鎖,才能寫入數(shù)據(jù)。假設(shè)F1 90為DID,根據(jù)該DID寫入數(shù)據(jù)的整個過程見下圖。
? ? 2.4 ISO15765-2標(biāo)準(zhǔn)
15765-2作為車輛診斷通信的一個組成部分,規(guī)范了“傳輸協(xié)議和網(wǎng)絡(luò)層服務(wù)”。
UDS網(wǎng)絡(luò)層,又稱為TP層(Transport Protocol Layer)。其存在的目的是為了解決ISO 11898協(xié)議中定義的經(jīng)典CAN數(shù)據(jù)鏈路層與ISO 14229協(xié)議中定義的應(yīng)用層,彼此之間數(shù)據(jù)長度不統(tǒng)一的問題。經(jīng)典CAN數(shù)據(jù)鏈路層最大能夠支持8個字節(jié),但I(xiàn)SO 14229并不僅僅是為了CAN總線設(shè)計的,最大容量達(dá)到4095個字節(jié)。比如VIN碼是17個字節(jié),CAN總線必然需要傳遞3幀才能傳完VIN碼,那么如何科學(xué)、快捷、安全地將多個字節(jié)通過經(jīng)典CAN來進(jìn)行傳輸,就成了一個需要解決的問題。ISO 15765-2 協(xié)議由此誕生。
網(wǎng)絡(luò)層協(xié)議數(shù)據(jù)單元(N_PDU,Network_Protocol Data Unit)包含N_AI,N_PCI,N_Data。即地址信息,協(xié)議控制信息和數(shù)據(jù)。
N_AI包含了源地址、目標(biāo)地址和尋址方式信息,后面再展開。
N_PCI標(biāo)識網(wǎng)絡(luò)層幀的類型。網(wǎng)絡(luò)層協(xié)議數(shù)據(jù)單元(N_PDU)有四種類型,即單幀(SF)、首幀(FF)、連續(xù)幀(CF)、流控制幀(FC)。
N_Data包含應(yīng)用層協(xié)議控制信息和數(shù)據(jù),即上文我們談到的那些。
2.4.1 N_AI
在發(fā)送報文的時候,需要在報文里體現(xiàn)自己是誰,報文要發(fā)給誰。這就是源地址(N_SA)、目標(biāo)地址(N_TA)、目標(biāo)地址類型(N_TAtype)、可選地址擴(kuò)展(N_AE)。關(guān)于這幾個地址有幾點要說明。
(1)源地址和目標(biāo)地址很好理解,但需要說明的是,一個設(shè)備的接收地址和發(fā)送地址是不一樣的。比如一個設(shè)備只接收目的地址為0x741的數(shù)據(jù),但是它在回復(fù)數(shù)據(jù)時,使用0x749為源地址。即收發(fā)是使用不同的地址。
(2)目的地址類型分為兩種,物理地址和功能地址。物理地址是指一對一的尋址,功能地址是指廣播。每個ECU有不同的物理地址,當(dāng)你想與特定的ECU通信時,需要以特定的物理地址為目的地址。但當(dāng)你想廣播一個信息的時候,那就使用功能地址為目的地址,比如我們約定0x7DF為目的地址,當(dāng)總線上出現(xiàn)了0x7DF為目的地址的信息后,所有的ECU都要動作。
(3)N_AE用于遠(yuǎn)程診斷,遠(yuǎn)程診斷的概念是指數(shù)據(jù)域里的內(nèi)容將會包含“遠(yuǎn)程地址(RA)”作為遠(yuǎn)程節(jié)點的標(biāo)識。
N_AI在CAN數(shù)據(jù)鏈路層的數(shù)據(jù)包中是要映射到CAN ID部分的。在這里插一句,通常上層協(xié)議的數(shù)據(jù)包直接填進(jìn)下層協(xié)議的Data段,在這里有點特殊。先看下CAN的數(shù)據(jù)包格式。
CAN的仲裁段就是CAN ID,網(wǎng)絡(luò)層的數(shù)據(jù)包會被拆散,其中N_AI會被映射到CAN ID段,N_PCI和N_Data整體會成為CAN的Data段。根據(jù)N_AI的映射方式,網(wǎng)絡(luò)層定義了幾種尋址方式。
(1)標(biāo)準(zhǔn)地址
標(biāo)準(zhǔn)地址:這個格式最常見,也最好理解,指的是使用CAN的“標(biāo)準(zhǔn)幀”11位作為N_AI,至于源地址、目標(biāo)地址等等,都是根據(jù)設(shè)備具體定義;比如上面0x741、0x749、0x7DF這些ID就已經(jīng)區(qū)分了源、目標(biāo)、類型這些內(nèi)容了。需要說明的是,源地址、目標(biāo)地址還有類型不需要單獨占一個字節(jié),不然11bit就不夠用了。由于這些數(shù)據(jù)組合有限,通過自定義的映射方式,11bit就夠用了。比如0x741,你自己就把它定義成,源地址是診斷儀、目標(biāo)地址是ECU3,地址類型是功能尋址。
(2)標(biāo)準(zhǔn)混合地址:也叫“常規(guī)固定尋址”,這個格式從名字上就有點怪,其實就是在標(biāo)準(zhǔn)地址的基礎(chǔ)上,把CAN的“標(biāo)準(zhǔn)幀”11位改為使用“擴(kuò)展幀”29位并做了特殊位定義。
對于CAN的擴(kuò)展幀,ID段有29位,相對11bit就寬裕很多。因此28-24位是固定的,23-16用于表征地址類型,15-8和7-0分別表示源地址和目的地址。
(3)擴(kuò)展地址:這個格式從名字上就容易讓人誤解,以為是使用CAN的“擴(kuò)展幀”,但其實就是在標(biāo)準(zhǔn)地址的基礎(chǔ)上,把數(shù)據(jù)域的字節(jié)1拿出來用作N_TA來標(biāo)識這個數(shù)據(jù)的接收者是誰。
很容易發(fā)現(xiàn)這種格式似乎并不好,因為不僅要浪費數(shù)據(jù)域的一個字節(jié),在數(shù)據(jù)處理上CPU也要在得到數(shù)據(jù)后進(jìn)行判斷篩選,而它的目的只是為了擴(kuò)展CAN標(biāo)準(zhǔn)幀的地址而已,那我們?yōu)槭裁床恢苯佑肅AN的“擴(kuò)展幀”格式“標(biāo)準(zhǔn)混合地址”呢?所以正常CAN ID夠用的情況下,似乎不需要使用這個格式。
(4)混合地址:又是一個從名字上就讓人容易混淆的格式!是專門用于“遠(yuǎn)程診斷”的,遠(yuǎn)程診斷的概念是指數(shù)據(jù)域里的內(nèi)容將會包含“遠(yuǎn)程地址(RA)”作為遠(yuǎn)程節(jié)點的標(biāo)識,混合地址的格式中對CAN的“標(biāo)準(zhǔn)幀”11位和“擴(kuò)展幀”29位的使用都進(jìn)行了不同的定義。
其中,混合地址的CAN“擴(kuò)展幀”29位的格式如下。
可以看到,主要的區(qū)別在于16~23位的值,與之前介紹的“標(biāo)準(zhǔn)混合地址”有所不同,這個dec段可以用于節(jié)點識別數(shù)據(jù)的地址格式。而且也一樣占用了數(shù)據(jù)域中的第一個字節(jié),作為地址擴(kuò)展。
混合地址的CAN“標(biāo)準(zhǔn)幀”11位的格式如下。
? 2.4.2 N_PCI
N_PCI字段,主要用于表征幀的類型。幀的類型分單幀、首幀、連續(xù)幀、流控幀等。
當(dāng)一次通訊數(shù)據(jù)內(nèi)容只需要一條CAN數(shù)據(jù)包就能包含時,就使用單幀格式。它的N_PCI需要占用1個字節(jié),如下。
其中的SF_DL是用于表示本次傳輸數(shù)據(jù)的長度,由于只有4bit,它的范圍和使用定義。
當(dāng)一次通訊整包數(shù)據(jù)較長,需要拆分成多個CAN數(shù)據(jù)進(jìn)行傳輸時,就需要使用首幀、連續(xù)幀與流控幀配合實現(xiàn)分包機(jī)制,這三種幀的多幀傳輸使用邏輯如下。
下面來分別介紹這三種類型的數(shù)據(jù)幀。
首幀的N_PCI需要占到2個字節(jié),如下。第一個字節(jié)的高四位為1表示幀類型是首幀,低四位和第二個字節(jié)組成FF_DL共同表示多幀傳輸?shù)淖止?jié)數(shù)。那么我們可以得到一次性最多可以發(fā)送2的12次方-1個字節(jié)。那就是4095個字節(jié)了。
連續(xù)幀的N_PCI需要占用1個字節(jié),如下。它有一個叫SN的代碼區(qū)域,這SN表示的是包的連續(xù)號,從0到15后,又置零。其功能是說明幀的連續(xù)順序。需要注意的是,首幀雖然沒有SN的區(qū)域,但是在首幀也占一個SN,因此首幀之后的連續(xù)幀需要從1開始計數(shù)。
流控幀的N_PCI需要占用3個字節(jié),其有三個區(qū)域FS,BS,STmin。
FS:表示的是流控狀態(tài)參數(shù)。0表示的是繼續(xù)發(fā)送(CTS),1表示的是等待(WT),這兩個配合使用可以控制發(fā)送速度;2表示溢出(OVFLW),用于接收者告訴發(fā)送者數(shù)據(jù)過大,在首幀后的第一條流控幀應(yīng)答。
BS:表示的是塊的大小,即發(fā)送端一次性能夠發(fā)送多少個連續(xù)幀。要注意的是,BS表示的是在發(fā)送端沒有接受到流控信號時,能夠發(fā)生的幀的數(shù)目。而當(dāng)BS為0則表示,在數(shù)據(jù)傳輸?shù)臅r,接收端不再發(fā)送流控幀了。發(fā)送端應(yīng)當(dāng)連續(xù)不斷的發(fā)送數(shù)據(jù)。
STmin:表示的是兩個連續(xù)幀(FF)的時間間隔。
CANFD下相關(guān)數(shù)據(jù)幀格式會有些不一樣,這里不再展開了,有興趣的去翻翻標(biāo)準(zhǔn)原文。有中文的標(biāo)準(zhǔn),如下圖。
? ? 2.4.3 網(wǎng)絡(luò)層定時參數(shù)
網(wǎng)絡(luò)層除了定義了網(wǎng)絡(luò)層相關(guān)協(xié)議,還定義了定時參數(shù)。
N_As:發(fā)送方發(fā)送CAN數(shù)據(jù)幀經(jīng)過鏈路層發(fā)送的時間。
N_Ar:接受方發(fā)送CAN數(shù)據(jù)幀經(jīng)過鏈路層發(fā)送的時間。
N_Bs:發(fā)送方接收流控幀的等待時間。
N_Br:接受方發(fā)送流控幀的間隔時間。
N_Cs:發(fā)送方發(fā)送連續(xù)幀的間隔時間。
N_Cr:接受方接收連續(xù)幀的等待時間。
具體的參數(shù)允許范圍,請查看標(biāo)準(zhǔn)ISO 15765-2,這里不展開。
3 基于以太網(wǎng)實現(xiàn)的UDS
DoIP的全稱是Diagnostic Over Internet Protocol,即基于TCP/IP協(xié)議的診斷協(xié)議。隨著以太網(wǎng)技術(shù)在車載領(lǐng)域的應(yīng)用范圍逐步擴(kuò)大,越來越多的控制器支持通過以太網(wǎng)進(jìn)行診斷通信,由于采用以太網(wǎng)通信技術(shù),DoIP診斷具有超高的數(shù)據(jù)傳輸速率,速率達(dá)到了100 Mbit/s,相較于CAN總線診斷,DoIP診斷總體速率是CAN診斷的100-200倍,網(wǎng)絡(luò)上的傳輸速率是CAN診斷的300-400倍。并且硬件成本低,在個人電腦上只需要一個以太網(wǎng)接口即可實現(xiàn)診斷的物理連接。DoIP技術(shù)可以完美匹配IT基礎(chǔ)設(shè)施,固定診斷和遠(yuǎn)程診斷均能應(yīng)用,車載以太網(wǎng)技術(shù)將是未來解決如何快速更新ECU軟件及標(biāo)定的主要策略之一。
回頭來看這張圖,ISO 14229-1定義了各種服務(wù)規(guī)范,與總線無關(guān)。所以基于以太網(wǎng)實現(xiàn)UDS,這部分就不需要重新講了。
ISO 14229-5,也就是UDSonIP,定義了當(dāng)UDS在以太網(wǎng)總線上實現(xiàn)時需要遵循的一些特有原則,這部分的標(biāo)準(zhǔn)內(nèi)容不多。
舉兩個例子,當(dāng)使用0x10(診斷會話控制服務(wù))時,會導(dǎo)致TCP連接中斷,再次開始診斷前,要重新建立TCP連接,并發(fā)送路由激活報文。
當(dāng)使用0x11(ECU復(fù)位服務(wù))時,同樣會導(dǎo)致TCP連接斷開,路由激活失效,再次開始診斷前也要重新建立TCP連接,并發(fā)送路由激活報文。
再往下是ISO 14229-2,定義了會話層的相關(guān)內(nèi)容,主要是數(shù)據(jù)傳輸/接收的一些參數(shù)設(shè)置,前文已經(jīng)講過了。
最后是我們關(guān)注的重點,ISO 13400-2,即DoIP。DoIP協(xié)議定義了從物理層(Physical Layer)到應(yīng)用層(Application Layer)搭建”通信橋梁”的規(guī)則(此處可類似 CAN總線的TP層協(xié)議ISO 15765-2)
3.1 DoIP的網(wǎng)絡(luò)架構(gòu)
支持DoIP的車輛網(wǎng)絡(luò)架構(gòu)圖如下。
根據(jù)ISO-13400的要求,DoIP通信在物理層支持100BASE-TX (100 Mbit/s Ethernet) 和10BASE-T (10 Mbit/s Ethernet) 兩種制式。
汽車內(nèi)部必須有一個DoIP的總網(wǎng)關(guān),它作為和外部的診斷設(shè)備DoIP通信的唯一接口。車內(nèi)網(wǎng)中,直接與外部診斷儀進(jìn)行物理連接的節(jié)點,叫做邊緣節(jié)點(DoIP edge node)。邊緣節(jié)點可作為一個網(wǎng)絡(luò)交換機(jī),將車內(nèi)網(wǎng)與車外網(wǎng)組成同一子網(wǎng);也可以作為一個網(wǎng)關(guān),將車內(nèi)網(wǎng)與車外網(wǎng)進(jìn)行安全隔離,屏蔽非法的網(wǎng)絡(luò)訪問和網(wǎng)絡(luò)攻擊。除了邊緣節(jié)點之外,還有另一類網(wǎng)關(guān),即車內(nèi)的DoIP網(wǎng)關(guān)節(jié)點。車內(nèi)DoIP網(wǎng)關(guān)節(jié)點的作用,是實現(xiàn)以太網(wǎng)到其他網(wǎng)絡(luò)總線(如CAN、LIN)的報文路由,這樣便實現(xiàn)了DoIP診斷與傳統(tǒng)網(wǎng)絡(luò)總線的兼容。多種網(wǎng)絡(luò)總線匯聚到DoIP網(wǎng)關(guān),這大大的降低了布線的復(fù)雜性,并且提高了各總線網(wǎng)絡(luò)中ECU的診斷效率。車內(nèi)網(wǎng)絡(luò)中,還存在一般的DoIP節(jié)點,這些節(jié)點只支持對自身的診斷,而不具備路由功能。最后,還有一類網(wǎng)絡(luò)節(jié)點(Network node),不具備DoIP診斷功能,與DoIP節(jié)點共享網(wǎng)絡(luò)資源。
3.2 DoIP的數(shù)據(jù)幀格式
在講DoIP數(shù)據(jù)幀格式之前,先回顧下完整的以太網(wǎng)數(shù)據(jù)幀如下。
IP段數(shù)據(jù)幀格式如下。在網(wǎng)絡(luò)層上DoIP使用IPV6協(xié)議,但為了向后兼容的原因,也支持IPV4,對于IPV4還要支持地址解析協(xié)議(ARP),對于IPV6還要支持鄰居發(fā)現(xiàn)協(xié)議(NDP),這兩個協(xié)議都是用于在只知道IP地址的情況下獲取MAC地址的。
TCP段數(shù)據(jù)格式如下。支持DoIP的ECU的診斷服務(wù)創(chuàng)建的socket必須監(jiān)聽在端口號13400上,外部測試設(shè)備通過連接此端口建立連接;每個支持DoIP的ECU必須支持n+1個并發(fā)的TCP socket連接,這是為了防止有多個外部測試設(shè)備同時和ECU進(jìn)行診斷通信;外部測試設(shè)備創(chuàng)建的socket應(yīng)選擇本地端口,本地端口即系統(tǒng)隨機(jī)的端口。
這里解釋下套接字的概念,在TCP/IP網(wǎng)絡(luò)中,區(qū)分不同的應(yīng)用程序進(jìn)程間的網(wǎng)絡(luò)通信和連接時主要有以下3個參數(shù):通信的目的地址、使用的傳輸協(xié)議(TCP或UDP)和使用的端口號(此處說明一下,Socket不僅在TCP有,在UDP同樣有)。通過將這3個參數(shù)結(jié)合起來,與一個Socket進(jìn)行綁定,應(yīng)用層就可以與傳輸層一起通過套接字接口區(qū)分來自不同應(yīng)用程序進(jìn)程或網(wǎng)絡(luò)連接的通信,實現(xiàn)數(shù)據(jù)傳輸?shù)牟l(fā)服務(wù)。為了區(qū)別不同的應(yīng)用程序進(jìn)程和連接,許多計算機(jī)操作系統(tǒng)為應(yīng)用程序與TCP/IP交互提供了稱為套接字(Socket)的接口。
UDP段數(shù)據(jù)格式如下。
DoIP段數(shù)據(jù)格式如下。
DoIP數(shù)據(jù)幀前面兩個字段分別是協(xié)議版本和協(xié)議版本的取反。第三個字段是數(shù)據(jù)類型,具體定義如下。
?
常用的數(shù)據(jù)類型如下:
0x0001至0x0004:用于汽車標(biāo)識上報或請求,只能通過UDP報文來發(fā)送這種命令,主要用于在汽車和診斷儀進(jìn)入網(wǎng)絡(luò)之后、診斷連接建立之前的車輛發(fā)現(xiàn)過程。
0x0005 和0x0006:標(biāo)識的Routing activation request 和 response用于在socket建立之后,進(jìn)行診斷通信的請求。
0x0007和0x0008:用于Alive check,用于檢查當(dāng)前建立的診斷連接socket是否仍然在使用中,如果不再使用,則關(guān)閉socket釋放資源。
0x8001,0x8002,0x8003:分別代表的含義分別是診斷消息、診斷消息正響應(yīng)和診斷消息負(fù)響應(yīng)。
Data Length標(biāo)識后面的user data的長度。
IS0 13400-2標(biāo)準(zhǔn)中給出了一個報文的示例如下。
? 3.3 車輛發(fā)現(xiàn)與聲明
在實現(xiàn)診斷通信之前,需要先發(fā)現(xiàn)車輛、建立TCP連接和建立診斷連接。先看車輛發(fā)現(xiàn)和聲明。
DoIP設(shè)備啟動后,首先通過UDP廣播的形式把一條DoIP報文(vehicle announcement message,Payload Type為0x0004)發(fā)給網(wǎng)絡(luò)上的所有的其他節(jié)點,其中就包括診斷儀,目的端口是13400,其中這條消息攜帶了DoIP設(shè)備的DoIP版本、VIN、logical address等信息,這條信息會發(fā)送三次,而之前監(jiān)聽在13400端口的診斷儀接收到這條信息,就知道了DoIP設(shè)備的基本信息。
如果診斷儀沒有收到,還有一種辦法,就是診斷儀這邊主動請求,通過UDP廣播的形式,主動發(fā)一條DoIP request消息(Payload Type為0x0001),目的端口號是13400,而之前啟動后就一直監(jiān)聽在13400的DoIP設(shè)備,接收到這條消息后,就會回復(fù)一條攜帶自己信息的response給診斷儀。
3.4 TCP連接
診斷儀通過創(chuàng)建tcp socket,然后調(diào)用connect方法向DoIP設(shè)備發(fā)起TCP連接請求(目的ip是DoIP設(shè)備ip,目的端口號是13400),而DoIP設(shè)備在啟動前已經(jīng)通過創(chuàng)建tcp socket監(jiān)聽在13400端口,接收到tcp連接請求后就會完成三次握手。
3.5 診斷連接
Socket一端連接著IP地址,一端連接著Port端口。并且Socket對于芯片而言是一種資源.因此有激活失效之分。在TCP連接建立后,診斷儀還需要發(fā)送一條Routing activation request的DoIP報文給DoIP設(shè)備,DoIP設(shè)備收到后會回復(fù)一條Routing activation response的DoIP報文,此時診斷連接建立,雙方可以診斷通信。
? 4 總結(jié)
設(shè)計一個復(fù)雜的系統(tǒng)后,去建立一個完善的診斷系統(tǒng),往大了說,是為了提高維修效率,為公司爭取經(jīng)濟(jì)利益。往小了說,是為了解放工程師自己,售后人員通過標(biāo)準(zhǔn)工具可以定位問題,就不會來找設(shè)計人員尋求技術(shù)支持。所以,工程師們,大家在設(shè)計復(fù)雜系統(tǒng)時,都記得給自己留條后路吧,不然量產(chǎn)后填坑會異常痛苦的。
審核編輯:黃飛
?
評論
查看更多