AUTOSAR與OSEK的關系 ?

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

AUTOSAR ?

AUTOSAR（Automotive Open System Architecture，即汽車開放系統(tǒng)架構(gòu)）的出現(xiàn)是為了解決汽車電子架構(gòu)日益增加的ECU單元帶來的復雜系統(tǒng)設計問題，讓汽車電子系統(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標準或者AUTOSAR架構(gòu)，我們經(jīng)常提到的AUTOSAR一般就是指AUTOSAR構(gòu)架/標準，AUTOSAR的全稱是AUTomotive Open System ARchitecture，隨著多年的發(fā)展，越來越多的行業(yè)內(nèi)的公司加入到了AUTOSAR聯(lián)盟中，這其中有OEM（汽車整車廠），Tier1（汽車零部件供應商），芯片制造商以及工具制造商，AUTOSAR構(gòu)架/標準也成為了汽車E/E設計的發(fā)展方向。 ?

AUTOSAR架構(gòu)和標準的目標是：

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

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

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

控制產(chǎn)品和流程的復雜度和風險

優(yōu)化成本

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

模塊化和可配置性

標準化接口

提出了RTE的概念

標準的測試規(guī)范

AUTOSAR標準有四個核心內(nèi)容：

ECU軟件構(gòu)架

軟件組件（software components）

虛擬功能總線（Virtual Functional Bus）

AUTOSAR設計方法（Methodology）

OSEK ?

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

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

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

? ?

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

其特點主要有以下幾個方面：

實時性

可移植性

可擴展性

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

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

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

OSEK建立邏輯環(huán)

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

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

? ?

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

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

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

? ? ?

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

? ?

2. AutoSAR - CanNm Algorithm ?

?

NM狀態(tài)機 ?

狀態(tài)機的狀態(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

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

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

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

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

Network Mode

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

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

1、Repeat Message State（RMS） ?

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

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

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

NM Immediate Transmit State ?

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

NM Normal Transmit State ?

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

2、Normal Operation State（NOS） ?

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

3、Ready Sleep State（RSS） ?

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

Prepare Bus-Sleep Mode

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

Passive Mode

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

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

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

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

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

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

? ?

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

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

?

3. 共同點：

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

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

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

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

4. 不同點：

4.1 喚醒幀類型不一樣：

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

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

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

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

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

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

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

同步休眠過程：

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

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

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

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

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

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

?

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

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

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

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

?

OSEK網(wǎng)絡幀PDU包括自己地址，目標地址（下一個令牌環(huán)目標），命令狀態(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)絡幀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報文中不包含同步局部網(wǎng)絡管理休眠請求； 1：NM報文中包含同步局部網(wǎng)絡管理休眠請求； ?

Bit 3：NM Coordinator Sleep Bit

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

Bit 4：Active Wakeup Bit

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

Bit 5: PN Learning Bit(PNL)

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

Bit 6 PN Information Bit(PNI)

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

小結(jié)

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

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

? ?



審核編輯：劉清