Tab Modellzugriff¶
Das Simulationsmodell läuft als Simulationsumgebung des Steuergerätes auf Echtzeit-Hardware z. B. von dSPACE. Mit Hilfe des Tabs Modellzugriff kann ecu.test dieses Modell steuern. Dies geschieht mit Hilfe von Variablen, die als Auswahlbaum dargestellt sind.
Werden Variablen gemapped, die im Modell unter Model Root zu finden sind, erfolgt die Anpassung der
Pfade auf dSpace Multiprozessorsystemen automatisch.
Des Weiteren besteht die Möglichkeit, Modell-Testschritte einzufügen, ohne dabei eine bestimmte Modellvariable auswählen zu müssen. Dies ist im Kapitel Generisch nachzulesen.
Mit Hilfe eines Rechtsklicks auf eine Variable des Simulationsmodells öffnet sich ein Kontextmenü mit dem verschiedene Aktionen gestartet werden können.
- Lesen
Wird der Menüpunkt mit der linken Maustaste bestätigt, öffnet sich das Dialogfenster Modell Lesen.
Die Eingabemöglichkeiten sind unter dem Kapitel Lesen-/ Schreiben-/ Ausführen-/ Stimulus-Dialog zu finden.
- Schreiben
Nach dem Bestätigen des Menüpunktes mit der linken Maustaste, öffnet sich das Dialogfenster Modell schreiben. Der obere Teil ist analog den Feldern im Lesen-Dialog. Im unteren Teil kann anstelle der Bewertung einer Variablen des Simulationsmodells ein bestimmter Wert zugewiesen und somit das Modell gesteuert werden.
Es kann jedoch immer nur eine Variable zu einem Zeitpunkt verstellt werden. Ist es notwendig mehrere Variablen zu verstellen, so müssen mehrere Testschritte eingefügt werden.
- Globales Mapping erstellen
Bei der Wahl dieser Option im Kontextmenü wird der Variablenpfad des Simulationsmodells der globalen Mappingliste hinzugefügt. Ein Hinzufügen der Variablennamen ist auch per „Drag & Drop“ aus der Liste der Modellvariablen möglich. Die Bedeutung und Nutzung der Mappingnamen wird im Abschnitt Globales Mapping erklärt.
Handelt es sich bei der Simulationsumgebung um eine Fahrdynamik- oder Umfeldsimulationssoftware mit der Szenarien erstellt und simuliert werden, öffnet sich beim Rechtsklick auf einen Knoten ebenfalls ein Kontextmenü mit weiteren Aktionen.
- Ausführen
Diese Option öffnet den Dialog zur Ausführung eines Szenarios. Nach Auswahl des Ausführungsmodus und Bestätigen des Dialogs können dem eingefügten Testschritt Schreiben-Aktionen untergeordnet werden. Bei Testausführung werden durch diesen Testschritt das Szenario auf der Simulationsumgebung aktiviert, die Schreiben-Aktionen ausgeführt und die Simulation gestartet. Es muss darauf geachtet werden, dass die untergeordneten Schreiben-Aktionen nur Variablen verstellen, die auch im Modell dem Szenario untergeordnet sind.
- Schreiben
Die Wahl dieser Option öffnet das Dialogfenster Modell schreiben. Dieser verstellt jetzt jedoch keine Variable, sondern einen Knoten innerhalb eines Szenarios. Dies hat zur Folge, dass sich während der Testausführung der Teilbaum des Szenarios im Modell verändert. Aus diesem Grund muss beachtet werden, dass keine Variablen verstellt werden, die sich innerhalb dieses Teilbaums befinden. Die Veränderung des Modellbaums ist nur temporär zur Testausführung und wird nicht visualisiert.
Signale können zu Signalaufnahmen hinzugefügt und somit während der Testausführung aufgezeichnet werden.
Über das Attribut Raster kann bestimmt werden, in welchem Abstand das Tool das Signal aktualisiert. Wird die Einstellung „Port-Default“ gewählt, wird das Standardraster verwendet. Das Raster kann auch manuell eingegeben werden, wobei ‚*‘ und ‚?‘ als Wildcards verwendet werden. Unterstützt das Tool die Rasteränderung nicht, bleibt die Angabe unberücksichtigt.
Info
Mithilfe der Tastenkombination CTRL-F besteht die Möglichkeit, bestimmte Modellgrößen bzw. Variablen in der Baumansicht zu suchen und sichtbar zu machen.
Modell in Datei speichern¶
Mit Hilfe eines Rechtsklicks auf den Wurzelknoten des Simulationsmodells kann aus den aktuell eingelesenen Modellgrößen eine Offline-Modelldatei erstellt werden. Es öffnet sich ein Dialog, der es ermöglicht den Speicherort und den Namen der zu erstellenden Offline-Modelldatei anzugeben. Sollte das dynamische Nachladen der Modellgrößen aktiv sein, werden nur die Modellgrößen gespeichert, die bereits nachgeladen wurden. Die so erstellte Offline-Modelldatei kann im Tab Plattform zur Offline Testfallerstellung als Modelldatei angegeben werden.
Info
Um alle Subelemente eines Modellknotens auch beim dynamischen Nachladen zu erhalten, kann man per Rechtsklick auf einen Modellknoten „Alle Unterelemente laden“ auswählen. Diese Option ist vorallem für MATLAB Simulink Modelle hilfreich.
Modell aktualisieren¶
Mit Hilfe eines Rechtsklicks auf den Wurzelknoten des Simulationsmodells kann das aktuelle Modell aktualisiert werden. Das Modell wird dann erneut eingelesen. Der Kontextmenüeintrag ist nur verfügbar, wenn das unterliegende Tool die Onlineabfrage unterstützt.
Generieren von virtuellen Modellgrößen via Signal-Mappings¶
Für gewisse Anwendungsfälle ist es möglich, virtuelle Modellgrößen generieren zu lassen. Dabei werden bestimmte Größen, welche die Ein-/Ausgänge eines Modells repräsentieren, zusammengefasst und als neues Element dem Modellbaum hinzugefügt. Je nach Aktion, die auf dieser neuen virtuellen Größe ausgeführt wird, wird dann im Hintergrund ein anderes Signal gelesen bzw. geschrieben.
Die Nutzung dieser Funktionalität setzt eine spezielle Modellstruktur voraus:
Voraussetzung ist, dass eine „selector“ Variable existiert, über die es möglich ist, verschiedene Signale an ein zentrales „out“ Signal weiterzuleiten. Je nachdem, welcher Wert in „selector“ geschrieben wird, wird ein anderes Signal zu „out“ weitergeleitet. Ist „selector“ beispielsweise auf 1 gesetzt, so wird der Wert von „const“ an „out“ weitergegeben.
Die Abbildung der einzelnen Modellelemente (const, out, stimulation, selector) auf die neue virtuelle Größe wird über eine *.sms-Datei definiert. Diese Datei kann in der Testkonfiguration als Toolspezifische Zusatzdatei angegeben werden. Die Struktur einer *.sms-Datei soll an folgendem Beispiel dargestellt werden:
{
"signals": {
"out": {
"suffix": ".out"
},
"const": {
"suffix": ".const",
"selectorValue": 1
},
"stimulation": {
"suffix": ".stim",
"selectorValue": 2
},
"selector" : {
"suffix": ".switch"
}
},
"entryPath": "path/to/the/smsVariables/",
"formatVersion": 2
}
Die Zuordnung erfolgt über Suffixe im Namen der Elemente. Im obigen Beispiel werden alle
Modellgrößen, die mit „.out“, „.const“, „.stim“ oder „.switch“ enden, als potentielle Quellen für
eine virtuelle Größe erkannt. Der Name der neuen virtuellen Größe leitet sich ab aus dem Name der
Modellgröße ohne ihren Suffix. So würde im obigen Beispiel für die Größen „Exhaust.out“,
„Exhaust.const“, „Exhaust.stim“ und „Exhaust.switch“ automatisch eine neue Modellgröße namens
„Exhaust“ angelegt. Die Definition der Signale „const“ und „stimulation“ verlangt zusätzlich einen
Wert für den Parameter "selectorValue" (im obigen Beispiel "selectorValue": 1 bzw.
"selectorValue": 2). Dieser Parameter gibt an, auf welchen Wert das „selector“ Signal gesetzt
werden muss, damit jeweils der Wert von „const“ oder „stimulation“ an „out“ weitergeleitet wird.
Info
Suffixe dürfen auch Pfadseparatoren enthalten. Dies ermöglicht es, Signale aus
verschiedenen Unterverzeichnissen zu referenzieren. Zum Beispiel wäre /subdir/Out auch ein
valider Suffix.
Abhängig von der Aktion, die auf dem neuen Element „Exhaust“ ausgeführt wird, wird intern auf ein anderes Signal zugegriffen:
Lesen: Der Wert von „Exhaust.out“ wird gelesen.
Schreiben: Der angegebene Wert wird in „Exhaust.const“ geschrieben. Danach wird „Exhaust.switch“ so gesetzt, dass „Exhaust.out“ nun den Wert von „Exhaust.const“ liefert.
Stimulieren: Der Stimulus wird an „Exhaust.stim“ angelegt. Danach wird „Exhaust.switch“ so gesetzt, dass „Exhaust.out“ nun den Wert des Stimulus liefert.
Zurücksetzen: „Exhaust.const“ und „Exhaust.switch“ werden wieder auf ihren ursprünglichen Wert zurückgesetzt. Dadurch liefert „Exhaust.out“ wieder den eigentlichen Wert des Modells.
Über das Feld "entryPath" wird definiert, ab welchem Pfad das Mapping gelten soll. Nur Signale,
deren Pfad mit diesem String beginnt, werden vom Mapping berücksichtigt. Falls "entryPath"
nicht angegeben ist, wird das Mapping auf den gesamten Modellbaum angewendet.
Filter, Aliase und Strukturierung des Modells¶
Die Darstellung des Simulationsmodells kann mit Hilfe von Filtern und Aliasen angepasst werden. Filter ermöglichen es, Modellgrößen auszublenden, während Aliase die Möglichkeit bieten, Modellgrößen unter einem anderen Namen bzw. Pfad anzuzeigen. Letzteres ermöglicht damit auch die Umstrukturierung des Modells durch die Gruppierung von Modellgrößen unter einem gemeinsamen Pfad. Beide Funktionen können über Toolspezifische Zusatzdatei aktiviert werden, indem eine Python-Datei im Benutzer-Python-Bibliotheksverzeichnis erstellt wird, die die Filter- und Aliasdefinitionen enthält. Diese Python-Datei muss den MODULE_TYPE = ‚USER_MODEL_MODIFIER‘ definieren. Außerdem sollte sie mindestens eine der beiden optionalen Methoden GetVariableAlias und IgnoreVariable in einer wie unten beispielhaft dargestellten Klasse implementieren:
MODULE_TYPE = 'USER_MODEL_MODIFIER'
class ExampleUserModelModifier:
def GetVariableAlias(self, variablePath: str) -> str | None:
return 'myAlias' if variablePath == 'path/to/the/variable' else None
def IgnoreVariable(self, variablePath: str) -> bool:
return True if variablePath == 'path/to/the/variableToBeIgnored' else False
In diesem Beispiel wird die Variable mit dem Pfad „path/to/the/variable“ im Modellbaum unter dem Namen „myAlias“ angezeigt. Alle Aktionen, die auf „myAlias“ ausgeführt werden, wirken sich auf die Variable „path/to/the/variable“ aus. Die Variable mit dem Pfad „path/to/the/variableToBeIgnored“ wird hingegen komplett aus der Baumansicht ausgeblendet und kann somit auch nicht für Aktionen ausgewählt werden.
Info
Aliase wirken sich nur auf die Darstellung des Modells aus. Alle Aktionen, wie z.B. das Lesen oder Schreiben von Variablen, beziehen sich immer auf die tatsächlichen Variablen des Modells, unabhängig davon, ob sie aliasiert wurden. Filter hingegen beeinflussen sowohl die Darstellung als auch die Verfügbarkeit der Variablen. Ausgeblendete Variablen können nicht für Aktionen ausgewählt werden, und werden weder in der Offline-Modelldatei gespeichert noch im Cache berücksichtigt. Filter werden zuerst angewendet. Für Variablen, die durch Filter ausgeblendet werden, werden keine Aliase erstellt.
Bemerkung
Für SDF-Modelle wird IgnoreVariables() bereits auf Gruppennamen angewendet. Dadurch kann der Parser ganze Teilbäume des Modells überspringen, was die Ladezeiten von Modellen deutlich verkürzen kann.