一 實時作業系統概述

1  作業系統概述

在計算機技術發展的初期階段，計算機系統中沒有作業系統(Operating System)這個概念。應用程式開發人員都要對處理器和硬體進行徹頭徹尾的控制。實際上，第一個作業系統的誕生，就是為了提供一個虛擬的硬體平臺，以方便程式設計師開發，同時提高計算機的資源利用率。為實現這個目標，作業系統只需提供一些較為鬆散的函式、例程――就好象現在的軟體庫一樣――以便於對硬體裝置進行重置、讀取狀態、寫入指令之類的操作。

這是作業系統的雛形：計算機監控程式(Monitor)，使使用者能通過監控程式來使用計算機。

隨著計算機技術的發展，計算機系統的硬體、軟體資源也愈來愈豐富，監控程式已不能適應計算機應用的要求。於是在六十年代中期，監控程式又進一步發展，形成了作業系統(Operating System)。 發展到現在，廣泛使用的有三種作業系統即多道批處理作業系統、分時作業系統以及實時作業系統。

多道批量處理系統一般用於計算中心較大的計算機系統中。由於它的硬體裝置比較全，價格較高，所以此類系統十分注意CPU及其它裝置的充分利用，追求高的吞吐量，不具備實時性。

分時系統的主要目的是讓多個計算機使用者能共享系統的資源，能及時地響應和服務於聯機使用者，只具有很弱的實時功能，但與真正的實時作業系統仍然有明顯的區別。具體的說，對於分時作業系統，軟體的執行在時間上的要求，並不嚴格，時間上的錯誤，一般不會造成災難性的後果。而對於實時作業系統，主要任務是對事件進行實時的處理，雖然事件可能在無法預知的時刻到達，但是軟體上必須在事件發生時能夠在嚴格的時限內作出響應（系統響應時間），即使是在尖峰負荷下，也應如此，系統時間響應的超時就意味著致命的失敗。另外，實時作業系統的重要特點是具有系統的可確定性，即系統能對執行情況的最好和最壞等的情況能做出精確的估計。

現代作業系統則在單處理器上引入了多工機制，每個使用者的應用程式可以設計成多個不同的任務，每個任務都是一個軟體模組，可以是互相獨立的，這些任務可以併發執行，提高系統的吞吐量，更有效地利用系統資源。嵌入式軟體經常是可以劃分成小的互相獨立的模組。這些任務的劃分提供了一個很關鍵的軟體抽象概念，這使得嵌入式作業系統的設計和實現更加容易，源程式也更易於理解和維護。通過把大的程式進行模組化劃分，程式設計師可以集中精力克服系統開發過程中的關鍵問題。基於任務的設計的可擴充套件性、可管理性大大提高了系統的可靠性。

2  實時多工作業系統的定義

一個實時系統，根據它所要執行的任務的複雜程度，可以使用不同的執行和管理方法。

對較小的實時系統，只需使用實時監控程式(Monitor)即可簡單而有效地執行和管理。監控程式管理應用程式的執行和對I/O裝置的操作，並具有按優先順序控制的中斷系統。被硬體啟用等各項功能可以由中斷服務程式來完成。

對規模較大的實時系統，需要使用實時多工作業系統來加以管理。較簡單的情況，可以僅使用實時多工核心(Kernel)，又稱為實時多工執行程式(Executive)。對複雜的情況，則必須使用包括了檔案系統在內的完全的實時多工作業系統。

一個作業系統操可以定義為：使得計算機系統的硬體成為可用的、由軟體或韌體(firmware)所實現的一個程式集。作業系統是介於程式設計者與機器硬體之間的一個軟體層。如圖1 所示。

圖 1  作業系統是硬體與程式設計者之間的介面

作業系統是一組計算機程式的集合，用來有效地控制和管理計算機的硬體和軟體資源，即合理地對資源進行排程，併為使用者提供方便的應用介面。它為應用支援軟體提供執行環境，即對程式開發者提供功能強、使用方便的開發環境。

傳統的通用作業系統通常包括以下幾部分：命令解釋程式，核心和I/O裝置驅動程式。它所提供的執行及管理機制為：

