Five Major Challenges Facing Software-Defined Vehicles

Introduction:

This article is excerpted from the “Software-Defined Vehicle Industry Ecosystem Innovation White Paper” published on November 10, which systematically elaborates on the five major challenges of software-defined vehicles, including:

1. Technical Architecture

2. Security & Privacy Protection

3. Organizational Processes

4. Business Models

5. Ecological Collaboration

This white paper was proposed by the Software Branch of the China Automotive Industry Association, jointly compiled by the Software-Defined Vehicle Committee and its member units as well as industry enterprises.

Reply 1113 to automatically download the full text of the white paper (a total of 102 pages).

Software-defined vehicles are an inevitable trend, and there is already a basic consensus in the industry. However, how to implement it and what key issues need to be resolved during the implementation process are challenges that every participating enterprise needs to face, recognize, and solve first.

With the gradual advancement of smart vehicles, the complexity of vehicles continues to increase, making the development complexity of smart vehicles increasingly difficult to manage. The main reasons affecting or slowing down the upgrade and development of the smart vehicle industry are as follows:

First: Increased Complexity from User Experience.With the development and popularization of intelligence, user driving experience is gradually expanding from traditional transportation tools to a third space, with the scenarios and functions of car usage greatly expanding, resulting in hundreds of thousands of combinations of scenarios and functions forming the increasingly complex smart vehicle system.

Second: Increased Complexity from Technological Advancements.For example, the pursuit of higher battery energy density and fast charging capability has brought serious battery safety challenges; the evolution of artificial intelligence, 5G communication, cloud computing, and other data-driven technologies towards intelligence also significantly increases the complexity of software and hardware development.

Third: Increased Complexity from Competition.The competition has led to an increase in the diversity and complexity of vehicle configurations due to the accumulation of options, configurations, and various customization modes.

Fourth: Increased Complexity from Regulations & Compliance.The intelligence and connectivity of vehicles provide smart and convenient experiences while also introducing serious security issues such as hacking and data abuse.

For traditional automotive industry chain upstream and downstream enterprises, what do these four reasons for increased complexity really mean? What are the specific impacts and challenges on the automotive industry? All these will lead to a future where the types and quantities of configurations, hardware, peripherals, and software for smart vehicles will increase by more than tenfold.

The large-scale introduction of software will bring five major challenges to the automotive industry:

First: Technical Architecture.Under the current architecture, any addition, modification, or update of a component will affect the entire vehicle. Taking the traditional communication matrix as an example, current modifications and configurations require N weeks of time. In the future, with the number of electronic and electrical software and hardware increasing by more than tenfold and the introduction of a large amount of software, what does that mean?

Second: Security and Privacy Protection.Full testing takes a long time and is costly. If some tests lead to missed checks, what consequences could arise? Especially if security vulnerabilities are hijacked by hackers, what impact would that have on the brand and user loyalty of the entire vehicle manufacturer?

Third: Organizational Processes.How should vehicle manufacturers establish an organizational structure that matches the software-defined vehicle development model? Faced with thousands of configuration combinations, thousands of experience scenarios, and tens of thousands of service and application combinations, which updates should be pushed to all users? Which ones should be pushed to limited users?

Fourth: Business Models.Faced with the disruption of traditional automotive supply chains and cooperation models by software-defined vehicles, how should the interests of all parties in the industry be distributed? How can they jointly expand the industry cake?

Fifth: Ecological Collaboration.The traditional automotive supply chain follows a linear model from Tier 2 to Tier 1 to vehicle manufacturers, but in the era of software-defined vehicles, new players such as internet companies, ICT technology companies, and even individual developers will emerge on one side, while vehicle manufacturers will find it difficult to meet consumers’ demands for constantly updated and personalized vehicles through traditional procurement and project models. Therefore, companies will innovate, research and develop, and supply products centered around consumers, breaking the traditional linear model and forming a networked collaboration. However, how to optimize the efficiency and cost of vehicle development through reasonable division of labor remains a challenge for the industry.

