Safety warning processing method and device of new energy vehicle and new energy vehicle

Abstract

This application discloses a safety alarm processing method, device, and vehicle for new energy vehicles. The method includes: acquiring a data set of operating conditions and hardware parameters of the new energy vehicle during operation; obtaining a preset alarm threshold and preset parameter weight for each type of hardware parameter in the hardware parameter dataset; correcting the preset alarm threshold and preset parameter weight for each type of hardware parameter based on the operating condition dataset to obtain a target alarm threshold and target parameter weight for each type of hardware parameter; determining a first weighted feature vector corresponding to multiple types of hardware parameters based on each type of hardware parameter and its corresponding target parameter weight; analyzing the first weighted feature vector using a pre-trained false alarm identification model to obtain an identification result; and issuing a vehicle safety alarm based on the identification result. This application solves the technical problem that traditional new energy vehicle alarm schemes are prone to false alarms due to fixed thresholds and unreasonable parameter weights.

Description

Technical Field

[0001] This application relates to the field of vehicle control technology, and more specifically, to a safety alarm processing method, device, and new energy vehicle for new energy vehicles. Background Technology

[0002] Safety alarms for new energy vehicles can provide timely risk warnings before or at the initial stage of a malfunction, preventing accidents from escalating and ensuring the safety of occupants, the vehicle, and the public. Existing safety alarm methods often rely on static parameter thresholds, failing to develop specific risk rules for different operating conditions to address instantaneous parameter disturbances under complex circumstances. For example, a fixed threshold scheme sets fixed voltage safety thresholds for both fast charging and driving modes, ignoring the wider voltage fluctuation range in fast charging mode. This leads to frequent false alarms during fast charging or missed overvoltage risks in driving mode, severely impacting user experience and system reliability. Furthermore, existing technologies use the same weight for multi-dimensional monitoring data, failing to differentiate the true contribution of each parameter to safety risks. For instance, temperature changes that foreshadow battery thermal runaway are far more valuable for early warning than vehicle acceleration fluctuations, but traditional methods fail to distinguish between them, weakening effective features and amplifying false alarms, resulting in low accuracy in risk feature selection and weak model generalization ability.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a method, device, and vehicle for handling safety alarms in new energy vehicles, in order to at least solve the technical problem that traditional alarm schemes for new energy vehicles are prone to false alarms due to fixed thresholds and unreasonable parameter weights.

[0005] According to one aspect of the embodiments of this application, a safety alarm processing method for new energy vehicles is provided, comprising: acquiring a data set of operating conditions and a data set of hardware parameters during the operation of the new energy vehicle, and acquiring a preset alarm threshold and a preset parameter weight corresponding to each type of hardware parameter in the hardware parameter dataset; determining the target operating condition type of the new energy vehicle based on the data set of operating conditions, and correcting the preset alarm threshold and preset parameter weight corresponding to each type of hardware parameter based on the target operating condition type to obtain a target alarm threshold and a target parameter weight corresponding to each type of hardware parameter; generating a candidate alarm event when any type of hardware parameter does not match the corresponding target alarm threshold, and determining a first weighted feature vector corresponding to multiple types of hardware parameters based on each type of hardware parameter and the corresponding target parameter weight, analyzing the first weighted feature vector using a pre-trained alarm false alarm identification model to obtain an identification result; if the identification result indicates that the candidate alarm event is a false alarm, blocking the candidate alarm event; if the identification result indicates that the candidate alarm event is not a false alarm, issuing a vehicle safety alarm.

[0006] Optionally, the process of acquiring the operating condition dataset and hardware parameter dataset of the new energy vehicle during operation includes: collecting operating condition data of the first dimension during the operation of the new energy vehicle, wherein the first dimension includes at least one of the following: vehicle speed, road conditions, ambient temperature, charging status, and driving mode; collecting hardware parameters of the second dimension during the operation of the new energy vehicle, wherein the second dimension includes at least one of the following: battery pack temperature, individual battery voltage difference, vehicle body insulation resistance, inverter temperature, motor speed, brake master cylinder pressure, and wheel speed difference; performing data preprocessing on the collected operating condition data to obtain the operating condition dataset, and performing data preprocessing on the collected hardware parameters to obtain the hardware parameter dataset, wherein the data preprocessing includes at least one of the following: outlier removal, missing value imputation, normalization, and one-hot encoding.

[0007] Optionally, the target operating condition type of the new energy vehicle is determined based on the operating condition dataset, including: analyzing the operating condition dataset using a pre-trained vehicle operating condition classification model to obtain the target operating condition type of the new energy vehicle. The type of the vehicle operating condition classification model includes one of the following: lightweight convolutional neural network, decision tree, random forest. The target operating condition type includes at least one of the following: high temperature static, high temperature high speed discharge, low temperature driving, fast charging condition, bumpy road condition, high speed cruise, and static after charging.

[0008] Optionally, the preset alarm threshold and preset parameter weight corresponding to each type of hardware parameter are corrected based on the target operating condition type to obtain the target alarm threshold and target parameter weight corresponding to each type of hardware parameter. This includes: for each type of hardware parameter, determining a target threshold correction coefficient corresponding to the target operating condition type and the type of hardware parameter from a preset first calibration database, wherein the first calibration database stores threshold correction coefficients for different types of hardware parameters under different operating conditions that have been pre-calibrated; correcting the preset alarm threshold corresponding to the hardware parameter based on the target threshold correction coefficient to obtain the target alarm threshold corresponding to the hardware parameter; for each type of hardware parameter, determining a target weight correction coefficient corresponding to the target operating condition type and the type of hardware parameter from a preset second calibration database, wherein the second calibration database stores weight correction coefficients for different types of hardware parameters under different operating conditions that have been pre-calibrated; correcting the preset parameter weight corresponding to the hardware parameter based on the target weight correction coefficient to obtain the corrected parameter weight corresponding to the hardware parameter; and normalizing the corrected parameter weights corresponding to multiple types of hardware parameters to obtain the target parameter weight corresponding to each type of hardware parameter.

[0009] Optionally, the training method for the false alarm identification model includes: constructing an initial identification model, wherein the initial identification model includes at least one of the following types: a combination model of residual network and bidirectional long short-term memory network, a combination model of convolutional neural network and gated recurrent unit, and a lightweight Transformer model; obtaining multiple sets of historical hardware parameter datasets when new energy vehicles are driving under various operating conditions, wherein the historical hardware parameter datasets include: a first type of historical hardware parameter dataset when the vehicle actually malfunctions and a second type of historical hardware parameter dataset when the vehicle generates false alarms due to non-malfunction reasons; for each set of historical hardware parameter datasets, correcting the preset parameter weights corresponding to each type of hardware parameter in the historical hardware parameter dataset based on the operating condition type corresponding to the historical hardware parameter dataset, and determining the second weighted feature vector corresponding to multiple types of hardware parameters in the historical hardware parameter dataset based on the corrected parameter weights, using the second weighted feature vector as a set of training samples, and using the actual malfunction or false alarm generated due to non-malfunction reasons as the corresponding sample label; using the obtained multiple sets of training samples to iteratively train the initial identification model, adjusting the model parameters based on the backpropagation algorithm to obtain the false alarm identification model, wherein the loss function used in the training is the cross-entropy loss function.

[0010] Optionally, the method further includes: storing the weighted feature vector and the recognition result as a set of sample data in a sample database; periodically optimizing and training the alarm false alarm recognition model based on the sample data in the sample database, and updating the model parameters of the alarm false alarm recognition model.

