DE10220938A1 - Ein Verfahren und ein System zum Prüfen einer Unternehmenskonfiguration - Google Patents

Abstract

Es wird ein Verfahren zum Prüfen der Konfiguration eines Unternehmens geschaffen, das folgende Schritte aufweist: Sammeln von Informationen, die sich auf die Konfiguration des Unternehmens beziehen, Analysieren der Konfigurationsinformationen, basierend auf Fachkenntnis; und Bereitstellen des Ergebnisses der Analyse in der Form von Berichten, sowie andere Ergebnisse der Analyse.

Description

• Die vorliegende Erfindung bezieht sich allgemein auf das Feld des Prüfens einer Konfiguration eines Unternehmens, und insbesondere auf ein Verfahren und ein System zum Analysieren der Konfigurationsinformationen eines Unternehmens basierend auf Fachkenntnis.
• Das zentrale Geschäft von heutigen Unternehmen hängt mehr und mehr von Informationstechnologie("IT")-Diensten ab. Als solches wird die Auswirkung von Ausfallzeiten oder Unterbrechungen im Dienst immer bedeutender. Geschäfte erfordern daher einen kontinuierlichen Betrieb einer Infrastruktur oder eines Systems. Aufgrund dieser Anforderung wird eine Infrastruktur, die "immer eingeschaltet" ist eher zur Regel als zur Ausnahme. Die Technik, die dieser Infrastruktur zugrunde liegt, muß konfiguriert sein, um einen kontinuierlichen und optimalen Betrieb ("immer richtig" konfiguriert) dieser Infrastruktur beizubehalten.
• Um eine optimale Konfiguration zu erhalten, kann ein Unternehmen wünschen, eine Prüfung der Konfiguration der Infrastruktur desselben durchzuführen. Die Infrastruktur kann z. B. eine Gruppenkonfiguration umfassen, die aus drei Knoten besteht. Im Allgemeinen ist eine Gruppenkonfiguration eine Gruppe von Knoten, die angeordnet ist, um die Ausführung eines Programms zu "sichern" und ersetzen, in dem Fall, daß ein Knoten nicht in der Lage ist, dieses Programm auszuführen, oder wenn der Knoten nicht verfügbar ist. Dieses Unternehmen kann die Prüfung durchführen oder kann üblicherweise ein außenstehendes Firmenunternehmen beauftragen, die Prüfung durchzuführen. Bei diesem Beispiel involviert die Prüfung üblicherweise die folgenden fünf Schritte:
  Ressourcen - Jemanden mit den richtigen Kenntnissen finden, um diese Systemkonfigurationsprüfung durchzuführen.
  Konfiguration - Betrachten einer komplexen Unternehmenskonfiguration, entweder direkt oder durch Sammeln aller relevanten Konfigurationsinformationen, die für die Untersuchung benötigt werden.
  Analyse - Schlußfolgerungen ziehen.
  Berichten - Dokumentieren der Ergebnisse und Präsentieren dieser Informationen einem Unternehmen, das die Prüfung anfordert.
  Aktionsplan - Erzeugen eines Aktionsplans, um den gefundenen Problemen zu begegnen.
• Leider liegen einige Themenpunkte oder Probleme auf dem Weg, die beseitigt werden müssen, um eine erfolgreiche Prüfung durchzuführen.
Ressourcen
• Ein Unternehmen muß das richtige Personal finden. Um eine Systemkonfiguration zu prüfen, benötigt eine Person praktische Erfahrung mit der zugrunde liegenden Technik. Der erfolgreiche Kandidat muß ausreichende technische und berufliche Fähigkeiten zusammen mit praktischer Erfahrung vorweisen. Üblicherweise besitzt keine Einzelperson Fachkenntnisse in allen erforderlichen Bereichen. Zeitliche und finanzielle Einschränkungen begrenzen die Anzahl von Ressourcen bei einer Prüfungsaktivität und begrenzen wiederum den Inhalt der Lieferung (Tiefe, Breite, . . .) und ferner die Qualität. Die Prüfung kann zum Stillstand kommen, wenn mehrere Personen sich entscheiden, den Arbeitsplatz zu wechseln. Ein hohe Fluktuation führt üblicherweise zu einem Wissensverlust, außer ein derartiges Wissen wird dokumentiert. In dem Fall einer Verabschiedung muß ein Unternehmen in Ausbildung investieren, was zeitaufwendig ist.
• Dies ist keine Garantie, daß das Unternehmen schließlich das Wissen und die Fachkenntnisse des Angestellten, der geht, erfaßt. Dieses Wissen ist für das Unternehmen ein Vermögenswert, der für immer verloren ist. Dieses Wissen muß nicht nur erfaßt und bewahrt werden, sondern es muß ferner effektiv verwendet werden. Man muß darauf zugreifen können, und ein automatischer Zugriff ist äußerst wünschenswert.
Konfiguration
• Der nächste Themenpunkt betrifft den Punkt, wie die Konfigurationsinformationen erhalten werden können. In bestimmten Umständen wurden die Informationen vorangehend erhalten. Diese Konfigurationsinformationen sind jedoch wahrscheinlich in einem Format, daß für die Analyse nicht verwendbar ist. Bei Nichtvorhandensein dieser Informationen müssen dieselben wiedergewonnen werden. In dem Fall, daß die Prüfung durch ein außenstehendes Unternehmen durchgeführt wird, sollte eine manuelle Interaktion mit dem System eines Kunden verhindert werden, sogar wenn der Kunde den Zugriff erlaubt. Es besteht ein Risiko, daß die Interaktion ein Problem mit der Plattform des Kunden verursacht. Der Kunde beschuldigt wahrscheinlich das außenstehende Unternehmen für die Problem mit dem System, unabhängig von dem Fehler.
• Heute sind Softwaretools für das Sammeln von Konfigurationsinformationen verfügbar. Wenn ein solches Tool lokal entwickelt wurde, ist die Zuverlässigkeit und die Wartung ein Problem, größtenteils weil derartige Tools unvollständig sind, wenn sie entwickelt werden. Ferner wird die Qualität eines lokalen Tools durch die lokalen Fachkenntnisse einschränkt.
• Nun erfordern die beschriebenen Tools eine Installation auf einem Kundensystem, die das System unverfügbar machen kann oder dasselbe zum Zusammenbruch bringt. Zusätzlich dazu kann der Kunde den Grund dafür fordern, warum er/sie das Tool auf seinen/ihren Systemen installieren soll. Kunden, die eine starre Änderungsverwaltung vor Ort haben, werden die kurzfristige Installation jeglicher Tools nicht erlauben.
Analyse
• Sogar wenn man erfolgreich beim Sammeln der Konfigurationsinformationen ist, bestehen andere Hindernisse. Die Analyse, die bei dem Ort des Kunden durchgeführt wird, erfordert wahrscheinlich mehrere Besuche. Dadurch geht wertvolle Zeit verloren. Zusätzlich sind üblicherweise begrenzt verfügbare Ressourcen vor Ort. Ferner erfordert eine Analyse üblicherweise die Anwendung mehrer Analysatoren zum Identifizieren von Problemen. Dann besteht der Themenpunkt, welche Teile des Knotens überprüft oder analysiert werden müssen, und welche Themenpunkte identifiziert werden sollten. Beide Themenpunkte werden üblicherweise durch eine Einzelperson beantwortet. Auf Grund des begrenzten Wissens dieser Einzelperson sind die System-Überprüfungen und -Themenpunkte, die identifiziert wurden, vielleicht nicht vollständig umfassend. Es ist jedoch wichtig, sich auf eine gut definierte Liste von Artikeln zu verlassen, die überprüft werden, und auf Kriterien der Zufriedenstellung, um eine zuverlässige und stabile Umgebung zu sichern. Es wäre vorteilhaft, Beiträge von mehreren fachmännischen Quellen zu verwenden, doch dies ist kaum jemals durchführbar.
• Da dies eine Gruppenkonfiguration betrifft, ist die Analyse der Konfiguration nicht auf die einzelnen System beschränkt. Bei Gruppenkonfigurationen sind Unterschiede zwischen System- oder Knoten-Konfigurationen (z. B. installierte Software, Speichergröße, Kernkonfiguration, etc.) wichtig. Daher müssen die Knoten in einer Gruppe miteinander verglichen werden. Ohne Tools vor Ort, um dies durchzuführen, wird es zu einer manuellen Anstrengung, gewisse Konfigurationsinformationen zu extrahieren und möglicherweise Scripts zu schreiben, um einen Vergleich durchzuführen und die Ergebnisse auf eine vorzeigbare Art zu liefern. Dies ist ein anstrengender und zeitaufwendiger Prozeß, jedoch eine notwendige Aufgabe.
Berichten
• Wenn die Analyse abgeschlossen ist und eine Liste erzeugt wurde, die Themenpunkte (Probleme) mit der Gruppenkonfiguration identifiziert, bestehen immer noch andere Hindernisse. Die identifizierten Themenpunkte sind nicht auf eine beliebige logische Weise oder gemäß Kundenanforderungen organisiert. Die Informationen sollten ausreichend sein, um eine angemessene Beschreibung zu liefern, die prägnant, professionell und genau ist, und die unterschiedliche Zielgruppen abdeckt (technisch und nichttechnisch).
• Es können falls erwünscht mehr Informationen umfaßt sein. Beschreibungen in den Berichten jedoch können die persönliche Sicht einer Einzelperson wiedergeben, im Gegensatz zur einheitlichen empfohlenen Praxis eines Unternehmens. Dies führt zu Inkonsistenzen zwischen zu liefernden Artikeln, wobei vermischte Nachrichten an Kunden gesendet werden. Es ist ferner wichtig, jeder Information die richtige Beschreibung zuzuordnen. Dies würde offensichtlich erscheinen, wird dies aber weniger, wenn einzelne Informationen für unterschiedliche Systeme gehandhabt werden.
• Nun sollte der vorgelegte Bericht konsistent formatiert sein. Technisches Personal sollte für das Schreiben von Berichten keine Zeit aufwenden müssen, wenn ihre technischen Fähigkeiten auf bessere Art und Weise genutzt werden können. Dies würde daher zusätzliche Ressourcen von Personal erfordern, die im technischen Schreiben ausgebildet sind. Ferner müssen die Berichte die Zielgruppe befriedigen, die die Prüfung anfordert. Die Zielgruppe kann technische und nichttechnisches Management, Verkaufspersonal und viele andere umfassen. Es ist ein System erwünscht, das in der Lage ist, unterschiedliche Berichte zu erzeugen, wobei die Ergebnisse der Analyse der Anfrage eines Prüfers entsprechen.
Aktionsplan
• Üblicherweise muß das Unternehmen, das die Prüfung durchführt, einen Aktionsplan vorbereiten, um die Themenpunkte zu lösen, die bestimmt wurden. Wenn das Unternehmen nicht zielstrebig handelt, kann das Unternehmen das Geschäft verlieren. In vielen Situationen hat das Unternehmen jedoch wenig Hilfe von dem geprüften Unternehmen für die Erzeugung eines Aktionsplans zur Verfügung. Die Vorbereitung des Aktionsplans wird ermöglicht, wenn ein Szenario mit den Schritten verfügbar ist, um einen spezifischen Themenpunkt zu lösen, zusammen mit den Einrichtungen, um zusätzliches Referenzmaterial zu finden.
• Zusammengefaßt verlassen sich Unternehmen in der heutigen Welt immer mehr auf ihre IT-Systeme für zentrale Teile ihres Geschäfts. Dies erzeugt immer weiter steigende Anforderungen nach Zuverlässigkeit, Verfügbarkeit, Skalierbarkeit und Verhalten. Daher werden Unternehmen immer fordernder, da die Konsequenzen gravierend sind, wenn ihre IT-Systeme unter Ausfallzeiten leiden. Ferner steigt die Geschwindigkeit, mit der Dinge durchgeführt werden, und dementsprechend sinkt die Durchlaufzeit zum Konsultieren von Lieferungen.
• Es wäre wünschenswert, ein automatisiertes System zu schaffen, das die oben beschriebenen Nachteile überwindet.
• Es wäre ferner wünschenswert, ein automatisiertes System zu erhalten, das eine komplette Prüfung einer Systemkonfiguration durchführt, die die notwendigen und erwünschten Prüfungsberichte automatisch erzeugt.
• Es ist die Aufgabe der vorliegenden Erfindung, verbesserte Verfahren und Vorrichtungen zum Prüfen von Unternehmenskonfigurationen zu schaffen.
• Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1 oder 11, ein System gemäß Anspruch 18, ein computerimplementiertes Verfahren gemäß Anspruch 12 und eine Rahmenstruktur gemäß Anspruch 22 gelöst.
• Kurz gesagt weist die vorliegende Erfindung bei einem Ausführungsbeispiel ein Verfahren zum Prüfen der Konfiguration eines Unternehmens auf, das folgende Schritte aufweist:
  Sammeln von Informationen, die sich auf die Konfiguration des Unternehmens beziehen; Analysieren der Konfigurationsinformationen basierend auf Experteninformationen; und Bereitstellen eines Ergebnisses der Analyse.
