Challenges and Opportunities
SOME/IP: The Next 15 Years
15 years ago, the foundations for Scalable service-Oriented MiddlewarE over IP (SOME/IP) were established — few could have predicted the pivotal role it would play in automotive communication. Today, numerous manufacturers and brands rely on SOME/IP to transmit control data over Automotive Ethernet.
When Automotive Ethernet was introduced, it quickly became clear that the industry did not want to continue following the classic communication paradigms such as used by CAN. Vehicle manufacturers and suppliers were actively searching for a modern communication solution that could replace both CAN and MOST communication (see also the BMBF project SEIS). Communication should no longer be signal-oriented but service-oriented to better manage increasing complexity. Efficient and scalable use of Automotive Ethernet required publish/subscribe capabilities, as well as the ability to move services within the vehicle network. This flexibility required service discovery. As with any automotive technology, fast startup capability was essential. Additionally, for support of partial networking and robustness, the solution had to be fully distributed and operate without central roles.
Given such a demanding set of requirements, it quickly became apparent that existing communication solutions—such as MQTT, DDS, Google Protocol Buffers, REST, CORBA, Apache Etch, and Bonjour—only partially met the needs. Considering the most important software platform at that time (AUTOSAR) and its licensing conditions, it was evident that only a new solution could adequately address the problem.
SOME/IP was developed as the solution for modern control communication in vehicles, and the first version of SOME/IP was publicly introduced and discussed in 2011. Further refinements followed in 2012, and SOME/IP was incorporated into ISO, GENIVI/COVESA, and AUTOSAR, leading to published standards in 2013 and 2014. Until 2016, additional functions were added and integrated into standardization. The last major feature was SOME/IP-TP, a minimal transport protocol for large messages over UDP.
Since 2016, the SOME/IP feature set has remained essentially stable and is increasingly used by vehicle manufacturers. In particular, the SOME/IP standards published in AUTOSAR have contributed significantly to its widespread adoption.
What is SOME/IP?
SOME/IP is a communication solution specifically tailored for vehicles using Automotive Ethernet. Figure 1 illustrates SOME/IP in the context of in-vehicle communication: as a middleware, SOME/IP spans the Automotive Ethernet communication within the vehicle and builds on top of standard TCP/IP protocols. This approach provides applications with Service Interfaces that effectively abstract the underlying communication, significantly reducing the effort required by application developers.
Key Features of SOME/IP:
- A service-oriented approach that combines request-based patterns (such as Remote Procedure Calls) with data-driven patterns (such as events and publish/subscribe).
- Robust support for scalable unicast communication (via publish/subscribe) and efficient multicast transmission.
- Real-time communication with minimal latency using UDP, which is essential for critical vehicle control functions (e.g., braking).
- Reliable communication using TCP for patterns that prioritize data integrity over latency.
- Serialization optimized for high speed and extremely low resource consumption.
- Dynamic and rapid discovery of communication partners (service discovery via SOME/IP-SD).
- Support for very large messages over the UDP transport protocol (SOME/IP-TP).
The extensive feature set of SOME/IP makes it easy to handle all control communication in modern vehicles, which is a key reason for its success.
Current Trends and Impacts
SOME/IP aligns well with the development model of recent years, which feature clearly defined responsibilities between vehicle manufacturers and suppliers. Manufacturers primarily handle the specification side by providing requirements and configurations, while suppliers implement the software based on standards such as AUTOSAR.
Currently, three major trends are challenging the established development model—and, by extension, the current SOME/IP ecosystem:
- Use of Software in the vehicle has become a dominant factor, and software development is now at the forefront. This shift results in software-defined vehicles that require faster development cycles, calling into question existing methods (such as those used in AUTOSAR).
- Open-source initiatives are gaining momentum, with strong backing from most automakers. The goal is twofold: to gain greater control over vehicle software and accelerate development, while also reducing costs through open-source adoption.
- Automotive Ethernet is no longer limited to passenger cars; it is increasingly used in commercial vehicles—a domain where AUTOSAR has traditionally seen less adoption and OEMs have developed more themselves. Heavy reliance on AUTOSAR in this context is not advantageous.
The push for faster development cycles primarily demands optimization of development processes. For example, when examining the process chain for defining and configuring a SOME/IP service, improvements or alternatives to the current approach are essential.
The AUTOSAR configuration format, ARXML, is now considered the de facto standard and must be provided by the manufacturer. However, ARXML comes with challenges: manufacturers struggle to produce these extensive files quickly and with sufficient quality, while suppliers cannot easily automate software updates based on these changes. These structural issues primarily affect AUTOSAR and ARXML, but since SOME/IP is often configured using ARXML, SOME/IP implementations are impacted as well.
Open-source adoption, on the other hand, represents a countertrend to AUTOSAR because AUTOSAR licenses are incompatible with open-source principles. Although solutions have been sought for years, none are in sight. This poses a problem for SOME/IP, as the latest specifications are primarily published through AUTOSAR. ISO has yet to release a complete SOME/IP specification, and while COVESA has published an open source SOME/IP stack (vsomeip), it has not provided a formal specification.
For the use of SOME/IP in commercial vehicles, the availability of robust standards is a critical issue. While communication in passenger cars is confined to the vehicle itself, commercial vehicles often involve communication with trailers or implements. A reliable standard is therefore essential. These standards are typically issued by ISO, but the absence of a complete, up to date SOME/IP specification from ISO or a compatible standards organization remains the biggest obstacle.
Figure 2 summarizes the current trends and their impact on SOME/IP.
Outlook
What needs to happen to ensure the continued success of SOME/IP?
To better support open-source initiatives and enable use in commercial vehicles, it is essential to have an open SOME/IP specification that can be freely used. For commercial vehicles, such an open SOME/IP specification could be published as an ISO standard.
It is also critical to maintain compatibility among different SOME/IP implementations, even if they are based on varying specifications.
For integration into open-source projects, the specification should support modern formats and processes. A current trend is treating requirements and specifications according to the “as-code” principle. By leveraging source code tools like Git and automated CI/CD processes, requirements, source code, and test cases can be linked seamlessly. This approach enables parallel development of requirements, source code, and test cases while rapidly detecting downstream impacts—a significant advantage for accelerating the often highly formal automotive development process. An example of this approach is Sphinx-Needs, a solution designed for model-based documentation and linking technical artifacts.
A team is currently working on an open SOME/IP specification in the Sphinx-Needs format to achieve these goals and benefits. This specification will be released soon to empower open-source projects such as Eclipse S-CORE and Eclipse OpenBSW, and to serve as a foundation for ISO standardization.
The first release of the open SOME/IP specification is planned for late 2025 and will be announced at https://some-ip.com. This release will include the core SOME/IP features that have been established until 2016, along with improvements and refinements.
Due to licensing restrictions, not all AUTOSAR features can simply be adopted. As a result, some “AUTOSAR extensions” will not be part of the initial open SOME/IP specification. For these to be included, they must be submitted by their original authors and rights holders first. The most notable such extension is TLV serialization, which is currently used by only one major vehicle manufacturer. Other extensions have even less impact and are therefore not critical for the broader community.
Next Steps
Work is already underway on a security specification for SOME/IP, scheduled for release in 2026. This will comprehensively document various integrations of security solutions with SOME/IP for the first time. Additional security features, such as a SOME/IP-based key exchange, will also be included.
Another important initiative is the development of a free and open configuration language for SOME/IP and related features. This effort also follows the “as-code” approach, allowing configurations to be treated like source code. The first release of this solution—called FLYNC—is planned for early 2026, providing developers of open SOME/IP solutions with a modern, open configuration language.
Further protocols and features are already under discussion.
Acknowledgments
The author thanks the involved vehicle manufacturers, stack providers, and colleagues from useblocks for their support in using Sphinx-Needs. Special thanks to the Technica Engineering/KPIT team for their leadership in advancing and coordinating the development of the open SOME/IP specification.