[0011] Optionally, the candidate alarm event is a Level 3 vehicle safety alarm event. If the identification result indicates that the candidate alarm event is a false alarm, the candidate alarm event is masked. If the identification result indicates that the candidate alarm event is not a false alarm, a vehicle safety alarm is issued, including: if the identification result indicates that the candidate alarm event is a false alarm, masking the candidate alarm event and generating a disturbance prompt message, wherein the disturbance prompt message is used to indicate that there is a hardware parameter disturbance caused by non-fault reasons; if the identification result indicates that the candidate alarm event is not a false alarm, a Level 3 vehicle safety alarm is issued, and corresponding vehicle control operations are executed, wherein the vehicle control operations include at least one of the following: high voltage cut-off, power limitation, hazard light activation, and emergency call.

[0012] According to another aspect of the embodiments of this application, a safety alarm processing device for new energy vehicles is also provided, comprising: an acquisition module, configured to acquire a data set of operating conditions and a data set of hardware parameters during the operation of the new energy vehicle, and acquire a preset alarm threshold and a preset parameter weight corresponding to each type of hardware parameter in the hardware parameter data set; a correction module, configured to determine the target operating condition type of the new energy vehicle based on the data set of operating conditions, and correct the preset alarm threshold and preset parameter weight corresponding to each type of hardware parameter based on the target operating condition type, to obtain a target alarm threshold and a target parameter weight corresponding to each type of hardware parameter; an identification module, configured to generate a candidate alarm event when any type of hardware parameter does not match the corresponding target alarm threshold, and determine a first weighted feature vector corresponding to multiple types of hardware parameters based on each type of hardware parameter and the corresponding target parameter weight, and analyze the first weighted feature vector using a pre-trained alarm false alarm identification model to obtain an identification result; and a processing module, configured to block the candidate alarm event if the identification result indicates that the candidate alarm event is a false alarm, and issue a vehicle safety alarm if the identification result indicates that the candidate alarm event is not a false alarm.

[0013] According to another aspect of the embodiments of this application, a computer program product is also provided, the computer program product comprising: a computer program, wherein when the computer program is executed by a processor, it implements the above-described safety alarm processing method for new energy vehicles.

[0014] According to another aspect of the embodiments of this application, a new energy vehicle is also provided, which includes a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-described safety alarm processing method for the new energy vehicle through the computer program.

[0015] In this embodiment, the target operating condition type of the new energy vehicle is determined by the operating condition dataset, and the preset alarm thresholds and preset parameter weights corresponding to various hardware parameters are corrected based on the target operating condition type to obtain the target alarm threshold and target parameter weights. This realizes the adaptive adjustment of alarm thresholds and parameter weights to changes in operating conditions and the differentiated weight allocation of key hardware parameters. At the same time, based on each type of hardware parameter and the corresponding target parameter weight, the first weighted feature vector corresponding to multiple types of hardware parameters is determined. Combined with the pre-trained alarm false alarm identification model, the weighted feature vector is used to identify false alarms. This effectively suppresses false alarms caused by environmental disturbances or instantaneous fluctuations, enhances the ability to identify real fault characteristics, improves the accuracy of alarm decision-making and scenario adaptability, and effectively solves the technical problem that traditional new energy vehicle alarm schemes are prone to false alarms due to fixed thresholds and unreasonable parameter weights. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0017] Figure 1 This is a schematic diagram of an optional safety alarm processing method for new energy vehicles according to an embodiment of this application;

[0018] Figure 2 This is a schematic diagram of the distribution of an optional on-board sensor device for a new energy vehicle according to an embodiment of this application;

[0019] Figure 3 This is a schematic diagram of an optional target alarm threshold and target parameter weight determination process according to an embodiment of this application;

[0020] Figure 4 This is a schematic diagram of the training process of an optional false alarm identification model according to an embodiment of this application;

[0021] Figure 5 This is a schematic diagram of an optional safety alarm processing device for new energy vehicles according to an embodiment of this application;

[0022] Figure 6 This is a schematic diagram of an optional electronic device for implementing a safety alarm processing method for new energy vehicles according to an embodiment of this application; Detailed Implementation

[0023] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0024] It should be noted that the terms "first," "second," etc., used in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0025] To better understand the embodiments of this application, the following is a translation and explanation of some nouns or terms that appear in the description of the embodiments of this application:

[0026] Level-3 Vehicle Safety Alert is the highest level in a multi-level alarm system set up according to relevant standards and the vehicle manufacturer's safety architecture. Essentially, it is the final confirmation and emergency response triggering mechanism for irreversible failure modes such as thermal runaway, high-voltage leakage, and brake failure. Its triggering means that there is an emergency risk that directly threatens the life safety of the occupants, the integrity of the vehicle structure, or public safety. Mandatory protective measures must be implemented immediately to prevent catastrophic consequences.

[0027] Example 1

[0028] According to an embodiment of this application, a safety alarm processing method for new energy vehicles is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0029] Figure 1 This is a flowchart illustrating a safety alarm handling method for new energy vehicles according to an embodiment of this application, as shown below. Figure 1 As shown, the method includes the following steps S102-S108:

[0030] Step S102: Obtain the operating condition dataset and hardware parameter dataset of the new energy vehicle during driving, and obtain the preset alarm threshold and preset parameter weight corresponding to each type of hardware parameter in the hardware parameter dataset.

[0031] Step S104: Determine the target operating condition type of the new energy vehicle based on the operating condition dataset, and correct the preset alarm threshold and preset parameter weight corresponding to each type of hardware parameter based on the target operating condition type to obtain the target alarm threshold and target parameter weight corresponding to each type of hardware parameter.

[0032] Step S106: If any type of hardware parameter does not match the corresponding target alarm threshold, generate candidate alarm events, and determine the first weighted feature vector corresponding to multiple types of hardware parameters based on each type of hardware parameter and the corresponding target parameter weight. Analyze the first weighted feature vector using a pre-trained alarm false alarm identification model to obtain the identification result.

[0033] Step S108: If the identification result indicates that the candidate alarm event is a false alarm, the candidate alarm event is blocked; if the identification result indicates that the candidate alarm event is not a false alarm, a vehicle safety alarm is issued.

[0034] The following section explains each step of the safety alarm handling method for new energy vehicles, based on a specific implementation process.

[0035] As an optional approach, regarding step S102 above, the operating condition dataset and hardware parameter dataset of the new energy vehicle during driving are obtained, and the preset alarm threshold and preset parameter weight corresponding to each type of hardware parameter in the hardware parameter dataset are obtained.

[0036] Specifically, the aforementioned operating condition dataset is multi-dimensional time-series data reflecting the dynamic state of the vehicle during driving, including but not limited to vehicle speed, ambient temperature, road conditions (such as urban, highway and bumpy roads), charging status, driving mode (such as driving discharge mode, acceleration mode, energy recovery mode and cruise mode), power battery charge and discharge rate, braking pressure change rate and vehicle acceleration information.

[0037] Specifically, the aforementioned hardware parameter dataset consists of multi-dimensional vehicle physical measurement data with time-series characteristics, including but not limited to battery pack temperature time series, individual cell voltage difference time series, vehicle body insulation resistance time series, motor winding temperature time series, inverter temperature time series, motor speed time series, brake master cylinder pressure time series, and wheel speed difference time series.

[0038] Optionally, the specific steps for obtaining the above-mentioned operating condition dataset and hardware parameter dataset are as follows:

[0039] First, the vehicle's operating condition data is collected in real time through onboard sensors and control systems.

[0040] Optionally, the above-mentioned operating condition data acquisition process includes: acquiring wheel rotation pulse signals through wheel speed sensors installed on the wheel hub or gearbox output shaft, which are then converted into vehicle speed by the electronic control unit; fusing data such as vehicle speed, steering wheel angle, and braking pressure through an inertial measurement unit (including accelerometers and gyroscopes), and having the vehicle controller or domain controller determine the road condition type (e.g., highway, city, bumpy) in real time, and generating structured labels as driving road conditions; and directly measuring the external temperature through an external temperature sensor (e.g., NTC thermistor type) located near the vehicle's front grille or rearview mirrors. The system outputs an analog voltage signal, which is converted from analog to digital by the vehicle control module to obtain the ambient temperature. Through collaborative data acquisition with the on-board charger via the battery management system, it monitors parameters such as the charging gun connection status, charging current / voltage, and battery state of charge change rate to determine whether the vehicle is currently in a charging state, such as not charging, slow charging, fast charging, or charging complete. Through the vehicle controller, based on a comprehensive judgment of multiple sources of signals such as driver operation (e.g., gear position signal, driving mode knob status), vehicle speed, battery state of charge, and power demand, it outputs predefined driving modes such as "city," "highway," and "bumpy."

[0041] Then, the hardware parameters of the second dimension during the driving process of new energy vehicles are collected in real time through various vehicle sensors and bus systems.

[0042] Optionally, Figure 2 This is a schematic diagram of the distribution of an optional on-board sensor device for a new energy vehicle according to an embodiment of this application, such as... Figure 2 As shown, the above hardware parameter acquisition process includes: temperature parameters (such as battery pack temperature and inverter temperature) are acquired at each sampling moment by thermistor temperature sensors embedded inside the battery module (for acquiring battery pack temperature) and on the surface of the inverter power module substrate or heat sink (for acquiring inverter temperature); the voltage acquisition chip built into the battery management system performs millisecond-level parallel sampling of each cell to obtain the voltage of each individual cell, and calculates the difference between the maximum and minimum voltage values ​​to form the individual cell voltage difference; a dedicated insulation monitoring module injects a small AC or DC detection signal between the high-voltage system and the chassis to measure the change in circuit current, and calculates the positive current based on Ohm's law. The insulation resistance value of the negative electrode to ground is used to obtain the vehicle body insulation resistance; the frequency of rotor magnetic pole change is detected by a rotary transformer or Hall effect speed sensor installed on the motor shaft, and a pulse signal is output, which is counted by the electronic control unit and converted into motor speed; the hydraulic pressure is directly measured by a piezoresistive pressure sensor installed at the brake master cylinder outlet, and an analog voltage signal proportional to the pressure is output, which is converted into a digital quantity by the brake control unit to obtain the brake master cylinder pressure; the wheel speed is collected by wheel speed sensors (usually electromagnetic induction type or Hall type) installed on the four wheel ends, and the electronic stability control system synchronously samples and calculates the speed difference between diagonal or coaxial wheels to obtain the wheel speed difference.

[0043] It should be noted that the selection of the above hardware parameters follows the triggering mechanism and safety risk level definition of Level 3 vehicle safety alarm events. Core hardware parameters that are directly related to Level 3 vehicle safety alarm events, have a clear abnormal mode, and can be collected in real time by existing on-board sensors are selected from the vehicle's power system, battery system, high-voltage system, and braking system. This ensures that the selected hardware parameters can fully characterize the vehicle characteristics of Level 3 vehicle safety alarm events that threaten occupant safety and vehicle structural integrity.

[0044] Finally, the collected operating condition data is preprocessed to obtain the operating condition dataset, and the collected hardware parameters are preprocessed to obtain the hardware parameter dataset. The above data preprocessing includes at least one of the following: outlier removal, missing value imputation, normalization, and one-hot encoding.

[0045] Specifically, the data preprocessing operations described above can include: First, identifying and removing outliers from the collected operating condition data and hardware parameters based on the 3σ criterion or box plot method to ensure statistical validity; second, since the data are all time series data, data gaps often occur in a certain time dimension after removing invalid data. Linear interpolation can be used to fill in these gaps, ensuring the integrity of the time series data; third, normalizing all parameters to map the original data with different dimensions and value ranges to a unified standard interval of [0,1], eliminating the impact of dimensional differences on subsequent model calculations; finally, since operating condition data is often represented in natural language, one-hot encoding is needed for non-numerical data (such as driving mode and charging status) to convert them into binary vectors that can be directly processed by neural networks. These steps, executed sequentially, form standardized, structured, dimensionless operating condition datasets and hardware parameter datasets, providing a consistent and reliable feature foundation for subsequent operating condition type classification and dynamic weight allocation of hardware parameters.

[0046] To determine under what parameter conditions a new energy vehicle is in a normal, warning, or dangerous state based on the collected hardware parameter dataset, and thus provide a basis for the alarm logic, reasonable alarm thresholds and parameter weights can be set to clarify the abnormal vehicle status corresponding to different ranges of each hardware parameter.

[0047] Optionally, the preset alarm threshold and preset parameter weights for each type of hardware parameter in the hardware parameter dataset can be obtained in the following way:

[0048] The preset alarm thresholds can be set according to the safety limits specified in relevant standards such as the "Safety Requirements for Power Batteries for New Energy Vehicles" and the "Safety Requirements for High-Voltage Systems of New Energy Vehicles." For example, the battery pack temperature threshold can be set to 65℃, the vehicle body insulation resistance threshold to 100Ω / V, and the single-cell voltage difference threshold to 300mV. These thresholds serve as initial benchmarks to ensure that the hardware parameters of new energy vehicles comply with industry safety standards and operate within a compliant framework.

[0049] Among them, the preset parameter weights can be assigned by new energy vehicle manufacturers based on their engineering experience and historical fault analysis, according to the degree of contribution of each hardware parameter to vehicle safety failure. For example, hardware parameters that are directly related to thermal runaway or braking failure, such as battery pack temperature, vehicle insulation resistance and brake master cylinder pressure, can be assigned a high base weight of 0.8–1.0; while indirect or low-risk parameters such as wheel speed difference and motor speed can be assigned a low base weight of 0.1–0.3 to reflect the priority differences of various hardware parameters in safety decision-making.

[0050] As an optional approach, regarding step S104 above, the target operating condition type of the new energy vehicle is determined based on the operating condition dataset, and the preset alarm threshold and preset parameter weight corresponding to each type of hardware parameter are corrected based on the target operating condition type to obtain the target alarm threshold and target parameter weight corresponding to each type of hardware parameter.

[0051] The aforementioned vehicle operating condition classification model is a machine learning or deep learning model used for real-time identification of the operating status of new energy vehicles. It includes, but is not limited to, lightweight convolutional neural networks, decision trees, and random forests. This model extracts features and classifies patterns from the collected operating condition dataset to output the corresponding vehicle target operating condition type.

[0052] The aforementioned target operating condition types refer to the driving states of new energy vehicles with specific thermodynamic and dynamic characteristics during actual operation. These include, but are not limited to, high-temperature static conditions, high-temperature high-speed discharge, low-temperature driving, fast charging conditions, bumpy road conditions, high-speed cruising, and static conditions after charging. These types are based on a comprehensive representation of multi-dimensional parameters in the operating condition data set, used to guide subsequent dynamic threshold correction and parameter weight allocation, ensuring that the alarm strategy is adapted to the current operating condition.

