SOME/IP Service Discovery Explained: What Test Engineers Need to Know

SOME/IP Service Discovery is the mechanism by which AUTOSAR Adaptive ECUs advertise their services and find the services they depend on. It sits between your application code and the Ethernet network - invisible when it works, catastrophic when it does not.

For test engineers, SD is the entry point to every SOME/IP test scenario. If service discovery fails, nothing else in the SOME/IP layer works. Understanding SD is not optional - it is the prerequisite for testing any SOME/IP service on a domain controller.

What Service Discovery Actually Does

SOME/IP SD has three distinct functions that test suites must cover separately:

1. Service Offering (OfferService) - A server application announces its service on the network. The SD daemon sends an OfferService message (multicast UDP to 224.224.224.245:30490 by default) containing the Service ID, Instance ID, Major Version, and TTL (time-to-live). Any client that is looking for this service - or that receives it as a broadcast - can now connect.

2. Service Finding (FindService) - A client application that has not yet received an offer for the service it needs sends a FindService multicast request. Any server offering the requested service responds with a unicast OfferService directly to the requesting client.

3. EventGroup Subscription (SubscribeEventgroup) - After a client receives an OfferService, it can subscribe to EventGroups to receive event notifications. The client sends a SubscribeEventgroup to the server's unicast address. The server responds with a SubscribeEventgroupAck.

These three operations have different timing properties, different failure modes, and different test requirements.

The SD State Machine - What Your Test Must Drive

SOME/IP SD servers go through a state machine before they start offering services: Initial Wait Phase → Repetition Phase → Main Phase. This means a newly started server does not immediately send an OfferService. It waits an initial delay (INITIAL_DELAY_MIN to INITIAL_DELAY_MAX, typically 0–100ms), then sends a configurable number of repetitions (REPETITIONS_MAX, typically 3) with increasing inter-repetition delays, then settles into cyclic offers at CYCLIC_OFFER_DELAY (typically 1000ms).

Test implication: a test case that expects an OfferService immediately after ECU startup will fail during the Initial Wait Phase. Your test must either wait for the offer (with an appropriate timeout) or send a FindService to trigger an immediate unicast offer.

The correct test pattern:

1. Start the SOME/IP Client Agent in FindService mode
2. Send FindService for the target Service ID + Instance ID
3. Assert a unicast OfferService is received within 500ms
4. Proceed with method calls and event subscriptions

Using FindService bypasses the Initial Wait Phase and makes your test deterministic - it does not depend on the server's offer timing configuration.

TTL Expiry - The Failure No One Tests

Every OfferService message carries a TTL field - the time in seconds for which the offer is valid. If the server does not renew the offer (by sending another OfferService before TTL expires), the client should consider the service gone and tear down its connections.

Most SOME/IP test suites never test TTL expiry. Here is what happens when they do not: the server crashes or restarts, its SD daemon stops sending offers, the TTL expires on the client side - but the client's SOME/IP stack continues to consider the service available because TTL validation is not implemented correctly. The client sends method calls into the void and receives no response, but the application layer reports the service as "connected" for minutes until a different timeout catches it.

Test TTL expiry explicitly: start the SOME/IP Server Agent, let the client subscribe, then stop the server daemon (simulated by stopping OfferService transmission). Measure how long until the client correctly detects service unavailability. Assert detection occurs within 2× TTL. If the client does not detect it within 3× TTL, the SOME/IP stack's TTL validation is broken.

EventGroup Subscription - Three Failure Modes Worth Testing

Multicast vs unicast delivery: SOME/IP events can be delivered via multicast (to a multicast group) or unicast (point-to-point). The delivery method is determined by the EventGroup configuration. Test both: subscribe two clients and verify multicast events reach both; subscribe with a unicast-configured EventGroup and verify events are delivered directly to the subscriber's unicast address, not broadcast to the multicast group.

Subscription expiry and renewal: EventGroup subscriptions have their own TTL. If the client does not renew the subscription before TTL expiry, the server stops delivering events to that client. Test that your client correctly renews subscriptions, and that events resume immediately after renewal without requiring a FindService/OfferService cycle.

StopOfferService behaviour: When a server sends StopOfferService (TTL=0), all subscriptions should be implicitly terminated. Test that a client receiving StopOfferService correctly stops expecting events, and correctly re-subscribes after the server restarts and offers the service again.

The Practical Testing Sequence

A minimal SOME/IP SD test suite covers these five cases in order:

1. FindService → receive OfferService within timeout ✓
2. Subscribe to EventGroup → receive SubscribeEventgroupAck ✓
3. Receive events at correct rate with correct payload ✓
4. Server StopOfferService → client detects service gone within 2×TTL ✓
5. Server restart and re-offer → client re-subscribes without FindService (server should offer proactively) ✓

If all five pass, your SOME/IP SD implementation is solid. If any fail, you have found a defect that will cause intermittent, hard-to-reproduce failures in the vehicle integration lab - exactly the kind of failure that takes three days to root-cause in a multi-ECU network.