SOME/IP Deep Dive

Advanced12 min read

Assumes: 3.2 Service-Oriented Architecture

TL;DR

SOME/IP (Scalable service-Oriented MiddlewarE over IP) is the automotive wire protocol for SOA on Ethernet. It defines methods (RPC), events (pub/sub), and fields (get/set/notify) with a binary header and typed serialization. SOME/IP-SD handles service discovery via multicast: providers Offer, consumers Find, event subscribers Subscribe. It runs over UDP (fast, fire-and-forget) and TCP (reliable RPC) on Automotive Ethernet (100BASE-T1 / 1000BASE-T1). Payloads serialize with a defined binary layout (from FIDL/ARXML code generation). Compared to DDS, SOME/IP is lighter, AUTOSAR-native, and dominant in cockpit/body domains. DDS targets ADAS/AD with richer QoS.

SOME/IP is the protocol behind the SOA concepts in Module 3.2, and the reason your “lb” OTA tool can discover update services without a hardcoded IP list. If you’ve seen vsomeip, CommonAPI, or the magical multicast address 224.244.224.245 in a Wireshark capture, you’ve already met SOME/IP — you just didn’t know its name yet.

SOME/IP Message Anatomy

Every SOME/IP message has a 16-byte header followed by a payload:

Header Field	Size	Purpose
Service ID	16 bit	Which service (e.g. 0x1234 = UpdateManagement)
Method/Event ID	16 bit	Which method or event within the service
Length	32 bit	Total bytes after length field
Client ID	16 bit	Who sent this (for routing responses)
Session ID	16 bit	Match request to response
Protocol Version	8 bit	Always 0x01
Interface Version	8 bit	Service interface version
Message Type	8 bit	Request, response, notification, error, SD
Return Code	8 bit	OK, not ready, unknown service, etc.

Service ID plus Method ID tells you what service and what action, like a phone number plus extension.

Three Communication Patterns

Methods (RPC)

Methods use request/response, typically over TCP for reliability:

sequenceDiagram
    participant Client as OTA Client (lb tool)
    participant Server as UpdateManagement Service

    Client->>Server: REQUEST (ServiceID=0x1234, MethodID=0x0001)<br/>startDownload(packageId)
    Note over Client,Server: TCP — reliable delivery
    Server->>Client: RESPONSE (ReturnCode=OK)<br/>sessionId, status=ACCEPTED

Message Type	Value	Direction
REQUEST	0x00	Client → Server
RESPONSE	0x80	Server → Client
ERROR	0x81	Server → Client (failure)

Events (Pub/Sub)

Events are fire-and-forget notifications, typically over UDP:

sequenceDiagram
    participant Sub as AAOS Consumer
    participant SD as SOME/IP-SD
    participant Pub as ClimateService

    Sub->>SD: SUBSCRIBE (EventGroup=0x0001)
    SD->>Pub: Subscribe acknowledgment
    Pub->>Sub: EVENT (MethodID=0x8001)<br/>CabinTempChanged(22.5°C)
    Note over Pub,Sub: UDP multicast or unicast

Event IDs use the high bit: 0x8000 | eventId distinguishes events from methods in the Method/Event ID field.

Fields (Get / Set / Notify)

Fields map to three method IDs under the hood:

Field Operation	SOME/IP Mapping	Transport
Getter	Method call (request/response)	TCP
Setter	Method call (request/response)	TCP
Notifier	Event (subscription + push)	UDP

From the application perspective, you call getSpeed() or subscribe to speed changes. The SOME/IP stack translates that into the correct method/event IDs from the service’s FIDL definition.

Mental Model

SOME/IP is a postal system with typed envelopes. The Service ID is the department (UpdateManagement, DoorService). The Method/Event ID is the form number (startDownload, DoorStatusChanged). The Client ID + Session ID is the return address + tracking number so responses find the right caller. SOME/IP-SD is the building directory in the lobby — it tells you which department is on which floor (IP + port).

Mnemonic: Count the 16-byte header — Service ID + Method ID + Length + Client ID + Session ID + versions + type + return code. If the envelope is wrong, the department rejects the letter.

Think About It

Your Wireshark capture shows SOME/IP packets on the network but no service is responding. Where do you look first?

Reveal Answer

Start at the SOME/IP-SD layer, not the RPC payload: filter udp.port == 30490 and verify FindService gets an OfferService back with the correct Service ID, Instance ID, IP, and port. Packets on the wire with no response usually mean VLAN/multicast routing is dropping 224.244.224.245, the provider never registered an OFFER in vsomeip logs, or Service ID / Interface Version mismatch causes the stack to reject the request before TCP RPC even connects.

