AutoSAR之基礎篇CanNM

駕駛哥

2021年4月8日 10:23

瀏覽：3006 收藏：1

知圈 | 進“車載芯片社群”請加微信13636581676，備注芯片

前言：首先，問大家幾個問題，你清楚：

為什么要引入網絡管理呢？上電同時啟動，下電同時關閉，它不香嗎？
你知道車上的ECU節點可以分為哪幾種類型嗎？
汽車啟動時，ECU之間怎么保持同步喚醒的呢？
下電時，ECU又是怎樣協同罷工的呢？
汽車熄火后，什么樣的ECU會繼續工作呢？

這篇，我們來一起探索并回答這些問題。為了便于大家理解，以下是本文的主題大綱：

網絡節點類型

汽車上ECU節點千千萬萬，不可能ignition On時所有ECU都正常工作，而是當用戶需要請求相關功能時，參與該功能的相關ECU節點才需要啟動起來，否則帶來的只是過多對電池的無用消耗。

為了更好的去利用整車的能源，防止出現不必要的電池浪費，網絡管理（Network Management，以下簡稱NM）便可以很好的解決此類問題，最大可能的高效利用整車電池能源，節約用車成本，延長電池使用壽命。

雖然汽車上網絡總線類型多種多樣，有CAN，FlexyRay、Lin、Ethernet等，但基本原理相似，本文將以最為常見的CAN總線的NM來講述，舉一反三，對于其他總線的NM，AUTOSAR也有相關規范，大家可以自行去閱讀學習。

一般而言，按照喚醒方式，我們可以將ECU網絡節點類型劃分為兩大類：本地喚醒與遠程喚醒。

本地喚醒 ：喚醒源來源于自身模塊，比如常說的KL15硬線喚醒或者hardware sensor感知喚醒等；

遠程喚醒 ：喚醒源來源于自身ECU節點所在的網絡報文，該節點可以處于完全休眠狀態，一般無靜電消耗；

根據這兩大類喚醒方式，可以組合出下列四種子喚醒方式，每種方式的供電方式如下圖所示：

僅本地喚醒節點

圖1 本地喚醒節點

特點： ECU始終保持after-running狀態，當檢測到本地喚醒源之后，就會開啟網絡通信；

僅網絡喚醒節點

圖2 僅網絡喚醒節點

特點： 只有當Transceiver監控到總線電平變化或者接收到特定報文時，就會接通Vreg給到芯片供電，從而喚醒ECU；

本地+網絡喚醒節點

特點： ECU始終保持After-Running模式，當接收到本地喚醒源或者網絡喚醒源時，就會啟動ECU；

類KL15喚醒節點

特點： 僅當Power supply 連接至ECU時，ECU才會喚醒，比如常說的KL15啟動喚醒。

NM狀態機

本文對于本地喚醒方式不作過多討論，因為本地喚醒本身就是一種供應商自定義的一種喚醒方式，比較直接，不需要其他ECU節點參與，同時也不會對其他ECU節點造成影響。

但是網絡喚醒是以網絡管理報文為基礎來協同整個網絡“同睡同醒”，采用分布式的直接網絡管理方式來發送自身節點所需的網絡管理請求及自身網絡管理狀態，并接受來自網絡上其他ECU節點的網絡管理請求與狀態。

因此，對于這些NM狀態的變化我們有必要進一步研究NM狀態機的狀態及它們之間狀態轉換關系。該狀態機的狀態類型可分為“三大三小”。其中“三大”指的是Bus Sleep Mode、Network Mode、Prepare Bus-Sleep Mode；而“三小”則指得是Network Mode下的三個子狀態：Repeat Message State、Normal Operation Mode、Ready Sleep Mode。

Bus Sleep Mode

當沒有遠程喚醒或者本地喚醒請求時，ECU的Controller應當切換至Sleep模式，電流消耗將降低至最低水平，該Mode是ECU啟動時的起始狀態或者是ECU睡眠時的最終狀態。

