即時作業系統

於去年的成果中，我們是以 Linux 作業系統做為控制平台，但是 Linux 本身 無法做為硬即時應用，最主要的原因有【4-1】：

(1) 非強取式核心（Non-preemptable kernel）

(2) 時間共用（Time-sharing）排程策略與動態配置優先權 (3) 使用虛擬記憶體

(4) 缺乏高解析度的系統計時器

就第一點而言，Linux 核心在進行系統呼叫（System call）或是在進行核心服 務的工作時，系統核心大多是處於將中斷設定為關閉的狀態，這時若進行一個長 時間的系統呼叫，那系統將有一段長時間無法處理外部的中斷訊息。而在即時系 統裡，當一個優先權較低的工作，對核心進行系統呼叫時，若有一個優先權較高 的程式正在等待執行，系統核心必須能被強迫交出控制權給優先權高的程式使 用，而目前的 Linux 核心並不具有強奪性（Preemption）的能力。

其次，Linux 是採程式之執行時間共用的排程策略，其目的是為了讓系統裡所

有程式，能公平地共用系統資源（處理器、記憶體、週邊裝置…等），致使系統有 最 大 CPU 使 用 率 與 最 大 平 均 產 能 。 在 程 式 排 程 上 ， Linux 會將 CPU 傾向

（CPU-bound）及 IO 傾向（IO-bound）的工作分開來集中處理，這可能會造成即 時性工作超出工作期限的情況。

Linux 在工作優先順序的配置上，則是採用動態安排方式，意思是說，我們隨 時可更改程式的優先權大小，而這可能會對排程的既定性造成影響。另外，Linux 利用磁碟空間當作虛擬記憶體使用，而磁碟是屬於機械式裝置，其反應能力無法 像電子式的裝置來得即時。因此，在進行虛擬記憶體置換（Swapping）時，將會 花費一段未知且無法預測的時間來處理。很明顯地在這段時間內，系統將是無法 預測與獲知外界的訊息。

至於最後一個無法採用 Linux 來作即時應用的主要原因，是系統計時器的時 間刻度。就 Linux 而言，計時器更新速度為

100Hz

，也就是每

10ms

系統產生一個 Tick，這意謂著系統裡的週期性工作，其最小執行週期為

10ms

。因此，若欲進行 一些小於

10ms

的高精確度控制或取樣動作，是無法滿足需求的。此外，系統排程 器的反應能力亦和計時器有關，系統計時器的時間刻度越小，排程器越能迅速反 應外界訊息並喚醒處理工作。

雖說 Linux 作業系統採用的策略與即時性作業系統的策略方式背道而馳，但 Linux 確提供了豐富的硬體支援、軟體發展工具，這是一般即時作業系統所不能及 的。因此，為了利用 Linux 的資源優勢，且讓 Linux 的資源能利用在即時應用上，

目前有兩種延伸方法【4-3】：

第一種方法：直接加強核心能力 第二種方法：加入一個即時核心

第一種方法是針對 Linux 核心的強奪性與排程演算做些部份修改，以減少那 些不可強取的（Non-preemptible）部份程式碼所耗費的時間。一般而言，採用這種 策略方式是為了最小化系統的”中斷延遲”或是即時工作的”排程延遲”，使得作業系 統核心具有更好的即時反應能力。採用這種作法，可能遭遇的問題是，無法確切 地提供一個延遲保證數據，除非加強型的 Linux 核心中所有可能執行路徑，都做過 完整的分析與測試。基本上，這就意謂著在這種環境下，是無法滿足硬即時的要 求，但卻能提供軟即時的工作環境。目前採用這類作法的即時作業系統，如：

TimeSys、MontaVista 及 RedSonic。

