The Scalable Service-Oriented Middleware over IP — commonly known as SOME/IP — is a powerful communication framework that enables seamless interaction between distributed systems over automotive IP networks. Running on top of UDP or TCP, Scalable Service-Oriented Middleware over IP provides a standardized way for services to discover, connect, and exchange data with each other.
At its core, Scalable Service-Oriented Middleware over IP is built upon the principles of service-oriented architecture (SOA) as against the typically signal-oriented messaging generally followed by CAN, LIN, and FlexRay technologies. It was originally published in 2011 as part of the BMBF-funded SEIS project and later made part of the AUTOSAR specifications.
In this article, we will explore the details of SOME/IP, how Scalable Service-Oriented Middleware over IP is mapped to the OSI layer model, its message structure, service types, and the service discovery protocol that enables dynamic service registration.
To grasp the inner workings of Scalable Service-Oriented Middleware over IP, it is essential to understand the OSI (Open Systems Interconnection) model and how it maps to SOME/IP.
The OSI model is a conceptual framework that defines the functions and interactions of different layers in a network architecture. In the case of SOME/IP, Scalable Service-Oriented Middleware over IP primarily operates at the application layer (Layer 7) of the OSI model.
SOME/IP builds upon the transport layer protocols — TCP and UDP — to establish reliable and efficient communication between services. By leveraging these lower layers, Scalable Service-Oriented Middleware over IP ensures that data is transmitted securely and efficiently across the network.
Scalable Service-Oriented Middleware over IP offers a range of key features and benefits that make it an attractive choice for building distributed automotive systems:
SOME/IP messages follow a predefined structure specified by the Scalable Service-Oriented Middleware over IP standard. Each SOME/IP message consists of a header and a payload. The header contains essential information — the message ID, service ID, and method ID — which helps in routing and processing the message correctly. The payload carries the actual data to be exchanged between services.
The first 4 bytes of the header constitute the message ID. This message ID must be unique across the vehicle network. If the 15th bit is 0, the Message ID represents a Remote Procedural Call (RPC) with the upper 16 bits as the Service ID and the lower 15 bits as the method ID. If this bit is 1, the Message ID represents an Event with the lower 15 bits as the Event ID.
The next 32 bits indicate the length of the message including the header minus 8. The following part is the Request ID — a concatenation of Client ID and session ID. One byte holds the protocol version, followed by a 1-byte interface version. The next 8 bits hold the message type: Request, Request with no response, Notification, Response, or Error response.
As the name Scalable Service-Oriented Middleware over IP implies, the building blocks of SOME/IP are its services. A service consists of one, multiple, or none of Fields, Methods, and Events.
Fields are the data components that hold a value such as Engine Temperature. They can offer one or more of: Setter (subscriber can change the value), Getter (subscriber can read the value), and Notifier (subscriber is sent the data on change of value).
Methods are functions or remote procedural calls that can be invoked on the provider by the subscriber. Events are data that are either sent cyclically or on change from publisher to subscriber. In object-oriented terms, Fields are members of an object, Methods are methods, and Events are callbacks.
Each service is uniquely identified by a service ID and IP address and can be consumed by one or more clients simultaneously.
The Request/Response method is a fundamental communication pattern in Scalable Service-Oriented Middleware over IP. It enables a client to send a request to a server and receive a corresponding response, widely used in scenarios where a client requires specific data from a server.
When using the Request/Response method, the client sends a message with a specific method ID and payload to the server. The server processes the request and sends back a response. The Request/Response method ensures synchronous communication between services and allows for reliable data exchange.
The Fire-and-Forget method is another communication pattern supported by Scalable Service-Oriented Middleware over IP. Unlike Request/Response, it does not expect any response from the server. It is commonly used when a client needs to send a command or trigger an action without requiring confirmation.
The Fire-and-Forget method reduces the overhead of waiting for a response, resulting in improved performance and efficiency for non-critical operations.
The Services-Event mechanism in SOME/IP enables real-time communication between services. It allows services to subscribe to specific events and receive notifications whenever those events occur. SOME/IP allows events to be transmitted on change or cyclically or both as per the sender configuration.
In the Services-Event model, publishers generate events and notify subscribers, while subscribers express their interest in specific events and receive corresponding notifications. For example, a service might subscribe to the Engine Temperature event and receive notifications whenever the temperature exceeds a threshold, enabling real-time monitoring and immediate action.
Like the Event mechanism, the Field services feature in Scalable Service-Oriented Middleware over IP provides asynchronous notifications. The difference is that it is associated with a Field, enabling getter and setter operations. When the value changes, subscribers are notified of the update.
For example, a service might have fields like Engine Speed, Fuel Level, and Odometer Reading. These fields can be updated and accessed independently, and subscribers are alerted on change with the updated value.
Sometimes it makes sense to group a set of events logically so that subscribers can subscribe to the entire event group with a single subscription rather than requesting each constituent event individually. For example, all events from a Fuel Computer module — low fuel, tank fill, fuel drain — can be grouped under FuelEvents. Scalable Service-Oriented Middleware over IP supports such event groups to optimize communication.
The SOME/IP service discovery protocol (SOME/IP-SD) is the mechanism by which clients and servers locate each other dynamically at runtime. The service discovery protocol uses a dedicated message format transmitted over UDP multicast and supports the following operations: Offer (server broadcasts available services), Find (client requests a specific service), Stop Offer (server announces service unavailability), Subscribe (client subscribes to an event group), SubscribeAck, SubscribeNack, and StopSubscribe. The service discovery protocol eliminates static IP configuration and supports plug-and-play addition of new services to the Scalable Service-Oriented Middleware over IP network. For teams building web-based service consumers or dashboards that integrate with SOME/IP, Embien's web application development services provide IP-layer service integration. For embedded-side service discovery protocol implementation within automotive ECUs, Embien's product engineering services offer SOME/IP stack integration across AUTOSAR and Linux platforms.
The service discovery protocol in SOME/IP is distinct from the data-plane messages: it uses a reserved Message ID of 0xFFFF8100 and its payload carries entry arrays describing offered or sought services along with options arrays containing endpoint information such as IPv4 address and UDP/TCP port. This clean separation between the service discovery protocol plane and the data plane is one of the architectural strengths of Scalable Service-Oriented Middleware over IP.
The SOME/IP protocol is now a foundational layer in modern automotive networking architectures, particularly in Ethernet-based domain and zonal controllers. In an automotive networking context, the SOME/IP protocol sits above the TCP/IP stack and integrates with the AUTOSAR Adaptive Platform, enabling service-oriented communication between high-compute ECUs such as ADAS processors, infotainment systems, and vehicle gateway modules. Understanding the SOME/IP protocol is essential for architects designing software-defined vehicle platforms where automotive networking must support dynamic service deployment and over-the-air configuration updates.
When designing automotive networking architectures, Scalable Service-Oriented Middleware over IP offers clear advantages over signal-based protocols for high-bandwidth, low-latency domains. Scalable Service-Oriented Middleware over IP enables automotive networking to transition from static bus schedules to dynamic service meshes, supporting the needs of connected vehicle applications such as remote diagnostics, digital cockpit integration, and V2X data aggregation.
Thus, Scalable Service-Oriented Middleware over IP provides all the necessary mechanisms needed to achieve a service-oriented architecture in automotive systems. With its SOME/IP services, service discovery protocol, message types, and event group subscriptions, this article provides a base for understanding SOME/IP further. We will venture into data serialization, transport protocol, and the SOME/IP service discovery protocol in detail in the upcoming article on SOME/IP protocol communication.
Embien's integrated product engineering services include Scalable Service-Oriented Middleware over IP (SOME/IP) stack development, service discovery protocol integration, and AUTOSAR Adaptive deployment.
Embien's embedded software development services cover SOME/IP stack implementation, service discovery protocol configuration, and automotive networking integration for Ethernet-based ECU platforms.
An IoT-based energy meter reading solution demonstrating Embien's expertise in service-oriented protocol stacks applicable to Scalable Service-Oriented Middleware over IP deployments.