-
Die
vorliegende Erfindung bezieht sich auf die Überwachung, Konfiguration oder
Installation von Hardware auf einem Computersystem.
-
Computersysteme
enthalten im Allgemeinen Hardware und Software. Die Hardware ist
der eigentliche physikalische Berechnungsmechanismus, während die
Software die Liste von Anweisungen ist, mit denen die Hardware betrieben
wird. Üblicherweise
enthalten Computersysteme eine Vielfalt von Hardwarevorrichtungen, die
miteinander eine Schnittstelle bilden. Wenn Hardwarevorrichtungen
miteinander eine Schnittstelle bilden, muss die Software, die die
Hardware betreibt, so konfiguriert sein, dass sie eine Kommunikation
zwischen den Hardwarevorrichtungen ermöglicht, damit die Hardwarevorrichtungen
kooperativ arbeiten können.
Außerdem ist
es wünschenswert,
dass Hardwarevorrichtungen überwacht
werden. Für
die Zwecke der Besprechung wird eine Hardwarevorrichtung, die konfiguriert
oder überwacht,
als Steuervorrichtung bezeichnet. Ebenso wird für die Zwecke der Besprechung
die Hardwarevorrichtung, die konfiguriert wird, um kooperativ zu
arbeiten oder um durch die Steuervorrichtung überwacht zu werden, als Kopplungsvorrichtung
bezeichnet.
-
Wenn
Hardwarevorrichtungen zu Beginn miteinander eine Schnittstelle bilden,
ist es bei der Software, die die Vorrichtungen betreibt, häufig der
Fall, dass sie unkonfiguriert bleibt, um einen kooperativen Betrieb
zu ermöglichen.
Dementsprechend konfiguriert ein erheblicher Teil von installierenden
Computerhardware-Vorrichtungen die Software kollektiv. Bei einigen
Anordnungen muss ein Anwender die Computerhardware von Hand konfigurieren,
indem er die Computerhardware öffnet
und Steckbrücken
oder DIP-Schalter physikalisch einstellt. Bei einigen weiteren Anordnungen
umfasst der Installationsprozess, dass der Anwender von einer Diskette
Software lädt,
um die Hardwarevorrichtungen zu konfigurieren. Es gab bei Computerhardware-Vorrichtungen
auch Versuche, Software in sie zu integrieren, die Hardwarevorrichtungen
automatisch konfigurieren kann. Jedoch bestehen im Hinblick auf
die oben angegebenen Ansätze
einige offenkundige Nachteile und Mängel.
-
Ein
Nachteil besteht darin, dass eine automatische Hardwareinstallations-Software in ihrer
Fähigkeit begrenzt
ist, sich an neue Vorrichtungen oder neue Hersteller anzupassen,
die in der Software nicht speziell programmiert wurden. Nach dem
Stand der Technik ist eine automatische Konfiguration nicht möglich, falls
die Steuervorrichtung das bestimmte Modell der Kopplungsvorrichtung
nicht erkennt. Mit anderen Worten: Falls die Steuervorrichtung nicht
so programmiert ist, dass sie das Modell einer Kopplungsvorrichtung
antizipiert, dann ist eine automatische Hardwarekonfiguration nicht
erfolgreich. In einem solchen Fall muss ein Anwender die Konfigurations-Kommunikationsmittel
für die
Hardwarevorrichtungen von Hand installieren.
-
Ein
weiterer Nachteil nach dem Stand der Technik liegt darin, dass die
Steuervorrichtung nicht in der Lage ist, Hardwarevorrichtungen teilweise
zu konfigurieren, falls das bestimmte Modell der Kopplungsvorrichtung
nicht identifiziert werden kann. Mit anderen Worten: Falls eine
Steuervorrichtung ein bestimmtes Modell der Kopplungsvorrichtung
nicht identifizieren kann, dann wird die Kopplungsvorrichtung nicht
so konfiguriert, dass sie kooperativ arbeitet. Dies führt dazu,
dass die unkonfigurierte Kopplungsvorrichtung nicht betriebsfähig und
im Wesentlichen nutzlos ist.
-
Für Hardwarevorrichtungen,
die sich in einem Netz befinden, ist es wünschenswert, dass sie für die Wartung,
die Nutzung oder andere Zwecke überwacht
werden. Jedoch war es angesichts der zwischen Herstellern und Modellen
von Kopplungsvorrichtungen unterschiedlichen Kommunikationsmittel
für eine
Steuervorrichtung schwierig, mit verschiedenen Kopplungsvorrichtungen
in einem Netz zu kommunizieren. Diese Nachteile hindern Netzadministratoren
daran, entscheidende Informationen über das Verhalten und die Effizienz
von Kopplungsvorrichtungen in einem Netz zu erhalten.
-
US 6.122.639 offenbart ein
Netz, in dem Informationen über
Vorrichtungen in dem Netz gesammelt werden.
-
US 6.349.306 offenbart eine
Vorrichtung und ein Verfahren zum Überwachen von Parametern, die
die Betriebseigenschaften einer Netzvorrichtung bestimmen.
-
Die
vorliegende Erfindung bezieht sich auf ein Verfahren und ein System,
um wenigstens eine an ein Netz angeschlossene Vorrichtung (überwachte
Vorrichtung) unter Verwendung einer Steuereinheit zu überwachen.
-
In Übereinstimmung
mit der vorliegenden Erfindung wird ein Verfahren geschaffen, um
zu bestimmen, ob eine überwachte
Vorrichtung durch ein Überwachungssystem
in einem netzbasierten System, das das Überwachungssystem und mehrere überwachte
Vorrichtungen, die über
ein Netz kommunikativ gekoppelt sind, umfasst, unterstützt wird,
wobei das Überwachungssystem
mit einer ersten und einer zweiten Datenbank kommunikativ gekoppelt
ist, wobei das Verfahren die folgenden Schritte umfasst:
- (a) Abfragen der überwachten Vorrichtung, um
einen Hersteller und/oder ein Modell und/oder eine eindeutige Kennung
der überwachten
Vorrichtung zu erhalten;
- (b) Bestimmen, ob das Überwachungssystem
so konfiguriert ist, dass es mit der überwachten Vorrichtung eine
Schnittstelle bildet, unter Verwendung von in der ersten Datenbank
gespeicherten Informationen;
- (c) Bestimmen, ob die überwachte
Vorrichtung durch das Überwachungssystem
unterstützt
wird, unter Verwendung von in der zweiten Datenbank, gespeicherten
Informationen durch:
- (i) Bestimmen, ob ein Hersteller der überwachten Vorrichtung durch
das Überwachungssystem
unterstützt wird,
- (ii) Erhalten einer Seriennummer und/oder einer eindeutigen
Kennung von der überwachten
Vorrichtung, falls der Hersteller durch das Überwachungssystem unterstützt wird;
- (iii) Erhalten einer MAC-Adresse der überwachten Vorrichtung, falls
der Hersteller durch das Überwachungssystem
nicht unterstützt
wird; und
- (iv) Zuweisen einer Zufallszahl zu der eindeutigen Kennung,
falls die MAC-Adresse
von der überwachten Vorrichtung
nicht erhalten werden kann.
-
Gemäß einem
weiteren Aspekt der Erfindung wird eine Vorrichtung zum Überwachen
wenigstens einer überwachten
Vorrichtung unter mehreren überwachten
Vorrichtungen in einem netzbasierten System, die mit einem Netz
kommunikativ gekoppelt sind, geschaffen, wobei die Vorrichtung umfasst:
ein Überwachungssystem,
das mit dem Netz kommunikativ gekoppelt ist;
eine erste Datenbank
und eine zweite Datenbank, die mit dem Überwachungssystem kommunikativ
gekoppelt sind;
Mittel, um die überwachte Vorrichtung abzufragen,
um einen Hersteller und/oder ein Modell und/oder eine eindeutige
Kennung der überwachten
Vorrichtung zu erhalten;
Mittel, um zu bestimmen, ob das Überwachungssystem
so konfiguriert ist, dass es mit der überwachten Vorrichtung eine
Schnittstelle bildet, unter Verwendung von in der ersten Datenbank
gespeicherten Informationen;
Mittel, um zu bestimmen, ob die überwachte
Vorrichtung durch das Überwachungssystem
unterstützt
wird, unter Verwendung von in der zweiten Datenbank gespeicherten
Informationen;
Mittel, um zu bestimmen, ob ein Hersteller der überwachten
Vorrichtung durch das Überwachungssystem
unterstützt
wird;
Mittel, um eine Seriennummer und/oder eine eindeutige
Kennung von der überwachten
Vorrichtung zu erhalten, falls der Hersteller durch das Überwachungssystem
unterstützt
wird;
Mittel, um eine MAC-Adresse der überwachten Vorrichtung zu erhalten,
falls der Hersteller nicht durch das Überwachungssystem unterstützt wird;
und
Mittel, um der eindeutigen Kennung eine Zufallszahl zuzuweisen,
falls die MAC-Adresse von der überwachten Vorrichtung
nicht erhalten werden kann.
-
Gemäß einem
weiteren Aspekt der Erfindung wird ein netzbasiertes System geschaffen,
das eine überwachte
Vorrichtung unter mehreren an ein Netz angeschlossenen Vorrichtungen
besitzt, wobei das System umfasst:
eine erste Datenbank und
eine zweite Datenbank, die mit der Steuereinheit kommunikativ gekoppelt
sind, wobei die zweite Datenbank Informationen speichert, um zu
bestimmen, ob die überwachte
Vorrichtung durch die Steuereinheit unterstützt wird;
eine Steuereinheit,
um die überwachte
Vorrichtung zu überwachen,
wobei die Steuereinheit eine Logik besitzt, um:
die überwachte
Vorrichtung abzufragen, um einen Hersteller und/oder ein Modell
und/oder eine eindeutige Kennung der überwachten Vorrichtung zu erhalten;
unter
Verwendung eines hierarchischen Verfahrens zu bestimmen, ob das Überwachungssystem
so konfiguriert ist, dass es mit der überwachten Vorrichtung eine
Schnittstelle bildet, indem in der ersten Datenbank gespeicherte
Informationen verwendet werden; und
zu bestimmen, ob die überwachte
Vorrichtung durch das Überwachungssystem
unterstützt
wird, unter Verwendung von in der zweiten Datenbank gespeicherten
Informationen durch:
- (i) Bestimmen, ob ein
Hersteller der überwachten
Vorrichtung durch das Überwachungssystem
unterstützt wird,
- (ii) Erhalten einer Seriennummer und/oder einer eindeutigen
Kennung von der überwachten
Vorrichtung, falls der Hersteller durch das Überwachungssystem unterstützt wird;
- (iii) Erhalten einer MAC-Adresse der überwachten Vorrichtung, falls
der Hersteller durch das Überwachungssystem
nicht unterstützt
wird; und
- (iv) Zuweisen einer Zufallszahl zu der eindeutigen Kennung,
falls die MAC-Adresse
von der überwachten Vorrichtung
nicht erhalten werden kann,
wobei Konfigurationsinformationen
in der ersten Datenbank mit in der zweiten Datenbank gespeicherten
Informationen aktualisiert werden, um die Steuereinheit in die Lage
zu versetzen, mit der überwachten
Vorrichtung eine Schnittstelle zu bilden, um dadurch eine Flexibilität bei der
Aktualisierung von durch das Überwachungssystem überwachten
Vorrichtungen unter mehreren Vorrichtungen zu ermöglichen.
-
Es
werden ein Verfahren und eine Vorrichtung zum Bereitstellen einer
Mehrfach-Anbieter-Unterstützung
für fernüberwachte
Vorrichtungen beschrieben. Das Verfahren umfasst das Abfragen einer überwachten Vorrichtung,
um einen Hersteller und/oder ein Modell und/oder eine eindeutige
Kennung der überwachten
Vorrichtung zu erhalten; die Verwendung eines hierarchischen Verfahrens,
um unter Verwendung von in einer ersten Datenbank gespeicherten
Informationen zu bestimmen, ob das Überwachungssystem so konfiguriert
ist, dass es mit der überwachten
Vorrichtung eine Schnittstelle bildet; und das Bestimmen, unter
Verwendung von in einer zweiten Datenbank gespeicherten Informationen,
ob die überwachte
Vorrichtung durch das Überwachungssystem
unterstützt
wird. Das hierarchische Verfahren umfasst das erste Bestimmen, ob
der Hersteller der überwachten
Vorrichtung durch das Überwachungssystem
unterstützt
wird, und dann das nachfolgende Bestimmen, ob das Modell der Vorrichtung
durch das Überwachungssystem
unterstützt
wird.
-
In
beispielhaften Ausführungsformen
der vorliegenden Erfindung werden mehrere Datenbanken dazu verwendet,
Vorrichtungen mit Systemen zu konfigurieren. Diese Ausführungsformen
sind vorteilhaft, da während
der Initialisierung der Vorrichtungen mit einem System wertvolle
Computerressourcen verwendet werden, während die Computerressourcen
während
des Systembetriebs bewahrt werden. Beispielsweise kann ein System
zwei separate Datenbanken verwenden, wenn eine Vorrichtung konfiguriert
wird. Die erste Datenbank (d. h. eine Systemkonfigurations-Datenbank)
speichert Vorrichtungsinformationen für Vorrichtungen, die bereits
für das
System konfiguriert sind und wobei betriebsbezogene Statusinformationen
der Vorrichtungen gespeichert werden, während die Vorrichtungen durch
das System überwacht
werden. Derartige Vorrichtungsinformationen können den Herstellernamen und
den Modellnamen umfassen, während
betriebsbezogene Statusinformationen die Seitenzählung und den Tonerfüllstand
umfassen können.
-
Die
in der ersten Datenbank gespeicherten Vorrichtungsinformationen
werden im Lauf der Initialisierung des Systems verwendet, während die
in der ersten Datenbank gespeicherten Statusinformationen während des
Systembetriebs gesammelt werden. Daher ist die erste Datenbank groß, da sie
Statusinformationen aufnimmt. Der Bedarf an Computerressourcen ist
jedoch geringer, da die Vorrichtungsinformationen im Lauf der Initialisierung
verwendet werden, während
Statusinformationen nur hinzugefügt
werden, wenn das System in Betrieb ist.
-
Bei
einer beispielhaften Ausführungsform
der vorliegenden Erfindung verwendet das System der vorliegenden
Erfindung auch eine zweite Datenbank (d. h. eine Systemunterstützungs-Datenbank).
Diese zweite Datenbank kann relativ groß sein, da sie Daten enthält, die
sich auf mehrere Vorrichtungen beziehen. Wenn eine Vorrichtung mit
einem System initialisiert wird und das System noch nicht so konfiguriert
ist, dass es mit der Vorrichtung eine Schnittstelle bildet, dann
kann die erste Datenbank (d. h. die Systemkonfigurations-Datenbank)
unter Verwendung der Informationen aus der zweiten Datenbank (d.
h. der Systemunterstützungs-Datenbank)
aktualisiert werden, sodass die Vorrichtung mit dem System eine
Schnittstelle bilden kann. Auf Grund der großen Menge an gespeicherten
Informationen ist das Abfragen der zweiten Datenbank nicht nur zeitraubend,
sondern verwendet auch eine große
Menge an wertvollen Computerressourcen. Sobald die kritischen Informationen
(d. h. das Protokoll), die sich auf die Vorrichtung beziehen, in
der ersten Datenbank mit Informationen aus der zweiten Datenbank
aktualisiert sind, wird nur die erste Datenbank verwendet.
-
Bei
einem Aspekt schafft die vorliegende Erfindung in einem netzbasierten
System, das ein Überwachungssystem
und mehrere über
ein Netz kommunikativ gekoppelte überwachte Vorrichtungen aufweist,
wobei das Überwachungssystem
mit der ersten und der zweiten Datenbank kommunikativ gekoppelt
ist, ein Verfahren zum Bestimmen, ob eine überwachte Vorrichtung durch
das Überwachungssystem
unterstützt
wird, wobei das Verfahren umfasst: Abfragen der überwachten Vorrichtung, um
einen Hersteller und/oder ein Modell und/oder eine eindeutige Kennung
der überwachten
Vorrichtung zu erhalten; Bestimmen, ob das Überwachungssystem so konfiguriert
ist, dass es unter Verwendung von in der ersten Datenbank gespeicherten
Informationen mit der überwachten
Vorrichtung eine Schnittstelle bildet; und Bestimmen, ob die überwachte
Vorrichtung unter Verwendung von in der zweiten Datenbank gespeicherten
Informationen durch das Überwachungssystem
unterstützt
wird.
-
Der
Schritt des Bestimmens, ob das Überwachungssystem
so konfiguriert ist, dass es mit der überwachten Vorrichtung eine
Schnittstelle bildet, erfolgt durch Abfragen der ersten Datenbank
mit einem Hersteller und/oder einem Modell und/oder einer eindeutigen
Kennung, die von der überwachten
Vorrichtung erhalten werden. Der Schritt des Bestimmens, ob die überwachte
Vorrichtung durch das Überwachungssystem
unterstützt
wird, umfasst das Bestimmen, ob ein Hersteller der überwachten
Vorrichtung durch das Überwachungssystem
unterstützt
wird, und falls dies zutrifft: Bestimmen, ob ein Modell der überwachten
Vorrichtung durch das Überwachungssystem
unterstützt
wird; und Aktualisieren der ersten Datenbank mit Hersteller- und
Modellinformationen, falls die überwachte
Vorrichtung durch das Überwachungssystem
unter Verwendung von in der zweiten Datenbank gespeicherten Informationen
unterstützt
wird.
-
Das
oben erwähnte
Verfahren umfasst ferner das Erhalten einer Seriennummer und/oder
einer eindeutigen Kennung von der überwachten Vorrichtung, falls
der Hersteller durch das Überwachungssystem
unterstützt
wird; das Erhalten einer MAC-Adresse der überwachten Vorrichtung, falls
der Hersteller durch das Überwachungssystem
nicht unterstützt
wird; und das Zuweisen einer Zufallszahl zur eindeutigen Kennung, falls
die MAC-Adresse von der überwachten
Vorrichtung nicht erhalten werden kann. Das Verfahren umfasst ferner
das Auflisten der überwachten
Vorrichtung als namenlos, falls der Hersteller der überwachten
Vorrichtung durch das Überwachungssystem
nicht unterstützt
wird; das Erhalten von Informationen, die den mehreren überwachten
Vorrichtungen gemeinsam sind, von der überwachten Vorrichtung; und
das Erhalten von Informationen, die mehreren überwachten Vorrichtungen von
dem allgemeinen Hersteller gemeinsam sind.
-
Das
Verfahren umfasst ferner das Erhalten von Informationen, die für die überwachte
Vorrichtung eindeutig sind, falls das Modell der überwachten
Vorrichtung durch das Überwachungssystem
unterstützt
wird; und das Erhalten von Informationen, die überwachten Vorrichtungen gemeinsam
sind, die durch den allgemeinen Hersteller hergestellt werden. Die
erste Datenbank ist eine Systemkonfigurations-Datenbank, die umfasst: Informationen
zum Freigeben einer Kommunikation zwischen dem Überwachungssystem und der überwachten
Vorrichtung; und Statusinformationen, die auf die überwachte
Vorrichtung bezogen sind, wobei die Statusinformationen nach der
Initialisierung des Überwachungssystems
hinzugefügt
werden.
-
Der
Schritt des Bestimmens, ob das Überwachungssystem
so konfiguriert ist, dass es mit der überwachten Vorrichtung eine
Schnittstelle bildet, umfasst das Abfragen der überwachten Vorrichtung mit
in der ersten Datenbank gespeicherten Daten. Die erste Datenbank
ist eine Systemkonfigurations-Datenbank und umfasst: Informationen,
um eine Kommunikation zwischen dem Überwachungssystem und der überwachten Vorrichtung
freizugeben; und Statusinformationen, die auf die überwachte
Vorrichtung bezogen sind, wobei die Statusinformationen nach der
Initialisierung des Überwachungssystems
hinzugefügt
werden, um die überwachte
Vorrichtung zu überwachen.
Die zweite Datenbank ist eine Systemunterstützungs-Datenbank und umfasst
Informationen über
verschiedene Her steller und Vorrichtungsmodelle, die durch das Überwachungssystem
unterstützt
werden.
-
Bei
einem weiteren Aspekt schafft die vorliegende Erfindung in einem
netzbasierten System, das mehrere mit einem Netz kommunikativ gekoppelte überwachte
Vorrichtungen aufweist, eine Vorrichtung zum Überwachen wenigstens einer überwachten
Vorrichtung unter den mehreren überwachten
Vorrichtungen, wobei die Vorrichtung umfasst: ein Überwachungssystem,
das mit dem Netz kommunikativ gekoppelt ist; eine erste Datenbank
und eine zweite Datenbank, die mit dem Überwachungssystem kommunikativ
gekoppelt sind; Mittel, um die überwachte
Vorrichtung abzufragen, um einen Hersteller und/oder ein Modell
und/oder eine eindeutige Kennung der überwachten Vorrichtung zu erhalten;
Mittel, um zu bestimmen, ob das Überwachungssystem
so konfiguriert ist, dass es mit der überwachten Vorrichtung eine
Schnittstelle bildet, unter Verwendung von in der ersten Datenbank
gespeicherten Informationen; und Mittel, um zu bestimmen, ob die überwachte
Vorrichtung durch das Überwachungssystem
unterstützt
wird, unter Verwendung von in der zweiten Datenbank gespeicherten
Informationen.
-
Bei
einem wiederum weiteren Aspekt schafft die vorliegende Erfindung
ein netzbasiertes System, das ein Überwachungssystem und mehrere über ein
Netz kommunikativ gekoppelte überwachte
Vorrichtungen aufweist, wobei das Überwachungssystem mit einer
ersten und einer zweiten Datenbank und einem Computerprogrammprodukt
innerhalb eines computernutzbaren Mediums kommunikativ gekoppelt
ist, das umfasst: Anweisungen zum Abfragen der überwachten Vorrichtung, um
einen Hersteller und/oder ein Modell und/oder eine eindeutige Kennung
der überwachten
Vorrichtung zu erhalten; Anweisungen zum Bestimmen, ob das Überwachungssystem
so konfiguriert ist, dass es mit der überwachten Vorrichtung eine
Schnittstelle bildet, unter Verwendung von in der ersten Datenbank
gespeicherten Informationen; und Anweisungen zum Bestimmen, ob die überwachte
Vorrichtung durch das Überwachungssystem
unterstützt
wird, unter Verwendung von in der zweiten Datenbank gespeicherten
Informationen.
-
Bei
einem zusätzlichen
Aspekt schafft die vorliegende Erfindung ein netzbasiertes System,
das eine überwachte
Vorrichtung unter mehreren an ein Netz angeschlossenen Vorrichtungen
aufweist, wobei das System umfasst: eine erste Datenbank und eine
zweite Datenbank, die mit der Steuereinheit kommunikativ gekoppelt
sind, wobei die zweite Datenbank Informationen speichert, um zu
bestimmen, ob die überwachte
Vorrichtung durch die Steuereinheit unterstützt wird; eine Steuereinheit,
um die überwachte
Vorrichtung zu überwachen,
wobei die Steuereinheit eine Logik besitzt, um: die überwachte
Vorrichtung abzufragen, um einen Hersteller und/oder ein Modell
und/oder eine eindeutige Kennung der überwachten Vorrichtung zu erhalten;
unter Verwendung eines hierarchischen Verfahrens zu bestimmen, ob
das Überwachungssystem
so konfiguriert ist, dass es mit der überwachten Vorrichtung eine
Schnittstelle bildet, indem in der ersten Datenbank gespeicherte Informationen
verwendet werden; und zu bestimmen, ob die überwachte Vorrichtung durch
das Überwachungssystem
unterstützt
wird, unter Verwendung von in der zweiten Datenbank gespeicherten
Informationen; und wobei Konfigurationsinformationen in der ersten
Datenbank mit in der zweiten Datenbank gespeicherten Informationen
aktualisiert werden, um die Steuereinheit in die Lage zu versetzen,
mit der überwachten
Vorrichtung eine Schnittstelle zu bilden, um dadurch eine Flexibilität bei der
Aktualisierung von durch das Überwachungssystem überwachten
Vorrichtungen unter mehreren Vorrichtungen zu ermöglichen.
-
Ein
Vorteil der vorliegenden Erfindung umfasst die Leichtigkeit, mit
der die Vorrichtungen zu verändern sind,
die das System unterstützt,
indem die Datenbank anstatt das System modifiziert wird.
-
Ein
vollständigeres
Verständnis
der vorliegenden Erfindung und vieler der mit ihr verknüpften Vorteile ist
leicht zu erhalten, wenn sie mit Bezug auf die nachfolgende ausführliche
Beschreibung besser verstanden wird, wobei sie im Zusammenhang mit
der beigefügten
Zeichnung betrachtet wird.
-
1 ist
ein Schaltbild, das die Netzverknüpfung der Vorrichtung 2 und
des Systems 8 bei einer beispielhaften Ausführungsform
der vorliegenden Erfindung veranschaulicht;
-
2 ist
ein beispielhafter Ablaufplan, der die erforderlichen Schritte beim
Bestimmen veranschaulicht, ob das System 8 so konfiguriert
ist, dass es mit der Vorrichtung 2 eine Schnittstelle bildet;
-
3 ist
ein beispielhafter Ablaufplan, der die erforderlichen Schritte beim
Bestimmen, unter Verwendung der Systemkonfigurations-Datenbank 6,
veranschaulicht, ob das System 8 so konfiguriert ist, dass
es mit der Vorrichtung 2 eine Schnittstelle bildet;
-
4 ist
eine beispielhafte Veranschaulichung eines hierarchischen Ansatzes
zum Bestimmen, ob die Vorrichtung 2 durch das System 8 unterstützt wird;
-
5 veranschaulicht
Softwareobjekte in einer beispielhaften Ausführungsform der vorliegenden
Erfindung;
-
6 veranschaulicht
ein beispielhaftes Sequenzdiagramm beim Initialisieren des Systems,
um Informationen über
Objektkennungen zu erhalten, die dazu dienen, den Hersteller, das
Modell und eine eindeutige Kennung zu identifizieren, und um Informationen über die
durch das System unterstützten
Hersteller und Modelle zu erhalten;
-
7 veranschaulicht
ein beispielhaftes Sequenzdiagramm zum Erzeugen von Vorrichtungsobjekten, um
die überwachten
Vorrichtungen während
der Initialisierung darzustellen;
-
8 zeigt
das Sequenzdiagramm zum Ausführen
der Funktion setAgent() 122 von VendorModel 118;
-
9 ist
ein beispielhafter Ablaufplan für
die Funktion setAgent() von VendorModel;
-
10 erläutert beispielhaft
ein Sequenzdiagramm, wenn das System Informationen erhält, die
dazu dienen, die Statusinformationen für den bestimmten Hersteller
und das bestimmte Modell der überwachten Vorrichtungen
zu erhalten;
-
11 zeigt
den Ablaufplan für
die Funktion createDevice() von DeviceFactory;
-
12 zeigt
das Sequenzdiagramm zum Ausführen
der Funktion monitor-Status();
-
13 zeigt
das Sequenzdiagramm zum Ausführen
der Funktion getStatus() 214 von Device 210;
-
14 zeigt
die Tabellen einer Datenbank, die Informationen über die durch das System unterstützten Hersteller
und Modelle enthält;
-
15 zeigt
ein Beispiel für
die Inhalte in den Tabellen der Datenbank, wie sie in 14 beschrieben ist;
und
-
16 zeigt
das Klassendiagramm für
das ODBC2-Paket.
-
1 ist
ein Schaltbild, das die Netzverknüpfung der Vorrichtung 2 und
des Systems 8 veranschaulicht. Die Vorrichtung 2 bildet
mit dem System 8 über
das Netz 4 eine Schnittstelle. Das System 8 ist
mit der Systemkonfigurations-Datenbank (SCD) 6 und der
Systemunterstützungs-Datenbank
(SSD) 10 gekoppelt. Das Netz 4 kann irgendein
Typ von Kommunikationsstruktur sein, der es der Vorrichtung 2 und
dem System 8 ermöglicht,
Daten auszutauschen. Beispielsweise kann das Netz 4 entweder
ein Weitverkehrsnetz (WAN), ein lokales Netz (LAN) oder ein einfaches
Kabel sein, das die Vorrichtung 2 und das System 8 physikalisch
verbindet. Es ist klar, dass die vorliegende Erfindung nicht durch
den Typ von Netzen beschränkt
ist und dass andere Netze verwendet werden können, um eine Kommunikation
zwischen der Vorrichtung 2 und dem System 8 zu
ermöglichen.
-
Die
Systemkonfigurations-Datenbank 6 enthält Informationen eines ersten
und eines zweiten Typs. Der erste Typ von Informationen sind Konfigurations- oder Vorrichtungsinformationen,
wie beispielsweise Herstellername, Modellname, IP-Adresse, Firmenname,
Name der Kontaktperson und E-Mail-Adresse der Kontaktperson, um
nur einige zu nennen. Die Konfigurationsinformationen werden nur
während
der Initialisierung des Systems 8 verwendet, um zu bestimmen,
welche Vorrichtungen überwacht
werden müssen.
Die Systemkonfigurations-Datenbank 6 enthält jedoch
keine Informationen darüber,
welches Protokoll zu verwenden ist, um mit der Vorrichtung 2 zu
kommunizieren. Die SCD 6 enthält jedoch für die Kommunikation notwendige
Informationen wie beispielsweise die IP-Adresse. Daher enthält die SCD 6 Informationen,
die der Bestimmung dienen, ob das System 8 so konfiguriert
ist, dass es mit der Vorrichtung 2 eine Schnittstelle bildet.
Der zweite Typ von in der SCD 6 gespeicherten Informationen
sind Statusinformationen. Beispiele für Statusinformationen umfassen
Seitenzählung,
Fehlerstatus und Tonerfüllstand.
Statusinformationen werden nach der Initialisierung des Systems 8 zur
Datenbank (SCD 6) hinzugefügt, wenn das System 8 Vorrichtungen überwacht,
die am Netz 4 angeschlossen sind. Die Systemkonfigurations-Datenbank
(SCD 6) ist nicht direkt von der Systemunterstützungs-Datenbank
(SSD 10) abhängig.
-
Die
SSD 10 enthält
Informationen über
Hersteller und Modelle, die durch das System 8 unterstützt werden.
Obwohl dieses System alle Vorrichtungen, ungeachtet des Herstellers
oder des Modells, unterstützen kann,
hängt die
Menge von Statusinformationen, die von der Vorrichtung 2 erhalten
werden, von Herstellern und Modellen ab, die durch die SSD 10 unterstützt werden.
Wenn der Hersteller und das Modell durch die SSD 10 unterstützt werden,
dann können
von der Vorrichtung 2 detaillierte Statusinformationen
erhalten werden. Dadurch bestimmt die SSD 10, welcher Typ
von Statusinformationen in der Systemkonfigurations-Datenbank (SCD 6)
gespeichert ist.
-
Informationen
sowohl von der SCD 6 als auch von der SSD 10 dienen
dazu, Vorrichtungsobjekte zu erzeugen, um die Vorrichtungen darzustellen,
die überwacht
werden. Obwohl eine einzelne Vorrichtung 2 als am Netz 4 angeschlossen
gezeigt ist, ist es klar, dass am Netz 4 mehrere Vorrichtungen
angeschlossen sein können,
die überwacht
werden müssen.
Die Vorrichtungsobjekte ermöglichen
es dem System 8, mit der Vorrichtung 2 zu kommunizieren
und zu bestimmen, welche Informationen von den Vorrichtungen zu
erhalten sind.
-
2 ist
ein beispielhafter Ablaufplan, der veranschaulicht, wie bestimmt
wird, ob das System 8 so konfiguriert ist, dass es mit
der Vorrichtung 2 eine Schnittstelle bildet. Im Block 12 bestimmt
das System 8 oder irgendeine andere Vorrichtung, die Teil
des Netzes 4 ist, ob das System 8 so konfiguriert
ist, dass es mit der Vorrichtung 2 eine Schnittstelle bildet.
Beispielsweise wird bestimmt, ob das System 8 mit Software
programmiert ist, die es dem System 8 ermöglicht,
mit der Vorrichtung 2 zu kommunizieren. Mit anderen Worten:
Das System 8 verwendet ein Protokoll, das mit der Vorrichtung 2 kompatibel
ist, sodass das System 8 und die Vorrichtung 2 Daten
austauschen und kooperativ arbeiten können. Beim Bestimmen, ob das
System 8 so konfiguriert ist, dass es mit der Vorrichtung 2 eine
Schnittstelle bildet, erhält
das System 8 auch Konfigurationsinformationen von der Vorrichtung 2 und
bestimmt, ob die Vorrichtung 2 durch das System 8 unterstützt wird.
-
Wenn
im Block 14 bestimmt wird, dass das System 8 so
konfiguriert ist, dass es mit der Vorrichtung 2 eine Schnittstelle
bildet, dann wird im Block 20 zwischen dem System 8 und
der Vorrichtung 2 ein Kommunikationsprotokoll aufgebaut,
das auf Informationen beruht, die in der Systemunterstützungs-Datenbank 10 gespeichert
sind. Im Block 22 wird die Systemkonfigurations-Datenbank
(SCD 6) mit den Konfigurationsdaten aktualisiert, die erhalten
wurden, als bestimmt wurde, ob das System 8 so konfiguriert
wurde, dass es mit der Vorrichtung 2 eine Schnittstelle
bildet. Wenn im Block 14 jedoch bestimmt wird, dass das
System 8 nicht so konfiguriert ist, dass es mit der Vorrichtung 2 eine
Schnittstelle bildet, dann endet der Prozess, und die Vorrichtung 2 bildet
mit dem System 8 keine Schnittstelle.
-
3 ist
ein beispielhafter Ablaufplan, der veranschaulicht, wie unter Verwendung
der Systemkonfigurations-Datenbank (SCD 6) bestimmt wird,
ob das System 8 so konfiguriert ist, dass es mit der Vorrichtung 2 eine
Schnittstelle bildet. Im Block 24 wird die Vorrichtung 2 unter
Verwendung eines üblichen
Kommunikationsprotokolls abgefragt, um ihren Hersteller, das Modell
und/oder die eindeutige Kennung zu bestimmen.
-
Wenn
im Block 26 der Hersteller, das Modell oder die eindeutige
Kennung der Vorrichtung bestimmt wird, dann geht der Prozess zum
Block 36 über,
andernfalls geht der Prozess zum Block 28 über. Im
Block 36 wird bestimmt, dass das System so konfiguriert
ist, dass es mit der Vorrichtung 2 eine Schnittstelle bildet.
-
Im
Block 28 wird die Vorrichtung 2 unter Verwendung
von in der Systemkonfigurations-Datenbank 6 gespeicherten
Daten abgefragt, um den Hersteller, das Modell und/oder die eindeutige
Kennung der Vorrichtung 2 zu bestimmen. Im Block 34 wird
bestimmt, ob der Hersteller, das Modell und/oder die eindeutige
Kennung der Vorrichtung 2 im Block 28 identifiziert
wurden. Wenn die Bestimmung im Block 34 ein positives Ergebnis
hat, dann wird im Block 36 bestimmt, dass das System so
konfiguriert ist, dass es mit der Vorrichtung 2 eine Schnittstelle
bildet. Wenn die Bestimmung im Block 34 ein negatives Ergebnis
hat, dann wird im Block 38 bestimmt, dass das System nicht
so konfiguriert ist, dass es mit der Vorrichtung 2 eine
Schnittstelle bildet.
-
Beim
Abfragen der Vorrichtung 2 nach den Hersteller- und Modellinformationen
in den Blöcken 24 und 28 werden
der Hersteller und das Modell der Vor richtung mit der Systemunterstützungs-Datenbank 10 überprüft, um zu
bestimmen, ob der Hersteller und das Modell durch das System 8 unterstützt werden.
Dies hat aber keinen Einfluss darauf, ob das System 8 so
konfiguriert ist, dass es mit der Vorrichtung 2 eine Schnittstelle bildet,
oder nicht.
-
Das
Systemunterstützungs-Datenbank 10 dient
zum Bestimmen, welche Statusinformationen von der Vorrichtung 2 zu
erhalten sind, wenn sie durch das System 8 überwacht
wird. Ein Vorrichtungsobjekt für
die Vorrichtung 2 enthält
Informationen aus der SSD 10 darüber, welche Statusinformationen
zu erhalten sind. Wenn der Hersteller und das Modell der Vorrichtung
in der SSD 10 nicht unterstützt werden, dann erhält das Vorrichtungsobjekt
Statusinformationen, die allen am Netz 4 angeschlossenen
Vorrichtungen zur Verfügung stehen.
Wenn der Hersteller in der SSD 10 unterstützt wird,
aber das Modell der Vorrichtung nicht unterstützt wird, dann erhält das Vorrichtungsobjekt
Statusinformationen, die allen Vorrichtungen eines Herstellers zur Verfügung stehen.
Wenn der Hersteller und das Modell unterstützt werden, dann erhält das Vorrichtungsobjekt Statusinformationen,
die allen Vorrichtungen des Modells zur Verfügung stehen.
-
4 ist
eine beispielhafte Veranschaulichung eines hierarchischen Ansatzes
zum Bestimmen, ob die Vorrichtung 2 durch das System 8 unterstützt wird.
In den Blöcken 56 und 58 wird
bestimmt, ob der Hersteller der Vorrichtung 2 durch das
System 8 unterstützt
wird. Wenn der Hersteller nicht unterstützt wird, dann wird im Block 60 bestimmt,
dass die Vorrichtung so konfiguriert ist, dass sie ein namenloses
Protokoll verwendet. Wenn der Hersteller unterstützt wird, dann geht der Prozess
zum Block 62 über.
-
In
den Blöcken 62 und 64 wird
bestimmt, ob das Modell der Vorrichtung 2 durch das System 8 unterstützt wird.
Wenn das Modell nicht unterstützt
wird, dann wird im Block 66 bestimmt, dass die Vorrichtung 2 unter
Verwendung eines herstellerspezifischen Protokolls zu konfigurieren
ist. Wenn das Modell unterstützt wird,
dann wird im Block 68 bestimmt, dass die Vorrichtung 2 unter
Verwendung eines modellspezifischen Protokolls zu konfigurieren
ist.
-
5 veranschaulicht
Softwareobjekte in einer beispielhaften Ausführungsform der vorliegenden
Erfindung. Das Softwareobjekt SendInterfaceManager 70 bildet
direkt oder indirekt Schnittstellen mit den Softwareobjekten DataTransfer 74,
ODBC-1 72, DeviceFactory 76, VenderModel 78,
ODBC-2 84, SNMP 80 und Device 82.
-
Tabelle
1 veranschaulicht die Funktionen der ODBC-1 72.
-
-
Tabelle
2 veranschaulicht die Funktionen von DeviceFactory 76.
-
-
Tabelle
3 veranschaulicht die Funktionen von DataTransfer 74.
-
-
Tabelle
4 veranschaulicht die Funktionen von Device 82.
-
-
Tabelle
5 veranschaulicht die Funktionen von ODBC-2 84.
-
-
Tabelle
6 veranschaulicht die Funktionen von SNMP 80.
-
-
VendorModel 78 ist
für das
Erhalten von Informationen über
den Hersteller und das Modell der überwachten Vorrichtung verantwortlich.
Dieses Softwareobjekt erhält
den Hersteller, das Modell und die eindeutige Kennung der überwachten
Vorrichtung. Die Klasse CVendorModel von VendorModel 78 verwendet
Informationen aus der Datenbank, um die durch das System unterstützten Hersteller
und Modelle zu bestimmen. Die Klasse verwendet auch Informationen
aus der Datenbank, die erforderlich sind, um das Modell und die
eindeutige Kennung von der überwachten
Vorrichtung zu erhalten. Die öffentlichen
und die privaten Funktionen von CVendorModel sind in der nachstehenden
Tabelle 7 gezeigt.
-
-
-
Die
nachstehende Tabelle 8 zeigt die in den oben erwähnten Funktionen verwendeten
Attribute der Klasse CVendorModel.
-
-
-
ManufacturerAndModelInfo
in m_ManufacturerAndModelInfoVector hat die folgende Struktur:
struct
ManufacturerAndModelInfo {
std::string m_sManufacturer;
std::string
m_sEnterpriseOID;
std::string m_sModelOID;
std::string
m_sUniqueOID;
};
-
m_sManufacturer
ist der Name des Herstellers. m_sEnterpriseOID ist die dem Hersteller
zugeordnete Unternehmensobjekt-Kennung. Die Unternehmensobjekt-Kennung
ist für
einen Hersteller eindeutig. m_sModelOID ist die Objektkennung, die
dazu dienen kann, den Modellnamen der Vorrichtung zu finden. m_sUniqueOID
ist die Objektkennung, die dazu dienen kann, die eindeutige Kennung
der Vorrichtung zu finden. Die eindeutige Kennung kann die Seriennummer
oder die MAC-Adresse der Vorrichtung sein.
-
DeviceFactory 76 ist
für das
Erzeugen eines Vorrichtungsobjekts, das die überwachte Vorrichtung darstellt,
verantwortlich. DeviceFactory 76 stellt sicher, dass dem
Vorrichtungsobjekt bekannt ist, welche Statusinformationen es erhalten
muss. CDeviceFactory ist die einzige Klasse im Paket DeviceFactory 76.
Die öffentlichen
und die privaten Funktionen von CDeviceFactory sind in der nachstehenden
Tabelle 9 gezeigt.
-
-
Die
nachstehende Tabelle 10 zeigt die in den oben erwähnten Funktionen
verwendeten Attribute der Klasse CDeviceFactory.
-
-
infoType
ist eine Zahl, die in m_GenericDeviceVector und in m_ManufacturerVectorMap
verwendet wird, die dazu dienen, einen bestimmten Typ von Statusinformationen
darzustellen. Beispielsweise stellt 503 einen NoPaper-Zustand für die überwachte
Vorrichtung dar, und 601 stellt die Seitenlebensdauer-Zählung der überwachten
Vorrichtung dar.
-
Device 82 stellt
eine überwachte
Vorrichtung dar. Dies greift auf Statusinformationen der überwachten Vorrichtung
zu. Statusinformationen enthalten Informationen wie etwa Fehlerstatus,
Seitenzählung,
Tonerkartuschenfüllstand
und Warnungen. CDevice ist die einzige Klasse im Paket Device 82.
Die öffentlichen
Funktionen von CDevice sind in der nachstehenden Tabelle 11 gezeigt.
-
-
Die
nachstehende Tabelle 12 zeigt die in den oben erwähnten Funktionen
verwendeten Attribute der Klasse CDevice.
-
-
6 veranschaulicht
ein beispielhaftes Sequenzdiagramm beim Initialisieren des Systems,
um Informationen über
die Objektkennungen zu erhalten, die dazu dienen, den Hersteller,
das Modell und die eindeutige Kennung zu identifizieren und Informationen über die
durch das System unterstützten
Hersteller und Modelle zu erhalten. VendorModel 86 wirkt
mit ODBC2 88 zusammen, um diese Informationen zu erhalten. ODBC2 88 stellt
eine Schnittstelle zur Datenbank bereit, um Informationen zu erhalten,
die von VendorModel 86 aus ihr angefordert werden. VendorModel 86 ruft
die Funktion getManufInfo() 90 von ODBC2 88 auf,
um aus der Datenbank die Objektkennungen zu erhalten, die dazu dienen,
den Hersteller, das Modell und die eindeutige Kennung der überwachten
Vorrichtungen zu identifizieren. Diese Informationen werden im Vektor m_ManufacturerAndModelInfoVector
gespeichert, der in der obigen Tabelle 8 beschrieben ist. getManufInfo() 90 wird
mehrere Male aufgerufen, bis alle Objektkennungen für alle durch
das System unterstützten
Hersteller aus der Datenbank eingelesen sind. Dann ruft VendorModel 86 die
Funktion getSupportedModel() 92 von ODBC2 88 auf,
um den Hersteller und das Modell, die durch das System unterstützt werden,
aus der Datenbank zu erhalten. Diese Informationen werden im Kennfeld
m_ManufacturerModelMap gespeichert, das in der obigen Tabelle 8
beschrieben ist. getSupportedModel() wird mehrere Male aufgerufen,
bis alle durch das System unterstützten Modelle aus der Datenbank
eingelesen sind. Um die durch das System unterstützten Hersteller und Modelle
zu entfernen, zu modifizieren oder hinzuzufügen, ist lediglich eine Änderung
in der Datenbank notwendig, die Informationen über die unterstützten Hersteller
und Modelle speichert. Es muss keine Änderung am System vorgenommen
werden, wenn sich die durch das System unterstützten Hersteller und Modelle ändern. Die
Informationen werden während
der Initialisierung aus der Datenbank eingelesen.
-
7 veranschaulicht
ein beispielhaftes Sequenzdiagramm zum Erzeugen von Vorrichtungsobjekten, um
die überwachten
Vorrichtungen während
der Initialisierung darzustellen. Zu Beginn versucht das System 8 (1),
eine Kommunikation mit der Vorrichtung 2 aufzubauen. Wenn
das System 8 nicht so konfiguriert werden kann, dass es
mit der Vorrichtung 2 eine Schnittstelle bildet, werden
Konfigurationsinformationen, wie etwa Hersteller, Modell und eine
eindeutige Kennung, von der Vorrichtung 2 erhalten. Beim
Prozess des Bestimmens der Konfigurationsinformationen erfolgt unter
Verwendung von Informationen aus der Systemunterstützungs-Datenbank
(SSD 10) eine Bestimmung, um festzustellen, ob die Vorrichtung 2 durch
das System 8 unterstützt
wird. Unter Verwendung von Informationen aus der SSD 10 wird
ein Vorrichtungsobjekt erzeugt, wodurch ein Kommunikationsprotokoll
zwischen dem System 8 und der Vorrichtung 2 aufgebaut
wird – unabhängig davon,
ob die Vorrichtung durch das System 8 unterstützt wird
oder nicht. Anschließend
werden in der Systemkonfigurations-Datenbank (SCD 6) Konfigurationsinformationen
für die
Vorrichtung 2 aktualisiert. SendIn terfaceManager 94 ruft
getConfig() 102 von ODBC 96 auf. ODBC 96 stellt
eine Schnittstelle zur Datenbank bereit, um Konfigurationsinformationen
der überwachten
Vorrichtungen zu erhalten. Die Konfigurationsinformationen umfassen
Herstellernamen, Modellnamen und IP-Adresse der überwachten Vorrichtung sowie
Namen, Telephonnummer und E-Mail-Adresse der Kontaktperson, die
für die überwachte
Vorrichtung verantwortlich ist. Die Datenbank enthält die Konfigurationsinformationen
aller Vorrichtungen, die überwacht
werden. Jedoch können
nicht alle Vorrichtungen in dieser Datenbank durch das System unterstützt werden,
wie in der Datenbank angegeben ist, die der ODBC2 84 von 5 zugeordnet
ist.
-
SendInterfaceManager 94 ruft
setAgent() 104 auf, wobei eine SNMP-Sitzung mit der überwachten
Vorrichtung aufgebaut wird, um den Hersteller, das Modell und die
eindeutige Kennung der Vorrichtung zu erhalten. Weitere Einzelheiten
dieser Funktion sind in 8 angegeben. SendInterfaceManager 94 ruft
getManufacturer() 106, getModel() 108 und getUniqueID() 110 von
VendorModel 98 auf, um den Herstellernamen, den Modellnamen
und die eindeutige Kennung der überwachten
Vorrichtung zu erhalten. SendInterfaceManager 94 ruft createDevice() 112 von
DeviceFactory 100 auf, um ein Vorrichtungsobjekt für die überwachte
Vorrichtung zu erzeugen. Das Vorrichtungsobjekt wird von SendInterfaceManager 94 verwendet,
um Statusinformationen der überwachten
Vorrichtung zu erhalten. SendInterfaceManager 94 ruft updateConfig()
von ODBC 96 auf, um die Konfigurationsinformationen in
der Datenbank zu aktualisieren.
-
Sämtliche
Schritte in der Sequenz werden wiederholt, bis alle überwachten
Vorrichtungen in der Datenbank erhalten wurden. Für jede der überwachten
Vorrichtungen wird ein Vorrichtungsobjekt erzeugt. SendInterfaceManager 94 bewahrt
jedes der Vorrichtungsobjekte.
-
8 zeigt
das Sequenzdiagramm zum Ausführen
der Funktion setAgent() 122 von VendorModel 118.
SendInterfaceManager 116 ruft setAgent() 122 von
VendorModel 118 auf. VendorModel 118 ruft setAgent() 124 von
SNMP 120 auf. Diese Funktion baut eine SNMP-Sitzung zwischen
dem System und der überwachten
Vorrichtung auf. VendorModel 118 ruft seine eigene Funktion
obtainManufacturer() 126 auf, um den Herstellernamen der überwachten
Vorrichtung zu erhalten. In der Funktion obtainManufacturer() 126 ruft
VendorModel 118 get- NetStringValueForOID() 128 von
SNMP 120 auf, um die Unternehmensobjekt-Kennung über SNMP von der überwachten
Vorrichtung zu erhalten. Die Unternehmensobjekt-Kennung dient dazu,
den Hersteller der überwachten
Vorrichtung zu identifizieren. VendorModel 118 ruft seine
eigene Funktion obtainModel() 130 auf, um den Modellnamen
der überwachten
Vorrichtung zu erhalten. In der Funktion obtainModel() 130 ruft
VendorModel 118 getNextStringValueForOID() 132 von
SNMP 120 auf, um über
SNMP den Modellnamen der überwachten
Vorrichtung zu erhalten. VendorModel 118 ruft seine eigene
Funktion obtainUniqueID() 134 auf, um die eindeutige Kennung
der überwachten
Vorrichtung zu erhalten. In der Funktion obtainUniqueID() 134 ruft
VendorModel 118 getNextStringValueForOID() 136 von
SNMP 120 auf, um über
SNMP die eindeutige Kennung der überwachten
Vorrichtung zu erhalten.
-
9 ist
ein beispielhafter Ablaufplan für
die Funktion setAgent() von VendorModel. Im Schritt 140 werden
die Variablen, die den Herstellernamen, den Modellnamen und die
eindeutige Kennung darstellen, auf eine leere Zeichenfolge gesetzt.
Diese Variablen sind m_sManufacturer, m_sModel und m_sUniqueID,
wie in Tabelle 8 beispielhaft erläutert. Im Schritt 142 wird über SNMTP
die Unternehmensobjekt-Kennung der überwachten Vorrichtung erhalten.
Im Schritt 144 wird die von der überwachten Vorrichtung erhaltene
Unternehmensobjekt-Kennung mit denjenigen verglichen, die durch
das System unterstützt
werden. Die Unternehmensobjekt-Kennung und der ihr entsprechende
durch das System unterstützte
Hersteller werden im Vektor m_ManufacturerAndModelInfoVector gespeichert,
wie in Tabelle 8 beschrieben. Der Vektor wird durchsucht, um zu
bestimmen, ob die Unternehmensobjekt-Kennung der überwachten
Vorrichtung gefunden wird. Wenn die Unternehmensobjekt-Kennung im
Vektor nicht gefunden werden kann, dann wird Schritt 156 als
nächster abgearbeitet.
Wenn die Unternehmensobjekt-Kennung im Vektor gefunden wird, dann
wird der Hersteller der überwachten
Vorrichtung durch das System unterstützt, und Schritt 146 wird
als nächster
abgearbeitet. Im Schritt 146 wird die Variable m_sManufacturer
für den
Herstellernamen auf den Herstellernamen gesetzt, der der Unternehmensobjekt-Kennung
im Vektor entspricht. Im Schritt 148 werden die Variablen m_sCurrentModelOID
und m_sCurrentUniqueOID für
die Objektkennung, die dazu dienen, den Modellnamen und die eindeutige
Kennung der überwachten
Vorrichtung zu finden, auf die Objektkennungen gesetzt, die der Unternehmens objekt-Kennung
im Vektor entsprechen. Im Schritt 150 wird der Modellname über SNMP
unter Verwendung der Objektkennung m_sCurrentModelOID von der überwachten
Vorrichtung erhalten.
-
Im
Schritt 152 wird der von der überwachten Vorrichtung erhaltene
Modellname mit denjenigen verglichen, die durch das System unterstützt werden.
Der Hersteller und das Modell, die durch das System unterstützt werden,
werden im Kennfeld m_ManufacturerModelMap gespeichert, wie in Tabelle
8 beschrieben. Das Kennfeld wird durchsucht, um zu bestimmen, ob
das Modell im Kennfeld gefunden wird. Wenn das Modell nicht im Kennfeld
gefunden werden kann, dann wird Schritt 156 als nächster abgearbeitet.
Wenn das Modell im Kennfeld gefunden werden kann, dann wird das
Modell der überwachten
Vorrichtung durch das System unterstützt, und Schritt 154 wird
als nächster
abgearbeitet. Im Schritt 154 wird die Variable m_sModel
für den
Modellnamen auf den für
die überwachte
Vorrichtung erhaltenen Modellnamen gesetzt. Im Schritt 156 wird über SNMP
unter Verwendung der Objektkennung m_sCurrentUniqueOID von der überwachten
Vorrichtung die eindeutige Kennung erhalten. Dann wird die Variable
m_sUniqueID für
die eindeutige Kennung auf die von der überwachten Vorrichtung erhaltene
eindeutige Kennung gesetzt.
-
Die
Funktion setAgent() von VendorModel ermöglicht es dem System, über SNMP
den Herstellernamen und den Modellnamen der überwachten Vorrichtung zu erhalten,
um zu bestimmen, ob sie durch das System unterstützt wird. Außerdem ermöglicht sie
es dem System, den Herstellernamen und den Modellnamen zu verifizieren.
-
10 erläutert beispielhaft
ein Sequenzdiagramm, wenn das System Informationen erhält, die
dazu dienen, die Statusinformationen für den bestimmten Hersteller
und das bestimmte Modell der überwachten Vorrichtungen
zu erhalten. DeviceFactory 160 wirkt mit ODBC2 162 zusammen,
um diese Informationen zu erhalten. ODBC2 162 stellt eine
Schnittstelle zur Datenbank bereit, um Informationen zu erhalten,
die von DeviceFactory 160 aus ihr angefordert werden. DeviceFactory 160 ruft
die Funktion getManufStatusInfo() 164 von ODBC2 162 auf,
um Informationen zu erhalten, die erforderlich sind, um über SNMP
von überwachten
Vorrichtungen die Statusinformationen für einen bestimmten Hersteller
zu erhalten. Die Informationen enthalten eine Zahl (infoType), die
irgend einen Typ von Statusinformationen und eine Objektkennung darstellt,
die dazu dienen, über
SNMP die Statusinformationen zu erhalten. getManufStatusInfo() 166 wird
mehrere Male aufgerufen, bis aus der Datenbank die Informationen
eingelesen sind, die erforderlich sind, um alle Statusinformationen
für einen
bestimmten Hersteller zu erhalten. Dann ruft DeviceFactory 160 die
Funktion getModelStatusInfo() 168 von ODBC2 162 auf,
um Informationen zu erhalten, die erforderlich sind, um über SNMP
von überwachten
Vorrichtungen Statusinformationen für ein bestimmtes Modell zu
erhalten. Die Informationen enthalten eine Zahl (infoType), die
irgendeinen Typ von Statusinformationen und eine Objektkennung darstellt,
die dazu dienen, die Statusinformationen über SNMP zu erhalten. getModelStatusInfo() 170 wird
mehrere Male aufgerufen, bis die Informationen, die erforderlich
sind, um alle Statusinformationen für ein bestimmtes Modell zu
erhalten, aus der Datenbank eingelesen sind. Diese Sequenz wird
innerhalb der Funktion createDevice() von DeviceFactory aufgerufen,
wenn ein Vorrichtungsobjekt für
die überwachte
Vorrichtung erzeugt wird. Diese Informationen werden zum Vorrichtungsobjekt
hinzugefügt,
wie in 11 beschrieben ist.
-
Durch
Verwendung der Datenbank zum Speichern von Informationen, die dazu
dienen, die zum Hersteller gehörenden
Statusinformationen und die zum Modell gehörenden Statusinformationen
zu erhalten, können
Statusinformationen, die von den überwachten Vorrichtungen zu
erhalten sind, ohne irgendwelche Änderungen am System leicht
modifiziert, entfernt oder zur Datenbank hinzugefügt werden.
-
11 zeigt
den Ablaufplan für
die Funktion createDevice() von DeviceFactory. Im Schritt 174 wird
ein Vorrichtungsobjekt erzeugt, um die überwachten Vorrichtungen darzustellen.
Im Schritt 176 wird ein Vektor, der Informationen enthält, die
erforderlich sind, um Statusinformationen von Vorrichtungen von
allen Herstellern zu erhalten, einem lokalen Vektor zugewiesen.
Dieser Vektor entspricht dem in Tabelle 10 beschriebenen m_GenericDeviceVector.
Im Schritt 178 wird der Herstellername der überwachten
Vorrichtung überprüft, um festzustellen,
ob er durch das System unterstützt
wird (der Herstellername ist eine leere Zeichenfolge, wenn er durch
das System nicht unterstützt
wird). Wenn der Herstellername nicht unterstützt wird, dann wird Schritt 186 als
nächster
abgearbeitet. Wenn der Herstellername unterstützt wird, dann wird Schritt 180 als
nächster abgearbeitet.
-
Im
Schritt 180 werden Informationen, die erforderlich sind,
um Statusinformationen von der überwachten
Vorrichtung eines bestimmten Herstellers zu erhalten, aus einem
Kennfeld erhalten und zu dem lokalen Vektor hinzugefügt. Das
Kennfeld entspricht dem in Tabelle 10 beschriebenen ManufacturerVectorMap.
Im Schritt 182 wird der Modellname der überwachten Vorrichtung überprüft, um festzustellen,
ob er durch das System unterstützt
wird (der Modellname ist eine leere Zeichenfolge, wenn er durch
das System nicht unterstützt wird).
Wenn der Modellname nicht unterstützt wird, dann wird Schritt 186 als
nächster
abgearbeitet. Wenn der Modellname unterstützt wird, dann wird Schritt 184 als
nächster
abgearbeitet.
-
Im
Schritt 184 werden Informationen, die erforderlich sind,
um Statusinformationen von der überwachten
Vorrichtung eines bestimmten Modells zu erhalten, aus der Datenbank
erhalten und zu dem lokalen Vektor hinzugefügt. Im Schritt 186 wird
der lokale Vektor, der die Informationen enthält, die erforderlich sind,
um alle Statusinformationen der überwachten
Vorrichtung zu erhalten, im Vorrichtungsobjekt gesetzt. Das Vorrichtungsobjekt
verfügt über Informationen
darüber,
welche Statusinformationen es von der überwachten Vorrichtung erhalten
muss.
-
DeviceFactory
erzeugt und initialisiert alle Vorrichtungsobjekte, sodass ihm bekannt
ist, welche Statusinformationen es erhalten muss.
-
12 zeigt
das Sequenzdiagramm zum Ausführen
der Funktion monitor-Status().
Der Prozess sendet die Statusinformationen der überwachten Vorrichtungen an
einen gewünschten
Ort. SendInterfaceManager 190 ruft startSend() 198 von
DataTransfer 196 auf, um das System darauf vorzubereiten,
die Statusinformationen der überwachten
Vorrichtungen über
E-Mail (SMTP) zu senden. SendInterfaceManager 190 ruft getStatus() 200 von
Device 194 auf, um die Statusinformationen der überwachten
Vorrichtung zu erhalten. Device 194 entspricht der überwachten
Vorrichtung und ist darüber
informiert, welche Statusinformationen es erhalten muss. SendInterfaceManager 190 ruft
saveStatus() 202 von ODBC 192 auf, um die Statusinformationen der überwachten
Vorrichtung in der Datenbank zu speichern. SendInterfaceManager 194 ruft
dataSend() 204 von DataTransfer 196 auf, um die
Statusinformationen der überwachten
Vorrichtung über
E-Mail (SMTP) zu senden. Die Schritte des Aufrufens von getStatus() 200,
saveStatus() 202 und dataSend() 204 werden für jede überwachte
Vorrichtung wiederholt. Für
jede überwachte
Vorrichtung liegt ein Vorrichtungsobjekt vor. SendInterfaceManager 190 ruft
endSend() 206 von DataTransfer 196 auf, um das
Senden der Statusinformationen über
E-Mail abzuschließen.
-
13 zeigt
das Sequenzdiagramm zum Ausführen
der Funktion getStatus() 214 von Device 210. SendInterfaceManager 208 ruft
getStatus() 214 von Device 210 auf, um die Statusinformationen
der überwachten
Vorrichtung zu erhalten. Device 210 stellt eine überwachte
Vorrichtung eines bestimmten Herstellers und Modells dar. Die Statusinformationen
werden von den überwachten
Vorrichtungen über
SNMP erhalten. Wenn die überwachte
Vorrichtung durch das System nicht unterstützt wird, dann sind die von
der überwachten Vorrichtung
erhaltenen Statusinformationen die Statusinformationen, die für alle überwachten
Vorrichtungen erhältlich
sind (Statusinformationen des gesamten Systems), wie etwa ein Fehlerstatus.
Wenn der Hersteller, nicht aber das Modell der überwachten Vorrichtung durch
das System unterstützt
wird, dann sind die von der überwachten
Vorrichtung erhaltenen Statusinformationen die Statusinformationen
des gesamten Systems und die für
alle überwachten
Vorrichtungen des bestimmten Herstellers erhältlichen Statusinformationen
(herstellerspezifischen Statusinformationen). Wenn der Hersteller
und das Modell der überwachten
Vorrichtung durch das System unterstützt werden, dann sind die von
der überwachten
Vorrichtung erhaltenen Statusinformationen die Statusinformationen
des gesamten Systems, die herstellerspezifischen Informationen und
die für
alle überwachten
Vorrichtungen des bestimmten Modells erhältlichen Statusinformationen
(modellspezifischen Statusinformationen). Device 210 enthält einen
Vektor, sodass ihm bekannt ist, welche Informationen es erhalten
muss. Device 210 ruft getNextStringValueForOID() von Snmp 212 auf,
sodass das System über
SNMP die Statusinformationen von der überwachten Vorrichtung erhalten
kann. getNextStringValueForOID() 218 wird mehrere Male
aufgerufen, um von der überwachten
Vorrichtung alle Statusinformationen zu erhalten.
-
14 zeigt
die Tabellen einer Datenbank, die Informationen über die durch das System unterstützten Hersteller
und Modelle enthält.
Die Tabelle enthält
auch Informationen darüber,
welche Informationen für
jeden Hersteller und jedes Modell zu erhalten sind. Manufacturer 230 ist
die Tabelle, die Informationen über
die durch das System unterstützten
Hersteller enthält.
Manufacturer 230 enthält
außerdem
die folgenden Informationen: eine Unternehmensobjekt-Kennung für den Hersteller,
eine Objektkennung, die dazu dient, den Modellnamen der überwachten
Vorrichtung zu finden, und eine Objektkennung, die dazu dient, die
eindeutige Kennung der überwachten
Vorrichtung zu finden. SupportedModelByManufacturer 220 ist
die Tabelle, die die durch das System unterstützten Modelle mit ihrem entsprechenden
Hersteller enthält.
Um durch das System unterstützte Hersteller
und Modelle hinzuzufügen
oder zu entfernen, müssen
nur die Tabellen Manufacturer 230 und SupportedModelByManufacturer 220 modifiziert
werden. Am Code des Systems muss keine Modifikation vorgenommen
werden. Das System liest die Informationen aus diesen Tabellen der
Datenbank aus.
-
ComManufStatus 226 ist
die Tabelle, die Informationen darüber enthält, welche Informationen von
der überwachten
Vorrichtung auf der Grundlage ihres Herstellernamens erhalten werden.
Die Tabelle enthält
den Herstellernamen und eine Zahl, die den Typ von Informationen
darstellt. ModelStatus 222 ist die Tabelle, die Informationen
darüber
enthält,
welche Informationen von der überwachten
Vorrichtung auf der Grundlage ihres Modellnamens erhalten werden.
Die Tabelle enthält
den Herstellernamen, den Modellnamen und eine Zahl, die den Typ
von Informationen darstellt. Um Informationen, die von der überwachten
Vorrichtung zu erhalten sind, hinzuzufügen oder zu entfernen, müssen nur
die Tabellen ComManufStatus 226 und ModelStatus 222 modifiziert
werden. Am Code des Systems muss keine Modifikation vorgenommen
werden. Das System liest die Informationen aus diesen Tabellen der
Datenbank aus.
-
EnumOID 224 ist
die Tabelle, die Informationen über
die Objektkennung enthält,
die dazu dienen, die der Zahl entsprechenden Informationen zu finden.
Die Objektkennung wird vom System dazu verwendet, über SNMP
von der überwachten
Vorrichtung einen bestimmten Typ von Informationen zu finden. EnumCorrespondence 228 ist
die Tabelle, die eine Beschreibung der Zahlen enthält, die
dazu dienen, einen Typ von Informationen darzustellen. Diese Tabelle
wird vom System nicht verwendet, sondern liefert dem Anwender des
Systems Informationen darüber,
was die Zahlen darstellen.
-
15 zeigt
ein Beispiel für
die Inhalte in den Tabellen der Datenbank, wie sie in 14 beschrieben ist.
Microsoft Access ist die Datenbank, mit deren Hilfe Informationen über die
durch das System unterstützten Hersteller
und Modelle gespeichert werden.
-
16 zeigt
das Klassendiagramm für
das ODBC2-Paket. Die Klasse CSupportODBC 232 ist die Schnittstelle
zu diesem Paket für
den Zugriff auf Informationen in der Datenbank. Die Klasse CManufactuerData 240 greift
auf Informationen aus der Datenbank zu, die erforderlich sind, um
den Hersteller, das Modell und die eindeutige ID der überwachten
Vorrichtung zu erhalten. Die Klasse CSupportedModelData 234 greift auf
Informationen aus der Datenbank über
den Hersteller und das Modell der durch das System unterstützten überwachten
Vorrichtung zu. Die Klasse CComManufStatusData 236 greift
auf Informationen aus der Datenbank zu, die erforderlich sind, um
Hersteller-Statusinformationen zu erhalten, die der überwachten
Vorrichtung zugeordnet sind. Die Klasse CModelStatusData 238 greift
auf Informationen aus der Datenbank zu, die erforderlich sind, um
Modell-Statusinformationen zu erhalten, die der überwachten Vorrichtung zugeordnet
sind. Die Klasse CManufacturerDatabase 242 stellt eine
Schnittstelle zur Tabelle in der Datenbank bereit, die die Herstellerinformationen
enthält.
Die Klasse CSupportedModelDDatabase 244 stellt eine Schnittstelle
zur Tabelle in der Datenbank bereit, die Informationen über unterstützte Modelle
enthält.
Die Klasse CComManufStatusDatabase 246 stellt eine Schnittstelle
zur Tabelle in der Datenbank bereit, die die Hersteller-Statusinformationen
enthält.
Die Klasse CModelStatusDatabase 250 stellt eine Schnittstelle
zur Tabelle in der Datenbank bereit, die die Modell-Statusinformationen
enthält.
Die Klasse CInfoTypeOIDDatabase 248 stellt eine Schnittstelle
zur Tabelle in der Datenbank bereit, die die Entsprechung zwischen
der infoType-Nummerierung und der Objektkennung enthält.
-
CManufacturerDatabase 242,
CSupportedModelDatabase 244, CComManufStatusDatabase 246, CModelStatusDatabase 250 und
CInfoTypeOIDDDatabase 248 sind sämtlich Klassen, die vom CRecordset 252 der
Microsoft-Foundation-Class-(MFC-)Bibliothek abgeleitet sind.
-
Die
obige Beschreibung der bevorzugten Ausführungsform der vorliegenden
Erfindung wurde für
Zwecke der Veranschaulichung und der Beschreibung geboten. Sie ist
nicht dazu bestimmt, erschöpfend
zu sein oder die Erfindung auf die präzise offenbarte Form einzuschränken, und
es sind angesichts der obigen Lehren zahlreiche Abwandlungen oder Änderungen
möglich.
Beispielsweise können
irgendeine oder mehrere der hierin beschriebenen oder gezeigten
Konzeptionen auf das System und/oder auf das Verfahren angewandt werden,
die im verwandten Dokument US 2002/52292 unter dem Titel "Method and System
of Remote Support of Device Using Email" offenbart sind. Außerdem kann jegliches Konzept
oder Merkmal, das in US 2002/152292 beschrieben ist, auf die hierin
offenbarten Systeme oder Verfahren angewandt werden. Die Ausführungsformen
wurden ausgewählt
und beschrieben, um auf bestmögliche
Weise die Prinzipien der Erfindung und ihre praktischen Anwendungen
zu beschreiben, wodurch es einem anderen Fachmann auf dem Gebiet ermöglicht wird,
die Erfindung und verschiedene Ausführungsformen zu verwenden,
auch mit verschiedenen Abwandlungen, wie sie für die jeweils vorgesehene besondere
Anwendung geeignet sind. Es ist beabsichtigt, dass der Umfang der
vorliegenden Erfindung lediglich durch die hier beigefügten Ansprüche definiert
ist.