• Bei einem weiteren Ausführungsbeispiel der vorliegenden Erfindung wird ein Verfahren zum Prüfen der Konfigurationen einer Mehrzahl von Feldplattformen oder Knoten in einem Unternehmen geschaffen, wobei das Verfahren folgende Schritte aufweist: Sammeln von Informationen in Bezug auf die Konfigurationen einer Mehrzahl von Feldplattformen oder Knoten; Erzeugen einer Mehrzahl von Analysatoren basierend auf Fachkenntnis, wobei jeder Analysator eine oder mehrere Themenpunkte darstellt, mit einer oder mehreren der Mehrzahl von Feldplattformen oder Knoten; Anwenden der Mehrzahl von Analysatoren auf die Konfigurationsinformationen, um zu bestimmen, ob die Themenpunkte mit der Mehrzahl von Feldplattformen oder Knoten existieren; Speichern der Themenpunkte, die durch die Mehrzahl von Feldplattformen oder Knoten identifiziert werden; Erzeugen einer Mehrzahl von Regeln basierend auf Fachkenntnis, wobei jede Regel einen Themenpunkt innerhalb des Unternehmens darstellt; Anwenden der Mehrzahl von Regeln auf die gespeicherten Themenpunkte, die in Bezug auf die Feldplattformen oder Knoten existieren; und Liefern eines Ergebnisses der Analyse, die Themenpunkte innerhalb des Unternehmens darstellt.
• Bei einem weiteren Ausführungsbeispiel der vorliegenden Erfindung wird ein computerimplementiertes Verfahren zum automatischen Prüfen einer Konfiguration von mindestens einer Quelle innerhalb eines Unternehmens geschaffen, wobei das Verfahren folgende Schritte aufweist: Sammeln variabel formatierter Konfigurationsinformationen von mindestens einer Quelle; analysieren der Konfigurationsinformationen unter Verwendung des Analysators, dessen Entwürfe auf Fachkenntnis basieren, um das Vorhandensein oder das Nichtvorhandensein von einer oder mehreren Themenpunkten zu identifizieren, die der mindestens einen Quelle zugeordnet sind; und Liefern von Informationen als ein Ergebnis der Analyse, die das Vorhandensein oder das Nichtvorhandensein von einer oder mehreren Themenpunkten in einem Standardformat definieren.
• Bei einem wiederum weiteren Ausführungsbeispiel der vorliegenden Erfindung wird ein System zum Prüfen einer Konfiguration einer Mehrzahl von Quellen innerhalb eines Unternehmens geschaffen, wobei die Quellen eine Mehrzahl von Kombinationen aus Hardware, Software und Betriebssystemen umfassen, wobei das System folgende Merkmale aufweist: eine Mehrzahl von Sammlern zum Sammeln von Konfigurationsinformationen von jeder der Mehrzahl von Quellen, wobei die Konfigurationsinformationen eine Mehrzahl von Kombinationen von Datenformaten, Datensyntax und Datenelementstruktur umfassen; eine Komponente zum Analysieren der Konfigurationsinformationen für jede Quelle aus der Mehrzahl von Quellen, um einen oder mehrere Themenpunkte zu identifizieren, die jeder Quelle zugeordnet sind; und eine Komponente zum Standardisieren der Konfigurationsinformationen.
• Bei einem wiederum anderen Ausführungsbeispiel der vorliegenden Erfindung wird eine automatisierte Rahmenstruktur geschaffen, die folgende Merkmale aufweist: eine erste Komponente zum Sammeln von Konfigurationsinformationen, die sich auf eine Mehrzahl von Quellen beziehen; eine zweite Komponente zum Analysieren der Konfigurationsinformationen basierend auf Fachkenntnis, um einen Themenpunkt zu identifizieren, die innerhalb jeder Quelle der Mehrzahl von Quellen zugeordnet ist; und eine dritte Komponente zum Liefern der Ergebnisse der Analyse jeder Quelle.
• Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend bezugnehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:
• Fig. 1 ein Übersichts-Blockdiagramm eines Unternehmens- Analysatorsystems, das periodisch Informationen von den Knoten in einem Unternehmen sammelt, diese Informationen analysiert und die Themenpunkte verwendet, die aus der Analyse resultieren, als eine Basis zum Erzeugen einer Vielzahl von Berichten.
• Fig. 2 ein Hardwareblockdiagramm, das die Knoten in einem Unternehmen darstellt, die mit einem Analysator-Server und einem Berichterzeuger-Server verbunden sind.
• Fig. 3 ein Hardwareblockdiagramm, das die Computer und andere Knoten in einem Unternehmen darstellt, das einen Unterstützungsknoten aufweist.
• Fig. 4 die Organisation einer Sammlerdatenbank.
• Fig. 5 einen Prozeß zum Erzeugen eines Sammlers.
• Fig. 6 einen Prozeß zum Installieren eines Sammlers auf einem Unternehmen.
• Fig. 7 ein Flußdiagramm des Prozesses zum periodischen Ausführen von Sammlern innerhalb eines Unternehmens.
• Fig. 8 ein Softwareblockdiagramm der Elemente der Analyse-Server, zusammen mit gewissen Elementen des Berichterzeuger-Servers und eines HAO-Servers.
• Fig. 9 die Organisation der Verfolgerdatenbank.
• Fig. 10 den Prozeß eines Prüfers, der eine Bewertungsaufgabe zum Analysieren eines Unternehmens und zum Erzeugen von Berichten entwirft.
• Fig. 11 eine Fortsetzung von Fig. 10, die den Prozeß darstellt, den ein Prüfer durchläuft, um die Berichte zu definieren, die erzeugt werden sollen.
• Fig. 12 ein Flußdiagramm, das den Prozeß zum Erzeugen eines neuen Analysators darstellt.
• Fig. 13 eine Fortsetzung von Fig. 12, die den Prozeß zum Erzeugen eines neuen Analysators darstellt.
• Fig. 14 eine Tabelle, die die Benutzerschnittstellentools auflistet, die erwünscht sind, um die Erzeugung des Analysators zu unterstützen.
• Fig. 15 ein Flußdiagramm des allgemeinen Prozesses, der durch den Analysierharnisch durchgeführt wird, wenn dasselbe die Analyse der Knoten in einem Unternehmen durchführt.
• Fig. 16 den Prozeß des Erzeugens einer Berichtschablone.
• Fig. 17 eine Fortsetzung von Fig. 16, die den Prozeß des Erzeugens einer Berichtschablone darstellt.
• Fig. 18 eine Fortsetzung der Fig. 16 und 17, die den Prozeß des Erzeugens einer Berichtschablone darstellen.
• Fig. 19 ein Flußdiagramm, das darstellt, wie Berichte erzeugt werden.
• Fig. 20 eine Fortsetzung von Fig. 19, die darstellt, wie Berichte erzeugt werden.
• Fig. 21 ein Übersichts-Blockdiagramm der Elemente, die in die Ausführung von Analysatoren involviert sind, einschließlich des Analysatorbooters, des Analysatorbeschreibers und des Analysator- Argumentverwalters.
• Fig. 22 ein Flußdiagramm der detaillierten Schritte, die durch die Elemente des Analysatorharnisch (gezeigt in Fig. 21) ausgeführt werden, wenn dasselbe einen Analysator durchführt.
• Fig. 23 eine Fortsetzung von Fig. 22, die die Schritte darstellt, die durch den Analysatorharnisch durchgeführt werden, wenn dasselbe einen Analysator durchführt.
• Fig. 24 eine Fortsetzung der Fig. 22 und 23, die die Schritte darstellt, die durch den Analysatorharnisch ausgeführt werden, wenn denselben ein Analysator durchführt.
• Fig. 25 eine XML-Hierarchie, die verwendet werden kann, um variierende Umfangsbewertungen eines Unternehmens zu erzeugen.
• Fig. 26 einen Prozeß zum Definieren einer Aufgabe in der Umgebung der XML-Hierarchie, die in Fig. 25 gezeigt ist.
BEGRIFFSDEFINITION
• Die nachfolgenden Begriffe, die bei dieser Anmeldung verwendet werden, sollen die jeweiligen Bedeutungen haben, die ihnen nachfolgend zugeschrieben werden, außer anderweitig eindeutig in dieser Anmeldung definiert.
Analysator
• Analysatoren sind Prozesse, die durch Regeln oder Programme definiert sind, die ausgewählte Konfigurationsinformationen analysieren, die durch einen oder mehrere Sammler an einem oder mehreren Knoten angesammelt werden, und die Themenpunkte, die Aufmerksamkeit erfordern können, identifizieren und berichten.
Analysatorharnisch
• Ein Analysatorharnisch ist eine Rahmenstruktur oder ein System, das einen Analysator einkapselt oder einhüllt und dann ausführt, wobei dem Analysator Sammlerdaten geliefert werden, die sich auf einen spezifischen Knoten oder mehrere Knoten eines spezifischen Unternehmens beziehen, jedes Mal wenn ein Analysator eingekapselt, eingehüllt und dann ausgeführt wird.
Prüfung
• Dieser Ausdruck wird üblicherweise für eine formelle Untersuchung oder Verifizierung von Finanzkonten verwendet und bedeutet in diesem Kontext eine sehr gründliche Untersuchung oder Verifizierung. Man kann eine sehr große Abdeckungstiefe und üblicherweise (aber nicht notwendigerweise) eine wesentliche Abdeckungsbreite (d. h. von mehreren Domänen) erwarten. In Anbetracht dieser Details braucht eine Prüfung üblicherweise eine bedeutende Zeitspanne. Ressourcen, die Prüfungen durchführen, sind üblicherweise Experten auf diesem Gebiet mit großer Erfahrung. Abhängig von den Abdeckungsbereichen wird dies durch eine Person oder durch ein Team durchgeführt. Üblicherweise erfordert dies ein Team aus mehreren Speziallisten.
Sammler
• Ein Sammler ist ein Befehl oder eine Reihe von Befehlen, der verursacht, daß Programme an einem oder mehreren Knoten installiert werden, um Konfigurationsinformationen über den Knoten anzusammeln, und der Berichte zurücksendet, die die Konfiguration des Knotens definieren.
Konfiguration
• Jegliche Informationen, die für die statische oder dynamische Konfiguration von einem oder mehreren Knoten (oder Feldcomputern, Hardware, Software, Firmware, Datenbanken, Speichersystemen, etc.) zu einem bestimmten Zeitpunkt spezifisch sind.
Konfigurations-Verfolger
• Ein Tool, das Konfigurationsinformationen von einem oder mehreren Knoten ansammelt, und das Änderungen zwischen Momentaufnahmen der Informationen hervorhebt, die zu verschiedenen Zeiten angesammelt wurden.
Hintergrundroutine (Dämon)
• Ein Unix-Ausdruck, der sich einen spezifischen Programm- oder Agenten-Typ bezieht, der entworfen ist, um im Hintergrund zu arbeiten.
Unternehmen
• Sammlung von Computern, Software und Netzverbindungen, die die Rechenumgebung eines Geschäfts aufweist.
Unternehmensname
• Ein Name, der ein bestimmtes Unternehmen identifiziert, und der als Wiedergewinnungsschlüssel verwendet werden kann, um auf die Konfigurationsinformationen des Unternehmens zuzugreifen.
Feldcomputer oder Feldknoten
• Feld-Computer oder -Knoten sind Computer oder Knoten, die am Ort des Unternehmens installiert sind, und deren Betrieb von einem zentralen Ort aus überwacht wird.
Rahmenstruktur
• Dies ist eine symbolische Struktur, in der Fachkenntnis und Erfahrung derart plaziert ist, daß es automatisch verwendet werden kann, um Unternehmenskonfigurationsinformationen zu analysieren, die durch Sammler angesammelt wurden, um Themenpunkte zu identifizieren, die die Aufmerksamkeit des Managements erfordern können. Genauer gesagt, im Kontext des bevorzugten Ausführungsbeispiels, werden Expertensystemregeln, genannt Analysatoren, in eine Verdrahtung oder in eine Rahmenstruktur plaziert und mit Konfigurationsinformationen von den Unternehmensknoten beliefert und daher aktiviert, um jegliche Themenpunkte zu berichten, die innerhalb des Unternehmens vielleicht entstanden sind.
Hochverfügbarkeitsobservatorium
• ("HAO" = High Availability Observatory). Bei dem bevorzugten Ausführungsbeispiel der Erfindung ist das Hochverfügbarkeitsobservatorium eine Software-Entität, die auf einem Unterstützungsknoten innerhalb eines Unternehmens installiert ist, die periodisch die Ausführung von Sammlern auf den Unternehmensknoten verursacht, die Berichte erfaßt, die die Sammler erzeugen, und diese Berichte für eine spätere Verwendung und Analyse zurück zu einer zentralisierten Verfolger-Datenbank überträgt. Es wird darauf hingewiesen, daß das HAO nur einer von mehreren möglichen Wegen ist, auf die Konfigurationsinformationen gesammelt und gemäß den Lehren der vorliegenden Erfindung analysiert werden können.
Themenpunkt
• Ein Themenpunkt (issue) ist jeglicher Gegenstand, der vielleicht untersucht oder an die Verwaltung eines Unternehmens berichtet werden muß. Ein Analysator führt auf Konfigurationsdaten hin Tests durch, die von den Knoten eines Unternehmens durch Sammler angesammelt wurden. Diese Tests bestimmen, ob irgendwelche Themenpunkte vorhanden sind, auf die das Management aufmerksam gemacht werden muß.
Themenpunkt-Datenbank
• Eine Themenpunkt-Datenbank ist eine Datenbank, die Themenpunktinformationen enthält, die durch Analysator erzeugt werden, wenn dieselben Konfigurationsinformationen verarbeiten, die durch Sammler erzeugt werden, die auf den Knoten eines Unternehmens arbeiten.
Verwaltetes Element
• Ein verwaltetes Element ist eine oder mehrere physische Vorrichtungen (CPU, Knoten, Computer, etc.) oder logische Vorrichtungen (Programm, Volumen, gekettetes Programm, Prozeß, etc.), die überwacht und/oder verwaltet werden. Jeder Analysator arbeitet ansprechend auf eine bestimmte Klasse von verwalteten Elementen, die ein einzelner Knoten sein können. Ein Satz von Analysatoren kann zugeordnet sein, um alle Bauglieder eines verwalteten Elements eines Unternehmens zu analysieren.
Knoten
• Ein Knoten ist eine bestimmte Vorrichtung in einem Unternehmen, wie z. B. ein Server, eine Arbeitsstation, ein Drucker, ein Router, ein Schalter oder ein Hub. Ein Multiprozessor kann entweder als einzelner Knoten oder als mehrere Knoten konfiguriert sein.
Verfolger-Datenbank
• Eine Verfolger-Datenbank ist eine Datenbank, die Konfigurationsinformationen enthält, die von einem oder mehreren Knoten von einem oder mehreren Unternehmen angesammelt wurden.
ÜBERBLICK ÜBER DAS SYSTEM
• Bezugnehmend auf Fig. 1 ist ein Übersichts-Blockdiagramm eines automatisierten Verfahrens 100 gezeigt, zum wiederholten Analysieren der Konfiguration eines Unternehmens. Das Verfahren 100 kann im allgemeinen in drei Stufen aufgeteilt werden: Sammlung, Analyse und Berichten, wie durch die gestrichelten Linien in Fig. 1 gezeigt ist.
• Bei Schritt 102 des Verfahrens werden Unternehmenskonfigurationsinformationen von Feldknoten gesammelt. Der Sammlungsschritt verwendet einen Satz von Sammlern 104, um die gewünschten Konfigurationsinformationen anzusammeln. Die Sammler 104 sind jeweils Befehle oder Programme, die auf einem Unterstützungsknoten in dem Unternehmen gespeichert sind. Die Sammler 104 werden in periodischen Intervallen auf jedem Knoten des Unternehmens abgespielt. Die Sammler 104 sammeln gewünschte Konfigurationsinformationen an und speichern dieselben als Dateien in der Verfolger-Datenbank 106. Genauer gesagt besteht für jeden Knoten eine Konfigurationsinformationendatei, die auf der Verfolger-Datenbank 106 gespeichert ist, die jedem einzelnen Sammler zugeordnet ist, der Konfigurationsinformationen erzeugt.
• Bei Schritt 108 werden Konfigurationsinformationen durch einen Analysatorharnisch 806 (Fig. 2) analysiert, um Themenpunkte innerhalb der Feldknoten zu identifizieren. Als Teil dieses Prozesses werden die Analysatoren 110verwendet, um bestimmte Themenpunkte zu untersuchen, die den Feldknoten zugeordnet sind. Die Analysatoren 110 werden von Experten entwickelt oder geschrieben, um einen Themenpunkt oder mehrere Themenpunkte zu identifizieren. Die Experten besitzen das Wissen und die Informationen, die in geschriebener Form erfaßt werden, wenn Analysatoren spezifische Themenpunkte bearbeiten. Die Analysatoren werden dann in einer Analysatordatenbank 804 (Fig. 2) für eine spätere Verwendung durch den Analysatorharnisch 806 gespeichert.
• Ein wichtiger Aspekt der vorliegenden Erfindung ist, daß die durch diese Anordnung erzeugten Berichte sich auf spezifische Themenpunkte und nicht auf den Zustand eines Unternehmens konzentrieren. Dementsprechend müssen die Unterstützungsingenieure nicht die gesamten großen Mengen von Konfigurationsinformationen durchforsten, um Probleme zu isolieren. Das Liefern von Unterstützung für das Unternehmen wird somit von einer Konfigurationsansammlung und manueller Analyse in das Durchführen eines spezifizierten Satzes von Analysatoren und das Ermöglichen der Rahmenstruktur- "Experten" umgewandelt, um das Problem zu diagnostizieren und die zugehörigen Themenpunkte zu identifizieren.
• Wie unten detaillierter beschrieben wird, führt der Analysatorharnisch 806 den gewünschten Analysator 110 mit den Konfigurationsinformationen aus, die in der Verfolger- Datenbank 106 gespeichert sind und erzeugt einen Bericht 2126 (Fig. 21) im XML-Format. Der Bericht 2126 identifiziert Themenpunkte betreffend die Feldknoten. Dieser Themenpunkteidentifizierungsbericht 2126 wird dann als eine Datei in einer Themenpunkt-Datenbank 112 gespeichert. Wenn ein Themenpunkt nicht im Hinblick auf einen Knoten entstanden ist, wird der Themenpunkt von dem Bericht 2126 entfernt.
• Auf dieser Stufe kann der Bericht 2126, der durch Schritt 108 erzeugt wurde, verwendet werden, um einen Gesamtbericht zusammen mit Textbeschreibungen der Themenpunkte zu erzeugen, wie durch einen Prüfer gewünscht wird. Der XML-Bericht 2126 von dem Analysatorharnisch 806 wird an einen Berichterzeuger 206 (Fig. 2) gesendet. Der Berichterzeuger 206 kann die Bericht-Schablonen und -Regeln-Datenbank 204 verwenden, um Berichte 208 zu erzeugen (Fig. 2), die bestimmten Themenpunkten für jeden Feldknoten begegnen. Diese Berichte 208 identifizieren die verwendeten Analysatoren 110, den Knoten von dem die Sammlerinformationen erhalten werden, optional die aktuelle Ausgabe des Sammlers 104 und der identifizierte Themenpunkt.
• Nun können die in der Themenpunkt-Datenbank 112 gespeicherten Themenpunkte auf eine andere Weise verwendet werden, um das Gesamtverhalten des Unternehmens zu überprüfen. Zu diesem Zweck werden bei Schritt 114 die Themenpunkte unter Verwendung von Regeln analysiert, die durch die Experten geschrieben wurden, und ein Bericht wird erzeugt, wie vom Prüfer gewünscht. Allgemein ausgedrückt werden die Berichte aus Schablonen erzeugt, die in der Bericht-Schablonen und -Regeln-Datenbank 204 gespeichert sind. Die Berichte können bei Schritt 118 dem Unternehmensmanagement, dem technischen Management, dem Feldingenieursteam und einem Arbeitsflußsystem oder Systemdienst (Selbstheilungstechnologie) vorgelegt werden. Diese Selbstheilungstechnologie hilft der Computerindustrie, das Ziel des Bereitstellens von Servern und anderen Knoten zu erreichen, die sich selbst automatisch reparieren und dadurch im Dienst bleiben, ohne über viele Jahre hinweg einen menschlichen Eingriff zu erfordern. Durch automatisches Identifizieren von Themenpunkten, die ein mögliches, zukünftiges Versagen von Knoten in Unternehmen andeuten können, und durch Erzeugen von Berichten des Typs, der die Operationen von anderen Knoten steuern kann, die Software herunterladen können, um Datenträgerlaufwerke neu einzurichten und andere Wartungsdienste automatisch durchzuführen, bewegt die vorliegende Erfindung die Computerindustrie um einen gigantischen Schritt näher an das Bereitstellen von Servern und anderen Knoten, die sich automatisch selbst warten und reparieren mit einem nur geringen, menschlichen Eingriff.
• Bezugnehmend auf Fig. 2 ist ein Hardwareblockdiagramm zum Implementieren des Verfahrens von Fig. 1 gezeigt. Ein Unternehmen 300 ist vor Ort bei einem Kunden positioniert und umfaßt einen Unterstützungsknoten 308, der durch den Hersteller der Computer bei dem Kunden vor Ort betrieben wird. Es wird darauf hingewiesen, daß der Unterstützungsknoten 308 die herkömmlichen Komponenten eines Computersystems umfaßt, einschließlich einer CPU, einer Anzeige oder einer anderen I/O-Vorrichtung, eines Netzwerks oder einer Kommunikationsschnittstelle, eines RAM oder ROM oder anderer Speicher, sowie stabile Speichervorrichtungen, wie z. B. Datenträger- oder CD-ROM-Laufwerke. Andere beschriebene Server oder Knoten können ferner die gleichen, herkömmlichen Komponenten umfassen.
• Software, die als Hochverfügbarkeitsobservatorium ("HAO"- High Availability Observatory) von Hewlett-Packard, Incorparated erhältlich ist, ist auf dem Unterstützungsknoten 308 gespeichert, und sie verwaltet die Sammler 104, die Konfigurationsinformationen ansammeln. Bei dem Unternehmen 300 ist der Unterstützungsknoten 308 mit den Knoten 302 und 304 durch ein Netzwerk verbunden, das die Sammler 104 aktiviert, um Konfigurationsinformationen anzusammeln. Es wird darauf hingewiesen, daß das Unternehmen 300 eine Brandmauer 324 aufweist, um als Barriere zu wirken, um einen unberechtigten Zugriff auf das Unternehmen 300 zu verhindern, und um als zentraler Punkt des Vorhandenseins für Wartungs- und E-Mail-Konnektivität zu wirken. Es wird darauf hingewiesen, daß die Verwendung eines Unterstützungsknotens auf diese Weise eine von vielen Möglichkeiten ist, auf die Konfigurationsinformationen gesammelt und für eine Analyse vorgelegt werden können.
• Fig. 2 stellt ferner die Komponenten dar, die an einer zentralen Stelle positioniert sind. Die zentrale Stelle umfaßt einen Analysatorserver 800, der entfernt von dem Unternehmen 300 positioniert ist. Der Analysatorserver 800 ist mit dem Unternehmen 300 über eine ISDN-Leitung oder eine andere Form eines weiten Netzwerks verbunden. Ein HAO- Server 105, ein Berichterzeuger-Server 202 und ein Stammserver 210 sind ferner ein Teil der zentralen Stelle. Der HAO-Server 105 ist mit dem Unterstützungsknoten 308 durch die ISDN-Leitung verbunden. Dateien von Konfigurationsinformationen, die durch die Sammler 104 erzeugt werden, werden in einer Verfolgerdatenbank 106 gespeichert. Diese Dateien werden aus der Verfolgerdatenbank 106 durch den Analysatorserver 800 wiedergewonnen, wie nachfolgend beschrieben wird.
• Der Analysatorserver 800 umfaßt eine Analysatordatenbank 804, die die Analysatoren 110 und einen Analysatorharnisch 806 zum Einhüllen der Analysatoren 110 speichert, die aus der Analysatordatenbank 804 wiedergewonnen werden, mit den Dateien von Konfigurationsinformationen, die aus der Verfolgerdatenbank 106 wiedergewonnen werden. Der Analysatorharnisch 806 erzeugt eine Themenpunkteberichtdatei im XML- Format, die in die Themenpunkt-Datenbank 112 plaziert wird. Wie nachfolgend ausführlicher erörtert wird, kann dieser Bericht verwendet werden, um einen Gesamtthemenpunktbericht zu erzeugen, wie oben im Hinblick auf Fig. 1 beschrieben wurde.
• Der Stammserver 210 umfaßt eine Stammdatenbank 212. Die Stammdatenbank 212 speichert Konfigurationsinformationsdateien, die während der bekannten, manuellen Sammlungen oder anderen Einrichtungen erhalten wurden. Die Stammdatenbank 212 kann mit dem Analysatorharnisch 806 verbunden sein. In dem Fall, daß die HAO-Sammler nicht verfügbar sind oder nicht vorhanden sind, um automatisch und kontinuierlich Konfigurationsinformationsdateien zu erzeugen, können die Konfigurationsinformationsdateien aus der Stammdatenbank 212 wiedergewonnen werden. Diese Informationen sind jedoch nur so aktuell, wie die letzte, manuelle Sammlung. Es können jedoch andere, automatisierte Techniken verwendet werden, um Knotenkonfigurationsinformationen in die Stammdatenbank 212 zu plazieren.
• Es wird darauf hingewiesen, daß das HAO nur eine Art ist, auf die Konfigurationsinformationen von einem Unternehmen angesammelt werden können. Dies kann und sollte für jeden Knoten in jedem Unternehmen durchgeführt werden, so daß die Vorteile des Sammelns und Analysierens von Konfigurationsinformationen universell zum Tragen kommen.
• Der Berichterzeugerserver 202 ist ferner ein Teil der zentralen Stelle. Der Berichterzeugerserver 202 ist mit dem Analysatorserver 800 durch die (XML) Themenpunkt-Datenbank 112 verbunden. Der Berichterzeugerserver 202 umfaßt einen Berichterzeuger 206 zum Empfangen der XML- Themenpunktberichte von der Datenbank 112. Wie oben bezugnehmend auf Fig. 1 erörtert wurde, kann der Berichterzeuger 206 einen Gesamtbericht betreffend die identifizierten Themenpunkte erzeugen, der detaillierte Informationen über jeden Themenpunkt enthält.
• Nun werden die Themenpunktberichte in einer Themenpunkt- Datenbank 212 gespeichert, wie beschrieben wurde. Eine Bericht-Schablonen- und -Regeln-Datenbank 204 ist ein Teil des Berichterzeugerservers 202. Der Server 202 speichert verschiedene Bericht-Schablonen und -Regeln, die durch Experten auf dem Gebiet entwickelt wurden. Dies kann Feldpersonal oder Produktentwicklungspersonal sein. Die Anwendung dieser Regeln hilft, das Gesamtverhalten des Unternehmens 300 zu bestimmen. Auf die Anforderung eines Prüfers hin erzeugt der Berichterzeuger 206 (1) die Regeln von der Bericht-Schablonen und -Regeln-Datenbank 204 und (2) die Themenpunkte, die in der Themenpunkt-Datenbank 112 gespeichert sind, und erzeugt dann einen Bericht 208 unter Verwendung der Schablonen aus der Bericht-Schablonen- und -Regeln- Datenbank 204. Der Bericht kann in jeglichem gewünschtem Format sein, wie z. B. Microsoft Word, Excel, Powerpoint oder HTML, oder in einem anderen speziellen Format, das für die Lieferung an bestimmte andere Computer oder Knoten zur Verwendung bei der automatischen Steuerung entwickelt ist. Der Bericht kann alle Themenpunkte mit dem Unternehmen 300 identifizieren, um dem Prüfer zu ermöglichen, das Gesamtverhalten des Unternehmens 300 zu bestimmen.
• Bezugnehmend auf Fig. 3 wird nun das oben beschriebene Gruppenkonfigurationsbeispiel zusammen mit einer Analyse der Unternehmenskonfiguration detaillierter erörtert. Als Teil des Unternehmens 300 sind die drei Knoten 302, 304, 306 und verschiedene Personalcomputer 314-322 durch ein Netzwerk 312 verbunden. Die Knoten 302, 304, 306 umfassen Dienstprogramme 303, 305, 307, um die Knoten jeweils richtig einzurichten und zu konfigurieren. Das Unternehmen 300 umfaßt ferner einen Dateiserver 326 mit einem Volumen 328 zum Speichern von Programmen. Der Dateiserver 326 ist mit den Knoten 302, 304, 306 verbunden, um diesen Knoten zu ermöglichen, von dem Volumen 328 auf dem Dateiserver 326 auf die Programme zuzugreifen. Wie oben erläutert wurde ist der HAO-Unterstützungsknoten 308 ferner ein Teil des Unternehmens 300, und derselbe umfaßt eine Sammlerdatenbank 310. Der HAO-Unterstützungsknoten 308 ist mit dem HAO-Server 105 über eine ISDN-Leitung oder eine andere Verbindungseinrichtung mit dem HAO-Server 105 an der zentralen Stelle verbunden. Eine Brandmauer 324 ist aus dem oben beschriebenen Grund auf dem Unternehmen 300 installiert.
• Die drei Knoten 302, 304, 306 sind in einer Gruppenkonfiguration angeordnet. Bei dieser Konfiguration sind die Knoten jeweils als Sicherung zueinander konfiguriert, um sicher zu stellen, daß ausführbare Programme auf einem Sicherungsknoten betrieben werden können, wenn der Knoten versagt, der zugewiesen ist, um ein Programm abzuspielen. Um die Gruppenkonfiguration richtig zu konfigurieren müssen die Dienstprogramme jedes Knotens eingerichtet sein, um sicher zu stellen, daß der Knoten das Programm auf dem Volumen 328 erkennt oder "sieht". Anders ausgedrückt muß das Volumen 328 des Dateiservers 326 an jeden der Knoten 302, 304, 306 "angebracht" werden, um jedem derselben zu ermöglichen, ein Programm abzuspielen oder auf ein Programm an dem Volumen 328 zuzugreifen. Wenn ein PC 314 z. B. ein Programm durch das Netzwerk 312 verwendet, das üblicherweise auf dem Knoten 302 abgespielt wird, muß das Volumen 328 an dem Knoten 304 angebracht sein, um dieses Programm abzuspielen, in dem Fall daß der Knoten 302 versagt oder anderweitig nicht in der Lage ist, das Programm auszuführen. Die Gruppenkonfiguration wird unter Verwendung eines Programms von Hewlett- Packard, Incorporated realisiert, das als MC/ServiceGuard bekannt ist. Das Programm MC/ServiceGuard erzeugt eine Gruppenkonfiguration, die sicherstellt, daß dieser Typ von Sicherung auftritt.
• Jetzt, bei diesem Beispiel, ist es erwünscht, die Konfigurationsinformationen der Gruppenanordnung zu analysieren. Zu diesem Zweck werden die Sammler 104 von der Sammler- Datenbank 310 an dem HAO-Unterstützungsknoten 308 zu den Knoten 302, 304, 306 gesendet, um Konfigurationsinformationen anzusammeln. Diese Informationen werden dann in Dateiform zurückgeschickt und zu dem zentralen HAO-Server 105 (Fig. 2) gesendet, um als Dateien auf der Verfolger- Datenbank 106 gespeichert zu werden. Die Verfolger- Datenbank 106 identifiziert den Knoten, von dem die Informationen angesammelt wurden, und die Dateien enthalten Fakten betreffend das, was gesammelt wurde, wie z. B. Speicherungs- oder Speicher-Kapazität, etc. Auf die Anforderung eines Prüfers hin gewinnt der Analysatorharnisch 806 (des Analysator-Servers 800) die gewünschten Konfigurationsinformationsdateien und die gewünschten Analysatoren 110 von der Analysator-Datenbank 804 wieder und verpackt dieselben zusammen, wobei eine Rahmenstruktur gebildet wird, die Themenpunktberichte 2126 im XML-Format erzeugen kann. Jeder Themenpunktbericht 2126 zeigt üblicherweise an, daß ein bestimmtes Problem innerhalb eines bestimmten Knotens besteht. Der Bericht 2126 kann z. B. berichten, daß der Knoten 304 das Volumen 328 auf dem Dateiserver 326 nicht erkennt, da derselbe dieses Volumen 328 nicht angebracht hat. Wenn der Knoten 304 das Volumen 328 nicht erkennt oder "sieht", kann der Knoten 304 in dem Fall, daß der Knoten 302 versagt kein Programm abspielen.
• Ein anderer, exemplarischer Bericht 2126, der nachfolgend erörtert wird, könnte anzeigen, daß die Speicherungs- oder Speicher-Kapazität des Volumens 328, das an dem Knoten 304 angebracht ist, weniger als 5% von dessen Gesamtkapazität beträgt. Diese Kapazitätsebene ist vielleicht nicht ausreichend, um ein erwartetes Wachstum in der Anzahl oder Größe der Dateien zu liefern, die auf diesem Volumen gespeichert sind.
DETAILLIERTE ERÖRTERUNG VON SYSTEMELEMENTEN
• Bezugnehmend wiederum auf Fig. 1 sind die Sammler 104 Befehle oder Sätze von Befehlen, die auf jedem der Knoten eines Unternehmens laufen können, die die Konfigurationen dieser Knoten testen, sowohl statisch als auch dynamisch, und Sammlerberichte erzeugen, die ihre Ergebnisse berichten. Bei Schritt 102 werden die Berichte, die durch diese Sammler erzeugt werden, in der Form von Dateien gesammelt und an einen zentralisierte Verfolger-Datenbank 106 übertragen, wo dieselben gespeichert werden. Auf diese Weise können viele Typen von Sammlern verwendet werden. Eine Familie von Sammlern 104, die an einer bestimmten Unternehmensstelle abgespielt werden, werden durch die Dienstingenieure an dieser Stelle definiert und können die gleichen Programme sein, die die Dienstingenieure abspielen, wenn sie die Stelle besuchen und manuell Tests durchführen, um etwas über die Systemkonfiguration herauszufinden.
• An der zentralen Stelle lesen und analysieren die Analysatoren 110 die Sammlerinformationen, die in der Verfolger- Datenbank 106 enthalten sind. Jeder Analysator wird durch einen Experten im System-Testen und -Beibehalten erzeugt, um die Informationen zu bewerten, die durch einen oder mehrere Sammler erzeugt werden, und um nach einem oder mehreren spezifischen, potentiellen Problemen zu suchen, die vorhanden sein können. Diese Probleme werden "Themenpunkte" genannt. Als ein einfaches Beispiel, das durch den Rest dieser Beschreibung und in den Anhängen verwendet wird, könnte ein Themenpunkt, der für die Verwaltung eines Unternehmens besorgniserregend sein könnte, die Tatsache sein, daß eines oder mehrere Volumen, die an einem oder mehreren Knoten angebracht sind, bis auf fünf Prozent ihrer maximalen Kapazität gefüllt sind, und in Gefahr sind, plötzlich keinen Raum mehr zu haben, um zusätzliche Dateien zu speichern. Unterschiedliche Analysatoren testen unterschiedliche Zustände und spezialisieren sich auf unterschiedliche Themenpunkte. Bei Schritt 108 werden die Analysatoren aufgerufen, um die Konfigurationsinformationen in der Verfolger-Datenbank 106 zu analysieren und dadurch Themenpunktinformationen zu erzeugen, die in einer Themenpunkt-Datenbank 112 gespeichert werden.
• Zusätzlich zu den Sammlern 104, die die definieren, welche Tests auf den einzelnen Knoten eines Unternehmens abgespielt werden, und zusätzlich zu den Analysatoren 110, die die Konfigurationsinformationen durchsuchen, die durch die Sammler 104 angesammelt wurden, um nach Themenpunkten zu suchen, auf die das Management aufmerksam gemacht werden muß, betrachtet die vorliegende Erfindung die Verwendung zusätzlicher Regel- und Bericht-Schablonen 116. Diese aktivieren bei Schritt 114 das Durchführen einer weiteren Analyse der Themenpunktinformationen unter Verwendung von Regeln, die von Experten geschrieben wurden; und die Erzeugung einer Vielzahl nützlicher Berichte, die auf unterschiedliche Zielgruppen gerichtet sind.
• Wie bei Schritt 118 angezeigt ist, könnte einer dieser Berichte ein zusammenfassender Bericht sein, der in Laiensprache geschrieben ist, der an das nichttechnische Management eines Unternehmens gerichtet ist, um es auf kritische Probleme und Trends hinzuweisen. Dieser Bericht kann allgemeine Zustände anzeigen, die existieren, und er kann Gründe vorschlagen, warum dieses Management über diese Zustände beunruhigt sein sollte, durch die Verwendung einfacher Beispiele und Erklärungen. Andere mögliche Berichte wären Berichte für das technische Management, die relativ detailliert sein könnten, und die in technischen Ausdrücken genau anzeigen, welche Probleme existieren und welche Lösungen berücksichtigt werden könnten. Ein separater Satz von Berichten könnte für das Feldingenieurteam erzeugt werden, der den Status des Unternehmens dokumentiert und Punkte anzeigt, die überwacht werden müssen, und möglicherweise Feldkorrekturen vorschlägt.
• Eine Themenpunktebeschreibungsdatenbank 117 kann bereitgestellt sein, die die Berichterzeugungssoftware mit hochdetaillierten Beschreibungen jedes Themenpunkts liefern kann, die entstehen könnte, einschließlich Beispielen und ferner Erklärungen darüber, warum diese Themenpunkte für das Management bedenklich sind, geschrieben in einer nichttechnischen Sprache, die von nichttechnischen Managern verstanden werden kann. Die Themenpunktbeschreibungen in der Datenbank 117 ergänzen somit die sehr kurzen Themenpunktbeschreibungen, die aus der Analyse resultieren, und die in der Themenpunkt-Datenbank 112 erscheinen.
• Zusätzlich dazu, daß die Berichte auf dem Auftreten von Themenpunkt-Informationen in der Datenbank 112 basieren, können dieselben direkt aus der zugrunde liegenden Verfolger-Datenbank erzeugt werden, derart, daß die Berichte den Status des Unternehmens sowie das Auftreten von Themenpunkten von Interesse für die Verwaltung anzeigen können. Zusätzlich dazu können Statusinformationen aus der Verfolger- Datenbank 106 verwendet werden, um Berichte zu ergänzen und zu vervielfältigen, die anderweitig auf dem Auftreten von Themenpunkten basieren.
• Wenn Arbeitsaufträge für die Feldingenieure durch Computer oder andere Knoten in einem Arbeitsflußsystem erzeugt werden, kann eine maschinenlesbare Ausgabe des Berichterzeugers direkt zu dem Arbeitsflußsystem gesendet werden, um dasselbe zu veranlassen, Arbeitsaufträge zu erzeugen, die verursachen, daß Dienstpersonal sofort zu der Stelle gesendet wird, um eine zeitkritische Wartung auszuführen. Berichte fehlerhafter Datenträgerlaufwerke in Datenträgerarrays können z. B. automatisch in Arbeitsaufträge umgewandelt werden, die ein Reparaturteam planen, um die Stelle zu besuchen und die Laufwerke auszutauschen, bevor ein auftragskritisches Unternehmen durch weitere Fehler abgeschaltet wird. Wenn automatisierte Tools oder "Heiler-Systeme" zum Durchführen von Korrekturen an den Knoten in dem Feld existieren, dann können einige Berichte erzeugt werden, die zu Befehlen für das Heiler-System werden, die eine sofortige Korrektur von gewissen Problemen durch eine automatisierte Einrichtung verursachen, um eine kontinuierliche Operation der Server sicherzustellen, die auftragskritisch für das Unternehmen sind. Fehlerhafte Dateien können z. B. automatisch heruntergeladen und neu installiert werden und nichtstartbare Systeme können repariert werden.
• Technische Berichte können Aktionspläne liefern, die genau erklären, wie einem Problem begegnet oder eine Maschine repariert werden kann. Durch eine Computerverbindung kann ein elektronischer Bericht die automatische Bestellung von Teilen und die Planung, daß ein Techniker die Stelle besucht, um die Teile zu installieren, auslösen. Es ist von hier nur noch ein kleiner Schritt, um eine automatische Reparatur und Korrektur von Defekten zu liefern, derart, daß der Knoten im Wesentlichen selbstheilend wird.
• Fig. 2 stellt ein Hardwareübersichtsdiagramm von sowohl einem Unternehmen 300, das an einer oder mehreren Geschäftsstellen positioniert ist als auch eines Analysator-Servers 800 und eines Berichterzeuger-Servers 202 dar, die üblicherweise an einem zentralen Ort positioniert sind, die aber auch an einem Unternehmensort positioniert sein können.
• Bei Fig. 3 existieren die Knoten 302 und 304 und möglicherweise viele andere Knoten an dem Unternehmensort 300. Diese Knoten wären üblicherweise Server, aber sie können Router, Drucker und andere Rechenvorrichtungen sein, die überwacht werden müssen. An der Unternehmensstelle 300 ist ferner ein Unterstützungsknoten 308 mit den anderen Knoten 302 und 304 vernetzt. Der Unterstützungsknoten 308 umfaßt Tools (das HAO-System), die es den Sammlern 104 ermöglichen, periodisch auf den Knoten 302 und 304 und anderen Unternehmensknoten abgespielt zu werden, wodurch Informationen erzeugt werden, die die statische und dynamische Konfiguration der Knoten 302 und 304 und anderer Knoten definieren. Das Unterstützungsknotenprogramm 402 (Fig. 4) erfaßt die Berichte, die durch die Sammler 104 erzeugt werden, und überträgt dieselben durch die Brandmauer 324 und über eine bestimmte Form eines weiten Netzwerk zu der Verfolger-Datenbank 106 innerhalb eine HAO-Servers 105, der üblicherweise an einem zentralen Ort positioniert ist. Dementsprechend enthält die Verfolger-Datenbank 106 eine aktuelle Reihe von Sammlerberichten, die die Konfiguration der Knoten 302 und 304 innerhalb des Unternehmens definieren. Diese Konfigurationsinformationen sind für das Dienstpersonal verfügbar, zum Verfolgen und Studieren, wenn sie versuchen zu entscheiden, welche Typen von Diensten gebraucht werden, um Operationen des Unternehmens 300 zu unterstützen.
• Einige Unternehmen 300 sind vielleicht nicht mit Unterstützungsknoten und Sammlern 104 oder etwas gleichwertigem ausgestattet, die ein HAO-Programm 402 aufweisen. Einige oder alle der Konfigurationsinformationen für ein derartiges Unternehmen 300 können auf einer Stammdatenbank 212 (Fig. 2) innerhalb eines Stammservers 210 beibehalten werden. Diese Informationen können ferner verwendet werden, um eine Analyse eines Unternehmens zu unterstützen.
• An dem zentralen Ort enthält der Analysator-Server 800 eine Analysator-Datenbank 804, die Analysatoren 110 enthält. Diese sind Regeln oder Programme, die Tests implementieren, die durch technische Experten definiert werden. Der Analysator-Server 800 enthält ferner eine Analysator-Verdrahtung 806, die in der Lage ist, individuelle Analysatoren 110 oder Regeln zusammen mit Konfigurationsinformationen zu verdrahten, die von den spezifischen Knoten 302 und 304 angesammelt werden. Diese Informationen werden aus der Verfolger-Datenbank 106 oder der Stammdatenbank 212 wiedergewonnen. Die Analysatoren 110 analysieren diese Informationen und bestimmen dadurch, ob jegliche Themenpunkte vorhanden sind, die adressiert werden müssen. Die Analysator- Verdrahtung 806 kann einen Themenpunktbericht empfangen, jedes Mal wenn ein Analysator 110 abgespielt wird, wenn jegliche Bedingungen vorhanden sind, die Aufmerksamkeit benötigen. Die Analysator-Verdrahtung 806 fügt diesen Themenpunktberichten Informationen hinzu, die die bestimmten Knoten 302 und 304 und die Themenpunkt- oder die Fehler- Meldung identifizieren, die dem Analysator 110 zugeordnet ist, und überträgt die Themenpunktberichte als XML-Berichte 2126 hinaus. Diese Berichte sind sowohl vom Menschen als auch Maschinenlesbar. Sie listen alle Themenpunkte auf, die die Aufmerksamkeit des Managements benötigen können. Diese werden in einer (XML)-Themenpunkt-Datenbank 112 gespeichert.
• Der XML-Themenpunktbericht wird zu einem Berichterzeuger 206 innerhalb eines Berichterzeugerservers 202 weitergeleitet. Der Berichterzeuger 202 umfaßt eine Bericht-Schablonen und -Regeln-Datenbank 204, die die Erzeugung einer breiten Vielzahl unterschiedlicher Berichte für unterschiedliche Zielgruppen steuert, wie oben erklärt wurde. Einige Berichte können z. B. einfach jeden der Themenpunkte in einem schöneren Format erneut darstellen und nach einer bestimmten Reihenfolge sortiert, für eine Präsentation für ein technisches Team, das ein detailliertes Verständnis für alle Themenpunkte erhalten muß, die entstanden sind. Andere Schablonen können unter der Steuerung ausgearbeiteter Regeln angeordnet werden, die die Informationen, die innerhalb des XML-Themenpunktberichts enthalten sind, zuerst scannen und analysieren, dieselben möglicherweise mit vorangehenden, ähnlichen Berichten vergleichen, die zu früheren Anlässen erzeugt wurden, um Entwicklungen zu erkennen und verschiedene Zustände, die Aufmerksamkeit benötigen, wodurch dieselben als ein Konfigurations-Verfolger fungieren. Diese Berichte können Erklärungen auf hoher Ebene über den Zustand der Unternehmenscomputer erzeugen und solche, die von Laien gelesen und verstanden werden können, einschließlich dem Unternehmensmanagement. Tendenzen bei den Informationen, die in dem detaillierten Themenpunktbericht nicht offensichtlich sind, können auf diese Weise ferner erkannt und ans Licht gebracht werden. Dementsprechend kann eine breite Vielzahl von technischen und nichttechnischen Berichten 208 in einer breiten Vielzahl von unterschiedlichen Formaten und Detailebenen erzeugt werden und an das Management und das technische Personal sowie an automatisierte Systeme weitergeleitet werden, die die Planung der Wartung automatisieren oder sogar die tatsächliche Reparatur der Knoten in dem Feld auslösen können.
SAMMLER-SAMMELN VON KONFIGURATIONSINFORMATIONEN
• Der nächste Teil dieser detaillierten Beschreibung spezialisiert sich auf die Fig. 3 bis 7, die erklären, wie die Sammler erzeugt und dann verwendet werden, um Konfigurationsinformationen zu sammeln und diese Informationen in die Verfolger-Datenbank 106 einzugeben.
• Fig. 3 stellt eine detaillierte Beschreibung eines Unternehmens 300 dar. Das Unternehmen 300 umfaßt 3 Server 302, 304 und 306, die in Fig. 3 als "Knoten" identifiziert sind. Darstellend für die vielen möglichen Server, Router, Drucker, Schalter und anderen akustischen Vorrichtungen, die innerhalb eines Unternehmens umfaßt sind, sind die Knoten durch ein Netzwerk 312 miteinander verbunden, das ferner eine große Anzahl von Arbeitsstationen oder PCs 314, 316, 318, 320 und 322 verbindet. Diese Arbeitsstationen oder PCs qualifizieren sich ferner als Knoten und können ebenfalls durch die vorliegende Erfindung überwacht werden.
• Eine Anzahl von Dienstprogrammen 303, 305 und 307 ist auf jedem der Knoten 302, 304 und 306 installiert. Während viele Dienstprogramme auf einer bestimmten Maschine vorhanden sein können, sind für diese Beschreibung Dienstprogramme von besonderer Bedeutung, die für das Dienstpersonal beim Untersuchen der Konfiguration der Maschine nützlich sein könnten. Dies sind Dienstprogramme, die durch das Dienstpersonal abgespielt werden können, und die dann Berichte erzeugen würden, die das Dienstpersonal auf dem Monitor ansehen oder ausdrucken könnte und dann im Verlauf des Diagnostizierens verschiedener Systemprobleme verwenden könnte.
• Während viele solche Dienstprogramme zum Zweck des Vereinfachens der vorliegenden Beschreibung der Erfindung nützlich sein würden, wird nur ein Dienstprogramm detailliert erörtert und durch die Beschreibung der Erfindung hinweg, die folgt, als ein Beispiel verwendet. Offensichtlich könnten viele Dutzende anderer Dienstprogramme auf die gleiche Weise verwendet werden, um alle Arten von Berichten zu erzeugen und alle Arten von Analysen dieser Knoten und die Erzeugung aller Arten von Berichten zu unterstützten.
• Das ausgewählte Dienstprogramm wird "bdf" genannt. Bezugnehmend auf die Anhänge, und insbesondere auf Anhang E, erzeugt der Befehl
  
  bdf-il
  
  der alleine auf einer Zeile als Befehl getippt wird, der an einen Computer oder Knoten ausgegeben wird, einen Bericht darüber, welche Volumen 328 von verschiedenen Datei-Servern 326 auf einem bestimmten Knoten 302, 304, oder 306"befestigt" sind, dessen Konfiguration bestimmt wird. Es wird ein Bericht erzeugt, wie der, der in Anhang E gezeigt ist. Dieser Bericht zeigt das Volumen an, das befestigt wird, dessen Größe, wieviel von dessen Kapazität durch Dateien verwendet wird, wieviel für eine weitere Speicherung verfügbar ist, und die Prozente des Speicherungsbereichs, der verwendet wird.
