JP4488227B2

JP4488227B2 - 可変性を有する制御部品のデバッグ方法、及びデバッグ支援装置

Info

Publication number: JP4488227B2
Application number: JP2005289245A
Authority: JP
Inventors: 繁人見; 徹雄香川; 寛吉田; 幸浩川上
Original assignee: Omron Corp
Current assignee: Omron Corp
Priority date: 2005-09-30
Filing date: 2005-09-30
Publication date: 2010-06-23
Anticipated expiration: 2025-09-30
Also published as: JP2007102380A

Description

本発明は、ラダー言語によって記述された機器制御プログラムの部品化並びに再利用化に関する発明である。

ラダープログラムの部品化・再利用化については、一般的にIEC61131規格で定義された『ファンクション・ブロック』の仕組みを用いて実現されている。ファンクション・ブロックにより、ラダープログラムと変数のカプセル化が実現され、ラダープログラムを部品として再利用することが可能になっている。また、プログラム上の複数箇所に現れる複合処理をそれぞれ簡単なマクロ演算部品の図形で置き換えることにより、図形表示されたプログラムの簡素化を図ることも知られている（特許文献１参照）。

しかしながら、ラダープログラムが用いられる機器制御システムの分野では、製品ラインナップを充実させてユーザのニーズに対応できるように、大部分は同一であるが部分的に差異のあるシステムを多数開発しているケースが多い。近年、製品ラインアップの共通性と差異性とを分析し、効果的なソフトウェア資産の形成を目指す『プロダクトライン・ソフトウェア・エンジニアリング（以下、ＰＬＳＥと省略）』と呼ばれる手法が提唱されつつあり、機器制御システムの分野へも適用が試みられている。

ラダープログラムは、全回路をサイクリックスキャンすることによって動作するという特徴から、プログラムの規模の増大がそのまま実行時間性能の低下つながる性質がある。そのため実行性能の観点から利用するラダープログラム部品は、極力使用されるアプリケーションに不要な回路を含まないことが望まれる。

しかしながら、複数のアプリケーションにおいて再利用できる汎用性のあるプログラム部品を作成するには、プログラム部品の内部構成や振る舞いにある程度のバリエーションを持たせ、オプション設定などにより内部構成や振る舞いを少し変更させることができる必要が生じる。たとえば火災検出アルゴリズムのプログラム部品を考える場合、火災検出用のセンサの数や種類、自己診断機能の有無などの、アルゴリズムそのものは同一であっても、使用する具体的なアプリケーションにより複数のバリエーションやオプションを含むことが多い。このようなオプション選択も入力値としてプログラム部品を記述することで汎用性をもったプログラム部品を実装することはできる。しかしながらこの場合、あるシステムの実現には不要なラダー回路が部品中に存在することになりプログラムの実行性能が無為に低下する。このため実行性能の制約に厳しい分野では、汎用性のあるプログラム部品を構成することが困難となっている。

ラダープログラミングにおいてファンクション・ブロックの概念は、後に詳細に説明するが、プログラムの階層的な設計を実現している。しかしＪａｖａ（登録商標）やＣ＋＋などのオブジェクト指向高級言語がプログラム実行時に動的に子インスタンスを構成できるのと異なり、ファンクション・ブロックでは子インスタンスを静的に親ファンクション・ブロック中に記述する。このため中間階層のプログラムを部品化することが困難であり、結果的に大部分は同じだが一部だけが異なる多くのプログラム部品を作成しなければならないという問題が生じる。

そのような場合を以下に、図２５にて示される例を参照して説明する。図２５には、ラダープログラミングにおけるファンクションブロックによるプログラムの階層的な設計の一例が示されている。図２５（ａ）にて示されるように、縮みきった状態と伸びきった状態を判定するセンサを持つエアシリンダ１００を制御するプログラム部品を一例として考える。このエアシリンダ１００には、筒状のシリンダ部１０１と、このシリンダ部１０１に挿入され、前後に伸縮可能なアーム部１０２によって概略構成される。このようなエアシリンダには、その伸びきり状態や縮みきり状態を検出するためのセンサが用いられ、例えば、センサとして光センサがついているものもあれば、同じ入出力をもつ磁気センサを持つものも考えられる。

しかし、図２５（ｂ）にて示されるように、ロボットアームの制御プログラム１１１には、エアシリンダの制御を行うプログラム１１２が組み込まれており、さらに、そのエアシリンダを制御するプログラム１１２に、磁気センサの制御プログラム１１３が組み込まれており、階層的な構造を有している。このようなエアシリンダにおいては、センサの種類にかかわらずエアシリンダ制御部の挙動は同一であるのだが、磁気センサを制御するプログラムがエアシリンダの制御プログラムに、そしてロボットアームの制御プログラムに組み込まれているため、センサとして光センサを用いるような場合においては、センサの制御プログラムのみを取り替えるということができない。従って、このような場合、ファンクション・ブロックでは使用するセンサの種類の組み合わせの数だけ『エアシリンダ』部品を作成しなければならない。

例えば、Ｃ言語ではマクロ処理によってソースコードを変形させることにより、Ｃ言語の言語仕様の範囲では実現できない高度な部品化を行う試みが既になされている。しかし当然ながら、Ｃ言語に特化したマクロであり、本発明が対象とするラダープログラミングの分野にはそのまま適用することはできない。

そして、本含発明の発明者は、性能的なオーバーヘッドを生じさせることなく汎用性の高いラダープログラムの部品化を実現する手段の一つとして、部品のバリアビリティーポイント（変化点）を定義して、予めラダープログラムにマクロとして組み込み、与える具体的なパラメータセットを変更することによってマクロ処理により変形した部品を生成する手法を考案した。
特開平６−２３０８０４号公報

