本文首發於微信公衆號“汽車控制與人工智能”歡迎關注。
今天整理下AUTOSAR中的CAN網絡管理。
AUTOSAR中網絡管理主要使用了CAN接口(CanIf)，並提供通用網絡管理接口(NmIf)。CAN網絡管理在CAN架構中所處的位置如圖1，與其他模塊的交互如圖2。
圖1 CAN架構
圖2 網絡管理和其他模塊的聯繫
AUTOSAR網絡管理基於分散的直接網絡管理策略，這意味着每個網絡節點僅依賴於通信系統中接收或傳輸的網絡管理pdu來執行自給自足的活動。網絡管理算法基於週期性的網絡管理PDUs，通過廣播傳輸被集羣中的所有節點接收。接收網絡管理PDUs表明發送節點希望保持網絡管理集羣處於喚醒狀態。如果有節點準備進入總線休眠模式，它將停止發送網絡管理PDU，但是隻要接收到來自其他節點的網絡管理PDU，它就會延遲向總線休眠模式的轉換。如果由於不再接收網絡管理PDU而導致計時器超時，則每個節點都將啓動到總線休眠模式的轉換。
如果網絡管理集羣中的任何節點需要總線通信，則可以通過傳輸網絡管理PDU將網絡管理集羣從總線休眠模式中喚醒。
下面介紹幾個相關的概念。
喚醒請求(Wake Up Request)
喚醒請求可分爲兩種：
● 主動喚醒請求：來自模塊內部對網絡的請求。主動喚醒節點的網絡管理報文必須先於應用報文發送。
● 被動喚醒請求：來自總線上其他模塊對該模塊的網絡請求。被動喚醒的節點，發送網絡管理報文和應用報文的先後順序無特別要求。
網絡狀態（Network States）
節點的網絡狀態包括以下兩種：
● 網絡請求：模塊需要主動與總線上其他節點進行信息交換時，它必須通過發送網絡管理報文來請求網絡，並將其網絡狀態設置爲“網絡請求”；
● 網絡釋放：模塊不需要主動與總線上其他節點進行信息交換時，必須將其網絡狀態設置爲“網絡釋放”；需要注意的是，在網絡釋放狀態下模塊仍可能因總線上的其他節點請求網絡而與其進行信息交互。
總線喚醒(Bus wake up)
採用AUTOSAR CAN 網絡管理方式的ECU必須選擇符合 ISO 11898-5 標準的高速 CAN 收發器。若ECU處於低功耗模式，僅在總線上出現符合ISO 11898-5標準定義的喚醒序列，且該 ECU成功接收到該網段定義的喚醒報文時才能夠被總線喚醒。這裏這條喚醒報文必須是該網段中 ECU 的網絡管理報文。
理解上面幾個概念後，我們可以看下AUTOSAR 網絡管理模式(AUTOSAR Network Management Operational Modes)了，AUTOSAR網絡管理（以下簡稱 CanNm）包含以下三種模式： 睡眠模式(Bus-Sleep Mode)，預睡眠模式(Prepare Bus-Sleep Mode)，網絡模式(Network Mode) ，三種模式的切換過程如圖3。
圖3 網絡管理狀態切換圖
睡眠模式
當節點沒有主動網絡喚醒及被動喚醒請求時，ECU 通信控制器切換至睡眠模式，ECU功耗降低至適當水平。在睡眠模式下，節點的網絡管理報文和應用報文禁止發送，並且不能對總線上的報文進行ACK應答。同時節點在該模式下，如果檢測到有效的喚醒源，節點必須被喚醒。
預睡眠模式
在預睡眠模式下，總線活動靜止下來，最終達到總線上沒有活動，ECU通信控制器狀態處於工作模式。在該模式下，節點的網絡管理報文和應用報文禁止發送，但應該對總線上的報文進行 ACK應答。節點的網絡管理狀態必須保持預睡眠模式一段時間，一旦超時，網絡管理狀態應該離開預睡眠模式，進入睡眠模式。
網絡模式
網絡模式可分爲三種內部狀態：
重複報文狀態 (Repeat Message State)
常規操作狀態 (Normal Operation State)
準備睡眠狀態(Ready Sleep State)
重複報文狀態
重複報文狀態包含兩個子狀態：
網絡管理報文快速發送狀態
網絡管理報文正常發送狀態
NM PDU 快速發送狀態
節點在進入NM PDU快速發送狀態時，必須開啓或重置NM-Timeout Timer，爲了快速喚醒網絡，必須以快速週期發送網絡管理報文，同時不得發送正常週期網絡管理報文；所有的應用報文必須在第一幀快速NM PDU報文發送開始後延遲一定時間才能發送。在NM PDU快速發送狀態下，節點一旦接收或發送一條網絡管理報文，或者NM-Timeout Timer超時，NM-Timeout Timer會立即重置。
NM PDU 正常發送狀態
進入NM PDU 正常發送狀態後，節點必須以正常週期發送網絡管理報文。若節點因被動喚醒請求進入NM PDU正常發送狀態，必須開啓NM-Timeout Timer，同時所有的應用報文必須從節點檢測到喚醒請求後延遲Tx_Enable_Time 才能發送。在NM PDU正常發送狀態下，節點一旦接收或發送一條網絡管理報文，或者 NM Timeout Timer超時，NM Timeout Timer會立即重置。
節點的網絡管理狀態保持重複報文狀態一段時間（這段時間一般可以配置），一旦超時，網絡管理狀態會離開重複報文狀態。在該狀態下，節點的網絡管理報文和應用報文能夠正常發送。
常規操作狀態
當節點處於網絡模式因主動網絡請求需要與網絡上其他節點繼續進行通信時，必須保持在常規操作狀態。在常規操作狀態下，節點一旦接收或發送一條網絡管理報文，或者NM-Timeout Timer超時，NM-Timeout Timer應該立即重置。在該狀態下，節點的網絡管理報文和應用報文必須正常發送。
準備睡眠狀態
節點進入準備睡眠狀態後，必須停止發送網絡管理報文，所有的應用報文在NM Timeout Timer超時後必須停止發送。在準備睡眠狀態下，節點一旦接收到一條網絡管理報文，NM Timeout Timer會立刻重置。NM Timeout Timer超時，節點的網絡管理狀態應該進入預睡眠模式。
網絡管理報文(NM PDU)
網絡管理報文格式(NM PDU structure)
AUTOSAR CAN 網絡管理報文的數據場格式如下表所示:
源節點標識符(Source Node Identifier)
NM PDU的字節 0 用於發送源節點標識符，每一個 ECU 都會被分配一個唯一的標識符，來告知接收節點該 NM PDU 是由哪個節點發送的。
控制比特向量(Control Bit Vector)
NM PDU 的字節 1 被分配用於發送控制比特向量。其中：
bit 0 :重複報文狀態請求位;
bit 3 :網絡管理睡眠協調位；
bit 4 :激活喚醒位；
bit 6 :部分網絡信息位；
其他bit位暫時預留。
用戶數據域(User Data)
網絡管理報文的字節 2 到字節 7 用於發送用戶自定義的數據信息，這些字節目前各項目爲擴展預留，都被填充爲‘0x00’。
網絡管理狀態切換(Network Management State Transition)
對照圖一起看下：
（高清圖可在微信公衆號後臺回覆“網絡管理”獲取）
Condition_01
節點供電狀態從電池off切換到電池on 後，節點必須進行網絡管理模塊CanNm初始化，初始化完成後節點必須進入睡眠模式，並且需要立即具備被主動喚醒請求或者被動喚醒請求喚醒的能力；
Condition_02
當節點處於睡眠模式時，如果收到有效的網絡管理報文，那麼節點將離開睡眠模式並進入重複報文狀態中的NM PDU正常發送狀態。進入NM PDU正常發送狀態後，在計時器Repeat Message Timer超時以前，節點必須以正常週期發送網絡管理報文。在節點收到網絡管理報文時，它向總線發出的第一幀報文可以是網絡管理報文也可以是應用報文。
Condition_03
如果節點在睡眠模式下檢測到主動喚醒請求，那麼節點必鬚髮送網絡管理報文來主動喚醒網絡，在節點主動喚醒網絡的過程中，必須首先進入NM PDU快速發送狀態。當節點因主動喚醒請求需要喚醒網絡時，必須快速發送連續NM PDU報文。
Condition_04
處於NM PDU快速發送狀態的節點，在計數器爲零時，節 點 將 進 入NM PDU正常發送狀態，並開始等待一段時間後以正常週期發送網絡管理報文。
Condition_05
處於重複報文狀態下的主動請求網絡節點，如果Repeat Message Timer 發生超時，但節點的主動網絡請求仍持續存在，節點必須進入常規操作狀態。節點繼續保持以正常週期發送網絡管理報文和應用報文PDU。
Condition_06
處於常規操作狀態的節點，如果釋放所有的網絡請求，不再需要主動請求網絡，那麼它必須立即將網絡管理狀態切換到準備睡眠狀態，同時該節點必須立即停止發送網絡管理報文。
Condition_07
處於準備睡眠狀態的節點，如果檢測到主動網絡請求，節點必須立刻進入常規操作狀態，
同時必須開始以正常週期發送網絡管理報文和應用報文PDU。
Condition_08
處於重複報文狀態的NM PDU正常發送狀態的節點，如果沒有檢測到主動網絡請求，一旦 Repeat Message Timer超時，節點將進入準備睡眠狀態。
Condition_09
處於準備睡眠狀態的節點如果沒有檢測到主動網絡請求，一旦NM Timeout Timer超時，節點將進入預睡眠模式。
Condition_10
處於預睡眠模式的節點，如果收到被動喚醒請求，節點將進入重複報文狀態的NM PDU正常發送狀態。
Condition_11
處於預睡眠模式的節點，如果檢測到主動喚醒請求，節點將進入重複報文狀態的NM PDU快速發送狀態。
Condition_12
處於預睡眠模式的節點如果不再收到主動或被動喚醒請求，一旦Wait Bus-Sleep Timer超時，節點將進入睡眠模式。
Condition_13
在任何狀態下發生電池掉電，節點都將進入關閉模式，不再擁有任何通信和網絡管理的功能。
AUTOSAR網絡管理的算法與處理器無關，即它不依賴於任何處理器特定的硬件支持，因此可以在AUTOSAR範圍內的任何處理器架構上實現。
狀態轉換的時序圖
當喚醒請求（主動喚醒請求、被動喚醒請求）將節點的網絡管理狀態激活時，該節點的所有應用報文必須延遲一定時間後才能夠開始發送。網絡中的被喚醒節點網絡管理報文的發送不受 延遲時間的限制，可以在它結束前發送，但首幀網絡管理報文必須在節點進入重複報文狀態後再延遲一定時間發送，以避免被喚醒節點同時髮網絡管理報文而形成網絡擁堵。
NM信號發送的時序圖
NM信號接收的時序圖
NM協調過程
在睡眠的過程中，一旦NM Timeout Timer超時，節點所有的應用報文必須立刻停止發送。
上圖描述的案例是針對單一主動喚醒請求觸發的喚醒與睡眠過程，當多個喚醒請求交錯發生時，各喚醒請求必須遵守各自的定時參數，不會互相影響。
文中名詞解釋：
AUTOSAR:AUTOmotive Open System Architecture, 汽車開放系統架構
CAN:Controller Area Network, 控制器局域網
NM:Network Management, 網絡管理
NM PDU:Network Management protocol data unit, 網絡管理協議數據單元
CanIf:CAN Interface CAN接口
CanNm:CAN Network Management CAN網絡管理
CBV:Control Bit Vector 控制比特向量
DTC:Diagnostic Trouble Code診斷故障碼
CWU:Car Wakeup 整車喚醒
ERA:External Request Array 外部請求數組
EIRA:External and Internal Request Array 外部和內部請求數組
PNC:Partial Network Cluster 部分網絡集
PNI :Partial Network Information 部分網絡信息
作者簡介：
Demu，傳統汽車電控向智能駕駛轉變的汽車人。從事發動機控制器系統工程師和軟件工程師多年，有豐富的ECU系統和軟件設計經驗。歡迎大家一起留言交流，共同進步。
