DE4039201C2 - - Google Patents

Description

Die Erfindung betrifft ein Emulationsverfahren zur Verhaltensanalyse von Echtzeitkommunika­ tionssystemen (EKS) gemäß dem Oberbegriff des Patentanspruchs 1 oder 3.

In Fig. 5 ist eine mögliche Topologie eines Experimental- EKS dargestellt. Bei der experimentellen Verhaltensana­ lyse in EKS wird üblicherweise folgendermaßen vorge­ gangen: In einem Experimental-EKS halten eine geringe Anzahl von Buscontrollern (7) einen relativ geringen Nachrichtenverkehr auf dem Übertragungsmedium (10) auf­ recht (Funke, A.: Aufbau und Leistungsanalyse eines lokalen Feldbusnetzes. Diplomarbeit, Universität Karls­ ruhe, Institut für Mikrorechner und Automation 1989), wobei einem Teil der Buscontroller eine Lastgenerator- Anwendung (8) und einem anderen Teil eine Lastabsorber- Anwendung (9) aufgesetzt ist. Der Nachrichtenverkehr wird durch einen Busmonitor (11) beobachtet. Den mit dieser Methode gewonnenen Untersuchungsergebnissen haf­ tet der Nachteil an, bei Systemen mit hoher Busausla­ stung keine oder nur eine eingeschränkte Gültigkeit zu haben. Eine hohe Auslastung des Übertragungsmediums mit in Experimental-EKS üblicher kleiner Anzahl von Busteil­ nehmern zu erzeugen, scheitert insbesondere bei hohen Übertragungsgeschwindigkeiten an der begrenzten Rechen­ geschwindigkeit der Buscontroller. Eine hohe Busbela­ stung läßt sich demnach nur erreichen, wenn die Anzahl der Busteilnehmer auf eine realistische Größe erhöht wird. Die materiellen Investitionen für das Experimen­ tal-EKS steigen damit rapide an.

Für die Beobachtung des EKS sind als Meßmittel Hardware-, Software- und Hybridmonitore einsetzbar (Fiedler, K., Hoyer, R.: Modellierungsverfahren und Testkonzeption für den Leistungstest. Forschungsbericht TU Magdeburg, Sektion AE, WSR, 1990). Dem Hardwaremoni­ tor, in (Lingenhal, Th.: Busmonitor. Aufgaben-Konfigu­ raion-Funktion. Offene Kommunikation im Feldbereich mit Profibus. VDI-Bericht 728. Düsseldorf: VDI-Verlag 1987, S.87 ff.) auch als Busmonitor bezeichnet, haftet der Nachteil an, daß er das EKS nur über das Abhören des Übertragungsmediums beobachten kann. Somit ist eine Untersuchung der inneren Systemzustände der Buscontrol­ ler nicht möglich. Zum Variantenvergleich von Protokoll­ implementierungen, Engpaß-, Warteschlangen- und Empfind­ lichkeitsanalysen gegenüber Systemparameteränderungen usw. wird aber gerade diese Fähigkeit vom Meßmittel verlangt. Abhilfe würde hier der Einsatz eines Software­ monitors schaffen (Franke, Ch.: Analyse der Last in einem Vielbenutzersystem. Bericht Nr. 85, Fachbereich Informatik. Universität Hamburg, 1982). Dieser muß in die Protokollsoftware der Buscontroller eingefügt werden, wobei die bei hohen Übertragungsgeschwindigkei­ ten ohnehin schon knappen Prozessorressourcen zusätzlich in Anspruch genommen werden. Aus diesem Grund scheidet der Einsatz eines Softwaremonitors zur Leistungsanalyse in EKS aus. Der Hybridmonitor vereint die Vorteile beider Monitortypen, ohne deren Nachteile zu besitzen, indem er, wie in Fig. 6 gezeigt, über einen (parallelen) Beobachtungsport (15) den internen Systemzustand des Buscontrollers (7) mit Hilfe von in der Protokollsoft­ ware (16) untergebrachten Testpunkten überwacht (Lutten­ berger, N.: Monitoring von Multiprozessor- und Multicom­ puter-Systemen. Dissertation A. Arbeitsberichte des Instituts für mathematische Maschinen und Datenverarbei­ tung (Informatik) der Universität Erlangen- Nürnberg, 1989) und (Schrott, G., Tempelmeier, T.: Messungen in einem Prozeßrechnersystem mit einem eigenen Meßrechner. TU München 1982). Die zur internen Buscontrollerbeobach­ tung und Ergebnisauswertung notwendigen Softwaremodule, beim Softwaremonitor Bestandteil der Protokollsoftware, können somit in den externen Hybridmonitorrechner verla­ gert werden und nehmen nicht mehr die Prozessorressour­ cen der Buscontroller (7) in Anspruch. Somit sollte zur Leistungsanalyse sinnvollerweise ein Hybridmonitor ein­ gesetzt werden. Insbesondere die Warteschlangen- und Empfindlichkeitsanalyse erfordert eine systemglobale Beobachtung und Ergebnisauswertung im Experimental-EKS. Dazu muß jeder Buscontroller (7) mit je einem Hybrid- Monitor (12) gekoppelt werden. Diese wiederum müssen über ein schnelles Datennetz (13) mit einem Auswerte­ rechner (14) verbunden sein, damit die Einzelereignis­ spuren der internen Buscontroller-Systemzustände ausge­ wertet werden können. In (Luttenberger, N.: Monitoring von Multiprozessor- und Multicomputer-Systemen. Disser­ tation A. Arbeitsberichte des Instituts für mathemati­ sche Maschinen und Datenverarbeitung (Informatik) der Universität Erlangen-Nürnberg, 1989) wurde dargelegt, daß für Untersuchungen in einem Multicomputersystem (ein solches stellt das EKS letztendlich dar) ein VLSI- Schaltkreis zur Beobachtung der einzelnen Prozessorda­ tenbusse, ein schnelles Meßdatennetz mit gesondertem Daten- und Synchronisationskanal und eine spezielle Datenbeschreibungssprache "Trace Description Language, TDL" entwickelt wurde. In diesem Falle ist der enorme Investitionsaufwand besonders auffällig.

