“The previous article introduced the scope of smart car software, software and hardware upgrades, and the connotation of SOA. This article will focus on the implementation details of SOA.

“

The previous article introduced the scope of smart car software, software and hardware upgrades, and the connotation of SOA. This article will focus on the implementation details of SOA.

Focus on the following issues: SOA basic software framework, SOA reference implementation, SOA implementation related technologies

1. SOA basic software framework

In the previous article, I introduced the service-oriented software architecture design SOA, but it is only an architecture design idea, not a software module in itself. The project needs a basic software framework to realize its architectural design ideas. The SOA Framework in the figure below is what I call the basic software framework.

The above figure shows a typical central computing Electronic and electrical architecture. The functions of dozens of ECUs are concentrated on a few computing units. Most of the ECUs have disappeared. However, due to the particularity of the chassis domain, some of the ECUs are still retained. Features. For several major controllers, high-performance SOCs are selected (three are just for illustration), and different operating systems are selected due to different tasks. SOA Framework is the key to the operation of this distributed software and hardware system. It has the following characteristics: it is an operating system middleware that runs on different OS kernels and can be cross-platform. In addition to being based on Ethernet, it is best to be compatible with traditional AutoSAR and provide a good development interface for upper-layer applications. Requires distributed collaboration with SOA Framework on multiple SOCs.

SOA Framework architecture. png

The overall structure of the SOA Framework is shown in the figure above, and its main functions are as follows: local services, remote services (services running on another SOC), and a unified interface description language IDL is the contract between them. IDL is a neutral language and has nothing to do with OS and development languages. Through the Service Development Framework, it provides developers with a basic framework for service development. The Service Manager manages local services and is responsible for synchronizing with the remote Service Manager. The Policy Manager is responsible for controlling the access rights between various services. Network Manager is responsible for network communication management and may use different communication protocols. Startup Manager defines the dependencies and startup sequence between services. Update Manager is responsible for service updates and upgrades. OS Abstraction Layer is responsible for abstracting the differences of each OS.

In the actual implementation process, many other services are needed as support, such as persistence, encryption and decryption, etc. The above architecture diagram is just to explain the principle for everyone. The services developed on this basic framework are loosely coupled with each other. Through the redefinition of new composite services and process services as we talked about in the previous article, new software functions can be generated. The differences between different chips will be shielded at the operating system level, and the basic software framework shields the differences in the operating system. Under this architecture, even if a new SOC is replaced, the software changes will be small, and the hardware can also be upgraded. Provides a software foundation.

2. SOA reference implementation

Both ROS and Adaptive AutoSAR are operating system middleware that follow the SOA architecture design philosophy. Why put them together is because they are all likely to develop into a distributed communication and computing framework suitable for vehicle environments.

The main goal of ROS (Robot Operating System) is to provide code reuse support for robot research and development. It is a distributed process (ie, “node”) framework, these processes are encapsulated in packages and function packages that are easy to share and release.

ROS was used more for academic research before. With the development of artificial intelligence and autonomous driving in recent years, ROS can be seen in many autonomous driving prototype systems. Baidu Apollo also initially used ROS. In the development process, the defects of the original ROS architecture design have slowly been exposed. In order to solve these problems, in 2017, the new architecture of ROS2 came out.

The biggest change in ROS2 is the cancellation of the Master central node to realize distributed discovery of nodes, publish/subscribe, and request/response communication; the bottom layer is based on the DDS communication mechanism and supports multiple operating systems, including Linux, windows, Mac, and RTOS. There is still a lot of work to be done to make ROS2 completely suitable for vehicles. The APEX mentioned earlier. AI companies are doing this.

Classic AutoSAR is the main standard for the development of ECUs. There are many related introductions on the Internet, so I will not introduce more. Adaptive AutoSAR only released the first release draft in 2017. It is mainly used for high-performance SOC and runs on a POSIX-compatible operating system. It also uses SOA architecture design ideas.

adaptive autosar. png

From Adaptive AutoSAR and ROS, we can see the sharp difference between the German and American architecture design ideas. My first feeling is that the American architecture design is more concise and flexible, and it pursues open source. The Germans like to complicate simple problems, over-design, engage in deep levels of abstraction, code generation, and strongly bind IDEs. This may have something to do with the rigor of their engineers’ thinking. The threshold is particularly high. Related companies can also sell standards and tools, and make a lot of money.

In traditional ECU development, Classic AutoSAR will still dominate. German-based companies are undoubtedly the dominant player. However, I personally do not like the development of Adaptive AutoSAR. The main points are as follows: The advancement of its standards has actually fallen behind Industry applications. In the development of autonomous driving, China and the United States are dominant, and Germany has been unable to achieve its hegemony in the field of traditional automobiles. Open source software has contributed to the prosperity of industries related to artificial intelligence and autonomous driving. The practice of German software vendors who set high thresholds and earn money through standards is difficult to continue. A set of basic software charges more than 10 million yuan. Choose open source, and those who have the strength will develop it by themselves. Everyone can learn from its design ideas at best.

3. DDS and SOME/IP

DDS (Data Distribution Service) and SOME/IP (Scalable service-Oriented MiddlewarE over IP) are both an application layer communication protocol based on TCP/IP, which mainly implements the following functions: data serialization service discovery data publishing and subscription mechanism

DDS is mainly used in industrial Internet, military industry and other fields. There are also some applications in the automotive field, such as Nvidia’s Drive AV platform. The underlying communication is based on DDS, which is also the underlying communication protocol of ROS2. SOME/IP is developed along with AutoSAR, and has been included in the AutoSAR standard. It is the underlying communication protocol of Adaptive AutoSAR. The functions of DDS and SOME/IP are similar. SOME/IP and AutoSAR are ecologically compatible, but DDS has more powerful functions. For example, it can realize QoS (Quality of Service). It is a security mechanism of the network and is used to solve the problem. Delays and blocking issues).

In the CAN bus, the communication process is signal-oriented, and the sender publishes information periodically, regardless of whether the receiver has a demand. DDS is different from SOME/IP. Both the sender and receiver are a subscription/publishing mechanism. It is sent when the receiver needs it. The advantage is that unnecessary data will not appear on the bus, thereby reducing the load.

The realization of DDS and SOME/IP is based on Ethernet. Why use automotive Ethernet? In addition to the transmission bandwidth problem that everyone knows, in fact, from a software perspective, the biggest advantage of Ethernet lies in its network. The model level is more complete than CAN, and more complex application layer protocols can be defined on this basis.

Concluding remarks

This article mainly introduces the SOA software framework, and discusses common technical concepts such as automotive Ethernet, SOME/IP, DDS, Adaptive AutoSAR, ROS2, etc., sorts out their respective technical levels and problems to be solved, and explains their relationship with SOA. The next article will mainly talk about some non-technical issues, such as the status quo of the industry and the difficulties that will actually be encountered in the implementation.

Link to this article：How does the software define the automotive 3-SOA basic software framework and reference implementation?