如今，高性能處理器和通用操作系統實時升級的速度，似乎再次引發了嵌入式系統是否仍需要RTOS的討論。答案沒有改變：在相對低端的處理器上只有真正的RTOS能提供一些保障，也就意味著，這些OS可以留在嵌入式環境中。

■ 究竟何時需要實時操作系統？

大多數嵌入式項目是否仍需要實時操作系統？

考慮到當今高性能處理器的速度以及適用于Linux，Windows和其他通用操作系統（GPOS）的實時補丁的可用性，這是一個很好的問題。答案在于嵌入式設備的本質。這些設備通常以數千，甚至數百萬桃這種規模下生產，即使每套硬件成本降低1美元，也能為制造商節省一筆小財富。換言之，這些設備無法負擔數百萬赫茲處理器的成本（更不用說散熱了）。例如，在汽車遠程信息處理市場，典型的32位處理器的運行頻率約為600Mhz，遠低于臺式機和服務器中常見的處理器。在這樣的環境中，設計用于從低端硬件中提取極其快速、可預測的響應時間的實時操作系統有巨大的經濟優勢。

除了節省成本外，實時操作系統提供的服務使許多計算問題更容易解決，特別是當多個活動競爭一個系統的資源時。例如，考慮一個用戶期望（或需要）立即響應輸入的系統。使用實時操作系統，開發人員可以保證由用戶發起的操作將優先于其他系統活動執行，除非必須首先執行更重要的活動（例如，有助于保護用戶安全的操作）。還要考慮一個必須滿足服務質量（QoS）要求的系統，例如顯示實時視頻的設備。如果設備的內容交付的任何部分都依賴于軟件，那么它會以用戶認為不可接受的速度體驗掉幀，設備是不可靠的。然而，通過實時操作系統，開發人員可以精確地控制軟件進程的執行順序，并確保以適當和一致的速率進行回放。

■ 實時操作系統不公平

在嵌入式行業中，對實時“硬”時間的需求仍然很普遍。問題是：實時操作系統有什么是GPOS沒有的？而且，對于某些GPOS來說，現在的實時擴展有多有用？他們能提供一個合理的實時操作系統性能嗎？

讓我們從任務調度開始。在GPOS中，調度程序通常使用“公平”策略將線程和進程分派到CPU。這樣的策略可以實現桌面和服務器應用程序所需的高整體吞吐量，但不能保證高優先級、時間緊迫的線程優先于低優先級的線程執行。例如，GPOS可能會降低分配給高優先級線程的優先級，或者為了保證系統中其他線程的公平性而動態調整線程的優先級。因此，高優先級線程可能被低優先級線程搶占。

此外大多數GPOS具有無界的調度延遲：系統中的線程越多，GPOS調度一個執行線程所需的時間就越長，這些因素中的任何一個都可能導致高優先級線程錯過最后期限，即使是在高速CPU上。此外，高優先級線程可以不間斷地運行，直到它完成它需要做的事情，當然，除非它被一個更高優先級的線程搶占。這種方法被稱為基于優先級的搶占式調度，允許高優先級線程滿足其最后期限，即使許多其他線程正在爭奪CPU時間。

■ 搶占式內核

在大多數GPOS中，os內核是不可搶占的。因此，高優先級用戶線程永遠不能搶占內核調用，而是必須等待整個調用完成—即使調用是由系統中優先級最低的進程調用的。此外，當驅動程序或其他系統服務（通常在內核調用中執行）代表客戶端線程執行exe剪切時，所有優先級信息通常都會丟失。這種行為會導致不可預知的延遲，并阻止關鍵活動按時完成。另一方面，在實時操作系統中，內核操作是可搶占的。與在GPOS中一樣，在時間窗口中可能不會發生搶占，在設計良好的實時操作系統中，這些窗口非常短，通常是數百納秒的順序。

