ステートマシン図の基礎：組み込みシステム初心者のためのステップバイステップガイド

組み込みシステムは厳格な制約の世界で動作します。1つのサイクルも、1バイトのメモリも重要です。このような環境では、コードの明確さは単なる望ましいものではなく、安定性と安全性のための必須条件です。この明確さを達成するための最も強力なツールの一つが、統一モデリング言語（UML）フレームワーク内のステートマシン図です。これらの図は、イベントに応じてソフトウェアが時間とともにどのように振る舞うかを視覚的に示す設計図です。

ステートマシンを用いて論理をモデル化する方法を理解することは、堅牢な組み込みアプリケーションを設計する上で基本的なことである。シンプルな温度調節器を構築している場合でも、複雑な自動車制御ユニットを構築している場合でも、ソフトウェアのライフサイクルを可視化することで、論理的な誤りがハードウェア障害になる前に防ぐことができる。このガイドでは、効果的なステートマシン図を作成するための必須の概念、構成要素、構築方法を段階的に解説する。

🧠 ステートマシン図とは何か？

ステートマシン図は、しばしばステートチャートまたは状態を焦点にしたアクティビティ図と呼ばれるもので、システムの動的挙動を表す。フローチャートが線形な手順の流れをマッピングするのに対し、ステートマシンは状態システムが任意の時点で存在する条件をマッピングする。この問いに答える：「現在、システムはどのような状態にあるのか？そして、その状態を変える要因は何なのか？」

組み込みシステムの文脈では、これはしばしば有限状態機械（FSM）と同義である。『有限』という部分が重要である。これは、システムが任意の時点で一つの特定の状態にしか存在できないことを意味する。同時に『実行中』と『停止中』の両方であることはできない。この明確な分離により、デバッグやテストが簡素化される。

🔑 ステートマシンの核心的な構成要素

図を構築するには、用語の理解が必要である。妥当な図は、特定の構成要素のセットから構成される。これらの要素がシステムの構造と論理を定義する。

1. 状態

状態は、オブジェクトまたはシステムの寿命における条件を表す。システムがイベントを待つ期間である。視覚的には、通常は丸みを帯びた長方形で描かれる。

• 単純な状態：内部構造を持たない基本的な状態（例：「アイドル」、「アクティブ」）
• 複合状態：他のサブ状態を含む状態（例：「処理中」には「センサー読み取り」や「データ書き込み」が含まれる可能性がある）
• 初期状態：マシンの出発点。通常、実線の円で表される。
• 最終状態：終了点。通常、大きな円の中に実線の円で表される。

2. 遷移

遷移とは、一つの状態から別の状態への移動を指す。システムの状態の変化を表す。遷移は、二つの状態を結ぶ矢印として描かれる。

• 遷移は瞬時に発生する。システムは「遷移中」に時間を費やすことはない。
• 特定のイベントによって引き起こされる。
• 移動が発生するためには、満たされなければならない条件（ガード）を含むことがある。

3. イベント

イベントとは、遷移を引き起こす重要な出来事を指す。組み込みシステムでは、イベントはしばしば以下のようなものである：

• ハードウェア割り込み（例：ボタンの押下）
• タイムアウト（例：タイマーの期限切れ）
• ソフトウェア信号（例：ネットワークから受信したデータ）
• 状態の入力/出力完了。

4. アクション

アクションはシステムが実行する作業です。これらは状態または遷移に関連しています。主に3つの種類のアクションがあります：

• エントリーアクション：システムが状態に入るとすぐに実行されるコード。
• エグザイトアクション：システムが状態を離れる際にすぐに実行されるコード。
• ドゥーアクション：システムが状態に留まる間、継続的に実行されるコード（例：モーター制御ループ）。

5. ガード条件

ガード条件は、遷移が発生するかどうかを決定する論理式です。ゲートキーパーの役割を果たします。イベントが発生しても、ガード条件がtrueに評価されない限り、状態は変化しません。

• 例：if (batteryLevel > 20%)
• 例：if (temperature < 100)

📊 コンポーネント比較表

これらのコンポーネントの違いを明確にするために、以下の表を参照してください。

コンポーネント	視覚的記号	機能	タイミング
状態	角丸長方形	条件を表す	継続時間（長時間または短時間のどちらでも可）
遷移	矢印	2つの状態を接続する	瞬間的
イベント	矢印上のテキスト	遷移をトリガーする	発生ポイント
ガード	括弧[]内のテキスト	遷移を検証する	遷移実行前
アクション	矢印上または状態内のテキスト	ロジックを実行する	エントリ、エグジット、またはステイ中

🛠️ 図の作成手順ガイド

