JP2000215115A - ユニバ―サル・シリアル・バス検査システム - Google Patents

Abstract

(57)【要約】 【課題】 ＵＳＢシステムが一連の定義済みＵＳＢ仕様
に適合しているかどうかをテストするシステムおよび方
法を提供する。 【解決手段】 テスト・システムを使用し、選択された
ＵＳＢデバイスが一組の標準デバイス要求への応答とし
て適切なデータを送るかどうかを判別することができ
る。テスト・システムは、テスト・アプリケーションと
テスト・アプリケーション・ドライバを備える。テスト
・アプリケーション・ドライバはＵＳＢシステム・ソフ
トウェアのＵＳＢドライバとインタフェースする。ＵＳ
Ｂシステム・ソフトウェアはホスト・コントローラ・ド
ライバを含む。ホスト・コントローラ・ドライバは、ホ
スト・コントローラとインタフェースし、ホスト・シス
テムのソフトウェアとＵＳＢ相互接続部やＵＳＢデバイ
スとのインタフェースとなる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般に、コンピュ
ータ・システムに関するものであり、さらに詳細には、
周辺装置とユニバーサル・シリアル・バス・システムと
の機能互換性を検査するためのシステムと方法に関する
ものである。

【０００２】

【従来の技術】パーソナル・コンピュータの出現以来、
コンピュータ・ユーザはコンピュータの機能拡張に熱心
であった。しかし、ユーザは、周辺装置を自分のコンピ
ュータに接続する作業に立ち向かったときに数え切れな
いほどの困難を経験してきた。ユーザがプリンタを自分
のコンピュータに取り付けるのは簡単なように思える
が、デバイス（たとえば、スキャナ）をシリアル・ポー
トに接続する作業はさらに難しくなる。スキャナ用のイ
ンタフェース・カードなどのコンピュータ内蔵機器の取
り付けは、なおいっそう難しい作業であり、ユーザはＩ
ＲＱの衝突を解決するためにＩ／ＯアドレスとＤＭＡア
ドレスを設定するという問題に直面することがある。こ
うした困難に出会うと、特にコンピュータが正常に動作
しなかったり、あるいは単にまったく動作しないとき
に、ユーザは挫折することになりかねない。

【０００３】コンピュータ技術が急激に進歩したため、
このような難しい問題に遭遇する機会が増えてきてい
る。そのため、こうした問題を少しでも緩和しようとい
う試みがなされてきた。たとえば、プラグ・アンド・プ
レイ周辺装置の設計コンセプトは、デバイスを取り付け
る難しい作業を緩和することを目的としていた。しか
し、このコンセプトは、主に、コンピュータのキャビネ
ットの内側に取り付けるデバイスを対象としている。プ
リンタやスキャナなどの外部周辺装置の取り付けには、
依然として、プラグ・アンド・プレイ・コンセプトの目
標となっている難しい問題点のいくつかが伴っている。

【０００４】周辺装置の取り付けに伴う問題点をなくす
試みに、他に、ＰＣカード技術の導入があった。この技
術は、以前には、ＰＣＭＣＩＡ−Ｐｅｒｓｏｎａｌ Ｃ
ｏｍｐｕｔｅｒ Ｍｅｍｏｒｙ Ｃａｒｄ Ｉｎｔｅｒ
ｎａｔｉｏｎａｌ Ａｓｓｏｃｉａｔｉｏｎ−と呼ばれ
ていた。ＰＣカード（ＰＣＭＣＩＡ）周辺装置は単純に
かつ簡単にＰＣカード・ソケットに挿入でき、コンピュ
ータによって認識される。しかし、この技術にも問題が
ある。それは元々携帯型コンピュータを対象としていた
という点である。ＰＣカード（ＰＣＭＣＩＡ）スロット
はデスクトップ・コンピュータにも取り付けることはで
きるが、この解決方法はただ単に広く採用されていない
ということである。

【０００５】

【発明が解決しようとする課題】そこで、デスクトップ
・コンピュータ向けの単純で便利なプラグ・アンド・プ
レイ・タイプの技術が依然として必要である。

【０００６】

【課題を解決するための手段】本発明のシステムと方法
のさまざまな実施態様を使用することにより、上記に概
説した問題点の１つまたはいくつかを解決することがで
きる。周辺装置を取り付ける際にまだ難しい点があるこ
と、また問題に対する解決策が必要であることに応え
て、ユニバーサル・シリアル・バス（ＵＳＢ）の概念が
開発された。ＵＳＢの開発は、周辺装置を追加する作業
の難しさおよびそれらのデバイスを取り付けようにも追
加ポートが不足していることなど、さまざまな要因がＵ
ＳＢの開発の動機になっている。ＵＳＢは、コンピュー
タのＩ／Ｏポートに接続されている外部周辺装置にプラ
グ・アンド・プレイ機能を付加し、多くのユーザが経験
している困難を軽減することを目的として設計されてい
る。ＵＳＢはさらに、ユーザを一人あるいは二人に制限
することなく、多数のデバイスを取り付ける手段となる
ようにも設計されている（ＵＳＢを装備していないコン
ピュータの各ポートに１つ）。

【０００７】ＵＳＢを利用したプラグ・アンド・プレイ
機能の実装は、ＵＳＢに単に依存しているだけではな
い。ＵＳＢ上に取り付ける周辺装置はＵＳＢと互換性が
なければならないということが基本にある。つまり、デ
バイスはＵＳＢの特定の特性に適合している必要があ
る。これは、これらの特性を定義するＵＳＢ仕様が普及
することで一部実現している。ここではＵＳＢ仕様は引
用によりそっくりそのまま本発明に取り込んでいる。周
辺装置の設計は、デバイス・シミュレーションを介して
製造前にチェックすることができる。しかし、このよう
なデバイス設計の検証はそれ自体誤りを含む場合があ
る。さらに、設計を物理デバイスに変換する際に誤りが
入り込むこともある。したがって、その最終的物理構成
において周辺装置のＵＳＢ互換性のいろいろな側面を検
証する手段を用意することが重要になってくる。また、
周辺装置とは別にＵＳＢシステム機能を検証する手段を
用意することも重要である。本発明のさまざまな実施態
様において、このような手段を実現している。

