DE10256158A1

DE10256158A1 - Diagnose von Datenübertragungsfehlern unter Verwendung von Beschränkungen

Info

Publication number: DE10256158A1
Application number: DE10256158A
Authority: DE
Inventors: Douglas R Manley; Lee A Barford
Original assignee: Agilent Technologies Inc
Current assignee: Agilent Technologies Inc
Priority date: 2002-02-19
Filing date: 2002-12-02
Publication date: 2003-09-04
Also published as: US20030159093A1; US7024600B2; JP2003256296A

Abstract

Verfahren zum Diagnostizieren von Fehlern in einem zu testenden System (SUT) sind vorgesehen. Ein repräsentatives Verfahren umfaßt das Identifizieren von zumindest einigen Abschnitten der Datenübertragungswege des SUT, die in der Lage sind, Fehler in die Datenübertragung einzubringen; das Liefern von Beschränkungen, die Beziehungen von zumindest einigen der Abschnitte der Datenübertragungswege definieren; und das Diagnostizieren des SUT bezüglich den Beschränkungen. Systeme, computerlesbare Medien und andere Verfahren sind ebenfalls vorgesehen.

Description

Die vorliegende Erfindung bezieht sich allgemein auf eine Systemfehlerdiagnose. Insbesondere bezieht sich die vorliegende Erfindung auf Systeme und Verfahren, die die Diagnose von Fehlern bei mehreren diskreten Datenübertragungen zwischen Teilen eines Systems betreffen.
Zum Diagnostizieren von Fehlern, die zu testende Systeme (SUT; SUT = system under test) aufweisen, werden bisher verschiedene Systeme und Verfahren verwendet. Beispielsweise werden manuelle Diagnose, automatische Diagnose auf der Basis von testmodellbasierter Technologie, Kundensoftware und Fehlersimulation verwendet. Diese Techniken neigen jedoch dazu, einen oder mehrere erkennbare Nachteile aufzuweisen, die dazu neigen, die Anwendbarkeit derselben zu begrenzen.
Bezüglich manueller Diagnose ist diese Technik typischerweise eine wissensintensive Technik, die einen sehr hohen Pegel von SUT- und Testreihenkenntnis erfordert. Das Aneignen dieses Wissens durch einen Betreiber kann zeitraubend und daher aufwendig sein. Außerdem sind Ergebnisse, die während der Diagnose erhalten werden, typischerweise nicht wiederholbar, da die Ergebnisse von Betreiber zu Betreiber und/oder Position zu Position variieren können. Eine solche Technik kann auch etwas fehleranfällig sein, da eine falsche Anwendung der Technik zu einer ungenauen Fehlerdiagnose führen kann.
Obwohl die testmodellbasierte Diagnose für die Diagnose von statischen Fehlern als kompetent angesehen wird, ist dieselbe für die Verwendung bei der Diagnose von intermittierenden Fehlern tendenziell uneffektiv. Ein statischer Fehler ist ein Fehler, der während einem gesamten Test vorliegt, und typischerweise alle Datenübertragungen während dem Test beeinträchtigt, während ein intermittierender Fehler typischerweise nur einen Teil der Datenübertragungen beeinträchtigt. Testmodellbasierte Techniken neigen dazu, einen gesamten Testweg zu verurteilen, wenn ein Fehler mit Bezugnahme auf diesen Testweg diagnostiziert wird, im Vergleich zum Verurteilen eines speziellen Teils/spezieller Teile und/oder einer speziellen Komponente/spezieller Komponenten des Testwegs. Außerdem erfordert eine testmodellbasierte Diagnose typischerweise die Entwicklung eines detaillierten Modells der Tests für ein System. Beispiele von testmodellbasierten Systemen sind in dem US-Patent Nr. 5,808,919 offenbart, ausgegeben an Preist u. a., das hierin durch Bezugnahme aufgenommen ist, und das gemeinsam mit dieser Offenbarung Agilent Technologies, Inc., zugewiesen ist.
Anwendersoftware wurde ebenfalls verwendet, um Systeme zu diagnostizieren. Leider ist Anwendersoftware typischerweise geschrieben, um nur ein spezifisches System zu diagnostizieren. Dieser Lösungsansatz tendiert dazu, mühsam und daher aufwendig zu implementieren zu sein.
Wie es ebenfalls bekannt ist, können bei der Systemdiagnose Fehlersimulatoren verwendet werden. Fehlersimulatoren arbeiten typischerweise durch Erzeugen eines Fehlerverzeichnisses. Die Fehlersimulation erfordert jedoch typischerweise sehr viel Modellierungszeit und relativ lange Ausführzeiten, insbesondere wenn das SUT komplexe Schaltungen verwendet. Deswegen wird die Fehlersimulation für die Verwendung bei komplexen handelsüblichen Anwendungen typischerweise nicht als praktisch angesehen. Außerdem ist eine Fehlersimulation für die Diagnose von intermittierenden Ausfällen nicht existent oder wird andernfalls als unpraktisch angesehen.
Auf der Basis des Vorhergehenden sollte klar sein, daß es einen Bedarf nach verbesserten Systemen und Verfahren gibt, die das vorher Erwähnte und/oder andere erkannte Nachteile des Stands der Technik adressieren.
Es ist die Aufgabe der vorliegenden Erfindung, ein Verfahren und ein System zum Diagnostizieren von Fehlern in einem zu testenden System mit verbesserten Charakteristika zu schaffen.
Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1 und 15 sowie ein System gemäß Anspruch 20, 25 und 28 gelöst.
Die vorliegende Erfindung bezieht sich auf die Diagnose von Fehlern bei Datenübertragungen eines zu testenden Systems (SUT; SUT = system under test). Typischerweise verwendet die Erfindung Beschränkungen, um Beziehungen zwischen verschiedenen Abschnitten des SUT zu definieren, die eine Datenübertragung beeinträchtigen. Diese Beschränkungen können dann mit Bezugnahme auf die Testergebnisse, die von dem SUT erhalten werden, ausgewertet werden.
Bei einigen Ausführungsbeispielen wird ein Datenflußmodell verwendet, um die Abschnitte eines SUT zu identifizieren, die in der Lage sind, Datenübertragungsfehler einzubringen. Dann werden Beschränkungen entwickelt, um Datenübertragungsbeziehungen zwischen den identifizierten Abschnitten zu definieren. Wenn somit Testergebnisse, die dem SUT entsprechen, empfangen werden, und ein Datenübertragungsfehler erfaßt wird, können die Beschränkungen bezüglich der Testergebnisse unter Verwendung des Datenflußmodells ausgewertet werden, um möglicherweise Komponenten und/oder Subkomponenten des SUT, die die Datenübertragungsfehler erzeugt haben könnten, zu identifizieren und/oder zu entlasten.
Außerdem können bei einigen Ausführungsbeispielen diejenigen Abschnitte eines SUT, die in der Lage sind, Daten, z. B. Datenpakete, zu zählen, und/oder in der Lage sind, eine Operation bezüglich der Daten durchzuführen, ebenfalls identifiziert werden. Eine solche Operation könnte beispielsweise das Reproduzieren (auf einem Bus versenden; bussing), Spalten, Kombinieren, Fallenlassen und/oder Leiten (Schalten) von Daten umfassen.
Ausführungsbeispiele der Erfindung können als Verfahren zum Diagnostizieren von Fehlern in einem SUT aufgefaßt werden. Diesbezüglich umfaßt ein solches Verfahren: Identifizieren zumindest einiger Abschnitte der Datenübertragungswege des SUT, die in der Lage sind, Fehler in die Datenübertragung einzubringen; Liefern von Beschränkungen, die Beziehungen von zumindest einigen der Abschnitte der Datenübertragungswege definieren; und Diagnostizieren des SUT bezüglich der Beschränkungen.
Ein weiteres solches Verfahren umfaßt: Liefern eines Datenflußmodells, das das SUT darstellt, wobei das Datenflußmodell Informationen umfaßt, die einer Beziehung von Fehlererfassungsfähigkeiten des SUT entsprechen; und Diagnostizieren des SUT bezüglich des Datenflußmodells.
Ausführungsbeispiele der Erfindung können außerdem als Systeme zum Diagnostizieren von Fehlern in einem zu testenden System (SUT; SUT = system under test) aufgefaßt werden. Ein solches System umfaßt ein Datenflußmodell und eine Schlußfolgerungsmaschine. Das Datenflußmodell stellt die Datenübertragungsfähigkeiten des SUT dar. Die Schlußfolgerungsmaschine ist angepaßt, um Testergebnisse auszuwerten, die dem SUT in Bezug zu dem Datenflußmodell entsprechen.
Ein weiteres System zum Diagnostizieren von Fehlern umfaßt eine Einrichtung zum Empfangen von Testergebnissen, die zumindest einigen Komponenten des SUT entsprechen, und eine Einrichtung zum Diagnostizieren des SUT zur Erhaltung des Datenflusses zwischen den zumindest einigen Komponenten.
Noch weitere Ausführungsbeispiele der Erfindung können als Diagnosesysteme aufgefaßt werden, von denen zumindest einige auf computerlesbaren Medien gespeichert werden können. Ein solches Diagnosesystem umfaßt eine Logik, die konfiguriert ist, um zumindest einige Abschnitte der Datenübertragungswege des SUT zu identifizieren, die in der Lage sind, Fehler in die Datenübertragung einzubringen; eine Logik, die konfiguriert ist, um Beschränkungen zu liefern, die Beziehungen von zumindest einigen der Abschnitte der Datenübertragungswege definieren; und eine Logik, die konfiguriert ist, um das SUT bezüglich der Beschränkungen zu diagnostizieren.
Andere Systeme, Verfahren, Merkmale und/oder Vorteile der vorliegenden Erfindung werden für einen Fachmann auf diesem Gebiet bei der Untersuchung der folgenden Zeichnungen und der detaillierten Beschreibung offensichtlich werden. Es ist beabsichtigt, daß alle diese zusätzlichen Systeme, Verfahren, Merkmale und/oder Vorteile in dieser Beschreibung enthalten sind, innerhalb des Schutzbereichs der vorliegenden Erfindung liegen und durch die beiliegenden Ansprüche geschützt sind.
Die vorliegende Erfindung, wie sie in den Ansprüchen definiert ist, ist mit Bezugnahme auf die folgenden Zeichnungen besser verständlich. Die Zeichnungen sind nicht notwendigerweise maßstabsgerecht, statt dessen wurde der Schwerpunkt darauf gelegt, die Prinzipien der vorliegenden Erfindung deutlich darzustellen.
Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:
Fig. 1 eine schematische Darstellung, die ein Ausführungsbeispiel eines Systems der vorliegenden Erfindung zeigt, das ein Ausführungsbeispiel eines Diagnosesystems umfaßt, das verwendet wird, um ein zu testendes System zu testen;
Fig. 2 ein Flußdiagramm, das eine Funktionalität eines Ausführungsbeispiels des Diagnosesystems der vorliegenden Erfindung zeigt;
Fig. 3 ein computer- oder prozessorbasiertes System, das verwendet werden kann, um ein Ausführungsbeispiel des Diagnosesystems der vorliegenden Erfindung zu implementieren,
Fig. 4 ein Flußdiagramm, das eine Funktionalität des Ausführungsbeispiels des Diagnosesystems von Fig. 3 zeigt;
Fig. 5 einen gerichteten Graph, der ein Ausführungsbeispiel eines Datenflußmodells darstellt, das durch ein Diagnosesystem der vorliegenden Erfindung verwendet werden kann;
Fig. 6 ein Blockdiagramm, das ein repräsentatives zu testendes System (SUT) zeigt;
Fig. 7 einen gerichteten Graph, der ein Ausführungsbeispiel eines Datenflußmodells darstellt, das durch ein Diagnosesystem der vorliegenden Erfindung verwendet werden kann, um das SUT von Fig. 6 zu diagnostizieren; und
Fig. 8 einen weiteren gerichteten Graph, der ein Ausführungsbeispiel eines Datenflußmodells darstellt, das durch ein Diagnosesystem der vorliegenden Erfindung verwendet werden kann, um das SUT von Fig. 6 zu diagnostizieren.
Wie es hierin nachfolgend näher beschrieben wird, ermöglichen Systeme und Verfahren der vorliegenden Erfindung potentiell Fehlerdiagnosen von zu testenden Systemen (SUT), die der Datenübertragung zugeordnet sind. Genauer gesagt, Beschränkungen, die Beziehungen zwischen verschiedenen Abschnitten der Datenübertragungswege eines SUT darstellen, können verwendet werden, um Fehlerkandidaten oder Abschnitte des SUT, die potentiell für die erfaßten Fehler verantwortlich sind, festzustellen und/oder zu entlasten. Die Beschränkungen können beispielsweise als Regeln und/oder Gleichungen geliefert werden, die beschreiben, wie Daten durch das SUT fließen sollen. Typischerweise wird ein Datenflußmodell, das das fehlerfreie Verhalten des SUT darstellt, verwendet. Bei einem solchen Ausführungsbeispiel kann das SUT unter Verwendung des Datenflußmodells und einer zugeordneten Schlußfolgerungsmaschine diagnostiziert werden. Bei einigen Ausführungsbeispielen können die diagnostizierten Fehler in dem SUT äußerst schnell auftreten und/oder können intermittierend sein.
Mit Bezugnahme auf die Zeichnungen, bei denen gleiche Bezugszeichen entsprechende Komponenten in den verschiedenen Ansichten anzeigen, ist Fig. 1 eine schematische Darstellung, die ein Ausführungsbeispiel eines Systems 10 der vorliegenden Erfindung zeigt. Genauer gesagt, das System 10 umfaßt ein Diagnosesystem 100, das mit einem SUT 110 kommuniziert. Das Diagnosesystem 100 umfaßt ein Datenflußmodell 120 und eine Schlußfolgerungsmaschine 130. Das Datenflußmodell 120 beschreibt den Datenfluß/die Datenflüsse, die dem SUT 110 zugeordnet sind, und die Schlußfolgerungsmaschine 130 interpretiert Testergebnisse bezüglich des Datenflußmodells, wie es nachfolgend näher beschrieben wird. Vorzugsweise umfaßt eine ausgegebene Diagnose des Diagnosesystems 100 eine Anzeige der Komponente/der Komponenten und/oder Teilkomponente(en), deren Ausfall zu den beobachteten Testergebnissen führen konnte.
Ein Flußdiagramm, das die Funktionalität eines Ausführungsbeispiels von System 10 der vorliegenden Erfindung darstellt, ist in Fig. 2 dargestellt. Wie es in Fig. 2 gezeigt ist, kann das System oder Verfahren 10 als bei Block 210 beginnend aufgefaßt werden, wo zumindest einige Abschnitte der Datenübertragungswege eines SUT identifiziert werden. Genauer gesagt, die identifizierten Abschnitte des SUT können in der Lage sein, Fehler in die Datenübertragung einzubringen. Bei Block 220 sind Beschränkungen vorgesehen, die Beziehungen von zumindest einigen der Abschnitte der Datenübertragungswege definieren. Danach, wie es z. B. im Block 230 dargestellt ist, wird das SUT bezüglich der Beschränkungen diagnostiziert.
Die Diagnosesysteme 100 können in Software, Firmware, Hardware oder einer Kombination derselben implementiert sein. Wenn es in Hardware implementiert ist, kann das Diagnosesystem 100 mit jeder oder einer Kombination verschiedener Technologien implementiert werden. Beispielsweise können die folgenden Technologien, die in der Technik gut bekannt sind, verwendet werden: eine diskrete Logikschaltung(en) mit Logikgattern zum Implementieren von Logikfunktionen auf Datensignale hin, eine anwendungsspezifische integrierte Schaltung (ASIC; ASIC = application specific integrated circuit) mit geeigneten Kombinationslogikgattern, ein programmierbare(s) Gatterarray(s) (PGA; PGA = programmable gate array) und ein feldprogrammierbares Gatterarray (FPGA; FPGA = field programmable gate array).
Wenn es in Software implementiert ist, kann das Diagnosesystem 100 ein Programm sein, das durch ein computer- oder prozessorbasiertes Gerät ausführbar ist. Ein Beispiel eines solchen computer- oder prozessorbasierten Geräts wird nun mit Bezugnahme auf die schematische Darstellung von Fig. 3 beschrieben.
Im allgemeinen umfaßt der Computer 300 von Fig. 3 bezüglich der Hardwarearchitektur einen Prozessor 302, einen Speicher 304 und ein oder mehrere Eingabe- und/oder Ausgabe-(I/O-)Geräte 306 (oder Peripheriegeräte), die über eine lokale Schnittstelle 308 kommunikativ gekoppelt sind. Die lokale Schnittstelle 308 kann beispielsweise ein oder mehrere Busse oder andere verdrahtete oder drahtlose Verbindungen sein, wie es in der Technik bekannt ist. Die lokale Schnittstelle 308 kann zusätzliche Elemente umfassen, die zur Erleichterung der Beschreibung ausgelassen sind. Diese zusätzlichen Elemente können beispielsweise Steuerungen, Puffer (Cache), Treiber, Repeater und/oder Empfänger sein. Ferner kann die lokale Schnittstelle Adreß-, Steuer- und/oder Datenverbindungen umfassen, um eine geeignete Kommunikation zwischen den Komponenten des Computers 300 zu ermöglichen.
Der Prozessor 302 kann ein Hardwaregerät sein, das konfiguriert ist, um Software auszuführen, die in dem Speicher 304 gespeichert werden kann. Der Prozessor 302 kann jeder speziell hergestellte oder im Handel erhältliche Prozessor, eine zentrale Verarbeitungseinheit: (CPU; CPU = central processing unit) oder ein Hilfsprozessor unter mehreren Prozessoren sein. Außerdem kann der Prozessor beispielsweise ein halbleiterbasierter Mikroprozessor (in der Form eines Mikrochips) sein.
Der Speicher 304 kann jede Kombination von flüchtigen Speicherelementen (z. B. Direktzugriffsspeicher (RAM, wie z. B. DRAM, SRAM usw.)) und/oder nichtflüchtigen Speicherelementen (z. B. ROM, Festplatte, Band, CDROM usw.) umfassen. Darüber hinaus kann der Speicher 504 elektronische, magnetische, optische und/oder andere Typen von Speichermedien umfassen. Es ist anzumerken, daß der Speicher 304 eine verteilte Architektur aufweisen kann, wo verschiedene Komponenten entfernt voneinander positioniert sind, auf die aber durch den Prozessor 302 zugegriffen werden kann.
Die Software in dem Speicher 304 kann ein oder mehrere getrennte Programme umfassen, von denen jedes eine geordnete Liste von ausführbaren Befehlen zum Implementieren logischer Funktionen umfaßt. Die Software in dem Speicher 304 umfaßt das Diagnosesystem 100 und ein geeignetes Betriebssystem (O/S; O/S = operating system) 310. Es ist anzumerken, daß das Diagnosesystem eine oder mehrere verschieden Funktionen aufweisen kann, wie z. B. Testen 100A, Modellieren 100B und Schlußfolgern 100C, die nachfolgend beschrieben werden. Bei einigen Ausführungsbeispielen können eine oder mehrere dieser Funktionen als getrennte Programme geliefert werden. Das Betriebssystem 310 steuert die Ausführung von anderen Computerprogrammen, wie z. B. dem Diagnosesystem 100. Das Betriebssystem 310 kann außerdem Zeitplanung, Eingabe-/Ausgabesteuerung, Datei- und Datenverwaltung, Speicherverwaltung und Kommunikationssteuerung und verwandte Dienste liefern.
Das/Die I/O-Gerät(e) 306 kann/können Eingabegeräte, wie z. B. eine Tastatur, umfassen. Das/Die I/O-Gerät(e) 306 kann/können auch Ausgabegeräte, wie z. B. ein Anzeigegerät, umfassen. Das/Die I/O-Gerät(e) 306 kann/können ferner Geräte umfassen, die konfiguriert sind, um sowohl Eingaben als auch Ausgaben zu kommunizieren, wie z. B. ein Kommunikationstor.
Wenn der Computer 300 in Betrieb ist, ist der Prozessor 302 konfiguriert, um Software auszuführen, die in dem Speicher 304 gespeichert ist, um Daten zu und von dem Speicher 304 zu kommunizieren, und um allgemein Operationen des Computers zu steuern. Das Diagnosesystem 100 und das Betriebssystem 300 werden ganz oder teilweise durch den Prozessor 302 gelesen, vielleicht in dem Prozessor 302 gepuffert und dann ausgeführt.
Wenn das Diagnosesystem 100 in Software implementiert ist, sollte angemerkt werden, daß das Diagnosesystem auf jedem computerlesbaren Medium durch die Verwendung durch oder in Verbindung mit jedem computerbezogenen System oder Verfahren gespeichert werden kann. Im Zusammenhang dieses Dokuments ist ein computerlesbares Medium ein elektronisches, magnetisches, optisches oder anderes physikalisches Gerät oder eine solche Einrichtung, die ein Computerprogramm für die Verwendung durch oder in Verbindung mit einem computerbezogenen System oder Verfahren enthalten oder speichern kann. Das Diagnosesystem 100 kann in jedem computerlesbaren Medium für die Verwendung durch oder in Verbindung mit einem Befehlsausführungssystem, einer Befehlsausführungsvorrichtung oder einem Befehlsausführungsgerät, wie z. B. einem computerbasierten System, einem prozessorenthaltenden System oder einem anderen System enthalten sein, das die Befehle von dem Befehlsausführungssystem, der Befehlsausführungsvorrichtung oder dem Befehlsausführungsgerät abrufen und die Befehle ausführen kann.
Wie es hierin verwendet ist, kann ein computerlesbares Medium jede Einrichtung sein, die ein Programm für die Verwendung durch oder in Verbindung mit einem Befehlsausführungssystem, einer Befehlsausführungsvorrichtung oder einem Befehlsausführungsgerät speichern, kommunizieren, ausbreiten oder transportieren kann. Somit kann ein computerlesbares Medium beispielsweise ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, eine solche Vorrichtung, ein solches Gerät oder ein solches Ausbreitungsmedium sein, ist aber nicht darauf beschränkt. Genauere Beispiele (eine nichterschöpfende Liste) eines computerlesbaren Mediums umfassen folgende: eine elektrische Verbindung (elektronisch) mit einem oder mehreren Drähten, eine tragbare Computerdiskette (magnetisch), einen Direktzugriffsapeicher (RAM) (elektronisch), einen Nur-Lese-Speicher (ROM) (elektronischen), einen löschbaren programmierbaren Nur-Lese-Speicher (EPROM, EEPROM oder Flash-Speicher) (elektronisch), eine optische Faser (optisch) und einen tragbaren CD-Nur-Lese-Speicher (CDROM) (optisch). Es ist anzumerken, daß das computerlesbare Medium sogar Papier oder ein anderes geeignetes Medium sein könnte, auf dem das Programm gedruckt ist, da das Programm über optisches Abtasten des Papiers oder des anderen Mediums elektronisch erfaßt, dann kompiliert, interpretiert oder, falls notwendig, anderweitig auf geeignete Weise verarbeitet, und dann in einem Computerspeicher gespeichert werden könnte.
Nachfolgend wird auf das Flußdiagramm von Fig. 4 Bezug genommen, das die Funktionalität eines repräsentativen Ausführungsbeispiels eines Diagnosesystems 100 darstellt. Diesbezüglich stellt jeder Block des Flußdiagramms ein Modulsegment oder einen Codeabschnitt dar, der einen oder mehrere ausführbare Befehle oder eine Logik zum Implementieren der spezifischen logischen Funktion(en) darstellt. Es sollte außerdem angemerkt werden, daß bei einigen alternativen Implementierungen die in den verschiedenen Blöcken von Fig. 4 angemerkten Funktionen oder alle anderen der beiliegenden Flußdiagramme in einer anderen Reihenfolge auftreten können, als dargestellt ist. Beispielsweise können zwei Blöcke, die in Fig. 4 aufeinanderfolgend gezeigt sind, in der Tat im wesentlichen gleichzeitig ausgeführt werden. Bei anderen Ausführungsbeispielen können die Blöcke manchmal in umgekehrter Reihenfolge ausgeführt werden, abhängig von der betroffenen Funktionalität.
Wie es in Fig. 4 gezeigt ist, kann das Diagnosesystem oder Verfahren 100 als bei Block 410 beginnend aufgefaßt werden, wo ein Datenflußmodell, das das SUT darstellt, vorgesehen ist. Vorzugsweise umfaßt das Datenflußmodell Informationen, die einer Beziehung der Fehlererfassungsfähigkeiten des SUT entsprechen, obwohl verschiedene andere Charakteristika enthalten sein können, wie es nachfolgend beschrieben wird. Bei Block 420 wird das SUT bezüglich des Datenflußmodells diagnostiziert. Typischerweise umfaßt dies das Erfassen von Testergebnissen, wie z. B. durch Verwenden von Testlogik (siehe Testen 100A von Fig. 3), und durch Analysieren der Testergebnisse mit einer Schlußfolgerungsmaschine (siehe Schlußfolgern 100C von Fig. 3).
Wie vorher erwähnt wurde, beschreibt ein Datenflußmodell den Datenfluß/die Datenflüsse zwischen den verschiedenen Komponenten eines SUT. Es ist anzumerken, daß sich der Begriff "Daten", wie er hierin verwendet wird, auf einen oder mehrere getrennte Informationsabschnitte bezieht, die durch ein SUT gesendet werden. Die Daten könnten beispielsweise als Datenpakete konfiguriert sein.
Vorzugsweise ist die Datenflußsemantik, die in einem Datenflußmodell enthalten ist, von allgemeiner Art und kann auf verschiedene Systeme angewendet werden. Das Datenflußmodell eines speziellen SUT ist vorzugsweise ein gerichteter Graph, der Scheitelpunkte und Kanten umfaßt. Ein Scheitelpunkt stellt das Ende einer Kante dar, d. h. ein Scheitelpunkt wird verwendet, um ein Ende einer Kante zu definieren. Außerdem kann ein Scheitelpunkt einer Position oder einem Abschnitt eines Datenübertragungswegs entsprechen, wo auf Daten eingewirkt werden kann. Beispielsweise kann ein Scheitelpunkt einem Abschnitt eines Datenübertragungswegs entsprechen, der Daten fallenläßt, Daten in mehrere Abschnitte teilt, Daten kombiniert, Daten leitet und/oder Daten reproduziert.
Kanten stellen Datenübertragungswege oder Abschnitte derselben durch ein SUT von einem Scheitelpunkt zu einem anderen dar. Genauer gesagt, Kanten sind direktionale bzw. Richtungskomponenten, die als Gelegenheiten für die Einführung von Datenübertragungsfehlern angesehen werden. Beispielsweise stellt eine Kante (A, B) die bedingte Übertragung von guten oder schlechten Daten dar, z. B. eines Datenpakets von dem Scheitelpunkt A zu dem Scheitelpunkt B. Eine Selbstschleife, z. B. (A, A), ist typischerweise nicht erlaubt.
Fehlererfassungsfähigkeiten eines SUT, das durch ein Datenflußmodell dargestellt ist, werden ebenfalls Kanten zugewiesen. Daher sind Zähler und/oder andere Komponenten, die in der Lage sind, Datenübertragungen zu verfolgen, typischerweise einer oder mehreren Kanten eines Datenflußmodells zugeordnet. Es ist anzumerken, daß das Verfolgen von Daten das Verfolgen von Daten von anderen Typen als gut und schlecht umfassen kann. Somit können Ausführungsbeispiele der Erfindung angepaßt werden, um andere Datencharakteristika auszumachen, abhängig von der speziellen Anwendung.
Bezüglich eines SUT sind Fehlererfassungsfähigkeiten Komponenten zugeordnet, die angepaßt sind, um Überprüfungen durchzuführen, um die Integrität von Daten während und/oder nach einer Operation, wie z. B. Erzeugung, Speicherung, Übertragung und Empfang, zu bestimmen. Solche Prüfungen umfassen zyklische Redundanzprüfungen (CRC; CRC = cyclical redundancy checks) und Nachrichtenauswahlverfahren, wie z. B. MD5. Dies ist selbstverständlich auf diejenigen SUTs anwendbar, die paketbasierte Architekturen umfassen. Bei solch einem SUT kann die Datenübertragungsintegrität beispielsweise durch Erzeugen eines CRC-Codes an einer Position des SUT, durch Neuberechnen des CRC-Codes an einer anderen Position und dann durch Vergleichen der beiden CRC- Codes sichergestellt werden.
Durch Verfolgen von Daten, wie z. B. durch Verwenden von Fehlererfassungsfähigkeiten, kann ein Teil oder eine Komponente eines SUT Informationen erfassen bezüglich dessen, ob fehlerenthaltende Daten, z. B. ein schlechtes Datenpaket, empfangen wurde, gesendet wurde oder demnächst gesendet wird, und/oder ob schlechte Daten fallengelassen wurden oder stromabwärts ausgebreitet wurden. Außerdem kann bei einigen Ausführungsbeispielen der Zustand der Komponente(n) und/oder eine Zeit, die der Fehlerfassung zugeordnet ist, bestimmt werden.
Bei einigen Ausführungsbeispielen wird angenommen, daß die Fehlerprotokollierungsfähigkeit des SUT perfekt ist. Das heißt, es wird typischerweise angenommen, daß das SUT aktiviert ist, um den korrekten Status ankommender Daten an allen Kanten und unter allen Bedingungen zu protokollieren. Dies ist jedoch bei typischen Anwendungen falsch, kann es aber ermöglichen, daß eine effizientere und höherauflösende Diagnose durchgeführt wird. Selbstverständlich könnten bei einigen Ausführungsbeispielen zusätzliche Variablen verwendet werden, wie z. B. zum Erklären einer nicht perfekten Fehlerprotokollierung.
Wie oben angemerkt wurde, verwenden Diagnosesysteme der vorliegenden Erfindung Beschränkungen, um Fehlerkandidaten von SUTs zu diagnostizieren. Bei einigen Ausführungsbeispielen können die Beschränkungen unter Verwendung linearer Programmierung angelegt werden. Ausführungsbeispiele von Diagnosesystemen, die lineares Programmieren verwenden, um SUTs zu bewerten, verwenden typischerweise Beschränkungsgleichheiten und/oder -ungleichheiten, um Datenflußbeziehungen gemäß der Funktionalität der jeweiligen SUTs zu definieren.
Eine lineare Programmierung kann beispielsweise verwendet werden, um eine mögliche Lösung zu finden, unter Berücksichtigung von SUT-Funktionalitätsbeschränkungen und Beschränkungen, die Tests zugeordnet sind, z. B. Gesamtzahl von versuchten Daten, z. B. Datenpaketübertragungen und/oder Beschränkungen, die beobachtetem Verhalten (Testergebnissen) zugeordnet sind. Insbesondere kann bei einigen Ausführungsbeispielen eine lineare Programmierung verwendet werden, um die Anzahl von Datenpaketen, die an jeder Kante schlechtgemacht werden, zu optimieren/maximieren.
Man nehme beispielsweise an, daß ein gerichteter Graph G = (V, E), der den zulässigen Datenfluß, z. B. Datenpakete, modelliert, vorgesehen ist. Ein Scheitelpunkt v ∈ V von G ist eine Position, wo Messungen durchgeführt werden können, die Güte oder Schlechtheit von Paketen getestet werden kann, z. B. durch Prüfen eines CRC-Codes, und/oder schlechte Pakete fallengelassen werden können.
Ein Scheitelpunkt kann mit Informationen über bestimmte Verhaltenscharakteristika des Scheitelpunkts markiert sein. Beispielsweise ist ein "prop"-Scheitelpunkt ein Scheitelpunkt, der schlechte Pakete ausbreitet, und ein "noprop"- Scheitelpunkt ist ein Scheitelpunkt, der alle schlechten Pakete, die erfaßt werden, fallenläßt. Man lasse Λ = {prop, noprop} den Satz von möglichen Scheitelpunkttags bzw. -etiketten sein. Jeder Scheitelpunkt v ∈ V weist einen zugeordneten Satz von Etiketten auf, gegeben durch die Funktion T : V → 2^Λ. Die gerichteten Kanten E ⊆ V × V sind Kommunikationswege zwischen Scheitelpunkten. Ohne die Allgemeingültigkeit zu verlieren, werden typischerweise nur Einzelrichtungskanten, d. h. Kanten mit nur einem Pfeil, verwendet. Andernfalls kann eine bidirektionale Kante durch zwei Einzelrichtungskanten ersetzt werden. Es sei daran erinnert, daß die Kanten (j, i) ∈ E als "In-Kanten" von i bezeichnet werden, und daß die Kanten (i, j) ∈ E als "Aus- Kanten" von i bezeichnet werden.
Die folgende Semantik von Kanten wird typischerweise angenommen: ein Paket, das in einen Scheitelpunkt v fließt, von irgendeiner der In-Kanten derselben, kann aus jeder Aus- Kante fließen. Falls bekannt ist, daß ein System oder ein Test den Fluß von Datenpaketen begrenzt, die an einer speziellen Kante oder Kanten in einen Scheitelpunkt eindringen, um aus einer anderen speziellen Kante oder Kanten auszutreten, sollte der Scheitelpunkt in zwei oder mehr Scheitelpunkt gebrochen werden. Ein Scheitelpunkt wird als Quelle bezeichnet, falls er keine In-Kanten aufweist. Er wird als Senke bezeichnet, falls er keine Aus-Kanten aufweist.
Zusätzlich zu dem Graph G wird angenommen, daß es einen Satz von Zählern Ψ und eine Abbildung (MAP) M : E × {t, r} × {gut, schlecht} Ψ gibt. Die Abbildung M gibt die Semantik der Zähler. Sie sollte wie folgt interpretiert werden:
Angenommen, M ((i, j), t, gut) = Ψ. Der Zähler Ψ wird jedesmal inkrementiert, wenn ein gutes Paket von dem Scheitelpunkt i auf die Kante (i, j) gesendet wird.
Angenommen, M ((i, j), t, schlecht) = Ψ. Dann wird Ψ jedesmal inkrementiert, wenn ein schlechtes Paket von dem Scheitelpunkt i auf die Kante (i, j) gesendet wird.
Angenommen, M ((i, j), r, gut) = Ψ. Dann wird Ψ jedesmal inkrementiert, wenn ein gutes Paket durch den Scheitelpunkt j über die Kante (i, j) empfangen wird.
Angenommen, M ((i, j), r, schlecht) = Ψ. Dann wird Ψ jedesmal inkrementiert, wenn ein schlechtes Paket von dem Scheitelpunkt i über die Kante (i, j) empfangen wird.
Es ist anzumerken, daß eine Abbildung M Eins-zu-Eins sein sollte, aber nicht sein muß. Beispielsweise nehme man an, daß ein Scheitelpunkt v drei In-Kanten (x, v), (y, v) und (z, v) aufweist. Es wird gewünscht, daß Ψ alle guten Pakete zählt, die bei v ankommen. Dann gilt:

M(((x, v), r, gut)) = M(((y, v), r, gut)) = M(((z, v), r, gut = Ψ
Auf gleiche Weise kann ein einziger Zähler verwendet werden, um eine große Vielzahl von unterschiedlichen Ereignissen zu zählen, die an verschiedenen. Kanten stattfinden. Ein Satz von speziell gemessenen Werten für jeden Zähler wird als ein Syndrom bezeichnet.
Ausführungsbeispiele einer Schlußfolgerungsmaschine, die lineares Programmieren verwendet, können im allgemeinen so beschrieben werden, daß sie drei Teilbereiche umfassen: (1) Beschränkungsextraktion, (2) Hinzufügen von Syndrombeschränkungen und (3) Bestimmung, welche Fehlerkandidaten unter den Beschränkungen und den Syndromen möglich sind. Typischerweise kann der erste Teilbereich für ein bestimmtes SUT im voraus berechnet werden. Außerdem müssen typischerweise nur der zweite und der dritte Teilbereich für jedes Syndrom wiederholt werden.
Bezüglich der Beschränkungsextraktion wird ein Satz von Variablen ∪_(i/j) _∈ _E {g(i, j), b(i, j), mb(i, j} erzeugt. Die Variable g(i, j) stellt die Anzahl von guten Paketen dar, die auf der Kante (i, j) gesendet werden. Die Variable b(i, j) stellt die Anzahl von schlechten Paketen dar, die durch den Scheitelpunkt i auf der Kante (i, j) gesendet werden. Die Variable mb(i, j) stellt die Anzahl von Paketen dar, die auf der Kante (i, j) schlechtgemacht werden, d. h. die Pakete, die als gut gesendet werden, aber als schlecht empfangen werden.
Im allgemeinen wird ein anfangs leerer Satz von Beschränkungen C erzeugt. Für jeden Scheitelpunkt i, der zumindest eine In-Kante und zumindest eine Aus-Kante aufweist, wird von den nachfolgend definierten Beschränkungen eine Beschränkung (KG) zu C hinzugefügt. Für jeden Scheitelpunkt, der zumindest eine Aus-Kante aufweist, wird zu C folgendes hinzugefügt: eine Beschränkung auf schlechte Pakete, ein prop-Scheitelpunkt (KBP), falls prop ∈ T(i); oder eine Beschränkung auf schlechte Pakete, noprop-Scheitelpunkt (KBNP), falls prop ∉ T(i).
Das folgende sind darstellende Beschränkungen, die zum Beschreiben der repräsentativen Datenflußbeziehungen verwendet werden. KG (Beschränkung auf gute Pakete):
Die Beschränkung KG zeigt an, daß die Anzahl von guten Paketen, die zu Scheitelpunkt i gesendet werden, minus der Anzahl von Paketen, die in den In-Kanten von i schlechtgemacht werden, gleich sein muß wie die Anzahl von guten Paketen, die aus i fließt. KBP (Beschränkung auf schlechte Pakete, prop- Scheitelpunkt)
Die Beschränkung KBP zeigt an, daß bei einem prop- Scheitelpunkt i die Anzahl von schlechten Paketen, die zu i gesendet werden, plus die Anzahl von Paketen, die in den In-Kanten von i schlechtgemacht werden, gleich sein muß wie die Anzahl von Paketen, die aus i fließt. KBNP (Beschränkung auf schlechte Pakete, noprop- Scheitelpunkt)
Die Beschränkung KBNP zeigt an, daß keine schlechten Pakete von einem nonprop-Scheitelpunkt gesendet werden.
Zählerbeschränkungen werden ebenfalls zu C hinzugefügt. Beispielsweise wird für jeden Zähler ψ ∈ Ψ eine COUNTER- (ZÄHLER-)Beschränkung zu C hinzugefügt:
COUNTER (Spezifiziere die Ereignisse, die ψ zählt):
Es ist anzumerken, daß es außerdem typischerweise notwendig ist, alle Variablen darauf zu beschränken, daß sie nicht negativ sind, d. h. es gibt keine negativen Paketflüsse. Außerdem ist es bei einigen Situationen wünschenswert, alle oder einige Variablen darauf zu beschränken, Ganzzahlen zu sein.
Um mit der Hinzufügung von Syndrombeschränkungen fortzufahren, umfaßt ein Syndrom typischerweise Werte, die den verschiedenen Zählern eines SUT zugeordnet sind. Für jeden solchen Zähler addiere man eine Gleichheit zu C, die den Wert des Zählers spezifiziert. Falls beispielsweise der Scheitelpunkt 17 einen txcrc-Zähler aufweist, der den Wert 127 zeigt, und einen guten Zähler, der den Wert 1001 zeigt, addiere man die Beschränkungen txcrc (17) = 127 und goodctr (17) = 1001. Diese Syndrombeschränkungen werden als S bezeichnet.
Bezüglich der Bestimmung möglicher Fehlerkandidaten ist es die Aufgabe, zu bestimmen, welche Fehlerkandidaten möglicherweise die erfaßten schlechten Pakete bewirkt haben könnten. Vorzugsweise entspricht jeder Fehlerkandidat genau einer Kante (i, j) ∈ E. Jede solche (i, j) entspricht einer Variable mb(i, j).
Da bei diesem Ausführungsbeispiel ein Fehlerkandidat fehlerhaft sein kann, falls und nur falls es eine Lösung der Beschränkungen gibt, wo der Fehlerkandidat zumindest ein schlechtes Paket bewirkte, kann die Kante (i, j) fehlerhaft sein, falls und nur falls max {mb(i, j)|C, S} ≥ 1. Da die Beschränkungen C und S alle linear sind, ist dieses Maximierungsproblem ein lineares Programmierungsproblem (LP- Problem).
Verschiedene Routinen können zum Lösen von LP-Problemen verwendet werden. Beispielsweise gibt es viele Bibliotheksroutinen, wie z. B. lp_solve, die zum Lösen von LP- Problemen verfügbar sind. Der Quellcode für lp_solve ist hierin durch Bezugnahme aufgenommen. Es ist anzumerken, daß bei lp_solve die Variablen als Vorgabe nicht negativ sind, daher müssen die Variablen nicht explizit als nicht negativ beschränkt werden.
Bei einigen Anwendungen kann es wünschenswert sein, eine Anzahl von gleichzeitigen Fehlern zu erzwingen. Beispielsweise kann aufgrund einer a priori Kenntnis oder einer Kundenpräferenz eine Anzahl von gleichzeitigen fehlerhaften Kanten erzwungen werden. Alternativ, nach Occams Razor, ist es wünschenswert, mit einer minimalen Anzahl von defekten Kanten zu einer Diagnose zu gelangen. Eine solche Diagnose kann gefunden werden, indem zunächst versucht wird, eine einzige fehlerhafte Kante zu finden, die die verfügbaren Daten erklärt. Dann, falls keine existiert, versucht man, ein Paar von fehlerhaften Kanten zu finden, die die verfügbaren Daten erklären. Dieser Prozeß kann fortgesetzt werden, bis eine Mehrfachdefekthypothese gefunden ist, die das Syndrom erklärt.
Man nehme an, eine Diagnose mit genau k gleichzeitigen Defekten ist gewünscht. Dann, für alle F ⊆ E,|F| = k, lasse man D (F) die Beschränkungen mb(f) ≥ 1 für f ∈ F und mb(f) = 0 für f ∉ F sein. F ist ein Satz von k Defekten, die das Syndrom erklären, falls, und nur falls, C, S und D(F) eine ausführbare Lösung haben.
Das Testen, ob eine ausführbare Lösung existiert, kann durchgeführt werden durch Einrichten eines linearen Programms mit jeder objektiven Funktion, die den Beschränkungen C, S und D(F) unterliegt. Jede Linearprogrammierungssubroutine sollte entweder einen optimalen Wert zurücksenden, in diesem Fall weisen die Beschränkungen eine ausführbare Lösung auf, oder eine Anzeige zurücksenden, daß das lineare Programm nicht ausführbar ist, in diesem Fall sind C, S und D(F) nicht gleichzeitig erfüllbar, d. h. die gleichzeitigen Fehler F erklären das gemessene Syndrom nicht.

Lineares Programmieren Fall 1

Nachfolgend wird auf das Datenflußmodell von Fig. 5 Bezug genommen. Jeder Scheitelpunkt, z. B. Scheitelpunkt 1, Scheitelpunkt 2 und Scheitelpunkt 3, zeigt vordefinierte Verhaltenscharakteristika. Insbesondere ist der Scheitelpunkt 1 in der Lage, gute gesendete Pakete zu zählen, der Scheitelpunkt 2 ist in der Lage, schlechte empfangene Pakete zu zählen, und der Scheitelpunkt 3 ist in der Lage, gute empfangene Pakete zu zählen. Außerdem breiten sowohl der Scheitelpunkt 1 als auch 3 empfangene schlechte Pakete nicht aus, und der Scheitelpunkt 2 breitet empfangene schlechte Pakete aus.
Basierend auf dem Datenflußmodell 500 können drei Zähler verwendet werden: Ψ = {ψ₁, ψ₂, ψ₃}.
Die Abbildung M ist gegeben durch:
M((1, 2), t, gut) = ψ₁
M((1, 2), r, schlecht) = ψ₂
M((2, 3), r, gut) = ψ₃
Die Beschränkungen C, die sich aus dem Datenflußmodell 500 ergeben, sind:
b_1_2 = 0; (KBNP auf Scheitelpunkt 1)
g_1_2 - mb_1_2 - g_2_3 = 0; (KG auf: Scheitelpunkt 2)
b_1_2 + mb_1_2 - b_2_3 = 0; (KBP auf Scheitelpunkt 2)
g_1_2 = psi_1; (ZÄHLER AUF ψ₁)
b_1_2 + mb_1_2 = psi_2; (ZÄHLER AUF ψ₂)
g_2_3 - mb_2_3 = psi_3; (ZÄHLER AUF ψ₃)
Es wird angenommen, daß der Scheitelpunkt 1 auf der Basis erfaßter Testergebnisse 20 gute Pakete zählte, der Scheitelpunkt 2 einen CRC-Fehler zählte und der Scheitelpunkt 3 19 gute Pakete zählte. Die Beschränkungen S, die sich von diesem Syndrom ergeben, sind:
psi_1 = 20
psi_2 = 1
psi_3 = 19
Die zu lösenden Ungleichheiten, um die Diagnose durchzuführen, sind:
1. max {mb_1_2|C, S} ≥ falls, und nur falls, Kante (1, 2) fehlerhaft sein kann; und
2. max {mb_2_3|C, S} ≥ falls, und nur falls, Kante (2, 3) fehlerhaft sein kann.
Die optimalen Werte der linearen Programme sind:
max { mb_1_2|C, S} = 1; und
max { mb_2_3|C, S} = 0.
Somit ist die Kante (1, 2) defekt.

Lineares Programmieren Fall 2

Nachfolgend wird auf Fig. 6 Bezug genommen, die ein Blockdiagramm eines repräsentativen SUT darstellt. Wie es in Fig. 6 gezeigt ist, umfaßt das SUT 600 fünf Komponenten, d. h. START, N2PB, PBIF, BUF und CBOC. Jede Komponente zeigt vordefinierte Verhaltenscharakteristika. Insbesondere ist jede der dargestellten Komponenten von SUT 600 in der Lage, empfangene Daten, z. B. Datenpakete, zu zählen, und CRC- Prüfungen durchzuführen. Außerdem sollte angemerkt werden, daß mehrere Komponenten bezüglich zueinander unterschiedlich ausführen, wenn sie schlechte Daten empfangen. Genauer gesagt, sowohl N2PB als auch BUF breiten empfangene schlechte Daten aus, und sowohl START als auch PBIG breiten empfangene schlechte Daten nicht aus. Außerdem gibt es zwei unterschiedliche Arten von BUFF-Einheiten. "Smart Buff"' (intelligenter Buff) zählt gute empfangene Pakete, der "Dumb Buff" (dummer Buff) tut dies nicht.
In dem Fall des "Dumb Buff" können vier Zähler verwendet werden: Ψ = {(ψ₁, ψ₂, ψ₃, ψ₄. Die Abbildung M ist gegeben durch:
M((Start, n2pb), t, gut) = ψ₁
M((Start, n2pb), r, gut) = ψ₂
M((n2pb, pbif), r, gut) = M((buff, pbif), r, gut = ψ₃; und M((pbif, cboc), r, gut) = ψ₄.
Es ist anzumerken, daß zwei unterschiedliche Argumente zu M auf ψ₃ abbilden. Somit wird ψ₃ jedesmal inkrementiert, wenn ein gutes Paket durch pbif empfangen wird, auf einer der beiden In-Kanten desselben, je nach Wunsch. In dem Fall des Smart Buff ist ein zusätzlicher Zähler ψ₅ erforderlich, und M((pbif, buff), r, gut) = ψ₅.
Das Datenflußmodell 700 von Fig. 7 kann auf der Basis der Informationen aufgebaut werden, die bezüglich des SUT 600 von Fig. 6 präsentiert werden. Es ist anzumerken, daß das Blockdiagramm von Fig. 6 und das Datenflußmodell 700 von Fig. 7 eine Datenflußmehrdeutigkeit aufweisen. Das heißt, sowohl das Blockdiagramm als auch das Datenflußmodell 700 beschreiben nicht, wie Daten tatsächlich von PBIF zu CBOC fließen. Genauer gesagt, es ist mehrdeutig, ob Daten, die bei PBIF ankommen, zunächst zu BUF und zurück fließen, bevor dieselben zu CBOC gesendet werden, oder ob BUF irgendwie umgangen wird. Aufgrund dieser Mehrdeutigkeit kann das Datenflußmodell 700, das direkte Entsprechungen für die fünf Komponenten des Blockdiagramms von Fig. 6 liefert, weniger nützlich sein als andere Datenflußmodelle, die keine solche Mehrdeutigkeit enthalten. Wenn beispielsweise Informationen bezüglich des tatsächlichen Datenflusses von PBIF zu CBOC erfaßt werden, kann ein unzweideutiges Datenflußmodell, das die Übertragung von Daten durch das SUT darstellt, aufgebaut werden. Ein Ausführungsbeispiel eines solchen Datenflußmodells wird nachfolgend mit Bezugnahme auf Fig. 8 beschrieben.
Mit Bezugnahme auf das Datenflußmodell von Fig. 7 wurden fünf Syndrome erzeugt, von denen jedes ein mögliches Syndrom ist, die sich aus einem intermittierenden Ausfall von einer der fünf Kanten in dem Datenflußmodell ergeben. Die Syndrome sind in Tabelle 1 gezeigt. Tabelle 1 Syndrome, die im Fall 1 und 2 verwendet werden
Die Ergebnisse des Lösens der Probleme der linearen Programmierung sind in Tabelle 2 und Tabelle 3 gezeigt. Es ist daran zu erinnern, daß ein Nicht-Null-Eintrag impliziert, daß die entsprechende Fehlerhypothese ein möglicher Ausfallgrund ist. Der Wert ist die Anzahl von schlechten Paketen, die dieser Ausfallursache zugewiesen sind. Tabelle 2 Ergebnisse von LP-Lösungen für Fall 2, Dumb Buffer

Tabelle 3 Ergebnisse der LP-Lösung für den Fall 2, Smart Buffer

Lineares Programmieren Fall 3

Bei diesem Beispiel wird eine weitere Annahme zu derjenigen hinzugefügt, die vorher in Bezugnahme auf Fall 2 beschrieben wurde. Insbesondere wird angenommen, daß eine zusätzliche Beschränkung bekannt ist, d. h. daß Pakete von n2pb zu pbifzu buffzu pbifzu cboc fließen müssen. Dann kann ein genaueres Datenflußmodell für das SUT aufgebaut werden. Ein solches Datenflußmodell ist in Fig. 8 dargestellt.
Wie es in Fig. 8 gezeigt ist, umfaßt das Datenflußmodell 800 die Scheitelpunkte START, N2PB, PBIF1, BUF, PBIF2 und CBOC. Die Kanten START → N2PB, N2PB → PBIF1, PBIF1 → BUF, BUF → PBIF2 und PBIF2 → CBOC sind durch die Scheitelpunkte definiert. Somit wurde die Komponente IF von Fig. 6 für den Zweck des Datenflußmodells 800 neu definiert, als zwei bestimmte Scheitelpunkte, d. h. PBIF1 und PBIF2, wodurch die Datenflußmehrdeutigkeit entfernt wurde.
Wie im Fall 2 können vier Zähler verwendet werden: Ψ = {ψ₁, ψ₂, ψ₃, ψ₄}. Die Abbildung M ist gegeben durch:
M((Start, n2pb), t, gut) = ψ₁
M((Start, n2pb), r, gut) = ψ₂
M((n2pb, pbif1), r, gut) = M((buff, pbif2), r, gut = ψ₃
M((pbif2, cboc), r, gut) = ψ_4.
Es ist anzumerken, daß ψ₃inkrementiert wird, wenn entweder durch pbif1 oder durch pbif2 ein gutes Paket empfangen wird. Dies liegt daran, daß pbif bei dem ursprünglichen Datenflußmodell von Fig. 7 alle ankommenden guten Pakete zählt, die auf jeder Kante ankommen.
Die Beschränkungen C sind:
g_start_n2pb - mb_start_n2pb - g_n2pb_pbif1 = 0;
b_start_n2pb + mb_start_n2pb - b_n2pb_pbif1 = 0;
g_n2pb_pbf1 - mb_n2pb_pbif - g_pbif1_buff = 0;
b-pbif1_buff = 0;
g_pbif1_buff - mb_pbifbuff - g_buffpbif2 = 0;
b_pbif1_buff + mb_pbifbuff - b_buffpbif2 = 0;
g_buffpbif2 - mb_buffpbif - g_pbif2_cboc = 0;
b_pbif2_cboc = 0;
g_start_n2pb = psi_1;
gstart_n2pb - mb_start_n2pb = psi_2;
g_n2pb_pbif1 - mb_n2pb_pbif + g_buff_pbif2 - mb_buff_pbif = psi 3;
g_pbif2_cboc - mb_pbif_cboc = psi 4.
Die Ergebnisse des Lösens der LP-Probleme erscheinen in Tabelle 4 und 5. In diesem Fall sind die Variablen außerdem darauf beschränkt, Ganzzahlen zu sein. Tabelle 4 Ergebnisse der LP-Lösung für Fall 3, Dumb Buffer

Tabelle 5 Ergebnisse der LP-Lösung für Fall 3, Smart Buffer

Claims

1. Verfahren zum Diagnostizieren von Fehlern in einem zu testenden System (SUT) (110), wobei das SUT Datenübertragungswege definiert, durch die Daten gesendet werden, wobei das Verfahren folgende Schritte umfaßt:
Identifizieren (210) zumindest einiger Abschnitte der Datenübertragungswege des SUT, die in der Lage sind, Fehler in die Datenübertragung einzubringen;
Liefern (220) von Beschränkungen, die Beziehungen von zumindest einigen der Abschnitte der Datenübertragungswege, die identifiziert wurden, definieren; und
Diagnostizieren (230) des SUT bezüglich der Beschränkungen.

2. Verfahren gemäß Anspruch 1, bei dem das Identifizieren das Liefern eines Datenflußmodells (120) umfaßt, das dem SUT (110) entspricht, wobei das Datenflußmodell (120) Kanten umfaßt, von denen jede einem Abschnitt von einem der Datenübertragungswege des SUT (110) entspricht, der in der Lage ist, Fehler bei der Datenübertragung einzubringen.

3. Verfahren gemäß Anspruch 2, bei dem das Datenflußmodell (120) Scheitelpunkte umfaßt, wobei jede der Kanten zwischen zwei der Scheitelpunkte definiert ist.

4. Verfahren gemäß Anspruch 3, bei dem jeder der Scheitelpunkte zumindest entweder ein Abschluß einer Kante ist oder eine Position darstellt, wo eine Operation bezüglich Daten auftreten kann.

5. Verfahren gemäß Anspruch 4, bei dem die Operation, die einem Scheitelpunkt entspricht, zumindest entweder das Fallenlassen von Daten, das Spalten von Daten, das Leiten von Daten, das Reproduzieren von Daten und das Kombinieren von Daten umfaßt.

6. Verfahren gemäß Anspruch 4 oder 5, das ferner folgende Schritte umfaßt:
Empfangen von Testergebnissen, die dem SUT (110) entsprechen; und
bei dem das Diagnostizieren das Analysieren der Testergebnisse bezüglich des Date nflußmodells (120) umfaßt.

7. Verfahren gemäß Anspruch 6, bei dem das SUT (110) Zähler umfaßt, die zumindest einigen der Kanten des Datenflußmodells (120) entsprechen; und
ferner folgenden Schritt umfaßt:
Empfangen von Informationen, die den Testergebnissen entsprechen, von zumindest einigen der Zählern.

8. Verfahren gemäß Anspruch 6 oder 7, bei dem das Datenflußmodell (120) ein gerichteter Graph ist.

9. Verfahren gemäß einem der Ansprüche 6 bis 8, bei dem das Analysieren der Testergebnisse folgende Schritte umfaßt:
Empfangen von Informationen, die mißlungenen Datenübertragungen entsprechen; und
Identifizieren von Abschnitten des SUT (110), die den mißlungenen Datenübertragungen potentiell zugeordnet sind.

10. Verfahren gemäß Anspruch 9, bei dem das Analysieren der Testergebnisse folgenden Schritt umfaßt:
Entlasten von Abschnitten des SUT (110), die anfangs als den mißlungenen Datenübertragungen zugeordnet identifiziert wurden, falls bestimmt wird, daß diese Abschnitte des SUT (110) nicht zumindest eine der mißlungenen Datenübertragungen ausgelöst haben.

11. Verfahren gemäß einem der Ansprüche 1 bis 10, bei dem das Diagnostizieren des SUT folgenden Schritt umfaßt:
Empfangen von Informationen bezüglich Datenübertragungen bezüglich der identifizierten Abschnitte, wobei die Informationen über eine zyklische Redundanzprüfung erhalten werden.

12. Verfahren gemäß einem der Ansprüche 1 bis 11, bei dem das Identifizieren das Liefern eines Datenflußmodells (120) umfaßt, das dem SUT (110) entspricht, wobei das Datenflußmodell (120) Kanten und Scheitelpunkte umfaßt, wobei jede der Kanten einem Abschnitt von einem der Datenübertragungswege des SUT entspricht, der in der Lage ist, Fehler in die Datenübertragung einzubringen, wobei jede der Kanten zwischen zwei der Scheitelpunkte definiert ist; und
wobei die Beschränkungen Datenflußcharakteristika des SUT entsprechen, das bezüglich der Scheitelpunkte gezeigt ist.

13. Verfahren gemäß Anspruch 12, bei dem zumindest eine der Beschränkungen von zumindest einem der Scheitelpunkte anzeigt, daß eine Datenmenge, die in den Scheitelpunkt fließt, einer Datenmenge entspricht, die von dem Scheitelpunkt fließt.

14. Verfahren gemäß Anspruch 13, bei dem die Datenmenge, die in den Scheitelpunkt fließt, einer Menge von zumindest: guten Daten, schlechten Daten und einem speziehen Datentyp, der in den Scheitelpunkt fließt, entspricht.

15. Verfahren zum Diagnostizieren von Fehlern in einem zu testenden System (SUT) (110), wobei das Verfahren folgende Schritte umfaßt:
Liefern (410) eines Datenflußmodells, das das SUT darstellt, wobei das Datenflußmodell Informationen umfaßt, die einer Beziehung von Fehlererfassungsfähigkeiten des SUT entsprechen; und
Diagnostizieren (420) des SUT bezüglich des Datenflußmodells.

16. Verfahren gemäß Anspruch 15, bei dem das Diagnostizieren des SUT folgenden Schritt umfaßt: Liefern von Beschränkungen, die Beziehungen von zumindest einigen der Abschnitte des Datenflußmodells definieren.

17. Verfahren gemäß Anspruch 15 oder 16, bei dem das Diagnostizieren des SUT folgenden Schritt umfaßt: Erzeugen von Informationen, die eine Versagensweise des SUT anzeigen.

18. Verfahren gemäß Anspruch 17, bei dem der Datenfluß ein Fluß von Datenpaketen ist; und
bei dem das Diagnostizieren des SUT ferner folgenden Schritt umfaßt:
Analysieren von Informationen, die über zyklische Redundanzprüfungen erfaßt wurden, die an verschiedenen Positionen, die dem Datenfluß zugeordnet sind, durchgeführt wurden.

19. Verfahren gemäß einem der Ansprüche 15 bis 18, bei dem dem Datenflußmodell Prozeßinhalt und Prozeßaufrufe fehlen.

20. System (10) zum Diagnostizieren von Fehlern in einem zu testenden System (110), wobei das System folgende Merkmale umfaßt:
ein Datenflußmodell (120), das Fehlererfassungsfähigkeiten des SUT darstellt; und
eine Schlußfolgerungsmaschine (130), die dem Datenflußmodell zugeordnet ist, wobei die Schlußfolgerungsmaschine angepaßt ist, um Testergebnisse auszuwerten, die dem SUT entsprechen, bezüglich des Datenflußmodells.

21. System gemäß Anspruch 20, bei dem das Datenflußmodell ein gerichteter Graph ist, der Kanten und Scheitelpunkte umfaßt, wobei jede der Kanten zumindest einem Abschnitt eines Datenübertragungswegs des SUT entspricht, durch den ein Fehler eingeführt werden kann, wobei jede der Kanten durch zwei der Scheitelpunkte definiert ist.

22. System gemäß Anspruch 20 oder 21, bei dem die Schlußfolgerungsmaschine angepaßt ist, um die Testergebnisse des SUT bezüglich Beschränkungen auszuwerten, wobei die Beschränkungen die Beziehungen von zumindest einigen der Abschnitte des Datenflußmodells definieren.

23. System gemäß einem der Ansprüche 20 bis 22, bei dem die Schlußfolgerungsmaschine angepaßt ist, um Informationen bezüglich mißlungener Datenübertragungen zu empfangen und Abschnitte des SUT zu identifizieren, die den mißlungenen Datenübertragungen potentiell zugeordnet sind.

24. System gemäß einem der Ansprüche 20 bis 23, das ferner folgendes Merkmal umfaßt: ein SUT, das kommunikativ zumindest entweder mit dem Datenflußmodell (120) oder der Schlußfolgerungsmaschine (130) gekoppelt ist.

25. System zum Diagnostizieren von Fehlern in einem zu testenden System, wobei das System folgende Merkmale umfaßt:
eine Einrichtung zum Empfangen von Testergebnissen, die zumindest einigen Abschnitten der Datenübertragungswege des SUT entsprechen; und
eine Einrichtung zum Diagnostizieren der SUT bezüglich Beschränkungen, die Beziehungen von zumindest einigen Abschnitten der Datenübertragungswege des SUT definieren.

26. System gemäß Anspruch 25, bei dem die Einrichtung zum Diagnostizieren eine Einrichtung zum Analysieren des SUT bezüglich eines Datenflußmodells umfaßt.

27. System gemäß Anspruch 25 oder 26, das ferner folgendes Merkmal umfaßt: eine Einrichtung zum Testen des SUT, um Testergebnisse zu erzeugen.

28. Diagnosesystem, das auf einem computerlesbaren Medium gespeichert ist, wobei das Diagnosesystem angepaßt ist, um Fehler in einem zu testenden System (SUT) zu diagnostizieren, wobei das Diagnosesystem folgende Merkmale umfaßt:
eine Logik, die konfiguriert isst, um zumindest einige Abschnitte der Datenübertragungswege des SUT zu identifizieren, die in der Lage sind, Fehler in die Datenübertragung einzubringen;
eine Logik, die konfiguriert ist, um Beschränkungen zu liefern, die Beziehungen von zumindest einigen der Abschnitte der Datenübertragungswege definieren; und
eine Logik, die konfiguriert ist, um das SUT bezüglich der Beschränkungen zu diagnostizieren.

29. Diagnosesystem gemäß Anspruch 28, bei dem die Logik, die konfiguriert ist, um zu diagnostizieren, folgende Merkmale umfaßt:
eine Logik, die konfiguriert ist, um ein Datenflußmodell zu liefern; und
eine Logik, die konfiguriert ist, um das SUT bezüglich eines Datenflußmodells zu analysieren.

30. Diagnosesystem gemäß Anspruch 28 oder 29, bei dem die Logik, die konfiguriert ist, um zu diagnostizieren, eine Logik umfaßt, die konfiguriert ist, um Informationen zu erzeugen, die den Datenfluß anzeigen, der einem Zeitpunkt der Fehlererfassung zugeordnet ist.

31. Diagnosesystem gemäß einem der Ansprüche 28 bis 30, bei dem die Logik, konfiguriert ist, um zu diagnostizieren, eine Logik umfaßt, die konfiguriert ist, um Abschnitte des SUT zu identifizieren, die potentiell mißlungenen Datenübertragungen zugeordnet sind.

32. Diagnosesystem gemäß Anspruch 31, bei dem die Logik, die konfiguriert ist, zu diagnostizieren, eine Logik umfaßt, die konfiguriert ist, um Komponenten zu entlasten, die anfangs als den mißlungenen Datenübertragungen zugeordnet identifiziert wurden.