DE102011101920A1

DE102011101920A1 - Fahrzeugsystemmodellerstellungssysteme und -verfahren

Info

Publication number: DE102011101920A1
Application number: DE102011101920A
Authority: DE
Inventors: Michael A. Kropinski; Minghui Kao; Gary Ferries; Hamid M. Esfahan; Wen-Chuan Lin; Michael A. Steele; Onassis Matthews
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2010-05-24
Filing date: 2011-05-18
Publication date: 2011-11-24
Also published as: US20110288840A1; US8739049B2; CN102262394B; CN102262394A

Abstract

Ein Fahrzeugsimulationssystem umfasst ein Compiler-Modul, ein Parser-Modul, ein Wrapper-Modul, ein Modellerstellungsmodul und ein Simulationsmodul. Das Compiler-Modul erzeugt einen Objektcode, der mit einem ersten Typ von Betriebssystem kompatibel ist, auf der Grundlage von Sourcecode, der durch ein Fahrzeugsteuermodul ausgeführt werden kann und der mit einem zweiten Typ von Betriebssystem kompatibel ist. Das Parser-Modul erzeugt eine Definitionsdatei und eine Extensible Markup Language-Datei (XML-Datei) auf der Grundlage des Sourcecodes und des Objektcodes. Das Wrapper-Modul erzeugt auf der Grundlage des Objektcodes und der Definitionsdatei eine Bibliotheksdatei. Das Modellerstellungsmodul erzeugt einen modellbasierten Sourcecode für ein virtuelles Modell auf der Grundlage der XML-Datei und einer Benutzerkonfiguration des virtuellen Modells. Das Simulationsmodul simuliert den Betrieb einer Anlage eines Fahrzeugs mit dem virtuellen Modell.

Description

QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
Diese Anmeldung beansprucht die Priorität der vorläufigen US-Anmeldung Nr. 61/347,629, die am 24. Mai 2010 eingereicht wurde. Der Offenbarungsgehalt der obigen Anmeldung ist hierin durch Bezugnahme vollständig mit eingeschlossen.
Diese Anmeldung ist mit der US-Patentanmeldung Nr. 12/861,207 [P012068 (8540P-001121)] verwandt, die am 23. August 2010 eingereicht wurde. Der Offenbarungsgehalt der obigen Anmeldung ist hierin durch Bezugnahme vollständig mit eingeschlossen.
GEBIET
Die vorliegende Offenbarung bezieht sich auf Fahrzeughardware- und -softwaresimulationssysteme und -verfahren.
HINTERGRUND
Die hierin bereitgestellte Beschreibung des Hintergrunds dient dem Zweck des allgemeinen Erläuterns des Kontexts der Offenbarung. Die Arbeiten der hierin genannten Erfinder, in dem Umfang, wie sie in dem Hintergrundabschnitt beschrieben werden, sowie die Aspekte der Beschreibung, die zum Zeitpunkt der Anmeldung nicht möglicherweise anderweitig Stand der Technik bilden, werden weder ausdrücklich noch implizit als Stand der Technik gegen die vorliegende Offenbarung zugelassen.
Fahrzeugcontroller und -hardware können vor der Produktion in einer simulierten Umgebung getestet werden, um eine Komponenten- und Systemgenauigkeit sicherzustellen. Die simulierte Umgebung wird durch ein Fahrzeugsimulationssystem bereitgestellt. Es existieren Fahrzeugsimulationssysteme für ein Hardware in the Loop-Testen (HIL-Testen). Ein HIL-Testen umfasst das Verwenden von eingebetteter Software, die an einem Zielsteuermodul ausgeführt wird, das eine Schnittstelle mit physikalischen und simulierten Lasten bildet.
Obwohl ein HIL-Testen effektiv sein kann, erfordert das HIL-Testen das Entwickeln von physikalischen Lasten oder in Echtzeit simulierten Lasten, was teuer sein kann und nur spät in einem Entwicklungszyklus ausgeführt werden kann. Ein HIL-Testen umfasst auch das Verwenden eines Satzes von Hardwareeinrichtungen, wie beispielsweise eines Fahrzeugsteuermoduls (z. B. eines Getriebesteuermoduls) und eines Signalsimulators.
ZUSAMMENFASSUNG
Ein Fahrzeugsimulationssystem umfasst ein Compiler-Modul, ein Parser-Modul, ein Wrapper-Modul, ein Modellerstellungsmodul und ein Simulationsmodul. Das Compiler-Modul erzeugt einen Objektcode, der mit einem ersten Typ von Betriebssystem kompatibel ist, auf der Grundlage von Sourcecode, der durch ein Fahrzeugsteuermodul ausgeführt werden kann und der mit einem zweiten Typ von Betriebssystem kompatibel ist. Das Parser-Modul erzeugt eine Definitionsdatei und eine Extensible Markup Language-Datei (XML-Datei) auf der Grundlage des Sourcecodes und des Objektcodes. Das Wrapper-Modul erzeugt auf der Grundlage des Objektcodes und der Definitionsdatei eine Bibliotheksdatei. Das Modellerstellungsmodul erzeugt einen modellbasierten Sourcecode für ein virtuelles Modell auf der Grundlage der XML-Datei und einer Benutzerkonfiguration des virtuellen Modells. Das Simulationsmodul simuliert den Betrieb einer Anlage eines Fahrzeugs mit dem virtuellen Modell.
Ein Fahrzeugsimulationsverfahren umfasst, dass: Objektcode, der mit einem ersten Typ von Betriebssystem kompatibel ist, auf der Grundlage von Sourcecode erzeugt wird, der durch ein Fahrzeugsteuermodul ausgeführt werden kann und der mit einem zweiten Typ von Betriebssystem kompatibel ist; eine Definitionsdatei und eine Extensible Markup Language-Datei (XML-Datei) auf der Grundlage des Sourcecodes und des Objektcodes erzeugt wird; eine Bibliotheksdatei auf der Grundlage des Objektcodes und der Definitionsdatei erzeugt wird; ein modellbasierter Sourcecode für ein virtuelles Modell auf der Grundlage der XML-Datei und einer Benutzerkonfiguration des virtuellen Modells erzeugt wird; und der Betrieb einer Anlage eines Fahrzeugs mit dem virtuellem Modell simuliert wird.
Gemäß noch weiteren Merkmalen werden die oben beschriebenen Systeme und Verfahren durch ein Computerprogramm realisiert, das durch einen oder mehrere Prozessoren ausgeführt wird. Das Computerprogramm kann sich an einem konkreten von einem Computer lesbaren Medium, wie beispielsweise, jedoch ohne Einschränkung, einem Speicher, einem nichtflüchtigen Datenspeicher und/oder anderen geeigneten konkreten Speichermedien befinden.
Weitere Anwendungsgebiete der vorliegenden Offenbarung werden aus der hierin nachfolgend bereitgestellten detaillierten Beschreibung ersichtlich. Es ist zu verstehen, dass die detaillierte Beschreibung und die spezifischen Beispiele lediglich Erläuterungszwecken dienen sollen und den Schutzumfang der Offenbarung nicht einschränken sollen.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Offenbarung wird aus der detaillierten Beschreibung und den begleitenden Zeichnungen deutlicher verständlich, in denen:
1A, 1B und 2 Funktionsblockdiagramme beispielhafter Fahrzeugsimulationssysteme gemäß den Prinzipien der vorliegenden Offenbarung sind;
3 eine Darstellung einer beispielhaften Dateistruktur eines Betriebssystems gemäß den Prinzipien der vorliegenden Offenbarung ist;
4 eine Darstellung einer beispielhaften ersten grafischen Benutzerschnittstelle (GUI von graphical user interface) gemäß den Prinzipien der vorliegenden Offenbarung ist;
5 eine Darstellung einer beispielhaften zweiten GUI gemäß den Prinzipien der vorliegenden Offenbarung ist;
6 eine Darstellung einer ersten beispielhaften Software in the Loop-GUI (SIL-GUI) gemäß den Prinzipien der vorliegenden Offenbarung ist;
7 eine Darstellung einer zweiten beispielhaften SIL-GUI gemäß den Prinzipien der vorliegenden Offenbarung ist;
8 eine weitere beispielhafte Darstellung der ersten SIL-GUI gemäß den Prinzipien der vorliegenden Offenbarung ist;
9 eine weitere beispielhafte Darstellung der zweiten SIL-GUI gemäß den Prinzipien der vorliegenden Offenbarung ist;
10 eine weitere beispielhafte Darstellung der ersten SIL-GUI gemäß den Prinzipien der vorliegenden Offenbarung ist;
11 eine weitere beispielhafte Darstellung der zweiten SIL-GUI gemäß den Prinzipien der vorliegenden Offenbarung ist;
12–14 beispielhafte Darstellungen einer dritten beispielhaften SIL-GUI gemäß den Prinzipien der vorliegenden Offenbarung sind; und
15 ein beispielhaftes Verfahren zum Durchführen einer Fahrzeugsystemsimulation gemäß den Prinzipien der vorliegenden Offenbarung ist.
DETAILLIERTE BESCHREIBUNG
Die folgende Beschreibung ist lediglich beispielhafter Natur und beabsichtigt keineswegs, die Offenbarung, ihre Anwendung oder Verwendungen zu beschränken. Zu Klarheitszwecken werden in den Zeichnungen die gleichen Bezugszeichen verwendet, um ähnliche Elemente zu identifizieren. Wie hierin verwendet, sollte die Phrase mindestens einer von A, B und C als ein logisches (A oder B oder C) bedeutend betrachtet werden, wobei ein nicht exklusives logisches Oder verwendet wird. Es ist zu verstehen, dass Schritte innerhalb eines Verfahrens in einer anderen Reihenfolge ausgeführt werden können, ohne die Prinzipien der vorliegenden Offenbarung zu verändern.
Eine erste Alternative zu einem Hardware in the Loop-Testen (HIL-Testen) umfasst die Simulation eines Fahrzeugsteuermoduls unter Verwendung von Sourcecode (z. B. C-Code, Fortran, etc.) und die Simulation eines Anlagenmodells. Der Sourcecode kann Handcode oder Code sein, der auf eine automatisierte Weise erzeugt wird (Autocode genannt). Handcode kann sich auf die manuelle Bearbeitung von Sourcecode beziehen und kann Fehler umfassen. Der HIL-Testansatz kann nicht erweitert werden, da der mit dem Fahrzeugsteuermodul in Verbindung stehende Code fest ist. Änderungen am Sourcecode und die Ausführung von zusätzlichen Simulationen sind unter Verwendung dieses Ansatzes mühsam.
Eine weitere Alternative zum HIL-Testen (bezeichnet als 2-Modus-Hybridbustesten) umfasst das Simulieren eines Fahrzeugsteuermoduls und von Fahrzeugkomponenten oder -systemen unter Verwendung von modellbasierter Software. Die modellbasierte Simulationssoftware (z. B. Matlab- und Simulink-Software von Mathworks) arbeitet in einem Microsoft Windows-Betriebssystem und umfasst das Verbinden von Funktionsblöcken und entsprechenden Eingängen und Ausgängen, um ein Modell zu erzeugen. In der Windows-Umgebung werden Modelle entwickelt, und auf der Grundlage der entwickelten Modelle kann Autocode erzeugt werden. Die modellbasierte Software ist benutzerfreundlich und ermöglicht eine einfache Bearbeitung von Modellen, Funktionsblöcken, Signalen etc. Das 2-Modus-Hybridbustesten ermöglicht jedoch keine Einbeziehung von Software eines Fahrzeugsteuermoduls, die in C-Code geschrieben ist.
Als Alternative zum HIL-Testen kann ein Software in the Loop-Testen (SIL-Testen) durchgeführt werden. SIL-Testen umfasst eine Kraftfahrzeugsteuersystemsimulation, bei der das Verhalten des gesamten Steueralgorithmus oder eines Teils hiervon erhalten wird, indem eine eingebettete Prozessorsoftware mit tatsächlichem Ziel eines Fahrzeugsteuermoduls in der Simulationsumgebung ausgeführt wird. Das SIL-Testen umfasst, dass Lasten simuliert werden, wie beispielsweise Eingänge und Ausgänge von: einem Car Area Network (CAN), Steuermodulen, Anlagenmodellen, Sensoren, etc.
In einer SIL-Testumgebung ist eine Zielsoftware, wie beispielsweise die Software eines Getriebesteuermoduls (TCM von transmission control module) virtuell mit einem Anlagenmodell gekoppelt. Das SIL-Testen erfordert keine spezielle mit der Anlage in Verbindung stehende Hardware. Ein Anlagenmodell simuliert den tatsächlichen Betrieb der Anlage (z. B. Maschine, Getriebe oder Fahrzeugdynamik). Das Anlagenmodell empfangt Eingänge von einem simulierten Steuermodul und erzeugt Ausgänge, die zurückgeführt werden können. Die virtuelle Kopplung der Zielsoftware mit einem Anlagenmodell ermöglicht einem Fahrzeugsystem, in einer virtuellen Umgebung früh in einem Entwicklungszyklus bewertet zu werden.
In der folgenden Beschreibung bezieht sich der Begriff Task auf eine Softwarefunktion, die während einer Simulation durchgeführt wird, oder ein Element, eine Funktion oder einen Schritt, das, die oder der während eines Verfahrens durchgeführt wird. Eine Funktion bezieht sich auf eine Subroutine oder ein Subprogramm, die oder das ein Codeabschnitt in eifern größeren Programm ist. Ein Task kann mehrere Sub-Tasks umfassen. In der folgenden Beschreibung bezieht sich auch der Begriff Ring auf einen Satz von Tasks oder Funktionen.
Nun auf 1A Bezug nehmend ist ein Funktionsblockdiagramm eines Fahrzeugsimulationssystems 2 dargestellt. Das Fahrzeugsimulationssystem 2 umfasst einen Host 4 mit einem Host-Steuermodul 6 und einem Speicher 8. Der Speicher 8 kann entfernt von dem Host 4 angeordnet sein und es kann auf ihn über ein Netz zugegriffen werden, oder er kann in dem Host 4 angeordnet sein, wie es gezeigt ist.
Das Host-Steuermodul 6 umfasst ein Fahrzeugsystemsimulations-Steuermodul (VSS-Steuermodul von vehicle system simulation control module) 10, das die Simulation eines/r oder mehrerer Fahrzeugsteuermodule, Komponenten und Systeme eines Fahrzeugs steuert. Das VSS-Steuermodul 10 kann steuern: Umwandeln von Sourcecode in modellbasierten Code; Kombinieren von modellbasiertem Code, der aus Sourcecode erzeugt wird, und modellbasiertem Code, der über Simulationssoftware erzeugt wird; und Erzeugung eines Modells auf der Grundlage von modellbasiertem Code.
Das Host-Steuermodul 6 kann ein Modellerzeugungsmodul 12, ein Planungsmodul 14, ein Fahrzyklusmodul 20, ein Anlagenmodellauswahlmodul 22, ein Datenverarbeitungsmodul 24, ein Kalibrierungsmodul 26 und ein Debugger-Modul 28 umfassen.
Das Modellerzeugungsmodul 12 erzeugt SIL-Modelle. Beispielsweise kann das Modellerzeugungsmodul 12 verwendet werden, um ein Modell zu erzeugen, das in Verbindung mit einem Modell einer Anlage, wie beispielsweise eines Getriebes, einer Maschine, eines Fahrzeugs, oder einer anderen geeigneten Anlage, verwendet werden kann. Das Modellerzeugungsmodul 12 kann ein oder mehrere Modelle aufbauen, was das Verknüpfen von Eingängen und Ausgängen der neu erzeugten Modelle mit Objekten von anderen Modellen umfasst. Verknüpfen kann sich beispielsweise auf das Verbinden der Eingänge und Ausgänge eines Modells mit Signalleitungen oder Knoten eines Blocks und/oder Modells beziehen. Objekte können Knoten, Signalleitungen, Eingänge, Ausgänge, gespeicherte Variablen etc. sein.
Das Planungsmodul 14 plant die Reihenfolge, in der die Simulations-Tasks in der Simulationsumgebung durchgeführt werden. Das Planungsmodul 14 kann ereignis- und/oder zeitbasiert sein. Die Tasks können auf der Grundlage von Bedingungen durchgeführt werden und/oder können beispielsweise in einer sequentiellen Reihenfolge durchgeführt werden. Als Beispiel kann eine Reihe von Tasks durchgeführt werden, wenn eine bestimmte Bedingung oder ein bestimmtes Ereignis auftritt. Es können mehrere Tasks während einer gegebenen Periode durchgeführt werden. Das Planungsmodul 14 kann beispielsweise Algorithmus-Tasks, Funktionen, Steuersystemsoftware-Tasks und andere geeignete Tasks planen.
Das Fahrzyklusmodul 20 steuert Eingänge in ein oder mehrere Steuermodelle. Beispielsweise kann das Fahrzyklusmodul 20 zwischen Benutzereingängen, vordefinierten Signaleingängen und gespeicherten Fahrzeugsignalen für ein gegebenes Modell auswählen und diese liefern.
Das Anlagenmodellauswahlmodul 22 wählt ein Genauigkeitsniveau eines oder mehrerer Anlagenmodelle aus. Ein Genauigkeitsniveau bezieht sich auf die Komplexität eines Anlagenmodells und einen Grad, zu dem das Anlagenmodell tatsächliche Komponenten und/oder Systeme der Anlage präzise simuliert. Die Simulation eines Anlagenmodells mit einem größeren Genauigkeitsniveau kann präziser simulieren, wie die Anlage tatsächlich arbeitet. Die Verarbeitungszeit wird jedoch für ein größeres Genauigkeitsniveau im Allgemeinen länger als für ein kleineres Genauigkeitsniveau.
Das Datenverarbeitungsmodul 24 wählt Objekte zum Überwachen, ruft verschiedene Daten ab, verarbeitet verschiedene Daten etc. Daten, die mit den überwachten Objekten in Verbindung stehen, werden in Objektdatendateien 30 in dem Speicher 8 gespeichert. Das Kalibrierungsmodul 26 ermöglicht eine Kalibrierung von Variablen oder gespeicherten Werten (in Kalibrierungsdateien 32) in dem Speicher 8. Das Kalibrierungsmodul 26 kann Werte von verschiedenen Typen anpassen, die Boolsche Werte, Skalarwerte, tabellarische Werte etc. umfassen. Das Debugger-Modul 28 wird verwendet, um einen modellbasierten Code zu debuggen.
Der Speicher 8 kann beispielsweise eine Sourcecode basierte Bibliothek 40, eine modelerstellungsumgebungsbasierte Bibliothek 42, geteilte Eingangsvariablen 44, geteilte Ausgangsvariablen 46 und eine Funktionsbibliothek 48 umfassen. Die Sourcecode basierte Bibliothek 40 umfasst einen modellbasierten Code für Modelle (oder Modellsätze 50), die auf der Grundlage von Sourcecode erzeugt werden. Der modellbasierte Code kann in einer Modellerstellungsumgebung ausgeführt werden und verwendet werden, um ein virtuelles Modell zu erzeugen. Die virtuellen Modelle können in der Modellerstellungsumgebung unter Verwendung von modellbasierter Software betrachtet werden. Es kann modellbasierter Code beim Durchführen einer Simulation und Simulieren des Betriebs des Modells in der Simulationsumgebung mit einem oder mehreren anderen Modellen verwendet werden.
Die modellerstellungsumgebungsbasierte Bibliothek 42 kann Modelle umfassen. Lediglich beispielhaft können die Modelle Anlagenmodelle 52, wie beispielsweise Steuermodelle 54, Sensormodelle 56, Controller Area Network-Modelle (CAN-Modelle) 58, Aktormodelle 60, Getriebemodelle 62, Maschinenmodelle 64, Fahrzeugmodelle 66, und andere geeignete Modelle umfassen.
Jedes Anlagenmodell kann verwendet werden, um eine entsprechende Anlage zu simulieren. Lediglich beispielhaft kann ein Sensormodell verwendet werden, um einen Sensor eines Fahrzeugs zu simulieren, wie beispielsweise einen Maschinendrehzahlsensor, einen Fahrzeuggeschwindigkeitssensor, einen Temperatursensor, einen Drucksensor, einen Strömungsratensensor etc. Es kann ein CAN-Modell verwendet werden, um Ausgangssignale zu simulieren, die über ein CAN eines Fahrzeugs empfangen werden. Es kann ein Aktormodell verwendet werden, um einen Aktor, wie beispielsweise eine Zündkerze, einen Elektromotor, eine Drosselklappe, ein Solenoid, einen Kraftstoffinjektor, oder einen anderen Aktor eines Fahrzeugs zu simulieren.
Die geteilten Eingangs- und Ausgangsvariablen 44 und 46 können sich auf Variablen beziehen, die von einem oder mehreren Modellen geteilt werden können. Die geteilten Eingangs- und Ausgangsvariablen 44 und 46 können globale Variablen umfassen, oder können Variablen umfassen, die mit einem/r oder mehreren von Modellen, Algorithmen oder Funktionen in Verbindung stehen können. Die Funktionsbibliothek 48 kann zusätzliche Standardblöcke umfassen, wie beispielsweise mathematische Funktionen, die verwendet werden, um einen oder mehrere Blöcke zu erzeugen.
Der Host 4 kann auch eine Anzeige 70, eine Benutzereingabeeinrichtung 72 und einen Compiler 74 umfassen. Eine oder mehrere grafische Benutzerschnittstellen (GUIs) 76, die durch das Host-Steuermodul 6 erzeugt werden, können für einen Benutzer über die Anzeige 70 angezeigt werden. Die Benutzereingabeeinrichtung 72 kann beispielsweise eine Zeigereinrichtung (z. B. eine Maus, Stift und Tablet, Touchscreen, etc.), eine Tastatur und/oder eine oder mehrere andere geeignete Einrichtungen umfassen. Die Benutzereingabeeinrichtung 72 kann bei verschiedenen Realisierungen die Anzeige 70 umfassen. Die Anzeige 70 kann beispielsweise einen Monitor, einen Projektor oder eine andere geeignete Anzeigeeinrichtung umfassen. Der Compiler 74 kann einen oder mehrere Typen von Code, wie beispielsweise Sourcecode, modellbasierten Code und/oder Autocode, kompilieren.
Nun auf 1B Bezug nehmend wird ein weiteres Funktionsblockdiagramm eines beispielhaften VSS-Systems 100 dargestellt. Eine Sourcecodedatei 102 umfasst Sourcecode zur Verwendung beim Erzeugen eines Modells in einer Modellerstellungsumgebung. Der Betrieb des Modells mit einem oder mehreren anderen Modellen, wie beispielsweise einem Modell einer Anlage (z. B. einer Maschine, eines Getriebes, eines Abgassystems, eines Fahrzeugs oder einer anderen geeigneten Anlage) kann in einer Simulationsumgebung simuliert werden. Lediglich beispielhaft kann der Sourcecode in einer Fortran-Programmiersprache, einer C-Programmiersprache oder einer anderen geeigneten Programmiersprache vorliegen. Der Sourcecode kann auf eine automatisierte Weise, von Hand oder auf eine andere geeignete Weise entworfen werden.
Ein Cross-Compiler-Modul 106 kompiliert den Sourcecode. Das Cross-Compiler-Modul 106 kann den Sourcecode in Objektcode umwandeln und den Objektcode in einer Objektcodedatei 110 speichern. Der Objektcode kann ein binärer Code sein, der mit einem anderen Betriebssystem als dem Betriebssystem, an dem das Cross-Compiler-Modul 106 läuft, kompatibel ist. Das Betriebssystem, an dem das Cross-Compiler-Modul 106 läuft, wird als erstes Betriebssystem bezeichnet, und das Betriebssystem, das mit dem Objektcode kompatibel ist, wird als zweites Betriebssystem bezeichnet. Lediglich beispielhaft kann das erste Betriebssystem ein Linux-basiertes Betriebssystem oder ein anderes geeignetes Betriebssystem umfassen und kann das zweite Betriebssystem ein Microsoft Windows-basiertes Betriebssystem oder ein anderes geeignetes Betriebssystem umfassen. Lediglich beispielhaft kann das Cross-Compiler-Modul 106 bei verschiedenen Realisierungen ein mingw32-gcc-Modul umfassen.
Ein Parser-Modul 114 extrahiert eine Information aus der Sourcecodedatei 102 und der Objektcodedatei 110. Das Parser-Modul 114 erzeugt eine Definitionsdatei 118 und eine Extensible Markup Language-Datei (XML-Datei) 122 auf der Grundlage der extrahierten Information. Die XML-Datei 122 umfasst eine Information, die den Sourcecode der Sourcecodedatei 102 beschreibt, wie beispielsweise in Verbindung stehende Variablen, Kalibrierungen, Funktionen, Algorithmen und andere geeignete Informationen. Die Definitionsdatei 118 enthält eine Information, die Daten beschreibt, die aus einer oder mehreren Bibliotheken zu exportieren sind.
Ein Wrapper-Modul 126 kann eine Sourcecode-Dynamic Link Library-Datei (Sourcecode-DLL-Datei) 130 und eine Datei 134 einer statischen Bibliothek auf der Grundlage von Daten von der Definitionsdatei 118 und der Objektcodedatei 110 erzeugen. Lediglich beispielhaft kann das Wrapper-Modul 126 bei verschiedenen Realisierungen ein mingw32-dllwrap-Modul umfassen. Bei verschiedenen Realisierungen können die Sourcecode-DLL-Datei 130 und die Datei 134 einer statischen Bibliothek in einer Datei umfasst sein.
Ein Kalibrierungsfreigabemodul 138 extrahiert eine Kalibrierungsinformation von der Sourcecode-DLL-Datei 130 und einer oder mehreren Datendateien (.DAT-Dateien), wie beispielsweise der Datendatei 142. Das Kalibrierungsfreigabemodul 138 erzeugt auf der Grundlage von Daten von der Sourcecode-DLL-Datei 130 und/oder der einen oder den mehreren Datendateien eine Kalibrierungsdatei 146. Die Kalibrierungsdatei 146 kann eine Information umfassen, die durch ein Kalibrierungsmodul, wie beispielsweise ein INCA-Modul (nicht gezeigt), verwendet werden kann. Lediglich beispielhaft kann die Kalibrierungsdatei 146 eine XML-Datei sein.
Bei einer Aufforderung über eine Benutzereingabe erzeugt ein Modellerstellungsmodul 160 eine oder mehrere grafische Benutzerschnittstellen (GUIs) (z. B. siehe 2–14) und zeigt es diese an. Die Benutzereingabe kann eine Benutzereingabe umfassen, die über eine Zeigereinrichtung (z. B. eine Maus, Stift und Tablet, Touchscreen, etc.), eine Tastatur und/oder eine oder mehrere andere geeignete Einrichtungen vorgenommen wird. Die eine oder die mehreren GUIs können an einem Anzeigebildschirm (z. B. einem Monitor), einem Projektor oder einer anderen geeigneten Anzeigeeinrichtung angezeigt werden.
Das Modellerstellungsmodul 160 kann in dem zweiten Betriebssystem arbeiten. Genauer gesagt kann das Modellerstellungsmodul 160 in einer Modellerstellungsumgebung (z. B. Programmraum) arbeiten, die mit dem zweiten Betriebssystem kompatibel ist. Lediglich beispielhaft kann das Modellerstellungsmodul 160 in einer Simulink-Modellerstellungsumgebung arbeiten.
Das Modellerstellungsmodul 160 ruft Daten von der XML-Datei 122 ab und zeigt selektiv die abgerufenen Daten für den Benutzer über die eine oder die mehreren der GUIs an. Der Benutzer kann über die eine oder die mehreren GUIs ein Modell in dem Modellerstellungsbereich konfigurieren. Das Modellerstellungsmodul 160 erzeugt auf der Grundlage der Daten, die von der XML-Datei 122 abgerufen werden, und der Konfiguration, die durch den Benutzer bereitgestellt wird, eine Modellsourcecodedatei 164. Die Modellsourcecodedatei 164 umfasst Code, der mit dem zweiten Betriebssystem kompatibel ist und in dem Modellerstellungsbereich funktioniert. Lediglich beispielhaft kann die Modellsourcecodedatei 164 einen S-Funktionscode oder einen anderen geeigneten Typ von Code umfassen. Mit anderen Worten kann die Modellsourcecodedatei 164 einen Code umfassen, der in einer S-Funktionsprogrammiersprache oder in einer anderen geeigneten Programmiersprache geschrieben ist.
Ein Modul 168 zur Erzeugung einer ausführbaren erzeugt eine ausführbare DLL-Datei 172 (auch als dynamisch ladbare ausführbare bezeichnet) auf der Grundlage der Sourcecode-DLL-Datei 130 und der Modellsourcecodedatei 164. Das Modul 168 zur Erzeugung einer ausführbaren kann die ausführbare DLL-Datei 172 ferner auf der Grundlage der Datei 134 einer statischen Bibliothek erzeugen. Das Modul 168 zur Erzeugung einer ausführbaren kann beispielsweise die Modellsourcecodedatei 164 zu der ausführbaren DLL-Datei 172 kompilieren und verlinken. Die ausführbare DLL-Datei 172 kann in der Modellerstellungsumgebung durch die Modellerstellungs-/Simulationssoftware ausgeführt werden. Lediglich beispielhaft kann die ausführbare DLL-Datei 172 in Verbindung mit einer Modelldatei 176 ausgeführt werden, die cm Modell der Anlage umfasst.
Nun auf 2 Bezug nehmend wird ein weiteres beispielhaftes Funktionsblockdiagramm des VSS-Systems 100 dargestellt. Ein Aufbaumodul 202 kann das Cross-Compiler-Modul 106, das Parser-Modul 114 und das Wrapper-Modul 126 umfassen. Das Aufbaumodul 202 kann auch ein Zipper-Modul 206 umfassen.
Das Zipper-Modul 206 kann die Sourcecodedatei 102 zu einer Sourcecode-Zip-Datei 210 zippen. Das Zipper-Modul 206 kann die XML-Datei 122, die Sourcecode-DLL-Datei 130, die Datei 134 einer statischen Bibliothek und die Sourcecode-Zip-Datei 210 zu einer Zip-Datei 214 zippen. Lediglich beispielhaft kann das Zipper-Modul 206 die Zip-Datei 214 erzeugen und die XML-Datei 122, die Sourcecode-DLL-Datei 130, die Datei 134 einer statischen Bibliothek und die Sourcecode-Zip-Datei 210 bei einer Auslösung über eine Benutzereingabe zu der Zip-Datei 214 zippen. Während dies nicht gezeigt ist, kann das Zipper-Modul 206 auch die Definitionsdatei 118 und eine oder mehrere andere Dateien zu der Zip-Datei 214 zippen. Die beispielhafte gestrichelte Linie 218 stellt eine beispielhafte Teilung zwischen dem ersten Betriebssystem und dem zweiten Betriebssystem dar.
Nun auf 3 Bezug nehmend ist eine beispielhafte Dateistruktur 300 des zweiten Betriebssystems dargestellt. Die Dateistruktur 300 kann N Elemente 302 der ersten Ebene umfassen, wobei N eine ganze Zahl, die größer als Null ist, ist. Lediglich beispielhaft können die Elemente 302 der ersten Ebene Ordner, Dateien oder andere geeignete Elemente umfassen. Jedes der Elemente 302 der ersten Ebene kann ein oder mehrere Subelemente umfassen, die als Elemente der zweiten Ebene bezeichnet werden können. Lediglich beispielhaft umfasst ein Element 310 der ersten Ebene Elemente 314 und 318 der zweiten Ebene.
Jedes der Elemente der zweiten Ebene kann ein oder mehrere Subelemente umfassen. Subelemente von Elementen der zweiten Ebene können als Elemente der dritten Ebene bezeichnet werden. Lediglich beispielhaft umfasst das Element 314 der zweiten Ebene ein Element 322 der dritten Ebene. Jedes der Elemente der dritten Ebene kann ein oder mehrere Subelemente umfassen und so weiter.
Die Dateistruktur 300 kann in einem ersten Sichtausschnitt 326 angezeigt werden. Wenn eines der Elemente der Dateistruktur 300 aus dem ersten Sichtausschnitt 326 ausgewählt wird, können die Subelemente des ausgewählten Elements, falls vorhanden, in einem zweiten Sichtausschnitt 330 dargestellt werden. Lediglich beispielhaft werden die Subelemente des Elements 314 der zweiten Ebene, wenn das Element 314 der zweiten Ebene in dem ersten Sichtausschnitt 326 ausgewählt wird, in dem zweiten Sichtausschnitt 330 angezeigt.
Wieder auf 2 Bezug nehmend und mit weiterer Bezugnahme auf 3 kann der Benutzer die Zip-Datei 214 als Subelement eines vorbestimmten der Elemente der Dateistruktur 300 speichern. Lediglich beispielhaft kann der Benutzer die Zip-Datei 214 als Subelement (d. h. ein Element der dritten Ebene) des Elements 314 der zweiten Ebene speichern, wie es in dem Beispiel von 3 gezeigt ist. Ein Entzipper-Modul 224, das in dem zweiten Betriebssystem arbeitet, entzippt selektiv die Zip-Datei 214. Genauer gesagt extrahiert das Entzipper-Modul 224 die in der Zip-Datei 214 gezippten Dateien an einem ausgewählten Ort. Lediglich beispielhaft kann das Entzipper-Modul 224 die Dateien als Subelemente des Elements 314 der zweiten Ebene extrahieren, wie es in dem Beispiel von 3 gezeigt ist. Die Sourcecode-Zip-Datei 210 kann als Subelement (d. h. ein Element der vierten Ebene) des Elements 322 der dritten Ebene extrahiert werden.
Auf diese Weise kann die Sourcecode-Zip-Datei 210 von den anderen extrahierten Dateien separat gehalten werden.
Das Modellerstellungsmodul 160 kann ein GUI-Modul 240, ein Datenabrufmodul 244, ein Konfigurationsmodul 248, ein Modellaktualisierungsmodul 252 und ein Simulationsmodul 256 umfassen. Wenn der Benutzer die Modellerstellungs-/Simulationssoftware öffnet, kann das GUI-Modul 240 eine erste GUI für den Benutzer öffnen und anzeigen.
Nun. auf 4 Bezug nehmend ist ein Diagramm einer beispielhaften ersten GUI 402 dargestellt. Die erste GUI 402 kann einen ersten Satz von vorbestimmten Optionen umfassen, wie beispielsweise eine Option 406, eine Option 410 etc. Lediglich beispielhaft kann der erste Satz von vorbestimmten Optionen arithmetische Operatoren, logische Operatoren, Vergleichsoperatoren, mathematische Funktionen, Zähler und Timer, Verzögerungsblöcke, Subsystemblöcke, nichtlineare Blöcke, Steuerblöcke und Filter und Durchschnitte umfassen. Der erste Satz von vorbestimmten Optionen kann beispielsweise auch Parameter und Konstanten, Signale, Analyseblöcke (wie beispielsweise Quellen und Senken), eine Modelldokumentation, zuvor verwendete Blöcke, Beispiele und eine Option 414 einer modellbasierten Codeerzeugung umfassen. Wenn der Benutzer die Option 414 einer modellbasierten Codeerzeugung auswählt, kann das GUI-Modul 240 eine zweite GUI für den Benutzer öffnen und anzeigen.
Nun auf 5 Bezug nehmend ist ein Diagramm einer beispielhaften zweiten GUI 502 dargestellt. Die zweite GUI 502 kann einen zweiten Satz von vorbestimmten Optionen, wie beispielsweise Option 506, Option 510, etc. umfassen. Lediglich beispielhaft kann der zweite Satz von vorbestimmten Optionen eine Datenobjekt-Assistent-Option, eine Modellhilfeoption, eine Option zum Erzeugen interner Typen, eine Legacy-Codeoption, eine Umgebungscontrolleroption und eine Software in the Loop-Option (SIL-Option) 514 umfassen. Wenn der Benutzer die SIL-Option 514 auswählt, kann das GUI-Modul 240 eine erste SIL-GUI für den Benutzer öffnen und anzeigen.
Nun auf 6 Bezug nehmend ist ein Diagramm einer beispielhaften ersten SIL-GUI 602 dargestellt. Wenn die SIL-Option 514 zum ersten Mal durch den Benutzer ausgewählt wird, wird ein SIL-Modul 606 in einem Anfangszustand (z. B. leer) für den Benutzer angezeigt. Das SIL-Modul 606, die Eingänge in das SIL-Modul 606 (nicht gezeigt) und die Ausgänge von dem SIL-Modul 606 (nicht gezeigt) können zusammen als virtuelles Modell bezeichnet werden. Ein Modell kann eine Anzahl von Null bis N SIL-Blöcken umfassen. Jeder SIL-Block steht zu einem gegebenen Zeitpunkt mit einer einzelnen DLL-Datei in Verbindung. Es können jedoch mehr als ein SIL-Block die gleiche zugrundeliegende DLL-Datei oder verschiedene zugrundeliegende DLL-Dateien verwenden. Man kann sich einen SIL-Block als einen beliebigen anderen Block in der Modellerstellungsumgebung vorstellen.
Der Benutzer kann ein zuvor gespeichertes virtuelles Modell über ein Menü 610 laden. Lediglich beispielhaft kann das Menü 610 ein Dateimenü umfassen, aus dem der Benutzer eine offene Option (nicht gezeigt) auswählen kann und das zuvor gespeicherte virtuelle Modell aus einem oder mehreren zuvor gespeicherten virtuellen Modellen auswählen kann. Wenn der Benutzer ein zuvor gespeichertes virtuelles Modell lädt, zeigt das GUI-Modul 240 das zuvor gespeicherte virtuelle Modell in der ersten SIL-GUI 602 an.
Der Benutzer kann ein virtuelles Modell über die erste SIL-GUI 602 auswählen. Lediglich beispielhaft kann der Benutzer ein virtuelles Modell durch Doppelklicken auf das SIL-Modul 606 oder auf eine andere geeignete Weise auswählen. Während hierin nachfolgend die Auswahl des SIL-Moduls 606 erläutert wird, kann die Auswahl eines zuvor gespeicherten virtuellen Modells ähnliche oder identische Ergebnisse liefern. Wenn ein virtuelles Modell ausgewählt wird, kann das GUI-Modul 240 eine zweite SIL-GUI für den Benutzer öffnen und anzeigen.
Nun auf 7 Bezug nehmend ist ein Diagramm einer beispielhaften zweiten SIL-GUI 702 dargestellt. Die zweite SIL-GUI 702 umfasst mehrere Felder, die der Benutzer verwenden kann, um das ausgewählte virtuelle Modell und/oder eine Funktion zu konfigurieren, die durch das ausgewählte virtuelle Modell aufgerufen werden kann. Lediglich beispielhaft kann die zweite SIL-GUI 702 ein SIL-Aufbaufeld 706, ein Funktionsfeld 710, ein Variablenfeld 714, ein Eingangsfeld 718 und ein Ausgangsfeld 722 umfassen.
Das Datenabrufmodul 244 ruft Daten für das SIL-Aufbaufeld 706, das Funktionsfeld 710 und das Variablenfeld 714 ab. Das Datenabrufmodul 244 füllt das SIL-Aufbaufeld 706, das Funktionsfeld 710 und das Variablenfeld 714 auf der Grundlage der abgerufenen Daten. Genauer gesagt füllt das Datenabrufmodul 244 die Menüs (z. B. Aufklappmenüs) 740, 744 und 748 des SIL-Aufbaufelds 706, des Funktionsfelds 710 bzw. des Variablenfelds 714 auf der Grundlage der abgerufenen Daten.
In Bezug auf das SIL-Aufbaufeld 706 kann sich das Datenabrufmodul 244 auf die Subelemente eines vorbestimmten Elements in der Dateistruktur 300 beziehen. Lediglich beispielhaft kann sich das Datenabrufmodul 244, wenn das Entzipper-Modul 224 die Dateien an dem Element 314 der zweiten Ebene extrahiert, auf die Subelemente des Elements 314 der zweiten Ebene beziehen. Das Datenabrufmodul 244 kann den/die Namen eines vorbestimmten Typs von Subelement des vorbestimmten Elements in der Dateistruktur 300 abrufen. Lediglich beispielhaft kann das Datenabrufmodul 244 den/die Namen der XML-Datei(en) des vorbestimmten Elements in der Dateistruktur 300 abrufen.
Das Datenabrufmodul 244 kann das Aufklappmenü 740 des SIL-Aufbaufelds 706 auf der Grundlage der abgerufenen Daten füllen. Lediglich beispielhaft kann das Datenabrufmodul 244 das Aufklappmenü 740 mit dem/den Namen der XML-Datei(en) füllen. Wenn der Benutzer das Aufklappmenü 740 des SIL-Aufbaufelds 706 auswählt, zeigt das GUI-Modul 240 selektiv den/die Namen in dem Aufklappmenü 740 an. Der Benutzer kann einen Namen aus den Aufklappmenü 740 auswählen. Der Name entspricht einem virtuellen Modell, das der Benutzer konfigurieren, in eine Simulation mit einem oder mehreren anderen virtuellen Modellen einbeziehen und/oder beim Durchführen einer anderen geeigneten Operation verwenden kann.
Sobald der Benutzer den Namen (d. h. das virtuelle Modell) ausgewählt hat, ruft das Datenabrufmodul 244 Daten bezüglich Funktionen ab, die mit dem ausgewählten virtuellen Modell in Verbindung stehen. Die Funktionen, die mit dem ausgewählten virtuellen Modell in Verbindung stehen, können beispielsweise in der XML-Datei definiert sein. Das Datenabrufmodul 244 kann das Aufklappmenü 744 des Funktionsfelds 710 mit dem Namen der in Verbindung stehenden Funktionen füllen. Die in Verbindung stehenden Funktionen können beispielsweise eine oder mehrere Funktionen, die durch das ausgewählte virtuelle Modell aufgerufen werden können, eine Null-Funktion oder eine Systemfunktion umfassen. Die Funktion(en), die durch das ausgewählte virtuelle Modell aufgerufen werden kann/können, kann/können beispielsweise in der XML-Datei definiert sein.
Wenn die Null-Funktion oder eine der Funktionen, die durch das ausgewählte virtuelle Modell aufgerufen werden können, ausgewählt wurde, kann der Benutzer selektiv Eingänge und Ausgänge über das Variablenfeld 714 konfigurieren. Die Null-Funktion kann beispielsweise ausgewählt werden, wenn das ausgewählte virtuelle Modell eine oder mehrere verfügbare Variablen verwenden soll, ohne eine in Verbindung stehende Funktion aufzurufen.
Das Datenabrufmodul 244 ruft Variablen, die mit dem ausgewählten virtuellen Modell in Verbindung stehen, und Variablen ab, die mit der Modelldatei 176 zur Verfügung stehen. Die Variablen, die mit dem ausgewählten virtuellen Modell in Verbindung stehen, können beispielsweise in der XML-Datei definiert sein. Das Datenabrufmodul 244 kann das Aufklappmenü 748 des variablen Felds 714 mit den in Verbindung stehenden Variablen füllen.
Wenn der Benutzer das Variablenfeld 714 auswählt, zeigt das Datenabrufmodul 244 selektiv die Namen der Variablen in dem Aufklappmenü 748 an. Der Benutzer kann eine der Variablen aus dem Aufklappmenü 748 auswählen. Sobald eine der Variablen aus dem Aufklappmenü 748 ausgewählt wurde, kann der Benutzer die ausgewählte Variable als Eingang oder als Ausgang hinzufügen. Der Benutzer kann die ausgewählte Variable als Eingang hinzufügen, indem er eine Eingangsoption 752 des Variablenfelds 714 auswählt. Der Benutzer kann die ausgewählte Variable als Ausgang hinzufügen, indem er eine Ausgangsoption 756 des Variablenfelds 714 auswählt. Der Benutzer kann einen oder mehrere andere Eingänge und/oder Ausgänge hinzufügen.
Wenn eine verfügbare Variable als Eingang hinzugefügt wird, fügt das Datenabrufmodul 244 die ausgewählte Variable zu dem Eingangsfeld 718 hinzu. Genauer gesagt fügt das Datenabrufmodul 244 die ausgewählte Variable zu einer Eingangsliste 760 des Eingangsfelds 718 hinzu. Das Datenabrufmodul 244 kann Einheitsdaten für den hinzugefügten Eingang und Dimensionsdaten für den hinzugefügten Eingang abrufen. Das Datenabrufmodul 244 fügt die Einheitsdaten und die Dimensionsdaten zu einer Einheitsliste 764 bzw. einer Dimensionsliste 768 des Eingangsfelds 718 hinzu.
Wenn eine ausgewählte Variable als Ausgang hinzugefügt wird, fügt das Datenabrufmodul 244 die ausgewählte Variable zu dem Ausgangsfeld 722 hinzu. Genauer gesagt fügt das Datenabrufmodul 244 die ausgewählte Variable zu einer Ausgangsliste 772 des Ausgangsfelds 722 hinzu. Das Datenabrufmodul 244 kann Einheitsdaten für den hinzugefügten Ausgang und Dimensionsdaten für den hinzugefügten Ausgang abrufen. Das Datenabrufmodul 244 fügt die Einheitsdaten und die Dimensionsdaten zu einer Einheitsliste 776 bzw. einer Dimensionsliste 780 des Ausgangsfelds 722 hinzu.
Wenn eine der Funktionen, die durch das ausgewählte virtuelle Modell aufgerufen werden können, über das Funktionsfeld 710 (d. h. nicht die Null-Funktion oder die Systemfunktion) ausgewählt wurde, ruft das Datenabrufmodul 244 Eingänge und/oder Ausgänge ab, die vorab mit dieser Funktion in Verbindung gebracht wurden. Die vorab in Verbindung gebrachten Eingänge und/oder Ausgänge können beispielsweise in der XML-Datei definiert sein. Das Datenabrufmodul 244 füllt das/die Liste von Eingangsfeld 718 und Ausgangsfeld 722 auf der Grundlage der vorab in Verbindung gebrachten Eingänge bzw. Ausgänge.
Der Benutzer kann einen hinzugefügten Eingang von dem Eingangsfeld 718 über eine Eingangslöschoption 784 des Eingangsfelds 718 löschen. Der Benutzer kann einen hinzugefügten Ausgang über eine Ausgangslöschoption 788 des Ausgangsfelds 722 löschen. Unter einigen Umständen können jedoch vorab in Verbindung gebrachte Eingänge und Ausgänge für ein Löschen nicht verfügbar sein. Der Benutzer kann die Konfiguration der zweiten SIL-GUI 702 (und der ersten SIL-GUI 602) über eine Speicheroption 792 speichern. Der Benutzer kann nicht gespeicherte Konfigurationen über eine Aufhebungsoption 796 verwerfen.
Nun auf 8 Bezug nehmend ist ein weiteres beispielhaftes Diagramm der ersten SIL-GUI 602 dargestellt. Das Modellaktualisierungsmodul 252 aktualisiert das virtuelle Modell 802, das über die erste SIL-GUI 602 angezeigt wird, auf der Grundlage der Konfiguration der zweiten SIL-GUI 702. Das Modellaktualisierungsmodul 252 aktualisiert einen Namensabschnitt 806 des SIL-Moduls 606 auf der Grundlage der Funktion, die in dem Aufklappmenü 744 des Funktionsfelds 710 ausgewählt wird.
Das Modellaktualisierungsmodul 252 erzeugt einen Eingangsindikator 814 für jeden Eingang des Eingangsfelds 718 (z. B. einen daraufzeigenden Pfeil) und zeigt diesen an. Das Modellaktualisierungsmodul 252 erzeugt einen Ausgangsindikator 818 für jeden Ausgang des Ausgangsfelds 722 (z. B. einen davon weg zeigenden Pfeil) und zeigt diesen an. Das Modellaktualisierungsmodul 252 kann für den Eingangs- und den Ausgangsindikator den Variablennamen und die Einheiten anzeigen. Das Modellaktualisierungsmodul 252 kann auch die Dimensionen und/oder andere geeignete Daten anzeigen. Beispiele dafür, wie das Modellaktualisierungsmodul 252 den Namen und die Einheiten für einen Eingangsindikator und einen Ausgangsindikator anzeigen kann, sind bei 822 bzw. 826 gezeigt.
Das Modellaktualisierungsmodul 252 kann das virtuelle Modell, das über die erste SIL-GUI 602 angezeigt wird, auf der Grundlage der Konfiguration der zweiten SIL-GUI 702 aktualisieren, wenn der Benutzer die Speicheroption 792 wählt. Bei verschiedenen Realisierungen kann das Modellaktualisierungsmodul 252 die erste SIL-GUI 602 jedes Mal aktualisieren, wenn eines der Felder der zweiten SIL-GUI 702 geändert wird, oder mit einer anderen geeigneten Häufigkeit.
9 umfasst ein weiteres beispielhaftes Diagramm der zweiten SIL-GUI 702. Das Eingangsfeld 718 kann auch eine Eingangs-UP-Option 902 und eine Eingangs-DOWN-Option 906 umfassen. Die Eingangs-UP-Option 902 oder die Eingangs-DOWN-Option 906 können für eine Bewegung an die Stelle, an der ein ausgewählter Eingang angezeigt wird, in Bezug auf die nicht ausgewählten Eingänge in der ersten SIL-GUI 602, verwendet werden. Lediglich beispielhaft kann das Modellaktualisierungsmodul 252, wenn ein Benutzer einen der Eingänge in der Eingangsliste 760 (oder die Einheiten oder Dimensionen, die mit einem der Eingänge in Verbindung stehen), ausgewählt hat, den ausgewählten Eingang um eine Stelle nach oben oder unten in der ersten SIL-GUI 602 zu bewegen, und zwar jedes Mal, wenn der Benutzer die Eingangs-UP-Option 902 bzw. die Eingangs-DOWN-Option 906 auswählt. Dies ist in 10 durch die beispielhaften Sätze 1002 und 1006 der gestrichelten Pfeile gezeigt.
Nun auf 11 Bezug nehmend wird ein weiteres beispielhaftes Diagramm der zweiten SIL-GUI 702 dargestellt. Wenn der Benutzer die Systemfunktion aus dem Aufklappmenü 744 des Funktionsfelds 710 auswählt, aktiviert das GUI-Modul 240 eine Planungsoption 1102. Genauer gesagt stellt das GUI-Modul 240 die Planungsoption 1102 für eine Auswahl durch den Benutzer zur Verfügung, wenn der Benutzer die Systemfunktion aus dem Funktionsfeld 710 auswählt. Wenn der Benutzer die Planungsoption 1102 auswählt, öffnet das GUI-Modul 240 eine dritte SIL-GUI.
Nun auf 12 Bezug nehmend wird ein Diagramm einer beispielhaften dritten SIL-GUI 1202 dargestellt. Der Benutzer kann beispielsweise eine Ausführung und/oder Planung eines oder mehrerer Tasks über die Planungsoption 1102 konfigurieren. Die Tasks können in einer Simulation des ausgewählten virtuellen Modells mit der Modelldatei 176 durchgeführt werden. Lediglich beispielhaft können die Tasks Algorithmus-Tasks, Funktionen, Betriebssystem-Tasks, Ereignis-Tasks und andere geeignete Typen von Tasks umfassen.
Die Betriebssystem-Tasks und die Ereignis-Tasks können in einem ersten Sichtausschnitt 1206 der dritten SIL-GUI 1202 angezeigt werden, die Algorithmus-Tasks können in einem zweiten Sichtausschnitt 1210 der dritten SIL-GUI 1202 angezeigt werden, und die Funktionen können in einem dritten Sichtausschnitt 1214 der dritten SIL-GUI 1202 angezeigt werden. Genauer gesagt können die Betriebssystem-Task-Liste 1220 und eine Ereignis-Task-Liste 1224 in dem ersten Sichtausschnitt 1206 angezeigt werden. Eine Algorithmus-Task-Liste 1228 kann in dem zweiten Sichtausschnitt 1210 angezeigt werden, und eine Funktions-Task-Liste 1232 kann in dem dritten Sichtausschnitt 1214 angezeigt werden.
Jede der Listen kann N Tasks umfassen, wobei N eine ganze Zahl ist, die größer als Null ist. Das Datenabrufmodul 244 kann die Betriebssystem-Tasks abrufen, wenn die Planungsoption 1102 ausgewählt wird. Das Datenabrufmodul 244 kann auch die Algorithmus-Tasks und die Funktionen abrufen, wenn die Planungsoption 1102 ausgewählt wird. Lediglich beispielhaft können die Betriebssystem-Tasks, die Algorithmus-Tasks und die Funktionen in der XML-Datei definiert werden.
Das Datenabrufmodul 244 füllt die Listen und zeigt jede der Listen mit den jeweiligen abgerufenen Tasks an. Betriebssystem-Tasks können als Steuersystemsoftware-Tasks bezeichnet werden. Ein Betriebssystem-Task kann sich auf einen Task beziehen, der in der Simulationsumgebung durchgeführt wird. Algorithmus-Tasks können als Komponentenmodell-Tasks bezeichnet werden. Funktionen können als Komponentensoftware-Tasks bezeichnet wurden. Das GUI-Modul 240 kann jeden der abgerufenen Betriebssystem-Tasks mit einem ersten Typ von Symbol oder Indikator (nicht gezeigt), wie beispielsweise einem Häkchen, anzeigen. Ein Beispiel des ersten Typs von Symbol oder Indikator ist bei 1252 gezeigt.
Jeder der Betriebssystem-Tasks kann einen oder mehrere Sub-Tasks umfassen, wie beispielsweise einen oder mehrere der Algorithmus-Tasks und/oder eine oder mehrere der Funktionen. Lediglich beispielhaft kann der beispielhafte Betriebssystem-Task 1240 eine Funktion 1244 und einen Algorithmus-Task 1248 umfassen. Der Benutzer kann einen Algorithmus-Task zur Durchführung mit einem ausgewählten Betriebssystem-Task über die dritte SIL-GUI 1202 planen (d. h. hinzufügen). Der Benutzer kann zusätzlich oder alternativ eine Funktion zur Durchführung mit einem ausgewählten Betriebssystem-Task über die dritte SIL-GUI 1202 planen (d. h. hinzufügen). Lediglich beispielhaft kann der Benutzer einen Algorithmus-Task oder eine Funktion zur Durchführung mit einem der Betriebssystem-Tasks durch Auswählen des Algorithmus-Tasks oder der Funktion aus der jeweiligen Liste und Ziehen des ausgewählten Algorithmus-Tasks oder der ausgewählten Funktion zu dem einen der Betriebssystem-Tasks in dem ersten Sichtausschnitt 1206 planen.
Das GUI-Modul 240 kann jeden hinzugefügten Algorithmus-Task mit einem zweiten Typ von Symbol oder Indikator (nicht gezeigt), wie beispielsweise einem A, anzeigen. Ein Beispiel des zweiten Typs von Symbol oder Indikator ist bei 1256 gezeigt. Das GUI-Modul 240 kann jede hinzugefügte Funktion mit einem dritten Typ von Symbol oder Indikator (nicht gezeigt), wie beispielsweise einem F, anzeigen. Ein Beispiel des dritten Typs von Symbol oder Indikator ist bei 1260 gezeigt.
Das GUI-Modul 240 kann für jeden Algorithmus in der Algorithmus-Task-Liste 1228 einen Zählwert anzeigen. Es wird auch ein Zählwert für jede der Funktionen in der Funktions-Task-Liste 1232 angezeigt. Lediglich beispielhaft sind die Zählwerte für den Algorithmus-Task 1248 und die Funktion 1244 als # gezeigt. Der Zählwert eines gegebenen Algorithmus-Tasks oder einer gegebenen Funktion stellt die Häufigkeit dar, wie oft der gegebene Algorithmus-Task oder die gegebene Funktion in der Betriebssystem-Task-Liste 1220 erscheint. Die Zählwerte sind ganze Zahlen, die größer oder gleich Null sind.
Der Benutzer kann die Konfiguration der dritten SIL-GUI 1202 durch Auswählen einer Speichern- und Fortfahren-Option 1270 speichern. Wenn der Benutzer die Speichern- und Fortfahren-Option 1270 auswählt, kann das GUI-Modul 240 die zweite SIL-GUI 702 anzeigen. Das GUI-Modul 240 kann auch die dritte SIL-GUI 1202 schließen.
Nun auf 13 Bezug nehmend ist ein weiteres beispielhaftes Diagramm der dritten SIL-GUI 1202 dargestellt. Der Benutzer kann einen in der Betriebssystem-Task-Liste 1220 geplanten Task über die dritte SIL-GUI 1202 sperren oder freigeben. Lediglich beispielhaft kann der Benutzer einen geplanten Task sperren, indem zuerst der geplante Task ausgewählt wird (z. B. Rechtsklick). Wenn der geplante Task ausgewählt wurde, kann das GUI-Modul 240 ein Aufklappmenü anzeigen, aus dem der Benutzer ein Sperren oder Freigeben auswählen kann. Wenn ein geplanter Task gesperrt wurde, wird der Task nicht während der normalen Durchführung der Betriebssystem-Task-Liste 1220 durchgeführt. Das GUI-Modul 240 kann jeden gesperrten Algorithmus-Task mit einem vierten Typ von Symbol oder Indikator (nicht gezeigt), wie beispielsweise einem X, anzeigen. Ein Beispiel für den zweiten Typ von Symbol oder Indikator ist bei 1302 gezeigt. Gesperrte Tasks bleiben in der Betriebssystem-Task-Liste 1220, werden jedoch während der Durchführung der Betriebssystem-Tasks nicht durchgeführt.
Der Benutzer kann auch einen hinzugefügten Task aus der Betriebssystem-Task-Liste 1220 über die dritte SIL-GUI 1202 löschen. Lediglich beispielhaft kann der Benutzer einen hinzugefügten Task löschen, indem er zuerst den hinzugefügten Task auswählt (z. B. Rechtsklick). Wenn der geplante Task ausgewählt wurde, kann das GUI-Modul 240 das Aufklappmenü anzeigen, aus dem der Benutzer ein Sperren, Freigeben oder Löschen auswählen kann. Wenn der Benutzer ein Löschen aus dem Auf klappmenü auswählt, kann der hinzugefügte Task von der Betriebssystem-Task-Liste 1220 entfernt werden.
Nun auf 14 Bezug nehmend ist ein weiteres beispielhaftes Diagramm der dritten SIL-GUI 1202 dargestellt. Der Benutzer kann auch ein weiteres Mal einen geplanten Task über die dritte SIL-GUI 1202 erneut planen. Lediglich beispielhaft kann der Benutzer, wenn die Funktion 1244 in der Betriebssystem-Task-Liste 1220 geplant ist, die Funktion 1244 aus der Funktions-Task-Liste 1232 auswählen. Der Benutzer kann die ausgewählte Funktion 1244 aus dem dritten Sichtausschnitt 1214 in den ersten Sichtausschnitt 1206 und insbesondere zu einem der geplanten Tasks ziehen. Wenn der Benutzer die Auswahl der Funktion 1244 beendet, setzt das GUI-Modul 240 die Funktion 1244 oberhalb oder unterhalb des einen der geplanten Tasks ein, um die Funktion 1244 erneut zu planen. Das GUI-Modul 240 kann die Funktion 1244 (dargestellt bei 1402) auch sperren und die Funktion 1244 als gesperrt markieren, wenn der Benutzer die Funktion 1244 innerhalb der Betriebssystem-Task-Liste 1220 erneut plant.
Der Benutzer kann über die dritte SIL-GUI 1202 auch einen geplanten Task zugunsten eines anderen Tasks umgehen. Lediglich beispielhaft kann der Benutzer, wenn die Funktion 1244 in der Betriebssystem-Task-Liste 1220 geplant ist, die Funktion 1244 für eine Umgehung auswählen. Der Benutzer kann die Funktion 1244 zum Umgehen auswählen, beispielsweise durch Rechtsklicken der Funktion 1244 und Auswählen einer ”Umgehungs”-Option. Dann kann der Benutzer eine weitere Funktion aus der Funktions-Task-Liste 1232 auswählen, um sie anstatt der Funktion 1244 durchzuführen, wenn die Funktion 1244 durchgeführt werden soll. Auf diese Weise kann die Funktion 1244 umgangen werden.
Nun wieder auf 2 Bezug nehmend erzeugt das Konfigurationsmodul 248 einen modellbasierten Code (z. B. den Code in der Modellsourcecodedatei 164) auf der Grundlage der Konfiguration der zweiten und dritten SIL-GUI 702 und 1202 und der XML-Datei 122. Das Modellaktualisierungsmodul 252 erzeugt ein Modell in der Modellerstellungs-/Simulationsumgebung auf der Grundlage des modellbasierten Codes und der Sourcecode-DLL-Datei 130. Das Modellaktualisierungsmodul 252 kann das Modell ferner auf der Grundlage der Datei 134 einer statischen Bibliothek erzeugen.
Das Simulationsmodul 256 simuliert den Betrieb des erzeugten Modells mit beispielsweise der Modelldatei 176 (d. h. einem Modell einer Anlage des Fahrzeugs), einem oder mehreren anderen Modulen etc. Das Simulationsmodul 256 kann den modellbasierten Code auch debuggen. Das GUI-Modul 240 kann die Simulation in einer oder mehreren GUIs (nicht gezeigt) anzeigen. Der Benutzer kann die zweite und/oder dritte SIL-GUI 702 und 1202 verwenden, um das Modell auf der Grundlage des Ergebnisses der Simulation erneut zu konfigurieren und erneut zu erzeugen. Während es anders gezeigt und dargestellt ist, kann oder können eines oder mehrere der Module von 1B und 2 in einem oder mehreren der Module von 1A realisiert sein.
Nun auf 15 Bezug nehmend ist ein Flussdiagramm dargestellt, das ein beispielhaftes Verfahren 1500 zum Durchführen einer Fahrzeugsystemsimulation zeigt. Die Steuerung kann mit 1502 beginnen, wobei die Steuerung den Objektcode auf der Grundlage des Sourcecodes erzeugt. Die Steuerung kann die Definitionsdatei und die XML-Datei bei 1506 erzeugen. Die Steuerung kann die Definitionsdatei und die XML-Datei auf der Grundlage des Sourcecodes und des Objektcodes erzeugen.
Bei 1510 kann die Steuerung die DLL-Datei und die Datei einer statischen Bibliothek erzeugen. Die Steuerung kann die DLL-Datei und die Datei einer statischen Bibliothek auf der Grundlage des Objektcodes und der Definitionsdatei erzeugen. Bei 1514 kann die Steuerung den modellbasierten Sourcecode erzeugen. Die Steuerung kann den modellbasierten Sourcecode auf der Grundlage der XML-Datei erzeugen. Die Steuerung kann auch ein virtuelles Modell erzeugen und bei 1514 das virtuelle Modell in einer GUI anzeigen.
Bei 1518 kann die Steuerung selektiv eine oder mehrere GUIs für den Benutzer anzeigen und Benutzerkonfigurationen empfangen. Bei 1522 kann die Steuerung den modellbasierten Sourcecode und das virtuelle Modell auf der Grundlage der Benutzerkonfigurationen aktualisieren. Bei 1526 kann die Steuerung die ausführbare Datei auf der Grundlage des modellbasierten Sourcecodes erzeugen. Die ausführbare Datei kann in der Simulationsumgebung ausgeführt werden. Bei 1530 kann die Steuerung eine Simulation durchführen, die das virtuelle Modell umfasst. Dann kann die Steuerung enden.
Die breiten Lehren der Offenbarung können auf eine Vielzahl von Formen realisiert werden. Daher sollte, während diese Offenbarung bestimmte Beispiele umfasst, der wahre Schutzumfang der Offenbarung nicht so eingeschränkt sein, da andere Abwandlungen für den Fachmann beim Studieren der Zeichnungen, der Beschreibung und der folgenden Ansprüche ersichtlich werden.

