?

　　隨著汽車工業的飛速發展，電子技術在汽車上的應用比重不斷增加。為了滿足日益復雜的汽車電子控制軟件的開發需要，實現應用軟件的可移植性和不同廠商的控制模塊間的可兼容性，1993年德國汽車工業界聯合推出了“汽車電子的開放式系統及接口軟件規范”，即OSEK(open system and the corresponding interfaces for automotive electronics)。1994年法國汽車工業界的相似規范VDX(vehicle distributed executive)和OSEK規范合并，從而形成OSEK/VDX規范體系。

　　此規范主要由4部分組成：操作系統規范(OSEKOS)、通信規范(OSEKCOM)、網絡管理規范(OSEKNM)和OSEK實現語言(OSEKOIL)。其中OSEKOS是針對汽車應用特點而專門制定的一個小型RTOS規范，著重以下幾個方面：

　　①可移植性，所有API都是標準化的并且在功能上都有明確的定義;

　　②可擴展性，OSEKOS旨在通用于任何類型的 ECU，因此一方面系統要高度的模塊化，另一方面又要能進行靈活的配置;

　　③汽車應用的特定需求，諸如可靠性、實用性和代價敏感性等。相應的，OSEKOS 靜態配置可以通過OS2EKOIL語言實現，用戶在系統生成時靜態制定任務的個數、需要的資源和系統服務。OSEKCOM為通信網絡中的數據交換提供了標準的接口和協議。OSEKNM為監視網絡的流量提供了一組標準的功能函數，以保證網絡的安全性和可靠性。

　　μC/OS-Ⅱ是一個著名的源代碼公開的實時內核，專門為嵌入式應用設計的。它的主要性能特點如下：

　　①源代碼公開。這樣很容易就能把操作系統移植到各個不同的硬件平臺上;

　　②可移植性。μC/OS-Ⅱ絕大部分源代碼是用C語言寫的，而與微處理器硬件相關的那部分是用匯編語言寫的，使得μC/OS-Ⅱ便于移植到其他的微處理器上;

　　③可固化。只要開發者有固化手段，μC/OS-Ⅱ可以嵌入到開發者的系統中;

　　④可裁剪性(Scalable)。開發者可以有選擇的使用μC/OS-Ⅱ中應用程序需要的那些系統服務，可以減少μC/OS-Ⅱ所需的存儲空間;

　　⑤占先(Preemp2tive)。μC/OS-Ⅱ完全是占先式的實時內核;

　　⑥多任務(Multi-Tasking)。μC/OS-Ⅱ可以管理64個任務，但是目前應用程序最多有56個任務;

　　⑦可確定性 (Affirmable)。μC/OS-Ⅱ系統服務的執行時間不依賴于應用程序任務的多少;

　　⑧實用性和可靠性。許多的行業都有成功應用該實時內核的實例，這些應用的實踐是該內核實用性和可靠性的最好證據。

　　OSEKOS結構特點及運行機制

　　OSEKOS的結構特點

　　(1)高實時性。由于在汽車控制領域，如果出現絲毫的差錯會導致危及生命安全的嚴重后果，因此要求具有高度的實時性。OSEKOS所有的系統對象由用戶在建立時靜態創建，避免了動態創建時的時間消耗，增強了其實時性。而且通過占先式的調度策略和警報機制也能滿足實時性需求;

　　(2)標準化應用接口。其制定了標準的應用程序編程接口，這樣可以屏蔽底層硬件結構的不同而提供一個一致的開發環境。并且用戶只需修改OIL配置文件中與硬件相關的部分，可以方便地在不同的ECU上進行移植;

　　(3)可裁剪性。其具有高度模塊化和可靈活配置的特性，用OIL語言進行裁剪，可以在很少的硬件資源環境下運行。

　　OSEKOS運行機制分析

　　任務管理

　　OSEK規范將任務分為基本任務和擴展任務。基本任務具有3種狀態：運行狀態、就緒狀態和掛起狀態。擴展任務多了一個等待狀態。此外基本任務只在開始和結束時才有同步點，所以其需要的資源少，而擴展任務可以對應不同的時間，在運行中可能有多個同步點，所以對環境要求高。操作系統的任務之間的同步通過調度程序來實現。

