A Model-Based Design and Verification Framework for Virtual ECUs in Automotive Seat Control Systems

Abstract

As automotive software continues to grow in scale and timing sensitivity, hardware-independent verification in the early design phase has become increasingly important—especially for safety-critical, body-domain controllers. This study proposes a framework that integrates MBD (Model-Based Design), AUTOSAR (Automotive Open System Architecture) Classic Platform configuration, and vECU (Virtual Electronic Control Unit) execution into a single, repeatable development workflow. Control logic validated in Simulink is translated into AUTOSAR-compliant software, built into a QEMU (Quick EMUlator)-based vECU, and exercised in DRIM-SimHub using both virtual stimuli and a real sensor–actuator signal delivered through a dedicated I/O interface board. Using a seat–slide virtual limit controller as a representative case, the proposed workflow enables consistent reuse of the test scenarios across model-in-the-loop (MiL), software-in-the-loop (SiL), and virtual ECU stages, while preserving production-level timing behavior and the semantics of the AUTOSAR runtime. The experimental results show that the vECU accurately reproduces the PWM outputs, Hall sensor pulse timing, and limit–stop decisions of physical ECU, and that integration issues previously discovered only in HiL tests can be exposed much earlier. Overall, the workflow shortens verification cycles, improves the observability of timing-dependent behavior, and provides a practical basis for early validation in software-defined vehicle development.

1. Introduction

The automotive industry is undergoing rapid shift, driven by electrification, advanced driver assistance systems, connectivity, and the move toward software-defined vehicles (SDVs) and highly integrated electrical/electronic (E/E) architectures [1,2,3,4]. As vehicle functions become more intelligent and service-oriented, the volume of embedded software increases, along with the variety of their functions and interdependencies. This expansion leads to higher architectural complexity, tighter timing constraints, and more interactions among Electronic Control Units (ECUs). As a result, the risk of software–hardware integration defects rise, and the overall verification effort required throughout the product lifecycle increases accordingly [5,6,7].

In many projects, these issues are exacerbated by conventional V-model workflows, where system-level integration and validation occur late in the development cycle. As illustrated in Figure 1 [8], traditional approaches depend heavily on physical ECUs and the prototype hardware. This leads to verification bottlenecks around gate reviews and the Start of Production (SOP), with delays caused by limited prototype availability and costly revisions arising from defects that appear only after software and hardware have been fully combined [9,10]. ISO 26262 also notes that discovering integration problems in the later stages significantly increases schedule pressure and rework costs [11,12]. These factors collectively highlight the need for earlier and more hardware-independent verification strategies.

Within this context, virtual Electronic Control Units (vECUs) have gained attention as a means of shifting integration activities to earlier in the development timeline. In vECS environments, AUTOSAR-compliant Application Software (ASW), RTE, and BSW are executed on timing-aware host platforms rather than on physical ECUs [13,14,15]. However, many existing vECU implementations rely solely on virtualized input/output (I/O) models, making it hard to compare behavior directly with real sensor and actuator signals and limiting the insights into the timing-critical and safety-relevant interactions that depend on realistic electrical characteristics.

Meanwhile, Model-Based Design (MBD) is well-established method for verifying control logic at the model stage before implementation. In practice, however, transferring MBD artifacts into production-grade AUTOSAR Classic software remains challenging. Differences between model-generated code and configured BSW often cause MBD-based development and AUTOSAR ASW development to diverge. When these paths are not well aligned, the overall development workload increases and the likelihood of late integration issues grows.

To address these challenges, this paper proposes a unified verification framework that combines MBD, AUTOSAR Classic Platform alignment, vECU execution, and real I/O interaction. The proposed workflow comprises the following: (i) MiL-verified models serve as the basis for AUTOSAR ASW; (ii) DRIM-VirtSAR generates RTE-mapped AUTOSAR Classic code; (iii) the generated code is built into vECU executables targeting a QEMU-based emulated CPU; and (iv) the resulting vECU runs in DRIM-SimHub (ver. 0.8.1), interacting not only with virtual I/O but also with real signals via a hardware interface board.