[0053] Alternatively, the target operating condition type for new energy vehicles can be determined based on the operating condition dataset in the following manner:

[0054] Specifically, the operating condition dataset is input into a pre-trained vehicle operating condition classification model. The pre-trained vehicle operating condition classification model is used to analyze the operating condition dataset. Based on the operating condition-feature mapping relationship learned from massive historical operating condition data, the pre-trained vehicle operating condition classification model extracts the data features of the above operating condition dataset. Through model inference, the normalized probability distribution of various vehicle operating condition types is determined in the forward propagation stage. Finally, the vehicle operating condition type with the highest probability is output according to the maximum probability principle, thus obtaining the target operating condition type of new energy vehicles.

[0055] By employing the above method, a pre-trained vehicle operating condition classification model is used to perform end-to-end analysis on the operating condition dataset, enabling accurate classification of target operating conditions such as high-temperature static, high-temperature high-speed discharge, low-temperature driving, fast charging, bumpy road conditions, high-speed cruising, and static after charging. This achieves automatic classification from operating condition data to structured operating condition labels, intuitively reflecting the current vehicle operating condition of new energy vehicles.

[0056] Furthermore, after obtaining the target operating condition type, the preset alarm threshold and preset parameter weights corresponding to each type of hardware parameter can be modified based on the target operating condition type to obtain the target alarm threshold and target parameter weights corresponding to each type of hardware parameter:

[0057] Optionally, Figure 3 This is a schematic diagram illustrating an optional target alarm threshold and target parameter weight determination process according to an embodiment of this application, as shown below. Figure 3 As shown, the target alarm threshold and target parameter weights for each type of hardware parameter include:

[0058] Step S11: For each type of hardware parameter, determine the target threshold correction coefficient corresponding to the target operating condition type and the type of hardware parameter from the preset first calibration database.

[0059] The first calibration database stores threshold correction coefficients for different types of hardware parameters under different operating conditions. The first calibration database uses "operating condition type - hardware parameter type" as a two-dimensional index. Each index combination corresponds to a threshold correction coefficient that has been pre-calibrated through real vehicle testing and operating condition-parameter correlation analysis. For example, the correction coefficient for battery temperature under high temperature conditions is k=1.1, which allows the battery temperature to have a certain upward floating space and avoids false alarms triggered by instantaneous over-temperature.

[0060] Optionally, the above-mentioned target threshold correction coefficient determination process includes: obtaining the target operating condition type and the type of hardware parameter to be corrected; using the operating condition type and parameter type as key values, performing precise matching based on the first calibration database; and retrieving the correction coefficient that uniquely corresponds to the operating condition type and parameter type. The correction coefficient is a multiplication factor derived from a large amount of real-vehicle operating data during the calibration process, used for scaling adjustments on a preset alarm threshold to ensure that the alarm threshold adapts to the normal fluctuation range under different operating conditions. The entire target threshold correction coefficient determination process is executed in real-time in the vehicle control unit using a table lookup method, eliminating the need for online calculations and ensuring low latency and high reliability, thereby achieving efficient mapping from static calibration data to dynamic threshold adjustment.

[0061] Step S12: Correct the preset alarm threshold corresponding to the hardware parameters based on the target threshold correction coefficient to obtain the target alarm threshold corresponding to the hardware parameters.

[0062] Optionally, the process of correcting the preset alarm threshold includes: multiplying the target threshold correction coefficient obtained based on the target operating condition type and hardware parameter type by the preset alarm threshold to obtain the target alarm threshold, as shown in the following formula:

[0063]

[0064] In the formula, Indicates the target alarm threshold. This indicates the preset alarm threshold. This represents the target threshold correction coefficient.

[0065] Step S13: For each type of hardware parameter, determine the target weight correction coefficient corresponding to the target operating condition type and the type of hardware parameter from the preset second calibration database.

[0066] The second calibration database stores pre-calibrated weight correction coefficients for different types of hardware parameters under different operating conditions. The second calibration database uses "operating condition type - hardware parameter type" as a two-dimensional index. Each index combination corresponds to a weight correction coefficient calibrated by the vehicle manufacturer based on historical fault data, safety priority analysis, and real vehicle operating condition experiments. Each item is the weight correction coefficient of a specific hardware parameter under a specific operating condition type, reflecting the safety contribution of the hardware parameter under that operating condition.

[0067] Optionally, the above-mentioned target weight correction coefficient determination process includes: using the target operating condition type and hardware parameter type as index keys, performing a precise lookup in the second calibration database to obtain the corresponding weight correction coefficient. This coefficient is a calibration factor between 0 and 2, used to multiply and correct the basic weights to enhance or suppress the decision-making influence of the parameter under the current operating condition. The entire target weight correction coefficient determination process is completed in real-time in the embedded computing unit using a constant lookup method, with extremely low computational overhead, ensuring dynamic weight adjustment is completed within a millisecond-level response period, and achieving adaptive weighting of risk characteristics in multi-parameter fusion.

[0068] Step S14: Correct the preset parameter weights corresponding to the hardware parameters based on the target weight correction coefficient to obtain the corrected parameter weights corresponding to the hardware parameters.

[0069] Optionally, the above-mentioned preset parameter weight correction process includes: multiplying the target weight correction coefficient obtained based on the target operating condition type and hardware parameter type by the preset parameter weight to obtain the corrected parameter weight corresponding to the hardware parameter, as shown in the following formula:

[0070]

[0071] In the formula, This indicates the adjustment of parameter weights. Indicates the preset parameter weights. This represents the target weight correction coefficient.

[0072] Step S15: Normalize the weights of the correction parameters corresponding to the multiple types of hardware parameters to obtain the target parameter weights for each type of hardware parameter.

[0073] Understandably, independently multiplying and adjusting the weights of each preset parameter based on the target weight correction coefficient may result in some corrected parameter weights being much larger than other parameter weights, disrupting the relative priority structure of the original parameter weight system. Therefore, normalization is necessary, for example, by using Softmax or Z-Score (Standard Score) to scale all corrected parameter weights to a uniform scale. This ensures that high-priority parameters dominate and low-priority parameters are suppressed without changing their relative size, and avoids gradient explosion and convergence difficulties caused by imbalance in the weighted feature vector values.

[0074] As an optional approach, regarding step S206 above, if any type of hardware parameter does not match the corresponding target alarm threshold, a candidate alarm event is generated, and a first weighted feature vector corresponding to multiple types of hardware parameters is determined based on each type of hardware parameter and the corresponding target parameter weight. The first weighted feature vector is then analyzed using a pre-trained alarm false alarm identification model to obtain the identification result.

[0075] Optionally, Figure 4 This is a schematic diagram illustrating the training process of an optional false alarm identification model according to an embodiment of this application, such as... Figure 4 As shown, the training methods for the above-mentioned false alarm identification model include:

[0076] Step S21: Construct the initial recognition model.

[0077] Optionally, the initial recognition model construction process includes: First, based on the temporal characteristics of the hardware parameters, initial recognition models that can capture local spatial features, bidirectional temporal dependencies, and global contextual relationships are set up respectively. The types of the initial recognition models include at least one of the following: a combination model of residual network and bidirectional long short-term memory network, a combination model of convolutional neural network and gated recurrent unit, and a lightweight Transformer model; then, parameter size constraints are applied to each initial recognition model to limit the number of layers, channels, and attention heads of the initial recognition model, ensuring that the inference latency of the model does not exceed a preset threshold; finally, a unified model input dimension (i.e., the hardware parameter dataset dimension that integrates the target parameter weights) and output dimension (i.e., binary classification: real fault or false alarm fault) are set to obtain the initial recognition model.

