PLC実機なしで上位ソフトを開発・テストする ― ラダーシミュレータでは埋まらない「通信相手」の穴

開発機に実機の PLC がつながっていないまま、現地に据え付けられるまで動作確認ができない――製造ラインの PC 側ソフトを作る現場では珍しくない話です。「PLC シミュレータを使えばいい」と言われて調べても、出てくるのはラダー(PLC プログラム)を机上でデバッグするためのツールばかりで、PC 側ソフトの検証には直接使えないことに気づきます。実機なしで上位ソフトを開発・テストするために必要なのは、ラダーの検証ツールではなく、本物と同じ通信規約でやり取りしてくれる「通信相手」です。

「PLCシミュレータ」で調べて出てくるものと、そこにない答え

PLC メーカーのエンジニアリングソフトには、ラダーを机上で模擬実行してデバッグする機能が備わっているのが一般的です。ラインを止めずに動作確認したいという要望に対して、まず候補に挙がるのはこの手のラダー側シミュレータでしょう。これらが主に検証しているのはラダーロジックそのものの正しさで、タイマ動作や対応命令の面で実機と完全には一致しない制約があるともいわれます。ライン全体を再現する 3D 連携シミュレーションのような選択肢もありますが、高価になりやすい仕組みです。オープンソースの PLC ランタイムも存在しますが、これも基本的にはラダー(制御ロジック)を動かす側のためのものです。

こうしたツールの多くが主眼に置いているのは、「PLC の中で動くロジックをどう検証するか」という問いです。仮にネットワーク越しの通信までカバーする機能を備えたシミュレータがあったとしても、それは基本的にラダーの動作確認を目的とした機能であり、PC 側ソフトが通信ライブラリの異常系(切断・タイムアウト・スレッドの異常終了)をどう扱うかまで再現するようには作られていません。私たちが実機なしで開発したいのは PLC の中身ではなく、PLC と通信する PC 側のソフトです。同じ「実機なし」という言葉を使っていても、この2つは確かめている対象がまったく違います。

上位ソフトが本当に必要としているのは「通信相手」

PC 側ソフトのバグは、ラダーロジックの中にはありません。通信フレームの組み立て方、応答を受け取るタイミング、PLC が応答しなかったときの振る舞いといった、通信そのものの扱い方の中に潜みます。ラダーの動作確認を目的にしたシミュレータでは、この種の不具合は通常の想定範囲に入っていません。PC 側ソフトが求めているのは、ラダーの正しさを教えてくれる相手ではなく、本物の PLC と寸分違わない通信規約でやり取りしてくれる相手です。

この「通信相手」に必要なのは、賢いロジックではなく、実物と同じ言葉をしゃべることです。私たちは、三菱電機の MC プロトコル(3E フレーム・ASCII 通信)を使う PC 側ソフトの開発で、この通信相手役を内製の疑似PLCとして社内に持っています。

内製した疑似PLCの設計判断 ― 「なんでもできる」を目指さなかった

私たちの疑似PLCは、任意のデバイス(ZR/D/M/X/Y/W など)の語・ビットを記憶して応答し、複数の PLC を同時に模擬でき、GUI で値を監視・手動で注入でき、あらかじめ用意したシナリオで PLC 側の挙動を自動再生できます。ここまでは、よくある通信スタブの延長に聞こえるかもしれません。

設計でまず決めたのは、「なんでも模擬できる汎用シミュレータ」を目指さないことでした。対象となるプロダクト群の実コードを事前に調べ、実際に使っている範囲だけに絞り込みました。通信フレームは全製品が使う ASCII の 3E のみに対応し、コマンドも一括読出・一括書込の2つだけに絞っています。ランダムな読み書きやリモート RUN/STOP のような、どの製品も使っていない機能には対応していません。

過剰な汎用シミュレータを避けたのは、対応範囲を広げるほど「疑似PLC自体が実機と正しく一致しているか」を検証する負担も増えると考えているからです。実際に使う範囲だけに絞れば、この検証負担を小さく保てます。便利さよりも検証のしやすさを取る、という判断です。

そのうえで、互換性は妥協していません。私たちの疑似PLCは、各プロダクトが実際にバンドルしている通信ライブラリと同一のワイヤ形式で応答します。実際のクライアントコードを疑似PLCサーバーへ向けて、語・ビット・文字列の往復が一致することを確認済みです。だから、疑似PLCで通った通信は、実機でもプロトコル層は通ります。

実機なしで再現すべき「壊れる瞬間」

疑似PLCが本領を発揮するのは、正常系の往復確認よりも、PLC 側が期待通りに振る舞わない場面の再現です。私たちが実機なしのテストで必ず用意するのは、次の3つです。

• 接続断からの再接続: 現場の PLC 接続には、常時接続でこまめに生存確認するものと、読み書きの瞬間だけ接続するものがあります。常時接続型では、LAN の瞬断や PLC 側の多忙状態を切断と誤判定してしまうことがあり、PLC 側の再試行猶予を超えて復帰できないとエラー扱いになります。また、接続オブジェクトが「None でなければ接続済み」という単純な判定をしていると、ソケット自体が壊れていても、例外が起きるまで再接続が走りません。
• 通信タイムアウト: PLC が応答しない、あるいは応答が遅れる状況をシナリオで再現し、PC 側ソフトがタイムアウトをどう扱うかを確かめます。
• ワーカースレッドが黙って死ぬ問題: 常駐スレッドがネットワーク断で例外的に終了すると、メインプロセス側はそれに気づけず、再起動なしでは自己回復しません。

これらはどれも、ラダーの動作確認を主眼にしたシミュレータでは通常の検証対象になりません。ラダーは正しく動いているのに、PC 側がその正しさを受け取り損ねる、という種類の不具合だからです。シナリオ再生でこの壊れ方を意図的に起こせるようにしておくことが、実機なし開発の実質的な価値だと考えています。

この仕組みを使って、私たちは役割の異なる3つの製造ライン向けシステム(生産指示・画像検査連携・設定書き込み)を実機なしで開発・テストしています。3システムはそれぞれ独自に通信ライブラリを保持していて実装の細部は少しずつ異なりますが、いずれも同じ三菱電機の MC プロトコル(3E フレーム・ASCII 通信)を使っています。だから、ワイヤ形式を一致させた疑似PLCサーバー1つが、3システム共通の通信相手として機能します。ただし、これで確かめられるのはプロトコル層までです。現地での実機接続では、配線やタイミング調整など、疑似PLCでは代替できない確認が別途残ります。

まとめ

あなたがこれから作る、あるいは発注する PC 側ソフトで最初にできるのは、疑似PLCを用意する前に、使うコマンド・デバイスの範囲・止まってほしい壊れ方を紙に書き出すことです。この棚卸しは通信相手を作る前でも一人でできる作業で、ここが定まって初めて、通信相手に何を模倣させればいいかが決まります。汎用的な模擬を先に用意しようとすると、模擬自体が正しいかの検証に手間を取られ、本来の目的である PC 側ソフトの検証が後回しになります。

「PLC シミュレータ」という言葉が指すものと、上位ソフトの開発に必要な「通信相手」は別物です。ラダーの正しさをどれだけ検証しても、PC 側ソフトが本物の通信規約とどう向き合うかは分かりません。同じ通信規約で応答する相手さえ用意できれば、開発機では疑似PLCと、現地では実機と、中身を入れ替えるだけで済みます。実機なし開発を検討するときは、まずこの2つを混同していないかを確かめることから始める価値があります。

出典:

• ソフテック技術レポート: PLC開発におけるシミュレータを活用した実機レスデバッグ

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