• 多工的管理
• 記憶體及資源管理
• 任務間的資訊傳遞
• 檔案系統的管理
• 邏輯I/O裝置的管理

實時作業系統也同樣包括以上各個部分，只是由於實時性的要求，管理方法上要作許多擴充。

實時多工作業系統（Real Time Operating System）是根據作業系統的工作特性而言的。實時是指物理程序的真實時間。實時作業系統是指具有實時性，能支援實時控制系統工作的作業系統。首要任務是排程一切可利用的資源完成實時控制任務，其次才著眼於提高計算機系統的使用效率，重要特點是要滿足對時間的限制和要求。

3  實時作業系統的發展歷史

許多嵌入式系統根本就沒有作業系統，只不過有一個控制環而已。對很簡單的嵌入式系統來說，這可能已經足夠了。不過，隨著嵌入式系統在複雜性上的增長，作業系統顯得重要起來，因為否則的話，將使(控制)軟體複雜度變得極不合理。

實時作業系統（RTOS）的研究是從六十年代開始的。從系統結構上看，RTOS到現在已經歷瞭如下三個階段： 

3.1 早期的實時作業系統 

同硬體一起，軟體也得到了發展。最初，只有一些簡單的開發工具可供用以建立和除錯軟體。各工程專案的執行軟體通常以信手塗鴉的方式編出來。由於編譯器經常有很多錯誤而且也缺乏象樣的偵錯程式，這些軟體差不多總是用匯編語言或巨集語言來寫。採用軟體構建塊和標準庫的程式設計思想直到20世紀70年代中期才流行起來。

早期的實時作業系統，還不能稱為真正的RTOS，它只是小而簡單的、帶有一定專用性的軟體，功能較弱，可以認為是一種實時監控程式。它一般為使用者提供對系統的初始化管理以及簡單的實時時鐘管理，有的實時監控程式也引入了任務排程及簡單的任務間協調等功能，屬於這類實時監控程式的有RTMX等。這個時期，實時應用較簡單，實時性要求也不高。應用程式、實時監控程式和硬體執行平臺往往是緊密聯絡在一起的。

用於嵌入式系統的與"擱架"無關的作業系統在20世紀70年代後期開始出現。它們中的許多是用匯編語言寫就的，並且僅能用於為其編寫的微處理器上。當這些微處理器變得過時的時候，它們使用的作業系統也厄運同臨。只能在新的處理器上從新寫一遍才能執行。今天，許多這種早期的系統只不過成了人們模糊的記憶。當C語言出現後，作業系統可以用一種高效的、穩定的和可移植的方式來編寫。這種方式對使用和經營有直接的吸引力，因為它承載著人們當微處理器廢棄不用時能保護他們的軟體投資的希望。聽起來，有點兒像商業市場營銷中的一段傳奇故事。用C來編寫作業系統已經成了一種標準，直至今天。總之，軟體的可複用性已經為人接受而且正在很好地發揮作用。

3.2專用實時作業系統 

隨著應用的發展，早期的實時作業系統已越來越顯示出明顯的不足了。有些實時系統的開發者為了滿足實時應用的需要，自己研製與特定硬體相匹配的實時作業系統。這類專用實時作業系統在國外稱為Real-Time Operating System Developed in House。它是在早期使用者為滿足自身開發需要而研製的，它一般只能適用於特定的硬體環境，且缺乏嚴格的評測，移植性也不太好。屬於這類實時作業系統的有Intel公司的iRMX等。

在各種專用的實時作業系統中，一些多工的機制如基於優先順序的排程、實時時鐘管理、任務間的通訊、同步互斥機構等基本上是相同的，不同的只是面向各自的硬體環境與應用目標。實際上，相同的多工機制是能夠共享的，因而可以把這部分很好地組織起來，形成一個通用的實時操作相同核心。這類實時作業系統大多采用軟元件結構，以一個個軟體"標準組件"構成通用的實時作業系統，一方面，在RTOS核心的最底層將不同的硬體特性遮蔽掉；另一方面，對不同的應用環境提供了標準的、可剪裁的系統服務軟元件。這使得使用者可根據不同的實時應用要求及硬體環境選擇不同的軟元件，也使得實時作業系統開發商在開發過程中減少了重複性工作。 