[0078] Step S22: Obtain multiple sets of historical hardware parameter datasets when the new energy vehicle is driving under various operating conditions. The historical hardware parameter datasets include: a first type of historical hardware parameter dataset when the vehicle actually malfunctions and a second type of historical hardware parameter dataset when the vehicle generates false alarms due to non-malfunction reasons.

[0079] Optionally, the historical hardware parameter dataset acquisition process includes: First, extracting historical hardware parameter data of new energy vehicles under various operating conditions in batches according to time ranges from the cloud big data platform and on-board event recording unit of the new energy vehicle manufacturer; Second, classifying the historical hardware parameter data according to alarm event tags based on the confirmation information in the vehicle maintenance work order, after-sales fault code, and battery management system alarm log: For events confirmed as real faults (such as thermal runaway, insulation breakdown) after inspection, extracting the time sequence data before and after the alarm to form the first category of historical hardware parameter data. For events that trigger a Level 3 alarm but are confirmed to have no substantial fault (such as momentary interference or operating condition fluctuations) after investigation, data for the corresponding time period is extracted to form a second type of historical hardware parameter dataset. Then, the two types of data are uniformly aligned in time, sampled in frequency, and filtered for outliers to ensure consistent time series lengths and matching sampling rates. Each sample is labeled with a binary label of "real fault" or "false alarm". Finally, the two types of datasets are grouped and stored according to operating condition type (such as fast charging, high speed, low temperature, etc.) to construct multiple sets of historical hardware parameter datasets with complete label information and operating condition type attributes.

[0080] Step S23: For each set of historical hardware parameter datasets, the preset parameter weights corresponding to each type of hardware parameter in the historical hardware parameter dataset are corrected based on the working condition type corresponding to the historical hardware parameter dataset. Based on the corrected parameter weights, the second weighted feature vectors corresponding to multiple types of hardware parameters in the historical hardware parameter dataset are determined. The second weighted feature vectors are used as a set of training samples, and the actual fault or the false alarm caused by non-fault reasons is used as the corresponding sample label.

[0081] Optionally, step S23 above can be understood as follows: First, for each set of historical hardware parameter datasets, based on its corresponding operating condition type, retrieve the weight correction coefficient matching the operating condition type-hardware parameter type from the second calibration database, multiply the preset parameter weight by the corresponding correction coefficient to obtain the dynamic correction weight of each historical hardware parameter under the operating condition; then, perform a weighted summation operation on the parameter value of each type of hardware parameter in the historical hardware parameter dataset and its corresponding dynamic correction weight to generate a second weighted feature vector reflecting the adaptability and safety contribution of different operating conditions. The dimension of this vector is equal to the number of types of historical hardware parameters, and each dimension vector represents the relative decision importance of the corresponding hardware parameter under the current operating condition; then, use the second weighted feature vector as a set of training samples. Based on historical fault records and alarm verification results, the actual fault or false alarm caused by non-fault reasons is used as the sample label corresponding to the second weighted feature vector of each group. For example, "1" indicates that the second weighted feature vector of this group corresponds to a real fault, and "0" indicates a false alarm caused by non-fault factors (such as instantaneous disturbances or operating condition fluctuations). Finally, all training samples and sample labels are sorted in chronological order, and a rolling time window partitioning strategy is adopted to divide the sample set into a training set, a validation set, and a test set according to a certain proportion. The training set is used to train the parameters of the initial recognition model, the validation set is used for hyperparameter tuning of the initial recognition model and early stopping mechanism triggering, and the test set is used for final model performance evaluation to ensure that the initial recognition model has the ability to generalize under different samples.

[0082] Step S24: The initial recognition model is iteratively trained using the obtained multiple sets of training samples. The model parameters are adjusted based on the backpropagation algorithm to obtain the alarm false alarm recognition model. The loss function used in the training is the cross-entropy loss function.

[0083] Optionally, the training process of the initial recognition model includes: in each training batch during model training, firstly, using multiple sets of training samples in the training set, the initial recognition model analyzes multiple training samples in the current training batch to obtain the alarm false alarm recognition results. A loss function, such as the cross-entropy loss function, is constructed based on the difference between the alarm false alarm recognition results and the corresponding sample labels. Then, based on the backpropagation algorithm, the model parameters are optimized with the goal of minimizing the loss function. Next, after each preset training round, the optimized model is evaluated using multiple sets of training samples in the validation set. The recognition accuracy, precision, recall, and inference latency of the model in that round on the validation set are calculated. Key metrics such as learning rate, number of network layers, and regularization strength are dynamically adjusted based on the model's convergence trend on the validation set. Then, the model parameters and hyperparameters of the initial recognition model are continuously adjusted through iterative training until a preset termination condition is met (e.g., the number of iterations reaches a preset threshold, or the loss function has converged). This yields a trained false alarm recognition model. Finally, the false alarm recognition model is evaluated using multiple training samples from the test set, and a final evaluation report is output, including quantitative metrics such as the reduction in false alarm rate, recognition accuracy, and millisecond-level inference time. This accurately reflects the model's performance on unknown data, ensuring the reliability of the project deployment.

[0084] To enable the false alarm identification model to adapt to new operating conditions, new fault modes, and the dynamic evolution of vehicle hardware parameters after training, and to overcome the limitations of traditional static models that become fixed after training, the weighted feature vectors input to the false alarm identification model during the model application phase and their corresponding identification results can be stored as a set of sample data in a sample database. The model can then be periodically optimized and trained based on the sample data in the sample database through the aforementioned model training process, updating the model parameters. This allows the model to no longer rely on fixed historical data but continuously absorb newly developed data samples, achieving adaptive evolution of model parameters over time.

[0085] As an optional approach, regarding step S108 above, if the identification result indicates that the candidate alarm event is a false alarm, the candidate alarm event is masked; if the identification result indicates that the candidate alarm event is not a false alarm, a vehicle safety alarm is issued.

[0086] Optionally, if the identification result indicates that the candidate alarm event is a false alarm, the candidate alarm event is blocked to prevent the new energy vehicle from triggering high-risk response actions such as high-voltage cut-off and power limitation. Based on the current operating condition label and the first weighted feature vector, a preset disturbance semantic template is automatically matched to generate disturbance prompt information, such as instantaneous temperature fluctuation, vibration interference, charging transients, etc. The above disturbance prompt information is output to the display instrument of the new energy vehicle in a low-priority, silent, and lightless visual form, so as to realize non-intrusive notification to the driver and ensure that false alarm events do not affect the safety control of the vehicle. At the same time, the interpretability prompts enhance the user's trust in the system. The disturbance prompt information is used to indicate the existence of hardware parameter disturbances caused by non-fault reasons.

