JP4488231B2 - プログラム管理装置 - Google Patents

Description

この発明は、機器制御プログラムを構成するプログラム部品についての編集，テストを行なうことのできるプログラム管理装置に関するものである。

工場に設置される検査装置や設備装置は、産業用制御装置が機器制御プログラムを実行することにより制御される。産業用制御装置の具体例は、プログラマブルコントローラである。工場の設備担当者や生産技術担当者などのプログラマブルコントローラユーザは、プログラマブルコントローラに任意の制御を実行させるために、プログラミングツールにてラダープログラムを予め作成する。そして、そのラダープログラムをプログラマブルコントローラに格納する。プログラマブルコントローラは、ラダープログラムをサイクリックに実行し、検査装置や設備装置を任意に制御する。最近では、プログラマブルコントローラの制御内容の一部が違っていても、既存のラダープログラムの一部を必要に応じて編集や修正等を施して、つまりラダープログラムを再利用して、プログラミング作業を効率化することが図られている。その際、プログラム部品管理ツールにて、再利用の対象となるプログラムをデータベース化することも図られている。

ラダープログラムの部品化・再利用化については、一般的にIEC61131規格で定義された”ファンクションブロック”の仕組みを用いて実現されている。ファンクションブロックにより、ラダープログラムと変数のカプセル化が実現され、ラダープログラムを部品として再利用することが可能になっている。変数は、例えばプログラマブルコントローラの制御対象である入出力接点などである。また、ラダープログラムの一部を必要に応じて編集や修正等を施す際に、そのプログラム上の複数箇所に現れる複合処理をそれぞれ簡単なマクロ演算部品の図形で置き換えることにより、図形表示されたプログラムについての一部編集や一部変更等の簡素化を図ることも知られている（特許文献１参照）。

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

しかし、このような分析に基づくプログラム部品化を行う上で、ファンクションブロックによる方法では以下に示す問題を有する。すなわち、プログラマブルコントローラはラダープログラムの全回路をサイクリックにスキャン実行することによって動作する。従って、プログラムの規模の増大がそのままプログラマブルコントローラにおける１スキャンの実行時間性能の低下につながり、引いては制御対象である設備装置の制御応答時間の遅れにつながる。そのため実行性能の観点から、ラダープログラム部品は、制御対象のアプリケーションに応じて、不要な回路を含まないことが望まれる。

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

ＰＬＳＥ手法では、戦略的な再利用部品をつくるため、プログラム部品にあらかじめ予期されている変化点を組み込んでおくことを提唱している。そこで、本発明者らは、その実現手段のひとつとして、プログラム部品のバリアビリティーポイント（変化点）を定義し、あらかじめラダープログラム中に、その一部を変形するためのマクロ記述を組み込み、与えるパラメータセットを変更してマクロ処理を実行することで、一部が変形したプログラム部品を生成する手法を提案した（特願２００５−２８８８５８号）。これにより、マクロ処理を実行して生成された最終的なラダープログラムは、不要なラダー回路は削除され、適用するアプリケーションに必要十分なラダー回路から構成されたものになり、プログラムの規模を可及的に縮小し実行時間性能の向上を図ることができるという作用効果を奏する。

しかしながら、変化点を含むプログラム部品の品質確保は変形部品毎にその変化点をテストする必要がある。そして、テストした結果不具合が見つかるとプログラムの修正をする必要が生じ、その修正がすでにテスト済みで合格した部品に影響を及ぼすこともある。このように、プログラムの修正，テストの実行，テスト結果の管理が煩雑となり、誤操作や勘違いにより思わぬ不具合やテスト漏れを発生させる可能性がある。

この発明は、変化点を含むプログラム部品のテスト作業の管理を確実かつ簡単に行なうことのできるプログラム管理装置を提供することを目的とする。

上記した目的を達成するため、本発明に係るプログラム管理装置は、機器制御プログラムを構成するための汎用性のある複数の資産プログラム部品と、その資産プログラム部品に基づいて生成される特定のアプリケーション用プログラム部品への入力条件および期待出力を時系列に記載したテストシナリオと、を関連づけて記憶するプログラム部品記憶手段と、前記資産プログラム部品の接続関係を示す関連図を表示装置に表示し、処理対象の資産プログラム部品並びに処理内容を選択させる選択手段と、前記資産プログラム部品を編集する編集手段と、前記特定のアプリケーション用プログラム部品がダウンロードされたシミュレータに対し、前記テストシナリオに従って入力条件を与えると共に、そのシミュレータの実行結果と前記期待出力とを比較するテスト手段と、を備える。そして、前記資産プログラム部品は、あらかじめ予期されている変化点が存在する場合に、その変化点をマクロ記述として含むプログラム部品であり、前記マクロ記述を含む資産プログラム部品に対応する前記特定のアプリケーション用プログラム部品は、マクロ処理を実行して生成され、前記関連図上の資産プログラム部品の表示態様を、前記テスト手段による比較結果を反映させるように構成した。

プログラム部品記憶手段は、実施の形態では、プログラム部品データベース７０に対応する。関連図は、実施の形態ではコンポーネント関連図に対応する。処理内容は、実施の形態では編集処理と単体テストに対応する。選択手段は、実施の形態ではコンポーネント関連図エディタ６４に対応する。編集手段は、実施の形態ではコンポーネント・エディタ６５に対応する。テスト手段は、実施の形態では、単体テストツール７１に対応する。

選択手段により、関連図上の資産プログラム部品を選択するとともに、処理内容を選択することで、その選択された処理内容に応じて編集手段あるいはテスト手段を起動することができる。これにより、プログラムの修正後、直感的にその部品をテストできることができる。

上記した目的を達成するため、本発明に係るプログラム管理装置は、機器制御プログラムを構成するための汎用性のある複数の資産プログラム部品と、その資産プログラム部品に基づいて生成される特定のアプリケーション用プログラム部品への入力条件と、当該特定のアプリケーション用プログラブ部品が合格の場合にその入力条件に従って演算実行した場合に出力される期待出力を演算実行順に時系列に記載したテストシナリオと、を関連づけて記憶するプログラム部品記憶手段と、前記資産プログラム部品が動作するために必要な他の資産プログラムとの接続関係を示す関連図を表示装置に表示し、処理対象の資産プログラム部品並びに編集処理かテストかの処理内容を選択させる選択手段と、前記選択手段により処理内容として編集処理が選択された場合に前記資産プログラム部品を編集する編集手段と、前記選択手段により処理内容としてテストが選択された場合に前記特定のアプリケーション用プログラム部品がダウンロードされたシミュレータに対し、前記テストシナリオに従って入力条件を与えると共に、そのシミュレータの実行結果と前記期待出力とを比較するテスト手段と、を備える。そして、前記資産プログラム部品は、プログラムの一部を変形するためのマクロ記述を組み込み、そのマクロ記述は、入力された条件に従って必要なプログラムの要素を特定し、不要なプログラムの要素を削除するものであり、前記マクロ記述を含む資産プログラム部品に対応する前記特定のアプリケーション用プログラム部品は、マクロ処理を実行して生成され、前記関連図上の資産プログラム部品の表示態様を、前記テスト手段による比較結果を反映させるように構成した。