しかしながら、マクロを含むラダープログラムはマクロ処理（最終的な部品として確定した状態）した後でないと実行できないので、原始プログラム（資産部品）とテストやデバッグ対象のプログラムが異なる。このことは、マクロ記述を施した原始プログラムには、変化点を組み込んでいることから不要な回路も入っており、そこに具体的なパラメータを入力してマクロ処理を実行することによりテストやデバッグ処理を行う最終部品として完成するためである。そして、プログラムのテストを実行するためにはシミュレータが用いられるが、そのシミュレータは、具体的なパラメータが入っている最終的なプログラムでないとテストを実行できない。

また、部品をデバッグするためには、以下のような煩雑な作業が必要となり、作業効率が低下してしまうという不具合が生じていた。
１．マクロ記述を含む資産部品をマクロ処理し、特定アプリケーション専用の部品に変形する。
２．その変形部品をラダープログラミングツールで読み込み、ＰＬＣにダウンロードする。
３．ＰＬＣを実行し、ＰＬＣの外部入力をＯＮ／ＯＦＦしながらラダー部品の動作を確認する。
４．ラダー部品にバグがある場合は、ラダープログラミングツールで修正する。バグがなくなるまでＰＬＣで実行しながら繰り返す。
５．修正が完了したら、ＰＬＣよりラダープログラミングツールでラダー部品をアップロードする。
６．修正箇所を特定した上で、マクロ記述を含む資産部品に修正を手動で反映する。

上記のように、変形後の最終部品でテストを行っても、変形部品としての状態で不具合があるかどうかの判定にすぎない。そのため、ユーザが手動にてラダープログラミングツールを介して、資産部品に対してテスト結果を反映させるという煩雑な作業が求められていた。

本発明は上記の問題点に着目したもので、その目的とするところは、マクロを含むラダープログラム部品の単体テスト作業を効率化する環境を提供し、マクロ記述を含む資産部品のデバッグ効率の向上を実現することである。

本発明のさらに他の目的並びに作用効果については、明細書の以下の記述を参照することにより、当業者であれば容易に理解されるであろう。

本発明に係るプログラム部品のデバッグ方法は、ラダープログラムを作成するためのプログラム部品のデバッグ方法であって、当該ラダープログラムの接点や回路を組み替えることを目的としたマクロ処理言語をプログラム部品に記述するステップと、マクロ記述を含むプログラム部品にマクロ処理を実行し、特定アプリケーション専用プログラム部品へと変形させるマクロ処理ステップと、特定アプリケーション専用プログラム部品に対して単体テストを実行し、適宜修正を行うデバッグ処理を実行するデバッグ処理ステップと、デバッグ処理にて行った修正を、特定アプリケーション専用プログラム部品にその修正箇所と修正内容をコメントとして記述するステップと、前記コメントが記述された特定アプリケーション専用プログラム部品を逆変換する際には、記述されたコメントを参照して、デバッグ処理にて行った修正をマクロ処理を実行する前のマクロ記述を含むプログラム部品に反映させるマクロ逆変換処理ステップと、を具備することを特徴とする。

ここで言う『コメント』とは、ラインコメント、命令コメント、または変数コメント等を含み、実行された特定アプリケーション専用プログラム部品への修正についてその実行箇所や実行内容を特定するコメントである。そして、このコメントの特徴として、マクロ処理に対応していないラダーのプログラミングツールでも開くことが可能とされている。

このような構成により、多岐にわたるアプリケーションに対応できるように可変性を有するプログラム部品に対して効率よくデバッグ処理を実行することが可能となる。

また、デバッグ処理の過程で発生した修正をコメントとして記述することで、そのコメントを参照して特定のアプリケーション専用プログラム部品を、可変性を有するマクロ記述を含むプログラム部品に変換することが可能となる。

本発明の実施の形態においては、マクロ逆変換処理ステップによって得られたマクロ記述を含むプログラム部品を、プログラム部品を格納するプログラム部品データベースに格納するステップをさらに具備することを特徴とする。

このような構成により、デバッグ処理にて知見されたバグ等に対応する修正をプログラムデータベースに自動的に反映させることが可能となる。

本発明の実施の形態においては、デバッグ処理が、仮想入力と期待出力とを設定可能とされた単体テストツールとＰＬＣシミュレータを含む仮想実行環境において実行され、単体テストツールは、シミュレータに仮想入力を与えるステップと、ＰＬＣシミュレータからの出力を予め設定された期待出力と比較してテストの可否を判断するステップと、をさらに具備することを特徴とする。

このような構成により、特定アプリケーション専用プログラムに対して仮想のラダー実行環境にてプログラム部品単体でのテストが実行可能とされ、実際にプログラム部品を組み込んでラダープログラムを作成する前に、部品単位でデバッグ作業が行うことが可能となる。ため、デバッグ処理の作業効率が向上する。また、デバッグ処理の過程で生じた修正は自動的にマクロ逆変換処理によってプログラム部品データベースに反映されるため、デバッグ処理とデータベースへの修正入力処理の作業効率が向上する。

本発明に係るプログラム部品のデバッグ支援装置は、ラダー言語によって記述された複数のプログラム部品を組み合わせて機器制御プログラムにおけるプログラム部品のデバッグ処理を支援するデバッグ支援装置であって、当該ラダープログラムの接点や回路を組み替えることを目的としたマクロ処理言語をプログラム部品に記述する手段と、マクロ記述を含むプログラム部品にマクロ処理を実行し、特定アプリケーション専用プログラム部品へと変形させるマクロ処理手段と、特定アプリケーション専用プログラム部品に対して単体テストを実行し、適宜修正を行うデバッグ処理を実行するデバッグ処理手段と、デバッグ処理にて行った修正を、特定アプリケーション専用プログラム部品にその修正箇所と修正内容をコメントとして記述する手段と、前記コメントが記述された特定アプリケーション専用プログラム部品を逆変換する際には、記述されたコメントを参照して、デバッグ処理にて行った修正をマクロ処理を実行する前のマクロ記述を含むプログラム部品に反映させるマクロ逆変換処理手段とを具備することを特徴とする。

