賴炳宇，李言華

（中國電子科技集團第29研究所，成都610000）

引 言

按照傳統(tǒng)意義的定義，嵌入式系統(tǒng)為以應(yīng)用為中心，計算機技術(shù)為基礎(chǔ)，軟硬件可裁剪，適應(yīng)應(yīng)用系統(tǒng)對功能、可靠性、成本、體積、功耗等嚴(yán)格要求的專用計算機系統(tǒng)。由于硬件平臺的諸多約束以及對應(yīng)用系統(tǒng)特定功能的適應(yīng)性要求，一般的嵌入式系統(tǒng)軟件設(shè)計力求簡單、可靠，而軟件與硬件的結(jié)合非常緊密，極具個性化色彩，軟件的可復(fù)用性、可擴展性、可移植性等在設(shè)計過程中往往不是考慮的主要因素。

然而，隨著芯片技術(shù)的飛速發(fā)展，一方面，目前硬件平臺能力已經(jīng)得到了極大的提高，大多數(shù)領(lǐng)域使用的芯片具有更強的處理能力，并且集成了多種接口，使嵌入式系統(tǒng)滿足更為復(fù)雜的應(yīng)用需求成為可能，軟件實現(xiàn)的功能也更為復(fù)雜；另一方面，基于應(yīng)用的需求，對產(chǎn)品的可靠性、成本、更新?lián)Q代的要求也在提高，嵌入式軟件的可復(fù)用性、可擴展性以及可移植性逐漸成為設(shè)計時必須要考慮的問題。

參考目前的桌面通用計算機軟件可以預(yù)見，通過建立可復(fù)用面向?qū)ο蟮那度胧杰浖軜?gòu)，能夠增強嵌入式軟件的可復(fù)用性、可擴展性和可移植性，降低研發(fā)周期和成本。

1 軟件框架和設(shè)計模式

軟件框架（Software Framework），通常指的是實現(xiàn)某個業(yè)界標(biāo)準(zhǔn)或完成特定基本任務(wù)的軟件組件規(guī)范，也指實現(xiàn)某個軟件組件規(guī)范時提供所要求的基礎(chǔ)功能的軟件產(chǎn)品。軟件框架的功能類似于基礎(chǔ)設(shè)施，與具體的軟件應(yīng)用無關(guān)，只是提供并實現(xiàn)最基礎(chǔ)的軟件架構(gòu)和體系。軟件設(shè)計師通常根據(jù)特定的軟件框架實現(xiàn)更為復(fù)雜的系統(tǒng)應(yīng)用和業(yè)務(wù)邏輯。

簡而言之，框架就是制定一套規(guī)范，使所有程序員在該規(guī)范下工作。在軟件的研發(fā)過程中，框架明確定義軟件的模塊化規(guī)范、模塊之間的交互、對外接口方法，以及高層事物的對象操作、邏輯和流程，以便于具體應(yīng)用實現(xiàn)者能夠集中精力于應(yīng)用本身的特定細(xì)節(jié)。

顯然，無論是對于桌面通用計算機軟件還是嵌入式系統(tǒng)軟件，軟件框架作為軟件運行的基礎(chǔ)，都是十分重要的。好的軟件框架可以使系統(tǒng)具有更好的可復(fù)用性、擴展性和移植性，進(jìn)而提升系統(tǒng)的可靠性并降低成本。良好的軟件框架共同的設(shè)計決策，十分強調(diào)設(shè)計復(fù)用，因此框架設(shè)計中必然使用設(shè)計模式。

設(shè)計模式（Design Pattern）是由Erich Gamma等人1990年從建筑設(shè)計領(lǐng)域引入的概念。設(shè)計模式并不直接完成程序代碼的編寫，而是描述在各種不同的情況下，如何解決問題的一種方案。它是一套被反復(fù)使用、多數(shù)人知曉、經(jīng)過分類編目、代碼設(shè)計經(jīng)驗的總結(jié)。使用設(shè)計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼的可靠性。毫無疑問，設(shè)計模式使代碼編制真正工程化，是軟件工程的基石脈絡(luò)。

2 嵌入式傳感器控制系統(tǒng)的特點及軟件框架設(shè)計考慮

在涉及系統(tǒng)調(diào)度控制領(lǐng)域的嵌入式系統(tǒng)中，由于需要實現(xiàn)的功能和接口日趨復(fù)雜，總結(jié)起來，具有如下特點：

