JP5230587B2

JP5230587B2 - ラダープログラムのプログラム試験装置、ラダープログラムのプログラム試験方法およびラダープログラムのプログラム試験用プログラム

Info

Publication number: JP5230587B2
Application number: JP2009268772A
Authority: JP
Inventors: 晃一中川
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2009-11-26
Filing date: 2009-11-26
Publication date: 2013-07-10
Anticipated expiration: 2029-11-26
Also published as: JP2011113277A

Description

この発明は、産業プラントのようにポンプやバルブなどの操作器や、流量計・圧力計などのセンサが大量に配置されているシステムにおいて、センサが検出した運転データをオペレータが監視することで、プラントの状態を即時に把握し、操作器を操作することで安定した運転を支援するコンピュータのプログラムを試験するプログラム試験装置に係るものである。

プラントはボイラや発電機などの大型の設備が多数あり、各設備にはポンプやバルブといった操作器、圧力計や流量計といったセンサなど、多数の機器が配置される。プラントの運転状態を監視するには、こうした機器がもつ信号を系統図や設備構成図などのＧＵＩ(Graphic User Interface)画面に表示されるグラフィックシンボルに割り付け、中央監視室と呼ばれる部屋で現在値を監視し、あるいは機器で生じた故障をメッセージやグラフィック形式でオペレータが確認して、操作器を操作することが行われている。こうしたプラントの現場ではPLC(programmable logic controller)と呼ばれるコンピュータが設置され、センサの値を使って演算を行いながら、オペレータの指示によりプラントの機器の制御を行うプログラムが実行されている。

こうしたプログラムを試験する場合は、信号の値を模擬するシミュレータを用いて主にオペレータが手動で値を操作・設定を行いながら目視で挙動を確認することが多い。また、プラントは信頼性が重要視されるので、プラントにつながれている信号の全点について確認を行う必要がある。プラントで扱う点数は規模にもよるが数百点から数万点の信号点数をもつものがあり、実施する試験の数が多く、試験するプログラムの規模も大きいためデバッグや保守が難しい。

このような試験（テスト）において、必要となるテストデータを設定するプログラムを自動生成することにより、テスト費用を削減するものがあった（例えば特許文献１）。テストで必要になるプログラムにはテストデータを設定するプログラムと、プログラムから出力された結果を評価するプログラムの２つがある。特許文献１では、テスト対象ラダー管理部にある試験対象となるプログラム（ラダープログラム）から入出力変数抽出部により入力となる変数を抽出することで、仮想入力ラダー生成部によりテストデータを設定するプログラムを自動的に生成することができる。また、テスト入力シーケンス管理部によりユーザが簡単なコマンドとパラメータを指定するだけで出力結果を評価するプログラムをつくることができ、比較的高度な知識を必要とするラダー言語を知らなくてもテストを行うことができる。

特開２００５-６３４２５号公報（図２）

特許文献１に開示されている技術によれば、テスト結果を評価するプログラム（手順）の設計はプログラム言語であるラダープログラムの記述方法を知らなくてもよいが、シーケンスプログラムの基本動作や、どのプログラム内のサブモジュールの依存関係や、どの変数がどこで参照されているかなどのプログラム設計者に相当するプログラムの内部情報
がないと設計ができない。
また、テスト結果の検証は正常値との比較といった単純なものだけしか扱うことができないため、複数の条件を組み合せたり、時間や状態変化を考慮するものであったり、ある条件での試験結果を他の条件の入力データとして使ったりするなどプログラマブルな条件を指定することができない。
本発明は、このような課題を解決するためになされたもので、複数の条件を組み合せたり、時間や状態変化を考慮できたり、ある条件での試験結果を他の条件の入力データとして使ったりするなど、プログラマブルな条件でプログラム試験が行えるプログラム試験装置を提供することを目的とする。

