Signalvorverarbeitung

Im Dokument Plattform zur Echtzeit-Co-Simulation für die virtuelle Inbetriebnahme (Seite 119-132)

6.2 Kopplungsmechanismus

6.2.2 Signalvorverarbeitung

Bei der Signalvorverarbeitung wird im Koppelsignal-Sender das Sendeintervall auf den Si- mulationstakt der langsameren Simulationstask eingestellt (siehe Abbildung 6.5a). Dies führt zu einer erheblichen Reduzierung der Datenmenge und stellt sicher, dass nur für die Modellberechnung relevante Signale in der Datenhaltung abliegen. Sollten auch Zwi- schenwerte für den Koppelsignal-Empfänger relevant sein, werden diese im Koppelsignal- Sender zwischengespeichert und der vollständige Signalverlauf zum Kommunikationszeit- punkt gemeinsam versendet.

6.2.3 Signalnachverarbeitung

Notwendige Mechanismen im Koppelsignal-Empfänger zur Signalnachverarbeitung sind die taktgenaue Einsortierung von Koppelsignalen, die Überprüfung auf die Reproduzier- barkeit des Simulationslaufs sowie die Modifikation der Koppelsignale:

Einsortierung von Koppelsignalen: In der Datenhaltung abgelegte Koppelsignale müs-

sen vom Empfängerbaustein taktgenau einsortiert werden (siehe Abbildung 6.5b).

Überprüfung auf Reproduzierbarkeit: Kommt es während einer Teilmodellberech-

nung zu Verzögerungen, liegt der benötigte Koppelsignaleingang nicht rechtzeitig vor. Es

Abbildung 6.5: a) Reduktion auf notwendige Signale, b) Einsortierung von Koppel-

signalen und c) Multi-Rate Methoden

Simulationstask 1 1 0 Simulationstask 2 1 0 t t Simulations- takt Task 2 Simulationstakt Task 1 0 … Warten 1 … Teilmodellberechnung … Koppelsignal … Simulationstakt a b Reduktion auf notwendige Signale Einsortierung von Koppelsignalen Multi-Rate Methoden c

kommt zu Verzerrungen im Ablauf. Der auftretende Fehler wird nicht zwangsläufig vom Steuerungssystem erkannt, da die Kommunikation mit dem Steuerungssystem von der gekoppelten RTOS-Simulationstask aufrecht gehalten wird. Allerdings geht hierbei die Re- produzierbarkeit des Simulationslaufs verloren. Anforderung 4.2 (taktgenaue Reprodu- zierbarkeit von Simulationsläufen) wäre damit nicht erfüllt. Im Empfänger-Baustein muss überprüft werden, ob ein benötigter Koppelsignaleingang rechtzeitig zur Verfügung steht. Liegt der Koppelsignaleingang nicht rechtzeitig vor, ist eine Warnung auszugeben. Sobald das Koppelsignal vorliegt, wird es taktverzögert einsortiert. Am Ende des Simula- tionslaufs muss der Simulationsexperte entscheiden, ob die Simulation trotz der Verzer- rung brauchbar ist.

Modifikation der Koppelsignale (Multi-Rate Methoden): Als Multi-Rate-Integration

bezeichnet man die „Anwendung unterschiedlicher Schrittweiten für die Integration der Teilsysteme“ (Dronka 2004). Hierbei liegen nicht zu jedem Simulationstakt der schnelleren Simulationstask neue Koppelsignale vor. Multi-Rate Methoden (Gear et al. 1984; Murray- Smith 2012) bezeichnen Algorithmen, welche die Simulationstakte ohne neue Koppelsig- nale mit Werten füllen (siehe Abbildung 6.5c). In der Literatur werden hierfür unterschied- liche Möglichkeiten aufgeführt:

 Zero-order-hold: Halten des letzten Koppelsignals als Eingang, bis ein neues Kop- pelsignal zur Verfügung steht

 Interpolation: Berechnung neuer Koppelsignale aus bekannten zukünftigen Kop- pelsignalen, z.B. Interpolation 1. Ordnung

 Extrapolation: Schätzung des Koppelsignals aus vorherigen Koppelsignalen, z.B. Extrapolation 1. Ordnung.

