01

網(wǎng)絡(luò)管理初識

為了更加通俗易懂地介紹網(wǎng)絡(luò)管理，先來構(gòu)建一個例子來進行說明，如下所示：

對該圖稍作說明：

對于一個控制器而言，它可能存在多種喚醒源，包括本地喚醒和網(wǎng)絡(luò)喚醒等方式，圖中這兩種方式都存在；?? ?

對于一個控制器參與CAN通訊，其他硬件組成有CAN收發(fā)器，CAN控制器和微控制器；

不同CAN總線網(wǎng)絡(luò)通過網(wǎng)關(guān)才能進行通訊。

當整車處于休眠狀態(tài)，即所有的控制器都睡覺了，在整車某個休眠喚醒場景下，制動踏板行程傳感器BPS感知到變化了，從而喚醒的硬線信號有了變化，被IEB檢測到了，那么處于休眠的IEB將被喚醒，對應(yīng)著圖中1區(qū)域，這里IEB稱為主動喚醒節(jié)點。

此時，為了實現(xiàn)這個喚醒場景的功能，需要參與其他一些控制器，比如EPS和VCU，稱為它倆為被動喚醒節(jié)點，這就意味著IEB需要去喚醒他倆。如果采用CAN總線的喚醒方式，則IEB可以通過網(wǎng)管報文去喚醒EPS和VCU，大致過程是：IEB被傳感器BPS喚醒后，它的網(wǎng)絡(luò)管理狀態(tài)會產(chǎn)生變化，由睡覺模式轉(zhuǎn)為網(wǎng)絡(luò)模式。

然后IEB會發(fā)出網(wǎng)管報文，EPS和VCU的CAN收發(fā)器會收到該網(wǎng)管報文，識別到需要喚醒，最后它們也會發(fā)網(wǎng)管報文，告訴IEB醒來了，可以一起搞事情，對應(yīng)到上圖的234部分。

在這個過程中，實現(xiàn)其實很復雜，有幾個層面的問題值得深入探究：

一是功能層面，整車哪些功能有休眠喚醒場景？誰是主動喚醒節(jié)點，誰是被動喚醒節(jié)點？

二是控制器層面：對于每個休眠喚醒場景，主動喚醒節(jié)點是怎么被喚醒，被動喚醒節(jié)點又是怎么被總線喚醒的？關(guān)于網(wǎng)絡(luò)管理狀態(tài)機，這些控制器之間是如何管理網(wǎng)絡(luò)狀態(tài)？關(guān)于網(wǎng)絡(luò)管理報文，IEB發(fā)送網(wǎng)管報文應(yīng)該是怎樣的？而EPS和VCU的又是怎樣的？

02

為什么需要網(wǎng)絡(luò)管理？

在回答上面的這些問題之前，先弄清楚下整車為什么需要進行網(wǎng)絡(luò)管理，我們知道隨著汽車行業(yè)的快速發(fā)展，從燃油車到混動車和純電動車，從傳統(tǒng)的機械鑰匙到遙控鑰匙再到無鑰匙進入PEPS，汽車部署控制器越來越多。下面列舉上世紀和當今汽車的整車網(wǎng)絡(luò)拓撲：

Source: Global B 電子電氣架構(gòu)，預示了通用的下一個十年。

Source: Global B 電子電氣架構(gòu)，預示了通用的下一個十年。

不難理解，越來越多的控制器部署到汽車電子電器架構(gòu)，意味著可以實現(xiàn)更多的功能，同時也意味著更多的能量消耗。另外，日益復雜的網(wǎng)絡(luò)拓撲對控制器間如何協(xié)同工作提出巨大的挑戰(zhàn)。為了節(jié)能減小耗電，某些時刻不需要工作的控制器應(yīng)該休眠；但某些時刻，又需要休眠的控制器立馬醒來參與工作。因此，需要一種控制機制或策略，即網(wǎng)絡(luò)管理策略，使得通訊拓撲網(wǎng)絡(luò)中的ECU節(jié)點能有序地休眠和喚醒，這樣就可以保證汽車功能的同時盡可能節(jié)省電量。

03

結(jié)合硬件來了解喚醒

