FPGA-Based AI-Driven Hardware-in-the-Loop Platform for Low-Latency Real-Time ABS ECU Testing

Abstract

This paper presents an FPGA-based hardware-in-the-loop (HIL) platform for real-time simulation testing of anti-lock braking system (ABS) electronic control units (ECUs). The proposed system integrates a Temporal Convolutional Network (TCN) model implemented on FPGA hardware to provide real-time predictions of wheel speed sensors under complex braking scenarios. The FPGA acceleration achieves low-latency processing with a total end-to-end latency of 10.61 µs per prediction cycle, corresponding to approximately 94.3 Ksamples/s, which is suitable for closed-loop automotive testing. Experimental results show that the TCN model provides accurate prediction based on mean squared errors below 0.001043 for key parameters such as wheel speed sensors and lateral acceleration. The modular architecture of the simulator allows extensibility to other automotive ECUs and provides a scalable solution for real-time system validation in safety-critical applications.

1. Introduction

The electronic control unit (ECU) plays a vital role in both the performance and safety of modern vehicles, directly contributing to the comfort and safety of drivers and passengers [1]. As vehicles become more dependent on complex networks of interconnected ECUs, maintaining efficient operation in dynamic environments has become essential [2]. The increasing demand for intelligent, safety-oriented features has driven the expansion of ECUs, making them a defining characteristic of modern automotive systems [3]. This growth has influenced vehicle development, performance, and testing protocols to meet evolving industry standards.

During the past decade, rapid advances in automation and automotive technology have drastically transformed the industry [4]. These innovations have led to the development of more productive, sustainable, and autonomous vehicles, redefining the way vehicles are designed and operated [5]. ECUs manage numerous critical vehicle functions including engine control, anti-lock braking systems (ABSs), and electronic stability programs [6].

A simulation platform that can offer a controlled and reliable testing environment is vital for rapid prototyping and testing of ECUs [7]. In this context, HIL simulation has emerged as an essential method for testing and validating functionality, security considerations, and expected system behavior of ECUs by replicating real-world conditions and obstacles encountered by vehicle subsystems such as braking, suspension, and steering [8]. HIL simulation has been used in the design and development of ECUs for power steering systems [9], active roll control [10], suspension system control [11], and vehicle climate-controller simulations [12].

The number of scenarios that must be tested in modern vehicle development is expensive, time-consuming, and unsafe to reproduce only with physical trials [13]. Traditional HIL simulation methods cannot always keep up with the increasing complexity of vehicle systems, particularly due to the growing number of connected ECUs. This complexity often leads to poor coverage of ECU testing scenarios [14].

A key challenge in vehicle control systems, such as ABSs, is accurately measuring component parameters due to their complex nonlinear behaviors [15]. AI-driven models address these limitations since they are more capable of learning complex system dynamics and provide higher estimation accuracy and adaptability. With the growth of artificial intelligence (AI), higher-order testing methods have become increasingly important in automotive applications. The development of autonomous vehicles, in particular, requires advanced computing capabilities, sophisticated algorithms, and deep learning frameworks [16].

Integrating AI-driven technologies into simulation platforms for testing ECUs can enhance the effectiveness and reliability of automotive product development by enabling real-time data analysis, predictive modeling, and adaptive decision-making [17]. AI-driven solutions, such as Temporal Convolutional Networks (TCNs), offer the predictive capability needed for complex ECU validation in dynamic automotive systems. TCNs are effective for sequential data and provide high predictive accuracy for vehicle control applications [18].

Furthermore, the parallel architecture of artificial neural networks maps efficiently onto FPGA hardware, improving the execution speed of AI-based approaches [19]. FPGA devices have also been increasingly adopted in HIL simulators to meet real-time requirements, improve computational performance, and reduce the latency of the simulation loop [20]. In closed-loop HIL simulations, where bidirectional interactions between physical and virtual components are essential, precise time synchronization is crucial to maintaining system accuracy [21]. These closed-loop simulations are also vital for testing real-time interactions between ECUs to ensure that the system responds appropriately to feedback and maintains stability under various operating conditions [22].

To address the limitations of existing methods, this paper introduces a novel HIL framework that integrates a TCN as a virtual wheel speed sensor on an FPGA platform for real-time, closed-loop testing of ABS ECUs. The core innovation lies in this co-designed integration and the virtual sensor paradigm: whereas prior studies have employed AI models [23] or used FPGAs for acceleration [24] in isolation, the proposed framework combines both to create an FPGA-based virtual representation of a physical wheel speed sensor for HIL testing. This system exploits the TCN’s ability to capture long-range temporal dependencies to dynamically synthesize physically accurate wheel speed signals within the deterministic, low-latency environment of an FPGA.

The primary goal is to emulate selected ABS ECU input and output signals using virtual sensors and actuators, simulating actual system inputs and outputs such as wheel speed sensors, brake pressure sensors, steering angle sensors, and solenoid valves. This setup provides a controlled and adaptable testing environment that evaluates ECU performance under varying operating conditions.

This paper is organized as follows. Section 2 describes the system model. Section 3 outlines the methodology. Section 4 details the experimental setup. Section 5 presents the results and discussion. Finally, Section 6 concludes the paper.

2. System Model

An ABS is an essential system in modern automobiles that prevents wheel lock-up while enhancing vehicle stability and steering control during sudden braking. A typical four-wheel ABS configuration, shown in Figure 1, includes wheel speed sensors, an ECU, a brake pressure modulator, and solenoid valves [25].

The ABS operates as a closed-loop control system. The wheel speed ${\omega }_w$ is continuously monitored by sensors and transmitted to the ECU. The ECU calculates the wheel slip ratio $\lambda$, a key parameter for preventing wheel lock-up:

$$\lambda ={\displaystyle \frac{v-r_w{\omega }_w}{v}},$$

(1)

where v is the vehicle speed and $r_w$ is the wheel radius. When $\lambda$ exceeds a threshold ${\lambda }_{\max }$, the ECU sends a control signal to the valve modulation unit, which adjusts the hydraulic pressure applied to the brake caliper. The brake torque applied to the wheel is given by

$$J_w{\displaystyle \frac{d{\omega }_w}{dt}}=T_b-r_w{F}_x,$$

