1. Automotive Intelligence Drives the Arrival of Software-Defined Vehicles

Looking back at the history of automotive development, the automotive industry has evolved from the mechanical era to the electronic era, and is now moving into the software era. Since the 1980s, ECUs have been continuously installed in vehicles, with the automotive industry centered around Tier 1 suppliers increasing ECUs to enhance vehicle functionality. During this process, automotive software has developed in a way that is deeply coupled with hardware; nowadays, the hardware configurations of different models produced by various automotive companies have gradually become similar, with limited room for cost and functionality improvements. As new energy and intelligence gradually achieve success, automotive software has begun to become a core element for automakers to create differentiation, leading the industry towards the era of Software Defined Vehicles (SDV).

The entire automotive industry is transitioning towards intelligence. Unlike traditional cars, intelligent vehicles can create rich perceptible value and a more comfortable driving experience for owners through new software technologies. In recent years, an increasing number of automakers, component manufacturers, and tech companies like Google, Apple, and Baidu have started investing in the research and development of intelligent vehicles, allowing intelligent cars to rapidly seize market share. For example, in terms of autonomous driving features, major global car manufacturers are intensively developing Level 3 and above autonomous driving, and the future rates of autonomous driving adoption and levels will continue to improve.

The intelligence of vehicles will drive explosive growth in automotive software development demand. The software code volume of a “digital” car (2015) can reach 100 million lines, far exceeding the code volume of high-tech products like Facebook, fighter jets, and artificial satellites. With the development of intelligent cockpit, autonomous driving, and other intelligent modules, the volume of automotive software code is still increasing at an annual growth rate of over 20%. The code volume of an intelligent car produced in 2025 is expected to reach 700 million lines, an increase of 2.3 times compared to 2020. It can be seen that the technological barriers in automotive manufacturing have shifted from the traditional three major components and the integration capability of parts to the capability of code development. As automotive intelligence continues to upgrade and the software ecosystem gradually flourishes, the demand for automotive software development will explode, and the proportion of software costs in the overall vehicle costs will significantly increase.

The automotive software market size will continue to expand. According to Berylls Management Consulting, the global automotive software market is expected to grow more than threefold from 2020 to 2030, with an average annual growth rate of 13%, increasing from 76 billion euros to 252 billion euros. Specifically, the intelligent driving sector (ADAS/AD) will occupy the largest share of the automotive service market growth from 2020 to 2030, and software platforms, safety, and integrated testing and validation will also see high compound growth rates. However, the fastest growth will be in high-performance computing platforms (HPC), which are expected to reach 37%. If we further break down the overall market increment, the core increment (approximately 210 billion euros) comes from the increased complexity of intelligent functions, while the efficiency improvements brought about by software modularization and changes in development methods will also reduce development expenditures by 62 billion euros.

1.1. EE Architecture Upgrade is the Hardware Foundation of Software Defined Vehicles

Intelligence and connectivity must be built on the core computing power of the electronic and electrical architecture. Without a hardware foundation, software-defined vehicles cannot be realized. The transformation of automotive EE architecture is mainly reflected in the following four aspects:

Computing Performance: Automotive chips are shifting from MCU to SoC. MCU chips typically contain only one CPU processing unit, storage, and interface units, with computing power generally only a few hundred DMIPS; whereas SoC is a system-on-chip, generally adopting a “CPU + AI chip (GPU/FPGA/ASIC)” architecture, such as NVIDIA’s Orin X with computing power reaching 254 TOPS. Intelligent cockpits and autonomous driving have brought a magnitude of improvement in the intelligent architecture and algorithm computing power required for vehicles. Chips based mainly on MCU will no longer meet these needs, and the shift is towards more powerful SoC chips.

Communication Bandwidth: In-vehicle Ethernet is becoming the backbone communication network of vehicles. In traditional distributed architectures, communication between ECUs is mostly done through CAN communication, LIN communication, Flex Ray, etc., with very limited data transmission speeds, generally only a few megabits per second. As the number of sensors in vehicles increases, the volume and speed requirements for data transmission will significantly increase. In the future, in-vehicle Ethernet will become the backbone network of vehicles, achieving transmission speeds of 100 Mbit/s, or even 1 Gbit/s over a single pair of unshielded twisted pairs.

Soft-Hard Decoupling Realizes OTA Upgrades. Software is no longer developed based on a fixed hardware platform. The original ECU software’s silo-like vertical architecture has transformed into a horizontally layered architecture of general hardware platform + basic software platform + various application software, achieving soft-hard decoupling. Hardware is pre-embedded, and software is deployed later, enabling continuous OTA to realize software function iterations and promote overall vehicle function upgrades.

Better Cost Control. Currently, in high-end models and highly intelligent models, the number of main ECUs can exceed 100, and when adding some simple function ECUs, the total number can exceed 200. The increase in ECUs and corresponding wiring harnesses leads to cost increases. Through domain control integration, the number of ECUs can be significantly reduced. Additionally, since ECUs are provided by different suppliers, any functional modification involves re-developing and validating multiple controllers, which is time-consuming and labor-intensive. Moreover, the software logic is controlled by the suppliers, and the OEM cannot efficiently manage the software functions.

Under the trend of intelligence and connectivity transformation, software and hardware are decoupled at the component level, with software becoming an independent core component product. The multidimensional vehicle data and control permissions obtained by automotive software enable complex functions and task execution. As automotive software becomes increasingly complex, the number of lines of code is rapidly increasing, gradually forming a system OS and application software architecture, thereby increasing the difficulty of automotive software development.

1.2. SOA is the Software Trend of Software Defined Vehicles

Under the traditional distributed EE architecture, the operation of automotive software is mainly based on signal-oriented architecture, which cannot meet the needs of intelligent vehicles:

Fixed architecture lacks flexibility. The coding of each ECU function is predefined in the ECU ordering file during the architecture design phase, and they are called and executed one by one during operation. The signal transmission relationship between ECUs is static, with signals only being forwarded by gateways, lacking flexibility. Additionally, this fixed software architecture limits the demand for personalized development by users, and external developers cannot define new functions through software, nor can it support online upgrades and software iteration.

Signal-oriented architecture cannot achieve vehicle-human interaction. Signal-oriented architecture only supports receive and send modes, not request and response modes, and cannot achieve interaction, which prevents the characteristics of intelligent vehicles from being fully utilized.

In a distributed architecture, software and hardware are highly coupled, and software operation relies on hardware. When software changes or upgrades occur, the entire vehicle must undergo integration verification, which is time-consuming and difficult. Moreover, if a certain controller has a problem, the corresponding functions may also fail, leading to increased costs and significant safety issues under intelligent cockpit and autonomous driving intelligent functions.

The cost of modifying software functions is high and difficult. Under the traditional signal-oriented architecture, if a software function needs to be modified, the entire vehicle communication system and ECUs must change, and the dramatic increase in the number of ECUs significantly raises the cost and complexity of this process.

SOA divides different functions and hardware capabilities at the vehicle end into services and breaks down services into smaller granular interfaces based on the vehicle’s atomic capabilities. The interfaces of each service component are standardized and encapsulated, allowing mutual access and combination through established protocols; the core elements of SOA include loose coupling, standardized definitions, and software reuse. SOA allows application layer functions to be reused across different vehicle models and can quickly respond to new functional demands from users based on standardized interfaces. When software engineers modify or add a certain software function, they only need to write code for the corresponding service component at the upper layer without needing to recompile and redevelop the basic software layer, runtime environment layer, and other software components, greatly reducing the complexity and cost of software upgrades and improving efficiency.

In the long term, automotive companies will introduce a large number of algorithm suppliers, software developers, and service providers to jointly build SOA, providing a high-quality operating platform for intelligent automotive software and offering comprehensive software services to customers. Therefore, major automotive companies are gradually shifting their focus to collaborative development of SOA, and it is expected that the next five years will usher in a peak period for the mass production of SOA.

Of course, it is important to recognize that the ideal SOA development is relatively costly, and inter-process communication (IPC) across ECUs is certainly more complex than IPC within ECUs, requiring additional interface packaging, which will increase additional scheduling and computing resources. These costs do not directly enhance user experience. Therefore, SOA architecture will not be achieved overnight.

2. Automotive Software Architecture

Intelligent automotive software is divided into three layers of architecture: 1. The underlying system software layer, including BSP, virtual machines, system kernels, middleware components, etc.; 2. The functional software layer, including library components and middleware, located above the operating system, network, and database, providing the operating and development environment for application software, helping users flexibly and efficiently develop and integrate complex application software; 3. The upper application algorithm software layer, including intelligent cockpit HMI, ADAS/AD algorithms, networking algorithms, cloud platforms, etc., used to actualize vehicle control and various intelligent functions.

2.1. System Software Layer – Narrow Sense Operating System

The automotive operating system is the underlying layer that manages and controls the hardware and software resources of intelligent vehicles, providing the runtime environment, communication mechanisms, and security mechanisms. Depending on the degree of transformation and capability depth of the underlying operating system, it can be mainly divided into the following types:

Basic operating systems: such as QNX, Linux, WinCE, etc., which include entirely new underlying operating systems and all system components, such as system kernels and lower-level drivers. Some also include virtual machines.

Customized operating systems: refer to deeply customized development on top of basic operating systems (including modifications to kernels, hardware drivers, runtime environments, application frameworks, etc.), ultimately achieving cockpit system platforms or autonomous driving system platforms, such as Volkswagen VW.OS, Tesla Version, Google Android Auto, Huawei Harmony OS, AliOS, etc.

ROM-type automotive operating systems: based on Linux or Android and other basic operating systems with limited customization development, not involving changes to the system kernel, generally only modifying and updating the applications that come with the operating system. Most automakers typically choose to develop ROM-type operating systems.

Super Apps: also known as vehicle-machine interconnection or mobile mapping systems, are not complete automotive operating systems in the full sense, but utilize the rich functionalities of mobile phones to map into the vehicle’s central control, meeting the owner’s entertainment needs, represented by Apple CarPlay, Baidu CarLife, Huawei HiCar, etc.

2.1.1. Underlying OS: Determines System Performance and is Key to Software Defined Vehicles

The operating system kernel, also known as the “underlying OS,” provides the most basic functions of the operating system, responsible for managing the system’s processes, memory, device drivers, files, and network systems, and is the core of the system software layer. Due to the highest development difficulty and safety requirements, its market competition pattern is relatively stable, mainly dominated by QNX, Linux, Android, and WinCE.

In the long run, the future market will see a triopoly of QNX, Linux, and Android. According to IHS Automotive data statistics, the system kernel currently mainly consists of QNX and open-source Linux, Android, with a combined market share of nearly 90%. In terms of system performance, the three major systems each have their advantages. Currently, QNX, with its high safety, high stability, and high real-time performance, firmly occupies the number one position in the market share of automotive embedded operating systems. Linux (including Android developed based on Linux) has a significant advantage over QNX in terms of being open-source, offering strong flexibility in custom development and high extensibility. In terms of applicable fields, QNX systems are more suitable for fields requiring higher safety performance, such as instrument systems and power systems, while Linux and Android are more advantageous in the in-vehicle information and entertainment field.

It is expected that the market share of Android systems will continue to rise. Compared to Linux, Android systems have a broader application in China and significant development space in the in-vehicle information and entertainment field, as Android is the best tool for connecting mobile internet content. Despite issues of security and stability, its open-source nature, strong flexibility, and rich ecosystem have allowed it to occupy a mainstream position in the domestic market, especially in the in-vehicle information and entertainment field, where safety requirements are relatively lower. Most domestic brands and new car-making forces are also based on Android to customize ROM-type automotive operating systems.

