Review and Prospect of Integration Compatibility in Digital Vehicles: Multi-Dimensional Challenges and Industry Practice

Abstract

Integration compatibility has emerged as a prominent challenge in the development of digital vehicles. This paper provides a comprehensive review of previous research on automotive integration compatibility, categorizing the relevant challenges into three main categories: technical, organizational, and methodological. Furthermore, the paper distinguishes between challenges encountered during the initial integration phase and those encountered during continuous integration according to the nodes of the start of production. By engaging in discussions with internal experts from an original equipment manufacturer (OEM) and other related enterprises regarding these challenges, the paper identifies the most pressing issues that require novel solutions, which are the current practical pain points of OEMs, thereby providing directions for future research.

1. Introduction

With digital technologies profoundly reshaping the landscape of the automotive industry, modern vehicles have evolved from simple transportation tools to complex systems with various functionalities [1]. These functionalities include autonomous driving, intelligent navigation, vehicle diagnostics, in-vehicle entertainment, and more, resulting in increasingly complex technological stacks. Digital vehicle is the next-generation automotive form that takes algorithms and data as core drivers, achieves intelligent and evolvable capabilities through the deep integration of perception, computing, communication, control, interaction, and service architectures, and evolves into a hardware–software integrated product and continuously upgradable terminal supported by the digital industry ecosystem. It differs from two easily confused concepts: (a) connected vehicle: focuses on V2X communication as the core, while digital vehicles regard connectivity as a supporting technology for “intelligent evolution”; (b) virtual vehicle: refers to digital twin/simulation models, while digital vehicles are physical vehicles with digital capabilities. The difference between technology stack and product characteristics leads to the great difference between the integration of digital vehicles and the integration of traditional vehicles.

The system integration of traditional vehicles primarily focuses on horizontal integration, that is, connecting products at the same level from different sources form a whole [2]. Suppliers have already completed the development of electronic control units (ECUs) that control various components. The integration work for OEMs mainly involves successfully debugging the communication signals between different ECUs and deploying them onto specific vehicle models. However, the system integration of digital vehicles is not only more complex horizontally but also involves vertical integration, that is, integrating technologies at different levels into an operational system or subsystem. On the one hand, the subsystems of different components in traditional vehicles are relatively independent, and OEMs do not need to have an in-depth understanding of the software and hardware implementation logic within them [3]. In contrast, digital vehicles require more horizontal interaction, and OEMs must have a thorough understanding of different subsystems to ensure the software and hardware provided by different suppliers can work together [4]. This involves dealing with various interface, protocol, and data format differences. On the other hand, due to the increased number of software components in digital vehicles, OEMs need to establish a layered software system to effectively manage these components [5]. This involves vertically integrating different types of technical components, such as hardware board support package (BSP), operating system (OS) kernel, middleware, and application software.

Another major difference in system integration between digital vehicles and traditional vehicles is the presence of a new integration stage in digital vehicles. In traditional vehicles, once a vehicle model reaches the start of production (SOP), the hardware and software of the ECUs on the vehicle rarely undergo any further changes [6]. However, digital vehicles introduce a new post-SOP integration stage, driven by the need for continuous updates to fix bugs, enhance performance, or add features [7]. For example, software updates can be carried out through over-the-air (OTA) updates, and Tesla has even replaced the autopilot platform HW 2 with HW 2.5 for some existing customers [8]. This means that after the SOP, OEMs still need to continue integrating new software and hardware components for the same vehicle model, resulting in the possibility of multiple system integration versions for the same vehicle model.

Figure 1 shows the different dimensions and complexity of automotive integration. Specifically, it illustrates the horizontal integration of components from various suppliers, the vertical integration of the technology stack, and the lifecycle integration that extends from an initial phase to continuous post-SOP updates. The evolution of digital vehicles has presented significant integration compatibility challenges for OEMs with limited prior software expertise. Numerous OEMs have encountered delays in product launches and even quality issues during user usage due to compatibility problems [9]. Consequently, these challenges have had a detrimental impact on the OEMs’ brand image and economic performance [10].

Despite the importance and urgency of addressing integration compatibility challenges in the automotive domain, there is currently a lack of comprehensive classification and systematic study in academia. The objective of this study is to present a literature review aiming to address two research questions:

RQ1: Which automotive integration compatibility challenges have been recognized and explored in the academic community, and what potential solutions have been proposed?

RQ2: Has the industry effectively responded to these challenges? What practical pain points still exist?

Through this literature review, we aim to provide a holistic perspective for automotive industry practitioners and researchers, deepening their understanding of integration compatibility issues and offering valuable insights for future research and practice. The remainder of this paper is organized as follows: Section 2 provides an overview of the research methodology. Section 3 and Section 4 present and explain our research findings. Finally, Section 5 concludes the paper.

2. Materials and Methods

The literature review methodology of this study is divided into three stages. The first stage involves the acquisition of relevant literature through a scientific and comprehensive literature retrieval and screening method. The second stage involves the organization and structured classification of the identified automotive compatibility challenges and potential solutions mentioned in the literature. The third stage involves consulting experts to gain insights into how OEMs address these challenges, thereby identifying current practical pain points. The first two stages are mainly aimed at RQ1, and the expert investigation in the third stage is mainly aimed at RQ2.

2.1. Literature Retrieval and Screening

