狀態機圖基礎：嵌入式系統初學者的一步一步指南

嵌入式系統運行在嚴格限制的環境中。每一個時鐘週期都至關重要，每一字節的記憶體都不可忽視。在這種環境下，程式碼的清晰度不僅是可有可無的優點；更是確保穩定與安全的必要條件。實現這種清晰度最強大的工具之一，是統一建模語言（UML）框架中的狀態機圖。這些圖表提供了軟體如何隨時間對事件作出反應的視覺藍圖。

理解如何使用狀態機來建模邏輯，是設計穩健嵌入式應用的基礎。無論你正在開發簡單的恆溫器，還是複雜的汽車控制單元，將軟體的生命週期可視化，有助於在邏輯錯誤演變為硬體故障之前加以預防。本指南將分解建立有效狀態機圖所需的關鍵概念、組件與構建方法。

🧠 什麼是狀態機圖？

狀態機圖，通常稱為狀態圖或以狀態為焦點的活動圖，用來表示系統的動態行為。與僅映射線性步驟序列的流程圖不同，狀態機映射的是系統在任何時刻所處的條件系統在任何特定時刻所處的條件。它回答的問題是：「系統目前的樣貌是什麼，什麼會改變這種樣貌？」

在嵌入式系統的背景下，這通常等同於有限狀態機（FSM）。「有限」這一點至關重要。它表示系統在任何給定時刻只能處於一個特定狀態。系統不可能同時處於「執行中」與「停止」狀態。這種明確的區分簡化了除錯與測試的過程。

🔑 狀態機的核心組件

要建立圖表，你必須理解相關術語。每個有效的圖表都是由一組特定的構建模塊組成的。這些元素定義了系統的結構與邏輯。

1. 狀態

狀態代表物件或系統生命週期中的某種條件。這是一段系統等待事件發生的時間。視覺上，狀態通常以圓角矩形表示。

• 簡單狀態： 一種沒有內部結構的基本狀態（例如：「空閒」、「激活」）。
• 複合狀態： 一種包含其他子狀態的狀態（例如：「處理中」可能包含「讀取感測器」或「寫入資料」）。
• 初始狀態： 機器的起始點。通常以實心圓圈表示。
• 終止狀態： 終止點。通常以一個實心圓圈位於較大圓圈內來表示。

2. 轉移

轉移是指從一個狀態移動到另一個狀態的過程。它代表系統狀態的改變。轉移以連接兩個狀態的箭頭來表示。

• 轉移是瞬間完成的。系統不會在「轉移中」耗費時間。
• 它們由特定事件觸發。
• 它們可能包含條件（守衛），這些條件必須滿足才能完成轉移。

3. 事件

事件是一種重要的發生事件，會觸發轉移。在嵌入式系統中，事件通常包括：

• 硬體中斷（例如：按鈕按下）。
• 逾時（例如：計時器到期）。
• 軟體信號（例如：從網路接收的資料）。
• 狀態進入/離開完成。

4. 動作

動作是系統執行的工作。它們與狀態或轉移相關聯。主要有三種類型的動作：

• 進入動作：系統進入狀態時立即執行的程式碼。
• 離開動作：系統離開狀態時立即執行的程式碼。
• 持續動作：系統處於狀態期間持續執行的程式碼（例如，馬達控制迴圈）。

5. 保護條件

保護條件是一種布林表示式，用來決定轉移是否可以發生。它如同守門人一般。即使事件發生，狀態也不會改變，除非保護條件評估為真。

• 範例：if (電池電量 > 20%)
• 範例：if (溫度 < 100)

📊 元件對照表

為釐清這些元件之間的差異，請參考以下表格。

元件	視覺符號	功能	時間
狀態	圓角矩形	代表一種條件	持續時間（可長可短）
轉移	箭頭	連接兩個狀態	瞬間
事件	箭頭上的文字	觸發轉移	發生點
守衛	方括號 [] 中的文字	驗證轉移	轉移執行前
動作	箭頭上或狀態中的文字	執行邏輯	進入、退出或停留期間

