軟件設計模式在嵌入式控制系統中的應用

賴炳宇，李言華

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

引 言

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

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

參考目前的桌面通用計算機軟件可以預見，通過建立可復用面向對象的嵌入式軟件架構，能夠增強嵌入式軟件的可復用性、可擴展性和可移植性，降低研發周期和成本。

1 軟件框架和設計模式

軟件框架（Software Framework），通常指的是實現某個業界標準或完成特定基本任務的軟件組件規范，也指實現某個軟件組件規范時提供所要求的基礎功能的軟件產品。軟件框架的功能類似于基礎設施，與具體的軟件應用無關，只是提供并實現最基礎的軟件架構和體系。軟件設計師通常根據特定的軟件框架實現更為復雜的系統應用和業務邏輯。

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

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

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

2 嵌入式傳感器控制系統的特點及軟件框架設計考慮

在涉及系統調度控制領域的嵌入式系統中，由于需要實現的功能和接口日趨復雜，總結起來，具有如下特點：

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

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

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

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

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

3 嵌入式控制系統軟件架構方案

針對第2節所描述的嵌入式系統的特點，結合設計模式，對嵌入式控制系統的軟件架構設計進行了考慮和設計決策。

3.1 核心調度控制算法多樣性問題的解決

為了解決核心調度算法多樣性的問題，使用Bridge模式將抽象部分和具體實現部分進行分離。這樣，當核心調度算法改變時，嵌入式系統的其余部分不會受到影響。

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

①抽象角色：它定義了抽象類的接口而且維護著一個指向實現角色的引用；

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

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

④具體實現角色：給出了實現角色定義接口的具體實現。

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

圖1 Bridge模式下的類圖

參照使用Bridge模式，將核心調度控制算法進行了抽象和封裝，這樣即使在系統設計實現的過程中，核心調度控制算法發生了變化，對整個系統的影響也微乎其微。

由此，我們確立了應用節點層的概念。由嵌入式系統軟件框架確定應用節點的接口規范，應用開發人員開發并設計各類應用節點，而各類應用節點根據具體的調度控制算法不同，完成不同的具體實現。嵌入式系統軟件架構下應用節點層的類圖如圖2所示。

圖2 嵌入式系統軟件架構下應用節點層的類圖

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

由于嵌入式系統中涉及的硬件接口多種多樣，為了與核心調度算法邏輯進行隔離，結合設計模式，使用Factory模式完成各類硬件接口類的創建。

Factory模式由3部分組成：

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

②抽象類產品角色：一般是具體產品繼承的父類或者實現的接口；

③具體產品角色：工廠類所創建的對象就是此角色的實例。

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

圖3 Factory模式的類圖

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

圖4 節點管理類的類圖

3.3 數據傳輸協議多樣化問題的解決

數據傳輸多樣化問題的本質同系統核心調度控制算法的多樣性一樣，仍然使用Birdge模式來解決這一問題，對數據傳輸解析協議進行了抽象，此處不再贅述。

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

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

Observer模式的組成部分包括：

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

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

③具體目標角色：將有關狀態存入各個具體觀察者角色對象，當它的狀態發生改變時，向它的各個觀察者發出通知；

④具體觀察者角色：存儲有關狀態，這些狀態應與目標的狀態保持一致。

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

圖5 Observer模式的類圖

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

綜上所述，考慮到嵌入式控制系統的特點，確立了系統的軟件架構。該軟件架構如圖6所示。

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

①虛擬操作系統層完成對底層操作系統的封裝，以屏蔽上層應用對于底層操作系統的依賴；

②節點管理層完成各種節點的創建、維護和管理；

③節點通信層完成上層各個應用節點之間通信的封裝和功能實現；

④應用節點層為上層應用提供接口規范，以明確統一上層應用節點的接口規范。

圖6 系統軟件架構圖

結 語

通過建立統一的嵌入式軟件架構，并借用成熟的軟件設計模式，能夠加大軟件復用程度、提高開發研制效率、降低研發成本，是嵌入式軟件開發的發展趨勢。

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

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