FEP3

Bisheriger/interner Bezeichner: FEP3

Herstellerinformationen

Hersteller

Webseite

Produktname

Version

Functional Engineering Platform

3.0

Kategorien

MDL 🛈

APL 🛈

BAN 🛈

BMA 🛈

SVC 🛈

DGN 🛈

FIU 🛈

EES 🛈

FCT 🛈

DBG 🛈

IMG 🛈

AUDIO 🛈

ENVSIM 🛈

ENVCOM 🛈

✓

Plattform

Betriebssystem

Unterstützung

Windows

✓

Linux

Ports

Besonderheiten

Diese Toolanbindung ermöglicht:

  • Lesen und Schreiben der Properties der Teilnehmer

  • Lesen und Schreiben von Signalen auf dem Simulationsbus

  • Aufnahme von Signalen mit anschließender Traceanalyse

  • Zustandssteuerung (Initialisieren, Starten, Stoppen, …) des Simulationsverbunds

Voraussetzungen

Für die Nutzung dieser Anbindung müssen folgende Voraussetzungen erfüllt sein:

Umgebungsvariable

Damit diese Anbindung in der Liste verfügbarer Tools in ecu.test angezeigt wird, muss auf dem genutzten Toolhost die Umgebungsvariable FEP3_PARTICIPANT_COMPONENTS_FILE_PATH gesetzt sein. Diese muss den absoluten Pfad des zu benutzenden FEP Component Configuration File (*.fep_components) enthalten. Details zu dieser Datei und dem Komponenten-System von FEP sind in der FEP User Documentation bzw. in der Dokumentation zum FEP SDK zu finden.

Launch des FEP-Systems

Das zu steuernde FEP-System muss bereits ausgerollt und gestartet sein. Dafür ist evtl. externes Tooling (FEP Agent, FEP Access, FEP Control etc.) notwendig.

Systembeschreibung

In der Testbenchkonfiguration wird der Pfad zur Systembeschreibungsdatei des FEP-Systems angegeben. Damit ecu.test die Beschreibung des Systems einlesen und im Modellzugriffs-Reiter den Signalbaum anzeigen kann, müssen alle relevanten Informationen im selben Verzeichnis liegen.

Dabei handelt es sich um folgende Dateien:

  • Systembeschreibungsdatei (*.mm3_system.yml)

  • Elementbeschreibungsdateien (*.mm3_element_type.yml)

  • DDL-Informationen (*.description)

Die Elementbeschreibungsdateien müssen dabei denselben Dateinamen haben, wie ihre Conan Reference in der Systembeschreibungsdatei.

Beispielhafter Auszug aus einer Systembeschreibungsdatei:

system:
    name: FepDemo
    element_instances:
        car_ego:
            conan_reference: fep_simple_car/..@..

In diesem Fall muss die Elementbeschreibungsdatei den Dateinamen fep_simple_car.mm3_element_type.yml besitzen.

Participant-Prioritäten

ecu.test wendet beim Initialisieren und Starten des FEP-Systems die in der Systembeschreibungsdatei angegebenen Init- und Start-Prioritäten an (Participants mit größerer Zahl werden vor Participants mit kleinere Zahl gestartet, negative Zahlen sind erlaubt). Gegebenenfalls zusätzlich vom Anwender eingebrachte, aber nicht in der Systembeschreibung aufgeführte Participants erhalten die Priorität 0. Gleiches gilt für die von ecu.test zur Steuerung und Überwachung des Systems eingebrachten Participants.

Es ist Aufgabe des Anwenders die Init- und Start-Prioritäten in der Systembeschreibung entsprechend der Abhängigkeiten der Participants untereinander zu setzen. Dabei ist zu beachten, dass die zusätzlich eingebrachten Participants in der Regel nach jenen in der Systembeschreibung initialisiert bzw. gestartet werden und der Timing-Master ganz zum Schluss. Dies lässt sich sehr einfach dadurch realisieren, dass man dem Timing-Master eine negative Priorität zuweist und für die anderen Participants in der Systembeschreibung ausschließlich Prioritäten >0 vergibt.

Einschränkungen

Folgende Einschränkungen sind bei der Verwendung dieser Anbindung zu beachten:

Systemproperties

Die in der Systembeschreibungsdatei für die einzelnen Participants ggf. angegebene Property-Bedatung (insb. Timing-Einstellungen und Signal-Renamings) wird nicht automatisch durch ecu.test appliziert. Dafür ist ggf. externes Tooling (FEP Access, FEP Control etc.) notwendig.

Lesen & Schreiben von FEP-Signalen

Bei allen Signalen, die im Modellbaum von ecu.test in erster Ebene unter dem Knoten Signale aufgelistet sind, handelt es sich um FEP-Signale. Wenn eines dieser Signale weiter aufgeklappt werden kann, so handelt es sich um ein komplexes Signal mit einem oder mehreren Untersignalen, auch Elemente genannt. Lese- und Schreibschritte beziehen sich jeweils auf eins dieser Signalelemente. Das Lesen bzw. Schreiben mehrerer Elemente eines Signals erfordert daher mehrere Testschritte.

Werden nacheinander mehrere Elemente eines Signals ausgelesen, ist nicht sichergestellt, dass die gelesenen Werte aus demselben Sample des Signals stammen.

