A Perspective on Software-in-the-Loop and Hardware-in-the-Loop Within Digital Twin Frameworks for Automotive Lighting Systems

Abstract

The increasing complexity of modern automotive lighting systems requires advanced validation strategies that ensure both functional performance and regulatory compliance. This study presents a structured integration of Software-in-the-Loop (SiL) and Hardware-in-the-Loop (HiL) testing within a digital twin (DT) framework for validating headlamp systems. A gated validation process (G10–G120) is proposed, aligning each development phase with corresponding simulation stages from early requirements and concept validation to real-world scenario testing and continuous integration. A key principle of this approach is the adoption of a framework built upon the V-Cycle, adapted to integrate DT technology with SiL and HiL workflows. This architectural configuration ensures a continuous data flow between the physical system, the digital twin, and embedded software components, enabling real-time feedback, iterative model refinement, and traceable system verification throughout the development lifecycle. The paper also explores strategies for effective DT integration, such as digital twin-as-a-service, which combines virtual testing with physical validation to support earlier fault detection, streamlined simulation workflows, and reduced dependency on physical prototypes during lighting system development. Unlike the existing literature, which often treats SiL, HiL, and DTs in isolation, this work proposes a unified, domain-specific validation framework. The methodology addresses a critical gap by aligning simulation-based testing with development milestones and regulatory standards, offering a foundation for industrial adoption.

1. Introduction

Modern automotive development increasingly relies on virtual validation technologies to manage system complexity, ensure functional safety, and accelerate development cycles. Among these, Software-in-the-Loop (SiL), Hardware-in-the-Loop (HiL), and digital twin (DT) techniques have emerged as critical enablers for model-based verification. However, the existing literature tends to treat these approaches in isolation or apply them generically across various domains, without tailoring to domain-specific challenges, such as those present in adaptive lighting systems.

This paper addresses a significant gap in the current State of the Art: the lack of an integrated, traceable framework that combines SiL, HiL, and DT technologies into a single development and validation pipeline for automotive headlamp systems. The structure of this paper is as follows:

• After the introduction in Section 1, Section 2 presents the background on virtual validation technologies and outlines key standards such as AUTOSAR, ISO 26262 [1], and ASPICE while framing the need to adapt the well-established V-Cycle model to support DT–SiL–HiL integration in lighting validation contexts;
• Section 3 introduces the proposed multi-layered architecture, detailing the system, software, and digital twin layers, and defines abstraction levels (L0–L4) used in validation;
• Section 4 applies the framework to lighting-specific validation requirements, supported by case-based examples and lifecycle traceability;
• Section 5, Section 6, Section 7 and Section 8 address implementation aspects, including development gates, test environment integration, risk analysis, and system traceability;
• Section 9 provides a strategic outlook on the evolution of DT validation systems and future research directions;
• Section 10 concludes the study and highlights future applied research opportunities.

Software-in-the-Loop (SiL) involves testing software components in a simulated environment, where the software is executed on a virtual platform instead of physical hardware [2,3]. Hardware-in-the-Loop (HiL) complements this by integrating real hardware components into a simulated environment, allowing for real-time interaction and behavior assessment [4,5,6]. When combined with a digital twin (DT)—a virtual representation of the physical system—these methods provide a comprehensive validation approach: SiL verifies software logic early, HiL ensures real-time response, and the DT enables traceability, continuous monitoring, and predictive diagnostics throughout the system lifecycle [7,8,9].

While the integration of DT, SiL, and HiL technologies offers a promising path toward comprehensive validation, it also introduces a complex set of challenges that must be addressed for successful implementation. These challenges extend to multiple dimensions, including technical interoperability, real-time system requirements, data infrastructure, and organizational readiness [4,6,8].

From a technical standpoint, integrating virtual models with physical testing environments involves synchronizing systems that operate at different abstraction levels. Achieving seamless interoperability between digital twin (DT), Software-in-the-Loop (SiL), and Hardware-in-the-Loop (HiL) components requires the adoption of standardized communication protocols, precise time synchronization mechanisms, and model compatibility across heterogeneous toolchains and execution platforms [4,7,9]. Moreover, real-time processing constraints—particularly within HiL and SiL environments—demand high-fidelity simulation engines and deterministic communication interfaces, which are not always readily available or scalable [10,11,12,13].

Beyond the technical hurdles, operational challenges such as data accessibility, quality assurance, and scalability significantly affect system performance and reliability. Digital twins rely heavily on live, high-quality data streams to provide predictive insight and maintain model fidelity. However, many organizations face data silos, inconsistent formats, or proprietary systems that limit cross-domain integration and slow down development cycles [14,15,16].

Digital twin frameworks are rapidly becoming foundational in modern engineering, offering scalable, secure, and standardized ways to replicate physical systems virtually. The strategic importance of architectural and security guidelines for ensuring the robust deployment of DTs across cyber–physical networks has been emphasized in recent surveys [17]. In alignment with the goals of Industry 4.0 and sustainable European manufacturing, dedicated projects have shown how DTs can enhance intelligent lighting systems through real-time monitoring and AI integration [18]. This is particularly relevant for automotive applications, where DTs are increasingly used to support diagnostic processes and predictive maintenance. One approach demonstrates the use of a 3D-simulated environment with camera-integrated virtual lighting systems for classifying headlamp states using neural networks, with an accuracy of 80% under real-world conditions [19]. Another method combines digital signal analysis and machine learning to detect short-circuit LED failures, with precision exceeding 99% [20]. These targeted implementations complement broader efforts to model vehicle environments and behaviors for safer, more efficient road operation through DT-enabled visual recognition and simulation techniques [19].

In addition, organizational resistance to technological change, combined with skill shortages in simulation-based validation, can hinder adoption. The implementation of a DT–SiL–HiL framework requires not only advanced tooling and infrastructure but also a workforce trained in systems modeling, real-time simulation, and cyber–physical system design. Bridging these gaps demands investment in upskilling, as well as cultural alignment within engineering and quality assurance teams to embrace model-based verification methodologies [21,22].

This paper addresses these multi-dimensional challenges by proposing a process-oriented framework that strategically integrates SiL, HiL, and DT technologies into a cohesive validation environment for automotive headlamp systems. The aim is to define a unified and traceable methodology that aligns simulation-based testing with system requirements and industry standards.

2. Fundamentals and Terminology

This chapter provides a conceptual foundation for the validation and simulation approaches used in automotive lighting system development. It first introduces the core technologies of HiL, SiL, and DTs, outlining how each supports the virtual testing and integration of embedded systems. These techniques are essential for creating a safe and iterative development environment before physical prototypes are available.

The structure of this chapter also aligns with a V-Cycle testing model, which is widely adopted in automotive system engineering. The V-Cycle reflects the parallel relationship between system specification and verification stages, ensuring that each development phase is validated through a corresponding testing activity. Within this adapted V-Cycle, SiL and HiL simulations, as well as DT-based approaches, are strategically placed to cover both early software verification and late-stage system validation. Section 2.2 presents how this model applies to the stepwise development of automotive lighting systems, mapping typical industry gates (e.g., G10 to G120) to validation levels from concept to integration.

2.1. Hardware-in-the-Loop (HiL), Software-in-the-Loop (SiL), and Digital Twin (DT)

The concepts of HiL and SiL are integral parts of the V-Cycle development process, which is commonly used in the automotive industry.

HiL is a standard method for testing Electronic Control Unit (ECU) software in automotive development [23]. SiL testing involves generating code from Simulink models and deploying it on hardware devices [2].

DTs are used to create virtual representations of physical systems, allowing for comprehensive testing and validation in a controlled environment. This approach is particularly useful for testing complex systems like automotive lighting under various simulated conditions [24].