(2)

where $J_w$ is the wheel inertia and $F_x$ is the longitudinal tire force. The brake torque $T_b$ is dynamically modulated, often using a PID-like controller:

$$T_b\left(t\right)=K_{p}e\left(t\right)+K_i{\int }_0^{t}e\left(\tau \right)d\tau +K_d{\displaystyle \frac{de\left(t\right)}{dt}},e\left(t\right)={\lambda }_{\mathrm{target}}-\lambda \left(t\right).$$

(3)

This closed-loop operation continues as the wheel rotates, with the sensor continuously updating the ECU and the valve modulation unit adjusting hydraulic pressure accordingly. This feedback loop ensures optimal braking performance while maintaining vehicle stability and steering control [26].

3. Methodology

The proposed closed-loop HIL simulation framework emulates the real-time dynamics of a semi-truck and replicates vehicle behavior under various driving conditions, including acceleration, braking, road-surface variation, and steering interaction. This framework provides testing inputs to the ECU that closely mirror real-world scenarios by using the Trucksim simulator, which generates diverse driving conditions and verifies the ECU response under these conditions. The FPGA-based prediction module functions as a virtual counterpart to the physical ABS by implementing a TCN-based virtual wheel speed sensor.

As illustrated in Figure 2, the FPGA-based prediction module plays a critical role in the closed-loop HIL simulation platform. It operates as a real-time predictor of ABS behavior, where the TCN-based virtual sensor dynamically synthesizes wheel speed data based on an AI model trained to replicate diverse ABS behavior. This virtual sensor emulates physical wheel speed sensor signals within the HIL environment by generating accurate, real-time signals directly from the ECU control inputs, enabling a fully software-defined and adaptable testing environment.

Sensor signals are emulated through signal generators and transmitted to the ECU, while feedback from the ECU is collected via signal-acquisition modules. The ABS input signals of the FPGA design are multiplexed with feedback signals from the ECU using a multiplexer (MUX). The MUX selects between FPGA-generated ABS signals selected from the Trucksim dataset and ABS feedback signals received from the ECU, enabling real-time comparison and validation.

The prediction module is developed through a three-stage design process, as shown in Figure 3: simulation model development, TCN model training, and real-time deployment on an FPGA.

• Simulation model development: ABS datasets are generated using the Trucksim simulator to emulate realistic driving conditions.
• TCN model training: A TCN model is trained on a GPU using the generated datasets. The process includes training, validation, and testing to obtain optimal model weights.
• Real-time deployment: The trained TCN model is deployed on the FPGA to enable real-time prediction of sensor data with high-speed and low-latency operation.

3.1. Simulation Model

The first step focuses on developing the simulation model used for ABS ECU testing and data generation. To validate the performance of the ABS ECU and generate training data for the TCN model, TruckSim 2022 was integrated with MATLAB/Simulink R2022b.This co-simulation platform enables realistic reproduction of vehicle dynamics under different braking, steering, and speed conditions.

TruckSim provides the vehicle dynamics environment, while MATLAB/Simulink generates the input profiles and manages the data-logging process. As shown in Figure 4, the integrated Simulink–TruckSim model receives input signals from MATLAB functions to create diverse driving scenarios. These functions generate key variables such as steering angle, brake command, and initial vehicle speed, using randomized braking intensity and initial-speed values to improve dataset diversity. The generated signals are then applied to the TruckSim “VS_SF” block to simulate vehicle behavior and export ABS-related time-series data for TCN training, validation, and FPGA-based HIL testing. The inputs to the TruckSim “VS_SF” block include:

• IMP_SPEED → initial speed (km/h);
• IMP_PCON_BK → brake intensity and brake rate (m/s²);
• IMP_STEER_SW → initial steering angle and steering rate.

The variability introduced in each test scenario generates a comprehensive dataset for ABS validation and TCN model development. The simulation framework improves dataset diversity by varying critical factors such as initial speed, braking intensity, and steering conditions. This dataset enables the AI-based prediction model to learn representative vehicle dynamics and supports real-time FPGA-based HIL simulation.

The key parameters summarized in

Table 1. ABS testing scenario parameters used as inputs of the Trucksim simulator.

Input Parameter	Formula	Description	Value Range
Initial speed	speed_t0 = rand()	Simulates different entry speeds.	Uniform: [20, 120] km/h
Brake delay	brake_delay = rand()	Delay before brake application.	Uniform: [0, 1] s
Brake rate	brake_rate = 2 · rand()	Represents braking deceleration.	Uniform: [0, 2] m/s2
Brake intensity	8%: brake_t1 = 0; otherwise $0.14+0.3·\mathrm{randn}\left(\right)$	Models partial or failed braking events.	Clipped to [0, 1]
Max steering angle	max_init_steering = ${\displaystyle \frac{1.5(-1.7·\mathrm{speed}\text{\_}\mathrm{t}0·120+260)}{\max \text{\_}\mathrm{steering}}}$	Limits steering for safe turning.	max_steering = 720°
Initial steering	10%: steering_t0 = 0; otherwise $\mathrm{rand}\left(\right)$	Models straight or turning motion.	Uniform: [0, 1]°
Steering delay	steer_delay = rand()	Delay before steering response.	Uniform: [0, 1] s
Steering rate	steer_rate = 1.5 · rand()	Rate of steering change.	Uniform: [0, 1.5]°/s

are designed to simulate diverse driving scenarios based on randomized input generation. The initial vehicle speed is randomly selected in the range of 20 to 120 km/h to reflect different urban and highway driving conditions. Brake-related inputs include the brake delay, brake rate, and brake intensity. Steering angle parameters are constrained to ensure vehicle stability and rollover prevention, particularly under road-friction conditions such as dry asphalt.

Although the dataset is generated synthetically, scenario realism is supported by the use of the TruckSim physics-based vehicle model coupled with MATLAB/Simulink input generation. The randomized input parameters were selected within physically meaningful ranges for initial speed, brake delay, brake rate, brake intensity, steering angle, steering delay, and steering rate. These variations generate diverse braking and steering conditions, including normal braking, partial braking, delayed braking, braking during steering, wheel speed transients, and ABS modulation behavior. In addition, generated simulations were filtered using vehicle-stability constraints, including roll-angle limits, to remove physically unrealistic or unstable cases. Therefore, the dataset is intended to provide broad coverage of representative synthetic ABS operating conditions rather than exhaustive coverage of all possible real-world events.