本発明に係るラダープログラムのプログラム試験装置は、入力部から入力された試験対象ラダープログラムを複数のモジュールに分割し、この分割されたモジュール毎のモジュールの情報と、モジュール毎に用いられている変数情報とを解析して取得し、モジュール毎に当該モジュールが実現する機能の情報と、当該モジュールに依存する他のモジュール
の識別情報とを入力部から取得してモジュールの情報に加えてモジュール情報とし、このモジュール情報と変数情報とをテストデータベースに格納するプログラム解析部と、テストデータベースに格納されたモジュール情報と変数情報とを用いて、モジュール毎にプログラム試験を行うために必要なテストロジックとテストデータとを入力部から入力するためのテスト入力画面を生成してこのテスト入力画面を構成するためのテスト入力画面情報を上記テストデータベースに格納するテスト入力画面生成部と、テスト入力画面情報を用いて表示部にテスト入力画面を表示させるとともに、テスト入力画面を用いて入力されたテストロジックから生成されたテストプログラムと入力されたテストデータをテストデータベースに格納するテスト編集部と、入力されたテストデータを用いてテストプログラムを実行し、テスト結果をテストデータベースに格納するテストプログラム実行部とを備えたものである。

この発明によれば、テストに際して、テストロジックをオペレータが入力するようにしたので、複数の条件を組み合せたり、時間や状態変化を考慮できたり、ある条件での試験結果を他の条件の入力データとして使ったりするなど、プログラマブルな条件でプログラム試験が行える。

本発明の実施の形態１によるプログラム試験装置の概要を示すブロック図である。本発明の実施の形態１によるプログラム試験装置のテストデータベースのデータ構成の一例を示す図である。本発明の実施の形態１によるプログラム試験装置のハードウエア構成の概要を示すブロック図である。本発明の実施の形態１によるプログラム試験装置のプログラム解析部の動作の概要を説明するフローチャート図である。本発明の実施の形態１によるプログラム試験装置のプログラム解析部によって表示する入力画面の一例を示す図である。本発明の実施の形態１によるプログラム試験装置のモジュール情報の構成の一例を示す図である。本発明の実施の形態１によるプログラム試験装置のテストデータベースの詳細構成の一部を示す図である。本発明の実施の形態１によるプログラム試験装置のテスト入力画面の変数情報の入力部分の生成例を示す図である。本発明の実施の形態１によるプログラム試験装置のテスト入力画面生成部の動作の概要を説明するフローチャート図である。本発明の実施の形態１によるプログラム試験装置のテスト入力画面のロジック入力部分の生成例を示す図である。本発明の実施の形態１によるプログラム試験装置のテスト入力画面の一例を示す図である。本発明の実施の形態１によるプログラム試験装置のテスト実行結果を表示する画面の一例を示す図である。本発明の実施の形態２によるプログラム試験装置のプログラム解析部の動作の概要を説明するフローチャート図である。本発明の実施の形態２によるプログラム試験装置のプログラム解析部によって表示する入力画面の一例を示す図である。本発明の実施の形態２によるプログラム試験装置のテスト入力画面生成部の動作の概要を説明するフローチャート図である。本発明の実施の形態２によるプログラム試験装置のテスト入力画面の一例を示す図である。

実施の形態１．
図１は本発明の一実施の形態によるプログラム試験装置の概要を示すブロック図である。プログラム試験装置はテストデータベース８０と制御部７０と、オペレータからデータを入力できる入力部４と、出力結果をグラフィックあるいはテキスト形式で表示する表示部２で構成される。なお、制御部７０はコンピュータがプログラムにより実行するものである。すなわち制御部７０はプログラム試験プログラムと同義である。入力部４から制御部７０にテストに関するデータの入力を行い、その出力結果を表示部２に出力する。入力部４から試験対象プログラム９２が入力されると、制御部７０は試験対象プログラム９２をいくつかのモジュールに分割し、モジュールのもつ変数に設定するテストデータやテストに指定するロジックを機能単位で分割してテストデータベース８０に記憶する。また試験対象プログラム９２を解析してプログラム中に宣言されている変数の情報をテストデータベース８０に格納する。記録したテストプログラムを実行するとテスト実行結果８５がテストデータベース８０に記憶される。

テストデータベース８０はテストに関するデータを管理する。変数情報８１はテストの対象となるプログラムの中でどのような変数があり、その変数がどのように使われているかに関する情報を管理する。モジュール情報８２は試験対象プログラム９２の中にあるモジュールを機能毎に管理する。またどのモジュールでどの変数が使われているかも管理する。テストプログラム８３はテストロジックをスクリプトのような軽量言語を使って記述したもので、モジュール単位で管理されている。テストデータ８４はモジュール単位で管理され、各モジュールがもつ変数がテストプログラム８３に格納されたテストプログラムごとにどのような値をもつかを格納したものである。テストプログラム８３はローダ９３によりＰＬＣ９４で実行できる形式に変換されてＰＬＣ９４上で実行される。実行された結果は関連する機能やテスト実行単位(何月何日の何回目の実行かなど)やバージョン単位で記録してテスト実行結果８５として管理する。