A key benefit of this approach is that AUTOSAR-compliant software can validated with real sensor and actuator signals even before physical ECUs are available. The mixed virtual–physical testbench reveals timing-sensitive defects and integration anomalies earlier than the conventional workflow. Using a safety-critical seat–slide virtual limit function as the target application, we demonstrated that the vECU exhibits behaviors consistently with the physical ECU, maintains deterministic AUTOSAR task execution, and reduces late-stage verification effort through early integration and scenario reuse.

Building on this observation, the distinction from existing approaches becomes clear. Prior vECU studies frequently rely on simulated I/O models or evaluate only parts of the AUTOSAR stack, which limits their ability to reveal timing-critical behavior under realistic electrical conditions. In contrast, the proposed workflow closes the gap between model-level verification and production-style execution by combining a level 4 vECU with live signal injection and real-time feedback from physical switches, motors, and Hall effect sensors. This configuration enables the earlier detection of timing- and integration-related issues that typically appear only during HiL testing. The aligned reuse of scenarios across MiL, SiL, and vECU stages further reduces redundancy and strengthens traceability. Overall, this shift-left strategy shortens the feedback cycle and increases confidence in safety-critical, body-domain software, even before prototype ECUs are available.

This paper makes the following contributions:

• It implements a QEMU-based AUTOSAR vECU connected to production seat–slide hardware, enabling host-executed ECU software to interact with real switches, a DC motor, and Hall effect sensors without requiring a prototype ECU.
• It reuses the same scenario-based tests consistently across the MiL, SiL, and vECU stages, so that virtual limit scenarios validated in Simulink are replayed on an AUTOSAR-compliant vECU with production-like timing behavior.
• It offers a mixed virtual–physical validation environment in which the vECU can be driven by either virtual I/O models or real electrical signals, allowing for the cross-checking of timing-sensitive behaviors such as PWM duty, Hall pulse characteristics, and limit enforcement under both conditions.

The remainder of this paper is organized as follows. Section 2 reviews related work on software-defined vehicle workflows, Model-Based Design, AUTOSAR Classic integration, and vECU techniques, with particular attention to QEMU-based virtual ECUs and XiL-oriented scenario reuse. Section 3 introduces the production seat–slide virtual limit function, describes its behavioral model and associated functional and safety requirements, and summarizes the limitations of conventional V-model processes for this type of body-domain controller. Section 4 presents the proposed framework, detailing the AUTOSAR Classic architecture adopted and the four-stage workflow that links Simulink-based MiL validation, DRIM-VirtSAR configuration, vECU construction, and mixed virtual–physical verification via DRIM-SimHub and DRIM-I/O. Section 5 describes the implementation and experimental setup, including the mixed virtual–physical testbench, and reports results that compare vECU behavior with the physical ECU in terms of PWM actuation, Hall sensor timing, and limit–stop decisions. Section 6 discusses the implications of these findings for the early verification of safety-relevant, body-domain software and concludes the paper with remarks on future extensions toward multi-ECU configurations and SDV-oriented platforms.

2. Related Work

The shift toward software-defined vehicles has increased software content, data volume, and integration complexity in modern E/E architectures. Surveys on vehicle software engineering report that workflows centered on individual ECUs and tightly bound to hardware are no longer sufficient and that virtualized development and continuous verification are becoming central practices [4,8,16]. At the process level, the V-model remains the main reference in safety standards such as ISO 26262 Part 6 [11]. However, its late integration points and reliance on hardware have led to incremental and simulation-enriched variants that move verification earlier in the lifecycle [17,18,19].

Model-Based Design (MBD) has become a common basis for early-phase verification in embedded systems. Foundational work on Simulink-based MiL describes how models can be used for early functional checks and coverage analysis before target hardware exists [20]. Prior studies on motor-control applications show that automatic code generation from MBD models can shorten development while preserving implementation fidelity on microcontroller platforms [21,22]. In this context, AUTOSAR Software Components (SWCs) represent the modular application-level units that interact with the Runtime Environment (RTE) and Basic Software (BSW) in production ECUs. Several tool-focused papers describe flows for deriving AUTOSAR SWCs and device drivers from MBD artifacts, but they usually stop at code-level integration and unit testing rather than complete production-style execution [23].

