Embedded Connectivity · SToESD I · Summer 2023

SOME/IP with ANDi & Vector

This page documents a four-part automotive networking lab conducted at Deggendorf Institute of Technology. The lab explored the full OSI stack in automotive Ethernet: physical devices, scripting tools, network interconnection, and finally SOME/IP service-oriented communication using Vector hardware and the ANDi tool. The project was completed with Qais Elyamani under the supervision of Prof. Dr.-Ing. Andreas Grzemba.

View References →

Overview

SOME/IP is the service-oriented middleware that modern vehicles use to let ECUs discover and subscribe to each other's data. Instead of a fixed CAN message layout, SOME/IP lets a camera ECU offer a streaming service and an ADAS ECU subscribe to it dynamically — across an automotive Ethernet backbone based on BroadR-Reach.

The lab used a real MediaGateway switch, a Vector VN5610 hardware interface, and two software tools — ANDi for scripting and traffic analysis, and Vector CANoe for ECU simulation. The goal of the final part was to reproduce a simulated ECU entirely from a second computer using ANDi, so that the original simulation could be switched off without breaking the service subscription.

Lab Structure

Part IDevices, IP/MAC, ANDi loopback
Part IITransmit/Receive scripts, VLAN
Part IIIMulti-gateway interconnection
Part IVSOME/IP with VN5610 & Vector

Key Concepts and Lab Findings

1. OSI Model and automotive networking scope+

Modern automotive networks are studied from OSI layer 1 (Physical Layer) to layer 4 (Transport Layer). This lab covered all four layers across its parts: physical devices and addressing in Part I, transport-layer scripting in Part II, device interconnection in Part III, and SOME/IP service-layer communication in Part IV.

Technical detail

OSI Physical Layer   →  BroadR-Reach / 100BASE-T1
OSI Data Link Layer  →  Ethernet frames, VLAN tagging
OSI Network Layer    →  IPv4 addressing, ARP
OSI Transport Layer  →  UDP / TCP (used by SOME/IP)

Each section of the lab targeted a different layer combination. Understanding the full stack is essential for diagnosing problems in automotive Ethernet systems.

2. SOME/IP protocol – scalable service-oriented middleware+

SOME/IP (Scalable service-Oriented MiddlewarE over IP) was developed to enable dynamic, service-oriented communication between ECUs with different sizes and operating systems. Unlike CAN, which uses static communication, SOME/IP runs over Ethernet and supports remote procedure calls, event notifications, and a defined serialisation format over UDP or TCP.

Technical detail

SOME/IP message structure:
  Message ID   [32 bit]  – Service ID + Method ID
  Length       [32 bit]  – from Request ID to end
  Request ID   [32 bit]  – Client ID + Session ID
  Protocol Ver  [8 bit]
  Interface Ver [8 bit]
  Message Type  [8 bit]  – REQUEST / NOTIFICATION / RESPONSE / ERROR
  Return Code   [8 bit]
  Payload       [variable]

UDP payload limit: 0–1400 bytes
TCP: segmentation supported, larger payloads allowed

The Message ID is unique across the entire system and user-defined. The Request ID helps providers and subscribers track parallel uses of the same method or event.

3. SOME/IP service model – events, methods, and fields+

SOME/IP structures communication through service definitions. A service can combine events, methods, and fields. Events carry data periodically or on change, from provider to subscriber. Methods allow subscribers to trigger remote procedure calls on the provider side. Fields combine notifiers, getters, and setters – notifiers send data on subscription and on change, getters let subscribers request current values, and setters allow subscribers to modify provider-side values.

In the lab simulation, CAMF acted as the service provider and ADAS as the subscriber. CAMF offered a service via SOME/IP-SD Offer Service, and ADAS subscribed using Find Service and Subscribe Eventgroup messages.

4. SOME/IP-SD – service discovery mechanism+

SOME/IP-SD (Service Discovery) handles the publishing and subscription side of SOME/IP. It implements a Publish/Subscribe concept: the server publishes its service, and the client subscribes to it. SOME/IP itself only transports the updated values; the discovery and subscription lifecycle is managed by SOME/IP-SD. In the lab, the communication sequence followed a strict order across the same Session ID.

Technical detail

ADAS  →  SOME/IP-SD: Find Service
CAMF  →  SOME/IP-SD: Offer Service
ADAS  →  SOME/IP-SD: Subscribe Eventgroup
CAMF  →  SOME/IP-SD: Subscribe Eventgroup Acknowledgment

After acknowledgment, the cycle repeats with cyclic NOTIFICATION updates.

When CAMF was deactivated in the lab, ADAS kept sending Find Service messages repeatedly because no Offer Service reply arrived. This confirmed that the service discovery handshake must complete before event data can flow.

5. BroadR-Reach and 100BASE-T1 physical layer+

BroadR-Reach (standardised as 100BASE-T1 in IEEE 802.3) is an automotive Ethernet physical layer that achieves 100 Mbit/s full-duplex communication over a single unshielded twisted copper pair. It reduces cable weight and cost compared to standard Ethernet while preserving compatibility with the Ethernet MAC layer. The physical layer uses PAM3 modulation at 33.3 MHz bandwidth to minimise EMI.

Technical detail

100BASE-T1 key properties:
  Speed:          100 Mbit/s full duplex
  Cable:          1 unshielded twisted pair
  Modulation:     PAM3 (33.3 MHz bandwidth)
  Standard:       IEEE 802.3bw
  Application:    In-vehicle Ethernet backbone

The MediaConverters in the lab converted standard 1 GBit Ethernet from the PCs into 100BASE-T1 to simulate in-vehicle network conditions as they would appear between real ECUs.

6. VLAN tagging and traffic segmentation+

