DE69128017T2

DE69128017T2 - Verteiltes rechnersystem

Info

Publication number: DE69128017T2
Application number: DE69128017T
Authority: DE
Inventors: Eric Campbell; Hugo Simpson
Original assignee: Matra Bae Dynamics UK Ltd
Current assignee: MBDA UK Ltd
Priority date: 1990-04-12
Filing date: 1991-04-12
Publication date: 1998-02-19
Anticipated expiration: 2011-04-13
Also published as: GB2244356B; GB9107865D0; WO1991016681A1; EP0477364B1; US5469549A; EP0477364A1; DE69128017D1; GB2244356A; JPH04507160A; GB9008366D0

Description

Es besteht ein fortgesetzes Wachstum im Hinblick auf die Computerleistung, die erforderlich ist, um digitale Datenverarbeitungs-Anwendungen zu unterstützen. Eine Möglichkeit zur Lösung dieses Problems besteht darin, größere, schnellere und komplexere Einzelprozessoren zu entwickeln; eine andere Möglichkeit besteht darin, mehrere Prozessoren miteinander, beispielsweise über Hochgeschwindigkeitsdaten- Leitungen, zu verbinden.
Bei den bestehenden Computersystemen, die miteinander verbundene Mehrfachprozessoren benutzen, ergeben sich verschiedene Probleme, und die Aufgabe der vorliegenden Erfindung besteht darin, ein abgewandeltes Mehrfachprozessor-System zu schaffen, welches vorzugsweise das Konzept eines integrierten, zugeordneten Hardware/Software-Systems enthält und bevorzugt für gewisse Anwendungsbereiche benutzt werden kann. Gemäß der vorliegenden Erfindung ist ein verteiltes Computersystem vorgesehen, welches die folgenden Merkmale aufweist:
mehrere asynchrone Computer-Einheiten, von denen jede mit einem Datenprozessor und einem privaten Datenspeicher versehen ist, der jeweils an den Prozessor über eine private Datenleitung verbunden ist;
einen Gemeinschafts-Datenspeicher, der Zugriffs- Ports aufweist, die mit jeweils einem Computer über zugeordnete private Datenleitungen verbunden sind, damit jede Computer- Einheit in der Lage ist, mit irgendeiner anderen Computer- Einheit über jeweils einen Zweiwege-Datenleitweg zu kommunizieren, der ein jeweiliges individuelles Feld des Gemeinschafts-Datenspeichers umfaßt; und
Kommunikationssteuermittel, die an die privaten Datenleitungen und den Gemeinschafts-Datenspeicher angeschlossen sind, um auf Steuerdaten zu antworten, die vom Prozessor irgendeiner Computer-Einheit ausgegeben wurden, um die Kommunikation über einen Leitweg einzuleiten, der vom Prozessor bestimmt wird.
Zum besseren Verständnis der Erfindung wird nachstehend ein Ausführungsbeispiel anhand der beiliegenden Zeichnung beschrieben. In der Zeichnung zeigen:
Fig. 1 ist ein Diagramm zur Erläuterung des allgemeinen Aufbaus der Zwischenprozeß-Kommunikation, die gemäß vorliegender Erfindung benutzt wird;
Fig. 2 ist ein vereinfachtes Diägramm eines Computersystems; und
Fig. 3 ist ein Diagramm zur Erläuterung der Benutzung des Systems nach Fig. 2 im Umfang einer integrierten Hardware/Software-Entwicklungsanordnung.
In Verbindung mit dem zu beschreibenden System wird auf eine sogenannte Data Interaction Architecture (DIA) Bezug genommen, welche auf den Daten beruht, die zwischen gleichzeitigen Prozeß-Systemen liegen. Der Ausdruck Architecture wird im Sinne von Elementen und ihrer Verbindung und Gruppierung benutzt, die zusammen ein digitales Datenverarbeitungssystem bilden. Im wesentlichen sind diese Elemente die Software- Prozesse und die Hardware-Prozessoren, die über die Gemeinschaftsdatenfelder kommunizieren, die in einem Gemeinschaftsspeicher angegeben sind. Demgemäß umfaßt das DIA eine Software mit Mehrfachaufgaben und eine Hardware mit einer Mehrfachverarbeitung. Das DIA kann als integrierende Technologie angesehen werden, die einen Rahmen für das System und die Komponentenausbildung liefert. Dies ist die allgemeine Annäherung, die innerhalb eines weiten Bereiches von Prozessortypen und Programmiersprachen benutzbar ist.
In einem Computersystem kann der Zwischenprozeß und die Zwischenprozessor-Kommunikation direkt sein, d. h. in totalem Synchronismus mit den "Lese- und Schreib"-Verfahren, die an dem Kommunikationspunkt miteinander verriegelt sind. Die von dem Prozeß unabhängigen Daten können nicht existieren, da kein Datenfeld (oder Prozeß) vorhanden ist, der die Information vorübergehend halten kann. Es gibt einen rendezvousartigen Stil der Kommunikation, der natürlich eine schwerwiegende Zeitabhängigkeit zwischen den beiden Prozessen einführt. In den Kommunikationspfad kann ein Monitorprozeß eingeschaltet werden, so daß die Operationen von Lese- und Schreibprozeß tatsächlich entkoppelt werden, aber dies geschieht nur auf Kosten beträchtlicher zusätzlicher Freileitungen und das zeitliche Zusammenwirken kann nicht völlig ausgeschaltet werden.
Das zu beschreibende System, d.h. das DIA, umfaßt eine Echtzeitschaltung, bei der die Kommunikation über einen Gemeinschaftsspeicher, d.h. indirekt, erfolgt, wie dies aus Fig. 1 ersichtlich ist. Die Form der Kommunikation ist mehr flexibel als oben erwähnt, indem es benutzt werden kann um einen weiten Bereich von Kommunikationsprotokollen zu liefern, einschließlich Formen, die voll oder bedingt asynchron, die lose synchron (beschränkter Puffer) und voll synchron sind (die Rendezvous-Form). Asynchrone und lose synchrone Protokolle vermeiden die eng verriegelten Zeitbeziehungen, die in der Rendezvous-Form enthalten sind, und es wird die Gefahr der gegenseitigen Blockierung und der schwerwiegenden Verschlechterung während der Laufzeit beträchtlich vermindert. Das DIA ergibt jedoch nicht die optimale Verwirklichung und alle Protokolle werden so abgestützt, daß der Konstrukteur die geeignetste Form zur Anwendung auswählen kann.
Der Software-Aufbau in DIA wird nach der bekannten MASCOT-Form (Modular Approach to Software Construction Operation and Test) der Echtzeitschaltung modelliert. MASCOT ist ein Software- Ausbildungsverfahren, das auf Datenflußkonzepten beruht und beispielsweise in den folgenden Artikeln beschrieben ist. "Process Synchronisation in Mascot" von H R Simpson und K Jackson, Computer Journal, 1979, 22, (4), Seiten 332-345 und in "The Mascot Method" von H R Simpson, Software Engineering Journal, 1986, 1, (3) Seiten 103-120. Dieses Verfahren hat den wichtigen Vorteil, daß es die Möglichkeit schafft, das System, welches zu repräsentieren ist, funktionell zu verteilen, so daß Mittel geschaffen werden, um sowohl die Umsetzung der Software-Ausbildung in verteilte Hardware zu steuern, und es wird die Möglichkeit geschaffen, Festzeit- Eigenschaften in Ausdrücken von Informations-Fortschreiteffekten zu analysieren.
Einzelne MASCOT-Prozesse sind bekannt als ACTIVITIEs. Jede ACTIVITY ist hinsichtlich ihres Konzeptes unabhängig, d.h. sie läuft gleichzeitig mit allen anderen ACTIVITIEs. In der Praxis, wo die ACTIVITIEs einem Prozessor gemeinsam sind, muß ein Planer zusammen mit Synchronisiermitteln vorgesehen werden, um einen gegenseitigen Ausschluß und eine Kreuz- Stimulierung zu gewährleisten.
Die gemeinsamen MASCOT-Datenfelder, über die die ACTIVITIEs kommunizieren, sind bekannt als Intercommunication Data Areas (IDAs), und es gibt zwei prinzipielle Klassen. Die POOL-Form von IDA wird benutzt, um Bezugsdaten zu halten, die von einem oder mehreren Aktualisierungsverfahren gehalten werden, um von einem oder mehreren befragt zu werden unter Benutzung von Prozessen mit einer minimalen zeitlichen Störung. Die CHANNEL-Form von IDA wird benutzt, um Nachrichten zwischen einem oder mehreren Produktprozessen nach einem oder mehreren Verbraucher-Prozessen zu leiten. POOLs sind im wesentlichen asynchron, während die CHANNELs synchron sind.
Eine wichtige DIA-Erstreckung für MASCOT ist das ROUTE-Konzept.
Eine ROUTE wird benutzt, um eine Kommunikation zwischen einem einzigen Schreibprozeß und einem einzigen Leseprozeß herbeizuführen, und sie ist äquivalent, entweder einem POOL (asynchrone Kommunikation zwischen einem Aktualisator und einem Benutzer) oder einem CHANNEL (synchrone Kommunikation zwischen einem Erzeuger und einem Verbraucher). ROUTEs werden benutzt, um abstrakte Kommunikations-Ausbildungen auszudrücken, und sie können in die Hardware in verschiedener Form übertragen werden, wodurch die Kommunikations-Erfordernisse erfüllt werden, unabhängig von der relativen Lage der ACTIVITIEs, die durch die ROUTE verbunden sind. DIA liefert eine spezielle Exekutiv- Software und Hardware-Möglichkeiten, um das ROUTE-Konzept zu stützen.
Die DIA-Verarbeitungs-Konfiguration ist in Fig. 2 dargestellt. Im Idealfall hat die zentrale Prozessoreinheit (CPU) 41 eine relativ einfache Form eines Reduced Instruction Set Computers (RISC), welcher keine Merkmale benutzt, die nicht bestimmbare Zeiteffekte einführen, wie z.B. Unterbrechungen, ein caching und dergleichen. Es können die meisten komplexen Computer benutzt werden, aber hierdurch wird es noch schwieriger, die Laufzeiteigenschaften zu analysieren.
Die zentrale vertikale Linie 42 in Fig. 2 gibt die private Speicherleitung der zentralen Prozessoreinheit wieder. Dies ergibt einen Zugriff auf: privaten Speicher (der private Schaltungselemente aufweist) 43, asynchrone Vorrichtungen (Peripheriegeräte) 44, synchrone Vorrichtungen (Peripheriegeräte, die eine äußere Anregung erzeugen können) 45, eine Reihe von asynchronen Doppelport-Speichern (ADPM - die Gemeinschafts-IDA-Elemente enthalten) 48 und zwei Gruppen spezialisierter VLSI-Vorrichtungen, nämlich ein Kernel- Exekutiv-Chip (KEC) 47 und für jeden Speicher 46 ein Comms- Exekutiv-Chip (CEC) 48.
Das KEC stützt die Mehrfachaufgaben, die benötigt werden, wenn zahlreiche Aktivitäten auf einen einzigen Prozessor übertragen werden (Prozessor = CPU + Privatspeicher). Es ist auch möglich, äußere Anregungen aufzunehmen, die Forderungen für eine Verarbeitung sind, die außerhalb des Prozessors auftreten (z.B. von synchronen Vorrichtungen, Zeitgebern, CECs usw.). Äußere Anregungen können als kooperative Unterbrechungen angesehen werden; sie ermöglichen es, daß äußere Forderungen an jedem Wiederplanungspunkt in Betracht gezogen werden können (wobei der Erfolg dieser Strategie natürlich abhängig ist von der genauen Vorhersage maximaler slice-Zeiten und von der Anordnung spezieller Prozessoren, die sämtliche Erfordernisse einer schnellen Reaktionszeit erfüllen). Es werden unterschiedliche Funktionen des KEC benutzt, um einen Schreiboder Lesezugriff auf unterschiedliche Adressen zu erhalten, die dem Chip zugeordnet sind (dies schafft die Möglichkeit, daß der Chip seine Funktion durchführt, wenn er über Interfaces mit zahlreichen CPU-Typen verbunden wird).
Eine Kommunikation mit einem benachbarten Prozessor wird über ein ADPM-CEC-Paar hergestellt. Jedes ADPM besitzt zwei völlig unabhängige Zugriffspfade nach den Speicherplätzen Hierdurch wird die Notwendigkeit vermieden, irgendeine willkürliche Form auf der Basis der Hardware einzuführen (die Daten-Integrität wird durch das CEC und die Software- Exekutive aufrechterhalten (siehe weiter unten)). Wie bei dem KEC erfolgt die Wahl der Funktionen am CEC mittels Schreib- und Leseoperationen auf speziellen Adressen mit der zusätzlichen Möglichkeit, eines von zahlreichen CECs durch Benutzung eines bestimmten Wertes im Datenfeld mit einer Schreiboperation auszuwählen. Gewisse CEC-Operationen erzeugen äußere Anregungen, die dem KEC eines benachbarten Prozessors zugeführt werden (dies wird für synchrone Leitwege zwischen benachbarten Prozessorpaaren benötigt). Die beiden Schnittstellen eines CECs, und zwar eine für jeden der hiermit verbundenen Prozessoren, liefern identische Leistungsmerkmale und, wie bei ADPM, ist keine willkürliche Entscheidung erforderlich.
Die Mehrfach-Leistungsmerkmale in Gestalt eines KECs und des Software-Planers schaffen die Mittel, durch die die zentrale Prozessoreinheit in jedem Prozessor zwischen residente ACTIVITIEs eingeteilt wird.
Das KEC ist in der Lage, Forderungen für die Verarbeitung zu registrieren und die nächste ACTIVITY als zugeteilte CPU-Zeit zu wählen. Das KEC, das gegenwärtig verfügbar ist, liefert einen Planungsträger bis herauf zu 64 ACTIVITIEs, die in 8 Prioritätspegeln zu je 8 ACTIVITIEs in jedem Pegel angeordnet sind. Äußere Anregungen werden (indirekt) durch den Level mit der höchsten Priortät geleitet. Die Wahlstrategie besteht darin, eine ACTIVITY vom Pegel höchster Priorität zu wählen, das die Forderung für die Verarbeitung enthält; wenn mehr als eine Forderung auf diesem Pegel vorhanden ist, dann wird eine "round robin search" benutzt, um die nächste ACTIVITY auszuwählen (der Chip erinnert sich an die letzte ACTIVITY, die in jedem Pegel geplant ist). Der Chip zeigt die nächste ACTIVITY an, die zu planen ist, indem die Zahl in den Bereich 0..63 zurückgeführt wird; wenn kein gegenwärtiger Bedarf besteht, dann wird 64 zurückgeführt.
Das KEC enthält zwei primäre Steuerbits für jede ACTIVITY. Das erste Bit ist das Startbit, das für eine ACTIVITY gesetzt werden muß, die für eine Planung kandidiert. Dies ergibt eine Gesamtsteuerung und kann benutzt werden, um die MASCOT-Steuerbefehle zu übermitteln. Das zweite Bit ist das Stimulierbit, das benutzt wird, um einen gegenwärtigen Bedarf für die Planung anzugeben. Es werden äußere Stimuli auf dem Chip gehalten, und sie werden an einem geeigneten Punkt (siehe unten) in die Planung eingeführt.
Die prinzipielle Form des Zusammenwirkens zwischen dem KEC und dem Software-Planer benutzt die folgenden Chip-Operationen (alle von diesen werden in einem einzigen Speicherzugriff durchgeführt, obgleich sie auch als PROCEDUREs oder FUNCTIONs ausgebildet sein können, was nur aus Gründen der Erläuterung erwähnt wird):
a. PROCEDUR kec_suspend; die äußeren Stimuli werden in die Tabelle aufgenommen (indem das Stim-Bit für irgendeine ausstehende äußere Nachfrage gesetzt wird). Das Stim-Bit für die gegenwärtige Aktivität wird wieder instandgesetzt, wodurch eine Forderung für eine weitere Verarbeitung registriert wird.
b. PROCEDUR kec_wait; wie bei kec-suspend mit dem Unterschied, daß das Stim-Bit nicht wieder instandgesetzt wird.
c. PROCEDUR kec_stim (act : 0..63); dies stützt die innere Anregung, wodurch eine ACTIVITY die Stim-Bits einer anderen einstellen kann.
d. FUNCTION kec_nextact : 0..64; hierdurch wird die Zahl der nächsten ACTIVITY, die in die Tabelle aufgenommen werden soll, zurückgeführt, und es werden die äußeren Anregungs-Nachfragen gelöscht, wenn diese in die Tabelle aufgenommen wurden, und es wird dann das Stim-Bit der ACTIVITY gelöscht, welches zur Aufnahme in die Tabelle gewählt wurde.
Die äußeren Anregungen sind überwiegend asynchron und das KEC und die zugeordnete Software gewährleisten, daß die hiermit verknüpfte Gefahr der Metastabilität auf einen vernachlässigbaren Wert vermindert und effektiv eliminiert wird. Dies wird durch die Verzögerung erreicht, die zwischen der Akzeptanz der äußeren Anregungen durch kec_suspend oder kec_wait existieren muß, und die Benutzung von kec_nextact zur Wahl der nächsten ACTIVITY.
Der Software-Tabellierer, der mit dem KEC über eine Schnittstelle verbunden ist, ist ausgeprägt unkompliziert. Zunächst führen wir einige Hilfsdefinitionen ein:
a. VAR curract: 0..64; dies ist eine Variable, die die Zahl der gegenwärtig geplanten ACTIVITY hält.
b. PROCECUR save; diese Prozedur sichert den Kontext der ACTIVITY, deren Zahl durch den Wert von curract angezeigt wird. Es wird angenommen, daß für diesen Zweck ein Raum ausgespart wurde. Der Kontext von einer ACTIVITY wird initialisiert, so daß die ACTIVITY zuerst in ihren Startpunkt eingeführt wird.
c. PROCEDUR restore; diese Prozedur stellt den Kontext der ACTIVITY wieder her, deren Zahl durch den Wert von curract angezeigt wird.
Die tabellierten Grundelemente, die direkt mit dem KEC über den Wert in Verbindung stehen, können nun wie folgt formuliert werden:-
Nunmehr sind wir in der Lage festzustellen, wie die Kreuzstimulation und der gegenseitige Ausschluß, nämlich die Basis- Synchronisier-Grundelemente, geschaffen werden können.
Nunmehr wird eine Aufzeichnung der Type control_node eingeführt, um einen Steuerpunkt zu schaffen, an dem eine ACTIVITY warten kann, um durch eine andere ACTIVITY angeregt zu werden:
wobei das Warten für FALSE initialisiert wird. Die Kreuzanregungsfähigkeit wird wie folgt geschaffen:
Der gegenseitige Ausschluß ist etwas mühsamer, und es werden gewisse Hilfsdefinitionen benötigt:-
a. TYPE act_queue; dies ist jene Type von Varbiablen, die in der Lage sind, ein FIFO queue von ACTIVITY- Zahlen zu halten.
b. PROCEDUR add_back (VAR q : act_queue); dies addiert die gegenwärtige ACTIVITY zur Rückseite des designierten act_queue.
c. FUNCTION take_front (VAR q : act_queue) : 0.. 63; dies nimmt die ACTIVITY von der Vorderseite des designierten act_queue weg.
Es wird eine control_queue-Aufzeichnungs-Type eingeführt, um Punkte zu schaffen, an denen die ACTIVITIEs an einem FIFO queue gehalten werden können, wobei die Verfügbarkeit einer "Resource" vorhanden ist, die ebenfalls durch andere ACTIVITIEs benötigt wird:
wobei die Zählung initialisiert wird bis -1 und das queue wird zur Entleerung initialisiert. Die gegenseitige Ausschlußfähigkeit wird demgemäß wie folgt geschaffen:
Die Kreuzanregung und die gegenseitigen Ausschluß-Grundelemente liefern alles, was nötig ist, um synchrones Zusammenwirken innerhalb eines einzigen Prozessors zu gewährleisten. Diese sind kompakt und einfach in der Anordnung.
Kommunikations-Möglichkeiten in Form von CEC, ADPM, ROUTE- Ausbildungen und Software-Anordnungen schaffen die Mittel, durch die ACTIVITIEs in benachbarten Prozessoren Daten von einem zu einem anderen überführen können. Unsere Beschreibung konzentriert sich hier auf diese spezielle Gemeinschaftsspeicher-Ausbildung, aber es muß darauf hingewiesen werden, daß eine ROUTE eine Ausbildungsabstraktion ist, die ohne Änderung von Schnittstelle oder Prozeß-Zusammenwirkungseigenschaften auch Kommunikationen zwischen ACTIVITIEs in einem einzigen Prozessor repräsentieren können und auch eine Kommunikation zwischen ACTIVITIEs repräsentieren können, die in Prozessoren vorhanden sind, die keinen gemeinschaftlichen Speicher aufweisen. Auch ist die ROUTE nur eine mögliche Form der IDA-Kommunikation, und andere Ausbildungen werden oft benötigt, um spezielle Anwendungserfordernisse zu erfüllen.
Die Schnittstellen nach einer ROUTE können entweder verfahrensorientiert oder datenorientiert sein, und in jedem Fall werden einzelne Elemente eingefügt oder extrahiert, und sie durchlaufen die ROUTE unverändert, d.h. die Arbeitsweise der Kommunikation über einer ROUTE hat überhaupt keine semantische Wirkung. Es gibt jedoch verschiedene dynamische Möglichkeiten:-
a. Voll asynchron. Die ROUTE ist hinsichtlich ihrer Wirkung ein POOL, wo Schreib- und Lese-ACTIVITIEs Daten zu jeder Zeit einfügen oder auslesen können, und diese Operationen können von irgendeiner Dauer sein. Das Kommunikationsprotokoll ist jenes von vier Schlitzmechanismen (vergleiche europäisches Patent Nr. 029287), und Datenkohärenz und Frische werden garantiert. Dies ist als fs_route bekannt.
b. Bedingt asynchron. Die ROUTE ist in ihrer Wirkung ein POOL, der ein pendelndes Pufferprotokoll betätigt. Die Datenkohärenz ist garantiert unter der Voraussetzung, daß die Dauer der Lesevorgänge immer kleiner ist als das Intervall zwischen den Schreibvorgängen und umgekehrt. Dies ist als ts_route bekannt.
c. Lose synchron. Die ROUTE ist in ihrer Wirkung ein Zweielementen-MASCOT-Standard-CHANNEL. Hier wird eine Nachricht geliefert, die mit einer begrenzten Pufferung hindurchläuft. Dies ist als bb_route bekannt.
d. Voll synchron. Diese ROUTE wird in ihrer Wirkung als Rendezvous zwischen den kommunizierenden Verfahren betätigt. Hier wird die Möglichkeit des Durchlaufs einer Nachricht geliefert, wobei keine scheinbare Pufferung stattfindet (obgleich die ADPM-Raumerfordernisse für lose und voll synchrone Formen identisch sind). Dies ist als rv_route bekannt.
Wie bereits erwähnt, wird ein gegebenes CEC gewählt, wenn die ihm eigene Nummer im Datenfeld einer speziellen Schreiboperation auftritt (gleichzeitig werden sämtliche anderen CECs abgewählt). Zusätzlich zur Chip-Zahl wird bei dieser Schreiboperation eine Kanalnummer gewählt. Jede Seite des gegenwärtigen Chips enthält 16 Kanäle, wobei jede Seite eines jeden Kanals die Logik enthält für:
a. Zähler (zwei Bit) Schritte
b. Zähler (zwei Bit) Vergleich
c. Übertragung Stim (multipliziert) X 2
d. Empfang Stim (gemultiplext) X 2
e. Zweischlitz-Asynchron-Senden
f. Zweischlitz-Asynchron-Empfang
g. Vierschlitz-Asynchron-Senden
h. Vierschlitz-Asynchron-Empfang
Diese Logik unterstützt:-
a. 16 X bb_route oder rv_route links nach rechts oder rechts nach links. Die CEC-Logik ermöglicht insgesamt 16 mögliche Synchron-ROUTEn (bb_route oder rv_route), von denen jede entweder Daten in der einen Richtung oder der anderen Richtung durchlaufen läßt. Die Wahl der Type der ROUTE und die Richtung werden überprüft, wenn die CEC-Logik der Anwendung der Kommunikationsfunktionen zugeordnet wird. Die Zählerschritte und die Zwischenprozessor-Stims für jeden Kanal werden auf dem Chip integriert, um die kompakteste Arbeitsweise zu gewährleisten (vergleiche unten).
b. 16 x stim_only, links nach rechts UND rechts nach links. Es wird eine weitere 16-Zwischen-Prozessoranregung in beiden Richtungen durchgeführt, um eine zusätzliche synchrone ROUTE (durch Software) aufzubauen.
c. 16 X ts_route und fs_route, links nach rechts UND rechts nach links. Die CEC-Logik ermöglicht 16 voll asynchrone und 16 bedingt asynchrone ROUTEn in beiden Richtungen, d.h. insgesamt 64 ROUTEn.
Die Chip- und Kanal-Wähloperation, die zu Beginn eines jeden Kommunikations-Verfahrens oder eines jeden Datenzugriffs erforderlich ist, benutzt das CEC und stellt auch den "Modus" des Chips so ein, daß er die jeweiligen individuellen Operationen durchführen kann, um ein spezielles Kommunikationsprotokoll zu unterstützen. Dieser "Modus" ist wie folgt definiert:-
a. TYPE mode = (stims, fs_rd, fs_wr, init, ts_wr, ts_rd, test, sync);
Die Wähloperation kann nunmehr wie folgt geschrieben werden:-
a. PROCEDUR cec_select (chip : 0..7; chan : 0..31; m : mode); der Chip-Parameter liegt im Bereich 0..7, weil das gegenwärtige CEC die Wahl von 1 aus 8 Chips ermöglicht (alle mit der gleichen Adresse). Der chan-Parameter liegt im Bereich 0..31, weil die Übertragungs und Empfangs-Anrege- Möglichkeiten 32 Kanäle breit sind; 16 Stims in jeder Richtung sind eng jeder Zählstufenlogik zugeordnet, wobei weitere 16 in jeder Richtung stim_only unterstützen.
Alle Typen von ROUTE erfordern, daß ein Datenraum in dem ADPM zugeteilt wird, der dem CEC zugeordnet ist. Die vernünftig große Zahl und Variation der ROUTE-Typen, die vom CEC unterstützt werden, ermöglichen eine beträchtliche Flexibilität in der Wahl der ROUTEn. Ebenso wie die KEC- und CEC-Operationen werden alle in einem einzigen Speicherzugriff durchgeführt.
Das CEC liefert eine Zahl von Operationen, um ein voll asynchrones Vierschlitz-Protokoll zu unterstützen:-
a. PROCEDUR cec_fs_rd_pr1; dies ist die Arbeitsweise, die ein Schlitzpaar zum Lesen wählt.
b. PROCEDUR cec_fs_rd_pr2; dies ist die Operation, die den Schlitz innerhalb des Paares zum Auslesen wählt.
c. FUNCTION cec_fs_rd_slot : 0..3; dies ist die Operation, die die Zahl des Schlitzes zurückführt, der als nächstes gelesen wird. Dies ist abhängig von den Ergebnissen der vorherigen zwei Operationen, die beide vollständig asynchron sind, und demgemäß besteht theoretisch die Gefahr der Metastabilität. In der Praxis jedoch sind bei den Computergeschwindigkeiten, bei der Auslegung der Chips und bei der Verzögerung vor Auslesung der Schlitznummer derart, daß die Metastabilität wirksam eliminiert wird.
d. PROCEDUR cec_fs-wr-pw1; dies ist die Arbeitsweise, die den Schlitz anzeigt, der die letzten Daten in dem gewählten Paar enthält und der auch den Schlitz in dem gewählten Paar bestimmt, der als nächstes geschrieben wird.
e. PROCEDUR cec_fs_wr_pw2; dies ist die Operation, die jedes Paar anzeigt, das die letzten Daten enthält und das jenes Paar wählt, das als nächstes geschrieben wird.
f. FUNCTION cec_fs_wr_slot; dies ist die Operation, die die Zahl der Schlitze zurückführt, die als nächstes geschrieben werden. Dies ist abhängig von den Ergebnissen der vorherigen zwei Operationen, von denen die zweite potentiell asynchron ist und daher theoretisch der Gefahr der Metastabilität ausgesetzt ist. In der Praxis wird durch die Ausbildung des Chips und das Verfahren der Benutzung diese Gefahr eliminiert.
All dies wird auf dem Chip, dem Kanal und dem Modus durchgeführt, vorgewählt durch cec_select.
Eine voll asynchrone ROUTE erfordert, daß ein geeignetes Vierschlitzfeld in dem ADPM deklariert wird, und wir nehmen an, daß die Daten, die übertragen werden, von der Type DATA sind. Die ROUTE kann so wie folgt repräsentiert werden :
Die Lese- und Schreiboperationen veranschaulichen das Zusammenwirken mit dem CEC. Hierdurch wird nicht der Weg angezeigt, auf dem die geeigneten Chip- und Chan-Parameter den cec_select-call zugeordnet sind; dies geschieht durch die Schaltungsaufbau- Software und liegt jenseits des Rahmens dieser Veröffentlichung. Ein weiterer wichtiger Punkt betrifft die Installation, und es ist notwendig zu gewährleisten, daß das Datenfeld in dem ADPM so initialisiert ist, daß jedes Auslesen erfolgt, bevor das erste Einschreiben nicht fehlerhafte Werte empfängt.
Das konditional asynchrone Zweischlitz-Protokoll hat eigene spezielle Operationen. Auf der Leseseite gibt es eine Operation, um den Schlitz zu wählen und eine, um die Zahl des nächsten zu lesenden Schlitzes zurückzuführen. Auf der Schreibseite werden die Anzeige der letzten Daten und die Rückführung der Schlitzzahl zum Schreiben in einer einzigen Operation kombiniert. Dies bedeutet, daß die Schreibprozedur die Schlitzzahl zwischen dem Aufrufen erinnern muß (angezeigt durch die eigene Variable weiter unten). Die ROUTE kann so wie folgt repräsentiert werden (unter der Annahme einer geeigneten Initialisierung und Parameterbildung von cec_select) :
Der Mechanismus zur Behandlung von Stims zwischen den Prozessoren umfaßt CEC und exekutive Software-Funktionen. Es gibt zwei Pegel für äußere Stim, nämlich einen Primärpegel und einen Sekundärpegel. Primär-Stims werden durch CEC-Operationen auf einer Seite des Chips erzeugt und über die andere übertragen, um auf dem KEC gehalten zu werden, wo sie in die Tabelle eingeführt werden und eine ACTIVITY erzeugen können, um zu laufen (siehe oben). Es gibt 32 Sekundär-Stims, die jedem Primär-Stim zugeordnet sind, und es wird eine Operation vorgesehen, um sie abzufragen:-
a. FUNCTION cec_next: 0..32; dies wird benutzt, um nach Sekundär-Stims zu suchen. Die Gruppe von ausstehenden Sekundär-Stims wird bei der vorhergehenden cec_select-Operation verriegelt und jeder Kanal wird nacheinander überprüft. Wenn ein Stim gefunden ist, dann wird dessen Zahl zurückgeführt und gleichzeitig wird es gelöscht. Wenn keine weiteren Sekundär-Stims vorhanden sind, dann wird die Zahl 32 zurückgeführt.
Die Operation wird durch eine exekutive ACTIVITY benutzt, deren Funktion darin besteht, das Sekundär-Stim über einen geeignten control_node zu schicken, wo er wiederum eine Anwendungs-ACTIVITY verursacht, um tabelliert zu werden. Dies kann in der folgenden Weise repräsentiert werden :
Für jedes CEC muß eine exec ACTIVITY installiert werden, und der ursprüngliche Zusammenhang muß in das Kontext-Sicherungsfeld gesetzt werden, so daß es als Ergebnis des ersten äußeren geeignten Primär-Stim tabelliert wird. Danach wird jeweils abgewartet, bis das Abfragen der Sekundär-Stims vollendet ist und eine Neutabellierung der relevanten Anwendungs-ACTIVITIEs über das xstrim-Feld bewirkt wird. Natürlich besteht eine Ungewißheit bezüglich der Zeit, die zwischen dem Anstieg eines äußeren Stim in einem Prozessor und seiner Benutzung zur Tabellierung einer Aktivität in einem anderen verläuft. Die äußere Grenze dieser Verzögerung ist aus der Kenntnis der längsten slice-Zeit berechenbar (d.h. dem Intervall zwischen wieder-tabellierten Punkten) bei allen ACTIVITIEs in einem Prozessor zusammen mit den slice-Zeiten der anderen ACTIVITIEs auf dem Pegel der höchsten Priorität. Die xstim-declaration nimmt eine vollständige Komplementierung von 8 CECs mit einem Bedarf von 32 notwendigen Kanälen an. Es ist extrem unwahrscheinlich, daß diese Fähigkeit jemals von einem einzigen Prozessor durchgeführt werden könnte, und der Raum, der für diese control _nodes erforderlich ist, würde auf gerade jenem gehalten werden, der für die Anwendung erforderlich ist.
Die synchronen ROUTEn zwischen benachbarten Prozessoren machen Gebrauch von der inter processor stim-Möglichkeit wie sie gerade beschrieben wurde, und zusätzlich wird dies durch die CEC-Logik in Form von zwei Bit-Zählern gestützt, zusammen mit Zählschritten und Testoperationen:-
a. FUNCTION cec_inc_stim; dies erhöht die Zählung für diese Seite (d.h. von wo die Operation durchgeführt wird) des gewählten Signals auf dem gewählten Chip, und es wird ein äußeres Stim (beide Pegel) erzeugt. Eine Zahl in dem Bereich 0..1 wird zurückgeführt, und dies ist der neue Zählwert MOD 2, was den Schlitz für den nächsten Zugriff für die Datenübertragung anzeigt.
b. FUNCTION cec_sync_p0; dies führt zu 0 zurück, wenn der Zähler auf dieser Seite gleich ist dem Zähler auf der anderen Seite plus Null, d.h. die beiden Zähler gleich sind, sonst wird auf 1 zurückgeführt.
c. FUNCTION cec_sync-p2; dies führt auf 0 zurück, wenn der Zähler auf dieser Seite gleich ist dem Zähler auf der anderen Seite plus Zwei; sonst wird nach 1 zurückgekehrt.
Die Zähler durchlaufen jeweils den Bereich 0..3 und werden benutzt, um die volle und die leere Bedingung in einem Zweischlitz-MASCOT-Standard-CHANNEL anzuzeigen. Die Initialisierung der Zähler wird unter Benutzung einer Operation bewirkt, die die Zähler fortschaltet, ohne ein Stim zu erzeugen. Für eine gebundene Puffer-ROUTE werden die Zähler auf Null initialisiert und die xstim-Feldelemente (control_nodes), die einer synchronen ROUTE zugeordnet sind, müssen in den "unstimmed"-Zustand initialisiert werden. So kann die ROUTE repräsentiert werden (unter der Annahme einer geeigneten cec_select-Parameterbildung und unter der Voraussetzung, daß die eigenen Variablen auf Null initialisiert sind):
Die Durchführung einer vollsynchronen ROUTE hat sich als sehr ähnlich einer lose synchronen ROUTE erwiesen. Das CEC muß so initialisiert werden, daß der Zähler auf der Schreibseite 1 ist und der Zähler auf der Leseseite 0 ist. In gleicher Weise muß die ic-OWN-Variable auf 1 initialisiert werden. Diese ROUTE wird wie folgt repräsentiert:
Es ist nunmehr ersichtlich, daß die Zählerlogik auf jeder Seite des CEC benutzt werden kann, um die ROUTEn in der einen oder anderen Richtung zu stützen (aber nicht in beiden) und daß jede ROUTE entweder als bb_route oder rv_route programmiert werden kann. Die eingebaute Software würde dann bestimmen, welche von diesen Optionen gewählt wird.
Wir haben nunmehr gesehen, wie die Exekutiv-Chips und die Software von niedrigerem Pegel benutzt werden können, um die Echtzeit-Schaltungen durchzuführen. Wir wollen nunmehr kurz die Art und Weise überprüfen, auf die Ausbildungen in einer Form erzeugt werden können, die geeignet ist zum Laden in eine derartige Exekutionsumgebung.
Das beschriebene und dargestellte DIA-System wird vorzugsweise in Verbindung mit einer Software/Digital-Systementwicklung benutzt, die im folgenden als acronym DORIS (Data Orientated Requirements Implementation Scheme) bezeichnet wird. Das Wesentliche von DORIS liegt in der Datenleitung zwischen Funktionen und Komponenten in einem System. Der Austausch von Daten ist ein eigenes Thema, und durch Anwendung dieses Prinzips von der Erfordernis-Analyse nach der Durchführung wird eine Nachführung durch den Entwicklungsprozeß gewährleistet. Ein sehr wichtiger weiterer Vorteil besteht in der Möglichkeit, eine vorgeschlagene Anordnung im Hinblick auf ihre Durchführungseigenschaften zu analysieren. Dies rührt von der verteilten Natur der Annäherung her, wodurch sofort die Bezugnahme auf dynamisch gemanagte Gemeinschaftsquellen vermindert wird, und dies ist eine bekannte Gefahr und eine Gefahr, die nicht zufriedenstellend in Systemen ausgeschaltet werden kann, wo zahlreiche nicht verbundene Verarbeitungsfunktionen in einer kleinen Zahl leistungsfähiger und komplexer Computer verarbeitet werden sollen und wo die Kommunikationen auf einer kleinen Zahl von Verbindungen hoher Bandbreite gemultiplext werden.
Das Wesen der DORIS-Funktion ist in Fig. 3 dargestellt. Die Erfordernis-Analyse führt dazu, daß die System-Definition des oberen Pegels unter Benutzung von CORE (COntrolled Requirements Expression) durchgeführt wird, ein Verfahren, welches einen großen Wert legt auf die Identifizierung der Information, die zwischen genau definierten Funktionen durchgeführt wird. Eine Information über CORE findet sich in "CORE - A method für Controlled Requirements Specification" von G P Mullery, veröffentlicht in "Proceedings of Fourth International Conference on Software Engineering", 1979, Seiten 126-135. Die Auslegungsphase wird in Audrücken einer adaptierten Form von MASCOT durchgeführt. Die prinzipielle Erstreckung auf MASCOT ist die Einführung von Typen-Parametern für templates (eine "template" ist eine Auslegungsbeschreibung, die benutzt wird, um Komponentenelemente in einem System einzuführen). Die primäre Motivierung für diese Erstreckung besteht darin, daß eine allgemeine Auslegung für ROUTEn möglich wird, anstatt neue ROUTEn-Templates für jede Art von Datenübertragungen auf diese Weise zu schaffen. Die Installierungsphase basiert auf DIA, wie oben beschrieben.
Fig. 3 weist zwei weitere Blöcke auf. Prototyping, Modelling, Simulation und Animations unterstützen den kreativen Prozeß der Definition und Ausbildung und mit der Investigation der vorgeschlagenen Lösungen durch experimentelle Versuche. Analyse, Verification, Validation und Testing sind die Mittel, durch die das Produkt der Entwicklungsphase zur Anpassung an die vorherigen Phasen benutzt werden kann.
Die Echtzeit-Schaltung ist eine Form der Ausbildungsabstraktion, die im Prinzip frei ist von Implemantations-Betrachtungen. In der Praxis wird die Ausbildung auf dem Feld der Echtzeit eingebettet in einem Mehrfachprozessor-System, wahrscheinlich ebenso schwerwiegend durch Durchführungsbetrachtungen beeinflußt und durch die Art und Weise, auf die die Ausbildung in verfügbare Exekutionsquellen überführt wird. Nichtsdestoweniger gelangen wir zu einer maximalen Abstraktion für die Klarheit, Flexibilität, generelle Aufrechterhaltung und einer Wiederverwendung usw., die hierdurch geschaffen werden.
Eine DORIS-Ausbildung drückt sich als reine Schaltung aus, die keine bestimmte Beziehung zu der Exekutions-Hardware hat. Die Exekutions-Umgebung wird getrennt beschrieben unter Benutzung einer Hardware-Beschreibungssprache, die die Möglichkeit schafft, daß die verfügbaren Prozessoren und Speicher und ihre Verbindungen definiert werden können. Dann wird eine Auslegungsbeschreibung benutzt, um die Schaltung auf die Hardware zu beziehen. Dieser Schritt ergibt einen beträchtlichen Vorteil im Hinblick auf die Entwicklung wirksamer Analyse-Durchführungs-Werkzeuge.
Die DORIS-Aufzeichnungsregeln sind sehr einfach:
a. eine ACTIVITY muß in einem einzigen Prozessor enthalten sein;
b. eine IDA-Ausbildung muß für jede Zwischen- ACTIVITY-Kommunikation existieren, die durch die Planung der ACTIVITIEs in der Hardware bewirkt wird.
Die zweiten Regeln treten auf, weil die Umsetzung allein in Ausdrücken der Lokalisierung der ACTIVITIEs ausgedrückt ist mit der erforderlichen Form der IDAs in Ausdrücken ihrer Verteilung in der Hardware, was hiervon abgeleitet ist. Wenn beispielsweise ein Schreiber mit einem Leser über eine ROUTE kommuniziert, hängt die erforderliche Ausbildung des IDA davon ab, ob die beiden Prozesse in dem gleichen Prozessor oder in benachbarten Prozessoren durchgeführt werden, oder ob die Prozesse noch weiter auseinanderliegen. Das DORIS-toolset behandelt diese Situation durch eine Schema-Substitutionstechnik. In Ausdrücken der Schaltung bleibt die äußere Beschreibung und die Funktion der Anwendung die gleiche, welche Schablone auch ersetzt wird, jedoch die innere Ausbildung unterscheidet sich, und es können zusätzliche Schaltungsverbindungen benötigt werden, um diese Möglichkeiten durchzuführen.
Es wurde bereits erwähnt, daß die Zwischenprozeß-Eigenschaften einer ROUTE die gleichen bleiben, unabhängig davon, wie die ROUTE in die Exekutions-Hardware übertragen wird. Dies bedeutet, daß die asynchronen Formen asynchron bleiben mit der gleichen Art der zeitlichen Begrenzungen oder des Fehlens hiervon. In gleicher Weise bleiben die synchronen Formen die gleichen in Ausdrücken der Pufferung oder Rendezvous-Charakteristiken. Jedoch erhöht sich die Informationsausbreitungs- Verzögerung, wenn die ROUTE über weitere Bereiche verteilt wird. Es ist nur die allgemeine Natur des Zusammenwirkens, die konstant bleibt, aber dies ist wichtig, weil hierdurch die Tür für generalisierte Zeitgeber-Analysatoren geöffnet wird, die in Ausdrücken von Zeitparametern arbeiten können, die in direkter Weise durch Betrachtungen der Exekutionsumgebung und der Schaltungsverteilung bestimmt werden.
Jedes KEC 46 und jedes CEC 48 kann eine kundenspezifische integrierte Schaltung aufweisen. Um eine Unabhängigkeit des Prozessors zu bewirken, können die Chips CEC und KEC mit der TTL-Technik kompatible Eingänge und Ausgänge aufweisen, und der Zugriff kann über konventionelle Speicherlese- und Schreiboperationen erfolgen.
Das KEC stützt die kooperative Planung der ACTIVITIEs innerhalb eines einzigen Prozessors unter der Steuerung der Software und behandelt die asynchronen äußeren Anregungen, die benutzt werden können, um die vorher leeren Unterbrechungen zu ersetzen, die in herkömmlichen Mikroprozessoren benutzt werden. Das KEC enthält eine Aktivierungsmatrix und eine Welligkeits-Suchlogik, um die nächst tablellierbare Aktivität gegen eine feste Regelanordnung zu identifizieren. Die Activities sind so ausgebildet, daß sie unter Software- Steuerung tabellierbar und abrufbar sind. Die asynchronen äußeren Anregungen werden auf dem Chip verriegelt, aber dies können nur Haupt-Activities in der Matrix unter der Software- Steuerung sein. Diese Verklinkungen können erst gelöscht werden, wenn sie sicher eine Activity in der Matrix eingeleitet haben. Das KEC, das ein unkonventionelles Lese- Stroboskop benutzt, damit die Chip-Logik parallel und asynchron arbeiten kann, und zwar einen Schritt vor dem Prozessor. Das KEC benutzt eine neuartige Ausbildung der "round robin"- Element-Suchlogik innerhalb der prioritisierten Nachforschung, wenn die nächste Activity gewählt wird.
Wie erwähnt, stützt jedes KEC 47 die Planung der Verarbeitungsregeln, die mit Activities bezeichnet werden für einen individuellen Mehrfach-Prozessor. Hierdurch wird auf Anforderung die Zahl der nächsten Activity während der Verarbeitungszeit unter der Exekutiv-Software-Steuerung in Gegenwart äußerer asynchroner Anregungen geliefert.
Beispielsweise könnte jedes KEC 47 einen Träger für vierundsechzig Activities stützen, von denen acht äußeren Anregungen zugeordnet sind. Die Activity-Zahlen können so programmiert werden, daß sie als Kandidaten zur Planung eingeschlossen oder ausgeschlossen sind, aber es werden die nächsten Aktivitätszahl-Wählregeln fixiert. Es gibt acht Prioritätspegel mit acht Activity-Nummern für jede Priorität. Die Suchlogik identifiziert die nächste eingeschlossene Aktivitäts-Zahl auf einer "round-robin"-Basis im höchsten Prioritätspegel, der eine eingeschlossene Aktivitäts-Zahl enthält.
Das CEC ermöglicht eine asynchrone Hardware-Kopplung zwischen Prozessor-Paaren, wobei jeder Prozessor innerhalb eines unabhängigen Zeitrahmens arbeiten kann. Jedes CEC hält die Variablen und manipuliert diese unter Software-Steuerung von jedem Prozessor und erzeugt eine asynchrone äußere Anregung auf jeder Seite. In Verbindung mit einem asynchronen Dual-Port- Memory (ADPM) kann jedes CEC viele parallele asynchrone oder synchrone Software-Kommunikations-Routen stützen, die in dem ADPM zwischen den Prozessor-Paaren aufgebaut werden.
Jedes CEC 48 kann ein Benutzer-VSLI-Chip aufweisen, das Variable und eine Logik enthält, um die gegenwärtige Benutzung verschiedener Typen von Gemeinschaftsspeicher-Kommunikations- Mechanismen zwischen einem Paar asynchron arbeitender Prozessoren zu unterstützen. Die Mechanismen steuern die Schreib- und Lesevorgänge in den Datenfeldern, die als Schlitze bezeichnet werden und in dem Asynchronous-Dual-Port-Memory (ADPM) 46 angeordnet sind, das parallel zu dem CEC geschaltet ist. Beispielsweise kann das CEC so ausgebildet sein, daß die gegenwärtige Benutzung von sechzehn Zwischenprozessor- Kanälen gestützt wird, wobei jeder Kanal die konkurrente Benutzung stützt von: zwei Vierschlitz-Mechanismen (einem in jeder Richtung); zwei Zweischlitz-Mechanismen (einem in jeder Richtung); und einem Nachrichten-Durchlauf-Mechanismus (der in jeder Richtung benutzt werden kann). Es kann eine Behandlung von vierundsechzig Anregungen (zweiunddreißig in jeder Richtung) vorgesehen werden.
Vorzugsweise besitzt jedes CEC zwei komplementär unabhängige Prozessor-Schnittstellen, die mit L und R (links und rechts) bezeichnet sind und die eine Verbindung zwischen zwei asynchron arbeitenden Prozessoren ermöglichen, ohne daß Restriktionen bezüglich eines gegenseitigen Zugriffs bestehen.
Das CEC kann zwischen zwei Prozessoren geschaltet werden, die unabhängige Taktgeber aufweisen. Jeder Prozessor hat einen freien Zugriff zu seiner Seite des CEC, ohne daß es notwendig wäre, einen Hardware-Ausschluß, eine Arbitration oder eine Synchronisation durchzuführen. Das CEC ist in zwei Hälften strukturiert, wobei jede Hälfte die jedem Prozessor zugeordnete Schaltung enthält. Dies besteht aus Stimulationsverklinkungen, gemeinsamen Bit-Variablen und einer Logik. Jede Stimulus-Verriegelung kann nur von einer Seite gesetzt werden und kann nur kopiert werden, wenn eine Identifizierung nach dem Prozessor stattfindet. Die Verriegelungen, die die gemeinsamen Bit-Variablen halten, können nur von einer Seite gesetzt und gelöscht werden, aber die Logik kann von beiden Seiten zugreifen. Die Logik ermöglicht es dem CEC, die kopierten Stimulus-Verriegelungen zu suchen und die gespeicherten Variablen in spezieller Weise unter Software- Steuerung zu manipulieren und den asynchronen äußeren Stimulus zu erzeugen.

