即時​作業系統 (RTOS: Real-​Time Operating System)

綜覽

本文​說明 Real-​Time 作業系統 (RTOS) 的​作業​原理​及其​如何​有效​運用​在​量​測​與​控制​應用,​並​比較​這類​作業系統​與 Windows 等​一般​用途​之​標準​作業系統​之間​的​差異。

目錄

  1. 即時​作業系統 (Real-​Time Operating System, RTOS) 簡介
  2. Real-​Time 系統​應用​程式​範例
  3. Real-​Time 作業系統​與​一般​用途​作業系統​的​差異
  4. 後續​步驟

即時​作業系統 (Real-​Time Operating System, RTOS) 簡介

以下​各節​概述 Real-​Time 作業系統​的​基本​概念​與​相關​詞彙。 看完​本文​內容​後,​建議​您​接著​瀏覽 Building a Real-​Time System with NI Hardware and Software (使用 NI 軟​硬體​打造 Real-​Time 系統) (英文),​以​深入​了解 NI 如何​協助​您​在​最短​的​時間​內​打造​出​優異​的 Real-​Time 即時​系統。​在​了解​即時​作業系統​之前,​我們​先來​看看​普通​的​作業系統​是​什麼。

作業系統

一般​來說,​作業系統 (OS) 管理​電腦​的​硬體​資源,​以及​電腦​上​執行​的​各項​託管​應用​程式,​負責​程序、​記憶體、​檔案​以及​輸入/ 輸出​設備​等等​的​管理,​是​電腦​系統​中的​核心。​Windows、​Mac OS 與​Linux​便是​最​受歡迎​的​幾種​個人​電腦​作業系統。

Real-​Time 作業系統 (RTOS) 是​什麼?

特別​設計​的 Real-​Time 作業系統 (RTOS) 不但​能​執行​一般​作業系統​的​功能,​還能​在​極為​精確​的​時間​點​以​高度​可靠​的​方式​執行​應用​程式。 對​量​測​與​自動化​系統​來說,​由於​停機​事件​的​成本​高昂​或​程式​延遲​可能​引發​安全​風險,​這項​能力​格外​重要。

為了​達成​「即時」​(real-​time) 目標,​作業系統​必須​為​所​執行​的​每一​項​關鍵​作業​分配​已知​的​最大​時間 (或者​至少​要​能​在​大多數​時候​保證​提供​最大​時間)。 其中​的​部分​作業,​包括​作業系統​呼叫​與​中斷​處理。 能夠​針對​這些​作業​項目​絕對​保證​提供​最大​時間​的​作業系統,​一般​稱為​「嚴格​的 real-​time」​(hard real-​time);​而​只能​保證​在​大多數​時候​提供​最大​時間​的​作業系統,​則​稱為​「彈性​的 real-​time」​(soft real-​time)。 在​實務​上,​這類​嚴格​的​分類​並​無法​充分發揮​效用 - 每一個 RTOS​解決​方案​都有​自己​專屬​的​效能​特性,​使用者​必須​仔細​研究​並​分辨​其​特性​差異。

為了​幫助​您​充分​理解​這些​概念,​我們​舉​以下​例子​說明。 想像​您​正​為一​款​新車​設計​安全​氣囊​系統。 在此​案例​中,​只要​觸發​時間​點​有​任何​差池 (造成​安全​氣囊​過​早​或​過​晚​充氣),​就​可能​導致​嚴重​事故​並​造成​人員​傷亡。 這時​就​需要​嚴格​的 Real-​time 作業系統;​系統​設計師​必須​保證​每一​次​安全​氣囊​觸發​操作​都不會​超過​特定​的​時間​限制。 另一方面,​假設​您​是​要​設計​一​款​能夠​接收​串​流​視訊​的​行動​電話,​那麼​偶爾​遺失​少量​資料​也​無關緊要,​不過​如果​能夠​跟上​視訊​串​流​的​速度​更好。 在​這種​應用​情況​中,​彈性​的 Real-​Time 作業系統​就​足夠​應付​所需。

重點​在於,​只要​程式設計​得當,​RTOS 就​能​保證​在​一致​的​時間​點​執行​程式。 要​達成​這項​目標,​Real-​Time 即時​作業系統​必須​賦予​程式​設計師​高度​控制​權限,​使​其​能​完全​掌控​工作​優先​順序;​而且,​為​確保​重要​的​交付​期​程​不受​耽誤,​一般​也會​允許​程式​設計師​進行​檢查。

