SomeIpXf Overview - SOME/IP Messages and VFB Serialization in Autosar

SomeIpXf is a serializer transformer dedicated to SOME/IP. It specifies both client-server, sender-receiver and trigger communication concepts from the VFB, with the goals of fulfilling the resource consumption requirements of embedded systems, provide compatibility and scalability with different platforms and operating systems and supporting the use cases of automotive.

The SOME/IP transformer implements some features of SOME/IP (so you will learn part of the SOME/IP protocol in this article, but only the essentials to get you started, as we will create one post dedicated to the SOME/IP protocol, so stay tuned), while others are handled by either the Service Discovery (SD) or the Socket Adaptor (SoAd) modules or have been left out by Autosar. Nonetheless, it is less limiting than ComXf (COM Transformer), other than supporting only out-of-place buffering. As you can guess, there will be SOME/IP specific values added to the serialized data.

The SOME/IP features not supported by the current Autosar implementation of SomeIpXf are:

• Exceptions and exception-related data structures.
• Some header information inserted by the SoAd is lost when routing SOME/IP messages through CAN or FlexRay.
• Queued fire-and-forget methods without parameters are not supported.
• Arrays are not checked for a minimal number of elements.
• Optional method arguments are not supported.

Moreover, its configuration is entirely contained within the SOMEIPTransformationDescription and SOMEIPTransformationISignalProps. It will be used as a transformer if some parameters of the TransformationTechnology are set, namely protocol, to SOMEIP, version, to 1 and transformerClass to serializer.

SOME/IP Messages

The SOME/IP header format (which is always encoded in big endian) can be observed in the figure below, for both SOME/IP and SOME/IP-SD messages, where Message ID and length are not implemented by the SomeIpXf:

Structure of a SOME/IP Message

One by one, the parameters present in a SOME/IP message are described below.

• Message ID - Comprised by the Service ID and Service Instance ID (method ID / Event ID), and has to be unique within the vehicle:

  • Service ID – Identifies a service. These values should be different for each service and service instance within a vehicle. The reserved service IDs are defined in the table below:

• Event ID – Identifies an event or notification inside a service. The highest bit is set to 1.

• Method ID – Identifies a method inside a service. The highest bit is set to 0. The following values, depicted in the table below, are reserved for both method and event IDs in the service 0xFFFF:

• Length – Message length after this point.

• Request ID – Comprised of the client ID and session ID (basically a sequence counter), it is used to distinguish different calls for the same service, therefore, it has to be a unique client and server combination. The values are chosen by the RTE and passed on to the SomeIpXf.

• Protocol Version – Version of the SOME/IP protocol, set to 0x01.

• Interface Version – Version of the SOME/IP interface.

• Message Type – The SOME/IP message type. It can be one of the following values described in the table below:

• Return Code – Return code of the message. Set to 0x00 for the message types REQUEST, REQUEST_NO_RETURN and NOTIFICATION.

• Payload – Contents of the message.

SOME/IP VFB Serialization

Since SOME/IP supports client-server, sender-receiver and trigger communication, we should have a look at how SomeIpXf serializes each of them. Today, you will get a general overview on the procedure.

Do not get confused with the serialization of the parameter types (client-server communication) and data structures (sender-receiver communication). These will be tackled separately in another article, due to the different number of cases that can exist. This will also be accompanied with examples, so that you get the full picture. Make sure to stay updated for these new articles!

Client-Server Communication

Starting with client-server, the following steps take place:

1. The payload is constructed, taking into account all the IN and INOUT ArgumentDataPrototypes of the ClientServerOperation, according to their order.
2. Request ID is optionally set to a unique number.
3. Protocol version and interface number are set.
4. Message type is set to REQUEST (0x00) and the return code to 0x00.

For the server response, this is the procedure for valid communication:

1. The payload is constructed by considering the INOUT and OUT ArgumentDataPrototypes of the ClientServerOperation, according to their order within it.
2. Message type is set to RESPONSE (0x80).
3. If one or more PossibleErrors are defined in the ClientServerOperation, the return value is set from 0x1F in case of error, and 0x00 otherwise.

In case of problems with the client-server communication, the SOME/IP transformer can autonomously construct a RESPONSE message with the return value given by the client minus 0x80 and empty payload. Moreover, client-server communication is the only type that supports error messages.

Sender-Receiver Communication

For sender-receiver communication, one Session Handling ID counter (same as Request ID) is initialized to 0x0001 and maintained if the option sessionHandlingSR.sessionHandlingActive is set. On the sender side, the serialization procedure takes shape like this:

1. The payload is created according to the element to be transferred.
2. The Request ID is set as stated before if sessionHandlingSR.sessionHandlingActive is selected, and 0x0000 otherwise. On the receiver side, the session ID is ignored.
3. Protocol and interface versions are set.
4. A message type is chosen according to the SOMEIPTransformationISignalProps, to either NOTIFICATION (0x02) when the messageType is set to notification, or REQUEST_NO_RETURN (0x01), in case the attribute is defined as requestNoReturn.
5. Return code is set to 0x00.

Trigger Communication

Laslty, trigger events are used to trigger Remote Procedure Calls (RPCs) in a fire-and-forget manner by SOME/IP and do not contain any arguments (therefore, the payload is empty), to be sent from one server to one or many clients, and these shall react accordingly. The source serializes them as such:

1. Define the Session ID in the same manner as sender-receiver communication.
2. Set the protocol and interface version.
3. Select the REQUEST_NO_RETURN (0x01) message type.
4. Add the return code 0x00.

Alright, this is all we have time for today! Hopefully this article gave you the general picture on how SOME/IP serialization works on the VFB level, allowing you to understand how the different supported ports and interfaces are mapped into a SOME/IP message. We will build upon this information in future posts, so if its not completely clear to you, do not worry too much, as you will have more contact points with this topic.

Remember, place yourself on the waiting list for the upcoming ebooks, where this will definitely be explained with greater detail, providing more examples, exercises and other material that will make you an automotive development powerhouse!

Author: Micael Coutinho (opens in a new tab)

References:

• Specification of SOME/IP Transformer - Autosar (opens in a new tab)