本発明の実施の形態においては、マクロ逆変換処理手段によって得られたマクロ記述を含むプログラム部品を、プログラム部品を格納するプログラム部品データベースに格納する手段とをさらに具備することを特徴とする。

本発明の実施の形態においては、デバッグ処理が、仮想入力と期待出力とを設定可能とされた単体テストツールとＰＬＣシミュレータを含む仮想実行環境において実行され、単体テストツールは、シミュレータに仮想入力を与える手段と、ＰＬＣシミュレータからの出力を予め設定された期待出力と比較してテストの可否を判断する手段と、をさらに具備することを特徴とする。

以上の説明で明らかなように、本発明によれば、マクロを含むラダープログラムのデバッグ作業において、手作業での煩雑な作業を省くことが可能となり、開発作業効率を向上させるという利点を有する。

また、本発明によれば、修正された特定アプリケーションのプログラム部品の変更点のみを、原始プログラム（マクロ記述を含む資産部品）に自動反映できるようになり、作業効率を向上させることが可能となるという利点を有する。

以下に、この発明の好適な実施の一形態を添付図面を参照しながら詳細に説明する。

本発明においては、対象となる製品のアプリケーション群（プロダクトライン）において共通性と差異性とを分析し、共通部分と差異部分とが一つの部品内に混在しないように部品を設計する。図１に製品の共通性と差異性とを分けた一例を説明する図が示されている。同図（ａ）には、開発対象のみを考慮した分析並びに設計の一例が示されている。同図にて示されるように、対象となる製品のみを考慮した場合、その製品を基礎として、異なる状況に対応できるような次の製品、並びに製品のバリエーションを作成する際に、例えば、同図の変更箇所１〜４にて示されるように変更箇所が多岐にわたってしまう。そのため、次の製品を作成するためにどこを変更すればよいのか分かりづらくなってしまう。また、それらの変更箇所１〜４は、モジュールＡ〜Ｄに組み込まれており、変更箇所のみを入れ替えて対応することが困難である。そのため、共通部分が多く、部分的な変更によって対応できるような場合においても再度製品を作成する必要が生じてしまうことがある。そこで、同図（ｂ）にて示されるように、対象となる製品のみではなく、製品の品揃えに加えて将来のバージョンアップも含めて、共通性と差異性とを分析することによって、同図（ｃ）にて示されるように、対象製品のバリエーションにおいて差異部分のみをまとめたモジュール５を構成することが可能となる。そして、このように共通部分と差異部分とを明確に分けて部品設計を行うことにより、異なる製品バリエーション等を作成する際にはその差異部分に対応する別のモジュール６と置き換えることにより容易に当該製品のバリエーションを作成することが可能となる。

図２には、一つの実施形態として検査装置１０が示されている。同図において点線にて描かれた円１１〜１７にて示されるように、当該検査装置はその機能や処理内容によって大まかに７つの部分に分けられる。

先ず、供給部１１を介して当該検査装置において検査対象となるワークが装置へと供給される。そして、エレベータ１２とロードアーム１３とを介して、ワークはインデックステーブル１４へと移動する。このインデックステーブル１４が回転動作を行うことにより、ワークは検査位置へと移動し、検査ヘッド１５が所定位置に降下し検査を行う。インデックステーブル１４は更に回転し、ワークを取り出し位置へと移動する。アンロードアーム１６によってワークはインデックステーブル１４から取り出され、排出部１７は、検査結果に従い良品／不良品とを分別して排出する。

次に、上記の検査装置に対して、同様の検査機能を有するものの、一部の特性において仕様の異なるバリエーションが表形式にて図３に示されている。同図における検査装置Ａが先に図２を用いて説明した検査装置の一例であり、検査装置Ｂとは、その検査装置Ａの特性を一部を変更したバリエーションである。同図に示される検査装置Ａと検査装置Ｂとの特性を比較すると、ワークの搬入及び搬出に関しては双方ともロボット輸送を採用しているが、それ以外の特性においては差異が見られる。例えば、供給部において、検査装置Ａはエレベータ供給を採用しているが、検査装置Ｂは採用していない。同様に、検査対象のワークを位置決めするために、検査装置Ａはインデックステーブルを用いているが、検査装置Ｂはベルトコンベアを採用している。同様に、ワークの停止位置についても、検査装置Ａは４ポジションによる位置決めを行っているが、検査装置Ｂではセンサによる位置決めを採用している。そして、検査を行う際に、検査装置Ａはカラーセンサを採用しているが、検査装置Ｂは画像センサを用いている。また、検査後のワークの排出については、検査装置Ａはロボットによる良品と不良品との分別を行っており、検査装置Ｂでは不良品のみを押し出す方法を採用している。

これらの検査装置Ａ並びに検査装置Ｂを特性によって共通部分と差異部分とに分けたコンポーネント図が図４〜６に示されている。図４には、コンポーネントの全体図が示されている。同図にて示されるように、検査装置２０は、ワーク搬入部２１、位置決め部２２、検査部２３、及びワーク搬出部２４に区分されている。そして、ワーク搬入部２１は、さらに供給部２１ａとロードアーム２１ｂとが備えられている。そして、位置決め部２２にはインデックステーブル２２ａとベルトコンベア２２ｂが、検査部２３には検査方法２５が、そしてワーク搬出部２４にはアンロ―ドアーム２４ａと仕分け部２４ｂとがそれぞれ備えられている。

図５には、ワーク搬入部２１における検査装置Ａ並びに検査装置Ｂの共通性と差異性が示されている。同図にて示されるように、検査装置Ａは、ワーク搬入部２１として供給部（エレベータ供給）２１ａとロードアーム２１ｂが備えられているが、それに対して検査装置Ｂは供給部２１ａはなく、ロードアーム２１ｂのみ備えられている。すなわち、これらの検査装置においては、供給部２１ａが差異部分であり、ロードアーム２１ｂは共通部分となる。そして、このように製品バリエーションにおける差異部分となった供給部２１ａは、オプション部品として切り出しておく。

