iEVEM: Big Data-Empowered Framework for Intelligent Electric Vehicle Energy Management

1. Introduction

Revolutionary Electric Vehicles (EVs) [1,2] are attracting significant attention nowadays. In addition to their inherent advantages in coping with the global energy crisis and environmental pollution [3], EVs equipped with cutting-edge Information and Communication Technologies (ICTs) (e.g., on-site sensing, artificial intelligence, and 5G) are rapidly progressing to the next-generation personal intelligent mobile terminals. These advancements are expected to profoundly impact people’s daily lives profoundly [4] in the near future. However, EV Energy (EVE) issues like battery safety, range anxiety, and charging economy have become the critical bottleneck hindering the increase of EV’s acceptance and penetration rates [5]. Specifically, the spontaneous combustion caused by battery faults (e.g., thermal failures) seriously limits consumers’ trust in EVs [6,7]. Also, since EVs’ residual range is obviously affected by various factors like ambient temperature and traffic congestion, it is difficult to accurately estimate, and intensely concerns EV drivers [8,9]. As for charging economy [10,11], uncomfortable experiences including inconvenient locations, prolonged queues, and climbing costs caused by less optimized siting of social charging facilities are gradually wearing out drivers’ preference for commuting with EVs.

To alleviate the aforementioned issues, both academia and industry are keen on constructing intelligent EVE Management (EVEM) solutions. On one hand, due to the inherently complex and highly non-linear electrochemical processes, accurate analytical modeling of real-world EVE status remains a significant challenges [8,12,13]. Benefiting from the significantly enhanced ICT capabilities of the EV industry, massive EVE data are being extensively collected during the entire EVE lifecycle, spanning production, service, and retirement. Flourishing attempts focus on data-driven methods, which leverage big data analytics through artificial intelligence techniques such as machine learning and deep learning, and perform promisingly in addressing a variety of EVE issues [6,7,8,9,10,11]. On the other hand, networked EVEM systems comprise distributed and interconnected equipment originating from diverse stakeholders (e.g, vehicle-mounted devices from individuals and cloud servers from organizations). Such a distributed trait offers a range of new opportunities in innovative computing schemes like edge intelligence [14,15,16], which leverages both distributed computing resources to enable efficient and intelligent processing.

However, existing works attempting to EVEM are narrowly scattered on solving detailed data-related or system-specific matters, often lacking generalizability and adaptability across different scenarios. Such a non-generic manner not only results in redundant development efforts but also hinders the proliferation of EVEM, i.e., impeding the scalability and widespread adoption of existing EVEM solutions. Therefore, it elicits the urgent need for a unified framework considering both data and system issues for coping with ever-increasing EVE big data and intelligent EVEM applications. Despite extensive studies on various big data frameworks, e.g., [17,18], their direct application to achieve accurate and efficient EVEM is still challenging due to the following fundamental differences.

• Particularity of Knowledge-Implied EVE Data. Except for traditional big data characteristics [19], EVE big data imply underlying complex domain-specific mechanisms, e.g., the EV energy recovery during braking. General data-driven approaches, which often neglect the incorporation of inherent domain knowledge, face significant challenges in accurately modeling EVE status [8,12,20]. Consequently, developing a framework that facilitates the seamless embedding of subtle and domain-specific knowledge is of paramount importance for achieving precise EVEM.
• Constraints of Resource-Limited EVEM Systems. Networked EVEM systems comprising heterogeneous devices with varying computational and communication capabilities. Traditional edge- and cloud-based schemes, while widely adopted, are often constrained by computational limitations (e.g., on-site EV devices with restricted processing power and memory) or communication bottlenecks (e.g., limited V2X bandwidth under dynamic network conditions). These inherent constraints significantly hinder their ability to ensure prompt and reliable responses required for latency-sensitive applications [21]. Consequently, an efficient EVEM framework capable of operating within limited resources is indispensable for practical deployment.
• Deficiencies of Distributed EVEM Systems and Isolated EVE Data. To protect the privacy [22,23] of different EV stakeholders like manufacturers, vendors, and consumers, EVEM systems are physically distributed and networked, and EVE data are strictly isolated and unassociated [24]. The property critically affects the feasibility and efficiency of EVEM, particularly in scenarios where multi-party and multi-scale spatio-temporal joint analysis is essential for accurate big data analysis. Therefore, addressing these challenges within the framework design is crucial to ensure comprehensive and practical EVEM.

To comprehensively address the above issues, this article presents iEVEM, the first systematic and scalable big data framework designed for intelligent EVEM, whose key contributions are summarized below.

1)