　　OSEK規范支持3種調度方式：

　　①完全搶占式調度。該策略用于保存現場的內存開銷較大，理論上可以在任務的任何位置重調度，因此任務必須同步訪問共享資源，增加了系統的復雜性;

　　②非搶占調度。此策略通過調用某些服務例程實現任務切換，即用戶設置重調度點。通過定義任務組，可以使多個任務同時具有搶占或非搶占調度的特征;

　　③混合搶占調度。搶占任務和非搶占任務共存于一個系統時，使用“混合搶占”調度策略。在這種情況下，調度策略依賴于正在運行任務的搶占特性，開發者通過配置任務優先級和搶占屬性來定義任務執行順序。

　　一致類

　　為了更加靈活的配置操作系統調度，OSEK規范定義了4種一致類：BCC1、BCC2、ECC1和ECC2。其根據每個優先級可能有的任務個數，需要的是基本任務還是擴展任務來進行劃分。若每個優先級上只有一個任務，且是基本任務則定義一致類為BCC1，是擴展任務則定義為BCC2;若每個優先級上可以有多個任務，且是基本任務則定義一致類為ECC1，是擴展任務則定義為ECC2。

　　中斷處理

　　OSEK規范定義了2種中斷服務程序：①ISR1。此類中斷程序不使用操作系統的資源，中斷結束后，處理程序從產生中斷的地方繼續執行。其對任務的管理沒有影響，不要求調用操作系統的API。②ISR2。此類中斷程序是系統生成時，通過用戶子程序配置而成，它可以調用操作系統的API。中斷的優先級高于任務，因此可以搶占任何任務。

　　事件機制

　　事件機制用于保證不同擴展任務之間的同步。該機制含義是，一個處于等待狀態的擴展進程，只有當它所等待的事件至少有一個發生，才能進入就緒態，并且事件的發生會以信號的方式傳給該進程。只有擴展任務，才具有事件。

　　資源管理

　　具有不同優先級的多任務訪問共享資源需要使用資源管理機制進行協調。這些資源可以是一段臨界區代碼、調度程序、共享內存或是數據結構，也可以是共享硬件設備。系統在處理多個進程對共享資源的互斥訪問時，采用信號量對臨界區數據或資源加鎖，但是這樣可能會導致優先級反轉。為了避免這種情況出現，OSEK采用了優先級最高限度協議(PCP)，即當一個進程占用了一個資源后，該進程的優先級會臨時升高為該資源優先級。當該任務釋放了資源后，其優先級回到要求訪問資源前的優先級。使用該協議同時也解決了死鎖的問題。

　　報警器

　　報警器是OSEK為處理循環事件提供的服務機制，警報或者基于系統時鐘，或者基于其他的某種計數器。當計數器到達警報設置值時被觸發，此時可以激活進程也可以為某進程設置事件，或者執行一個警報回調程序。

　　消息處理

　　任務之間是通過消息實現通信的，消息是應用數據的容器，只有一個發送者，但是可以有多個接受者。OSEK規范將消息分為可排隊和不可排隊的。前者是靜態長度消息，內部數據被組織成FIFO隊列，能被接受服務例程移走;不可排隊消息是不斷被刷新的消息，不能被服務例程移走。

　　錯誤處理

　　OSEKOS提供了系統專用的鉤子程序，以便在操作系統內部操作時執行用戶定義的函數。鉤子程序可用于：系統啟動，相應鉤子程序在操作系統啟動后，進入調度程序之前執行;系統關閉，相應鉤子程序在應用或操作系統(此時發生嚴重錯誤)請求系統停止運行時執行;跟蹤、調試應用以及現場切換時調用用戶定義的擴展程序;錯誤處理。

　　基于μC/OS-Ⅱ的OSEKOS設計

　　OSEKOS設計理念

　　根據OSEK規范和μC/OS-Ⅱ的內核要求，CC1和ECC1這2個符合級別都只允許一個優先級有一個進程，因此可以將優先級從0到N-1分配給N個進程，使每個進程分配到的優先級不同，N是系統中的進程數量，這樣可以使修改后的μC/OS-Ⅱ內核滿足ECC1類模式。由于BCC2和ECC2這2個符合級別可以允許每個優先級有多個進程，因此要使用復雜的調度策略來追蹤各個進程。

