1. 項(xiàng)目概述從“喚醒”與“簇”看汽車電子網(wǎng)絡(luò)的協(xié)同管理在汽車電子電氣架構(gòu)日益復(fù)雜的今天一個(gè)高效的網(wǎng)絡(luò)管理系統(tǒng)Network Management NM是確保整車電子系統(tǒng)穩(wěn)定、可靠、低功耗運(yùn)行的核心。當(dāng)看到“AutoSar網(wǎng)絡(luò)管理的喚醒方式、PN網(wǎng)絡(luò)簇”這個(gè)標(biāo)題時(shí)我立刻意識(shí)到這觸及了現(xiàn)代汽車網(wǎng)絡(luò)設(shè)計(jì)的兩個(gè)關(guān)鍵痛點(diǎn)如何讓沉睡的節(jié)點(diǎn)精準(zhǔn)、高效地醒來協(xié)同工作以及如何管理那些邏輯上緊密耦合、需要同步上下線的節(jié)點(diǎn)群組。這不僅僅是AutoSar標(biāo)準(zhǔn)文檔里的幾個(gè)章節(jié)更是我們?cè)谶M(jìn)行域控制器設(shè)計(jì)、功能安全評(píng)估和整車能耗優(yōu)化時(shí)每天都要面對(duì)的實(shí)際工程問題。簡單來說喚醒方式解決的是“叫醒誰”和“怎么叫”的問題直接關(guān)系到整車啟動(dòng)速度、靜態(tài)電流和功能可用性。而PN網(wǎng)絡(luò)簇Partial Network Cluster則解決的是“誰和誰必須一起醒來/睡覺”的問題它是實(shí)現(xiàn)復(fù)雜功能如高級(jí)駕駛輔助系統(tǒng)ADAS的傳感器融合、智能座艙的多屏互動(dòng)的基礎(chǔ)邏輯單元。理解這兩者就等于掌握了AutoSar NM協(xié)同管理策略的精髓。無論你是負(fù)責(zé)底層軟件開發(fā)的工程師還是進(jìn)行系統(tǒng)架構(gòu)設(shè)計(jì)的工程師亦或是負(fù)責(zé)測試驗(yàn)證的工程師理清這兩個(gè)概念及其交互關(guān)系都能讓你在排查網(wǎng)絡(luò)異常、優(yōu)化電源模式時(shí)思路更加清晰。2. 核心概念深度解析喚醒與網(wǎng)絡(luò)簇的底層邏輯在深入實(shí)操細(xì)節(jié)前我們必須先夯實(shí)理論基礎(chǔ)。AutoSar NM的設(shè)計(jì)哲學(xué)是“協(xié)同”其目標(biāo)是在滿足功能需求的前提下盡可能減少不必要的網(wǎng)絡(luò)通信從而降低總線負(fù)載和功耗。喚醒和PN網(wǎng)絡(luò)簇是實(shí)現(xiàn)這一哲學(xué)的兩大支柱。2.1 AutoSar網(wǎng)絡(luò)管理喚醒方式詳解AutoSar NM的喚醒機(jī)制并非單一方法而是一個(gè)分層、協(xié)同的體系。它主要涉及兩種喚醒源本地喚醒和遠(yuǎn)程喚醒。這里的“本地”與“遠(yuǎn)程”是相對(duì)于ECU電子控制單元自身的視角而言的。本地喚醒是指由ECU自身硬件狀態(tài)變化觸發(fā)的喚醒。最常見的就是KL15點(diǎn)火開關(guān)信號(hào)。當(dāng)駕駛員扭動(dòng)鑰匙或按下啟動(dòng)按鈕時(shí)KL15信號(hào)線電平變化直接喚醒與之相連的ECU。此外一些專用的喚醒輸入引腳Wake-up Line接收到特定信號(hào)如車門開關(guān)信號(hào)、CAN總線特定的喚醒模式也會(huì)觸發(fā)本地喚醒。本地喚醒的特點(diǎn)是直接、快速、可靠但需要硬線連接增加了線束成本。遠(yuǎn)程喚醒則是通過總線網(wǎng)絡(luò)本身來傳遞喚醒指令。這是AutoSar NM協(xié)同管理的核心體現(xiàn)。在CAN總線上它通常通過發(fā)送特定的喚醒幀Wake-up Frame或網(wǎng)絡(luò)管理報(bào)文NM Message來實(shí)現(xiàn)。這里有一個(gè)關(guān)鍵點(diǎn)并非所有ECU都能直接“聽懂”并響應(yīng)總線上的任意報(bào)文。為了進(jìn)一步降低靜態(tài)功耗很多ECU在休眠時(shí)其總線收發(fā)器Transceiver會(huì)進(jìn)入低功耗模式此時(shí)它只能識(shí)別一種特殊的喚醒模式Wake-up Pattern例如CAN總線上的一串顯性位Dominant Bits序列。只有先被這個(gè)“特殊暗號(hào)”喚醒收發(fā)器ECU的主控芯片Microcontroller才會(huì)上電進(jìn)而才能處理標(biāo)準(zhǔn)的NM報(bào)文進(jìn)行進(jìn)一步的協(xié)同喚醒或休眠。注意在實(shí)際項(xiàng)目中混淆“總線喚醒模式”和“NM報(bào)文喚醒”是常見的錯(cuò)誤。前者是物理層/數(shù)據(jù)鏈路層的硬件行為后者是網(wǎng)絡(luò)層/應(yīng)用層的軟件行為。一個(gè)典型的啟動(dòng)鏈可能是某個(gè)節(jié)點(diǎn)因本地事件如開門被喚醒 - 該節(jié)點(diǎn)在總線上發(fā)出硬件喚醒模式 - 其他節(jié)點(diǎn)的收發(fā)器被喚醒 - 被喚醒的節(jié)點(diǎn)開始收發(fā)NM報(bào)文協(xié)調(diào)整個(gè)網(wǎng)絡(luò)簇的狀態(tài)。2.2 PN網(wǎng)絡(luò)簇的本質(zhì)與設(shè)計(jì)原則PN網(wǎng)絡(luò)簇是AutoSar中實(shí)現(xiàn)“按需激活”網(wǎng)絡(luò)的核心邏輯概念。它指的是一組邏輯上關(guān)聯(lián)、需要同步進(jìn)行網(wǎng)絡(luò)激活和休眠的ECU集合。一個(gè)ECU可以屬于多個(gè)PN網(wǎng)絡(luò)簇這體現(xiàn)了功能的交叉與復(fù)用。為什么要引入PNC想象一下沒有PNC的場景整車有100個(gè)ECU每次啟動(dòng)車輛所有ECU不管用不用得上全部上電、初始化、加入網(wǎng)絡(luò)通信。這會(huì)造成巨大的啟動(dòng)延遲和瞬間功耗沖擊。而有了PNC我們可以這樣設(shè)計(jì)PNC 1 舒適進(jìn)入簇。包含車門控制模塊、無鑰匙進(jìn)入模塊、車內(nèi)燈控制模塊。當(dāng)用戶攜帶鑰匙靠近車輛時(shí)只需激活這個(gè)簇完成解鎖和迎賓燈效其他如發(fā)動(dòng)機(jī)、變速箱等模塊完全無需喚醒。PNC 2 智能駕駛簇。包含前視攝像頭、雷達(dá)、域控制器。當(dāng)激活自適應(yīng)巡航功能時(shí)只需喚醒這個(gè)簇信息娛樂系統(tǒng)可能仍處于休眠狀態(tài)。PNC 3 整車運(yùn)行簇。包含發(fā)動(dòng)機(jī)控制器、變速箱控制器、車身穩(wěn)定系統(tǒng)等車輛行駛核心模塊。在行車過程中此簇必須保持激活。PNC的設(shè)計(jì)原則功能內(nèi)聚性一個(gè)PNC內(nèi)的所有ECU應(yīng)共同完成一個(gè)明確的用戶可感知功能或子功能。生命周期同步簇內(nèi)ECU的喚醒和休眠時(shí)機(jī)應(yīng)高度同步避免出現(xiàn)“功能已觸發(fā)但部分節(jié)點(diǎn)未就緒”的尷尬局面。接口清晰化PNC之間通過定義良好的信號(hào)接口進(jìn)行交互降低系統(tǒng)耦合度。一個(gè)PNC的激活可以通過發(fā)送特定的NM報(bào)文或應(yīng)用信號(hào)來觸發(fā)另一個(gè)PNC的喚醒。PNC與喚醒方式的關(guān)系喚醒事件是PNC激活的觸發(fā)器。一個(gè)本地喚醒事件如按下啟動(dòng)按鈕可能觸發(fā)“整車運(yùn)行簇”的激活而一個(gè)遠(yuǎn)程喚醒請(qǐng)求如手機(jī)APP發(fā)送的空調(diào)開啟指令則可能觸發(fā)“空調(diào)預(yù)調(diào)節(jié)簇”的激活。NM模塊負(fù)責(zé)將具體的喚醒源映射到對(duì)應(yīng)的PNC控制邏輯上。3. 喚醒方式的具體實(shí)現(xiàn)與配置要點(diǎn)理解了理論我們來看在AutoSar工具鏈如Vector的DaVinci Developer/Configurator ETAS的ISOLAR中如何具體配置這些喚醒機(jī)制。這里以CAN總線為例因?yàn)樗诋?dāng)前車型中應(yīng)用最廣。3.1 硬件喚醒配置硬件喚醒的配置通常在兩個(gè)地方ECU硬件描述和收發(fā)器驅(qū)動(dòng)配置。定義喚醒源Wakeup Source在系統(tǒng)級(jí)設(shè)計(jì)工具中你需要為ECU定義可能的硬件喚醒源。例如WakeupSource_KL15WakeupSource_DoorSwitchWakeupSource_CANBus每個(gè)喚醒源需要關(guān)聯(lián)一個(gè)喚醒原因Wakeup Reason供上層軟件識(shí)別。配置收發(fā)器Transceiver在MCAL微控制器抽象層配置中對(duì)CAN收發(fā)器驅(qū)動(dòng)進(jìn)行設(shè)置。關(guān)鍵參數(shù)包括CanTrcvWakeupModeSupport: 是否支持喚醒功能。CanTrcvWakeupByBusSupported: 是否支持被總線活動(dòng)喚醒。CanTrcvWakeupPattern: 定義硬件喚醒模式如顯性位持續(xù)時(shí)間。這個(gè)模式必須與網(wǎng)絡(luò)內(nèi)其他節(jié)點(diǎn)的設(shè)置一致否則無法喚醒。配置I/O驅(qū)動(dòng)對(duì)于KL15等硬線喚醒需要配置對(duì)應(yīng)的Port和Dio驅(qū)動(dòng)設(shè)置引腳為輸入模式并可能啟用中斷。3.2 網(wǎng)絡(luò)管理報(bào)文喚醒與協(xié)同當(dāng)ECU被硬件喚醒后NM軟件開始工作。協(xié)同喚醒主要通過NM報(bào)文實(shí)現(xiàn)。NM報(bào)文設(shè)計(jì)AutoSar NM報(bào)文的核心是節(jié)點(diǎn)狀態(tài)和PNC信息。在NM報(bào)文中有專門的位域Bit Vector用來標(biāo)識(shí)該節(jié)點(diǎn)所請(qǐng)求的PNC。例如一個(gè)節(jié)點(diǎn)在NM報(bào)文中將PNC 2對(duì)應(yīng)的位置為1就是在向網(wǎng)絡(luò)宣告“我需要PNC 2被激活”。PNC關(guān)聯(lián)與依賴在系統(tǒng)配置中你需要為每個(gè)ECU配置它支持的PNC它屬于哪些簇和請(qǐng)求的PNC它正常工作時(shí)需要哪些簇必須激活。一個(gè)ECU可以支持但不請(qǐng)求某個(gè)PNC作為該P(yáng)NC的“服務(wù)提供者”但不主動(dòng)請(qǐng)求它。更重要的是配置PNC之間的依賴關(guān)系。例如“空調(diào)壓縮機(jī)控制器”可能請(qǐng)求PNC 5空調(diào)系統(tǒng)簇但PNC 5可能依賴于PNC 1整車基礎(chǔ)電源簇的激活。這種依賴關(guān)系確保了喚醒序列的正確性。狀態(tài)機(jī)協(xié)同每個(gè)ECU的NM模塊都運(yùn)行著一個(gè)復(fù)雜的狀態(tài)機(jī)如AUTOSAR NM的Ring狀態(tài)機(jī)或PN狀態(tài)機(jī)。喚醒過程本質(zhì)上是網(wǎng)絡(luò)中各節(jié)點(diǎn)NM狀態(tài)機(jī)協(xié)同遷移的過程。一個(gè)典型的遠(yuǎn)程協(xié)同喚醒流程如下觸發(fā)節(jié)點(diǎn)A因本地事件喚醒并進(jìn)入NM網(wǎng)絡(luò)模式。請(qǐng)求節(jié)點(diǎn)A在其發(fā)出的NM報(bào)文中置位它所請(qǐng)求的PNC例如PNC 2。擴(kuò)散網(wǎng)絡(luò)中的其他節(jié)點(diǎn)如節(jié)點(diǎn)B、C收到該NM報(bào)文檢查自身配置。如果它們也支持PNC 2并且當(dāng)前PNC 2未激活它們會(huì)開始評(píng)估是否滿足喚醒條件如電源、通信正常。應(yīng)答與同步滿足條件的節(jié)點(diǎn)B、C會(huì)將自己的NM報(bào)文中PNC 2的位也置為1作為應(yīng)答。當(dāng)節(jié)點(diǎn)A在指定時(shí)間內(nèi)收到足夠多根據(jù)配置的、同樣請(qǐng)求PNC 2的NM報(bào)文時(shí)它認(rèn)為網(wǎng)絡(luò)已就緒。激活所有請(qǐng)求PNC 2的節(jié)點(diǎn)同步進(jìn)入“網(wǎng)絡(luò)已激活”狀態(tài)應(yīng)用層功能如ADAS算法可以開始運(yùn)行。實(shí)操心得配置PNC依賴關(guān)系時(shí)一定要避免循環(huán)依賴。例如PNC A依賴PNC BPNC B又依賴PNC A這會(huì)導(dǎo)致整個(gè)喚醒邏輯死鎖相關(guān)功能永遠(yuǎn)無法激活。在系統(tǒng)設(shè)計(jì)階段應(yīng)該繪制PNC依賴關(guān)系圖并進(jìn)行環(huán)路檢查。4. PN網(wǎng)絡(luò)簇的工程化設(shè)計(jì)與實(shí)戰(zhàn)策略設(shè)計(jì)一個(gè)好的PN網(wǎng)絡(luò)簇方案是系統(tǒng)架構(gòu)師的核心工作之一。這不僅僅是配置幾個(gè)參數(shù)而是對(duì)整車功能拓?fù)浜碗娫茨Ｊ降纳疃壤斫狻?.1 PNC設(shè)計(jì)流程與考量因素功能分解從用戶場景出發(fā)列出所有需要網(wǎng)絡(luò)通信的功能。例如“遠(yuǎn)程空調(diào)預(yù)調(diào)節(jié)”功能可能涉及車聯(lián)網(wǎng)模塊T-Box、空調(diào)控制器、鼓風(fēng)機(jī)、溫度傳感器、車身控制器用于解鎖相關(guān)許可。ECU映射將上述功能涉及到的軟件組件SWC映射到具體的ECU硬件上。確定每個(gè)ECU在各項(xiàng)功能中的角色。簇劃分將功能相近、生命周期一致的ECU劃分為一個(gè)PNC。劃分原則強(qiáng)實(shí)時(shí)性要求對(duì)響應(yīng)時(shí)間要求苛刻的功能如碰撞預(yù)警應(yīng)獨(dú)立成簇或劃入高優(yōu)先級(jí)簇確保其喚醒和初始化速度。功耗敏感度常電Battery供電且需要長期待機(jī)的ECU如防盜模塊、T-Box應(yīng)盡量劃入小而精的簇減少不必要的協(xié)同喚醒。信號(hào)交互密度彼此之間通信流量大、信號(hào)交互頻繁的ECU應(yīng)劃入同一簇以減少跨簇通信的延遲和復(fù)雜度。定義接口與觸發(fā)條件明確每個(gè)PNC的激活觸發(fā)條件如硬線信號(hào)、應(yīng)用層信號(hào)、NM報(bào)文請(qǐng)求和休眠條件如超時(shí)、應(yīng)用層釋放請(qǐng)求。定義PNC之間通信的關(guān)鍵信號(hào)。4.2 配置實(shí)例一個(gè)簡單的車門迎賓燈PNC假設(shè)我們?cè)O(shè)計(jì)一個(gè)“車門迎賓燈”PNCPNC_ID 0x01包含左前車門模塊ECU_Door_LF、右前車門模塊ECU_Door_RF、車身控制器ECU_BCM 負(fù)責(zé)控制車內(nèi)氛圍燈。系統(tǒng)配置步驟定義PNC在NM配置容器中創(chuàng)建PNC 0x01命名為“PNC_DoorWelcome”。配置ECU的PNC屬性對(duì)于ECU_Door_LF和ECU_Door_RFNmNodeSupportsPnc 0x01 (支持PNC 0x01)NmNodeRequestsPnc 0x01 (功能實(shí)現(xiàn)需要PNC 0x01激活)NmPncWakeupSource 關(guān)聯(lián)到“車門把手觸摸傳感器”的硬件喚醒源。對(duì)于ECU_BCMNmNodeSupportsPnc 0x01NmNodeRequestsPnc 0x01NmPncWakeupSource 可能不直接關(guān)聯(lián)硬件喚醒而是通過收到車門模塊的NM報(bào)文來觸發(fā)。配置NM報(bào)文為每個(gè)ECU配置NM報(bào)文確保其NmPncNetworkVectorPNC位向量在報(bào)文數(shù)據(jù)中正確映射。當(dāng)車門模塊被喚醒后它發(fā)出的NM報(bào)文中代表PNC 0x01的位應(yīng)置為1。配置狀態(tài)超時(shí)設(shè)置NmTimeoutTime和NmWaitBusSleepTime等參數(shù)。例如當(dāng)車門關(guān)閉后NM模塊會(huì)啟動(dòng)一個(gè)定時(shí)器超時(shí)后ECU會(huì)在NM報(bào)文中將PNC 0x01的位清零并協(xié)調(diào)進(jìn)入休眠。代碼層面的處理以AUTOSAR接口為例 應(yīng)用層需要調(diào)用Nm_PassiveStartup或Nm_NetworkRequest來觸發(fā)PNC請(qǐng)求。當(dāng)NM模塊確定PNC被激活后會(huì)通過Nm_NetworkMode回調(diào)函數(shù)通知應(yīng)用層。應(yīng)用層在收到NM_MODE_NETWORK通知后才能啟動(dòng)迎賓燈控制邏輯。/* 在車門模塊的應(yīng)用層代碼中 */ void DoorHandle_TouchDetected(void) { /* 檢測到觸摸請(qǐng)求網(wǎng)絡(luò) */ Nm_NetworkRequest(NM_CHANNEL_CAN, PNC_DOOR_WELCOME_MASK); } /* NM回調(diào)函數(shù) */ void Nm_NetworkMode(NetworkHandleType nmNetworkHandle) { if (nmNetworkHandle NM_CHANNEL_CAN) { /* 網(wǎng)絡(luò)已激活可以安全地進(jìn)行CAN通信和控制輸出 */ Appl_EnableWelcomeLight(); } }5. 常見問題排查與調(diào)試技巧實(shí)錄在實(shí)際項(xiàng)目開發(fā)和測試中與喚醒和PNC相關(guān)的問題層出不窮。下面是我總結(jié)的一些典型問題及其排查思路。5.1 喚醒失敗問題排查現(xiàn)象某個(gè)ECU無法被喚醒或整個(gè)PNC無法激活。排查步驟遵循從硬件到軟件從底層到上層的順序硬件與電源檢查測量ECU的供電引腳常電、點(diǎn)火電電壓是否正常。檢查喚醒輸入引腳如KL15 CAN喚醒線的電平信號(hào)是否到達(dá)ECU連接器。使用示波器測量CAN總線波形在喚醒事件發(fā)生時(shí)查看總線上是否有正確的喚醒模式一串顯性位。如果沒有問題可能出在發(fā)起喚醒的節(jié)點(diǎn)或其收發(fā)器配置上。收發(fā)器與驅(qū)動(dòng)層檢查確認(rèn)ECU的收發(fā)器配置是否正確支持喚醒CanTrcvWakeupSupport為TRUE。檢查收發(fā)器初始化序列中是否正確地使能了喚醒功能調(diào)用了CanTrcv_SetWakeupMode。在MCAL調(diào)試中確認(rèn)是否收到了來自收發(fā)器的喚醒中斷CanTrcv_CheckWakeup。NM軟件層檢查確認(rèn)ECU的NM模塊已正確初始化并且使能了PNC功能Nm_EnablePn。使用CANoe等總線工具抓取NM報(bào)文。觀察預(yù)期應(yīng)該發(fā)起喚醒請(qǐng)求的節(jié)點(diǎn)是否發(fā)出了NM報(bào)文其NM報(bào)文中對(duì)應(yīng)的PNC位向量是否被置位網(wǎng)絡(luò)中的其他節(jié)點(diǎn)是否對(duì)此做出了響應(yīng)也置位了相同的PNC位檢查NM狀態(tài)機(jī)通過調(diào)試器或診斷服務(wù)如UDS 0x86服務(wù)讀取ECU的NM狀態(tài)看其是否卡在NM_STATE_BUS_SLEEP或NM_STATE_PREPARE_BUS_SLEEP狀態(tài)。應(yīng)用層與集成檢查確認(rèn)應(yīng)用層是否正確調(diào)用了Nm_NetworkRequestAPI。檢查系統(tǒng)描述文件ARXML中該ECU的PNC支持與請(qǐng)求配置是否與代碼一致。檢查PNC依賴關(guān)系是否存在因某個(gè)依賴PNC未激活而導(dǎo)致的連鎖失敗。5.2 PNC狀態(tài)不同步問題現(xiàn)象同一個(gè)PNC內(nèi)的部分ECU已激活并工作但另一部分ECU仍處于休眠狀態(tài)導(dǎo)致功能不全。排查思路NM報(bào)文分析抓取總線所有NM報(bào)文。對(duì)比不同ECU發(fā)出的NM報(bào)文中同一PNC的位狀態(tài)是否一致。如果某個(gè)ECU沒有置位該P(yáng)NC說明它沒有發(fā)出請(qǐng)求或請(qǐng)求未被接受。配置一致性檢查這是最常見的原因。逐一核對(duì)PNC內(nèi)所有ECU的以下配置項(xiàng)是否完全一致NmPnEnabled(是否使能PN功能)NmPncId(PNC標(biāo)識(shí)符)NmPncNetworkVectorPosition(該P(yáng)NC在NM報(bào)文位向量中的具體位置)NmUserDataEnabled(如果PNC信息通過User Data傳遞則需檢查User Data相關(guān)配置)時(shí)序問題檢查各ECU的NmTimeoutTime、NmRepeatMessageTime等定時(shí)參數(shù)。如果差異過大可能導(dǎo)致一個(gè)節(jié)點(diǎn)已認(rèn)為超時(shí)準(zhǔn)備休眠而另一個(gè)節(jié)點(diǎn)才剛剛開始請(qǐng)求造成狀態(tài)不同步。建議同一PNC內(nèi)的ECU使用相同或相近的超時(shí)參數(shù)集。信號(hào)干擾或丟包在電磁環(huán)境惡劣的區(qū)域可能導(dǎo)致NM報(bào)文丟失使得部分節(jié)點(diǎn)無法及時(shí)同步狀態(tài)。可以增加NM報(bào)文的發(fā)送周期縮短N(yùn)mRepeatMessageTime或檢查總線物理層質(zhì)量終端電阻、線束等。5.3 休眠失敗與靜態(tài)電流超標(biāo)現(xiàn)象車輛下電后某些ECU無法進(jìn)入深度休眠導(dǎo)致蓄電池虧電。排查技巧定位“釘子戶”使用電流鉗測量整車的靜態(tài)電流或逐個(gè)拔掉ECU保險(xiǎn)絲來定位耗電模塊。更先進(jìn)的方法是使用支持“網(wǎng)絡(luò)管理跟蹤”功能的診斷工具它可以記錄每個(gè)ECU的NM狀態(tài)切換過程直接找出停留在“網(wǎng)絡(luò)模式”或“準(zhǔn)備休眠”狀態(tài)的ECU。檢查PNC釋放邏輯確認(rèn)應(yīng)用層在功能結(jié)束后是否及時(shí)調(diào)用了Nm_NetworkRelease釋放對(duì)PNC的請(qǐng)求。檢查是否有其他ECU仍在請(qǐng)求該P(yáng)NC。一個(gè)ECU的釋放請(qǐng)求需要得到簇內(nèi)所有其他ECU的“同意”都釋放請(qǐng)求整個(gè)簇才能進(jìn)入休眠協(xié)調(diào)流程。檢查通信棧關(guān)閉順序ECU休眠前需要按順序關(guān)閉通信棧應(yīng)用層停發(fā)報(bào)文 - COM層停發(fā) - PDUR路由停止 - 網(wǎng)絡(luò)管理協(xié)調(diào)休眠 - CanIf停發(fā) - CanDrv關(guān)閉控制器 - CanTrcv進(jìn)入低功耗模式。任何一環(huán)未正確關(guān)閉都可能阻止休眠。確保EcuMECU狀態(tài)管理器的GoToSleep流程正確執(zhí)行了所有Shutdown回調(diào)函數(shù)。硬件保持喚醒檢查是否有硬件信號(hào)如錯(cuò)誤的KL15信號(hào)毛刺、某個(gè)傳感器漏電持續(xù)保持ECU處于喚醒狀態(tài)。可以使用IO記錄儀或測量相關(guān)引腳電平進(jìn)行排查。調(diào)試工具推薦Vector CANoe/CANalyzer其Network Management IG交互發(fā)生器和Trace窗口是分析NM狀態(tài)和PNC的利器可以圖形化顯示每個(gè)節(jié)點(diǎn)的狀態(tài)和PNC位向量。ETAS INCA結(jié)合AUTOSAR BSW基礎(chǔ)軟件的測量與標(biāo)定功能可以實(shí)時(shí)監(jiān)控和修改NM模塊的內(nèi)部變量和狀態(tài)。示波器/邏輯分析儀用于底層硬件信號(hào)和總線喚醒模式的抓取與分析是解決硬件層喚醒問題的根本手段。6. 進(jìn)階思考面向SOA架構(gòu)的演進(jìn)隨著汽車電子架構(gòu)向域集中式和中央計(jì)算式發(fā)展基于信號(hào)的AUTOSAR ClassicCP與面向服務(wù)的AUTOSAR AdaptiveAP共存。這對(duì)網(wǎng)絡(luò)管理提出了新挑戰(zhàn)也帶來了新思路。在AP平臺(tái)中傳統(tǒng)的基于周期性NM報(bào)文的協(xié)同機(jī)制可能不再適用因?yàn)镾OA通信如SOME/IP本身就是按需、事件驅(qū)動(dòng)的。AP的NM更側(cè)重于服務(wù)實(shí)例的生命周期管理和機(jī)器狀態(tài)的健康監(jiān)控。例如一個(gè)提供“攝像頭圖像”服務(wù)的ECU當(dāng)沒有客戶端訂閱該服務(wù)時(shí)它可以進(jìn)入深度休眠當(dāng)有客戶端請(qǐng)求時(shí)由中間件如Ara::COM協(xié)同執(zhí)行器管理Ara::EXM將其喚醒。然而PNC的思想在SOA架構(gòu)下依然有價(jià)值并可能演化為服務(wù)簇或功能域集群的概念。系統(tǒng)可以定義一個(gè)“自動(dòng)駕駛感知服務(wù)簇”包含攝像頭服務(wù)、雷達(dá)服務(wù)、融合算法服務(wù)。當(dāng)需要啟動(dòng)高速公路輔助駕駛功能時(shí)車控計(jì)算機(jī)可以統(tǒng)一調(diào)度同時(shí)激活這個(gè)“服務(wù)簇”中的所有服務(wù)提供者確保功能的完整性和實(shí)時(shí)性。即使在CP和AP混合的網(wǎng)絡(luò)中喚醒和PNC管理也需跨域協(xié)同。例如CP域的一個(gè)車身事件如開門喚醒傳統(tǒng)CAN網(wǎng)絡(luò)上的BCMBCM再通過網(wǎng)關(guān)將事件轉(zhuǎn)換為SOME/IP服務(wù)調(diào)用觸發(fā)AP域座艙控制器啟動(dòng)迎賓場景。這就要求網(wǎng)關(guān)不僅是一個(gè)協(xié)議轉(zhuǎn)換器更要成為一個(gè)網(wǎng)絡(luò)狀態(tài)與電源模式的協(xié)調(diào)器在CP NM報(bào)文和AP服務(wù)狀態(tài)之間建立映射關(guān)系。這要求我們工程師不僅要精通經(jīng)典的AutoSar NM機(jī)制更要保持開放心態(tài)理解新舊架構(gòu)下電源與網(wǎng)絡(luò)管理理念的變與不變才能設(shè)計(jì)出適應(yīng)下一代電子電氣架構(gòu)的高效、可靠的網(wǎng)絡(luò)管理系統(tǒng)。