Im Falle der Echtzeit-Co-Simulation sind keine zukünftigen Koppelsignale bekannt. Daher sind nur Zero-order-hold oder die Extrapolation anwendbar. Eine weitere Möglichkeit ist die parallele Simulation desselben Verhaltensmodells in zwei Teilmodellen auf unter- schiedlichen Echtzeit-Ebenen in unterschiedlichen Modelltiefen. Hierbei entstehen soge- nannte mehrskalige Simulationsmodelle. Das abstrahierte und performante Modell in der

„schnellen“ Simulationstask wird von einem konkreten und berechnungsintensiven Mo- dell in der „langsamen“ Simulationstask geführt (Scheifele et al. 2018). Beispielsweise kann zur Abbildung eines Materialflusses ein performantes kinematisches Materialfluss- modell, das den Materialfluss ohne physikalische Effekte und damit sehr idealisiert be- trachtet, in der schnellen Simulationstask durch ein präzises und rechenintensives physik- basiertes Materialflussmodell in der langsamen Simulationstask geführt werden (Scheifele et al. 2018).

Die weitere Betrachtung beschränkt sich auf den Zero-order-hold Ansatz, da im Rahmen dieser Arbeit die Konzeption der Echtzeit-Co-Simulationsarchitektur und die Untersu- chung der Eignung dieser Simulator-Architektur für eine HILS-RTOS im Vordergrund steht.

6.3 Synchronisationsmechanismus

Durch die Untersuchungen in Kapitel 5 wurde gezeigt, dass die verlustfreie und zeitsyn- chrone Kommunikation mit dem Steuerungssystem (Anforderung 4.1) durch die Kopp- lung einer einzelnen RTOS-Simulationstask an das Steuerungssystem sowie die Einhaltung der Bedingungen aus Kapitel 5.3.3 an die Partitionierung gewährleistet ist. Die Entwick- lung des Synchronisationsmechanismus unterliegt damit der Anforderung, eine taktge- naue Reproduzierbarkeit von Simulationsläufen (Anforderung 4.2) zu gewährleisten. Die Abläufe innerhalb einer Simulationstask zur Simulation eines (Teil-)Modells werden unter anderem in Röck 2007 betrachtet. Röck teilt den Ablauf einer Simulation in einer Simulationstask in drei Abschnitte: Die Initialisierungsphase, die Durchlaufphase und die Terminierungsphase (siehe Abbildung 6.6).

In der Durchlaufphase lassen sich nach Röck 2007 zwei Arten der Simulatortaktung un- terscheiden:

 Selbstgetakteter Simulator: Die Taktung des Simulators orientiert sich an der eigenen Uhr und damit an einer eigenen Zeitbasis. Dies macht eine Synchronisation der Uhr auf die reale Zeit erforderlich.

 Fremdgetakteter Simulator: Die Taktung des Simulators orientiert sich an einer externen Uhr. Die Simulationstask wird damit von außen kommandiert.

Bei der HILS-RTOS mit einer geschlossenen Simulationsarchitektur nach Röck 2007 ist die RTOS-Simulationstask als fremdgetaktete Simulationstask realisiert. Das RTOS führt die Taktung der Simulationstask durch. Die Uhr des RTOS synchronisiert sich dabei auf die Feldbus- bzw. Steuerungs-Uhr. Dies führt zu einer absoluten Zeitsynchronität zwischen Steuerung und Simulation (Röck 2007). Bei der Echtzeit-Co-Simulation werden im RTOS nun mehrere Echtzeit-Tasks angelegt und den Prozessoren des Mehrkernprozessors zu- geordnet. Die Taktung auf der Peripherie- und RT-Ebene soll damit vollständig durch das RTOS erfolgen. Mit der in Kapitel 6.2 dargestellten Prüfung auf Reproduzierbarkeit ist sichergestellt, dass die taktgenaue Reproduzierbarkeit gewährleistet ist. Im Weiteren wird

Abbildung 6.6: Aufbau eines Simulators in Anlehnung an Röck 2007

Initialisierungsphase

Durchlaufphase

 Einlesen und Initialisierung des (Teil-)Modells

Terminierungsphase

 Terminierung des (Teil-)Modells  Eingänge lesen

 (Teil-)Modell berechnen  Ausgänge schreiben  fremdgetaktet

6.3.1 Selbstgetaktete NRTOS-Simulationstask

