AUTOSAR與OSEK的關系 ?
AUTOSAR與OSEK二者都是汽車電子軟件的標準。OSEK/VDX是基于ECU開發的操作系統標準,AUTOSAR基于整體汽車電子開發的功能標準。AUTOSAR中規定的操作系統標準就是基于OSEK/VDX,通信和網絡管理雖然和OSEK有區別,但是是有繼承性的。可以認為,AUTOSAR是基于OSEK/VDX發展出來的,OSEK/VDX被AUTOSAR標準軟件架構所包含。 ? ?
AUTOSAR ?
AUTOSAR(Automotive Open System Architecture,即汽車開放系統架構)的出現是為了解決汽車電子架構日益增加的ECU單元帶來的復雜系統設計問題,讓汽車電子系統開發更靈活,更有效率。 ?
2003年汽車行業內的幾大巨頭(BMW, Bosch, Continental, DaimlerChrysler, Volkswagen, Siemens VDO)聯合建立了AUTOSAR聯盟,一起開發并建立一套真正的開放的汽車電子電器架構,也就是我們現在所說的AUTOSAR標準或者AUTOSAR架構,我們經常提到的AUTOSAR一般就是指AUTOSAR構架/標準,AUTOSAR的全稱是AUTomotive Open System ARchitecture,隨著多年的發展,越來越多的行業內的公司加入到了AUTOSAR聯盟中,這其中有OEM(汽車整車廠),Tier1(汽車零部件供應商),芯片制造商以及工具制造商,AUTOSAR構架/標準也成為了汽車E/E設計的發展方向。 ?
AUTOSAR架構和標準的目標是:
滿足未來汽車的需求,如可用性和安全性、軟件升級更新、可維護性等
增加軟件的靈活性和可擴展性來實現軟件的集成和整合
控制產品和流程的復雜度和風險
優化成本
AUTOSAR架構的主要特點是:
模塊化和可配置性
標準化接口
提出了RTE的概念
標準的測試規范
AUTOSAR標準有四個核心內容:
ECU軟件構架
軟件組件(software components)
虛擬功能總線(Virtual Functional Bus)
AUTOSAR設計方法(Methodology)
OSEK ?
為了解決汽車控制技術通信和網絡發展多元化帶來的軟件移植和不同應用程序的接口協調問題,德國汽車工業界在1993年推出了OSEK(open systems and the corresponding interfaces for automotive electronics)體系,定義汽車開放式系統及接口。1994年法國標致雷諾將汽車分布式運行系統VDX(vehicle distributed executive)納入OSEK。 ?
在1995年召開的OSEK研討會上,眾多的廠商對OSEK和VDX的認識達成了共識,產生了OSEK/VDX規范(1997年發布)。它主要由四部分組成:操作系統規范(OSEK Operating System,OSEK OS)、通信規范(OSEK Communication , OSEK COM )、網絡管理規范( OSEK Net Management, OSEK NM)和OSEK實現語言(OSEK Implementation Language,OIL)。 ?
此后,各軟件生產廠商都相繼推出了符合OSEK規范的產品。隨著該規范應用的不斷深入,其結構和功能不斷完善和優化,版本也不斷升級和擴展。目前OSEK OS2.2 , OSEK COM2.3 , OSEK NM2.3和OIL2.3已經提交ISO審議,即將成為一個國際標準。
? ?
OSEK規范為實現其制定的初衷并滿足汽車控制領域對系統安全性和節省有限資源的特殊要求,制定了系統而全面的操作系統規范。 ?
其特點主要有以下幾個方面:
實時性
可移植性
可擴展性
由上我們可以看出,AUTOSAR與OSEK二者都是汽車電子軟件的標準。OSEK基于ECU開發,AUTOSAR基于整體汽車電子開發。AUTOSAR中規定的操作系統就是OSEK,而通信和網絡管理雖然和OSEK有區別,但思路一樣的。所以認為,AUTOSAR是基于OSEK提出的(但不僅基于OSEK),OSEK被AUTOSAR標準軟件架構包含。 ? ?
AUTOSAR和OSEK網絡管理比較 ?
1. OSEK - Simplified state transition diagram of the direct NM ?
OSEK建立邏輯環
直接網絡管理(以下簡稱為NM)通過發送和接收兩種類型的消息來建立邏輯環:Alive message和Ring message。其中,Alive message是一個節點要加入邏輯環時要發送的消息,Ring message是網絡正常工作時的環消息,是從一個節點傳遞給下一個節點,依次在邏輯環中傳遞,以表示網絡中的節點正常工作。當某一節點功能不正常時,就會周期性的向網絡中發送LimpHome message。 ?
邏輯環的建立通過一種發送“令牌(Token)”的方式來進行,按標識符由小到大的順序進行傳遞,最初發送Alive message的節點(或者標識符優先級高的節點)成為邏輯環中的第一個發送節點,消息都是以廣播的方式發送的,這就使得每個節點發送的消息,其他節點都可以監測到,以確定自己是否為上一個發送節點的后繼節點,并更新節點的運行狀態等。
? ?
所有參與建環的ECU在建環初期,發出報文數據的第一字節都是自己的ID ,第二字節都是 0xC9 ,即協議里講的發出指向自身的 Alive 報文,每個 ECU 都發完 Alive 報文之后,就建立起來邏輯環了,上圖的后面幾幀報文, ECU25 指向了 ECU17 , ECU17指向了ECU1D, ECU1D指向了ECU21, ECU21指向ECU22 , ECU22指向ECU25 ,ECU25 指向 ECU17 ,形成一個封閉的邏輯環,且第二字節都是 Ring 置 1 的 Ring 報文。??
正常建環的情況下,上一條NM報文的ID就是下一條NM報文的第一字節的數據,比如劃線的3條報文,第一條報文的ID為0x19,數據的第一字節為0xE8,第二條報文的ID為0xE8,數據的第一字節為0xEE,第三條報文的ID為0xEE,數據的第一字節為0x19,所有正常建環的報文的第二字節,其Bit2置1,表示發出了正常建環的Ring報文,這就是所謂的邏輯環。
ECU 進入 LimpHome 狀態時的情況,下圖所示,在網絡上只有一個 NM 節點的情況下, ECU上電后,先嘗試建立邏輯環,嘗試 5 次后,依舊無法建立邏輯環,則 ECU 進入 LimpHome 狀態, ECU 按 TError (一般是 1000ms )的周期發送 LimpHome 位置 1 的報文,下圖可以看出, LimpHome 報文的第一字節指向自己,第二字節為 0x04 。
?
? ? ?
OSKE網絡管理的休眠過程,當我們下到 OFF 檔時,控制器滿足了休眠條件,就會發出睡眠指示位 (Sleep.Ind) 置 1 的 Ring 報文,如圖中的第二字節數據為 0x12 的報文,當所有節點都滿足休眠條件,發出 0x12 的報文后,最后一個休眠節點的下一個節點,就會發出睡眠應答位 (Sleep.Ack) 置 1 的 Ring 報文,如圖中的第二字節數據為 0x32 的報文,同一網段的控制器收到這個報文后,就會進入睡眠狀態,這個時候,會停止發送任何報文到總線,等待 ECU 的內部任務完成后,就會進入低功耗模式,靜態電流會變得很小。
? ?
2. AutoSAR - CanNm Algorithm ? ?
NM狀態機 ?
狀態機的狀態類型可分為“三大三小”。其中“三大”指的是Bus Sleep Mode、Network Mode、Prepare Bus-Sleep Mode;而“三小”則值得是Network Mode下的三個子狀態:Repeat Message State、Normal Operation Mode、Ready Sleep Mode。 ?
Bus Sleep Mode
當沒有遠程喚醒或者本地喚醒請求時,ECU的Controller應當切換至Sleep模式,電流消耗將降低至最低水平,該Mode是ECU啟動時的起始狀態或者是ECU睡眠時的最終狀態。 ? 在該模式下,NM報文以及應用報文都應該被禁止發送,但是可以被網絡上的報文喚醒。 ?
在此特意說明一點,當Transiver支持并使能了特定幀喚醒時,該ECU只會接受到特定的NM報文才會正常喚醒,否則就會一直處于休眠狀態,能夠不受網絡上應用報文的干擾。 ?
如果Transiver不支持特定幀喚醒,那么網絡的任意報文都可以喚醒該ECU,如果喚醒條件不滿足,又會走休眠流程繼續睡下去,這樣“睡醒交替”的方式就是不支持特定幀喚醒的Transiver的典型特征。
當然,如果整車上的NM都可以正常運作,那么就不會頻繁出現這種“睡醒交替”的方式,這種方式一般都是在做測試時才會較多的體現出來。 ?
Network Mode
一旦進入Network Mode,計時器T_NM_Timeout就會啟動,只要成功接收到來自總線上的NM報文或者成功發送至總線NM報文,都會將該計時器T_NM_Timeout重置。 ?
該模式又進一步細分為以下三種子狀態,RMS、NOS、RSS。 ?
1、Repeat Message State(RMS) ?
該狀態能夠確保當ECU的狀態機從Bus-Sleep Mode或者Prepare Bus-Sleep mode切換至Network Mode時能夠及時的被網絡上其他ECU節點發現,也就是告訴其他ECU,“大家注意了,我成功上線了,請多多指教!” ? 當成功進入到RMS狀態時,該節點就會重新發送NM報文并開啟計時器T_REPEAT_MESSAGE,應用報文則需要等待第一幀網絡管理報文發送之后再發送。 ?
當然,第一幀NM報文可以通過配置參數MSG_CYCLE_ OFFSET來延遲發送,降低在同一時間內的總線負載,這個配置參數默認是0 ,一般根據測試結果來做適當的調整。 ? 在計時器T_REPEAT_MESSAGE超時之前,該節點就會一直保持在該狀態,否則將會離開該狀態。 ?
在該狀態下也存在著兩個子狀態: ?
NM Immediate Transmit State ?
在該模式下,ECU的目的是快速喚醒整個網絡,同時該節點將會以配置參數T_NM_ImmediateCycleTime的周期發送NM報文,而發送次數則是由配置參數N_ImmediateNM_TIMES來決定,每一次成功發送,該參數就會減1,直至為0,退出該子狀態; ?
NM Normal Transmit State ?
在該模式下,ECU節點將會以正常報文周期T_NM_MessageCycle的方式來發送NM報文。 ?
2、Normal Operation State(NOS) ?
只要ECU節點自身存在網絡通信的需要,那么ECU就會一直工作在NOS的狀態下。該狀態下NM報文的發送將會以T_NM_MessageCycle的周期來發送報文,每次報文的成功發送或接收或者計時器NM-Timeout超時都會重置該計時器NM-Timeout; 在該狀態下的NM報文以及應用報文都應該正常收發通信。 ?
3、Ready Sleep State(RSS) ?
在該模式下,ECU節點應當停止發送NM報文。每次成功接受到來自網絡上的NM報文,計時器T_NM_TIMEROUT 就會重置,一旦T_NM_TIMEROUT超時,那么就會離開該狀態轉而進入Prepare Bus-Sleep狀態。 ?
Prepare Bus-Sleep Mode
一旦進入該模式,計時器T_WAIT_BUS_SLEEP就會啟動。在該模式下禁止網絡管理報文的發送,允許接受NM報文。應用報文已經在buffer中的一般允許繼續發送,但最終應該是silent bus,該ECU的Controller的狀態應當處于operational mode。一旦T_WAIT_BUS_SLEEP超時,就會進入到Bus-Sleep階段。 ?
Passive Mode
?在該模式下只接受NM報文,但不發送任何的NM報文。該模式可以通過配置得到,同時該模式應只存在于開發或者調試過程中,在正式SOP的軟件中禁止出現此種模式。 ?
報文發送與接受狀態 ?
在測試的過程中,需要針對網絡管理每一個狀態下的NM報文與APP報文接收與發送進行測試。如下圖所示,體現了在不同NM子狀態下的報文發送與接受狀態。 ?
Bus-Sleep階段,只接收NM報文喚醒,不發送任何報文;
Pre-Bus-Sleep階段,同樣僅允許接收NM報文,對于早已在發送Buffer中的APP報文應發送完畢后立刻停止APP報文;
Network Mode模式,除了在Ready Sleep階段不允許發送NM報文之外,其余階段APP報文與NM報文正常收發;
? ?
狀態機時間參數 ?
在網絡管理各子狀態的切換過程中都依賴于各種計時器,相關參數總結如下。
?
3. 共同點:
都屬于直接網絡管理。
網絡管理的目的都是協調各節點同步進入休眠及喚醒(主要是休眠)。
都依靠特定的網絡管理CAN報文,每個節點的網絡管理ID都不一樣。
喚醒方法相同,第一個喚醒的節點發送網絡管理幀即同時喚醒其它節點。
4. 不同點:
4.1 喚醒幀類型不一樣:
網絡喚醒后,OSEK要求節點發出的第一幀必須是Alive類型,不能是Ring, Limphome等。
AutoSar只要求是網絡管理幀就行,條件寬松。
4.2 休眠的同步算法不一樣:
OSEK網絡管理使用令牌環機制,令牌從網絡地址低的節點傳到網絡地址高的節點,如果沒有更高的節點,就傳給最低地址節點。令牌環根據ECU的網絡地址建立。每個ECU都會接受網絡管理消息,只有和目的地址相同的一個節點才會得到令牌。
喚醒后建立邏輯環過程:
控制器喚醒后想參與網絡的節點會先發Alive報文申請加入邏輯環。
邏輯環建成后,各節點按順序發Ring報文向后續節點傳遞“令牌”。
同步休眠過程:
如果邏輯環中有節點想休眠,就設置Ring報文中的Sleep.Ind指示位。
當邏輯環中所有的節點都設置了Sleep.Ind指示位,也意味著任何節點接收到所有其它節點的Sleep.Ind指示位。
邏輯環中所有的節點設置Sleep.Ack指示位
任何節點接收到所有其它的節點的Sleep.Ack指示位
所有節點同步進入等待睡眠狀態
tWaitBusSleep時間內沒有收到喚醒時間,所有節點同步進入睡眠狀態。
?
AutoSar基于分布式策略,每個節點根據通信系統中發送或者接收到的NM消息來執行自給自足的網絡活動。NM消息通過廣播發送,所有網絡中的所有節點都可以接收到。接收到NM消息表示發送這個NM消息的節點傾向保持網絡工作模式(NETWORK MODE)。如果有節點準備好進入總線睡眠模式 (BUS SLEEP MODE),它就停止發送NM消息,但是只要它還能夠接收到從其他節點發來的NM消息,它就延遲到總線睡眠模式的變遷。最終,在一定的時限內,由于不再接收到NM消息,每個節點都啟動到總線睡眠模式的變遷。如果網絡中的任何節點需要總線通信,它可以通過發送NM消息使網絡從來總線睡眠模式中喚醒。概括如下:
每個網絡節點如果想保持總線通信,就會一直發送周期性的NM消息;如果它不再需要保持總線通信,它就不再發送NM消息。
如果總線通信已經被釋放,并且在配置的一段時間內沒有發送或者接收到NM消息,則執行到Bus-Sleep模式的轉移。
4.3 PDU結構不一樣:
?
OSEK網絡幀PDU包括自己地址,目標地址(下一個令牌環目標),命令狀態,用戶選擇數據。
?
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網絡幀PDU只包括自己地址,少量控制信息,用戶選擇數據。內容簡單的多。
?
Bit 0: Repeat Message Request Bit
0: 代表存在Repeat Message Request ; 1:代表不存在Repeat Message Request ; ?
Bit 1:PN ShutDown Request Bit(PNSR)
0:NM報文中不包含同步局部網絡管理休眠請求; 1:NM報文中包含同步局部網絡管理休眠請求; ?
Bit 3:NM Coordinator Sleep Bit
0:未被主協調NM節點請求開始同步休眠; 1:已被主協調NM節點請求開始同步休眠; ?
Bit 4:Active Wakeup Bit
0:節點沒有喚醒過網絡,屬于被動喚醒; 1:節點喚醒過網絡,屬于主動喚醒; ?
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位。 ? ?
小結
OSEK同步休眠時刻是所有節點都發送Ring請求休眠幀,且收到其它節點的Ring確認休眠幀。而AutoSar的同步休眠時刻是所有節點都停發NM幀,且不能收到其它節點的NM幀。比較而言,AutoSar要簡單一些。
OSEK令牌環中有一個節點異常,其它節點就要重新建立環才能維持正常網絡狀態,策略比較復雜。而AutoSar網絡管理中,一個節點異常時不影響其它節點的網絡狀態。比較而言,AutoSar要簡單一些。
? ?
審核編輯:劉清
評論