In the context of this review, we define a digital twin (DT) in alignment with the Basyx Asset Administration Shell (AAS) type 2 classification. This definition characterizes the DT as more than a static data container (type 1, i.e., a serialized AAS); rather, it is an active software entity deployed on a server. It exposes an interface—referred to as the front end in the Basyx framework—that allows interaction with other parts of the system, in our case, the operational environment. This interface provides access to both properties and operations, enabling runtime interaction. While a metamodel may also be included in accordance with the AAS type 2 specification, it is not essential for the discussion presented in this paper. Importantly, unlike a type 3 AAS, the DT defined here is not autonomous in initiating negotiations with other components. This distinction is critical because autonomous behavior in safety-critical systems—such as vehicle subsystems governed by ISO 26262—requires extensive validation and formal guarantees of functional safety. Limiting the DT to type 2 ensures that it remains predictable and verifiable, avoiding the introduction of runtime uncertainties that could compromise system integrity [25].

Figure 1 presents a V-Cycle representation adapted for automotive systems engineering with integrated DT functionality. The left branch of the V reflects the development workflow, beginning with system requirements and progressing through system-level design, component specification, and software implementation. Each layer incrementally refines the system architecture in preparation for integration and testing. The right branch represents the validation process, starting with HiL and SiL evaluations, advancing to integrated HiL/ViL (Vehicle-in-the-Loop) scenarios, and culminating in complete vehicle testing to ensure regulatory compliance and real-world performance. At the center, the DT serves as a cross-domain enabler, synchronizing data between virtual models and physical systems throughout the development lifecycle. This integration supports continuous monitoring, traceability, and predictive analytics, enhancing both early design validation and post-deployment feedback. The figure also emphasizes the shift toward a data-driven, simulation-supported validation strategy that aligns with current trends in automotive system digitization.

2.2. Automotive Lighting System Development Stages

Gantt charts are a popular tool for visualizing temporal discrete event sequences with dependencies, commonly used in manufacturing and computing [26].

Figure 2 illustrates a structured integration of DT technology into the development lifecycle of automotive headlamp systems. Each gate represents a critical validation point, ensuring continuous alignment between the DT framework and system engineering processes. The key gate activities are outlined as follows:

• G10—Initial DT Requirements: The system requirements—both functional and non-functional—are defined and analyzed from the perspective of the DT, ensuring that the DT-related needs are identified and aligned with the overall system objectives;
• G20—System DT Architecture: General system aspects are defined through the DT view, establishing a high-level structure that guides DT integration within the overall system architecture;
• G30—Concept DT Validation: This gate evaluates the feasibility of the conceptual DT representation. Verification activities include preliminary simulations and use–case alignment to confirm that the DT can represent essential system behaviors accurately at an abstract level;
• G40—SiL Integration with DT: The DT logic is integrated into the simulation environment to enable virtual testing and validation of system behavior during early development stages;
• G50—HiL Integration with DT: The DT components are connected to physical subsystems, enabling real-time validation of the system interactions;
• G60—Requirements Traceability via DT: This stage focuses on the behavior of test cases against the requirements, which are integrated with the DT concept to ensure complete traceability;
• G70—DT Calibration: This process aligns the DT with real-world data through calibration;
• G80—Scenario-Based Testing: This gate allows the DT to be tested across a wide range of real-world and edge-case scenarios, helping to assess system robustness, safety performance, and behavior under uncommon or critical conditions;
• G90—Analytics for DT-Based Diagnostics: Diagnostic analytics are integrated with the DT to enable fault detection, root cause analysis, and prognostics;
• G100—Standards Compliance Validation (via DT Simulations): DT-based simulations are used to verify compliance with industry standards and certification requirements;
• G110—Continuous Integration and Testing (CI/CT) with DT: The DT is incorporated into automated CI/CT workflows, supporting regression testing and continuous verification;
• G120—Final Deployment Readiness and Field Monitoring with DT: The final gate assesses deployment readiness, with the DT prepared for post-deployment monitoring.

To further demonstrate the systematic role of the DT in the development and validation of automotive lighting systems, we analyzed the implementation of functional and non-functional technical requirements across all 12 validation gates (G10–G120), as shown in

Table 1. Lifecycle validation of a lighting system requirement across DT development gates.

Gate	REQ_01_Lighting_Behavior	REQ_02_Fault_Response	REQ_03_Response_Time
G10	Define DT validation objectives for lighting: response time, beam compliance, system interaction	Identify fault detection timing and CAN signaling as critical diagnostic objectives	Define maximum acceptable ECU lighting response delay (200 ms)
G20	Structure the DT to modularly include lighting elements, sensor emulation, and ECU logic	Include diagnostic logic for LED/sensor fault injection in the DT model	Include timing paths and latency estimators in the DT
G30	Test early DT behaviors like auto-on under concept scenarios (e.g., entering a tunnel)	Evaluate error response through simulated fault injection scenarios	Evaluate logic-to-actuator delay through timing simulation in the DT
G40	Verify lighting control software in virtual conditions through DT-CAN message simulation	Simulate fault detection logic for various LED/sensor failure cases	Verify latency in signal propagation using SiL
G50	Assess real-time lighting system response with DT connected to hardware	Inject real-time faults and confirm ECU detection via HiL interface	Measure actual sensor-to-actuator delay on the HiL bench
G60	Link lighting requirements to test cases validated in the DT simulation framework	Trace fault detection events against expected fault model behavior	Document timing conformance with the requirement across configurations
G70	Use real measurements to adjust lighting model for beam intensity and distribution	Adjust DT to simulate varying fault severities (LED, power)	Calibrate model delays using real timing logs
G80	Simulate real-world events (fog, night driving) to test lighting safety and robustness	Create composite scenarios: LED fault + communication error during fog driving	Inject environmental load (fog, temperature) and measure response time
G90	Enable detection of lighting faults (LED failure, delay) via integrated analytics	Enable predictive analytics for fault detection and failure prediction	Predict delay risks using historical timing anomalies
G100	Verify DT behavior against lighting compliance regulations (e.g., UNECE)	Confirm diagnostic flow meets regulatory and OEM safety requirements	Validate conformance to latency standards (e.g., ISO), if applicable
G110	Automate lighting validation through DT in CI pipeline post-software updates	Run fault regression tests using CI-integrated DT model	Integrate timing benchmarks into nightly CI validation
G120	Monitor headlamp performance live using DT telemetry and support OTA updates	Enable real-time fault status tracking and analytics via cloud telemetry	Enable real-time latency tracking during fleet testing

. This approach highlights not only the relevance of the DT at each phase but also the coherence and traceability it enables throughout the entire lifecycle from early design to field operation.

The analysis shows that a well-defined DT can be aligned with each development milestone, acting as a central validation mechanism. In the early phases (G10–G30), the DT helps capture functional requirements and simulate key lighting behaviors in conceptual form. During integration phases (G40–G50), it enables both virtual (SiL) and real-time (HiL) testing, ensuring that software logic and physical subsystems respond appropriately to various input conditions.

From G60 onward, the DT becomes essential for maintaining traceability and realism. It links specifications to concrete test cases, incorporates real-world calibration data, and is capable of executing complex scenario-based tests (e.g., fog, curves, night driving). Advanced features such as predictive diagnostics (G90) and standards compliance simulations (G100) further extend its value. Finally, its integration into CI workflows (G110) and deployment environments (G120) ensures that lighting system behavior is continuously verified, even after release, enabling a feedback loop for over-the-air improvements.

3. Architectural Layers and Digital Twin Integration for Headlamp Systems

Modern headlamp systems have evolved beyond traditional electromechanical design and now function as complex, software-driven subsystems. Their performance relies on real-time integration with vehicle dynamics, environmental inputs, and adaptive control algorithms. To manage this complexity, contemporary development approaches employ a layered system architecture and leverage DT technology for early validation, logic testing, and continuous integration. This section presents a layered view of headlamp system architecture and discusses abstraction levels critical to simulation and testing.

3.1. Architectural Layers

To further clarify the functional content of the system and software architecture layers depicted in Figure 3, the system layer includes physical subsystems, such as ambient light sensors, camera-based perception units, LED arrays, stepper motors for beam adjustment, and the headlamp management ECU. These components interact via CAN FD communication and are powered through monitored supply lines.

Figure 3 presents an integrated view of the system and software architecture for an automotive headlamp system, illustrating the interaction between physical components, embedded logic, and their virtualization via the digital twin.