2.1.2. Leading Automakers and Tech Companies Enter the Operating System Space, Aiming to Establish Competitive Advantages

In-vehicle operating systems are key to the automotive ecosystem, and leading OEMs and third-party companies are actively laying out automotive operating systems. Among automakers, systems like Tesla.OS, Volkswagen Group’s VW.OS, Daimler’s MB.OS, BMW-OS, Geely’s GKUI, etc., are all based on Linux, QNX, and other RTOS kernels to achieve hardware abstraction, forming a middleware operating system that supports application development and defines developer interaction logic.

Self-developed operating systems help simplify the vehicle software development process and increase OTA frequency. For example, Tesla, by using an open-source Linux self-developed operating system, can no longer rely on software suppliers but fully master the stack, enabling quick fixes and upgrades through OTA whenever issues arise, enhancing user experience. Since first using a self-developed operating system in the Model S in 2014, Tesla has undergone multiple significant upgrades to its operating system through OTA technology.

Self-developed operating systems that open vehicle programming to industry chain enterprises can master developer ecosystem resources, forming a certain monopoly advantage. With an operating system, an ecosystem monopoly can be established, allowing comprehensive control over the upper-level components and applications. For example, Volkswagen’s self-developed VW.OS, relying on its nearly ten million annual vehicle sales, forces Tier 1 and software suppliers, even other OEMs, to develop based on VW.OS, making it akin to iOS in the smartphone domain, ultimately forming a business model of “OS licensing fees + IoT services + APP docking licensing fees + APP value-added service sharing,” generating excess profits.

Third-party automotive operating system players include TINNOVE, Zebra Zhixing (Tencent-backed), Guoqi Zhikong, Baidu, and Huawei, among others. These companies mainly develop independent operating systems based on mainstream underlying OS. From a technical perspective, internet and tech companies leverage their software development advantages to achieve a high degree of system transformation and have rich product ecosystems. Therefore, third-party enterprise products themselves have strong competitiveness, allowing them to cooperate with automakers that have a relatively singular ecosystem and inadequate development capabilities, forming a virtuous cycle.

From the perspective of cooperation with automakers, third-party companies actively collaborate with numerous partners. In 2016, Zebra Zhixing collaborated with SAIC to launch more than ten models equipped with the AliOS system, and in 2017, it collaborated with Dongfeng Motor. Huawei’s HiCar super app system currently collaborates with more than 20 automakers, including Volvo, Changan, Geely, Dongfeng, GAC Trumpchi, BYD, and more, with over 150 models.

2.2. System Software Layer – BSP Layer

BSP (Board Support Package) is the interface layer between the kernel and hardware, generally considered part of the operating system. BSP primarily includes Bootloader (the basic support code to load the operating system’s boot program), HAL (Hardware Abstraction Layer) code, drivers, configuration documents, etc. For specific hardware platforms, all hardware-related code is encapsulated in the BSP, which provides a virtual hardware platform to the operating system through defined interfaces, allowing it to run better on the hardware motherboard. Its purpose is to provide the operating system with a virtual hardware platform, making it hardware-independent and portable across multiple platforms.

BSP is relative to the operating system, with different operating systems corresponding to different defined forms of BSP. For example, the BSP of VxWorks and the BSP of Linux may implement the same functions for a certain CPU, but the writing methods and interface definitions are completely different. Therefore, writing BSP must adhere to the definition form of that system’s BSP to maintain correct interfaces with the upper OS.

Tier 1, OEM, and Tier 2 manufacturers all participate in the BSP market. However, due to the deep understanding of chip architecture required for high-end chip BSP development, the current market is primarily dominated by third-party companies closely collaborating with chip manufacturers, such as Thunder Software Technology. Thunder Software Technology maintains deep cooperation with leading chip suppliers like Qualcomm, Renesas, Texas Instruments, and NXP, having a profound understanding of the chips of related companies, and can represent chip manufacturers to provide BSP technical support for automakers/Tier 1 suppliers. (Report Source: Future Think Tank)

2.3. Virtual Layer (Hypervisor)

To allow different types of operating systems to run on a single computing platform, the most direct technical path is virtualization (Hypervisor). Virtualization technology can simulate a complete hardware system function and run in a completely isolated environment, allowing vendors not to design multiple hardware systems to meet different functional requirements, but rather to perform virtualization software configurations on the vehicle’s main chip, forming multiple virtual machines, and running the corresponding software on each virtual machine to meet the demands. Therefore, in-vehicle virtualization operating systems must meet the following three technical requirements: (1) Use resource partitioning technology to strictly isolate and allocate resources; (2) Have a flexible and efficient real-time and non-real-time task scheduling mechanism; (3) Inter-process communication to achieve messaging between virtual machines.

Currently, the main virtualization technology providers are QNX and ACRN. Common hypervisors include BlackBerry’s QNX, Intel and Linux-led ACRN, Mobica’s XEN, Open Synergy’s COQOS acquired by Panasonic, Continental’s L4RE, and VOSyS’s VOSySmonitor from France, among which BlackBerry’s QNX and Intel and Linux-led ACRN are the most mainstream. QNX is the only virtualization operating system recognized to achieve ASIL D level and has been mass-produced and applied in actual vehicle models. The entire operating system is a collection of processes managed by a microkernel, ensuring safety and real-time performance. Currently, BlackBerry’s VAI project in China has system integrators as partners, including Thunder Software Technology, Wuhan Guangting Information, and Nanjing Chengmai Technology.

2.4. Middleware: The Key “Link” in Software Development

