「品質向上の取り組み 〜PLCソフト開発における自動テストの活用〜」

自動テストシステムについて紹介する前に、まずはテスト対象システムについて紹介します。
システム構成の概略は図 1の通りです。

図1.  システム構成

今回自動テストの対象としたのは、フィールドネットワークで接続された5台のPLCが、連動して動作するシステムでした。
マスタPLCの上位にはサーバーが存在し、制御に必要な情報を通信にて取得します。
マスタPLCは、サーバーから取得した情報に従って、サブPLCへ指示を出し処理を行います。

PLCで動作する制御プログラムは、上位サーバーから受け取ったパラメータによって、様々な組み合わせで動作可能な設計となっています。
例えば以下のような感じです。

• パラメータで指定されたサブPLCの外部機器に対して入出力制御を行う。
• 位置決めモジュールなどのI/Oモジュールにアクセスし、外部機器を制御する。
• フィールドネットワーク内のPLC間でデバイス共有や時計同期などを行う。

図2.  プログラム構成

ライブラリ内のプログラムは汎用的に開発していますので、パラメータは複数存在し、パラメータが取り得る値のパターンも多くあります。更に、パラメータが不正な場合などの異常系も含めると、動作パターンは膨大な数となります。

全て人手でテストすることも可能でしたが、今回は他案件でも使用できる汎用的なプログラムであることや、今後もプログラムの改造や修正が発生する可能性が高いことから、繰り返し同じテストを実行できる自動テストが適していると考え、今回導入することとしました。

今回の自動テストシステムを含めた構成を図 3に示します。
今回、テスト対象と同じPLCに、自動テスト用プログラムも共存する形で実現しました。
本来テスト対象には手を加えずにテストを行うことが理想ではありますが、テスト対象がライブラリとして完全に独立しているため、今回はこの構成としました。
図中の点線箇所が、自動テストシステムの機能となります。

図3.  自動テスト構成

PLC内に実装した「自動テストプログラム」が、ライブラリ内のプログラムを呼び出すことでテストを行います。呼び出すプログラムやパラメータを決めるのは、「自動テスト用FTPフォルダ」に置いた「テストパターンファイル」です。期待値も定義し実行結果の合否判定も行います。
サーバーPC上で動作する「自動テストUI」によって、テストパターンの選択や自動テスト開始、終了指示を出すことができます。

テストパターンファイル、結果ファイルなど、自動テストで使用するファイルは、FTP経由でやり取りする構成としました。
テスト対象システムには、もともとFTP通信を行う仕組みがありましたので、これを利用しています。
自動テストに必要な情報をファイルでやり取りすることで、テストパターンやテスト結果をファイルとして記録に残すことが可能としています。

自動テストの流れに沿って整理すると以下の通りです。
図 3に記載した番号に沿って記載します。

(1)

「自動テストUI」から、テストパターンを指定して開始の指示を出す。

(2)

「自動テストプログラム」は、指示に従ってFTPフォルダからテスト内容、期待値が書かれた「テストパターンファイル」を取得する。

(3)

自動テストの実行状態は、「自動テストUI」で確認可能。

(4)

「テストパターンファイル」に書かれた順番とパラメータに従って、汎用プログラムを順次実行する。

(5)

汎用プログラムの実行が終了したら、期待値と比較して合否判定。

(6)

合否結果を「テスト結果ファイル」に出力してFTPフォルダに送付する。

次章より、自動テストプログラムのポイントを説明していきます。

テストパターンファイルのフォーマットを図 4に示します。

図4.  テストパターンファイル

簡単な具体例を出して、テストパターンファイルを見ていきます。
図 4 の1行目は、プログラム0001のテストであることを表しています。
プログラム0001の動作は以下の通りです。

(1)

指定した出力モジュールの端子に指定した値を出力する。

(2)

指定した入力モジュールの端子から入力信号を読み込む。

(3)

入力した信号を実行結果として返す。

パラメータは6つ持っており、以下の通りです。

• パラメータ1 … サブPLC番号
• パラメータ2 … 出力モジュールのスロット番号
• パラメータ3 … 出力モジュールの開始アドレス
• パラメータ4 … 出力データ（0: OFF or 1: ON）
• パラメータ5 … 入力モジュールのスロット番号
• パラメータ6 … 入力モジュールの開始アドレス

図 4の1行目のテストパターンは以下の動作となります。

• ・サブPLC3のY508にONを出力。
• ・サブPLC3のX408の入力信号を読み込む。
• ・読み込んだ入力信号が期待値と一致していたらOK。不一致ならNG。

自動テストでは、出力モジュールから出た信号が入力モジュールに入力されるように、ハード的に結線を行うことで実施しました。
そのため、プログラム0001が正しく動作していれば、パラメータ4の出力データと期待値が一致することとなります。
1行目は出力モジュールにONを出力しましたが、2行目はOFFを出力した場合の確認となります。

テストパターンファイルはCSV形式とすることで、Excel等で容易に編集できるようにしています。
ファイルの内容を編集することでテストパターンを変えることができますので、PLC側のプログラムに手を加える必要はありません。