In parallel, AUTOSAR Classic has become the standard way to structure production ECU software into SWC, RTE, and BSW layers [24,25]. vECUs extend this structure to host-based execution and help decouple software verification from the availability of physical ECUs. Earlier work discusses vECU workflows based on ARXML parsing and virtual RTEs [26]. More recent work combines QEMU, SystemC, or Renode to execute real target binaries with high timing fidelity and to support automated regression test campaigns [13,27]. In the broader X-in-the-Loop (XiL) literature, MiL, SiL, and HiL are viewed as complementary stages that should reuse scenarios and test assets along the V-model [28,29,30]. HiL-oriented studies further explore interface design and fault injection for the real-time validation of safety-critical ECUs [31].

Additional work on QEMU-based AUTOSAR Classic vECUs has quantified the timing drift on Cortex-M4–class targets, reduced simulation deviations, and compared execution timing against physical ECUs. In our prior experiments with an AUTOSAR application on an STM32F407 ECU and its QEMU vECU, calibrating the AUTOSAR OS tick on the vECU to the measured timing of the physical ECU reduced the average simulation timing error rate from about 2.40% to 0.02% [14]. Follow-up work introduced an I/O simulation method that reproduces pulse-level sensor and actuator behavior, enabling AUTOSAR-oriented operation checks without hardware and showing that QEMU can approximate microcontroller-level timing and electrical behavior closely enough for early-stage verification [32].

Building on this, the present work provides an end-to-end workflow that starts from a Simulink-based MBD model of a safety-related seat–slide limit function, configures AUTOSAR R22-11, generates a vECU, and validates it on real switches and a physical motor in a mixed virtual–physical setup. Rather than stopping at MiL or host-compiled SiL, the workflow preserves production-equivalent SWC, RTE, and BSW semantics and carries realistic Hall sensor characteristics through all stages. In contrast to earlier MBD or vECU studies that focused on model-level validation or purely virtual I/O, the proposed approach combines MBD, AUTOSAR Classic configuration, QEMU-based vECU execution, and interaction with real electrical signals into a single, repeatable process that reuses MiL scenarios at the vECU stage and enables comparison against measured PWM and Hall effect waveforms before any prototype ECU is available.

Unlike vECU approaches that rely exclusively on simulated I/O, the proposed workflow connects a QEMU-based AUTOSAR vECU to real seat hardware so that production-style binaries are validated against measured motor and Hall sensor signals, while the same MiL scenarios can still be executed with either virtual or physical I/O. This provides a unified basis for reusing tests across MiL, SiL, and vECU stages within one mixed virtual–physical environment.

3. System Overview

We focus on the early design and verification of a seat–slide virtual limit ECU by linking MBD, AUTOSAR Classic code generation, and vECU execution with live I/O. This unified workflow mitigates V-model weaknesses such as late-integration issue discovery, timing mismatches, and heavy reliance on hardware-based testing, as summarized in Figure 2.

3.1. Target Seat-Slide Virtual Limit Function

The target function is the seat–slide actuator from a mid-size sedan platform. The actuator is driven by a DC motor and uses one or two Hall effect sensors, depending on the vehicle trim. The seat moves along a rail with a maximum measured travel distance of approximately 240 mm. Each Hall pulse corresponds to about 0.5 mm of motion, as summarized in

Table 1. Characteristics of the Sonata seat–slide Hall effect sensor.

Parameter	Value
Maximum travel	240 mm
Resolution	0.5 mm/pulse
Typical pulse frequency during motion	70–85 Hz
Duty ratio	49–51%

. Pulse trains represent rotor motion and direction, and the ECU uses them to estimate positions and identify when the seat approaches the mechanical end stops.

The virtual limit mechanism defines the software-based limits around the physical end positions, as illustrated in Figure 3. During initialization, the seat is driven to the rear mechanical stop and then to the front stop. The controller defines a virtual rear limit a small number of pulses ahead of the rear stop and a virtual front limit a small number of pulses before the front stop. In this way, the commanded motion is stopped before the mechanism reaches the hard end positions. In the production system used here, the rear reference position is the mechanical rear stop (seat_position $=0$), and the virtual rear limit lies slightly forward of that point. The front reference is the mechanical front stop (seat_position $=240$ mm), and the virtual front limit is placed slightly behind that point.

