實時操作系統 (Real-time OS) 是相對於分時操作系統 (Time-Sharing OS) 的一個 概念。在一個分時操作系統中，計算機系統的資料會被平均的分配給系統內所有的工作。對於這些工作而言，它們似乎是在一個速度較慢、資源較少的虛擬系統上工作。 而這個虛擬系統所擁有的資源會和真實系統內等待執行的工作數有關。簡單的說，如 果有 n 個工作要做，每一個工作就會分到 n 分之一的資源。
然而在一個實時操作系統之中，系統內有多少工作並不是那麼重要。我們關心的 事一個工作在多少的時間內可以被完成。和分時操作系統最大的不同之處在於 “時限(deadline)”這個概念，實時操作系統通常會要求每一個工作在交付給系 統的時候同時也給定一個時限。實時操作系統的任務不只是要求完成每一個工作， 並且要按時給定的時限完成每一個工作。
所以我們可以看出這二個概念的不同之處，分時操作系統的重點在於”公平”， 而實時操作系統的重點在於”時限(timing constraint)”“。
任何時候。我不是開玩笑，當一個實時操作系統中的每一個工作都有相同的時限時， 它應該和分時操作系統用相同的方式工作。分時操作系統和實時操作系統的分野在於工作的特性而非操作系統工作的模式。
在很多的書及文獻上我們可能會看到”硬實時(hard real-time)”和”軟實時 ( soft real-time)”這二個名詞。不同的人會給它們不同的意義，但大致來說它們是一組相對的概念。硬實時對滿足時限的要求會比軟實時來的嚴格。有些人會從 工作的特性上來分，硬實時工作 (hard real-time task) 通常指不能有任何差 錯的工作而軟實時則是指比較容許差錯的工作。例如我們常會用核能電廠和看 VCD 為例，用在核能電廠的實時操作系統如果出了差錯可能會導致嚴重的損害，然而 VCD Player 出了些差錯不過是讓使用者認清他所用的程序不夠好而已。所以前者 是硬實時，後者是軟實時。
但在大多數的狀況下，分野並不是如此的清楚。做 VCD Player 的廠商當然不 希望它的 Player 老是出錯，它也會希望 Player 用一個硬實時操作系統來驅動。 所以硬實時和軟實時的差別可能只是分類學上的問題而已。
然而對於一般的應用而言，實時操作系統的意義在那裡呢? 我們使用流覽器看一 個網站時，如果結果在 0.5 秒內出現，我們可能會覺得非常舒服。如果結果在 2 秒才出現，可能會覺得有些延遲。但如果花上 30 秒才出現，那可能就沒有人會等 到結果出現了。
對於我們而言，等個 3,5 秒可能覺得沒什麼。但也許 Bill Gates 不這麼想， 他會算給你聽他的一秒值多少錢! 所以不同的人可能會對延遲有不同的看法。即 時操作系統最大的優勢就在於他可以為不同的工作提供”不同等級的服務( differentiated service)”。
一個對實時系統常有的誤解是實時系統是一個高效率 (high performance) 的 系統，它會跑得比一般操作系統來的快，overhead 來得小。這其實是市場策略宣 傳造成的影響。一大堆非常小的操作系統宣稱它們是嵌入式實時操作系統 (embedded real-time OS)，這麼一來”嵌入”、”實時”和”小”就被莫名其 妙的連起來了。實事上這三個是完全不相干的概念。”嵌入”指的是操作系統可 以在一些資源受限的環境，例如沒有 disk，的情況下工作。”小”是指因為功能 簡單，要求不多，所以操作系統可以寫的很小，減少不必要的額外負擔。這些都 和”實時”的概念完全沒有關系。不幸的是，即使是學有專精的計算機工程師也常 把它們混為一談。
為什麼不用? 實時操作系統和分時操作系統並不是完全互斥的概念，我前面說過如 果一個實時操作系統中所有的工作都有相同的時限，那它應該會制造出和分時作業 系統相同的結果。
所以一個系統可以同時執行分時和實時的工作另一個常有的誤解是實時的工作 應該比分時的工作先執行。這其實是不對的，實時的工作只是要求在時限內完成 而已，一個時限在 10 秒之後的工作沒有道理一定要在現在立刻執行。太早完成 它沒有任何好處，有時還會造成系統不必要的負擔。
實時操作系統的優勢在於它知道目前系統資源使用的狀況，它能比起分時作業 系統更精准的控制系統資源的使用。對於分時操作系統而言，它無法預測一個工 作到底還須要花多少時間才能完成。因此對於比較重要的工作，唯一的方法就是 盡快的完成它。而實時操作系統可以預測工作完成的時間，因此它可以輕易的決 定工作要在什麼時間被執行。
所以實時操作系統所做的事，不過就是一個更強大的 renice 指令而已。在 renice 中，你只能指定一個叫優先權 (priority) 的值。優先權越高的工作 在分時系統中會分到更多的時間，但多多少呢? 沒人能回答這個問題，因為在 分時操作系統中不把它視為一個重要的事。
而實時操作系統的 renice 指定可以指定一大堆的參數，你可以指定前述的 時限 (deadline)，優先權 (priority)。還可以指定工作在單工狀態下執行所 需的時間 (execution time)、工作應該在什麼時候允許開始執行 (start time) 、什麼時候就不應該再繼續下去了(finish time)。當然過去二十年來在實時作 業系統理論上的發展使得我們還有更多更多的可能性來實作實時操作系統的 renice 指令。但簡單的說，我們得到的是一個更強大的 renice 指令。它可以被用來更 精准的調整系統的整體效能。這也就是我為什麼會認為，為什麼不用實時作業系 統。
我的看法是，在將來的操作系統，實時會是一個和網絡一樣、是系統標准的功能。
和 Linux 其它領域一般，有一大堆的人都試圖為 Linux 加上實時的功能。每個人 都有不同的看法，每個人看的角度也不相同，所以產生了各式各樣的”real-time Linux OS”。在這裡，我們看到了開放原始碼 (open source) 在這個領域優勢所 在。我們可以想見在不久的將來，這些各有專精的系統會自然的合並成一套非常好 用的實時操作系統。而不是相互用市場的策略惡性競爭。所以 open source 可以 提供我們一套更新、更好、更實用的實時操作系統。
接下來，我們先簡介一下現存的各種 real-time Linux OS。
NMT RT-Linux
NMT 是新墨西哥科技大學(New Mexico Technology) 的縮寫。這一套系統可以說是 所有 Real-time Linux 的鼻祖。它目前已經發展到 3.0 版。這個系統是由 Victor Yodaiken 和它的學生 Michael Barabanov 所完成。這個系統的概念是”架空” Linux kernel，使得它的 real-time 行程得以盡快的被執行。下面的圖例說明了 NMT RT-Linux 和其它類似產品的系統架構。
你可以看到基本上RT-Linux 中的實時工作(realtime task) 其實並不是 一個 Linux 的行程，而是一個 Linux 的可加載式核心模塊( loadable kernel module)。
之所以要如此做的原因在於 Linux 是一個很大的系統，且在設計的時候並沒 有考慮 real-time 的需求。舉個例說，單一個 Linux 系統呼叫可能會花上超過 10ms 的時間。對有些像工業控制的應用而言，它們對時間的要求通常在 1ms 的 等級上，Linux 根本無法滿足這種需求。所以 NMT RT-Linux 采用一個比較簡單 的做法，它干脆不用直接 Linux 的任何功能，而把需要高度時間精確度的工作 寫成一個驅動程序的型式，然後直接用 PC 時序芯片 (timer chip) 所產生的中 斷呼叫這個驅動程序。如此一來，不管 Linux 系統呼叫的時間有多長都沒有關系 了。
從這個角度看，NMT RT-Linux 其實是一個實時驅動程序的架構，算不上是真 正的 real-time Linux. 但由於它出現的早，且其架構很符合自動控制的需求。 使用者非常的多，且多半是有關自動控制的應用。
RTAI
RTAI 是 Real-Time Application Interface 的縮寫。顧名思義知道它是一套可 以用來寫實時應用程序的界面。大致而言，RTAI 和 NMT RT-Linux 是相同的東西。 它同樣的架空了 Linux，而直接用可加載式核心模塊( loadable kernel module) 實作 real-time process。每一個實時行程實際上就是一個可加載式核心模塊。
RTAI 和 NMT RT-Linux 最大的不同地方在於它非常小心的在 Linux 上定義了 一組 RTHAL (Real-Time Hardware Abstraction Layer)。RTHAL 將 RTAI 需要 在 Linux 中修改的部份定義成一組程序界面，RTAI 只使用這組界面和 Linux 溝通。這樣做的好處在於我們可以將直接修改 Linux 核心的程序代碼減至最小， 這使得將 RTHAL 移植到新版 Linux 的工作量減至最低。
RTAI 采取這種途徑最大的原因在於 NMT RT-Linux 在由 2.0 版移植至 2.2 版 的過程序遇到問題，使得基於 2.2 版核心的 NMT RT-Linux 一直無法完成。所以 在 Dipartimento di Ingegneria Aerospaziale Politecnico di Milano 的 Paolo Mantegazza 和他的同事們就決定自行做移植的工作，但由 NMT RT-Linux 的困境他們體認到必須采取上述的途徑以解決將來可能再度面臨的兼容性問題。
於是 RTAI 便誕生了，它是一個比 NMT RT-Linux 更好的 NMT RT-Linux，雖 然後來 NMT RT-Linux 也隨後完成移植的工作，但那已經是 RTAI 誕生半年以 後的事了。
LXRT
由於 RTAI 無法直接使用 Linux 的系統呼叫，解決的方法是使用 RT-FIFO 將一個 RTAI real-time kernel module 和真正的 Linux 行程連接在一起，由這個行程做 代理人的工作為其呼叫 Linux 系統呼叫。下圖說明了 LXRT proxy 行程的概念
紅色的部份表示一組 RTAI 的實時行程和它在使用者模式 (user space) 的 伙伴。你可以了解，當 proxy 激活後，它不再可以被任何的搶先 (preempt)， 所以原本有的優勢就不再保有了。
KURT
KURT 是由 kansas 大學所創造的系統，它和 NMT RT-Linux 及 RTAI 有很大的不同。KURT 是第一個可以使用系統呼叫的 real-time Linux。由於 KURT只是簡單的將 Linux 的排程器用一個很簡單的時間驅動式(time driven)排程器加以取代，實時行程的執行很容易很其它非實時行程的影響。
RED-Linux
這是小弟在下不才我在加州大學 Irvine 分校所做的系統，它和 KURT 類似，是一個 可以使用所以 Linux 系統呼叫的 real-time Linux。它的特點是使用”搶先檢查點 (preemption point)”改善系統的反應速度。前面說過 KURT 的最大問題在於它受 限於原有的 Linux 架構，使得系統的反應時間很難控制。然而在 RED-Linux 這一 點已經被大大的改善，由在 2.0 版的經驗得知其反應延遲約在 100 us 左右。
RED-Linux 非常有彈性的排程器架構也是其特點之一，這部份基本上就是我博士 論文的主軸。它使得 RED-Linux 可以符合各種不同復雜度系統的需求。基本上，它將排程器分成 dispartcher 和 allocator 二部份，dispatcher 在核心中執行而 allocator 在使用者模式執行。allocator 可以是應用程序的一部份，也可以是一個獨立的單位。通常它可能是 middleware 的一部份，負責將應用程序的 resource request 轉換成 kerner 可以了解的格式。
RED-Linux 目前正在進行 POSIX 兼容模式的移植工作，所有 POSIX 中的實時 排程、定時器、sporadic server 等都將會被實作出來。
所有這些有關 real-time Linux 的計畫都是在 open source 的情況下發展，所以 我們可以預期在將來它們會有某些程度上截長補短的情況出現。前面說過，real-time Linux 主要有二個大類。第一種是 NMT RT-Linux 和 RTAI，它們的實時行程實際上 是一個核心模塊。所以它們事實上是一種 real-time 驅動程序，RTAI 和檔案系統 及網絡系統其實有很相似的結構，差別只是在於其驅動的硬件類別不同而已。
而另一方面，如 KURT, Linux/RK 及 RED-Linux 之類的系統則受限於能達到的時 間分辨率。雖然 RED-Linux 已經把這個極限推到 1ms 左右，但我們可以預期在 PC 的架構下要達到 100us 以下是很困難的。也就是說，對於要求 10K 以上頻率的應用 是不可能使用這種架構來達成。
但這其實是一個很合理的限制，我們可以將二種架構整合成一個系統來滿足 所有的需求。LXRT 是一個正確的方向，但如果使用 RED-Linux 和 RTAI 整合 可能更能達成需求。RED-Linux 非常彈性的排程器架構使得整合更行簡單。我 希望能在未來半年內推出這個產品，以成為一個終極的 real-time Linux。並 思考如何使整個系統正式的和 Linux 整合以利未來的發展。
摘自：http://linuxfab.cx