The concept of ‘integration compatibility’ is relatively vague and may not be directly mentioned in many literature sources, although they may address related issues. Therefore, it is necessary to clarify the keywords for literature retrieval. In this study, integration compatibility is understood as not only ensuring the overall functionality of the system but also achieving it in a low-cost and efficient manner, rather than being solely a concept of quality [11]. For example, if an OEM requires a large team and a long time to integrate a small function, we consider the compatibility of the system to be inadequate. A highly compatible system should be safe, high-quality, flexible, open, easy to debug, scalable, and manageable [12]. This definition focuses on the “full-lifecycle balance of function, cost, and efficiency” (rather than just functional or technical matching), which aligns with the practical pain points of OEMs (e.g., high integration costs, delayed upgrades). We used these adjectives in combination with keywords such as ‘automotive integration’, ‘automotive system’ and ‘compatibility’ to search for and filter relevant literature.

Figure 2 illustrates the process of literature search and screening. By eliminating duplicate, irrelevant, similar, and low-quality articles, we ultimately selected 49 relevant literature sources for in-depth analysis. In terms of screening titles, this study excluded records where titles explicitly focused on non-digital vehicle scenarios (e.g., traditional mechanical vehicle assembly, non-automotive integration such as aerospace systems) or lacked core concepts (e.g., “automotive software” without mentioning “integration” or “compatibility”). In terms of screening abstracts, this study further excluded records that failed to meet two conditions: (a) The research object clearly involves the digital function of the vehicle; (b) addressing at least one dimension of integration compatibility (technical/organizational/methodological). For example, some records were excluded because they only discussed “automotive software development” (without integration) or “traditional ECU communication” (without compatibility challenges). In this study, the quality of literature includes: (a) methodological rigor (e.g., clear research design for empirical studies, transparent retrieval process for reviews); (b) data validity (e.g., experimental data with repeatability, expert interviews with clear sampling logic); (c) technical validation (e.g., OEM whitepapers with test data, industry reports with multi-stakeholder verification); (d) authorship clarity (excluding anonymous documents). The two co-first-authors independently evaluated each full-text according to the above criteria. Disagreements were resolved through discussion with other authors.

2.2. Structured Classification

Through careful reading of the literature, we identified that the challenges of automotive integration compatibility are diverse and not limited to technical aspects alone but also involve internal and external management of OEMs. We proposed a structured classification framework, as shown in Figure 3, to categorize and organize the challenges mentioned in the literature.

The different integration stages are distinguished based on the SOP node. The integration stage prior to SOP is defined as the initial integration. Initial integration is the final phase in the progressive development process, where the automotive product is built from scratch. Completion of the initial integration signifies that the vehicle product meets the basic functional and quality requirements and complies with the specifications for production and sales [13]. The integration stage following SOP is defined as continuous integration. Continuous integration ensures the availability of the overall system after partial software or hardware updates [14]. Continuous integration spans the entire lifecycle of the vehicle model, and OEMs can choose to release some new versions at different stages and deploy them on vehicles through OTA updates and other means [15]. Specifically, there are several differences between initial integration and continuous integration:

• Initial integration is about building from scratch, while continuous integration involves making additions, deletions and modifications to an already stable system, which introduces more dynamic problems. For example, due to continuous software updates, the probability of system errors also dynamically changes [16].
• Initial integration focuses on the overall vehicle system, while continuous integration sometimes targets a specific component or subsystem.
• During initial integration, the versions and states of various technology stacks across different vehicles of the same model are consistent. In contrast, during continuous integration, the technology stack versions and states may vary among different vehicles of the same model. For example, two individuals may purchase the same model of computer, but due to differences in usage time and installed software updates, the two computers may gradually exhibit significant differences in terms of memory usage and software performance.
• Initial integration is typically driven by fixed and predetermined deadlines to meet product launch requirements. While the deadlines of continuous integration are often flexible and uncertain. For instance, urgent bug fixes may require completion within a week, while the integration of new functions can be adjusted flexibly based on market demands and research and development (R&D) progress [17].

The inherent differences between initial integration and continuous integration determine that they face different compatibility challenges. The identified challenges were subsequently classified into three primary dimensions: technical, organizational, and methodological.

• Technical dimension: There are significant differences among various software and hardware components in vehicles. Certain technical measures can facilitate communication and collaboration between components, thereby improving integration compatibility. This dimension primarily involves system design, interaction interfaces, standard protocols, toolchains, etc.
• Organizational dimension: The automotive integration work involves multiple departments, including design, research and development, engineering, operations, and supply chain management. Effective communication and collaboration mechanisms are essential to seamlessly integrate components into the vehicle system. This dimension primarily involves organizational structure, team, location, culture, external cooperation, etc.
• Methodological dimension: Cost, efficiency, and quality are considered challenging to simultaneously achieve in integration testing. Appropriate methodological strategies are widely regarded as being able to optimize this imbalanced triangle relationship [18]. This dimension primarily involves product management, quality control, processes, testing strategies, etc.

2.3. Expert Investigation

Expert investigation method is a commonly used research approach that involves consulting experts in a particular field who possess extensive experience and specialized knowledge [19]. In this study, we aim to gain insights into the current responses of OEMs to various integration compatibility challenges by consulting experts. This allows us to understand the current industrial practices. We invited a total of six experts with different roles, whose professional backgrounds and experiences encompass various aspects of automotive integration. These experts include:

• Expert#1—Head of Integration Department at a well-known OEM: This expert has extensive management experience and a deep understanding of internal integration challenges within OEMs.
• Expert#2—OEM integration testing engineer: This expert has practical experience in integration testing, providing direct exposure and understanding of compatibility issues.
• Expert#3—Researcher specializing in digital vehicle development: This expert has conducted in-depth research on digital automotive technical trends.
• Expert#4—Partner at an automotive industry management consulting firm: This expert possesses rich consulting experience and a comprehensive understanding of the automotive industry.
• Expert#5—Product manager at an automotive software supplier: This expert has professional knowledge and experience in automotive software development and integration.
• Expert#6—Researcher focusing on automotive industry standards: This expert has a deep understanding of industry standards and specifications and has participated in the development process of related standards.

We conducted in-depth interviews with each expert using a semi-structured approach, either face-to-face or remotely. During the interviews, we presented the experts with a series of integration compatibility challenges derived from the literature review. We guided the experts to share their perspectives on these challenges and provide insights based on their practical experiences within their respective organizations. All interviews were audio-recorded and transcribed verbatim to ensure data integrity, resulting in over 200 pages of interview records. This study focuses primarily on the perspectives of different experts regarding the degree of resolution of various challenges covered in the literature review within current industry practices. Experts’ overall attitudes were coded into four categories: “significantly improved”, “partially improved”, “not significantly improved”, and “not aware”. The research team conducted cross-validation of the coded themes to resolve discrepancies. We prioritized challenges that were consistently reported by ≥4 out of 6 experts to ensure consensus. Actual pain points were explicitly defined as the following themes revealed by expert feedback: (1) lack of effective industry solutions; (2) mismatch between academic proposals and industrial feasibility; (3) cross-role consensus. This analysis ensures that the pain points are not speculative conclusions but a systematic synthesis based on experts’ experience.

3. Compatibility Challenges of Automotive Integration

Based on 49 relevant literature sources, a total of 26 challenges have been identified and grouped into 14 topics. The following sections will provide a detailed description of each challenge.

3.1. Technical Challenges of Initial Integration

Table 1. Technical challenges of initial integration.

Technology	Challenges	Related Keywords	References
System Design	Complex dependencies between features	Flexible, Scalable, Safe	[20,21]
	Distributed deployment of software	Easy to debug, Manageable	[22,23,24]
Interactive Interface	Multiple kernel integration	Safe, Open, Easy to debug	[25,26,27,28]
	Interaction of software components	Efficient, Open, Easy to debug, Safe, Manageable	[29,30,31,32,33]

presents the technical challenges faced during the initial integration stage, with a primary focus on system design and interaction interfaces.

3.1.1. System Design

The system design of digital vehicles typically encompasses both software and hardware systems. The quality of system design directly influences the level of difficulty during the integration stage [34]. As a result, architecture engineers are receiving increasing attention from OEMs.

The automotive software system consists of numerous features. Each feature corresponds to a set of software components, and these components interact with each other in various ways. If the behaviour of a feature is influenced not only by its primary inputs but also by the state or data of another feature, then it depends on the latter feature [20]. Therefore, when one feature depends on another, there exists some form of communication relationship between them. Excessive dependency between features can lead to mutual impact among them. If a component encounters even minor issues, it can potentially result in the failure of the entire software system [21]. Andreas [20] conducted an internal survey within an OEM and found that 50% of feature dependencies were unknown to developers. This is also why, with the increase in the number of features, automotive software integration has become increasingly challenging.

The automotive hardware system consists of distributed hardware units, which are divided into different hierarchies. The bottommost layer is the sensor and actuator unit (SAU), above which is the local controller unit (LCU), followed by the domain controller unit (DCU) or zonal controller unit (ZCU), and finally, the central computing unit (CCU) [22]. Once the software system is designed, it needs to be deployed onto the hardware system. If software components are mistakenly deployed onto incorrect hardware during the system design phase, it can lead to system failures. On the one hand, certain software components have specific coupling relationships with hardware units [23]. For example, some hardware-dependent drivers and control software must be deployed on the SAU or LCU. On the other hand, the capability of hardware units must support the execution of software; otherwise, there may be task overflow during integration [24]. Generally, software with higher complexity is deployed on hardware with higher computational capacity. As the number of software components on vehicles increases and hardware units rapidly advance, software deployment becomes increasingly crucial for integration compatibility.

3.1.2. Interactive Interface

Integration compatibility requirements ensure that software can interact effectively with each other [12]. However, with the increasing presence of heterogeneous software on vehicles, this interaction becomes more complex.

For underlying system software, different application software has varying demands on the OS kernel [25]. As the computational capacity becomes more centralized in future vehicles, multiple OS kernels need to run simultaneously on a single computing platform [26]. To allocate different hardware resources to different OS kernels, hypervisor technology is employed to facilitate interaction between OS kernels [27]. It can transform physical resources into virtual resources and allocate them as needed to each OS. However, due to the increasing variety of chips, OS, and peripherals in the automotive domain, the current hypervisor technology faces challenges in adapting to such a diverse range of hardware and OS [28].

For upper-level software components, their interaction relies on middleware to facilitate communication. Currently, there are two major standardized middleware platforms in the industry: AUTOSAR CP and AP. AUTOSAR CP effectively addresses software interaction among traditional ECUs. AUTOSAR AP aims to address software interaction across OS on high-performance computing platforms [29]. However, there are two challenges in this context. Firstly, efficient implementation of interaction between CP and AP is difficult. This is due to the different communication mechanisms of CP and AP, and currently, there is no sufficiently efficient translation module available to facilitate their integration [30,31]. Secondly, ensuring the security of interactions based on AP is challenging. This is because AP utilizes a thread-based programming paradigm [32]. Thread-based programming paradigm cannot guarantee real-time performance. When multiple applications call the same software component at the same time, the response sequence of the component is uncertain and the time of information transmission between software components is unpredictable [33].

