DE69329178T2 - Simulationsgerät für Netzwerkcode - Google Patents

Description

• Die vorliegende Erfindung betrifft einen Simulator für einen Kommunikationsschichten-Code eines Netzes, der in der Folge des Textes zur Vereinfachung Netzcode (networking code im Englischen) genannt wird. Sie ist insbesondere anwendbar auf die Simulation eines Codes, der in einem Datenverarbeitungssystem-Prozessor, der den Informationsaustausch mit den verschiedenen Stationen eines Netzes steuert, ausführbar ist, wobei dieses Netz beispielsweise ein Netz des Typs FDDI (von der ANSI unter dem Zeichen X3T9-5 und von der ISO, Internationale Organisation für Normung, genormt) sein kann.
• Es ist bekannt, daß die Kommunikationsnetze aus mehreren Terminals oder Stationen gebildet sind, die über eine Übertragungsverbindung, die einen Übertragungsträger enthält, der beispielsweise im Fall eines FDDI-Netzes aus Lichtleitfasern bestehen kann, untereinander verbunden sind. Ein Rechner, der mit einem solchen Netz verbunden ist, wird als Terminal betrachtet.
• Es ist bekannt, daß zahlreiche moderne Telekommunikations- und Informationsnetze nach einem Referenzmodell funktionieren, das unter dem Namen OSI-Referenzmodell bekannt ist. Andere Netze können auch gemäß anderen Modellen funktionieren, die jedoch hinsichtlich der Definition der Architektur dieser Netze in Form von normierten Schichten mit dem OSI-Referenzmodell verwandt sind (dies gilt beispielsweise für die TCP/IP-Netze). So besteht die Architektur im OSI-Modell aus einem Stapel aus sieben Aktivitätsschichten, wobei die unterste Schicht (Schicht 1) der physischen Übertragung der Signale zwischen den verschiedenen Systemen über den physischen Verbindungsträger (Lichtleitfasern) entspricht, während die oberste Schicht (Schicht 7) Funktionen entspricht, die durch die Anwendungsprogramme und die Anwender des betreffenden Telematiknetzes ausgeübt werden.
• Das OSI-Modell definiert außerdem die Konzepte, mit denen die Funktion jeder Schicht beschrieben werden kann. Es sind ferner Mechanismen bekannt, die die Beziehungen zwischen benachbarten Schichten definieren, wie beispielsweise ein als "STREAMS" bezeichneter Mechanismus von der Firma AT&T, der in den im Verlauf des Textes erwähnten Dokumenten genauer definiert ist.
• Die Tendenz der technologischen Entwicklung der Netze und der Einsatz von immer mehr Terminals führen innerhalb der Rechner selbst zur Entwicklung von programmierten Kommunikationsprozessoren, die dadurch, daß sie einen Teil der Steuerung der Kommunikation der Rechnerzentraleinheit mit den anderen Netzstationen ausführen, die Last der Rechnerzentraleinheit verringern.
• Ferner ist es bei der gegebenen extrem schnellen Entwicklung der Kommunikationsnetze sowie der Datenverarbeitungssysteme notwendig geworden, verschiedenartige Rechner, die verschiedene Betriebssysteme (operating systems) verwenden, an dasselbe Netz anzuschließen.
• Der Zweck eines Kommunikationsprozessors, der auch als Datenübertragungssystem oder Verbindungsbrückeneinrichtung bezeichnet werden kann, besteht in der Anpassung der Datenübertragungsbedingungen auf dem Rechnerbus an die Übertragungsbedingungen auf dem Netz, die völlig verschieden sein können. Ferner ermöglicht dieser Kommunikationsprozessor den Dialog der Rechnerbetriebssysteme untereinander. Insbesondere ermöglicht er den Dialog der verschiedenen Kommunikationsschichten des Betriebssystems eines ersten Rechners mit den verschiedenen Kommunikationsschichten der Betriebssysteme anderer mit demselben Netz verbundenen Rechner.
• Der Kommunikationsprozessor muß folglich innerhalb seines Betriebssystems selbst einen Kommunikationsschichten-Code enthalten, der ihm den Dialog sowohl mit dem Betriebssystem des Rechners, mit dem er verbunden ist, als auch mit den anderen an das Netz, beispielsweise des Typs FDDI, angeschlossenen Rechnern ermöglicht.
• Es ist beispielsweise ein solcher Kommunikationsprozessor, der auch als Datenübertragungssystem bezeichnet wird, bekannt.
• Ein solcher Kommunikationsprozessor, NCC genannt, dient zur Steuerung der Datenübertragung zwischen einem Rechner HOST, der mit einem internen Bus PSB versehen ist und dessen Betriebssystem mit OS bezeichnet wird, und einem Netz RE, beispielsweise des Typs FDDI. Der Bus PSB ist beispielsweise ein Bus, der MULTIBUSII (eingetragenes Warenzeichen der Firma INTEL) genannt wird und nach der Norm IEEE 1296 (Institute of Electrical and Electronic Engineers) normiert ist.
• Der NCC-Kommunikationsprozessor enthält die folgenden drei wesentlichen Teile:
• - Der erste Teil, der als GPU (englische Abkürzung von General Purpose Unit) bezeichnet wird, entspricht beispielsweise dem im französischen Patent Nr. 2 679 352 beschriebenen Modell. Dieser Teil ist mit einem Betriebssystem, beispielsweise des im französichen Patent Nr. 2 679 351 beschriebenen Typs, versehen. Das Ziel dieses Teils GPU ist es, einerseits die Initialisierung der Kopplereinheit NCC und anderseits den Dialog mit dem Rechner HOST über den Bus PSB unter Berücksichtigung der Normen der Verwendung dieses Busses und der Übereinstimmung mit den Eigenschaften des Betriebssystems OS des Rechners HOST sicherzustellen. Ferner stellt der Teil GPU den physische Datentransport zwischen dem Bus PSB und dem zweiten Teil DEA sicher, der als Adaptereinrichtung bezeichnet wird und mit dem Netz RE direkt verbunden ist. Die Funktion dieses Teils DEA wird im folgenden beschrieben.
• - Der Teil DEA ist beispielsweise von dem Typ, der, den Hardwareteil betreffend, im Patent Nr. 2 650 412 mit dem Titel "dispositif passerelle de connexion d'un bus d'ordinateur a un reseau fibre optique en forme d'anneau" und, den Softwareteil betreffend, in dem französischen Patent Nr. 2 695 740 beschrieben ist. Dieser Teil DEA stellt den physischen Datentransport zwischen dem Teil GPU und dem Netz RE sowie die physische Verbindung zum Netz sicher.
• - Der dritte Teil, PPA genannt, ist eigentlich ein Kommunikations-Coprozessor, der insbesondere zur Steuerung der verschiedenen Telekommunikationsschichten des OSI-Modells oder auch des TCP/IP-Modells vorgesehen ist. Sowohl in bezug auf das OSI-Modell als auch auf das TCP/IP-Modell stellt der Teil PPA die Steuerung der Kommunikationsschichten C&sub4;, C&sub3;, C&sub2;, d. h. der Übertragungsschicht, der Netzschicht und der Datenverbindungsschicht, sicher.
• Die Kommunikationsschichten C&sub2; bis C&sub4; kommunizieren untereinander mit Hilfe von Grundfunktionen, die den Dialog zwischen zwei benachbarten Schichten ermöglichen. So kommunizieren die Schichten C&sub2; und C&sub3; untereinander über die Funktionsmenge ST&sub2;, während die Schichten C&sub3; und C&sub4; über die Funktionsmenge ST&sub3; kommunizieren. Ferner kommuniziert C&sub4; mit der Umgebung, d. h. beispielsweise mit den externen Anwendungen, über eine Schnittstelle SH.
• In einer bei der Erfindung bevorzugten Ausführungsform sind die Funktionsmengen ST&sub2;, ST&sub3;, SH Funktionen, die in der heutigen Praxis unter dem Namen STREAMS bekannt sind. Diese Standardfunktionen sind beispielsweise in den folgenden Dokumenten definiert:
• - UNIX System V Release 4-STREAMS Programmer's Guide, AT&T issue 1
• - UNIX System V Release 3.2 - STREAMS Programmer's Guide, AT&T (ISBN: 0-13-944810-1): 1989
• In dem in Fig. 1 gezeigten Ausführungsbeispiel läuft eine Nachricht, wenn der Rechner HOST diese an das Netz RE schickt oder auch wenn diese vom Netz RE kommt, über einen FIFO-Spei cher, nämlich FF&sub1;, zu den Schichten C&sub2; bis C&sub4;, wobei diese Nachricht vom Teil PPA über den FIFO-Speicher FF&sub2; im ersten Fall an die Adaptereinrichtung DEA und im zweiten Fall an die GPU übertragen wird. Wenn es sich um die Annahme einer vom Rechner HOST stammenden Verbindungsanforderung handelt, kommt diese Anforderung über die Schnittstelle SH, während die Nachrichten, wenn es sich um das Senden von Nachrichten an alle oder einen Teil der an das Netz angeschlossenen Stationen handelt und die Verbindung bereits hergestellt ist, direkt zu den Schichten C&sub4; bis C&sub2; laufen.
• Die Kommunikationsschichten C&sub2; bis C&sub4; und die verschiedenen Funktionen ST&sub2;, ST&sub3; und SH sowie das zugeordnete Betriebssystem (jenes des Teils PPA) bilden eine Gesamtheit, die als Kommunikationsschichten-Code CC oder als Netzcode oder auch als Kommunikationskern bezeichnet wird.
• In der heutigen Praxis muß bei der Entwicklung von Kommunikationsprozessoren wie etwa des NCC darauf gewartet werden, bis die Hardwareunterstützung zur Entwicklung des Netzcodes realisiert ist, was einen Zeitverlust mit sich bringt. Seine Entwicklung wird deshalb entsprechend verzögert.
• Konzepte zur Codesimulation sind bekannt. Eines von diesen ist in dem Dokument "Hosted software for microcomputers" von D. E. WREGE, veröffentlicht im Januar 1982 in der Zeitschrift COMPUTER DESIGN, Bd. 21, Nr. 1, Seiten 175-179 beschrieben.
• Es besteht im Entwurf einer für einen Mikrorechner vorgesehenen Anwendung auf einem Großrechner. Die Anwendung wird in einer hochentwickelten oder problemorientierten Sprache (high order language) entworfen. In dieser Weise nutzt der Entwickler die leistungsfähige Umgebung des Großrechners, d. h. dessen Entwicklungsmodule und einen Kreuzkompilierer (cross-compiler), aus, der die in HOL, einer dem Mikrorechner eigenen Sprache, geschriebene Anwendung zurückübersetzt.
• Außerdem sind Protokollsimulationstechniken bekannt. Eine von diesen ist in einem von I. CHLAMTAC 1986 in der Zeitschrift MICROPROCESSING AND MICROPROGRAMMING, Bd. 18, Nr. 1-5, Seiten 145-152 veröffentlichten Artikel beschrieben.
• Sie besteht aus einer Simulationsumgebung, die Kommunikationsprotokollmodelle, die zu entwerfen sind, verwendet. Diese Modellsimulation ermöglicht das Fertigstellen oder Konfigurieren eines Protokolls. Es handelt sich somit nicht um die Simulation eines Kommunikationscodes.
• Die vorliegende Erfindung ermöglicht das Beseitigen dieser Nachteile, indem der Kommunikationskern CC auf einen externen Rechner portiert wird und dieser Kern als Anwendung für das Betriebssystem dieser Maschine betrachtet wird.
• Gemäß der Erfindung ist der Simulator eines Kommunikationsschichten-Codes für den Zugriff auf ein Netz wie durch Anspruch 1 definiert beschaffen.
• Weitere Merkmale und Vorteile der vorliegenden Erfindung werden in der folgenden Beschreibung deutlich, die beispielhaft und nicht beschränkend gegeben wird und sich auf die beigefügte Zeichnung bezieht, worin:
• Fig. 1 die verschiedenen wesentlichen Bestandteile eines Kommunikationsprozessors in Erinnerung ruft,
• Fig. 2 die wesentlichen Bestandteile des erfindungsgemäßen Simulationswerkzeugs zeigt,
• Fig. 3 eine Ausführungsform der Erfindung genauer zeigt, deren in Fig. 2 gezeigte wesentliche Bestandteile auf den Entwurf eines Kommunikationsprozessors, der ein beliebiges Betriebssystem verwenden kann, bezogen sind,
• Fig. 4 eine spezielle Ausführungsform des erfindungsgemäßen Simulationswerkzeugs zeigt, das insbesondere beim Entwurf des Codes CC des in Fig. 1 gezeigten Teils PPA verwendet werden kann.
• Es wird nun auf Fig. 2 Bezug genommen, die die wesentlichen Bestandteile des erfindungsgemäßen Simulators (SIM) zeigt. Der Simulator besteht in der Zuordnung einer ORD genannten Maschine, einer Simulationsumgebung, nämlich Es, und Code-Testanwendungen A&sub1; bis An. Die Simulationsumgebung wird auf eine Maschine ORD portiert, die beispielsweise zum Entwurf verschiedenartiger Programme vorgesehen ist und deren Betriebssystem mit NY bezeichnet wird. In einem bevorzugten Ausführungsbeispiel der Erfindung laufen sowohl NY als auch Es unter dem von AT&T definierten UNIX-Betriebssystem, das heute bereits weit verbreitet ist.
• Die Simulationsumgebung Es wird von NY als Anwendung betrachtet und befindet sich folglich außerhalb des Betriebssystems selbst. Falls beim Entwurf der Simulationsumgebung Es ein Fehler auftritt, betrifft dieser somit nur die Anwendung selbst, während die Maschine ORD mit seinem Betriebssystems NY weiter laufen kann und für den Entwurf anderer Anwendungen verfügbar bleibt.
• Die Simulationsumgebung Es enthält einen zentralen Kern CC, der die Kommunikationsschichten, beispielsweise C&sub2; bis C&sub4;, die in Fig. 1 gezeigt sind, nachbildet. Die Kommunikationsschichten CC enthalten genau dieselben Codezeilen wie jene, die im Teil PPA in Fig. 1 vorkommen. Der einzige Unterschied ist der, daß diese Kommunikationsschichten in die der Maschine ORD eigenen internen Sprache kompiliert werden.
• Die in CC enthaltenen Kommunikationsschichten sind genau jene, die der Anwender simulieren und testen will. Sie sind von einem beliebigen Typ, beispielsweise vom Typ OSI oder TCP/IP, LAP-D usw. Sie können sich im Verlauf der Zeit ändern, da der Anwender, den Bedürfnissen zu einem bestimmten Zeitpunkt folgend, sich vor die Notwendigkeit gestellt sieht, verschiedenartige Netzcodes zu entwerfen. Selbstverständlich kann der Kern CC zum selben Zeitpunkt verschiedenartige Kommunikations schichten oder keinerlei Kommunikationsschichten enthalten. Die Umgebung Es enthält außerdem einen Konfigurator CONFIG, der zur Inbetriebnahme des Kerns CC vorgesehen ist. Letzterer kann mit den zu Es externen Testanwendungen A&sub1;, ...A&sub1;, ...An über die Anwendungsbibliotheken L&sub1;, ...Lj, ...Lm, die ebenfalls zu Es gehören, bzw. die Bibliotheken l&sub1;, ...lk, ...lp, die zu A&sub1;, ...Ai, ...An gehören, kommunizieren.
• Die Gesamtheit dieser Bibliotheken (L&sub1; bis Lm, l&sub1; bis lp) enthält Aufrüfsysteme O&sub1;, ...Ok... Op gemäß dem UNIX-Standard. Die Anzahl m von Bibliotheken von Es (L&sub1; bis Lm) unterscheidet sich im allgemeinen von der Anzahl p der Bibliotheken 11 bis die sich wiederum von der Anzahl n der Anwendungen A&sub1; bis An unterscheidet.
• Tatsächlich können mehrere verschiedene Anwendungen wie etwa A&sub1; und A&sub2; in Fig. 2 identische Bibliotheken, hier 11, besitzen, die mit derselben Bibliothek L&sub1; kommunizieren, wodurch das Aufrufsystem O&sub1; definiert wird.
• In Fig. 2 wird angenommen, daß A&sub1; eine Bibliothek Lk besitzt, die mit Lj kommuniziert, wodurch das Aufrufsystem Ok definiert wird, während An die Bibliothek lp besitzt, die mit der Bibliothek Lm kommuniziert, wodurch das Aufrufsystem Op definiert wird.
• Falls eine Anwendung A&sub1; mit der Simulationsumgebung Es über das Aufrufsystem Ok zu kommunizieren versucht und keihe Antwort seitens der Es erhält, wird der Aufruf an das zentrale Betriebssystem NY der Maschine ORD zurückgesendet, wie dies beispielsweise die Pfeile F&sub1;, ...Fi, ...Fn in Fig. 2 bezeugen. Dies ist beispielsweise der Fall, wenn A&sub1; eine Datei zu öffnen versucht und CC dies nicht ausführt.
• Die Simulationsumgebung Es bietet eine Umgebung für die folgenden Testanwendungen an:
• - Anwendung zum unitären Test von Schnittstellen des Typs STREAMS, wobei der Begriff "unitär" hier bedeutet, daß eine bestimmte STREAMS-Schnittstelle getestet werden soll,
• - Anwendungen zum unitären Test von Kommunikationsprotokollschichten, wobei der Begriff "unitär" hier bedeutet, daß eine bestimmte Schicht getestet werden soll,
• - Anwendungen zum Test eines Schicht-Stapels, mit anderen Worten, Anwendungen zur Funktionssimulation eines Netzes. Die Umgebung Es ist konfigurierbar. Ihr Kern CC wird vom Konfigurator CONFIG gestartet. Er kann von einem im NY liegenden Diagnoseprogramm (debugger) gesteuert werden.
• Die Simulationsumgebung Es bietet allen Testanwendungen einen dynamischen Zugriff an und macht die Simulation für die verschiedenen Schichten des Kerns CC transparent, da keine einzige Codezeile des letzteren und auch keine Zeile seiner Anwendungen verändert wird.
• Die Testanwendungen können entweder, wie in Fig. 2 gezeigt wird, von einer UNIX-Befehlssprache ausgehend, direkt über verschiedene Systemaufrufe O&sub1; bis Op oder auch von einem UNIX- Standard-Anwendungsentwickler (einem beliebigen Diagnoseprogramm, das sich dem obenerwähnten unterscheidet und von NY unter UNIX bereitgestellt wird) gestartet werden.
• Die Ausführung einer Simulation des Codes CC wird Simulationssitzung genannt, während der sich die Testanwendungen dynamisch zuschalten können. Ferner können in derselben Umgebung Es mehrere Simulationssitzungen gleichzeitig bestehen.
• Jedes der Aufrufsysteme O&sub1;, ...Ok, ...OP entspricht der Semantik eines STREAMS-Systemaufrufs unter UNIX. Mit anderen Worten heißt dies, daß eine Emulation der UNIX-Systemaufrufe in der Simulationsumgebung Es verwirklicht wird, oder auch, daß die Anwendungen A&sub1; bis An mit der Simulationsumgebung Es kommunizieren, als würde es sich um ein wirkliches UNIX-System handeln.
• Es wird nun auf Fig. 3 Bezug genommen, die ein erstes Ausführungsbeispiel der in Fig. 2 gezeigten Simulationsumgebung Es zeigt. Diesbezüglich wird angenommen, daß es sich um drei Anwendungen A&sub1;, A&sub2;, A&sub3; handelt.
• Die Anwendung A&sub1; ist eine Netzsimulationsanwendung. Sie simuliert folglich Nachrichten, die von einem Netz kommen, also Nachrichten, die mit dem Protokoll bei einer Anwendung auf diesem Netz übereinstimmen.
• Die Anwendung A&sub2; ist eine Testanwendung für den von AT&T definierten XTI-Standard. XTI ist ein Standard für eine Schnittstelle zwischen der Schicht der Ebene 4 (Transport) und einer beliebigen Benutzeranwendung (process user).
• Die Anwendung A&sub3; ist eine Testanwendung, die STREAMS-Standardsystemaufrufe verwendet. Es ist somit ersichtlich, daß diese Anwendungen entweder vom Anwender spezifisch geschriebene Anwendungen wie beispielsweise die Anwendung A&sub1; oder UNIX- Standardanwendungen wie etwa die Anwendungen A&sub2; und A&sub3; sind.
• Die Anwendungen A&sub1; bis A&sub3; können über spezifische Bibliotheken L&sub1;, L&sub2; und L&sub3;, die zu Es gehören, auf eine Simulationssitzung zugreifen. Es wird hier zur Vereinfachung angenommen, daß A&sub1;, A&sub2;, A&sub3; die Bibliotheken 11, 12 bzw. 13 besitzen, die den Aufrufsystemen O&sub1;, O&sub2;, O&sub3; bzw. den Bibliotheken L&sub1;, L&sub2;, L&sub3; zugeordnet sind. Jede dieser Bibliotheken liefert der entsprechenden Anwendung eine Funktionsmenge, die es ihr ermöglicht, mit dem virtuellen Kern CC zu kommunizieren. Der Dialog der Anwen dungen mit diesem Kern basiert auf einem UNIX-Mechanismus, nämlich dem IPC-Mechanismus. Deshalb enthält jede der Bibliotheken L&sub1; bis L&sub3; eine Unterbibliothek, LC&sub1;, LC&sub2; bzw. LC&sub3;, die als IPC-Client-Bibliothek bezeichnet wird. Dieser Mechanismus, der für die Anwendung transparent ist, ermöglicht deren Anwender, die Simulationssitzung, an der er teilnehmen will, zu identifizieren. (Es sei daran erinnert, daß für denselben virtuellen Kern CC mehrere Sitzungen gleichzeitig stattfinden können.) Die Schicht unmittelbar über dem IPC-Mechanismus ist eine Zwischenschicht, die die untere IPC-Schicht für die Anwendung unsichtbar macht. Deshalb sind die beiden Bibliotheken L&sub2; und L&sub3; jeweils mit einer Unterbibliothek, nämlich LS&sub2; bzw. LS&sub3;, ausgestattet, die beispielsweise spezifische Tests für die STREAMS-Schnittstellen bereitstellen.
• Die Bibliothek L&sub2; enthält zusätzlich eine für XTI-Testanwendungen spezifische Unterbibliothek LX&sub2;. Ferner enthält die Bibliothek L&sub1; eine Unterbibliothek LT&sub1;, die transparente Bibliothek genannt wird und die Zugriffsmittel auf die Simulationsumgebung Es enthält, die das Simulieren der Nachrichten ermöglichen, die von einem bestimmten Netz eines speziellen Typs, das simuliert werden soll, stammen.
• Der Konfigurator CONFIG startet die Ausführung des virtuellen Kerns CC, der simuliert werden soll. Letzterer wird wie eine beliebige UNIX-Anwendung gestartet. Dieser Konfigurator CONFIG startet ferner Dienstanwendungen, nämlich die Taktsteuerung GH und die Unterbrechungssteuerung SI.
• Der Konfigurator CONFIG liest seine Direktiven aus einer Konfigurationsdatei, in der alle möglichen Operationen, die während einer Simulationssitzung gestartet werden sollen, angegeben sind.
• Der virtuelle Kern CC enthält zusätzlich eine bestimmte Anzahl von Diensten, nämlich:
• - Die Anwendungsverbindungsdienste, die vom Server IPCS (oder dem unter UNIX definierten IPC-Server) gebildet werden, und einen Abwickler R (dispatcher R), der ermöglicht, daß jede Anwendung den Eingangspunkt in die Kommunikationsschicht des CC findet, auf die sie zugreifen soll: tatsächlich sind die Eingangspunkte je nach Typ der Kommunikationsschichten, die entworfen werden sollen, verschieden.
• - Die Gesamtheit der Dienste SCC, die das Basisbetriebssystem des Kerns CC bereitstellt.
• - Die Dienste, die die Hardwaredienste simulieren, die vom Kommunikationsprozessor verwendet werden, der den Kommunikationscode CC, der simuliert werden soll, verwendet. Diese Hardwaredienste können beispielsweise aus einer Unterbrechungssteuerung, die die Hardwareunterbrechungen simuliert, einer Taktsteuerung, die die Zeitsteuerungsfunktionen (timing functions) simuliert, den Speicherzuweisungsdiensten sowie den Sperrdiensten (inhibition services) bestehen.
• - Die Dienste SMS des STREAMS-Mechanismus, die in den Normen definiert sind, die sich auf eben dieses STREAMS beziehen. Der virtuelle Kern CC enthält ferner eine Gesamtheit aus Elementen, die das darstellt, was als STREAMS-Architektur definiert werden kann, und folgende Elemente umfaßt:
• - Die STREAMS-Schnittstelle SH, die der Schnittstelle SH der Gesamtheit der Kommunikationsschichten des Teils PPA in Fig. 1 genau gleicht.
• - Das Element timod, das ein mit XTI verbundenes STREAMS-Modul ist.
• - Die Gesamtheit LPC von Kommunikationsprotokollmodulen, die zu einem gegebenen Zeitpunkt geprüft werden sollen. Zu einem anderen Zeitpunkt kann diese Gesamtheit anderer Natur sein (TCP/IP, ISO, LAP-D usw.). Diese Module werden miteinander nach Regeln verknüpft, die durch eine vom Anwender bereitgestellten Codedatei in der Sprache C2+ angegeben werden. Diese verschiedenen Module ignorieren die Tatsache, daß sie in einer Simulationsumgebung ausgeführt werden. Sie verhalten sich somit genau so, wie sie es in einer wirklichen Umgebung tun würden.
• - Eine Gesamtheit LT von Modulen, die für jeden der Tests, die ausgeführt werden sollen, spezifisch sind. Sie werden in derselben Weise wie die Protokollmodule LPC miteinander verknüpft.
• Die oben genannten Elemente kommunizieren untereinander (fett gezeichnete Pfeile in Fig. 3) über STREAMS-Dienste SMS (in der Norm definiert). So kommuniziert SH mit timod, timod mit LPC und LT mit LPC über die Dienste SMS.
• Wie aus Fig. 3 deutlich wird, erfolgt der Informationsaustausch und der Dialog zwischen den verschiedenen Elementen, die die Simulationsumgebung bilden, in beiden Richtungen, was durch die Menge der doppelsinnigen Pfeile, die L&sub3;, L&sub2;, L&sub1; jeweils mit CC verbinden, einerseits und zwischen dem Abwickler R und der STREAMS-Schnittstelle SH andererseits veranschaulicht wird. Es außerdem zu erkennen, daß die Kommunikation unter den einzelnen Anwendungen A&sub1; bis A&sub3; über die Bibliotheken l&sub1; bis l&sub3;, L&sub1; bis L&sub3; und über den Server IPCS und den Abwickler R über die STREAMS- Schnittstelle SH führt. Der Dialog zwischen SH und R erfolgt ebenfalls in beiden Richtungen, wie dies durch die zwei doppelsinnigen Pfeile im Inneren des virtuellen Kerns CC veranschaulicht wird, wobei die Pfeile zum einen die STREAMS und XTI-Test und zum andern die Netzsimulationstests symbolisieren.
• Fig. 4 zeigt ein spezielles Beispiel der Ausführung nach Fig. 3, das insbesondere zur Funktionssimulation des Kommunikationscodes des Elements PPA aus Fig. 1 vorgesehen ist.
• Die meisten der wesentlichen Bestandteile aus Fig. 3, nämlich die Anwendungen A&sub1; bis A&sub3; mit ihren entsprechenden Bibliotheken L&sub1; bis L&sub3;, sowie die wesentlichen Bestandteile des Kommu nikationscodes, nämlich der Server IPCS, der Abwickler R, der Dienst des virtuellen Kerns SCC, die STREAMS-Schnittstelle SH, das Element timod und die Menge LPC, finden sich in Fig. 4 wieder. Die in Fig. 4 gezeigte Simulationsumgebung enthält zusätzlich eine Anwendung A&sub4;, Host-Anwendung genannt, die von ihr zugeordneten Bibliotheken begleitet ist, nämlich einerseits von der ihr eigenen Bibliothek 14 und andererseits von L&sub4; für Es, die in Analogie zu den Unterbibliotheken LC&sub1; bis LC&sub3; aus einer Unterbibliothek LC&sub4; und einer transparenten Bibliothek LT&sub4;, die die Nachrichten simuliert, die der Rechner HOST über die in Fig. 1 gezeigten Teile GPU, PPA und DEA an das Netz RE schicken kann, zusammengesetzt ist. Ferner enthält der virtuelle Kern CC eine FIFO-Speicher-Steuerung, wobei die beiden FIFO-Speicher FF&sub1; und FF&sub2;, die FIFO-Speicher FF&sub1; und FF&sub2; aus Fig. 1 mit derselben Bezeichnung sehr exakt simulieren. In Fig. 4 enthält der virtuelle Kern CC zusätzlich eine Schnittstelle HI, die zwischen der STREAMS-Schnittstelle SH und dem Element timod angeordnet ist.
• Ferner enthält der virtuelle Kern CC in Fig. 4 eine FIFO- Speicherbeschreibungssoftware FD.
• Die Elemente SH, HI, timod, LPC, FD kommunizieren untereinander über die STREAMS-Dienste SMS, die zu jenen aus Fig. 3 analog sind. Ferner kommuniziert die FIFO-Speicherbeschreibungssoftware FD direkt mit dem FIFO-Element FF&sub2;, während das Element FF&sub1; direkt mit der Host-Schnittstelle HI kommuniziert. Die Anwendungen A&sub1; und A&sub4; kommunizieren mit dem virtuellen Kern CC über die Bibliotheken 11 und 14, L&sub1; und L&sub4;, während die Elemente IPC und R (in gleicher Weise wie in Figur ·3) mit der FIFO-Speicher-Steuerung GF direkt kommunizieren. Umgekehrt ist die Art und Weise, in der die Anwendungen A&sub2; und A&sub3; mit dem virtuellen Kern CC kommunizieren, mit der in Fig. 3 angegebenen Weise völlig identisch. Folglich kommuniziert der Abwickler R in diesem Fall direkt mit der STREAMS-Schnittstelle SH.
• Ferner enthalten die Dienste SCC des virtuellen Kerns eine Task-Steuerung GT, die dem im Element PPA real eingesetzten Betriebssystem eigene Funktionalitäten aufweist. In dem hier beschriebenen Ausführungsbeispiel gehören diese Funktionalitäten zur Kommunikationssoftware CNS, die von der Anmelderin entwickelt wurde.
• Die weiteren Elemente CONFIG, GH, SI sind mit jenen aus Fig. 3 genau identisch.
• Die Host-Schnittstelle HI ist ein Multiplexer, der zum Abholen der Nachrichten aus dem FIFO-Lesespeicher FF&sub1; dient. Diese Nachrichten übertragen an diesen Prozessor-NCC Primitive in einem spezifischen Format. Einige dieser Nachrichten werden entweder über die Schnittstelle SH an eine Task des Typs CNS in Erwartung einer Verbindung oder zu den LPC weitergeleitet.
• Wie oben beschrieben wurde, trägt die Beschreibungssoftware FD die Nachrichten in den FIFO-Schreibspeicher FF&sub2; ein.
• Die Kommunikationsprotokollprogramme LPC laufen in derselben Weise wie in Fig. 3 ab oder werden von einer Konfigurations- Task verkettet, die durch Konfigurationsnachrichten definiert werden, die von der Anwendung A&sub4;, wenn diese simuliert wird, empfangen werden.