Claims

1. Verteiltes Computersystem mit den folgenden Merkmalen:-

mehrere asynchrone Computer-Einheiten, von denen jede mit einem Datenprozessor (61) und einem privaten Datenspeicher (43) versehen ist, der jeweils mit dem Prozessor über eine private Datenleitung (42) verbunden ist;

einen Gemeinschafts-Datenspeicher (46), der Zugriffs- Ports aufweist, die mit jeweils einem Computer über zugeordnete private Datenleitungen verbunden sind, damit jede Computer-Einheit in der Lage ist, mit irgendeiner anderen Computer-Einheit über jeweils einen Zweiweg-Datenweg zu kommunizieren, der ein jeweils individuelles Feld des Gemeinschafts-Datenspeichers umfaßt; und

Kommunikations-Steuermittel (47, 48), die an die privaten Datenleitungen und den Gemeinschafts-Datenspeicher angeschlossen sind, um auf Steuerdaten zu antworten, die vom Prozessor irgendeiner Computer-Einheit ausgegeben wurden, um die Kommunikation über einen Leitweg einzuleiten, der vom Prozessor (41) bestimmt wird, wobei der Leitweg benutzt wird, um eine Kommunikation zwischen einem einzigen Schreibprozeß und einem einzigen Leseprozeß herbeizuführen.

