MTF Configuration File

Overview

The configuration file in a YAML format is essential for the MTF framework because MTF requires assigning logical channels to physical channels to specify which hardware interface or channel should be used for data reception and transmission. The configuration file defines this assignment, ensuring proper communication between the ECU(s), the test bench, and other connected components.

The configuration file should clearly represent the entire setup, showing how different elements—such as tracers, logical channels, physical adapters, and devices—are connected. However, this file does more than just listing these components; it also links them together so they can work as a system.

One key benefit of using this configuration file is that it allows the same test cases to run on different setups. To adapt to a new setup, users only need to update the physical channel information, keeping the logical channels and test cases unchanged. This supports the framework’s main goal of abstraction, which simplifies hardware management. Instead of specifying the exact physical channel a device is connected to, test cases can refer to a logical channel name, and the MTF will handle the rest.

File structure

This configuration file is composed of three main sections:

Channels:

The Channels section is mandatory, even for the simplest test cases. It defines logical channels using several fields, such as name, Id, Type, ect. A channel can, for instance, be a bus, an I/O (input/output) interface, a serial port, etc.

Mappings:

The Mappings section is also mandatory. It maps logical channels to physical channels. It varies depending on the device being mapped to.

FrameworkConfig:

The FrameworkConfig section is optional. It defines traces configuration, internal modules configuration, etc.

Note

The order of the configuration file sections does not affect how the YAML file is interpreted. The order used in this guide is preferred for clarity and for easily creating the file from scratch.

Section 1: Channels section

Overview

The first step in creating the MTF configuration file is to define the channels section. This section describes logical channels, which will later be linked to real (physical) channels in the mapping section.

A logical channel is an abstraction, meaning it is a virtual representation of a real hardware channel. It appears in the configuration file as an entry that the test framework later connects to a physical channel. Physical channels can be of different types, such as bus interfaces (e.g., CAN, LIN), I/O lines, or serial ports.

Before defining the channels, you should be familiar with the available hardware in your test bench, because as explained, each logical channel you create should reflect a real physical channel in your system. However, you don’t need to include all hardware channels; just define the channels required for the test case. In other words, you can optimize the YAML file by not including channels for devices that are not involved in the current test. This way, the configuration depends on both the hardware setup and the specific test case.

Therefore, it is important to use clear and meaningful names. For example, if you have a CAN bus, name the logical channel something like “can_ch1” or “can_cluster_name”. The name should clearly indicate that it is a CAN channel.

A detailed explanation of all fields and configuration options is provided under the following titles. The information above serves as overview to understand the first section

Section structure

In YAML, data is stored as key-value pairs: you write a key (the name or label), a colon, then its value. Values can be simple (strings, numbers) or nested (dictionaries).

The Channels section is itself a top key-value pair:

Key: Channels
Value: a dictionary of logical channels

Channels:
 CAN_channel:
  Id: 1 # <-----(Required)
  Type: CAN  # <------(Required)
  Protocol: CAN2.0 # <-------(Optional)
  loggingName: CAN_channel # <--------(Optional)
  Alias: [Ch_CAN, Chan_CAN] # <---------(Optional)
  TracerName: ASCII_Tracer_CAN # <----------(Optional)
 CAN_FD_channel:
  Id: 2
  Type: CAN
  Protocol: CANFD
  Alias: [Ch_CAN_FD]
  TracerName: ASCII_Tracer_CAN
 ETH_SOMEIP:
  Id: 3
  Type: ETHERNET
  TracerName: PCAP_Tracer_SOMEIP

Under Channels (indented one space), each logical channel is defined by a custom name. That name is the key, and its value is another dictionary of properties.

Channels:
 CAN_channel:

Within each channel (indented one space under the channel name), list every property as its own key-value pair.

Channels:
 CAN_channel:
  Id: 1
  Type: CAN

Since YAML relies on indentation to recognize and show hierarchy, consistent spacing is important. To avoid formatting issues, it is best to use spaces instead of tabs.

Finally note that the order of the properties does not affect how the configuration is interpreted.

Note

All field names are case-sensitive. Ensure consistent spelling and casing to avoid parsing errors or unexpected test results.

Field descriptions

Below is a detailed explanation of the fields and sub-fields of the channels section:

‘ChannelName’: This field is mandatory and represents the logical channel name The name must be unique and meaningful, either using the names from the database clusters or reflecting the protocol/type of the channel. You can use numbers(but not at the start) and underscores (no space), or any format that suits your needs. Examples: Eth_ch, CAN_ch, CAN2_ch, ect
Note

Note1: If the user needs to set or listen to an AUTOSAR PDU or Signal PDU, the logical channel’s name must match the channel name defined in the loaded Communication Matrix via the database file.

Note2: In case of ethernet network access (e.g., PduTransport signals, SomeIP message parameters): Other channels can be configured for listening. A typical use case involves having an Capture module (CM) connected. MTF will search for these channels in the following order:

A channel with a name (or one of its aliases) matching “ETH-SOMEIP-SPY” for SomeIP listening, or “ETH-NPDU-list” for PDU Transport listening.

Channels with a name (or one of its aliases) starting with the original channel name plus the suffixes -SPY or -PORT, e.g., MY_ETHERNET_CHANNEL-SPY_1, ETH_CHANNEL-SPY_2, or MY_ETHERNET_CHANNEL-PORT_1, ETH_CHANNEL-PORT_2.
- Id: This field is mandatory and represents the unique ID (user-defined).
- Alias: This field is optional, and allows you to assign one or multiple alternative Names to the logical channel for use in multiple test cases. The same naming rules apply to aliases. For example, CAN_channel can have aliases like Ch_CAN or Chan_CAN.
  Note
  
  Note1: If the user needs to set or listen to an AUTOSAR PDU or Signal PDU, one of the logical channel’s aliases must match the channel name defined in the loaded Communication Matrix via the database file.
  
  Note2: In case of Ethernet Network Access (e.g., PduTransport signals, SomeIP message parameters): Other channels can be configured for listening. A typical use case involves having an Capture module (CM) connected. MTF will search for these channels in the following order:
  
  One of the channel aliases matching “ETH-SOMEIP-SPY” for SomeIP listening, or “ETH-NPDU-list” for PDU Transport listening.
  
  One of the channel starting with the original channel name plus the suffixes -SPY or -PORT, e.g., MY_ETHERNET_CHANNEL-SPY_1, ETH_CHANNEL-SPY_2, or MY_ETHERNET_CHANNEL-PORT_1, ETH_CHANNEL-PORT_2.
- Type: This field is mandatory and specifies the protocol used for the communication over the corresponding physical channel. The available options include:
  For CAN Channels: CAN, CAN-FD
  
  For LIN Channels: LIN
  
  For FlexRay Channels: FR, FLEXRAY
  
  For Ethernet Channels: ETHERNET
  
  For IOs Channels: IOOUTPUT, IOINPUT
  
  For Serial Channels: IOSERIAL, SERIAL
  
  For PowerSupplies Channels: PS
  
  For Bridge Channels: BRIDGE
- Protocol: This field is mandatory in cases of complex hardware architecture(if the logical channel is a bus system). In those cases, the protocol version may need to be specified to support additional hardware or a specific type of hardware.Examples of protocol versions include:
  
  Type
  
  Protocol
  
  CAN
  
  CAN2.0
  
  CAN-IB500
  
  CANFD
  
  CANFD
  
  CANFD-IDENTICAL-ArbPh-DataPh (BRS = 0 for all Tx Request)
  
  LIN
  
  LIN1.2
  
  LIN2.3
- loggingName: This field is optional. It allows you to assign a specific logging name to the channel, which will be used during ASCII or PCAPNG tracing.
- TracerName: This field is optional. It defines the name of the tracer that is linked to the channel. This tracer is used for logging incoming and outgoing traffic or measurements data. For example, it allows tracing the traffic of a specific channel to a particular trace.
  
  The full tracer configuration is defined later in the third section: FrameworkConfig. In this Channels section, you only assign a tracer to each logical channel.