In (Lawrenz, W.: Entwicklungswerkzeuge für Controller- Netzwerke. Elektronik, Heft 18, 04.09.87, S.136-140) und in der Patentschrift (DE 37 21 719 C3) wird ein Verfah­ ren zur Prüfung eines Netzwerkaufbaus mit einer Mehrzahl von Datengeneratoren, deren Daten über einen Datenweg untereinander gesendet und empfangen werden (CSMA/CD- Buszugriffsverfahren) sowie auf eine Steuerung gelangen sollen, beschrieben.

Dabei wird in einem ersten Schritt das gesamte Netzwerk vollständig simuliert, d. h. die Kommunikationsprozesse werden an Hand eines Modells auf einem Rechner nachge­ stellt. Es wird keine Aussage gemacht, wie relevante Zeitparameter für die Simulationsmodellparametrierung (z. B. das Zeitverhalten der Kommunikationscontroller bzw. der Netzknoten) ermittelbar sind. Offenbar wird bei der Simulation des Netzwerkes nur geprüft, ob es zu den generierten Ereigniszeitpunkten, die einen Datenfluß zur Folge haben, zu Kollisionskonflikten kommen könnte und wie diese gelöst werden. Bei aufwendigeren Buszugriffs­ verfahren, wie z. B. Token Passing, und umfangreichen Protokollstacks sind kompliziertere Modellansätze mit genaueren Parametervorgaben erforderlich um hinreichend verläßliche Aussagen treffen zu können.

Im zweiten Schritt des Verfahrens werden nur noch die Kommunikationsforderungen simuliert, das eigentliche Kommunikationssystem, bestehend aus Übertragungsmedium und allen seriellen Schnittstellen zu diesem (Netzwerk- Interfaces), ist vollständig aufgebaut. Das mit dieser Anordnung ermittelte Zeitverhalten dürfte dem Verhalten des im dritten Schritt vollständig aufgebauten Netzwer­ kes schon sehr nahe kommen, da die wesentlichsten zeit­ verhaltensbestimmenden Netzwerkkomponenten, die Kommuni­ kationscontroller, real arbeiten. Heutzutage besteht der Leistungsengpaß von Kommunikationssystemen nicht mehr im Übertragungsmedium, sondern in den Kommunikationscon­ trollern, da die Realisierung umfangreicher Protokoll­ stacks, insbesondere bei offenen Systemen, sehr viel Zeit benötigt. Demzufolge ist das Zeitverhalten der Kommunikationscontroller nicht mehr vernachlässigbar.

