點擊上方藍字談思實驗室

獲取更多汽車網絡安全資訊

AUTOSAR定義的是一種自上而且的近乎分層結構的軟件架構。可以最大化的在微控制器上抽象為三個軟件層級：應用層（Application），運行環境層（Runtime Environment）和基礎軟件層（Basic Software）

1.1基礎軟件層

AUTOSAR的基礎軟件層（BSW）又可分為服務層（Services Layer）、ECU抽象層、微控制器抽象層和復雜驅動層（Complex Drivers Layer）

微控制器抽象層在BSW的最底層，它包含微控制的驅動程序；

ECU抽象層接口微控制器層的，它包含外部設備的驅動。該層提供API來訪問外部設備。

（OSI分層結構中的CAN數據鏈路層對應AUTOSAR分層架構的微控制器抽象層和ECU抽象層）

引自：《AUTOSAR_SWS__COM》第2.1節

復雜驅動層可集成一些特定的功能、驅動或外設。AUTOSAR并未對改成進行詳細規定。

服務層是BSW的最高層，包含以下功能：

（1）提供車輛網絡通信和管理服務

（2）內存服務

（3）診斷服務

（4）ECU狀態管理和模式管理

（5）操作系統的功能

（6）診斷服務（包括UDS通信、故障存儲和錯誤處理等）

基礎軟件層按照提供的功能又可以分為幾個不同的服務模塊，這和上面的介紹只是分法不同。

大致可分為：

（1）輸入\輸出服務

（2）存儲服務

（3）通信服務（本文介紹的內容均包含在這個模塊）

1.2 CAN通信協議棧的分層結構

前面說到了BSW可以分為不同的服務模塊，其中包含有通信服務，如下圖：

本文要介紹的內容即為CAN NM模塊，即基于CAN總線的AUTOSAR網絡管理。

2.1網絡管理報文的格式

做了AUTOSAR網絡管理的ECU，原則上需要定義一條特定的報文作為網絡管理報文，網絡管理報文的類型應為Nosendtype。也許有人疑問，正常工作時網絡管理報文都是按照特定的周期來發送的，為什么類型不是周期報文？這是因為在準備睡眠狀態中是不發送網絡管理報文的，在ECU被主動喚醒時還會以特定的周期快發，所以報文類型不能是周期報文。

剛才說到原則上是需要定義網絡管理報文的，但是國內的有個別非常個性的主機廠，他們定義的整車中某個節點需要支持網絡管理，但是不需要發送網絡管理報文。原則上這是不符合AUTOSAR要求的，但如果該節點沒有主動喚醒網絡的需求，這種做法也是可以的。

2.1.1網絡管理報文的ID

NM報文的ID一般定義為：基礎ID+源地址。AUTOSAR并未指定網絡管理報文的ID范圍，這是OEM自行選擇的，一般0x3xx、0x4xx、0x5xx和0x6xx的都有使用。

以0x53f為例，0x53f=0x500+0x3f，其中0x500即為基礎ID，0x3f為源地址。

2.1.2網絡管理報文的數據場格式

一般網絡管理報文的DLC為8，AUTOSAR舉例的8個字節的的網絡管理報文格式如下：

注：圖片來源《AUTOSAR_SWS_CANNetworkManagement》

（1）舉例中的第一個字節為節點的源地址，源地址的用處可在剛被喚醒時根據源地址判定整個網段中有哪些節點在線。（不過現在很少有見到用的）

通過CanNmPduNidPosition設為off，可以不適用源地址字節。

（2）舉例中的第二個字節為控制位向量，它的格式如下：

注：圖片來源《AUTOSAR_SWS_CANNetworkManagement》

Bit0:重復報文請求位，當某個節點發的NM報文中的此位置1時，所有接收到該NM報文的節點均要返回Repeat Message State。

實際在使用中并未見過有這種需求的工況或場景，如有大神了解，請幫忙補充。

Bit3:協調睡眠準備位，當某個節點發出的NM報文中的此位置1時，意味著該控制器為多個網段的主協調器，且請求同步進入Shutdown。

Bit4:主動喚醒位，該位的作用是標示自身是被主動喚醒的還是被動喚醒的，當自身是被主動喚醒的則置1，被動喚醒則置0。這里的主動和被動既是外部條件，也是自身有無需求。主動喚醒，意味著ECU自身的本地喚醒事件被觸發（本地喚醒事件只有當自身需要請求網絡通信時才會被觸發），自身有網絡通信的需求。例如對于車身控制器BCM，車門狀態的改變是它的本地喚醒條件，當外界環境（人）改變車門狀態時，BCM即被主動喚醒，開發發送NM報文喚醒其它節點，此時該位要置1。被動喚醒是指自身的本地喚醒條件沒有被觸發，但是其它節點有和自己通信的需求，在收到其它節點的網絡管理報文后被喚醒，此時該位置0。

