Mathworks: MATLAB & Simulink¶
Bisheriger/interner Bezeichner: MATLAB/Simulink
Herstellerinformationen
Hersteller |
Webseite |
Produktname |
Version |
|---|---|---|---|
The Mathworks, Inc. |
MATLAB & Simulink |
Windows: R2015b (8.6) bis R2024b (24.2) Linux: R2020b (9.9) bis R2024b (24.2) |
Kategorien
MDL 🛈 |
APL 🛈 |
BAN 🛈 |
BMA 🛈 |
SVC 🛈 |
DGN 🛈 |
FIU 🛈 |
EES 🛈 |
FCT 🛈 |
DBG 🛈 |
IMG 🛈 |
AUDIO 🛈 |
ENVSIM 🛈 |
ENVCOM 🛈 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
✓ |
✓ |
Plattform
Betriebssystem |
Unterstützung |
|---|---|
Windows |
✓ |
Linux |
✓ |
Ports¶
Besonderheiten¶
MATLAB ist eine Software zur Lösung mathematischer Probleme, insbesondere zu numerischer Simulation, Datenerfassung, Datenanalyse und Datenauswertung.
Die Anbindung von ecu.test zu MATLAB und Simulink bietet umfangreiche Möglichkeiten um Simulink-Modelle zu testen. Überblick über die Features:
Lesen, Schreiben, Stimulieren und Aufzeichnen von Modellsignalen,
Lesen und Schreiben von Block-Parametern,
Samplegenaue Steuerung der Simulationszeit,
und vieles mehr.
Eine Playlist mit Einführungsvideos in die MATLAB-Anbindung ist im Youtube-Kanal der tracetronic GmbH verfügbar.
Allgemeine Hinweise¶
Voraussetzungen zur Verwendung von MATLAB mit ecu.test¶
Windows
ecu.test automatisiert MATLAB über dessen COM API. Voraussetzung dafür ist, dass der MATLAB-COM-Automatisierungs-Server korrekt in Windows registriert ist. Details dazu sind der MATLAB-Hilfe zu entnehmen: Register MATLAB as Automation Server
Beim Konfigurationsstart startet ecu.test standardmäßig eine neue Instanz von
MATLAB. Über die Einstellung MATLAB-Verbindungsart in den Tooleigenschaften
lässt sich jedoch auch festlegen, dass eine bereits laufende MATLAB-Instanz
verwendet wird. Voraussetzung ist, dass in der laufenden Instanz der Automation-Server
mittels enableservice('AutomationServer', true) bereits gestartet wurde.
Linux
Damit ecu.test unter Linux auf MATLAB zugreifen kann, müssen folgende Voraussetzungen erfüllt sein:
ecu.test ist unter Linux installiert. Siehe ecu.test auf Linuxsystemen.
Aktivierter X-Server und korrekt gesetzte
DISPLAY-Umgebungsvariable. Siehe dazu auch Start MATLAB on Linux Platforms. Die Umgebungsvariable kann mitecho $DISPLAYabgefragt werden. Diese muss mitexport DISPLAY=wertvor dem Start von ecu.test bzw. Tool Server gesetzt werden, falls diese nicht bereits initialisiert ist.wertist dabei häufig:0oder:0.0.
Weitere Informationen zur Verwendung von ecu.test unter Linux:
Des Weiteren gelten folgende Einschränkungen in den Tooleigenschaften der Testbenchkonfiguration:
Unter Linux muss der Pfad zum Installationsverzeichnis direkt in der Testbenchkonfiguration angegeben werden. Es kann kein explizites MATLAB-Release aus der Liste der Releases ausgewählt und auch kein Release automatisch ermittelt werden.
Unter Linux ist es nicht möglich sich mit einer bereits gestarteten MATLAB-Instanz zu verbinden. Als MATLAB-Verbindungsart sind somit lediglich Auto oder New verwendbar. Siehe dazu auch Attach to Existing MATLAB Sessions.
Vorsicht
Aufgrund von Performanceproblemen bei der Verwendung der MATLAB C++ Engine API können die Simulationsmodi „Echtzeit“ und „kontinuierlich“ unter Linux nicht verwendet werden. Sollten diese Modi benötigt werden oder weitere Fragen bestehen, kontaktieren Sie bitte support@tracetronic.com.
Es werden alle MATLAB-Versionen unterstützt, die mit der unter Systemanforderungen angegebenen Linux-Version kompatibel sind. Details dazu sind der MATLAB-Hilfe zu entnehmen: System Requirements
Log-Dateien¶
Um die Fehlersuche zu erleichtern, wird von der Anbindung an MATLAB eine eigene Log-Datei
geschrieben. Diese Log-Datei wird am Ende der Testfallausführung in das jeweilige Reportverzeichnis
kopiert. Außerdem wird eine Kopie im Log-Verzeichnis von ecu.test im
Unterordner MATLAB abgelegt.
Bei Supportanfragen sollten diese Log-Dateien berücksichtigt werden.
Caching der Modellstruktur¶
ecu.test speichert Informationen über die Modellstruktur des verwendeten Modells und für jedes darin referenzierte Modell in separaten Cache-Dateien.
Info
Zur initialen Erstellung der Caches, oder wenn das Modell oder ein darin referenziertes Modell geändert wurden, muss das Modell beim Konfigurationsstart einmalig kompiliert werden, um die Modellstruktur zu bestimmen. Der Kompiliervorgang kann, je nach Komplexität der Modelle, eine gewisse Zeit in Anspruch nehmen.
Bei jedem weiteren Konfigurationsstart wird die Modellstruktur aus dem Cache entnommen und es kann auf das Kompilieren verzichtet werden.
Wurde die Konfiguration gestartet und im Modellzugriffsreiter ein Knoten ausgeklappt, welcher noch nicht im Cache enthalten ist, dann wird das Modell kompiliert, sofern es sich nicht bereits im kompilierten Zustand befindet und der Cache wird um die Informationen der ausgeklappten Modellstrukturebene erweitert.
Info
Um komplette Teilbäume des Modells zu laden und damit in den Cache aufzunehmen, kann die Option Alle Unterelemente laden im Kontextmenü eines Knotens im Modellzugriffsreiter verwendet werden.
Die Cache-Dateien liegen im .ecutest/<Modellname>-Ordner neben dem Modell ab.
Caches die länger als 30 Tage nicht mehr genutzt wurden, werden nach dem Konfigurationsstart
automatisch gelöscht.
Das Caching der Modellstruktur ist standardmäßig aktiviert. Sollten Inkonsistenzen mit dem Cache
auftreten, können die entsprechenden Cache-Dateien im .ecutest-Ordner gelöscht werden. Das
Caching der Modellstruktur kann in der Testbenchkonfiguration auch gänzlich deaktiviert werden.
Hinweise zur Testbenchkonfiguration¶
Allgemeine Hinweise zur Erstellung einer neuen Testbenchkonfiguration siehe Was ist eine Testbenchkonfiguration?.
Hinweise zur Testkonfiguration¶
Allgemeine Hinweise zur Erstellung einer neuen Testkonfiguration siehe Was ist eine Testkonfiguration?.
Auswahl des Testmodells¶
Auf dem Tab Plattform kann die zu verwendende Modell-, Initialisierungs- oder Simulink-Project-Datei ausgewählt werden.
Info
Auf dem Tab Ausführung kann eingestellt werden, ob das Modell in „Echtzeit“, „kontinuierlich“ oder „schrittweise“ ausgeführt werden soll. Einzelheiten zu den verschiedenen Ausführungsmodi werden im Abschnitt Steuerung der Simulationszeit erläutert.
Wie bereits erwähnt, können auch m-files im Tab Plattform angegeben werden. Dadurch ist es möglich, nutzerspezifische Initialisierungen vorzunehmen, um das Modell in einem simulationsfähigen Zustand bereitzustellen. ecu.test erwartet nach dem Öffnen bzw. Ausführen der in Tab Plattform angegebenen Datei ein geöffnetes, initialisiertes und simulationsfähiges Simulink-Modell.
Example
Der folgende Code verdeutlicht die Verwendung eines Init-Skriptes.
load('initData.mat');
myModelVariable = 1;
open_system('sldemo_autotrans');
Anstatt das Gesamtmodell zu verwenden, kann alternativ auch ein Subsystem aus dem Gesamtkontext herausgeschnitten werden. Hierfür kann die mit ecu.test bereitgestellte Hilfsfunktion verwendet werden.
sut = ecuTest.OpenModel('sldemo_absbrake', 'Wheel Speed')
Eine detaillierte Dokumentation hierzu ist in MATLAB über folgenden Befehl verfügbar:
doc ecuTest.OpenModel
Ausblenden nicht relevanter Modellstrukturen¶
Beim Starten der Konfiguration wird in ecu.test die Modellstruktur im Tab Modellzugriff dargestellt. Bei sehr umfangreichen Modellen ist die hierbei darzustellende Menge an Modellpfaden entsprechend groß und kann zu einer erhöhten Wartezeit führen. Wenn nur einige der Modellpfade für die Tests relevant sind, können diese Modellstrukturen beim Laden des Modells explizit angegeben werden. Dies bewirkt, dass die Konfiguration schneller lädt. Außerdem werden nur die zuvor angegebenen Elemente einschließlich Substrukturen im Tab Modellzugriff von ecu.test dargestellt. Diese Funktion hat keinerlei Einfluss auf das Modellverhalten, sondern beeinflusst lediglich die Darstellung des Modellbaums.
ecuTest.Settings.ModelTree.Include(<subsystem path>)
Example
Die Funktion kann im Initialisierungsscript wie folgt verwendet werden:
modelName = 'sldemo_auto_climatecontrol';
open_system(modelName);
ecuTest.Settings.ModelTree.Include('Heater Control');
ecuTest.Settings.ModelTree.Include('AC Control');
Umgang mit speziellen Modellbestandteilen¶
Model Reference¶
Simulink-Modelle können andere Modelle als Model Reference beinhalten. Mit ecu.test ist es möglich in diesen referenzierten Modellen auf Signale und Parameter zuzugreifen. Jedoch gilt folgende Einschränkung:
Zugriff ist nur auf einmalig referenzierte Modelle möglich (Wird ein und dasselbe referenzierte Modell an mehreren Stellen im Modell verwendet, ist auf all diese Modellreferenzen kein Zugriff möglich)
Model Reference im Accelerator Mode¶
Simulink-Modelle können Model References im Accelerator Mode enthalten, Accelerated Models genannt. Im Accelerator Mode sind die Modellmethoden von der Simulink-Software getrennt. Mit ecu.test ist es möglich, auf Eingangs- und Ausgangssignale sowie auf Mask Parameters des Accelerated Models zuzugreifen. Interne Signale und Parameter lassen nur begrenzte Interaktionen zu.
Es gelten folgende Einschränkungen für interne Signale und Parameter von Accelerated Models:
Alle Einschränkungen, die auch für Model References gelten.
Bis MATLAB R2020a gilt:
Lesen/Schreiben/Stimulieren/Aufzeichnen interner Parameter und Signale ist nicht möglich.
Ab MATLAB R2020b gilt:
Das Lesen interner Signale sowie das Lesen/Schreiben interner Parameter sind möglich, solange die Simulation gestoppt ist.
Stimulation interner Signale ist nicht möglich.
Aufzeichnung interner Signale ist möglich.
Protected Model¶
Simulink-Modelle können Protected Models als referenzierte Modelle enthalten. Mit ecu.test ist es möglich, auf Eingangs- und Ausgangssignale sowie auf Mask Parameters des Protected Models zuzugreifen. Jedoch gelten folgende Einschränkungen:
Es gelten alle Einschränkungen, die auch für Model References gelten
Zusätzlich muss bei der Erstellung des Protected Models sichergestellt sein, dass folgende Modellparameter wie angegeben gesetzt sind. Der Wert der Modellparameter ist für die Simulation mit ecu.test erforderlich, kann aber von ecu.test innerhalb von Protected Models nicht geändert werden, weil diese schreibgeschützt sind.
set_param('<MODELNAME>', 'SignalLogging', 'on')
set_param('<MODELNAME>', 'OptimizeBlockIOStorage', 'off')
set_param('<MODELNAME>', 'SaveFormat', 'StructureWithTime')
set_param('<MODELNAME>', 'StopTime', 'inf')
set_param('<MODELNAME>', 'SignalLoggingSaveFormat', 'Dataset')
Configuration Reference¶
Die Verwendung von Modellen mit Configuration Reference wird von ecu.test nativ unterstützt. Notwendige Änderungen an der Modell-Konfiguration werden auch bei referenzierten Konfigurationen vorgenommen.
Info
Der Anwender muss nicht mehr mit Hilfe eines Modell-Init-Skript die referenzierte Konfiguration in eine normale Modell-Konfiguration umwandeln, da ecu.test dies bereits übernimmt.
Steuerung der Simulationszeit¶
Siehe auch: Zeitverhalten: Echtzeit- und Simulationszeit-Modi.
Folgende Hinweise sollten dabei beachtet werden.
Schrittweise Ausführung in Simulationszeit¶
In diesem Modus übernimmt ecu.test die Zeitsteuerung des Modells. Er sollte bevorzugt verwendet werden, weil dabei die breitestmögliche Unterstützung von Features dieser Tool-Anbindung existiert.
Info
Um im Modell Zeit vergehen zu lassen wird im Testfall der Wait-Testschritt verwendet.
Die Wait-Zeit sollte ein Vielfaches der Modell-Schrittweite (bei Fixed-Step-Solvern) bzw. der minimalen Schrittweite (bei Variable-Step-Solvern) betragen.
Echtzeit-Modus¶
Dieser Modus wird verwendet, wenn das Modell in Realzeit simuliert wird und ohne dass es zwischendurch pausiert werden sollte, beispielsweise in einer Co-Simulation mit einem weiteren Tool.
Info
Falls das Modell zum Package-Start bereits im gestarteten Zustand ist, dann ist die Verwendung von Signal-Schreiben und -Stimulation nicht möglich, da diese eine Instrumentierung des Modells voraussetzen.
Wird Simulink im External-Mode verwendet, dann ist dies in der Regel nur im Echtzeit-Modus möglich.
Vorsicht
Aufgrund von Performanceproblemen kann der Echtzeit-Modus unter Linux nicht verwendet werden. Sollte dieser Modus benötigt werden oder weitere Fragen bestehen, kontaktieren Sie bitte support@tracetronic.com.
Kontinuierliche Ausführung in Simulationszeit¶
Bei diesem Modus streamt das Modell die aktuelle Simulationszeit zu ecu.test. Es gelten die selben Einschränkungen wie auch beim Echtzeit-Modus.
Vorsicht
Aufgrund von Performanceproblemen kann der kontinuierliche Simulationsmodus unter Linux nicht verwendet werden. Sollte dieser Modus benötigt werden oder weitere Fragen bestehen, kontaktieren Sie bitte support@tracetronic.com.
Hinweise zur Verwendung von Modellgrößen¶
Prinzipiell werden folgende Arten von Modellgrößen unterschieden:
- Signale
Datenfluss zwischen Simulink-Blöcken, repräsentiert durch Verbindungslinien im Modell
- Parameter
Parametrierung von Simulink-Blöcken (z.B. bei Constant- oder Gain-Blöcken)
- States
Zustandsgrößen bestimmter Blocktypen (z.B. Integratoren, Delays, S-Functions etc.)
Im Tab Modellzugriff können die verfügbaren Modellgrößen ausgewählt werden. Je nach Art der Modellgröße stehen unterschiedliche Aktionen (Lesen/Schreiben, Signalaufnahme, Stimulation) zur Verfügung:
- Signale
Lesen, Schreiben, Aufnahme, Stimulation
- Parameter
Lesen, Schreiben
- States
Lesen, Aufnahme
Um das Schreiben und die Stimulation von Signalen zu ermöglichen, wird von ecu.test automatisch ein Instrumentierungsblock im Simulink-Modell am jeweiligen Signalverbinder eingefügt.
Unterstützte Repräsentationen:
- Physikalisch
Zahlenwert (Integer oder Fließkomma)
- Interpretierter Text
Bezeichnung des Wertes für Enumeration-Datentypen
- Rohwert
Text-Repräsentation des Paramters in der Blockmaske (nur bei skalaren Parametern)
Info
Wird ein Signal nur gelesen oder aufgezeichnet und dabei weder geschrieben noch stimuliert, dann muss dafür das Modell nicht instrumentiert werden. Eine Ausnahme ist das Lesen unter Verwendung einer Zeitoption.
Info
Beim Schreiben eines Block-Parameters in dem eine Variable referenziert ist, wird der phsyikalische Wert direkt in die Blockmaske geschrieben. Um den Wert eines in der Blockmaske verwendeten Parameters zu ändern, kann der Parameter bzw. die Variable aus dem BASE WORKSPACE-, MODEL WORKSPACES- oder DATA DICTIONARIES-Knoten verwendet werden.
Signale mit Verzweigungen¶
Beim Einfügen eines Instrumentierungsblocks wird unweigerlich in die Struktur des Modells eingegriffen. ecu.test ist dabei bemüht, dass sich dadurch keine Auswirkungen auf die Datenintegrität ergeben.
Bei nicht verzweigten Signalverbindungen (ein Source-Outport verbunden mit einem Destination-Inport) werden dabei automatisch die Eigenschaften des Source-Ports nach rechts hinter den eingefügten Instrumentierungsblock verschoben, um die Signaleigenschaften für nachfolgende Modellteile zu erhalten.
Wird allerdings bei einer verzweigten Signalverbindung (ein Source-Outport verbunden mit mehreren Destination-Inports) ein Inport im Testfall referenziert, ist die Verschiebung der Signaleigenschaften vom Source-Outport nicht möglich. Daher wird empfohlen, beim Schreiben und Stimulieren von Modellsignalen stets den Source-Outport zu verwenden.
Parameter, Signale und Variablen im MATLAB-Workspace¶
ecu.test ermittelt beim Konfigurationsstart alle Workspace-Variablen der Typen Simulink.Parameter und Simulink.Signal und zeigt diese als separaten BASE WORKSPACE-Knoten im Modellbaum an. Weiterhin durchsucht ecu.test das Modell nach verwendeten Variablen und zeigt diese in einem eigenen Knoten an.
Diese Größen bieten einen einfachen Zugriff auf Modell-Signale und -Parameter, welche ansonsten an beliebigen Stellen im Modell verteilt sein können.
Folgende Besonderheiten gelten:
- Simulink.Parameter oder Variablen
Können gelesen und geschrieben werden
Beim Schreiben wird automatisch das Modell aktualisiert (
set_param(model, 'SimulationCommand', 'update')), damit der neue Parameterwert in der Simulation aktiv wird.
- Simulink.Signal
Lesen, Schreiben, Aufzeichnen und Stimulieren ist möglich
Zum Schreiben und Stimulieren wird das Signal, welches mit dem Simulink.Signal-Objekt verknüpft ist, instrumentiert
- Model Workspaces
Falls das Modell oder die darin referenzierten Modelle Model-Workspaces besitzen, so sind die darin enthalten Variablen, Parameter und Signale unterhalb des MODEL WORKSPACES-Knoten erreichbar. Auch hier werden nur die Größen angezeigt, die tatsächlich im jeweiligen Modell verwendet werden.
- Data Dictionaries
Das Modell oder die darin referenzierten Modelle können mit Data Dictionaries verknüpft werden. Variablen, Parameter und Signale, die in einem solchen gespeichert sind, werden ebenfalls in einem seperaten DATA DICTIONARIES-Knoten angezeigt, falls diese im Modell verwendet werden.
Lesen mit Zeitoption¶
Wird beim Lesen eines Signals zusätzlich eine Zeitoption angegeben, dann wird während des Lesen-Testschrittes die Simulation fortgeführt, bis
entweder die angegebene Erwartung erfüllt ist
oder das angegebene Timeout abgelaufen ist.
Die Zeitoption wird direkt im Simulink-Modell ausgewertet, sofern die Erwartung aus einer Kombination von Vergleichsoperatoren und logischen Operatoren (das beinhaltet auch Vergleiche mit Toleranzen) zusammengesetzt ist. Für diesen Zweck fügt ecu.test einen Instrumentierungsblock für das zu lesende Signal in das Modell ein.
Für Multi-Check-Testschritte ist die Auswertung der Zeitoption direkt im Simulink-Modell nur möglich, wenn folgende Bedingungen erfüllt sind:
Ausschließlich Lesen-Testschritte (keine Berechnen- oder Job-Testschritte) bei denen Ausführung alle n Iterationen nicht aktiv ist
Pro Signal-Mapping nicht mehr als ein Lesen-Testschritt
Polling-Zyklus deaktiviert
Bei einer Zeitoption mit komplexerem Erwartungsausdruck (z.B. Vergleich mit Funktionsaufrufen) oder wenn eine der Bedingungen für Multi-Check-Testschritte nicht erfüllt ist, erfolgt die Auswertung der Zeitoption durch ecu.test. Die Simulation wird dann sehr häufig pausiert und wieder gestartet, was in der Regel zu einem deutlichen Geschwindigkeitsverlust führt. Um die Performance-Auswirkungen in diesem Fall möglichst gering zu halten, sollte bei der Zeitoption ein möglichst hoher Polling-Zyklus gewählt werden.
Hinweise zur Stimulation¶
Das erste Sample einer Stimulation (zum Zeitpunkt 0) wird im im Modell nur dann aktiv, wenn die Stimulation im Testfall bereits vor dem Start der Simulation definiert wurde. Am Ende der Stimulation wird der letzte Wert solange gehalten, bis dieser entweder durch einen Schreiben-Testschritt oder einer weiteren Stimulation überschrieben, bezeziehungsweise der Wert über den Zurücksetzen-Testschritt wieder vom Modell berechnet wird.
Start Stimulus
Die Stimulation von Signalen erfolgt durch eine analytische Berechnung der Segmente, die mit dem Signal Editor erzeugt wurden (für beispielsweise Sinus-, Rampen- oder Const-Segmente). Das ermöglicht eine samplegenaue Wiedergabe der Signalverläufe auch bei der Verwendung von Variable-Step-Solvern, ohne dass der Signalverlauf gesampelt werden muss. Bei Dateireferenz-Segmenten werden die Signalverläufe mit der minimalen Schrittweite des Solvers gesampelt.
Neben der Verwendung von STI/STZ-Dateien können auch alle von ecu.test lesbaren Traceformate für die Stimulation verwendet werden. ecu.test kümmert sich dabei um die Konvertierung der Signalverläufe in ein Format, welches mit der Verwendung in Simulink kompatibel ist.
Info
Es wird ausschließlich die Stimulation von skalaren Signalen unterstützt. Die Stimulation von Vektoren, Matrizen und Bus-Signalen ist nicht möglich.
Stimulus-Dialog
Neben der Verwendung des Start-Stimulus-Testschrittes gibt es die Möglichkeit, eine Stimulation mittels Stimulus-Dialog zu definieren.
Verwendung von States¶
Modell-Zustandsgrößen, so genannte States, können optional aus ecu.test heraus verwendet werden. Hierfür muss die entsprechende Porteigenschaft in der Testbenchkonfiguration gesetzt werden. Im Tab Modellzugriff sind die States über einen separaten Knoten zugänglich und können gelesen und aufgezeichnet werden.
Die in der Testbenchkonfiguration angegebenen Tooleigenschaften zur Verringerung der Signalaufnahme-Abtastrate bzw. zur Begrenzung der Messwerte pro Signal sind auch bei der Aufnahme von States wirksam.
Info
Bei der Aufnahme von States ist zu beachten, dass diese in eine eigene Signalgruppe eingefügt werden, in welcher sich keine Signale anderer Art befinden (siehe hier).
Signale mit physikalischen Einheiten¶
Seit MATLAB R2016a ist es möglich, an Modell-Signalen physikalische Einheiten festzulegen. Falls vorhanden, werden diese Einheiten automatisch in ecu.test erkannt und können beim Lesen bzw. Schreiben wahlweise in andere Einheiten umgerechnet werden (siehe auch units.spec).
Verändern der Sample Time beim Schreiben von Signalen¶
Bei Bedarf kann beim Schreiben eines Signals dessen Sample Time im Modell explizt auf einen anderen Wert gesetzt werden. Dazu kann im Dialog des jeweiligen Mappings das Raster auf den gewünschten Wert gesetzt werden.
Initial enthält die Liste nur Port-Default, -1 und no change. Die Sample Times aus dem Modell werden hinzugefügt, wenn die zugehörige Option in der Testbenchkonfiguration aktiviert ist. Es handelt sich um ein Freitextfeld, in welches ein in MATLAB gültiger Ausdruck eingetragen werden kann. Sofern jedoch ein Wert verwendet werden soll, der nicht bereits in der Auswahlliste vorhanden ist, muss die Option Erlaube alternatives Raster deaktiviert werden.
Der Standardwert Port-Default bewirkt, dass die Sample Time nicht explizit geändert wird, sondern der bereits konfigurierte Wert behalten wird (standardmäßig -1, bzw. das, was in einem vorangegangen Testlauf potentiell gesetzt wurde). Das Raster no change bewirkt das gleiche Verhalten.
Verwendung des Fast-Restart-Modus¶
Die Verwendung des Fast-Restart-Modus von Simulink ist zusammen mit ecu.test grundsätzlich möglich. Um diesen zu verwenden, muss die entsprechende Porteigenschaft in der Testbenchkonfiguration gesetzt werden. Diese bewirkt, dass ecu.test den Fast-Restart-Modus beim erstmaligen Starten der Simulation aktiviert und diesen für nachfolgende Simulationen aktiviert lässt. Aufgrund von Einschränkungen des Fast-Restart-Modus, welche bestimmte Manipulationen am Modell nicht zulassen, ist auch die Verwendung von Testgrößen eingeschränkt:
Schreiben, Stimulieren und Aufnehmen von Signalen ist nur für die Größen möglich, welche in der allerersten Modellausführung geschrieben oder stimuliert bzw. aufgenommen wurden. (Siehe auch die Hinweise zur gruppierten Projektausführung, um diese Einschränkung zu umgehen.)
Das Lesen von Größen ist nicht eingeschränkt, es sei denn die Option „Erzwinge Instrumentierung“ ist aktiviert (dann gelten die gleichen Einschränkungen wie beim Schreiben)
Das Lesen mit Zeitoption funktioniert nur für Signale, welche im allerersten Package mit Zeitoption gelesen wurden.
Der Zugriff auf Parameter ist nicht eingeschränkt.
Der Fast-Restart-Modus eignet sich dadurch insbesondere für Testabläufe mit häufigen Wiederholungen, bei denen immer wieder die gleichen Signale verändert werden.
Info
In Testszenarien, wo in unterschiedlichen Packages unterschiedliche Signale geschrieben werden sollen und trotzdem der Fast-Restart-Modus verwendet werden soll, ist die Verwendung einer gruppierten Projektausführung hilfreich.
Info
Für komplexere Anwendungsfälle können auch die Portjobs FastRestartOn,
FastRestartOff und FastRestartStatus verwendet werden.
Hinweise zur Integration in MATLAB und Simulink¶
Es existiert eine Integration von ecu.test in Simulink. Ziel dieser Integration ist die vereinfachte Anbindung bereits geöffneter Simulink-Modelle an ecu.test. Der Anwender wird bei der Erstellung einer geeigneten Testbenchkonfiguration sowie einer zum jeweiligen Modell passenden Testkonfiguration unterstützt.
Außerdem können über das Simulink-Kontextmenü des Modells globale Mappings erzeugt werden. Dies ist für Inports, Outports und Parameter eines Blocks und auch für Signale möglich. Die Mappings werden in einer globalen Mapping-Datei (<Modellname>.xam) angelegt, automatisch in ecu.test geladen und stehen dann für die Testfallerstellung zur Verfügung.
Um diese Features aus Simulink heraus nutzen zu können, muss zuvor der Ordner matlab innerhalb
des ecu.test-Installationspfades (z.B. <installation path>/ecu.test 20XX.Y/matlab) zum
MATLAB Search Path
hinzugefügt werden. Dies kann über das MATLAB Set Path Menü erfolgen oder alternativ mittels
Ausführung des folgenden Codes in MATLAB. (Installationspfad entsprechend anpassen)
addpath('<installation path>/ecu.test 20XX.Y/matlab');
sl_refresh_customizations;
Die ecu.test-Integration ist nun bei einem geöffneten Modell aus dem heraus verfügbar.
Mit wird ecu.test geöffnet, automatisch eine Testbenchkonfiguration sowie eine Testkonfiguration generiert und diese Konfiguration gestartet, was die Anbindung des aktuellen Simulink-Modells an ecu.test bewirkt.
Zur Generierung der benötigten Artefakte werden im ecu.test-Workspace innerhalb des
Templates-Ordners einige Vorlagen und MATLAB-Funktionen abgelegt. Diese dienen dazu,
die Generierung der Artefakte zu steuern. Beispielsweise kann somit das in der
Testkonfiguration referenzierte Startup-m-file beeinflusst werden.
Info
Die generierten Artefakte werden innerhalb des ecu.test-Workspace unter Verwendung des Simulink-Modellnamens abgelegt und dienen lediglich als Beispiel. Diese können nach Bedarf angepasst werden.
Weitere Möglichkeiten der individuellen Ansteuerung von ecu.test aus MATLAB und der nutzerspezifischen Generierung von Artefakten ergeben sich mit der Verwendung spezieller MATLAB-Funktionen, welche mit ecu.test ausgeliefert werden. Eine detaillierte Dokumentation hierzu ist in MATLAB über folgenden Befehl oder alternativ über verfügbar.
doc ecuTest.api.EcuTestController
Info
Die Integration steht nur unter Windows mit lokaler Toolanbindung zur Verfügung.
Verwendung von Events¶
Es ist möglich, eigene nutzerspezifische Funktionsaufrufe zu bestimmten Zeitpunkten der Testfallausführung zu triggern. Hierfür müssen diese Funktionen unter Nutzung des Event und Listener Konzeptes von MATLAB registriert werden.
Weitere Details sind bei gestarteter Konfiguration mit folgendem MATLAB-Befehl verfügbar:
doc ecuTest.api.Events
Verwendung von Export-Function Models¶
Einschränkungen
Da innerhalb von Export-Function Models einige Einschränkungen gelten, ist bei der Verwendung zusammen mit ecu.test folgendes zu beachten:
Alle Function-Call-Trigger müssen periodisch getriggert werden. Eventbasierte Triggerung bspw. mittels Stateflow-Charts wird nicht unterstützt.
Auf Root-Ebene können keine Signale geschrieben oder aufgezeichnet werden
Signale auf Root-Ebene können nur gelesen werden, wenn keine Instrumentierung verwendet wird
Alternatives Vorgehen
Um diese Einschränkungen zu umgehen, gibt es in der Testbenchkonfiguration eine Port-Einstellung Function-Call-Inports ersetzen. Ist diese aktiviert, dann werden beim Konfigurationsstart die Function-Call-Inports durch Function-Call-Generatoren ersetzt. In einem solchen Modell sind auch auf Root-Ebene Manipulationen möglich und die Verwendung von bestimmten Source-Blöcken ist nicht eingeschränkt.
Damit das Modell ohne weitere Änderungen an der Modellstruktur simulierbar bleibt, nimmt ecu.test in der Modell-Konfiguration folgende Einstellungen vor:
Solver: Setzen von Automatically handle rate transition for data transfer
Solver: Setzen von Deterministic data transfer auf Never (minimum delay)
Info
Inwieweit dies ein zulässiger Eingriff in das Simulationsverhalten des Modells ist und ob dabei die Datenintegrität erhalten bleibt, ist im Einzelfall durch den Anwender zu prüfen.
Hinweise zur Steigerung der Testperformance¶
Folgende Punkte sollten beachtet werden, falls es beim Testen von Simulink-Modellen zu starken Performanceeinbußen kommt.
Lesen mit Zeitoption
Unter Lesen mit Zeitoption ist beschrieben, wie verhindert werden kann, dass die Simulation während eines Lesen-Testschritts häufig pausiert und wieder gestartet wird.
Modell im Hintergrund simulieren
Bei der Simulation des Simulinkmodells macht es in einigen Fällen einen Unterschied, ob während der Ausführung das jeweilige Modellfenster geöffnet oder nicht sichtbar ist. Ein sichtbares Modellfenster bewirkt häufig, dass die Simulation langsamer abläuft. Dieses Verhalten ist unabhängig von ecu.test, kann aber über die Option Im Hintergrund simulieren in der Testbenchkonfiguration gesteuert werden.
Der Unterschied liegt darin, ob das Modell mit open_system (mit Fenster) oder
load_system (im Hintergrund) geöffnet wird. Ein mit load_system geladenes Modell lässt
sich jederzeit nachträglich mit open_system öffnen (z.B. zu Debugging-Zwecken).
Das Aktivieren der Option wird erst ab MATLAB R2015b empfohlen, da in
früheren Versionen im load_system-Fall einige Modell-Callbacks beim Laden nicht ausgeführt
werden.
Gruppierte Projektausführung
Falls auf einem Modell viele Testfälle aus einem Projektkontext heraus ausgeführt werden sollen, dann ist die Verwendung des Fast-Restart-Modus hilfreich um zu verhindern, dass zwischen den Testfällen das Modell jedes Mal neu kompiliert werden muss.
Problematisch ist dabei, dass spätere Packages Signale schreiben müssen, welche zu Anfang noch nicht instrumentiert wurden. Diese Instrumentierung schlägt fehl, wenn sich das Modell im Fast-Restart-Modus befindet oder gerade simuliert.
Um dieses Problem zu umgehen erkennt ecu.test zu Beginn einer Projektausführung, ob die Instrumentierung später verwendeter Signale bereits vor dem Start der Simulation möglich ist. Dazu müssen die folgenden Kriterien zutreffen:
Es muss eine Konfiguration gestartet sein, in welcher ausschließlich das Tool MATLAB/Simulink und dessen Modellport verwendet wird.
Das Projekt darf folgende Komponenten nicht enthalten:
Projektreferenz, welche als separates Unterprojekt ausgeführt wird
Info
Bei der gruppierten Ausführung werden bereits zu Projektbeginn alle im Projekt enthaltenen Packages und Parametersätze einmalig geladen und darin enthaltene Schreiben-Schritte und Signalaufnahmen instrumentiert. Dieser Vorgang kann insbesondere bei Projekten mit vielen Schritten etwas dauern.
Anwendungsart: MATLAB Automation-Server
Mit der Einstellung der MATLAB-Anwendungsart MATLAB Automation-Server in den Porteigenschaften der Testbenchkonfiguration kann MATLAB mit einer reduzierten GUI gestartet werden. Diese Einstellung führt zu einem signifikanten Performancegewinn, insbesondere unter Linux.
Sample Times nur bei Bedarf laden
In der TBC die Option Sample Times vom Modell abrufen deaktivieren um zu verhindern, dass das Modell im Voraus extra kompiliert wird, um Sample Time Informationen zu laden. Diese haben lediglich informativen Charakter und werden nur in wenigen Anwendungsfällen benötigt.
Base Workspace nur bei Bedarf laden
Wenn keine Variablen, Signale oder Parameter des MATLAB Base Workspace oder des Model Workspace des Hauptmodells gelesen werden müssen, kann die TBC Option Lade Base Workspace deaktiviert werden, um das Laden dieser Workspaces zu vermeiden.
Irrelevante Modellstrukturen ausblenden
Unter Ausblenden nicht relevanter Modellstrukturen wird beschrieben, wie man unnötige Teile des Modells ausblenden kann. Dies kann den Konfigurationsstart beschleunigen.
Nutzung von Model Workspaces und SLDDs aus referenzierten Modellen vermeiden
Die Variablen und Parameter in Model Workspaces und Simulink Data Dictionaries (SLDDs) von referenzierten Modellen werden jetzt nur noch bei Bedarf eingelesen. Falls im Test auf Größen aus diesen Quellen verzichtet wird, führt dies automatisch zu einem schnelleren Konfigurationsstart. Wird im großen Umfang auf diese Art von Größen aus einer Vielzahl referenzierter Modelle zugegriffen, sollte in Erwägung gezogen werden, Testfälle herunterzubrechen und einzelne Unit-Tests für jedes referenzierte Sub-Modell zu implementieren. Nur dort wird dann auf die internen Parameter zugegriffen. Dann kann bei einem übergeordneten Systemtest der Zugriff auf Interna der referenzierten Sub-Modelle verzichtet werden.
Unterstützte Formate von .mat-Dateien¶
Für die Stimulation von Signalen und zur Verwendung in der Traceanalyse unterstützt ecu.test nativ das Einlesen von .mat-Dateien. Voraussetzung ist, dass diese in einem der im folgenden beschriebenen Formate vorliegen.
Info
In ecu.test können nur Signale mit numerischen Datentypen (double, int32,
uint8 etc.) verarbeitet werden. Datentypen, welche zumindest eine numerische
Repräsentation besitzen (z.B. Enumerationen oder embedded.fi) sollten noch in
MATLAB mittels int32(values) bzw. double(values) entsprechend konvertiert werden.
„Structure With Time“ mit gemeinsamer Zeitachse¶
Bei diesem Format handelt es sich um ein Format, welches Simulink anlegt, wenn man in den Modelleinstellungen festlegt, dass States- oder Output-Daten während der Simulation in Workspace-Variablen gespeichert werden sollen und als Format: Structure with time gewählt wird.
In der Traceanalyse werden Signalverläufe von Skalaren, Vektoren und 2D-Matrizen unterstützt. Zur Stimulation sind nur skalare Signalverläufe möglich.
Example
Das nachfolgende Skript zeigt, wie eine solche .mat-Datei erzeugt werden kann:
matFileData = struct('time', [], 'signals', []);
matFileData.time = 0:0.1:1;
matFileData.signals = struct();
% Scalar Signal
matFileData.signals(1).values = 0.5*matFileData.time;
matFileData.signals(1).dimensions = 1;
matFileData.signals(1).label = 'ScalarSignal1';
% Vector Signal
matFileData.signals(2).values = [sin(matFileData.time)' cos(matFileData.time)'];
matFileData.signals(2).dimensions = 2;
matFileData.signals(2).label = 'VectorSignal1';
% Matrix Signal
matrixData = rand(2, 3, numel(matFileData.time));
matFileData.signals(3).values = matrixData;
matFileData.signals(3).dimensions = [2 3];
matFileData.signals(3).label = 'MatrixSignal1';
traceFileName = 'MatTraceFile.mat';
save(traceFileName, 'matFileData', '-V7');
„Structure With Time“ mit separaten Zeitachsen¶
Bei diesem Format besitzt jeder einzelne Signalverlauf eine eigene Zeitachse. Ansonsten gelten zur Analyse und Stimulation die gleichen Einschränkungen wie beim Format mit gemeinsamer Zeitachse.
Example
matFileData = struct('time', [], 'signals', []);
% Scalar Signal
time = 0:0.1:1;
values = 0.5 * time;
signalStruct = struct('values', values, 'dimensions', 1, 'label', 'ScalarSignal1');
dataStruct = struct('time', time, 'signals', signalStruct);
matFileData(1) = dataStruct;
% Vector Signal
time = 0:0.2:1;
values = [sin(time)' cos(time)'];
signalStruct = struct('values', values, 'dimensions', 2, 'label', 'VectorSignal1');
dataStruct = struct('time', time, 'signals', signalStruct);
matFileData(2) = dataStruct;
% Matrix Signal
time = 0:0.25:1;
values = rand(2, 3, numel(time));
signalStruct = struct('values', values, 'dimensions', [2 3], 'label', 'MatrixSignal1');
dataStruct = struct('time', time, 'signals', signalStruct);
matFileData(3) = dataStruct;
traceFileName = 'MatTraceFile.mat';
save(traceFileName, 'matFileData', '-V7');
Weitere Formate¶
Grundsätzlich kann auch das hier beschriebene Format verwendet werden. Da es sich jedoch um ein älteres Format handelt, sollte zu Gunsten eines der beiden zuvor beschriebenen Formate darauf verzichtet werden.
Problembehebung¶
Durch das Einfügen des ecu.test-Instrumentierungsblocks kann Simulink die Sample Time im Modell nicht mehr korrekt bestimmen (Fehlermeldung ‚Inconsistent sample times‘)
Um dem Signal wieder die korrekte Sample Time zuzuweisen, kann diese explizit als „Raster“ des jeweiligen Mappings gesetzt werden.
Eigenschaften 🛈¶
Name |
Verfügbar wenn |
Standardwert |
Gültige Werte |
Typ |
Beschreibung |
|---|---|---|---|---|---|
Modell-Verzeichnis |
uri |
Basisverzeichnis für die Modellsuche. Wenn es sich um eine relative Pfadangabe handelt, wird der Basispfad vom genutzten Toolhost verwendet und um das angegebene Modellverzeichnis ergänzt. |
|||
MATLAB-Release |
Auto |
[Auto, Pfad zum Installationsverzeichnis, R2015b, R2016a, R2016b, R2017a, R2017b, R2018a, R2018b, R2019a, R2019b, R2020a, R2020b, R2021a, R2021b, R2022a, R2022b, R2023a, R2023b, R2024a, R2024b] |
string |
MATLAB-Release, welches verwendet werden soll. ‚Auto‘ wählt die Standardinstallation auf dem Tool Server. ‚Pfad zum Installationsverzeichnis‘ erlaubt die Angabe eines Pfades zur MATLAB-Installation. Unter Linux ist es nicht möglich, eine MATLAB-Instanz unter Angabe des Release zu verwenden oder automatisch ermitteln zu lassen. |
|
Installationspfad |
MATLAB-Release: ‚Pfad zum Installationsverzeichnis‘ |
uri |
Das zu verwendende MATLAB-Installationsverzeichnis. |
||
MATLAB-Anwendungsart |
‚MATLAB Desktop‘ |
[‚MATLAB Desktop‘, ‚MATLAB Automation-Server‘] |
string |
Auswahl, ob MATLAB als Desktop-Version oder Automation-Server gestartet werden soll. Die Einstellung ‚MATLAB Automation-Server‘ führt insbesondere unter Linux zu einem signifikanten Performancegewinn. |
|
MATLAB-Verbindungsart |
‚New‘ |
[‚Auto‘, ‚Reconnect‘, ‚New‘] |
string |
Auswahl, ob eine neue Instanz von MATLAB gestartet werden soll, oder ob eine bestehende Instanz verbunden werden soll. Unter Linux ist es nicht möglich, sich mit einer bestehenden MATLAB-Instanz zu verbinden. |
|
Max. Werte Signalaufnahme |
‚0‘ |
string |
Maximale Anzahl der Messwerte pro Signal, die zwischengespeichert werden. (‚Limit data points to last‘) |
||
Signalaufnahme-Abtastrate verringern |
‚0‘ |
string |
Kann verwendet werden, um die Anzahl der zwischengespeicherten Werte zu verringern. Verwendung jedes n-ten Samples. (‚Decimation‘) |
||
Quelle der Datentypen |
‚Model‘ |
[‚Model‘, ‚Mapping‘, ‚Mapping (strict)‘] |
string |
Gibt an, ob die Datentypen des Modells oder die aus dem ecu.test-Mapping verwendet werden sollen. Optional strikte Datentypprüfung, welche verifiziert, dass Modell- und Mapping-Datentyp übereinstimmen. |
|
Rundungsmodus bei Datentypkonvertierung |
‚Floor‘ |
[‚Ceiling‘, ‚Convergent‘, ‚Floor‘, ‚Nearest‘, ‚Round‘, ‚Simplest‘, ‚Zero‘] |
string |
Gibt an, wie beim Konvertieren von Komma- in Ganzzahlwerte gerundet werden soll. |
|
Integer-Überlauf verhindern |
☐ |
bool |
Bei expliziter Konvertierung in Ganzzahlwerte den Integer-Überlauf verhindern. (Nur wenn Datentypquelle das Mapping ist.) |
||
Erzwinge Instrumentierung |
☐ |
bool |
Für das ausschließliche Lesen eines Signals wird nun keine Instrumentierung mehr benötigt. Sollte es jedoch zu Problemen kommen, kann optional das Einfügen einer Instrumentierung auch für lesenden Zugriff erzwungen werden. |
||
MATLAB-Arbeitsverzeichnis |
‚<modelroot>‘ |
string |
Legt fest, wohin und ob das MATLAB-Arbeitsverzeichnis gewechselt werden soll. Mögliche Optionen:
Der Bezeichner <modelroot> kann auch als Pfadbestandteil verwendet werden. |
||
Caching der Modellstruktur |
☑ |
bool |
Aktiviert das Caching der Informationen über die Modellstruktur. Dadurch können unmodifizierte Modelle während des Konfigurationsstarts ohne Kompilierung geladen werden. |
||
Im Hintergrund simulieren |
☐ |
bool |
Zum Laden des Modells load_system statt open_system verwenden. Dadurch bleibt das Modell unsichtbar und die Simulation erfolgt in der Regel schneller. |
||
Timeout für Toolzugriffe ❲in Sek.❳ |
‚600‘ |
string |
Zeit nach der eine Anfrage an das Tool abgebrochen wird. |
Jobs 🛈¶
ExecuteWorkspaceCmd¶
Befehle in MATLAB ausführen.
Parametrierung
Parameter
Name |
Verfügbar wenn |
Standardwert |
Gültige Werte |
Typ |
Beschreibung |
|---|---|---|---|---|---|
Command |
string |
Ausdruck, der in der MATLAB-Befehlszeile ausgewertet werden soll. Ein Semikolon wird implizit angehängt. |
Rückgabewert
Name |
Verfügbar wenn |
Standardwert |
Gültige Werte |
Typ |
Beschreibung |
|---|---|---|---|---|---|
result |
string |
Alle Ausgaben, die während der Ausführung des Befehls durch disp()-, warning()- oder fprintf()-Aufrufe erzeugt werden. Um das Ergebnis des ausgewerteten Ausdrucks abzurufen, weisen Sie es einer temporären Variablen zu und rufen ihren Wert mit dem Job ReadWorkspaceVar ab. |
GetModelParameter¶
Modell-Parameter lesen.
Parametrierung
Parameter
Name |
Verfügbar wenn |
Standardwert |
Gültige Werte |
Typ |
Beschreibung |
|---|---|---|---|---|---|
parameterName |
‚SimulationTime‘ |
[‚SimulationTime‘, ‚SimulationStatus‘, ‚SimulationMode‘, ‚Name‘, ‚Tag‘, ‚Description‘, ‚MdlSubVersion‘, ‚ModelVersion‘, ‚Version‘, ‚Type‘, ‚Creator‘, ‚Created‘, ‚ModifiedBy‘, ‚LastModifiedBy‘, ‚LastModifiedDate‘, ‚Solver‘, ‚SolverName‘, ‚SolverType‘, ‚InitialStep‘, ‚FixedStep‘, ‚MaxStep‘, ‚MinStep‘, ‚RelTol‘, ‚AbsTol‘, ‚SaveFormat‘, ‚SignalLoggingSaveFormat‘, ‚SignalLoggingName‘, ‚LimitDataPoints‘, ‚UnderSpecifiedDataTypeMsg‘, ‚UnnecessaryDatatypeConvMsg‘, ‚SignalResolutionControl‘, ‚EnableOverflowDetection‘, ‚SignalRangeChecking‘, ‚FixptConstOverflowMsg‘, ‚IntegerOverflowMsg‘, ‚IntegerSaturationMsg‘, ‚Int32ToFloatConvMsg‘, ‚ParameterDowncastMsg‘, ‚ParameterOverflowMsg‘, ‚ParameterUnderflowMsg‘, ‚ParameterPrecisionLossMsg‘] |
string |
Bezeichnung des zu lesenden Parameters |
Rückgabewert
Name |
Verfügbar wenn |
Standardwert |
Gültige Werte |
Typ |
Beschreibung |
|---|---|---|---|---|---|
result |
object |
Python-Repräsentation des Parameterwerts |
LoadMatFile¶
*.mat-Datei in den MATLAB Workspace laden. Die Datei muss sich im Modellverzeichnis bzw. im MatlabPath auf dem Toolhost befinden.
Parametrierung
Parameter
Name |
Verfügbar wenn |
Standardwert |
Gültige Werte |
Typ |
Beschreibung |
|---|---|---|---|---|---|
FileName |
string |
Dateiname der zu ladenenden *.mat-Datei |
Rückgabewert
Name |
Verfügbar wenn |
Standardwert |
Gültige Werte |
Typ |
Beschreibung |
|---|---|---|---|---|---|
result |
/ |
Kein Rückgabewert |
ReadWorkspaceVar¶
Variablenwerte aus dem MATLAB-Workspace lesen.
Parametrierung
Parameter
Name |
Verfügbar wenn |
Standardwert |
Gültige Werte |
Typ |
Beschreibung |
|---|---|---|---|---|---|
VarName |
string |
Name der Variablen |
Rückgabewert
Name |
Verfügbar wenn |
Standardwert |
Gültige Werte |
Typ |
Beschreibung |
|---|---|---|---|---|---|
result |
object |
Python-Repräsentation des Variablenwerts |
SetModelParameter¶
Modell-Parameter schreiben.
Parametrierung
Parameter
Name |
Verfügbar wenn |
Standardwert |
Gültige Werte |
Typ |
Beschreibung |
|---|---|---|---|---|---|
parameterName |
‚IntegerOverflowMsg‘ |
[‚Solver‘, ‚SolverName‘, ‚SolverType‘, ‚InitialStep‘, ‚FixedStep‘, ‚MaxStep‘, ‚MinStep‘, ‚RelTol‘, ‚AbsTol‘, ‚SaveFormat‘, ‚SignalLoggingSaveFormat‘, ‚SignalLoggingName‘, ‚LimitDataPoints‘, ‚UnderSpecifiedDataTypeMsg‘, ‚UnnecessaryDatatypeConvMsg‘, ‚SignalResolutionControl‘, ‚EnableOverflowDetection‘, ‚SignalRangeChecking‘, ‚FixptConstOverflowMsg‘, ‚IntegerOverflowMsg‘, ‚IntegerSaturationMsg‘, ‚Int32ToFloatConvMsg‘, ‚ParameterDowncastMsg‘, ‚ParameterOverflowMsg‘, ‚ParameterUnderflowMsg‘, ‚ParameterPrecisionLossMsg‘] |
string |
Bezeichnung des zu setzenden Parameters |
|
parameterValue |
‚warning‘ |
[‚none‘, ‚warning‘, ‚error‘, ‚on‘, ‚off‘, ‚0.01‘, ‚ode3‘] |
string |
Wert des Parameters |
Rückgabewert
Name |
Verfügbar wenn |
Standardwert |
Gültige Werte |
Typ |
Beschreibung |
|---|---|---|---|---|---|
result |
/ |
Kein Rückgabewert |
WriteWorkspaceVar¶
Variablenwerte in den MATLAB-Workspace schreiben.
Parametrierung
Parameter
Name |
Verfügbar wenn |
Standardwert |
Gültige Werte |
Typ |
Beschreibung |
|---|---|---|---|---|---|
VarName |
string |
Name der Variablen |
|||
VarValue |
object |
Wert der Variablen |
Rückgabewert
Name |
Verfügbar wenn |
Standardwert |
Gültige Werte |
Typ |
Beschreibung |
|---|---|---|---|---|---|
result |
/ |
Kein Rückgabewert |