Preface
First of all, I would like to ask you a few small questions. Do you know:
- Do you know what SOME/IP is?
- Do you know why SOME/IP is generated and related background?
- Do you know the inextricable connections between SOME/IP and SOA?
- How should SOME/IP be used in practice?
Today, let’s explore and answer these questions together. In order to facilitate everyone's understanding, the following is the topic outline of this article:
mind Mapping
text
General introduction
As introduced in the previous article <Introduction to Automotive Ethernet Link>
The vehicle Ethernet protocol stack can be divided into five layers in total, namely the physical layer, data link layer, network layer, transport layer, and application layer . The content SOME/IP we will introduce today is an application layer protocol .
According to the description in AUTOSAR, the SOME/IP protocol content can be further divided into three types of sub-protocols:
- SOME/IP standard protocol at the application layer
- SOME/IP-SD protocol
- SOME/IP-TP protocol at TP layer ,
These three parts complement each other and fully explain the entire content of the SOME/IP protocol in detail. They are the only way to study the SOME/IP protocol.
Since the SOME/IP protocol has a lot of content and complex relationships, in order to let everyone have a step-by-step understanding of SOME/IP, due to space limitations, this article will mainly explain the SOME/IP standard protocol at the application layer. Other protocol contents will be continued in the next article. Share it with everyone and please pay more attention to it!
Background and motivation
In 2011, BMW developed and designed a set of middleware that can implement a service-oriented communication method. This middleware is different from the traditional signal-oriented communication method. It can not only greatly reduce the network load and improve the communication quality of both parties. efficiency, and the introduction of Ethernet communication can also greatly meet the growing communication needs of future vehicles.
Signal-oriented data transmission will always be sent in a loop regardless of whether the network needs it or not, while service-oriented communication method is different. The sender will only send data when at least one receiver in the network needs the data. This is a kind of oriented Significant advantages of the service communication method.
BMW calls this service-oriented communication method SOME/IP (full name: Scalable service-Oriented Middleware over IP ). As its name suggests, this protocol is closely related to Ethernet, yes! SOME/IP is middleware running on the basis of the automotive Ethernet protocol stack, or it can also be called application layer software.
SOME/IP is gradually being accepted by AUTOSAR due to its popularity and is planned to be incorporated into its official standard. It will be integrated into AUTOSAR 4.X in 2014. Several key development nodes are as follows:
- AUTOSAR 4.0 - Completed preliminary integration of BMW SOME/IP messages;
- AUTOSAR 4.1 - supports SOME/IP-SD and its publish/subscribe functions;
- AUTOSAR 4.2 - Add transformer for serialization and other related optimizations;
- AUTOSAR 4.3 - Fix some transformer bugs and add SOME/IP-TP protocol and other SOME/IP-SD optimization work for a large number of UDP packets;
- Continuous optimization. . . . . .
1. What is SOME/IP
As the full name of SOME/IP was mentioned in the previous section, let’s use its full name to understand what SOME/IP is:
- One of the original intentions of the Scalable
protocol is to achieve scalability and interoperability between heterogeneous devices with different hardware platforms, different operating systems or embedded firmware, and different application software. - service-Oriented
indicates that it is a basic service-oriented protocol. So data is exchanged in a client-server configuration only when the client requests or the server notifies a specific subscriber, this ensures that bandwidth is never wasted and data is communicated/exchanged only when and where it is needed. - MiddlewareE
is also a kind of middleware. That is, it is located at the application layer and has its own general protocol layer to handle more specific operations and applications; - over IP
is also an Ethernet-based protocol. It uses a similar hardware interface to ensure bandwidth up to 100Mbps. At the same time, data is communicated through the middleware (i.e., application layer) through network cables using TCP/IP or UDP protocols.
When a client requires data from a server, it can be requested by the client using the TCP protocol. If the server must deliver data to all active subscribers, it can be delivered via the UDP protocol. Data communication over the UDP protocol can be unicast, multicast, or broadcast.
As shown in Figure 1 below, it clearly shows the position of SOME/IP in the automotive Ethernet protocol stack and its relationship with other modules:
Figure 1 Relationship between SOME/IP and automotive Ethernet protocol stack
So what is the position of the SOME/IP protocol in the AUTOSAR protocol stack? As shown below:
As can be seen from the figure above,
The SOME/IP protocol involves interaction with AUTOSAR standard modules such as RTE, COM, PDUR and SOAd.
SOME/IP-SD used for service discovery involves BswM,
SD involves the interaction of SoAd modules .
The interactive relationship between the SOME/IP protocol and each module will be discussed in subsequent articles. Mentioning this will give everyone an overall idea of the relationship between the SOME/IP protocol and the AUTOSAR protocol stack. This article will not go into too much detail.
SOME/IP was originally developed as an alternative RPC mechanism to ensure compatibility with AUTOSAR devices and provide maximum functionality required for automotive use cases, and it is also a network layer designed for inter-ECU client-server serialization agreement .
Currently, the protocol can be implemented on a number of different operating systems, including AUTOSAR, OSEK and GENIVI . It can also be implemented on embedded firmware that does not run an operating system.
Large devices such as cameras, headsets, telematics devices, AUTOSAR devices, and even infotainment systems can use the SOME/IP protocol to efficiently exchange inter-ECU messages.
SOME/IP support has been public since the release of Wireshark 3.2 SOME/IP, and SOME/IP data can be parsed on Wireshark.
In summary, we can summarize the basic characteristics of SOME/IP as a service-oriented communication protocol and an application layer protocol based on the automotive Ethernet protocol stack.
Table 1 below shows the five basic characteristics of the SOME/IP protocol:
Table 1 Five basic characteristics of SOME/IP protocol
The relationship between SOME/IP and SOA
SOA
In short, SOA is a service-oriented architecture ( Service-Oriented Architecture ). It is of course also an important way of software design. It was proposed by Gartner, an IT research and consulting company, in 1996. It is not a new concept in itself, and It has been popular in the IT Internet field for more than 20 years.
According to W3C's definition:
"SOA is an application architecture in which all functions are defined as independent services with well- defined callable interfaces that can be called in a defined sequence to form business processes.
Serve:
A service is a collection of information with a larger granularity than a component. It actually contains a logical combination that implements multiple associated business requirements, and allows each service to use a specific platform, architecture or technical solution;
Callable interface:
The service-oriented interface is different from the component interface. Its implementation has nothing to do with a specific language or a specific platform. It can very conveniently realize the interaction of different heterogeneous platforms;
Contact and difference:
- First of all, it needs to be clear that SOME/IP is not SOA, and SOA is not SOME/IP;
- Since SOME/IP itself is also a service-oriented protocol, it is generally believed that SOME/IP is just a feasible protocol choice for implementing SOA;
- Generally speaking, both message-based communication and RPC (Remote Procedure Call) communication can implement SOA, and SOME/IP is a protocol based on the RPC framework;
- SOME/IP can be used to implement SOA, but the implementation of SOA does not necessarily require SOME/IP;
2. SOME/IP protocol analysis
Next, let Xiao T lead everyone to uncover the mystery of SOME/IP by analyzing SOME/IP! , in order to lay a solid foundation for subsequent learning of automotive Ethernet.
2.1 Related identifiers and version notes
Figure 2 below shows the Header structure of the SOME/IP protocol:
Figure 2 SOME/IP protocol Header
The detailed explanation of the Message ID, Request ID, Protocol Version and Interface Version marked in the figure above is shown in Table 2 below:
Table 2 Related identifiers and version descriptions
Length
As shown in Figure 2 above, Length covers the range from the beginning of the Request ID to the end of the SOME/IP message.
Message Type
Used to identify different message types. The currently existing types are shown in Figure 3 below, where TP represents a packetized message, which is defined as follows according to the AUTOSAR standard ( R21-11) :
Figure 3 Message Type table
Return Code
Return Code is used to indicate whether the Message has been successfully processed, or to provide feedback on the error content in the request. Figure 4 below shows the Return Code type defined in AUTOSAR ( R21-11 ):
Figure 4 Return Code definition table
3. SOME/IP communication mechanism
After understanding the detailed definition of the SOME/IP protocol standard, it is next necessary to discuss what rules the vehicle ECU needs to follow to realize data transmission. Therefore, familiarity with this part will be crucial to the development and testing of the vehicle Ethernet SOME/IP. It's important.
3.1 Service Discovery
The communication mechanism of service discovery is implemented through the SOME/IP-SD protocol. It is mainly used to inform the client of the availability and access method of the current service instance in the vehicle Ethernet. This can be achieved through Find Service and Offer Service.
Before transmitting data through the SOME/IP protocol, we need to know what services currently exist in the entire vehicle network, what is the availability of the services, and if the client subscribes to the services provided by the server.
Since the SOME/IP-SD protocol is also a very important piece of content, we will not go into too much detail here. We will only briefly introduce its basic functions and mechanisms. The specific content of the SOME/IP-SD protocol will be introduced separately in the future, so stay tuned!
Figure 5 below shows the basic functions of SOME/IP-SD, showing the interactive relationship between Client and Server.
Figure 5 SOME/IP-SD Client and Server interaction diagram
As can be seen from the above figure, the SOME/IP service discovery process can be divided into the following three basic steps:
- The Client sends a Find Service message to find available service instances in the vehicle network;
- After receiving the Client's Find Server, the Server sends an Offer Service response through UDP ;
- Client subscribes to related events by sending Subcribe Event Group;
- The server checks whether the client meets the subscription conditions, and replies with ACK if satisfied; if not, replies with NACK;
- After the Client successfully subscribes to the relevant event, the Server will publish to the Client who has subscribed to the event according to the attributes of the event itself;
Remote Process Call (RPC)
Remote process calls can be mainly divided into four communication modes:
- The Request/Response communication mode can be summarized as one of the Methods
; its basic communication model is shown in Figure 6 below: As the most common communication method, the Request-Response model’s main task is to send request information to the client, and the server Receive the request, perform relevant processing and then respond accordingly.
Figure 6 Request-Response communication model
- Fire&Forget communication mode can be summarized as one of the Methods
; the main task of this communication model is to send requests from the client to the server, and the server does not need to make any response, which is somewhat similar to suppressing positive responses in the diagnostic service.
Figure 7 Fire&amp;Forget communication model
- Notification Event communication mode;
- This communication model mainly describes the content of publish/subscribe messages. The main task is to enable the client to subscribe to the relevant event group from the server. When the event group on the server occurs or the value changes, it needs to subscribe to the client who has subscribed to the event group. Publish updated content.
Figure 8 Notification event communication model
- The remote process control (Field)
access process communication mechanism is mainly to obtain and change data for the application. The main task is to enable the client to obtain the value of the Server through Getter and to set the value of Server through Setter.
Field can be understood as the basic attribute of a Service, which can include three methods: Getter, Setter, and Notifier. Among them, Getter is a method of reading a certain value in Field, Setter is a method of changing Field value, and Notifier is a trigger event when the value in Field changes.
Figure 9 Field’s communication model
As can be seen from the above figure, we use the Request/Response mechanism in the Getter and Setter method.
There is an empty Payload in the Getter request message, and the Payload in the response message is the value that needs to be obtained;
When using a Setter request, the Payload in the request message is the value to be set. If the setting is successful, the Payload in the response message is the value to be set successfully.
At the same time, we can also conclude that service entity is a very important concept in the SOME/IP protocol. A service entity can be any combination of Fields, Events, and Methods .
4.SOME/IP error handling mechanism
There are always various errors in any communication process, and SOME/IP, as a service-oriented application protocol, is no exception. Therefore, in order to more efficiently locate problems in the communication process, AUTOSAR has formulated A set of error handling mechanisms for checking the content of the SOME/IP protocol format.
For example, version information check, service ID, etc., other fault information can be defined in detail in the Payload.
Currently SOME/IP supports the following two error handling mechanisms. These two uowu handling mechanisms can be selected according to configuration.
- Message type 0x80, Response information, that is, the problem can be located through the Return Code in the Response Message;
- Message type 0x81, explicit error message;
Figure 10 below shows the basic flow of SOME/IP handling general errors:
Figure 10 SOME/IP error handling process
If you want to further learn how to implement the content of the SOME/IP protocol stack, you can refer to the open source code on GitHub led by BMW. Search for the " vsomeip " keyword in GitHub to find the corresponding open source code to learn .
It is worth noting that vsomeip is a SOME/IP protocol stack developed in C++ language based on the Linux platform.
Thank you for reading this far, there is also SOME/IP (Part 2), it is exciting and worth looking forward to, so stay tuned!
For more exciting content, please pay attention to the public account "My Views on ADAS and ECU"!