スクラッチから図を作成するのは気圧を感じるかもしれません。論理的な一貫性と完全性を確保するために、この構造化されたプロセスに従ってください。

ステップ1：システムの範囲を特定する

状態機械が制御する内容を定義してください。それは全体のデバイスなのか、それとも特定のモジュールだけなのか。範囲を管理可能な状態に保つことは非常に重要です。たとえば、1つの図で車両の電子システム全体をモデル化しようとしないでください。代わりに「エンジン制御ユニット」または「電力管理モジュール」に特に注目してください。

ステップ2：状態をリストアップする

システムが取り得るすべての可能な状態を頭で整理してください。自分に尋ねてください：「運用の明確なモードは何ですか？」

• 電源オフ
• 起動中
• スタンバイ
• アクティブ運用
• エラー回復

これらの状態が互いに排他的であることを確認してください。システムは同時に2つの状態に存在してはいけません。

ステップ3：イベントを定義する

ステップ2でリストアップした状態間をシステムが移動させる原因は何ですか？入力を確認してください。

• ユーザー入力（ボタン押下）
• 外部信号（センサデータ）
• 内部タイマー
• システムエラー

ステップ4：遷移を描画する

状態を矢印で接続します。各矢印に、それをトリガーするイベントをラベル付けします。遷移に条件が必要な場合は、括弧内にガード条件を追加します。

• 開始点には実線の円を描きます。
• 終了点には二重の円を描きます。
• 開始点を初期の運用状態に接続します。

ステップ5：アクションを追加する

各状態内で何が起こるかを指定します。”Active”状態に入るために変数の初期化が必要な場合、それをエントリーアクションとして記述します。”Active”状態を離れる際にデータの保存が必要な場合、それをエグジットアクションとして記述します。

🌡️ 実用例：サーモスタットの論理

これらの概念を古典的な組み込みシナリオに適用しましょう：デジタルサーモスタットです。この例は、温度制御論理を明確に管理する方法を示しています。

シナリオの説明

サーモスタットには2つの主要モードがあります：暖房と冷房。初期状態は”Off”です。ボタンが押されると、”Setup”モードに入ります。温度が設定値を下回ると、”Heating”モードに切り替わります。温度が設定値を上回ると、”Cooling”モードに切り替わります。

図の構築

このシステムの状態と遷移の構成は以下の通りです。

• 状態：OFF
  • エントリーアクション： ヒーターをオフ、ファンをオフにする。
  • イベント： ボタン押下
  • 遷移： “SETUP”に移行する。
• 状態：SETUP
  • エントリーアクション： 現在の温度を表示する。
  • イベント： 温度低下
  • 遷移： 目標温度を下げる。
  • イベント： ボタン押下（長押し）
  • 遷移： “HEATING”に移行する。
• 状態: 加熱中
  • エントリーアクション:ヒーターのピンをHIGHに設定する。
  • Doアクション:5秒ごとに温度センサーを読み取る。
  • ガード条件:もし (現在温度 >= 目標温度)
  • 遷移:「OFF」に移行する。

この構造により、システムが明示的に「加熱中」の状態にない限り、ヒーターがオンにならないことが保証される。また、ショート回路を引き起こすような、ヒーターとファンを同時にオンにするような衝突するアクションを防ぐ。

⚠️ 状態設計における一般的な落とし穴

経験豊富なエンジニアですら、状態機械の保守を難しくする複雑さを導入してしまうことがある。これらの一般的な問題に注意を払うべきである。

1. 「スパゲッティ状態」

すべての状態が他のすべての状態と接続される図を作らないようにする。交差する矢印の網目のような図が見られたら、論理がおそらくあまりにも複雑である。関連する振る舞いをグループ化するために複合状態を使用する。たとえば、「Error_1」、「Error_2」、「Error_3」を別々のトップレベル状態として持つ代わりに、親の「Error」状態の下にサブ状態としてグループ化する。

2. 遷移の欠落

イベントが定義されていない状態で発生した場合、何が起こるだろうか？組み込みシステムでは、これによりクラッシュや未定義動作が発生することが多い。常に「すべてをカバーする」遷移を定義するか、システムが予期しないイベントを適切に処理できるようにする。たとえば、デフォルトの「エラー」状態に移行するなどする。

3. 非アトミックな遷移

遷移が単一の論理的単位として行われることを保証する。遷移が複数の変数の変更を含む場合、システムが次の状態に移行する前にすべての変数が更新されるべきである。部分的に更新された状態にシステムが長く留まるのを許してはならない。

4. 「Do」アクションの過剰使用

「Do」アクションは継続的な監視に有用であるが、それを使いすぎると、状態機械が状態ベースのモデルではなく、連続ループのように見えることがある。センサーのポーリングなど、システムがイベントを待っている間、繰り返し実行しなければならないタスクにのみ「Do」アクションを割り当てるべきである。

