嵌入式專案中維護乾淨程式碼的狀態機圖最佳實務

嵌入式系統運作於資源受限且可靠性至關重要的環境中。🌍 在為微控制器或即時作業系統設計軟體時，邏輯通常圍繞著不同的運作模式展開。裝置可能啟動、等待輸入、處理資料，然後進入休眠狀態。妥善管理這些轉換至關重要。

狀態機圖（SMD）是統一塑模語言（UML）的一部分，為此類行為提供視覺藍圖。然而，圖表的價值取決於其所對應的程式碼品質。🧱 本指南概述了設計狀態機圖的最佳實務，使其能直接轉換為可維護且穩健的嵌入式程式碼。

📋 理解狀態機在嵌入式設計中的角色

在深入語法或佈局之前，了解為何狀態機優於雜亂的邏輯或複雜的巢狀if-else敘述是至關重要的。主要目標是確定性。

• 可預測性：根據目前的狀態與輸入事件，下一狀態總是明確定義的。
• 可追蹤性：工程師可以視覺化追蹤系統如何回應外部觸發。
• 可維護性：新增狀態或修改轉換的影響範圍是局部的，可降低破壞無關功能的風險。

在嵌入式專案的脈絡下，這種視覺清晰度能降低除錯時的認知負荷。當裝置行為出乎預期時，圖表便成為預期行為的唯一依據。

🏗️ 結構最佳實務以確保清晰度

視覺雜亂是維護的敵人。一張看起來像蜘蛛網的圖表，代表其對應的程式碼庫將難以修改。遵循這些結構性指南，以保持模型的清晰。

1. 每張圖表的狀態數量應有限制

雖然沒有硬性限制，但若一張圖表包含超過20個狀態，通常表示需要重構。高複雜度暗示模型試圖承擔過多功能。應將大型模型拆分為子圖表或複合狀態。

• 經驗法則：如果你不斷地縮放以看見整體圖像，就應該拆分圖表。
• 策略：使用階層式狀態來分組相關行為，而不會使頂層過於雜亂。

2. 一致的命名慣例

命名不僅是標籤，更是一種溝通。狀態名稱應描述一種狀態，而非動作。轉換標籤應描述一個事件。

• 良好範例： 閒置, 處理中, 閒置 -> 按鈕已按下 -> 處理中.
• 錯誤： 開始流程, 等待輸入, 按鈕 -> 開始.

狀態名稱應為名詞或名詞片語，代表穩定的狀態。轉移標籤應為動詞或動詞片語，代表變更觸發。

3. 最小化跨層轉移

跨越整個圖表的轉移會造成耦合。如果狀態 A 需要轉移到狀態 Z，而它們相距甚遠，請考慮是否可以透過共用的中間狀態或層次結構來調解。

• 轉移通常應連接鄰近或邏輯上相關的狀態。
• 避免出現「義大利麵式連接」，即線條在圖表畫布上交叉縱橫。

🧩 透過層次結構管理複雜性

隨著系統擴大，平坦的狀態機將變得難以管理。UML 支援層次狀態機，允許狀態包含其他狀態。這是擴展複雜性的主要工具。

1. 組合狀態（超狀態）

組合狀態是一種包含其他狀態的狀態。它作為容器使用。這對於分組操作模式非常有用。

• 使用案例： 一個 作業 超狀態，包含 正常模式, 維修模式，以及診斷模式.
• 優勢：您可以定義適用於所有子狀態的轉移，而無需重複。

2. 進入與離開動作

進入或離開狀態時執行的動作是初始化和清理的強大工具。然而，必須謹慎使用，以避免隱藏的依賴關係。

• 進入動作：在進入狀態時，初始化變數、啟動計時器或啟用中斷。
• 離開動作：在離開狀態時，停止計時器、儲存資料或停用中斷。
• 警告：不要在此處放置繁重的邏輯。保持動作輕量，以避免阻塞。

3. 正交區域

某些系統需要處理並行行為。正交區域允許一個狀態同時存在於多個狀態中。這通常用於獨立的子系統，例如顯示控制器和網路處理器。

• 視覺呈現：以虛線表示，將狀態框劃分為不同區段。
• 實作：程式結構必須支援平行執行，通常透過獨立的任務或中斷處理常式來實現。

⚡ 事件與轉移的處理

狀態機的邏輯位於轉移之中。這些是促使系統從一種狀態轉移到另一種狀態的觸發條件。

1. 事件過濾

並非每個事件都需要在每個狀態中觸發轉移。應明確定義守衛條件來控制流程。這可防止系統對無法處理的事件做出反應。

• 守衛條件：一個布林表達式，必須為真時轉移才會發生。
• 範例： ButtonPressed[Level == 5].

2. 避免事件風暴

過多的事件會造成模糊性。如果一個狀態監聽20個不同的事件，它就會變成「神級狀態」。應保持事件的覆蓋範圍在可管理的範圍內。

• 在可能的情況下，將相關事件分組為複合事件。
• 使用中央事件分發器，將事件的生產者與消費者解耦。

3. 自轉移

返回到同一狀態的轉移是有效且有用的。它允許系統執行操作而不改變其模式。

• 使用情境：記錄錯誤、更新計數器或切換LED。
• 注意：確保該操作不會導致狀態機被輪詢時產生無限循環。

🔄 歷史狀態：保留上下文