Nach heutigem Stand der Technik wird also zum Erhalt hinreichend genauer Zeitverhaltensaussagen ein reali­ siertes (Experimental-)Kommunikationssystem mit Übertra­ gungsmedium und genügend großer Anzahl von Kommunika­ tionscontrollern benötigt.

Das Ziel der Erfindung soll in einer drastischen Ver­ ringerung des Testkonfigurations- und Testmittelaufwan­ des bei der experimentellen Verhaltensanalyse in EKS be­ stehen.

Es ergibt sich die Aufgabe, ein Emulationsverfahren für Echtzeitkommunikationssysteme zu entwickeln, das mit ge­ ringem Aufwand eine Verhaltensanalyse von EKS umfangrei­ cher Konfiguration ermöglicht, wobei das Zeitverhalten der Kommunikationscontroller vollständig einzubeziehen ist.

Erfindungsgemäß wird die Aufgabe gemäß dem kennzeichnenden Teil des Patentanspruchs 1 oder 3 gelöst.

Im weiteren soll die Erfindung an einem Ausführungsbei­ spiel näher erläutert werden. Hierzu zeigen

Fig. 1 und Fig. 2 das Prinzipschema möglicher An­ ordnungen zur Realisierung des Emulationsverfahrens für Echtzeitkommunikationssysteme,

Fig. 3 und Fig. 4 das Zeitregime der Rechenprozesse und deren Times­ haring.

In Fig. 1 besteht die Anordnung aus einem überge­ ordneten Steuerrechner (4), im weiteren als Experiment- Manager bezeichnet, einem Original-Buscontroller (1) und einem Mikrocontroller, der als Busemulator (2) fungiert. Der Busemulator (2) und der Buscontroller (1) sind über die serielle Bus-Schnittstelle (5) und den Übertragungs­ kanal (6) miteinander verbunden. Die Ankopplung des Experiment-Managers an Buscontroller (1) und Busemulator (2) kann zweckmäßig über einen Dual Fort Memory (3) erfolgen.

Die Anordnung in Fig. 2 unterscheidet sich von der in Fig. 1 durch die Einbeziehung mehrerer Buscontroller (1, 1′, 1′′ . . . ) in den Emulationsprozeß mit dem Ziel, auch heterogene EKS, bestehend aus Buscontrollern verschiede­ ner Hardware- und/oder Softwareversionen, nachbilden zu können.

Die Programmlaufprozesse der implementierten Kommunika­ tions-Protokollsoftware in den Buscontrollern des ver­ teilten EKS sind systemglobal betrachtet zeitparallele Rechenprozesse (RP). Das bedeutet, da diese RP auf ver­ schiedenen, simultan arbeitenden Buscontroller-Prozes­ soren laufen, wobei sich die Rechenoperationen zeitlich überlappen. In Fig. 3 ist ein Beispiel für die Paralleli­ tät der Rechenprozesse RP i im verteilten EKS und in Fig. 4 die Überführung der einzelnen Rechenprozesse RP1, RP2 und RP3 auf eine Laufzeitressource (1) des konzen­ trierten Emulationssystems dargestellt. Die Kommunika­ tionsbeziehungen (17, 18) sollen in der Reihenfolge
1. RP1 auf Buscontroller 1 zum Zeitpunkt t₁₁ mit einer Zeitdauer T_act1,
2. RP3 auf Buscontroller 3 zum Zeitpunkt t₃₂ mit einer Zeitdauer T_act3 und
3. RP2 auf Buscontroller 2 zum Zeitpunkt t₂₃ mit einer Zeitdauer T_act2,
ablaufen.

