軟件設(shè)計(jì)模式在嵌入式控制系統(tǒng)中的應(yīng)用

賴炳宇，李言華

（中國電子科技集團(tuán)第29研究所，成都610000）

引 言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖1 Bridge模式下的類圖

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

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

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

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

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

Factory模式由3部分組成：

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

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

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

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

圖3 Factory模式的類圖

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

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

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

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

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

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

Observer模式的組成部分包括：

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

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

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

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

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

圖5 Observer模式的類圖

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

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

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

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

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

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

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

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

結(jié) 語

通過建立統(tǒng)一的嵌入式軟件架構(gòu)，并借用成熟的軟件設(shè)計(jì)模式，能夠加大軟件復(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è)計(jì)模式[M].北京：中國鐵道出版社，2013.