項目包含Autosar網(wǎng)絡(luò)管理時，一般會要求Node外發(fā)的第一幀是網(wǎng)絡(luò)管理報文，目的是為快速喚醒網(wǎng)絡(luò)；同時也會充分考慮通信棧的任務(wù)周期和時序，因為網(wǎng)絡(luò)狀態(tài)切換與其密切相關(guān)，如果未考慮好這兩點則可能帶來潛在的Bug。本文從工程實際出發(fā)，分享一個實例：Node路由超時引發(fā)的Bug。

1、需求描述

如下圖，Node1所在CAN/Flexray總線接收網(wǎng)絡(luò)管理報文NM1，該網(wǎng)絡(luò)管理報文在VCU內(nèi)部轉(zhuǎn)發(fā)給Node2（Node2連接CAN總線），如果收到的NM1包含Node2的PNCdes置位，則Node2網(wǎng)絡(luò)喚醒，且Node2發(fā)送網(wǎng)絡(luò)管理報文NM2。這里使用了PN的GateWay功能。

注意：Node1接收的NM1報文可以是不同的節(jié)點發(fā)來的網(wǎng)絡(luò)管理報文，即測試時，接收到的NM1報文時間可以是隨機的。

接收的NM1報文，第一次PNCsrc = 1、PNCdes = 1時，設(shè)置時間為T1，Node2外發(fā)第一幀NM2的時間設(shè)置為T2，需求規(guī)定T2-T1 ＜ 15ms，偏差10%，即(T2-T1)max < 15+15*10% = 16.5ms，T2-T1=Tgate。

NM1在Node1 Bus和NM2在Node2 Bus的具體行為如下所示：

實際測試結(jié)果：實際測試Tgate ＞ 16.5ms，不符合需求，Bug就這么來了。

2、Bug原因分析

問題點1：Node2發(fā)出的第一幀報文不是網(wǎng)絡(luò)管理報文NM2，而是Node2的應(yīng)用報文（周期性報文），由于NM2的優(yōu)先級低于應(yīng)用報文，導(dǎo)致NM2發(fā)送延遲。

具體分析1：如下圖所示，如果NM、App等報文在通信開啟的那一刻（t0）都請求驅(qū)動發(fā)送報文，比如：Can Controller，它只能根據(jù)優(yōu)先級（CANID）決定報文發(fā)送順序，因為NM報文相對App報文優(yōu)先級低，所以NM報文會被延遲發(fā)送。

如果讓每個周期性App報文，偏移（Offset）一段時間（t1、t2等）發(fā)送，而不是在t0時刻搶占NM報文，則可以讓NM報文優(yōu)先發(fā)送。

問題點2

：通信棧模塊周期不匹配，這個因素影響較大

具體分析2

：比如CanSM、CanNM、Can等模塊任務(wù)周期是5ms，ComM模塊任務(wù)周期是20ms。當收到NM1中的

PNCsrc = 1

時，信息由CanNM通知到ComM，ComM切換到FULL_COMMUNICATION，這個過程實際只是一個狀態(tài)切換指令下發(fā)，真正做狀態(tài)切換的是CanSM，而CanSM狀態(tài)機的切換需要時間，切換狀態(tài)后通知到ComM，

此時ComM至少要一個任務(wù)周期（20ms）才能知道狀態(tài)是否切換成功，切換成功才請求NM啟動網(wǎng)絡(luò)，

網(wǎng)絡(luò)狀態(tài)切換告知ComM時間過長導(dǎo)致路由時間超時

3、Bug修復(fù)策略

問題點1修復(fù)策略

CanNM模塊修改配置

配置Retry Frist Message Request，確保Node2的NM2報文發(fā)送成功，即當前周期發(fā)送失敗，下一周期繼續(xù)嘗試發(fā)送。

Com模塊修改配置

Com模塊中，配置所有周期性(PERIODIC)/混合(MIXED)應(yīng)用報文偏移值（ComTxModeTimeOffset，默認值為0），避免高優(yōu)先級的應(yīng)用報文在通信開始時，搶占網(wǎng)絡(luò)管理報文，確保網(wǎng)絡(luò)管理報文被優(yōu)先發(fā)送。

問題點2修復(fù)策略

修改ComM模塊任務(wù)周期。由20ms調(diào)整到5ms，與CanSM、CanNM、Can等通信模塊任務(wù)周期匹配，確保ComM能更快地獲取底層狀態(tài)切換結(jié)果。


審核編輯：劉清