Before the emergence of middleware, system software was developed directly based on the operating system, leading to a high degree of coupling between software and hardware. As the volume of in-vehicle code increases, the complexity and cost of systems surge. To improve the manageability, portability, scalability, and quality of software, it is necessary to define a set of standard interfaces, seamless integration of high quality, efficient development, and manage complex systems through new models. Middleware separates software and hardware, abstracts and utilizes lower-level hardware resources, drives chips, and optimizes operating systems, providing service interfaces for upper-layer software and different types of plugins for different algorithms. Middleware solves problems related to data transmission, application scheduling, system integration, and workflow management, significantly improving the development efficiency of application-layer software.

Classic middleware design standard: AUTOSAR. The automotive electronic software standard mainly includes AUTOSAR, OSEK/VDX, etc., among which the AUTOSAR standard has developed over ten years and has formed a complex technical system and a wide range of development ecosystems, being the mainstream design standard for automotive middleware. AUTOSAR specifies layered architecture, methodology, and application interface specifications, allowing developers of automotive embedded system control software to free themselves from dependence on hardware systems during ECU software development and verification processes, achieving software-hardware separation.

AUTOSAR’s entire architecture is layered from top to bottom as follows: Application Software Layer, Runtime Environment (RTE), Basic Software Layer (BSW), Microcontroller. To maintain independence between each layer, each layer can only call the interfaces of the next layer and provide interfaces for the upper layer.

The advantages of AUTOSAR mainly include: 1. It is conducive to improving the reuse of software, allowing software to be reused across platforms; 2. Facilitates the exchange and update of software; 3. Software functions can be defined and verified at the architecture level in advance, thus reducing development errors; 4. Reduces the amount of manual code and lightens the burden of testing and verification, improving software quality; 5. Uses a standardized data exchange format (ARXML), facilitating communication and cooperation between companies.

AUTOSAR is divided into two major platforms: Classic Platform and Adaptive Platform, where the Classic Platform mainly targets distributed ECUs, and Adaptive AUTOSAR mainly targets more complex domain controllers and central computing platform electronic and electrical architectures. Compared to Classic AUTOSAR, Adaptive AUTOSAR’s advantages lie in strong real-time performance, high portability of operating systems, and more flexible software upgrades.

AUTOSAR is the game rule set by traditional automotive industry giants, and currently has over 300 ecological partner companies. There are very few companies worldwide capable of developing a complete AUTOSAR architecture-based underlying protocol stack. The well-known AUTOSAR solution providers globally include ETAS (Bosch), EB (Continental), Mentor Graphics (Siemens), Wind River (TPG Capital), as well as Vector, KPIT (a US-Indian joint venture), etc. Most Tier 1 and OEMs need to purchase underlying software from the above suppliers. In China, the development toolchain and basic software under the Classic AUTOSAR standard are dominated by overseas suppliers, while major domestic players include Neusoft Ruichi, Huawei, and Jingwei Hengrun; in terms of Adaptive AUTOSAR, it is still in its infancy, with Continental EB collaborating with Volkswagen to apply the AP AUTOSAR and SOA platform to Volkswagen’s MEB platform ID series pure electric models. Domestic manufacturers are actively focusing on AP AUTOSAR, launching corresponding middleware and toolchain products to seize market opportunities.

In the entire AUTOSAR framework, the only part that truly has control is the Application Layer, while the other layers (RTE and below) play supportive roles. The functions of different Application layers correspond to the same basic software (BSW), and AUTOSAR requires software engineers to strictly adhere to standards when “writing”. This results in a situation where, under a distributed architecture, as the number of controllers increases, the number of lines of software increases, and the cost of software development rises. In the domain control architecture, even when ECUs and actuators still follow the AUTOSAR standard, it cannot significantly reduce the amount of code. Therefore, Tesla does not use AUTOSAR, relying on its self-developed operating system and basic software to achieve more efficient development.

On July 22, 2020, 20 companies, including FAW, SAIC, GAC, NIO, Geely, Great Wall, Changan, Beiqi Foton, Dongfeng, FAW Liberation, Xiaopeng Motors, Neusoft Ruichi, Hengrun, Nansen, Horizon, Suzhou Zhitu, Wanxiang Qianchao, Weimais, Zhongshu, and China Automotive Innovation, formed the China Automotive Basic Software Ecological Committee (AUTOSEMO), aiming to establish a basic software architecture standard and interface specification with independent intellectual property rights led by local enterprises, share knowledge results, and build an industrial ecosystem.

2.5. Functional Software Layer

In the automotive software architecture, functional software mainly includes core common functional modules for autonomous driving. Core common functional modules include general frameworks for autonomous driving, connectivity, cloud control, etc., which, combined with system software, form a complete autonomous driving operating system supporting the realization of autonomous driving technology.

Currently, in the functional software layer, traditional Tier 1, OEMs, tech giants, and third-party software suppliers all have certain layouts. Each party can leverage its own advantages to provide solutions, choosing to develop modules they are proficient in. For example, algorithm vendors with advantages in the sensor field can focus on developing the sensor module in functional software, achieving more effective division of labor and cooperation across the industry.

In the functional software field, the model of collaborating with suppliers helps meet the automotive companies’ needs for functional development of intelligent vehicle products. Compared to automakers, the software modules developed by major suppliers have been tested in various scenarios and on different products, ensuring higher quality. Some software suppliers can also provide solutions more suited to automakers’ unique characteristics, accelerating development efficiency. For example, providing functional module solutions for automakers with relatively strong development capabilities, opening clean interfaces for them to control the entire user experience and product definition. Meanwhile, for automakers with less developed software capabilities, they can offer integrated hardware and software delivery solutions, significantly shortening the automakers’ development cycles.

2.6. Application Software Layer

Application layer software runs on top of the broad operating system, specifically responsible for function realization. It mainly includes algorithms for autonomous driving, map navigation, in-vehicle voice, OTA and cloud services, infotainment, etc. A typical computing platform, after loading the operating system and functional software that constitute the operating system, supports application software development upwards, ultimately realizing overall functionality. The upper application software layer is a key area for OEMs to develop differentiated products, such as cockpit HMI and autonomous driving.