Die Ankopplung von NRTOS-Simulationstasks führt zu nachfolgender Problematik:  Asynchrone Uhren bei der Selbsttaktung: Es kann nicht davon ausgegangen

werden, dass die NRTOS-Simulationstask über eine zum RTOS synchrone Uhr ver- fügt. Es muss berücksichtigt werden, dass bei der Simulation ein Clock-Drift ent- steht.

 Kein garantierter Zeitdeterminismus: NRTOS gewährleisten keine zeitdetermi- nistische Ausführung der Simulation. Eine harte Echtzeitsimulation kann mit den vom NRTOS zur Verfügung gestellten Scheduling-Mechanismen nicht zuverlässig gewährleistet werden.

Wird die NRTOS-Simulationstask als selbstgetaktete Simulationstask realisiert, orientiert sich die Taktung an der eigenen Zeitbasis. Um für Synchronität im Co-Simulationsnetz- werk zu sorgen, muss die Uhr der Simulationstask aufsynchronisiert werden. Im Bereich der Kommunikationstechnik sind Standards zur Uhrzeitsynchronisation verfügbar, z.B. das Precision Time Protocol (PTP) nach IEEE 1588 (Dreher et al. 2005) oder das Network Time Protocol (NTP) nach RFC 5905. Im Kontext der aktuellen Entwicklungen hin zu einem herstellerübergreifenden Kommunikationsstandard für Industrie 4.0 wird mit OPC UA TSN (TSN - Time Sensitive Networking) an einem einheitlichen, offenen Standard gearbeitet, welcher unter anderem Mechanismen zur Uhrzeitsynchronisation zukünftig leicht integ- rierbar zur Verfügung stellen wird. Bei der Realisierung einer auf mehreren Hardware- Plattformen verteilten Echtzeit-Co-Simulation ist eine Verwendung dieser Lösungen aus dem Bereich der Kommunikationstechnik vielversprechend. Im Rahmen dieser Arbeit wird die Berechnung allerdings auf einem einzelnen Rechnersystem durchgeführt. Die Realisie- rung einer fremdgetakteten Simulationstask stellt die effizientere und performantere Lö- sung zur Begegnung der Problemstellung dar und wird im Weiteren betrachtet.

6.3.2 Fremdgetaktete NRTOS-Simulationstask

Betrachtet man die Realisierung der fremdgetakteten Variante, so lässt sich eine Analogie zu vorhandenen Realisierungen im Bereich der numerischen Steuerungssysteme und der

Echtzeit-Berechnung auf Mehrprozessor-Steuerungssystemen herstellen. Eine Analogie zur NC-Technik ist sinnvoll, da hier die ähnlichen Echtzeitanforderungen wie bei der HILS- RTOS vorherrschen. Plasch betrachtet die Entwicklung von standardisierten Software- schnittstellen zur Realisierung eines NC-spezifischen Schnittstellenkonzepts für den Da- tenaustausch miteinander gekoppelter paralleler Prozesse in Mehrprozessor-Steuersyste- men (Plasch 1983). Plasch motiviert ein NC-spezifisches Schnittstellenkonzept, da Lösun- gen aus dem Bereich der Informatik nicht den gestellten Anforderungen entsprechen. Insbesondere Semaphoren zur Interprozesskommunikation stellen nach Plasch wegen ih- rer Unsicherheit und Unüberschaubarkeit nicht die geeignete Lösung dar.

Bei der Betrachtung des Datenflusses in der NC-Technik unterscheidet Plasch die Signale hinsichtlich der Datenverwendung:

 Bereitstellungsdaten: „Daten, die bereitgestellt und in einem bestimmten Zyklus aktualisiert werden“ (Plasch 1983)

 Verbrauchsdaten: „Daten, die einen bestimmten Speicherbereich (Datenpuffer) solange belegen, bis ihr Verbrauch sichergestellt ist und der Datenpuffer wieder mit neuen Daten geladen werden kann“ (Plasch 1983)

Während bei Bereitstellungsdaten nach Plasch keine Synchronisation zwischen Sender und Empfänger notwendig ist, liegt bei Verbrauchsdaten die Notwendigkeit zur Bereit- stellung eines „Verfahrens zur einwandfreien Synchronisation zwischen Datenquelle und Datensenke“ (Plasch 1983) vor.