【０００８】本発明の一実施態様は、一組の標準デバイ
ス要求に対し正しい応答を返すＵＳＢデバイスの能力を
検証するテスト・システムを備える。標準デバイス要求
では、ＵＳＢデバイスにベンダー識別記号、デバイス・
クラス、および構成などの標準デバイス情報の問い合わ
せを実行できる。他のデバイス・クラス関係およびベン
ダー定義情報も、標準デバイス要求を通じて取得するこ
とができる。テスト・システムでは、ＵＳＢデバイス・
ベンダーは自社のデバイスがＵＳＢ仕様で規定されてい
るとおりにこの情報を適切に送ることができるかどうか
を判別することができる。

【０００９】本発明の他の実施態様は、コンピュータ・
システムにＵＳＢアーキテクチャ・フレームワーク・サ
ポートの実装を検証するテスト・システムを備える。Ｕ
ＳＢアーキテクチャ（ＵＳＢＡ）は、ＵＳＢクライアン
ト・ドライバと関連するＵＳＢデバイスとの通信のチャ
ネルを実装するインタフェースのライブラリから成り立
っている。テスト・システムは、ＵＳＢＡインタフェー
スへの呼び出しを実行し、テスト・パラメータをデコー
ドし、妥当性の確認を行って、それが有効かどうかを判
断する。

【００１０】テスト・システムは、テスト・アプリケー
ションとテスト・アプリケーション・ドライバを備え
る。テスト・アプリケーション・ドライバはＵＳＢシス
テム・ソフトウェアとインタフェースしている。ＵＳＢ
システム・ソフトウェアは、ＵＳＢドライバ、ホスト・
コントローラ・ドライバ、およびその他のホスト・ソフ
トウェアを含んでいてよく、Ｓｏｌａｒｉｓ^TM実装では
ＵＳＢフレームワーク・サポートと呼んでいる。（Ｓｏ
ｌａｒｉｓ^TMはＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉ
ｎｃ．がＳＰＡＲＣ^TMワークステーション上で使用する
ために開発したＵｎｉｘオペレーティング・システムで
ある。）ＵＳＢドライバは、テスト・アプリケーション
・ドライバを介してテスト・アプリケーションとインタ
フェースする。ホスト・コントローラ・ドライバは、ホ
スト・コントローラとインタフェースし、次にこれはＵ
ＳＢ相互接続およびＵＳＢデバイスを備えるホスト・シ
ステム上のソフトウェアとインタフェースする。

【００１１】一実施態様において、テスト・システムは
コマンド・ライン・インタプリタを組み込んでおり、ユ
ーザはこれを使用して、ＵＳＢシステムに対して特定の
操作およびテスト、またはそれらの組み合わせを実行す
るコマンドを入力することができる。ユーザはこれによ
り、標準デバイス要求またはインタフェース機能の集合
をテスト・スイートの一部として検証したり、コマンド
・ライン・インタプリタを介して個別に検証することが
できる。標準デバイス要求またはインタフェース機能の
個々のテストは、システムの検証済みの部分に対する不
要なテストを避けるために使用できる。コマンド・ライ
ン・インタプリタを使用すると、テスト・プログラムを
作成またはコンパイルすることなく、標準デバイス要求
およびインタフェース機能をテストすることができる。
さらにコマンド・ライン・インタプリタを使用すると、
ユーザ側では、ＵＳＢテストまたはデバッグ・セッショ
ンを中断せずにオペレーティング・システム（たとえ
ば、Ｕｎｉｘ）のシェル内でコマンドを実行することが
できる。さらにコマンド・ライン・インタプリタを使用
すると、ユーザはリモートでコマンドを入力できるため
（たとえば、コンピュータ・システムに接続されたモデ
ムを介して）、コンピュータ・システムのサイトにいな
いユーザの専門知識技術を活用できる。

【００１２】

【発明の実施の形態】本発明の他の目的と利点は、以下
の説明を読み、添付の図面を参照すると明白になる。

【００１３】本発明にはさまざまな修正および代替形態
がありうるが、図面の例を使って特定の実施形態を示
し、詳細に説明する。しかし、本発明の図面と詳細な説
明は本発明を特定の形態に制限する意図はなく、それと
は反対に、添付の特許請求の範囲によって定義される本
発明の精神および範囲に含まれるすべての修正、均等
物、および代替物をカバーするものであることを理解さ
れたい。

【００１４】本発明の一実施形態を以下に説明する。こ
の実施形態では、ホスト・コンピュータでＵＳＢシステ
ムを使用する。ＵＳＢシステムは、ＵＳＢ、ＵＳＢに結
合されたＵＳＢホスト・コントローラ、ホスト・コント
ローラを駆動するホスト・コントローラ・ドライバ、お
よびテスト・アプリケーションとホスト・コントローラ
・ドライバとの交信に使用される一組のＵＳＢインタフ
ェースを備える。テスト・アプリケーションは、ＵＳＢ
システム・ソフトウェアとインタフェースするテスト・
アプリケーション・ドライバを含む。テスト・アプリケ
ーションは、ＵＳＢデバイスのデバイス・デスクリプタ
を調べ、テスト・アプリケーション・ドライバ内に保持
されているデバイスの状態情報を構築するように設定さ
れている。テスト・アプリケーションは、ＵＳＢインタ
フェース機能と標準デバイス要求へのＵＳＢデバイスの
応答を検証するテスト・ケースを構築する。テスト・ア
プリケーションを使用すると、ユーザは最初にテスト・
アプリケーションを作成し、コンパイルしなくても、こ
れらの操作を実行することができる。そのためテスト・
アプリケーションにより、ＵＳＢインタフェース機能の
検証作業が容易になり、またＵＳＢに接続されているＵ
ＳＢデバイスがＵＳＢ仕様書の要求どおりに動作してい
ることを検証できる。

