DE10331880A1

DE10331880A1 - Verfahren und Vorrichtung zum Koordinieren von Gruppen von heterogenen Messungen

Info

Publication number: DE10331880A1
Application number: DE10331880A
Authority: DE
Inventors: David L. Sunnyvale Barnard; Robert H. Colorado Springs Kroboth
Original assignee: Agilent Technologies Inc
Current assignee: Agilent Technologies Inc
Priority date: 2002-08-22
Filing date: 2003-07-14
Publication date: 2004-03-04
Also published as: US7231555B2; US20040039970A1; JP4460241B2; JP2004088779A

Abstract

Ein Netzwerkfehlersuchzentrum NTC, das orchestrierte Tests durchführt, die aus heterogenen Messungen zusammengesetzt sind. Das System innerhalb des NTC umfaßt eine Architektur zum Verwalten von Tests gemäß Anforderungen, die durch gelieferte Daten auferlegt werden. Das NTC umfaßt die Operationen zum Definieren des Tests, der durchgeführt werden soll, Konfigurieren der Einstellungen gemäß der Protokolle, die zum Liefern von Daten verwendet werden, Verriegeln spezifischer Ressourcen, die für den bestimmten Test zweckgebunden sind, der durchgeführt wird, und Ausführen der Tests an heterogenen Messungen auf orchestrierte Weise, zum Liefern eines Spektrums von Ergebnissen, so daß eine Fehlersuche der heterogenen Ergebnisse auf einer gewünschten Ebene durchgeführt und zusammengefaßt werden kann.

Description

Die vorliegende Erfindung bezieht sich auf das Koordinieren von Gruppen von Messungen, und insbesondere auf das Koordinieren von heterogenen Messungen von unterschiedlichen Quellen und Messungen des selben Typs von unterschiedlichen Quellen.

Softwareplattformen müssen in der Lage sein, Messungen von Datenquellen zu sammeln, die Daten in unterschiedlichen Formen liefern, z. B. unterschiedliche Typen von Daten, Daten die an unterschiedlichen Zeittabellen zugreifbar sind, etc. Bestimmte Beispiele der Datenquellen (Protokolle, die Schemata umfassen, die erklären, wie Daten formatiert und organisiert werden), die Daten liefern, die gesammelt und/oder koordiniert werden sollen, umfassen z. B. Router, Stimmtester, Netzwerkanalysatoren oder Netzwerksonden. Die Protokolle, die durch die Datenquellen implementiert werden, umfassen, sind jedoch nicht beschränkt auf, SNMP (RMON, MIB2, etc.), RTP, XML, SCPI, http, CMIP, LDAP, ODBC, JDBC, etc. Diese Messungen werden üblicherweise auf eine sehr individuelle Weise verwendet, um spezifische Probleme innerhalb eines einzelnen Netzwerks zu suchen, wie z. B. Messungen, die durch SNMP-Agenten bereitgestellt werden. Eine solche Fehlersuche umfaßt Tests, die das Nehmen und Präsentieren individueller Messungen umfassen, die Abweichungen von erwarteten Ergebnissen hervorheben. Ein Beispiel eines häufig verwendeten Systems, das Berichte über eine Vielzahl von Messungen in einer bestimmten Domäne liefert, wie z. B. Messungen, die durch SNMP-Agenten geliefert werden, ist eines von CONCORD COMMUNICATIONS.

Vor kurzem jedoch ist ein Bedarf entstanden, ein verteiltes Testen durchzuführen, da viele der Probleme, die mit Netz werken entstehen, die eine Fehlersuche erfordern, schwierig durch individuelle Messungen zu lokalisieren sind. Somit besteht ein Bedarf, in der Lage zu sein, mehrere Messungen an unterschiedlichen Orten in dem Netzwerk zur gleichen Zeit zu koordinieren. Ferner, um bestimmte der Messungen zu ergänzen, die bei bestimmten Produkten durchgeführt werden, besteht ein Bedarf, andere Messungen in einen Gesamttest aufzunehmen, der durch unterschiedliche Netzwerkgeräte, Netzwerkanwendungen und Netzwerkbetriebssysteme durchgeführt wird, die auf einem Netzwerk an einem bestimmten Punkt vorliegen. Dementsprechend besteht ein Bedarf, in der Lage zu sein, unterschiedliche Typen von Testaktivitäten zusammenzuziehen. Um z. B. in der Lage zu sein, unterschiedliche Messungen gemeinsam zu planen und auszulösen, und um diese Messungen so zu konfigurieren, daß dieselben die ordnungsgemäße Konfiguration im Hinblick auf das Abspielen der unterschiedlichen Messungen erhalten. Ferner besteht ein Bedarf, diese Ergebnisse der weitgehend unterschiedlichen Datentypen in einer konsolidierten Form einer Datenbank zu sammeln. Schließlich besteht ein Bedarf, in der Lage zu sein, die wichtigsten Verstöße oder Abweichungen von Erwartungen von Meßergebnissen hervorzuheben sowie die Ergebnisse der unterschiedlichen Messungen zusammenzufassen und zu präsentieren. Dementsprechend besteht ein Bedarf nach einer Softwareplattform, die unterschiedliche Daten in einer gemeinsamen Quelle sammeln und/oder koordinieren kann.

Es ist die Aufgabe der vorliegenden Erfindung, eine Vorrichtung, ein Verfahren zum Integrieren heterogener Messungen, ein Verfahren zum Koordinieren von Gruppen heterogener Messungen und ein Netzwerkfehlersuchsystem mit verbesserten Charakteristika zu schaffen.

Diese Aufgabe wird durch eine Vorrichtung gemäß Anspruch 1, 10, 14, 21, 45 oder 51, ein Verfahren zum Integrieren heterogener Messungen gemäß Anspruch 23, ein Verfahren zum Koordinieren von Gruppen von heterogenen Messungen gemäß Anspruch 34 und ein Netzwerkfehlersuchsystem gemäß Anspruch 47 gelöst.

Es ist ein Aspekt der vorliegenden Erfindung, eine Plattform zu schaffen, die Messungen definiert, die an einem Netzwerk durchgeführt werden sollen, Einstellungen von Vorrichtungen auf dem Netzwerk konfiguriert, von denen heterogene Daten geliefert werden, um die Messungen durchzuführen, die die einstellungskonfigurierten Vorrichtungen verriegelt, um die Vorrichtungen zuzuordnen, um die heterogenen Daten zu liefern, und die Tests durchführt, um die heterogenen Messungen von den verriegelten Vorrichtungen zu nehmen.

Es ist ein anderer Aspekt der vorliegenden Erfindung, ein Verfahren zum Ordnen von Gruppen von heterogenen Messungen und/oder Messungen des selben Typs von Daten aus Datenquellen zu liefern.

Es ist ein wiederum anderer Aspekt der vorliegenden Erfindung, einen Rahmen zu schaffen, der einer Mehrzahl von Vorrichtungen auf einem Netzwerk gemeinsam ist, wobei der Rahmen die heterogenen Messungen automatisch synchronisiert, die von der Mehrzahl von Vorrichtungen über das Netzwerk durchgeführt werden.

Es ist ein wiederum anderer Aspekt der vorliegenden Erfindung, eine computerimplementierte Datensammelvorrichtung zu schaffen, die einer Mehrzahl von Vorrichtungen auf einem Netzwerk gemeinsam ist, wobei die Datensammelvorrichtung automatisch heterogene Messungen aus der Mehrzahl von Vorrichtungen über das Netzwerk ansammelt.

Es ist ein wiederum anderer Aspekt der vorliegenden Erfindung, eine Vorrichtung zu schaffen, die folgende Merkmale aufweist: Einen gemeinsamen Rahmen zum Korrelieren von Messungen, die aus unterschiedlichen Vorrichtungen erhalten werden, wobei zumindest zwei der Vorrichtungen Daten eines unterschiedlichen Typs liefern, durch Synchronisieren der Messungen, die von den unterschiedlichen Vorrichtungen erhalten werden.

Es ist ein wiederum anderer Aspekt der vorliegenden Erfindung, eine computerimplementierte Präsentationsvorrichtung zu liefern, die heterogene Messungen korreliert, die von einer Mehrzahl von Vorrichtungen auf einem Netzwerk durchgeführt werden, die korrelierten heterogenen Messungen auf einem Anzeigebildschirm an einen Endbenutzer präsentiert und dem Endbenutzer ermöglicht, sich von einer weniger detaillierten Präsentation zu einer detaillierteren Präsentation zu bewegen.