1. Technical Architecture.

1.1 Urgent Need for Improvement in Software-Defined Vehicle Technology

To transform and develop the automotive industry, collaboration among all stakeholders in the supply chain is required. Currently, vehicle manufacturers, Tier 1, Tier 2, ICT technology companies, etc., are proposing software-defined vehicle-related technology capability planning and solutions from different perspectives, with inconsistent technical focuses, and an industry-level technical collaborative plan has yet to be formed. As shown in the figure below, the current industry is still in the phase of promoting technical solutions.

Five Major Challenges Facing Software-Defined Vehicles

Figure 3-1 Technology Maturity Curve

From the perspective of vehicle manufacturers

The traditional “hardware product-centric” technical capability is gradually shifting to “software-hardware integration, with software products as the main focus,” requiring the completion of the vehicle’s electronic and electrical architecture upgrade, and planning technical capabilities based on the degree of R&D leadership and software capabilities.

This will generally form four models: Full-stack technology layout; Core area technology breakthroughs; Strategic collaboration with software companies; Deep binding with mainstream core Tier 1s.

Therefore, to form a long-term clear software technology capability development plan and corresponding technical capabilities and software ecological solutions, a certain exploration and validation period is required.

From the perspective of component suppliers (Tier 1/Tier 2)

Under the background of “software-defined vehicles and vehicle architecture upgrades,” existing product supply methods and technical capabilities face serious challenges and require profound adjustments. How to achieve integration with as many vehicle manufacturers’ technical solutions as possible and what key technical capabilities need to be reserved requires a certain exploration and validation period.

From the perspective of ICT technology companies

Software-defined vehicles are like “smartphones on four wheels” where the relevant mature technical capabilities on the mobile side can be directly referenced. However, there are certain cognitive biases and technical capability mismatches with other stakeholders, requiring a certain exploration and validation period.

The concept of software-defined vehicles has just reached a consensus in the industry, and all stakeholders in the supply chain are still in the exploratory reserve phase regarding software-defined vehicle technical capabilities. There are currently no successful cases in the industry, and lacking mature experience references, a large-scale attempt that chooses the wrong technical path will bring huge risks.

Since all stakeholders in the supply chain are basically at the same starting line, many new technologies found in the exploration of software-defined vehicles have been successfully applied in the consumer electronics field but have not yet been applied in the automotive field. Some chip product planning roadmaps do not meet the requirements of controllers and vehicle development plans; some operating systems, protocol stacks, and middleware are still in an immature state; the original electronic and electrical architecture does not meet the needs for rapid market response; and the original development processes and tools do not meet the needs for rapid iteration development.

To solve these problems, the entire supply chain, including vehicle manufacturers, component suppliers, software developers, chip manufacturers, tool vendors, ICT companies, etc., needs to work together.

1.2 Customization and Private Interfaces Cause Inefficiency and Waste in Development

The automotive industry itself has a large number of customized and private interfaces, and this inefficient and wasteful traditional development model continues to persist.

In software: Software customization will lead to a large number of interface adaptations, driver adaptations, repeated calibrations, and continuous adjustments of the communication matrix, resulting in low end-to-end software development efficiency and severe waste of human resources. In the traditional automotive era, this model could be maintained, but with the acceleration of vehicle intelligence, software will exhibit exponential growth, and a transformation of the software development model will be imperative.
In hardware: Hardware customization results in frequent customizations, harness customizations, repetitive DV/PV, certifications, etc., leading to high complexity and cost in end-to-end management. Frequent production line adjustments lead to waste of capacity, and switching models leads to a linear increase in spare parts and inventory. As the intelligence of vehicles develops, the requirements for hardware are becoming increasingly high. If this hardware customization model continues, the workload of hardware customization and the resulting software adaptation workload will be unimaginable, hence this hardware model also needs urgent optimization.

2. Security & Privacy Protection

2.1 Increasing Security Threats

