AUTOSAR與OSEK的關(guān)系 ?

AUTOSAR與OSEK二者都是汽車電子軟件的標(biāo)準(zhǔn)。OSEK/VDX是基于ECU開發(fā)的操作系統(tǒng)標(biāo)準(zhǔn)，AUTOSAR基于整體汽車電子開發(fā)的功能標(biāo)準(zhǔn)。AUTOSAR中規(guī)定的操作系統(tǒng)標(biāo)準(zhǔn)就是基于OSEK/VDX，通信和網(wǎng)絡(luò)管理雖然和OSEK有區(qū)別，但是是有繼承性的。可以認(rèn)為，AUTOSAR是基于OSEK/VDX發(fā)展出來的，OSEK/VDX被AUTOSAR標(biāo)準(zhǔn)軟件架構(gòu)所包含。 ? ?

AUTOSAR ?

AUTOSAR（Automotive Open System Architecture，即汽車開放系統(tǒng)架構(gòu)）的出現(xiàn)是為了解決汽車電子架構(gòu)日益增加的ECU單元帶來的復(fù)雜系統(tǒng)設(shè)計(jì)問題，讓汽車電子系統(tǒng)開發(fā)更靈活，更有效率。 ?

2003年汽車行業(yè)內(nèi)的幾大巨頭（BMW, Bosch, Continental, DaimlerChrysler, Volkswagen, Siemens VDO）聯(lián)合建立了AUTOSAR聯(lián)盟，一起開發(fā)并建立一套真正的開放的汽車電子電器架構(gòu)，也就是我們現(xiàn)在所說的AUTOSAR標(biāo)準(zhǔn)或者AUTOSAR架構(gòu)，我們經(jīng)常提到的AUTOSAR一般就是指AUTOSAR構(gòu)架/標(biāo)準(zhǔn)，AUTOSAR的全稱是AUTomotive Open System ARchitecture，隨著多年的發(fā)展，越來越多的行業(yè)內(nèi)的公司加入到了AUTOSAR聯(lián)盟中，這其中有OEM（汽車整車廠），Tier1（汽車零部件供應(yīng)商），芯片制造商以及工具制造商，AUTOSAR構(gòu)架/標(biāo)準(zhǔn)也成為了汽車E/E設(shè)計(jì)的發(fā)展方向。 ?

AUTOSAR架構(gòu)和標(biāo)準(zhǔn)的目標(biāo)是：

滿足未來汽車的需求，如可用性和安全性、軟件升級更新、可維護(hù)性等

增加軟件的靈活性和可擴(kuò)展性來實(shí)現(xiàn)軟件的集成和整合

實(shí)現(xiàn)商用現(xiàn)成的跨產(chǎn)品線的軟件硬件

控制產(chǎn)品和流程的復(fù)雜度和風(fēng)險(xiǎn)

優(yōu)化成本

AUTOSAR架構(gòu)的主要特點(diǎn)是：

模塊化和可配置性

標(biāo)準(zhǔn)化接口

提出了RTE的概念

標(biāo)準(zhǔn)的測試規(guī)范

AUTOSAR標(biāo)準(zhǔn)有四個核心內(nèi)容：

ECU軟件構(gòu)架

軟件組件（software components）

虛擬功能總線（Virtual Functional Bus）

AUTOSAR設(shè)計(jì)方法（Methodology）

OSEK ?

為了解決汽車控制技術(shù)通信和網(wǎng)絡(luò)發(fā)展多元化帶來的軟件移植和不同應(yīng)用程序的接口協(xié)調(diào)問題，德國汽車工業(yè)界在1993年推出了OSEK（open systems and the corresponding interfaces for automotive electronics）體系，定義汽車開放式系統(tǒng)及接口。1994年法國標(biāo)致雷諾將汽車分布式運(yùn)行系統(tǒng)VDX（vehicle distributed executive）納入OSEK。 ?

在1995年召開的OSEK研討會上，眾多的廠商對OSEK和VDX的認(rèn)識達(dá)成了共識，產(chǎn)生了OSEK/VDX規(guī)范(1997年發(fā)布)。它主要由四部分組成:操作系統(tǒng)規(guī)范(OSEK Operating System,OSEK OS)、通信規(guī)范(OSEK Communication , OSEK COM )、網(wǎng)絡(luò)管理規(guī)范( OSEK Net Management, OSEK NM)和OSEK實(shí)現(xiàn)語言(OSEK Implementation Language,OIL)。 ?

