DE60304768T2

DE60304768T2 - Verfahren und Vorrichtung zum Überwachen entfernter Geräte durch Erzeugen von Geräteobjekten für die zu überwachenden Geräte

Info

Publication number: DE60304768T2
Application number: DE60304768T
Authority: DE
Inventors: Tetsuro San Jose Motoyama; Avery San Jose Fong
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2002-05-31
Filing date: 2003-05-15
Publication date: 2007-05-24
Anticipated expiration: 2023-05-16
Also published as: US20030167323A1; HK1057834A1; US7849171B2; EP1367766A2; JP4159410B2; JP2004030642A; EP1367766A3; ES2262949T3; EP1367766B1; DE60304768D1

Description

Die vorliegende Erfindung betrifft die Überwachung, Konfiguration oder Installation von Hardware auf einem Computersystem.
Erörterung des Hintergrundes
Im Allgemeinen umfassen Computersysteme Hardware und Software. Die Hardware ist die eigentliche physikalische Rechenmaschinerie, während die Software die Liste von Befehlen, um die Hardware zu betreiben, ist. Typischerweise umfassen Computersysteme eine Vielfalt von Hardwarevorrichtungen, die eine Schnittstelle miteinander bilden. Wenn Hardwarevorrichtungen miteinander eine Schnittstelle bilden, ist es erforderlich, dass die Software, die die Hardware betreibt, konfiguriert wird, um die Kommunikation zwischen den Hardwarevorrichtungen zu ermöglichen, so dass die Hardwarevorrichtungen kooperativ arbeiten können. Es ist auch erwünscht, dass Hardwarevorrichtungen überwacht werden. Für die Zwecke der Erörterung wird eine Hardwarevorrichtung, die konfiguriert oder überwacht, als Steuervorrichtung bezeichnet. Ebenso wird für die Zwecke der Erörterung die Hardwarevorrichtung, die konfiguriert wird, um kooperativ zu arbeiten, oder durch die Steuervorrichtung überwacht wird, als Schnittstellenvorrichtung bezeichnet.
Wenn Hardwarevorrichtungen anfänglich miteinander eine Schnittstelle bilden, ist es üblich, dass die Software, die die Vorrichtungen betreibt, unkonfiguriert bleibt, um einen kooperativen Betrieb zu ermöglichen. Folglich konfiguriert ein signifikanter Teil von installierenden Computer-Hardwarevorrichtungen gemeinsam die Software. In einigen Anordnungen muss ein Anwender die Computerhardware manuell durch Öffnen der Computerhardware und physikalisches Setzen von Jumpern oder Dip-Schaltern konfigurieren. In noch einigen weiteren Anordnungen umfasst der Installationsprozess, dass ein Anwender eine Software von einer Diskette lädt, um die Hardwarevorrichtungen zu konfigurieren. Es bestanden auch Versuche, dass Computer-Hardwarevorrichtungen eine Software umfassen, die Hardwarevorrichtungen automatisch konfigurieren kann. Es bestehen jedoch einige scheinbare Nachteile und Mängel in Bezug auf die vorstehend identifizierten Vorgehensweisen.
Ein Nachteil besteht darin, dass eine automatische Hardware-Installationssoftware in ihrer Fähigkeit begrenzt, sich an neue Vorrichtungen oder an neue Hersteller anzupassen, die nicht speziell in die Software programmiert wurden. Wenn die Steuervorrichtung das spezielle Modell der Schnittstellenvorrichtung nicht erkennt, ist im Stand der Technik eine automatische Konfiguration nicht möglich. Mit anderen Worten, wenn die Steuervorrichtung nicht dazu programmiert ist, das Modell einer Schnittstellenvorrichtung vorherzusehen, dann ist eine automatische Hardwarekonfiguration nicht erfolgreich. Unter einem solchen Umstand muss ein Anwender das Konfigurationskommunikationsmittel manuell in die Hardwarevorrichtungen installieren.
Ein weiterer Nachteil des Standes der Technik besteht darin, dass die Steuervorrichtung außerstande ist, Hardwarevorrichtungen teilweise zu konfigurieren, wenn das spezielle Modell der Schnittstellenvorrichtung nicht identifiziert werden kann. Mit anderen Worten, wenn eine Steuervorrichtung ein spezielles Modell der Schnittstellenvorrichtung nicht identifizieren kann, dann wird die Schnittstellenvorrichtung nicht so konfiguriert, dass sie kooperativ funktioniert. Dies führt dazu, dass die unkonfigurierte Schnittstellenvorrichtung betriebsunfähig und im Wesentlichen nutzlos ist.
Es ist erwünscht, dass Hardwarevorrichtungen, die sich in einem Netz befinden, zur Wartung, Verwendung oder für andere Zwecke überwacht werden. Es war jedoch für eine Steuervorrichtung schwierig, in Anbetracht der verschiedenen Kommunikationsmittel zwischen Herstellern und Modellen von Schnittstellenvorrichtungen mit verschiedenen Schnittstellenvorrichtungen in einem Netz zu kommunizieren. Diese Nachteile verhindern, dass Netzadministratoren eine entscheidende Information über die Leistung und die Effizienz von Schnittstellenvorrichtungen in einem Netz erhalten.
DE-A1-100 22 491 offenbart die Aktualisierung eines Treibers auf einem PC über das Internet.
US 5 546 595 offenbart ein objektorientiertes Hardware-Konfigurationssystem.
Die vorliegende Erfindung betrifft ein Verfahren zum Aufbauen einer Verbindung zwischen mindestens einer Vorrichtung und einem Überwachungssystem, eine Vorrichtung, die dazu ausgelegt ist, eine Verbindung mit mindestens einer Vorrichtung aufzubauen, ein Computerprogramm mit einem Programmcodemittel, das, wenn es auf einem Computersystem ausgeführt wird, den Computer anweist, das Verfahren durchzuführen, und ein System mit mindestens einer mit einem Netz verbundenen Vorrichtung.
Insbesondere werden ein Verfahren und eine Vorrichtung zum leichten Erzeugen von Vorrichtungsobjekten, die die überwachte Vorrichtung darstellen, beschrieben. Anfänglich versucht die Steuereinheit/das Überwachungssystem, eine Kommunikation mit der überwachten Vorrichtung herzustellen. Wenn die Steuereinheit nicht so konfiguriert werden kann, dass sie mit der überwachten Vorrichtung eine Schnittstelle bildet, werden Konfigurationsinformationen, wie z. B. Hersteller, Modell und eine eindeutige Kennung, von der überwachten Vorrichtung erhalten. Im Prozess der Bestimmung der Konfigurationsinformationen wird eine Feststellung durchgeführt, um herauszufinden, ob die überwachte Vorrichtung durch die Steuereinheit unter Verwendung von Informationen von der Systemunterstützungsdatenbank (SSD) unterstützt wird. Ein Vorrichtungsobjekt wird unter Verwendung von Informationen von der SSD erzeugt, wobei folglich ein Kommunikationsprotokoll zwischen der Steuereinheit und der überwachten Vorrichtung festgelegt wird. Anschließend werden die Konfigurationsinformationen für die überwachte Vorrichtung in der Systemkonfigurationsdatenbank (SCD) aktualisiert.
Zwei Datenbanken werden verwendet, um Vorrichtungen mit Systemen zu konfigurieren. Diese Ausführungsformen sind vorteilhaft, da wertvolle Computer-Ressourcen während der Initialisierung der Vorrichtungen mit einem System verwendet werden, während die Computer-Ressourcen während des Systembetriebs bewahrt werden. Ein System kann beispielsweise zwei separate Datenbanken verwenden, wenn eine Vorrichtung konfiguriert wird. Die erste Datenbank (d. h. eine Systemkonfigurationsdatenbank) speichert Vorrichtungsinformationen für Vorrichtungen, die bereits auf das System konfiguriert wurden, und wobei Betriebsstatusinformationen der Vorrichtungen gespeichert werden, wenn die Vorrichtungen vom System überwacht werden. Solche Vorrichtungsinformationen können den Herstellernamen und den Modellnamen umfassen, während die Betriebsstatusinformationen die Seitenzahl und den Tonerstand umfassen können.
Die in der ersten Datenbank gespeicherten Vorrichtungsinformationen werden während der Initialisierung des Systems verwendet, während die in der ersten Datenbank gespeicherten Statusinformationen während des Systembetriebs angesammelt werden. Die erste Datenbank ist daher groß, da sie Statusinformationen enthält. Der Verbrauch von Computer-Ressourcen ist jedoch unbedeutend, da die Vorrichtungsinformationen während der Initialisierung verwendet werden, während die Statusinformationen nur hinzugefügt werden, wenn das System in Betrieb ist.
Das System der vorliegenden Erfindung verwendet auch eine zweite Datenbank (d. h. eine Systemunterstützungsdatenbank). Diese zweite Datenbank kann relativ groß sein, da sie Daten enthalten würde, die eine Vielzahl von Vorrichtungen betreffen. 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 Systemkonfigurationsdatenbank) unter Verwendung der Informationen von der zweiten Datenbank (d. h. der Systemunterstützungsdatenbank) aktualisiert werden, so dass die Vorrichtung mit dem System eine Schnittstelle bilden kann. Aufgrund der großen Menge von gespeicherten Informationen ist das Abfragen der zweiten Datenbank nicht nur zeitraubend, sondern verwendet auch eine große Menge von wertvollen Computer-Ressourcen. Sobald die entscheidenden Informationen (d. h. Protokoll) in Bezug auf die Vorrichtung in der ersten Datenbank mit Informationen aus der zweiten Datenbank aktualisiert sind, wird nur die erste Datenbank verwendet.
In einem Aspekt schafft die vorliegende Erfindung ein Verfahren zum Aufbauen einer Verbindung zwischen mindestens einer Vorrichtung und einem Überwachungssystem, wobei die mindestens eine Vorrichtung und das Überwachungssystem kommunikationsfähig über ein Netz gekoppelt sind, wobei das Überwachungssystem mit einer ersten und einer zweiten Datenbank kommunikationsfähig gekoppelt ist, wobei das Verfahren die Schritte umfasst:

(a) Feststellen, ob das Überwachungssystem dazu konfiguriert ist, mit der mindestens einen Vorrichtung eine Schnittstelle zu bilden;
(b) Erhalten von Konfigurationsinformationen von der mindestens einen Vorrichtung, wenn das Überwachungssystem nicht dazu konfiguriert ist, mit der mindestens einen Vorrichtung eine Schnittstelle zu bilden;
(c) Feststellen, ob die mindestens eine Vorrichtung vom Überwachungssystem unter Verwendung von in der zweiten Datenbank gespeicherten Informationen unterstützt wird;
(d) Erzeugen eines Vorrichtungsobjekts unter Verwendung von Informationen, die in der ersten und der zweiten Datenbank gespeichert sind, um eine Kommunikation zwischen der mindestens einen Vorrichtung und dem Überwachungssystem aufzubauen, wobei das Vorrichtungsobjekt Bezugnahmen auf Konfigurationsinformationen umfasst, die in der ersten Datenbank gespeichert sind, wobei die Bezugnahmen Vektoren und Matrizen verwenden; und
(e) Aktualisieren der Konfigurationsinformationen für die mindestens eine Vorrichtung, die in der ersten Datenbank gespeichert sind, mit Konfigurationsinformationen, die in der zweiten Datenbank gespeichert sind, um zu ermöglichen, dass das Überwachungssystem mit der mindestens einen Vorrichtung eine Schnittstelle bildet, wodurch Flexibilität bei der Erzeugung von Vorrichtungsobjekten ermöglicht wird.

