DE3751949T2

DE3751949T2 - Verfahren zum Starten eines Untersystems in einem verteilten Verarbeitungssystem

Info

Publication number: DE3751949T2
Application number: DE3751949T
Authority: DE
Inventors: Hirokazu Kasashima; Katsumi Kawano; Minoru Koizumi; Kinji Mori; Kozo Nakai; Masayuki Orimo; Yasuo Suzuki; Isao Wachi
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1986-08-15
Filing date: 1987-07-20
Publication date: 1997-05-22
Anticipated expiration: 2007-07-21
Also published as: EP0530863A2; DE3786381D1; EP0261335B1; US4953096A; JPS6347849A; DE3786381T2; EP0530863A3; DE3751949D1; EP0261335A3; EP0530863B1; EP0261335A2; JPH0827738B2

Description

Umfeld der Erfindung

Gebiet der Erfindung

Die Erfindung betrifft ein Prüfverfahren und eine Prüfvorrichtung, durch die ein Prüfmodus und ein On-line-Modus in einem verteilten System ausgetauscht werden.

Beschreibung des Standes der Technik

JP-A-57-146361 offenbart ein Verfahren, durch das in einem verteilten Verarbeitungssystem, bei dem die Reihe von Prozessen eines Tasks in verteilter Weise auf mehrere an eine gemeinsame Übertragungsleitung angeschlossene Prozessoren aufgeteilt 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. Nach diesem Verfahren kann der jeweilige Prozessor entsprechende der Reihen von Prozessen verteilt auszuführen, ohne daß ein Verwaltungsprozessor zum Verwalten des gesamten Systems erforderlich wäre. Es hat jedoch keine Mittel zum Testen eines zum Laden in jeden Prozessor entwickelten Anwendungsprograinms unter Verwendung von Online-Daten und zum Entscheiden, ob sich die betreffende Online-Umgebung in einem normalen oder einem anomalen Zustand befindet.
US-A-4 306 288 offenbart eine Prozessor-Startsequenz in einem Mehrprozessorsystem, bei dem jeder Prozessor mit dem Ablauf einer Diagnoseroutine anfängt. Bei fehlerloser Beendigung dieser Routine wird der Prozessor an einen Kommunikationskanal mit den anderen Prozessoren angeschlossen.
Einige herkömmliche Systeme außer dem verteilten Verarbeitungssystem beinhalten Mittel zum Sammeln der verarbeiteten Ergebnisdaten von Programmen. Die Funktion dieser Mittel besteht jedoch lediglich darin, den Logarithmus der Daten in zeitlicher Folge zu bilden, was für eine Analyse des Teststart-Ergebnisses unter Verwendung der gesammelten Ergebnisse unbefriedigend war.
Ferner kann dann, wenn ein Test mit On-line-Daten ausgeführt worden ist, ein anderes Untersystem, das das Testergebnis empfängt, innerhalb des eigenen Untersystems einen Prozeß aufweisen, der von dem empfangenen Testergebnis beeinflußt wird. Daher muß darauf geachtet werden, daß der Test mit den On-line-Daten realisiert wird, ohne daß ein anderer Teil beeinflußt wird.
Zu berücksichtigen ist auch der Fall, daß ein nach dem Testergebnis für normal befundenes Untersystem direkt in das System eingegliedert und dann betrieben werden soll.

Zusammenfassung der Erfindung