【００１５】ＵＳＢの開発は、主に、次の３つの考慮事
項が動機となっている。第１には、パーソナル・コンピ
ュータでは従来、コンピュータの再構成に関して自由度
が制限されていた。パーソナル・コンピュータの使い勝
手を向上する進歩がグラフィカル・ユーザ・インタフェ
ースや内部バス・アーキテクチャの分野で見られたが、
周辺装置をデスクトップ・システムに接続する方法の改
良についてはほとんど進展がなかった（携帯型コンピュ
ータにおけるＰＣカードのプラグ・アンド・プレイ周辺
装置の成功は除く）。第２には、パーソナル・コンピュ
ータでは通常、周辺装置を接続できるポートの数に限り
がある。たとえば、通常のシステムはパラレル・ポート
を１つ、シリアル・ポートを１ないし２つ備えている。
したがって、ユーザはコンピュータ上で２つまたは３つ
のポートに対応する２つまたは３つよりも多い周辺装置
を備えることができなかった。第３には、計算および通
信機能を互いに利用できる潜在力はあったが、これらの
技術は本質的に無関係に発展しており、これらの技術は
簡単には融合できなかった。したがって、コンピュータ
を介して情報をやり取りする簡単で安価な手段が必要で
あった。ＵＳＢは、こうした要求に応えるために設計さ
れた。

【００１６】図１では、ＵＳＢは外部周辺装置をデスク
トップ・コンピュータ・システムに接続するための単純
で効率的な方法となるように設計されたバスである。図
は、複数の周辺装置１１ないし１５に接続されたコンピ
ュータ・システム１０を示している。デバイスは、ハブ
１７ないし１８を介してコンピュータ・システム上のＵ
ＳＢポート１６に接続されている。ハブ１７ないし１８
をＵＳＢ上で使用すると、ユーザはコンピュータ・シス
テムに接続可能なデバイスの台数を増やすことができる
（それとは対照的に、非ＵＳＢシステムでは直接接続で
きるのは２つ、または３つである）。システムは、さら
に、ハブおよび機能デバイスの両方として使用される複
合デバイス１２も含むことがある。デバイス１３は複合
デバイス１２を介してＵＳＢに接続されていることに注
意されたい。

【００１７】図２に、ＵＳＢシステムの主物理コンポー
ネントを説明するブロック図を示す。物理ＵＳＢシステ
ムは、ＵＳＢホスト２０、ＵＳＢデバイス２２、および
ＵＳＢ相互接続２１の３つの部分に分けて説明すること
ができる。第１の部分は、ＵＳＢホストであるが、ＵＳ
Ｂルート・ハブを組み込み、ＵＳＢシステムの基盤をな
すコンピュータ・システムである。第２の部分は、ＵＳ
Ｂデバイスであり、コンピュータ・システムに接続する
周辺装置と機能デバイスを備えている。ＵＳＢ「デバイ
ス」は、追加アタッチメント・ポートを実装するＵＳＢ
に接続できるハブを指す場合もある。第３の部分は、Ｕ
ＳＢ相互接続部であり、ＵＳＢデバイスとＵＳＢホスト
との間の物理接続と、デバイスがホストと交信する手段
とを備えている。

【００１８】ＵＳＢシステムと関連するホストが１つあ
る。ホストは、ＵＳＢシステムが実装されるコンピュー
タ・システムである。ホストは、デバイスまたは他のハ
ブ用の１つまたは複数のアタッチメント・ポイントを備
えるＵＳＢのルート・ハブを組み込んでいる。ホスト・
コントローラは、ホストとＵＳＢとのインタフェースを
装備している。ホスト・コントローラは、ハードウェ
ア、ファームウェア、およびソフトウェアのうちの１つ
またはその組み合わせで実装することができる。

【００１９】ＵＳＢデバイスは、システムに機能を付加
する機能デバイスである（たとえば、ＩＳＤＮモデム、
ジョイスティック、またはスピーカ一式）。ＵＳＢデバ
イスはさらに、追加デバイスを接続できるＵＳＢへの追
加アタッチメント・ポイントを実装するハブでもよい。
非ハブ・デバイスは機能とも呼ばれる。一部のＵＳＢデ
バイスは他のデバイスを取り付けることができる機能デ
バイスとハブの両方に使用される。ＵＳＢ仕様では、す
べてのＵＳＢデバイスがいくつかのインタフェース規格
に準拠することを要求しており、それにより、デバイス
がＵＳＢプロトコルを理解し、標準ＵＳＢ要求およびコ
マンドに応答するよう規定している。

【００２０】ＵＳＢ相互接続の物理的側面は、バス・ト
ポロジによって定められている。バス・トポロジには、
ＵＳＢ相互接続の非物理的側面が含まれているが、この
開示では別のところで取り扱う。バス・トポロジとは、
ＵＳＢがＵＳＢデバイスをＵＳＢホストと接続する方法
を記述するものである。図３において、ＵＳＢ相互接続
の物理構成は層化したスター型である。ホストは相互接
続の基盤となるルート・ハブを備えている。デバイスや
追加ハブをルートおよび他のハブに接続して、相互接続
の連続層を形成することができる。したがって、それぞ
れのハブは層化スター型構成におけるスターの１つの中
心となる。相互接続内のそれぞれの配線セグメントはホ
ストまたはハブと他のハブまたはデバイスとのポイント
・ツー・ポイント接続である。

【００２１】ＵＳＢシステムでは、「ホット・プラグ機
能」をサポートしている。つまり、ＵＳＢデバイスはい
つでもＵＳＢに取り付けたり、ＵＳＢから取り外したり
できるということである。ＵＳＢは、物理的トポロジ内
の変化を検出し、使用可能な機能の変更に対応できるよ
うに設計されている。すべてのＵＳＢデバイスは、ハブ
の１つでＵＳＢに接続されている（ルート・ハブまたは
ルートからチェーン接続されたハブの１つ）。ハブでデ
バイスを取り付けたり、取り外したりする操作は、ハブ
のポート状態で示される。デバイスがハブに取り付けら
れると、ハブは通知をホストに送る。次にホストは、ハ
ブに問い合わせを送り、通知がホストに送られた理由を
確定する。この問い合わせに応答して、ハブはデバイス
がホストに取り付けられているポートの番号を送る。次
にホストは、このポートを使用可能にし、制御パイプ
（０エンドポイント）を介してデバイスとの交信を開始
する。ホストは、取り付けられているデバイスがハブな
のか機能なのかを判別して、一意的なＵＳＢアドレスを
デバイスに割り当てる。一意的なＵＳＢアドレスとデバ
イスの０エンドポイントをデバイスの制御パイプとして
使用する。新規に取り付けられたデバイスが、そのポー
トにデバイスがすでに取り付けられているハブである場
合、この同じプロセスを取り付けられているデバイスご
とに繰り返す。デバイスを取り付けて、デバイスとホス
トとの交信を確立した後、当該ホスト・ソフトウェアに
通知を送る。