一般​用途​的​作業系統,​如​最​受歡迎​的​個人​電腦​作業系統 (像是 Windows) 不同​於 Real-​Time 作業系統 (RTOS)。 以下​小節​將​深入探討 Real-​Time 即時​作業系統​與​一般​用途​的​作業系統​之間​的​技術​差異,​需要​注意​的是,​這​兩種​作業系統​各有​優缺點。 Windows 等​作業系統​主要​透過​運行​各種​程式​與​服務​來​即時​回應​使用者​需求 (以​確保​「公平性」),​而 Real-​Time 即時​系統​則是​需要​在​精準​的​時間​控制​下,​可靠​地​執行​關鍵​應用​程式 (依照​程式​設計師​制訂​的​優先​順序​來​執行)。

作業系統​重要​詞彙​與​概念

作業​決定​性:在​嚴格​的 Real-​Time 作業系統​上​執行​的​應用​程式 (或​關鍵​的​應用​程式​片段),​如果​能夠​保證​出錯​數量​在​執行​時間​內​不​超出​限定​範圍​的​話,​表示​具備​決定​性​特質。

彈性​的/​嚴格​的 Real-​Time:能夠​針對​所有​作業​保障​絕對​最大​時間​的​作業系統,​可​稱為​嚴格​的 Real-​Time 作業系統。 反之,​通常​在​特定​時間​內​完成​作業​的​作業系統,​可​稱為​彈性​的 Real-​time。

抖動:某​項​工作​在​後續​執行​程式​或​迴圈​的​反覆​運算​過程​期間​的​出錯​數量,​稱為​「抖動」。 最佳​化​的 Real-​Time 作業系統​只要​程式設計​得當,​就​可​達到​低​度​的​抖動​目標;​這樣​每項​工作​每次​執行​時​所需​的​時間​就會​非常​接近。

圖 1. 抖動​是​第一次​執行​工作​與​後續​反覆​運算​的​時間​差​量​測​值。 最佳​化​的 Real-​Time 作業系統​可​有效​減少​抖動​情況。

 

回到​頂端

Real-​Time 系統​應用​程式​範例

Real-​Time 作業系統​主要​用於​兩大類​應用:​事件​回應​與​閉​迴圈​控制。 事件​響應​應用 (像是​對​組​裝​線上​零件​進行​自動化​視覺​檢查) 需要​在​特定​時間​範圍​內​對​激​源​進行​響應。 舉例來說,​在此​視覺​檢查​系統​中,​經過​組​裝​線​的​每一​項​零件​都​必須​拍照​並​進行​分析,​才能​進入​下​個​階段。

藉由​對​嚴格​的 Real-​Time 作業系統 (RTOS) 上所​執行​的​應用​程式​審慎​地​進行​程式設計,​負責​事件​響應​應用​的​設計​人員​就​能​保證​提供​決定​性的​響應 (在​特定​最大​時間​範圍​內)。 在​零件​檢查​範例​上,​使用​一般​用途​的​作業系統​可能會​讓​零件​無法​及時​接受​檢查 - 進而​拖延​組​裝​線​作業​時間,​導致​必須​丟棄​零件,​或是​送出​可能​有​瑕疵​的​零件。

相反​地,​閉​迴圈​控制​系統 (例如​汽車​自動​巡航​控制​系統) 會​持續​處理​反饋​資料​以​調整​一​或​多項​輸出。​因為​每一​項​輸出​值​皆​取決於​固定​時間​範圍​內​的​輸入​資料,​因此​必須​符合​迴路​截止​日期​要求​才能​確保​產出​正確​的​輸出​值。 當​自動​巡航​控制​系統​無法​決定​特定​時間​點​的​調節​設定​時,​會有​何​後果? 再說​一遍,​嚴格​的 Real-​Time 作業系統​可以​保證​在​一致​的​時間​範圍​內 (與​最糟​情況​下​固定​的​最大​時間​範圍) 處理​控制​系統​輸入​資料。

另外​值得​注意​的是,​許多​執行​時間​必須​拉長​的​應用​程式,​會​因為​可靠​的​即時​作業系統​而​受益​良​多。 因為​系統​通常​只​執行​最少​的​軟體​集合 (而​非​同時​執行​許多​應用​程式​與​程序),​這類​系統​便​非常​適合​應用​在​需要 24 小時​全年​無休​運作​的​系統,​或是​不​允許​發生​停機​或是​停機​成本​高昂​的​系統。

如果​您​考慮​在​未來​的​專案​上​使用 Real-​Time 作業系統,​請​參閱​以下​文件:​Do I Need a Real-​Time System?

(我​需要​一套 Real-​Time 系統​嗎?) (英文)

回到​頂端

