機械設計 #52：State machine — 機械全体のBehaviorを一つのStepNoに入れない

機械設計 #52：状態機械 — 機械のふるまい全部を StepNo 一つに押し込まない

多くのPLCプログラムでは、シーケンスを一つの変数で回している。

StepNo = 0, 10, 20, 30...

正常に動いているうちは、これで十分すっきりして見える。数年経つとこうなる。

新機種のために step 120 が足された。
step 125 はセンサが遅いときの応急処置である。
step 127 は復旧の後だけ通る。
あるコイルが step 90 と異常処理ルーチンの両方から書かれている。
停電時に StepNo は保持されたが、機構は動いてしまっている。
step 240 は「使っているかもしれない」ので誰も消せない。

問題は整数を使ったことではない。ふるまいの取り決めがコードの中に溶けて消えたことである。

よい状態機械は、モード、状態、遷移、動作、不変条件を分ける。分けてあるからこそ、設計者は答えられる。機械はいまどこにいるのか、なぜそこへ移ってよかったのか、出力は誰のものか、そして論理上の状態と物理的な状態がずれたときどう復旧するのか。

1. StepNo が悪いのではない。取り決めのない StepNo が悪い

整数でも、次を満たせば立派な実装である。

どの値にも名前と意味がある。
遷移が管理されている。
不正な値のふるまいが決まっている。
出力の持ち主がはっきりしている。
状態が観測でき、記録される。
要求と試験がそこまで追える。

逆に、立派な状態機械のフレームワークを使っても、ガードが曖昧だったり、遷移が複数のタスクに散っていたり、出力が上書きされていれば誤りである。

目的は、あらゆる CASE StepNo を複雑なライブラリに置き換えることではない。理解でき、検証でき、保全できるふるまいにすることである。

2. モード、状態、ステップを分ける

混ぜられやすい三つの概念がある。

モード

モードは、機械やユニットをどう制御するか、どのふるまいを許すかを決める。生産（自動）、手動、保全、段取り、あるいは用途ごとに定義したモードである。

モードはHMI上の表示名ではない。次に影響する。

誰がどの指令を出してよいか。
どの遷移を許すか。
速度とエネルギーのふるまい。
どのシーケンスが動くか。
診断。
復旧。
アーキテクチャが関係するなら、安全関連機能。

状態

状態とは、事象への反応を決められる程度に安定した、ふるまい上の条件である。用途のモデルがそう選ぶなら、Idle、Starting、Execute、Holding、Held、Stopping、Stopped、Aborting、Aborted、Completing、Complete などになる。

ステップ

ステップは通常、手順の中の細かい一動作である。つかむ、上げる、運ぶ、置く。多くのステップが Execute 状態の中に収まりうる。ステップは必ずしも上位の機械状態ではない。

機械の全ステップ、全モード、全異常を一つの列挙型に押し込むと、モデルはすぐ迷路になる。

ISA-TR88.00.02-2022 と OMAC PackML は、機械・ユニットの状態とモードの参照パターンを示している。用語をそろえるのに役立つが、どの機械もモデル全体や同じ状態一覧を採らなければならない、という意味ではない。

3. 状態は六つの問いに答えられること

状態ごとに定義を持たせる。

目的：この状態は何のためにあるのか。
開始条件：入ったことをどうやって知るのか。
不変条件：この状態の間、常に真であるべきことは何か。
受け付ける事象・指令：ここで意味を持つ入力はどれか。
出力・動作：この状態が持つ出力や活動は何か。
終了・遷移：どの条件で出てよいのか。

仮の例：

Held：工程は定義したチェックポイントで管理下に停止している。製品の識別と所有は保持される。生産シーケンスからの動作指令は出してはならない。再開は、保持の原因が解消し、必要条件が有効で、運転者またはシステムの承認が適切なときにのみ受け付ける。

この定義は State = 40 // held よりはるかに役に立つ。

4. 状態名より不変条件が重要である

Idle と名付けても、機械が本当に待機中である証拠にはならない。

不変条件にはこうしたものが入る。

自動の動作指令が一つも有効でない。
所有者のいない処理が残っていない。
グリッパと製品の状態が確定している。
レシピは読み込まれているが実行されていない。
共有ゾーンを二つのユニットが同時に確保していない。
アクチュエータの指令とフィードバックが、許容時間を超えて食い違っていない。

不変条件があると次ができる。

状態の破綻を検出する。
意味のあるアラームと診断を書く。
復旧を定義する。
異常系の試験を作る。
並行処理をレビューする。
その状態を保持してよいか判断する。

不変条件と並んで、あってはならない状態も定義する。

保持が必要なゾーンを軸が通っている最中にクランプが開いている。
製品はあるのに所有者が「なし」である。
自動モードと保全指令が同時に有効である。
Complete なのに品質結果がまだない。
インターフェースの版が非互換なのに Execute である。

