即時作業系統 (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 整合以利未來的發展。