図６には位置決め部２２における検査装置Ａ並びに検査装置Ｂの共通性と差異性が示されている。同図にて示されるように、検査装置Ａは、位置決め部２２としてインデックステーブル２２ａを採用しているが、それに対して検査装置Ｂはベルトコンベア２２ｂを採用している。すなわち、これらの検査装置においては、インデックステーブル２２ａとベルトコンベア２２ｂとのいずれかを選択することとなる。そして、このような場合は、インデックステーブル２２ａとベルトコンベア２２ｂとを代替部品（代替コンポーネント）として切り出しておく。

このとき、ラダープログラムにて必要な回路を行単位で取り出すマクロ例としては、
！＄ＩＦ（condition）[
true statements
！][
false statements
！]
となる。ここで、conditionには、条件を記述する。ある特性が選択されているかどうかを条件とする場合は、
；＄feature=true
もしくは、
；＄feature=false
と記述する。このとき、feature（特性）には、特定の特性名を指定する。そして、true statementsとfalse statementsには、取り出したい範囲の回路が入り、行コメントに記述された[]で囲む。

このようなマクロを使用した例が図７及び８に示されている。図７には上述のワーク搬入部２１のファンクションブロックが示されており、オプションの扱いが示されている。同図にて示されるように、『エレベータ供給』が条件として記述されており、オプションとして選択されていることが示されている。

そして、図８には位置決め部２２のファンクションブロックが示されており、代替の扱いが示されている。同図にて示されるように、インデックステーブルとベルトコンベアが代替として記述されている。このように、アプリケーション毎の部品に生じる差異は部品の変形で対応する。尚、ここでは、ワーク搬入部２１におけるエレベータ供給と、位置決め部２２におけるインデックステーブルとベルトコンベアについて説明したが、他の差異についても同様に対応できることは言うまでもない。

図９及び図１０に、特性モデルの例が示されている。特性モデルとは、後に詳細に説明するが、製品ラインアップを特性によって表現したモデルである。これらの図にて示されるように、検査装置３０は、その特性によって供給３１，ワーク搬入３２，位置決め３３，検査３４，ワーク搬出３５，排出３６のコンポーネントに分けられる。そして、供給３１にはエレベータ供給がオプション・コンポーネントとして備えられている。ここで、エレベータ供給に設けられている円３７ａは、この特性がオプション・コンポーネントとして選択可能に設定されていることを示している。それに対して、ワーク搬入３２及びワーク搬出３５に設けられたロボット輸送３８及び４０は、オプションとしての特性ではないため、エレベータ供給３７における円３７ａのような表示はされていない。

また、位置決め３３には停止位置３９が設けられており、その停止位置は、その特性上さらに４ポジション３９ａとセンサによる位置決め３９ｂとが代替コンポーネントとして設けられている。同様に、検査３４にはカラーセンサ３４ａと画像センサ３４ｂが、そして排出３６には不良品のみ押し出し３６ａとロボットによる分別３６ｂとがそれぞれ代替コンポーネントとして設定されている。

図１０は、上述の特性モデルにおいて、オプションの選択有無、及びどちらの代替コンポーネントが使用されているかを示している。同図にて示されるように、オプションとして設けられているエレベータ供給３７には、黒点４１にてマーキングが施されている。この黒点４１は、対象となる特性コンポーネントが選択されていることを示すものである。同様に、４ポジション３９ａ、画像センサ３４ｂ、及びロボットによる分別３６ｂにも黒点４１が施され、これらの特性が選択されていることを示している。そして、このような特性を組み合わせていくと、先に説明した検査装置Ａのような特性を有する検査装置が実現される。さらに、このような特性モデル、並びに特性の選択有無をしめすマーキングをユーザに対して画像モニタ等にて表示することによって、どの特性が選択されているのか、並びに選択可能な特性が一目瞭然となる。

次に、本発明における実施形態のソフトウェア構成図が図１１に示されている。

同図にて示されるように、この実施形態においては、ドメイン分析支援ツール５０、プログラム部品管理ソフトウェア６０、ラダー・プログラミング・ツール７０、及びプログラム部品データベース８０とによって概略構成されている。

ドメイン分析支援ツール５０内のＦｅａｔｕｒｅモデルエディタ（以下、特性モデルエディタと言う）５１とは、開発対象ドメインにおける製品ラインアップの共通性と差異性とを分析し、製品ラインアップを『特性』によって表現した分析モデルである『ＦｅａｔｕｒｅＭｏｄｅｌ（以下、特性モデルと言う）』と製品の特性情報５２を作成するものである。

次に、プログラム管理ソフトウェア６０内の各機能を説明する。プロダクト・パラメータ・マネージャ６１とは、ある製品のアプリケーションを構築するために必要なプログラム部品群と、そこに含まれるマクロへの入力パラメータセット（以下、プロダクト・パラメータと言う）を管理するものである。本実施形態では、ドメイン分析支援ツール５０が作成する特性モデルと、製品の特性情報５２を元に、プロダクト・パラメータを作成する機能も備えている。

コンポーネント・マネージャ６６とは、ラダープログラムの作成用のプログラム部品６５が格納されているプログラム部品データベース８０から、プロダクト・パラメータ・マネージャ６１によって作成されたプロダクト・パラメータに従い、必要となるラダープログラム部品を取り出す機能を有する。また、プログラム部品データベース８０に格納されていない部品を新規作成したり、既存のプログラム部品６５に編集を加えた場合において、新たに作成されたプログラム部品６５をプログラム部品データベース８０に格納する機能も有する。

コンポーネント・エディタ６２とは、マクロを含んだラダープログラム部品の編集を行うものである。この実施形態においては、マクロの編集機能と、ラダープログラムの編集機能とを併せ持っている。

