Mathworks: MATLAB & Simulink¶

Herstellerinformationen

Kategorien

Plattform

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,

• Lesen und Aufzeichnen von Modell-Zustandsgrößen,

• Samplegenaue Steuerung der Simulationszeit,

• Fernsteuern von ecu.test von eigenen MATLAB-Skripten aus

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 mit echo $DISPLAY abgefragt werden. Diese muss mit export DISPLAY=wert vor dem Start von ecu.test bzw. Tool Server gesetzt werden, falls diese nicht bereits initialisiert ist. wert ist dabei häufig :0 oder :0.0.

Weitere Informationen zur Verwendung von ecu.test unter Linux:

• Basisworkflow unter Linux

• Tutorial Tool Server 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.

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.

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.

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 Testbenchkonfiguration anlegen.

Hinweise zur Testkonfiguration¶

Allgemeine Hinweise zur Erstellung einer neuen Testkonfiguration siehe Testkonfiguration anlegen.

Auswahl des Testmodells¶

Auf dem Tab Plattform kann die zu verwendende Modell-, Initialisierungs- oder Simulink-Project-Datei ausgewählt werden.

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.

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>)

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.

Steuerung der Simulationszeit¶

Siehe auch: Details zu den Zeitmodi.

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.

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.

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.

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 Parameters in der Blockmaske (nur bei skalaren Parametern)

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 separaten 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.

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.

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.

• 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. Hat man ein Projekt mit Packages, in welchen unterschiedliche Signale manipuliert oder aufgenommen werden sollen, kann der Fast-Restart-Modus unter bestimmten Bedingungen trotzdem verwendet werden. ecu.test muss dafür die Möglichkeit haben, alle verwendeten Signale bereits zu Beginn des Projektes zu instrumentieren. Das passiert automatisch, wenn folgende Kriterien erfüllt sind:

• Es muss eine Konfiguration gestartet sein, in welcher ausschließlich das Tool MATLAB/Simulink und dessen Modellport verwendet werden.

• Das Projekt darf folgende Komponenten nicht enthalten:

  • Konfigurationswechsel

  • Projektgenerator

  • Packagegenerator

  • Projektreferenz, welche als separates Unterprojekt ausgeführt wird

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 Simulink-Menu ‣ Tools ‣ ecu.test heraus verfügbar.

Mit Simulink-Menu ‣ Tools ‣ ecu.test ‣ Start Configuration 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.

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 Simulink-Menu ‣ Tools ‣ ecu.test ‣ Help verfügbar.

doc ecuTest.api.EcuTestController

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)

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.

Fast-Restart-Modus nutzen

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.

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.

„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.

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.

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 🛈¶

Jobs 🛈¶

ExecuteWorkspaceCmd¶

Befehle in MATLAB ausführen.

GetModelParameter¶

Modell-Parameter lesen.

LoadMatFile¶

*.mat-Datei in den MATLAB Workspace laden. Die Datei muss sich im Modellverzeichnis bzw. im MatlabPath auf dem Toolhost befinden.

ReadWorkspaceVar¶

Variablenwerte aus dem MATLAB-Workspace lesen.

SetModelParameter¶

Modell-Parameter schreiben.

WriteWorkspaceVar¶

Variablenwerte in den MATLAB-Workspace schreiben.