Tool categories¶

Tool categories provide, thematically separated, the configurable standard interfaces of ecu.test. Every tool category allows reading description files and provides user-friendly dialogs for configuring specific test steps as well as the functions for execution and for the test report.

Model access - Model simulation¶

The tool category model access is used for tests carried out in a HiL. The system environment of existing components is simulated by means of a real-time model.

A HiL environment provides clearly better possibilities of simulating events than do, for example, tests in a vehicle. Test steps for reading and modifying model quantities are offered for the generation of test cases.

Applicable peripheral software:

• dSPACE ControlDesk

• NI Veristand

• OPAL RT-LAB 8.4

• Vehinfo LABCAR Operator

• Tool_QUANCOM

• EA UTA12

Furthermore, model access is used for MiL and SiL tools, such as:

• MATLAB/Simulink (MiL)

• FMI tool adapter (SiL)

Usage:

• Model access tab

Application - application access¶

The tool category application allows application access to the existing control units participating in the test by means of the two variants measurement and calibration. Measurement provides test steps for reading access to internal control unit quantities whereas calibration offers both reading and writing access to system constants as well as characteristic curves and diagrams.

Classification in measurement and calibration follows the standard ASAM MCD-2MC (ASAP2) that makes a distinction between measurement and calibration quantities.

Peripheral software used:

• ETAS INCA

• Vector CANape

Usage:

• Measurement tab

• Calibration tab

Diagnostics - diagnostic communication¶

The Diagnostics tool category provides the options for executing diagnostic services on the ECUs. These services can be used to query status values, control components and read out the fault memory.

Functions of this tool category can be used in three different ways:

Diagnostics

With this type of access it is possible to perform UDS diagnostics via CAN. Communication is based on the support for hardware-related bus connections. Besides the device driver for the hardware interface, no additional software is required. Under Diagnostics tab you will find an overview of the functions.

The following protocol standards are supported:

• UDS (ISO 14229-1)

• KWP2000 (ISO 14230)

• ISO-TP (ISO 15765-2)

• DoIP (ISO 13400)

• FlexRay TP (AUTOSAR FrTp, ISO 10681-2)

• OBD DTC Definitions (ISO 15031-6 / SAE J2012)

• SAE J1939

Diagnostics(EDIABAS)

This type of access is specially designed for the basic EDIABAS. Under Diagnostics(EDIABAS) tab you will find a function overview.

Diagnostics(DTS)

This access mode enables the ASAM MCD-2D/3D compatible control of the diagnostic tool Softing: DTS. Under Diagnostics(DTS) tab you will find a function overview.

Raw diagnostics with KWP2000 over ISO-TP¶

Besides, the close-to-hardware CAN bus connections allow carrying out diagnoses with KWP2000 via ISO-TP (ISO 15765-2). For that purpose the corresponding diagnostics bus ports provide the port jobs OpenKwp2000overIsoTpSession, CallService and CloseSession

First you call the port job OpenKwp2000overIsoTpSession. Parameters to be entered are request and response ID (CAN message IDs for diagnostics requests and responses). All other parameters are optional. The return value of that call serves as identification characteristic for the diagnostic session just opened. It has to be used for later calls of CallService and CloseSession; this is why it should be stored in a variable.

In order to call a diagnostic function you call now the port job CallService. It is necessary to enter, in addition to the session ID (received as return value from tooljob OpenKwp2000overIsoTpSession), a request in the form of a ByteStream. As an option you can enter a timeout (in ms). The return value is a DiagResult object.

The execution of the port job CallService is completed immediately, even if the transmission of the request for diagnostics or the wait for response are still going on in the background. Only at the moment of reading access to the DiagResult you have to wait until the result appears.

Bus communication¶

The tool category bus access provides the functions required for sending and receiving PDUs on bus systems. This is necessary, in particular, for testing functions which are distributed across several control units.

Applicable peripheral software:

• ETAS INCA

• IXXAT

• IXXAT-RBS

• PEAK

• VECTOR

• Softing DTS

• NI Veristand

Usage:

• Bus access tab

• Service tab

The close-to-hardware bus tool adapters offer some additional functionality:

Automatic E2E calculation¶

Für E2E profiles 1, 2, 4, 5, and 7, ecu.test offers an option to automatically calculate the E2E signals Data-ID(-Nibble), DataLength, Counter, and CRC (if applicable for the respective profile). In order for that to happen, set a placeholder value in the test bench configuration, and in the test case, assign this value to those E2E signals that shall be auto-filled.

Mini residual bus simulation¶

