1. 從一個踩坑現(xiàn)場說起為什么網(wǎng)絡(luò)管理報文值得單獨(dú)拎出來講剛接觸AUTOSAR網(wǎng)絡(luò)管理那會兒我犯過一個很典型的錯誤整車休眠后電流死活降不下來查了三天最后定位到某個ECU的NM報文一直在發(fā)網(wǎng)絡(luò)死活進(jìn)不了Bus-Sleep模式。當(dāng)時對CanNm的狀態(tài)機(jī)理解不透以為只要應(yīng)用層不發(fā)包就行結(jié)果被網(wǎng)絡(luò)管理模塊狠狠上了一課。這件事讓我意識到AUTOSAR網(wǎng)絡(luò)管理報文NM PDU雖然在整個通信矩陣?yán)镎嫉钠淮蟮苯記Q定了整車網(wǎng)絡(luò)的睡眠喚醒行為、靜態(tài)電流表現(xiàn)以及ECU之間能否協(xié)調(diào)一致地上下電。你可以把它理解成整個CAN網(wǎng)絡(luò)的“作息管理員”——誰該醒著、誰可以睡、什么時候大家一起睡全靠這幾幀報文來協(xié)調(diào)。這篇筆記面向的是剛接觸AUTOSAR通信棧的嵌入式軟件工程師、總線測試人員以及需要配置NM參數(shù)的集成工程師。我會從NM報文的數(shù)據(jù)結(jié)構(gòu)講起把CanNm狀態(tài)機(jī)、定時器參數(shù)、NM PDU的字節(jié)布局、配置要點(diǎn)、常見故障排查都過一遍。內(nèi)容基于AUTOSAR CanNm規(guī)范4.x版本和我在實(shí)際項(xiàng)目中的配置經(jīng)驗(yàn)涉及具體參數(shù)的地方會說明計算邏輯方便你直接套用到自己的項(xiàng)目里。需要提前說明的是不同OEM對NM報文的定義有差異AUTOSAR規(guī)范只規(guī)定了機(jī)制框架具體字節(jié)含義往往由主機(jī)廠在通信矩陣?yán)锛s定。所以下面講到的字節(jié)布局是通用結(jié)構(gòu)實(shí)際項(xiàng)目要以你手上的通信矩陣為準(zhǔn)。2. AUTOSAR網(wǎng)絡(luò)管理到底管的是什么2.1 網(wǎng)絡(luò)管理的核心目標(biāo)協(xié)調(diào)睡眠與喚醒整車上有幾十個ECU掛在CAN總線上如果每個ECU都按自己的節(jié)奏決定睡不睡結(jié)果就是有的睡了有的還醒著總線永遠(yuǎn)靜不下來。AUTOSAR網(wǎng)絡(luò)管理的核心目標(biāo)就一個讓同一網(wǎng)絡(luò)上的所有節(jié)點(diǎn)協(xié)調(diào)一致地進(jìn)入睡眠并在需要通信時快速喚醒整個網(wǎng)絡(luò)。這里的關(guān)鍵詞是“協(xié)調(diào)一致”。NM不是讓某個節(jié)點(diǎn)單獨(dú)睡覺而是通過周期性地發(fā)送NM報文來宣告“我還醒著大家先別睡”當(dāng)所有節(jié)點(diǎn)都不再需要通信時大家同時停止發(fā)送NM報文等定時器超時后一起進(jìn)入Bus-Sleep模式。這個機(jī)制保證了網(wǎng)絡(luò)狀態(tài)的統(tǒng)一性。從實(shí)現(xiàn)層面看AUTOSAR網(wǎng)絡(luò)管理分為直接網(wǎng)絡(luò)管理和間接網(wǎng)絡(luò)管理兩種。直接網(wǎng)絡(luò)管理就是節(jié)點(diǎn)主動發(fā)送NM報文來維持網(wǎng)絡(luò)喚醒狀態(tài)CanNm就是典型的直接網(wǎng)絡(luò)管理。間接網(wǎng)絡(luò)管理則是通過監(jiān)聽?wèi)?yīng)用報文來判斷網(wǎng)絡(luò)是否活躍不單獨(dú)發(fā)NM報文。目前乘用車CAN網(wǎng)絡(luò)絕大多數(shù)用的是直接網(wǎng)絡(luò)管理也就是CanNm。2.2 CanNm在AUTOSAR通信棧中的位置CanNm模塊位于AUTOSAR通信棧的中間層往上對接Nm模塊網(wǎng)絡(luò)管理接口層往下對接CanIfCAN接口層。它的上下關(guān)系大致是這樣的Nm模塊提供統(tǒng)一的網(wǎng)絡(luò)管理接口屏蔽底層總線差異上層應(yīng)用或BswM通過Nm來請求網(wǎng)絡(luò)、釋放網(wǎng)絡(luò)。CanNm模塊實(shí)現(xiàn)CAN總線上的具體NM機(jī)制負(fù)責(zé)NM報文的收發(fā)、狀態(tài)機(jī)管理、定時器管理。CanIf模塊負(fù)責(zé)CAN報文的實(shí)際收發(fā)CanNm通過CanIf提供的接口來發(fā)送和接收NM PDU。CanDrv模塊最底層的CAN驅(qū)動直接操作CAN控制器寄存器。理解這個層次關(guān)系很重要因?yàn)榕挪镹M問題時你需要知道問題可能出在哪一層。比如NM報文發(fā)不出去可能是CanNm狀態(tài)機(jī)沒進(jìn)到Normal Operation也可能是CanIf的發(fā)送緩沖滿了還可能是CanDrv的郵箱配置有問題。2.3 NM報文與普通應(yīng)用報文的關(guān)鍵區(qū)別很多人剛接觸時會問NM報文和普通CAN報文有什么區(qū)別從CAN幀格式上看沒有本質(zhì)區(qū)別都是標(biāo)準(zhǔn)幀或擴(kuò)展幀。但從行為特征上看區(qū)別很大對比維度NM報文普通應(yīng)用報文發(fā)送觸發(fā)周期性發(fā)送由NM狀態(tài)機(jī)驅(qū)動由應(yīng)用邏輯觸發(fā)事件驅(qū)動發(fā)送目的維持網(wǎng)絡(luò)喚醒狀態(tài)傳輸實(shí)際數(shù)據(jù)停止條件所有節(jié)點(diǎn)釋放網(wǎng)絡(luò)后停止應(yīng)用不再需要發(fā)送時停止接收處理收到即刷新NM定時器維持網(wǎng)絡(luò)由應(yīng)用層解析處理報文ID通常在特定ID段優(yōu)先級較高按通信矩陣分配數(shù)據(jù)內(nèi)容包含源節(jié)點(diǎn)ID、控制位等應(yīng)用數(shù)據(jù)NM報文的發(fā)送是周期性的只要節(jié)點(diǎn)還在Normal Operation狀態(tài)就會一直按固定周期發(fā)送。這個周期通常由OEM規(guī)定常見值有20ms、100ms、200ms、500ms、1000ms等。周期越短網(wǎng)絡(luò)喚醒響應(yīng)越快但總線負(fù)載也越高。3. CanNm報文的數(shù)據(jù)結(jié)構(gòu)逐字節(jié)拆解3.1 NM PDU的通用字節(jié)布局CanNm的NM PDU長度通常為8字節(jié)經(jīng)典CAN在CAN FD場景下可以更長。AUTOSAR規(guī)范定義了NM PDU的基本結(jié)構(gòu)但具體字節(jié)含義由OEM通信矩陣約定。一個典型的NM PDU布局如下字節(jié)位置含義說明Byte 0Source Node ID源節(jié)點(diǎn)標(biāo)識標(biāo)識是哪個ECU發(fā)的Byte 1Control Bit Vector控制位向量包含重復(fù)報文請求、NM協(xié)調(diào)等標(biāo)志Byte 2~7User Data用戶數(shù)據(jù)OEM自定義常用于傳遞喚醒原因等Source Node ID是NM報文最核心的字段。每個ECU在通信矩陣?yán)锒加幸粋€唯一的Node ID接收方通過這個字段知道是誰在發(fā)NM報文。這個ID也用于NM報文ID的分配很多OEM的做法是NM報文ID 基礎(chǔ)ID Node ID這樣每個節(jié)點(diǎn)的NM報文ID都不同方便總線上區(qū)分。Control Bit VectorCBV是控制位向量AUTOSAR規(guī)范定義了其中幾個位的含義Bit 0Repeat Message Request重復(fù)報文請求位。當(dāng)某個節(jié)點(diǎn)需要其他節(jié)點(diǎn)進(jìn)入Repeat Message狀態(tài)時會置位。Bit 1NM Coordinator Sleep Ready協(xié)調(diào)器睡眠就緒位。Bit 4Active Wakeup Bit主動喚醒位標(biāo)識本次喚醒是主動喚醒還是被動喚醒。Bit 6Partial Network Information Bit部分網(wǎng)絡(luò)信息位。其余位保留或由OEM自定義。CBV的位定義在不同AUTOSAR版本間可能有細(xì)微差異配置時要對照你使用的規(guī)范版本。3.2 Source Node ID的分配與注意事項(xiàng)Source Node ID的分配看似簡單實(shí)際項(xiàng)目里經(jīng)常出問題。我遇到過好幾次因?yàn)镹ode ID沖突導(dǎo)致NM行為異常的案例。分配Node ID時有幾個原則唯一性同一網(wǎng)絡(luò)內(nèi)每個節(jié)點(diǎn)的Node ID必須唯一這是最基本的要求。與NM報文ID的映射關(guān)系如果OEM采用“基礎(chǔ)ID Node ID”的方式分配NM報文ID那Node ID的取值要保證NM報文ID不與其他報文沖突。避免使用0x00和0xFF有些實(shí)現(xiàn)會把0x00當(dāng)作無效值0xFF可能被保留具體要看OEM規(guī)范。與診斷地址區(qū)分Node ID和診斷的源地址、目標(biāo)地址是兩套體系不要混用。注意Node ID沖突是NM問題的常見根因之一。如果發(fā)現(xiàn)總線上有兩個節(jié)點(diǎn)發(fā)相同ID的NM報文或者某個節(jié)點(diǎn)的NM行為異常先檢查Node ID分配表。3.3 用戶數(shù)據(jù)區(qū)的典型用法Byte 2~7這6個字節(jié)是用戶數(shù)據(jù)區(qū)AUTOSAR規(guī)范沒有強(qiáng)制定義留給OEM和供應(yīng)商自定義。實(shí)際項(xiàng)目中常見的用法包括喚醒原因標(biāo)識本次網(wǎng)絡(luò)喚醒是由哪個事件觸發(fā)的比如KL15上電、CAN喚醒、LIN喚醒等。節(jié)點(diǎn)狀態(tài)傳遞節(jié)點(diǎn)的當(dāng)前狀態(tài)信息供其他節(jié)點(diǎn)參考。部分網(wǎng)絡(luò)信息在部分網(wǎng)絡(luò)Partial Networking場景下傳遞PN相關(guān)的信息。預(yù)留擴(kuò)展為未來功能預(yù)留通常填默認(rèn)值。用戶數(shù)據(jù)區(qū)的填充值在項(xiàng)目初期就要和OEM確認(rèn)清楚因?yàn)橐坏┝慨a(chǎn)修改用戶數(shù)據(jù)區(qū)可能影響其他節(jié)點(diǎn)的解析邏輯。我見過一個項(xiàng)目因?yàn)橛脩魯?shù)據(jù)區(qū)某個字節(jié)的含義在開發(fā)中期被OEM重新定義導(dǎo)致所有節(jié)點(diǎn)的NM解析代碼都要改返工量很大。4. CanNm狀態(tài)機(jī)網(wǎng)絡(luò)管理的核心邏輯4.1 三個主要狀態(tài)與狀態(tài)遷移CanNm的狀態(tài)機(jī)是理解網(wǎng)絡(luò)管理行為的關(guān)鍵。AUTOSAR CanNm定義了三個主要狀態(tài)Bus-Sleep Mode總線睡眠模式。這是最省電的狀態(tài)NM模塊不發(fā)送任何報文只等待喚醒事件。Prepare Bus-Sleep Mode準(zhǔn)備睡眠模式。這是一個過渡狀態(tài)等待總線上的NM報文都停止后再進(jìn)入Bus-Sleep。Network Mode網(wǎng)絡(luò)模式。這是正常工作狀態(tài)包含三個子狀態(tài)Repeat Message State、Normal Operation State、Ready Sleep State。狀態(tài)遷移的邏輯大致是上電或喚醒事件后進(jìn)入Network Mode在Network Mode內(nèi)部根據(jù)網(wǎng)絡(luò)請求和定時器在三個子狀態(tài)間切換當(dāng)所有節(jié)點(diǎn)都釋放網(wǎng)絡(luò)后經(jīng)過Prepare Bus-Sleep進(jìn)入Bus-Sleep。4.2 Network Mode下的三個子狀態(tài)Repeat Message State重復(fù)報文狀態(tài)進(jìn)入Network Mode后首先進(jìn)入這個狀態(tài)。在這個狀態(tài)下NM報文會以較快的周期發(fā)送通常是Normal周期的1/2或更快目的是讓總線上其他節(jié)點(diǎn)快速檢測到本節(jié)點(diǎn)的存在。這個狀態(tài)持續(xù)的時間由Repeat Message Time定時器控制。Normal Operation State正常運(yùn)行狀態(tài)當(dāng)節(jié)點(diǎn)需要保持網(wǎng)絡(luò)通信時進(jìn)入這個狀態(tài)。NM報文按正常周期發(fā)送網(wǎng)絡(luò)保持喚醒。只要應(yīng)用層還持有網(wǎng)絡(luò)請求節(jié)點(diǎn)就會留在這個狀態(tài)。Ready Sleep State準(zhǔn)備睡眠狀態(tài)當(dāng)應(yīng)用層釋放了網(wǎng)絡(luò)請求但總線上還有其他節(jié)點(diǎn)在發(fā)NM報文時節(jié)點(diǎn)進(jìn)入這個狀態(tài)。此時本節(jié)點(diǎn)停止發(fā)送NM報文但仍然監(jiān)聽總線只要收到其他節(jié)點(diǎn)的NM報文就會刷新定時器保持網(wǎng)絡(luò)不睡。當(dāng)所有節(jié)點(diǎn)都進(jìn)入Ready Sleep且沒有NM報文時網(wǎng)絡(luò)進(jìn)入Prepare Bus-Sleep。這三個子狀態(tài)的切換邏輯是CanNm最核心的部分也是配置參數(shù)時最容易出錯的地方。理解每個狀態(tài)的進(jìn)入條件、退出條件和持續(xù)時間是排查NM問題的基本功。4.3 定時器參數(shù)的計算與配置CanNm涉及多個定時器每個定時器的取值直接影響網(wǎng)絡(luò)行為。以下是主要定時器及其典型配置定時器名稱含義典型值配置要點(diǎn)CanNmMsgCycleTimeNM報文正常發(fā)送周期500ms由OEM規(guī)定影響總線負(fù)載CanNmMsgCycleOffset發(fā)送偏移0~周期值避免多節(jié)點(diǎn)同時發(fā)送CanNmRepeatMessageTime重復(fù)報文狀態(tài)持續(xù)時間1600ms通常為周期值的整數(shù)倍CanNmTimeoutTimeNM報文接收超時時間2000ms通常大于周期值CanNmWaitBusSleepTime等待總線睡眠時間2000ms從Ready Sleep到Bus-SleepCanNmImmediateNmCycleTime立即發(fā)送周期20ms喚醒后快速發(fā)送的周期CanNmImmediateNmTransmissions立即發(fā)送次數(shù)3~5次喚醒后快速發(fā)送的次數(shù)這些參數(shù)的取值不是隨便定的它們之間有約束關(guān)系。比如CanNmTimeoutTime必須大于CanNmMsgCycleTime否則正常運(yùn)行時就會誤判超時。CanNmWaitBusSleepTime要足夠長確保總線上所有節(jié)點(diǎn)都能收到最后一幀NM報文并完成狀態(tài)遷移。提示配置這些參數(shù)時建議先畫出狀態(tài)遷移的時間軸圖把每個狀態(tài)的持續(xù)時間和定時器超時點(diǎn)標(biāo)出來這樣能直觀地檢查參數(shù)之間是否有沖突。5. 手把手配置CanNm從參數(shù)到代碼5.1 配置工具的選擇與工程結(jié)構(gòu)配置CanNm通常有兩種方式一是使用AUTOSAR配置工具如Vector DaVinci Configurator、ETAS ISOLAR等二是手寫配置代碼。大項(xiàng)目基本都用配置工具因?yàn)閰?shù)多、關(guān)聯(lián)復(fù)雜手寫容易出錯。以DaVinci Configurator為例CanNm的配置通常在CanNm模塊下進(jìn)行主要配置項(xiàng)包括CanNmGlobalConfig全局配置包含定時器參數(shù)、節(jié)點(diǎn)ID等。CanNmChannelConfig通道配置每個CAN通道一份。CanNmRxPdu接收的NM PDU配置。CanNmTxPdu發(fā)送的NM PDU配置。CanNmNodeConfig節(jié)點(diǎn)相關(guān)配置。配置完成后工具會生成CanNm_Cfg.c和CanNm_Cfg.h等配置文件以及對應(yīng)的ECUC參數(shù)。這些生成的代碼會參與編譯最終燒錄到ECU里。5.2 關(guān)鍵配置項(xiàng)逐項(xiàng)說明CanNmNodeId本節(jié)點(diǎn)的Node ID必須與通信矩陣一致。這個值會出現(xiàn)在發(fā)送的NM PDU的Byte 0。CanNmMsgCycleTimeNM報文發(fā)送周期單位通常是ms。這個值直接決定總線負(fù)載配置時要算一下如果總線上有20個節(jié)點(diǎn)每個節(jié)點(diǎn)都以500ms周期發(fā)8字節(jié)NM報文那NM報文帶來的總線負(fù)載大約是 20 × (847) / 500 ≈ 2.2%按標(biāo)準(zhǔn)幀約47位開銷估算。這個負(fù)載在可接受范圍內(nèi)。CanNmMsgCycleOffset發(fā)送偏移用于錯開各節(jié)點(diǎn)的發(fā)送時刻。如果不配偏移多個節(jié)點(diǎn)可能在同一時刻發(fā)送導(dǎo)致總線瞬時負(fù)載升高。偏移值通常按Node ID分配比如Node ID為1的偏移0msNode ID為2的偏移10ms以此類推。CanNmRepeatMessageTime重復(fù)報文狀態(tài)的持續(xù)時間。這個值要足夠長讓總線上所有節(jié)點(diǎn)都能檢測到本節(jié)點(diǎn)。典型值是NM周期的3~5倍。CanNmTimeoutTime接收超時時間。如果在這個時間內(nèi)沒有收到任何NM報文節(jié)點(diǎn)會認(rèn)為網(wǎng)絡(luò)異常。這個值必須大于NM周期通常取周期的4~5倍。CanNmWaitBusSleepTime從Ready Sleep到Bus-Sleep的等待時間。這個值要大于NM周期確保最后一幀NM報文能被所有節(jié)點(diǎn)收到。CanNmImmediateNmTransmissions喚醒后立即發(fā)送的NM報文次數(shù)。這個機(jī)制用于快速喚醒網(wǎng)絡(luò)通常配3~5次。5.3 配置代碼示例與RTE接口配置工具生成的代碼主要是數(shù)據(jù)結(jié)構(gòu)的初始化實(shí)際的狀態(tài)機(jī)邏輯在CanNm模塊的源碼里。應(yīng)用層通過RTE調(diào)用Nm模塊的接口來請求或釋放網(wǎng)絡(luò)典型接口包括/* 請求網(wǎng)絡(luò)保持網(wǎng)絡(luò)喚醒 */ Nm_NetworkRequest(Nm_ChannelType channel); /* 釋放網(wǎng)絡(luò)允許網(wǎng)絡(luò)睡眠 */ Nm_NetworkRelease(Nm_ChannelType channel); /* 獲取當(dāng)前網(wǎng)絡(luò)狀態(tài) */ Nm_StateType Nm_GetState(Nm_ChannelType channel); /* 主動喚醒網(wǎng)絡(luò) */ Std_ReturnType Nm_PassiveStartUp(Nm_ChannelType channel);應(yīng)用層通常通過BswM基礎(chǔ)軟件模式管理器來間接調(diào)用這些接口而不是直接調(diào)用。BswM會根據(jù)應(yīng)用模式、通信模式等條件來決定是否請求網(wǎng)絡(luò)。這種分層設(shè)計的好處是應(yīng)用層不需要關(guān)心網(wǎng)絡(luò)管理的細(xì)節(jié)只需要表達(dá)“我需要通信”或“我不需要通信”。注意Nm_NetworkRequest和Nm_NetworkRelease必須成對使用。如果請求了網(wǎng)絡(luò)但忘記釋放網(wǎng)絡(luò)永遠(yuǎn)進(jìn)不了睡眠靜態(tài)電流會超標(biāo)。這是實(shí)際項(xiàng)目中最常見的NM問題之一。6. 常見問題排查與實(shí)戰(zhàn)經(jīng)驗(yàn)6.1 NM報文發(fā)不出去的排查思路NM報文發(fā)不出去是最常見的問題之一。排查時按以下順序逐層檢查檢查CanNm狀態(tài)通過調(diào)試器或XCP讀取CanNm的當(dāng)前狀態(tài)確認(rèn)是否在Network Mode。如果在Bus-Sleep說明網(wǎng)絡(luò)請求沒生效。檢查網(wǎng)絡(luò)請求確認(rèn)應(yīng)用層是否調(diào)用了Nm_NetworkRequest或者BswM是否觸發(fā)了網(wǎng)絡(luò)請求。檢查CanIf發(fā)送緩沖如果CanIf的發(fā)送緩沖滿了NM報文會發(fā)送失敗。檢查CanIf的TxBuffer配置和總線負(fù)載。檢查CanDrv郵箱最底層的問題檢查CAN控制器的發(fā)送郵箱是否正常是否有總線錯誤。檢查硬件CAN收發(fā)器、終端電阻、線束連接這些硬件問題也會導(dǎo)致發(fā)送失敗。我遇到過一次NM報文發(fā)不出去查了半天軟件最后發(fā)現(xiàn)是CAN收發(fā)器的使能引腳配置錯了收發(fā)器根本沒工作。所以排查時不要只盯著軟件硬件也要確認(rèn)。6.2 網(wǎng)絡(luò)無法進(jìn)入睡眠的典型原因網(wǎng)絡(luò)無法睡眠是另一個高頻問題直接表現(xiàn)為靜態(tài)電流超標(biāo)。常見原因包括應(yīng)用層忘記釋放網(wǎng)絡(luò)某個應(yīng)用模塊請求了網(wǎng)絡(luò)但沒有釋放導(dǎo)致節(jié)點(diǎn)一直留在Normal Operation。NM報文持續(xù)被接收總線上有其他節(jié)點(diǎn)一直在發(fā)NM報文本節(jié)點(diǎn)收到后不斷刷新定時器無法進(jìn)入睡眠。定時器配置錯誤CanNmTimeoutTime或CanNmWaitBusSleepTime配置過小或過大導(dǎo)致狀態(tài)遷移異常。網(wǎng)絡(luò)管理協(xié)調(diào)器問題如果使用了NM協(xié)調(diào)器協(xié)調(diào)器的邏輯可能阻止了網(wǎng)絡(luò)睡眠。診斷會話保持診斷會話未結(jié)束診斷模塊持有網(wǎng)絡(luò)請求。排查這類問題時用CANoe或類似工具抓取總線上的NM報文看是哪個節(jié)點(diǎn)一直在發(fā)。如果所有節(jié)點(diǎn)都停了但網(wǎng)絡(luò)還是沒睡那就是本節(jié)點(diǎn)的應(yīng)用層或配置問題。6.3 喚醒異常與重復(fù)喚醒的處理喚醒異常通常表現(xiàn)為網(wǎng)絡(luò)被意外喚醒、喚醒后無法正常通信、反復(fù)喚醒導(dǎo)致電流波動。常見原因和處理方法問題現(xiàn)象可能原因處理方法網(wǎng)絡(luò)被意外喚醒總線上的干擾被誤判為喚醒事件檢查CanIf的喚醒濾波配置喚醒后無法通信NM狀態(tài)機(jī)未正確遷移檢查喚醒源配置和狀態(tài)機(jī)參數(shù)反復(fù)喚醒某個節(jié)點(diǎn)反復(fù)請求網(wǎng)絡(luò)抓包定位異常節(jié)點(diǎn)喚醒響應(yīng)慢Immediate NM配置不當(dāng)調(diào)整立即發(fā)送次數(shù)和周期部分節(jié)點(diǎn)未喚醒喚醒報文未覆蓋所有節(jié)點(diǎn)檢查NM報文ID和接收濾波配置6.4 用CANoe分析NM報文的實(shí)操技巧CANoe是分析NM報文最常用的工具。幾個實(shí)用技巧建立NM報文過濾在Trace窗口設(shè)置過濾條件只看NM報文ID段避免被應(yīng)用報文淹沒。使用Graphics窗口把NM報文的關(guān)鍵字節(jié)如Source Node ID、CBV拖到Graphics窗口可以直觀看到各節(jié)點(diǎn)的發(fā)送節(jié)奏。統(tǒng)計發(fā)送周期用CANoe的統(tǒng)計功能測量每個節(jié)點(diǎn)NM報文的實(shí)際發(fā)送周期與配置值對比判斷是否有異常。模擬節(jié)點(diǎn)用CANoe的CAPL腳本模擬某個節(jié)點(diǎn)的NM行為測試網(wǎng)絡(luò)協(xié)調(diào)邏輯。記錄長時間數(shù)據(jù)NM問題往往需要長時間觀察用CANoe的Logging功能記錄幾小時的報文事后分析。提示分析NM問題時建議同時記錄總線負(fù)載、NM報文周期、各節(jié)點(diǎn)狀態(tài)變化綜合判斷。單看某一項(xiàng)容易誤判。7. 幾個容易踩坑的配置細(xì)節(jié)7.1 NM報文ID與接收濾波的匹配NM報文ID的分配方式直接影響接收濾波的配置。如果OEM采用“基礎(chǔ)ID Node ID”的方式那每個節(jié)點(diǎn)的NM報文ID都不同接收方需要配置一個ID范圍來接收所有NM報文。如果配置成只接收特定ID就會漏收其他節(jié)點(diǎn)的NM報文導(dǎo)致網(wǎng)絡(luò)協(xié)調(diào)失敗。我見過一個項(xiàng)目接收濾波只配了本節(jié)點(diǎn)的NM報文ID結(jié)果收不到其他節(jié)點(diǎn)的NM報文網(wǎng)絡(luò)永遠(yuǎn)無法協(xié)調(diào)睡眠。這種問題在集成測試階段才會暴露排查起來很費(fèi)時間。7.2 部分網(wǎng)絡(luò)Partial Networking的配置要點(diǎn)部分網(wǎng)絡(luò)是AUTOSAR網(wǎng)絡(luò)管理的一個高級特性允許網(wǎng)絡(luò)中的部分節(jié)點(diǎn)保持睡眠只喚醒需要的節(jié)點(diǎn)。PN的配置比普通NM復(fù)雜得多涉及PN過濾、PN信息位、PN掩碼等。配置PN時要注意PN報文ID和普通NM報文ID可能不同接收濾波要同時覆蓋。PN信息位在CBV中的位置要確認(rèn)。PN掩碼的配置要與OEM的PN定義一致。PN功能需要硬件支持不是所有CAN控制器都支持。PN功能用得好可以顯著降低靜態(tài)電流但配置復(fù)雜調(diào)試周期長。如果項(xiàng)目沒有明確的PN需求建議先用普通NM穩(wěn)定后再考慮PN。7.3 多通道NM的協(xié)調(diào)問題有些ECU同時掛在多個CAN通道上比如網(wǎng)關(guān)需要處理多通道的NM協(xié)調(diào)。多通道NM的復(fù)雜性在于不同通道的網(wǎng)絡(luò)狀態(tài)可能不同一個通道睡了另一個還醒著網(wǎng)關(guān)需要決定何時整體睡眠。處理多通道NM時通常使用Nm協(xié)調(diào)器或者BswM的協(xié)調(diào)邏輯。配置時要明確哪個通道是主通道通道間的狀態(tài)如何同步協(xié)調(diào)器的睡眠條件是什么。這些問題在項(xiàng)目初期就要定義清楚后期修改成本很高。8. 寫在最后一些個人體會NM這塊內(nèi)容看規(guī)范的時候覺得不難就那么幾個狀態(tài)、幾個定時器但真正到項(xiàng)目里問題往往出在細(xì)節(jié)上。Node ID配錯、定時器參數(shù)不匹配、應(yīng)用層忘記釋放網(wǎng)絡(luò)、接收濾波漏配這些都是我實(shí)際踩過的坑。我的建議是項(xiàng)目初期就把NM的參數(shù)定義清楚和OEM確認(rèn)好通信矩陣?yán)锏拿恳粋€字段不要等到集成測試才發(fā)現(xiàn)問題。調(diào)試階段多用CANoe抓包把NM報文的行為可視化比對著代碼猜要高效得多。另外NM的測試要覆蓋各種邊界場景正常睡眠、正常喚醒、異常喚醒、部分節(jié)點(diǎn)掉線、總線干擾等這些場景在實(shí)際車上都可能遇到。還有一點(diǎn)NM的配置和診斷、BswM、ComM等模塊都有交互排查問題時不要只看CanNm要順著調(diào)用鏈往上往下都看看。很多時候問題不在NM本身而在上層模塊的網(wǎng)絡(luò)請求邏輯或者下層的CAN配置。最后分享一個小技巧如果懷疑某個節(jié)點(diǎn)的NM行為異?？梢杂肅ANoe的CAPL腳本模擬這個節(jié)點(diǎn)單獨(dú)測試它的NM邏輯排除其他節(jié)點(diǎn)的干擾。這個方法在定位多節(jié)點(diǎn)協(xié)調(diào)問題時特別有效。