在該模式下，NM報文以及應用報文都應該被禁止發送，但是可以被網絡上的報文喚醒。

在此特意說明一點，當Transceiver支持并使能了特定幀喚醒時，該ECU只會接受到特定的NM報文才會正常喚醒，否則就會一直處于休眠狀態，能夠不受網絡上其他報文的干擾。

如果Transiver不支持特定幀喚醒，那么網絡的任意報文都可以喚醒該ECU，如果喚醒條件不滿足，又會走休眠流程繼續睡下去，這樣“睡醒交替”的方式就是不支持特定幀喚醒的Transiver的典型特征。當然，如果整車上的NM都可以正常運作，那么就不會頻繁出現這種“睡醒交替”的方式，這種方式一般都是在做測試時才會較多的體現出來。

Network Mode

一旦進入Network Mode，計時器T_NM_Timeout就會啟動，只要成功接收到來自總線上的NM報文或者成功發送至總線NM報文，都會將該計時器T_NM_Timeout重置。

該模式又進一步細分為以下三種子狀態，RMS、NOS、RSS。

Repeat Message State（RMS）
該狀態能夠確保當ECU的狀態機從Bus-Sleep Mode或者Prepare Bus-Sleep mode切換至Network Mode時能夠及時的被網絡上其他ECU節點發現，也就是告訴其他ECU，“大家注意了，我成功上線了，請多多指教！”
當成功進入到RMS狀態時，該節點就會重新發送NM報文并開啟計時器T_REPEAT_MESSAGE，應用報文則需要等待第一幀網絡管理報文發送之后再發送。
當然，第一幀NM報文可以通過配置參數MSG_CYCLE_ OFFSET來延遲發送，降低在同一時間內的總線負載，這個配置參數默認是0 ，一般根據測試結果來做適當的調整。
在計時器T_REPEAT_MESSAGE超時之前，該節點就會一直保持在該狀態，否則將會離開該狀態。
在該狀態下也存在著兩個子狀態：

NM Immediate Transmit State
在該模式下，ECU的目的是快速喚醒整個網絡，同時該節點將會以配置參數T_NM_ImmediateCycleTime的周期發送NM報文，而發送次數則是由配置參數N_ImmediateNM_TIMES來決定，每一次成功發送，該參數就會減1，直至為0，退出該子狀態；
NM Normal Transmit State
在該模式下，ECU節點將會以正常報文周期T_NM_MessageCycle的方式來發送NM報文。

Normal Operation State（NOS）
只要ECU節點自身存在網絡通信的需要，那么ECU就會一直工作在NOS的狀態下。該狀態下NM報文的發送將會以T_NM_MessageCycle的周期來發送報文，每次報文的成功發送或接收或者計時器NM-Timeout超時都會重置該計時器NM-Timeout；
在該狀態下的NM報文以及應用報文都應該正常收發通信。
Ready Sleep State（RSS）
在該模式下，ECU節點應當停止發送NM報文。每次成功接受到來自網絡上的NM報文，計時器T_NM_TIMEROUT 就會重置，一旦T_NM_TIMEROUT 超時，那么就會離開該狀態轉而進入Prepare Bus-Sleep狀態。

Prepare Bus-Sleep Mode

一旦進入該模式，計時器T_WAIT_BUS_SLEEP就會啟動。在該模式下禁止網絡管理報文的發送，允許接受NM報文。應用報文已經在buffer中的一般允許繼續發送，但最終應該是silent bus，該ECU的Controller的狀態應當處于operational mode。一旦T_WAIT_BUS_SLEEP超時，就會進入到Bus-Sleep階段。

Passive Mode

在該模式下只接受NM報文，但不發送任何的NM報文。該模式可以通過配置得到，同時該模式應只存在于開發或者調試過程中，在正式SOP的軟件中禁止出現此種模式。

報文發送與接受狀態

在測試的過程中，需要針對網絡管理每一個狀態下的NM報文與APP報文接收與發送進行測試。如下圖所示，體現了在不同NM子狀態下的報文發送與接受狀態。