During normal operation, the ECU interprets user commands from forward and rearward slide switches and updates the internal position counter using the number of Hall pulses seen in each sampling interval. When the position estimate reaches either virtual limit, the ECU stops the motor. The logic also includes protection features. For example, if the Hall pulse count stays below a configured threshold over a one-second window while a motion command is active, the controller treats this as an error consistent with a stalled mechanism or a blocked seat rail and immediately shuts down the motor. To avoid leaving the seat stuck at the error location, the controller permits an override: if the user keeps actuating the same switch for a defined period, the seat is allowed to move further in the commanded direction.

Figure 3 summarizes the virtual limit state behavior of the controller. It includes rear-end referencing, forward-end referencing, steady-state tracking, and several safety-oriented states related to limit handling. The statechart formalizes how the controller interprets Hall sensor pulse trains—their instantaneous frequency, rotation direction, and timing pattern—to infer the motion and interaction with the mechanical boundaries. In particular, the controller exits the moving the seat state when the estimated position reaches the configured virtual limits or when the user releases the slide switch, at which point it transitions to the appropriate limit-handling or idle state.

State changes take place only when clearly defined sensing conditions are met. For example, the controller leaves a normal motion state when the pulse frequency falls below a threshold during rearward motion, when forward pulses appear after a period of inactivity, or when no pulses are observed for a configured time despite an active move request. These conditions reflect the functional requirements of the seat system (for example, establishing mechanical end stops, checking that the user’s command actually results in motion, and stopping before over-travel) and respect the physical behavior of the mechanism, including motor back-EMF, gear train inertia, and the discrete resolution of the Hall effect encoder.

Taken together, the statechart describes how virtual limits are learned, updated, and enforced. It also captures how the controller responds when operation deviates from the nominal case, such as under sensor noise, blocked travel, or missing pulses.

3.2. Functional and Safety Requirements

The mechanical travel range of the seat and its direct contact with occupants lead to several core requirements for the ECU. It must estimate position reliably under noisy sensor pulses, run the control logic with a fixed cycle time in the 5–10 ms range, shut down the motor quickly when a fault is detected, and behave consistently for both forward and rearward movement.

More concretely, the implementation is expected to recover the seat position from the Hall pulses even when noise and timing variations are present, to execute the virtual limit algorithm in a periodic task whose latency is compatible with the motor and seat dynamics, to identify pulse loss or stall conditions within a bounded interval and stop the motor before overshoot occurs, and to apply the same safety and limit behavior in both motion directions.

Assessing all of these aspects at the MiL level alone is difficult. Timing jitter, debounce behavior, and pulse shaping can all influence how the limit logic reacts, and these effects are tied to the actual signal waveforms. For this reason, we connect MBD-level semantics to AUTOSAR-based execution and to real electrical stimuli in the workflow described in the following sections.

3.3. Limitations of Conventional V-Model Processes

When verification depends mainly on hardware, many defects are not observed until late in the project. Typical problems include timing deviations between Simulink model execution and AUTOSAR RTE task scheduling, inconsistencies introduced by manual BSW configuration, and the fact that purely virtual I/O cannot fully reproduce real pulse edges. HiL platforms can mitigate some of these issues, but they are relatively expensive, hard to scale to many variants, and still tend to reveal issues close to the end of the development timeline (Figure 1).

These observations suggest that a development flow is needed in which MBD, AUTOSAR, and vECU stages are linked into a single pipeline focused on early verification.

3.4. Motivation for a Unified Workflow

A workflow that combines MBD, AUTOSAR Classic integration, and vECU execution with real I/O can address these needs. Such a workflow keeps model semantics intact, exposes timing problems earlier, allows for the realistic reproduction of sensor and actuator signals, and reduces dependencies on prototype ECUs and HiL rigs. These goals drive the design of the framework presented in the next section.

4. Proposed Framework

The proposed framework connects DRIM-VirtSAR, which performs AUTOSAR configuration and vECU creation, with DRIM-SimHub, which handles vECU execution and hardware bridging. Together they form a single toolchain. The same chain is used from model-level design and MiL checks through to AUTOSAR configuration and verification against physical signals, without requiring a physical ECU. Figure 4 shows the AUTOSAR architecture on which the framework is based.

4.1. Framework Architecture Overview