本発明の実施の形態１によるプラント試験装置の制御部７０は概略以下のように動作する。まず、入力部４から試験対象となる試験対象プログラム９２を入力する。試験対象プログラム９２は、プログラム解析部７５により複数モジュールに分割され、モジュールごとに関連する機能や使われている変数と変数の利用状況が解析される。これらの解析は、例えば、モジュールに分割する部分などは良く知られたプログラム解析ツールなどで行われるが、以下に説明するように、モジュールがどのような機能を果たしているのかなど、解析ツールだけでは解析しきれない部分を、オペレータが関与して解析を行う。ここに本
発明の特徴がある。

プログラムを解析することにより得られた情報からは各モジュールで使われる変数の属性を知ることができるので、それに合わせてモジュール毎に含まれる変数の入力画面（マークアップテキスト生成）を構成する。このとき各変数には別名が自動的に、あるいは入力画面からの入力によって付加される。この別名はテストを記述するときに変数を特定するために使うものである。また、変数の説明などもオペレータによって入力され、別名とともに変数情報８１の一部としてテストデータベース８０に格納される。ただし、変数情報は、解析によって得られる情報のみで十分な場合もあり、常に入力によって得る必要はない。

プログラムの解析がすべて完了すると、テスト入力画面生成部７１によりテストデータやテストロジックを入力する画面が生成される。入力画面はＨＴＭL(Hyper Text Markup Language)などのマークアップ言語を生成することで実現してもよい。
テストデータの入力画面とテストロジックの入力画面は合成されてテスト入力画面として生成され、生成されたテスト入力画面がデータ形式でテスト入力画面情報８８としてテストデータベース８０に格納される。

以上で試験対象プログラム９２をテストする準備が整った。次に、どのようなテストを行うのかを、生成されたテスト入力画面情報８８により実際にテスト入力画面を表示部２に表示させ、オペレータが入力部４から必要な情報を入力する。すなわち、テスト編集部７３では、生成されたテスト入力画面を使ってテストごとに編集するテストデータと実行するテストのロジックを入力部４からオペレータが入力する。

入力画面から入力されるテストロジックはマークアップ言語とは別にECMAのJavaScript（登録商標）やMicrosoft 社のVBScriptやAdobe社のActionScriptのようなマークアップ
内に記述可能なスクリプトとして入力される。このようなスクリプトはコンパイル不要な言語で、軽量言語と呼ばれている。上記した変数の別名を使って制御構文などを使ってテストの検証ロジックを記述する。このように、テストロジックを、制御構造を有する軽量言語で記述できるので、機械語に近い低度な表現力しか有さないラダープログラムでは記述し難かった検証ロジックを簡単に記述することができる。テスト編集部７３は入力されたロジックと、別名でプログラムの変数にアクセスするためのプログラムを結合してテストプログラム８３を生成してテストデータ８４とともにテストデータベース８０に記録する。
テストプログラム実行部７４はテストデータベース８０に記録されたテストデータ８４を用いてテストプログラム８３を実行することによりテストを実行しテスト実行結果８５をテストデータベース８０に記録する。

以上のステップのうち、テストを準備するまでのステップでは、例えば変数の説明や機能などの入力は試験対象プログラムのプログラム知識を有するオペレータが行う必要があるが、どのようなテストを行うのかを入力したり、テストを実行したりするステップ、すなわち実際にプログラム試験を行う段階では、試験対象プログラムのプログラム知識を有しないオペレータでも、軽量言語など最低限の知識を有していれば実施することができる。