We conduct the first comprehensive investigation on intelligent EVEM. Particularly, we clarify essential EVEM applications at the driver-, enterprise-, and social-levels, effectively highlighting the practical significance of EVEM. Meanwhile, we systematically identify and extract the key challenges associated with designing and implementing a framework for intelligent EVEM, providing

2)

We propose a novel big data framework, termed iEVEM, to address the challenges as mentioned above. Specifically, we construct a layered architecture of EVE data processing and analysis, starting from the physical layer, which manages heterogeneous and isolated EVE data for data collection. This is followed by the data layer and algorithm layer, which enable supporting the efficient design of knowledge-enhanced intelligent solutions, ultimately supporting diverse intelligent EVEM applications in the application layer. Additionally, an edge-cloud collaborative system architecture is introduced to facilitate practical application deployment while effectively addressing the resource constraints of distributed systems.

3)

We conducted a proof-of-concept case study of iEVEM using real-world data to validate its effectiveness. For EV energy consumption outlier detection, the experimental results demonstrate that iEVEM achieves significant improvements in both detection accuracy, with gains of up to 47.48% higher, and response speed, being at least 3.07 × faster compared with state-of-the-art methods. Furthermore, we also highlight several important open issues and research directions for the further development and refinement of intelligent EVEM.

2. Essential EVEM Applications

We first comprehensively classify EVEM applications into distinct user levels, i.e., driver, enterprise, and social levels, which are shown in Figure 1.

2.1. Driver-Level Applications

Driver-level applications serve individuals to enhance general user experiences. Leveraging the energy supplement (i.e., battery) and consumption (i.e., appliances) related data, EVEM offers services to improve driving safety and energy economy.

2.1.1. Driving Safety

Such services guarantee driving safety by identifying and preventing vehicle failures that may cause hazardous even fatal consequences to drivers. For instance, Status Monitoring [25] perceives the current operating condition of EVE components (e.g., battery) and alerts when there is an anomaly (e.g., excessive cell temperature). In such cases, abnormal temperatures need to be warned in time, otherwise, thermal failure would result in combustion or explosion that seriously hampers driving safety [6]. Hence, real-time data analysis is critical for such services. Another example is Predictive Maintenance, which predicts EVE status for preventing potential failures in advance. For example, the battery’s remaining useful life (RUL) [26] indicates its capacity degradation, whose premature decline is a sign of hidden hazards. However, accurate RUL prediction is challenging since it is affected by multiple factors varied with time (e.g., long-term exposure to low temperature will cause irreversible effects on RUL while short-term exposure only results in temporary RUL fluctuations), which indicates the necessity of multi-scale spatio-temporal analysis for addressing EVE status prediction uncertainty.

2.1.2. Energy Economy

Energy economy [27] devotes efficient energy usage, which helps drivers reduce driving overhead by providing the following personalized recommendations. For example, Charging Strategy Optimization [28] offers drivers convenient and efficient charging opportunities. Such strategy development requires multiple considerations from different participants, e.g., drivers’ driving habits, grids’ electricity prices, and surrounding available chargers from map providers. The multi-party decision-making raises privacy concerns, which brings challenges of joint analysis without sharing sensitive information (i.e., raw data). Another example is Energy Consumption Minimization, which helps drivers reduce energy consumption by offering advice, e.g., energy-efficient route planning [11]. The energy consumption is predicted based on various factors (e.g., road slope, traffic congestion, and driving behavior). However, due to the high dynamics of these factors, accurate energy consumption prediction remains a challenge.

2.2. Enterprise-Level Applications

Enterprise-level applications assist relevant enterprises (e.g., battery manufacturers, vehicle companies, and repair factories) to increase their economic values, where EVEM provides tools for boosting profits by quality control and cost reduction.

2.2.1. Quality Control

Such efforts enhance corporate reputation and profits invisibly by ensuring product quality. For instance, Service Vehicle Monitoring [29] guarantees the quality of managed vehicles during operation. By remotely monitoring vehicles’ status, anomalies are timely detected for early maintenance. For enterprises managing large-scale vehicles, prompt response dealing with high concurrency is challenging and should be addressed. Another example is Production Quality Improvement [30], which pursues higher quality products. For instance, cell consistency significantly affects battery quality while different aspects (e.g., voltage and capacity) of consistency imply diverse impacts. To improve the overall consistency, the underlying influence on quality from different aspects requires expert cognition, showing the need for knowledge embedding.

2.2.2. Cost Reduction

