DE60009185T2

DE60009185T2 - "Universal serial bus" Interpreter

Info

Publication number: DE60009185T2
Application number: DE60009185T
Authority: DE
Inventors: Michael N. San Jose Chew
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1999-01-19
Filing date: 2000-01-18
Publication date: 2005-01-27
Anticipated expiration: 2020-01-19
Also published as: US6389560B1; ATE262701T1; EP1031931A3; JP2000215116A; EP1031931B1; EP1031931A2; DE60009185D1

Description

Die vorliegende Erfindung bezieht sich allgemein auf Computersysteme und genauer gesagt auf Verfahren und Einrichtungen zum Testen der funktionellen Kompatibilität peripherer Geräte mit einem universellen, seriellen Bus.
Seit dem Erscheinen der Personal Computer waren Computerbenutzer dahinter her, die Fähigkeiten ihrer Maschinen zu erweitern. Die Benutzer haben sich jedoch auch zahlreichen Problemen gegenübergesehen, wenn sie mit der Aufgabe konfrontiert wurden, periphere Geräte an ihre Computer anzuschließen. Während es für einen Benutzer sehr einfach sein kann, einen Drucker an seinem bzw. ihrem Computer anzuschließen, stellt die Verbindung eines Gerätes (beispielsweise eines Scanners) an einem seriellen Anschluß bzw. Port eine größere Herausforderung dar. Die Installation von internen Ausrüstungsgegenständen des Computers, wie z.B. einer Schnittstellenkarte für einen Scanner kann noch größere Schwierigkeiten bieten und der Benutzer kann sich Problemen gegenübersehen, I/O- und DMA-Adressen zur Auflösung von IRQ-Konflikten einzustellen. Diese Schwierigkeiten können den Benutzer frustrieren, insbesondere, wenn sie bewirken, daß der Computer nicht korrekt arbeitet oder einfach überhaupt nicht mehr arbeitet.
Mit den schnellen Fortschritten auf dem Gebiet der Computertechnologie ist das Potential, derartige Schwierigkeiten zu erfahren, noch gewachsen. Im Ergebnis sind Versuche unternommen worden, um diese Probleme zu beheben. Beispielsweise sollte das Konzept der Ausgestaltung von peripheren Plug-and-Play-Geräten die Schwierigkeiten der Installation der Geräte erleichtern bzw. beseitigen. Dieses Konzept ist jedoch primär auf Geräte gerichtet, die in dem Gehäuse des Computers installiert werden. Die Installation externer peripherer Geräte, wie z.B. von Druckern oder Scannern, ist wahrscheinlich immer noch von einigen der Schwierigkeiten begleitet, die das Plug-and-Play-Konzept im Auge hatte.
Ein weiterer Versuch, einige der Probleme zu beseitigen, die mit der Installation von peripheren Geräten zusammenhängen, bestand in der Einführung der PC-Kartentechnologie. (Diese Technologie wurde früher als PCMCIA – Personal Computer Memory Card International Association – bezeichnet.) Periphere Geräte vom Typ der PC-Karte (PCMCIA) werden in einfacher Weise und leicht in einen PC-Kartensockel eingesetzt und werden von dem Computer erkannt. Die Probleme bei dieser Technologie bestehen jedoch darin, daß sie sich ursprünglich auf tragbare Computer richtete. Auch wenn ein Steckplatz für eine PC-Karte (PCMCIA) in einem Desktop-Computer installiert werden kann, ist diese Lösung einfach noch nicht in weitem Umfang angenommen worden. Es verbleibt daher ein Bedarf an einer einfachen und bequemen Technologie vom Plug-and-Play-Typ für Desktop-Computer.
In Reaktion auf die fortgesetzten Schwierigkeiten beim Installieren peripherer Geräte ist die Idee des universellen, seriellen Busses (USB) entwickelt worden. Die Entwicklung von USB wurde motiviert durch eine Anzahl von Faktoren, einschließlich der Schwierigkeit des Hinzufügens peripherer Geräte und des Fehlens zusätzlicher Anschlüsse zum Installieren dieser Geräte. Der USB ist dafür ausgelegt, Plug-and-Play-Fähigkeiten für externe periphere Geräte bereitzustellen, die mit den I/O-Anschlüssen (Ports) des Computers verbunden sind und die dadurch das Erfahren von Schwierigkeiten durch viele Benutzer reduzieren. Der USB wurde auch dafür ausgelegt, eine Einrichtung für das Installieren zahlreicher Geräte bereitzustellen, anstatt den Benutzer auf ein oder zwei (einen für jeden Anschluß auf einem Computer, der kein USB hat) zu beschränken.
Die Implementierung von Plug-and-Play-Fähigkeiten durch den USB hängt nicht allein von dem USB ab. Es ist von grundsätzlicher Bedeutung, daß die peripheren Geräte, die an dem USB installiert werden sollen, mit dem USB kompatibel sind. Mit anderen Worten, es ist notwendig, daß die Geräte mit den speziellen Charakteristiken des USB in Übereinstimmung sind. Dies wird teilweise sichergestellt durch das Durchlaufen der USB-Spezifizierung, welche diese Eigenschaften definiert. Die Ausgestaltungen peripherer Geräte können vor der Herstellung durch Gerätesimulationen überprüft werden. Eine derartige Verifikation von Geräteausgestaltungen kann jedoch ihrerseits Fehler enthalten. Zusätzlich können beim Übersetzen des Modells in ein physikalisches Gerät Fehler eingeführt werden. Es ist deshalb wichtig, daß man Mittel hat zum Verifizieren unterschiedlicher Aspekte von USB-Kompatibilität peripherer Geräte in ihren endgültigen räumlichen Ausgestaltungen. Es ist auch wichtig, daß man Mittel zum Verifizieren der USB-Systemfunktionen getrennt von den peripheren Geräten hat. Die verschiedenen Ausführungsformen der Erfindung stellen solche Mittel bereit.
Dreitlein M.: "The challenge of testing SCSI peripherals" ("Die Herausforderung beim Testen peripherer SCSI-Geräte"), Electronics Test, US, Miller Freeman, San Francisco, Band 13, Nr. 6, 1. Juni 1990 diskutiert auf den Seiten 55, 56, 58, 59, ISSN: 0164-9620 das Testen von peripheren SCSI-Einrichtungen (Small Computer System Interface). Dies wird insbesondere für einen Gerätequalifizierungsvorgang verwendet, um nämlich sicherzustellen, daß ein gegebenes Peripheriegerät mit der Spezifikation übereinstimmt, jedoch eine adäquate Leistungsfähigkeit in einer Systemumgebung hat usw.
"Revision 1.0", Universal Serial Bus Specification 'Online!, 15. Januar 1996, zu entnehmen aus dem Internet: URL: httpa/www.adelaide.edu.au/{gturner/specification/usb/usb-10.pdf>, stellt auf den Seiten 165–215 allgemeine Einzelheiten der USB-Spezifizierung bereit.
Besondere und bevorzugte Aspekte der vorliegenden Erfindung sind in den beiliegenden unabhängigen und abhängigen Ansprüchen dargelegt. Merkmale der abhängigen Ansprüche können mit denjenigen unabhängige Ansprüche kombiniert werden, je nachdem, was geeignet erscheint.
Aspekte der Erfindung werden durch die anhängenden Ansprüche beispielhaft wiedergegeben.
Eine Ausführungsform der Erfindung weist einen USB-Interpreter bzw. -Übersetzer auf. Der USB-Übersetzer ist ein Softwarewerkzeug, welches in einem USB-System verwendet werden kann, um wahlweise Gerätedaten zu untersuchen, USB-Befehle auszuführen und USB-Funktionen auszuüben. Der USB-Übersetzer bzw. -Interpretierer kann diese Funktionen ausführen, ohne daß er ein Testprogramm erzeugen und kompilieren muß, und er kann daher bei Fehlersuchgeräten bezüglich der USB-Kompatibilität zweckmäßig sein. Der USB-Übersetzer kann auch in der Entwicklung von USB-Software verwendet werden.
Der USB-Übersetzer weist eine Testanwendung und einen Treiber der Testanwendung auf. Der Testanwendungstreiber bildet eine Schnittstelle mit der USB-Systemsoftware. Die USB-Systemsoftware, welche einen USB-Treiber, einen Host-Steuerungstreiber und andere Host-Software umfassen kann, wird mitunter als die Stütze des USB-Rahmens bezeichnet. Der USB-Treiber bildet eine Schnittstelle mit der Testanwendung durch den Testanwendungstreiber. Der Host-Steuerungstreiber bildet eine Schnittstelle mit der Host-Steuerung, welche ihrerseits eine Schnittstelle zu der Software auf dem Host-System mit der USB-Verbindung und den USB-Geräten bildet.
In einer Ausführungsform beinhaltet der USB-Übersetzer einen Befehlszeilenübersetzer, durch welchen ein Benutzer Befehle eingeben kann, um spezielle Vorgänge und Tests auf dem USB-System auszuführen. Der Benutzer kann dadurch die Durchführung unnötiger Tests mit zuvor bereits verifizierten Bereichen des Systems vermeiden. Die Verwendung des Befehlszeilenübersetzers erlaubt weiterhin, daß der Benutzer Befehle in einer Betriebssystemumgebung (z.B. Unix) ausführt, ohne daß eine USB-Test- oder -Fehlersuchsitzung unterbrochen werden muß. Die Verwendung eines Befehlszeilenübersetzers ermöglicht es dem Benutzer außerdem, Befehle aus der Ferne einzugeben (beispielsweise über ein Modem, welches mit dem Computersystem verbunden ist), so daß die Erfahrung eines Benutzers, der sich nicht am Ort des Computersystems befindet, genutzt werden kann.
Für ein besseres Verständnis der Erfindung und um zu demonstrieren, wie dieselbe in die Praxis umgesetzt werden kann, wird nunmehr anhand von Beispielen auf die beigefügten Figuren Bezug genommen, von denen:
1 ein Blockdiagramm ist, welches die physikalische Ausgestaltung einer Mehrzahl von peripheren USB-Geräten zeigt, welche an einem Computersystem angebracht sind,
2 ein Blockdiagramm ist, welches die primären physikalischen Bestandteile eines USB-Systems veranschaulicht,
3 ein Blockdiagramm ist, welches die physikalische Ausgestaltung nach Art einer abgestuften Sternstruktur für eine Mehrzahl von Geräten veranschaulicht, die mit Hubs ("Naben") an eine USB-Verbindung angeschlossen sind,
4 ein Blockdiagramm ist, welches die logische Konfiguration des einfachen Sterns für eine Mehrzahl von Geräten zeigt, die an eine USB-Verbindung angeschlossen sind,
5 ein funktionelles Blockdiagramm ist, welches die logischen und physikalischen Ströme von Daten innerhalb eines USB-Systems zeigt,
6 ein Funktionsblockdiagramm ist, welches die logischen und physikalischen Ströme von Daten innerhalb des Hosts in einem USB-System zeigt,
7 ein Diagramm ist, welches den Datenstrom zwischen Client-Software in dem USB-Host und einer Mehrzahl von Endpunkten in einem USB-Gerät zeigt,
8 ein Diagramm ist, welches die Struktur der USB-Testanwendung in einer Ausführungsform der Erfindung zeigt.
Während die Erfindung für verschiedene Modifikationen und alternative Formen anpaßbar ist, sind spezielle Ausführungsformen derselben anhand eines Beispiels in den Figuren dargestellt und werden hier im einzelnen beschrieben. Es versteht sich jedoch, daß die Zeichnungen und die genaue Beschreibung derselben nicht die Erfindung auf die speziell dargestellte Form beschränken sollen.
Eine Ausführungsform der Erfindung wird nachstehend beschrieben. In dieser Ausführungsform verwendet ein Host-Computer ein USB-System. Das USB-System weist einen USB, eine USB-Host-Steuerung auf, die mit dem USB verbunden ist, einen Host-Steuerungstreiber für das Treiben der Host-Steuerung und einen Satz von USB-Schnittstellen auf, welche Kommunikationen zwischen einer Testanwendung und einem Treiber der Host-Steuerung erlauben. Die Testanweisung weist einen USB-Übersetzer auf, der verwendet wird, um gezielt die Funktionen des USB-Systems zu testen. Speziell ist die Anwendung dafür ausgelegt, standardmäßige Gerätedeskriptoren zu untersuchen, USB-Geräte unter Verwendung von standardmäßigen Geräteanforderungen abzufragen und individuelle USB-Schnittstellenfunktionen auszuführen. Der USB-Übersetzer ermöglicht es dem Benutzer, diese Aktionen auszuführen, ohne daß er zunächst eine Testanwendung erzeugen und kompilieren muß. Ein USB-Übersetzer ermöglicht es dadurch einem Benutzer, gezielt Information zu erhalten, welche eine Fehlersuche von USB-Geräten und der zugehörigen Software ermöglicht.
Die Entwicklung des USB war in erster Linie aufgrund von drei Gesichtspunkten motiviert. Als erstes haben Personal Computer traditionell eine begrenzte Flexibilität bezüglich einer Neukonfigurierung des Computers. Auf den Gebieten der graphischen Benutzerschnittstellen und der internen Busarchitekturen ist eine Reihe von Fortschritten gemacht worden, welche Personal Computer benutzerfreundlicher gemacht haben, es wurde jedoch nur wenig Fortschritt gemacht bei der Verbesserung der Anschließbarkeit peripherer Geräte an Desktop-Systeme (trotz des Erfolges der peripheren Geräte in Form der PC-Karten nach dem Prinzip Plug-and-Play bei tragbaren Computern). Zum zweiten hatten Personal Computer typischerweise eine begrenzte Anzahl von Anschlüssen, an welchen periphere Geräte angeschlossen werden konnten. Ein typisches System hat beispielsweise vielleicht einen einzigen parallelen Anschluß und einen oder zwei serielle Anschlüsse. Benutzer wurden deshalb daran gehindert, mehr als zwei oder drei periphere Geräte zu verwenden, welche den zwei oder drei Anschlüssen an ihren Computern entsprachen. Zum dritten haben sich, auch wenn es ein beträchtliches Potential an Berechnungs- und Kommunikationsfunktionen gibt, aus welchen wechselweise Vorteile gezogen werden konnten, diese Technologien im wesentlichen unabhängig entwickelt, so daß die Technologien nicht in einfacher Weise integriert wurden. Es bestand daher ein Bedarf an einer einfachen und preiswerten Einrichtung für die Übermittlung bzw. Kommunikation von Information über Computer. Der USB wurde entwickelt, um diese Erfordernisse zu erfüllen.
Gemäß 1 ist der USB ein Bus, der dafür ausgelegt ist, ein einfaches und effizientes Verfahren zum Anschließen von externen peripheren Geräten an Desktop-Computersysteme bereit zustellen. Die Figur zeigt ein Computersystem 10, welches mit mehreren peripheren Geräten 11–15 verbunden ist. Die Geräte sind mit dem USB-Anschluß 16 an dem Computersystem über "Hubs" 17–18 verbunden. Die Verwendung von Hubs 17–18 an dem USB ermöglicht es den Benutzern, die Anzahl von Geräten, die an das Computersystem angeschlossen werden können (im Vergleich zu den zwei oder drei, die direkt an ein Nicht-USB-System angeschlossen werden können), zu vergrößern. Das System kann auch zusammengesetzte Geräte 12 enthalten, die sowohl als Hubs als auch als funktionelle Geräte dienen. (Man beachte, daß das Gerät 13 mit dem USB über eine solche kombinierte Einrichtung 12 verbunden ist.) Gemäß 2 ist ein Blockdiagramm wiedergegeben, welches die primären physikalischen Komponenten eines USB-Systems veranschaulicht. Das physikalische USB-System kann in drei Teilen beschrieben werden: ein USB-Host 20, USB-Geräte 22, und eine USB-Verbindung 21. Das erste dieser drei Teile, der USB-Host, ist das Computersystem, welches den USB-Kern-Hub enthält bzw. inkorporiert und die Basis des USB-Systems bildet. Der zweite Teil, die USB-Geräte, weisen die peripheren und funktionellen Geräte auf, die mit dem Computersystem verbunden werden sollen. USB-"Geräte" kann sich auch auf die Hubs beziehen, die mit dem USB verbunden werden können, um zusätzliche Anschlüsse für die Anbringung bereitzustellen. Der dritte Teil, die USB-Verbindung, weist die physikalischen Verbindungen zwischen den USB-Geräten und dem USB-Host auf, ebenso wie die Art und Weise, in welcher die Geräte mit dem Host kommunizieren.
Es gibt in jedem USB-System einen einzelnen Host. Der Host ist das Computersystem, in welchem das USB-System implementiert ist. Der Host beinhaltet den Kern-Hub des USB, welcher ein oder mehrere Anbringungspunkte für Geräte oder für andere Hubs bereitstellt. Ein Host-Controller stellt die Schnittstelle zwischen dem Hub und dem USB bereit. Der Host-Controller kann in Form von Hardware, Firmware oder Software oder in einer Kombination hieraus implementiert sein.
Die USB-Geräte sind funktionelle Geräte, die gewisse Fähigkeiten für das System bereitstellen (beispielsweise ein ISDN-Modem, ein Joystick oder ein Satz von Lautsprechern). Die USB-Geräte können auch Hubs sein, welche zusätzliche Anbringpunkte für den USB bereitstellen, an welchen zusätzliche Geräte angeschlossen werden können. (Geräte, die nicht Hubs sind, werden manchmal auch als Funktionen bezeichnet.) Einige USB-Geräte dienen sowohl als funktionelle Geräte als auch als Hubs, an welchen andere Geräte angebracht werden können. Die USB-Spezifikation erfordert, daß alle USB-Geräte mit gewissen Schnittstellenstandards übereinstimmen und sie stellt dadurch sicher, daß die Geräte das USB-Protokoll beinhalten und auf standardmäßige USB-Anforderungen und -Befehle reagieren.
Die physikalischen Aspekte der USB-Verbindung werden durch die Bustopologie definiert. (Auch wenn die Bustopologie nicht physikalische bzw. nicht körperliche Aspekte der USB-Verbindung umfaßt, so werden diese an anderer Stelle in der vorliegenden Offenbarung berücksichtigt.) Die Bustopologie beschreibt die Art und Weise, auf welche die USB USB-Geräte mit dem USB-Host verbindet. Gemäß 3 hat die physikalische Konfiguration der USB-Verbindung eine abgestufte Sternstruktur. Der Host hat ein Kern-Hub, welches die Basis der Verbindung bildet. Geräte und/oder zusätzliche Hubs können an dem Kern von anderen Hubs angeschlossen werden, um aufeinanderfolgende Stufen der Verbindung zu bilden. Demnach bildet jeder Hub das Zentrum eines der Sterne in der Konfiguration abgestufter Sterne. Jeder Kabelabschnitt in der Verbindung ist eine Punkt-zu-Punkt-Verbindung zwischen dem Host oder einem Hub und einem anderen Hub oder einem Gerät.
USB-Systeme unterstützen das "Hot-Plugging" (Verbinden im "heißen" bzw. aktiven Zustand). Das heißt, USB-Geräte können zu jeder Zeit an dem USB angebracht oder von diesem abgenommen werden. Der USB ist dafür ausgelegt, diese Veränderungen in seiner physikalischen Topologie zu erfassen und sich an die Veränderungen in den verfügbaren Funktionen anzupassen. Alle USB-Geräte sind an einem der Hubs mit dem USB verbunden (entweder mit dem Kern-Hub oder einem der Hubs, die sich in einer Kette von dem Stern erstrecken). Das Anbringen oder Abnehmen eines Gerätes an einem Hub wird in dem Anschlußstatus des Hubs angezeigt. Wenn ein Gerät an dem Hub angebracht wird, sendet der Hub eine Nachricht an den Host. Der Host sendet dann eine Anfrage an den Hub, um festzustellen, aus welchem die Nachricht an den Host gesendet wurde. In Reaktion auf diese Anfrage sendet der Hub die Nummer des Anschlusses, an welchem das Gerät mit dem Host verbunden wurde. Der Host schaltet dann diesen Anschluß frei und beginnt eine Kommunikation mit dem Gerät über die Steuerleitung (Null-Endpunkt). Der Host stellt fest, ob das angebrachte Gerät ein Hub oder eine Funktion ist und ordnet dem Gerät eine eindeutige USB-Adresse zu. Die eindeutige USB-Adresse und der Null-Endpunkt des Gerätes werden als eine Steuerleitung für das Gerät verwendet. Wenn das neu angebrachte Gerät ein Hub ist, an dessen Anschlüssen bereits Geräte angebracht sind, wird derselbe Vorgang für jedes der angebrachten Geräte wiederholt. Nachdem ein Gerät angebracht worden ist und Kommunikationen zwischen dem Gerät und dem Host bereitgestellt wurden bzw. stattgefunden haben, werden Nachrichten an die interessierte Host-Software gesendet.
Wenn ein Gerät von einem Hub entfernt wird, so setzt der Hub den Anschluß außer Betrieb, an welchem das Gerät angebracht war und sendet eine Nachricht über die Entfernung des Gerätes an den Host. Der Host entfernt dann das Gerät und die zugehörigen Daten von irgendwelchen dadurch beeinflußten Datenstrukturen. Wenn das weggenommene Gerät ein Hub ist, an welchem andere Geräte angebracht sind, so wird der Entfernungsvorgang für jedes der Geräte wiederholt, welches an dem weggenommenen Hub angebracht war. Nachrichten werden an interessierte Host-Software gesendet und zeigen an, daß die entfernten Geräte nicht mehr verfügbar sind.
Auch wenn die physikalische Topologie der USB-Verbindung die Konfiguration abgestufter Sterne hat, ist die logische Topologie des Systems ein einfacher Stern, wie es in 4 dargestellt ist. Alternativ kann die logische Konfiguration als eine Serie direkter Verbindungen zwischen den individuellen USB-Geräten und einer Client-Softwareanwendung auf dem Host betrachtet werden. Die logische Beziehung der Client-Software zu den Geräten kann man sich auch als eine oder mehrere direkte Verbindungen zwischen der Client-Software und den speziellen Funktionen vorstellen, welche durch die Geräte bereitgestellt werden. Während die Betrachtung der logischen Konfiguration als eine Serie direkter Verbindungen für die meisten Vorgänge zutreffend ist, ist sich das System über die abgestufte physikalische Topologie bewußt, so daß Geräte stromabwärts von einem weggenommenen bzw. entfernten Hub aus der logischen Konfiguration entfernt werden können, wenn der Hub entfernt wird (siehe die obige Diskussion des Austauschs im heißen Zustand).
Der USB stellt eine Einrichtung für Kommunikationen zwischen Client-Software, welche auf dem Host läuft, und Funktionen bereit, die auf den USB-Geräten bereitgestellt werden. Die 5 und 6 veranschaulichen den Strom von Daten, welche in der Kommunikation zwischen der Client-Software und den Gerätefunktionen hin- und herlaufen. Die Figuren zeigen den Host als einen, der drei Komponenten aufweist: die Client-Software, die USB-Systemsoftware (einschließlich USB-Treiber, Host-Steuerungstreiber und Host der Software), und USB-Host-Steuerung. Der Host-Steuerungstreiber bildet eine Schnittstelle der Host-Steuerung zu der USB-Systemsoftware und der USB-Treiber bildet eine Schnittstelle der USB-Systemsoftware mit der Client-Software. 5 zeigt, daß das USB-Gerät auch drei Komponenten aufweist: die Funktion, die logische Einrichtung und die Busschnittstelle des USB.
Während der logische Informationsstrom zwischen der Client-Software und der Funktion direkt ist, zeigt die Figur, daß der aktuelle Datenstrom von der Client-Software zu der USB-Systemsoftware, zu dem USB-Host-Controller, zu der USB-Busschnittstelle, zu der logischen Einrichtung des USB und schließlich zu der Funktion geht. In ähnlicher Weise muß, auch wenn der logische Strom von Steuerungsinformation von der USB-Systemsoftware zu der logischen USB-Einrichtung direkt erfolgt, der aktuelle Informationsstrom durch die Host-Steuerung und die Busschnittstelle verlaufen.
Gemäß 7 wird ein logisches USB-Gerät von dem USB-System als eine Schnittstelle angesehen, die durch eine Ansammlung von Endpunkten gebildet wird. Ein Endpunkt ist ein in einer eindeutigen Weise identifizierbarer Bereich eines USB-Gerätes, welcher das Ende eines Kommunikationspfades von dem Host zu dem Gerät bildet. Software kann mit einem USB-Gerät nur über seine Endpunkte kommunizieren. (Der Kommunikationsstrom wird in der Figur durch die Pfeile veranschaulicht.) Die Nummer jedes Endpunktes wird durch den Entwickler des Gerätes festgelegt. Die Kombination einer Geräteadresse (die von dem System zum Zeitpunkt des Anbringens des Gerätes zugewiesen wird) und die Nummer des Endpunktes ermöglichen es, daß jeder Endpunkt in eindeutiger Weise identifiziert wird.
Alle USB-Geräte müssen einen Endpunkt mit der Nummer 0 haben. Dieser Endpunkt wird verwendet, um das logische Gerät zu initialisieren und zu manipulieren (beispielsweise zu konfigurieren). Der Endpunkt 0 stellt einen Zugriff auf die Konfigurationsinformation des Gerätes bereit und ermöglicht den Zugriff auf das Gerät für Zustands- und Steuerungszwecke. Geräte können zusätzliche Endpunkte haben, je nachdem, wie es für die Implementierung ihrer Funktionen erforderlich ist. Geräte können bis zu 16 zusätzliche Eingangsendpunkte und 16 zusätzliche Ausgangsendpunkte haben (wenn sie nicht Geräte mit voller Geschwindigkeit sind, wobei sie in diesem Fall auf eine reduzierte Anzahl von Endpunkten beschränkt sind).
Der Kommunikationspfad zwischen einem Endpunkt eines Gerätes und der Software auf dem Host wird als Leitung (pipe bzw. Rohr) bezeichnet. Eine Leitung beginnt zu existieren, wenn ein USB-Gerät konfiguriert wird. Softwareklienten verlangen normalerweise Datenübertragungen über I/O-Anforderungspakete (IRPs) an eine Leitung. Die Software-Clients warten dann entweder oder sie werden benachrichtigt, wenn die Anforderungen abgearbeitet sind. Der Endpunkt 0 hat eine zugeordnete Pipe, die Standardpipe bzw. -leitung genannt wird. Die Standardleitung wird von der Systemsoftware verwendet, um eine Geräteidentifizierung und Konfigurationserfordernisse zu bestimmen und das Gerät zu konfigurieren. Die Standardleitung kann auch von gerätespezifischer Software verwendet werden, nachdem das Geräte konfiguriert worden ist, jedoch behält die USB-Systemsoftware die "Inhaberschaft" der Standardleitung und kontrolliert deren Verwendung durch Client-Software.
Gemäß 8 ist die Softwarestruktur einer Ausführungsform der Erfindung dargestellt. Die Client-Software weist in dieser Ausführungsform eine Testanwendung 30 und einen Testatwendungstreiber 31 auf. Die USB-Systemsoftware 32 weist einen USB-Treiber 33 und einen Host-Steuerungstreiber 34 auf. Der USB-Treiber 33 und der Host-Steuerungstreiber 34 sind Teil der Unterstützung des USB-Rahmens. Die Unterstützung des USB-Rahmens ist eine Implementierung der USB-Systemsoftware auf Solaris-Basis und umfaßt einen Satz von Schnittstellen (USB-Architekturschnittstellen oder USBAI), die es dritten Anbietern erlaubt, USB-Client-Treiber auf einer Solaris-SPARC-Plattform zu schreiben.
Die Testanwendung 30 umfaßt Module, die dafür ausgelegt sind, das Testen der verschiedenen Funktionen des USB-Systems zu steuern. In diesem Fall stimmt die Trennung der Fähigkeiten der Module im wesentlichen mit der Trennung der USB-Funktionalitäten überein, die in der USB-Spezifikation definiert sind. Beispielsweise steuert ein Modul 35 das Testen von standardmäßigen Geräteanforderungen, welche in Kapitel 9 der Beschreibung definiert sind, während ein anderes Modul 36 das Testen von Anforderungen an den Hub-Standard steuert, wie es in Kapitel 11 definiert ist, und ein weiteres Modul 38 steuert das Testen von USBAI-Funktionen. Ein Übersetzermodul 37 stellt nicht das Testen eines separaten Satzes von Funktionen bereit, sondern unterstützt stattdessen das Testen aller USB-Funktionen. Diese Module sind alle mit dem Hauptteil 39 der Testanwendung wirksam verbunden.
Der Testanwendungstreiber 31 ist in ähnlicher Weise aufgebaut und hat einen Haupttreiberbestandteil 40 und mehrere Module 41–44, welche den Modulen der Anwendung 30 entsprechen. Der Testanwendungstreiber 31 ist ein ladbarer Treiber. Das heißt, wenn ein USB-Gerät im heißen (aktiven) Zustand angeschlossen wird, lädt der Rahmen der USB-Architektur den Treiber und erzeugt einen Geräteknoten für das neu installierte Gerät. Wenn das Gerät im heißen bzw. aktiven Zustand abgetrennt wird, wird der Treiber bezüglich des abgenommenen Gerätes wieder ausgeladen.
Die Testanwendung kann man auf irgendeinem USB-Gerät ablaufen lassen, nachdem sie installiert ist. In einer Ausführungsform nimmt die Anwendung, welche primär durch das Übersetzermodul gesteuert wird, einen Geräteknoten als ein Argument, öffnet den Geräteknoten und baut Zustandsinformation für das Gerät auf der Basis von Deskriptorinformation auf, welche von dem Gerät erhalten wurde. Der Anwendungstreiber 31 hält den Gerätezustand für die Verwendung beim Testen des Gerätes aufrecht. Systemtestressourcen werden auf der Basis der aufgebauten Zustandsinformation zugewiesen. Die Zustandsinformation wird auch als Basis der Testanforderungen verwendet, welche durch die Anwendung 30 formuliert werden können. Die Testanforderungen werden dem USBI-Modul 43 des Testanwendungstreibers 31 weitergeleitet, welcher die Testparameter decodiert und validiert. Wenn die Testparameter gültig sind (d.h. innerhalb der erlaubten Grenzwerte der Parameter liegen), bauen die Testanwendung 30 und der Anwendungstreiber 30 unter Verwendung von USBAI-Funktionen Testfälle auf. Die entsprechenden Funktionsaufrufe werden an den USB-Treiber gesendet, der die Funktionen ausführt. Der Testanwendungstreiber 31 aktualisiert die Zustandsinformation für das Gerät, wenn die Funktionsaufrufe ausgegeben werden und benachrichtigt die Testanwendung 30 über den Bestanden/Nicht-Bestanden-Zustand der Tests, nachdem die Testfunktionen ausgeführt worden sind. Die Testanwendung 30 benachrichtigt dann den Benutzer.
In einer Ausführungsform durchläuft die Testanwendung eine Folge von Tests, um alle USBAI-Funktionsaufrufe zu verifizieren. Die Anwendung öffnet einen Geräteknoten, baut Zustandsinformation für das Gerät auf und weist auf der Basis der Zustandsinformation Systemressourcen zu. Das USBAI-Modul 38 der Testanwendung 30 formuliert Testanforderungen und Parameter auf der Basis der Zustandsinformation und leitet die Testanforderungen und Parameter an das USBAI-Modul 42 des Testanwendungstreibers 31 für eine Validierung. Nach der Validierung der Testanforderungen und Parameter formuliert das USBAI-Modul des Testanwendungstreibers eine Serie von Testfällen unter Verwendung der USBAI-Funktionen. Das USBAI-Modul des Testanwendungstreibers macht dann USBAI-Funktionsaufrufe, welche den Testfällen der USB-Systemsoftware entsprechen. Das USBAI-Modul des Testanwendungstreibers liefert eine Anzeige über ein Bestanden oder Nicht-Bestanden an die Testanwendung, nachdem die Ergebnisse der Funktionsaufrufe analysiert worden sind. Derselbe Vorgang wird für alle Endpunkte in dem ausgewählten USB-Gerät wiederholt. Die Testanwendung kann sich in mehrere Stränge verbreitern, um ein gleichzeitiges Testen der verschiedenen Endpunkte zu ermöglichen. Einige Ausführungsformen können auch ein gleichzeitiges Testen mehrerer USB-Geräte bereitstellen.
In ähnlicher Weise kann die Testanwendung eine Folge von Tests durchlaufen, um zu bestätigen, daß ein USB-Gerät geeignete Geräteinformation in Reaktion auf alle standardmäßigen Geräteanforderungen bereitstellt, welche in der USB-Spezifikation definiert sind. Die Anwendung öffnet erneut einen Geräteknoten, baut Zustandsinformation für das Gerät auf und weist Systemressourcen auf der Basis der Zustandsinformation zu. Alle Standardgeräteanforderungen sind in einer Anforderungsstruktur verpackt, die an den Testanwendungstreiber geleitet wird. Das Modul 41 des Testanwendungstreibers 31 nach Kapitel 9 validiert die Befehle in der Anforderungsstruktur und leitet dann die Anforderungen an das USB-Gerät über die Standardleitung weiter. Die durch das Gerät in Reaktion auf die Standardgeräteanforderungen bereitgestellte Information wird dann an die Testanwendung zurückgeliefert.
Verschiedene Ausführungsformen der Erfindung können unterschiedliche Merkmale enthalten. Ein solches Merkmal ist ein Befehlsleitungsbetrieb. Im Befehlsleitungsbetrieb kann ein Benutzer individuelle Befehle eingeben, die durch die Anwendung interpretiert bzw. übersetzt und ausgeführt werden, um bestimmte Funktionen des USB-Systems zu testen. Dies kann ein überflüssiges Testen beseitigen bzw. vermeiden, welches durch eine umfangreiche Folge von Tests ausgeführt werden würde. Befehle können jedoch auch so eingestellt werden, daß eine Reihe von Vorgängen anstelle eines einzelnen Vorgangs ausgeführt wird.
Der Befehlsleitungsbetrieb ermöglicht es der Testanwendung auch, daß sie aus der Ferne verwendet wird. Mit anderen Worten, der Benutzer muß nicht körperlich anwesend sein, um das USB-System zu testen. Der Benutzer kann stattdessen Kommunikationen mit dem Testsystem herstellen und durch das Kommunikationsverbindungsglied Befehle eingeben. Beispielsweise kann der Benutzer eine Modemverbindung zwischen einem entfernten Computer und dem Testsystem bereitstellen und dann über die Modemverbindung Befehle eingeben. Das Verbindungsglied kann irgendwelche geeigneten Einrichtungen für die Kommunikation verwenden und das vorstehende Beispiel eines Verbindungsgliedes auf Modembasis soll lediglich der Anschauung dienen, anstatt beschränkend zu sein.
Der Benutzer kann auch Befehle ausführen, die sich nicht auf das Testsystem beziehen (beispielsweise Unix Shell-Befehle), ohne daß die Testsitzung unterbrochen werden muß. Die Zeit, die normalerweise erforderlich ist, um andere Testsysteme zu starten und abzuschließen, um Nicht-Systemfunktionen auszuführen, kann dadurch vermieden werden. Der Befehlsleitungsbetrieb kann so ausgestaltet sein, daß er die verfügbaren Befehle unter einem anderen Namen in eine eindeutige Liste eingibt, um den Umfang des erforderlichen Schreibens zu vermindern. Das Testsystem kann auch so ausgestaltet werden, daß es eine Online-Hilfe bereitstellt, um die Interaktion des Benutzers mit dem System zu ermöglichen.
Eine Ausführungsform des Testsystems ist mit einem Funktionsbetrieb ausgestaltet, in welchem das System in einzelnen Schritten eine USBAI-Funktion durchlaufen kann. Dies kann zweckmäßig sein, wenn der Benutzer den Verkehr auf dem USB untersuchen muß. Nachdem ein USBAI-Funktionsbefehl ausgegeben worden ist, kann der USB-Verkehr unter Verwendung eines Logikanalysators untersucht werden, während jede einzelne Stufe der Funktion ausgeführt wird. Dies kann ein wertvolles Fehlersuchmerkmal sein.
Ein anderes Merkmal, welches enthalten sein kann, ist die Fähigkeit des Umschaltens von Anschlüssen während des Testens. Wie oben erwähnt, ist das System dafür ausgelegt, eine Gerätenumerierung auszuführen, d.h. wenn mehrere USB-Geräte mit dem System verbunden sind, so kann es alle angeschlossenen Geräte auflisten und Zustandsinformation, wie z.B. die Anschlußnummer, den Gerätetyp, die Geräteklasse und den Pfad für jedes der Geräte aufbauen. Der Benutzer kann das Gerät an einem bestimmten Anschluß für gewisse Tests auswählen und dann zu einem anderen Anschluß umschalten und das an diesem Anschluß angeschlossene Gerät testen.
Zusätzlich zu der Bestimmung der Geräteinformation zum Zwecke des Testens der Geräte kann das Testsystem so ausgestaltet sein, daß es diese Information für den Benutzer verfügbar macht. Die Information, wie z.B. Gerätedeskriptoren, kann in einem Matrixformat angezeigt werden, um es dem Benutzer zu ermöglichen, Seite für Seite die Eigenschaften der individuellen Geräte zu vergleichen. Da die Busnumerierung eine fortgesetzte Aktivität in dem USB-System ist, werden Ge räte erkannt, wenn sie mit dem USB verbunden werden und die Information, die normalerweise auf diesen Geräten erhalten wird, kann zusammen mit Information für zuvor installierte Geräte angezeigt werden. In ähnlicher Weise kann Information, welche Geräten entspricht, die von dem USB-System abgenommen wurden, aus der Anzeige entfernt werden.
In einer Ausführungsform können die Befehle, die in das Testsystem eingegeben werden können, in vier Kategorien eingeteilt werden: Befehle, die sich auf Gerätezustandsinformation beziehen, standardmäßige Geräteanforderungsbefehle, Schnittstellenbefehle der USB-Architektur und verschiedene bzw. sonstige Befehle. Auch wenn eine Anzahl dieser Befehle unten aufgelistet sind, so soll diese Liste jedoch nicht beschränkend sein. Man kann sich vorstellen, daß die USB-Spezifikation verbessert werden kann, um zulässige Befehle hinzuzufügen, zu löschen oder zu modifizieren, um eine Anpassung an die sich ändernde Funktionalität des USB vorzunehmen, und das Testsystem kann so angepaßt werden, daß es die neuen Befehle und Funktionen des USB umfaßt.
Die Befehle der Gerätezustandsinformation sind in Tabelle 1 zusammen mit ihren entsprechenden Funktionen wiedergegeben. Gerätezustandsinformation wird für die numerierten Geräte verfolgt und durch das Testsystem identifiziert. Wenn auf einen Endpunkt eines Gerätes zugegriffen wird, wird sein Zustand in dem Testsystem aktualisiert.
Tabelle 1
Die Standardgeräteanforderungen sind in Kapitel 9 der USB-Spezifikation definiert. Die Standardgeräteanforderungen sind in Tabelle 2 zusammen mit ihren entsprechenden Funktionen dargestellt. Alle USB-Geräte müssen auf Standardgeräteanforderungen von dem Host reagieren. Diese Anforderungen werden unter Verwendung von Steuerungsübertragungen über die Standardleitung des Gerätes vorgenommen. Die Anforderung und die Parameter der Anforderung werden in dem Einrichtungspaket an das Gerät gesendet.
Tabelle 2
Die USBAI-Befehle sind in Tabelle 3 zusammen mit ihren entsprechenden Funktionen wiedergegeben. Die USBAI-Befehle werden an einen bestimmten Endpunkt eines ausgewählten Gerätes ausgegeben. Die USBAI-Funktionen, welche diesen Befehlen entsprechen, können in einem Einzelstufenbetrieb ausgeführt werden, um es dem Benutzer zu ermöglichen, den Verkehr auf dem USB zu untersuchen.
Tabelle 3
Zusätzlich zu den vorstehenden Befehlen sieht die Testanwendung noch die folgenden Befehle vor (siehe Tabelle 4).
Tabelle 4
Während die vorliegende Erfindung unter Bezug auf besondere Ausführungsformen beschrieben worden ist, versteht es sich, daß nur Ausführungsformen dargestellt wurden und daß der Schutzumfang der Erfindung in dieser Weise nicht eingeschränkt ist. Jegliche Variationen, Modifikationen, Hinzufügungen und Verbesserungen der beschriebenen Ausführungsformen sind möglich. Diese Variationen, Modifikationen, Hinzufügungen und Verbesserungen können in den Schutzumfang der Erfindung fallen, wie er im einzelnen in den folgenden Ansprüchen dargelegt ist.