此外，實時操作系統對搶占延遲和中斷禁用的時間設置了一個上限；這個上限允許開發人員確定最壞情況下的延遲。為了實現一致的可預測性和關鍵活動的及時完成這一目標，實時操作系統內核必須盡可能簡單優雅。實現這種簡單性的最佳方法是設計一個內核，該內核只包含具有短執行路徑的服務。

通過從內核中排除工作密集型操作（例如進程加載）并將其分配給外部進程或線程，實時操作系統設計器可以幫助確保通過內核的最長不可搶占代碼路徑上存在上限。在一些GPOS中，內核增加了一定程度的搶占性。然而，不可能發生搶占的時間間隔仍然比典型實時操作系統中的時間間隔長得多；任何此類搶占時間間隔的長度將取決于GPOS內核中任何模塊（例如，網絡）的最長關鍵部分。此外，一個可搶占的GPOS內核不會處理其他可能造成無限延遲的條件，例如，當客戶端調用驅動程序或其他系統服務時發生的優先級信息丟失。

■ 避免優先級反轉

在GPOS中，甚至在實時操作系統中，低優先級線程可能無意中阻止高優先級線程訪問cpu，這種情況稱為優先級反轉。當發生無限優先級反轉時，可能會錯過關鍵的最后期限，從而導致從異常系統行為到徹底失敗的結果。不幸的是，在系統設計過程中，優先級反轉常常被忽略。優先級反轉的例子很多，其中包括1997年7月火星探險者項目。

一般來說，當兩個不同優先級的任務共享一個資源，而高優先級的任務無法從低優先級的任務獲得資源時，就會發生優先級反轉。為了防止這種情況超過有限的時間間隔，實時操作系統可以提供GPOS中不可用的機制選擇，包括優先級繼承和優先級上限模擬。我們不可能公正地對待這兩種機制，所以讓我們關注一個優先級繼承的例子。。首先，我們必須考慮任務同步如何導致阻塞，以及阻塞如何反過來導致優先級反轉。假設兩個任務正在運行，任務1和任務2，并且任務1具有更高的優先級。

如果任務1已準備好執行，但必須等待任務2完成活動，則會阻塞。此阻塞可能是由于同步造成的；例如，任務1和任務2共享由鎖或信號量控制的資源，而任務1正在等待任務2解鎖該資源。或者，可能是因為任務1正在請求任務2當前使用的服務。阻塞允許任務2運行，直到發生任務1正在等待的條件（例如，任務2解鎖兩個任務共享的資源）。此時，任務1開始執行。任務1必須等待的總時間稱為阻塞因子。

如果任務1要滿足其任何時間限制，則此阻塞因子不能隨任何參數（例如線程數或系統輸入）而變化。換句話說，阻塞因子必須是有界的。現在讓我們介紹第三個任務，任務 3，它的優先級高于任務 2，但低于任務 1（參見圖1）。如果任務3在任務2執行時準備好運行，則它將搶占任務2，并且任務2將無法再次運行，直到任務3阻塞或完成。當然，這個新任務會增加任務1的阻塞因子；也就是說，它會進一步延遲任務1的執行。搶占引入的總延遲是一個優先級反轉。

圖1 ?任務1正在等待任務2完成一個活動，這時任務3搶占了任務2。此新任務進一步延遲任務1的執行 實際上，多個任務可以通過這種方式搶占任務2，從而產生一種稱為鏈阻塞的效果在這種情況下，任務2可能會被無限期搶占，從而產生無限的優先級反轉，并導致任務1無法滿足其任何最后期限。 這就是優先級繼承的來源。如果我們返回到我們的場景，并使任務2在同步期間以任務1的優先級運行，那么任務3將無法搶占任務2，從而避免產生優先級反轉（參見圖2）。 ?

圖2 任務2繼承任務1的較高優先級，從而防止任務3搶占任務2。任務3不再延遲任務1的執行。 ■ 分區調度器
?

