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