Real-​Time 作業系統​與​一般​用途​作業系統​的​差異

常見​作業系統​如 Microsoft Windows 與 Mac OS 之類​是​極佳​的​作業​平台,​可用​以​開發​並​執行​非​關鍵​的​量​測​與​控制​應用。 然而,​因為​這些​作業系統​是​針對 Real-​Time 作業系統​以外​的​其他​用途​所​設計,​因此​並不​適於​執行​需要​精確​時間​控制​或​要求​更多​連續​運作​時間​的​應用​程式。 本節​將​同時​指出​存在​這​兩種​作業系統​之間​的​一些​運作​原理​相關​之​重大​差異,​並​說明​設計 Real-​time 應用​程式​之際​可能​發生​的​各種​情況。

設定​優先​順序

在​設計​應用​程式​時,​大多數​作業系統 (任何​類型) 都​允許​程式​設計師​為​整體​應用​程式 (甚至​是​為​應用​程式​或​執行​緒​內​的​其他​工作) 指定​優先​項目。 這些​優先​順序​是​給​作業系統​參考​的​訊號,​代表​設計​人員​認為​是​最​重要​的​作業​項目。 其​用意​在於​假設​同時​有​兩項​以上​的​工作​準備​執行,​作業系統​將從​優先​順序​較高​的​工作​開始​執行。

在​實務​上,​一般​用途​的​作業系統​不會​每次​都​嚴格​遵守​這些​程式設計​優先​順序。 因為​一般​用途​的​作業系統​經過​最佳​化​後,​可​同時​執行​多種​應用​程式​與​程序,​它們​通常​會​確保​每一​項​工作​至少​會​分配​到​一些​處理​時間。 因此,​低​優先​順序​的​工作​有時候​會將​自身​優先​順序​提高,​以便​比​其他​較高​優先​順序​的​工作​更​早​執行。 此舉​可​確保​每一​項​工作​都能​獲得​一些​執行​時間,​但​缺點​是​無法​讓​設計​人員​百分之百​滿意。

相較​之下,​Real-​Time 即時​系統​則​較為​嚴格​遵守​程式​設計師​所​制訂​的​優先​順序。 在​大多數 Real-​Time 作業系統​中,​當​高​優先​順序​工作​用​掉了 100% 的​處理器​資源​時,​必須​等到​該​工作​完成​作業,​才能​輪到​其他​低​優先​順序​的​工作​進行。 因此,​Real-​time 系統​設計​人員​在​設計​應用​程式​時,​必須​仔細​斟酌​各個​程式​的​優先​順序。 在​典型​的 Real-​time 應用​程式​中,​設計​人員​會將​具有​時效性​的​程式碼 (例如,​事件​響應​或​控制​碼) 置​入​具有​極高​優先​順序​的​區段​中。 其他​重要性​較低​的​程式碼 (例如​記錄​至​磁碟​或​網路​通訊),​則會​與​優先​順序​較低​的​工作​混合​在​同​一個​區段。

中斷​潛時

中斷​潛​時​指​的是,​裝置​產生​中斷​到​獲得​服務​之間​所​經過​的​時間​量​測​值。 一般​用途​的​作業系統​回應​特定​中斷​所需​的​時間​可能​每次​都​不同,​但是 Real-​Time 作業系統​則​必須​保證​所有​中斷​必須​在​一定​的​最大​時間​範圍​內​獲得​服務。 換句話說,​Real-​Time 作業系統​的​中斷​潛​時​必須​受到​約束。

效能

一般人​常有​的​錯誤​觀念​是,​Real-​Time 作業系統 (RTOS) 的​效能​必定​優於​其他​一般​用途​的​作業系統。 雖然​在​某些​情況​中,​Real-​Time 作業系統​因為​應用​程式​與​服務​之間​的​多重​作業​情況​較​少,​因此​可以​提供​更​優異​的​效能,​但​並非​每次​皆​如此。 實際​的​應用​程式​效能​取決於 CPU 速度、​記憶體​架構、​程式​特性​等​因素。

儘管 Real-​Time 即時​作業系統​不一定​保證​提升​執行​速度,​但是​卻​可​提供​比​一般​用途​作業系統​更加​精確​且​可​預測​的​時效​特性。

回到​頂端

後續​步驟

請​繼續​閱讀​後續​文件,​以​了解​如何​運用 NI 軟​硬體,​在​最短​的​時間​內​打造​出​一套​優異​的 Real-​time 系統:

>> 使用 NI 軟​硬體​打造 Real-​Time 系統

>> 我​是否​需要 Real-​Time 系統?

>> 體驗​版​軟體

回到​頂端