對于許多系統，保證資源可用性是至關重要的。如果一個關鍵的子系統被剝奪了，比如說，CPU周期，那么這個子系統提供的服務對于用戶來說就變得不可用了。例如，在拒絕服務（DoS）攻擊中，惡意用戶可以用需要高優先級進程處理的請求轟炸系統。這個進程可能會使CPU超載，使其他進程的CPU周期中斷，從而使系統對用戶不可用。安全漏洞并不是進程饑餓的唯一原因。在許多情況下，向系統添加軟件功能會將系統推向“崩潰的邊緣”，并使現有的應用程序占用大量CPU時間。及時運行的應用程序或服務不再按預期或要求作出響應。從歷史上看，解決這個問題的唯一辦法要么是改造硬件，要么是重新編碼（或重新設計）軟件——兩者都是不受歡迎的選擇。

為了解決這些問題，系統設計人員需要一個分區方案，通過硬件或軟件強制執行CPU運算，以防止進程或線程獨占其他進程或線程所需的CPU周期。由于實時操作系統已經提供了對CPU、內存和其他計算資源的集中訪問，所以實時操作系統是執行CPU分區運算的最佳選擇。有些實時操作系統提供一個固定的分區調度器。使用此調度器，系統設計人員可以將任務劃分為組或分區，并為每個分區分配一定百分比的CPU時間。使用這種方法，任何給定分區中的任務消耗的CPU時間都不會超過分區靜態定義的百分比。例如，假設一個分區分配了30%的CPU。如果該分區中的進程隨后成為拒絕服務攻擊的目標，那么它消耗的CPU時間將不超過30%。這個分配的限制允許其他分區保持其可用性;例如，它可以確保用戶界面（例如遠程終端）保持可訪問性。因此，操作員可以訪問系統并解決問題，而不必按下復位開關。

然而，這種方法有一個問題。因為調度算法是固定的，所以一個分區永遠不能使用分配給其他分區的CPU周期，即使這些分區沒有使用它們分配的周期。這種方法會浪費CPU周期，并阻止系統處理峰值需求。因此，系統設計者必須使用更昂貴的處理器，容忍更慢的系統，或者限制系統能夠支持的功能數量。

■ 自適應分區

另一種分區方案稱為自適應分區，它通過提供更動態的調度算法來解決靜態分區的缺點。與靜態分區一樣，自適應分區允許系統設計人員為一個進程或一組進程保留CPU周期。因此，設計人員可以保證一個子系統或分區上的負載不會影響其他子系統的可用性。但是，與靜態方法不同，自適應分區可以動態地將CPU周期從不繁忙的分區重新分配給可以從額外處理時間分區預算中受益的分區，只有在CPU完全加載時才強制執行。因此，系統可以處理峰值調度應用程序不需要改變它們的調度行為。此外，設計人員可以動態地重新配置分區，以優化系統的性能。

■ “雙重”內核

包括Linux、Windows和各種風格的unix在內的GPOS通常缺乏迄今為止討論的實時機制。為了填補這個空白，GPOS供應商開發了大量的實時擴展和補丁。例如，有一種雙內核方法，在這種方法中，GPOS作為一個任務運行在一個專用的實時內核之上（參見圖4）。因此，這些任務可以在GPOS需要執行時搶占它們，并且僅在GPOS完成工作時才將CPU交給它們。

不幸的是，在實時內核中運行的任務只能有限地使用GPOS中的現有系統服務——文件系統、網絡等等。事實上，如果某個實時任務向GPOS請求任何服務，那么該任務將受到相同的優先處理要求并實現100%的利用率，同時享受資源保障的好處。同樣重要的是，自適應分區可以覆蓋在現有系統之上，而無需重新設計或修改代碼。系統設計人員可以簡單地在分區中啟動現有的基于POSIX的應用程序，而實時操作系統調度器可以確保每個分區都收到分配的預算。在每個分區中，每個任務都根據基于優先級的搶占規則進行調度。

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