そして、関連図上に表示された資産プログラム部品の表示態様をテスト結果が反映されるようにしたため、各資産プログラム部品のテスト結果を視覚的に確認でき、テストが完了（合格）していない資産プログラムを容易に見つけることができ、チェック漏れなどの管理上のケアレスミスを防ぐことができる。

前記選択手段により選択された資産プログラム部品に、前記関連図で下位側に接続された他の資産プログラム部品である子の資産プログラム部品が存在するか否かを判断し、前記子の資産プログラム部品が存在する場合には、前記資産プログラム部品と前記子の資産プログラム部品とを合成して１つのプログラムを生成するプログラム合成手段を備えるようにすることができる。

この場合に、前記子の資産プログラム部品に対しては、プログラムの内容の表示を許可するが、前記編集手段による編集を禁止するよう設定する禁止手段を備えると良い。禁止手段は、実施の形態では、資産プログラム部品に、読み取り専用属性フラグを設定し、そのフラグのＯＮ／ＯＦＦをすることで実現される。

前記選択手段により選択された資産プログラム部品に、前記関連図で下位側に接続された他の資産プログラム部品である子の資産プログラム部品が存在するか否かを判断し、前記子の資産プログラム部品が存在する場合には、前記資産プログラム部品に対応する前記特定のアプリケーション用プログラム部品と、前記子の資産プログラム部品に対応する前記特定のアプリケーション用プログラム部品とを合成して１つのプログラムを生成するプログラム合成手段を有し、前記シミュレータにダウンロードされ実行される前記特定のアプリケーション用プログラム部品は、前記プログラム合成手段で生成されたプログラムとすることができる。

前記テスト手段による比較結果を反映は、テストシナリオを実行して合格したものと、合格していないものを識別可能にするものとすることかできる。また、合格していないとは、未テストの状態もあれは、テストした結果不合格の場合もある。少なくとも、合格したものと合格していないものを識別できればよいが、合格していないものについては、不合格と未テストをさらに識別可能にするとよい。

前記合格したものの表示態様の資産プログラム部品を前記編集手段で編集処理したか否かを判断し、編集処理された場合には表示態様を合格していない状態に変更する手段を備えるとよい。係る手段は、実施の形態では、コンポーネント関連図エディタで実現されている。合格した資産プログラム部品に対して編集処理を実行すると、プログラムの内容が変更されるため、前に行なった合格の意味がなくなる。そこで、この発明では、自動的に表示態様を合格していない養生に変更することで、再度テストをする必要があることを見落とすことなく、編集後のプログラム部品についてのテストを確実に行なわせることができる。

資産プログラム部品について準備したテストシナリオすべてが合格となった場合に、その資産プログラム部品を合格したものとすることかできる。全てのテストシナリオが合格したと言うことは、そのプログラムは問題がない完成されたものであると言える。なお、本発明のテストの合格は、必ずしも準備したテストシナリオの全てが合格した場合に限ることはなく、たとえば、テストシナリオをユーザに選択させるような場合、選択され実行したテストシナリオについて合格した（不合格がでない）場合にテストが合格したと判定するようにすることもできる。なお、係る場合には、全てのテストシナリオが合格したものと、選択したテストシナリオについては全て合格したものについての表示形態を異ならせるとなお良い（異ならせなくても良いが）。

前記資産プログラム部品は、ラダープログラムにより構成され、前記マクロ記述は、入力された条件に従って特定のアプリケーションに合わせて当該ラダープログラムの接点や回路を組み替え、当該特定のアプリケーションに不要な回路を削除することを目的としたマクロ処理言語でマクロ記述であるとすることができる。

本発明では、変化点を含むプログラム部品のテスト作業の管理を確実かつ簡単に行なうことができる。

本発明の実施の形態を説明するに先立ち、前提となる、あらかじめ予期する変化点をマクロ記述としてラダープログラムに組み込み、アプリケーションに応じて与えるパラメータセットを変更するとともにマクロ処理を実行し、その特定のアプリケーション用プログラム部品を生成する技術について説明する。

まず、再利用範囲を共通性の多い類似のアプリケーション群（プロダクトライン）に限定する。つまり、特定のプロダクトライン（製品系列）の範囲内だけでプログラム部品の再利用を考えるようにした。一例を示すと、携帯電話、ＣＤプレーヤ、半導体製造装置など一つの製品ドメインに限定し、再利用範囲は、その限定された１つの製品の品揃えやバージョンアップを想定した範囲とした。これは、従来のユーザプログラムの開発においては、例えば、ある製品或いはその製品を製造するための製造ラインの動作・制御を司るラダープログラムを開発する場合、その製品にのみ着目し、その製品のための製造ライン用の専用のラダープログラムを作成していた。一方、複数のアプリケーションにおいて再利用できる汎用性のあるプログラム部品を作成するに際し、ＰＬＳＥ手法による戦略的な再利用部品をつくるため部品にあらかじめ予期されている変化点を組み込むことが行なわれる。この場合に、想定する複数のアプリケーションの範囲をいたずらに広げるのではなく、上述したように、特定のプロダクトライン（製品系列）の範囲内だけでプログラム部品の再利用を考えることで、より適切な部品を作成することができる。

具体的には、対象となる製品のアプリケーション群（プロダクトライン）において共通性と差異性とを分析し、共通部分と差異部分とが一つのプログラム部品内に混在しないようにプログラム部品を設計する。図１は、製品の共通性と差異性とを分けた一例を説明する図である。同図（ａ）には、上述した従来の開発対象の製品Ａ（アプリケーション）のみを考慮して分析し、その製品用のプログラムを作成した例が示されている。ここでは、便宜上、４つのモジュール（ファンクションブロック）によりラダープログラムが構築されているとする。この状態において、その製品と同一シリーズ（バリエーション：品揃え）の製品が存在したり、その製品を基礎としたバージョンアップが行なわれたりすることがある。係る場合、そのバリエーションの製品Ａ１，Ａ２，……やバージョンアップされた製品Ａ′，Ａ″，……は、元となる製品Ａと共通することが多く、その製品Ａ１，Ａ′等のためのラダープログラムは、元となる製品Ａのラダープログラムの一部を編集・変更することで製造することができる場合が多々ある。ただし、通常では、製品Ａ用のラダープログラムを開発する場合には、製品Ａのみを考慮して作成するため、バージョンアップした次の製品Ａ′等や製品Ａのバリエーションの製品Ａ１等のためのラダープログラムを開発する場合、例えば、同図の変更箇所Ｘにて示されるように変更箇所が多岐にわたってしまう。

