事例１）旧シーケンサ（PLC）・FA-LANリプレース
工事概要
- MELSEC-NET/2、ACPU → ETHERNET、QCPUリプレース (2006年実施)
工事詳細
- MELSEC-A：12台、MELSEC-A0J2：2台とMELSECNET/2(同軸ケーブル) FA-LANをQシリーズでリプレースする。
- 工事で該当プラントが停止できるのは月に2回(1日又は2日)のみで、それ以外は24時間連続稼働。リプレースでトラブルが発生したら工事当日内に解決か、元に戻さなければいけない。よって、全体を一括リプレースすることは難しい。
弊社の提案
「自分ならこうする」型置換え提案
- 1回(1日)の工事で1ノードずつリプレースする、設備運転継続型工事とする。
- リプレースで不具合が出た場合に、すぐに元に戻せる一時仮設型のリプレースにする。
- LANは汎用性が高いイーサネット（ETHERNET：光ギガビットLAN）へ置き換える。
- 大型Aシリーズの32点/16点端子台ユニット（AC100V入力、リレー出力ユニットなど）は全て64点FCNコネクタタイプの入出力ユニットに統一する。 AC入力はMEE製AC入力端子台使用。
- I/Oに4～5点の端数が出た場合も32点コネクタではなく64点コネクタユニットする。
本工事の方式・特徴
１）新旧ネットワークを併用した仮設ホットスタンバイ型のリプレース
工場の基幹プラントで、サイズもネットワークも異なるCPUをいきなり全数交換するのは危険。 古いPLCやLANを全て生かしたまま、新しいLANを敷設し、PLCを1台ゲートウェイにして 2つのLANのデータリンクを同期させることで、新PLCをネットワークに1台ずつ参加させる。 この方式は万が一のトラブルの際も、10分程度で昔のシステムに戻せる。
２）ホットスタンバイを実現する仮設治具製作
ホットスタンバイの仮設を実現するには、I/Oがすぐに脱着できる構造にする必要があります。 元が64点のユニットの部分は容易に脱着できますが、元が32点16点端子台のユニットの脱着は 容易ではありませんので、32点16点端子台からA6TBへ変換する仮設治具を製作しました。
これは、新PLCのI/Oユニットを64点コネクタで標準化することが前提の仮設中継治具です。
３）仮設運転期間を置く
自社で作成していないシステムのPLCのリプレースは、全ての制御内容を理解した上でのリプレースではなく、応用命令の置換え、デバイスの移動、ユニット機能の代替処理などの理論上のリプレースである。
よって、現場で一通りの機能を検証するまでは検証完了と言えないため、旧PLCやネットワークは残しておき、全ノードのリプレース後に数日稼働してプラントの動作検証が終わってから、旧PLCや同軸ケーブルを撤去する。
４）イーサネット・データリンク標準プログラム開発
MELSEC-Qはイーサネットユニット自体にプログラムレスデータリンク機能がありません(2006年当時)。 そこで、データリンク用命令語を使用した、全ノード共通で使える巡回式のデータリンク標準プログラムモジュールを開発。
これは、イーサネットユニットの号機設定値を自動で読込んで、自ノードの書き込みエリアを決定しデータリンクします。
このプログラムモジュールは以下３点のようなリスクを回避するため、全ノード一斉同報の書込命令は使用せず『ノード番号指定のデータリンク書込命令を使用した巡回式』としました。
- 書込や読出の正常完了レスポンスが取れない。
- LAN内に他社PLCやPCが参加している場合、悪影響を及ぼす可能性がある。
- ノード12台から一斉同報書込みが重なると受信ノードでオーバーフローを起こす。
なおノード番号指定のデータリンク書込命令は通信エラーが起こると通信が3秒ほど 止まり、プラントの通信がリアルタイム性を失うため、その対策も搭載しております。通信エラーや電源ＯＦＦのノードへの巡回はメインのデータリンク巡回から外し サブのデータリンク巡回に移管してリトライを継続します。これによりメインのイーサネットデータリンク巡回の高速性を維持します。
（サブで正常通信の確認ができれたノードはメインのデータリンク巡回に戻します）
５）オープンな通信を推奨
本件のプラントのノード間の通信はms(ミリ秒)までの応答が必要ないため、MELSECNET/Hではなく汎用性が 高いイーサネット（ETHERNET）を推奨しました。
2006年時点では、イーサネットは断線時のループバックや、PLC間のプログラムレスデータリンク機能が無くMELSECNET/Hより劣る点があったのですが、イーサネットユニットもそのうち改善されると考えました。
また、メーカ独自のMELSECNET/Hはマルチデバイスに対応できず陳腐化するリスクもありました。
実施手順(実際に行ったリプレース作業実績)
- ① 調査: 既設MELSECNET/2のデータリンクデーブル割付及び実際に使用しているデバイスを確認。
- ② 設計: 将来の拡張性を考慮した２倍以上のデータリンクｃｈ割付で設計。
- ③ 設計: イーサネット・データリンク標準プログラム開発。
- ④ 設計: G/W用PLC間RS232C通信プログラム及び新旧ネットワークの同期を取るプログラム製作。
- ⑤ 現地工事(平日): 光ギガビットLANを敷設、及びインテリジェント光HUB設定。
- ⑥ 現地工事(半日): 旧ネットワークと新ネットワークにG/W用PLCを設置してデータリンクを同期。
- ⑦ 設計: 32点端子台、16点端子台の中継用仮設治具製作。
- ⑧ 設計: リプレースノードのAシリーズプログラムをQシリーズにプログラムをコンバートし、新CPUに転送。
- ⑨ 現地工事(1日): 新PLCを仮設して、旧PLCのI/Oを外して新PLCに差し替える。
・直近の旧PLCのデバイスデータを吸い上げ、保存。
・新CPUに直近のデバイスデータを書き込み。
・I/Oコネクタ、端子台のつなぎ替え。
旧PLCの32点16点I/Oユニットは仮設治具で中継して新PLCの64点I/Oへ接続。
・G/WのPLCで、工事該当ノードの旧PLCのデータリンクをラダーで無効にし、新PLCのデータリンクを有効にする。 - ⑩ 現地工事: 1日1台、順次14ノード分行う。 お客様指定によりＡＯＪ２ノード２ヶ所とＡ２Ｎ１ヶ所はＣＰＵを置かずＣＣ－ＬＩＮＫ子局に置き換え。
- ⑪ 仮運転: 全ノードが仮設PLCで運転状態になった状態で運転。<
- ⑫ 不具合対応: イーサネットのデータリンクは当初の設計では1台のQ(仮のマスタ局)で読出/書込を行っていたが、仮運転中にネットワークをスルーする信号の1ヶ所が旧システムより極端に応答が遅くなった。そのため巡回方式を変更。通信モジュールを１１台全ノードが平等に巡回書込する方式に変更して、応答時間を改善。
- ⑬ 現地工事: プラントの運転に特に問題が無いため約1ヶ月後より旧PLCを撤去して 仮設新PLCを制御盤に固定。
中継用仮設治具を外してA6TBへ直接配線。 リプレース完了。 - ⑭ 不具合対応: 1ヶ所のPLCを停止した際、停止していない1つ後の番号のノードにもPLC停止の表示が出る
ことが分かり、データリンク標準プログラムの故障診断回路を修正。 全ノード分表示不具合修正完了。
成果・反省
成果
- 工場の稼働に全く影響なくリプレース工事が完了した。 もしトラブルが出たとしても、旧システムにすぐに戻せる安心感があった。
- 現地日帰り工事当日も毎回17時以内に終了した。
- 大型Aシリーズ32点端子台サイズの呪縛から解放されQシリーズ本来のコンパクト化実現。
- 64点コネクタ化で次期リプレースの脱着作業も容易となる。
- 64点コネクタ統一で保守部品や図面の管理が楽になった。
- イーサネットにしたため、その後オムロン製PLCやSCADA-PCもLANを共用できた。
- データリンクch量が増えたため、その後プラント故障集中監視システムが構築できた。
- 現場のHUBやPLCどこからでもPLCのメンテナンスができるようになった。
- 今後事業所内LANと接続できる通信基盤ができた。
- 2006年当時はイーサネット幹線の光LANは100BASEが主流であったが、1000BASE（1ギガ）にしておいて正解であった。2023年現在でも陳腐化していない上、 光スイッチを交換するだけで10ギガビットLANにアップグレードできる。
- ネットワーク経由の押しボタンフラグ1ヶ所だけ、応答が昔より若干遅い感じ。（ラダーソフト修正でかなり改善されたものの旧システムより若干遅い様子）
- ETHERNETの巡回型データリンク通信プログラムがユーザで理解するのが難しく、実質ブラックボックス。
- ※なお、明らかに近々廃棄・償却の計画のある設備の今回限りのPLCリプレースならば、弊社でもわざわざ小型化標準化せずメーカ推奨大型PLC32点端子台アタッチメントでリプレース提案すると思います。
反省