正常系は「動かせる」ことしか証明しない。あってはならない状態のレビューが、「意図しない組合せに落ちない」ことを示してくれる。

5. 遷移は取り決めである

遷移とは、こう書くだけのものではない。

IF SensorA THEN StepNo := 20;

必要なのは次である。

起点と終点

どの状態からどの状態へか。全体に効く遷移はあるか。

引き金

どの事象、指令、時間条件が始めるのか。

ガード

遷移の瞬間に真でなければならない条件は何か。

動作

通過する際に何を行うのか。所有権の更新、データの取得、タイマの解除、指令の発行など。

優先順位

複数の遷移が同時に真になったとき、どれが勝ち、それはなぜか。

不正な事象への対応

その状態に属さない事象が来たとき、無視するのか、拒否するのか、記録するのか、警報を出すのか、上位へ上げるのか。

例：

Ready から Executing へ、StartRequest を引き金として。ガードは、レシピが有効、インターフェースが受理済み、遮断中の異常なし、資源が確保済みであること。動作として処理の文脈を作り、ベースラインを記録する。同じIDの要求が重ねて来たら、二つ目の実行を作らず現在の状態を返す。

この遷移の取り決めは、#51 で扱ったインターフェース制御に直接つながる。

6. 隠れた優先順位は見つけにくい不具合である

PLCのスキャンでは、コードの順序が「公表されていない優先順位」になりうる。

IF Start THEN State := Execute;
IF Stop THEN State := Stopping;
IF Fault THEN State := Aborting;

Start、Stop、Fault が同時に真なら、最終値は順序で決まる。読む人は Fault が最優先だと考えるかもしれないが、別のルーチンが後から状態を書き直しているかもしれない。

だから次を守る。

優先順位はモデルの側で定義する。
遷移を確定する場所を一か所だけにする。
押しのけられた事象を記録する。
同時発生を試験する。
複数のタスクやルーチンから状態を書かない。

優先順位は機械の文脈で決まるもので、万能の表はない。安全関連の制御経路に属する反応を、運転状態の優先順位に頼らせてはならない。

7. 開始時・実行中・終了時の動作を分ける

動作には次の種類がある。

入ったときに一度だけ実行する。
状態の間、周期的に実行する。
出るときに一度だけ実行する。
特定の遷移に属する。

分けていないと、「初期化」の指令が毎スキャン送られたり、出力が早く消えたりする。

開始時の動作

タイマを初期化する。
処理の文脈を記録する。
ローカル変数を初期化する。
取り決めが求めるなら、指令のエッジを出す。

実行中の活動

出力を保持する。
ガードと不変条件を監視する。
進捗を更新する。
タイムアウトを確認する。

終了時の動作

資源を解放する。
結果を保存する。
その状態が持っていた指令を解除する。

出力の持ち主は明示する。

出力	持ち主の状態・部品	既定値	上書き経路
搬送指令	搬送シーケンス	OFF	中断処理
クランプ指令	治具コントローラ	ローカル状態が定める	安全反応の経路
HMI表示状態	状態管理	現在の状態	なし

同じコイルを複数のルーチンが書いているなら、それは所有権が壊れている一番分かりやすい兆候である。

8. 階層化は状態数の爆発を抑える

組合せをすべて平らな状態にすると、AutoExecuting、AutoHolding、ManualIdle、ManualFaulted、MaintenanceFaulted、SetupWaiting… と数が急に増える。

階層型の状態機械なら、子の状態が親のふるまいを受け継げる。

Operational
Idle
Starting
Execute
Holding
Stopped
StoppedNormal
Aborted
Faulted
Recoverable
RequiresIntervention

ただし階層にも意味付けが要る。

事象は子で処理するのか、親で処理するのか。
開始と終了の順序は。
親の不変条件は常に適用されるのか。
履歴状態を使うのか。
再開はどの子の状態へ戻るのか。

図を美しくするためだけに階層を使わない。所有権と遷移がより明確になることが条件である。

9. 並行処理：二つのシーケンスが同時に走るなら調整が要る

機械は同時に次を行いうる。

製品を処理する。
次の材料を準備する。
前工程と通信する。
データを記録する。
ユーティリティを監視する。

直交した領域は便利だが、競合を生む。

二つの領域が同じアクチュエータを要求する。
領域Aが先に完了し、領域Bが異常になる。
ある領域が遷移中に停止指令が届く。
一方が再起動し、他方は状態を保持している。
結果のまとめ方が決まっていない。

設計で決めるべきこと。

資源の所有権。
同期の地点。
合流の意味付け。
異常の伝わり方。
全体状態の求め方。
取消しの手立てと処理の文脈。
領域ごとと全体のタイムアウト。