Das Funktionsprinzip des EKS-Emulators nutzt den Umstand aus, daß sich bei Protokollen mit determeniertem Buszu­ griffsverfahren (Tokenpassing, Polling) zu einem bestimmten Zeitpunkt auf dem gesamten Übertragungsmedium nur ein Telegramm befinden kann. Deshalb ist es möglich, die systemglobal zeitparallelen RP der im EKS verteilten Buscontroller (7) zur experimentellen Verhaltensanalyse am EKS nacheinander so auf nur einer Buscontroller-Hard­ ware-Ressource (1) ablaufen zu lassen, daß mit der Ori­ ginal-Buscontroller-Hardware und einer gegenüber dem Original nur geringfügig modifizierten Protokollsoftware eine Systemkommunikation in Non-Real-Time abwickelbar ist. Dazu werden der physischen Buscontroller-Hardware je nach gerade aktueller Kommunikationsbeziehung nach­ einander verschiedene logische Teilnehmer-Identitäten zugewiesen. In Fig. 4 ist zu erkennen, daß im Emulations­ zyklus 1 auf nur einer Buscontroller-Ressource (1) zuerst RP1, gefolgt von RP2 und RP3 mit einer Laufzeit T_act1 aktiv sind. Danach wird der zweite Emula­ tionszyklus vom RP3 eingeleitet, weil dieser vom RP1 gemäß der aktuellen Kommunikationsbeziehung (17) durch ein Telegramm angesprochen wird. Die Rechenprozeßdauer aller RP eines Zyklus wird von T_act des RP bestimmt, der einen Emulationszyklus einleitet (im zweiten Zyklus T_act3, im dritten Zyklus T_act2).

Die Kontrolle über den Emulationsvorgang und die experi­ mentelle Verhaltensanalyse am jetzt emulierten EKS ob­ liegt dem Experiment-Manager (4).

Der Busemulator (2) stellt eine physisch und logisch selbständige Komponente des EKS-Emulationssystems dar. Er hat die Aufgabe, die serielle Busschnittstelle (5) der Buscontroller-Hardware (1) abzuhören und nach bestimmten Regeln mit zwischengespeicherten Telegrammen so zu versorgen, daß das lokale Buscontroller-RP-Zeitge­ füge erhalten bleibt, weil der Buscontroller zwischen den logischen Identitätswechseln in Echtzeit arbeitet. Der Busemulator (2) substituiert funktionell genaugenom­ men nur das Übertragungsmedium des EKS einschließlich der zur aktuellen Teilnehmeridentität in Opposition ste­ henden Netzwerkkomponenten, indem er die von den Teil­ nehmern abgesendeten Telegramme absorbiert, für sich eine Adreßauswertung vornimmt und das absorbierte Tele­ gramm im nächsten Emulationszyklus nacheinander an alle (logischen) Teilnehmer des EKS weitergibt. Da dabei das Zeitgefüge gedehnt wird, muß für die Leistungsanalyse eine Zeitkorrektur vorgenommen werden. Dazu werden zwei Zeitebenen eingeführt: Unter Echtzeit wird in diesem Zusammenhang die für die Verhaltensanalyse heranzuzie­ hende Zeitebene verstanden, d. h. diese spiegelt die im realen, verteilten System verbrauchten Zeitressourcen wider. Die Emulationszeit ist dagegen der Zeitbetrag, den der Emulationssystem-Anwender von außen beobachten kann.

Wurde vom Busemulator (2) ein Telegramm empfangen, fil­ tert er zunächst die Zieladresse aus und übergibt diese dem Experiment-Manager (4). Somit kennt dieser dann den Teilnehmer des EKS, der den nächsten Emulationszyklus eröffnet. Damit die lokalen Buscontrollertimer am Anfang des nächsten Emulationszyklus den gleichen Stand haben, müssen die restlichen, nicht adressierten logischen Teilnehmeridentitäten im aktuellen Emulations­ zyklus i für die Zeit T_acti aktiviert und vom Busemula­ tor (2) mit dem im Vorgängerzyklus von ihm empfangenen Telegramm zeitrichtig beschickt werden. T_acti ist unge­ fähr die Zeit, die zwischen Empfang und Senden bei dem logischen Teilnehmer vergeht, der vom Vorgängeremula­ tionszyklus i-1 adressiert wurde.

Der logische Identitätswechsel geht so von statten, daß der RP auf dem Buscontroller (1) eingefroren und die aktuelle Teilnehmer-Identität auf einen Massenspeicher des Experiment-Managers (4) abgelegt wird. Nun kann die neue, durch den Emulationsalgorithmus bestimmte Identi­ tät, vom Massenspeicher in den Buscontroller (1) geladen und der RP auf dem Buscontroller (1) wieder aktiviert werden, wo er unter Echtzeitbedingungen so lange läuft, bis das Abbruchereignis eintritt. Als Abbruchereignis wird entweder das Ende eines vom RP ausgesendeten Tele­ gramms definiert (beim adressierten Teilnehmer) oder der Ablauf von T_acti (beim nichtadressierten Teilnehmer). Der Datenaustausch zwischen Buscontroller (1) und Expe­ riment-Manager (4) erfolgt vorteilhaft über einen DPM (3).

