上兩篇文章探討了在嵌入式開發中設計嵌入式軟件架構的五個步驟。到目前為止，我們已經看到現代嵌入式系統需要將軟件架構分為硬件相關和硬件無關的架構。我們還討論了在過程早期識別系統數據資產的好處。我們的討論揭示了一個重要的軟件架構原則，數據決定設計。

 

本文探索了設計嵌入式軟件架構的第三步：分解系統。

 

一旦團隊初步了解了數據資產以及它們如何在系統中移動，我們就準備好分解軟件架構了。分解不是讓我們的軟件腐爛分解成混亂！相反，分解是獲取我們的數據資產并創建軟件架構的構建塊的行為，如軟件任務、線程和其他組織機制。

 

架構師或團隊如何分解通常取決于他們的最終目標和系統的復雜性。可以使用三種分解方法來開發一個軟件架構。這些分解技術包括：

l 按安全性分解

l 按域分解

l 按任務分解

讓我們來看看這些如何幫助嵌入式軟件架構師。

 

l 按安全性分解

在嵌入式開發中對于具有需要從安全角度保護的數據資產的系統，首先的分解步驟之一是將體系結構進一步分為安全和非安全的體系結構部分。例如，如果我分解我們已經檢查過的電機控制器設備，架構圖可能如圖4所示。這是因為該圖根據數據資產應該位于的安全域來分隔數據資產。(威脅模型和安全分析可以識別這些資產。)

 圖4

 

通過安全性分離體系結構可以幫助體系結構識別需要特殊處理的數據資產和應用程序組件。例如，這些數據資產可能需要放在硬件隔離的執行環境中。此外，這些數據資產可能需要配置額外的內存保護單元(MPU)來限制訪問。最后，甚至可能需要實現信任根服務來管理和訪問數據資產。

 

l 按域分解

按領域分解軟件體系結構已經成為一種非常流行的軟件體系結構設計方法。在最廣泛的意義上，步驟1，分離軟件架構，嵌入式開發人員已經將軟件架構分解為兩個域：實時硬件域和應用程序域。按安全性進行分解還確定了另外兩個域：安全和非安全應用程序域。這些領域中的每一個都可以單獨分解和構建。

理論上，體系結構可以進一步分解成額外的領域，允許領域專家專注于該領域的體系結構。例如，圖5顯示，對圖4稍作重新排列后，數據中出現了三個額外的域:

輸入域

電機控制領域

輸出域

圖5

 

有趣的是，當以這種方式看待領域時，它們通常跨越應用程序層，包含與領域相關的所有內容。例如，電機控制域管理高級應用程序狀態，并通過抽象層與低級硬件交互。甚至可能需要一個應用程序接口，以便域之間進行交互，正如在輸入和電機控制域之間可以看到的那樣。使用RTOS為各個域創建消息隊列以便彼此交互并不罕見。

 

l 按任務分解

超過50%的嵌入式系統使用實時操作系統(RTOS)。即使嵌入式開發人員在不使用RTOS的系統中，使用協作執行任務的周期性調度程序也是很常見的。任務是源代碼和架構思想的邏輯分組，它們相互關聯并解決軟件問題。或者在我們的例子中，一個任務可能封裝了跨多個軟件域的數據資產以及數據上的操作和過程。

基于任務分解初始架構可能是有益的。例如，如果我們再看看我們的電機控制設備，我們可以使用區域分解為系統創建三個任務：

輸入任務

運動控制任務

輸出任務

 

根據系統的不同，這可能沒問題。然而，如果我們查看每個領域的細節，我感覺每個任務都試圖做得太多，隨著系統的發展，它可能會有可伸縮性的問題。因此，相反，基于我們已經確定的數據資產，我可能傾向于如圖6所示的任務分解。

圖6

 

如你所見，該系統中有五項任務:

控制器任務

傳感器任務

Rx任務

電機任務

顯示任務

這種任務分解將更加靈活，因為每個任務都有一個它所關注的單一職責。例如，如果客戶近期需要診斷，嵌入式開發人員可以添加診斷任務。如果添加更多傳感器，傳感器任務可以管理它們。如果我們需要通過遙測傳輸設備狀態，我們可以添加一個遙測任務和一個傳輸任務。如果我們設計了一個使用電機的新裝置，我們就可以把我們的電機任務重新利用起來！

 

填寫細節

一旦我們將我們的系統分解成高級的塊和任務，我們就可以分解一些初始的通信架構。例如，在上一節中，我們看到我們的初始架構有五個任務。我們可以在幾個區域看到數據，數據流跨越了任務之間的界限：

傳感器任務到控制器任務

Rx任務到控制器任務

控制器任務到運動任務

要顯示任務的控制器任務

邊界交叉表明這些任務需要交互以交換數據或以某種方式相互通信。作為分解步驟的一部分，我們可以突出這些交互，并確定傳輸數據的潛在機制。然而，盡可能推遲做出架構決策通常是一種最佳實踐。例如，在此階段，我們可能會看到傳感器任務與控制器任務的交互，并意識到有幾種解決方案：

使用消息隊列將溫度數據傳輸到控制器

使用帶有互斥體的共享內存位置來保護數據

 

軟件架構設計第3步結論

正如我們在本文中看到的，我們在前面步驟中識別的數據已經開始自然地決定我們如何將系統分解成域和任務。數據在系統中的流動方式突出了任務之間的交互。雖然通常有多種解決方案來處理任務交互，但我們經常將最終決定推遲到設計過程的后期。推遲決策通常允許嵌入式開發人員更容易地改變和發展設計，并且只在必要的時候才做出決定。