此后，各軟件生產(chǎn)廠商都相繼推出了符合OSEK規(guī)范的產(chǎn)品。隨著該規(guī)范應(yīng)用的不斷深入，其結(jié)構(gòu)和功能不斷完善和優(yōu)化，版本也不斷升級和擴(kuò)展。目前OSEK OS2.2 , OSEK COM2.3 , OSEK NM2.3和OIL2.3已經(jīng)提交ISO審議，即將成為一個國際標(biāo)準(zhǔn)。

? ?

OSEK規(guī)范為實(shí)現(xiàn)其制定的初衷并滿足汽車控制領(lǐng)域?qū)ο到y(tǒng)安全性和節(jié)省有限資源的特殊要求，制定了系統(tǒng)而全面的操作系統(tǒng)規(guī)范。 ?

其特點(diǎn)主要有以下幾個方面：

實(shí)時性

可移植性

可擴(kuò)展性

由上我們可以看出，AUTOSAR與OSEK二者都是汽車電子軟件的標(biāo)準(zhǔn)。OSEK基于ECU開發(fā)，AUTOSAR基于整體汽車電子開發(fā)。AUTOSAR中規(guī)定的操作系統(tǒng)就是OSEK，而通信和網(wǎng)絡(luò)管理雖然和OSEK有區(qū)別，但思路一樣的。所以認(rèn)為，AUTOSAR是基于OSEK提出的（但不僅基于OSEK），OSEK被AUTOSAR標(biāo)準(zhǔn)軟件架構(gòu)包含。 ? ?

AUTOSAR和OSEK網(wǎng)絡(luò)管理比較 ?

1. OSEK - Simplified state transition diagram of the direct NM ?

OSEK建立邏輯環(huán)

直接網(wǎng)絡(luò)管理（以下簡稱為NM）通過發(fā)送和接收兩種類型的消息來建立邏輯環(huán)：Alive message和Ring message。其中，Alive message是一個節(jié)點(diǎn)要加入邏輯環(huán)時要發(fā)送的消息，Ring message是網(wǎng)絡(luò)正常工作時的環(huán)消息，是從一個節(jié)點(diǎn)傳遞給下一個節(jié)點(diǎn)，依次在邏輯環(huán)中傳遞，以表示網(wǎng)絡(luò)中的節(jié)點(diǎn)正常工作。當(dāng)某一節(jié)點(diǎn)功能不正常時，就會周期性的向網(wǎng)絡(luò)中發(fā)送LimpHome message。 ?

邏輯環(huán)的建立通過一種發(fā)送“令牌（Token）”的方式來進(jìn)行，按標(biāo)識符由小到大的順序進(jìn)行傳遞，最初發(fā)送Alive message的節(jié)點(diǎn)（或者標(biāo)識符優(yōu)先級高的節(jié)點(diǎn)）成為邏輯環(huán)中的第一個發(fā)送節(jié)點(diǎn)，消息都是以廣播的方式發(fā)送的，這就使得每個節(jié)點(diǎn)發(fā)送的消息，其他節(jié)點(diǎn)都可以監(jiān)測到，以確定自己是否為上一個發(fā)送節(jié)點(diǎn)的后繼節(jié)點(diǎn)，并更新節(jié)點(diǎn)的運(yùn)行狀態(tài)等。

? ?

所有參與建環(huán)的ECU在建環(huán)初期，發(fā)出報(bào)文數(shù)據(jù)的第一字節(jié)都是自己的ID ，第二字節(jié)都是 0xC9 ，即協(xié)議里講的發(fā)出指向自身的 Alive 報(bào)文，每個 ECU 都發(fā)完 Alive 報(bào)文之后，就建立起來邏輯環(huán)了，上圖的后面幾幀報(bào)文， ECU25 指向了 ECU17 ， ECU17指向了ECU1D， ECU1D指向了ECU21， ECU21指向ECU22 ， ECU22指向ECU25 ，ECU25 指向 ECU17 ，形成一個封閉的邏輯環(huán)，且第二字節(jié)都是 Ring 置 1 的 Ring 報(bào)文。??

正常建環(huán)的情況下，上一條NM報(bào)文的ID就是下一條NM報(bào)文的第一字節(jié)的數(shù)據(jù)，比如劃線的3條報(bào)文，第一條報(bào)文的ID為0x19，數(shù)據(jù)的第一字節(jié)為0xE8，第二條報(bào)文的ID為0xE8，數(shù)據(jù)的第一字節(jié)為0xEE，第三條報(bào)文的ID為0xEE，數(shù)據(jù)的第一字節(jié)為0x19，所有正常建環(huán)的報(bào)文的第二字節(jié)，其Bit2置1，表示發(fā)出了正常建環(huán)的Ring報(bào)文，這就是所謂的邏輯環(huán)。