SOME/IP-SD: Service Discovery

SOME/IP-SD (Service Discovery) runs as a special SOME/IP service (Service ID 0xFFFF) over UDP multicast. Default address: 224.244.224.245:30490.

sequenceDiagram
    participant Provider as Zone Controller
    participant Multicast as 224.244.224.245:30490
    participant Consumer as QNX Gateway
    participant Subscriber as AAOS App (via QNX proxy)

    Provider->>Multicast: OFFER (Service=DoorService, Instance=0x0001,<br/>IP=192.168.1.10, Port=30501, Version=1.0)
    Consumer->>Multicast: FIND (Service=DoorService, Instance=any)
    Multicast->>Consumer: OFFER (from Provider — unicast response)
    Consumer->>Provider: TCP REQUEST lock(doorId=FL)

    Subscriber->>Multicast: SUBSCRIBE (EventGroup=DoorEvents)
    Provider->>Subscriber: EVENT DoorStatusChanged (UDP unicast/multicast)
    Provider->>Multicast: OFFER (repeated at TTL interval — heartbeat)

SD Entry Types

Entry Type	Flag	Meaning
FindService	0x00	“Is anyone offering Service X?”
OfferService	0x01	“I’m offering Service X at this IP:port”
StopOfferService	0x01 (TTL=0)	“I’m going away”
SubscribeEventgroup	0x06	“Notify me of events in group Y”
SubscribeEventgroupAck	0x07	“Subscription confirmed”
StopSubscribeEventgroup	0x06 (TTL=0)	“Unsubscribe”

TTL (Time To Live): Offers and subscriptions expire if not refreshed. Provider re-sends Offer every TTL seconds. If TTL expires without refresh, consumers mark the service as unavailable.

Common Gotcha

If service discovery works in the lab but not in the vehicle, check VLAN and multicast routing first.

Automotive Ethernet uses 802.1Q VLANs to segregate domains (infotainment, ADAS, OBD). SOME/IP-SD multicast must be permitted on the VLAN between provider and consumer. A misconfigured switch ACL silently drops 224.244.224.245 — Find gets no Offer, and everything looks like “service not available.”

Common Gotcha

Beginner thinks SOME/IP is a transport protocol like TCP.

Reality: SOME/IP is middleware — it rides on UDP/TCP over IP. It defines service addressing, serialization, RPC patterns, and discovery (SOME/IP-SD). The transport layer underneath is still plain IP/Ethernet; SOME/IP adds the automotive service contract on top.

Transport: UDP vs TCP on Automotive Ethernet

Transport	Used For	Why
UDP	Events, SD messages, small notifications	Low latency, multicast-capable, loss tolerable for periodic data
TCP	Methods (RPC), large payloads, file transfer	Reliable delivery, flow control, connection-oriented

Automotive Ethernet physical layer:

• 100BASE-T1: 100 Mbps over single twisted pair (most common in production today)
• 1000BASE-T1: 1 Gbps (newer platforms, ADAS backbone)
• 802.1AS (gPTP): time synchronization across the network
• 802.1Qbv (TAS): time-aware scheduling for deterministic traffic

SOME/IP sits at Layer 7 (application) over standard IP. It doesn’t care about the physical layer as long as IP packets flow.

Serialization Format

SOME/IP payloads use a binary serialization defined by the service interface (typically from FIDL, Franca IDL, or AUTOSAR ARXML):

Data Type	Serialization
uint8/16/32/64	Big-endian fixed width
float/double	IEEE 754 big-endian
string	Length prefix (4 bytes) + UTF-8 bytes + null padding to 4-byte boundary
array	Length prefix + repeated elements
struct	Fields in declaration order, each aligned to 4-byte boundary
enum	Underlying integer type

Code generators (CommonAPI, ara::com, proprietary tools) produce serialize/deserialize functions from the IDL. You never hand-pack bytes.

Example mental layout for startDownload(packageId: string):

[4 bytes: string length][N bytes: packageId UTF-8][padding to 4-byte align]

SOME/IP-TP: Large Payloads

Standard SOME/IP over UDP has a practical payload limit (~1400 bytes MTU). SOME/IP-TP (Transport Protocol) segments larger payloads across multiple SOME/IP messages with segment counters, similar in purpose to ISO-TP on CAN. You’ll encounter SOME/IP-TP when transferring firmware metadata, large configuration blobs, or log files over the service layer. Your OTA tool may use SOME/IP-TP for manifest delivery and gRPC for the actual binary image.