These applications improve economic benefits in the direct way of minimizing enterprise costs. Illustratively, Production Process Optimization [31] adjusts the production process (e.g., eliminating redundant work steps) to avoid unnecessary time and labor costs. Actually, the identification and streamlining of inefficiencies in production processes need consult experts for practical feasibility, which illustrates the necessity of introducing expert knowledge into implementable production line optimization. Another example is Intelligent Fault Diagnosis [7]. It assists repairing staff to improve diagnosis efficiency and reduce maintenance costs, which involves automatically detecting faults, identifying root causes, and making decisions. Due to scarce fault data, the expert experience should be efficiently integrated into fault diagnosis since it plays a vital role (e.g., prior failure records) in dealing with insufficient data.

2.3. Social-Level Applications

Social-level applications aid government decision-making in improving social benefits. Hence, EVEM aims at mobilizing resources to build a sustainable and convenient society from environmental protection and public welfare.

2.3.1. Environmental Protection

Such tasks encourage the public to reduce their carbon footprint and promote recycling. For example, Carbon Assets Management [32] is designed to track, measure and manage carbon emissions. For instance, a company managing a fleet of EVs earns carbon credits by counting the carbon emissions reduction of the fleet. For fairness, carbon assets must be calculated accurately, which is hard since it is affected by complicated factors. Another example is Battery Cascade Utilization [33]. It is the practice of repurposing batteries withdrawn from EVs, which is eco-friendly by extending the battery lifespan. The quality of second-life batteries needs to be guaranteed, preferably with access to historical data from different sources (e.g., production, service, and maintenance), where data privacy should be fully considered during cross-silo analysis.

2.3.2. Public Welfare

These applications reflect the government’s efforts to promote the well-being of all citizens. Illustratively, Energy Infrastructure Construction [34] indicates the planning, design, and building of socially valuable energy facilities. For example, charging pile location is a high-profile initiative, which attempts to make chargers more accessible to drivers. Since it requires information from multiple parties (e.g., transport bureau, grid company, and land office), the privacy leakage issue among multiple participants needs to be properly addressed. Another example is Vehicle-to-Grid (V2G) [35]. It refers to the bi-directional flow of energy between EVs and grids, where EVs provide energy back to grids as a distributed power supply during peak demand to reduce strain on grids. To balance benefits between grids and drivers (e.g., grids pay drivers for energy storage and drivers bear their own costs), multi-objective optimizations should be constructed for achieving a win-win V2G, where multifaceted limitations should be considered with the aid of expert advice.

3. Challenges to the EVEM Framework

To support the above applications, significant challenges arise from both data and system perspectives during framework design.

3.1. Data Challenges

Data challenges mainly affect the reliability of EVEM.

①

It is difficult to accurately model EVE using general methods due to underlying complex knowledge. On one hand, given the inherent complexity, nonlinearity, and uncontrollability of energy reactions, EVE status is hard to model formally, which brings great challenges for existing mechanism-driven methods. On the other hand, lacking effective solutions to integrate inherent knowledge, pure data-driven methods struggle to model EVE accurately [8,12] and cannot support reliable EVEM.

②

Unassociated fragmented EVE data pose challenges to multi-scale spatio-temporal correlation analysis. Since EVE status is impacted by a range of factors varying over space and time, multi-scale joint analysis is necessary for EVEM. However, EVE data are collected and possessed in distributed manners and isolated at different owners (e.g., drivers, enterprises, and government agencies) without a way to associate [36]. This seriously impedes the feasibility of joint analysis.

3.2. System Challenges

System challenges primarily hinder the efficiency of EVEM.

③

Rapid response is difficult to satisfy by conventional schemes with limited system resources. In the naturally distributed EVEM systems, low end-to-end (E2E) latency is challenging with limited computing capabilities of edge nodes (e.g., vehicle-mounted devices) and communication resources between nodes (e.g., moving EVs) [21]. Specifically, predominating cloud-based methods requiring massive data uploading suffer from prolonged communication time. Local-based methods, processing data locally entirely, result in unacceptable computation time and cannot support efficient EVEM.

④

Isolated EVEM systems pose challenges to multi-party joint analysis. Numerous EVEM applications inherently require multiple stakeholders (e.g., drivers, enterprises, and government agencies) to participate. However, with widespread and growing privacy concerns [22,37] of participants, all data are best kept locally to prevent privacy leakage. Hence, the strictly isolated systems severely hinder the feasibility of joint analysis across multiple parties.

To address these issues, we propose iEVEM, explicitly presenting its data intelligence architecture and edge-cloud collaborative system architecture in the following sections.

4. Data Intelligence Architecture of iEVEM

To address data challenges, the data intelligence architecture, as demonstrated in Figure 2, is proposed for intelligent solution construction fully considering underlying knowledge and isolated data, comprising the physical, data, and algorithm layers.

4.1. The Physical Layer

The physical layer deals with original data sources. As shown in Figure 2, EVE data are acquired from the EVE full life cycle (i.e., production, service, and maintenance) and domain experts (e.g., mechanical engineer and business manager).

