Automotive Ethernet · SOME/IP-SD · Vector CANoe

SOME/IP Service Discovery Analysis with ANDi & Vector

This page documents an automotive Ethernet connectivity case study focused on SOME/IP and SOME/IP-SD traffic analysis. The project used Vector CANoe to simulate CAMF and ADAS ECUs, a Vector VN5610 interface to connect the simulated bus to the Ethernet setup, and ANDi with Wireshark to inspect and reproduce selected service discovery messages.

View References →

Overview

SOME/IP provides service-oriented communication for automotive ECUs through RPC-style calls, event notifications, and a defined wire format. Service discovery and subscription handling are managed by SOME/IP-SD. In this project, CAMF acted as a camera service provider, while ADAS searched for the service, subscribed to the event group, and received cyclic notification traffic.

The work connects CANoe based virtual ECU simulation with hardware-assisted Ethernet communication and packet-level analysis. The final experiment attempted to imitate selected CAMF SOME/IP-SD messages with ANDi after the original CAMF simulation was deactivated. The reproduced traffic was visible in CANoe, but the Offer Service and Subscribe Eventgroup Acknowledgment messages were not fully separated in the final script.

Project Flow

1CANoe simulated CAMF and ADAS ECUs
2SOME/IP-SD traffic captured with ANDi and Wireshark
3Find Service, Offer Service, and Subscribe Eventgroup sequence analysed
4Selected CAMF service behaviour reproduced with ANDi scripts

Key Concepts and Findings

1. Automotive Ethernet project scope+

The project focused on analysing service-oriented communication in an automotive Ethernet setup. The main objective was to observe SOME/IP and SOME/IP-SD traffic between two simulated ECUs, understand the discovery sequence, and reproduce selected provider-side service discovery behaviour with ANDi generated frames.

Technical detail

Main workflow:
  CANoe simulates CAMF and ADAS ECUs
  VN5610 connects CANoe traffic to the Ethernet setup
  MediaGateway provides the automotive Ethernet switching path
  ANDi and Wireshark observe SOME/IP-SD traffic
  ANDi scripts reproduce selected CAMF messages

The page intentionally focuses on the SOME/IP case study. General lab activities such as camera access, port scanning, VLAN exercises, and raw Ethernet loopback tests are not included.

2. SOME/IP protocol+

SOME/IP, Scalable service-Oriented MiddlewarE over IP, enables service-oriented communication between automotive ECUs. It supports remote procedure calls, event notifications, and a defined wire format over UDP or TCP. In this project, SOME/IP was used as the application level communication mechanism between the simulated camera provider and the ADAS consumer.

Technical detail

SOME/IP message structure:
  Message ID     [32 bit]  → Service ID + Method ID or Event ID
  Length         [32 bit]  → Message length after this field
  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]

Transport:
  UDP  → commonly used for service discovery and notifications
  TCP  → supports larger segmented payloads

SOME/IP transports service data. Service discovery and subscription handling belong to SOME/IP-SD, which must be described separately to avoid mixing the protocol roles.

3. SOME/IP service model+

A SOME/IP service can contain methods, events, and fields. Methods represent remote procedure calls. Events transmit data periodically or whenever a change occurs. Fields combine notifier, getter, and setter behaviour. In the investigated setup, CAMF behaved as the service provider and ADAS behaved as the consumer that searches for the service and subscribes to the event group.

Technical detail

Service roles:
  CAMF  → Camera service provider
  ADAS  → Service consumer / subscriber

Service elements:
  Method  → request and response interaction
  Event   → provider sends data to subscribers
  Field   → notifier + getter + setter semantics

The important engineering task was not only to send a frame. The frame had to match the expected service discovery state machine between CAMF and ADAS.

4. SOME/IP-SD discovery sequence+

SOME/IP-SD manages the service discovery lifecycle. The consumer first searches for a service. The provider answers with an offer. The consumer then subscribes to an event group, and the provider acknowledges the subscription. Only after this sequence can the consumer treat the provider as an available service source.

Technical detail

Expected SOME/IP-SD sequence:

  ADAS  →  Find Service
  CAMF  →  Offer Service
  ADAS  →  Subscribe Eventgroup
  CAMF  →  Subscribe Eventgroup Acknowledgment

After CAMF deactivation:
  ADAS  →  repeatedly sends Find Service
  CAMF  →  no provider response is available

This sequence became the central evidence for understanding what had to be reproduced by the ANDi script.

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

The hardware path used automotive Ethernet through BroadR-Reach / 100BASE-T1. This physical layer provides 100 Mbit/s full-duplex Ethernet communication over a single twisted pair. In the project, it formed the connection between the Vector VN5610 interface and the MediaGateway.