Technical challenges in software interaction remain largely unresolved, persistently hindering significant improvements in integration compatibility. As a result, industry organizations such as AUTOSAR and AUTOSEMO have been actively working to bring together relevant companies to establish standardized interaction interfaces, ultimately enhancing integration compatibility in the automotive industry.

3.2. Organizational Challenges of Initial Integration

Table 2. Organizational challenges of initial integration.

Organization	Challenges	Related Keywords	References
Organization structure	Cross-departmental conflict of interest	Low-cost, Efficient	[35,36]
	Repeated work across models and brands	Low-cost, Efficient	[37]
	Floating developers	Efficient, High-quality	[38]
Team	Lack of preparation for transformation	Efficient	[39]
	Lack of talent	Efficient, High-quality	[40,41]
Location	Distributed software projects	Low-cost, Efficient	[42,43]
External Cooperation	Collaboration across fragmentation standards	Low-cost, Efficient, Open	[44]

presents the organizational challenges faced during the initial integration stage, with a primary focus on organization structure, team, location and external cooperation.

3.2.1. Organization Structure

Traditional component-centric organizational structures create interest groups resistant to new architectures, causing platform-vehicle model incompatibilities [35,36].

Furthermore, for an OEM that owns multiple vehicle models and brands, different research and development project teams are often established for different vehicle models and brands. While the business objectives of these teams may differ to some extent, many technologies are actually generic, and redundant development can result in wasted integration testing resources [37].

Moreover, due to the existence of multi-model, multi-brand projects, it has been observed that an increasing number of developers are no longer confined to a single fixed team but may simultaneously participate in 3,4 projects and constantly switch between them [38]. This can easily lead to a loss of focus for developers, affecting the development of highly complex and safety-critical automotive functionalities. Discontinuous work tasks can also hamper continuous knowledge accumulation for developers, which is detrimental to their long-term growth. However, it is worth discussing that in our subsequent expert investigations, there are also views that shared developers between teams increases cross-functional collaboration within the organization.

3.2.2. Team

Deloitte’s interviews and workshops have revealed that most companies have not reached a satisfactory level in team building, with OEMs generally being less prepared than suppliers [39]. For example, there is a severe shortage of software talent reserves, and the decision-making authority of software leaders is not given sufficient priority. Additionally, internal software skill training mechanisms within companies are inadequate.

Even more critically, the supply of relevant talent in the industry is currently severely insufficient [40]. For instance, there is a shortage of test engineers and product managers for digital vehicles. It takes a long time to become an excellent automotive test engineer due to the need to learn and understand the products thoroughly. However, as the number of features on future vehicles increases, along with the interactions between these features, the industry’s talent supply struggles to meet the demand. Product managers for digital vehicles need to be able to understand user requirements promptly, allocate these requirements accurately and efficiently to specific software and hardware components, and ensure compatibility with other components. This demands product managers to have knowledge of both hardware and software, as well as possess architectural thinking skills [41]. Such multi-skilled talent is indeed scarce.

3.2.3. Location

Coordinating geographically dispersed software development projects can be highly challenging, as it involves risks related to knowledge management, task allocation, and stakeholder alignment [42]. The presence of diverse geographical locations, ethnicities, cultures, and societies further complicates communication and integration. Therefore, we have witnessed a growing trend of international OEMs establishing software development centers in China, which boasts the largest automotive market globally [43].

For example, a model development of a multinational OEM in 2021 involved teams in Germany and Shanghai (China). Time zone differences and cultural gaps led to misinterpretation of user interface requirements, resulting in a 3-month delay in finalizing the infotainment system’s touchscreen logic.

3.2.4. External Cooperation

At present, there are many software-related industry organizations in the automotive industry, and their focus points are different. For example, AUTOSAR pays more attention to the standardized middleware platform. AGL pays more attention to the OS kernel of Linux and the graphical user interface of upper application. COVESA pays more attention to the signal specifications and interfaces of connected vehicles. Beyond industry consortia, OEMs have further fragmented standards by developing proprietary ecosystems to differentiate their products. Standard fragmentation is particularly problematic in three high-impact areas:

• Middleware Interoperability: Middleware acts as the “glue” between hardware and software, but conflicting standards hinder cross-stack communication.
• OTA Update Standards: OTA has become a cornerstone of continuous integration, but the absence of universal protocols for update packaging, validation, and rollback creates chaos.
• Hardware–Software Co-Design: Digital vehicles demand tight hardware–software synchronization, but standards for hardware abstraction layers (HALs) and resource allocation are inconsistent.

These interoperability gaps not only increase integration costs and delays but also limit scalability [44]. As digital vehicles evolve toward cross-OEM service ecosystems (e.g., shared mobility or V2X networks), standard fragmentation risks creating isolated “technical silos” where vehicles from different OEMs cannot exchange critical data or leverage shared services.

3.3. Methodological Challenges of Initial Integration

Table 3. Methodological challenges of initial integration.

Method	Challenges	Related Keywords	References
Product Management	Non-uniform hardware test environment	Easy to debug, Manageable, Low-cost, Efficient, Scalable	[45,46]
	Complexity of software variants	Low-cost, Efficient, Manageable	[47]