Koppelsignale der Echtzeit-Co-Simulation besitzen die Eigenschaften von Verbrauchsda- ten. Ein Sender (Simulationstask 1) stellt nach der Teilmodellberechnung die vom Emp- fänger (Simulationstask 2) benötigten Koppelsignale in einem Speicherbereich zur Verfü- gung. Besitzt Simulationstask 1 einen schnelleren Simulationstakt als Simulationstask 2, werden die Koppelsignale von Simulationstask 1 nur zu den Simulationstakten von Simu- lationstask 2 verschickt (vgl. Abbildung 6.4). Zur Erfüllung der taktgenauen Reproduzier- barkeit von Simulationsläufen (Anforderung 4.2) muss sichergestellt sein, dass Simulati-

onstask 2 die Koppelsignale rechtzeitig zur Verfügung stehen und diese im richtigen Si- mulationstakt verwendet werden. Hierzu ist eine einwandfreie Synchronisation notwen- dig.

Zum Ablegen der Signale im Speicherbereich stellt Plasch nachfolgende Datenstrukturen vor (Plasch 1983):

 Block: Datenblock mit definierter Blocklänge. Enthält einen Synchronisationsme- chanismus.

 String: Datenblock mit variabler Blocklänge zur Speicherung von Zeichenketten mit definiertem Endzeichen. Enthält einen Synchronisationsmechanismus.

 FIFO: Eine Folge von Blöcken, die nach dem FIFO-Prinzip zu verarbeiten sind. Ein Koppelsignal besitzt einen einzigen Sender und einen einzigen Empfänger. Liegt im Blockschaltbild eine Verzweigung mit zwei unterschiedlichen Signalempfängern vor, wird je Empfänger ein eigenes Koppelsignal erzeugt. Sind für den Empfänger Zwischenwerte von Bedeutung, so wird für jeden Zwischenwert ebenfalls ein eigenes Koppelsignal er- stellt. Ein Koppelsignal besitzt über den Simulationslauf hinweg immer dieselbe Länge. Laufen die Teilmodellberechnungen in den einzelnen Simulationstasks synchron zueinan- der, ist nur das aktuelle und zum Simulationstakt passende Koppelsignal von Bedeutung. Die Datenhaltung von Koppelsignalen bei der Echtzeit-Co-Simulation müssen folgende Kriterien erfüllen:

 Aus Sicht des Senders: Es muss sichergestellt sein, dass immer das aktuelle Kop- pelsignal im Speicherbereich abliegt.

 Aus Sicht des Empfängers: Es muss sichergestellt sein, dass das abgelegte Kop- pelsignal rechtzeitig vor dem nächsten Koppelsignal abgeholt wurde.

Da zu jedem Zeitpunkt immer nur ein einziges Koppelsignal vorliegen muss, ist die Ver- wendung eines FIFO nicht notwendig. Darüber hinaus besitzen ausgetauschte Koppelsig- nale immer dieselbe Länge, weshalb auch die Datenstruktur String nicht verwendet wer- den soll. Die Verwendung der Datenstruktur Block stellt die richtige Datenstruktur dar. Plasch sieht für die Datenstruktur Block die Verwendung einer Gültigkennung vor, um

den Zugriff auf die Daten nach dem Prinzip des „löschenden Lesens“ (Plasch 1983) zu verwalten: „Eine Variable wird nur dann beschrieben, wenn sie vorher als Null gelesen wurde und die zugehörige Information nur dann als gültig gelesen, wenn sie ungleich Null war“ (Plasch 1983). Beim Austausch der Koppelsignale stellt dieses Vorgehen ein „Quittierungsmechanismus“ (Plasch 1983) dar. Der Koppelsignal-Sender kann nur ein neues Koppelsignal ablegen, wenn der Koppelsignal-Empfänger das vorherige Signal ab- geholt und die Gültigkennung auf die Zahl „0“ gesetzt hat. Der Koppelsignal-Empfänger wiederum erkennt direkt, wenn ein neues Koppelsignal zur Verfügung steht, da die Gül- tigkennung von „0“ auf ungleich „0“ wechselt.