[0087] Optionally, if the identification result indicates that the candidate alarm event is not a false alarm, the alarm status is immediately set to the highest priority, a three-level vehicle safety alarm is issued to the driver or passengers, and corresponding vehicle control operations are executed. These vehicle control operations include at least one of the following: high-voltage cutoff, power limitation, hazard light activation, and emergency call. The specific content of these vehicle control operations includes: disconnecting the high-voltage main positive / main negative contactor to cut off the power battery circuit; clearing the motor torque command and locking the power output to force the new energy vehicle to stop; activating the hazard lights to warn surrounding vehicles; and sending an automatic emergency call containing the vehicle's location, fault code, and real-time status to the cloud platform and preset emergency contacts via the T-Box (Telematics Box, vehicle communication terminal) module. All of the above control operations are completed without user intervention, and the execution path is independent of the conventional control bus, ensuring reliable triggering even in the event of a main control unit malfunction. This achieves a zero-delay safety closed loop of identifying alarm events and immediately executing control operations, maximizing the safety of occupants and the vehicle.

[0088] The following explanation, with reference to optional examples, illustrates the safety alarm handling method for new energy vehicles in this application.

[0089] Taking the scenario of new energy vehicles driving at high speeds in high-temperature summer conditions as an example, the specific implementation process of the safety alarm handling method for new energy vehicles is as follows:

[0090] Step S31, Scenario setting: Summer ambient temperature 40℃, new energy vehicle is driving at 120km / h, the preset threshold of battery pack temperature is 62℃, the preset weight of battery pack temperature is 0.5, the battery pack experiences instantaneous temperature overheating due to continuous discharge (instantly rising from 60℃ to 69℃).

[0091] In step S32, the data acquisition module of the new energy vehicle collects hardware parameters such as battery pack temperature, individual cell voltage difference, vehicle body insulation resistance, inverter temperature, motor speed, brake master cylinder pressure, and wheel speed difference through the data bus.

[0092] Step S33: After preprocessing the collected hardware parameter data through the 3σ criterion and linear interpolation method, a hardware parameter dataset is obtained.

[0093] Step S34: The operating condition data collected by the operating condition perception module, namely vehicle speed 120km / h, ambient temperature 40℃, high-speed driving, and discharge rate 0.8C, is preprocessed to obtain the operating condition dataset. The above operating condition dataset is then input into the pre-trained vehicle operating condition classification model, and the target operating condition type is output as "high temperature high speed discharge".

[0094] Step S35: Based on the target operating condition type (i.e., high temperature and high speed discharge), the target threshold correction coefficient is determined to be 1.1, and the preset battery pack temperature threshold of 62℃ is corrected to obtain the target alarm threshold of 68.2℃.

[0095] Step S36: Based on the target operating condition type (i.e., high temperature and high speed discharge), determine the battery pack temperature as the core safety parameter, determine the target weight correction coefficient as 1.2, multiply it by the preset weight of the battery pack temperature as 0.5, and after normalization, determine the target parameter weight of the battery pack temperature as 0.8, and the sum of the weights of other parameters as 0.2.

[0096] Step S37: When the battery pack temperature of 69°C is greater than the target alarm threshold of 68.2°C, a candidate alarm event is generated.

[0097] Step S38: Determine the first weighted feature vector corresponding to multiple hardware parameters based on the target parameter weights, and input the first weighted feature vector into the pre-trained alarm false alarm identification model to extract the time-series features of battery pack temperature (instantaneous rise from 60℃ to 69℃, without a continuous upward trend) and other parameter features (other battery parameters such as voltage and insulation resistance are normal), and output the identification result as a false alarm.

[0098] In step S39, based on the above identification results, the alarm determination module blocks the triggering of the three-level alarm and only displays a slight prompt on the vehicle instrument panel that "the battery temperature fluctuates momentarily and there is no safety risk." The vehicle continues to drive normally without high voltage cutoff or power restriction.

[0099] Through the above steps, the preset alarm thresholds corresponding to the hardware parameter types are adjusted according to the target operating condition type, so that the hardware parameter alarm range is closely integrated with the actual operating conditions. This solves the problem of frequent false alarms in complex operating conditions caused by traditional methods based on fixed parameter thresholds. At the same time, the preset parameter weights corresponding to each hardware parameter type are adjusted according to the target operating condition type, which strengthens the decision-making dominance of core safety hardware in various operating conditions among multiple hardware parameters, and treats non-core safety hardware as secondary features. This effectively dilutes noise interference, allows the model to focus on the highly sensitive features of real faults, and improves the accuracy and robustness of alarm identification. If the hardware parameters do not match the target alarm threshold and a candidate alarm event is triggered, the alarm false alarm identification model extracts features and performs pattern recognition on the first weighted feature vector to determine whether the candidate alarm event is a real fault or a false alarm. This achieves a dual verification mechanism for alarm events, preventing false alarms from affecting the normal operation of new energy vehicles. If the model identification result is a false alarm, the candidate alarm event is masked, and only a light disturbance is displayed, such as "Instantaneous fluctuation in battery temperature, no safety risk," to transparently convey the abnormal situation to the driver, avoiding anxiety and inconvenience caused by unwarranted stopping. If the model identification result is a real fault, the corresponding vehicle control operation is immediately executed to ensure the safety of the vehicle and its occupants.

[0100] Example 2

[0101] According to an embodiment of this application, a safety alarm processing device for new energy vehicles is also provided for implementing the safety alarm processing method for new energy vehicles in Embodiment 1, such as... Figure 5 As shown, the safety alarm processing device for the new energy vehicle includes at least: an acquisition module 51, a correction module 52, an identification module 53, and a processing module 54, wherein:

[0102] The acquisition module 51 is used to acquire the operating condition dataset and hardware parameter dataset of the new energy vehicle during the driving process, and to acquire the preset alarm threshold and preset parameter weight corresponding to each type of hardware parameter in the hardware parameter dataset.

[0103] The correction module 52 is used to determine the target operating condition type of the new energy vehicle based on the operating condition dataset, and to correct the preset alarm threshold and preset parameter weight corresponding to each type of hardware parameter based on the target operating condition type, so as to obtain the target alarm threshold and target parameter weight corresponding to each type of hardware parameter.

[0104] The identification module 53 is used to generate candidate alarm events when any type of hardware parameter does not match the corresponding target alarm threshold, and to determine the first weighted feature vector corresponding to multiple types of hardware parameters based on each type of hardware parameter and the corresponding target parameter weight. The first weighted feature vector is analyzed using a pre-trained alarm false alarm identification model to obtain the identification result.

[0105] The processing module 54 is used to block the candidate alarm event if the identification result indicates that the candidate alarm event is a false alarm, and to issue a vehicle safety alarm if the identification result indicates that the candidate alarm event is not a false alarm.

[0106] The following section explains the functions of each module of the safety alarm processing device for new energy vehicles, based on a specific implementation process.

[0107] The aforementioned acquisition module is also used to acquire operating condition datasets and hardware parameter datasets during the operation of new energy vehicles, including: collecting operating condition data of the first dimension during the operation of new energy vehicles, wherein the first dimension includes at least one of the following: vehicle speed, road conditions, ambient temperature, charging status, and driving mode; collecting hardware parameters of the second dimension during the operation of new energy vehicles, wherein the second dimension includes at least one of the following: battery pack temperature, individual battery voltage difference, vehicle body insulation resistance, inverter temperature, motor speed, brake master cylinder pressure, and wheel speed difference; performing data preprocessing on the collected operating condition data to obtain an operating condition dataset, and performing data preprocessing on the collected hardware parameters to obtain a hardware parameter dataset, wherein the data preprocessing includes at least one of the following: outlier removal, missing value filling, normalization, and one-hot encoding.

