はじめに
前回の記事では、PythonでPLCのコアロジックを実装しました。
次にやりたかったのは「複数のPLCやデバイスを組み合わせた複雑なシステムの構築」ですが、ここでWebエンジニアなら誰もが直面する問題にぶつかりました。
「ターミナルがプロセスとログで埋め尽くされて管理不能になる」
そこで、複数のPLCやデバイスをコンテナのように一括管理し、CLIから操作できる 「オーケストレーター」 を自作してみました。
1. 目指したのは「PLCのDocker Compose」
実機のPLC開発ではなかなか難しい「プロセスのライフサイクル管理」を、モダンな開発ツール風に実装してみました。
- YAMLによる宣言的定義: どのPLCがどのポートを使い、何に依存しているかをYAMLに記述。
-
依存関係の解決:
depends_onを見て、PLCが起動してModbusがReadyになってからデバイスを起動。 - セルフヒーリング（自己修復）: プロセスが予期せず落ちたら、オーケストレーターが検知して自動再起動。
2. ログの「迷子」をなくすCLIの実装
複数のプロセスが同時に動くと、標準出力はカオスになります。
そこで、各プロセスの出力はファイルに逃がしつつ、 必要な時に必要なログだけを覗き見（Peeking） できるCLIを実装しました。
-
インタラクティブ・ビューワー:
logコマンドを打つと最新のログファイル一覧をインデックス付きで表示。 - 番号指定で閲覧: 長いタイムスタンプ付きのファイル名を打たずとも、番号を選ぶだけで末尾20行を表示。
これが意外と快適で、デバッグ効率が爆上がりしました。
3. カオスエンジニアリングの導入：あえて「揺らす」
まだSCADA（監視システム）はありませんが、 「将来作るSCADAをいじめるための準備」 として、カオスエンジニアリングの機能を盛り込みました。
-
プロセスの強制終了 (
chaos kill): 稼働中のPLCを突然殺したときに、システム全体がどう振る舞うか。 -
通信遅延の注入 (
chaos delay):
ここままだ実装途中なのですが、、、一番こだわっているポイントです。
Modbusサーバーをラップし、 「ロジックは動いているが、通信の応答だけが5秒遅れる」 という絶妙な不具合を再現できるように試行錯誤しています。
4. なぜSCADAを作る前にこれをやったのか？
「動くもの」を作るのは楽しいですが、産業用システムにおいて最も重要なのは堅牢性なのだろうと捉えています。
- 通信が遅れたら？
- プロセスが死んだら？
- 依存関係が崩れたら？
これらを再現できる「プラットフォーム」が先にあることで、今後実装するSCADAを最初から「異常系に強い」状態で開発できる準備が整えて置きたかったんですね～。
技術スタックの裏側
- Subprocess & Threading: CLIとプロセス監視の両立。
- Pymodbusのラップ: 既存ライブラリを拡張して遅延を注入するテクニック。
- Glob & Stat: ファイルシステムをスキャンして最新ログを特定するロジック。
おわりに
Web開発の当たり前（Docker、オーケストレーション、CLIツール、カオスエンジニアリング）をPLCの世界に持ち込むと、レガシーな技術領域が急にモダンでエキサイティングな遊び場に変わります。
次は、この「揺らせる」基盤の上で、実際に監視システムを構築していく予定です。