有時，系統必須記住離開複合狀態前的位置。歷史狀態解決了這個問題。

1. 淺層歷史

表示系統應返回到複合狀態的最後一個活躍子狀態。它不會記住子狀態的歷史。

2. 深層歷史

表示系統應返回到整個層次結構中最後一個活躍狀態。這對於跨越多個層級的複雜工作流程非常有用。

• 情境： 一個裝置進入 設定 狀態，然後進入 網路 子狀態。如果被中斷並恢復，應返回到 網路，而不是僅僅回到 設定.
• 實作：需要將狀態ID儲存在非揮發性記憶體或RAM中。

📊 比較：良好與不良實務

為了鞏固這些概念，直接比較以下情境。

面向	❌ 反模式	✅ 最佳實務
狀態命名	TurnOnLED()	LED_Active
轉移邏輯	轉移標籤內的邏輯	動作/效果區段中的邏輯
圖表大小	所有邏輯集中在一個圖表中	使用階層狀態
事件處理	一個狀態處理所有事件	使用守衛過濾事件
程式碼耦合	邏輯中硬編碼的狀態ID	使用列舉來定義狀態ID
文件說明	變更後圖表過時	整合至CI/CD流程

🔗 圖表與實作的連結

設計與程式碼之間的落差，正是錯誤常藏身之處。確保狀態機圖表與產生的或手動撰寫的程式碼保持一致，是一項關鍵的最佳實務。

1. 命名一致性

圖表中使用的識別符必須直接對應到程式碼中的識別符。如果一個狀態在模型中命名為啟動，則C/C++的列舉應為啟動.

• 使用自動化程式碼產生工具，以減少手動對應錯誤。
• 若手動撰寫程式碼，則透過靜態檢查工具強制執行嚴格的命名規範。

2. 可追溯性矩陣

維持一份文件或試算表，將圖示元素與特定的程式碼功能或檔案連結。這對於安全關鍵認證（例如 ISO 26262、DO-178C）至關重要。

• 狀態 ID： 對應至 switch(state) case。
• 轉移： 對應至函數呼叫或邏輯分支。
• 守衛： 對應至驗證函數。

3. 程式碼產生策略

使用程式碼產生時，工具應產生乾淨、易讀的程式碼。避免產生難以手動除錯的程式碼。

• 確保產生的程式碼包含註解，參考圖示的狀態 ID。
• 在程式碼審查過程中審查產生的程式碼，以確保其符合架構意圖。

🧪 測試與驗證

狀態機圖示是一份規格說明，並非測試案例。然而，它會引導測試策略。

1. 狀態覆蓋

確保在測試期間每個狀態至少被訪問一次。這可以透過覆蓋率工具追蹤。

• 檢查是否存在無法到達的狀態。
• 確認所有進入/離開動作都能正確觸發。

2. 轉移覆蓋

測試每個已定義的轉移。這包括在特定來源狀態下觸發特定事件。

• 使用壓力測試來驗證高負載下的轉移。
• 確認無效轉移會被忽略或妥善處理（預設行為）。

3. 故障注入

測試系統在出錯時的反應。如果事件在錯誤狀態下到達，會發生什麼情況？

• 實作一個 錯誤 或 未知狀態 狀態以捕捉意外的轉移。
• 記錄錯誤以協助事後分析。

🛠️ 常見陷阱與解決方案

即使是經驗豐富的工程師也會犯錯。以下是常見問題及其解決方法。

1. 「神態」問題

當單一狀態包含過多邏輯時就會發生此問題，通常作為未定義行為的萬能容器。

• 解決方案：將邏輯拆分為多個特定狀態。
• 解決方案：為錯誤使用備用狀態，但保持主要邏輯清晰區分。

2. 歷史狀態濫用

歷史狀態可能讓新工程師難以跟上流程。它們會引入隱藏狀態。

• 解決方案：僅在必要時使用歷史狀態（例如，持久化會話）。
• 解決方案：在模型註釋中明確記錄歷史狀態的使用方式。

3. 與硬體緊密耦合

狀態機通常直接存取硬體暫存器，導致在個人電腦上難以測試。

• 解決方案：在狀態機與硬體之間使用硬體抽象層（HAL）。
• 解決方案：狀態機應與邏輯服務互動，而非物理接腳。

📈 長期維護圖表

圖表是一份活文件，必須隨著程式碼一起演進。

• 版本控制：將圖表與原始碼儲存在同一個程式庫中。使用標準的版本控制系統。
• 重構：重構程式碼時，應立即更新圖表。不要將圖表視為過時的文件。
• 視覺風格：在專案中保持視覺風格一致。使用相同的顏色、字型和版面規則。

🎯 設計紀律總結

開發可靠的嵌入式軟體需要紀律。狀態機圖提供了管理複雜性的必要結構。透過遵循命名、層次結構和轉移邏輯方面的最佳實務，您將建立一個更易於建構、測試和維護的系統。

在清晰的模型上投入的努力，會在除錯階段帶來回報。一個文件完整狀態機可減少透過程式碼轉儲追蹤邏輯所花的時間。它能將焦點從「程式碼在做什麼？」轉移到「為什麼程式碼會這樣做？」。

請記住，圖表不僅是設計工具，也是溝通工具。它與硬體工程師、軟體開發人員和測試人員溝通。保持清晰、準確，並與實際實作保持一致。