A practical example of how this layered architecture operates can be seen when a vehicle enters a short, unlit tunnel. In this scenario, the system layer detects the ambient light drop via onboard sensors and relays the signal to the lighting control ECU. The software layer evaluates this input and activates the headlamps through CAN FD-based control logic. The DT replicates the sensor signal and software response in a virtual environment, allowing engineers to verify system behavior, switching time, and compliance without physical testing.

3.1.1. System Architecture Layer

This includes the physical components such as lighting elements (e.g., LED matrices), actuators (e.g., stepper motors for beam adjustment), sensors (e.g., ambient light, rain, camera), and control ECUs (drivers). It defines how the headlamp unit interacts with the vehicle and the external environment.

3.1.2. Digital Twin Layer

The DT mirrors the behavior of the real-world headlamp system in a virtual environment. It simulates sensor input, hardware response, and environmental conditions to enable

• Early validation of software logic and control strategies;
• Scenario-based testing (e.g., glare detection, city/highway adaptation);
• Continuous verification of software changes without requiring physical hardware.

3.1.3. Software Architecture Layer

This layer encompasses the embedded control software, including functional algorithms (e.g., Adaptive Driving Beam control), middleware (communication stacks, diagnostic services), and safety components. Model-based design (e.g., Simulink, AUTOSAR) is commonly used here to support reusability and formal verification.

3.2. Abstraction Levels: L0, L1, L2, L3, and L4

To enable systematic virtual validation and efficient integration of DT technology into automotive headlamp systems, we define a multi-level abstraction model that structures the gradual evolution of the system from conceptual design to real-world deployment.

This layered approach provides a framework for organizing validation strategies according to system maturity and complexity. These levels reflect the increasing degree of system realism, from early behavioral modeling to full-scale DT deployment, and their ability to represent the real ECU and its physical environment. Figure 4 illustrates this progression, showing how DT involvement expands as the system moves from concept to test drives and finally to a fully integrated digital replica:

• L0 (conceptual validation) uses abstract behavioral models with minimal realism, focused on early functional exploration. DT involvement is limited, serving only basic traceability.
• L1 (Software-in-the-Loop) introduces executable code within a virtualized ECU, allowing early logic validation. The DT begins supporting behavioral tracking and input simulation.
• L2 (Hardware-in-the-Loop) blends virtual and real components, enabling validation of real-time behavior on physical hardware. The DT support increases, contributing to environmental modeling and prediction.
• L3 (test drive) integrates the DT with real-world driving tests, enabling parallel monitoring and scenario-based diagnostics.
• L4 (full DT integration) represents a fully bidirectional connection between virtual and physical domains, supporting high-fidelity simulations, predictive maintenance, and scalable validation of advanced lighting features.

3.3. Role of DT in Virtual Validation

Building upon the abstraction model introduced in the previous section, this part outlines the practical validation capabilities enabled by DT integration across the L0–L4 levels. The digital twin enables early-stage software verification, real-time interaction testing, and predictive analysis in both simulated and physical environments. In headlamp system development, these capabilities facilitate a shift from hardware-dependent validation toward proactive, model-based strategies aligned with AUTOSAR-compliant ECU architectures.

In practical terms, the proposed abstraction levels allow engineers to progressively develop and reuse models, test scenarios, configuration data, and validation results throughout the V-Cycle. For example, consider the case of an automatic headlamp function that activates an LED string. At the conceptual level (L0), the requirement is defined as a basic lighting behavior specification, described through logical flowcharts or functional diagrams without implementation. At the SiL stage (L1), the logic is implemented and tested in a virtual environment using simulated light sensor input. At L2 (HiL), the same logic is integrated with real hardware components—such as the ECU and lighting control unit—allowing engineers to verify switching behavior under real-time conditions and actual CAN messages. During L3 (test drive), the system is validated in a real vehicle under dynamic conditions, confirming performance under real-world scenarios. Finally, in L4 (DT), data from physical tests is reused to refine the digital representation of the system, enabling engineers to simulate similar lighting events without requiring physical testing setups. This structured flow ensures continuity across development levels and supports traceability, reusability, and increasing system realism.

4. Requirement Validation and Compatibility Analysis

4.1. Overview of Standards

AUTOSAR, an open and standardized automotive software architecture, separates application software from associated hardware to improve cost-efficiency and reusability [27,28]. Another key aspect of this concept is the modularity of the architecture, which enables the development of software components independently of specific hardware platforms or operating systems. This abstraction allows application developers to concentrate on software functionality without being constrained by ECU hardware variants or underlying operating environments [29].

Table 2. AUTOSAR-compliant digital twin framework for automotive validation.

Aspect	Details
Standard Overview	Leading architecture, global cooperation, separation of software and hardware, layered design
Digital Twin Integration	Service-oriented architecture, modular design, configuration, and automation
Testing and Validation	Dependability assessment, automated testing tools, model-based testing, virtual testing, and interface checks

illustrates the relationship between the key aspects and implementation details of automotive validation within an AUTOSAR-compliant distributed test framework. The integration of AUTOSAR standards with DT technology creates a traceable pathway from simulation to real-world deployment that is particularly valuable for complex systems like adaptive headlight controls or predictive maintenance architectures.

ISO 26262 is a critical standard for the development of automotive safety-related systems. It explicitly mentions HiL as a suitable test environment for software unit tests, integration tests, and verification of safety requirements at the component level [23]. This standard is mandatory for passenger car development worldwide and provides guidelines on the development and testing of automotive electronics, including lighting systems.

ASPICE is a process assessment model that provides a framework for evaluating the performance of automotive software development processes. It is often used in conjunction with ISO 26262 to ensure comprehensive compliance and quality assurance [30]. These standards facilitate the interoperability and efficiency of testing platforms, which is crucial for the effective use of digital twins in automotive lighting testing.

ASAM (Association for Standardization of Automation and Measuring Systems) standards, such as ASAM XIL, provide guidelines for the integration and automation of test systems, including HiL and SiL environments [31]. These standards facilitate the interoperability and efficiency of testing platforms, which is crucial for the effective use of digital twins in automotive lighting testing.

4.2. Case-Based Requirement Analysis

The DT process plays a significant role in the automotive industry, especially in the development of complex lighting systems. Validation of this process happens across several levels, each with a specific purpose. Initially, theoretical requirements are established through sketches, preliminary calculations, and risk analyses at the conceptual stage. This helps define general specifications and identify potential issues before starting development. Software algorithms are tested in a virtual environment, eliminating the need for physical components, verifying logic and performance, thereby reducing the requirement for early physical prototypes (SiL). Hardware components, such as ECUs or sensors, are tested by connecting them to a real-time simulator to validate system behavior under conditions close to reality (HiL). Finally, a complete virtual replica of the system is created, which is used for complex simulations and predictive analyses (DT). This allows real-time monitoring, performance optimization, and problem detection before physical implementation. This process strengthens development and reduces associated risks.

Table 3. Distribution of validation requirements across concept, SiL, HiL, and digital twin.

REQ	Concept	SiL	HiL	DT
1	—	✓	—	✓
2	✓	✓	✓	✓
3	—	—	✓	✓

✓: Requirement is validated/covered in this stage. —: Requirement is not validated/not applicable in this stage.

summarizes different validation requirements (REQs). Requirement 1 is validated primarily at the SiL and DT stages, reflecting the focus on software logic testing and advanced virtual simulation. Requirement 2 is covered at all stages—conceptual, SiL, HiL, and DT—indicating it is a fundamental aspect addressed throughout the entire development process, from early theoretical definition to real-time monitoring. Requirement 3 appears only at the HiL and DT stages, highlighting the need for physical hardware testing and comprehensive virtual replication to validate system behavior under realistic conditions.

Table 4. Progressive validation approach across Conceptual, SiL, HiL, and DT stages.

