As the demand for sustainable transportation grows, hybrid electric vehicles (HEVs) have emerged as a pivotal solution to balance environmental sustainability and driving convenience. However, HEV users often face challenges in locating optimal charging and fueling stations efficiently, while privacy concerns over user data hinder the development of centralized recommendation systems. This research addresses these issues by proposing a vertical federated learning (VFL)-based recommendation algorithm that integrates blockchain and cloud computing, ensuring both privacy protection and high-efficiency station recommendation for HEVs.
Abstract
As a low-carbon and eco-friendly transportation mode, the hybrid electric vehicle (HEV) has witnessed rapid development. To safeguard user privacy during the recommendation process, I introduce a HEV station recommendation algorithm rooted in vertical federated learning. The approach employs a local training and central aggregation mechanism to update local models without compromising privacy. By combining blockchain technology with cloud computing, a secure cloud service network is established to transmit encrypted training parameters, replacing centralized architectures prone to single-point failures with a decentralized aggregator. Experimental results demonstrate that the decentralized algorithm with 10 cloud nodes outperforms traditional centralized methods by 5.2 seconds, highlighting its efficiency in recommending stations while mobilizing idle resources effectively.
Keywords
hybrid electric vehicle, recommendation algorithm, vertical federated learning, charging station recommendation, cloud computing, blockchain
1. Introduction
The proliferation of electric vehicles (EVs) has reshaped transportation, but challenges like limited range and charging infrastructure shortages persist. HEVs, blending internal combustion engines with electric drives, alleviate these issues by offering both eco-friendliness and long-distance capability. However, the lack of dedicated recommendation algorithms for HEVs—considering both charging stations (CS) and gas stations (GS)—has spurred this research.
Existing recommendation methods for EVs have notable limitations. Li et al. [3] proposed a collaborative filtering algorithm based on historical charging behavior, but it overlooks vehicle and station characteristics. Sundstrom et al. [4] optimized charging routes by integrating EVs, power grids, and road networks, yet prioritized traffic and grid stress over user experience. Nordlander [5] focused on shortest-path planning without addressing real-world charging prediction in China. Domestically, 邵尹池等 [6] developed a spatio-temporal charging load prediction model, but it neglects large-scale traffic network impacts. These methods often excel in simulated environments but lack practical viability, particularly regarding data privacy in the era of GDPR regulations [10].
To bridge these gaps, I present a VFL-based recommendation algorithm for HEVs. The approach ensures privacy through local training, central parameter aggregation, and blockchain-validated cloud nodes. By integrating decentralized cloud networks, it enables real-time, privacy-preserving recommendations while optimizing station utilization.
2. Methodology
2.1 System Model and Parameter Definition
The recommendation system model focuses on three key participants: HEVs, CSs, and GSs, denoted as \(k = \{1, 2, 3\}\). Each participant holds a local dataset \(D_k\) with samples \(\{x_i, y_i\}\), where \(x_i\) represents features and \(y_i\) denotes labels (e.g., idle, charging, fueling). The goal is to derive model parameters \(\Theta \in \mathbb{R}^d\) that minimize the loss function while preserving privacy.
In VFL, participants may have distinct feature spaces. The model must align these spaces securely. Let \(\Theta_{hev}\), \(\Theta_{cs}\), and \(\Theta_{gs}\) represent parameters for HEVs, CSs, and GSs, respectively. The performance of the VFL model \(M_{vfl}\) must approximate that of a centralized model \(M_{cent}\) within a tolerance \(\sigma\):\(|\sigma_{vfl} – \sigma_{cent}| < \sigma \quad (1)\) where \(\sigma_{vfl}\) and \(\sigma_{cent}\) denote the performances of \(M_{vfl}\) and \(M_{cent}\), respectively.
2.2 Feature Selection for Recommendation
Key features influencing HEV station selection are categorized into three groups, as outlined in Table 1. These features are critical for training a robust recommendation model that balances distance, cost, waiting time, and vehicle status.
| Category | Features |
|---|---|
| \(d_{hev}\) | Vehicle location, average speed, weather, surrounding infrastructure, traffic congestion, battery capacity, charging start/end times, vehicle status (charging/fueling/driving) |
| \(d_{cs}\) | CS latitude/longitude, number of chargers, average charging capacity, cost, parking/service fees, charging duration |
| \(d_{gs}\) | GS latitude/longitude, number of fuel pumps, average fueling cost, capacity, waiting/fueling time |
2.3 Vertical Federated Learning Framework
The VFL process comprises two main phases: encrypted entity alignment and local model training.
2.3.1 Encrypted Entity Alignment
Participants (HEV, CS, GS) generate encrypted samples of their identifiers (e.g., location, cost) and compute the intersection of these sets to align common entities. This ensures only matched records are used for training, preserving privacy by avoiding direct sharing of raw data [12].
2.3.2 Local Model Training
The training workflow involves five steps:
- Cloud aggregator \(c_p\) sends initialized parameters \((\theta_{hev}, \theta_{cs}, \theta_{gs})\) to participants.
- Participants compute intermediate values (gradients, losses), encrypt them, and exchange results.
- Encrypted gradients and losses are sent to \(c_p\) for aggregation.
- \(c_p\) returns updated parameters, which participants decrypt to update local models.
- A recommendation list \(L_i\) (0–2 for idle/charging/fueling) is generated and sorted.
For illustrative purposes, consider a ridge regression model with homomorphic encryption. The training objective is:\(\min_{\theta_{hev}, \theta_{cs}, \theta_{gs}} \sum_i \left( \Theta_{hev}x_i^{hev} + \Theta_{cs}x_i^{cs} – y_i + \Theta_{gs}x_i^{gs} – z_i \right)^2 + \lambda \left( g(\Theta_{hev}) + g(\Theta_{cs}) + g(\Theta_{gs}) \right) \quad (2)\) where \(\lambda\) is a regularization parameter, and \(g(\cdot) = \frac{1}{2}\|\cdot\|^2\). The encrypted loss function is:\(\llbracket L \rrbracket = \llbracket \sum_i \left( u_i^{hev} + u_i^{cs} – y_i + u_i^{gs} – z_i \right)^2 + \lambda \left( g(\Theta_{hev}) + g(\Theta_{cs}) + g(\Theta_{gs}) \right) \rrbracket \quad (3)\) with \(u_i^{hev} = \Theta_{hev}x_i^{hev}\), \(u_i^{cs} = \Theta_{cs}x_i^{cs}\), and \(u_i^{gs} = \Theta_{gs}x_i^{gs}\). The loss can be decomposed into local and inter-participant components, such as:\(\llbracket L_{hev} \rrbracket = \sum_i \llbracket (u_i^{hev})^2 + \lambda g(\Theta_{hev}) \rrbracket \quad (4)\)\(\llbracket L_{hev \to cs} \rrbracket = 2\sum_i \llbracket u_i^{hev}(u_i^{cs} – y_i) \rrbracket \quad (5)\) Gradients are computed as:\(\llbracket \frac{\partial L}{\partial \Theta_{hev}} \rrbracket = \sum_i \llbracket d_i \rrbracket x_i^{hev} + \llbracket \lambda \Theta_{hev} \rrbracket \quad (6)\) where \(\llbracket d_i \rrbracket = \llbracket u_i^{hev} \rrbracket + \llbracket u_i^{cs} – y_i \rrbracket + \llbracket u_i^{gs} – z_i \rrbracket\).
2.4 Blockchain-Enhanced Cloud Architecture
To secure the cloud network, I integrate blockchain technology to validate and register cloud nodes. The CloudletChain framework operates in four steps:
- New Node Registration: A cloud node \(c_{new}\) submits a transaction TX with its public key and hash, entering a transaction pool for validation.
- Transaction Validation: A randomly selected miner node \(c_m\) verifies TX and packages it into a block \(b_r\), which is broadcast to the network.
- Block Mining: Miners solve a proof-of-work puzzle to validate the block, ensuring its integrity using Merkle tree hashing:\(H(TX_n + TX_{n-1}) = H(hash(TX_n)) + H(hash(TX_{n-1})) \quad (7)\)
- Ledger Update: The validated block is added to the blockchain, and all nodes update their ledgers, ensuring transparent and tamper-proof operations.
This architecture ensures that only authorized cloud nodes participate in parameter aggregation, enhancing system security and reliability [14–15].
3. Experimental Evaluation
3.1 Dataset and Setup
The experiment uses real-world data from a Chinese city between September and December 2023, including:
- 20 CSs: ID, charging history, cost, location
- 20 GSs: ID, fueling cost, location, number of pumps
- 50 HEVs: ID, battery capacity, remaining charge, charging time
Ten cloud nodes are distributed geographically to facilitate fast communication, with their information recorded on the blockchain.
3.2 Evaluation Metrics
- Queuing Probability: Likelihood of waiting at a recommended station.
- Total Cost: Sum of charging/fueling and parking fees.
- Time Utilization: Percentage of time stations are in use.
- Hourly Revenue: Station earnings per hour.
- Execution Time: Time to generate recommendations.
- Communication Delay: Time from request to receiving recommendations.
3.3 Baseline Algorithms
- Real-Time Recommendation (RT) [16]: A collaborative filtering-based approach.
- EFT: A state-of-the-art federated learning method.
3.4 Results and Analysis
3.4.1 Performance Comparison
Table 2 shows the proposed algorithm outperforms baselines in key metrics. Compared to RT, it reduces queuing probability by 89.3%, total cost by 23.0%, and increases time utilization by 36.5%. Against EFT, it further reduces cost by 7.3% and improves hourly revenue, demonstrating its efficiency in balancing user cost and station profitability.
| Algorithm | Queuing Probability | Total Cost (CNY) | Parking Cost (CNY) | Time Utilization | Hourly Revenue (CNY) |
|---|---|---|---|---|---|
| RT [16] | 0.122 | 25.231 | 3.579 | 0.148 | 7916 |
| EFT | 0.085 | 20.948 | 1.754 | 0.193 | 9021 |
| Proposed | 0.013 | 19.426 | 0.126 | 0.202 | 9062 |
3.4.2 Execution Time Analysis
Figure 1 (conceptual) illustrates how execution time scales with the number of participants. With fewer participants, the system processes data swiftly, but as the number increases (e.g., 50 HEVs, 20 CSs/GSs), execution time grows linearly but remains manageable, indicating the algorithm’s scalability.
3.4.3 Waiting Time Analysis
The waiting time metric \(\rho\), defined as the difference between historical and current HEV waiting times, is crucial for user experience. The proposed algorithm maintains a low and stable \(\rho\), especially for HEVs encountering congested stations (e.g., HEV8, HEV13, HEV16), where it avoids recommending busy stations, thus minimizing waiting time (Figure 2, conceptual).
3.4.4 Communication Delay
Figure 3 (conceptual) compares communication delays in centralized and decentralized networks. A centralized system takes ~9 seconds to generate recommendations, while the decentralized approach with 10 cloud nodes reduces this to ~3 seconds, a 66.7% improvement. Increasing cloud nodes further decreases delay, highlighting the advantage of decentralized architectures for real-time applications.
3.4.5 Blockchain Overhead
Adding new cloud nodes introduces blockchain mining overhead. Figure 4 (conceptual) shows that as the number of blocks increases, the minimum and maximum mining times rise, though the variance remains manageable for small network sizes. This trade-off between security and latency is acceptable for HEV recommendation systems requiring robust privacy protection.
4. Conclusion
This research presents a VFL-based recommendation algorithm for HEVs that integrates blockchain and cloud computing to address privacy and efficiency challenges. By enabling local training with central aggregation, the approach preserves user privacy while delivering accurate, real-time recommendations. Experimental results confirm that the algorithm outperforms traditional methods in queuing probability, cost, and time utilization, with a 5.2-second speedup over centralized systems using 10 cloud nodes.
Future work will extend the model to public electric vehicles, such as buses, requiring real-world data collection and validation in public transport networks. Additionally, the impact of blockchain on data protection within the recommendation system will be further analyzed to optimize security and performance trade-offs.