Quality Control	Quality control after SW and HW decoupling	High-quality, Easy to debug	[48,49]
	Balance between quality and cost	Efficient, Safe, Manageable	[50]
Development Mode	Blind adoption of agile development	Efficient, High-quality, Manageable	[51]

presents the methodological challenges faced during the initial integration stage, with a primary focus on product management, quality control and development mode.

3.3.1. Product Management

For hardware, it is difficult for heterogeneous hardware platforms to ensure the compatibility of software components with the test environment. Heterogeneous hardware often needs multiple interoperable components when integrating with software, and each component may have multiple versions, which leads to many possible component combinations that require testing for integration [45]. At present, the platformization strategy adopted by most OEMs only unifies the subsystems of the same vehicle model size. A small number of leading OEMs may go further, realizing the connection between different platforms and sharing some hardware modules between different model grades. One of the main goals is to further disassemble the hardware module into unified parts and assemble them into different vehicle model sizes in the form of toolkit [46].

For software, there are several hundreds of variants for the same software in order to produce cars with different parameters adjusted for different landscapes, temperatures, altitudes, emission regulations, preferences of cultures, etc. [47]. With variants come the multiplicity of the complexity of code, architecture, requirements, and tests. Variants obscure code conformance to requirements and tests.

3.3.2. Quality Control

Traditional quality control focuses on hardware modules and subsystems of components. Since software is embedded within hardware, quality objectives are ultimately decomposed to the supply status of the components [48]. Quality agreements between OEMs and suppliers primarily emphasize the reliability and durability of the components. However, in the case of digital vehicles, software and hardware are decoupled and developed separately, sometimes even sourced from different suppliers. While quality objectives for hardware can still be decomposed, setting and measuring quality objectives for software becomes challenging, resulting in a state of confusion when assessing the quality of the final software–hardware integration [49].

The ideal situation for quality management is to control the total quality cost as low as possible. Due to reputational concerns, most OEMs tend to invest more in preventive costs in the early stages to ensure product quality upon delivery [50]. However, in the future, the relationship between quality and cost, already difficult to balance, will become even more complex due to the increased unpredictability of initial integration testing costs.

3.3.3. Development Mode

To speed up the pace of software development, more and more OEMs introduce agile development mode internally. However, there is a certain conflict between agile culture and the rigorous high-quality culture in OEM in the past, which leads to the great inadaptability of development and management teams in OEM [51]. Some specific problems will be introduced in Section 4.

For example, the charging function of a 2021 model rushed agile iterations without aligning with automotive safety standards. Bi-weekly sprints bypassed critical ISO 26262 [52] validation steps, resulting in software-induced brake latency issues that required regulatory approval for fixes.

3.4. Technical Challenges of Continuous Integration

Table 4. Technical challenges of continuous integration.

Technology	Challenges	Related Keywords	References
OTA Upgrade	Cross-version upgrade	Low-cost, Efficient, Manageable	[53]
	Matching of software and hardware	Scalable, Flexible	[54]
Standard Protocol	Software changes across middleware	Low-cost, Efficient, Open, Flexible, Scalable, Easy to debug	[55,56,57]

presents the technical challenges faced during the continuous integration stage, with a primary focus on OTA upgrade, toolchain and standard protocol.

3.4.1. OTA Upgrade

OTA upgrade is the primary method for releasing new software during the continuous integration stage. However, various compatibility issues arise due to the potential changes that may occur after the sale of the vehicle.

Different vehicles of the same model may have different software versions due to variations in production dates [52]. For example, cars produced this month may have software version V1.0, while those produced next month may have V1.1. Consequently, when the OEM intends to upgrade the software version to V2.0 at a later time, they face the challenge of cross-version upgrades. Some vehicles with V1.0 may need to be directly upgraded to V2.0 without going through V1.1 or V1.2. Furthermore, scenarios involving cross-version upgrades will become increasingly common, with both V1.2 to V3.0 and V2.1 to V3.0 upgrades coexisting. Although the ultimate goal of the upgrade is the same, the upgrade paths and the required software packages differ. This requires significant time and effort for enterprises to develop upgrade packages that are compatible with different versions.

As software continues to be updated, the richness of software in a vehicle, the complexity of its logical architecture, and the demand for data processing will increase [8]. This necessitates the use of more hardware resources. Therefore, many companies now employ a hardware reservation strategy to ensure that hardware performance matches the software’s requirements [53]. However, this introduces a problem: due to the considerable uncertainty associated with software upgrades, it is challenging to predict how much hardware resources should be reserved. If too few hardware resources are reserved, it not only fails to deliver an improved user experience but also increases the risk of resource consumption approaching its limits, leading to potential security risks. On the other hand, if too many hardware resources are reserved, it means that users are paying for hardware that they may not fully utilize. While this cost may be acceptable for luxury vehicles, it may not be suitable for the average consumer.

3.4.2. Standard Protocol

For OEMs with many brands, different brands often use different middleware platforms to meet the needs of different user groups [54]. For example, for luxury vehicles, middleware platforms tend to integrate more functions, while for affordable vehicles, more simplified middleware platforms are often adopted. In addition, the middleware platform on the mass production vehicle may be different from the middleware platform used for testing and simulation in the cloud. Because the vehicle middleware platform needs to be lighter, and the cloud middleware platform pays more attention to performance efficiency [55]. This also means that OEMs often need to deploy the same logical architecture and APPs on different middleware platforms. This leads to different code implementations of the same software logic on different middleware platforms [56]. In the continuous integration, when the logic architecture or APP is changed, OEMs need to make changes for different middleware platforms, which adds a lot of extra workloads.