Requirement	Test Type	Input	Output
REQ_01_AdaptiveLight	Conceptual	Beam adjustment sketches	Theoretically validated concept
	SiL	Simulated data: car in the opposite direction	Beam was adjusted without glare
	HiL	CAN signal from real camera	Response < 50 ms
	DT	Three-dimensional environment with rain + traffic	Correct beam adjustment
REQ_02_ElectricalFault	Conceptual	Redundancy block diagram	Safety feature requirements
	SiL	CAN signal loss test	The system passes safely
	HiL	Short circuit injection	The headlight deactivates in controlled mode
	DT	Cascade defect simulation	System impact analysis

, analyzing the conceptual, SiL, HiL, and DT perspectives on each requirement, highlights the progressive validation approach embedded in the development process. At the conceptual stage, the focus is on theoretical validation. Beam adjustment sketches or redundancy block diagrams are used to define functional expectations early on, enabling risk identification before any implementation begins. In the SiL phase, simulated environments and software models validate control logic under virtual conditions, such as testing response times or handling signal loss, without requiring physical hardware. This allows fast iterations and early detection of logic or integration issues.

Moving into HiL, real components are integrated to test how the system responds to physical signals and disturbances, such as real camera inputs or fault injections. This stage brings virtual validation closer to reality by introducing tangible behaviors and interactions. Finally, the DT level provides a comprehensive, real-time simulation of the entire system within realistic scenarios—weather, traffic, and cascading faults—capturing complex interdependencies and verifying the system-wide impact. This layer closes the loop by enabling predictive analysis and performance optimization before physical deployment.

It is important to note that Table 3 and Table 4 present illustrative validation scenarios designed to demonstrate the structure and logic of the proposed framework. Although the data itself is fictional, the validation sequences and requirements reflect realistic engineering processes observed in current automotive development. The framework is, therefore, technically applicable in industrial contexts. Future work will focus on applying the method to empirical data obtained from actual headlamp system projects to further evaluate its robustness and integration potential.

While this paper does not report experimental prototyping or implementation of a full case study, its primary objective is to define a reusable and transferable validation structure that integrates SiL, HiL, and DT methods. The validation logic—though presented in abstract form—is grounded in common industry practices, and a pilot application is planned in future work to strengthen the framework’s empirical foundation.

5. Stage-Wise Role of SiL and HiL Across Development Phases

5.1. Applicability of SiL and HiL Testing

In the development of automotive lighting systems, selecting between SiL and HiL testing is not a matter of preference but rather a strategic alignment with system maturity and the complexity of requirements.

Software-in-the-Loop testing proves most effective in early development phases, where control logic and software algorithms must be verified quickly and without hardware dependencies. Simulated environments allow iterative testing under various scenarios, contributing to early fault detection and reduced development costs.

Hardware-in-the-Loop testing, by contrast, becomes essential when validating real-time interactions between software and physical components. For requirements involving precise response timing, safety-critical behavior, or physical signal processing, HiL is the only viable option. It enables the injection of realistic disturbances and ensures compliance with functional safety standards.

5.2. Strengths and Benefits of Each Approach

Software-in-the-Loop procedures offer speed, flexibility, and cost-efficiency. They allow high-frequency regression testing, support automated verification workflows, and facilitate the rapid prototyping of control strategies. SiL is well-suited for algorithm validation, internal communication, fault injection (e.g., signal loss), and early behavioral tuning.

Hardware-in-the-Loop procedures, on the other hand, provide critical realism. They validate signal integrity, actuator response, and the real-time performance of embedded systems under physical conditions. This is particularly important for tests where software behavior must react to sensor inputs or disturbances such as voltage spikes or CAN bus errors.

Together, SiL and HiL create a complementary validation chain: SiL accelerates early design loops, while HiL ensures that physical integration meets safety, timing, and hardware constraints.

5.3. Operational and Methodological Limitations

Software-in-the-Loop’s primary limitation is its lack of physical realism. Although high-fidelity models can simulate inputs, they cannot fully replicate the nuances of hardware timing, signal delays, or environmental noise. Moreover, performance on virtual ECUs may diverge from behavior on physical platforms due to timing discrepancies or resource contention. These limitations may be acceptable in many cases, especially when the development process favors early (unit) testing. Nonetheless, developers must remain aware of the reduced level of realism when interpreting results.

Hardware-in-the-Loop introduces realism but at the expense of scalability and cost. Setting up and maintaining a HiL bench requires specialized equipment, calibration time, and manual oversight. The iterative process slows down considerably compared to SiL, and hardware availability often becomes a bottleneck.

Both methods require careful planning to balance depth of coverage against cost, repeatability, and system maturity.

5.4. Test Coverage Across Development Stages

Digital twin technology involves creating a virtual replica of a physical system to simulate, predict, and optimize its performance. Both SiL and HiL testing play significant roles in the development and validation of DTs [32,33].

In a modern development pipeline, SiL and HiL are not mutually exclusive but are sequentially and iteratively integrated. A DT framework bridges both layers, enabling models and real hardware to synchronize through shared scenarios and data sets.

The Gantt-based development timeline introduced in Section 2.2 outlines a gated process (G10–G120) for integrating SiL, HiL, and DT technologies across the product lifecycle. This framework, presented in

Table 5. Test method distribution across development gates.

Gate	Activity Focus	Dominant Test Level	SiL Role	HiL Role	Digital Twin Role
G10–G30	System definition, design	L0	—	—	Initial requirement mapping
G40–G50	Logic and software validation	L1	✓	—	Simulation support
G60	Traceability and requirements	L1	✓	—	Documentation and linkage
G70	DT calibration	L2	✓	✓	Digital modeling foundation
G80–G90	Real-time validation	L2	✓	✓	Environment integration
G100	Integration pipeline	L3	✓	✓	Scenario orchestration
G110–120	Launch and operation	L4	—	—	Monitoring and analytics

✓: Method applicable/used at this development gate. —: Method not applicable/not used at this development gate.

, aligns validation methods with engineering milestones.

5.4.1. Phase I—Definition and Design (G10–G70)

G10–G30 focused on system requirements and early functional discovery. At this stage, conceptual validation (L0) is the dominant approach. In G40–G50, SiL is introduced to test control logic and virtual ECU behavior, independent of hardware. This phase enables the rapid iteration of software functions. G60 supports requirement traceability, connecting SiL outcomes to functional and safety requirements in preparation for physical validation.

5.4.2. Phase II—Validation and Integration (G70–G110)

The second phase begins with DT calibration within G70. Simulation environments are refined using data from prior SiL tests and physical system constraints. From G80 to G90, HiL testing enables real-time performance validation under realistic electrical and sensor conditions. Fault injection, timing analysis, and ISO 26262 compliance are key activities during this phase. At G100, a continuous integration and testing pipeline emerges, synchronizing SiL and HiL outputs within a centralized DT platform. Testing becomes iterative, coordinated, and traceable. Ultimately, G110 pre-deployment activities encompass scenario-based simulation, diagnostics, and operational readiness verification through hybrid test environments.

5.4.3. Phase III—Post-Deployment (G120)

In G120, the DT plays a monitoring role, tracking live system performance, detecting anomalies, and enabling predictive maintenance, eliminating the need for redundant physical revalidation.

6. Assessment of Integration Within Digital Twin

6.1. Deployment Readiness and Validation Depth

The simulation of real-world conditions within a DT framework depends heavily on the quality of the simulated environment, which must cover various driving scenarios, including diverse lighting and weather conditions. This allows for a comprehensive evaluation of the headlamp system’s behavior and performance [19,34]. By continuously monitoring the virtual model, potential failures can be identified and addressed early, thereby avoiding disruptions in the physical system. This predictive capability contributes to reducing both downtime and maintenance costs [35,36].

Digital twins also play a key role in developing and validating advanced safety functionalities such as Adaptive Front-lighting Systems (AFSs), which dynamically adjust the headlamp direction based on steering input to enhance driver visibility on curves [37].

