2022 China Automobile Forum | Liu Wei: Autonomous driving domain controller based on open SOA architecture

From November 8th to 10th, 2022, the 12th China Automobile Forum hosted by the China Association of Automobile Manufacturers was held in Jiading, Shanghai. As the first grand gathering of the automobile industry after the 20th National Congress of the Communist Party of China, this forum has the theme of "Gathering Strength to Stabilize and Gather Momentum for a New Journey" and has a total of "1 closed-door summit + 1 conference forum + 16 themes" Forum", focusing on the high-quality development of the automotive industry, and working with industry elites to implement the new spirit, analyze the new situation, and discuss new measures. Among them, at the "Theme Forum 12: Cross-border Integration, Empowering the Implementation of Autonomous Driving" held on the afternoon of November 10, Liu Wei, deputy general manager of Neusoft Reach, delivered a wonderful speech via video.

The following content is a transcript of the live speech: 

Thank you to the China Association of Automobile Manufacturers for the invitation. I am honored to participate in the 2022 China Automotive Forum. I am Liu Wei from Neusoft Ruichi Automotive Technology Shanghai Co., Ltd. I am very happy to have the opportunity to share and communicate with my peers and experts.

The title of my speech today is "Autonomous Driving Domain Controller Based on Open SOA Architecture".

Before introducing the autonomous driving domain controller, let us first take a look at the development trends of the autonomous driving industry.

From the perspective of the E/E architecture of the entire vehicle, it is gradually developing towards domain control. In the past, we could see hundreds of ECUs on traditional cars to complete some car functions. Now it is gradually turning to three domain controls, evolving towards autonomous driving, smart cockpit, and chassis power. In the future, it will also evolve into integrated cabin and driving, and a central computing unit.

From the perspective of the evolution of software architecture, it has gradually evolved from the original monolithic architecture and distributed architecture to SOA and microservice architecture.

The monolithic architecture is a common architecture in traditional automobiles. It is customized according to different hardware forms. It has its own proprietary software architecture, which is more process-oriented and satisfies a single function. As the degree of centralization of automobiles gradually increases, the monolithic architecture can no longer meet the needs of multi-functional integrated development and flexible deployment. Therefore, it has transitioned to an object-oriented distributed architecture, also called a vertical architecture. In the future, with the development of central computing units, in order to flexibly and conveniently provide more new functional services after meeting the vehicle SOP, the software architecture will begin to evolve towards SOA architecture and microservice architecture.

So from the perspective of the demand for vehicle intelligence, sensors are gradually being upgraded. We can see that from the level of autonomous driving, including the L1 level of autonomous driving to the L5 level, with the different levels of autonomous driving, the sensor The number of configurations and configuration plans are also changing. After reaching the L4 and L5 levels, the number of sensors in the entire vehicle has evolved to as many as 30-40.

From the perspective of the technical requirements of autonomous driving, it is still changing, and we can see several important changes here. Judging from changes in sensors, driving and parking sensors were separated in the past. We see that in more and more high-level autonomous driving, the division of labor between driving and parking sensors has gradually become blurred. When driving, the parking sensors also play a role. Then the generalization of sensor functions has gradually become a future development trend.

In addition, from the perspective of development form, in the past, products that integrated software and hardware to provide overall solutions have gradually transitioned to development methods that separate software and hardware for large domain control and central computing. In the future, the separation of software and hardware will become the development trend of the entire future development. From the perspective of functional distribution, integration is moving towards centralized mode. The distributed functional units in the past have gradually been integrated into domain control and central computing.

Judging from the cooperation model between suppliers and OEMs, there is also a trend of continuous change and evolution. Especially from the black box and closed development in the past to the white box or gray box open development method. A product that was completed by one or two suppliers in the past has gradually become developed in a way that multiple function providers collaborate to provide different functions.

From the perspective of data, in the past, because some data were rarely uploaded, at most it was some trigger data, such as EDR data, which was stored in the cloud to provide some assistance for the use of functions. In fact, we can see that as the level of autonomous driving functions increases, more and more data-driven development methods gradually evolve into a new development method. This also highlights a new demand, which is the demand for information security and functional security, including data desensitization, and some new security requirements such as OTA have emerged.

In addition, we can see that as the functional level of the autonomous driving domain controller increases, its computing power is also gradually increasing. From a few TOPS in the past to dozens of TOPS, or even hundreds or thousands of TOPS now, more and more domain controllers need to provide such large computing power through multi-core heterogeneous methods to support these increasingly complex tasks. Come higher and higher functionality. Therefore, the difficulty of controller development has also risen sharply.

From the autonomous driving development model, we can see more and more changes beginning to occur. In the past, OEMs provided requirements, and suppliers completed the development of functions and products. Now we can see that more and more OEMs are building their own software capabilities to participate in the early design of the entire product. The multi-party joint development approach is becoming more and more popular. Change the face of the entire automotive ecosystem.

We can see that in the past, it was a typical flat development, and each functional hardware was developed independently. The signal-based architecture has been locked at the beginning of the design, but in fact we can see that today more and more new product forms are integrated with parking and parking, and cabin and driving are increasingly adopting three-dimensional development and hierarchical development. , horizontally open up the software architecture. At the same time, service-oriented for flexible expansion and deployment, single ECUs in the past are increasingly being replaced by integrated ECUs. From the underlying software to middleware to the functional applications above, the layered approach is becoming more and more sophisticated. obvious.

Especially when facing central computing, increasingly complex functions and applications are decoupled, and the development of multi-dimensional systems has become an obvious development trend in the future.

In the past two years, everyone has been talking about the software-defined car model. In fact, we can see that the demand in the automotive consumer market continues to promote the transformation of software-defined car SDV to provide consumers with more and better diversified intelligent experiences. The implementation of intelligent experience requires an open and continuously iterative SOA architecture. Such an architecture can not only implement the separation of software and hardware, but also provide an implementation basis for the new cooperative development model mentioned above.

A typical SOA architecture of a software-defined car can be seen from bottom to top, from hardware to adaptation factory to achieve separation of software and hardware to differentiate different hardware. There is a standardized AUTOSAR software on top, a common basic middleware on top to support the development of different functional domains, and functional domain middleware on top to shield some differentiated development of different functional applications. The top layer can support services and flexible iteration of the business layer, which includes autonomous driving, vehicle control, and cockpit applications. This is also a personalized and differentiated application development layer that is very important for OEMs to attract end users.

Here we also summarize some features of the open SOA architecture. Including SOA, here we mention different communications, shared designs, and components to achieve separation of software and hardware. There is a self-evolving architecture that meets functional safety and information security requirements. At the same time, it should be an integrated architecture that can realize device-cloud linkage, support cross-domain, including intra-domain and cross-domain integration, and be able to realize the publication and subscription of different services.

Judging from the trends and needs introduced earlier, the architecture of a good autonomous driving domain controller should be secure, separated from hardware and software, service-oriented, open, and developer-oriented, capable of self-evolution and realizing multi-functional sensors. Generalized.

Here is an introduction to the Neusoft Reichi autonomous driving SOA software architecture.

The entire architecture is divided into three levels: hardware layer, software platform layer, and service application layer.

We use NeuSAR to separate software and hardware, provide service APPs through the service application layer, and implement sensor services, autonomous driving services, video services, and scene services through configuration. The scene services are used for self-evolution, and some corner case model automatic driving data collection mechanisms are embedded to deal with the long-tail problem.