As described in our introductory article on SOME/IP, the SOME/IP protocol — Scalable Service-Oriented Middleware over IP — is a powerful communication framework that enables seamless interaction between distributed systems over IP networks. It provides a standardized way for services to discover, connect, and exchange data with each other, making the SOME/IP protocol a crucial component in modern automotive software development.
At its core, the SOME/IP protocol is built upon the principles of service-oriented architecture (SOA) and leverages IP-based networking to facilitate communication between various components. By utilizing the SOME/IP protocol, developers can create robust and scalable applications that seamlessly integrate with other systems. Let us understand how the SOME/IP protocol recommends serializing data, performing transmission of larger packets, and the SOME/IP SD service discovery mechanisms in the coming sections.
Efficient data transfer is a crucial aspect of any communication protocol, and the SOME/IP protocol addresses this through its data serialization mechanism. Data serialization refers to the process of converting complex data structures into a format suitable for transmission over a network.
The SOME/IP protocol supports direct serialization formats similar to C language data handling. By serializing data, the SOME/IP protocol optimizes network bandwidth and reduces the size of transmitted data, resulting in improved performance and efficiency.
The data can be a single value (scalar), a complex grouping of information (data structure), or a remote procedural call (RPC). The SOME/IP protocol defines the following basic data types for scalar values:
The SOME/IP protocol also supports the following complex data types, which must be explicitly padded if elements do not align to their natural boundary:
The default data size is 32-bits (configurable), and all size and type fields are encoded in big-endian format.
The size of the SOME/IP protocol payload depends on the transport protocol used. With UDP the payload can go up to about 1400 bytes — the natural boundary of the Ethernet frame. With TCP, there is no theoretical limit since it supports segmentation by itself. When a sender wants to transmit a packet of over 1400 bytes on UDP, it can rely on the Transport Protocol mechanism defined by the SOME/IP protocol specification.
The 6th bit (the TP flag) in the Message Type field of the SOME/IP protocol header indicates if it is a segmented packet. If the Message Type field has a value of 0x20 OR-ed, it is a segmented packet and the receiver should accumulate subsequent packets to reassemble. The sender splits a larger payload into smaller ones and sets this TP flag for all segmented packets except the last one.
With this mechanism the SOME/IP protocol can accommodate larger data over UDP without the overhead of a full TCP/IP transport session.
With a server supporting a variable number of services, it is essential to have a mechanism to identify the available services. The SOME/IP SD (SOME/IP Service Discovery) protocol is the mechanism that addresses this. SOME/IP SD is used to locate service instances, know their current states, and perform publish/subscribe operations within the SOME/IP protocol ecosystem.
The SOME/IP SD header uses the same format as the SOME/IP protocol but with a reserved Message ID of 0xFFFF8100 to indicate it is specific to the SOME/IP SD protocol. The payload can have entries with optional Options arrays that describe the services offered or being subscribed.
In the example below, the SOME/IP SD Offer specifies that it supports a service ID (0x1234) at instance (0x5678). With the options array, it specifies that this particular service is available over IPv4 address 192.168.29.93 at UDP port 30509.
The SOME/IP SD mechanism supports the following operations:
Offer: The server actively sends Offer messages over multicast with the list of available services so clients can connect and consume them.The SOME/IP SD service discovery protocol separates the control plane (service advertisement and subscription management) from the data plane (actual method calls and events). This service discovery protocol architecture allows services to be added, removed, or restarted without reconfiguring clients, which is essential for over-the-air update scenarios in software-defined vehicles. The service discovery protocol in SOME/IP SD uses UDP multicast for broadcast announcements and unicast for targeted responses, minimizing bus load while ensuring all clients receive service state changes.
The SOME/IP protocol plays a central role in Connected Vehicles Development. As vehicles become software-defined platforms with real-time connectivity requirements, Connected Vehicles Development teams rely on the SOME/IP protocol to expose vehicle services — from sensor data streams to remote control interfaces — over the automotive Ethernet backbone. Connected Vehicles Development architectures using the SOME/IP protocol typically deploy SOME/IP SD on the internal vehicle Ethernet domain and bridge selected services to cloud backends via a vehicle gateway running TCP/IP. Embien's digital transformation services support Connected Vehicles Development teams in integrating the SOME/IP protocol into production ECU software, including SOME/IP SD configuration and V2C (vehicle-to-cloud) service bridging. Embien's RAPIDSEA product family includes the SOME/IP protocol stack for rapid deployment on both AUTOSAR and Linux-based ECU platforms, accelerating Connected Vehicles Development programs.
Connected Vehicles Development workflows that use the SOME/IP protocol benefit from its ability to carry high-frequency sensor data (camera feeds, radar point clouds) alongside low-frequency status parameters (door state, HVAC settings) within the same IP network. This flexibility makes the SOME/IP protocol the preferred middleware for Connected Vehicles Development projects that need a unified communication layer across all vehicle domains.
In modern automotive networking architectures, the SOME/IP protocol sits above the TCP/IP layer and integrates with the AUTOSAR Adaptive Platform for zonal and domain controller designs. Automotive networking engineers deploying the SOME/IP protocol must configure SOME/IP SD timing parameters (initial delay, repetition max, cyclic offer interval) to balance service advertisement latency against bus load in the automotive networking fabric. With Ethernet becoming the backbone of automotive networking, the SOME/IP protocol provides the application-layer contracts that tie together ADAS, infotainment, and powertrain service domains.
Whether implementing a server or client, building a SOME/IP protocol application requires careful consideration of various factors. Key steps include:
By following these steps, you can successfully implement the SOME/IP protocol in your application, enabling seamless communication and interoperability with other systems.
The SOME/IP protocol services supported by the server can be specified using the ARXML and FIBEX formats so that any third-party tools or clients can consume them.
In conclusion, the SOME/IP protocol is a comprehensive and powerful middleware framework that enables seamless communication between distributed systems over IP networks. By understanding its data serialization, SOME/IP SD service discovery protocol, transport layer mechanisms, and Connected Vehicles Development applications, developers can harness the full power of the SOME/IP protocol to build scalable, flexible, and efficient automotive applications. With Automotive Ethernet becoming a norm, the SOME/IP protocol is the definitive middleware choice for Connected Vehicles Development programs that require dynamic, service-oriented automotive networking.
Embien's cross-domain embedded services include SOME/IP protocol stack development, SOME/IP SD configuration, and Connected Vehicles Development integration for automotive Ethernet ECUs.
Embien's embedded system security services protect SOME/IP protocol deployments against unauthorized service discovery and secure Connected Vehicles Development architectures.
A uCLinux-based Microsemi SmartFusion2 SoC FPGA design demonstrating Embien's embedded networking expertise applicable to SOME/IP protocol and Connected Vehicles Development.