Es ist ein wiederum anderer Aspekt der vorliegenden Erfindung, ein Verfahren zum Integrieren von heterogenen Messungen zu schaffen, die von einer Mehrzahl von Datenquellen in einem gemeinsamen Netzwerk empfangen werden, wobei das Verfahren folgende Operationen umfaßt: (a) Definieren von jeder der Messungen, die mit dem Dienst von zumindest einer Datenquelle durchgeführt wird; (b) Konfigurieren der Einstellungen von jeder der Datenquellen, die in den Messungen umfaßt sind, die durchgeführt werden sollen; (c) Verriegeln von Ressourcen, die für jede spezifische Messung zweckgebunden sind, die durchgeführt werden soll; (d) Durchführen von Messungen an den Daten, die von den Datenquellen empfangen werden; (e) Synchronisieren der durchgeführten heterogenen Messungen; und (f) gemeinsames Präsentieren der Messungen.

Es ist ein wiederum anderer Aspekt der vorliegenden Erfindung, ein Verfahren zum Koordinieren von Gruppen von heterogenen Messungen in einer gemeinsamen Plattform zu schaffen, wobei das Verfahren folgende Operationen umfaßt: Bereitstellen einer Mehrzahl von Datenquellen, wobei jede Datenquelle einen unterschiedlichen Datentyp im Hinblick auf die andere Datenquelle enthält; Messen der unterschiedlichen Datentypen aus der Mehrzahl von Datenquellen; und Normieren der gemessenen Ergebnisse auf einer gemeinsamen Skala.

Es ist ein wiederum anderer Aspekt der vorliegenden Erfindung, ein Netzwerkfehlersuchsystem zu schaffen, das folgende Merkmale aufweist: Zumindest zwei Datenquellen, wobei jede Datenquelle Daten eines unterschiedlichen Typs im Hinblick auf eine andere Datenquelle liefert, die gemessen werden soll; einen Datenquellverwalter, der eine Verwaltung bereitstellt, wie die unterschiedlichen Datentypen gemessen werden sollen; eine Datensammelvorrichtung, die Informationen liefert, die für das Netzwerkfehlersuchsystem notwendig sind, um die unterschiedlichen Datentypen zu messen, die durch die zumindest zwei Datenquellen geliefert werden; eine Datenbank zum Speichern der durchgeführten Messungen; und einen Testverwalter zum Verwalten des Verhaltens der Messungen an den unterschiedlichen Datentypen, die durch die zumindest zwei Datenquellen geliefert werden.

Diese zusammen mit anderen Aspekten und Vorteilen, wie nachfolgend offensichtlich wird, liegen in den Details des Aufbaus und der Operation, wie hierin nachfolgend umfassender beschrieben und beansprucht wird, wobei Bezug auf die beiliegenden Zeichnungen genommen wird, die einen Teil hiervon bilden, wobei gleiche Bezugszeichen sich durchgehend auf gleiche Teile beziehen.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beigefügten Zeichnungen näher erläutert. Es zeigen:

1 ein Beispiel der Netzwerkfehlersuchzentrums-Architektur (NTC- = Network Troubleshooting Center) gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;

2 eine allgemeine Darstellung von Komponenten eines Tests unter Verwendung des NTC gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;

3 ein Beispiel eines Tests unter Verwendung des NTC gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;

4 einen Test, der aus einer einzelnen diskreten Messung zusammengesetzt ist, die durch das Netzwerkfehlersuchzentrum gemäß einem Ausführungsbeispiel der vorliegenden Erfindung durchgeführt wird;

5 einen Test, der aus einer einzelnen, in Intervalle aufgeteilten Messung zusammengesetzt ist, die durch das Netzwerkfehlersuchzentrum gemäß einem Ausführungsbeispiel der vorliegenden Erfindung durchgeführt wird;

6 einen Test, der aus einer einzelnen progressiven Messung zusammengesetzt ist, die durch das Netzwerkfehlersuchzentrum gemäß einem Ausführungsbeispiel der vorliegenden Erfindung durchgeführt wird;

7 ein Beispiel eines einfachen XML-Testergebnisdokuments gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;

8 ein Beispiel eines komplexen Zusammenfassungsdokuments gemäß einem Ausführungsbeispiel der Erfindung;

9 ein Beispiel zum Kombinieren der Meßergebnisse in einer Testberichterstatterseite gemäß einem Ausführungsbeispiel der vorliegenden Erfindung; und

10 ein Diagramm der Anzeige von normierten Daten in Farbe gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.