[0108] The aforementioned correction module is also used to determine the target operating condition type of new energy vehicles based on the operating condition dataset, including: analyzing the operating condition dataset using a pre-trained vehicle operating condition classification model to obtain the target operating condition type of new energy vehicles. The type of the vehicle operating condition classification model includes one of the following: lightweight convolutional neural network, decision tree, random forest. The target operating condition type includes at least one of the following: high temperature static, high temperature high speed discharge, low temperature driving, fast charging condition, bumpy road condition, high speed cruise, and static after charging.

[0109] The aforementioned correction module is further configured to correct the preset alarm threshold and preset parameter weight corresponding to each type of hardware parameter based on the target operating condition type, thereby obtaining the target alarm threshold and target parameter weight corresponding to each type of hardware parameter. This includes: for each type of hardware parameter, determining a target threshold correction coefficient corresponding to the target operating condition type and the type of hardware parameter from a preset first calibration database, wherein the first calibration database stores pre-calibrated threshold correction coefficients for different types of hardware parameters under different operating conditions; correcting the preset alarm threshold corresponding to the hardware parameter based on the target threshold correction coefficient to obtain the target alarm threshold corresponding to the hardware parameter; for each type of hardware parameter, determining a target weight correction coefficient corresponding to the target operating condition type and the type of hardware parameter from a preset second calibration database, wherein the second calibration database stores pre-calibrated weight correction coefficients for different types of hardware parameters under different operating conditions; correcting the preset parameter weight corresponding to the hardware parameter based on the target weight correction coefficient to obtain the corrected parameter weight corresponding to the hardware parameter; and normalizing the corrected parameter weights corresponding to multiple types of hardware parameters to obtain the target parameter weight corresponding to each type of hardware parameter.

[0110] The training method for the false alarm identification model in the aforementioned identification module includes: constructing an initial identification model, wherein the initial identification model includes at least one of the following types: a combination model of residual network and bidirectional long short-term memory network, a combination model of convolutional neural network and gated recurrent unit, and a lightweight Transformer model; acquiring multiple sets of historical hardware parameter datasets when new energy vehicles are driving under various operating conditions, wherein the historical hardware parameter datasets include: a first type of historical hardware parameter dataset when the vehicle actually malfunctions and a second type of historical hardware parameter dataset when the vehicle generates false alarms due to non-malfunction reasons; for each set of historical hardware parameter datasets, correcting the preset parameter weights corresponding to each type of hardware parameter in the historical hardware parameter dataset based on the operating condition type corresponding to the historical hardware parameter dataset, and determining the second weighted feature vector corresponding to multiple types of hardware parameters in the historical hardware parameter dataset based on the corrected parameter weights, using the second weighted feature vector as a set of training samples, and using the actual malfunction or false alarm generated due to non-malfunction reasons as the corresponding sample label; using the obtained multiple sets of training samples to iteratively train the initial identification model, adjusting the model parameters based on the backpropagation algorithm to obtain the false alarm identification model, wherein the loss function used in the training is the cross-entropy loss function.

[0111] The safety alarm processing device for new energy vehicles also includes an optimization module, which stores the weighted feature vector and the recognition result as a set of sample data in a sample database; periodically optimizes and trains the alarm false alarm recognition model based on the sample data in the sample database, and updates the model parameters of the alarm false alarm recognition model.

[0112] The aforementioned processing module is also used to, when the identification result indicates that the candidate alarm event is a false alarm, to block the candidate alarm event and generate a disturbance prompt message, wherein the disturbance prompt message is used to indicate that there is a hardware parameter disturbance caused by non-fault reasons; when the identification result indicates that the candidate alarm event is not a false alarm, to issue a level three vehicle safety alarm and execute the corresponding vehicle control operation, wherein the vehicle control operation includes at least one of the following: high voltage cut-off, power limitation, hazard light activation, and emergency call.

[0113] It should be noted that each module in the safety alarm processing device for new energy vehicles in this application embodiment corresponds one-to-one with each implementation step of the safety alarm processing method for new energy vehicles in Embodiment 1. Since Embodiment 1 has been described in detail, some details not shown in this embodiment can be referred to Embodiment 1, and will not be elaborated further here.

[0114] Example 3

[0115] According to an embodiment of this application, a computer program product is also provided, which includes a computer program, wherein when the computer program is executed by a processor, it implements the safety alarm processing method for new energy vehicles in Embodiment 1.

[0116] According to an embodiment of this application, a non-volatile storage medium is also provided, which includes a stored computer program, wherein the device where the non-volatile storage medium is located executes the safety alarm processing method for new energy vehicles in Embodiment 1 by running the computer program.

[0117] According to an embodiment of this application, a processor is also provided for running a computer program, wherein the computer program executes the safety alarm processing method for new energy vehicles in Embodiment 1.

[0118] According to another aspect of the embodiments of this application, a new energy vehicle is also provided, which includes a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-described safety alarm processing method for the new energy vehicle through the computer program.

[0119] Specifically, the computer program executes the following steps during runtime: It acquires a dataset of operating conditions and a dataset of hardware parameters during the operation of the new energy vehicle, and obtains the preset alarm threshold and preset parameter weights corresponding to each type of hardware parameter in the hardware parameter dataset; it determines the target operating condition type of the new energy vehicle based on the operating condition dataset, and corrects the preset alarm threshold and preset parameter weights corresponding to each type of hardware parameter based on the target operating condition type, obtaining the target alarm threshold and target parameter weights corresponding to each type of hardware parameter; if any type of hardware parameter does not match the corresponding target alarm threshold, it generates candidate alarm events, and determines the first weighted feature vector corresponding to multiple types of hardware parameters based on each type of hardware parameter and the corresponding target parameter weights; it analyzes the first weighted feature vector using a pre-trained false alarm identification model to obtain the identification result; if the identification result indicates that the candidate alarm event is a false alarm, it blocks the candidate alarm event; if the identification result indicates that the candidate alarm event is not a false alarm, it issues a vehicle safety alarm.

[0120] As an optional implementation, the aforementioned new energy vehicle also includes electronic devices, which may be in the form of mobile terminals, computer terminals, or similar computing devices. Figure 6 A hardware block diagram of an electronic device for implementing a safety alarm processing method for new energy vehicles is shown. Figure 6 As shown, the electronic device 60 may include one or more (shown as 602a, 602b, ..., 602n) processors 602 (processors 602 may include, but are not limited to, processing devices such as microprocessors or programmable logic devices), a memory 604 for storing data, and a transmission device 606 for communication functions. In addition, it may also include: a display, an input / output interface, a universal serial bus port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 6 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, electronic device 60 may also include components that are more... Figure 6 The more or fewer components shown, or having the same Figure 6 The different configurations shown.

[0121] It should be noted that the aforementioned one or more processors 602 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element of the electronic device 60. As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0122] The memory 604 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the safety alarm processing method for new energy vehicles in this embodiment of the application. The processor 602 executes various functional applications and data processing by running the software programs and modules stored in the memory 604, thereby realizing the aforementioned safety alarm processing method for new energy vehicles. The memory 604 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 604 may further include memory remotely located relative to the processor 602, and these remote memories can be connected to the electronic device 60 via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0123] The transmission device 606 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the electronic device 60. In one example, the transmission device 606 includes a network adapter that can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 606 may be a radio frequency module used for wireless communication with the Internet.

[0124] The display can be, for example, a touchscreen LCD display that allows the user to interact with the user interface of the electronic device 60.

[0125] The sequence numbers of the above embodiments are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0126] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0127] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0128] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0129] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0130] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory, random access memory, portable hard drive, magnetic disk, or optical disk.