　　設計的OSEKOS可以采用μC/OS-Ⅱ的調度結構——就緒表，使用簡單的占先式的調度策略，將每個進程的就緒態標志都放入就緒表中，然后從其中找到優先級最高的就緒態進程執行，實現一個基于優先級的可剝奪型的實時內核。這樣不僅可以提高系統的實時性，而且可以降低操作系統的CPU負荷。對于BCC2和 ECC2這2個符合級別而言，可以在基于優先級的占先式調度策略基礎上添加時間片輪換調度算法來處理優先級相同的2個任務之間的調度;也可以為每個優先級增加一個FIFO隊列，先以任務優先級為檢索，然后選擇該進程隊列中位于對首的進程運行。但是這樣會犧牲一定的實時性，并且加大CPU的負荷，占用更多的 RAM。

　　為了提高OSEKOS的可移植性和利于OSEKOS的配置，按照μC/OS-Ⅱ的內核結構將其分為3部分：硬件無關部分、硬件相關部分和應用相關部分。這樣可以使其在不同的硬件之間移植時更加的方便，將與應用相關部分放入配置文件內，便于用戶使用。

　　μC/OS-Ⅱ在處理多個進程對共享資源的互斥訪問時，主要是采用開關中斷與信號量來對臨界區數據或資源加鎖，使用互斥型信號量管理來避免優先級反轉，通過允許用戶在申請信號量時定義等待超時化解死鎖問題。OSEKOS是通過采用優先級最高限度協議(PCP)來避免優先級反轉和死鎖問題。可以通過在系統生成期間，靜態分配每一資源的最高限度優先級，使設計的OS2EKOS執行PCP協議，達到兼容OSEK規范的目的。

　　根據OSEK規定的2類中斷，針對具體的處理器平臺，實現中斷管理的標準API，并且根據μC/OS-Ⅱ提供非OSEK標準的API：開/關中斷。由于是基于ECC1類模式來實現OSEKOS，所以支持OSEK規范定義的事件機制，可用于實現任務之間的同步協調。根據μC/OS-Ⅱ，可以支持的事件種類有信號量、互斥型信號量、郵箱和消息隊列。由μC/OS-Ⅱ提供的時間管理和定時中斷功能，實現OSEKOS中要求的警報器管理，以進一步提高操作系統的實時性和安全性。在μC/OS-Ⅱ中，定義了一系列與OSEKOS規范要求類似的鉤子程序，用于實現用戶自己定義的函數。

　　OSEKOS基本結構的組成

　　由于OSEKOS中的標準應用程序接口(API)定義在操作系統的核心空間，根據以上設計理念可以將操作系統按功能分為進程管理和調度、資源管理、警報與計數器管理、事件管理和中斷管理，其結構組成如圖1所示。其中進程管理與調度是整個操作系統的核心，其他的管理機制為它提供不同的服務支持。

?

　　圖1　OSEKOS結構組成圖

　　每個進程都通過一個進程控制塊(TCB)來管理，在進程管理模塊中，實現OSEK標準API：激活進程、終止進程、連接進程、調度、捕獲當前運行進程ID 和獲得進程狀態。資源管理模塊實現OSEK標準API：獲得資源、釋放資源。計數器管理沒有標準API，警報管理結構由警報和警報行為組成。其標準 API：獲得警報信息、獲得警報到期所需時間、設置相對警報、設置絕對警報和消除警報。事件管理模塊實現的OSEK標準API：等待事件、設置事件、消除事件和獲得進程的時間狀態。實現中斷管理的標準API：開/關所有中斷和開/關第二類中斷。

　　結束語

　　根據OSEKOS規范和μC/OS-Ⅱ內核實現的不同技術特點，提出OSEKOS的一些設計思想，并且設計出OSEKOS的基本結構組成。 OSEK/VDX體系的建立給國際汽車工業帶來深遠的影響，采用基于OSEK/VDX規范的RTOS進行開發能節省開發時間，降低成本，提高軟件質量和模塊的可移植性，而且需要的資源少。因此，研究基于OSEK/VDX規范的操作系統具有重要的意義。