- LoggingBusIndex: This field is optional and specific to IO ASCII Tracing. It configures a specific logging index as shown in the example below:
  Channels: Channel_name: Id: 105 Type: IOINPUT LoggingBusIndex: 45
  If LoggingBusIndex is not configured, the logging index will be chosen in the following order:
  ID of the channel “Debug_CAN” or “Debug-CAN” if found (via its name or aliases).
  
  ID of the channel “IOs_logging_virtual_can” if found (via its name or aliases).
  
  An unused channel ID (the maximum of the configured channel IDs + 1).

Setup example

This is a step-by-step guide on how to create the channels section with a concrete example of a test bench architecture. Let’s assume you have these devices connected to your test bench via those channels, as shown in the image below:

Step1: Understand the setup and physical Connections

Connection

Type

Medium

Computer ↔ Switch ↔ CM and BTSEvo

Ethernet

RJ45

Capture Module CAN Combo ↔ BTSEvo

CAN bus 1

CAN cable

Capture Module CAN Combo ↔ BTSEvo

CAN bus 2

CAN cable

Capture Module CAN Combo ↔ BTSEvo

FlexRay

FlexRay cable (twisted pair)

Step2: Understand and define logical channels

A logical channel represents a unidirectional or bidirectional communication path between devices. Logical channels are defined in the configuration file to map the framework’s communication to the physical channels.

In this example setup you need:

1 Ethernet logical channel because all devices connected to the test bench are on the same network.

4 CAN logical channels because each CAN bus is represented by 1 TX and 1 RX pair total. This means, you don’t set up a send and receive channel for each device. Instead, you set them up for the whole CAN bus.

That’s because the two devices share the same bus and can send and receive on it. So you only need one channel for sending and one for receiving per bus.

2 FlexRay logical channels because each FlexRay bus is represented by 1 TX and 1 RX pair total as well.

Step3: Start the channels section

Begin with the “Channels:” Keyword. As explained above, this section will list each logical channel you want to configure.
Channels:

Step4: Add logical channels entries

As we explained, for this example we need :

1 Ethernet logical channel

4 CAN logical channels

2 FlexRay logical channels

A. Create the Ethernet logical channel

Ethernet_Switch:   #<-- Named after the switcher device connected to.
  Id: 8            #<-- User defined (unique)
  Type: ETHERNET
  TracerName: ETH_PCAP_Tracer   #<-- Link the channel to 'ETH_PCAP_Tracer'

B. Create the CAN logical channels for CAN bus1

We choose to transmit CAN-FD frames via CAN bus1.

CAN_FD1_ch1:   #<--It recieves/transmists CAN_FD frames.
  Id: 9   #<--User defined (unique)
  TracerName: ASCII_Tracer_CAN  #<--Link the channel to 'ASCII_Tracer_CAN'
  Type: CANFD
  Protocol: CANFD
CAN_FD2_ch1:
  Id: 10
  TracerName: ASCII_Tracer_CAN
  Type: CANFD
  Protocol: CANFD

C. Create the CAN logical channels for CAN bus2

We choose to transmit CAN frames via CAN bus2.

CAN1_ch2:   #<--It recieves/transmists CAN frames.
  Id: 11   #<--User defined (unique)
  TracerName: ASCII_Tracer_CAN   #<--Link the channel to 'ASCII_Tracer_CAN'
  Type: CAN
  Protocol: CAN
CAN2_ch2:
  Id: 12
  TracerName: ASCII_Tracer_CAN
  Type: CAN
  Protocol: CAN

D. Create the FlexRay logical channels

FlexRay_ch1:
  Id: 13   #<--User defined (unique)
  TracerName: ASCII_Tracer_FLEXRAY   #<--Link the channel to 'ASCII_Tracer_FLEXRAY'
  LoggingName: A_FlexRay
  Type: FR
FlexRay_ch2:
  Id: 14
  TracerName: ASCII_Tracer_FLEXRAY
  LoggingName: Ab_FlexRay
  Type: FR

Final result

Finally, the entire Channels section for this example would look like this:

Channels:
 Ethernet_Switch:
   Id: 8
   Type: ETHERNET
   TracerName: ETH_PCAP_Tracer
 CAN_FD1_ch1:
   Id: 9
   TracerName: ASCII_Tracer_CAN
   Type: CANFD
   Protocol: CANFD
 CAN_FD2_ch1:
   Id: 10
   TracerName: ASCII_Tracer_CAN
   Type: CANFD
   Protocol: CANFD
 CAN1_ch2:
   Id: 11
   TracerName: ASCII_Tracer_CAN
   Type: CAN
   Protocol: CAN
 CAN2_ch2:
   Id: 12
   TracerName: ASCII_Tracer_CAN
   Type: CAN
   Protocol: CAN
 FlexRay_ch1:
   Id: 13
   TracerName: ASCII_Tracer_FLEXRAY
   LoggingName: A_FlexRay
   Type: FR
 FlexRay_ch2:
   Id: 14
   TracerName: ASCII_Tracer_FLEXRAY
   LoggingName: Ab_FlexRay
   Type: FR

Section 2: Mappings section

Overview

After defining the logical channels in the “Channels” section, the next step is to map each one of them to a physical channel and actual hardware interfaces available in your test bench and selected for use in your test cases.

This is done in the “Mappings” part of the configuration file.

This connection allows the test framework to identify which hardware resource to use when a logical channel is referenced in a test case.

By doing so, you can write reusable test cases using logical names and easily adapt the configuration to different hardware setups by simply updating the mapping.

Mappings can be done for various types of devices, such as capture modules, power supplies, adapters, and more. In the following parts, we will explain how to map each device type in detail.

Section structure

The Mappings section of the configuration file starts with the keyword “Mappings:”.

Mappings:

Under “Mappings:”, each top-level entry (such as CM, BTS, PCAP, Manson_PowerSupply, Genesys_PowerSupply, ect) represents a hardware category or device type in your system. Each of these entries is indented with two spaces.

Each device type contains specific fields based on what is needed to describe that type:

CM has a “Devices:” field. Under it, you list each CM device using a number (1,2, ect) as a key. The number does not mean quantity but is a label for each individual device.
BTS has two fields:
- Boards
- EthernetConfiguration
PCAP lists the network adapters directly using numbers (1, 2, 3, 4) as keys.
Genesys_PowerSupply (or any type of power supply) has a “Channels:” field. Under it, each channel is listed by number (1,2, ect) and contains the configuration for that specific channel.
Serial has a “Ports:” field. They represents serial ports that will be used for serial communication.

VirtualDevices has a “Buses:” field. Buses represents virtual channels (not physical).

Mappings:
  CM:
    Devices:
      ....
  BTS:
    Boards:
      1:
      ....
      2:
      ....
      3:
      ....
    EthernetConfiguration:
        ....
  PCAP:
    1:
    ....
    2:
    ....
    3:
    ....
    4:
    ....
  Genesys_PowerSupply:
    Channels:
      1:
        ....
  Serial:
    Ports:
      ....
  VirtualDevices:
    Buses:
      ....

Mapping logical channel to a Capture Module

One example of the devices that can be mapped to logical channels is the Capture Module It is a device that records the data in vehicle communication systems. It is available in multiple types, each made to support different automotive protocols including CAN, CAN-FD, LIN, FlexRay, and Ethernet standards.

Some configuration fields are shared between different types , while others are specific to one type only.

Common fields

The following fields are shared between CAN and LIN Combo CMs (Capture Modules). These fields define the identity of the device and how it communicates on the hardware level.

Id(mandatory): Represents the last fourth byte of the IP of the CM IP address. For example: If the CM IP: CM 10.104.3.64 -> Id : 64.
Type(mandatory): Defines the type of the CM being used. Valid value include “CAN_Combo” “LIN_Combo”.
Buses(mandatory): Lists the Logical buses that are connected to the CM.
- “Logical channel name”(mandatory): Represents the name of the bus (or channel) as used in the configuration.
  - HWChannel(mandatory): Specifies the channel ID defined in the CM’s Web interface.
    
    OperationMode:(optional): Defines how the logical channel will behave. A logical channel can be mapped to 2 physical channels, one for Rx (reception) and one for Tx (transmission). Possible values are:
    
    Normal: The channel will be used for Rx (receive) and Tx (transmit).
    
    Spy: The channel only listens (Spy mode). It does not send data. For example in CAN, no ACK is sent.
    
    TxOnly: The channel will be used only for transmission.
    
    RxOnly: The channel will be used only for listening.