そのため、次の製品を作成するためにどこを変更すればよいのか分かりづらくなってしまう。また、それらの変更箇所Ｘは、モジュールＡ〜Ｄに組み込まれており、しかも、複数のモジュールにまたがって存在するものもあり、変更箇所のみを入れ替えて対応することが困難である。そのため、共通部分が多く、部分的な変更によって対応できるような場合においても、実際には、再度その製品に合わせたラダープログラムを作成する必要が生じてしまうことがある。

そこで、同図（ｂ）に示されるように、対象となる製品のみではなく、予め製品の品揃えに加えて将来のバージョンアップも含めて、共通性と差異性とを分析することによって、同図（ｃ）に示されるように、対象製品のバリエーションにおいて差異部分のみをまとめたモジュールＥを構成することが可能となる。そして、このように共通部分と差異部分とを明確に分けて部品設計を行うことにより、異なる製品バリエーション等を作成する際にはその差異部分に対応する別のモジュールＦと置き換えることにより容易に当該製品のバリエーションを作成することが可能となる。

図２には、一つのアプリケーションとしての検査装置が示されている。同図において点線で囲まれたように、検査装置はその機能や処理内容によって大まかに６つの部分に分けられる。

すなわち、この検査装置は、供給部１と、ロードアーム３と、インデックステーブル４と、検査ヘッド５と、アンロードアーム６と、排出部７と、を備えている。供給部１は、検査対象のワークＷを貯留するホッパー１ａと、そのホッパー１ａの下方から１つずつ搬出されるワークＷを上昇移動させるエレベータ１ｂと、そのエレベータ１ｂで上昇移動されたワークＷを搬出する下方傾斜状のシューター１ｃとを備える。ワークＷは、シューター１ｃを滑り降りるように移動し、供給部１の先端に至る。この供給部１は、エレベータ１ｂを備えたエレベータ供給装置となっている。

ロードアーム３は、供給部１の先端に位置しているワークＷを掴むと共に旋回し、インデックステーブル４上の所定位置に置くロボットである。つまり、ロボットアーム３は、インデックステーブル４へのワーク搬入を行なうロボット輸送の一形態である。他には、３次元空間上を移動可能なロボットアームなど、各種の代替え品がある。

このインデックステーブル４が回転動作を行うことにより、ワークＷは検査位置へと移動し、検査ヘッド５が所定位置に降下し検査を行う。インデックステーブル４は更に回転し、ワークWを取り出し位置へと移動する。つまり、インデックステーブル４は、９０度ごとに回転・停止するように制御される。これにより、ロードアーム３により供給されワークＷは、９０度回転して検査位置に移動し、その後さらに９０度移動して排出位置に移動することになる。換言すると、インデックステーブル４は、４つの位置で位置決めがされるように動作する。

検査位置や排出位置などの所望に位置にワークを移動させる手段としては、インデックステーブル４に限ることはなく、たとえば、ベルトコンベアその他各種の手段がある。そして、ベルトコンベアを用いた場合には、ワークを検出するためのセンサを設け、そのセンサ位置にワークが来たときにベルトコンベアを停止することで位置決めできる。よって、センサの設置位置を調整することで任意の位置で位置決めをすることができる。

検査装置５は、たとえばカラーセンサなどを用いることで、形状と色情報を加味して良否判定を行なうことができる。これにより、より高精度な判定を行なうことができる。また、これに限ることはなく、形状を認識する画像センサを用い、簡易で短時間での良否判定を行なうようにすることもできる。

排出位置に移動したワークＷは、アンロードアーム１６によって掴まれてインデックステーブル１４から取り出され、排出部１７に送られる。そして、排出部１７は、検査結果に従い良品／不良品とを分別して排出する。

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

これらの検査装置Ａ並びに検査装置Ｂを特性によって共通部分と差異部分とに分けたコンポーネント関連図が、図４〜図６に示されている。「コンポーネント関連図」は、ユーザが選択する特性とは異なり、何をどのようにして作るかという視点で作成される部品図であり、ソフトウェア設計のクラス図に相当する。そして、分析結果を参考に、共通特性と、差異特性が一つの部品内に混在しないように部品を設計する。

図４には、コンポーネントの全体図が示されている。同図にて示されるように、検査装置２０は、ワーク搬入部２１、位置決め部２２、検査部２３、及びワーク搬出部２４に区分されている。そして、ワーク搬入部２１は、さらに供給部２１ａとロードアーム２１ｂとが備えられている。そして、位置決め部２２にはインデックステーブル２２ａとベルトコンベア２２ｂが、検査部２３には検査方法２５が、そしてワーク搬出部２４にはアンロ―ドアーム２４ａと搬出部２４ｂとがそれぞれ備えられている。実際の装置（アプリケーション）における６つの部分との関係でいうと、供給部１と、ロードアーム３とでワーク搬入部２１が構成され、アンロードアーム６と、排出部７とでワーク搬出部２４が構成される。

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

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

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

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

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

図９及び図１０に、特性モデルの例が示されている。特性モデルとは、製品ラインアップを特性によって表現したモデルである。ここで「特性」は、機能、性能、デザインなどユーザが製品を選択する基準になる概念である。また、特性モデルは、装置を共通性と差異性に着目して分析した特性のモデルである。

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

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

また、この特性モデルと、図４に示したコンポーネント関連図とを対比すると、特性モデル図の供給３１とワーク搬入３２とが、コンポーネント関連図のワーク搬入部２１に対応し、特性モデル図のワーク搬出３５と排出３６とが、コンポーネント関連図のワーク搬出部２４に対応する。このように、各図を作成する際の視点が異なることから、まとめ方が一部相違する。

図１１は、本発明に係るプログラム作成支援装置１０の一実施の形態が示されている。同図に示すように、この実施の形態においては、ドメイン分析支援ツール５０と、プログラム部品管理ツール６０と、プログラム部品データベース７０と、単体テストツール７１と、ＰＬＣシミュレータ７２とを備えている。なお、ドメイン分析支援ツール５０は、なくても良い。

ドメイン分析支援ツール５０内の特性モデルエディタ５１は、開発対象ドメインにおける製品ラインアップの共通性と差異性とを分析し、製品ラインアップを「特性」によって表現した分析モデルである特性モデル（製品の特性情報）５２を作成するものである。つまり、図９に示す特性モデルを作成するエディタである。この特性モデルを作成することによって、共通性と差異性（オプションの有無や、選択（代替え）可能な部品の有無等）が分析でき、図において表現できる。係る特性モデルが、プログラム部品管理ツール６０に与えられる。

プログラム部品管理ツール６０は、プロダクト・パラメータ・マネージャ６１と、コンポーネント・マネージャ６２と、マクロ・プロセッサ６３と、コンポーネント関連図エディタ６４と、コンポーネント・エディタ６５と、ワークメモリ６６とを備えている。