• Production Phase refers to the process from raw materials (e.g., electrolyte) to concrete power battery products (e.g., cell, module, and pack) [38]. Production data are collected by manufacturing equipment, mainly containing battery monitoring records (e.g., current, voltage, and resistance), which are generally structured in a predefined format like spreadsheets and acquired continuously near real-time following specific industrial standards (e.g., ISO 12405 in European Union).
• Service Phase indicates the usage of finished products like EVs and charging piles, where service data record their operating information. Particularly, EV service data are collected by on-board sensors [36] and mainly perceive the status of eic systems, i.e., the battery (e.g., temperature), motor (e.g., velocity), and controller (e.g., regenerative braking). Following the national standard (e.g., GB/T 32960 in China), service data are also collected in structured with a prescribed format and frequencies.
• Maintenance Phase indicates the status of out-of-service, including repairing and recycling. The maintenance data are collected by checkout equipment, which includes the testing information of productions, e.g., fault in repairing and RUL in recycling. Among them, repairing data are usually formatted in semi-structure and varied with enterprises, while recycling data tend to be structured in required testing procedures along with the increasingly published recycling standards (e.g., UL 1974 in America).
• Domain Expert refers to EVE-domain specialists, and the expert knowledge indicates the information converted by prior experience, which is evolved in aforementioned phases (e.g., working procedures in production, energy mechanisms in service, repairing logs in maintenance). Knowledge is usually formatted in semi-structured (e.g., worksheet) and unstructured data (e.g., text), and as an additional input for intelligent solution construction, knowledge representation and embedding are crucial.

4.2. The Data Layer

Based on the data collected from the physical layer, the data layer is applied for data processing. As illustrated in Figure 2, iEVEM has special considerations in data association and knowledge-enhanced feature engineering.

4.2.1. Data Association

In addition to traditional data preprocessing (e.g., data cleansing), data association is required for supporting multi-scale spatio-temporal correlation analysis by aligning distributed and time-dependent EVE data. Considering the EVE property in state transition (e.g., small-scale transition of cells-modules-packs and large-scale transition of service-maintenance-recycle), an identifier for data association is designed for addressing challenge ②, which acts at arbitrary adjacent links. Specifically, the identifier needs to contain temporal (e.g., precursors and successors in linked list structures) and spatial (e.g., hierarchical inclusion relationships like tree structures) information. For any battery pack, the historical records (i.e., precursors links) of cells in it (i.e., inclusion relationships) can be traced back.

4.2.2. Knowledge-Enhanced Feature Engineering

Feature engineering is the process of obtaining informative features from data. For high-quality features (i.e., meaningful, task-oriented, and quantity-appropriate), knowledge should be embedded into feature engineering with challenge ① being considered.

• Step 1: Feature Extraction transforms raw data into sets of features with underlying patterns. Traditional feature extraction, relying on straightforward mathematics properties (e.g., mean and variance), ignores physical meaning with potentially critical information unexplored (e.g., the peak of the incremental capacity curve is a decisive factor for capacity estimation [39]). Knowledge embedding effectively alleviates the issue by forming feature candidates for each data dimension in advance, which facilitates extracting meaningful features by the feat of expert experience.
• Step 2: Feature Selection intends to identify relevant features for given tasks from feature candidates, which is usually achieved by feature importance ranking. However, existing methods (e.g., decision tree) are prone to unstable ranking since they strongly rely on sample data. To enhance the reliability of task-oriented feature selection, expert knowledge is used to guide the identification of critical relevant features (e.g., expert knowledge can be utilized to assign feature weights in feature ranking) for given tasks.
• Step 3: Dimensionality Reduction refers to the process of reducing the quantity of features while preserving sufficient and necessary information, which significantly contributes to subsequent efficient data analysis and model performance. Traditional reduction methods (e.g., PCA and autoencoders) reduce features by changing feature spaces, where transformed dimensions lack clear physical meanings. Domain knowledge helps obtain refined features with practical meaning retained in original feature spaces (e.g., reduce redundant features according to physical correlations or integrate multiple features into one with practical meaning).

4.3. The Algorithm Layer

The algorithm layer is responsible for data analysis based on the features from the data layer, and its results are applied to support the application implementation.

4.3.1. General Model

Existing general models are classified into mechanism- and data-driven based on design principles.

