DE102013224378A1

DE102013224378A1 - Automatisierte Auswertung von Testprotokollen im Telekommunikationsbereich

Info

Publication number: DE102013224378A1
Application number: DE102013224378.2A
Authority: DE
Inventors: Andrei Bechet; Francesco Rossetto; William Powell
Original assignee: Rohde and Schwarz GmbH and Co KG
Current assignee: Rohde and Schwarz GmbH and Co KG
Priority date: 2013-09-18
Filing date: 2013-11-28
Publication date: 2015-03-19
Also published as: US9785889B2; US20150081614A1; CN104461751A; CN104461751B

Abstract

Die Erfindung betrifft die automatisierte Auswertung von Testprotokollen für den Test von Telekommunikationsgeräten. Gemäß einem Verfahrensaspekt der Erfindung wird ein probabilistisches Modell (166) bereitgestellt, welches Ereignisse (506, A0–A3) in einem Testprotokoll mit möglichen Ursachen (504, H0–H3) verknüpft. Wahrscheinlichkeitswerte für die Ursachen (504) werden basierend auf dem Modell (166) und einem Durchsuchungsergebnis berechnet. Ein Hinweis auf eine mögliche Ursache wird basierend auf den berechneten Wahrscheinlichkeitswerten ausgegeben.

Description

