大部分嵌入式項目還需要實時操作系統嗎?這個問題問得好，因為現代高性能處理器和 Linux、Windows 和其他通用操作系統 (GPOS) 的實時補丁的可用性都在飛速發展。嵌入式設備的本質道出了答案。在許多情況下，制造設備都需要幾千甚至幾百萬個部件。哪怕設備硬件的單位成本節省 1 美元，都會為制造商帶來不小的財富。換言之，設備無法承受數千兆赫茲級處理器的成本(更不用說熱耗散了)。例如，在汽車遠程信息處理技術市場，常見的 32 位處理器以約 600 Mhz 的速度運行——遠遠慢于臺式機和服務器的常用處理器。在這種運行環境中，實時操作系統能得到低端硬件超快、可預測的響應，因此具有顯著的節約成本的優勢。

除節約成本之外，實時操作系統提供的服務還能使許多計算問題迎刃而解，特別是當多種運行爭奪系統資源時。例如，試想一個用戶期望(或需要)立即響應輸入的系統。利用實時操作系統，軟件開發人員能確保用戶啟動的操作會先于其他系統活動執行，除非必須先執行更重要的任務(如幫助保護用戶安全的運行)。

再試想一個必須滿足服務質量 (QoS) 要求的系統，例如一臺可播放現場視頻的設備。如果設備依靠軟件播放其內容，它可能會以用戶無法接受的速率出現失幀現象——從用戶的角度看，該設備不可靠。但使用實時操作系統的話，軟件開發人員就能精確控制軟件進程的執行順序，確保以適當和一致的媒體速率播放。

實時操作系統并不“公平”

對“硬”實時的需求(以及對實現該功能的實時操作系統的需求)仍然是嵌入式產品業的普遍要求。問題是，實時操作系統具備哪些通用操作系統所不具備的功能呢?適用于一些通用操作系統的實時擴展組件有多大用處呢?它們能提供和實時操作系統一樣的性能嗎?

讓我們先從任務調度開始。在通用操作系統中，調度程序通常使用一種“公平”策略，將線程和進程分配到 CPU 中。這種策略可確保臺式機和服務器的應用程序所需的較高的總吞吐量，但無法保證優先級高、時間要求嚴格的線程先于優先級低的線程執行。

例如，通用操作系統可能會降低分配給優先級高的線程的優先級，或按照有利于系統內其他線程的公平原則，以動態方式調整優先級。因此，優先級高的線程就可能被優先級低的線程搶占。此外，大多數通用操作系統都具有無限期的分配潛伏期：系統內的線程越多，通用操作系統調度線程執行所需的時間就越久。其中任何一種因素都能導致優先級高的線程錯過最后期限，即使在速度很快的 CPU 上。

另一方面，在實時操作系統中，線程會按其優先級的順序執行。如果優先級高的線程準備運行，它能在很短且有限的時間間隔內，從正在執行的優先級低的線程那里接管 CPU。此外，優先級高的線程還能不間斷地運行直到完成任務為止——當然，除非它被優先級更高的線程搶占。這種眾所周知的基于優先級的搶占式調度，可確保優先級高的線程始終如一地滿足最后期限的要求，即使在其他線程爭奪 CPU 時間時。

搶占式內核

大多數通用操作系統的操作系統內核都不是搶占式的。因此，優先級高的用戶線程無法搶占內核調用，相反，它必須等待整個調用全部結束——即使是系統內優先級低的進程進行調用。此外，當驅動程序或其他系統服務(通常在內核調用中運行)以客戶端線程的名義執行時，操作系統通常會丟失所有優先級信息。這種系統行為會導致無法預料的延遲，而且會妨礙關鍵運行按時完成。

另一方面，在實時操作系統中，內核運行是可搶占的。雖然仍有一些時間窗無法搶占，但在設計精密的實時操作系統中，這些間隔非常短暫，通常大約僅幾百納秒。另外，實時操作系統會針對搶占推遲和中斷禁止的時限設置上限;這能保證軟件開發人員確定情況最糟的延遲期。