In the long term, the upper layer applications and algorithms will hold the most value. In the short term, for automotive software enterprises to truly implement SOA software architecture, system software such as virtualization technology, system kernels, and middleware (AUTOSAR) are crucial. However, in the long term, once the SOA architecture and broad operating system framework mature, the rich upper-layer application ecosystem and algorithms will have greater value space.

Typical Upper Layer Application Example 1: Upper Layer Application Algorithms in Autonomous Driving Domain

Upper layer application algorithms for autonomous driving domain controllers include scene algorithms (covering data perception, decision planning, control execution, etc.), data maps, and human-machine interaction (HMI), among which scene algorithms are the most complex, typically including algorithms across perception, decision-making, and execution dimensions, thus realizing various autonomous driving functions under different scenarios.

OEMs developing their own autonomous driving algorithms is becoming a future trend. In the medium to short term, due to the lack of algorithm capabilities among most OEMs, they will choose to cooperate with Tier 1 or software companies with obvious algorithm advantages. In this stage, companies like Bosch, Continental, Desay SV, and Thunder Software Technology have significant advantages. However, in the long term, as OEMs gain talent and data advantages, they will gradually develop their own key algorithms (such as fusion/decision algorithms), ultimately extending their full-stack algorithm capabilities. Under this trend, suppliers should follow current OEM demands and clarify their positioning, or focus on a specific area of the autonomous driving application layer to maintain lasting competitiveness.

Typical Upper Layer Application Example 2: Digital Maps

In the field of autonomous driving, high-precision positioning and maps (data maps) are essential for achieving advanced autonomous driving. The market scale will continue to expand. High-precision maps not only ensure functionality under special weather conditions but also effectively eliminate some sensor errors and provide corrective modifications to existing sensor systems. Moreover, high-precision maps can build a driving experience database, analyze hazardous areas, and provide drivers with new driving experience data sets.

Currently, the main players in the high-precision map field include Four-Dimensional Map, Amap, and Baidu, with the three companies forming a competitive landscape. Each company has its strengths: Baidu was the first in China to conduct research on high-precision maps, launching its unmanned vehicle project in 2013; Amap has the full support of Alibaba and is progressing rapidly; Four-Dimensional Map is a well-established map provider in China. In 2020, the three companies held over 65% of the market share, forming a “three-legged” competitive situation.

3. SDV Brings Industry Chain Restructuring and Competitive Landscape Analysis

3.1. Industry Chain Restructuring

3.1.1. OEMs Attempt to Lead the Vehicle Software Sector, Software Suppliers Advance to Tier 1

OEMs are beginning to deeply participate in software development. In the traditional automotive industry chain, the development of various system software was almost entirely completed by Tier 1/2 suppliers, providing black-box solutions to OEMs, who were merely the definers of the overall architecture, responsible for designing and managing the definition of system concepts, and ultimately completing system integration and verification, as illustrated in the yellow section of the diagram below. As the importance of automotive software continues to rise, OEMs have begun to emphasize defining software and deeply participate in system architecture and functional requirement analysis, even leading the design and development of software units, as shown in the green and red sections of the diagram below.

Software suppliers are advancing to Tier 1. Whether it is establishing partnerships with core software companies or self-developing, the traditional supply chain relationships will undergo fundamental changes. The collaboration between automakers and software suppliers will deepen further, as OEMs seek to master the initiative and reduce high development costs by directly collaborating with software suppliers that possess strong independent algorithm development capabilities. As a result, these software suppliers leap to become Tier 1 suppliers, breaking the traditional pyramid supply model where software suppliers provide to Tier 1, who then supply to OEMs, and evolving towards a flatter supply network model.

For software suppliers, as OEMs’ autonomy and software self-development capabilities continue to strengthen, OEMs are beginning to seek direct cooperation with software suppliers. For instance, OEMs will first seek to reclaim cockpit HMI interaction system functions, purchasing software licenses for UI/UX design tools, voice recognition modules, audio modules, facial recognition modules, and other application software directly from software suppliers, thereby bypassing traditional Tier 1 suppliers and realizing independent development. For software suppliers, the more software IP products they can offer, the higher the single-vehicle value they can obtain. At the same time, software suppliers are also seeking to enter the hardware design and manufacturing areas traditionally controlled by Tier 1, such as domain controllers (Thunder Software Technology), TBOX, etc., to provide diverse solutions.

3.1.2. Software Development Evolves Towards Layered and Modular Structures, Providing Significant Opportunities for Middleware Suppliers

The transition from traditional V-shaped development to layered development oriented towards software-defined vehicles is fundamentally based on the introduction of middleware. The complexity of application algorithms in domain control architectures is high, especially in the field of autonomous driving, where almost no company can provide a complete software system. Therefore, multiple suppliers need to collaborate to complete the entire software package. The introduction of middleware has achieved soft-hard decoupling, allowing for the introduction of third-party software, which must be built on the functional interfaces provided by middleware. This requires the automaker or supplier responsible for system integration to have very strong software system architecture capabilities and middleware platform design capabilities.

From the perspective of software development models, the layering and modularization of software is an inevitable event when software reshapes each industry. Taking the mobile phone field as an example, both Android and iOS platforms have very rich development tools and basic software modules within their ecosystems, with a wide variety of SDK (Software Development Kit) categories in the Android ecosystem, and most modules are independently provided by third parties.

