一文詳解整車網絡管理指南

01

網絡管理初識

為了更加通俗易懂地介紹網絡管理，先來構建一個例子來進行說明，如下所示：

對該圖稍作說明：

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

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

不同CAN總線網絡通過網關才能進行通訊。

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

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

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

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

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

二是控制器層面：對于每個休眠喚醒場景，主動喚醒節點是怎么被喚醒，被動喚醒節點又是怎么被總線喚醒的？關于網絡管理狀態機，這些控制器之間是如何管理網絡狀態？關于網絡管理報文，IEB發送網管報文應該是怎樣的？而EPS和VCU的又是怎樣的？

02

為什么需要網絡管理？

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

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

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

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

03

結合硬件來了解喚醒

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

3.1 喚醒源

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

1）KL15硬線喚醒

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

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

2）傳感器喚醒

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

3）CAN網絡喚醒

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

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

CAN網絡喚醒從喚醒方式來進一步劃分的話，可以分為：

喚醒幀（Wake-up Frame）：CAN網絡中的節點可以通過發送喚醒幀來喚醒其他節點或整個系統。喚醒幀是一種特殊的CAN數據幀，它包含喚醒標識符和相關的控制信息，用于告知接收節點進行喚醒操作。

連續監聽（Continuous Listening）：某些CAN網絡實現中，節點可以設置為持續監聽CAN總線，以偵聽特定的喚醒幀或其他相關報文。當接收到指定的報文時，節點將執行喚醒操作。

4）RTC喚醒

RTC喚醒（Real-Time Clock Wakeup）是一種可以在預定的時間點或間隔后喚醒控制器的喚醒方式。在汽車中，RTC喚醒通常用于控制器的定時操作，通過配置RTC喚醒功能，可以在設定的時間點喚醒相關控制器，以執行特定的任務或操作。例如，BMS可以利用RTC喚醒來進行電池狀態監測、數據記錄等操作，以確保電池在休眠期間得到適當的管理和保護。

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

3.2 控制器相關硬件?

喚醒源作用到控制器硬件后，有可能直接喚醒微控制器，也有可能經電源芯片間接喚醒微控制器，可以先了解下汽車控制器硬件的組成，其通常由微處理器和相關的傳感器和執行器組成。汽車控制器實物如下圖所示，上面有很多芯片和電子元器件，它們能夠實現怎么的功能呢？

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

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

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

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

Source：TLE9252手冊

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

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

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

04

休眠喚醒表

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

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

Source：遠程啟動功能可以開空調嗎？夏天遠程啟動車開空調傷車嗎

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

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

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

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

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

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

注意休眠喚醒表是網絡管理最核心的內容，正是有了這樣的需求，才有采用何種網絡管理方法，來實現預期的休眠喚醒行為。

05

網絡管理策略

5.1 AutoSAR NM 狀態機

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

在重復報文狀態，主動喚醒節點IEB會開始以快發形式發送網管報文，而且會連續發送一定的數量網管報文，比如以20ms的發送周期連續快發5幀網管報文。

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

另外在這個狀態，對于主動喚醒節點IEB除了需要發送網管報文，還需要發送應用報文，但第一幀是需要先發網管報文，再發應用報文。

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

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

當節點需要主動與總線上其他節點進行信息交換時，就通過發送網管報文來請求網絡，并將其網絡狀態設置為“網絡請求”；

當節點不需要主動與總線上的其他節點進行交互時，就將網絡狀態設置為“網絡釋放”，節點在“網絡釋放”狀態下依然需要響應總線上其他節點的網絡請求。

5.2 AutoSAR NM 網絡管理報文

網絡管理報文定義如下表：

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

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

Bit 0 : 重復報文狀態請求位，用來表示有無請求重發報文狀態，1則有，0則無；

Bit 4 : 主動喚醒位，用來表示是否為主動喚醒網絡，1為主動喚醒，0為被動喚醒；

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

其他位暫時預留。

06

休眠喚醒表與網絡管理

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

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

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

?

?

審核編輯：黃飛