糾錯1

Autosar網絡管理：網絡管理報文的收/發與網絡管理時間配置參數解析

一文中，提到這樣一個觀點“3.有快速發送功能（網絡被動喚醒）：在RMS狀態下，先以快發周期發送一定次數的網絡管理報文，eg：20ms發送10次，之后以正常周期發送網絡管理報文，eg：500ms。”此處表達不準確，收到網絡管理報文（沒有PN功能），被動喚醒(調用CanNm_PassiveStartUp()接口)，沒有快發模式。

即：被動喚醒沒有快發模式。快發模式需要滿足的條件：

節點非PASSIVE MODE；

調用CanNm_NetworkRequest()接口主動請求網絡；

CanNmImmediateNmTransmissions＞0。

看一下Autosar規范給的解釋，如下所示：

CASE1：

可以看出，由BSM或者PBSM進入RMS，由CanNm_NetworkRequest()觸發，且CanNmImmediateNmTransmissions＞0時，使能快發模式。

CASE2：

CanNmPnHandleMultipleNetworkRequests = TRUE，可以理解為PN功能使能，調用CanNm_NetworkRequest()接口進入RMS狀態時，CanNmImmediateNmTransmissions＞0，使能快發模式。

注意：

CanNmImmediateNmTransmissions設置為1，沒有意義，工程需求中，常見設置：10、20等；

CanNmRepeatMessageTime > CanNmImmediateNmTransmissions * CanNmImmediateNmCycleTime，即：快發模式限于RMS狀態；

快發功能使用時，CanNmMsgCycleOffset不再適用，既然都快發了，就是想快速喚醒網絡，所以，沒必要再延遲發送NM Msg。

糾錯2

工程開發問題（七）：Flexray網絡狀態切換錯誤，通信異常一文中，說到：“Fr節點進入RSS狀態以后，即使本節點有內部網絡請求（Network Request，比如：VFC置位），節點也不會進入NOS狀態?！?，該表達不準確。完整的解讀Autosar規范如下所示：

意思是說，Flexray節點在RSS狀態下，如果同時滿足如下條件：

FrNm_ReaySleepCnt>0；

FrNm_NetworkRequest=TRUE，主動調用FrNm_NetworkRequest()接口；

FrNM_RepeatMessage=FALSE。

在當前Repetition Cycle結束后，Flexray節點的網絡狀態由RSS進入NOS狀態。

網絡管理問題QA

Q1：Application軟件升級，$11復位后，節點處于何種網絡狀態？

A1：本問題源于一個朋友的討論。在此，說一下個人理解。正常的刷寫流程中，一般操作如下：

Step1：拓展會話($10 03)中，使用功能尋址將總線上的所有節點通信（0x28服務）和DTC監控（0x85服務）禁用，功能尋址一直在周期性發送$3E 80（維持會話）；

Step2：使用物理尋址升級目標ECU（進入編程會話，$10 02），比如：下圖的ECU3；

Step3：ECU3升級完成以后，使用物理尋址發送$11 01服務，復位ECU3；

Step4：等待一定時間（比如：2s）,功能尋址發送$10 03服務，使ECU3進入拓展會話；

Step5：再等待一定時間（比如：2s）,功能尋址發送$28服務，使能所有節點通信；......

具體解釋：

Step3中，發送$11 01使ECU3復位，ECU3執行復位，由Boot跳轉到Application，Application程序初始化，Application程序運行起來，需要一定時間，這是上位機（Tester）延遲2s的作用(確保Application程序已經完成初始化動作)，這個時間內ECU3節點網絡處于BSM（Bus Sleep Mode）模式；Step4中，功能尋址發送$10 03服務，主要使ECU3進入拓展會話。在升級ECU3的過程中，由于Tester一直周期性發送$3E 80（避免因S3超時，ECU1、ECU2進入默認會話，使得通信和DTC控制失效），ECU1和ECU2一直在拓展會話呆著。Step5中，又經過2s時間，Tester發送$28 00服務，開啟通信。提示：

$28服務針對非診斷報文的通信

（比如：網絡管理報文、應用報文），主要是把總線讓給診斷報文，提高刷寫速率。所以，ECU3只要完成啟動流程，Controller和Transceiver進入Normal模式，ECU3就可以正常接收診斷報文。如果開發的ECU要求

網絡管理報文喚醒網絡，此時ECU3節點的網絡狀態處于何種模式呢？答：個人理解，BSM。雖然上位機從請求ECU復位到發送$28服務（開通信）間隔了4s時間，但是這4s時間內有一定的時間ECU在完成初始化（一般要求100~300ms時間范圍）。

如上圖：T0時刻，ECU3收到$11 01復位，一般程序會在Boot呆一定時間，比如：50ms（Stay In Boot功能），之后識別到App程序有效，Jump到App，完成App初始化，在OS RUN之前需要100~300ms時間不等（每個項目的代碼量和功能有所不同，耗時不同）。

到T2時刻使能通信之前的這段時間，ECU3處于BSM模式，原因：沒有收到有效的喚醒事件（比如：沒有收到網絡管理報文）。注意：

ECU1和ECU2一直處于NM（Network Mode），因為診斷報文在一直維持兩者的網絡狀態。

T2時刻，ECU1和ECU2的通信使能，可以發送網絡管理報文和應用報文，ECU3接收到網絡管理報文以后，進入NM，ECU3相當于被動喚醒。

所以，從ECU3復位，到接收到$28 00服務，近4s的時間內，ECU3的網絡狀態處于BSM模式。

注意：

再次提醒：不要混淆ECU喚醒和網絡喚喚醒。雖然ECU3收到診斷報文，可以處理診斷服務，但是診斷報文并不是有效的喚醒源，如果Transceiver沒有硬件過濾功能，診斷報文可以將ECU喚醒（uC被供電），但是網絡并未喚醒，此時ECU會保持一定時間驗證喚醒事件的有效性，比如：3s等；

有些節點的Transceiver有過濾功能，即：只能有效的網絡管理報文被接收，所以，冷啟動時，診斷報文，ECU接收不到；

某些ECU的開發中，會將診斷報文作為有效喚醒源，即：網絡管理報文一樣，可以喚醒網絡，診斷報文和注意識別。

$11 01診斷服務思考

工程中，ECU刷寫后，需要$11 01執行uC的復位，這個復位可以操作PORST Pin，控制uC的Vcc供電（5V），使得uC完成一個熱啟動過程，即：ECU復位。注意，這個復位動作，雖然也給uC重新供電，但是，它不同于KL15硬線上電，不能看作主動喚醒，所以$11 01診斷復位不能觸發網絡的主動喚醒。

提示：$11 01復位，執行uC的下電流程，需要執行NVM的存儲。

如下通過控制SBC（System Basis Chip）實現uC復位，也可以通過控制外部看門狗實現。

審核編輯：劉清