淺談嵌入式軟件系統設計中的正交性

摘要 嵌入式軟件系統設計領(lǐng)域存在“正交”的思想。本文結合實(shí)際項目經(jīng)驗，總結了軟件系統正交化的方法，同時(shí)較全面地分析了正交性給嵌入式軟件設計帶來(lái)的諸多方便，最后回顧“正交”思想對不同自然科學(xué)領(lǐng)域的積極影響與啟發(fā)。

關(guān)鍵詞  嵌入式軟件設計  正交性  小波

1  小波漫談

　　小波變換是20世紀最輝煌的科學(xué)成就之一，已經(jīng)廣泛應用于信號處理、圖像分析、非線(xiàn)性科學(xué)、地球科學(xué)、音樂(lè )雷達、CT成像、地震勘探、天體識別、量子場(chǎng)論、機械故障診斷、分形等科技領(lǐng)域。

　　20世紀初，哈爾(Alfred Haar)對在函數空間中尋找一個(gè)與傅里葉類(lèi)似的基非常感興趣。1909年他最早發(fā)現和使用了小波，后來(lái)這被命名為哈爾小波(Haar wavelets)。20世紀 70年代，當時(shí)在法國石油公司工作的地球物理學(xué)家 Jean Morlet提出了小波變換 WT(Wavelet Transform)的概念。 進(jìn)入 20世紀 80年代，法國科學(xué)家 Y.Meyer和他的同事開(kāi)始研究系統的小波分析方法。1985年，Daubechies提出“正交小波基”，并構造具有緊支撐的光滑小波，以及隨后 Mallat提出的多分辨分析及快速小波變換，將小波研究推向高潮。小波分析己經(jīng)成為目前發(fā)展最快和最引入注目的學(xué)科之一，幾乎涉及信息領(lǐng)域的所有學(xué)科。

　　為何“正交小波基”與多分辨分析的提出成為小波分析發(fā)展史中的重大突破成就？主要原因之一是：變換系數沒(méi)有冗余，能夠將信號分解成互不影響的正交子信號，這樣就可以根據需求方便地對所需特征的子信號進(jìn)行分析，從而很好地反映信號的細節。

2  嵌入式軟件系統設計的正交性

　　其實(shí)，在軟件系統設計領(lǐng)域同樣或多或少存在“正交”的思想。一個(gè)常被引用的模式是Smalltalk編程語(yǔ)言（Krasner和 Pope，1988）的模型視圖控制器(ModelViewController)框架。該模式強制性地將軟件系統的輸入、處理和輸出分開(kāi)，形成數據模型、視圖、控制器三大模塊，如圖1所示。圖中“數據模型”包括程序的設計部分，“視圖”表示用戶(hù)界面，“控制器”定義用戶(hù)和視圖的交互方式。

圖1  模型視圖控制器框架

　　其中每部分都是一個(gè)獨立的對象，每個(gè)對象有自己處理數據的規則。這種功能的分離恰巧促成各個(gè)模塊的正交性、減少它們之間的冗余，因此也使該框架成為應用最為廣泛的模式之一。

2.1  設計正交嵌入式軟件系統

　　毫無(wú)疑問(wèn)，正交的思想使得系統設計更加清晰和方便。那么如何才能更好地使嵌入式軟件系統具有“正交性”呢？

（1）  設計具有正交性的系統體系結構

　　進(jìn)行系統設計首先要進(jìn)行系統的體系結構設計。系統的宏觀(guān)設計同樣也體現正交性思想，如圖2所示。

圖2  系統體系結構

　　其中，底層驅動(dòng)與RTOS是唯一與系統硬件相聯(lián)系的模塊，直接負責與硬件打交道，對硬件進(jìn)行管理與控制，并為其上層模塊提供所需的驅動(dòng)支持；調度程序在RTOS支持下，根據系統需求對不同的任務(wù)模塊進(jìn)行實(shí)時(shí)調度與管理，確保所有任務(wù)能順利、均衡地執行；最上層的任務(wù)模塊具有不同的功能，以滿(mǎn)足用戶(hù)需求，它們各自獨立、正交、不存在冗余，同時(shí)提供相應數據接口，以便與其他模塊通信，形成有機整體。

　　整個(gè)系統體系結構同樣體現了正交思想，各個(gè)層的不同模塊負責相互獨立、正交的任務(wù)。從垂直角度看上去，該體系結構同正交小波一樣，可以用多尺度空間思想表示，如圖3所示。越核心的地方，功能輪廓越粗略；越到外層，越體現細節、越貼近用戶(hù)需求。