2. System nach Anspruch 1, bei welchem der Gemeinschafts-Datenspeicher mehrere asynchron betätigbare Dual- Port-Speicher aufweist, und zwar jeweils einen für jede Datenroute, wobei die Kommunikations-Steuermittel mehrere Kommunikations-Steuereinheiten (48) aufweisen, die so geschaltet sind, daß sie jeweils einen der Dual-Port-Speicher steuern.

3. System nach Anspruch 1, bei welchem jede Computer- Einheit mit einer Activity-Planungs-Software programmiert wird, um einen periodischen Bezug durch den zugeordneten Prozessor nach einem vorbestimmten Speicherfeld zu initialisieren und um Activities durchzuführen, die in Abhängigkeit von einem Datensignal gewählt werden, das in dem vorbestimmten Speicherfeld befindlich ist, wobei das System Activity- Steuermittel aufweist, die betätigbar sind, um Bedarfssignale zu empfangen, die die jeweiligen Activities identifizieren, die von der betreffenden Computer-Einheit durchzuführen sind und um diese Signale in dem vorbestimmten Speicherfeld der jeweiligen Computer-Einheit zu registrieren.

4. System nach Anspruch 3, bei welchem die Activity- Steuermittel mit den Kommunikations-Steuermitteln verbunden sind, um die die Activities identifizierenden Bedarfssignale zu empfangen, einschließlich Antworten von jeder Computer- Einheit auf Kommunikations-Abfragen von anderen Computer- Einheiten.