Mappings: CM: Devices: 1: Id : 64 Type: CAN_Combo Buses: CAN_channel1: # CAN-A HWChannel: 619 OperationMode: Normal 2: Id : 48 Type: LIN_Combo Buses: CAN_channel1: # LIN-A HWChannel: 536 OperationMode: Normal

Setup Example

The setup below demonstrates how to make 2 Capture Module devices communicate with each other via CAN and FlexRay buses. The goal is to define logical channels in this setup and map them to the physical channels of the CMs.

Step1: Understand the physical setup

In the image above you have:

A switcher connected to two CAN Capture Modules to route the communication between the 2 devices and the PC(framework).
2 CAN CMs connected to each other via a CAN bus and a FlexRay bus.

Step2: Understand and define logical channels

A logical channel represents a unidirectional or bidirectional communication path between devices. Logical channels are defined in the configuration file to map the framework’s communication to the physical channels.

In this example setup you need:

logical Channel

Physical Channel

Description

2 logical channels

for CAN communication

CAN bus

Each logical channel

a communication path

from CM1 to CM

or from CM to CM1

2 logical channels

for FlexRay communication

FlexRay bus

Each logical channel

a communication path

from CM1 to CM

or from CM to CM1

Step3: Create the Channels section

Ch_CAN_FD_1:
  Id: 1
  TracerName: default_ascii_tracer
  Type: CAN
  Protocol: CANFD

Ch_CAN_FD_2:
  Id: 2
  TracerName: default_ascii_tracer
  Type: CAN
  Protocol: CANFD

Ch_FlexRay_1:
  Id: 3
  TracerName: default_ascii_tracer
  LoggingName: Ch1_FlexRay
  Type: FLEXRAY

Ch_FlexRay_2:
  Id: 4
  TracerName: default_ascii_tracer
  LoggingName: Ch2_FlexRay
  Type: FLEXRAY

Step3: Create the Mappings section

Mappings:
CM:
  Devices:
    1:
      Id: 64
      Type: CAN_Combo
      Buses:
        Ch_CAN_FD_1:
          HWChannel: 10

        Ch_FlexRay_1:
          HWChannel: 20
          KeySlot: 1
          NodeType: ColdStartFollowing
          WakeUpCluster: false
    2:
      Id: 65
      Type: CAN_Combo
      Buses:
        Ch_CAN_FD_2:
          HWChannel: 11

        Ch_FlexRay_2:
          HWChannel: 21
          KeySlot: 1
          NodeType: ColdStartLeading
          WakeUpCluster: false

Mapping logical channel to a Power Supply

Among the devices that can be mapped to logical channels in the configuration file is the power supply. It is a hardware component that provides electrical power to system elements, commonly referred to as loads. MTF supports different types of power supplies including Genesys, Manson and Stamos.

Each type may have its own settings, but some fields are common to all of them.

Fields explanation

Below is a description of the fields shared by all supported power supply types.

Genesys_PowerSupply: This field is mandatory. It specifies the type of power supply being mapped, in this case a Genesys power supply.
- Channels This field is mandatory. It is a key, and its value is the list of channels (1,2,3).
  - 1,2,3..: These are mandatory fields. Each number represents a specific channel on the power supply. The number itself is the key, and the value is a set of configuration settings for that individual channel.
    - ChannelName: This field is mandatory. It specifies the name of the logical channel being mapped, allowing you to identify the channel in the configuration.
    - DefaultVoltage: This field is Optional. It defines the default generated voltage by the Power Supply.
    - MaxVoltage: This field is mandatory. It defines the maximum voltage that we want to generate by the Power Supply.
    - DefaultMaxCurrent: This field is mandatory. The default Power Supply current limit value.
    - SamplingInterval: This field is optional. It Represents the interval between two consecutive power consumption measurements (sampling interval). The DUT’s power consumption should be recorded for post-execution analysis. The default is 100 ms.
    - PortName: This field is mandatory. The COM port name connected to the power supply.
    - ContinuousMonitoringActive: This field is optional. Indicates whether we should continuously send a request to read out voltage and current or not(depending on the SamplingInterval).
    - KeepStatus: This field is optional. The power supply will remain ON between test cases, with no default voltage set. At the end of the execution, the power supply will not be set to a safe and known state. Please make sure the power supply is ON and the voltage is correctly configured before starting the execution.
    - BitRate: This field is mandatory. The serial speed.

Genesys_PowerSupply:
  Channels:
    1:
      BitRate: 19200
      ChannelName: PS_Channel
      DefaultMaxCurrent: 35
      DefaultVoltage: 12
      MaxVoltage: 20
      PortName: COM2
      RoutingSleepTime: 100

The Genesys power supply type requires additional fields beyond the common ones. This is because it communicates using TCP, UDP, or serial connections, which need more specific configuration than simpler types like Manson.

The following are the fields required for configuring a Genesys power supply:

CommunicationProtocol: Serial or Tcp. For Serial, you must specify the BitRate and PortName. For TCP, an IP and port must to be selected.

IP: The IP of the power supply.

Port: The TCP/UDP communication port.

Language: Can be set to SCPI or GEN.

Genesys_PowerSupply:
  Channels:
    1:
      ChannelName: PS_Channel
      DefaultMaxCurrent: 35
      DefaultVoltage: 12
      MaxVoltage: 20
      CommunicationProtocol: Tcp
      Language: SCPI
      IP: 169.254.16.136
      Port: 8003

Setup example

The example below explains how to set up and configure a test environment involving two different types of power supplies: the GenensysPlus and the Manson.

The goal is to define logical channels in this setup and map them to the physical channels of the two devices.

Step1: Understand the physical setup

The setup includes:

GenensysPlus power supply connected to PC via an Ethernet cable.

Manson power supply connected to PC via USB-cable (serial Bus).

At this stage, you should confirm:

That the correct drivers are installed (e.g., Silicon Labs CP210x for Manson).

That you can identify the IP address for GenensysPlus and the COM port for Manson.

For more information related to the setting refer to this tutorial: Map logical channel to a Power Supply.

Step2: Understand and define logical channels

A logical channel represents a unidirectional or bidirectional communication path between devices. Logical channels are defined in the configuration file to map the framework’s communication to the physical channels.

In this example setup you need:

logical Channel

Physical Channel

Description

1 logical Channel

for the Manson PS.

COM3

(It is just an example,

check Device Manager

for your actual port name.)

Serial port communication

with the Manson PS via USB.

1 logical Channel

for the GenensysPlus PS.

192.168.1.100:5025

(It is just an example

check the device or its manual

for your actual

IP address).

TCP connection

to the GenensysPlus PS

using SCPI protocol.

Note

The IP address (192.168.1.100), its port (5025) and the COM port (COM3) may differ depending on your setup. Make sure to use the correct values detected on your system.

Step3: Create the channels section

Now the logical channels are defined, add them to your configuration file under Channels section.

Channels:
  PS_M_Channel:
    Id: 70 # mandatory
    TracerName: default_ascii_tracer  # optional
    LoggingName: PowerSupplyMan  # optional
    Type: PS  # mandatory

  PS_G_Channel:
    Id: 71 # mandatory
    TracerName: default_ascii_tracer  # optional
    LoggingName: PowerSupplyGen  # optional
    Type: PS  # mandatory

Step4: Map the logical channels to the device’s physical channels

After defining the logical channels, the next step is to tell the Framework(MTF) which channel belongs to which device. This is done in the Mappings section.

