Scalable Service-Oriented Middleware over IP(SOME/IP)

Introduction and overview

• The SOME/IP (Scalable Service-Oriented Middleware over IP) protocol is a powerful communication framework that enables seamless interaction between distributed systems over automotive IP networks. Running on top of UDP or TCP, it provides a standardized way for services to discover, connect, and exchange data with each other.
• SOME/IP supports remote procedure calls, event notifications and the underlying serialization/wire format.
• Compatible with AUTOSAR at least on the wire-format level; i.e. can communicate with PDUs AUTOSAR can receive and send without modification to the AUTOSAR standard.
• It can be implemented on different operating system like AUTOSAR, Genivi and OSEK.
• It shall be used for Inter-ECU Client/Server serialization.
• Implementation of SOME/IP allow AUTOSAR to parse the RPC Pdus and transport the signal to application.
• SOME/IP is built upon the principles of service-oriented architecture (SOA) as against the typically signal-oriented messaging generally followed by CAN, LIN and FlexRay technologies

Key Features and Benefits of the SOME/IP Protocol

The SOME/IP protocol offers a range of key features and benefits that make it an attractive choice for building distributed systems:

1. Scalability:

SOME/IP provides a scalable architecture that allows systems to grow and adapt to changing demands. It enables the addition of new services and components without disrupting the existing infrastructure, making it ideal for large-scale applications.

2. Flexibility:

With SOME/IP, developers have the flexibility to configure services and fields according to their specific requirements. This allows for the customization and optimization of the communication process, resulting in efficient data transfer and reduced latency.

3. Real-time Communication:

SOME/IP supports the Services-Event mechanism, enabling real-time communication between services. This feature is crucial for applications that require instant updates and notifications, such as in automotive systems where timely information exchange is critical for safety and performance.

4. Service Discovery:

SOME/IP incorporates a robust service discovery mechanism that allows services to find and connect with each other dynamically. This eliminates the need for hard-coded IP addresses and simplifies the integration of new services into an existing system.

5. Efficient Data Transfer:

Data serialization is a core aspect of the SOME/IP protocol, ensuring efficient and compact representation of complex data structures. By serializing data, developers can optimize network bandwidth and reduce processing overhead, leading to improved overall system performance.

Services in SOME/IP

As the name Scalable Service-Oriented Middleware over IP implies, the building blocks of the SOME/IP protocols are its services. A service consists of one, multiple or none of Fields, Methods and Events.

Fields are the data components that essentially hold a value such as Engine Temperature. It can offer one or more of the following features.

• Setter: When a subscriber can change the value
• Getter: The subscriber can read the value
• Message ID [32 Bit]:? The Message ID shall be a 32 Bit identifier that is used to identify the RPC call to a method of an application or to identify an event.

Request/Response Communication:

The Request/Response method is a fundamental communication pattern in the SOME/IP protocol. It enables a client to send a request to a server and receive a corresponding response. This method is widely used in scenarios where a client requires a specific service or data from a server.

For the SOME/IP request message the client has to do the following for payload and header:

• Construct the payload
• Set the Message ID based on the method the client wants to call
• Set the Length field to 8 bytes (for the part of the SOME/IP header after the length field) + length of the serialized payload?????????
• ?Optionally set the Request ID to a unique number (shall be unique for client only)
• Set the Protocol Version according [PRS_SOMEIP_00052]
• Set the Interface Version according to the interface definition
• Set the Message Type to REQUEST (i.e. 0x00)
• Set the Return Code to 0x00

?Fire &Forget Communication:

The Fire-and-Forget method is another communication pattern supported by the SOME/IP protocol. Unlike the Request/Response method, the Fire and Forget method does not expect any response from the server. It is commonly used in scenarios where a client needs to send a command or trigger an action but does not require any specific response or confirmation.

?For the SOME/IP request-no-return message the client has to do the following for payload and header:

• Construct the payload
• Set the Message ID based on the method the client wants to call
• Set the Length field to 8 bytes (for the part of the SOME/IP header after the length field) + length of the serialized payload??????????
• Optionally set the Request ID to a unique number (shall be unique for client only)
• Set the Protocol Version according [PRS_SOMEIP_00052]
• Set the Interface Version according to the interface definition
• Set the Message Type to REQUEST_NO_RETURN (i.e. 0x01)
• Set the Return Code to 0x00?

Some important term used in SOME/IP

• Request:? ?A message of the client to the server invoking a method
• Response:? A message of the server to the client transporting results of a method invocation
• Event: Events provide data that are sent cyclically or on change from the provider to the subscriber
• Methods: are functions or remote procedural calls that can be invoked on the provider by the subscriber. Examples include initiating an Auto learning process etc.
• Remote Procedure call(RPC):? A method call from one ECU to another that is transmitted using messages

SOME/IP Message Format (Serialization):

Serialization describes the way data is represented in protocol data units (PDUs) as payload of either UDP or TCP messages, transported over an IP-based automotive in-vehicle network.

SOEME/IP Headers: The structure of header layout consist of

• Message ID (Service ID/Method ID) [32 Bits]
• Length [32 Bits]
• Request ID (Client ID/Session ID) [32 Bits]
• Protocol Version [8Bits]
• Interface Version [8 Bits]
• Message Type [8 Bits]
• Return Code [8 Bits]

Message ID [32 Bit]:? The Message ID shall be a 32 Bit identifier that is used to identify

• the RPC call to a method of an application
• or to identify an event.

