■ 1. PLCの定義と役割
- PLCとは:
- 産業機械のシーケンス制御、タイマー処理、カウンター処理などを担う制御機器
- 従来はブロック状の専用ハードウェアとして提供される形態
- 実行専用の頭脳:
- 電源が入っている限り単体で自律的に動作し続ける
- PLCが担う代表的な要素:
- シーケンス制御、すなわちリレー的なON/OFF制御、タイマー、カウンター
- モーション制御、すなわちサーボモータ、パルス発生、位置決め
- アナログ処理、すなわち温度、圧力等のセンサ値取得とPID制御
- GP-IB、RS-232C、専用インターフェース等による上位機器との通信
- 操作パネル（HMI）としての表示、入力
■ 2. PLCの実装形態による分類
- ハードPLC:
- 従来型であり、専用ハードウェアとして実体を持つ
- ソフトPLC（特定ハード固定型）:
- 制御をソフトウェア化しているが、動作するハードウェアはベンダー指定の特定機種に固定される
- ソフトPLC（標準化ハード汎用型）:
- 特定ハードではなく、一定基準で標準化されたハード群に対応する
- バーチャルPLC（vPLC）:
- ハイパーバイザ、コンテナ等の仮想環境上で動作するソフトPLCの一形態
- ハードウェアから完全に分離される
- ソフトPLCとvPLCの関係:
- ソフトPLCは広義の用語であり、必ずしも仮想化を前提としない
- バーチャルPLCは仮想化技術の利用を明確に前提とする、より進んだ形態
- 業界内でも両者がほぼ同義で使われる場面があり、用語は完全には統一されていない
- 代表的なソフトPLC製品:
- Beckhoff TwinCAT、CODESYS対応製品、シーメンスSoftware Controller
- CODESYSは多数のメーカーのハードウェアに対応し、特定ベンダーへのロックインを避けやすい
■ 3. PLCと汎用PCの役割分担
- 従来型におけるPLC本体:
- I/Oの読み書きとロジック実行を現場で自律的に継続する
- PCが外れても運転は止まらない
- 従来型における汎用PC（エンジニアリングPC）:
- プログラムの書き込みと読み出し、パラメータ設定、稼働監視に使用する
- GX Works、Sysmac Studio、TIA Portal等の専用ソフトを用いる
- PLC本体とは物理的に別の機器であり、開発、監視用途で一時的に接続する
- ソフトPLCにおける統合:
- PLCとPCが物理的に同一のハードウェアに統合される
- 汎用PCのCPU上でPLCの実行エンジン（ランタイム）そのものが走り、機械はこのPCに直接接続される
- PCがPLCを制御するのではなく、PC自体がPLCとして機械を直接制御するという理解が正確
- リアルタイム性の確保:
- 単純なUSBや一般的なEthernetは通常のOS通信スタックを経由するためリアルタイム性が保証されない
- EtherCATマスター機能を持つ専用NIC、ドライバなど専用のリアルタイムEthernetインターフェースを使用する
- Windowsへのリアルタイムカーネル拡張、リアルタイムLinux、専用リアルタイムOSの併用等でOS自体をリアルタイム化する
- 指揮者と演奏者の喩え:
- PLCまたはソフトPLCの上位ロジック層は全体のタイミングを統括する指揮者であり、自らは音を出さない
- 電流制御、PWM生成といったμs〜数十kHzオーダーの超高速処理は演奏者が担う
- 演奏者はサーボアンプ等に内蔵された専用マイコン（DSP/FPGA等）であり、自律的に動作する
- この多段構成は従来型、ソフトPLCのいずれでも変わらない
- エッジ側での分散処理:
- センサーの一次処理やリモートI/Oターミナルなど、機械側に分散配置された小さなマイコン群も同様の役割を担う
- 局所的な高速処理をエッジ側で完結させ、上位のPLCやPCは全体統括に専念するという設計思想の表れ
■ 4. 加工機械の制御アーキテクチャ
- バネ、ワイヤー曲げ加工の制御対象:
- 送り軸、曲げ軸、回転軸、カット軸などが相対位置、相対タイミングで同期する
- 送り量に対して何mm進んだら何度曲げるという形で同期する、モーション制御が主役の対象
- 同期精度が品質を左右する理由:
- 曲げタイミングのズレが直接、角度誤差やバネ形状不良につながる
- 現実的な構成の選択肢:
- 単純なシーケンス制御中心のPLCだけでは同期精度が不足しやすい
- 電子カム機能を持つモーション統合型PLC（三菱モーションCPU、オムロンNJ/NX＋EtherCAT等）
- 専用モーションコントローラと上位PLCの組み合わせで、シーケンス部分のみPLCが担当する構成
- 移行の中核作業となる電子カム化:
- 機械式カムで作っていた曲げタイミングをデータ化する作業
- 送り軸の位置に対する曲げ軸の目標値という関数（カム線図）として表現する
- プロトタイプ設計の考え方:
- 目的がロジック検証、機構検証、量産機の制御方式実証のいずれかによって構成を変えるのが定石
- ロジック、機構検証が主目的ならArduino/STM32とステッピングモータでも電子カムの考え方を十分検証できる
- 送り軸位置を基準に曲げ軸目標値をテーブル化する構造を検証でき、コストと開発速度を優先できる
- 量産機の制御方式そのものを早期実証したい場合は、小型のモーション統合PLCで最初から組む方が手戻りが少ない
■ 5. 古いPC制御機械のPLCリプレース
- 既存機械の役割分解:
- PC-98等で制御されている機械の役割は、シーケンス制御、モーション制御、アナログ処理、上位通信、HMI表示に分解できる
- 置き換えの難易度:
- シーケンス制御、アナログ処理、HMI表示はPLCとタッチパネルHMIへの置き換えが比較的容易
- 高速、高精度なモーション制御が絡む場合はPLC単体では不足する
- その場合はモーションコントローラや産業用PC（IPC）とのハイブリッド構成が必要になることがある
- リプレース時の注意点:
- I/O、信号の完全な洗い出しが必要であり、配線図が散逸していることが多く現地調査が必要になりやすい
- Cバス等の専用インターフェースボードの代替設計が必要
- PLCのスキャンタイムで足りるかというタイミング、応答速度の検証が必要
- 制御ロジックの仕様化が必要であり、ソースコードが残っておらず実機トレースによるリバースエンジニアリングが発生しやすい
- 非常停止回路の二重化等、安全規格への適合が必要
- 現実的な進め方の手順:
- 信号リストとタイミングチャートを作成する制御仕様書化
- PLCとHMIでの置き換え設計
- 並行稼働またはオフラインでの検証
- 段階的な切り替え
■ 6. ハードウェア陳腐化を避けるための技術選定
- PC-98問題の本質:
- ハードウェアが壊れたら詰むことよりも、制御ロジックが特定ハードウェア、特定技術者に依存し移植できないことにある
- 発想の転換:
- 陳腐化しない機器を探すのではなく、陳腐化しても被害を最小化できる体制を作ることが重要
- 優先度が高い対策:
- IEC 61131-3準拠かつEtherCAT/PROFINET/EtherNet-IP等の標準通信規格に対応した機器を選ぶ
- ロジック、図面、パラメータを標準形式でドキュメント化し外部保管する
- 優先度が中程度の対策:
- CODESYS等のソフトPLCでハードウェア非依存化を検討する
- 長期供給方針が明確な大手メーカーの製品を選ぶ
- 標準I/O、標準コネクタでモジュール構成にする
- 優先度が中〜低の対策:
- プログラム読み書きのライセンス形態を事前確認する
- 結論:
- 壊れない機器を探すのではなく、ロジックと知識がハードウェアに縛られない体制を作ることが本質的な対策
- 標準規格に基づいたロジックとドキュメントが残っていれば、置き換え作業は大変だが可能なレベルに収まる
■ 7. 遠隔操作時の遅延対策
- 階層分離の基本方針:
- 軸間同期などμs〜ms単位のタイミングを要するリアルタイム制御は現場内で完結させる
- 遠隔地からは監視と非同期の設定変更のみを行う
- 通信経路の使い分け:
- 機械内部はEtherCAT等の産業用リアルタイムイーサネットで閉じる
- 遠隔PC、クラウドとは標準EthernetまたはVPN経由で、秒単位の遅延まで許容される情報のみをやり取りする
- 近年の主流構成:
- エッジコンピューティングの考え方に基づく構成が主流
- 現場側の小型PC、ゲートウェイでリアルタイム制御を完結させ、クラウドとは集約データのみを同期する
■ 8. バーチャルPLC化に伴う新たな依存リスク
- 依存対象の移動:
- バーチャルPLC、ソフトPLCへの移行はPC-98問題の対策として有効
- 一方で依存の対象を専用ハードウェアから仮想化基盤、ドライバ層へ移動させているだけという側面がある
- この点は楽観できず、新たなロックインポイントとして認識しておく必要がある
- 依存構造の4層:
- 最上位はIEC 61131-3準拠プログラムであるPLCアプリケーション（ロジック）
- 次にTwinCAT、CODESYS等のPLCランタイム
- 次にハイパーバイザー、リアルタイムカーネル拡張、専用ドライバといったリアルタイム化の仕組み
- 最下位はPC、NIC等の汎用ハードウェア
- 層ごとの標準化の度合い:
- 上2層のアプリケーションとランタイムは比較的標準化が進んでいる
- 下2層のリアルタイム化の仕組みとハードウェアの橋渡しはベンダー独自技術であることが多い
- 下2層が実質的な依存ポイントになりやすい
- EtherCATマスター機能の依存:
- Intel i210/i225等の特定チップセットのNICを前提とした専用ドライバでのみ確定的な低遅延通信が保証されることが多い
- 汎用NICでは性能やリアルタイム性が保証されないことがある
- リアルタイムカーネル拡張の依存:
- WindowsやLinuxの内部に割り込むタイプの製品が該当する
- OSのバージョンアップに対してベンダー側が動作保証を追従してくれるかに依存する
- ハイパーバイザーの依存:
- Intel VT-x/VT-d等、特定CPU世代、チップセットの仮想化支援機能に依存することがある
- 将来のハードウェア世代でも同じ挙動が保証されるかはベンダーのロードマップ次第
- PC-98時代との依存構造の比較:
- PC-98時代は依存の中心が専用ハードウェア1点であり、障害時は部品調達不能で完全に詰む
- バーチャルPLC時代は汎用ハードウェアとベンダー独自ドライバ、リアルタイム化技術の組み合わせが依存の中心
- ハードウェア自体は代替可能だが、保証範囲外の組み合わせでは性能、安定性が保証されない
- 互換性マトリクスの管理コストが新たに発生する
- 対策としての互換性マトリクス確認:
- どのCPU、NICチップセット、OSバージョンで動作保証するかを事前に確認する
- 保証範囲が広く、かつ継続的に更新され続けている製品を選ぶ
- 対策としてのオープン性の重視:
- ドライバ、リアルタイム化技術のオープン性を見る
- 完全にクローズドな独自実装よりも、Linuxカーネル本体にマージされたPREEMPT_RT等の標準機能が望ましい
- コミュニティベースで存続しやすい技術は特定ベンダーの方針転換の影響を受けにくい
- 対策としてのベンダー分散:
- ハードウェアとソフトウェアを同一ベンダーで固めすぎない
- ランタイム、ハイパーバイザー、ハードウェアを別ベンダーの組み合わせで運用できる構成が将来の代替手段確保に有利
- 対策としての枯れた技術の選択:
- 仮想化、リアルタイム化技術はまだ新しい分野も多い
- 複数世代のハードウェア交換を乗り越えてきた実績のある製品の方が将来リスクを低く見積もれる