3.5. Organizational Challenges of Continuous Integration

Table 5. Organizational challenges of continuous integration.

Organization	Challenges	Related Keywords	References
Long-term Operation	Maintenance of third-party software	Safe, Manageable	[58]
	Maintenance of open-source software	Safe, Manageable	[59]

presents the organizational challenges faced during the continuous integration stage, with a primary focus on long-term operation.

It is impossible for OEM to develop all the software by itself, so OEM will use many software products from suppliers or third parties, whose maintenance is a problem. Software has its own life cycle. In China, most OEMs promise a warranty period of 8 years for on-board computers (including software) of passenger cars in their websites or user manuals. There may be subtle differences in different countries, but this warranty period is significantly longer than that of mobile phones and PCs. If the third party or supplier only provides maintenance services for 5 years, how should OEM maintain the software after 5 years? Third-party software companies often cannot accept an 8-year maintenance period, and even the original development team may not exist after 5 years. If the OEM pays the maintenance fee to the third party, will the maintenance fee be paid after 8 years? Moreover, the software update and maintenance of suppliers depend on the return of software running data, but now many OEMs are reluctant to hand over a lot of data to suppliers to improve their control over the software [57].

Open-source software has similar long-term maintenance problems. When developing operating systems, middleware and even some application algorithms, OEMs will use some open-source components to reduce costs and speed up the time to market [58]. However, there are many bugs in open-source components, and no one is responsible for the bugs. For example, a European OEM used an outdated open-source audio codec library in the infotainment system, and there were unpatched loopholes. Due to the lack of in-house expertise, it took the OEM six weeks to solve this problem.

3.6. Methodological Challenges of Continuous Integration

Table 6. Methodological challenges of continuous integration.

Method	Challenges	Related Keywords	References
Software Risk Management	Functional safety risks of software changes	Efficient, Safe	[60,61,62]
	Accumulation of software faults	Safe, High-quality, Manageable	[63,64]
Process	Iteration rhythm	High-quality, safe, Easy to debug, Manageable	[65]
	Traceability	High-quality, safe, Manageable	[66,67,68]
	Implementation of CI/CD	Efficient, Safe, High-quality, Easy to debug, Manageable	[63,69]

presents the methodological challenges faced during the continuous integration stage, with a primary focus on software risk management and process.

3.6.1. Software Risk Management

Traditional automotive software development has typically emphasized software quality. However, during the continuous integration phase, automotive software operates in a state of continuous updates and changes, placing greater emphasis on software risk management [60].

Automotive functional safety requires whenever a new function or component is integrated in the system, violation of different qualitative and quantitative safety requirements needs to be evaluated [61]. It is reasonable to conduct complete safety analysis or complex quality inspection in the initial integration. However, it will be too complicated to conduct a complete safety analysis for every update in continuous integration. Taking fault tree analysis as an example, it is a top-down reliability analysis method, starting from the top event that needs to be analyzed, as the root of the fault tree, and gradually tracing down the cause of the event until the basic event [62]. For such a complex system as vehicle, a complete fault tree analysis will generate a towering tree, which needs to consume a lot of test resources.

Moreover, software defects can escape from one iteration to another in agile software development [63]. If a delivery containing undiscovered faults from Iteration N is used to add new functionalities for the upcoming deliveries N+, the undiscovered faults are also implicitly translated to these deliveries. Continuous updates and changes increase the likelihood of introducing new bugs, compatibility issues, or vulnerabilities [64]. For example, a Japanese OEM experienced progressive infotainment freezes after 8+ minor updates in 2023. Each update fixed immediate issues but introduced hidden conflicts, culminating in a system crash requiring a full factory reset in 12% of vehicles.

3.6.2. Process

Continuous integration extends the traditional automotive development process by introducing new workflows [1]. These new workflows require the capability to iteratively develop automotive software while ensuring traceability and delivering it to users at an appropriate pace.

Nowadays, many OEMs hope to release some new features to enhance user experience and improve user loyalty every once in a while. However, due to the poor communication between product planning and engineering R&D departments [39], sometimes it is difficult to complete the R&D and verification of new features before the planned release time, or the new features that have been developed are delayed until they are outdated. Rushing project can easily lead to quality issues with integration, while matching a reasonable development cycle for software release is a complex decision-making problem that needs to integrate risks, costs and benefits [64]. Different software and hardware have different iteration cycles. Different iteration cycles not only require enterprises to set up different development and maintenance teams, but also easily lead to incompatibility between software and hardware [8].

Traceability refers to establishing an association between test requirements and test execution results in the process of software development and testing to ensure that test requirements are met and can be traced back to test results [66]. Traditional automotive software development has strict processes to standardize traceability [67]. However, in the future digital vehicles, the software system needs to meet a variety of quality attributes, has heterogeneous functions, and has been developed by multidisciplinary stakeholders from different suppliers and OEMs for several years. Coupled with the agile iteration of software in its life cycle, it is a challenge to ensure the traceability of software [68].

Continuous integration or continuous delivery (CI/CD) is considered to be one of the most suitable development processes for frequent software upgrades in the era of Internet of Things [68]. However, for a complex system like automotive software, the entire CI/CD pipeline will become unprecedentedly intricate. Abazi et al. [63], through a case study and interviews conducted with two OEMs, found numerous challenges in the specific implementation of CI/CD regarding environment setup, integration channels, and testing time. The main reasons were attributed to the development tools employed, lack of synchronization among different stakeholders, and communication barriers with suppliers.