SOME/IP vs DDS

Both are middleware for publish/subscribe and RPC on Ethernet, but they target different domains:

	SOME/IP	DDS (Data Distribution Service)
Origin	AUTOSAR / BMW → industry standard	OMG standard, ROS 2 compatible
Discovery	SOME/IP-SD (centralized multicast)	SPDP/SEDP (distributed peer discovery)
QoS policies	Basic (TTL, reliable/unreliable)	Rich (deadline, lifespan, liveliness, history, durability)
Data model	Service-centric (methods/events/fields)	Topic-centric (typed data streams)
Serialization	SOME/IP binary (from FIDL)	CDDR / XCDR
Typical domain	Cockpit, body, comfort, OTA	ADAS, AD, sensor fusion, simulation
Tooling	vsomeip, CommonAPI, Vector CANoe	RTI Connext, CycloneDDS, FastDDS
Footprint	Lighter, designed for ECUs	Heavier, designed for compute platforms
Your daily life	QNX services, OTA discovery, body control	Less common unless on ADAS team

Think of it this way: SOME/IP for services in the cockpit, DDS for data streams in ADAS.

Full Communication Flow

flowchart TB
    subgraph Discovery["Phase 1: Service Discovery (UDP multicast)"]
        OFFER["Provider → OFFER<br/>Service 0x1234 @ 192.168.1.10:30501"]
        FIND["Consumer → FIND<br/>Service 0x1234"]
        OFFER_RESP["Provider → OFFER response<br/>(IP, port, version)"]
        FIND --> OFFER_RESP
        OFFER -.->|"multicast 224.244.224.245:30490"| FIND
    end

    subgraph RPC["Phase 2: Method Call (TCP)"]
        REQ["Consumer → REQUEST<br/>Method 0x0001: startDownload()"]
        RESP["Provider → RESPONSE<br/>ReturnCode=OK"]
        REQ --> RESP
    end

    subgraph Events["Phase 3: Event Subscription (UDP)"]
        SUB["Consumer → SUBSCRIBE<br/>EventGroup 0x0001"]
        ACK["Provider → SubscribeAck"]
        EVT["Provider → EVENT<br/>DownloadProgress(45%)"]
        SUB --> ACK
        ACK --> EVT
    end

    Discovery --> RPC
    RPC --> Events

Where You'll See This

SOME/IP is everywhere in your stack. Here’s where to look:

• Wireshark filter: someip || udp.port == 30490 captures service messages and SD traffic. Look for Service ID, Method ID, and Return Code in the dissector.
• vsomeip / CommonAPI config JSON defines application name, service IDs, instance IDs, multicast address, and port bindings. Misconfigured unicast or diagnosis address = SD works but RPC fails.
• QNX logs: grep for OFFER, FIND, SUBSCRIBE, on_availability. The vsomeip runtime logs service lifecycle events.
• “lb” OTA tool uses SOME/IP-SD to Find the UpdateManagement service, then calls methods over TCP to start/prepare downloads. If discovery fails, the tool can’t find the service endpoint. Check VLAN and SD multicast first.
• Service version mismatches: Interface Version in the header must match. Provider offers v2, consumer expects v1 → E_WRONG_PROTOCOL_VERSION. Check FIDL/ARXML version fields in both repos.

When someone says “SOME/IP is broken,” ask three questions: (1) Is SD working? (Offer/Find visible in Wireshark?) (2) Is the RPC connection established? (TCP SYN-ACK?) (3) Does the payload deserialize? (Return code OK but garbage data = IDL mismatch.)

Connect the Dots

Module 3.2 (SOA) explains why services exist. This page explains how they’re encoded on the wire. Module 3.4 (gRPC) covers the complementary protocol for QNX↔AAOS and tool↔vehicle data transfer. Module 0 (Physical Interfaces) covers Automotive Ethernet PHYs; Module 2 (Zonal Architecture) shows where SOME/IP runs between zone controllers and central compute. Page 9.5 (Vector Toolchain) covers CANoe with the Ethernet option — the tool for testing SOME/IP services: observing SD multicast, injecting method calls, and running restbus simulations with the SOME/IP interaction layer.

The short version