3.3通用實時作業系統 

許多用於嵌入式系統的的商業作業系統在20世紀80年代獲得了蓬勃發展。從1981年Ready System釋出的世界上第一個商業嵌入式實時核心(VRTX32)，到今天已有20年的歷史。目前已經有幾打的商業性實時作業系統可供選擇，出現了許多互相競爭的產品，如VxWorks，pSOS，Neculeus和WindowsCE等。

這類通用實時作業系統，有Integrated System公司的Psos+、Intel公司的iRMX386、Ready System公司（1995年與Microtec Research合併）的VRTX32（後推出新一代的實時核心VRTXsa）等。它們一般都提供了實時性較好的核心、多種任務通訊機制、基於TCP/IP的網路元件、檔案管理及I/O服務，提供了集編輯、編譯、除錯、模擬為一體的整合開發環境，支援使用者使用C、C++進行應用程式的開發。如Integrated System公司的Prism+，Windriver公司的Tornado，Ready System公司的Spectra。

作為候選的嵌入式作業系統，Linux有一些吸引人的優勢：它可以移植到多個有不同結構的CPU和硬體平臺上，具有很好的穩定性，以及各種效能的升級能力，而且開發更容易。

4 實時作業系統的分類

從實時系統的應用特點來看，實時作業系統可以分為兩種：一般實時作業系統和嵌入式實時作業系統。

一般實時作業系統與嵌入式實時作業系統都是具有實時性的作業系統，它們的主要區別在於應用場合和開發過程。

一般實時作業系統應用於實時處理系統的上位機和實時查詢系統等實時性較弱的實時系統，並且提供了開發、除錯、運用一致的環境。

嵌入式實時作業系統應用於實時性要求高的實時控制系統，而且應用程式的開發過程是通過交叉開發來完成的，即開發環境與執行環境是不一致的。

5 實時作業系統的特點

RTOS是作業系統研究的一個重要分支，它與一般商用多工作業系統如Unix、Windows、Multifinder等有共同的一面，也有不同的一面。對於商用多工作業系統，其目的是方便使用者管理計算機資源，追求系統資源最大利用率；而RTOS追求的是實時性、可確定性、可靠性。

評價一個實時作業系統一般可以從任務排程、記憶體管理、任務通訊、記憶體開銷、任務切換時間、最大中斷禁止時間等幾個方面來衡量。因此，實時作業系統一般具備以下要求：

5.1 可確定性(deterministic)

作業系統的可確定性是指它可以按照固定的、預先確定的時間或時間間隔執行操作。當多個任務競爭使用資源和處理器時，沒有哪個系統是完全可確定的。在實時作業系統中，任務請求服務是用外部事件和時間安排來描述的。作業系統可以確定性地滿足請求的程度首先取決於它響應中斷地速度，其次取決於系統是否具有足夠的能力在要求的時間內處理所有的請求。

作業系統可確定性能力的一個非常有用的度量是從高優先順序中斷到達到開始服務之間的延遲。在非實時作業系統中，這個延遲可以是幾十到幾百毫秒，而在實時作業系統中，這個延遲的上限可以從幾微秒到1毫秒。

5.2 響應性（responsiveness）

確定性關注的是作業系統獲知有一箇中斷之前的延遲，響應性關注的是在知道中斷之後作業系統為中斷提供服務的時間。

響應性包括以下幾個方面：

A) 最初處理中斷並開始執行中斷服務程式所需要的時間總量。如果ISR的執行需要一次任務切換，需要的延遲將比在當前任務上下文環境中執行ISR的延遲長。

B) 執行ISR所需的時間總和，通常與硬體環境有關。

C) 中斷巢狀的影響。如果一個ISR可以被另一箇中斷的到達而中斷，服務將會延遲。

確定性和響應性共同組成了對外部事件的響應時間。對實時系統來說，響應時間的要求非常重要，因為它必須滿足外部事件的時間要求。

5.3 使用者控制(user control)

