新設Windowsアプリケーションと既設FA500でデータの受け渡しを行うために、FA-M3をゲートウェイPLCとして間に入れ、情報を中継させることでリプレースを実現しました。（図2）

図 2　新システム構成

ゲートウェイPLCは図 3に示すように、シーケンスCPU（F3SP58）とMLバスCPU（F3MP30）のマルチCPU構成としました。
シーケンスCPUが、Ethernetインタフェースモジュール（F3LE12）の上位通信機能を利用してPCと情報の受け渡しを行い、MLバスCPUがFA500との情報の受け渡しを行ないます。

図 3　ゲートウェイPLCの構成

ゲートウェイPLC内のシーケンスCPUとMLバスCPUは、マルチCPU間の構成としています。
データ受け渡し方法には以下の2種類存在します。 本事例では、2)を採用していますが、その理由は、特別な処理を組まなくてもシーケンスCPUとMLバスCPU間で同期が取れる点にあります。

MLバスCPUによるデータ更新がシーケンスCPUに伝わるまでの間、MLバスCPUのプログラム内では、そのステートメントで止まっていることを意味しますので、MLバスCPUが異なるデータ更新をシーケンスCPUに通知することによるデータの取りこぼしは発生しません。

1)の場合には、MLバスCPU側の処理に関係なく、シーケンスCPUのタイミングでデバイスのリフレッシュが行なわれますので、MLバスCPUとシーケンスCPU間では非同期となります。
MLバスCPUは、データ更新がシーケンスCPUに伝わっているかどうかに関係なく自身の処理を続けますので、シーケンスCPUがデータ更新を検知する前に、異なるデータ更新をシーケンスCPUに通知する可能性があります。
結果として、ソフトウェアの設計によってはデータ更新の通知を取りこぼす可能性があります。
これを回避するためには、双方のアプリケーションで考慮した設計を行う必要があります。

いずれにしても、FA500側アプリケーションの作りも意識する必要がありますので、
FA500から通知されるシグナルの間隔や、各PLCの処理速度も考慮してどちらを採用すべきか決定する必要があります。

FA-M3とFA500との間で情報共有を行うためには、MLバス上のコモンレジスタにアクセスする必要があります。
そのために、まずは、ゲートウェイPLCのMLバスCPUを既設MLバスネットワークに参加させました。
そして、既設システムでFA500からYEWMAC500へシグナルを通知していたところを、ゲートウェイPLCへ通知するように変更することで実現しました。

PCとFA500間のデータの流れは以下の通りです。

本事例の場合、YEWMACの代わりにMLバスCPUをMLバス上のノードに参加させる必要があるため、少なくともMLバスのユニット構成定義に関する知識が必要となります。
また、導入後の現地確認の際にも、新設アプリケーションによる問題か、既設部分の問題かの切り分け作業が必要となることも少なくありません。
よって、FA500ラダー開発ツール（本事例では「PCCAD2」）や、FA500 BASICプログラム作成ツール、また、その他既設機器に関するツールなどを使いこなせる必要があります。
本事例の場合は、これらのツールの使用方法に詳しい社員がいましたので、教えてもらうことで習得することができました。

リプレースという開発は、現状動作しているプログラムと同じものを作るだけなので簡単であるといったイメージがあるかもしれません。
しかし現実は、既設アプリケーションが開発されてからの多くの時間が経過していることが多いため、その間にドキュメントがメンテナンスされていなかったり、ソースコードのコメントが無かったりということが多々あります。
そのため、実際の動作や、限られた情報の中から、既設ソースプログラム上の処理を結びつける想像力が必要となります。

本事例も、リプレース元のソフトウェアは当社で納入したものではありませんでした。そのため、ソースコードと限られたドキュメント、ヒアリングしたシステムの実際の動作から既設プログラムを解析していく必要がありました。

今回のようなYEWMAC500のリプレースの場合は、コモンレジスタのデータフローと、シグナル送受信の関係が重要となりますので、表 1、表 2に示すような表を作成しながらプログラム解析を行い、まずはシステム全体の動きを把握しました。

表 1　シグナル送受信の解析

表 2　コモンレジスタ読書きの解析

システム全体の動きを把握した上で、より詳細なプログラムの解析を行うことにより効率良く解析作業を進めることができます。

本事例では、YEWMAC500部分のみのリプレースでしたが、現地調整では、リプレース対象外の部分においても隠れた問題が発生し、対応を行うことが少なくありません。
かといって既設プログラム全てを完全に解析することは、それなりの期間がかかりコストが増大してしまうため、お客様からご依頼を頂かなければ行うことは困難です。

上記のような方法で、システム全体の動きを資料化し理解しておくことで、リプレース対象外のトラブルにも迅速に対応することが可能となります。

リプレース案件は、稼動中のシステムに対しての更新ですので、更新と動作確認に使うことができる時間は限られており、更新後も更新前と同様に生産を行わなくてはなりません。
このように、短い期間で生産できる状態まで一気に立ち上げなければならないという難しさもあります。

本事例の場合には、長期工場の生産が停止する期間を狙っての現地調整となりました。現地調整期間は一週間ほどです。
ソフトウェアの確認のみでなく、ハード側の工事や、更新後の本生産に向けての確認などもありますので、ソフトウェアの確認だけに使うことができる時間は3〜4日程度となります。

現地での立ち上げを成功させるためには、社内試験を十分に行い、品質の高いソフトウェアを持ち込んで現地調整に臨むことはもちろんですが、事前に段取りをしっかりと立てて、着実に作業を行っていくことが非常に重要となります。