前言： 最近正好在學習CAN總線的AUTOSAR網絡管理，前期踩了很多的坑，總結了一下最近所學和大家一起學習。學的很淺，有不正確的地方請各位前輩同仁不吝賜教~

1、什么是AUTOSAR？

官方一點： AUTOSAR 就是AUTomotive Open System ARchitecture的簡稱，中文翻譯就是汽車開放系統架構。

直白一點： 將汽車電子控制單元（ECU）的軟件底層做了一個標準的封裝。使得大家都能共用一套底層軟件，只需要修改其中的一些參數，就可以匹配不同硬件，也可以匹配不同的應用層軟件。如此之后，用戶只需要專心負責應用層功能開發即可，底層都交給AutoSAR工程師就行了。

再直白一點： “就是一套寫的比較好的底層軟件”。其實現了硬件驅動的封裝（類似于STM32的庫），實現了操作系統的功能。用戶只需要開發操作系統上層的軟件應用即可（類似于基于安卓開發App）。

再再再直白一點： 各個廠家在五花八門的硬件上隨意開發，想怎么寫就怎么寫，怎么爽怎么來，導致開發一時爽，維護火葬場，如果底層硬件換掉了，上面的代碼基本就要全部推倒重來，而且不同廠家之間的代碼移植性也幾乎沒有，各個廠家和工程師都很頭大，于是AUTOSAR應運而生。AUTOSAR將各個硬件的底層接口做了封裝，以后如果換硬件，只需要配置一下AUTOSAR，告訴它我換硬件了，趕緊給我適配就可以了，上層代碼完全不需要改動就可以使用。從開發的角度來講，提高了代碼的復用性，降低了代碼的復雜度，提高了代碼的可維護性。

2、什么是網絡管理？

網絡管理的目的是使網絡中的ECU節點有序的睡眠和喚醒。在沒有通信需求的時候睡眠，在需要通信的時候喚醒，可以節約汽車電池的電量。

3、什么是CAN總線？

這個CSDN和知乎都有很多的介紹，這里就不贅述了。

4、CAN總線的AUTOSAR網絡管理報文（以下簡稱NM報文）長啥樣？

首先要明確一點，NM報文就是CAN報文。NM報文符合CAN報文的格式，由幀起始、仲裁場、控制場、數據場、CRC場、應答場、幀結尾組成。

一般廠家在設計的時候會規定好NM報文的ID范圍。

舉個例子：規定標識符在0x500到0x5FF范圍為NM報文。當在CANoe中抓取到此ID范圍內的報文，那就是NM報文。

此報文ID=0x502，那么它就是一幀NM報文

NM報文數據場

NM報文的重點在于數據場8字節里的內容：

NM報文數據場內容格式

Byte0： 這里填的是ECU的地址，或者叫ECU的ID；

此報文的ID=一個基礎值+ECU的ID，例如廠家規定基礎值為0x500，那么此報文的ID=0x500+0x8=0x508；

這里要注意區分報文的ID和ECU ID的概念，很容易混淆；

Byte1：

NM報文數據場byte1格式

這里關注下bit0和bit4：

bit0：當此位置1時強制進入RMS（下面會講到）；

bit4：告訴其他節點自身是怎么被喚醒的。

置0：被動喚醒、遠程喚醒，比如被其他節點發送的NM報文喚醒；

置1：主動喚醒、本地喚醒，比如給ECU上電；

byte2-byte7 里的user data數據由用戶自行定義。

5、CAN NM狀態介紹

AUTOSAR網絡管理有三種狀態：

睡眠模式（Bus-Sleep Mode）：當節點沒有本地網絡喚醒以及遠程喚醒請求時，ECU通訊控制器切換至睡眠模式，ECU功耗降低至適當水平；此模式下，NM報文只收不發，APP報文不收不發，當出現有效喚醒源時必須要被喚醒；

預睡眠模式（Prepare Bus-Sleep Mode）：這個狀態是為了等待總線上的所有節點能夠在進入Bus-Sleep Mode之前有時間停止節點的active狀態（如清空隊列中為發送的報文）；此模式下，NM報文只收不發，APP報文不收不發，如果緩沖區有APP報文那可以繼續發完；