The modular industry division in the mobile field provides significant market opportunities for standard module suppliers, with representative listed companies like Twilio and Salesforce. Twilio, as a cloud communication company, provides APIs that help developers easily add SMS, voice, and web calling functionalities to other applications. According to the overall service framework of CPaaS (Communications Platform as a Service), CPaaS can be divided into five levels. Twilio can provide several services within this framework, including many commonly requested basic modules like SMS, Voice, Phone Number, which constitute over 90% of current CPaaS revenue. The demand for web communication, RCS, email, video, etc., saw explosive growth in 2020, as more enterprises and users embraced electronic communications and omni-channel communication, and future demands for modules in IoT, AI, remote healthcare, payments, and biometric security will continue to grow rapidly. The company’s revenue grows with the increase in supported third-party applications.

Since its establishment, the company has maintained rapid revenue growth, with 2021 revenues exceeding 18 billion yuan and a market value peaking at 80 billion US dollars.

Under the trend of “software-defined vehicles,” the automotive software industry will inevitably witness layering and modularization, leading to the emergence of specialized middleware supplier enterprises. Automakers find it challenging to complete the research and development of full-chain software modules, while standard third-party modules undergo more testing across various scenarios and products, ensuring higher quality and longevity, and can share and reduce costs for each module. For instance, in the cockpit domain, Thunder Software Technology has seized the trend of industry division, providing digital cockpit solutions for Li Auto, while opening clean interfaces for GAC Nio and Li Auto to control the entire user experience and product definition. Core functional modules in intelligent automotive software functionality systems also involve collaboration among multiple parties, including general frameworks for autonomous driving, connectivity modules, cloud control modules, AI and vision modules, sensor modules, etc. By utilizing these common functional modules, developers can conduct more efficient research and development at the business level of autonomous driving. Suppliers can leverage their advantages to offer solutions to automakers, achieving more efficient division of labor and collaboration. (Report Source: Future Think Tank)

3.2. Competitive Landscape? – Assessing Software Companies’ Growth from Several Dimensions

3.2.1. Entering Core Ecosystems like Chips, Operating Systems, or Middleware

Automakers are shifting from building ecosystem systems around Tier 1 to constructing ecosystems around chip, operating system, or middleware companies. In the traditional automotive era, the automotive ecosystem was centered around Tier 1, which procured chips, integrated software, and supplied them to OEMs. In the era of intelligent vehicles, when defining an intelligent vehicle, automakers will focus on determining the computing power of the chip required to support the expected intelligent functions. After finalizing the chip, surrounding components, operating systems, and software will be selected among related companies supported by that chip. Thus, automakers will build ecosystems around NVIDIA, Qualcomm, Horizon, and other ecosystems. Of course, there are also automakers building ecosystems around operating systems like QNX, LINUX, Android, or middleware systems like Apollo, AUTOSAR.

Therefore, if software suppliers can deeply penetrate these core chip, operating system, and middleware ecosystems, they will be able to share in the explosive growth of the automotive software market. Taking Thunder Software Technology as an example:

(1) Chip Field: Deeply Bound to Qualcomm

Qualcomm dominates the intelligent cockpit chip field. 1. In automotive chips, Qualcomm’s third-generation intelligent cockpit chip (Snapdragon 8155) is the first automotive-grade digital cockpit SoC built using 7nm process technology, with multi-core heterogeneous performance twice that of other chips, and both CPU and GPU performance far exceed those of other manufacturers’ chips, making it the most powerful cockpit SoC chip currently available. More than 20 of the world’s top 25 automakers have produced models equipped with the 8155 chip, indicating a strong market presence. 2. In terms of chip platforms, Qualcomm has also launched the Ride, fourth-generation Snapdragon platform, and 5G vehicle networking products. The fourth-generation chip SA8295P, launched last year, uses a 5nm process, with an eight-core CPU frequency significantly improved compared to the third-generation chip and other manufacturers’ chips, with GPU performance also increased by over 50%. This marks Qualcomm’s further breakthroughs in chip technology, and the release of the Ride platform has also allowed Qualcomm to complete its full product line layout in the automotive market, attempting to integrate the cockpit and autonomous driving domains.

Thunder Software Technology is deeply bound to Qualcomm, continuously benefiting from Qualcomm’s customer referrals. Since its establishment, Thunder has formed a strategic partnership with Qualcomm, which produces mobile terminal chips, including the joint development of QRD (Qualcomm Reference Design) mobile phones and establishing a joint laboratory for mobile chip-systems. Thus, Thunder’s familiarity with Qualcomm’s chip platform is far superior to that of other automotive software companies, laying a solid foundation for their preferred cooperation in the automotive sector. Additionally, Thunder and Qualcomm established a joint venture – Chongqing Chuangtong Lianda Intelligent Technology Co., Ltd. in 2016 to provide customers with “Qualcomm chip platform’s chip + operating system + core algorithm intelligent products or software” one-stop solutions, further deepening their binding at the equity level. In summary, Thunder’s integration into Qualcomm’s chip ecosystem, with Qualcomm’s clients referring to Thunder, provides guarantees for the stable and continuous growth of Thunder’s intelligent cockpit business; at the same time, long-term cooperation with Qualcomm has deepened Thunder’s technical accumulation regarding chip virtualization, firmware drives, and other aspects.

Thunder will optimize the operating system, core SDK, and middleware for Qualcomm’s integrated platform. Thunder possesses deep understanding of automotive-grade requirements and has accumulated production-level optimization technology for automotive-grade operating systems, helping Qualcomm connect with downstream automakers, understand their customization needs, and develop OS tailored for automakers based on Qualcomm’s different generations of chips, as well as making individual adaptations and improvements for different vehicle models. Therefore, the deep binding with Qualcomm is Thunder’s core advantage over other software manufacturers.