當車輛處于長時間停止使用或待機狀態(tài)時，控制器會進入休眠模式以降低功耗。在需要時，控制器又能被喚醒以響應(yīng)特定事件或指令，如車門開關(guān)、遙控鑰匙信號等。這里，首先涉及到喚醒源，然后喚醒源作用在控制器硬件，最后一個控制器通過CAN總線網(wǎng)絡(luò)作用到另外的控制器，下面來詳細了解這些內(nèi)容。

3.1 喚醒源

先聊下喚醒源，常見的喚醒源有：本地喚醒，網(wǎng)絡(luò)喚醒和RTC喚醒等。本地喚醒是指某些控制器可以通過特定的觸發(fā)信號被喚醒，比如KL15硬線，某些傳感器喚醒引腳信號。當這些觸發(fā)信號被檢測到時，控制器可以被喚醒以執(zhí)行相應(yīng)的操作。

1）KL15硬線喚醒

KL15是汽車電子中的一個標準電源信號，常用于控制器的供電。KL15硬線信號在車輛點火時處于高電平狀態(tài)，表示電源已連接。KL15硬線喚醒是指通過監(jiān)測KL15信號的狀態(tài)變化來喚醒控制器或其他電子模塊，并開始執(zhí)行相應(yīng)的操作，例如初始化或執(zhí)行特定任務(wù)等。下圖所示是一種最常見的KL15硬線喚醒方式。

Source: KL15和KL30 - Smah - 博客園 (cnblogs.com)

2）傳感器喚醒

做底盤域控開發(fā)時，就碰到制動踏板傳感器有喚醒引腳。某些工況下，駕駛員踩制動踏板，制動踏板傳感器感知到后，通過其喚醒引腳以硬線形式去喚醒某些控制器，比如IEB，從而及時觸發(fā)這些車輛穩(wěn)定性控制系統(tǒng)或防抱死制動系統(tǒng)等安全系統(tǒng)的操作。

3）CAN網(wǎng)絡(luò)喚醒

CAN網(wǎng)絡(luò)喚醒源是指能夠通過CAN總線發(fā)送網(wǎng)絡(luò)報文，以喚醒處于休眠狀態(tài)的設(shè)備或模塊。這些網(wǎng)絡(luò)報文可以是預定義的標準報文，也可以是自定義的擴展報文。接收到特定的喚醒報文后，設(shè)備或模塊會解析該報文并進行相應(yīng)的喚醒操作。比如，當CAN收發(fā)器監(jiān)控到總線電平變化或者特定報文時，就可以通過INH引腳使能電源芯片供電，從而喚醒ECU。

Source: 你知道BMS有哪些內(nèi)外部的喚醒信號嗎 (zhihu.com)

CAN網(wǎng)絡(luò)喚醒從喚醒方式來進一步劃分的話，可以分為：

喚醒幀（Wake-up Frame）：CAN網(wǎng)絡(luò)中的節(jié)點可以通過發(fā)送喚醒幀來喚醒其他節(jié)點或整個系統(tǒng)。喚醒幀是一種特殊的CAN數(shù)據(jù)幀，它包含喚醒標識符和相關(guān)的控制信息，用于告知接收節(jié)點進行喚醒操作。

連續(xù)監(jiān)聽（Continuous Listening）：某些CAN網(wǎng)絡(luò)實現(xiàn)中，節(jié)點可以設(shè)置為持續(xù)監(jiān)聽CAN總線，以偵聽特定的喚醒幀或其他相關(guān)報文。當接收到指定的報文時，節(jié)點將執(zhí)行喚醒操作。

4）RTC喚醒

RTC喚醒（Real-Time Clock Wakeup）是一種可以在預定的時間點或間隔后喚醒控制器的喚醒方式。在汽車中，RTC喚醒通常用于控制器的定時操作，通過配置RTC喚醒功能，可以在設(shè)定的時間點喚醒相關(guān)控制器，以執(zhí)行特定的任務(wù)或操作。例如，BMS可以利用RTC喚醒來進行電池狀態(tài)監(jiān)測、數(shù)據(jù)記錄等操作，以確保電池在休眠期間得到適當?shù)墓芾砗捅Ｗo。

Source: 大普通信高精度高可靠性RTC，為新能源汽車BMS安全管理助力 (laoyaoba.com)

3.2 控制器相關(guān)硬件?

喚醒源作用到控制器硬件后，有可能直接喚醒微控制器，也有可能經(jīng)電源芯片間接喚醒微控制器，可以先了解下汽車控制器硬件的組成，其通常由微處理器和相關(guān)的傳感器和執(zhí)行器組成。汽車控制器實物如下圖所示，上面有很多芯片和電子元器件，它們能夠?qū)崿F(xiàn)怎么的功能呢？

