以下本発明を実施するための最良の形態について図面に示す実施例を参照して説明する。なお以下では携帯電話やPDA等を検査対象機器とする例について説明するが、既述の機器、装置、及びその他類似の構成を有する機器、装置についても本発明を適用できることは明らかであるので、そのような機器についての説明は省略する。
以下本発明の実施例を説明する。なお、図示し、説明する実施例は、外部からの物品接触による入力事象として、例えばボタンの押下、つまみの回転、タッチパネルへの接触・描画入力、音声入力、カメラ等からの画像信号入力を含む外部入力、また、コネクタからの有線信号入力、電波、赤外線による無線入力に対応して内部状態が変化し、内部状況の変化に伴い、画像、音声を含む外部出力を送出する出力事象を変化させる出力手段を備えた機器を検査対象とする。
また、以下では、擬似的又は実際的に発生させて前記検査対象機器又は検査対象装置の機能をチェックする手段、すなわち、外部入力に対応する出力を前記機器に対して発生する擬似入力手段として複数の操作ボタンの一つを押下可能な押下手段を有するボタン操作手段を例としているが、これは適宜の自由度(例えば、3軸、6軸)を有するロボットで、複数のボタンを順次押下するものでも、多数のボタン操作手段を有するものでもいずれであってもよい。また図示の例のロボットには限定されず、さらには平面的に配設されたボタンを操作するものだけでなく、特に多軸のロボットを使用して、立体的に配置されたボタンやつまみを的確に操作することができるようにしたものも含み、いずれにしても図示の例のものには限定されない。
さらに、検査のための擬似入力を検査対象機器又は検査対象装置に対して印加する擬似入力手段は、検査対象機器が、つまみの回転、タッチパネルへの接触・描画入力、音声入力、カメラ等からの画像信号入力を含む外部入力、また、コネクタからの有線信号入力、電波、赤外線による無線入力前記外部入力である場合には、これらに対応する出力をなすものとすればよい。
図1は、本発明に係る機器、装置の機能チェック装置の一実施例を概念的に示す斜視図である。本実施例装置は、判定、検査しようとする評価対象機(図示の例ではPDA)1を予め定めた状態にセットし、PDA1の表示部であるLCDパネル3を撮像し、LCDパネル3の画像を得るカメラ4、PDA1のLCDパネル3に表示される操作ボタン画像又はPDA1が備える機械的操作ボタン(以下では特に必要がないかぎりこれらを総称してキーボタンという。)5・・・の一つを、押し下げ可能なレリーズ6を押下手段として複数有するプランジャーユニット7により押し下げ、プランジャーユニット7の動作をコンピュータ8で制御するとともに、この動作制御に対応するLCDパネル3の表示内容の可否を判断する等の制御を行う。図中9はモニタで、カメラ4で得たLCDパネル3の画像やコンピュータ8からの信号に基づく画像の表示手段となる。なおコンピュータ8は、ハードウェアとしてはビデオキャプチャーボード、入出力用ボード、サウンドボード、イーサネット(登録商標)ボードあるいはこれらと同等構成品を備えるものとし、ソフトウェアとして、後述する携帯電話自動評価システムソフトならびにOSソフト、そして必要に応じてテキストエディタ、ワードプロセッサ、データベースソフト等を内蔵するものが好ましい。またキーボード、マウス、ネットワーク端子(端末対向テスト用)、プリンタ等をもシステム構成に含ませることができる。なお図中10はプランジャーユニット7を駆動するためのロボットで、図示の例ではXY軸移動タイプでレリーズ6も単一のものであるが、後述するように、レリーズ6に代わるプランジャーを多数備えたユニットも使用される。したがって、ロボット10も図示のタイプのものに限定されず種々公知のロボットを採用できる。
図2は検査対象機器を携帯電話とした場合に使用するアダプタユニット2とレリーズ6に代わるプランジャーを多数備えたプランジャーユニット20を示す斜視図である。携帯電話1は、図示の例では折り畳み型のもので、LCDパネル3を有する表示部11と、キーボタン5を有する操作部12とからなるが、検査対象となる携帯電話としてはこのタイプのものに限定されず、表示部11と操作部12に対してそれぞれ外側からアクセスできればストレートタイプのもの、フリップタイプのもの、等どのようなものでも対象とすることができる。なお本発明は、対象機器を携帯電話1に限るものではなく、PHS、PDA、ゲーム機、ノートブック型のパーソナルコンピュータ、カーナビゲーション装置、パネルディスプレイ装置等の機器であり、いくつかの操作ボタンが設けられていて、これらを操作するようになっているものであれば種々の機器に適用できる。
またアダプタユニット2は背面カメラ2aを備えており、この背面カメラ2aによって折りたたみ式の携帯電話1の背面(折りたたんだ状態では正面)に位置することになる図示しない液晶ディスプレイのテストも自動で行えるようになっている。
このアダプタユニット2は、折り畳み型の携帯電話1のLCDパネル3の表面をカメラ4の光軸に対して垂直面をなすようにセットするためのベース部21と、その状態でカメラ4の光軸に対して所定の角度をなす携帯電話1の操作部12をセットできる傾斜部22と、図示は省略するが、傾斜板22との間に携帯電話1の操作部12を挟んだ状態で並行またはほぼ並行にセットするレリーズガイドパネル23、これらを支持する一対の側板等からなる。なおストレートタイプやフリップタイプの携帯電話等においては、図示の例のようにベース板21と傾斜板22に角度を付けて構成する必要がないことが多いので、アダプタユニット2の構成は図示の例に限定されず、対象機器の形状、構造に合わせて形成すればよい。なおレリーズガイドパネル23は、評価対象とする携帯電話1の操作部12のキーボタン5の数等に合わせてレリーズ6を挿入する孔を有するとともにかつ対象機器に合わせて交換できるようになっている。またレリーズガイドパネル23には、携帯電話1のマイク(図示せず)に対応させた位置に孔(図示せず)を設け、この孔の位置にスピーカを取り付けできるようにしてある。
なお、既に述べたプランジャーユニットや、XYタイプのロボットは、評価対象機器としては最も多く利用されるものとなっているが、プランジャーユニットタイプのロボットを使用すると、同時押し、早押し、開閉、背面液晶のテストが行える。一方、XYタイプのロボットを使うと評価機器が変わっても簡単に取り外し、固定ができ、機体のタイプの変更がある場合にもすぐに対応できる。またなお、携帯電話の開閉センサーを利用して、擬似的に携帯電話を閉じた状態を作り出すことで開閉テストを行うこともできる。さらに、基地局シミュレータと連携することで、発呼、着呼、割り込み着信、電波受信状態変化、海外端末の検査も行える。
図3、図4は、携帯電話を保持するためのアダプタユニット2の変形例を概念的に示す斜視図であり、図3は、複数の移動可能なあるいは位置固定の支持部材101で、蓋部102を開いた携帯電話1を保持し、着脱可能なゴムヒモなどの弾性部材103でホールド性を高め、携帯電話1を押さえた状態を示している。
複数の支持部材101は、位置固定の一対のガイド支持部材101a、101aと、それらの軸線方向で位置を可変とするようにスライド可能に差し渡して取り付けた二つの親スライダ101b、101bと、それぞれの親スライダ101b上にそれらの軸線方向で、すなわち親スライダ101bのスライド方向とは直角に交叉する方向でスライド可能に取り付けた子スライダ101cと、親スライダ101bと平行でかつ位置固定にガイド支持部材101a、101a間に設けた保持用支持部材101dから構成してあり、親スライダ101bが携帯電話1の底面を支持し、子スライダ101cが携帯電話1の側面を支え、保持用支持部材101dが携帯電話1の保持性を向上させる支持部材として構成してある。
なお、図示の実施例では、子スライダ101cを載せ得る親スライダ101bが2つしか設けていないが、例えばこれを4つに増やし、そのうち一つで携帯電話下部の高さを可変に支え、もう一つで携帯電話1の本体1aではなく蓋部102のLCDパネル3部分側の側部を押さえるものとする。残りの2つは図示の実施例と同じ役目をはたす構成とするとよい。
また子スライダ101cのスライド部品を付け替え得るようにし、以下の3種類を必要に応じて交換可能とすることもできる。
(1)携帯電話1の高さ方向とサイド方向の両方を押さえるもの(図示の実施例)
(2)携帯電話1のLCDパネル3部分のサイドを押さえるもの(様々な高さのLCDパネル3部分が考えられるので、それらに対応できるように、例えば10cm程の高さのあるものにするとよい)
(3)携帯電話1の高さ方向のみを支えるもの(図示の実施例と同じ高さで、携帯電話1の特に本体部分1aの側面に設けられるサイドボタンやケーブルの邪魔にならないような形状とすることが好ましい)
また上述のようなサイドボタンを押しても先端部品がぶつからないように、子スライダ101cの高さを例えば1.5cm程高くしても良い。
また子スライダ101cは、例えばノギスと同様の構造のものとすることができるが、その構造の場合、歯車を使用しているため携帯電話1を挟んだときに少しガタがあり、片方を固定しても反対側ががたついてしまうことがあり得る。サイドボタンを押した場合は少しのガタがカメラ画像などに影響するので、しっかりと携帯電話1の両サイドを固定する必要がある。例えば子スライダ101cをネジ止めしてその位置を固定する構造とすることができるが、一つのネジでは上述のようなガタを無くすことが難しい場合は、ネジ止めを2箇所で行ってもよい。
上述のように、子スライダ101cをガイド支持部材101a、101a間のセンターに合わせるためのテンションをかけるために、また携帯電話1のLCDパネル3側が上がらないように、上からゴムヒモなどの弾性部材103で押さえつけるように固定しているが、弾性部材103は、子スライダ101bを構成する部品101baに穴を開け、ここに弾性部材103に設けた球状等の部材を嵌入させて引っ掛ける。全ての子スライダ101cの部品にこの穴101bbを空けておき、弾性部材103をどこにでも取り付けられるようにするとよい。なお図示の実施例ではゴムヒモなどの弾性部材103を用いているが、これに代えてバネを採用することもできる。
子スライダ101cの開く横幅は、戴置する携帯電話1が大きいものでも固定できるようすると、近年続々と発売されているPDAタイプのものや、ターンタイプと称されてLCDパネル3を有する表示部11が横向きに回転するタイプ等のような種々のタイプのものにも対応できるようになる。
なお、固定用のネジにはPCのケースに使われているような、ドライバーを使わなくても締結が可能なネジを採用することが好ましい。また子スライダ101cの位置を変える場合には、ネジが完全に外れなくても緩めるだけで移動できるようにすることが好ましい。また、親スライダ101bに目盛を振るなどして、子スライダ101cを所定の位置に再度固定できるようにすることが望ましい。
さらに、携帯電話1の本体1aの端部を抑える固定の支持部材101e、101eは、携帯電話1のタイプ、具体的には端部形状、端部構造の違いに対応できるように、ベースにネジ止めする構造等としておいて、交換できるようにすることが好ましい。
図5はカメラ4等を装備するためのベースユニット30の側面図である。このベースユニット30は、ベース板31と、カメラ4やマイク32を搭載するためのタワー部33とからなり、ベース板31上にはピン等(図示を省略する)を設けてアダプタユニット2を位置決め搭載可能とし、タワー部33には、光軸が垂直下方を向くようにかつ上下動可能にカメラ4を取り付けるとともに、携帯電話1のスピーカ13に対応させてマイク35を設けてある。なお、カメラ4の光軸はもちろん垂直下方以外の方向へ向けても良く、それに合わせてアダプタユニット2等の取り付け、配置形態を変えればよい。なお、カメラ4の位置を可変させる機構も備えているが説明を省略する。
既述のように、プランジャーユニット7は、レリーズ6を複数本、詳細には評価対象とする携帯電話1のキーボタン5の個数以上の本数を有し、これらを選択的に駆動できる装置である。駆動装置そのものは公知であるので説明は省略する。またレリーズ6は、図6に示すように、チューブ61とその中を通したピン62からなるいわゆるレリーズワイヤタイプのものであるが、図示のように、レリーズガイドパネル23の孔25への着脱が容易に行えるように、チューブ61先端に設ける金属管部63のネジヤマ64を全長にわたらずに基部近傍のみ設けてある。なお基部にはロックネジ65と調節ネジ66とが設けてあり、ピン62の飛び出し長さを調節できるようにしてある。ただしこのタイプのレリーズでは、ピン62の飛び出し長さが長いほど確実にキーボタン5に届くようになるが押す力が弱くなる。なお、各ユニット、カメラ等の配線、駆動系、信号伝達系等々についての図示及び説明は省略する。
本実施例装置を、アダプタユニット2に載置した携帯電話1のキーボタン5に対してプランジャーユニット7の所望のレリーズ6を駆動してキーボタン5を押し下げ、この押し下げによって変化するLCDパネル3をカメラ4により撮影し、所望のキーボタン5の押し下げに伴って設計、製造時に設定した通りの画像がLCDパネル3に表れるか否か等を判定するものとして以下説明する。
図7は、モニタ9にメイン画面として表示させる画面の内容を示す図である。この画面は、カメラ4により撮影したLCDパネル3の画像3aと、例えばデジタルカメラ等で撮像して予め得ておいた判定、検査対象となる携帯電話1の全体平面画像1aとを合成して示している。なお、
次に本実施例装置における評価の流れを説明する。
評価は、
(1)機種ファイル作成(ボタン設定、LCD画面調整)
(2)シナリオ作成(設計書や仕様書(期待値画像とテスト項目)を用意して、シナリオを作成する)とデバッグ
(3)1回目の評価(実行、手動判定、画像入れ替え)
(4)2回目以降の評価(実行・自動判定)
という手順になる。
以下、本実施例装置における評価の手順等について詳細に説明するが、まず機種ファイル作成について説明する。
評価の開始に当たっては、最初に機種ファイルの新規作成を行い、携帯電話1の情報を設定する。機種ファイルとは、携帯電話1の個別情報をまとめたファイルであり、画像の調整や携帯電話1のキーボタン5とレリーズ6の対応を設定する。
即ち、予め用意しておいた評価対象携帯電話の画像ファイルを用い、モニタ画面に携帯電話1の全体画像を、もちろん表示部11と操作部12とが見えるように表示させ、これに組み合わせるLCDパネル3に相当する画面を作成する。なお画像ファイルとしては、例えばビットマップ形式で、メイン画面に収まるぐらいの大きさのものを用意する。そして、判定に必要なキーボタン5の設定とレリーズ6の割り当てを行う。キーボタン5は一つずつ設定する。即ち、図8に示すようにメイン画面上で携帯電話1のキーボタン5を囲んで範囲を指定し、キーボタン5の個数分だけ名称とプランジャーユニット7のレリーズ6の番号を指定する。図9は携帯電話情報設定画面、図10はボタン情報設定画面、図11はボタン情報一覧画面、図12はキーボタン5の情報設定でのレリーズ6の番号入力例を示す図である。
キーボタン5に対応するレリーズ6が、メイン画面上に作成したキーボタン5をクリックしたときに動作するかは、実際にプランジャーユニット7を動作させて確認する。例えばメイン画面での操作により作成したキーボタン5をクリックすると、そのキーボタン範囲が青くなるようにして、対応するプランジャーユニットのレリーズが携帯電話のボタンを押すかどうかをチェックする。既述の機種ファイル編集画面で動作確認を行うようにすることもできる。
図13は、特殊操作手順設定である携帯電話を待ち受け画面に戻す操作(リセット)、携帯電話に供給されている電源から切り電源を投入する操作(強制リセット)、折り畳み式携帯電話の開閉動作ボタンの設定を行う画面を示す。なお折り畳み開閉動作の機能が使用できるのは、携帯電話1が折り畳み式であり、それにアダプタユニットとプランジャーユニットが対応しており、レリーズ6で例えば磁石を用いた開閉機構の操作ボタンを押せる場合であり、これにより実際には携帯電話1を開閉せずに(図示の実施例では既に開いてしまった状態で)検査、評価することができる。
以上のように設定してきた機種ファイルは、適宜の名称でコンピュータ8が内蔵しまたは外部手段として有する記憶媒体に保存する。この保存した機種ファイル、即ち作成済みの機種ファイルは修正できることはもちろんである。図14は、機種ファイルの編集画面の図である。
図15はモニタ9に表示させるLCDパネル3画面の調整画面である。画像の調整は、必要があれば歪み補正データの取得、補正データに基づいた画像補正、補正後画像の微調整、の順に行う。また必要ならばLCD画面の大きさも調整する。図15には、LCD枠の設定部分、LCDオフセットの設定部分も示す。LCD画面の調整画面での調整が終了し、必要があれば画像の補正を行い、補正後画像の台形補正を行う。図16は、補正後画像の確認画面である。画像の色調や明るさ補正も行える。また補正後画像の微調整として、画像の台形補正を行え、基準となる画像をもとにLCD画面の大きさ、傾きの微調整を行う。
台形補正は、図17に示すキャリブレーションシート40を基準にカメラ4の焦点距離、歪み具合などのパラメータを求め、それを補正データとして画像を補正するものである。補正値を取得するには、携帯電話1にキャリブレーションシート40を乗せてカメラ4で撮影し、メイン画面に表示されているキャリブレーションシート40の画像の黒い四角、点がはっきり見えるようにする。ついでキャリブレーションシート40を取り除いて携帯電話1のLCDパネル3の画面を撮影する。図18は歪み具合取得ウィザード画面の図である。歪み具合を取得する前に、まず携帯電話1のLCDパネル3画面の大きさとして縦、横サイズの測定値を入力し、歪み具合取得ボタンを押して歪み具合の取得を開始し、補正後画像として表示する。
次にシナリオ作成について説明する。
図19は、シナリオ作成編集画面を示す図である。この画面は、シナリオ表示用のシナリオリストボックス50と、コマンド設定タブ51・・により切り替え可能な画面となっている情報設定部52からなる。
シナリオ作成には、まずキーボタン5の操作コマンドをシナリオリストボックス50に入力する。次いでキーボタン5の押下条件を情報設定部52で設定する。ここでは、複数押し(同時に複数のキーボタン5を押下するコマンド)、押下時間(携帯電話のボタンを押下する時間の設定、押下間隔(1つのコマンドが終わってから次の処理に移るまでの間隔)を設定する。評価環境番号ラジオボタンは、評価環境の番号の設定するもので、対向試験を行う設定で使用する。また折り畳み部開閉は、折り畳み式携帯電話の開閉動作ボタンの押下間隔を設定する。もちろん、この機能が使用できるのは、折り畳み式携帯電話のアダプタユニットと折り畳み式携帯電話の開閉動作ができるプランジャーユニットを用意した場合のみである。さらに、再生、制御、単体シナリオ呼び出し、リモートシナリオ呼び出し(対向試験で対向先のコンピュータでシナリオを実行させるコマンド)、待ち、繰り返し、停止、判定の各コマンドを設定する。判定コマンドは、画像の期待値を取得し、その場で判定(即時判定)を行い、判定結果によってシナリオ実行を続けたり停止したりするためのものである。なお取得した実測値の判定は後述する確認画面で行うが、この判定コマンドを用いると、その場で判定し、判定の結果が期待した通りでなければシナリオの実行を中断することができる。また一つのシナリオ内で別のシナリオを入れ子状に呼び出すことを可能とするシナリオ呼び出しコマンドも設定できる。図20は、その複数呼び出した例を示す図である。
図21は、期待値設定タブの内容を示す図である。この画面では、携帯電話1の反応を記録するコマンドを入力できる。記録できるのはLCDパネル3の画面の画像と、マイク35で録音した音声である。なお図中53は期待値画像表示スペースである。
画像取得コマンドは、期待値画像を設定し、実際の画像と比較することでテストを行うためのものである。期待値画像には、例えばjpg、bmp、emf等の形式のファイルを設定する。また実測値を記録するタイミングとして、記録を開始するタイミングを指定するとともに、画像指定、判定範囲設定を行う。一方、音声取得コマンドは、マイク35で集音した音声を録音するもので、キーボタン5を押下した時の音(DTMF音)を確認画面で判定することができるようにするものである。
なお図19の入力支援部は、名前や電話番号などのひらがな、数字、アルファベット、記号を携帯電話1で入力するシナリオを自動生成するための部位である。またこの部位のキーボタン情報ボタンを操作すると、図22に示すボタン対応表が表示されるようになっており、文字入力に使用する携帯電話1のキーボタン5と、機種ファイルで登録したキー名の対応を設定できる。
そして、作成したシナリオが正しく動作するか否かをデバッグを行うことでチェックする。なおデバッグ画面は、後述する実行画面(図23)と同様である。チェックの結果は、例えば図24に示すようなエラーレポートとして出力する。
次にシナリオの実行について説明する。
図23は実行画面を示す図である。この画面は、シナリオリストボックス80、実行時指定部81、実行状況表示部82からなり、実行状況表示部82は、シナリオ一覧リストボックス83、カレントシナリオボックス84、期待値画像表示部85、実行LCD画像表示部86からなる。シナリオリストボックス80には、実行中のシナリオあるいはこれから実行するシナリオの名称を表示する。実行時指定部81は、キーボタン5の押し時間に関する設定を表示する部位、期待値を記録するタイミングの設定を表示する部位、停止レベルを表示する部位を含む。またシナリオ一覧リストボックス83は、選択しているシナリオとシナリオ集を表示し、カレントシナリオボックス84は、シナリオ一覧リストボックス83で選択しているシナリオを表示する。期待値画像表示部85は、画像取得コマンド実行時、期待値として設定されている画像を表示し、実行LCD画像表示部86は同じく撮影した携帯電話1のLCDパネル3の画面を表示する。なお図24はエラーレポートを示す図である。
上述のような携帯電話自動評価システムを2セット使用して対向試験を行うことができる。対向試験では、相手方システムのコンピュータとLANで接続し、接続した側のシステムで同じシナリオを自動的に実行する。即ち、2台の携帯電話自動評価システムの、片方をサーバーとし、他方をクライアントとして、サーバーがクライアントを制御する試験となる。そして、サーバー側でシナリオ実行をすると、サーバーがクライアント側のプランジャーユニット7を操作することで2台の携帯電話1を操作できる。したがって、別の携帯電話1に電話をかけて、かけられた携帯電話機で電話をうけるというような検査を行うことができる。
なお対向試験であるか否かにかかわらず、シナリオを自動実行させ得るが、途中での手動による一時停止、停止、再開が可能であり、シナリオをステップごとに実行させるステップ実行、途中から自動実行に切り替える半自動実行も設定できる。
またなお、現在実行中のシナリオに、指定した周期ごとに別のシナリオを実行させる、いわゆる割り込み処理を可能とすることによって、携帯電話を操作中にメールを受信するといった実際の使用状況に近い試験を自動的に行える。
ある携帯電話について1回目のシナリオを実行した後、確認(手動判定と画像入れ替え)を行う。即ち例えば一度手動で判定を行い、判定結果が良ければ画像を入れ替える。まず、画像を確認し、期待値画像と実行画像が一致するかどうかについてシナリオの全ステップを判定する。複数のシナリオを実行するときは、全シナリオについて全ステップを判定する。そして期待値画像が直接画面を撮影した画像でない場合は、画像判定が行えないので期待値画像の入れ替えを行う。入れ替えを行うと、次に同じシナリオを実行したときには入れ替えられた画像が期待値としてデータベースに登録され、画像の自動判定を行うことができる。また用意した期待値画像のある一部分だけを自動判定に使用したいときは、判定範囲設定を行うことができる。
なお判定範囲にはデフォルト判定範囲と個別判定範囲を設定でき、前者ではすべての画像に同じ判定範囲を適用し、後者では画面上で範囲を設定された画像だけに適用する。判定範囲と除外範囲も設定でき、判定範囲と除外範囲を組み合わせることで、複雑な形の判定ができる。コンピュータを用いたシステムであるので、もちろん判定範囲の座標指定等も可能である。
そして2回目以降のシナリオ実行の結果は、期待値画像が入れ替えられていれば、自動判定ができる。自動判定機能は、用意された判定範囲に基づいて、期待値画像と実測画像が一致するかどうかを自動的に判定するものである。また、期待値DTMF音の周波数と実測DTMF音の周波数が一致するかどうかも自動的に判定できる。
なお、図示は省略するが、折り畳み型の携帯電話でかつキーボタン5を有する操作部12の外面にもう一つの表示パネルを備えるものあるいは同様の構造のPDA等が近年開発、市販されている。これらを評価対象とする場合には、開いた状態でLCDパネル3の表示を評価することと、閉じた状態で操作部12外面の表示パネルを評価することを個別に行うこと、あるいはもう一つカメラを用意して、開いた状態とした携帯電話等の二画面を二つのカメラで同時にかつ個別に撮像して評価することのいずれでも可能である。
また上述してきた実施例の機能を総合し、人間の判断に近い曖昧さを兼ね備えた画像判定ができるようにすることができ、期待値画像と実測値画像の微妙な違いを許容して画像判定を行えるようになる。例えば、これによりカメラ4の再設置の際のセットアップ時間を大幅に短縮することができるようになる。また画像判定が難しかった45インチ大画面TVのような機器が検査対象であっても自動判定が可能になる。なお、ファジィ理論の画像計測への応用は種々の方法が提案されており、検査対象に応じて等種々の条件を勘案して適宜の方法を選択し、上述した画像処理に組み込めばよいので詳細な説明は省略する。
以下、画面の表示内容の評価方法について説明する。本例では、図25に示すように、静止画、動画を評価する他、図26に示すように携帯電話等の器具が発生する音声についても判定を行う。
まず画像の評価の概略を説明する。本例では、図25に示すようにまずカメラ4からの画像のキャリブレーションを行う(S101)。このキャリブレーションは、システム全体で一回行えばよく、システムを構成する他の機器、装置の機能チェック装置のカメラが取得した画像に適用できる。
次に、各機器、装置の機能チェック装置において、検査対象携帯電話1の操作ボタン5を操作し(S102)、携帯電話1のLCDパネル3に画像を表示させる。この画像を前記カメラ4で取得し静止画、動画別に画像判定を行う(S104)。
一方、音声判定においては、本例ではDTM音、BT/RBT音、及びメロディについて判定を行う。この判定は、図26に示すように、携帯電話1の操作ボタン5を操作し(S201)、発生した音声をマイク35で取得し(S202)、音声信号を一端機器、装置の機能チェック装置に格納し、その格納した音声に対して判定を行う(S203)。まず、機器、装置の機能チェック装置の画像取得用の撮像装置のキャリブレーションについて詳しく説明する。
このキャリブレーションでは、図17で示したキャリブレーション用シートの中央に表示されている7×7個の黒い点の座標を撮像画像から読み取る、そして、実際のキャリブレーション用シートと撮影した画像の点とを比較することによりカメラの撮影特性データを取得する。
まず、キャリブレーション用シートの画像を複数枚、例えば20枚撮影する。これらの撮影に際しては、キャリブレーション用シートを様々な位置・角度に配置して撮影する。これにより、様々な条件下での、キャリブレーション用シート画像の点の位置座標を取得する。
次に、実際に検査する携帯電話の液晶画面と平行においたキャリブレーション用シートの画像を撮影する。すべてのキャリブレーション用シート画像から点の位置座標を取得し、これらのデータからカメラの焦点距離、放射状歪みの中心位置、歪み度合いを計算する。これは画像処理ライブラリによって計算される。画像処理ライブラリは市販のソフトウェア(例えばMVTec製HALCON(商標))であり、前記各要素を計算するものである。そして、携帯電話画面に乗せて撮影した(最後の)キャリブレーション用シート画像の歪みがなくなるよう補正を行う。
本例では、キャリブレーション用シートから点の位置を検出するのに、当装置の被い内で撮影するため暗い画像になってしまう。画像処理ライブラリの中にはシートの矩形位置を取得する関数があり、指定した特定の色のラインで表示される矩形のみを取得することができる。
この関数には閾値を引数として渡すが、これが高すぎると暗い画像では検出することができない。逆に閾値が低いと誤った領域を取得してしまう。また、ライブラリの戻り値では矩形を取得できたかがわからない。失敗したまま続けていくと後からエラーとなることがあるので、ここで正確に矩形領域を取得する必要がある。
このため、暗いムラのある画像でもマークを検出することができるように、高い閾値から序々に閾値を下げながら、前記と同じ矩形を取得する関数を実行することとする。取得された領域が最も正方形に近い形になったところで止めるようにする。
次に、キャリブレーション用シートの画像からカメラの歪みを修正するためのパラメータを取得する。カメラの焦点距離、放射状歪みの中心位置、歪み具合、最後のキャリブレーション用シートの画像に合わせて変換したカメラ座標を画像処理ライブラリで計算する。
以上より求めたパラメータを用いて携帯電話の画像に変換をかける。前記の値を用いて、最後に取得したキャリブレーション用シートと、携帯電話のLCD画像に対して変換をかける。これでキャリブレーション用シートは歪みのない正方形で表示される。
さらに、中央に適度な大きさで表示されるよう変換をかける。最終的にはキャリブレーション用シートではなく、携帯電話のLCD画面が中央に歪みなく表示されるのが目的なので、適切なサイズで中央に表示されるよう変換パラメータを化させながら変換を繰り返す。
そして、他の機種の基準画像に合わせて他の機器、装置の機能チェック装置で画像が使用できるよう、補正をかける。ユーザーは基準となる画像を1枚選択し、自動補正ボタンをクリックするだけで、現在の画像が基準画像と同じサイズ・明るさになるよう補正される。
基準画像に合わせて自動補正をかける。即ち、位置、回転、拡大・縮小、縦横比が基準画像と一致するようアフィン変換をかける。カメラで撮影している画像から静止画を取得するときにこの補正をかけている。
次に、基準画像に合わせてカメラの明るさ・コントラストを調整する。静止画の明るさを後から変えると、元の画像は例えば0〜255のデータしか持っていないので、例えば明るすぎて白く飛んでいる場合は正確な色の値が分からない。よって、撮影後の画像に変換をかけるのではなく、カメラの設定値を直接変更する。カメラの明るさ・コントラストを変化させながら連続して撮影・比較することにより適切な明るさ・コントラストに合わせていく。
次に静止画の比較について説明する。
本発明に係る機器、装置の機能チェック装置の画像処理では、入力画像としてどのような画像が来るか予想がつかない。したがって、入ってきた画像によって最適な判定ロジックを選択し、ミスのない判定を行う必要がある。具体的には、画面の細かい画像、暗い画像が入ってきても判定しやすい明るさに補正し、ある程度の面積を持った領域の違いを判定する。
LCDの明るい領域を例えば以下のように取得する。
図27に示すように、画像のヒストグラム(0〜255)を求め、それを大きく3つの山に分ける。そのうち暗い方から数えて1つ目の山と2つ目の山を分ける境目の値で閾値処理を行う。
また、山が偶数にしか分かれない場合は中心をとる。1つ目の山と2つ目の山を分ける間をとる理由は、本例では、画像を周りの黒い枠と明るいLCD部分に分けたいので、黒いところが除ければよい。しかし、中には光が漏れて灰色に明るくなってしまう場合もあるので、このような方法を採用する。
画像の明るさが大きく異なる場合に、それらを同じ程度の明るさに合わせるか、または明るさが違うためにNGと判断するかは、設定ファイルの値で決めることができ、ユーザーが変更することも可能である。
ここで設定した値より実際の画像の明るさが異なっていた場合は位置補正をしないまま画像比較し、一致しなかったという結果を出す。
基準画像から位置合わせのためのテンプレートを作成基準画像と実測画像のずれをなくすため、後工程で位置補正を行う。そのためのパターンマッチング用テンプレートを基準画像を元に作成する。(画像処理ライブラリで計算)テンプレート作成用の画像を選択する。
本例では、LCD領域の淵(幅3ピクセル)の領域に画像を絞り込んだものを登録画像としている。これにより正確かつ速い位置補正が可能となる。
次に元画像のコントラストが低い場合はコントラストを上げるための補正を行うこれは、単にガンマ補正をかけるのではなく、図28に示すように、色平均値より明るい部分はより明るく、暗い部分はより暗く補正する。画像平均値と最大値・最小値から明るさ強調の変換テーブルを計算して、コントラストの補正を行う。色合いの微妙な画像の判定に使用する。このようにコントラストを上げると、途中でここから上は明るくし、ここから下は暗くするといった変極点が生じる。
次に、基準画像に合わせて実測画像の色補正を行う。このとき、多少違う画像でも同じように色補正されるよう細かい画像やエッジ領域を除いた部分で調整する。基準画像と実測画像で色の平均値が閾値(ユーザが指定したパラメータ)だけ異なる場合は補正をかけないようにする。さらに、テンプレートを基準にパターンマッチングを行う。先に作成したテンプレートを基準にパターンマッチングを行う。これは、画像処理ライブラリで計算する。
なお、繰り返し判定するときに、2度目以降は1回目の位置情報を利用して速く判定する。1回目の基準画像の位置データをとっておき、2回目以降の判定ではそれを読み込んで画像マッチングすることで位置合わせを行う。
位置合わせを行った結果、大きくずれてしまった場合、またユーザーが指定したよりも移動してしまった場合は元の位置に戻して、そのまま重ねて判定する。
基準画像と実測画像をそのまま重ね合わせて判定を行う。色が大きく違う、位置が異なるなど何かしらNGであると思われる要素があった場合は、位置補正を行わないで単に画像差分をとった結果を出す。なおこの判定では、人間の判断に近い曖昧さを兼ね備えた画像判定とすることができる。いわゆるファジー制御を用いた判定機能により、期待値画像と実測値画像の微妙な違いを許容して画像判定を行えば、カメラ再設置の際のセットアップ時間を大幅に短縮することができる。
位置合わせで取得したデータに基づいて画像・判定範囲に変換をかける。位置合わせが成功した場合は、データに基づいてアフィン変換をかける。この処理は画像処理ライブラリで行う。そして、ユーザーが指定した判定対象範囲に基準画像、実測画像の絞り込み判定を行う。
次に、基準画像と実測画像の差分をとる。本例ではRGB画像とグレイ画像の4種類ごとに基準画像と実測画像で画像差分をとる。元画像のコントラストの低いものについては、差分を強調する処理をかけることが有効である。この処理は取得したRGB、Grayごとの差分画像を加算してよりはっきりさせるものである。
差分画像に閾値処理でNGと期待される領域を取得する閾値(70くらい、ユーザからも設定できる)から255の間で閾値処理を行う。基準画像と実測画像で異なる部分が抽出される。
本例は、多数の画像をターゲットに、ロジックやパラメータを少しずつ変化させながら結果を比較していき、閾値として最も良かった結果のものを採用した。画像の明るさによって閾値を変えることが望ましい。基準の閾値は設定ファイルから読み込むが、画像が暗めの場合はそれに合わせて閾値を下げる。逆に明るい場合は上げるようにする。
次にノイズ処理を行う。閾値処理で求めたNG領域(画像差分領域)からノイズを削除し、本当にNGである領域のみを残す処理である。まず、NG候補領域から大きくNGだとわかる部分だけを抽出する。単に閾値より明るい部分をNG領域とするのではなく、明るい部分が含まれていてかつNG候補となる白い部分の周辺面積が大きいものだけを最終的なNG領域とする。
例えば、図29に示す場合、左の領域は面積が広くても明るさの最大値が低いのでNGと判断されない。右の領域は中心の明るさが高くなっているので、この領域全体がNGとして検出される。
前記処理により、NGと判断された領域の面積がゼロであればOK、1以上の場合はNGと判断され、NG領域が表示される。なお図30は本実施例に係る携帯電話の検査装置での静止画像判定処理動作中の領域特定処理を示す図である。
ノイズ処理に関しては、その他、比較対象画像を8方向に0.5ピクセルずつ動かし、位置合わせがほんの少しずれただけでノイズが増えるので、位置合わせを行った後さらに0.5ピクセルずつ移動させて、最もノイズの少なかった位置を最適とする方法や、NGと判断された領域のうち、その領域のエッジの情報から「ずれ」と「違い」を判断する方法を採用することができる。
具体的には図31に示すように、かつ上述してきたように、画像サイズの判定(S111)、LCD領域の画像取得(S112)、明るさ判定(S113)、位置合わせ用テンプレート作成(S114)、コントラスト調整(S114)、色補正(S116)、テンプレートを基準にパターンマッチング(S117)、位置確認(S118)、画像判定範囲の変換(S119)又は基準画像と実画像を重ね合わせて判定(S120)、画像を判定範囲に絞り込む(S121)、基準画像と実測画像との差分抽出(S122)、差分画像に閾値処理で不良(NG)と期待される領域を取得(S123)、ノイズ処理(S124)、そして結果出力(S124)となる。
次に本発明に係る機器、装置の機能チェック装置の動画判定処理について図32ないし図37に基づいて説明する。図32は、動画処理を示すフローチャートである。本例では、期待値、実測値はそれぞれaviファイルとする。期待値と実測値は静止画に切り出したとき、同じサイズとする。ただし撮影時間は異なっても差し支えない。さらに、画像の周囲の枠が黒く表示されていることが望ましい。
まず、カメラで撮影され格納された動画ファイル(AVIファイル)から、動画の読み込みを行う(S141)。そして動画を1フレーム毎(30f/s)に静止画(ビットマップ)に切り出す。これは画像を読み出した撮像装置の取得フレーム数である。
次に読み込んだ画像の平均化を行う。これは、図35に示すように画像を1枚ずつ読み込み、2つ前の画像(図33(a))と1つ前の画像(同(b)と、着目した画像(同(c)を合成し画像3枚の平均画像を取得するものである(S143)である。そして、3枚の画像の平均画像を1枚の画像(図33(d)として扱う。これにより期待値と実測値の切り出しのタイミングがずれていても平均化することによりなめらかな動きになる。
さらに後の工程で期待値と実測値の同期を合わせた後に比較を行うのに使用するデータを取得する(S144)。そして、平均化した画像をRGB、Grayの4色に分ける(S145)。平均化した各画像を、RGBとGray画像に分ける。Gray画像は人間の目で見たのと近いように0.299*red+0.587*green+0.144*blueとする。そして、グレイ画像を半分のサイズ(面積で4分の1)にしてメモリ上にとっておく(S146)。取得したグレイ画像を半分の倍率に縮小し、メモリ上に確保しておく。この際面積では元のサイズの4分の1とする(S147)。RGB、Grayごとに1つ前の画像と引き算で画像差分をとる。より明るくなった部分とより暗くなった部分を求め、そのトータルグレイ値(面積とグレイ値(0〜255)の積分値)を取得する(S148)。これは、以下の(1)〜(3)の処理による。
(1)RGB、Gray画像ごとに現在の画像から一つ前の画像を引いて、一つ前の画像より明るくなった部分を画像として取得する(図34(a)、(b)、(c))。
(2)同様に一つ前の画像から現在の画像を引いて、より暗くなった部分を画像として取得する。
(3)取得した差分画像のトータルグレイ値(白く表示される部分の面積と明るさの積分値)をRGB、Grayごとに取得する。
これで、動画を静止画に切り出したときの1枚の画像あたり、8個のトータルグレイ値が取得できる。明るくなった画像と暗くなった画像がそれぞれRGB、Grayの4チャンネル分あることとなる。
次にRGB、Grayごとに取得した差分画像を合わせる。この画像に閾値処理をかけて差分のあった領域を取得する(S148)。これは、以下の(1)〜(2)の処理による。
(1)RGB、Grayごとに取得した差分画像をRGB、Grayの4チャンネル分足す。
(2)この4チャンネル分足した差分画像にパラメータ(約50)で閾値処理をかけ明るい部分を領域として取得する(このパラメータはユーザー側で指定できる)。
これで、カラー画像としてより明るくなった部分の領域とより暗くなった部分の領域が取得できる。
より明るくなった画像と暗くなった画像を合わせ、閾値処理をかけ前後の画像で差分のあった領域を取得する(S149)。この領域の重心を求める。これは以下の(1)〜(4)の処理による。
(1)(S148)で取得したより明るくなった部分を示す差分画像とより暗くなった部分を示す差分画像を足して一つの画像にし、一つ前との差分画像を取得する。
(2)パラメータ(約50)で閾値処理をかけ明るい部分を領域として取得する。(このパラメータはユーザー側で指定できる)この領域が一つ前の画像との差分領域になる。
(3)(2)で取得した領域の重心位置を求める。前の画像と差がなく、差分の領域面積がゼロの場合は画像の中心位置を代入する。
(4)より明るくなった部分を示す差分画像とより暗くなった部分を示す差分画像をそれぞれ半分のサイズに縮小し、メモリ上に確保しておく(面積では4分の1)。
動画のずれ時間を求め、実測値と期待値の撮影のタイミングを合わせる(S150)。ここで、期待値と実測値の撮影のタイミングが異なる場合や撮影時間が異なる場合でも判定できるよう、時間を合わせる必要がある。これは以下の(1)〜(4)の処理による。
(1)期待値と実測値を1枚ずつ、ずらしながら(S147)で取得したトータルグレイ値を比較していく。期待値と実測値の時間が重なっている間だけ、1コマごとにトータルグレイ値の差分をとり、その合計値を取得する。
(2)期待値と実測値のタイミングが合ったところではこの差分が極小値となるので、1つ前の値より小さく、1つ後の値より小さいところが候補となる。そして(f(n+1)−f(n))+(f(n−1)−f(n))が最も大きくなるnを求める。この差分が最も大きかったところを求めるずれ時間とする。
(3)RGB、Grayの4チャンネルで求められた時間が異なる場合は8個のデータの候補が多い順に選ぶ。
(4)RGB、Grayごとに取得された時間の候補が一致しない場合はすべてのチャンネルにてデータを合計し、その合計値が最も高かった場所(最も前後との差があった時間)をずれ時間とする。
次に、実測値と期待値のずれを合わせた状態で、実測値と期待値のデータを比較する(S151)。即ち、ここでは、前の画像と比較して移動した部分の領域の重心位置を比較する(S152)。これは以下の(1)〜(3)の処理による。これは本例において、比較1となる。この比較1では、差分領域の重心位置を求め、場所の違いを求めるものである。
(1)期待値と実測値の同期を合わせてからS159で求めた期待値と実測値の各画像の重心位置を比較する。X座標、Y座標ごとに差を求め、それぞれが画像の幅・高さに対
してどれだけの割合かを求める(1−Xの差分/判定範囲の幅、1−Yの差分/判定範囲の高さ)。
(2)前記(1)を、切り出した画像分求めて平均値をとる。この値が低いと一致率が低いということになる(1に近いほど差がないということになる)。
(3)ここで求めた値(0〜1.0)を比較結果としてresult1とする。
図35(a)、(b)で示した画像は、異なる個所でアイコンが点滅している画像を示ししており、この比較1により違う画像であると判断することができる。
より明るくなった領域と暗くなった領域ごとに、期待値と実測値の移動領域を比較する(S153)。これは以下の(1)〜(5)の処理による。
これは本例中の比較2となる。この比較2では、移動領域の差分をとり、動きの違いを見る。
(1)期待値と実測値の同期を合わせてから(S148)で求めた期待値と実測値の領域の差分をとる。
(2)次に、「期待値または実測値で移動のあった領域」を取得する。期待値、実測値共に輝度の増えた画像と減った画像(計4種)をすべて足して合成する。これに閾値処理をかけ、明るく表示される部分を領域として取得する。この領域に膨張収縮処理をかけ、ある程度の面積を持つ領域に絞る。これを「動きのあった領域」とする。
(3)輝度の増えた画像、減った画像ごとに期待値と実測値の差分を取得する。期待値と実測値が同じように変化している場合はこれらの差分をとることで、相殺されて領域がなくなるが、移動個所の異なる場合は差分をとってもその領域が残る。
(4)前記(3)の画像にパラメータ(約50)で閾値処理をかけ明るい部分を領域として取得する(このパラメータはユーザー側で指定できる)。輝度の増えた画像と減った画像の領域を足してひとつの移動差分領域として取得する。
(5)前記(2)で取得した「動きのあった領域」に対する(4)で取得した期待値と実測値の差分領域の割合を求める。次に、前記(2)で求めた「動きのあった領域」が画像の判定対象面積に対してどれだけの割合かを求める。この面積が小さい場合は(5)で取得した差分領域の割合よりさらに小さくする。処理が必要とされるのは、動きのあった面積が判定範囲の面積にたいして小さいというのは、動き自体が少ない動画となるからである。つまり、期待値と実測値の動画部分が異なったところで差は小さいということになるからである。以上より「動きのあった領域」に対する期待値と実測値の差分領域の割合(0〜1)を1から引くと、期待値と実測値が同じように動いた割合(一致率)を求めることができる。この値は大きいほど(1に近いほど)一致率が高くなる。
(6)前記(5)の値をすべての画像で求め、画像枚数で割ることにより画像1枚あたりの平均値を求める。ここで求めた値(0〜1.0)を比較結果result2とする。
図36(a)、(b)で示した2枚の画像をこの比較2により違う画像であると判断することができる。
縮小した画像の画像差分をとることで比較し、背景も含めて画像全体がどれだけ異なるかを比較する(S154)。これは以下の(1)〜(2)の処理による。これは本例中の比較3となる。この比較3では、画像の絶対値で判定する、即ち本比較3では静止状態での違いを見るのである。
(1)期待値と実測値の同期を合わせ、合わせた時間同士でS156で取得した期待値と実測値の画像の差分をとる。まず期待値と実測値で位置合わせを行う。具体的には期待値を基準に実測値画像に対してパターンマッチングを行い、見つかった位置にアフィン変換で実測値を移動させる。期待値と実測値の時間が重なる場合はすべての画像において位置合わせを行う。位置合わせを行った後、期待値と実測値の画像差分をとる。
(2)前記(1)で取得した期待値と実測値の差分領域から、S163−(2)で取得した動きのあった領域を引く。これによって背景(静止画部分)のみの違いを取得することができる。差分画像に閾値処理をかけ、のこった面積が大きいほど一致率が低くなる。
(3)この面積は100%異ならなくても人間の目では充分異なっていることが分かるので、結果(<1)を2乗した値を答えとする。
(4)ここで求めた値(0〜1.0)をさらに2乗し、比較結果としてresult3とする。なお、画像の絶対値比較は他の処理では行われない。他の処理はすべて相対位置での比較のため、画像全体の明るさが異なるときなどは比較しても同じと判断されてしまうからである。
図37(a)、(b)で示した2枚の画像をこの比較3により違う画像であると判断することができる。
そして、以上の比較要素を掛け算し、最終結果を得る(S155)。期待値と実測値の同期を合わせてから前記のresult1、result2、result3の結果を取得し、これらの積をとる(値は、0〜1.0となる)。これに100をかけて%に対応させた結果を返す。
そして、結果(0〜100)を返す(S156)ことにより、この値が閾値以上である場合、合格とし、閾値未満である場合不合格とする。そして、次に本発明に係る機器、装置の機能チェック装置の音声判定を図38ないし図40に基づいて説明する。本例では、DTMF判定(図38)、BT/RBT判定(図39)、メロディ判定(図40)の3つの判定を行う。
まず、DTMF判定を、図38に基づいて説明する。
DTMF(Dual Tone Multi Frequency)は、電話のボタン(0〜9、*、#)ごとに割り当てられている、2種類の周波数からなる音声信号である。DTMF判定では、マイクで収音した実測値を解析し、実測値に含まれる音声信号の種類が、期待値として指定されているDTMF番号(0〜9、*、#)と一致するかどうかを判定する。
DTMF音は、それぞれ予め定められた固有の周波数の組合せであるため期待値として利用するのは各DTMFの周波数情報であり、期待値としての音データは保持しない。各番号に対応する周波数情報は、図41に示す通りである。
以下に判定の手順を示す。
まず、押しボタンを操作し(S211)実測値の中で最大音量を記録している周波数を2点取得して(S212)、この値を期待値WAVEファイルを読み込む。
次に、読み込んだWAVEデータをFFT(Fast Fourier Transform:高速フーリエ変換)にかけて、周波数毎の音量レベルを表す音量データ配列を取得する(S213)。すると、配列のインデックスが周波数帯域を表し、インデックス毎のデータが音量レベルとなる。
次に取得した音量データを、DTMFの周波数帯域が記録されていると思われる帯域を低域と高域の2つ(650Hz〜970Hz、1150Hz〜1500Hz)に分ける(S214)。この2つに分けた帯域から、それぞれ最も大きい音量レベルが記録されているデータを1点取得する(S214)。この2つのデータをDTMF音の実測値の周波数とする。
さらに、期待値として指定されているDTMF番号の周波数(2点)と、実測値から割り出された周波数(2点)の低域同士と高域同士でそれぞれ比較し(S216)、固定の許容誤差範囲(±20Hz)内であれば一致していると判定する(S217、S218)。この許容誤差外であるときは不良であると判定する(S219)。次に、BT/RBT(ビジートーン/リングバックトーン)判定を図37に基づいて説明する。ここで、BT/RBT(ビジートーン/リングバックトーン)とは、それぞれ以下の意味を持つ。即ち、BT(ビジートーン)は、電話の話中状態を表す音声信号(プーッ・プーッという音)(・は無音)であり、RBT(リングバックトーン)は、電話の呼び出し状態を表す音声信号(プルルルル・プルルルルという音)である前記の「プーッ」、もしくは「プルルルル」の部分をONデータと呼び、「・」の部分をOFFデータと呼ぶ。
BT/RBT判定では、マイクで収音した実測値を解析し、実測値に含まれる音声信号の種類が、期待値として指定されているBT、もしくはRBTと一致するかどうかを判定する。
RBT、BTにはそれぞれ特有の鳴動パターン(OFFデータとONデータの間欠パターン)があるため、そのパターンを数値化したものを期待値として利用する。よってこの処理で利用する音データは実測値のみとなる。
以下に判定の具体的な手順を示す。
まず、押しボタンを操作して(S221)鳴動音を取得する(S222)し、期待値WAVEファイルを読み込む。次に、読み込んだWAVEデータをFFTにかけて、周波数毎の音量レベルを表す音量データ配列を取得する(S223)。この処理で、配列のインデックスが周波数帯域を表し、インデックス毎のデータが音量レベルとなる(S224)。
次に、音量データ配列の内容がBT/RBTの周波数帯域(400Hz±20Hz)と一致するかどうか調べる(S225)。所定の許容誤差範囲内で一致する場合はONデータであると判断し、そうでない場合はOFFデータであると判断する。これを時間軸に沿って調べて、ONデータとOFFデータの数を算出した鳴動パターン配列を取得する。
次に、期待パターンと取得した鳴動パターンを比較する。これには、まず実測パターンの有効部分を認識する。このとき、実測値の最初にOFFデータが含まれている場合はその部分を切り捨てて、ONデータから始まる部分をデータの有効部分とみなす。
そして、期待パターンと実測パターンを、実測パターンの有効部分から時間軸に沿って比較する。それぞれの鳴動間隔ごとのON/OFFデータの要素数の差が指定の誤差範囲未満であれば、その位置は指定トーンのパターンの一部であるとみなす。
そして、期待パターンと同じパターンが一定範囲持続している場合に、一致していると判定し、そうでない場合は不一致とする。
次に、図38に基づいて、メロディ判定の説明をする。本例でメロディとは、前述のDTMF、BT/RBT以外の、音階変化のある音データのことをいうものとする。
メロディ判定では、マイクで収音した実測値を解析し、実測値に含まれる。音データが、期待値として指定されている音データと内容がどれくらい一致しているかということを一致率で表す。
一致率を求める処理、及び一致率を求めるためのデータ生成には、一般に使用される音声ライブラリ(例えば、Animo社のVoiceBaseIIライブラリ)を用いる。判定結果の合否は、システムの既定値またはユーザーの設定した一致率閾値を判定処理で取得した一致率の値が上回るかどうかで合否判定を行う。
この処理で利用する音データは期待値、及び実測値の2つとなる。まず、期待値と実測値とをもとに、それぞれの処理データを取得する。即ち、期待値、実測値のWAVEファイルを読み込む(S231)。次に、無音区間検出(音声ライブラリ使用)を行い、有効データの開始位置を取得する(S232)。このとき、期待値と実測値の有効データ長をもとに、処理データの単位(1フレーム)ごとのデータ量を決める。
次に、処理データを窓関数(音声ライブラリ)にかけ、FFTフィルタバンク分析(音声ライブラリ)を行い、マッチング処理用の処理データを取得する(S233)。次に、DP法(音声ライブラリ)による期待値と実測値の比較処理を行い、比較結果の距離データを取得する(S234)。そして、取得した距離データから一致率を算出する(S236)。
さらに、算出された一致率が、指定の一致率閾値よりも大きい場合に一致していると判定し、閾値未満の場合不一致と判定する(S236〜S238)。
これらの処理を予め定めたメロディについて行い音声判定処理は終了する。
次にPDA1に対する自動テストを図42〜図44を参照しつつ説明する。
上述した携帯電話の場合と同様に、まず環境設定として、ロボット10のレリーズ6が押すタッチパネル(LCDパネル3)に表示されているボタン5やハードウェアとしてボタン5等の位置のティーチング、カメラから撮影する画面の設定、ボタン表示位置の設定を行う。評価機の設定を切り替えて複数の機種を扱うことが可能でる点も同様である。次にコンピュータ8付属のマウス8aの操作でタッチパネルに表示されているボタン5やハードウェアとしてボタン5の擬似的操作を行う。すなわち、図43に示すような擬似画面上をマウスクリックすると、ロボット10のレリーズ6がその位置まで移動し、実際に検査対象機であるPDAのタッチパネルを押下する。例えばロボットがアイコンを探して押下するので、ポップアップメニューのようにタッチパネル上のボタンの位置が毎回変わる場合でも大丈夫であり、押下位置を画像で登録することでボタンの表示位置が変わっても、それを認識してロボットが押すことができる。コンピュータ8は、上述のようなマウスクリックや擬似動作、実動作でシナリオ作成する。具体的には、これも上述のように、テスト手順をテストシナリオというスクリプトに記述する。高度な分岐・条件文もマウスクリックで簡単に記述することが可能である。すなわち、擬似画面上でボタンを操作すると自動でシナリオが書き込まれる。そして、シナリオに従ってロボット10が評価機1を操作し、カメラ4で画像を撮影する。操作内容や画像は全てデータベースに登録される。
ついで画像の判定を行う。これは、静止画判定、OCR判定、SEARCH判定、動画判定、音声判定など自動で判定を行う。「と」、「i」、「j」など、微妙な違いも確実に判定できることが望ましい。そして結果確認を行い、テスト結果一覧からすぐに不具合箇所を見つけ、結果報告として、必要な情報を、テスト結果をCSVファイル出力機能や印刷機能を利用して、簡単に出力すればよい。
なお、既に述べたプランジャーユニットや、XYタイプのロボットは、評価対象機器としては最も多く利用されるものとなっているが、プランジャーユニットタイプのロボットを使用すると、同時押し、早押し、開閉、背面液晶のテストが行える。一方、XYタイプのロボットを使うと評価機器が変わっても簡単に取り外し、固定ができ、機体のタイプの変更がある場合にもすぐに対応できる。
次に評価対象機器をカーナビ、カーオーディオとした例を図44を参照して説明する。使用するロボットのタイプは、6軸ロボット200(図44A)とプランジャーユニット20(図45B)が考えられるが、いずれを用いてもタッチパネル3の操作はもちろんのこと、ダイヤル202をつまんで回すこともできるので(プランジャーユニット20については機構の図示を省略してあるが、簡単な構造のアダプタ204を用いることで可能となる)、ボリュームの調整も可能である。三次元操作で画面が傾いていても正面から画面を押すことが可能である。
また6軸ロボット200を用いれば、CDチェンジャー206の操作(図44C)も可能である。評価対象機器のテストと併せてCD208の出し入れを自動で行うことができる。テスト対象機器がカーナビ210の場合のCD208やDVD212の出し入れを6軸ロボット200が自動で行い、CDチェンジャー206やカーナビ210自体もコンピュータ8から制御できる。
なお、車関連の検査としては、図46に示すように電源の制御が行える。低電圧状態やイグニッションをONにしたときの電圧状態など、QCからプログラマブル電源を操作することにより、電圧状態を変えたテストができる。図示の例では、供給電圧9.5Vでディスプレイの表示に問題が無く、供給電圧7.5Vでディスプレイの一部の表示が消えた(図中矢印Xで示す部分)例を示す。
また、図47に示すように、CANシミュレータ300との連携もなし得る。すなわち、CANインターフェースを持つ車載機器の開発、検証時に広く使用されているCANシミュレータ(商品名:CANoe)との連携テストが行える。コンピュータ8側でCANシミュレータを制御することにより、CANの環境を変更させながら実機を操作するといった連携試験を行える。
また話し言葉判定にも使用できる。すなわち、人の話し言葉を認識して自動判定を行い、これによって、カーナビの音声案内や、外国語対応した組込み機器のマルチランゲージ試験の自動化を実現可能とするのである。図48の例では音声案内などをマイク302で録音し、録音した音あるいは音声が期待値の波形と同じものであるか否かを判定している。
なお、以上の説明で検査対象機器としてきたタッチパネル等がRGB入力で出力する画像データをそのまま取り込むことができる。歪みのない高い解像度の画像を取り込むことができるので、画像判定も高い精度で行うことができ、大きなディスプレイを搭載している機器にも対応可能となる(図49参照)。またプログラマブル表示器ではタッチパネル3を操作するだけでなく、各種PLC3bと連携稼動し、より実際の環境に近いテストを実行することもできる(図50参照)。さらに、タッチパネル3の画面3a上に表示された文字をカメラ4で撮影した画像を基に、OCRにより文字認識を行い、見つけ出した文字の座標位置にロボットのアームやプランジャーを誘導することもできる(図51参照)。図示の例では、実測画像(図51A)中の「証明書」という文字列を認識し、タッチパネル3の画面上で文字列に対応する位置において実際にロボットがアームやプランジャーを作動させるのである。
さらに本発明は、図52に示すように、赤外線リモコン操作を行えるデジタル家電機器400に対して本例装置が赤外線信号を制御するように構成できる。図中401はコントローラ、402は赤外線発信器である。すなわち、通常使用する赤外線リモコンに代わって本例装置が赤外線信号を制御する。学習リモコン機能を有するコントローラ401に赤外線信号を登録しておくことで、学習リモコンと同じ操作が可能となる。本例装置のモニタ9の画面上で学習リモコンと同じ操作を行うと、コントローラ401を介してそれに対応する赤外線信号が赤外線発信器402から出力される。そして、赤外線入力に応じて変化する画面の内容をカメラ又はRGB入力で取り込めば上述のような機器、装置の機能チェック用のシステムを構成できる。また図52の例の変形例になるが、例えば図53に示すように、物理的に操作するプランジャーユニット7とコントローラ401と赤外線発信器402による赤外線制御を合体させることで、DVDデッキのようなデジタル家電機器400を赤外線信号で操作しつつ、実機についているボタンをプランジャーユニット7のレリーズ6で押すといった試験を自動化することができる。
図54は操作内容がそのままテストシナリオになる機能を有する赤外線リモコン500とそのディスプレイ内容の一例を示す。赤外線リモコン500のボタン501を押すと、例えば「ボタンを押す」というコマンドがシナリオに記述されるようにして実現できる。
また本発明の装置は、Windows(登録商標)アプリケーションの自動評価に使用できる。図55はそのような例を示す。このような構成とすることにより、例えばWindows(登録商標)をインストールしたパソコン600のマウスやキーボード601のような入力機器からの入力を擬似的に自動操作することができ、また他のマニピュレーターと同時に使用することができるので、XYロボット10で携帯電話を操作しながらPCとの連携試験を行うといったことが可能となる。
図55、図56を用い、Windows(登録商標)をインストールしたパソコン(以下クライアントPCという)600を用いて行うアプリケーションの連携試験の流れを説明する。
まず、本発明の実施例装置でクライアントPC600を操作する。本発明の実施例装置のモニタ9のディスプレイに、クライアントPC600のデスクトップ画面を擬似画面として表示させる。この擬似画面を本発明の実施例装置側のキーボード8aやマウス8bで操作すると、同時にクライアントPC600が操作されます。操作内容は自動的にシナリオとして入力される(図56A)。
次にロボット10とクライアントPC600の両方を操作する。図56(B)に示すように、画面を切り替えることでロボット10とクライアントPC600の両方の擬似画面を操作でき、ロボット10の操作とクライアントPC600の操作を組み合わせることで、例えばクライアントPC600から携帯電話1を操作して音楽検索をするなど、クライアントPC600とテスト対象機器である携帯電話1を連動させたテストを行う。そして、図示は省略するが、テスト結果をデータベースに保存し、期待値と実測値を自動で比較・判定する。評価対象機器である例えば携帯電話1側とクライアントPC600側の両方の画像が判定される。判定結果は例えばデータベースに保存すればよい。
また本発明の実施例装置は、図57(A)に示すように、1台の本発明装置と1台のロボット10を対応させて制御することも、図57(B)に示すように、1台の本発明装置で2台のロボット10、20を制御することも可能である。2台のロボット10の制御を予め作成した1本のシナリオで行えば、シナリオの維持管理の手間が軽減さ、また、制御に使用するコンピュータ8が1台で済むので、導入コストも低減できる。なお図示のように、ロボットは異なる機種でも、同一機種でも、いずれでもよい。
図58に示すように、本発明では、携帯電話1等の検査対象機器又は検査対象装置に対して使用される組込みシステム向けの開発支援を行うCASEツール(例えばZIPC:商品名)で作成した状態が変化する事象に基づいて少なくとも擬似入力手段を協調動作させ、この協調動作に基づいて、検査対象である携帯電話1等に対する擬似入力の手順を作成する構成も可能である。
本発明は、以上説明してきたようなものであるが、外部からの物品接触による入力は、例えばボタンの押下、つまみの回転、タッチパネルへの接触・描画入力、音声入力、カメラ等からの画像信号入力を含む外部入力、また、コネクタからの有線信号入力、電波、赤外線による無線入力に対応して内部状態が変化し、内部状況の変化に伴い、画像、音声を含む外部出力を送出する出力手段を備えた機器を検査対象とすることができる。
また、適宜の自由度(例えば、3軸、6軸)を有するロボットを用いて複数のボタンを順次または同時に押下するようにすることができる。特に多軸のロボットを使用した場合には、立体的に配置されたボタン、つまみを的確に操作することができる。
さらに、擬似入力手段としては、検査対象機器が、つまみの回転、タッチパネルへの接触・描画入力、音声入力、カメラ等からの画像信号入力を含む外部入力、また、コネクタからの有線信号入力、電波、赤外線による無線入力前記外部入力である場合には、これらに対応する出力をなすことが簡単にできるようになる。
そして、検査対象機器が携帯電話やカーナビの場合の試験には、外部に接続されたプログマブル電源、電波発生器、シグナルジェネレータ、測定器などの機器やこれらのコントロールソフトと接続した環境でテストをする場合があるが、本発明では、外部機器制御の機能として、シナリオの中にこれら外部機器への制御用命令文を記述することにより、それぞれの機器の制御を行う外部制御モジュールソフトと交信を行い、連携した試験を行える。この場合、外部制御モジュールは、接続機器ごとに用意し、本システムときめられたプロトコルにより、通信を行って外部制御モジュールより外部機器を制御し、または値を得て本発明のシステムに渡すこととなる。
次に本発明に係るソフトウェアツールとして、常時監視ツールについて説明する。常時監視ツールは大きく分けて以下2つの機能で構成されている。
(1)カメラから動画を撮影し、各コマにおいて画像判定を行い、取得した画像を保存する機能(記録ツール)
(2)保存した動画の内容を確認する機能(ビューア)
図59は、常時監視ツール画面イメージを示す図である。図59(A)は記録ツールから得られる画像の例を示し、図59(B)は常時監視ツール画面のイメージ図である。本例では、常時監視ツール画面はいわゆるPC用等で用いられているビューワソフトの外観を呈しており、図59(B)の図中矢印Aはファイル操作部分、矢印Bは画像ファイルを時系列で示す表示部分、矢印Cは監視対象画像をファイル名と時間データとともにサムネイル表示する部分、矢印Dは画像をサイズを変更するスライダである。
ここで常時監視の動作を説明すると、まず録画、記録を、
(1)カメラまたは画像信号出力可能な機器から画像データを取得し、任意のフレームレート(1〜20fps程度)でPCに画像データを保存するとともに、カメラから取り込んでいる画像をリアルタイムに表示する(図59(A)参照)。
(2)なお対応可能な画像入力は、例えばUSBカメラからのUSB端子経由の入力やDFG/SV1のS端子経由の入力が挙げられるが、これはもちろん拡張可能である。
(3)なお先に説明してきた自動検査システム側から常時監視ツールの制御(監視開始と停止)が可能であるが、本ツールは独立したソフトウェアとして単独でも使用できる。
次に画像の自動判定について説明する。
(1)動画を録画しながらコマごとに画像の自動判定を行うことができる。なお、自動判定を行うとその分撮影スピードは落ちてしまうので、どの判定を実行するか任意にユーザーが選択することができる。撮影した画像は指定のフォルダに保存され、ノイズ判定などNG位置画像がある場合も任意の指定フォルダに保存される(図59(B)参照)。
画像判定の形態としては、上述した自動検査システムにおける静止画判定(簡易化した判定も可)、フリーズの検出、ノイズの検出が挙げられる。もちろん判定形態も、種々の態様のものを可能にできる。
(2)指定した画像が表示されている箇所を検出できる。この場合、まず設定画面にて複数枚の静止画画像を登録する。動画を1コマずつ切り出し、登録した静止画と同じ画像が表示されている箇所を検出することで、自動的に正誤判定する。例えばブラックアウトの画面を登録することで、動画の中から一瞬だけ暗くなった箇所を「NG」として検出する。また、撮影したデータすべてに撮影時刻が紐付けられていることから、その「NG」画像が表示されるまでの時間を測定することもできる。
(3)フリーズ状態の検出は次のように行う。記録した動画において一定時間変化がない場所をフリーズ状態として検出する。フリーズ箇所が「NG」とは限らないが、長時間録画した動画から変化の無い箇所を表示することで、動画内容の確認を効率的に行うことができる。
(4)またノイズは、信号線から取得した動画データにおいて、一瞬表示されるような画像のぶれや異常表示を検出し、自動的に正誤判定する。通常人が見る動画像はゆっくりと変化していくが、ノイズはコマごとに小さな変化が起こるので、変化速度の違いをノイズとして検出することができる。
次に動画内容の表示について説明する。
(1)任意の区間において動画を複数枚の静止画に切り出し、サムネイル表示機能とあわせてすぐに目的の画像が表示されている部分を視認することができる。また、画像撮影の時刻も表示される。
(2)画像は時間別のフォルダに格納され、画面上の時間表示箇所で任意の時刻をマウスで選択すると、その時刻周辺の画像が選択され表示される。また、画像は時系列に沿って確認することができる。具体的には、一定時間間隔ごとに静止画を並べて表示し、その隣に帯状の色表示を行う。画像が撮影されている時間帯は例えば水色、画像がない時間帯は例えば灰色、現在表示している時間帯は例えば青色とする。このような色帯状部分をマウスクリックすると、その時間帯の画像が表示される。
(3)また記録した画像データを元の動画と同様に、任意の位置から連続的に再生ができる。カメラで撮影している状態と同じように連続的に動画として再生することができる。動画再生は任意の位置で開始・停止が可能である。
結果表示について説明する。
(1)判定結果も時系列に沿って確認することができる。一定時間間隔ごとに並べた静止画の隣に色帯が表示されるが、そこで判定結果も確認できる。例えば、「NG」のある箇所では帯表示の隣に文字で「NG」と表示され、画像判定の種類ごとに色がつけられる。NG表示をマウスクリックすると実際に「NG」結果が出た画像とその周辺画像がサムネイルに表示される。また、ノイズ検出の場合はどこがNGになったかという情報が別画像(NG位置画像)で保存されており、サムネイルの画像上で右クリックするとNG位置画像表示を選択することができる。
(2)上述した自動検査システムソフトウェアがインストールされたPC上で常時監視ツールの結果確認ができる場合は、上述した自動検査システムのテスト結果データベースと連携しているため、例えば上述した自動検査システムでNG判定が出た瞬間、常時監視ツールでどのような画像が表示されていたかといったことを確認できる。
すなわち、
(1)本常時監視ツールは、これまで主に静止画で扱っていたものを、動画のように長時間記録し、それを自動的に正誤判定するものであり、動画を1ファイルとして扱うのではなく、1コマずつ切り出した静止画の集合体として扱うことで、任意の位置から速やかに再生・表示を行い、高速な画像認識を行うことができる。また取得したデータを動画として処理することで、画面表示が「速い」、「遅い」といった時系列に対する変化や性能を判定する機能も取り入れることができる。
また、
(2)組込み機器自動検査システムで用いる場合、組込み機器をロボットで操作し、その操作内容や時刻をすべてデータベースに記録しているので、そのデータと連携して本ツールを稼動させることにより、画面表示とロボット操作内容を時刻で照らし合わせることができる。これにより、例えば画面上にエラー表示が起きた時点でロボットがどのような操作を行っていたかといった内容を一瞬にして確認することができる。
次に、画像内容の高速判定ツールについて説明する。このツールは、
(1)ある操作をしてから特定の画面に遷移するまでの時間を測定するもので、例えば、携帯電話でブラウザボタンを押してからブラウザが表示されるまでの時間を測定したり、
(2)すぐに消えるような画面、例えばプログレスバー、100ms単位のストップウォッチ、バックライトを判定する。
上記のような目的を達成するために、画像取得から判定までの処理を10回/1秒〜30回/1秒程度の速度で可能な機能(コマンド)を上述した自動検査システムに組み込む。この機能は、前記要求に対応するため、画像取得と判定を高速に繰り返すことができるコマンドとなる。また高速に繰り返す必要があるため繰り返し中の画像はデータベースに登録しない。
このツールの機能仕様については以下の通りである。
・機能:画像取得から判定までの一連の処理を指定された期待値が出るまで繰り返す。最大待ち時間になるまで指定された期待値が出なかった場合はNGを返す。
・引数1:期待値(遷移完了時画面の期待値/すぐ消える画像)
・引数2:最大待ち時間 1ミリ秒〜30秒 (省略可)
・引数3:ON/OFF(※PICコマンドのON/OFFと同様)
・引数4:取得待ち時間 (省略可)
・引数5:カメラ番号
・戻り値(#):結果(OK,NG,ERR)
OK(文字列):最大待ち時間内に期待された期待値になった場合
NG(文字列):最大待ち時間期待された期待値にならなかった場合
ERR(文字列):上記に当てはまらない場合
・戻り値(#ELAPSED_TIME);OKまたはNGになるまでの経過時間(ミリ秒)
判定OKの場合:判定OKになった画像を取得した時間−1枚目の画像を取得した時間(ただし取得待ち時間は含まれない)
判定NGの場合:#ELAPSED_TIME≒最大待ち時間(取得待ち時間も含まれる)
判定ERRの場合:判定開始からERRになった時点までの時間
この機能(コマンド)の使用例としては以下のようになる。コマンド名をFPSTLとして、
FPSTL(“期待値”, 5s, OFF, , 0)
SET(RET,$#)
SET(RET_TIME,$#ELAPSED_TIME)
以下の変数については例えば以下について実行時設定にて設定が可能である。
・取得待ち時間のデフォルト値
・最大待ち時間のデフォルト値(@QCSYSTEM_FP_MAX_WAIT_TIME)
・判定精度(@QCSYSTEM_FP_STL_METHOD)
0.HIGH_ACCURACY
判定が高精度(ただし、HIGH_SPEEDに比べて判定速度が若干遅い)
1.HIGH_SPEED
判定が高速(ただし、HIGH_ACCURACYに比べて判定精度が若干低い)
2.AFTER_CAPTURE
最大待ち時間になるまで画像を取得し、その後に判定する(HIGH_ACCURACYと同精度)
・実測値保存フォルダ(@QCSYSTEM_FP_ACQ_PATH)
・実測値を保存するか(@QCSYSTEM_FP_ACQ_WRITE_IMAGE)
・すべてのNG画像を保存するか(@QCSYSTEM_FP_NG_WRITE_IMAGE)
結果表示、すなわち上述のコマンド名FPSTLの実行結果は、結果画面にて、判定結果、経過時間、期待値、最後の実測値、NGの場合のNG画像を参照することが可能である。また、途中経過の画像、判定結果画像は特定のフォルダにすべて格納され、エクスプローラにて参照することが可能である。
このコマンドFPSTLの実現方法は以下の通りである。
上述の検査システムでは、マシンスペック、画像サイズによるが、画像取得、画像判定には1回/1秒程度の判定速度が限界だった。これは画像取得した画像を一旦ファイル化し、データベースに格納し、その後ファイル化した画像を読み込み判定し、結果をDBに格納していたため、主にファイル化とDBアクセスに時間がかかり、1回/1秒程度の判定速度となっていた。ファイル化していた一つの理由には、画像取得するプログラムと、判定するプログラムが別アプリで実現されていたためというものがある。
そのため、本機能(コマンド名FPSTL)では以下のように実現することで極力ファイル化とデータベースへのアクセスの回数を減らし、10回/1秒〜30回/1秒程度の判定速度を実現する。
・画像取得と判定は同じアプリケーション(擬似画面)内で行い、画像の受け渡しはファイルではなくメモリで行う。
・判定をより高速に行うようにするため、判定で使用するモデル画像は事前に作成する。
・同一の期待値で、異なる実測値に対して判定を繰り返すため、変わらない値(判定範囲等)は始めの判定で生成し、繰り返し中の判定では作成済みのデータを使用する。
・判定ライブラリの関数や、判定ロジックで、より最適化できる部分を最適化する。
・実行側のアプリケーション(検査システム)と画像取得、判定アプリケーション(擬似画面)とで必要なデータの受け渡しは、異なるアプリケーションであることを意識しないよう、メモリマップドファイルで実現する。
・途中経過の画像保存は、データベースに格納せず、一旦すべてメモリに蓄え本機能(FPSTLコマンド)終了直前にファイル化を行う。
・本機能(FPSTLコマンド)終了時に結果参照に必要なデータのみDBに格納する。
なお、その他としては、画像処理ツールHalcon(商標)取り込みが可能なカメラ(現状DFG、DFK、UFG)であれば、使用可能である。現行のPCスペックを有し、かつ80万画素まであれば、カメラのフレームレートと同じ速度で判定が可能である。