糾錯(cuò)1

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

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

即：被動(dòng)喚醒沒有快發(fā)模式?？彀l(fā)模式需要滿足的條件：

節(jié)點(diǎn)非PASSIVE MODE；

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

CanNmImmediateNmTransmissions＞0。

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

CASE1：

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

CASE2：

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

注意：

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

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

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

糾錯(cuò)2

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

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

FrNm_ReaySleepCnt>0；

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

FrNM_RepeatMessage=FALSE。

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

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

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

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

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

Step2：使用物理尋址升級(jí)目標(biāo)ECU（進(jìn)入編程會(huì)話，$10 02），比如：下圖的ECU3；

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

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

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

具體解釋：

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

$28服務(wù)針對(duì)非診斷報(bào)文的通信

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

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

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

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

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

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

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

注意：

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

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

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

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

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

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

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

審核編輯：劉清