【００２２】デバイスをハブから取り外すと、ハブによ
って、デバイスが取り付けられていたポートが使用不可
にされ、デバイスの取り外しの通知をホストに送る。ホ
ストは次に、デバイスおよび関係データを影響を受ける
データ構造から除去する。除去されたデバイスが他のデ
バイスの取り付けられているハブであれば、その取り外
しプロセスを、取り外されたハブに取り付けられている
デバイスごとに繰り返す。通知が当該ホスト・ソフトウ
ェアに送られ、取り外されたデバイスが使用できなくな
ったことを通知する。

【００２３】ＵＳＢ相互接続の物理トポロジは層化スタ
ー型構成であるが、システムの論理トポロジは図４に示
されているように単純なスターである。それとは別に、
この論理構成は、個別ＵＳＢデバイスとホスト上のクラ
イアント・ソフトウェア・アプリケーションの間の一連
の直接接続と考えることができる。クライアント・ソフ
トウェアとデバイスとの論理的関係も、クライアント・
ソフトウェアとデバイスに用意されている特定の機能と
の１つまたは複数の直接接続と考えることもできる。論
理構成を一連の直接接続とみることはほとんどの操作に
ついて真であるといえるが、システムは層化物理トポロ
ジを認識しており、取り外されたハブの下流にあるデバ
イスはハブを取り外したときに論理構成から取り外すこ
とができる（上記のホット・スワッピングの説明を参照
のこと）。

【００２４】ＵＳＢは、ホスト上で動作しているクライ
アント・ソフトウェアとＵＳＢデバイスが用意している
機能との間で交信を行うための手段を備えている。図５
および図６は、クライアント・ソフトウェアとデバイス
機能との間で交信するデータの流れを示している。図
は、クライアント・ソフトウェア、ＵＳＢシステム・ソ
フトウェア（ＵＳＢドライバ、ホスト・コントローラ・
ドライバ、およびソフトウェアのホストを含む）、およ
びＵＳＢホスト・コントローラの３つのコンポーネント
から成り立っているホストを示している。ホスト・コン
トローラ・ドライバは、ホスト・コントローラとＵＳＢ
システム・ソフトウェアとのインタフェースであり、Ｕ
ＳＢドライバはＵＳＢシステム・ソフトウェアとクライ
アント・ソフトウェアとのインタフェースである。図５
は、ＵＳＢデバイスがさらに機能、論理デバイス、およ
びＵＳＢバス・インタフェースの３つのコンポーネント
を備えている状態を示している。

【００２５】クライアント・ソフトウェアと機能の間の
情報の論理的な流れは直接であるが、図はデータの実際
の流れはクライアント・ソフトウェアからＵＳＢシステ
ム・ソフトウェア、ＵＳＢホスト・コントローラ、ＵＳ
Ｂバス・インタフェース、ＵＳＢ論理デバイス、そして
最後に機能に向かっていることを示している。同様に、
ＵＳＢシステム・ソフトウェアからＵＳＢ論理デバイス
への制御情報の論理的な流れは直接であるが、情報の実
際の流れはホスト・コントローラとバス・インタフェー
スを通らなければならない。

【００２６】図７において、ＵＳＢ論理デバイスはＵＳ
Ｂシステムからはエンドポイントの集まりによって形成
される１つのインタフェースのように見える。エンドポ
イントは、ホストからデバイスへの通信経路の終端を形
成するＵＳＢデバイスの一意的に識別可能な部分であ
る。ソフトウェアは、エンドポイントを介してＵＳＢデ
バイスとしか交信できない。通信の流れは図中において
矢印で示されている。各エンドポイントの番号は、デバ
イスの設計者によって決定される。デバイス・アドレス
（デバイス取り付け時にシステムによって割り当てられ
る）とエンドポイント番号の組み合わせにより、各エン
ドポイントを一意的に識別できる。

【００２７】すべてのＵＳＢデバイスは、番号０のエン
ドポイントがなければならない。このエンドポイントを
使用して、論理デバイスの初期化と操作（たとえば、設
定）を行う。エンドポイント０は、デバイスの構成情報
にアクセスすることができ、状態および制御目的のため
デバイスにアクセスできる。デバイスは、機能を実装す
るのに必要なだけ追加エンドポイントを備えることがで
きる。デバイスに備えられる追加入力エンドポイント数
は最大１６、追加出力エンドポイント数は１６である
（高速デバイスでない場合。その場合、少ないエンドポ
イント数に制限される）。

【００２８】デバイスのエンドポイントとホストのソフ
トウェアとの通信経路のことをパイプと呼ぶ。パイプ
は、ＵＳＢデバイスが構成されると存在するようにな
る。ソフトウェア・クライアントは通常、Ｉ／Ｏ要求パ
ケット（ＩＲＰ）を介してパイプへのデータ転送を要求
する。ソフトウェア・クライアントは、待機している
か、要求が完了したときに通知する。エンドポイント０
は、デフォルト・パイプと呼ばれる関連パイプを持つ。
デフォルト・パイプは、デバイス識別と構成要求条件を
確定し、デバイスを設定するためにシステム・ソフトウ
ェアによって使用される。デフォルト・パイプはさら
に、デバイスを設定した後にデバイス固有ソフトウェア
で使用することもできるが、ＵＳＢシステム・ソフトウ
ェアはデフォルト・パイプの「所有権」を保持し、クラ
イアント・ソフトウェアによる使用を制御する。