図２に、テストデータベースの具体的な構成を示す。図２に示すように、テストデータベース８０はプログラムごとにモジュール情報８２を格納するモジュール情報領域８２０と、モジュール毎に変数情報８１を格納する変数情報領域８１０とをもち、モジュールの識別情報である要素ＩＤを格納する要素ＩＤ領域８７を有している。またモジュールごとにテスト情報を格納するテスト情報領域８６をもち、テスト情報領域８６にはモジュール
で使われるすべてのテストデータ８４とテストプログラム８３が格納されている。モジュール情報領域８２０にはプログラムの解析単位であるプログラムの部分（行番号のどこからどこまで）や直接関連する機能などが記憶されており、各モジュールのモジュール情報領域に変数情報領域８１０、テスト情報領域８６を有している。変数情報領域８１０には各モジュールで使われている変数に関する属性（名称、型名、別名など）や、変数の使用状況（入力変数、出力変数、値の参照）が記憶されている。このように、各情報は、モジュール毎に関連付けて格納されており、モジュール情報にはそのモジュールが実現する機能の情報も含まれているため、結局各情報は機能ごとに管理されることになる。

図１のプログラム試験装置を、ＣＰＵなどを用いて実現した場合のハードウエア構成を図３に示す。図３において、ＣＰＵ１には、メモリ３、ディスプレイ２１などの表示部２、キーボード４１やマウス４２などの入力部４、ハードティスク８が接続される。ハードディスク８には、図１の制御部７０の機能を果たすプログラム試験プログラムとテストデータベース８０、オペレーティングシステム（ＯＳ）９０が記録されている。プログラム試験プログラム（制御部）７０は、例えば記憶媒体からハードディスク８にインストールされる。図３では、ＣＤ−ＲＯＭドライブ５を介してＣＤ−ＲＯＭからインストールされる例を示している。

図４に、制御部（プログラム試験プログラム）７０のプログラム解析部７５の動作の概要をフローチャートにして示す。プログラム試験プログラム７０は、オペレーティングシステム９０と協働して処理を行う。まず、キーボードから、試験対象となる試験対象プログラム９２を入力する（ST01）。プログラムの入力は、入力部４のキーボードから入力したり、ＣＤ−ＲＯＭなどの記憶媒体からファイル形式で読み込むなどして行われる。ＣＰＵ１は入力された試験対象プログラム９２をディスプレイ上に表示する。表示された試験対象プログラムの一例を図５に示す。図５に示すように、試験対象プログラムとともに、プログラムＩＤや後述する要素ＩＤ、また機能名などオペレータが入力するための入力ボックス、あるいは変数情報なども表示される。

解析するプログラムがそこで終了すれば処理を終了し、そうでなければ次の処理を行う(ST02)。試験対象プログラムは、一般に用いられているプログラム解析ツールなどと同様の方法でモジュールと呼ばれる部分に分割され、モジュールに付加する要素ＩＤが生成される(ST03)。図５の例では、モジュールに対して137222という要素ＩＤが生成されたことを示している。要素ＩＤは、分割した各モジュールに対してテストデータベースがシステム内で識別するために設ける識別子である。例えば、機能やモジュール番号、プログラム番号などにＩＤをつけ、それを数ビット単位で割りつけるといった形にすると検索効率がよくなる。

入力したプログラムの解析範囲や関連する機能名をオペレータが入力する(ST04)。これら解析範囲や機能名などは、オペレータが決定するものであってプログラム試験プログラム自体では判断や生成ができないため、オペレータが入力する。解析範囲の入力は、試験対象プログラムがラダープログラムであれば、プログラムソースやラダー命令の開始行と終了行を指定することで行われる。また、機能名は文字列を使って入力する。図５の例では「ポンプ運転」を機能名として入力している。

図６はテストデータベースにおける要素ＩＤを記憶させた領域である要素ＩＤ領域８７に格納されている情報の一例を示したもので、最上段の要素ＩＤはプログラムのＩＤが０１で機能ＩＤ（機能の識別情報）は１０、このプログラム０１におけるモジュールのシリアル番号は０１であることを示している。この値を１６進として 0x011001と処理すると10進で69633の値が算出できる。このように、各モジュールは機能と関連付けて管理されている。