使用者控制在實時作業系統中通常比在普通作業系統中更廣泛。在典型的非實時作業系統中，使用者或者對作業系統的排程功能沒有任何控制，或者僅提供了概括性的指導，例如把使用者分成多個優先順序組。但在實時作業系統中，允許使用者細粒度地控制任務的優先順序是必不可少的。使用者應該能夠區分硬任務和軟任務，並且確定其相對優先順序。實時系統還允許使用者指定一些特性，例如哪個任務必須常駐Cache。

5.4 可靠性(reliability)

在實時系統中比非實時系統中更重要。在非實時系統中，暫時性故障可以通過重新啟動系統來解決，多處理器非實時系統中的處理器失敗可能導致服務級別降低，直到發生故障的處理器被修復或替換。但是實時系統是實時地響應和控制事件，效能的損失或降低可能產生災難性的後果，從資金損失到損壞主要裝置甚至危及生命。

5.5．故障弱化執行(fail-soft running)

與其它領域一樣，實時作業系統和非實時作業系統的區別只是一個程度問題，即使實時系統也必須設計成響應各種故障模式。故障弱化執行是指在系統故障時實時系統將試圖改正這個問題或者最小化它的影響並繼續執行。

故障弱化執行的一個重要特徵是穩定性。我們說一個實時系統是穩定的，是指如果當它不可能滿足所有任務的最後期限時，即使總是不能滿足一些不太重要的任務的最後期限，系統也將首先滿足最重要的、優先順序最高的任務的最後期限。

為滿足前面的要求，當前的實時作業系統典型地包括以下特徵：

• 快速的任務切換

當由於某種原因使一個任務退出執行時，RTOS儲存它的執行現場資訊、插入相應佇列、並依據一定的排程演算法重新選擇一個任務使之投入執行，這一過程所需時間稱為任務切換時間。任務切換時間一般在毫秒或微秒數量級上。

• 體積小（只具備最小限度的功能）

實時作業系統的設計過程中，最小記憶體開銷是一個較重要的指標，這是因為在工業控制領域中的某些工控機，由於基於降低成本的考慮，其記憶體的配置一般都不大，例如康拓5000系列5185板，其基本記憶體配置僅為256K SRAM＋128K EPROM，而在這有限的空間內不僅要裝載實時作業系統，還要裝載使用者程式。因此，在RTOS的設計中，其佔用記憶體大小是一個很重要的指標，這是實時作業系統設計與其它作業系統設計的明顯區別之一。

一般實時核心只有幾十K位元組大小，並可固化使用。

• 通過諸如訊號量、事件之類的任務間通訊手段，實現多工處理

下面我們將詳細介紹多工有關的一些概念。

1．使用特殊的順序檔案，可以快速儲存資料

提供存取盤上資料的優化方法，使得存取資料時查詢時間最少。通常要求把資料儲存在順序檔案上。

2．基於優先順序的搶佔排程

實時作業系統的實時性和多工能力在很大程度上取決於它的任務排程機制。為保證響應時間，實時作業系統必須允許高優先順序任務一旦準備好執行，馬上搶佔低優先順序任務的執行。

3．最小化禁止中斷的時間間隔

當RTOS執行在核態或執行某些系統呼叫的時候，是不會因為外部中斷的到來而中斷執行的。只有當RTOS重新回到使用者態時才響應外部中斷請求，這一過程所需的最大時間就是最大中斷禁止時間。

4．硬體抽象化

硬體抽象化的目的是透過作業系統本身的設計將硬體因素降到最低，軟體本身牽涉到的硬體因素越少，則其跨平臺的可能性越高，而硬體抽象化的最直接作法即是將作業系統本身與硬體有關的部分集中成一個模組，利用此模組將作業系統及應用程式與硬體介面相隔絕。

5．用於使任務延遲一段固定的時間或暫停/恢復任務的原語

6．特別的告警和超時設定

總的來說，實時作業系統是事件驅動的(event driven)，能對來自外界的作用和訊號在限定的時間範圍內作出響應。它強調的是實時性、可靠性和靈活性， 與實時應用軟體相結合成為有機的整體，起著核心作用，由它來管理和協調各項工作，為應用軟體提供良好的執行軟體環境及開發環境。

進入20世紀90年代後，RTOS在嵌入式系統設計中的主導地位已經確定，越來越多的工程師使用RTOS，更多的新使用者願意選擇購買而不是自己開發。當前，RTOS的技術發展有以下一些變化：