Es wird nun detailliert Bezug auf die Ausführungsbeispiele der vorliegenden Erfindung genommen, wobei Beispiele derselben in den beiliegenden Zeichnungen dargestellt sind, wobei gleiche Bezugszeichen sich durchgehend auf gleiche Elemente beziehen.
Unterschiedliche Typen von Netzwerksystemen werden üblicherweise durch einen weiten Bereich von unterschiedlichen Protokollen implementiert, d. h. SNMP (RMON, MIB2, etc.), RTP, XML, SCPI, http, CMIP, LDAP, ODBC, JDBC, etc. Dementsprechend sind die Daten, die durch diese Protokolle geliefert werden, heterogen im Hinblick aufeinander. Die vorliegende Erfindung schafft ein Betriebssystem und ein Verfahren zum Sammeln der heterogenen Daten von jedem der separaten Protokolle, Synchronisieren der heterogenen Daten, um orchestrierte Tests durchzuführen, und Präsentieren eines normierten Ergebnisses des Tests, während die Fähigkeit bereitgestellt wird, die Ergebnisse auf eine interaktiv navigierbare Weise zu betrachten.
1 ist ein Diagramm, das ein Beispiel der Netzwerkfehlersuchzentrum-Architektur (NTC-Architektur; NTC = Network Troubleshooting Center) 100 (ebenfalls bezeichnet als Plattform) gemäß einem Ausführungsbeispiel der vorliegenden Erfindung darstellt. Dieses NTC ist derart dargestellt, daß es in der Lage ist, Daten aus vielen unterschiedlichen Datenquellen oder Netzwerkhosts (ebenfalls bezeichnet als Agenten) zu sammeln und synchronisierte Tests an den Daten durchzuführen.
Es bestehen drei Agenten 101a-101c, die in 1 zu darstellenden Zwecken bereitgestellt sind, die drei gemeinsam verwendete Protokolle unterbringen. Es wird jedoch darauf hingewiesen, daß viele zusätzliche sowie unterschiedliche Agenten 101a-n, die viele unterschiedliche Typen von Protokollen unterbringen, verwendet werden können, um Daten zu dem Netzwerkfehlersuchzentrum 100 der vorliegenden Erfindung zu liefern (siehe 2 und 3, die nachfolgend beschrieben werden). Bestimmte andere Typen von Protokollen, die durch die Agenten 101a-n untergebracht sind, umfassen z. 8. SNMP, XML, SCPI, SNMP (RMON, MIB2, etc.) XML, NSTP, RTP, http, CMIP, LDAP, ODBC, JDBC, etc. Es wird darauf hingewiesen, daß diese erweiterte Liste von Protokollen, die durch das NTC 100 der vorliegenden Erfindung implementiert werden können, nicht auf dieselben beschränkt sind, sondern daß dieselben nur als darstellende Beispiele der vielen standardmäßigen oder proprietären Protokolle vorgesehen sind, die durch das NTC 100 der vorliegenden Erfindung implementiert werden können. Eine Kommunikationsschicht 102 wird verwendet, um die unterschiedlichen Protokolle, die das NTC 100 unterstützen, mit dem NTC 100 selbst zu kommunizieren. Die Kommunikationsschicht 102 liefert z. B. die unterschiedlichen Meßdaten (heterogen im Hinblick aufeinander), die von den unterschiedlichen Agenten 101a-n empfangen werden, die durch eine Datensammelvorrichtung 103 gesammelt werden sollen.
Die Datensammelvorrichtung 103 sammelt heterogene Messungen, die durch jeden der Agenten 101a-n geliefert werden, die durch das NTC 100 implementiert sind (ebenfalls bezeichnet als eine gemeinsame Plattform). Die Messungen, die durchgeführt werden, können aktive Messungen, passive Messungen, absolute Messungen, differentielle Messungen, diskrete Messungen, kontinuierliche Messungen und progressive Messungen umfassen. Es wird darauf hingewiesen, daß, obwohl eine einzelne Datensammelvorrichtung 103 zu darstellenden Zwecken bereitgestellt ist, darauf hingewiesen wird, daß eine Mehrzahl von Datensammelvorrichtungen mit dem NTC 100 der vorliegenden Erfindung verwendet werden kann.
Ein aktives Testen umfaßt das Messen des Ansprechverhaltens auf einen bestimmten Stimulus, der als Teil des Meßaufbaus erzeugt wird. Bestimmte Beispiele umfassen eine PSQM-Stimmqualitätsmessung, Pfeifen und Spurweg bzw. Traceroute und eine aktive Anwendungsansprechzeit. Ein passives Testen umfaßt das Beobachten einer Netzwerk- (oder System-) Aktivität mit minimalem Einfluß auf die zu testende Umgebung. Bestimmte Beispiele umfassen Paketerfassung, SNMP RMON- und MIB-Statistiken und RTP-Qualitätsmessungen. Ob die Messung aktiv oder passiv ist wichtig im Hinblick auf die Verwendungsfälle. Aktive Messungen erfordern z. B. manchmal das nichtprozeßgekoppelte Verwenden von Kommunikationsausrüstung oder das Verringern von dessen Kapazität.
Absolute Messungen umfassen jene, die aus unabhängigen Beobachtungen aufgebaut sind. Andererseits erfordern andere Messungen das Zusammenfaktorisieren anderer Beobachtungen, um ein unabhängiges Ergebnis zu berechnen. Differenzmessungen erfordern das Subtrahieren einer Beobachtung von einer anderen, um ein Ergebnis zu erhalten. Ein Beispiel einer Differenzmessung ist ein Zähler, der ein gemeinsames Merkmal von SNMP MIBs ist. Ein solcher Zähler ist der Oktett-Zähler an einer MIB2-Schnittstelle. Der Wert des Zählers selbst ist nicht sehr nützlich, da derselbe keine deterministische Referenz aufweist. Eine Messung basiert in diesem Fall auf zwei Lesungen des Zählers, die zeitlich getrennt sind.
Bestimmte Messungen sind in ihrer Eigenschaft repititiv, während andere dies nicht sind. Das Messen von SNMP-Statistiken ist z. B. einfach für periodische oder in Intervalle aufgeteilte Messungen verwendbar. In diesem Fall ist die Messung eine in Intervalle aufgeteilte Datensammlung, die eines oder mehrere Zeitintervalle enthält. Andere Messungen sind in ihrer Eigenschaft einzeln oder einfach, wie z. B. die Zeitdauer eines Stimmrufs. Messungen, wie z. B. Stimmqualität und Klingeln können auf beide Weisen verwendet werden. Für in Intervalle aufgeteilte Messungen ist das Erzeugen eines kleinen Ergebnissatzes üblicherweise wichtig. Ein wichtiger Lösungsansatz bei in Intervalle aufgeteilten Messungen ist das Erhalten von entscheidenden Statistiken, von jenen, die die beste Zusammenfassung des zugrundeliegenden Zustands liefern. Wenn somit eine PSQM-Messung repititiv durchgeführt wird, würden die Meßergebnisse weniger Detail aufzeichnen, und wenn dieselben einfach durchgeführt wird, würde dieselbe mehr Details aufzeichnen.
Eine progressive Messung ist eine, die eine Reihe von Zwischenergebnissen entlang des Wegs zur Fertigstellung erzeugt. Dies unterscheidet sich von einer kontinuierlichen Messung insofern, daß jeder Zwischenergebnissatz unterschiedlich sein kann. Ein Beispiel ist ein Spurweg. Diese Idee gilt ferner für Phasenmeßprozesse, wie z. B. bestimmte Stimmessungen, die einen Ruf-Aufbau und eine -Unterbrechung umfassen. Für diese Arten von Tests ist es häufig nützlich, Teilergebnisse an den Benutzer zu liefern, da sich der Test abhängig davon entwickelt, wie häufig Zwischenergebnisse verfügbar sind.
Bei der vorliegenden Erfindung können verschiedene Mechanismen verwendet werden, um zwischen dem Testagent zu kommunizieren, um Status, Entwicklungsaktualisierungen und Testergebnisse zu kommunizieren. In solchen Fällen muß der Agent abgefragt werden. In anderen Fällen kann derselbe eine asynchrone Benachrichtigung durch SNMP-Fallen oder andere Mechanismen liefern. Für Netzwerkfehlersuchanalysevorrichtungen, wie z. B. die AGILENT Netzwerkanalysevorrichtung der vorliegenden Erfindung, kann eine proprietäre XML API verwendet werden.
2 stellt eine allgemeine Darstellung der Komponenten eines Tests 300 unter Verwendung des NTC 100 (oder der gemeinsamen Plattform) der vorliegenden Erfindung dar. Wie oben erwähnt wurde, sind die Agenten 101a-n Datenquellen (ebenfalls bezeichnet als Datenliefervorrichtungen), die eine Vielzahl von Protokollen unterbringen, die durch das NTC 100 der vorliegenden Erfindung unterstützt werden sollen. Das NTC 100 kann eine große Anzahl von Agenten 101a-101n implementieren, von denen es Daten empfängt, um Messungen derselben bei den Operationen 200a-200c durchzuführen. Es wird darauf hingewiesen, daß die Anzahl von Meßoperationen in 2 ausschließlich zu Darstellungszwecken bereitgestellt ist, aber so umfassend sein kann, wie die Anzahl von Agenten 101a-n, die durch das NTC 100 der vorliegenden Erfindung implementiert sind. Jeder Agent 101, oder manchmal eine Gruppe von Agenten zusammen (l0lc-101n), kann Meßdaten liefern. Jede Messung liefert einen unabhängigen Satz von Ergebnissen, die eventuell eine Möglichkeit zum Korrelieren mit anderen Meßergebnissen ermöglichen. Eine Messung kann aus Rohbeobachtungsdaten oder dem Ergebnis eines Tests niedriger Ebene bestehen, möglicherweise gefiltert oder zusammengefaßt. Allgemein ausgedrückt, sobald die Daten gemessen sind, kann ein synchronisiertes Testen durchgeführt werden. Spezifische Operationen werden jedoch vor dem tatsächlichen Testen aufgebaut, wie nachfolgend detailliert beschrieben wird.
3 stellt ein detaillierteres Beispiel eines Tests 301 dar, der durch das NTC 100 der vorliegenden Erfindung durchgeführt wird, wobei der Test 301 hier aus dem Nehmen von heterogenen Messungen bei den Operationen 200a-200c zusammengesetzt ist. Dieser heterogene Test 301 kann verwendet werden, um ein Stimme-Über-IP-Verhaltensproblem zu suchen. Eine Ende-Zu-Ende-Messung von Stimmklarheit ist eine der Messungen, die bei Operation 200c durchgeführt wird. Ferner sind zwei Messungen von Netzwerkstatistiken für eine Netzwerkausrüstung dargestellt, die der Stimme-Über-IP-Ruf überquert. Dementsprechend bringen die Agenten 101a-n, die in 3 dargestellt sind, Protokolle unter, die RMON, SNMP und 2 Stimmtester umfassen. Wie oben erwähnt wurde, sind diese Protokolle ausschließlich zu darstellenden Zwecken bereitgestellt und können durch andere Protokolle ersetzt werden, die durch das NTC 100 der vorliegenden Erfindung implementiert werden sollen. Ein Suchen des Problems erfordert, in der Lage zu sein, die Ergebnisse der individuellen Messungen zu korrelieren, die bei den Operationen 200a-200c als Teil der Testergebnispräsentation durchgeführt werden, die durch das NTC 100 der vorliegenden Erfindung durchgeführt wird.
Wie in 1 dargestellt ist, liefert ein Testverwalter 106 eine Verwaltung dafür, wie die Tests ausgeführt werden sollen. Anders ausgedrückt bestimmt der Testverwalter 106, wie die Tests orchestriert werden sollen, die zwischen den unterschiedlichen Messungen ausgeführt werden, die durchgeführt werden. Zum Beispiel ruft ein Testorchestrierer (nicht gezeigt), der Teil des Testverwalters 106 ist, jede Testverwalterschnittstelle (domänenspezifische Testeinsteckelemente, die als Teil eines Agentenverwalters implementiert sein können) eines Agenten auf, wie z. B. MIB2, RMON, VQT, der sich bewußt ist, wie das resultierende Dokument verpackt werden soll, um die Elemente zu enthalten, die zum Zusammenfassen des fraglichen Tests nützlich sind. Dies entlastet die Testberichtvorrichtung und den Testorchestrierer davon, mit einer domänenspezifischen Kenntnis programmiert werden zu müssen.
Ein Agentenverwalter 104 liefert eine Verwaltung dafür, wie Daten gemessen werden sollen. Der Agentenverwalter 104 und die Datensammelvorrichtung 103 sind im wesentlichen zwei Einheiten, die eine spezifische Kenntnis darüber haben, was für die Messungen geliefert werden muß.
Der Test der Messungen, die durchgeführt werden sollen, muß definiert werden. Zum Beispiel ist der Test aus einer oder mehreren Messungen zusammengesetzt. Diese Messungen können von der selben Art oder heterogen sein. Eine Auswahl der Messung, die durchgeführt werden soll, kann durch eine GUI 107 bestimmt werden. Alternativ kann die Auswahl der Messung, die durchgeführt werden soll, durch einen automatisierten Prozeß unter Verwendung einer API 108 bestimmt werden. Alles über die Messung, die durchgeführt werden soll, wird allgemein definiert, bevor der Test ausgeführt wird. Alternativ können die Meßparameter während des Ablaufs des Tests oder der Tests verändert werden, der oder die durchgeführt werden.
Sobald der Typ des Tests und alle Details über den Test definiert sind, müssen Konfigurationseinstellungen für jede Messung, die durchgeführt werden soll, ebenfalls bereitgestellt werden. Diese Konfigurationseinstellungen sind meßspezifisch und werden üblicherweise durch einen bestimmten Typ eines Dateneintrags bereitgestellt. Die GUI 107 kann einen Benutzer anleiten, benutzerspezifizierte Einstellungen anzuwenden, dadurch, daß dem Benutzer durch jede Messung aufgezählt wird, die Konfigurationseinstellungen anzuwenden. Alternativ kann eine Konfigurationseinstellung durch die API 108 durch einen automatisierten Prozeß angewendet werden. Sobald die notwendigen Konfigurationseinstellungen bereitgestellt wurden, ist der Test zum Ausführen bereit. Bestimmte Beispiele von Konfigurationen, die gesetzt werden sollen, umfassen z. B. was gemessen wird, wie Endergebnisse erwünscht sind, etc. Ein anderes Beispiel von benötigten Konfigurationseinstellungen sind solche, die Messungen umfassen, die im Hinblick auf Stimme-Über-IP-Telephonanrufe durchgeführt werden sollen. Hier, wenn Messungen der Anzahl von Anrufen an eine bestimmte Nummer erforderlich sind, könnte die Nummer selbst eine Konfigurationseinstellung sein. Ein anderes Beispiel könnte sein, wenn die Stimmqualität bestimmt werden soll, könnten die Konfigurationseinstellungen gesetzt werden, um ein Verfahren unter verschiedenen unterschiedlichen Verfahren zum Messen der Stimmqualität zu implementieren.
Ein anderer Teil der Konfigurationseinstellung ist ein autonomer Abschnitt der Konfiguration, wo der Testverwalter 106 die Konfigurationseinstellungen zur Meßlaufzeit in die Agenten 101 hineinschiebt. Es besteht eine Entkopplung zwischen dem Benutzer, der die Meßkonfigurationseinstellung spezifiziert und dem Hinausschieben der Konfigurationsin formationen in die jeweiligen Meßagenten 101a-n. Der Testverwalter 106 führt diese Entkopplung durch.
Zusätzlich zu den Konfigurationseinstellungen, die vor dem Ausführen der Tests erhalten werden, können neue Konfigurationseinstellungen, die während des Durchführens der Tests bereitgestellt werden, durch die GUI 107 oder die API 108 in das NTC 100 eingegeben werden. Zum Beispiel kann ein Javabean mit der GUI 107 implementiert sein, um neue Konfigurationseinstellungen für das NTC 100 (gemeinsame Plattform) der vorliegenden Erfindung zu liefern.
Eine Messung, die durchgeführt werden soll, kann Ressourcen aufweisen, die ausschließlich für dieselbe während der Dauer einer Messung zweckgebunden sein müssen. Um eine Ressourcenverwendung in Anbetracht der Tatsache zu koordinieren, daß mehr als ein Test durchgeführt werden kann, können bestimmte Ressourcen, die für einen bestimmten Test zweckgebunden sind, im Hinblick auf den Test verriegelt werden, die anderweitig als „Verriegelungsressourcen" bezeichnet werden. Wenn somit ein Test gestartet wird, kann der Test auf einer oder mehreren notwendigen Ressourcen verriegelt sein, um den Test oder die Messung durchzuführen. Die Verriegelung(en) werden gelöst, sobald der Test abgeschlossen ist oder wenn der Test, der durchgeführt wird, die Ressource(n) nicht länger benötigt. Der Testverwalter 106 empfängt und verwendet spezifische Informationen, die zu demselben geliefert werden, um eine notwendige Verriegelung der Ressourcen im Hinblick auf die bestimmten Tests durchzuführen. Die Verriegelung der Ressourcen wird durchgeführt, bevor der Test ausgeführt wird.
Sobald der Test beginnt, können unterschiedliche Typen von Messungen durchgeführt werden, wie vorangehend beschrieben wurde. Zum Beispiel können diskrete Messungen (ausgelöst), kontinuierliche Messungen, progressive Messungen, etc. durchgeführt werden. Ein Auslöser kann den Test starten, oder es kann eventuell ein diskontinuierlicher Test durch geführt werden. Bei kontinuierlichen Messungen wird der Testverwalter 106 vielleicht nicht zu dem Ausmaß benötigt, zu dem derselbe bei anderen Messungen benötigt wird. Der Testverwalter 106 muß jedoch in der Lage sein, die unterschiedlichen Typen von Messungen zu unterstützen. Der Testverwalter 106 muß z. B. wissen, ob er den Test startet oder ob er auf die Messungen zählen kann, die bereits stattfinden. Daher können diese Informationen, die üblicherweise als Meta-Kenntnisse bezeichnet werden, durch den Agentenverwalter 106 und/oder die Datensammelvorrichtung 103 in den Testverwalter 106 plaziert werden, so daß jedes Szenario (unterschiedliche Typen von Tests, die durchgeführt werden) unterstützt wird. Wie vorangehend erwähnt wurde, sind der Agentenverwalter 104 und die Datensammelvorrichtung 103 im wesentlichen die zwei Einheiten, die spezifische Meta-Kenntnisse darüber haben, was zum Durchführen der unterschiedlichen Messungen geliefert werden muß, und der Agentenverwalter 104 und die Datensammelvorrichtung 103 liefern wichtige Daten zu dem Testverwalter 106, so daß derselbe in der Lage ist, unterschiedliche Typen von Messungen zu unterstützen.
Eine Zeitsynchronisierung der Messungen, die durch das NTC 100 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung durchgeführt werden, ist für eine orchestrierte Testverwaltung notwendig. Eine Zeitsynchronisierung der Messungen, die beobachtet werden, kann durch das NTC 100 auf viele unterschiedliche Weisen durchgeführt werden. Zum Beispiel im Hinblick auf SNMP-Messungen stempelt die Datensammelvorrichtung 103 die Daten zeitmäßig, üblicherweise durch Nehmen einer absoluten Zeit, aber dieselbe behält ferner eine relative Zeit darüber, wann eine Meßbeobachtung basierend auf „Systemzeitticks" aufgetreten ist. Die Systemzeitticks beziehen sich üblicherweise auf einen bestimmten beliebigen Startpunkt. Das Verwaltungssystem kann einen absoluten Zeitstempel erhalten, durch Vergleichen einer aktuellen Zeit mit dem aktuellen Zeitsystemtickwert, und skaliert diesen dann in absolute Zeit. Dann sind alle Systemzeitticks, die den Beobachtungen zugeordnet sind, relativ zu dem Datentakt in dem Datensammelsystem.
Das NTC 100 ist gemäß einem Ausführungsbeispiel der vorliegenden Erfindung in der Lage, viele unterschiedliche Typen von Agenten 101 zu implementieren, die unterschiedliche Typen von Protokollen unterbringen, die oben aufgelistet sind. Ferner sind die Typen von Agenten 101, die durch das NTC 100 der vorliegenden Erfindung implementiert werden könnten, wie oben aufgelistet ist, und die Protokolle, die durch diese unterschiedlichen Typen von Agenten 101 untergebracht werden könnten, nur zu Darstellungszwecken bereitgestellt und nicht auf dieselben beschränkt.
Es ist bekannt, daß unterschiedliche Agenten 101 unterschiedliche Zeitsynchronisierungstechniken zum Liefern von Daten aufweisen. Bei dem NTC 100 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung kann jede dieser Zeitsynchronisierungstechniken, die durch die unterschiedlichen Agenten 101 angenommen werden, die mit dem NTC 100 verwendet werden sollen, in demselben implementiert und miteinander synchronisiert werden. Beispiele der Agenten, die zusammen mit dem NTC 100 der vorliegenden Erfindung verwendet werden können, sind nachfolgend ausschließlich zu Darstellungszwecken bereitgestellt und sind nicht auf dieselben beschränkt.
Bestimmte Agenten 101 sind in der Lage, ihre eigene „Zeitstempelungu" durch Zeitsystemprotokolle durchzuführen, wie z. B. NTP. Diese Technik wird durch das NTC zum Bereitstellen einer Synchronisierung von verteilten Messungen unterstützt. Ein anderer Typ einer Zeitsynchronisierung, der durch die Agenten bereitgestellt wird, umfaßt das Aufweisen eines „gemeinsamen Takts", der zu einer Gruppe von Agenten verteilt wird, und als „Taktverteilung" bekannt ist. Hier werden die Messungen innerhalb der Agenten auf den gemeinsamen Takt synchronisiert. Die Verwaltungsstation ist mit dem gemeinsamen Takt so synchronisiert, daß eine Absolut zeit erhalten werden kann. Ein anderer Typ einer Zeitsynchronisierung, der durch das NTC-System 100 der vorliegenden Erfindung unterstützt wird, umfaßt eine „diskrete Datensammlung". Hier wird ein Beobachtungspunkt gesammelt und mit dem Systemtakt verglichen, derart, daß eine Steuerung darüber vorliegt, wann die Lesung durchgeführt wird. Andere Agenten, die mit dem NTC 100 der vorliegenden Erfindung implementiert sein können, weisen ihren eigenen Systemtakt auf, der periodisch angepaßt werden kann, um denselben relativ genau im Hinblick auf den Systemtakt zu halten. Wenn der Agent ein aktives Synchronisierungsprotokoll aufweist, wie z. B. ein NTP-Protokoll, verwendet das NTC-System 100 der vorliegenden Erfindung dieses Verfahren der Zeitsynchronisierung. Bestimmte der häufiger verwendeten Zeitsynchronisierungstechniken, die mit dem NTC 100 der vorliegenden Erfindung implementiert sein können, wurden oben ausschließlich zu Darstellungszwecken aufgelistet, es können jedoch viele andere Zeitsynchronisierungstechniken mit dem NTC 100 der vorliegenden Erfindung implementiert werden, wie z. B. eine absolute Zeitsynchronisierung (wichtig für Server-Zu-Server- und Agent-Zu-Agent-Datenkorrelation), „GPS", „Interne Zeitbasen" (die extremsten physischen Schichtmessungen, die Takte umfassen, die in synchronen, netzwerk-erfordernden, internen Laborebenen-Präzisionszeitbasen verwendet werden), „Synchronisierung durch Verwaltungsstationsabfrage" (wo die Verwaltungsstation eine Datensynchronisierung durch Durchführen von Meßbeobachtungen an abgefragten Intervallen liefert) etc.
4-6 stellen Sequenzdiagramme für die Typen von Messungen dar, die oben unter der Steuerung eines Testverwalters 106 beschrieben sind. Es wird darauf hingewiesen, daß diese Tests, die durch das NTC 100 der vorliegenden Erfindung durchgeführt werden, wie in den 4-6 gezeigt ist, nur zu Darstellungszwecken vorliegen, und daß die unterschiedlichen orchestrierten Tests, die durch das NTC 100 der vorliegenden Erfindung durchgeführt werden können, nicht auf dieselben beschränkt sind.
4 stellt einen Test dar, der aus einer einzelnen diskreten Messung zusammengesetzt ist. Hier wird ein orchestrierter Test bei Operation 23 gestartet, entweder durch eine Eingabe von einem Benutzer (an der GUI 107) oder durch ein automatisiertes Verfahren (an der API 108). Dann weist der Testverwalter 106 das orchestrierte Verhalten der Agentenmessung bei Operation 501 an, einschließlich welcher Agent zu einer gegebenen Zeit implementiert wird. Dann liefert der Agentenverwalter 104 spezifische Informationen (Meta-Kenntnisse) über die Verwaltung der Daten, die gemessen werden sollen, einschließlich Vorkonfigurations-Einstellungsinformationen 502, und Anweisungen, die Messung 503 zu starten. Sobald die Meta-Kenntnisse durch den Agentenverwalter 104 geliefert werden, liefert der Agent 101 die Messung. Dann empfängt die Datensammelvorrichtung 103 die Meßergebnisse 504 und leitet die Ergebnisse 505 an den Testverwalter für eine Präsentation oder Speicherung 29 an der GUI 107 oder der API 108 weiter.
5 stellt einen umfassenderen Test dar, der aus einzelnen in Intervalle unterteilten Messungen zusammengesetzt ist. Hier, wie in 4 durchgeführt wurde, wird ein orchestrierter Test bei Operation 23 gestartet, entweder durch eine Eingabe von einem Benutzer (an der GUI 107) oder durch einen automatisierten Prozeß (an der API 108). Dann weist der Testverwalter 106 das orchestrierte Verhalten der Agentenmessung bei Operation 501 an, einschließlich welcher Agent implementiert wird, um die Daten zu liefern, die zu der Zeit gemessen werden sollen. Dann liefert der Agentenverwalter 104 spezifische Informationen (Meta-Kenntnis) über die Verwaltung der Daten, die gemessen werden sollen, einschließlich Vorkonfigurations-Einstellungsinformationen 502 und Befehle zum Starten der Messung 503. Sobald die Meta-Kenntnisse durch den Agentenverwalter 104 geliefert werden, liefert der Agent 101 die Messung bei Operation 504 zu der Datensammelvorrichtung. Die Datensammelvorrichtung 103 empfängt die Meßergebnisse bei Operation 504 und dann wiederum bei verschiedenen weiteren Intervallen, d. h. den Operationen 507 und 508, und leitet dann die im Lauf der Zeit bei Operation 505 gesammelten Ergebnisse an den Testverwalter 106 weiter, der die Ergebnisse dann für eine Präsentation oder Speicherung entweder an die GUI 107 oder die API 108 bei Operation 29 weiterleitet.
6 stellt einen Test dar, der aus einer einzelnen progressiven Messung zusammengesetzt ist. Hier und oben wird ein orchestrierter Test bei Operation 23 entweder durch eine Eingabe von einem Benutzer (an der GUI 107) oder durch einen automatisierten Prozeß (bei der API 108) gestartet. Dann weist der Testverwalter 106 das orchestrierte Verhalten der Agentenmessung bei Operation 501 an, einschließlich welcher Agent implementiert wird, um die Daten zu liefern, die zu der Zeit gemessen werden sollen. Dann liefert der Agentenverwalter 104 spezifische Informationen (Meta-Kenntnisse) über die Verwaltung der Daten, die gemessen werden sollen, einschließlich Vorkonfigurations-Einstellungsinformationen, bei Operation 502 sowie Befehle zum Starten der Messung bei Operation 503. Sobald die Meta-Kenntnisse durch den Agentenverwalter 104 geliefert werden, liefert der Agent 101 die Messung. Dann empfängt die Datensammelvorrichtung 103 das Meßergebnis bei Operation 504 und leitet dasselbe dann bei Operation 505 zu dem Testverwalter 106 weiter. Dann prüft der Agent 101 den Status der Messung bei Operation 508, liefert einen Fortschritt der Messung bei Operation 32 und liefert dann eine Benachrichtigung zu der Datensammelvorrichtung 103, wenn der Fortschritt der Messung bei Operation 501 abgeschlossen ist. Jedes Mal, wenn der Agent 101 eine Aktualisierung (Fortschritt) der Messung liefert, sendet die Datensammelvorrichtung 103 das aktualisierte Meßergebnis an den Testverwalter, d. h. Operationen 511 und 512. Sobald der Test abgeschlossen ist, werden die zusammengesetzten Meßergebnisse bei Operation 29 entweder zu der GUI 107 oder der API 108 geliefert, für Operationen wie z.B. Präsentation, etc.
Sobald die Tests durchgeführt wurden, wie oben erwähnt wurde, werden die Ergebnisse in einer oder mehreren Datenbanken 105 gespeichert. Bestimmte der Datenbanken 105, die mit dem NTC 100 implementiert sein können, umfassen eine relationale Datenbank und/oder eine XML. Da die individuellen Meßergebnisse weit abweichen können, können mehrere Datenbanken erforderlich sein. Zum Beispiel kann zum Speichern der Ergebnisse einer Liste, die Hostnamen, Netzwerkadressen, Protokollnamen, numerische Daten, etc. enthält, entweder eine flache Dateispeicherung oder eine XML implementiert sein und keine relationale Datenbank. Ein anderes Beispiel für das Implementieren einer XML- oder flachen Dateispeicherung kann in dem Fall sein, in dem die Ergebnisse eines Paketerfassungsspeicherauszugs gespeichert werden.
Das NTC 100 (gemeinsame Plattform) führt dann die Operation des Zusammenfassens der Ergebnisse des Tests durch, der mehrere heterogene Messungen enthält. Sobald die Ergebnisse zusammengefaßt sind, kann eine detaillierte Präsentation für eine Betrachtung aufgebaut und geliefert werden. Das NTC 100 implementiert ferner eine Präsentationsvorrichtung 400, die bezugnehmend auf die 7-9 detaillierter beschrieben wird.
Eine Form der Zusammenfassung der Testergebnisse umfaßt eine Ansammlung. Bei einem Ausführungsbeispiel der vorliegenden Erfindung verwendet das NTC 100 einen Mechanismus, der RYG (Red-Yellow-Green = Rot-Gelb-Grün) genannt wird, der an SNMP-Daten angewendet wird und nachfolgend in Formel 1 dargestellt ist.
Formel (1)