3.2. TCN Learning Model

Recurrent Neural Networks (RNNs) are widely applied to sequential data tasks such as time-series analysis. However, conventional RNN-based models, including Long Short-Term Memory (LSTM), Gated Recurrent Unit (GRU), and Nonlinear AutoRegressive with eXogenous input (NARX) networks, can suffer from inefficiencies when processing long sequences, gradient-vanishing problems, and limited parallel processing. TCNs [27] address these issues by employing causal and dilated convolutions, which enable efficient parallel processing while capturing long-range temporal dependencies.

The predictive capability of TCNs was empirically validated through a comparative study with LSTM, GRU, and NARX models. As shown in

Table 2. Performance comparison of sequential models.

Model	MSE	MAE
TCN	$3.77\times {10}^{-4}$	0.0099
LSTM	$5.99\times {10}^{-4}$	0.0114
GRU	$7.36\times {10}^{-4}$	0.0130
NARX	$6.04\times {10}^{-4}$	0.0127

, the TCN achieved the lowest MSE and MAE on the ABS ECU dataset, showing the best prediction accuracy among the evaluated sequence models. These results motivated the selection of TCNs for FPGA deployment, where low latency and high throughput are essential for real-time ECU validation.

Trucksim-generated data are used to train the TCN model in Python 3.10 to replicate ABS ECU behavior.

By capturing temporal patterns in vehicle sensor data, the TCN predicts ABS sensor values for different driving conditions used in closed-loop HIL simulations. The dataset is generated by co-simulating Trucksim with Simulink, and Trucksim exports time-series ABS ECU-related signals in CSV format. Using 14 input signals representing driver commands and ECU feedback, the TCN model is trained to predict 17 output signals. The TruckSim parameters used as inputs and outputs for the ABS TCN model are summarized in

Table 3. TruckSim parameters for the ABS TCN model.

Variable Name	Description	Unit	Role
Pbk_Con	Brake pressure command	unitless ([−1, 0])	Input
Steer_SW	Steering wheel angle	degree	Input
ABS_L1 to ABS_L5	ABS control state for five left wheels	Boolean	Input
ABS_R1 to ABS_R5	ABS control state for five right wheels	Boolean	Input
GearStat	Gear status	Integer	Input
Throttle	Throttle pedal position	unitless ([0, 1])	Input
Vx	Longitudinal speed	km/h	Output
AVz	Yaw rate	degree/s	Output
AVz_2	Yaw rate (trailer)	degree/s	Output
Ay	Lateral acceleration	m/s2	Output
Ay_2	Lateral acceleration (trailer)	m/s2	Output
Fs	Mean wheel load	N	Output
Roll	Roll angle	degree	Output
Vx_L1 to Vx_L5	Five left wheel speeds	km/h	Output
Vx_R1 to Vx_R5	Five right wheel speeds	km/h	Output

.

The TCN is designed for sequential data processing and includes the following features: causal convolution, same-length input and output mapping, receptive field expansion through dilation, and parallel processing. Causal convolution ensures that outputs depend only on past and present inputs, avoiding future information leakage [28]. Same-length input and output mapping supports direct sequential-data prediction [29]. Dilated convolutions expand the receptive field efficiently, capturing long-range dependencies for ABS and steering-control applications [30].

The TCN architecture shown in Figure 5 consists of an input layer, encoder, three stacked temporal convolution cells, decoder, and output layer. Although the physical input set contains 14 external signals, the implemented model also uses the previous values of the 17 predicted outputs as autoregressive feedback. Therefore, the TCN receives 31 input channels in total and predicts 17 output channels at each time step. In the implemented model used in this study, the TCN uses three temporal convolution cells, 128 hidden channels, a kernel size of 4, and a base dilation factor of 3.

Although tire–road friction, tire condition, and load transfer strongly influence wheel speed dynamics during braking, these variables were not explicitly included as independent TCN input channels in the current implementation. The objective of this work was to build a virtual sensor using signals available through the implemented ABS ECU HIL interface, rather than relying on internal simulator-only variables. In practical ECU testing, road-friction coefficients and tire-condition parameters are often not directly measured by the ECU and may not be available as real-time input signals. Their effects are instead reflected indirectly through the vehicle response, including wheel speed transients, vehicle speed, yaw rate, lateral acceleration, roll angle, and load-related dynamics.

In the implemented autoregressive TCN, these effects are implicitly captured through the previous 17 predicted output signals that are fed back to the model. Future extensions will evaluate the inclusion of explicit road-friction profiles, tire-condition parameters, and road-surface labels as additional inputs or scenario descriptors to improve generalization under low-friction, split-friction, and abrupt friction-transition braking events.

For this configuration, the effective receptive field is 40 samples. Since the TruckSim data are sampled at 60 Hz, this corresponds to approximately 0.67 s of temporal context. This receptive field was selected to capture short-term ABS dynamics, including wheel speed transients, brake pressure variations, and ABS modulation behavior, while keeping the model compact enough for deterministic low-latency FPGA implementation.

The model was trained for 140 epochs using the Adam optimizer with a learning rate of $5\times {10}^{-4}$ and a batch size of 16. Before training, all input and output variables were normalized using MinMax scaling. The primary loss function was the mean squared error (MSE). To improve closed-loop stability and reduce high-frequency oscillations in the predicted signals, an additional first-difference loss was added to the TCN objective and weighted by $\alpha =30$. Gradient clipping with a maximum norm of 0.15 was applied during training. Small Gaussian noise with a standard deviation of $1/2^{16}$ was added to the non-Boolean input channels to improve robustness.

No dropout layer was used in the implemented TCN. Instead, closed-loop prediction stability was improved through first-difference regularization, input-noise injection, and gradient clipping.

The receptive field R of a TCN determines how many input time steps influence a single output value and is calculated as

$$R=1+{\displaystyle \sum _{l=1}^L}\left(k^{\left(l\right)}-1\right)d^{\left(l\right)},$$

(4)

