DE102007054648B4

DE102007054648B4 - Fehler-Identifikation in einem rechner-basierten Netzwerk

Info

Publication number: DE102007054648B4
Application number: DE102007054648A
Authority: DE
Inventors: Robert Bielig; Thomas Dr. Hertlein; Roland Knörl; Frank Strobel
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2007-11-15
Filing date: 2007-11-15
Publication date: 2010-07-29
Anticipated expiration: 2027-11-16
Also published as: DE102007054648A1; US20090161559A1; US8385213B2

Abstract

Verfahren zum Identifizieren von möglichen Fehlerursachen in einem Netzwerk (NW), umfassend eine Vielzahl von rechner-basierten Knoten (K) mit folgenden Verfahrensschritten:
– Ausgehend von einem Steuerknoten (S) wird die Ausführung eines jeweils lokal ablaufenden Test-Moduls (TM) auf allen oder auf ausgewählten zu testenden Knoten (K) zur Identifikation von möglichen Fehlerursachen auf dem jeweiligen Knoten (K) getriggert;
– Testen einer Netzwerkverbindung zwischen allen oder ausgewählten zu testenden Knoten (K) zur Identifikation von möglichen Fehlerursachen;
– Erfassen eines Ergebnisses (E), umfassend eine Fehlerursache, falls eine solche identifizierbar ist, wobei das Testen der Knoten (K) durch Ausführen der Test-Module (TM) nicht in einem Zeitraum erfolgt, zu dem die Netzwerkverbindung zwischen den beteiligten Knoten (K) getestet wird.

Description