圖3  多尺度嵌入式軟件體系結構

（2）  保持模塊間的松耦合

　　劃分軟件模塊時(shí)很重要的一個(gè)原則是：盡可能地保證各模塊間的松耦合和模塊內部的高聚合。這實(shí)際上就實(shí)現了系統的正交化，減少了模塊間的冗余與關(guān)聯(lián)。理想的系統結構呈樹(shù)狀，如圖4所示。

圖4  嵌入式系統的理想樹(shù)狀結構

　　整個(gè)系統呈樹(shù)狀結構，模塊間的連接只能存在上下級之間的調用關(guān)系，不能有同級模塊之間的橫向關(guān)系，即不能出現網(wǎng)狀結構或交叉調用關(guān)系。

　　如圖4所示，通過(guò)調用I2C總線(xiàn)讀寫(xiě)子模塊可以實(shí)現I2C一主多從通信子模塊以及RTC和EEPROM的讀寫(xiě)子模塊，但是這些子模塊之間彼此不能互相調用。所以，當系統對EEPROM沒(méi)有需求時(shí)，可以方便地將EEPROM讀寫(xiě)子模塊移除，而不會(huì )影響到其他模塊。

（3）  保持任務(wù)間的松耦合

　　嵌入式系統中常常會(huì )用到RTOS，根據系統需求確定不同的任務(wù)以及任務(wù)執行的頻率或次序。在滿(mǎn)足需求的前提下，盡可能地保證每個(gè)任務(wù)有固定的執行周期，因為這樣可以讓任務(wù)按照既定頻率執行，減少任務(wù)間的通信和調用，同時(shí)也增強了系統的可預見(jiàn)性。

　　例如，系統SPI通信解析任務(wù)（即ProcSPI任務(wù)）的執行頻率為10 Hz，為了保證通信正常，需要一個(gè)任務(wù)實(shí)時(shí)檢測SPI通信是否出現故障（即FaultSPI任務(wù)）。為說(shuō)明簡(jiǎn)便，假設SPI通信故障的唯一來(lái)源是數據解析時(shí)校驗不通過(guò)，并且當出錯概率超過(guò)50%時(shí)即可判定SPI通信故障。圖5所示為FaultSPI任務(wù)被調用的2種方式。

　　圖中，MCscheduler為系統調度程序，能以固定頻率調用不同的任務(wù)。圖5（a）表明每次解析SPI數據時(shí)，都直接觸發(fā)FaultSPI 任務(wù)。顯然，根據需求，該方式做了許多無(wú)用的判斷。圖5（b）表明FaultSPI任務(wù)由系統調度程序以1 Hz的頻率調用。該任務(wù)只需要確定SPI數據有5次以上校驗錯誤，即可判斷SPI通信故障。這種方式消除了2個(gè)任務(wù)的直接調用關(guān)系，即保持了任務(wù)間的松耦合。

（4）  合并同類(lèi)項

　　以模塊或文件為單位，每個(gè)模塊或文件面向獨立的設備或需求，每個(gè)模塊又由許多子模塊構成，這些子模塊盡可能負責獨立、單一的任務(wù)或功能。如 GetTime()、SetTime()、GetFault()、PushFault()等，這些子模塊可能會(huì )調用相同的函數或方法，也可能會(huì )使用同一個(gè)屬性變量，如果將這些子模塊歸在一起，封裝成一個(gè)文件，那么這些被調用的函數、方法或變量就不需要“extern”聲明(C語(yǔ)言中)，因此對于其他文件是隱藏的、不可見(jiàn)的，增加了系統的安全性；另外，當不需要該功能或設備時(shí)，可以方便地將該文件從項目中移除，而不會(huì )影響到其他模塊的工作。

（5）  避免編寫(xiě)相似函數

　　功能相似的函數往往很難保持正交性，所以應該避免相似函數的出現，或者將其統一成一個(gè)函數。比如，一個(gè)系統存在著(zhù)多種通信方式，而在通信過(guò)程中，常常需要開(kāi)發(fā)者確定自己的通信協(xié)議以及校驗方式；如果每一種通信方式都編寫(xiě)自己的校驗函數，則增加代碼量的同時(shí)，也使得系統通信校驗函數過(guò)于零散；在設計時(shí)，可以考慮統一系統中的通信校驗方式，編寫(xiě)一個(gè)校驗函數，以支持各類(lèi)通信的校驗。這樣既能使系統簡(jiǎn)潔，同時(shí)也便于維護。