「PLCを組み合わせた自動テスト」

テスト作業というと、「人が試験項目書を確認しながら、操作を行い項目書通りに動作することを確認していく」というイメージがあると思いますが、今回取り上げるのは「自動テスト」についてです。私が担当した案件で試験対象機器からのデジタル入力、出力をふくめた自動テストを実現する必要がありました。
別案件でデジタル入力、出力の必要が無いパソコン単体で完結する自動テストは経験済みだったため、ある程度システム構成は想像することができました。このようなデジタル入出力があるシステムの自動テストを実現するためにどのような事を検討し、設計したかを本メルマガでご紹介できればと思います。

そもそも世間の自動テストにはどのような物があり、歴史はどうなのか？とふと疑問に思い、Googleで検索してみました。
意外にも自動テストの歴史は古くからあり1962年には自動テストに関する論文が発表されている事がわかりました。また自動テストを支援するツールも様々存在していますが、メジャーな開発言語で動作するアプリケーションやWEBアプリケーションなどに片寄っていると感じました。
市販されている自動テストツールも簡単に調べてみましたが、結局自分が求める事ができるのか容易に判断できないという点で、自動テストツールを導入するのは敷居が高く感じます。
一方弊社が扱うプログラムおよびシステムはFA関連のソフトウェアが多く、一般に市販されているような自動テストツールは使えない事が多いという状況も見えてきました。
また自動テストツールを導入する、もしくはアプリケーションやシステムに自動テストの機能を組み込む際には、何を自動化すればもっとも効果的なのか？コストメリットは出るのか？使いやすいか？など検討すべき事が多くあり、非常に奥が深いテーマだと思います。

今回の自動テストではデジタル入力、出力を扱う必要があったため、どのようにPCアプリケーションを使って実現するか考えるところから始まりました。
PCの拡張インターフェースボードにデジタル入力、出力のIOボードを追加してパソコンのみで実現する案と、PLC(programmable logic controllerと呼ばれる。一般的にシーケンサとも呼ばれるリレー回路を組むことが出来る)を使ってPCアプリケーションとPLCを通信させながら実現させる案と2案浮かびました。
私は普段からPCアプリケーションのほかに、PLCを使った仕事をやっている事もあり、パソコンのみで実現する案とPLCを使った場合のどちらが良いか検討しました。
結果、私はPLCを使ったシステムを選びました。理由は本件で扱うデジタル入力信号で速度を求められる入力判定があり、この部分を正確に行うためにはPCの拡張インターフェースボード+アプリケーションでは取りこぼしが出そうだと考えた為です。
またPLCを使うことで、PLC内にプログラムを作成すれば入力信号の判定部分を行わせる事ができ、速度的な問題は解決できると考えた事、他にも入出力の拡張性などPLCの方が有利だったこともあります。

「自動テスト」という名の通り、「あらかじめ設定した条件で試験を自動的に行い、期待する結果と比較してその結果を残す」という動作をします。
弊社では、試験内容を記述する設定ファイルを「シナリオ」、そのシナリオを実行したときに得られる正しい結果を記述する設定ファイルを「期待値」と呼んでいます。これらのデータは自動試験を行う際にはあらかじめ用意する必要があります。
下図１の①のパソコンに自動テスト用アプリケーション（以降自動テストアプリと略します）と、④の試験対象機器を制御するためアプリケーションを動作させておきます。
自動テストアプリにシナリオを読み込ませ、実行することでシナリオに記述した通りの動作を③のPLCや、④の試験対象機器を制御する各アプリケーションに指示します。
PLCや各アプリケーションは自動テストアプリから受け取った指示どおりに動作し、その結果を自動テストアプリに返します。
シナリオが実行された結果、デジタル入力や出力なども同時に動作し、試験対象に接続された機器からもその動作状態がデジタル入力側に結果として返ってきます。その結果を自動テストツールで収集し、期待値と比較して試験正常、異常という判断をする流れになります。

図1. 自動テストシステム構成概要

下図２のように自動テストアプリにはシナリオファイルと、期待値を読み込ませます。
試験開始すると自動テストアプリからPLCや試験対象機器制御アプリケーションにシナリオに記述されたとおりに動作指示を出した結果はログとして自動テストアプリに帰ってきます。
その結果と期待値を突き合わせて試験OK、NGを判断します。

図2..自動テスト処理概要