Mappings:

  Genesys_PowerSupply:
    Channels:
      1:
        ChannelName: PS_M_Channel # mandatory
        DefaultMaxCurrent: 120
        DefaultVoltage: 13
        MaxVoltage: 20
        CommunicationProtocol: Tcp
        language: SCPI
        IP: 192.168.1.100
        Port: 5025

  Manson_PowerSupply:
    Channels:
      1:
        ChannelName: PS_G_Channel # mandatory
        PortName: "COM3" # mandatory
        BitRate: 9600 # mandatory
        MaxVoltage: 20 # mandatory default =0
        MaxCurrent: 12 # mandatory default =0
        DefaultVoltage: 12 # optional default =0
        KeepStatus: true # optional default =0
        ContinuousRead: false # optional default =0
        ContinuousReadingInterval: 1000 # optional default =0

Mapping logical channel to a Network Adapter

Fields explanation

Name: The logical channel assigned to this physical channel, in this case, the network adapter.
FriendlyName: (or AdapterFriendlyName): Friendly Adapter Name. (On Windows, the adapter’s friendly name can be found by following this path: Control Panel > Network and Internet > Network Connections.)
Interface: (Needed if AdapterFriendlyName is not defined) Adapter Name. For example:
- Windows: “DeviceNPF_{212BBE8E-C3C1-4944-972C-C72D687B5707}”
- Linux: “ensp04”
BufferSize: The kernel buffer size (in MB) associated with the adapter. For more information, visit pcap_set_buffer_size.
BpfFilter: Sets a filter on the network adapter (e.g., ip src 192.168.0.1). For more information, visit pcap-filter.
Timeout: The read timeout in milliseconds (ms). For more information, visit pcap main page.
TimeStampPrecision:: Microsecond or Nanosecond (supported only on Linux). For more information, visit pcap_set_tstamp_precision.
TimeStampSource: Options include TimeStampHost, TimeStampHostLowPrecision, TimeStampHostHighPrecisionSync, TimeStampAdapterUnsync, TimeStampHostHighPrecisionUnsync. (More information). Windows supports only TimeStampHost.
ImmediateMode: If set to true, packets are delivered as soon as they arrive, with no buffering. This increases the transitions from kernel space to user space, leading to a performance impact. For more information, visit, pcap_set_immediate_mode.
SnapshotLength: The snapshot length. For more information, visit, pcap main page.
PcapDeviceMode: Can be set to Promiscuous, which captures all packets, even if they are not addressed to the MAC address of the adapter. For more information, visit pcap_set_promisc. visit pcap_set_promisc.
UseDataLoggerTimeStamp: Replaces the software timestamp introduced by libraries like Libpcap or Npcap with the one provided by the hardware Logger (CM or BRY-SPY).
RemoveDataLoggerMetaData: Removes metadata added to the packet by data loggers (e.g. CM or BRY-SPY). This is valid only if packetization is not active.
DataLoggerType: If UseDataLoggerTimeStamp or RemoveDataLoggerMetaData is set to true, this field identifies the data logger being used. Each data logger adds a specific metadata to the logged packet.
PacketProcessingActive: If set to false, the adapter will only be used for logging, and traffic will be not forwarded to upper layer.
PacketIdentificationActive: If set to false, packets will be not processed and the whole traffic will be forwarded to the upper layers without identification (SOME/IP, NM or DOIP).
DifferentHandlerForTxAndRx: In Some Systems, Libpcap don’t capture packets that were injected into the same interface using the same handler. This option allows you to use different handlers to overcome this limitation.
TECMPPacketizationActive: or CMPacketizationActive: if the Technica CM Packetization option is active, this setting needs to be set to ‘true’ to ensure that the Framework divide each packetized message in individual TECMP or CMP packets. Please note that as a precondition, the PacketIdentificationActive setting also needs to be set to ‘true’.

Note

If the adapters will be used only for Pcap file generation, it makes sense to:

Set ImmediateMode to false.

Set Timeout to 100 ms.

Set PacketProcessingActive to false.

Set PacketIdentificationActive to false.

PCAP:
  1:
       Adapter:
           Name: ETH_SOMEIP
           FriendlyName: "Ethernet-ch"
           BufferSize: 8
           BpfFilter: ''
           Timeout: 1
           TimeStampPrecision: Microsecond
           TimeStampSource: TimeStampAdapter
           ImmediateMode: true
           SnapshotLength: 65536
           PcapDeviceMode: promiscuous
           UseDataLoggerTimeStamp: false
           RemoveDataLoggerMetaData: false
           DataLoggerType: NotDefined
           PacketProcessingActive: true
           PacketIdentificationActive: true

Note

If a driver packet loss is detected, you may need to increase the Pcap adapter BufferSize.

Note

If a bus listener is needed for the channel, you need to:

Set PacketProcessingActive to true.
Set PacketIdentificationActive to true.

And it will be better to add sleep(time in seconds) before and after sending the message/frame, to make sure that the message can be captured by the bus listener.

Setup example

The setup below demonstrates how to use a Network Adapter to send and receive Ethernet messages. In this case, the Capture Module Ethernet Combo is used as the network adapter.

Step1: Understand the physical setup

In the image above:

The Capture Module Ethernet Combo is connected to the PC via a standard Ethernet cable and powered by a power supply.
The MediaConverter 100/1000BASE-T1 is connected to the CM via a MATEnet cable (automotive Ethernet), and to the PC via a standard Ethernet cable. The MC coverts automotive Ethrenet to standard Ethernet and vise versa.

Step2: Understand and define logical channels

A logical channel represents a unidirectional or bidirectional communication path between devices. Logical channels are defined in the configuration file to map the framework’s communication to the physical channels.

In this example setup you need:

logical Channel

Physical Channel

Description

1 logical channel: CM_com

MATEnet cable (automotive Ethernet)

+ standard Ethernet cable

(from Capture Module to MediaConverter to PC and back).

Used for communication between

the Capture Module

and the framework.

1 logical channel: CM_log

Standard Ethernet cable (from Capture Module to PC).

Used for logging the captured

traffic.

Step3: Create the channels section

CM_com:
  Id: 66
  LoggingName: CM_com
  TracerName: PCAP_Tracer_CM_com
  Type: ETHERNET

CM_log:
  Id: 67
  LoggingName: CM_log
  TracerName: PCAP_Tracer_CM_log
  Type: ETHERNET

Step4: Map the logical channels to the device’s physical channels

PCAP:
    1:
      Adapter:
        BpfFilter: ''
        BufferSize: 128
        DataLoggerType: TECMP
        ImmediateMode: false
        FriendlyName: CM_com_adapter
        Name: CM_com
        PacketIdentificationActive: true
        PacketProcessingActive: true
        PcapDeviceMode: promiscuous
        RemoveDataLoggerMetaData: false
        SnapshotLength: 65536
        TimeStampPrecision: Nanosecond
        TimeStampSource: TimeStampAdapter
        Timeout: 1
        UseDataLoggerTimeStamp: false
    2:
      Adapter:
        BpfFilter: ''
        BufferSize: 128
        DataLoggerType: TECMP
        ImmediateMode: false
        FriendlyName: CM_log_adapter
        Name: CM_log
        PacketIdentificationActive: true
        PacketProcessingActive: true
        PcapDeviceMode: promiscuous
        RemoveDataLoggerMetaData: false
        SnapshotLength: 65536
        TimeStampPrecision: Nanosecond
        TimeStampSource: TimeStampAdapter
        Timeout: 1
        UseDataLoggerTimeStamp: false

Mapping logical channel to a BTS-REVO

The BTS-REVO (Body Electronics Test System) is a Technica device used to simulate buttons, sensors and actuators. It is commonly used in hardware setups to perform operations such as:

Checking voltage changes in a DUT(Device Under Test).

Simulating on/off actions.

Testing fault conditions like short to ground , short to VBAT or open load.

Using MTF we can map logical channels to the BTS-REVO’s physical channels to control and monitor analog signal(current, voltage) states during tests.

Fields explanation

Below are the different possible fields of the BTS-REVO mapping section:

BTS-Revo (mandatory): This field specifies the device type to be be mapped which in this case is a BTS-Revo.
- Boards (mandatory): This field is a key and its value is the list (1,2,3..) of BTS-Revo devices we have in the system and we want to configure.
  - 1,2,3..(mandatory): Each number represents a BTS device.
    - Id: The fourth byte of the IP of the BTS-Revo. For example: IP BTS-Revo 10.104.3.160 -> Id : 160. The full IP address is written on the back of the device; and you can set the last byte/Id by rotating the rotary switch. For example: Position 0 -> Id= 160
    - IOs (mandatory): It is a key and its value is the list of IOs configuration.
      - ChannelName (mandatory): The logical channel name that is defined in the Channels section. It is a key and it value is the following parameters:
        
        HWChannel (mandatory): The index of the physical channel on the BTS Board to be mapped to the logical channel. The BTS-REVO has 24 IO channels; and the counting starts from the connector that is farthest from the power lines.
        
        MeasurementAttribute (mandatory): Specifies the type of measurement required, such as Voltage, Current, PWM (pulse width modulation)
        
        LineContactState (optional): Indicates whether the Open Load state is active by default. “Open Load” refers to a condition where a circuit is open or disconnected; for example, there is no load attached (a load is something that uses electricity to do work).
        
        GndContactState (optional): Indicates whether the Short to GND state is active by default. “Short to GND” happens when a signal line is unintentionally connected to ground, causing incorrect behavior or a fault.
        
        VbatContactState (optional): Indicates whether the Vbat state is active by default. “Vbat” typically refers to the battery voltage or a main supply voltage in automotive or hardware systems.
        
        StaticChannel (optional): The state of the channel is static and cannot be changed by test cases or test functions.
        
        InitValue (optional): Depending on the channel type, this can be default resistance, voltage or other parameters.
        
        Function (mandatory): None, Relay, Potentiometer, ElectronicLoad, GNDSwitch, VBATSwitch, VoltageGenerator, etc.
        
        ChannelType (optional): HC (HighCurrent Channel).
        
        MeasurementConfig (optional): Provide a list of configuration id that should be applied on this channel.
      - PWMWindowTime (optional): It is the maximum time required to detect 0% or 100% duty cycle. It is defined in milliseconds, and by default, it is set to 200 ms.
      - SubscriptionConfig (optional): This specifies the subscription mechanism that the BTS uses to return values. Possible values are: Default value is:
        
        ID: ID of the subscription config.
        
        Type: On which Measurement attribute event it will be applied.
        
        IsPeriodic: Flag indicates if the subscription is periodic.
        
        Polling: It is taken into consideration if IsPeriodic is true and it can take as values 5,10,25,50,100,250,500 and 1000.
        
        UpperThreshold: The upper threshold in which the event will be triggered
        
        LowerThreshold: The lower threshold in which the event will be triggered

Important

As shown in the image below:

The rotary switch, highlighted with a blue line, specifies the board Id starting from the value 160.
The BTS-REVO contains 24 I/O channels (pins), and the numbering starts from the left, meaning from left to right: 1, 2, … 8, etc.

Setup example

The setup below demonstrates how to use a BTS-Revo board to simulate three signal conditions:

Short to Ground
Short to VBAT
Open Load

The goal is to define logical channels in this setup and map them to the physical channels of the BTS-REVO.

Step1: Understand the physical setup

In the image above you have:

BTS-REVO connected to the 12v power source + GND of the power supply.
2 IO channels connected to each other in a loop (pin 1 + pin 2).
2 IO channels to simulate the short to Vbat (pin 3) and short to GND (pin 4).
1 IO channel to test the open load.
A dagger board connected to the BTS to add the ability to change the resistance value. One dagger adds the resistance functionality to 4 consecutive channels starting from channel 1,5,9,13,17,21 depending on the connector connected to it.

Step2: Understand and define logical channels

A logical channel represents a unidirectional or bidirectional communication path between devices. Logical channels are defined in the configuration file to map the framework’s communication to the physical channels.

In this example setup you need:

logical Channel

Physical Channel

Description

1 logical channel

Between the power supply

and the BTS-Revo.

2 logical channels for ?.

Loop between Pin1

and Pin2 in the BTS board.

1 logical Channel for the short to Vbat test.

Pin 3

Simulates direct

connection to the PS voltage.

1 logical Channel for the short to GND test.

Pin4

Simulates direct

connection to ground.

1 logical Channel for the open load test.

Simulates open circuit.

Step3: Create the channels section

PS_bts_Ch:
  Id: 70
  TracerName: default_ascii_tracer
  LoggingName: PowerSupply
  Type: PS

Ch1-BTS:
  Id: 72
  TracerName: default_ascii_tracer
  LoggingName: VoltageChange1
  Type: IOOUTPUT

Ch2-BTS:
  Id: 72
  TracerName: default_ascii_tracer
  LoggingName: VoltageChange2
  Type: IOINPUT

Ch3-BTS:
  Id: 73
  TracerName: default_ascii_tracer
  LoggingName: VPin
  Type: IOOUTPUT

Ch4-BTS:
  Id: 74
  TracerName: default_ascii_tracer
  LoggingName: GNDPin
  Type: IOOUTPUT

Ch5-BTS:
  Id: 74
  TracerName: default_ascii_tracer
  LoggingName: OpenL
  Type: IOOUTPUT

Step4: Map the logical channels to the device’s physical channels

Genesys_PowerSupply:
  Channels:
    1:
      BitRate: 9600
      ChannelName: PS_bts_Ch
      DefaultMaxCurrent: 120
      DefaultVoltage: 12
      MaxVoltage: 20
      PortName: COM9
      RoutingSleepTime: 100
      KeepStatus: true

BTS-Revo:
  Boards:
    1:
      Id: 160
      IOs:
        Ch1-BTS:
          HWChannel: 1
          MeasurementAttribute: Voltage

        Ch2-BTS:
          HWChannel: 2
          MeasurementAttribute: Voltage

        Ch3-BTS:
          HWChannel: 3
          Function: VBATswitch
          MeasurementAttribute: Voltage

        Ch4-BTS:
          HWChannel: 4
          MeasurementAttribute: Voltage

        Ch5-BTS:
          HWChannel: 5
          MeasurementAttribute: Voltage

Mapping logical channel to a Serial Port

PortName: The serial Port name.
BaudRate: The serial port option to permit changing the baud rate.
Parity: The serial port option to permit changing the parity.
DataBits: The serial port option to permit changing the character size.
StopBits: The serial port option to permit changing the number of stop bits.
FlowControl: The serial port option to permit changing the flow control.
MessageTerminator: The end of line char, used for the message termination detection like LF or CR (MessageTerminator: “\r\n”)
SeparationTimeMs: The time separating the send of two consecutive characters in the message in milliseconds.

Serial:
    Ports:
      Master-Serial: <============= logical channel name
        PortName: COM13
        BaudRate: 4000000
        Parity: None
        DataBits: 8
        StopBits: One
        FlowControl: None
        MessageTerminator: "" # Will be used to specify the message terminator:
                              # empty, ACSII character, CR/LF or LF/CR (default no terminator).
        MaxReceivedDataSize: 512

Mapping logical channel to HH Electrical load

HH electrical load is an external device used to simulate a load in a channel. For more information visit the official website. Two types of devices were integrated: PLI series and PMLI series.

PortName: The serial Port name.
BaudRate: The serial port option to permit changing the baud rate.
Id: The device id.
Type: PLI or PMLI (PMLI refers to multi-channel).
Channels: Map a channel to the channel index.
- ID: The ID of the channel.
- Name : The name of the signal should exist in channel section.
- ExternalTrigger: ndicates whether the trigger is done through external I/O (I/O port of the electrical load) or via remote communication. By default, it is set to false (remote-controlled by default).
- VoltageProtection: The voltage protection value.

HH_Electrical_load:
    Devices:
        1:
          Id: 1
          PortName: COM9
          Type: PMLI
          BitRate: 115200
          Channels:
            1:
                Id: 1 # channel_index
                Name: channel_name

Mapping logical channel (Antenna) to an LF_Reader

New LF_reader is an extension board for BTS revo. It has a maximum of 3 antenna per board.