コンポーネント・デバッガ６３とは、マクロ処理事項前後での、ラダープログラムの紐付け情報を管理する。マクロ処理後のプログラム部品に対する修正や変更を、マクロ処理実行前の汎用的なプログラム部品に反映させる機能を有する。

マクロ・プロセッサ６７とは、マクロ記述とプロダクト・パラメータに従い、ラダープログラムの変形を実行し、特定アプリケーション用のプログラム部品を生成する機能を有する。

そして、ラダー・プログラミング・ツール７０には、図示しないラダーエディタ・デバッガが含まれており、一般的なラダープログラミングツールであるため、詳細な説明は省略する。このラダープログラミングツール７０では、プログラム部品管理ソフトウェアによって生成されたラダープログラム部品（特定アプリケーション専用プログラム部品９０）を用いて、アプリケーションを作成する。また、ラダー・プログラミング・ツール７０は、図示しないが、ＰＬＣシミュレータと単体テストツール等によって構成されるラダー実行環境と接続されており、作成されたプログラムをラダー実行環境へとダウンリロードし、単体テストを実行可能とする。

次に、図１２〜図１４に、全体の処理を示すフローチャートが示されている。これらのフローチャートにて示されるように、特性モデルエディタ５１は、ユーザが選択した特性を保存する（ステップ１００１）。続いて、プロダクト・パラメータ・マネージャ６１が特性選択結果よりマクロへの入力パラメータ６４を生成する（ステップ１００２）。続いて、コンポーネント・マネージャ６６は、ユーザが選択したコンポーネントを記憶し（ステップ１００３）、プログラム部品データベース８０より資産プログラム部品（マクロ記述済みのプログラム部品）６５を取り出し（ステップ１００４）、資産プログラム部品６５と入力パラメータ６４とをマクロ・プロセッサへと渡す（ステップ１００５）。マクロ・プロセッサ６７は、マクロ処理を実行し、資産プログラム部品６５を変形して、特定アプリケーション専用プログラム部品９０を生成する（ステップ１００６）。

図１１に続き、コンポーネント・デバッガ６３は、特定アプリケーション専用プログラム部品９０をラダー・プログラミング・ツール７０へと送る（ステップ１００７）。そして、ラダー実行環境にプログラムをダウンロードし、単体テストを実行する（ステップ１００８）。この単体テストに合格しない場合（ステップ１００９，ＮＯ）、ラダー・プログラミング・ツール７０にてプログラムを修正し（ステップ１０１０）、ステップ１００８に戻りラダー実行環境にダウンロードし単体テストを実行する。それに対して、ステップ１００８の単体テストに合格した場合（ステップ１００９，ＹＥＳ）、ラダー・プログラミング・ツール７０にてプログラムをアップロードする（ステップ１０１１）。続いて、コンポーネント・デバッガ６３にてマクロの逆変換処理を実行する（ステップ１０１２）。ここで、マクロの逆変換処理に成功した場合（ステップ１０１３，ＹＥＳ）、コンポーネント・デバッガ６３にてマクロの逆変換処理を実行し（ステップ１０１４）、コンポーネント・マネージャ６６が資産プログラム部品を上書き更新する（ステップ１０１５）。それに対して、ステップ１０１２におけるマクロの逆変換処理が成功しなかった場合（ステップ１０１３，ＮＯ）、修正前との差分を表示し（ステップ１０１６）、ユーザがコンポーネント・エディタ６２で直接資産プログラムの更新を実行する（ステップ１０１７）。ここでのマクロ逆変換処理が成功しない場合とは、マクロ処理した部分にユーザが変更を加えた場合のことであり、その修正が加えられる前との差分（差異部分）を表示して、ユーザが直接マクロプログラムを更新するようにしたものである。

続いて、図１５及び図１６に、マクロ処理のフローチャートが記されている。同図にて示されるように、先ず資産プログラム部品を格納しているファイルがオープンされ（ステップ１３０１）、新しい特定アプリケーションプログラム部品９０を格納するファイルを新規作成する（ステップ１３０２）。続いて、資産プログラム部品のスキャンが実行される（ステップ１３０３）。資産プログラム部品６５をスキャンした結果、ファイルの終わりであれば（ステップ１３０４，ＹＥＳ）、資産プログラム部品ファイル、特定アプリケーションプログラム部品ファイルをクローズし、処理を終える（ステップ１３０５）。

ステップ１３０３に戻り、資産プログラム部品６５をスキャンした結果、ファイルの終わりでなければ（ステップ１３０４，ＮＯ）、続いてマクロ処理が行われているかどうかの判別が実行される（ステップ１３０６）。このとき、マクロ処理が行われていなければ、資産プログラム部品６５から特定アプリケーション専用プログラム部品９０に、その行を単純コピーし（ステップ１３０７）、ステップ１３０４に戻りファイルの終わりであるかどうかの判別を実行する。それに対して、マクロ処理がある場合（ステップ１３０６，ＹＥＳ）、マクロ命令を取り出し（ステップ１３０８）、マクロＩＤをインクリメントする（ステップ１３０９）。

続いて、取り出されたマクロ命令の種類の判別が行われる（ステップ１３１０）。このとき、同図においては、必要な回路を取り出す（ステップ１３１１）、回路を行単位でコピーする（ステップ１３１２）、及び命令をＡＮＤ接続でコピーする（ステップ１３１３）の３つが記載されているが、これらはマクロ命令の一例に過ぎず、後に説明する様々なマクロ命令の種類の判別を実行する。マクロ命令の種類判別が実行されると、続いて、コメントとして記述されているマクロ命令にマクロＩＤを追加する（ステップ１３１４）。ここで言うマクロＩＤとは、ラダープログラムにおけるマクロ処理の記述部位を示す識別子であり、例えば、ライン番号等が用いられる。そして、マクロ命令で削除されるオリジナル回路はコメントアウトし、マーク（ＲＥＭ文とマクロＩＤを追加）を付けておく（ステップ１３１５）。ここで言うＲＥＭとは、Remarkの略であり、コメントが挿入されていることを意味するものである。