The complexity of the automotive production supply chain and manufacturing process requires cooperation and participation from suppliers at all levels. If there is a security risk in one supplier link, it will affect the safety of the final consumer. How to build a comprehensive digital security protection system that spans the entire process involving R&D, production, supply chain, sales service, and consumers is a huge challenge for smart connected vehicles.

From the perspective of automotive industry development, in the future, an integrated network based on in-vehicle networks, vehicle-to-vehicle (V2V) networks, and vehicle-mounted mobile internet will achieve intelligent traffic management, intelligent dynamic information services, and intelligent vehicle control. With the development of the smart vehicle industry, the scope of security in the automotive sector will extend from functional safety to network security. The risks of network attacks on smart connected vehicles are increasing, posing security threats to society and lives.

Frequent security incidents in the automotive industry have led vehicle manufacturers to pay increasing attention to automotive network security. The higher the level of intelligence in vehicles, the more security attack surfaces they face. Under the backdrop of intelligence, no global vehicle manufacturer has been spared, with international first-tier brands such as Mercedes-Benz, BMW, Audi, Volkswagen, Toyota, Honda, and Hyundai all facing varying degrees of security attacks. Data security has significant implications for smart vehicles and even national security, and it is likely that more policies and regulations will be introduced in the future.

2.2 Technical Challenges of Network Security

First: The Wide Attack Surface of Smart Connected Vehicles.

The product form of smart connected vehicles determines that they have numerous attack surfaces and significant physical exposure. Wireless interface security alone involves WIFI security, Bluetooth security, cellular communication security, GNSS security, TPMS security, FM security, and more. Within the accessible range, there are also NFC security, USB security, OBD security, etc., that need to be considered.

Common network security risks faced by vehicle ECUs include:

In-vehicle networks currently mostly use CAN/CAN FD protocols for communication, while CAN/CAN FD has limited byte length, arbitration mechanisms, no source address domain, and no authentication domain, which pose potential network security risks;
ECU hardware may have readable silkscreen prints and exposed debugging interfaces, making it vulnerable to reverse analysis and other security risks;
The ECU firmware flashing mechanism has not undergone information security protection, which may lead to ECU firmware or configuration data being tampered with;
If sensitive data in the ECU (such as calibration data, virtual key data, map data, configuration data, etc.) is not protected by encryption storage and access control during storage and access, it may be tampered with or leaked, and tampered data may cause system functions to deviate from expectations, leading to other information security risks.

Second: More Vulnerabilities in Smart Connected Vehicles.

Vulnerabilities and defects are numerous, distributed across different devices, making them difficult to defend against. The wide distribution, high number, and hidden nature of vulnerabilities can be attributed to the iterative development of smart connected vehicle technology architectures and the rise of the software-defined vehicle concept, which is reconstructing vehicles at the software level.

The development of smart vehicles is driven by the application functions carried by smart vehicles and is inseparable from the development of electronic and electrical architectures. In the future, vehicle controllers will carry an increasing number of functions, and the information security status presented under different electronic and electrical architectures will also differ. At the same time, the complexity of onboard controllers is increasing, gradually resembling high-performance computers in the ICT industry, which may bring new information security threats and attack methods.

Smart connected vehicles, driven by smart driving technology, rely on a large number of smart sensors, algorithms, and cloud platforms. These infrastructures and functional units contain massive amounts of code to support operations. If any link encounters a problem, it will affect the secure and reliable operation of the entire chain. Therefore, the large-scale entry of software into the vehicle manufacturing industry brings opportunities while also posing significant security challenges.

2.3 Regulatory Requirements