　　阻止GPOS進程確定性行為的問題。因此，必須專門為實時內核創建新的驅動程序和系統服務，即使GPOS已經有了類似的服務。而且，實時內核中運行的任務無法從大多數GPOS為常規，非實時流程提供的受MMU保護的強大環境中受益。 相反，它們在內核空間中不受保護地運行。因此，包含常見編碼錯誤（例如損壞的C指針）的實時任務很容易導致致命的內核錯誤。這是一個問題，因為大多數需要實時的系統也需要很高的可靠性。更復雜的是，雙內核方法的不同實現使用不同的api。在大多數情況下，為GPOS編寫的服務不能輕松地移植到實時內核，為一個供應商的實時擴展編寫的任務可能不能在另一個供應商的擴展上運行。

　　圖4 在典型的雙內核實現中，GPOS作為單獨的實時內核中優先級最低的任務運行。

　　這些解決方案指出了使GPOS能夠支持實時行為的真正困難和巨大范圍。這并不是“實時操作系統好，GPOS壞”的問題。諸如Linux、Windows和各種unix等GPOS都可以很好地作為桌面或服務器操作系統使用。

　　然而，當它們被迫進入非為環境而設計的確定性環境時，如車載遠程信息處理單元、醫療器械、實時控制系統和連續媒體應用程序，它們就不能滿足要求。

　　■ 擴展操作系統 特定于應用程序的需求

　　無論它們在確定性環境中的缺點是什么，使用它們都是有好處的。

　　這些優點包括對廣泛使用的api的支持，以及對Linux的開放源碼模型的支持。使用開放源碼，開發人員可以根據特定于應用程序的需求定制操作系統組件，從而節省大量的故障排除時間。實時操作系統供應商不能忽視這些好處。對POSIX api （Linux和各種風格的unix使用的相同api）的廣泛支持是重要的第一步。提供文檔良好的源代碼和定制工具包，以滿足嵌入式開發人員的特定需求和設計挑戰，也是如此。

　　實時操作系統的架構也起了作用。例如，基于微內核設計的實時操作系統可以使操作系統定制的工作從根本上比其他體系結構更容易實現。在微內核實時操作系統中，只有一小部分基本操作系統服務（例如，信號、計時器、調度）駐留在內核本身中。所有其他組件——驅動程序、文件系統、協議棧、應用程序——作為獨立的、受內存保護的進程在內核之外運行（參見圖5）。事實上，作為用戶空間程序，這樣的擴展變得和標準應用程序一樣容易開發，因為它們可以用標準的源代碼級工具和技術進行調試。

　　圖5 在微內核實時操作系統中，系統服務作為標準的用戶空間進程運行，從而簡化了操作系統自定義的任務。 例如，如果設備驅動程序試圖訪問其進程容器之外的內存，操作系統可以識別負責的進程，指示錯誤的位置，并創建一個可以用源代碼級調試工具查看的進程轉儲文件。轉儲文件可以包含調試器識別導致問題的源代碼所需的所有信息，以及諸如數據項的內容和函數調用歷史等診斷信息。

　　這種體系結構還提供了更好的故障隔離和恢復：如果驅動程序、協議棧或其他系統服務出現故障，它可以在不破壞其他服務或操作系統內核的情況下進行故障隔離和恢復。事實上，“軟件監督”可以持續監視此類事件，并動態地重新啟動違規服務，而無需重新設置整個系統或以任何方式涉及用戶。類似地，可以動態地停止、啟動或升級驅動程序和其他服務，而無需關閉系統。

　　這些好處不應該被忽視——對實時性能的最大破壞是計劃外的系統重新啟動！即使計劃重新啟動以合并軟件升級也會干擾操作，盡管是以一種受控的方式。為了確保最后期限總是能夠滿足，開發人員必須使用能夠持續可用的操作系統，即使在軟件故障或服務升級的情況下也是如此。

　　■ 一個戰略決策