Betrachtet man die Abläufe einer Simulationstask innerhalb der Durchlaufphase, so glie- dert sich ein Simulationsschritt in das Lesen der Koppelsignaleingänge, die Durchführung der Teilmodellberechnung sowie das Schreiben der Koppelsignal-Ausgänge. Es lässt sich festlegen, dass eine Teilmodellberechnung erst dann durchgeführt werden darf, wenn alle notwendigen Koppelsignaleingänge vorliegen (siehe Abbildung 6.7). Geht man davon aus, dass zumindest eine Simulationstask aufgrund der Kopplung an das reale Steue- rungssystem an der realen Zeitachse läuft, synchronisiert sich die NRTOS-Simulationstask

S Teilmodell

Koppelsignal-Abfrage (prüft zyklisch die Verfügbarkeit der

Koppelsignal-Eingänge) Simulationsschritt durchführen Eingänge lesen Modell berechnen Ausgänge schreiben Koppelsignal- Verbraucher Koppelsignal- Erzeuger warten S … Simulationstask

mit der RTOS-Simulationstask, indem sie auf die Bereitstellung der Koppelsignaleingänge wartet.

Abbildung 6.8 zeigt den Ablauf der Synchronisation. Abbildung 6.8a stellt die Zeit dar, die ein Koppelsignal zur Übertragung zwischen den beiden Simulationstasks benötigt. Sobald die NRTOS-Simulationstask das Koppelsignal von der RTOS-Simulationstask emp- fängt, beginnt sie mit der Teilmodellberechnung. Hierbei kann ein „Vorlauf“ entstehen wenn die Koppelsignale bereits früher zur Verfügung stehen (siehe Abbildung 6.8b). Bei einem „Vorlauf“ startet die NRTOS-Simulationstask bereits vor dem eigentlichen Startzeit- punkt auf der realen Zeitachse, da die benötigten Koppelsignale für einen Simulations- schritt bereits vorliegen. Der entstehende Vorlauf zur realen Zeit kann jedoch vernachläs- sigt werden, da dieser minimal ist und die Anforderung nach einer taktgenauen Repro- duzierbarkeit trotz des Vorlaufs gewährleistet ist.

Werden die Koppelsignaleingänge der NRTOS-Simulationstask nicht zur Verfügung ge- stellt, verharrt dieser im Warte-Zustand ohne eine Fehlermeldung auszugeben. Die RTOS- Simulationstask wird dagegen auch bei fehlenden Koppelsignaleingängen vom RTOS zur Durchführung der Teilmodellberechnung gezwungen. Abbildung 6.9a stellt die Über- schreitung der der NRTOS-Simulationstask zur Verfügung stehenden Simulationszeit dar. Ist die Überschreitung minimal ist es möglich, dass das Koppelsignal noch rechtzeitig bis zum Aufruf des Koppelsignal-Empfängerbausteins zur Verfügung steht. In Abbildung 6.9 ist die Überschreitung allerdings so groß, dass das Koppelsignal nicht mehr rechtzeitig

Abbildung 6.8: Ablauf der Taktung von NRTOS-Simulationstasks auf der NRT-Ebene

Simulationstask (NRTOS) Simulationstask (RTOS) t t *2 … Koppelsignal … Simulationstakt Simulations- start 1 0 2 Laufzeit Kommunikationsstrecke „Vorlauf“, da Koppelsignale bereits zur Verfügung

*1: Simulationstakt Simulationstask (RTOS) *2: Simulationstakt Simulationstask (NRTOS) 0: auf Trigger warten

1: auf Koppelsignal-Eingänge warten 2: Teilmodellberechnung * 1 1 0 2 a b b a

vorliegt. Daher kommt es in Abbildung 6.9b zu einer Signalverzerrung (vgl. Kapitel 6.2.3). Da das Koppelsignal nicht zur Verfügung steht, wird mit alten Signalwerten weitergerech- net und eine Warnung ausgegeben. Sobald das Koppelsignal vorliegt, wird es taktverzö- gert einsortiert. Am Ende des Simulationslaufs muss der Simulationsexperte entscheiden, ob die Simulation trotz der Verzerrung brauchbar ist. Beim Auftreten einer Signalverzer- rung geht die Reproduzierbarkeit des Simulationslaufs verloren (Abbildung 6.9c). Um das Auftreten einer Signalverzerrung zu verhindern gibt es zwei Möglichkeiten. Die eine Möglichkeit ist die Erhöhung des Simulationstakts in der NRTOS-Simulationstask, um mehr Zeit zur Modellberechnung und zum Ausgleich von variierenden Antwortzeiten zur Verfügung zu haben. In manchen Fällen ist dann allerdings der Simulationstakt zu groß für ein präzises Simulationsergebnis. Die zweite Möglichkeit ist, den Simulationstakt der NRTOS-Simulationstask beizubehalten und in einem n-fachen des Simulationstakts Kop- pelgrößen auszutauschen. Der Kommunikationstakt beträgt damit ein n-faches des Simu- lationstakts der NRTOS-Simulationstask (siehe Abbildung 6.10) und gleicht die variieren- den Antwortzeiten aus.

