Hello readers! 👋😍. My name is Ashwin, and I am a Junior Software Developer at Luxoft India. I have been fortunate to work on adaptive projects at Luxoft which has helped me gain valuable experience in Adaptive Autosar and inspired me to discuss
about SOMEIP.
Introduction
Today's cars are not just a means of transportation and transportation; vehicles are now designed full of features to make the journey a luxurious experience. All this is achieved by integrating advanced electronics into the vehicle's ECU (Engine Control Unit). This new scenario significantly changed the communication between different ECUs. Traditional automotive protocols such as CAN, MOST, LIN, and Flexray are signal-based communication protocols, and these protocols have some significant limitations, as noted below.
Traditional protocols such as CAN, LIN, MOST and Flexray have limited bandwidth. These protocols only apply to static systems that have not undergone software updates or upgrades during their lifetime. In these protocols, data is transferred between the sender and receiver where ever an event occurs. The receiver may not need the information for every event. Therefore, in these protocols, there is always additional data in the communication channel that cannot be avoided or managed in any way. Conventional protocols such as CAN, LIN, MOST and Flexray are signal-based communication protocols and do not ensure interoperability between different operating systems, embedded firmware, data interfaces and application software. Due to the aforementioned limitations of traditional automotive communication protocols, in 2011 the BMW Group launched a middleware protocol for data transfer between different heterogeneous units of any ECU, Scalable Service-Oriented Middleware over IP (SOME/Ip).
These protocol's are:
Scalable: This protocol is designed with scalability and interoperability between heterogeneous devices with different hardware platforms, operating systems and embedded firmware, different application software.
Service-Oriented: It is a service oriented protocol. Therefore in a client-server configuration data is exchanged only when the client requests it or when the server informs certain subscribers about it This ensures that bandwidth are never wasted and data is transferred/exchanged when necessary.
MiddlewarE: It is a middleware protocol, which means that it resides in the application layer and has its own general-purpose protocol layers to handle more specific functions and applications.
over IP: It is an Ethernet-based protocol. It uses a similar hardware interface that provides bandwidth up to 100 Mbps. Data is transmitted through the middleware, or application layer, over a network cable using TCP/IP or UDP protocols. When a client requests information from server the client requests it using TCP protocol. If the server needs to transmit data to all active subscribers, it is sent through UDP protocol. Communication over the UDP protocol can be unicast, multicast or broadcast.
Features of the SOME/IP protocol SOME/IP is a network layer protocol that works as a middleware, ie. is logically implemented in the application layer. As a middleware, IUJ/IP can provide many different applications/functions, such as different general-purpose protocol layers. Some of the key functions/applications of IUJ/IP are as follows. Serialization: The protocol takes care of converting messages between ECUs in a wired representation and back. In cable form, the protocol is compatible with the AUTOSAR .x standard. Remote Procedure Calls (RPC) and Messaging: The protocol can deliver messages (sent as fields) and remote procedure calls (application procedure/function calls).
Service Discovery:
Communication using the SOME/IP protocol takes place in a client-server agreement. Some /IP addresses are based on the architecture of the service. The server provides many different services that client devices can subscribe to. The protocol allows clients to dynamically search for, subscribe to, and allocate access to services.
Publish/Subscribe: Communication in ANY/IP is via publish/subscribe. Clients can subscribe to services provided by the server, and the server can publish notifications to active subscribers. It allows dynamic configuration between client devices and the server. With publish/subscribe, the server can selectively deliver data to clients that need specific messages between ECUs.
Segmentation of UDP messages: When the server needs to send notifications to active subscribers, they are sent using the UDP protocol. ANY/IP can transmit large UDP messages without fragmentation.
How SOME/IP protocol works
All communication in the SOME/IP protocol occurs as services. The ECU server provides services. Client devices can dynamically discover services provided by the server (Service Discovery), order services and complete settings to access the ordered services.
Services are a combination of areas, events and/or methods. A field represents the state of an entity and can be a notifier, recipient, or setter. A notifier is field that are sent from the server to the client when the value changes A getter is a field that client sends to server and request a specific value. A setter is a field that the client sends to the server to explicitly change the value.
An event is message sent from server to client when a value is changed or sent cyclically to clients A method is a (program) function that can be called. The method are invoked on the server by a remote call from the client. A service provides interface and a single instance of service that implements the service interface which is called a service instance A service instance is provided by server ECU that implements the service interface. The client ECU can use service event to retrieve the necessary data fields, events, and methods from server ECU.
Client devices know about available services ie. available service instances, using the service discovery protocol. The service request protocol has two mechanisms for communicating the availability of services - "Offer Service" and "Search Service". When the server ECU communicates available services to the network (all client ECUs), the mechanism is called "service provisioning". When clients request available services from the ECU server, the Find Service mechanism is called. Therefore, the search for services available on the network can be initiated by both the server ECU and the client ECU.
SOME/IP supports the following complex data types–
struct: This is a list of predefined parameters. The structure begins with an optional length field that indicates all bytes following the length field.
string: Strings containing ASCII,UTF-8 and UTF-16 characters. Springs can be fixed length or dynamic length Dynamic length strings start with an endian field indicating the length of the string.
array: A set of parameters of same data type. Arrays can be one-dimensional or multi-dimensional. The table length can be fixed or dynamic. A dynamic length table starts with a length field.
enumeration: It is an unsigned integer that expresses different values in its bits.
union/variant: It is the parameter which contain other's parameter of different data types.
Data is transferred between the server ECU and the client ECU via UDP or TCP protocols. The UDP protocol is used when the server needs to send data to all active subscribers (such as notification fields and events). Data transmission with UDP can be unicast, multicast or broadcast. When the client needs to send data to the server (such as getter, setter fields and RPC), the client must connect to the server using the TCP protocol.
In SOME/IP, there is the four methods remote procedure calls (RPC) and are as follows:
Request/Response method: In this method a request for calling a function 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 are 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 message communicated from server to client when a value are changed and 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 method which read a field value and Setter is the method to change the field value. Notifier is notification event triggered by a change of a field value.
The data like fields, events, and methods is 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 consist 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:
The Some/IP protocol has many advantages over traditional automotive protocols such as CAN, LIN and MOST. Some of the notable benefits of Some/IP include: As a service-oriented protocol, it is interoperable and scalable. New parameters and functions can be easily added to the vehicle system via Some/IP. Only the header must be identical across all network/IP applications. Some/IP offers great flexibility for all types of data transfer between ECUs in a tightly coupled ecosystem, allowing the transfer of scalar data values into complex data structures.
SOME/IP provides high bandwidth for data communication in the range of 100 Mbps and ensures that bandwidth is not wasted by providing each data transfer in a client-server configuration. Some/IP allows the implementation of complex service interfaces, supporting many different data types and multiple RPC mechanisms. Data from Server ECU can be transmitted to client ECU via unicast multicast and broadcast. As middlewar is even suitable for CPU-intensive applications Some/IP can implemented in many automotive operating systems and even embedded firmware without operating system.
Conclusion
Cars are now mostly packed with complex heterogeneous electronics housed in the vehicle's ECU. These functions include infotainment systems, driver assistance, cameras, diagnostics, navigation and internet applications. Such versatile applications require a flexible, interoperable and scalable network layer protocol that enables easy value addition to the vehicle ecosystem despite different hardware and software environments. SOME/IP, a service-oriented protocol built on top of Ethernet, is perfect for new automotive applications. Compatibility with the AUTOSAR .x standard and compatibility with other automotive operating systems and non-OS firmware make Some/IP the best choice for automotive software.
Top comments (0)