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
Application number
DE87110477T
Other languages
English (en)
Other versions
DE3786381D1 (de
Inventor
Hirokazu Kasashima
Katsumi Kawano
Minoru Koizumi
Kinji Mori
Kozo Nakai
Masayuki Orimo
Yasuo Suzuki
Isao Wachi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Publication of DE3786381D1 publication Critical patent/DE3786381D1/de
Application granted granted Critical
Publication of DE3786381T2 publication Critical patent/DE3786381T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01RMEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317Testing of digital circuits
    • G01R31/31701Arrangements for setting the Unit Under Test [UUT] in a test mode
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/22Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3688Test 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

    Hintergrund der Erfindung: Gebiet der Erfindung:
  • Die Erfindung betrifft ein Prüfverfahren und eine Prüfvorrichtung, durch die ein Prüfmodus und ein Onlinemodus in einem verteilten System ausgetauscht werden.
  • Beschreibung des Standes der Technik:
  • 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.
  • Zusammenfassung der Erfindung:
  • 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.
  • Kurze Beschreibung der Zeichnungen:
  • 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.
  • Detaillierte Beschreibung der bevorzugten Ausführungsbeispiele:
  • 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.
  • (1) Betrieb im Testmodus:
  • 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.
  • (2) Betrieb im Testmodus:
  • 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.
  • (3) Betrieb im Testmodus:
  • 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.
  • (4) Betrieb im Onlinemodus:
  • 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.
DE87110477T 1986-08-15 1987-07-20 Prüfverfahren und -gerät für ein verteiltes Verarbeitungssystem. Expired - Fee Related DE3786381T2 (de)

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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 株式会社日立製作所 データ処理方法

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