簡化一下大概像下圖這樣：?

控制器的功能有電源管理，傳感器信號采集，執(zhí)行器驅(qū)動和通訊等功能，對于CAN通訊功能的硬件部分，通常由CAN總線，終端電阻，CAN收發(fā)器，CAN控制器和微控制器組成，如下示意：

在控制器上，CAN總線就不是雙絞線形式，而是CAN-H和CAN-L兩個PIN腳接入；終端電阻可能沒有而在其他控制器上，CAN收發(fā)器一定有。CAN收發(fā)器最主要作用是提供物理層的接口功能和進行信號轉(zhuǎn)換。當接收報文時，將輸入的差分電壓轉(zhuǎn)化成邏輯電平（顯性/隱性）；當發(fā)送報文時，將邏輯電平轉(zhuǎn)換成差分電壓輸出。而涉及到網(wǎng)絡(luò)喚醒的話，那么它能夠接收、解析和處理喚醒信號，實現(xiàn)對休眠節(jié)點的喚醒操作，通常操作是使能電源芯片給微控制器上電的作用。

在硬件層面，CAN收發(fā)器常見于2種形式，一種是作為一塊獨立的芯片，如下圖示意；另一種是被集成到某些芯片，比如集成到SBC中。

Source：TLE9252手冊

CAN控制器的作用是管理CAN總線上的通信活動。它負責處理消息的發(fā)送和接收，確保消息的正確性、完整性和時序性。CAN控制器通常集成在微控制器或通信芯片中，用于與其他CAN節(jié)點進行通信，通常一個微控制器中包括多個CAN控制器，如下示意的英飛凌TC系列芯片就有幾個。

由這些器件構(gòu)成的CAN通訊硬件，常見的一種C網(wǎng)絡(luò)喚醒方式是這樣：通過CAN收發(fā)器的喚醒引腳或中斷功能來觸發(fā)喚醒信號，然后使用喚醒信號來激活電源芯片，再由電源芯片提供電源給微控制器。這種方式中，當CAN收發(fā)器接收到特定的喚醒幀或觸發(fā)條件時，會通過喚醒引腳發(fā)送喚醒信號給電源芯片，激活電源芯片以為微控制器提供電源。

結(jié)合之前的本地喚醒源和當下的整車通訊網(wǎng)絡(luò)架構(gòu)，喚醒機制通常是：本地喚醒某個控制器，然后這個控制器再通過CAN網(wǎng)絡(luò)喚醒其所在總線的相關(guān)其他控制器，這樣喚醒的這些控制器共同來實現(xiàn)某一個功能。比如鎖車休眠之后插槍交流充電工況，CP硬線信號喚醒OBC，OBC再發(fā)送網(wǎng)絡(luò)管理報文喚醒BMS等控制器，最終實現(xiàn)交流充電功能。

04

休眠喚醒表

接著從整車休眠喚醒功能層面來進行介紹，上面的IEB例子僅是眾多休眠喚醒場景中的一個，再多看兩個例子：

一臺純電動汽車關(guān)門鎖車下電后進入休眠，在它處于休眠這期間，實際上存在很多種喚醒場景。比如用戶有用車需求了，可能通過手機端APP提前遠程開啟空調(diào)或座椅加熱等功能，那么這時就需要喚醒汽車上的很多控制器。首先TBOX需要被喚醒，然后TBOX醒來后會喚醒上高壓相關(guān)的控制器，再喚醒空調(diào)，加熱器的控制器等。? ??

Source：遠程啟動功能可以開空調(diào)嗎？夏天遠程啟動車開空調(diào)傷車嗎

用戶發(fā)現(xiàn)汽車電量不充足了，那么會有充電需求，插槍充電，這時如果插上慢充槍，那么OBC會先被喚醒，識別出插槍行為及其慢充槍的連接狀態(tài)，然后OBC喚醒BMS和其他相關(guān)的控制器進行充電。

Source: 【圖】熱門電動汽車新聞_新能源汽車行業(yè)資訊_電動邦 (diandong.com)

