なぜ制御ループはクラウドに置けないのか

システム

Coral Vita で私は、サンゴ礁再生施設を動かし続ける制御システムを作っている。Raspberry Pi 上のファームウェアが、水処理とゾーンごとの生命維持 — ポンプ、バルブ、薬液注入、センサー — を物理的に駆動し、壁の Avalonia タッチスクリーンと、その上位の施設サーバがそれを補う。ファームウェアはおよそ 1 秒に一度、入力を読み、状態を更新し、出力を書くリアルタイムループを回す。そのループが止まれば、バグの下流には生きた生物がいる。

すべてを決めた制約

施設のインターネットは Starlink だ。衛星回線はビデオ通話の相手には十分でも、生命維持の制御ループの中に置くには完全に不向きだ。天候や遮蔽で切れ、衛星間で切り替わり、上限を定められないレイテンシを足す。ポンプを動かし続けることがクラウドリージョンへの往復に依存していたら、クラウドリージョン — あるいは曇り空 — がサンゴの水槽を殺しうる。

だから設計上の問いは「どのクラウドか」では決してなかった。問いはこうだ。何がインターネットに依存してよく、何がインターネットが働かないときにも動き続けねばならないのか。

決断: エッジで制御する

制御ループは現地に、装置の上に、各施設ごとに置く。Neuron — ファームウェア — が GPIO、I2C、Modbus でローカルにハードウェアを駆動し、ローカルの MQTT ブローカー経由でサイトの他の部分と話す。クラウド／サーバ層は監督、履歴、オペレーター操作のためのもので、水を動かし続けるミリ秒〜秒単位の判断のためではない。各施設はサイトごとに独立して Docker でデプロイされる。

具体的には、これで四つのものが手に入る。

障害の隔離 — あるサイトの接続性や中央サーバの障害が、別のサイトの生命維持を止めることはできない。各施設はデフォルトで自律的だ。

上限のある決定的なレイテンシ — ポンプやバルブへの命令は装置上のローカルな判断であり、クラウドへの往復ではない。だから 1 Hz のループは回線に関係なくタイミングを保つ。

フェイルセーフな劣化 — 主コントローラやネットワークが不調になると、専用のフォールバックコントローラが引き継ぎ、MQTT はリトライ付きで自動再接続する。だから装置は固まる代わりに、自力で安全に劣化する。

固定された契約 — MQTT のワイヤプロトコルは、ファームウェア・キオスク・サーバ間で共有されバージョン固定された部品だ。だからオフラインの装置も、実行時の交渉で誤る余地なく、まさに正しいプロトコルを話し続ける。

受け入れたトレードオフ

施設ごとのエッジはタダではない。すべてが簡単に見渡せる単一のクラウド画面はなく、デプロイと更新は多数の自律した装置に届かねばならず、それ自体が不安定な回線越しにサイトをデバッグするのは本当に難しい。その運用コストは承知で引き受けた — 生命維持にとって、ローカルで安全に停止するアーキテクチャは、観測は楽でも衛星が生きていることに依存するアーキテクチャに勝る。