FEP3

Legacy/internal identifier: FEP3

Vendor information

Vendor

Web page

Product name

Version

Functional Engineering Platform

3.0

Categories

MDL 🛈

APL 🛈

BAN 🛈

BMA 🛈

SVC 🛈

DGN 🛈

FIU 🛈

EES 🛈

FCT 🛈

DBG 🛈

IMG 🛈

AUDIO 🛈

ENVSIM 🛈

ENVCOM 🛈

✓

Platform

Operating system

Support

Windows

✓

Linux

Ports

Specifics

This tool connection provides:

  • Reading and writing properties of the participants

  • Reading and writing signals on the simulation bus

  • Recording of signals with subsequent trace analysis

  • Controlling the system state (Initializing, Start, Stop, …)

Prerequisites

The following conditions must be met in order to use this connection:

Environment variable

For this connection to appear in the list of available tools in ecu.test, the environment variable FEP3_PARTICIPANT_COMPONENTS_FILE_PATH must be set on the used tool host. It must contain the absolute path of the FEP Component Configuration File (*.fep_components) to be used. Details on this file and the component approach that FEP participants are based on can be found in the FEP User Documentation and in the documentation included in the FEP SDK.

Launch of the FEP system

The FEP system to be controlled must already be deployed and launched. This may require external tooling (FEP Agent, FEP Access, FEP Control etc.).

System description

The path to the system description file of the FEP system is specified in the test bench configuration. To enable ecu.test to read the system description and make its contents available in the model access tab, all relevant information must be located in the same folder.

These are the following files:

  • System description file (*.mm3_system.yml)

  • Element description files (*.mm3_element_type.yml)

  • DDL information (*.description)

The element description files must have the same file name as their conan reference in the system description file.

Sample snippet from a system description file:

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

In this case the element description file must have the file name fep_simple_car.mm3_element_type.yml.

Participant priorities

When initializing or starting the FEP system, ecu.test applies the init and start priorities as specified in the system description file (participants with larger number are started before participants with smaller number, negative numbers are allowed). Additional participants added by the user but not listed in the system description file are assigned priority 0. The same applies for additional participants added by ecu.test to control and monitor the FEP system.

It is up to the user to properly set the init and start priorities of the participants in the system description according to their mutual dependencies. Note that the additional participants not listed in the system description must usually be initialized or started after the participants specified in the system description. Also note that the timing master must usually be the last one in this sequence. All this can be easily realized by assigning a negative priority to the timing master and only priorities >0 to the other participants in the system description.

Limitations

Please note the following limitations when using this connection:

System properties

Property values that can be specified for the individual participants in the system description file (esp. timing configuration and signal renamings) are not automatically applied by ecu.test. This may require external tooling (FEP Access, FEP Control etc.).

Reading and writing FEP signals

All signals listed in the model tree of ecu.test in the first level under the node Signals are FEP signals. If one of these signals can be expanded further, it is a complex signal with one or more sub-signals, also called elements. Read and write test steps always refer to one of these signal elements. Thus, reading or writing of multiple elements of a signal requires multiple test steps.

If multiple elements of a signal are read out, it is not guaranteed that the obtained values of the elements originate from the same signal sample.

Each time one of the elements of a signal is written, a sample of the entire complex signal is transmitted, with all other elements retaining their current values. These are the values from the most recent sample of the signal received or sent by ecu.test. If there is no recent sample, 0 or the value corresponding to the element memory completely filled with 0 is used as the current value.

If multiple elements of a signal are changed, each of the successive write test steps sends a complete sample of the complex signal.

Cyclic transmission and muting of FEP signals is not supported. If there is a participant in the FEP system that sends (cyclically) the same signal, the values sent by ecu.test will be overwritten.

Supported signal types

ecu.test only supports DDL signals whose structure is defined in a description file (stream_meta_type: "ddl-fileref"). RAW signals and other signal types are not supported.

Signal names

The renaming of signals must be statically defined in the system description file and the renaming scheme that is actually active in the INITIALIZED and RUNNING state must exactly match this specification. A different, dynamic definition or dynamic change of the renaming is not supported by ecu.test.

Info

The signal names that appear in the model tree of ecu.test result from the input and output specifications in the element description files and, if present, the signal renaming at the element instances in the system description file. Each of the displayed names is a signal name introduced by a signal renaming or / and the original name of an input or output for which no renaming is defined.

Trace recording

Only one recording group is supported for each signal group.

Each recording group can be started and stopped only once in a test case.

Trace recording of FEP signals is only possible if the FEP system is in state UNLOADED when the test case package is started, and is reset to state UNLOADED at the end of the test case. Therefore it is not possible to distribute the steps Load, Start, Stop and Unload across several test case packages (for example in a project) if FEP signals are to be recorded.

Timing Modes

On ecu.test side, the tool connection supports real-time and continuous simulation time mode (see Temporal behaviour). The controlled FEP system can be operated in the synchronized FEP timing modes Continuous Timing or Discrete Timing or can run unsynchronized (No Timing Master).

By default, this tool connection activates the continuous simulation time mode. This mode ensures in all (synchronized) FEP timing modes that test case time and FEP time run synchronously. The FEP timing mode used by the system is automatically detected.

The resolution at which the FEP time is fed into ecu.test in continuous simulation time mode is configured automatically. That means, if the FEP system runs in Discrete Timing mode, the time step size of the timing master is used. And for all other FEP timing modes, a resolution of 100ms is used by default. If required, the automatic setting of the resolution can also be deactivated in the test bench configuration and set to a user-defined value via the Time grid property.

The time grid determines the accuracy of test steps with time specifications. For example, a wait test step of 250ms would wait 300ms with a 100ms time grid. For high accuracy, the smallest possible time grid is desirable. However, small time grids increase the rate of timestamps to be processed by ecu.test, which is limited.

Info

In general, it must be ensured that the timestamp rate to be processed by ecu.test does not exceed 100 timestamps per second. The time stamp rate is the quotient of the TimeFactor_float property of the timing master divided by the Time grid setting in ecu.test. For example, a time factor of 2.0 (double real time) and a time grid of 50ms (0.05s) result in a rate of 40 timestamps per second.

In real-time mode, the test case time and the FEP time are not synchronized. The real-time mode is therefore only useful for the FEP timing modes Discrete Timing with TimeFactor_float = 1.0 or Continuous Timing or potentially for unsynchronized FEP systems (No Timing Master), because otherwise the times in the test case and in the FEP system would drastically diverge.