For CAN, CAN FD and FlexRay a limited residual bus simulation is available. For that purpose, it is necessary to create a port of type BUSACCESS in the test bench configuration with implementation type CAN, CAN-FD or FLX, respectively. In the test configuration it should be selected as point of manipulation.

Now, on the Bus access tab, for a PDU the option Change PDU timing can be chosen in order to activate the cyclic transmission of that PDU. With Change PDU timing the cycle time can be varied and the cyclic transmission of the pdu can be activated or deactivated. The content of the PDU may be modified at any time (also before switching on the cyclical transmission) by changing some signals via Write (see section Bus access tab).

The PDU is transmitted cyclically with the configured data. The configuration can be altered without restarting the cycle. At the same time the activation state of the PDU remains unchanged.

Calculated frames and signals

When using the Mini residual bus simulation, in the test step Write signal group for CAN, CAN FD or FlexRay it is possible to specify a python object that determines the frame or signal value. Using this, it is possible to evaluate valid signal values dynamically (e.g., for checksums or alive counter signals).

The calculation class has to be implemented in Python and has to be stored in the User-defined Python functions directory in a sub-directory named BusCalcFunctions. A skeleton of calculation classes can be generated automatically by right-clicking a PDU in the Bus access tab and choosing Create calculation classes. Please refer the generated code in order to learn how you have to implement this class.

The frame calculation object can only be used in the Mini residual bus simulation. To use an instance of this class for a specific PDU, specify it in the input box Calculation object in the test step Change PDU timing. (E.g., user.BusCalcFunctions.MyProject.MyCalculationObjects.Calculate_MyFrame() if the class is defined in a project named MyProject and a module named MyCalculationObjects and is called Calculate_MyFrame. The project is an optional parameter and is represented by a subdirectory in BusCalcFunctions)

If you want to specify a calculation object to calculate the raw value of only a specific signal, specify it in the test step Write or Write signal group.

For accessing a calculation class e.g. for instantiation, please refer User-defined Python functions.

Support for PDUs with multiplexers

If CAN, CANFD or FlexRay PDUs with multiplexers are used, it is possible to set the multiplexer value in different ways:

• It can be set in the respective signal calculation method in the calculation class.

• It can be written explicitly in a package (via Write signal group). Then, the PDU is sent with this multiplexer value until a new value overwrites it.

• It uses the multiplexer value of the activated PDU. If several PDUs are activated, ecu.test cycles through their respective multiplexer values.

Mini residual bus simulation with complex signal flows

As an extension to the Mini residual bus simulation it is possible to create complex signal flows on the bus, based on stimuli files. These signal flows can be created with the Signal Editor. To connect the bus signals with the signals from the stimuli file, the test step Start Stimulus is used. Please note that only signals which belong to the same bus can be combined in a call of the test step. This applies to both input and output signals. All signal values are considered as physical values. Care must be taken that the mapping element for the relevant bus signals must have set the option Manipulation. To enable or disable a PDU the test step Change PDU timing must be used. When using the empty segment the signal raw value is set to 0.

Additional functions of the close-to-hardware bus connections¶

Reading Frames with additional information

The port job ReadFrameEx returns a CanFrame, FlexRayFrame or LinFrame object, which can be stored in a variable. Afterwards you can (e.g. with a calculation step) access the properties enumerated below. Not all implementations fill all property slots. The values 0 and False can also occur if the respective property cannot be evaluated by the implementation.

Streaming of messages into an inbox

The port type BUSACCESS possesses in combination with the implementation types CAN, FLX and LIN the Port jobs RegisterFrameForInbox and DeregisterFrameForInbox. With these jobs it is possible, if the hardware is connected via Tool Server, to link one or more messages with an inbox that needs to be created as variable or to remove this linkage respectively. After registering messages received from the bus are automatically filed into the inbox data structure and can be processed from there (see Inbox and “Read from inbox”). This enables the lossless evaluation of messages in the test case. In addition to the identifiers for a message, that vary for CAN, CANFD and FlexRay and are deposited as job descriptions, the job RegisterFrameForInbox contains the parameter saveAsCanFrame, saveAsFlxFrame or saveAsLinFrame, respectively. Is this one activated the messages are filed as CanFrame, FlexRayFrame or LinFrame object, respectively. Otherwise only the payload of the message is saved as ByteStream object.

Raw diagnostics

See section Raw diagnostics with KWP2000 over ISO-TP.

Service access¶

The service access tool category allows access to SOME/IP services. It enables usage of methods, events, as well as their parameters.

Applicable tool adapters:

• tracetronic: Ethernet

• Vector: XL API

• Vector: SIL-Kit

