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

1、需求描述

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

注意：Node1接收的NM1報文可以是不同的節點發來的網絡管理報文，即測試時，接收到的NM1報文時間可以是隨機的。

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

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

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

2、Bug原因分析

問題點1：Node2發出的第一幀報文不是網絡管理報文NM2，而是Node2的應用報文（周期性報文），由于NM2的優先級低于應用報文，導致NM2發送延遲。

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

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

問題點2

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

具體分析2

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

PNCsrc = 1

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

此時ComM至少要一個任務周期（20ms）才能知道狀態是否切換成功，切換成功才請求NM啟動網絡，

網絡狀態切換告知ComM時間過長導致路由時間超時

3、Bug修復策略

問題點1修復策略

CanNM模塊修改配置

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

Com模塊修改配置

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

問題點2修復策略

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


審核編輯：劉清