HOME会社概況業務内容開発分野開発事例CANモジュールソフテックだよりお問い合わせ
HOME > ソフテックだより > 第49号(2007年9月5日発行) 技術レポート「サポートが終了したFAシステムのリプレース」

「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。

ソフテックだより(発行日順)のページへ
ソフテックだより(技術分野別)のページへ
ソフテックだより(シーン別)のページへ


ソフテックだより 第49号(2007年9月5日発行)

技術レポート

「サポートが終了したFAシステムのリプレース」

1.はじめに

当社の開発では、既存システムのリプレースを行う案件も存在します。

リプレース(Replace)とは、既設システムで使用している機器の生産停止や、サポート停止などの理由から、仕様はそのままに(可能な限りの改良は加えるが)新しいハードへソフトウェアを移行することをいいます。

今回の技術レポートでは、私が経験したリプレース案件の中で、サポートが終了しているFAコンピュータYEWMAC500(※1)を用いたシステムのリプレース案件について取り上げ、開発で用いた技術や、開発から学んだリプレースする際の注意点について紹介します。

2.システム構成

今回取り上げる事例では、リプレース元は図 1に示す構成でした。

リプレース元の既設システム構成です
図1. 既設システム構成

お客様からの要望により、図 1の構成からYEWMAC500のみをFAパソコン+Windowsアプリケーションに置き換え、誰もが使い慣れたWindowsユーザインタフェースの提供と、よりグラフィカルな情報表示を行うことが本リプレースの目的でした。

しかし、既設FA500(※2)はそのまま残す必要があるため、新規開発したWindowsアプリケーションから、MLバス(※3)経由でFA500のデータを直接参照することは不可能でした。
したがって、本事例では次章に示すような方法でリプレースを行いました。

3.本事例のポイント
(1) ゲートウェイPLC(FA-M3)を利用

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

リプレース後のシステム構成です
図2. 新システム構成

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

リプレース後のシステム構成内で使用している、ゲートウェイPLCのモジュール構成です
図3. ゲートウェイPLCの構成

(2) ゲートウェイPLC内の情報共有

ゲートウェイPLC内のシーケンスCPUとMLバスCPUは、マルチCPU間の構成としています。
データ受け渡し方法には以下の2種類存在します。

1)
共有デバイス(E, R)を使用する方法
2)
MLバスCPUのENTER, OUTPUT命令(YM-BASIC)を使用する方法

本事例では、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の処理速度も考慮してどちらを採用すべきか決定する必要があります。

(3) FA-M3−FA500間の情報共有

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

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

[PC→FA-M3→FA500]

  1. シーケンスCPUから、取り決めたデバイスにデータを書き込む。
  2. シーケンスCPUから、SIGNAL命令を使用してMLバスCPUへ割り込みを発生させる。
  3. MLバスCPUは、発生した割り込みルーチンの中で、ENTER命令を用いてシーケンスCPUから該当データを読み込む。
  4. MLバスCPUは、シーケンスCPUから読み取ったデータを、MLバスのコモンレジスタ上に書き込む。
  5. MLバスCPUは、該当ノードへデータ更新を表すシグナルを通知する。

[FA500→FA-M3→PC]

  1. FA500からMLバスCPUへシグナルが通知される。
  2. MLバスCPUは、コモンレジスタのデータをOUTPUT命令でシーケンスCPUのデバイスに書き込む。
  3. 情報が更新されたことを、ハンドシェイク用のデバイスにOUTPUT命令を用いて通知を表す値(例: ‘1’)に書き換える。
  4. シーケンスCPUは、ハンドシェイク用デバイスにより通知を検知し、MLバスCPUにて書き込まれたデータをPCに通知する。
  5. シーケンスCPUは、PCへの通知が完了したらハンドシェイク用のレジスタを0クリアする。
4. リプレースの難しさ
(1) 既設機器に関する知識が必要

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

(2) 既設プログラムの解析

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

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

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

シグナル送受信の解析で作成した表の概略です
表1. シグナル送受信の解析

コモンレジスタのデータ解析で用いた表の概略です
表2. コモンレジスタ読書きの解析

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

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

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

(3) 現地での垂直立ち上げ

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

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

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

5. おわりに

本技術レポートでは、私が経験したリプレース事例の1つを紹介しました。

本事例のように、既設システムの一部が残る場合には当然なのですが、どのリプレース案件においても、既設システムに関連する知識が必要不可欠となります。
既設プログラムの解析だけでなく、トラブル発生時に適切な切り分けを行えるように、新旧に問わず幅広い知識が必要となるということが難しい点の一つであると考えます。

今まで述べてきたように、リプレースは難しい要素が多い開発ですが、本事例ではスケジュールどおりに現地立ち上げも成功し、新設Windowsアプリケーションのユーザインタフェースにも満足していただいております。

リプレースは、製品サイクルが存在する限り無くなることはありませんので、今後も柔軟に対応することができるように、広く技術習得に励む必要があると考えます。

(M.S.)

[参考文献]
「横河電機株式会社ホームページ − ネットワークベース生産システム(STARDOM)」
[注釈]
(※1) YEWMAC500シリーズ
IEC 61131-3:
国際電気標準会議(IEC)が制定した、PLC用プログラミング言語を規定した標準規格。
(※2) FA500シリーズ
1989年9月に発表された、横河電機株式会社製プログラマブルコントローラ(PLC)。
(※3) MLバス
FA-M3、FA500およびYEWMAC500との間でデータ共有を行う通信ライン。

関連ページへのリンク

関連するソフテックだより