自動テスト用にWindowsアプリケーションの開発を行いました。
図 3の構成図の「自動テストUI」となります。
このアプリケーションを使用することで、テスト開始と終了の指示をパソコンから行うことで、結果もパソコン上で確認できるようにしています。

テストパターンファイルは、「Test0001.csv」のようにファイル名に4桁のパターン番号(0000〜9999)を含め、最大10000種類指定できるようにしています。
テストパターンファイルを複数「自動テスト用FTPフォルダ」に用意しておくことで、「自動テストUI」から選択して実行することができます。

「自動テストUI」とPLCとのやりとりは、PLCに標準で備わっているModbusスレーブ機能を活用し、Modbus/TCP通信にて実装しています。
Modbus通信については、過去のソフテックだよりでも何度か取り上げていますので、そちらも参照ください。

• 第329号（2019年5月1日発行）技術レポート「Modbus/TCP通信 〜三菱PLCと横河レコーダの接続〜」
• 第155号（2012年2月1日発行）技術レポート「PLCでModbus TCP通信 〜横河電機社製での実装例〜」
• 第133号（2011年3月2日発行）技術レポート「PLCでModbus通信 〜横河電機社製での実装例〜」
• 第237号（2015年7月1日発行）技術レポート「PLCでのModbus通信 〜各メーカーの比較〜」

テストパターンファイルの内容に沿って、順次プログラムを実行し期待値との判定を行います。
テストパターンファイルの最後まで実行すると、実行結果をまとめてファイル出力、FTP通信にて「自動テスト用FTPフォルダ」に送付します。
ファイルフォーマットは以下の通りです。

図5.  テスト結果ファイル

汎用プログラム0001を順番に2回実行したところ、2回目の実行結果がNGであったことが分かります。
試験結果の詳細情報も備考としてファイル出力することが可能です。

また、自動テストは、終了指示を出すまで繰り返し実行が可能ですので、放置しているだけでFTPフォルダにテスト結果がどんどん蓄積されていきます。
同時に、自動試験に関連するイベントやPLCの命令実行など様々なタイミングで、時刻の情報を付加したログ出力するようにしています。
この試験結果とログファイルを元に、あとから問題個所を特定することが可能です。

この機能は、汎用プログラムの組合せ試験だけでなく、繰り返し試験や負荷試験でも役立ちました。

ここまでに紹介した、テストパターンファイルに沿った確認以外にも、品質向上に役立ったことがありましたので紹介します。

まずは、プログラムの実行タイミングを自由に変えたテストを行えること、スキャンタイムを変化させることで容易に負荷テストを実施可能なことでした。
テストパターンファイルには、プログラムの実行順を自由に定義することができますので、実行順の異なるパターンファイルを用意することで実現できました。また、処理時間の大きなプログラムを準備して呼び出すことで、負荷をかけたテストも行うことができました。

2つ目は、ある一定範囲のデバイス領域を監視する機能です。
プログラムの実行結果だけに着目するのではなく、プログラムを実行することで関係しないメモリ領域が変化していないかというチェック機能も実装していますので、品質向上に役立てることができました。

人が行う作業は、どうしてもケアレスミスが付き物だと思います。
ケアレスミスの発生度合いは人それぞれ違いますし、その時の体調、集中力、作業量、難易度などいろいろな要素に左右されます。
自動テストであれば、テストプログラムおよび設定値や期待値が正しい限り、何度繰り返してもミスは発生しません。

また、自動テストは、昼だろうが夜だろうが関係なく動き続けることが可能です。
自動テストを仕掛けて、人間は他の作業を行うことで工数を削減できること、これもメリットです。

本事例では、自動テストプログラムを組み込んだのはマスタPLC1台のみとしました。
自動テストプログラムを組み込み、自動試験UIを対応させることが必要ですが、工夫次第では複数PLC同時に試験を行い更に作業効率を向上させることが可能となります。

自動テストプログラムの開発自体に工数がかかります。
今回の事例の場合、外部で指示やモニタを行うWindowsアプリケーションを開発しましたし、PLC内部にもテスト用のプログラムを開発する必要がありました。
この自動テストのための開発工数が、手動でテストする場合よりも大きいようだと意味がありません。

また、テスト対象のプログラムには、出力モジュールから外部機器へ出力を行うもの、位置決めモジュールアクセスを行うものもありました。
今回、出力モジュールから出た信号を入力モジュールにループバックさせる対応は行いましたが、外部機器に相当する治具や模擬装置、シミュレータを用意することで、更にテスト品質を向上させることが可能です。
これらは、開発規模や費用対効果からの判断が重要だと考えます。

次に、自動テスト用プログラム自体にバグがあっては、問題が発生した場合に悪いのがどちらか分からないという事態に陥ってしまいます。
そうならないためにも、自動テストプログラム自体の品質をしっかりと担保しておく必要があります。

最後に、今回の自動テストの構成では、テスト対象のPLCに対しても自動テスト用プログラムを組み込むことで対応しました。理想はテスト対象のプログラムに手を加えない状態でテストを行うことだと思います。「自動テストUI」を改善することで対応可能と思いますので、今後の課題として取り組んでいきたいと思います。