SOME/IP & Service-Oriented Architecture - AUTOSAR Adaptive Platform

SOME/IP Wire Format

SOME/IP (Scalable service-Oriented MiddlewarE over IP) is the wire protocol used by ara::com's SOME/IP binding. Every SOME/IP message begins with an 8-byte header:

Offset	Field	Size	Description
0x00	Service ID	2 bytes	16-bit identifier for the service interface
0x02	Method/Event ID	2 bytes	16-bit method or event ID (events have bit 15 set: 0x8000–0xFFFF)
0x04	Length	4 bytes	Length of remaining message (header bytes 8–end + payload)
0x08	Client ID	2 bytes	Identifies the calling client process
0x0A	Session ID	2 bytes	Increments per request, used to match request/response
0x0C	Protocol Version	1 byte	Always 0x01
0x0D	Interface Version	1 byte	Major version of the ServiceInterface
0x0E	Message Type	1 byte	0x00=REQUEST, 0x02=REQUEST_NO_RETURN, 0x80=NOTIFICATION, 0x40=RESPONSE
0x0F	Return Code	1 byte	0x00=OK, 0x01=NOT_OK, 0x02=UNKNOWN_SERVICE, etc.

SOME/IP Message Structure

Byte:  0    1    2    3    4    5    6    7
      +----+----+----+----+----+----+----+----+
      | Srv ID  | Mth/Evt |      Length       |
      +----+----+----+----+----+----+----+----+
Byte:  8    9   10   11   12   13   14   15
      +----+----+----+----+----+----+----+----+
      | Client  |Session  | PV | IV | MT | RC |
      +----+----+----+----+----+----+----+----+
      [    Payload (serialized application data)    ]

Service/Instance ID Space

Service IDs and Instance IDs are each 16-bit unsigned integers managed by the OEM's service registry. They are declared in the Service Instance Manifest and must be unique across the vehicle network.

Range	Meaning
0x0001 – 0xFFFE	OEM-assigned service IDs
0xFFFF	Wildcard — used in SD FindService to match any instance
0x0000	Reserved

💡 Instance ID

A single Service Interface can be instantiated multiple times on the same ECU (e.g., two CameraService instances for front and rear cameras) with different Instance IDs. The consumer uses the specific Instance ID (or 0xFFFF wildcard) when calling StartFindService().

SOME/IP-SD Packet Flow

SOME/IP-SD (Service Discovery) runs over UDP, default multicast group 239.192.0.1:30490. The SD FSM has three phases:

Phase	Description	Key Timing Parameters
INITIAL_WAIT	Provider waits a random delay before first Offer	InitialDelayMin / InitialDelayMax
REPETITION	Provider sends repeated Offers at doubling intervals	RepetitionBaseDelay × 2^n, max RepetitionMax times
MAIN	Provider sends periodic Offers at steady-state interval	CyclicOfferDelay

SD Offer/Find/Subscribe Sequence

Provider ECU                    Consumer ECU
     |                                  |
     |--- SD OfferService (multicast) -->|
     |                                  |
     |<-- SD FindService (unicast) ------|  (optional)
     |--- SD OfferService (unicast) ---->|
     |                                  |
     |<-- SD SubscribeEventgroup --------|
     |--- SD SubscribeEventgroupAck ---->|
     |                                  |
     |--- SOME/IP Event (UDP) ---------->|  (NotificationType=NOTIFICATION)
     |--- SOME/IP Event (UDP) ---------->|
     ...

SOME/IP-TP (Large Payloads)

SOME/IP Transport Protocol (TP) segments payloads larger than the MTU (typically ~1400 bytes for Ethernet with VLAN headers) into multiple SOME/IP-TP messages.

TP Header Field	Size	Description
Offset	4 bytes (upper 28 bits)	Byte offset of this segment within the full payload
More Segments Flag	1 bit (LSB of offset word)	1 if more segments follow, 0 for last segment

💡 TP Message Type

TP messages use Message Type byte: 0x20 (TP_REQUEST), 0x22 (TP_REQUEST_NO_RETURN), 0x23 (TP_NOTIFICATION), 0x60 (TP_RESPONSE). The receiver reassembles segments based on the Offset field and detects completion when a segment with More Segments=0 arrives. Reassembly timeout is configured in the Service Instance Manifest.

Summary

SOME/IP provides a well-specified wire format for service-oriented Ethernet communication in vehicles. Understanding the header layout, SD state machine, and TP fragmentation is essential for debugging with Wireshark and for configuring Service Instance Manifests correctly.

🔬 SOME/IP Protocol Architecture Deep Dive

SOME/IP (Scalable service-Oriented MiddlewarE over IP) is the dominant middleware protocol for service-oriented communication in modern automotive Ethernet networks. Understanding its wire format and service discovery mechanism is essential for debugging integration issues:

Message header (16 bytes): Service ID (2B) + Method ID (2B) + Length (4B) + Client ID (2B) + Session ID (2B) + Protocol Version (1B) + Interface Version (1B) + Message Type (1B) + Return Code (1B). The Service ID + Method ID combination uniquely identifies the service operation on the network.
Message types: REQUEST (0x00) — expects reply; REQUEST_NO_RETURN (0x01) — fire and forget (Methods only); NOTIFICATION (0x02) — event or field notification; RESPONSE (0x80) — reply to REQUEST; ERROR (0x81) — error reply. Mixing these up causes clients to wait forever for a reply that will never come.
SOME/IP-SD (Service Discovery): Uses UDP multicast on port 30490. The OfferService entry (TTL > 0) advertises a service. FindService queries availability. StopOfferService (TTL = 0) removes it. SD uses a randomised initial delay (InitialDelayMin/Max) to prevent storm on ECU boot. Missing this randomisation causes Ethernet broadcast storms when 20+ ECUs start simultaneously.
Serialisation: SOME/IP uses a flat binary serialisation. SOME/IP-Transformer in Adaptive uses the ara::com Transformer chain. Type mismatches between client and server serialiser versions (e.g., after an interface version update) produce silent data corruption — not connection errors.

🏭 SOME/IP in Production Vehicles

BMW iX / i4 architecture: The Central Domain Controller communicates with Body Domain Controllers using SOME/IP over 100BASE-T1 Automotive Ethernet. Over 300 SOME/IP services are defined in the VSOME/IP configuration for a single vehicle. Wireshark with the SOME/IP dissector plugin is the standard debugging tool.
SOME/IP vs DDS: For high-frequency data (lidar point clouds at 10 Hz, 1M points per scan), DDS with RTI Connext or Eclipse Cyclone DX is preferred over SOME/IP because DDS natively supports pub/sub with QoS (deadline, liveliness). SOME/IP is preferred for low-frequency service calls and configuration operations.
E2E protection on SOME/IP: AUTOSAR E2E Profile 7 is applied on top of SOME/IP payload for safety-relevant services. The E2E header (CRC + counter) is prepended to the serialised data. Configuring E2E on both sides requires identical CRC polynomial and data length — a mismatch causes all messages to be rejected with E2E_STATUS_ERROR.

⚠️ SOME/IP Integration Pitfalls

Service ID / Method ID collision: Two services accidentally configured with the same Service ID on the same network will cause clients to receive responses intended for the wrong service. Use a central SOME/IP ID registry managed in a FIBEX or ARXML system description.
SD InitialDelay not configured: All ECUs broadcasting OfferService simultaneously on boot creates a multicast storm. Configure InitialDelayMin=0 ms, InitialDelayMax=100–500 ms (vary by ECU type) to spread the load.
Method call timeout too short: A SOME/IP method call with RequestResponseTimeout=100 ms to a server on a congested Ethernet switch may legitimately take 150 ms. The client reports TIMEOUT, retries, and the duplicate request arrives at the server causing double-execution of a side-effect-ful operation.
Event subscription without StopSubscribe: If a client application closes without sending StopSubscribeEventgroup, the server continues sending events to a closed socket. These generate ICMP Port Unreachable responses that slowly fill the server's receive buffer — causing subtle memory leak in long-running systems.

📊 Industry Note

AUTOSAR Adaptive R22-11 introduced SOME/IP-SD Multicast Subscription optimisation to reduce subscription traffic in large vehicle networks. Projects using R19-11 or earlier should be aware that each subscriber generates individual SubscribeEventgroup unicast messages — this can cause 200+ UDP packets per second on a 32-ECU network during startup.

🧠 Knowledge Check — Click each question to reveal the answer

❓ What is the purpose of the Session ID field in the SOME/IP header, and how is it used for request-response matching?

✅ The Session ID is a 16-bit counter incremented by the client for each REQUEST. The server copies the Session ID into the RESPONSE header. The client matches responses to pending requests by checking Session ID + Client ID. Without this, if two simultaneous requests to the same Method ID are in flight, the client cannot know which response belongs to which request.

❓ A developer sees that SOME/IP OfferService messages are missing in the network trace after ECU startup. What are the likely causes?

✅ Likely causes: (1) SD not started because the ara::com Runtime is not initialised before ara::com::Runtime::GetInstance().get() is called — check startup order. (2) Wrong multicast IP or port configured in the vsomeip.json / Machine Manifest. (3) The service is in a Function Group that hasn't started yet. (4) A firewall rule in the Linux network namespace is blocking UDP multicast. Use tcpdump on the ECU to confirm whether SD packets are being sent at the kernel level.

❓ What is the difference between a SOME/IP Method and a SOME/IP Event, and when should each be used?

✅ A Method is a client-initiated request to a specific server — like a function call. The client sends REQUEST and expects RESPONSE. Use for: get/set operations, commands with return values, operations with side effects. An Event is server-initiated notification pushed to all subscribers. The client sends SubscribeEventgroup once; the server pushes NOTIFICATION messages on every update. Use for: periodic status updates, asynchronous state changes, telemetry. Events are more efficient for recurring data than repeated Method polls.