y = f(x) wobei
y = 3,0 wobei x >= Cmax
y = 2,0 + (x – Tyr)/(Cmax – Tyr) wobei Cmax > x >= Tyr
Y = 1,0 + (x – Tgy)/(Tyr – Tgy) wobei Tyr > x >= Tgy
Y = x/(Tgy – Cmin) wobei Tgy > x >= Cmin
y = 0,0 wobei x < Cmin

Hinweis: Obwohl er dargestellt ist, um an den positiven Fall angewendet zu werden, kann dieser Ausdruck für den negativen Fall (höher ist besser) oder zusammengesetzte Fälle modifiziert werden, wo mehrere positive und negative Bereiche innerhalb der Eingangsfunktion vorliegen.
Bei der RYG-Transformation ist x die Eingabe in die Transformationsfunktion, y ist die Ausgabe derselben, Cmin ist ein minimaler Beschränkungswert, Cmax ist ein maximaler Beschränkungswert, Tyr ist die zweite Schwelle ausgedrückt in denselben Einheiten wie der x-Wert und Tgy ist die erste Schwelle ausgedrückt in den selben Einheiten wie der x-Wert. Der Ausdruck kann für negative Fälle modifiziert werden, wo ein höheres x besser ist, oder zusammengesetzte Fälle, wo mehrere positive und negative Bereiche innerhalb der Eingangsfunktion vorliegen. Ausführungsbeispiele der vorliegenden Erfindung sind nicht auf die RYG-Transformation beschränkt, da andere Funktionen zum Normieren der Daten verwendet werden können.
Innerhalb der Testarchitektur kann die RYG wie folgt angewendet werden. Zuerst werden die Schlüsselmaße oder wesentlichen Statistiken, die die Meßergebnisse an jedem Beobachtungspunkt am besten charakterisieren, identifiziert. Dann wird die RYG-Transformation angewendet, unter Verwendung der geeigneten Schwellen, um ein normiertes Ergebnis zu erzeugen, das auf einen bestimmten Punkt in dem RYG-Kontinuum abgebildet wird. 10 stellt z. B. einen Graphen des Prozentsatzes der Zeit dar, für die ein Netzwerkelement nicht verfügbar ist, während dasselbe auf zwei Schwellen basiert. Zum Beispiel ist die erste Schwelle bei 1,0 normiert, während die zweite Schwelle bei 2,0 normiert ist. Der grüne Abschnitt ist die normale Operationsregion; der gelbe Abschnitt ist der Warnabschnitt; und der rote Abschnitt ist die kritische Region. Innerhalb dieses nor mierten Raums können die Schlüsselmaße kombiniert, verglichen, eingesammelt, etc. werden, unabhängig von Maßstab oder Einheiten. Ein Beispiel der normierten Daten, die die RYG-Transformation verwenden, wird wie folgt bereitgestellt. Bei normierten Werten in einem Kontinuum von 0,0 bis 3,0, wäre 0,0 der beste Referenzwert, während 3,0 der schlechteste Referenzwert wäre. Für normierte Daten, die unter einer ersten Schwelle liegen, d. h. einem normierten Wert von 1,0, kann grün verwendet werden; für normierte Daten, die bei oder über der ersten Schwelle liegen, d. h. dem normierten Wert bei 1,0, aber unter der zweiten Schwelle, d. h. dem normierten Wert bei 2,0, kann gelb verwendet werden; für normierte Daten, die bei oder über der zweiten Schwelle liegen, d. h. dem normierten Wert bei 2,0, kann rot verwendet werden. Für eine Verwendungsmessung könnte GY (Grün-Gelb) 33% sein und YR (Gelb-Rot) könnte 66% sein. Somit wäre 33% auf 1,0 auf dem Kontinuum normiert und 66% wäre auf 2,0 auf dem Kontinuum normiert.
Ausführungsbeispiele der vorliegenden Erfindung sind nicht auf die Kombination von Rot, Gelb und Grün beschränkt. Zum Beispiel könnte eine andere Farbe oder Farbkombination verwendet werden. Ausführungsbeispiele der vorliegenden Erfindung sind nicht auf bestimmte Farben für bestimmte Schwellbereiche begrenzt. Zum Beispiel könnte Rot oder eine andere Farbe für normierte Daten unter der ersten Schwelle verwendet werden, d. h. normiert bei 1,0. Ausführungsbeispiele der vorliegenden Erfindung sind nicht auf das Ändern von Farbe beschränkt, wenn die normierten Daten einer Schwelle gleichen. Zum Beispiel können die normierten Daten als grün angezeigt werden, wenn dieselben bei oder unter der ersten Schwelle liegen, d. h. normiert auf 1,0. Ausführungsbeispiele der vorliegenden Erfindung sind nicht auf das Anzeigen von normierten Daten in mehreren Farben pro vertikales Anzeigeelement beschränkt. Zum Beispiel könnte die vorliegenden Erfindung bei dem am weitesten linken vertikalen Anzeigeelement konfiguriert sein, um normierte Daten anzuzeigen, die die zweite Schwelle noch nicht über kreuzt haben, d. h. bei 2,0 in einer Farbe anstatt von zwei normiert sind. Ausführungsbeispiele der vorliegenden Erfindung sind nicht auf einen Graphen auf X- und Y-Achsen unter Verwendung von vertikalen Anzeigeelementen beschränkt. Zum Beispiel könnte eine Farbtabellenkalkulation oder eine Streukurve verwendet werden. Ausführungsbeispiele der vorliegenden Erfindung sind nicht auf das Anzeigen von nur einem Typ und Satz von Messungen zu einer Zeit beschränkt. Zum Beispiel können mehrere Graphen auf dem selben Bildschirm angezeigt werden, wobei jeder Graph einen unterschiedlichen Typ und Satz von Messungen, Schwellen etc. darstellt. Die Normierungsdarstellung kann in unterschiedliche Ebenen unterteilt werden, die z. B. mehr Zwischenbereiche aufweisen als RYG. Ein wichtiges Konzept hier ist, daß alle gewünschten Punkte an einem Punkt auf einem Kontinuum definiert sind. Alles kann unter Verwendung von Schwellen auf die normierte Skala abgebildet werden.
Eine Anzahl von Techniken kann verwendet werden, um die RYG-Ergebnisse zu präsentieren, wobei bestimmte derselben nachfolgend beschrieben sind.
Es wird darauf hingewiesen, daß nur ein sehr allgemeines Datenmodell die vielen Formate der Meßergebnisse darstellen kann, die verfügbar sind. Wie vorangehend ausgeführt wurde, da nur Zusammenfassungsdaten Teil der verallgemeinerten Darstellung sein brauchen, verwenden bei einem anderen Ausführungsbeispiel der vorliegenden Erfindung detaillierte Daten und Daten, die eine spezialisierte Darstellung erfordern, eine systemeigene Benutzerschnittstelle und werden durch einen Kontextstart zugreifbar gemacht. Diese Form der Verzonung (beim Navigieren zu einer bestimmten Ebene) auf unterschiedlichen Ebenen von Testergebnissen wird „Ebenenbewegung" genannt, und wird nachfolgend detaillierter erörtert.
Der Datentyp, der bei einer zusammenfassenden Darstellung nützlich ist, wird nachfolgend aufgelistet:

1. Eine-Leitung-Testzusammenfassung;
2. RYG-Ansammlung, unter Verwendung einer Darstellung wie z. B. Auf-Einen-Blick-Diagramme und Radardiagramme;
3. Korrelations-Graphen und -Tabellen, die eine Zeitachsenkorrelation umfassen;
4. Zusammenfassungswerte, die Teil einer konsolidierten Zusammenfassungsergebnistabelle sein könnten; und
5. Andere Zusammenfassungsdaten für Graphen und Tabellen, die als Zwischenabwärtsebenenbewegungen von der Zusammenfassungsseite dargestellt werden könnten, und Kontextstartinformationen für eine Zuordnung zum zur Ebenenabwärtsbewegung von den obigen vier Präsentationen.

Dieser Lösungsansatz könnte einfach durch ein einfaches Objektmodell berücksichtigt werden, oder alternativ ein einfaches XML-Dokument, das von dem Testverwalter 106 zu einer Testberichtvorrichtung 400 gesendet werden würde (d. h. eine Testergebnis-GUI-Bildschirm/Präsentations-Vorrichtung). Das XML-Beispiel wird als nächstes ausschließlich zu darstellenden Zwecken beschrieben. Die Testberichtsvorrichtung 400 (ebenfalls bezeichnet als eine Präsentationsvorrichtung) setzt einfach die Stücke von jedem orchestrierten Test zusammen und baut eine darstellende Präsentation desselben auf einer Zusammenfassungsseite auf (siehe 7). Dies liefert einen in Phasen aufgeteilten Lösungsansatz, der sehr umfassend zum Implementieren von zukünftigen Anforderungen ist. Wie in 7 dargestellt ist, umfaßt die erste Phase, die an der Präsentationsvorrichtung 400 bereitgestellt ist, einfach die Eine-Leitung-Testzusammenfassung und die Kontextstartinformationen. Andere Informationen können inkrementell hinzugefügt werden, wie an der Präsentationsvorrichtung 400 in 8 dargestellt ist.
In 8 werden Symbole bereitgestellt, die eine „Ebenenbewegung" durchführen können. Diese Ebenenbewegung ermög licht es einem Benutzer, die Testberichtvorrichtung von einer Ebene der Testergebnisse zu einer anderen Ebene zu starten, z. B. abhängig von den spezifischen Eigenschaften der gewünschten Ergebnisse. Anders ausgedrückt, ermöglicht es eine Ebenenbewegung einem Benutzer, interaktiv von zusammengesetzten Darstellungen von Testergebnissen zu einer detaillierteren Darstellung von Testergebnissen zu navigieren und umgekehrt. Genauer gesagt kann eine höhere Ebene (Zusammenfassungspräsentationsebene) der Testergebnisse durch Aktivieren einer Verbindung betrachtet werden, die eine Navigation zu einer systemeigenen Benutzerschnittstelle ermöglicht, während es die Navigationsverbindung einem Benutzer ermöglicht, nach unten zu einer Präsentation detaillierterer Ebene der Testergebnisse zu navigieren oder sich zu dorthin bewegen.
Zusätzliche Datenformate, die Testergebnisse darstellen, können durch die Testberichtvorrichtung 400 (Präsentationsvorrichtung) gemäß einem Ausführungsbeispiel der vorliegenden Erfindung präsentiert werden, durch Starten oder Bewegen zu anderen Ebenen, abhängig von dem Ausmaß des Testens, das durch das NTC 100 ausgeführt wird.
9 stellt ein Beispiel zum Kombinieren von Meßergebnissen und Zusammensetzen der Zusammenfassungsseite der Testberichtvorrichtung 400 (Präsentationsvorrichtung) aus den individuellen Ergebnisdokumenten basierend auf dem Beispiel aus 8 dar.