その後、マクロ命令で追加、変形された結果の回路の前後にコメントでマクロＩＤを挿入する（ステップ１３１６）。ここで、その例を以下に示す。
（^＊MacroID=3:マクロ命令[^＊]
（^＊]^＊）
（^＊BEGIN(3)^＊）
変形結果
（^＊END(3)^＊）
マクロＩＤの挿入後、特定アプリケーションプログラム部品ファイルに一連の処理を書き出し（ステップ１３１７）、ステップ１３０４に戻ってファイルの終わりであるかどうかの識別を実行し、その後上述の処理を繰り返す。

本実施形態においては、ラダープログラムに対して以下の操作を行うためのマクロを定義する。

＜宣言の変更＞
（１）変数宣言の複製
（２）変数名の変更
（３）入出力属性の変更
＜ラダー回路の変更＞
（１）接点名の変更
（２）応用命令へのオペランド変更
（３）ファンクション・ブロック・インスタンスの入れ替え
（４）ライン内の特定のＩＮ接点のｎ倍化
（ア）ＩＮ接点を連番で複製し、ＡＮＤ命令で接続
（イ）ＩＮ接点を連番で複製し、ＯＲ命令で接続
（５）ライン内の特定のＯＵＴ接点のｎ倍化
（ア）ＯＵＴ接点を連番で複製し、ＯＲ命令で接続
（イ）応用命令を連番で複製し、ＯＲ命令で接続
（ウ）ファンクション・ブロック・インスタンスを連番で複製し、ＯＲ命令で接続（６）ライン単位での変形
（ア）ブロック単位での入れ替え
（イ）ブロック単位でのｎ倍化
（７）ＰＯＵ（Program Organization Unit：プログラム部品）名の変更
（８）ＰＯＵのｎ倍化

そして、図１７に、本実施形態におけるマクロの定義体系が示されている。同図にて示されるように、この例でのマクロ定義は、ＦＢ（Function Block）内部変数宣言の操作、回路の操作、ＰＯＵ操作の３つに大別され、それらの操作からさらに詳細操作が枝分かれしている。

本マクロを使用した例が図１８に示されている。同図にて示されるケースは、先に説明した、行単位で必要な回路を取り出すマクロの一例であり、inputというオプションが存在していることが前提とされる。図１８（ａ）では、行単位で回路を取り出す条件として、inputと言う特性が記述されており、そのinputが選択されていることが条件であることを示す
；＄feature（この例ではinput）=true
という記述もされている。これに対してマクロ処理を行う。inputという特性が選択されていると、図１８（ｂ）の回路が得られる。それに対して、inputとい特性が選択されていないと、条件が満たされていないため、上同図（ｂ）の回路は取り出されずに、図１８（ｃ）の回路が得られる。このとき、条件として記述されている特性が選択されているか否かは先に図９及び図１０を参照して説明した特性モデルで確認することが可能である。

この処理をテキストファイル形式で表したものが図１９に示されている。同図にて示されるように、条件である特性（input）が選択されているかどうかで得られる回路は異なる。同図左側が、inputが選択されている場合を示し、同図右側がinputが選択されていない場合を示している。尚、他のマクロの例が図２０の表に示されている。図２０の表にてＦＢとは、Function Blockの略であり、ファンクションブロックを意味するものであり、ＰＯＵとは、上述のプログラム部品を意味する。

次に、図２１〜２４を参照して本発明による、マクロ記述を含むプログラム部品のデバッグ方法を説明する。図２１には、特定アプリケーション専用プログラム部品のデバッグ処理と、ツールの機能の関係を説明するための図が記されている。

同図にて示されるように、コンポーネントエディタ１２０は、プログラム部品データベース１３０に格納されているプログラム部品を取り出し、その部品に対してマクロ記述を埋め込むことによりマクロ入り資産部品の作成を行い、作成されたマクロ記述入り資産部品をプログラム部品データベース１３０に格納する。そして、プログラム部品管理ソフトウェア１４０内に格納されているマクロ処理部１４１（マクロプロセッサ）が、当該マクロ記述が埋め込まれたプログラム部品に対してマクロ処理を実行し、プログラム部品に対する変形を実行する。

マクロプロセッサ１４１によって変形されたプログラム部品（同図では変形部品）１５１は、特定アプリケーション専用プログラム部品１５０となり、ラダープログラミングツール１６０へと送られる。ラダープログラミングツール１６０は、単体テストツール１７１とＰＬＣシミュレータ１７２を備えたラダー実行環境１７０に接続されており、特定アプリケーション専用プログラム部品１５０を用いたプログラムを作成し、ラダー実行環境１７０へとダウンロードする。ラダー実行環境１７０とは、テストを実行するための仮想実行環境である。ラダー実行環境１７０においては、単体テストツール１７１がダウンロードしたプログラムをＰＬＣシミュレータ１７２に仮想入力し、単体テストを実行する。このとき、単体テストツール１７１は、仮想入力と期待出力のペアがテストケースとして設定されている。そして、ＰＬＣシミュレータ１７２に仮想入力を与え、ＰＬＣシミュレータ１７２からの出力と、設定していた期待出力とを比較して、単体テストのＯＫ／ＮＧを判定する。単体テストの結果がＮＧであれば、ラダープログラミングツール１６０にて部品の修正が実行され、テストに合格するまで繰り返し実行される。

ラダープログラミングツール１６０にて修正された部品１５２は特定アプリケーション専用プログラム部品１５０として、プログラム部品管理ソフトウェア１４０に格納されるマクロ逆変換部（コンポーネントデバッガ）１４２によって、マクロの逆変換処理が実行される。このマクロ逆変換部１４２にてマクロの逆変換処理が実行されることにより、単体テストに合格した修正された部品１５２を、マクロ記述入りのプログラム部品の状態に戻すことが可能となり、その状態でプログラム部品データベース１３０にマクロ実行前の資産部品にラダープログラミングツール１６０で行われた修正が反映され、格納される。