• Mechanism-driven Models are constructed based on the fundamental insights of underlying EVE mechanisms (e.g., physical laws and chemical reactions), which emphasize interpretability and physical fidelity, making them indispensable for EVEM. These models are mainly developed in formalized mathematical expressions for representing the intrinsic principles (e.g., the electrochemical and thermal dynamics of batteries, the operational characteristics of motors, and the energy flow in powertrain systems). For example, equivalent circuit models (ECMs) [7] are widely used to describe battery behavior, leveraging electrical circuit analogies to represent processes like charge transfer and diffusion. While mechanism-driven models exhibit strong interpretability, they often face challenges in terms of adaptability to complex, nonlinear, and uncontrollable energy reactions and systems. Nonetheless, these models remain a reserve and cornerstone for EVEM.
• Data-driven Models are constructed to uncover patterns, relationships, and decision-making rules directly from data, bypassing the need for explicit physical or mechanistic understanding. Such methods are primarily developed by statistics, machine learning, and deep learning. By virtue of learning patterns and relationships from massive historical data, the solution is built automatically based on mined rules. In the context of EVEM, supervised learning algorithms [29], such as decision trees in machine learning and neural networks in deep learning [20], are commonly used to predict battery degradation and RUL based on historical usage patterns. As another model basis of EVEM, the primary strength of data-driven models lies in their ability to automatically learn complex, nonlinear, and uncontrollable relationships from data without domain knowledge. However, these methods also exhibit notable drawbacks in their stability and reliability, suffering from their poor interpretability.

4.3.2. Knowledge-Enhanced Algorithm Construction

Considering the challenge ①, the above general models are difficult to satisfy EVEM demands, where the specified algorithms construction procedure (i.e., knowledge-enhanced algorithm construction) is shown in Figure 2.

• Step 1: Problem Definition abstracts and models the target problem including task types (e.g., classification or regression) and requirements (e.g., optimization objectives and constraint conditions) from real scenarios, which should be expressed explicitly with the aid of domain experts. For instance, expert knowledge in text form can be transformed into optimization formulas through a large language model.
• Step 2: Algorithm Development indicates the design of specified intelligent solutions. Depending on the task type and requirements from the problem definition, practicable base models are selected from the model pool, whose characteristics have been elaborated in advance by experts. After that, the algorithm is designed (e.g., construct a novel one or modify general models) with further considering available data, application demands, and muttons with knowledge guidance (e.g., the optimum parameters are set by prior experience). Moreover, in a knowledge-enhanced way, in addition to expert-guided practicable general model selection and proper parameter setting, knowledge representation and embedding are utilized for algorithm design to further improve performance. For instance, the correlation of EVE components can be presented in the knowledge graph, where nodes represent components (e.g., battery, motor) and edges capture their dependencies (e.g., energy flow or thermal coupling). If a component fails, a graph neural network (GNN) operating on the knowledge graph can trace the connections to identify the root cause, such as linking abnormal motor performance to upstream issues like battery instability or inverter faults.
• Step 3: Solution Validation is the feasibility evaluation of constructed solutions before application launch. However, practical challenges arise for traditional methods (e.g., cross-validation) due to time and labor costs caused by the data availability (e.g., insufficient failure data make the verification of fault diagnosis difficult), label accessibility (e.g., limited labeled samples for cross-validation), and experiment producibility (e.g., battery degradation requiring years to manifest). Therefore, the validation design needs to rely on domain experts to fully consider actual situations (e.g., constructing a simulation environment by domain experts) to address this dilemma.

5. Edge-Cloud Collaborative System Architecture of iEVEM

To address system challenges, an edge-cloud collaborative system architecture, as shown in Figure 3, is adopted for the practical implementation of intelligent solutions in resource-constrained and device-isolated EVEM systems.

5.1. EVEM Systems

As shown in Figure 3a, EVEM systems are naturally distributed and hierarchical [17], i.e., the government is connected with multiple enterprises where a company manages a large number of vehicles. The mapping between either vehicles-enterprise or enterprises-government is roughly abstracted as the edge-cloud architecture, i.e., a cloud is connected with multiple edges that illustrated in Figure 3b. For EVEM systems, on one hand, the available system resources are generally constrained. As shown in Figure 3b, the principal resources of edge-cloud EVEM systems are clarified conceptually as the computing capability of the edges and the cloud and the communication resource between them. First, the computing capacities of edges are limited. For example, vehicles are generally equipped with small chips (e.g., Qualcomm Snapdragon Automotive and NVIDIA DRIVE series), while enterprises are capable of applying powerful servers (e.g., NVIDIA GeForce RTX and AMD Radeon RX series) or even clusters. Then, edge-cloud communication is restricted, e.g., the most commonly used communication technology (i.e., LTE [15]) in vehicles-enterprise may suffer bandwidth fluctuation easily, particularly for high-speed moving vehicles. On the other hand, the sensitive information of EV stockholders (e.g., driver’s personnel information and organization’s core technologies) raises ubiquitous privacy concerns in distributed EVEM systems. Therefore, the data of some participants in EVEM systems need to be strictly isolated.