Der Schritt des Erhaltens von Konfigurationsinformationen von der mindestens einen Vorrichtung umfasst vorzugsweise das Identifizieren von mindestens einem des (i) Herstellers, (ii) des Modells der Vorrichtung und (iii) der IP-Adresse der mindestens einen Vorrichtung. Die Konfigurationsinformationen werden nur während der Initialisierung des Überwachungssystems verwendet, um die mindestens eine Vorrichtung zu identifizieren, die die Überwachung erfordert. Der Schritt des Feststellens, ob das Überwachungssystem dazu konfiguriert ist, mit der mindestens einen Vorrichtung eine Schnittstelle zu bilden, umfasst vorzugsweise das Abfragen der ersten Datenbank mit zumindest einem des Herstellers, des Modells und der IP-Adresse der mindestens einen Vorrichtung.
Der Schritt des Feststellens, ob das Überwachungssystem dazu konfiguriert ist, mit der mindestens einen Vorrichtung eine Schnittstelle zu bilden, umfasst das Abfragen der mindestens einen Vorrichtung mit in der ersten Datenbank gespeicherten Daten. Die erste Datenbank ist eine Systemkonfigurationsdatenbank, die Informationen zum Ermöglichen einer Kommunikation zwischen dem Überwachungssystem und der mindestens einen Vorrichtung; und Statusinformationen, die die mindestens eine Vorrichtung betreffen, umfasst, wobei die Statusinformationen nach der Initialisierung des Überwachungssystems zum Überwachen der mindestens einen Vorrichtung hinzugefügt werden. Die zweite Datenbank ist eine Systemunterstützungsdatenbank und umfasst Informationen über verschiedene Hersteller und Vorrichtungsmodelle, die vom Überwachungssystem unterstützt werden.
Der Schritt des Feststellens, ob die mindestens eine Vorrichtung vom Überwachungssystem unterstützt wird, umfasst ferner das Erhalten von detaillierten Statusinformationen der mindestens einen Vorrichtung, die überwacht wird, wenn der Hersteller und das Modell der mindestens einen Vorrichtung vom Überwachungssystem unterstützt werden. Das Vorrichtungsobjekt ermöglicht, dass das Überwachungssystem mit der mindestens einen Vorrichtung kommuniziert und Informationen bestimmt, die von der mindestens einen Vorrichtung erhalten werden müssen. Das mindestens eine Vorrichtungsobjekt speichert vorzugsweise Bezugnahmen auf Informationen unter Verwendung von Vektoren oder Matrizen. Das Vorrichtungsobjekt speichert ferner Bezugnahmen auf Informationen, die Objektkennungen umfassen. Die Vorrichtung umfasst vorzugsweise Hardware- oder Softwarekomponenten.
In einem weiteren Aspekt der vorliegenden Erfindung wird eine Vorrichtung geschaffen, die dazu ausgelegt ist, eine Verbindung mit mindestens einer Vorrichtung aufzubauen, die über ein System auf Netzbasis kommunikationsfähig gekoppelt ist, wobei die Vorrichtung umfasst: ein Überwachungssystem, das mit dem Netz kommunikationsfähig gekoppelt ist; eine erste und eine zweite Datenbank, die mit dem Überwachungssystem kommunikationsfähig gekoppelt sind; ein Mittel zum Feststellen, ob das Überwachungssystem dazu konfiguriert ist, mit der mindestens einen Vorrichtung eine Schnittstelle zu bilden; ein Mittel zum Erhalten von Konfigurationsinformationen von der mindestens einen Vorrichtung, wenn das Überwachungssystem nicht dazu konfiguriert ist, mit der mindestens einen Vorrichtung eine Schnittstelle zu bilden; ein Mittel zum Feststellen, ob die mindestens eine Vorrichtung vom Überwachungssystem unter Verwendung von Konfigurationsinformationen, die in der zweiten Datenbank gespeichert sind, unterstützt wird; ein Mittel zum Erzeugen eines Vorrichtungsobjekts unter Verwendung von Konfigurationsinformationen, die in der ersten und der zweiten Datenbank gespeichert sind, um eine Kommunikation zwischen der mindestens einen Vorrichtung und dem Überwachungssystem herzustellen, wobei das Vorrichtungsobjekt Bezugnahmen auf Konfigurationsinformationen umfasst, die in der ersten Datenbank gespeichert sind, wobei die Bezugnahmen Vektoren oder Matrizen verwenden; und ein Mittel zum Aktualisieren der Konfigurationsinformationen für die mindestens eine Vorrichtung, die in der ersten Datenbank gespeichert sind, mit Konfigurationsinformationen, die in der zweiten Datenbank gespeichert sind, um zu ermöglichen, dass das Überwachungssystem mit der mindestens einen Vorrichtung eine Schnittstelle bildet, wodurch Flexibilität bei der Erzeugung von Vorrichtungsobjekten ermöglicht wird.
In einem weiteren Aspekt der vorliegenden Erfindung wird ein Computerprogramm nach Anspruch 24 geschaffen.
In noch einem weiteren Aspekt der vorliegenden Erfindung wird ein System nach Anspruch 25 geschaffen.
Ein Vorteil der vorliegenden Erfindung umfasst die Leichtigkeit, mit der die Vorrichtungen geändert werden, die das System unterstützt, indem vielmehr die Datenbank als das System modifiziert wird.
Eine vollständigere Einschätzung der vorliegenden Erfindung und von vielen von deren zugehörigen Vorteilen wird leicht erhalten, da dieselbe durch Bezugnahme auf die folgende ausführliche Beschreibung besser verständlich wird, wenn sie in Verbindung mit den begleitenden Zeichnungen betrachtet wird.
1 ist ein Diagramm, das die Netzbeziehung der Vorrichtung 2 und des Systems 8 in einer beispielhaften Ausführungsform der vorliegenden Erfindung darstellt.
2 ist ein beispielhafter Ablaufplan, der die Schritte darstellt, die am Feststellen, ob das System 8 dazu konfiguriert ist, mit der Vorrichtung 2 eine Schnittstelle zu bilden, beteiligt sind;
3 ist ein beispielhafter Ablaufplan, der die Schritte darstellt, die am Feststellen, ob das System 8 dazu konfiguriert ist, mit der Vorrichtung 2 unter Verwendung der Systemkonfigurationsdatenbank 6 eine Schnittstelle zu bilden, beteiligt sind;
4 ist eine beispielhafte Darstellung einer hierarchischen Vorgehensweise, um festzustellen, ob die Vorrichtung 2 vom System 8 unterstützt wird;
5 stellt Softwareobjekte dar;
6 stellt ein beispielhaftes Sequenzdiagramm dar, wenn das System initialisiert wird, um Informationen über Objektkennungen zu erhalten, die verwendet werden, um den Hersteller, das Modell und die eindeutige Kennung zu identifizieren, und um Informationen über die Hersteller und Modelle, die vom System unterstützt werden, zu erhalten;
7 stellt ein beispielhaftes Sequenzdiagramm zum Erzeugen von Vorrichtungsobjekten dar, 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 veranschaulicht ein Sequenzdiagramm, wenn das System Informationen erhält, die verwendet werden, um die Statusinformationen für den speziellen Hersteller und das spezielle 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 monitorStatus();
13 zeigt das Sequenzdiagramm zum Ausführen der Funktion getStatus() 214 von Device 210;
14 zeigt die Tabellen einer Datenbank mit Informationen über die Hersteller und Modelle, die vom System unterstützt werden;
15 zeigt ein Beispiel der Inhalte in den Tabellen der Datenbank, wie in 14 beschrieben; und
16 zeigt das Klassendiagramm für das ODBC2-Paket.
1 ist ein Diagramm, das die Netzbeziehung der Vorrichtung 2 und des Systems 8 darstellt. Die Vorrichtung 2 bildet mit dem System 8 über das Netz 4 eine Schnittstelle. Das System 8 ist mit der Systemkonfigurationsdatenbank (SCD) 6 und der Systemunterstützungsdatenbank (SSD) 10 gekoppelt. Das Netz 4 kann eine beliebige Art von Kommunikationsstruktur sein, die ermöglicht, dass die Vorrichtung 2 und das System 8 Daten austauschen. Das Netz 4 könnte beispielsweise entweder ein weiträumiges Netz (WAN), ein lokales Netz (LAN) oder ein einfaches Kabel, das die Vorrichtung 2 und das System 8 physikalisch verbindet, sein. Es ist zu erkennen, dass die vorliegende Erfindung die Art von Netzen nicht begrenzt und dass andere Netze verwendet werden können, um eine Kommunikation zwischen der Vorrichtung 2 und dem System 8 zu ermöglichen.
Die Systemkonfigurationsdatenbank 6 umfasst Informationen erster und zweiter Typen. Der erste Typ von Informationen sind die Konfigurations- oder Vorrichtungsinformationen, wie beispielsweise der Herstellername, Modellname, die IP-Adresse, der Firmenname, der Name der Kontaktperson und die E-Mail-Adresse der Kontaktperson, um einige zu nennen. Die Konfigurationsinformationen werden nur während der Initialisierung des Systems 8 verwendet, um festzustellen, welche Vorrichtungen überwacht werden müssen. Die Systemkonfigurationsdatenbank 6 umfasst jedoch keine Informationen darüber, welches Protokoll zu verwenden ist, um mit der Vorrichtung 2 zu kommunizieren. Die SCD 6 umfasst jedoch Informationen, die zur Kommunikation erforderlich sind, wie beispielsweise die IP-Adresse. Daher enthält die SCD 6 Informationen, die verwendet werden, um festzustellen, ob das System 8 dazu konfiguriert ist, mit der Vorrichtung 2 eine Schnittstelle zu bilden. Der zweite Typ von Informationen, die in der SCD 6 gespeichert sind, sind Statusinformationen. Beispiele von Statusinformationen umfassen die Seitenzahl, den Fehlerstatus und den Tonerstand. Statusinformationen werden zur Datenbank (SCD 6) nach der Initialisierung des Systems 8 hinzugefügt, wenn das System 8 Vorrichtungen überwacht, die mit dem Netz 4 verbunden sind. Die Systemkonfigurationsdatenbank (SCD 6) hängt nicht direkt von der Systemunterstützungsdatenbank (SSD 10) ab.
Die SSD 10 umfasst Informationen über Hersteller und Modelle, die vom System 8 unterstützt werden. Obwohl dieses System alle Vorrichtungen ungeachtet des Herstellers oder Modells unterstützen kann, hängt die Menge an Statusinformationen, die von der Vorrichtung 2 erhalten werden, von den Herstellern und Modellen ab, die von der SSD 10 unterstützt werden. Wenn der Hersteller und das Modell von der SSD 10 unterstützt werden, dann können detaillierte Statusinformationen von der Vorrichtung 2 erhalten werden. Folglich bestimmt die SSD 10, welche Art von Statusinformationen in der Systemkonfigurationsdatenbank (SCD 6) gespeichert werden.
Die Informationen von sowohl der SCD 6 als auch der SSD 10 werden verwendet, um Vorrichtungsobjekte zu erzeugen, um die überwachten Vorrichtungen darzustellen. Obwohl eine einzelne Vorrichtung 2 als mit dem Netz 4 verbunden gezeigt ist, ist zu erkennen, dass eine Vielzahl von Vorrichtungen, die überwacht werden müssen, mit dem Netz 4 verbunden sein können. Die Vorrichtungsobjekte ermöglichen, dass das System 8 mit der Vorrichtung 2 kommuniziert und feststellt, welche Informationen von den Vorrichtungen erhalten werden sollen.
2 ist ein beispielhafter Ablaufplan, der darstellt, wie festgestellt wird, ob das System 8 dazu konfiguriert ist, mit der Vorrichtung 2 eine Schnittstelle zu bilden. Im Block 12 stellt das System 8 oder irgendeine andere Vorrichtung, die ein Teil des Netzes 4 ist, fest, ob das System 8 dazu konfiguriert ist, mit der Vorrichtung 2 eine Schnittstelle zu bilden. Es wird beispielsweise festgestellt, ob das System 8 mit einer Software programmiert ist, die ermöglicht, dass das System 8 mit der Vorrichtung 2 kommuniziert. Mit anderen Worten, das System 8 verwendet ein Protokoll, das mit der Vorrichtung 2 kompatibel ist, so dass das System 8 und die Vorrichtung 2 Daten austauschen und kooperativ arbeiten können. Beim Feststellen, ob das System 8 dazu konfiguriert ist, mit der Vorrichtung 2 eine Schnittstelle zu bilden, erhält das System 8 auch Konfigurationsinformationen von der Vorrichtung 2 und stellt fest, ob die Vorrichtung 2 vom System 8 unterstützt wird.
Wenn im Block 14 festgestellt wird, dass das System 8 dazu konfiguriert ist, mit der Vorrichtung 2 eine Schnittstelle zu bilden, dann wird im Block 20 ein Kommunikationsprotokoll zwischen dem System 8 und der Vorrichtung 2 auf der Basis von in der Systemunterstützungsdatenbank 10 gespeicherten Informationen festgelegt. Im Block 22 wird die Systemkonfigurationsdatenbank (SCD 6) mit den Konfigurationsdaten aktualisiert, die erhalten werden, wenn festgestellt wird, ob das System 8 dazu konfiguriert war, mit der Vorrichtung 2 eine Schnittstelle zu bilden. Wenn jedoch im Block 14 festgestellt wird, dass das System 8 nicht dazu konfiguriert ist, mit der Vorrichtung 2 eine Schnittstelle zu bilden, dann endet der Prozess und die Vorrichtung 2 bildet mit dem System 8 keine Schnittstelle.
3 ist ein beispielhafter Ablaufplan, der darstellt, wie festgestellt wird, ob das System 8 dazu konfiguriert ist, mit der Vorrichtung 2 unter Verwendung der Systemkonfigurationsdatenbank (SCD 6) eine Schnittstelle zu bilden. Im Block 24 wird die Vorrichtung 2 unter Verwendung eines Standard-Kommunikationsprotokolls abgefragt, um ihren Hersteller, ihr Modell und/oder die eindeutige Kennung zu bestimmen.
Wenn im Block 26 der Hersteller, das Modell oder die eindeutige Kennung der Vorrichtung bestimmt ist, dann geht der Prozess zum Block 36 weiter, ansonsten geht der Prozess zum Block 28 weiter. Im Block 36 wird festgestellt, dass das System dazu konfiguriert ist, mit der Vorrichtung 2 eine Schnittstelle zu bilden.
Im Block 28 wird die Vorrichtung 2 unter Verwendung von Daten, die in der Systemkonfigurationsdatenbank 6 gespeichert sind, abgefragt, um den Hersteller, das Modell und/oder die eindeutige Kennung der Vorrichtung 2 zu bestimmen. Im Block 34 wird festgestellt, ob der Hersteller, das Modell und/oder die eindeutige Kennung der Vorrichtung 2 im Block 28 identifiziert wurde. Wenn die Feststellung des Blocks 34 bejahend ist, dann wird im Block 36 festgestellt, dass das System dazu konfiguriert ist, mit der Vorrichtung 2 eine Schnittstelle zu bilden. Wenn die Feststellung des Blocks 34 verneinend ist, dann wird im Block 38 festgestellt, dass das System nicht dazu konfiguriert ist, mit der Vorrichtung 2 eine Schnittstelle zu bilden.
Beim Abfragen der Vorrichtung 2 für die Hersteller- und Modellinformationen in den Blöcken 24 und 28 werden der Hersteller und das Modell der Vorrichtung mit der Systemunterstützungsdatenbank 10 geprüft, um festzustellen, ob der Hersteller und das Modell vom System 8 unterstützt werden. Es beeinflusst jedoch nicht, ob das System 8 dazu konfiguriert ist, mit der Vorrichtung 2 eine Schnittstelle zu bilden, oder nicht.
Die Systemunterstützungsdatenbank 10 wird verwendet, um festzustellen, welche Statusinformationen von der Vorrichtung 2 erhalten werden sollen, wenn sie vom System 8 überwacht wird. Ein Vorrichtungsobjekt für die Vorrichtung 2 umfasst Informationen von 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 für alle mit dem Netz 4 verbundenen Vorrichtungen erhältlich sind. 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 für alle Vorrichtungen eines Herstellers erhältlich sind. Wenn der Hersteller und das Modell unterstützt werden, dann erhält das Vorrichtungsobjekt Statusinformationen, die für alle Vorrichtungen des Modells erhältlich sind.
4 ist eine Darstellung einer hierarchischen Vorgehensweise, um festzustellen, ob die Vorrichtung 2 vom System 8 unterstützt wird. In den Blöcken 56 und 58 wird festgestellt, ob der Hersteller der Vorrichtung 2 vom System 8 unterstützt wird. Wenn der Hersteller nicht unterstützt wird, dann wird im Block 60 festgestellt, dass die Vorrichtung dazu konfiguriert werden soll, ein allgemeines Protokoll zu verwenden. Wenn der Hersteller unterstützt wird, dann geht der Prozess zum Block 62 weiter.
In den Blöcken 62 und 64 wird festgestellt, ob das Modell der Vorrichtung 2 vom System 8 unterstützt wird. Wenn das Modell nicht unterstützt wird, dann wird im Block 66 festgestellt, dass die Vorrichtung 2 unter Verwendung eines herstellerspezifischen Protokolls konfiguriert werden soll. Wenn das Modell unterstützt wird, dann wird im Block 68 festgestellt, dass die Vorrichtung 2 unter Verwendung eines modellspezifischen Protokolls konfiguriert werden soll.
5 stellt Softwareobjekte dar. Das Softwareobjekt Send Interface Manager (Sendeschnittstellenmanager) 70 bildet mit den Softwareobjekten DataTransfer (Datenübertragung) 74, ODBC-172, DeviceFactory (Vorrichtungswerk) 76, VendorModel (Verkäufermodell) 78, ODBC-2 84, SNMP 80 und Device (Vorrichtung) 82 direkt oder indirekt eine Schnittstelle.
Die Tabelle 1 stellt die Funktionen des ODBC-1 72 dar.
TABELLE 1
Tabelle 2 stellt die Funktionen von DeviceFactory 76 dar.
TABELLE 2
Tabelle 3 stellt die Funktionen von DataTransfer 74 dar.
TABELLE 3
Tabelle 4 stellt die Funktionen von Device 82 dar.
TABELLE 4
Tabelle 5 stellt die Funktionen von ODBC-2 84 dar.
TABELLE 5
Tabelle 6 stellt die Funktionen von SNMP 80 dar.
TABELLE 6
Das VendorModel 78 ist zum 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 des VendorModel 78 verwendet Informationen aus der Datenbank, um die vom 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 privaten Funktionen des CVendorModel sind in der nachstehenden Tabelle 7 gezeigt.
TABELLE 7
Die nachstehende Tabelle 8 zeigt die Attribute der CVendorModel-Klasse, die in den obigen Funktionen verwendet werden.
TABELLE 8
ManufacturerAndModelInfo im m_ManufacturerAndModelInfo-Vektor hat die folgende Struktur:
m_sManufacturer ist der Name des Herstellers. m_sEnterpriseOID ist die Unternehmensobjektkennung, die dem Hersteller zugeordnet ist. Die Unternehmensobjektkennung ist für einen Hersteller eindeutig. m_sModelOID ist die Objektkennung, die verwendet werden kann, um den Modellnamen der Vorrichtung zu finden. m_sUniqueOID ist die Objektkennung, die verwendet werden kann, um die eindeutige Kennung der Vorrichtung zu finden. Die eindeutige Kennung kann die Seriennummer oder die MAC-Adresse der Vorrichtung sein.
DeviceFactory 76 ist zum Erzeugen eines Vorrichtungsobjekts verantwortlich, das die überwachte Vorrichtung darstellt. DeviceFactory 76 stellt sicher, dass das Vorrichtungsobjekt weiß, welche Statusinformationen es erhalten muss. CDevice- Factory ist die einzige Klasse im Paket der DeviceFactory 76. Die öffentlichen und privaten Funktionen von CDeviceFactory sind in der nachstehenden Tabelle 9 gezeigt.
TABELLE 9
Die nachstehende Tabelle 10 zeigt die Attribute der CDeviceFactory-Klasse, die in den obigen Funktionen verwendet werden.
TABELLE 10
infoType ist eine Zahl, die in m_GenericDeviceVector und m_ManufacturerVectorMap verwendet wird, das verwendet wird, um einen speziellen Typ von Statusinformationen darzustellen. 503 stellt beispielsweise eine Bedingung Kein Papier für die überwachte Vorrichtung dar und 601 stellt die Seitenlebensdauerzahl der überwachten Vorrichtung dar.
Device 82 stellt eine überwachte Vorrichtung dar. Es greift auf Statusinformationen der überwachten Vorrichtung zu. Die Statusinformationen umfassen Informationen wie z. B. Fehlerstatus, Seitenzahl, Tonerkartuschenstand und Warnungen. CDevice ist die einzige Klasse im Paket von Device 82. Die öffentlichen Funktionen von CDevice sind in der nachstehenden Tabelle 11 gezeigt.
TABELLE 11
Die nachstehende Tabelle 12 zeigt die Attribute der CDevice-Klasse, die in den obigen Funktionen verwendet werden.
TABELLE 12
6 stellt ein beispielhaftes Sequenzdiagramm dar, wenn das System initialisiert wird, um Informationen über die Objektkennungen zu erhalten, die verwendet werden, um den Hersteller, das Modell und die eindeutige Kennung zu identifizieren, und um Informationen über die Hersteller und Modelle, die vom System unterstützt werden, zu erhalten. Das VendorModel 86 wirkt mit ODBC2 88 zusammen, um diese Informationen zu erhalten. ODBC2 88 stellt eine Schnittstelle mit der Datenbank bereit, um Informationen zu erhalten, die von dieser vom VendorModel 86 angefordert werden. Das VendorModel 86 ruft die Funktion getManufInfo() 90 von ODBC2 88 auf, um die Objektkennungen, die verwendet werden, um den Hersteller, das Modell und die eindeutige Kennung der überwachten Vorrichtungen zu identifizieren, von der Datenbank zu erhalten. Diese Informationen werden im Vektor m_ManufacturerAndModelInfoVector, der in obiger Tabelle 8 beschrieben ist, gespeichert. getManufInfo() 90 wird mehrere Male aufgerufen, bis alle Objektkennungen für alle vom 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 vom System unterstützt werden, aus der Datenbank zu erhalten. Diese Informationen werden in der Abbildung m_ManufacturerModelMap, die in obiger Tabelle 8 beschrieben ist, gespeichert. getSupportedModel() wird mehrere Male aufgerufen, bis alle Modelle, die vom System unterstützt werden, aus der Datenbank eingelesen sind. Zum Entfernen, Modifizieren oder Hinzufügen der Hersteller und Modelle, die vom System unterstützt werden, liegt die einzige erforderliche Änderung in der Datenbank, die Informationen über die unterstützten Hersteller und Modelle speichert. Am System muss keine Änderung vorgenommen werden, wenn sich die vom System unterstützten Hersteller und Modelle ändern. Die Informationen werden während der Initialisierung aus der Datenbank eingelesen.
7 stellt ein beispielhaftes Sequenzdiagramm zum Erzeugen von Vorrichtungsobjekten dar, um die überwachten Vorrichtungen während der Initialisierung darzustellen. Anfänglich versucht das System 8 (1), eine Kommunikation mit der Vorrichtung 2 herzustellen. Wenn das System 8 nicht konfiguriert werden kann, um mit der Vorrichtung 2 eine Schnittstelle zu bilden, werden Konfigurationsinformationen, wie z. B. Hersteller, Modell und eine eindeutige Kennung von der Vorrichtung 2 erhalten. Im Prozess der Bestimmung der Konfigurationsinformationen wird eine Feststellung durchgeführt, um herauszufinden, ob die Vorrichtung 2 vom System 8 unter Verwendung von Informationen von der Systemunterstützungsdatenbank (SSD 10) unterstützt wird. Ein Vorrichtungsobjekt wird unter Verwendung von Informationen von der SSD 10 erzeugt, wobei folglich ein Kommunikationsprotokoll zwischen dem System 8 und der Vorrichtung 2 – ungeachtet dessen, ob die Vorrichtung vom System 8 unterstützt wird oder nicht – festgelegt wird. Anschließend werden die Konfigurationsinformationen für die Vorrichtung 2 in der Systemkonfigurationsdatenbank (SCD 6) aktualisiert. SendInterfaceManager 94 ruft getConfig() 102 von ODBC 96 auf. ODBC 96 stellt eine Schnittstelle mit der Datenbank bereit, um Konfigurationsinformationen der überwachten Vorrichtungen zu erhalten. Die Konfigurationsinformationen umfassen den Herstellernamen, den Modellnamen und die IP-Adresse der überwachten Vorrichtung, den Namen, die Telephonnummer und die E-Mail-Adresse der Kontaktperson, die für die überwachte Vorrichtung verantwortlich ist. Die Datenbank enthält die Konfigurationsinformationen aller Vorrichtungen, die überwacht werden sollen. Nicht alle der Vorrichtungen in dieser Datenbank können jedoch vom System unterstützt werden, wie in der Datenbank festgelegt, die dem ODBC2 84 von 5 zugeordnet ist.
SendInterfaceManager 94 ruft setAgent() 104 auf, was eine SNMP-Sitzung mit der überwachten Vorrichtung erzeugt, um den Hersteller, das Modell und die eindeutige Kennung der Vorrichtung zu erhalten. Mehr Details dieser Funktion sind in 8 bereitgestellt. 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 vom 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.
Alle Schritte in der Sequenz werden wiederholt, bis alle überwachten Vorrichtungen in der Datenbank erhalten sind. Ein Vorrichtungsobjekt wird für jede der überwachten Vorrichtungen erzeugt. SendInterfaceManager 94 hält jedes der Vorrichtungsobjekte aufrecht.
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 richtet eine SNMP-Sitzung zwischen dem System und der überwachten Vorrichtung ein. 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 getNextStringValueForOID() 128 von SNMP 120 auf, um die Unternehmensobjektkennung über SNMP von der überwachten Vorrichtung zu erhalten. Die Unternehmensobjektkennung wird verwendet, um 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 den Modellnamen der überwachten Vorrichtung über SNMP zu erhalten. VendorModel 118 ruft seine eigene Funktion obtainUniqueID() 134 auf, um die eindeutige Kennung der überwachten Vorrichtung zu erhalten. In der Funktion obtain-UniqueID() 134 ruft VendorModel 118 getNextStringValueForOID() 136 von SNMP 120 auf, um die eindeutige Kennung der überwachten Vorrichtung über SNMP zu erhalten.
9 ist ein beispielhafter Ablaufplan der Funktion setAgent() von VendorModel. In Schritt 140 werden die Variablen, die den Herstellernamen, den Modellnamen und die eindeutige Kennung darstellen, auf einen leeren String gesetzt. Diese Variablen sind m_sManufacturer, m_sModel und m_sUniqueID, wie in Tabelle 8 veranschaulicht. In Schritt 142 wird die Unternehmensobjektkennung der überwachten Vorrichtung über SNMP erhalten. In Schritt 144 wird die Unternehmensobjektkennung, die von der überwachten Vorrichtung erhalten wird, mit den vom System unterstützten verglichen. Die Unternehmensobjektkennung und ihr entsprechender Hersteller, der vom System unterstützt wird, werden im Vektor m_ManufacturerAndModelInfoVector gespeichert, wie in Tabelle 8 beschrieben.
Der Vektor wird durchsucht, um festzustellen, ob die Unternehmensobjektkennung der überwachten Vorrichtung gefunden wird. Wenn die Unternehmensobjektkennung im Vektor nicht gefunden werden kann, dann wird Schritt 156 als nächstes verarbeitet. Wenn die Unternehmensobjektkennung im Vektor gefunden wird, dann wird der Hersteller der überwachten Vorrichtung vom System unterstützt und Schritt 146 wird als nächstes verarbeitet. In Schritt 146 wird die Variable für den Herstellernamen m_sManufacturer auf den Herstellernamen entsprechend der Unternehmensobjektkennung im Vektor gesetzt. In Schritt 148 werden die Variablen m_sCurrentModelOID und m_sCurrentUniqueOID für die Objektkennung, die verwendet wird, um den Modellnamen und die eindeutige Kennung der überwachten Vorrichtung zu finden, auf die Objektkennungen gesetzt, die der Unternehmensobjektkennung im Vektor entsprechen. In Schritt 150 wird der Modellname von der überwachten Vorrichtung über SNMP unter Verwendung der Objektkennung m_sCurrentModelOID erhalten.
In Schritt 152 wird der von der überwachten Vorrichtung erhaltene Modellname mit den vom System unterstützten verglichen. Der Hersteller und das Modell, die vom System unterstützt werden, werden in der Abbildung m_ManufacturerModelMap gespeichert, wie in Tabelle 8 beschrieben. Die Abbildung wird durchsucht, um festzustellen, ob das Modell in der Abbildung gefunden wird. Wenn das Modell in der Abbildung nicht gefunden werden kann, dann wird Schritt 156 als nächstes verarbeitet. Wenn das Modell in der Abbildung gefunden werden kann, dann wird das Modell der überwachten Vorrichtung vom System unterstützt und Schritt 154 wird als nächstes verarbeitet. In Schritt 154 wird die Variable für den Modellnamen m_sModel auf den Modellnamen gesetzt, der von der überwachten Vorrichtung erhalten wird. In Schritt 156 wird die eindeutige Kennung von der überwachten Vorrichtung über SNMP unter Verwendung der Objektkennung m_sCurrent-UniqueOID erhalten. Dann wird die Variable für die eindeutige Kennung m_sUniqueID auf die von der überwachten Vorrichtung erhaltene eindeutige Kennung gesetzt.
Die Funktion setAgent() von VendorModel ermöglicht, dass das System den Herstellernamen und Modellnamen der überwachten Vorrichtung über SNMP erhält, um festzustellen, ob sie vom System unterstützt wird. Es ermöglicht auch, dass das System den Herstellernamen und Modellnamen überprüft.
10 veranschaulicht ein Sequenzdiagramm, wenn das System Informationen erhält, die verwendet werden, um die Statusinformationen für den speziellen Hersteller und das spezielle Modell der überwachten Vorrichtungen zu erhalten. DeviceFactory 160 wirkt mit ODBC2 162 zusammen, um diese Informationen zu erhalten. ODBC2 162 stellt eine Schnittstelle mit der Datenbank bereit, um Informationen zu erhalten, die von dieser durch DeviceFactory 160 angefordert werden. DeviceFactory 160 ruft die Funktion getManufStatusInfo() 164 von ODBC2 162 auf, um Informationen zu erhalten, die erforderlich sind, um die Statusinformationen von überwachten Vorrichtungen für einen speziellen Hersteller über SNMP zu erhalten. Die Informationen umfassen eine Zahl (infoType), die irgendeinen Typ von Statusinformationen darstellt, und eine Objektkennung, die verwendet wird, um die Statusinformationen über SNMP zu erhalten. getManufStatusInfo() 166 wird mehrere Male aufgerufen, bis die Informationen, die erforderlich sind, um alle Statusinformationen für einen speziellen Hersteller zu erhalten, aus der Datenbank eingelesen sind. Dann ruft DeviceFactory 160 die Funktion getModelStatusInfo() 168 von ODBC2 162 auf, um Informationen zu erhalten, die erforderlich sind, um Statusinformationen von überwachten Vorrichtungen für ein spezielles Modell über SNMP zu erhalten. Die Informationen umfassen eine Zahl (infoType), die einen gewissen Typ von Statusinformationen darstellt, und eine Objektkennung, die verwendet wird, um die Statusinformationen über SNMP zu erhalten. getModelStatusInfo() 170 wird mehrere Male aufgerufen, bis die Informationen, die erforderlich sind, um alle Statusinformationen für ein spezielles 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.
Unter Verwendung der Datenbank, um Informationen zu speichern, die verwendet werden, um die Statusinformationen, die den Hersteller betreffen, und die Statusinformationen, die das Modell betreffen, zu erhalten, können die von den überwachten Vorrichtungen zu erhaltenden Statusinformationen ohne irgendwelche Änderungen am System leicht modifiziert, aus der Datenbank entfernt oder zu dieser hinzugefügt werden.
11 zeigt den Ablaufplan für die Funktion createDevice() von DeviceFactory. In Schritt 174 wird ein Vorrichtungsobjekt erzeugt, um die überwachten Vorrichtungen darzustellen. In Schritt 176 wird ein Vektor, der Informationen enthält, die zum Erhalten von Statusinformationen von Vorrichtungen aller Hersteller erforderlich sind, einem lokalen Vektor zugewiesen. Dieser Vektor entspricht m_Generic-DeviceVector, der in Tabelle 10 beschrieben ist. In Schritt 178 wird der Herstellername der überwachten Vorrichtung geprüft, um festzustellen, ob er vom System unterstützt wird (der Herstellername ist ein leerer String, wenn er nicht vom System unterstützt wird). Wenn der Herstellername nicht unterstützt wird, dann wird Schritt 186 als nächstes verarbeitet. Wenn der Herstellername unterstützt wird, dann wird Schritt 180 als nächstes verarbeitet.
In Schritt 180 werden Informationen, die zum Erhalten von Statusinformationen von der überwachten Vorrichtung eines speziellen Herstellers erforderlich sind, von einer Abbildung erhalten und zum lokalen Vektor hinzugefügt. Die Abbildung entspricht m_ManufacturerVectorMap, die in Tabelle 10 beschrieben ist. In Schritt 182 wird der Modellname der überwachten Vorrichtung geprüft, um festzustellen, ob er vom System unterstützt wird (der Modellname ist ein leerer String, wenn er nicht vom System unterstützt wird). Wenn der Modellname nicht unterstützt wird, dann wird Schritt 186 als nächstes verarbeitet. Wenn der Modellname unterstützt wird, dann wird Schritt 184 als nächstes verarbeitet.
In Schritt 184 werden Informationen, die erforderlich sind, um Statusinformationen von der überwachten Vorrichtung eines speziellen Modells zu erhalten, von der Datenbank erhalten und zum lokalen Vektor hinzugefügt. In Schritt 186 wird der lokale Vektor, der die Informationen enthält, die zum Erhalten aller Statusinformationen der überwachten Vorrichtung erforderlich sind, im Vorrichtungsobjekt festgelegt. Das Vorrichtungsobjekt besitzt Informationen darüber, welche Statusinformationen es von der überwachten Vorrichtung erhalten muss.
DeviceFactory erzeugt und initialisiert alle Vorrichtungsobjekte, so dass es weiß, welche Statusinformationen es erhalten muss.
12 zeigt das Sequenzdiagramm zum Ausführen der Funktion monitorStatus(). Der Prozess sendet die Statusinformationen der überwachten Vorrichtungen zu einer gewünschten Stelle. SendInterFaceManager 190 ruft startSend() 198 von DataTransfer 196 auf, um das System auf das Senden der Statusinformationen der überwachten Vorrichtungen über E-Mail (SMTP) vorzubereiten. SendInterfaceManager 190 ruft getStatus() 200 von Device 194 auf, um die Statusinformationen der überwachten Vorrichtung zu erhalten. Device 194 entspricht der überwachten Vorrichtung und sie weiß, welche Statusinformationen sie erhalten muss. SendInterfaceManager 190 ruft saveStatus() 202 von ODBC 192 auf, um die Statusinformationen der überwachten Vorrichtung in der Datenbank zu speichern. SendInterfaceManager 190 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. Es ist ein Vorrichtungsobjekt für jede überwachte Vorrichtung vorhanden. SendInterfaceManager 190 ruft endSend() 206 von DataTransfer 196 auf, um das Senden der Statusinformationen über E-Mail zu beenden.
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 speziellen Herstellers und Modells dar. Die Statusinformationen werden von den überwachten Vorrichtungen über SNMP erhalten. Wenn die überwachte Vorrichtung vom 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 (die Statusinformationen des gesamten Systems) wie z. B. der Fehlerstatus. Wenn der Hersteller, aber nicht das Modell der überwachten Vorrichtung vom System unterstützt wird, dann sind die von der überwachten Vorrichtung erhaltenen Statusinformationen die Statusinformationen des ganzen Systems und die Statusinformationen, die für alle überwachten Vorrichtungen des speziellen Herstellers erhältlich sind (herstellerspezifische Statusinformationen). Wenn der Hersteller und das Modell der überwachten Vorrichtung vom System unterstützt werden, dann sind die von der überwachten Vorrichtung erhaltenen Statusinformationen die Statusinformationen des ganzen Systems, die herstellerspezifischen Statusinformationen und die Statusinformationen, die für alle überwachten Vorrichtungen des speziellen Modells erhältlich sind (modellspezifische Statusinformationen). Device 210 enthält einen Vektor, so dass sie weiß, welche Informationen sie erhalten muss. Device 210 ruft getNextStringValueForOID() von Snmp 212 auf, so dass das System die Statusinformationen von der überwachten Vorrichtung über SNMP erhalten kann. getNextStringValueForOID() 218 wird mehrere Male aufgerufen, um alle Statusinformationen von der überwachten Vorrichtung zu erhalten.
14 zeigt die Tabellen einer Datenbank, die Informationen über die vom Sys tem unterstützten Hersteller und Modelle enthalten. Die Tabelle umfasst 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 vom System unterstützten Hersteller enthält. Manufacturer 230 enthält auch die folgenden Informationen – Unternehmensobjektkennung für den Hersteller, Objektkennung, die zum Finden des Modellnamens der überwachten Vorrichtung verwendet wird, und Objektkennung, die zum Finden der eindeutigen Kennung der überwachten Vorrichtung verwendet wird. SupportedModelByManufacturer 220 ist die Tabelle, die die Modelle mit ihrem entsprechenden Hersteller, der vom System unterstützt wird, enthält. Um Hersteller und Modelle, die vom System unterstützt werden, hinzuzufügen oder zu entfernen, müssen nur die Tabellen Manufacturer 230 und SupportedModelByManufacturer 220 modifiziert werden. Am Code des Systems müssen keine Modifikationen vorgenommen werden. Das System liest die Informationen aus diesen Tabellen der Datenbank.
ComManufStatus 226 ist die Tabelle, die Informationen darüber enthält, welche Informationen von der überwachten Vorrichtung auf der Basis ihres Herstellernamens erhalten werden. Die Tabelle enthält den Herstellernamen und eine Zahl, die den Informationstyp darstellt. ModelStatus 222 ist die Tabelle, die Informationen darüber enthält, welche Informationen von der überwachten Vorrichtung auf der Basis ihres Modellnamens erhalten werden. Die Tabelle enthält den Herstellernamen, den Modellnamen und eine Zahl, die den Informationstyp darstellt. Um Informationen zu den von der überwachten Vorrichtung erhaltenen hinzuzufügen oder von diesen 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.
EnumOID 224 ist die Tabelle, die Informationen über die Objektkennung enthält, die verwendet wird, um die der Zahl entsprechenden Informationen zu finden. Die Objektkennung wird vom System verwendet, um einen speziellen Informationstyp von der überwachten Vorrichtung über SNMP zu finden. EnumCorrespondence 228 ist die Tabelle, die eine Beschreibung der zum Darstellen eines Informationstyps verwendeten Zahlen enthält. Diese Tabelle wird vom System nicht verwendet, sondern versieht den Anwender des Systems mit Informationen darüber, was die Zahlen darstellen.
15 zeigt ein Beispiel der Inhalte in den Tabellen der Datenbank, wie in 14 beschrieben. Microsoft Access ist die zum Speichern von Informationen über die vom System unterstützten Hersteller und Modelle verwendete Datenbank.
16 zeigt das Klassendiagramm für das ODBC2-Paket. Die Klasse CSupport-ODBC 232 ist die Schnittstelle für dieses Paket, um auf Informationen in der Datenbank zuzugreifen. Die Klasse CManufacturerData 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 von der Datenbank über den Hersteller und das Modell der überwachten Vorrichtung, die vom System unterstützt wird, zu. Die Klasse CComManufStatusData 236 greift auf Informationen aus der Datenbank zu, die erforderlich sind, um Herstellerstatusinformationen zu erhalten, die der überwachten Vorrichtung zugeordnet sind. Die Klasse CModelStatusData 238 greift auf Informationen von der Datenbank zu, die erforderlich sind, um Modellstatusinformationen zu erhalten, die der überwachten Vorrichtung zugeordnet sind. Die Klasse CManufacturerDatabase 242 stellt eine Schnittstelle mit der Tabelle in der Datenbank bereit, die die Herstellerinformationen enthält. Die Klasse CSupportedModelDatabase 244 stellt eine Schnittstelle mit der Tabelle in der Datenbank breit, die Informationen über unterstützte Modelle enthält. Die Klasse CComManufStatusDatabase 246 stellt eine Schnittstelle mit der Tabelle in der Datenbank bereit, die die Herstellerstatusinformationen enthält. Die Klasse CModelStatusDatabase 250 stellt eine Schnittstelle mit der Tabelle in der Datenbank bereit, die die Modellstatusinformationen enthält. Die Klasse CInfoTypeOID-Database 248 stellt eine Schnittstelle mit der 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 CInfoTypeOIDDatabase 248 sind alle Klassen, die von CRecordset 252 der Bibliothek der Microsoft Foundation Class (MFC) abgeleitet sind.
Die vorangehende Beschreibung der bevorzugten Ausführungsform der vorliegenden Erfindung wurde für die Zwecke der Erläuterung und Beschreibung dargestellt. Sie soll nicht erschöpfend sein oder die Erfindung auf die offenbarte genaue Form begrenzen. Ein oder mehrere beliebige der hierin beschriebenen oder gezeigten Konzepte können beispielsweise auf das System und/oder Verfahren angewendet werden, das in der US-Patentanmeldung Veröffentlichung Nr. 20020152292 (SerienNr. 09/756 120), eingereicht am 9. Januar 2001, mit dem Titel "Method and System of Remote Support of Device Using Email", offenbart ist. Überdies kann ein beliebiges Konzept oder Merkmal, das in der US-Patentanmeldung Nr. 09/756 120 beschrieben ist, auf die hierin offenbarten Systeme oder Verfahren angewendet werden. Die Ausführungsformen wurden gewählt und beschrieben, um die Prinzipien der Erfindung und ihre praktischen Anwendungen am besten zu erläutern, wodurch ermöglicht wird, dass andere Fachleute die Erfindung verwenden. Es ist vorgesehen, dass der Schutzbereich der vorliegenden Erfindung nur durch die hier beigefügten Ansprüche definiert ist.