Claims (6)

1. Simulator (SIM) für einen Kommunikationsschichten-Code (CC) eines Netzes RE, der in jedem Datenverarbeitungssystem- Prozessor (NCC) ausführbar ist, der den Informationsaustausch zwischen verschiedenen Elementen des über das Netz verbundenen Systems steuert, dadurch gekennzeichnet, daß er zugeordnet enthält:

- einerseits einen Rechner (ORD), der ein Betriebssystem (NY) enthält,

- andererseits eine Simulationsumgebung (Es), die eine auf dem Rechner laufende Anwendung bildet und außerhalb des Betriebssystems (NY) bleibt,

- Testanwendungen (A&sub1; bis A&sub3; oder An) des Kommunikationscodes (CC), wobei die Umgebung (Es) enthält:

- den Kommunikationsschichten-Code (CC), der nicht modifiziert und in die interne Sprache des Rechners (ORD) kompiliert ist und als virtueller Kern für den Rechner (ORD) angesehen wird,

- Konfigurationsmittel (CONFIG, SI, GH), die dazu bestimmt sind, die Ausführung des Kommunikationscodes zu starten,

- eine Mehrzahl von m Mitteln (L&sub1; bis L&sub3; oder Lm) für den Zugriff auf den Code (CC) für alle Testanwendungen (A&sub1; bis A&sub3; oder An) dieses letzteren.