Bus-Sleep階段，只接收NM報文喚醒，不發送任何報文；
Pre-Bus-Sleep階段，同樣僅允許接收NM報文，對于早已在發送Buffer中的APP報文應發送完畢后立刻停止APP報文；
在Network Mode模式下，除了在Ready Sleep階段不允許發送NM報文之外，其余階段APP報文與NM報文正常收發；

圖5 NM過程中報文收發狀態

狀態機時間參數總結

鑒于在網絡管理各子狀態的切換過程中都依賴于各種計時器，為了便于后續狀態機切換的講述以及后續查表方便，將相關參數總結如下，以供參考。

圖6 NM計時器參數表

NM狀態機切換

NM狀態機是整個網絡管理的核心。從上述內容可知NM管理狀態機總共分為3種模式：Bus-Sleep、Pre-Bus-Sleep以及Network Mode。

其中Network Mode 又可分為3個子狀態：Repeat Message State、Normal Operation State以及Ready Sleep State。

其中Repeat Message State又可分為Immediate Transmit State與Normal Transmit State。

如圖7所示，根據以下狀態切換路徑來一一講解各個狀態的切換。

喚醒源一般可分為本地喚醒源與遠程喚醒源。

本地喚醒源 ：主要指的是基于內部計時器、傳感器、按鈕或者硬線連接或者基于內部狀態的自身請求等。
遠程喚醒源 ：主要指的是來自網絡上的NM報文或者其他相關信號，比如點火開關信號等。

在ECU被喚醒前，軟件內部狀態機應當充分實現喚醒源的可靠性檢查，如果檢查失敗，應當禁止進入Network Mode。

絕大部分情況下，需要支持NM的ECU都始終連接著KL30。在這種情況下，ECU是否被啟動（存在靜態電流消耗），則取決于網絡上是否存在任意報文或者存在特定的NM報文。需要注意的是特定的NM報文喚醒方式則取決于是否采用支持特定幀喚醒的Transiver。