🔍 深掘り：ガード条件とアクション内のロジック

組み込み設計における最も頻繁な質問の一つは、ロジックをどこに配置するかである：ガード条件に置くのか、それともアクション自体に置くのか。

• ガード条件:これらは、遷移が発生するかどうかを判断する簡単なブールチェックに使用する。もし遷移が発生するかどうかを判断する。軽量に保つこと。ロジックが複雑になると、イベント処理が遅くなる。
• アクション:これらは、遷移中に実際に行われる「作業」に使用する。作業遷移中に実際に行われる作業に使用する。値を計算するか、変数を更新する必要がある場合は、アクション内で行う。

バッテリー残量が十分である場合にのみ遷移が発生する状況を考えてみましょう。ガードは次のことを確認すべきです。if (battery > 10%)。真であれば、アクションは次のようになるかもしれません。turnOnMotor()。この分離により、図の可読性が向上します：矢印は「いつ」起こるかを教えてくれ、ラベルは「何を」行うかを教えてくれます。いつ起こるかを示し、ラベルは何を行うかを教えてくれます。

🧪 テストと検証

図が完成したら、それが正しく動作しているかどうかどうやって確認するのでしょうか？モデルベース設計では、CやC++のコードを1行も書く前に図をテストできます。

1. パスカバレッジ

図を通るすべての可能なパスを追跡してください。すべての状態に到達できますか？すべての遷移に到達できますか？システムが詰まるようなデッドエンドがないか確認してください。

2. イベントシーケンステスト

イベントのシーケンスをシミュレートしてください。たとえば、ボタンを押す、5秒待つ、もう一度ボタンを押す。状態が予測どおりに変化しますか？これにより、タイミングやイベントの順序が正しいか確認できます。

3. 端境ケース

境界をテストしてください。温度がちょうどしきい値に一致した場合どうなるでしょうか？2つのイベントが同時に発生した場合どうなるでしょうか？状態機械がこれらの端環境ケースをクラッシュせずに処理できることを確認してください。

🔄 状態機械とフローチャート

初心者は、状態機械図とフローチャートを混同することがあります。どちらも形状と矢印を使用しますが、目的は異なります。

特徴	状態機械図	フローチャート
注目点	時間経過に伴うシステムの挙動	アルゴリズムの実行フロー
持続時間	状態には持続時間（費やした時間）がある	ステップは瞬間的である
入力	イベント（外部/割り込み）	入力データ
再利用性	高 (状態を再利用可能)	低 (線形パス)
最適な用途	組み込み制御、UIロジック	計算、データ処理

組み込みシステムでは、状態機械はリアルタイムシステムを特徴づける待機期間やイベント応答を明示的に処理するため、制御ロジックにおいて優れた選択です。

📝 組み込み状態機械のベストプラクティス

コードの品質とシステムの信頼性を維持するため、図から導き出されたロジックを実装する際は、これらのガイドラインに従ってください。

• 命名規則：状態とイベントの名前を明確にします。状態にはPascalCaseを使用してください（例：StateIdle）で、イベントにはCamelCaseを使用してください（例：OnButtonPressed).
• 状態の分離：状態は小さく保ちましょう。状態にロジックが多すぎると、サブ状態に分割してください。
• イベント処理：到着する信号を管理するためにイベントキューを使用してください。これにより、イベントが順序通りに処理され、競合状態を防ぐことができます。
• 状態変数：現在の状態を専用の変数で追跡してください。状態を判断するためにフラグを使用しないでください。状態変数そのものを使用してください。
• ドキュメント：図を常に最新の状態に保ちましょう。コードが変更された場合、図もその変更を反映しなければなりません。古くなった図は、何も図がないよりも危険です。

🚀 結論

組み込みソフトウェアを設計するには、正確さと先見性が求められます。状態機械図は、この正確さを達成するために必要な視覚的基盤を提供します。複雑な振る舞いを離散的な状態と明確に定義された遷移に分解することで、理解しやすく、テストしやすく、保守しやすいシステムを構築できます。

小さなステップから始めましょう。まずは簡単な機能をモデル化してください。状態、遷移、イベント、ガードといった要素に慣れると、これらの図がエンジニアリングツールキットにおいて欠かせないものになることに気づくでしょう。抽象的なロジックを具体的な地図に変換し、現実のハードウェアとの相互作用の複雑さをコードが導く手がかりになります。

思い出してください。目的は単に動くコードを書くことではなく、物理世界の予測不可能な性質に対して頑健なシステムを設計することです。しっかりとした状態機械の基盤があれば、あなたの組み込みプロジェクトはより安定した土台の上に立つことになります。