ECU 進(jìn)入 LimpHome 狀態(tài)時的情況，下圖所示，在網(wǎng)絡(luò)上只有一個 NM 節(jié)點(diǎn)的情況下， ECU上電后，先嘗試建立邏輯環(huán)，嘗試 5 次后，依舊無法建立邏輯環(huán)，則 ECU 進(jìn)入 LimpHome 狀態(tài)， ECU 按 TError (一般是 1000ms )的周期發(fā)送 LimpHome 位置 1 的報(bào)文，下圖可以看出， LimpHome 報(bào)文的第一字節(jié)指向自己，第二字節(jié)為 0x04 。
?

? ? ?

OSKE網(wǎng)絡(luò)管理的休眠過程，當(dāng)我們下到 OFF 檔時，控制器滿足了休眠條件，就會發(fā)出睡眠指示位 (Sleep.Ind) 置 1 的 Ring 報(bào)文，如圖中的第二字節(jié)數(shù)據(jù)為 0x12 的報(bào)文，當(dāng)所有節(jié)點(diǎn)都滿足休眠條件，發(fā)出 0x12 的報(bào)文后，最后一個休眠節(jié)點(diǎn)的下一個節(jié)點(diǎn)，就會發(fā)出睡眠應(yīng)答位 (Sleep.Ack) 置 1 的 Ring 報(bào)文，如圖中的第二字節(jié)數(shù)據(jù)為 0x32 的報(bào)文，同一網(wǎng)段的控制器收到這個報(bào)文后，就會進(jìn)入睡眠狀態(tài)，這個時候，會停止發(fā)送任何報(bào)文到總線，等待 ECU 的內(nèi)部任務(wù)完成后，就會進(jìn)入低功耗模式，靜態(tài)電流會變得很小。

? ?

2. AutoSAR - CanNm Algorithm ?

?

NM狀態(tài)機(jī) ?

狀態(tài)機(jī)的狀態(tài)類型可分為“三大三小”。其中“三大”指的是Bus Sleep Mode、Network Mode、Prepare Bus-Sleep Mode；而“三小”則值得是Network Mode下的三個子狀態(tài)：Repeat Message State、Normal Operation Mode、Ready Sleep Mode。 ?

Bus Sleep Mode

當(dāng)沒有遠(yuǎn)程喚醒或者本地喚醒請求時，ECU的Controller應(yīng)當(dāng)切換至Sleep模式，電流消耗將降低至最低水平，該Mode是ECU啟動時的起始狀態(tài)或者是ECU睡眠時的最終狀態(tài)。 ? 在該模式下，NM報(bào)文以及應(yīng)用報(bào)文都應(yīng)該被禁止發(fā)送，但是可以被網(wǎng)絡(luò)上的報(bào)文喚醒。 ?

在此特意說明一點(diǎn)，當(dāng)Transiver支持并使能了特定幀喚醒時，該ECU只會接受到特定的NM報(bào)文才會正常喚醒，否則就會一直處于休眠狀態(tài)，能夠不受網(wǎng)絡(luò)上應(yīng)用報(bào)文的干擾。 ?

如果Transiver不支持特定幀喚醒，那么網(wǎng)絡(luò)的任意報(bào)文都可以喚醒該ECU，如果喚醒條件不滿足，又會走休眠流程繼續(xù)睡下去，這樣“睡醒交替”的方式就是不支持特定幀喚醒的Transiver的典型特征。

當(dāng)然，如果整車上的NM都可以正常運(yùn)作，那么就不會頻繁出現(xiàn)這種“睡醒交替”的方式，這種方式一般都是在做測試時才會較多的體現(xiàn)出來。 ?

Network Mode

一旦進(jìn)入Network Mode，計(jì)時器T_NM_Timeout就會啟動，只要成功接收到來自總線上的NM報(bào)文或者成功發(fā)送至總線NM報(bào)文，都會將該計(jì)時器T_NM_Timeout重置。 ?

該模式又進(jìn)一步細(xì)分為以下三種子狀態(tài)，RMS、NOS、RSS。 ?

1、Repeat Message State（RMS） ?