BoardId: The board with LF_reader extension id.
Antennas: Define which channel of the LF_reader each antenna is connected to:
- AntennaNumber: The number of the antenna.
- HWchannel: The channel of the LF_Reader.

Lf_Reader:
    1:
      BoardId: 169
      Antennas:
          1:
              AntennaNumber: 1
              HWChannel: 1
          2:
              AntennaNumber: 2
              HWChannel: 2
          3:
              AntennaNumber: 3
              HWChannel: 3

Mapping RelayBoards Channels (Technica Relay Board “SHS”)

The relay board is a component with several relays (electrically operated switch) that allows us to control their behavior and perform several additional actions. The fields are:

CANChannelName: Name of the CAN channel connected to the Relay boards CAN bus.
Boards: The list of connected relay boards.
- Id : Mandatory board Id.
- Relays: The list of relay channels in the board.
  RELAY_NAME:
  
  HWChannel: The channel id in the relay.
  
  InitValue: It is optional. Default is OFF. Possible values are ON and OFF.
  
  DefaultValue: It is optional. Default is OFF. Possible values are ON and OFF.
  
  Function: Relay.

RelayBoards:
        CANChannelName: RELAY_BOARDS_CAN
        Boards:
            1:
                Id: 1
                Relays:
                  RELAY_A:
                    HWChannel: 1 # mandatory (starting from 1)
                    Function: Relay
            2:
                Id: 2
                Relays:
                  RELAY_B:
                    HWChannel: 1
                    InitValue: ON
                    DefaultValue: ON
                    Function: Relay

Mapping HIDRelayBoards Channels (DCTTECH manufacturer)

This section is a map of relay boards, where the key is a unique integer global ID, and the value is the board definition, as shown below:

ID: It is a mandatory field. It contains the board serial (can be obtained via the TestApp using Find device button).

Relays: The list of relay channels in the board (please first define the channels in the Channels section explained above, setting their type as IOOUTPUT).
- RELAY_NAME:
  HWChannel: The channel id in the relay.
  
  InitValue: It is optional. Default is OFF. Possible values are ON and OFF.
  
  DefaultValue: It is optional. Default is OFF. Possible values are ON and OFF.

HIDRelayBoards:
    1:
        ID: Board1Id
        Relays:
            RELAY_C:
                HWChannel: 1
                InitValue: ON
                DefaultValue: OFF
            RELAY_D:
                HWChannel: 2
    2:
        ID: Board2Id
        Relays:
            RELAY_E:
                HWChannel: 8

Mapping WinpkFilter Channels

To configure WinpkFilter channels, a section WinpkFilter should be added. It should contain a list of channels, each of them can be configured as the following:

CHANNEL_NAME
- AdpaterFriendlyName : The name of the corresponding Ethernet Adapter.
- Type: The type of the channel (possible values are: Filter, FilterFastIO).
- IPMacTable : The list of couples of IP and its desired MAC.
- IPV4Ttl: The IPV4Ttl value to be used for all outgoing IPV4 packets.
- VLans:
  InnerTags and/or OuterTags: The list of Vlans.
  
  ID: The Vlan Id (integer).
  
  Priority: The Vlan Priority (integer).
  
  IPList: The list of IP addresses to be assigned to this Vlan.

WinpkFilter:
    WinpkFilterTestChannel1:
        AdpaterFriendlyName: TestAdapter1
        Type: Filter
        IPMacTable: [[160.48.199.57, 00:00:00:00:00:39],[160.48.199.100, 00:00:00:00:00:64]]

    WinpkFilterTestChannel2:
        AdpaterFriendlyName: TestAdapter2
        Type: Filter
        VLans:
            InnerTags:
                -
                    ID: 68
                    Priority: 1
                    IPList: [160.48.199.57, 160.48.199.100]

            OuterTags:
                -
                    ID: 19
                    Priority: 7
                    IPList: [160.48.199.57]
        IPV4Tl: 1

To use this feature, the Windows Packet Filter driver needs to be installed and activated in the adapter. Releases · wiresock/ndisapi (github.com)

Note

It is recommended to deactivate this feature on all adapters that are not using it.

Mapping TUN/TAP Bridge Channels

The TUN/TAP functionality enables you to bridge multiple virtual adapters with a physical adapter. This functionality allows for specific alterations to packet data at the bridging level. The update involves adding Vlan tags to packets transferred from the virtual to the physical adapter. In the other direction, the change consists of removing any Vlan layers from the packet and orienting the packet to the proper target virtual adapter.

To configure the TUN/TAP functionality, define an Ethernet channel with the bridge type in the list of channels, as shown below:

Channels:
 ETH_Bridge:
  Id: 90
  Type: BRIDGE

Then, the TUNTAP_BRIDGE mappings should be defined under the Mappings config section, linking the list of virtual adapters and the physical adapter under the same Ethernet bridge channel.

Mappings:
    TUNTAP_BRIDGE:
      ETH_Bridge:
        Name: ETH_Bridge
        PhysicalAdapter: Ethernet adapter
        TunTapAdapterList:
          TunTapAdapter:
            Name: Virtual_tap1
            InnerVlan:
              VlanId: 0x12
              VlanEthertype: 0x8100
              VlanPriorityTag: 0
              VlanCfi: true
            OuterVlan:
              VlanId: 0x34
              VlanEtherType: 0x9100
              VlanPriorityTag: 0
              VlanCfi: false

Name: Indicates the name of the Ethernet bridge channel.
PhysicalAdapter: Represents the friendly name of the physical adapter that will be associated with the virtual adapters.
TunTapAdapterList: Provides a list of virtual adapters that will be linked to the physical adapter of the specified Ethernet bridge channel.
- TunTapAdapter: Specifies a configuration section for a single virtual adapter.
  Name: The friendly name of the virtual adapter.
  
  InnerVlan: The inner Vlan configuration section for the particular virtual adapter.
  
  OuterVlan: The outer vlan configuration section for the particular virtual adapter.
  
  VlanId: The ID field value for the current VLAN configuration section.
  
  VlanEthertype: The ethertype value for the current VLAN configuration section. It is used to specify the VLAN standard.
  
  VlanPriorityTag: Represents the priority field value for the current VLAN config section.
  
  VlanCfi: IThe value of the VLAN CFI flag in relation to the current VLAN configuration section.

The TUN/TAP feature can be combined with a packet manipulation feature, which is responsible for VLAN tagging and changing the source MAC address of packets that are sent dynamically (as opposed to statically, where the VLAN tags are preconfigured for the virtual adapter), based on a configuration data set.

This can be used with ManipulatePackets config option flag under the TunTapAdapter section. It indicates whether a tap adapter communication is eligible for packet modification.

If the packet manipulation feature is left unspecified, it defaults to false. However, if it is set to true, the tagging process is based on the data set specified in the EthernetTopology config section, which is located under the FrameworkConfig section within the EthernetConfig section.

Therefore, defining the Inner and Outer Vlans configuration under the TunTapAdapter will be unnecessary.

Configuration of the time synchronization source (Time Server)

The TE EES serves as a highly accurate synchronization source, delivering nanosecond-level time to PTP clients, such as our test bench equipment (e.g. CM/BTSEvo boards).

A test bench can incorporate multiple EES units, and this configuration section is used to specify which EES that will function as the Grandmaster.

GrandMaster: The Id of the EES responsible for the time synchronization.

EES:
    GrandMaster: 200

Section 3: FrameworkConfig section

Tracers

The common fields for all the tracers are:

Type: Type of the Tracer (e.g., PCAP, ASCII, etc.).
TimeStamp: Timestamp precision: Microsecond or Nanosecond. It depends on the trace format; for example, ASCII supports only the microseconds. Additionally, system capabilities affect this; for example, Windows supports only microsecond time-stamping. The tracer timestamp precision needs to match the configured network adapter timestamp to avoid any logging problems.