第二種方法除了採用一個獨立的即時排程器之外，較不同於之前修改核心的 方式，是在 Linux 核心與硬體間加入了一個硬體處理層，來截取與管理實際的硬體 中斷，我們稱為硬體抽象層（Hardware Abstraction Layer，HAL）。系統所有的硬 體中斷完全由這個抽象層所控制。若是有必要，抽象層會模擬這些中斷給上層 Linux 核心使用，一般我們稱這樣的系統為一個微核心系統（Micro-kernel system）。 而即時排程器部份，會根據系統裡有即時性需求的工作，將它們安排在這個即時 核心工作空間中處理，反之，對於非即時性需求的工作，則交由 Linux 核心處理。

採用獨立即時排程器與硬體抽象層的好處是，不需要修改大部份的 Linux 核心，也

由於沒有進行大修改，因此，其他的子系統、裝置驅動程式或是使用者程式都能 很順利地在上面運行，另外，也不需要額外去分析 Linux 核心程式碼路徑，唯一需 要進一步分析的是即時排程器（及相關 IPC 和服務的程式碼）與抽象層。故採用 此方法能提供具硬即時的工作環境。目前採用這類作法的即時作業系統，如：

RTLinux 及 RTAI。

為了加強六軸運動平台的控制效果，我們採用第二種加強核心方式的 RTAI，

來改善原有 Linux 作業系統不具即時性的問題，而 Real-Time Application Interface

（RTAI）是由 DIAPM-RTLinux 加以改良的版本。DIAPM 的成員，將原有的 RTLinux 排程器保留，並加入一些新的功能與特性，在改良部份，則是放在即時的計時功 能上，除了新加入週期性計時（Periodic timing）功能，並藉由 CPU 的 TSC 來取 代 RTLinux 原有的計時方式，大大改善單次計時（One-shot timing）的效能。RTAI 第一個修改核心的正式版本，是在 1999 四月時，由 Paolo Mantegazza 所釋放出來。

目前 RTAI 是一個開放源始碼的計劃，早期只支援 x86 的平臺，但目前已提供以下 幾種硬體支援平臺：

x86

ARM (StrongARM, ARM7) PowerPC

MIPS CRIS

圖 4-2-1 為 RTAI 的運作架構圖。在架構上，RTAI 與 RTLinux 並沒有太大的 差異，在設計上，RTAI 在 Linux 上定義了一組即時硬體抽象層（Real-Time Hardware Abstraction Layer，RTHAL）。RTHAL 將 RTAI 需要在 Linux 中修改的部份，集合 並定義成一組系統介面，RTAI 可利用這組系統介面和 Linux 溝通。這樣做的好處 在於，可以將直接修改 Linux 核心內部的程式碼減至最小。所以，未來在將 RTHAL 移植到新 Linux 核心的工作量，可減至最低。除了加入 RTHAL 外，RTAI 還加入 了一個自己的即時核心。事實上，採用這種模組化設計的好處，甚至可不必採用 RTAI 的即時核心，而改用其他即時核心和 RTHAL 進行溝通。其中 RTHAL 主要 工作有二項：

(1) 負責收集 Linux 指向硬體相關資料或系統函式的所有指標，至一個結構中

（rthal）。

(2) 集合至這個結構的指標，能夠根據系統是否有要載入硬即時延伸，將這些 指標以動態方式，指向 Linux 一般系統函式或是 RTAI 的即時系統函式。

這讓 Linux 可在執行期間（Run time），進行一般作業系統與硬即時性作業 系統的切換。

事實上，這樣的動作，除了輕微降低系統的效能，Linux 本身的運作幾乎不受 加入的 RTHAL 所影響。輕微降低系統效能的原因要歸因於進行那些被取代的硬體 相關函式呼叫，如：sti 及 cli 相關的功能函式，而這些呼叫並不是直接與硬體連結 溝通的。RTAI 系統的即時工作，同樣也是以核心模組的方式存，並且在核心空間

中運作。當 RTAI 載入之後，Linux 核心不再是直接受到硬體中斷所控制的，而即 時工作也不再受到它的掌控。至於採用核心模組，有一些好處是即時工作不會被 進行分頁快取交換出去的動作，以降低 TLB 的 miss 率。而且即時工作的執行是在 處理器的特權模式（Supervisor mode）下運作，因此擁有低階硬體的所有存取權。