Eine Aufgabe der Erfindung besteht darin, ein Testverfahren anzugeben, gemäß dem ein Test ausgeführt werden kann, ohne ein anderes Untersystem zu beeinflussen, selbst wenn während des Betriebs eines Systems On-line-Daten verwendet werden, und bei dem außerdem ein getestetes Untersystem bei Bedarf unmittelbar eingegliedert werden kann.
Diese Aufgabe der in den beigefügten Ansprüchen im einzelnen definierten Erfindung wird durch ein verteiltes System mit mehreren Untersystemen gelöst, die an eine gemeinsame Übertragungsleitung angeschlossen sind, wobei jedes der Untersysteme eine Einrichtung zum Registrieren fehlerhafter Programme innerhalb des entsprechenden Untersystens sowie eine Modusänderungseinrichtung aufweist, so daß ein Programm mit einem von der Übertragungsleitung empfangenen Datenverarbeitungsergebnis oder mit von irgendeiner anderen Einrichtung empfangenen Daten diaguostiziert wird, wobei es bei Vorliegen eines Fehlers in einer Registriereinrichtung für fehlerhafte Programme registriert wird, und wobei die Modusänderungseinrichtung auf die Registriereinrichtung für fehlerhafte Programme Bezug nimmt und entsprechend dem in der Registriereinrichtung registrierten oder aus dieser gelöschten Programm Testmodus und On-line-Modus austauscht.
In einem verteilten Verarbeitungssystem aus mehreren an ein Netzwerk angeschlossenen Untersystemen empfängt jedes der Untersysteme über das Netzwerk oder von einer beliebigen anderen Einrichtung Daten und verarbeitet sie. Bei der Erfindung diagnostiziert das Untersystem, das den Prozeß selbst ausgeführt hat, oder ein beliebiges anderes Untersystem, das Ergebnis des Prozesses etwa durch Überprüfen der Entsprechung der Inhalte von Eingangs- und Ausgangsdaten als normal oder anomal.
Unter Verwendung des Diagnoseergebnisses des eigenen Untersystems oder desjenigen des anderen Untersystems können die Modi unabhängig voneinander ausgetauscht werden, um bei normalem Ergebnis den On-line-Modus und bei anomalem Ergebnis den Testmodus einzustellen. Ist in jedem Untersystem eine Vorrichtung vorhanden, die im Testmodus On-line-Daten in Testdaten umwandelt, so kann ferner das verarbeitete Ergebnis der On-line-Daten als Testdaten im Testmodus ausgegeben werden.
Aus dem obigen Grund kann das Untersystem sogar mit den On-line-Daten getestet werden, ohne daß während des Betriebs des Systems ein anderes Untersystem beeinflußt wird; ist das Untersystem normal, so kann es direkt in das System eingegliedert werden.
Ob das Verarbeitungsergebnis normal oder anomal ist, kann außer durch den oben genannten Vergleich der Inhalte der Eingangs- und Ausgangsdaten auch durch Vergleich einer Verarbeitungszeitspanne mit einer vorgegebenen Zeitspanne (Zeitüberschreitung) usw. entschieden werden.

Kurzbeschreibung der Zeichnungen

Fig. 1 zeigt ein Flußdiagramm eines Modusänderungsprozesses als Ausführungsbeispiel der Erfindung;
Fig. 2 zeigt ein schematisches Blockdiagramm des inneren Aufbaus jedes Untersystens eines verteilten Verarbeitungssystems gemäß einem Ausführungsbeispiel der Erfindung;
Fig. 3 zeigt ein Diagramm der Beziehungen von Eingangs/Ausgangsdaten bei jeweiligen Moduszuständen im verteilten Verarbeitungssystem als Ausführungsbeispiel der Erfindung;
Fig. 4 zeigt ein Diagramm des Datenformats, mit dem jedes Untersystem Übertragungen ins Netzwerk vornimmt;
Fig. 5 zeigt ein Diagramm für ein Beispiel einer Anordnung einer Registriertabelle für fehlerhafte Programme;
Fig. 6 zeigt ein Diagramm für ein Beispiel des Diagnoseformats eines von einer Testeinheit gelieferten Verarbeitungsergebnisses;
Fig. 7 zeigt ein Anordnungsdiagramm eines anderen Ausführungsbeispiels der Erfindung; und
Fig. 8 und 9 sind Formatdiagramme der Ausgangsinformationen einer Testeinheit und der Ausgangsinformationen eines Diagnoseergebnisses in Fig. 7.

Detaillierte Beschreibung der bevorzugten Ausführungsbeispiele