Claims

Fahrzeugsimulationssystem, umfassend: ein Compiler-Modul, das Objektcode, der mit einem ersten Typ von Betriebssystem kompatibel ist, auf der Grundlage von Sourcecode erzeugt, der durch ein Fahrzeugsteuermodul ausgeführt werden kann und der mit einem zweiten Typ von Betriebssystem kompatibel ist; ein Parser-Modul, das eine Definitionsdatei und eine Extensible Markup Language-Datei (XML-Datei) auf der Grundlage des Sourcecodes und des Objektcodes erzeugt; ein Wrapper-Modul, das eine Bibliotheksdatei auf der Grundlage des Objektcodes und der Definitionsdatei erzeugt; ein Modellerstellungsmodul, das einen modellbasierten Sourcecode für ein virtuelles Modell auf der Grundlage der XML-Datei und einer Benutzerkonfiguration des virtuellen Modells erzeugt; und ein Simulationsmodul, das den Betrieb einer Anlage eines Fahrzeugs mit dem virtuellen Modell simuliert.
Fahrzeugsimulationssystem nach Anspruch 1, wobei das Modellerstellungsmodul umfasst: ein Modul einer grafischen Benutzerschnittstelle (GUI-Modul), das ein konfigurierbares Modul in einer ersten GUI anzeigt und das eine zweite GUI anzeigt, wenn das konfigurierbare Modul ausgewählt ist; ein Datenabrufmodul, das Daten für das virtuelle Modell aus der XML-Datei abruft und das selektiv Menüs der zweiten GUI auf der Grundlage der abgerufenen Daten füllt.
Fahrzeugsimulationssystem nach Anspruch 2, wobei das Modellerstellungsmodul ferner umfasst: ein Konfigurationsmodul, das den modellbasierten Sourcecode auf der Grundlage der XML-Datei und des Benutzerkonfigurationseingangs über die zweite GUI erzeugt; und ein Modellaktualisierungsmodul, das das konfigurierbare Modul, das in der ersten GUI angezeigt wird, auf der Grundlage des Benutzerkonfigurationseingangs über die zweite GUI aktualisiert.
Fahrzeugsimulationssystem nach Anspruch 2, wobei das Datenabrufmodul das virtuelle Modell für eine Auswahl über ein erstes der Menüs darstellt, wobei das Datenabrufmodul eine Funktion für einen Aufruf durch das virtuelle Modell für eine Auswahl über ein zweites der Menüs darstellt, und wobei das Datenabrufmodul eine Variable für eine Hinzufügung als einen Eingang in die oder einen Ausgang aus der Funktion über ein drittes der Menüs darstellt.
Fahrzeugsimulationssystem nach Anspruch 2, wobei das GUI-Modul eine dritte GUI anzeigt, wenn eine Task-Planungsoption der zweiten GUI ausgewählt wird.
Fahrzeugsimulationssystem nach Anspruch 5, wobei das Konfigurationsmodul den modellbasierten Sourcecode ferner auf der Grundlage eines Konfigurationseingangs über die dritte GUI erzeugt.
Fahrzeugsimulationssystem nach Anspruch 5, wobei das Datenabrufmodul eine Liste von Tasks auf der Grundlage der XML-Datei erzeugt.
Fahrzeugsimulationssystem nach Anspruch 7, wobei das Datenabrufmodul einen Algorithmus-Task und/oder eine Funktion für eine Hinzufügung zu der Liste von Tasks über die dritte GUI darstellt.
Fahrzeugsimulationssystem nach Anspruch 7, ferner umfassend ein Modul zur Erzeugung einer ausführbaren, das eine ausführbare Datei auf der Grundlage der Bibliotheksdatei und des modellbasierten Sourcecodes erzeugt, wobei das Ausführungsmodul den Betrieb der Anlage unter Verwendung der ausführbaren Datei, der Liste von Tasks und eines virtuellen Modells der Anlage simuliert.
Fahrzeugsimulationssystem nach Anspruch 1, wobei sich das erste und das zweite Betriebssystem unterscheiden.