MTF Configuration File

MTF Core requires assigning logical channels to physical channels to specify which hardware interface/channel has to be used for data reception and transmission. MTF Core config file (yaml file) defines such assignment.

This config file is composed of three main sections:

  • Channels: Defined logical (software) channels, accessible from the framework or test cases. A channel can for instance be a Bus, IO (input/output) , a serial port, etc.

  • Mappings: HW channels to Logical channels mapping.

  • FrameworkConfig: Tracers configuration, internal modules configuration, etc.

Channels

Logical (software) channels, accessible from the framework or test cases. A channel can for instance, be a bus, an IO, a serial port, ect.

  • ‘ChannelName’: A channel must have a unique (HW independent) name.

    • Id: A channel must have a unique (HW independent) ID.

    • Alias: A channel can have several aliases (e.g. CAN_channel have as aliases Ch_CAN or Chan_CAN).

    • Type: A channel has a specific type:

      • 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: A channel can have a protocol version. In case the logical channel is a bus system, this field indicates the Protocol version (e.g. CANFD, CAN2.0, CAN-IB500, CANFD-IDENTICAL-ArbPh-DataPh (BRS = 0 for all Tx Request), LIN1.3, LIN2.2 ect).

    • loggingName: A channel can have a specific logging name (used during ascii or pcapng tracing).

    • TracerName: A channel can be associated to a specific tracer. This tracer is used for logging the incoming and outgoing traffic or measurements. For example, this allows us to trace the traffic of a specific channel to a particular Trace.

Channels:
 CAN_channel:
  Id: 1
  Type: CAN
  Protocol: CAN2.0
  loggingName: CAN_channel
  Alias: [Ch_CAN, Chan_CAN]
 CAN_FD_channel:
  Id: 2
  Type: CAN
  Protocol: CANFD
  Alias: [Ch_CAN_FD]
 ETH_SOMEIP:
  Id: 3
  Type: ETHERNET
  TracerName: PCAP_Tracer_1
  • For Network Access:

    1. AUTOSAR PDU or Signal PDU:

    If the user needs to set or listen to an AUTOSAR PDU or Signal PDU, the logical channel’s name (or one of its aliases) must match the channel name defined in the loaded Communication Matrix via the database file.

    1. 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, MY_ETHERNET_CHANNEL-SPY_2, or MY_ETHERNET_CHANNEL-PORT_1, MY_ETHERNET_CHANNEL-PORT_2.

  • For IO ASCII Tracing:

    A specific logging index can be configured using LoggingBusIndex, as shown in the example below:

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

Mappings

Every Logical channel (e.g CAN_channel) needs to be mapped to a physical channel, for example: CM(Capture Module) -> CAN Combo channel. In this section these kind of mappings are defined.

Map logical channel to a Capture Module

Capture Modules are hardware devices that capture the data of in-vehicle communication systems via their logging network. Common fields for CAN and LIN Combo CM’s are:

  • Id: the fourth byte of the IP of the CM (Capture Module). For example: IP CM 10.104.3.64 -> Id : 64.

  • Type: CM Type (CAN_Combo, LIN_Combo).

  • Buses: Logical buses connected to the CM (Capture Module).

    • HWChannel: Channel ID defined in the CM Web page.

    • OperationMode: A logical channel can be mapped to 2 physical channels, one for Rx (reception), one for Tx (transmission).

      • Normal: Channel will be used for Rx and Tx.

      • Spy: Spy mode, no data transmission (over CAN no ACK), etc.

      • TxOnly: Channel will be used only for transmission.

      • RxOnly: Channel will be used only for listening.

For the mapping of FlexRay channels, additional fields are needed to correctly map the logical and physical channels:

  • KeySlot: A static slot that will be used by CM to transmit sync and startup frames in case the node type(the next explained field) is ColdStartLeading or ColdStartFollowing.

  • NodeType: FlexRay node type can be one of these values : ColdStartFollowing, ColdStartLeading, NonColdStartNonSync or NonColdStartSync

  • WakeUpCluster: Possibility to transmit a wake up pattern on the cluster.

Important

All of those 3 fields are only valid for FlexRay channels.

Mappings:
    CM:
      Devices:
        1:
        2:
          Id: 65
          Type: CAN_Combo
          Busses:
            CAN_channel1: #CAN-A
              HWChannel: 619
              OperationMode: Normal
            CAN_channel2: #CAN-B
              HWChannel: 620
              OperationMode: Normal
            CAN_FD_channel1: #CAN-C
              HWChannel: 521
              OperationMode: Normal
            CAN_channel3: #CAN-D
              HWChannel: 623
              OperationMode: Normal
            CAN_channel4: #CAN-E
              HWChannel: 629
              OperationMode: Normal
            CAN_channel5: #CAN-F
              HWChannel: 644
              OperationMode: Normal

Map logical channel to a Power Supply

A power supply is an electrical device that provides power to a load. Some types of power supplies include Genesys, Manson, and Stamos.

Common fields for all type of supported power supplies:

  • ChannelName: The logical channel name object of the mapping.

  • DefaultVoltage: The default generated voltage by the Power Supply.

  • MaxVoltage: The max voltage that we want to generate by the Power Supply.

  • DefaultMaxCurrent: The default Power Supply current limit value.

  • SamplingInterval: 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: The COM port name connected to the power supply.

  • ContinuousMonitoringActive: Indicates whether we should continuously send a request to read out voltage and current or not(depending on the SamplingInterval).

  • KeepStatus: 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: The serial speed.

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

These fields are specific to Genesys+:

  • 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 device.

  • 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

Map logical channel to a Network Adapter

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

Map logical channel to a BTS-REVO

  • Id: The fourth byte of the IP of the BTSRevo. For example: IP BTSRevo 10.104.3.160 -> Id : 160. The IP is defined by the rotary switch.

  • ChannelName: It should be defined in the Channels field and it contains the following parameters:
    • HWChannel: Channel index in the BTS Board. Start counting from the connector far from the power lines.

    • MeasurementAttribute: Needed measurement such as: Voltage, Current, PWM (BTS Input Channel).

    • LineContactState: Indicates whether the Open Load state is active by default.

    • GndContactState: Indicates whether the Short to GND state is active by default.

    • VbatContactState: Indicates whether the Vbat state is active by default.

    • StaticChannel: The state of the channel is static and cannot be changed by test cases or test functions.

    • InitValue: Depending on the channel type, this can be default resistance, voltage or other parameters.

    • Function: None, Relay, Potentiometer, ElectronicLoad, GNDSwitch, VBATSwitch, VoltageGenerator, etc.

    • ChannelType: HC (HighCurrent Channel).

  • PWMWindowTime: 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.

Map 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

Map 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

Map 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

Map 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

Map 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

Map 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

Note

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

Map 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

FrameworkConfig

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.

PCAP Tracer configuration

  • 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

ASCII Tracer configuration

  • 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

ChannelsConfig

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