【００２９】図８には、本発明の一実施形態のソフトウ
ェア構造が示されている。この実施形態におけるクライ
アント・ソフトウェアは、テスト・アプリケーション３
０とテスト・アプリケーション・ドライバ３１を備え
る。ＵＳＢシステム・ソフトウェア３２は、ＵＳＢドラ
イバ３３およびホスト制御ドライバ３４を備える。ＵＳ
Ｂドライバ３３とホスト制御ドライバ３４はＵＳＢフレ
ームワーク・サポートの一部である。ＵＳＢフレームワ
ーク・サポートはＵＳＢシステム・ソフトウェアのＳｏ
ｌａｒｉｓ^TMベースの実装であり、Ｓｏｌａｒｉｓ^TMＳ
ＰＡＲＣ^TMプラットフォームにサードパーティ・ベンダ
ーがＵＳＢクライアント・ドライバを書き込むことがで
きる一組のインタフェース（ＵＳＢアーキテクチャ・イ
ンタフェース、すなわちＵＳＢＡＩ）を備える。

【００３０】テスト・アプリケーション３０には、ＵＳ
Ｂシステムのいろいろな機能のテストを制御するように
設定されたモジュールが含まれる。この場合、モジュー
ルの機能の分離は一般に、ＵＳＢ仕様で定義されている
ＵＳＢ機能の分離に準拠する。１つのモジュール３５は
ＵＳＢ仕様の第９章で定義されている標準デバイス要求
のテストを制御する。そこで、このモジュールのことを
「第９章」モジュールと呼ぶ。モジュール３８はＵＳＢ
ＡＩ機能のテストを制御し、したがって、ここではＵＳ
ＢＡＩモジュールと呼ぶ。他のモジュール（３６）はＵ
ＳＢ仕様の第１１章で定義されているようにハブ標準要
求のテストを制御する。図８に示されている実施形態で
は、さらにシステムはモジュール３７を備え、これはイ
ンタプリタである。このインタプリタは、別々の機能セ
ットのテストを行うものではなく、その代わりに、すべ
てのＵＳＢ機能のテストをサポートしている。このイン
タプリタを他のモジュールとともに使用し、標準デバイ
ス要求、ＵＳＢＡＩ機能、および標準ハブ要求のテスト
を制御することができる。すべてのモジュールは操作に
より、テスト・アプリケーション３９の本体に結合され
る。

【００３１】テスト・アプリケーション・ドライバ３１
も同様に構造化されており、アプリケーション３０のモ
ジュールに対応する主ドライバ・コンポーネント４０と
いくつかのモジュール４１ないし４４を備えている。テ
スト・アプリケーション・ドライバ３１はロード可能ド
ライバである。つまり、ＵＳＢデバイスを電源オン状態
で挿入したとき、ＵＳＢアーキテクチャ・フレームワー
クがドライバをロードし、新規インストール・デバイス
のデバイス・ノードを作成する。デバイスを電源オン状
態で抜き取ったとき、ドライバは抜き取ったデバイスに
関してアンロードされる。

【００３２】テスト・アプリケーションは、インストー
ルした後ＵＳＢデバイスで走らせることができる。一実
施形態において、テスト・アプリケーションはテスト・
スイートを実行して、ＵＳＢデバイスがＵＳＢ仕様で定
義されているすべての標準デバイス要求に応答して適切
なデバイス情報を提供できることを検証する。アプリケ
ーションは、デバイス・ノードを開き、デバイスの状態
情報を構築し、状態情報に基づいてシステム資源を割り
当てる。テスト・アプリケーション・ドライバ３１はデ
バイスをテストする際に使用するためにデバイス状態を
保持する。テスト・アプリケーション３０の第９章モジ
ュール３５は状態情報に基づいてテスト要求とパラメー
タを作成し、テスト要求とパラメータを妥当性確認のた
めにテスト・アプリケーション・ドライバ３１の第９章
モジュール４１に伝送する。パラメータが有効であれば
（つまり、パラメータの許容可能な限度内で）、テスト
要求（標準デバイス要求）は要求構造にパッケージ化さ
れ、テスト・アプリケーション・ドライバに受け渡され
る。テスト・アプリケーション・ドライバ３１の第９章
モジュール４１は要求構造内のコマンドの妥当性を確認
し、デフォルト・パイプを介してその要求をＵＳＢデバ
イスに伝送する。その後、標準デバイス要求に応答して
デバイスから送られる情報がテスト・アプリケーション
に返される。

【００３３】他の実施形態では、テスト・アプリケーシ
ョンは一連のテストを実行して、ＵＳＢドライバがＵＳ
Ｂインタフェース・ファンクション・コールに応答して
正常に機能するかどうかを検証することができる。テス
トは、標準デバイス要求に関する上記の方法と実質的に
同じ方法で実行される。テスト・アプリケーションはデ
バイス・ノードを開き、デバイス情報を取得し、デバイ
ス状態情報を構築し、テスト用のシステム資源を割り当
てる。ＵＳＢＡＩテスト・アプリケーション・モジュー
ル３８はテスト・パラメータを作成し、その後、これを
テスト・アプリケーション・ドライバＵＳＢＡＩモジュ
ール４２で検証する。妥当性が確認されたテスト・パラ
メータに基づいてＵＳＢＡＩファンクション・コールを
構成し、ファンクション・コールを実行する。ファンク
ション・コールの結果がテスト・アプリケーションに返
される。

【００３４】一実施形態において、テスト対象のＵＳＢ
デバイスはＵＳＢに接続されているいくつかのうちの１
つである。テスト・システムは、ＵＳＢシステムを調べ
て、ＵＳＢ相互接続に接続されているデバイスを決定す
る。ＵＳＢシステムは、接続されているデバイスに関す
る情報を進行中の列挙活動の一部として保持する。ユー
ザに接続デバイスの一覧が提示される。ユーザは標準デ
バイス要求またはインタフェース・ファンクション・コ
ールへの適切な応答としてテストするデバイスの１つを
選択することができる。ユーザに対してさらに、デバイ
スに対応するエンドポイント情報が提示することがで
き、テストする特定のエンドポイントを選択することが
できる。