The future integration of cockpit and autonomous driving domains will provide Thunder with broader display opportunities. The fusion of cockpit and autonomous driving domains will lead to a rapid increase in software complexity, utilizing multiple systems, virtual machines, and various middleware. This will require integrating non-real-time operating systems with real-time operating systems at the system level, significantly increasing the complexity of the entire software system, driving further enhancement of the value of software throughout the industry chain. The specific content provided by Thunder in the RIDE platform includes: chip virtualization; security middleware (which needs to encapsulate many underlying hardware resources, access services, access permission controls, and provide unified service interfaces and permissions for the upper layers), ensuring real-time access to tasks, as well as the integration of algorithms or source data.

(2) Operating System Field: Long-Term Focus on Operating Systems

The company has a deep understanding of operating system underlying technologies, with extensive experience in customizing and developing various operating systems, widely adapting to QNX, LINUX, and various virtual machine vendors. 1. Thunder is a solution provider for QNX (BlackBerry) autonomous driving systems. BlackBerry has developed entertainment systems, intelligent cockpits, and assisted driving systems for automotive companies, providing developers with flexible tool choices. Thunder’s strong foundational capabilities in operating systems have successfully built a collaborative relationship with QNX, becoming one of QNX’s solution providers in the autonomous driving field. 2. Thunder integrates into the Android ecosystem, further enhancing its advantages in intelligent cockpits. The biggest advantage of Linux over QNX lies in its open-source nature, which offers strong flexibility for custom development. Android, developed by Google based on the Linux kernel, is mainly applied in in-vehicle information and entertainment systems and navigation fields, and currently dominates the in-vehicle information and entertainment system market in China. As a leader in intelligent cockpits and the epitome of the Android ecosystem, Thunder’s mutually beneficial cooperation with Android system vendors further strengthens its advantages in the intelligent cockpit field.

(3) Middleware Field: Middleware Capability is the Core Capability of Thunder

Thunder has the capability to develop AutoSAR AP. Thunder has built an integrated SOA platform of “cloud management end” to provide development toolchains for software development, vehicle integration, and more. At the same time, Thunder has joined the Apollo ecosystem to expand multidimensional in-depth cooperation. Thunder provides a series of services and solutions at the software platform level, including operating system customization and optimization, development of intelligent driving algorithms, and customization and optimization of human-machine interaction interfaces.

3.2.2. Deep Binding with Downstream Customers, Forming Long-Tail Coverage

The automotive software market exhibits a long-tail market characteristic, where a broader customer coverage leads to better performance sustainability and stronger product universality. Thus, manufacturers with a more extensive distribution of downstream customers and lower customer concentration will have a competitive advantage. Currently, companies like Thunder Software Technology, Neusoft Ruichi, Wuhan Guangting, and Jingwei Hengrun have rich domestic and international customer resources, and their products have covered the vast majority of mainstream vehicle models.

Thunder’s customer coverage encompasses almost all mainstream OEMs and Tier 1 suppliers, with a customer concentration significantly lower than comparable companies. Compared to the other three manufacturers, Thunder’s top five customers accounted for 29.6% of revenue in 2020 and 26% in 2021, far lower than Guangting’s 53% and Jingwei Hengrun’s 52.7%. This indicates that Thunder’s revenue structure is more diversified, with lower dependence on single customers, suggesting that Thunder’s operations are relatively more stable. Additionally, due to Thunder’s binding with Qualcomm, it has further absorbed Qualcomm’s domestic and international customers, leading to better performance sustainability and stronger product universality.

3.2.3. Revenue Model: Higher Barriers with “License + Royalty,” More Stable Revenue Compared to NRE

The business model for automotive software generally adopts the model of “IP + solutions + services.” The software charging model mainly includes three types: the first is receiving outsourcing, providing a one-time quote under the NRE (Non-Recurring Engineering) model, pricing based on the number of developers and hours required for the project, usually used for software and system development business; the second is selling IP and software development licenses to customers, with specific charging standards including Royalty and License, which generally have higher gross margins, usually exceeding 70%; the third is a packaged charging model of “NRE + License,” which charges a one-time fee and another fee based on the number of vehicles.

According to Zosi Automotive Research data, the current IP licensing fee per vehicle is between 2000-3000 yuan, and as the complexity of automotive functions increases and related software enterprises emerge, software licensing fees will continue to rise.

Thunder sells IP and customer software development licenses, occupying a leading position in the industry. Most automotive software companies in China provide purely outsourced software development services and solution services, with charging typically based on project forms or one-time NRE forms. The NRE model has low market barriers, as automotive software vendors typically only need to provide technology and manpower. In a rapidly growing industry, this model can achieve high-speed growth through personnel expansion. However, as automakers gradually enhance their software capabilities, the sustainability of outsourcing projects becomes questionable, and revenue stability is lower. In contrast, the technical difficulty of IP licensing is higher, and only enterprises with leading technology in niche fields can support the licensing model, with their revenue primarily dependent on the vehicle sales of customers. This model is conducive to maintaining customer stickiness and revenue stability. Currently, only Thunder and Neusoft Group can rely on IP charges, with Thunder’s IP revenue share being higher, mainly coming from the licensing of IP like Kanzi. As the number of vehicle models equipped with the 8155 cockpit chip continues to grow, Thunder’s ROYALTY revenue is expected to see significant growth in 2022.

3.2.4. Focusing on a Single Field and Cross-Field Market Scale Will Differ

Under the wave of intelligence, automotive software companies focusing on a single field can achieve stable revenue and market scale. However, in the long term, companies that focus on a single field may lack sufficient growth potential. As product iterations and technological advancements occur within the industry, it will become challenging for companies to form differentiation, resulting in limitations in competitive advantages. Therefore, compared to companies focusing on a single field, those with broader software business coverage and involvement in more fields will have better growth potential in the long term.