A VLAN (Virtual Local Area Network) segments working groups at OSI layer 2 by adding tag information to Ethernet frames. In the MediaGateway, VLAN mode is activated globally and each port is assigned a default VLAN ID. Frames are forwarded only to ports sharing the same VLAN ID, which improves bandwidth efficiency and adds a security layer by filtering frames with unknown VLAN tags.

Technical detail

VLAN tag structure (802.1Q):
  TPID   [16 bit] – Tag Protocol Identifier (0x8100)
  PCP    [ 3 bit] – Priority Code Point
  DEI    [ 1 bit] – Drop Eligible Indicator
  VID    [12 bit] – VLAN Identifier (0–4094)

Example configuration in lab:
  BR-S1-P3  →  VLAN ID 040  (BroadR-Reach port)
  S1-P5     →  VLAN ID 049  (Ethernet port)

In Part III, all ports on the path to the Central WebCam (S1-P3 → S1-P8 → S2-P4 → S2-P8 → S3-P4 → S3-P8) had to be tagged with VLAN ID 073 to allow traffic to traverse the Central MediaGateway.

7. ANDi tool – scripting and traffic analysis+

ANDi (Automotive Network Diagnoser) is a test and simulation environment for Ethernet ECUs and bus systems (CAN, LIN, FlexRay). Scripting in ANDi uses a Python-based language with proprietary library functions. Adapters are configured as Stimulation (transmit) or Logging (receive). The tool supports live traffic viewing, PCAP replay, and direct SOME/IP frame generation through its Traffic Generator.

Technical detail

ANDi script structure (simplified):
  g_ethernet_msg.mac_address_source      = source_mac
  g_ethernet_msg.mac_address_destination = dest_mac
  g_ethernet_msg.payload = System.Array[Byte](...)
  g_ethernet_msg.send()
  sleep(1)   # timed transmission loop

The ANDi Traffic Generator was used in Part IV to imitate the CAMF ECU from computer 2. By reproducing the Offer Service and Subscribe Eventgroup Acknowledgment messages, ADAS could maintain its subscription even after the original CAMF simulation was deactivated.

8. Vector VN5610 and CANoe integration+

The Vector VN5610 is an Ethernet/CAN/USB interface used as a Vector Network Interface (VNI). It supports 10BASE-T, 100BASE-T1, 100BASE-TX, and 1000BASE-T physical layers, as well as CAN and LIN. In the lab it connected computer 1 to the MediaGateway via 100BASE-T1 BroadR-Reach. CANoe used it to simulate two virtual ECUs: CAMF (camera) and ADAS (Advanced Driver-Assistance Systems).

Technical detail

VN5610 connections in lab:
  CH1  →  MediaGateway S3-P3 via BroadR-Reach
  CH2  →  not used (redundant for this project)
  USB  →  Computer 1 (CANoe host)

CANoe project loaded: SOMEIPBasicAutosar
Ethernet channel setting: IEEE 100BASE-T1 (BR), Master (DSUB9)
BroadR-Reach mode: Slave (data flows from VN5610 to network)

No extra IP configuration was needed for the VN5610 because it acts as an interface rather than a network endpoint. The ECU IP addresses are managed within the CANoe simulation.

9. CAN and LIN bus protocols+

CAN (Controller Area Network) is a message-based protocol standardised under ISO 11898. It serialises data frames from multiple ECUs and grants transmission priority to the highest-priority device when collisions occur. It performs CRC-based error checking and nodes can disconnect if error counts exceed a threshold. LIN (Local Interconnect Network) complements CAN for simpler, lower-bandwidth subsystems where a single master controls up to 15 slaves over one wire.

Technical detail

CAN priority arbitration:
  Higher priority ID wins bus access
  Error detection via CRC
  Node states: Error Active → Error Passive → Bus Off

LIN topology:
  1 master + up to 15 slaves
  Single wire serial protocol
  Lower bandwidth than CAN – used as helper protocol

In the lab, a CAN-Motor module was connected to the MediaGateway via CAN-A, and a CANcaseXL on computer 2 accessed it. This allowed CAN data to reach the Ethernet-based system through the gateway.

10. Lab result – imitating CAMF with ANDi+

The final goal of Part IV was to reproduce the CAMF ECU from computer 2 using ANDi scripts, so that ADAS could maintain its SOME/IP subscription after the original simulation was deactivated. The ANDi script was built from Wireshark captures of the real SOME/IP-SD traffic, extracting Service IDs, Instance IDs, Eventgroup IDs, TTL, and version numbers. The reproduced signal was visible in the CANoe trace on computer 1 as an Offer Service notification.

The Acknowledge message was not fully separated from the Offer Service in the final result, likely due to incomplete if-condition logic in the ANDi script. The project identified this as a limitation related to insufficient documentation for this specific SOME/IP-SD scripting pattern.

Tools Used

  • ANDi (Automotive Network Diagnoser) – scripting and traffic viewer
  • Vector CANoe – ECU simulation and trace analysis
  • Vector VN5610 – Ethernet/CAN/USB hardware interface
  • Technica Engineering MediaGateway – automotive Ethernet switch
  • Wireshark – packet capture and SOME/IP-SD inspection
  • Zenmap / Nmap – port scanning and host discovery

Key Challenges

  • Limited ANDi documentation made SOME/IP-SD scripting difficult.
  • Understanding VLAN path configuration across three switch layers.
  • Separating Offer Service and Acknowledge messages in the reproduced script.
  • Both tools (ANDi and CANoe) required valid licences to operate.
  • Finding the correct camera port using Zenmap required knowledge of standard TCP/UDP port numbers.

References and Materials

These sources were used for the SOME/IP protocol specification, BroadR-Reach physical layer, ANDi scripting, Vector hardware, and general automotive networking background.

© 2026 Atam Oguz Erkara