止まらないシステムより、正しく止まるシステム ― PLC 書込みを止める「fail loud」という設計判断

「ラインを止めるな」――PLC と通信するソフトを作っていると、この直感に強く引っ張られます。多少あやしくても、まずは動き続けさせる実装を選びたくなる場面は少なくありません。ですが、PC から PLC の ZR 領域へ値を書き込む処理に限っては、その直感が裏目に出る場面があります。書込みデータが割り当てられた領域を食い破ろうとしたとき、私たちは処理を止め、例外を送出して書込みそのものを拒否する設計を選びました。うるさく失敗する ― fail loud(失敗を隠さず、即座に大きく報せる設計)です。

なぜ「動き続ける」ほうが高くつくのか

型式名称や号機のような項目は、PLC の ZR 領域に「N ワード固定」というレイアウトで並んでいます。この桁数を 1 ワードでも間違えると、後続のワードまで巻き込んで破壊します。桁の食い違いが実際にどう起きるかは、姉妹記事「三菱 MC プロトコルの ASCII と BIN、間違えても例外は出ない」で扱った通りです。この記事で扱いたいのは、その種の事故が起きかけたときにソフト側がどう振る舞うべきか、という設計判断そのものです。

動き続けることを優先すると、割り当てられた領域からはみ出した値がそのまま PLC へ送信され、後続のワードや隣の項目まで書き換えてしまいます。通信自体は成功として処理されるため、コード上は正常終了に見えます。気づくのは、ラインの制御や品質記録に想定外の値が現れてからです。だから、私たちは ZR 領域への書込みを「とりあえず動かして様子を見る」対象から外しました。

fail loud という設計判断 ― spill guard の仕組み

割り当てられたストライド(項目ごとの語数)を書込みデータが食い破ろうとしたとき、spill guard が ValueError を送出し、書込み自体を拒否します。これが、私たちが「動き続けるより止まる」を選んだ具体的な実装です。

ここでいう「食い破る」とは、ある項目に割り当てられた語数を超えて値がはみ出し、隣の項目の領域にまで書き込もうとする状態を指します。私たちが採った設計は、この状態を検出した時点で書込み処理そのものを実行せず、例外を呼び出し元に伝えることです。値が実際に PLC へ送信される前に処理を止めるため、ラインには誤った値が一切渡りません。「動くが間違っている」状態を許さず、「止まって気づく」状態だけを許す、という線引きです。

未確定は実行しない

spill guard が扱うのは、値が実行時に領域をはみ出した場合です。これとは別に、そもそも番地が決まっていない項目もあります。この場合、私たちは「とりあえず動く」実装を用意せず、bit 項目の番地が未確定であることを示す NotImplementedError を送出し、実装そのものを止めます。

番地が未確定のまま実装を進めてしまうと、「動いてはいるが、書き込んでいる先が正しいかどうかは分からない」という状態のままラインに出てしまいます。番地・レイアウトが未確定の項目は、確定するまで実行を止める ― spill guard と同じ思想を、実装前の段階にも適用した形です。

例外を投げる設計は、テストで固めやすい

「境界を超えたら例外を投げる」という仕様には、副次的な利点があります。仕様そのものがテストのシナリオになるということです。番地の算術・ASCII/BIN・全角文字のエンコード・切捨て・spill/bit のガードは、実機や実 Excel がなくてもユニットテストで検証でき、私たちはこの設計を 31 件のテストで担保しています。仕様の矛盾(たとえば、ある項目に必要なワード数が割り当てられた領域を超えてしまうようなケース)は、このテストが検知器として働きます。

これは狙って得た効果ではなく、fail loud という設計判断の結果として得られた性質です。値を黙って通す設計では、「通った値が正しいかどうか」をテストで機械的に確かめる基準がありません。例外を投げる設計は、境界そのものがテストの合格・不合格を決める基準になります。

握りつぶして続行する現場ソフトとの対比

PLC 通信のエラーをログにしか残さず、if ret == False: return のようなコードで次のフレームへ進んでしまう実装は、現場のソフトウェアで珍しくありません。私たちが保守する製品群の中にも、そうした実装が実在します。

この種のコードは、動作が止まらない分だけ一見すると頑丈に見えます。しかし実際には、失敗を検知する手段そのものを手放しています。重要な失敗はログに沈めず、ステータス表示やリトライへ引き上げる ― これが、握りつぶしを見つけたときの改善の方向です。

どちらの設計を選ぶかは、その書込み処理を誰が、どこまで責任を持って作るかという話にもつながります。設計判断そのものをどこまで自ら握れるかは、内製と外注のどちらを選ぶかにも関わってきます。この選択については、別の記事「生産指示システムは自作か外注か ― 分かれ目は「止まり方」を設計できるか」で扱っています。

まとめ

あなたの手元の PLC 書込みコードで、まず確認できるのは、書込み処理の try/except が何を握りつぶしているかです。エラーをログに書くだけで処理を続けている箇所があれば、そこが「動き続けることを優先した」判断の跡です。

止まらないシステムが、常に正しいわけではありません。書込みデータが割り当てられた領域を食い破ろうとしたとき、番地がまだ確定していないとき、私たちは処理を止めることを選びました。例外を投げる設計は、副次的にテストのしやすさも運んできます。次に PLC への書込み処理を書くときは、「動き続けさせてよい場所」と「止めるべき場所」を、実装する前に分けておく価値があります。

出典:

• 私たちが保守する PLC 連携システムの設計判断記録(社内一次情報)

※ この記事は AI を使用しています。Leadeas が自社開発した AI エージェント基盤で下書きを作成し、人間のレビューを経て公開しています。AI ネイティブ開発会社として自社の技術をそのまま実演する目的で、この手法を用いています。(詳しくは AI 利用ポリシー)