LoggingType: MultipleAdapterMode or PerformanceMode.
- MultipleAdapterMode: Logs the traffic of several adapters in the same pcapng file.
- PerformanceMode: Used when performance is needed, such as using several buffers, writing packets by block, etc.
FileConfig:
- Extension: The file extension (optional), such as ‘.pcap’, ‘.pcapng’, or .‘pcapng.zst’ (Zstandard compression).
- CompressionLevel: It is valid only for the MultipleAdapterMode logging type, and the extension must be pcapng.zst.
  
  Note: On Windows, .zst files are not supported by default. To enable this support You can install 7-zip along with the Modern7z plugin. Wireshark, However supports reading zstd compressed files by default.
- BaseFileName: For the rotating policy: this defines the base file name (e.g. trace_eth_1, trace_eth_2, trace_eth_3, etc.). It should be unique for each tracer.
- MaxFile: For the rotating policy: this specifies the maximum number of files that the tracer will generate.
- MaxFileSize: For the rotating policy: the tracer will create a new log file when the current log file exceeds the specified size limit (MaxFileSize in MBytes). This ensures that the tracer doesn’t exceed the defined size, and new log files are created for further events.
BufferConfig:
- BufferSize: The size of the buffer to be used to contain the received packets.

Note

Additional fields are needed for the PerformanceMode logging:

BufferNumber: The number of buffers to be used to contain the received packets.

WriteBurstSize: Writing bytes to the file is done in blocks; this filed defines the size of each block.

Note

If an application packet loss is detected, you may need to modify the Pcap logger configuration by increasing the BufferSize or the BufferNumber or even change the Pcap logger type (e.g. from MultipleAdapterMode to PerformanceMode).

Tracing:
    PCAP_Tracer_1:
        Type: PCAP
        LoggingType: MultipleAdapterMode
        Timestamp: Microsecond
        LoggerConfiguration:
            BufferConfig:
                BufferSize: 200
            FileConfig:
                Extension: ".pcapng.zst"
                CompressionLevel: 5
    PCAP_Tracer_2:
        LoggerConfiguration:
            BufferConfig:
                BufferNumber: '4'
                BufferSize: '128'
                WriteBurstSize: '128'
            FileConfig:
                Extension: trace_2
                Extension: .pcap
                MaxFileSize: '1024'
        LoggingType: PerformanceMode
        Timestamp: Microsecond
        Type: PCAP

Base: Hex or Decimal formatting.
InternalEventLogged: Internal events like LIN wake-up request. More details can be found in the ASCII format specification.
Extension: The file extension (optional).
BaseFileName: For the rotating policy: this defines the base file name (e.g. trace_eth_1, trace_eth_2, trace_eth_3, etc.). It should be unique for each tracer.
MaxFile: For the rotating policy: this specifies the maximum number of files that the tracer will generate.
MaxFileSize: For the rotating policy: the tracer will create a new log file when the current log file exceeds the specified size limit (MaxFileSize in MBytes). This ensures that the tracer doesn’t exceed the defined size, and new log files are created for further events.
TimeStampSetting: Absolute or Relative (to the start of the test case) timestamps.

default_ascii_tracer:
  Base: Hex
  InternalEventLogged: 'true'
  LoggerConfiguration:
    FileConfig:
      BaseFileName: lin_can_trace
      Extension: .asc
      MaxFile: '150'
      MaxFileSize: '200'
  TimeStamp: Microsecond
  TimeStampSetting: Absolute
  Type: ASCII

Note

If you would like to test ASCII Tracer on a local computer, you need to add the channel that uses the ASCII Tracer to VirtualDevices.

CAN_channel1:
Id: 45
Type: CAN
LoggingName: Debug-CAN
TracerName: Default_Ascii_Tracer
CAN_channel2:

Mappings:
    VirtualDevices: Hex
        Buses: 'true'
            CAN_channel1:
                Name:
    PCAP:
        1:

ConnectedEcus (DUT’s)

List of Devices under test connected to the Test bench. Names should match the ECU names defined in the database file (ARXML, DBC, LDF, FIBEX).

FrameworkConfig:
  ConnectedEcus:
    - ECU1
    - ECU2
    - ECU3

Publisher Configuration

MTF (Modular Test Framework) implements a Publish/Subscribe Model for the events dispatching. For example: received CAN frames.

PublisherType: SingleThreaded or MultiThreaded.
- SingleThreaded: only one thread will be used for the dispatching of all types of events.
- MultiThreaded: several threads will be used for the events dispatching.
ChannelsGroups: Define the threads/channels mapping.

FrameworkConfig: # optional
    PublisherConfig:
        PublisherType: MultiThreaded
        ChannelsGroups: # only relevant for MultiThreaded
            - [Ch_CAN1, Ch_CAN2, Ch_CAN3]
            - [ETH_SPY]

Ethernet Configuration

It contains different optional configurations:

NPdu configuration

NPduConfig:
- ManangeVlansInCom: a 802.1Q Vlan tag will be added to the NPDU packets sent via the com layer based on the database.
- RestrictNPduChannelsInCom: Creates only COM NPDU packets that are transmitted over the Ethernet channels (e.g VLAN) of the DUTT Ecus, as defined in ConnectedEcus section.
- IPMacTable: The list of couples of IP and its desired MAC.
- VLans:
  - InnerTags and/or OuterTags: The list of Vlans.
    
    ID: Vlan Id.
    
    Priority: Vlan Priority.
    
    IPList: The list of IP addresses to be assigned to this Vlan.

SomeIP configuration

SomeIPConfig:
- ServerToClientPortRangeMapping:
  - ServerPorts: The list of server ports ranges
  - ClientPorts: The list of the corresponding client ports ranges
- EndpointImplementation: The socket implementation to be used (“lwip” or “boost”, default is “boost”).
- AdapterName: The interface name, friendly name or description of the adapter to use for LWIP.

AppLayer Ports

It is a list of ports and/or ports ranges of the following App layer protocol : NPdu, SomeIp, UDPNM, DLT and SomeIpSD.

ConsiderOnlyEthernetTopologyEcus: If set to True only the ECUs the are defined in EthernetTopology section will be considered for COM ethernet communication (in addition to the DUTT ECUs defined in ConnectedEcus section).

EthernetConfig:
    ConsiderOnlyEthernetTopologyEcus: true # optional default false
    NPduConfig: # optional
        ManageVlansInCom: false # optional default false
        RestrictedNPduChannelsInCom: true # optional default false
        IPMacTable: [[160.48.199.57, 00:00:00:00:00:39], [160.48.199.100, 00:00:00:00:00:64]] # optional
        VLans: # optional
              InnerTags:
                  -
                      ID: 68 # Mandatory
                      Priority: 1 # Mandatory
                      IPList: [160.48.199.57, 160.48.199.100] # Mandatory
              OuterTags:
                  -
                      ID: 19 # Mandatory
                      Priority: 7 # Mandatory
                      IPList: [160.48.199.57] # Mandatory
                  -
                      ID: 20 # Mandatory
                      Priority: 1 # Mandatory
                      IPList: [160.48.199.100] # Mandatory
      SomeIPConfig: # optional
          ServerToClientPortRangeMapping: # optional
            ServerPorts: [[30501,30599], [31501,31599], [32501,32599]] # Mandatory
            ClientPorts: [[30491,30499], [31491,30499], [32491,32499]] # Mandatory must have the same length as ServerPorts
      AppLayerPorts: # optional
          NPdu: [3000, [3100, 3200], 3208]
          SomeIp: [[500, 503], 1000]
          UDPNM: [4100]
          DLT: [5000, 5001]
          SomeIpSD: [30490]

EthernetTopology

EthernetTopology defines the list of Ethernet ECUs and their respective data (such as source MAC address, IP addresses list and VLANs) that participate in sending communication to the DuT, and the priority field value for the DuT VLAN for each ethernet packet type. The packet manipulation feature currently receives its data sets from this data configuration section. Below is a description of the EthernetTopology configuration section:

EthProtoPrioConfig: A configuration list section to specify Ethernet protocol’s priority field for the DuT VLAN layer.
- Protocol: It is mandatory. It describes the desired protocol required to have its VLAN priority set to a certain value (currently supported values: TCP, UDP and ICMPv6).
- DefaultPriority: It is mandatory. It specifies the default value for VLAN priority to the current protocol configuration (supported values range from 0 to 7).
- Ports: It is optional. It overrides default VLAN priority for a specific port number or range, supported only for transport layer protocols (currently, only TCP & UDP are supported). The configuration can be set to specify an appropriate port or a port range for source or destination port.
  SrcPort/DstPort: It indicates the port number whose VLAN priority will be overridden.
  
  SrcPortRange/DstPortRange: It indicates the port range whose VLAN priority will be overridden.
  
  Priority: It is mandatory. It specifies a value for VLAN priority for this port configuration.
TopologyConfig: A list in which every ECU configuration data is specified.
- EcuName: It is optional. The ECU name that applies to this configuration information.
- SrcIpList: It is mandatory. A list of the IP addresses used by this ECU.
- SrcMacAdr: It is optional. The source MAC address that this ECU uses for communication.
- TunTapAdapterName: It is optional. It indicates the current topology configuration relevant to which TunTap’s tap adapter. If no adapter is specified, the current topology configuration will not be consumed by the TunTap.
- Vlans: It is optional. The VLAN configuration that this ECU uses for communication.
  DefaultVlan: It is optional. It emphasizes the default VLAN to be used.
  
  OuterVlanTag/InnerVlanTag: It represents a VLAN layer tag option.
  
  Id: It represents the current VLAN configuration section’s ID field value.
  
  Ethertype: Is is used to define the VLAN standard for the present VLAN configuration section. The following are the supported Ethertype:
  
  IEEE 802.1Q EtherType 0x8100 for InnerVlanTag.
  
  IEEE 802.1ad EtherType 0x88a8 and IEEE 802.1 q-in-q EtherType 0x9100 for OuterVlanTag.
  
  VlanPriorityTag: It reflects the value of the priority field in the current VLAN configuration section.
  
  VlanCfi: It indicates the VLAN CFI flag’s value.
  
  MulticastVlanForwarding: It is optional. It emphasizes the forwarding of multicast packets to different VLANs.
  
  OuterVlanTag/InnerVlanTag: It represents a VLAN layer tag option.
  
  Id: It represents the current VLAN configuration section’s ID field value.
  
  Ethertype: Is is used to define the VLAN standard for the present VLAN configuration section.The following are the supported Ethertype:
  
  IEEE 802.1Q EtherType 0x8100 for InnerVlanTag.
  
  IEEE 802.1ad EtherType 0x88a8 and IEEE 802.1 q-in-q EtherType 0x9100 for OuterVlanTag.
  
  VlanPriorityTag: It reflects the value of the priority field in the current VLAN configuration section.
  
  VlanCfi: It indicates the VLAN CFI flag’s value.
  
  DstIpVlanMapping: It is optional. It emphasizes that each destination IP is associated with a specific VLAN configuration.
  
  DstIp: The target IP associated with the following VLAN configuration.
  
  OuterVlanTag/InnerVlanTag: It represents a vlan layer tag option.
  
  Id: It represents the current VLAN configuration section’s ID field value.
  
  Ethertype: Is is used to define the VLAN standard for the present VLAN configuration section.The following are the supported Ethertype:
  
  IEEE 802.1Q EtherType 0x8100 for InnerVlanTag.
  
  IEEE 802.1ad EtherType 0x88a8 and IEEE 802.1 q-in-q EtherType 0x9100 for OuterVlanTag.
  
  VlanPriorityTag: It reflects the value of the priority field in the current VLAN configuration section.
  
  VlanCfi: It indicates the VLAN CFI flag’s value.

ChannelToEcusMapping

This section links an ECU to its corresponding Ethernet transmission adapter via the physical channel name. Its a map of a channel and ECU pair.

ChannelToEcusMapping: # (optional) Link an Ecu to its corresponding Ethernet transmit adapter via the physical channel name.
    CHANNEL1: [ECU1, ECU2]
    CHANNEL3: [ECU3]

Diagnostics

This section is optional and it specifies protocol and addresses used for diagnostics sessions:

EcuIpAddress: The IP address of the ECU to connect to. Can be left as “AutoDetect”.
TestersIpAddress: The tester address to use. It can be left as “Auto”. (Note: If the value is “Auto”, tester address cannot be manually changed in the diag session struct in C API)
Protocol: Can be set to HSFZ or DOIP.
NetID: It is optional. The Net address of the target ECU. If not specified, identification requests will be sent through all interfaces. If set, identification requests will only be sent through the specified net address.

FrameworkConfig: #optional
    Diagnostics:
        EcuIpAddress: AutoDetect # default AutoDetect or manually provided e.g "169.1.1.1"
        TestersIpAddress: 172.172.22.22 # default Auto or manually provided e.g "169.1.1.2"
        Protocol: DOIP # or HSFZ
        NetID: 160.48

Section 4(optional): ChannelsConfig section

This section is optional.

FaultyChannels

FaultyChannels is used to define IO channels used to provoke a fault in one the buses or IO’s. For example: short circuit in a CAN bus or open wire in a LIN Bus.

ChannelsConfig:
    Io_Channel_Ex1: =================================================> logical channel name
        FaultyChannels: {keyFaultyType, valueIoHwChannel}
    Io_Channel_Ex2:
        FaultyChannels: {keyFaultyType, valueIoHwChannel}============> logical channel name

Important notes

Important

By default, antivirus solutions inspect outgoing and incoming Ethernet traffic in our systems to detect potential threats.

It is very important to disable such services and turn off any kind of network protection in your Test System to prevent any performance impact if you are using hardware modules such as CMs, BTSRevo Boards, EES, etc.

Such changes in the Test System need to be done only by the IT team

logical Channel	Physical Channel	Description
1 logical Channel for the Manson PS.	COM3 (It is just an example, check Device Manager for your actual port name.)	Serial port communication with the Manson PS via USB.
1 logical Channel for the GenensysPlus PS.	192.168.1.100:5025 (It is just an example check the device or its manual for your actual IP address).	TCP connection to the GenensysPlus PS using SCPI protocol.

MTF Configuration File

Overview

File structure

Section 1: Channels section

Overview

Section structure

Field descriptions

Setup example

Step1: Understand the setup and physical Connections

Step2: Understand and define logical channels

Step3: Start the channels section

Step4: Add logical channels entries

A. Create the Ethernet logical channel

B. Create the CAN logical channels for CAN bus1

C. Create the CAN logical channels for CAN bus2

D. Create the FlexRay logical channels

Final result

Section 2: Mappings section

Overview

Section structure

Mapping logical channel to a Capture Module

Common fields

Fields related to FlexRay channels

Setup Example

Step1: Understand the physical setup

Step2: Understand and define logical channels

Step3: Create the Channels section

Step3: Create the Mappings section

Mapping logical channel to a Power Supply

Fields explanation

Setup example

Step1: Understand the physical setup

Step2: Understand and define logical channels

Step3: Create the channels section

Step4: Map the logical channels to the device’s physical channels

Mapping logical channel to a Network Adapter

Fields explanation

Setup example

Step1: Understand the physical setup

Step2: Understand and define logical channels

Step3: Create the channels section

Step4: Map the logical channels to the device’s physical channels

Mapping logical channel to a BTS-REVO

Fields explanation

Setup example

Step1: Understand the physical setup

Step2: Understand and define logical channels

Step3: Create the channels section

Step4: Map the logical channels to the device’s physical channels

Mapping logical channel to a Serial Port

Mapping logical channel to HH Electrical load

Mapping logical channel (Antenna) to an LF_Reader

Mapping RelayBoards Channels (Technica Relay Board “SHS”)

Mapping HIDRelayBoards Channels (DCTTECH manufacturer)

Mapping WinpkFilter Channels

Mapping TUN/TAP Bridge Channels

Configuration of the time synchronization source (Time Server)

Section 3: FrameworkConfig section

Tracers

ConnectedEcus (DUT’s)

Publisher Configuration

Ethernet Configuration

NPdu configuration

SomeIP configuration

AppLayer Ports

EthernetTopology

ChannelToEcusMapping

Diagnostics

Section 4(optional): ChannelsConfig section

FaultyChannels

Important notes