• 因為新處理器越來越多，RTOS自身結構的設計更易於移植，以便在短時間內支援更多種微處理器。
• 開發原始碼之風已波及RTOS廠家。數量相當多的RTOS廠家出售RTOS時，就附加了原始碼並含生產版權。
• 後PC時代更多的產品使用RTOS，它們對實時性要求並不高，如手持裝置等。微軟的WinCE，Plam OS，Java OS等RTOS產品就是順應應用而開發出來的。
• 電信裝置、控制系統要求的高可靠性對RTOS提出了新的要求。瑞典Enea公司的OSE和WindRiver新推出的VxWorks AE對支援高可用性和熱切換等特點都下了一番功夫。
• 嵌入式Linux已經在消費電子裝置中得到廣泛應用。

6 實時作業系統的標準－POSIX

對於嵌入式系統最煩人的事情之一就是它們缺乏一個公共的應用程式介面(API)，這對於希望在基於不同作業系統的產品之間共享應用程式程式碼的公司來說，這是一個特別問題。

其實，每一個嵌入式作業系統的基本功能大致一樣。每一個函式或者方法代表了作業系統可以嚮應用程式提供的一種服務。但是沒有那麼多不同的可能的服務。經常是這種情況：兩個實現之間真正的不同只是在於函式和方法的名稱。

這個問題從嵌入式作業系統產生就出現了，已經持續了幾十年了。與此同時的Win32和POSIX API已經分別佔據了PC機和UNIX工作站，成為事實上的標準，雖然這兩種API在實現上差別很大，但基本原理是相同的。

POSIX全稱為“可移植的UNIX作業系統介面”，不僅僅是API介面標準，而且是一個完整的作業系統標準，它囊括了與作業系統有關的各個方面的內容。其中，系統服務介面（IEEE 1003.1）是最基本的標準。

原始POSIX標準(IEEE 1003.1)的作者們也為實時作業系統建立了一個類似標準（IEEE 1003.4b）。一些很像UINX的嵌入式作業系統，例如VxWorks和LynxOS，就是符合這個標準API。

7 實時作業系統的發展方向

實時作業系統經過多年的發展，先後從真實模式進化到保護模式，從微核心技術進化到到超微核心技術，在系統規模上也從單處理器的RTOS發展到支援多處理器的RTOS和網路RTOS，在作業系統研究領域中形成了一個重要分支。

目前，嵌入式實時作業系統及其應用開發環境的發展動向是：

7.1 嵌入式實時作業系統正向實時超微核心(Nanokernel)、開放發展

八十年代後期，國外提出了微核心(Microkernel)的思想，即將傳統作業系統中的許多共性的東西抽象出來，構成作業系統的公共基礎，即微核心，真正具體的作業系統功能則由構造在微核心之外的伺服器實現。這是一種機制與策略分離的開放式設計思路。

近幾年，國外發展了一種基於微核心思想設計的精巧的嵌入式微核心，即實時超微核心(Nanokernel)。超微核心是一種非常緊湊的基本核心程式碼層， 為嵌入式應用提供了可搶佔， 快而確定的實時服務， 在它的基礎上可以靈活地構造各種型別的、與現成系統相容的、可伸縮的嵌入式實時作業系統。因此能滿足應用程式碼的可重用和可伸縮性(scalability)的需求。MRI首先推出的基於實時超微核心的嵌入式實時作業系統VRTXsa，它與VRTX32相容，並具有更強的功能，實時性和可靠性有了很大的改進。

7.2 開發環境向開放的、整合化的方向發展

    由於嵌入式應用軟體的特殊性，往往要求應用程式設計者具有一定的實時作業系統的專門知識，能合理地劃分任務，合理的配置系統以及目標聯機的除錯。因此，要設計實現一個高效能的實時應用軟體，需要強有力的交叉開發工具系統的支援。國外十分重視發展與實時作業系統配合的嵌入式應用的整合開發環境，現已發展到第三代，它以客戶－伺服器的系統結構為基礎，具有執行系統的無關性、連線的無關性、開放的軟體介面(與嵌入式實時作業系統，與開發工具，與目標環境的介面)、環境的一致性、宿主機上的目標模擬的特點。