5.2. Edge-Cloud Collaborative Solution

Considering the resource constraints and isolated manners of networked EVEM systems, an edge-cloud collaborative scheme is adopted for big data processing, including data storage and data computing, with challenges ③ and ④ addressed.

5.2.1. Edge-Cloud Collaborative Storage

Storage collaboration refers to a hybrid data storage architecture designed to balance local storage at edge devices and centralized storage on cloud servers, aiming to optimize efficiency, scalability, and privacy preservation in EVEM. All data generated from edges are initially stored locally. If there are no privacy concerns, the data could be uploaded to the cloud server for permanent storage (e.g., Hadoop Distributed File System (HDFS)). Otherwise, the data are kept at local for privacy preservation. In such scenarios, privacy-preserving techniques, including differential privacy or encryption, can be applied to the data before selective sharing with the cloud.

5.2.2. Edge-Cloud Collaborative Computing

It offloads partial tasks from the cloud to edges while fully respecting the edge-cloud resource imbalance, which achieves rapid response by preventing massive data uploading and excessive local computing load. There are three distinctive and alternative approaches for edge-cloud collaboration (shown in Figure 3c), where edges generally work on local data and the cloud serves as an additional resource for massive data processing and analysis. Note that considering predominant EVE data are collected in real-time as streaming data, stream processing (e.g., Flink) is particularly necessary in addition to the commonly used batch processing (e.g., Spark) for big data processing on the cloud.

• Model Lightweight involves deploying an entire small and efficient model directly on edge devices. In such scenarios, edge devices can independently accomplish tasks without relying on cloud resources, ensuring prompt and robust responses even under poor communication conditions (e.g., vehicles performing in-situ energy-efficient route planning while traveling through a tunnel with limited connectivity). To achieve such lightweight models, techniques such as model distillation, pruning, and quantization merit further exploration, as they enable the reduction of model complexity while maintaining sufficient accuracy for real-time applications.
• Model Partition refers to the strategy of splitting parts of a large-scale model between the cloud and edge devices For example, energy component fault diagnosis using a GNN, the first few GNN layers are executed at vehicles for extracting shallow features (e.g., local anomalies in voltage or current). The extracted features are then sent to the cloud, where the remaining layers of GNN are carried out to perform deeper fault diagnosis, such as identifying root causes. Uploading features instead of massive raw data effectively reduces communication time thus response latency. The communication-efficient technologies like traffic compression (e.g., quantization and sampling) are crucial for further minimizing response latency.
• Model Cascade refers to synergy varisized functional models at the edge device and the cloud server in a staged manner. Take EV fault diagnosis as an example, EV can perform a quick self-check using a lightweight local model to detect potential anomalies and provide rapid alerts. If the local model identifies an ambiguous or complex fault, the cloud-based large model can be engaged for a more accurate and comprehensive diagnosis. Dynamic cascading (i.e., determining when to involve the cloud model based on task) is conducive to the trade-off between latency and accuracy, adapting to real-time requirements and system constraints effectively.

Note that for joint analysis across multiple entities, distributed (e.g., federated learning [40]) and centralized (e.g., cloud-based) methods are applied with or without privacy concerns, respectively. Both of them are supported by the edge-cloud collaborative scheme.

6. Case Study: Outlier Detection of EV Energy Consumption

To demonstrate the effectiveness of iEVEM, we conducted a case study on EV energy consumption outlier detection.

6.1. Scenario

Energy consumption outlier vehicles indicate those with abnormal energy consumption caused by factors like damaged components or manual irregularities. To avoid potential safety risks and operational reliability, accurate and rapid outlier detection is required. From a business perspective, once the actual energy consumption deviates from the rational range, the vehicle is identified as an outlier. Therefore, the EV energy consumption outlier detection can be divided into two key steps, i.e., rational energy consumption estimation and outlier identification. Accordingly, there are two main obstacles to practical application implementation: $1)$ the rational energy consumption is difficult to estimate accurately since it suffers from complex and dynamic driving conditions, and $2)$ the timely outlier detection is hard to achieve within resource-limited vehicle-enterprise networks. Therefore, without loss of generality, we focused on the EV component with the highest energy consumption ratio, the motor, as a representative example in the case study.

6.2. Experimental Setup

6.2.1. Dataset

We used real-world vehicle operation data in the southwestern region of China from our partner (a leading global EV manufacturer), encompassing over 4,000 EVs in three different types of EV within three months (from August to October of 2021). Specifically, each vehicle collects 638 data dimensions of data field per second, following the enterprise standard and national standard of GB/T 32960, which includes the basic information (e.g., vehicle and battery version), vehicle operating status (e.g., velocity and acceleration), battery operating status (e.g., state-of-charge (SOC) and state-of-health (SOH)), appliance operating status (e.g., current and voltage), and external factors (e.g., temperature and altitude), etc. As statistics, there are approximately 1% of vehicles are considered as abnormal, with the energy consumption deviation of 5$\sigma$ (i.e., five standard deviations from the mean of the normal data distribution).

