提高實時操作系統的實時性能和可靠性策略
http://www.dcyhziu.cn 2007/6/5 源自:中華職工學習網 【字體：
】
】
對很多嵌入式系統來說，一個設計良好的實時操作系統(RTOS)可以讓開發工程師掌握系統執行任何任務或響應任何關鍵事件的時間，滿足系統實時性要求。為了理解RTOS如何通過系統調度策略實現實時性要求，本文介紹了搶占式調度、可搶占的內核、優先級繼承和中斷處理等概念。
在設計工業控制系統或醫療設備時，大部分工程師和系統設計工程師會認為采用RTOS是必需的。然而，網際路由器、車載娛樂系統和多媒體設備等普通應用還需要采用RTOS嗎？像Linux或Windows這樣的通用操作系統是否就能勝任呢？通常，這些產品需要采用RTOS，但是這個問題常常直到設計階段的后期才能意識到。
RTOS對于很多嵌入式系統來說不但是有益的，而且也是必要的，認識到這一點很重要。例如，一個播放如MPEG格式電影的設備，如果依靠軟件來實現其整個內容傳輸，可能會出現用戶難以接受的高丟幀率。然而，通過使用RTOS，系統設計工程師能夠準確地控制軟件過程的執行順序，從而保證按照給定的媒體速率進行播放。上述大部分情況適用于用戶希望對輸入做出立即響應的系統。通過RTOS，開發人員能夠保證由用戶的操作總能得到及時的響應，除非一個更重要的操作(如一項有助于保障用戶安全的操作)必須首先執行。
總之,一個好的RTOS支持開發人員控制系統執行任何任務或對任何重要事件做出反應的時間，并且能夠以一種可以預測并且完全一致的形式滿足任務執行的最終期限要求。但是，如果RTOS崩潰，這些最終期限就不能被滿足。因此，RTOS必須提供高度的可靠性。特別是它必須提供在不需要重啟的情況下，從軟件故障中快速并智能恢復的機制。
搶占式調度
在像Linux這樣的通用操作系統中，在對線程和進程的CPU占用上采用了“公平”調度策略。這樣的策略能夠提供良好的整體表現，但是不能保證高優先級、對時間要求嚴格的線程將優先于低優先級的線程執行。事實上，操作系統有時甚至會中斷高優先級的線程來為低優先級線程提供CPU時間。其結果可能造成對時間要求嚴格的線程很容易地錯過它們的最終期限，甚至在一個高速的高端處理器上運行時也會出現這種情況。
而在RTOS中，線程按照其優先級順序執行。如果一個高優先級的線程準備運行時，它將在一個短的、有限時間間隔內從任何可能正在運行的低優先級進程接管CPU。另外，高優先級的線程能夠不被中斷地運行，直到它已經完成了需要做的事情－當然是在不被更高優先級進程搶占的前提下。這種方法就是搶占式調度，保證了高優先級線程始終滿足其最終期限，而不管有多少其它線程正在競爭CPU時間。
通過合理地控制線程優先級，開發者能顯著地提高很多對用戶非常重要的應用響應速度。然而，控制優先級可能是一把雙刃劍，當使用不當時它可能會潛在地導致低優先級的進程不能得到CPU時間。保證高優先級的進程和線程的同時確保不會使其它進程處于“饑餓”狀態的關鍵是要對它們的執行進行限制，通過對執行進行調整或在響應加載的過程中進行控制，開發人員能夠限制這些活動消耗的CPU時間比例，并支持低優先級進程獲得對CPU的共享。
優先級控制能夠使很多應用受益，包括像前面提到的媒體播放器(MP3、WAV、MPEG2等格式)。媒體播放器需要實現正常播放所要求的速率(例如44kHz的音頻、30fps的視頻)。在這種限制之下，一個讀線程和一個顯示線程可以被設計成依靠一個可編程的定時器來喚醒，緩沖或顯示一幀后進入睡眠狀態，直到下一個定時觸發。這提供了一種調整機制，支持高于正常用戶活動而又低于關鍵系統功能的優先級設置。換句話說，如果沒有更重要的任務準備運行，媒體播放將始終以給定的媒體速率執行。
最壞情形
搶占式調度僅在高優先級的線程在一個短的、有限時間段內搶占低優先級線程的情況下有效。否則，系統將不可能預測要花費多長時間來執行一個給定的操作。因此，任何銷售進程模式的RTOS的供應商都必須提供針對下面兩種時間間隔提供最壞情形：線程切換時間，即當兩個線程處于同一進程的情況下，從執行一個線程的最后一條指令到執行下一個被調度線程的第一條指令所經過的時間；前后關系切換(context switch)時間，其定義同上，但僅針對兩個線程處于不同進程的情況。
可以將線程看作是最小的“執行單元”，而將進程看作是一個或多個線程的“容器”，進程定義了線程將要在其中執行的地址空間。顯然，最壞情形的前后關系切換時間將比最壞情形的線程切換時間要慢，盡管在一個好的RTOS設計中差別可能是微不足道的。
將所有的線程放在幾個大的進程中將是錯誤的，因為線程提供的切換速度更快。雖然線程能實現并行處理優勢因而適合于某些設計，但將一個應用分成多個內存保護的進程使得代碼更容易調試，提供了更好的錯誤隔離和恢復能力，并允許系統進行新功能的動態升級。
可搶占的內核
在大部分通用操作系統中，操作系統的內核是不可搶占的。其結果是，一個高優先級的進程不可能搶占一個內核調用，而是必須等待整個調用完成，即使這個調用是由系統中的低優先級進程發起的。另外，當經常在內核調用中執行的驅動程序或其它系統服務代表一個客戶線程執行的時候，所有的優先級信息常常會丟失，這導致了不可預測的延遲并阻止了關鍵活動的準時完成。
而在RTOS中,內核操作是可搶占的。盡管仍然會存在一些時間窗口，在這些時間窗口中可能沒有搶占，但是這些時間間隔應該是相當短暫的，通常在幾百納秒。另外，必須有一個關于搶占被推遲或中斷被禁止的時間上限，這樣開發者可以確定最壞情形下的等待時間。
為了實現這個目標，操作系統內核必須盡可能簡潔，只有具有較短執行路徑的服務才被包含在內核中，任何需要大量工作(如進程加載)的操作必須被安排到外部進程或線程。這種方法有助于通過內核確保最長的不可搶占代碼路徑具有一個時間上限。
優先級繼承
然而，為一個進程設定一個高優先級并不總能保證該進程能夠搶占低優先級的進程。有時候，系統會出現一種稱為優先級倒置(priority inversion)的狀態，在這種狀態下，低優先級的進程將在“無意中”阻止較高優先級進程占用CPU。優先級倒置可能會表現為幾種形式，為了防止發生這種情況，RTOS必須提供一種稱為優先級繼承的功能。
假定系統有三個進程：A(低優先級)，B(中等優先級)，Z(高優先級)。這里Z是一個為A和B提供服務的“服務器”進程。參見圖1。
現在假定A已經請求Z來執行一個計算，而在這期間，突然B需要Z的服務。因為B擁有比A更高的優先級，一般會認為Z將立即掛起A的請求并將轉向為B服務。但是實際情況并非如此，因為Z比B具有更高的優先級。其結果是，B不能阻止Z完成它當前的工作，即對A做出響應。
從效果上看，低優先級的進程A占用了更高優先級進程B的CPU時間，這是引入優先級繼承的原因。通過使用RTOS提供的優先級繼承機制，系統可以在A發出請求的情況下，讓Z繼承A的低優先級。通過這種方式，B能夠在任何時候搶占A的請求。
如果一個應用程序分布于幾個通過網絡連接的處理器，那么RTOS也應該支持分布式優先級繼承，這樣可以按照優先級的順序處理來自多個處理器的請求。如果沒有優先級繼承，一個多處理器系統可能會落入無限的優先級倒置和死鎖中。
中斷處理
為了獲得對外部事件的及時響應，最小化硬件中斷發生到執行該中斷的第一條代碼的時間很重要。這個時間間隔稱為中斷延遲，為了保證中斷延遲盡可能小，一個好的RTOS應該在幾乎所有時間內都支持產生中斷。正如在關于內核搶占部分提到的那樣，一些重要的代碼段的確需要暫時屏蔽中斷。這種最大的屏蔽時間通常被定義為最大的中斷延遲。
在某些情況下，硬件中斷處理器必須調度并運行一個更高優先級的線程(例如在一個驅動程序中)。在這樣的情況下，中斷處理器將返回并指示一個事件將被處理。這樣的處理將引入了第二種形式的延遲－調度延遲，這個延時必須在設計中加以考慮。調度延遲是介于用戶的中斷處理器的最后一條指令和驅動程序線程第一條指令的執行之間的時間。
在一個嵌入式系統中可能會同時出現多個硬件中斷。例如，在一個病人監護系統中，當一個傳感器記錄了病人心跳的一次變化并且網卡接收到網絡傳來的數據的同時，護士按了觸摸屏。很明顯，一些中斷(如心率的變化)應該立即得到處理，而其他的則可以延緩。通過提供對嵌套中斷的支持，RTOS支持嵌入式系統優先處理更高優先級的中斷。
如何提高可靠性
我們已經明白怎樣使RTOS具有可以預測性，但是如何實現其可靠性呢？答案在很大程度上取決于RTOS的架構。
例如在實時執行模式架構中，大部分或所有軟件組件都在一個單一的內存地址空間中運行，包括操作系統內核、網絡協議棧、設備驅動程序、應用程序等。雖然很有效率，但這種架構有兩個明顯的缺陷：1. 在任何組件中的一個指針錯誤，不論這個錯誤多么細微，都可能破壞操作系統內核或任何其它組件，導致不可預測的行為和整個系統的崩潰；2. 很難動態修復或替換任何有故障的組件。在大多數情況下，出現這些問題時系統復位是唯一的選擇。
一些RTOS，也像Linux一樣，試圖通過使用單內核架構來解決這個問題。在這種架構中，用戶的應用程序在隔離的、受保護內存地址空間中運行。如果一個應用程序試圖訪問其地址空間之外的數據，內存管理單元(MMU)將通知操作系統，操作系統可能會采取保護措施，例如終止出錯進程。然而，這樣的操作系統需要將大多數或所有驅動程序、文件系統和其它系統服務綁定到內核中。因此，任何組件中的一個錯誤都可能帶來災難性的內核故障。
第三種方法是采用微內核(mricokernel)架構來提供更精確的故障隔離，像QNX Neutrino這樣的操作系統都基于微內核架構。微內核有兩個明確的特征：
1. 在操作系統內核中只實現了一個包含了基本OS服務的小內核(如信號量、定時器、任務調度等)。包括驅動程序、文件系統、協議棧和用戶應用程序在內的所有其它的組件在內核外部分離的、保護內存的進程中運行。有問題的系統服務不再作為孤立的故障點，而是在它破壞其它服務或操作系統內核之前被終止并重啟。
2. 所有的組件能夠通過消息傳遞進行通信，一個定義良好的通信機制保障了程序在保持彼此安全隔離的前提下進行數據交換。適當實現的消息傳遞也可以作為一個虛擬的“軟件總線”，允許幾乎任何的軟件組件，甚至是一個設備驅動程序被動態地加入或替換，對于必須提供連續服務的系統而言這是一項關鍵要求。
和傳統的操作系統架構相比，微內核支持嵌入式設備贏得明顯更快的平均修復時間(MTTR)。例如，如果一個設備驅動程序失敗將可能出現以下情況：操作系統可以終止該驅動程序，回收其正在使用的資源，并對其進行重新啟動，這個過程通常這只需要幾個毫秒時間。
盡管和傳統的操作系統相比，基于消息傳遞的微內核RTOS通常提供了更好的容錯性和動態升級能力，也有一些觀點認為消息傳遞增加了開銷。在實際應用中，如果實現正確，消息傳遞的性能可以接近底層硬件的內存帶寬。例如，一個微內核RTOS可以采用多段式(multipart)消息和線程到線程的消息數據直接拷貝等各種技術，來確保系統性能可以達到傳統的進程間通信(IPC)方法的水平。由一些組織如Dedicated Systems(網址：www.omimo.be)等進行的獨立測試證實，和傳統的RTOS相比，微內核RTOS在一系列的實時指標方面表現良好，在很多情況下甚至有更好的表現。
策略決策
RTOS有助于使一個復雜的應用程序具有可預測性和可靠性。當然，選擇一個合適的RTOS本身就是一項復雜的任務，而RTOS的底層架構是選擇的重要依據，此外還有一些其它因素，包括：
1. 調度算法的靈活選擇。RTOS應該支持調度算法的選擇(先入先出(FIFO)、輪詢(round robin)、零星調度等)并支持以線程為單位設定這些算法。這樣，工程師就可以不必將一個算法用到系統中的所有線程。
2. 圖形用戶界面(GUI)。RTOS使用的是原始的圖形庫還是能支持多層界面、多路顯示、3D渲染以及其它高級的圖形功能的真正的窗口系統？能很容易定制GUI的外觀嗎？GUI支持同時顯示和輸入多種語言(漢語、韓語、日語、英語、俄語等)嗎？
3. 遠程診斷工具。因為對很多嵌入式系統而言，中斷系統運行進行檢測和維護是無法接受的。RTOS供應商應該提供診斷工具，這些工具能夠在不中斷系統服務的前提下分析系統的行為。要尋找能提供代碼覆蓋、應用測評、跟蹤分析和內存分析工具的供應商。
4. 開發平臺。RTOS提供商提供的開發環境是基于像Eclipse那樣的開放平臺，允許工程師嵌入所喜愛的第三方工具來進行建模、版本控制嗎？還是開發環境基于專利技術？
5. 互聯網功能。RTOS支持預集成最新的IPv4、IPv6、IPsec、SCTP和具有NAT功能的IP過濾等協議棧套件嗎？它支持嵌入式網絡瀏覽器嗎？瀏覽器應該具有可擴展的封裝模式，并能夠在很小的屏幕上繪制網頁。它也應該支持像HTML 4.01、XHTML 1.1、SSL 3.0和 WML 1.3這樣的標準。
6. 標準API。RTOS將你限定到專有的API之中了嗎？還是它對于像POSIX這樣的標準API提供了完全的支持，這使得將代碼移植到其它操作系統，或者從其它操作系統移植代碼變得更容易？另外，所用的RTOS提供完全一致性的API還是僅僅支持被定義接口的一個子集？例如，POSIX.1的最新版本包含了大約1,300個接口。
7. 多處理技術。RTOS能支持對稱多處理和分布式多處理技術來提高應用性能和容量嗎？如果這樣，是必須重新設計你的應用程序呢，還是RTOS能夠將應用程序透明的分配到多個處理器上去呢？
8. 源代碼工具包。RTOS供應商提供了能使RTOS滿足設計需求的具有詳細文檔的定制工具包嗎？供應商提供了方便開發驅動定制硬件的驅動程序開發工具包嗎？
9. 對于很多公司而言，選擇一款RTOS是一項戰略性決策。RTOS供應商在對上述問題提供了清楚的回答后，你將選擇出一個在現在和將來都適合你的RTOS。
在設計工業控制系統或醫療設備時，大部分工程師和系統設計工程師會認為采用RTOS是必需的。然而，網際路由器、車載娛樂系統和多媒體設備等普通應用還需要采用RTOS嗎？像Linux或Windows這樣的通用操作系統是否就能勝任呢？通常，這些產品需要采用RTOS，但是這個問題常常直到設計階段的后期才能意識到。
RTOS對于很多嵌入式系統來說不但是有益的，而且也是必要的，認識到這一點很重要。例如，一個播放如MPEG格式電影的設備，如果依靠軟件來實現其整個內容傳輸，可能會出現用戶難以接受的高丟幀率。然而，通過使用RTOS，系統設計工程師能夠準確地控制軟件過程的執行順序，從而保證按照給定的媒體速率進行播放。上述大部分情況適用于用戶希望對輸入做出立即響應的系統。通過RTOS，開發人員能夠保證由用戶的操作總能得到及時的響應，除非一個更重要的操作(如一項有助于保障用戶安全的操作)必須首先執行。
總之,一個好的RTOS支持開發人員控制系統執行任何任務或對任何重要事件做出反應的時間，并且能夠以一種可以預測并且完全一致的形式滿足任務執行的最終期限要求。但是，如果RTOS崩潰，這些最終期限就不能被滿足。因此，RTOS必須提供高度的可靠性。特別是它必須提供在不需要重啟的情況下，從軟件故障中快速并智能恢復的機制。
搶占式調度
在像Linux這樣的通用操作系統中，在對線程和進程的CPU占用上采用了“公平”調度策略。這樣的策略能夠提供良好的整體表現，但是不能保證高優先級、對時間要求嚴格的線程將優先于低優先級的線程執行。事實上，操作系統有時甚至會中斷高優先級的線程來為低優先級線程提供CPU時間。其結果可能造成對時間要求嚴格的線程很容易地錯過它們的最終期限，甚至在一個高速的高端處理器上運行時也會出現這種情況。
而在RTOS中，線程按照其優先級順序執行。如果一個高優先級的線程準備運行時，它將在一個短的、有限時間間隔內從任何可能正在運行的低優先級進程接管CPU。另外，高優先級的線程能夠不被中斷地運行，直到它已經完成了需要做的事情－當然是在不被更高優先級進程搶占的前提下。這種方法就是搶占式調度，保證了高優先級線程始終滿足其最終期限，而不管有多少其它線程正在競爭CPU時間。
通過合理地控制線程優先級，開發者能顯著地提高很多對用戶非常重要的應用響應速度。然而，控制優先級可能是一把雙刃劍，當使用不當時它可能會潛在地導致低優先級的進程不能得到CPU時間。保證高優先級的進程和線程的同時確保不會使其它進程處于“饑餓”狀態的關鍵是要對它們的執行進行限制，通過對執行進行調整或在響應加載的過程中進行控制，開發人員能夠限制這些活動消耗的CPU時間比例，并支持低優先級進程獲得對CPU的共享。
優先級控制能夠使很多應用受益，包括像前面提到的媒體播放器(MP3、WAV、MPEG2等格式)。媒體播放器需要實現正常播放所要求的速率(例如44kHz的音頻、30fps的視頻)。在這種限制之下，一個讀線程和一個顯示線程可以被設計成依靠一個可編程的定時器來喚醒，緩沖或顯示一幀后進入睡眠狀態，直到下一個定時觸發。這提供了一種調整機制，支持高于正常用戶活動而又低于關鍵系統功能的優先級設置。換句話說，如果沒有更重要的任務準備運行，媒體播放將始終以給定的媒體速率執行。
最壞情形
搶占式調度僅在高優先級的線程在一個短的、有限時間段內搶占低優先級線程的情況下有效。否則，系統將不可能預測要花費多長時間來執行一個給定的操作。因此，任何銷售進程模式的RTOS的供應商都必須提供針對下面兩種時間間隔提供最壞情形：線程切換時間，即當兩個線程處于同一進程的情況下，從執行一個線程的最后一條指令到執行下一個被調度線程的第一條指令所經過的時間；前后關系切換(context switch)時間，其定義同上，但僅針對兩個線程處于不同進程的情況。
可以將線程看作是最小的“執行單元”，而將進程看作是一個或多個線程的“容器”，進程定義了線程將要在其中執行的地址空間。顯然，最壞情形的前后關系切換時間將比最壞情形的線程切換時間要慢，盡管在一個好的RTOS設計中差別可能是微不足道的。
將所有的線程放在幾個大的進程中將是錯誤的，因為線程提供的切換速度更快。雖然線程能實現并行處理優勢因而適合于某些設計，但將一個應用分成多個內存保護的進程使得代碼更容易調試，提供了更好的錯誤隔離和恢復能力，并允許系統進行新功能的動態升級。
可搶占的內核
在大部分通用操作系統中，操作系統的內核是不可搶占的。其結果是，一個高優先級的進程不可能搶占一個內核調用，而是必須等待整個調用完成，即使這個調用是由系統中的低優先級進程發起的。另外，當經常在內核調用中執行的驅動程序或其它系統服務代表一個客戶線程執行的時候，所有的優先級信息常常會丟失，這導致了不可預測的延遲并阻止了關鍵活動的準時完成。
而在RTOS中,內核操作是可搶占的。盡管仍然會存在一些時間窗口，在這些時間窗口中可能沒有搶占，但是這些時間間隔應該是相當短暫的，通常在幾百納秒。另外，必須有一個關于搶占被推遲或中斷被禁止的時間上限，這樣開發者可以確定最壞情形下的等待時間。
為了實現這個目標，操作系統內核必須盡可能簡潔，只有具有較短執行路徑的服務才被包含在內核中，任何需要大量工作(如進程加載)的操作必須被安排到外部進程或線程。這種方法有助于通過內核確保最長的不可搶占代碼路徑具有一個時間上限。
優先級繼承
然而，為一個進程設定一個高優先級并不總能保證該進程能夠搶占低優先級的進程。有時候，系統會出現一種稱為優先級倒置(priority inversion)的狀態，在這種狀態下，低優先級的進程將在“無意中”阻止較高優先級進程占用CPU。優先級倒置可能會表現為幾種形式，為了防止發生這種情況，RTOS必須提供一種稱為優先級繼承的功能。
假定系統有三個進程：A(低優先級)，B(中等優先級)，Z(高優先級)。這里Z是一個為A和B提供服務的“服務器”進程。參見圖1。
現在假定A已經請求Z來執行一個計算，而在這期間，突然B需要Z的服務。因為B擁有比A更高的優先級，一般會認為Z將立即掛起A的請求并將轉向為B服務。但是實際情況并非如此，因為Z比B具有更高的優先級。其結果是，B不能阻止Z完成它當前的工作，即對A做出響應。
從效果上看，低優先級的進程A占用了更高優先級進程B的CPU時間，這是引入優先級繼承的原因。通過使用RTOS提供的優先級繼承機制，系統可以在A發出請求的情況下，讓Z繼承A的低優先級。通過這種方式，B能夠在任何時候搶占A的請求。
如果一個應用程序分布于幾個通過網絡連接的處理器，那么RTOS也應該支持分布式優先級繼承，這樣可以按照優先級的順序處理來自多個處理器的請求。如果沒有優先級繼承，一個多處理器系統可能會落入無限的優先級倒置和死鎖中。
中斷處理
為了獲得對外部事件的及時響應，最小化硬件中斷發生到執行該中斷的第一條代碼的時間很重要。這個時間間隔稱為中斷延遲，為了保證中斷延遲盡可能小，一個好的RTOS應該在幾乎所有時間內都支持產生中斷。正如在關于內核搶占部分提到的那樣，一些重要的代碼段的確需要暫時屏蔽中斷。這種最大的屏蔽時間通常被定義為最大的中斷延遲。
在某些情況下，硬件中斷處理器必須調度并運行一個更高優先級的線程(例如在一個驅動程序中)。在這樣的情況下，中斷處理器將返回并指示一個事件將被處理。這樣的處理將引入了第二種形式的延遲－調度延遲，這個延時必須在設計中加以考慮。調度延遲是介于用戶的中斷處理器的最后一條指令和驅動程序線程第一條指令的執行之間的時間。
在一個嵌入式系統中可能會同時出現多個硬件中斷。例如，在一個病人監護系統中，當一個傳感器記錄了病人心跳的一次變化并且網卡接收到網絡傳來的數據的同時，護士按了觸摸屏。很明顯，一些中斷(如心率的變化)應該立即得到處理，而其他的則可以延緩。通過提供對嵌套中斷的支持，RTOS支持嵌入式系統優先處理更高優先級的中斷。
如何提高可靠性
我們已經明白怎樣使RTOS具有可以預測性，但是如何實現其可靠性呢？答案在很大程度上取決于RTOS的架構。
例如在實時執行模式架構中，大部分或所有軟件組件都在一個單一的內存地址空間中運行，包括操作系統內核、網絡協議棧、設備驅動程序、應用程序等。雖然很有效率，但這種架構有兩個明顯的缺陷：1. 在任何組件中的一個指針錯誤，不論這個錯誤多么細微，都可能破壞操作系統內核或任何其它組件，導致不可預測的行為和整個系統的崩潰；2. 很難動態修復或替換任何有故障的組件。在大多數情況下，出現這些問題時系統復位是唯一的選擇。
一些RTOS，也像Linux一樣，試圖通過使用單內核架構來解決這個問題。在這種架構中，用戶的應用程序在隔離的、受保護內存地址空間中運行。如果一個應用程序試圖訪問其地址空間之外的數據，內存管理單元(MMU)將通知操作系統，操作系統可能會采取保護措施，例如終止出錯進程。然而，這樣的操作系統需要將大多數或所有驅動程序、文件系統和其它系統服務綁定到內核中。因此，任何組件中的一個錯誤都可能帶來災難性的內核故障。
第三種方法是采用微內核(mricokernel)架構來提供更精確的故障隔離，像QNX Neutrino這樣的操作系統都基于微內核架構。微內核有兩個明確的特征：
1. 在操作系統內核中只實現了一個包含了基本OS服務的小內核(如信號量、定時器、任務調度等)。包括驅動程序、文件系統、協議棧和用戶應用程序在內的所有其它的組件在內核外部分離的、保護內存的進程中運行。有問題的系統服務不再作為孤立的故障點，而是在它破壞其它服務或操作系統內核之前被終止并重啟。
2. 所有的組件能夠通過消息傳遞進行通信，一個定義良好的通信機制保障了程序在保持彼此安全隔離的前提下進行數據交換。適當實現的消息傳遞也可以作為一個虛擬的“軟件總線”，允許幾乎任何的軟件組件，甚至是一個設備驅動程序被動態地加入或替換，對于必須提供連續服務的系統而言這是一項關鍵要求。
和傳統的操作系統架構相比，微內核支持嵌入式設備贏得明顯更快的平均修復時間(MTTR)。例如，如果一個設備驅動程序失敗將可能出現以下情況：操作系統可以終止該驅動程序，回收其正在使用的資源，并對其進行重新啟動，這個過程通常這只需要幾個毫秒時間。
盡管和傳統的操作系統相比，基于消息傳遞的微內核RTOS通常提供了更好的容錯性和動態升級能力，也有一些觀點認為消息傳遞增加了開銷。在實際應用中，如果實現正確，消息傳遞的性能可以接近底層硬件的內存帶寬。例如，一個微內核RTOS可以采用多段式(multipart)消息和線程到線程的消息數據直接拷貝等各種技術，來確保系統性能可以達到傳統的進程間通信(IPC)方法的水平。由一些組織如Dedicated Systems(網址：www.omimo.be)等進行的獨立測試證實，和傳統的RTOS相比，微內核RTOS在一系列的實時指標方面表現良好，在很多情況下甚至有更好的表現。
策略決策
RTOS有助于使一個復雜的應用程序具有可預測性和可靠性。當然，選擇一個合適的RTOS本身就是一項復雜的任務，而RTOS的底層架構是選擇的重要依據，此外還有一些其它因素，包括：
1. 調度算法的靈活選擇。RTOS應該支持調度算法的選擇(先入先出(FIFO)、輪詢(round robin)、零星調度等)并支持以線程為單位設定這些算法。這樣，工程師就可以不必將一個算法用到系統中的所有線程。
2. 圖形用戶界面(GUI)。RTOS使用的是原始的圖形庫還是能支持多層界面、多路顯示、3D渲染以及其它高級的圖形功能的真正的窗口系統？能很容易定制GUI的外觀嗎？GUI支持同時顯示和輸入多種語言(漢語、韓語、日語、英語、俄語等)嗎？
3. 遠程診斷工具。因為對很多嵌入式系統而言，中斷系統運行進行檢測和維護是無法接受的。RTOS供應商應該提供診斷工具，這些工具能夠在不中斷系統服務的前提下分析系統的行為。要尋找能提供代碼覆蓋、應用測評、跟蹤分析和內存分析工具的供應商。
4. 開發平臺。RTOS提供商提供的開發環境是基于像Eclipse那樣的開放平臺，允許工程師嵌入所喜愛的第三方工具來進行建模、版本控制嗎？還是開發環境基于專利技術？
5. 互聯網功能。RTOS支持預集成最新的IPv4、IPv6、IPsec、SCTP和具有NAT功能的IP過濾等協議棧套件嗎？它支持嵌入式網絡瀏覽器嗎？瀏覽器應該具有可擴展的封裝模式，并能夠在很小的屏幕上繪制網頁。它也應該支持像HTML 4.01、XHTML 1.1、SSL 3.0和 WML 1.3這樣的標準。
6. 標準API。RTOS將你限定到專有的API之中了嗎？還是它對于像POSIX這樣的標準API提供了完全的支持，這使得將代碼移植到其它操作系統，或者從其它操作系統移植代碼變得更容易？另外，所用的RTOS提供完全一致性的API還是僅僅支持被定義接口的一個子集？例如，POSIX.1的最新版本包含了大約1,300個接口。
7. 多處理技術。RTOS能支持對稱多處理和分布式多處理技術來提高應用性能和容量嗎？如果這樣，是必須重新設計你的應用程序呢，還是RTOS能夠將應用程序透明的分配到多個處理器上去呢？
8. 源代碼工具包。RTOS供應商提供了能使RTOS滿足設計需求的具有詳細文檔的定制工具包嗎？供應商提供了方便開發驅動定制硬件的驅動程序開發工具包嗎？
9. 對于很多公司而言，選擇一款RTOS是一項戰略性決策。RTOS供應商在對上述問題提供了清楚的回答后，你將選擇出一個在現在和將來都適合你的RTOS。
|
|
相關鏈接
|
|