Als Teilnehmer-Identität wird die Menge von Daten defi­ niert, die den Zustand des auf dem Buscontroller (1) ablaufenden Rechenprozesses eindeutig beschreibt. Zu diesen Daten gehören mindestens:

• - der Inhalt des gesamten Prozessor-Registersatzes
• - der Inhalt aller Protokollsoftware-Variablen,
• - der Inhalt der Hardware-Zähler und
• - die Daten in Puffern von Peripherie-Schaltkreisen.

Somit ist für den Emulationsprozeß sichergestellt, daß ein Rechenprozeß genau dort wieder aufgenommen werden kann, wo er vor seiner Archivierung unterbrochen wurde.

Claims (3)

1. Emulationsverfahren zur Verhaltensanalyse von Echtzeitkommunikationssystemen mittels eines ersten Mikrocontrollers (1), auf dem eine Kommunikationsprotokollsoftware implementiert ist, und dessen serielle Busschnittstelle (5) über einen Datenkanal (6) mit einem zweiten Mikrocontroller (2), der als Busemulator arbeitet, verbunden ist, wobei beide Mikrocontroller (1) und (2) über Koppelelemente (3) mit einem übergeordneten Rechner (4) in Verbindung stehen, dadurch gekennzeichnet, daß der Kommunikationsbetrieb eines Echtzeitkommunikationssystems teilweise außerhalb des Echtzeitbetriebs nachgebildet wird, indem der erste Mikrocontroller (1) ein Telegramm über seine serielle Busschnittstelle (5) aussendet, der als Busemulator arbeitende Mikrocontroller (2) dieses Telegramm empfängt, zwischenspeichert und nach dem Wechsel der logischen Identität des ersten Mikrocontroller (1) diesem ein zwischengespeichertes Telegramm wieder zusendet, wobei der erste Mikrocontroller (1) zwischen den Identitätswechseln in Echtzeit arbeitet.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß ein systemglobaler Kommunikationsbetrieb eines Echtzeitkommunikationssystems dadurch emuliert wird, daß die systemglobal zeitparallelen Rechenprozesse aller Buscontroller (7) des Echtzeitkommunikationssystems nacheinander auf dem ersten Mikrocontroller (1) ablaufen und dieser in einer Weise vom als Busemulator arbeitenden Mikrocontroller (2) mit zwischengespeicherten Telegrammen beschickt wird, daß der systemweite Kommunikationsbetrieb zum Zweck der systemglobalen Verhaltensanalyse außerhalb des Echtzeitbetriebes, aber unter Einbeziehung des Realzeitverhaltens jedes einzelnen Buscontrollers des Realsystems (7) nachgebildet wird.

Emulationsverfahren zur Verhaltensanalyse von Echtzeitkommunikationssystemen mit Buscontrollern (7) verschiedener Hardware- und/oder Softwareversionen, mittels mehrerer erster Mikrocontroller (1, 1′, 1′′ . . .), auf denen jeweils eine Kommunikationsprotokollsoftware implementiert ist, und deren serielle Busschnittstellen (5) über einen Datenkanal (6) mit einem zweiten Mikrocontroller (2), der als Busemulator arbeitet, verbunden sind, wobei alle ersten und zweiten Mikrocontroller (1, 1′, 1′′ . . .) und (2) über Koppelelemente (3) mit einem übergeordneten Rechner in Verbindung stehen, dadurch gekennzeichnet, daß der Kommunikationsbetrieb eines Echtzeitkommunikationssystems teilweise außerhalb des Echtzeitbetriebs nachgebildet wird, indem einer der ersten Mikrocontroller (1, 1′, 1′′ . . .) ein Telegramm über seine serielle Busschnittstelle (5) aussendet, der als Busemulator arbeitende Mikrocontroller (2) dieses Telegramm empfängt, zwischenspeichert und nach dem Wechsel der logischen Identität des vom übergeordneten Rechner (4) ausgewählten ersten Mikrocontrollers (1 oder 1′ oder 1′′ oder . . .) diesem ein zwischengspeichertes Telegramm wieder zusendet, wobei die ersten Mikrocontroller (1 oder 1′ oder 1′′ oder . . .) zwischen den Identitätswechseln in Echtzeit arbeiten.