where L is the number of TCN layers, $k^{\left(l\right)}$ is the kernel size at layer l, and $d^{\left(l\right)}$ is the dilation factor at layer l. In the implemented model, the TCN has three temporal convolution layers, a constant kernel size of $k=4$, and a base dilation factor of 3. Therefore, the dilation factors are $d^{\left(1\right)}=1$, $d^{\left(2\right)}=3$, and $d^{\left(3\right)}=9$. The effective receptive field is therefore

$$R=1+(4-1)(1+3+9)=1+3\times 13=40.$$

(5)

Thus, each prediction uses 40 previous samples. Since the TruckSim data are sampled at 60 Hz, this corresponds to approximately

$${\displaystyle \frac{40}{60}}\approx 0.67\mathrm{s}.$$

(6)

This temporal context was selected to capture short-term ABS dynamics, including wheel speed transients, brake pressure variations, and ABS modulation behavior, while keeping the TCN compact enough for deterministic low-latency FPGA implementation.

The primary metrics used to evaluate the TCN model are the mean squared error (MSE) and the mean absolute error (MAE). The MSE is defined as

$$\mathrm{MSE}={\displaystyle \frac{1}{n}}{\displaystyle \sum _{i=1}^n}{(y_i-{\widehat{y}}_i)}^2,$$

(7)

where $y_i$ is the ground-truth value, ${\widehat{y}}_i$ is the predicted value, and n is the total number of samples. The MAE is defined as

$$\mathrm{MAE}={\displaystyle \frac{1}{n}}{\displaystyle \sum _{i=1}^n}|y_i-{\widehat{y}}_i|.$$

(8)

MSE penalizes larger prediction errors more strongly, while MAE provides a direct measure of the average absolute prediction deviation.

TCN Hyperparameter Ablation Study

The ablation results include both 64-channel and 128-channel candidate architectures. The 64-channel models were used to evaluate the effect of temporal depth and dilation factor with lower model capacity, while the 128-channel models were used to examine the effect of increased model capacity. Although TCN-D uses a deeper four-cell architecture and a larger kernel size, it did not outperform the selected TCN architecture. The selected TCN, with 128 hidden channels, three temporal convolution cells, kernel size 4, and base dilation factor 3, achieved the best overall prediction accuracy, with an MSE of $3.77\times {10}^{-4}$ and an MAE of 0.0099. Therefore, this configuration was selected for FPGA implementation because it provides the best trade-off between prediction accuracy, temporal context, and deterministic hardware deployment.

Only the selected TCN model was implemented and synthesized on the FPGA. Therefore, the ablation study reports GPU-based prediction accuracy for the candidate architectures, while FPGA latency, resource utilization, and power consumption are reported for the selected architecture. Increasing the number of temporal cells, kernel size, or channel width increases the number of convolution operations, stored activations, and coefficient-memory requirements. Therefore, deeper or wider TCN variants are expected to require higher LUT, DSP, and BRAM usage.The preliminary GPU-based ablation results for the TCN hyperparameters are summarized in

Table 4. Preliminary GPU-based ablation study of TCN hyperparameters.

Config.	Epochs	Channels	Cells	Kernel	Dilation	MSE/MAE
TCN-A	300	64	2	4	2	0.000531116/0.013054130
TCN-B	220	64	3	4	2	0.000490104/0.012964860
TCN-C	220	64	3	4	3	0.000429798/0.010757723
TCN-D	140	128	4	5	2	0.000410845/0.011198771
Selected TCN	140	128	3	4	3	$3.77\times {10}^{-4}$/0.009900

.

3.3. FPGA Implementation

The next stage of the prediction module is the FPGA implementation of the trained TCN model. The FPGA implementation enables real-time sensor-data processing for closed-loop HIL simulation by executing the TCN inference directly on the programmable logic. The trained weights and biases generated by the Python-based model are mapped to FPGA memory resources and used to predict ABS-related sensor values, including wheel speed signals.

Although the physical input set contains 14 external signals, the implemented autoregressive TCN also feeds back the previous values of the 17 predicted outputs. Therefore, the FPGA implementation processes 31 input channels in total and generates 17 output channels at each time step.

Figure 6 shows the FPGA architecture of the TCN prediction module. The design is organized into modular hardware blocks, including input buffering, BRAM-based coefficient memories, convolution blocks, ReLU activation, residual-addition blocks, optimized fixed-point MAC units, and output-interface logic. The TCN finite-state machine (FSM) and inner control blocks schedule the execution of the model layers and coordinate data movement between memory and computation units.

A key step in the hardware implementation is mapping the trained TCN weights and biases to FPGA memory resources. The pre-trained parameters are converted into Q1.15 fixed-point format and stored in coefficient files used to initialize ROM blocks during bitstream generation. During inference, the FSM controller generates the required ROM addresses and supplies the stored coefficients directly to the corresponding MAC units, avoiding external memory access for model parameters.

The MAC unit is one of the most resource-demanding components in neural network accelerators. Therefore, optimizing the MAC design is essential to reduce FPGA resource utilization while maintaining deterministic real-time performance. The proposed implementation uses an optimized fixed-point MAC unit (OFM) [31]. The OFM consists of a multiplication unit and an accumulator operating on Q1.15 fixed-point operands, where one bit is assigned to the integer/sign part and fifteen bits are assigned to the fractional part. This format provides efficient FPGA resource usage while maintaining sufficient numerical precision for ABS sensor prediction.

Hardware Timing, Quantization, and Scalability Analysis

The FPGA implementation was designed to provide deterministic real-time inference rather than only high average throughput. The TCN datapath is controlled by a synchronous finite-state machine that schedules the encoder, temporal convolution cells, ReLU stages, residual addition, and decoder in a fixed sequence. The control and handshake signals are registered to reduce long combinational paths and simplify timing closure at the 100 MHz operating frequency. The convolution stage is implemented using a parallel multiplier-bank/MAC structure, while the ReLU and residual-addition operations are organized as separate pipeline stages. This organization provides deterministic cycle-by-cycle behavior and avoids uncontrolled memory-access conflicts during inference.