In recent years, there has been increasing attention to the network security, data security, and OTA upgrade security issues of smart vehicles in China. Under the model of government guidance, industry promotion, and standard committee execution, relevant automotive safety standards have been actively developed. Progress has been made in the formulation of automotive network security standards, as shown in the figure below. On October 11, 2021, the National Automotive Standardization Technical Committee (SAC/TC114) released four national standards: “GB T 40855-2021 Technical Requirements and Test Methods for Information Security of Remote Service and Management Systems for Electric Vehicles,” “GB T 40856-2021 Technical Requirements and Test Methods for Information Security of Onboard Information Interaction Systems,” “GB T 40857-2021 Technical Requirements for Information Security of Automotive Gateways,” and “GB T 40861-2021 General Technical Requirements for Automotive Information Security,” which came into effect on May 1, 2022. The work of converting national standards for international automotive network security and upgrade management, R155 and R156, has also started.

Figure 3-2 Achievements in Automotive Network Security Standard Development

In terms of data security, there is significant attention from consumers and at the national level. On one hand, regulations on data security have been introduced successively, from the “Cybersecurity Law” to the “Data Security Law” to the “Personal Information Protection Law,” further regulating the management of automotive data security and the self-inspection system for network security.

On the other hand, data security capabilities are further focused, specifically reflected in:

Data collection and processing processes are traceable and auditable;
Further strengthening of regulatory requirements under Chinese laws and regulations and requirements for personal information processing;
Further strengthening research and regulation on communication security based on cryptography.

Figure 3-3 Relevant Laws and Regulations on Automotive Data Security

To support the implementation of the “Several Regulations on Automotive Data Security Management (Trial)” released on October 1, 2021, the National Information Security Standardization Technical Committee released technical document TC260-001 “Guidelines for Automotive Data Collection and Processing Security” on October 8, which specifies the requirements regarding automotive data transmission, storage, and outbound transmission outlined in certain provisions. The automotive collection data is defined as data collected through automotive sensing devices and control units, as well as data generated after processing; it does not include data transmitted to the vehicle for processing through other networks, such as data collected by mobile phones and other external devices or personal information collected by automotive data processors through offline means such as sales contracts.

Technical documents specify that automotive collection data is divided into external data, cabin data, operational data, and location trajectory data,

and requirements for different types of data are proposed.

For external data, requirements regarding anonymization of personal information, maximum storage time, and outbound transmission are proposed;
For cabin data, requirements regarding data transmission to the outside and outbound transmission are proposed;
For location trajectory data, requirements regarding maximum storage time and outbound transmission are proposed.

At the same time, technical documents clearly state that automotive manufacturers should be responsible for the data security of the vehicles they produce, and in addition to restraining and supervising the behavior of component suppliers in handling automotive collection data, they should also disclose the complete situation of automotive collection data transmission to users.

Building a vehicle-level security capability and mechanism to ensure that smart vehicles truly give consumers peace of mind and confidence is key to development. In the era of traditional functional vehicles, vehicles were isolated units, and vehicle manufacturers had strong functional safety assurance mechanisms but had little to do with network security and privacy protection, with no relevant experience to draw on. The era of smart vehicles urgently needs to build a comprehensive defense moat for functional safety, network security, and privacy protection.

3. Organizational Processes

3.1 Organizational Structure Reform

The organizational structure determines the product architecture; the type of system desired dictates the type of team to be built. The following is a schematic diagram of the organizational structure of vehicle manufacturers.

The main body of the vehicle R&D team is the R&D headquarters, with branches set up domestically and abroad. The organizational division of the R&D headquarters has two dimensions: one dimension is by vehicle model, divided into departments for passenger cars, commercial vehicles, buses, new energy vehicles, etc.; the other dimension is by vehicle function module, divided into departments for electronic and electrical, engine, transmission, body, etc., where software development is just a specialized module under the electronic and electrical department. Within the software development module, control units such as engine control systems, transmission control systems, and body control systems are developed independently by different specialized teams.

Figure 3-4 Schematic Diagram of Vehicle Manufacturer Organizational Structure

With the arrival of the software-defined vehicle era, the electronic and electrical architecture of vehicles is developing towards “domain centralization” and “centralized control,” and the boundaries between electronic control units are gradually blurring. Hardware is being merged, and software operates within the same control unit. Many departmental boundaries that previously existed within vehicle manufacturers have been broken, and as they move towards a centralized organizational structure, departmental boundaries have become very ambiguous.