需要注意，在一個喚醒-預睡眠周期內，該位不會重置。當ECU進入預睡眠狀態時會重置該位。支持該位的前提是CanNmActiveWakeupBitEnabled=ture。

Bit6:局部網絡信息位（PNI），該位置1標示ECU自身發送的NM報文中包含PNI。只有在整車網絡中使用了局部網絡管理時才會用到該位。

現在使用CAN總線協議為主干網的車型上，網段的數量約為4-6個，一般多為整車使用AUTOSAR網絡管理，不做局部網絡管理。但是實際在整車上根據不同的功能需求，可以將整多個網段定義為不同的局部網絡管理，這樣能夠更進一步的節省能耗（貌似也節省不了多少），通信效率更高。

關于源地址和控制位向量，需要注意：

• 不是必須的，NM報文中可以不使用這兩個位。

2.如果使用，推薦在byte(0)和byte(1)這兩個字節。可以源地址在byte(1)，CVB在byte(0)。它們的位置可以通過CanNmPduNidPosition配置

（3）用戶自定義數據User Data

在部分字節OEM可根據自身需求定義。一般可定義喚醒原因、維持喚醒原因、NM狀態、PNC信息等內容。

網絡管理報文很重要的一個作用是幫助排差整車異常喚醒或不休眠（延時休眠）的問題，如果User Data使用得當，非常有利于睡眠喚醒問題的排查。

2.1.3 網絡管理報文相關的測試

首先要測試NM報文的格式是否符合OEM的定義，源地址和ID是否對應；

其次需要測試CVB每一位的置位情況是否正確，例如主要喚醒時（例如KL15 on）Active wakeup bit是否置1；

第三需要測試CVB每一位的初始化或重置是否正確。控制器在上電初始化時要將CVB各位置0.

2.2 AUTOSAR網絡管理的狀態

AUTOSAR規定有三種狀態：睡眠模式（bus sleep mode）、預睡眠模式（Perpare Bus Sleep mode）和網絡模式（Network mode）。

2.2.1睡眠模式(Bus-Sleep mode)

ECU上30電后要先進行初始化,初始化完成后默認進入睡眠模式。在初始化過程中ECU不能向總線發送報文甚至顯性電平。在睡眠模式中控制器既不接收也不發送報文，但激活了喚醒源的監測，即如果此時總線上有網絡管理報文在發送（發送成功了或NoAckError后自動重發），CAN NM模塊需要通知應用層接收到了喚醒源，并由應用層決定是否被喚醒。

睡眠模式的作用主要是降低功耗，車輛在不使用的狀態下（滿足休眠條件下），控制器進入睡眠模式后的工作電流非常小。

在睡眠狀態中如果總線上由應用報文持續發送，控制器是否給ACK取決于所選用的收發器。例如使用TJA 1041，控制器在睡眠狀態中收到應用報文后給收發器上電，從而給出ACK應答。但應用報文并不是控制器的喚醒源，應答一段時間后就又關閉首發器。

如果使用TJA1043，則在睡眠狀態中接收到應用報文會持續的給出ACK。

現在有些收發器在自身就帶有屏蔽寄存器（TJA1042T\1043T\1145），可以自行判斷收到的信號是否為喚醒源，進而自己覺得是否需要給出ACK應答。

需要注意，控制器在未上30電時的狀態不屬于睡眠狀態。不同的控制器在上30電后的初始化時間也不相同。

2.2.2預睡眠狀態(Perpare Bus-Sleep mode)

預睡眠狀態的目的是確保網段上所有的節點有時間停止當前的網絡活動（有些ECU在進入睡眠前可能還要往EEPROM中存儲數據、等待一些執行機構完成動作等）在預睡眠模式控制器既不發送也不接收報文（CanNmTimeoutTime超時后如果發送緩存里面還有列隊中的報文還是要發送的）。在預睡眠狀態中控制器的收發器還未關閉，此時網總線持續發送應用報文，仍可關閉。

ECU進入預睡眠狀態后會啟動CanNmWaitBusSleepTime定時器，該定時器可配置，且不能重啟，超時后ECU進入睡眠狀態。

AUTOSAR規定在預睡眠狀態中如果接收診斷請求，則需要進入Network mode，默認進入Repeat Message State。

2.2.3網絡狀態（Network Mode）

網絡模式包含三種內在的狀態：

• 重復報文狀態（Repeat Message state）

• 正常工作狀態（Normal Operation State ）