An example of a real-world scenario simulation is illustrated in Figure 5, which shows the static driving simulator developed at Hochschule Karlsruhe (HKA). This system enables the immersive reproduction of complex road environments. Curves, varying illumination, and environmental stimuli can be reproduced consistently, making it a valuable platform for testing adaptive lighting systems in a repeatable manner. It is also conceivable that this setup lets test engineers include cases that are hard to encounter in test drives, like heavy fog, and vary the position of external illumination, like street lighting.

Moreover, such environments support proactive system monitoring. Using embedded sensors, including cameras, the simulator can collect behavioral data and establish feedback loops between the physical and virtual models. This supports predictive diagnostics by identifying anomalies, misalignments, or delayed responses in the lighting system.

Since the system is purely virtual, it also offers evaluation methods not available in physical test drives. As an example, it allows for the placement of virtual cameras freely in space, either static or relative to the movement of vehicles. This feature can be used to evaluate the effects of the lighting system on oncoming vehicles. By using virtual cameras, the test can be run for trucks, cars, and bicycles simultaneously by placing three different virtual cameras in the respective positions.

The functional behavior of the headlamp system is modeled using Simulink, allowing for modular representation and early verification of control logic. This model is intended to represent the lighting subsystem independently of vehicle-level interactions. To simulate and validate the broader vehicle context, including sensor signals, traffic, and interaction timing, the environment was emulated in CANoe. Within CANoe, system logic is expressed using CAPL (Communication Access Programming Language), which enables flexible simulation of driving conditions, lighting commands, and error handling. This separation allows the headlamp model to be tested both in isolation (SiL) and as part of an integrated virtual vehicle environment (HiL or DT) while maintaining a clear boundary between subsystem development and system-level validation.

6.2. Compatibility Between Test Levels and Requirement Types

The integration of SiL and HiL within a DT framework allows for a structured and scalable validation architecture, where each test level corresponds to specific requirement types. Functional and algorithmic requirements—often related to logic flow, data handling, or embedded algorithms—are most efficiently addressed through system-level (SiL) design during early development phases. In contrast, hardware-dependent or safety-critical requirements demand HiL validation, where real-time electrical signals and physical sensor feedback must be processed under realistic operating constraints.

Digital twin technology serves as a unifying layer that ensures traceability between requirements, simulation of artefacts, and real-world outcomes. It provides a bidirectional link that helps propagate insights and faults across all development levels. Rather than replacing SiL or HiL, the DT strengthens its impact by enabling continuous validation, synchronizing cross-domain data, and supporting test coverage extension with minimal physical effort.

6.3. Non-DT-Testable Requirements and Subjectivity

Digital twin technology does not yet fully address all categories of requirements. Certain specifications remain difficult or impossible to validate in an entirely virtual space due to their reliance on subjective interpretation, physical interaction, or unpredictable context sensitivity.

For instance, luminance-related requirements—such as achieving a minimum 1000 lx at a specified distance—can be evaluated through photometric simulation. However, real-world perception of glare, beam uniformity, and visual comfort depends heavily on individual user feedback and environmental influences, which are beyond the scope of current digital models.

Other examples of non-DT-testable requirements include cybersecurity robustness, where network-based threats and penetration vulnerabilities require real-world testing environments; aerodynamic behavior, which, while partially simulated, still relies on wind tunnel validation for certification; and mechanical tolerances in mounting structures, where fundamental assembly dynamics can introduce deviations difficult to replicate virtually. Additionally, subjective evaluations—such as visual quality, light tone appeal, or perceived system responsiveness—are inherently subjective and cannot be fully validated through DT simulation; therefore, they must be assessed through physical trials or user-based testing protocols.

These limitations highlight the need for hybrid validation strategies. Digital twins should be complemented with physical prototypes and field trials to fully capture user perception, aesthetic integration, and compliance with regulatory nuances. In such cases, the DT remains an indispensable tool, but one that must be integrated wisely within a broader test ecosystem.

7. Discussion and Open Questions

Despite the increasing adoption of DT frameworks coupled with SiL and HiL testing for automotive headlamp systems, several architectural and methodological gaps remain. Key challenges include insufficient traceability between system requirements and validation artifacts, limited scenario coverage—particularly for edge cases—and fragmented feedback loops across abstraction levels (L0–L4). Gate-based development flows often lack enforcement in hybrid test environments, leading to misaligned verification stages and latent functional risks. This section outlines these critical issues, examines infrastructure and tooling limitations, and integrates recent findings from the literature to define open questions for future standardization and implementation.

7.1. Identified Gaps in Current DT-Based Validation Approaches

Although the integration of SiL, HiL, and DT technologies offers a promising validation architecture for automotive lighting systems, several critical gaps remain. A key concern is the disconnect between theoretical requirements and their practical testability. Many requirements are defined at a conceptual level without being fully traceable by virtual or hybrid validation stages. This lack of end-to-end alignment creates ambiguity about what is being tested, how it is being validated, and with what level of confidence.

Additionally, there are integration gaps between abstraction levels, particularly between L3 (test drives with DT) and L4 (full DT integration). In many cases, feedback loops are fragmented or manual, preventing real-time synchronization between the physical system and its digital counterpart. Without a continuous, bidirectional data exchange pipeline, predictive validation remains narrow in scope. Finally, validation often emphasizes functional coverage under standard operating conditions while neglecting edge-case scenarios or rare environmental conditions that are crucial for safety and robustness.

Gate-based development processes (G10–G120) assume a sequential and coherent flow between design, integration, and validation phases. However, in real-world implementations, certain gates may be handled superficially or skipped entirely. For instance, if G60 (requirements traceability) is not thoroughly addressed before G80 (scenario-based testing), validation activities may be performed based on incomplete or unverified specifications. This misalignment between gates compromises the integrity of the testing process and risks passing systems that have not been fully evaluated.

Most validation workflows focus on common operational conditions. Yet, lighting systems must also function reliably under rare or extreme conditions, such as

• Reflective glare from wet roads;
• Dense fog that diffuses headlamp output;
• Snow occlusion on sensors;
• Interactions with vehicles having non-standard light signatures.

Neglecting these conditions leaves the system vulnerable to failure in critical real-world situations. Digital twins offer an opportunity to simulate these edge cases with high fidelity. However, this requires a rich library of scenario models and advanced simulation capabilities that are often missing or underdeveloped.

7.2. Infrastructure Requirements for Effective DT Feedback Integration

One of the key promises of DTs is the establishment of a constant feedback loop between the physical system and its digital representation. In practice, this feedback is often fragmented due to

• A lack of standardized protocols for real-time data exchange;
• Limited capabilities for collecting and synchronizing field data;
• Insufficient edge or cloud-based computing resources to process telemetry efficiently.

Without a robust and scalable digital infrastructure, the DT remains largely a static simulation model rather than a dynamic, real-time diagnostic and optimization platform. This limits its role in predictive maintenance, auto-calibration, and lifecycle performance management.

7.3. Underutilized Potential of Abstraction Layers (L0–L4)

The L0–L4 abstraction model provides a structured framework for progressive system validation, from conceptual modeling to complete system integration in real-world environments. However, its practical implementation is often inconsistent:

• L0 models are disconnected from downstream validation efforts and rarely reused.
• L1 (SiL) environments are limited to isolated logic testing, without direct traceability to requirements or outcomes at later levels.
• L3 and L4 stages are rarely implemented due to a lack of tools, data collection capabilities, or test infrastructure.

Recent studies further substantiate these findings and expand the contextual relevance of DT-based automotive validation. Eddy et al. [38] implement a digital twin for ground-vehicle predictive maintenance, integrating real telemetry, closely matching our assertion of necessary bi-directional data loops at abstraction levels L3–L4. A review in Advanced Engineering Informatics [39] emphasizes methodological requirement traceability in DT predictive maintenance systems, reaffirming our concerns regarding gaps in gate-based processes and edge-case coverage. In the area of cybersecurity, a survey in [40] outlines layered DT security challenges, offering systematic threat categorizations that align with and expand our discussion in Section 8.3. The issue that increasing connectivity of DT platforms exposes the validation environment to cybersecurity threats, such as unauthorized access and data falsification, has been notably addressed in another recent systematic review by El-Hajj et al. [41]. They analyzed 67 studies and highlighted common attack vectors, intrusion detection, spoofed telemetry, and vulnerabilities in IIoT-to-DT communication, as well as methods for ensuring data confidentiality and authentication. These findings substantiate our calls for proactive security measures, including lightweight secure communication, integrated intrusion detection, and robust encryption, even in resource-constrained validation setups.

