――「kill」では学べないが「freeze」だと見えるものがある

こんな人におすすめ

SCADA / 監視制御の設計を学習中の人
「通信監視は実装したが、その先で悩んでいる人」
状態遷移モデルやアラーム設計にモヤっとしている人

はじめに

SCADA（監視制御システム）の開発や学習をしていると、
「異常系をどう再現するか？」という壁に必ずぶつかります。

プロセスが落ちたら再起動すればいい。
通信が切れたら切断イベントを拾えばいい。

…それだけで、本当に現場っぽい学びになるでしょうか？

本記事では、SCADA開発学習を目的として作っているPLCシミュレータに、
あえて「freeze（通信は生きているが制御が止まる）」という障害を入れた理由を整理します。

※ 本稿の主語は「PLCシミュレータ開発」ではなく、
　SCADA開発を学ぶ側の視点です。

よくある異常注入：「kill」では何が起きるか

多くの検証環境では、異常系として次のようなことを行います。

プロセスを kill する
コンテナを stop / delete する
ネットワークを切断する

これらは分かりやすく、再現もしやすい。
しかし SCADA 側から見ると、挙動はかなり単純です。

通信断として検知される
タイムアウトが発生する
明確なエラー状態に遷移する

つまり、
「落ちた」「切れた」という分かりやすい世界しか学べません。

現実に近いのは「止まっているのに生きている」状態

一方、実際の制御システムでは、もっと厄介な状態が存在します。

通信は確立している（TCPは生きている）
レジスタの読み書きも一応できる
でも…値が変わらない
制御ロジックが進んでいない

つまり、

PLCは死んでいない。でも、仕事もしていない。

この状態、SCADA開発者にとっては非常に悩ましい。

ここで閃いたのが freezeさせてみては・・・？

freeze障害とは何か

freeze 障害とは、
PLC の通信（Modbus/TCP）は生きているにも関わらず、
PLC 内部の制御処理（スキャン）が停止している状態を
意図的に作り出す障害です。

具体的には、

Modbus/TCP の接続は維持される
Read 要求に対しては応答が返る
しかし PLC のスキャン処理は停止しているため
- 内部メモリ（D / M / Y など）は更新されない
- Heartbeat や ScanCount が進まない

という、「一見すると通信は正常そうに見えるが、制御としては完全に止まっている」
中途半端で厄介な状態を再現します。

この状態は、単純なプロセス停止（kill）では再現できません。
kill では TCP 接続自体が切断されてしまい、
SCADA 側は即座に「通信断」として検知してしまうからです。

freeze 障害を使うことで、次のような学習・検証が可能になります。

通信は成立しているのに値が変化しない場合、SCADA はどう振る舞うか
Heartbeat 停止と通信断を正しく区別できているか
タイムアウト・警告・アラームの設計は妥当か
「Not Ready」状態をどう定義・表現すべきか

これは PLC の挙動を学ぶためというよりも、
SCADA 側の状態監視・異常判定ロジックを学習するための障害モデルとして設計したものです。

この挙動を確認するために、学習用途のPLCシミュレータ
simpleplcsim に freeze / unfreeze 機能を実装しました。

「freeze障害」でしか見えないSCADA側の論点

PLCシミュレータに freeze 障害を入れることで、
SCADA 側には次のような問いが突きつけられます。

1. 通信正常 ≠ システム正常

ポーリングは成功している
エラーも返ってこない
でも値が更新されない

SCADAは何をもって「異常」と判断するのか？

2. 値の変化がないことをどう扱うか

何秒間値が変わらなかったら異常？
本当に「変わらない」のか「たまたま」なのか？
状態遷移モデルはどこで検知する？

単なる通信監視では足りないことが分かります。

3. アラーム設計・運用設計の学習になる

freeze 状態は、

即エラーにすべきか？
警告レベルで留めるべきか？
オペレータにどう伝えるべきか？

といった、
運用を前提とした設計判断を要求します。

kill では、この議論は生まれません。

freeze は何を止めているのか（実装イメージ）

freeze 状態では、PLC 内部で以下の処理を意図的に停止しています。

スキャンループ（ラダーロジック実行）
ScanCount / Heartbeat の更新
PLC → Modbus 同期処理

一方で、以下は停止しません。

Modbus/TCP サーバ自体
Read リクエストへの応答
既存接続の維持

この「止めるもの / 止めないもの」を分けた設計が、freeze 障害の本質かな？と思います。

なぜ「産業制御向けChaos Engineering」と言い切らないのか

最近よく使われる言葉に Chaos Engineering があります。

確かに発想としては近いですが、
私はこの取り組みを「産業制御向け」とは言い切っていません。

理由はシンプルで、

実機PLCを扱った経験はない
現場制御の最適解を語れる立場ではない

からです。

本稿でやっているのは、

SCADA開発を学ぶために、考える材料を増やすこと

そのための 疑似的な混沌 を、
シミュレータで安全に作っているだけです。

※カオスエンジニアリングが気になる方は・・・こちらの記事をご一読ください。参考になります。

freeze障害は「学習装置」

この freeze 機能は、

正解を教えてくれる機能ではありません
便利な自動復旧もしてくれません

代わりに、

設計者に問いを投げる
実装者に迷いを与える
状態モデルを見直させる

そんな 学習装置 になっています。

おわりに

「PLCが止まったらどうなるか」は、kill でも想像できます。

でも
「通信は生きているのに、制御だけが止まっている」 状態は、
実際に“観測できる環境”がないと、なかなか理解できません。

今回の freeze 障害は、PLC を壊すためではなく、
SCADA 側の設計や監視ロジックを考えるための材料として実装しました。

実機がなくても、完全に正解でなくても、
「この状態だったら自分はどう作るか？」を考えられる環境があると、
学習は一段深くなる気がしています。

同じように

SCADA 開発を学んでいる方
監視や状態判定で悩んだことがある方
kill だけの障害注入に物足りなさを感じていた方

の参考になれば嬉しいです。

「ここ、うちだとこうするな」
「この状態、現場だともっとヤバい」
など、コメントでのツッコミも大歓迎です。

もし、

通信は生きているのに制御が進まない状況
状態遷移やアラーム設計の難しさ
を学習してみたい方がいれば、以下から試せます。
　
GitHub: https://github.com/pekokana/SimplePLCSim
Release: simpleplcsim_v0.2.0_win64

※ 本記事で紹介した PLC シミュレータは、学習・検証目的のものです。
　実運用環境での適用を意図したものではありません。