プロダクト・パラメータ・マネージャ６１は、ある設備装置や製品のアプリケーションを構築するのに必要なプログラム部品群と、そこに記述されるマクロへの入力パラメータセット（「プロダクト・パラメータ」と呼ぶ）６７を管理するものである。本実施の形態では、ドメイン分析支援ツール５０が作成した特性モデルと製品の特性情報を元に、プロダクト・パラメータを作成する機能も持っている。

つまり、差異性に基づいて変更可能な各種の組み合わせからなるアプリケーションを実現するために記述されるマクロへの入力パラメータセット（プロダクト・パラメータ）６７を作成する。上述した例では、検査装置Ａを実現するためのマクロの入力パラメータや、検査装置Ｂを実現するためのマクロへの入力パラメータを作成する。もちろん、選択・生成可能なアプリケーションは、検査装置Ａ，Ｂに限られるものではなく、他の部品の組み合わせからなる検査装置も生成可能なため、それらの検査装置を実現するためのマクロへの入力パラメータも作成する。

このマクロへの入力パラメータセット６７の作成であるが、製品の特性情報を認識しその差異性に基づいて選択可能な組み合わせを全て自動的に抽出することで、自動的に生成するようにすることができる。ただし、係る自動的に生成する方法によると、現実的でないアプリケーションも構築されるため、例えば、図９に示す特性モデル図を表示装置に表示すると共に、図示省略する入力装置をユーザが操作して、差異性の部分（選択可能な部分）について指定する（図１０中黒丸印）。プロダクト・パラメータ・マネージャ６１は、係る指定された組み合わせに基づいてマクロへの入力パラメータを生成する。これにより、ユーザが、入力装置を操作してアプリケーションを複数設定することで、マクロへの入力パラメータセット（プロダクト・パラメータ）６７が生成される。

プログラム部品データベース７０は、図１２に示すように、製品の特性情報と、資産プログラム情報とが格納されている。製品の特性情報は、ドメイン分析支援ツール５０で作成された特性モデルと、特性の組み合わせ（「マクロへの入力パラメータ」に対応）を規定する特性選択データ（マクロへの入力パラメータである）がある。資産プログラム部品情報は、各部品を構成するコンポーネントごとに登録される。これら各コンポーネントは、図４中符号２０から２５で示す個々のコンポーネントに対応し、「ａ」，「ｂ」などの付記号が付された符号は、変更箇所及び変更内容を示すためのマクロとして、上位のコンポーネント中に記述される。

各コンポーネントは、コンポーネントヘッダと、そのコンポーネントヘッダに関連付けられた資産プログラム部品並びにテストシナリオから構成される。資産プログラム部品は、そのコンポーネントを実現するために基本となるラダープログラムである。この資産プログラム部品を元にして、一部を変更した新プログラム部品を作成する。資産プログラム部品のラダープログラムを変化したいところが存在する場合には、マクロ記述が組み込まれる。そして、１つのコンポーネントに対し、１つのファンクションブロックが構築される。テストシナリオは、プログラム部品への入力条件、および期待出力を時系列に記載したものである。作成されたユーザプログラムの検証（単体テスト）時に使用する。

コンポーネントヘッダは、図１３に示すようなデータ構造からなる。図から明らかなように、上位から順に、コンポーネント名，実現している特性のリスト，インタフェース定義，関連コンポーネントリスト，プログラム種別，プログラム部品ファイル，テストシナリオリスト並びにコメントから構築される。

「コンポーネント名」には、コンポーネント関連図エディタで表示されるそのコンポーネントの名称が記述される。このコンポーネント名は、対応するコンポーネントの１番上の欄に標記される。

「実現している特性のリスト」には、コンポーネントにより実現／実装されている特性のリストが記述される。特性の名前でもあり、コンポーネント関連図エディタで表示された場合に、そのコンポーネントの２番目の欄に標記される。また、特性モデル図（図９等）において、各それぞれの特性として標記される。

インタフェース定義と、関連コンポーネントリストは、外部との関連を定義する領域である。「インタフェース定義」には、他のコンポーネントが利用可能な入出力定義を記述する。具体的には、変数名およびデータ型、入出力の区別などが記述される。「関連コンポーネントリスト」には、そのコンポーネントが動作するために必要なコンポーネントを記載したリストが記述される。たとえば、図４において検査装置２０のコンポーネントには、ワーク搬入部２１，位置決め部２２，検査部２３，ワーク搬出部２４の各コンポーネントを特定する情報がリストとして記述される。これにより、各コンポーネントの接続関係がわかり、コンポーネント関連図も再現できる。

プログラム種別と、プログラム部品ファイルは、コンポーネント本体であり、「プログラム種別」には、プログラム部品が実装されている言語、または実行できるＰＬＣ機種の種別が記述され、「プログラム部品ファイル」には、上記プログラム種別により、実装されたプログラムのソースコードが記述される。

テストシナリオリストは、制御対象情報であり、上記プログラム部品への入力条件、および期待出力を時系列に記載したシナリオファイルを複数リストにしたものが記述される。このテストシナリオリストは、図１３（ｂ）に示すように、シナリオＩＤと、テスト結果と、テストシナリオファイル名と、適合特性選択データ名とを関連付けたテーブルとなっている。ここで、シナリオＩＤは、テストシナリオをユニークに特定するための認識番号であり、テスト結果の欄は、そのテストシナリオに従って実行した結果（ＯＫ／ＮＧ）並びに未テスト状態（−）が格納される。テキストシナリオファイル名は、各テキストシナリオのファイル名が格納される。適合特性選択データ名は、対応するテキストシナリオを用いてテストを行なえる特性選択データのファイル名を格納する。すなわち、異なる特性選択データであっても、プログラム部品への入力条件、およびそれに対する期待出力の時系列データが等しいことがある。特に、アプリケーション群を構成する各アプリケーションは、バージョンアップであったり、製品の品揃えであり共通する部分も多数あるため、異なる特性選択データであっても同一のテストシナリオを用いることができることがある。また、１つの特性選択データに対し、複数のテストシナリオが用意されることももちろんある。

なお、「コメント」には、コンポーネントの内容を把握するためのコメントが記述される。このように、コンポーネントヘッダにより、そのコンポーネントに格納された資産プログラム部品並びにテストシナリオとのリンクが張られるとともに、他のコンポーネントとの関連づけが行なわれる。

単体テストツール７１は、ラダー部品に与える仮想入力と期待出力のペアをテストケースとして設定できる。設定した「仮想入力」をＰＬＣシミュレータ７２に与え、シミュレーションを実行し、その出力と期待出力を比較して、テストケースのＯＫ／ＮＧを判定する機能を持つ。その判定結果は、コンポーネント関連図エディタ６４，コンポーネント・マネージャ６２経由でプログラム部品データベース７０に格納される。

ＰＬＣシミュレータ７２はプログラマブルコントローラ（ＰＬＣ）をパソコン上で模擬実行するエミュレータである。ダウンロードされたラダープログラムを、単体テストツール７１から与えられる仮想的なＩ／Ｏ情報を元に実行する。

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