7.4. Risk Analysis in Digital Twin-Based Validation Frameworks

The integration of DT, SiL, and HiL technologies in automotive lighting system validation introduces numerous benefits, such as accelerated development cycles, enhanced test coverage, and early defect detection. However, these advances also introduce a variety of risks that can undermine system safety, reliability, and regulatory compliance if not adequately managed. Timely identification and mitigation of these risks are critical to leverage the full potential of virtual and hybrid validation frameworks while maintaining trust in their outcomes.

There are five identified risks regarding requirement management and operational safeguards [42].

7.4.1. Risks Associated with Model Fidelity and Validation Gaps

A primary risk arises from discrepancies between digital models and their physical counterparts. Inaccurate or incomplete simulation models can lead to false confidence in system behavior, particularly for safety-critical functions such as adaptive headlamp control. These modeling errors may result from simplified or outdated environmental representations (e.g., lighting conditions, weather effects), insufficient coverage of edge cases and rare operating scenarios, and limited representation of sensor inaccuracies or hardware variability [43].

Examples are as follows:

• An adaptive headlamp system model used in a DT may simplify environmental factors such as fog density or wet road reflectivity. In a real-world scenario, the system might fail to correctly adjust beam patterns under heavy fog, causing glare to oncoming drivers. If this edge case is absent or poorly represented in the simulation, the false sense of system reliability could lead to hazardous conditions post-deployment;
• Simulation of sensor noise: If a camera sensor model does not accurately represent the noise characteristics caused by low light or dirty lenses, the system’s object detection reliability may be overestimated in the virtual tests;
• Failure to model hardware aging: An LED light’s luminance may degrade over time, but if the model only represents ideal initial conditions, maintenance schedules based on DT predictions may be inaccurate.

Failure to identify these gaps can cause undetected system faults, impacting vehicle safety and regulatory compliance. Rigorous model validation against empirical data and continuous model updates are necessary to minimize these risks [44].

Although it is possible to include all of these effects in high-fidelity models within the DT framework, organizations must ultimately determine an appropriate balance between the development effort and the anticipated return on investment. Beyond a certain level of complexity, further model refinement may no longer be economically justifiable.

7.4.2. Traceability and Requirement Coverage Risks

The complexity of requirements mapping across SiL, HiL, and DT environments poses risks related to incomplete or ambiguous test coverage. Insufficient traceability may lead to omission of critical functional or safety requirements during simulation, validation activities performed on outdated or unverified specifications, and misalignment between virtual test results and physical system behavior [45].

Examples include the following:

• Suppose a safety requirement mandates automatic dimming of high beams when oncoming traffic is detected at night. If this requirement is not properly linked to test cases in the HiL validation phase, the software controlling this function might be insufficiently tested, leading to failures not caught before vehicle release;
• If regulatory requirements for glare limits change late in the project, and the updated requirements are not propagated to all simulation environments, the test results may reflect outdated compliance criteria, risking certification delays or recalls.

This risk emphasizes the need for robust requirements management frameworks that maintain end-to-end traceability [46], ensuring that all requirements are systematically addressed through corresponding test cases at appropriate abstraction levels.

7.4.3. Cybersecurity Risks in Connected Digital Twins

The increasing connectivity of DT platforms exposes the validation environment to cybersecurity threats, as extensively presented in Section 8.3. Given the safety-critical nature of automotive lighting systems, such breaches could compromise validation integrity and vehicle operation; thus, embedding cybersecurity measures, such as encrypted communications, access control, and intrusion detection, is imperative [47].

Examples include the following:

• In 2023, a reported cybersecurity incident involved unauthorized access to a cloud-hosted DT environment used for vehicle software validation. Attackers manipulated test parameters, causing false positives in safety tests that could have masked latent system defects [48];
• Injection of false telemetry data into a digital twin during operational monitoring may lead to incorrect maintenance decisions;
• Denial-of-service attacks may occur that disable remote simulation capabilities during critical validation phases.

7.4.4. Operational and Deployment Risks

Post-deployment, the DT is leveraged for continuous monitoring and predictive maintenance. However, this phase involves risks related to reliance on telemetry data quality, which may be affected by sensor failures or communication losses, model drift over time as physical system behavior deviates due to aging or environmental factors, and inadequate responsiveness of the DT to emerging fault conditions, leading to missed or late anomaly detection [49].

Examples are as follows:

• A fleet of vehicles equipped with headlamp DTs experienced a sudden drop in anomaly detection accuracy after a firmware update altered sensor calibration characteristics. The DT models, based on prior calibration data, failed to adapt promptly, delaying fault detection and potentially risking driver safety;
• Telemetry loss may occur due to poor cellular coverage during vehicle operation, resulting in gaps in DT data streams;
• Model drift caused by environmental factors such as extreme temperature variations not accounted for in the initial DT calibration may occur.

Operational risk management must include validation of telemetry integrity, adaptive model updating mechanisms, and fail-safe procedures to handle detected anomalies.

7.4.5. Risk Mitigation Strategies

Effective risk management requires a balanced combination of technical solutions and organizational practices. A multifaceted approach is necessary to ensure the safety, reliability, and compliance of automotive lighting systems across all stages of validation and deployment.

First, comprehensive validation practices must be adopted by leveraging multi-level testing. This includes a systematic combination of SiL, HiL, and physical testing methods to cross-verify results and identify discrepancies or gaps in system behavior that might not be evident in any single validation environment. This layered approach helps ensure robust coverage of both functional and safety-critical requirements.

Second, the use of advanced traceability tools is essential. Requirement management systems that are integrated with simulation and testing platforms can facilitate consistent coverage, transparent traceability, and full auditability of validation activities. Such tools support alignment between requirements, test cases, and simulation results, reducing the risk of overlooked functionalities or misaligned specifications.

Third, a cybersecurity-by-design philosophy should be embedded from the early stages of DT development. This involves integrating cybersecurity measures such as encrypted communication protocols, access control mechanisms, and intrusion detection systems in accordance with established standards like ISO/SAE 21434 and UNECE WP.29. Early incorporation of these safeguards helps protect the integrity of both virtual validation environments and deployed systems [50].

Fourth, continuous monitoring and feedback loops between the physical system and its digital twin should be established. This bi-directional data flow enables real-time tracking of system performance, early detection of deviations, and adaptive model updates. Such mechanisms are particularly important in the post-deployment phase, where operational risks due to model drift or sensor degradation must be proactively managed.

Finally, hybrid validation strategies should be implemented by balancing the efficiency of virtual testing with the realism of physical trials. While simulation offers speed and flexibility, targeted physical tests remain indispensable for validating mechanical interactions and subjective performance aspects, such as optical quality and user perception of adaptive lighting.

Examples include the following:

• A leading automotive supplier implemented a hybrid validation approach combining extensive SiL and HiL testing with periodic physical validation runs in climatic chambers simulating diverse weather conditions. This approach uncovered discrepancies in sensor response under heavy rain, which were corrected before production;
• Automated traceability tools should be deployed that alert engineers to missing test cases when requirements change;
• ISO/SAE 21434-compliant cybersecurity frameworks should be implemented to protect DT environments using multi-factor authentication and encrypted communications [51];
• Machine learning algorithms should be used to monitor telemetry data quality in real time and trigger model recalibration when deviations are detected [52].

In

Table 6. Categorization and management of risks in digital twin implementation.

