11th China Automotive Forum was Held in Shanghai
The 11th China Automotive Forum, hosted by the China Association of Automobile Manufacturers (CAAM), was held in Jiading, Shanghai from June 17 to 19, 2021. During the theme forum “Creating the New Ecology of Software Defined Vehicles” held on the morning of June 19, Cao Bin, the general manager of Neusoft Reach Automotive Technology (Shanghai) Co., Ltd., delivered a keynote speech entitled “Software Empowers Vehicle Enterprises to Accelerate the Development of SDV”. The following is the transcript of the on-site speech:
Distinguished leaders and guests, good morning. President Zhao just said that no one wants to attend forums nowadays. However, software-defined vehicles (SDV) started to heat up two years ago, and it is even more appropriate to participate in forums at this time. Whether we are practitioners, new joiners, or colleagues from overseas entrepreneurial companies, we are constantly thinking and exploring every day while engaged in technical development and contributions during the era of transformation. This experience may take one, two, or three years, and the system gradually forms and becomes relatively complete. With a clearer track and framework, we can work more easily and conduct more activities without too much trial and error. Moreover, we can move more steadily towards the determined direction.
At this stage, we are still talking about SDV or the development of new architecture, new platforms, and new systems around this time last year. There are many ideas and path explorations, but ultimately, it may be the direction that nobody has thought of or has not yet seen clearly, which can truly go on. The other branches or mainlines may be cut off one day. From an economic perspective, this is a silent cost, because you explore far, and the branches will wither, but it will bring a lot of contributions and reflections to the whole industry, summarize experience and lessons. Experience and lessons exist at the same time in this process. It is precisely because of these lessons that experience can be refined, developed, and retrieved.
We are also thinking about software. I have been engaged in automotive software work since 1995. Neusoft Group started to do automotive software in 1991. Looking back at this process over the past thirty years is like reviewing a long history. Each stage has different considerations, methods, difficulties, and pain points. What is the difference between software-defined vehicles today and what we did in software ten years ago, twenty years ago, or even thirty years ago?Why is it called “software-defined car” now? Car companies, parts suppliers, software companies, and IT companies are all saying that we are doing a “software-defined car”. Are we really doing a “software-defined car” or just pretending? Sometimes it may not be true, so we need to reflect on the key points, or this is my summary and thinking, which can be discussed today.
We believe that the most critical point is the large amount of software development work that has been done in the past. In fact, many of them are repetitive and solving engineering problems. Many software are in the firmware, in many controllers inside the car, and they are developed in order to meet the functions of the car. These parts are integrated together, everyone adjusts and fixes bugs, diagnoses, and calibrates. All the problems are the engineering coupling problems that have to be solved in order to sell the car. The engineering coupling problems are largely repetitive, and many of the development work cannot be reflected in the consumer’s usage experience, which does not bring more sales value or more willingness to pay for consumers.
To put it another way, many companies say they are doing a software-defined car, especially car companies, where is the most critical point? How much code is self-developed? Does the code contribute value to consumers? Or just implement underlying functions, can it be continuous iterated and improved even after the development of different models, and continue to create new value to provide value to consumers? Both of these are the extremely important core attributes.
To be honest, most of our friends and practitioners in the industry can really control only a small part of the software in the host factory. We say a car has billions of lines of code, but car companies really control less than 5%-10%, maybe even lower. Most of these codes may have to be reconstructed in the next car, and there will be engineering repetition inside. I think that whether it is SDV or software-defined cars, it can really develop and enter the track with three characteristics:
-
Universal hardware. Why do car companies need to reconstruct when we do software most of the time? Because the supplier may change, the processor and peripheral devices used by the supplier may also change, and the internal interface may also change. As a result, the window controller software developed on the previous hardware cannot run on the new hardware and needs to be reconstructed. Therefore, when we see a large number of customized software with a lot of strong differences in hardware, it is very difficult to reconstruct the upper-level applications in different car companies.
-
The software layering framework on top of the universal hardware gradually becomes clear. Until now, we have discussed many SOA, technical software, application frameworks, and atomic services. The layered software framework is the basis for our upper-layer applications to continue to iterate and develop. Most of our work is adaptation.
-
When car companies develop software, we often think about when we have 500, 1000, or 5000 people, which part of the software to do. At this time, there are still many ideas and space for changes, and different car companies have different choices.We believe that hardware has a significant impact on software-defined cars, as chip technology changes very quickly. Currently, there are many considerations and plans for domain controllers. Generally speaking, there are autonomous driving domain controllers, general domain controllers, and cockpit domain controllers. Currently, there is not much disagreement in the industry among these three categories.
The cockpit domain controller is particularly unique because it involves human-machine interaction, with many unique hardware components that are fun and interesting. Therefore, there will be significant trends and opportunities for hardware change. However, for autonomous driving and general domain controllers, the chips and processors have become relatively stable, which will determine whether software and upper-layer applications can sustainably and stably develop during the next generation of iterated development of the entire vehicle architecture.
Here are two examples. The TDA4 does not emphasize computing power, with neural network computing power of only 8 TOPS, but its functionality is very complete. For example, it not only has neural networks but also includes DSP, ISP, and GPU, making it equipped with a basic hardware framework for forward functions and parking, and each part can reach L2 level. When we see such a chip appearing, it has universal computing power, real-time and non-real-time parts, and many peripheral interfaces and dedicated chips. This means that in the future, when developing software, it is not necessary to consider how to combine and apply the applications in the forward control unit and the parking control unit and how to switch sensors because these aspects can be hidden by either software or hardware. We can confidently develop upper-layer applications, which is an important starting point.
The S32G is another general-purpose pre-control chip that does not have strong computing power, but it makes the vehicle’s control more like a computer, just like in the PC field we are familiar with. It has real-time and non-real-time parts, MCU, CPU or SOC, supports DDR memory, high-speed storage, and excellent network support, making it a convenient general-purpose computing platform. It can extend the real-time and control parts to the lower layer, where software encapsulation and clear and stable architecture can be provided, making it easier to iterate the application software without concerning hardware when the software is developed in the next step. The appearance of these two chips has a very strong reference role in the entire industry, prompting everyone to think.
There are many other chip suppliers listed below who have also done a lot of exploration in this area. I believe that similar chips will continue to emerge, but it is possible that the internal system architecture and function division and framework targeted for these two domains on future chips may have entered a relatively clear and stable state. This is a critical and iconic stage for us to develop software-defined cars.For these two controllers, we can gradually move towards an autonomous driving controller as well as a general domain controller. The distinctive feature of the autonomous driving domain controller should be the ability to integrate forward function, lane-keeping function, parking function, and memory parking into one box or chip. This may be a very critical starting point. Currently, we see many implementation solutions that either have multiple boxes or looks like one box, but when opened, it may contain several chips for acceleration, processing or stacked chips for better computing power. In this scenario, it is difficult to ensure software stability. What if we implement certain pruning on the functionality and performance so as to maintain the stability of the hardware and software architecture? I believe this will have a very significant meaning and make it easier for industry division of labor once all software operates here.
The existence of a general domain controller is also very significant. As Mr. Zhang Jie mentioned earlier, there are many controllers that need to be migrated, and the general domain controller is the place to migrate them. In the future, many new software may be developed on this kind of general platform instead of in the MCU below. A lot of software and functionality can be migrated here in the general pre-controller.
Will the MCU disappear in the future? The CP is still widely used in many fields, and even in many component applications, the CP is also very widely used. However, the CP will become more and more codeless, and software will be easier to configure and will not be modified very often. It will only solve basic functional configuration and has certain configuration capabilities. OEMs consider these issues as a functional key that can be configured, but we do not need to be concerned about its code, and we do not need to rewrite or master it. This makes the entire system easier, and the change and application parts are transferred to the general domain controller.
For the bottom-level software, both of these domains are typical features. Whether it is the autonomous driving domain or the general domain, both involve real-time control, complex calculations, and functional safety.
How has the upper-level software architecture developed, whether it is SOA or general framework? There is still a considerable period of adaptation. A basic software should have a clearer framework, an intermediate layer should form middleware or software platforms, or an SOA platform.
Above this is the application. Can the application be continuously and simply iterated? There needs to be an adaptation layer, which will not disappear in the short term or may exist as an engineering service for a long time. The automaker is responsible for developing the top-level applications, and we provide software technology or software middleware. At the same time, when providing code and software, we should also provide engineering services to help the automaker adapt the upper-level applications well. This is also very important. In the development of this stage, adaptation and engineering services are also essential.If we consider the emergence of the new chips mentioned earlier, and the trend towards clear and stable software architecture with AUTOSAR, AP+CP, and middleware, this marks the true beginning of the acceleration towards software-defined cars. The application software of car manufacturers will rapidly thrive, as it is the visible and competitive part that consumers can feel and experience.
Chip development is on a deterministic track, with greater clarity and definition of chip capabilities and attributes. To develop chips that support industry growth, we must meet the requirements of these functions and frameworks. In this context, we believe that the “Moore’s Law” effect may occur in the automotive industry, where computing power, processing capacity, and bandwidth will accelerate the rapid development of applications and promote the burgeoning development of intelligence and the entire automotive business ecosystem.
Our view is that, as a participant in the framework, Neusoft Reach is also a friendly provider of key components of the ecosystem. We are willing to do the dirty work and help fill gaps in car manufacturers’ needs, playing a role as a dedicated service provider.
We have observed that many foreign software monopolies have dominated technical software for many years, requiring long-term reliability verification. Now, at this stage, frameworks and middleware need to develop and change rapidly. Basic software should be positioned directly in automakers’ development process, responding to their application needs. Even AUTOSAR is subject to change every year, and the standard components developed by AUTOSAR may need modification within the application framework. In these cases, Neusoft Reach can provide mature, standard AUTOSAR components, and build unique modifications and corrections for application and upper-level frameworks. We believe we can stand with car manufacturers and help them develop their own software capabilities by providing them with components and technical support.
Meanwhile, we are launching the next-generation software platform, NeuSAR, which has many application cases, experiences, and lessons in traditional body controllers, new energy controllers, and more. In this process, we have accumulated and improved continually. Therefore, we hope to collaborate with host factories and Tier1 suppliers on the development of basic software components, while providing abundant toolchain products.
This is our middleware. We transform the zero-base necessary parts into core components for host factories and parts suppliers to build their own systems. Meanwhile, we have many industry partners with whom we refine common aspects and integrate them to form standardized and common components, including the development of SOA frameworks.The software ecosystem is something we are more willing to build. Where will these software be placed? A car manufacturer may have 300 million lines of code for different vehicle models. There may be millions of lines of code that are self-developed, and many other parts are provided by other suppliers, its circle
of friends, trusted friends who contribute code. These codes should be in a software repository, and a series of software tools are needed to support how to maintain and manage them, so that each component can iterate and develop in different vehicle models, and become configurable.
In conclusion, the software architecture of AUTOSAR Adaptive + AUTOSAR Classic + Middleware is becoming clearer. The basic software needs to be oriented towards SOA, iteratively upgraded based on existing foundation, and adapted to the future development trend of SDV. Dongfeng SoftRide builds a collection of basic software for the new architecture, fully ensuring the adaptability of applications and hardware, helping car manufacturers increase software reuse, accelerate hardware iteration speed, and empower car manufacturers to accelerate their development towards SDV. Thank you!
This article is a translation by ChatGPT of a Chinese report from 42HOW. If you have any questions about it, please email bd@42how.com.