The trained TCN parameters are stored locally in FPGA BRAMs as coefficient memories initialized during bitstream generation. Therefore, inference does not require external memory access for weights or biases. The BRAM-based weight storage supplies the MAC units directly, while the AXI-Stream FIFO interface between the programmable logic and the processing system decouples the TCN pipeline from USB3 communication with the HIL simulator. As a result, communication latency is isolated from the internal TCN computation, supporting the measured PL inference latency of 5.45 μs and the total end-to-end latency of 10.61 μs.

The Q1.15 fixed-point format was selected to balance numerical precision and FPGA resource efficiency, following the optimized fixed-point MAC design presented in [31]. Since the input and output variables are MinMax-normalized, most values lie within the representable range of Q1.15. The quantization step is $2^{-15}\approx 3.05\times {10}^{-5}$, which provides sufficient fractional resolution for the normalized ABS-related signals. In the fixed-point MAC, each multiplication produces an intermediate wider product that is scaled back to Q1.15 format using normalization and rounding. These operations reduce truncation error and help limit numerical drift during closed-loop prediction.

The effect of fixed-point quantization was evaluated by comparing the Python floating-point model, the FPGA floating-point implementation, and the FPGA Q1.15 fixed-point implementation. The detailed fixed-point accuracy results and FPGA resource-utilization comparison are reported in the Results and Discussion section. The Q1.15 implementation was selected to support deterministic low-latency execution and resource-efficient real-time ECU testing.

A complete sensitivity analysis over multiple fixed-point formats, such as Q2.14, Q3.13, or Q4.12, was not performed in the present study because each format requires a separate quantization, FPGA implementation, timing closure, and synthesis flow. Future work will include a systematic fixed-point word-length study to evaluate the trade-off between prediction accuracy, numerical stability, overflow margin, LUT/DSP/BRAM usage, and timing performance.

From a scalability perspective, the fixed-point implementation leaves substantial resource headroom on the ZCU102 platform. The fixed-point MAC version reduces LUT and DSP usage compared with the FP16 implementation, enabling the integration of additional virtual sensors, more wheel speed channels, or larger TCN models. Increasing the TCN channel width, depth, or kernel size affects multiple FPGA resource categories. Additional weights and past activations increase BRAM requirements, while additional convolution operations increase DSP and LUT usage. The architecture can therefore be scaled in two ways: by increasing parallel MAC resources to preserve inference latency, or by reusing the existing MAC units across more cycles when a larger latency budget is acceptable.

3.4. Closed-Loop HIL Simulation

Closed-loop HIL simulation provides real-time interaction between the ECU and the virtual environment. Data are transferred through the signal-generation module to the ECU, and feedback signals from the ECU are transferred from the acquisition module to the prediction module. Signal generation and acquisition components emulate system inputs and outputs, including wheel speed sensors, brake pressure sensors, steering angle sensors, and solenoid valves. The FPGA-based closed-loop ABS ECU testing workflow is shown in Figure 7.

The PS/PL AXI FIFO interface enables low-latency communication between the processor system (PS) and programmable logic (PL) in the FPGA. The PS includes an ARM processor that manages the USB3 connection to the simulator. The USB3 interface provides high-bandwidth communication for real-time exchange of sensor and actuator data between the simulator and the FPGA prediction module.

The FPGA-based prediction module acts as a virtual replica of the physical ABS. The model operates in two phases: an initialization open-loop phase and a prediction closed-loop phase. In the open-loop phase, short sequences of ground-truth values from Trucksim are provided to the FPGA-based TCN model to initialize the simulation context. In the closed-loop phase, the TCN predicts wheel speed sensor values based only on ABS control signals. The predicted sensor values are fed back into the model as inputs, creating a feedback loop that allows continuous prediction without further dependency on ground-truth data.

Because the closed-loop phase feeds the predicted outputs back into the TCN input sequence, recursive prediction errors may accumulate over time. To reduce this risk, the implemented TCN was trained with first-difference regularization, small Gaussian input-noise injection, and gradient clipping, and the closed-loop prediction phase is initialized using a short ground-truth context sequence. These mechanisms help reduce high-frequency oscillations and support short-term closed-loop stability during the evaluated ABS scenarios. However, a dedicated long-duration prediction-drift analysis under extended braking maneuvers, abrupt steering transitions, and long continuous closed-loop operation was not performed in the present study. Future work will therefore include long-duration closed-loop experiments and explicit drift metrics over extended prediction horizons to further evaluate recursive prediction stability.

4. Experimental Setup

Figure 8 shows the proposed HIL framework for testing and verification of the ABS ECU, using the Bendix EC-60 ABS ECU as the device under test. The framework includes four key hardware modules: the FPGA prediction module, the signal-generation module, the signal-acquisition module, and the communication module for J1939/CAN bus communication with the ECU.

The USB ports of all modules are connected to the host computer through the simulator backplane. When the prediction-data reading function is activated, data from the FPGA prediction module are transferred to the Bendix EC-60 ABS ECU through the signal-generation module. The ECU processes the wheel speed sensor data received from the signal-generation module and generates ABS output signals, which are transferred back to the host computer through the signal-acquisition module. The main input and output interfaces of the Bendix EC-60 ABS ECU used in the HIL setup are summarized in

Table 5. Inputs and outputs of the Bendix EC-60 ABS ECU.

Category	Signal	Description
Inputs	Wheel speed sensors	Measure wheel-end speed on each side of the front and rear axles.
	Brake pressure sensor	Provides brake pressure feedback to the ECU for modulation accuracy.
Outputs	Pressure-modulating valves	Independently regulate brake pressure at each axle end to prevent wheel lock-up.
	Traction control valves	Apply selective braking to regain traction during wheel spin on drive axles.

.

5. Results and Discussion

5.1. Prediction Accuracy and FPGA Resource Evaluation

The foundation of the proposed HIL framework is the TCN-based virtual wheel speed sensor. The dataset collected by the Trucksim simulator consisted of 2000 truck driving simulations with durations from 2 to 10 s, amounting to approximately 4 h of non-consecutive driving data. The dataset was sampled at 60 Hz and partitioned into 70% training, 20% validation, and 10% testing subsets.

The trained TCN model achieved an MSE of $3.77\times {10}^{-4}$ and an MAE of 0.0099 on the validation set. These metrics indicate that the model provides accurate prediction on the evaluated validation set and can capture wheel speed sensor behavior under the tested scenarios. Low error rates demonstrate that the TCN model captures both short-term variations and long-range temporal dependencies in sequential driving data.