Wird eines dieser Elemente geschrieben, so wird immer das vollständige, komplexe Signal versendet, wobei alle anderen Elemente ihre aktuellen Werte behalten. Dies sind die Werte aus dem letzten Sample des Signals, das von ecu.test empfangen oder versendet wurde. Existiert kein letztes Sample, wird 0 bzw. der dem vollständig genullten Pufferspeicher des Elements entsprechende Wert als aktueller Wert verwendet.

Werden mehrere Elemente durch aufeinanderfolgende Schreibschritte verändert, so wird bei jedem Schreibschritt ein vollständiges, komplexes Signal versendet.

Zyklisches Senden und Muten von FEP-Signalen wird nicht unterstützt. Existiert in dem FEP-System ein Participant, der dasselbe Signal (zyklisch) sendet, so werden die von ecu.test gesendeten Werte des Signals wieder überschrieben.

Unterstützte Signaltypen

ecu.test unterstützt ausschließlich DDL-Signale, deren Struktur in einer Description-Datei definiert ist (stream_meta_type: "ddl-fileref"). RAW-Signale und andere Signaltypen werden nicht unterstützt.

Signalnamen

Die Umbenennung von Signalen muss statisch in der Systembeschreibung spezifiziert und genauso im Status INITIALIZED bzw. RUNNING aktiv sein. Eine davon abweichende, dynamische Festlegung bzw. Änderung wird von ecu.test nicht unterstützt.

Info

Die im Modellzugriffs-Reiter von ecu.test angezeigten Signale ergeben sich aus den Input- und Output-Spezifikationen in den Elementbeschreibungsdateien und etwaigen Signalumbenennungen an den Element-Instanzen in der Systembeschreibung. Jeder der angezeigten Signalnamen ist der neue Name in einer Signalumbenennung und/oder der Originalname eines Inputs bzw. Outputs, für den es keine Signalumbenennung gibt.

Traceaufzeichnung

Pro Signalgruppe wird nur eine Aufnahmegruppe unterstützt.

Jede Aufnahmegruppe kann im Testfall nur einmal gestartet und gestoppt werden.

Traceaufzeichnung von FEP-Signalen ist nur möglich, wenn sich das FEP-System bei Start des Testfall-Packages im Status UNLOADED befindet und am Testfallende wieder in den Status UNLOADED gebracht wird. Es ist also nicht möglich, die Schritte Load, Start, Stop und Unload auf mehrere Testfall-Packages (z.B. innerhalb eines Projektes) zu verteilen, wenn FEP-Signale aufgezeichnet werden sollen.

Zeitmodi

Die Toolanbindung unterstützt ecu.test-seitig den Echtzeit- und den kontinuierlichen Simulationszeitmodus (siehe Zeitmodus). Das angesteuerte FEP-System kann in den synchronisierten FEP-Timing-Modes Continuous Timing und Discrete Timing oder unsynchronisiert (No Timing Master) laufen.

Standardmäßig aktiviert diese Toolanbindung den kontinuierlichen Simulationszeitmodus. Dieser stellt in allen (synchronisierten) FEP-Timing-Modes sicher, dass die Zeit im Testfall und die FEP-Zeit synchron laufen. Der vom FEP-System verwendete Timing-Mode wird dabei automatisch erkannt.

Die Auflösung, mit der die FEP-Zeit im kontinuierlichen Simulationszeitmodus in ecu.test zur Verfügung steht, wird automatisch konfiguriert. Läuft das FEP-System im Modus Discrete Timing, wird die Zeitschrittgröße des Timing-Master übernommen. In allen anderen FEP-Timing-Modes wird standardmäßig eine Auflösung von 100ms verwendet. Bei Bedarf kann die automatische Bestimmung der Auflösung auch in der Testbenchkonfiguration deaktiviert und über die Eigenschaft Zeitraster auf einen nutzerdefinierten Wert gesetzt werden.

Das Zeitraster bestimmt die Genauigkeit von Testschritten mit Zeitangaben. Zum Beispiel würde ein Warte-Testschritt von 250ms bei einem 100ms-Zeitraster 300ms warten. Für eine hohe Genauigkeit ist ein möglichst kleines Zeitraster wünschenswert. Allerdings erhöhen kleine Zeitraster die von ecu.test zu verarbeitende Rate von Zeitstempeln, welche begrenzt ist.

Info

Generell ist darauf zu achten, dass die von ecu.test zu verarbeitende Zeitstempelrate 100 Zeitstempel pro Sekunde nicht überschreitet. Die Zeitstempelrate ergibt sich als Quotient aus TimeFactor_float-Einstellung des Timing-Masters geteilt durch die Zeitraster-Einstellung in ecu.test. Zum Beispiel ergeben ein Zeitfaktor von 2,0 (doppelte Echtzeit) und ein Zeitraster von 50ms (0,05s) eine Rate von 40 Zeitstempeln pro Sekunde.

Im Echtzeitmodus werden die Zeit im Testfall und die FEP-Zeit nicht synchronisiert. Der Echtzeitmodus ist daher nur für die FEP-Timing-Modes Discrete Timing mit TimeFactor_float = 1.0 oder Continuous Timing geeignet und ggf. für unsynchronisierte FEP-Systeme (No Timing Master), da andernfalls die Zeiten im Testfall und im FEP-System stark auseinanderlaufen.