The framework follows the AUTOSAR Classic layering—ASW, RTE, BSW, and MCAL—as shown in Figure 4. The application layer (ASW) sits on top of the RTE, which in turn connects to the configured BSW modules and the Microcontroller Abstraction Layer (MCAL). DRIM-VirtSAR imports ARXML files generated by Simulink AUTOSAR Blockset models, configures RTE connections, and builds BSW stacks for a Cortex-M4–class vECU. In contrast to manual configuration, DRIM-VirtSAR aligns services, scheduling, interrupts, and I/O abstractions with the intended behavior of the MBD model.

Figure 5 shows the DRIM-VirtSAR configuration environment, where ASW code, ARXML interfaces, and BSW modules are combined into a vECU project that can be built and executed.

4.2. Unified Four-Stage Workflow

The end-to-end workflow in Figure 2 is organized into four tightly linked stages:

• MBD modeling and MiL validation: MATLAB/Simulink is used to model the virtual limit algorithm. The model incorporates the measured Hall effect sensor characteristics and the state transitions shown in Figure 3. The logic covers the initialization sequence (rear and front referencing), normal motion behavior, error detection based on pulse rate thresholds, and user override conditions. Validation is carried out using scenario-based simulation (Figure 6) with a 10 ms task cycle, which matches the task period of the production body/comfort ECU. A set of 54 scenarios exercises nominal motion, limit–stop behavior, sensor noise, pulse dropout, and rail-blocking events. The expected seat position and error flags are compared with simulation outputs for each scenario. The model reaches approximately 96% decision coverage and 89% condition coverage, indicating that the control logic has been extensively exercised before code generation.
• AUTOSAR Classic integration via DRIM-VirtSAR: The ASW code and ARXML exported from the model are imported into DRIM-VirtSAR. The tool configures RTE ports and BSW modules and produces a vECU source tree. In this step, the virtual limit application is mapped to AUTOSAR OS tasks, RTE ports are associated with I/O abstractions, and BSW services such as ICU, PWM, and NVRAM are instantiated as needed by the seat control function.
• vECU build and execution: DRIM-VirtSAR builds a Cortex-M4-compatible binary that runs on a QEMU-based vECU inside DRIM-SimHub. The vECU executes the same generated AUTOSAR code that would run on the physical ECU, including OS scheduling, RTE dispatch, and BSW drivers, so that the functional semantics of the production stack are preserved.
• Real-signal validation using DRIM-SimHub and DRIM-I/O: The vECU interacts with physical switches and a real seat motor via the DRIM-I/O prototype board, which sends pulse edges and receives motor-driving PWM signals. In this mixed virtual–physical configuration, the vECU observes the Hall pulses produced by the real motor and applies the same limit detection logic as in the deployed ECU, while developers can observe the internal state and external waveforms in parallel.

4.3. Toolchain and vECU Configuration

The vECU is built from AUTOSAR R20-11 configuration artifacts generated by DRIM-VirtSAR. The ARXML files exported from the Simulink AUTOSAR Blockset are imported into DRIM-VirtSAR, which maps Simulink runnables to AUTOSAR OS tasks with a 10 ms period and assigns RTE ports to BSW I/O abstractions that are in turn connected to DRIM-IO channels. In the seat–slide controller, the main virtual limit runnable is scheduled in a single high-priority periodic task, while auxiliary runnables (for diagnostics and communication) are mapped to lower-priority tasks that preserve the scheduling relationship used on the production ECU.

The resulting vECU binary is executed using a QEMU-based Cortex-M4 virtual platform whose clock frequency and timer configuration are aligned with those of the physical ECU. In line with our previous work, the AUTOSAR OS tick configuration on the vECU is calibrated against measured execution times on the STM32F407-based ECU, which reduced the average simulation timing error rate from about 2.40% to 0.02% and keeps task activation latency and PWM edge timing within a small fraction of the 10 ms task period. DRIM-SimHub runs on the DRIM-Pi platform and hosts the QEMU-based vECU, mapping its ICU and PWM BSW modules to external channels provided by the DRIM-IO board: DRIM-IO samples the slide switches and Hall effect sensor signals and sends the resulting digital inputs and ICU events to DRIM-SimHub, while PWM outputs from the AUTOSAR application are delivered via DRIM-SimHub to DRIM-IO, which drives the physical seat motor through a motor driver stage.

4.4. Reproduction of Sensor and Actuator Signal Characteristics

