DE102007054648A1 - Fehler-Identifikation in einem rechner-basierten Netzwerk - Google Patents

Fehler-Identifikation in einem rechner-basierten Netzwerk Download PDF

Info

Publication number
DE102007054648A1
DE102007054648A1 DE102007054648A DE102007054648A DE102007054648A1 DE 102007054648 A1 DE102007054648 A1 DE 102007054648A1 DE 102007054648 A DE102007054648 A DE 102007054648A DE 102007054648 A DE102007054648 A DE 102007054648A DE 102007054648 A1 DE102007054648 A1 DE 102007054648A1
Authority
DE
Germany
Prior art keywords
node
test
network
tested
test module
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
DE102007054648A
Other languages
English (en)
Other versions
DE102007054648B4 (de
Inventor
Robert Bielig
Thomas Dr. Hertlein
Roland Knörl
Frank Strobel
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to DE102007054648A priority Critical patent/DE102007054648B4/de
Priority to US12/267,289 priority patent/US8385213B2/en
Publication of DE102007054648A1 publication Critical patent/DE102007054648A1/de
Application granted granted Critical
Publication of DE102007054648B4 publication Critical patent/DE102007054648B4/de
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/22Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2294Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing by remote test
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/50Testing arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Debugging And Monitoring (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Die vorliegende Erfindung betrifft ein Verfahren, ein System, ein Test-Modul (TM) und ein Computerprogrammprodukt zum Identifizieren von möglichen Fehlerursachen in einem Netzwerk (NW), wobei neben dem Netzwerk (NW) auch Fehler im Hinblick auf die jeweiligen Knoten (K) berücksichtigt werden. Auf dem zu testenden Knoten (K) sind jeweils lokale Test-Module (TM) installiert, die von einem Steuerrechner (S) getriggert werden. Es werden mögliche Fehlerursachen in dem Netzwerk (NW) und in dem jeweils beteiligten Knoten (K) analysiert und in einem Ergebnis (E) zusammengefasst.

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 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 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.
  • 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 K1 und K2 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 K1 getriggert. Dies ist in 1 mit dem nach innen weisenden Pfeil auf der rechten Seite in dem Knoten K1 gekennzeichnet. Daraufhin wird ein lokales Test-Modul TM an dem Knoten K1 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 K1. Ein mit "2" gekennzeichneter Pfeil von Knoten K1 an Knoten K2 soll ein Testen einer Netzwerkverbindung darstellen, wobei die Netzwerkverbindung von dem Knoten K1 ausgeht und an den Knoten K2 gerichtet ist. Bei dem mit "3" gekennzeichneten Pfeil, der von dem Knoten K1 an den Knoten K2 verweist, soll gekennzeichnet sein, dass ein Servertest auf dem Knoten K2 angefordert wird. Mit dem Kreis "4" in dem Knoten K2 soll gekennzeichnet sein, dass zu diesem Zeitpunkt das Test-Modul TM auf dem Knoten K2 ausgeführt wird. Das Test-Modul wird lokal auf dem Knoten K2 ausgeführt und überprüft die Hardware und die Software des Knotens K2. Daraufhin kann zum Zeitpunkt "5" (bzw. dem mit „5" gekennzeichneten Pfeil ausgehend von K2 und auf K1 weisend) ein Netzwerktest erfolgen. Der Netzwerktest erfolgt in diesem Fall für die Richtung der Datenübertragung: K2 → K1. Anschließend können zum Zeitpunkt "6" (bei dem mit „6" gekennzeichneten Pfeil) die Ergebnisse des Test-Moduls TM, das auf dem Knoten K2 ausgeführt worden ist, an den Knoten K1 ü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 K1 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 K1, der hier als Steuerknoten S dient, einloggen und muss sich keinen weiteren Zugang zu dem Knoten K2 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 K1 → K2. Daraufhin wird ein Servertest auf dem Knoten K2 angefordert, der anschließend ausgeführt wird und die Hardware- und/oder Software-Module auf dem Knoten K2 überprüft. Anschließend wird die Netzwerkverbindung in der anderen Richtung überprüft: K2 → K1 und es können die Ergebnisse des Test-Moduls TM, der auf dem Knoten K2 ausgeführt worden ist, auf den Knoten K1 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 K2 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 K1 und einem zweiten Knoten K2 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 K2 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 K1 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.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • - US 5732213 [0004]
    • - US 5937165 [0005]

Claims (11)

  1. 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.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Netzwerkverbindung zwischen jeweils zwei Knoten (K) in einer Download- und in einer Upload-Richtung getestet wird.
  3. 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.
  4. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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, 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.
  10. Test-Modul (TM) zur Verwendung in einem System gemäß Anspruch 9, 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.
  11. 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 8 auszuführen, wenn das Programm in dem Computer ausgeführt wird.
DE102007054648A 2007-11-15 2007-11-15 Fehler-Identifikation in einem rechner-basierten Netzwerk Expired - Fee Related DE102007054648B4 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102007054648A DE102007054648B4 (de) 2007-11-15 2007-11-15 Fehler-Identifikation in einem rechner-basierten Netzwerk
US12/267,289 US8385213B2 (en) 2007-11-15 2008-11-07 Error identification in a computer-based network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102007054648A DE102007054648B4 (de) 2007-11-15 2007-11-15 Fehler-Identifikation in einem rechner-basierten Netzwerk

Publications (2)

Publication Number Publication Date
DE102007054648A1 true DE102007054648A1 (de) 2009-05-20
DE102007054648B4 DE102007054648B4 (de) 2010-07-29

Family

ID=40560702

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102007054648A Expired - Fee Related DE102007054648B4 (de) 2007-11-15 2007-11-15 Fehler-Identifikation in einem rechner-basierten Netzwerk

Country Status (2)

Country Link
US (1) US8385213B2 (de)
DE (1) DE102007054648B4 (de)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102804689B (zh) * 2010-02-05 2016-04-27 爱斯福公司 测试网络通信链路
DE102010043718A1 (de) * 2010-11-10 2012-05-10 Siemens Aktiengesellschaft Automatische Verbindungsanalyse für ein DICOM-Netzwerk
US9264340B2 (en) 2013-03-15 2016-02-16 Ixia Methods, systems, and computer readable media for misdirected packet drill down and negative packet capture at a network test device
US9094336B2 (en) 2013-03-15 2015-07-28 Ixia Methods, systems, and computer readable media for assisting with the debugging of conditions associated with the processing of test packets by a device under test
DE102013224378A1 (de) * 2013-09-18 2015-03-19 Rohde & Schwarz Gmbh & Co. Kg Automatisierte Auswertung von Testprotokollen im Telekommunikationsbereich
US11356353B1 (en) * 2019-05-20 2022-06-07 Kyle Matthew Henson System and process to perform synthetic testing of digital imaging and communications in medicine devices and integrations in a network

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0335917B1 (de) * 1987-06-10 1994-10-19 Robert Bosch Gmbh Verfahren zur lokalisierung defekter stationen in lokalen netzwerken und dazugehöriger schnittstellencontroller
US5732213A (en) 1996-03-22 1998-03-24 Ericsson Inc. System and method of testing open systems interconnection (OSI) layers in telecommunication networks
US5937165A (en) 1996-09-10 1999-08-10 Ganymede Software, Inc Systems, methods and computer program products for applications traffic based communications network performance testing
US6996067B1 (en) * 1999-12-07 2006-02-07 Verizon Services Corp. Apparatus for and method of providing and measuring data throughput to and from a packet data network
DE102007006614A1 (de) * 2007-02-06 2008-08-07 Daimler Ag Anwendung einer verteilten Diagnosearchitektur in AUTOSAR

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100564756B1 (ko) * 2003-12-03 2006-03-27 한국전자통신연구원 Megaco 프로토콜 시험 장치 및 방법
US7362713B2 (en) * 2004-01-20 2008-04-22 Sbc Knowledge Ventures, Lp. System and method for accessing digital subscriber line data
US7653180B2 (en) * 2004-10-01 2010-01-26 Tollgrade Communications, Inc. Method for assessing DSL capability of telephone lines
US7246276B2 (en) * 2004-10-04 2007-07-17 Agilent Technologies, Inc. Error tolerant modular testing of services
US7489641B2 (en) * 2005-04-25 2009-02-10 Acterna Data connection quality analysis apparatus and methods
EP1955234A2 (de) * 2005-11-23 2008-08-13 Koninklijke Philips Electronics N.V. Verfahren und vorrichtung zur fernüberwachung von patienten
TW200722990A (en) * 2005-12-14 2007-06-16 Inventec Corp Power-on self test debugging system and method
US20090010643A1 (en) * 2007-07-06 2009-01-08 Delew David A Method and apparatus for identifying faults in a passive optical network
US9215086B2 (en) * 2007-10-30 2015-12-15 Centurylink Intellectual Property Llc System and method for an integrated DSL/cable modem performance test

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0335917B1 (de) * 1987-06-10 1994-10-19 Robert Bosch Gmbh Verfahren zur lokalisierung defekter stationen in lokalen netzwerken und dazugehöriger schnittstellencontroller
US5732213A (en) 1996-03-22 1998-03-24 Ericsson Inc. System and method of testing open systems interconnection (OSI) layers in telecommunication networks
US5937165A (en) 1996-09-10 1999-08-10 Ganymede Software, Inc Systems, methods and computer program products for applications traffic based communications network performance testing
US6996067B1 (en) * 1999-12-07 2006-02-07 Verizon Services Corp. Apparatus for and method of providing and measuring data throughput to and from a packet data network
DE102007006614A1 (de) * 2007-02-06 2008-08-07 Daimler Ag Anwendung einer verteilten Diagnosearchitektur in AUTOSAR

Also Published As

Publication number Publication date
US20090161559A1 (en) 2009-06-25
DE102007054648B4 (de) 2010-07-29
US8385213B2 (en) 2013-02-26

Similar Documents

Publication Publication Date Title
DE102012102770B4 (de) System und Verfahren zur Fehlereingrenzung und Fehlerabschwächung basierend auf einer Netzwerkmodellierung
DE60017457T2 (de) Verfahren zur isolierung eines fehlers in fehlernachrichten
DE102005027378B3 (de) Dynamische Priorisierung von Prüfschritten in der Werkstattdiagnose
DE10309246B4 (de) Verfahren für das Event Management
DE102007054648A1 (de) Fehler-Identifikation in einem rechner-basierten Netzwerk
DE102022201746A1 (de) Verwaltung von rechenzentren mit maschinellem lernen
DE102013224378A1 (de) Automatisierte Auswertung von Testprotokollen im Telekommunikationsbereich
DE102015113739A1 (de) Verfahren zum Verbinden einer Eingabe/Ausgabe-Schnittstelle eines für das Testen eines Steuergeräts eingerichteten Testgeräts
DE102016203598A1 (de) Gemeinschaftliche sammlung von diagnosedaten von softwareprogrammen
DE202016101711U1 (de) Kapazitätsplanungswerkzeug, insbesondere einer Informationstechnologie-Infrastruktur
DE102012216321A1 (de) Verfahren und System zur Nachkonstruktion von Protokollen
DE112012004301T5 (de) Erzeugen einer vorhersagenden Datenstruktur
DE102021130630A1 (de) Testen von software-anwendungskomponenten
DE112021003657T5 (de) Fehlerlokalisierung für cloud-native anwendungen
EP3340250B1 (de) Bauteilidentifikation bei der fehlerbehandlung von medizinischen geräten
DE112015004557T5 (de) Anforderungsüberwachen
DE19640346C2 (de) Verfahren zum Überprüfen eines gemäß einem Kommunikationsprotokoll durchgeführten Datenaustausches
WO2020016340A1 (de) Penetrationstestverfahren, computerprogramm und vorrichtung zur datenverarbeitung
WO2005109196A1 (de) Verfahren zur bestimmung von verklemmungen in nebenläufigen prozessen
AT523948B1 (de) Verfahren zur Detektion von anomalen Betriebszuständen eines Computersystems
EP3134842A1 (de) Rechenvorrichtung und verfahren zum erkennen von angriffen auf ein technisches system anhand von ereignissen einer ereignisfolge
EP3119035B1 (de) Verfahren zum überprüfen von netzwerkeinrichtungen und netzwerk
EP3705993B1 (de) System und verfahren zum auffinden und identifizieren von rechenknoten in einem netzwerk
DE102011056524A1 (de) Verfahren zur Bewertung einer Nutzung einer von einer Automatisierungskomponente bereitgestellten Leistung und/oder Funktion
EP2189908A1 (de) Verfahren und Vorrichtung zum Bestimmen einer Kenngröße eines IT-Systems

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8364 No opposition during term of opposition
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee