DE102022127638A1

DE102022127638A1 - Simulationssystem und -verfahren

Info

Publication number: DE102022127638A1
Application number: DE102022127638.4A
Authority: DE
Inventors: Hector Sanchez; Ningsheng Qiao; Sudhakaran Maydiga; Steve DiBella
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2022-05-25
Filing date: 2022-10-20
Publication date: 2023-11-30
Also published as: CN117130741A; US20230409383A1

Abstract

Ein Verfahren in einem Simulationssystem umfasst: Implementieren einer Vielzahl von Threads unter Verwendung eines Betriebssystems, das jedem Thread ein Zeitquantum einer vorbestimmten Ausführungszeit zuteilt, während der der Thread während der Ausführung nicht vorgezogen wird; Überwachen von Timing-Anforderungen jeder einer Vielzahl von Aufgaben für eine Vielzahl von verschiedenen virtuellen Plattformen; Segmentieren jeder der Vielzahl von Aufgaben in eine oder mehrere Sequenzen von programmierten Anweisungen, die in einem Thread innerhalb eines Zeitquantums ausgeführt werden können; Bereitstellen der einen oder mehreren Sequenzen von programmierten Anweisungen für jede der Vielzahl von Aufgaben als eine Vielzahl von programmierten Anweisungssequenzen mit spezifischen Timing-Anforderungen; Planen von jeder der Vielzahl von programmierten Anweisungssequenzen basierend auf den spezifischen Timing-Anforderungen, um in einem der Vielzahl von Threads zu einem geeigneten Zeitpunkt ausgeführt zu werden; und Durchführen einer Echtzeitsimulation des Anwendungscodes unter Nutzung von verfügbarer Rechenleistung bei voller Kapazität.

Description