Die Erfindung liegt auf den Gebieten der Datenverarbeitung und der Medizintechnik und betrifft insbesondere ein Verfahren zum Identifizieren von möglichen Fehlerursachen in einem Netzwerk, das aus einer Vielzahl von rechner-basierten Knoten besteht, wie z. B. rechner-gestützte CT-Anlagen, Kernspin-Tomographen, Postprocessing-Geräte oder sonstige Laborgeräte oder dergleichen.
Gerade auf dem Gebiet der Medizintechnik ist es unabdingbar, dass ein Fehler, der innerhalb des Netzwerkes festgestellt wird, so schnell wie möglich gelöst werden kann. Dafür ist es eine Voraussetzung, den Fehler so schnell wie möglich und so detailliert wie möglich zu lokalisieren.
Im Stand der Technik ist eine Vielzahl von Ansätzen bekannt, um Fehler in einem verteilten rechner-basierten System zu finden.
So offenbart die US 5,732,213 A ein System und ein Verfahren zum Testen von bestimmten Ebenen (layers) einer Schnittstelle (Open System Interconnection, OSI) in einem Telekommunikationsnetzwerk. Das dort vorgeschlagene Konzept basiert darauf, einen Datenübertragungsprotokoll-Simulator zu verwenden. Darüber hinaus wird ein Emulator verwendet, um einen entfernten Knoten in dem Netzwerk hinsichtlich einer Applikationsebene (des ISO-OSI-Schichtenmodells) zu emulieren. Somit werden hier zu testende Module eines Netzwerkknotens auf einem anderen Test-Netzwerkknoten simuliert bzw. emuliert.
Darüber hinaus offenbart die US 5,937,165 A ein System, ein Verfahren und ein Computerprogrammprodukt zum Testen von Netzwerksystemen hinsichtlich ihrer Performance. Dazu wird in einem ersten Schritt eine erwartete Netzwerkbelastung auf dem Netzwerk bestimmt. Darauf basierend wird ein Test-Szenario ausgeführt, das auf den erwarteten Netzwerkbelastungen aufsetzt. Das Test-Szenario berücksichtigt aktuelle Betriebssystembedingungen, unterschiedliche Netzwerkprotokolle wie z. B. TCP/IP oder APPC.
Des Weiteren offenbart die US 6,996,067 B1 eine Vorrichtung und ein Verfahren zur Messung eines Datendurchsatzes zu und von einem paketvermittelnden Datennetzwerk. Insbesondere wird ein Verbindungstest bei DSL-Verbindungen beschrieben.
Darüber hinaus offenbart die nachveröffentlichte DE 10 2007 006 614 A1 eine Elektrik/Elektronik Architektur, ein verteiltes Diagnosesystem und ein Multiagentensystem für Kraftfahrzeuge. Mit der Technik des Multiagentensystems werden Teildiagnosen von Einzelgeräten, die die verteilten Diagnoseaufgaben im zu diagnostizierenden Systemumfang wahrnehmen, zu einem Diagnoseergebnis zusammengeführt.
Außerdem offenbart die EP 0 335 917 B1 ein Verfahren zur Lokalisierung von defekten Stationen in lokalen Netzwerken mit mehreren verteilt arbeitenden Stationen, die über einen seriellen Bus Botschaften untereinander austauschen. Der Bitstrom jeder Station wird auf dem Bus mit Hilfe von Fehlererkennungsmechanismen kontinuierlich überwacht.
Allen Testsystemen aus dem Stand der Technik ist jedoch gemeinsam, dass sie vornehmlich auf das Testen des Netzwerkes an sich abstellen und eine detailliertere Testung der beteiligten Netzwerkknoten nicht prüfen. Darüber hinaus ist es bei den bestehenden Testsystemen aus dem Stand der Technik erforderlich, dass eine manuelle Interaktion an beiden Endpunkten einer Netzwerkverbindung ausgeführt wird. Mit anderen Worten muss sich ein Netzwerk-Administrator sowohl bei dem Quell-Knoten der zu testenden Netzwerkverbindung einwählen und auch bei dem Ziel-Knoten dieser Verbindung, um bestimmte Netzwerktests zu triggern bzw. ausführen zu lassen.
Sobald ein Kommunikationsproblem innerhalb eines Netzwerkes identifiziert worden ist, fokussieren die meisten Testprogramme aus dem Stand der Technik mit anderen Worten auf die Netzwerkprobleme und überprüfen insbesondere die einwandfreie Funktion der Netzwerkverbindungen (beispielsweise über ICMP-PING oder andere spezifische Protokolle). Die Überprüfung der Funktionalität der beteiligten Knoten findet hingegen zu wenig Beachtung.
Die vorliegende Erfindung hat sich deshalb zur Aufgabe gestellt, einen Weg aufzuzeigen, bei dem ein Netzwerktest auch Fehlerquellen der Netzwerkknoten berücksichtigt und ausgibt und, der einen deutlich geringeren Administrationsaufwand bedeutet. Mit anderen Worten soll ein umfassenderes Testergebnis (was auch die Netzwerkknoten berücksichtig) auf einfachere Weise möglich sein.
Diese Aufgabe wird durch die beiliegenden unabhängigen Ansprüche gelöst, insbesondere durch das Verfahren, durch ein System, durch ein Test-Modul und durch ein Computerprogrammprodukt.
Im Folgenden wird die Lösung der erfindungsgemäßen Aufgabe anhand des Verfahrens beschrieben. Hierbei erwähnte Vorteile, Merkmale oder alternative Ausführungsformen können entsprechend auch auf die anderen Lösungen der Aufgabe (also auf die anderen Kategorien der Patentansprüche wie z. B. Vorrichtung, Produkt, etc.) übertragen werden und umgekehrt. Die entsprechenden funktionalen Merkmale werden durch entsprechende gegenständliche Merkmale, die in Hardware ausgebildet sind, gelöst.
Die Erfindung wird insbesondere gelöst durch ein Verfahren zum Identifizieren von möglichen Fehlerquellen bzw. Fehlerursachen in einem Netzwerk, umfassend eine Vielzahl von rechner-basierten Knoten, wobei das Verfahren folgende Verfahrensschritte umfasst:

– an einem rechner-basierten Steuerknoten wird die Ausführung eines jeweils lokal auf allen oder auf ausgewählten zu testenden Knoten zur Identifikation von einer möglichen Fehlerursache auf den zu testenden Knoten ablaufenden Test-Moduls getriggert;
– Testen einer Netzwerkverbindung zwischen allen oder ausgewählten Knoten des Netzwerkes, insbesondere Testen einer Netzwerkverbindung zwischen dem zu testenden Knoten und dem Steuerknoten;
– Erfassen eines Testergebnisses, umfassend zumindest eine Fehlerursache, falls eine solche identifizierbar ist.