マクロ・プロセッサ６３は、マクロ記述とプロダクト・パラメータに従い、ラダープログラムの変形を実行し、特定アプリケーション用のプログラム部品を生成する機能を有する。すなわち、アプリケーションの要求仕様(特性）と差異部分の関連づけを行なうもので、図１４に示すように、必要な資産プログラム部品を読み出し、資産プログラム部品中にマクロ記述が存在するものに対しては、マクロへの入力パラメータである特性選択データに基づいてマクロ処理を実行し、ラダープログラム中の不要な回路を削除し、必要十分なラダー回路で記述された特定のアプリケーション用プログラム部品が生成される。マクロ処理は、あらかじめマクロ記述で定義した変化点を特性選択データを入力パラメータとして変形処理するもので、係る処理をマクロ・プロセッサ６３が実行する。

なお、図１４に示すように、資産プログラム部品の中には、実際のプログラムと、マクロに加え、その子コンポーネントとが編集禁止状態にあるか否かを規定する「読み取り専用属性フラグ」と、テストが完了して合格した資産プログラム部品であるかを特定するための「テスト済みフラグ」がある。これらのフラグについての利用は、後述する。

コンポーネント関連図エディタ６４は、コンポーネント間の関連を視覚的に表示した図であるコンポーネント関連図（図４参照）を表示装置のエディタ画面上に表示すると共に、そのコンポーネント関連図上で編集・テスト対象コンポーネントを特定し、コンポーネントの編集手段たるコンポーネント・エディタ６５や、テスト手段たる単体テストツール７１を起動する。コンポーネント関連図は、例えばプログラムデータベース７０に格納されたコンポーネントヘッダの関連コンポーネントリストなどを参照することで各コンポーネントの関係がわかるので、コンポーネント関連図を構築できる。換言すると、コンポーネント関連図が構築できるような情報を関連コンポーネントリストに登録する。また、特性モデルと同様に、コンポーネント関連図もプログラム部品データベース７０に登録しておき、それを読み出すようにしても良い。

また起動処理は、具体的には、図１５に示すように、表示装置に表示されたコンポーネント関連図エディタ３４のエディタ画面Ｗに表示されたコンポーネント関連図の中から、処理対象のコンポーネントを選択する。係る選択は、たとえばユーザがポインティングデバイスを操作し、エディタ画面Ｗ上のポインタを移動し、目的のコンポーネント（図では「ワーク搬入部」）の上に位置させた後、クリックする。すると、コンポーネント関連図エディタ６４は、そのクリックされた位置の座標位置からどのコンポーネントが指定・選択されたかを判断し、選択されたことを示す標記（図の例では、頂点並びに中間点に○を表示）をするとともに、起動する手段（編集／単体テスト）を選択する入力メニューリストＭＬを表示する。そして、入力メニューリストＭＬ中の「編集」が選択された場合には、編集手段たるコンポーネント・エディタ６５を起動し、入力メニューリストＭＬ中の「単体テスト」が選択された場合には、テスト手段たる単体テストツール７１を起動する。これらの処理もコンポーネント関連図エディタ６４が行なう。

さらにコンポーネント関連図エディタ６４は、指定されたコンポーネントの資産プログラム部品（マクロ記述済み）６８を取得すると共に、そのコンポーネントを元とし（以下、親のコンポーネントと表現）、その元から派生したコンポーネント（以下、子のコンポーネントと表現）が有るか否かを判断する。つまり、図１５のコンポーネント関連図で下位側に接続されたコンポーネント（子）があるか否かを判断し、存在する場合には、その子のコンポーネントに対応する資産プログラム部品６８も読み出し、読み出した各資産プログラム部品を合成し、合成したプログラムをワークメモリ６６に格納する。図１５に示す例では、「ワーク搬入部」が選択されたため、その下位に繋がる「供給部」と「ロードアーム」の各コンポーネントが子のコンポーネントとなり、それぞれの資産プログラム部品も読み出され、合成される。ただし、選択されたのはあくまでも親のコンポーネントである「ワーク搬入部」であるため、本実施の形態では、編集対象は係る親のコンポーネント（ワーク搬入部）に対する資産プログラム部品の部分のみとした。換言すると、子のコンポーネント（供給部，ロードアーム）に対応する資産プログラム部品については、プログラムの中身（ラダー回路）を見ることはできるものの、編集処理はできないようにしている。もちろん、本発明は係る機能を設けるものに限られるものではなく、このコンポーネントに対しても編集できるようにしても良い。

このとき、コンポーネント関連図エディタ６４は、ワークメモリ６６に格納した際の日時情報を記憶保持する機能も持つ。また、起動されたコンポーネント・エディタ６５は、このワークメモリ６６に格納されたプログラム（合成済み）を読み出して編集処理をする。そして、コンポーネント・エディタ６５は、編集処理が終了したならば、編集後のプログラムをワークメモリ６６に保存する。この保存された編集後のプログラムは、コンポーネント関連図エディタ６４で読み出され、編集対象の資産プログラム部品（編集後）をコンポーネント・マネージャ６２を介してプログラム部品データベース７０の対応するコンポーネントのファイルに格納し、更新処理をする。コンポーネント関連図エディタ６４は、コンポーネント・エディタ６５で編集処理が行なわれなかった場合には、上述したプログラム部品データベース７０への更新処理を行なわないようにしている。編集処理がされたか否かは、コンポーネント関連図エディタ６４がワークメモリ６６に保存した際に記憶した日時情報と、現在のプログラムについての保存時の日時情報を比較し、一致すれば編集処理がされておらず、一致しなければ編集処理がされたと判断するようにしている。もちろん、編集処理の有無の判断は、これに限ることはなく、サムチェックや、編集前のプログラム全体を記憶しておきそれと比較するなどの他、各種の方式を採ることができる。

コンポーネント・エディタ６５は、コンポーネントの編集等を行なうものであり、本実施の形態ではマクロ記述を含んだラダープログラム部品の編集を行うものである。つまり、コンポーネント・エディタ６５の一形態として、ラダーエディタ（ラダープログラミングツール）がある。この実施の形態においては、マクロの編集機能と、ラダープログラムの編集機能とを併せ持っている。図１６は、起動されたコンポーネント・エディタ（ラダーエディタ）６５の操作画面を示している。

次に、編集機能を説明する。本実施の形態では、コンポーネント関連図エディタ６４とコンポーネント・エディタ６５との協働により、編集機能を実現している。具体的には、図１７，図１８に示すフローチャートを実行するものである。

まず、コンポーネント関連図エディタ６４は、ポインティングデバイスを操作して指定された（ポインタでクリックされた）コンポーネントを認識し、そのコンポーネントのコンポーネントヘッダをコンポーネント・マネージャ６２を介してプログラム部品データベース７０より取得する。

該当コンポーネントの「資産プログラム部品」ファイルが存在するか否かを判断し（Ｓ２）、存在する場合には、該当コンポーネント、およびそれに関連する子のコンポーネントのリストを作成する（Ｓ３）。このリストの作成は、上述したように、コンポーネントヘッダの関連コンポーネントリストに基づいて作成できる。

ついで、上記リストに従い、プログラム部品データベース７０より、リストに載った個々の資産プログラム部品のファイルを取り出すとともに（Ｓ４）、その取り出した個々の「資産プログラム部品」のファイルを合成し、コンポーネント・エディタ６５のラダープログラミングツールが認識できる１つのプログラムファイルとする。（Ｓ５）。

ユーザが指定したコンポーネント以外、つまり、子のコンポーネントに対応するプログラム部分（ファンクションブロック）は、編集ができないように読み取り専用属性に変更する（Ｓ６）。つまり、図１４に示すように、資産プログラム部品には、プログラム（マクロ付）とともに、読み取り専用属性フラグと、テスト済みフラグが設定されている。そこで、読み取り専用属性フラグをＯＮにする。

そして、該当プログラムファイルをコンポーネント・エディタ６５に渡す。具体的には、処理ステップＳ５で作成した１つのプログラムファイル（Ｓ６の処理で設定した読み取り専用属性フラグＯＮ情報とともに）をワークメモリ６６に保存する。このとき、保存日時を記憶する。そして、コンポーネント・エディタ６５を起動する。また、処理ステップＳ２の分岐判断がＮｏ、つまり、該当コンポーネントの「資産プログラム部品」ファイルが存在しない場合には、「資産プログラム部品」のファイルを新規作成する（Ｓ８）。上述した処理ステップＳ１からＳ８までの各処理は、コンポーネント関連図エディタ６４が実行する。

次に、コンポーネント・エディタ６５は、ワークメモリ６６に格納された該当プログラムファイルをロードし、該当「資産プログラム部品」の内容（ファンクションブロックのラダープログラム）を表示装置のエディタ画面に表示する（図１６参照）。ユーザは、コンポーネント・エディタ６５であるラダープログラミングツール（ラダーエディタ）を操作し、表示されたラダー回路に対する編集処理を行ない、その後ユーザによる編集処理を終了する（Ｓ１０，Ｓ１１）。すると、編集後のラダープログラムについて、文法が正しいか否かのチェックを行ない（Ｓ１２）、文法が正しくなるまで編集処理を行なわせる。上述した処理ステップＳ１０からＳ１２までの各処理は、コンポーネント・エディタ６５が実行する。

コンポーネント・エディタ６５が終了したならば、プログラム変更の有無を判断する（Ｓ１３）。本実施の形態では、現在のワークメモリ６６に記憶されているプログラムファイルの保存日時と、処理ステップＳ７で記憶保持した日時情報とを比較し、一致している場合には、プログラム変更がなく、一致していない場合には、プログラム変更があったと判断するようにした。

プログラム変更があった場合には、そのコンポーネントのテスト済みフラグをＯＦＦにし（Ｓ１４）、該当プログラムを「資産プログラム部品」としてプログラム部品データベース７０に保存する（Ｓ１５）。つまり、後述する単体テストにより合格し、テスト済みフラグがＯＮになっている場合でも、編集処理によりプログラムの内容が変更された場合には、そのテスト済みフラグは編集前のプログラムについてのものであるため、フラグをＯＦＦにし、不合格状態（ここでは未テスト状態）に戻す。また、これに伴い、プログラム部品データベース７０に格納されるテストシナリオのテスト結果の欄は「−」にする。なお、処理ステップＳ１３の分岐判断がＮｏ、つまり、プログラム変更がなかった場合には、そのまま処理を終了する。上述した処理ステップＳ１３からＳ１５までの各処理は、コンポーネント関連図エディタ６４が実行する。

図１９は、編集禁止手段の機能を示すフローチャートである。図１８の処理ステップＳ１０のファンクションブロックの編集処理を行なうべく、ユーザがその編集しようとするファンクションブロックを指定した場合、その指定されたファンクションブロックを認識し（Ｓ２１）、該当ファンクションのラダー回路を表示する（Ｓ２２）。そして、その該当ファンクションブロックに関連する読み取り専用属性フラグがＯＮか否かを判断し（Ｓ２３）、読み取り専用属性がＯＮの場合には、編集モードを解除する（Ｓ２６）。これにより、ラダー回路を見ることはできるが、編集処理は禁止される。また、読み取り専用属性がＯＦＦの場合には、そのまま編集モードに移行し（Ｓ２４）、ユーザからの編集命令を待ち、入力された指示に従ってラダー回路の編集（変更）を行なう（Ｓ２５）。この図１９に示すフローチャートに示された機能は、コンポーネント・エディタ６５であるラダープログラミングツールが行なう。

次に、単体テスト機能について説明する。図２０は、一部のコンポーネントに対して単体テストを実行した後のコンポーネント関連図エディタ６３により表示されるコンポーネント関連図を示している。図２０に示すように、単体テスト機能を実行し、テスト済み（合格）のコンポーネントにはテスト済みマークＭを付けたり、表示する色を変えたりしている（図では、両方行なっている）。このように表示形態を変えることで、「単体テストを実行していない」か或いは「単体テストを実行したがＮＧ」のコンポーネントと、単体テストが完了（ＯＫ）」して完成されたコンポーネントとを、一目で識別することができる。

そして、係る単体テスト機能は、本実施の形態では、コンポーネント関連図エディタ６４と単体テストツール７１と、ＰＬＣシミュレータ７２との協働により実現している。具体的には、図２１に示すフローチャートを実行するものである。

ユーザがポインティングデバイスを操作してコンポーネントを指定すると共に、入力メニューリストＭＬ中の「単体テスト」が選択された場合、コンポーネント関連図エディタ６４は、指定されたコンポーネントを認識し、そのコンポーネントのコンポーネントヘッダをコンポーネント・マネージャ６２を介してプログラム部品データベース７０より取得する（Ｓ３１）。次いで、該当コンポーネントの「資産プログラム部品」ファイルが存在するか否かを判断し（Ｓ３２）、存在しない場合には、エラー表示をして（Ｓ３７），処理を終了する。

一方、存在する場合には、特性選択データを（ユーザに選択要求し）、プログラム部品データベース７０より取り出す（Ｓ３３）。すなわち、本実施の形態では、単体テストをする特定アプリケーション用プログラム部品を生成するためのマクロへの入力パラメータ（特性選択データ）をマニュアルで指定するようにしている。これは、例えば、上述した編集処理機能により編集したプログラムが正常に動作するか否かをチェックしたいことが多々ある。特に、マクロに対応する一部のラダー回路を編集した場合、その編集したラダー回路に関連する特性選択データを優先的にテストしたいということがある。そこで、係る要求を満たすために、ユーザが単体テストを実行したいコンポーネントを指定させるとともに、特性選択データを指定させるようにした。もちろん、プログラム部品データベース７０に格納された特性選択データを順次抽出するように自動実行するようにしても良い。

次いで、ユーザに指定された特性選択データに対応する「特定アプリケーション用プログラム部品」を生成する（Ｓ３４）。この処理ステップ３４の具体的な処理手順は、図２２に示すフローチャートを実行する。すなわち、まず該当コンポーネント、およびそれに関連する子のコンポーネントのリストを作成する（Ｓ４１）。係る処理は、編集処理における処理ステップＳ３と同様である。そして、上記リストに従い、「プログラム部品データベース７０」より、個々の「資産プログラム部品」のファイルを取り出す（Ｓ４２）。係る処理は、編集処理における処理ステップＳ４と同様である。

その後、指定された該当特性選択データ（マクロへの入力パラメータ）を用いてマクロ・プロセッサ６３にてマクロ処理を行い、「資産プログラム部品」を「特定アプリケーション用プログラム部品」に変換する（Ｓ４３）。ここで、該当特性選択データは、指定されたコンポーネントはもちろんのこと、子のコンポーネントが存在する場合には、その子のコンポーネントについての特性選択データも含まれる。換言すると、Ｓ３３におけるユーザの選択に伴い取り出された特性選択データは、子のコンポーネントについても指定され、取り出される。そして、個々の「特定アプリケーション用プログラム部品７３」のファイルを合成し、１つのプログラムファイルとする（Ｓ４４）。

このようにして特定アプリケーション用プログラム部品が生成される。つまり、子のコンポーネントが存在しない場合には、特定アプリケーション用プログラム部品は元々指定された１つのコンポーネントから生成された１つの特定のアプリケーション用プログラム部品からなるプログラムファイルで構成されるが、子のコンポーネントが存在する場合には、各コンポーネントに基づく特定アプリケーション用プログラム部品を合成し、１つのプログラムファイルを生成する。

次に、コンポーネント関連図エディタ６４は、コンポーネント・マネージャ６２を介して、処理ステップ３４を実行して生成された「特定アプリケーション用プログラム部品」に対応したテストシナリオを、プログラム部品データベース７０から取り出す（Ｓ３５）。この処理ステップ３５の具体的な処理手順は、図２３に示すフローチャートを実行する。すなわち、まず、コンポーネント関連図エディタ６４は、コンポーネント・マネージャ６２を介してプログラム部品データベース７０に格納された該当コンポーネントヘッダより、テストシナリオリストを取得する。つまり、子のコンポーネントが存在する場合には、その子のコンポーネントに対するテストシナリオも取得する。そして、取得したテストシナリオリストから、該当特性選択データと適合するテストシナリオを抽出する（Ｓ５２）。すなわち、図１３（ｂ）に示すように、コンポーネントヘッダのテストシナリオリスト名の欄には、適合特性選択データ名が記述されているため、指定された特性選択データと一致するテストシナリオファイル名をすべて抽出し、取得することができる。

コンポーネント関連図エディタ６４は、抽出した「指定された特性選択データと一致するテストシナリオファイル名」を候補テストシナリオとして表示画面に表示し、ユーザに対して今回実行するテストシナリオの選択を促す（Ｓ５３）。そして、ユーザが選択したならば、その選択されたテストシナリオ名に対応するテストシナリオのファイルを取得する（Ｓ５４）。

コンポーネント関連図エディタ６４は、上記の処理ステップＳ３４，Ｓ３５を実行して取得した該当するプログラムファイルとテストシナリオを単体ツールに渡す（Ｓ３６）。そして、単体ツールは、取得したプログラムファイルとテストシナリオに基づいてテストを実行する（Ｓ３８）。係るテストの具体的な処理手順は、図２４に示すフローチャートを実行する。すなわち、まず、単体テストツール７１は、該当プログラムファイルをＰＬＣシミュレータ７２にダウンロードし（Ｓ６１）、ＰＬＣシミュレータ７２の実行を開始する（Ｓ６２）。次いで、単体テストツール７１は、テストシナリオを順番に実行する（Ｓ６３）。シナリオが終了したか否かを判断し（Ｓ６４）、終了していない場合には、シナリオに従い入力を変更する（Ｓ６５）。この入力の変更に伴い、ＰＬＣシミュレータ７２は、演算実行して出力をするので、単体ツール７１は、その出力を記録し、シナリオの想定結果と比較する（Ｓ６６）。そして、比較した結果、出力が想定内か否か、つまり、想定結果と一致するか否かを判断し（Ｓ６７）、想定内の場合には、処理ステップＳ６３に戻り、次のシナリオの実行をする。

処理ステップ６７の分岐判断でＮｏ、つまり、ＰＬＣシミュレータ７２が求めた出力と、想定結果とが一致しなかった場合には、このテストシナリオについてのテスト結果をＮＧとする（Ｓ６８）。また、処理ステップ６４の分岐判断でＹｅｓとなった場合には、シナリオを最後まで実行して全ての出力の結果が想定結果と一致したことを意味するので、このテストシナリオについてのテスト結果をＯＫとする（Ｓ６９）。

このようにして指定された特性選択データに基づく特定アプリケーション用プログラム部品についての、選択されたテストシナリオを用いた単体テストツールでのテストが終了すると、テスト結果をテストシナリオリスト内の該当テストシナリオの結果に反映する（Ｓ３９）。すなわち、単体テストツール７１は、コンポーネント関連図エディタ６４から渡された該当プログラムファイルとテストシナリオに基づくテストが終了したならば、そのテスト結果をコンポーネント関連図エディタ６４に渡すため、コンポーネント関連図エディタ６４は、受け取ったテスト結果（ＯＫ／ＮＧ）を、該当するコンポーネントヘッダのテストシナリオリスト名のテスト結果の欄に格納する。

コンポーネント関連図エディタ６４は、全てのテストシナリオのテスト結果がＯＫのコンポーネントには、図２０に示すようにテスト済みマークＭを付けたり、色を変える（Ｓ４０）。これにより、コンポーネント関連図を見るだけで、テストが完了（全てのテストシナリオのテスト結果がＯＫ：合格）していないコンポーネントを一目で見つけることができる。よって、使用者は、編集処理或いは単体テストをすべきコンポーネントを見つけ、必要な処理をスムーズに実行できる。なお、テストに合格したコンポーネントは、本来プログラムが完成しており、修正する必要はないが、編集機能により編集をすることはできる。係る場合には、図１８の処理ステップＳ１４の実行により、テスト済みフラグがＯＦＦとなるため、全てのテストシナリオのテスト結果がＯＫの条件を満たさなくなるので、コンポーネント関連図エディタ６４は、テスト済みマークＭを消去したり、色を元の状態に戻す処理を行なうことになる。

これにより、たとえ一度単体テストに合格したコンポーネントであっても、その後に編集処理をした場合は、その編集によって書き換えられたラダー回路が正常に動作する保証がないため、一旦不合格状態に戻すことになる。よって、ユーザは再度単体テストを実行し、編集後のコンポーネントもテストが合格するか否かの判断を行なうことができる。

なお、上述した実施の形態では、合格したコンポーネントに合格したことがわかる表示形態（マーク付与や色替え）とし、合格していないも（不合格と未テスト）は基本の表示形態のままとしたが、合格していないものについては、不合格と未テストをさらに識別可能に異なる表示形態をとるようにしても良い。

合格した特定アプリケーション用プログラム部品は、特定のＰＬＣに格納されて、そのＰＬＣは特定アプリケーション用プログラム部品（ラダープログラム）をサイクリックに実行し、検査装置の一部である特定アプリケーションを制御する。また、合格した複数の特定アプリケーション用プログラム部品をもとに、それらを合成したプログラムを作成し、必要なデストをする。その後、その合成プログラムをＰＬＣに格納し、そのＰＬＣが合成プログラムをサイクリックに実行し、検査装置全体を任意に制御する。

製品の共通性と差異性との分析を説明する図である。 アプリケーションの一形態である検査装置の構造を示す図である。 検査装置における特性のバリエーションを表形式で示した図である。 コンポーネントの全体構成図である。 オプションコンポーネントを説明する図である。 代替コンポーネントを説明する図である。 オプションコンポーネントを記述するファンクションブロックの一例を示す図である。 代替コンポーネントを記述するファンクションブロックの一例を示す図である。 特性モデルの全体図である。 特性モデルにおいて、オプションコンポーネントと代替コンポーネントの選択状態を示す図である。 本発明の一実施の形態を示す図である。 プログラム部品データベースに格納される情報の一例を示す図である。 コンポーネントヘッダのデータ構造の一例を示す図である。 マクロ処理の作用・原理を説明する図である。 コンポーネント関連図エディタにおける表示画面の一例を示す図である。 コンポーネント・エディタの操作画面の一例を示す図である。 編集機能の一例を示すフローチャートの一部である。 編集機能の一例を示すフローチャートの一部である。 編集禁止処理の機能を説明するフローチャートである。 テスト結果を反映させた表示形態の一例を示すコンポーネント関連図である。 単体テストの処理手順を示すフローチャートである。 図２１のＳ３４の具体的な処理手順を示すフローチャートである。 図２１のＳ３５の具体的な処理手順を示すフローチャートである。 図２１のＳ３８の具体的な処理手順を示すフローチャートである。

符号の説明

５０ ドメイン支援分析ツール
５１ 特性モデルエディタ
５２ 製品の特性情報
６０ プログラム部品管理ソフトウェア
６０ プログラム管理ツール
６１ プロダクト・パラメータ・マネージャ
６２ コンポーネント・マネージャ
６３ マクロ・プロセッサ
６４ コンポーネント・エディタ
６５ コンポーネント・エディタ
６６ ワークメモリ
６７ マクロへの入力パラメータ（特性選択データ）
６８ 資産プログラム部品（マクロ記述済み）
７０ プログラム部品データベース
７１ 単体テストツール
７２ ＰＬＣシミュレータ
７３ 特定アプリケーション用プログラム部品

Claims (8)

1. 機器制御プログラムを構成するための汎用性のある複数の資産プログラム部品と、その資産プログラム部品に基づいて生成される特定のアプリケーション用プログラム部品への入力条件と、当該特定のアプリケーション用プログラブ部品が合格の場合にその入力条件に従って演算実行した場合に出力される期待出力を演算実行順に時系列に記載したテストシナリオと、を関連づけて記憶するプログラム部品記憶手段と、
   前記資産プログラム部品が動作するために必要な他の資産プログラムとの接続関係を示す関連図を表示装置に表示し、処理対象の資産プログラム部品並びに編集処理かテストかの処理内容を選択させる選択手段と、
   前記選択手段により処理内容として編集処理が選択された場合に前記資産プログラム部品を編集する編集手段と、
   前記選択手段により処理内容としてテストが選択された場合に前記特定のアプリケーション用プログラム部品がダウンロードされたシミュレータに対し、前記テストシナリオに従って入力条件を与えると共に、そのシミュレータの実行結果と前記期待出力とを比較するテスト手段と、
   を備え、
   前記資産プログラム部品は、プログラムの一部を変形するためのマクロ記述を組み込み、そのマクロ記述は、入力された条件に従って必要なプログラムの要素を特定し、不要なプログラムの要素を削除するものであり、
   前記マクロ記述を含む資産プログラム部品に対応する前記特定のアプリケーション用プログラム部品は、マクロ処理を実行して生成され、
   前記関連図上の資産プログラム部品の表示態様を、前記テスト手段による比較結果を反映させるように構成した、
   ことを特徴とするプログラム部品管理装置。
2. 前記選択手段により選択された資産プログラム部品に、前記関連図で下位側に接続された他の資産プログラム部品である子の資産プログラム部品が存在するか否かを判断し、前記子の資産プログラム部品が存在する場合には、前記資産プログラム部品と前記子の資産プログラム部品とを合成して１つのプログラムを生成するプログラム合成手段を備えたことを特徴とする請求項１に記載のプログラム部品管理装置。
3. 前記子の資産プログラム部品に対しては、プログラムの内容の表示を許可するが、前記編集手段による編集を禁止するよう設定する禁止手段を備えたことを特徴とする請求項２に記載のプログラム部品管理装置。
4. 前記選択手段により選択された資産プログラム部品に、前記関連図で下位側に接続された他の資産プログラム部品である子の資産プログラム部品が存在するか否かを判断し、前記子の資産プログラム部品が存在する場合には、前記資産プログラム部品に対応する前記特定のアプリケーション用プログラム部品と、前記子の資産プログラム部品に対応する前記特定のアプリケーション用プログラム部品とを合成して１つのプログラムを生成するプログラム合成手段を有し、
   前記シミュレータにダウンロードされ実行される前記特定のアプリケーション用プログラム部品は、前記プログラム合成手段で生成されたプログラムとすることを特徴とする請求得１から３のいずれか１項に記載のプログラム管理装置。
5. 前記テスト手段による比較結果を反映は、テストシナリオを実行して合格したものと、合格していないものを識別可能にするものであることを特徴とする請求項１から４のいずれか１項に記載のプログラム管理装置。
6. 前記合格したものの表示態様で表示された資産プログラム部品を前記編集手段で編集処理したか否かを判断し、編集処理された場合には表示態様を合格していない状態に変更する手段を備えたことを特徴とする請求項５に記載のプログラム管理装置。
7. 資産プログラム部品について準備したテストシナリオすべてが合格となった場合に、その資産プログラム部品を合格したものとすることを特徴とする請求項５又は６に記載のプログラム管理装置。
8. 前記資産プログラム部品は、ラダープログラムにより構成され、
   前記マクロ記述は、入力された条件に従って特定のアプリケーションに合わせて当該ラダープログラムの接点や回路を組み替え、当該特定のアプリケーションに不要な回路を削除することを目的としたマクロ処理言語でマクロ記述であることを特徴とする請求項１から７のいずれか１項に記載のプログラム管理装置。

Images