Traditional vehicle functional software is holistic and system-level. Under the trend of software-defined vehicles, software architecture and forms increasingly emphasize layered decoupling, standardization, modularization, and openness. Modules have clearly defined standard interfaces, can be combined and expanded between modules, and can be provided by different suppliers. The emergence of numerous scenarios will spur new applications, necessitating that the software architecture possesses sufficient openness and robustness, allowing for high reuse and high extensibility for different scenarios. Central computing platforms/domain controllers typically deploy service-oriented software architectures, as illustrated in the diagram below.

Figure 3-5 Schematic Diagram of Service-Oriented Software Architecture

Therefore, stakeholders in the supply chain need to adjust their company organizational structures from a strategic perspective to establish a top-down driven, strategically aligned, cross-departmental collaborative platform software organization, breaking the original siloed organizational model divided by functional modules.

In the process of organizational reform, the decision-makers’ determination and stability regarding strategic investment play a crucial role. If decision-makers lack judgment about the development trend of software-defined vehicles, they will face many difficulties when encountering resistance to internal reform, potentially leading to abandonment.

3.2 Automotive Software Talent

Traditional vehicle manufacturers need to further enhance their control capabilities over software.

In the past vehicle development model, vehicle manufacturers mainly defined and accepted product functional requirements, while suppliers developed and validated software and hardware based on the requirements specifications released by vehicle manufacturers, delivering them to the manufacturers. In this process, vehicle manufacturers rarely participated in the actual development of component products, leading to their existing R&D teams being relatively lacking in software development capabilities.

Under the centralized electronic and electrical architecture, the complexity of software architecture has greatly increased. How different functional domain software models or codes are integrated into a single SoC or MCU, and how to carry out reasonable computing power allocation and optimization, as well as integrated testing and validation after fusion, are all technical challenges faced by automotive software developers.

With the introduction of chip technologies such as SoC, many software technologies from IT fields will be applied to vehicles, such as operating systems, SOA middleware, AI technologies, and complex Ethernet communication protocols, all of which demand higher software development capabilities from both vehicle manufacturers and suppliers.

Traditional vehicle manufacturers’ talent structures are primarily mechanical and power-focused. Currently, various manufacturers are actively introducing multidisciplinary talents in software engineering, artificial intelligence, IoT, autonomous driving, and electronic engineering to rapidly adjust the structure of their existing talent teams, increasing the proportion of software engineers to ensure competitiveness during the transformation towards software and product innovation.

The main reasons for the shortage of automotive software talent are:

Automotive electronic software development is a branch of embedded software, and the industry is relatively closed, with a narrow source of personnel, leading to insufficient talent reserves and high demand.

Automotive engineers need to cross fields; traditional automotive electronic and electrical architecture engineers and embedded software development engineers primarily focus on CAN bus communication, controller distribution and harnessing, vehicle physical topology, power, chassis, entertainment, AUTOSAR CP, etc. However, under the trend of software-defined vehicles, more ICT capabilities need to be integrated, increasing the demand for skills in Ethernet, TSN, SOME/IP, SOA, Linux/QNX, Hypervisor, AUTOSAR AP, etc. Software engineers from internet companies, while strong in IT software development capabilities, often lack automotive engineering and software skills in the field of automotive embedded hardware.

In summary, the industry lacks talents who understand both software and automotive technology, especially system architecture engineers, and automotive software engineers are in a state of shortage. Therefore, it is challenging to form a mature software development team by concentrating a large number of software talents in a short period.

3.3 Development Model Transformation