【００３５】本発明の他の実施形態には、いろいろな機
能が含まれる。一実施形態において、テスト・システム
はコマンド・ライン・インタプリタを備える。コマンド
・ライン・インタプリタを使用することで、ユーザはア
プリケーションによって解釈され実行される個々のコマ
ンドを入力し、ＵＳＢシステムの特定の機能をテストす
ることができる。こうして、ユーザは第９章要求または
インタフェース・ファンクション・コールのスイート全
体ではなく個々の標準デバイス要求またはＵＳＢＡＩフ
ァンクション・コールを実行することができる。これに
より、総合的なテスト・スイートによって実行される不
要なテストをなくすことができる。標準デバイス要求、
ＵＳＢＡＩ機能および標準ハブ要求など、各種の操作の
組み合わせを実行するコマンドを設定することができ
る。

【００３６】さらにコマンド・ライン・モードでは、テ
スト・アプリケーションをリモートで使用することもで
きる。つまり、ユーザはＵＳＢシステムをテストするた
めに物理的に存在している必要がないということであ
る。ユーザはその代わりに、テスト・システムとの通信
を確立し、通信リンクを介してコマンドを入力すること
ができる。たとえば、ユーザはリモート・コンピュータ
とテスト・システムとの間でモデムによる接続を確立
し、モデム接続を介してコマンドを入力することができ
る。リンクは通信に適当な手段を利用することができ、
モデムの例は制限することが目的ではなく、説明するこ
とが目的である。

【００３７】ユーザはさらに、テスト・セッションを中
断することなくテスト・システムに無関係のコマンド
（たとえば、Ｕｎｉｘシェル・コマンド）を実行するこ
ともできる。コマンド・ライン・モードは、必要なタイ
ピング量を減らすため、使用可能なコマンドに別名を付
けてユニークなリストに追加するように設定することが
できる。テスト・システムはさらに、ユーザとシステム
との交互作用を容易にするためにオンライン・ヘルプを
提供することができる。

【００３８】テスト・システムの一実施形態は、システ
ムが操作をシングル・ステップで実行できる機能モード
で設定されている。これは、ユーザがＵＳＢ上のトラヒ
ックを調査する必要がある場合に役立つ。コマンドを発
行した後、操作の実行時にロジック・アナライザを使用
してＵＳＢトラヒックを調べることができる。

【００３９】備えることができる他の機能として、テス
ト中にポートを切り替える機能がある。ユーザはいくつ
かのテストのため特定のポートでデバイスを選択し、そ
の後、別のポートに切り替えて、そのポートに接続され
ているデバイスをテストすることができる。上述のよう
に、システムのデバイス列挙活動は進行中であり、ユー
ザはテスト・システムが実行を開始した後にデバイスを
追加するときでもテストするデバイスを選択することが
できる。デバイスがシステムに接続されているので、識
別され、対応する状態情報が構築され、テストのためシ
ステムで使用できるようになる。

【００４０】デバイスをテストするためにデバイス情報
を決定する他に、この情報をユーザ側で使用できるよう
にテスト・システムを設定することができる。デバイス
・デスクリプタなどの情報は、行列形式で表示できるた
め、ユーザ側では個々のデバイスの特性を並べて比較す
ることができる。バス列挙はＵＳＢシステム内の進行中
の活動なので、デバイスはＵＳＢに接続されるときに認
識され、デバイス上で通常取得される情報はすでにイン
ストールされているデバイスの情報と並べて表示するこ
とができる。同様に、ＵＳＢシステムから取り外される
デバイスに対応する情報を表示から除去することができ
る。

【００４１】一実施形態において、テスト・システムに
入力できるコマンドは、デバイス状態情報に関係するコ
マンド、標準デバイス要求コマンド、ＵＳＢアーキテク
チャ・インタフェース・コマンド、およびその他のコマ
ンドの４つのカテゴリにグループ分けすることができ
る。ＵＳＢ仕様は、ＵＳＢの変更機能に対応するように
許容されるコマンドの追加、削除、または修正を行える
ように改正される可能性があり、テスト・システムはＵ
ＳＢの新しいコマンドおよび機能を取り込むように改造
できると考えられる。

【００４２】標準デバイス要求はＵＳＢ仕様の第９章で
定義されている。標準デバイス要求は、対応する機能と
ともに表１に示した。すべてのＵＳＢデバイスはホスト
からの標準デバイス要求に応答する必要がある。これら
の要求は、制御転送機能を使ってデバイスのデフォルト
・パイプ経由で送られる。要求と要求のパラメータはセ
ットアップ・パケット内でデバイスに送られる。

【００４３】

【表１】

【００４４】ＵＳＢＡＩコマンドを対応する機能ととも
に表２にまとめた。ＵＳＢＡＩコマンドは、選択された
デバイスの特定のエンドポイントに対して発行される。
これらのコマンドに対応するＵＳＢＡＩ機能は、シング
ル・ステップ・モードで実行されるため、ユーザ側でＵ
ＳＢ上のトラヒックを調査することができる。

【００４５】

【表２】

【表３】

【００４６】特定の実施形態を参照しながら本発明を説
明したが、実施形態は説明のため用いたものであり、発
明の範囲はそのように制限されていないことを理解され
たい。説明した実施形態に変形、修正、追加、改善を加
えることが可能である。こうした変形、修正、追加、改
善は、特許請求の範囲内で述べる発明の範囲に含まれ
る。

【図面の簡単な説明】

【図１】コンピュータ・システムに取り付けられた複数
のＵＳＢ周辺装置の物理構成を示すブロック図である。

【図２】ＵＳＢシステムの主物理コンポーネントを示す
ブロック図である。

【図３】ＵＳＢ相互接続上のハブに接続されている複数
のデバイスの層化スター型物理構成を示すブロック図で
ある。

【図４】ＵＳＢ相互接続に接続されている複数のデバイ
スの単純スター型論理構成を示すブロック図である。

【図５】ＵＳＢシステム内のデータの論理的および物理
的流れを示す機能ブロック図である。

