上兩篇文章探討了在嵌入式開發(fā)中設(shè)計(jì)嵌入式軟件架構(gòu)的五個步驟。到目前為止，我們已經(jīng)看到現(xiàn)代嵌入式系統(tǒng)需要將軟件架構(gòu)分為硬件相關(guān)和硬件無關(guān)的架構(gòu)。我們還討論了在過程早期識別系統(tǒng)數(shù)據(jù)資產(chǎn)的好處。我們的討論揭示了一個重要的軟件架構(gòu)原則，數(shù)據(jù)決定設(shè)計(jì)。
本文探索了設(shè)計(jì)嵌入式軟件架構(gòu)的第三步：分解系統(tǒng)。
一旦團(tuán)隊(duì)初步了解了數(shù)據(jù)資產(chǎn)以及它們?nèi)绾卧谙到y(tǒng)中移動，我們就準(zhǔn)備好分解軟件架構(gòu)了。分解不是讓我們的軟件腐爛分解成混亂！相反，分解是獲取我們的數(shù)據(jù)資產(chǎn)并創(chuàng)建軟件架構(gòu)的構(gòu)建塊的行為，如軟件任務(wù)、線程和其他組織機(jī)制。
架構(gòu)師或團(tuán)隊(duì)如何分解通常取決于他們的最終目標(biāo)和系統(tǒng)的復(fù)雜性。可以使用三種分解方法來開發(fā)一個軟件架構(gòu)。這些分解技術(shù)包括：
l 按安全性分解
l 按域分解
l 按任務(wù)分解
讓我們來看看這些如何幫助嵌入式軟件架構(gòu)師。
l 按安全性分解
在嵌入式開發(fā)中對于具有需要從安全角度保護(hù)的數(shù)據(jù)資產(chǎn)的系統(tǒng)，首先的分解步驟之一是將體系結(jié)構(gòu)進(jìn)一步分為安全和非安全的體系結(jié)構(gòu)部分。例如，如果我分解我們已經(jīng)檢查過的電機(jī)控制器設(shè)備，架構(gòu)圖可能如圖4所示。這是因?yàn)樵搱D根據(jù)數(shù)據(jù)資產(chǎn)應(yīng)該位于的安全域來分隔數(shù)據(jù)資產(chǎn)。(威脅模型和安全分析可以識別這些資產(chǎn)。)
圖4
通過安全性分離體系結(jié)構(gòu)可以幫助體系結(jié)構(gòu)識別需要特殊處理的數(shù)據(jù)資產(chǎn)和應(yīng)用程序組件。例如，這些數(shù)據(jù)資產(chǎn)可能需要放在硬件隔離的執(zhí)行環(huán)境中。此外，這些數(shù)據(jù)資產(chǎn)可能需要配置額外的內(nèi)存保護(hù)單元(MPU)來限制訪問。最后，甚至可能需要實(shí)現(xiàn)信任根服務(wù)來管理和訪問數(shù)據(jù)資產(chǎn)。
l 按域分解
按領(lǐng)域分解軟件體系結(jié)構(gòu)已經(jīng)成為一種非常流行的軟件體系結(jié)構(gòu)設(shè)計(jì)方法。在最廣泛的意義上，步驟1，分離軟件架構(gòu)，嵌入式開發(fā)人員已經(jīng)將軟件架構(gòu)分解為兩個域：實(shí)時硬件域和應(yīng)用程序域。按安全性進(jìn)行分解還確定了另外兩個域：安全和非安全應(yīng)用程序域。這些領(lǐng)域中的每一個都可以單獨(dú)分解和構(gòu)建。
理論上，體系結(jié)構(gòu)可以進(jìn)一步分解成額外的領(lǐng)域，允許領(lǐng)域?qū)＜覍Ｗ⒂谠擃I(lǐng)域的體系結(jié)構(gòu)。例如，圖5顯示，對圖4稍作重新排列后，數(shù)據(jù)中出現(xiàn)了三個額外的域:
輸入域
電機(jī)控制領(lǐng)域
輸出域
圖5
有趣的是，當(dāng)以這種方式看待領(lǐng)域時，它們通?？缭綉?yīng)用程序?qū)?，包含與領(lǐng)域相關(guān)的所有內(nèi)容。例如，電機(jī)控制域管理高級應(yīng)用程序狀態(tài)，并通過抽象層與低級硬件交互。甚至可能需要一個應(yīng)用程序接口，以便域之間進(jìn)行交互，正如在輸入和電機(jī)控制域之間可以看到的那樣。使用RTOS為各個域創(chuàng)建消息隊(duì)列以便彼此交互并不罕見。
l 按任務(wù)分解
超過50%的嵌入式系統(tǒng)使用實(shí)時操作系統(tǒng)(RTOS)。即使嵌入式開發(fā)人員在不使用RTOS的系統(tǒng)中，使用協(xié)作執(zhí)行任務(wù)的周期性調(diào)度程序也是很常見的。任務(wù)是源代碼和架構(gòu)思想的邏輯分組，它們相互關(guān)聯(lián)并解決軟件問題。或者在我們的例子中，一個任務(wù)可能封裝了跨多個軟件域的數(shù)據(jù)資產(chǎn)以及數(shù)據(jù)上的操作和過程。
基于任務(wù)分解初始架構(gòu)可能是有益的。例如，如果我們再看看我們的電機(jī)控制設(shè)備，我們可以使用區(qū)域分解為系統(tǒng)創(chuàng)建三個任務(wù)：
輸入任務(wù)
運(yùn)動控制任務(wù)
輸出任務(wù)
根據(jù)系統(tǒng)的不同，這可能沒問題。然而，如果我們查看每個領(lǐng)域的細(xì)節(jié)，我感覺每個任務(wù)都試圖做得太多，隨著系統(tǒng)的發(fā)展，它可能會有可伸縮性的問題。因此，相反，基于我們已經(jīng)確定的數(shù)據(jù)資產(chǎn)，我可能傾向于如圖6所示的任務(wù)分解。
圖6
如你所見，該系統(tǒng)中有五項(xiàng)任務(wù):
控制器任務(wù)
傳感器任務(wù)
Rx任務(wù)
電機(jī)任務(wù)
顯示任務(wù)
這種任務(wù)分解將更加靈活，因?yàn)槊總€任務(wù)都有一個它所關(guān)注的單一職責(zé)。例如，如果客戶近期需要診斷，嵌入式開發(fā)人員可以添加診斷任務(wù)。如果添加更多傳感器，傳感器任務(wù)可以管理它們。如果我們需要通過遙測傳輸設(shè)備狀態(tài)，我們可以添加一個遙測任務(wù)和一個傳輸任務(wù)。如果我們設(shè)計(jì)了一個使用電機(jī)的新裝置，我們就可以把我們的電機(jī)任務(wù)重新利用起來！
填寫細(xì)節(jié)
一旦我們將我們的系統(tǒng)分解成高級的塊和任務(wù)，我們就可以分解一些初始的通信架構(gòu)。例如，在上一節(jié)中，我們看到我們的初始架構(gòu)有五個任務(wù)。我們可以在幾個區(qū)域看到數(shù)據(jù)，數(shù)據(jù)流跨越了任務(wù)之間的界限：
傳感器任務(wù)到控制器任務(wù)
Rx任務(wù)到控制器任務(wù)
控制器任務(wù)到運(yùn)動任務(wù)
要顯示任務(wù)的控制器任務(wù)
邊界交叉表明這些任務(wù)需要交互以交換數(shù)據(jù)或以某種方式相互通信。作為分解步驟的一部分，我們可以突出這些交互，并確定傳輸數(shù)據(jù)的潛在機(jī)制。然而，盡可能推遲做出架構(gòu)決策通常是一種最佳實(shí)踐。例如，在此階段，我們可能會看到傳感器任務(wù)與控制器任務(wù)的交互，并意識到有幾種解決方案：
使用消息隊(duì)列將溫度數(shù)據(jù)傳輸?shù)娇刂破?/span>
使用帶有互斥體的共享內(nèi)存位置來保護(hù)數(shù)據(jù)
軟件架構(gòu)設(shè)計(jì)第3步結(jié)論
正如我們在本文中看到的，我們在前面步驟中識別的數(shù)據(jù)已經(jīng)開始自然地決定我們?nèi)绾螌⑾到y(tǒng)分解成域和任務(wù)。數(shù)據(jù)在系統(tǒng)中的流動方式突出了任務(wù)之間的交互。雖然通常有多種解決方案來處理任務(wù)交互，但我們經(jīng)常將最終決定推遲到設(shè)計(jì)過程的后期。推遲決策通常允許嵌入式開發(fā)人員更容易地改變和發(fā)展設(shè)計(jì)，并且只在必要的時候才做出決定。