Traditional automotive software development adopts a V-shaped waterfall model, as shown in the diagram below. Due to the relative independence of each development part, there is often only localized optimization within certain parts, lacking a system-level and platform-level overall perspective, making it difficult to achieve overall optimization. At the same time, the development time of each part is inconsistent, and the sequential dependencies between parts can easily cause queue effects. If there is a delay in the development of a certain part, it will affect the overall development progress. Each stage relies too much on the outcomes of the previous stage, leading to high development costs and long cycles, which contradicts the requirements of software-defined vehicles for manufacturers to shorten product launch cycles, base products on consumer needs, support continuous iteration, and respond quickly to market demands.

Figure 3-6 Traditional V-Shaped Waterfall Development Process Diagram

In the context of software-defined vehicles, automotive software development will shift from the traditional waterfall development model to an agile development model. The agile development model facilitates close coordination and cooperation, minimizing management costs. Its flexible working mode allows development teams to interact closely with users, quickly meeting user needs in the form of minimum viable products, continuously innovating and iterating during use, and realizing continuous development, continuous integration, and continuous delivery, highlighting the advantages of software-defined vehicles.

Mainly reflected in:

Software Development Process

Traditional controller development follows a V-shaped development process, using the vehicle manufacturer’s requirements as input, considering information security and functional safety, and strictly adhering to the complete process of design, implementation, and verification, ultimately completing requirement acceptance with the controller as the object. This process helps ensure the complete realization of requirements. At the same time, the entire process also involves quality assurance, process, and after-sales departments participating in reviews and audits, forming a good quality management and assurance system. However, the entire process is relatively closed and does not meet the openness and extensibility requirements for rapid software iteration.

Delivery Methods

In traditional automotive software development, the development scenarios are clearly defined, and software is tightly coupled with hardware. There is no clear concept of “software delivery” for embedded software, as software is delivered together with controller hardware. From a technical perspective, application software is integrated and solidified with the foundational software, with clear unified release nodes.

With the advent of the software-defined vehicle era, “separation of software from hardware and software from software” is gradually becoming the main theme. Embedded software has truly transformed from a pile of “codes” attached to hardware into an independently sellable product; this product can continuously generate value throughout the vehicle lifecycle. From the technical perspective of embedded software development and validation, this trend requires software to be able to iterate quickly, continuously update, and continuously deliver.

Project Management

In traditional controller development, a relatively complete system architecture and software architecture are formed at the early stage of the project, which is then decomposed into software components, moving through detailed design to software development. This development model is suitable for the product form of controllers, relying on the complete accumulation of mature technologies.

With the characteristics of open architecture/continuous delivery in mind, agile has become the keyword for project management. As software delivery is no longer a fixed delivery node, software modules have opportunities for new additions throughout the vehicle’s lifecycle: modular software meets the conditions and scenarios for separate delivery, leading to iterative changes in the design/development/testing/validation nodes of the software, making change and continuous delivery the norm, which places higher demands on overall software project management.

In summary, the transformation of automotive software development from the traditional waterfall model to the agile development model presents huge challenges for the implementation of software-defined vehicles.

4. Business Models

4.1 Shift in Value Chain Division

Software-defined vehicles have brought disruptive changes to the division of labor in the industry chain. The changes in the roles of various stakeholders are illustrated in the diagram below:

Figure 3-7 Changes in the Division of Labor Among Various Stakeholders in the Industry Chain

In the past

Most vehicle manufacturers were responsible for defining the electronic and electrical configuration characteristics of the entire vehicle, describing the characteristics and functions of the vehicle model, and clarifying the visible automotive features that users could experience, such as “electric sunroofs,” “panoramic sunroofs,” and other features that enhance vehicle safety, like “anti-lock braking systems (ABS)” or “lane departure warning (LDW).”

In the traditional model, vehicle manufacturers coordinated various Tier 1 suppliers to develop products, assemble them into test vehicles, and complete product certification through a series of vehicle tests, leading to long change cycles. This complete reliance on Tier 1 has drawbacks such as inflexibility, low operational efficiency, and fragmented data, making it difficult to meet the demands for rapid feature iteration and market launch.