Der vorgestellte Kopplungsmechanismus ist um beliebige Simulationstasks erweiterbar. In der Koppelsignal-Abfrage werden alle Koppelsignale und damit der Empfang der Signale

Simulationstask (NRTOS) Simulationstask (RTOS) t t Überschreitung der Simulationszeit … Koppelsignal … Simulationstakt 1 0 2

Reproduzierbarkeit geht verloren 1

0 2

Signalverzerrung:

Notwendiges Kopplungssignal liegt nicht vor

Simulations- start

a

b

c

0: auf Trigger warten

1: auf Koppelsignal-Eingänge warten 2: Teilmodellberechnung

von allen gekoppelten Simulationstasks überprüft. Ein Simulationsfehler aufgrund fehlen- der Koppelsignale kann nur durch eine Simulationstask auf der Peripherie- oder der RT- Ebene ausgegeben werden, da diese Simulationstask vom RTOS zur Modellberechnung gezwungen werden.

6.4 Zusammenfassung Kapitel 6

In diesem Kapitel wurde die Phase der Echtzeitberechnung in einer Echtzeit-Co-Simulati- onsarchitektur betrachtet. Es wurden Mechanismen zur Durchführung der auf mehrere Simulationstasks verteilten Echtzeitberechnung betrachtet. Hierzu wurden ein Kopplungs- sowie ein Synchronisationsmechanismus entworfen.

In Kapitel 6.1 wurde in die, für die Echtzeitberechnung in einer Echtzeit-Co-Simulations- architektur notwendigen, Mechanismen eingeführt. Zur Durchführung der Echtzeitbe- rechnung besteht die Notwendigkeit der Entwicklung eines Kopplungsmechanismus so- wie eines Synchronisationsmechanismus. Als Ablaufsteuerung in der Echtzeit-Co-Simula- tion stellte sich das Jacobi-Schema als geeignet heraus, um durch eine parallele Berech- nung der einzelnen Simulationstasks eine Reduzierung der Rechenzeiten im Vergleich zu einer sequentiellen Simulation mit einer einzelnen Simulationstask zu erreichen.

Abbildung 6.10: Austausch von Koppelsignalen nach einer 4-fachen Taktung der NRTOS-Simulationstask 1 0 1 0 t Kommunikationstakt = 4 Simulationstakt 0 … Warten 1 … Teilmodellberechnung … Koppelsignal … Simulationstakt 1 2 3 4 t Simulationstask (NRTOS) Simulationstask (RTOS)

Im Anschluss betrachtete Kapitel 6.2 den Entwurf eines Kopplungsmechanismus. Kom- munikationsstrukturen lassen sich hinsichtlich einer zentralen und einer dezentralen Struk- tur unterscheiden. Im Hinblick auf die Echtzeitfähigkeit des zu entwickelnden Kopplungs- mechanismus stellte sich der dezentrale Ansatz als die performantere Lösung heraus. Zur Realisierung des dezentralen Ansatzes wurde ein Kommunikationsbaustein-Paar zur Sig- nalvorverarbeitung sowie zur Signalnachverarbeitung entworfen. Die notwendigen Me- chanismen betrachten die Reduktion auf notwendige Signale, die Einsortierung von Kop- pelsignalen, die Überprüfung auf Reproduzierbarkeit sowie die Modifikation der Koppel- signale.