For deployment in the real-time HIL environment, the trained TCN model was implemented on a Xilinx ZCU102 FPGA. This step transitions the model from a GPU-based predictor to a hardware-virtualized sensor, which is a core contribution of this work. The FPGA implementation preserves high accuracy while achieving microsecond-scale latency suitable for real-time closed-loop HIL operation. Representative prediction results from the TruckSim, Python-based TCN, and FPGA-based TCN implementations are shown in Figure 9.

Table 6. MSE comparison for truck speed, lateral acceleration, and wheel speed.

Parameter	Python Model MSE	FPGA Float MSE	FPGA Fixed MSE
Truck Speed (AVx)	0.000007	0.000009	0.000186
Lateral Acceleration (Ay)	0.000111	0.000136	0.000787
Wheel Speed (Vx_L3)	0.000163	0.000203	0.000835
Wheel Speed (Vx_L5)	0.000066	0.000163	0.001043

reports the MSE results averaged over 200 diverse ABS test scenarios across Python-based, FPGA floating-point, and FPGA fixed-point implementations. The Python-based model achieves the highest precision, while the FPGA floating-point implementation closely follows with minimal degradation. The fixed-point implementation produces slightly higher errors due to quantization effects but maintains acceptable accuracy while improving resource efficiency.

Figure 10 illustrates the PMV control signals for one wheel. The left plot shows the ABS command signals generated by the EC-60 ECU, while the right plot displays the predicted wheel speed sensor values generated by the FPGA-based TCN model on the HIL platform. These results show that the FPGA-based HIL setup can inject predicted wheel speed signals into the EC-60 ECU and record the corresponding ECU output response under the evaluated wheel-dynamics scenario.

Compared to GPU execution, the FPGA implementation achieves a substantial reduction in inference latency. The TCN predictions complete in approximately 5.45 $\mathrm{\mu }\mathrm{s}$ on the PL logic at 100 MHz, with an additional 2.56 $\mathrm{\mu }\mathrm{s}$ required for PL-to-PS transfer and roughly 2.6 $\mathrm{\mu }\mathrm{s}$ for PS-to-simulator transfer through the USB3 interface. The total end-to-end latency is therefore approximately 10.61 $\mathrm{\mu }\mathrm{s}$, corresponding to a throughput of approximately 94.3 Ksamples/s. Compared with GPU execution on a GTX 1060 at 5200 $\mathrm{\mu }\mathrm{s}$ per inference, the FPGA implementation achieves an improvement factor of approximately 490×. This comparison corresponds to the single-sample real-time inference configuration used in this study and should not be interpreted as a general FPGA versus GPU performance claim under all batching, precision, or software-optimization conditions.

The GPU reference latency was measured using the Python-based TCN inference workflow with batch size 1 and FP32 precision, corresponding to the single-sample closed-loop HIL use case. No GPU-specific deployment optimizations, such as TensorRT acceleration, graph compilation, kernel fusion, batched inference, or mixed-precision inference, were applied. The proposed FPGA latency corresponds to the deployed Q1.15 fixed-point implementation on the ZCU102 platform, while the FP16 FPGA implementation was used only as a floating-point hardware comparison for accuracy and resource utilization. Therefore, the reported 490× improvement should be interpreted as the latency reduction achieved by the proposed Q1.15 FPGA implementation for the non-batched real-time inference workflow used in this study, rather than as a general comparison between FPGA and GPU inference platforms with deployment-specific optimizations.

Table 7. FPGA resource-utilization comparison for the selected Q1.15 fixed-point TCN implementation, the 128-channel FP16 comparison design, and the 64-channel FP16 scalability design.

Resource	128-Channel Fixed-Point MAC		128-Channel FP16 MAC		64-Channel FP16 MAC
	Utilization	Util. (%)	Utilization	Util. (%)	Utilization	Util. (%)
LUT	21,368	7.80	57,090	20.83	28,947	10.56
LUTRAM	302	0.21	302	0.21	302	0.21
FF	59,346	10.83	93,187	17.00	61,059	11.13
BRAM	88.50	9.70	105	11.51	52.5	5.75
DSP	64	2.54	128	5.08	64	2.54
IO	1	0.30	1	0.30	1	0.30
BUFG	1	0.25	1	0.25	1	0.25

compares FPGA resource utilization for three TCN implementation cases: the selected 128-channel Q1.15 fixed-point MAC design, the 128-channel FP16 MAC comparison design, and the 64-channel FP16 MAC scalability design. The Q1.15 fixed-point implementation is the final hardware configuration used in the proposed HIL platform, because it provides sufficient prediction accuracy with substantially lower FPGA resource usage and deterministic low-latency execution. It uses 21,368 LUTs, 59,346 FFs, 88.5 BRAMs, and 64 DSPs, corresponding to 7.80% LUT, 10.83% FF, 9.70% BRAM, and 2.54% DSP utilization.

The 128-channel FP16 implementation is included only as a floating-point comparison baseline to evaluate the precision/resource trade-off. It uses 57,090 LUTs, 93,187 FFs, 105 BRAMs, and 128 DSPs, corresponding to 20.83% LUT, 17.00% FF, 11.51% BRAM, and 5.08% DSP utilization. This comparison shows that FP16 arithmetic can provide higher numerical fidelity and better tolerance to quantization effects, but at the cost of substantially higher LUT, FF, and DSP usage. Therefore, the Q1.15 fixed-point implementation was selected for the proposed real-time HIL platform because it provides the best balance between prediction accuracy, latency, and FPGA resource efficiency.

To provide a quantitative indication of channel-width scalability, the 64-channel FP16 implementation was also synthesized on the ZCU102 platform. This configuration is included only to show how resource usage changes when the FP16 channel width is reduced from 128 to 64. It uses 28,947 LUTs, 61,059 FFs, 52.5 BRAMs, and 64 DSPs, corresponding to 10.56% LUT, 11.13% FF, 5.75% BRAM, and 2.54% DSP utilization. Compared with the 128-channel FP16 implementation, the 64-channel FP16 configuration reduces LUT usage from 20.83% to 10.56%, BRAM usage from 11.51% to 5.75%, and DSP usage from 5.08% to 2.54%. These results provide a quantitative indication of channel-width scalability while confirming that the selected Q1.15 fixed-point implementation remains the most resource-efficient configuration for the proposed FPGA-based HIL platform.