また、プログラムＩＤが０１のプログラムは、ＩＤが０１、０２、１３、６４、４５のモジュールで構成されており、０１、０２、１３のモジュールによって機能ＩＤが１０の機能を、６４、４５のモジュールによって機能ＩＤが１１の機能を実現するプログラムであることを示している。同様に、プログラムＩＤが０２のプログラムは、ＩＤが０５、１１、２３のモジュールから構成されており、これらのモジュールで機能ＩＤが２０の機能を実現するプログラムであることを示している。プログラムＩＤが０３のプログラムはＩＤが０８、０９、１８のモジュールから構成されており、０８のモジュールで機能ＩＤが０１の機能を、０９のモジュールで０２の機能を、１８のモジュールで０３の機能を実現するプログラムであることを示している。

以上のように、プログラム解析部７５により、試験対象プログラムはモジュールに分割されるが、機能名はオペレータが名づけるものであり、オペレータが名づけた機能がどのモジュールで実行されるのかはプログラム解析部７５が自動で判断することはできない。従って、上記したように、オペレータがモジュール毎に機能名を入力することで、図６のような情報が得られる、すなわち、試験対象プログラムの解析にオペレータが関与することで、例えば機能ごとのプログラム試験が行えるようになるなど、効率的でより実際の動作に近い状況でプログラム試験が実行できるようになる。

次にモジュールにおける変数の解析を行い、変数情報８１を変数情報領域８１０に格納する。図７に示す変数情報領域８１０に記述されている変数情報がテストデータベース８０における変数情報の例であり、ここではこのモジュールには変数M02、M24、B02、B36が検出されている。変数M02などはラダープログラムにおけるメモリアドレスの識別子であり、プログラムを記述するときによくアドレスが変わることがある。そこでＡ１などの別名を付けておき、テストを記述する際に使用する。また、この変数M02の型はWORD型１６ビット長さの変数で、モジュールの入力変数として使われていることがわかる。なお、使用状況の欄におけるＩＮが入力変数として使用されていることを示し、ＯＵＴは出力変数、ＲＥＦは参照変数として使用されていることを示す。

以上の解析により得られた変数情報８１からは各モジュールで使われる変数の属性を知ることができるので、それに合わせてモジュール毎に含まれる変数の入力画面（マークアップテキスト生成）を構成する（ST06）。モジュール毎に入力画面を構成するのは、解析により得ることができない変数の情報をオペレータにより入力させるためである。図８は変数情報からマークアップ言語を使って画面を生成した例である。既成のテンプレートのような画面を用意することで簡単に画面を生成することができる。このとき各変数には別名が自動的に、あるいはオペレータの入力により作成される。この別名はテストを記述するときに変数を特定するために使うものである。図８の入力画面の例では、オペレータによって変数の説明を入力させるようにしている。ただし、前述のように、変数情報は解析によって得られる情報のみで十分な場合もあり、必ずしも入力画面を構成して入力によって得る必要はない。

図５の例では、この変数に関する入力画面を、モジュールの機能名などを入力する画面と同時に表示している。図５の太線枠がオペレータによって入力する情報であり、ここでは、変数の別名もオペレータにより入力するようになっている。これら入力された変数の情報は、解析により得られた変数情報とともに変数情報領域８１０に格納される。

以上で、試験対象プログラム９２の解析が完了し、テストに必要なプログラムの情報が得られた。次に、テストに必要なテストの情報、すなわちどのようなテストを行うのかをオペレータが入力するためのテスト入力画面を生成する。図９に、テスト入力画面生成部７１の動作をフローチャートにして示す。まず、キーボードから対象となるプログラムを
入力する（ST10）。対象となるプログラムにテスト入力画面を生成するための解析を行うモジュールがなければ終了し、そうでない場合は次の処理を行う（ST11）。
次に、プログラムのもつモジュールの解析されていない最初の要素ＩＤを取得してモジュールを読み込む(ST12)。次に作成するテスト入力画面を識別するテスト番号を入力する(ST13)。

ステップ１４（ST14）では変数を解析してテストに必要な変数の値などを入力させるためのテストデータの入力画面を生成する。変数の入力画面が生成されると、次に各モジュールのテストロジックの入力画面が生成される（ST15）。このテストロジックの入力画面は、例えばマークアップ言語を使って生成する。上記した変数の別名を使って制御構文などを用いてテストのロジックを記述する。テストデータの入力画面とテストロジックの入力画面は合成されてテスト入力画面として生成され（ST16）、その画面を構成するのに必要なデータがテスト入力画面情報８８としてテストデータベース８０に格納される。