• 準備睡眠狀態（Ready Sleep State）

ECU從睡眠狀態或預睡眠狀態跳轉到網絡狀態時均要先進入重復報文狀態。進入重復報文狀態后，啟動CanNmRepeatMessageTimer定時器。該定時器不會重啟，超時后就會進入正常工作狀態或準備睡眠狀態。

重復報文狀態的目的是定義了所有節點的NM模塊stay active的最小時間。因為進入重復報文狀態后都會發送自身NM報文，所有節點均網絡在線，可用于當前的有哪些節點在線。在該狀態ECU正常發送和接收NM報文和周期應用報文。

ECU進入重復報文狀態后會發送自身NM報文，并啟動NM-Timeout Timer(也可能是先接收到NM報文，同樣會啟動該定時器)，ECU成功發送或成功接收一幀NM報文后都會重啟該定時器。

當CanNmRepeatMessageTimer超時后，如果控制器維持有本地喚醒條件（有請求網絡通信的需求）則會進入正常工作狀態。

我們在車輛的使用過程中，絕大部分時間均處在正常工作狀態。同樣的在正常工作作態，ECU成功發送或成功接收一幀NM報文就會重啟NM-Timeout Timer定時器。因為該定時器可以重啟，正常工作狀態確保了節點可以長期維持網絡喚醒，只要它對網絡通信有需求。在該狀態ECU正常發送和接收NM報文和應用報文。

當CanNmRepeatMessageTimer超時后，如果ECU沒有本地喚醒條件被觸發（沒有請求網絡通信的需求）則會進入準備睡眠狀態。該狀態是用來等待其他節點停止網絡請求，同時進入預睡眠狀態。在該狀態中ECU正常發送應用報文，不在發送網絡管理報文。正常接收網絡管理報文和應用報文。當成功接收到一幀網絡管理報文后會重啟NM-Timeout Timer，使自身維持在準備睡眠狀態。

2.3 AUTOSAR網絡管理的狀態跳轉

在開始介紹這部分內容前，需要先明確幾個概念。

兩個狀態：NetworkRequest和NetworkrRleased。這是NM模塊內部（或額外的，不屬于上述的三種模式）的網絡管理狀態，當處在NetworkRequest狀態時，說明ECU有網絡通信的請求，會持續發送NM報文，維持著整個網段的喚醒；當處在NetworkrRleased狀態時，說明ECU沒有網絡通信的請求，不在發送NM報文，只發送應用報文，等待所有節點釋放網絡后同時進入預睡眠狀態。

兩類事件：本地喚醒事件和遠程喚醒事件。本地喚醒事件也可稱為主動喚醒事件，意味著ECU自身的本地喚醒條件被觸發，需要自身請求網絡，進而開發發送NM報文。例如最常見的KL15電，在車上，當KL15繼電器閉合后，很多連接在KL15電的控制器被同時觸發本地喚醒事件，同時請求網絡，均要發出自身的NM報文。車輛在正常工作狀態中，KL15繼電器是閉合的，所有的有KL15電的節點均有請求網絡通信的需求。遠程喚醒事件，意味著ECU自身不需要主動請求網絡通信，但是其它節點有通信需求，這個時候ECU只需要發送應用報文不發送NM報文，即維持在準備睡眠狀態即可。即本地對應主動，遠程對應被動。

綜上，當觸發本地喚醒條件時，會使NM模塊進入NetworkRequst狀態，會周期的發送NM報文；當收到遠程喚醒事件時，會使NM模塊進入NetworkRleased狀態，重復報文狀態后不在發送NM報文，進入準備睡眠狀態等待所有節點都釋放網絡。

兩個特征：低功耗和同睡（同醒，不是嚴格的同一時刻被喚醒）。使用網絡管理的最終目的是為了降低能耗；整車所有做AUTOSAR的NM簇要同睡同醒。當總線上某個節點主動或被動喚醒，會同時喚醒其它節點（以無局部網絡為例），當所有節點都釋放網絡后，等NM-Timeout Timer超時后同時進入預睡眠狀態。

一般在多網段的車型上，網關節點都是最后一個釋放網絡的。網關最后釋放網絡，它的NM-Timeout Timer超時后所有網段的節點同時進入預睡眠狀態（無局部網絡管理）。網關要實現最后一個釋放網絡需要做一些特殊的策略，例如接收到其它節點的NM報文會作為網關的本地喚醒事件，使網關維持在正常工作狀態。當其它所有節點都釋放網絡后，網關再延時一段事件釋放網絡，確保了所有節點同時NM-Timeout Timer超時。

來源：知乎@求正宇

https://zhuanlan.zhihu.com/p/71141532