6.2.2. Implementation

• For data intelligence implementation, domain knowledge was embedded in both feature engineering and algorithm construction to enhance accuracy and interpretability. First, 74 attributes were selected from the original 638 features based on expert experiences, with empirically irrelevant attributes to energy consumption (e.g., seat angle) being systematically eliminated. Besides, 49 additional features (e.g., acceleration derived from velocity and time) were constructed based on 74 attributes with essential physical and statistical laws. Then, referring to the business understanding, a two-step algorithm was constructed, comprising a rational energy consumption estimation sub-task with extreme gradient boosting and outlier detection sub-task with Gaussian distribution instead of conventional unsupervised one-step methods [41]. This structured approach ensures better alignment with the practical needs of energy consumption analysis and outlier detection.
• For system implementation, an edge-cloud collaborative prototype was constructed with a Jetson Nano serving as the edge device (representing the EV’s on-site computer) and an NVIDIA 2080 Ti acting as the cloud server (representing the enterprise cloudlet). The edge-cloud communication was configured with a 10Mbps bandwidth, adhering to the LTE standard [24], to simulate realistic network conditions. In this setup, model cascade was employed for efficient edge-cloud collaboration. Specifically, the rational energy consumption estimation task was deployed on the edge device to process local data and minimize the need for massive raw data uploads, thereby reducing bandwidth usage. The cloud server, in turn, aggregated the energy consumption deviations reported by multiple edge devices and performed centralized outlier detection using Flink CEP. This collaborative architecture ensures a balance between local processing efficiency and cloud-level computational scalability, meeting the requirements of real-time and large-scale EVEM.

6.2.3. Metrics

• For evaluating the general performance of iEVEM, the area under the curve (AUC) [41] is adopted as a primary indicator of reliability, which is a widely recognized metric to measure classification performance, particularly in scenarios involving an imbalance between positive and negative samples. Note that the closer the AUC to 1 indicates superior performance. Besides, the E2E latency is utilized as a critical metric for reflecting efficiency, where it denotes the response time from data generation to results obtained, representing the system’s ability to process and respond in a timely manner.
• For evaluating the effectiveness and necessity of iEVEM components, the mean absolute percentage error (MAPE) [42], indicating the energy consumption estimation precision, is used for reflecting reliability. A lower MAPE value reflects higher estimation accuracy, which is critical for ensuring dependable EVEM. Additionally, the E2E latency is also applied to compare the efficiency of different deployment schemes.

6.2.4. Comparatives

Given the absence of sufficient abnormal data, we compared the general performance of iEVEM with state-of-the-art unsupervised outlier detection methods [41]. These methods operate under the assumption that anomalies are typically located in low-density regions of the data distribution. They can be roughly categorized into shallow machine learning (i.e., KNN, CBLOF, IForest, and ECOD) and deep neural network methods (i.e., DSVDD). Since outlier detection requires multiple vehicle participation for distribution statistics, edge-only schemes lacking global information are impracticable. Therefore, all comparatives are implemented in cloud-based settings, with iEVEM being the only solution employing the edge-cloud collaborative design.

6.3. Main Results

To thoroughly validate the effectiveness of iEVEM, we first present its general performance and then explain the necessity of framework components by ablation experiments.

6.3.1. The General Performance

Based on the above setting, we compared the AUC and E2E latency of iEVEM with that of all comparatives. Note that, considering statistics of real-world outliers (i.e., 1% anomaly proportion and $5\sigma$ deviation degree), we conducted extensive experiments with extended different ratios of anomaly injection exceptions R (i.e., $0.1\%$ and $10\%$) and deviation degrees D (i.e., $3\sigma$ and $7\sigma$) indicating scenarios with hard and easy mode (smaller deviations indicate anomalies that closely resemble normal situations and are more challenging to recognize), respectively. As illustrated in Table 1, iEVEM achieves at least 0.94 in terms of AUC and 185ms in terms of E2E latency with various settings, enabling support reliable and efficient EVEM. Additionally, iEVEM is distinctly superior to comparatives (12.86% to 47.48% higher in AUC and $3.07\times$ to $148.97\times$ lower in E2E latency), which demonstrates iEVEM outperforms in detecting outlier vehicles in terms of reliability and efficiency.

6.3.2. Ablation Experiments

The effectiveness of components in iEVEM is demonstrated as follows.