[0131] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A safety warning processing method for a new energy vehicle, characterized in that, include: Acquire the operating condition dataset and hardware parameter dataset of the new energy vehicle during the driving process, and obtain the preset alarm threshold and preset parameter weight corresponding to each type of hardware parameter in the hardware parameter dataset. Based on the operating condition dataset, the target operating condition type of the new energy vehicle is determined, and based on the target operating condition type, the preset alarm threshold and preset parameter weight corresponding to each type of hardware parameter are corrected to obtain the target alarm threshold and target parameter weight corresponding to each type of hardware parameter. If any type of hardware parameter does not match the corresponding target alarm threshold, a candidate alarm event is generated, and a first weighted feature vector corresponding to multiple types of hardware parameters is determined based on each type of hardware parameter and the corresponding target parameter weight. The first weighted feature vector is analyzed using a pre-trained alarm false alarm identification model to obtain the identification result. If the identification result indicates that the candidate alarm event is a false alarm, the candidate alarm event is blocked; if the identification result indicates that the candidate alarm event is not a false alarm, a vehicle safety alarm is issued.

2. The method of claim 1, wherein, Obtain the operating condition dataset and hardware parameter dataset of new energy vehicles during operation, including: The first dimension of the operating condition data of the new energy vehicle during driving is collected, wherein the first dimension includes at least one of the following: vehicle speed, road conditions, ambient temperature, charging status, and driving mode; The hardware parameters of the second dimension are collected during the operation of the new energy vehicle. The second dimension includes at least one of the following: battery pack temperature, single cell voltage difference, body insulation resistance, inverter temperature, motor speed, brake master cylinder pressure, and wheel speed difference. The collected operating condition data is preprocessed to obtain the operating condition dataset, and the collected hardware parameters are preprocessed to obtain the hardware parameter dataset. The data preprocessing includes at least one of the following: outlier removal, missing value imputation, normalization, and one-hot encoding.

3. The method according to claim 1, characterized in that, Based on the aforementioned operating condition dataset, the target operating condition type of the new energy vehicle is determined, including: The operating condition dataset is analyzed using a pre-trained vehicle operating condition classification model to obtain the target operating condition type of the new energy vehicle. The type of the vehicle operating condition classification model includes one of the following: lightweight convolutional neural network, decision tree, random forest. The target operating condition type includes at least one of the following: high temperature static, high temperature high speed discharge, low temperature driving, fast charging condition, bumpy road condition, high speed cruising, and static after charging.

4. The method according to claim 1, characterized in that, Based on the target operating condition type, the preset alarm threshold and preset parameter weight corresponding to each type of hardware parameter are corrected to obtain the target alarm threshold and target parameter weight corresponding to each type of hardware parameter, including: For each type of hardware parameter, a target threshold correction coefficient corresponding to the target operating condition type and the type of the hardware parameter is determined from a preset first calibration database. The first calibration database stores the threshold correction coefficients of different types of hardware parameters under different operating conditions that have been pre-calibrated. The preset alarm threshold corresponding to the hardware parameter is corrected based on the target threshold correction coefficient to obtain the target alarm threshold corresponding to the hardware parameter; For each type of hardware parameter, a target weight correction coefficient corresponding to the target operating condition type and the type of hardware parameter is determined from a preset second calibration database. The second calibration database stores pre-calibrated weight correction coefficients for different types of hardware parameters under different operating conditions. Based on the target weight correction coefficient, the preset parameter weights corresponding to the hardware parameters are corrected to obtain the corrected parameter weights corresponding to the hardware parameters. The weights of the correction parameters corresponding to multiple types of hardware parameters are normalized to obtain the target parameter weights for each type of hardware parameter.

5. The method according to claim 1, characterized in that, The training methods for the false alarm identification model include: Construct an initial recognition model, wherein the type of the initial recognition model includes at least one of the following: a combination model of residual network and bidirectional long short-term memory network, a combination model of convolutional neural network and gated recurrent unit, and a lightweight Transformer model; Acquire multiple sets of historical hardware parameter datasets when new energy vehicles are driving under various operating conditions. The historical hardware parameter datasets include: a first type of historical hardware parameter dataset when the vehicle actually malfunctions and a second type of historical hardware parameter dataset when the vehicle generates false alarms due to non-malfunction reasons. For each set of historical hardware parameter datasets, the preset parameter weights corresponding to each type of hardware parameter in the historical hardware parameter datasets are corrected based on the working condition type corresponding to the historical hardware parameter datasets. Based on the corrected parameter weights, the second weighted feature vectors corresponding to multiple types of hardware parameters in the historical hardware parameter datasets are determined. The second weighted feature vectors are used as a set of training samples, and the actual fault occurrence or the false alarm caused by non-fault reasons is used as the corresponding sample label. The initial recognition model is iteratively trained using multiple sets of training samples, and the model parameters are adjusted based on the backpropagation algorithm to obtain the false alarm recognition model. The loss function used in the training is the cross-entropy loss function.

6. The method according to claim 1, characterized in that, The method further includes: The weighted feature vector and the recognition result are stored as a set of sample data in a sample database; The alarm false alarm identification model is periodically optimized and trained based on sample data in the sample database, and the model parameters of the alarm false alarm identification model are updated.

7. The method according to claim 1, characterized in that, The candidate alarm event is a Level 3 vehicle safety alarm event. If the identification result indicates that the candidate alarm event is a false alarm, the candidate alarm event is masked; if the identification result indicates that the candidate alarm event is not a false alarm, a vehicle safety alarm is issued, including: If the identification result indicates that the candidate alarm event is a false alarm, the candidate alarm event is blocked and a disturbance prompt message is generated, wherein the disturbance prompt message is used to indicate that there is a hardware parameter disturbance caused by non-fault reasons; If the identification result indicates that the candidate alarm event is not a false alarm, a level three vehicle safety alarm is issued and the corresponding vehicle control operation is executed. The vehicle control operation includes at least one of the following: high voltage cut-off, power limitation, hazard lights activation, and emergency call.

8. A safety alarm processing device for new energy vehicles, characterized in that, include: The acquisition module is used to acquire the operating condition dataset and hardware parameter dataset of the new energy vehicle during the driving process, and to acquire the preset alarm threshold and preset parameter weight corresponding to each type of hardware parameter in the hardware parameter dataset. The correction module is used to determine the target operating condition type of the new energy vehicle based on the operating condition dataset, and to correct the preset alarm threshold and preset parameter weight corresponding to each type of hardware parameter based on the target operating condition type, so as to obtain the target alarm threshold and target parameter weight corresponding to each type of hardware parameter. The identification module is used to generate candidate alarm events when any type of hardware parameter does not match the corresponding target alarm threshold, and to determine the first weighted feature vector corresponding to multiple types of hardware parameters based on each type of hardware parameter and the corresponding target parameter weight. The first weighted feature vector is analyzed using a pre-trained alarm false alarm identification model to obtain the identification result. The processing module is configured to block the candidate alarm event if the identification result indicates that the candidate alarm event is a false alarm, and to issue a vehicle safety alarm if the identification result indicates that the candidate alarm event is not a false alarm.

9. A computer program product, characterized in that, include: A computer program, wherein when executed by a processor, the computer program implements the safety alarm processing method for new energy vehicles as described in any one of claims 1 to 7.

10. A new energy vehicle, characterized in that, include: A memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the safety alarm processing method for new energy vehicles according to any one of claims 1 to 7 through the computer program.

Images