Figure 11 presents the estimated power usage on the ZCU102 evaluation board. Dynamic power accounts for 78% of total power consumption, with the PS contributing 94% of the dynamic power. Static power represents 22%, with 87% consumed by the PL.

5.2. Comparison with Existing HIL Simulators

Table 8. Quantitative comparison of existing HIL and real-time simulation platforms with the proposed FPGA-based AI-driven HIL platform. Metrics are reported when available in the corresponding prior studies.

Study	Platform/Simulator	Reported Quantitative Metrics	Gap Compared with This Work
[32]	Custom ABS HIL simulator	Measured variables: wheel speed, simulated vehicle speed, brake-fluid pressure, longitudinal slip, and braking distance.	ABS-specific HIL test bench, but no FPGA acceleration, AI virtual sensor, TCN prediction, latency, throughput, or FPGA resource analysis is reported.
[33]	MATLAB/Simulink + BSI-HiL full-brake simulator	Actuator capability: 1600 N maximum force, 200 mm stroke, and 1.33 m/s velocity. Straight-braking validation from 100 km/h to 0 km/h with automated KPI evaluation.	Relevant brake-system HIL baseline, but no FPGA acceleration, AI virtual sensing, TCN-based wheel speed prediction, or microsecond-level latency is reported.
[34]	Static driving HIL simulator + EPSiL steering bench	Maximum simulator delay: ≈1 ms. KPI errors: <10% for full-brake, pulse-brake, and brake-in-turn tests; <8% for sine-steer test.	Automotive HIL validation with real brake-by-wire hardware and steering feedback, but no FPGA implementation, AI prediction, or FPGA resource analysis is reported.
[35]	Software/model-based ABS/TCS simulator	Braking without ABS: $R^2=0.99$, $0.99$, and $0.98$ for vehicle, front-wheel, and rear-wheel speeds. With ABS/TCS active: $R^2=0.99$ for wheel speeds.	Good ABS/TCS model-validation baseline, but software-based and without FPGA timing, hardware utilization, or AI-based virtual wheel speed prediction.
[20]	FPGA-based HLS real-time simulator	For a 41-state NPC converter at 100 MHz: time step = 310 ns, 680 ns, and 630 ns for custom FPGA, VHLS resource-constrained, and VHLS latency-constrained designs. Derived throughput: 3.23, 1.47, and 1.59 MSamples/s. Error < 0.01%.	Strong FPGA real-time benchmark, but not automotive, not AI-based, and does not include TCN virtual wheel speed prediction or ABS ECU closed-loop validation.
[24]	FPGA-based embedded real-time digital simulator	FPGA latency: ≈10 μs for an RL circuit and 16 μs for a PMDC motor. PC-based simulation: 5–20 ms for RL and 2.08 s for PMDC.	Useful FPGA real-time baseline, but focused on simple electrical/mechanical systems rather than AI-enabled automotive ABS ECU testing.
[23]	Neural-network-based HIL implementation	Neural-network-based control-profile performance is reported.	Relevant as an AI-enabled HIL example, but not automotive ABS-specific and not focused on FPGA-based virtual wheel speed sensing.
This work	FPGA-based AI-driven HIL simulator on Xilinx ZCU102	PL inference latency: 5.45 μs; total latency: 10.61 μs; throughput: 94.3 Ksamples/s. TCN MSE: $3.77\times {10}^{-4}$; MAE: 0.0099. FPGA fixed-point MSE $\le 0.001043$. Resource usage: 7.8% LUTs, 10.83% FFs, 9.70% BRAMs, and 2.54% DSPs.	Combines TCN-based virtual sensing, FPGA acceleration, deterministic low-latency execution, closed-loop ABS ECU testing, prediction accuracy, and FPGA resource efficiency in one platform.

provides a quantitative comparison between the proposed platform and existing automotive HIL, FPGA-based real-time simulation, and AI-enabled HIL studies. The comparison shows that most automotive HIL platforms mainly report system-level validation metrics, such as braking distance, wheel speed correlation, slip behavior, or KPI error, while detailed timing and hardware metrics such as latency, throughput, WCET, jitter, and FPGA resource utilization are often not reported. In contrast, FPGA-based real-time simulators provide microsecond- or sub-microsecond-level deterministic execution, but they are generally applied to power-electronics or electromechanical systems rather than AI-enabled ABS ECU testing.

Compared with these prior works, the proposed platform combines three aspects in a single framework: closed-loop ABS ECU validation, TCN-based virtual wheel speed sensing, and FPGA-based low-latency inference. The FPGA implementation achieves a PL inference latency of 5.45 μs, an end-to-end latency of 10.61 μs, and a throughput of approximately 94.3 Ksamples/s, while maintaining high prediction accuracy with a TCN validation MSE of $3.77\times {10}^{-4}$ and an MAE of 0.0099. The low FPGA resource utilization further indicates that the architecture can be extended toward additional virtual sensors, more wheel speed channels, or larger neural network models.

Traditional physics-based wheel speed simulators are commonly used in HIL platforms because they provide interpretable models based on vehicle dynamics, tire–road interaction, wheel inertia, brake torque, and slip behavior. However, these simulators are typically executed on CPU-based real-time platforms or commercial HIL systems. Their computational cost is usually reported using solver step size, real-time factor, CPU load, or simulator delay rather than FPGA-specific metrics such as LUT, FF, BRAM, and DSP utilization. Therefore, a direct FPGA resource-utilization comparison with model-based wheel speed simulators is not always possible.

Recent FPGA-based HIL studies have also explored physics-based real-time simulation of electrical machines. For example, Bergheim et al. [36] proposed a semi-analytical, discrete-time model for externally excited synchronous machines and implemented it on FPGA for high-frequency real-time HIL simulation. Although this work targets electric-machine behavior rather than ABS wheel speed sensing, it demonstrates the value of mapping physically interpretable models to FPGA hardware for deterministic HIL execution. The proposed work is complementary to such physics-based FPGA-HIL approaches because it focuses on a data-driven TCN-based virtual wheel speed sensor for ABS ECU testing.