Risk Category	Likelihood (1–5)	Impact (1–5)	Risk Score (L × I)	Risk Level	Mitigation Strategies
Model fidelity and validation gaps	3	5	15	High	Rigorous model validation with empirical data; continuous model updates; extensive coverage of edge cases and scenarios
Traceability and requirement coverage	3	3	9	Medium	Robust requirements management systems; maintain end-to-end traceability; automated test mapping
Cybersecurity in connected DTs	3	5	15	high	Cybersecurity-by-design; encrypted communications; access control; intrusion detection aligned with ISO/SAE 21434
Operational and deployment risks	4	3	12	Medium-high	Validate telemetry data integrity; adaptive model updating; fail-safe procedures for anomaly detection
Risk mitigation strategy effectiveness	2	4	8	Medium	Continuous process improvement; regular audits; integration of cross-functional teams to enforce mitigation adherence

, a semi-quantitative assessment of key risks associated with the integration of a DT, SiL, and HiL in automotive lighting system validation is presented, which is widely used in systems engineering and model-based development for emerging validation technologies. Each risk category is evaluated based on two critical dimensions: likelihood (the probability of the risk occurring) and impact (the severity of consequences if the risk materializes). Both dimensions are scored on a numeric scale from 1 (lowest) to 5 (highest), based on a hypothetical evaluation intended to illustrate the risk management approach. The risk score, the product of likelihood and impact scores, provides an effective metric for prioritizing mitigation actions when historical failure data or quantitative probabilistic models are not available. This approach is particularly suited for hybrid SiL/HiL/DT validation environments, where conventional Failure Mode and Effects Analysis (FMEA) may be either premature or computationally impractical due to dynamic model granularity, variable abstraction layers, and evolving requirement sets. The 1–5 scale corresponds to defined bins of probability and consequence thresholds adopted from ISO 31010 [53]-aligned risk matrices. As the DT validation process matures, this framework can be extended to integrate more formalized risk estimation models. Mitigation strategies outline targeted technical and organizational measures designed to reduce the occurrence or consequences of each risk. These mitigations represent best practices and industry standards tailored to the unique challenges posed by virtual and hybrid validation environments.

High-risk areas such as model fidelity and cybersecurity require proactive management strategies, including rigorous model validation, continuous synchronization, and robust security protocols. Medium-risk categories underscore the need for integrated requirements management and operational safeguards. By quantitatively prioritizing risks, this approach supports the development of targeted mitigation plans, enhancing the safety, reliability, and regulatory compliance of automotive lighting systems validated via DT, SiL, and HiL technologies.

8. Application Challenges and Strategic Directions for Digital Twin Integration

The increasing complexity of automotive systems and the transition toward model-based development paradigms have catalyzed the use of DT technology across engineering workflows [54,55]. In the context of headlamp system validation, DTs offer simulation-based platforms that complement SiL and HiL testing [19] by enabling continuous integration, scenario-driven validation, and early design verification. However, the general adoption of DTs in industrial settings is limited by a combination of technical, organizational, and regulatory barriers [51,56].

This section explores the current limitations of DT integration. It outlines strategic directions that aim to address these barriers, thereby facilitating the scalable deployment of DT frameworks across the automotive lifecycle.

8.1. Practical Scope of Digital Twin Utilization in Automotive Development

Digital twin technology has the potential to support multiple functions across the design–validation–deployment continuum:

• In early development, DTs can be used for virtual prototyping and functional modeling, enabling engineers to explore design alternatives without physical prototypes;
• During the SiL and HiL stages, DTs support real-time simulation of hardware–software interactions, augmenting traditional test platforms through model-driven fault injection, scenario orchestration, and predictive behavior analysis;
• In the post-deployment phase, DTs allow for continuous monitoring, performance analytics, and remote diagnostic capabilities. By leveraging vehicle telemetry, they support condition-based maintenance, dynamic calibration, and long-term operational optimization.

Beyond these stages, DTs may also be used in

• Manufacturing process validation by modeling assembly line behavior and tolerances;
• Fleet-level analysis by aggregating DT data across vehicle populations to identify systemic reliability trends;
• Human-in-the-loop simulation by reproducing user inputs and their impact on vehicle systems.

While these use cases are technically feasible, integration across the entire lifecycle remains uncommon, primarily due to ecosystem fragmentation and resource constraints.

8.2. Barriers to Deployment: Organizational, Technical, and Cultural Factors

8.2.1. Skills Gap and Organizational Resistance

A significant obstacle to the deployment of DTs is the shortage of interdisciplinary expertise. Effective DT integration requires the convergence of systems engineering, embedded software, real-time simulation, and cybersecurity—disciplines that are often separated within traditional automotive organizations.

Moreover, development teams often show inertia toward replacing well-established test procedures with simulation-driven workflows, especially for safety-critical systems. This highlights the need to establish dedicated DT specialists with cross-domain proficiency in model integration, physical-to-virtual synchronization, and secure data handling.

Organizational resistance may also stem from perceived risks related to the reliance on virtual models over physical validation. Overcoming this challenge requires the establishment of robust test traceability, quantitative validation metrics, and continuous alignment between DT predictions and empirical outcomes.

8.2.2. Tool Fragmentation and Lack of Standardization

Digital twin integration is further complicated by the heterogeneity of simulation tools and the lack of standardized modeling formats [8]. Inconsistent model exchange formats, time synchronization mechanisms, and interface semantics impede interoperability between tools used in SiL, HiL, and DT workflows.

Despite efforts by standardization bodies, such as AUTOSAR, ASAM, and the Modelica Association [57,58], practical interoperability remains limited. Test artifacts developed in SiL environments often cannot be reused seamlessly in HiL or DT settings, which leads to redundant engineering effort and reduced efficiency in regression testing and requirement verification.

8.3. Cybersecurity Considerations for Connected Digital Twins

As DTs increasingly operate in connected environments—integrated with in-vehicle networks, cloud-based analytics platforms, and over-the-air (OTA) update systems—they introduce a new class of cybersecurity risks. These include

• Data spoofing attacks, where manipulated sensor inputs are injected into the DT, leading to invalid conclusions or inappropriate responses;
• Model leakage and IP theft, as adversaries could reverse-engineer simulation models or extract system parameters through observation of DT outputs;
• Attacker training, as attackers could practice and evaluate attacks virtually with little risk of detection;
• Unauthorized access to test interfaces, which potentially compromises the integrity of the test environment or allowing command injection into safety-critical systems.

These risks necessitate a cybersecurity-first approach to digital transformation (DT) architecture. To mitigate vulnerabilities, future DT platforms should implement

• Encrypted communication protocols to safeguard data exchange between components and external systems;
• Isolated model execution sandboxes to prevent cross-domain interference;
• Secure and restricted interface layers to limit access strictly to authenticated and validated simulation APIs.

These risks underscore the importance of embedded emerging automotive cybersecurity regulations, such as ISO/SAE 21434 [51], into DT lifecycle management and test documentation practices. Aligning DT architectural practices with these standards ensures compliance with both industry expectations and related regulations, such as UNECE R.155 [52], which mandates certification of cybersecurity management systems for type approval.

8.4. Strategic Directions for Scalable DT Integration

8.4.1. Role Specialization and Workflow Integration

To achieve scalable DT deployment, responsibilities across the development team must be clearly defined:

• System architects must design DT specifications aligned with functional and non-functional system requirements;
• Simulation engineers must be tasked with building high-fidelity models and managing physical–virtual synchronization;
• Cybersecurity engineers must evaluate threat surfaces and embed protections at both interface and model levels;
• Validation experts must translate real-world scenarios into reproducible simulation-based test cases and verify requirement coverage.

Such role-based structuring allows for modular development and efficient lifecycle management of the DT environment [59].

8.4.2. DT-Driven Certification and Homologation

One of the most transformative directions for DT is its potential use in regulatory compliance. By digitally signing simulation results and ensuring a version-controlled traceability of test cases, DTs could become part of certification dossiers [54]. This would reduce the physical testing burden while improving repeatability and auditability of functional safety evaluations.

Simulation-based certification is particularly promising for

• Adaptive headlight performance under variable weather conditions;
• Failure mode validation in redundant lighting architectures;
• System behavior in pre-defined regulatory scenarios.

8.4.3. Cloud-Based Digital Twin-as-a-Service (DTaaS)