Anhand der Zeichnungen werden nun Ausführungsbeispiele der Erfindung im einzelnen beschrieben.
Fig. 3 ist ein Diagramm, das die Beziehungen von Eingangs/Ausgangs-Daten in jeweiligen Moduszuständen in einem verteilten Verarbeitungssystem als Ausführungsbeispiel der Erfindung zeigt. In der Figur sind Untersysteme 1, 2, ... n über ein Netzwerk 21 miteinander verbunden. Die Untersysteme 1, 2, ... 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 es benötigt, 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 bezeichnen Bezugszeichen 31 - 36 Daten, die innerhalb des Netzwerks 21 fließen, unter denen die Einzeldaten 31 - 35 Testdaten sind und der Datenwert 36 ein On-line- Datenwert 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 Untersystennummer 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 Untersysterne 1, 2, ... n. Eine Übertragungssteuereinheit 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 Übertragungssteuereinheit 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 Inhaltscode-Tabelle 53 registriert.
Ist der Inhaltscode 41 der im Netzwerk 21 fließenden Daten in der Inhaltscode-Tabelle 53 vorhanden ist, so 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 anomal 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. Anomalie 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.
Hat die Testeinheit 56 das Verarbeitungsergebnis jedes Programms diaguostiziert, so 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 anomal ist. Beispielsweise ist er "0" für Normalität und "1" für Anomalie.
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. Ist zdem Programm 54 innerhalb des Untersystems 1 .B. die Nummer "1" zugeordnet, so zeichnet die Prüfeinheit 56, die das Verarbeitungsergebnis 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 Diaguoseergebnis von der Prüfeinheit 56 als anomal 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.
Programm-Einzelinformationen 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.
Ist im Fall einer Modusänderung des Untersystems auch nur ein Programm in die Tabelle 57 für fehlerhafte Programme eingeschrieben, so 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 Untersystern erkennt den Inhaltscode 41 der im Netzwerk 21 fließenden Daten und beurteilt, ob es diese Daten benötigt oder nicht, und es nimmt die Daten erforderlichenfalls auf. Ist ein Testdaten-Anzeige-Flag, z.B. mit dem Wert "1", wie oben angegeben, als Testflag für die aufgenommenen Daten gesetzt, so 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 Untersysterne 2 und 3 im On-line-Modus sind; die anderen Untersysteme sollen derzeit nicht berücksichtigt werden. Auch 1 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 1 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 ferner 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 On-line-Daten 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ängtern 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 anomal ist. Da das Programm 54 sich zum normalen Zustand erholt hat, beurteilt die Prüfeinheit 56 das Verarbeitungsergebnis vorn 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ß anomal 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ß anomal 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 Testrnodus 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 vorn Untersystem 1 gelieferter Testdatenwert ist.
(2) Betrieb 2 im Testmodus:
Nachfolgend sei angenommen, daß On-line-Daten 36 vom Untersystem 1 aufgenommen wurden.
Es sei angenommen, daß das Programm 55 des Untersystems 1, das die On-line-Daten 36 aufgenommen hat, fehlerhaft bleibt. Die Prüfeinheit 56, die das Verarbeitungsergebnis vorn 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 Anderungsprozeß 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 Ta-15 belle 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 3 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 On-line-Daten 36 empfangen hat, wird in ihm derselbe Prozeß wie im Fall des fehlerhaften Programms 55 ausgeführt. D.h., daß die Testeinheit 56 das Verarbeitungsergebmis 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 anomalen 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). Wird nun angenommen, daß sich auch das Programm 54 wie oben beschrieben bereits erholt hat, so ist nun kein Programm mehr in die Tabelle 57 für fehlerhafte Programme eingeschrieben. Daher führt die Modusänderungseinheit 58 den j Wechsel in den On-line-Modus aus (Schritte 15, 17).
So wird zu diesem Zeitpunkt das Testflag 43 des Verarbeitungsergebnisses 34 der On-line-Daten 36 auf "0" gesetzt und als On-line-Daten ausgegeben. Daher wird auch das Verarbeitungsergebnis 35 des Untersystems 3, das die Daten 34 empfangen hat, als On-line-Daten ausgegeben.
(4) Betrieb 1 im On-line-Modus:
Nachfolgend sei angenommen, daß das Programm 54 innerhalb des Untersystems 2 im On-line-Modus fehlerhaft wurde.
Es sei nun angenommen, daß Daten 32 On-line-Daten 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 On-line-Modus, 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 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 On-line-Modus und den Testmodus abhängig von seiner eigenen Beurteilung jedesmal dann, wenn Testdaten oder On-line-Daten 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.
Ist das System während seines Betriebs durch Hinzufügen eines neuen Untersysterns oder durch Hinzufügen neuer Programme zu beliebigen vorhandenen Untersysternen erweitert worden, so 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 On-line-Daten Tests auf dieselbe Weise wie beim vorigen Ausführungsbeispiel ausgeführt. Sind alle Programme fehlerlos geworden, so wird das System in den On-line-Modus umgestellt, und die erweiterten Abschnitte können im On-line-Status betrieben werden.
Bei den obigen Ausführungsbeispielen wurde ein Verfahren beschrieben, das ein Untersystern selbst zwischen dem Testmodus und dem On-line-Modus wechselt. Die Modusänderung eines einzelnen Programms kann durch ein Verfahren bewirkt werden, i das dem Verfahren für ein Untersystem ähnlich ist.
Einfache Beispiele hierfür werden nachstehend 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 On-line-Daten gestartet wurde und daß das Verarbeitungsergebmis 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 Diagnoseergebmisses, und der Prozeß der Modusänderungseinheit 58 können mit denselben Verfahren realisiert werden wie bei den vorigen Ausführungsbeispielen.
Nachdem nun das Verarbeitungsergebmis 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 Verarbeitungsergebmis 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 On-line-Daten 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 On-line-Modus. D.h., daß das Testflag 43 diesmal auf "0" gesetzt wird und das Verarbeitungsergebnis des Programms 54 als On-line-Datenwert 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. Ist die Modusänderungseinheit 58 beispielsweise so eingestellt ist, daß sie jedes Programm als fehlerfrei ansieht, wenn das Programm fünfmal in Folge gearbeitet hat, und dann die Modi ändert, so wird das Untersystem im Testmodus gehalten, solange nicht alle Programme im Untersystem fünfmal normal arbeiten. Werden andererseits die Modi der einzelnen Programme erst dann verändert, wenn jedes einzelne Programm fünfmal normal gearbeitet hat, so wird ein Programm, das noch nicht fünfmal gearbeitet hat, weiter im Testmodus belassen.
In den vorstehenden Ausführungsbeispielen wurde das Programm von der Prüfeinheit 56 innerhalb des entsprechenden Untersystems diagnostiziert; die Modi können aber auch aufgrund des Diagnoseergebnisses eines anderen Untersystems geändert werden.
Ein einfaches Ausführungsbeispiel hierfür wird unten stehend unter Bezugnahme auf Fig. 7 beschrieben.
Wie oben wird auch hier nur die Modusänderung des Programms 54 betrachtet. Es sei angenommen, daß innerhalb der Untersysteme 2 eine Diagnose des Verarbeitungsergebnisses der jeweiligen Programme stattfindet, d.h. ein externer Tester 80 vorhanden ist. Ferner sind der Kürze halber die Prüfeinheit 56 und die Modusänderung 58 in Fig. 7 gemeinsam dargestellt.
Wird das Programm 54 neu in das Untersystem 1 eingege ben, so wird die Information zu diesem Programm genauso wie oben in die Tabelle 57 für fehlerhafte Programme eingeschrieben.
Es sei angenommen, daß das Programm 54 für einen Test mit On-line-Daten 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 Eingabedateninformation 45, der Ausgangsdaten 46 und der Programminformation 44, und er liefert Diagnose-Ergebnisdaten 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 Diagnoseergebmis 47 aufgezeichnet.
Die Prüfeinheit 56 innerhalb des Untersystems 1, die das Diagnoseergebmis 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 Diaguoseergebnis 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 vorn Testmodus in den On-line-Modus 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 On-line- 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 Testdaten- Speicher Datei versehen ist. Selbst mit solchen Daten können die Modi ziemlich ähnlich geändert werden.
Im Testrnodus ist es nicht immer erforderlich, Testdaten an die Übertragungsleitung zu liefern.
In der Prüfeinheit 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 On-line-Modus abhängig von eigener Beurteilung auswechseln. Durch den Wechsel wird das Ergebnis des Tests, selbst wenn er mit On-line-Daten 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 I 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 On-line-Modus 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 On-line-Daten 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