EINLEITUNG
Das technische Gebiet betrifft im Allgemeinen Systeme, Verfahren und Vorrichtungen zum Simulieren elektronischer Systeme und betrifft insbesondere Systeme, Verfahren und Vorrichtungen zum Simulieren mehrerer gleichzeitig arbeitender elektronischer Systeme.
In den letzten Jahrzehnten haben Fahrzeuge einen enormen Wandel von hauptsächlich mechanischen Maschinen hin zu digitalen Hardware (HW)/Software (SW)-zentrierten Fahrzeugsystemen vollzogen. In dieser Zeit ist die Fahrzeug-SW sehr vielfältig geworden und reicht von Infotainment bis hin zu sicherheitskritischen Echtzeit-Steuerungsanwendungen. Bei modernen Fahrerassistenzsystemen (ADAS, Advanced Driver Assistance Systems), die auf autonome Fahrszenarien abzielen, kann ein High-End-Auto rund 100 Millionen Zeilen Quellcode enthalten. Was die Kfz-HW betrifft, so kann ein High-End-Fahrzeug etwa 100 vernetzte elektronische Steuergeräte (ECUs, electronic control units) mit etwa 250 eingebetteten und grafischen Prozessoren aufweisen.
Die funktionale Sicherheit von HW/SW hat bei Kfz-Systemen hohe Priorität erlangt. Angesichts exponentiell steigender SW-Mengen, neuer komplexer Multi-Core- und Many-Core-Technologien und anspruchsvoller Anforderungen durch funktionale Sicherheitsstandards sind die Entwicklung und Validierung von HW/SW-Systemen im Automobilbereich äußerst schwierig geworden. Zum Simulieren einzelner HW/SW-Einheiten wurde die Technologie der virtuellen Plattform (VP, Virtual Platform) vorgeschlagen.
Da Fahrzeuge jedoch sehr heterogen sind, ist eine Gesamtfahrzeugsimulation erforderlich, um die Interaktionen der einzelnen Teilsysteme (Domänen) zu erfassen, da zwischen ihnen starke Abhängigkeiten bestehen.
Es ist daher wünschenswert, dass verbesserte Verfahren, Systeme und Vorrichtungen zum Simulieren mehrerer gleichzeitig arbeitender elektronischer Systeme entwickelt werden. Weitere wünschenswerte Merkmale und Eigenschaften der vorliegenden Offenbarung ergeben sich aus der nachfolgenden detaillierten Beschreibung und den beigefügten Ansprüchen, die in Verbindung mit den beigefügten Zeichnungen und dem vorstehenden technischen Gebiet und Hintergrund betrachtet werden.
Die in dieser Einleitung offenbarten Informationen dienen lediglich dem besseren Verständnis des Hintergrunds der vorliegenden Offenbarung und können daher Informationen enthalten, die nicht zum Stand der Technik gehören und die einer Person mit normalem Fachwissen in diesem Land bereits bekannt sind.
KURZDARSTELLUNG
Bei einer Ausführungsform wird ein Simulationssystem bereitgestellt. Das Simulationssystem umfasst: eine Vielzahl von Rechenressourcen, die eine Vielzahl von Prozessorkernen umfasst, und ein Betriebssystem (z. B. Windows oder Linux), das so konfiguriert ist, dass es eine Vielzahl von Ausführungs-Threads (Threads) unter Verwendung der Vielzahl von Prozessorkernen implementiert, wobei das Betriebssystem so konfiguriert ist, dass es jedem Thread ein Zeitquantum (z. B. ungefähr 10 - 15 ms) einer vorbestimmten Ausführungszeit zuteilt, während der der Thread während der Ausführung nicht vorgezogen wird. Das Simulationssystem umfasst ferner einen Multithread-Scheduler, der so konfiguriert ist, dass er die Timing-Anforderungen jeder einer Vielzahl von Aufgaben überwacht, die in einem Anwendungscode für eine Vielzahl von unterschiedlichen virtuellen Plattformen umfasst sind, jede der Vielzahl von Aufgaben in eine oder mehrere Sequenzen von programmierten Anweisungen segmentiert, die die Ausführung in einem Thread innerhalb des Zeitquantums abschließen können, und die eine oder mehreren Sequenzen von programmierten Anweisungen für jede der Vielzahl von Aufgaben als eine Vielzahl von programmierten Anweisungssequenzen mit spezifischen Timing-Anforderungen bereitstellt. Das Simulationssystem umfasst ferner einen Umgebungsmanager, der so konfiguriert ist, dass er jede der Vielzahl von programmierten Anweisungssequenzen basierend auf den spezifischen Timing-Anforderungen so plant, dass sie in einem der Vielzahl von Threads zu einem geeigneten Zeitpunkt ausgeführt wird; wobei das Simulationssystem eine Echtzeitsimulation des Anwendungscodes unter Nutzung von verfügbarer Rechenleistung bei voller Kapazität ermöglicht.
Bei einer Ausführungsform ist der Umgebungsmanager ferner so konfiguriert, dass er eine Vielzahl von Simulationsfenstern erzeugt, wobei jedes Simulationsfenster so konfiguriert ist, dass es eine Vielzahl von programmierten Anweisungssequenzen mit spezifischen Timing-Anforderungen für eine spezifische virtuelle Plattform ausführt, wobei die Vielzahl von Simulationsfenstern die Multi-Domain-Simulation der Vielzahl von virtuellen Plattformen erleichtert.
Bei einer Ausführungsform umfasst der Umgebungsmanager ferner eine Interprozessorkommunikations (IPC, inter-processor communication)-Anwendungsprogrammierschnittstelle (API, application programming interface), um die Kommunikation zwischen programmierten Anweisungssequenzen zu erleichtern, die in unterschiedlichen Simulationsfenstern für unterschiedliche virtuelle Plattformen ausgeführt werden.
Bei einer Ausführungsform erleichtert die IPC-API die Kommunikation zwischen virtuellen Plattformen, die in verschiedenen Simulationsfenstern ausgeführt werden, basierend auf: Empfangen von Mitteilungen von einer virtuellen Plattform, die an eine andere virtuelle Plattform gerichtet sind; Aufbauen einer kreisförmigen Sendernachrichten-Signalwarteschlange zum Empfangen der Mitteilungen; Bereitstellen eines ausgewogenen IPC-Handlers zum Handhaben von IPC in der kreisförmigen Sendernachrichten-Signalwarteschlange; Aufbauen einer kreisförmigen semaphorgeschützten Multithread-Warteschlange für die vom IPC-Handler gehandhabte IPC; und Bereitstellen eines gemeinsamen IPC-Pools von Kernel-Objekt-Handlern für das Planen von Aktivierungen virtueller Plattformen zum Empfangen von Mitteilungen.
Bei einer Ausführungsform erleichtert die IPC-API die gleichzeitige Multi-Domain-Simulation mehrerer virtueller Plattformen über ein Netzwerk-Kommunikationsprotokoll wie CAN (Controller Area Network) oder Ethernet.
Bei einer Ausführungsform erleichtert die IPC-API die gleichzeitige Multi-Domain-Simulation mehrerer virtueller Plattformen durch Kommunikation mit einem Simulator.
Bei einer Ausführungsform erleichtert die IPC-API die gleichzeitige Multi-Domain-Simulation mehrerer virtueller Plattformen durch Kommunikation mit einem Controller der realen Welt.
Bei einer Ausführungsform erleichtert die IPC-API die gleichzeitige Multi-Domain-Simulation mehrerer virtueller Plattformen durch Bereitstellen einer grafischen Benutzeroberfläche für Speichersonden.
Bei einer Ausführungsform erleichtert die IPC-API die gleichzeitige Multi-Domain-Simulation mehrerer virtueller Plattformen durch Bereitstellen einer Bedingungssonde.
Bei einer Ausführungsform umfasst der Umgebungsmanager ferner einen Zeitsynchronisationsmanager, der so konfiguriert ist, dass er jede der Vielzahl von programmierten Anweisungssequenzen für eine virtuelle Plattform abruft und die planungszeitsynchrone Ausführung jeder der Vielzahl von programmierten Anweisungssequenzen in einem der Simulationsfenster plant.
Bei einer Ausführungsform stellt jedes Simulationsfenster eine Functional Mock-up Unit (FMU) dar und eine erste ausführende FMU wird als primärer FMU-Prozess bezeichnet, und nachfolgende ausführende FMUs werden als sekundäre FMU-Prozesse bezeichnet, wobei der primäre FMU-Prozess ein Taktsignal erzeugt, das zum Synchronisieren des Betriebs von Quantumsaufgaben im primären FMU-Prozess und Quantumsaufgaben in den sekundären FMU-Prozessen verwendet wird.
Bei einer anderen Ausführungsform wird ein Verfahren in einem Simulationssystem offenbart. Das Verfahren umfasst: Implementieren einer Vielzahl von Ausführungs-Threads (Threads) unter Verwendung einer Vielzahl von Prozessorkernen und eines Betriebssystems, das jedem Thread ein Zeitquantum (z. B. ungefähr 10 - 15 ms) einer vorbestimmten Ausführungszeit zuteilt, während der der Thread während der Ausführung nicht vorgezogen wird; Überwachen von Timing-Anforderungen jeder einer Vielzahl von Aufgaben, die im Anwendungscode für eine Vielzahl von verschiedenen virtuellen Plattformen umfasst sind; Segmentieren jeder der Vielzahl von Aufgaben in eine oder mehrere Sequenzen von programmierten Anweisungen, die die Ausführung in einem Thread innerhalb eines Zeitquantums abschließen können; Bereitstellen der einen oder mehreren Sequenzen von programmierten Anweisungen für jede der Vielzahl von Aufgaben als eine Vielzahl von programmierten Anweisungssequenzen mit spezifischen Timing-Anforderungen; Planen von jeder der Vielzahl von programmierten Anweisungssequenzen basierend auf den spezifischen Timing-Anforderungen, um in einem der Vielzahl von Threads zu einem geeigneten Zeitpunkt ausgeführt zu werden; und Durchführen einer Echtzeitsimulation des Anwendungscodes unter Nutzung von verfügbarer Rechenleistung bei voller Kapazität.
Bei einer Ausführungsform umfasst das Verfahren ferner das Erzeugen einer Vielzahl von Simulationsfenstern, wobei jedes Simulationsfenster so konfiguriert ist, dass es eine Vielzahl von programmierten Anweisungssequenzen mit spezifischen Timing-Anforderungen für eine spezifische virtuelle Plattform ausführt, wobei die Vielzahl von Simulationsfenstern die Multi-Domain-Simulation der Vielzahl von virtuellen Plattformen erleichtert.
Bei einer Ausführungsform umfasst das Verfahren ferner eine Interprozessorkommunikations (IPC)-Anwendungsprogrammierschnittstelle (API), um die Kommunikation zwischen programmierten Anweisungssequenzen zu erleichtern, die in unterschiedlichen Simulationsfenstern für unterschiedliche virtuelle Plattformen ausgeführt werden.
Bei einer Ausführungsform umfasst das Verfahren ferner das Erleichtern von Kommunikation zwischen virtuellen Plattformen, die in verschiedenen Simulationsfenstern ausgeführt werden, basierend auf: Empfangen von Mitteilungen von einer virtuellen Plattform, die an eine andere virtuelle Plattform gerichtet sind; Aufbauen einer kreisförmigen Sendernachrichten-Signalwarteschlange zum Empfangen der Mitteilungen; Bereitstellen eines ausgewogenen IPC-Handlers zum Handhaben von IPC in der kreisförmigen Sendernachrichten-Signalwarteschlange; Aufbauen einer kreisförmigen semaphorgeschützten Multithread-Warteschlange für die vom IPC-Handler gehandhabte IPC; und Bereitstellen eines gemeinsamen IPC-Pools von Kernel-Objekt-Handlern für das Planen von Aktivierungen virtueller Plattformen zum Empfangen von Mitteilungen.
Bei einer Ausführungsform umfasst das Verfahren ferner das Erleichtern von gleichzeitiger Multi-Domain-Simulation mehrerer virtueller Plattformen über ein Netzwerk-Kommunikationsprotokoll wie CAN (Controller Area Network) oder Ethernet zu einem Simulator oder einem realen Controller.
Bei einer Ausführungsform umfasst das Verfahren ferner das Erleichtern von gleichzeitiger Multi-Domain-Simulation mehrerer virtueller Plattformen durch Bereitstellen einer grafischen Benutzeroberfläche für Speichersonden oder einer Bedingungssonde.
Bei einer Ausführungsform umfasst das Verfahren ferner das Abrufen jeder der Vielzahl von programmierten Anweisungssequenzen für eine virtuelle Plattform und das Planen von zeitsynchronisierter Ausführung jeder der Vielzahl von programmierten Anweisungssequenzen in einem der Simulationsfenster.
Bei einer Ausführungsform stellt jedes Simulationsfenster eine Functional Mock-up Unit (FMU) dar und eine erste ausführende FMU wird als primärer FMU-Prozess bezeichnet, und nachfolgende ausführende FMUs werden als sekundäre FMU-Prozesse bezeichnet, wobei der primäre FMU-Prozess ein Taktsignal erzeugt, das zum Synchronisieren des Betriebs von Quantumsaufgaben im primären FMU-Prozess und Quantumsaufgaben in den sekundären FMU-Prozessen verwendet wird.
Bei einer anderen Ausführungsform wird ein nicht transitorisches computerlesbares Medium offenbart, das mit Programmieranweisungen codiert ist, die so konfiguriert werden können, dass sie ein Simulationssystem veranlassen, ein Verfahren durchzuführen. Das Verfahren umfasst: Implementieren einer Vielzahl von Ausführungs-Threads (Threads) unter Verwendung einer Vielzahl von Prozessorkernen und eines Betriebssystems, das jedem Thread ein Zeitquantum (z. B. ungefähr 10 - 15 ms) einer vorbestimmten Ausführungszeit zuteilt, während der der Thread während der Ausführung nicht vorgezogen wird; Überwachen von Timing-Anforderungen jeder einer Vielzahl von Aufgaben, die im Anwendungscode für eine Vielzahl von verschiedenen virtuellen Plattformen umfasst sind; Segmentieren jeder der Vielzahl von Aufgaben in eine oder mehrere Sequenzen von programmierten Anweisungen, die die Ausführung in einem Thread innerhalb eines Zeitquantums abschließen können; Bereitstellen der einen oder mehreren Sequenzen von programmierten Anweisungen für jede der Vielzahl von Aufgaben als eine Vielzahl von programmierten Anweisungssequenzen mit spezifischen Timing-Anforderungen; Planen von jeder der Vielzahl von programmierten Anweisungssequenzen basierend auf den spezifischen Timing-Anforderungen, um in einem der Vielzahl von Threads zu einem geeigneten Zeitpunkt ausgeführt zu werden; und Durchführen einer Echtzeitsimulation des Anwendungscodes unter Nutzung von verfügbarer Rechenleistung bei voller Kapazität.
Bei einer Ausführungsform des nicht transitorischen computerlesbaren Mediums umfasst das Verfahren ferner das Erzeugen einer Vielzahl von Simulationsfenstern, wobei jedes Simulationsfenster so konfiguriert ist, dass es eine Vielzahl von programmierten Anweisungssequenzen mit spezifischen Timing-Anforderungen für eine spezifische virtuelle Plattform ausführt, wobei die Vielzahl von Simulationsfenstern die Multi-Domain-Simulation der Vielzahl von virtuellen Plattformen erleichtert.
Bei einer Ausführungsform des nicht transitorischen computerlesbaren Mediums umfasst das Verfahren ferner eine Interprozessorkommunikations (IPC-Anwendungsprogrammierschnittstelle (API), um die Kommunikation zwischen programmierten Anweisungssequenzen zu erleichtern, die in unterschiedlichen Simulationsfenstern für unterschiedliche virtuelle Plattformen ausgeführt werden.
Bei einer Ausführungsform des nicht transitorischen computerlesbaren Mediums umfasst das Verfahren ferner das Erleichtern von Kommunikation zwischen virtuellen Plattformen, die in verschiedenen Simulationsfenstern ausgeführt werden, basierend auf: Empfangen von Mitteilungen von einer virtuellen Plattform, die an eine andere virtuelle Plattform gerichtet sind; Aufbauen einer kreisförmigen Sendernachrichten-Signalwarteschlange zum Empfangen der Mitteilungen; Bereitstellen eines ausgewogenen IPC-Handlers zum Handhaben von IPC in der kreisförmigen Sendernachrichten-Signalwarteschlange; Aufbauen einer kreisförmigen semaphorgeschützten Multithread-Warteschlange für die vom IPC-Handler gehandhabte IPC; und Bereitstellen eines gemeinsamen IPC-Pools von Kernel-Objekt-Handlern für das Planen von Aktivierungen virtueller Plattformen zum Empfangen von Mitteilungen.
Bei einer Ausführungsform des nicht transitorischen computerlesbaren Mediums umfasst das Verfahren ferner das Erleichtern von gleichzeitiger Multi-Domain-Simulation mehrerer virtueller Plattformen über ein Netzwerk-Kommunikationsprotokoll wie CAN (Controller Area Network) oder Ethernet zu einem Simulator oder einem realen Controller.
Bei einer Ausführungsform des nicht transitorischen computerlesbaren Mediums umfasst das Verfahren ferner das Erleichtern von gleichzeitiger Multi-Domain-Simulation mehrerer virtueller Plattformen durch Bereitstellen einer grafischen Benutzeroberfläche für Speichersonden oder einer Bedingungssonde.
Bei einer Ausführungsform des nicht transitorischen computerlesbaren Mediums umfasst das Verfahren ferner das Abrufen jeder der Vielzahl von programmierten Anweisungssequenzen für eine virtuelle Plattform und das Planen von zeitsynchronisierter Ausführung jeder der Vielzahl von programmierten Anweisungssequenzen in einem der Simulationsfenster.
Bei einer Ausführungsform des nicht transitorischen computerlesbaren Mediums stellt jedes Simulationsfenster eine Functional Mock-up Unit (FMU) dar und eine erste ausführende FMU wird als primärer FMU-Prozess bezeichnet, und nachfolgende ausführende FMUs werden als sekundäre FMU-Prozesse bezeichnet, wobei der primäre FMU-Prozess ein Taktsignal erzeugt, das zum Synchronisieren des Betriebs von Quantumsaufgaben im primären FMU-Prozess und Quantumsaufgaben in den sekundären FMU-Prozessen verwendet wird.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die beispielhaften Ausführungsformen werden im Folgenden in Verbindung mit den folgenden Figuren beschrieben, wobei gleiche Bezugszeichen gleiche Elemente bezeichnen, und wobei:

1 ist ein Blockdiagramm, das ein Beispiel für ein Simulationssystem darstellt, gemäß einer Ausführungsform;
2 ist ein Blockdiagramm, das eine beispielhafte Simulationsausführung zeigt, gemäß einer Ausführungsform;
3 ist ein Blockdiagramm, das eine beispielhafte Methodologie zeigt, die durch eine beispielhafte IPC-API für die gemeinsame Nutzung gleichzeitiger Hardware-Transaktionen für die Kommunikation zwischen FMUs implementiert wird, gemäß einer Ausführungsform;
4 ist ein Blockdiagramm, das eine beispielhafte zeitliche Synchronisation zwischen mehreren FMUs darstellt, gemäß einer Ausführungsform; und
5 ist ein Prozessablaufdiagramm, das einen beispielhaften Prozess zum gleichzeitigen Simulieren mehrerer virtueller Plattformen darstellt, gemäß einer Ausführungsform.

DETAILLIERTE BESCHREIBUNG
Die folgende detaillierte Beschreibung hat lediglich beispielhaften Charakter und ist nicht dazu bestimmt, die Anwendung und Verwendungen einzuschränken. Ferner besteht keine Absicht, sich an eine ausdrückliche oder stillschweigende Theorie zu binden, die im vorangegangenen technischen Gebiet, Hintergrund, der Kurzdarstellung oder der folgenden detaillierten Beschreibung dargelegt wird. Wie hierin verwendet, bezieht sich der Begriff „Modul“ auf jede Hardware, Software, Firmware, elektronische Steuerkomponente, Verarbeitungslogik und/oder Prozessorvorrichtung, einzeln oder in beliebiger Kombination, umfassend, aber nicht beschränkt auf: anwendungsspezifische integrierte Schaltung (ASIC), ein feldprogrammierbares Gate-Array (FPGA), eine elektronische Schaltung, einen Prozessor (gemeinsam, dediziert oder Gruppe) und einen Speicher, der ein oder mehrere Software- oder Firmwareprogramme ausführt, eine kombinatorische Logikschaltung und/oder andere geeignete Komponenten, die die beschriebene Funktionalität bereitstellen.
Ausführungsformen der vorliegenden Offenbarung können hierin in Form von funktionalen und/oder logischen Blockkomponenten und verschiedenen Verarbeitungsschritten beschrieben werden. Es sei darauf hingewiesen, dass solche Blockkomponenten durch eine beliebige Anzahl von Hardware-, Software- und/- oder Firmware-Komponenten realisiert werden können, die konfiguriert sind, um die angegebenen Funktionen auszuführen. Beispielsweise kann eine Ausführungsform der vorliegenden Offenbarung verschiedene integrierte Schaltungskomponenten verwenden, z. B. Speicherelemente, digitale Signalverarbeitungselemente, Logikelemente, Nachschlagetabellen oder ähnliches, die eine Mehrzahl von Funktionen unter der Kontrolle eines oder mehrerer Mikroprozessoren oder anderer Steuergeräte ausführen können. Darüber hinaus wird der Fachmann erkennen, dass Ausführungsformen der vorliegenden Offenbarung in Verbindung mit einer beliebigen Anzahl von Systemen verwendet werden können und dass die hierin beschriebenen Systeme lediglich beispielhafte Ausführungsformen der vorliegenden Offenbarung sind.
Der Kürze halber wird auf eine ausführliche Beschreibung konventioneller Techniken der Signalverarbeitung, Datenübertragung, Signalisierung, Steuerung und anderer funktionaler Aspekte der Systeme (und der einzelnen Betriebskomponenten der Systeme) verzichtet. Ferner sollen die in den hierin enthaltenen, verschiedenen Figuren dargestellten Verbindungslinien beispielhafte funktionale Beziehungen und/oder physikalische Verbindungen zwischen den verschiedenen Elementen darstellen. Es sollte beachtet werden, dass viele alternative oder zusätzliche funktionale Beziehungen oder physikalische Verbindungen in einer Ausführungsform der vorliegenden Offenbarung vorhanden sein können.
In den letzten Jahrzehnten haben Fahrzeuge einen enormen Wandel von hauptsächlich mechanischen Maschinen hin zu digitalen Hardware (HW)/Software (SW)-zentrierten Fahrzeugsystemen vollzogen. In dieser Zeit ist die Fahrzeug-SW sehr vielfältig geworden und reicht von Infotainment bis hin zu sicherheitskritischen Echtzeit-Steuerungsanwendungen. Bei modernen Fahrerassistenzsystemen (ADAS), die auf autonome Fahrszenarien abzielen, kann ein High-End-Auto rund 100 Millionen Zeilen Quellcode enthalten. Was die Kfz-HW betrifft, so kann ein High-End-Fahrzeug etwa 100 vernetzte elektronische Steuergeräte (ECUs) mit etwa 250 eingebetteten und grafischen Prozessoren aufweisen.
Die funktionale Sicherheit von HW/SW hat bei Kfz-Systemen hohe Priorität erlangt. Angesichts exponentiell steigender SW-Mengen, neuer komplexer Multi-Core- und Many-Core-Technologien und anspruchsvoller Anforderungen durch funktionale Sicherheitsstandards sind die Entwicklung und Validierung von HW/SW-Systemen im Automobilbereich äußerst schwierig geworden. Die Technologie der virtuellen Plattform (VP) wurde vorgeschlagen, um einzelne HW/SW-Einheiten unter verschiedenen Betriebssystemumgebungen wie Windows- und Linux-Umgebungen zu simulieren.
Da Fahrzeuge jedoch sehr heterogen sind, ist eine Gesamtfahrzeugsimulation erforderlich, um die Interaktionen der einzelnen Teilsysteme (Domänen) zu erfassen, da zwischen ihnen starke Abhängigkeiten bestehen. Dies schränkt die Nutzung virtueller Plattformen ein und erfordert Modellierungs- und Simulationstechniken über die Domänengrenzen hinaus. Es wird eine bereichsübergreifende Co-Simulation benötigt. Beispielsweise beeinflussen sich im Falle der Simulation des Stromanschlusses eines Elektrofahrzeugs die elektrischen, mechanischen und thermischen Eigenschaften der Vorrichtung gegenseitig erheblich und müssen daher gemeinsam betrachtet werden. In ähnlicher Weise wird das Verhalten von ADAS-Anwendungen nicht nur von den HW/SW-Systemen beeinflusst, in die sie eingebettet sind, sondern auch von physikalischen Eingaben aus der Umgebung (z. B. Temperatur, Straßeneigenschaften, atmosphärische Bedingungen), die von peripheren Vorrichtungen (z. B. Sensoren) erfasst werden.
Die hierin offenbarten Geräte, Systeme, Techniken und Artikel ermöglichen eine Multi-Domain-Simulation. Die hierin offenbarten Geräte, Systeme, Techniken und Artikel wandeln VPs in Functional Mock-Up Units (FMUs) für die Multi-Domain-Simulation um.
Die hierin offenbarten Geräte, Systeme, Techniken und Artikel stellen eine Verbesserung der Computertechnologie dar. Die offenbarten Geräte, Systeme, Techniken und Artikel stellen eine Simulationsumgebung für die Multi-Domain-Simulation verschiedener HW/SW-Systeme bereit. Die offenbarten Geräte, Systeme, Techniken und Artikel stellen eine spezielle Simulationsmaschine bereit, die eine Multi-Domain-Simulation durchführen kann.
1 ist ein Blockdiagramm, das ein beispielhaftes Simulationssystem 100 zeigt. Das beispielhafte Simulationssystem 100 umfasst Rechenressourcen 102, ein Betriebssystem 104 und einen Multithread-Scheduler 106, die mit einem Umgebungsmanager (nicht dargestellt) zusammenarbeiten, um die Simulationsausführung 108 zu erreichen. Der Umgebungsmanager führt den Anwendungscode 110 aus und wendet Eingaben aus einem Simulationsmodell 112 an. Bei dem Simulationsmodell 112 kann es sich um Anlagenmodelle, Sensormodelle, intelligente Aktuatormodelle handeln, die von CAE-Modellierungswerkzeugen oder Simulationsmodellierungswerkzeugen (wie von MATLAB und/oder SIMULINK, die Beispiele der realen Welt simulieren) erstellt wurden, und/oder um Eingaben von einem oder mehreren virtuellen Controllern 114, die als elektronisches Steuergerät (ECU) in einem Kraftfahrzeug dargestellt werden, um eine Multi-Domain-Simulation durchzuführen.
Die Rechenressourcen 102 können aus Server- und/oder Laptop-Ressourcen bestehen, die für die Datenverarbeitung verwendet werden können. Die Rechenressourcen 102 können eine Vielzahl von Rechenkernen, Taktfrequenz, Speicher usw. umfassen.
Das Betriebssystem 104 umfasst Standard-Betriebssystemprimitive (z. B. Windows, Linux) sowie spezielle Simulationsmesswerkzeuge (z. B. INCA, XCP). Das Betriebssystem 104 implementiert eine Vielzahl von Ausführungs-Threads (Threads) unter Verwendung der Rechenressourcen 102, die die Vielzahl von Prozessorkernen umfassen. Das Betriebssystem 104 ermöglicht es dem Simulationssystem 100, die Ausführung von Anwendungscode 110 so zu simulieren, wie er in Systemen der realen Welt, wie ECUs in einem Kraftfahrzeug, ausgeführt werden würde. Das Betriebssystem 104 führt Aufgaben aus, die auf einem System der realen Welt unter Verwendung von Threads ausgeführt werden würden. Das Betriebssystem 104 ist so konfiguriert, dass es jedem Thread ein Zeitquantum einer vorbestimmten Ausführungszeit (ungefähr 10 - 15 ms) zuteilt, während der der Thread während der Ausführung nicht vorgezogen wird.
Der Multithread-Scheduler 106 ist ein ausgewogener dynamischer Multithread-Scheduler, der so konfiguriert ist, dass er Thread-Prioritäten, Scheduling, Affinitäten und Quantum definiert. Der Multithread-Scheduler 106 ist so konfiguriert, dass er die Timing-Anforderungen jeder der Vielzahl von Aufgaben überwacht, die im Anwendungscode 110 umfasst sind, jede der Vielzahl von Aufgaben in eine oder mehrere Sequenzen von programmierten Anweisungen segmentiert, die die Ausführung in einem Thread innerhalb des Zeitquantums abschließen können, und die eine oder mehreren Sequenzen von programmierten Anweisungen für jede der Vielzahl von Aufgaben als eine Vielzahl von programmierten Anweisungssequenzen mit spezifischen Timing-Anforderungen bereitstellt.
Der Anwendungscode 110 ist die Software (SW) für die zu prüfenden Systeme wie virtuelle ECUs (vECUs). Der beispielhafte Anwendungscode 110 umfasst den Anwendungscode für eine Vielzahl von ECUs in einem Kraftfahrzeug. Das Simulationsmodell 112 simuliert Eingaben für den Anwendungscode 110, wie Bremsen, Beschleunigen usw. Der eine oder die mehreren virtuellen Controller 114 stellen Hardware-Einheiten (z. B. reale ECUs) dar, die sich in einem realen Fahrzeug befinden würden.
Der Umgebungsmanager simuliert basierend auf den verschiedenen Eingaben Aufgaben des Anwendungscodes. Der Umgebungsmanager ist so konfiguriert, dass er jede der Vielzahl von programmierten Anweisungssequenzen basierend auf den spezifischen Timing-Anforderungen so plant, dass sie in einem der Vielzahl von Threads zu einem geeigneten Zeitpunkt ausgeführt werden. Der Umgebungsmanager ermöglicht dem Simulationssystem 100 eine Echtzeitsimulation des Anwendungscodes 110 unter Nutzung von verfügbarer Rechenleistung bei voller Kapazität. Der Umgebungsmanager ist so konfiguriert, dass er jeden verfügbaren Thread, der über die Rechenressourcen 102 und das Betriebssystem 104 bereitgestellt wird, nutzt, um die Vielzahl von programmierten Anweisungssequenzen gemäß ihren spezifischen Timing-Anforderungen auszuführen.
2 ist ein Blockdiagramm, das eine beispielhafte Simulationsausführung 108 zeigt. Die beispielhafte Simulationsausführung 108 erfolgt unter Verwendung eines Betriebssystems 201 (z. B. Windows, Linux) und seiner APIs (Anwendungsprogrammierschnittstellen), Simulationsmesswerkzeugen 203 wie INCA (Integrated Calibration and Application Tool/Integriertes Kalibrierungs- und Anwendungs-Tool) und XCP (Universal Measurement and Calibration Protocol/Universelles Mess- und Kalibrierungsprotokoll) und wird von einem Umgebungsmanager 200 verwaltet. Der beispielhafte Umgebungsmanager 200 wandelt eine Vielzahl von VPs 208 (z. B. vECUs) in eine Vielzahl von FMUs um und verwaltet die Multi-Domain-Simulation der mehreren FMUs. Der beispielhafte Umgebungsmanager 200 umfasst einen Zeitsynchronisationsmanager 202, stellt eine Vielzahl von Simulationsfenstern 204 bereit und umfasst eine Interprozessorkommunikations (IPC)-API 206.
Das Simulationsmess-Tool wie INCA ist ein Software-Tool, das eine automobilspezifische Umgebung für die Messung, Kalibrierung und Diagnose elektronischer Steuerungen in einem Fahrzeug bereitstellt. Es integriert eine große Bandbreite von ECU- und Busschnittstellen sowie Messvorrichtungen.
XCP ist ein High-Level-Protokoll zum Verbinden von Kalibriersystemen mit ECUs (elektronische Steuergeräte). XCP ermöglicht Systemen das Erfassen, Stimulieren und Kalibrieren von Daten in ECUs.
Der Zeitsynchronisationsmanager 202 ist prozessorimplementiert und so konfiguriert, dass er jede der Vielzahl von programmierten Anweisungssequenzen aus dem Anwendungscode für eine VP 208 abruft und die zeitsynchronisierte Ausführung jeder der Vielzahl von programmierten Anweisungssequenzen in einem der Simulationsfenster 204 plant, wodurch die VP in eine FMU umgewandelt wird. Jede der beispielhaften VPs 208 umfasst einen Ziel-Binärcode, der vor dem Einsatz in einer realen Hardware getestet wird. Der Zeitsynchronisationsmanager 202 plant basierend auf den spezifischen zeitlichen Anforderungen jeder programmierten Anweisungssequenz, die innerhalb eines vorgegebenen Zeitquantums für die Aufgaben einer VP 208 ausgeführt werden kann, jede programmierte Anweisungssequenz zu einem geeigneten Zeitpunkt für die Ausführung in einem verfügbaren Simulationsfenster 204 ein.
Der beispielhafte Umgebungsmanager 200 nutzt alle verfügbaren Rechenressourcen und stellt so viele Simulationsfenster 204 zur Verfügung, wie die verfügbaren Rechenressourcen unterstützen können. Jedes Simulationsfenster 204 wird verwendet, um die Ausführung einer oder mehrerer programmierter Anweisungssequenzen zu simulieren, die innerhalb des vorgegebenen Zeitquantums für die Aufgaben einer VP 208 ausgeführt werden können. Jedes Simulationsfenster 204 hat Zugriff auf die IPC-API 206.
Die IPC-API 206 stellt eine Methodik für die Inter-Prozessor-Kommunikation zwischen verschiedenen FMUs in den Simulationsfenstern 204 bereit, um eine Multi-Domain-Simulation zu ermöglichen. Die IPC-API 206 stellt einen virtuellen Speicherbus und eine Methodik zum Speichern von Daten im lokalen Speicher und/- oder im Speicher eines cloud-basierten Systems bereit. Die IPC-API 206 stellt Eingabedaten für die Simulationsfenster 204 (aus dem lokalen Speicher und/oder einem Speicher in einem cloud-basierten System) bereit. Die IPC-API 206 überträgt Daten zwischen Simulationsfenstern 204. Die IPC-API 206 stellt den Zugriff auf den (lokalen oder cloud-basierten) Speicher zur Verwendung durch Simulationsfenster 204 bereit. Die IPC-API 206 stellt eine Möglichkeit bereit, die Simulationsaktivität durch Speichersonden 210 zu prüfen (einschließlich einer grafischen Benutzeroberfläche für Speichersonden zum Anzeigen der Simulationsaktivität).
Die IPC-API 206 stellt Zugang zu einer Bedingungssonde 212 bereit, die es dem Simulationssystem ermöglicht, die Reaktion der in einem Simulationsfenster 204 ausgeführten Anwendungssoftware auf verschiedene Bedingungen durch Fehlerinjektion, Plausibilitätsprüfungen usw. zu prüfen. Die IPC-API 206 stellt den Simulationsfenstern 204 durch ein Mitteilungsprotokoll eine Netzwerksonde 214 bereit, wie eine CAN-Sonde (Controller Area Network) oder eine Ethernet-Sonde, die jeweils einen CAN- oder Ethernet-Bus in einem Fahrzeug der realen Welt simuliert. Die IPC-API 206 stellt Zugang zu einer Simulatorschnittstelle 216 für den Empfang von Eingaben von einem Simulationsmodell 112 bereit. Bei dem Simulationsmodell 112 kann es sich um Anlagenmodelle, Sensormodelle, intelligente Aktuatormodelle handeln, die von CAE-Modellierungswerkzeugen oder Simulationsmodellierungswerkzeugen (wie MATLAB und/oder SIMULINK) erstellt werden, die physikalische Eingaben simulieren können, wie sie ein ECU der realen Welt von der Umgebung erhält (z. B. Temperatur, Straßeneigenschaften, atmosphärische Bedingungen) und die von peripheren Vorrichtungen (z. B. Sensoren) erfasst werden. Die IPC-API 206 stellt Zugang zu einer Controller-Schnittstelle 218 bereit, um Eingaben von einem virtuellen Controller 114 (z. B. ECU) zu empfangen.
3 ist ein Blockdiagramm, das eine beispielhafte Methodik 302 zeigt, die von einer beispielhaften IPC-API 206 für die gemeinsame Nutzung gleichzeitiger Hardware-Transaktionen für die Kommunikation zwischen FMUs (z. B. Kommunikation zwischen VPs) implementiert wird. Die beispielhafte Methodik umfasst das Empfangen von Mitteilungen 304 von einer VP 306, die an eine andere VP 306 gerichtet sind. Die beispielhaften Mitteilungen 304 sind gleichzeitige atomare Transaktionen mit dem Transaktionsspeicher.
Die beispielhafte Methodik 302 umfasst das Aufbauen einer kreisförmigen Sendernachrichten-Signalwarteschlange (Vorgang 308) zum Empfangen der beispielhaften Mitteilungen 304, wobei eine kreisförmige Warteschlange eine lineare Datenstruktur ist, in der die Vorgänge basierend auf dem FIFO-Prinzip (First In First Out) durchgeführt werden und die letzte Position mit der ersten Position zurückverbunden wird, um einen Kreis zu bilden. Die beispielhafte Methodik 302 umfasst das Bereitstellen eines ausgewogenen Interprozessorkommunikations-(IPC)-Handlers (Vorgang 310) zum Handhaben aller IPC in der kreisförmigen Sendernachrichten-Signalwarteschlange zwischen den VPs, wobei IPC durch gemeinsam genutzten Speicher ein Konzept ist, bei dem zwei oder mehr Prozesse auf den gemeinsamen Speicher zugreifen können und die Kommunikation über diesen gemeinsam genutzten Speicher erfolgt, in dem von einem Prozess vorgenommene Änderungen von einem anderen Prozess eingesehen werden können. Die beispielhafte Methodik 302 umfasst das Aufbauen einer kreisförmigen semaphorgeschützten Multithread-Warteschlange (Vorgang 312) für die vom IPC-Handler gehandhabte IPC, wobei ein Semaphor eine Variable ist, die von einem Thread verwendet wird, um einen anderen Thread zu signalisieren. Die beispielhafte Methodik 302 umfasst das Bereitstellen eines gemeinsamen IPC-Pools von Kernel-Objekt-Handlern (Vorgang 314). Die Kernel-Objekt-Handler können basierend auf der IPC Aktivierungen (Vorgang 316) der VPs 306 planen.
4 ist ein Blockdiagramm, das ein Beispiel für die zeitliche Synchronisation zwischen mehreren FMUs zeigt. Dargestellt sind ein primärer FMU-Prozess-Thread 402 und eine Vielzahl sekundärer FMU-Prozess-Threads 404 (in diesem Beispiel sind zwei dargestellt, es könnten aber auch viele weitere umfasst sein).
Jeder FMU-Prozess-Thread 402, 404 umfasst einen Thread-Timer 406-1, 406-2 zum Bereitstellen eines periodischen Taktsignals 407, 409, in diesem Beispiel von 0,5 Millisekunden, für einen Aufgaben-Timer 408, der zum Planen der Ausführung verschiedener Quantumsaufgaben 410 für den zugeordneten FMU-Prozess verwendet wird. Der Thread-Timer 406-1 im primären FMU-Prozess-Thread 402 fungiert als Master-Thread-Timer für alle FMU-Prozess-Threads 402, 404. Der Thread-Timer 406-2 in den sekundären FMU-Prozess-Threads 404 empfängt jeweils das Taktsignal 407 vom Master-Thread-Timer 406-1 und erzeugt basierend darauf das Taktsignal 409, das dem Aufgaben-Timer 408 für den zugeordneten FMU-Prozess bereitgestellt wird. Der erste zu startende FMU-Prozess wird dem primären Prozess-Thread 402 zugewiesen und jeder nachfolgende FMU-Prozess wird einem sekundären Prozess-Thread 404 zugewiesen. Diese Anordnung stellt Multiprozess-FMUs bereit, die alle mit einem gemeinsamen Takt synchronisiert sind.
5 ist ein Prozessablaufdiagramm, in dem ein beispielhafter Prozess 500 zum gleichzeitigen Simulieren mehrerer virtueller Plattformen gezeigt wird. Die Vorgangsreihenfolge innerhalb des Prozesses 500 ist nicht auf die sequenzielle Ausführung beschränkt, wie in 5 veranschaulicht, kann aber in einer oder mehreren unterschiedlichen Reihenfolgen durchgeführt werden, je nach Anwendbarkeit und in Übereinstimmung mit der vorliegenden Offenbarung.
Der beispielhafte Prozess 500 umfasst das Implementieren einer Vielzahl von Threads unter Verwendung einer Vielzahl von Prozessorkernen und eines Betriebssystems, das jedem Thread ein Zeitquantum einer vorbestimmten Ausführungszeit zuteilt, während der der Thread während der Ausführung nicht vorgezogen wird (Vorgang 502).
Der beispielhafte Prozess 500 umfasst das Überwachen von Timing-Anforderungen jeder einer Vielzahl von Aufgaben, die im Anwendungscode für eine Vielzahl von verschiedenen virtuellen Plattformen umfasst sind (Vorgang 504).
Der beispielhafte Prozess 500 umfasst das Segmentieren jeder der Vielzahl von Aufgaben in eine oder mehrere Sequenzen von programmierten Anweisungen, die die Ausführung in einem Thread innerhalb eines Zeitquantums abschließen kann (Vorgang 506).
Der beispielhafte Prozess 500 umfasst das Bereitstellen der einen oder mehreren Sequenzen von programmierten Anweisungen für jede der Vielzahl von Aufgaben als eine Vielzahl von programmierten Anweisungssequenzen mit spezifischen Timing-Anforderungen (Vorgang 508).
Der beispielhafte Prozess 500 umfasst das Planen jeder der Vielzahl von programmierten Anweisungssequenzen basierend auf den spezifischen Timing-Anforderungen so, dass sie in einem der Vielzahl von Threads zu einem geeigneten Zeitpunkt ausgeführt wird (Vorgang 510).
Der beispielhafte Prozess 500 umfasst das Durchführen einer Echtzeitsimulation des Anwendungscodes unter Nutzung von verfügbarer Rechenleistung bei voller Kapazität (Vorgang 512).
Die hierin offenbarten Geräte, Systeme, Techniken und Artikel stellen eine Methodik zum Erzeugen selbständiger lauffähiger FMUs bereit, die bei Vorhandensein anderer FMUs miteinander kommunizieren. Die hierin offenbarten Geräte, Systeme, Techniken und Artikel können den einfachen Standard des Windows/Linux-Betriebssystems Kernel verwenden. Die hierin offenbarten Geräte, Systeme, Techniken und Artikel stellen eine Methodik zum Erzeugen von Multithreading- und Multiprozess-FMUs bereit, die alle mit einem gemeinsamen Taktgeber synchronisiert sind. Die hierin offenbarten Geräte, Systeme, Techniken und Artikel stellen eine Methodik zum Durchführen von Analysen und zum Ausgleichen von Schedulern für ein Echtzeitbetriebssystem bereit. Die hierin offenbarten Geräte, Systeme, Techniken und Artikel stellen eine Methodik zum Schutz gleichzeitiger Hardware-Transaktionen für die Kommunikation zwischen FMUs bereit. Die hierin offenbarten Geräte, Systeme, Techniken und Artikel stellen die Nutzung von Rechenressourcen mit voller Kapazität bereit.
Die vorstehenden Ausführungen skizzieren die Merkmale verschiedener Ausführungsformen, sodass die Fachleute die Aspekte der vorliegenden Offenbarung besser verstehen können. Fachleute auf dem Gebiet sollten erkennen, dass sie die vorliegende Offenbarung ohne weiteres als Basis für die Entwicklung oder Modifizierung anderer Verfahren und Strukturen verwenden können, um dieselben Zwecke zu erfüllen und/oder dieselben Vorteile der hierin vorgestellten Ausführungsformen zu erzielen. Fachleute sollten sich auch darüber im Klaren sein, dass solche äquivalenten Konstruktionen nicht vom Geist und Umfang der vorliegenden Offenbarung abweichen, und dass sie verschiedene Änderungen, Ersetzungen und Abwandlungen vornehmen können, ohne vom Geist und Umfang der vorliegenden Offenbarung abzuweichen.

Claims

Simulationssystem, umfassend: eine Vielzahl von Rechenressourcen, die eine Vielzahl von Prozessorkernen umfasst; ein Betriebssystem, das so konfiguriert ist, dass es eine Vielzahl von Ausführungs-Threads (Threads) unter Verwendung der Vielzahl von Prozessorkernen implementiert, wobei das Betriebssystem so konfiguriert ist, dass es jedem Thread ein Zeitquantum einer vorbestimmten Ausführungszeit zuteilt, während der der Thread während der Ausführung nicht vorgezogen wird; einen Multithread-Scheduler, der so konfiguriert ist, dass er die Timing-Anforderungen jeder einer Vielzahl von Aufgaben überwacht, die in einem Anwendungscode für eine Vielzahl von unterschiedlichen virtuellen Plattformen umfasst sind, jede der Vielzahl von Aufgaben in eine oder mehrere Sequenzen von programmierten Anweisungen segmentiert, die die Ausführung in einem Thread innerhalb des Zeitquantums abschließen können, und die eine oder mehreren Sequenzen von programmierten Anweisungen für jede der Vielzahl von Aufgaben als eine Vielzahl von programmierten Anweisungssequenzen mit spezifischen Timing-Anforderungen bereitstellt; und einen Umgebungsmanager, der so konfiguriert ist, dass er jede der Vielzahl von programmierten Anweisungssequenzen basierend auf den spezifischen Timing-Anforderungen so plant, dass sie in einem der Vielzahl von Threads zu einem geeigneten Zeitpunkt ausgeführt wird; wobei das Simulationssystem eine Echtzeitsimulation des Anwendungscodes unter Nutzung von verfügbarer Rechenleistung bei voller Kapazität ermöglicht.
Simulationssystem nach Anspruch 1, wobei der Umgebungsmanager ferner so konfiguriert ist, dass er eine Vielzahl von Simulationsfenstern erzeugt, wobei jedes Simulationsfenster so konfiguriert ist, dass es eine Vielzahl von programmierten Anweisungssequenzen mit spezifischen Timing-Anforderungen für eine spezifische virtuelle Plattform ausführt, wobei die Vielzahl von Simulationsfenstern die Multi-Domain-Simulation der Vielzahl von virtuellen Plattformen erleichtert.
Simulationssystem nach Anspruch 2, wobei der Umgebungsmanager ferner eine Interprozessorkommunikations (IPC, inter-processor communication)-Anwendungsprogrammierschnittstelle (API, application programming interface) umfasst, um die Kommunikation zwischen programmierten Anweisungssequenzen zu erleichtern, die in unterschiedlichen Simulationsfenstern für unterschiedliche virtuelle Plattformen ausgeführt werden.
Simulationssystem nach Anspruch 3, wobei die IPC-API die Kommunikation zwischen virtuellen Plattformen, die in verschiedenen Simulationsfenstern ausgeführt werden, erleichtert, basierend auf: Empfangen von Mitteilungen von einer virtuellen Plattform, die an eine andere virtuelle Plattform gerichtet sind; Aufbauen einer kreisförmigen Sendernachrichten-Signalwarteschlange zum Empfangen der Mitteilungen; Bereitstellen eines ausgewogenen IPC-Handlers zum Handhaben von IPC in der kreisförmigen Sendernachrichten-Signalwarteschlange; Aufbauen einer kreisförmigen semaphorgeschützten Multithread-Warteschlange für die vom IPC-Handler gehandhabte IPC; und Bereitstellen eines gemeinsamen IPC-Pools von Kernel-Objekt-Handlern für das Planen von Aktivierungen virtueller Plattformen zum Empfangen von Mitteilungen.
Simulationssystem nach Anspruch 3, wobei die IPC-API die gleichzeitige Multi-Domain-Simulation mehrerer virtueller Plattformen durch eines oder mehrere ermöglicht von: einem Netzwerkkommunikationsprotokoll; Kommunikation mit einem Simulator; Kommunikation mit einem Controller der realen Welt; Bereitstellen einer grafischen Benutzeroberfläche für Speichersonden; oder Bereitstellen einer Bedingungssonde.
Simulationssystem nach Anspruch 2, wobei der Umgebungsmanager ferner einen Zeitsynchronisationsmanager umfasst, der so konfiguriert ist, dass er jede der Vielzahl von programmierten Anweisungssequenzen für eine virtuelle Plattform abruft und die planungszeitsynchrone Ausführung jeder der Vielzahl von programmierten Anweisungssequenzen in einem der Simulationsfenster plant.
Simulationssystem nach Anspruch 2, wobei jedes Simulationsfenster eine Functional Mock-up Unit (FMU) darstellt und eine erste ausführende FMU als primärer FMU-Prozess bezeichnet wird, und nachfolgende ausführende FMUs als sekundäre FMU-Prozesse bezeichnet werden, wobei der primäre FMU-Prozess ein Taktsignal erzeugt, das zum Synchronisieren des Betriebs von Quantumsaufgaben im primären FMU-Prozess und Quantumsaufgaben in den sekundären FMU-Prozessen verwendet wird.
Verfahren in einem Simulationssystem, umfassend: Implementieren einer Vielzahl von Ausführungs-Threads (Threads) unter Verwendung einer Vielzahl von Prozessorkernen und eines Betriebssystems, das jedem Thread ein Zeitquantum einer vorbestimmten Ausführungszeit zuteilt, während der der Thread während der Ausführung nicht vorgezogen wird; Überwachen von Timing-Anforderungen jeder einer Vielzahl von Aufgaben, die im Anwendungscode für eine Vielzahl von verschiedenen virtuellen Plattformen umfasst sind; Segmentieren jeder der Vielzahl von Aufgaben in eine oder mehrere Sequenzen von programmierten Anweisungen, die die Ausführung in einem Thread innerhalb eines Zeitquantums abschließen können; Bereitstellen der einen oder mehreren Sequenzen von programmierten Anweisungen für jede der Vielzahl von Aufgaben als eine Vielzahl von programmierten Anweisungssequenzen mit spezifischen Timing-Anforderungen; Planen von jeder der Vielzahl von programmierten Anweisungssequenzen basierend auf den spezifischen Timing-Anforderungen, um in einem der Vielzahl von Threads zu einem geeigneten Zeitpunkt ausgeführt zu werden; und Durchführen einer Echtzeitsimulation des Anwendungscodes unter Nutzung von verfügbarer Rechenleistung bei voller Kapazität.
Verfahren nach Anspruch 8, das ferner das Erzeugen einer Vielzahl von Simulationsfenstern umfasst, wobei jedes Simulationsfenster so konfiguriert ist, dass es eine Vielzahl von programmierten Befehlssequenzen mit spezifischen Timing-Anforderungen für eine spezifische virtuelle Plattform ausführt, wobei die Vielzahl von Simulationsfenstern die Multi-Domain-Simulation der Vielzahl von virtuellen Plattformen erleichtert.
Verfahren nach Anspruch 9, das ferner das Erleichtern von Kommunikation zwischen virtuellen Plattformen umfasst, die in verschiedenen Simulationsfenstern ausgeführt werden, basierend auf: Empfangen von Mitteilungen von einer virtuellen Plattform, die an eine andere virtuelle Plattform gerichtet sind; Aufbauen einer kreisförmigen Sendernachrichten-Signalwarteschlange zum Empfangen der Mitteilungen; Bereitstellen eines ausgewogenen IPC-Handlers zum Handhaben von IPC in der kreisförmigen Sendernachrichten-Signalwarteschlange; Aufbauen einer kreisförmigen semaphorgeschützten Multithread-Warteschlange für die vom IPC-Handler gehandhabte IPC; und Bereitstellen eines gemeinsamen IPC-Pools von Kernel-Objekt-Handlern für das Planen von Aktivierungen virtueller Plattformen zum Empfangen von Mitteilungen.