🛠️ 建立圖表的逐步指南

從零開始建立圖表可能令人感到壓力。遵循此結構化流程，以確保邏輯一致性與完整性。

步驟 1：識別系統範圍

定義狀態機所控制的內容。是整個裝置，還是僅特定模組？保持範圍可控至關重要。例如，不要試圖在一個圖表中模擬整個汽車電子系統。專注於「引擎控制單元」或「電力管理模組」。

步驟 2：列出狀態

腦力激盪系統可能處於的每種條件。問自己：「運作的明確模式有哪些？」

• 關機
• 啟動中
• 待機
• 主動運作
• 錯誤恢復

確保這些狀態互斥。系統不應同時處於兩個狀態。

步驟 3：定義事件

什麼會導致系統在步驟 2 所列狀態之間切換？請觀察輸入訊號。

• 使用者輸入（按鈕按壓）
• 外部訊號（感測器資料）
• 內部定時器
• 系統錯誤

步驟 4：繪製轉移

使用箭頭連接各狀態。將每個箭頭標示為觸發它的事件。如果轉移需要條件，請在括號中加入保護條件。

• 為起始點繪製一個實心圓圈。
• 為終止點繪製一個雙圓圈。
• 將起始點連接到初始操作狀態。

步驟 5：新增動作

說明每個狀態內部發生的動作。如果進入「Active」狀態需要初始化變數，請將其寫為進入動作。如果離開「Active」狀態需要儲存資料，請將其寫為離開動作。

🌡️ 實際範例：恆溫器邏輯

讓我們將這些概念應用於一個經典的嵌入式情境：數位恆溫器。此範例示範如何乾淨地管理溫度控制邏輯。

情境描述

恆溫器有兩種主要模式：加熱與冷卻。它從「關閉」狀態開始。當按鈕被按下時，會進入「設定」模式。如果溫度降至設定點以下，就會啟動「加熱」。如果溫度升至設定點以上，就會啟動「冷卻」。

圖示建構

以下是此系統中狀態與轉移的分解方式。

• 狀態：關閉
  • 進入動作： 關閉加熱器，關閉風扇。
  • 事件： 按鈕按下
  • 轉移： 轉移到「設定」。
• 狀態：設定
  • 進入動作： 顯示目前溫度。
  • 事件： 溫度下降
  • 轉移： 降低目標溫度。
  • 事件： 按鈕按下（長按）
  • 轉移： 轉移到「加熱」。
• 狀態：加熱
  • 進入動作： 將加熱器引腳設為高電平。
  • 執行動作： 每5秒讀取一次溫度感測器。
  • 保護條件： 如果（目前溫度 ≥ 目標溫度）
  • 轉移： 轉移到「關閉」。

此結構確保加熱器僅在系統明確處於「加熱」狀態時才會啟動。同時也能防止衝突動作，例如同時開啟加熱器與風扇，導致短路。

⚠️ 狀態設計中的常見陷阱

即使經驗豐富的工程師也可能引入使狀態機難以維護的複雜性。請注意這些常見問題。

1. 「義大利麵狀態」

避免創建每個狀態都與其他所有狀態相連的圖表。如果看到交叉箭頭形成的網狀結構，表示邏輯可能過於複雜。使用複合狀態來整合相關行為。例如，不要將「Error_1」、「Error_2」和「Error_3」設為獨立的頂層狀態，而應將它們歸入一個父級「Error」狀態下，並設立子狀態。

2. 缺少轉移

如果事件發生在未定義的狀態中會怎麼樣？在嵌入式系統中，這通常會導致系統崩潰或未定義行為。務必定義一個「萬能」轉移，或確保系統能妥善處理意外事件，例如轉移到預設的「錯誤」狀態。

3. 非原子轉移

確保轉移以單一邏輯單元進行。如果轉移涉及更改多個變數，則必須在系統進入下一狀態前全部更新。不應允許系統停留在部分更新的狀態中。