Method ID [16 Bit]:? The Message ID header field shall be structured into a 16 Bit Service ID header field (to distinguish up to 216 services) and a 16 bit Method ID header field to distinguish up to 216 service elements (namely methods and/or events). Methods would be in the range 0x0000-? 0x7FFF (first bit of Method-ID is 0) and Events/Notifications would use the range 0x8000-0x8FFF.

Length [32 Bit]:? Length field shall contain the length in Byte starting from Request ID/Client ID until the end of the SOME/IP message

Request ID [32 Bit]: The Request ID allows a server and client to differentiate multiple parallel uses of the same method, getter or setter. Request ID shall be constructed of the Client ID and Session ID

In case Session Handling is not active, the Session ID shall be set to 0x00 and case Session Handling is active, the Session ID shall be set to a value within the range [0x1, 0xFFFF]

?Protocol Version [8 Bit]:? The Protocol Version identifies the used SOME/IP Header format (not including the Payload format).

?Interface Version [8 Bit]: Interface Version shall be an 8 Bit field that contains the Major Version of the Service Interface.

Message Type [8 Bit]:? The Message Type field is used to differentiate different types of messages and shall contain the following values as shown in Table

Note: Regular request (message type 0x00) shall be answered by a response (message type 0x80), when no error occurred. If errors occur an error message (message type 0x81) shall be sent

?Return Code [8 Bit]:? The Return Code shall be used to signal whether a request was successfully processed.

Payload [variable size]:? The size of the SOME/IP payload field depends on the transport protocol used. With UDP the SOME/IP payload shall be between 0 and 1400 Bytes. Since TCP supports segmentation of payloads, larger sizes are automatically supported.

Protocol Specification:

• SOME/IP provides service oriented communication over a network. It is based on service definitions that list the functionality that the service provides. A service can consist of combinations of zero or multiple events, methods and fields.
• In order to transport SOME/IP messages different transport protocols may be used. SOME/IP currently supports UDP and TCP.
• When transporting multiple SOME/IP payloads in UDP or TCP the alignment of the payloads can be only guaranteed, if the length of every payloads is a multiple of the alignment size (e.g. 32 bits)
• The header format allows transporting more than one SOME/IP message in a single packet. The SOME/IP implementation shall identify the end of a SOME/IP message by means of the SOME/IP

?length field. Based on the packet length field, SOME/IP shall determine if there are additional SOME/IP messages in the packet.

• Each SOME/IP payload shall have its own SOME/IP header.

Magic Cookies: In order to allow testing tools to identify the boundaries of SOME/IP Message transported via TCP, the SOME/IP Magic Cookie Message may be inserted into the SOME/IP messages over TCP message stream at regular distances.

for communication from Client to Server:

– Message ID (Service ID/Method ID): 0xFFFF 0000

– Length: 0x0000 0008

– Request ID (Client ID/Session ID): 0xDEAD BEEF

– Protocol Version: 0x01

– Interface Version: 0x01

– Message Type: 0x01

– Return Code: 0x00

for communication from Server to Client:

– Message ID (Service ID/Method ID): 0xFFFF 8000

– Length: 0x0000 0008

– Request ID (Client ID/Session ID): 0xDEAD BEEF

– Protocol Version: 0x01

– Interface Version: 0x01

– Message Type: 0x02

– Return Code: 0x00

Transporting large SOME/IP messages of UDP (SOME/IP-TP)

• The UDP binding of SOME/IP can only transport SOME/IP messages that fit directly into an IP packet.
• If larger SOME/IP messages need to be transported over UDP (e.g. of 32 KB) the SOME/IP Transport Protocol (SOME/IP-TP) shall be used.
• Use TCP only if very large chunks of data need to be transported (> 1400 Bytes) and no hard latency requirements in the case of errors exists
• SOME/IP messages using SOME/IP-TP shall activate SesSion Handling
• SOME/IP-TP segments shall have a TP header right after the SOME/IP header

• UDP-based SOME/IP messages are limited to 1400 bytes payload. Due to this, the maximum length of a segment that is correctly aligned is 1392 bytes

Example.

This example describes how an original SOME/IP message of 5880 bytes payload has to be transmitted. The Length field of this original SOME/IP message is set to 8 + 5880 bytes.

This original SOME/IP message will now be segmented into 5 consecutive SOME/IP segments.

• For these segments, the SOME/IP TP module adds additional TP fields (marked red). The Length field of the SOME/IP carries the overall length of the SOME/IP segment
• including 8 bytes for the Request ID, Protocol Version, Interface Version, Message Type and Return Code. Because of the added TP fields (4 bytes), this Length information is extended by 4 additional SOME/IP TP bytes.

• The first 4 segments contain 1392 Payload bytes each with "More Segments Flag" set to ’1’:
• The last segment (i.e. #5) contains the remaining 312 Payload bytes of the original 5880 bytes payload. This last segment is marked with "More Segments flag" set to ’0’.

Note: Please be aware that the value provided within the Offset Field is given in units of 16 bytes, i.e.: The Offset Value of 87 correspond to 1392 bytes Payload.

• SOME/IP messages shall be checked by error processing. This does not include the application based error handling but just covers the error handling in messaging and RPC. An overview of the error processing is shown below

Conclusion:

With the growing demand for automotive bandwidth requirements and moving towards Automotive Ethernet service-oriented communication is a much-needed solution. The existing communication protocols based on signal-oriented data such as CAN, LIN, FlexRay, etc are not efficient enough to meet up the requirements

References: https://www.embien.com/automotive-insights/scalable-service-oriented-middleware-over-ip-an-introduction

https://www.autosar.org/fileadmin/standards/R22-11/FO/AUTOSAR_PRS_SOMEIPProtocol.pdf