Das ”Identifizieren” von möglichen Fehlerquellen umfasst das Lokalisieren derselben im Netzwerk, so dass als Ergebnis des Verfahrens immer ein rechner-basierter Knoten oder ein diesen eineindeutig identifizierender Hinweis ausgegeben wird.
Die Begriffe ”Fehlerursache” oder ”Fehlerquelle”, die hier synonym verwendet werden, sind sehr breit zu verstehen und umfassen grundsätzlich alle Kategorien von Fehlern, die auf allen Schichten des ISO-OSI-Schichtenmodells erfolgen können. Damit sind Netzwerkprobleme umfasst und auch solche Probleme, die an die Software oder an die Hardware des jeweiligen Knotens gebunden sind, wie z. B. eine CPU-Überlastung, Overflow im Speicherbereich, falsche Schnittstellen etc. Das Ermitteln bzw. Identifizieren von Problemen und/oder von diesbezüglichen, möglichen Fehlerursachen erfolgt üblicherweise mittels eines SOLL/IST-Wert-Vergleichs. Schwellwerte für den Vergleich, insbesondere der SOLL-Wert sind dabei konfigurierbar. So kann z. B. ein Speicherproblem erkannt werden, wenn der freien Speicherbereich auf der System-Festplatte unter einem Wert von 5% des Gesamtvolumens liegt.
Bei den Knoten handelt es sich um rechner-gestützte bzw. computer-gestützte Knoten (ggf. unterschiedlicher Art) in einem Netzwerk. Dabei kann es sich um Computer zur Nachbearbeitung von Bilddaten, um Scanner, um medizintechnische Anlagen oder sonstige digitale Geräte handeln. Die Knoten umfassen einen Steuerknoten, der sich dadurch auszeichnet, dass von ihm ausgehend das Testverfahren gesteuert wird. Darüber hinaus wird auf dem Steuerknoten das Resultat des Testergebnisses angezeigt und/oder abgelegt. In einer alternativen Ausführungsform ist es möglich, dass das Testverfahren von einem ersten Steuerrechner aus getriggert wird, während es von einem zweiten Steuerrechner aus analysiert wird, so dass das Testergebnis auf dem zweiten Steuerrechner, der sich von dem ersten Steuerrechner unterscheidet, angezeigt und dargestellt wird. Üblicherweise sind jedoch der erste und der zweite Steuerrechner identisch.
Welcher der Knoten innerhalb des Netzwerkes als Steuerknoten heranzuziehen ist, kann sich von Test zu Test unterscheiden. Der Steuerknoten ist somit dynamisch variierbar und kann nach den Gegebenheiten des Administrators oder nach sonstigen Verwaltungserfordernissen gewählt oder bestimmt werden.
Üblicherweise ist ein Test-Modul vorgesehen, das auf allen zu testenden Knoten lokal zur Ausführung gebracht wird. Es wird durch ein und denselben Steuerknoten getriggert. In alternativen Ausführungsformen ist jedoch vorgesehen, nicht ein und dasselbe Test-Modul zu verwenden, sondern knotenspezifische Test-Module, die auf die jeweiligen Anforderungen des Knotens ausgelegt sind und somit einen spezifischen Test ausführen können. Grundsätzlich sind gemäß der erfindungsgemäßen Lösung keine spezifischen Anforderungen an die Auswahl des jeweiligen Test-Moduls gestellt, abgesehen von dem Erfordernis, dass sie alle über eine definierte Web-Schnittstelle erreichbar sein müssen. Mit anderen Worten können herkömmliche, aus dem Stand der Technik bekannte Test-Module zum Einsatz kommen, die gegebenenfalls mit dieser Schnittstelle nachgerüstet werden.
Das Testen der Netzwerkverbindung wird in der Regel zwischen zwei Knoten ausgeführt, zwischen einem Quellknoten, der eine Testnachricht sendet, und einem Zielknoten, der die Testnachricht empfängt. Das Testen umfasst unter anderem einen Bandbreitentest und weitere netzwerkspezifische Größen. Das Testen der Netzwerkverbindung erfolgt üblicherweise in beide Richtungen, also ausgehend von dem Quellknoten in Richtung auf den Zielknoten und umgekehrt: Also sowohl in einer Download-Richtung als auch in einer Upload-Richtung. Bedarfsweise kann hier nur eine Richtung getestet werden.
Das Testergebnis umfasst eine oder mehrere mögliche Fehlerursachen, falls solche identifizierbar sind. In der Regel erfolgt dies in Form einer Liste, mit Einträgen der getesteten Knoten und einem Hinweis, ob der ausgeführte Test eine Fehlerquelle identifiziert hat oder nicht.
In einer vorteilhaften Ausführungsform der vorliegenden Erfindung werden die Test-Module auf den zu testenden Knoten jeweils parallel ausgeführt. Dies bringt eine Zeitersparnis mit sich und führt dazu, dass das Ergebnis des Fehler-Identifikationsverfahrens schneller zur Verfügung steht.
In der Regel ist es sinnvoll, dass in einer ersten Phase die zu testenden Knoten getestet werden und dass in einer zweiten Phase die jeweiligen Netzwerkverbindungen getestet werden.
Üblicherweise sind die Zeiträume so bemessen, dass die erste Phase und die zweite Phase keinen Überschneidungsbereich haben. Mit anderen Worten erfolgt das Testen der Knoten nicht in dem Zeitraum, in dem die Netzwerkverbindungen getestet werden. Dies hat den Vorteil, dass das Ergebnis der Durchführung der Test-Module nicht dadurch verfälscht werden kann, dass die Netzwerkverbindungen durch den Test verändert belastet werden. Vorteilhafterweise kann somit das Testen der Knoten unabhängig vom Testen der Netzwerkverbindungen ausgeführt werden. Des Weiteren kann das Testen auf den einzelnen Knoten auch jeweils unabhängig voneinander bzw. jeweils asynchron zueinander erfolgen.
Im Rahmen der Erfindung ist es durchaus möglich – und je nach anwendungsspezifischer Situation auch sinnvoll – eine andere Reihenfolgen der Verfahrensschritte zu wählen (z. B. ersten Knoten testen, Netzwerkverbindung(en) im Zusammenhang mit dem ersten Knoten testen, zweiten Knoten testen und anschließend die Netzwerkverbindung(en) im Zusammenhang mit dem zweiten Knoten, etc.). Darüber hinaus können die vorstehend erwähnten Verfahrensschritte auch verschränkt bzw. ineinander verzahnt (also mit einem zeitlichen Überschneidungsbereich) ausgeführt werden.
Wie oben bereits erwähnt, umfasst das Ergebnis in der Regel eine Liste von möglichen Fehlerquellen, wobei jeder Fehlerquelle ein Eintrag zugeordnet ist. Anschließend kann in einer vorteilhaften Weiterbildung das Testergebnis einer weiteren Analyse unterzogen werden. Hierbei werden die unterschiedlichen Einträge nach vordefinierbaren Erfahrungswerten gewichtet. So hat es sich beispielsweise bei Client-Server-Netzwerken herausgestellt, dass, falls sowohl ein Client und das Netzwerk als mögliche Fehlerquellen des Problems genannt sind, in den meisten Fällen der Fehler beim Client liegt. Falls ein Server und das Netzwerk als mögliche potenzielle Fehlerquellen identifiziert worden sind, wird aller Wahrscheinlichkeit nach der Server die Fehlerursache sein. Darüber hinaus gilt folgende Erfahrungsregel: Falls sowohl der Server als auch der Client als potenzielle Fehlerquelle identifiziert worden sind, so ist höchstwahrscheinlich der Client die Fehlerursache. Die Erfahrungswerte sind in Form von vordefinierbaren Regeln abgelegt. Diese Regeln fließen bei der Wichtung des Testergebnisses ein, so dass die jeweils wahrscheinlichste Fehlerursache an erster Stelle der Liste steht und weitere mögliche Fehlerquellen anführt, mit absteigender Wahrscheinlichkeit.
Ein wesentlicher Vorteil der erfindungsgemäßen Lösung ist darin zu sehen, dass ein Administrator zum Lokalisieren möglicher Fehlerquellen sich lediglich an einem Knoten einwählen muss, um einen Fehler in dem Netzwerk zu finden. Es ist nicht mehr notwendig, dass der sich Administrator an den jeweils zu testenden Knoten separat einwählt, wie dies im Stand der Technik der Fall war. Dafür wird eine separate Schnittstelle zwischen dem Test-Modul an einem ersten Knoten und dem Test-Modul an einem zweiten Knoten implementiert. Die Schnittstelle kann beispielsweise über einen Webservice ausgebildet sein. Die Testschritte des jeweiligen Testverfahrens können in einem Software- oder in einem Hardware-Modul auf dem Knoten implementiert sein. Dabei kommunizieren die Netzwerkknoten bzw. deren Test-Module unmittelbar miteinander.
Das jeweilige Test-Modul, das jeweils lokal auf den zu testenden Knoten implementiert ist, umfasst Hardware- und/oder Software-Module.
Gemäß einem weiteren Aspekt der Erfindung ist es vorgesehen, dass die Knoten (einschließlich des Steuerknotens) und/oder die Test-Module des jeweiligen Knotens über eine separate Schnittstelle, insbesondere über einen Webservice miteinander interagieren.
Weitere Aufgabenlösungen bestehen in einem System zum Identifizieren von möglichen Fehlerursachen in einem Netzwerk, umfassend eine Vielzahl von rechner-basierten Knoten mit:

– einem Steuerknoten, der dazu ausgebildet ist, die Ausführung eines Test-Moduls zu triggern, wobei das jeweilige Test-Modul lokal auf zumindest einem der zu testenden Knoten implementiert ist und abläuft und zur Identifizierung von möglichen Fehlerursachen auf dem Knoten dient;
– ein Verbindungstester, der dazu bestimmt ist, eine Netzwerkverbindung zwischen allen oder ausgewählten Knoten zur Identifikation von möglichen Fehlerursachen in dem Netzwerk zu testen, und
– einem Ergebnis-Modul, das dazu bestimmt ist, ein Testergebnis zu erfassen und darzustellen, wobei das Testergebnis zumindest eine Fehlerursache umfasst, falls eine solche identifizierbar ist.

Die Knoten und der Steuerknoten stehen in einer Netzwerkverbindung untereinander. Darüber hinaus können die auf dem jeweiligen Knoten implementierten Test-Module über eine separate Schnittstelle (z. B. über einen Webservice) miteinander interagieren. Die jeweiligen Test-Module sind zum Testen der jeweiligen Knoten ausgebildet, um mögliche Fehlerursachen auf dem Knoten zu identifizieren, während der Netzwerktester (Verbindungstester) zum Testen der jeweiligen Netzwerkverbindung ausgebildet ist und mögliche Fehlerursachen bereitstellt, die im Rahmen der Netzwerkverbindung auftreten können. Zum Testen des Netzwerkes wird sequentiell oder parallel eine point-to-point-Verbindung zwischen dem Steuerknoten und den zu testenden Knoten aufgebaut.
Das Ergebnis-Modul dient zum Ableiten eines Ergebnisses, das mögliche Fehlerquellen auf dem Knoten und mögliche Fehlerquellen in dem Netzwerk kombiniert anzeigt.
Eine weitere Lösung der erfindungsgemäßen Aufgabe besteht in einem Test-Modul zur Anwendung in einem System mit den Merkmalen, die oben beschrieben worden sind.
Die vorstehend beschriebenen, erfindungsgemäßen Ausführungsformen des Verfahrens können auch als Computerprogrammprodukt ausgebildet sein, wobei der Computer zur Durchführung des oben beschriebenen, erfindungsgemäßen Verfahrens veranlasst wird und dessen Programmcode durch einen Prozessor ausgeführt wird.
Eine alternative Aufgabenlösung sieht ein Speichermedium vor, das zur Speicherung des vorstehend beschriebenen, computerimplementierten Verfahrens bestimmt ist und von einem Computer lesbar ist.
Darüber hinaus ist es möglich, dass einzelne Komponenten des vorstehend beschriebenen Verfahrens in einer verkaufsfähigen Einheit und die restlichen Komponenten in einer anderen verkaufsfähigen Einheit – sozusagen als verteiltes System – ausgeführt werden können.
Weitere vorteilhafte Ausführungsformen ergeben sich aus den Unteransprüchen.
In der folgenden detaillierten Figurenbeschreibung werden nicht einschränkend zu verstehende Ausführungsbeispiele mit deren Merkmalen und weiteren Vorteilen anhand der Zeichnungen besprochen. In dieser zeigen:
1 eine übersichtsartige Darstellung von zwei beispielhaften Knoten eines Netzwerks gemäß einer bevorzugten Ausführungsform eines erfindungsgemäßen Systems,
2 ein Flow Chart gemäß einer bevorzugten Ausführungsform der Erfindung und
3 ein Flow Chart gemäß einer Variante zu der in 2 gezeigten Ausführungsform.
In 1 sind exemplarisch zwei zu testende Knoten K₁ und K₂ eines medizintechnischen Netzwerks NW dargestellt. Dabei soll K die Obermenge aller Knoten sein, während die Indizes auf die einzelnen Knoten gerichtet sind. Die Aufgabe besteht nun darin, mögliche Fehlerquellen in dem Netzwerk NW, umfassend eine Vielzahl von Knoten K, aufzuzeigen, bzw. identifizieren und zu lokalisieren. Dazu wird ein Test an dem Knoten K₁ getriggert. Dies ist in 1 mit dem nach innen weisenden Pfeil auf der rechten Seite in dem Knoten K₁ gekennzeichnet. Daraufhin wird ein lokales Test-Modul TM an dem Knoten K₁ zum Zeitpunkt, der in der 1 mit ”1” in einem Kreis gekennzeichnet ist zur Ausführung gebracht. Das Test-Modul TM überprüft die Hardware- und die Software-Module des Knotens K₁. Ein mit ”2” gekennzeichneter Pfeil von Knoten K₁ an Knoten K₂ soll ein Testen einer Netzwerkverbindung darstellen, wobei die Netzwerkverbindung von dem Knoten K₁ ausgeht und an den Knoten K₂ gerichtet ist. Bei dem mit ”3” gekennzeichneten Pfeil, der von dem Knoten K₁ an den Knoten K₂ verweist, soll gekennzeichnet sein, dass ein Servertest auf dem Knoten K₂ angefordert wird. Mit dem Kreis ”4” in dem Knoten K₂ soll gekennzeichnet sein, dass zu diesem Zeitpunkt das Test-Modul TM auf dem Knoten K₂ ausgeführt wird. Das Test-Modul wird lokal auf dem Knoten K₂ ausgeführt und überprüft die Hardware und die Software des Knotens K₂. Daraufhin kann zum Zeitpunkt ”5” (bzw. dem mit „5” gekennzeichneten Pfeil ausgehend von K₂ und auf K₁ weisend) ein Netzwerktest erfolgen. Der Netzwerktest erfolgt in diesem Fall für die Richtung der Datenübertragung: K₂ -> K₁. Anschließend können zum Zeitpunkt ”6” (bei dem mit „6” gekennzeichneten Pfeil) die Ergebnisse des Test-Moduls TM, das auf dem Knoten K₂ ausgeführt worden ist, an den Knoten K₁ übertragen werden. Abschließend wird zum Zeitpunkt „7” ein Ergebnis E der Testungen evaluiert.
Die in den Kreisen angeordneten Ziffern stellen keine Bezugszeichen dar, sondern sollen unterschiedliche Zeitpunkte oder Zeitphasen andeuten, zu denen bestimmte Verfahrensschritte zur Ausführung gebracht werden. Die übliche Abfolge ist: 1, 2, 3, 4, 5, 6, und 7. Wie bereits erwähnt sind hier jedoch auch alternative zeitliche Abfolgen und/oder zeitliche Überlappungen denkbar.
In dem in 1 dargestellten Beispiel dient der Knoten K₁ als Steuerknoten S, von dem ein Test angestoßen bzw. initiiert wird und auf dem zusätzlich das Ergebnis E erfasst, evaluiert und/oder dargestellt wird. Der Steuerknoten S ist somit aktiv und steuert die Ausführung der jeweiligen Test-Module TM, die lokal auf den zu testenden weiteren Knoten K ausgeführt werden sollen, während die weiteren Knoten K passiv verbleiben. Der Administrator muss sich lediglich auf dem Knoten K₁, der hier als Steuerknoten S dient, einloggen und muss sich keinen weiteren Zugang zu dem Knoten K₂ verschaffen. Die jeweils lokal implementierten Test-Module TM auf dem Knoten K kommunizieren über einen Webservice miteinander.
In 2 ist noch einmal schematisch ein möglicher Ablauf gemäß einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens dargestellt. In einem ersten Schritt erfolgt eine Einwahl in einen Knoten K als Steuerrechner S. In einem zweiten Schritt wird ein Test-Modul TM auf dem Steuerrechner S ausgeführt. Daraufhin wird eine Netzwerkverbindung getestet für die Richtung K₁ -> K₂. Daraufhin wird ein Servertest auf dem Knoten K₂ angefordert, der anschließend ausgeführt wird und die Hardware- und/oder Software-Module auf dem Knoten K₂ überprüft. Anschließend wird die Netzwerkverbindung in der anderen Richtung überprüft: K₂ -> K₁ und es können die Ergebnisse des Test-Moduls TM, der auf dem Knoten K₂ ausgeführt worden ist, auf den Knoten K₁ bzw. auf dem Steuerknoten S übertragen werden. Daraufhin kann ein Ergebnis E auf dem Steuerknoten S erfasst, evaluiert und dargestellt werden.
Ein alternativer Ablauf zu dem in Zusammenhang mit dem in 2 (und indirekt in 1 beschriebenen) ist in 3 dargestellt. Hier werden in einer ersten Knotentestphase alle Konten getestet und in einer zweiten Netzwerkverbindungstestphase alle relevanten Netzwerkverbindungen (vorzugsweise solche, in Zusammenhang mit den zu testenden Knoten) getestet. Der durch die Ziffern in den Kreisen in 1 dargestellte zeitliche Ablauf wäre dann entsprechend angepasst. An dieser Stelle sei darauf hingewiesen, dass natür lich auch andere zeitliche Abfolgen vom Schutzumfang dieser Erfindung umfasst sein sollen.
Ebenso ist es möglich eine Vorauswahl von zu testenden Knoten K vorzunehmen, so dass das Test-Modul TM nur auf relevanten Knoten K zur Ausführung gebracht wird, nämlich auf solchen, die möglicherweise im Zusammenhang mit einem identifizierten Fehler stehen. Gibt es beispielsweise Knoten K, die sicher nicht den identifizierten Fehler verursachen können, müssen diese Knoten K nicht notwendigerweise getestet werden.
Der in den 2 und 3 verwendete Begriff „Ausführen eines Test-Moduls TM” umfasst eine Zeitspanne zwischen dem Starten des jeweiligen Test-Moduls und dem Ableiten bzw. Erfassen oder dem Vorliegen von Ergebnissen zu diesem Test. Solange noch keine Ergebnisse E vorliegen, muss auch die Test-Modulausführung gewartet werden. Diese Wartezeit kann erfindungsgemäß durch das Anstoßen von parallelen Tests (von anderen Knoten K und/oder anderen Netwerkverbindungen) genutzt werden.
Das Netzwerkprotokoll ist nicht auf eine bestimmte Art festgelegt und vorzugsweise handelt es sich um das TCP/IP-Protokoll.
Bei dem Netzwerk kann es sich um ein Local-Area-Network (LAN) oder um Wide-Area-Network (WAN) handeln.
Vorteilhafterweise muss sich der Administrator zur Fehlersuche lediglich in den Steuerknoten S einloggen und nicht in den zu testenden Knoten K₂ etc.
Die erfindungsgemäße Lösung sieht vor, dass neben einer netzwerk-basierten Suche nach möglichen Fehlerquellen auch zusätzlich immer eine knoten-basierte Suche nach möglichen Fehlerquellen auf den beteiligten Knoten K ausgeführt wird. Die knoten-basierte Suche nach Fehlerquellen umfasst ein Testen aller oder ausgewählter Software- oder Hardware-Module des jeweiligen Knotens. Hier werden vordefinierbare Hardware- oder Software-Parameter überprüft, wie z. B. die CPU-Auslastung, der Speicherverbrauch etc. Sobald die überprüften Parameter außerhalb eines erlaubten Bereichs liegen, wird der jeweilige Knoten als mögliche Fehlerursache gekennzeichnet. Der Verbindungstester sieht ein bidirektionales Testen der jeweiligen Kommunikationsverbindung zwischen einem ersten Knoten K₁ und einem zweiten Knoten K₂ vor. Üblicherweise werden hier ein Bandbreitentest, ein Latenztest, ein Durchsetztest, ein PING-Test etc. durchgeführt. Sobald vordefinierbare Netzwerkparameter außerhalb eines erlaubten Bereichs liegen, wird das Netzwerk als mögliche Fehlerursache gekennzeichnet. Alle möglichen Fehlerursachen werden in dem Ergebnis E zusammengefasst.
Üblicherweise ist der Steuerrechner S dazu ausgelegt, alle Testergebnisse (der jeweiligen Test-Module TM) aller zu testenden Knoten K zu empfangen und zu evaluieren. Nach der Evaluierung wird üblicherweise zumindest eine mögliche Fehlerquelle abgeleitet und dargestellt. Falls eine solche Fehlerquelle nicht eindeutig identifizierbar ist (beispielsweise weil mehrere Objekte als mögliche Fehlerquellen gekennzeichnet worden sind), wird eine Liste als Ergebnis E ausgegeben, die mehrere potenzielle Fehlerquellen umfasst.
In einer vorteilhaften Weiterbildung kann das Ergebnis E noch weiter analysiert werden, indem eine Wichtung der jeweiligen Einträge erfolgt. Dies basiert auf vordefinierbaren Erfahrungswerten. In der bevorzugten Ausführungsform werden erst die möglichen Fehlerquellen, die in Zusammenhang mit einem ersten Knoten K oder mit dem Steuerknoten S auftraten, gelistet, gefolgt von möglichen Fehlerquellen, die in Zusammenhang mit einem zweiten Knoten K₂ auftraten, und weiter gefolgt von möglichen Fehlerquellen, die in Zusammenhang mit dem Netzwerk NW erfasst worden sind.
Handelt es sich um ein Client-Server-Netzwerk, so können die vorstehend erwähnten Erfahrungswerte in Form von folgenden Regeln festgehalten werden:

– ”Mögliche Fehlerquellen beim Client und im Netzwerk festgestellt” -> wahrscheinlichste Fehlerursache: ”Client”,
– ”mögliche Fehlerquellen bei Server und Netzwerk festgestellt -> wahrscheinlichste Fehlerursache: ”Server”, und
– ”mögliche Fehlerquellen bei Server und Client festgestellt” -> wahrscheinlichste Fehlerquelle: ”Client”.

Diese Regeln können jederzeit dynamisch verändert und so an die aktuellen Erfahrungen angepasst werden.
In dem in 1 dargestellten Beispiel dient der erste Knoten K₁ als Steuerknoten S, von dem aus das Testen anhand der Test-Module TM initiiert wird. Es ist jedoch jederzeit möglich, einen anderen Knoten als Steuerknoten S zu wählen.
Abschließend sei darauf hingewiesen, dass die Beschreibung der Erfindung und die Ausführungsbeispiele grundsätzlich nicht einschränkend in Hinblick auf eine bestimmte physikalische Realisierung der Erfindung zu verstehen sind. Für einen einschlägigen Fachmann ist es insbesondere offensichtlich, dass die Erfindung teilweise oder vollständig in Soft- und/oder Hardware und/oder auf mehrere physikalische Produkte – dabei insbesondere auch Computerprogrammprodukte – verteilt realisiert werden kann.