• The Impact of Knowledge-enhanced Approach. We evaluated the impact of data intelligence architecture by the MAPE of rational energy consumption estimation with different data processing and analysis, i.e., mechanism-driven and data-driven methods. The mechanism-driven method is built upon vehicle dynamics referring to [42], i.e., an analytical formulation of vehicle velocity and road grade. The data-driven method is constructed on the same model as iEVEM but without knowledge-enhanced feature engineering, i.e., all data dimensions are utilized. Results are shown in Figure 4a, iEVEM outperforms comparatives in terms of MAPE. Specifically, the knowledge-enhanced method achieves a MAPE of 9.9%, which is substantially lower than the mechanism-driven method’s 13% and the data-driven method’s 12%. It manifests that the knowledge-enhanced approach is conducive to more reliable EVEM.
• The Impact of Edge-cloud Collaborative Deployment. We evaluated the impact of edge-cloud collaborative system architecture on the E2E latency of outlier detection with conventional cloud computing. Shown in Figure 4b, the E2E latency of iEVEM is significantly lower where the identical two-step model is adopted. Specifically, the E2E latency of edge-cloud collaborative deployment is approximately 185ms, which is significantly lower compared to the 685ms observed in the cloud-based deployment. It is worth noting that the collaborative scheme reduces traffic more than $100\times$ compared to the cloud-based scheme. The reduction is attributed to the transformation of raw data into energy consumption values at the edge of proposed two-step model. Hence, the edge-cloud collaboration can effectively reduce the traffic and thus E2E latency, enabling achieving efficient EVEM.

7. Open Issues

We have demonstrated the effectiveness of iEVEM above. There are still important open issues deserving further exploration for more sophisticated EVEM applications.

• Multimodal Data Fusion for EVEM: In addition to the structured data discussed, incorporating broader and more diverse data modalities [25] should be considered to further enhance the effectiveness and accuracy of intelligent EVEM. For instance, integrating visual data and point-cloud data of the road environment can provide richer contextual information, facilitating more precise vehicle energy consumption modeling and prediction. Developing efficient approaches for subtle multimodal data fusion remains a critical challenge.
• Automatic EVEM Knowledge Embedding: A simple attempt at knowledge-enhanced modeling is proven to be effective in this article. However, automated knowledge embedding is essential for handling the vast, diverse, and ever-changing EVEM knowledge. For example, integrating new findings in battery materials or regularly revised energy management standards will require a systematic and automated approach. Nevertheless, achieving such a unified, automatic, and scalable knowledge embedding mechanism poses significant technical challenges and demands further investigation.
• Dynamic Resource Management of EVEM Systems: Given the dynamic and often unpredictable nature of EVEM system resources (e.g., vehicle-to-cloud communication may degrade significantly inside tunnels or during network congestion), developing an agile platform for dynamic resource and scheme management is critical. For example, such a platform could enable seamless switching from in-situ energy-efficient route planning to cloud-based solutions when exiting tunnels or encountering better network conditions. Addressing this issue effectively will require novel strategies to adapt EVEM operations to varying resource availability in real-time.

8. Conclusion

This article presents iEVEM, a novel big data-empowered framework specifically for intelligent management of EV energy, aiming to address the current development bottleneck faced by EVs. By leveraging advanced intelligent techniques, iEVEM addresses the challenges associated with the complexity and fragmentation of EVE data in distributed and heterogeneous EVEM systems.

Specifically, through the comprehensive discussion and taxonomy of essential EVEM applications, the fundamental challenges of designing a framework are systematically sorted out from data and system perspectives. To address these issues, the proposed iEVEM presents data intelligence architecture and edge-cloud collaborative system architecture to facilitate accurate and efficient intelligent EVEM applications. For the data intelligence architecture, a hierarchical structure is proposed. The physical layer is responsible for managing distributed and isolated EVE data, while the data layer and algorithm layer work collaboratively by embedding domain-specific knowledge to derive more reliable big data processing and analysis methods, thereby providing robust support for a wide range of intelligent EVEM applications. For the edge-cloud collaborative system architecture, the edge-cloud collaborative storage and computation is introduced to address the resource constraints and privacy concerns of distributed EVEM systems.

To validate the effectiveness of iEVEM, a case study on energy consumption outlier vehicle detection was conducted using real-world data. The experimental result demonstrates the performance gain of iEVEM in terms of detection accuracy and response speed, showcasing the potential of iEVEM to outperform traditional approaches and be conducive to a wider range of intelligent EVEM applications. Moreover, this article lays a solid foundation for further exploration and innovation in the field of intelligent EVEM, thus, additional promising opportunities are highlighted at the end of this article for the further development of intelligent EVEM applications.