Danach erarbeitete Kapitel 6.3 einen Synchronisationsmechanismus. Während auf der Pe- ripherie- und RT-Ebene die Taktung durch das RTOS erfolgt, ist für die Anbindung von NRTOS-Simulationstasks ein Synchronisationsmechanismus notwendig. Der Zeitfortschritt in einem Simulator lässt sich entweder selbstgetaktet oder fremdgetaktet realisieren. Da die Berechnung auf einem einzelnen Rechnersystem durchgeführt wird, wurde die Reali- sierung einer fremdgetakteten Simulationstask als die effizientere und performantere Lö- sung zur Begegnung der Problemstellung gesehen. Der in Kapitel 6.3 entworfene Syn- chronisationsmechanismus einer NRTOS-Simulationstask prüft zyklisch die Verfügbarkeit der Koppelsignaleingänge. Sobald alle Koppelsignaleingänge vorliegen wird ein Simulati- onsschritt durchgeführt. Damit synchronisieren sich die gekoppelten NRTOS-Simulations- tasks auf das RTOS auf. Bei der Konfiguration der Echtzeit-Co-Simulation muss allerdings durch eine großzügige Auslegung der Simulationstakte der NRTOS-Simulationstasks be- rücksichtigen werden, dass in den NRTOS-Simulationstasks variierende Antwortzeiten o- der eine erhöhte Berechnungszeit auftreten kann, die zu Verzögerungen im Ablauf füh- ren. In der entwickelten Datenhaltung liegt zu jedem Zeitpunkt nur ein einziger Wert eines Koppelsignals. Durch das Prinzip des „löschenden Lesens“ kann nur ein neuer Wert des Koppelsignals geschrieben werden, wenn das vorherige Koppelsignal abgeholt wurde. Damit liegt eine einwandfreie Synchronisation vor, die einen Verlust der Reproduzierbar- keit verlässlich erkennt.

An dieser Stelle ist zu erwähnen, dass sich der betrachtete Synchronisationsmechanismus auch für reine SILS-Anwendungen ohne Echtzeitanforderungen und der ausschließlichen Verwendung von NRTOS-Simulationstasks in der Co-Simulation eignet. Eine Verzögerung in einer Teilmodellberechnung verzögert beim Warten auf die Verfügbarkeit der Koppel- signale automatisch die Gesamtmodellberechnung im vollständigen Co-Simulationsnetz- werk unter Beibehaltung der Reproduzierbarkeit des Simulationslaufs. Allerdings läuft mit dem entworfenen Synchronisationsmechanismus die Simulation insgesamt so schnell wie möglich. Eine Synchronisation auf die reale Zeitachse kann erreicht werden, indem eine Simulationstask die Simulation auf die reale Zeit bremst und damit den anderen Simulati- onstasks die Koppelsignaleingänge für eine gewisse Zeitdauer vorenthält.

Die in den vorangegangenen Kapiteln entworfene Plattform zur Echtzeit-Co-Simulation für die HILS-RTOS soll abschließend realisiert und die Machbarkeit anhand von zwei bei- spielhaften Simulationsszenarien validiert werden.

Zunächst werden in Kapitel 7.1 die ausgewählten Simulationsszenarien vorgestellt. Ein Simulationsszenario betrachtet die Erhöhung der Modelltiefe und ein Szenario die Erhö- hung des Modellumfangs (vgl. Abbildung 1.5). In Kapitel 7.2 folgt die Umsetzung der Plattform zur Echtzeit-Co-Simulation. In Kapitel 7.3 wird aufgezeigt, wie mit der entwor- fenen Plattform zur Echtzeit-Co-Simulation der Problemstellung dieser Arbeit in den ge- wählten Simulationsszenarien begegnet werden kann. Die Anwendung und die Realisie- rung werden anhand der Problemstellung und den Anforderungen bewertet.

Alle präsentierten Ergebnisse wurden auf einem handelsüblichen Desktop-PC mit Intel® Core™ i7-6700K CPU @ 4.00 GHz und 32,0 GB Arbeitsspeicher durchgeführt. Auf dem Simulations-PC kommt als Betriebssystem Windows 10 Enterprise 64-Bit der Firma Micro- soft Corporation4 mit der Echtzeiterweiterung TwinCAT 3.1.4022.20 der Firma Beckhoff

Automation GmbH & Co. KG5 zum Einsatz.

Im Dokument Plattform zur Echtzeit-Co-Simulation für die virtuelle Inbetriebnahme (Seite 119-132)