Claims

Verfahren zum Identifizieren von möglichen Fehlerursachen in einem Netzwerk (NW), umfassend eine Vielzahl von rechner-basierten Knoten (K) mit folgenden Verfahrensschritten: – Ausgehend von einem Steuerknoten (S) wird die Ausführung eines jeweils lokal ablaufenden Test-Moduls (TM) auf allen oder auf ausgewählten zu testenden Knoten (K) zur Identifikation von möglichen Fehlerursachen auf dem jeweiligen Knoten (K) getriggert; – Testen einer Netzwerkverbindung zwischen allen oder ausgewählten zu testenden Knoten (K) zur Identifikation von möglichen Fehlerursachen; – Erfassen eines Ergebnisses (E), umfassend eine Fehlerursache, falls eine solche identifizierbar ist, wobei das Testen der Knoten (K) durch Ausführen der Test-Module (TM) nicht in einem Zeitraum erfolgt, zu dem die Netzwerkverbindung zwischen den beteiligten Knoten (K) getestet wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Netzwerkverbindung zwischen jeweils zwei Knoten (K) in einer Download- und in einer Upload-Richtung getestet wird.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Test-Module (TM) auf den zu testenden Knoten (K) jeweils parallel ausgeführt werden.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Ergebnis (E) Einträge zu jeder Ausführung eines Test-Moduls (TM) umfasst, wobei die Einträge in dem Ergebnis (E) analysiert und insbesondere anhand von vordefinierbaren Regeln gewichtet werden.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Ausführen aller Test-Module (TM) auf den jeweiligen Knoten (K) ausschließlich ausgehend von dem Steuerknoten (S) getriggert wird, so dass nur ein Zugriff auf den Steuerknoten (S) erforderlich ist, um den Test auf allen oder auf ausgewählten anderen Knoten (K) auszuführen.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Test-Modul (TM) alle oder ausgewählte Hardware-Module und/oder Software-Module des zu testenden Knotens (K) umfasst.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Steuerknoten (S) und/oder das Test-Modul (TM) dessen Steuerknoten (S) über eine Webservice-Schnittstelle interagieren.
System zum Identifizieren von möglichen Fehlerursachen in einem Netzwerk (NW), umfassend eine Vielzahl von rechner-basierten Knoten (K) mit: – einem Steuerknoten (S), der dazu ausgebildet ist, die Ausführung eines Test-Moduls (TM) zu triggern, wobei das jeweilige Test-Modul (TM) lokal auf einem der zu testenden Knoten (K) implementiert ist und abläuft und zur Identifizierung von möglichen Fehlerursachen auf dem Knoten (K) dient; – ein Verbindungstester, der dazu bestimmt ist, eine Netzwerkverbindung zwischen allen oder ausgewählten Knoten (K) zur Identifikation von möglichen Fehlerursachen in dem Netzwerk (NW) zu testen, wobei das Testen der Knoten (K) durch Ausführen der Test-Module (TM) nicht in einem Zeitraum erfolgt, in dem der Verbindungstester die Netzwerkverbindung zwischen den beteiligten Knoten (K) testet, und – einem Ergebnis-Modul, das dazu bestimmt ist, ein Ergebnis (E) zu erfassen und darzustellen, wobei das Ergebnis zumindest eine Fehlerursache umfasst, falls eine solche identifizierbar ist.
Test-Modul (TM) zur Verwendung in einem System gemäß Anspruch 8, bei dem das Test-Modul (TM) als lokal auf dem zu testenden Knoten (K) implementiert ist und dessen Ausführung von dem Steuerknoten (S) getriggert wird.
Computerprogrammprodukt, welches direkt in einen Speicher eines Computers ladbar ist, mit Programm-Code-Mitteln, um alle Schritte eines Verfahrens nach zumindest einem der Verfahrensansprüche 1 bis 7 auszuführen, wenn das Programm in dem Computer ausgeführt wird.