The problem
Modern vehicles move from fixed CAN signal lists to services that ECUs offer and find at runtime over automotive Ethernet. SOME/IP and its Service Discovery protocol are the standard way AUTOSAR systems do this, but students rarely see the messages on the wire. This project builds a working service setup, makes the discovery process visible and measures how it behaves when a provider starts late or fails.
Objectives
- Explain SOME/IP message structure, method calls, events and eventgroups.
- Build and configure vsomeip on Linux with JSON configuration files.
- Implement a provider offering a method and an event, and a consumer that calls and subscribes.
- Capture and decode SOME/IP and SOME/IP-SD traffic in Wireshark.
- Measure call latency, discovery time and recovery after a provider restart.
What you need
Tools and toolboxes
- vsomeip (COVESA) — Open-source SOME/IP and SOME/IP-SD implementation used for the provider and consumer applications.
- C++ with CMake and GCC — Builds vsomeip and the service applications on Linux.
- Wireshark — Captures traffic and decodes SOME/IP headers and Service Discovery entries with its built-in dissectors.
- Linux network namespaces or two virtual machines — Separates provider and consumer so traffic really crosses a network interface.
- Python with pandas and matplotlib — Parses timing logs and plots latency and discovery-time distributions.
Software
- Ubuntu Linux
- vsomeip with Boost
- CMake and GCC
- Wireshark
- Python with pandas and matplotlib
Extra parts and data
None beyond the software above.
Key concepts
- SOME/IP
- Scalable service-Oriented MiddlewarE over IP: a header with service ID, method or event ID, client and session IDs, message type and return code, carried over UDP or TCP. It supports request/response, fire-and-forget and events.
- Service Discovery (SOME/IP-SD)
- A protocol on UDP multicast in which providers send OfferService entries and consumers send FindService and SubscribeEventgroup entries, so endpoints find each other without fixed addresses.
- Eventgroup
- A set of events that a consumer subscribes to together. The provider only sends events to subscribers whose subscription it has acknowledged.
- Serialisation
- Converting structured data such as a list of radar objects into a byte payload with agreed order, lengths and alignment, so both sides read it the same way.
Step-by-step guide
- 1
Define the service interface
Write a short interface specification for a RadarObjects service: a service ID and instance ID, a method GetObjectCount that returns an integer, and an event ObjectList in an eventgroup, sent at 20 Hz, carrying up to 16 objects with ID, range, relative speed and azimuth as fixed-size fields. State the transport (UDP for the event, TCP or UDP for the method) and the expected payload size. Also write requirements for discovery time and method latency to measure later.
Checkpoint: An interface table with IDs, payload layout in bytes and numeric targets for latency and discovery.
- 2
Build vsomeip and run the examples
Install the build dependencies, including Boost, then clone and build vsomeip with CMake. Run the bundled hello-world or request-response examples on one machine using the routing manager, and read the provided JSON configuration files to understand unicast address, applications, services and the routing section. Set VSOMEIP_CONFIGURATION and VSOMEIP_APPLICATION_NAME environment variables so each process loads the right file. Keep notes of every configuration key you change.
Checkpoint: A bundled example runs and the console log shows the service being offered and the request answered.
- 3
Set up two network endpoints
Create two Linux network namespaces joined by a veth pair, or two virtual machines on a host-only network, each with its own IP address. Give each endpoint its own vsomeip configuration with its unicast address and the service-discovery multicast address and port. Confirm that multicast traffic passes between them, because Service Discovery depends on it. Start Wireshark on the shared interface before running anything so you capture the first offers.
Checkpoint: Ping and a multicast test work between the endpoints, and Wireshark sees packets on the interface.
- 4
Implement the provider
Write the provider in C++: create the vsomeip application, register a message handler for GetObjectCount, offer the service with offer_service, and offer the event with offer_event in its eventgroup. In a timer thread, generate synthetic radar objects, serialise them into a payload with explicit byte order, and call notify at 20 Hz. Add a sequence counter and a send timestamp inside the payload so the consumer can measure loss and latency.
Checkpoint: The provider runs, and Wireshark shows OfferService entries in SOME/IP-SD packets with the correct service ID.
- 5
Implement the consumer
Write the consumer: register an availability handler, call request_service, and when the service becomes available send GetObjectCount requests and subscribe to the eventgroup with request_event and subscribe. In the message handler, deserialise the object list, check the sequence counter for gaps and log receive time minus send time. Use a shared clock source such as both namespaces on one host, or note clock offset if using separate machines.
Checkpoint: The consumer prints decoded object lists at 20 Hz and receives correct method responses.
- 6
Decode traffic in Wireshark
Enable the SOME/IP and SOME/IP-SD dissectors and decode on the ports from your configuration. Identify OfferService, FindService, SubscribeEventgroup and SubscribeEventgroupAck entries, their TTL fields and the options carrying endpoint addresses. Find a request and its response by matching client and session IDs. Annotate screenshots of each message type for the report, and export the capture so examiners can open it.
Checkpoint: Annotated captures showing each SD entry type and one matched request/response pair.
- 7
Measure latency and discovery time
Run 10,000 method calls and record round-trip times. Log event one-way latency over several minutes at 20 Hz. For discovery time, start the consumer first, then the provider, and measure from provider start to the consumer availability callback; repeat 30 times. Then vary the initial delay and repetition settings in the SD configuration and repeat. Plot distributions and report median and 99th percentile rather than averages alone.
Checkpoint: Histograms of method latency, event latency and discovery time with median and 99th-percentile values.
- 8
Test failure and recovery
Kill the provider during operation and measure how long the consumer takes to report the service unavailable, which depends on the offer TTL and whether a StopOfferService is sent. Restart it and measure time until events resume. Add tc netem packet loss of 1 and 5 per cent on the interface and record event loss and method retries. Compare a graceful stop with a crash, because the consumer sees them very differently.
Checkpoint: A table of detection and recovery times for graceful stop, crash and packet-loss cases.
- 9
Report
Document the interface specification, configuration files, code structure, annotated Wireshark captures and all measurements against the requirements set in step one. Explain where SOME/IP sits in an AUTOSAR Adaptive system and how ara::com would wrap what you wrote by hand. State the limits: software endpoints on one host, no real automotive Ethernet PHY and synthetic radar data. Include build instructions so another student can reproduce the results.
Checkpoint: A report with reproducible build steps, captures and measured results compared with the targets.
Testing & validation
- Wireshark decodes all SD entries and SOME/IP headers with correct IDs.
- Method round-trip latency distribution over 10,000 calls.
- Event loss and latency at 20 Hz with and without injected packet loss.
- Discovery time over 30 repetitions for different SD timing settings.
- Detection and recovery times after provider stop and crash.
Expected results
A working SOME/IP provider and consumer pair on vsomeip with annotated captures of Service Discovery and measured latency, discovery and recovery behaviour.
Take it further
- Add a second provider instance and test load sharing between instances.
- Generate the serialisation code from an interface description instead of writing it by hand.
- Bridge the event into ROS 2 for visualisation.
- Compare UDP and TCP transport for the method under packet loss.
Viva and review questions
Why does SOME/IP need Service Discovery?
It lets providers announce services and consumers find them at runtime, so addresses and ports need not be hard-coded and services can start in any order.
What is the difference between a method and an event?
A method is a request from the consumer, optionally with a response. An event is pushed by the provider to all acknowledged subscribers of its eventgroup.
Why did you report the 99th percentile latency?
Safety-relevant consumers care about worst-case delays, and a mean can look good while occasional slow messages would still violate a deadline.
How does the consumer notice that a crashed provider is gone?
Without a StopOfferService, it relies on the offer TTL expiring or on missing responses, so the TTL setting directly sets detection time.
Learn it at DIYguru
These DIYguru courses and programmes teach what this project needs.