Claims

Testsystem für die Feststellung, ob ein universelles, serielles Bus(USB)-System einen Satz vorbestimmter Spezifikationen erfüllt, mit: einem Computersystem (10), wobei das Computersystem dafür ausgelegt ist, zumindest eine Testanwendung und eine USB-Systemsoftware (32) auszuführen, und wobei das Computersystem eine Host-Steuerung (20) aufweist, einem USB-Anschluß (21), der mit dem Computersystem verbunden ist und der dafür ausgelegt ist, durch die Host-Steuerung gesteuert zu werden, wobei das Computersystem dafür ausgelegt ist, Testbefehle von einem Benutzer über einen USB-Übersetzer (30, 31) anzunehmen, wobei die Ausführung jedes der Testbefehle einem entsprechenden USB-Systemvorgang zugeordnet ist, und wobei der Vorgang bei Ausführung des Testbefehls durchgeführt wird.
Testsystem nach Anspruch 1, wobei das Computersystem eine Unix-Betriebsumgebung aufweist, wobei der USB-Übersetzer einen Befehlszeilen-Übersetzer aufweist, der dafür ausgelegt ist, die Testbefehle über individuell eingegebene Befehlszeilen anzunehmen, und wobei der Benutzer sowohl Unix-Befehle als auch die Testbefehle eingeben kann, wobei die Testbefehle durch das Testsystem ausgeführt werden und die Unix-Befehle durch eine Unix-Ebene ausgeführt werden.
Testsystem nach Anspruch 1 oder 2, wobei der USB-Übersetzer dafür ausgelegt ist, eine vorbestimmte Serie von Operationen in Reaktion auf eine Benutzereingabe auszuführen.
Testsystem nach Anspruch 3, wobei die Serie von Operationen bzw. Vorgängen einen Satz aus standardmäßigen USB-Geräteanforderungen aufweist.
Testsystem nach Anspruch 3, wobei die Serie von Operationen einen Satz von USB-Architekturfunktionen aufweist.
Testsystem nach einem der vorstehenden Ansprüche, welches weiterhin eine Kommunikationsverbindung zwischen dem Computersystem und einem fern gelegenen Ort aufweist und wobei die Testbefehle von dem fern gelegenen Ort über die Kommunikationsverbindung in das Computersystem eingegeben werden.
Testsystem nach Anspruch 6, wobei Daten, die als Ergebnis einer Ausführung des Testbefehls erzeugt werden, über die Kommunikationsverbindung an den fern gelegenen Ort gesendet werden.
Testsystem nach einem der vorstehenden Ansprüche, welches weiterhin ein oder mehrere USB-Geräte (22) aufweist, die mit dem USB-Anschluß verbunden sind.
Testsystem nach Anspruch 8, wobei der USB-Übersetzer dafür ausgelegt ist, die einen oder mehreren Geräte aufzuzählen und Daten für den Benutzer anzuzeigen, welche die aufgezählten Geräte repräsentieren, und wobei der USB-Übersetzer weiterhin dafür ausgelegt ist, die Auswahl eines der aufgelisteten Geräte zu ermöglichen.
Testsystem nach Anspruch 8, wobei der USB-Übersetzer dafür ausgelegt ist, das eine oder die mehreren Geräte aufzuzählen bzw. aufzulisten und wobei die Testbefehle dafür ausgelegt sind, für die Operation ein bestimmtes Gerät aus der Geräteliste zu bezeichnen bzw. auszuwählen.
Testsystem nach Anspruch 8, wobei jedes des einen oder der mehreren Geräte einen oder mehrere Endpunkte hat und wobei die Testbefehle dafür ausgelegt sind, einen bestimmten dieser Endpunkte für die Operation anzugeben.
Testsystem nach Anspruch 8, wobei der USB-Übersetzer und die USB-Systemsoftware dafür ausgelegt sind, das Anschließen eines oder mehrerer zusätzlicher Geräte an dem Anschluß zu erkennen und wobei der USB-Übersetzer und die USB-Systemsoftware dafür ausgelegt sind, das Entfernen eines oder mehrerer der Geräte von dem Anschluß zu erkennen.
Testsystem nach Anspruch 8, wobei der USB-Übersetzer dafür ausgelegt ist, Statusinformationen zu speichern, die zumindest einem der Geräte zugeordnet sind.
Testsystem nach Anspruch 8, wobei der USB-Übersetzer dafür ausgelegt ist, eine oder mehrere Leitungen bzw. Durchgänge und einen oder mehrere entsprechende Endpunkte in den Geräten bereitzustellen.
Testsystem nach einem der vorstehenden Ansprüche, wobei der USB-Systembetrieb eine mehrstufige Funktion ist und wobei das Testsystem dafür ausgelegt ist, den USB-Systembetrieb in einem Einzelstufenbetrieb auszuführen.
Testsystem nach Anspruch 15, welches weiterhin einen Logikanalysator aufweist, der mit dem USB-Anschluß verbunden ist, wobei der Logikanalysator dafür ausgelegt ist, Daten zu erzeu gen, die Signalverkehr auf dem USB-System während der Ausführung des USB-Systembetriebs anzeigen.
Verfahren zum Testen einer Funktion eines universellen, seriellen Bus(USB)-Systems eines Computers (10), wobei das USB-System einen USB-Anschluß (21), eine oder mehrere USB-Schnittstellen und eine oder mehrere USB-Geräte (22) hat, wobei das Verfahren aufweist: Eingeben eines Testbefehls in den Computer, Übersetzen des Testbefehls unter Verwendung eines Befehlszeilen-Übersetzers, wobei der Befehlszeilen-Übersetzer einen USB-Übersetzer (30, 31) aufweist, Ausführen einer Operation, die zu dem Testbefehl gehört, Senden eines Testsignals an das USB-System, und Gültigmachen eines Testergebnisses, welches durch das USB-System erzeugt wurde, in Reaktion auf das Testsignal.
Verfahren nach Anspruch 17, wobei die Operation eine USB-Schnittstellenfunktion ist und wobei das Testsignal an eine der USB-Schnittstellen des USB-Systems gesendet wird.
Verfahren nach Anspruch 17, wobei die Operation eine standardmäßige Geräteanforderung ist und wobei das Testsignal an eines von dem einen oder den mehreren USB-Geräten des USB-Systems gesendet wird.
Verfahren nach Anspruch 17, 18 oder 19, wobei der Computer über eine Kommunikationsverbindung mit einem fern gelegenen Ort verbunden ist und wobei das Eingeben des Testbefehls das Eingeben des Testbefehls an dem fern gelegenen Ort und das Senden des Testbefehls über die Kommunikationsverbindung an den Computer umfaßt.
Verfahren nach Anspruch 17, 18, 19 oder 20, welches weiterhin das Eingeben eines Oberflächenbefehls (shell command) in den Computer und das Ausführen des Oberflächenbefehls auf einer Oberfläche des Betriebssystems, welches auf dem Computer läuft, umfaßt.
Verfahren nach einem der Ansprüche 17 bis 20, wobei das Ausführen der Operation in einem Einzelschritt- bzw. Einzelstufenbetrieb erfolgt.
Verfahren nach einem der Ansprüche 17 bis 22, welches weiterhin aufweist: Erzeugen eines Knotens, welcher dem einen von dem einen oder den mehreren USB- Geräten entspricht, Öffnen des Knotens, Erhalten von Zustandsinformation für das eine von dem einen oder den mehreren USB-Geräten, Speichern der Zustandsinformation, Ausführen eines oder mehrerer Tests auf der Basis der Zustandsinformation, wobei jeder des einen oder der mehreren Tests einer bestimmten Funktion des USB-Systems entspricht, und Gültigmachen der Ergebnisse des einen oder der mehreren Tests.
Verfahren nach Anspruch 23, wobei das Erzeugen des Computerknotens das Spezifizieren des USB-Systems zum Identifizieren des einen oder der mehreren USB-Geräte und das Erzeugen von Knoten für die Geräte aufweist.
Verfahren nach Anspruch 24, wobei das Erhalten von Zustandsinformation für das eine oder die mehreren USB-Geräte das Anfordern von einem oder mehreren Deskriptoren von dem einen, des einen oder der mehreren USB-Geräte aufweist.
Verfahren nach Anspruch 25, wobei die Tests Tests von USBAI-Funktion aufweisen.
Verfahren nach Anspruch 26, wobei die Tests weiterhin Tests von standardmäßigen Geräteanforderungsfunktionen aufweisen.