2. Simulator (SIM) nach Anspruch 1, dadurch gekennzeichnet, daß jede Anwendung eine Bibliothek für den Zugriff nach außen umfaßt, die mit einem der m Zugriffsmittel kommunizieren kann, indem sie mit diesem ein Aufrufsystem definiert, wobei die Anzahl p unterschiedlicher Anwendungsbibliotheken gleich der oder kleiner als die Anzahl m der Code-Zugriffsmittel ist, wobei mehrere Anwendungen gleiche Anwendungsbibliotheken besitzen können, wobei die Anzahl unterschiedlicher Aufrufsy steme ebenfalls gleich p ist.

3. Simulator (SIM) nach Anspruch 1, dadurch gekennzeichnet, daß die Testanwendungen enthalten:

- Testanwendungen für Schnittstellen, die zwischen den verschiedenen Kommunikationsschichten (A&sub2;, A&sub3;) des Netzes bestimmt sind,

- Testanwendungen für jede der Kommunikationsschichten,

- Testanwendungen (A&sub1;) für den Stapel aus Kommunikationsschichten.

4. Simulator nach Anspruch 3, dadurch gekennzeichnet, daß jedes Zugriffsmittel eine Zugriffsbibliothek ist, wobei jede Code-Zugriffsbibliothek (L&sub1; bis L&sub3;) eine erste Unterbibliothek (LC&sub1;, LC&sub2;, LC&sub3;) enthält, die einen Mechanismus umfaßt, der dem Anwender des Simulators ermöglicht, die Simulationssitzung zu identifizieren, auf die er zugreifen möchte, wobei mehrere Simulationssitzungen nebeneinander im Simulator vorhanden sein können, wobei jede Code-Zugriffsbibliothek (L&sub1; bis L&sub3;) eine zweite Unterbibliothek enthält, die spezifische Tests an Schnittstellen zwischen diesen Kommunikationsschichten enthält.

5. Simulator nach Anspruch 4, dadurch gekennzeichnet, daß jede Code-Zugriffsbibliothek (L&sub1;), die mit den Testanwendungen für den Schicht-Stapel (A&sub1;) kommuniziert, Code-Zugriffsmittel enthält, die die Simulation von Nachrichten ermöglichen, die vom Netz stammen und in einer Unterbibliothek enthalten sind.

6. Simulator nach den Ansprüche 2 und 3, dadurch gekennzeichnet, daß die Systemaufrufe solche des UNIX-Systems sind, wobei die Schnittstellen zwischen den verschiedenen Kommunikationsschichten vom Typ STREAMS sind.