為實現這一目標，實時操作系統內核必須盡可能簡單、精致。實現這種簡單性的最佳途徑是設計一種只包含短執行路徑服務的內核。通過排除內核中任務集中的運行(如進程加載)并將其分配到外部進程或線程，實時操作系統的設計人員就能保證通過內核的最長的非搶占代碼路徑有上限。

在一些通用操作系統，內核增加了某種程度的可搶占性。但無法搶占的時間間隔仍然比常見實時操作系統的長得多;這種搶占間隔的長度取決于通用操作系統內核中包含的最長的關鍵模塊部分(如網絡)。另外，搶占式通用操作系統內核不能解決可能的無限期延遲情形，例如因為客戶端調用驅動程序或其他系統服務時丟失優先級信息。

避免優先級反轉的機制

即使在實時操作系統中，優先級低的線程也能在無意中阻止優先級高的線程訪問 CPU——這種情況被稱為優先級反轉。當出現無限期的優先級反轉時，可能會錯過關鍵的最后期限，進而導致系統運行異常和全面故障的結果。遺憾的是，在系統設計過程中人們往往會忽視優先級反轉。有很多優先級反轉的實例，包括 1997 年 7 月火星探路者項目遭受困擾的實例。

一般來說，當優先級不同的兩個任務共享資源，而優先級高的任務無法從優先級低的任務那里獲得資源時，就會出現優先級反轉。為防止這種狀況超過有限的時間間隔，實時操作系統可提供一種通用操作系統不具備的選擇機制，包括優先級繼承和優先級封頂模擬。我們不能單純地評價兩種機制的優劣，所以我們著重介紹優先級繼承的實例。

首先，我們必須考慮任務同步如何能造成阻塞，而阻塞反過來又如何導致優先級反轉。我們假設有任務 1 和任務 2 兩個任務正在運行，其中任務 1 具有較高的優先級。如果任務 1 準備執行，但必須等待任務 2 完成運行，就出現阻塞的狀況。同步化也會導致這種阻塞;例如，任務 1 和任務 2 共享由鎖或信號量控制的資源，任務 1 等待任務 2 對資源進行解鎖。或者，當任務 1 請求目前正由任務 2 使用的服務時，也會出現阻塞狀況。

 Michael Barr.“優先級反轉簡介”

阻塞允許任務 2 運行，直到任務 1 等待的條件出現為止(例如，任務 2 對兩個任務共享的資源解鎖)。此時，任務 1 可以執行。任務 1 須等待的總時間會隨最少時間、平均時間和最多時間變化。這種間隔就是阻塞因數。如果任務 1 必須滿足一定的時間限制，該因數就不能隨任何參數變化，如線程數或系統內的輸入。換句話說，必須限制阻塞因數。

現在，我們引入第三個任務(任務 3)——其優先級比任務 2 的高但比任務 1 的低(參見圖 1)。當任務 2 正在運行時，任務 3 準備運行，它會搶占任務 2，而任務 2 在任務 3 被阻塞或完成前都無法運行。當然，這樣會增加任務 1 的阻塞因數;也就是說，它會進一步延遲任務 1 的運行。搶占導致的總延遲就是優先級反轉。

實際上，可以有多個任務以這種方式搶占任務 2，從而導致連續阻塞的結果。在這種情況下，任務 2 可能被無限期地搶占，產生無限期的優先級反轉，導致任務 1 無法滿足其最后期限。

這時優先級繼承就會發揮作用。如果我們回到上述假設中，在同步期內使任務 2 以任務 1 的優先級運行，那么任務 3 就無法搶占任務 2，這樣就能避免優先級反轉的產生(參見圖 2)。

圖 1——當任務 3 搶占任務 2 時，任務 1 等待任務 2 完成運行。這進一步推遲了任務 1 的運行。 4　

圖 2——任務 2 繼承了任務 1 的優先級，因而阻止了任務 3 搶占任務 2。任務 3 不再推遲任務 1 的運行。

提供有保證的 CPU 可用性的分區調度

保證資源的可用性對許多系統而言都至關重要。如果某個關鍵子系統(如 CPU 周期)丟失，用戶就無法獲取該子系統提供的服務。例如，在拒絕服務 (DoS) 攻擊中，惡意用戶會利用需要優先級高的進程處理的請求攻擊系統。該進程會使 CPU 過載并導致其他進程的 CPU 周期匱乏，從而使用戶無法使用系統。