4. 過度使用「執行」動作

雖然「執行」動作對於持續監控很有用，但過度使用會使狀態機看起來像是一個持續循環，而非基於狀態的模型。應僅將「執行」動作保留給那些在系統等待事件時必須重複執行的任務，例如感測器輪詢。

🔍 深入探討：保護條件與動作中的邏輯

嵌入式設計中最常見的問題之一是：邏輯應放在保護條件中，還是動作本身中？

• 保護條件： 用於簡單的布林檢查，以決定是否 轉移是否發生。保持它們輕量級。如果邏輯過於複雜，會降低事件處理速度。
• 動作： 用於實際執行的工作 在轉移期間執行的實際工作。如果需要計算值或更新變數，請在動作中完成。

考慮一個情境，其中僅當電池電量足夠時才會發生轉移。守衛應檢查如果 (電池 > 10%)。如果為真，動作可能是啟動馬達()。這種分離使圖表更易讀：箭頭告訴你何時發生，而標籤告訴你做什麼它會執行。

🧪 測試與驗證

圖表完成後，如何知道它運作正常？模型驅動設計讓您在撰寫任何一行 C 或 C++ 程式碼之前，就能測試圖表。

1. 路徑覆蓋

追蹤圖表中每條可能的路徑。是否能到達每個狀態？是否能到達每個轉移？確保沒有系統會卡住的死路。

2. 事件序列測試

模擬一連串事件。例如，按下按鈕，等待 5 秒，再次按下按鈕。狀態是否如預期般改變？這有助於驗證時序與事件順序是否正確。

3. 边界情況

測試邊界情況。如果溫度恰好位於門檻值上會發生什麼？如果兩個事件同時發生會怎麼樣？確保狀態機在這些邊界情況下不會當機。

🔄 狀態機與流程圖

初學者經常混淆狀態機圖與流程圖。雖然兩者都使用形狀與箭頭，但用途不同。

特徵	狀態機圖	流程圖
重點	系統隨時間的行為	演算法執行流程
持續時間	狀態具有持續時間（花費的時間）	步驟是瞬間完成的
輸入	事件（外部/中斷）	輸入資料
可重用性	高（狀態可重複使用）	低（線性路徑）
最適合	嵌入式控制、UI邏輯	計算、資料處理

對於嵌入式系統，狀態機在控制邏輯方面更為優越，因為它明確處理了定義即時系統的等待期間和事件回應。

📝 嵌入式狀態機的最佳實務

為維持程式碼品質與系統可靠性，實施來自您圖表的邏輯時，請遵循這些指導原則。

• 命名慣例：明確命名您的狀態與事件。狀態使用 PascalCase（例如，StateIdle），事件使用 CamelCase（例如，OnButtonPressed).
• 狀態分離：保持狀態簡潔。若某狀態包含過多邏輯，應拆分為子狀態。
• 事件處理：使用事件佇列來管理傳入訊號。這可確保事件依序處理，並防止競爭條件。
• 狀態變數：使用專用變數追蹤目前狀態。避免使用旗標來判斷狀態；應直接使用狀態變數。
• 文件：保持圖表更新。若程式碼變更，圖表必須反映此變更。過時的圖表比沒有圖表更危險。

🚀 結論

設計嵌入式軟體需要精確與遠見。狀態機圖表提供了達成此精確性的視覺基礎。透過將複雜行為分解為明確的狀態與定義良好的轉移，您將建立更易理解、測試與維護的系統。

從小處著手。先建立簡單功能的模型。當您熟悉狀態、轉移、事件與守衛等元件後，會發現這些圖表成為您工程工具箱中不可或缺的工具。它們將抽象邏輯轉化為具體的地圖，引導您的程式碼穿越現實世界硬體互動的複雜性。

請記住，目標不僅是撰寫能運作的程式碼，更要設計出能抵禦現實世界不可預測性的穩健系統。擁有穩固的狀態機基礎，您的嵌入式專案將建立在更堅實的根基之上。