因為 RTAI 是一個開放原始碼的計劃，所以早期是以 LGPL 2 的方式授權，但 最近有關 RTAI 核心的部份，則是改為 GPL 2 的授權方式，其餘的部份仍是 LGPL 2 的方式。至於 RTAI 的檔雖然不是即時更新的，但算是相當完善。此外，mailing list 每日的訊息量相當地大，在上網詢問問題的時候，往往能很迅速獲得解答與答 覆【4-2, 4-7】。

Real-Time Scheduler Real-Time

Direct hardware access Software

interrupts

Hardware interrupts Linux Kernel Device Drivers

I/O

Real-Time Kernel Hardware Abstraction Layer

Real-Time Hardware Abstraction Layer

圖 4-2-1 RTAI 系統運作圖

器及致動器回授訊號的收集處理。其中逆向運動學轉換的部份是負責進行平台姿

Stewart Platform

Servomotors Actuators Sensors

Hardware control circuit A/D Data Source

Sensor Input Processing

Inverse

Transformation Controller

Monitor

^ measures Actuation

Channel predecessor

transformation

activate / shutdown

(5) 致動器回授訊號的收集處理

Data log Monitor

Embedded RTOS

control hardware VR Simulator

Ethernet Direction of data flow Direction of data

and command flow

圖 4-2-4 系統整合架構圖

4.2.2.3 系統狀態設計

在整個即時控制系統的狀態設計中，我們根據模擬系統的流程，將系統分成 Testing 與 Simulation 兩種模式。並依據這兩種模式，將模擬系統分成六種系統狀 態，分別為 initial, testing, ready, running, shutdown, emergency。圖 4-2-5 為我們的 即時控制系統狀態圖，以下分就這兩種模式工作流程進行說明。

/ rt_shutdown( )

< event > / < action >

Initial

[CMD] rise_up /rt_riseup( )

Emergency

Ready

/ notify_user( ) & entry periodic mode

Shutdown [CMD] shutdown /

exit periodic mode Running

Testing

receiving data / do platform control

receiving data / do platform control [CMD] testing /

entry periodic mode

[CMD] exit_testing / exit periodic mode

圖 4-2-5 即時控制系統狀態圖

(1) Testing 模式：

在此模式中，其目的是進行平台動作的測試，我們稱作平台軌跡規劃測 試。系統將根據我們預先規劃好的平台移動路徑，進行各種姿態的模擬。系 統的初始狀態為 initial，一旦使用者下命令要求進入 Testing 模式時，系統會 由 initial 狀態進入至 testing 狀態，此時系統會由事先安排的動作路徑，以固 定週期，進行即時的資料讀取、處理與控制。待使用者要求離開此模式時或 是系統完成軌跡規化測試後，系統會轉移至 shutdown 模式，將平台回歸初始 位置，最後系統狀態恢復至 initial 狀態。

(2) Simulation 模式：

平台在未進行任何模擬時，是處於 initial 狀態。當要進行動態模擬時，

平台必須提昇至一定的高度，才能開始進行資料的處理與控制。所以，在使 用者下達一個”rise_up”的命令後，平台提昇至固定的模擬高度，待完成這項動 作後，系統狀態便會由 initial 轉換至 ready 狀態。在進入 ready 狀態後，控制 系統接著通知使用者開始進行資料輸入的動作，隨即轉換至 running 的狀態。

在此狀態中，模擬系統便不斷地接收控制的資料，進行處理、運算與平台控 制。最後，待使用者再下達”shutdown”的命令後，系統會由模擬進行中的

在此狀態中，模擬系統便不斷地接收控制的資料，進行處理、運算與平台控 制。最後，待使用者再下達”shutdown”的命令後，系統會由模擬進行中的

在文檔中 產學合作計畫：高階飛行動態模擬器之研製(III) (頁 122-129)