並行にする必要がないなら、逐次のほうが検証しやすい。PLCが並行に走れるというだけで分岐を作らない。

10. モード変更は条件付きの遷移である

こう書いてはいけない。

Mode := HMI_ModeSelection;

モードの要求と、有効なモードは別のものである。

モード変更の流れ：

要求。
承認。
現在の状態との整合。
必要なら管理された停止・遷移。
資源と指令の後始末。
新しいモードの開始条件。
有効になったことの応答。

問うべきこと。

軸が動いている最中に自動から手動へ切り替えたらどうなるか。
保全モードに鍵、役割、手順を要求するか。
遠隔と現地の要求が同時に来たらどうするか。
モードは電源を切っても保持するのか、既定値に戻るのか。
相手側のインターフェースへ通知するのか。
処理途中の製品はどうするのか。

モード管理は安全機能に関わりうる。その場合に決めるのは、標準PLC内の列挙型ではなく、適用する安全アーキテクチャと妥当性確認である。

11. 異常、停止、保持、中断、完了は別物である

停止（Stop）

通常の工程を通して、活動を停止状態へ持っていく。

保持（Hold）

設計されたチェックポイントから再開できる形で一時停止する。

中断（Abort）

異常な離脱。再開できなくなることがあり、復旧が必要になる。

異常（Fault）

機能を妨げる、または期待に反する状態。診断と反応を伴う。

完了（Complete）

手順が意図した結果に達し、結果と文脈を閉じられる状態。

これらがすべて StepNo = 0 へ戻ってしまうと、機械は次を失う。

製品の所有。
チェックポイント。
原因。
すでに行った動作。
再開の可能性。
証拠。

リセットは「すべての状態を消すこと」であってはならない。リセットが何を確認・解除するのか、前提条件は何か、どの状態へ向かうのかを定義する。

12. 起動・再起動：論理の状態を物理の状態と突き合わせる

停電の後はこうなりうる。

状態変数は保持されている。
空圧アクチュエータは位置が変わっている。
サーボは絶対位置の文脈を失っている。
ワークはまだグリッパの中にある。
相手のPLCは別の時刻に再起動している。
処理が途中で終わっている。

危険な三つのやり方。

必ず Idle へ戻す。
必ず保持したステップから再開する。
すべての機構を自動で原点復帰させる。

どれも万能ではない。

起動時にはこう進める。

起動の理由を判定する。
構成と版数を確認する。
物理的なフィードバックを集める。
製品、資源、インターフェースの状態を判定する。
保持していた論理上の文脈と突き合わせる。
整合、復旧可能な曖昧さ、不明のいずれかに分類する。
設計された初期化・復旧の経路を選ぶ。
動作や再開の前に、適切な承認を求める。

予期しない起動のリスクは、リスクアセスメントと適用される機械安全の要求に従う。本稿は汎用の自動再開ロジックを示さない。

13. 状態が見えることは要求事項である

状態が記録もされない内部変数の中にしかなければ、故障探究は当て推量になる。

適切な粒度で外に出す。

有効なモード、状態、下位状態。
直前の遷移。
その時刻またはサイクル。
引き金と、満たされなかったガード。
有効な処理または製品。
経過時間とタイムアウトまでの余裕。
異常または保持の理由。
復旧の前提条件。
状態モデルとインターフェースの版数。

運転者に生のビットを何百も見せない。HMIには、いまの作業に対する答えが要る。

機械は何をしているのか。
どの条件を待っているのか。
次の動作は誰の担当か。
遷移を妨げているのは何か。
どの復旧が許されているのか。

事象の記録では、指令、遷移の要求、遷移の受理・拒否、状態への進入を区別する。

14. IEC 61131-3:2025 は実装を助けるが、アーキテクチャの代わりにはならない

IEC 61131-3:2025 第4版は、ST、LD、FBD、およびSFCの要素の構文と意味を定めている。

SFCは、整数のコードよりステップ、遷移、動作を明確に表せる。STやファンクションブロックは階層型の状態管理をうまく実装できる。しかし言語の選択だけでは次は解決しない。

要求の抜け。
遷移の曖昧さ。
出力の所有権。
競合と並行処理。
安全でない復旧。
不十分な試験。

「IEC 61131-3 準拠」は言語についての記述であって、機械のふるまいが正しいことも、安全度に達していることも証明しない。

15. IEC 61512 / ISA-88 と PackML の使い方

IEC 61512-1:2026 はバッチおよび手順指向の製造を扱い、レシピ手順要素と設備手順要素を分ける考え方を持つ。この分離の原則と状態の参照は役に立つが、適用範囲を守って使う。

ISA-TR88.00.02-2022 は自動機の状態とモードの実装例を示す。OMAC PackML は、ふるまいとデータの一貫性を促す。

これらは次に役立つ。

共通の用語。
独自の状態モデルを減らす。
HMIとデータの統一。
統合のしやすさ。

