What is SOME/IP Protocol

Today’s automobiles are not just a means of commuting and transportation; the vehicles are now designed feature-packed to make the journey a luxury experience. All of this comes by integrating sophisticated electronics with the vehicle’s ECU (Engine Control Unit). This new scenario has significantly changed how data communicate among different units of ECU. Traditional automotive protocols like CAN, MOST, LIN, and Flexray are signal-based communication protocols, and these protocols have some notable limitations, as mentioned below.

Traditional Protocols like CAN, LIN, MOST, and Flexray have limited bandwidth.
These protocols are only suitable for static systems that do not have any software upgrade or update in their lifetime.
In these protocols, data is communicated between the sender and the receiver whenever there is an event (like the reception of an interrupt). The receiver may not need the data in response to every event. Therefore, these protocols always have a data overhead in the communication channel, which cannot be avoided or managed in any way.
Traditional Protocols like CAN, LIN, MOST, and Flexray, being signal-based communication protocols, do not ensure interoperability among different operating systems, embedded firmware, data interfaces, and application software.

In the context of the limitations mentioned above of traditional automotive communication protocols, in 2011, BMW group introduced a middleware protocol for data communication among various heterogeneous units of any ECU, the Scalable service-Oriented MiddlewarE over IP (SOME/IP). As the name itself indicates, this protocol is:

Scalable: This protocol is designed for scalability and interoperability among heterogeneous devices with different hardware platforms, different operating systems or embedded firmware, and different application software.

service-Oriented: It is a service-oriented protocol. Therefore, the data is exchanged in a client-server configuration only when requested by a client or notified by the server to the particular subscribers. This ensures that the bandwidth is never wasted and data is communicated/exchanged only when and where required.

MiddlewarE: This is a middleware protocol, i.e., it lies in the application layer and has its own general-purpose protocol layers to deal with more specific operations and applications.

over IP: This is an Ethernet-based protocol. It uses a similar hardware interface, ensuring a bandwidth of up to 100Mbps. The data is communicated over the middleware, i.e., the application layer, over the network cable using TCP/IP or UDP protocols. When the client requires the data from the server, it is requested by the client using the TCP protocol. If the server must communicate the data to all the active subscribers, it is transmitted over UDP protocol. The data communication over UDP protocol can be unicast, multicast, or broadcast.

SOME/IP was initially developed as another RPC mechanism to ensure compatibility with AUTOSAR devices and provide the maximum features required by automotive use-cases. It is a network layer protocol designed specifically for inter-ECU client-server serialization. At present, the protocol can be implemented over several different operating systems, including AUTOSAR, OSEK, and GENIVI. It can also be implemented on embedded firmware running no operating system. Devices such as cameras, head units, telematics devices, AUTOSAR devices, and even large devices like infotainment systems, can efficiently exchange inter-ECU messages using SOME/IP protocol. SOME/IP support has been public since the release of Wireshark 3.2 SOME/IP that can be accessed at Wireshark.

Features of SOME/IP protocol
SOME/IP is a network layer protocol that works as a middleware, i.e., logically implemented in the application layer. As a middleware, SOME/IP can provide many different applications/features as different general-purpose protocol layers. Some of the key features/applications of SOME/IP are following.

Serialization: The protocol takes care of transforming inter-ECU messages into and from on-wire representations. At the wire-format level, the protocol is compatible with the AUTOSAR 4.x standard.

Remote Procedure Calls (RPC) and Messaging: The protocol can communicate messages (sent as fields) as well as the remote invocation of methods (implement procedure/function calls).

Service Discovery: The data communication using SOME/IP protocol happens in a client-server arrangement. SOME/IP is based on a service-oriented architecture. The server provides many different services to which client devices can subscribe. The protocol allows clients to dynamically find services, subscribe to them, and configure their access to the services.

Publish/Subscribe: The data communication in SOME/IP takes place through publish/subscribe. The clients can subscribe to services provided by the server, and the server can publish notifications to the active subscribers. This allows dynamic configuration between the client devices and the server. With publish/subscribe arrangement, the server can selectively communicate data to the clients requiring specific inter-ECU messages.

Segmentation of UDP messages: Whenever notifications have to be sent to active subscribers by the server, they are sent over UDP protocol. SOME/IP is capable of communicating large UDP messages without the need for any fragmentation.

How SOME/IP protocol works
All data communication in SOME/IP protocol is performed in the form of services. The server ECU provides the services. The client devices can dynamically find services offered by the server (Service Discovery), subscribe to the services, and perform configuration to access subscribed services.

The services are a combination of fields, events, and/or methods. A field represents the status of an entity and can be a notifier, getter, or setter. A Notifier is a field sent from server to client on change of a value. A Getter is a field sent by the client to the server for explicitly querying a value. A Setter is a field sent by the client to the server to change/modify a value explicitly. Event is a message communicated from the server to the client when a value is changed or cyclically communicated to clients. Method is a (programming) function/procedure/subroutine that can be invoked. A method is run on the server on remote invocation from the client.

A service provides an interface, and a single instance of a service implementing a service interface is called Service Instance. The service instance is provided by the server ECU that implements a service interface. The client ECU can use a service instance to get the required data (fields, events, and methods) from the server ECU.