該狀態(tài)能夠確保當(dāng)ECU的狀態(tài)機(jī)從Bus-Sleep Mode或者Prepare Bus-Sleep mode切換至Network Mode時能夠及時的被網(wǎng)絡(luò)上其他ECU節(jié)點(diǎn)發(fā)現(xiàn)，也就是告訴其他ECU，“大家注意了，我成功上線了，請多多指教！” ? 當(dāng)成功進(jìn)入到RMS狀態(tài)時，該節(jié)點(diǎn)就會重新發(fā)送NM報(bào)文并開啟計(jì)時器T_REPEAT_MESSAGE，應(yīng)用報(bào)文則需要等待第一幀網(wǎng)絡(luò)管理報(bào)文發(fā)送之后再發(fā)送。 ?

當(dāng)然，第一幀NM報(bào)文可以通過配置參數(shù)MSG_CYCLE_ OFFSET來延遲發(fā)送，降低在同一時間內(nèi)的總線負(fù)載，這個配置參數(shù)默認(rèn)是0 ，一般根據(jù)測試結(jié)果來做適當(dāng)?shù)恼{(diào)整。 ? 在計(jì)時器T_REPEAT_MESSAGE超時之前，該節(jié)點(diǎn)就會一直保持在該狀態(tài)，否則將會離開該狀態(tài)。 ?

在該狀態(tài)下也存在著兩個子狀態(tài)： ?

NM Immediate Transmit State ?

在該模式下，ECU的目的是快速喚醒整個網(wǎng)絡(luò)，同時該節(jié)點(diǎn)將會以配置參數(shù)T_NM_ImmediateCycleTime的周期發(fā)送NM報(bào)文，而發(fā)送次數(shù)則是由配置參數(shù)N_ImmediateNM_TIMES來決定，每一次成功發(fā)送，該參數(shù)就會減1，直至為0，退出該子狀態(tài)； ?

NM Normal Transmit State ?

在該模式下，ECU節(jié)點(diǎn)將會以正常報(bào)文周期T_NM_MessageCycle的方式來發(fā)送NM報(bào)文。 ?

2、Normal Operation State（NOS） ?

只要ECU節(jié)點(diǎn)自身存在網(wǎng)絡(luò)通信的需要，那么ECU就會一直工作在NOS的狀態(tài)下。該狀態(tài)下NM報(bào)文的發(fā)送將會以T_NM_MessageCycle的周期來發(fā)送報(bào)文，每次報(bào)文的成功發(fā)送或接收或者計(jì)時器NM-Timeout超時都會重置該計(jì)時器NM-Timeout； 在該狀態(tài)下的NM報(bào)文以及應(yīng)用報(bào)文都應(yīng)該正常收發(fā)通信。 ?

3、Ready Sleep State（RSS） ?

在該模式下，ECU節(jié)點(diǎn)應(yīng)當(dāng)停止發(fā)送NM報(bào)文。每次成功接受到來自網(wǎng)絡(luò)上的NM報(bào)文，計(jì)時器T_NM_TIMEROUT 就會重置，一旦T_NM_TIMEROUT超時，那么就會離開該狀態(tài)轉(zhuǎn)而進(jìn)入Prepare Bus-Sleep狀態(tài)。 ?

Prepare Bus-Sleep Mode

一旦進(jìn)入該模式，計(jì)時器T_WAIT_BUS_SLEEP就會啟動。在該模式下禁止網(wǎng)絡(luò)管理報(bào)文的發(fā)送，允許接受NM報(bào)文。應(yīng)用報(bào)文已經(jīng)在buffer中的一般允許繼續(xù)發(fā)送，但最終應(yīng)該是silent bus，該ECU的Controller的狀態(tài)應(yīng)當(dāng)處于operational mode。一旦T_WAIT_BUS_SLEEP超時，就會進(jìn)入到Bus-Sleep階段。 ?

Passive Mode

?在該模式下只接受NM報(bào)文，但不發(fā)送任何的NM報(bào)文。該模式可以通過配置得到，同時該模式應(yīng)只存在于開發(fā)或者調(diào)試過程中，在正式SOP的軟件中禁止出現(xiàn)此種模式。 ?

報(bào)文發(fā)送與接受狀態(tài) ?

在測試的過程中，需要針對網(wǎng)絡(luò)管理每一個狀態(tài)下的NM報(bào)文與APP報(bào)文接收與發(fā)送進(jìn)行測試。如下圖所示，體現(xiàn)了在不同NM子狀態(tài)下的報(bào)文發(fā)送與接受狀態(tài)。 ?

Bus-Sleep階段，只接收NM報(bào)文喚醒，不發(fā)送任何報(bào)文；

Pre-Bus-Sleep階段，同樣僅允許接收NM報(bào)文，對于早已在發(fā)送Buffer中的APP報(bào)文應(yīng)發(fā)送完畢后立刻停止APP報(bào)文；

Network Mode模式，除了在Ready Sleep階段不允許發(fā)送NM報(bào)文之外，其余階段APP報(bào)文與NM報(bào)文正常收發(fā)；

? ?

狀態(tài)機(jī)時間參數(shù) ?

在網(wǎng)絡(luò)管理各子狀態(tài)的切換過程中都依賴于各種計(jì)時器，相關(guān)參數(shù)總結(jié)如下。

?

3. 共同點(diǎn)：

都屬于直接網(wǎng)絡(luò)管理。

網(wǎng)絡(luò)管理的目的都是協(xié)調(diào)各節(jié)點(diǎn)同步進(jìn)入休眠及喚醒（主要是休眠）。

都依靠特定的網(wǎng)絡(luò)管理CAN報(bào)文，每個節(jié)點(diǎn)的網(wǎng)絡(luò)管理ID都不一樣。

喚醒方法相同，第一個喚醒的節(jié)點(diǎn)發(fā)送網(wǎng)絡(luò)管理幀即同時喚醒其它節(jié)點(diǎn)。

4. 不同點(diǎn)：

4.1 喚醒幀類型不一樣：

網(wǎng)絡(luò)喚醒后，OSEK要求節(jié)點(diǎn)發(fā)出的第一幀必須是Alive類型，不能是Ring, Limphome等。

AutoSar只要求是網(wǎng)絡(luò)管理幀就行，條件寬松。

4.2 休眠的同步算法不一樣：

OSEK網(wǎng)絡(luò)管理使用令牌環(huán)機(jī)制，令牌從網(wǎng)絡(luò)地址低的節(jié)點(diǎn)傳到網(wǎng)絡(luò)地址高的節(jié)點(diǎn)，如果沒有更高的節(jié)點(diǎn)，就傳給最低地址節(jié)點(diǎn)。令牌環(huán)根據(jù)ECU的網(wǎng)絡(luò)地址建立。每個ECU都會接受網(wǎng)絡(luò)管理消息，只有和目的地址相同的一個節(jié)點(diǎn)才會得到令牌。

喚醒后建立邏輯環(huán)過程：

控制器喚醒后想?yún)⑴c網(wǎng)絡(luò)的節(jié)點(diǎn)會先發(fā)Alive報(bào)文申請加入邏輯環(huán)。