図１０はモジュール情報８２から生成されたテスト入力画面におけるテストロジックの入力画面部分を示したものである。ここでは変数情報８１で定義された別名を用いて、簡易言語のような軽量言語を使ってロジック if( A3&A4 == true) { assert( A2 == A1+100
); } を記述している。これはビット型変数であるＡ３とＡ４のいずれかがtrueであるとき、WORD型の変数Ａ２がWORD型の変数Ａ１より100大きい数でない場合が異常であること
を検出するロジックである。このようなテストロジックは、試験毎にオペレータが決める必要があり、テスト入力画面生成部７１によって自動で生成することはできないため、入力画面によってオペレータが入力するように構成している。このようにプログラマブルな条件を指定できるように構成することで、複雑な条件など、種々の状態を模擬した試験が行えるようになる。

図１１は生成されたテスト入力画面の例である。ここでは、このモジュールに関連するプログラム名は”Ａ水処理場“、機能名は”水処理“であり、モジュールで使用されている変数へのテストデータ入力画面部などが表示されている。テストデータやロジックは画面にある編集ボタンを押すことで編集モードに切り替わり編集が行えるようになる。

次に、実際にテストを行う場合、テスト編集部７３が、テスト入力画面情報８８を用いて、表示部２に図１１の例で示すようなテスト入力画面を表示させ、オペレータにテストロジックや必要なテストデータを入力させる。入力されたテストロジックと、別名でプログラムの変数にアクセスするためのプログラムを結合してテストプログラム８３を生成して、入力された変数データなどのテストデータ８４とともにテストデータベース８０に記録する。

このようにしてテストプログラム８３およびテストデータ８４が整った後、オペレータにより実行ボタンが押されると、テストプログラム実行部７４がテストデータベース８０に記録されたテストデータ８４と軽量言語のような簡易言語で記述されたテストプログラム８３を読み込んで、ローダ９３にテストプログラム８３とテストデータ８４を送り、ローダ９３がＰＬＣ９４で実行可能な形式に変換してＰＬＣ９４上でテストが実行される。テストが実行されると、テストプログラム実行部７４がＰＬＣ９４のメモリーにある実行結果のデータを受け取り、テスト実行結果８５をテストデータベース８０に記録する。また、テスト結果は表示部２に表示させることもできる。このようにして、テストプログラム実行部７４では、ＰＬＣ９４上でテストプログラムを実行させるとともに、テストの実行結果を機能ごと、テスト実行単位で管理することができる。

図１２はテストデータベース８０にあるテスト実行結果８５の例である。これによればＡ水処理場に関するテストが１日単位で実行され、９月９日のテストではモジュール３４
と５６についてはテストが成功していないが、次の日の９月１０日のテストでは各モジュールのバージョンがともに0.8から1.0、1.1から2.0に更新されることでテストがクリアされていることがわかる。このようにテスト結果を一元的に管理することで機能単位、モジュール単位、日時単位といった側面で多角的に分析を行えるため試験の効率化をはかることが可能になる。

以上説明したように、本実施の形態１によれば、プログラム解析部が自動で解析により得ることができないモジュール情報や変数情報の一部を、オペレータに入力させることで得ることができ、さらに、オペレータにテストロジックとテストデータを入力させることにより、複数の条件を組み合せたり、時間や状態変化を考慮したり、ある条件での試験結果を他の条件の入力データとして使ったりするなどプログラマブルな条件でプログラム試験が行える効果がある。

実施の形態２．
図１３は、本発明の実施の形態２によるプログラム試験装置のプログラム解析部７５の動作の概要を説明するフローチャート図である。各機能は、機能同士で関連する場合がある。例えばある機能の出力値が別の機能の入力になったり、ある機能の出力値により別の機能の判断が変化したり、といった様に、相互に他の機能に依存することが多い。このような依存関係は、プログラムの解析によるだけでは抽出できない場合が多い。このため、オペレータに依存関係を入力させて、依存関係を明確にしておくことで、プログラム試験が、より効率的に実行できることになる。

