-
Die Erfindung betrifft ein Verfahren zum Durchführen einer Simulation eines virtuellen Steuergerätes und wenigstens eines weiteren Simulationsteilnehmers auf einem vorbestimmten Zielprozessor mittels eines einen Emulator umfassenden Simulators, wobei wenigstens ein Simulationsteilnehmer für das Ausführen der Simulation auf einem zu dem Zielprozessor verschiedenen Prozessor ausgestaltet ist, mit folgenden Verfahrensschritten:
- Emulieren des Zielprozessors derart, dass der emulierte Zielprozessor den zum Zielprozessor verschiedenen Prozessor nachbildet, und
- Simulieren des virtuellen Steuergerätes und des weiteren Simulationsteilnehmers, wobei die Simulation des virtuellen Steuergerätes und des weiteren Simulationsteilnehmers jeweils eine diskrete Abfolge von mehreren Simulationsschritten umfasst und die Emulation des Zielprozessors eine diskrete Abfolge von mehreren Emulationsschritten umfasst.
-
Es sind PC-basierte Simulationsplattformen für die Absicherung von Software elektronischer Steuergeräte (ECU) in verschiedenen Entwicklungsphasen bekannt. Solche Simulationsplattformen ermöglichen die Simulation einer Vielzahl unterschiedlicher Modelle - von Funktionsmodellen über Netzwerke virtueller Steuergeräte bis hin zu Bussystemen und Fahrzeugmodellen - und zwar auch bereits in frühen Entwicklungsphasen. So bietet die dSPACE GmbH z.B. ein entsprechendes System unter der Bezeichnung VEOS® an. VEOS® ist eine PC-basierte Simulationsplattform, die SIL-Tests (SIL = Software in the Loop) bei der Entwicklung elektronischer Steuergeräte (ECUs) unterstützt. VEOS® ermöglicht das Simulieren einer Vielzahl unterschiedlicher Modelle, darunter Funktionsmodelle, Functional Mock-up Units (FMUs), virtuelle Steuergeräte (V-ECUs) und Fahrzeugmodelle, unabhängig von jeglicher Simulationshardware in frühen Phasen der Entwicklung. In Szenarien mit mehreren Modellen unterstützt VEOS® Import, Anschluss und Ausführung beliebig vieler Funktions- und Streckenmodelle basierend auf Simulink® oder Functional Mock-up Interface (FMI) und erweitert so den Funktionsumfang der Anwendungen.
-
Diese PC-basierten Simulationen werden offline durchgeführt. Das bedeutet, dass keine Verbindung zur tatsächlichen Zielhardware erforderlich ist, sondern die Simulation auf einer Recheneinheit bzw. Computer ausgeführt wird. Abhängig von dem Prozessor des Computers, der die Simulation berechnet, und den Daten, die von den Simulationsteilnehmers zur Verfügung stehen, ergeben sich unterschiedliche Herausforderungen und Vorgehensweisen.
-
Im Idealfall ist für jeden Simulationsteilnehmer der Quellcode bekannt, sodass dieser für einen beliebigen Zielprozessor kompiliert werden kann und die Simulation schnell und effizient auf dem Zielprozessor ausgeführt werden kann.
-
In bestimmten Fällen ist es jedoch nicht möglich den Quellcode zu erhalten. Dies ist insbesondere bei Restbusmodellen der Fall. Dies kann unter Anderem aus technischen Gründen der Fall sein, beispielsweise weil es schwierig ist, einen funktionsfähigen Quellcode zu erhalten, der ursprünglich für einen anderen Prozessor inklusive eines anderen Integrationsprozesses und anderer Bibliotheken konzipiert wurde. Ferner können rechtliche Gründe vorliegen, sodass die Codeweitergabe für einen bestimmten Simulationsteilnehmer nicht gestattet ist. Oft besteht auch der Wunsch, dass der Code nicht in Klartext, sondem nur fertigkompiliert IP-geschützt weitergegeben werden darf. Auch ist es unter Umständen aus testtheoretischen Erwägungen nicht sinnvoll, den Quellcode für einen anderen Prozessor zu kompilieren und dann zu testen, weil sich dadurch der Testgegenstand ändert.
-
In solchen Fällen sind im Stand der Technik unterschiedliche Lösungen bekannt. Zum einen kann der Binärcode des Simulationsteilnehmers, für den der Quellcode nicht bekannt ist, auf einer Instructionset-Simulation ausgeführt werden. In der Realität ist diese Ausführung jedoch derart langsam, dass sie wenig Praxisrelevanz aufweist. Zum anderen kann für die Simulation des Simulationsteilnehmers mit unbekanntem Quellcode, die eigentlich für einen anderen Prozessor ausgestaltet ist, der Zielprozessor auf einer virtuellen Maschine (VM) gekapselt und ausgeführt werden. Dies ist jedoch mit hohen Ansprüchen an die Hardware des Anwenders verbunden. Die entsprechende Hardware, die für eine derartige VM geeignet ist, ist mit hohen Kosten verbunden.
-
Davon ausgehend ist es die Aufgabe der Erfindung, eine schnelle, effiziente, präzise und kostengünstige Möglichkeit bereitzustellen, eine Simulation mit wenigstens einem Simulationsteilnehmer mit unbekanntem Quellcode für einen bestimmten Zielprozessor durchzuführen.
-
Diese Aufgabe wird durch den Gegenstand des Patentanspruchs 1 gelöst. Bevorzugte Weiterbildungen finden sich in den Unteransprüchen.
-
Erfindungsgemäß ist somit ein Verfahren zum Durchführen einer Simulation eines virtuellen Steuergerätes und wenigstens eines weiteren Simulationsteilnehmers auf einem vorbestimmten Zielprozessor mittels eines einen Emulator umfassenden Simulators vorgesehen, wobei wenigstens ein Simulationsteilnehmer für das Ausführen der Simulation auf einem zu dem Zielprozessor verschiedenen Prozessor ausgestaltet ist, mit folgenden Verfahrensschritten:
- Emulieren des Zielprozessors derart, dass der emulierte Zielprozessor den zum Zielprozessor verschiedenen Prozessor nachbildet, und
- Simulieren des virtuellen Steuergerätes und des weiteren Simulationsteilnehmers, wobei
- die Simulation des virtuellen Steuergerätes und des weiteren Simulationsteilnehmers jeweils eine diskrete Abfolge von mehreren Simulationsschritten umfasst und die Emulation des Zielprozessors eine diskrete Abfolge von mehreren Emulationsschritten umfasst, dadurch gekennzeichnet, dass
- die Simulationsschritte und die Emulationsschritte parallel und zeitlich synchron ablaufen.
-
Es ist somit ein maßgeblicher Punkt der Erfindung, dass der Zielprozessor für einen Simulationsteilnehmer ohne bekannten Quellcode passend emuliert werden kann und die Emulation und Simulation in einem System, also auf derselben Recheneinheit, ausgeführt werden kann. Dadurch lassen sich die Kosten für die Hardware senken sowie die Effizienz steigern. Durch die Synchronisation der Emulations- und Simulationsschritte können sehr präzise und reproduzierbare Ergebnisse erhalten werden.
-
Als Simulator kann insbesondere die PC-basierte Simulationsplattform (VEOS®) verwendet werden, die SII,-Tests (SIL = Software in the Loop) bei der Entwicklung elektronischer Steuergeräte (ECUs) unterstützt. Der Emulator, wie beispielsweise QEMU, wird in Co-Simulation mit den Simulationsteilnehmern verwendet. Dabei ist für das virtuelle Steuergerät der Quellcode bekannt, sodass dieser für einen beliebigen Zielprozessor bzw. für den emulierten Zielprozessor kompiliert werden kann.
-
Gemäß einer bevorzugten Weiterbildung der Erfindung wird die zeitliche Dauer eines Simulationsschrittes und eines Emulationsschrittes durch eine Schrittweite bestimmt wird. Die Schrittweite ergibt sich aus der Zeitdauer zwischen Start- und dem Endzeitpunkt des jeweiligen Simulations- bzw. Emulationsschritte. Vorliegend handelt es sich um eine Event-basierte Simulation, sodass die einzelnen Schritte bzw. Events nicht zu einem fixen Zeitpunkt stattfinden, sondern über ihre Schrittweiten beliebig angepasst werden können. Die Simulation bzw. Emulation umfasst dann eine diskrete Abfolge der einzelnen Schritte bzw. Events.
-
Gemäß einer bevorzugten Weiterbildung der Erfindung ist die Schrittweite eines Emulationsschrittes durch die Anzahl von CPU-Instruktionen pro Emulationsschritt bestimmt. „CPU“ steht dabei für die englische central processing unit und meint den Prozessor. Für jede CPU-Instruktion wird eine vorbestimmte Zeitdauer angenommen. Diese Zeitdauer ist prozessorabhängig. Für I/O-Operationen wird vorzugsweise eine Dauer von null Sekunden angenommen. Zusammen mit einer festgelegten Schrittweite ergibt sich daraus, wie viele CPU-Instruktionen pro Schritt emuliert werden dürfen, nämlich nach folgender Formel:
-
Der Emulator wird dazu in einen Modus versetzt, bei dem seine reale Zeit für einen Emulationsschritt (Wall Clock) durch eine virtuelle Zeit abhängig von der Anzahl der CPU-Instruktionen, also durch die Schrittweite, ersetzt wird (näheres dazu in der Figurenbeschreibung).
-
Gemäß einer bevorzugten Weiterbildung der Erfindung ist die Schrittweite der Simulationsschritte kleiner oder gleich der Schrittweite des Emulationsschrittes. Weiterhin wird ein neuer Simulationsschritt erst dann ausgeführt, wenn der parallele Emulationsschritt beendet ist. Dadurch kann die Simulation der Simulationsteilnehmer mit der Emulationsschrittweite synchronisiert werden. Die Schrittweite der Simulationsschritte ist üblicherweise frei wählbar. Ein neuer Simulationsschritt wird erst dann ausgeführt, wenn der Emulationsschritt beendet ist. Nach jedem Emulationsschritt wird somit eine Synchronisation mit den Simulationsschritten erreicht. Die Synchronisation der Schritte ist für korrekte und reproduzierbare Ergebnisse ausschlaggebend. Vorzugsweise können die Schrittweiten auch dahingehend angepasst werden, dass auch eine beschleunigte oder verlangsamte Ausführung je nach Wunsch bzw. Simulationshardware realisierbar ist.
-
Gemäß einer bevorzugten Weiterbildung der Erfindung umfasst das Verfahren folgenden weiteren Verfahrensschritt:
- Wiederholen der Simulationsschritte und/oder Emulationsschritte in deterministischer Weise.
-
Dabei ist mit „deterministischer Weise“ eine Wiederholung der Simulations- und/oder Emulationsschritten mit exakt den gleichen Ergebnissen gemeint. Um reproduzierbare Ergebnisse nach einem Neustart der Simulation zu erhalten, ist es wichtig, dass Simulations- bzw. Emulationsschritte immer exakt dieselben Operationen ausführen wie im vorangegangenen Simulationslauf. Dazu wird der Emulator in einen Modus versetzt, bei dem seine virtuelle Zeit anhand der CPU-Instruktionen anstatt der Realzeit (Wall clock) bestimmt wird. Bei herkömmlichen Instructionset-Emulatoren ist dies in der Regel nicht der Fall. So können I/O-Operationen vorzugsweise je nach Auslastung des Systems auch langsamer oder schneller abgearbeitet werden.
-
Grundsätzlich können Umgebungsmodelle, klassische V-ECUs und Restbusmodelle Simulationsteilnehmer sein. Gemäß einer bevorzugten Weiterbildung der Erfindung ist der Simulationsteilnehmer ein Restbusmodell. Restbusmodelle werden simuliert, wenn nur Teile eines Systems tatsächlich real vorliegen. Die fehlenden Funktionalitäten oder Netzwerkteilnehmer des Steuergerätes werden durch die Restbussimulation simuliert. Für den Restbus ist es regelmäßig nicht möglich den Quellcode zu erhalten, sodass ein oder mehrere Ersatzmodelle verwendet werden, die gleichwertige Ergebnisse über die gleichen Schnittstellen wie die virtuellen Steuergeräte liefern.
-
Gemäß einer bevorzugten Weiterbildung der Erfindung umfasst das Emulieren des Zielprozessors das Anpassen von Betriebssystemschnittstellen eines den Zielprozessor aufweisenden Zielsystems umfasst. Um den Binärcode erfolgreich ausführen zu können, kann es regelmäßig nicht ausreichen, den Prozessor allein zu emulieren. Vielmehr ist es dann auch notwendig, die I/O-Hardware ebenfalls zu emulieren. Die Modelle dafür herzustellen ist sehr aufwendig, während die Prozessormodelle jedoch oft verfügbar sind. Zu diesem Zweck wird vorzugsweise der Emulator angepasst, um Betriebssystemschnittstellen des Zielsystems zu nutzen, sodass die typische, aber spezifische I/O-Hardware nicht emuliert werden muss und auf höherer Ebene abgefangen wird.
-
Erfindungsgemäß ist weiterhin eine Recheneinheit zum Durchführen eines oben beschriebenen Verfahrens vorgesehen, aufweisend eine Simulationsplattform mit einem Simulator zum Simulieren der Simulationsteilnehmer und einen Emulator zum Emulieren des Zielprozessors, wobei die Recheneinheit ein Level-1-Rechner ist. Der Simulator und der Emulator sind in die Simulationsumgebung integriert, sodass sowohl die Simulation als auch die Emulation auf derselben Recheneinheit bzw. Rechner ablaufen. Der Emulator wird in Co-Simulation mit den Simulationsteilnehmern der Simulationsplattform angewendet. „Level 1-Rechner“ meint einen Rechner ohne die Fähigkeit eine gekapselte Virtuelle Maschine (VM) auszuführen.
-
Nachfolgend wird die Erfindung anhand eines bevorzugten Ausführungsbeispiels unter Bezugnahme auf die Zeichnungen weiter im Detail erläutert.
-
In den Zeichnungen zeigen
- 1a, 1b schematisch jeweils ein Simulationsmodell nach dem Stand der Technik,
- 2 schematisch ein Simulationsmodell gemäß einem bevorzugten Ausführungsbeispiel der Erfindung,
- 3 schematisch die Synchronisation der Schritte gemäß einem bevorzugten Ausführungsbeispiel der Erfindung.
-
Die 1a und 1b zeigen jeweils ein Simulationsmodell, wie es aus dem Stand der Technik bekannt ist. Beide Figuren zeigen eine Recheneinheit 9, auf der eine Simulationsplattform 10 ausgeführt wird. In 1a wird das virtuelle Steuergerät 1 mittels eines separierten Instructionset-Simulators 11 simuliert bzw. der Binärcode des virtuellen Steuergerätes 1 auf einer Instructionset-Simulation 11 ausgeführt. Dazu muss im Instructionset-Simulator 11 nicht nur der unterschiedliche Zielprozessor, sondern die vollständige Hardware modelliert werden. Dieser Ansatz ist sehr aufwendig und nur langsam in der Ausführung. In 1b wird das angepasste virtuelle Steuergerät 1' mittels einer virtuellen Maschine 12 simuliert. Der Zielprozessor wird auf der virtuellen Maschine 12 verkapselt und angepasst, sodass insgesamt die Binärcodes der Simulationsteilnehmer für denselben Zielprozessor ausgeführt werden können. Für diesen Ansatz bedarf es einer komplexen Recheneinheit, die in der Lage ist, eine Nested-VM laufen zu lassen. Dies ist mit hohen Kosten für den Anwender verbunden. In beiden Fällen erfolgt die Simulation des virtuellen Steuergerätes 1 und des weiteren Simulationsteilnehmers 2 mittels getrennter Systeme, nämlich Simulator 4 und Instructionset-Simulator 11 oder Simulator 4 und virtuelle Maschine 12.
-
2 zeigt einen anderen Ansatz, nämlich die Kombination eines Simulators 4 und eines Emulators 3 innerhalb derselben Simulationsplattform 10. Sowohl die Simulation der Simulationsteilnehmer als auch die Emulation des Zielprozessors werden als Co-Simulation parallel innerhalb dergleichen Umgebung ausgeführt.
-
Die Synchronisation der Simulation und der Emulation ist schematisch in 3 gezeigt. Dargestellt ist eine Zeitachse, auf der virtuelle Zeitabschnitte eingetragen sind. Die Simulationsschritte 5A bis 5D verlaufen parallel zu den Emulationsschritten 6A bis 6D. Die Schrittweite 7 der Simulationsschritte 5A bis 5D ist dabei kleiner als die Schrittweite 8 der Emulationsschritte 6A bis 6D. Die Schrittweite 8 der Emulationsschritte 6A bis 6D definiert die virtuellen Zeitabschnitte, die nicht mehr der realen Zeitabschnitte, sondern der Anzahl der CPU-Instruktionen entspricht. Die Anzahl der CPU-Instruktionen ergibt sich aus der vorgegebenen Schrittweite des Emulationsschrittes 6A bis 6D und der vorbestimmten Zeitdauer einer CPU-Instruktion. Dadurch, dass die Schrittweite 7 der Simulationsschritte 5A bis 5D kleiner gewählt ist, eilen diese nicht mehr voraus. Nach jedem Emulationsschritt 6A bis 6D synchronisiert sich der Emulator mit dem Simulator, sodass die virtuellen Startzeiten der parallelen Schritte, beispielsweise 5A und 6A bzw. 5B und 6B, gleich sind. Ein neuer Simulationsschritt, beispielsweise 5C, startet erst, wenn der vorherige Emulationsschritt, also 6B, beendet ist.
-
Bezugszeichenliste
-
- 1
- virtuelles Steuergerät
- 1'
- angepasstes virtuelles Steuergerät
- 2
- weiterer Simulationsteilnehmer
- 3
- Emulator
- 4
- Simulator
- 5A-5D
- Simulationsschritte
- 6A-6D
- Emulationsschritte
- 7
- Schrittweite des Simulationsschrittes
- 8
- Schrittweite des Emulationsschrittes
- 9
- Recheneinheit
- 10
- Simulationsplattform
- 11
- Instructionset-Simulator
- 12
- virtuelle Maschine
