依稀記得是2019年國慶假期后回來上班的第二天，收到售后的一封郵件，大意是：客戶剛提車1個月，已發生2次車輛饋電導致無法啟動，客戶現在正鬧著要退車，請相關工程師全力協助排查。過程不去贅述，最終結論就是車輛的TBOX被云端異常周期喚醒，TBOX隨后又喚醒整車，如此周期往復，最終導致整車小電池電量耗盡發生饋電，饋電是整車網絡管理中最不愿意見到的一幕，傷敵一千自損八百。而隨著桀驁不馴的智駕域的加入，整車網絡管理難度也隨之加大，已經開始挑戰各主機廠的企業標準。如何對包含智駕域的整車進行網絡管理，如何將有限的能量轉換為無限長的放置時間，成為主機廠會議室中一個重要的議題，本文就對擔負著減少整車能量消耗的網絡管理進行介紹。
01 喚醒休眠
整車上的部分控制器會一直由小電瓶供電，這樣才能支持你隨心所欲地遠程控車、遙控尋車等功能，但是車輛在長時間靜置的時候，如果一直保持著功能就緒狀態的電量消耗，那么車輛上小電池的電量將會急劇減少，雖然現在電動車都設計有大電池給小電池的補電策略，但這種消耗帶來的續航里程減少也是不可容忍的，為了規避這個問題，就需要對常電供電的控制器進行網絡管理。在整車網絡管理的眼中，控制器沒有了算力高低之分，沒有了高矮胖瘦之分，有的只是喚醒和休眠之分。車輛在需要控制器出苦力的時候（整車上電）將其喚醒，而在準備吃香喝辣的時候（整車下電）又將其休眠，地主老爺不過如此。對于控制器來說，喚醒的時候究竟是醒了什么，怎么醒的？休眠的時候究竟是眠了什么，怎么眠的？這是正式介紹網絡管理前必須要理清的概念。對于控制器來說，常用的喚醒方式有硬線喚醒和網絡喚醒，與之相對應的休眠方式也就有硬線休眠和網絡休眠。
（1）硬線喚醒休眠
硬線喚醒休眠是指通過電壓或電流方式喚醒休眠控制器，整車控制器常用的硬線喚醒休眠方式為KL15點火信號，在發動機啟動（燃油車）或整車上高壓（電動車）時，KL15點火信號會由0V上升到12V。不同控制器基于實現的功能不同，硬線喚醒休眠的內部邏輯也會有所區別，本節為了解釋硬線喚醒休眠的邏輯，以一個簡單系統為例，給出了一種使用KL15點火信號喚醒控制器的可能硬件架構，如圖1所示。
圖1 一種支持硬線喚醒休眠的硬件架構
該系統由CPU，承擔電源管理功能的系統基礎芯片（System Basis Chip，SBC），CAN收發器、外部存儲器、溫度傳感器、蓄電池等組成。圖1中紅色實線和虛線代表電源線、黑色實線代表信號線。在該系統中SBC直接接蓄電池，也就是由KL30供電，除非蓄電池發生故障或饋電，否則無論整車點火還是熄火，SBC都會有電。SBC的喚醒接口接KL15點火信號，在整車沒有點火或上高壓時，KL15端電壓為0，SBC判斷整車沒有喚醒需求，從而進入到Sleep模式，且不對片內其他模塊供電，其他模塊進入到OFF或Shutdown模式，此時控制器整體對外表現出一種低功耗休眠模式，控制器的靜態電流也就是這種模式下的電流，傳統控制器的靜態電流常要求20mA以內。當整車點火或上高壓，KL15端電壓升高到12V，SBC檢測到整車有喚醒需求，由Sleep模式一步步跳轉到Normal模式，并打開對CPU、CAN收發器、外部存儲器、溫度傳感器等模塊的供電，整車控制器隨之開始正常工作。當整車熄火或下高壓，SBC和CPU同時檢測到KL15端電壓下降，CPU進行下電前的準備工作，包括緩存寫入外部存儲器，并將是否準備好下電的狀態通過SPI告知SBC，SBC收到CPU準備就緒的狀態后，按照設定好的順序依次切斷其他模塊的供電，自身隨后一步步跳轉到Sleep模式。
（2）網絡喚醒休眠
網絡喚醒休眠是指通過網絡管理報文喚醒休眠控制器，CAN網絡下一種網絡喚醒硬件架構如圖2所示。
圖2一種支持網絡喚醒休眠的硬件架構
CAN收發器通過一個DCDC和KL30直連，在沒有網絡喚醒需求的時候，CAN收發器進入Sleep模式，一旦檢測到CAN總線上有網絡喚醒報文，CAN從Sleep模式恢復，INH引腳產生一個10ms的高電平信號， SBC的WAK引腳檢測到一個10ms的高電平信號， SBC被喚醒。SBC收到喚醒信號后，由Sleep模式一步步跳轉到Normal模式，并打開對CPU、外部存儲器、溫度傳感器等模塊的供電，整車控制器隨之開始正常工作，休眠過程與之類似。知道了喚醒休眠的本質，接下來就能介紹網絡管理了，目前整車上常用的網絡管理方式包括OSEK網絡管理和AUTOSAR網絡管理，下文將逐一介紹。
02 OSEK網絡管理
為了解決汽車控制技術通信和網絡發展多元化帶來的軟件移植和不同應用程序的接口協調問題，德國汽車工業界在1993年推出了OSEK（open systems and the corresponding interfaces for automotive electronics）體系，定義汽車開放式系統及接口。1994年法國標致雷諾將汽車分布式運行系統VDX（vehicle distributed executive）納入OSEK。在1995年召開的OSEK研討會上，眾多的廠商對OSEK和VDX的認識達成了共識，產生了OSEK/VDX規范(1997年發布)。它主要由四部分組成：操作系統規范(OSEK Operating System，OSEK OS)、通信規范(OSEK Communication , OSEK COM)、網絡管理規范(OSEK Net Management，OSEK NM)和OSEK實現語言(OSEK Implementation Language，OIL)。OSEK網絡管理是一個三層的狀態機，最頂層有三個狀態：NMOff，NMOn和NMShutDown，如圖3所示。
圖3 OSEK網絡管理頂層狀態機
（1）NMOff
網絡管理關閉狀態，控制器上電后首先進入的狀態，通過調用StartNM接口，控制器將離開此狀態并開始運行網絡管理，運行中的網絡管理通過調用StopNM接口，控制器將跳轉到NMShutDown狀態，進而回到此狀態并關閉網絡管理。
（2）NMOn
進入到NMOn狀態后，又會按照圖4進行網絡管理，圖4左右兩邊是兩組并行的狀態，互不影響。對于左邊來說，首先進入NMinit狀態并進行硬件初始化，初始化完成后，如果有通信需求會跳轉到NMAwake狀態，如果沒有通信需求會跳轉到NMBusSleep。對于右邊來說默認進入NMActive子狀態，表示參與邏輯環循環過程，若應用層通過參數設置為不參與，則將跳轉到NMPassive狀態，控制器停止發送Ring消息及參與邏輯環的循環過程。
圖4 NMOn下子狀態機
NMAwake狀態是控制器正常進行網絡管理時長期保持的狀態，還可以繼續細分為三個子狀態NMReset、NMNormal和NMLimpHome，如圖5所示。
圖5 NMAwake下子狀態機
（a）NMReset
控制器喚醒后會一步步跳轉到NMReset狀態，并以廣播形式發出一幀特殊網絡管理報文（第一字節是控制器自身ID，第二字節Bit0為1），用來喚醒其他控制器及建立邏輯環。當網絡中所有控制器都發完Alive報文之后，網絡中所有控制器根據收到的Alive報文ID由小到大的循序確認自己的邏輯后繼節點，ID最大控制器的后繼節點為ID最小控制器（如21->22->23->24->25>26->21），由此組成一個邏輯環，并進入NMNormal狀態。
（b）NMNormal
最初發送Alive報文的控制器（或者Alive報文標識符優先級高的控制器）成為邏輯環中的第一個Ring報文發送控制器，Ring報文的第一個字節是下一個控制器的ID，第二字節的Bit1為1。網絡中其他控制器收到指向自身ID的網絡管理報文后，也被稱為“令牌”，才能發出自身Ring報文，因此網絡中同一時間只有一個控制器能發出網絡管理報文，每個控制器按照順序發送網絡管理報文，這個順序就叫做邏輯環，一個簡單的邏輯環原理如圖6所示。
圖6 邏輯環原理
邏輯環建立完成之后，無論是有新控制器加入還是某個控制器掉線，都需要重新進行建環以維持正常的網絡管理，因此對網絡的穩定性要求比較高，整體策略比較復雜。當控制器自身休眠條件滿足，就會發出睡眠指示位 (Sleep.Ind，第二字節Bit4) 為 1 的 Ring 報文，表示自身不再主動請求網絡管理，當所有控制器都滿足休眠條件，最后一個休眠控制器的下一個節點，就會依次發出睡眠應答位 (Sleep.Ack，，第二字節Bit5) 為 1 的 Ring 報文，當網絡上所有控制器都接收到其他所有控制器的睡眠應答位為1的Ring報文后，等待一定時間后同步進入睡眠狀態。這個時候，控制器會停止發送任何報文到總線，等待控制器的內部任務完成后，就會進入低功耗模式，靜態電流會變得很小。
（3）NMLimpHome
如果控制器或總線有故障導致邏輯環建立失敗，控制器將進入NMLimpHome狀態，并按一定周期發送LimpHome網絡管理報文（第一字節是自己的ID，第二字節Bit2為1）。
03 AUTOSAR網絡管理
2003年汽車行業內的幾大巨頭（BMW, Bosch, Continental, DaimlerChrysler, Volkswagen, Siemens VDO）聯合建立了AUTOSAR（AUTomotive Open System ARchitecture）聯盟，一起開發并建立一套真正的開放的汽車電子電器架構，也就是我們現在所說的AUTOSAR標準或者架構。AUTOSAR網絡管理的狀態機有三個模式：Bus-Sleep Mode、Network Mode和Prepare Bus-Sleep Mode，如圖7所示。
圖7 AUTOSAR網絡管理狀態機
（1）Bus-Sleep Mode
控制器上電狀態，如果沒有本地喚醒或遠程喚醒請求時，控制器將進入的一種休眠模式，此模式下控制器電流消耗將降低至最低水平。該模式下，網絡管理報文及應用報文都被禁止發送，但可以接收網絡管理報文和應用報文。當收發器支持特定幀喚醒時，那么控制器只有在接收到事先定義好的網絡管理報文才會喚醒；當收發器不支持特定幀喚醒時，那么網絡上的任意報文都可以將控制器喚醒，喚醒之后再去判斷是否為有效網絡管理報文，如果不是，又會再次按照休眠流程進入到休眠模式。
（2）Network Mode
Network Mode模式又可細分為三個子狀態：Repeat Message State、Normal Operation State和Ready Sleep State，如圖2所示。
圖8 Network Mode下子狀態機
（a）Repeat Message State
Repeat Message State是一個短時間的重復消息狀態，當控制器從Bus-Sleep Mode或者Prepare Bus-Sleep Mode進入到Network Mode后，控制器會發出自身的網絡管理報文通知其他控制器自己上線，就好比你早上到了辦公室之后，和身邊的同事打個招呼，告訴他們今日話搭子已上線，請做好嘮嗑準備。Repeat Message State下還有兩個子狀態：NM Immediate Transmit State和NM Normal Transmit State，兩個狀態的主要區別就是網絡管理報文發送周期的不同，前面子狀態下網絡管理報文可以按照配置參數高頻發送一定周期，目的是快速喚醒整個網絡，后面子狀態下網絡管理報文恢復到正常周期。進入到Network Mode后，應用報文需要在第一幀網絡管理報文發送之后再發送，同時開啟一個計時器，在計時器超時之前會一直保持該狀態，否則會離開該狀態，
（b）Normal Operation State
當控制器自身存在網絡通信的需求，且整車網絡和控制器均正常，那么控制器將跳轉并一直保持在Normal Operation State狀態，進入該狀態后，控制器將周期性發送網絡管理報文，同時正常收發應用報文。
（c）Ready Sleep State
當控制器不再需要網絡通信時處于的就緒休眠狀態，該狀態下控制器將停止發送網絡管理報文，但可以正常發送自身的應用報文，同時正常收發應用層報文。進入該狀態后將同時啟動一個計數器，每次成功接收到其他控制器發送的網絡管理報文，計時器將重置，一旦計時器超時，控制器將跳轉到Prepare Bus-Sleep狀態。整車網絡和控制器均正常，控制器將維持在Normal Operation State和Ready Sleep State狀態，差別就是自身是否有網絡通信需求。
（3）Prepare Bus-Sleep Mode
此模式為控制器準備進入睡眠模式的一個過渡，不會長期處于此模式。該模式下網絡管理報文停止發送，可以接收網絡管理報文，已經存在緩存器的應用報文可以繼續發送，同時不再接收應用層報文。進入該模式后，同樣啟動一個計時器，一旦計時時間到，就將跳轉到Bus-Sleep Mode。
04 比較
（1）相同點
（a）均屬于直接網絡管理。
（b）均需要特定的網絡管理報文，且每個控制器的網絡管理報文ID均不同。
（c）喚醒方式相同，網絡中第一個喚醒的控制器發送網絡管理報文喚醒其他控制器。
（d）目的相同，都是協調多個控制器同步喚醒及休眠，并最終達到低功耗的目的。
（2）不同點：
（a）喚醒幀類型不同，OSEK網絡管理要求控制器喚醒后的第一幀網絡管理報文必須為Alive類型，而AUTOSAR網絡管理要求只要是網絡管理報文即可。
（b）休眠邏輯不同，OSEK網絡管理的休眠是一個請求和確認的過程，所有控制器都發送Ring請求休眠幀，且收到其它控制器的Ring確認休眠幀之后才可以準備進入休眠，而AUTOSA網絡管理直接停止發送網絡管理的報文且一定時間內檢測不到網絡上其他的網絡管理幀就可以準備進入休眠。
（c）網絡保持方式不同，OSEK網絡管理下控制器喚醒后想參與網絡的節點會先發Alive報文申請加入邏輯環，邏輯環建成后，各節點按順序發Ring報文向后續節點傳遞“令牌”。而AUTOSAR網絡管理下，喚醒的控制器直接發送網絡管理報文就可以，所有的控制器想參與到通信中的只要各自發送網絡管理報文就可以。
（d）網絡管理幀PDU格式不一樣，OSEK由于喚醒過程要知道下一個喚醒的控制器，因此在PDU中包含了自己地址、令牌環中下一個控制器的目的地址、命令狀態、用戶數據等，而AUTOSAR網絡管理報文只包含自己的地址、少量控制信息及用戶選擇數據，相比之下要簡單不少。
轉自十一號組織
