糾錯1

Autosar網(wǎng)絡(luò)管理：網(wǎng)絡(luò)管理報文的收/發(fā)與網(wǎng)絡(luò)管理時間配置參數(shù)解析

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

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

節(jié)點非PASSIVE MODE；

調(diào)用CanNm_NetworkRequest()接口主動請求網(wǎng)絡(luò)；

CanNmImmediateNmTransmissions＞0。

看一下Autosar規(guī)范給的解釋，如下所示：

CASE1：

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

CASE2：

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

注意：

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

CanNmRepeatMessageTime > CanNmImmediateNmTransmissions * CanNmImmediateNmCycleTime，即：快發(fā)模式限于RMS狀態(tài)；

快發(fā)功能使用時，CanNmMsgCycleOffset不再適用，既然都快發(fā)了，就是想快速喚醒網(wǎng)絡(luò)，所以，沒必要再延遲發(fā)送NM Msg。

糾錯2

工程開發(fā)問題（七）：Flexray網(wǎng)絡(luò)狀態(tài)切換錯誤，通信異常一文中，說到：“Fr節(jié)點進入RSS狀態(tài)以后，即使本節(jié)點有內(nèi)部網(wǎng)絡(luò)請求（Network Request，比如：VFC置位），節(jié)點也不會進入NOS狀態(tài)。”，該表達不準確。完整的解讀Autosar規(guī)范如下所示：

意思是說，F(xiàn)lexray節(jié)點在RSS狀態(tài)下，如果同時滿足如下條件：

FrNm_ReaySleepCnt>0；

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

FrNM_RepeatMessage=FALSE。

在當前Repetition Cycle結(jié)束后，F(xiàn)lexray節(jié)點的網(wǎng)絡(luò)狀態(tài)由RSS進入NOS狀態(tài)。

網(wǎng)絡(luò)管理問題QA

Q1：Application軟件升級，$11復位后，節(jié)點處于何種網(wǎng)絡(luò)狀態(tài)？

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

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

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

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

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

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

具體解釋：

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

$28服務(wù)針對非診斷報文的通信

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

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

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

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

ECU1和ECU2一直處于NM（Network Mode），因為診斷報文在一直維持兩者的網(wǎng)絡(luò)狀態(tài)。

T2時刻，ECU1和ECU2的通信使能，可以發(fā)送網(wǎng)絡(luò)管理報文和應(yīng)用報文，ECU3接收到網(wǎng)絡(luò)管理報文以后，進入NM，ECU3相當于被動喚醒。

所以，從ECU3復位，到接收到$28 00服務(wù)，近4s的時間內(nèi)，ECU3的網(wǎng)絡(luò)狀態(tài)處于BSM模式。

注意：

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

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

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

$11 01診斷服務(wù)思考

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

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

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

審核編輯：劉清