SOME/IP is an automotive middleware protocol designed to enable service-oriented communication between ECUs over in vehicle IP networks. It defines a compact binary wire format and supports key messaging patterns such as remote procedure calls, event notifications, publish subscribe mechanisms, and service discovery.
As part of the AUTOSAR ecosystem, SOME/IP is widely adopted in domains like infotainment, advanced driver assistance systems, and other areas that require flexible ECU to ECU communication. Its design ensures compatibility with a wide range of devices, from small embedded components like cameras to full featured head units and telematics platforms.
The protocol was built to support both control messages and data intensive applications, making it suitable for replacing legacy protocols such as MOST while also complementing traditional CAN based scenarios. By providing scalability across different operating systems and hardware platforms, SOME/IP has become a cornerstone for modern service oriented automotive architectures.
Table of Contents
History of SOME/IP
SOME/IP traces back to research and development efforts around 2011 and was made public in releases authored by engineers associated with BMW and the SEIS research project. Early public releases and tutorial material name Dr Lars Völker and Benjamin Krebs as authors and contributors. SOME/IP was subsequently incorporated into AUTOSAR specifications and has evolved within the AUTOSAR working groups.
As the protocol matured, it was recognized as a flexible replacement for traditional domain specific technologies such as MOST in infotainment and as a complement to CAN in control domains. Its introduction into AUTOSAR allowed suppliers and OEMs to standardize service oriented communication across hardware and software platforms, reducing integration costs and improving interoperability.
Over time, the adoption of SOME/IP has played a critical role in the shift toward service oriented architectures in vehicles, paving the way for software defined vehicles and connected mobility solutions.
Core components and messaging patterns of SOME/IP
Let us now discuss the core components and messaging patterns of SOME/IP.
Protocol building blocks
SOME/IP defines three main functional areas: the base message serialization and semantics, SOME/IP service discovery and the transport protocol for message segmentation and reassembly. The specification also defines the binary header fields that identify service id, method id, event id, length and other essential information.
This structured approach ensures that each message can be uniquely identified and properly routed, which is critical in complex automotive networks where hundreds of services may coexist. For example, a request to a diagnostic service will carry a specific method id, while a streaming service such as real time sensor data uses event ids grouped into event groups that follow a publish subscribe model.
Another example is in over the air software updates where large payloads are segmented by the SOME/IP transport protocol and reliably reassembled, ensuring that critical data such as firmware images are delivered without corruption. By combining these messaging patterns and transport features, SOME/IP provides flexibility and efficiency while maintaining the lightweight binary structure required for embedded systems.
Here is an example of the publish subscribe model in SOME/IP showing one publisher (Radar Module) and multiple subscribers (Brake, Lane Assist, Head Unit).
+-------------------+ Event Group: Radar Detected Objects
| Radar Module | ---> Event ID 0x2001, 0x2002 ...
+-------------------+
|
v
+-------------------+ +-------------------+ +-------------------+
| Brake Control | | Lane Assist ECU | | Head Unit (HMI) |
+-------------------+ +-------------------+ +-------------------+
Subscribes Subscribes SubscribesAnother example of Segmentation and Reassembly in SOME/IP. This Demonstrates how OTA updates or map data are safely transmitted using segmentation and then reconstructed at the receiver without corruption.
Large Payload (Firmware Image, 10 MB)
|
v
+------------------------------------------------------+
| Segmented into smaller SOME/IP messages (e.g. 1KB) |
+------------------------------------------------------+
[Header + Payload Chunk 1] [Header + Payload Chunk 2] ...
|
v
+---------------------------------------------------------+
| Receiving ECU reassembles payload using header fields |
+---------------------------------------------------------+Message types and patterns
SOME/IP supports multiple message types that enable developers to design flexible communication models. Request response interactions follow an RPC style that allows synchronous method calls between clients and services.
Event based notifications are organized into event groups, forming the basis of publish subscribe communication where several clients can listen to updates from a single source. These patterns give developers the choice of using method calls for procedure like interactions or events for asynchronous updates depending on the scenario.
From a technical perspective, this combination of message types improves scalability because synchronous calls are reserved for critical control operations, while asynchronous notifications handle high frequency data streams more efficiently. By unifying these communication models under one protocol, SOME/IP enables both deterministic control flows and flexible data distribution across distributed automotive systems.
Request–Response (RPC Style) -> Shows a direct synchronous call where the client requests an action and waits for a response. Example: Climate control setting cabin temperature.
+---------+ Request: Set Temperature(22°C) +-------------+
| Client | -------------------------------------> | Service |
+---------+ +-------------+
^ |
| Response: OK / Current Temp = 22°C v
+-----------------------------------------------------------------+Publish–Subscribe (Event Based) -> Shows one publisher (Sensor ECU) broadcasting events to multiple subscribers (Climate ECU, Head Unit, Logging ECU). Example: Ambient temperature updates or lane detection data.
+-------------+
| Sensor ECU | Event: AmbientTemp = 24°C
+-------------+
|
--------------------------------------------
| | |
+---------------+ +---------------+ +---------------+
| Climate ECU | | Head Unit ECU | | Logging ECU |
+---------------+ +---------------+ +---------------+Header and payload in SOME/IP
A SOME/IP message consists of a fixed header and a payload. The header contains fields such as message id, length, request id, protocol version, interface version, message type, and return code. The payload is a serialized representation of parameters or event data, with its format defined in the AUTOSAR specification.
The base header is twelve bytes long and provides enough information for receivers to identify and correctly deliver the message before examining the payload. The message id is built from a service id and a method or event id, which tells the receiving ECU whether the packet is a procedure call or an event notification.
The length field is crucial for segmentation and reassembly because it specifies the total size of the message, making it possible to detect incomplete transfers. By separating header metadata from the payload, SOME/IP ensures accurate routing and efficient binary serialization, which are essential for real time automotive communication.
SOME/IP Base Header (12 Bytes):
Byte 0 1 2 3 4 5 6 7 8 9 10 11
+----------------------+----------------------+----------------+---------+---------+
| Message ID | Length | Request ID | ProtVer | faceVer |
|(ServiceID + MethodID)| (Total message size) | Client+Session | | |
+----------------------+----------------------+----------------+---------+---------+Message ID (4 bytes, offset 0–3): Composed of Service ID (16 bits) + Method/Event ID (16 bits).
Example: 0x1111 0020 → Service 0x1111 (Camera), Method 0x0020 (GetFrame).
Length (4 bytes, offset 4–7): Total size of the message in bytes (header + payload).
Example: 0x00000030 → Message size is 48 bytes.
Request ID (2 bytes, offset 8–9): Identifies the client and session, ensuring responses match the right request.
Example: 0x0005 → Client 0, Session 5.
Protocol Version (1 byte, offset 10): Defines SOME/IP protocol version. AUTOSAR specifies 0x01.
Interface Version (1 byte, offset 11): Defines version of the service API. Example: 0x02 → Version 2 of the service interface.
Example Encoded Header: If the fields are:
- Service ID =
0x1111 - Method ID =
0x0020 - Length =
0x00000030(48 bytes) - Request ID =
0x0005 - Protocol Version =
0x01 - Interface Version =
0x01
The 12-byte header in hex looks like:
11 11 00 20 00 00 00 30 00 05 01 01
Transport Mapping and Segmentation in SOME/IP
SOME/IP is transport agnostic at the application layer but is most commonly carried over UDP or TCP. For payloads larger than a single UDP datagram, the SOME/IP transport protocol provides segmentation and reassembly. TCP offers reliable streams with built in error handling, while UDP with segmentation is preferred for lower overhead or multicast scenarios such as service discovery.
Large over the air software updates are typically carried over TCP since guaranteed delivery is essential, whereas real time sensor data such as radar detections may use UDP with segmentation to minimize latency. Segmentation adds control information to each fragment so the receiver can reassemble the original message even if packets arrive out of order.
Multicast with UDP enables multiple ECUs to receive the same message without duplicating traffic, which is critical in bandwidth constrained environments. By providing this dual transport capability, SOME/IP supports both high reliability diagnostics and time critical perception systems within the same unified communication framework.
OTA Update over TCP (Reliable Stream): Use cases are Over the air firmware updates.
- TCP ensures ordered delivery, retransmissions, and reliability.
- Critical when transferring multi-MB binary images.
+------------+ +-----------------+ +-------------+
| Server | ----------> | Vehicle ECU | <---------- | Server |
+------------+ TCP ACK +-----------------+ TCP ACK +-------------+
| | |
|<-- Guaranteed Delivery -->|<------ Error Handling -----> |Real Time Sensor Data over UDP with Multicast. Use case: Radar or camera streams.
- UDP multicast allows one sender to reach many receivers.
- Lower overhead, minimal latency.
- SOME/IP segmentation reassembles large frames safely.
+-------------------+
| Radar Sensor ECU |
+-------------------+
|
------------------------------------------
| | |
+---------------+ +---------------+ +---------------+
| ADAS ECU | | Logging ECU | | HMI ECU |
+---------------+ +---------------+ +---------------+Segmentation and Reassembly: Ensures data integrity even when payloads exceed the Ethernet MTU.
Large Payload (e.g. 4 MB map update)
|
v
[Seg1][Seg2][Seg3]…[SegN] --> transmitted via UDP or TCP
|
v
ECU Reassembles Segments --> Complete Payload RestoredService discovery and addressing
Service discovery is a core component of the SOME/IP ecosystem and is responsible for enabling dynamic communication between services and clients. SOME/IP SD manages announcements, offers, requests, and subscriptions, typically using multicast to broadcast availability across the network.
It supports versioning, service instances, and life cycle management so that clients can detect and bind to the correct service at runtime. This approach eliminates the need for hard coded IP addresses or ports and allows multiple instances of a service to coexist while maintaining compatibility across software versions.
As a result, service discovery makes deployments more flexible, scalable, and resilient in complex automotive networks.
Serialization and interface description
SOME/IP uses a compact binary serialization tailored for resource constrained ECUs. Interface definitions are commonly expressed in interface description languages such as Franca which then map to SOME/IP identifiers and parameter formats. Tooling exists to convert from higher level interface definitions into SOME/IP compatible serializers and stub code.
Limitations and when to consider alternatives
SOME/IP is optimized for automotive constraints and service-oriented scenarios but it is not a one size fits all solution. For strict real time hard real time control loops classical field bus technologies or TSN aware stacks with deterministic guarantees may be needed.
Similarly, if an architecture requires rich application layer semantics provided by modern general purpose RPC frameworks careful trade-offs must be considered. The industry trend is hybrid architectures where SOME/IP coexists with other specialized protocols.