Hello Readers, 👋😍 My name is Nagaraj B H and I am a Junior Software Engineer at Luxoft India. Luxoft gave me several opportunities to work on many projects that made me discuss important strategies for SOME/IP communication development. Here we talk about SOME/IP communication in detail.
Introduction: Due to the 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).
Scalable: This protocol is designed for scalability and interoperability between 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, 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 is never wasted and data is only transferred/exchanged when needed.
Middleware: This is a middleware protocol, which means it resides in the application layer and has its own general-purpose protocol layers to handle more specific functions and applications.
over IP: This 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 a server, the client requests it using the TCP protocol. If the server needs to transmit data to all active subscribers, it is sent via the UDP protocol As a middleware, SOME/IP can provide many different applications/functions such as different general-purpose protocol layers.
Some of the main functions/applications of SOME/IP are as follows.
Serialization: The protocol takes care of converting messages between ECUs in a wired representation and back. In its wired 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 lookup: Communication using the SOME/IP protocol takes place in a client-server agreement. SOME/IP is based on a service architecture. The server provides many different services that client devices can subscribe to. The protocol allows clients to dynamically search for services, subscribe to them and determine access to services.
Publish/Subscribe: Data transfer in SOME/IP is done by 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.
UDP message segmentation: 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 the 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. A field represents the state of an entity and can be a declarer, receiver, or setter. A notifier is a field that is sent from the server to the client when the value changes. A getter is a field that the client sends to the server to request a specific value. A setter is a field sent by the client to the server to explicitly change/modify the value. An event is a message that is sent from a server to a client when a value is changed or sent cyclically to clients. A method is a (program) function/procedure/subroutine that can be called. The method is triggered on the server by the remote call from a client.
The service provides a single copy of the interface and a service interface is called a copy of the service. An instance of the service is provided by the ECU server, which implements the service interface. The Client ECU can use the Server ECU to get a copy of the service (fields, events and methods). If the necessary services are found through both mechanisms, they can order these copies of the service. For an order, the client must send an Order transaction group to the server.
The server checks the subscription request for validation, and if found valid, returns a positive confirmation. Multiple clients can subscribe to a given service instance.
Conclusion: Automotive industry is 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. ECU communication has never been so flexible and scalable before the development of the SOME/IP network protocol.
Top comments (0)