1993年， MRI推出了世界上最先進的第三代嵌入式整合交叉開發系統Spectra。該系統可在UNIX及WINDOWS NT上建立起開放的、網路環境的交叉開發平臺，能將多來源的開發工具有機地結成一體，對複雜的嵌入式應用開發提供全過程支援。

綜上所述，嵌入式實時作業系統及其應用開發環境正向開放、整合發展。

    今後，RTOS研究方向主要集中在如下幾個方面： 

    1. RTOS的標準化研究 

    如今國外的RTOS開發商有數十家，提供了上百個RTOS，它們各具特色。但這也給應用開發者帶來難題，首先是應用程式碼的重用性難，當選擇不同的RTOS開發時，不能保護使用者已有的軟體投資，RTOS的標準化研究越來越被重視。美國IEEE協會在UNIX的基礎上，制定了實時UNIX系統的標準POSIX 1001.4系列協議，但仍有許多工作還待完成。 

    2. 多處理器結構RTOS、分散式實時作業系統和實時網路的研究 

    實時應用的飛速發展，對RTOS的效能提出了更高的要求。單處理器的計算機系統已不能很好地滿足某些複雜實時應用系統的需要，開發支援多處理器結構的RTOS已成為發展方向，這方面比較成功的系統有Psos+m等。至於分散式RTOS，國外一些RTOS廠家雖 

已推出部分產品，如QNX、Chorus、Plan 9等，但分散式實時作業系統的研究還未完全成熟，特別是在網路實時性和多處理器間任務排程演算法上還需進一步研究。 

    3. 整合的開放式實時系統開發環境的研究 

RTOS研究的另一個重要方向是整合開發環境的研究。開發實時應用系統，只有RTOS是不夠的，需要集編輯、編譯、除錯、模擬模擬等功能為一體的整合開發環境的支援。開發環境的研究還包括網路上多主機間協作開發與除錯應用技術的研究、RTOS與環境的無縫連線技術等。

8 實時作業系統的結構

一  作業系統的模型

任何作業系統在設計上若沒有一個簡化的模型（藍圖）做為整個大方向的引導，就很容易陷入一種混淆的局面――程式程式碼無組織的交相混雜在一起，甚至導致失敗。模型就象大樓的骨架，先有健全的骨架，然後繼續填土，粉刷等修飾的工作會變得比較容易。所以提出一個作業系統模型(Operating System Model)勢在必行。

有人稱，早期的MS-DOS，Windows3.x等產品還稱不上作業系統，而只是檔案操作和圖形介面的“程式組”，因為和那些登得上大雅之堂的所謂理論上的模型比較之下，它們離“真正的”作業系統還差一大截，所以作業系統模型應該是個滿足“學術理論模型”的作業系統，甚至應較理論上的更強些。

 在作業系統理論上，有較常見的三種模型：單體模型（Monolithic Model），層狀模型(Layered Model)，主從模型（Client/Server Model）。在確定實時作業系統模型之前，我們先簡單瞭解現有其它作業系統模型： 

1 單體模型

20世紀50年代中期到後期開發的早期作業系統很少考慮結構問題，沒有人具有構造大型軟體系統的經驗，並且對由於相互依賴和互動產生的問題估計過低。

單體模型把該有的功能都整合於一個整體，其中分不出明顯的模組，任何過程實際上都可以呼叫任何別的過程，作業系統內部之間的關係就像炒大鍋菜一般，或者用藕斷絲連來形容它，其中的函式呼叫來，呼叫去，很難分割出單獨的個體，如MS-DOS。

這種模型的最大特點就是牽一而發全身，所以更新，升級困難。

2 層狀模型

單體模型缺乏結構，無法解決大規模軟體開發的問題，需要採用模組化的程式設計技術，這就產生了分層作業系統。

層狀模型所有功能按層次組織，只是相鄰層之間發生互動。大多數層或所有層都在核心模式下執行。

圖 2 分層的核心模型