The advancement of cloud-native automotive architectures has paved the way for digital twin-as-a-service (DTaaS) solutions that align with modern vehicle development workflows. Within these frameworks, digital twin instances can be deployed dynamically in secure cloud containers to support scalable simulation and validation tasks. Simulation workloads are distributed across OEMs, enabling seamless collaboration throughout the supply chain. Centralized repositories ensure version control and traceability of test results, promoting consistency across development stages and supporting compliance with functional safety and cybersecurity standards [60,61,62].

This DTaaS model fosters collaboration, promotes traceable development practices, and aligns with agile methodologies, including continuous integration and deployment (CI/CD) pipelines. Its advantages have translated into significant real-world benefits. Automotive manufacturers have integrated DTaaS into R&D and supply chain operations, leveraging virtual prototyping to reduce vehicle development cycles by 30%. A major Swedish electric vehicle OEM reported a 40% reduction in battery testing costs through DTaaS-based thermal behavior simulations under extreme conditions [63]. Over 60% of automotive companies now prefer per-use pricing for DTaaS in production line optimization, avoiding fixed costs amid seasonal demand fluctuations. However, this shift to flexible pricing and scalable deployment does not eliminate barriers, especially for smaller enterprises. Small and Medium Enterprises (SMEs) continue to face prohibitive upfront costs. For instance, a German automotive parts supplier terminated its DTaaS pilot upon discovering a USD 120,000 platform setup cost—nearly 15% of its annual IT budget—making it economically unjustifiable [64].

8.4.4. Toward a Hybrid Validation Strategy: Blending Virtual and Physical Testing

Although DTs substantially reduce the need for physical prototyping, some validation tasks remain inherently physical [29]. These include

• Visual comfort assessments, such as perceived glare or light tone consistency;
• Mechanical durability and mounting stress validation;
• Electromagnetic compatibility (EMC) and cross-interference testing;
• Subjective user acceptance testing under real driving conditions.

Rather than viewing physical and virtual validation as competing paradigms, the future of automotive testing lies in a hybrid strategy that integrates

• The use of DTs to reduce prototype cycles and optimize test parameters;
• Selective validation of edge-case findings through physical test rigs;
• The establishment of bi-directional feedback loops from real-world usage into DT updates.

A hybrid validation strategy, integrating both DTs and physical testing, is pivotal in advancing automotive development. This approach leverages the scalability and efficiency of virtual simulations alongside the fidelity and assurance provided by real-world testing, ensuring comprehensive validation across the vehicle lifecycle. Digital twins facilitate early-stage validation by enabling high-fidelity simulations of vehicle systems, allowing engineers to test a multitude of scenarios in a controlled virtual environment. Given the example of a major Nordic OEM [65], its autonomous solution employs a closed-loop simulation setup where control signals are directed to both real trucks and their digital twins. This method, encompassing SiL and HiL testing, allows for the detection of software and hardware integration issues, latency effects, and timing bugs before physical deployment. However, certain aspects of vehicle performance, such as visual comfort, mechanical durability, and electromagnetic compatibility, necessitate physical validation. These real-world tests ensure that the vehicle meets safety standards and user expectations. By focusing physical testing on these critical areas, manufacturers can optimize resource allocation and reduce costs. The integration of virtual and physical testing also supports regulatory compliance. Combined documentation from both approaches provides a comprehensive audit trail, facilitating traceability and reproducibility, which are important in meeting stringent safety and environmental standards. Moreover, the continuous feedback loop between virtual simulations and physical tests allows for the refinement of digital models. Incorporating real-world data into digital twins enhances their accuracy, leading to more reliable predictions and improved vehicle performance over time.

In summary, this section presents key strategic avenues for scaling DT integration in automotive development. These include clear role specialization across interdisciplinary teams, simulation-based certification workflows aligned with evolving safety regulations, the adoption of cloud-based DTaaS models for scalable collaboration, and hybrid validation strategies that blend virtual and physical testing. Addressing current barriers—such as cybersecurity risks, toolchain fragmentation, and organizational resistance—will be critical to realizing the full potential of DTs across all development stages.

Ultimately, a hybrid validation strategy that combines the scalability and speed of digital twins with the assurance and realism of physical testing offers a balanced path forward. This dual approach enhances the efficiency, adaptability, and overall quality of modern automotive systems.

9. Strategic Outlook for Next Generation Validation Systems and Research Direction

The integration of DT, SiL, and HiL technologies marks a pivotal shift in the evolution of automotive system validation. As embedded systems become more complex and regulatory demands increase in terms of traceability and functional safety, traditional validation workflows—based on sequential prototyping and isolated test benches—are rapidly reaching their limits.

Next-generation validation environments must support distributed, parallel, and multidisciplinary development processes. SiL and HiL components, together with DT services, must operate as orchestrated subsystems within a unified architecture. There is a growing need for scalable simulation platforms that are capable of real-time synchronization, modular deployment, and remote co-simulation, enabling OEMs and suppliers to collaborate effectively without relying on localized physical setups.

To unlock the full potential of DTs in industrial and regulatory contexts, validation artifacts must evolve into certifiable assets. Simulation outputs, test cases, and model configurations should be version-controlled, digitally signed, and aligned with safety standards such as ISO 26262 and ISO/SAE 21434. This transition requires the implementation of formal model verification workflows, traceability tools, and simulation-driven homologation processes. Certification bodies must also adapt to simulation-first validation pipelines, particularly for systems that undergo frequent updates.

Looking beyond development environments, digital twins are expected to function as real-time operational mirrors, continuously fed with vehicle telemetry. This capability would enable predictive maintenance, adaptive headlamp calibration, and in-service anomaly detection. Such feedback mechanisms demand secure cloud infrastructure, high-fidelity sensor emulation, and real-time data pipelines that minimize divergence between virtual and physical system states.

Despite strong progress in technical validation, current DT frameworks still struggle to address subjective and perceptual performance criteria, such as visual comfort, glare perception, and driver behavior under dynamic lighting conditions. These aspects are naturally difficult to simulate and often require human-in-the-loop feedback, experimental studies, or VR/AR-based testbeds. Future research should explore how these perceptual and behavioral dimensions can be embedded into simulation workflows to extend validation coverage beyond purely functional metrics.

Several cross-cutting priorities also emerge: the adoption of open modeling standards (e.g., ASAM XIL, Modelica, FMI) to ensure toolchain interoperability; the use of AI-augmented testing to generate edge-case scenarios and uncover non-obvious failure modes; and the integration of cybersecurity validation, embedding threat simulations, anomaly detection, and secure interface testing into the DT framework.

By consolidating these directions into a coherent and forward-looking approach, validation shifts from being a final quality gate to becoming a continuous, intelligent, and predictive process embedded throughout the product lifecycle. This paradigm lays the groundwork for a new era in automotive engineering, where systems are not only tested for compliance but designed for resilience, adaptability, and long-term performance.

10. Conclusions and Future Work

This paper proposes an integrated validation framework that combines digital twin, Software-in-the-Loop, and Hardware-in-the-Loop technologies, specifically tailored for automotive headlamp systems. The study contributes a layered architecture model, a structured requirement-to-validation traceability approach, and scenario-based validation examples that align with industry practices and standards.

The framework emphasizes the transition from fragmented test stages to a unified validation pipeline that supports predictive, modular, and simulation-driven engineering. The use of conceptual validation chains and synthetic examples illustrates the practical relevance of the approach, even in the absence of physical prototyping.

However, the study has several limitations. First, it does not include empirical implementation results or a full pilot case study. The validation scenarios are demonstrative, although grounded in realistic automotive challenges. Furthermore, the evaluation does not yet cover subjective metrics, such as visual comfort or real-time driver feedback, which are increasingly important in lighting system performance.

Future research should focus on implementing the proposed framework within an industrial development project, allowing for quantitative performance assessment and real-world system integration. Additionally, research should explore the inclusion of human-in-the-loop simulations, cognitive feedback, and AI-assisted edge case generation. These extensions will help refine digital twin-based validation workflows into operationally relevant tools for both OEMs and regulatory stakeholders.