Vector: CANoe / CANalyzer¶

Vendor information

Categories

Data sources

Signal recordings 🛈

Platform

Ports¶

Specifics¶

Notes regarding system and environmentvariables

Access from ecu.test to system variables, whose name or namespace starts with an underscore, can possibly be read only.

When writing system variables, you must provide a value of the correct type. In particular, writing an integral number (without a decimal point) into a system variable of type Double is not possible. Instead, a floating point number must be specified (i.e. 3.0 or float(3) instead of 3).

System variables and environment variables of type Data are not accessible via the Model access tab in ecu.test. Instead, you can use the Tooljobs ReadSysVar and WriteSysVar. The values must be given as tuples or lists of numbers. For environment variables, the numbers must be in unsigned-int8 format (between 0 and 255, inclusively). If the value written does not end with a 0, CANoe/CANalyzer will automatically add a trailing zero. For system variables, however, the signed-int8 format is required (between -128 and +127), and no trailing zero gets added.

Notes regarding recording

There is no support for explicitly recording system variables or environment variables. However, when a bus recording is performed, system variables and environment variables are implicitly contained in the recording file. Therefore, you can drag additional system variables and/or environment variables into a bus recording. You only have to make sure there are more signals from one bus than system variables or environment variables, so ecu.test will perform a bus recording with additional system variables and/or environment variables, rather than try a variable recording.

In order to record anything, ecu.test needs to create its own recorders in the online measurement setup. This is only possible when the measurement is not running. If at least as many recorders created by ecu.test exist as there are signal recording groups in the test case, these can be re-used even when the measurement is running.

Recordings can only be started when the measurement is already running, and they should be finished before stopping the measurement. In particular, this means that if the Start of measurement in the test bench configuration is set to Manually, the Auto-Start-Stop function of the recording group cannot be used, but rather the test steps StartTrace () and StopTrace () need to be called before/after the Jobs StartMeasurement and StopMeasurement, respectively.

Notes regarding CAPL functions

For calling CAPL functions with ecu.test there are some restrictions:

• All CAPL functions used in the test case must be registered at the start of measurement.

  For this to work, the measurement needs to be started by ecu.test, either automatically upon test start, or explicitly via Job StartMeasurement. If the measurement is already running and does not get influenced by ecu.test, said CAPL registration can not be performed.

  ecu.test automatically tries to determine the names of all CAPL functions called via the CallCAPLFunction job in any test case, in which the measurement gets started automatically or explicitly, and will register them.

  If the names of CAPL functions are determined only at runtime, or the measurement gets started in one test case, and CAPL functions are used in a different, later test case, they cannot be detected automatically. In this case, the job RegisterCAPLFunction must be used.

• Only arguments and return values of the type long are possible. For other types, the behavior is undefined: Error messages and/or bogus values may occur.

• CAPL functions which return a value must be placed in the measurement setup in CANoe. When placed in the simulation setup, nonsense is returned instead of the intended return value.

• When changing the CAPL source code, you must manually click compile all nodes in CANoe/CANalyzer.

Notes regarding bus databases

Please make sure that the same bus database is also specified in CANoe or CANalyzer because it is not automatically stored by ecu.test.

FlexRay channels A and B (restriction applies to Fibex only)

If CANoe/CANalyzer is used with a FlexRay, where both channels A and B are active, then ecu.test must be configured the following way:

• In the test bench configuration, two BUSACCESS ports must be configured under the tool CANoeCANalyzer, which reference the same channel in CANoe/CANalyzer.

• In the test configuration, under Bus access, two bus systems must be configured, which reference the same bus data base.

• Under Channel, one of each channel must be selected.

• As Active node, choose one of the bus ports each.

Note regarding test modules

Test modules can be executed by means of the test step CANoe Test Module Runner

Stop of measurement on reconnect

If the connection between ecu.test and CANoe/CANalyzer is closed and rebuild, the measurement is briefly halted. If, however, the active configuration in CANoe/CANalyzer is kept on reconnect, the running measurement is not stopped, provided that the Start of measurement in the test bench configuration is set to Manually and the option On Disconnect is set to Do not exit tool.

Note regarding XIL-API

Mandatory software

• Vector CANoe XIL API

• ASAM AE XIL Standard Assemblies 2.0.1 and above

Settings for each CANoe configuration

File Tab ‣ Options ‣ Extensions ‣ XIL API & FDX Protocol

• Enable XIL API Server

• Enable FDX

• Create and link FDX file

FDX files

