The rising demand for bandwidth has led the Automotive industry to think beyond CAN, FlexRay and even MOST. We are talking about applications like Infotainment, ADAS, highly automated driving and over-the-air update (OTA). All of these new age automotive solutions need lightning fast data transfer speed to the tune of 100 Mbps. Moreover, a paradigm shift from the existing signal-based communication (CAN, LIN) to service-based communication is something that can make a difference.
Ethernet emerged as the best fit considering the changing communication requirements of the ECU both within the vehicle and beyond. As an industry-wide accepted protocol, Ethernet is backed by over 30 years of rigorous R&D and proven protocols such as TCP/IP and UDP. However, Ethernet could not be used as it is, in the automotive industry.
There are certain add-ons that are required to make it compatible with the communication demands of an automotive ECU. One such pre-requisite, that we briefly mentioned above is the implementation of service-oriented architecture (SOA). And that’s where SOME/IP (Service-oriented Middleware over IP) takes the center stage.
But before we go into the nuances of SOME/IP, it is recommended we understand the service-oriented communication in contrast to the signal-based communication.
Signal-Based Communication vs Service-Oriented Architecture
Signal-based communication has long been used in communication protocols such as CAN, LIN, FlexRay, MOST and more. As the software and hardware in such automotive solutions are closely coupled, the communication between the ECUs are defined statically. It is assumed that the software will not be modified during its lifetime. Signal based communication was best suited for such applications.
In the realm of Signal-based communication, the data is sent over the network whenever the data values are updated or modified. The sender is not concerned about whether the data is required by a node in the network. Such an arrangement may burden the nodes with unwanted data that they might never require.
Fast forward to Service-oriented architecture, the sender sends the data only if a receiver needs it. Therefore, in such an arrangement, the server has to be notified about the receivers that are waiting for the data. This is merely one aspect of the service-based communication.
When we talk of highly automated driving, ADAS, connected cars, etc., service-oriented architecture (SOA) is a must-have. Powered by Ethernet and SOME/IP, SOA models the entire system as service interfaces. New software can be easily added to the system without worrying about the compatibility with others.
While Ethernet provided the backbone and TCP & UDP the transport layer, a middleware was required for data serialization, remote call procedure, etc. And that’s precisely why SOME/IP was created!
What is SOME/IP?
SOME/IP stands for Scalable Service-Oriented Middleware over IP and was developed by BMW group in the year 2011. The name makes it abundantly clear that it is a middleware solution that enables service-oriented communication between the control units. More specifically, SOME/IP offers a wide range of middleware features like serialization and Remote Procedure Call (RPC) to enable the ECU software to communicate with each other.
SOME/IP can be implemented on both OS (Genivi, AUTOSAR, Linux and OSEK) and Non-OS embedded system. In the recent past, it has emerged as the middleware of choice for Adaptive AUTOSAR implementation.
As already mentioned, the service-oriented architecture makes it easier for the software components over diverse networks to communicate with each other. Therefore, in order for these applications on different networks to understand each other, there has to be some kind of a middleware. Its primary role is to resolve the message format and make it comprehendible to the intended recipient of the message. SOME/IP has been specifically designed for this purpose.
So how does SOME/IP resolve the different data packets and makes the inter-ECU communication possible? Let’s find out!
Some Key Features of SOME/IP:
- Serialization: It is the way the data is represented in a data unit, which can be either a UDP or a TCP message. When data is transmitted over network, the ECU reading the data might have a different architecture, operating system, etc. inter-operability can be ensured only if there is a mechanism for a consistent data transmission. SOME/IP allows for some serialization.
- Remote Procedure Call (RPC): This is a method for remote invocation of functions as requested by the Client ECU. It is a data exchange method employed by the client ECU when it requires some data from a server. An RPC may or may not have a return value, i.e., the client can ask for data as a response or simply call a function to perform some task at the server-end.
- Service Discovery: The service discovery (SD) protocol is the backbone of SOME/IP concept. In a service-oriented architecture, it is imperative for the service (functional entity- methods, events or fields) to be discoverable. The SOME/IP SD protocol manages this aspect- whether to offer a service or stop it from being available.
- Publish/Subscribe: A client can subscribe to the content of the server so that it can receive the updated data from the server dynamically. Publish/subscribe feature of SOME/IP deduces which data (event/field) a client needs and shares the same. Pub/Sub is managed by SOME/IP SD.
So far, we have understood the concept of service-oriented architecture and the role of SOME/IP in its implementation. We will now delve a little deeper to understand how exactly SOME/IP and Ethernet enable the inter-ECU Client/Server communication.
Understanding how Communication through Ethernet and SOME/IP Works
Before we start with our exploration, we must understand some terms associated with SOME/IP.
| Service | A combination of events, methods or field that offers an interface |
| Service Instance | It is a single instance of the service; It implements a service interface |
| Event | It is a message from the server to the client when something happens |
| Field | It is part of the service that represents the status and thus always has a value |
| Getter/Setter | A Request/Response call that gives the access to read/write on a field property |
| Event Group | It is a logical group of more than one events |
| Method | It may be a function, a subroutine or a procedure that can be invoked |
| Notifier | Responsible for sending an event message when a field value is changed |
| Notification Event | An event message sent by the notifier |
The Server ECU provides a service instance which implements a service interface. The client ECU can use this service instance using SOME/IP to request the required data from the server. The Service Discovery protocol has two mechanisms in place by which a client knows about the available services.
The first mechanism is the ‘Offer Service’ using which the server is able to provide the available services to the network. The other one is ‘Find Service’, which enables the clients to request for the available services.
However, in order for the client to use the service, it has to subscribe to the content on server first.
Using the SOME/IP Service Discovery protocol, a client can send a Subscribe Eventgroup to the server. If the subscription request is valid, the server will respond with a positive acknowledgement and vice-versa.
As the applications inside the ECUs are not tightly coupled in a Service-oriented architecture, multiple clients can subscribe to a service on the server simultaneously. The data can be made available either over UDP or TCP. In case of UDP, data is sent to all the clients who are active subscribers. The data transfer is usually sent via unicast, multicast or broadcast. However, with TCP, the requesting client must establish a connection with the server for data transfer.
While the underlying principle of SOME/IP is based on the client-server architecture where a request by a client is followed by a response from the server, there are several methods/communication patterns for the communication. Let’s have a look at them.
- Request/Response Method
- A request is a message sent from the client to the server for calling a function.
- Response is the message sent from the server to the client depicting the result of the function invoked by the client
- Fire and Forget Method
- A message is sent to the server from the client to call a function
- No response is returned from the server
- Services: Event
- An event is a callback sent from the server to the client either cyclically or when a change in the server attributes occur
- The server notifies about the change only to those clients who have previously subscribed
- A notification of event is sent to the client every time the event occurs
- Services: Field
- Field is a property of service that can be remotely accessed using Getters/setters.
- Getter is the method to read field value
- Setter is the method to set the field value
- When a field’s value changes, a notification event is sent out by the notifier.
Value-Adds of SOME/IP as an Inter-ECU Communication Protocol
The fact that SOME/IP enables service-oriented architecture itself adds a lot of value. Not only does it make the entire vehicle network dynamic and flexible, but also provides the backbone required for implementation of CPU-intensive applications.
Let’s check out some more advantages that SOME/IP brings to the table:
- Adding new functions to a vehicle electronics system becomes easier
- Provides the required flexibility to the vehicle system as part of a connected ecosystem
- Complicated service interfaces can be implemented using Ethernet with the help of events and methods
- It supports both unicast and multicast.
- It reduces the complexity of the data path by introducing events, notifiers, etc.
The Bigger Picture
SOME/IP is a masterfully crafted middleware with features of CAN, MOST and FlexRay along with the coveted service-oriented communication. Its liaison with another path-breaking technology- Adaptive AUTOSAR, is already grabbing eyeballs. Together, they have the potential to change the way automotive software is developed and integrated to the ECU network.
