-
Die Erfindung betrifft ein Verfahren zur ereignisbasierten Simulation eines Systems.
-
In der Entwicklung elektronischer Steuergeräte, welche verbreitet auch kurz als ECU (engl. Electronic Control Unit) bezeichnet werden, liegt heutzutage ein Fokus auf einer virtuellen Absicherung und damit auf frühzeitigen Tests im Entwicklungsprozess. Diese finden statt, bevor das elektronische Steuergerät an seinem Bestimmungsort getestet wird und oft bevor überhaupt ein Prototyp der zukünftigen Steuergeräte-Hardware vorliegt. Ein solches reales Steuergerät ist meist ein vollwertiger Rechner mit einem Betriebssystem und Eingangs- und Ausgangsschnittstellen (I/O-Schnittstellen), welche an ein Bussystem angebunden sind, mittels welchem das Steuergerät mit weiteren Steuergeräten kommunizieren kann. Das verwendete Betriebssystem muss oft Echtzeitbedingungen erfüllen, da die Steuergeräte in ihrem Bestimmungseinsatz sicherheitskritische Funktionalitäten abbilden sollen. Die Aufgaben der Steuergeräte sind zumeist steuerungs- und regelungstechnischer Natur und finden beispielsweise Anwendung im automotiven Bereich oder der Luft- und Raumfahrttechnik. Beispiele für solche Funktionalitäten sind die Regelung eines Verbrennungsmotors durch ein Motorsteuergerät oder die Steuerung von Fahrassistenzsystemen wie eine geschwindigkeitsadaptive Distanzregelung. In diesen Anwendungsbereichen ist die Vernetzung der Steuergeräte untereinander ein wichtiger Aspekt, da diese untereinander in einem Wirkzusammenhang stehen.
-
In der eingangs erwähnten frühzeitigen Absicherung werden häufig Software-in-the-Loop-Simulationen (auch: SIL-Simulation) verwendet, mittels welcher der fertige Produktivcode in einer virtuellen Umgebung getestet werden kann, ohne eine Steuergeräte-Hardware zu benötigen. Dafür werden virtuelle Steuergeräte eingesetzt, auf denen der Produktivcode ausgeführt wird. Virtuelle Steuergeräte simulieren die Steuergeräte-Hardware und sind die wie physikalisch vorhandene, reale Steuergeräte in der Lage, mittels I/O-Schnittstellen und Bussystem untereinander Nachrichten auszutauschen, Messungen von Sensordaten zu empfangen und auf Aktoren einzuwirken. Dafür wird eine SIL-Simulationsumgebung benötigt, die Sensordaten und das Verhalten des Bussystems simuliert, sowie das virtuelle Steuergerät bereitstellt, welches für die reale Steuergerätehardware eintritt. Dieses virtuelle Steuergerät umfasst dann auch die Softwarekomponenten, die im realen Fall zur Hardwareplattform gehören und von dem darauf ausgeführten Produktivcode zu unterscheiden sind. Diese Softwarekomponenten umfassen beispielsweise ein Betriebssystem mit Kernel und Hardwareabstraktionsschicht, eine Laufzeitumgebung, diverse Dienste für System und Kommunikation, und weitere Komponenten. Diese Funktionalitäten werden dann virtuell nachgebildet und mittels eines Simulators simuliert. Ein Simulator kann beispielsweise durch eine oder mehrere physikalisch real vorhandene Recheneinheiten gegeben sein, die auf die Simulationsaufgabe spezialisiert sind. Ebenso kann es sich um virtuell emulierte Recheneinheiten handeln, die auf einem handelsüblichen PC ausgeführt werden. Möglich ist auch, das virtuelle Steuergerät auf einem Echtzeitsystem wie einem HIL-Simulator auszuführen. Innerhalb des Simulators treten das oder die virtuellen Steuergeräte in Interaktion mit der Simulationsumgebung, die im Folgenden auch Simulator-Applikation genannt wird. Das virtuelle Steuergerät hat dazu eine äußere Datenschnittstelle, die den Austausch von Nachrichten mit einer entsprechenden Datenschnittstelle der Simulator-Applikation erlaubt. Diese Art der Simulation ist im Stand der Technik bekannt und kann beispielsweise in der Dokumentation zu den Produkten dSPACE SystemDesk V-ECU Generation Module oder dSPACE VEOS nachgelesen werden.
-
In diesem frühen Stadium des Steuergeräteentwicklungsprozesses ist es noch nicht erforderlich oder auch nicht gewünscht die Simulation, wie später im Fall von HIL-Tests des fertigen Steuergeräts, unter Echtzeitbedingungen durchzuführen. Da das Steuergerät hier simuliert wird, wird auch die real vorhanden Steuergeräte-Uhr in der Simulation abgebildet. Daher erfolgt die Simulation entlang einer simulierten Zeit, im Folgenden auch Simulationszeit genannt. Diese schreitet nicht zwingend gekoppelt an die echte, außerhalb der Simulation vergehende Zeit, voran. Die Simulationszeit verhält sich also asynchron und kann schneller oder langsamer als die wirkliche Zeit vergehen, abhängig von der Taktfrequenz und Anzahl der verwendeten Recheneinheit, und davon ob die Simulation angehalten wird. Man spricht daher im Fall dieser Simulationen von Offline-Simulationen, die auch auf einem handelsüblichen Computer durchgeführt werden können.
-
Bei solchen Offline-Simulationen bedient man sich dem Konzept der ereignisbasierten Simulation. Bei ereignisbasierten Simulationen schreitet die Simulation entlang einer Liste von abzuarbeitenden Ereignissen voran. Dabei werden nur die diskreten Ereignisse zu den Zeitpunkten simuliert, zu denen sie in der Liste, hier als Ereigniswarteschlange bezeichnet, vorgesehen sind. Die Zeit zwischen den Ereignissen wird nicht simuliert. Diese Vorgehensweise ermöglicht es, bei großen Schrittweiten zwischen zwei diskreten Ereignissen lange virtuelle Zeiträume innerhalb kurzer real vergehender Zeit zu simulieren. Darüber hinaus wird die Simulation von der sogenannten Nullzeitannahme beherrscht, was bedeutet, dass die Ereignisse selbst aus Sicht der Simulationszeit als instantan ausgeführt angenommen werden. Die Ausführungszeit, die ein solches Ereignis auf einem realen Steuergerät benötigen würde, wird nicht in der Simulation abgebildet.
-
Die Systeme aus Steuergeräten in heutigen Kraftfahrzeugen werden immer komplexer, und auch die Aufgaben, die diese Steuergeräte beispielsweise für Fahrassistenzsysteme - auch im Kontext des allseits angestrebten autonomen Fahrens - werden zunehmend umfangreicher werden. Dies hat selbstverständlich auch Auswirkungen auf die Komplexität der Testsysteme, mittels der eine frühzeitige virtuelle Absicherung solcher Steuergerätefunktionen erzielt wird. Daraus folgende Simulationsmodelle stellen erhebliche Anforderung an Rechenleistung und Speicherbedarf des vom Simulator verwendeten Rechnersystems. Vor diesem Hintergrund kann es notwendig sein, die Berechnung verschiedener Simulationsobjekte, bei denen es sich beispielsweise um virtuelle Steuergeräte handeln kann, auf verschiedene Recheneinheiten aufzuteilen. Dabei ist es unerheblich, ob die Recheneinheiten als physikalisch vorhandener Rechenknoten vorliegen oder ob es sich um in einem Hypervisor virtualisierte Recheneinheiten handelt. Dies kann beispielsweise auch notwendig sein, wenn Simulationsobjekte nicht auf dem Betriebssystem des verwendeten Simulators lauffähig sind, oder wenn es wie oben beschrieben erforderlich ist, die Rechenlast auf mehrere Rechner zu verteilen.
-
In diesem Fall gibt eine zentrale Recheneinheit, auf der die Ereigniswarteschlange verwaltet wird, die geltende Simulationszeit vor. Sie hat dann die Aufgabe, die verteilten und mit der zentralen Recheneinheit verbundenen Recheneinheiten zum Ausführen eines anstehenden Ereignisses anzutriggern. Auf diesen werden die Simulationsobjekte in ihrem jeweiligen Betriebssystem ausgeführt. Dabei kommt es regelmäßig vor, dass ein Simulationsobjekt einen Betriebssystemaufruf tätigt, um das anstehende Ereignis abzuarbeiten. Bei einem solchen Betriebssystemaufruf wird gegebenenfalls die Zeit aus der Zeitbasis des verteilten Systems abgefragt. Dabei stimmt dann aber die vom Simulationsobjekt derart abgefragte Zeit nicht mit der zentralen Simulationszeit überein, was gegebenenfalls zu einem fehlerhaften Verhalten der Simulation führt.
-
Vor diesem Hintergrund besteht die Aufgabe der Erfindung darin, den Stand der Technik weiterzubilden.
-
Die Aufgabe wird gelöst durch ein Verfahren zur ereignisbasierten Simulation eines Systems mit den Merkmalen des Patentanspruchs 1. Vorteilhafte Ausführungsformen sind Gegenstand der von Patentanspruch 1 abhängigen Unteransprüche.
-
Gemäß dem Gegenstand des Verfahrens zur ereignisbasierten Simulation eines Systems wird eine Simulation auf einem Rechnersystem umfassend eine erste Recheneinheit und wenigstens eine zweite Recheneinheit ausgeführt, wobei die erste Recheneinheit eine Simulationszeit hat, wobei die zweite Recheneinheit eine Betriebssystemschicht und eine Applikationsschicht aufweist, wobei die zweite Recheneinheit in der Betriebssystemschicht eine Systemzeit aufweist, wobei wenigstens die zweite Recheneinheit eine Simulator-Applikation ausführt, wobei auf der Simulator-Applikation wenigstens ein Simulationsobjekt ausgeführt wird, und wobei die erste Recheneinheit eine Ereigniswarteschlange verwaltet, wobei in der Ereigniswarteschlange wenigstens ein Ereignis pro Simulationsschritt aufgelistet ist, und dem Ereignis ein durch das Simulationsobjekt auszuführender Prozess und ein zur Ausführung des Prozesses vorgesehener Simulationszeitpunkt zugeordnet sind, wobei die zweite Recheneinheit einen virtuellen Taktgeber aufweist, wobei das Verfahren für jeden Simulationsschritt die folgenden Schritte aufweist: Übermitteln, durch die erste Recheneinheit, eines Startsignals an den virtuellen Taktgeber zum Ausführen eines nächsten Simulationsschritts in der zweiten Recheneinheit, und basierend auf einer Zeitdifferenz zwischen einem vergangenen Simulationsschritt und der Simulationszeit, Inkrementieren der Systemzeit der zweiten Recheneinheit, und Ausführen des anstehenden Prozesses zu dem dem Prozess zugeordneten Simulationszeitpunkt.
-
Im Kontext des erfindungsgemäßen Verfahrens wird unter einem Rechnersystem ein Verbund aus Recheneinheiten verstanden, die jeweils ein eigenes Betriebssystem aufweisen und auf denen Applikationen ausführbar sind. In diesem Rechnersystem hat eine erste Recheneinheit, welche in den folgenden Ausführungen als zentrale Recheneinheit bezeichnet wird, von der ausgehend das Fortschreiten der Simulation verwaltet wird. Darüber hinaus sind in dem Rechnersystem eine zweite oder mehrere weitere Recheneinheiten enthalten, die mit der ersten Recheneinheit über ein Bussystem verbunden sind. Das Bussystem kann auf Ethernet oder auf weiteren Bussystemen basieren. Die weiteren Recheneinheiten werden als verteilte Recheneinheiten bezeichnet, auf denen die Simulation ausgeführt werden. Die Simulation umfasst die Ausführung eines oder mehrerer Simulationsobjekte auf der den verteilten Recheneinheiten oder auch auf der zentralen Recheneinheit. Diese Simulationsobjekte können beispielsweise virtuelle Steuergeräte, Simulink-Modelle, Functional Mock-up Units (FMUs), oder virtuelle Steuergeräte nach einem AUTOSAR-Standard sein. Die beteiligten Simulationsobjekte können dabei in einem Wirkzusammenhang stehen. Dies bedeutet, dass beispielsweise ein Simulationsobjekt während der Ausführung der Simulation das Berechnungsergebnis eines Prozesses einem weiteren Simulationsobjekt zusendet und dieses in einem folgenden Simulationsschritt basierend auf diesem Berechnungsergebnis weitere Prozesse ausführt. Das Zusenden des Berechnungsergebnisses kann hierbei mittels des Bussystems erfolgen.
-
Zur Ausführung der Simulationsobjekte werden auf den verteilten Recheneinheiten Simulator-Applikationen ausgeführt. Darunter wird eine Applikation verstanden, die die ihr zugeordneten Simulationsobjekte verwaltet und die Prozesse startet, die den verwalteten Simulationsobjekten zugeordnet sind. Außerdem empfängt die Simulator-Applikation Berechnungsergebnisse von Simulationsobjekten auf anderen Recheneinheiten zur Weiterverarbeitung durch ihr zugeordneten Simulationsobjekten und/oder leitet Berechnungsergebnisse der ihr zugeordneten Simulationsobjekte an Simulationsobjekte auf anderen Recheneinheiten weiter.
-
In diesem Zusammenhang wird unter einer ereignisbasierten Simulation eines Systems eine Simulation verstanden, die anhand einer Liste von abzuarbeitenden Ereignissen, welche hier Ereigniswarteschlange genannt wird, fortschreitet. Dabei wird die Zeit, die zwischen den Ereignissen vergeht, nicht simuliert. Das Fortschreiten der Simulation orientiert sich dabei an der Simulationszeit, die durch die zentrale Recheneinheit vorgegeben wird, die die Ereigniswarteschlange verwaltet. Dafür kann die zentrale Recheneinheit beispielsweise ihre interne Hardwareuhr verwenden. Die Ereigniswarteschlange listet zu jedem Ereignis jeweils einen auszuführenden Prozess und einen Simulationszeitpunkt auf, zu dem die Ausführung stattfinden soll, sowie gegebenenfalls eine Nachricht an die ausführende Recheneinheit. Sobald also der Simulationszeitpunkt eines Ereignisses gekommen ist, wird dieses ausgeführt und überführt die Simulation in den nächsten Simulationszustand. Ist das Simulationsobjekt, welchem das nächste anstehende Ereignis zugeordnet ist, auf einer der verteilten Recheneinheiten, ist der korrekte Zeitpunkt zur Ausführung des zugehörigen Prozesses aus Sicht des Simulationsobjekts erstmal unbekannt. Das liegt daran, dass das Simulationsobjekt ohne weiteres bei Zeitabfragen an das Betriebssystem der verteilten Recheneinheit erstmal die Systemzeit der Recheneinheit zurückgeliefert bekommt. Diese stimmt aber nicht notwendigerweise mit der Simulationszeit überein. Das erfindungsgemäße Verfahren sieht daher vor, auf den verteilten Recheneinheiten virtuelle Taktgeber zu verwenden, welche als Zeitgeber für das Betriebssystem auf der jeweiligen Recheneinheit fungiert. Dieser erhält zu Beginn eines jeden Simulationsschritts ein Startsignal für diesen Simulationsschritt von der ersten Recheneinheit. Dieses Startsignal enthält die Information, dass der nächste Simulationsschritt ausgeführt werden kann. Wie diese Information übertragen wird, spielt keine Rolle. Im einfachsten Fall reicht schon ein Bit wie beispielsweise eine steigende Flanke, oder ein Wechsel von 0 zu 1.
-
Mittels des Startsignals und der darin enthaltenden Information über die Simulationszeit kann die zweite Recheneinheit nun ihre Systemzeit auf die korrekte Simulationszeit inkrementieren. Das ist nun so zu verstehen, dass die zweite Recheneinheit aus dem vorangegangenen Simulationsschritt die geltende Simulationszeit und die zu diesem Zeitpunkt passende Systemzeit kennt. Zu Beginn des neuen Simulationsschritts erhält die zweite Recheneinheit nun die für diesen Simulationsschritt geltende Simulationszeit. Die zweite Recheneinheit kann nun ihre Systemzeit um die Zeitdifferenz zwischen diesen beiden Simulationszeitpunkten - des vergangenen und des neuen Simulationsschritts - nachkorrigieren. Der im neuen Simulationsschritt anstehende Prozess wird dann zum korrekten Simulationszeitpunkt berechnet.
-
Das erfindungsgemäße Verfahren ermöglicht eine vorteilhafte Entkopplung der eventbasierten Simulation von der realen, außerhalb der Simulation ablaufenden Zeit. Dadurch wird es möglich, Simulationsergebnisse sicher zu reproduzieren, was ohne die Erfindung nicht der Fall wäre. Zudem ist es möglich, die Simulation schneller oder langsamer als in Echtzeit ablaufen zu lassen und zu pausieren.
-
In einer vorteilhaften Ausgestaltung der Erfindung ist vorgesehen, dass die Zeitdifferenz zwischen dem vorangegangenen und dem neuen Simulationsschritt bereits durch die erste Recheneinheit berechnet wird und mit dem Startsignal an den virtuellen Taktgeber auf der zweiten oder einer weiteren verteilte Recheneinheit übertragen wird.
-
In einer weiteren vorteilhaften Ausgestaltung der Erfindung ist vorgesehen, dass zunächst die aktuelle Simulationszeit von der ersten Recheneinheit zusammen mit dem Startsignal an die zweite oder eine weitere verteilte Recheneinheit übertragen wird. Die Simulatorapplikation auf der zweiten Recheneinheit bildet die Zeitdifferenz dann und der virtuelle Taktgeber inkrementiert die Systemzeit so, dass diese mit der Simulationszeit übereinstimmt.
-
Eine weitere vorteilhafte Ausgestaltung der Erfindung sieht vor, dass die erste und die zweite bzw. weitere verteilte Recheneinheiten über Netzwerkschnittstellen verfügen, mittels der die Kommunikation zwischen den Recheneinheiten über das Bussystem ermöglicht wird.
-
In einer weiteren vorteilhaften Ausgestaltung der Erfindung ist vorgesehen, dass die Simulationsobjekte auf dem gleichen Betriebssystem ausgeführt werden wie die Simulator-Applikation, die die Simulationsobjekte verwaltet. Das verwendete Betriebssystem kann beispielsweise auf Linux basieren und/oder ein Echtzeitbetriebssystem sein. Da die Simulationsobjekte während der Simulation Betriebssystemaufrufe können, ist das jeweilige Betriebssystem als Teil der Simulation zu betrachten.
-
In einer weiteren vorteilhaften Ausgestaltung der Erfindung ist vorgesehen, dass die Simulationsobjekte in einer abgeschlossenen Umgebung ausgeführt werden. Das bedeutet, dass den Simulationsobjekten der Zugriff auf Hardwareressourcen nur soweit erlaubt ist, wie es für die Simulation notwendig ist. Insbesondere wird der Zugriff der Simulationsobjekte auf die Systemzeit der verteilten Recheneinheit unterbunden, da ansonsten die Synchronisierung mit der Simulationszeit nicht mehr gewährleistet wäre. Den Simulationsobjekten kann in der abgeschlossenen Umgebung, welche beispielsweise eine Sandbox sein kann, Zugriff auf Festplattenspeicher, Netzwerkschnittstelle, Arbeitsspeicher, Prozessorkernen, und weiteres erlaubt sein.
-
Eine weitere vorteilhafte Ausgestaltung der Erfindung sieht vor, dass die erste und die zweite bzw. weitere verteilte Recheneinheiten über virtuelle Netzwerkschnittstellen verfügen, mittels der die Kommunikation zwischen den Recheneinheiten über ein virtuelles Bussystem ermöglicht wird. Dies ermöglicht die Ausführung der Simulation auf mehreren, virtuellen Rechenknoten.
-
Eine weitere vorteilhafte Ausgestaltung der Erfindung sieht vor, dass ein oder mehrere der Simulationsobjekte in der Simulation durch virtuelle Steuergeräte gegeben sind, die das Verhalten physikalisch vorliegender Steuergeräte nachbilden. Unter einem virtuellen Steuergerät wird eine Software-Applikation verstanden, die die umfangreichen Komponenten eines Seriensteuergeräts wie zum Beispiel Laufzeitumgebung, Systemdienste, Kommunikationsdienste, oder Hardwareabstraktionsschicht, nachbildet um in einem Simulator simuliert werden zu können.
-
In einer weiteren vorteilhaften Ausgestaltung der Erfindung ist vorgesehen, dass die die Berechnungsergebnisse der Simulationsobjekte von der virtuellen Netzwerkschnittstelle einer ersten Recheneinheit über einen Netzwerktunnel an die virtuelle Netzwerkschnittstelle einer zweiten Recheneinheit übertragen werden.
-
Eine weitere vorteilhafte Ausgestaltung der Erfindung sieht vor, dass die verwendeten Recheneinheiten jeweils physikalische Rechenknoten sind.
-
Eine weitere vorteilhafte Ausgestaltung der Erfindung sieht vor, dass die verwendeten Recheneinheiten virtuelle Rechenknoten sind, wobei dessen Betriebssystem von einem Hypervisor ausgeführt wird.
-
In einer weiteren vorteilhaften Ausgestaltung der Erfindung ist vorgesehen, dass der virtuelle Taktgeber in der Applikationsschicht implementiert ist.
-
In einer weiteren vorteilhaften Ausgestaltung der Erfindung ist vorgesehen, dass der virtuelle Taktgeber in der Betriebssystemschicht implementiert ist.
-
Die Erfindung wird nachfolgend unter Bezugnahme auf die Zeichnungen näher erläutert. In den Zeichnungen sind Teile gleicher Gattung mit gleichlautenden Bezeichnern beschriftet.
- 1 eine schematische Ansicht auf eine Ausführungsform der Erfindung mit einem System aus drei Recheneinheiten
- 2 eine Darstellung des zeitlichen Ablaufs einer ereignisbasierten Simulation auf zwei Recheneinheiten unter Anwendung des aus dem Stand der Technik bekannten Verfahrens
- 3 eine Darstellung des zeitlichen Ablaufs einer ereignisbasierten Simulation auf zwei Recheneinheiten unter Anwendung des erfindungsgemäßen Verfahrens
-
1 zeigt eine Abbildung einer Ausführungsform der Erfindung auf einem verteilten Rechnersystem, welches drei Recheneinheiten RE1, RE2 und RE3 umfasst. Die Anzahl der Recheneinheiten in diesem Ausführungsbeispiel ist willkürlich gewählt. Genauso wie in 1 skizziert und im Folgenden erläutert würde die Erfindung auch auf einem Rechnersystem bestehend aus zwei, vier oder mehr Recheneinheiten funktionieren. Es ist außerdem unerheblich, ob die Recheneinheiten als physikalische Rechenkerne oder virtuelle Rechenknoten vorliegen. Die Recheneinheiten RE1, RE2, und RE3 weisen jeweils ein Betriebssystem OS auf, auf dem jeweils eine Simulatorapplikation SAP1, SAP2 oder SAP3 ausgeführt wird. Das Betriebssystem OS ist nicht notwendigerweise auf jeder Recheneinheit das gleiche. Die Aufgabe der Simulatorapplikation SAP1 auf Recheneinheit RE1 ist die Verwaltung einer Ereigniswarteschlange, welche zur Durchführung der ereignisbasierten Simulation abgearbeitet wird. Die Ereigniswarteschlange umfasst eine Auflistung von Ereignissen, und eine Zuordnung von den Ereignissen zugeordneten Prozessen TASK und die Information zu welchem Zeitpunkt in der Simulationszeit die aufgelisteten Ereignisse abzuarbeiten sind, sowie die Information durch welche Recheneinheit die Ausführung vorgesehen ist. Bei Ausführung der Simulation sendet die Simulatorapplikation SAP1 auf der zentralen Recheneinheit RE1 ein Startsignal an die Simulatorapplikation SAP2 und SAP3, die zur Ausführung des anstehenden Ereignisses vorgesehen ist.
-
Die Simulatorapplikationen SAP2 und SAP3 auf den Recheneinheiten RE2 und RE3 haben wiederrum die Aufgabe, die Abarbeitung der Ereignisse durch die jeweils zuständige verteilte Recheneinheit RE2 oder RE3 anzustoßen, sobald das Startsignal S1 erhalten wurde und der Zeitpunkt der Simulationszeit gekommen ist, zu der die Ausführung des Ereignisses durch die mit dem Ereignis assoziierten Recheneinheit vorgesehen ist. Nach Abarbeiten des Ereignisses sendet die Simulatorapplikation der jeweils ausführende Recheneinheit ein Abschlusssignal S2 (nicht in 1 dargestellt) an die Simulatorapplikation SAP1 auf der zentralen Recheneinheit RE1. Das Abschlusssignal signalisiert, dass die Abarbeitung des Ereignisses erfolgt ist.
-
Zum Austausch der Start- und Abschlusssignale weisen die Recheneinheiten RE1, RE2, und RE3 darüber hinaus jeweils eine Netzwerkschnittstelle ETH1, ETH2, und ETH3 auf, welche an ein Bussystem BUS angeschlossen sind, welches den Simulatorapplikationen SAP1, SAP2 und SAP3 den Austausch von Nachrichten zwischen der zentralen Recheneinheit RE1 und den verteilten Recheneinheiten RE2 und RE3 erlaubt. Diese Netzwerkschnittstellen ETH1, ETH2, und ETH3 können beispielsweise durch einen Ethernet-Controller realisiert werden. Die Recheneinheiten tauschen dann Nachrichten basierend auf einem Ethernet-Protokoll aus.
-
Im Ausführungsbeispiel, welches 1 zugrunde liegt, ist die Rolle der Recheneinheit 1 eine zentrale Recheneinheit zu bilden, während Recheneinheiten RE2 und RE3 verteilte Recheneinheiten darstellen.
-
Recheneinheiten RE2 und RE3 weisen zusätzlich zu den bereits beschriebenen Komponenten jeweils einen virtuellen Taktgeber VCLK, einen Betriebssystem-Kernel KRN und eine abgeschlossene Umgebung BOX auf. In der abgeschlossenen Umgebung BOX werden die Simulationsobjekte ausgeführt, die der jeweiligen verteilten Recheneinheit RE2 oder RE3 zur Ausführung zugeordnet sind, wobei hier die Simulationsobjekte SO1 und SO2 der Recheneinheit RE2 und die Simulationsobjekte SO3 und SO4 der Recheneinheit RE3 zugeordnet sind. Diese abgeschlossene Umgebung kann beispielsweise eine Sandbox sein, oder ein Kernel Namespace, falls das verwendete Betriebssystem OS auf der jeweiligen Recheneinheit RE2 oder RE3 Linux-basiert ist. Die Aufgabe der abgeschlossenen Umgebung ist sicherzustellen, dass die darin ausgeführten Simulationsobjekte lediglich auf die ihnen zugewiesenen Hardware-Ressourcen Zugriff haben. Diese Hardware-Ressourcen können zum Beispiel Festplatten-Speicher, die Netzwerkschnittstellen ETH2 oder ETH3, ein oder mehrere Prozessor-Kerne, oder der Arbeitsspeicher sein.
-
Die Recheneinheiten RE2 und RE3 weisen in diesem Ausführungsbeispiel jeweils einen virtuellen Taktgeber VCLK auf. Die Aufgabe des virtuellen Taktgebers VCLK ist, die Systemzeit im Betriebssystem-Kernel KRN der verteilten Recheneinheiten entsprechend einer ermittelten Taktdifferenz zwischen einem vergangenen Simulationsschritt und der zum Zeitpunkt des Ermittelns geltenden Simulationszeit zu inkrementieren. In diesem Sinne ist der virtuelle Taktgeber als virtueller Ersatz für den originalen Taktgeber zu verstehen, den die betreffende Recheneinheit zum Inkrementieren ihrer Systemzeit verwenden würde. Da die ermittelte Taktdifferenz direkten Bezug zur Simulationszeit hat, die durch die zentrale Recheneinheit RE1 vorgegeben wird, verwenden die verteilten Recheneinheiten so indirekt die zentrale Simulationszeit als Systemzeit. Die Ermittlung der Taktdifferenz kann dabei durch den virtuelle Taktgeber VCLK selbst erfolgen, oder auch schon von der ersten Recheneinheit RE1 berechnet und an den virtuellen Taktgeber übermittelt worden sein. In beiden Fällen verwendet der virtuelle Taktgeber die Taktdifferenz um die Systemzeit in der verteilten Recheneinheit - in diesem Ausführungsbeispiel Recheneinheiten RE2 oder RE3 - zu inkrementieren und mit der Simulationszeit zu synchronisieren.
-
In der Abbildung der 2 ist eine Skizze des zeitlichen Ablaufs einer ereignisorientierten Simulation gemäß des Verfahrens, wie es im Stand der Technik bekannt ist. In diesem Beispiel finden sich zwei Recheneinheiten RE1 und RE2. Die Anzahl ist hier völlig willkürlich gewählt, genauso würde sich der abgebildete Sachverhalt auch auf drei oder mehr Recheneinheiten darstellen.
-
2 zeigt den zeitlichen Ablauf der Abarbeitung der Prozesse, der Simulationsobjekte SO1 und SO2 auf der Recheneinheit RE1, dargestellt im oberen System, und des Simulationsobjekts SO3 auf der Recheneinheit RE2, dargestellt im unteren System. Bei den Simulationsobjekten SO1, SO2, und SO3 kann es sich beispielsweise um virtuelle Steuergeräte handeln. Die erste Recheneinheit RE1 ist in diesem Beispiel als Simulator ausgestaltet, das heißt auf der Recheneinheit RE1 wird eine Simulator-Applikation SAP ausgeführt. Diese verwaltet die Ereigniswarteschlange (nicht dargestellt) und startet die Ausführung der in der Ereigniswarteschlange als nächstes anstehenden Prozesse durch die Simulationsobjekte SO1 und SO2, in dem sie ein Startsignal S1 übermittelt. Die Recheneinheit RE2 ist eine verteilte Komponente, welche getrennt von der Recheneinheit RE1 und der darauf laufenden Simulator-Applikation ausgeführt wird. Auf Recheneinheit RE2 wird das Simulationsobjekt SO3 ausgeführt.
-
Mit dem Startsignal S2 startet der erste Simulationsschritt Step 1, und die Simulationsobjekte SO1 und SO2 führen jeweils die Prozesse PRZ1 und PRZ2 aus. Sobald sie damit fertig sind, melden sie die Beendung durch ein Abschlusssignal S2 an die Simulator-Applikation SAP zurück. In diesem Beispiel ist zunächst Simulationsobjekt SO1 fertig, dann folgt Simulationsobjekt SO2. Sobald beide mit Prozessen beauftragten Simulationsobjekte fertig sind, endet der Simulationsschritt. Nach Beendung des Simulationsschritts werden die Berechnungsergebnisse der Simulationsobjekte an andere Simulationsobjekte übermittelt, die das Berechnungsergebnis für ihren nächsten ausgeführten Prozess benötigen. Im Beispiel wird das Berechnungsergebnis von Simulationsobjekt SO1 vor dem Beginn von Simulationsschritt Step 2 an das Simulationsobjekt SO2 über ein Bussystem übermittelt. Das Berechnungsergebnis von Simulationsobjekt SO2 wird für den nächsten Simulationsschritt von Simulationsobjekt SO3 benötigt und an dieses übermittelt.
-
Mit dem nächsten Startsignal S1 startet der nächste Simulationsschritt Step 2, und auf Recheneinheit RE1 führt Simulationsobjekt SO1 den Prozess PRZ3 aus, Simulationsobjekt SO2 führt den Prozess PRZ4 unter Verwendung des Berechnungsergebnisses aus Step 1 von Simulationsobjekt SO1 aus, und auf Recheneinheit 2 führt das Simulationsobjekt SO3 den Prozess PRZ5 aus. Sobald die Simulationsobjekte SO1 und SO2 ihre Prozesse - PRZ3 und PRZ4 - fertig berechnet haben, melden sie wieder ein Abschlusssignal S2 an die Simulator-Applikation SAP. Da Simulationsobjekt SO3 in diesem Beispiel nicht zeitlich synchron simuliert wird, sondern lediglich auf die Berechnungsergebnisse von Simulationsobjekt SO2 reagiert, endet der Simulationsschritt bevor die Simulationsobjekt SO3 die Berechnung des Prozesses PRZ5 abschließen kann. Während hier noch weiter berechnet wird, werden in Simulationsobjekten SO1 und SO2 weitere Prozesse simuliert. Im einfachsten Fall handelt es sich um Prozesse CHECK welche lediglich prüfen ob neue Berechnungsergebnisse vorliegen. Falls das nicht der Fall ist, wird der Simulationsschritt wieder beendet indem Abschlusssignal S2 an die Simulator-Applikation SAP gemeldet wird. Diese Abfrage wird so lange wiederholt und damit Simulationsschritte angehäuft, bis ein Simulationsobjekt SO3 ein neues Berechnungsergebnis für SO2 zur Verfügung stellt. Dies ist in diesem Ausführungsbeispiel dann der Fall, wenn das Simulationsobjekt SO3 auf Recheneinheit RE2 mit der Berechnung des Prozesses PRZ5 fertig ist. Simulationsobjekt SO3 sendet nach Beendung der Berechnung sein Berechnungsergebnis an den vorher festgelegten Empfänger - hier ist das das Simulationsobjekt SO2 - welcher das im folgenden Simulationsschritt Step 1000 in einen Buffer schreibt. In diesem Beispiel kann das Berechnungsergebnis von PRZ5 also erst bei Simulationsschritt Step 1000 an Simulationsobjekt SO2 übermittelt werden.
-
Da jeder Simulationsschritt einer Simulationszeit zugeordnet ist, erhält SO2 das Berechnungsergebnis fälschlicherweise zum 1000ten Simulationszeitpunkt, obwohl das Berechnungsergebnis wegen der Nullzeitannahme schon nach dem zweiten Simulationsschritt vorliegen müsste.
-
In der Abbildung der 3 ist eine Skizze des zeitlichen Ablaufs einer ereignisorientierten Simulation nach dem erfindungsgemäßen Verfahren.
-
3 zeigt den zeitlichen Ablauf der Abarbeitung der Prozesse, der den Simulationsobjekten SO1 und SO2 auf der Recheneinheit RE1, dargestellt im oberen System, und des Simulationsobjekts SO3 auf der Recheneinheit RE2, dargestellt im unteren System. Bei den Simulationsobjekten SO1, SO2, und SO3 kann es sich beispielsweise um virtuelle Steuergeräte handeln. Die erste Recheneinheit RE1 ist in diesem Beispiel als Simulator ausgestaltet, das heißt auf der Recheneinheit RE1 wird eine Simulator-Applikation SAP1 ausgeführt. Diese verwaltet die Ereigniswarteschlange (nicht dargestellt) und startet die Ausführung der in der Ereigniswarteschlange als nächstes anstehenden Prozesse durch die Simulationsobjekte SO1 und SO2, und SO3 in dem sie ein Startsignal S1 übermittelt. Die Recheneinheit RE2 ist eine verteilte Komponente, welche getrennt von der Recheneinheit RE1 und der darauf laufenden Simulator-Applikation SAP1 ausgeführt wird. Auf Recheneinheit RE2 wird eine Simulator-Applikation und das Simulationsobjekt SO3 ausgeführt.
-
Mit dem Startsignal startet der erste Simulationsschritt Step 1, und die Simulationsobjekte SO1 und SO2 führen jeweils die Prozesse PRZ 1 und PRZ 2 aus. Sobald sie damit fertig sind, melden sie die Beendung durch ein Abschlusssignal S2 an die Simulator-Applikation SAP1 zurück. In diesem Beispiel ist zunächst Simulationsobjekt SO1 fertig, dann folgt Simulationsobjekt SO2. Sobald beide mit Prozessen beauftragten Simulationsobjekte fertig sind, endet der Simulationsschritt. Nach Beendung des Simulationsschritts übermitteln die Simulationsobjekte ihre Berechnungsergebnisse an andere Simulationsobjekte, die das Berechnungsergebnis für ihren nächsten ausgeführten Prozess benötigen.
-
Im Beispiel übermittelt Simulationsobjekt SO1 sein Berechnungsergebnis vor dem Beginn von Simulationsschritt Step2 an das Simulationsobjekt SO2 über ein Bussystem. Das Berechnungsergebnis von Simulationsobjekt SO2 wird für den nächsten Simulationsschritt von Simulationsobjekt SO3 benötigt und an dieses übermittelt. Für die Übermittlung des Berechnungsergebnisses kann beispielsweise ein Netzwerktunnel genutzt werden (angedeutet durch den gestrichelten Pfeil), der die Kommunikation zwischen den Simulationsobjekten auf verschiedenen Recheneinheiten ermöglicht.
-
Mit dem nächsten Startsignal S1 startet der nächste Simulationsschritt Step 2, und auf Recheneinheit RE1 führt Simulationsobjekt SO1 den Prozess PRZ3 aus, Simulationsobjekt SO2 führt den Prozess PRZ4 unter Verwendung des Berechnungsergebnisses aus Step 1 von Simulationsobjekt SO1 aus. Der bereits abgeschlossene Prozess PRZ2 hat einen Folgeprozess PRZ5 ausgelöst, der auf Recheneinheit 2 durch das Simulationsobjekt SO3 ausgeführt werden soll. Nach Abschluss von Simulationsschritt Step 1 sendet Simulationsobjekt SO2 sein Berechnungsergebnis an das Simulationsobjekt SO3. Mit dem Startsignal S1 erhält die Recheneinheit RE2 implizit die Information über die Simulationszeit und kann ihre Systemzeit entsprechend inkrementieren. Das Simulationsobjekt SO3 kann dann zum richtigen, in der Ereigniswarteschlange hinterlegten, Simulationszeitpunkt mit der Berechnung des Prozesses PRZ5 beginnen.
-
Sobald die Simulationsobjekte SO1 und SO2 ihre Prozesse - PRZ3 und PRZ4 - fertig berechnet haben, melden sie wieder ein Abschlusssignal S2 an die Simulator-Applikation SAP1. Während die Simulationsobjekte SO1 und SO2 ihre Berechnungen beendet haben, läuft die Berechnung des Prozesses PRZ5 auf der Recheneinheit RE2 weiter. Der Simulationsschritt ist im Unterschied zum Beispiel, welches zu 2 beschrieben wird, dann noch nicht beendet. Das liegt daran, dass die Simulationszeit, die für die Berechnung aller Prozesse zugrunde liegt, beiden Recheneinheiten RE1 und RE2 während aller Simulationsschritte bekannt und identisch ist.
-
Nachdem Beenden der Berechnung des Prozesses PRZ5 auf Recheneinheit RE1 wird das Berechnungsergebnis an Simulationsobjekt SO2 auf Recheneinheit RE1 gesendet.
-
Da die Simulation unter einer Nullzeitannahme durchgeführt wird, vergeht während der Berechnung der Prozesse keine Simulationszeit. Der Simulationsschritt STEP 2 ist daher erst beendet, wenn die Berechnung des Prozesses PRZ5 durch Simulationsobjekt SO3 auf Recheneinheit RE2 abgeschlossen ist. Währenddessen vergeht aus Sicht der Simulation keine Zeit.