Technical detail

100BASE-T1 key properties:
  Speed:        100 Mbit/s full duplex
  Cable:        single twisted pair
  Modulation:   PAM3
  Use case:     automotive Ethernet links

Traffic path:
  CANoe host → VN5610 → 100BASE-T1 → MediaGateway → ANDi / Wireshark

This should be presented as an automotive Ethernet lab topology, not as a real in-vehicle deployment.

6. CANoe, VN5610, and MediaGateway integration+

Vector CANoe simulated the CAMF and ADAS ECUs. The Vector VN5610 acted as the hardware interface between the CANoe host and the automotive Ethernet setup. The MediaGateway provided the switching path that allowed traffic generated from CANoe to be observed from another machine using ANDi and Wireshark.

Technical detail

VN5610 connections:
  CH1  →  MediaGateway S3-P3 via BroadR-Reach / 100BASE-T1
  CH2  →  not used in this project
  USB  →  CANoe host machine

CANoe configuration:
  Project: SOMEIPBasicAutosar
  Ethernet channel: IEEE 100BASE-T1 (BR), Master (DSUB9)

Observed simulated ECUs:
  CAMF  → camera service provider
  ADAS  → advanced driver assistance consumer

The VN5610 should be described as an interface, not as an IP endpoint. The relevant ECU addressing belongs to the CANoe simulation context.

7. ANDi and Wireshark traffic analysis+

ANDi was used to observe automotive Ethernet traffic and prepare script based SOME/IP frame generation. Wireshark was used to inspect the packet fields in detail. The captured traffic helped identify Service ID, Instance ID, Eventgroup ID, TTL, version fields, and the structure of the SOME/IP-SD entries required for reproducing CAMF behaviour.

Technical detail

Extracted information from captured traffic:
  Service ID
  Instance ID
  Eventgroup ID
  TTL
  Major / minor version information
  SOME/IP-SD entry type
  Session ID behaviour

Main tools:
  CANoe trace window
  ANDi Traffic Viewer
  Wireshark SOME/IP-SD packet inspection

The value of this step was translating observed CANoe and Wireshark evidence into the fields needed by the ANDi generated message.

8. Reproducing selected CAMF behaviour+

The final implementation attempted to reproduce selected CAMF SOME/IP-SD behaviour from the second machine using ANDi scripts. After the original CAMF node was deactivated in CANoe, ANDi generated frames were sent back into the setup. CANoe received the reproduced traffic as Offer Service behaviour.

Technical detail

Reproduction goal:
  1. Deactivate simulated CAMF in CANoe
  2. Keep ADAS active
  3. Generate CAMF-like SOME/IP-SD frames with ANDi
  4. Observe whether CANoe receives provider-side service discovery traffic

Observed result:
  Reproduced traffic appeared as Offer Service in CANoe

This should be described as partial reproduction, not a fully working ECU emulator.

9. Final limitation+

The reproduced frames were visible in CANoe, but the final script did not cleanly separate the expected Subscribe Eventgroup Acknowledgment behaviour from the Offer Service message. The likely reason was incomplete conditional logic in the ANDi script and limited documentation for this specific SOME/IP-SD scripting pattern.

Technical detail

Final status:
  Offer Service reproduction       → visible in CANoe
  Subscribe Eventgroup Ack split   → incomplete
  Full CAMF ECU replacement        → not achieved

Correct positioning:
  SOME/IP-SD traffic analysis and partial provider behaviour reproduction

This limitation should stay visible. It makes the project technically honest and prevents the page from overclaiming a fully functional ECU imitation.

Tools Used

  • Vector CANoe – virtual ECU simulation and trace analysis
  • Vector VN5610 – automotive Ethernet hardware interface
  • ANDi – SOME/IP traffic viewing and script-based frame generation
  • Wireshark – packet capture and SOME/IP-SD field inspection
  • Technica Engineering MediaGateway – automotive Ethernet switching path

Key Challenges

  • Understanding the SOME/IP-SD sequence between CAMF and ADAS.
  • Mapping CANoe trace information to ANDi-generated SOME/IP-SD frames.
  • Extracting Service ID, Instance ID, Eventgroup ID, TTL, and version fields from captured traffic.
  • Reproducing CAMF Offer Service traffic after deactivating the original simulated provider.
  • Separating Offer Service and Subscribe Eventgroup Acknowledgment behaviour in the final ANDi script.

References and Materials

These sources support the protocol description, BroadR-Reach physical layer background, ANDi scripting context, Vector hardware integration, and automotive Ethernet analysis.