今回私が担当した自動テストは技術的に難しいところはありませんでしたが、これまで私が得たPLC知識とPCアプリケーションの知識をうまく組み合わせて設計するという点で難しさがありました。
PLCを使う事で入力ユニット、出力ユニットなど任意の構成にすることができますが、そのような部分をどのように汎用性を持たせるか？という設計部分に注意しながら作業していました。
たとえば試験対象機器の設定変更などで入出力の意味合いが変更になった場合を考えました。対象機器からの出力信号Aの意味や出力端子が変わってしまうかもしれませんし、入力端子についても同様です。そのような場合にプログラムを変更、ベースとなる試験シナリオを修正するのは骨が折れる作業となります。そのような場合も考慮して設定ファイルだけで入出力の位置が変わっても吸収できるように考慮しています。
他にも自動テストを使う担当者が、たまたまPCアプリケーションをメインとする担当者だった場合、PLC側のスキルが不足しているとこの自動試験の仕組みや環境について敷居が高く感じられたりする場合も考えられます。
使う人の事も考えながら、機器構成が変わった時にどうすれば簡単にテスト環境を変えられるかなど機能面と作りやすさ、不適合が出にくいシンプルさや汎用的にとバランスを取りながら設計するのが難しかったです。

PLC側と通信するためには各PLCメーカーが提供している通信ドライバや公開されている仕様を元に通信処理を作成する、もしくはサードパーティ社製品の通信ドライバを使って対応する場合があります。
今回の場合は、通信ドライバを新規作成するメリットは無いと考え、Roboticsware社のFA-Engineを使用して、イーサネット通信することにしました。このFA-Engineを使う事で、通信処理を新規作成する必要はなくなり、かつ約100機種のPLC通信に対応していることもあり他機種への移植も簡単です。
またFA-EngineではPLCのデバイスに名前（タグ）を付けて扱う事ができるため、PLCが変わってもタグを使ってデバイスにアクセスする設定にしておくことで、使用するPLC機種が変更になった場合でも少ないプログラム修正で対応することができます。

自動テストはパソコンが自動的に行う試験のため、人が行う試験とは違って疲れたり、集中力が散漫になり試験結果を誤って記述してしまうという事がありません。
そのため同じテストを延々と何回も繰り返す事できます。
たとえば同じ試験項目書を見て試験を担当者Aさん、Bさん、Cさんでやった場合、試験内容及びそのボリュームによって結果が異なる事がありえます。Aさんは同じ試験を飽きずに試験できる能力はあるが、一方Bさんはすぐに飽きてしまう。Cさんは試験項目書に書いていない事まで気にして、こういう場合はどうかな？このようにしたらどうだろう？と試験するなど結果が異なる要素がいろいろあります。
たとえばCさんのように試験項目書に書いていない事も考慮しながら試験できれば自動テストと比べても品質は良くなる可能性がありますが、なんといっても自動試験の結果は機械的に処理されるため、その人の気分や体調、その他の環境に左右されることなくシナリオ通りに実施した結果を何度でも正確に記録します。
ただし自動テストを行うためには、あらかじめどのように試験を行うのか記述する「シナリオ」と試験を行った結果、どのような結果が得られたら試験正常とする「期待値」が非常に重要です。
このシナリオと期待値が適切に記述していなければ、自動テストを行ってもその結果で品質を担保できないというような状況にもなりえますが、このシナリオと期待値についてもある程度、自動生成する仕組みを用意しています。

自動テストの仕組みや、構想は私が考えたものではありませんが、最初に自動テストの話を聞いた時には「とても素晴らしいシステムだ」と思いました。
機械的にできるところは、機械にまかせて、どんどん自動でテストしてくれ、結果もきちんと残る。さらに人の負荷も減らし、テスト結果にブレが無いというのはとても素晴らしいと思います。
ただ自動テストという言葉に馴染みの無い人がこの言葉を聞くと、「人がかかわる事がなく完全な自動化」を思い浮かべる人もいると思いますが、それを目指すことは非常に難しい（予算や開発期間、様々なテストケース想定したシナリオや期待値の自動生成など色々な問題点があります）です。そのため弊社では必ず人が判断する手作業のテストも組み合わせて行っています。
私が対応した自動テストについては、使いやすさという点ではまだ課題も改善点も多くあります。
今後も自動テストを担当する機会はあると思いますので、より良い自動テストの仕組みを考える事と、自動テストを使う事で空いた時間は、人しかできない創造的な事に時間を使えるようにしていきたいと思います。

−以上−