邏輯環(huán)建成后，各節(jié)點(diǎn)按順序發(fā)Ring報(bào)文向后續(xù)節(jié)點(diǎn)傳遞“令牌”。

同步休眠過程：

如果邏輯環(huán)中有節(jié)點(diǎn)想休眠，就設(shè)置Ring報(bào)文中的Sleep.Ind指示位。

當(dāng)邏輯環(huán)中所有的節(jié)點(diǎn)都設(shè)置了Sleep.Ind指示位，也意味著任何節(jié)點(diǎn)接收到所有其它節(jié)點(diǎn)的Sleep.Ind指示位。

邏輯環(huán)中所有的節(jié)點(diǎn)設(shè)置Sleep.Ack指示位

任何節(jié)點(diǎn)接收到所有其它的節(jié)點(diǎn)的Sleep.Ack指示位

所有節(jié)點(diǎn)同步進(jìn)入等待睡眠狀態(tài)

tWaitBusSleep時間內(nèi)沒有收到喚醒時間，所有節(jié)點(diǎn)同步進(jìn)入睡眠狀態(tài)。

?

AutoSar基于分布式策略，每個節(jié)點(diǎn)根據(jù)通信系統(tǒng)中發(fā)送或者接收到的NM消息來執(zhí)行自給自足的網(wǎng)絡(luò)活動。NM消息通過廣播發(fā)送，所有網(wǎng)絡(luò)中的所有節(jié)點(diǎn)都可以接收到。接收到NM消息表示發(fā)送這個NM消息的節(jié)點(diǎn)傾向保持網(wǎng)絡(luò)工作模式（NETWORK MODE）。如果有節(jié)點(diǎn)準(zhǔn)備好進(jìn)入總線睡眠模式 （BUS SLEEP MODE），它就停止發(fā)送NM消息，但是只要它還能夠接收到從其他節(jié)點(diǎn)發(fā)來的NM消息，它就延遲到總線睡眠模式的變遷。最終，在一定的時限內(nèi)，由于不再接收到NM消息，每個節(jié)點(diǎn)都啟動到總線睡眠模式的變遷。如果網(wǎng)絡(luò)中的任何節(jié)點(diǎn)需要總線通信，它可以通過發(fā)送NM消息使網(wǎng)絡(luò)從來總線睡眠模式中喚醒。概括如下：