網絡模式（Network Mode）：

包含3個子狀態：

重復報文狀態（Repeat Message State）：NM報文可收可發，APP報文可收可發；

正常工作狀態（Normal Operation State）：NM報文可收可發，APP報文可收可發；

準備睡眠狀態（Ready Sleep State）：NM報文只收不發，APP報文可收可發；

總結見下圖：

6、定時器及參數介紹

第5小節和第6小節的內容看一遍可能理解不了，學完下面的狀態遷移圖，再回過來多看幾遍就能理解了。

7、狀態機

現在終于來到AUTOSAR網絡管理的最難理解也是最容易使人禿頭的狀態機了，這里我不打算把每一條狀態轉換的文字描述直接貼上來，跟著我的思路，我們來一個一個看吧。

在開始之前，先了解一下各種縮略語：

BSM-睡眠模式 NM-網絡模式 PBM-預睡眠模式
RMS-重復報文模式 NOS-正常操作狀態 RSS-準備睡眠模式

01： 給ECU上電，ECU自己就會初始化進入睡眠模式。如果沒有喚醒源來喚醒此節點，那就會一直待在睡眠模式。

02+03： 當出現本地喚醒（03）或者遠程喚醒（02）時，進入RMS狀態。這里再解釋下，本地喚醒就是我自己想要主動和其他節點通信；遠程喚醒是其他節點想要和我通信。

04： 我們現在已經走到網絡模式的重復報文子狀態了。話說為什么叫重復報文子狀態呢，因為在這個狀態里的時候，ECU需要一直發送周期報文，來告訴別人：我在線，性感ECU在線陪聊，你再不來找我我就要開始想念你......

如果是走03（本地喚醒）進來的，那么需要先在NM Immediate Transmit State中以很快的周期發送N幀報文（例：以20ms的周期連續發送5幀報文），發完這N幀報文再進入到NM Normal Transmit State中以正常的周期發送報文（例：500ms為周期發送報文。這個在上面的表格里有定義）。如果是直接走02進來的，那么直接以正常周期發送NM報文就可以了。一直發到T_repeat_message定時器超時。

這一步的目的是如果是本地喚醒的話，可能此ECU下面還有很多從屬節點，當此ECU喚醒之后，需要同時喚醒其他兄弟節點一起通信，所以最開始的N幀報文周期很短，目的是為了快速、低延遲地喚醒其他節點。為什么被遠程喚醒就不需要這一步呢？歡迎大家在評論區里一起討論~

06+12： 且慢，我們先來計算一下從BSM到這一步花費了多少時間了。參考上面定時器的定義，在02或03中，最大喚醒時間為T_wake_up=200ms；在04中，T_repeat_message=1600ms。總計1800ms，差不多為2s的時間，此時ECU有可能已經不需要通信了（2019-11-29補充：ECU持續處于喚醒狀態的條件是有持續的喚醒源，例如一直有NM報文遠程喚醒、或一直有本地喚醒源例如上電）。如果還需要繼續通信，走06，進入NOS，繼續周期發送NM報文，可以收發APP報文，當不再需要通信了，就停止發送NM報文，等待T_NM_timeout超時之后走09；如果直接不需要通信了，直接走12。

10： 收到本地喚醒，進入NOS。

11： 收到NM報文的byte1字節的重復請求位如果置1，強制進入RMS。

08+14+05：T_NM_timerout定時器超時，不改變當前狀態。定時器需要重置。

13： 在RSS狀態，NM報文不可以發送。等待T_NM_TIMEOUT定時器超時后進入PBM。

15+16： PBM狀態只可以接收NM報文，其他報文不發不。收到遠程喚醒，走15；收到本地喚醒，走16。

17： 如果PBM狀態收不到任何喚醒源，在T_WAIT_BUS_SLEEP定時器超時后進入BSM。

以上就是CAN總線AUTOSAR網絡管理的內容分享。