As described in our introductory article on SOME/IP, the SOME/IP (Scalable Service-Oriented Middleware over IP) protocol is a powerful communication framework that enables seamless interaction between distributed systems over IP networks. It provides a standardized way for services to discover, connect, and exchange data with each other, making it a crucial component in modern software development.
At its core, SOME/IP is built upon the principles of service-oriented architecture (SOA) and leverages IP-based networking to facilitate communication between various components. By utilizing the SOME/IP protocol, developers can create robust and scalable applications that can seamlessly integrate with other systems, regardless of their underlying technologies. Let us understand how SOME/IP recommends serializing the data, perform transmission of larger packets and the service discovery mechanisms in the coming sections.
Data Serialization in SOME/IP: Efficient Data Transfer
Efficient data transfer is a crucial aspect of any communication protocol, and SOME/IP addresses this through its data serialization mechanism. Data serialization refers to the process of converting complex data structures into a format suitable for transmission over a network.
SOME/IP supports direct serialization formats similar to C language data handling. By serializing data, it optimizes network bandwidth and reduces the size of the transmitted data, resulting in improved performance and efficiency.
The data can be either a single value (scalar) or a complex grouping of information (data structure) or a remote procedural call (RPC). SOME/IP defines the following basic data types that are used to represent scalar values.
- boolean: An 8-bit field that can hold with 0 for False or 1 for True
- 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: IEEE754 compatible 32-bit single precision floating-point number
- float64: IEEE754 compatible 64-bit double precision floating-point number
Following complex data types are supported in SOME/IP and are to be padded explicitly in case the elements do not align to their natural boundary.
- struct: Predefined list of parameters. It can start with an optional length field that specifies the size of all the bytes (excluding the length field).
- string: Contains sequence of ASCII, UTF-8, or UTF-16 characters. It can have fixed length (predefined) or dynamic length that begins with a big -endian encoded field specifying the length of the string.
- array: As with C, it is a set of parameters of the same data type that can be multi-dimensional. Dynamic length array must have a length field before start of the data.
- enumeration: An unsigned integer that can be used for custom naming purposes.
- bitfield: An 8-, 16- or 32-bit parameter in which each bit can be individually named and is a boolean value.
- union: A parameter that contains other parameters of different data types, that is determined at the run time.
The default data size is 32-bits, that is configurable, and all the size and type fields are encoded in big-endian format.
Transport Protocol - Larger packets over SOME/IP
The size of the SOME/IP payload depends on the transport protocol used whereby with UDP the payload can go up to about 1400 bytes - the natural boundary of the Ethernet frame. With TCP, there is no theoretical limit considering it supports segmentation of payloads by itself and hence larger sizes are automatically supported. So, when a sender wants to transmit a packet of over 1400 bytes on UDP, it can rely on the Transport Protocol mechanism defined by the SOME/IP specification.
The 6th bit (called the TP flag) in the Message Type field of the SOME/IP header is used to indicate if it is a segmented packet are not. If Message Type field has a value of 0x20 ORed, then it is a segmented packet and further the receiver should accumulate the subsequent packets to reassemble it. The sender thus splits a larger payload to smaller ones and sets this TP flag for all the segmented packets except the last one.
With this mechanism it is possible to accommodate larger data information over UDP easily without the hassles of the TCP/IP transport overhead.
Service Discovery in SOME/IP: Finding and Connecting to Services
With a server supporting a variable number of services, it is essential to have a mechanism to identify the services available. Though these are more or less static in an automotive network, the current state of the service instances is very much needed for the client to know before consuming them. The SOME/IP Service Discovery protocol comes to the rescue for the same. SOME/IP-SD protocol is used to locate the services instances, know their current states, and perform publish/subscribe operations.
The SOME/IP-SD header looks as below:
While the format is same as SOME/IP, it uses a reserved Message ID of 0xFFFF8100 for indicating it is specific to the Service Discovery protocol. The payload can have entries with optional Options array that describes the services offered/being subscribed.
In the example below, the SD Offer specifies that it supports a service ID (0x1234) at instance (0x5678). With the options array, it specifies that this particular service is available over IPv4 address 192.168.29.93 at UDP port 30509.
The SOME/IP-SD offers following services:
Offer: With this, the server actively sends the Offer messages over multicast with the list of available services to the client so that they can connect to it and consume them.Find: In some cases, the client might not have received the Offer, or it may want to explicitly know the current service offerings from the service. In this case, the client sends the Find service for which the server responds with Offer.
Stop Offer: When the service becomes unavailable, the server sends the Stop Offer over multicast for the clients to know.
Subscribe: The client, based on the Offer received, can subscribe to a particular set of services by sending the Subscribe message to the relevant event group.
SubscribeAcK: If the server can service the Subscribe request from the client, it acknowledges the same with SubscribeAck message and then publishes the events as requested.
SubscribeNacK: If for some reason, the server cannot provide the Subscribe service to the client, it sends a negative acknowledgment to the client indicating the same.
StopSubscribe: When a client no longer needs data from the event group, it can send a Stop Subscribe message to the server to unsubscribe from the event.
Implementing SOME/IP Protocol in Your Application
Whether it is a server or client, implementing the SOME/IP protocol in your application requires careful consideration of various factors and best practices. Here are some key steps to follow:
- Define Service Interfaces: Clearly define the interfaces for your services, including the methods, fields, and events they support.
- Implement Serialization: Carefully follow the serialization format, considering factors such as data complexity, alignment, and throughput.
- Implement Communication Handlers: Develop the necessary communication handlers for sending and receiving SOME/IP messages, taking into account the supported methods and events.
- Integrate Service Discovery: Incorporate the service discovery mechanism into your application, allowing services to dynamically discover and connect to each other.
By following these steps, you can successfully implement the SOME/IP protocol in your application, enabling seamless communication and interoperability with other systems.
The SOME/IP services supported by the server can be specified using the ARXML and FIBEX formats so that any third-party tools/client can consume it.
Conclusion
In conclusion, the SOME/IP protocol is a comprehensive and powerful middleware framework that enables seamless communication between distributed systems over IP networks. By understanding its key features, message structure, and implementation best practices, developers can harness the power of SOME/IP to build scalable, flexible, and efficient automotive applications.
With Automotive Ethernet becoming a norm, embrace the power of SOME/IP and unlock the potential of your automotive network.