• Bezugnehmend auf die Zeilen 14 und 16 von Anhang E wird ersichtlich, daß zwei der Volumen 96% ihres verfügbaren Speicherungsraumes mit Dateien gefüllt haben. Aufgrund der Wichtigkeit des Beibehaltens von zusätzlichem, verfügbarem Speicherungsraum in Dateisystemen zum Hinzufügen zusätzlicher Dateien würde Dienstpersonal, das diese Maschine untersucht wahrscheinlich folgern, daß die Volumen übermäßig voll sind, und daß Anpassungen durchgeführt werden müssen, um sicher zu stellen, daß zusätzliche Dateien, die diesem Volumen hinzugefügt werden, nicht verursachen, daß die Volumen ihre Kapazität überschreiten und Fehler erzeugen und keine Dateien mehr annehmen.
• Innerhalb des Unterstützungsknotens 308 besteht eine Sammler-Datenbank 310, deren Inhalte in Fig. 4 dargestellt sind. Diese Datenbank 310 umfaßt ein HAO-Sammlerprogramm 402, das in der Lage ist, einen Sammlerbefehl zu geben, wie z. B. den "bdf"-Befehl, der in dem vorangehenden Absatz dargestellt ist, ansprechend auf jeden der Knoten 302, 304 oder 306 und ferner auf die PCs 314, 316, etc. Dieses Sammlerprogramm verursacht periodisch, daß die Sammler auf jedem der Knoten laufen, die durch diesen bestimmten Unterstützungsknoten 308 beaufsichtigt werden. Dies wird gemäß einem Sammlungsplan 404 durchgeführt. Die untersuchten Knoten werden in eine Knotenliste 406 aufgenommen. Der Sammler-Abschnitt der Sammler-Datenbank 310 ist bei 408 gezeigt. Er enthält eine Liste von allen Sammler, die ausgeführt werden sollen, zusammen mit einem logischen Namen und einer ID-Nummer für jeden Sammler, wie für den "Datenträgerverwendung"-Sammler "bdf-il" gezeigt ist, dem die ID- Nummer "100024" zugeordnet ist.
• In einigen Fällen ist ein Sammler vielleicht kein einfacher Befehl, wie oben dargestellt ist, sondern er kann eine Reihe von Befehlen sein, um gewisse Programme oder Dienstprogramme in einer gewissen Reihenfolge abzuspielen. Eine derartige Liste von Befehlen kann in einer Datei gespeichert sein, die ein komplexer Sammler genannt werden kann. Komplexer-Sammler-Dateien werden bei 410 gespeichert und werden ferner in den Dienstprogrammbereichen 303, 305 und 307 und auf den Knoten 302, 304 und 306 gespeichert. In dem Fall eines komplexen Sammlers umfaßt die Liste von Sammler 408 den Namen der Datei, die die Liste von Befehlen enthält, die den komplexen Sammler aufweisen, und nicht die eigentlichen Sammlerbefehle selbst.
• Fig. 5 stellt den Prozeß des Erzeugens eines neuen Sammlers dar. Bei Schritt 502 wird ein neuer Sammler einfach durch Hinzufügen desselben zu der Liste von Sammler 408 erzeugt. Der Sammlerbefehl 506 wird zusammen mit einem Namen für den Sammler 504 und dessen ID-Nr. 508 eingegeben. Sobald ein neuer Sammler der Liste von Sammler 408 hinzugefügt ist, wird derselbe aktiv. Natürlich können verschiedene Listen unterschiedlicher Sammler vorhanden sein, die häufiger oder weniger häufig auf jeglichen gegebenen Unternehmenssystem abgespielt werden.
• Sobald ein Sammler erzeugt wird, kann derselbe auf einem Unternehmen 300 installiert werden, bei Schritt 602, durch Installieren desselben auf dem Unterstützungsknoten 308 des Unternehmens innerhalb der Sammler-Datenbank 310, und insbesondere in dem Abschnitt 408 der Datenbank 310, die für Sammler reserviert ist. Komplexe Sammler, die aus mehreren Befehlen bestehen, müssen als Script-Dateien auf den Knoten 302, 304 und 306 mit den Namen der Script-Dateien gespeichert werden, die der Liste von Sammler 408 hinzugefügt werden. Schließlich wird der Sammler bei Schritt 604 für eine periodische Ausführung in dem Plan 404 eingeplant.
• Fig. 7 stellt die Ausführung von Sammler gegen die Knoten 302, etc. in einem Unternehmen 300 dar. Die Ausführung wird üblicherweise durch einen Zeitgeber 702 ausgelöst. (Die Ausführung kann ferner durch Dinge wie einen Konfigurationsartikel ausgelöst werden, wobei das System bestimmt hat, daß er seinen Zustand derart geändert hat, daß die Änderung des Zustands des Konfigurationsartikels verursacht, daß eine verwandte Analyse ausgeführt wird). Wenn ein Zeitgeber abläuft, wird auf die Knotenliste 406 innerhalb der Sammler-Datenbank 310 bezug genommen, und die Knoten werden einer nach dem anderen verarbeitet. Bei Schritt 704 wird ein Knoten ausgewählt. Bei Schritt 706 wird auf die Liste von Sammler 408 bezug genommen, und ein erster Sammler wird für eine Ausführung ausgewählt. Ein Befehl wird an den Knoten 302 gesendet, der geprüft wird, um den bezeichneten Sammler auszuführen. Dies kann z. B. unter Verwendung eines Dienstprogramms, wie z. B. Telnet über ein Internetnetzwerk durchgeführt werden, es muß jedoch sehr darauf geachtet werden, daß die Sammler sicher sind, um ausgeführt zu werden, und nicht die Operationen der missionskritischen Knoten zu stören. Bei dem bevorzugten HAO-Ausführungsbeispiel der Erfindung sind ein Sammlungsagent und eine Sammlungshintergrundroutine (nicht gezeigt) auf jedem Knoten installiert (siehe U.S.-Patent Nr. 6,148,402, erteilt am 14. November 2000 an Randall B. Campbell). Das Unterstützungsknoten-Sammlerprogramm 402 sendet einen Sammler 104 und die Sammlungs-Hintergrundroutine auf dem Knoten 302, um geprüft zu werden. Die Hintergrundroutine leitet den Sammler 104 an einen Sammlungsagenten weiter. Der Sammlungsagent führt den Sammler 104 aus, erfaßt dessen Standardausgabe und Standardfehlerausgaben (STDOUT = standard output und STDERR = standard error outputs), und sendet die gesammelten Ausgangsinformationen zu der Hintergrundroutine zurück, die dieselben zu dem Sammlungsprogramm 402 zurücksendet, das auf dem Unterstützungsknoten 308 läuft.
• Bei Schritt 710, wenn mehrere Sammler vorhanden sind, verzweigt sich die Programmsteuerung zurück zu Schritt 706, wo verursacht wird, daß zusätzliche Sammler auf demselben Knoten 302 ausgeführt werden. Dann, bei Schritt 712, wenn mehrere Knoten 304, etc. zum Prüfen vorhanden sind, kehrt die Programmsteuerung zurück zu Schritt 704, wo der nächste Knoten 304 ausgewählt wird und die Analyse fortschreitet, wie oben beschrieben ist.
• Schließlich, nachdem alle Sammler 104 auf allen Knoten 304, etc. zum Prüfen gelaufen sind, und alle Informationen von den Sammler 104 angesammelt wurden, wird die Sammlerausgaben zu der zentralen Verfolger-Datenbank 106 an dem zentralen Ort für eine weitere Analyse übertragen.
ANALYSIEREN DER KONFIGURATIONSINFORMATIONEN
• Der Analyseprozeß wird in Fig. 8 in Blockdiagrammform erläutert, wobei diese Figur die verschiedenen Datenbanken und Programme zeigt, die in die Analyse und den Berichterzeugungsprozeß involviert sind.
• Bezugnehmend auf Fig. 8 ist der Analysator-Server 800 oben an der Figur gezeigt, und enthält die Analysator-Datenbank 804 und der Analysatorharnisch 806. In dem unteren, rechten Abschnitt von Fig. 8 ist der HAO-Server 105 gezeigt, der die Verfolger-Datenbank 106 enthält, die alle Konfigurationsinformationen in Bezug auf die Knoten 302 und 304, etc. in dem Unternehmen 300 enthält. Links in Fig. 8 ist der Berichterzeuger-Server 302 zusammen mit der Datenbank 204 gezeigt, die die Berichtschablonen und die Regeln und den Berichterzeuger 206 enthält.
• Der erste Schritt bei dem Analyseprozeß ist der des Erzeugens des Analysators 110 und des Erzeugens der Berichterzeugungs-Regeln und -Schablonen 116, die die Berichte 208erzeugen. Wie in der Figur gezeigt ist, verwenden Inhaltsexperten 812 Analysatorerzeugungs-Dienstprogramme 802, um die verschiedenen Dokumente zu erzeugen, die die Analysatoren 110 definieren und dieselben in der Analysator- Datenbank 804 speichern. Diese und andere Inhaltsexperten 812 erzeugen ferner die Regeln, die die Berichterzeugung sowie die Schablonen für die Berichte verwalten, und sie speichern dieselbe, in der Datenbank 204 innerhalb des Berichterzeugerservers 202. Jeder Analysator 110 konzentriert sich auf einen bestimmten Themenpunkt oder einen Satz verwandter Themenpunkte, die innerhalb der Knoten 302, etc. in dem Unternehmen 300 entstehen können. Jeder Analysator ist entworfen, um einen XML-Bericht zu erzeugen, immer wenn sich herausstellt, daß ein Themenpunkt vorhanden ist und durch die Verwaltung berücksichtigt werden muß. Wenn alle der Themenpunktinformationen für einen bestimmten Satz von Knoten innerhalb der (XML) -Themenpunktedatenbank 112 vorhanden sind, dann können alle diese Informationen durch einen höheren Satz von Schablonen und Regeln 118 analysiert werden, die in der Datenbank 204 gespeichert sind, und die die Erzeugung von Berichten 208 in einer höheren Programmiersprache steuern, wobei der Zustand des Unternehmens 300 auf Arten zusammengefaßt wird, die die Verwaltung des Unternehmens verstehen kann.
• Sobald die Analysatoren 110 erstellt und installiert sind, und die Bericht-Schablonen und -Regeln 116 eingerichtet sind, kann das System dann aufgerufen werden, um eine Bewertung des Unternehmens 300 durchzuführen. Ein Prüfer 814, der ein Ingenieur oder eine andere Person sein kann, der wünscht, über den Zustand der Knoten 302, etc. in dem Unternehmen etwas herauszufinden, fordert eine Prüfung an, durch Verwenden eines Aufgabendefinitionssystems 810, um eine Bewertungsaufgabe zu erzeugen. Bei 814 ist eine Bewertungsaufgabe A gezeigt. Die Bewertungsaufgabe 814 umfaßt in deren Definition eine Liste der Unternehmen, die analysiert werden sollen, eine Liste der Knoten an jedem Unternehmen, die der Analyse unterzogen werden sollen und eine Liste der Analyse, die durchgeführt werden soll, in Form der tatsächlichen Namen der Analysatoren, die ausgeführt werden sollen. Zusätzlich dazu umfaßt die Bewertungsaufgabe 814 eine Liste der Berichte, die nachfolgend zu der Analyse erzeugt werden sollen. Eine Berichterzeugung kann zu der Zeit der Analyse durchgeführt werden, oder die Berichte können zu einer späteren Zeit in einem separaten Arbeitsschritt durchgeführt werden.
• Sobald eine Aufgabe 814 definiert und initiiert ist, wird die Liste von Unternehmen, Knoten und Analysatoren an der Analysatorharnisch 806 weitergeleitet. Der Analysatorharnisch 806 fährt dann durch Aufnehmen der Analysatoren 110 aus der Datenbank 804 fort, einer nach dem anderen, und mit jedem Analysator 110 fährt der Analysatorharnisch 806 durch die Knoten 302, etc. fort, einer nach dem anderen. Für jeden Knoten erzeugt der Harnisch 806 eine Rahmenstruktur, wobei der Analysator 110 mit den Konfigurationsinformationsdateien verbunden wird, die aus der Verfolger-Datenbank 106 wiedergewonnen werden. Unter Verwendung dieser Rahmenstruktur wickelt der Harnisch 806 den Analysator 110 in diese Umgebung ein und verursacht, daß derselbe in dem Kontext der Liste von Konfigurationsinformationsdateien ausgeführt wird, die Konfigurationsinformationen enthält, die von dem Knoten 302 angesammelt werden, der momentan analysiert wird. Während seiner Ausführung ruft der Analysator 110 spezielle Unterprogramme (Subroutinen) auf, die kurze XML-Berichte jedes Themenpunkts erzeugen, die die Aufmerksamkeit der Verwaltung gewährleisten, und ferner von jedem Fehlerzustand, der entstehen kann. Nachdem der Analysator 110 abgeschlossen ist, nimmt der Analysatorharnisch 806 diese kleinen Themenpunkt-XML-Berichte und erweitert dieselbe unter Verwendung von Themenpunkttextschablonen, die aus der Analysator-Datenbank 804 wiedergewonnen werden, und ferner von Informationen betreffend die Identität des Knotens und die Identität der Bewertungsaufgabe, und erzeugt einen erweiterten XML-Bericht, der in der (XML) Themenpunkt-Datenbank 112 gespeichert wird, nachdem die Analysen bezüglich aller der Knoten 302, etc. durchgeführt wurden. Auf diese Weise wird ein erweiterter Themenpunktbericht in einem XML-Format erzeugt, der sowohl von Personen lesbar ist, und der es ermöglicht, in eine Datenbank aufgenommen werden, für eine automatische Wiedergewinnung und Handhabung.
• Die Liste von Berichten aus der Aufgabendefinition 814 wird an den Berichterzeuger 206 weitergeleitet. Der Berichterzeuger 206 hat ferner Zugriff zu der Bericht-Schablonen und -Regeln-Datenbank 204 sowie zu dem XML-Themenpunktbericht, der aus der (XML) Themenpunkt-Datenbank 112 wiedergewonnen werden kann. Unter Verwendung dieses gesamten Materials bewertet eine Expertensystemmaschine innerhalb, oder ergänzend zu, dem Berichterzeuger 206 die Regeln und untersucht, unter deren Führung, die Themenpunktinformationen, wobei Schlußfolgerungen auf hoher Ebene für die Verwaltung erzeugt werden, die den allgemeinen Zustand des Unternehmens betreffen. Dann, unter Verwendung der Berichtschablonen, bereitet der Berichterzeuger 206 eine Vielzahl von Berichten vor, wie erklärt wurde, die den Zustand des Unternehmens 300 und dessen Knoten 302, etc. erläutern. Diese werden dann an verschiedene Empfänger der Berichte 817 verteilt.
• Fig. 9 stellt die Inhalte der Verfolger-Datenbank 106 dar. Bei dem bevorzugten Ausführungsbeispiel ist eine Verfolger- Datenbank 104 für die Vereinigten Staaten eingerichtet, eine andere für Europa und eine andere für Asien. Diese Verfolger-Datenbanken 106 sind durch ein herkömmliches Vernetzen mit den unterschiedlichen Unternehmen 300 verbunden, auf die sich dieselben beziehen, so daß sie Informationen 24 Stunden am Tag sammeln können und somit auf dem Laufenden bleiben. Wie in der Figur dargestellt ist, sind die Informationen der Verfolger-Datenbank 106 als erstes nach Unternehmen organisiert, innerhalb des Unternehmens nach Knoten, innerhalb des Knotens nach dem Sammler, und innerhalb des Sammlers nach den Ausgangsdateien, die jeder Sammler erzeugt hat, wobei jeweils Zeit und Datum angegeben sind, so daß eine historische Sammlung von Konfigurationsinformationen möglich ist. Mit dieser Organisation ist der Analysatorharnisch 806 in der Lage, die Informationsdatei anzufordern, die durch einen Sammler 104 erzeugt wurde, als derselbe auf einem Knoten 302, etc. innerhalb eines Unternehmens 300 lief.
• Fig. 10 stellt ein Flußdiagramm des Prozesses dar, durch den ein Prüfer 814 die Bewertungsaufgabe definiert, die durch den Analyse-Server 800 während einer gegebenen Verarbeitungsoperation ausgeführt werden muß.
• Der Prüfer 814 beginnt durch Spezifizieren des Typs von Bewertung, die ausgeführt werden soll. Bei 1002 ist ein erster Typ von Bewertung die "Gesamtprüfungsanfrage". Die Gesamtprüfungsanfrage betrachtet alle Aspekte des Unternehmens 300, bis hin zu den kleinsten Details. Sie erzeugt ferner Berichte in einer höheren Programmiersprache für die Verwaltung und für andere, die allgemeine Schlußfolgerungen über den Zustand des Unternehmens, die Eigenschaften der aufgefundenen Probleme und die möglichen Lösungen, die berücksichtigt werden können, ziehen. Es ist die Gesamtprüfungsanfrage oder die Gesamtprüfung von Abschnitten eines Unternehmens, die den vollen Vorteil aus den Fähigkeiten der vorliegenden Erfindung zieht, nicht nur um viele Konfigurationsinformationen unter Verwendung der Sammler 104 über ein Unternehmen 300 zu sammeln, und diese Informationen unter Verwendung mehrerer Analysatoren 110 zu analysieren, sondern ferner um einem Berichterzeuger 206 Regeln zuzuweisen, die die Themenpunkte durchsehen können, die durch den Analysator 110 entwickelt wurden, die Themenpunktinformationen auf der Suche nach statistischen Anzeigen und Tendenzen durchsuchen können und ferner aktuelle und vergangene Themenpunktinformationen vergleichen zu können, um langfristig Tendenzen zu sehen, wodurch bedeutende Berichte darüber erzeugt werden, in welche Richtung das Unternehmen 300 geht, und was getan werden kann, um dessen Versagen zu verhindern und dessen Flußoperationen und Zuverlässigkeit zu verbessern. Sobald diese Informationen bekannt, weitergeleitet und bearbeitet sind, ist es möglich, sich in den Fachbereich von selbstheilenden System zu bewegen. In diesem Fachbereich wird ein Themenpunkt automatisch erfaßt, die empfohlene Aktion ist bekannt, und der Themenpunkt wird gelöst, bevor dieselbe zu einem Problem wird. Der Kunde wird über die Lösung und nicht über den Themenpunkt benachrichtigt.
• Ein zweiter Bewertungstyp wird einfach eine "Bewertung" genannt. Eine Bewertung umfaßt die Verwendung einer großen Anzahl von Sammlern 104, deren Ausgaben durch eine relativ große Anzahl von Analysatoren 110 verarbeitet wird. Ein detaillierter Bericht von allen identifizierten Themenpunkten wird dann erzeugt.
• Ein dritter Bewertungstyp ist die Gesundheitsüberprüfung, die in relativ zusammenfassenden Worten angibt, ob die Knoten innerhalb eines Unternehmens OK sind, oder ob Probleme vorhanden sind, die adressiert werden müssen. Dies ist eine relativ einfache "Ja"- oder "Nein"-Typ-Bewertung, die primär ausschließlich auf kritische Werte sieht und die einen minimalen Bericht erzeugt.
• Der Prüfer 814 kann jeglichen von verschiedenen unterschiedlichen Typen von Geltungsbereichen für jede dieser Bewertungen auswählen. Eine Gesamtbewertung betreibt alle Analysatoren 110 und erzeugt eine große Menge von Themenpunktinformationen über alle Aspekte eines Unternehmens 300. Eine Hardware- und Betriebssystem-Bewertung betreibt nur jene Analysatoren 110, die sich auf die Hardware- und Betriebssystem-Elemente konzentrieren, im Gegensatz zu ihren Programmen, Dateisystemen, Netzwerken, etc. Eine Netzwerkbewertung konzentriert sich auf die Netzwerkaspekte eines Unternehmens 300, einschließlich solcher Dinge wie Netzwerkbelastung, Netzwerk-Verlangsamung, und die Zustände der verschiedenen Netzwerk-Router und -Schalter. Eine Dateiverwaltungs- und Speicherungs-Bewertung konzentriert sich auf den Zustand der Datenträgerlaufwerke, die Verfügbarkeit von Raum innerhalb des Dateisystems, und andere derartige Themenpunkte. Die Bewertungshierarchie, die für eine Aufgabendefinition verfügbar ist, kann die Bewertungs-XML-Hierarchie der XML-Steuerinformationen für die einzelnen Analysatoren anpassen, wie in Fig. 25 dargestellt ist, und wie zu einem späteren Zeitpunkt erklärt wird.
• Der nächste Schritt bei dem Aufgabendefinitionsprozeß ist der Schritt 1004, der eine vorläufige Liste von Analysatoren auswählt, die mit dem ausgewählten Bewertungstyp übereinstimmt. Die vorläufige Liste von Analysatoren 110 wird automatisch durch das Aufgabendefinitionssystem 810 ausgewählt und wird mit Kontrollkästchen neben jedem Analysatornamen angezeigt; dann wird dem Prüfer ermöglicht, die Liste von Analysatoren anzusehen und zu modifizieren, die schließlich verarbeitet wird, möglicherweise durch Hinzufügen von einigen und möglicherweise durch Entfernen von einigen, die für eine gegebene Prüfung nicht erforderlich oder notwendig sind. Nur die Analysatoren, deren Kontrollkästchen abgehakt sind, werden schließlich ausgeführt.
• Als nächstes wird der Standort der Bewertung gekennzeichnet. Bei Schritt 1006 wird eine Region (Vereinigte Staaten, Europa, etc.) ausgewählt, oder möglicherweise wird eine Informationsquelle einer Stammdatenbank 212 ausgewählt, wenn eine Echtzeitüberwachung des zu prüfenden Unternehmens 300 momentan nicht implementiert ist. Bei Schritt 1008 werden eines oder mehrere Unternehmen 300 innerhalb der ausgewählten Region für ein Prüfen ausgewählt. Bei Schritt 1010 wird automatisch eine Auflistung der Knoten 302, etc. des Unternehmens 300 erzeugt und angezeigt, wiederum mit Kontrollkästchen, derart, daß der Prüfer hingehen kann und einige Knoten aus der Prüfung entfernen kann und andere Knoten zu der Prüfung hinzufügen kann. Als nächstes geben bei Schritt 1012 in Fig. 11 die Prüfer Informationen ein, die sie selbst identifizieren, und ferner Anmerkungen, wie z. B. eine allgemeine Erklärung darüber, warum die Prüfung durchgeführt wird. Wenn der Kunde z. B. gewisse Schwierigkeiten erfahren hat, kann der Prüfer wünschen, dies an diesem Punkt zusammenzufassen, damit der Grund für die Prüfung in dem Endbericht erscheint.
• Bei Schritt 1014 wird die Eigenschaft des oder der gewünschten Berichte ausgewählt. Der Prüfer kann nur einen Verwaltungszusammenfassungsbericht berichten, oder er oder sie kann einen technischen Zusammenfassungsbericht anfordern. Andererseits könnte der Prüfer wünschen, alle technischen Details zu sehen. Ein spezieller Marketingbericht, der Bereiche anzeigt, in denen das Unternehmen überzeugt werden könnte, zusätzliche Hardware oder Software zu kaufen, kann ebenfalls erzeugt werden. Ein detaillierter Bericht des Herstellers würde über die Aktualisierungsebene und über Versionen der gesamten Software und Hardware berichten, und könnte Informationen betreffend die Fehler enthalten, die für eine spätere Wartung des Unternehmens nützlich sein könnten, oder die den Bedarf nach Verbesserungen bei dem Entwurf einer Systemkomponente vorschlagen können.
• Es wird ferner ein Format für den Bericht ausgewählt. Der Textbericht kann in der Form eines Textverarbeitungsdokuments erzeugt werden, das für ein Drucken in Farbe geeignet ist. Berichte in höherer Programmiersprache können in einem Präsentationsformat für eine Projektion und eine Anzeige an die Verwaltung erzeugt werden. Ein HTML-Bericht könnte eine Verbindung zu zugrundeliegenden, erklärenden Details von einem allgemeinen Bericht sein. Zusätzlich könnte der Prüfer 814 wünschen, anzufordern, daß statistische Informationen in einer tabellarischen, graphischen oder Diagramm-Form vorgelegt werden, um dieselben leichter verständlich zu machen.
• Das Berichtformat variiert ferner abhängig von dem Ziel des Berichts. Daher wird bei den obigen Berichtformaten angenommen, daß Personen den Bericht empfangen sollen. Wenn der Bericht jedoch für eine Datenbank bestimmt ist, würde derselbe jedoch natürlich als ein XML-Dokument erzeugt werden, das für einen einfachen Datenbankeintrag geeignet ist oder möglicherweise direkt in eine SQL- oder einen anderen Typ von Datenbank eingegeben wird. Falls ein Arbeitsflußsystem existiert, das Arbeitsaufträge für Dienstpersonal erzeugen kann, kann es wünschenswert sein, eine maschinenlesbare Datei zu erzeugen, die Informationen von dem Bericht enthält, die direkt in das Arbeitsflußsystem übertragen werden können, um direkt zu dem Planen von Wartung und Reparatur zu führen. Dies kann insbesondere für kritische Themenpunkte durchgeführt werden, die sofortige Aufmerksamkeit benötigen. Wenn eine Heilersystem-Einrichtung alternativ verfügbar ist, die hingehen kann, um eine neue Software auf Knoten neu zu konfigurieren oder zu booten, kann eine maschinenlesbare Version eines Berichts in einem Format erzeugt werden, das als Eingabe in das Heilersystem akzeptabel ist, so daß derartige Reparaturen sofort begonnen werden können. Dies ist wünschenswert, um einen fehlersicheren Betrieb der Knoten 302, etc. zu erreichen, nicht nur bei auftragskritischen Anwendungen, sondern bei den meisten oder allen Anwendungen. Die vorliegende Erfindung kann somit als zentrale Rückkopplungsverbindung bei der Realisierung von tatsächlich selbstheilenden Systemen verwendet werden.
• Bei Schritt 1016 wird schließlich ein Liefermechanismus ausgewählt. Die Berichte können natürlich gedruckt werden, oder sie können per E-Mail an eine Empfängerliste gesendet werden, die versorgt werden muß. In dem Fall von maschinenlesbaren Berichten, die für Arbeitsflußsysteme oder Heiler- Systeme oder -Datenbanken bestimmt sind, muß die Internetadresse der Empfängercomputer bereitgestellt sein.
ERZEUGEN NEUER ANALYSATOREN
• Der Analysatorerzeugungsprozeß ist in den Fig. 12 und 13 in Flußdiagrammform dargestellt, und Fig. 14 stellt eine Liste von Benutzerschnittstelleneinrichtungen dar, die bei dem Prozeß des Erzeugens neuer Analysatoren helfen können. Zusätzlich dazu stellen die Anhänge A, B, C und D einfache Beispiele der verschiedenen Komponenten eines Analysators dar.
• Als ein einfaches Beispiel dafür, wie ein Analysator erzeugt werden kann, kann die "Datenträgerverwendung"- Sammlernummer 100024, deren Erzeugung bei 500 in Fig. 5 dargestellt war, und deren Speicherung in der Sammler- Datenbank 310 bei 408 in Fig. 4 dargestellt ist, als eine Quelle von Eingangsinformationen für einen Analysator 110 verwendet werden, der erzeugt wurde, um den Prozeß darzustellen.
• Es wird darauf hingewiesen, daß der "Datenträgerverwendung"-Sammler 104, wenn er auf einem Knoten 302 ausgeführt wird, den einfachen Textbericht erzeugt, der in Anhang E dargestellt ist. Einfach ausgedrückt listet dieser Bericht für jedes Dateisystemvolumen, das an einem bestimmten Knoten angebracht ist, den Namen des Volumens, und u. a. den Prozentsatz des Dateispeicherungsbereichs des Volumens dar, der mit Dateien gefüllt ist. Die Anhänge A-D stellen die Details eines Analysators dar, der zugeordnet ist, um den Bericht zu betrachten, der in Anhang E gezeigt ist, um Berichte betreffend alle Volumen zu extrahieren, deren Belegungspegel 90 oder 95 Prozent überschreitet, oder die voll sind, und die daher in Gefahr sind, ihre Kapazität zu überschreiten. Dieser Analysator 110 testet die numerischen Informationen auf jeder Leitung des Berichts, der in Anhang E gezeigt ist, lokalisiert die Prozentzahl, vergleicht dieselbe mit 90 und 95 und 100 Prozent und erzeugt dann einen Themenpunktbericht, wenn, und nur wenn die Menge von belegter Speicherung die 90- 95- oder 100-Prozentgrenze überschreitet. Wie erklärt wird, wird dieser Themenpunktbericht durch den Analysator innerhalb einer Rahmenstrukturumgebung erzeugt, in der der Analysator nicht wirklich "weiß", welchen Knoten 302, etc. derselbe bewertet. Dementsprechend wird der Bericht dann in einen größeren XML-Bericht eingebettet, der durch den Analysatorharnisch 806 erzeugt wird, die den Knoten identifiziert, und die ferner Textmeldungen einschließt, die die Eigenschaft des Themenpunkts erklären, die entstanden ist.
• Bezugnehmend nun auf Fig. 12 beginnt der Analysatorerzeugungsprozeß vorzugsweise mit dem Inhaltsexperten 812 unter Verwendung eines Textverarbeiters, um eine Textbeschreibung des Analysators 110 vorzubereiten, die erklärt, was in vom Menschen lesbaren Ausdrücken zu tun ist. Dieser Textbericht erscheint in Anhang A für den exemplarischen Analysator, der entworfen ist, um den Bericht zu akzeptieren und zu analysieren, der in Anhang E gezeigt ist, der durch den Sammler "bdf-il" geliefert wird, der die Verwendung des Volumenspeicherungsraumes bewertet.
• Der Experteninhalt, der in die Analysatoren eingegeben wird, deckt formelles und systematisches Wissen ab, das leicht kommuniziert und kodiert werden kann, und das leicht erhältlich ist (explizites Wissen) und persönliche Informationen, die auf Erfahrung und Lernen basieren, und die oft nicht aufgezeichnet und nicht ausgesprochen (taktisches Wissen) werden, und schwieriger zu formulieren sind.
• Als nächstes sammeln die Analysatorerzeugungs- Dienstprogramme 802 bei Schritt 1204 Informationen, die den Inhaltsexperten 812 dieses Analysators 110 sowie die Erzeugungsrevisionsdaten und andere Hintergrundinformationen identifizieren.
• Bei Schritt 1206 wird dem Entwerfer 812 eine Liste aller Sammler vorgelegt, die nach Klassen verwalteter Elemente organisiert sind, und wird eingeladen auszuwählen, welche Sammler Eingangsinformationen für diesen Analysator liefern. Im allgemeinen kann ein einzelner Analysator Eingangsinformationen von einem oder einer beliebigen Anzahl von Sammler 104 annehmen und kann dann diese Informationen auf jegliche Anzahl von komplexen Wegen verarbeiten. Dutzende von Sammler-erzeugten Knotenkonfigurationsdateien können in einen Analysator eingegeben werden, der ein riesiges Computerprogramm sein kann, geschrieben in "C" oder "C++" und kompiliert aus zahlreichen "C" oder "C++"- Programmdateien unter der Steuerung "Erstellungs"-Datei. Andererseits kann ein Analysator ein sehr einfaches Programm sein, das in "Java" oder "Perl" geschrieben ist. Um das Beispiel, das hier entwickelt wird, einfach zu halten, sammelt der Analysator Informationen nur von dem Sammler, der als "Datenträgerverwendung" identifiziert ist, und dem die Identifikationsnummer "100024" zugeordnet ist.
• Als nächstes erzeugt der Entwerfer bei Schritt 1208 eine oder mehrere Analysatorthemenpunktschablonen, die Platzhalter für die Einfügung von variablen Informationen enthalten können. Eine solche Schablone ist in Anhang D dargestellt, wo Schablonennummern den drei Schablonen vorangehen. Diese Schablonen enthalten innerhalb ihres Textes Begrenzungszeichen, die markieren, wo variable Informationen eingefügt werden können. In diesem Fall identifizieren die variablen Informationen das Dateisystemverzeichnis, das einen Themenpunkt verursacht hat.
• Als nächstes wird bei Schritt 1210 der Quellcode (mit Anmerkungen) für den Analysator erzeugt. Eine typische Quellcodedatei ist in Anhang B dargestellt. Diese Quellcodedatei wird entweder kompiliert oder interpretiert oder anderweitig ausgeführt, nachdem dieselbe verkabelt und in eine Rahmenstruktur eingehüllt wurde, die dieselbe mit den richtigen Eingangsinformationen beliefert, um die Analyse eines bestimmten Knotens durchzuführen. Die Quellcodedatei kennt die Identität des Knotens nicht, dessen Konfigurationsinformationen dieselbe analysiert. Sie weiß einfach, daß eine Liste von Dateinamenargumenten eingegangen ist, und aus ihrer Reihenfolge weiß dieselbe von welchen Sammler diese Dateien stammen. Bei diesem einfachen Beispiel ist das Argument ein einfacher Dateiname, der Name einer Datei, die den Bericht enthält, der in Anhang E erscheint, und der Informationen enthält, die die Identität der angehängten Dateisysteme identifiziert, und wie nahe ihre Volumen daran sind, ihre Kapazität zu überschreiten, wie bereits erklärt wurde. Bei einem komplexeren Fall würde eine Reihe von Quelldateien, die durch eine Reihe unterschiedlicher Sammler entwickelt wurden, als Argumente für die Ausführung in den Analysatorcode übertragen. Der Analysatorcode wird unabhängig von jeglichem, bestimmten Knoten beschrieben, in den meisten Fällen so, daß der gleiche Analysator wiederholt verwendet werden kann, um Hunderte von unterschiedlichen Knoten zu analysieren, die Tausende von unterschiedlichen Konfigurationen aufweisen.
• Bei dem bevorzugten Ausführungsbeispiel der Erfindung ist die Analysatorverdrahtung 806 in "Java" geschrieben, und dementsprechend kann "Java" als eine der Sprachen verwendet werden, in der ein Analysator geschrieben werden kann. Bytecodekompilierte Versionen derartiger "Java"- Analysatoren werden einfach gebootet und direkt durch die Analysatorverdrahtung 806 ausgeführt, und denselben wird die Liste von Dateinamen als eine Eingabe übertragen.
• In manchen Fällen kann es wünschenswert sein, einen Analysator in den Programmiersprachen "C" oder "C++" zu schreiben, oder es kann wünschenswert sein, ein bestehendes Programm, das in "C" oder "C++" geschrieben ist anzupassen, das bereits für ein Feldtesten verwendet wird, um als ein Analysator zu dienen. Solche ausführbaren Dateien werden kompiliert und unter der Herstellungsdateisteuerung auf normale Weise verbunden, und werden durch die Analysator- Verdrahtung 806 in Betrieb gesetzt, die ein herkömmliches Betriebssystem "Schalen"-Dienstprogramm nennt, um solche ausführbare Analysatoren zu starten. Solche "C-" oder "C++"- Programme können hochkomplex sein und können ein Quellmodul sowie zusätzliche Codemodule umfassen und ein Herstellungs- Dienstprogramm zum Steuern, Kompilieren und Verbinden. Bereitstellungen in den Analysatorerzeugungsdienstprogrammen 802 werden gemacht, um alle diese Analysatordateikomponenten in der Analysator-Datenbank 804 zu umfassen, und dieselben nach Bedarf für eine Ausführung zu kompilieren, immer wenn Änderungen an dem Quellcode durchgeführt werden, genau wie in einer Standardprogramm-Entwicklungsumgebung.
• In anderen Fällen kann der Analysator in einer interpretierbaren Sprache geschrieben sein, wie z. B. perl oder "Kshell", und nicht in "Java" oder "C" oder "C++". In diesen Fällen startet der Analysatorharnisch 806 ein Interpretiererprogramm und leitet dasselbe an die Argumentliste weiter, die die Namen der Dateien enthält, die die Sammler- Konfigurationsinformationen enthalten, die verarbeitet werden sollen.
• Wie bei Schritt 1210 angedeutet ist, akzeptiert die vorliegende Erfindung Analysatoren, die in "Java", "C" oder "C++", "Perl" oder "Kshell" geschrieben sind, und speichert dieselben in der Analysator-Datenbank 804, kompiliert (falls notwendig) und bereit, um ausgeführt zu werden. Bezugnehmend auf Fig. 13 ruft Schritt 1212 den Entwerfer 812 eines Analysators 110 auf, zu spezifizieren, welche Knoten 302 er analysieren soll, falls nötig. Die Voreinstellung ist, daß ein Analysator 110 alle Knoten 302 verarbeitet, und dann wird der Analysator 110 durch den Analysatorharnisch 806 aufgerufen, um Dateien zu verarbeiten, die durch die Sammler 104 erzeugt wurden, für alle Knoten 302, 304, 306 (etc.) nacheinander, wobei der Analysator 110 einmal für jeden Knoten mit unterschiedlichen Eingangsdatei- Argumentlisten ausgeführt wird, jedes Mal vorausgesetzt, daß der Analysator 110 läuft.
• In manchen Fällen kann ein gegebener Analysator auf einem Teilsatz von verwalteten Elementen arbeiten, die als eine Sammlung von Knoten spezifiziert sein können, die in einer Liste von verwalteten Elementen umfaßt sind. Alternativ kann es bei einem System, bei dem Knoten zusammen gruppiert sind, um einander gegenseitig zu sichern, und um alternative Plattformen zum Ausführen von Programmen zu liefern, wenn einer oder ein anderer der Knoten in einer Gruppe außer Betrieb ist, möglich sein, daß ein gegebener Analysator Eingangsdaten verarbeitet, die von allen Knoten in einer Gruppe gleichzeitig empfangen werden.
• Wenn der Inhaltsexperte 812 nun den Prozeß des Definierens des Analysators 110 abgeschlossen hat, verbleibt es nun, die Informationen in der Analysator-Datenbank 804 zu speichern, die einen Analysator 110 definieren. Der Schablonentext (Anhang D) und der Quellcode (Anhang B) zusammen mit der Textbeschreibung (Anhang A) des Analysators werden einfach als separate Dateien in der Analysator-Datenbank 804 gespeichert und werden mit dem Namen des Analysators in einem Verzeichnis verbunden. Es verbleiben die anderen Informationen, die durch den Benutzer geliefert werden, die die Bedingungen definieren, unter denen der Analysator betrieben werden soll, die Namen der Dateien, die die Schablonen und den Quellcode enthalten, der Autor des Codes, die bestimmte Sprache, in der die Schablone geschrieben ist, und andere Dinge. Diese Informationen werden in der Form einer XML-Analysator-Beschreiberdatei ferner in der Analysator-Datenbank bei Schritt 1214 gespeichert. Eine exemplarische XML-Datei erscheint in Anhang C.
• Bezugnehmend auf Anhang C umfaßt der Abschnitt dieser XML- Datei der Analysatordefinition folgendes:
  
  einen Standard-XML-Anfangsblock;
  den Analysatornamen und die Versionsnummer;
  die E-Mail-Adresse des Autors;
  eine einzeilige Beschreibung des Analysators;
  eine Verbindung oder einen Zeiger zu der ASCII- Schablone, die die Themenpunkte definiert (siehe Anhang D);
  eine Verbindung oder einen Zeiger zu der Analysator- Codedatei;
  die bestimmte Programmiersprache ("Kshell", "Java", "C", "perl"), die beim Schreiben des Analysators verwendet wurde;
  den Typ der Analysatorquelle - Text, binär ("C" oder "C++"), oder Bytecode ("Java");
  den "Zweck" dieser Analysatordatei - Hauptdatei, Hilfsdatei oder Herstellungsdatei, und ob dieselbe ausführbar ist;
  (Wiederholungen der obigen vier Zeilen für jede separate Analysatorprogrammdatei;
  die Anzahl von Knoten, die gleichzeitig verarbeitet werden können; und
  die Eingabequelle in der Form einer Liste von Kollektor-Namen oder -Nummern.
  
• Wie ersichtlich ist, definiert die hierin erläuterte XML- Datei ausführlich, wie der Analysatorharnisch 806 einen bestimmten Analysator ausführen muß, nachdem dieselbe ihn in einen Rahmen einhüllt und einstellt, um die Informationen zu prüfen, die sich auf einen bestimmten Knoten oder eine Reihe von Knoten beziehen. Diese XML-Datei kann man sich als ein Steuerprogramm für den Analysatorharnisch 806 vorstellen, das die Ausführung des entsprechenden Analysators 110 verwaltet.
• Schließlich werden bei Schritt 1216 alle soeben beschriebenen Information in der Analysator-Datenbank 804 als Teil der Definition des Analysators 110 gespeichert.
• Ein bevorzugtes Ausführungsbeispiel der Erfindung liefert eine Anzahl von optionalen aber nützlichen Tools für den Analysator-Entwerfer in der Form von Benutzerschnittstellen und Dienstprogrammen. Diese sind in Fig. 14 aufgelistet:
  Ein allgemeines Dienstprogramm ermöglicht die Erstellung von neuen Analysatoren und die Modifikation oder Löschung bestehender Analysatoren bei 1402 und ist den Tools ähnlich, die in jeglicher Programmentwicklungsumgebung bereitgestellt sind.
• Wenn das Eingeben der Informationen betreffend einen Analysator abgeschlossen ist, erzeugt ein XML-Descriptor- Erzeugungsdienstprogramm 1404 die XML-Datei, wie z. B. in Anhang C dargestellt ist, automatisch.
• Verwalter werden bei 1408 bereitgestellt, für einen Programmquellcode, einen Hilfsquellcode, und Herstellungsdateien, die denen ähnlich sind, die in jeglicher Allzweck- Programmentwicklungsumgebung angetroffen werden. Zusätzlich wird einem Verwalter ermöglicht, bei der Erzeugung von Schablonentextdateien zu helfen, wie z. B. der, die in Anhang D gezeigt ist, die eine Bereitstellung zum Einbetten verschiedener Platzhalter in eine derartige Textdatei umfaßt. Ein Analysator könnte z. B. eine Information aus einem Sammlerdokument herausziehen und dann arrangieren, daß die Informationen an dem variablen Einfügungspunkt innerhalb einer solchen Textdateischablone eingefügt werden, so daß die Schablone knotenspezifische Informationen enthält, zusätzlich zu (vorformulierten) Hintergrund-Standardinformationen, die einen gegebenen Themenpunkt definieren.
• Um beim Verwalten der vielen Sammler zu assistieren, die verfügbar sein können, ist eine Sammler-Sucheinrichtung 1410 bereitgestellt, die ein Durchsuchen von Sammler ermöglicht, sowohl durch den Unix- oder einem anderen Befehl, der einem Sammler zugeordnet ist (z. B. "bdf"') und ferner durch die logischen Namen und Nummern, die einem Sammler zugeordnet sind.
• Um das Testen von Analysatoren zu ermöglichen, ist bei 1412 eine einfache Analysator-Entwicklungsumgebung bereitgestellt, die einen Analysator in einer Rahmenstruktur einkapselt und denselben mit Live-Probeninformationen beliefert, die von editierbar gespeicherten Proben (Stichproben) von einer Sammlerausgangsdatei-Eingabe erhalten werden, so daß ein Prototypanalysator in einer sicheren Umgebung getestet werden kann, um zu sehen, wie sich derselbe verhält.
• Ein besonderes hilfreiches Tool ist eines, das die Erzeugung der Listen von Sammlerausgangs-Konfigurationsinformationsdateien ermöglicht, die in die Analysatoren als deren Informationseingangssignal eingegeben werden, und die dem Entwerfer helfen, die Namen dieser Sammlerausgangsdateien in der richtigen Reihenfolge anzuordnen, die durch die Analysatoren erwartet wird. Diese Einrichtung 1414 stellt in tabellarischer Form eine vertikale Liste von Analysatoren auf der linken Seite und eine vertikale Liste von Sammlerberichten auf der rechten Seite dar und ermöglicht durch Klicken mit der Maus, jeden Analysator mit einem oder mehreren Sammlerberichten zu verbinden, und durch das Anordnen dieser Verbindungen die Reihenfolge anzuzeigen, in der Sammlerberichte in jeden Analysator als Argumente eingegeben werden sollen, die einem Analysator jedes Mal übertragen werden, wenn ein Analysator ausgeführt wird.
• Ein anderes, nützliches Dienstprogramm liefert dem Entwerfer einfach Ansichten von Muster-Sammlerberichten bei 1416. Da die Analysatoren in diese Berichte eintreten müssen und Text aus der Mitte der Berichte unter Verwendung programmierbarer Befehle extrahieren müssen, ist es wichtig, daß die Entwerfer der Analysatoren Zugriff zu Musterberichten haben, damit sie sehen können, wie der Text positioniert ist, und dann den richtigen Textextrahierungscode liefern, um Ausschnitte für eine Analyse oder für eine mögliche Aufnahme in die Themenpunktanmerkungen aus den Berichten auszuschneiden. In Zukunft zergliedert die Rahmenstruktur die Informationen, und die Analysatoren werden nur die Information empfangen, die sie benötigen, um ihre Analyse durchzuführen.
• Bei Schritt 1418 wird schließlich ein Verwalter bereitgestellt, der Analysatoren in logische Gruppen gruppiert und dadurch den Analysatoren ermöglicht, einem bestimmten Bewertungstyp zugeordnet zu sein. Dieses Tool ermöglicht die Anordnung von Analysatoren derart, daß der Prüfer 813 eine intelligente Entscheidung bei Schritt 1002 (Fig. 10) darüber treffen kann, welche Aufgabe durchgeführt werden soll, und einen geeigneten Satz von Analysatoren präsentiert, die bei Schritt 1004 modifiziert werden können, wenn der Prüfer 813 eine Aufgabendefinition unter Verwendung des System 810 durchführt, wie vorangehend beschrieben wurde.
ERZEUGEN VON SCHABLONENBERICHTEN
• Die Fig. 16-18 stellen mittels Flußdiagrammen den Prozeß des Erzeugens von Schablonenberichten dar und ferner die Regeln, die die Anordnung von Schablonen verwalten und die eine Analyse der Themenpunkte in höherer Programmiersprache durchführen, die durch die individuellen Analysatoren identifiziert werden. Die Fähigkeit des Systems, lesbare, wichtige zusammenfassende Verwaltungsberichte zu erzeugen, hängt weitgehend von diesem Abschnitt des Systems ab.
• Bei dem bevorzugten Ausführungsbeispiel der Erfindung wird ein Programm mit dem Namen "Crystal Reports", erhältlich bei Krystal Decisions, Palo Alto, Kalifornien, verwendet, um Schablonendokumente in fertige Berichte unter der Steuerung der Datenbank umzuwandeln. Crystal Reports umfaßt Analysetools, die Tendenzen untersuchen, Beziehungen freilegen und sich auf wichtige Fakten konzentrieren können. Somit kombiniert dasselbe Regel- und Bericht-Schablonen in einem einzelnen "Stapel"-orientierten Berichterzeuger, der durch die Themenpunkt-Datenbank getrieben werden kann, die von einer XML-Dateiform in ein Microsoft-Access-Datenbanksystem übertragen wird. Andere auf Regeln und Schablonen basierende Berichterzeuger können ebenfalls verwendet werden, wie z. B. "Caps Author" und "Hot docs" (von der Capsoft Development Corporation, Provo, Utah).
• Das Einrichten dieser Systeme involviert zwei Aspekte. Zuerst wird angenommen, daß die eingehenden Informationen in einer bestimmten Form einer Datenbank sind. Bei dem bevorzugten Ausführungsbeispiel der Erfindung ist die Datenbank ein Microsoft Access-Datenbankprogramm. Die XML- Themenpunktdatei wird einfach gelesen und ihre Inhalte werden direkt in Access eingegeben.
• Die Schablonendokumente, die gemäß den Berichterzeugererklärungen entworfen sind, enthalten große Mengen von Standard- oder Hintergrund-Text. Sie können ferner eingebettete Befehle analog zu den Programmiersprachenbefehlen "if", "else" und "end if" enthalten, die in Programmen verwendet werden, um auszuwählen, welche Codeabschnitte ausgeführt oder übersprungen oder als Alternative durchgeführt werden sollen. In dem Fall von Dokumentschablonen bestimmen diese gleichen Befehlstypen, welcher Text in einem Bericht endet und welcher Standardtext ausgeschnitten und auf dem Schneideraumboden gelassen wird.
• Solche Berichterzeuger sorgen ferner für die Erzeugung sich wiederholender Abschnitte durch die Verwendung von Befehlen analog zu den Sprachbefehlen "repeat" und "end repeat", die in Programmiersprachen gefunden werden. Schließlich können Schablonen verschiedene Typen von Platzhaltern für Ausdrücke enthalten, die bewertet und dann in den Standardtext eingefügt werden, um Teil des Endberichts zu werden.
• Zusätzlich dazu haben die meisten solchen Systeme die Einrichtung, um separate Regeln zu liefern, die nicht nur Werte berechnen, die in die Berichte eingefügt werden sollen, sondern ebenfalls Werte, die den Einschluß oder Ausschluß von Standardtext sowie den Einschluß sich wiederholender Einfügungen steuern. Diese Regelsysteme können wohldurchdacht sein, und bilden "rückwärtsverkettende" Expertensysteme, die Hunderte von Regeln einschließen können, und die sehr detaillierte und ausführliche Analysen ansprechend auf die eingehenden Analysatorinformationen durchführen können, von denen angenommen wird, daß dieselben in einer Microsoft- Access-Datenbank gespeichert werden (jegliches andere Datenbanksystem auf jeglicher Plattform könnte hier verwendet werden). Ein abschließende Bereitstellung dieser Systeme verursacht das Einfügen von Tabellen in den Text eines Berichts, wobei die Tabellen aus der Access-Datenbank extrahiert werden. Ein solch detaillierter, technischer Themenpunktbericht könnte z. B. eine Tabelle umfassen, die jeden einzelnen der Themenpunktberichte zusammenfaßt, der durch eine Analyse erzeugt wurde, wie am Ende von Anhang G dargestellt ist.
• Am Anfang des Prozesses der Berichtschablonenerstellung ist der erste Schritt bei 1602, die symbolischen Namen der Analysator-Ausgangsinformationen für den Autor des Berichts verfügbar zu machen, die sowohl eingebettet in die Berichtschablonen als auch zum Steuern der Berichtschablonen- Standardauswahl verwendet werden sollen. Diese Informationswerte kommen notwendigerweise aus dem Analysensystem. Bezugnehmend auf Anhang F, stellt Teil 2 von Anhang F den XML-Informationsausgang dar, der von Themenpunkten stammt, die durch die Ausführung von Analyseprogrammen an Konfigurationsinformationen erfaßt wurden, die durch Sammler angesammelt wurden. Diese Informationsstruktur wird in eine Microsoft-Access-Datenbank übertragen, aus der die Werte unter Verwendung von Identifizierern gleich oder ähnlich denselben, die in der XML-Informationsstruktur erscheinen, wiedergewonnen werden können. Dementsprechend muß der Autor mit Musterthemenpunktberichten der Art beliefert werden, die in Teil 2 von Anhang F gezeigt ist, für jeden einzelnen der verfügbaren Analysatoren und jede für einzelne der Themenpunkte, die jeder derartige Analysator in der Lage ist, zu berichten. Diese Informationen ermöglichen es dem Schablonen- und Regel-Autor, einen Regelsatz vorzubringen, der die Informationen der Themenpunkt-Datenbank 112 analysieren und zusammenfassen kann, sowie detaillierte Informationen aus derselben aufnehmen kann und dieselben in jeglichen beliebigen Typ von Bericht eingliedern kann, der liebigen Typ von Bericht eingliedern kann, der notwendig oder wünschenswert sein könnte.
• Unter Verwendung dieser Informationen betreffend die Namen von Variablen entwickelt der Autor bei Schritt 1604 einen Regelsatz, der das Gesamtverhalten eines Unternehmens 300 überprüfen kann. Der Autor muß offensichtlich ein erfahrener, technischer Unternehmensexperte sein, der weiß, nach was er in den Themenpunktinformationen suchen muß, die durch eine große Computerunternehmensinstallation erzeugt werden, und der weiß, wie Regeln geschrieben werden, die dieselben Typen von Analysen ausführen, die der Experte/die Expertin selbst persönlich durchgeführt hätten, wären sie in der Lage gewesen, sich zu dem Ort des Unternehmens zu begeben.
• Nach dem Entwickeln von Regeln, um die Berichterzeugung zu steuern, bewegt sich der Experte bei Schritt 1606 weiter, um eine zusammenfassende Verwaltungsberichtschablone zu entwickeln, die in lesbarer Form den allgemeinen Zustand des Systems angibt. Dieser Bericht sollte idealerweise von Laien lesbar sein, wie z. B. den obersten Betriebsmitgliedern der Firma, die das Unternehmen besitzt und verwaltet. Er sollte allgemeine Problem herausstellen, und sollte dann Beispiele darüber geben, warum diese Probleme die Aufmerksamkeit der Verwaltung verdienen. Er kann dann allgemeine Übersichtsvorschläge darüber liefern, wie diese Probleme verwaltet werden sollten. In diesen Bericht ist deutlich die Erfahrung eines Experten für Entwurf und Verwaltung des Unternehmenssystems eingebaut. Er kann Kostenschätzungen für Konfigurationsänderungen vorlegen, die das Unternehmensverhalten verbessern können.
• Für den technischen Verwalter entwickelt der Experte eine unterschiedliche Schablone, die alle kritischen, technischen Punkte in zusammenfassender Form auflistet, ihren Bedenklichkeitsgrad angibt und dann kurze Erklärungen und Kostenschätzungen für ihre Korrektur vorlegen. Dieser Bericht umfaßt keine Hintergrunderklärungen, die der Laien- Verwalter benötigt. Er wird viel kürzer und prägnanter sein, und umfaßt ferner eine Ebene von technischen Details, die in dem vorherigen Bericht weggelassen wurde.
• Bei Schritt 1610 kann eine zusätzliche Schablone entwickelt werden, die eine vollständig detaillierte Präsentation aller spezifischen Themenpunkte für jeden der Knoten oder der Gruppe von Knoten erzeugt, die analysiert wurden. Zusätzlich zu der Angabe von Themenpunkten, die direkt von den Analysatoren erhalten wurden, kann dieser Bericht Gründe darüber umfassen, warum gewissen Themenpunkten begegnet werden muss, Kosten von Implementierungsänderungen und möglicherweise eine detaillierte Erklärung dieser Themenpunkte, die durch eine Hypertext-Verbindung zu anderen Dokumenten sein kann. Bruchstücke der tatsächlichen Sammler- Konfigurationsinformationen können nach Bedarf umfaßt sein, um einen Themenpunkt zu klären. Wie sowohl in Teil 1 als auch 2 von Anhang F dargestellt ist, können solche Bruchstücke leicht in die XML-Ausgabe eines Analysators integriert sein, und können dann nach außen geleitet und in den technischen Bericht aufgenommen werden, um den technischen Experten bei dem Verstehen von jeglichen Themenpunkten zu helfen, denen durch die Berichterzeugungsregeln nicht begegnet wurde.
• Bei Schritt 1612 ist es schließlich wünschenswert, eine Vielzahl von Master- bzw. Haupt-Berichtschablonen zu entwickeln, die für unterschiedliche Zielgruppen und Geschäftsbedürfnisse gedacht sind, die verschiedene Kombinationen der soeben beschriebenen Bericht umfassen, sowie mögliche zusätzliche einleitende und erklärende Berichte, die über eine Hyperlink mit Hintergrundinformationen verbunden sind. Somit kann ein einzelner Bericht mehrere Teile enthalten, die für unterschiedliche Einzelpersonen bestimmt sind und kann als eine Einheit zu den Inhabern und Verwaltern eines Unternehmens geliefert und für dieselben gedruckt werden kann.
• Der Berichterzeugungsprozeß, ausgelöst durch den Prüfer 813, wird durch den Berichterzeuger 206 ausgeführt, der bei dem bevorzugten Ausführungsbeispiel der Erfindung das Programm "Crystal Reports" ist. Bezugnehmend nun auf Fig. 19 und 20 empfängt der Berichterzeuger 206 eine Liste von Berichten von der Bewertungsaufgabe 814 und beginnt durch Aufrufen der Schablonen und Regeln aus der Bericht- Schablonen- und Regeln-Datenbank 204, die für das Erzeugen der gewünschten Berichte bei Schritt 1902 benötigt werden. Als nächstes geht der Berichterzeuger 206 bei Schritt 1904 zu der (XML)-Themenpunkt-Datenbank 112 und erhält die notwendigen XML-Themenpunktinformationen, die durch die Analysatoren 110 erzeugt wurden, und überträgt den Inhalt dieser Informationen in eine Microsoft-Access-Datenbank für einen bequemen Zugriff und eine Wiedergewinnung durch den Berichterzeuger 206. Der Berichterzeuger 206 erhält von dem Aufgabendefinitionssystem 810 ferner zusätzliche Informationen über diese Prüfung, ihren Autor, usw., und überträgt diese Informationen in die Access-Datenbank, für ein bequemes Wiedergewinnen durch den Berichterzeuger 206. Als nächstes kann der Berichterzeuger 206 bei Schritt 1908 wieder auf Anweisung des Aufgabendefinitionssystems 810 hin direkt von der Verfolger-Datenbank 106 Hintergrundinformationen über das spezifische Unternehmen und die Knoten erhalten, die für eine Aufnahme in die Berichte überprüft werden, und kann diese Informationen zusammen mit dem Rest in die Access-Datenbank plazieren. Zusätzlich dazu kann die Liste von Unternehmen, die Liste von Knoten und die Liste von Analysatoren in der Bewertungsaufgabe 814 der Access- Datenbank hinzugefügt werden und an einem geeigneten Platz in einen Bericht aufgenommen werden.
• Bei Schritt 1910 arbeitet das Crystal-Reports-Programm schließlich im Stapelmodus als ein Schablonen- und Regel- Prozessor, der durch die Schablonen und Regeln und durch den Inhalt der Access-Datenbank gesteuert wird, um alle notwendigen und erforderlichen Berichte zu erzeugen. Dies könnte ferner ein nicht auf Papier basierender Bericht sein, wie z. B. ein Arbeitsfluß-Verwaltungssystem.
DER ANALYSATORHARNISCH
• Der Analysatorharnisch wird aus drei unterschiedlichen Perspektiven beschrieben. Als erstes stellt Fig. 15 im Programm-Flußdiagrammform die Schritte dar, die durch den Analysatorharnisch 806 und die Analysatoren 110 ausgeführt werden, um in allgemeinen Begriffen darzustellen, wie die individuellen Analysatoren aufgerufen werden, um Informationen zu verarbeiten, die durch die einzelnen Knoten geliefert werden (Fig. 15 adressiert die Aufgabe des Beschreibens der komplexen Interaktionen nicht, die zwischen den einzelnen Analysatoren und dem Analysatorharnisch 806 auftreten). Als zweites stellt Fig. 21 ein Softwareelement- Blockdiagramm dar, das das genaue Verhältnis darstellt, das zwischen den drei Teilkomponenten 2102, 2104, 2106, der Analysatorharnisch 806 und den verschiedenen Typen von Analysatoren 2110, 2112 und 2114 besteht, die bei dem vorliegenden Ausführungsbeispiel der Erfindung unterstützt werden. Schließlich stellen die Fig. 20-24 ein Flußdiagramm der Schritte dar, die durch die Komponenten des Analysatorharnisch 806 ausgeführt werden, die in Fig. 21 dargestellt sind, wobei dem Themenpunkt begegnet wird, der durch Fig. 15 nicht begegnet wurde.
• Bezugnehmend nun auf Fig. 15 sind die Informationsverarbeitungsoperationen in einem herkömmlichen Software- Flußdiagramm gezeigt, die durch den Analysatorharnisch 806 ausgeführt werden. Der Prozeß beginnt bei 1502, wenn das Aufgabendefinitionssystem 810 den Analysatorharnisch 806 die Bewertungsaufgabe 814 übergibt, die die Unternehmen, Knoten und Analysen auflistet, die durchgeführt werden müssen. Dies ermöglicht es dem Analysatorharnisch 806, einen Dreifachsatz von verschachtelten Schleifen einzurichten, wie gezeigt ist, der sich bei Schritt 1522zurückverzweigen, nachdem jeder Knoten verarbeitet wurde, nachdem jeder Analysator gegen jeden Knoten verarbeitet wurde, und nachdem jedes Unternehmen verarbeitet wurde.
• Der Gesamtprozeß beginnt bei Schritt 1504, bei dem ein erstes Unternehmen 300 ausgewählt wird. Dann wird bei Schritt 1506 ein erster Analysator 110 ausgewählt. Als nächstes werden bei Schritt 1508 die Definitionen des Analysators und Informationen darüber, wie dieselben ausgeführt werden sollen (siehe Anhänge B und C) aus der Analysator-Datenbank 804 zusammen mit der Schablone (Anhang D) wiedergewonnen, die Themenpunktmeldungen für den Analysator enthält. Als nächstes werden bei Schritt 1510 die Namen der Sammler, die durch diesen Analysator in dem XML-Descriptor (Anhang C) des Analysators gekennzeichnet wurden, als Anzeige dafür gesammelt, woher die Eingangsinformationen kommen müssen. Bei Schritt 1512, wenn der Analysator im Lauf der Zeit eine Tendenz berechnet, wird ebenfalls ein gekennzeichneter Satz von Zeiten und Daten oder ein Bereich von Zeiten und Daten aufgenommen.
• Die Programmsteuerung fährt dann bei Schritt 1514 fort, und die Schritte 1514 bis 1522 werden für jeden Knoten 302, etc. wiederholt, der durch diesen bestimmten Analysator analysiert werden soll.
• Bei Schritt 1516 werden die Namen der bezeichneten Sammlerberichtdateien für diesen bestimmten Knoten aus der Verfolger-Datenbank 106 wiedergewonnen und werden als Eingangsargumente für die Ausführung des Analysators aufgelistet. Dann wird bei Schritt 1518 der Analysatorcode in dem Kontext der Sammlerberichte ausgeführt, die in dieser Eingangsargumentliste bereitgestellt sind. Bei Schritt 1520 erzeugt der Analysator kleine XML-Berichte, wenn jegliche Themenpunkte oder Fehler entstehen, und sendet dieselben zurück zu dem Analysatorharnisch 806, der dieselben mit Informationen, wie z. B. den Namen des Knotens und den Schablonenthemenpunkttext vergrößert (siehe Anhang D). Das Durchlaufen der Schleife fährt dann von Schritt 1522 fort, bis alle Knoten durch diesen Analysator verarbeitet wurden.
• Als nächstes bewegt sich der Analysatorharnisch 806 zu dem nächsten Analysator und wiederholt die Schritte 1506 bis 1522, bis alle der Analysatoren verarbeitet wurden. Sie bewegt sich dann zu dem nächsten Unternehmen und wiederholt die Schritte 1504 bis 1522, bis alle der Unternehmen verarbeitet wurden, falls mehr als eines vorhanden ist.
• Wenn das Verarbeiten abgeschlossen ist wird bei Schritt 1524 der Analysator-XML-Ausgangsbericht als eine Datei in der (XML)-Themenpunkt-Datenbank 112 gespeichert.
• Bezugnehmend nun auf Fig. 21 liegt eine detaillierte Darstellung der Struktur des Analysatorharnisch 806 vor, die dessen Verhältnis zu den Analysatoren darstellt und ferner darstellt, wie die unterschiedlichen Typen von Analysatoren verarbeitet werden. Diese Figur wird in dem Kontext des Flußdiagramms der Analysatorharnisch-Operation erörtert, die in den Fig. 22-24 vorliegt.
• In Fig. 21 ist der Analysatorharnisch 806 derart gezeigt, daß er drei Hauptkomponenten aufweist. Eine Analysator- Ladevorrichtung 2102 ist die primäre Komponente, die das Laden und Ausführen der Analysatoren während dem Verarbeiten der Konfigurationsinformationen verwaltet. Diese Analysator-Ladevorrichtung 2102 ruft einen Analysator-Descriptor 2104 auf, um die XML-Informationen für einen bestimmten Analysator 110 aus der Analysator-Datenbank 804 zu erhalten, und um diese Informationen in eine Datenbank zu stellen, von der aus die Analysator-Ladevorrichtung leichten Zugriff zu denselben hat, während sie bestimmt, wie ein bestimmter Analysator 110 in eine Rahmenstruktur verkabelt und eingekapselt werden soll, der ausgeführt werden soll. Die Analysator-Ladevorrichtung 2102 ruft ferner einen Argumentverwalter 2106 auf, um in die Verfolger-Datenbank 106 zu reichen, um Sammler-Berichte 2108 zu finden und zu arrangieren, daß diese Berichte oder die Dateinamen für diese Berichte als eingehende Argumente an die Analysatoren 110 weitergeleitet werden, wenn dieselben durch die Analysator- Ladevorrichtung 2102 ausgeführt werden. Die Ladevorrichtung 2102, die in "Java" geschrieben ist, führt direkt mit "Java" ausführbare Analysatoren 2110 aus. Sie ruft ein "Shell"-Dienstprogramm eines Standardbetriebssystems auf, um die Analysatoren 2112 auszuführen, die in den Programmiersprachen "C" oder "C++" geschrieben sind. Sie ruft ferner einen Betriebssystem-Interpretierer auf, um einen Analysator zu interpretieren und auszuführen, der in "Perl" oder "Kshell" oder einen anderen interpretierenden Sprache 2114 geschrieben ist. Die Ausgabe eines Analysators ist bei 2124 als eine XML-Ausgabe gezeigt, die durch spezielle XML- Ausgabe-Unterroutinen 2116 erzeugt wird, die durch den Analysator 110 aufgerufen werden, unabhängig von dessen Form, um XML-"Themenpunkte"-Ausgabemeldungen und ferner Fehlerausgabemeldungen zu erzeugen. Die Ausgabe 2124 umfaßt keine Identifikation des relevanten Knotens, weder umfaßt es Textinformationen über einen Themenpunkt, da diese Informationen für die Analysatoren 110 nicht verfügbar sind, wenn dieselben ausgeführt werden. Dementsprechend akzeptiert die Analysator-Ladevorrichtung 2102 die XML-Ausgabe der Analysatoren 2124 und erzeugt einen erweiterten XML-Bericht 2126, der die themenpunktdefinierende Sprache umfaßt, die aus den Analysator-Themenpunktschablonen 2122 genommen werden, sowie die Identifikation des Knotens, der verarbeitet wird, und ferner den Namen der Bewertungsaufgabe 814. Dies ist aus Anhang F ersichtlich, bei dem die XML-Ausgabe eines Analysators 110 in Teil 1 gezeigt ist, und der XML-Bericht 2126 der Analysator-Ladevorrichtung 2102 für den einfachen Analysator in Teil 2 gezeigt ist, der durch diese Patentanmeldung als ein exemplarischer Analysator verwendet wurde.
• Bezugnehmend nun auf die Fig. 22-24 wird der Prozeß des Analysatorharnischs 806, der einen Analysator 110 ausführt erörtert. Bei Schritt 2202 empfängt die Analysator- Ladevorrichtung 2102 (Fig. 21) den Namen eines Analysators 110, der Laden und Verarbeiten muß. Dies entspricht im allgemeinen dem Schritt 1506, der in Fig. 15 gezeigt ist. Die Ladevorrichtung leitet den Namen an ein Analysator- Descriptorprogramm 2104 weiter.
• Bei Schritt 2204 lokalisiert und liest das Analysator- Descriptorprogramm 2104 in der entsprechenden XML-Datenbank den Analysator (siehe Anhang C) und erzeugt dadurch in seiner eigenen, inneren Informationsstruktur ein Analysator- Descriptorobjekt, das zurück zu der Analysator- Ladevorrichtung 2102 geleitet wird.
• Bei Schritt 2206 ruft die Ladevorrichtung 2102 als nächstes den Argumentverwalter 2106 auf, um aus der Verfolger- Datenbank 106 die geeigneten Sammler-Berichte für die Sammler wiederzugewinnen, die in dem Descriptor-Objekt für einen bestimmten Knoten gekennzeichnet sind (gekennzeichnet bei Schritt 1514 von Fig. 15). Die Sammler-Berichte 2108 werden nach Dateinamen identifiziert, und diese Dateinamen sind der Reihe nach als eine Eingangsargumentliste für den Analysator 110 organisiert, um diese Dateien der Reihe nach zu lesen und dieselben zu verarbeiten. Die Dateinamen werden zurück an die Ladevorrichtung 2102 geleitet.
• Abschließend ruft die Analysator-Ladevorrichtung 2102 bei Schritt 2208 eine geeignete Entität auf, um den Analysator 110 gemäß der Eigenschaft des Analysators auszuführen, wobei die Liste von Dateinamen als Eingangsargument weitergeleitet wird.
• Bezugnehmend auf Fig. 23 oben wird auf die XML- Analysatorinformationen, die nun innerhalb des Descriptorobjekts vorliegen jetzt bei einem Versuch Bezug genommen, um zu bestimmen, welche Art von Analysator zur Hand ist. Wenn bei Schritt 2210 der Analysator in "Java" geschrieben ist, dann wird derselbe einfach als eine "Java"- Unterroutine aufgerufen und dieselbe wird bei 2212 zu der Eingangsliste von Dateinamen als ein Eingangsargument geschickt. Wenn der Analysator nicht in "Java" geschrieben ist, dann testet Schritt 2214 um zu sehen, ob derselbe interpretierbar ist. Wenn ja, dann wird bei Schritt 2218 ein geeigneter Interpretierer für "Perl" oder "Kshell" betrieben, und die Eingangsargumentliste von Dateinamen wird wiederum als Eingabe für die Ausführung des Analysators 110 zu dem Interpretierer weitergeleitet. Wenn der Analysator schließlich nicht interpretierbar aber ausführbar ist, wie in dem Fall eines kompilierten "C" -oder "C++"-Programms, dann wird bei 2216 ein "Shell"-Dienstprogramm eines Betriebssystems aufgerufen, um das ausführbare Analysatorprogramm zu starten, wobei demselben wiederum die Liste von Dateinamen als Eingangsargument an das ausführende Programm bereitgestellt wird.
• Derart durch den Harnisch 806 in einer Rahmenstruktur eingehüllt, die Eingangssammler-Konfigurationsinformationsdateien umfaßt, die von dem geeigneten Knoten 302 erhalten wurden, führt der Analysator 110 seine Tests durch und prüft dadurch, um zu sehen, ob jegliche Themenpunktberichte erzeugt werden müssen. Wenn ja, oder wenn jegliche Fehler auftreten, ruft der Analysator spezielle Routinen auf 2116, die die Analysatorausgabe als XML-Strukturen normalisieren, wie z. B. die, die in Teil 1 von Anhang F gezeigt ist.
• Die Argumente, die durch die Ausgangsroutine 2116 geleitet werden, umfassen:
  
  die Themenpunkt-ID-Nummer;
  Null oder mehr Argumente für ein späteres Einfügen in die Analysatorthemenpunktschablonen 2122; und
  einen optionalen Bruchteil, der aus einem Sammler- Bericht genommen wird, oder eine erklärende Textzeichenfolge, oder eine Nullzeichenfolge.
  
• Bei Schritt 2222 wird die Themenpunktliste- oder Fehlerliste-XML-Ausgabe (siehe Muster 1 in Anhang F) erfaßt und wird an die Analysator-Ladevorrichtung 2102 in der Form einer XML-Ausgabe 2124 zurückgesendet. Bei Schritt 2222 erweitert die Analysator-Ladevorrichtung 2102 die Größe dieser XML- Ausgabe durch Hinzufügen von Informationen zu demselben, die den Namen des Knoten 302 definieren, aus dem die Sammler-Konfigurationsinformationen kamen, der Name der Bewertungsaufgabe 814, die durch den Prüfer 813 gestartet wird und andere derartige Hintergrundinformationen. Die Analysator-Ladevorrichtung 2102 gewinnt ferner die Analysator- Themenpunktschablonen für diesen Analysator aus der Analysator-Datenbank 804 wieder 2122 (Anhang D), und aus diesem Satz von Schablonen gewinnt dieselbe nach Anzahl die bestimmte Textschablone wieder, die den bestimmten Themenpunkt identifiziert und derselben entspricht, die die XML- Ausgabe ausgelöst hat. Wenn jegliche variablen Platzhalter in dieser Textschablone vorhanden sind, betrachtet die Analysator-Ladevorrichtung 2102 die XML-Ausgabe 2124, um zu sehen, welcher Wert an diesem Punkt eingefügt werden muß, und dieselbe fügt den Wert in die Schablone ein, wobei dieselbe in eine Themenpunkt-Meldung umgewandelt wird. Die Analysator-Ladevorrichtung 2102 erzeugt dann ein neues Segment für einen wachsenden Ausgang-XML-Bericht 2126, der alle der oben hinzugefügten Informationen umfaßt, die der Analysator-XML-Ausgabe hinzugefügt wurden 2124. Ein Muster eines solchen Berichts kann in Teil 2 von Anhang F gesehen werden.
• Die Analysator-Ladevorrichtung 2102 fährt dann mit den nächsten Knoten bei Schritt 2224 fort und macht weiter, bis alle Knoten durch diesen bestimmten Analysator 110 analysiert wurden. Dann fährt dieselbe bei Schritt 2226 mit dem nächsten Analysator 110 fort und macht dadurch weiter, bis alle der Analysatoren gegen alle Knoten verarbeitet wurden. Der XML-Bericht 2126 wird dann in der (XML)-Themenpunkt- Datenbank 112 gespeichert, wo derselbe für den Berichterzeuger 206 verfügbar gemacht wird, wie erklärt wurde.
HIERARCHISCHE ORGANISATION VON ANALYSATOR-XML- INFORMATIONEN 2118
• Ein Analysator besteht wie oben beschrieben aus vier Teilen: Einer Textbeschreibung des Analysators und dessen Funktionen (siehe Anhang A), dem Quellcode des Analysators 2120 (siehe Anhang B), dem Text der Schablone 2122, der die Themenpunkte eines Analysators definiert (siehe Anhang D) und einer XML-Datei, die für den Analysatorharnisch 806 definiert, wie der Analysator verarbeitet werden muß und welche Informationen er erfordert.
• Bei einem unterschiedlichen Ausführungsbeispiel der Erfindung, das oben vorgeschlagen wurde, das aber nicht umfassend beschrieben wurde, können die Analysatoren 110 hierarchisch organisiert sein, um verschiedenen breiten und engen Anordnungen oder Sätzen verwalteter Elemente innerhalb eines gegebenen Unternehmens zu entsprechen. In Fig. 10 z. B., wo die Bewertungsaufgaben definiert sind, sind die Bewertungstypen in Allgemein, Hardware/Betriebs-System, Netzwerkfunktionen, Datei-Verwaltung und -Speicherung, usw. unterteilt. Diese Bewertungen entsprechen jeweils einem bestimmten Satz oder einer Sammlung von verwalteten Elementen. Diese Sätze können noch weiter unterteilt werden. Wie z. B. in Fig. 25 bei 2502 gezeigt ist, kann das Dateisystem in logische Volumen, Dateisystem-Verwendungsanalysen und Logisches-Volumen-Verwaltung aufgeteilt werden. Auf ähnliche Weise kann die Hardware in einen Speicher, eine CPU und andere Kategorien unterteilt werden. Netzwerkfunktionen können auf ähnliche Weise unterteilt werden.
• Um diese Typen von Bewertungsprüfungen der Unterteile eines großen Systems zu ermöglichen, kann eine XML-Steuerdatei erzeugt werden, die an ihrer Basis oder an den niedrigsten Elementen alle der Verbindungen zu den Analysator-XML- Definitionen anderer Unterkomponenten einer Prüfung umfaßt, die in der Analysator-Datenbank 804 enthalten ist. Diese XML-Datei könnte als ihre Hauptüberschrift "Unternehmen" oder einen ähnlichen allgemeinen Titel umfassen; und dieselbe könnte dann Verbindungen zu den XML-Dateien für sekundäre Überschriften haben, wie z. B. "Betriebssystem", "Dateisystem", usw. Dann könnte jeder diese Unterüberschriften wiederum zu weiteren Unter-Überschriften verbunden sein, usw., derart, daß viele unterschiedliche Möglichkeiten für Prüfungen durch verschiedene Sammlungen verwalteter Elemente des Unternehmens in Erwägung gezogen werden können. Diese XML-Datei, die symbolisch in Anhang G angezeigt ist, wird dann ein Haupt-Tool zum Steuern der Operationen des Analysatorharnisch 806, wodurch verursacht wird, daß derselbe eine bestimmte Prüfung an einer bestimmten Sammlung von verwalteten Elementen durchführt. Es werden durch die Rahmenstruktur keine Änderungen benötigt, um diese Mehrfachkombinationen von Bewertungen zu handhaben, wenn dies implementiert ist. Die einzigen Änderungen, die benötigt werden, involvieren den Satz von Analysator- /Überschrift-Definitionen, die in den XML-Dateien enthalten sind, die ein- und ausgetauscht werden können, ohne die Rahmenstruktur zu beeinflussen.
• Die tatsächliche Hierarchie wird eigentlich durch die Verbindungen in der Bewertungs-Typ-XML-Datei zu den Komponenten des Betriebssystems, Dateisystems, . . . erzeugt, die wiederum Verbindungen zu ihren Unterkomponenten haben, bis die Verbindung zu dem tatsächlichen Analysator erzeugt ist - Siehe Anhang H.
• Dementsprechend erreicht man die konzeptionelle Bewertungs- XML-Hierarchie, die bei 2502 in Fig. 25 mit kleinen Änderungen an dem aktuellen Harnisch gezeigt ist. Dann wird in Fig. 26 das Aufgabendefinitionssystem 814 derart modifiziert, daß bei Schritt 2602 (der den Schritt 1002 in Fig. 10 ersetzt) nur ein gewünschter Bewertungstyp in der Umrißstruktur spezifiziert wird, die durch die große XML- Struktur 2502 definiert ist, die in Fig. 25 gezeigt ist.
• Dieser Aufgabenbewertungstyp entspricht einem Satz von verwalteten Elementen, die einem Unterteil der XML-Hierarchie entsprechen, die in Fig. 25 gezeigt ist, und die alle Analysatoren 110 für den Satz von verwalteten Elementen enthält. Es wird darauf hingewiesen, daß die XML-Daten 2118 (siehe Anhang C) für den "Datenträgerverwendung"-Analysator unter "Dateisystem", "Logische Volumen" und "Dateisystem- Verwendungsanalysen" in der exemplarischen XML-Struktur erscheinen, die bei 2502 in Fig. 25 symbolisch gezeigt ist. Bei Schritt 2604 (der den Schritt 1502 in Fig. 15 ersetzt) wird die Liste von Unternehmen und Knoten zusammen mit der größeren XML-Struktur 2502 einfach an den Analysatorharnisch 806 weitergeleitet, wobei die Struktur als eine Unterstruktur die Liste von Analysatoren enthält, die gemäß Fig. 25 arbeiten müssen, die den Abschnitt der XML-Struktur in Fig. 25 enthalten, die der Prüfer für eine Ausführung gekennzeichnet hat. Der Analysatorharnisch 806 führt diese Bewertungen dann automatisch aus und deckt dabei soviel oder sowenig der System-Hardware und -Software ab, wie der Prüfer in jeglicher gegebenen Analyseoperation abgedeckt haben will, umfassend und dauerhaft gesteuert durch die XML-Struktur von Fig. 25 und durch den Abschnitt dieser Struktur, den der Prüfer für die Ausführung gekennzeichnet hat.
BESCHREIBUNG DER ANALYSATOREN
• Zusätzlich zu dem "Diskettenverwendung"-Analysator, der als exemplarischer Analysator durch diese Erklärung hindurch verwendet wurde, umfaßt das bevorzugte Ausführungsbeispiel der Erfindung eine Anzahl von zusätzlichen Analysatoren, die nachfolgend als Beispiele der vielen möglichen Analysatoren beschrieben werden, die erzeugt werden können. Offensichtlich können und sollten viele andere Typen von Analysatoren entwickelt werden.
EINZELNE-FEHLERPUNKTE-ANALYSATOR
• Dieser Analysator testet, um sicher zu stellen, daß sowohl ein primärer Bootdatenträger als auch ein alternativer Bootdatenträger vorhanden sind. Ferner testet dieser Analysator, um sicher zu stellen, daß der primäre Bootdatenträger und den alternativen Bootdatenträger nicht auf dem gleichen Hardware-Weg installiert sind. Somit wird ein Themenpunkt markiert, wenn eine primärer Datenträger ohne einen alternativen Datenträger installiert ist. Ferner wird eine Themenpunkt markiert, wenn der primäre und der alternative Bootdatenträger auf demselben Hardware-Weg installiert sind.
MC/SERVICEGUARD-ZEITGEBUNGSPARAMETER-ANALYSATOR
• Dieser Analysator inspiziert die MC/Serviceguard- Zeitgebungsparameter nach Genauigkeit und Unterstützbarkeit. Die folgenden Themenpunkte werden markiert: Ein Themenpunkt wird markiert, wenn der Wert von NODE_TIMEOUT auf den voreingestellten Wert eingestellt ist, der üblicherweise zwei Sekunden ist; ein Themenpunkt wird markiert, wenn der NETWORK_POLLING-Parameter konfiguriert ist, um größer oder gleich dem NODE_TIMEOUT-Parameter zu sein; ein Themenpunkt wird markiert, wenn jeglicher der Werte von HEART- BEAT_INTERVAL, NODE_TIMEOUT, AUTO_START_TIMEOUT und NETWORK_POLLING_INTERVAL unter einen vorbestimmten Wert eingestellt ist, wobei der vorbestimmte Wert üblicherweise eine Zeit von weniger oder gleich einer Sekunde ist; und ein Themenpunkt wird markiert, wenn der Wert von NODE_TIMEOUT auf weniger eingestellt ist, als mindestens zweimal der Wert des HEARTBEAT_INTERVAL-Parameters.
MC/SERVICEGUARD-AUSGABE-ANALYSATOR
• Dieser Analysator testet die installierte MC/Serviceguard- Version an allen Knoten und stellt sicher, daß die neueste Version für eine bestimmte Ausgabe von HP-UX (Version von Unix von Hewlett-Packard, Inc.) installiert ist, und daß dieselbe die gleiche auf allen Knoten in der Gruppe ist. Ein Themenpunkt wird markiert, wenn scheint, daß MC/Serviceguard nicht installiert ist, wenn eine neuere Version von MC/Serviceguard für das Betriebssystem verfügbar ist, oder wenn Knoten in der Gruppe eine unterschiedliche MC/Serviceguard-Ausgabe betreibt als die anderen.
MC/SERVICEGUARD-PAKETKONFIGURATION-ANALYSATOR
• Dieser Analysator testet die Konfiguration der Pakete innerhalb einer MC/Serviceguard-Gruppe. Ein Themenpunkt wird markiert, wenn das voreingestellte Paket-Unterverzeichnis nicht existiert, wenn die Paketschaltung deaktiviert ist, oder wenn separate Paketsteuerung-Start- und Halte-Scripts für das Paket existieren.
MC/SERVICEGUARD-HINTERGRUNDROUTINE-TESTER
• Dieser Analysator testet, um zu bestimmen, ob die MC/Serviceguard-Hintergrundroutinen) laufen oder nicht. Unter Verwendung einer Hintergrundroutine kann ein Programm einfach Daten an ein kleineres Programm abgeben und eine andere Arbeit ausführen. Wo die MC/Serviceguard- Hintergrundroutine "cmcld" nicht auf dem Knoten in dem Gruppensystem läuft, wird ein Themenpunkt markiert.
MC/SERVICEGUARD-GRUPPE-STATUS
• Dieser Analysator testet den MC/Serviceguard-Gruppenstatus, -Knotenstatus und -Paketstatus. Ein Themenpunkt wird markiert, wenn: Die Gruppe abgeschaltet ist, die Gruppe auf einem Untersatz der Knoten läuft, eines oder mehrere Pakete der Gruppe nicht laufen, eine globale Paketschaltung deaktiviert ist, das Knotenschalten bei einem Paket für einen oder mehrere Knoten deaktiviert ist, ein Paket nicht auf dessen primärem Knoten läuft, oder wenn kein alternativer Knoten verfügbar ist, auf den das Paket geschaltet werden kann.
MC/SERVICEGUARD-GRUPPENKONFIGURATIONS-ANALYSATOR
• Dieser Analysator testet die Konfiguration der MC/Serviceguard-Gruppe auf richtige Konfiguration. Ein Themenpunkt wird markiert, wenn: Die ASCII(American Standard Code for Information Interchange)-Konfigurationsdatei nicht an der voreingestellten Position und/oder mit dem voreingestellten Namen gefunden wird, wenn die ASCII- Konfigurationsdatei nicht mit der binären Gruppenkonfigurationsdatei übereinstimmt, wenn die ASCII-Gruppenkonfigurationsdatei nicht auf allen Knoten in der Gruppe die gleiche ist, wenn die Binäre-Gruppe-Konfiguration nicht auf einem oder mehreren Knoten in der Gruppe existiert, wenn die Binäre-Gruppe-Konfigurationsdatei nicht auf allen Knoten in der Gruppe die gleiche ist, oder wenn eine inkorrekte Inhaberschaft und/oder Erlaubnis auf der Binäre-Gruppe- Konfigurationsdatei existiert.
WURZELSPIEGEL-ANALYSATOR
• Dieser Analysator verifiziert, daß das Wurzelvolumen mindestens einmal wiedergespiegelt wird, stellt sicher, daß jeder Spiegel bootbar ist, stellt sicher, daß ein Eintrag in /stand/bootconf für jeden Spiegel existiert, und testet nach einzelnen Fehlerpunkten in Bezug auf die Bootdatenträger. Ein Themenpunkt wird markiert, wenn: Kein Spiegel für das logische Wurzelvolumen gefunden wird, die Bootspiegelvorrichtung aus /stand/bootconf fehlt, ein nichtbootbarer Spiegel des Wurzel-Treibers vorhanden ist, ein primärer Bootdatenträger ohne einen alternativen Datenträger installiert ist, oder der primäre und der alternative Bootdatenträger auf dem selben Hardwareweg installiert sind.
PROZESSOR-ANALYSATOR
• Dieser Analysator extrahiert Informationen aus den CPU(Central Processing Unit = zentrale Verarbeitungseinheit)- Hardwareprotokollen von jedem Prozessor, der in dem System installiert ist. Angesammelte, CPU-spezifische Informationen, umfassen die Anzahl installierter Prozessoren, PDC(Processor Dependent Code = prozessorabhängiger Code) - Revisionsebene, die Hardwaremodelnummer (für den Bericht übersetzt), die Prozessorchiprevision und die Schlitznummer, in der der/die Prozessoren installiert ist/sind. Zusätzlich dazu sammelt der Analysator HPMC(High Priority Machine Check = Hochprioriäts-Maschinentest)-Fehlerinformationen an, spezifisch für die CPU, den Speicher und die I/O(Input/Output = Eingabe/Ausgabe)-Fehlerprotokolle. Ferner identifiziert der Analysator, daß das Schnellboot- Statusflag des Prozessors eingestellt wurde, das anzeigt, daß der Speicherselbsttest während des Systemselbsttestabschnitts des PDC-Bootcodes deaktiviert wurde. Eine Prozessorchiprevision wird erhalten, und kann verwendet werden, um proaktiv Prozessoren zu identifizieren, die Klasseproblemen und/oder bekannten Fehlern zugeordnet sind. Ein Themenpunkt wird markiert, wenn: Die Prozessor-PDC- Revisionsebene nicht die neueste, unterstützte Revision ist, wenn ein gültiger HPMC in den Hardwareprotokollen existiert, wenn ein gültiger Speicherfehler in den Hardwareprotokollen existiert, wenn ein gültiger, fataler I/O- Fehler in den Hardwareprotokollen existiert, oder wenn die Schnellbootflag eingestellt wurde.
SPEICHER-ANALYSATOR
• Dieser Analysator testet das Vorhandensein von Einzel- und Doppel-Bit-Fehlern in den Hardwareprotokollen und verifiziert ferner die Anzahl verfügbarer Einträge in die Seitenzuordnungsaufhebungstabelle (PDT = page deallocation table). Ein Themenpunkt wird üblicherweise markiert, wenn:
  Ein Einzel-Bit-Speicherfehler existiert und dessen Zählwert größer oder gleich 1000 ist, wenn ein Doppel-Bit- Speicherfehler existiert, und dessen Zählwert größer oder gleich 1 ist, oder wenn die Anzahl von verwendeten PDT- Einträgen 50% der PDT-Gesamtgröße überschreitet, die standardmäßig auf einen maximalen Eintragswert von 50 eingestellt ist.
LVM GENERAL
• Dieser Analysator führt grundlegende Tests an der LVM(Logical Volume Management = Logisches-Volumen-Verwaltung)- Konfiguration durch, wie z. B. Vergleichen des Inhalts von /etc/lvmtab mit der Ausgabe der lmv(logical volume management)-Befehle, um Volumengruppen zu finden, oder physische Volumen die nicht aktiviert sind, oder Inkohärenzen. Er kann ferner Basistests für jede Volumengruppe, jedes physische Volumen oder logische Volumen durchführen. Ein Themenpunkt wird markiert, wenn: Nicht alle in lvmtab (logical volume management tab = Logisches-Volumen-Verwaltung- Tabelle) aufgelisteten Volumengruppen aktiviert sind, wenn alle physischen Volumen in einer VG (Volumengruppe) momentan aktiv sind, wenn ein physisches Volumen in /etc/lvmtab fehlt, wenn eine aktivierte VG nicht in /etc/lvmtab definiert ist, wenn nicht alle in lvmtab aufgelisteten Volumengruppen aktiviert sind, oder wenn die Schlecht-Block- Verschiebung nicht auf KEINE für LV (Logisches Volumen) auf EMC(Electric Machine Control, Inc.)-Datenträger eingestellt ist.
LVLNBOOT-ANALYSATOR
• Dieser Analysator verifiziert die Daten, die durch lvlnboot berichtet werden. "lvlnboot-v" zeigt die Root-, Boot-, Swap- und Dump-lvm-Konfiguration (Swap = Umlagern; Dump = Auszug) einer LVM-aktivierten Boot-Vorrichtung an. Ein Themenpunkt wird markiert, wenn keine Speicherabzug- Vorrichtungen konfiguriert wurden. Der Analysator kann falls erwünscht ferner Boot, Root und Swap verifizieren.
KERNELINPLACE
• Dieser Analysator verifiziert, daß Standard- und Sicherungs-Kernel-Dateien vor Ort sind. Ein Themenpunkt wird markiert, wenn: Eine Standard-Kernel-Datei nicht vor Ort ist, eine Standard-Sicherungs-Kernel-Datei nicht vor Ort ist, oder ein Standard-Kernel nicht als ein Kernel identifiziert werden konnte.
KERNELCOMPARE
• Dieser Analysator vergleicht und zeigt Differenzen zwischen Kernel-Parametereinstellungen für eine Liste von Hosts an. Ein Themenpunkt wird markiert, wenn einige Kernel-Parameter unterschiedliche Werte aufweisen.
ALLGEMEINE-FEHLER-ANALYSATOR
• Dieser Analysator analysiert allgemeine Fehler und I/O- Fehlereinträge in die Befehlszeile Support Tool Manager, d. h.: CSTM-Protokolldatei. (CSTM ist eine Online- Unterstützungstool-Plattform, die unter der Steuerung des hp-ux-Betriebssystems arbeitet. Sie liefert eine automatische Konfigurationsabbildung, einen Satz von Vorrichtungsverifizierern, Ausführern, Informationsmodulen, Expertentools, Dienstprogrammen, und Firmware-Aktualisierungstools für die Systemkomponenten und die Peripheriegeräte, die auf hp-ux-Systemen installiert sind. Die I/O-Fehlereinträge sind Teil des CSTM-Informationsmoduls. Die I/O- Fehlereinträge protokollieren spezifische Vorrichtungsverhaltensinformationen für Vorrichtungs- und Systemkomponenten, die ein unnormales Betriebsverhalten aufweisen.) Der Themenpunkt wird üblicherweise markiert, wenn: Die Anzahl von nicht korrigierbaren Fehlern, die für eine DLT oder DDS-Bandlaufwerkvorrichtung protokolliert wurden größer oder gleich eins ist, wenn weniger als 30 Tage vergangen sind, seit dem Datum und der Zeit des letzten Eintrags in die formatierte Rohprotokolldatei (wenn nicht markiert, wird der Analysator abgebrochen), wenn die Anzahl von Überzeit-Einträgen (Overtemp-Einträgen) größer oder gleich eins ist, wenn die Anzahl von I/O-Fehlereinträgen für die Systemkomponenten oder Peripheriegeräte größer oder gleich zehn ist, oder wenn die Anzahl von LPMC(Low Priority Machine Check)-Einträgen größer oder gleich zehn ist. Bei einer PA-RISC-Systemarchitektur, bestehen behebbare und nichtbehebbare Hardwarefehler. Das Erfassen eines HPMC (High Priority Machine Check) durch einen PDC (Processor Dependent Code) ist ein schwerwiegender Fehler, der die weitere Ausführung von Befehlen durch die CPU-Hardware sofort stoppt. Ein LPMC ist ein behebbarer Fehler in dem Hauptspeicher von CACHE-Komponenten der CPU. Wenn ein LPMC auftritt, identifiziert eine kombinierte Interaktion zwischen einem PDC und dem hp-ux-Betriebssystem den Typ des behebbaren Fehlers, der aufgetreten ist, löst aus, daß der PDC-Code einen Hardware-Neuversuch ausführt, um kritische Daten aus der zuführenden Hardwarekomponente zu holen und das Datum bei einem Fehler wieder in die Komponente einzufügen, um das Ereignis zu protokollieren, das aufgetreten ist, und um dann wieder einen normalen Systembetrieb zu starten. Der LPMC ist daher ein Mechanismus, der einen "Hardware-Neuversuch" von bestimmten Prozessor- und Speicher-Fehlern liefert, die nicht als unbehebbar klassifiziert sind.
• Gegenwärtig ist dieser AnaLysator in der Lage, das Vorhandensein von Systemhardware-Abnormalitäten und I/O-Fehlern zu analysieren, zu erfassen und zu berichten. Die Funktionalität dieses Analysators wird in zukünftigen Ausgaben erhöht, um eine automatische Analyse zu umfassen, die Ernsthaftigkeits- und Schwellen-Pegel der detaillierten Inhalte der I/D-Fehlerprotokollinhalte ebenfalls zu umfassen.
FSTAB-ANALYSATOR
• Dieser Analysator testet die Dateisysteme in /etc/fstab nach Problemen und testet, ob dieselben richtig konfiguriert sind. Ein Themenpunkt wird markiert, wenn: Ein Dateisystem, das in /etc/fstab aufgelistet ist, nicht befestigt ist, wenn ein Dateisystem befestigt ist, das nicht in der /etc/fstab-Datei umfaßt ist, wenn ein Konflikt in der Dateisystem-Befestigungsreihenfolge besteht, oder wenn ein CDFS(CD-Dateisystem)-Dateisystem über /etc/fstab befestigt ist.
FIRMWARE-ANALYSATOR
• Dieser Analysator verifiziert die Firmwarerevision aller Vorrichtungen mit schreibbarer Firmware, die in dem System installiert und an dasselbe angebracht sind, einschließlich: Interne und externe SCSI(Small Computer Systems Interface = Kleincomputersystemschnittstelle)-Festplatten, Datenträgerarray-Steuerungsmodule, interne Array-SCSI- Datenträgermodule und der Status von Lüftern, Leistungsversorgungen, Batterien, DRAM (Dynamic Random Access Memory = Dynamischer Direktzugriffsspeicher) und NVRAM (Non-Volatile Random Access Memory = nichtflüchtiger Direktzugriffsspeicher) auf Array-Steuerungen und Array-Chassis. Dieser Analysator kann wo erwünscht ferner verwendet werden, um zu verifizieren, daß jede Vorrichtung ein unterstütztes Hewlett-Packard-Produkt ist.
• Der Firmware-Analysator markiert üblicherweise einen Themenpunkt, wenn: Das Produkt kein unterstütztes Hewlett- Packard-Produkt ist, die Firmware-Revision des Datenträgers nicht die aktuelle Ausgabe ist, wenn Lese-, Schreib-, Verifizierungs- oder Nicht-Medium-Fehler auf einem SCSI- Datenträger protokolliert sind und die Anzahl von Fehlern größer oder gleich eins ist, wenn ein Schlecht-Status für einen Array-Lüfter, eine Leistungsversorgung, eine Batterie, einen DRAM oder NVRAM besteht, oder wenn das Datenträger-Array ein Hewlett-Packard("HP")-Produkt Modell 12 ist. Im Gegensatz zu älteren Modellen von HP-Arrays kann das Modell 12 richtig mit internen SCSI-Datenträgermodulen arbeiten, die nicht die aktuelle Version der Vorrichtungsfirmware enthalten. Dies wird durch die Array- Steuerungsfirmware erreicht, die eine separate Hardwarekomponente aus den internen Datenträgermodulen ist. Wenn der Analysator ein Modell 12 erfaßt, führt derselbe nur Tests an den Array-Steuerungen durch und bricht die Firmware- Tests an den internen Datenträgermodulen ab.
DATEISYSTEM-TESTPASSNUMMERN-ANALYSATOR
• Dieser Analysator testet, daß die Dateisystem-Paßnummer- Parameter richtig konfiguriert und unterstützbar sind. Ein Themenpunkt wird üblicherweise markiert, wenn: Die Dateisystem-Testdurchlaufnummer auf null eingestellt ist, wenn die Dateisystem-Testdurchlaufnummer für das Root- Dateisystem auf null eingestellt ist, wenn die Dateisystem- Testdurchlaufnummer für ein Nicht-Root-Dateisystem auf eins eingestellt ist, wenn die Dateisystem- Testdurchlaufnummer fehlt, wenn identische Durchlaufnummern für Dateisysteme auf den gleichen Datenträgerlaufwerken vorhanden sind, oder wenn Dateisystem-Testsdurchlaufnummern nicht für einen parallelen fsck (file system check = Dateisystemtest) optimiert sind.
DUMPFILESYSTEM
• Dieser Analysator testet, daß das Dateisystem, das durch savecrash (Sicherungs-Absturz) verwendet wird, groß genug ist. Ein Themenpunkt wird markiert, wenn: Keine Speicherabzugsvorrichtung konfiguriert ist, oder wenn das Dateisystem zu klein für einen Speicherabzug ist. Die Größe des Dateisystems, das verwendet werden kann, um den Speicherabzug zu speichern, wird getestet, wobei eine Komprimierung von 75% berücksichtigt wird, wenn eine Komprimierung aktiviert ist, und ein Kernel von 80 MB. Die Berechnung wird basierend auf der Gesamtspeichergröße für den schlimmsten Fall durchgeführt.
DMESG-ANALYSATOR
• Dieser Analysator erfaßt Systemfehlermeldungen von einem dmesg (ein UNIX-Befehl, der den Inhalt eines Ringpuffers anzeigt, der diagnostische Informationen enthält). Ferner verifiziert dieser Analysator, daß eine Unterstützung zum inkrementellen Erfassen der dmesg-Ausgabe vorhanden ist, um sicher zu stellen, daß keine der Systempufferinformationen verloren gehen. Wenn die Unterstützung für das Erfassen dieser Informationen existiert, verifiziert der Analysator, daß dieselbe richtig konfiguriert ist. Ein Themenpunkt wird markiert, wenn: Kein Eintrag in der crontab-Datei besteht (eine Konfigurationsdatei zum Planen von Aufgaben in UNIX, um Befehle zu bestimmten Zeiten abzuspielen), um die dmesg- Ausgabe inkrementell zu erfassen, wenn ein Eintrag in der crontab besteht, um das dmesg zu erfassen, derselbe jedoch nicht in die voreingestellte Position geschrieben wird, besteht ein Eintrag in die crontab, um das dmesg zu erfassen, aber das Intervall zum Sammeln ist größer als ein vorbestimmter, empfohlener Wert, oder es besteht ein Eintrag in die crontab, um die dmesg-Ausgabe zu erfassen, aber die Ausführung des dmesg-Befehls erfaßt die inkrementellen Änderungen nicht.
DIAGNOSTIKKONFIGURATIONS-ANALYSATOR
• Dieser Analysator prüft, ob eine Online-Diagnostik installiert wurde und läuft oder nicht. Ein Themenpunkt wird markiert, wenn: Die Online-Diagnostik nicht komplett installiert ist, eine oder beide Diagnostik-Hintergrundroutinen (Diagmond und Memlogd) nicht laufen oder die Version der Diagnostik-Software nicht die letzte, ausgegebene Revision ist.
CRASHCONF-ANALYSATOR
• Dieser Analysator ist einer der erforderlichen Tests, die, wenn sie mit anderen geeigneten Analysatoren kombiniert sind, sicherstellen werden, daß das System richtig konfiguriert ist, um einen erfolgreichen System-Speicherabzug durchzuführen. Ein Themenpunkt wird markiert, wenn: Die System-Speicherabzugvorrichtungen keinen ausreichenden Raum haben, um den System-Speicherabzug zu halten, oder wenn die minimal erforderlichen Klassen nicht bei einem Schnellspeicherabzug (fastdump) aktiviert wurden.
CPU-CHASSIS-ANALYSATOR
• Dieser Analysator testet die internen Prozessor- Hardwareprotokolle und berichtet über den Status der CPU- Lüfter, Leistungsversorgungen und die CPU-Prozessormodul- Dekonfiguration. Der Dekonfigurationszustand eines Prozessormoduls wird in den internen Prozessor- Hardwareprotokollen archiviert. Die möglichen Zustände sind "C", der anzeigt, daß das Prozessormodul konfiguriert ist und normal arbeitet, und "D", der anzeigt, daß das Prozessormodul durch den PDC als Ergebnis des Auftretens eines vom PDC erfaßten Hardwarefehlers dekonfiguriert wurde. Es besteht ein zusätzlicher Untersatz von Dekonfigurations- Statusflags (RS), der überwacht, ob das CPU-Prozessormodul durch den PDC dekonfiguriert wurde, als Ergebnis eines behebbaren, nicht schwerwiegenden Hardwarefehlers, oder ob das CPU-Prozessormodul nie durch den PDC nach dem physischen Ersetzen rekonfiguriert wurde. Wenn die RS-Flag einstellt ist, zeigt dieselbe an, daß der Zustand des Prozessors momentan dekonfiguriert ist, aber auf eine Rekonfiguration und eine Aktivierung durch ein physisches Neustarten des Systems wartet. Da es möglich ist, daß mehrere CPU- Prozessormodule, Lüfter und Leistungsversorgungen in einer CPU-Chassis installiert sind, wird die physische Position jeder fehlerhaften Komponente ebenfalls berichtet.
• Ein Themenpunkt wird markiert, wenn: Die CPU- Prozessormodule, die installiert sind, ein "D"-Status-Bit eingestellt haben, wenn die CPU-Prozessormodule, die installiert sind, sowohl "D"- und "RS"-Statusbits eingestellt haben, wenn das "F"(fehlerhaft)-Statusbit für einen Einbaulüfter eingestellt ist, oder wenn das "F"-Statusbit für eine Einbauleistungsversorgung eingestellt ist. Die "D"-, "RS"- und "F"-Statusbits werden nur durch den PDC eingestellt, wenn das CPU-Modul, der Lüfter oder die Leistungsversorgung physisch in der Systemprozessorchassis installiert sind.
BOOTSCRIPT-ANALYSATOR
• Dieser Analysator verifiziert, daß die Bootkonfigurationsscripts in /etc/rc.config.d eine optimale Konfiguration für ein HA(High Availability = Hochverfügbarkeit)-System aufweisen. Falls erwünscht kann dieser Analysator nur die crashconf- und savecrash-Konfiguration testen, aber es ist wünschenswert, alle Bootscripts zu testen. Ein Themenpunkt wird markiert, wenn: crashconf nicht konfiguriert ist, um zu laufen, savecrash nicht konfiguriert ist, um zu laufen, savecrash nicht konfiguriert ist, um im Vordergrund zu laufen, mindestens eine Speicheabzugvorrichtung nicht konfiguriert werden kann, die Speicherabzugsvorrichtungen nicht groß genug für einen Gesamtspeicherabzug sind, die Speicherabzugsvorrichtungen nicht groß genug für einen Speicherabzug sind, oder die Speicherabzugsvorrichtungen nicht in der Lage sind, den gesamten physischen Speicher zu halten.
Anhang A Textbeschreibung des Analysators Analysatorzusammenfassung
• NAME DATEISYSTEMVERWENDUNG VERSION 34
ZUSAMMENFASSUNG
• Dieser Analysator testet den Datenträgerraum auf jedem der befestigten, lokalen Dateisysteme. Erforderliche Daten /usr/bin/bdf
• Der bdf-Befehl (mit den -il-Optionen) zeigt die Menge von freiem Datenträgerraum an, der auf allen normal befestigten, lokalen Dateisystemen verfügbar ist. Die berichteten Zahlen sind in Kilobyte und umfassen einen Bericht von allen verwendeten und freien Inoden.
Erfaßte Themenpunkte
• Dies sind Themenpunkte, die von diesem Analysator erfaßt werden:
  Das Dateisystem ist voll.
  Der Datenträgerraum auf dem Dateisystem hat einen Schwellenpegel erreicht (90%).
  Der Datenträgerraum auf dem Dateisystem hat einen Schwellenpegel erreicht (95%).
1. DAS DATEISYSTEM IST VOLL
• Dieser Themenpunkt wird markiert, wenn kein verbleibender Datenträgerraum für ein bestimmtes Dateisystem verbleibt.
2. DER DATENTRÄGERRAUM AUF DEM DATEISYSTEM HAT EINEN SCHWELLENPEGEL ERREICHT (90%)
• Dieser Themenpunkt wird markiert, wenn der Datenträgerraum für ein gegebenes Dateisystem 90% erreicht hat.
3. DER DATENTRÄGERRAUM AUF DEM DATEISYSTEM HAT EINEN SCHWELLENPEGEL ERREICHT (95%)
• Dieser Themenpunkt wird markiert, wenn der Datenträgerraum für ein gegebenes Dateisystem 95% erreicht hat.
Durch den Analysator zurückgesendete Informationen
• Die durch den Analysator zurückgesendeten Informationen sind:
  Der durch den Analysator zurückgesendete, unterstützende Text ist:
  Algorithmus/Pseudocode
  Verifiziere, daß eine Eingangsdatei übertragen wurde nach:
  Wenn der Test fehlschlägt,
  Fehler erzeugen.
• Für jedes Dateisystem:
  Prüfe, daß der Dateisystemraum nicht voll ist (überschreitet den vollen Pegel)
  Wenn der Test fehlschlägt,
  Erzeuger Themenpunkt #1
  Ansonsten ?
  Teste, daß das Dateisystem keinen Schwellenpegel erreicht hat
  Wenn der Test fehlschlägt ?
  Erzeuger Themenpunkt #2
  Zusätzliche Informationen
• Für zusätzliche Informationen, gehen sie zu . . .
  Empfohlene Aktionen
• Es ist vielleicht heutzutage aus der Sicht eines Kunden mit großen Datenträgerflächen nichts zu tun. Sogar wenn die Schwellen erreicht wurden, könnte immer noch 5 GB Datenträgerraum verfügbar sein, z. B. auf einem Dateisystem von 100 GB. Die Themenpunkte sollten Empfehlungen und nicht definitive Fehler sein. Anhang B - Analysatorcode
  
  
  
  Anhang C -Analysator-XML-Descriptor <?xml Version = "1.0"?>
  <Analysatorversion = "1.0" Name = "FileSystemUsageAnalyzer" Themenpunkt-Basis-Wert = "100">
  <submitter>jean_ guiannotte@hp.com</submitter>
  <caption>Prüft, ob Dateisystem voll ist oder nach verwendetem Raum über der 90%- und 95%- Schwelle</caption>
  <issue-strategy>TEXT_PROPERTIES_ISSUE_STRATEGY</issue- strategy>
  <!-Dies ist die Definition der Ausführung des Analysators -->
  <program>
  <language>ksh</language>
  <source type = "text" purpose = "MAIN"> FileSystemUsageAnalyzer.ksh</source>
  </program>
  <number-of-systems>1</number-of-systems>
  <!--this is the expected input to the analyzer -->
  </input>
  <argument index = "1" collectible-id = "100024"/>
  </input>
  </analyzer> Anhang D -Analyzer Template #Fri Mar 16 11 : 51 : 36 EST 2001
  1 = Der\Datenträger\raum\auf\dem\Datei\system\{0}\hateinen \-Schwellen\wert\erreicht (voll)
  2 = Der\Datenträger\raum\auf\dem\Datei\system\{0}\hateinen \-Schwellen\wert\erreicht (90%)
  3 = Der\Datenträger\raum\auf\dem\Datei\system\{0}\hateinen \-Schwellen\wert\erreicht (95%). Anhang E -Durch einen Sammler erzeugter Bericht
  
  Anhang F -Analysatorthemenpunkt-XML-Bericht
  
  
  
  
  
  
Anhang G -Endbericht Acme Catapults Denver, CO Technikbewertungsbericht
• Hardware- und Betriebssystem-Analyse
  02. Mai 2001
  Vorbereitet durch
  Bewertungsteam
  Joe Smith - 987-654-3310.
  
  
  
  
  
  
  
  
  Anhang H
  
  

Claims (23)

1. Verfahren zum Prüfen einer Konfiguration eines Unternehmens (300), das folgende Schritte aufweist:
Sammeln (102, 104) von Informationen (106), die sich auf eine Konfiguration des Unternehmens (300) beziehen;
Analysieren (108, 806) der Konfigurationsinformationen (106) basierend auf Fachkenntnis (110, 804); und
Liefern (108, 118, 206, 806) eines Ergebnisses (112, 208) der Analyse (108, 806).

2. Verfahren gemäß Anspruch 1, das ferner den Schritt des Erzeugens (114, 206) eines Berichts (208) des Ergebnisses (112) der Analyse (108, 806) in einem Format (116, 117, 204) aufweist, das durch eine anfordernde Partei (1612) bezeichnet wird.

3. Verfahren gemäß Anspruch 2, das ferner den Schritt des Lieferns (118) des Berichts (208) zu der anfordernden Partei (118) aufweist.

4. Verfahren gemäß einem der Ansprüche 1 bis 3, bei dem der Analysierungsschritt (108, 806) den Schritt des Definierens (1200) eines Analysators (110) basierend auf Fachkenntnis (1202) als ein Themenpunkt (1208) zu der Konfiguration (102) des Unternehmens (300) umfaßt.

5. Verfahren gemäß Anspruch 4, bei dem der Schritt des Analysierens (108, 806) der Konfigurationsinformationen (106) ferner den Schritt des Anwendens (2212, 2216, 2218) des Analysators (110) auf die Konfigurationsinformationen (106) aufweist, um zu identifizieren, ob der Themenpunkt innerhalb des Unternehmens (300) existiert (2220, 2222).

6. Verfahren gemäß Anspruch 4 oder 5, das ferner den Schritt des Erfassens der Fachkenntnis (1202) zum Definieren des Analysators (110, 1200) umfaßt.

7. Verfahren gemäß einem der Ansprüche 1 bis 6, bei dem das Verfahren vollkommen automatisiert ist (104, 206, 806).

8. Verfahren gemäß einem der Ansprüche 2 bis 7, das ferner den Schritt des Erzeugens eines Aktionsplans (1610) zum Adressieren des Themenpunkts aufweist, der durch den Analysator (110) identifiziert wird.

9. Verfahren gemäß einem der Ansprüche 1 bis 8, das ferner den Schritt des Speicherns (708) der Informationen (106) aufweist, die sich auf die Konfiguration des Unternehmens (300) beziehen.

10. Verfahren gemäß einem der Ansprüche 1 bis 9, das ferner den Schritt des Wiederholens (604, 702) der Schritte des Verfahrens aufweist.

11. Verfahren zum Prüfen einer Konfiguration einer Mehrzahl von Feldplattformen oder Knoten (302, 304, 306) in einem Unternehmen (300), das folgende Schritte aufweist:
Sammeln von Informationen, die sich auf Konfigurationen einer Mehrzahl von Feldplattformen oder Knoten (302, 304, 306) beziehen;
Erzeugen eine Mehrzahl von Analysatoren (110) basierend auf Fachkenntnis, wobei jeder Analysator (110) einen oder mehrere Themenpunkte darstellt, zu einer der Mehrzahl von Feldplattformen oder Knoten (302, 304, 306);
Anwenden der Mehrzahl von Analysatoren (110) auf die Konfigurationsinformationen (106), um zu bestimmen, ob die Themenpunkte zu der Mehrzahl von Feldplattformen oder Knoten (302, 304, 306) existieren;
Speichern der Themenpunkte, die mit der Mehrzahl von Feldplattformen oder Knoten (302, 304, 306) identifiziert sind;
Erzeugen einer Mehrzahl von Regeln basierend auf Experteninformationen, wobei jede Regel einen Themenpunkt zu dem Unternehmen (300) darstellt; Anwenden der Mehrzahl von Regeln auf die gespeicherten Themenpunkte, die bezüglich der Feldplattformen oder Knoten (302, 304, 306) bestehen; und
Bereitstellen eines Ergebnisses der Analyse, die Themenpunkte innerhalb des Unternehmens (300) darstellt.

12. Computerimplementiertes Verfahren zum Automatischen Prüfen einer Konfiguration von mindestens einer Quelle innerhalb eines Unternehmens (300), das folgende Schritte aufweist:
Sammeln von variabel formatierten Konfigurationsinformationen (106) von mindestens einer Quelle,
Analysieren der Konfigurationsinformationen (106) unter Verwendung von Analysatoren (110), deren Entwürfe auf Fachkenntnis basieren, um das Vorhandensein oder das Nichtvorhandensein von einem oder mehreren Themenpunkten zu identifizieren, die der mindestens einen Quelle zugeordnet sind; und
Liefern von Informationen (106) als ein Ergebnis der Analyse, die das Vorhandensein oder das Nichtvorhandensein des einen oder der mehreren Themenpunkten in einem Standardformat definieren.

13. Verfahren gemäß Anspruch 12, bei dem jedes variable Format durch das Ordnen von Informationen in der Standardausgabe eines Computerprogrammsammlers (104) bestimmt wird.

14. Verfahren gemäß Anspruch 12 oder 13, bei dem die Quelle eine Plattform oder ein Knoten (302, 304, 306) ist.

15. Verfahren gemäß einem der Ansprüche 12 bis 14, bei dem das Standardformat XML ist.

16. Verfahren gemäß Anspruch 15, das ferner den Schritt des Übertragens des XML-Analyseergebnisses in eine Datenbank und ein nachfolgendes Verwenden der Datenbank zum Steuern der Anordnung von Berichten (208) aufweist.

17. Verfahren gemäß einem der Ansprüche 12 bis 16, bei dem der Analysierungsschritt den Schritt des Anwendens eines Analysators (110) auf die Konfigurationsinformationen (106) umfaßt, um zu identifizieren, ob die Themenpunkte innerhalb der Quelle existieren.

18. System zum Prüfen einer Konfiguration einer Mehrzahl von Quellen innerhalb eines Unternehmens (300), wobei die Quellen eine Mehrzahl von Kombinationen aus Hardware, Software und Betriebssystemen umfassen, wobei das System folgende Merkmale aufweist:
eine Mehrzahl von Sammlern (104) zum Sammeln von Konfigurationsinformationen (106) von jeder der Mehrzahl von Quellen, wobei die Konfigurationsinformationen (106) eine Mehrzahl von Kombinationen aus Datenformaten, Datensyntax und Datenelementstruktur umfassen;
eine Komponente zum Analysieren der Konfigurationsinformationen (106) für jede Quelle der Mehrzahl von Quellen, um einen oder mehrere Themenpunkte zu identifizieren, die jeder Quelle zugeordnet sind; und
eine Komponente zum Standardisieren der Konfigurationsinformationen (106).

19. System gemäß Anspruch 18, bei dem die Komponente zum Standardisieren der Konfigurationsinformationen (106) eine Komponente zum Umwandeln der Konfigurationsinformationen (106) in ein einheitliches Format umfaßt.

20. System gemäß Anspruch 19, das ferner eine Komponente zum Erzeugen eines Berichts (208) des Ergebnisses der Analyse umfaßt.

21. System gemäß Anspruch 20, bei dem das Ergebnis in eines aus einer Mehrzahl von Präsentationslayouts angepaßt sein kann.

22. Automatisierte Rahmenstruktur, die folgende Merkmale aufweist:
eine erste Komponente zum Sammeln von Konfigurationsinformationen (106), die sich auf eine Mehrzahl von Quellen beziehen;
eine zweite Komponente zum Analysieren der Konfigurationsinformationen (106) basierend auf Fachkenntnis zum Identifizieren eines zugeordneten Themenpunkts innerhalb jeder Quelle der Mehrzahl von Quellen; und
eine dritte Komponente zum Liefern von Ergebnissen der Analyse jeder Quelle.

23. Automatisierte Rahmenstruktur gemäß Anspruch 22, die ferner eine vierte Komponente zum Erzeugen von einem aus einer Mehrzahl von Berichten (208) mit den Ergebnissen aufweist.