Die vorliegende Erfindung betrifft ein Verfahren zur automatisierten Auswertung von Testprotokollen für den Test von Telekommunikationsgeräten, sowie ein entsprechendes Computerprogrammprodukt und Computersystem.
In technischen Kommunikationssystemen werden zwischen beteiligten Geräten Signalisierungsinformationen zur Durchführung von Datenkommunikationen und/oder Sprachkommunikationen zwischen Menschen und/oder Maschinen ausgetauscht. So werden etwa im Mobilfunkbereich Signalisierungsnachrichten über die Luftschnittstelle zwischen Endgeräten (UE, "User Equipment", bspw. Smartphones) und Netzknoten (bspw. Basistationen) ausgetauscht.
Vor der Bereitstellung neuer Geräte, neuer Software-Releases, neuer Features, etc. muss der fehlerfreie Nachrichtenaustausch über die relevanten Schnittstellen getestet werden. Hier sind Funktionstests, aber auch Systemtests unter Einschluss von Last- und Stresstests, Regressionstests, etc. durchzuführen. In der Regel werden diese Tests automatisiert durchgeführt; bspw. kann ein spezielles Testgerät (TE, "Test Equipment") im Batchmodus Nachrichten mit dem zu testenden Gerät (DUT, "Device under Test") austauschen. Ein automatisierter Test kann über eine kürzere Zeitspanne von z.B. einigen Minuten ablaufen, oder kann einen deutlich längeren Zeitraum beanspruchen, der im Bereich von einer Stunde, mehreren Stunden oder gar Tagen liegt.
Während des Tests wird (meist vom TE) der Nachrichtenaustauch über eine oder mehrere Schnittstellen mitprotokolliert und in einem Log oder Testprotokoll gespeichert. Nach Abschluss des Tests kann das Testprotokoll in Form einer Datei, bspw. einer Textdatei vorliegen. Meist enthält das Protokoll eine chronologische Sequenz von Ereignissen oder Events, d.h. das Protokoll umfasst eine Liste von Zeitstempeln, wobei jedem Zeitstempel eine Nachricht zugeordnet ist. Die Angabe der Nachricht kann ausgewählte Details umfassen, bspw. bestimmte Nachrichteninhalte wie das Vorhandensein und/oder der Wert von Parametern, eingebettete Nachrichten tieferer Nachrichtenprotokoll-Schichten, etc.
Es sind in der Regel die im Testprotokoll aufgeführten Ereignisse, und nur diese, die zum Auffinden von Problemen und zur Feststellung von deren Ursache zur Verfügung stehen.
Eine Auswertung des Testprotokolls kann vor Ort im Testlabor erfolgen. Meist wird die Auswertung aufgrund ihrer Komplexität aber nachgelagert und außerhalb des Testlabors durchgeführt. Die Auswertung umfasst einerseits das Auffinden von Fehlersituationen, was die Erkenntnis einschließt, das überhaupt eine Fehlersituation vorliegt, und andererseits die Suche nach den Ursachen erkannter Fehlersituationen. In einfachen Fällen kann aufgrund einer Nachricht oder Nachrichtensequenz eindeutig auf das Vorhandensein eines Fehlers sowie auch auf dessen Ursache geschlossen werden. Bspw. kann ein Softwarefehler im DUT sich in einem bestimmten Parameterwert einer Nachricht niederschlagen; geht dies aus dem Protokoll hervor, so ist die Ursache für einen Neustart eines DUT oder einer Komponente erkennbar.
Häufig kann aber eine Fehlersituation oder ein Ereignis im Prinzip auf unterschiedliche Ursachen zurückgehen. In diesen Fällen ist im konkreten Fall ein Schluss auf die tatsächliche vorliegende Fehlerursache schwierig, und kann eine umfangreichere Auswertung des Protokolls erfordern.
Als Beispiel möge ein Test eines UE (bspw. eines Smartphones) dienen, bei dem das UE sich bereits erfolgreich mit einem Mobilfunknetz synchronisiert hat, etwa auf einer RLL("Radio Link Layer")-Ebene. Aus dem Testprotokoll geht hervor, dass sich das UE plötzlich erneut mit dem Netz synchronisieren will; bspw. leitet das UE plötzlich eine neue Random-Access-Procedure ein. Hier zeigt das Auftauchen dieser Nachricht zwar grundsätzlich an, dass offenbar ein Problem vorliegt, jedoch sind eine Reihe unterschiedlicher Ursachen für dieses Verhalten denkbar; so kann ein Fehler im UE vorliegen, es kann sich aber auch um eine Reaktion des UE auf eine Testbedingung handeln, wie etwa einen simulierten Leistungsabfall im Radionetz, z.B. aufgrund eines Fehlers im Netz oder einer Bewegung des UE im Netz, z.B. zum Herbeiführen eines Handovers, etc. In diesem Fall ist es nicht einfach festzustellen, ob überhaupt eine Fehlersituation vorliegt, und wenn ja, welche konkrete Ursache dem Fehler zugrunde liegt.
Uneindeutige (Fehler-)Situationen wie im Beispiel stellen ein grundlegendes Problem bei der Auswertung von Protokollen automatisierter Tests etwa im Telekommunikationsbereich dar.
Eine Durchsicht und Auswertung des Protokolls kann durch einen menschlichen Tester erfolgen. Allerdings kann ein Testprotokoll auch schon bei Testdauern von nur wenigen Minuten aufgrund der Komplexität moderner Kommunikationssysteme und des entsprechenden Signalisierungsanfalls sehr viele Daten umfassen, so dass eine Analyse durch menschliches Testpersonal zeitaufwändig ist. Außerdem kann aufgrund der Menge an Daten nicht in wünschenswerter Weise sichergestellt werden, dass alle Fehlersituationen erkannt werden. Möglicherweise werden Fehlersituationen auch falsch beurteilt, weil nicht der grundlegende Fehler sondern nur ein Nebeneffekt oder eine spätere Auswirkung des Fehlers erkannt wird.
Es sind Testwerkzeuge bzw. -tools bekannt, die den menschlichen Tester bei der Auswertung unterstützen sollen. Bspw. können Teile des Protokolls etwa bei einer Darstellung auf einem Bildschirm in unterschiedlichen Farben eingefärbt dargestellt werden, um die Lesbarkeit zu erhöhen. So können etwa unterschiedliche Nachrichtenprotokollebenen unterschiedlich dargestellt werden. Weiterhin kann ein Testtool die Suche nach bestimmten Textstrings in einem textbasierten Testprotokoll unterstützen. Die Strings charakterisieren dann etwa einen bestimmten Nachrichtentyp, eine bestimmte Fehlersituation, etc. Derartige Stringsuchen können auch automatisiert durchgeführt werden.
Für eine automatisierte Auswertung von Testprotokollen sind weiterhin Expertensysteme bekannt.
D. Gustavsson, D. Molin, "Expert System for Error Analysis – Rule Based Reasoning Applied on Log Information and Dump Reports from Mobile Phones", Masterarbeit, Juni 2010, abrufbar unter http://fileadmin.cs.lth.se/ai/xj/Daniel Gustavsson/ADLA_Report_100615.pdf
beschreibt ein derartiges Expertensystem. Das System verfügt über ein Wissen, welches etwa in Form einer Mehrzahl von Regeln repräsentiert ist. Das System kann Schlüsse ziehen, und zwar werden vorgegebene Entscheidungsbäume abhängig von einer Auswertung der Regeln durchlaufen. Eine Regel umfasst einen Bedingungsteil und einen Ergebnisteil. Im Bedingungsteil kann ein möglicherweise auftretendes Ereignis repräsentiert sein, und im Ergebnisteil eine Schlussfolgerung. Das Expertensystem durchsucht dann das Testprotokoll nach dem Auftreten der im Bedingungsteil angegebenen Bedingung, was im Regelfall einer Stringsuche entspricht ("Pattern Matching"), und zieht daraus die entsprechenden Schlüsse.
Derartige Entscheidungsbäume sind gut geeignet um spezifische Fehler zu finden, d.h. gut definierte Ereignisse, die auf eine vorab festlegbare, eindeutige Ursache zurückgehen. Wird eine Vielzahl entsprechender Entscheidungsbäume in einer Datenbank abgespeichert, kann im Prinzip eine entsprechende Vielzahl von Problemen im Testprotokoll aufgefunden und gelöst werden.
Derartige Expertensysteme stellen daher ein effizientes Tool dar, das den menschlichen Tester dabei unterstützt, zuverlässig das Vorhandensein entsprechender Fehler festzustellen sowie deren Ursache festzustellen.
Allerdings können bekannte Expertensysteme nicht effizient mit unklar definierten Fehlersituationen umgehen. So werden Probleme nicht erkannt, wenn sie nicht exakt zu einer vorab definierten Bedingung passen. Auch das Fehlen einer Nachricht führt dazu, dass ein Expertensystem keinen sinnvollen Schluss mehr ziehen kann. Bekannte Expertensysteme können den menschlichen Tester daher nur beim Auffinden und Klären einfacher Fehlersituationen unterstützen. Der menschliche Tester muss in der Regel dennoch das gesamte Protokoll auf das Auftreten komplexerer Fehlersituationen durchsehen und diese Fehler allein mit seiner Erfahrung klären.
Zwar können bekannte Expertensysteme ständig weiter ausgebaut werden, um immer weitere denkbare Fehlersituationen abzufangen, jedoch skaliert dieser Ausbau nicht: Für jede neue Fehlersituation muss ein entsprechender, neuer Entscheidungsbaum implementiert werden. Wird eine ständig verbesserte Granularität des Systems verlangt, führt dies zu rasch zunehmender Komplexität des Expertensystems. Die Pflege des Systems bspw. zur Nachführung von Änderungen in den Nachrichtenprotokollen gestaltet sich entsprechend aufwendig, d.h. komplex und fehleranfällig.
Eine Aufgabe der vorliegenden Erfindung besteht darin, effiziente Lösungen für eine automatisierte Auswertung von Testprotokollen im Bereich des Tests von Telekommunikationsgeräten vorzuschlagen, die eine zuverlässige Unterstützung des menschlichen Testers bei der Erkennung und/oder Aufklärung komplexer Fehlersituationen ermöglichen.
Diese Aufgabe wird durch ein Verfahren mit den Merkmalen des Anspruchs 1, ein Computerprogrammprodukt mit den Merkmalen des Anspruchs 11, und ein Computersystem mit den Merkmalen des Anspruchs 12 gelöst.
Erfindungsgemäß wird ein Verfahren zur automatisierten Auswertung eines Testprotokolls zum Test eines Telekommunikationsgerätes vorgeschlagen, welches die folgenden Schritte umfasst: Bereitstellen eines vordefinierten probabilistischen Modells, welches eine Mehrzahl von Ereignissen, die in dem Testprotokoll auftreten können, mit einer Mehrzahl von möglichen Ursachen verknüpft; Durchsuchen des Testprotokolls nach dem Auftreten der Ereignisse; Berechnen von Wahrscheinlichkeitswerten für die Ursachen basierend auf dem probabilistischen Modell und einem Durchsuchungsergebnis; und Bereitstellen einer Angabe zu mindestens einer möglichen Ursache für Ereignisse, die in dem Testprotokoll aufgetreten und/oder nicht aufgetreten sind, basierend auf den berechneten Wahrscheinlichkeitswerten.
Bei dem zu testenden Telekommunikationsgerät kann es sich allgemein um ein Telekommunikations(TK)-Endgerät (UE) handeln, also etwa um ein Endgerät für Benutzer, Konsumenten, etc., also bspw. um ein Mobilfunkendgerät wie etwa ein Smartphone, ein Tablet, Surfstick, etc. Es kann sich auch um ein Endgerät für ein anderes schnur- bzw. drahtloses, oder aber schnur- bzw. drahtgestütztes Kommunikationssystem handeln, bspw. um ein Gerät welches zur Kommunikation gemäß einem LAN-Standard, WLAN-Standard, etc. ausgerüstet ist. Auch eine Implementierung einer Schnittstelle bspw. in Form einer Schnittstellenkarte, eines Socket, usw., bspw. zur Realisierung einer Kommunikationsschnittstelle wie etwa einer IP-Schnittstelle in einem Gerät wie einem PC oder einem Notebook, kann als TK-Gerät angesehen werden.
Als TK-Geräte werden andererseits im Rahmen der vorliegenden Offenbarung auch Netzknoten oder Komponenten hiervon verstanden, die ein Teil eines (Tele-)Kommunikationsnetzes sind, wobei das Netz auch nur aus dem Knoten bestehen kann, welches etwa zu Testzwecken als DUT mit einem TE Nachrichten austauscht, wobei das TE bspw. ein Endgerät emuliert. Bei dem Netzknoten kann es sich also bspw. um eine Basisstation wie etwa eine BSS ("Base Station Subsystem") oder ein eNB ("evolved Node B") eines Mobilfunknetzes handeln, oder um einen anderen Knoten im Radio- oder Kernnetz eines derartigen Netzes oder allgemein eines Kommunikationsnetzes. So kann das DUT etwa ein Access-Knoten eines beliebigen drahtlosen oder drahtgestützten Kommunikations- oder TK-Netzes sein.
Als TE werden in der Regel spezielle Geräte eingesetzt, die zur Emulation von einem oder mehreren Netzknoten und/oder Endgeräten ausgebildet sind. In der Regel verfügt ein TE weiterhin über eine Komponente zum Protokollieren des Datenaustauschs über eine Schnittstelle zum DUT, also etwa einen Sniffer oder ein sonstiges Tool zur Netzwerkanalyse.
Das Testprotokoll kann ein Testbericht, Log-File und/oder Dump-File sein, wie es während eines automatisierten Tests etwa vom TE erstellt wird. Das Testprotokoll kann in Form einer Datei oder mehrerer Dateien vorliegen, etwa als Textdatei, die bspw. Daten im ASCII- oder HTML-Format oder einem anderen durchsuchbaren Format enthält.
Ein Ereignis ("event") umfasst mindestens einen Vorgang, der sich im Testprotokoll auffinden lässt. So kann ein Ereignis das Senden einer bestimmten Nachricht oder Nachrichtensequenz sein, die über eine bestimmte Schnittstelle versendet wird (z.B. eine Synchronisierungsnachricht). Als ein Ereignis kann jedoch auch das Nicht-Auffinden einer Beobachtung bzw. eines Vorgangs im Testprotokoll definiert werden, bspw. das Fehlen einer Nachricht.
Eine Ursache ("cause") umfasst ebenfalls mindestens einen Vorgang (z.B. ein Handover). Es ist denkbar, dass auch dieser Vorgang unmittelbar aus dem Testprotokoll abgeleitet werden kann. Allerdings ist allein durch das Auffinden unter Umständen noch nicht belegt, dass dieser Vorgang ursächlich für einen Vorgang ist, der als Ereignis definiert ist bzw. aufgefunden wurde.
Ein Durchsuchen des Testprotokolls kann bspw. auf Basis einer Stringsuche ("pattern matching") oder allgemeiner in Form einer Suche nach einem bekannten Muster (Mustererkennung bzw. "pattern recognition") erfolgen. Verfahren zur Mustererkennung sind dem Fachmann als solche bekannt. Die Suche kann sich über das gesamte Testprotokoll oder nur einen Teil des Protokolls erstrecken. Die Suche kann konditionale Anteile enthalten, wobei nur bei Auffinden (oder Nicht-Auffinden) eines Musters gezielt nach einem oder mehreren weiteren Mustern gesucht wird.
Das probabilistische Modell kann Aussagen darüber repräsentieren, mit welcher Wahrscheinlichkeit ein bestimmtes Ereignis auf eine bestimmte Ursache zurückgeht. Das probabilistische Modell kann als eine Formalisierung bzw. technische Realisierung von Verknüpfungen (Beziehungen) zwischen den Ereignissen und den Ursachen angesehen werden, wobei den Verknüpfungen Wahrscheinlichkeitswerte zuordnebar sind.
Das probabilistische Modell kann ein Netzwerk repräsentieren, bei dem die Ereignisse und die Ursachen Knoten des Netzwerkes darstellen, die miteinander verknüpft sind. Ein solches Netzwerk kann als Klassifikator ("classifier") im Sinne aus der allgemeinen Informatik bekannter Klassifikationsverfahren angesehen werden und wird daher nachfolgend auch als Klassifikator bezeichnet.
Bei einigen Ausführungsformen weist das Netzwerk Verknüpfungen nur zwischen jeweils einem Ereignis und jeweils einer Ursache auf, jedoch keine Verknüpfungen nur zwischen Ereignissen, oder nur zwischen Ursachen. Bei bestimmten Ausführungsformen verknüpft jede Verknüpfung genau ein Ereignis mit genau einer möglichen Ursache. Bei einigen dieser Ausführungsformen ist jedes Ereignis mit allen möglichen Ursachen verknüpft, die im probabilistischen Modell repräsentiert sind.
Mindestens einer Verknüpfung im probabilistischen Modell kann ein vordefinierter Wahrscheinlichkeitswert zugewiesen sein, der zur Berechnung der Wahrscheinlichkeitswerte für die möglichen Ursachen herangezogen wird. Bei bestimmten Ausführungsformen ist jeder Verknüpfung des Modells bzw. Netzwerks genau ein Wahrscheinlichkeitswert zugewiesen. Die Wahrscheinlichkeitswerte können bspw. als Zahlenwerte zwischen 0 und 1, oder zwischen 0% und 100% repräsentiert werden.
Das probabilistische Modell kann ein bayessches Netz umfassen, also einen Bayes-Klassifikator repräsentieren. Zusätzlich oder alternativ kann das Modell ein Markov-Netz, ein neuronales Netz, und/oder einen Entscheidungsbaum umfassen.
Das Alphabet, das den Ereignisknoten im Netzwerk zur Verfügung steht, kann binär sein, also z.B. nur die Werte "Wahr" ("True", "1", etc.) und "Falsch" ("False", "0", etc.) umfassen. Es wird also beim Durchsuchen nur überprüft, ob ein Ereignis auftritt, oder nicht auftritt, also etwa ob eine bestimmte Nachricht oder Nachrichtensequenz mit mehreren Nachrichten, etc. im Testprotokoll auftritt, oder nicht auftritt. Die den Verknüpfungen zugeordneten Wahrscheinlichkeitswerte können dann angeben, mit welcher Wahrscheinlichkeit das Auftreten der Nachricht auf eine jeweilige Ursache zurückzuführen ist, oder mit welcher Wahrscheinlichkeit das Nicht-Auftreten einer Nachricht auf die Ursache zurückzuführen ist.
Bei einigen Ausführungsformen können bspw. dem Auftreten bzw. Nicht-Auftreten einer Nachricht (oder auch eines Parameters oder Parameterwertes) jeweils separate Wahrscheinlichkeiten zugewiesen sein; d.h. sowohl das Auftreten einer Nachricht oder allgemeiner eines Musters ("pattern") als auch das Nicht-Auftreten des Musters können als separate Ereignisse in einem Klassifikator vorgesehen werden.
Bei anderen Ausführungsformen kann ein Alphabet mehr als zwei Werte umfassen, und kann z.B. zehn Werte oder mehr umfassen. So kann zusätzlich zum Auftreten oder Nicht-Auftreten einer Nachricht ein Ereignis das Auftreten oder Nicht-Auftreten eines Parameters in einer Nachricht, und/oder das Auftreten oder Nicht-Auftreten eines Parameterwertes eines Parameters in einer Nachricht betreffen. Ein solches Netz kann in ein Netz mit binärem Alphabet überführt werden, wobei sich dann mehrere Ereignisse auf ein- und dieselbe Nachricht beziehen können, jedoch bspw. auf unterschiedliche Nachrichteninhalte oder bestimmte Parameterwerte, etc.
Das probabilistische Modell kann die Möglichkeit einer unbekannten Ursache umfassen. Ist ein Ereignis mit gegebenen Wahrscheinlichkeiten auf bestimmte Ursachen zurückzuführen, kann eine Verknüpfung mit der unbekannten Ursache mit einer verbleibenden Restwahrscheinlichkeit vorgesehen werden. Eine Angabe, dass eine Ursache für ein bestimmtes Ereignis oder mehrere Ereignisse nicht gefunden werden konnte, weist den menschlichen Tester zumindest darauf hin, dass bekannte Ursachen mit geringer Wahrscheinlichkeit vorliegen, d.h. zum Beispiel praktisch ausgeschlossen werden können.
Das probabilistische Modell kann ein zweischichtiges Netz mit einer Ereignisschicht und einer Ursachenschicht umfassen. Das probabilistische Modell kann auch mehrere zweischichtige Netzwerke bzw. ein drei- oder mehrschichtiges Netzwerk umfassen. Das probabilistische Modell kann also etwa eine Ereignisschicht, eine Zwischenschicht und eine Ursachenschicht umfassen. Die Knoten der Zwischenschicht können für die Ereignisschicht Ursachen und/oder für die Ursachenschicht Ereignisse repräsentieren. Wird das dreischichtige Modell als Kombination eines ersten und eines zweiten zweischichtigen Modells behandelt, dann kann zunächst das erste zweischichtige Modell berechnet werden, wobei im Testprotokoll aufgefundene Ereignisse auf Ursachen des ersten Modells zurückgeführt werden. Sodann werden die Ursachen (bzw. die Ursachen repräsentierenden Knoten des ersten Modells) als Ereignisse (bzw. die Ereignisse repräsentierenden Knoten) des zweiten Modells angesehen, also etwa als abgeleitete Ereignisse. Anhand des zweiten Modells können dann Wahrscheinlichkeiten übergeordneter Ursachen berechnet werden.
Drei- oder mehrschichte Modelle können bspw. verwendet werden, um Chronologien von Ereignissen zu analysieren. Dabei kann mindestens ein Knoten der Zwischenschicht eine zeitliche Abfolge von Ereignissen repräsentieren.
Erfindungsgemäß wird weiterhin ein Computerprogrammprodukt zur Ausführung eines Verfahrens vorgeschlagen, wie es vorstehend skizziert oder anderweitig in dieser Offenbarung beschrieben ist, wenn das Computerprogrammprodukt auf einem programmierbaren Computersystem oder einem digitalen Signalprozessor ausgeführt wird.
Das Computerprogramm kann auf einem maschinenlesbaren Datenträger gespeichert sein, bspw. einem permanenten oder wiederbeschreibbaren Medium in oder in Zuordnung zu einer programmierbaren Computereinrichtung oder einer CD-ROM, DVD oder einem USB-Stick. Zusätzlich oder alternativ kann das Computerprogramm zum Herunterladen auf eine programmierbare Computereinrichtung bereitgestellt werden, zum Beispiel über ein Datennetzwerk wie das Internet oder eine sonstige Kommunikationsverbindung.
Erfindungsgemäß wird nochmals weiterhin ein Computersystem vorgeschlagen, auf dem ein Computerprogrammprodukt wie vorstehend skizziert implementiert ist. Bei dem Computersystem kann es sich um ein Gerät wie einen herkömmlichen PC, ein Notebook, Tablet oder dgl. handeln, welches zur Testauswertung genutzt wird. Das Computerprogrammprodukt kann aber auch auf einem DSP installiert sein, bspw. einem Prozessor eines TE.
Auf dem Computersystem kann ein Expertensystem zur Auswertung von Testprotokollen von Telekommunikationsgeräten implementiert sein. Das Computerprogrammprodukt kann ein Auswertungstool im Rahmen des Expertensystems bereitstellen.
Das Auswertungstool kann zur Entgegennahme von Benutzereingaben ausgebildet sein. Zum Beispiel können die Eingaben die Berücksichtigung mindestens eines Ereignisses und/oder die Berücksichtigung mindestens einer Ursache betreffen, die bspw. manuell spezifiziert oder aus einem Menü ausgewählt werden können. Zusätzlich oder alternativ kann die Benutzereingabe auch die Angabe mindestens eines Wahrscheinlichkeitswertes für eine Verknüpfung betreffen. Somit können die Wahrscheinlichkeitswerte einiger oder aller vorhandener Verknüpfungen eines probabilistischen Modells von Hand eingegeben oder verändert werden. Es können bspw. vorgegebene Werte angepasst werden. Aspekte des Klassifikators wie die Wahrscheinlichkeitswerte können auch durch ein Software-Update aktualisiert werden. Zusätzlich oder alternativ kann das Tool auch als lernendes System ausgebildet sein, bspw. in dem es Rückmeldungen des Benutzers entgegennimmt und Aspekte des Klassifikators entsprechend anpasst.
Ein Auswertungstool kann eine Mehrzahl probabilistischer Modelle für unterschiedliche Fragestellungen zur Testauswertung bereitstellen. So kann bspw. für jeden Klassifikator ein eigenständiges Fenster ("View") bereitgestellt werden.
Erfindungsgemäß können Ereignisse, die in einem Testprotokoll detektierbar sind, als Beobachtungen eines probabilistischen Modells angesehen werden. Dieser Ansatz erlaubt die Zuordnung von Wahrscheinlichkeitswerten zu den Verknüpfungen zwischen den Beobachtungen und ihren möglichen Ursachen. Auf diese Weise kann ein Klassifikator definiert werden, der Sätze von Beobachtungen oder Ereignissen mit bestimmten Wahrscheinlichkeiten Sätzen von Ursachen oder Hypothesen zuordnet.
Die Erfindung ermöglicht eine automatisierte Auswertung von Testprotokollen im Bereich von Kommunikationssystemen, bei der für Beobachtungen oder Messungen, d.h. im Testprotokoll aufgefundene Ereignisse, verschiedene mögliche Ursachen in Betracht gezogen, d.h. als Hypothesen behandelt werden können. Hierzu können in einem probabilistischen (graphischen) Modell wie etwa einem Bayes-Netz Verknüpfungen zwischen detektierten bzw. beobachteten Ereignissen und möglichen Ursachen oder Interpretationen definiert werden. Den Verknüpfungen können Wahrscheinlichkeiten zugeordnet werden, deren Werte sich etwa aus theoretischen Analysen ebenso wie aus der Erfahrung ergeben können. Das System kann auch selbstlernend angelegt sein, so dass die den Verknüpfungen zugeordneten Wahrscheinlichkeitswerte z.B. anhand von Rückmeldungen des Testpersonals angepasst werden können.
Die Erfindung ermöglicht damit die automatisierte Erkennung und/oder Aufklärung komplexer Fehlersituationen bzw. die Unterstützung des Testpersonals bei diesen Aufgaben. Die automatisierte Protokollanalyse kann vermehrt Probleme abdecken, die nicht eineindeutig mit bestimmten Ereignissen verknüpft sind. Vielmehr können erfindungsgemäße Analysetools auch zwischen Ursachen unterscheiden, die eine Beobachtung oder mehrere beobachtbare Ereignisse gemeinsam haben.
Ein erfindungsgemäßes Tool ermöglicht somit eine erhöhte Zuverlässigkeit bei der Testauswertung nicht nur für einfache sondern auch komplexere Fehlersituationen und kann in dieser Weise das menschliche Testpersonal besser unterstützen, indem weniger Probleme übersehen oder nicht korrekt erkannt werden. Das Tool kann auch dazu dienen, bestimmte Ursachen (mit einer entsprechenden Wahrscheinlichkeit) auszuschließen; auch dies trägt zur Aufklärung komplexer Fehlersituationen bei und führt zu einer effizienteren Testauswertung.
Zwischen konkurrierenden Hypothesen kann prinzipiell auch mittels Durchlaufen herkömmlicher Entscheidungsbäume entschieden werden. Jedoch ist der Aufwand zur Erstellung und Anpassung derartiger Bäume hoch und das Durchlaufen der Entscheidungsbäume ist rechenintensiv. Die Erstellung und Pflege erfindungsgemäß verwendeter probabilistischer Modelle ist demgegenüber mit verringertem Aufwand verbunden, und die Entscheidungsfindung erfordert weniger Prozessorressourcen.
Ein Klassifikator eines erfindungsgemäßen Analysewerkzeugs kann durch Hinzufügung etwa einer weiteren Ursache einfach erweitert werden. Erfindungsgemäße Verfahren skalieren im allgemeinen besser als etwa Verfahren, die auf Entscheidungsbäumen basieren, was zu entsprechenden Vorteilen bei den Aufwänden für Administration, Pflege, Aktualisierung, etc. führt.
Weitere Aspekte und Vorteile der Erfindung werden nachfolgend anhand der beigefügten Zeichnungen beschrieben. Hierbei zeigen:
1 in schematischer Form ein Ausführungsbeispiel eines erfindungsgemäßen Systems zur Testauswertung;
2 eine Detailansicht des Systems aus 1;
3 ein Flussdiagramm zu einem ersten Ausführungsbeispiel einer Arbeitsweise des Systems aus den 1 und 2;
4 ein Flussdiagramm zu einem zweiten Ausführungsbeispiel einer Arbeitsweise des Systems aus den 1 und 2;
5 eine schematische Darstellung eines Ausführungsbeispiels eines erfindungsgemäßen Klassifikators, wie er in dem Testsystem der 1 und 2 zum Einsatz kommen kann;
6 ein Beispiel für eine mögliche Kommandozeilenausgabe während des Ablaufs der 4; und
7 eine Beispiel für eine Eintragung in einen Testbericht am Ende des Ablaufs aus 4.
1 veranschaulicht in schematischer Form ein Ausführungsbeispiel eines Testsystems 100 sowie eines Testauswertungssystems (RS, "Reporting System") 160. Das Testsystem 100 ist Teil einer Testumgebung TB ("Testbed") bzw. eines Testlabors, wie es dem Fachmann ansonsten bekannt ist. Das Testsystem 100 umfasst ein zu testendes Telekommunikationsgerät (DUT, "Device under Test"), im Beispiel etwa ein Endgerät 102 für ein Mobilfunknetz. Das Testsystem 100 umfasst weiter ein Testgerät (TE, "Test Equipment") 104.
Ein Test des Endgeräts 102 umfasst das Senden 106 von Nachrichten vom TE 104 an das DUT 102 ebenso wie das Senden 108 von Nachrichten vom DUT 102 an das TE 104. Der Nachrichtenaustausch 106, 108 verläuft dabei über mindestens eine Schnittstelle 110, also bspw. über eine Luftschnittstelle. Hierzu kann das TE 102 über die Schnittstelle 110 etwa das Verhalten einer Basisstation eines Mobilfunknetzes emulieren.
Das TE 104 protokolliert den Testablauf, d.h. insbesondere die über die Schnittstelle 110 gesendeten 106 bzw. empfangenen 108 Nachrichten, in einem Testprotokoll ("Log") 112, welches z.B. nach Abschluss des Tests in Form einer oder mehrerer computerlesbarer Dateien vorliegen kann. Je nach Art und Zweck des Tests kann eine Vielzahl von Nachrichten über die Schnittstelle 110 ausgetauscht werden. Zu jeder Nachricht werden in der Regel weitere Details protokolliert, etwa eingebettete Nachrichten tieferer Protokollschichten, vorhandene Parameter, ggf. mit Parameterwerten, etc., so dass sich ein entsprechend umfangreiches Testprotokoll 112 ergibt, wie dies dem Fachmann bekannt ist.
Das Auswertungssystem (RS, "Reporting System") 160 ist vom Testsystem 100 bzw. der Testumgebung TB abgesetzt, wie durch die Linie 150 angedeutet. Das RS 160 umfasst als funktionale Komponente ein Expertensystem (ES) 162, welches auf einem nicht weiter in Einzelheiten gezeigten Computersystem implementiert sein kann, bspw. einem gewöhnlichen Büro-PC oder einem Computernetzwerk mit verteilten Ressourcen wie etwa einem gewöhnlichen Büronetzwerk. Alternativ kann das Expertensystem auf dem TE 104, oder auf einem Notebook oder dgl. tragbaren Gerät implementiert sein, bspw. um in einem Servicefall eine Testauswertung vor Ort zu ermöglichen.
Menschliches Testpersonal, d.h. ein menschlicher Tester oder ein menschliches Testteam, stößt über eine Konsole (Ein-/Ausgabesystem) 164 die Testauswertung an und erhält die Ergebnisse über die Konsole 164, die bspw. eine Tastatur und/oder sonstige Eingabemittel sowie ein Display und/oder sonstige Ausgabemittel einschließlich elektronischer Speichermöglichkeiten zur Speicherung von Ergebnisberichten umfassen kann.
Das Expertensystem 162 hat Zugriff auf eine Datenbasis (Datenbank), die insbesondere mindestens einen Klassifikator (Cl, "Classifier") 166 bereitstellt. Zur Durchführung der Testauswertung erhält das Expertensystem 162 Zugriff 168 auf das Testprotokoll 112. Eine Testauswertung kann bspw. vom Testpersonal mittels eines entsprechenden, über die Konsole 164 abgesetzten Befehls ausgelöst werden. Daraufhin führt eine funktionale Komponente 170 für jeden Klassifikator eine Durchsuchung des Testprotokolls 112 durch (PR, "Pattern Recognition"), d.h. die Komponente 170 durchsucht das Protokoll 170 nach dem Auftreten bestimmter Muster, bspw. Zeichensequenzen, etwa Nachrichten-Identifikatoren. Diese Muster werden durch den Klassifikator 166 vorgegeben.
Eine funktionale Komponente 172 führt eine Auswertungsverarbeitung (EV, "Evaluation") basierend auf dem Auffinden und/oder Nicht-Auffinden der Ereignisse durch. Auch die Verarbeitung wird durch den Klassifikator 166 vorgegeben. Eine funktionale Komponente 174 ermittelt basierend auf der Verarbeitung Testergebnisse (TR, "Test Results"), die dem Testpersonal in Form eines Ergebnisberichts bereitgestellt werden können, bspw. zur Speicherung in Form einer Ergebnisdatei und/oder zur Ausgabe an die Konsole 164.
2 zeigt das Expertensystem 162 mit den Komponenten 170, 172 und 174 und weiteren Details, auf die nachfolgend bei der Schilderung beispielhafter Testauswertungen Bezug genommen wird.
3 zeigt ein Flussdiagram welches beispielhaft eine Arbeitsweise (Verarbeitung) 300 des Expertensystems 162 der 1 und 2 veranschaulicht. Die Arbeitsweise 300 betrifft die automatisierte Auswertung des Testprotokolls 112 zum Test des Telekommunikationsgerätes 102.
Im Schritt 302 wird ein vordefiniertes probabilistisches Modell bereitgestellt, welches eine Mehrzahl von Ereignissen, die in dem Testprotokoll 112 auftreten können, mit einer Mehrzahl von möglichen Ursachen verknüpft. Das probabilistische Modell kann bei dem hier beschriebenen Beispiel den Klassifikator 166 umfassen. In Schritt 304 wird von der Komponente 170 das Testprotokoll 112 nach dem Auftreten der durch den Klassifikator 166 vorgegebenen Ereignisse durchsucht.
In Schritt 306 werden von der Komponente 172 Wahrscheinlichkeitswerte für die vom Klassifikator 166 vorgegebenen Ursachen basierend auf dem probabilistischen Modell und einem Ergebnis der im Schritt 304 durchgeführten Untersuchung berechnet. In Schritt 308 stellt die Komponente 174 eine Angabe zu mindestens einer möglichen Ursache für Ereignisse bereit, die in dem Testprotokoll aufgetreten und/oder nicht aufgetreten sind, und zwar basierend auf den berechneten Wahrscheinlichkeitswerten. In Schritt 310 endet das Verfahren, bspw. indem eine Ablaufkontrolle an ein übergeordnetes Steuerprogramm im Rahmen des Expertensystems 162 oder Testauswertungssystems 160 zurückgegeben wird.
4 zeigt in Form eines Flussdiagramms ein weiteres Ausführungsbeispiel einer Arbeitsweise (Verarbeitung) 400 des Expertensystems 162 der 1 und 2. Von nicht explizit angesprochenen Aspekten kann angenommen werden, dass diese sich mit denen der Arbeitsweise 300 der 3 decken. Umgekehrt sind viele nachfolgend in Bezug auf die Verarbeitung 400 beschriebene Aspekte auch für den Ablauf 300 anwendbar.
Auch die Verarbeitung 400 betrifft beispielhaft die automatisierte Auswertung des Testprotokolls 112 wobei hierzu der Graph eines vorgegebenen probabilistischen Modells aufgebaut wird. Die Arbeitsweise 400 kann durch ein Computerprogramm implementiert sein, und kann bspw. durch eine Eingabe über die Konsole 164 angestoßen werden. Die Verarbeitung 400 kann in einem Batchmodus laufen, und/oder kann im Hintergrund ablaufen, während über die Konsole 164 oder andere, nicht gezeigte Komponenten des Auswertungssystems 160 andere Prozesse gesteuert werden. Die Verarbeitung kann umfassen, dass nach dem Anstoßen der Verarbeitung 400 ein Auswertungsergebnis auf der Konsole 164 präsentiert wird.
Die Arbeitsweise 400 beschreibt einen Ablauf aus Sicht eines Hauptprogramms. Die funktionalen Komponenten 170, 172, 174 können in Form von Unterprozeduren implementiert sein, die jeweils durch einen Aufruf vom Hauptprogramm aus angesteuert werden. Das Hauptprogramm kann z.B. das Expertensystem 162 implementieren, bzw. eine Instanz hiervon. Andere Konfigurationen sind aber ebenfalls denkbar.
In Schritt 402 wird ein Prozess (Programm, Subroutine, Funktion, etc.) "GetOutOfSync" aufgerufen. Aufgrund dieses Prozesses werden in Schritt 404 die Daten des Klassifikators 166 dem Expertensystem 162 verfügbar gemacht, bspw. indem der Klassifikator 166 "OutOfSync" eingelesen wird. Ab Schritt 406 erfolgt die weitere Verarbeitung entsprechend der durch den Klassifikator 166 vorgegebenen Daten. Die Schritte 402 bis 406 können als konkrete Ausprägung des Schrittes 302 angesehen werden.
5 ist eine Veranschaulichung des Klassifikators bzw. probabilistischen Modells oder Netzwerks 166. Der Klassifikator 166 implementiert beispielhaft ein Entscheidungsnetzwerk zu einer Warum-Frage 502, nämlich warum ein Mobilfunkgerät aus einer Synchronisation mit einem Mobilfunknetzwerk herausfällt ("Out of Sync") bzw. keinen Synchronisationszustand aufbauen kann.
Hierzu sind eine Mehrzahl möglicher Ursachen 504 bzw. Hypothesen H0, H1, H2 und H3 repräsentiert, außerdem eine Mehrzahl möglicher Ereignisse 506 oder Beobachtungen (Aussagen) A0, A1, A2, A3 mit ihren dem Fachmann als solches bekannten Kurzbeschreibungen der Nachrichten bzw. Nachrichtensequenzen. Die Ursache H0 repräsentiert mindestens eine unbekannte Ursache; mit dieser können Beobachtungen berücksichtigt werden, z.B. bestimmte Kombinationen des Auftretens und/oder Nicht-Auftretens von Ereignissen, die zu keiner der bekannten Ursachen H1, H2, H3 passen. Die unbekannte Ursache H0 gibt somit dem menschlichen Testauswerter einen Hinweis darauf, dass das Expertensystem keine wahrscheinliche Ursache identifizieren konnte, dass dies daher durch den Testauswerter geschehen sollte, und/oder dass ggf. das Expertensystem nach Auffinden der "unbekannten" Ursache um diese erweitert werden könnte.
Jedes Ereignis ist mit jeder Ursache durch genau eine Verknüpfung (Beziehung, Kante) 508 verknüpft. Umgekehrt verknüpft jede Verknüpfung 508 genau ein Ereignis mit genau einer Ursache. Die Verknüpfungen 508 sind in 5 als Pfeile dargestellt, d.h. der Klassifikator 166 ist ein gerichteter Graph, wobei die Pfeilrichtungen eine Kausalitätsrichtung angeben, wonach aus einer Ursache 504 ein oder mehrere Ereignisse 506 folgen. Das Ergebnis der hier diskutierten Bearbeitung besteht dann darin, aus beobachteten Ereignissen auf die wahrscheinlichste Ursache oder die wahrscheinlichsten Ursachen zurückzuschließen, auch wenn diese oder ein Teil dieser nicht oder nicht direkt beobachtbar sind.
Der Klassifikator 166 repräsentiert die Ursachen 504, Ereignisse 506 und Verknüpfungen 508 in Form eines bayesschen Netzes, bei dem jeder Verknüpfung 508 ein Wert 510 zugewiesen ist, der eine Wahrscheinlichkeit angibt. Die Wahrscheinlichkeitswerte 510 können als Wahrscheinlichkeiten dafür interpretiert werden, dass das durch die entsprechende Verknüpfung 508 bezeichnete Ereignis 506 auf die durch die Verknüpfung 508 verknüpfte Ursache zurückgeht. Diese Wahrscheinlichkeitswerte 510 können innerhalb des Klassifikators 166 als Konstanten vorgegeben sein. Die Werte 510 können bei der Entwicklung des Klassifikators 166 oder des Expertensystems 162 vorgegeben werden, durch eine Software-/Firmware-Aktualisierung aktualisiert werden, und/oder durch einen Anwender des Expertensystems 162 oder des Testauswertungssystems 160 eingegeben oder verändert werden. So kann das Expertensystem etwa in einem administrativen Modus, in dem keine Testauswertungen durchgeführt werden, über die Konsole Eingaben entgegennehmen, mit denen die Wahrscheinlichkeiten 510 durch Testpersonal eingegeben oder verändert werden können, und etwa an konkrete Erfahrungswerte angepasst werden können.
Es ist auch denkbar, dass weitere Aspekte des Klassifikators veränderbar sind. Bspw. kann vorgesehen sein, dass ein Benutzer über die Konsole 164 eine weitere Ursache zu den Ursachen H0–H3 hinzufügt und/oder eine oder mehrere der Ursachen H0–H3 aus dem Graphen 166 entfernt. Ebenso kann vorgesehen sein, dass ein Benutzer ein Ereignis zu den Ereignissen A0–A3 hinzufügt und/oder eine oder mehrere der Ereignisse A0–A3 aus dem Graphen 166 entfernt. Das Hinzufügen und/oder Entfernen von Knoten 506, 508 kann etwa über eine Menüauswahl erfolgen, mit der dem Benutzer Vorgänge bzw. Aussagen vergleichbar zu den Vorgängen H0–H3, A0–A3 angeboten werden. Bspw. kann ein Menü eine Auswahl von Nachrichten eines gegebenen Protokollstacks für eine bestimmte Schnittstelle wie etwa die Schnittstelle 110 in 1 anbieten.
Mit Schritt 408 in 4, der Schritt 304 in 3 entsprechen kann, wird ein "Mess"-Prozess aufgerufen, d.h. ein Prozess zum Durchsuchen des Testprotokolls. Konkret kann die Komponente 170 etwa eine Liste 202 (vgl. 2) von Zeichenketten (Stringsequenzen) laden, wobei für jedes der Ereignisse A0–A3 des Klassifikators 166 mindestens eine Zeichenkette definiert ist. Eine Zeichenkette kann bspw. einem Bezeichner einer Nachricht entsprechen, mit dem diese Nachricht im Testprotokoll 112 gekennzeichnet ist. Aus Gründen der Klarheit sind die Zeichensequenzen 202 in 2 lediglich durch die entsprechenden, auch in 5 dargestellten Ereignisbezeichnungen A0–A3 veranschaulicht.
Die Komponente 170 führt nun ein Verfahren zur Mustererkennung, d.h. eine Messung, bzw. einen Durchsuchungs- oder Scanvorgang durch, d.h. es wird bspw. für jede der Zeichenketten 202 überprüft, ob diese im Testprotokoll 112 auftritt. Zusätzlich können weitere Informationen gemessen werden, etwa die Position des Auftretens (bspw. der Zeitstempel, und/oder eine Position im Logfile 112), zugeordnete Nachrichteninhalte, etc. Es wird angemerkt, dass ein Ereignis 506 aus 5 auch das Nicht-Auftreten einer Nachricht, eines Parameters in einer Nachricht, etc. betreffen kann, so dass die Komponente 170 auch ein entsprechendes Nicht-Auftreten überprüft bzw. misst.
Nach Abschluss des Scanvorganges im Schritt 408 werden in Schritt 410 die Messergebnisse bzw. Beobachtungen 204 (2) von der Verarbeitungskomponente 172 entgegengenommen, bspw. eingelesen. Wird im Messprozess 408 lediglich das Auftreten oder Nicht-Auftreten von Ereignissen überprüft, kann das Alphabet, mit dem die Ereignisse 506 belegt werden, ein binäres Alphabet sein, das z.B. nur die Buchstaben "T" ("True") und "F" ("False") 205 umfasst. Die Beobachtungen 204 können dann als eine einfache sequentielle Liste übergeben werden, in der jedem Ereignis A0–A3 entweder ein "T" oder ein "F" zugewiesen ist.
Im vorliegendem Beispiel wird angenommen, dass die im Netzwerk oder Graph 166 in 5 angegebenen Wahrscheinlichkeiten 510 den "True"-Zustand des jeweiligen Ereignisses 506 betreffen, d.h. der Wahrscheinlichkeitswert 510 bezeichnet eine Wahrscheinlichkeit, mit der ein tatsächlich aufgetretenes Ereignis auf eine bestimmte Ursache 504 zurückgeht, d.h. die Wahrscheinlichkeit mit der dann eine bestimmte Ursache 504 vorliegt. Bei einem weiteren Ausführungsbeispiel kann mindestens einer Verknüpfung 508 ein weiterer Wahrscheinlichkeitswert zugewiesen sein, der angibt mit welcher Wahrscheinlichkeit die entsprechend verknüpfte Ursache vorliegt, wenn ein Ereignis nicht detektiert wurde. Bei einem nochmals weiteren Ausführungsbeispiel ist jeder Verknüpfung genau ein Wahrscheinlichkeitswert zugewiesen, jedoch ist zusätzlich spezifiziert, ob sich der Wahrscheinlichkeitswert auf das Auftreten oder Nicht-Auftreten des entsprechenden Ereignisses bezieht.
Die eingelesenen Messdaten 204 können weitere Informationen enthalten. So können für detektierte Ereignisse etwa Nachrichteninhalte übergeben werden, oder es kann eine zeitliche Reihenfolge detektierter Ereignisse übergeben werden. Das Alphabet mit dem die Ereignisse belegt sind, kann entsprechend umfangreich sein. Letztlich kann jedes Alphabet auf ein binäres Alphabet zurückgeführt werden, d.h. es kann eine Nachricht mit verschiedenen Nachrichteninhalten in Form einer Mehrzahl atomarer Ereignisse repräsentiert werden, die dann nur noch mit einem binären Alphabet belegt sind. Allerdings können Ereignislisten wie die Liste 204 umfangreich werden. Die konkrete Ausgestaltung kann anhand der obigen Diskussion für jeden Einzelfall optimiert werden.
In Schritt 412 berechnet die Verarbeitungskomponente 172 Wahrscheinlichkeiten für die im Klassifikator 166 repräsentierten Ursachen 504 (Hypothesen H0–H3). Neben den Ereignissen, welche der Komponente 172 auch über die Messergebnisse 204 zur Verfügung stehen, liest die Komponente 172 auch Indikatoren 206 (2) für die Hypothesen 504, die Verknüpfungen V 508 und die zugeordneten Wahrscheinlichkeitswerte P(V) 510 ein. Diese Indikatoren 206 müssen keine Textstrings oder Prozentzahlen sein, wie sie in 5 zur Veranschaulichung für die Ursachen 504 und Wahrscheinlichkeitswerte 510 verwendet werden; vielmehr können die Indikatoren durch interne Variablen des Expertensystems 162 repräsentiert sein, bspw. Indices, Integerzahlen, Zeiger, etc. Die Wahrscheinlichkeitswerte 510 können intern durch Realzahlen repräsentiert sein.
Das Netzwerk bzw. der Klassifikator 166 wird in diesem Beispiel als Bayes-Netzwerk bzw. als bayesscher Klassifikator behandelt. Dementsprechend kann eine Berechnung der Wahrscheinlichkeiten, mit denen die Ursachen 504 des Graphen 166 in 5 belegt sind, basierend auf den Wahrscheinlichkeiten 510 und der Ereignisliste 204, durch den Aufruf eines entsprechenden, als solches bekannten Berechnungssystems erfolgen. Bspw. kann die Komponente 172 ein solches System aus einer entsprechenden Bibliothek (Lib, "Library") 208 anziehen und/oder die Berechnungen in einer entsprechenden Unterfunktion durchführen.
Als Ergebnis der Berechnungen wird eine Liste 210 (2) zurückgegeben, in der z.B. alle Hypothesen H0–H3 bzw. möglichen Ursachen 504 mit jeweils einer zugeordneten Wahrscheinlichkeit 212 aufgeführt sein können. Die Darstellung der Liste 210 mit Indikatoren H0–H3 in 2 und Prozentangaben 212 wird allein aus Gründen der Klarheit gewählt. Bei anderen Ausführungsbeispielen können die Hypothesen in der Liste 210 weiterhin durch interne Indikatoren gekennzeichnet sein. Die Hypothesen-Indikatoren in der Liste 210 können auch ganz entfallen, wenn die Wahrscheinlichkeiten 212 allein durch ihre Reihenfolge in der Liste 210 den Hypothesen 504 zugeordnet werden können.
Die Schritte 410 und 412 können in etwa dem Schritt 306 entsprechen. In den Schritten 414 und 416, die in etwa dem Schritt 308 entsprechen können, nimmt die Berichtskomponente 174 die Ergebnisdaten 210 entgegen. Zusätzlich kann die Komponente 174 auch Daten des Klassifikators 166 abrufen 214 (vgl. 2), bspw. textuelle Beschreibungen der Ursachen 504, also etwa zumindest der für die Ausgabe in einen Testbericht oder an die Konsole 164 bestimmten Ursache/n. Die Komponente 174 kann ausgebildet sein, um einen Testbericht in eine vorhandene oder automatisiert neu zu erstellende Datei zu schreiben. Die Datei kann für einen menschlichen Benutzer etwa mittels eines geeigneten Editors oder vergleichbaren Programms an der Konsole 164 ausgegeben werden, und/oder kann für eine maschinelle Weiterverarbeitung der enthaltenen Informationen vorgesehen sein. Bei der Datei kann es sich etwa um eine Textdatei handeln.
6 zeigt ein Beispiel für eine Ausgabe 600, wie sie von der Komponente 174 zur Einfügung in einen Testbericht und/oder Darstellung auf einem Anzeigeschirm, bspw. in einer Kommandozeilenumgebung, generiert werden könnte. In Ergebniszeilen 602 werden die für die Ursachen bzw. Hypothesen H0–H3 berechneten Wahrscheinlichkeitswerte ausgegeben, wie sie aus dem Schritt 412 resultieren. In weiteren Ergebniszeilen 604 kann in Textform zumindest die Ursache genannt werden, für welche die höchste Wahrscheinlichkeit berechnet wurde. Im vorliegenden Beispiel wurde festgestellt, dass die wahrscheinlichste Ursache für einen Verlust der Synchronisation zwischen dem DUT 102 und TE 104, basierend auf dem beobachteten Auftreten bzw. Nichtauftreten der Ereignisse A0–A3 im Testprotokoll 112, ein Handover (HO) ist. Für diese Ursache (H1) wurde eine höhere Wahrscheinlichkeit berechnet als für andere Ursachen wie bspw. das Auftreten eines Fehlers im DUT 102 (H3).
7 zeigt in schematischer Form einen beispielhaften Auszug aus einem Testbericht 700, der in Form einer Liste von Bookmarks wesentliche Positionen im Testlog 112 angibt, soweit diese automatisiert erkannt wurden, und zu jeder angegebenen Position eine Sequenz mit weiteren Informationen aufführt. Einträge in der Liste 700 können sowohl auf Ergebnisse erfindungsgemäßer Testauswertung wie auch herkömmlicher Testauswertung zurückgehen.
Die Komponente 174 hat die Generierung eines Bookmarks 702 angestoßen, welches auf eine bestimmte Position im Testprotokoll 112 verweist und eine wahrscheinliche Ursache für eine dieser Position zugeordnete Fehlersituation angibt. Im Einzelnen wird durch den Bookmark 702 eine Warnung eingestellt. An der durch die ID 704 bezeichneten Position wurde ein Synchronisationsverlust (OOS, "Out of Sync") des DUT 102 festgestellt. Die ID 704 kann eine Sprungadresse sein. Bei anderen Ausführungsbeispielen kann unmittelbar eine Zeilennummer, ein Zeitstempel, oder sonstige Positionsangabe im Testlog 112 angegeben sein.
Der Bookmark 702 enthält weiterhin eine kurze textuelle Angabe der Ursache des OOS, wie sie mit dem vorstehend geschilderten erfindungsgemäßen Verfahren berechnet wurde. Bei einer Darstellung des Testberichts auf der Konsole 164 könnten durch einen Klick auf die Zeile 702 weitere Informationen angezeigt werden, bspw. mit einer Ausführlichkeit wie bei der Kommandozeilenausgabe 600 der 6.
Anstatt nur die wahrscheinlichste Ursache auszugeben, können auch mehrere Ursachen ausgegeben werden, bspw. dann wenn zwei oder mehrere höchste Wahrscheinlichkeiten in einem Korridor von z.B. 10% beieinander liegen.
Der Klassifikator 166 in 5 ist als zweischichtiges Netz repräsentiert. Ein erfindungsgemäßes probabilistisches Modell kann jedoch auch durch ein drei- oder mehrschichtiges Netzwerk repräsentiert werden, insbesondere zur automatisierten Analyse komplexerer Fragestellungen. So kann zunächst eine Reihe von Beobachtungen oder Ereignissen in einem Testprotokoll gemessen werden und dann mittels einer Auswertung wie vorstehend geschildert auf eine oder mehrere wahrscheinliche Ursachen zurückgeführt werden, die jedoch ihrerseits auf nochmals grundlegendere Ursachen zurückgeführt werden können, etc.
Allgemein können sowohl Ereignisse wie Ursachen letztlich als Vorgänge angesehen werden, d.h. ein Vorgang kann ebenso als Ereignis wie auch als Ursache in einem probabilistischen Modell repräsentiert werden. Auf Grundlage dessen kann ein dreischichtiges Netzwerk als Kombination zweier zweischichtiger Netzwerke behandelt werden wie oben skizziert. Die Ursachen einschließlich der errechneten Wahrscheinlichkeitswerte des ersten zweischichtigen Netzwerks gehen als Ereignisse in das zweite zweischichtige Netzwerk ein. Als Beispiel für eine komplexe Analyse, die sich für die Repräsentation in einem mehrschichtigen Netzwerk anbietet, sei die Analyse zeitlicher Abhängigkeiten bspw. in Bezug auf eine Abfolge von Nachrichten im Testprotokoll genannt.
Während der Klassifikator 166 in 5 zur Feststellung der wahrscheinlichsten Ursache für einen OOS ausgebildet ist, können andere Klassifikatoren entsprechend zur automatisierten Beantwortung einer Vielzahl anderer analytischer Fragestellungen ausgebildet sein, bspw. in Bezug auf ein Mobilfunk-Endgerät betreffend Fragestellungen warum eine Anmeldung im Netz nicht funktioniert, ein Handover nicht funktioniert, eine Datenübertragung nicht funktioniert, eine Datenübertragungsrate zu niedrig ist, etc. Für den Test von Netzknoten wie Basisstationen können ähnliche Fragestellungen ebenfalls in Form von Klassifikatoren wie erfindungsgemäß vorgeschlagen einer automatisierten Auswertung zugänglich gemacht werden.
Ein Expertensystem wie das System 164 in den 1, 2 kann zur Testauswertung basierend auf einer Mehrzahl unterschiedlicher probabilistischer Modelle ausgebildet sein. Hierbei würde ein Ablauf wie vorstehend anhand der 3, 4 geschildert mehrfach sequentiell oder parallel für unterschiedliche Klassifikatoren durchgeführt. Die Modelle bzw. Klassifikatoren können auf ein- und dasselbe Testprotokoll angewendet werden und dabei automatisiert unterschiedliche Fragestellungen untersuchen.
Dem Benutzer kann die Auswertung mittels erfindungsgemäßer Klassifikatoren in Form eines (oder mehrerer) Auswertungstools angeboten werden. Im Rahmen dieses Tools kann der Benutzer etwa eine oder mehrere Fragestellungen an- oder abwählen. Auch die optionale Eingabe von Ereignissen, Ursachen und Wahrscheinlichkeitswerten für die Verknüpfungen kann im Rahmen des Auswertungstools erfolgen. Es ist auch denkbar, dass für das Tool, oder für jeden angewählten Klassifikator, ein eigener View bzw. ein eigenes Fenster etwa auf einem Anzeigeschirm der Auswertungskonsole 164 geöffnet ist bzw. wird, in dem dann auch die Auswertungsergebnisse dargestellt werden, entweder in Kurzform wie in 7 oder ausführlicher wie in 6 beispielhaft gezeigt.
Die hier beschriebenen Verfahrensabläufe können allgemein in Form von Hardwareschaltungen, Software in Zusammenhang mit einem programmierbaren Mikroprozessor, einer anwendungsspezifischen, integrierten Schaltung (ASIC) und/oder unter Verwendung von einem oder mehreren digitalen Signalprozessoren (DSP) implementiert werden. Eine Softwarekodierung der hier beschriebenen Verfahren kann beispielsweise in einem Random-Access-Memory (RAM) oder einem Read-Only-Memory (ROM) abgelegt sein, beispielsweise einem „Erasable Programable ROM“ (EPROM) oder einem vergleichbaren semipermanenten oder permanenten Speichermedium.
Die Erfindung ist nicht auf die hier beschriebenen Ausführungsbeispiele und die darin hervorgehobenen Aspekte beschränkt; vielmehr sind innerhalb des durch die anhängenden Ansprüche angegebenen Bereichs eine Vielzahl von Abwandlungen möglich, die im Rahmen fachmännischen Handelns liegen. Insbesondere sind dem Fachmann bestimmte Kombinationen von vorstehend separat beschriebenen Merkmalen als zweckmäßig oder vorteilhaft ersichtlich.
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 Nicht-Patentliteratur

