(57)【要約】携帯通信ユニット（２）をテストするためのテスト装置（１）は、テスト入力データを携帯通信ユニット（２）へ供給すると共に、テストスケジュールに従って少なくとも携帯通信ユニット（２）からテスト出力データを取り出すように適合されたテストユニット（３）を備える。テスト装置（１）は、テスト装置（１）と、テスト装置（１）から離れた遠隔地に配置されているサーバ（５）との間に通信リンクを設けるように適合された無線インタフェースユニット（４）をさらに備える。テストユニット（３）はテスト入力データの少なくとも一部をサーバ（５）から取り出す。さらに、テストユニット（３）はテスト出力データの少なくとも一部をサーバ（５）へ転送する。携帯通信ユニット（２）をテストする方法も開示される。
2010514304.tif 000002
【特許請求の範囲】
【請求項１】
携帯通信ユニット（２）をテストするためのテスト装置（１）であって、
テスト入力データを携帯通信ユニット（２）へ供給すると共に、テストスケジュールに従って少なくとも携帯通信ユニット（２）からテスト出力データを取り出すテストユニット（３）と、
前記テスト装置（１）と、前記テスト装置（１）から離れた遠隔地に配置されているサーバ（５）との間に通信リンクを設ける無線インタフェースユニット（４）と
を備え、
前記テストユニット（３）は、前記テスト入力データの少なくとも一部を前記サーバ（５）から取り出し、かつ、前記テスト出力データの少なくとも一部をサーバ（５）へ転送することを特徴とするテスト装置（１）。
【請求項２】
前記テストユニット（３）は、更新されたテストスケジュールを前記サーバ（５）から取り出すことを特徴とする請求項１に記載のテスト装置（１）。
【請求項３】
前記テスト入力データは、前記携帯通信ユニット（２）のデータ処理ユニットのためのソフトウェアコードを含むと共に、前記テストユニット（３）は、前記テストスケジュールに従って前記ソフトウェアコードを携帯通信ユニット（２）へアップロードすることを特徴とする請求項１又は２に記載のテスト装置（１）。
【請求項４】
前記テスト入力データは、前記携帯通信ユニット（２）とのユーザインタラクションのエミュレーションを行うためのテストケース制御データを含むと共に、前記テストユニット（３）は、前記テストスケジュールに従って前記テストケース制御データを携帯通信ユニット（２）へ供給することを特徴とする請求項１乃至３のいずれか１項に記載のテスト装置（１）。
【請求項５】
前記テスト出力データは、前記携帯通信ユニット（２）においてシステム障害が発生したときの前記携帯通信ユニット（２）のメモリ状態を含むことを特徴とする請求項１乃至４のいずれか１項に記載のテスト装置（１）。
【請求項６】
前記テストユニット（３）は、前記携帯通信ユニット（２）においてシステム障害が発生した場合、前記携帯通信ユニット（２）を再起動することを特徴とする請求項１乃至５のいずれか１項に記載のテスト装置（１）。
【請求項７】
前記テスト装置（１）の少なくとも１つの環境パラメータを表す信号を検出するように適合されたモニタユニット（６）をさらに備えると共に、個々の環境パラメータはそれ自体に関連付けられたインタバルを有し、該インタバル内で前記テスト装置（１）の作動が促されることを特徴とする請求項１に記載のテスト装置（１）。
【請求項８】
前記モニタユニット（６）は、前記テストユニット（３）が停止されているかどうかを検出すると共に、前記テストユニット（３）が停止されていれば、前記少なくとも１つの環境パラメータを表す前記信号に基づいて、前記少なくとも１つの環境パラメータの各々が当該環境パラメータに関連付けられたインタバル内にあることを検出することに応じて、前記テストユニット（３）を起動することを特徴とする請求項７に記載のテスト装置（１）。
【請求項９】
前記モニタユニット（６）は、前記テストユニット（３）が作動中であるかどうかを検出すると共に、前記テストユニット（３）が作動中であれば、前記少なくとも１つの環境パラメータを表す前記信号に基づいて、前記少なくとも１つの環境パラメータのうちの少なくとも１つが当該環境パラメータに関連付けられたインタバルの外にあることを検出することに応じて、前記テストユニット（３）を停止させることを特徴とする請求項７または８に記載のテスト装置（１）。
【請求項１０】
１つの環境パラメータが前記テスト装置（１）の温度であることを特徴とする請求項７乃至９のいずれか１項に記載のテスト装置（１）。
【請求項１１】
１つの環境パラメータが前記テスト装置（１）へ電力を供給する電源の電圧であることを特徴とする請求項７乃至１０のいずれか１項に記載のテスト装置（１）。
【請求項１２】
１つの環境パラメータが、車輌のエンジンが動いているかどうかを示すエンジンモニタパラメータであると共に、前記エンジンが動いているときには、前記エンジンモニタパラメータは当該エンジンパラメータに関連付けられたインタバル内にあり、かつ、前記エンジンが動いていないときには、前記関連付けられたインタバルの外にあることを特徴とする請求項７乃至１１のいずれか１項に記載のテスト装置（１）。
【請求項１３】
前記テストユニット（３）は、
携帯通信ユニット（２）への、前記テスト入力データの前記供給を制御し、少なくとも前記携帯通信ユニット（２）からの、前記テスト出力データの前記検索を制御し、前記テスト制御ユニット（１０）の作動中に第１のトリガ信号を生成するテスト制御ユニット（１０）と、
前記第１のトリガ信号を受信するように適合され、前記第１のトリガ信号が所定の時間の間に受信されなかったことに応じて、前記テストユニット（３）を停止させる制御ユニット（２０）と
を備えることを特徴とする請求項７乃至１２のいずれか１項に記載のテスト装置（１）。
【請求項１４】
前記制御ユニット（２０）は、前記制御ユニット（２０）の作動中に第２のトリガ信号を生成すると共に、
前記モニタユニット（６）は、前記テストユニット（３）への電力供給を制御し、前記第２のトリガ信号を受信し、前記第２のトリガ信号が所定の時間量の間に受信されなかったことに応じて、前記電力の供給を中断することを特徴とする請求項１３に記載のテスト装置（１）。
【請求項１５】
前記テスト装置（１）は、前記テスト装置（１）の地理上の位置を追跡する測位ユニット（５０）をさらに備え、該測位ユニット（５０）は前記テストユニット（３）と作動可能に接続され、かつ、前記測位ユニット（５０）は、前記テスト装置（１）の地理上の座標を含むテスト出力データを生成することを特徴とする請求項１乃至１４のいずれか１項に記載のテスト装置（１）。
【請求項１６】
前記測位ユニット（５０）は全地球測位システム受信機を備えることを特徴とする請求項１５に記載のテスト装置（１）。
【請求項１７】
前記テストユニット（３）には、ソフトウェアコード手段が中に格納されているメモリユニットを備えたコンピュータが実装されており、前記ソフトウェアコード手段は、それが前記コンピュータで実行されることで、
携帯通信ユニット（２）へテスト入力データを供給し、
テスト出力データを前記携帯通信ユニット（２）から取り出し、
前記テスト入力データの少なくとも一部を前記サーバ（５）から取り出し、前記ソフトウェアコード手段が前記コンピュータ上で実行されるとき、前記テスト出力データの少なくとも一部を前記サーバ（５）へ転送することを特徴とする請求項１乃至１６のいずれか１項に記載のテスト装置（１）。
【請求項１８】
前記テストユニット（３）は、少なくとも２つの携帯通信ユニットへテスト入力データを供給し、かつ、少なくとも２つの携帯通信ユニットからテスト出力データを取り出すことを特徴とする請求項１乃至１７のいずれか１項に記載のテスト装置（１）。
【請求項１９】
前記テストユニット（３）は、移動通信ネットワークを介して通信を行うために、前記少なくとも２つの携帯通信ユニットの第１及び第２の携帯通信ユニットを制御することを特徴とする請求項１８に記載のテスト装置（１）。
【請求項２０】
テスト装置（１）と、前記テスト装置（１）から離れた遠隔地に配置されているサーバ（５）との間に、前記テスト装置（１）の無線インタフェースユニット（４）を用いて通信リンクを設けるステップと、
前記テスト装置（１）において、テスト入力データを前記サーバ（５）から取り出すステップと、
テストスケジュールに従って、前記サーバ（５）から取り出された前記テスト入力データを前記テスト装置（１）のテストユニット（３）によって携帯通信ユニット（２）へ供給するステップと、
前記テストスケジュールに従って、前記テストユニット（３）をテスト出力データによって少なくとも前記携帯通信ユニット（２）から取り出すステップと、
前記テスト出力データの少なくとも一部をサーバ（５）へ転送するステップと
を有することを特徴とする携帯通信ユニット（２）をテストする方法。
【請求項２１】
コンピュータを備えた電子装置によって実行することで請求項２０に記載の方法を実行するためのコンピュータプログラム。
【請求項２２】
コンピュータを備えた電子装置によって実行することで請求項２０に記載の方法を実行するためのコンピュータプログラムを格納したコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯通信ユニットをテストするためのテスト装置に関する。
【背景技術】
【０００２】
通常テストは電子装置を設計する際の設計手順の重要な一部である。設計手順は通常反復処理となる。テスト中に、設計時のバグや不具合が発見される場合がある。そのとき、次の設計の反復中に何らかの対策を講じて、発見されたバグを解決することが可能となる。しかし、新たなバグが生じることもあり、これらのバグの発見のためにさらに別のテストが必要となる。
【０００３】
テストの複雑さ及びテストに要する時間は、通常、電子装置が複雑になると共に増加する。携帯電話機のような携帯通信ユニットは、ますます複雑な設計で開発されている。例えば、携帯電話機は、通常、例えば、移動通信グローバルシステム（ＧＳＭ）ネットワークや、ユニバーサル移動電話システム（ＵＭＴＳ）ネットワークや、例えば各種のＩＥＥＥ８０２．１１規格に準拠すると共にブルートゥーストランシーバや赤外線（ＩＲ）トランシーバのような短距離トランシーバを用いる無線ローカルエリアネットワーク（ＷＬＡＮ）などのような多数の様々な種類の通信ネットワークにおける通信をサポートする必要がある。
【０００４】
さらに、携帯電話機に与えられる機能の量は、例えば、テキストメッセージの送信、画像の撮影と送信、音楽の聴取、チャット、テレビ電話などのためのビデオ符号化などを行うためますます増大している。この機能の一部は通常ソフトウェアの形で実装されている。したがって、携帯電話機のアナログハードウエア及びデジタルハードウェアと共存し、かつ作動できる必要があるソフトウェアの量は増えつづけている。同時に、アナログ及びデジタルハードウェアの複雑さも増加している。
【０００５】
携帯通信ユニットのテストは、例えば実験室などにおいてコンピュータによりシミュレーションした通信ネットワークにおいて実施することができる。現実の通信ネットワークにおいて生じる可能性がある種々のシナリオのシミュレーションを行うことが可能である。しかし、たとえばこのような通信ネットワークにおいて通信ネットワーク固有の複雑さに起因して生じ得るすべての異なる状況及び問題点を予見することが困難であるという理由のために、このようなテストは効率の良いものではない。
【０００６】
携帯通信ユニットの実地テストは、現実の通信ネットワークにおいて携帯通信ユニットを携帯して移動する人間のオペレータによって実施することができる。人間のオペレータは、ボタンを押したり、ＡＴコマンドを携帯通信ユニットへ送信したりすることによってテストを実施することができる。このような実地テストは、例えば人間のオペレータの上述した役割に起因して、効率が良くないうえに、高コストのものとなる。
【０００７】
欧州特許ＥＰ１５６９４８１公報には、無線データ装置を遠隔地においてテストするための方法及びシステムが開示されている。無線データ装置はインタフェースを介してサーバマシンに接続される。サーバマシンは、インターネット、広域ネットワーク、ローカルエリアネットワークのようなネットワークを介して、あるいは単に２つのコンピュータ間の接続を介してクライアントマシンと通信を行う。クライアントマシンは無線データ装置のグラフィック表示と同一のグラフィック表示を維持する。ユーザはクライアントマシンにおいてキーストロークを入力することができる。次いで、キーストロークは無線装置へ渡される。このようにして、ローカルなユーザは遠隔無線データ装置を制御し、遠隔無線装置に表示される結果を取得することが可能となる。ＥＰ１５６９４８１公報に開示されている、システムに関して無線装置をテストするステップは、クライアントマシン対してキーストロークを与え、リアルタイムでクライアントマシンを介して無線データ装置のグラフィック表示をモニタする人間のオペレータを必要とする。したがって、このようなテストもまた、効率が良くないうえに、コストが高くなることが考えられる。
【０００８】
欧州特許ＥＰ０８３７６１５公報は、第１の位置から離れた遠隔地にある第２の位置から第１の位置においてセルラサービスをテストする方法及び装置を開示するものである。テストセットはテスト携帯電話機とアクセス携帯電話機とを含む。技術者端末は、通信ネットワークを介してテストセットと通信を行うことができる。技術者端末を介して、人間の技術者は、あたかもテストセットと同じ位置にいるかのように、テスト携帯電話機とアクセス携帯電話機とのうちの少なくともいずれかのキーボードの操作を遠隔地から制御することができる。さらに、技術者は、公衆交換電話ネットワーク（ＰＳＴＮ）を介してアクセス携帯電話機と移動体交換センタ（ＭＳＣ）とに接続された電話機によってテストセットへの音声パスを確立することができる。前記電話機を通じて、人間の技術者は、テスト携帯電話機が受信するのと同じオーディオ情報を聞くと共に、テスト携帯電話機が送信する音声情報を生成することができる。上記公報は、テスト携帯電話機又はアクセス携帯電話機自体のテストを目的とするものではないセルラサービスのテストを開示するものである。さらに、テストセットは、人間の技術者が技術者端末からテストセットを制御し、リアルタイムでテスト結果をモニタするように要求する。上記のように、このようなテストは効率が良くないうえに、コストが高くなる可能性がある。
【０００９】
テスト及び検証を行うための複雑さの増大を結果として招くことになる携帯通信ユニットの複雑さの増大に起因して、携帯電話機のような携帯通信ユニットのテストと検証とを行うためのさらに効率の良い手段が必要とされている。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
携帯通信ユニットをさらに効率良くテストする手段を提供することが本発明の目的である。
【課題を解決するための手段】
【００１１】
第１の側面によれば、携帯通信ユニットをテストするためのテスト装置が提供される。テスト装置は、テスト入力データを携帯通信ユニットへ供給すると共に、テストスケジュールに従って少なくとも携帯通信ユニットからテスト出力データを取り出すように適合されたテストユニットを備える。テスト装置はテスト装置とサーバとの間に通信リンクを設けるのに適合した無線インタフェースユニットをさらに備える。サーバはテスト装置から離れた遠隔地に配置することができる。さらに、テストユニットはテスト入力データの少なくとも一部をサーバから取り出すように適合される。さらに、テストユニットはテスト出力データの少なくとも一部をサーバへ転送するように適合される。
【００１２】
テストユニットは、更新されたテストスケジュールをサーバから取り出すように適合されることができる。
【００１３】
テスト入力データは、携帯通信ユニットのデータ処理ユニットのためのソフトウェアコードを含むことができる。テストユニットはテストスケジュールに従ってソフトウェアコードを携帯通信ユニットへアップロードするように適合されることができる。
【００１４】
テスト入力データは携帯通信ユニットとのユーザインタラクションのエミュレーションを行うためのテストケース制御データを含むことができる。テストユニットはテストスケジュールに従ってテストケース制御データを携帯通信ユニットへ供給するように適合されることができる。
【００１５】
テスト出力データは、携帯通信ユニットにおいてシステム障害が発生したときの携帯通信ユニットのメモリ状態を含むことができる。
【００１６】
携帯通信ユニットにおいてシステム障害が発生した場合、テストユニットは携帯通信ユニットを再起動するように適合されることができる。
【００１７】
テスト装置は、テスト装置の少なくとも１つの環境パラメータを表す信号を検出するのに適合したモニタユニットをさらに備えることができる。個々の環境パラメータは当該環境パラメータに関連付けられたインタバルを含んでもよく、そのインタバル中でのテスト装置の作動が促される。
【００１８】
モニタユニットは、テストユニットが停止されているかどうかを検出し、テストユニットが停止されていれば、少なくとも１つの環境パラメータを表す信号に基づいて、前記少なくとも１つの環境パラメータの各々が関連付けられたインタバル内にあることを検出することに応じて、テストユニットの起動を開始するように適合されることができる。
【００１９】
モニタユニットは、テストユニットが作動中であるかどうかを検出し、テストユニットが作動中であれば、テストユニットは、少なくとも１つの環境パラメータを表す信号に基づいて、前記少なくとも１つの環境パラメータのうちの少なくとも１つが関連付けられたインタバルの外にあることを検出することに応じて、テストユニットの停止を開始するように適合されることができる。
【００２０】
１つの環境パラメータはテスト装置の温度であってもよい。上記に追加して、又は、上記とは別に、１つの環境パラメータはテスト装置へ電力を供給する電源の電圧であってもよい。さらに上記に追加して、又は、上記とは別に、１つの環境パラメータは車輌のエンジンが動いているかどうかを示すエンジンモニタパラメータであってもよい。エンジンモニタパラメータは、エンジンが動いているときには関連付けられたインタバル内にあり、かつ、エンジンが動いていないときには関連付けられたインタバル外にあるようにすることができる。
【００２１】
テストユニットはテスト制御ユニットを備えることができる。テスト制御ユニットは、携帯通信ユニットへのテスト入力データの供給を制御するように適合されることができる。さらに、テスト制御ユニットは、少なくとも携帯通信ユニットからのテスト出力データの検索を制御するように適合されることができる。テスト制御ユニットは、さらに、テスト制御ユニットの作動中に第１のトリガ信号を生成するように適合されることができる。テストユニットは制御ユニットをさらに備えることができる。制御ユニットは第１のトリガ信号を受信するように適合されることができる。制御ユニットは、所定の時間量の間に第１のトリガ信号が受信されなかったことに応じて、テストユニットの停止を開始するように適合されることができる。
【００２２】
制御ユニットは制御ユニットの作動中に第２のトリガ信号を生成するように適合されることができる。モニタユニットはテストユニットへの電力供給を制御するように適合されることができる。モニタユニットは第２のトリガ信号を受信するように適合されることができる。さらに、モニタユニットは、所定の時間量の間に第２のトリガ信号が受信されなかったことに応じて、電力の供給を中断するように適合されることができる。
【００２３】
テスト装置は、テスト装置の地理上の位置を追跡するように適合された測位ユニットを備えることができる。測位ユニットはテストユニットと作動可能に接続することができる。測位ユニットは、テスト装置の地理上の座標を含むテスト出力データを生成するように適合されることができる。測位ユニットは全地球測位システム受信機を備えることができる。
【００２４】
テストユニットには、メモリユニットを備えたコンピュータの実装が可能である。メモリユニットには、ソフトウェアコード手段がコンピュータ上で実行されるとき、テスト入力データを携帯通信ユニットへ供給し、テスト出力データを携帯通信ユニットから取り出し、テスト入力データの少なくとも一部をサーバから取り出し、次いで、テスト出力データの少なくとも一部をサーバへ転送するための前記ソフトウェアコード手段が中に格納されていてもよい。
【００２５】
テストユニットは、少なくとも２つの携帯通信ユニットへテスト入力データを供給すると共に、少なくとも２つの携帯通信ユニットからテスト出力データを取り出すように適合されることができる。テストユニットは、移動通信ネットワークを介して相互に通信を行うために前記少なくとも２つの携帯通信ユニットの第１及び第２の携帯通信ユニットを制御するように適合されることができる。
【００２６】
第２の側面によれば、携帯通信ユニットをテストするための方法が提供される。本方法によれば、テスト装置の無線インタフェースユニットを用いて、テスト装置と、テスト装置から離れた遠隔地に配置されているサーバとの間に通信リンクが設けられる。さらに、テスト装置においてテスト入力データがサーバから取り出される。さらに、サーバから取り出されたテスト入力データは、テストスケジュールに従ってテスト装置のテストユニットにより携帯通信ユニットへ出力される。テストスケジュールに従って、少なくとも携帯通信ユニットから得られるテスト出力データはテストユニットにより取り出される。テスト出力データの少なくとも一部はサーバへ転送される。
【００２７】
第３の側面によれば、コンピュータプログラムコード手段がコンピュータ能力を有する電子装置によって実行されるとき、コンピュータプログラム製品は上記方法を実行する前記コンピュータプログラムコード手段を含む。
【００２８】
第４の側面によれば、前記コンピュータプログラムコード手段がコンピュータ能力を備えた電子装置によって実行されるとき、コンピュータ可読媒体には、上記方法を実行するコンピュータプログラムコード手段を含むコンピュータプログラム製品が中に格納されている。
【００２９】
いくつかの実施形態によれば、テスト装置の可搬性が高められる。例えば、セルラ通信ネットワークのような現実の世界の通信ネットワークの中で動き回ることができるテスト装置を車輌内に配置することができる。このことによって、現実の世界の通信ネットワークにおいて携帯通信ユニットを効率良くテストすることができるという利点が生じることになり、これは優位をもたらすものとなる。
【００３０】
本発明のさらなる実施形態が従属クレームにおいて規定されている。
【００３１】
本明細書で使用される場合、「備える／備えている（comprises／comprising）」という用語は、言及された特徴、整数、ステップ又は構成の存在を特定するために用いられるが、これら以外の特徴、整数、ステップ、構成、又はこれらのグループの存在又は追加を排除するものではない、という点に留意されたい。
【００３２】
本発明の別の目的、特徴及び利点は、添付図面を参照しながら行う以下の本発明の詳細な説明から生じることになる。
【図面の簡単な説明】
【００３３】
【図１】実施形態に係るテスト装置のブロック図である。
【図２】実施形態に係るテスト装置のブロック図である。
【図３】実施形態に係るテスト装置内のテストユニットを示すブロック図である。
【図４】実施形態に係るテスト装置を示すブロック図である。
【図５ａ】実施形態に係るテスト装置のテストユニットを実行する方法を表すフローチャートである。
【図５ｂ】実施形態に係るテスト装置のテストユニットを実行する方法を表すフローチャートである。
【図６】実施形態に係る制御ユニットのテストユニットを実行する方法を表すフローチャートである。
【図７】実施形態に係る制御ユニットのモニタユニットを実行する方法を表すフローチャートである。
【発明を実施するための形態】
【００３４】
図１は携帯通信ユニット２をテストするためのテスト装置１の実施形態を示す図である。図１において、携帯通信ユニット２は携帯電話機として具現化されている。しかし、携帯通信ユニット２は、移動体無線端末、ポケットベル、コミュニケータ（電子手帳、スマートフォン等）のような任意の種類の携帯通信ユニットであってもよい。携帯通信ユニット２は、ＧＳＭ（移動通信グローバルシステム）とＵＭＴＳ（ユニバーサル移動電話システム）とのうちの少なくともいずれか（但しこれらのみに限定されるわけではない）のような１以上のタイプの移動通信ネットワークにおいて作動するように適合されることができる。本明細書の残りの部分に関連して携帯通信ユニット２を被検体装置（ＤＵＴ）と呼ぶことにする。
【００３５】
図１に示す実施形態では、テスト装置１はテストユニット３を備える。テストユニット３はＤＵＴ２と作動可能に接続するように適合される。ユニバーサルシリアルバス（ＵＳＢ）インタフェース又はＲＳ−２３２インタフェースのような電気的インタフェース（但しこれらのみに限定されるわけではない）を介して作動接続部を設けることができる。テストユニット３はテスト入力データをＤＵＴ２へ供給するように適合される。これによって、テストユニット３はＤＵＴ２の作動を制御することが可能となる。テストユニット３は、人間のオペレータが例えばＤＵＴ２上のキー又はボタンを押すために存在している必要なしに、ＤＵＴ２の作動を制御することが可能となる。テストユニット３はさらに、ＤＵＴ２からテスト出力データを取り出すように適合されることができる。ＤＵＴ２から取り出されたテスト出力データは、ＤＵＴ２においてシステム障害が発生すると、例えば、オーディオと、ビデオと、音声とのうちの少なくともいずれかの品質に関連する１以上のデータ、データスループットに関連するデータ、及びコアダンプ（ＤＵＴ２のメモリ状態（図示せず））を含むことができる（但しこれらのデータのみに限定されるわけではない）。ＤＵＴ２から取り出されたテスト出力データは、上記とは別に、又は、上記に加えて、ＤＵＴ２の状態情報のようなＤＵＴ２内の有限状態マシンの状態と、ＤＵＴ２内で生成されたエラーと、警告とのうちの少なくともいずれかを含むことができる。前記エラーと警告の少なくともいずれかは、ＤＵＴ２のデータ処理ユニットで実行されているソフトウェアのためのデバッグ情報の中に含まれるものであってもよい。さらに上記に追加して、又は、上記とは別に、ＤＵＴ２から取り出されたテスト出力データは、ＤＵＴ２が作動している通信ネットワークの状態情報を含むことができる。このようなネットワークの状態情報は、例えば１以上の認証ステータス、ハンドオーバステータス、セルラネットワークにおける隣接セルに関する情報、信号対雑音比（ＳＮＲ）と信号対妨害比（ＳＩＲ）とのうちの少なくともいずれかを含むことができる（但しこれらのみに限定されるわけではない）。ネットワークの状態情報は、例えばＤＵＴ２のデバッグを行うために有益な情報になり得る。例えば、通信エラーのようなエラーが生じた場合、エラー発生時に支配していた外部状態に関する情報と、エラーがＤＵＴ２内において生じたか、通信ネットワーク内において生じたかどうかに関する情報との少なくともいずれかの情報をネットワークの状態情報によって明らかにすることが可能となる。
【００３６】
テスト装置１は、テスト入力データとテスト出力データとを記憶するためのメモリユニット（図示せず）を備えることができる。メモリユニットは、フラッシュメモリのような不揮発性メモリ、コンパクトディスク（ＣＤ）又はデジタル多用途ディスク（ＤＶＤ）ドライブのような光メモリ、又はハードディスクドライブなどであってもよい。さらに、テスト装置は外部サーバ５と通信を行うように適合されることができる。図１に示す実施形態では、テスト装置１は、テスト装置１とサーバ５との間に通信リンクを設けるように適合された無線インタフェースユニット４を備える。本発明を限定するものではない実施例として、無線インタフェースユニット４はモデムであってもよい。このモデムは、無線ローカルエリアネットワーク（ＷＬＡＮ）モデム、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）モデム、ＧＳＭモデム、次世代ＧＳＭ拡張型データレート（ＥＤＧＥ）モデム、汎パケット無線サービス（ＧＰＲＳ）モデム、又はＵＭＴＳモデムなどであってもよい（但しこれらのみに限定されるわけではない）。実施形態によれば、サーバ５はファイル転送プロトコル（ＦＴＰ）サーバである。しかし、ＦＴＰサーバとは別のタイプのサーバも同様に使用してもよい。テスト装置は、例えばインターネットのような広域ネットワーク（ＷＡＮ）を介してサーバ５と接続するように適合されることができる。
【００３７】
テストユニット３は、テスト出力データ、又は該出力データの一部をサーバ５へ転送するか、アップロードするように適合されることができる。これによって、テスト出力データがサーバ５へアップロードされるとすぐに、テスト管理者である人間のオペレータがテスト出力データの分析を行うことが可能となる。サーバ５はテスト装置１から離れた遠隔地に配置することができる。したがって、人間のオペレータがテスト装置１の所在位置と同じ場所にいる必要はなくなる。
【００３８】
上記に追加して、又は、上記とは別に、テストユニット３は新たなテスト入力データをサーバ５から取り出すように適合されることができる。これによって、ＤＵＴ２においてどのテストを実行すべきかを遠隔地において制御することが可能となる。したがって、人間のオペレータがテスト装置１と同じ場所にいる必要なく、実施すべきテストをテスト装置１の作動中に修正することが可能となる。
【００３９】
テストユニット３はテストスケジュールに従ってＤＵＴ２の作動を制御するように適合されることができる。テスト入力データをテストスケジュールに基づいてＤＵＴ２へ供給することによってＤＵＴ２の作動を制御することが可能となる。テスト装置１の上述のメモリデバイスにテストスケジュールを記憶しておいてもよい。テストスケジュールは、機械解釈可能言語で書かれたファイルの形で記憶することができる。ファイルは「．ｔｘｔ」ファイル又は、「．ｉｎｉ」ファイルのようなテキストファイルなどであってもよい。ファイルは、拡張マークアップ言語（ＸＭＬ）ファイルのようなマークアップ言語で書かれたファイルであってもよい。いくつかの実施形態では、テストユニット３は、新たな又は更新されたテストスケジュールをサーバ５から取り出すように適合される。したがって、人間のオペレータがテスト装置１と同じ場所にいる必要なく、テスト装置１の作動中にテストスケジュールの修正が可能となる。
【００４０】
いくつかの実施形態によれば、テスト入力データには、ＤＵＴ２のＣＰＵのようなデータ処理ユニットをプログラムするためのソフトウェアコードが含まれる。これらの実施形態では、テストユニット３は、テストスケジュールに基づいてソフトウェアコードをＤＵＴ２へアップロードするように適合される。この処理はＤＵＴ２の再プログラミングと呼ばれる。ＤＵＴ２は、再プログラミング処理を可能にするためにプログラミングモードでセットする必要がある場合がある。実施形態によれば、ＤＵＴ２は、テストユニット３とＤＵＴ２との間に作動接続部を設けた電気的インタフェースにおいて、専用コネクタを第１の論理状態‘１’などにセットすることによって、プログラミングモード時にセットされるように適合される。ＤＵＴ２は、専用コネクタを第２の論理状態‘０’などにセットすることによって、プログラミングモードから解除されて作動モードに入るように適合されることができる。
【００４１】
ＤＵＴ２の再プログラミングは、ＤＵＴ２の個々の機能とアプリケーションとの少なくともいずれかのためのソフトウェアコードを含んでもよい。例えば、ＤＵＴ２の再プログラミングはＤＵＴ２のファームウェアを更新するステップを含んでもよい。
【００４２】
上記に追加して、又は、上記とは別に、ＤＵＴ２の再プログラミングは、ＤＵＴ２の完全な再プログラミング、すなわちＤＵＴ２におけるすべてのソフトウェアの完全なインストール又は再インストールを含んでもよい。携帯通信ユニットの完全な再プログラミングは、携帯通信ユニットの「フラッシング」と呼ばれることもある。
【００４３】
いくつかの実施形態によれば、テスト入力データには、テストケースに基づいてＤＵＴ２とのユーザインタラクションのエミュレーションを行うためのテストケース制御データか、あるいはテストベクトルが含まれる。これらの実施形態において、テストユニット３はテストスケジュールに従ってテストケース制御データをＤＵＴ２へ供給するように適合される。ＤＵＴ２とのユーザインタラクションのエミュレーションを行うことは、例えば、ＤＵＴ２の様々な機能を呼び出すためのＤＵＴ２のキー又はボタンの押下エミュレーションを行うことを含むことができる。様々な機能は、例えば出接続呼又は着呼拒絶と、ショートメッセージサービス（ＳＭＳ）メッセージ又はマルチメディアメッセージサービス（ＭＭＳ）メッセージのようなメッセージの送信と、例えば無線アプリケーションプロトコル（ＷＡＰ）などを用いてＷＡＮを介して行われる通信と、ＤＵＴ２の種々のソフトウェアアプリケーションの実行とのうちの少なくともいずれかを行うステップを含むことができる（但しこれらのみに限定されるわけではない）。
【００４４】
１つの実施形態によれば、例えば、上記のようにＤＵＴ２とのユーザインタラクションのエミュレーションを行うために、テストケース制御データをＤＵＴ２へ供給するステップと、テスト出力データの少なくとも一部をＤＵＴ２から取り出すステップとのうちの少なくともいずれかは、双方向ソフトウェアセンサプローブによって達成される。双方向ソフトウェアプローブについてはＵＳ２００４／００５９９６２公報に記載があるので、本明細書ではさらなる説明はしない。
【００４５】
いくつかの実施形態によれば、例えばＤＵＴ２において実行していたソフトウェア処理がクラッシュしたり、フリーズしたりした場合のように、ＤＵＴ２においてシステム障害が発生した場合、ＤＵＴ２はコアダンプを生成するように適合される。システム障害が発生したとき、コアダンプは例えばＤＵＴ２のメモリ状態を含むことができる。ＤＵＴ２から取り出されるテスト出力データはコアダンプを含んでもよい。
【００４６】
いくつかの実施形態によれば、前記システム障害が発生すると、ＤＵＴ２は、（ＤＵＴ２が作動不能になる状態などの）ロック状態に入る。ＤＵＴ２をロック状態から解除するために、例えば、ＤＵＴ２に対してまず電源装置のスイッチを切り、次いで、スイッチを入れることによってＤＵＴ２の再起動が必要となる場合がある。テストユニット３はＤＵＴ２の再起動するように適合されることができる。例えば、テストユニット３はＤＵＴ２の電源を制御するように適合されることができる。これによって、ＤＵＴ２においてシステム障害が生じた場合にもＤＵＴ２のテストの継続が可能となる。人間のオペレータの手動による介在を伴うことなくテストの継続が可能となる。
【００４７】
ＤＵＴ２のシステム障害は、ＤＵＴ２のメモリに記憶されたソフトウェアコードが損傷を受けたり、破損したりしたことに起因して生じる場合がある。このようなイベント時に、個々のＤＵＴ２の再起動後、システム障害が発生し続けることが考えられる。いくつかの実施形態によれば、テストユニット３は、ＤＵＴ２の再起動と組み合わされてＤＵＴ２を再プログラムするように適合される。これによって、ＤＵＴ２のメモリ内のソフトウェアの障害又は破損が生じた場合にＤＵＴ２のテストの継続が可能となる。
【００４８】
いくつかの実施形態によれば、テストユニット３にはパーソナルコンピュータ（ＰＣ）のようなコンピュータが実装される（但しこれのみに限定されるわけではない）。コンピュータはメモリユニットを備えてもよい。コンピュータのメモリユニットはフラッシュメモリのような不揮発性メモリ又はハードディスクドライブなどであってもよい。コンピュータ上で実行する場合のテストユニット３の機能を実行するソフトウェアコードは、コンピュータのメモリユニットに記憶することができる。コンピュータ内のハードウェア構成要素は、テスト装置１において用いるために必要な最小限のものに限定することができる。例えば、グラフィックボード、サウンドカード、及び光ディスク装置のような補助デバイスはいくつかの実施形態では省いてもよい。さらに、ハードディスクドライブの代わりにフラッシュメモリのような不揮発性メモリデバイスを利用することができる。これによって、例えば、家庭用又はオフィス用に適合されたＰＣと比べて、消費電力と、サイズと、重さとのうちの少なくともいずれかの低減が可能となる点で、テスト装置１の可搬性が高められることになる。
【００４９】
図２はテスト装置１の別の実施形態を示す図である。テストユニット３及び無線インタフェースユニット４に加えて、図２に示すテスト装置１の実施形態はモニタユニット６を備えたものとなる。モニタユニット６はテストユニット３と作動可能に接続される。モニタユニット６は、テスト装置１の少なくとも１つの環境パラメータを表す信号を検出するように適合される。個々の環境パラメータは関連付けられたインタバル（区間）を有しており、そのインタバル内でテスト装置の作動が促される。モニタユニット６は、環境パラメータの検知又は測定を行うように適合された１以上のセンサと作動可能に接続されるように適合されることができる。次いで、センサは環境パラメータを表す信号をモニタユニットへ供給するように適合することができる。前記１以上のセンサはセンサユニット７と共に図２にまとめて示されている。この図は単に例示を目的とするものであり、別個のハードウェアユニットと共に１以上のセンサを実装することが可能である。
【００５０】
１つの環境パラメータはテスト装置１の温度とすることができる。例えば、或る一定温度未満では、テスト装置１の電子部品上での湿気の凝縮に起因して、テスト装置１の作動は不適切なものになり得る。さらに、別の或る一定温度以上では、加熱リスク及びおそらくテスト装置の電子部品に損傷を与えるリスクに起因してテスト装置１の作動が不適切なものになり得る。本発明を限定するものではない実施例として、テスト装置の作動を促すインタバルは−５℃〜５５℃である。例えば、どの電子部品がテスト装置１の中に含まれているかに応じて、個々のテスト装置１の実装構成に対応する適切な温度インタバルを決定することが望ましい。
【００５１】
１つの環境パラメータはテスト装置１へ電源を供給するバッテリのようなソース電圧であってもよい。本発明を限定するものではない実施例として、テスト装置の作動を促すインタバルは１１Ｖ（ボルト）〜１８Ｖとなる。例えば、使用されているのがどのタイプのバッテリであるかに応じて、個々のテスト装置１の実装構成に対応する適切な電圧インタバルを決定することが望ましい。いくつかの実施形態では、テスト装置１への電源供給用としてメインバッテリとバックアップバッテリのような２以上のソースを利用してもよい。これらの実施形態では、ソースのそれぞれに対して別個の環境パラメータを提供してもよい。
【００５２】
いくつかの実施形態では、テスト装置１は、乗用車のような車輌搭載用として適合される（但しこれのみに限定されるわけではない）。前記メインバッテリのような、テスト装置１へ電源を供給するための１つのソースは車輌のバッテリであってもよい。１つの環境パラメータは車輌のエンジンが動いているかどうかを示すエンジンモニタパラメータであってもよい。エンジンモニタパラメータによって、エンジンが動いているときには、エンジンの関連付けられたインタバル内にあり、そのインタバル内ではテスト装置の作動が促され、かつ、エンジンが動いていないときには、該インタバルの外にあるようにすることができる。例えば、エンジンモニタパラメータは、エンジンが動いているときには値‘１’を採用し、エンジンが動いていないときには値‘０’を採用する離散値パラメータであってもよい。テスト装置の作動を促すインタバルは値‘１’から成る離散インタバルになり得る。換言すれば、エンジンが動いているとき、テスト装置の作動を促すことができると共に、この時エンジンからのエネルギがバッテリの再充電を可能にすることになる。
【００５３】
いくつかの実施形態では、テストユニット３が停止されている場合、モニタユニット６は、環境パラメータを表す信号に基づいて、前記少なくとも１つの環境パラメータの各々がそれに関連付けられたインタバル内にあることを検出するステップに応じて、テストユニット３の起動を開始するように適合される。これによって、テスト装置１の作動が促されていることが環境パラメータにより示されると、ＤＵＴ２のテストの開始又は再開が可能となる。したがって、人間のオペレータが手動で介在することなく、ＤＵＴ２のテストの開始又は再開が可能となる。
【００５４】
いくつかの実施形態では、テストユニット３が作動中の場合、環境パラメータを表す信号に基づいて、前記少なくとも１つの環境パラメータのうちの少なくとも１つがそれに関連付けられたインタバルの外にあることを検出するステップに応じて、モニタユニット６はテストユニット３の停止を開始するように適合される。これによって、テスト装置１の作動が促されていないことが環境パラメータにより示されると、ＤＵＴ２のテストを中断することができる。したがって、人間のオペレータが手動で介在することなく、ＤＵＴ２のテストの中断が可能となる。
【００５５】
上記に従ってモニタユニット６が起動と停止の双方を行うように適合される実施形態では、テスト装置が促されたことが環境パラメータによって示されたとき、かつ、この場合にのみ、ＤＵＴ２のテストが実行される。これは人間のオペレータが手動で介在することなく、モニタユニット６により達成することができる。
【００５６】
図３はテストユニット３の実施形態を示す図である。テストユニット３はテスト制御ユニット１０と制御ユニット２０とを備える。テスト制御ユニット１０はＤＵＴ２へのテスト入力データの供給を制御するように適合される。テスト制御ユニット１０は、少なくともＤＵＴ２からのテスト出力データの検索を制御するようにさらに適合される。さらに、テスト制御ユニット１０はテスト制御ユニット１０の作動中に第１のトリガ信号を生成するように適合される。第１のトリガ信号は、テスト制御ユニット１０の作動中に規則的な間隔で発することができる。この規則的な間隔は、１０、２０、３０、４０、５０、又は６０秒毎に一回などであってもよい（但しこれらのみに限定されるわけではない）。第１のトリガ信号はテスト制御ユニット１０の状態の管理又はモニタを作動可能にする。例えば、第１のトリガ信号の存在は、テスト制御ユニット１０が十全に機能していることを示すものとなる。第１のトリガ信号が所定の時間の範囲内で発されなかった場合などのような第１のトリガ信号の非存在は、テスト制御ユニット１０が停止しているか、テスト制御ユニット１０において作動不良が生じたかのいずれかを示すものであることが考えられる。いずれの場合にせよ、第１のトリガ信号の非存在は、テスト制御ユニット１０によってＤＵＴ２のテストが実行されていないことを示すものとなる。
【００５７】
制御ユニット２０はテスト制御ユニット１０と作動可能に接続される。制御ユニット２０は第１のトリガ信号をテスト制御ユニット１０から受信するように適合される。これによって、制御ユニット２０はテスト制御ユニット１０の作動のモニタ又は管理を行うことが可能となる。
【００５８】
制御ユニット２０は、所定の時間量の間に第１のトリガ信号が受信されなかったことに応じてテストユニット３の停止を開始するように適合されることができる。所定の時間量は６０秒などであってもよい（但しこれのみに限定されるわけではない）。ＤＵＴ２のテストを実行しない場合、テストユニット３を停止させることによって、テスト制御ユニットは、電力を節減することが可能となる。これは、テスト装置１へ電力を供給するバッテリ（図示せず）の耐用期間を改善できるという理由のために、移動体であるテスト装置１にとって利点のあるものとなる。さらに、制御ユニット２０によって、人間のオペレータが手動で介在することなくこの省電力化を行うことが可能となる。上記とは別に、テストユニット３の停止は、テスト制御ユニット１０における作動不良が生じた場合のテストユニット３の再開の一部としてもよい。
【００５９】
テストユニット３にコンピュータが実装されている実施形態において、テスト制御ユニット１０及び制御ユニット２０はコンピュータの中央演算処理装置（ＣＰＵ）上で実行しているソフトウェア処理により具現化することができる。テストユニット３の停止の起動は、上で実行されるソフトウェア処理の「ｋｉｌｌ」コマンドのような終了コマンドの発出ステップを含むものとなる。さらに、この終了コマンドの後に、コンピュータのオペレーティングシステムを停止するためのコマンドと、コンピュータを待機モード又は休眠モードにセットするためのコマンドのような、コンピュータのスイッチを完全にオフにするためのコマンドと、コンピュータを低消費電力状態にセットするためのコマンドとのうちの少なくともいずれかのコマンドが後続することができる。これによって追加電力の節減が可能となる。
【００６０】
いくつかの実施形態では、テストユニット３又は該テストユニット３の一部が専用ハードウェアユニットで実現される。例えば、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、等のような専用ハードウェアユニットをテスト制御ユニット１０と制御ユニット２０（図３）の少なくともいずれかのユニットに実装することが可能である。
【００６１】
ある実施形態では、制御ユニット２０は、制御ユニット２０の作動中に第２のトリガ信号を生成するように適合される。制御ユニット２０の作動中に第２のトリガ信号は規則的な間隔で発することができる。この規則的な間隔は、１０、２０、３０、４０、５０、又は６０秒毎に一回などであってもよい（但しこれらのみに限定されるわけではない）。モニタユニット６（図２）は、本実施形態では、第２のトリガ信号を受信するように適合される。モニタユニット６は、テストユニット３への電力供給を制御するようにさらに適合される。さらに、モニタユニット６が所定の時間量の間に第２のトリガ信号を受信しなかった場合、モニタユニット６は、テストユニット３への電力の供給を中断するように適合されることができる。
【００６２】
モニタユニット６は、テストユニット３が停止されたかどうかの判定を行うように適合されることができる。第２のトリガ信号がテストユニット３の所定の時間量の間に受信されなかったことに基づいてこの判定を行うようにしてもよい。
【００６３】
本実施形態では、停止は以下に概説するように実行することができる。環境パラメータがそれに関連付けられたインタバルの外にあることを検出することに応じて、モニタユニット６はモニタユニットの出力部上に停止指示信号を生成する。テストユニット３はこの停止指示信号を検出する。次いで、テスト制御ユニット１０が停止される。したがって、テスト制御ユニット１０は第１のトリガ信号をもはや生成しなくなる。
【００６４】
所定の時間量の間に制御ユニット２０が第１のトリガ信号を検出しなかった場合、制御ユニット２０は、テスト制御ユニット１０がもうＤＵＴ２のテストを実行していないものと判定する。次いで、制御ユニット２０はテストユニット３の停止を開始する。
【００６５】
テストユニット３が停止してしまうと、制御ユニット２０はそれ以上作動しなくなる。したがって、制御ユニット２０は第２のトリガ信号をそれ以上生成しなくなる。
【００６６】
モニタユニット６が所定の時間量の間に第２のトリガ信号を検出しなければ、モニタユニット６はテストユニット３への電力の供給を中断するように適合されることができる。これによって、電力が節減されることになる。この省電力化は人間のオペレータが手動で介在することなく達成することができる。
【００６７】
テスト制御ユニット１０は、テスト制御ユニット１０の作動不良に起因して第１のトリガ信号の発出が中断されてしまう場合がある。例えば、テスト制御ユニット１０がＣＰＵ上で実行されるソフトウェア処理によって実現されている場合、ＣＰＵ内におけるコンフリクトに起因して前記ソフトウェア処理がクラッシュしているか、フリーズしていることが考えられる。制御ユニット２０は、所定の時間量の間に第１のトリガ信号を検出しなかった場合、テストユニット３の停止を開始する。
【００６８】
テストユニット３が停止してしまうと、制御ユニットはそれ以上第２のトリガ信号を生成しなくなる。モニタユニット６は、第２のトリガ信号を受信しなかった場合、テストユニット３が停止したと判断する。環境パラメータの関連付けられたインタバル内に環境パラメータの各々があり、そのインタバル内でテスト装置１の作動が促されれば、モニタユニット６はテストユニット３の起動を開始できることになる。したがって、本実施形態では、テスト制御ユニット１０などにおいて作動不良が生じた場合でも、継続されるＤＵＴ２のテストが容易になる。モニタユニット６によって、人間のオペレータが手動で介在することなく、ＤＵＴ２のテストを継続して行うことが可能となる。
【００６９】
図４はテスト装置１の別の実施形態を示す図である。この実施形態では、テスト装置１は測位ユニット５０を備える。測位ユニット５０はテスト装置１の地理上の位置を追跡するように適合される。本実施形態では、テストユニット３は、ＤＵＴ２からのテスト出力データの検索に加えて、テスト出力データを測位ユニット５０から取り出すように適合される。測位ユニットから取り出されたテスト出力データは、例えばテスト装置１の地理上の座標を表すことができる。
【００７０】
テスト出力データの中に地理上の座標を表すデータを含めることはＤＵＴ２のデバッグを行う上で有益なものになり得る。例えば、ＤＵＴ２においてエラーが生じて、エラー発生時のＤＵＴ２の地理上の座標がわかっていれば、エラー発生時にどのような外部状態が支配的であったかを追跡することが可能となる。例えば、無線状態はどのような状態であったか？他の無線トランシーバのような多くの外部干渉器が存在していたか？丘陵や大きなビルのような多数の妨害物が存在していたか？ＤＵＴ２がセルラ通信ネットワーク内の２つのサービングセル間の境界上に位置していたか？
測位ユニット５０は衛星ナビゲーションモジュールであってもよい。例えば、測位ユニット５０は、ＧＰＳ受信機を備えた全地球測位システム（ＧＰＳ）モジュールであってもよい。しかし、他のタイプの衛星と作動可能である別のタイプの衛星ナビゲーションモジュールのようなタイプの測位ユニットを用いることも可能である。測位ユニット５０は、例えば、ＵＳＢインタフェースやＲＳ−２３２インタフェース（但しこれらのみに限定されるわけではない）のような有線インタフェースを介するか、あるいはブルートゥースインタフェースやＩＲインタフェースなどのショートレンジの無線インタフェース（但しこれらのみに限定されるわけではない）のような無線インタフェースを介して、テストユニット３と作動可能に接続されたものであってもよい。
【００７１】
いくつかの実施形態によれば、テストユニット３は、テスト入力データを２以上のＤＵＴへ供給するか、テスト出力データを２以上のＤＵＴから取り出すかの少なくともいずれかを行うために、同時に２以上のＤＵＴと作動可能に接続するように適合される。これによって、実行できるタイプのテストとしてどのようなテストを相対的に低い複雑さで行い得るかに関して相対的に高いレベルの柔軟性が得られることになる。テストは２以上のＤＵＴ間での通信によって行うことができる。この文脈における通信は、２以上のＤＵＴ間での音声通話又はテキストメッセージやデータの転送などを含んでもよい。この場合、テストを行うためにＤＵＴ２と外部通信装置との間で通信を行う必要はなく、テスト装置１を介してテスト全体を制御することができる。これら２以上のＤＵＴは、異なる通信事業者により処理される（ＧＳＭ又はＵＭＴＳなどの）様々なタイプの通信システムと通信ネットワークとのうちの少なくともいずれかのような異なる通信ネットワークにテスト中に接続されることができる。これによって、異なる通信ネットワークにおけるＤＵＴの挙動を同時にテストすることが可能となる。
【００７２】
図５ａは、例示の実施形態に係るテストユニット３（図１、図２及び図４）において実行される方法をフローチャートによって示す図である。例えば、テスト制御ユニット１０（図３）によって本方法を実行することができる。本方法はステップ１００から開始する。ステップ１１０において、テストユニット３は、テスト入力データとテストスケジュールとの少なくともいずれかのような更新済みデータがサーバ５において利用可能であるかどうかのチェックを行う。ステップ１１０における答えがイエスであれば、更新された日付がステップ１２０においてサーバ５から取り出される。次いで、本方法はステップ１３０へ進む。ステップ１１０における答えがノーであれば、本方法は直接ステップ１３０へ進む。
【００７３】
ステップ１３０において、ＤＵＴ２を再プログラムすべきかどうか、すなわち、新たなソフトウェアをＤＵＴ２へアップロードすべきかどうかを調べるためにテストスケジュールがチェックされる。ステップ１３０における答えがイエスであれば、ステップ１４０においてＤＵＴ２の再プログラムが行われる。次いで、本方法はステップ１５０へ進む。ステップ１３０における答えがノーであれば、本方法は直接ステップ１５０へ進む。
【００７４】
ステップ１５０において、例えば、ユーザがＤＵＴ２上でキー又はボタンを押すエミュレーションを行うためのテストケース制御データがＤＵＴ２へ供給される。さらに、テスト出力データがＤＵＴ２から取り出される。テスト装置１が測位ユニット５０を備える実施形態において、テスト出力データはまた、測位ユニット５０から取り出されるものであってもよい。次いで、本方法はステップ１６０へ進む。
【００７５】
ステップ１６０において、システム障害がＤＵＴ２の中で生じたかどうかのチェックが行われる。ステップ１６０における答えがイエスであれば、ステップ１７０においてコアダンプがＤＵＴ２から取り出される。次いで、ステップ１８０においてテストユニット３がＤＵＴ２を再起動する。次いで、本方法はステップ１９０へ進む。ステップ１６０における答えがノーであれば、本方法は直接ステップ１９０へ進む。
【００７６】
ステップ１９０においてテスト出力データはサーバ５へ転送される。次いで、ステップ２００において、テストスケジュールの最後に達したかどうかを調べるためにテストスケジュールがチェックされる。ステップ２００における答えがイエスあれば、ステップ２１０においてテストユニット１０はテストスケジュールの開始点へ戻る。次いで、テストはステップ１１０へ戻ることによって続けられる。ステップ２００における答えがノーであれば、ステップ１１０へ戻ることによって、テストはテストスケジュールにおける現在の位置において続けられる。
【００７７】
図５ａと関連して説明した実施形態は単に例示にすぎない。これらのステップは異なる順序で実行してもよい。逐次的に実行されるものとして例示されているいくつかのステップを並列に実行してもよい。例えば、ＤＵＴ２のテストが実行されているとき、（ステップ１２０の場合のようにデータをサーバ５から取り出すステップと、ステップ１９０の場合のようにデータを転送するステップとの少なくともいずれかのステップのような）テスト装置１とサーバ５との間でのデータ転送を同時に実行してもよい。これは多量のデータを転送しなければならない場合などに有利である。なぜなら、そのようにすればテストがさらに時間効率のよいものになるからである。さらに、ステップ１９０において何らかのテスト出力データを転送すべきか否かをテストスケジュールの中に指定してもよい。同様に、ステップ１９０において単にサブセットのテスト出力データを転送するのであれば、前記サブセットをテストスケジュールの中に指定してもよい。本方法の中に他のステップが含まれてもよく、また、図５ａの中のいくつかのステップを省いてもよい。いくつかの実施形態では、ステップ２１０における答えがイエスであれば本方法は終了となる。
【００７８】
テスト制御ユニット１０は、作動中いくつかの実施形態に従って第１のトリガ信号を生成する必要がある。例えば、第１のトリガ信号は規則的な間隔で生成されることができる。さらに、モニタユニット６を含む実施形態では、モニタユニット６が停止指示を生成した場合、テスト制御ユニット１０は停止することが望ましい。図５ｂは、実施形態に従って作動中に第１のトリガ信号を生成し、テスト制御ユニット１０の停止を制御する方法を示すフローチャートを示す図である。この実施形態は第１のタイマ（図５ｂに図示のタイマ１）を利用するものである。タイマ（タイマ１）は、例えば、タイマ１のリセットイベントのような所定のイベントからの秒で表される時間をカウントすることができる。
【００７９】
本方法はステップ３００から開始する。ステップ３００はタイマ１のリセットを含んでもよい。ステップ３１０において、モニタユニット６が停止指示を生成したかどうかのチェックが行われる。
【００８０】
ステップ３１０における答えがイエスであれば、テスト制御ユニット１０の停止が起動され、方法はステップ３６０へ進み、本方法は終了される。
【００８１】
ステップ３１０における答えがノーであれば、ステップ３３０において、タイマ１の時間が第１のしきい値（図５ｂに示されたしきい値１）以上であるかどうかのチェックが行われる。このしきい値は、１０、２０、３０、４０、５０、又は６０秒毎に一回などであってもよい（但しこれらのみに限定されるわけではない）。
【００８２】
ステップ３３０における答えがイエスであれば、ステップ３４０において第１のトリガ信号が生成される。次いで、タイマ１がステップ３５０においてリセットされ、ステップ３６０において本方法は終了される。
【００８３】
ステップ３３０における答えがノーであれば、本方法は直接ステップ３６０へ進み、ここで方法は終了される。
【００８４】
図５ｂと関連して説明した実施形態は単に例示にすぎない。これらのステップは異なる順序で実行してもよい。逐次的に実行されるものとして例示されているいくつかのステップを並列に実行してもよい。他のステップが含まれてもよく、図５ｂの中のいくつかのステップを省いてもよい。例えば、テスト装置がモニタユニット６を備えていない実施形態ではステップ３１０及び３２０を省いてもよい。
【００８５】
規則的な間隔又は不規則な間隔でテスト制御ユニット１０において図５ｂに示す方法を実行してもよい。例えば、テスト制御ユニット１０が図５ａに示す方法を実行するように適合されていれば、図５ａの中のステップ１００〜２１０のうちのすべてのステップ又はいくつかのステップは、図５ｂに示す方法を１以上の回数実行するステップを含むようにしてもよい。
【００８６】
図６は、フローチャートによって、例示の実施形態に従う制御ユニット２０（図３）の作動を示す図である。第２と第３のタイマ（図６にそれぞれ示されたタイマ２とタイマ３）が本実施形態では利用される。タイマ（タイマ２とタイマ３）は、例えば、タイマ２とタイマ３のリセットイベントのような所定のイベントから開始される秒の単位で表される時間をそれぞれカウントすることができる。
【００８７】
処理はステップ４００から開始される。ステップ４００はタイマ２及びタイマ３のリセットを含んでもよい。ステップ４１０において、タイマ２の時間が第２のしきい値（図６に示されたしきい値２）以上であるかどうかのチェックが行われる。第２のしきい値（しきい値２）は１０、２０、３０、４０、５０、又は６０秒などであってもよい（但しこれらのみに限定されるわけではない）。ステップ４１０における答えがイエスであれば、ステップ４２０において第２のトリガ信号が生成される。次いで、ステップ４２５においてタイマ２はリセットされる。その後、制御ユニット２０の作動はステップ４３０へ進む。ステップ４１０における答えがノーであれば、制御ユニット２０の作動は直接ステップ４３０へ進む。
【００８８】
ステップ４３０において、第１のトリガ信号が存在しているかどうかのチェックが行われる。ステップ４３０における答えがイエスであれば、ステップ４４０においてタイマ（タイマ３）がリセットされる。その後、制御ユニット２０の作動はステップ４１０へ戻る。
【００８９】
ステップ４３０における答えがノーであれば、ステップ４３０において、タイマ３の時間が第３のしきい値（図６に示されたしきい値３）以上であるかどうかのチェックが行われる。第３のしきい値（しきい値３）は６０秒などであってもよい（但しこれのみに限定されるわけではない）。ステップ４５０における答えがノーであれば、これは、テスト制御ユニット１０が、しきい値３によって決定される所定の時間量の間に第１のトリガ信号を生成しなかったことを示すことになる。したがって、テスト制御ユニット１０によってＤＵＴ２のテストは実行されていないことが示される。したがって、ステップ４６０においてテストユニット３の停止が起動される。
【００９０】
ステップ４５０における答えがノーであれば、制御ユニット２０の作動はステップ４１０へ戻る。
【００９１】
例えば、テスト装置がモニタユニット６を含まない実施形態の場合、制御ユニット２０による第２のトリガ信号の生成は不要にすることができる。これが当てはまる場合、図６に示す制御ユニット２０の作動と比べて制御ユニット２０の作動を単純化することが可能となる。ステップ４１０、４２０及び４２５は省くことができる。ステップ４００及び４４０の後にステップ４３０が後続することができる。さらに、ステップ４５０における答えがノーであれば、制御ユニット２０の作動はステップ４３０へ戻ることができる。
【００９２】
制御ユニット２０の作動についての上記の実施形態は単に例示にすぎない。これらのステップは異なる順序で実行してもよい。逐次的に実行されるものとして例示されているいくつかのステップを並列に実行してもよい。他のステップが含まれてもよく、図６の中のいくつかのステップは省いてもよい。
【００９３】
図７は、例示の実施形態に従ってモニタユニット６の作動（図２及び図４）をフローチャートによって示す図である。本実施形態では第４のタイマ（図７に示されるタイマ４）が利用される。例えば、タイマ４のリセットイベントのような所定のイベントから開始される秒の単位で表される時間をカウントすることができる。
【００９４】
処理はステップ５００から開始される。ステップ５００はタイマ４のリセットを含んでもよい。ステップ５１０において、すべての環境パラメータがそれらの関連付けられたインタバル内にあるかどうかのチェックが行われる。ステップ５１０において答えがイエスであれば、テストユニット３への電力供給が中断されたか、スイッチがオフにされたかのチェックがステップ５２０において行われる。
ステップ５２０において答えがイエスであれば、ステップ５３０においてテストユニット３への電力供給のスイッチがオンにされる。ステップ５４０において、テストユニット３の開始が起動される。次いで、ステップ５５０においてタイマ４はリセットされる。その後、モニタユニット６の作動はステップ５１０へ戻る。
【００９５】
ステップ５２０における答えがノーであれば、ステップ５６０において、タイマ４の時間が第４のしきい値（図７に示されたしきい値４）以上であるかどうかのチェックが行われる。第４のしきい値は６０秒などであってもよい（但しこれのみに限定されるわけではない）。ステップ５６０において答えがイエスであれば、しきい値４によって決定された所定の時間量の間に第２のトリガ信号は生成されなかったことが示される。言い換えると、これはテストユニット３が作動中ではないことを示すものである。したがって、モニタユニットの作動は上述したステップ５４０へ進むことになる。
【００９６】
ステップ５６０において答えがノーであれば、所定の時間の間に第２のトリガ信号が発されなかったことが示される。次いで、本方法はステップ５７０へ進む。
【００９７】
ステップ５７０において、第２のトリガ信号が存在しているかどうかかのチェックが行われる。ステップ５７０において答えがイエスであれば、モニタユニット６の作動は上述したステップ５５０へ進む。
【００９８】
ステップ５７０における答えがノーであれば、モニタユニット５３０の作動はステップ５１０へ戻る。
【００９９】
ステップ５１０において答えがノーであれば、環境パラメータはテスト装置１の作動が促されていないことを示す。したがって、ステップ５８０においてモニタユニット６により停止指示が生成される。次いで、テストユニット３への電力供給が中断されたか、スイッチがオフにされたかのチェックがステップ５９０において行われる。ステップ５９０において答えがイエスであれば、モニタユニット６の作動はステップ５１０へ戻る。
【０１００】
ステップ５９０において答えがノーであれば、タイマ４の時間がしきい値４以上かどうかのチェックがステップ６００において行われる。ステップ６００において答えがイエスであれば、しきい値４によって決定された所定の時間量の間に第２のトリガ信号は生成されなかったことが示される。次いで、ステップ６１０においてテストユニット３への電力供給は遮断される。次いで、モニタユニット６の作動はステップ５１０へ戻る。
【０１０１】
ステップ６００において答えがノーであれば、第２のトリガ信号が存在しているかどうかのチェックがステップ６２０において行われる。ステップ６２０において答えがイエスであれば、ステップ６３０においてタイマ４はリセットされる。次いで、モニタユニット６の作動はステップ５１０へ戻る。ステップ６２０における答えがノーであれば、モニタユニット６の作動は直接ステップ６００へ進む。
【０１０２】
図７に関連する上記記載の実施形態は単に例示にすぎない。これらのステップを異なる順序で実行してもよい。シーケンシャルに実行されるものとして例示されているいくつかのステップをパラレルに実行してもよい。他のステップが含まれてもよく、図７の中のいくつかのステップを省いてもよい。
【０１０３】
上記記載の実施形態に従うテスト装置１は、ＤＵＴ２をテストするための携帯テスト装置の中に含まれてもよい。テスト装置１に加えて、携帯テスト装置は車輌を含むものであってもよい。車輌は乗用車、バス、トラック、列車、路面電車、又は飛行機のうちのいずれかであってもよい（但しこれらのみに限定されるわけではない）。テスト装置１は、例えば、車輌の内部又は外部に機械的に取り付けられて配置されるか、あるいは、単に置かれたものであってもよい。携帯テスト装置はさらにセンサユニット７（図２及び図４）を備えたものであってもよい。
【０１０４】
上述したように、本明細書で開示されたテスト装置１の実施形態は電力消費の低減を可能にするものである。さらに、テスト装置と同じ場所にいる人間のオペレータの介在を必要とせずにテスト装置１の自動作動が可能にされる。これは、言い換えると、テスト装置１を移動体にすることができるので柔軟性を高めるものとなる。例えば、テスト装置１は上述の携帯テスト装置の中に含まれるものであってもよい。このことは、セルラ通信ネットワークなどの現実の世界の通信ネットワークにおいて、ＤＵＴ２を効率良くテストできるという利点をもたらすものとなる。これによって、携帯電話機のような携帯通信ユニットの設計時に効率の改善が可能となる。なぜなら、例えば、シミュレーションした通信ネットワークにおいてテストを行う場合と比べてデバッグ能力が改善されるからである。さらに、例えば、人間のオペレータが、ＤＵＴ２のボタン又はキーなどを押すことによってＤＵＴ２を制御するテスト設定と比べて、ＤＵＴ２へ供給されるテスト入力データ、及び、ＤＵＴ２から検索できるテスト出力データの量は本明細書に開示した実施例の場合、実質的に増加する。これによって、携帯通信ユニットの複雑さが増大するにつれて、効率の良い携帯通信ユニットのテストが容易化されることになる。
【０１０５】
いくつかの実施形態によれば、ＤＵＴ２をテストする方法が提供される。実施形態によれば、本方法はテスト装置１とサーバ５との間に無線インタフェースユニット４を用いて通信リンクを設けるステップを提供する。実施形態によれば、本方法は、テスト装置１においてサーバ５からテスト入力データを取り出すステップをさらに有する。さらに、この実施形態によれば、本方法はテストユニット３によってテスト入力データをＤＵＴ２へ供給すると共に、テストユニット３によって、テストスケジュールに基づいて少なくともＤＵＴ２からテスト出力データを取り出すステップを有する。さらに、実施形態によれば、本方法はテスト出力データの少なくとも一部をサーバ５へ転送するステップを有する。
【０１０６】
本発明は、本明細書に記載の本方法及び機能の実装を可能にするコンピュータプログラム製品の中に組み込むことが可能である。本発明は、コンピュータプログラム製品がロードされ、かつ、コンピュータ能力を備えたシステムにおいて実行されるとき実施可能である。本文脈でのコンピュータプログラム、ソフトウェアプログラム、プログラム製品又はソフトウェアとは、処理機能を有するシステムに特別の機能を直接実行させるか、あるいは、別の言語、コード又は表記への変換後に上記機能を実行させることを意図する１セットの命令の任意の表現であって、任意のプログラム言語、コードあるいは表記での表現を意味するものである。
【０１０７】
以上、特定の実施形態を参照しながら本発明について説明した。しかし、上記記載の実施形態とは別の実施形態も本発明の範囲で可能である。ハードウェア又はソフトウェアによる方法が実行される、上記に記載した方法以外の異なる方法ステップを本発明の範囲で提供することも可能である。上記記載の特徴及びステップとは別の組み合わせで、本発明の上記異なる特徴及びステップを組み合わせることも可能である。本発明の範囲は添付の特許請求の範囲のみによって限定される。
【図１】
2010514304.tif 000003
【図２】
2010514304.tif 000004
【図３】
2010514304.tif 000005
【図４】
2010514304.tif 000006
【図５ａ】
2010514304.tif 000007
【図５ｂ】
2010514304.tif 000008
【図６】
2010514304.tif 000009
【図７】
2010514304.tif 000010
【国際調査報告】
2010514304.tif 000011
2010514304.tif 000012
2010514304.tif 000013