從成本等角度考慮，汽車ECU中用於快取診斷服務資料的buffer大小有限，所以當我們需要讀取或寫入超過buffer大小的資料時，就無法簡單地使用2E和22服務了，UDS據此定義了幾個將大塊資料寫入或讀出的服務，即資料下載和上傳。

Upload Download functional unit總共定義了5個診斷服務，分別是：

RequestDownload （0x34）：客戶端向伺服器請求下載資料
RequestUpload （0x35）客戶端向伺服器請求上傳資料
TransferData（0x36） 客戶端向伺服器傳資料（下載），或者伺服器向客戶端傳資料（上傳）
RequestTransferExit（0x37）資料傳輸完成，請求退出
RequestFileTransfer（0x38） 傳輸檔案的操作，可以用於替代上傳下載的服務。
下圖是資料下載的簡略過程，用到了34，36，37這三個服務，如果是上傳的話，34服務被35服務替換，資料傳輸方向變一下，就可以了。

RequestDownload （0x34）：

0x34服務用於啟動下載傳輸，作用是告知ECU準備接受資料，ECU則通過0x74 response告訴診斷儀自己是否允許傳輸，以及自己的接受能力是多大。

0x34服務的請求格式包括5個部分

第一部分：1個byte的SID

第二部分：1個byte的dataFormatIdentifier，這裡面標識了資料格式相關的資訊，比如資料是否有壓縮，是否有加密，用的什麼演算法加密等，應該由主機廠與供應商約定好，用哪個bit來表示壓縮、加密等資訊。

第三部分：1個位元組的addressAndLengthFormatIdentifier，用於指示後面兩個部分所佔用的位元組，高4bit表示memorySize所佔的位元組長度，低4bit表示memoryAddress

所佔的位元組長度。在這個例子中我將這兩個值分別設定為n和m。

第四部分：m個位元組的memoryAddress，由addressAndLengthFormatIdentifier中的低4bit指示。含義是要寫入資料在ECU中的邏輯地址。

第五部分：n個位元組的memorySize，由addressAndLengthFormatIdentifier中的高4bit指示。含義是要寫入資料的位元組數。
ECU收到請求之後，如果允許傳輸的話，會給出如下response

第一部分：1個byte的 Response SID

第二部分：1個byte的dataFormatIdentifier作為echo

第三部分：maxNumberOfBlockLength，長度不定，表示可以通過0x36服務一次傳輸的最大資料量。

ransferData（0x36）：

如果34服務得到了正確響應，tester就要啟動資料傳輸過程了，使用的就是36服務。36服務的格式如下。

第一部分：1個byte的 SID

第二部分：1個byte的blockSequenceCounter，標識當前傳輸的是第幾個資料塊，或者簡單地說就是第幾次呼叫36服務。

第三部分：transferRequestParameterRecord，傳輸的資料。第次傳輸資料量的上限就是34服務響應中的maxNumberOfBlockLength。

舉例：如果ECU告知tester,maxNumberOfBlockLength = 20，也就是說tester每次通過36服務只能傳送最多20個位元組，其中還包括了SID和blockSequenceCounter，所以實際上每次可傳的資料資訊只有18個位元組。如果tester要傳的資料為50個位元組，則需要傳輸三次，每次分別傳輸18，18，14個位元組，即呼叫3次36服務。

36的響應很簡單，就是一個位元組的Response SID再加一個位元組的blockSequenceCounter作為echo。

RequestTransferExit（0x37）：

37服務用於退出上傳下載，如果之前的34和36服務都順利執行完成，那麼37服務就可以得到ECU的positive response。

格式很簡單，請求就是37，正確響應就是77，都是一個位元組。

如果前面的36服務沒有執行完成，以我前面舉的例子來說，比如這個資料塊有50個位元組，但是tester只發了兩次36服務傳了36個位元組，那麼這次傳輸對於ECU來說是失敗的，所以ECU應該給出NRC 0x7F 37 24，表示診斷序列執行有錯誤。

車載網路匯流排管理的目的是使網路中的ECU節點有序地睡眠和喚醒，在沒有通訊需求的時候睡眠，可以節約電池的能量。

CAN總線上的網路管理，是一種無中心式的網路管理，網路中的每個節點都依賴於自己和別人的網路管理報文（NM PDU）來實現通訊的睡眠和喚醒，這個NM PDU是週期性傳送的，對於每個ECU來說，收到別的ECU傳送的NM PDU則意味著當前的網路有通訊需求，自己發出NM PDU則是告知別的ECU自己有通訊需求。如果某個ECU打算進入Bus-Sleep-Mode，它就會通止傳送NM PDU，在進入Bus-Sleep-Mode之前會有一段延時，如果在這段延時中沒有收到任何NM PDU，則它就會轉入Bus-Sleep-Mode狀態了。

CAN NM為ECU的網路管理定義了三種模式（Mode）：

Bus-Sleep Mode
Prepare Bus-Sleep Mode
Network Mode
最後的Network Mode又分為三個狀態（state），

Repeat Message State
Normal Operation State
Ready Sleep State
CAN總線上的網路管理的核心，就是ECU在這3種模式和3個狀態之間的轉換的狀態機。

Bus-Sleep Mode
Prepare Bus-Sleep Mode
Network Mode
最後的Network Mode又分為三個狀態（state），

Repeat Message State
Normal Operation State
Ready Sleep State
CAN總線上的網路管理的核心，就是ECU在這3種模式和3個狀態之間的轉換的狀態機。

跟著狀態機走一遍，就會對這個過程有比較直觀的瞭解了。

ECU最初處於Bus-Sleep Mode中，當它有了通訊需求（比如接收其他ECU的NM報文，或者它的邏輯功能要求自己喚醒，比如車門控制器收到了遙控鑰匙的訊號），它就會進入Network Mode，Repeat Message狀態是Network Mode的入口狀態，到達這個狀態之後，ECU會啟動一個Repeat Message Timer，在這個Timer定義的時間內，ECU會一直處於Repeat Message狀態。當這個timer結束後，如果有通訊需求，ECU則進入Normal Operation狀態，如果沒有通訊需求，則進入Ready Sleep 狀態。Normal Operation狀態就是ECU正常執行的狀態，此時它的應用報文和NM報文都會正常收發。當ECU沒有通訊需求，它會瞬間進入Ready Sleep狀態，在Ready Sleep中，如果又出現了通訊需求，ECU則瞬間再回復到Normal Operation，如果在一個Timeout Timer中一直沒有通訊需求，ECU就進入Prepare Bus-Sleep Mode，在Prepare Bus-Sleep狀態中，也會啟動一個Timeout Timer，如果在這段時間內有了通訊需求，ECU又會立即回到Repeat Message狀態，如果過了這個timer還沒有通訊需求，則ECU會回到Bus-Sleep Mode中。

綜上所述，ECU網路管理的實現的核心就是實現這個狀態機，在AUTOSAR中，這些狀態之間的跳變就是由AUTOSAR定義的各種介面函式實現的。

1. NM（網路管理）是用來做什麼的；
   大家知道，不管是傳統的燃油車還是新能源車，車上都有各種各樣的ECU，而所有這些ECU都是需要用電的，而車上的供電單元一般是蓄電池，因此蓄電池的電量是有限的，對於新能源車來說太耗電無疑會給電池的續航里程帶來巨大影響，因此為了儘可能的省電，所以就提出了網路管理，也就是說網路管理一個最重要的作用就是為了省電。
   那麼網路管理是如何來實現省電的呢？我們知道車上的所有ECU之間會通過CAN通訊、Flexray或乙太網等進行相互通訊連線在一起，那麼網路管理就是通過在各個ECU的網路上，傳送一些命令制定一套規則，來實現各個ECU的協同睡眠和喚醒。
   什麼是ECU的睡眠和喚醒？為了支援睡眠和喚醒，ECU的晶片必須支援低功耗模式和正常工作模式的切換。低功耗模式（ECU睡眠）指一個ECU斷電或者處於極少數的外圍器件工作的模式；喚醒指的是ECU處於全工作模式。
   舉個例子來說，也許你看過特斯拉的車門，它的門把手是和門平齊的，只有你帶著車鑰匙靠近時，它的門把手才會張開，其實這就是在喚醒了車門控制器，也就是說你把車停在那裡時，實際上車門控制器是在睡眠狀態，耗電量極地，而你帶著車鑰匙靠近了，表示你要用車了，他就會通過無線感應模組來喚醒車門，這樣你就可以正常開啟車門了，這個時候車門控制器ECU就處於喚醒狀態。
   總結下：其實網路管理就是用來節約能源，有效的實現車上的ECU的協同睡眠和喚醒。

