What is the essence of the so-called subversive revolution of new cars? How should software-defined cars be understood? Is the automotive software ecosystem a forest or a prairie? How hard is it to upgrade OTAs and the like across time and multiple models? How do you build a software architecture that can detach from a specific vehicle model? And how to achieve the further "hardware pluggable"?
"Zhao Fuquan Research Institute" No. 69, continue to explore the "automotive technology ecological innovation", Zhao Fuquan talked with Cao Bin, general manager of Neusoft Ruichi Automotive Technology (Shanghai) Co., Ltd., to deeply analyze the underlying logic of "software-defined automobile" and "software ecology".
Summary of views
Hardware standardization:
Nowadays, the degree of homogenization of hardware is getting higher and higher, especially in electric vehicles, including a series of key components such as batteries and motors. As a result, it is becoming increasingly difficult for car companies to build product differentiation through hardware.
Hardware-software decoupling:
The future trend is to decouple hardware from software, and software no longer needs to be developed for specific hardware, but can flexibly call standardized hardware. Synchronize the development of software and hardware and the development of the whole vehicle. In this way, when the hardware is iteratively upgraded, the car company can directly switch to the new hardware.
Software First:
A new model for automotive product development. The current model development is a traditional model of one by one; and in the future, in the new mode of "software first", each car company will have its own set of exclusive software systems, which are cross-model, and software engineers can develop various functions of various models in a completely virtualized environment. You don't even need to know which model the software will be on.
Grassland Ecology vs Forest Ecology:
The mobile phone developer ecology is like a grassland, a barbaric growth of the ecological model, the participants work hard, do not affect each other. The car developer ecosystem is more like a forest, at least for now, more like the ecology of PC computers, but it will be more orderly and richer than the PC ecology. As for whether there will be individual developers in the future, it is difficult to judge now.
Users co-create into chicken ribs:
It may be a little disappointing to everyone, and the user's customized space is not arbitrary. All new combinations on the car must be verified so as not to pose a safety hazard. Car companies ensure the safety, reliability and quality of the software. This threshold is difficult for individuals and small teams of developers to cross. There's not a lot of room left for outside developers.
Big Fish Games:
The living space for small companies has become very small. That is, when mobile phone systems become smarter, open innovation space is compressed. This is the inevitable result of the development of smart products to a certain stage. The bigger development path of the automotive ecosystem is to launch high-complexity, high-reliability and high-quality human-computer interaction software by some heavyweight participants from the beginning.
Complexity of OTAs:
How to match all models with one software system? Which model is the baseline for implementing OTA upgrades to the software system? Is it only possible to upgrade on some models and not on others? To be honest, no vehicle company can clearly answer these questions, and if the car company wants to upgrade dozens of models in the future, its difficulty will increase exponentially.
OTAs require hardware standardization:
In order to reduce the complexity of OTA upgrades, as we mentioned earlier, enterprises must strive to achieve hardware standardization, otherwise when there are too many software versions that need to be maintained, car companies cannot cope with resources and energy, and the result is likely to be that a car will not be updated after only a few rounds of OTA.
Pluggable reality:
It can be replaced by plugging and unplugging, which will undoubtedly give the user an additional attraction. But doing so is also costly, and it may be more difficult to implement than using hardware such as chips from the latest models directly on new models. Future pluggable hardware upgrades must be strictly limited, i.e. several permissible replacements are identified in advance.
Eliminatable:
In the future, automotive products will increasingly have the attributes of fast-selling products. In other words, auto companies can expect users to choose to eliminate old cars and buy new cars because hardware such as chips cannot support the latest software systems.
The following is a transcript of the conversation:
Zhao Fuquan: Hello netizens of Phoenix Network! Welcome to the high-end dialogue column of The Zhao Fuquan Research Institute of Phoenix Automotive, I am the host of this column, Zhao Fuquan of the Institute of Automotive Industry and Technology Strategy of Tsinghua University. Today, we are very honored to invite Mr. Cao Bin, General Manager of Neusoft Ruichi Automotive Technology Co., Ltd.
Cao Bin: Hello everyone! I am Cao Bin of Neusoft Ruichi.
Zhao Fuquan: General Manager Cao, welcome to the high-end dialogue column of "Zhao Fuquan Research Institute". Today is the 69th dialogue since the launch of this column, and our theme is "Innovation in the Automotive Technology Ecosystem". Many netizens are more familiar with the vehicle company, but may have a limited understanding of the behind-the-scenes hero of the car- the supplier, especially at present, in addition to the traditional hardware supplier, the software supplier has also become an important part of the automobile industry, which is often less known. I know that Mr. Cao has participated in the development of a lot of automotive software, next, please first introduce to netizens, what kind of company is Neusoft Ruichi? What are the main businesses? What is the current size?
Cao Bin: It is a great honor to be invited to participate in today's dialogue. Neusoft Ruichi Automotive Technologies Co., Ltd. was founded in 2015 on the eve of the transformation of the automotive industry. We consider Neusoft Ruichi to be a company built for change. Neusoft Ruichi relies on Neusoft Group, and Neusoft Group's automotive electronics business has been doing for 30 years.
At that time, Neusoft's management team vaguely felt that the automotive industry was about to undergo major changes, and several of them should be determined: one was electrification, although it was still the early stage of the development of electric vehicles, in the "ten cities and thousands of vehicles" demonstration and promotion stage; second, intelligence, we believe that the Internet and software will play an increasingly important role in the automotive industry, and the software load of autonomous vehicles in the future will be very large. Based on these judgments, we combined the relevant technical directions and launched a startup company for the future transformation of the automotive industry in 2015, namely Neusoft Ruichi.
Neusoft Ruichi has developed a lot of interaction with partners in the automotive industry and has gained many opportunities for growth. At present, the company has more than 1300 employees. In 2021, we ushered in better development, completed the first financing of about 650 million yuan, and it should be said that we have initially entered the ranks of unicorn companies. As a start-up company, Neusoft Ruichi mainly provides basic software, common domain controllers, autonomous driving domain control and assisted driving technology, etc., including BMS battery management system and some products and services in the cloud.
Especially in terms of basic software and domain controllers, we are one of the first enterprises in the industry to exert and disseminate related concepts, put forward a series of pioneering concepts and carry out specific practices, in the "software-defined car", basic software and middleware and other hierarchical forms, domain controllers and other aspects of the integration of the industry, we are at the forefront of the industry, and have been recognized by ecological partners and consumers. The above is the business layout of Neusoft Ruichi.
Zhao Fuquan: After listening to Mr. Cao's introduction, we learned that the management of Neusoft Group made a strategic prediction on the evolution trend of the automobile industry as early as 2015, and believed that the future automobile industry will develop rapidly in the direction of electrification and intelligence, so neusoft Ruichi was established as a high-tech startup company. Looking back now, it was not simple to have such a judgment and make up your mind to invest in 2015. Today, Neusoft Ruichi has turned 6 years old. Facts have proved that you are on the right path and have great potential for development.
The deep integration of the two major industries of automotive and IT is an inevitable direction and a major opportunity
Zhao Fuquan: General Manager Cao, at present, everyone is discussing the development direction of the automobile industry, including the so-called new four modernizations, intelligent networked vehicles, and new automobile species. As the general manager of Neusoft Ruichi, you have witnessed the changes in all aspects of the automotive industry over the years, and you have also had in-depth exchanges with many corporate customers, so how do you think about the restructuring of the automotive industry in this round? What do you think this refactoring means for Neusoft?
Cao Bin: The automotive industry has been in a relatively stable state for many years. For example, the engine's EFI system was first invented by a German supplier, and in the more than 50 years from the early production to today, the technology has basically developed linearly, there is no fundamental revolution, and the automobile company has always relied on such technology to make a profit. But since 2017 or earlier, the situation has changed, and there are signs of technological convergence between the automotive industry and the IT industry, and there is more and more interaction between each other.
Recall that point in time, the mobile phone industry has just undergone profound changes, from communication devices to computing devices. In the mobile phone communication industry, the game between traditional mobile phone companies and IT companies, the final result is that IT companies win, google and other companies use IT technology to turn mobile phones into computing devices. So in 2017-2018, there was also a sense of crisis in the automotive industry: everyone is worried that the automotive industry will also be subverted by the IT industry like the mobile phone industry? The car was originally a mechanical device, will it become a computing device in the future? In the years since, it should be said that auto companies have been entangled in this, with a fluctuating mentality, sometimes feeling anxious, sometimes feeling slightly relieved.
At the same time, IT companies also realize that it is difficult to build a car from scratch, after all, building a car requires a lot of traditional technology in terms of machinery, power, etc., and it is very difficult to manufacture. At the same time, the threshold for developing automotive software is also very high, and loading software into the car is far less so easy to develop an APP and run it on a mobile phone. Even now, it's still not easy for pure software companies to develop software for cars.
That is to say, the automotive industry has its own particularities, and its high complexity, the number of related technologies, and the amount of knowledge involved are not comparable to mobile phones and other products. However, the IT industry is also very strong, and it has also accumulated a lot of expertise and technology, and this knowledge and technology is exactly what the future of automotive products need. What are the consequences of such two industries colliding together? This is a completely new subject with no historical experience to refer to. But one thing is certain, this round of automotive industry transformation must be the process of collision and integration of these two huge and different knowledge systems and business forms.
As for the future direction of this convergence, I personally believe that there may be a long way to go in terms of computing architecture, control system, software method, ecosystem, etc. In this process, a series of new product forms, business models, collaboration methods and ecological relationships will be generated before. As a result, everything that exists will change. This is undoubtedly a huge opportunity for a company like Neusoft Ruichi that understands both automobiles and IT. As mentioned earlier, we have been keenly aware of this new opportunity for a long time, and we are willing and able to invest resources to seize this opportunity. In fact, enterprises at the center of industrial change should have the courage to explore and try, and actively promote industrial innovation and development.
Zhao Fuquan: Just now Cao said that the traditional car is dominated by hardware, taking the automotive EFI system as an example, this electronic control based on mechanical hardware such as fuel injection system is fundamentally different from the software control for digital cars in the future, which has generated a new demand for technical capabilities and business models. Neusoft Sees a major opportunity in this round of automotive industry transformation and believes that it has the ability to seize this opportunity, because you feel that you know both IT and cars. Speaking of this, some netizens may have doubts, Neusoft Ruichi was born from a software company, why do you say that you understand cars? Can Mr. Cao elaborate?
Cao Bin: Neusoft Group was founded in 1991, and it has been 30 years since 2021, and Neusoft has been developing automotive software since its inception. I myself came to work at Neusoft in 1995, and my first job at Neusoft was to develop car central control navigation, and I remember that car navigation software was just emerging at that time. In fact, Neusoft is the first company to introduce many advanced concepts in automotive software development, especially in the construction of software development systems in the field of automotive electronics, including CMM (Capability Maturity Model), quality management, and ASPICE (Automotive Software Process Improvement and Capability Assessment), etc. Neusoft is at the forefront of China's automotive industry.
In this process, we have always existed as a Tier2 (second-tier supplier) of the vehicle company, helping some Tier1 (Tier 1 suppliers) at home and abroad to develop embedded software. It is precisely because of such a process that Neusoft now has a clear understanding of how the car should develop software, including what mode of development to use, how to ensure quality, what are the requirements of the vehicle company and Tier1 for the software, how the software development process matches the vehicle development process, what work needs to be completed at each stage, and the reliability and durability requirements of the relevant system. It should be said that Neusoft has accumulated rich experience in these aspects, which in itself is a threshold that it is difficult for IT companies to enter the automotive industry.
Zhao Fuquan: That is to say, Neusoft has been one of the main suppliers of the automotive industry since its inception, but previously mainly served Tier1 and was a supporter behind the first-tier supplier. Because the electronic systems on traditional cars, including navigation systems and other systems, use embedded software, that is, software integrated into the hardware. Neusoft has formed a deep accumulation of 30 years in terms of how software companies cooperate with vehicle companies, Tier1 suppliers, and how automotive software can effectively integrate with hardware.
Just now Mr. Cao talked about a very important point, facing the future development of the automobile industry, in recent years, everyone has increasingly felt that simple hardware-based automotive products are gradually losing competitiveness. While hardware is still very important as the foundation of the car, hardware alone is no longer enough. In the future, with the advancement of networking technology, digital technology and intelligent technology, the automotive industry and products will undergo unprecedented comprehensive upgrading and bring unprecedented major opportunities. How big is this opportunity? How can I catch it? These issues are still being explored. But there is no doubt that this opportunity will be largely reflected in the software.
The automobile industry has been developing for more than a hundred years, and a large number of scientific theories and basic technologies have been accumulated in hardware. For car manufacturers, in the future, automobile manufacturing, process and other technologies will still be an insurmountable core capability, and will provide important support for the future development of automotive products to automation and intelligence. However, at the same time, future automotive products also need new capabilities in software and other aspects, involving a large number of related scientific theories and basic technologies, which are also indispensable core capabilities.
Mr. Cao led the software technology team into the automotive industry, that is, to empower automotive companies on the basis of hardware. Of course, this software-to-hardware empowerment does not mean that simple software programming can redefine the car. It is worth affirming that Mr. Cao expressed his deep awe for the automotive industry, and he does not think that the development of some software can make fundamental changes in the car, nor does he think that it is possible to build a new connotation of the future car by it alone.
However, one thing is clear, in the future, if auto companies only rely on hardware to develop, the future will be very slim. Only on the basis of excellent hardware, the latest achievements of the new round of scientific and technological revolution, especially the networking, digitalization and intelligent technology, to achieve the deep integration of software and hardware two technologies, two systems and two major industries, can we create a real new car. This will provide huge development opportunities for IT companies such as Neusoft Ruichi.
The "software-defined car" is intended
Emphasis is placed on the increasing role of software
Zhao Fuquan: Because Cao knows cars very well, he has enough reverence for the auto industry. 26 years ago, you began to engage in automotive software development related work, and now you want to introduce digital technology and intelligent technology into the automotive industry, empower automotive companies with the mentality of a changemaker, and also provide important support for the innovation of automotive products.
This raises a problem: there is a lot of controversy surrounding the current reference to "software-defined cars." On the one hand, in the future, the hardware of automotive products is no longer enough, there will be more and more software, and play an increasing role, which is an indisputable fact. Therefore, some people think that in the future, it must be "software-defined cars", which has also become a more recognized understanding in the industry. But on the other hand, there are also people who believe that the role of software is to generate, collect and process data, which should actually be "data-defined cars"; others say that chips are the core of future cars, so it should be "chip design cars". In addition, many other auto people do not agree with the above statement, they believe that in fact, it has always been a "consumer-defined car", but the original main use of hardware to meet the needs of consumers, and now consumers pay more attention to experience and service, relying only on hardware is not enough, need software and hardware together to meet the needs of consumers. What do you think of this controversy? What do you think this means for industrial development?
Cao Bin: There are indeed some auto people who do not agree with the "software-defined car", they feel that the car is always a hardware entity, in the past, it was the engine, chassis and other hardware that determined the function and performance of the car. However, from the perspective of the IT industry, the term "software-defined cars" or SDVs is not offensive.
Speaking of which, the concept of "software-defined" first appeared in the IT field, and I have the impression that it is SDN, that is, software-defined networking. As networked systems developed, they became more and more complex. Because many functions are designed around hardware, it is difficult to respond quickly to customer needs. For example, the connection of the previous network system was achieved through hardware interface plugging, which was obviously not convenient enough to quickly meet the needs of network changes. Later, the IT industry gradually standardized the hardware, so that various interfaces can be defined by software, and then the rapid reconstruction of the network can be realized through software operation. In fact, after intelligent systems are complex to a certain extent, certain functions must be rebuilt through software to quickly meet customer needs. It can be seen that "software-defined" does not mean a comprehensive replacement of the hardware itself by software, but the functional implementation of the entire system will be mainly controlled by software.
The same is true in the car, the future software is still only a part of the big system of the car, just like the power, chassis, body and other hardware. Previously, to some extent, it was hardware that defined the car, and the drivability of a car was mainly determined by the chassis system. In the future, the so-called "software-defined car" refers to the change in the means of determining the main functions and performance of the car, for example, we can change the drivability of the car by adjusting the relevant software. In this sense, I think we must clarify the subject of "software-defined car", the subject here is not software, let alone software companies, but always car companies, that is, in the future, car companies mainly use software to define cars. That's probably not much of a debate.
I think "software-defined cars" actually represent two evolutionary directions. One direction is hardware, that is, how hardware will play a role in the car in the future. Previously, the overall pattern of the automotive industry was relatively stable, mainly dominated by a number of vehicle and supplier giants. These companies are based on mechanical hardware such as engines, chassis, etc. as a competitive advantage, they have introduced new models from generation to generation based on the advancement of hardware technology. But now the situation in the automotive industry as a whole is completely different, and the role and status of hardware suppliers in particular has changed a lot compared to the past. Previously, vehicle companies and hardware suppliers at all levels such as Tier1 and Tier2 had their own housekeeping skills, forming a solid fortress layer by layer. Now the degree of homogenization of hardware is getting higher and higher, especially in electric vehicles, including a series of key components such as batteries and motors, which can be obtained by various car companies through similar supply chain systems. As a result, it is becoming increasingly difficult for car companies to build product differentiation through hardware.
Not long ago, I bought a domestic electric car, and on the whole, I feel that it is very close to the products of leading foreign brands, and some aspects have even surpassed. The driving experience, including the high-grade feeling of the suspension and the smoothness of the vehicle, is very good. In my opinion, this is not only the progress of the local car company itself, but also the accumulation and improvement of the entire industry, and more importantly, the reshaping of the automotive supply chain in the era of electrification. At the same time, this also shows that automotive hardware is becoming more and more homogeneous, and car companies must adopt new strategies in the future, rather than continuing to rely on hardware to create product characteristics.
The other direction is software. Since it is impossible to build differentiated automotive products based on hardware, software naturally plays a greater role. Automotive hardware corresponds to the configuration, parameters and other basic parts, in the future in these aspects, the products of each car company will not be much different; and the ability and performance of the vehicle, more reflected in the interaction between people and the car, the interaction between the car and the exterior, and the behavior mode of the car in various scenarios, etc., these will be defined by software, and achieved by software-driven hardware. I think that at least a large part of the attributes of future automotive products will be determined by software, so automotive product managers must pay close attention to the characteristics of the software level.
At the same time, in the combination and integration of various standardized hardware, software will also play a completely different and important role than before. Imagine if the software in each hardware system is customized and embedded, then it will be very difficult for vehicle companies to recombine various hardware and build new product features. Or if each piece of hardware and its software are built individually by different vendors, then when vehicle updates evolve, the coordination and response between these vendors will encounter great problems and cannot achieve a high degree of agility. Whether the vehicle enterprise can build a combination of new features and the speed of building this combination is precisely the basis for the continuous iterative upgrading and dynamic update of the automobile in the future, and it is also the key to the car company to create differentiated products.
Therefore, car companies need suppliers to provide standardized hardware decoupled from software, and then based on their own understanding of the car, through software combination and mobilization of different hardware to create unique products. I believe that in the future, differences between automotive products can only be achieved through the definition and call of standardized hardware by software. This may still be somewhat controversial in the industry, but everyone's understanding is increasingly converging. More and more colleagues believe that in the future, software will play a more important role in the car, and hardware will tend to be standardized, and eventually car companies will mainly build differentiated products through software.
Zhao Fuquan: Mr. Cao believes that the concept of "software-defined cars" is not an offense to the automotive industry, which has been dominated by hardware. In fact, the future car brand is still in the hands of car companies, and car companies define their connotations. Under this premise, software is just a new tool and new means that can help car companies reconstruct the functions and performance of the car to achieve the best user experience. Therefore, on the one hand, "software-defined cars" reflect the direction of industrial development, which is undoubtedly correct in itself; on the other hand, it does not deny the foundation and importance of hardware, and does not mean who wants to grab the jobs of traditional automakers.
In the future, the space for automotive hardware to meet the needs of users will become smaller and smaller, and it will become more and more difficult to achieve brand differentiation. Because the development cycle of hardware is long, the degree of freedom to change is small, and more importantly, in the face of new needs generated by users, the cost investment required by changing hardware to meet it is too large, and the response speed is too slow. It is undoubtedly much cheaper and faster to meet user needs through software. In this way, the market demand for software should have existed for a long time, why has the industry proposed "software-defined cars" in recent years?
Cao Bin: This has a lot to do with the progress of the entire Internet and the IT industry. At the same time, hardware-based design and manufacturing systems encounter more and more problems in supporting the rapid evolution of products. In the past, when we cooperated with vehicle companies, we often encountered this situation. For example, the wiper assembly is not complicated overall. However, such a small assembly, if you want to make certain modifications, the entire development cycle and cost are very high. Because every car has to define, calibrate and verify the wiper assembly at a given point in the development process. If you want to modify it later, you can only develop it twice. To this end, car companies and suppliers need to re-sign contracts and re-calibrate and verify at all levels. Obviously, such a hardware-oriented engineering system and process cannot support the rapid iterative evolution of products in the future of increasingly complex vehicles.
How to solve this problem? The way to do this is to standardize the hardware. For example, the wiper assembly is actually a mechanical part driven by a motor, and the sensor required by the wiper can use the camera or other sensors on the vehicle, so that intelligent control can be realized. When the current windshield is less transparent in the rain or dirty after the rain, the vehicle is controlled by software to automatically start the appropriate working mode of the wiper, which achieves the purpose of the software-defined wiper function.
When a variety of different assemblies and modules are standardized, a higher level of intelligence can be achieved through the software running in the central controller, which is similar to the effect of multiple apps running on mobile phones. On the one hand, this can greatly shorten the product development cycle, on the other hand, the widespread use of standardized components, but also help enterprises to control costs and quality. For example, a parts company develops and produces a standardized wiper, and then sells it to various vehicle companies, the price will be very cheap; at the same time, the calibration and verification of standardized hardware can be appropriately simplified, thereby further saving development time and cost.
From this point of view, "software-defined automobiles" is actually a path that must be chosen after the development of the automotive industry has reached a certain stage and the product functions have been complex to a certain extent. Otherwise, to reconstruct a new car that is more complex and has higher intelligence and capabilities on the basis of the original model, the cost and time required are unbearable, or even impossible, for auto companies. The successful practice of the IT industry just provides a feasible reference for the automotive industry, as long as it effectively draws on similar methods for transformation and upgrading, the automotive industry can form a new model and launch new products.
Zhao Fuquan: I think that a new round of scientific and technological revolution, especially the rapid development of digital technology, will make "software-defined cars" a natural success. While there may still be some in the automotive industry who don't subscribe to the term "software-defined cars," there is a consensus on the growing importance of software.
So why is the role of software getting bigger and bigger? Because the development of hardware to today, has been very mature, car companies want to rely on hardware to make differentiated products and brands are becoming more and more difficult; at the same time, the hardware-led development model is costly, slow, it is difficult to achieve rapid iterative update of products, can not effectively meet the user's continuous upgrading of personalized needs.
In contrast, software is precisely able to solve these problems. In the future, after the gradual standardization of various hardware, we can use software decoupling to call different hardware and combine new functions, so that the ability of hardware can be more fully exerted, and the needs of users can be more flexibly and faster to meet. At the same time, this model also has more advantages in terms of cost. Not only is the cost of the software itself much lower than the hardware, but the same hardware can be used for a longer time, during which the product can be iteratively updated through the software, so that the car always maintains good function and performance, and even obtains better functions and performance.
Furthermore, software is the key to optimizing the user experience. Experience is probably one of the most talked about buzzwords in businesses right now, and the fundamentals of improving the user experience are constantly meeting the needs of users. To this end, I have previously proposed that enterprises must first meet, then explore, and the highest realm is to create and guide user needs, so as to bring users a surprising experience. This requires enterprises to make full use of digital, intelligent and other capabilities, and these capabilities must undoubtedly be based on software to achieve. Finally, with the continuous enrichment of software and the rapid improvement of capabilities, we will bid farewell to the era of hardware-led product differentiation and enter a new era of software-led products and brand personalized experience.
Future automotive innovation and development
The ultimate direction is to understand people
Zhao Fuquan: Just now we also talked about "data-defined cars" and "chip design cars", how do you understand this? How do they differ from "software-defined cars"? What is the core of it?
Cao Bin: In the era of "software-defined cars", software will be in a state of continuous growth. We know that hardware is a fixed and unchanging product; and software is fundamentally different from it, software is a changing system, can continue to grow from small to large, from good to better continuous iteration. That is, software can add new functions and form new capabilities, and the self-evolution of products is the core of "software-defined cars". Therefore, whether it is a vehicle company or a supplier, it can make its products have a "soul" through software and form certain brand characteristics.
At the same time, as software grows, it will place increasingly high demands on the external environment that supports its operation. This external environment also includes related hardware, such as the requirements of future automotive software for chips will continue to increase, prompting chips to accelerate upgrades from generation to generation. The more functions the software wants to implement, the stronger the computing power of the chip must be. At the same time, the structure of the chip must also evolve to better match the growing software. That is to say, like computer chips and mobile phone chips, car chips must also be continuously upgraded with the increasing complexity of software. This means that there is a strong coupling relationship between software and chips: on the one hand, the growth of software is the fundamental driving force for the improvement of chip computing power; on the other hand, the performance of chips will promote or limit the role of software.
So can chips define cars? As mentioned earlier, chips are a very important part of future automotive products and will certainly continue to evolve. In the future, there may even be consumers who choose to buy cars according to the chips they are equipped with, that is, because the car uses an advanced chip that can run certain software, consumers believe that the car has more advanced intelligence or a better experience. It's like today's consumers pay attention to the performance of their processor chips when they buy a computer. As a result, the chip will provide additional brand value to automotive products. Under this prospect, I think that in the future, the automotive industry will have a clearer division of labor, resulting in a series of giant companies focusing on different key areas such as automotive software and chips. As an important component with both versatility and unique brand characteristics, the chip will provide consumers with reference indicators for perceiving vehicle capability upgrades, functional progress, and experience optimization, and will also allow consumers to pay more attention to a car brand because of the chip brand. However, I still think that the term "chip-defined car" is slightly different from that of "software-defined car", and the former has a smaller connotation than the latter.
In addition, the software generates more and more data while it is running. In fact, the main role of software is to collect, process and use all kinds of data. That is to say, the software system will continue to produce data, and the mining and utilization of this data will make the software system more intelligent. To put it more bluntly, software is "fed" by a variety of data. Without data, it is impossible for software to understand the user and give them features that are more relevant to their needs and a more personalized experience. In the future, if auto companies want to make personalized products, they must first accurately describe user preferences and fully explore user needs based on the data of users' daily use of vehicles. In this sense, data drive is both the fundamental driving force for software development and the inevitable result of software development. So "data-defined cars" and "software-defined cars" are actually the same thing.
Zhao Fuquan: Mr. Cao just further shared his views on different concepts such as "software-defined cars" and "data-defined cars" and "chips defining cars". In fact, if software can define cars, then data can also define cars, because it is the data that software ultimately produces and uses. What is the data? In my opinion, data is the digital representation of various information such as users, vehicles, and the environment, which reflects the needs of users and the situation of the vehicle. In the future, software that cannot generate or utilize data will have no vitality and will gradually lose its role and position in the tide of automobile intelligence.
The data is processed by the software on the chip, and the software algorithm and the chip computing power will jointly determine the scale, speed and level of data processing. Therefore, the chip is crucial, and its performance directly affects the capabilities of the software, that is, the ability to process data, and in turn affects the potential of the car to achieve more functions and performance. Conversely, in order to optimize the vehicle based on data, it is necessary to achieve data acquisition and reflow, and deep processing of data, which puts forward clear requirements for the capabilities of chips. From this point of view, software, data, and chips will be integrated in the future.
In short, in the era of digitalization and intelligence, it will be impossible to achieve rapid iteration of products based on hardware, and it is difficult to meet the individual needs of users. Based on the growing software, using powerful chips, car companies can effectively collect, process and apply a variety of data, so as to flexibly call the same hardware to meet user needs to the greatest extent.
It can be seen that whether it is a "software-defined car", a "data-defined car", or a "chip-defined car", it is only from different angles to pay attention to and emphasize the problem of car intelligence.
If from the perspective of data support product iteration, no data can not accurately identify user needs, and constantly optimize product performance, so it can be said that the data defines the car; if from the perspective of software generation and application data, no software can not produce and apply data, so it can also be said that the software defines the car; if from the perspective of chip support algorithm processing data, the chip computing power directly determines the upper limit of data processing capacity, thus determining the upper limit of automobile function and performance design. This is also the upper limit of the ability to meet the needs of users, so it can also be said that the chip defines the car. Of course, I think for chips, a more appropriate term should be "chip design car".
It should be pointed out here that even with a chip with excellent performance, it is not necessarily possible to play the role of software to the extreme, and it is not necessarily possible to design the car well. But if there is no good chip, it must be a bad design car, which is an indisputable fact. Therefore, chips are a necessary condition for designing the cars of the future, but not a sufficient condition. In fact, whether enterprises can use the computing power of chips to the extreme depends on whether the software, including data acquisition, processing and application algorithms, can be highly matched with chips.
As for whether it can be said that "consumers define cars", I understand it this way: consumer needs are indeed crucial, and the ultimate goal of companies is to make consumers willing to buy their products. However, on the one hand, all products must meet the needs of consumers, which does not reflect the changes in the industrial restructuring period and the particularity of new cars; on the other hand, consumers do not know how much potential they have in the future of automotive products, nor do they necessarily know what kind of cars they really need, which requires companies to guide them based on the prediction of technological progress and the positioning of their own brands.
For the clear demand of consumers, car companies should go all out to fully meet the needs of consumers; and for the needs that consumers cannot clearly put forward, car companies should deeply analyze and process the data obtained based on software, effectively excavate the essence and boundaries of such needs, and meet the potential needs of consumers as much as possible; in addition, in the future, with the continuous development of big data and artificial intelligence technology, car companies can also create new needs that consumers have not expected, thereby surprising consumers and leading the consumer trend.
Such surprises cannot be defined by consumers, but can only be actively defined and effectively guided by enterprises based on a deep understanding of consumers. This requires enterprises to continuously accumulate and analyze big data such as consumers, vehicles and the environment, combined with their daily car scenes, personal habits and preferences and even personal values, etc., to provide consumers with a sense of satisfaction that exceeds their expectations. Obviously, this is far from "consumer-defined car".
Cao Bin: Teacher Zhao summed it up very brilliantly. Here, I would also like to talk about Neusoft Ruichi's understanding of data. In my opinion, software is a set of code, a chip is a piece of hardware that runs the code, and data is a memory of the external environment of the system, and this memory determines the system's capabilities. Of course, in the past, due to insufficient means of data collection, processing and application, this memory did not play a full role, only staying in the construction of relatively solidified functions, and could not really be used to understand people. Now, with the continuous development of artificial intelligence algorithms such as neural networks, this situation is gradually changing.
In fact, cars are highly complex products, and their complexity is far from comparable to mobile phones. The car has an independent space, in which there are components such as seats that have direct physical contact with people, as well as functions such as light, smell, air quality, and atmosphere that indirectly interact with people or chemical reactions. Especially the latter, there are many places for innovation in the future, and the key lies in how enterprises accurately grasp the needs of users.
There are companies that now refer to cars as mobile robots, and I think that's apt statement, or the essence of the problem. The car has many different ways and channels to interact with people, so in the future, the car must understand the user like a person, effectively use these ways and channels, and provide users with functions and services that truly meet their needs. This is the ultimate direction of automotive innovation and development.
Nowadays, cars have more and more functions, but they are not convenient to use. As a simple example, I've always felt that a car's air conditioning system is not humane enough, and even often distracts the driver. For example, when I was driving, I didn't want the air conditioner to blow directly, so I had to manually adjust the wind direction. Why can't the wind direction be adjusted automatically? The function itself is very simple, the problem is that the system does not understand that I do not need the air conditioner to blow the wind straight over now, and I do not know what kind of wind direction is most suitable for me.
To solve this problem involves the progress of a series of elements such as software, data, and chips, and the goal is to make the vehicle more aware of people, understand people's demands for travel by car, and people's comprehensive feelings about the space inside the car. That is to say, we need to build a robot system with more and more complete memories and thus more and more intelligent based on the backflow and feedback of data, that is, Robot (robot) system or artificial intelligence system. And such a system will understand people more and more, better and better.
For example, my car passenger seat has a massage function, although my lover and colleagues often sit in the passenger seat, but they are not familiar with the car, do not know that there is a massage function, and do not know how to easily start the massage function. Another example is that many models are now equipped with automatic driving functions, but the opening and use of automatic driving functions often requires the operation of a series of buttons or paddles, and ordinary consumers do not know what these devices are and how to use them if they do not read the "User Manual". Not to mention the time and scenario under which the primary stage of autonomous driving can be started, which is inherently complicated.
I think that the future car must not need users to read the manual and learn the operation before they can use various functions. Its function should be on the go, on the go, just right next to you when you need it, or automatically start up. This is the direction of future innovation and development of automobiles.
Zhao Fuquan: Cao Zong's words are very important, and the core of it is that in the future, we must make cars understand people better. This is also what I often say, the partner interaction function of the future car, that is, the emotional attribute, will be far greater than the simple mobility tool attribute. As a result, the value of the car as a third space will be truly highlighted.
Speaking of which, the first, second, and third spaces we are talking about now are sorted according to their current intensity and importance of use, so we regard home as the first space, the office as the second space, and the car as the third space. However, the future car is not necessarily just a third space, it is likely to be a second space, or even a first space. From the perspective of people's choice, the car as a third space now mainly stems from passive selection, that is, people need to move, so they have to enter and use the car. In the future, the car will become a more important organic part of people's lives than ever before, so that many people will actively choose to enjoy the car space.
As Cao Zong just said, people's feelings in cars now are not good. How to make users feel more convenient, more pleasant and more intimate in the car is the most important thing. Many people say that the future car will be a mobile robot, the meaning is that although the car is still a machine, it is a human, vital, self-evolving, and more and more user-aware machine.
Looking forward to the future, data as a carrier will quickly transmit user demand information to the car in a quantifiable way, and the car will fully understand the needs of users through the deep processing of data, and let them get the most extreme satisfaction. This satisfaction is all-round, including the so-called "body" feelings that can be directly accessed, such as the seat just mentioned, but also many so-called "heart" feelings that are indirectly exposed. For example, the air conditioner is automatically adjusted, the wind direction and wind speed are always pleasant, and the combination of sound and lighting creates different atmospheres that meet the preferences of different users. These can be based on the basic functions of the hardware, through the software on the chip processing data to achieve, the end result is to form an emotional connection between the human and the car such a machine, the establishment of a partnership relationship.
At that time, the car is no longer a hard state object, but the best companion with temperature and emotion, which can not only carry the user to carry out the required mobility, but also in the process of using the car, let it enjoy a variety of convenient and thoughtful functions, considerate and various services. As I said before, the future of the car will gradually develop from simply helping people to liberating people, and the ultimate goal is to understand people. Only by truly understanding people can cars better help people and liberate people.
Implement different hardware and software
Open up the reconstruction of the structure, the division of labor reshaping
Zhao Fuquan: Mr. Cao, in the exchange just now, we reached a consensus: the opportunity of software in the automotive industry today is much greater than when you first proposed the SDC concept. There is no doubt that the way cars are designed is changing, as are their communication and computing power, and thus the way software works on cars will change. Specifically, in the relationship between software and cars, how do you think it is different now from the past? What are the essential changes in the future? For example, the wiper you just talked about is actually controlled by software now, and will the software with similar functions in the future car be the same as it is now?
Cao Bin: In the past, when a vehicle company developed a model, the supplier provided the hardware assembly, and then the vehicle company combined these assemblies according to the product definition and completed the debugging. In that era, vehicle companies could have no software capabilities. All software is provided by vendors, and much of the software is in Tier2's hands. That is, the software is only a part of the electronic component, embedded in the corresponding hardware. Taking the wiper as an example, its controller has software configured to achieve the established mechanical functions, and the logic code of these software corresponds to the different actions of the wiper, pre-written, input into the controller, you can make the wiper run effectively. Therefore, most of the previous control software was done by the supplier when developing the relevant hardware.
The future situation will be very different, and the software of the future must be based on data, scenario-oriented, and understanding requirements. As a result, there will be a combination of multiple hardware applications, such as when the door is opened, the lights in the car will automatically turn on, which is a combination; and the seat attitude can be synchronized with the temperature in the car and the wind direction of the air conditioner, which is also a combination. In the future, there will be a lot of software to achieve this combination of cross-component, cross-system, and cross-functional applications, and car companies need to build a model that optimizes user behavior patterns, vehicle operating conditions and external environmental conditions. I believe that the above type of software can only be dominated by vehicle companies in the end, because no supplier can solve the multi-component, multi-functional, multi-scenario collaboration problem at the vehicle level. This is the first difference.
On the other hand, in the past, software was embedded in the hardware assembly, some developed by the supplier itself, and some developed by the supplier to find a company with software development capabilities. In this case, software development is tightly tied to specific hardware. The future trend is to decouple hardware from software, and software no longer needs to be developed for specific hardware, but can flexibly call standardized hardware. As a result, software developers and hardware developers can be completely separated, and in order to make the separation of soft and hard in automotive products truly realized, it is necessary to completely change the existing vehicle electronic and electrical architecture to ensure that software development for automotive hardware can be carried out relatively easily. If the original electrical and electronic architecture is still used, the computing power of the car is scattered in a number of different hardware assemblies, and the software is embedded in various controllers that are independent of each other, then the space for iterative update and continuous optimization of the vehicle will be very small. That is why the concept of a domain controller has emerged and a trend towards centralization of central computing units has emerged. This change in the electronic and electrical architecture is bound to trigger profound changes in the automobile development model, supply chain system, and supply relationship.
For this change, the average consumer can not feel it, but in terms of car development, it means a subversive revolution. In the past, many functions in the car were developed separately by different departments; now the control and combination of various functions only need to be developed by a design team with software capabilities at the corresponding domain controller level.
Going forward, in order for cars to truly understand people better, have more complex behavior patterns, and provide smarter services and experiences, automotive companies must build several domain controllers, and possibly even the only central control unit, and then develop richer and better-use applications based on this. This demand will not only drive changes in electrical and electronic architectures, but will also promote the layering of related software to build new systems that are highly intelligent. This is the second difference.
Therefore, "software-defined vehicles" will not only change the object, scope and mode of software development, but also trigger the reconstruction of the vehicle's electrical and electronic architecture, pointing out the direction for the transformation and upgrading of the entire industry. As for who is responsible for providing key hardware such as domain controllers, who is responsible for providing the development platform under the new architecture, who is responsible for providing middleware software, and who is responsible for providing upper-level application software, it is the industrial re-division of labor problem caused by this. Overall, I think automakers will have more room to play and redefine automotive products and their differences from the perspective of understanding people.
Zhao Fuquan: Mr. Cao's remarks illustrate an important point: the logic of software development is completely different from before. In the past, there was also software on the car, but it was only software based on some kind of hardware, and the role was to make that hardware work, without involving other hardware. For example, the engine has its own control software, and the transmission also has its own control software, which is developed by the supplier based on a specific hardware, in order to maximize the performance of this hardware. In fact, many companies are still based on this traditional idea when developing automotive software, and it is impossible to achieve a true "software-defined car" at all.
However, with the continuous improvement, increase and change of consumer demand, in the future, we need to combine various functions on the car to provide users with personalized and intelligent services. To this end, on the one hand, it is necessary to standardize and decouple the hardware, and on the other hand, to solve the problem of software linkage. In fact, different software is difficult to get through. And if each software is as independent as in the past, it is impossible to form an effective linkage. Therefore, "software-defined car" means that we need to reconstruct the electronic and electrical architecture of the whole vehicle in order to effectively open up all kinds of software, so that different software under the same architecture and different hardware controlled by it can be truly linked, so as to play a greater role. Obviously, this new electrical and electronic architecture will be a leap forward for the automotive industry.
As a result, the industrial division of labor will also undergo major changes. Like Neusoft was originally used as Tier2 to support Tier1, that is, Tier1 sold hardware to vehicle companies, and Neusoft provided software; of course, many Tier1s themselves also do part of the software. In this case, the vehicle company does not need to understand the software, such as the purchase of brakes, which comes with embedded software, which can realize the control and optimization of the brakes. However, the problem is that such software only works on the brake, and cannot realize the linkage and optimization between other hardware such as brakes and steering, resulting in various hardware being in a relatively independent island state.
The future situation is completely different, different software can flexibly mobilize and use different hardware, to achieve effective linkage between hardware functions, so that it can form a variety of combinations of new features, provide a full range of new experiences, and achieve cross-component, cross-system global optimization. At that time, it is likely that there will be such a scene: it is the son's birthday, after the family gets into the car, the stereo will automatically play the "Happy Birthday Song", and the lights will also show the atmosphere of celebrating the child's birthday. Instead of requiring the user to press the button many times to tune out several functions one by one, the experience effect achieved will be blunt and lack of "texture". Obviously, in order to do the above, the relationship between automotive electronic and electrical architecture, computing platform, hardware and software, and the division of labor between the vehicle and the supplier will be revolutionary.
One point in this series of changes is clear: in order to ensure the definition of automobile brand connotation and product experience, and enhance the core competitiveness of the new era, vehicle companies must form stronger software capabilities. It is impossible for car companies to have all the software and hardware capabilities, so they need corresponding support from software suppliers like Neusoft Ruichi. However, the premise is that the car company must first define the vehicle architecture and prepare for it accordingly; at the same time, the software supplier must develop the software based on the new electrical and electronic architecture platform. Only in this way can vehicle companies obtain stronger resource allocation and combination capabilities.
However, many vehicle companies are not ready for this. In the future, consumer demand will be more and more, the change will be faster and faster, and correspondingly, automotive products will become more and more complex. However, the reform of the vehicle structure and the enterprise organization is not to complicate the simple problems, but to simplify the complex problems, that is, by reconstructing the structure, defining the division of labor and changing the organization, forming a general environment that makes the industrial division of labor clearer and the cooperation between the whole supply and supply more orderly. This is an important goal that automotive companies must strive for.
Automotive software classification
Control software, infotainment software, autonomous driving software
Zhao Fuquan: Mr. Cao just talked about software layering, and it should be said that there are more and more types of automotive software at present. Can you share your thoughts: How will automotive software evolve in the next decade? What kind of classification will be formed? What companies provide each type of software? What does this software mean for vehicle companies? In particular, vehicle companies and tier 1, Tier2 and so-called Tier0.5 and other levels of suppliers, who will have what kind of software?
Cao Bin: From the perspective of automotive product development, automotive software can be divided into three categories at this stage.
The first category is control-related software. Software that controls batteries, motors, brakes, steering, doors, windows, etc. all fall into this category. In this type of software, traditional parts suppliers have a greater advantage. For example, body control software, there may be many Tier1 suppliers or specialized companies engaged in vehicle design, have a very good foundation to develop this type of software.
The second category is infotainment software. Mainly distributed in the cockpit and center console, this type of software belongs to the more open system. Now the mainstream choice is based on the Development of the Android system, which can provide good Internet content support, such as video, audio, etc., in addition to accessing more and more content, including the connection with various resources on the Internet and the Internet of Things. This kind of software is relatively open, and its development is relatively mature, not only has a lot of external resources that can be connected, but also has a lot of developer resources: one is a mobile phone vendor, which has a large number of developers based on Android systems; the other is that Internet companies, such as Tencent, Baidu, etc., have gone deep into the field.
The third category is autonomous driving software. This kind of software is a very special field, due to the high degree of specialization, involving professional algorithms and high computing power, so the development of automatic driving software usually needs to be responsible for by a professional team to systematically solve various software problems in the current and future of automatic driving.
In the process of automotive product development, it is basically the above types of software, and car companies have different development strategies for various types of software. At present, when many car companies enter the software field, they will first start from the relatively familiar control software, take the body control as the priority input object, and based on the body control, they can realize functions such as door and light linkage. This situation poses a serious challenge to Tier1, which originally provided hardware and software for vehicle companies at the same time, because in the future, car companies only need Tier1 to provide hardware, and the software will be developed by car companies themselves or provided by other suppliers. In this process, the division of labor and boundaries between Tier1 suppliers and car companies will continue to be re-established. Some suppliers may be left behind, while others may find new opportunities to provide car companies with products and services that are in line with new business models.
At present, automatic driving software has become a focus of general attention of vehicle companies. However, due to the unique professionalism of automatic driving, traditional car companies must cross great technical obstacles if they want to develop autonomous driving alone. Relatively speaking, some new car manufacturers have attached great importance to this field from the beginning, gathered a lot of talents to tackle automatic driving, and some car companies have set up hundreds or even thousands of automatic driving development teams. This is also a software strategy that some car companies have clearly chosen.
Looking forward to the future, car companies will form a new business model of mutual cooperation with software suppliers, chip suppliers and other suppliers, that is, a new ecosystem of multi-party participation and re-division of labor that is different from the past. In this new ecosystem, some software is developed by suppliers, and then the vehicle company is responsible for the integration of software and hardware. At the same time, some software, such as HMI human-machine experience, and some applications may be developed by car companies themselves. However, suppliers may also have the opportunity to provide relatively mature and complete platform-based software for car companies. For example, an operating system is provided by an independent vendor as a platform for various software to run. Such an operating system can be widely used by many car companies, and even form its own brand effect.
Software development requires a growthable architecture
Organization as well as system integration and testing capabilities
Zhao Fuquan: Looking forward to the future, we will take ten years as the node, how do you think the vehicle enterprises should make reserves? Under the trend of "software-defined cars", the number of software will increase. There are tens of thousands of hard parts on a car, and there will probably be tens of thousands or more of software in the future. In the face of so much software, vehicle companies cannot completely master it, but it is also impossible to master it all.
Just like the automatic driving just mentioned, many car companies believe that automatic driving is the most important ability of future cars, and vehicle companies must not control the driving situation of vehicles, so they must make up their minds to develop themselves. However, the technical difficulty of autonomous driving is very high, involving perception, decision-making, execution, and many core technologies in different fields such as data, algorithms, and chips. Even if car companies form a development team of thousands of people and have a dedicated software team, they may not be able to do a good job.
Recently, many car companies have begun to cooperate with professional autonomous driving startups. I am also thinking about this: this deep binding is mainly because the autonomous driving company feels that its technology cannot realize value without the whole vehicle, so it has to turn to the vehicle company? Or is it because vehicle companies are gradually realizing that it is far more difficult than expected to promote autonomous driving technology on their own, so they actively seek the support of external professional teams? Further, will autonomous driving technology be standardized in the future? This is also a problem that many entrepreneurs often discuss with me. Mr. Cao, what do you think about this?
Cao Bin: I think we can look at this issue from two levels. At the first level, car companies should indeed participate in software development, and they should grasp a certain degree of dominance and form a certain uniqueness. The so-called uniqueness is that some of the core software in the car is unique to the car company itself, rather than provided by the supplier. Because the supplier can supply both the car company and the car company, so as to maximize its own commercial interests. Therefore, relying on suppliers for software development, it is difficult for car companies' products to be unique. Car companies must grasp a part of the core software in their own hands, this part of the software is the difference of the product, but also the "soul" of the product.
So, how can we choose the direction of software investment and truly grasp the "soul" of the product? When I talk to a lot of car managers, I often ask them: If you have 500 software engineers, which direction are you going to put them into? The answers obtained in the results are different, some car companies pay more attention to vehicle control, some car companies pay more attention to power optimization, and some car companies hope to give priority to solving automatic driving or human-computer interaction problems. And as I continued to ask them: Do you have your own software architecture? Where is your software architect? Many people can't answer.
In fact, software is very unique: on the one hand, unlike hardware, software has no manufacturing costs and can be copied, so its cost is extremely low. On the other hand, software is a highly complex system, and the core demand of software development is to overcome this complexity. For example, we need to write 100 lines of software code, just find a trained high school student to do it; but if we need to add 100 lines of new code to the 1 million lines of software code, this job may not even be able to do many doctoral graduates. Because only a team that is very familiar with the 1 million lines of software code can write a better 100 lines of code after repeated discussion. It's not that the more lines of software code, the greater the value of the software, and software code that can't be optimized on the basis of the original is just garbage.
That is, there is a symbiotic relationship between software and the organization that develops and maintains it, and we cannot treat a piece of software as a solidified, separate component. Therefore, when enterprises invest in the field of software, I think the most important thing should be to build an architecture and organization that can support the continuous growth and continuous progress of core software, which is the vitality of the future development of software. As long as this architecture is clear and the team is effectively built and run, the software can naturally continue to precipitate, polish, and iterate continuously, and ultimately carry the "soul" of the product. This point must be highly valued when vehicle companies enter the software field.
At the second level, in software development, car companies should give priority to the formation of system integration and testing capabilities. Taking the automatic driving software as an example, Dean Zhao also mentioned just now that its complexity is very high. The complexity of a set of software for autonomous driving systems is now absolutely greater than any other hardware assembly on the car. For such a complex system, car companies should think about how to ensure that various functions, such as high-speed cruise, automatic follow-up and automatic parking, can be well provided to users. This is the first priority for car companies.
In this process, car companies can get the support of many suppliers, some do algorithms, some do chips, and do cameras or radars, and so on. The key lies in how to effectively combine these hardware and software provided by suppliers on automotive products to achieve the various functions required. This requires that vehicle companies must have two major capabilities.
First, system integration capabilities. For autonomous driving, system integration capabilities mean that car companies must have a clear software architecture. Otherwise, various pieces of software from different vendors are combined and difficult to run well. The second is the ability to test and verify the system. Including data acquisition, annotation, screening and training, there must be verification, and it needs to be covered from "back-end development" to "front-end development", and is responsible for by specialized teams with different professional skills. This is a key problem that car companies must solve to master software capabilities.
After the car company has the above capabilities, it makes sense to consider other divisions of labor. Like whether to develop their own algorithms, whether to design new features by themselves, whether to do some deep integration across systems, such as combining the perception fusion of lidar and other sensory integration with the optimization of the power system, all of which can be sorted out after solving the architectural and organizational problems and having the ability to integrate and test. Therefore, whether car companies give priority to building automatic driving systems or giving priority to intelligent cockpit or body control software, they need to first establish a sustainable growth software architecture and team organization, and form system integration capabilities and test verification capabilities.
Zhao Fuquan: What Mr. Cao just talked about is very important, which is one of the most concerned issues for CEOs (CEOs) and CTOs (chief technology officers) of various companies in recent years. I myself have a lot of thinking in this regard, leading the team to do a lot of research, and proposing solutions for some enterprises. I think this question is at the heart of the theme of our conversation today, which is how exactly "software-defined cars" land.
In the future, automotive products may have tens of thousands or even hundreds of thousands of different software, forming a more complex application ecology than mobile phones, and even consumers can directly participate in the development of some automotive software. The so-called SOA (service-oriented architecture), a large part of the software is to provide services to consumers, if consumers can not fully participate, it is impossible to achieve true SOA.
After the standardization of automotive hardware, automotive products need more software to meet the different needs of consumers in order to achieve the ultimate personalized experience. However, it is unrealistic for vehicle companies to thoroughly understand and realize the individual needs of each consumer. Even if car companies really have the ability to do this, they will not be able to form the characteristics of their own brands due to "big and complete". Therefore, car companies should establish and operate an open platform, so that every user has a channel to express their needs, and then many participants on the platform jointly meet the needs of these users. I think this is the most difficult and critical problem for "software-defined cars", and if it doesn't reach this level, this industry restructuring will not be complete enough.
Let me talk about my understanding of what Mr. Cao just shared. First of all, Mr. Cao stressed that whether it is a "software-defined car" or a "hardware-defined car", vehicle companies must have their own core capabilities, which is the basic premise for car companies to participate in market competition. It's just that in the era of "software-defined cars", car companies need different new core capabilities. This may sound like a big truth, but it's actually the most important thing. All enterprises must take the initiative to think, when the software determines the competitiveness and brand connotation of automotive products, what kind of core capabilities do they need?
Second, the combination of software and hardware is different in difficulty. For hardware, it is relatively easy to combine, such as assembling compressors, condensers and controllers, etc., to form an air conditioning system. Software is not at all like this, not only different software involves different interfaces, but the software combination is often very complex, if you just put the various software simply together, it is easy to cause the system to collapse. That is to say, the complexity of software integration is 1+1>3, but the effect of integration may not reach 1+1=2, and may even be 1+1<1.
So, how can we effectively integrate various software to play a greater role? Mr. Cao believes that it is necessary to rely on the appropriate structure. Because of this, the chief architect responsible for defining the architecture becomes critical. In my opinion, the role of the chief architect is to simplify the complex software portfolio, by defining the architecture clearly, so that many participants can clearly find their own position, accurately complete their tasks, and ensure and promote effective collaboration between the participants and the software, so that the entire system can operate efficiently, and further absorb more excellent participants and related software.
Finally, software and hardware work differently. For hardware, vehicle companies can adopt this supplier today and replace it with another supplier tomorrow, as long as the supplier has the ability to meet the requirements of car companies. However, for software, in addition to building an architectural platform, car companies also need to have a long-term stable team, because software development needs to be accumulated continuously. In the software development process, there are many details that cannot be seen and hidden in the depths of the code. Don't talk about replacing a brand new team, even if the core people in the team jump ship, can cause the successor to be confused. In addition, even if the personnel is relatively stable, if there is no long-term accumulation and effective inheritance of team awareness and corporate culture, then software development will still be more and more difficult, and it is ultimately impossible to achieve the desired results. There is now a saying that because hardware is becoming more and more complex, only the import of software can meet the growing needs of consumers. But if the software is becoming more and more complex, and the enterprise cannot get good results, it may be better not to import the software.
From this point of view, I would like to remind the leaders of the vehicle company that for the development of software, especially the automatic driving system, the first job is not to delve into the algorithm by yourself, but to build the overall architecture first. Be sure to figure out what kind of capabilities your goals are to achieve in automotive products. How much potential is there? And how many steps do you need to take to reach such a goal? How many parties need to be pooled, including hardware and software providers? That is, enterprises should determine the appropriate overall structure, and then decompose to form a specific landing plan, and then implement it step by step according to their long-term strategy and capabilities.
Based on my experience of working hard in the vehicle company for nearly 20 years, I can fully feel the impact of "software-defined car" on the CTO of traditional car companies who are well versed in hardware development. In fact, the development of hardware and software inherently requires completely different capabilities, but also a completely different model, which is not simply to replace the difference between several suppliers, but must completely change the existing concept. For example, software development may not be like hardware development, always thinking of replacing the A-point supplier with strong development capabilities with a lower-cost B-point vendor, which is difficult to ensure the accumulation and continuation of software.
In short, car company leaders should realize that in the era of "software-defined cars", we must first establish a new product development concept from the construction of the overall architecture, and form a completely different model and process from traditional hardware development. On this basis, we will rethink and solve the specific problems of core ability selection and division of labor. Such as whether to develop your own algorithms, etc., these are the second level.
At the heart of the "software-defined car"
Differentiate by "doing something and not doing something"
Zhao Fuquan: Mr. Cao, let's continue with the topic just now. Looking ahead to 2030, how far do you think OEMs will need to master the core capabilities of "software-defined vehicles"? In this way, how should the current car companies promote the technological innovation ecology of "software-defined cars"? In my opinion, these problems must be clearly thought out by enterprises now, otherwise it will be too late to wait until 2030 to lay out. Of course, the goals, capabilities and current status of different companies are different, so the strategy chosen will be different. There are also many enterprises that are facing great operational pressure, and it is understandable to choose the strategy of "mr. survival and later development". However, one thing is clear, all enterprises should face the ideal state of the future, think seriously and strive to do a good job in the immediate layout. As the leader of Neusoft Ruichi and a software expert who knows the automotive industry very well, what capabilities do you think automakers should have to face the competition in 2030? In particular, what abilities do you have to try to do first, even if you can't do it right now?
Cao Bin: Your question is very challenging. The industry is currently in a special period of rapid change, and it is very difficult to predict the situation in ten years. I can only try to talk about some of my own judgments.
I think there are several general directions for the automotive industry in the future that are certain. First, the standardization of automotive hardware. As we mentioned earlier, the future of automotive products must be composed of a series of standardized hardware. Second, automotive software will appear hierarchical and division of labor, forming specialized software platform companies, tool companies and application software development companies focusing on different fields, such as automatic driving systems, human-computer interaction software, etc. In this process, there will be a number of independent software companies to grow up and form a certain brand effect.
At that time, I think car companies should have the following three core capabilities.
First, a good product manager. When the car can interact quickly and closely with consumers, it will have certain attributes and characteristics of FMCG to a large extent, and thus lead to significant changes in consumer trends and competitive factors. At this time, the role of the product manager will become greater than ever, because the product manager is the key person who accurately identifies the market segment and accurately defines the product ability of the car company, and he must effectively present the corporate philosophy and brand connotation through the product, and quickly deliver the market. On the other hand, it is more difficult to become a good product manager than before, because the future product manager must choose both good hardware and good software, and integrate these hardware and software to achieve the fastest product update, the largest product value and the best user experience, and must also do a good job of cost control.
Second, strong system integration capabilities. As mentioned earlier, the software and hardware from decoupling to integration will force the vehicle enterprises to form a stronger system integration capability, which is also the biggest test faced by car companies. Now car companies often encounter such a situation, in the early stage of product development to select some parts, but in the later integration is found to be difficult to carry out, this is mainly due to the continuous development of software led to the continuous development of the vehicle level integration difficulty. Therefore, "software-defined cars" will put forward higher requirements for the integration capabilities of car companies. This includes a deep understanding of the overall architecture and individual systems, as well as integrated process management and post-management, such as the full lifecycle management of software, the innovation of development processes and control content, and the re-structuring of organizations and teams for new automotive product development models. In short, in the future, if car companies want to quickly launch competitive products in a limited time and at a reasonable cost, strong system integration capabilities are essential core capabilities.
Third, the ability to differentiate. At any time, the products of each car company should have a different part to reflect the corporate philosophy and brand connotation. When mainstream car companies have excellent system integration capabilities and can use the resources of the whole industry to create competitive products, where is their differentiation? I think it depends on the pattern of the company when building the vehicle architecture and software architecture, that is, how much room for integration and innovation is reserved. On this basis, some car companies will continue to polish for application scenarios, travel modes or aspects of the human-vehicle interaction form to form more and more refined and strong product characteristics; some car companies will focus on vertical integration, such as from application software to chips, sensors and other key hardware, to provide better integration effects to achieve product differences; and some car companies will focus on horizontal extension, through a wider range of professional customization and services to meet the personalized needs of consumers. These can bring differentiated competitive advantages to car companies.
Zhao Fuquan: This is indeed a very big and challenging topic. What are the core capabilities of future vehicle companies? How do you create a new product? Just now, Mr. Cao talked about a background, that is, the future industrial division of labor will be clearer.
On the one hand, hardware standardization helps to clarify the industrial division of labor. In the future, standardized hardware can be called by software at any time, and ensure that quality and cost are controlled, which requires hardware suppliers to achieve large-scale production to the extreme. At the same time, other related enterprises can also concentrate more energy on software development.
On the other hand, software layering also contributes to a clear division of industry. Software layering itself means that vehicle companies have a clear understanding of what work they must focus on and which work can be handed over to other companies. In the future, car companies should all want to do more software themselves, but it is impossible to pack it to the end, after all, no company is all-round, even if the ability is strong, it must have a clear positioning. To this end, it is necessary to first choose the center of the core business, and then determine the radius range that can be covered according to its own strength. The radius is long and short, but it is impossible to extend indefinitely; and once the center of the circle is wrong, the company's efforts are all meaningless.
In this context, first, vehicle companies still need to emphasize brand building, and product managers are crucial in this regard. Because in the future, car companies can communicate directly with consumers, understand, identify and define user needs at any time, and can quickly convert these needs into product functions and services, so that users can get the best experience. The key to doing the above work well is that the company must have excellent product managers for the future.
From the perspective of work content, the previous product manager mainly handled some simple and direct user needs, and the future product manager needs to define the product based on the software architecture and create the product with a new software and hardware integration thinking. In fact, I now lecture to students repeatedly and they emphasize systems thinking. The systematic thinking under the "software-defined car" requires the leader to have the overall concept and way of thinking of the system architect, and must clearly know how many layers the software is divided into, and which key points the enterprise should grasp at which level.
In terms of time span, the product manager of the future will no longer be a simple project manager. We know that the project manager's job is one-time; future automotive products will need to be constantly iteratively updated, so there will be multiple deliveries (X SOPs). This is the SOPX concept I proposed earlier, that is, in the future, automotive products will achieve X series production through OTA upgrades. Every delivery in the entire life cycle of the car is a sublimation of product performance, functions and experience, which requires the product manager to be responsible for the whole process, always closely connected with the user, and respond to new user needs at any time. Obviously, the concept of a product manager will be completely different from what it is now.
Second, in the face of the new pattern of industrial restructuring and boundary expansion, enterprises need to "do something and do nothing", which involves the problem of how enterprises determine their core demands. In this regard, Mr. Cao talked about a very important point, that is, enterprises should return to the original point of origin and ask where is the biggest difference point of their products? If a car brand and product want to do everything, it will lose its personality and cannot be distinguished from other brands and products; and products that only achieve an average score in all aspects cannot really impress consumers.
In fact, the scope of "software-defined cars" is very wide, and companies can have different emphases, such as prioritizing smart cockpits or autonomous driving. Even if the same more attention to automatic driving, different companies can have different priorities, for example, some companies pay more attention to the automatic parking scenario, some companies pay more attention to the road driving scenario, the algorithm and data basis of the two are different. Of course, there are still companies that want to do it all, but then it is possible to invest 5 times or even 10 times more than other companies, and the resources of the enterprise are limited after all, not to mention that different emphases may also involve different corporate culture genes. Therefore, in the future, enterprises must adhere to the principle of "doing something and not doing something".
Specifically, for the future focus area of focus , software , it must also be "done and not done.". The software development team must first have enough scale, there are not a few people who are specifically responsible for programming to do a good job of software, 10 people, 100 people, 1000 people team, the effect is definitely not the same. After having a team of sufficient size, enterprises should select key areas and concentrate on tackling key problems. Suppose there are 1,000 software developers in the enterprise, if they are all invested in 1 key area, there is a high probability that they will do a good job or even lead; if they are dispersed to 10 key areas, then there will be only 100 people in each field, and the result is likely to be that no field can do well.
Third, for vehicle companies, Mr. Cao believes that building a good architecture platform and cultivating related core capabilities is the key to achieving differentiation. On the architecture platform, car companies should plan forward and leave enough "gaps" to reserve space for the future growth of the ecology. At the same time, the core capabilities of software architecture and other aspects, car companies must control themselves, and can not rely too much on software suppliers.
Hardware standardization
The inevitable result of industrial development
Zhao Fuquan: General Manager Cao, just now we have talked many times about the future hardware will be standardized, or it can also be called abstraction. So, how to achieve hardware standardization or abstraction? Hardware and software decoupling is currently being discussed in the industry, specifically, what hardware do you think should be decoupled? To what extent does hardware and software need to be decoupled?
Cao Bin: At present, some car companies have made a lot of investment in the development of controllers in the fields of motors and batteries. In the exploration period of industrial change, car companies decide where to invest resources and energy according to their own judgment, which in itself is not absolutely right or wrong. But looking ahead, I think automotive hardware as a whole will become more and more standardized and able to be developed in parallel.
We know that it usually takes about 3 years to develop a car now, and the development cycle of some car companies is relatively short, and it also takes about 2 years. During this time, various pieces of hardware have been advancing. This creates a problem: a new car defines hardware at the beginning of development, but by the time it comes to mass production, it already has better hardware, but it can't use the new car. For some critical hardware, this problem is even more prominent. For example, the chip is in this state, when a model starts development, even if the best chip at the time is selected, but when this new car is on the market, the chip previously selected has long been behind. Because the normal upgrade frequency of the chip industry is one generation a year, under the development cycle of 2-3 years, the chip has been updated for at least two generations. Getting new models to use the latest chips and adapt the software to them is a very difficult, or even impossible, thing to do in the traditional automotive product development process.
In the traditional development process, companies basically choose hardware when defining new models and develop software based on this. For some platform-based models, the timing of determining the hardware may be earlier, for example, I have contacted such a case, the company selected the hardware at the beginning of the platform planning, and the mass production of some models on the platform will be 5-7 years later. Imagine the hardware you chose 7 years ago, how can you not lag behind? How can it effectively support the current software? Such a product is difficult to succeed in the market. This situation was not surprising to everyone before, but in the era of new cars, it cannot continue like this. So, we have to decouple hardware and software.
The purpose of software and hardware decoupling is to allow suppliers' software and hardware development work to synchronize with the vehicle development work of car companies. In this way, when the hardware is iteratively upgraded, the car company can directly switch to the new hardware, and even another supplier can provide the same hardware. For example, when the development of automotive products is halfway through, and another supplier releases more advanced hardware, the car company can directly switch to the new product of this supplier. Of course, the premise is that car companies must have the ability to decouple software and hardware, achieve abstraction in hardware design, and only need to develop software based on the standard interface of the hardware, so that the software can be easily adapted and called hardware.
With this in mind, we have been advocating for a new model of automotive product development, which is "software first". That is, on the vehicle architecture platform, first use software to build a car, the car's various assemblies and components, such as chassis, body, power system, human-vehicle interaction system and sensors, actuators, etc., have been completely abstracted; then you can form the basic framework of the vehicle based on these abstracted hardware systems, and develop software that controls vehicle behavior patterns and key functions according to the corresponding hardware interface; finally, these software and hardware are adapted and debugged in parallel. In addition, this development model can also adopt different adaptation strategies and iteration cycles for different models, which also helps product managers to play their full role.
In contrast, the current model development is carried out one by one, which is also the traditional model that most car companies are still using; and in the future, in the new model of "software first", each car company will have its own set of exclusive software systems. This software system is cross-model, representing the core connotation and unique characteristics of the company's automobile brand. And this software system will be built by a professional team, is constantly iteratively updated, can effectively ensure that the various software in the system can be with different models, different development stages and different hardware systems, including chips, actuators, sensors, etc., effective matching and different combinations, so as to form different product functions and performance. The premise of this development model is that the hardware must be standardized and abstracted into an interface that can be called by software. Only such hardware can enter the architecture platform of car companies in the future and be adapted with related software.
In my opinion, hardware standardization is an inevitable result of the rapid iterative update of models. In fact, after all industrial development reaches a certain stage, when its products become highly complex, it is bound to move towards a more refined industrial division of labor. Because no one company can do the best in all parts, especially in software-dominated industries. Unless companies can bring together the world's top talent in every field and form an organization and culture that matches it, it's impossible. Therefore, an enterprise must form a strong advantage in some core businesses, and at the same time make full use of the advantages of other enterprises in other businesses.
Zhao Fuquan: This brings up another question, the so-called hardware standardization, should it be something promoted by the industry, or something that enterprises should do?
Cao Bin: I think we must first form a consensus at the industry level. On the one hand, if the vehicle company still adheres to the traditional way of thinking and development mode, it is meaningless to rely only on suppliers to provide some standardized hardware; on the other hand, a single vehicle company does not have enough strength to drive the full standardization of hardware. Because standardization must be the result of interaction, sharing and mutual recognition between the parties involved, otherwise it cannot become a basic model widely adopted by the industry. Therefore, I suggest that various organizations within the industry should play a greater role in promoting hardware standardization. In this process, industry organizations need to take the lead in defining the framework, refining consensus, and gradually making it a common consensus and standard model in the industry, and then promoting the industrial division of labor; and once the industrial division of labor is established, each enterprise will find a suitable position for itself, so as to further promote the process of hardware standardization.
Zhao Fuquan: I think that for hardware standardization to become the consensus of the industry, everyone needs to be able to fully understand the inevitability and necessity of this direction. If anyone does not know clearly or understands too slowly, it is likely to be eliminated by the rapidly developing era. Conversely, if the industry as a whole does not work together in this direction, the speed at which the industry develops will be affected. From another point of view, if Chinese companies can form a more thorough understanding of hardware standardization, and The Chinese auto industry can form a relevant consensus earlier, then we will have an advantage in the future competition of the global auto industry.
In my opinion, the internal logic of hardware standardization is very clear: the future of highly intelligent automotive products need to meet the increasingly individual needs of users, for this reason, it is first necessary to achieve a comprehensive decoupling of hardware and software through hardware standardization; on this basis, vehicle companies can define digital cars through software, or build a new car virtually based on the software architecture platform; and then continue to accumulate, iterate and optimize on this virtual model, so that different software and hardware are fully adapted and integrated with each other Finally, to create a new car that can meet the dynamic needs of users, have industry competitiveness, and reflect the soft and hard integration of corporate brand connotation. This is definitely a major trend in the development of the industry, which company can go to the front, there is a chance to seize the strategic opportunity.
However, hardware standardization is not something that can be achieved by one or a few companies. It may be that a supplier tries to do this, but the vehicle company does not necessarily accept it; it may also be that a vehicle company has raised this demand, but its suppliers cannot adapt. Therefore, in addition to the efforts of industry organizations, I believe that promoting hardware standardization requires relevant supply companies to reach a new type of strategic partnership. That is, based on the unanimous judgment of the industry trend, the two sides take the initiative to form alliances and cooperate with each other to work together in this direction. At the same time, industry experts and media should also make more appeals, so that more colleagues can realize that hardware standardization is the trend of the times.
I think this is also one of the important values of the dialogue column of "Zhao Fuquan Research Institute" - we can play a role in learning from each other and consolidating consensus by sharing our judgments on industry trends with our colleagues. On this communication platform, we do not sell cars, nor do we sell software, that is, to make judgments on the future development of the industry as experts, and to widely disseminate this knowledge, concept and ideas to help everyone understand the general trend of the industry, confirm their ideas, and form industry consensus.
In fact, not only the automobile industry, the entire manufacturing industry has developed to today, and it is very important to re-understand the special division of labor, and it is necessary to form a new consensus in the industry such as hardware standardization. Of course, this requires a process. At present, many people's thinking may still stay on the previous concept, such as the differentiation of hardware to achieve product differentiation, based on the traditional platform concept of "visible is different, invisible is the same" to develop products. The development concept of future products will be completely different, based on the same hardware, the use of different software can achieve product differentiation. At that time, the products of each company may have similar hardware that can be seen, and the invisible software is different, because software is the key to achieving differentiated competition, and it is also the core competitiveness of each company.
Software for the car of the future
The demand for talent will change significantly
Zhao Fuquan: When it comes to hardware standardization, I naturally think of the next question. What exactly does a software engineer need to know about hardware? Especially when it comes to hardware standardization and software can directly call hardware, do software engineers still need to understand cars? At present, a very realistic problem is that traditional automotive engineers understand cars but do not understand software, and it is difficult to complete good software development; while software engineers who cross-border into the automotive field understand software but do not understand cars, it is difficult to effectively control and optimize automotive products through software. The ideal scenario, of course, is that every car company has some engineers who understand both cars and software, but such talents will not appear out of thin air.
Cao Bin: I think it's going to be a process of continuous evolution, and in fact we can see that the demand for software talent in automotive companies is changing dramatically.
Previously, because software was embedded in hardware, the entire automotive industry did not pay much attention to software. At the same time, in terms of software development, various model development methods and tools for embedded software have also been formed, and the automotive industry has been fully applied in this regard.
With the deepening of industrial change, more and more car companies have begun to seek to master some software, first of all, various control software. However, the development of this part of the software by car companies is still based on model development methods, such as the use of tools such as MATLAB, which has led to the shortage of software talents in this area. This is still the case, and automotive companies are grabbing software engineers who understand model development.
However, in the next stage of development, I am afraid that the situation will be different again, and the model development of only component-level control and embedded software will become less and less applicable. Because in the future, automotive hardware will become more and more abstract and become a variety of clearer and clearer interfaces. The software will be independent of the hardware and at the same time will be able to call up a variety of different hardware. Therefore, the software developer must understand which hardware system the various functions of the vehicle are implemented, whether it needs to control the chassis, the body, or the steering and braking, or the battery and motor. In the end, these hardware systems must be opened up to achieve various combinations. This would involve expertise in many different areas of expertise, which would be a high bar far from being directly qualified by existing software engineers familiar with model development.
In the face of more and more, more complex, more and more important software, the automotive industry has come into a new development concept, the so-called SOA. SOA requires further implementation of the separation and decoupling of various application services or functions on the basis of hardware abstraction, so as to form an architecture that can support these application services to be flexibly invoked. At the same time, there are various views on the evolution of the vehicle architecture under SOA. Some believe that a unified central computing unit will eventually be needed, some believe that it will be divided into three domain controllers, and some think that it will be subdivided into more regional controllers and control units. Different hardware combinations have different topologies, and their appropriate development methods need to continue to be explored. At the end of the day, the goal of SOA is to turn all functions into application services, both low-level and relatively advanced services, which developers can freely invoke based on the SOA architecture. In this case, the software developer's understanding of the car can gradually decrease.
In the future, it is likely that software engineers can develop various functions of various models in a fully virtualized environment. They don't even need to know which model the software they're developing will be on, because all of the vehicle's hardware, including windows, doors, lights, etc., as well as power, chassis systems, etc., have standardized interfaces and application services. In other words, in the future we may be able to develop upper-level software that can run on any model. Although there is still a long way to go from such an ideal state, the pace of industry progress is accelerating step by step. Ultimately, this will revolutionize the capability needs and gaps for automotive software engineers.
In recent years, the scarcity and inward volume of software talent has been very serious, and companies are complaining about the "talent shortage". This is because the current industry has a relatively high threshold for software talents, who must be familiar with how many control functions of the car are implemented, and they cannot develop generalized software. However, I believe that with the further development of the industry, new development concepts and methods will be more and more applied, which will gradually reduce the requirements of the automotive industry for software talents.
Zhao Fuquan: Therefore, the highest realm and ultimate goal pursued by automobile companies should be to achieve the complete decoupling of software and hardware. At that time, software engineers only need to understand the basic functions of the hardware, and then describe it by digital means, and do not need to understand the principles and details of the hardware. However, at this stage, because the software and hardware have not been decoupled to this extent, automotive companies need talents who understand both hardware and software, which means that software engineers also have to learn some automotive knowledge, otherwise it is impossible to ensure that automotive software development can achieve the desired results. Of course, this is only a transitional state of last resort. Eventually, the industrial division of labor will certainly be refined to the full decoupling of software and hardware, but this may need to go through a fairly long process.
In addition, as Mr. Cao just said, some companies are currently trying new models of SOA in product development. Perhaps without an SOA architecture, "software-defined cars" cannot move to the next step, but this has not yet formed an industry consensus. At the same time, how to build SOA by enterprises also needs to be explored and practiced.
In any case, one thing is certain: hardware and software decoupling must be achieved in order for the value of "software-defined cars" to be fully realized. To this end, on the one hand, the entire industry should reach a consensus as soon as possible; on the other hand, all enterprises should have a long-term vision, work together in the direction of soft and hard decoupling, and strive to form a clearer and more refined industrial division of labor, so that professional people can do professional things. This is crucial for enterprises to form the core competitiveness required for the new era.
According to my observation, many car companies are still too concerned about whether a certain product in front of them can be launched as soon as possible, so they pull suppliers from various fields and try to quickly "save" new models, which is known as a highly integrated product. In the long run, however, this is not really the way to solve the problem. If the enterprise does not think systematically about the problem, how to build the entire architecture first think clearly, including how many resources are needed, how much they currently master, how much they must master in the end, how much they can hand over to others to master, how much the interface of the relevant hardware is, etc., then all the efforts of the enterprise are blind and short-sighted, and the subsequent products cannot be effectively accumulated, continuously inherited and continuously optimized.
Because of this, we often see this situation: some car companies have a product that is more successful and has a good intelligent effect, but it becomes worse when the next generation of products is launched. In the era of "software-defined cars", with the continuous accumulation of data and the continuous iteration of software, products should have been stronger than generations, but the actual effect is just the opposite. The reason for this is that enterprises have not thought clearly and made clear some fundamental issues. For example, the inheritance of software that is different from hardware is not enough, the two generations of products are created by different teams, and the integrated resources are different; at the same time, from the perspective of vehicle architecture, try to establish a cross-model software system. The result is that the development of each new car starts from scratch, with no accumulation and improvement at all.
A generalized operating system
Based on industry consensus, promote ecological construction
Zhao Fuquan: Mr. Cao, let's talk about the operating system that manages automotive hardware and software. Since hardware and software have their own developers, from the perspective of mutual collaboration, these developers will form an ecosystem with vehicle companies, which is the theme of our dialogue today, "Technology Innovation Ecology". It should be said that the automobile industry originally had a technical ecology, but before that it was only a simple linear structure, that is, the automotive industry chain composed of upstream suppliers, downstream dealers, and intermediate vehicle companies. Now that the situation is changing, in the future, the automotive technology ecosystem will have more participants and innovators to join, and present an intertwined network structure, forming an automotive ecosystem involving multiple industries, fields and levels. So, what role do you think the operating system will play in this ecosystem?
In addition, how should enterprises build a technological innovation ecosystem? I think it may be necessary to start with the most basic player, the vehicle company. However, many CAR COMPANY CEOs have said when communicating with me that they have a certain understanding of smart cockpits, automatic driving, etc., but they are not clear how to build a technology ecosystem. This is probably not a minority of people's confusion, and the industry's understanding of this issue is still relatively vague. Mr. Cao, can you share your views?
Cao Bin: Dean Zhao, your first question is about the role of the car operating system. In fact, operating systems have a narrow and broad meaning. The narrowest or lowest-level operating system is a microkernel operating system such as Linux, which can ensure that core hardware such as chips can run normally and complete the most basic work including memory management and hashrate scheduling. This is also what we usually call the role of traditional operating systems.
There are also operating systems in a broader sense or at a higher level, which integrate a series of important software that reflects the core attributes of the product, which can make the automotive product itself run effectively. For example, some car companies have established independent software companies with thousands of people, responsible for the software development of all their models. The various software provided by this software company, including both the operating system kernel, as well as various middleware and even application software, reflect the brand connotation and product characteristics of the enterprise. I think the collection of these software is the operating system of the car company.
That is, a broad operating system is a cross-model, hierarchical, highly complex integrated software package. In the future, if such an operating system wants to adapt to the switching of different suppliers and different hardware, it must be able to interact with the resources of the whole industry through standardized hardware and software interfaces. This brings us to the second question you just mentioned – how to build a technological innovation ecosystem.
For example, a car company can define a camera interface and data format. However, if the supplier only develops a specific purpose of the camera for the requirements of the car company, then it is difficult for the car company to replace it with other cameras, because its software cannot call the new camera at all; and it is also very difficult for other car companies to choose this camera, because its software is difficult to match. And there's a lot of hardware on the car, far more than just cameras, like radar, wipers, headlights, and so on. To this end, the vehicle company has to communicate with each supplier involved and agree on the interface of the relevant hardware. In this case, enterprises simply cannot obtain the support of industry-wide ecological resources; conversely, the ecosystem of the automotive industry cannot be formed.
To change this, companies must consider their own definition of hardware interfaces, component forms and architectural patterns, can it become a common understanding of the industry? The so-called common understanding is the standard or specification that many vehicle companies and suppliers agree with, so that each company can apply its own advanced technology, develop its own excellent products, and finally combine these products to get a car. This result is the embodiment of the ecological effect, that is, each participant is under the common standard, effective division of labor, mutual cooperation, focusing on the soft and hard decoupling of their own responsibility for the technology and products, to provide effective support for the final vehicle product.
It can be seen that there is a premise for the formation of the future automotive technology ecology: that is, the industry has formed a basic and unified general consensus on the vehicle architecture, software layering and interface specifications. Of course, this consensus is not static. For example, the interface standard is defined based on the current hardware situation, and the future products will have new requirements, hardware will have new progress, and the whole supply relationship will also have new changes, so the interface standard also needs to keep pace with the times and continuously improve. Conversely, only with the continuous development of the ecology and the continuous practice of enterprises, the industry will have a clearer and more consistent understanding of the industrial division of labor and cooperation forms of hierarchical, sub-module, and sub-components, which is the construction process of the automotive technology ecology or developer ecology.
The mobile phone developer ecosystem is like a prairie
The car developer ecosystem is like a forest
Zhao Fuquan: Now everyone is also discussing, will the car developer ecosystem develop like the mobile phone developer ecology? We know that in the mobile phone ecosystem, there are a large number of developers who do not have a deep coupling relationship with the mobile phone industry, including small companies and even individuals, who are independent of mobile phone manufacturers, develop their own software, and then widely used on a variety of mobile phones. Will there be such a small company or individual among car developers in the future? Can they also not contact the car company directly?
Cao Bin: Personally, I think that such a picture in the automotive industry is still very far away. At least in the early stage or the first half of the industrial transformation, the car developer ecosystem should still be a relatively organized ecology composed of enterprises.
I think I can make an analogy to illustrate the difference between mobile phones and car ecology: the mobile phone developer ecology is like a grassland, the software is large and small, and the number of participants is huge. There are big apps like Tencent WeChat, as well as very small tool software or game software. Some small software may only be developed by two or three people, and it can also be very popular. This is the ecological model of barbaric growth on the grassland, and the participants work hard and do not affect each other. Appearing or disappearing is completely random.
The car developer ecosystem is more like a forest, at least for now, and I think it may be the same for a long time to come. Forest ecology is clustered, each participant or small group has its own organization, and cooperates and games with each other in order to survive and develop. Therefore, the competition in the forest is more intense than that in the grassland, and it is easier to form a certain order. A large number of participants work together in a co-constructed organization through mutually recognized business relationships. Relatively speaking, this is more like the PC ecosystem, but it will be more orderly and richer than the PC ecology.
As for whether there will be individual developers in the future, it is difficult to judge now. After all, the development of automotive application software has a high threshold: on the one hand, because of the personal and vehicle safety involved, the reliability requirements for products are very high, and it is far less easy to obtain certification than mobile phones; on the other hand, the knowledge system involved is also very complex. For example, in the process of software development, we can abstract the data, but we still need to understand the logic behind the data, so we must master the relevant knowledge and receive professional training. Obviously, these two thresholds are difficult for individuals and small teams of developers to cross.
However, it should be emphasized that this does not mean that individuals cannot participate in automotive product development. The customized development of future automobiles will make products truly have the ability to meet the individual needs of users, that is, to achieve the so-called "thousands of cars and thousands of faces, thousands of faces", which is also the inevitable result of this round of automobile industry reform. For enterprises, of course, they hope that the automotive products they have created can fully match the preferences of users, and it is undoubtedly the best way to define the attributes, scenarios and behavior patterns of automotive products based on the needs of users. To this end, in the future, enterprises will definitely use big data analysis, human-computer interaction and other means to allow the majority of users to participate in the process of automotive product development.
Of course, the work of obtaining and meeting the personalized needs of users is itself very professional, and involves various levels of software and hardware, or should be handed over to professional companies to complete, which is also the work that Neusoft Ruichi is committed to doing. At present, we are working with some car companies to build related systems, so that users can use mobile phones or car machine systems to customize more and more vehicle functions and behavior patterns in the form of human-vehicle interaction; even after the delivery of the vehicle, users can also independently carry out some combination of services to make the vehicle have new functions and features. We are working intensively on this system, and it is expected to be unveiled on some models next year. I think it's a better way for individuals to participate in the car ecosystem.
The premise of car customization
Ensure that there are no functional safety risks
Zhao Fuquan: Giving users greater freedom to participate in automotive product development and thus achieve the ultimate experience is one of the industry changes we are most looking forward to. However, I feel that your view on this is not too optimistic. It is an indisputable fact that you think that the driving of a vehicle will involve many safety issues, whether it is hardware or software, which has much higher requirements or thresholds than mobile phones. But what about features that don't have a strong correlation with security? For example, sunroof, air conditioning, interior lighting and other parts directly related to the user experience, can not allow users to directly participate in the development of related application software?
Cao Bin: There is a technical term in the automotive field called functional safety, that is, a function is not allowed to cause injury, or it must be avoided due to functional failure or improper use, resulting in injury to the occupants of the car or people outside the car. In fact, almost all dynamic parts of the car, such as windows, sunroofs, seats, etc., are functional safety components. Because once there is a failure, failure or improper operation, it can cause serious consequences.
Zhao Fuquan: Functional safety is more from the perspective of component quality and reliability. The function that can be personalized directly by the user will certainly not conflict with functional safety. For example, when I smoke in the car, the sunroof opens automatically. At the same time, user needs are diverse, there may be users who need this function, some users do not need, and even like the opposite function - when I smoke in the car, I have to close the sunroof.
At the end of the day, it is the responsibility of the enterprise to ensure functional safety. So, why can't companies do a better job and more fully in the process of product reliability development and verification, so as to provide users with more room for personalized customization? At the very least, it should be ensured that the reliability of the hardware does not hamper the software developer, or does not affect the possibilities and freedom of the "software-defined car".
If those functional parts that have a greater impact on the user experience can only be developed in accordance with the previous traditional way or through simple human-computer interaction, and users cannot be personalized and developed according to their own preferences and experiences, will this hinder the full play of the self-evolution ability of future cars? Also deviates from the ultimate pursuit of "cars understand people better"? If it is worried that the professionalism of users is not enough, then why can't enterprises build corresponding platforms, let users complete personalized development through this platform, and then test, verify and approve by enterprises?
Cao Bin: The user needs you just mentioned, such as the sunroof automatically opens as long as someone in the car smokes; or when it rains outside, the sunroof automatically closes. I think such functions should be provided by car companies and do not need to be developed by users themselves.
And then you're really talking about product development boundaries, which is a very challenging topic. That is, where is the right boundary for users to participate in automotive product development? At present, many vehicle companies are exploring this aspect and trying to build corresponding capabilities. The basic logic of this ability is that through the standardization of hardware and its functions, users can make certain customized choices and form a suitable development method.
In this process, the software system also needs to be further improved, and we are now helping some car companies to build such systems, methods and capabilities. For example, it presents a very easy-to-understand graphical environment to the user, which is a bit like building blocks for users to select and combine functions. Neusoft Ruichi is developing such software systems and platforms to ensure vehicle safety, so that users can get the desired service through simple operations on the mobile phone or the car side. At the same time, the system will also record that the user has started a function in a certain scenario as a follow-up priority. I think this interactive environment will be possible in the next two or three years.
To be clear, the combination chosen by the user is not an app in itself. In other words, a true combination of applications and functional implementations also requires a series of support from back-end systems. And it can be listed, allowing the user to define the combination of scenarios, functions and services, must be determined that there is no security risk. This may be a bit disappointing: the original user's customized space is not arbitrary. But this is a basic principle that must be observed in car building, that is, all new combinations on the car must be verified, so as not to bring safety hazards. In other words, the behavior pattern of the car and its results must be predictable, and if not, the user should not be left to choose.
Car customization
Let the user's choice space is larger, the operation is simpler
Zhao Fuquan: I think that there will definitely be a lot of applications similar to mobile phones on the car in the end, which can combine some functions that directly affect the experience. For example, I know best how the air conditioner wind blows to be comfortable, or I want to combine the way the air conditioner blows the air conditioner with the music played, which are the personalized needs of users in the process of using the car, and cannot be preset in the car development stage. At the same time, companies can choose features that do not involve car safety to be open to users. Conversely, if these functions are not open to users, or if the relevant capabilities are not ready, then the future of automotive products will be similar to today's automotive products. We have exchanged here, and it feels like you, as a software expert, are more conservative than I am an old car expert?
Cao Bin: I think it will be a gradual process. By the time individual users can develop application software to control car air conditioning, it means that the vehicle's software system has developed to a fairly high level. To reach such a level, it is necessary to accumulate, iterate and optimize for a long time. During this time, a group of independent automotive application development teams or organizations may emerge. They will provide some standardized tools so that ordinary consumers can also deeply participate in the application development of automotive products, and then hand over the developed application software to the car company, who will ensure the safety, reliability and quality of the software.
For such a model, I personally do not think it is conservative. On the one hand, most of the functions on the car should still be implemented by the car company; on the other hand, the part that can be given to the user to choose, of course, should be as open as possible for the user to choose. But this customization should be achieved in a convenient way through human-vehicle interaction. I think this is the embodiment of the car's higher intelligence to understand people. Because a highly intelligent system should not require users to know how to program, develop their own software, and even consider the verification of software in the car, and then be customized, so it is too troublesome, how to talk about intelligence?
The intelligence of the future car, especially the so-called understanding of people, must be the high complexity of automotive products, extremely rich in functions, so that automotive companies can maximize the ability to provide users with the services they may need, or present the attributes that are closest to the needs of users; at the same time, the car can continue to evolve and develop new services and attributes in the process of use. On the user side, it should be simpler and more convenient as possible.
Zhao Fuquan: Here we talk about the core issue of automobile customization, and it is also the misunderstanding of many people. Most people's understanding of customization is to open this development ability to individual users, because the individual needs of users are very different, and car companies cannot meet the different needs of each user in the product development stage. Cao always feels that users need a space that can choose independently, rather than to do software development on their own. This means that car companies need to decide which customizable options can be provided to users based on their understanding of user needs and full consideration of vehicle functional safety; at the same time, car companies must also form the ability to effectively interact with users and achieve the combinations selected by users. If this is done, companies can help users with customized development to meet the individual needs of users. As for whether the relevant application software is left to the user to develop, in fact, it does not matter, let alone should not become a measure of whether the enterprise has the ability to customize. I think this is a very important point of view, and it is also a major result of this in-depth exchange just now.
Cao Bin: I think the most important thing is that the future car must be able to evolve, and its software system can be constantly updated, so that the car can understand people more and more. To this end, auto companies should make full use of more data to accurately identify user needs; second, they should build a team with strong collaborative development capabilities in the background, so that after understanding the needs of users, enterprises can quickly react and let users feel that cars are becoming more and more intelligent. In this sense, intelligent upgrading based on software systems is a main line for the development of the automotive industry in the future.
Never let the user
Participation in automotive product innovation becomes chicken ribs
Zhao Fuquan: Now some car companies are already trying to open up certain components or functions on the car, let users participate in the design, choose the configuration by themselves, that is, the so-called C2B model; some car companies propose that users can develop certain application software, and then upload it to the vehicle company for verification and approval, and once approved, the function can be opened to all users. This is not only in the product development stage according to the needs of consumers by the enterprise to customize the design, but to leave an open port for users, so that they can directly participate in the development process of automotive products, but also can be endorsed by car companies, to all users. I think that's a big step forward.
However, according to what Cao just said, in the long run, this model seems to be unnecessary. According to your deduction, since the intelligence of the car has evolved to the point where users can quickly judge and meet any needs they ask, where is the need to involve users in software development? I don't know what you think of the above attempts of car companies?
Cao Bin: These attempts are undoubtedly beneficial in themselves. In general, there are two main innovative models in the direction of intelligent upgrading of automobiles. One is autonomous innovation, in which companies are usually very strong or are facing extremely complex technical problems; the other is open innovation, that is, companies bring in external forces to participate in innovation to make up for the lack of their own innovation capabilities.
Once open innovation is passed, the innovation ability of enterprises will become very powerful. However, open innovation is very difficult and requires good soil. On the one hand, behind this model, enterprises need to have a strong support for the architecture platform and related capabilities; on the other hand, external forces, especially users, must have sufficient space and enthusiasm to deeply participate in innovation.
For automotive products, due to the high safety and reliability attributes of the vehicle, the space left for external developers is not very large, or it is relatively small. In this case, if the scale and effect of open innovation is not enough to significantly improve vehicle capabilities and user experience, then engaging users in innovation may become a chicken rib. Because in order to open up the interface to users who can participate in product development, car companies must establish an architecture and platform that can provide corresponding support. If the benefits are insufficient, it is extremely difficult to change this architecture and platform later. Therefore, I suggest that car companies must think systematically and make prudent decisions in the early stage, so as not to bring serious restrictions to the future development of enterprises due to the wrong choice of direction and mode.
Zhao Fuquan: This begs a new question, in your opinion, how much value does an open innovation ecosystem have for the automotive industry? On the one hand, when the company's own innovation ability is strong enough to meet the vast majority of consumer needs, then for the remaining small part of the demand, that is, the so-called long tail part, the enterprise does not need to care, it is likely that these consumers do not belong to the target user group of the enterprise. If in order to win over these consumers, you have to make a lot of reservations on the product, and even affect the layout of the architecture platform, development interface and supporting capabilities, I am afraid it is not worth it. In this way, the significance of the open innovation ecology does not seem to be so great?
However, on the other hand, car companies themselves have enough ability to judge and meet the various needs of all consumers, and even have the ability to tap and create some needs that consumers have not put forward or thought of, which may never be an ideal state. When the car has not yet reached such a high degree of intelligence, why can't car companies help themselves improve their innovation ability to meet user needs through an open innovation ecology that allows users to participate in product development? In this sense, an open innovation ecosystem is not only necessary, but essential. What do you think about that?
Cao Bin: I think this has a lot to do with the stage of ecological development. For example, do we have the need and motivation to develop some kind of application on the phone now? I'm afraid that most people don't have it, because the mobile phone ecology is already very rich, enough to meet everyone's needs. In fact, compared with a few years ago, the current applications on everyone's mobile phones have changed a lot. 5 years ago, many people's mobile phone applications are different, each has its own choices and preferences; but today everyone's mobile phone application convergence is very strong, like social software is almost all WeChat, as well as short video, entertainment and game platforms and other application software, are also the mainstream of those.
It is not difficult to find that the providers of these widely used software are almost all large companies. Correspondingly, the living space of small companies has become very small. That is, when mobile phone systems become smarter and can provide more advanced features and superior experiences, the participation of individual consumers declines, or the open space for innovation is compressed. I think this is the inevitable result of the development of smart products to a certain stage.
So, how will the automotive innovation ecosystem evolve in the future? One possible path is to first go through the stage of various developers blossoming, and then some application developers will grow into giants in a certain field, and correspondingly, other small developers will gradually withdraw, and eventually form a general convergence situation. Personally, I think the more likely path is to launch high-complexity, high-reliability, and high-quality human-computer interaction software from the beginning by some heavyweight players, and soon dominate in various major areas.
My judgment is mainly based on two points: First, automotive products have high-value attributes, and consumers spend much more on cars than mobile phones, which ensures the enthusiasm of giant companies to participate in automotive innovation. Second, automotive products are extremely complex, the development and use cycle is long, the requirements for safety, reliability and durability are high, and small companies or individuals may not have enough ability and resources to develop such high standards of automotive software.
Of course, in the process of the development of the automobile ecology, there may also be an intermediate state of the above two paths. However, I think the probability is very small. And even if this happens, it is unstable, and new changes will definitely occur in the future. So at present, open innovation for individuals or small teams in the automotive field is indeed in a more difficult state. The previous mention of the automobile ecology is a forest-style ecology, which also means that the main participants in this ecology are vehicle companies and software and hardware suppliers, which are "trees" with a certain scale, rather than "weeds" with small volumes.
Zhao Fuquan: In fact, this is one of the most troubled problems for the leaders of the current automobile companies. Although mobile phones can be used as an important reference, they are very different from cars. At present, the mobile application ecology has been relatively mature after years of development, and there is a relatively clear development model and ecological pattern. However, for automobile companies, it may not be the best choice to compare with mobile phones or imitate mobile phones and refer to the path of mobile phone ecology to develop automobile ecology. We often say that strategically, we must first clarify "who I am." This "me" must be a car, not a phone. Therefore, the automotive industry should learn and learn from some practices in the mobile phone industry, but cannot "forget" to learn and learn, so I am afraid that it will eventually lose its way.
Speaking of which, I would like to tease out a few of the core points that have been made from previous exchanges.
First, in the future, hardware must be standardized and abstracted so that software can play a greater role. To achieve this, it is necessary for the industry to reach a broad consensus as soon as possible, and it also requires relevant participants to actively explore and practice. Even if we start with a small cooperation group of several vehicle and supplier companies, we should strive to move in this direction, because this is related to the core competitiveness of the company in the future. On the contrary, if the industry cannot reach a consensus and enterprises do not move forward, the progress of the entire industry will be hindered.
Second, the operating system is crucial. At present, people have various different understandings of the scope of operating systems, and I think that enterprises must avoid generalizing the concept of operating systems. At the same time, enterprises can consider developing their own operating systems, but it must be clear that if the self-built operating system does not have ecological support, it will be meaningless.
Specifically, operating systems must ultimately be shared, not exclusive. It is difficult for a single enterprise to support the operating system alone, because if only one enterprise is using this operating system, then each module must communicate with the supplier one by one, which is not only a complicated task, a huge workload, but also a high cost and difficult to sustain. In this way, even if the effect is good for a while, it will eventually fall into difficulties due to the inability to get the effective support of various resources in the industrial ecology.
Because of this, the operating system must be open to the entire industrial ecology. Vehicle companies can decide to focus on a certain part of the operating system according to their own goals, priorities and competitive strategies. For example, you can choose to do only the cockpit operating system, or you can form a 3,000-person software development team to try to do more parts of the operating system. But no matter how big and capable the company's software team is, it still needs to embrace the entire industry ecosystem. If you only pull the suppliers in your own system together to do the operating system, and do not push the operating system to more users and participants, it is difficult to build an industrial ecology, and it is difficult to have room for continuous growth and development in the future.
Third, the mobile phone developer ecology is grassland-style, while the car developer ecology is forest-like. Unlike mobile phones, cars have much higher safety requirements. Even apps that can be opened to users should be highly concerned about the potential risks of users participating in this part of the development. There are some application software, rather than open to users, vehicle companies are far more invested, by themselves or excellent suppliers to be responsible. That is to say, for the functions and services that users may think of and expect, auto companies should perhaps reserve 99% of them and try their best to do them well; the remaining and controlled parts are then left to users to choose or develop twice. That is, the less white space left for the user, the better.
In this process, car companies should truly form the ability to make automotive products understand people better, that is, as long as users have relevant needs, car companies can do it. Of course, whether to do it or not, it also needs to be measured according to the security risk and input-output ratio. Rather than saying that because car companies do not have the ability to develop the required functions for users, they simply open the corresponding ports and let users develop themselves, which is incorrect. What's more, allowing users to participate in product development will make the back-end system doubly complex and bring potential functional security risks.
This actually reflects two different product development ideas and methods. We may wish to make an analogy: one is to let consumers choose dishes or even cook their own dishes to solve the problem of difficulty; the other is to prepare 99% of the dishes that consumers may order in advance, and the remaining 1% are either ignored, or a small amount is left for individual consumers to do it themselves under the premise of quality control to meet their individual needs.
The future of car companies
Leave room for custom development for enthusiasts
Zhao Fuquan: General Manager Cao, you judge that the automobile ecology is not a grassland-style open ecology, but a relatively concentrated ecology of the forest. Such a powerful software supplier will have more business opportunities, according to the characteristics of the car product, do what they are good at, so that the car becomes smarter, more able to read the user and meet the user, rather than letting the user develop the desired function by himself. You think this is more in line with the particularity of the automotive industry.
For now, that may indeed be the case. However, in the future, when car companies have enough ability and grasp, should they open a part of the interface to users? After all, there are still ashes fans and enthusiasts among users, such as many enthusiasts who have modified cars now. So, do you think that in the future automotive innovation ecosystem, will there be room for individual consumers to participate in product development?
Cao Bin: I think that all goods with emotional attributes will eventually have a part of the space that belongs to enthusiasts, and in the future, auto companies should also leave a certain amount of customized development space for enthusiasts. However, this part of consumer demand must be niche, non-mainstream, and obviously different from mass consumers. Therefore, car companies can provide space for car enthusiasts to deeply customize or secondary development, and even open road tests such as automatic driving, but they need to have clear choices and limitations for users. I think it's entirely possible that in the future there may be car brands and products that are purely for enthusiasts. Because when the automotive industry develops to a certain stage, there will be companies that deeply cultivate different market segments. The enthusiast group that likes to design and customize the development of cars is undoubtedly a market segment with considerable potential.
Zhao Fuquan: Regarding the above topics that I exchanged with Mr. Cao, I believe that everyone has their own views and their understandings are also different, which is very normal. However, as a software expert who understands automobiles, Mr. Cao shares the views and insights we share based on years of experience in the field of automotive software, which will undoubtedly bring a lot of thinking and inspiration to everyone. This is also the purpose of inviting Mr. Cao to participate in this column - we are to openly and unspeakably discuss a series of core issues in the current development of automotive software innovation, so as to provide useful reference and guidance for the entire industry and various related enterprises. At present, the deepening of the transformation of the automobile industry is precisely the critical period for all kinds of enterprises to cross the sea and show their abilities. At this time, whether the company can forward-looking and formulate the correct development strategy is more critical than ever. This undoubtedly adds value to our dialogue today.
Automotive software layering
Base, middle, and upper layer application software
Zhao Fuquan: Let's discuss some of the details of automotive software, do you think automotive software should be divided into several levels? What is the relationship between them? What kind of enterprises should lead the software at each level? For vehicle companies, what part of the software should be focused on?
Cao Bin: The layering of automotive software has become clearer and clearer in the last one or two years. That is, the software is mainly divided into three levels, namely the basic layer part, the middle layer is the middleware part and the upper layer application part. Among them, the middle layer includes real-time systems and non-real-time systems. In addition, from the functional point of view, there can also be different systems such as automatic driving and infotainment. There are great differences between different systems and different models, but they can be broken down into the above three levels, which has been agreed in the industry.
Overall, we can liken software to a sapling whose growth requires three essential factors: sunlight, soil, and water. Among them, sunlight is the external driving force that promotes the growth of software. The "sunshine" of the software is its application part, the more widely used, the stronger the saplings, the stronger the vitality. Soil and water are about the intrinsic drivers of software growth. The "soil and water" of the software includes the appropriate organization and development team of the enterprise, as well as the relevant technical know-how (Know-how) of the enterprise.
Specifically, first of all, the basic layer software is a general component, mainly the underlying operating system. In the past, some car companies have had the idea of self-development, but now car companies have become more and more aware that this part of the component is generalized, should be widely used in many models of many car companies, and the more widely used, the better.
In fact, whether it is the underlying operating system or middleware, it is to provide support for the upper-level application, the purpose is to make the development of the upper-level application software more convenient, so that the hardware equipment and topology under the underlying software should be fully connected. I think that for the underlying layer software and middleware, it should still be developed by some independent vendors. This is not only because the professional ability of independent suppliers is stronger, but also because independent suppliers are more likely to cooperate with multiple car companies, thereby expanding the scope and scenarios of this part of software applications.
Secondly, the gradual improvement of software must be demand-oriented and application-led. Software will always have some defects and deficiencies of one kind or another, which need to be constantly iterated and optimized in the actual use process. Many software have experienced the stage of "adding pits" in the development process, that is, they have to fill the original vulnerabilities one by one. Only in this way can the software eventually move towards perfection and form its own advanced nature. From this perspective, the more applications the software touches, the faster it will be perfected.
Previously, some enterprises' operating systems or middleware have been recognized in the market, but many companies have not developed similar software. I don't think it's mostly a matter of talent or technology gaps between companies. The real reason is that the software of successful enterprises has been exposed to many applications, and there is an opportunity to continuously precipitate and effectively combine these applications, so that their vitality is getting stronger and stronger, and the trust of customers is getting higher and higher; in turn, this allows them to contact more applications, so that they can continue to optimize, and ultimately do better and better. So I think that software is a strong field.
Finally, for the future development of the automotive software industry, I have the following three judgments and suggestions: First, the basic layer software includes the operating system kernel, hardware driver software and proprietary software of specific hardware, etc., to connect and interact with the following chips and other hardware, this part of the software should be completed by the software vendor. Second, middleware will become more and more mature, eventually forming a set of widely used standardized software, combined with corresponding management tools and adaptation services. Third, vehicle companies should focus on creating upper-level applications. There are many types of upper-level application software, some of which are large, such as autonomous driving and intelligent cockpit systems, and some of which are specific to hardware or assemblies, such as air conditioning control. In the future, car companies should select key systematic applications and "small" applications with a wide audience for targeted development.
Here I would like to emphasize once again that the development of software is closely coupled with the organization, so we must attach great importance to the inheritance of the team; and only by continuously iterating and evolving can the software be better and better, grow and grow. If a car company can concentrate on developing a set of software, and then adhere to the application in the future several or even dozens of products, continuous improvement and optimization, then the competitiveness of this group of software will become stronger and stronger, and its advantages will eventually appear. On the contrary, if the car company focuses on the development of this function in a generation of products, and then develops that function in the next generation of products, it is always "doing one, losing one"; or just developing a generation of products, the next generation of products has changed to another team, without continuity and accumulation, this way of playing is impossible to really do a good job of software.
Fully abstract the hardware
The premise of effectively achieving a "soft-hard balance"
Zhao Fuquan: As mentioned earlier, in the era of "software-defined cars", the relationship between software and hardware will be much more complicated than in the past. In this regard, I specifically proposed the syllogism of the relationship between soft and hard a few years ago: that is, in the future development process of automotive products, we must first "separate soft and hard", and develop software and hardware according to their own laws and in different ways; then we must "combine soft and hard" to ensure that software and hardware can be seamlessly connected and flexibly combined physically; and then "hard and software integration", so that software and hardware can be effectively matched and integrated, and the overall best results are presented, which is also the highest realm pursued by new cars; and finally " Soft and hard balance" is mainly to measure the cost performance of the product to determine the appropriate hardware reservation strategy.
The premise of "hardware and software fusion" is that the unchanged hardware can provide effective support for the changing software, and any product must consider the cost, which involves another focus of the current industry's general concern - in the face of constantly upgrading software, how should the hardware be reserved? If the hardware reservation is insufficient, the follow-up will not be able to play its due performance, it is difficult to support the upgrade of the software; on the contrary, if the hardware reservation is too much, not to mention that it may not be able to do it, even if there is hardware with sufficient forward-looking performance, I am afraid that the enterprise will not be able to bear its high cost. Further, when the hardware is not enough or tends to age, should the software be upgraded? And how do you upgrade it? Mr. Cao, what do you think of this problem?
Cao Bin: Now some auto companies have implemented OTA (over-the-air download) functions based on software. This means that car companies can upgrade the software of the products that have been sold at any time to improve vehicle performance, which is also a major trend in the current development of the industry. However, in terms of OTA upgrades, there is still a lot of room for improvement and a lot of problems that need to be solved.
In fact, the principle of OTA upgrade is not complicated, but it is very difficult to operate in practice. Suppose there is a car company that has sold dozens of products in 10 years, so that the market has both models sold by the company 10 years ago and models that have just been released. How does the car company match all these models with a software system? And which model should be used as the benchmark for implementing OTA upgrades to software systems? Is the company's latest software system only upgradable on some models, while other models cannot be upgraded? To be honest, no vehicle company can clearly answer these questions, and this is the driving force for companies to continue to explore and practice.
Zhao Fuquan: This is also the value of our dialogue column - we ask key questions, fully discuss, and try to give answers in the collision of ideas for the industry's reference. Going back to the question just now, this is indeed one of the questions that I have been thinking about the most recently. Suppose a company launches a model and then continues to upgrade its OTA, but after a few years, the software system will not be able to upgrade due to the backwardness and aging of the hardware. At this time, users do not want to replace the new car, the enterprise will fall into the embarrassing situation of dilemma: if the product is no longer upgraded, it means that the model can not achieve the so-called "commonly used and new, the more used the better" in the subsequent life cycle, which will cause dissatisfaction among users; and if you want to continue to upgrade, how should the car company deal with the hardware that is not enough to support the software?
Maybe car companies will have to force upgrades to the latest version of software systems on aging hardware, but will the functionality and performance of vehicles get better or worse? Will there be a security risk? I feel that it is a good result that there is no obvious change in the car experience, and it is likely that the experience will decline, just like the old mobile phone will slow down when running the new system; and the mismatch between the new software and the old hardware may also lead to problems in driving safety. Speaking of which, what is the case when powerful software controls weak hardware? I don't know what Cao Zong has?
Cao Bin: Dean Zhao, this is how I see this question. First of all, the architecture and standardization of the current hardware are not enough to support the continuous upgrading of the software, and it is impossible to maintain strong compatibility at all times. For example, the models released by many car companies this year are different in terms of hardware architecture compared with the models released last year, including the type and quantity of hardware that software can call, and the computing power and characteristics of the chip are also different. In this case, if the car company wants to upgrade dozens of models in the future, its difficulty will increase exponentially. This is equivalent to adapting to dozens of models one by one for each new feature developed, and each car must be re-matched and verified.
Nevertheless, OTA upgrades are a must for car companies in the future. In order to reduce the complexity of OTA upgrades, as we mentioned earlier, enterprises must strive to standardize hardware, including the definition of chip characteristics in domain controllers; at the same time, we must build a future-oriented, sustainable hardware architecture platform, so as to provide a basic guarantee for the iterative upgrade of software. If the hardware layer is not done well, the software upgrade will only become more and more difficult, and even after a year or two, it will be difficult to sustain. Because if the software continues to advance and the hardware stagnates, the enterprise will have to accommodate the old hardware and maintain the outdated software version, which not only fails to reflect the advanced nature of the new software, but also has to pay a high cost. Even if the cost is not considered, when there are too many software versions that need to be maintained, the car company cannot cope with the resources and energy, and the result is likely to be that a car only does a few rounds of OTA, patches a small number of bugs (vulnerabilities), and then no longer updates. I think this is an important issue that car companies must face in the future, and its essence is how to effectively balance costs and benefits in the process of upgrading new cars.
With "Software First"
Clear the biggest barrier to iterative upgrades
Zhao Fuquan: Mr. Cao, is there a more feasible solution to this problem in the industry? After all, the layout of the enterprise today directly affects the results of tomorrow. If the leaders of the whole vehicle company ask you now, when the automotive hardware has aged or lagged behind in a few years and cannot support the new software system, how can you make your products "old trees blossom and new flowers"? How would you answer that?
Cao Bin: This is the fundamental reason why we proposed the "software first" model. Specifically, it is important to determine what the core parts of the software system are that need to be continuously optimized. Then this core part is completely abstracted, starting from the middleware, that is, SOA, the layer, to the basic layer of the operating system kernel, and then to the hardware architecture, layer by layer. The ultimate goal is that even though the hardware may vary greatly over time and in different models, the definition of the hardware architecture is still consistent as it steps up to the SOA service layer, so that any iterative updates to the upper-level application software will not encounter any obstacles. That is to say, the part of the software to be iteratively upgraded is developed based on the abstract concept of the software middle layer, the basic layer and the hardware layer, so that it can span ten years and dozens of models without problems.
For vehicle companies, this is something that needs to be deeply considered now. Neusoft Ruichi provides SOA and middleware services to car companies to solve this problem. We hope that the majority of car companies can reach a consensus on the point that the underlying logic of the software must be determined first and the standard software must be developed. In other words, the relevant software must be developed before product development, and the software system developed must not only be aimed at existing models, but also consider adapting to future models.
In the past, we always said that software should adapt to hardware, and in the future, we should emphasize hardware adaptation software. In the future, within the defined boundaries, whether it is the underlying hardware architecture or the specific hardware, such as chips from different manufacturers in domain controllers, the differences should be completely abstracted in each layer of software. This kind of abstraction has not yet been achieved, which is the biggest problem that currently exists at the level of vehicle architecture and should be solved as a priority. If the vehicle company recognizes this now, begins to systematically plan and forward-looking layout, and begins to build and establish a model for product development "software first", then in the future, there will be an opportunity to completely remove the biggest obstacle to software iterative updates, so that their products have long-term vitality and sustained competitiveness. In addition, based on this concept, enterprises can further think, if the performance of the software is not enough, how should it be solved? What if there is not enough space to carry resources?
Of course, this will be a gradual process. In fact, if you have to upgrade the software system to the OTA of the model that went into production 10 years ago, this will always be a problem, even in the current mature mobile phone field. In the future, automotive products will have higher and higher demand for computing power, and there will be more and more functions and algorithms, such as various AI algorithms such as neural networks, and the existing hardware computing power will certainly not be enough to cope. When the software "can't run" on the hardware of a car, the user will realize that the car can no longer be upgraded, and the product of this model is outdated. In this case, if the user chooses to continue to use this product, it may not complain that the car company no longer provides upgrade services.
Vehicle companies should provide a relatively fixed set of expression methods that are easy for consumers to understand in the product sequence, including the model model and its corresponding software version. For example, as software evolves, car companies will continue to release new models and software. At this time, the enterprise can explain to the user through the product model and software version number: the software of a certain model can be continuously upgraded within five years, and the main software can no longer be upgraded after five years; or models within five generations can continue to be upgraded, and models outside the five generations no longer support upgrades. If you can tell in advance, I believe that users can also understand.
Whether the software can be upgraded
Hardware life and its normal use should not be affected
Zhao Fuquan: Generally speaking, the design life of all parts of traditional automobiles is consistent. For example, if the design life of a certain model is 15 years, engineers will set the design life of the engine, transmission, body, chassis, etc. to 15 years. However, in the era of "software-defined cars", as you just mentioned, future software iteration upgrades are likely to fail to cover models that are 5 years old. Will there be such a problem - the original design life is 15 years of the model, but because the software can not be continuously upgraded, resulting in limited vehicle functions, and even can not complete the braking, steering and other basic operations, so that the service life of the car is much shorter than expected?
For example, a car that has been used for several years, the hardware of its braking system is still intact, but the brake control software can no longer be upgraded, and may not even be able to start and run normally, so that it will not cause safety hazards, and eventually make the whole vehicle have to be eliminated in advance? Even if there is no problem with the basic use of the vehicle, but the hardware is constantly aging, and can not be targeted adjustment through the software, so that the performance of the car is bound to decline, how to reflect the advantages of smart cars "commonly used and constantly new, the more used the better"? If this so-called "smart" car is a "short-lived ghost" to use, or it is no longer "smart" after a period of time, will users still favor and trust smart cars? Mr. Cao, how do you think this problem should be solved?
Cao Bin: First of all, the hardware involving the basic functions of the vehicle, no matter how intelligent the car is, cannot reduce its reliability and durability requirements. For example, chassis structural parts, body frames, power systems, brakes, steering mechanisms, etc., including doors, windows and other functional hardware, its life expectancy should be at least the same as traditional cars, or even longer. In this regard, I believe that the ability to update the software should not affect the life and normal use of the hardware. In other words, even if the software is not updated, it must be ensured that the hardware is useful and sufficient.
On the other hand, car companies should also strive to extend the time span that software upgrades can cover, so that the new features introduced on new models can also be implemented through software OTAs on old models, so as to provide the same experience for old users. To a large extent, the ability of car companies to upgrade OTAs for old models will directly determine the user's brand loyalty. Because users usually do not change cars quickly after purchasing a car; and in the whole process of using the car, users definitely want to enjoy more of the new features and new experiences brought by software upgrades. If car companies can do this, it will not only help to enhance the reputation and loyalty of users, but also have a strong promotion effect on the establishment of intelligent brand image.
Zhao Fuquan: For traditional cars, the power for users to change cars usually comes from the configuration and styling, because the new model will have better hardware and newer styling styles. Compared with the old models sold by future car companies, the new models sold by car companies are likely to be not much different in hardware, or even exactly the same, and users can get a better experience just by continuously upgrading the software. This gives the car the ability to "blossom new flowers from the old tree", which will completely change the business logic of the automotive industry.
Cao Bin: Yes, most of the automotive hardware in the future can remain unchanged, and there is no need to replace it frequently. At the same time, as we just mentioned, some key hardware related to the operation effect of software, such as chips and other key processor devices, will receive more and more attention from consumers in the future. For example, the computing power of central computing units, autonomous driving chips and smart cockpit chips has a great impact on vehicle performance, so consumers will certainly pay much more attention to these chips than before, and even some consumers may choose to buy because of advanced chips on a certain model. Obviously, car hardware like this needs to be constantly upgraded.
In fact, these key hardware related to vehicle function and performance will become one of the key evaluation indicators for the advancement of future automotive products. If these hardware is difficult to meet the needs of users, and can not be replaced separately, users may eliminate the old car and buy a new car, which is also a new consumption power. Overall, I think the future of car consumption will be more and more like the current mobile phone consumption. We know that the upgrading of processors and the expansion and capacity of memory will make everyone have the desire to change mobile phones; and the future of automotive products is likely to be the same. This also shows that under the trend of continuous upgrading of consumption, there will be more and more very delicate concerns for automobile consumers in the future.
Pluggable hardware mode
The challenge is enormous, and the replacement space needs to be strictly limited
Zhao Fuquan: Mr. Cao, pluggable hardware is also one of the topics that are currently exchanged in the automotive industry. In your opinion, what future automotive hardware can be designed to plug and unplug? How can these pluggable pieces of hardware support continuous software upgrades?
I think that hardware being pluggable and unattainable will be a big positive for software vendors. Imagine if the car is composed of non-pluggable hardware, even if the life of these hardware is very long, but because the follow-up software can not be continuously upgraded, or that the performance of key hardware such as chips can not support the software with higher computing power requirements, the result will inevitably lead to the loss of software empowerment of automotive products gradually backward, re-become unintelligent traditional cars, in the use of the effect and the current car is not essentially different. Conversely, if the hardware can be flexibly plugged in and out of replacement, software upgrades can be supported over a longer period of time, allowing enterprises to generate greater value in software investment. At the same time, in the future, perhaps the life of hardware will not need to be designed to be too long, which will help reduce the cost of the product. Mr. Cao, what do you think of this problem?
Cao Bin: As for whether the future automotive hardware is pluggable and replaceable, it should be said that the industry is currently discussing such a possibility. I personally classify it as a market segment, such as a model of autonomous driving controller, intelligent cockpit controller or the core processor and storage components in the central computing unit, etc., which can be replaced by plugging and unplugging, which will undoubtedly bring additional attraction to users. But doing so is also costly, and it may be more difficult to implement than using hardware such as chips from the latest models directly on new models.
Because the design and development of a model that can continuously replace key hardware for many years to come, it must be guaranteed that there will be no security problems, not only is the development extremely difficult, but also the development cost and component cost can not be ignored. I think there may be room for this type of technology in some market segments, such as on some high-end or high-life models.
In fact, I think that in the future, automotive products will increasingly have the attribute of fast-selling products. In other words, auto companies can expect users to choose to eliminate old cars and buy new cars because hardware such as chips cannot support the latest software systems. This is common in the mature FMCG market, just like smartphones today. As a result, the progress of key hardware will become one of the important driving forces for the upgrading of automotive products, which I think will definitely occur in the future development process of the automotive industry.
As for users who choose to continue to use the old car, there is no need to worry about the problem of hardware aging, the basic functions and performance of the car are still guaranteed. Because auto companies will definitely adhere to the quality of products, providing safe and reliable vehicles has always been the bottom line of the automotive industry.
Of course, car companies should also strive to make the new software can be applied more and longer on the old model, which will significantly increase the user's recognition and satisfaction with the car brand and products. The key to achieving this goal lies in the software capabilities of the middle layer, specifically, to build an SOA architecture that can be separated from specific models, and form a core team that can support long-term iterative software updates.
Zhao Fuquan: Although there is a lot of discussion about pluggable hardware in the industry, Cao believes that this model actually has many difficulties. So, can you please analyze in detail why the hardware pluggable model faces great challenges, even as much as developing a new product?
Cao Bin: Usually the development and testing of automotive products follow the "V-shaped model", that is, from the beginning of the design to the final finalization, it is necessary to first go through the step-by-step index decomposition from the whole vehicle to the system to the parts, and then go through the step-by-step test and verification from the parts to the system and then to the whole vehicle. The entire process is integrated, with high demands on matching and reliability at every level. Without going through the entire process, the safety of the vehicle cannot be fully ensured, or the certainty of vehicle behavior will decrease.
For pluggable hardware, the "V-shape model" must also be followed during development to fully verify what happens after the hardware is replaced. Theoretically, each pluggable hardware needs to complete the verification, coupled with the different combinations between multiple pluggable hardware, it is necessary to evaluate the various situations that may occur, and the amount of work and the difficulty of the work can be imagined. In addition, additional redundancy is required in case of compatibility issues after a combination of old and new hardware. All of the above things must be taken into account in a comprehensive and systematic manner at the beginning of product development.
Furthermore, there is a conundrum that must be solved: for traditional automotive products, the software can only be developed based on existing hardware. For automotive products where the hardware is pluggable and replaced, it must be ensured that the software can still run reliably after the subsequent replacement of the new hardware. But the new hardware may not be available now, so how to develop software based on the new hardware? That's actually the hardest part. That is to say, in the past, when designing a new car, it is only necessary to consider which hardware is currently used; in the future, it is also necessary to consider which hardware will be replaced in the future, and what the new hardware used to replace will look like, there is no way to know.
Zhao Fuquan: I think there are two situations here: one is functional hardware, such as brake pads, which will gradually age after a period of use, and then it will be replaced by a new one. This hardware replacement does not require additional verification, and in fact existing automotive products also exist. Another scenario is the pluggable replacement of critical hardware such as controllers, which is what we're going to talk about today. This part of the hardware that supports intelligence, after aging or backwardness, if you do not try to replace it with a new generation of hardware, the intelligent ability of the car can not be guaranteed. In this sense, even if there are many difficulties, I am afraid that car companies should also try.
Cao Bin: In fact, what we are talking about is the same, the pluggable hardware we are talking about does not refer to traditional hardware such as brake pads, but to hardware that is related to intelligence such as chips. The replacement of traditional hardware after aging is normal maintenance, and the new hardware replaced is exactly the same as the old hardware, but it is just an old replacement. However, this is not the case with hardware such as chips, and it is to be replaced with new hardware in the true sense of the word with different performance.
Usually we talk about the chip will not talk about aging, but about insufficient processing power, that is, it can no longer support the operation of new software well, so it has the demand to replace a new generation of chips. This replacement requires two prerequisites: one is to give birth to a new generation of hardware with superior performance, which will not be a problem; the other is that the old hardware can be unplugged, and then the new hardware or its modules can be easily and reliably inserted into the entire hardware architecture, that is, to achieve the so-called "pluggable". But what the specifications and performance of the new generation of hardware will be, enterprises do not currently know, so it is very difficult to make reasonable reservations in advance.
So, how exactly should companies build a vehicle architecture that can support pluggable hardware? I think that planning and reservation can only be based on predictions about the future development of related hardware such as chips. To be honest, it is not easy to think clearly about the development process of chips, especially various specific details, not to mention the need to consider the verification links at all levels in advance. The difficulty of this model is likely to be beyond imagination.
So I think that future pluggable hardware upgrades must be strictly limited, that is, several permissible replacements are specified in advance. Then the car company only for these changes, step by step disassembly, clear the indicators and their requirements, while determining how to verify. In addition, fully evaluate the incremental costs that allow these changes. Only in this way can the pluggable hardware have the possibility of really landing.
It should be pointed out that in this process, the increase in costs is inevitable. Because once the relevant hardware is set to pluggable, it will inevitably involve many mechanical, electronic components and software systems that are adapted to it. These mechanical, electronic components, and software systems must change design metrics based on potential changes brought about by pluggable hardware, and be developed and validated accordingly, which is bound to increase the cost of the product.