　　實時操作系統有助于使復雜的應用程序既可預測又可靠；事實上，實時操作系統對時間的精確控制增加了GPOS無法實現的可靠性。（如果基于GPOS的系統由于不正確的計時行為而不能正確工作，那么我們可以合理地說該系統是不可靠的。）然而，選擇正確的rtos本身可能是一項復雜的任務。實時操作系統的底層架構是一個重要的標準，但其他因素也是如此。其中包括：

　　? 靈活選擇調度算法-實時操作系統是否支持選擇調度算法（FIFO，循環調度，零星調度等？）開發人員可以按線程分配算法，還是實時操作系統強迫他為系統中的所有線程分配一種算法？

　　? 時間分區-實時操作系統是否支持時間分區，以便為進程提供一定百分比的CPU周期？這樣的保證簡化了從多個開發團隊或供應商集成子系統的工作。它們還可以確保關鍵任務仍然可用并滿足其最后期限，即使系統受到拒絕服務（DoS）攻擊和其他惡意攻擊。

　　? 支持多核處理器——遷移到多核處理器的能力已經成為各種高性能設計的基礎。實時操作系統是否支持多處理模型（對稱多處理、非對稱多處理、綁定多處理）的選擇，以幫助開發人員充分利用多核硬件？系統跟蹤工具是否支持實時操作系統，以便開發人員診斷和優化多核系統的性能？如果沒有能夠突出資源爭用、過度的線程遷移和多核設計中常見的其他問題的工具，優化多核系統很快就會成為一項繁重、耗時的任務。

　　? 用于遠程診斷的工具-由于許多嵌入式系統無法容忍停機，因此實時操作系統供應商應提供診斷工具，可以分析系統的行為而不會中斷系統提供的服務。尋找一個提供用于系統分析，應用程序分析和內存分析的運行時分析工具的供應商。

　　? 開放式開發平臺-實時操作系統供應商是否提供基于開放式平臺（如Eclipse）的開發環境，從而允許開發人員“插入”他們喜歡的第三方工具來進行建模，版本控制等？還是開發環境基于專有技術？

　　? 圖形用戶界面-實時操作系統是使用原始圖形庫，還是支持多種人機界面技術（HTML5、Qt、OpenGL ES等），并提供高級圖形功能，如多層界面、多頭顯示、加速3D渲染和真正的窗口系統？gui的外觀和感覺可以很容易地定制嗎？guis能同時顯示和輸入多種語言（漢語、韓語、日語、英語、俄語等）嗎？二維和三維應用程序可以輕松地共享同一屏幕嗎？標準api-實時操作系統是將開發人員鎖定到專有api中，還是為posix和opengl es等標準api提供經認證的支持，從而使代碼更易于在其他環境之間進行移植？此外，實時操作系統是否提供了對api的全面支持，或者它只支持定義接口的一小部分？

　　? 標準api-實時操作系統是將開發人員鎖定到專有api中，還是為posix和opengl es等標準api提供經認證的支持，從而使代碼更易于在其他環境之間進行移植？此外，實時操作系統是否提供了對api的全面支持，或者它只支持定義接口的一小部分？

　　? 針對數字媒體的中間件——對數字媒體的靈活支持正在成為一系列嵌入式系統的設計要求，包括汽車收音機、醫療設備、工業控制系統、媒體服務器，當然還有消費電子產品。一個系統可能需要處理多個媒體源（設備、流等），理解多個數據格式，并支持多種drm方案。通過為數字媒體提供設計良好的中間件，實時操作系統供應商可以消除連接到多個媒體源、組織數據和啟動適當的數據處理路徑所需的大量軟件工作此外，一個設計良好的中間件解決方案將有靈活性來支持新的數據源，如下一代iPod，而不需要修改用戶界面或其他軟件組件。

　　對于任何項目團隊來說，選擇實時操作系統都是一項戰略決策。實時操作系統供應商為上述問題提供清晰的答案后，您將可以選擇現在和將來最適合的。

　　編輯：黃飛