Vector: CANoe / CANalyzer

Legacy/internal identifier: CANoeCANalyzer

Vendor information

Vendor

Web page

Product name

Version

Vector Informatik GmbH

http://www.vector.com

CANoe / CANalyzer

from 10.0, tested up to 18SP2

Categories

MDL 🛈

APL 🛈

BAN 🛈

BMA 🛈

SVC 🛈

DGN 🛈

FIU 🛈

EES 🛈

FCT 🛈

DBG 🛈

IMG 🛈

AUDIO 🛈

ENVSIM 🛈

ENVCOM 🛈

✓

✓

✓

Data sources

File format

Comment

*.dbc

CAN-DBC

*.xml

Fibex (ASAM MCD 2 NET)

*.arxml

Autosar XML

*.MAPort.xml

MAPort configuration file

Signal recordings 🛈

File format

Comment

*.blf, *.csv, *.mdf, *.mf4

Platform

Operating system

Support

Windows

✓

Linux

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 (StartTrace_Symbol) and StopTrace (StopTrace_Symbol) 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

Note regarding XIL-API

Mandatory software

  • Vector CANoe XIL API

  • ASAM AE XIL Standard Assemblies 2.0.1 and above

Info

Please use the correct version of CANoe in XIL-API Server in the test bench configuration: Only the 64 bit version is supported.

Further information on setup can be found at How to Troubleshoot XIL API Issues.

Settings for each CANoe configuration

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

  • Enable XIL API Server

  • Enable FDX

  • Create and link FDX file

Info

Please follow the instructions in the CANoe users manual at section CANoe ‣ ASAM XIL API ‣ Model Access Port

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.

Info

If using multiple groups in an FDX file, please check their proper configuration in the .MAPort.xml

*.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.

Info

Please check the CANoe users manual at section CANoe ‣ ASAM XIL API ‣ Model Access Port

Notes regarding the generic bus port

Info

The generic bus port can only be used together with the XIL model access 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.

Info

A valid expression could be e.g %(signal)s, where “signal” is a placeholder and “s” is 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

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.