2. AutoSar中網路管理的原理；
   以下，我會以用的比較多的CAN網路管理為例來進行說明，我會主要圍繞其中最重要的一個狀態機來進行介紹。
   首先我們講一講，為了實現網路管理，我們要考慮些什麼因素，也就是有哪些需求。
   網路管理最終要實現的是車上的ECU能夠協同睡眠以及喚醒，也就是說網路管理最重要的一點是要保證車上的ECU能夠協同喚醒和休眠。那麼假如車上的ECU都處於睡眠模式，網路上都沒有報文，你咋實現喚醒呢，其實，一般不會讓所有的ECU都處於睡眠模式，這個時候可能會有極少的ECU處於工作狀態，比如車上的BCM。也就是說有一些ECU是通過KL15直接喚醒的，而有些是通過CAN報文喚醒。當然或許後面會升級到更加節能的模組，可以不需要鑰匙訊號，這些模組在睡眠狀態時，耗能非常少，因此可以一直處於可喚醒狀態。
   為了滿足這種協同喚醒和睡眠，我們下面來看看Autosar中的NM是如何實現協同的。
   如圖所示，狀態機中有三個主狀態，分別是BusSleep、PreSleep、Network三個狀態；其中Network狀態又分為三個子狀態，分別是RepeatMsg、NormalOperate、ReadSleep。下面我來講一下每個狀態它的作用。
   BusSpleep狀態：這個狀態就是我們所說的休眠狀態，這個狀態下是不傳送網路管理報文也不收發應用報文，一般該狀態時一個低功耗的狀態，也就是我們上文提到的協同睡眠狀態。當然我們上電初始化時，也會預設進入該狀態。
   PreSleep狀態：這個狀態是進入休眠狀態的前一準備狀態，這個狀態一般不傳送網路管理報文幀了，也不傳送應用報文了，只是等待其他ECU一起睡眠，為啥要這個狀態呢，其實就是實現‘’協同‘’兩個字，也就是讓等一段時間讓車上所有ECU實現一起睡眠，其實這個一起睡眠還是比較重要的，比如車上某個ECU的工作與其他ECU的工作是關聯的，比如VCU（整車控制器）和INV（電機控制器），有可能VCU不發報文了，會導致INV報故障，因此這種情況是要避免的。
   Network狀態：這個狀態是允許ECU進行正常通訊的，一般這個狀態下即可以收發網路管理報文幀也可以收發應用報文（包括診斷報文），意思就是喚醒狀態。接下來我來解釋一下這個狀態下里面的三個子狀態的含義：
   Repeat meassage：表示重複髮網絡管理報文的狀態。首先說說這個狀態下會發生什麼事，一般我們進入網路（Network）狀態時，首先會進入這個狀態，這個狀態下會快速的傳送一些網路管理報文幀出來，為啥要快速傳送一些網路管理報文呢？其實就是想盡快的告訴車上的其他ECU，我上線了！我要正常通訊了，大家請注意啊，大家也和我一塊進行整車通訊啊。就是以上這個意思。
   Normal Operation：在進入RepeatMsg一段一時間後，如果需要通訊，就會跳到正常工作狀態，正常工作狀態會按照正常的週期傳送網路管理報文，以及所有應用報文正常進行通訊，可以說這個狀態就是真正的喚醒狀態。
   ReadySleep：如果喚醒後，需要休眠，那麼我們可能需要做一些準備工作才能允許我們的ECU進入休眠，比如這個時候有一些資料要儲存、比如電機控制器檢測到電機還沒停下來等等情況，因此這個狀態就是用來做一些休眠前的準備工作，我們可以看到，任何從喚醒到休眠的過程，都需要經過這個狀態，也就是說睡眠前有些準備工作是必須要完成的。那麼這個狀態下，其實還是能夠進行通訊的，只有進入PreSleep狀態，才會把相應的應用報文收發關閉，以及傳送NM報文關閉。還有一點要宣告的是，一般網路管理報文幀的接收不會關閉。
   其實，網路管理中，各個狀態的切換條件是比較重要的，有興趣的可以看著圖進行鑽研一下。

作者：AgingMoon
來源：CSDN
原文：https://blog.csdn.net/agingmoon/article/details/77826995
版權宣告：本文為博主原創文章，轉載請附上博文連結！