層狀模型的主要特色是一種由上而下的多層階梯結構（類似於我們熟悉的OSI七層模型），與應用程式越有關的東西擺在越靠近應用程式的地方（較上層），與應用程式越無關或不希望應用程式直接碰觸到的東西則擺在距離應用程式較遠的地方（較下層），命令則一律由上往下層傳送，執行，不允許跨層或任意方向傳送至其它層。

與單體模型比較，層狀模型主要有兩個優點：

1．作業系統按功能模組化使得子系統（模組）的更新，除錯容易。

2．應用程式僅接觸到作業系統的最上層應用程式介面（API）部分，不易對整個系統造成傷害，API是由作業系統提供的較低層的成套函式或切入點，程式設計者於其程式中呼叫種種API以獲得各種內建於作業系統的功能，如開啟檔案，讀檔案，移動游標位置等等。

層狀模型也存在一些問題。每層都處理相當多的功能，一層中的主要變化可能會產生巨大的影響，跟蹤相鄰層(上一層或下一層)中的程式碼有很多困難。其結果是，通過增加或減少一些功能，在基本作業系統上很難實現一個專用版本，並且由於相鄰層之間有很多互動，因而很難保證安全性。

3 主從模型

當我們在網路方面說到主從模型(Server/Client)時，一般指的是一部負責提供資料的伺服器及另一部取得資料的工作站，其中所共享的資料通常是檔案和印表機等。

作業系統的主從模型也很類似，但所分享的資料是系統所提供的種種服務，當然也負責提供服務的程式及所接受服務的程式，WindowsNT採用的作業系統架構就是主從模型。這兩個主從模型在抽象上都有個伺服器及客戶機主體，只是形式不一樣，換言之，透過這種機制，可將作業系統主體設計成分散於一群機器的分散式作業系統，應用系統扮演客戶端角色，作業系統本身則作為伺服器，應用程式向作業系統要求服務，作業系統則提供服務。　

二 實時核心

多工系統中，核心負責管理各個任務，或者說為每個任務分配CPU時間，並且負責任務之間的通訊。核心提供的基本服務是任務切換。

之所以使用實時核心可以大大簡化應用程式的設計，是因為實時核心允許將應用分成若干個任務，由實時核心來管理它們。核心本身也增加了應用程式的額外負荷，程式碼空間增加了ROM的用量，核心本身的資料結構增加了RAM的用量。但更為主要的是，每個任務要有自己的堆疊空間，這一塊佔起記憶體來是相當厲害的。核心本身對CPU的佔用時間一般在2%-5%之間。

微控制器一般不能執行實時核心，因為微控制器的RAM很有限。通過提供必不可少的系統服務，諸如訊號量管理、訊息佇列、延時等，實時核心使得CPU的利用更為有效。

需要指出的是，實時核心並不等於實時作業系統，實時核心只是實時作業系統的一部分。

核心是整個作業系統的基礎，實時核心同樣是實時作業系統的基礎，目前很多實時核心採用微核心結構。實時核心通常是基於優先順序排程的核心，所有時間要求苛刻的事件都得到了儘可能快捷、有效的處理。

如果應用專案對額外的需求可以承受，應該考慮使用實時核心。這些額外的需求為：核心的價格，額外的ROM/RAM開銷，2-5%的CPU額外負荷。使用實時核心會增加價格成本，在一些應用中，價格就是一起，以至於對使用RTOS連想都不敢想。

為滿足某些特殊需要的實時軟體開發的要求，可能會需要自己開發實時核心，一般它要符合POSIX實時擴充套件標準介面(支援系統的開發性和可移植性要求)。

實時核心設計時要考慮輪詢、協同、中斷驅動以及前/後臺工作等需求，提供對任務、中斷、時間和多處理器等的全面管理，並要求用高階語言實現(可移植性考慮)。設計出的實時核心要求緊湊、高效、專用、可移植性好。

實時核心的多處理器支援應包括處理同構和異構系統的能力，其核心程式應具有自動補償不同處理器之間體系結構的差別(如位元組交換等)。這使得從一個處理器家族到另一個處理器家族的轉換變得異常容易，且不需要重新設計。

三 微核心

微核心(microkernel)是一個小型的作業系統核心，為模組化擴充套件提供了基礎。微核心通過在Mach作業系統中的使用而推廣。理論上，微核心方法提供了高度的靈活性和模組化。當今許多作業系統都聲稱採用了微核心結構，例如Windows 2000。