每個網(wǎng)絡(luò)節(jié)點(diǎn)如果想保持總線通信，就會一直發(fā)送周期性的NM消息；如果它不再需要保持總線通信，它就不再發(fā)送NM消息。

如果總線通信已經(jīng)被釋放，并且在配置的一段時間內(nèi)沒有發(fā)送或者接收到NM消息，則執(zhí)行到Bus-Sleep模式的轉(zhuǎn)移。

4.3 PDU結(jié)構(gòu)不一樣:

?

OSEK網(wǎng)絡(luò)幀PDU包括自己地址，目標(biāo)地址（下一個令牌環(huán)目標(biāo)），命令狀態(tài)，用戶選擇數(shù)據(jù)。

?

NM messages can have length of 4-8 bytes depending on manufacturer. Byte-1: It contains address of logical successor in the ring here. In case node is in Alive Mode or in Limphome mode , it will have the station’s own address here. Byte-2: It contains Network state information. Bit 0 - Alive State Bit 1 - Ring State Bit 2 - Limphome state Bit 3 - Reserved Bit 4 - Sleep indication State Bit 5 - Sleep acknowledgement State Bit 6 - Reserved Bit 7 - Reserved Byte-3: Reason for wake up is listed in this byte. Data is interpreted as follows 00 - No entry 01 - Wake Up due to Power ON/IGN ON 02 - Wake Up due to CAN messages 03 - Wake Up due to external events like door warning 04 - Wake Up due to internal events like NMWakeUp Bytes 4-8 - Reserved ?

AutoSar網(wǎng)絡(luò)幀PDU只包括自己地址，少量控制信息，用戶選擇數(shù)據(jù)。內(nèi)容簡單的多。

?

Bit 0: Repeat Message Request Bit

0: 代表存在Repeat Message Request ； 1：代表不存在Repeat Message Request ； ?

Bit 1：PN ShutDown Request Bit（PNSR）

0：NM報(bào)文中不包含同步局部網(wǎng)絡(luò)管理休眠請求； 1：NM報(bào)文中包含同步局部網(wǎng)絡(luò)管理休眠請求； ?

Bit 3：NM Coordinator Sleep Bit

0：未被主協(xié)調(diào)NM節(jié)點(diǎn)請求開始同步休眠； 1：已被主協(xié)調(diào)NM節(jié)點(diǎn)請求開始同步休眠； ?

Bit 4：Active Wakeup Bit

0：節(jié)點(diǎn)沒有喚醒過網(wǎng)絡(luò)，屬于被動喚醒； 1：節(jié)點(diǎn)喚醒過網(wǎng)絡(luò)，屬于主動喚醒； ?

Bit 5: PN Learning Bit(PNL)

0: PNC learning被請求 1: PNC learining未被請求 ?

Bit 6 PN Information Bit(PNI)

0: NM報(bào)文中包含PN 信息； 1:NM報(bào)文中未包含PN 信息； 常使用到的也就Bit0，Bit3，Bit4, Bit6這4位。 ? ?

小結(jié)

OSEK同步休眠時刻是所有節(jié)點(diǎn)都發(fā)送Ring請求休眠幀，且收到其它節(jié)點(diǎn)的Ring確認(rèn)休眠幀。而AutoSar的同步休眠時刻是所有節(jié)點(diǎn)都停發(fā)NM幀，且不能收到其它節(jié)點(diǎn)的NM幀。比較而言，AutoSar要簡單一些。

OSEK令牌環(huán)中有一個節(jié)點(diǎn)異常，其它節(jié)點(diǎn)就要重新建立環(huán)才能維持正常網(wǎng)絡(luò)狀態(tài)，策略比較復(fù)雜。而AutoSar網(wǎng)絡(luò)管理中，一個節(jié)點(diǎn)異常時不影響其它節(jié)點(diǎn)的網(wǎng)絡(luò)狀態(tài)。比較而言，AutoSar要簡單一些。

? ?



審核編輯：劉清