上一篇文章討論了設計嵌入式軟件架構的五個步驟的第一步驟，我們探討了在嵌入式開發中將嵌入式軟件系統視為兩種架構的好處：獨立于硬件的應用業務架構和依賴于硬件的實時架構。

在今天的帖子中，我們將探索設計嵌入式軟件架構的第二步：識別和跟蹤數據資產。

當團隊一起設計他們的嵌入式軟件時，工程師有兩種傾向；首先，他們想從第一天就進入硬件領域。工程師們表現得好像與硬件交互的底層代碼就是最終產品，一刻也不能浪費。不幸的是，這是嵌入式軟件開發的過時觀點。在大多數系統中，真正的價值在于應用程序代碼，即體系結構中與硬件無關的部分。

第二，工程師們幾乎立即開始拋出圍繞中斷、消息傳遞、RTOS交互等設計模式的架構思想。雖然集思廣益并讓想法得到評估是很好的，但是你如何知道什么架構概念和設計模式在第一天就與設計問題相匹配呢？答案是你沒有！

一旦嵌入式開發團隊完成了第一步，分離軟件架構，設計嵌入式軟件架構的第二步就是識別和跟蹤系統中的數據資產。數據資產是系統用來幫助其執行功能的任何數據。例如，嵌入式系統可能有如下數據資產：

l 加密密鑰

l 唯一的標識號

l 像素地圖

l 控制器狀態

更多的數據資產進入一個系統，當我們將一切歸結為設計和構建實時嵌入式系統時，我們所做的核心工作是管理數據。

嵌入式軟件設計的首要原則

現代嵌入式軟件設計的首要原則是“數據決定設計”我們可以為完成給定的任務創建各種令人興奮和獨特的架構。然而，最有效的架構是圍繞系統數據資產設計的架構。這是因為所有無關緊要的垃圾，因為它是最新和最偉大的，或者因為我們認為它是優雅的，所以經常會被丟棄。

當我們關注數據時，體系結構可能會過度關注它應該如何處理數據。事實證明，只能對數據進行一些操作。首先，系統可以輸入數據。例如，用戶可以按下按鈕或通過通信接口接收串行數據。第二，系統可以輸出數據。例如，向顯示器顯示像素圖或驅動電機。第三，系統可以處理數據。例如，可能串行數據以分組格式進入系統，然后進行解碼。進行處理以驗證數據包，然后解壓縮存儲的數據。最后，系統可以將數據存儲在易失性或非易失性存儲器中。

識別數據資產和可以在數據上執行的操作可以極大地幫助嵌入式開發團隊設計其嵌入式軟件架構。數據資產就像向架構師揮舞的紅旗，表明設計中的架構需求。不幸的是，太多的團隊忽略了數據，而是在了解他們試圖用系統解決的數據問題之前追逐現代設計模式。

以數據為中心的架構意味著什么？

許多嵌入式軟件開發人員會覺得“數據決定設計”這個想法有點奇怪。這很令人驚訝，因為在面向對象編程中，我們專注于創建對象，這些對象是數據的集合，并對這些數據進行操作。老實說，以數據為中心的架構設計觀點并不新鮮。然而，從數據的角度來看架構有很多優點。

首先，以數據為中心的架構方法非常適合那些系統存在安全問題的團隊。如果你對保護你的嵌入式系統感興趣，你必須執行威脅模型安全分析(TMSA)。這種分析要求開發人員識別系統中的各種數據資產，并確定他們需要的保護級別。TMSA需要在設計系統架構之前執行，這意味著數據決定的架構所需的許多細節已經可用。

第二，識別數據資產可以幫助我們確定如何在組件級別分解系統。假設我們是優秀的架構師，并遵循單一責任原則(SRP)。在這種情況下，很有可能我們識別的每個數據資產都將被包裝在它的模塊中，并具有對其進行操作的功能。

第三，跟蹤各種數據資產如何交互可以開始提示系統在應用程序級別的架構。例如，在嵌入式開發中，假設我可以看到輸入到系統中的數據及其與處理數據的速率相比的高頻率。在這種情況下，我可以開始將交互與接收數據的輸入活動和處理數據的活動綁定。在早期的架構階段，我不會選擇是使用中斷、緩沖區還是直接內存訪問（DMA）來接收高頻數據輸入。我只想把問題解決，等到有必要時再做最后決定。我不會立即跳出來說處理活動是一項RTOS任務。該活動可能是一項任務或其他內容。現在說還為時過早。雖然工程師經常努力盡快鎖定盡可能多的細節，但優秀的軟件架構師會盡可能長時間地推遲決策，以最大限度地提高靈活性。

結論

設計嵌入式軟件架構的第二步是識別和跟蹤系統中的數據資產。對于一個通常專注于硬件的嵌入式軟件工程師來說，過度關注數據似乎有些奇怪。改變我們思維模式的一個方法是修改嵌入式軟件的定義，使其:

嵌入式軟件是為確定性運行而設計和構建的代碼，通常有實時期限，通過各種形式的輸入、處理、輸出和存儲來管理數據。

強大的嵌入式軟件架構允許數據決定設計。在嵌入式開發中，識別數據，然后跟蹤它如何與系統中的其他數據交互，可以幫助軟件架構師看到架構是如何出現的。架構圖通常從30，000英尺的高處開始，提示組件和任務可能有意義的地方。然而，在這個階段，我們只想識別數據資產和它們所涉及的操作。