安全漏洞并非是導致進程匱乏的唯一原因。在許多情況下，增加系統的軟件功能都會導致系統“瀕臨危險邊緣”，導致現有應用程序的 CPU 時間匱乏。及時運行的應用程序或服務不再按預期或要求的那樣迅速響應。從歷史角度，解決這一問題的唯一途徑是更新硬件或對軟件進行重新編碼(或重新設計)——這兩種方法都無法讓人滿意。

為解決這些問題，系統設計人員需要一種可通過硬件或軟件執行 CPU 預算的分區計劃，以阻止進程或線程獨占其他進程或線程所需的 CPU 周期。實時操作系統正是執行 CPU 分區預算的最佳選擇，因為實時操作系統已經提供了對 CPU、內存和其他計算資源的集中訪問。

某些實時操作系統提供了固定分區調度算法。系統設計人員能利用這種調度算法對任務進行分組或分區，然后為每個分區分配一定比例的 CPU 時間。利用這種方法，任何既定分區內的任務消耗的 CPU 時間都不會超過該分區靜態確定的比例。例如，我們假設為分區分配了 30% 的 CPU。如果該分區內的進程隨后成為拒絕服務攻擊的目標，它會消耗不超過 30% 的 CPU 時間。這種分配限制確保了其他進程保持各自的可用性;例如，它能保證可訪問的用戶界面(如遠程終端)。因此，操作人員能訪問系統并解決問題——無需按動復位開關。 5

但是，這種方法也存在問題。由于調度算法是固定的，因此一個分區無法使用分配到另一個分區的 CPU 周期，即使這些分區未使用其分配的周期。這種方法會浪費 CPU 周期并阻止系統處理高峰需求。因此，系統設計人員必須使用更昂貴的處理器應對運行緩慢的系統，或限制系統能支持的功能數量。

自適應分區

另一種被稱作自適應分區的方法提供了更靈活的動態調度算法，從而有效克服了這些缺陷。與靜態分區一樣，自適應分區允許系統設計人員為單獨進程或一組進程預留 CPU 周期。因此，系統設計人員能保證一個子系統或分區上的負載不會影響其他子系統的可用性。而且，與靜態分區不同的是，自適應分區還能將空閑分區中的 CPU 周期以動態方式重新分配到可受益于額外處理時間的分區——只有當 CPU 滿載時，分區預算才會執行。因此，系統就能處理高峰需求并使利用率達到 100%，同時又能繼續享受資源保證帶來的收益。

同樣重要的是，自適應分區還能直接應用于先有系統，而無需重新設計代碼或修改代碼。例如，在 QNX Neutrino 中，系統設計人員只需啟動分區內已有的基于 POSIX 應用程序，實時操作系統的調度程序就會確保每個分區都會收到分配的預算。在每個分區內，會繼續根據基于優先級的搶占式調度算法對每項任務進行調度——應用程序不必更改其調度運行。此外，系統設計人員還能以動態方式重新配置分區，以精確調節系統實現最佳性能。

圖 3——自適應分區可阻止優先級高的任務消耗超過其分配的規定比例的 CPU，除非系統包含未使用的 CPU 周期。例如，任務 A 和任務 D 可在分配至分區 3 的時間內運行，因為任務 E 和任務 F 不需要剩余的 CPU 周期預算。 6

“組合”內核

通用操作系統(包括 Linux、Windows 和各種類型的 Unix 系統)通常都缺少我們目前介紹的實時機制。但供應商已開發出許多實時擴展組件和補丁，試圖填補這一空白。例如，有一種雙內核方法，其中的通用操作系統能以任務的形式在專用實時內核上運行(參見圖 4)。任何需要確定性調度的任務都會在該內核中運行，但其優先級要高于通用操作系統的優先級。因此，只要這些任務需要運行，它們就能搶占 Linux，而且只有在其工作完成后，才會向 Linux 釋放 CPU。

