SOME/IP Service Discovery, Subscription, and TP — A Practical Walkthrough

Where SOME/IP fits in SOA in-vehicle networks

SOME/IP (Scalable service-Oriented MiddlewarE over IP) is the AUTOSAR middleware for service-oriented in-vehicle communication, carried over Automotive Ethernet. Where classical CAN / LIN networks are signal-centric and rely on cyclic PDU broadcasts, SOME/IP models ECU relationships as service providers and consumers — the same model exposed through ara::com on the AUTOSAR Adaptive Platform. A service is composed of methods, events, and fields; events follow publish / subscribe semantics; and node discovery is performed at runtime by SOME/IP-SD. The protocol is normatively specified in the SOME/IP Protocol Specification (AUTOSAR FO R23-11). This article targets version 4.4.0.

Message types and communication patterns

SOME/IP distinguishes four communication patterns through the Message Type field in the PDU header and the use of the Method ID:

• Request / Response: the consumer issues a Request and the provider returns a Response (synchronous call).
• Fire-and-Forget: the consumer sends a Request without expecting any Response (commands that do not need acknowledgement).
• Notification: the provider pushes events to subscribed consumers — the core of publish / subscribe.
• Error Response: replaces a normal Response when the method fails, carrying a Return Code.

Each method maps to a 16-bit Method ID; events use the upper portion of that field (typically values above 0x8000) to keep them apart from methods.

SOME/IP-SD: Find / Offer / Subscribe flow

SOME/IP-SD (Service Discovery) is the runtime protocol used to locate services dynamically; it is transported over UDP multicast. The core entries are:

• FindService: a consumer searches for providers of a given Service ID / Instance ID.
• OfferService: a provider announces availability with its IP, port, and transport.
• StopOfferService: a provider notifies consumers that it is going offline.
• SubscribeEventgroup: a consumer subscribes to a specific Eventgroup on a provider.
• SubscribeEventgroupAck / Nack: the provider’s response to the subscription request.

The typical flow is:

1. The provider boots and enters the Initial Wait Phase (a randomised delay that prevents broadcast storms).
2. It moves into the Repetition Phase and re-emits OfferService at increasing intervals.
3. It enters the Main Phase, broadcasting Cyclic Offers at a longer fixed period.
4. Consumers receiving an Offer reply with SubscribeEventgroup.
5. The provider replies with SubscribeEventgroupAck and starts pushing notifications to the subscriber, either as unicast or multicast.

Addressing model: Service / Method / Event / Eventgroup ID

SOME/IP messages are addressed by four 16-bit identifiers:

• Service ID: identifies the service type.
• Instance ID: distinguishes multiple instances of the same service type. It is part of SD and endpoint configuration, not of the on-the-wire PDU header.
• Method ID / Event ID: methods and events share the same field; the high bit splits the two namespaces.
• Eventgroup ID: the unit of subscription. A single Eventgroup may bundle multiple events so a consumer subscribes once and receives the entire group.

In ARXML these IDs come from elements such as ServiceInstanceToMachineMapping, ProvidedServiceInstance, and EventHandler. KITE Pulse parses them through the autosar-data crate and exposes the result in its database tree.

PDU header layout and endianness

The SOME/IP header is fixed at 16 bytes and uses big-endian (network byte order):

Field	Width (bits)	Notes
Service ID	16	Service identifier
Method ID	16	Method or Event ID
Length	32	Number of bytes that follow, starting at Request ID
Client ID	16	Distinguishes multiple clients within one node (upper half of Request ID)
Session ID	16	Per-call sequence number (lower half of Request ID)
Protocol Version	8	Currently 0x01
Interface Version	8	Service interface version
Message Type	8	Request / Response / Notification / Error / TP variants
Return Code	8	E_OK or an error code

Payload encoding may be little-endian or big-endian as defined in the ARXML; the SOME/IP specification does not impose a fixed payload byte order, and decoders must follow the database.

SOME/IP-TP segmentation

When a payload exceeds the size of a single UDP datagram (commonly capped around 1400 bytes in practice), SOME/IP-TP segmentation is used:

• The Message Type carries the 0x20 bit to indicate a TP variant (for example RequestTp, NotificationTp).
• A 4-byte TP header is appended after the SOME/IP header. The upper 28 bits encode the Offset in 16-byte units (to keep the field within range); the lowest bit is the More Segments flag.
• The receiver reassembles segments by Service / Method / Client / Session ID; the last segment carries More Flag = 0.

TP itself does not provide retransmission. Reliability has to come from a higher layer or from TCP, when the service uses TCP transport.

A hands-on SOME/IP capture in KITE Pulse

KITE Pulse ships with a complete SOME/IP stack. A typical capture session looks like this:

1. Load the ARXML describing services, event groups, and endpoints into DatabasePanel. The tool parses it with autosar-data and lists the Service / Eventgroup hierarchy.
2. Open an Ethernet channel on the relevant NIC through ExplorerPanel (open_eth_channel) so the host can receive SD multicast traffic.
3. Observe service discovery: PacketDecodePanel decomposes the multicast SD frames into Find / Offer / Subscribe entries, letting you verify the provider’s IP, port, and transport.
4. Subscribe to an Eventgroup with the node_someip_subscribe Tauri command for the target Service / Instance / Eventgroup, and watch the SubscribeEventgroupAck arrive in TracePanel.
5. Decode notifications: once the subscription is active, the notifications pushed by the provider are decoded through the ARXML types and can be dragged into SignalPanel for live plotting.
6. Record to BLF: call start_recording followed by save_recording to keep the entire SOME/IP capture as a .blf file for offline review.

To act as a provider instead, use node_someip_init followed by node_someip_offer.

Common questions

Multicast group address: SOME/IP-SD typically uses an administratively-scoped IPv4 multicast group (often in the 239.x.x.x range). The exact address comes from the SD configuration in the ARXML, and the network team must ensure switches do not filter the corresponding IGMP group.

No Offer during the Initial Wait Phase: the specification requires the provider to apply a randomised delay before entering the Repetition Phase. If the observation window is shorter than that delay, the service may appear to be missing. Extend the capture window or check the InitialDelay range in the SD configuration.

Repetition Phase timing: the initial interval and the maximum number of repetitions are governed by InitialOfferBehavior in the ARXML. The interval typically doubles between OfferService transmissions until the provider switches into the Main Phase with its longer Cyclic Offer period. When debugging a discovery problem, comparing the Repetition versus Main timing in TracePanel quickly separates “the offer never went out” from “the SubscribeEventgroupAck never came back”.