Thunder has acquired several upper-layer field companies, achieving cross-field development in intelligent automotive business. Thunder has been listed for many years and has established a complete platform in the intelligent cockpit field, forming a brand effect. However, the company is not satisfied with just developing the underlying OS, gradually expanding into upper-layer (application layer) fields. Since 2016, Thunder has acquired several companies in different fields, such as Applause and Rightware, significantly expanding and enhancing its business. As a result, Thunder has become one of the few companies that comprehensively covers operating system technology from chip level, system level, application level to cloud, occupying a position in high-growth areas such as IVI technology, HMI interface design, image processing algorithms, and automatic parking, while other companies in the industry have yet to expand into these areas or lack corresponding clients, posing minimal threats to Thunder. Thus, through acquisitions, Thunder leads in cross-automotive sub-field development, helping it explore markets and gain unique advantages in multiple fields.

The Kanzi software from Rightware is a key supplement to intelligent cockpit technology, allowing Thunder to achieve breakthroughs. Kanzi has very strong technology in in-vehicle information and entertainment systems, with many advantages in its products. (1) Kanzi’s particle effects, PBR, etc., reach the level of end-game graphics, providing better realism; (2) Supports ultra-fast startup and MCU chip support, compatible with various development languages and seamlessly integrates with Android, while occupying very little memory; (3) Allows for rapid onboarding, enabling some technical designs without coding, significantly improving efficiency; (4) Meets C language development standards, compliant with ASPICE and other automotive-grade quality safety verifications; (5) Currently, Kanzi is used in over 100 vehicle models, achieving the delivery of one million vehicle software units, and has over 100 original factory technical support personnel globally, demonstrating mass production capabilities. Kanzi has now become the preferred tool for HMI design for more than 80% of domestic automakers, and Thunder leverages Kanzi’s strong technology to package Kanzi and other core capabilities, implementing an IP licensing model to charge software licensing fees. Thus, Thunder has prioritized its position in the intelligent automotive sub-field market through the acquisition of Rightware, while also breaking through the “License + Royalty” barriers and enhancing its bargaining power in Tier 1.

The company’s business structure is driven by three wheels, with automotive, mobile, and IoT. In 2021, the company’s revenues for mobile, automotive, and IoT were 1.055 billion, 1.2 billion, and 1.27 billion, respectively. The mobile business has maintained steady growth despite a decline in terminal shipments, while the IoT business has seen explosive growth, with 2021 revenues increasing by 82.87% year-on-year. Thunder’s IoT business primarily targets emerging markets such as robotics, drones, video conferencing, smart cameras/AI cameras, and VR, and is expected to continue to show explosive growth in 2022.

3.3. How to View Automakers’ Self-Development?

Software-defined vehicles have become an industry consensus, and automakers will certainly increase their investments in software. When making decisions about self-development or outsourcing, many fields are involved, such as which stages of the development process to self-develop and which to outsource. In layered technology, whether to self-develop the operating system or which domain to self-develop varies by enterprise, and companies can make choices based on their resource endowments and strategic goals.

Leading New Forces in the Automotive Industry Choose Self-Development, While Other Automakers Tend to Purchase Basic Software and Self-Develop Application Software

Leading new force enterprises choose to self-develop software. Currently, only leading new force enterprises are fully self-developing, as these automakers have strong differentiation demands and sufficient financial strength and software talent to support them. Companies like NIO and Li Auto self-develop algorithms at the perception and decision-making layers of autonomous driving and the underlying software to pursue leading positions in autonomous driving functionality and create differentiated selling points. In the cockpit domain, both Xiaopeng’s P7 (Qualcomm 820A) and P5 (Qualcomm 8155) rely on Thunder to develop underlying software. However, for the Qualcomm 8295 generation cockpit chip, Xiaopeng has begun to directly connect with Qualcomm to improve efficiency and strive for market leadership.

Mainstream domestic and foreign automakers are very cost-sensitive and tend to purchase universal, standardized hardware platforms along with basic software, while self-developing upper-layer application software to seek differentiation. Generally speaking, automakers are better at defining user scenarios and utilizing user data rather than system-oriented capabilities. Therefore, as underlying hardware becomes increasingly centralized, more complex software is needed to bridge the gap, increasing the value of software. Companies like Thunder Software Technology will see continuous market opportunities. For long-tail OEMs with insufficient resources, packaged services for hardware, underlying software, and application layer software will be necessary.

Leading New Forces’ Models Generally in the B-Class and Above, Price Ranges Above 250,000 Yuan, Not the Main Force in Sales

Currently, new force enterprises that choose full-stack self-development generally have models priced above 250,000 yuan, mostly falling into the B-class and above categories. Looking at the entire domestic passenger car market, only 24% of models were priced above 250,000 yuan in 2021, with B-class and above models accounting for only 34% of sales. The main sales force in China consists of models priced below 250,000 yuan and classified as B-class and below. In terms of market share, Tesla, NIO, and Li Auto accounted for only 2.9% in China in 2021.

Moreover, according to information disclosed during Thunder’s 2021 financial report performance briefing, the number of major customers (with revenues exceeding 2 million yuan) is expected to increase from 4 in 2021 to over 22 in 2022, covering mainstream automakers both domestically and internationally, including General Motors, Ford, Great Wall, SAIC, Geely, Volkswagen, Toyota, BYD, etc., reflecting Thunder’s increasing market share among these customers and their growing reliance on Thunder. Therefore, we believe that aside from the leading new force enterprises with extreme differentiation pursuits, mainstream automakers will adopt industry division forms to promote software-defined vehicles.

Automotive Software’s Evolution Towards Layering and Modularization is Inevitable

Referring to the PC and mobile phone eras, automotive software will also form a layered and modular division pattern. In the early stages of the industry, various technologies are not mature, and automakers will choose to invest. However, after investing to a certain boundary, their investment will decrease. Additionally, full-stack self-development is very uneconomical; standard third-party modules will undergo more testing across various scenarios and products, increasing their longevity and quality, while also reducing costs through distribution across many scenarios. From a business perspective, it is certain that they will choose vendor solutions, and the industry will undergo a process of division of labor.