FEP

Bisheriger/interner Bezeichner: FEP

Warnung

Dieses Tool wurde abgekündigt und wird in einer der kommenden Versionen entfernt!

Herstellerinformationen

Hersteller

Webseite

Produktname

Version

Functional Engineering Platform

2.2.0 - 2.7.4

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 das Anzeigen, Lesen und Schreiben der Properties aller Teilnehmer, das Lesen und Schreiben von Signalen auf dem Datenbus zur Laufzeit sowie die Aufnahme beliebiger Signale mit anschließender Traceanalyse. Die Teilnehmer des FEP-Systems können auf verteilten Systemen unter Windows und Linux aufgestartet und beendet werden. Weiterhin kann ecu.test für die Lifecyclesteuerung des Simulationsverbunds und zur Überwachung der Zustände der Teilnehmer eingesetzt werden.

Info

Für die Nutzung dieser Anbindung ist zwingend ein korrekt erstelltes Metamodell, ein vorhandenes FEP-SDK sowie ein Timing-Master im FEP-System notwendig. Weiterhin muss das FEP-System über die Anbindung gesteuert werden. Eine gleichzeitige Steuerung des FEP-Systems über ein externes Tool oder eine andere Anbindung wird nicht unterstützt.

ecu.test benötigt die FEP2-SDK-Bestandteile FEP-SDK-Participant in Version 2.7.3 und FEP-SDK-System in Version 2.7.4. Das FEP-System, mit dem sich ecu.test verbindet, kann eine andere FEP-SDK-Version verwenden. Dabei werden alle Versionen von FEP2 ab der 2.2.0 unterstützt.

Die Pfade zu den zu verwendenden FEP-SDK-Bestandteilen FEP-SDK-Participant und FEP-SDK-System müssen in der TBC angegeben werden.

Alle im Metamodell konfigurierten Teilnehmer sowie deren Properties und registrierten Signale werden bei geladener Konfiguration im Reiter Modellzugriff angezeigt. Eine Ausnahme bilden Signale ohne Typangabe, sogenannte Rohsignale. Auf diese kann in ecu.test nicht zugegriffen werden. Deshalb werden sie auch nicht angezeigt.

Aufnahmen können sowohl per explizitem Aufruf von Start trace und Stop trace als auch per Auto-Start/Stop erzeugt werden.

Info

Beim Schreiben von Signalen in FEP ist folgendes zu bedenken:

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. Wenn in ecu.test eines dieser Elemente geschrieben wird, so wird immer das vollständige, komplexe Signal versendet und alle anderen Elemente behalten ihren aktuellen Wert. Das ist entweder der Standardwert, falls das Signal noch nie auf dem FEP-Bus versendet wurde, oder der Wert vom letzten versendeten Signalsample.

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

Wenn mehrere Elemente zeitgleich geändert werden sollen, und somit das komplexe Signal nur ein Mal versendet wird, so muss der Portjob SendSignalSample verwendet werden.

Aktuell wird kein zyklisches Senden und kein Muten von FEP-Signalen unterstützt. Existiert in dem FEP-System ein Participant, der dasselbe Signal zyklisch sendet, so wird das von ecu.test gesendete Signal überschrieben.

Automatisches Aufspalten/Demultiplexing von Signalen der Typen „tFEP_VU_ObjectState“ bzw. „tFEP_VU_VehicleAppearance“ des FEP-VU-Interfaces kann über die TBC-Option „Signaldemultiplexing von FEP-VU-Signalen aktivieren“ in der TBC eingeschaltet werden. Bei aktivierter Option werden die registrierten Signale der genannten Signaltypen jeweils durch virtuelle Signale mit einem Index-Suffix ersetzt. Diese aufgespaltenen Signale enthalten jeweils die Signalsamples des Ursprungssignals, bei welchen „ui32Id“ bzw. „ui32ObjectId“ gleich dem jeweiligen Index sind. Die Anzahl der erzeugten virtuellen Signale pro aufzuspaltendem Signal kann über die Option „Anzahl der Demultiplexsignale“ eingestellt werden.

Zur Überwachung der Zustände der Teilnehmer können die Tooljobs GetParticipantState und GetAggregatedState verwendet werden. Über GetParticipantState kann der Zustand eines im genutzten Metamodell angegebenen Teilnehmers abgerufen werden. Durch GetAggregatedState wird ein aus den Zuständen aller im Metamodell angegebenen Teilnehmer aggregierter Gesamtzustand abgefragt. Analog zu den genannten Tooljobs wird auch ein virtuelles FEP-Signal ParticipantStates zur Verfügung gestellt, welches die aktuellen Zustände der FEP-Teilnehmer sowie den aggregierten Gesamtzustand („_Aggregated“) enthält.

Info

Bei der Nutzung des Signals ParticipantStates ist Folgendes zu beachten:

Das Signal ParticipantStates wird periodisch einmal pro Sekunde gesendet. Dieses Signal enthält jeweils die zur Sendezeit des Signals zwischengespeicherten Zustände der Teilnehmer. Durch die asynchrone Aktualisierung der zwischengespeicherten Teilnehmerzustände können kurzzeitig Unterschiede zwischen den Signalwerten und den wahren Teilnehmerzuständen auftreten.

Zeitmodi

Die Toolanbindung unterstützt ecu.test-seitig den Echtzeit- und den kontinuierlichen Simulationszeitmodus (siehe Zeitmodus). Das angesteuerte FEP-System kann in einem der FEP-2-Timing-Modes (AFAP, SYSTEM_TIME, EXTERNAL_CLOCK) oder in den FEP-3-Timing-Modes Continuous Timing bzw. Discrete Timing with Distributed Scheduling laufen.

Standardmäßig aktiviert diese Toolanbindung den kontinuierlichen Simulationszeitmodus. Dieser stellt in allen 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.

Im kontinuierlichen Simulationszeitmodus ist die Auflösung, mit der die FEP-Zeit ecu.test zur Verfügung stellt wird, anpassbar. Die Anpassung erfolgt über die TBC-Eigenschaft Zeitraster. 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

In den FEP-2-Timing-Modes SYSTEM_TIME mit fSpeedFactor = 1.0 bzw. EXTERNAL_CLOCK wird empfohlen, das Zeitraster am Minimum der Zykluszeiten der StepListener im FEP-System auszurichten.

Für den FEP-3-Timing-Mode Discrete Timing wird empfohlen, sich am Wert der CycleTime_ms-Einstellung des Timing-Masters zu orientieren.

In allen anderen Konstellationen, aber auch 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 fSpeedFactor (bzw. TimeFactor_float bei FEP-3-Timing) des FEP-Systems geteilt durch die Zeitraster-Einstellung. 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-2-Timing-Modes SYSTEM_TIME mit fSpeedFactor = 1.0 und EXTERNAL_CLOCK bzw. für die FEP-3-Timing-Modes Discrete Timing mit TimeFactor_float = 1.0 oder Continuous Timing geeignet, da andernfalls die Zeiten im Testfall und im FEP-System auseinanderlaufen.