SOME IP in Five Minutes
Everybody needs a "five-minute" article to get started with a new topic. Here is a quick overview of SOME/IP.
SOME/IP stands for "Scalable Oriented MiddlewarE over IP". It is a communication protocol that targets embedded projects, typically in the automotive industry. It is driven by the AUTOSAR (AUTomotive Open System ARchitecture) consortium. Therefore, you can find the specification of the SOME/IP communication protocol on autosar.org, e.g., Release 22-11.
SOME/IP is typically used for inter-ECU communication. Since SOME/IP works over UDP or TCP, it does not matter which operating system is running on the ECUs or PCs. It could be Linux, Windows, QNX, AUTOSAR Classic, or even a bare-metal microcontroller as long as UDP or TCP is supported.
For intra-ECU communication, using an IPC mechanism is recommended. The SOME/IP serialization for communication on the same ECU is not needed. Therefore, an IPC mechanism is the better choice, e.g., Unix Domain Sockets or Shared Memory communication.
Here is an example network topology showing ECUs and PCs using different operating systems. The devices could be connected via switched Ethernet.
In SOME/IP, everything is based on Services. A service is a functionality offered by an ECU (= server). A server can even offer multiple services allowing to logically separate different functionalities. Clients, i.e. other ECUs can use the offered services.
For example, one ECU could offer a "Calculator service" via SOME/IP. Clients could call the Calculator Service remotely and pass an operation code (add/subtract/multiply/divide) as well as two operands. The server will calculate the result and send back a response to the calling client. This type of service is called a Method in SOME/IP. It describes a request-response communication.
Another type of service are Notification Events. If one ECU has a button connected and wants to notify other ECUs every time the button is pressed, it can offer a SOME/IP service containing an Event. Other ECUs can subscribe to this service and will receive a notification in case the button is pressed. Notification Events in SOME/IP describe a publish/subscribe communication.
In SOME/IP, Services can be seen as a blueprint or template similar to a class in object-oriented programming. Services are instantiated once or multiple times into Service instances allowing ECUs to offer multiple instances of the same service. E.g., if there are three buttons connected to one ECU, the ECU could simply offer three service instances all providing the same "button press service".
In SOME/IP Services, Instances, Methods, and Events are identified by IDs (numbers). In other middlewares, e.g., in ROS (Robot Operating System), instances (ROS Topics) are identified by names.
Besides providing functionality as Methods and Notification Events, SOME/IP also takes care of the on-wire serialization of data. SOME/IP allows you to use basic datatypes (like unsigned/signed integers and floating-point numbers) and strings or define structures and arrays. The structures can be used as arguments for Methods or as datatypes for Events. SOME/IP takes care of properly serializing data on the sender-side in order to transport it via UDP or TCP and deserialize data on reception.
While it is possible to statically define a network topology (IP addresses and ports) and all IDs in a system beforehand, a major feature of SOME/IP is Service Discovery. Service Discovery allows a Service to announce itself on the network to potential clients by sending SOME/IP SD Offer Entries via UDP multicast. Clients can search for services by sending so called Find Entries via multicast. In case the offered and requested IDs match, servers and clients can dynamically find each others services without knowing the IP addresses of each ECU beforehand.
For applications using SOME/IP, the network topology is therefore transparent. It does not matter which ECU is offering a service. For an application it is only of importance that a service can be found via SOME/IP Service Discovery. The application is only dependent Service, Service Instance, and Method/Event IDs.