Many vECU approaches rely only on virtual sensors and actuators. In contrast, DRIM-SimHub lets the vECU interact with real Hall effect sensor pulses, actual motor load dynamics, and real electrical noise. Figure 7 shows the I/O monitoring panel, where the pulse frequency, duty ratio, switch inputs, and motor PWM outputs can be observed in real time. These signals are essential when verifying timing-sensitive seat control logic.

By keeping the AUTOSAR implementation, vECU execution, and physical I/O flows aligned, the framework ensures that the virtual ECU behavior closely matches that of the production ECU, enabling earlier defect detection and reducing dependence on prototype hardware.

5. Implementation and Experimental Results

This section presents how the proposed MBD–AUTOSAR–vECU workflow is realized in practice and evaluates its behavioral fidelity using a mixed virtual–physical seat limit testbench. The implementation describes the vECU execution environment, toolchain configuration, and hardware interface, while the experiments assess how closely the vECU reproduces the behavior of the physical ECU under real actuation scenarios. All the simulations, coverage measurements, and code generation were performed using MATLAB and Simulink R2022a.

5.1. Mixed Virtual–Physical Demonstration Environment

Figure 8 shows the mixed virtual–physical test environment used in this study. The setup consists of three main components: (1) a user PC running development and analysis tools, (2) a DRIM-Pi platform that executes the QEMU-based vECU through DRIM-SimHub, and (3) the DRIM-IO board, which connects the vECU to real switches, the seat motor, and the Hall effect sensor.

The user PC (Figure 8, ➀) hosts MATLAB/Simulink, Vector CANoe v 18.0 (Figure 8, ➄), and additional analysis tools that observe the AUTOSAR application behavior during vECU execution. Its specifications are summarized in

Table 2. User PC specification.

Item	Specification
Operating system	Windows 11 Pro 64-bit
vECU execution	WSL2 Ubuntu 22.04.3 LTS
CPU	Ryzen 7 6800H @ 3.20 GHz
RAM	40 GB

. The Simulink visualization model (Figure 8, ➂) displays the real-time seat position, velocity, and virtual limit behavior derived from the vECU commands, while CANoe visualizes the CAN traffic exchanged with the environment. The DRIM-SimHub I/O monitoring panel (Figure 7) can also be accessed remotely from the PC to inspect switch states, PWM outputs, and the decoded Hall effect sensor’s characteristics.

The DRIM-Pi platform (Figure 8, ➁) serves as the host for the QEMU-based vECU and mediates communication among the vECU, the Simulink visualization model, and the I/O hardware. A physical DC motor (Figure 8, ➃) is driven directly by PWM signals generated by the AUTOSAR application synchronized to the vECU’s OS tasks. An oscilloscope (Figure 8, ➅) captures motor and sensor waveforms to verify the timing behavior.

The DRIM-IO board (Figure 8, ➆) shown in Figure 9 provides the hardware interface between the vECU and the seat control components. The yellow-labeled area includes terminals for switch inputs, while the green-labeled section offers connectors for the motor driver and Hall effect sensor. The board supports digital input capture, PWM output, and ICU-based edge timing, which together replicate the signal environment of a production seat–slide mechanism.

The forward and rearward switch commands (D1 and D0) are captured on the board and forwarded to the vECU over TCP/IP. The PPWM motor drive outputs generated by the AUTOSAR application are delivered to the motor driver stage on the DRIM-IO board. The Hall effect sensor’s pulses are processed through the ICU, which extracts edge timing and duty ratio information and sends the resulting events to the vECU via DRIM-SimHub for real-time position estimation. This setup enables the vECU to operate with realistic electrical signals while remaining fully host-executed.

Figure 10 details the electrical connections between the seat–slide hardware and the DRIM-IO board. The slide switches are wired to digital input channels D0 and D1, the motor driver receives PWM outputs PF10 and PA11 from the AUTOSAR application, and the Hall effect sensor is connected to an ICU channel that provides edge timing information to the vECU via DRIM-SimHub.

5.2. Experimental Procedure

To assess how closely the vECU reproduces the behavior of the physical controller, two primary actuation scenarios were evaluated, corresponding to the D0 and D1 switch activations. Pressing D0 triggers rearward motion, while D1 commands forward motion. For each experiment, the following data were recorded:

• vECU-generated PWM outputs (PF10 and PA11);
• Hall effect sensor frequency and duty ratio;
• Motor rotation direction;
• CAN messages via Vector CANoe;
• Oscilloscope waveforms for timing verification.

The vECU task period was set to 10 ms, matching both the MiL model configuration and the production ECU, enabling direct comparison across the MiL, SiL, and vECU stages.

5.3. D0 Input: Rearward Seat Motion

Figure 11 illustrates the PWM outputs generated during D0-driven rearward motion. PF10 carries a higher duty ratio than PA11, producing the expected rearward rotation. The Hall effect sensor response (Figure 12) shows an 80 Hz pulse frequency and a 50.37% duty ratio, consistent with earlier measurements on the physical motor.

During this sequence, the vECU’s internal position estimate and virtual limit state transition consistently track the observed pulse stream. As the estimate approaches the configured virtual rear limit, the controller removes the PWM command and stops the motor, mirroring the behavior of the physical ECU.

5.4. D1 Input: Forward Seat Motion

Figure 13 shows the PWM output patterns generated during D1-derived forward motion. In this case, PA11 carries the higher duty cycle and drives forward rotation. The corresponding Hall effect waveform (Figure 14) again shows an 80 Hz pulse frequency with a 49.70% duty ratio, indicating that the vECU reproduces the sensor timing characteristics observed in the physical system.

Across all the evaluated scenarios, the vECU reproduced the PWM duty cycles, Hall sensor pulse characteristics, and limit–stop decisions of the physical ECU within the measurement resolution. Across all the repeated runs for the D0 and D1 actuation scenarios, the observed task activation jitter and PWM edge timing on the vECU remained within sub-millisecond bounds relative to the physical ECU, and no systematic drift was observed within the measurement resolution of the oscilloscope. The MiL model achieved high structural coverage before code generation, and identical scenarios were replayed at the vECU level with real hardware in the loop. This confirms that test scenarios can be consistently reused along the MiL, SiL, and vECU stages and that timing- and integration-related issues can be observed well before prototype ECUs are available. These results suggest that a substantial portion of functional and timing-related defects can be exposed before prototype ECUs are available, which is particularly beneficial for safety-relevant, body-domain controllers under tight project schedules. The vECU used in this study adopts the same QEMU timing calibration technique as in our previous work, in which the AUTOSAR OS tick configuration on the virtual ECU was tuned against measurements from the physical ECU, resulting in an average simulation timing error rate of 0.02% compared with 2.40% before calibration; this ensures that the MiL/SiL/vECU scenario reuse evaluated here is based on a vECU whose temporal behavior closely matches that of the production ECU.

Table 3. Qualitative comparison between a conventional HiL-centric workflow and the proposed MBD–AUTOSAR–vECU workflow.

Aspect	Conventional HiL-Centric Workflow	Proposed MBD–AUTOSAR–vECU Workflow
Test entry point	MiL results are typically used only as a design–time reference, and most scenario-based verification starts at HiL or prototype ECU stages.	MiL-level scenarios are directly reused on an AUTOSAR-compliant vECU, enabling end-to-end execution with real electrical signals through the DRIM-IO interface.
Dependency on prototypes	Verification of PWM, Hall sensor, and limit behaviors generally requires prototype ECUs and dedicated benches, making the test campaign strongly dependent on hardware availability.	The same behaviors can be reproduced on a QEMU-based vECU connected to real actuators and sensors, reducing the dependency on early hardware prototypes.
Test repeatability	Test repeatability can be affected by bench configuration, wiring, and hardware condition, which complicates exact repetition of scenario executions across different campaigns.	vECU images and scenario sets are version-controlled, so identical test runs can be reproduced on different hosts and by different developers with minimal variation.
Front-loading potential	A large portion of functional verification is concentrated in late HiL campaigns close to SOP, limiting the scope of integrated testing in early development phases.	The integrated MBD–AUTOSAR–vECU pipeline allows analysis of PWM timing, sensor characteristics, and virtual limit enforcement earlier in the lifecycle, before prototype ECUs are available.
Focus of this study	Existing reports often provide limited or no quantitative data on the impact of process changes and focus on specific test stages in isolation.	This case study demonstrates the technical feasibility of the proposed workflow on a seat control ECU, highlighting scenario reuse, AUTOSAR-based execution, and coupling with real I/O rather than claiming quantitative process improvements.