目前關於微核心的概念還有一些含糊，關於微核心的許多問題，例如微核心應該提供什麼功能以及實現什麼結構，不同的作業系統設計者有不同的回答。

與微核心相對的是巨集核心的概念。 巨集核心中把本來在微核心之外實現的許多作業系統功能放到了核心之中實現(如程序管理，記憶體管理等)。 Linux就是這樣的系統。

微核心將許多作業系統服務放入分離的伺服器，如檔案系統，裝置驅動程式，而應用程式通過訊息傳遞呼叫作業系統服務。微核心結構必然是多工的，第一代微核心，在核心提供了較多的服務，因此被稱為“胖微核心”，它的典型代表是Mach，它既是GNU HURD也是APPLE SERVER OS 的核心，可以說，蒸蒸日上。第二代為核心只提供最基本的作業系統服務，典型的作業系統是QNX，QNX在理論界很有名，被認為是一種先進的作業系統。

微核心通常採用分層結構，如圖 3所示。

圖 3 微核心作業系統

微核心通常只保留程序間通訊(IPC)，任務排程，低階儲存管理，中斷處理等幾項最基本的功能，它依據客戶-伺服器模型概念，把所有的其它的作業系統功能都變成一個都變成一個個使用者態的伺服器，而使用者態程序則被當作客戶。客戶應用程式要用到作業系統時，其實就是通過微核心與伺服器通訊，微核心僅僅成了一個傳遞訊息的工具。微核心驗證訊息的有效性，在客戶機和伺服器之間傳遞它們並核准對硬體的存取。例如，如果應用程式想開啟一個檔案，則它給檔案系統伺服器傳送訊息，如圖4所示；如果要建立一個任務，則它給任務伺服器傳送訊息。每個伺服器也可以給別的伺服器傳送訊息，並可以呼叫微核心提供的其它功能。

圖 4 應用程式與伺服器之間的通訊

微核心是指核心功能少，而不一定是核心尺寸小，例如著名的微核心作業系統Mach的核心就有100-200K位元組。

採用微核心的優點：

1．一致性介面：微核心提供了一致性介面，所有的服務都通過訊息傳遞提供，使用者態程式不需要區分是核心級服務還是使用者級服務。

2．可移植性：與CPU有關的硬體方面的細節都在微核心中，這樣，整個作業系統就很容易從一個CPU體系移植到另一個CPU體系。

3．可擴充套件性：如果要擴充套件功能，僅是要增加或修改相應的伺服器，而不用構造一個新核心。

4．靈活性：與可擴充套件性相對應，不僅可以增加新功能，還可以刪除現有的功能，以產生一個更小、更高效的實現。使用者可以根據應用的實際需要，刪除某些可選的功能，從而自己定製了一個更符合自己需要的作業系統。

5．可靠性：在微核心方式下，各個伺服器都是獨立的使用者態程序，有自己的記憶體保護空間，以標準的IPC方式通訊，一個伺服器出錯，不會導致整個系統崩潰。另外，軟體規模越大，越難以保證其可靠性，而微核心較小，可以被嚴格測試，而且它只使用了少量的API介面，便於掌握，而且與其它模組的互動較少，有利於產生高質量的程式碼。

6．分散式系統支援：伺服器可以在不同的處理機上執行，適合多處理機系統或分散式處理系統。

當把微核心機制用於實時作業系統時，存在兩種擔心：一是使用者態與核心態的切換頻率，會增加上下文切換時間；另一是程序之間的訊息傳遞開銷要比傳統作業系統的系統呼叫的開銷要大。通常上下文切換時間與執行一項作業系統服務總的時間相比很小，尤其是在將上下文切換時間作了優化之後。分立的伺服器程序可以使各項作業系統服務並行地進行，而且各個伺服器程序還可以像使用者程序一樣按優先順序處理，高優先順序服務程序可以搶佔低優先順序服務程序。這些都帶來極大的優越性。因此，總體來看，微核心開銷比傳統作業系統的開銷反而要小。

大多數訊息傳輸都在20位元組的數量級，傳輸