Using the XIL-API, ecu.test can only access signals and variables from CANoe if they are part of an FDX file. Such a file can be created and linked in CANoe at File Tab ‣ Options ‣ Extensions ‣ XIL API & FDX Protocol.

All entries in the FDX are later available in ecu.test as model variables.

*.MAPort.xml

If accessing CANoe using the XIL-API, a *.MAPort.xml is necessary in addition to the CANoe configuration (*.cfg). This file determines the CANoe configuration to be used and configures the groups in FDX files.

The path to this file has to be configured as Model directory (see above). Afterwards you can select the .MAPort.xml to be used as the model file in the test configuration.

Notes regarding the generic bus port

The bus port can read and manipulate bus signals via model variables. These model variables originate from the FDX and are mapped to the bus signals using a custom mapping (see above). The corresponding syntax is described in the following section.

Porttyp BUSACCESS (GENERIC)

Bus port for access to the rest bus simulation of the environment model. The representation of signal/message names on model paths can be largely configured by means of path patterns. The representation of CRC and ALIVE signals is configured separately. CRC and ALIVE signals can be recognized by the prefixes “CRC” or “ALIV” in the signal names.

Path like properties might contain certain placeholders. Those will be automatically replaced when accessing bus signals. A placeholder always begins with the character “%” and is enclosed by parenthesis, like so: %(<placeholder>). The closing parenthesis has to be followed by a formatter.

Available placeholders

bus

Name of the bus

node

Name of the control unit

frame

Name of the message / frame

frameId

Numeric ID of the message / frame

CAN: CAN ID FlexRay: Slot ID

pdu

Name of the PDU / subframe

signal

Name of the signal

cycleRepetition

FlexRay only: The number of cycles after which a frame is sent again

baseCycle

FlexRay only: The first communication cycle in which a frame is sent

segmentType

FlexRay only: “Dynamic” if the current slot id is greater than the number of static slots, else “Static”

signalGroup

Name of the signalgroup

multiplexer

Multiplexer switch code (for example _DP_m4), if the signal belongs to a multiplexed PDU

Formatters

The placeholders can be formatted using the following formatting rules:

s

placeholder is just replaced, case sensitive spelling of value to be replaced remains unchanged

us

replaced value is completely converted into upper-case letters

ls

replaced value is completely converted into lower-case letters

d

replaced value is represented in decimal format

x

replaced value is represented in hex format with lower-case letters

X

replaced value is represented in hex format with upper-case letters

4x

replaced value is expanded to 4 digits with leading zeros (number of digits can be changed, and combination with X or d instead of x is also possible)

Marking parts of a path as optional

It is possible to mark certain parts of a path as optional. A part is optional if it:

• is placed between squared brackets and

• it contains at least one place holder

An optional part will be left out if any of the contained placeholders is evaluated to an empty string.

For example: A TX path has been configured as /can/[%(signalGroup)s/]%(signal)s/Value. Assuming a signal “A” belonging to signal group “sign_group”, manipulating it will result in the following model path: /can/sign_group/A/Value. The optional part is kept in the final path. But if the signal is not in a signal group, the path will result in /can/A/value.

Tx-Switch Path

The Tx-Switch path is used to de/-activate the manipulation of signals. The Switch path signal is set to the following values, to control the manipulation of the target signal:

• 0: if the target signal is not manipulated

• 1: if the target signal is written in Representation Physical conversion

• 2: if the target signal is written in Representation Raw value

If Ignore missing *-Tx switch path is set, the Tx-Switch path may be non-existent. The target signal will still be written with the desired value.

Properties 🛈¶

Jobs 🛈¶

CallCAPLFunction¶

Calls a CAPL function. This function can only be called when the measurement is running. The CAPL function must be registered before starting the measurement, e.g. with RegisterCAPLFunction.

ChangeCfg¶

To load a configuration file

ChangeVTCFG¶

Load a VT configuration file. The file needs to be present on the tool host. If a measurement is running, it needs to be stopped before executing the job.

GetCurrentCfg¶

Returns the path of current loaded cfg file in CANoe/CANalyzer.

IsMeasurementRunning¶

Inquiry whether measurement is running

ReadEnvVar¶

Reads an environment variable

ReadSysVar¶

Reads a system variable

RegisterCAPLFunction¶

Registers a CAPL function. This function can only be called when the measurement is not running.

StartMeasurement¶

Starts the measurement.

StopMeasurement¶

Stops the measurement

WriteEnvVar¶

Writes an environment variable

WriteSysVar¶

Writes a system variable