也就是說，通過對一個又一個整車功能和應(yīng)用場景的詳細分析，最終能夠匯總出整車所有的休眠喚醒場景需求，通常會用一個表格來管理，俗稱休眠喚醒表。休眠喚醒表一般有哪些內(nèi)容？根據(jù)上述所講的邏輯：

首先休眠喚醒需求，定義有哪些休眠場景或喚醒場景。針對每個喚醒場景，喚醒的條件是什么，針對每個休眠場景，休眠的條件又是什么。

其次是對于每個喚醒場景，哪些控制器需要參與？誰是主動喚醒節(jié)點，誰又是被動喚醒節(jié)點，每個控制器需要做什么事情。

然后呢，對于每個喚醒或休眠場景，有無喚醒或休眠的時間要求。如下圖示意（綠色代表主動喚醒節(jié)點）：

注意休眠喚醒表是網(wǎng)絡(luò)管理最核心的內(nèi)容，正是有了這樣的需求，才有采用何種網(wǎng)絡(luò)管理方法，來實現(xiàn)預期的休眠喚醒行為。

05

網(wǎng)絡(luò)管理策略

5.1 AutoSAR NM 狀態(tài)機

當整車處于休眠狀態(tài)，如果出現(xiàn)了喚醒場景，那么一定有來自控制器內(nèi)部的本地喚醒請求，然后才有喚醒網(wǎng)絡(luò)請求，體現(xiàn)在AutoSAR NM狀態(tài)機就是本地喚醒源使得IEB進入總線睡眠模式（BusSleep Mode），成為主動喚醒源，然后IEB就會從總線睡眠模式跳轉(zhuǎn)到網(wǎng)絡(luò)模式（Network Mode）的重復報文狀態(tài)（Repeat Message State）。? ??

在重復報文狀態(tài)，主動喚醒節(jié)點IEB會開始以快發(fā)形式發(fā)送網(wǎng)管報文，而且會連續(xù)發(fā)送一定的數(shù)量網(wǎng)管報文，比如以20ms的發(fā)送周期連續(xù)快發(fā)5幀網(wǎng)管報文。

而被動喚醒節(jié)點EPS和VCU接收到IEB的網(wǎng)管報文，同樣它們的狀態(tài)會跳轉(zhuǎn)到重復報文狀態(tài)，也會周期性發(fā)送不同ID的網(wǎng)管報文，但不是快發(fā)形式，通常是500ms的發(fā)送周期，具體發(fā)多少幀取決具體需求。另外，對于被動喚醒節(jié)點EPS和VCU需要連續(xù)接收到IEB幾幀網(wǎng)管報文，可能是一幀，也可能是兩幀等，取決于具體需求。

另外在這個狀態(tài)，對于主動喚醒節(jié)點IEB除了需要發(fā)送網(wǎng)管報文，還需要發(fā)送應(yīng)用報文，但第一幀是需要先發(fā)網(wǎng)管報文，再發(fā)應(yīng)用報文。

當IEB處于重復報文狀態(tài)一段時間后，就會跳轉(zhuǎn)到正常運行狀態(tài)（Normal Operation State）,主動喚醒節(jié)點IEB將繼續(xù)周期性發(fā)送網(wǎng)管報文，比如500ms的發(fā)送周期，以此告訴其他節(jié)點自己在正常通信。

而EPS和VCU可能繼續(xù)周期性發(fā)送報文，也可能會停發(fā)，取決于節(jié)點是否需要與與總線上其他節(jié)點進行信息交換。

當節(jié)點需要主動與總線上其他節(jié)點進行信息交換時，就通過發(fā)送網(wǎng)管報文來請求網(wǎng)絡(luò)，并將其網(wǎng)絡(luò)狀態(tài)設(shè)置為“網(wǎng)絡(luò)請求”；

當節(jié)點不需要主動與總線上的其他節(jié)點進行交互時，就將網(wǎng)絡(luò)狀態(tài)設(shè)置為“網(wǎng)絡(luò)釋放”，節(jié)點在“網(wǎng)絡(luò)釋放”狀態(tài)下依然需要響應(yīng)總線上其他節(jié)點的網(wǎng)絡(luò)請求。

5.2 AutoSAR NM 網(wǎng)絡(luò)管理報文

網(wǎng)絡(luò)管理報文定義如下表：