ただし標準のモデルも、機械の機能、寿命とモード、安全・制御アーキテクチャ、製品の流れ、インターフェース、復旧に合わせて仕立て直す必要がある。

意味も試験もない状態を、「標準に合わせるため」だけに増やさない。

16. 仮の例：つかむ・運ぶ・置く

ふるまいの階層

Stopped
Idle
Executing
Acquire
Transfer
Place
Verify
Holding
Held
Completing
Complete
Aborting
Aborted

不変条件

製品の所有者はつねに一つだけである。
搬送ゾーンを通る動作は、ゾーンの確保が有効なときだけ行う。
グリッパの解放は Place の中で、位置と受け側の条件が満たされたときだけ行う。
Complete は、在荷と品質の結果が確認された後にのみ到達する。

遷移の例

Transfer → Place

引き金：目標位置に到達。
ガード：受け側が処理を受理済み、識別が一致、置くゾーンが確保済み。
動作：所有のチェックポイントを移す。置く動作のタイムアウトを初期化する。
不正な場合：チェックポイントの前に受け側が受理を取り消したら、定めた方針に従って Holding または Aborting へ遷移する。

異常の例

Transfer の途中で製品のフィードバックを失った場合。

Idle へ飛ばさない。状態管理は次を行う。

処理の文脈を保つ。
設計どおりに停止・反応する。
最後に確認できたチェックポイントを記録する。
物理的な曖昧さを判定する。
Aborting または復旧要の状態へ移る。
適切な復旧手順だけを許す。

再起動の例

保持した状態は Transfer なのに、軸のフィードバックは別の位置にあり、製品の有無が不明である。突き合わせの結果は曖昧と判定され、機械は自動で再開せず、管理された復旧へ進む。

17. 検証のマトリクス

要求	モデル要素	実装	試験
置く条件の前に解放しない	不変条件とガード	Place の遷移	異常系の境界試験
Execute から停止要求を処理できる	全体に効く遷移	状態管理	すべての下位状態での停止
重複した起動で二重にサイクルを作らない	不正事象の規則	指令処理	指令の繰返し
曖昧な再起動では自動再開しない	突き合わせ	起動管理	電源再投入の状態マトリクス

試験には次を含める。

すべての状態と遷移。
ガードの真偽それぞれの境界。
同時に発生する事象と優先順位。
不正な指令。
タイムアウト。
センサ間の食い違い。
モード変更。
保持、停止、中断。
重要な各段階での再起動。
インターフェースの喪失と再接続。
保持データと非保持データ。
出力の所有権。
あってはならない状態の監視。

遷移の網羅率が100%でも、ガードの組合せと物理的な境界を試していなければ十分ではない。

18. レビュー用チェックリスト

モード、状態、ステップが分かれているか。
各状態に目的、開始条件、不変条件、受け付ける事象、出力、終了条件があるか。
あってはならない状態を定義したか。
各遷移に起点、終点、引き金、ガード、動作、優先順位があるか。
不正な事象のふるまいが決まっているか。
開始時・実行中・終了時の動作が分かれているか。
出力ごとに持ち主が一つだけか。
階層に、事象・開始・終了・履歴の意味付けがあるか。
並行する領域に資源の所有権と同期があるか。
モード要求が、有効モードへ直接書き込まずに手順を踏んでいるか。
停止、保持、中断、異常、完了が区別されているか。
リセットと復旧に、向かう状態と前提条件があるか。
再起動で物理的な突き合わせを行っているか。
状態、遷移、ガードが十分に見えるか。
言語やフレームワークを、アーキテクチャや安全評価の代わりに使っていないか。
要求からモデル、コード、試験まで追えるか。

まとめ

状態機械はコードの整理術ではない。機械のふるまいを記述したものである。どの状態が存在し、どの不変条件を守り、どの事象を受け付け、論理が物理と合わなくなったとき何をするのか。

モード、状態、遷移、出力の所有権それぞれに取り決めがあれば、シーケンスはレビューしやすく、試験しやすく、復旧しやすくなる。すべてが StepNo の中にしかなければ、機械は今日は動くかもしれないが、理解し変更する費用は、次の保全のたびに増えていく。

公開参考資料

IEC 61131-3:2025 — Programmable-controller languages: https://webstore.iec.ch/en/publication/68533
ISA-TR88.00.02-2022 — Machine and Unit States: https://www.isa.org/products/isa-tr88-00-02-2022-machine-and-unit-states-an-imp
OMAC PackML: https://www.omac.org/packml
IEC 61512-1:2026 — Batch-control models and terminology: https://webstore.iec.ch/en/publication/75287
ISO/IEC/IEEE 15288:2023 — System life cycle processes: https://www.iso.org/standard/81702.html

MINATAの技術記事をすべて見る