|
嵌入式軟件系統設計領域存在“正交”的思想。本文結合實際項目經驗，總結了軟件系統正交化的方法，同時較全面地分析了正交性給嵌入式軟件設計帶來的諸多方便，最后回顧“正交”思想對不同自然科學領域的積極影響與啟發。 1 小波漫談 小波變換是20世紀最輝煌的科學成就之一，已經廣泛應用于信號處理、圖像分析、非線性科學、地球科學、音樂雷達、CT成像、地震勘探、天體識別、量子場論、機械故障診斷、分形等科技領域。 20世紀初，哈爾(Alfred Haar)對在函數空間中尋找一個與傅里葉類似的基非常感興趣。1909年他最早發現和使用了小波，后來這被命名為哈爾小波(Haar wavelets)。20世紀 70年代，當時在法國石油公司工作的地球物理學家 Jean Morlet提出了小波變換 WT(Wavelet Transform)的概念。 進入 20世紀 80年代，法國科學家 Y.Meyer和他的同事開始研究系統的小波分析方法。1985年，Daubechies提出“正交小波基”，并構造具有緊支撐的光滑小波，以及隨后 Mallat提出的多分辨分析及快速小波變換，將小波研究推向高潮。小波分析己經成為目前發展最快和最引入注目的學科之一，幾乎涉及信息領域的所有學科。 為何“正交小波基”與多分辨分析的提出成為小波分析發展史中的重大突破成就？主要原因之一是：變換系數沒有冗余，能夠將信號分解成互不影響的正交子信號，這樣就可以根據需求方便地對所需特征的子信號進行分析，從而很好地反映信號的細節。 2 嵌入式軟件系統設計的正交性 其實，在軟件系統設計領域同樣或多或少存在“正交”的思想。一個常被引用的模式是Smalltalk編程語言（Krasner和 Pope，1988）的模型視圖控制器(ModelViewController)框架。該模式強制性地將軟件系統的輸入、處理和輸出分開，形成數據模型、視圖、控制器三大模塊，如圖1所示。圖中“數據模型”包括程序的設計部分，“視圖”表示用戶界面，“控制器”定義用戶和視圖的交互方式。 圖1 模型視圖控制器框架 其中每部分都是一個獨立的對象，每個對象有自己處理數據的規則。這種功能的分離恰巧促成各個模塊的正交性、減少它們之間的冗余，因此也使該框架成為應用最為廣泛的模式之一。 2.1 設計正交嵌入式軟件系統 毫無疑問，正交的思想使得系統設計更加清晰和方便。那么如何才能更好地使嵌入式軟件系統具有“正交性”呢？ （1） 設計具有正交性的系統體系結構 進行系統設計首先要進行系統的體系結構設計。系統的宏觀設計同樣也體現正交性思想，如圖2所示。 圖2 系統體系結構 其中，底層驅動與RTOS是唯一與系統硬件相聯系的模塊，直接負責與硬件打交道，對硬件進行管理與控制，并為其上層模塊提供所需的驅動支持；調度程序在RTOS支持下，根據系統需求對不同的任務模塊進行實時調度與管理，確保所有任務能順利、均衡地執行；最上層的任務模塊具有不同的功能，以滿足用戶需求，它們各自獨立、正交、不存在冗余，同時提供相應數據接口，以便與其他模塊通信，形成有機整體。 整個系統體系結構同樣體現了正交思想，各個層的不同模塊負責相互獨立、正交的任務。從垂直角度看上去，該體系結構同正交小波一樣，可以用多尺度空間思想表示，如圖3所示。越核心的地方，功能輪廓越粗略；越到外層，越體現細節、越貼近用戶需求。 圖3 多尺度嵌入式軟件體系結構 （2） 保持模塊間的松耦合 劃分軟件模塊時很重要的一個原則是：盡可能地保證各模塊間的松耦合和模塊內部的高聚合。這實際上就實現了系統的正交化，減少了模塊間的冗余與關聯。理想的系統結構呈樹狀，如圖4所示。 圖4 嵌入式系統的理想樹狀結構 整個系統呈樹狀結構，模塊間的連接只能存在上下級之間的調用關系，不能有同級模塊之間的橫向關系，即不能出現網狀結構或交叉調用關系。 如圖4所示，通過調用I2C總線讀寫子模塊可以實現I2C一主多從通信子模塊以及RTC和EEPROM的讀寫子模塊，但是這些子模塊之間彼此不能互相調用。所以，當系統對EEPROM沒有需求時，可以方便地將EEPROM讀寫子模塊移除，而不會影響到其他模塊。 （3） 保持任務間的松耦合 嵌入式系統中常常會用到RTOS，根據系統需求確定不同的任務以及任務執行的頻率或次序。在滿足需求的前提下，盡可能地保證每個任務有固定的執行周期，因為這樣可以讓任務按照既定頻率執行，減少任務間的通信和調用，同時也增強了系統的可預見性。 例如，系統SPI通信解析任務（即ProcSPI任務）的執行頻率為10 Hz，為了保證通信正常，需要一個任務實時檢測SPI通信是否出現故障（即FaultSPI任務）。為說明簡便，假設SPI通信故障的唯一來源是數據解析時校驗不通過，并且當出錯概率超過50%時即可判定SPI通信故障。圖5所示為FaultSPI任務被調用的2種方式。 圖中，MCscheduler為系統調度程序，能以固定頻率調用不同的任務。圖5（a）表明每次解析SPI數據時，都直接觸發FaultSPI 任務。顯然，根據需求，該方式做了許多無用的判斷。圖5（b）表明FaultSPI任務由系統調度程序以1 Hz的頻率調用。該任務只需要確定SPI數據有5次以上校驗錯誤，即可判斷SPI通信故障。這種方式消除了2個任務的直接調用關系，即保持了任務間的松耦合。 圖5 FaultSPI任務調用方式 （4） 合并同類項 以模塊或文件為單位，每個模塊或文件面向獨立的設備或需求，每個模塊又由許多子模塊構成，這些子模塊盡可能負責獨立、單一的任務或功能。如 GetTime()、SetTime()、GetFault()、PushFault()等，這些子模塊可能會調用相同的函數或方法，也可能會使用同一個屬性變量，如果將這些子模塊歸在一起，封裝成一個文件，那么這些被調用的函數、方法或變量就不需要“extern”聲明(C語言中)，因此對于其他文件是隱藏的、不可見的，增加了系統的安全性；另外，當不需要該功能或設備時，可以方便地將該文件從項目中移除，而不會影響到其他模塊的工作。 （5） 避免編寫相似函數 功能相似的函數往往很難保持正交性，所以應該避免相似函數的出現，或者將其統一成一個函數。比如，一個系統存在著多種通信方式，而在通信過程中，常常需要開發者確定自己的通信協議以及校驗方式；如果每一種通信方式都編寫自己的校驗函數，則增加代碼量的同時，也使得系統通信校驗函數過于零散；在設計時，可以考慮統一系統中的通信校驗方式，編寫一個校驗函數，以支持各類通信的校驗。這樣既能使系統簡潔，同時也便于維護。 2.2 正交嵌入式系統的好處 正交思想幾乎觸及到自然科學的各個領域，利用該思想來進行嵌入式軟件系統設計同樣存在諸多優點。 （1） 方便單元測試 在整個軟件開發周期中，軟件的測試工作占據著相當重要的比例，甚至會超過整個周期的50%。倘若等到所有代碼都編寫完成之后才開始測試工作，那么，軟件系統不同層面以及各個任務模塊中的眾多Bug，常常會使程序員無法理清思路，從而不能判斷問題的根源。所以在進行系統集成測試之前，應該將各個模塊的Bug減少到最低，這也就需要在編寫各個模塊時，進行有效的單元測試。而保證單元測試順利有效進行的前提是，該模塊有很高的獨立性，這也正是正交性解決的問題。圖6所示為嵌入式軟件系統的測試流程。 圖6 嵌入式軟件系統測試流程 （2） 更易于維護 常常有軟件系統維護的人員發現了系統存在的問題，卻不敢輕易改動，特別是系統底層部分。原因很簡單：系統一直運行良好，沒有出錯，而且由于沒有完整的文檔說明，擔心改動之后會出現新的問題。這種憂慮折射出的是：程序員對眼前軟件系統是否具備較好正交性的疑慮。所以一個具有較好正交性的嵌入式軟件系統，能夠讓軟件維護人員更快、更順利地接手，提高維護效率的同時保證很高的正確性。 （3） 便于移植 硬件的更新速度相當之快，要降低產品升級成本、加快升級速度，必須讓軟件系統具備很好的可移植性，特別是嵌入式軟件系統中與硬件沒有直接關聯的應用層部分。一個正交嵌入式系統正好從垂直方向保證了系統各層之間的獨立性，很好地將應用層與物理層分離開來。 （4） 便于協同開發 DSP與ARM較傳統MCU的優勢之一，是使用了流水線技術，使指令能并行執行。對于軟件，同樣希望能并行協同開發。正交嵌入式系統各個模塊相互獨立，只要定義好各模塊的接口，軟件開發人員并不需要等待其他模塊完成就能開展工作。圖7所示為正交嵌入式軟件系統的開發模式。 正交的嵌入式軟件系統，能夠非常方便地將系統分為互不干擾的獨立模塊。每個軟件開發人員或開發團隊負責不同的模塊，并行地開展工作。開發人員在開發過程中能夠互相溝通（如圖7中虛線箭頭所示），甚至可以隨時協助同伴攻克難題。 圖7 正交軟件系統開發模式 3 小結 在眾多研究領域，人們很早就開始借助正交性思想來幫助解決種種問題。從歐氏空間線性變換到經典力學中物體受力分析，從傅里葉變換到信號處理，從小波分析到地震勘探、量子場論、信號處理（包括圖像和語音）、機械故障診斷以及JPEG2000標準的制定。這些都是借助正交性思想，將對象分成多個相對獨立的部分，進而對各部分單獨進行研究，從而化繁為簡。在嵌入式軟件設計中，也存在類似的思想，正交的嵌入式軟件系統能夠降低系統各模塊間的依賴性，從而使系統更易于維護、方便測試，也更加容易實現系統的移植。從軟件開發過程的角度來看，正交性思想還能夠幫助研發團隊并行作業、協同開發，減少了等待時間，大大提高開發效率，因此該思想值得軟件設計人員探討和利用。 |