①核心調(diào)度控制算法存在多樣性。在嵌入式控制系統(tǒng)中，尤其在涉及傳感器控制的系統(tǒng)中，為了實現(xiàn)特定的功能需求、針對不同的應(yīng)用場景，傳感器資源的調(diào)度和控制，存在多種不同的策略和算法，而某種調(diào)度控制策略和算法只與應(yīng)用有關(guān)，而與底層的硬件和所搭載的平臺無關(guān)。

②硬件接口多樣化。由于需要滿足不同應(yīng)用的工程實現(xiàn)環(huán)境，不同的嵌入式控制系統(tǒng)所面臨的硬件接口差異較大。目前，常用的硬件通信接口包括TCP/IP網(wǎng)絡(luò)通信接口、RS232/422串口通信接口、光纖總線接口、1553B總線通信接口以及CAN總線通信接口等，各種硬件接口存在一定的差異性。

③數(shù)據(jù)傳輸協(xié)議多樣化。不同的嵌入式傳感器控制系統(tǒng)，可能會搭載在不同的平臺上，而不同的平臺之間，其數(shù)據(jù)傳輸協(xié)議也存在較大的差異。

④軟件模塊通信的松耦合性。即不同的嵌入式控制系統(tǒng)一般由相同的各種硬件、軟件調(diào)度邏輯算法集成，單一軟件模塊的功能普遍相同，具有很大的可復(fù)用性，如何保證該軟件模塊的松耦合性，是提高軟件復(fù)用度的關(guān)鍵點之一。而保證軟件模塊的松耦合性的關(guān)鍵還在于與其他軟件模塊的通信具有松耦合性。

綜上所述，嵌入式傳感器控制系統(tǒng)具有算法邏輯、硬件接口和數(shù)據(jù)傳輸協(xié)議多樣的特點，為了提高其可復(fù)用性、可擴展性和可移植性，在設(shè)計嵌入式軟件框架時，必須考慮盡量提高模塊的內(nèi)聚性，降低模塊之間的耦合性。

3 嵌入式控制系統(tǒng)軟件架構(gòu)方案

針對第2節(jié)所描述的嵌入式系統(tǒng)的特點，結(jié)合設(shè)計模式，對嵌入式控制系統(tǒng)的軟件架構(gòu)設(shè)計進(jìn)行了考慮和設(shè)計決策。

3.1 核心調(diào)度控制算法多樣性問題的解決

為了解決核心調(diào)度算法多樣性的問題，使用Bridge模式將抽象部分和具體實現(xiàn)部分進(jìn)行分離。這樣，當(dāng)核心調(diào)度算法改變時，嵌入式系統(tǒng)的其余部分不會受到影響。

Bridge模式主要由4種角色組成：

①抽象角色：它定義了抽象類的接口而且維護(hù)著一個指向?qū)崿F(xiàn)角色的引用；

②精確角色：實現(xiàn)并擴充由抽象角色定義的接口；

③實現(xiàn)角色：給出了實現(xiàn)類的接口，這里的接口與抽象角色中的接口可以不一致；

④具體實現(xiàn)角色：給出了實現(xiàn)角色定義接口的具體實現(xiàn)。

Bridge模式下的類圖如圖1所示。

圖1 Bridge模式下的類圖

參照使用Bridge模式，將核心調(diào)度控制算法進(jìn)行了抽象和封裝，這樣即使在系統(tǒng)設(shè)計實現(xiàn)的過程中，核心調(diào)度控制算法發(fā)生了變化，對整個系統(tǒng)的影響也微乎其微。

由此，我們確立了應(yīng)用節(jié)點層的概念。由嵌入式系統(tǒng)軟件框架確定應(yīng)用節(jié)點的接口規(guī)范，應(yīng)用開發(fā)人員開發(fā)并設(shè)計各類應(yīng)用節(jié)點，而各類應(yīng)用節(jié)點根據(jù)具體的調(diào)度控制算法不同，完成不同的具體實現(xiàn)。嵌入式系統(tǒng)軟件架構(gòu)下應(yīng)用節(jié)點層的類圖如圖2所示。

圖2 嵌入式系統(tǒng)軟件架構(gòu)下應(yīng)用節(jié)點層的類圖

3.2 硬件接口多樣化問題的解決

