DE3786381T2 - Prüfverfahren und -gerät für ein verteiltes Verarbeitungssystem. - Google Patents
Prüfverfahren und -gerät für ein verteiltes Verarbeitungssystem.Info
- Publication number
- DE3786381T2 DE3786381T2 DE87110477T DE3786381T DE3786381T2 DE 3786381 T2 DE3786381 T2 DE 3786381T2 DE 87110477 T DE87110477 T DE 87110477T DE 3786381 T DE3786381 T DE 3786381T DE 3786381 T2 DE3786381 T2 DE 3786381T2
- Authority
- DE
- Germany
- Prior art keywords
- data
- subsystem
- program
- function
- test
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000010998 test method Methods 0.000 title claims description 4
- 238000012360 testing method Methods 0.000 claims description 115
- 238000000034 method Methods 0.000 claims description 39
- 230000005540 biological transmission Effects 0.000 claims description 20
- 238000003745 diagnosis Methods 0.000 claims description 17
- 230000002159 abnormal effect Effects 0.000 description 10
- 238000010586 diagram Methods 0.000 description 9
- 238000011084 recovery Methods 0.000 description 6
- 230000002950 deficient Effects 0.000 description 4
- 230000005856 abnormality Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000002405 diagnostic procedure Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
- G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
- G01R31/28—Testing of electronic circuits, e.g. by signal tracer
- G01R31/317—Testing of digital circuits
- G01R31/31701—Arrangements for setting the Unit Under Test [UUT] in a test mode
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
Description
- Die Erfindung betrifft ein Prüfverfahren und eine Prüfvorrichtung, durch die ein Prüfmodus und ein Onlinemodus in einem verteilten System ausgetauscht werden.
- Die Japanische Patentanineldung JP-A-57146361 offenbart ein Verfahren, durch das in einem verteilten Verarbeitungssystem, bei dem die Reihe von Prozessen eines Tasks in verteilter Weise durch mehrere an eine gemeinsame Übertragungsleitung angeschlossene Prozessoren ausgeteilt wird und ein Programm zum Ausführen jeder der Reihe von Prozessen dann gestartet wird, wenn Einzeldaten, wie sie für die Ausführung des Programms erforderlich sind, insgesamt von der Übertragungsleitung in den eigenen Prozessor übernommen wurden. Dieses Verfahren erlaubt es den jeweiligen Prozessoren, die entsprechenden der Reihen von Prozessen verteilt auszuführen, ohne daß ein Erfordernis für einen Verwaltungsprozessor zum Verwalten des gesamten Systems besteht. Jedoch beinhaltet es kein Mittel zum Testen eines Anwendungsprogramms, das so entwickelt wurde, daß es in jeden Prozessor geladen werden kann, unter Verwendung von Onlinedaten, und zum Entscheiden, ob sich die betreffende Onlineumgebung in einem normalen oder einem anormalen Zustand befindet.
- Verschiedene herkömmliche Systeme außer dem verteilten Verarbeitungssystem beinhalten Mittel zum Ansammeln der verarbeiteten Ergebnisdaten von Programmen. Die Funktion der Mittel besteht jedoch lediglich darin, den Logarithmus der Daten in zeitlicher Folge zu bilden, und sie war unzufriedenstellend hinsichtlich einer Analyse eines Teststartergebnisses unter Verwendung der angesammelten Ergebnisse.
- Ferner kann dann, wenn ein Test mit Onlinedaten ausgeführt wurde, ein anderes Untersystem, das das Ergebnis des Tests empfängt, einen Prozeß innerhalb des eigenen Untersystems aufweisen, das vom empfangenen Testergebnis beeinflußt wird. Demgemäß muß darauf geachtet werden, daß der Test mit den Onlinedaten realisiert wird, ohne daß irgend ein anderer Teil beeinflußt wird.
- Auch muß ein Fall berücksichtigt werden, bei dem ein als Ergebnis des Tests als normal aufgefundenes Untersystem direkt in das System eingegliedert und dann betrieben werden soll.
- Es ist eine Aufgabe der Erfindung, ein Testverfahren anzugeben, gemäß dem ein Test ausgeführt werden kann, ohne ein anderes Untersystem zu beeinflussen, selbst wenn Onlinedaten während des Betreibens eines Systems verwendet werden, und bei dem außerdem ein getestetes Untersystem direkt eingeliedert werden kann, falls dies erwünscht ist.
- Die obige Aufgabe der Erfindung wird durch ein verteiltes System mit mehreren Untersystemen gelöst, die an eine gemeinsame Übertragungsleitung angeschlossen sind, bei dem jedes der Untersysteme eine Einrichtung zum Registrieren fehlerhafter Programme innerhalb des entsprechenden Untersystems aufweist, und eine Modusänderungseinrichtung aufweist, so daß ein Programm mit einem Datenverarbeitungsergebnis diagnostiziert wird, das von der Übertragungsleitung empfangen wird, oder mit durch eine beliebige andere Einrichtung empfangenen Daten, wobei es dann, wenn ein Fehler vorliegt, in einer Registriereinrichtung für fehlerhafte Programme registriert wird, und wobei die Modusänderungseinrichtung auf die Registriereinrichtung für fehlerhafte Programme Bezug nimmt und einen Testmodus und einen Onlinemodus entsprechend dem Programm austauscht, das in der Registriereinrichtung registriert oder aus dieser gelöscht ist.
- Im verteilten Verarbeitungssystem, das aus mehreren an ein Netzwerk angeschlossenen Untersystemen besteht, empfängt jedes der Untersysteme Daten über das Netzwerk oder von einer beliebigen anderen Einrichtung und verarbeitet die empfangenen Daten. Bei der Erfindung diagnostiziert das Untersystem, das den Prozess selbst ausgeführt hat, oder ein beliebiges anderes Untersystem, das Ergebnis des Prozesses als normal oder anormal, z.B. durch Überprüfen der Entsprechung der Inhalte von Eingangs- und Ausgangsdaten.
- Unter Verwendung des Diagnoseergebnisses des Untersystems selbst oder desjenigen des anderen Untersystems, können die Modi unabhängig voneinander ausgetauscht werden, um den Onlinemodus für das normale Ergebnis und den Testmodus für das anormale Ergebnis einzustellen. Zusätzlich kann dann, wenn in jedem Untersystem eine im Testmodus Onlinedaten in Testdaten wandelnde Vorrichtung vorhanden ist, das verarbeitete Ergebnis der Onlinedaten als Testdaten im Testmodus ausgegeben werden.
- Aus dem obigen Grund kann das Untersystem selbst mit den Onlinedaten getestet werden, ohne daß während des Betreibens des Systems irgend ein anderes Untersystem beeinflußt wird, und wenn das Untersystem normal ist, kann es direkt in das System eingegliedert werden.
- Ob das Verarbeitungsergebnis normal oder anormal ist, kann durch den Vergleich einer Verarbeitungszeitspanne mit einer vorgegebenen Zeitspanne (Zeitüberschreitung) usw. entschieden werden, neben dem oben genannten Vergleich der Inhalte der Eingangs- und Ausgangsdaten.
- Fig. 1 ist ein Flußdiagramm eines Modusänderungsprozesses, der ein Ausführungsbeispiel der Erfindung ist;
- Fig. 2 ist ein schematisches Blockdiagramm des inneren jedes Untersystems eines verteilten Verarbeitungssystems, das ein Ausführungsbeispiel der Erfindung zeigt;
- Fig. 3 ist ein Diagramm, das die Beziehungen von Eingangs/ Ausgangsdaten bei jeweiligen Moduszuständen im verteilten Verarbeitungssystem als Ausführungsbeispiel der Erfindung zeigt;
- Fig. 4 ist ein Diagramm, das das Datenformat zeigt, mit dem jedes Untersystem Übertragung ins Netzwerk vornimmt;
- Fig. 5 ist ein Diagramm, das ein Beispiel einer Anordnung einer Registriertabelle für fehlerhafte Programme zeigt;
- Fig. 6 ist ein Diagramm, das ein Beispiel des Diagnoseformats eines Verarbeitungsergebnisses zeigt, das von einer Testeinheit geliefert wird;
- Fig. 7 ist ein Anordnungsdiagramm eines anderen Ausführungsbeispiels der Erfindung; und
- Fig. 8 und 9 sind Formatdiagramme der Ausgangsinformation einer Testeinheit und der Ausgangsinformation eines Diagnoseergebnisses in Fig. 7.
- Es werden nun Ausführungsbeispiele der Erfindung im einzelnen unter Bezugnahme auf die Zeichnungen beschrieben.
- Fig. 3 ist ein Diagramm, das die Beziehungen von Eingangs/ Ausgangs-Daten in jeweiligen Moduszuständen in einem verteilten Verarbeitungssystem zeigt, das ein Ausführungsbeispiel der Erfindung ist. In der Figur sind Untersysteme 1, 2, ... und n über ein Netzwerk 21 miteinander verbunden. Die Untersysteme 1, 2, ... und n sind unabhängig voneinander und können sogar alleine arbeiten. Darüber hinaus nimmt jedes der Untersysteme Daten aus im Netzwerk 21 fließenden Daten auf, die für es erforderlich sind, was nach eigener Beurteilung erfolgt, und es führt einen Prozeß aus. Danach überträgt es ein Verarbeitungsergebnis in das Netzwerk 21.
- In Fig. 3 kennzeichnen Bezugszeichen 31 - 36 Daten, die innerhalb des Netzwerks 21 fließen, unter denen die Einzeldaten 31 - 35 Testdaten sind und der Datenwert 36 ein Onlinedatenwert ist.
- Fig. 4 zeigt das Datenformat, mit dem jedes Untersystem in das Netzwerk 21 sendet. Ein Inhaltscode 41 ist ein Code, der die Art des Inhalts der Daten 44 spezifiziert. Eine Untersystemnummer mit dem Bezugszeichen 42 spezifiziert das Untersystem, das die Daten geliefert hat. Ein Testflag 43 ist ein Flag, das spezifiziert, ob die Daten mit dem in Fig. 4 dargestellten Format Testdaten sind oder nicht.
- Fig. 2 ist ein schematisches Blockdiagramm des Inneren jedes der Untersysteme 1, 2, ... und n. Eine Übertragungssteuerungseinheit 51 führt die Übertragungssteuerung der innerhalb des Netzwerks 21 fließenden Daten aus; sie ist in jedem Untersystem vorhanden. Jedes Untersystem ist über die Übertragungssteuerungseinheit 51 mit dem Netzwerk 21 verbunden.
- In jedem Untersystem sind mehrere Programme 54, ... und 55 zum Ausführen beliebiger Prozesse unter Verwendung von aus dem Netzwerk 21 empfangenen Daten mit der Anzahl von Funktionen vorhanden, die für das entsprechende Untersystem erforderlich sind. Daneben sind die Inhaltscodes 41 (siehe Fig. 4) der für diese Programme erforderlichen Daten in einer Inhaltscodetabelle 53 registriert.
- Wenn der Inhaltscode 41 der im Netzwerk 21 fließenden Daten ein solcher ist, der in der Inhaltscodetabelle 53 vorhanden ist, nimmt ein Prozessor 52 die Daten mit dem in der Tabelle 53 registrierten Inhaltscode in das Untersystem auf und liefert die aufgenommenen Daten an eine Prüfeinheit 56.
- Danach liefert der Prozessor 52 die Daten mit dem durch die Inhaltsdaten 41 angezeigten Inhalt an das Programm, das sie benötigt. Hierbei testet die Prüfeinheit 56 das Programm, wenn das Testflag 43 auf den Flagwert "1" gesetzt ist, was Testdaten spezifiziert. Darüber hinaus führt das Programm, z.B. 54, das die Daten empfangen hat, einen Prozeß aus, nach dessen Ende ein Verarbeitungsergebnis an den Prozessor 52 zurückgeliefert wird, zusammen mit dem Inhaltscode des Prozesses, der durch das Programm 54 ausgeführt wurde. Nachdem der Prozessor 52 das Verarbeitungsergebnis des Programms 54 erhalten hat, liefert er es an die Prüfeinheit 56.
- In der Prüfeinheit 56 sind vorab Eingangs/Ausgangs-Beziehungen interner Codes registriert, wie oben angegeben, z.B. die Tatsache, daß, was einen Inhaltscode A betrifft, das durch den Code A spezifizierte Datenverarbeitungsergebnis auf jeden Fall einen Inhaltscode B begleitet.
- Nach Überprüfung der Eingangs/Ausgangs-Beziehungen der Inhaltscodes entscheidet die Prüfeinheit 56, ob der Prozeß im Programm anormal ist oder nicht, und das Entscheidungsergebnis wird an den Prozessor 52 geliefert. Genauer gesagt, nehmen alle Programme die Daten mit vorgegebenen Inhalten an und führen vorbestimmte Prozesse hinsichtlich des Inhalts der aufgenommenen Daten aus, woraufhin sie Verarbeitungsergebnisse ausgeben, denen vorgegebene Inhaltscodes beigefügt sind. Anormalität oder Fehlerhaftigkeit kann daher durch Überprüfung z.B. der Inhaltscodes für die Eingabe und die Ausgabe aufgefunden werden. Dasselbe gilt für einen Fall, bei dem mehrere Inhaltscodes betroffen sind.
- Wenn die Testeinheit 56 das Verarbeitungsergebnis jedes Programms diagnostiziert hat, gibt sie ein Diagnoseergebnis in einem Format aus, wie es in Fig. 6 dargestellt ist. Hierbei ist ein Programmstatuscode 71 ein Code, der anzeigt, ob das diagnostizierte Programm normal oder anormal ist. Beispielsweise ist er "0" für Normalität und "1" für Anormalität.
- Programminformation 72 ist Information für das durch die Prüfeinheit 56 diagnostizierte Programm, und es wird Information aufgezeichnet, aus der das diagnostizierte Programm ersichtlich ist, wie die Kennzeichnungsnummer des Programms innerhalb des Untersystems. Wenn z.B. die Nummer "1" dem Programm 54 innerhalb des Untersystems 1 zugeordnet ist, zeichnet die Prüfeinheit 56, die das Verarbeitungssergebnis vom Programm 54 diagnostiziert hat, "1" als Programminformation 72 auf und liefert das Diagnoseergebnis mit dem Format von Fig. 6.
- Die Information darüber, ob das Programm gemäß dem Diagnoseergebnis von der Prüfeinheit 56 als anormal oder fehlerhaft diagnostiziert wurde, wird in eine Tabelle 57 für fehlerhafte Programme durch eine Modusänderungseinheit 58 mit dem in Fig. 5 dargestellten Format eingeschrieben.
- Programmeinzelinformationen 62, ... und 63 sind Codes, die fehlerhafte Programme innerhalb des Untersystems spezifizieren, und es werden Einzelinformationen aufgezeichnet, die ähnlich der Programminformation 72 sind, die zuvor in Verbindung mit Fig. 6 aufgeklärt wurde. Diese Teile werden durch die Modusänderungseinheit 58 auf Grundlage der Information der Prüfeinheit 56 aufgezeichnet.
- Wenn im Fall einer Modusänderung des Untersystems auch nur ein Programm in die Tabelle 57 für fehlerhafte Programme eingeschrieben ist, hält die Modusänderungseinheit 58 das Untersystem im Testmodus. Daneben hält, wenn die Modi des Programms verändert werden, die Modusänderungseinheit 58 das in die Tabelle 57 für fehlerhafte Programme eingeschriebenen Programm im Testmodus.
- Die Modusänderungseinheit 58 setzt z.B. das Testflag 43 für die vom Untersystem oder vom Programm im Testmodus gelieferten Daten auf "1", was Testdaten anzeigt, wodurch die an eine Übertragungsleitung zu liefernden Daten in Testdaten umgewandelt werden.
- Nachfolgend werden Einzelheiten des Betriebs der Erfindung unter Bezugnahme auf Fig. 3 beschrieben.
- Jedes Untersystem erkennt den Inhaltscode 41 der im Netzwerk 21 fließenden Daten und beurteilt, ob es diese Daten benötigt oder nicht, und es nimint die Daten erforderlichenfalls auf. Wenn ein testdatenanzeigendes Flag, z.B. mit dem Wert "1", wie oben angegeben, als Testflag für die aufgenommenen Daten gesetzt ist, bestimmt das Untersystem, das die Daten aufgenommen hat, nach eigener Beurteilung, ob ein Test ausgeführt wird oder nicht.
- Es sei nun angenommen, daß, wie dies in Fig. 3 dargestellt ist, die Untersysteme 1 und n im Testmodus sind, während die Untersysteme 2 und 3 im Onlinemodus sind; die anderen Untersysteme sollen derzeit nicht berücksichtigt werden. Auch soll für den aktuellen Zeitpunkt keine Modusänderung jedes der einzelnen Programme berücksichtigt werden. Durch Fig. 1 wird der Betrieb der Modusänderungseinheit 58 veranschaulicht.
- Es wird angenommen, daß das im Testmodusstatus befindliche Untersystem 1 zwei fehlerhafte Programme 54 und 55 aufweist. D.h., daß "54" und "55" jeweils in die Spalten von Programminformation 62 und 63 der Tabelle 57 für fehlerhafte Programme eingeschrieben sind.
- Es sei auch angenommen, daß der Inhaltscode 41 der Testdaten 31 einen Inhalt von Daten anzeigt, die das Programm 54 aufnehmen sollte, und daß der Inhaltscode 41 der Onlinedaten 36 einen Inhalt von Daten anzeigt, die das Programm 55 aufnehmen sollte.
- Nachdem das Programm 54 die Testdaten 31 aufgenommen hat, führt es einen Prozeß auf, und daher gibt es ein Verarbeitungsergebnis mit angehängtem Inhaltscode aus. Die Prüfeinheit 56 empfängt und diagnostiziert das Verarbeitungsergebnis. Es sei nun angenommen, daß das Programm 54 sich zum normalen Zustand erholt hat und ein normales Verarbeitungsergebnis liefert.
- Nachdem die Prüfeinheit 56 das Verarbeitungsergebnis vom Programm 54 empfangen hat, diagnostiziert sie z.B. auf Grundlage der vorstehend genannten Beziehung der Eingangs/ Ausgangs-Inhaltscodes, ob das Ergebnis normal oder anormal ist. Da das Programm 54 sich zum normalen Zustand erholt hat, beurteilt die Prüfeinheit 56 das Verarbeitungsergebnis vom Programm 54 als normal oder fehlerfrei.
- Anschließend nimmt die Prüfeinheit 56 auf die Tabelle 57 für fehlerhafte Programme Bezug und untersucht, ob das Programm 54 als fehlerhaftes eingeschrieben ist. Da das Programm 54 bis zum letzten Prozeß anormal arbeitete, findet die Prüfeinheit 56 heraus, daß das Programm 54 in die Tabelle 57 für fehlerhafte Programme eingeschrieben ist. Die Prüfeinheit 56 erkennt die Erholung des Programms 54 zum normalen Zustand auf Grundlage der Tatsache, daß das Verarbeitungsergebnis vom Programm 54 fehlerfrei ist, und daß das Programm 54 bis zum letzten Prozeß anormal war.
- Die Prüfeinheit 56 gibt die Information, daß sich das Programm 54 erholt hat dadurch aus, daß sie z.B. "2" in die Programmstatus-Codespalte 71 einschreibt, was die Erholung anzeigt, und "54" in die Programminformationsspalte 72 im Format von Fig. 6 einschreibt.
- Wenn die Modusänderungseinheit 58 die obige Information empfängt, daß sich das Programm 54 erholt hat, wird der Prozeß der Modusänderung durch das in Fig. 1 dargestellte Flußdiagramm ausgeführt.
- Genauer gesagt, ist die Information, die die Modusänderungseinheit 58 empfangen hat, die Information, daß sich das Programm 54 erholt hat (Schritt 13), so daß die Registrierung des Programms 54 in der Tabelle 57 für fehlerhafte Programme gelöscht wird (Schritt 14).
- Da das Programm 55 in der Tabelle 57 für fehlerhafte Programme aufgezeichnet ist, hält die Modusänderungseinheit 58 das Untersystem 1 noch im Testmodus, ohne die Modi zu ändern (Schritte 15, 16).
- Da das Untersystem 1 im Testmodus intakt blieb, erhält der von diesem Untersystem 1 zu liefernde Datenwert 32 "1" als Untersystem Nr. 42 aufgezeichnet, und "1" als Testflag 43 aufgezeichnet. Dadurch ist klar gekennzeichnet, daß der Datenwert 32 ein vom Untersystem 1 gelieferter Testdatenwert ist.
- Nachfolgend sei angenommen, daß Onlinedaten 36 vom Untersystem 1 aufgenommen wurden.
- Es sei angenommen, daß das Programm 55 des Untersystems 1, das die Onlinedaten 36 aufgenommen hat, fehlerbehaftet bleibt. Die Prüfeinheit 56, die das Verarbeitungsergebnis vom Programm 55 empfangen hat, diagnostiziert dieses Programm als fehlerhaft. Anschließend nimmt sie auf die Tabelle 57 für fehlerhafte Programme Bezug und überprüft, ob das Programm bereits als fehlerhaft registriert wurde. Da das Programm 55 in der Tabelle 57 für fehlerhafte Programme als fehlerhaft registriert ist, erkennt die Prüfeinheit 56 den Fehler des Programms 55 als existierenden Fehler, und sie gibt die Information aus, daß der Fehler des Programms 55 existiert, und zwar dadurch, daß sie z.B. "3" in die Programmstatus-Codespalte 71 und "55" in die Programminformationsspalte 72 gemäß dem Format von Fig. 6 einschreibt.
- Nachdem die Modusänderungseinheit 58 die Information hinsichtlich der Wirkung erhalten hat, daß das Programm 55 einen existierenden Fehler aufweist, führt sie einen Änderungsprozeß gemäß dem vorstehend genannten Verarbeitungsfluß von Fig. 1 aus. Genauer gesagt, schreibt die Modusänderungseinheit 58, auf Grundlage der Information, daß das Programm 55 einen existierenden Fehler aufweist, dieses Programm nicht erneut in die Tabelle für fehlerhafte Programme ein (Schritte 11, 13, 15), und sie beläßt das Untersystem 1 weiterhin im Testmodus (Schritt 16).
- Demgemäß wird "1" als Untersystem Nr. 42 der Daten 34 aufgezeichnet, und "1" als Testflag 43.
- Nachfolgend sei ein Fall angenommen, bei dem das Programm 55 innerhalb des Untersystems 1 sich zum normalen Zustand erholt hat.
- Nachdem das Untersystem 1 die Onlinedaten 36 empfangen hat, wird in ihm derselbe Prozeß wie im Fall des fehlerhaften Programms 55 ausgeführt. D.h., daß die Testeinheit 56 das Verarbeitungsergebnis des Programms 55 diagnostiziert und entscheidet, ob das Programm 55 normal ist, sich erholt hat, einen existierenden Fehler aufweist oder einen neuen Fehler aufweist, was auf Grundlage des Ergebnisses der Diagnose und des Ergebnisses einer Abfrage der Tabelle 57 für fehlerhafte Programme erfolgt.
- Hierbei ist das Programm 55 vom anormalen Zustand in den normalen Zustand zurückgekehrt. Daher entscheidet die Testeinheit 56, daß sich das Programm 55 erholt hat, und sie gibt die Information betreffend die Erholung im Format von Fig. 6 aus.
- Nachdem die Modusänderungseinheit 58 die Erholungsinformation erhalten hat, löscht sie die Information betreffend das Programm 55 aus der Tabelle 57 für fehlerhafte Programme (Schritt 13, 14)
- Wenn nun angenommen wird, daß sich auch das Programm 54 wie oben beschrieben bereits erholt hat, ist nun kein Programm mehr in die Tabelle 57 für fehlerhafte Programme eingeschrieben. Daher führt die Modusänderungseinheit 58 den Wechsel in den Onlinemodus aus (Schritte 15, 17).
- So wird zu diesem Zeitpunkt das Testflag 43 des Verarbeitungsergebnisses 34 der Onlinedaten 36 auf "0" gesetzt und als Onlinedaten ausgegeben. Daher wird auch das Verarbeitungsgergebnis 35 des Untersystems 3, das die Daten 34 empfangen hat, als Onlinedaten ausgegeben.
- Nachfolgend sei angenommen, daß das Programm 54 innerhalb des Untersystems 2 im Onlinemodusstatus fehlerhaft wurde.
- Es sei nun angenommen, daß Daten 32 Onlinedaten sind und daß ein Programm, das einen Prozeß unter Verwendung der Daten 32 ausführen soll, das Programm 54 des Untersystems 2 ist.
- Das Programm 54 empfängt die Daten 32 und führt den Prozeß aus, dessen Ergebnis durch die Prüfeinheit 56 diagnostiziert wird. Hierbei ist das Programm 54 fehlerhaft, so daß die Prüfeinheit 56 entscheidet, daß das Verarbeitungsergebnis des Programms 54 fehlerhaft ist.
- Anschließend nimmt die Prüfeinheit 56 auf die Tabelle 57 für fehlerhafte Programme Bezug. Dabei war das Untersystem 2 bis zum letzten Prozeß im Onlinemodus, so daß das Programm nun in die Tabelle 57 für fehlerhafte Programme eingeschrieben wird.
- Da die Tabelle 57 für fehlerhafte Programme keinen Eintrag enthält, diagnostiziert die Prüfeinheit 56 den Fehler des Programms 54 als neuen Fehler und gibt das Ergebnis der Diagnose dadurch aus, daß es z.B. "4" in die Programmstatus- Codespalte 71 und "54" in die Programminformationsspalte 72 gemäß dem Format von Fig. 6 einschreibt.
- Nachdem die Modusänderungseinheit 58 diese Ausgangsinformation von der Prüfeinheit 56 erhalten hat, führt sie einen Prozeß gemäß dem in Fig. 1 dargestellten Flußdiagramm aus. D.h., daß sie entscheidet, daß das Programm einen neuen Fehler aufweist (Schritt 11) und das fehlerhafte Programm 54 in die Tabelle 57 für fehlerhafte Programme einschreibt (Schritt 12).
- Da das fehlerhafte Programm in der Tabelle 57 für fehlerhafte Programme registriert ist (Schritt 15) führt die Modusänderungseinheit 58 den Wechsel in den Testmodus aus (Schritt 16)
- Da das Untersystem 2 in den Testmodus geändert wurde, wird das Testflag 43 des Verarbeitungsergebnisses 33 der Daten 32 auf "1" gesetzt, was Testdaten anzeigt.
- Von da an ändert, aufgrund eines ähnlichen Prozesses, jedes Untersystem den Onlinemodus und den Testmodus abhängig von seiner eigenen Beurteilung jedesmal dann, wenn Testdaten oder Onlinedaten ankommen.
- Nun wird die Modusänderung für den Fall beschrieben, daß das vorliegende System während seines Betriebs erweitert wird, z.B. durch Hinzufügen eines neuen Untersystems.
- Wenn das System während seines Betriebs durch Hinzufügen eines neuen Untersystems oder durch Hinzufügen neuer Programme zu beliebigen vorhandenen Untersystemen erweitert wurde, werden die erweiterten Abschnitte als fehlerhafte Programme angesehen und alle werden in die oben genannte Tabelle 57 für fehlerhafte Programme eingeschrieben.
- Anschließend werden unter Verwendung von Testdaten und Onlinedaten Tests auf dieselbe Weise wie beim vorigen Ausführungsbeispiel ausgeführt. Wenn alle Programme fehlerlos wurden, wird das System in den Onlinemodus umgestellt und die erweiterten Abschnitte können im Onlinestatus betrieben werden.
- Bei den obigen Ausführungsbeispielen wurde ein Verfahren beschrieben, das ein Untersystem selbst zwischen dem Testmodus und dem Onlinemodus wechselt. Die Modusänderung eines einzelnen Programms kann durch ein Verfahren bewirkt werden, das dem Verfahren für ein Untersystem ähnlich ist.
- Einfache Beispiele hierfür werden unten stehend beschrieben.
- Nun sei nur eine Modusänderung des Programms 54 betrachtet. Es sei angenommen, daß das Programm 54 neu in das Untersystem eingeschrieben wurde.
- Bei dieser Gelegenheit wird die Information zum Programm 54 auf dieselbe Weise wie im vorigen in die Tabelle 57 für fehlerhafte Programme eingeschrieben.
- Es sei angenommen, daß das Programm 54 mit Onlinedaten gestartet wurde und daß das Verarbeitungsergebnis desselben von der Prüfeinheit 56 diagnostiziert wurde. Dabei wird angenommen, daß die Prüfeinheit 56 das Verarbeitungsergebnis des Programms 54 als fehlerhaft diagnostiziert hat. Das Diagnoseverfahren, die Diagnoseverarbeitung der Prüfeinheit 56, wie die Ausgabe des Diagnoseergebnisses, und der Prozeß der Modusänderungseinheit 58 können mit denselben Verfahren realisiert werden wie bei den vorigen Ausführungsbeispielen.
- Nachdem nun das Verarbeitungsergebnis des Programms 54 durch die Testeinheit 56 als fehlerhaft beurteilt wurde, bleibt die Information zum Programm 54 in die Tabelle 57 für fehlerhafte Programme eingeschrieben. Was das Verarbeitungsergebnis des in die Tabelle 57 für fehlerhafte Programme eingeschriebenen Programms 54 betrifft, setzt die Modusänderungseinheit 58 das Testflag 43 auf den Wert "1", was Testdaten anzeigt.
- So stellt die Modusänderungseinheit 58 das Testflag 43 beim Ausgeben des diagnostizierten Verarbeitungsergebnisses an das Netzwerk 21 auf "1", was Testdaten anzeigt, bis das Verarbeitungsergebnis des Programms 54 von der Testeinheit 56 als fehlerfrei oder erholt diagnostiziert wird.
- Beim vorliegenden Ausführungsbeispiel bleibt das Programm 54 in die Tabelle 57 für fehlerhafte Programme eingeschrieben und wird daher durch die Modusänderungseinheit 58 in den Testmodus gesetzt.
- Anschließend wird das Programm 54 als einem Erholungsprozeß, wie einem Neuladen, unterzogen angenommen. Es sei angenommen, daß sich das Programm 54 durch den Erholungsprozeß vom fehlerhaften Zustand in den fehlerfreien Zustand gewandelt hat.
- Nun wird das Programm 54 mit Onlinedaten gestartet, die Testeinheit 56 beurteilt das Programm 54, da es fehlerfrei wurde, als erholt, und sie gibt das Ergebnis der Diagnose aus. Nachdem die Modusänderungseinheit 58 das Diagnoseergebnis empfangen hat, löscht sie den Eintrag des Programms 54 aus der Tabelle 57 für fehlerhafte Programme und versetzt dieses Programm 54 in den Onlinemodus. D.h., daß das Testflag 43 dieses Mal auf "0" gesetzt wird und das Verarbeitungsergebnis des Programms 54 als Onlinedatenwert ausgegeben wird.
- Auf diese Weise kann die Modusänderung in einer einzelnen Programmeinheit mit demselben Verfahren ausgeführt werden wie die Modusänderung für jedes Untersystem.
- Ferner kann das Programm oder das Untersystem selbst dann, wenn die Anzahl aufeinanderfolgender Abläufe, in denen jedes Programm als fehlerhaft angesehen wird, in der Modusänderungseinheit 58 registriert wird, für die registrierte Anzahl von Malen im Testmodus gehalten werden. Wenn z.B. die Modusänderungseinheit 58 so eingestellt ist, daß sie jedes Programm als fehlerfrei ansieht, wenn das Programm fünf Mal in Folge gearbeitet hat, und dann die Modi ändert, wird das Untersystem im Testmodus gehalten, solange nicht alle Programme im Untersystem fünf Mal normal arbeiten. Wenn andererseits die Modi der einzelnen Programme erst verändert werden, wenn jedes einzelne Programm fünf Mal normal gearbeitet hat, wird ein Programm, das noch nicht fünf Mal gearbeitet hat, weiter im Testmodus belassen.
- Obwohl die vorstehenden Ausführungsbeispiele von der Prüfeinheit 56 innerhalb des entsprechenden Untersystems diagnostiziert wurde, können die Modi ferner auf Grundlage des Diagnoseergebnisses eines anderen Untersystems geändert werden.
- Ein einfaches Ausführungsbeispiel hierfür wird unten stehend unter Bezugnahme auf Fig. 7 beschrieben.
- Es wird nun wie beim Vorstehenden nur die Modusänderung des Programms 54 in Betracht gezogen. Es sei angenommen, daß die Diagnosefunktion des Verarbeitungsergebnisses der jeweiligen Programme, d.h. ein externer Tester 80, innerhalb der Untersysteme 2 vorhandenist. Ferner sind der Kürze halber die Prüfeinheit 56 und die Modusänderung 58 in Fig. 7 gemeinsam dargestellt.
- Wenn das Programm 54 neu im Untersystem 1 eingestellt wird, wird die Information zu diesem Programm auf dieselbe Weise wie beim vorigen in die Tabelle 57 für fehlerhafte Programme eingeschrieben.
- Es sei angenommen, daß das Programm 54 für einen Test mit Onlinedaten oder Testdaten gestartet wurde (36 in Fig. 7) und daß die Prüfeinheit 56 das Verarbeitungsergebnis für den Test empfangen hat. Bei dieser Gelegenheit gibt die Prüfeinheit die Testergebnisdaten 37 aus, wie in Fig. 8 dargestellt. Programminformation 44 ist die Information zum Programm, das zum Testen gestartet wurde. Eingabedateninformation 45 kennzeichnet die Daten, die für den Start verwendet wurden. Ausgangsdaten 46 sind das Verarbeitungsergebnis nach dem Teststart.
- Der externe Tester 80, der innerhalb des Untersystems 2 die Diagnosefunktion aufweist, und der dieses Ergebnis empfangen hat, diagnostiziert es auf Grundlage der Eingangsdateninformation 45, der Ausgangsdaten 46 und der Programminformation 44, und er liefert Diagnoseergebnisdaten 38 mit dem in Fig. 9 dargestellten Format.
- Programminformation 44 ist Information, die das diagnostizierte Programm spezifiziert. Ob das diagnostizierte Programm fehlerfrei ist oder nicht, wird in einem Diagnoseergebnis 47 aufgezeichnet.
- Die Prüfeinheit 56 innerhalb des Untersystems 1, die das Diagnoseergebnis 38 empfangen hat, erkennt das Programm, das das Diagnoseergebnis erzielt hat aufgrund der Programminformation 44. Im Fall des vorliegenden Ausführungsbeispiels wird erkannt, daß das Diagnoseergebnis dasjenige des Programms 54 ist. Anschließend gibt die Prüfeinheit 56 unter Verwendung des Diagnoseergebnisses 47 und durch ziemlich denselben Prozeß wie beim Vorstehenden ein Diagnoseergebnis mit dem Format von Fig. 6 aus. Von da an werden die Modi durch ziemlich denselben Prozeß verändert, wie bei den vorigen Ausführungsbeispielen.
- Beim vorliegenden Ausführungsbeispiel wurde die Modusänderung vom Testmodus in den Onlinemodus als ein Beispiel genannt. Jedoch können die Modi umgekehrt auf ziemlich dieselbe Weise wie beim vorigen Ausführungsbeispiel geändert werden, wenn die Prüfeinheit 56 ein Verarbeitungsergebnis auf Grundlage von Online- oder Testdaten mit dem Format von Fig. 8 ausgibt.
- Auch die Modusänderung jedes Untersystems kann auf ziemlich dieselbe Weise ausgeführt werden wie beim obigen Ausführungsbeispiel.
- Nun wurden die Ausführungsbeispiele der Erfindung als solche Beispiele dargestellt, die Testdaten von der Übertragungsleitung empfangen. Die Testdaten können jedoch auch von einem anderen Hilfsmittel empfangen werden, z.B. durch eine Maßnahme, gemäß der jedes Untersystem mit einer testdatenspeichernden Datei versehen ist. Selbst mit solchen Daten können die Modi ziemlich ähnlich geändert werden.
- Im Testmodus ist es nicht immer erforderlich, Testdaten an die Übertragungsleitung zu liefern.
- In der Testeinheit 56 können die Modusänderungseinheit 58 und der externe Tester 80 gut aus getrennten Prozessoren wie Mikrocomputern gebildet sein, die so ausgebildet sind, daß sie die oben angegebenen Funktionen realisieren. Es ist auch möglich, die Prozessoren zum Prozessor 52 zu vereinigen, in dem alle Funktionen realisiert sind, ohne daß die einzelnen Prozessoren eingerichtet werden.
- Wie oben festgestellt, kann gemäß den Ausführungsbeispielen in dem aus den über das Netzwerk miteinander verbundenen Untersystemen bestehenden verteilten System jedes Untersystem den Testmodus und den Onlinemodus abhängig von eigener Beurteilung auswechseln. Durch den Wechsel wird das Ergebnis des Tests, selbst wenn er mit Onlinedaten ausgeführt wird, ganz in Form von Testdaten geliefert, solange sich das Untersystem im Testmodus befindet, so daß kein Einfluß auf ein anderes Untersystem ausgeübt wird. Darüber hinaus kann, wenn ein erweiterter Abschnitt z.B. zum Zeitpunkt der Erweiterung des Systems im Testmodus gehalten werden, dieser im Betriebszustand des Systems getestet werden, ohne daß er irgendeinen Einfluß auf die anderen Untersysteme ausübt.
- Wie oben beschrieben ist gemäß der Erfindung bei einem System mit mehreren an eine gemeinsame Übertragungsleitung angeschlossenen Untersystemen jedes Untersystem darin mit einer Registriereinrichtung für fehlerhafte Programme und einer Modusänderungseinrichtung versehen, so daß ein Programm auf Grundlage des Verarbeitungsergebnisses von Daten diagnostiziert wird, die von der Übertragungsleitung empfangen wurden, oder von Daten, die durch eine andere Einrichtung empfangen wurden, und es wird in die Registriereinrichtung für fehlerhafte Programme eingeschrieben, wenn es fehlerhaft ist, und die Modusänderungseinrichtung ändert einen Testmodus und einen Onlinemodus durch Bezugnahme auf die Registriereinrichtung für fehlerhafte Programme und abhängig von Programmen, die in die Registriereinrichtung eingeschrieben oder aus dieser gelöscht sind. Daher erzielt die Erfindung den bemerkenswerten Effekt, daß ein Test während des Betriebs des Systems sogar mit Onlinedaten ausgeführt werden kann, ohne daß andere Untersysteme beeinflußt werden, und daß der direkte Einschluß eines Programms usw. in ein Untersystem zugelassen ist, wie erwünscht.
Claims (10)
1. Prüfverfahren für ein verteiltes System, bei dem mehrere
Untersysteme (1, 2,...n) zur Ausführung jeweiliger Funktionen
über ein Übertragungsmedium (21) miteinander verbunden sind,
dadurch gekennzeichnet, daß jedes Untersystem folgende
Schritte auszuführen vermag:
Verarbeiten (52) der entsprechenden Funktion jedes
besagten Untersystems (1, 2,...n) unter Verwendung von von dem
Übertragungsmedium (21) empfangenen Daten und/oder von Daten
des Untersystems selbst,
Diagnostizieren (56) der Funktion aufgrund eines
Verarbeitungsergebnisses,
Registrieren von Information der besagten Funktion in
einer Registriereinrichtung (57) in jedem besagten
Untersystem, falls die Funktion als fehlerhaft festgestellt wird,
und
Versetzen (58) des betroffenen Untersystems und/oder der
betreffenden Funktion in entweder einen Prüfmodus oder einen
On-line-Modus in Abhängigkeit davon, ob die verarbeitete
Funktion in der Registriereinrichtung (57) registriert war
oder nicht.
2. Verfahren nach Anspruch 1, wobei die über das
Übertragungsmedium übertragenen Daten einen Abschnitt (43) zum
Spezifizieren von Prüfdaten und einen einen Inhalt dieser Daten
angebenden Inhaltscode (41) umfassen.
3. Verfahren nach Anspruch 1 oder 2, ferner umfassend den
Schritt, in dem Daten des besagten Untersystems (1, 2,..
selbst, das die als fehlerhaft diagnostizierte Funktion
aufweist, und/oder Daten des verarbeiteten Ergebnisses der als
fehlerhaft diagnostizierten Funktion als Prüfdaten an das
ertragungsmedium (21) gesendet werden, wenn sich das
besagte Untersystem im Prüfmodus befindet.
4. Verfahren nach Anspruch 2, wobei der
Diagnostizierschritt den Schritt umfaßt, in dem die Funktion aufgrund
einer Beziehung zwischen dein Inhaltscode (41) der entsprechend
der Funktion zu verarbeitenden Daten und dem Inhaltscode der
Daten des verarbeiteten Ergebnisses diagnostiziert wird.
5. Verfahren nach einem der Ansprüche 1 bis 4, ferner
umfassend den Schritt, in dem die fehlerhafte Funktion jedes
besagten Untersystems in der Registriereinrichtung (57)
aufgrund eines Diagnoseergebnisses in einem anderen Untersystem
registriert wird.
6. Prüfgerät für ein verteiltes System, bei den mehrere
Untersysteme (1, 2...n) zur Ausführung jeweiliger Funktionen
über ein Übertragungsmedium (21) miteinander verbunden sind,
wobei jedes Untersystem (1, 2,...n) gekennzeichnet ist durch
eine Einrichtung (52) zum Verarbeiten der entsprechenden
Funktion unter Verwendung von von dem Übertragungsmedium (21)
empfangenen Daten und/oder von Daten innerhalb des
Untersystems selbst,
eine Einrichtung (56) zum Diagnostizieren der Funktion
aufgrund eines Verarbeitungsergebnisses,
eine Einrichtung (57) zum Registrieren von Information
der Funktion, falls diese als fehlerhaft festgestellt wird,
und
eine Einrichtung (58), die das betroffene Untersystem
und/oder die betreffende Funktion entweder in einen Prüfmodus
oder in einen On-line-Modus in Abhängigkeit davon versetzt,
ob die verarbeitete Funktion in der Registriereinrichtung
(57) registriert war oder nicht.
7. Gerät nach Anspruch 6, wobei die über das
Übertragungsmedium (21) übertragenen Daten einen Abschnitt (43) zum
Spezifizieren von Prüfdaten und einen einen Inhalt dieser Daten
angebenden Inhaltscode (41) umfassen.
8. Gerät nach Anspruch 6 oder 7, wobei jedes besagte
Untersystem (1, 2,...n) ferner eine Einrichtung umfaßt, die Daten
des Untersystems selbst, das die als fehlerhaft
diagnostizierte Funktion aufweist, und/oder Daten des verarbeiteten
Ergebnisses der als fehlerhaft diagnostizierten Funktion als
Prüfdaten an das Übertragungsmedium (21) sendet, wenn sich
das besagte Untersystem im Prüfmodus befindet.
9. Gerät nach Anspruch 7, wobei die Diagnoseeinrichtung
(56) eine Einrichtung umfaßt, die die Funktion aufgrund einer
Beziehung zwischen dem Inhaltscode der entsprechend der
Funktion zu verarbeitenden Daten und dem Inhaltscode der Daten
des verarbeiteten Ergebnisses diagnostiziert.
10. Gerät nach einem der Ansprüche 6 bis 9, wobei jedes
besagte Untersystem (1, 2,...n) ferner eine Einrichtung (57)
umfaßt, die die fehlerhafte Funktion aufgrund eines
Diagnoseergebnisses in einem weiteren Untersystem in der
Registriereinrichtung registriert.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP61191842A JPH0827738B2 (ja) | 1986-08-15 | 1986-08-15 | オンラインテスト方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
DE3786381D1 DE3786381D1 (de) | 1993-08-05 |
DE3786381T2 true DE3786381T2 (de) | 1993-10-14 |
Family
ID=16281422
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE87110477T Expired - Fee Related DE3786381T2 (de) | 1986-08-15 | 1987-07-20 | Prüfverfahren und -gerät für ein verteiltes Verarbeitungssystem. |
DE3751949T Expired - Fee Related DE3751949T2 (de) | 1986-08-15 | 1987-07-20 | Verfahren zum Starten eines Untersystems in einem verteilten Verarbeitungssystem |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE3751949T Expired - Fee Related DE3751949T2 (de) | 1986-08-15 | 1987-07-20 | Verfahren zum Starten eines Untersystems in einem verteilten Verarbeitungssystem |
Country Status (4)
Country | Link |
---|---|
US (1) | US4953096A (de) |
EP (2) | EP0530863B1 (de) |
JP (1) | JPH0827738B2 (de) |
DE (2) | DE3786381T2 (de) |
Families Citing this family (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS5980827A (ja) * | 1982-10-27 | 1984-05-10 | Junji Ogawa | 油圧式シヨベルの伸縮ア−ム |
JP2624676B2 (ja) * | 1987-04-24 | 1997-06-25 | 株式会社日立製作所 | プログラム世代管理方法 |
IN170793B (de) * | 1987-12-18 | 1992-05-23 | Hitachi Ltd | |
JPH0259937A (ja) * | 1988-08-26 | 1990-02-28 | Hitachi Maxell Ltd | Icカード |
JPH02269229A (ja) * | 1989-04-10 | 1990-11-02 | Koberuko Kenki Eng Kk | 多段伸縮アーム |
US5119493A (en) * | 1990-02-23 | 1992-06-02 | International Business Machines Corporation | System for recording at least one selected activity from a selected resource object within a distributed data processing system |
JP2501140Y2 (ja) * | 1990-09-21 | 1996-06-12 | ミサワホーム株式会社 | 曲がり折れ梁による母屋の支持構造 |
GB2270399B (en) * | 1992-09-05 | 1996-01-03 | Marconi Gec Ltd | Method of operating a distributed processor arrangement |
JPH06188909A (ja) * | 1992-12-18 | 1994-07-08 | Fujitsu Ltd | 異常パケット処理方式 |
US5371883A (en) * | 1993-03-26 | 1994-12-06 | International Business Machines Corporation | Method of testing programs in a distributed environment |
GB2276738A (en) * | 1993-03-30 | 1994-10-05 | Ibm | Generation of random conversation testcases. |
JP3552258B2 (ja) * | 1993-12-27 | 2004-08-11 | 株式会社日立製作所 | 分散計算機システム及びその情報管理方法 |
JP3212228B2 (ja) * | 1994-10-17 | 2001-09-25 | 富士通株式会社 | 試験プログラム作成装置における試験プログラム自動作成方法 |
JP3367305B2 (ja) * | 1995-11-14 | 2003-01-14 | 三菱電機株式会社 | ネットワークシステム |
US5933639A (en) * | 1996-05-17 | 1999-08-03 | International Business Machines Corporation | System and method for debugging distributed programs |
US6266709B1 (en) * | 1996-07-01 | 2001-07-24 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server failure reporting process |
US5881219A (en) * | 1996-12-26 | 1999-03-09 | International Business Machines Corporation | Random reliability engine for testing distributed environments |
DE19827431C2 (de) * | 1997-07-22 | 2000-12-07 | Siemens Ag | Verfahren zur Fehlererkennung in einem Prozessorsystem |
US6591417B1 (en) | 1999-12-30 | 2003-07-08 | International Business Machines Corporation | Method of and system for testing compatibility with an external API upgrade |
US20030131088A1 (en) * | 2002-01-10 | 2003-07-10 | Ibm Corporation | Method and system for automatic selection of a test system in a network environment |
JP4467505B2 (ja) * | 2005-11-21 | 2010-05-26 | 株式会社日立情報システムズ | ファイル管理制御システムと方法およびプログラム |
US20080320071A1 (en) * | 2007-06-21 | 2008-12-25 | International Business Machines Corporation | Method, apparatus and program product for creating a test framework for testing operating system components in a cluster system |
CN106886488A (zh) * | 2015-12-16 | 2017-06-23 | 阿里巴巴集团控股有限公司 | 异常处理方法及装置 |
Family Cites Families (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3551659A (en) * | 1969-05-05 | 1970-12-29 | Charles O Forsythe | Method for debugging computer programs |
US4204251A (en) * | 1977-12-28 | 1980-05-20 | Finn Brudevold | Interconnection unit for multiple data processing systems |
JPS5533320A (en) * | 1978-08-30 | 1980-03-08 | Hitachi Ltd | Reception host diagnosis system for network |
JPS5694427A (en) * | 1979-12-28 | 1981-07-30 | Fujitsu Ltd | Diagnostic system of data processing system |
US4306288A (en) * | 1980-01-28 | 1981-12-15 | Nippon Electric Co., Ltd. | Data processing system with a plurality of processors |
US4323966A (en) * | 1980-02-05 | 1982-04-06 | The Bendix Corporation | Operations controller for a fault-tolerant multiple computer system |
US4412281A (en) * | 1980-07-11 | 1983-10-25 | Raytheon Company | Distributed signal processing system |
US4489379A (en) * | 1982-01-25 | 1984-12-18 | International Business Machines Corporation | Distributed data processing in ring-structured networks architected for full duplex peer-to-peer operation of processing stations and uninterruptible transfer of long data records between stations |
US4507727A (en) * | 1982-02-11 | 1985-03-26 | Texas Instruments Incorporated | Microcomputer with ROM test mode of operation |
JPS58159160A (ja) * | 1982-03-17 | 1983-09-21 | Toshiba Corp | デ−タ処理装置 |
US4468734A (en) * | 1982-03-26 | 1984-08-28 | International Business Machines Corporation | Method of purging erroneous signals from closed ring data communication networks capable of repeatedly circulating such signals |
JPS58195257A (ja) * | 1982-05-10 | 1983-11-14 | Hitachi Ltd | 電子計算機の障害回復方式 |
JPS5985153A (ja) * | 1982-11-08 | 1984-05-17 | Hitachi Ltd | 冗長化制御装置 |
US4589068A (en) * | 1983-10-03 | 1986-05-13 | Digital Equipment Corporation | Segmented debugger |
JPS60144851A (ja) * | 1983-12-30 | 1985-07-31 | Fujitsu Ltd | チヤネル制御装置 |
EP0148297B1 (de) * | 1984-01-09 | 1993-12-15 | Hitachi, Ltd. | Synchrones dezentralisiertes Verarbeitungssystem |
US4803683A (en) * | 1985-08-30 | 1989-02-07 | Hitachi, Ltd. | Method and apparatus for testing a distributed computer system |
JPH0756636B2 (ja) * | 1985-12-11 | 1995-06-14 | 株式会社日立製作所 | データ処理方法 |
-
1986
- 1986-08-15 JP JP61191842A patent/JPH0827738B2/ja not_active Expired - Fee Related
-
1987
- 1987-07-20 EP EP92119567A patent/EP0530863B1/de not_active Expired - Lifetime
- 1987-07-20 DE DE87110477T patent/DE3786381T2/de not_active Expired - Fee Related
- 1987-07-20 DE DE3751949T patent/DE3751949T2/de not_active Expired - Fee Related
- 1987-07-20 EP EP87110477A patent/EP0261335B1/de not_active Expired - Lifetime
- 1987-08-12 US US07/084,693 patent/US4953096A/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
EP0530863A3 (en) | 1993-06-09 |
EP0530863A2 (de) | 1993-03-10 |
JPH0827738B2 (ja) | 1996-03-21 |
DE3751949D1 (de) | 1996-12-12 |
EP0261335A3 (en) | 1989-08-30 |
DE3751949T2 (de) | 1997-05-22 |
EP0261335B1 (de) | 1993-06-30 |
US4953096A (en) | 1990-08-28 |
DE3786381D1 (de) | 1993-08-05 |
EP0261335A2 (de) | 1988-03-30 |
JPS6347849A (ja) | 1988-02-29 |
EP0530863B1 (de) | 1996-11-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE3786381T2 (de) | Prüfverfahren und -gerät für ein verteiltes Verarbeitungssystem. | |
DE3629178C2 (de) | ||
DE2515297A1 (de) | Pruefsystem fuer logische netzwerke mit simulatororientiertem fehlerpruefgenerator | |
DE69116919T2 (de) | Selbsttestverfahren für inhaltsadressierbare Speicher | |
DE2953432C1 (de) | Vorrichtung zum Testen eines Mikroprogramms | |
DE3851247T2 (de) | An Ort und Stelle diagnostizierbare elektronische Leiterplatte. | |
DE60203032T2 (de) | Integrierte Halbleiterschaltung | |
DE2328058C2 (de) | Fehlerdiagnoseeinrichtung in einer digitalen Datenverarbeitungsanordnung | |
DE2359776C2 (de) | Speichermodul | |
DE19742446B4 (de) | Fehlerdiagnoseverfahren | |
DE3685634T2 (de) | Verteiltes datenverarbeitungssystem und -verfahren. | |
DE2735397C2 (de) | Überwachungseinrichtung für eine programmgesteuerte Maschine | |
DE4317729A1 (de) | Programmierbare Steuereinheit | |
DE3201768C2 (de) | ||
DE3902488A1 (de) | Vorrichtung zur dezentralen datenverarbeitung und verfahren zum laden von programmen dafuer | |
WO2006105930A1 (de) | Diagnosesystem zur bestimmung einer gewichteten liste möglicherweise fehlerhafter komponenten aus fahrzeugdaten und kundenangaben | |
DE4305522C2 (de) | Einrichtung zur rechnergestützten Diagnose eines aus Modulen bestehenden technischen Systems | |
DE2244402A1 (de) | Datenverarbeitungsanlage | |
DE3702408C2 (de) | ||
DE68922440T2 (de) | Gerät und Verfahren zur gleichzeitigen Einreichung von Fehlerunterbrechung und Fehlerdaten zu einem Unterstützungsprozessor. | |
DE60116187T2 (de) | Wartunssmeldung auf Basis der Fahrparametern eines Aufzugs | |
DE102004004572A1 (de) | Fehlerdiagnoseverfahren für ein Fahrzeugkommunikationsnetz | |
DE2442847A1 (de) | Test- und diagnoseanordnung fuer eine datenverarbeitungseinheit | |
DE2461592C3 (de) | Anordnung zur Durchführung von Wartungsoperationen bei einem Datenverarbeitungssystem | |
DE60002618T2 (de) | Verfahren und Analysewerkzeug zur Fehlerortung in einem Rechner |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8364 | No opposition during term of opposition | ||
8339 | Ceased/non-payment of the annual fee |