【図６】ＵＳＢシステムのホスト内のデータの論理的お
よび物理的流れを示す機能ブロック図である。

【図７】ＵＳＢホスト内のクライアント・ソフトウェア
とＵＳＢデバイス内の複数のエンドポイントとの間のデ
ータの流れを示す図である。

【図８】本発明の一実施形態におけるＵＳＢテスト・ア
プリケーションの構造を示す図である。

【符号の説明】

１０ コンピュータ・システム １１〜１５ 周辺装置 １２ 複合デバイス １３ デバイス １６ ＵＳＢポート １７、１８ ハブ ２０ ＵＳＢホスト ２１ ＵＳＢ壮語接続 ２２ ＵＳＢデバイス ３０ テスト・アプリケーション ３１ スト・アプリケーション・ドライバ ３２ ＵＳＢシステム・ソフトウェア ３３ ＵＳＢドライバ ３４ ホスト制御ドライバ ３５、３６、３７、４１、４３、４４ モジュール ３８ ＵＳＢＡＩテスト・アプリケーション・モジュー
ル ３９ テスト・アプリケーション ４０ 主ドライバ・コンポーネント ４２ テスト・アプリケーション・ドライバＵＳＢＡＩ
モジュール

───────────────────────────────────────────────────── フロントページの続き (71)出願人 591064003 901 ＳＡＮ ＡＮＴＯＮＩＯ ＲＯＡＤ ＰＡＬＯ ＡＬＴＯ，ＣＡ 94303，Ｕ. Ｓ．Ａ. (72)発明者 マイケル・エヌ・チュウ アメリカ合衆国・95132・カリフォルニア 州・サン ホゼ・ストーンウッド レー ン・1965

Claims (25)

【特許請求の範囲】
1. 【請求項１】 ユニバーサル・シリアル・バス（ＵＳ
   Ｂ）システムの機能を検証するテスト・システムであっ
   て、 コンピュータ・システムがテスト・アプリケーションお
   よびＵＳＢシステム・ソフトウェアを実行するように構
   成されており、前記テスト・アプリケーションがテスト
   ・アプリケーション・ドライバを備え、前記ＵＳＢシス
   テム・ソフトウェアがＵＳＢドライバを備え、コンピュ
   ータ・システムがホスト・コントローラを備え、前記ホ
   スト・コントローラが前記ＵＳＢシステム・ソフトウェ
   アによって駆動されるコンピュータ・システムと、 前記コンピュータ・システムに結合され、前記ホスト・
   コントローラによって制御されるように構成されている
   ＵＳＢ相互接続部とを備え、 前記テスト・アプリケーションが、前記ＵＳＢシステム
   の１つまたは複数の機能を検証する１つまたは複数のテ
   ストを作成し、前記の１つまたは複数のテストを実行
   し、前記の１つまたは複数のテストに対する前記ＵＳＢ
   システムの応答が有効かどうかを判別するように構成さ
   れていることを特徴とするテスト・システム。
2. 【請求項２】 前記ＵＳＢ相互接続部に結合された第１
   のＵＳＢデバイスを備え、前記テスト・アプリケーショ
   ンが複数の標準デバイス要求を前記ＵＳＢデバイスに送
   り、前記ＵＳＢデバイスが前記の複数の標準デバイス要
   求への応答として送る情報が有効なものかどうかを判別
   するように構成されている請求項１に記載のシステム。
3. 【請求項３】 前記の複数の標準デバイス要求が前記の
   ＵＳＢデバイスに個別に送られ、ユーザが入力した対応
   するコマンド行への応答として前記のそれぞれの標準デ
   バイス要求が前記ＵＳＢデバイスに送られる請求項２に
   記載のシステム。
4. 【請求項４】 前記テスト・アプリケーションが前記テ
   スト・アプリケーション・ドライバを介して前記ＵＳＢ
   ドライバに１つまたは複数のテスト信号を送り、前記の
   テスト信号のそれぞれが前記ＵＳＢドライバのＵＳＢＡ
   Ｉ動作に対応するように構成され、前記テスト・アプリ
   ケーションが前記の対応するテスト信号への応答として
   前記ＵＳＢドライバによって前記ＵＳＢＡＩ動作が正し
   く実行されるかどうかを判別するように構成されている
   請求項１に記載のシステム。
5. 【請求項５】 コマンド・ライン・インタプリタを備
   え、前記の１つまたは複数のテスト信号のそれぞれを前
   記ＵＳＢドライバに個別に送り、ユーザが入力した対応
   するコマンド・ラインへの応答として前記のテスト信号
   のそれぞれを前記ＵＳＢドライバに送る請求項４に記載
   のシステム。
6. 【請求項６】 前記コンピュータ・システムがコマンド
   ・シェルを備え、前記テスト・アプリケーションが個別
   に入力されるコマンド・ラインを介してテスト・コマン
   ドを受け入れるように構成されているコマンド・ライン
   ・インタプリタを備え、ユーザがシェル・コマンドと前
   記テスト・コマンドの両方を入力することができ、前記
   テスト・コマンドが前記テスト・システムによって実行
   され、前記シェル・コマンドが前記コマンド・シェルに
   よって実行される請求項１に記載のテスト・システム。
7. 【請求項７】 前記コンピュータ・システムがＵｎｉｘ
   動作環境を備え、前記テスト・コマンドがＵｎｉｘコマ
   ンドを備えている請求項６に記載のテスト・システム。
8. 【請求項８】 前記コンピュータ・システムとリモート
   の場所との間に通信リンクを備え、前記通信リンクを介
   して前記のリモートの場所から前記テスト・コマンドを
   前記コンピュータ・システムに入力する請求項６に記載
   のテスト・システム。
9. 【請求項９】 前記テスト・コマンドの実行結果として
   生成されたデータが前記通信リンクを介して前記のリモ
   ートの場所に送られる請求項８に記載のテスト・システ
   ム。
10. 【請求項１０】 前記テスト・アプリケーションが前記
    の複数のＵＳＢデバイスを列挙するように構成され、前
    記テスト・コマンドが前記の列挙されたＵＳＢデバイス
    の特定の１つを指定するように構成される請求項６に記
    載のテスト・システム。