Byte0 用于發(fā)送源節(jié)點ID，每一個 ECU 都會被分配一個唯一的ID，來告知接收節(jié)點該網(wǎng)管報文是由哪個節(jié)點發(fā)送的。比如定義IEB的網(wǎng)管報文ID為0x410, 則節(jié)點ID為0x10；同樣地，EPS的網(wǎng)管報文ID為0x412, 則節(jié)點ID為0x12；VCU亦是如此邏輯。??

Byte1控制位向量，非常重要，這里著重介紹Bit0, 4, 6。

Bit 0 : 重復報文狀態(tài)請求位，用來表示有無請求重發(fā)報文狀態(tài)，1則有，0則無；

Bit 4 : 主動喚醒位，用來表示是否為主動喚醒網(wǎng)絡(luò)，1為主動喚醒，0為被動喚醒；

Bit 6 : 局部網(wǎng)絡(luò)信息位，用來表示網(wǎng)管報文包含PNC信息，如果網(wǎng)絡(luò)管理有使用到PN功能，那么該位會被置為1，否則為0；

其他位暫時預留。

06

休眠喚醒表與網(wǎng)絡(luò)管理

網(wǎng)絡(luò)管理是指車輛（下電，Power off）休眠之后，喚醒需要工作的控制器一起去實現(xiàn)相應(yīng)的整車功能。說到底就是需要結(jié)合好休眠喚醒表和網(wǎng)絡(luò)管理策略才有更完善的整車功能和行為，那他倆是如何相互結(jié)合的呢？

首先是休眠喚醒表與網(wǎng)絡(luò)管理報文相聯(lián)系，首先是網(wǎng)絡(luò)管理報文的Byte1（CBV），對應(yīng)上表中的某個場景滿足，綠框打勾的那個ECU就是主動喚醒節(jié)點，那么該ECU的網(wǎng)絡(luò)管理報文Byte1的Bit4就應(yīng)該置1；其次，與網(wǎng)絡(luò)管理報文Byte 2-7相關(guān)，即User data。就結(jié)合本文IEB例子，某個喚醒場景需要實現(xiàn)底盤域控相關(guān)功能，需要喚醒IEB, EPS, EPB和VCU，其中IEB是主動喚醒節(jié)點，那么對于IEB的網(wǎng)絡(luò)管理報文的User data可以如下圖這樣的定義：

這樣通過休眠喚醒需求分析各個場景，最終可以提煉出每一個控制器作為主動喚醒節(jié)點，它需要去喚醒哪些控制器或網(wǎng)絡(luò)。因此可以確定每個控制器的網(wǎng)絡(luò)管理報文，不難理解，byte0和byte1。同時針對不同休眠或喚醒場景，網(wǎng)管報文的user data有所區(qū)別，如何做到場景與網(wǎng)管報文內(nèi)容一一映射，通常會定義另一幀報文，用來表明當前是哪個或哪幾個請求條件或釋放條件滿足。另外，采取何種網(wǎng)絡(luò)管理策略其實會影響休眠喚醒表的定義，比如采用PN，那么在休眠喚醒表中，是需要定義清楚PN cluster的。對于PN，有需要的話，可關(guān)注開心果 Need Car。

07

代碼的角度

?

?

/***************************************************************************************************
 Function name    : CanNm_InternalMainProcess
 Syntax           : void CanNm_InternalMainProcess( const NetworkHandleType CanNm_NetworkHandle )
 Description      : This is an internal main function of CANNM which does state machine processing
                    for all channels.
 Parameter        : CanNm_NetworkHandle - Identification of the CANNM-channel
 Return value     : None
 ***************************************************************************************************/

?

?

?

?

/***************************************************************************************************
 Function name    : CanNm_NetworkRequest
 Description      : This is the AUTOSAR interface to request the network, since ECU needs to
                    communicate on the bus. This API shall be called by Nm.
 Parameter        : nmChannelHandle - Identification of the NM-channel
 Return value     : E_OK - No error
                  : E_NOT_OK - Requesting of network has failed
 ***************************************************************************************************/

?

?

?

?

?

/***************************************************************************************************
 Function name    : CanNm_NetworkRelease
 Description      : This is the AUTOSAR interface to release the network, since ECU doesn't have to
                    communicate on the bus. This API shall be called by Nm.
 Parameter        : nmChannelHandle - Identification of the NM-channel
 Return value     : E_OK - No error
                  : E_NOT_OK - Releasing of network has failed
 ***************************************************************************************************/

?

?

審核編輯：黃飛