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