5. System nach Anspruch 3, bei welchem die Activity- Steuermittel für jede Computer-Einheit eine jeweils individuelle Registereinheit aufweisen, die mit der Computer-Einheit über die zugeordnete private Datenleitung verbunden ist und das vorbestimmte Speicherfeld für die Computer-Einheit einnimmt.

6. System nach Anspruch 1, bei welchem der Gemeinschafts- Datenspeicher (46) und die Kommunikations-Steuermittel (48) zusammen betätigbar sind, um für irgend zwei Computer-Einheiten eine voll asynchrone Form einer Interkommunikation verfügbar zu machen, bei der jede der beiden Computer-Einheiten Zugriff zu dem jeweiligen Gemeinschaftsdaten-Speicherfeld aus irgendeiner Form von Synchronismus hat mit Zugriffen durch die jeweils andere der beiden Computer-Einheiten.

7. System nach Anspruch 6, bei welchem die Computer- Einheiten mit Activities-Planungs-Software programmiert sind und mit jeweiligen Gruppen von Software-Moduln, um die Computer-Einheiten zu veranlassen, zugeordnete vorbestimmte Activities auszuführen, wobei die Module so gewählt sind, daß sie durch die geplante Software laufen und die Module Kommunikations-Prozesse aufweisen, die betätigbar sind, um Daten sowohl zwischen den Moduln, die in der gleichen Computer- Einheit angeordnet sind, und zwischen Moduln zu überführen, die in jeweils einem von zwei verschiedenen Computer- Einheiten zugeordnet sind, und zwar über eine Zweiweg- Datenroute, die ein entsprechendes Feld des Gemeinschafts- Datenspeichers aufweist.

8. System nach Anspruch 6, bei welchem der gemeinsame Datenspeicher und die Kommunikations-Steuermittel zusammen betätigbar sind, um irgend zwei Computer-Einheiten einer weniger als voll asynchrone Form der Interkommunikation verfügbar zu machen, wobei wenigstens eine gewisse Synchronisation der Zugriffe nach dem gemeinsamen Datenspeicherfeld durch die beiden Computer-Einheiten vorhanden ist, die eine voll asynchrone Form und eine nicht voll asynchrone Form der Interkommunikation verfügbar ist, bestimmt durch die Daten, die durch die Kommunikations-Steuermittel durch jene Computer-Einheit ausgegeben wurden, die die Kommunikation eingeleitet hat.