Claims

Vorrichtung, die folgende Merkmale aufweist: eine Plattform, die Messungen definiert, die an einem Netzwerk durchgeführt werden, die Einstellungen von Vorrichtungen auf dem Netzwerk definiert, von dem heterogene Daten geliefert werden, um die Messungen durchzuführen, die die einstellungskonfigurierten Vorrichtungen verriegelt, um die Vorrichtungen zuzuweisen, um die heterogenen Daten zu liefern, und die Tests durchführt, um die heterogenen Messungen (101a– c, 102) von den verriegelten Vorrichtungen durchzuführen.
Vorrichtung gemäß Anspruch 1, bei der das Definieren das Bestimmen der Anzahl von Messungen aufweist, die durchgeführt werden sollen.
Vorrichtung gemäß Anspruch 2, bei der die Messungen, die durchgeführt werden sollen, Messungen sind, die durch Beobachten des Netzwerks erhalten werden.
Vorrichtung gemäß Anspruch 2 oder 3, bei der die Messungen, die durchgeführt werden sollen, Messungen eines Ansprechverhaltens auf einen Stimulus sind, der als Teil des Meßaufbaus erzeugt wird.
Vorrichtung gemäß einem der Ansprüche 1 bis 4, bei der das Definieren das Bestimmen der Vorrichtungen aufweist, die implementiert werden sollen, um die heterogenen Daten zu liefern.
Vorrichtung gemäß einem der Ansprüche 1 bis 5, bei der die Plattform eine GUI (107) aufweist, um einen Benutzers anzuleiten, Konfigurationseinstellungen für jede der Vorrichtungen einzugeben, die heterogene Daten liefern.
Vorrichtung gemäß einem der Ansprüche 1 bis 6, die ferner eine API (108) aufweist, um automatisch Konfigurationseinstellungen für jede der Vorrichtungen einzugeben, die heterogene Daten liefern.
Vorrichtung gemäß einem der Ansprüche 1 bis 7, die ferner Verriegelungen aufweist, um eine bestimmte Vorrichtung zu verriegeln, die angeforderte heterogene Daten liefert.
Vorrichtung gemäß einem der Ansprüche 1 bis 8, die ferner eine entfernte API (108) aufweist, um das Abspielen eines Tests zu starten.
Vorrichtung, die folgendes Merkmal aufweist: einen Rahmen (100), der einer Mehrzahl von Vorrichtungen auf einem Netzwerk gemeinsam ist, wobei der Rahmen automatisch heterogene Messungen (101a-c, 102) synchronisiert (103, 104, 105, 106), die von der Mehrzahl von Vorrichtungen über das Netzwerk durchgeführt werden.
Vorrichtung gemäß Anspruch 10, bei der der Rahmen die heterogenen Messungen (101a-c, 102) auf einer gemeinsamen Zeitskala automatisch synchronisiert (103, 104, 105, 106).
Vorrichtung gemäß Anspruch 11, bei der das Synchronisieren der heterogenen Messungen auf einer gemeinsamen Zeitskala durch Nehmen relativer Zeitdifferenzen der Messungen basierend auf Systemzeitticks durchgeführt wird.
Vorrichtung gemäß Anspruch 11 oder 12, bei der das Synchronisieren (103, 104, 105, 106) der heterogenen Messungen (101a-c, 102) auf einer gemeinsamen Zeitska- la durch Verteilen eines gemeinsamen Taktsignals durch ein Koaxialkabel durchgeführt wird.
Vorrichtung, die folgendes Merkmal aufweist: eine computerimplementierte Datensammelvorrichtung (103), die einer Mehrzahl von Vorrichtungen auf einem Netzwerk gemeinsam ist, wobei die Datensammelvorrichtung (103) automatisch heterogene Messungen (101a-c, 102) von der Mehrzahl von Vorrichtungen über das Netzwerk ansammelt.
Vorrichtung gemäß Anspruch 14, bei der die Mehrzahl von Vorrichtungen Netzwerkhosts sind, die Daten liefern, die einem Protokoll entsprechen, das durch den jeweiligen Netzwerkkost implementiert wird.
Vorrichtung gemäß Anspruch 15, bei der die Netzwerkhosts Vorrichtungen sind, die Meßdaten liefern.
Vorrichtung gemäß einem der Ansprüche 14 bis 16, die ferner einen Testverwalter (106) zum Verwalten einer Orchestrierung der Messungen aufweist, die unter der Mehrzahl von Vorrichtungen durchgeführt werden sollen, abhängig von den Ergebnissen, die von den Messungen gewünscht sind.
Vorrichtung gemäß Anspruch 17, die ferner eine Eingabeeinheit zum Eingeben von Konfigurationseinstellungen zum Steuern der Messungen aufweist, die durchgeführt werden sollen.
Vorrichtung gemäß Anspruch 18, bei der die Eingabeeinheit eine GUI (107) ist, die eine Eingabe von einem Benutzer empfängt.
Vorrichtung gemäß Anspruch 18 oder 19, bei der die Eingabeeinheit eine API (108) ist, zum automatischen Bereitstellen von Konfigurationseinstellungen.
Vorrichtung, die folgendes Merkmal aufweist: eine computerimplementierte Präsentationsvorrichtung, die heterogene Messungen (101a-c, 102) korreliert, die von einer Mehrzahl von Vorrichtungen auf einem Netzwerk durchgeführt werden, die korrelierten heterogenen Messungen auf einem Anzeigebildschirm einem Endbenutzer präsentiert und dem Endbenutzer ermöglicht, sich von einer weniger detaillierten Darstellung zu einer detaillierteren Darstellung zu bewegen.
Vorrichtung gemäß Anspruch 21, bei der die Präsentationsvorrichtung eine Zusammenfassung von heterogenen Meßergebnissen anzeigt, die eine Mehrzahl von Verbindungen umfassen, um sich nach oben oder unten zu der gewünschten Ebene der detaillierten Präsentation der Meßergebnisse zu bewegen.
Verfahren zum Integrieren von heterogenen Messungen (101a-c, 102), die von einer Mehrzahl von Datenquellen in einem gemeinsamen Netzwerk empfangen werden, das folgende Schritte aufweist: Definieren von jeder der Messungen, die mit dem Dienst von zumindest einer Datenquelle durchgeführt werden sollen; Konfigurieren von Einstellungen der Datenquelle, in der die Messungen durchgeführt werden sollen; Verriegeln der Datenquelle (102), in der die Messung durchgeführt werden soll; Durchführen von Messungen an den Daten, die von der verriegelten Datenquelle empfangen wurden; Synchronisieren der durchgeführten heterogenen Messungen (101a-c, 102); und Präsentieren der heterogenen Messungen (101a-c, 102) auf einer gemeinsamen Skala.
Verfahren gemäß Anspruch 23, bei dem das Definieren das manuelle Auswählen der Daten aufweist, die durch eine GUI (107) gemessen werden sollen.
Verfahren gemäß Anspruch 23 oder 24, bei dem das Definieren das automatische Auswählen der Daten aufweist, die durch eine API (108) gemessen werden sollen.
Verfahren gemäß einem der Ansprüche 23 bis 25, bei dem das Konfigurieren der Einstellungen das Erhalten von Konfigurationseinstellungen für die Messungen manuell durch eine GUI (107) aufweist.
Verfahren gemäß einem der Ansprüche 23 bis 26, bei dem das Konfigurieren der Einstellungen das Erhalten von Konfigurationseinstellungen für die Messungen automatisch durch eine API (108) aufweist.
Verfahren gemäß einem der Ansprüche 23 bis 27, bei dem das Verriegeln von Ressourcen das Verriegeln des gemeinsamen Netzwerks an der Datenquelle aufweist, die die gewünschte Messung liefert.
Verfahren gemäß einem der Ansprüche 23 bis 28, bei dem das Synchronisieren der heterogenen Messungen (101a-c, 102) das Plazieren der unterschiedlichen Messungen auf einer gemeinsamen Zeitskala aufweist.
Verfahren gemäß Anspruch 29, bei dem das Plazieren der unterschiedlichen Messungen auf einer gemeinsamen Zeitskala das Nehmen von relativen Zeitdifferenzen der Messungen basierend auf Systemzeitticks aufweist.
Verfahren gemäß Anspruch 29 oder 30, bei dem das Plazieren der unterschiedlichen Messungen auf einer gemeinsamen Zeitskala das Verteilen eines gemeinsamen Taktsignals durch ein Koaxialkabel aufweist.
Verfahren gemäß einem der Ansprüche 23 bis 31, bei dem das Präsentieren der heterogenen Messungen (101a-c, 102) auf einer gemeinsamen Skala das Normieren der heterogenen Messungen aufweist.
Verfahren gemäß Anspruch 32, das ferner das Bereitstellen eines Kontextstroms für Daten aufweist, die eine spezialisierte Präsentation erfordern.
Verfahren zum Koordinieren von Gruppen von heterogenen Messungen in einer gemeinsamen Plattform, das folgende Schritte aufweist: Bereitstellen einer Mehrzahl von Datenquellen (101a– 101n), wobei jede Datenquelle einen unterschiedlichen Typ von Daten im Hinblick auf eine andere Datenquelle enthält; Messen der unterschiedlichen Typen von Daten (501) aus der Mehrzahl von Datenquellen; und Normieren der gemessenen Ergebnisse (104) auf einer gemeinsamen Skala.
Verfahren gemäß Anspruch 34, bei dem das Messen der unterschiedlichen Typen von Daten das Verriegeln an einer spezifischen Datenquelle (102) aufweist, in der Daten gemessen werden sollen, vor dem Messen der Daten aus dieser Datenquelle.
Verfahren gemäß Anspruch 35, bei dem das Messen der unterschiedlichen Datentypen ferner das Synchronisieren der unterschiedlichen Datentypen aufweist, die auf einer gemeinsamen Zeitskala gemessen (104) werden.
Verfahren gemäß Anspruch 36, bei dem das Synchronisieren der unterschiedlichen Datentypen das Nehmen von relativen Zeitdifferenzen (103) der Messungen basierend auf Systemzeitticks aufweist.
Verfahren gemäß Anspruch 36 oder 37, bei dem das Synchronisieren der unterschiedlichen Datentypen das Verteilen eines gemeinsamen Taktsignals durch ein Koaxialkabel zu der Mehrzahl von Datenquellen (101a-n) aufweist.
Verfahren gemäß einem der Ansprüche 36 bis 38, bei dem das Synchronisieren der unterschiedlichen Datentypen das Zeitstempeln (103) der gemessenen Daten aufweist.
Verfahren gemäß einem der Ansprüche 34 bis 39, bei dem das Normieren das Anwenden der nachfolgenden Formel aus die gemessenen Daten aufweist. y = f(x) wobei y = 3,0 wobei x >= Cmax y = 2,0 + (x – Tyr)/(Cmax – Tyr) wobei Cmax > x >= Tyr Y = 1,0 + (x – Tgy)/(Tyr – Tgy) wobei Tyr > x >= Tgy Y = x/(Tgy – Cmin) wobei Tgy > x >= Cmin y = 0,0 wobei x < Cmin
Verfahren gemäß einem der Ansprüche 34 bis 40, bei dem das Normieren (106) das Verwenden einer mathematischen Transformationsfunktion aufweist, um zumindest zwei heterogene skalare Meßdaten jeweils in einen homogenen mathematischen Transformationsraum zu transformieren; und Anzeigen von zumindest einer der zwei transformierten heterogenen skalaren Meßdaten.
Verfahren gemäß einem der Ansprüche 34 bis 41, bei dem das Normieren das Verwenden einer Transformationsfunktion zum Abbilden der gemessenen Ergebnisse auf einem homogenen Transformationsraum aufweist.
Verfahren gemäß Anspruch 42, bei dem das Abbilden der gemessenen Ergebnisse auf einen homogenen Transformationsraum das Verwenden von Schwellwerten aufweist, um die gemessenen Ergebnisse in eine Zusammenfassungsform zu versetzen.
Verfahren gemäß einem der Ansprüche 40 bis 43, bei dem die Formel an negative Daten angewendet wird.
Vorrichtung, die folgendes Merkmal aufweist: einen gemeinsamen Rahmen (100) zum Korrelieren von Messungen, die aus unterschiedlichen Vorrichtungen erhalten werden, wobei zumindest zwei der Vorrichtungen Daten eines unterschiedlichen Typs liefern, durch Synchronisieren der Messungen, die von den unterschiedlichen Vorrichtungen erhalten werden.
Vorrichtung gemäß Anspruch 45, bei der das Synchronisieren der erhaltenen Messungen eine Einheit aufweist, um relative Zeitdifferenzen basierend auf Systemzeitticks zu nehmen, um die erhaltenen Messungen zeitmäßig zu stempeln.
Netzwerkfehlersuchsystem, das folgende Merkmale aufweist: zumindest zwei Datenquellen, wobei jede Datenquelle Daten eines unterschiedlichen Typs im Hinblick auf eine andere Datenquelle liefert, die gemessen werden soll; einen Datenquellverwalter, der eine Verwaltung dafür liefert, wie die unterschiedlichen Datentypen gemessen werden sollen; eine Datensammelvorrichtung (103), die Informationen liefert, die für das Netzwerkfehlersuchsystem notwendig sind, um die unterschiedlichen Datentypen zu messen, die durch die zumindest zwei Datenquellen geliefert werden; eine Datenbank (105) zum Speichern der durchgeführten Messungen; und einen Testverwalter (106) zum Verwalten des Verhaltens der Messungen an den unterschiedlichen Datentypen, die durch die zumindest zwei Datenquellen geliefert werden.
Netzwerkfehlersuchsystem gemäß Anspruch 47, bei dem die unterschiedlichen gemessenen Datentypen auf einer gemeinsamen Zeitskala synchronisiert werden.
Netzwerkfehlersuchsystem gemäß Anspruch 48, bei dem die unterschiedlichen Datentypen durch Zeitstempeln zeitsynchronisiert werden, wobei eine Zeitgebung basierend auf Systemzeitticks bereitgestellt wird, die einen gemeinsamen Takt aufweisen, der zu jeder der zumindest zwei Datenquellen verteilt wird, die die Daten mit einem Systemtakt vergleichen oder einen GPS-Empfänger verwenden.
Netzwerkfehlersuchsystem gemäß einem der Ansprüche 47 bis 49, bei dem die zumindest zwei Datenquellen einen Router, einen Stimmtester, eine Netzwerkanalysevorrichtung oder eine Netzwerksonde aufweisen.
Vorrichtung, die folgendes Merkmal aufweist: eine computerimplementierte Präsentationsvorrichtung, die heterogene Messungen korreliert, die von einer Mehrzahl von Vorrichtungen auf einem Netzwerk durchgeführt werden, und die Messungen auf einer gemeinsamen Skala für eine zusammengefaßte Präsentation der heterogenen Messungen (101a-c, 102) ansammelt.
Vorrichtung gemäß Anspruch 51, die ferner eine Ebenenbewegungseinheit aufweist, um es einem Endbenutzer zu ermöglichen, sich von der zusammengefaßten Darstellung der heterogenen Messungen zu einer detaillierteren Darstellung der heterogenen Messungen zu bewegen.