有限状態マシンを作成する必要があったことはありますか？

Question

これには、大学で行った可能性のある有限状態マシンは含まれていません。

誰が作成しなければならなかったのか、その理由を知りたいのですが？

マシンを作成する上で最も難しい側面は何でしたか？

Answer 1

はい、たくさんあります。基本的に、パフォーマンス上の理由から、字句アナライザーを手動で実装する必要がありました。他の個人的な用途は、FSAがユーザーとの対話の流れを制御するGUI設計でした。

作成このようなマシンはまったく難しくありません。変更は、FSAの構造の少なくとも一部がコードに厳密に埋め込まれているためです。状態パターンは、これらの移行の一部を緩和するのに役立ちますが、すべてではありません。>

Answer 2

何度も！

通信システムで使用されるほとんどのプロトコルスタックは、ステートマシンとして実装されます。CSTA呼び出しモデルは1つの良い例です。

また、ほとんどの組み込みシステムは本質的にステートマシンです。

基本的に、現実世界のイベントに反応する必要のあるシステムは、ステートマシンとして実装するのに適した候補です。

ステートマシンで最も難しいのは、最新のドキュメントがない場合にステートマシンが何をするかを理解することです。認識できないほどバグが修正される傾向があります。

Answer 3

確かに、私は小さなタービン、ポンプ、モーターを制御するためのタービンガバナーを設計および作成しました。 DSPチップを搭載した組み込み機器です。停止、起動、実行、過速度テストなどの状態があり、実行状態には他の制御の可能性をカバーするいくつかの状態があります。

私の場合、ステートマシンの管理で最も難しい部分は、特にステートにサブステートを含めることができる場合に、クリーンな遷移を設計することでした。タービンガバナの場合、これは、速度出力（アクチュエータ）を遷移間でスムーズに調整する必要があることを意味しました。その他の課題は、ユーザーインターフェイス（プッシュボタンと7セグメントLEDディスプレイ）と、それらがステートマシンとどのように相互作用するかに関連していました。そのため、最終的には、マスター制御ステートマシン、関連するユーザーインターフェイスステートマシン、および関連する通信ステートマシンが存在しました（タービンの稼働中に特定の値を書き込むことは許可されませんでした）。

私は他のさまざまなプロジェクトでステートマシンを使用しました。一部は組み込みソフトウェア、一部は標準ソフトウェアであり、通信からユーザーインターフェイスソフトウェアまでです。

Answer 4

上記のように、FSAの目的は、ステップからステップへと、すべての処理（および状態変化）が1つのループで処理されることです。また、プロセスで何かが変更された場合、次の論理的なステップに進むのは簡単です。

はい、簡単に実行できます。25年以上にわたって頻繁に使用しています。

Answer 5

私も持っています。大きなFSMはメンテナンスの悪夢になるため、私は通常、小さなFSM（状態が少ない）を作成しますが、FSMは、特定のタスクに対して非常にシンプルでエレガントな設計である場合があります。

実際の例として、特定の種類のファイルを一度修復するための小さなユーティリティを作成しました。ユーザーとの可能なインタラクションパスは3つまたは4つだけでした：

• 小さなメッセージを表示し、ファイルを選択して（おそらくキャンセルして最初からやり直します）、
• ファイルを修復します（おそらくキャンセルしてエラーメッセージで終了します）、
• 確認メッセージを表示します。

  ステートマシンを作成すると、これらのパスが明確になり、実装が簡単になりました。