5.3状態遷移設計とイベント駆動

組込み機器は「電源オフ」「起動中」「待機」「動作中」「異常」のように、限られた数の状態を行き来しながらふるまいます。この「今どの状態にいて、何が起きたら次にどの状態へ移るか」を明確に整理しないまま実装すると、想定外の入力の組み合わせで機器が固まったり誤動作したりします。この節では、状態を体系立てて設計する手法と、外部イベントへの反応方式の選び方を学びます。

5.3.1状態遷移図と状態遷移表

• 状態遷移図＝機器が取りうる状態を円（ノード）で、状態間の移動をイベントに応じた矢印（エッジ）で図示したもの。全体のふるまいを視覚的に俯瞰しやすいが、状態数・イベント数が増えると図が煩雑になりモレ（未定義の遷移）の見落としが起きやすい。
• 状態遷移表＝縦軸に「現在の状態」、横軸に「発生しうるイベント」を並べたマトリクスで、各セルに「次状態（と実行するアクション）」を記入する形式。全ての状態×全てのイベントの組み合わせを機械的に埋めるため、状態遷移図では見落としやすい「その状態でそのイベントが来たらどうなるか未定義」という抜けを体系的に検出できる。レベル4の組込み設計では、複雑な機器ほど遷移表での網羅的な洗い出しが重視される。

5.3.2イベント駆動とポーリングの使い分け

• イベント駆動＝外部からの入力（割込み・メッセージ受信等）が発生した時点で対応する処理を呼び出す方式。入力が発生していない間はCPUを他の処理や省電力状態に回せるため、消費電力・CPU効率が良い。一方、想定していないイベントの組み合わせや順序（例：初期化未完了の状態で通信要求イベントが来る）への対応漏れがあると誤動作しやすい。
• ポーリング＝一定周期で状態やフラグを能動的に確認する方式。実装がシンプルで、確認周期内であれば状態変化を確実に捉えられるが、周期の間は他の処理ができない（CPUを占有する）ため消費電力・応答性の面で不利になりやすく、周期より短い時間で発生し消えるイベントは見逃しうる。バッテリ駆動機器ではイベント駆動が有利な場面が多いが、確実な周期監視が必要な場面（センサの安全監視等）ではポーリングを併用することもある。

あるバッテリ駆動の産業用センサ端末で、通常は「待機」「計測中」「送信中」の3状態をイベント駆動で遷移させる設計だったとします。運用開始後、まれに端末が「送信中」のまま応答しなくなる不具合が報告されました。設計者が状態遷移図を見直しても、図では「送信中に送信完了イベントが来れば待機へ戻る」という主要な遷移しか描かれておらず、「送信中に新たな計測開始イベントが来た場合どうするか」が図に描かれていないことに気づきにくい状態でした。そこで状態遷移表を作成し、3状態×想定される全イベント（計測開始・計測完了・送信完了・通信エラー・タイムアウト等）を機械的に洗い出したところ、「送信中に計測開始イベントが来た場合の遷移が未定義」というモレが見つかりました。実機ではこの未定義の組み合わせが発生すると、内部変数が不整合な値のまま次の処理に進み、結果として応答不能に陥っていたのです。この不具合を修正するにあたり、「送信中に計測開始イベントが来たら、計測開始要求をいったんキューに保持し、送信完了後にあらためて処理する」という例外遷移を明示的に定義しました。また、送信完了イベント自体が通信障害で永遠に来ない可能性に備え、タイムアウトイベントでも送信中から待機（またはエラー状態）へ強制的に遷移できる例外ルートも追加しました。このように、正常系の主要な遷移だけでなく、あらゆる状態×あらゆるイベントの組み合わせを表で機械的に洗い出し、モレなく次状態を定義することが、堅牢な組込みソフトウェアの状態遷移設計の核になります。

5.3.3この節のまとめ

• 状態遷移表は全状態×全イベントを機械的に埋め、状態遷移図では見落としやすい未定義遷移（モレ）を体系的に検出できる
• イベント駆動は省電力/CPU効率に優れるが未定義の組み合わせに弱く、ポーリングは確実だがCPU占有で消費電力に不利
• モレを見つけたら、キュー保持やタイムアウトによる強制遷移等の例外遷移を明示的に定義し、応答不能に陥らないようにする