4. Potential Countermeasures

Among the 49 selected articles, many studies have proposed corresponding solutions or optimization suggestions for the identified challenges. OEMs have also successively put these ideas into practice. However, the degree of improvement in different challenges varies in the current context. This study compiled the perspectives of six experts on the effectiveness of current industry practices. Figure 4 presents the structured classification framework for automotive integration compatibility challenges proposed in this study, along with the quantitative results of the expert investigation. It can be observed that among the 26 challenges, 19 have achieved significant or partial improvement, and experts have expressed optimism about the further resolution of these challenges. This section systematically reviews these potential countermeasures, incorporates expert insights, and analyzes their effectiveness and limitations.

4.1. Countermeasures for Technical Challenges in Initial Integration

Against the challenges of complex feature dependencies and distributed software deployment (Section 3.1.1), leading OEMs have prioritized building specialized system architecture teams. These teams focus on optimizing feature coupling through modular design and establishing clear deployment rules for software–hardware mapping. As noted by Expert#1: “We’ve established a cross-functional architecture review committee that evaluates every new feature’s dependency chain before development. This has reduced post-integration conflicts by approximately 30%.” However, gaps remain: the expert further emphasized, “While architectural design has improved, dynamic changes in user requirements still lead to last-minute dependency adjustments, which our current processes struggle to accommodate.”

To tackle multi-kernel integration and software component interaction issues (Section 3.1.2), industry efforts have focused on standardizing interfaces and promoting middleware decoupling. AUTOSAR and COVESA-led initiatives aim to unify communication protocols, while OEMs have invested in hypervisor optimization. Expert#5 stated: “We’ve developed translation modules between AUTOSAR CP and AP, but real-time performance degradation in high-load scenarios remains unresolved.” For software component interaction, middleware standardization has reduced compatibility issues, but experts highlighted: “Thread-based programming in AP still introduces unpredictable response delays, especially in autonomous driving functions requiring microsecond-level precision.”

4.2. Countermeasures for Organizational Challenges in Initial Integration

To address cross-departmental conflicts, redundant work, and talent shortages (Section 3.2.1 and Section 3.2.2), many OEMs have transitioned to a “Three-Platform” organizational architecture (back-end: infrastructure and standards; middle-end: common capabilities; front-end: vehicle-specific implementation) [70]. Expert#4 explained: “The three-platform model has cut redundant R&D by 25% by centralizing common technologies, but middle-end and front-end teams often clash over priority allocation.” Moreover, OEMs have strengthened recruitment and internal training, with a focus on software–hardware hybrid skills [71]. Expert#3 noted: “We’ve partnered with universities to launch automotive software courses, but it takes 2–3 years to train qualified engineers, which lags behind industry demand”.

To mitigate issues with distributed projects (Section 3.2.3), OEMs have established local R&D centers in key markets. “Setting up R&D hubs in China reduced cross-time-zone communication delays by 40%,” Expert#2 reported. For external cooperation (Section 3.2.4), OEMs now participate in standard development with suppliers, but Expert#6 noted: “Collaboration across AUTOSAR, AGL, and COVESA is improving, but competing commercial interests slow down standard unification—only 60% of interfaces are fully compatible today.”

4.3. Countermeasures for Methodological Challenges in Initial Integration

For non-uniform hardware test environments and complex software variants (Section 3.3.1), OEMs have promoted hardware generalization and software product line engineering [72]. “Standardizing plug-in hardware interfaces reduced test environment costs by 35%,” Expert#1 stated, but added: “Heterogeneous legacy platforms still require custom adaptation, limiting the scope of generalization.” Software product line engineering has centralized variant management, but Expert#2 noted: “Over 200 variants per model still strain testing resources—we lack tools to automate variant compatibility checks.”

4.4. Countermeasures for Technical Challenges in Continuous Integration

For cross-version OTA upgrades and software–hardware matching (Section 3.4.1), OEMs have implemented regular version alignment and hardware reservation strategies [73,74]. “We now require all vehicles to align to a baseline version before major upgrades, reducing cross-version failure rates by 25%,” Expert#5 stated. However, hardware reservation remains problematic: “Over-reservation increases costs, while under-reservation risks performance bottlenecks—we lack data-driven prediction models for long-term resource needs.”

To address middleware differences (Section 3.4.2), OEMs have decoupled logical architectures from middleware and developed model compilers. “Compilers translate logical code to different middleware syntax, but runtime efficiency drops by 10–15%,” Expert#6 noted.

4.5. Countermeasures for Organizational Challenges in Continuous Integration

For long-term maintenance of third-party and open-source software (Section 3.5), OEMs have shifted from turnkey to lifecycle cooperation models with suppliers, establishing joint maintenance teams [75,76]. “We now include 8-year maintenance clauses in contracts, but third-party suppliers often demand premium fees,” Expert#1 revealed. For open-source software, Expert#3 admitted: “We rely on community updates, but critical vulnerabilities in niche components can take months to patch—no OEM wants to take ownership.”

4.6. Countermeasures for Methodological Challenges in Continuous Integration

The challenge of unbalanced iteration rhythms—rooted in poor coordination between product planning and engineering teams, and mismatched software/hardware update cycles (Section 3.6.2)—has prompted OEMs to establish structured release planning mechanisms. Leading practices include cross-departmental “release steering committees” that align business objectives with technical feasibility, and phased iteration strategies that prioritize critical updates. Expert#4 noted: “We’ve implemented quarterly release roadmaps with monthly alignment meetings between planning and R&D teams. This has reduced last-minute feature cuts by 40%, but market pressure to accelerate new features still forces us to compress testing cycles.”