このマクロの逆変換処理のフローチャートが図２２に示されている。同図にて示されるように、先ず、資産プログラム部品を格納する一時ファイルを新規作成する（ステップ２４０１）。続いて、特定アプリケーション専用プログラム部品を格納するファイルをオープンし（ステップ２４０２）、特定アプリケーション専用プログラム部品をスキャンする（ステップ２４０３）。このとき、ファイルの終わりであれば（ステップ２４０４，ＹＥＳ）、資産プログラム部品ファイル、特定アプリケーション専用プログラムファイルをクローズし（ステップ２４０５）、作業は終了する。これに対して、ファイルの終わりでなければ（ステップ２４０４，ＮＯ）、続いて当該特定アプリケーション専用プログラム部品にＲＥＭマークが記述されているかどうかの識別が実行される（ステップ２４０６）。ここでのＲＥＭとは、先に説明したように、コメントが挿入されていることを示す識別子であり、ＲＥＭマークがあるということは、ラダープログラミングツールにて修正が実行されたことを意味するものである。

そして、ＲＥＭマークがある場合（ステップ２４０６，ＹＥＳ）、当該特定アプリケーション専用プログラム部品からＲＥＭマークを削除し、コメントアウトを解除したものを資産プログラム部品にコピーし（ステップ２４０７）、ステップ２４０３に戻り、特定アプリケーション部品のスキャンを行い、ファイルの終わりに到達するまで作業を繰り返す。

また、ステップ２４０６において、ＲＥＭマークがない場合（ステップ２４０６，ＮＯ）、続いてＢＥＧＩＮマークの有無が確認される（ステップ２４０８）。ここで、ＢＥＧＩＮマークがある場合（ステップ２４０８，ＹＥＳ）、ＥＮＤマークまでスキップし（ステップ２４０９）、ステップ２４０４に戻り特定アプリケーション部品のスキャンを行い、ファイルの終わりに到達するまで作業を繰り返す。また、ステップ２４０８にてＢＥＧＩＮマークがない場合（ステップ２４０８，ＮＯ）、特定アプリケーション専用プログラム部品から資産プログラム部品に対象となる行を単純コピーし（ステップ２４１０）、ステップ２４０４に戻り特定アプリケーション部品のスキャンを行い、ファイルの終わりに到達するまで作業を繰り返す。

本発明においては、プログラム部品には、様々なアプリケーションに対応できるように、変化点（変更箇所）にマクロ記述が組み込まれている。そして、このマクロ記述を含むプログラム部品に、パラメータを入力することによって、特定のアプリケーション専用のプログラム部品が作成される。ところが、マクロ記述を含むプログラム部品は、先に説明したように、多様のアプリケーションに対応できるように部品の変化点ををマクロとして組み込んでいるため、その状態ではシミュレータによるテストやデバッグ処理が実行できない。

そこで、上述のように、特定アプリケーション専用プログラム部品をマクロ処理によって作成し、テストやデバッグ処理を実行できる状態にすることが必要となる。また、デバッグ処理の過程で、特定アプリケーション専用プログラム部品に不具合が生じて修正が必要となった場合、その修正箇所並びに修正内容をコメントとして特定アプリケーション専用プログラム部品に記述することによって、当該コメントを参照して特定アプリケーション専用プログラム部品に対してマクロ逆変換処理を実行して原始プログラムであるマクロ記述を含むプログラム部品を得ることが可能となる。その後、得られたマクロ記述を含むプログラム部品をプログラム部品データベースに反映させることにより、マクロ記述を含むプログラム部品のデバッグ処理並びにデータベースへの反映を自動的に行うことが可能となり、デバッグ処理の作業効率が向上する。

次に、図２３及び図２４を参照して、マクロ逆変換処理の一例を説明する。図２３には、マクロ記述入りの資産部品（マクロ処理実行前）に対してマクロ処理を実行した場合の一例が示されており、図２４には、特定アプリケーション専用プログラム部品に対してマクロ逆変換処理を実行した一例が示されている。

図２３にて示されるように、資産部品において設定されている条件（inputという特性が選択されているかどうか）によって、２通りの処理が実行される。このことは、先に説明したのでここでの説明は省略する。ここで、inputがtrueであると仮定し、その結果作成された部品が特定アプリケーション専用プログラム部品であるとする。この場合、inputがtrueとなり、条件を満たしているため、
LD in
OUT out
が選択され、
LD in_1
AND in_2
OUT out
は削除される。そして、削除した項目については、ＲＥＭ文によってコメントとして残されている。

続いて、図２４似て示されるように、この特定アプリケーション専用プログラム部品に対してマクロ逆変換処理を行うと、削除された項目については、当該特定アプリケーションプログラム部品にＲＥＭ文にてコメントとして記述されているため、マクロ逆変換処理を実行することにより、容易にマクロ処理前の資産部品を得ることが可能となる。ここで、同図にて『xxxxxxx』にて示されるのは、当該特定アプリケーション専用プログラム部品が、単体テストの結果を受けてラダープログラミングツールが何らかの修正を施していた場合であり、その修正部分を表している。この修正がマクロ逆変換処理によって資産部品にも反映されている。このようなマクロ逆変換処理、並びに特定アプリケーション専用プログラム部品に施された修正事項を資産部品に自動反映させることにより、ラダー実行環境において好適な資産部品を再構築して以後の使用に備えて保存することが可能となる。

本発明によれば、マクロを含むラダープログラムのデバッグ作業において、手作業での修正反映などの煩雑な作業を自動化し、作業効率を向上させることが可能となるという利点を有する。