The client devices know about the available services, i.e., available service instances using a service discovery protocol. The service discovery protocol has two mechanisms to convey the availability of services – ‘Offer Service’ and ‘Find Service’. When the server ECU communicates the available services to the network (all the client ECUs), the mechanism is called ‘Offer Service’. When the clients request available services from the server ECU, the mechanism is called ‘Find Service’. Therefore, the discovery of available services within the network can be initiated from both server ECU as well as client ECUs.

Once services required by a client are discovered using either mechanism, it can subscribe to those service instances. For subscription, the client needs to send a Subscribe Eventgroup to the server. The server checks the validation of the subscription request and, if found correct, sends back a positive acknowledgment. It is possible that multiple clients may subscribe to a given service instance.

The data communicated between server and client can be a scalar value, a complex data structure, or a function invocation (RPC). The following scalar data types are supported in SOME/IP –

boolean: This has an 8-bit field containing False (0) or True (1). No other values are allowed in boolean type.

uint8: 8-bit unsigned integer

uint16: 16-bit unsigned integer

uint32: 32-bit unsigned integer

uint64: 64-bit unsigned integer

sint8: 8-bit signed integer

sint16: 16-bit signed integer

sint32: 32-bit signed integer

sint64: 64-bit signed integer

float32: 32-bit floating-point number

float64: 64-bit floating-point number

Following complex data types are supported in SOME/IP –

struct: It is a predefined list of parameters. A struct starts with an optional length field indicating all the bytes following the length field.

string: Character strings containing ASCII, UTF-8, or UTF-16 characters. The strings can have fixed length or dynamic length. The dynamic length strings begin with an endian field indicating the length of the string.

array: A set of parameters of the same data type. Arrays can be one-dimensional as well as multi-dimensional. The length of the array can be fixed or dynamic. The dynamic length array begins with a length field.

enumeration: It is an unsigned integer indicating different values by its bits.

bitfield: It is an 8-, 16- or 32-bit parameter in which each bit is a boolean value.

union/variant: It is a parameter that contains other parameters of different data types.

The data is communicated between server ECU and client ECU over UDP or TCP protocols. UDP protocol is used when data needs to be sent by the server to all the active subscribers (like in the case of notifier fields and events). The data transfer using UDP can be via unicast, multicast, or broadcast. When data needs to be sent by the client to the server (like in the case of getter fields, setter fields, and RPC), the client needs to establish a connection with the server using TCP protocol.

In SOME/IP, there are four methods for remote procedure calls (RPC) as follows:

Request/Response method: In this method, a request for calling a function is sent by the client to the server, and the server sends back a response to the client. The response can be a positive acknowledgment or an error message. The function is run on the server ECU at request from a client ECU.

Fire and Forget method: In this method, the client sends a request for calling a function to the server, and the server does not communicate any response to the client.

Services-Event: Event is a message communicated from the server to the client when a value is changed or cyclically communicated to clients. The server notifies the change in a value only to the clients who have subscribed for that service. The notification is sent every time the event occurs, i.e., the value related to the subscribed service is changed.

Services-Field: A field is a property/attribute of service. It can be a notifier, getter, or setter. Getter is a method to read a field value, and Setter is a method to change a field value. Notifier is a notification event triggered by a change of a field value.

The data (fields, events, and methods) are transferred in protocol data units (PDUs) as TCP/UDP messages payloads. The TCP/UDP messages are transported over an IP-based in-vehicle network enabling inter-ECU data communication. A header precedes the payload. For ensuring inter-operability, the header layout is identical for all implementations of SOME/IP. The header consists of a 32-bit Message ID, 32-bit Length Field, 32-bit Request ID/Session ID, 8-bit Protocol Version/8-bit Interface Version/8-bit Message Type/8-bit Return Code. Hence, a TCP/UDP data packet communicated over SOME/IP protocol has the following PDUs.

TCP or UDP data packet in SOME/IP protocol

SOME/IP Protocol Data Units

Advantages of SOME/IP Protocol
SOME/IP protocol has many advantages compared to traditional automotive protocols like CAN, LIN, and MOST. Some of the worth-noting advantages of SOME/IP are the following:

Being a service-oriented protocol, it is interoperable and scalable. New parameters and functions can be easily added to a vehicle system using SOME/IP. Only the header layout must be identical in all implementations of SOME/IP within a network.
SOME/IP offers great flexibility for all types of data communication in a closely coupled inter-ECU ecosystem by providing communication of scalar data values to complex data structures.
SOME/IP provides large bandwidth for data communication in the range of 100Mbps and takes care of not wasting the bandwidth at all by providing all data communications in a client-server configuration.
SOME/IP allows the implementation of complicated service interfaces by supporting many different data types and multiple RPC mechanisms.
The data from the server ECU can be communicated to client ECU via unicast, multicast, and broadcast.
Being a middleware, it is suitable even for CPU-intensive applications.
SOME/IP can be implemented on many automotive operating systems and even embedded firmware with no operating system.

Conclusion
Automobiles are now essentially feature-packed with sophisticated heterogeneous electronic devices included in the vehicle ECU. These features include infotainment systems, driver assistance, cameras, diagnostics, navigation, and internet applications. Such diverse applications need a flexible, interoperable, and scalable network layer protocol that allows easy value-addition to a vehicle ecosystem despite different hardware and software environments. SOME/IP, a service-oriented protocol built over Ethernet, is perfect for the new automotive use-cases. Being compatible with AUTOSAR 4.x standard and compatibility with other automotive operating systems and non-OS firmware makes SOME/IP the best choice for automotive software. The inter-ECU data communication has never been so flexible and scalable until the SOME/IP network protocol development.