Against the challenge of maintaining traceability in complex, agile-evolving software systems (Section 3.6.2), OEMs have invested in digital lifecycle management tools and standardized traceability frameworks [77]. These tools automate the association of requirements, design documents, test cases, and execution results across the software lifecycle. Expert#2 stated: “We use blockchain-based digital records to track every component’s version and test history, which has improved traceability compliance from 60% to 85%.”

5. Practical Pain Point

Although implementing countermeasures does not imply the complete resolution of a particular challenge, it indicates that OEMs have recognized the issues and are moving towards solutions. The current practical pain points are those challenges that OEMs have either not noticed or have noticed but do not know how to address. Figure 4 shows that experts have basically reached a consensus on the challenges that have not been significantly improved. This study synthesizes the opinions of six experts and boils down these challenges to two practical pain points, as shown in Figure 5.

5.1. Inadaptability to the New Development Model

The automotive industry, with its long-standing history, tends to be resistant to adopting other development cultures [78]. The expert investigation reveals that applying new development practices such as agile development and CI/CD directly has had negative impacts on integration compatibility, which can be summarized in the following four aspects:

• Agile development relies on task allocation as a prerequisite for improving efficiency [38]. Consequently, many software engineers in OEMs are not directly involved in coding but rather responsible for task allocation and outsourcing development [51]. The consequence of moving further away from the source code is a lack of knowledge when facing integration issues.
• Some development teams are forced to break down individual tasks into sub-tasks to meet the bi-weekly project milestones [51]. For software suppliers, excessively granular task packages not only introduce numerous meaningless milestones but also severely restrict the suppliers’ subjective initiative, making it challenging to address compatibility issues [79].
• Traditional automotive software development teams are accustomed to handovers and communication at project milestones after completing their own tasks, rather than engaging in proactive cross-functional communication during the development process [80]. This contradicts the communication principles of agile development and leads to many issues going unnoticed and becoming uncontrollable [81].
• The intensive agile cycles necessitate developers to anticipate the requirements of the next feature during the integration testing gap of the current feature [82]. Additionally, if there are bugs in the previous feature, developers need to find time within the current agile cycle to address them. This results in developers potentially being involved in 3–4 projects simultaneously, leading to potential quality risks.

To eliminate these negative impacts, comprehensive reforms are required across multiple dimensions, including organization, culture, manager, team composition, toolchains, and processes [83].

5.2. Prediction, Evaluation and Testing Methods of Software Problems

Since the introduction of digital vehicles into the consumer market, there have been an increasing number of news reports highlighting software issues in vehicles. Examples include black screens on the central control display, infotainment system lag, electronic brake failures, and remote hacking of vehicles [84]. These incidents clearly demonstrate the challenges that OEMs face in dealing with the rapid expansion of automotive software, making them somewhat helpless. This predicament cannot be resolved simply by discovering new methods or developing new testing tools. In fact, our research review indicates that many scholars have explored technical approaches to testing automotive software and achieved performance optimization in some small-scale case studies. However, in expert investigation, the consensus among most experts is that the majority of academic achievements are difficult to apply on a large scale in the industry, and even when applied, they have limited effectiveness. There are several main reasons for this:

• Many software errors are hidden at the source code level, and source code review can easily lead to intellectual property disputes [85]. Conflicts of interest prevent many methods and tools from being applied to software provided by suppliers.
• Predicting, evaluating, and testing software problems rely on a significant amount of prerequisite information, such as development requirements, architectural designs, dependencies, and coupling relationships [86]. In the real world, obtaining this information involves hundreds of teams from different companies, making it nearly impossible to acquire complete information.
• Automotive software exhibits strong heterogeneity [87]. Some software operates as black boxes based on AI networks, allowing only black box testing. Some software has complex coupling relationships with hardware, requiring highly specialized knowledge. Additionally, certain software involves extensive data exchange with the cloud, introducing unknown attack vectors. These software components also form a complex network of interactions, for which no universal approach can accommodate all components [88].
• Many academic research outcomes exist at the theoretical level, while the engineering implementations of automotive software integration testing standards, tools, and other aspects have already been solidified by industry organizations and major giant corporations [89]. This leaves OEMs with limited space for modification. The widespread application of new methods would require convincing the entire industry chain to switch.

6. Conclusions

This study provides a systematic review of automotive integration compatibility, structuring 26 distinct challenges and validating their practical relevance through expert investigation. Our analysis confirms that the most persistent pain points stem from a fundamental friction: the automotive sector’s struggle to adapt its established, quality-centric culture to the agile paradigms of software development.

Addressing these core challenges requires a paradigm shift. For researchers, a critical agenda emerges: developing hybrid models that embed safety and quality assurance within agile workflows. For practitioners, this means fostering new inter-departmental collaboration and investing in transparent, data-driven processes.

Furthermore, future research should extend this analysis to the unique integration challenges faced by small- and medium-sized enterprises (SMEs) and emerging suppliers, as their role is expected to grow with the increasing decentralization of the automotive supply chain.

One limitation of this study is that the literature retrieval based on keywords may not have covered all relevant research. Additionally, the scope of our expert investigation could be broadened to better distinguish between company-specific and industry-wide challenges.