D. Gustavsson, D. Molin, "Expert System for Error Analysis – Rule Based Reasoning Applied on Log Information and Dump Reports from Mobile Phones", Masterarbeit, Juni 2010, abrufbar unter http://fileadmin.cs.lth.se/ai/xj/Daniel Gustavsson/ADLA_Report_100615.pdf [0012]

Claims

Verfahren zur automatisierten Auswertung eines Testprotokolls zum Test eines Telekommunikationsgerätes, mit den folgenden Schritten: Bereitstellen (302, 402, 404) eines vordefinierten probabilistischen Modells (166), welches eine Mehrzahl von Ereignissen (506), die in dem Testprotokoll (112) auftreten können, mit einer Mehrzahl von möglichen Ursachen (504) verknüpft; Durchsuchen (304, 408, 410) des Testprotokolls (112) nach dem Auftreten der Ereignisse (506); Berechnen (306, 412) von Wahrscheinlichkeitswerten (212) für die Ursachen (504) basierend auf dem probabilistischen Modell (166) und einem Durchsuchungsergebnis; und Bereitstellen (308, 414, 416) einer Angabe (600, 700) zu mindestens einer möglichen Ursache für Ereignisse, die in dem Testprotokoll aufgetreten und/oder nicht aufgetreten sind, basierend auf den berechneten Wahrscheinlichkeitswerten.
Verfahren nach Anspruch 1, wobei mindestens einer Verknüpfung (508) im probabilistischen Modell (166) ein vordefinierter Wahrscheinlichkeitswert (510) zugewiesen ist, der zur Berechnung der Wahrscheinlichkeitswerte für die möglichen Ursachen herangezogen wird.
Verfahren nach Anspruch 1 oder 2, wobei jede Verknüpfung (508) genau ein Ereignis mit genau einer möglichen Ursache verknüpft, und jeder Verknüpfung genau ein Wahrscheinlichkeitswert (510) zugewiesen ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei jedes Ereignis (506) mit allen möglichen Ursachen (504) verknüpft ist, die im probabilistischen Modell (166) repräsentiert sind.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das probabilistische Modell ein bayessches Netz (166), ein neuronales Netz, und/oder einen Entscheidungsbaum umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Ereignisse (506) das Auftreten oder Nicht-Auftreten mindestens einer Nachricht, das Auftreten oder Nicht-Auftreten eines Parameters in einer Nachricht, und/oder das Auftreten oder Nicht-Auftreten eines Parameterwertes eines Parameters in einer Nachricht betreffen.
Verfahren nach einem der vorhergehenden Ansprüche, wobei dem Auftreten bzw. Nicht-Auftreten einer Nachricht, eines Parameters oder Parameterwertes separate Wahrscheinlichkeitswerte zugewiesen sind.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das probabilistische Modell (166) die Möglichkeit einer unbekannten Ursache (H0) umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das probabilistische Modell ein mehrschichtiges Netz mit einer Ereignisschicht, einer Zwischenschicht und einer Ursachenschicht umfasst, und die Knoten der Zwischenschicht für die Ereignisschicht Ursachen und/oder für die Ursachenschicht Ereignisse repräsentieren.
Verfahren nach Anspruch 9, wobei mindestens ein Knoten der Zwischenschicht eine zeitliche Abfolge von Ereignissen repräsentiert.
Computerprogrammprodukt zur Ausführung aller Schritte des Verfahrens nach einem der vorhergehenden Ansprüche, wenn das Computerprogrammprodukt auf einem programmierbaren Computersystem (160) oder einem digitalen Signalprozessor ausgeführt wird.
Computersystem, auf dem ein Computerprogrammprodukt nach dem vorhergehenden Anspruch implementiert ist.
Computersystem nach Anspruch 12, wobei auf dem Computersystem (160) ein Expertensystem (162) zur Auswertung von Testprotokollen (112) von Telekommunikationsgeräten (102) implementiert ist und mittels des Computerprogrammprodukts ein Auswertungstool (170, 172, 174) im Rahmen des Expertensystems bereitgestellt wird.
Computersystem nach Anspruch 13, wobei das Auswertungstool Benutzereingaben betreffend die Berücksichtigung mindestens eines Ereignisses, die Berücksichtigung mindestens einer Ursache, und/oder die Angabe mindestens eines Wahrscheinlichkeitswertes für eine Verknüpfung ermöglicht.
Computersystem nach Anspruch 13 oder 14, wobei das Auswertungstool eine Mehrzahl probabilistischer Modelle für unterschiedliche Fragestellungen zur Testauswertung bereitstellt.