遺憾的是，實時內核中運行的任務只能有限地利用通用操作系統中現有的系統服務，如文件系統、網絡服務等。

實際上，如果實時任務向通用操作系統請求任何服務，它都會面臨同樣的搶占問題，這會阻止通用操作系統以確定方式運行。因此，必須針對實時內核創建新的驅動程序和系統服務，即使通用操作系統中已存在相同的服務。但是，多數通用操作系統為正常的非實時進程提供的受內存管理單元 (MMU) 保護的可靠環境卻無法惠及在實時內核中運行的任務。相反，它們會在無保護的內核空間運行。因此，任何含有公共編碼錯誤(如損壞的 C 指針)的實時任務都會輕易導致內核出現嚴重故障。這的確是一個問題，因為需要實時功能的大部分系統同樣需要極高的可靠性。

雙內核方法的不同實現使用不同的應用程序接口 (API) 使問題進一步復雜。在多數情況下，為通用操作系統編寫的服務無法輕易移植到實時內核中，而且針對一個供應商的實時擴展組件編寫的任務未必能在另一個供應商的實時擴展組件上運行。

圖 4——在常見的雙內核實現中，通用操作系統會作為優先級最低的任務在單獨的實時內核中運行。

這種解決方案指出了使通用操作系統支持實時運行的實際困難和復雜性。但這并非是關于實時操作系統和通用操作系統孰優孰劣的問題。通用操作系統(如 Linux、Windows 和各種 Unix 系統)都能以臺式機或服務器操作系統的形式正常運行。但是，當進入不符合其設計用途的確定運行環境中(如車載遠程信息處理裝置、醫療器械、實時控制系統和連續媒體應用)時，它們就會凸顯不足。 7

令調試和定制更輕松的源代碼

使用通用操作系統仍有一些好處，例如在 Linux 的開源模式下支持廣泛使用的應用程序接口 (API)。利用開源模式，軟件開發人員能針對應用程序的具體需求定制操作系統組件，從而能節約大量用于故障排解的時間。為保持這些優勢，實時操作系統的供應商應根據友好的商業授權許可條款，確保其源代碼易于訪問。

實時操作系統的架構也發揮了重要作用。例如，基于微內核設計的實時操作系統能從根本上簡化操作系統的定制過程。在微內核實時操作系統中，只有少數核心基本對象(如信號、計時器、調度程序)才會存在于內核中。所有其他組件(驅動程序、文件系統、協議棧、應用程序)都會以單獨的受內存保護的進程在內核外部運行;參見圖 5。因此，開發定制的驅動程序和其他與應用程序有關的操作系統擴展組件無需專門的內核調試程序或內核專家。實際上，作為用戶空間程序，開發這種操作系統擴展組件和開發標準應用程序一樣容易，因為開發人員都能使用標準、源代碼級工具對它們進行調試。

圖 5——在微內核實時操作系統中，系統服務作為標準的用戶空間進程運行，因而簡化了操作系統的定制任務。

例如，如果設備驅動程序試圖訪問其進程空間之外的內存，操作系統就能識別相關進程，指出故障位置并創建可使用源代碼級調試工具查看的進程轉儲文件。轉儲文件可包括調試程序確定導致故障的源代碼行所需的所有信息以及診斷信息(如數據項的內容和函數調用的歷史)。 8

這種架構還提供了絕佳的故障隔離和恢復功能：如果驅動程序、協議棧或其他系統服務出現故障，它可在不影響其他服務或損壞操作系統內核的情況下完成這種操作。實際上，“軟件監視程序”會持續監測此類事件，并能以動態方式重啟出現故障的服務，無需重啟整個系統或以任何方式干擾用戶。同樣，驅動程序和其他服務都能以動態方式停止、啟動或升級，無需關閉系統。

絕不可小看這些優勢——因為破壞實時性能的最大威脅就是不定期的系統重啟!甚至軟件更新中包含的以可控制的方式進行的預定重啟都會干擾系統運行。為保證一直滿足最后期限的要求，軟件開發人員必須使用即使在出現軟件故障或進行服務升級時，也能保持連續可用的操作系統。

戰略決策

實時操作系統能使復雜的應用程序變得可預測而且可靠;實際上，實時操作系統實現的精確時間控制，就是通用操作系統無法提供的可靠功能。(如果基于通用操作系統的系統由于計時錯誤而無法正常運行，我們可以合理認為該系統不可靠。)選擇正確的實時操作系統本身仍然是一項復雜的任務。實時操作系統的底層架構是重要標準，而其他因素也不例外。具體包括：

• 調度算法的靈活選擇——實時操作系統支持調度算法選擇(先入先出 [FIFO] 調度、循環調度、偶發調度等)嗎?您能根據每個線程分配這些算法嗎?或者實時操作系統要求您針對系統中的所有線程分配一種算法嗎?

• 時間分區——實時操作系統支持能為進程提供有保證的 CPU 周期預算的時間分區嗎?這種保證簡化了對多個開發團隊或供應商的子系統進行集成的工作。它們還能確保關鍵任務在系統遭到拒絕服務 (DoS) 攻擊和其他惡意攻擊時，保持可用并滿足其最后期限的要求。

• 支持多核處理器——向多核處理器遷移的功能已成為各種高性能設計的基本要求。實時操作系統是否支持多重處理模式(對稱多重處理、不對稱多重處理、混合多重處理)的選擇，并幫助您最大限度地利用多核硬件?允許您診斷和優化多核系統性能的系統跟蹤工具支持實時操作系統嗎?如果沒有能顯示資源競爭、線程的過度遷移和其他多核設計常見問題的工具，那么對多核系統進行優化就會變得異常麻煩和費時。

• 遠程診斷工具——由于許多嵌入式系統都不允許有故障時間，因此實時操作系統供應商應提供能在不中斷系統服務的情況下分析系統運行的診斷工具。尋找能提供運行分析工具(用于系統剖析、應用程序剖析和內存分析的)的供應商。

• 開放的開發平臺——實時操作系統供應商能否提供基于開放平臺(如 Eclipse)的開發環境，允許您“插入”您最喜歡的第三方工具以便進行建模、版本控制等工作?或者，開發環境是基于專有技術的嗎?

• 圖形用戶界面——實時操作系統使用基元圖形庫嗎?或者它提供了高級圖形處理功能(如多層界面、基于 Flash 的人機界面、多目標顯示、3D 加速渲染和真正的窗口系統)嗎?您能輕松地自定義圖形用戶界面的視覺效果嗎?圖形用戶界面能同時顯示和輸入多種語言(中文、朝鮮語、日語、英語、俄語等)嗎?2D(如 Flash)和 3D(如 OpenGL ES)應用程序能輕松共享同一屏幕嗎? 9

• 標準應用程序接口——實時操作系統限制您使用專有應用程序接口嗎?或者它提供了對標準應用程序接口(如 POSIX 和 OpenGL ES)的認證支持，使各種運行環境之間的代碼移植變得更容易?實時操作系統還提供對應用程序接口的綜合支持嗎?還是只支持一小部分已定義接口的子集?

• 源代碼——實時操作系統供應商允許您輕松訪問源代碼以簡化調試過程，并幫助您根據具體需求定制實時操作系統服務嗎?

• 面向數字媒體的中間件——對數字媒體的靈活支持已成為各種嵌入式系統(如車載收音機、醫療設備、工業控制系統、媒體服務器以及消費電子產品)的設計要求。系統可能需要處理多種媒體資源(如 USB 閃存、MP3 播放器、網絡流媒體、藍牙電話等)，分辨多種數據格式(如 MP3、WMA、AAC、MPEG-2、MPEG-4 等)并支持各種數字版權管理 (DRM) 方案。通過為數字媒體提供設計精密的中間件，實時操作系統供應商能避免連接多媒體資源、組織數據以及初始化適當的數據處理路徑所需的大量軟件工作。另外，設計完善的中間件解決方案還能靈活支持新的數據源(如下一代 iPod)，無需修改用戶界面或其他軟件組件。

選擇實時操作系統是項目團隊的戰略性決策。如果實時系統供應商針對以上問題給出了清楚的答案，那么您離現在和將來選擇到完全適用的實時操作系統又近了一步。