11. 【請求項１１】 前記の第１のＵＳＢデバイスが前記Ｕ
    ＳＢ相互接続部に結合されている複数のＵＳＢデバイス
    のうちの１つであり、前記テスト・アプリケーション
    が、前記の複数のＵＳＢデバイスを列挙し、前記の列挙
    されたＵＳＢデバイスを表すデータを前記のユーザに表
    示するように構成され、前記の第１のＵＳＢデバイスを
    前記の列挙されたＵＳＢデバイスから前記のユーザが選
    択する請求項３に記載のテスト・システム。
12. 【請求項１２】 前記のテスト・アプリケーションが前
    記ＵＳＢ相互接続部に１つまたは複数の追加ＵＳＢデバ
    イスを取り付けられたことを認識するように構成され、
    前記テスト・アプリケーションが前記ＵＳＢ相互接続部
    に接続されている前記ＵＳＢデバイスの１つまたは複数
    の取り外しを認識するように構成されている請求項１１
    に記載のテスト・システム。
13. 【請求項１３】 １つまたは複数の標準デバイス要求に
    対するデバイスの応答をテストする方法であって、 第１のデバイスに応答するノードを開くステップと、 前記の第１のデバイスのデバイス情報を取得し、前記の
    ノードに対応する状態情報を構成するステップと、 前記の状態情報に基づいて前記ノードの１つまたは複数
    のテストを作成するステップと、 前記の１つまたは複数のテストを実行するステップと、 前記の１つまたは複数のテストに対する応答を生成する
    ステップと、 ユーザに前記の応答を送るステップとを含む方法。
14. 【請求項１４】 前記テストが前記の第１のデバイスに
    対する標準デバイス要求を含む請求項１３に記載の方
    法。
15. 【請求項１５】 前記テストがＵＳＢＡＩファンクショ
    ン・コールを含む請求項１３に記載の方法。
16. 【請求項１６】 前記の第１のデバイスに対応して前記
    のノードを開くステップが、 ＵＳＢシステムに接続されている１つまたは複数のＵＳ
    Ｂデバイスを識別するステップと、 前記のＵＳＢデバイスの第１のものを選択するステップ
    と、 前記のＵＳＢデバイスの前記の第１の１つに対応して前
    記のノードを開くステップを含む請求項１３に記載の方
    法。
17. 【請求項１７】 前記の１つまたは複数のテストを実行
    するステップが、 前記の１つまたは複数のテストを要求データ構造にパッ
    ケージするステップと、 前記のデータ構造の前記の要求を前記の第１のデバイス
    に対応して第１のドライバに伝送するステップを含む請
    求項１３に記載の方法。
18. 【請求項１８】 前記のデータ構造の前記テストを前記
    の第１のドライバに伝送する前に前記テストで使用して
    いる一組のパラメータの妥当性を確認するステップをさ
    らに含む請求項１７に記載の方法。
19. 【請求項１９】 前記の第１のデバイスが接続されてい
    るホスト・コンピュータを実行するコマンド・ライン・
    インタプリタを介して入力したコマンドへの応答として
    前記テストを選択する請求項１３に記載の方法。
20. 【請求項２０】 リモートの場所と前記ホスト・コンピ
    ュータとの間に通信リンクを確立するステップと、 前記のコマンドを前記のリモートの場所から前記ホスト
    ・コンピュータに伝送するステップを含む請求項１９に
    記載の方法。
21. 【請求項２１】 ユニバーサル・シリアル・バス（ＵＳ
    Ｂ）相互接続部、１つまたは複数のＵＳＢインタフェー
    ス、および１つまたは複数のＵＳＢデバイスを備える、
    コンピュータ内のＵＳＢシステムの機能をテストする方
    法であって、 前記コンピュータ上でテスト・コマンドを入力するステ
    ップと、 コマンド・ライン・インタプリタを使用して前記テスト
    ・コマンドを解釈するステップと、 テスト信号を前記ＵＳＢシステムに送る前記テスト・コ
    マンドと関連するテストを実行するステップと、 前記テスト信号への応答として前記ＵＳＢシステムによ
    って生成されるテスト結果の妥当性を確認するステップ
    とを含む方法。
22. 【請求項２２】 前記コンピュータ・システムが通信リ
    ンクを介してリモートの場所に結合されＴうぃるとき
    に、前記テスト・コマンドを入力するステップが、前記
    のリモートの場所で前記のテスト・コマンドを入力する
    ステップと、前記通信リンクを介して前記テスト・コマ
    ンドを前記コンピュータ・システムに送るステップを含
    む請求項２１に記載の方法。
23. 【請求項２３】 前記コンピュータ上でシェル・コマン
    ドを入力するステップと、前記コンピュータ上で稼働し
    ているオペレーティング・システムのシェルで前記シェ
    ル・コマンドを実行するステップをさらに含む請求項２
    １に記載の方法。
24. 【請求項２４】 前記操作を実行するステップがシング
    ル・ステップ・モードで実行される請求項２１に記載の
    方法。
25. 【請求項２５】 バス・システムの機能を検証するテス
    ト・システムであって、 コンピュータ・システムがテスト・アプリケーションと
    バス・システム・ソフトウェアを実行するように構成さ
    れ、前記テスト・アプリケーションがテスト・アプリケ
    ーション・ドライバを備え、前記バス・システム・ソフ
    トウェアがバス・ドライバを備え、コンピュータ・シス
    テムがホスト・コントローラを備え、前記ホスト・コン
    トローラが前記バス・システム・ソフトウェアによって
    駆動されるコンピュータ・システムと、 前記コンピュータ・システムに結合され、前記ホスト・
    コントローラによって制御されるように構成された相互
    接続部とを備え、 前記テスト・アプリケーションが前記バス・システムの
    １つまたは複数の機能を検証するため１つまたは複数の
    テストを作成し、前記の１つまたは複数のテストを実行
    し、前記の１つまたは複数のテストに対する前記バス・
    システムの応答が有効かどうかを判別するように構成さ
    れているテスト・システム。