由于嵌入式系統(tǒng)中涉及的硬件接口多種多樣，為了與核心調(diào)度算法邏輯進(jìn)行隔離，結(jié)合設(shè)計模式，使用Factory模式完成各類硬件接口類的創(chuàng)建。

Factory模式由3部分組成：

①工廠類角色：含有一定的商業(yè)邏輯和判斷邏輯；

②抽象類產(chǎn)品角色：一般是具體產(chǎn)品繼承的父類或者實現(xiàn)的接口；

③具體產(chǎn)品角色：工廠類所創(chuàng)建的對象就是此角色的實例。

Factory模式的類圖如圖3所示。

圖3 Factory模式的類圖

參照使用Factory模式，確立了節(jié)點管理類，在節(jié)點管理中完成了對各種硬件接口的抽象，并根據(jù)不同硬件接口，提供硬件接口的生成操作，即對不同的硬件接口進(jìn)行具體實現(xiàn)。其類圖如圖4所示。

圖4 節(jié)點管理類的類圖

3.3 數(shù)據(jù)傳輸協(xié)議多樣化問題的解決

數(shù)據(jù)傳輸多樣化問題的本質(zhì)同系統(tǒng)核心調(diào)度控制算法的多樣性一樣，仍然使用Birdge模式來解決這一問題，對數(shù)據(jù)傳輸解析協(xié)議進(jìn)行了抽象，此處不再贅述。

3.4 軟件模塊通信的松耦合性問題的解決

為了使各個軟件模塊在通信過程中具有松耦合性，參照Observer模式，設(shè)計了節(jié)點通信層，各個軟件模塊的消息通信通過節(jié)點通信層完成傳遞，避免了相互之間的耦合。

Observer模式的組成部分包括：

①抽象目標(biāo)角色：目標(biāo)角色知道它的觀察者，可以有任意多個觀察者觀察同一個目標(biāo)，并且提供注冊和刪除觀察者對象的接口；

②抽象觀察者角色：為那些在目標(biāo)發(fā)生改變時需要獲得通知的對象定義一個更新接口；

③具體目標(biāo)角色：將有關(guān)狀態(tài)存入各個具體觀察者角色對象，當(dāng)它的狀態(tài)發(fā)生改變時，向它的各個觀察者發(fā)出通知；

④具體觀察者角色：存儲有關(guān)狀態(tài)，這些狀態(tài)應(yīng)與目標(biāo)的狀態(tài)保持一致。

Observer模式的類圖如圖5所示。

圖5 Observer模式的類圖

參照使用Observer模式，確立了節(jié)點通信層，各個應(yīng)用節(jié)點通過在節(jié)點通信層進(jìn)行消息的注冊，完成對應(yīng)消息的獲取和發(fā)送，從而解決了應(yīng)用節(jié)點之間的通信耦合性問題。

綜上所述，考慮到嵌入式控制系統(tǒng)的特點，確立了系統(tǒng)的軟件架構(gòu)。該軟件架構(gòu)如圖6所示。

其中軟件框架的層次劃分及功能描述如下：

①虛擬操作系統(tǒng)層完成對底層操作系統(tǒng)的封裝，以屏蔽上層應(yīng)用對于底層操作系統(tǒng)的依賴；

②節(jié)點管理層完成各種節(jié)點的創(chuàng)建、維護(hù)和管理；

③節(jié)點通信層完成上層各個應(yīng)用節(jié)點之間通信的封裝和功能實現(xiàn)；

④應(yīng)用節(jié)點層為上層應(yīng)用提供接口規(guī)范，以明確統(tǒng)一上層應(yīng)用節(jié)點的接口規(guī)范。

圖6 系統(tǒng)軟件架構(gòu)圖

結(jié) 語

通過建立統(tǒng)一的嵌入式軟件架構(gòu)，并借用成熟的軟件設(shè)計模式，能夠加大軟件復(fù)用程度、提高開發(fā)研制效率、降低研發(fā)成本，是嵌入式軟件開發(fā)的發(fā)展趨勢。

[1]Erich Gamma，Richard Helm，Ralph Johnson，et al.Design Patterns：Elements of Reusable Object-Oriented Software[M].San Antonio：Pearson Education，2000.

[2]郭峰.深入淺出設(shè)計模式[M].北京：中國鐵道出版社，2013.