The proposed TCN-FPGA implementation maps the virtual wheel speed prediction directly to programmable logic. The selected design achieves a PL inference latency of 5.45 μs and a total end-to-end latency of 10.61 μs, while using 7.8% LUTs, 10.83% FFs, 9.70% BRAMs, and 2.54% DSPs on the ZCU102 platform. The estimated power analysis shows that dynamic power accounts for 78% of total power consumption. This comparison indicates that physics-based simulators provide physical interpretability, whereas the proposed FPGA-based TCN virtual sensor provides learned prediction capability, deterministic low-latency execution, and measurable FPGA resource utilization and power characteristics for closed-loop ABS ECU HIL testing.

5.3. Scope and Future Closed-Loop Robustness Validation

The present study focuses on validating the real-time FPGA implementation of the TCN-based virtual wheel speed sensor, including prediction accuracy, end-to-end latency, throughput, and closed-loop integration with the ABS ECU. Although the HIL platform demonstrates that the predicted wheel speed signals can be generated and injected into the ECU loop in real time, a full robustness-oriented ABS control campaign under severe operating conditions is beyond the scope of this work. Such a campaign would require systematic testing under abrupt road-friction transitions, actuator delays, noisy measurements, and sensor disturbances.

This extension is technically supported by the same TruckSim–Simulink HIL workflow used in this study. In our related ABS HIL fault-scenario framework [37], several challenging operating conditions were systematically generated, including brake and steering delays, brake-only delay, stuck-at wheel-speed faults, sudden maximum braking, wheel speed drift, spike/drop disturbances, scaling errors, and steering saturation. These scenarios provide a direct basis for extending the proposed FPGA-based virtual-sensing platform toward more comprehensive closed-loop ECU robustness validation under safety-critical conditions.

Nevertheless, rare safety-critical ABS events, such as abrupt road-friction transitions, extreme low-friction surfaces, sensor faults, actuator faults, and unusual driver maneuvers, require targeted scenario generation and additional validation against real vehicle or chassis-dynamometer data. These conditions will be targeted in future dataset extensions to better evaluate the robustness of the TCN virtual sensor under rare but safety-relevant braking events.

In addition to targeted synthetic rare-event generation, future validation will include real vehicle sensor data, chassis-dynamometer measurements, or controlled physical braking experiments. These experiments will allow direct comparison between TruckSim-generated responses, TCN-predicted wheel speed signals, and measured real sensor signals under representative braking conditions. Such validation is necessary to assess robustness under real sensor noise, actuator delays, tire–road variability, vehicle load changes, and other practical deployment effects that may not be fully captured by simulation-based data alone.

Although the proposed platform was validated with the Bendix EC-60 ABS ECU, additional validation is required to assess real-world hardware variability across different ECU models and sensor interfaces. Future work will therefore include testing with multiple ABS ECUs, sensor-noise profiles representative of physical wheel speed sensors, and long-duration closed-loop experiments under different operating conditions. In addition, future real-time characterization will include worst-case execution time (WCET), closed-loop jitter measurements, and scalability analysis when increasing the number of simulated wheels or adding additional virtual sensors. These experiments will provide a more complete assessment of robustness, timing determinism, and scalability for safety-critical automotive HIL applications.

The proposed low-latency TCN-FPGA virtual sensor framework can also be extended beyond conventional ABS ECU testing toward autonomous-vehicle HIL validation. Autonomous vehicles require precise, predictive, and safety-critical braking and stability-control algorithms that must be evaluated under deterministic real-time conditions before deployment. As discussed by Wiseman [38], autonomous vehicles can support more conservative and energy-efficient driving behavior by reducing excessive acceleration, unnecessary braking, and inefficient speed profiles. In this context, the proposed FPGA-based HIL platform could be adapted to evaluate predictive braking behavior, wheel speed dynamics, and stability-control responses for autonomous-driving applications, while maintaining low-latency execution and closed-loop safety validation.

5.4. Safety and Certification Considerations

The proposed TCN-based virtual wheel speed sensor is intended as a research HIL testing component and does not claim compliance with automotive or avionics certification standards such as ISO 26262 or DO-178C. However, because ABS ECU testing is safety-critical, the use of data-driven virtual sensors requires careful consideration of potential failure modes and safety-monitoring mechanisms. Possible failure modes include prediction drift during long closed-loop operation, inaccurate predictions under out-of-distribution driving scenarios, sensitivity to sensor noise, fixed-point quantization effects, and timing or communication faults in the closed-loop HIL interface.

Future safety-oriented implementations should therefore include independent monitoring and fallback mechanisms. These may include range checks on predicted wheel speed values, plausibility checks based on vehicle dynamics constraints, watchdog timers for communication and execution timing, fault-injection tests, and comparison against physics-based reference models. A hybrid rule-based and AI architecture could further improve safety by allowing the TCN to provide low-latency learned prediction while an independent rule-based or physics-based supervisor detects physically inconsistent outputs and triggers fallback behavior when needed. Such an approach would better align the proposed platform with ISO 26262-style principles, where safety mechanisms, diagnostic coverage, and fail-safe behavior are required for safety-critical automotive validation.

6. Conclusions

This work introduced an AI-driven closed-loop HIL simulation platform on an FPGA for real-time closed-loop testing of ABS ECU functionality. The integration of the HIL simulator with a predictive TCN model enables the proposed framework to achieve accurate real-time wheel speed prediction under the evaluated HIL scenarios. The FPGA implementation ensures low-latency processing and high-speed performance and enables testing of diverse and complex ABS ECU scenarios.

The proposed framework reduces the gap between theoretical designs and practical applications by replicating real-world conditions in a closed-loop simulation environment. The FPGA-based closed-loop HIL simulation integrated with AI allows continuous monitoring of the ABS ECU and supports more reliable and extensible ABS testing.

The current validation mainly focuses on signal prediction accuracy, FPGA resource efficiency, and real-time latency, while closed-loop robustness under extreme friction transitions, rare safety-critical braking events, and long-duration prediction drift remains pending future validation.

This framework provides a scalable and efficient basis for FPGA-based AI-assisted HIL testing and can be extended to other automotive ECU validation tasks.