1. SOME/IP encodes methods (RPC), events (pub/sub), and fields (get/set/notify) with a 16-byte header.
2. SOME/IP-SD discovers services via UDP multicast: Offer, Find, Subscribe with TTL-based heartbeat.
3. TCP for reliable RPC; UDP for events and discovery. Both over Automotive Ethernet.
4. Payloads serialize from FIDL/ARXML code generation. Never hand-packed.
5. SOME/IP dominates cockpit/body; DDS dominates ADAS/AD. Know which world you’re in.

Check Your Understanding

1. How many bytes does the SOME/IP message header occupy before the payload begins?

Recall

A. 16 bytes — Service/Method IDs, Length, Client/Session, Type, ReturnB. 12 bytes — a compact header with no version or session tracking fieldsC. 8 bytes — covering only Service ID and Method ID fields combinedD. 32 bytes — including optional authentication and encryption metadata

2. Which SOME/IP transport is appropriate for a DoorService.lock() method call?

Recall

A. UDP — low latency is the critical requirement for door lock commandsB. SOME/IP-SD multicast — broadcast the lock command to all zone nodesC. CAN-FD — door lock commands are safety-critical and need bus priorityD. TCP — reliable request/response with connection-oriented delivery path

3. Your OTA client sends a FindService for UpdateManagement but receives no Offer. The service IS running on the zone controller. What's the most likely cause?

Applied

A. SOME/IP requires DDS as the underlying discovery transport protocolB. TCP port 30501 is blocked by the zone controller's firewall rulesC. SD multicast (224.244.224.245:30490) is blocked by VLAN or switch ACLD. The FIDL serialization format is mismatched between client and server

4. A SOME/IP provider stops re-sending its Offer message and the TTL expires. What happens on the consumer side?

Applied

A. TCP connections are forcibly reset by the Ethernet managed switch chipB. Consumer marks the service unavailable until a fresh Offer is receivedC. Consumer automatically switches to gRPC as the fallback RPC transportD. Consumer falls back to decoding raw CAN signals from the gateway bus

5. How does SOME/IP differ from DDS in typical automotive deployment?

Applied

A. DDS is lighter weight and targets MCUs; SOME/IP requires a Linux host OSB. SOME/IP runs only on CAN buses while DDS runs exclusively on EthernetC. SOME/IP is service-centric for cockpit/body; DDS is topic-centric for ADASD. They are identical wire protocols marketed under two different brand names

6. Wireshark shows SOME/IP Find packets on infotainment VLAN 20 but zero Offer responses. The provider's vsomeip log confirms OFFER is being sent. What's the next architectural check?

Synthesis

Connects to: Module 10 — Wireshark Protocol Analysis

A. Increase the CAN FD data phase bitrate to 2 Mbit/s on the body busB. Replace the SOME/IP stack entirely with QMI calls through the modemC. Regenerate the protobuf stubs on the QNX-side VM and rebuild servicesD. Verify VLAN membership and switch ACLs allow SD multicast on port 30490

Further Reading

• AUTOSAR — SOME/IP Protocol Specification — Official AUTOSAR SOME/IP wire protocol specification defining the 16-byte header, message types, and serialization format covered in this page.
• AUTOSAR — SOME/IP Service Discovery Protocol (SOME/IP-SD) — Specification for Offer/Find/Subscribe discovery over UDP multicast (224.244.224.245:30490) with TTL-based heartbeat semantics.
• COVESA/vsomeip — Reference SOME/IP Implementation — Open-source SOME/IP stack with configuration examples (vsomeip.json), application lifecycle logging, and SD multicast support for lab testing.
• Franca IDL — Service Interface Definition — IDL language used to define service interfaces that CommonAPI and ara::com code generators translate into SOME/IP method/event IDs and serialization routines.
• Vector CANoe — Ethernet and SOME/IP Option — CANoe with Ethernet option supports SOME/IP dissection, SD multicast monitoring, and restbus simulation — the tool referenced for testing SOME/IP services.
• OPEN Alliance — 100BASE-T1 and 1000BASE-T1 Ethernet PHY Specifications — Physical layer standards for single-pair Automotive Ethernet that SOME/IP rides on (100M and 1G variants).
• AUTOSAR — SOME/IP Transport Protocol (SOME/IP-TP) — Specification for segmenting large payloads across multiple SOME/IP messages when data exceeds UDP MTU — relevant for OTA metadata and config transfers.
• Wireshark — SOME/IP Protocol Dissector — Wireshark’s built-in SOME/IP dissector documentation for filtering (someip || udp.port == 30490) and inspecting Service ID, Method ID, and Return Code fields in captures.