In the development of new electronic and electrical architectures, vehicle manufacturers hope to define requirements, functions, and standards from the top down. When defining the electronic and electrical configuration characteristics of the entire vehicle, it is essential to tell a good user story (User Story), clearly stating as a , I want to , so that can be achieved. Based on this, use case designs are completed, along with complex system and software designs, forming hardware and software requirements for each electronic control system, followed by separate procurement of software and hardware. Currently, there are generally two ways to implement electronic and electrical architecture: one is to establish cooperation with basic platform manufacturers, and the other is to develop independently and vertically integrate. Both methods will fundamentally change the supply relationship, and there is resistance to the transformation of the original traditional supply chain system.

In the future

The value chain where vehicle manufacturers, Tier 1, and Tier 2 each play their roles will be further disrupted. Tier 1 and even Tier 2 will deeply participate in the complex system and software design led by vehicle manufacturers. The influx of ICT technology companies, internet companies, and automotive software firms will flatten supply chain management, and the boundaries among various stakeholders in the industry chain have not yet been clearly defined. In the overall planning of software-defined vehicles, the top-level design of SOA, what parts should vehicle manufacturers be responsible for? What parts should Tier 1 be responsible for? These are challenges faced by vehicle manufacturers. If everything is done in-house, it will consume a lot of energy and financial resources; if everything is handed over to Tier 1 manufacturers, it will be difficult to form product differentiation. How to divide labor and clarify the boundaries between vehicle manufacturers and Tier 1 manufacturers is currently a challenge.

4.2 Transformation of Traditional Supply Chain Models in Automotive Enterprises

Traditional procurement models of vehicle manufacturers mainly organize, process, and tools around hardware, while the electronic and electrical architecture required for current and future software-defined vehicles is shifting from signal-oriented to service-oriented, leading to the decoupling of software and hardware and the transformation of supply chain collaboration models.

Vehicle manufacturers have already begun to consider key issues such as the Maker-or-Buyer strategy for software, procurement strategies, quality assurance, and organizational optimization, such as:

Which parts of the software value chain should be self-developed and controlled by vehicle manufacturers? Which parts should be provided by external suppliers?
How should vehicle manufacturers collaborate with suppliers to effectively ensure and control the maturity and completeness of software systems?
For software development, how should vehicle manufacturers adjust their long-term cooperative relationships and merger investment plans? How to expand partnerships with software suppliers and other partners?

4.3 Transformation of Industry Profit Models

In the traditional model, the automotive industry primarily makes money through car sales, and what users pay for is the vehicle itself, such as the engine, transmission, chassis, and cabin, with vehicle manufacturers profiting from the difference between material costs and vehicle prices.

Now, automotive hardware is becoming increasingly homogeneous, and the parts industry is becoming more transparent, leading to thinner profits for vehicle manufacturers.

In the software-defined vehicle era, the focus is no longer on hardware but on software. Vehicle manufacturers will register all services provided by vehicles in a service registration center, allowing all users, including corporate users, individual users, and ecological users, to subscribe to services through the service registration center. An example of service subscription is shown in the figure below. For example, through service subscription, users’ vehicles can have voice control functions, including controlling speed, lights, window raising and lowering, air conditioning temperature and airflow, etc. Voice control services can be purchased with a one-time payment or rented monthly. These functions do not require additional hardware installation, only the writing of code by software engineers, and software development can proceed without increasing costs, so as long as there is a good idea, the profit margins are limitless.

Figure 3-8 Example of Service Subscription

Vehicle manufacturers are transforming the aftermarket into a new profit growth engine through hardware pre-installation and service subscriptions. More and more vehicle manufacturers will sell cars at close to cost price and primarily provide added value to users through software, which will not only reduce consumers’ vehicle purchase costs but also allow users to enjoy the practical convenience of the Internet of Everything. The commercial model of vehicles is shifting from one-time pre-installation fees to continuous subscription fees in the aftermarket, and constructing a competitive profit model that truly brings commercial value is a significant challenge, primarily reflected in:

1. The continuous monetization ability of the aftermarket needs further exploration.