• dSPACE: ControlDesk Service-Manager

Usage:

• Service tab

Simulation of services¶

In addition to accessing services offered by control units, ecu.test can also itself provide services for the control unit(s) under test to use.

For that purpose, first python modules have to be generated, which implement the behavior of the methods and events offered by each pertinent service. By editing these modules, the behavior can be adapted:

• For each method and event, the structure of its input and output parameters is documented in the header of the method implementing it. You can extract data from input parameters and fill values into the initially empty output parameters.

• You can set the interval for cyclic events.

• You can add your own methods to change data or behavior to the ServiceInstance class, which you can later call from the test case.

Subsequently, the service API can be used to control the simulation.

In the testbench configuration you can select simulated services to be started automatically with the test case (without having to call the respective API function), and set up the simulation to continue after the end of the test case in which it was started.

Low-Level Simulation

Sometimes it is necessary to simulate other network services besides SOME/IP. For this purpose, ports of lower network layers offer a job StartSendPacketCyclic. By means of this job, a custom sequence of bytes can be transmitted cyclically. There are two ways to define the payload: You can pass a static ByteStream object (e.g. ByteStream('11:22:33')), or a self-defined object. For the second case, a callable class must be defined in a *.py file under WORKSPACE/UserPyModules/CyclicPayloadFunctions/. In the following example a class was created in WORKSPACE/UserPyModulesCyclicPayloadFunctions/SimpleCyclicFunction.py.

from tts.lib.dataStructures.ByteStream import ByteStream


class SimpleCyclicFunction:
    def __init__(self, a="11", b="22", c="33"):
        self.a = a
        self.b = b
        self.c = c

    def __call__(self, *args, **kwargs):
        return ByteStream("{0}:{1}:{2}".format(self.a, self.b, self.c))

As the payload, you can now pass an instance like user.CyclicPayloadFunctions.SimpleCyclicFunction.SimpleCyclicFunction('11', '22', '33'). When creating the class, it must be ensured that a default value is specified when using parameters. Furthermore the __call__ method must be overridden and return a ByteStream object.

Debugging¶

The debugging tool category enables access to debugger tools.

Applicable peripheral software:

• Universal Debug Engine

• Lauterbach TRACE32

Usage:

• Debugging tab

Function access¶

The tool category function access allows synchronous/asynchronous execution of simple external functions (e.g. from a DLL). Only basic data types and strings are supported as arguments and return values.

Configuration:

• Platform tab

• VI Integration

Usage:

• Function access tab

Failure simulation¶

Failure simulation means that electric failures are created in a control unit. Normally those failures are displayed by entries in the failure control unit memory. Failures which can be simulated are:

• An interrupted cable or a loose contact leading to a sensor/actor

• A short circuit to ground or voltage

• Connecting pins via a common bus bar

Configuration:

• Platform tab

Usage (EES):

• Electrical Error Simulation (EES)

• Error Simulation via bus hardware (CANway)

Usage (FIU):

• Electric failure simulation

Specific test steps¶

The tool category test steps provides a wide range of test functions, such as test run control by loops, pauses and conditional execution, data operations, steps for test structuring, the creation of electrical failures at hardware pins and further specific implementations. All test steps are specialized parts of the tool category by the same name. This makes it easy to implement further user-specific functions and integrate them as plugins into the existing installation of ecu.test.

Usage:

• Test steps tab

Multimedia access¶

The tool categorie “Multimedia access” provides access to a video device - for example a webcam. Images and parts of images can be compared, manipulated using user defined filters and saved in the report.

Configuration:

• Media Access Tab

• tracetronic: Multimedia

Usage:

• Reading and comparing images

• Touch input

• Reading and comparing audio recordings

• Output of audio signals

Extension:

• Defining masks

• Image filters

• User defined speech output

Environment simulation access¶

For the testing of complex driver assistance systems and autonomous driving, new requirements arise for test methodologies and test tools. Thereby the importance of the simulation of the vehicle environment continues to increase. With environment simulation tools the environment can be modeled and used within tests.

The environment usually consists of:

• the route (road geometry, road surface, road signs, traffic lights, trees,…)

• the involved actors (ego vehicle, other vehicles, pedestrians, etc.)

• the concrete actions or manoeuvres of the actors (e.g. a cutin scenario)

The tool category “Environment simulation access” allows to start, configure, parameterize and controll environment simulation tools.

Configuration:

• Tab Environment

Usage:

• Environment Simulation

Environment communication access¶

The environment communication access tool category provides access to environment information by receiving message-based communication.

Configuration:

• Tab Environment

Usage:

• Environment communication access