Scalable service-Oriented MiddlewarE Architecture in AUTOSAR

1. SOME/IP Motivation

The automotive industry is currently facing disruptive changes in multiple areas. Examples are more ADAS w/ the goal of fully autonomous vehicles, the switch from internal combustion engines towards electric motors /fuel cell, and the increasing connectivity internally as well as w/ its environment due to wirless interfaces. As a result, modern vehicles can be assigned to cyber-physical systems claass, while the relevance of software and electronics in terms of innovation and value creation in the automotive industry will continue to increase significantly. This evolution transforms the vehicle from a hardware-driven product to a software-driven device, which requires new approaches, especially in the area of software and electrical and electronical architecture (E/E architecture).

In order to meet increasing communication needs, BMW group designed SOME/IP in 2011, and it's compatible to AUTOSAR standards. It relies on using Ethernet and TCP/IP.

2. Key features of SOME/IP

• SOME/IP provides service oriented communication over a network;
• SOME/IP supports a wide range of middleware features;

a. Serialization - transforming into and from on-wire representation

b. Remote Procedure Call(RPC) - implementing remote invocation of functions

c. Service Discovery(SD) - dynamically finding functionality and configuring its access

d. Publish / Subscribe(Pub/Sub) - dynamically configuring which data is needed and shall be sent to the client

e. Segmentation of UDP messages - allowing the transport of large SOME/IP messages over UDP without the need of fragmentation

• SOME/IP can be implemented on different operating systems(AUTOSAR, GENIVI and OSEK) and even embedded devices without operating system;
• SOME/IP is used for inter-ECU Client / Server serialization

3. SOME/IP Protocol Stack based on OSI Model

4. Services of SOME/IP

Therea are 4 most common patterns:

• Request / Response

Request - a message from client to server calling a method

Response - a message from server to client transporting the results of the method invocation

 

• Fire and Forget

Request - a message from client to server calling a method

Fire and Forget - a method invocation with just a Request message

Message Type "REQUEST_NO_RETURN"

Does NOT support answers and errors

 

• Events

Event - a Fire & Forget callback, that is sent out by the Server(e.g. cyclically or on change)

Sent from Server to Client

 

• Field

Field - represents a remote accessible property that includes Getter / Setter and /or Notification

Getter - Method to read field value

Setter - Method to write field value. Notification(Sends out Events with new values on change of field value)

 

5. Data Package of SOME/IP

Data package includes Header and data.

SOME/IP Header format:

                                                      SOME/IP Header Format

• Message ID distinguishes different services and service interfaces. It consists of Service ID and Method ID, the most significant bit(MSB) of Method ID judges comminucation method.

If MSB is set to 0, Client --> Server; if MSB is set to 1,  Server --> Client or Notifier.

• Length represents the length from Request ID to Payload
• Request ID is used to respond to a specific data request and send. Client ID is an unique identifier for each ECUs. Session ID is an unique identifier. In case of Session handling is active, the Session ID shall be incremented for each invocation, incremental value is 1.
• Protocol version represents current version information of SOME/IP, default value 0x01.
• Interface version represents version information of service interface.
• Message Type represents the detailed message types

                                                                                 Message Types

• Return code represents error handling of RPC communication. Regarding the detailed information, please refer to [PRS_SOMEIP_00191].

Data

Data Field represent the specific contents.

For UDP protocol: SOME/IP Header +payload ≤1416 Byte

For TCP protocol: SOME/IP Header +payload≤4095 Byte

 

6. Communication Concept

• Request / Response Method

Request message from Client

Response message from Server

Exception error message from Server

 

• Fire & Forget Method

Fire & Forget Communication

 

• Notification / Event

Notification - Publish / Subscribe FlowChart

 

7. SOME/IP Serialization

SomeIP的数据在通信的过程中都会放在对应的数据payload中，但是在数据协议中对于结构体、数据、联合体等不同类型的数据在SomeIP传输中必须按照一定的规则定义成相应的二进制数据流，这个就是SomeIP的序列化操作，在数据的接收端按照相应的规则将二进制的数据流按照同样的规则解析成与发送端一样的实际的数据类型，比如结构体、数组等这个过程就是反序列化操作。

序列化与反序列化的应用主要在AutoSAR中满足整个软件架构的定义。数据在AutoSAR的定义一般都是用PDU的形式存在的定义了一组大小可以配置的数据。典型的应用就是CAN通信，一般一个PDU代表了一帧报文，一般8个字节或者CANFD中64个字节。同样在以太网通信中数据从PDUR到COM层也是基于PDU来传输的。在COM层的数据也是以单个的信号进行数据传输的，因此在序列化过程中要在数据到COM层之前将SomeIP传输的复杂的数据类型通过序列化的操作解析成单个的数据信号，并按照定义的位置和大小映射到具体的PDU中特定的位置，此时在PDU上就是一个个的紧密排列的信号，而在COM层中直接对具体的信号操作便会在PDU中更新特定位置特定长度的信号。而接收的时候，PDU中的信号会在COM层更新到特定位置特定长度的对应的信号，然后在RTE层根据数据的反序列化操作经SomeIP传递的数据进行整合，在APP层实现对一个结构体、数据或者单独一个信号的操作，从而完成数据的传输。在AutoSAR中的传输示意图如下所示

8. SOME/IP-SD Header Format

SOME/IP-SD is a kind of special SOME/IP Service.

Flags

Entry Format

There are two format types (Services vs. Eventgroups):

    1. Both have a Service ID, Instance ID (0xffff = all), and TTL.

    TTL: Describes the lifetime of the entry in seconds(以秒为单位来描述entry的生命周期)

    2. Services need major and minor version.
    3. Eventgroup need Eventgroup Ids.

Options - Endpoint options

• L4-Proto:

Based on IETF/IANA Protocol-Numbers

0x06: TCP / 0x11: UDP

• Options provide a higher level of detail for the entries:

      1. IP Address

      2. Transport Protocol

     3. Port No.