Claims

Verfahren zum Aufbauen einer Verbindung zwischen wenigstens einer Vorrichtung und einem Überwachungssystem (8), wobei die wenigstens eine Vorrichtung (2) und das Überwachungssystem (8) über ein Netz (4) kommunikationsfähig gekoppelt sind, wobei das Überwachungssystem (8) mit einer ersten Datenbank (6) und mit einer zweiten Datenbank (10) kommunikationsfähig gekoppelt ist, wobei das Verfahren die folgenden Schritte umfasst: a) Feststellen, ob das Überwachungssystem (8) so konfiguriert ist, dass es mit der wenigstens einen Vorrichtung (2) eine Schnittstelle bildet; b) Erhalten von Konfigurationsinformationen von der wenigstens einen Vorrichtung (2), falls das Überwachungssystem (8) nicht so konfiguriert ist, dass es mit der wenigstens einen Vorrichtung (2) eine Schnittstelle bildet; c) Feststellen, ob die wenigstens eine Vorrichtung (2) durch das Überwachungssystem (8) unter Verwendung von in der zweiten Datenbank (10) gespeicherten Informationen unterstützt wird; d) Erzeugen eines Vorrichtungsobjekts unter Verwendung von in der ersten Datenbank (6) und in der zweiten Datenbank (10) gespeicherten Informationen, um eine Kommunikation zwischen der wenigstens einen Vorrichtung (2) und dem Überwachungssystem (8) aufzubauen, wobei das Vorrichtungsobjekt Bezugnahmen auf Konfigurationsinformationen enthält, die in der ersten Datenbank (6) gespeichert sind, wobei die Bezugnahmen Vektoren oder Matrizen verwenden; und e) Aktualisieren von in der ersten Datenbank (2) gespeicherten Konfigurationsinformationen für die wenigstens eine Vorrichtung (2) mit in der zweiten Datenbank (10) gespeicherten Konfigurationsinformationen, damit das Überwachungssystem (8) mit der wenigstens einen Vorrichtung (2) eine Schnittstelle bilden kann, wodurch eine Flexibilität bei der Erzeugung von Vorrichtungsobjekten ermöglicht wird.
Verfahren nach Anspruch 1, bei dem der Schritt des Erhaltens von Konfigurationsinformationen von der wenigstens einen Vorrichtung (2) das Identifizieren wenigstens eines der folgenden umfasst: i) Hersteller der Vorrichtung (2), ii) Modell der Vorrichtung (2) und iii) eindeutige Kennung der wenigstens einen Vorrichtung (2).
Verfahren nach Anspruch 2, bei dem die Konfigurationsinformationen nur während der Initialisierung des Überwachungssystems verwendet werden, um festzustellen, ob wenigstens eine Vorrichtung (2) eine Überwachung erfordert.
Verfahren nach Anspruch 1, 2 oder 3, bei dem der Schritt des Feststellens, ob das Überwachungssystem (8) so konfiguriert ist, dass es mit der wenigstens einen Vorrichtung (2) eine Schnittstelle bildet, das Abfragen der ersten Datenbank (6) mit dem Hersteller und/oder dem Modell und/oder der eindeutigen Kennung der wenigstens einen Vorrichtung (2) umfasst.
Verfahren nach Anspruch 1, 2, 3 oder 4, bei dem der Schritt des Feststellens, ob das Überwachungssystem (8) so konfiguriert ist, dass es mit der wenigstens einen Vorrichtung (2) eine Schnittstelle bildet, das Abfragen der wenigstens einen Vorrichtung (2) mit in der ersten Datenbank (6) gespeicherten Daten umfasst.
Verfahren nach Anspruch 5, bei dem die erste Datenbank (6) eine Systemkonfigurationsdatenbank ist und umfasst: Konfigurationsinformationen, die eine Kommunikation zwischen dem Überwachungssystem und der wenigstens einen Vorrichtung (2) ermöglichen; und Statusinformationen, die auf die wenigstens eine Vorrichtung (2) bezogen sind, wobei die Statusinformationen nach der Initialisierung des Überwachungssystems (8) hinzugefügt werden, um die wenigstens eine Vorrichtung (2) zu überwachen.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die zweite Datenbank (10) eine Systemunterstützungsdatenbank ist und Informationen über verschiedene Hersteller und Vorrichtungsmodelle, die durch das Überwachungssystem (8) unterstützt werden, enthält.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Schritt des Feststellens, ob die wenigstens eine Vorrichtung durch das Überwachungssystem (8) unterstützt wird, ferner das Erhalten detaillierter Statusinformationen der wenigstens einen überwachten Vorrichtung (2) umfasst, falls der Hersteller und das Modell der wenigstens einen Vorrichtung (2) durch das Überwachungssystem (8) unterstützt werden.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem das Vorrichtungsobjekt dem Überwachungssystem (8) ermöglicht, mit der wenigstens einen Vorrichtung (2) zu kommunizieren und Konfigurationsinformationen, die von der wenigstens einen Vorrichtung (2) benötigt werden, zu bestimmen.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem das Vorrichtungsobjekt, das Bezugnahmen für Konfigurationsinformationen speichert, Objektkennungen enthält.
Verfahren nach einem der vorhergehenden Ansprüche, bei der die wenigstens eine Vorrichtung (2) Hardware-Komponenten enthält.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die wenigstens eine Vorrichtung (2) Software-Komponenten enthält.
Vorrichtung, die so beschaffen ist, dass sie eine Verbindung mit wenigstens einer Vorrichtung (2) aufbaut, die über ein netzbasiertes System kommunikationsfähig gekoppelt ist, wobei die Vorrichtung umfasst: ein Überwachungssystem (8), das mit dem Netz kommunikationsfähig gekoppelt ist; eine erste Datenbank (6) und eine zweite Datenbank (10), die mit dem Überwachungssystem (8) kommunikationsfähig gekoppelt sind; Mittel, um festzustellen, ob das Überwachungssystem so konfiguriert ist, dass es mit der wenigstens einen Vorrichtung (2) eine Schnittstelle bildet; Mittel, um Konfigurationsinformationen von der wenigstens einen Vorrichtung (2) zu erhalten, falls das Überwachungssystem (8) nicht so konfiguriert ist, dass es mit der wenigstens einen Vorrichtung eine Schnittstelle bildet; Mittel, um festzustellen, ob die wenigstens eine Vorrichtung (2) durch das Überwachungssystem (8) unterstützt wird, unter Verwendung von in der zweiten Datenbank (10) gespeicherten Konfigurationsinformationen; Mittel, um unter Verwendung von Konfigurationsinformationen, die in der ersten Datenbank (6) und in der zweiten Datenbank (10) gespeichert sind, ein Vorrichtungsobjekt zu erzeugen, um eine Kommunikation zwischen der wenigstens einen Vorrichtung (2) und dem Überwachungssystem (8) aufzubauen, wobei das Vorrichtungsobjekt Bezugnahmen für Konfigurationsinformationen, die in der Datenbank (6) gespeichert sind, enthält, wobei die Bezugnahmen Vektoren oder Matrizen verwenden; und Mittel, um in der ersten Datenbank (6) gespeicherte Konfigurationsinformationen für die wenigstens eine Vorrichtung (2) mit in der zweiten Datenbank (10) gespeicherten Konfigurationsinformationen zu aktualisieren, damit das Überwachungssystem mit der wenigstens einen Vorrichtung eine Schnitstelle bilden kann, wodurch eine Flexibilität bei der Erzeugung von Vorrichtungsobjekten ermöglicht wird.
Vorrichtung nach Anspruch 13, bei der die Konfigurationsinformationen Informationen enthalten, die bezogen sind auf: i) Hersteller, ii) Modell und iii) eindeutige Kennung der wenigstens einen Vorrichtung (2).
Vorrichtung nach Anspruch 14, bei der die Konfigurationsinformationen nur während der Initialisierung des Überwachungssystems (8) verwendet werden, um wenigstens eine Vorrichtung (2), die eine Überwachung erfordert, zu identifizieren.
Vorrichtung nach Anspruch 13, 14 oder 15, die ferner umfasst: Mittel, um die erste Datenbank (6) mit dem Hersteller und/oder dem Modell und/oder der eindeutigen Kennung der wenigstens einen Vorrichtung (2) abzufragen, um festzustellen, ob das Überwachungssystem (8) so konfiguriert ist, dass es mit der wenigstens einen Vorrichtung (2) eine Schnittstelle bildet.
Vorrichtung nach Anspruch 13, 14, 15 oder 16, die ferner umfasst: Mittel, um die wenigstens eine Vorrichtung (2) mit in der ersten Datenbank (6) gespeicherten Daten abzufragen, um festzustellen, ob das Überwachungssystem (8) so konfiguriert ist, dass es mit der wenigstens einen Vorrichtung (2) eine Schnittstelle bildet.
Vorrichtung nach einem der Ansprüche 13 bis 17, bei der die erste Datenbank (6) eine Systemkonfigurationsdatenbank ist und umfasst: Konfigurationsinformationen, die eine Kommunikation zwischen dem Überwachungssystem und der wenigstens einen Vorrichtung (2) ermöglichen; und Statusinformationen, die auf die wenigstens eine Vorrichtung (2) bezogen sind, wobei die Statusinformationen nach der Initialisierung des Überwachungssystems hinzugefügt werden, um die wenigstens eine Vorrichtung (2) zu überwachen.
Vorrichtung nach einem der Ansprüche 13 bis 18, bei der die zweite Datenbank (10) eine Systemunterstützungsdatenbank ist und Informationen über verschiedene Hersteller und Vorrichtungsmodelle, die durch das Überwachungssystem (8) unterstützt werden, enthält.
Vorrichtung nach einem der Ansprüche 13 bis 19, bei der das Vorrichtungsobjekt dem Überwachungssystem (8) ermöglicht, mit der wenigstens einen Vorrichtung (2) zu kommunizieren und Konfigurationsinformationen zu bestimmen, die von der wenigstens einen Vorrichtung (2) benötigt werden.
Vorrichtung nach einem der Ansprüche 13 bis 20, bei der das Vorrichtungsobjekt, das Bezugnahmen für Konfigurationsinformationen speichert, Objektkennungen enthält.
Vorrichtung nach einem der Ansprüche 13 bis 20, bei der die wenigstens eine Vorrichtung (2) Hardware-Komponenten enthält.
Vorrichtung nach einem der Ansprüche 13 bis 22, bei der die wenigstens eine Vorrichtung (2) Software-Komponenten enthält.
Computerprogramm, das Programmcodemittel enthält, die, wenn sie auf einem Computersystem ausgeführt werden, das Computersystem anweisen, das Verfahren nach einem der Ansprüche 1 bis 12 auszuführen.
System, das wenigstens eine mit einem Netz (4) verbundene Vorrichtung (2) besitzt, wobei das System umfasst: eine Steuereinheit (8), um die wenigstens eine mit dem Netz verbundene Vorrichtung zu überwachen, wobei die Steuereinheit eine Logik aufweist, um: festzustellen, ob die Steuereinheit (8) so konfiguriert ist, dass sie mit der wenigstens einen über das Netz verbundenen Vorrichtung (2) eine Schnittstelle bildet; und um Konfigurationsinformationen von der wenigstens einen über das Netz verbundenen Vorrichtung (2) zu erhalten, falls die Steuereinheit (8) nicht so konfiguriert ist, dass sie mit der wenigstens einen mit dem Netz verbundenen Vorrichtung (2) eine Schnittstelle bildet; eine erste Datenbank (6) und eine zweite Datenbank (10), die mit der Steuereinheit (8) kommunikationsfähig gekoppelt sind, wobei die zweite Datenbank (10) Konfigurationsinformationen speichert, um festzustellen, ob die wenigstens eine mit dem Netz verbundene Vorrichtung (2) durch die Steuereinheit (8) unterstützt wird, wobei die erste Datenbank (6) und die zweite Datenbank (10) Konfigurationsinformationen besitzen, um ein Vorrichtungsobjekt zu erzeugen um eine Kommunikation zwischen der wenigstens einen mit dem Netz verbundenen Vorrichtung (2) und der Steuereinheit (8) aufzubauen, wobei das Vorrichtungsobjekt Bezugnahmen für in der ersten Datenbank gespeicherte Konfigurationsinformationen enthält, wobei die Bezugnahmen Vektoren oder Matrizen verwenden; und wobei die Konfigurationsinformationen in der ersten Datenbank (6) mit in der zweiten Datenbank (10) gespeicherten Konfigurationsinformationen aktualisiert werden, damit die Steuereinheit mit der wenigstens einen mit dem Netz verbundenen Vorrichtung (2) eine Schnittstelle bilden kann, wodurch eine Flexibilität bei der Erzeugung von Vorrichtungsobjekten ermöglicht wird.