[轉] 系統架構設計實例分析(III) – RTOS/Embedded-Linux通用的系統架構

(出處: 大黑狗偉大航道之航海 )

菜鳥:『可不可以再提一個比較”高階”的例子,畢竟我們現在用的是32bit的CPU,而且似乎也沒可憐到需要為了幾個byte斤斤計較。』

PM:『OK,我來講一個跟embedded Linux有關的案子;這個內部的案子我之前應該有跟你提過,希望將原本在RTOS上已開發好的應用移植到embedded Linux上;

再繼續討論下去之前,這種案子有幾個重要的背景需要先知道:

1. Embedded Linux會用在比較高階的產品線,但採用embedded Linux的產品仍必須具有原RTOS系統上的所有應用(例如可上網的多媒體播放器,雖然新增了網路應用,但絕對不能忽略了多媒體播放功能。)
2. 使用RTOS的低階產品仍有市場需求,亦即應用程式仍可能繼續發展與改善;而所有應用程式的改變都必須能反應到使用embedded Linux的高階產品線。簡單的說,我們希望使用RTOS與embedded Linux的系統,可以共用同一套應用程式的source code。
3. 高階產品(採用Embedded Linux)新增功能,影響不要到既有RTOS上的應用程式。
4. 無論專案採用RTOS或embedded Linux,系統必須能夠執行在同樣的硬體架構之上;但RTOS與Linux驅動程式的寫法是截然不同的。

因為要考量的事情真的很多,大家往往很容易一不小心就鑽入技術細節的黑洞中,而這就是設計系統架構的大忌 – 骨架沒出來,任何對骨/肉的討論都沒太大意義!而且我們上面說過,系統架構設計本來就是一種循序漸進過程。

當我參與這個專案的討論之後,我實在受不了這種冗長又無法產生結論的會議;雖然不是由我主導這個專案,我還是畫了幾張架構圖,雖然不會是最後的方案,但總算把大家拉回系統架構設計的正軌上。

一旦我們認真檢視這個專案真正的目的,你會發現一開始就把重心放在embedded Linux是不對的…』

菜 鳥:『沒錯,工程師個性就是如此,總是傾向於花時間與注意力在自己沒作過的事情上。Porting Linux到既有硬體平台上只是這個專案的主要工作之一而已,這個專案主要的目的其實是要找出一個可以讓embedded Linux能共用RTOS上既有應用程式的方式罷了。』

PM:『沒錯,很多事情都是當局者迷,旁觀者清。既然目標是共用RTOS上的應用程式,我們當然得先來看看既有的系統架構,是個很嚴謹的分層架構。』

圖6-29:既有產品線,使用RTOS當核心的系統架構

PM:『這是一個典型的基於RTOS的multi-tasking system,我們來檢視一下,這個系統中哪些模組是可以與Linux共用的?』

菜鳥:『Linux本身就是一個完整的系統,有自己的驅動程式、記憶體管理、標準C函式支援…等,此外還有許多專為嵌入式系統所設計的GUI系統可選擇,例如:QT/Embedded、Micro-Win…等等。

從上圖看來,我認為OS-API以下乃屬於系統部份,RTOS與embedded Linux並無法共用這些系統模組。而設計OS-API的目的就是希望OS-API以上的程式模組是OS-independent的,亦即上層程式只能透過呼叫OS-API來使用系統與硬體功能;所以理論上只要在embedded Linux上包裝出完全相同(介面相同 + 行為相同)的OS-API,並使用embedded Linux上的thread模擬原先RTOS上的task,則原RTOS上的middleware與application應該就能再Linux上跑了吧。』

PM:『不錯,分析得很好,越來越有sense了;所以我們畫出的系統架構圖如下:』

圖6-30:RTOS與Linux共用middleware與application的系統架構

PM:『上面這張圖以OS-API作為區隔,往上是與OS無關的部份,也就是我們希望RTOS與embedded Linux能共用的模組;往下分為兩部份,左邊是RTOS,右邊是embedded Linux,後者為了要包裝出既定的OS-API,勢必要額外補上一些功能。

這張圖中值得一提的是HAL(Hardware Abstraction Layer/硬體抽象層 );驅動程式的穩定度是整個產品品質的根基,所以我們希望兩個系統能最大程度地共用驅動程式,為此我們定義了硬體抽象層API。也就是說,無論硬體配置是否相同,驅動程式都必須包裝出通同的介面(HAL),系統(RTOS or embedded Linux)則將HAL當作是抽象的硬體,再依該系統的規範實作驅動程式。

所以即便RTOS與embedded Linux上對驅動程式的寫法有不同的規範,在我們的系統架構中,真正”驅動”硬體的程式則只有一套,這可以為以後的測試與品質工作省下很多麻煩。

言歸正傳,當我們有了兩個系統共存的架構圖後,我們可以依此畫出embedded Linux執行原RTOS上之application的架構圖;其實就是把上個圖中RTOS的部份去掉,再加上embedded Linux上為了要包裝出OS-API所需額外補上的模組即可。請參考下圖:』

圖6-31:以Linux當核心,執行原RTOS系統上的所有功能

PM:『這張圖應該很容易理解,在此我就不解釋了。看圖說故事是最好的溝通方式,至此共三張圖應該可以把故事說清楚了。當然不是系統架構圖出來後就天下太平 了,這只是初稿而已,但至少所有人有了可以討論的平台;而且在接下來的討論中,我們會再擴充或改良系統架構圖,讓所有人都可以從這些圖中了解,我們到底要把這個專案作成什麼樣子?

舉例來說,老闆看了以上三張圖後似懂非懂的問道:”這些圖說明了兩個系統如何共用application,那如果embedded Linux想要擴充功能,如何保證不會影響既有的application?”,則我們會發現少了一張圖說明embedded Linux上既有application與擴充功能如何共存;當碰到這種情況時,立即補上就是了,我們不是一再強調系統架構設計是一種循序漸進的過程嗎?沒有人有把握將新專案的系統架構一次就設計完整無誤的。』

發表迴響