SOME/IP Deep Dive

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 0xFFFF multicast in a Wireshark capture, you’ve already met SOME/IP.

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).

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

“Service discovery works in the lab but not in the vehicle” usually means VLANs or multicast routing. 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.”

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 4 (Networking) covers Automotive Ethernet physical layer and VLANs that SOME/IP depends on.

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. 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?

A. TCP port 30501 is blockedB. SOME/IP-SD multicast (224.244.224.245:30490) is blocked by VLAN/switch ACLC. The FIDL serialization format is wrongD. SOME/IP requires DDS for discovery

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

A. UDP — low latency is critical for door locksB. TCP — reliable request/response with connection-oriented deliveryC. SOME/IP-SD multicast — broadcast the lock commandD. CAN-FD — door locks are safety-critical

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

A. SOME/IP runs on CAN; DDS runs on EthernetB. SOME/IP is service-centric with AUTOSAR-native discovery, targeting cockpit/body; DDS is topic-centric with rich QoS, targeting ADAS/ADC. DDS is lighter weight and used on MCUs; SOME/IP requires LinuxD. They are identical protocols with different names