summarizes a qualitative comparison between a conventional HiL-centric validation process and the proposed MBD–AUTOSAR–vECU workflow. In current industrial practice, most scenario-based verifications of automotive ECUs are still performed on HiL benches and prototype hardware, and MiL results are often used only as design–time guidance rather than as executable test assets. In contrast, the proposed workflow executes MiL-derived scenarios on a QEMU-based AUTOSAR vECU while interacting with real motors and sensors through DRIM-IO, which enables earlier analysis of behaviors such as PWM timing, Hall sensor characteristics, and virtual limit enforcement. A formal quantitative comparison with an existing process is outside the scope of this work; instead, the case study focuses on demonstrating the technical feasibility of the integrated MBD–AUTOSAR–vECU pipeline and its potential to front-load ECU validation activities.

5.5. Discussion

The experimental results show how the proposed MBD–AUTOSAR–vECU workflow changes both the timing and the scope of verification activities for the seat–slide virtual limit controller. Because the AUTOSAR application runs on a host-based vECU, functional analysis can start before prototype ECUs or early hardware samples are prepared, and timing behavior can be inspected with full access to internal AUTOSAR states. DRIM-VirtSAR reduces the manual effort normally required to align application code with RTE and BSW configurations, so the interactions between runnables, services, and I/O abstractions can be examined at an early stage. The mixed virtual–physical testbench confirms that the vECU correctly processes real electrical signals delivered through DRIM-IO and DRIM-SimHub, and oscilloscope traces indicate that the generated AUTOSAR software reproduces the PWM timing, Hall sensor characteristics, and limit-handling decisions observed on the physical ECU.

MiL simulations and structural coverage measurements from the Simulink model complement these observations. Most of the critical functional and timing behaviors are exercised before deployment, and identical scenarios can be replayed at the MiL, SiL, and vECU stages. This continuity across the abstraction levels helps identify inconsistencies earlier in development and supports the systematic reuse of test assets along the V-model. For safety-relevant, body-domain functions, the ability to expose timing-sensitive faults and integration anomalies without waiting for prototype ECUs can reduce late-phase verification load and ease schedule pressure in hardware-intensive projects. Recent work on intelligent fault diagnosis for rotating machinery has emphasized robustness under zero-fault or zero-sample conditions and under out-of-distribution data, for example by using relation networks with out-of-distribution data augmentation or physics-informed feature learning to detect and localize faults when no faulty samples are available during training. In contrast, the present study does not introduce a new machine-learning-based fault detector; instead, it focuses on providing a vECU-based mixed virtual–physical environment in which such diagnostic algorithms, whether conventional or zero-sample/OOD-aware, could later be exercised against realistic timing behavior and real sensor waveforms before prototype ECUs are available.

6. Conclusions

This study integrated Model-Based Design, AUTOSAR Classic configuration, and vECU execution into a single workflow that enables the early, host-based verification of an automotive seat–slide virtual limit controller. After validation at the MiL stage, the Simulink model is carried forward to a Cortex-M4–class vECU while preserving production-style RTE and BSW semantics, allowing identical scenarios to be executed across the MiL, SiL, and vECU stages with real electrical signals from switches, the DC motor, and the Hall effect sensor remaining observable and debuggable. The experimental results confirmed that this setup maintains consistency in production-relevant timing behavior and limit–stop decisions while reducing dependencies on prototype hardware. At the same time, the scope of this study is limited to a single body-domain function and a specific toolchain. Future work will extend the workflow to networks of multiple virtual ECUs and to more sophisticated timing models, and will investigate how the same concept can be applied to AUTOSAR Adaptive and container-based SDV platforms. Moving to multi-vECU configurations will require coordinated scheduling, clock synchronization, and communication modeling across several virtual nodes so that bus load and end-to-end latencies remain realistic. Applying the approach to AUTOSAR Adaptive or container-based platforms also raises challenges in terms of representing multi-core execution, POSIX-process level timing, and dynamic service deployment within a vECU environment, which will demand tighter integration between host virtualization, timing analysis, and mixed virtual–physical I/O.