NM_01(系統初始化):
當系統KL30啟動或者接收到來自網絡的喚醒源時，則會執行系統初始化，在初始化的過程中，則會執行CanNM_Init來實現NM的初始化。如果喚醒條件不滿足，ECU就會一直停留在Bus-Sleep 階段，直至滿足條件休眠或者被正常喚醒。
NM_02(Bus-Sleep to RMS):
當ECU處于Bus-Sleep階段時，如果接收到有效的NM報文，則會進入到Normal Transmit State。當進入到該階段后，在T_REPEAT_MESSAGE 超時前，ECU將按照T_NM_MessageCycle周期來傳輸報文，同時T_MESSAGE_TIMEOUT也會啟動。
NM_03(Bus-Sleep to RMS):
當ECU在Bus-Sleep階段，存在本地喚醒請求時，ECU應當主動激活網絡，并進入Immediate Transmit State階段，同時將發送的NM報文中的Active Wake up bit置為1。
在該狀態下，應當按照N_ImmediateNM_TIMES的次數發送報文周期為T_NM_ImmediateCycleTime的網絡管理報文。
NM_04:
當N_ImmediateNM_TIMES 等于0之后，NM狀態就會從Immediate Transmit State進入到Normal Transmit State。
NM_05(RMS to RMS):
在RMS階段，如果T_NM_TIMEROUT超時，當前NM狀態不會被改變，但是T_NM_TIMEROUT會被重置。當T_MESSAGE_TIMEOUT超時后，則會調用相應的exception函數通知上層進行處理。
NM_06(RMS to NOS):
當處于RMS階段時，T_REPEAT_MESSAGE超時后，ECU需要繼續保持網絡通信的需要，即通過調用CanNM_NetworkRequest函數進入到NOS階段，而ECU則會繼續按照T_NM_MessageCycle來發送NM報文。
NM_07(NOS to RMS):
在NOS階段，有兩個RMS子狀態可以到達：Immediate Transmit State 與 Normal Transmit State。如果自身節點有repeat message的需要，那么則會進入到Immediate Transmit State。如果接收到的NM中repeat message bit置1，則進入到Normal Transmit State。
NM_08(NOS to NOS):
在NOS階段，如果T_NM_TIMEROUT超時，當前NM狀態不會被改變，但是T_NM_TIMEROUT會被重置。當T_MESSAGE_TIMEOUT超時后，則會調用相應的exception函數通知上層進行處理。
NM_09(NOS to RSS):
當休眠條件滿足時，ECU就會通過CanNm_NetworkRelease函數來實現從NOS至RSS狀態。在RSS狀態下應當停發NM報文。
NM_10(RSS to NOS):
在RSS狀態下，如果存在本地喚醒請求，則可以通過CanNm_NetworkRequest函數來切換至NOS狀態。
NM_11(RSS to RMS):
在RSS狀態下，RMS存在兩種子狀態可供進入：Immediate Transmit State與 Normal Transmit State。當自身節點存在repeat message請求時，則會進入前者；當接受到外部的NM報文中repeat message bit為1時，則進入后者。
NM_12(RMS to RSS):
當ECU處在RMS狀態中的Normal Transmit State狀態下，如果T_REPEAT_MESSAGE超時且滿足休眠條件時，則會進入RSS狀態。
NM_13(RSS to Pre-Bus-Sleep):
在RSS狀態下，如果沒有本地喚醒請求或者遠程喚醒請求，在計時器T_NM_TIMEROUT 超時之后就會進入Pre-Bus-Sleep 階段，同時T_MESSAGE_TIMEOUT置為0，啟動T_WaitBusSleep計時器。
NM_14(Network Mode to Network Mode):
在Network Mode下，當成功接受或者發送NM報文時T_NM_TIMEROUT 就會被重置，重置該定時器的行為就發生在調用函數CanNM_RxIndication或者CanNM_Txconfirmation接口中。
NM_15(Pre-Bus-Sleep to RMS):
在Pre-Bus-Sleep模式下，如果存在遠程喚醒請求，則會進入到RMS階段中的Normal Transimit State。同時啟動T_REPEAT_MESSAGE。
NM_16(Pre-Bus-Sleep to RMS):
在Pre-Bus-Sleep模式下，如果存在本地喚醒請求，即調用函數接口CanNm_NetworkRequest來進入到RMS中的Immediate Transmit階段，應當按照N_ImmediateNM_TIMES的次數發送報文周期為T_NM_ImmediateCycleTime的網絡管理報文。
NM_17(Pre-Bus-Sleep to Bus-Sleep):
在Pre-Bus-Sleep模式下，如果不存在本地喚醒或者遠程喚醒請求，則進入到Bus-Sleep狀態。至于何時關閉電源控制，則可以根據自身節點類型來shutdown。

網絡管理報文結構

NM報文作為傳遞自身節點的NM狀態的重要載體，有必要仔細研究報文中每一位Bit的含義。

接下來就以CAN NM報文為例，來一同解析其報文總體結構以及各個Bit的相應含義，以便了解各個ECU節點的協同喚醒與休眠方式。

NM報文總體結構解析

如下圖8所示，根據最新的AutoSAR官方文檔的介紹：

圖8 NM報文結構

由圖可知，Byte 0表示當前節點的Source ID，比如如何當前節點發送的NM報文ID為0x514，那么該Source ID就為0x14；Byte1則為CBV，該字節中傳遞著當前節點的網絡狀態，是非常重要的字節；其余字節作為User Data給到客戶自行定義，如定義當前喚醒源有哪些？網絡管理狀態機切換過程等。

當然上述報文內容定義只是AutoSAR舉例說明，Source ID可以被分配至Byte0，Byte1或者沒有，而CBV也是可被分配至Byte0，Byte1或者沒有。這些字節內容的分配與定義一般均可以在BSW工具鏈中進行配置。