製品の共通性と差異性との分析を説明する図である。本発明の一実施形態である検査装置の構造を示す図である。検査装置における特性のバリエーションを表形式で示した図である。コンポーネントの全体構成図である。オプションコンポーネントを説明する図である。代替コンポーネントを説明する図である。オプションコンポーネントを記述するファンクションブロックの一例を示す図である。代替コンポーネントを記述するファンクションブロックの一例を示す図である。特性モデルの全体図である。特性モデルにおいて、オプションコンポーネントと代替コンポーネントの選択状態を示す図である。本発明の実施形態におけるソフトウェア構成図である。全体の処理を示すフローチャート（その１）である。全体の処理を示すフローチャート（その２）である。全体の処理を示すフローチャート（その３）である。マクロ処理を示すフローチャート（その１）である。マクロ処理を示すフローチャート（その２）である。マクロの定義体系を説明するための図である。本発明のマクロ処理の実行例を説明するための図である。本発明のマクロ処理をテキストファイル形式で表した図である。本発明におけるマクロの一例を示す図である。特定アプリケーション専用プログラム部品のデバッグ処理とツールの機能の関係を説明するための図である。マクロ逆変換処理を示すフローチャートである。マクロ処理を実行した一例を説明するための図である。マクロ逆変換処理を実行した一例を説明するための図である。ファンクションブロックによるプログラムの階層構造を説明する図である。

１〜４変更箇所
５差異箇所のモジュール
６変更用モジュール
１０検査装置
１１供給部
１２エレベータ
１３ロードアーム
１４インデックステーブル
１５検査部
１６アンロードアーム
１７排出部
２０検査装置
２１ワーク搬入部
２１ａ供給部
２１ｂロードアーム
２２位置決め部
２２ａインデックステーブル
２２ｂベルトコンベア
２３検査部
２４ワーク搬出部
２４ａアンロードアーム
２４ｂ仕分け部
２５検査方法
５０ドメイン支援分析ツール
５１ Featureモデルエディタ
５２製品の特性情報
６０プログラム部品管理ソフトウェア
６１プロダクト・パラメータ・マネージャ
６２コンポーネント・エディタ
６３コンポーネント・デバッガ
６４入力パラメータ
６５プログラム部品
６６コンポーネント・マネージャ
６７マクロプロセッサ
７０ラダー・プログラミング・ツール
８０プログラム部品データベース
９０特定アプリケーション専用プログラム部品
１００エアシリンダ
１０１シリンダー部
１０２アーム部
１１１ロボットアーム制御プログラム
１１２エアシリンダ制御プログラム
１１３磁気センサ制御プログラム

Claims

ラダープログラムを作成するためのプログラム部品のデバッグ方法であって、
当該ラダープログラムの接点や回路を組み替えることを目的としたマクロ処理言語をプログラム部品に記述するステップと、
マクロ記述を含むプログラム部品にマクロ処理を実行し、特定アプリケーション専用プログラム部品へと変形させるマクロ処理ステップと、
特定アプリケーション専用プログラム部品に対して単体テストを実行し、テスト結果に応じて適宜修正を行うデバッグ処理を実行するデバッグ処理ステップと、
デバッグ処理にて行った修正を、特定アプリケーション専用プログラム部品にその修正箇所と修正内容をコメントとして記述するステップと、
前記コメントが記述された特定アプリケーション専用プログラム部品を逆変換する際には、記述されたコメントを参照して、デバッグ処理にて行った修正をマクロ処理を実行する前のマクロ記述を含むプログラム部品に反映させるマクロ逆変換処理ステップと
を具備するプログラム部品のデバッグ方法。
マクロ逆変換処理ステップによって得られたマクロ記述を含むプログラム部品を、プログラム部品を格納するプログラム部品データベースに格納するステップをさらに具備する請求項１に記載のプログラム部品のデバッグ方法。
デバッグ処理が、仮想入力と期待出力とを設定可能とされた単体テストツールとＰＬＣシミュレータを含む仮想実行環境において実行され、
単体テストツールは、シミュレータに仮想入力を与えるステップと、
ＰＬＣシミュレータからの出力を予め設定された期待出力と比較してテストの可否を判断するステップと、
をさらに具備する請求項１に記載のプログラム部品のデバッグ方法。
ラダー言語によって記述された複数のプログラム部品を組み合わせて機器制御プログラムにおけるプログラム部品のデバッグ処理を支援するデバッグ支援装置であって、
当該ラダープログラムの接点や回路を組み替えることを目的としたマクロ処理言語をプログラム部品に記述する手段と、
マクロ記述を含むプログラム部品にマクロ処理を実行し、特定アプリケーション専用プログラム部品へと変形させるマクロ処理手段と、
特定アプリケーション専用プログラム部品に対して単体テストを実行し、適宜修正を行うデバッグ処理を実行するデバッグ処理手段と、
デバッグ処理にて行った修正を、特定アプリケーション専用プログラム部品にその修正箇所と修正内容をコメントとして記述する手段と、
前記コメントが記述された特定アプリケーション専用プログラム部品を逆変換する際には、記述されたコメントを参照して、デバッグ処理にて行った修正をマクロ処理を実行する前のマクロ記述を含むプログラム部品に反映させるマクロ逆変換処理手段と
を具備することを特徴とするプログラム部品のデバッグ支援装置。
マクロ逆変換処理手段によって得られたマクロ記述を含むプログラム部品を、プログラム部品を格納するプログラム部品データベースに格納する手段をさらに具備することを特徴とする請求項４に記載のデバッグ支援装置。
デバッグ処理が、仮想入力と期待出力とを設定可能とされた単体テストツールとＰＬＣシミュレータを含む仮想実行環境において実行され、
単体テストツールは、シミュレータに仮想入力を与える手段と、
ＰＬＣシミュレータからの出力を予め設定された期待出力と比較してテストの可否を判断する手段と、
をさらに具備することを特徴とする請求項４に記載のデバッグ支援装置。