PLC は生きているのに『切断』と判定される ― 生存確認が LAN 瞬断で誤爆する仕組みと対策

常時接続で PLC と通信している PC 側ソフトが「切断しました」というログを吐きます。ところが設備側の表示灯も PLC そのものも、何ひとつ異常な動きをしていない――こうした現場では、この食い違いに出くわすことがあります。原因のひとつは、通信が本当に切れたことではなく、生存確認という仕組み自体が LAN の瞬断や PLC 側の一時的な多忙を「切断」と誤判定していることにあります。厄介なのは、この誤判定への対応、つまり切断処理から再接続へと進むシーケンスそのものが、PLC 側の許容時間に間に合わなければ実害に変わってしまう点です。

接続モデルは製品ごとに別物 ― 生存確認の設計はここに従属する

PLC と PC 側ソフトの接続方式は、ひとつの型に決まっているわけではありません。私たちが複数の製造ライン向けシステムの実装をレビューした範囲だけでも、性質の異なる接続モデルが並んでいました。ひとつは、複数のワーカーが各 PLC へ常駐セッションを張り、特定デバイスの読み出しを一定周期で行って生存を確かめる常時接続型です。もうひとつは同じ常時接続でも、短い周期でのビット書込みトグルによって生存を確かめる方式です。そして三つ目は、読み書きが必要になった瞬間だけポートを開き、都度クローズするトランジェント接続で、そもそも生存確認という概念自体を持ちません。

生存確認が要るのは、この中の常時接続型だけです。既存の接続コードを新しい製品にそのままコピーしてはいけない、という社内の申し送りには理由があります。生存確認の閾値も、再接続までの挙動も、どちらの常時接続方式を採用しているかによって前提が変わるからです。だから、次に見る誤判定の話は、常時接続型を選んだ製品だけに起きる問題として読んでください。

生きているのに「切断」と判定される ― 生存確認の誤検知と見逃し

常時接続で特定デバイスの read を周期的に行う方式では、実際に「切断」を誤爆させるケースがありました。ある製品では、この読み出しを 15 秒周期で行い、3 回連続で失敗した時点で切断と判定するロジックを採用しています。この判定は LAN の瞬断や PLC 側の一時的な多忙状態でも成立してしまいます。PLC も通信経路も生きているのに、生存確認の側が「死んでいる」と誤って結論づけてしまうということです。

問題はここで終わりません。誤判定した時点でソフトウェアは切断処理に入り、再接続のシーケンスを開始します。この再接続が PLC 側のリトライ猶予(目安として約 18 秒)以内に完了しなければ、今度は PLC 側がエラー扱いにします。実際には一度も切断していないのに、「切断したという誤判定」への対応そのものが、ラインへの影響という実害に変わっていくのです。

同じ生存確認という仕組みは、逆方向にも外れます。別の製品では、接続オブジェクトが None でなければ「接続済み」とみなす判定を採用していました。この場合、ソケット自体が壊れていても、明示的な例外が発生しない限りオブジェクトは None に戻りません。実際には死んでいる接続を「生きている」と誤認したまま使い続けてしまいます。誤検知(生きているのに切断と判定する)とは正反対の失敗ですが、根っこは同じです。どちらも接続の「今の状態」を実測せず、代理指標――read の連続失敗回数か、オブジェクトの有無か――だけで判定を済ませていることが原因です。

起動直後にも同じ根っこの罠 ― ハンドシェイクの偽エッジ

「今の状態を確かめずに仮定で済ませる」という根っこの罠は、切断判定の場面だけに現れるわけではありません。起動直後のハンドシェイクにも同じ形で現れます。

ある製品では、PLC が信号を OFF にするのを PC 側がエッジ検出し、完了フラグを書き戻すというハンドシェイク方式を使っています。この実装では、PC 側プログラムの「前回値」を起動時に OFF(False)で初期化していました。ところが起動した時点で PLC 側のビットがすでに ON になっていると、本来存在しないはずの OFF から ON への偽のエッジを検出してしまいます。

原因は、ここまで見てきた生存確認の2つの症状(誤検知・見逃し)とまったく同じ構造です。PLC の「今の状態」を確かめずに、初期値を仮定でスタートさせています。だから対策も同じ方向を向きます。監視を始める前に、まず PLC の現在値を一度読んでおくことです。

「今の状態」を仮定しない設計にする

ここまでの実例に共通する対策の方向は、突き詰めれば「今の状態を仮定で済ませない」という一点に集約されます。

生存確認の失敗判定には、ネットワークの一時的な要因を織り込みます。具体的には、判定の閾値と周期を、PLC 側のリトライ猶予から逆算して決めます。3 回連続失敗のような数字を先に決めるのではなく、PLC 側が何秒まで待ってくれるかを起点にして、その範囲に収まる形で生存確認の設計を組み立てるということです。数字を先に決めるか、外側の制約から逆算するか――どちらでも動くコードは書けます。後者のほうが、閾値の妥当性を私たちの感覚でなく PLC 側の仕様という外部の基準で説明しやすくなると考えられます。

接続状態の判定でも、オブジェクトの有無という代理指標に頼らないようにします。ソケットの実状態や直近の通信成否を見て判定します。そして起動時には、PLC の現在値を一度読んでから監視・初期化を始めます。

言葉にすればどれも当たり前の話に聞こえるかもしれません。しかし厄介なのは、これらの異常系――瞬断、無応答、起動時にすでに ON になっている状態――は、実機を使ったテストでは狙って再現しづらいということです。LAN ケーブルを都合よく一瞬だけ抜き差しするタイミングも、PLC 側の多忙状態も、起動直後にビットが ON になっている状況も、実機相手には狙って作り込みにくいものです。

私たちは、この種の異常系を疑似 PLC のシナリオ再生機能を使って意図的に再現しています。瞬断・無応答・起動時 ON といった状態をシナリオとして用意し、狙ったタイミングで発生させることで、生存確認や初期化のロジックがどう振る舞うかを実機なしで確かめられます(疑似 PLC を使った実機なし開発については別記事で詳しく書いています)。

まとめ

あなたが今日から確かめられるのは、自分のシステムの生存確認が「何を根拠に切断と判定しているか」を1つ書き出し、その基準が PLC 側の許容時間(リトライ猶予)と噛み合っているかを照らし合わせることです。

生存確認は、本来は切れたことを検知するための仕組みです。ところが閾値や判定方法、そして起動時の初期値を仮定で決めていると、切れていないものを切れたと誤判定したり、切れているものを見逃したり、起きていないはずのタイミングを偽エッジとして検出したりします。いずれも根は同じで、接続の「今の状態」を実測せずに代理指標や初期値だけで済ませていることです。常時接続で PLC と通信するソフトを扱うなら、この仮定という第三の失敗モードを、切断そのものと同じくらい重く見る価値があります。狙って再現しづらいぶん、疑似 PLC のようなシナリオ再生の手段で意図的に確かめておくと、本番で初めて踏むリスクを減らせます。

出典:

• 私たちが保守する PLC 連携システムの実装レビュー記録(社内一次情報)

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