Once software applications are implemented, the replication cost is negligible, and the profitability of software is entirely based on the existing software carriers (vehicles) and the proportion of users opting for optional software. However, the continuous monetization ability of the aftermarket still needs further exploration.

New automotive forces have great revenue potential but struggle to scale.The biggest issue is the low penetration rate of optional software, for example, the optional rate of Tesla’s FSD in the Chinese market is only 1%-2%;secondly, there is a significant gap between the user base of new automotive forces and traditional vehicle manufacturers.
Traditional vehicle manufacturers have a large number of brand supporters, making their business environment more favorable than that of new forces. However, due to the existence of user stickiness, traditional vehicle manufacturers must consider users of all age groups during the transformation process, and developing intelligent software that is easy for users of all ages to use is no easy task.

2. Balancing hardware pre-installation with cost pressure is challenging.

Although software determines product performance, hardware sets the ceiling for product performance; no matter how powerful the features are, they must rely on hardware for implementation. Therefore, to ensure that vehicles maintain their growth attributes over time, more hardware devices need to be pre-installed. However, traditional vehicle manufacturers’ business models rarely consider future upgrade needs, and under the enormous cost pressures of competition, it is challenging to reserve chip computing power, storage space, and redundant modules for future upgrades, as they typically only meet current functional requirements.

3. Challenges in transforming software product thinking.

The new business model will focus more on the personalized and experiential functional needs of drivers and passengers. This transformation will occur at the front end of product development, requiring more product managers who understand user experience to define relevant functional requirements based on the characteristics of different consumer segments. However, these product managers often have limited knowledge of automobiles, making it difficult for the functions designed to be practically implemented.

How to build a competitive business model that forms large-scale continuous monetization and how to choose a sustainable evolving software architecture to support future additional features or on-demand services are still in the embryonic stage.

5. Ecological Collaboration

In the field of new electronic and electrical architecture, most vehicle manufacturers and suppliers are currently focusing on platform infrastructure construction, such as the development and implementation of new architecture hardware, software middleware, SOA architecture, and atomic services. In the long run, once the SOA architecture and the general vehicle operating system construction mature, a rich upper application ecosystem will be the key to future value growth, possessing immense imaginative potential. The core of creating a rich application ecosystem is to build a prosperous developer ecosystem. Using the developer ecosystem data from the smartphone industry in China as an example, see the table below.

Table 3.2 Statistics on the Ecosystem Data of the Chinese Smartphone Industry

Figure 3-9 Business Models of Developer Platforms in the Smartphone Industry

Some vehicle manufacturers and component suppliers have already begun to layout and build automotive application software developer ecosystems. However, compared to the smartphone industry, the challenges for the automotive application software developer ecosystem are greater, mainly reflected in:

First: The lack of unified standards and interface specifications among vehicle manufacturers.

Automobiles are highly customized and non-standard products; the software and hardware interfaces designed under the electronic and electrical architectures of different vehicle manufacturers vary, and all are developing their own automotive operating systems, service interfaces, and development toolchains. This means that deploying the same application across different brands of vehicles may require extensive development and adaptation work, leading to high application development and deployment costs, which may affect developers’ willingness to participate.

Second: The limited scale and user base of individual vehicle manufacturers make it difficult to attract a large number of developers.

The user numbers of individual vehicle manufacturers are limited; most domestic manufacturers sell fewer than 2 million vehicles per year, and small manufacturers may have fewer than 100,000 vehicles. Coupled with the previously mentioned differences in standards and interfaces among manufacturers, this means that the user base accessible for a single application development and deployment is limited.

Third: The high professional requirements for automotive software development and the long time to see results.

As a product with high safety attributes, automotive applications require developers to have strong professional knowledge backgrounds. The applications developed must ensure that they do not compromise functional safety and information security requirements, necessitating lengthy testing and validation before they can be deployed in vehicles.

Click to read the original text at the end of the article to download the full white paper.

Five Major Challenges Facing Software-Defined Vehicles