1. Verfahren zum Starten eines Programms in einem verteilten Verarbeitungssystem mit mehreren durch ein Übertragungsmedium (21) miteinander verbundenen Untersystemen (1...4), deren jedes mindestens ein Programm zur Ausführung einer gegebenen Funktion enthält, wobei

(a) das Programm in einen Testmodus versetzt wird,

(b) die von dem Programm geforderten On-Line-Daten über das Übertragungsrnedium empfangen werden,

(c) die Funktion des Programms unter Benutzung der On- Line-Daten durchgeführt wird,

(d) die besagte Funktion aufgrund des Ergebnisses der Ausführung im Schritt (d) diagnostiziert wird, und

(e) falls das Ergebnis als normal diagnostiziert wird, das Programm in einen On-Line-Modus versetzt und das Verarbeitungsergebnis über das Übertragungsmedium übertragen wird.

2. Verfahren nach Anspruch 1, wobei zu dem Schritt (a) das Registrieren des Programms als fehlerhaftes Programm in einer Registriereinrichtung (57) gehört.

3. Verfahren nach Anspruch 2, wobei zu dem Schritt (e) gehört:

Löschen des Programms, falls nicht als fehlerhaft diagnostiziert, aus der Registriereinrichtung (57) und

Prüfen der Registriereinrichtung (57) und Versetzen des Programms, falls nicht in der Registriereinrichtung (57) registriert, in einen On-Line-Modus.