図１３において、ステップ０８（ST08）、０９（ST09）以外は実施の形態１の図４と同様である。これらステップ０８、０９が、プログラム解析部７５において依存関係を入力するステップである。依存するモジュールがなければ次の処理に移る（ST08）が、このモジュールが依存する他のモジュールがあればその要素ＩＤを入力する(ST09)。実際には、図１４に示すように、依存するモジュールを入力させるボックスを用意することで行われる。図１４の例では、依存するモジュールとして要素ＩＤ69634のモジュールを指定して
いる。つまり要素ＩＤ69634のモジュールは要素ＩＤ137222のモジュールから呼び出され
るモジュールとなる。この情報は、モジュール情報に格納される。なお、依存関係は、モジュールではなく、依存する機能を入力させるようにしても良い。依存する機能がわかれば依存するモジュールが抽出できるからである。この場合、機能のＩＤまたは機能名を入力させることになる。

図１５は、本発明の実施の形態２によるプログラム試験装置のテスト入力画面生成部の動作の概要を説明するフローチャート図である。図１５において、ステップ１７（ST17）、１８（ST18）以外は実施の形態１の図９と同様である。これらステップ１７、１８が、テスト入力画面生成部において、依存関係を判断して対応する入力画面を生成するステップである。入力画面を生成するモジュールのモジュール情報に、他のモジュールに依存する情報があるかどうか判断し（ST17）ある場合は、関連するモジュール（あるいはそのモジュールが実行する機能）の入力画面へのハイパーリンクを生成する（ST18）。ステップ１４で生成されたテストデータの入力画面とステップ１５で生成されたテストロジックの入力画面、およびステップ１８で生成された関連するモジュールの入力画面は合成されてテスト入力画面として生成され、その画面を構成するためのデータがテスト入力画面情報８８としてテストデータベース８０に格納される。

図１６に生成されたテスト入力画面の例を示す。ここでは、実施の形態１の図１１と同様、このモジュールに関連するプログラム名は”Ａ水処理場“、機能名は”水処理“であり、モジュールで使用されている変数へのテストデータ入力画面部などが表示されている。テストデータやロジックは画面にある編集ボタンを押すことで編集モードに切り替わり編集が行えるようになる。加えて、「依存関係にある機能」の欄が設けられ、この欄に関連する機能の入力画面へのハイパーリンクが表示されている。

次に、実際にテストを行う場合、実施の形態１と同様、テスト編集部７３が、テスト入力画面情報８８を用いて、表示部２に図１６の例で示すようなテスト入力画面を表示させ、オペレータにテストロジックや必要なテストデータを入力させる。入力されたテストロジックと、別名でプログラムの変数にアクセスするためのプログラムを結合してテストプログラム８３を生成して、入力された変数データなどのテストデータ８４とともにテストデータベース８０に記録する。

このようにしてテストプログラム８３およびテストデータ８４が整った後、オペレータにより実行ボタンが押されると、テストプログラム実行部７４がテストデータベース８０に記録されたテストデータ８４と軽量言語のような簡易言語で記述されたテストプログラム８３を読み込んで、ローダ９３にテストプログラム８３とテストデータ８４を送り、ローダ９３がＰＬＣ９４で実行可能な形式に変換してＰＬＣ９４上でテストが実行される。テストが実行されるとテストプログラム実行部７４がＰＬＣ９４のメモリーにある実行の結果のデータを受け取り、テスト実行結果８５をテストデータベース８０に記録する。また、テスト結果は表示部２に表示させることもできる。このようにして、テストプログラム実行部７４では、ＰＬＣ９４上でテストプログラムを実行させるとともに、テストの実行結果を機能ごと、テスト実行単位で管理することができる。

以上説明したように、本実施の形態２によれば、実施の形態１と同様、プログラム解析部が自動で解析できないモジュール情報や変数情報の一部を、オペレータに入力させることで得ることができ、さらに、オペレータによりテストロジックを入力させることにより、複数の条件を組み合せたり、時間や状態変化を考慮したり、ある条件での試験結果を他の条件の入力データとして使ったりするなどプログラマブルな条件でプログラム試験が行える。本実施の形態２では、これに加えて、依存関係にある機能をテストすることができるため、テスト結果に異常があり、試験対象プログラムにバグがある可能性があると判断された場合など、依存関係にある機能のテストも行うことで、効率的にバグ検索を行うことができる。

２：表示部４：入力部
７０：制御部７１：テスト入力画面生成部
７３；テスト編集部７４：テストプログラム実行部
８０：テストデータベース８１：変数情報
８２：モジュール情報８３テストプログラム
８４：テストデータ９２：試験対象プログラム

Claims

入力部と表示部と制御部とテストデータベースとを備えたラダープログラムのプログラム試験装置において、
上記制御部は、上記入力部から入力された試験対象ラダープログラムを複数のモジュールに分割し、この分割されたモジュール毎に当該モジュールを解析して、モジュールの情報と、上記モジュール毎に用いられている変数情報とを取得し、上記モジュール毎に当該モジュールが実現する機能の情報と、当該モジュールに依存する他のモジュールの識別情報とを上記入力部から取得して上記モジュールの情報に加えてモジュール情報とし、このモジュール情報と上記変数情報とを上記テストデータベースに格納するプログラム解析部と、
上記テストデータベースに格納された上記モジュール情報と上記変数情報とを用いて、上記モジュール毎にプログラム試験を行うために必要なテストロジックとテストデータとを上記入力部から入力するためのテスト入力画面を生成してこのテスト入力画面を構成するためのテスト入力画面情報を上記テストデータベースに格納するテスト入力画面生成部と、
上記テスト入力画面情報を用いて上記表示部に上記テスト入力画面を表示させるとともに、上記テスト入力画面を用いて入力されたテストロジックからテストプログラムを生成し、生成したテストプログラムと入力されたテストデータを上記テストデータベースに格納するテスト編集部と、
上記テストデータベースに格納された上記テストデータを用いて上記テストプログラムを実行し、テスト結果を上記テストデータベースに格納するテストプログラム実行部と
を備えたことを特徴とするラダープログラムのプログラム試験装置。
入力された試験対象ラダープログラムを複数のモジュールに分割するステップと、
この分割されたモジュール毎のモジュールの情報と、これらモジュール毎に用いられている変数情報とを解析して取得するステップと、
上記モジュール毎に当該モジュールが実現する機能の情報を入力部から取得して上記モジュールの情報に加えてモジュール情報とし、このモジュール情報と上記変数情報とをテストデータベースに格納するステップと、
上記モジュール毎に当該モジュールに依存する他のモジュールの識別情報を入力部から取
得し、取得した上記他のモジュールの識別情報を当該モジュールの上記モジュール情報に加えて上記テストデータベースに格納するステップと、
上記テストデータベースに格納された上記モジュール情報と上記変数情報とを用いて、上記モジュール毎にプログラム試験を行うために必要なテストロジックとテストデータとを入力するためのテスト入力画面を生成するステップと、
生成された上記テスト入力画面を表示部に表示させて、上記入力部から入力されたテストロジックからテストプログラムを生成し、この生成されたテストプログラムと上記入力部から入力されたテストデータとを上記テストデータベースに格納するステップと、
上記テストデータベースに格納された上記テストデータを用いて上記テストプログラムを実行し、テスト結果を上記テストデータベースに格納するステップとを備えたことを特徴とするラダープログラムのプログラム試験方法。
入力された試験対象ラダープログラムを複数のモジュールに分割する手順と、
この分割されたモジュール毎のモジュールの情報と、これらモジュール毎に用いられている変数情報とを解析して取得する手順と、
上記モジュール毎に当該モジュールが実現する機能の情報を入力部から取得して上記モジュールの情報に加えてモジュール情報とし、このモジュール情報と上記変数情報とをテストデータベースに格納する手順と、
上記モジュール毎に当該モジュールに依存する他のモジュールの識別情報を入力部から取得し、取得した上記他のモジュールの識別情報を当該モジュールの上記モジュール情報に加えて上記テストデータベースに格納する手順と、
上記テストデータベースに格納された上記モジュール情報と上記変数情報とを用いて、上記モジュール毎にプログラム試験を行うために必要なテストロジックとテストデータとを入力するためのテスト入力画面を生成する手順と、
生成された上記テスト入力画面を表示部に表示させ、テストロジックとテストデータとを入力させる手順と、
入力された上記テストロジックからテストプログラムを生成する手順と、
入力された上記テストデータを用いて上記テストプログラムを実行し、テスト結果を上記テストデータベースに格納する手順と、
をコンピュータに実行させることを特徴とするラダープログラムのプログラム試験用プログラム。