提高實時作業系統的實時效能和可靠性策略論文

　　實時作業系統是保證在一定時間限制內完成特定功能的作業系統。實時作業系統有硬實時和軟實時之分，硬實時要求在規定的時間內必須完成操作，這是在作業系統設計時保證的;軟實時則只要按照任務的優先順序，儘可能快地完成操作即可。我們通常使用的作業系統在經過一定改變之後就可以變成實時作業系統。以下是小編今天為大家精心準備的：提高實時作業系統的實時效能和可靠性策略相關論文，內容僅供參考，歡迎閱讀!

　　提高實時作業系統的實時效能和可靠性策略全文如下：

　　對很多嵌入式系統來說，一個設計良好的實時作業系統***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等進行的獨立測試證實，和傳統的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。