Vehicle, method for risk prediction thereof, and storage medium
Patent Information
- Application Number
- CN202610998623.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-06
- Publication Date
- 2026-10-27
AI Technical Summary
[0018]根据本申请实施例的另一方面,还提供了一种计算机程序,计算机程序被处理器执行时实现本申请各个实施例中的方法。
Smart Images

Figure CN122987608A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicles, and more specifically, to a vehicle, a risk prediction method thereof, and a storage medium. Background Technology
[0002] As vehicles become increasingly intelligent, their systems are becoming more complex. However, current vehicle risk prediction technologies often rely on simple rules or single models, making it difficult to accurately pinpoint potential problems within the vehicle system, thus resulting in low accuracy in risk prediction.
[0003] There is currently no good solution to the above problems. Summary of the Invention
[0004] This application provides a vehicle, a risk prediction method thereof, and a storage medium to at least address the technical problem of low accuracy in risk prediction of vehicles in related technologies.
[0005] According to one aspect of the embodiments of this application, a vehicle risk prediction method is provided, comprising: acquiring vehicle state data and corresponding system change data when a system change occurs in the vehicle; generating target state data based on the change data, state data, and a digital twin model of the vehicle, wherein the target state data is used to represent the vehicle's state data after the system change, and the digital twin model is used to simulate the vehicle's operating state and the performance degradation process of components in the vehicle; and performing risk prediction on the vehicle based on the target state data to obtain a risk prediction result, wherein the risk prediction result is used to indicate whether the vehicle has a preset risk in a future time period.
[0006] Furthermore, based on the change data, status data, and the vehicle's digital twin model, target status data is generated, including: determining the target test scenario from multiple preset test scenarios based on the change data and status data; inputting the target test scenario, change data, and status data into the digital twin model, and using the digital twin model to generate the target status data.
[0007] Furthermore, based on change data and status data, a target test scenario is determined from multiple preset test scenarios, including: determining at least one candidate test scenario from multiple preset test scenarios based on the change object type in the change data, wherein the scenario identifier of at least one candidate test scenario matches the change object type; and determining the target test scenario corresponding to the current working condition from at least one candidate test scenario based on the current working condition in the status data.
[0008] Furthermore, the target test scenario, change data, and status data are input into the digital twin model, and the target status data is generated using the digital twin model. This includes: updating the digital twin model based on the change data to obtain the target digital twin model; determining the component status data of multiple components in the target digital twin model based on the status data, wherein the component status data is used to represent the real-time degradation status of multiple components; and inputting the scenario data, change data, and component status data of the target test scenario into the target digital twin model for simulation to generate the target status data.
[0009] Furthermore, the digital twin model is updated based on the changed data to obtain the target digital twin model, including: determining the data type of the changed data; determining the target update method for the digital twin model based on the data type; and updating the digital twin model based on the target update method and the changed data to obtain the target digital twin model.
[0010] Furthermore, risk prediction is performed on the vehicle based on the target state data to obtain risk prediction results, including: extracting features from the target state data to obtain at least one vehicle performance feature; comparing the at least one vehicle performance feature with the corresponding preset performance benchmark to obtain performance comparison results, wherein the performance comparison results are used to indicate whether there are abnormal indicators in the at least one vehicle performance feature; if the performance comparison results indicate that there are abnormal indicators in the at least one vehicle performance feature, the risk prediction result is determined to be that the vehicle has a preset risk in the future time period.
[0011] Furthermore, at least one vehicle performance feature is compared with its corresponding preset performance benchmark to obtain a performance comparison result, including: if at least one vehicle performance feature meets the corresponding preset performance benchmark, the performance comparison result is determined to be that there is no abnormal indicator in at least one vehicle performance feature; if any one of the at least one vehicle performance features does not meet the corresponding preset performance benchmark, the performance comparison result is determined to be that there is an abnormal indicator in at least one vehicle performance feature.
[0012] Furthermore, the method also includes: when the risk prediction result indicates that the vehicle has a preset risk in the future time period, determining the target component status data and historical status data of the target component corresponding to the abnormal indicator; performing risk prediction based on the target component status data and historical status data to generate the risk occurrence time; determining the risk response strategy based on the risk occurrence time; and outputting the risk response strategy.
[0013] According to another aspect of the embodiments of this application, a vehicle risk prediction device is also provided, comprising: an acquisition module, configured to acquire vehicle state data and corresponding system change data when a system change occurs in the vehicle; a generation module, configured to generate target state data based on the change data, state data, and a digital twin model of the vehicle, wherein the target state data represents the vehicle's state data after the system change, and the digital twin model simulates the vehicle's operating state and the performance degradation process of components in the vehicle; and a prediction module, configured to perform risk prediction on the vehicle based on the target state data to obtain a risk prediction result, wherein the risk prediction result indicates whether the vehicle faces a preset risk in a future time period.
[0014] According to another aspect of the embodiments of this application, a vehicle is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.
[0015] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.
[0016] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.
[0017] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods in various embodiments of this application.
[0018] According to another aspect of the embodiments of this application, a computer program is also provided, which, when executed by a processor, implements the methods of the various embodiments of this application.
[0019] In this application embodiment, a vehicle risk prediction method is proposed. The method first obtains the vehicle's state data and the corresponding system change data when a system change occurs in the vehicle. Then, the change data and state data are input into the vehicle's digital twin model to simulate the vehicle's operating state and the performance degradation process of the vehicle's components, so as to generate target state data describing the vehicle after the system change. Finally, the risk prediction of the vehicle is performed based on the target state data to obtain the risk prediction result. This application employs a method that, under system change triggering, utilizes a digital twin model to fuse real-time vehicle status and change data to reconstruct the future evolution of the vehicle, and conducts risk assessment based on the reconstructed status. By acquiring change data, the source of system disturbance is identified; by acquiring status data, a baseline is established; and by utilizing the ability of the digital twin model to simulate component performance degradation in the vehicle system, change information is combined with component performance degradation trends to generate target status data reflecting the coupling effect of change and aging. This achieves the goal of accurately simulating vehicle behavior under the combined effects of system change and component performance degradation in virtual space, thereby eliminating complex coupling interference that cannot be captured by a single model or simple rules. This improves the accuracy and foresight of vehicle risk prediction, thus solving the technical problem of low accuracy in vehicle risk prediction in related technologies. Attached Figure Description
[0020] 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:
[0021] Figure 1 This is a flowchart of a vehicle risk prediction method according to an embodiment of this application;
[0022] Figure 2 This is a schematic diagram of a vehicle risk prediction system according to an embodiment of this application;
[0023] Figure 3 This is a flowchart of an automated testing method according to an embodiment of this application;
[0024] Figure 4 This is a schematic diagram of a predictive maintenance analysis module according to an embodiment of this application;
[0025] Figure 5 This is a flowchart of a personalized configuration verification method according to an embodiment of this application;
[0026] Figure 6 This is a schematic diagram of a vehicle risk prediction device according to an embodiment of this application. Detailed Implementation
[0027] 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.
[0028] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying 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.
[0029] According to an embodiment of this application, an embodiment of a vehicle risk prediction method 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. Furthermore, 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.
[0030] This embodiment provides a method for predicting vehicle risks. Figure 1 This is a flowchart of a vehicle risk prediction method according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps:
[0031] Step S102: In the event of a system change in the vehicle, obtain the vehicle's status data and the corresponding system change data.
[0032] The aforementioned vehicles can refer to mobile devices equipped with autonomous driving assistance functions. Vehicles may include, but are not limited to, pure electric vehicles, hybrid electric vehicles, fuel cell vehicles, and internal combustion engine vehicles, with the specific vehicles to be determined based on actual circumstances. Vehicles can be used as the implementing entity and monitoring object of the risk prediction method in this application.
[0033] The aforementioned system changes refer to technical activities that substantially alter the vehicle's software logic, hardware configuration, or operating parameters throughout the vehicle's entire lifecycle. System changes may include, but are not limited to, software changes (such as Over-The-Air (OTA) upgrades, feature unlocking, etc.), hardware changes (such as hardware replacement, hardware addition, etc.), and configuration parameter adjustments. The above system changes are merely examples; specific system changes need to be determined based on actual circumstances. System changes can be used as the event source triggering the risk prediction process of this application. Because system changes disrupt the vehicle's original stable state, they may introduce new failure modes or amplify the aging risks of existing hardware; therefore, a reassessment of vehicle safety is necessary.
[0034] The aforementioned status data can refer to a set of data reflecting the vehicle's health status, operating environment, and physical attributes. Status data may include, but is not limited to, vehicle health status data, vehicle operating status data, and system operating status data. Vehicle health status data may include, but is not limited to, battery data and chassis data; vehicle operating status data may include, but is not limited to, driving data such as vehicle speed, acceleration, steering angle, and braking status; and system operating status data may include, but is not limited to, software status and sensor status. Specific status data needs to be determined based on actual conditions. Status data can be used to digitize the current state of a real vehicle. Status data can be used to determine the initial boundary conditions of the digital twin model (such as remaining battery power, motor temperature, and tire wear), ensuring that the simulation results closely approximate the physical constraints of the real world.
[0035] The aforementioned change data refers to structured information corresponding to the specific content of system changes. Change data can be used to quantitatively describe the nature, scope, version, and parameter changes of system changes, serving as the basis for updating the digital twin model to reflect the post-change state. Change data may include, but is not limited to, software change data, hardware change data, and configuration change data; the specific change data needs to be determined based on the actual changes. Change data can drive the evolution of the digital twin model. Change data can be used to determine which modules in the twin model to update (such as replacing sensor models, loading new algorithm logic, or modifying physical parameters), thereby generating target state data reflecting the consequences of the changes.
[0036] In one optional embodiment, when a system change occurs in the vehicle, bus data and sensor signals are collected in real time through the vehicle's onboard network interface to construct status data reflecting the vehicle's current operating conditions, hardware health, and software operating status. Simultaneously, upgrade package metadata, version identifiers, configuration parameter change logs, and hardware replacement records from a cloud server or local diagnostic tool are received as change data. Then, the above two types of data are spatiotemporally aligned and matched to ensure that the differences between the vehicle's baseline state before the change and the specific parameters introduced by the change can be accurately captured at the moment the system change is triggered, thereby providing a high-fidelity, time-consistent data input foundation for subsequent updates to the digital twin model.
[0037] In one optional embodiment, the vehicle system is monitored for changes via a vehicle gateway module. When a system change is detected, the change command corresponding to the system change is parsed to obtain change data, including the change object identifier and parameter change records. Simultaneously, the vehicle status monitoring service is invoked to collect real vehicle sensor readings, bus communication load, and key component health indicators as status data at the moment the change is executed. Then, the change data and status data are bound and encapsulated using the Vehicle Identity Number (VIN) and event timestamp to form a joint data message containing the change context and real-time environmental constraints. This establishes an accurate virtual-real mapping benchmark before the change takes effect, ensuring that subsequent digital twin simulation can assess the potential risks brought about by the change based on the real vehicle physical state, thus improving the timeliness and accuracy of risk prediction.
[0038] Step S104: Based on the change data, status data, and the vehicle's digital twin model, generate target status data. The target status data represents the vehicle's status data after the system change, and the digital twin model simulates the vehicle's operating status and the performance degradation process of the vehicle's components.
[0039] The aforementioned digital twin model refers to a virtual mapping entity built based on a vehicle's multiphysics simulation engine, machine learning algorithms, and real-time data-driven approach, maintaining high-fidelity synchronization with the real vehicle in terms of geometry, physical properties, software logic, and operation. The digital twin model not only includes the vehicle's static geometric information but also integrates dynamic behavioral rules and component degradation patterns that evolve over time. The digital twin model can be used as a virtual simulation platform for risk simulation. It receives change data and current state data as input, simulates the system's performance under "post-change" conditions, predicts potential performance deviations or failure risks, and generates target state data reflecting the expected behavior after the change, without requiring high-risk testing on a real vehicle.
[0040] The aforementioned target state data refers to the set of expected operating states generated after simulation calculations in a digital twin environment. Target state data is the output of the simulation process, representing the ideal or predicted state after changes. Target state data can be used as a basis for risk prediction.
[0041] The aforementioned components can refer to independent functional units that constitute the physical entity or software system of a vehicle. Components can be used as the smallest granular unit for state mapping and prediction. By coupling analysis of performance changes (such as aging) of specific components with system changes (such as software upgrades), the impact of changes on the function of specific components can be determined, thereby achieving fine-grained risk assessment.
[0042] In one optional embodiment, the changed data is imported into the digital twin model for model updates. Simultaneously, the current real-time vehicle operating conditions and component aging levels reflected in the status data are loaded. This drives the updated digital twin model to perform simulation calculations in a virtual environment. By simulating the changed system behavior and component performance degradation trends, target status data reflecting the expected operating performance and performance indicators after the system changes is calculated and output. This process utilizes high-fidelity digital twin technology to pre-assess hardware-software coupling risks in virtual space, avoiding the high costs and long cycles of real-vehicle testing. Furthermore, combining component performance degradation prediction improves the accuracy of risk identification, ensuring the safety and reliability of the system after changes.
[0043] In one optional embodiment, the change data is loaded into the digital twin model, and the remaining lifespan, health indicators, and real-time environmental parameters of each component represented by the status data are read synchronously. A virtual test scenario containing hardware degradation characteristics is constructed, and the digital twin model is driven to perform closed-loop simulation in the virtual space. By calculating the load impact and performance response of the system change on the aging components, target status data containing the expected failure rate, performance threshold, and safety margin after the change is generated, so as to realize the quantitative assessment of the hardware-software coupling risk in the virtual environment.
[0044] Step S106: Perform risk prediction on the vehicle based on the target state data to obtain the risk prediction result, wherein the risk prediction result is used to indicate whether the vehicle has a preset risk in the future time period.
[0045] The aforementioned risk prediction results refer to the likelihood of vehicle risks occurring within a future timeframe after system changes. These predictions may include, but are not limited to, the presence or absence of pre-existing risks within the future timeframe; the specific prediction result must be determined based on the actual circumstances. Risk prediction results can be used to clarify the vehicle's risk situation in the future timeframe, serving as a basis for initiating risk response strategies. By identifying potential risks in advance, a shift from reactive maintenance to proactive predictive maintenance can be achieved, preventing high-risk vehicles from being put on the road or put into operation, and ensuring the safety and reliability of the vehicle throughout its entire lifecycle.
[0046] The aforementioned future time period can refer to a specific time interval or mileage interval extending into the future from the current moment (i.e., the moment the target state data is generated). The future time period can include, but is not limited to, the next 1 day, the next 10 days, the next 30 days, etc., and the specific future time period needs to be determined based on actual forecasting needs. The future time period can be used as a time boundary for risk forecasting. It can also be used to limit the timeliness of forecast results, ensuring that maintenance decisions (such as scheduled repairs, software rollbacks, and functional restrictions) can be executed within a valid window before the actual occurrence of a failure. Different future time periods correspond to maintenance strategies with different levels of urgency; for example, short-term periods are used for emergency early warning, while long-term periods are used for lifespan planning.
[0047] The aforementioned preset risks refer to a pre-defined set of vehicle risk events. Preset risks may include, but are not limited to, risks such as component aging, functional malfunctions, and configuration incompatibility. Specific preset risks need to be determined based on the forecast requirements and the actual vehicle type. Preset risks can provide clear criteria for judging risk prediction results. By matching preset risks, abnormal states requiring attention can be automatically identified, thereby triggering corresponding early warning mechanisms, maintenance recommendations, or system limiting measures to ensure that the vehicle operates within a safe and controllable range.
[0048] In one optional embodiment, target state data is input into a risk prediction model. By comparing it with preset safety thresholds, a historical fault mode library, and critical values of key performance indicators, abnormal features deviating from the normal range in the target state data are identified. The evolution trend of these abnormal features over time is analyzed to determine the probability of them evolving into actual faults in the future, thereby generating a risk prediction result indicating whether the vehicle faces a preset risk in the future. This process automates the conversion from simulation state to quantitative risk assessment, enabling the identification of potential hazards before actual vehicle operation and effectively reducing the rate of sudden failures.
[0049] In one optional embodiment, target state data is input into a risk assessment module based on the fusion of a rule engine and a machine learning model. Key performance indicator sequences are extracted from the target state data, and their evolution trajectory within a future time window is predicted using a machine learning model. The predicted trajectory is then matched against preset risk thresholds and fault logic defined in the rule engine to identify data segments that exceed safety boundaries or meet fault symptom indicators. A comprehensive determination is made of the probability and type of the vehicle triggering a preset risk within a future time period. This results in a risk prediction outcome containing risk level, potential fault points, and confidence level. This process, combining data-driven approaches with logical rules, improves the accuracy of risk identification in complex nonlinear coupled systems, enabling earlier detection of potential fault symptoms.
[0050] In this application embodiment, a vehicle risk prediction method is proposed. The method first obtains the vehicle's state data and the corresponding system change data when a system change occurs in the vehicle. Then, the change data and state data are input into the vehicle's digital twin model to simulate the vehicle's operating state and the performance degradation process of the vehicle's components, so as to generate target state data describing the vehicle after the system change. Finally, the risk prediction of the vehicle is performed based on the target state data to obtain the risk prediction result. This application employs a method that, under system change triggering, utilizes a digital twin model to fuse real-time vehicle status and change data to reconstruct the future evolution of the vehicle, and conducts risk assessment based on the reconstructed status. By acquiring change data, the source of system disturbance is identified; by acquiring status data, a baseline is established; and by utilizing the ability of the digital twin model to simulate component performance degradation in the vehicle system, change information is combined with component performance degradation trends to generate target status data reflecting the coupling effect of change and aging. This achieves the goal of accurately simulating vehicle behavior under the combined effects of system change and component performance degradation in virtual space, thereby eliminating complex coupling interference that cannot be captured by a single model or simple rules. This improves the accuracy and foresight of vehicle risk prediction, thus solving the technical problem of low accuracy in vehicle risk prediction in related technologies.
[0051] Optionally, based on the change data, status data, and the vehicle's digital twin model, target status data is generated, including: determining a target test scenario from multiple preset test scenarios based on the change data and status data; inputting the target test scenario, change data, and status data into the digital twin model, and using the digital twin model to generate target status data.
[0052] The aforementioned pre-set test scenarios refer to a collection of standard test scenarios pre-built and stored in a test scenario library. These pre-set test scenarios can serve as input constraints for digital twin simulations. They can provide specific operational contexts for the digital twin model, ensuring that the simulation process is not conducted in a vacuum or ideal environment, but rather based on real, diverse usage environments. By selecting specific scenarios from the pre-set test scenarios, the performance of system changes under specific operating conditions can be verified in a targeted manner, improving test coverage and effectiveness.
[0053] The aforementioned target test scenarios refer to test scenarios corresponding to changes and status data of the vehicle. Target test scenarios can serve as the simulation environment for the actual use of the digital twin model in the current evaluation task. Target test scenarios can also serve as a vehicle for accurate risk discovery. They enable dynamic adaptation of test scenarios, avoiding the waste of computational resources caused by full simulation of all scenarios. By focusing on scenarios highly relevant to the current changes and status, specific risk points under hardware-software coupling can be discovered more efficiently and accurately, improving the targeting and efficiency of predictive maintenance.
[0054] In one optional embodiment, based on the type of changed object in the change data and the current operating condition of the vehicle represented by the status data, multiple preset test scenarios are screened or matched to determine target test scenarios that can cover potential risks or are representative. Subsequently, the target test scenarios, change data, and status data are synchronously input into the digital twin model, driving the model to perform high-fidelity simulation calculations in a virtual environment, ultimately generating target status data reflecting the expected operating performance and component performance status after the system change. This process, through dynamic matching of test scenarios, achieves accurate deployment of simulation resources, avoids computational redundancy caused by full-scenario simulation, improves the efficiency and relevance of digital twin simulation, and ensures that the target status data accurately reflects the actual impact of system changes on vehicle performance under specific operating conditions.
[0055] In one optional embodiment, firstly, based on the type of changed object in the change data and the vehicle's current operating condition in the status data, a matching algorithm is used to select at least one candidate test scenario most relevant to the changed content and current state from a preset test scenario library. Then, combining the vehicle's real-time operating trajectory data and historical fault records, a weighted fusion algorithm is used to dynamically combine and fine-tune the parameters of the candidate test scenarios, generating a target test scenario combination that includes extreme edge cases. Finally, the target test scenario, change data, and status data are input in parallel into the digital twin model, and parallel simulation acceleration technology is used to generate target status data reflecting the coupling effect of multiple scenarios. This process, by expanding from single-scenario simulation to multi-scenario fusion simulation based on operating condition matching and dynamic combination, can more comprehensively cover the complex boundary conditions that vehicles encounter in actual use, effectively avoiding coverage blind spots caused by single-scenario testing, thereby improving the comprehensiveness of the target status data generated by the digital twin model and the reliability of risk prediction.
[0056] Optionally, based on change data and status data, a target test scenario is determined from multiple preset test scenarios, including: determining at least one candidate test scenario from multiple preset test scenarios based on the change object type in the change data, wherein the scenario identifier of at least one candidate test scenario matches the change object type; and determining a target test scenario corresponding to the current working condition from at least one candidate test scenario based on the current working condition in the status data.
[0057] The aforementioned change object type can refer to the category of a specific vehicle entity or software module in the system change data. Change object types can include, but are not limited to, software changes, hardware changes, configuration changes, and system architecture changes; the specific change object type needs to be determined based on the actual situation. Change object type can be used as the first-level filtering condition for test scenario selection. By identifying the change object type, the system can quickly eliminate scenarios unrelated to the change from multiple preset test scenario libraries, narrowing the search scope and improving the efficiency of determining the target test scenario.
[0058] The aforementioned candidate test scenario can refer to a set of one or more test scenarios that are logically related to the change type, initially selected from multiple preset test scenarios based on the change object type. At least one candidate test scenario can be used as an initial risk coverage set.
[0059] The aforementioned scenario identifiers can refer to the identifiers corresponding to each preset test scenario. Scenario identifiers may include, but are not limited to, hardware test scenario identifiers, software test scenario identifiers, configuration test scenario identifiers, and system architecture test scenario identifiers, etc. The specific scenario identifiers need to be determined based on the actual situation. Scenario identifiers can be used as index keys for matching scenarios with changes. By comparing the change object type with the scenario identifier, automated and rule-based test scenario retrieval can be achieved.
[0060] The aforementioned current operating condition refers to the real-time physical environment and operating status of the vehicle recorded in the status data. The current operating condition can be used as the final criterion for determining the target test scenario. It ensures that the generated target state data not only focuses on the change itself but also on how the change manifests in a specific real-time environment. By matching the current operating condition, the test scenario that best approximates the actual operating state of the vehicle can be selected, thereby improving the accuracy and relevance of the prediction results.
[0061] In one optional embodiment, firstly, based on the type of changed object in the change data, at least one candidate test scenario matching the scenario identifier in a preset test scenario library is retrieved to initially narrow down the test scope related to the changed content; then, combined with the current operating condition in the status data, a target test scenario matching the current real-time operating environment and status of the vehicle is selected from the at least one candidate test scenario, and this target test scenario is used for subsequent digital twin simulation. These steps, through a dual screening mechanism of type matching and operating condition adaptation, achieve accurate positioning of the test scenario, avoiding invalid calculations of irrelevant scenarios and ensuring a high degree of realism in the simulation environment. This reduces computational resource consumption while improving the targeting and accuracy of risk prediction.
[0062] Optionally, the target test scenario, change data, and status data are input into the digital twin model, and the target status data is generated using the digital twin model, including: updating the digital twin model based on the change data to obtain the target digital twin model; determining the component status data of multiple components in the target digital twin model based on the status data, wherein the component status data is used to represent the real-time degradation status of multiple components; and inputting the scenario data, change data, and component status data of the target test scenario into the target digital twin model for simulation to generate the target status data.
[0063] The aforementioned target digital twin model refers to a digital twin entity that reflects the latest hardware and software configuration, version information, and specific operating state of the vehicle after the change data injection and update. The target digital twin model can serve as the core carrier for simulating the impact of changes, ensuring that the digital twin model can realistically reflect the physical or logical state of the system after the changes. This allows subsequent simulation results (target state data) to accurately characterize the vehicle's performance, rather than the old version or an idealized state.
[0064] The target digital twin model can be used to simulate the vehicle's state after system changes in subsequent simulations. Target digital twin models can include, but are not limited to, software-enhanced twin models (models embedding the latest software version code, parameter configurations, or algorithm logic), hardware-replacement twin models (models with parameters updated to the characteristics of newly replaced hardware), configuration-adjustment twin models (models reflecting user-personalized settings or the unlocking status of specific functions), and hybrid update twin models (comprehensive models that include both software and hardware / configuration changes). The above target digital twin models are merely examples; the specific target digital twin model needs to be determined based on the actual system update type and data.
[0065] The aforementioned components can refer to key physical entities or functional modules that constitute the vehicle system, are independently modeled or parameterized in the digital twin model, and whose state changes affect overall performance. These components can serve as granular units for condition monitoring and risk attribution. By decomposing the vehicle into multiple components, the health status of each component (such as aging and wear) can be determined, thereby enabling the identification of specific performance bottlenecks or failure sources when generating target state data, achieving fine-grained risk assessment.
[0066] The aforementioned component status data can refer to a dataset reflecting the real-time degradation level, State of Health (SOH), Remaining Useful Life (RUL), or performance deviation of each component in the digital twin model. Component status data may include, but is not limited to, physical degradation indicators, performance degradation indicators, and fault precursor indicators; the specific component status data needs to be determined based on the actual situation. Component status data can be used as a key factor in ensuring the realism of the simulation. By introducing component status data, simulation results can more accurately predict the risk of performance degradation or failure caused by system changes in older vehicles or under specific vehicle conditions.
[0067] The aforementioned scenario data can refer to a specific set of parameters describing all environmental elements, traffic participant behaviors, road geometry, and dynamic event sequences in the target test scenario. Scenario data may include, but is not limited to, static environmental parameters (e.g., road type, number and width of lanes, slope, etc.), dynamic traffic participant data (e.g., other vehicle driving data, pedestrian movement data, cyclist movement data, etc.), and interaction logic rules (used to characterize the physical interaction rules between traffic participants or between participants and the road). Specific scenario data needs to be determined based on the target test scenario. Scenario data can be used as environmental constraint input for digital twin simulation.
[0068] In one optional embodiment, firstly, the parameters or logic of the digital twin model are updated based on the change data to construct a target digital twin model reflecting the latest system configuration. Next, component state data of multiple components in the target digital twin model is extracted by combining state data. Finally, scenario data, change data, and component state data of the target test scenario are synchronously input into the target digital twin model for high-fidelity simulation, ultimately generating target state data characterizing the expected performance of the system under current operating conditions and aging states. This process, by integrating change content, real-time environment, and component aging states, achieves an accurate mapping of the digital twin model from a static structure to a dynamic real state, improving the fidelity of the simulation results to the actual vehicle operating state, thereby providing data support for subsequent risk prediction and maintenance decisions.
[0069] Optionally, updating the digital twin model based on the changed data to obtain the target digital twin model includes: determining the data type of the changed data; determining the target update method for the digital twin model based on the data type; and updating the digital twin model based on the target update method and the changed data to obtain the target digital twin model.
[0070] The data types mentioned above refer to the nature of the changes represented by the changed data. Data types can include, but are not limited to, software data, hardware data, configuration data, etc., with the specific data type determined based on the changed data. Data types can be used as a classification basis for determining update strategies. By identifying data types, corresponding update algorithms or logic can be matched to ensure that the digital twin model is updated correctly and efficiently, thereby guaranteeing the accuracy and consistency of model updates.
[0071] The aforementioned target update method can refer to a predefined technical path or algorithm strategy for modifying the internal structure, parameters, or behavioral logic of a digital twin model, tailored to the data type. The target update method can specify the concrete modification actions within the digital twin model, ensuring that changed data can be mapped to the model in a standardized manner, maintaining the integrity of the model structure and the correctness of its logic, while simultaneously improving the automation and efficiency of the update process.
[0072] Target update methods can include, but are not limited to, parameter overwrite / replacement updates, module replacement / injection updates, logical branch updates, and connection relationship reconstruction. Parameter overwrite / replacement updates are suitable for changes in hardware parameters or scalar configurations, directly modifying the attribute values of corresponding components in the digital twin model. Module replacement / injection updates are suitable for changes in software functions or hardware entities, replacing existing functional modules or physical entities in the digital twin model with newer versions. Logical branch updates are suitable for changes in configuration switches or conditional judgments, modifying the conditional judgment logic or execution path in the digital twin model. Connection relationship reconstruction is suitable for changes in network topology or system architecture, modifying the data flow connections or control flow connections between modules or components in the digital twin model. The above target update methods are only examples; the specific target update method needs to be determined based on the actual data type.
[0073] In one optional embodiment, firstly, the data type of the changed data is identified to determine the nature of the system change; then, a corresponding target update method is matched based on the data type; subsequently, the target update method and the changed data are used to perform corresponding update operations on the digital twin model, thereby generating a target digital twin model reflecting the latest system state. This process, by establishing a mapping mechanism between data types and update strategies, automates and ensures the accuracy of the model update process, avoiding errors caused by manual intervention. It ensures that the digital twin model can synchronize with the changes made to the actual vehicle in a timely and accurate manner, providing a reliable foundation for subsequent high-fidelity simulations based on the latest model.
[0074] Optionally, risk prediction of the vehicle is performed based on the target state data to obtain a risk prediction result, including: extracting features from the target state data to obtain at least one vehicle performance feature; comparing the at least one vehicle performance feature with a corresponding preset performance benchmark to obtain a performance comparison result, wherein the performance comparison result is used to indicate whether there is an abnormal indicator in the at least one vehicle performance feature; if the performance comparison result indicates that there is an abnormal indicator in the at least one vehicle performance feature, the risk prediction result is determined to be that the vehicle has a preset risk in the future time period.
[0075] At least one vehicle performance characteristic can refer to a key indicator extracted from the target state data that can quantitatively characterize the performance of a vehicle or specific component under simulated conditions. At least one vehicle performance characteristic can serve as the core basis for risk assessment. By transforming complex simulation raw data into concise, quantifiable performance indicators, at least one vehicle performance characteristic enables the system to directly perform standardized comparisons and analyses across multiple performance dimensions, thereby quickly identifying potential performance deviations.
[0076] At least one vehicle performance characteristic may include, but is not limited to, dynamic performance characteristics, thermal management performance characteristics, electrical performance characteristics, and perception and control performance characteristics. Among them, dynamic performance characteristics may include, but are not limited to, maximum acceleration, braking deceleration, peak lateral acceleration, and steering response delay time; thermal management performance characteristics may include, but are not limited to, battery limit temperature, motor winding temperature rise rate, and brake disc limit temperature; electrical performance characteristics may include, but are not limited to, battery discharge capacity, inverter conversion efficiency, voltage fluctuation amplitude, and peak power consumption; perception and control performance characteristics may include, but are not limited to, adaptive cruise control (ACC) following error value, automatic parking assist (APA) parking path deviation, sensor data packet loss rate, and algorithm processing delay. The above vehicle performance characteristics are only examples, and specific vehicle performance characteristics need to be determined based on the target state data.
[0077] The aforementioned preset performance benchmarks can refer to a pre-defined set of reference standards or thresholds used to measure whether vehicle performance is up to standard. Preset performance benchmarks can be used to represent the expected performance range of a vehicle under healthy, ideal, or compliant conditions. Preset performance benchmarks can be used as criteria for determining performance compliance.
[0078] The performance comparison results mentioned above refer to the judgment results generated after logically or numerically comparing the vehicle's performance characteristics with preset performance benchmarks. Performance comparison results may include, but are not limited to, the presence or absence of abnormal indicators; the specific performance comparison results need to be determined based on the actual comparison situation. Performance comparison results can be used to determine whether further risk assessment of the vehicle is necessary.
[0079] The aforementioned anomaly indicators can refer to specific vehicle performance characteristics identified in performance comparison results as not meeting preset performance benchmarks. Anomaly indicators can serve as specific indicators for risk attribution. After identifying a preset risk, anomaly indicators can help maintenance personnel or the system quickly pinpoint which specific component or function is malfunctioning (e.g., battery overheating causing performance degradation, or sensor delay causing control failure), thereby guiding subsequent maintenance actions.
[0080] In one optional embodiment, feature extraction is first performed on the target state data to obtain at least one vehicle performance feature describing vehicle performance. Then, this at least one vehicle performance feature is compared with a corresponding preset performance benchmark to generate a performance comparison result. Finally, the risk prediction result is determined based on whether any abnormal indicators exist in the performance comparison result. This process, through quantitative analysis of the differences between simulation data and standard benchmarks, can accurately identify potential performance deviations, achieving automated judgment from data to risk, thereby providing early warning of impending faults or performance failures and offering timely and accurate decision-making basis for preventative maintenance.
[0081] In one optional embodiment, at least one vehicle performance feature is first extracted from the target state data. Then, a pre-trained machine learning classification model (such as a random forest or support vector machine) is used to comprehensively evaluate the at least one vehicle performance feature, calculating the confidence score for each performance feature's deviation from normal operating conditions. Subsequently, the confidence scores are compared with dynamically adjusted risk thresholds. When the confidence score of any vehicle performance feature exceeds the corresponding risk threshold, the vehicle performance feature is determined to be an anomalous indicator, and the risk prediction result is determined to be that the vehicle has a preset risk in the future time period. When the confidence scores of all vehicle performance features do not exceed the corresponding risk thresholds, the performance comparison result is determined to be that at least one vehicle performance feature does not have an anomalous indicator, and the risk prediction result is determined to be that the vehicle does not have a preset risk in the future time period. This process, through a machine learning model, can adaptively capture nonlinear, high-dimensional, complex performance decay patterns, effectively reducing the false positive and false negative rates caused by environmental interference or individual differences, thereby improving the robustness and accuracy of risk prediction.
[0082] Optionally, at least one vehicle performance feature is compared with a corresponding preset performance benchmark to obtain a performance comparison result, including: if at least one vehicle performance feature meets the corresponding preset performance benchmark, the performance comparison result is determined to be that there is no abnormal indicator in at least one vehicle performance feature; if any one of the at least one vehicle performance features does not meet the corresponding preset performance benchmark, the performance comparison result is determined to be that there is an abnormal indicator in at least one vehicle performance feature.
[0083] In one optional embodiment, by verifying one by one whether at least one vehicle performance feature meets its corresponding preset performance benchmark, if all vehicle performance features meet their corresponding preset performance benchmarks, it is determined that there are no abnormal indicators; if any vehicle performance feature does not meet its corresponding preset performance benchmark, it is determined that there are abnormal indicators. This process, by establishing clear logic for full pass and single-point rejection, automates and standardizes the generation of performance comparison results, ensuring the accuracy and consistency of abnormal indicator identification and providing a clear and reliable basis for subsequent risk prediction.
[0084] Optionally, the method further includes: when the risk prediction result indicates that the vehicle has a preset risk in the future time period, determining the target component status data and historical status data of the target component corresponding to the abnormal indicator; performing risk prediction based on the target component status data and historical status data to generate the risk occurrence time; determining the risk response strategy based on the risk occurrence time; and outputting the risk response strategy.
[0085] The aforementioned target component can refer to a specific physical vehicle entity or functional module whose corresponding vehicle performance characteristics are identified as "abnormal indicators" in the risk prediction results. The target component can be used as a location point for risk attribution and handling. By identifying a specific target component, performance anomalies can be transformed into specific hardware or software objects, thereby guiding subsequent data retrieval, cause analysis, and the issuance of maintenance instructions.
[0086] The aforementioned target component status data can refer to the target component's operating parameters, environmental condition data, and system logs when abnormal indicators are detected. This target component status data can serve as the current baseline for risk analysis. Combining target component status data with historical data can be used to assess the target component's current health status, aging trends, and the specific operating conditions leading to abnormalities, providing fundamental input for determining the urgency of risks and the timing of their occurrence.
[0087] The aforementioned historical status data refers to the accumulated operational data sequence of the target component over a past period. Historical status data may include, but is not limited to, the target component's time-series performance curves, past fault records, maintenance history, and long-term aging trend data. Specific historical status data needs to be determined based on the actual target component. Historical status data can be used as a basis for trend analysis and lifespan prediction of the target component. By comparing the current state of the target component with its historical state, the system can identify the gradual process of performance changes (such as the slow decay of battery capacity over time), thereby more accurately predicting the remaining useful life (RUL) and the specific time point when risks occur, avoiding misjudgments based solely on instantaneous data.
[0088] The aforementioned risk occurrence time can refer to the specific point in time or time period estimated based on the analysis and prediction of the target component's current and historical status data, indicating that the target component's performance has fallen below the safety threshold or its failure probability has exceeded the allowable limit. The risk occurrence time can serve as a decision-making window for developing maintenance plans. It can also clarify the urgency of risk resolution, distinguish different levels of risk, thereby improving resource allocation and avoiding over-maintenance or delayed maintenance.
[0089] The aforementioned risk response strategies can refer to a set of specific action suggestions or instructions generated in response to predicted risks and their expected occurrence time, used to eliminate, mitigate, or avoid such risks. Risk response strategies may include, but are not limited to, user alert strategies, such as pushing warning messages to the vehicle's infotainment screen or mobile app to advise users to pay attention to their driving behavior or schedule a check-up; remote software repair strategies, such as pushing OTA upgrade packages to adjust control algorithms, parameter thresholds, or restrict the use of defective functional modules; preventative maintenance strategies, such as recommending the replacement of target components, performing system calibration, or cleaning sensors; emergency avoidance strategies, such as limiting vehicle speed, restricting the use of high-risk functions (such as automatic parking), or forcing the vehicle into a safe mode; and spare parts scheduling strategies, such as notifying the service center in advance to prepare necessary spare parts and arrange repair bays. The above risk response strategies are merely examples; specific risk response strategies need to be determined based on actual circumstances. Risk response strategies can be implemented according to the time of risk occurrence and the urgency of the risk, guiding users, vehicle owners, or maintenance personnel to take correct actions to ensure that risks are effectively controlled before they occur, thus protecting vehicle safety and performance.
[0090] In one optional embodiment, when the risk prediction result indicates that a preset risk exists in the vehicle within a future time period, the target component status data and historical status data of the target component corresponding to the abnormal indicator are retrieved. Then, based on the target component status data and historical status data, a time series analysis or degradation model is constructed to predict the specific time point of risk occurrence, i.e., the risk occurrence time. Appropriate risk response strategies, such as preventative maintenance, remote software upgrades, or emergency avoidance, are matched according to the urgency of the risk occurrence time. Finally, the risk response strategies are output to the user end or the maintenance end. This process, by combining real-time status and long-term evolution trends, achieves refined prediction of the risk occurrence time, ensuring that the formulation of response strategies has sufficient time window and is targeted, effectively avoiding resource waste caused by over-maintenance or safety accidents caused by maintenance delays, and improving the intelligence level and maintenance efficiency of vehicle lifecycle management.
[0091] In one optional embodiment, when the risk prediction result indicates that a preset risk exists in the vehicle within a future time period, the system first locates the abnormal indicator that triggers the risk and extracts the target component's state data and its historical state data to construct a degradation curve. Subsequently, based on this degradation curve, the system predicts the specific time point at which the target component's performance degrades to a preset threshold, thereby generating an accurate risk occurrence time. Next, based on the risk occurrence time and the current vehicle operating status (such as mileage, remaining battery power, or geographical location), the system dynamically evaluates and generates differentiated risk response strategies, including maintenance time window recommendations, spare parts pre-installation, or remote software frequency reduction. Finally, the risk response strategies are pushed to the user terminal or maintenance service center for execution. This process, by refining the prediction from "risk existence" to "risk occurrence time" and combining it with real-time operational scenarios to generate dynamic response strategies, achieves a shift from passive early warning to proactive intervention. This not only significantly reduces the safety risks and maintenance costs caused by sudden failures but also improves vehicle availability and extends the service life of critical components by adjusting maintenance timing.
[0092] In one alternative embodiment, Figure 2 This is a schematic diagram of a vehicle risk prediction system according to an embodiment of this application, such as... Figure 2 As shown, the system mainly comprises a real vehicle data acquisition layer, a digital twin modeling and simulation layer, a data analysis and decision-making layer, and an execution and interaction layer. The real vehicle data acquisition layer includes onboard sensors and a user interface; the digital twin modeling and simulation layer includes a high-fidelity 3D model, multiphysics simulation, a multiphysics simulation engine, a behavioral model library, and synchronous acquisition of real vehicle status; the data analysis and decision-making layer includes a full lifecycle data lake, an automated testing engine, a predictive maintenance analysis module, and a personalized configuration verification module; the execution and interaction layer includes a vehicle control interface, a user terminal / maintenance center platform, command transmission, and interactive feedback. Data collected by the real vehicle data acquisition layer is sequentially transmitted to the digital twin modeling and simulation layer and the data analysis and decision-making layer for processing, and finally executed by the execution and interaction layer, which can receive data from the real vehicle data acquisition layer.
[0093] This risk prediction system operates through a four-layer architecture. The real-vehicle data acquisition layer utilizes onboard sensors and user interfaces to acquire real-time vehicle operating status and user commands. The collected data is then sequentially transmitted to the digital twin modeling and simulation layer. This layer uses a high-fidelity 3D model, a multi-physics simulation engine, and a behavioral model library to synchronously map the real-vehicle state, constructing a virtual mapping. The data then enters the data analysis and decision-making layer, where it undergoes in-depth processing and decision generation using a full lifecycle data lake, an automated testing engine, a predictive maintenance analysis module, and a personalized configuration verification module. Finally, the execution and interaction layer executes commands and provides interactive feedback through the vehicle control interface, user terminal, or maintenance center platform. This execution and interaction layer can directly receive data from the real-vehicle data acquisition layer, forming a closed loop. This system architecture achieves complete closed-loop control from physical world perception to virtual world simulation decision-making and then to physical world execution. It not only ensures the real-time performance and accuracy of data processing but also improves the system's response speed to complex operating conditions and the reliability of maintenance decisions through bidirectional data interaction, effectively guaranteeing the safe and efficient operation of the vehicle throughout its entire lifecycle.
[0094] In one optional embodiment, a vehicle risk prediction system consists of six core components: a high-fidelity digital twin modeling module, a full lifecycle data lake, an automated testing engine, a predictive maintenance analysis module, a personalized configuration verification module, and a decision support and execution interface. Together, they construct a closed-loop vehicle lifecycle management ecosystem.
[0095] Among them, the high-fidelity digital twin modeling module utilizes a multi-physics simulation engine to integrate multi-source data such as the vehicle controller area network (CAN) bus, global positioning system (GPS) and cameras to build a comprehensive virtual model covering vehicle dynamics, electrical system and software behavior in real time.
[0096] The full lifecycle data lake adopts a hybrid storage architecture of time-series database and graph database. It uses VIN code as a unique identifier to centrally associate and store software versions, hardware batches, maintenance records and test data throughout the entire process from production to disposal, providing a solid data foundation for upper-layer applications.
[0097] Building on this, the automated testing engine supports scripted test cases, enabling it to simulate complex road, climate, and traffic flow scenarios in a digital twin environment and automatically perform functional, performance, and safety tests. For example, it can automatically inject a noise model to verify the robustness of the ACC system in response to the increasing trend of radar noise.
[0098] The predictive maintenance analysis module combines Long Short-Term Memory (LSTM) networks with attention mechanisms to perform degradation modeling and remaining life prediction for key components such as batteries and brake pads, and generates maintenance recommendations when performance approaches the safety threshold.
[0099] The personalized configuration verification module allows users to "test drive" the paid unlock function in a virtual environment, verifying its compatibility and security with the current hardware status and outputting a risk assessment report. Finally, the decision support and execution interface sends maintenance instructions or appointment information to vehicles or service centers through the vehicle network and feeds the execution results back to the data lake, forming a complete closed loop of "data collection - twin simulation - decision generation - execution feedback".
[0100] The above process enables the traceability and analyzability of vehicle lifecycle data, provides early warning of the impact of hardware aging on software functions through predictive maintenance, reduces the cost of real vehicle testing and site dependence, provides a low-cost and high-security verification environment for user personalized configuration, and continuously improves model accuracy and system adaptability through a continuous learning mechanism.
[0101] In one optional embodiment, the risk prediction process of a vehicle risk prediction system based on digital twins is as follows: When a system change occurs in the vehicle, such as an OTA software upgrade, hardware module replacement, or unlocking of user-personalized configurations (e.g., paid unlocking of high-performance mode), the system triggers the risk prediction process. At this time, the controller acquires the vehicle's current status data, including real-time sensor readings, CAN bus data, driving behavior logs, and vehicle health status; simultaneously, it acquires change data, clearly recording the type of change, the version of the change, the time of the change, and the scope of the change's impact.
[0102] Next, based on the type of changed object in the change data, at least one candidate test scenario is determined from multiple preset test scenarios. For example, if the changed object is "autonomous driving algorithm," candidate test scenarios related to autonomous driving are selected; if the changed object is "battery strategy," candidate scenarios related to batteries, such as fast charging and low-temperature discharge, are selected. Then, based on the current operating condition in the state data, the target test scenario that best matches the current operating condition is determined from the aforementioned candidate test scenarios. For example, if the current operating condition is "winter low temperature and charging," the specific target test scenario "low-temperature fast charging degradation" is determined from the battery-related candidate scenarios.
[0103] Then, the target test scenario, changed data, and status data are input into the digital twin model for processing. In this process, the data type of the changed data is first determined; and based on the data type, the target update method for the digital twin model is determined. Then, based on this target update method and the changed data, the original digital twin model is updated to obtain a target digital twin model reflecting the latest vehicle status. Next, based on the status data, the component status data of multiple components (such as battery cells, motor windings, brake pads, etc.) in the target digital twin model are determined. This data uses historical degradation curves and real-time sensor data to represent the real-time degradation status of multiple components (such as remaining health at sea level, temperature distribution, vibration spectrum). Then, the scenario data of the target test scenario (such as virtual road geometry, traffic flow, and weather conditions), changed data, and component status data are input into the updated target digital twin model for high-fidelity simulation. After time-accelerated or event-driven simulation calculations, target status data is generated.
[0104] Furthermore, feature extraction is performed on the generated target state data to obtain at least one vehicle performance feature. This feature is then compared with its corresponding preset performance benchmark to obtain the performance comparison results. The preset performance benchmark is a threshold range pre-set according to vehicle design specifications and safety standards (e.g., braking distance deviation must not exceed 2 meters).
[0105] If at least one vehicle performance feature meets its corresponding preset performance benchmark, the performance comparison result is determined to be free of abnormal indicators. If any one of the at least one vehicle performance feature does not meet its corresponding preset performance benchmark (e.g., a feature value exceeds the upper or lower threshold), the performance comparison result is determined to contain abnormal indicators. Based on this, if abnormal indicators are found, the system determines the risk prediction result to be that the vehicle faces a preset risk in the future.
[0106] The above process ensures the relevance and realism of the digital twin simulation scenario by dynamically determining the target test scenario by combining the type of the changed object with the current working conditions; it achieves real-time synchronization between the model and the real vehicle status by updating the digital twin model based on data type differences; and it achieves rapid and accurate risk warning by comparing performance characteristics with preset benchmarks, thereby effectively reducing the risk of sudden failures and improving the safety and maintenance efficiency of the vehicle throughout its entire life cycle.
[0107] Figure 3 This is a flowchart of an automated testing method according to an embodiment of this application, such as... Figure 3As shown, this method begins by monitoring system change events; then, it matches corresponding test scenarios from the test case library; subsequently, it injects the test scenarios into the digital twin environment; the test results are stored in the data lake and a maintenance decision process is triggered; a test report is generated; and finally, the test is executed and performance metrics are collected.
[0108] Specifically, the above automated testing method first monitors the system in real time to capture any changes to the vehicle's software, hardware, or configuration. Once a change is detected, it retrieves and matches specific test scenarios related to that change from the test case library. Subsequently, the matched scenarios are injected into a digital twin environment for high-fidelity simulation. During the simulation, specific test procedures are executed and key performance indicator data is collected in real time. After the test, the system automatically generates a detailed test report containing performance analysis and rationality assessment. The report and original test data are persistently stored in a full lifecycle data lake to ensure the integrity of the evidence chain. Based on the test results, subsequent maintenance decision-making processes are triggered, thus forming an automated closed loop from change monitoring to decision triggering. This achieves unmanned and standardized testing processes, not only reducing testing costs but also ensuring the comprehensiveness and traceability of testing after each change, improving the security and maintenance efficiency of vehicle system updates.
[0109] Figure 4 This is a schematic diagram of a predictive maintenance analysis module according to an embodiment of this application, as shown below. Figure 4 As shown, this module first aggregates multi-source information such as historical maintenance records, real-time sensor data, component characteristic parameters, and environmental data, inputting it into the processing core. Through a degradation curve synthesis unit integrating predictive models, it models and predicts the performance of key vehicle components. Then, a risk matrix assessment unit performs in-depth analysis of the prediction results, specifically assessing the potential impact of camera performance degradation on lane-keeping assist, the remaining lifespan of each component, and the cascading effects of hardware performance degradation on software functions. Based on this, personalized maintenance recommendations are generated. This process, by integrating multi-dimensional data and multi-dimensional risk assessment models, achieves a leap from single-component status monitoring to system-level coupled risk prediction. It can identify the risk of software function anomalies caused by hardware aging in advance, thereby formulating scientific and proactive maintenance strategies, effectively reducing the rate of sudden failures, and improving the safety and reliability of the vehicle throughout its entire lifecycle.
[0110] Figure 5 This is a flowchart of a personalized configuration verification method according to an embodiment of this application, such as... Figure 5As shown above, the verification process involves checking the vehicle's current hardware status and software version when a user initiates a function unlock request (such as "track mode"); then loading the corresponding function package in the digital twin and simulating typical usage scenarios; performing compatibility tests, stress tests, and security boundary tests; outputting a test report (verification successful / verification failed) after the test is completed; and finally recording the test results in the user database.
[0111] The above verification methods, by verifying the compatibility and security of personalized functions with specific vehicle hardware status in advance in a virtual environment, effectively avoid the failure of real vehicle functions or security risks caused by hardware aging or configuration conflicts. This provides users with a low-cost, zero-risk functional experience window, while ensuring the reliability and security of paid unlocking functions when executed in real vehicles.
[0112] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.
[0113] According to an embodiment of this application, a vehicle risk prediction device is provided. It should be noted that the device can be used to perform the above-described vehicle risk prediction method.
[0114] Figure 6 This is a schematic diagram of a vehicle risk prediction device according to an embodiment of this application, such as... Figure 6 As shown, the device includes: an acquisition module 602, a generation module 604, and a prediction module 606.
[0115] The acquisition module 602 is used to acquire the vehicle's status data and the corresponding system change data when a system change occurs in the vehicle; the generation module 604 is used to generate target status data based on the change data, status data, and the vehicle's digital twin model, wherein the target status data represents the vehicle's status data after the system change, and the digital twin model is used to simulate the vehicle's operating status and the performance degradation process of the vehicle's components; the prediction module 606 is used to perform risk prediction on the vehicle based on the target status data and obtain a risk prediction result, wherein the risk prediction result indicates whether the vehicle has a preset risk in the future time period.
[0116] Optionally, the generation module is used to determine the target test scenario from multiple preset test scenarios based on change data and status data; input the target test scenario, change data, and status data into the digital twin model, and use the digital twin model to generate target status data.
[0117] Optionally, the generation module is also used to determine at least one candidate test scenario from multiple preset test scenarios based on the change object type in the change data, wherein the scenario identifier of at least one candidate test scenario matches the change object type; and to determine the target test scenario corresponding to the current working condition from at least one candidate test scenario based on the current working condition in the status data.
[0118] Optionally, the generation module is also used to update the digital twin model based on the change data to obtain the target digital twin model; based on the state data, determine the component state data of multiple components in the target digital twin model, wherein the component state data is used to represent the real-time degradation state of multiple components; input the scene data, change data and component state data of the target test scenario into the target digital twin model for simulation to generate target state data.
[0119] Optionally, the generation module is also used to determine the data type of the changed data; determine the target update method for the digital twin model based on the data type; and update the digital twin model based on the target update method and the changed data to obtain the target digital twin model.
[0120] Optionally, the prediction module is used to extract features from the target state data to obtain at least one vehicle performance feature; compare the at least one vehicle performance feature with the corresponding preset performance benchmark to obtain a performance comparison result, wherein the performance comparison result is used to indicate whether there is an abnormal indicator in the at least one vehicle performance feature; if the performance comparison result indicates that there is an abnormal indicator in the at least one vehicle performance feature, the risk prediction result is determined to be that the vehicle has a preset risk in the future time period.
[0121] Optionally, the prediction module is further configured to determine that there are no abnormal indicators in at least one vehicle performance feature when at least one vehicle performance feature meets the corresponding preset performance benchmark; and to determine that there are abnormal indicators in at least one vehicle performance feature when any one of the at least one vehicle performance features does not meet the corresponding preset performance benchmark.
[0122] Optionally, the device is also used to determine the target component status data and historical status data of the target component corresponding to the abnormal indicator when the risk prediction result indicates that the vehicle has a preset risk in the future time period; to perform risk prediction based on the target component status data and historical status data, and generate the risk occurrence time; to determine the risk response strategy based on the risk occurrence time; and to output the risk response strategy.
[0123] Embodiments of this application also provide a vehicle, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods described in various embodiments of this application when it runs.
[0124] Embodiments of this application also provide a computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.
[0125] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.
[0126] Embodiments of this application also provide a computer program product, including a non-volatile computer-readable storage medium for storing a computer program that, when executed by a processor, implements the methods in various embodiments of this application.
[0127] Embodiments of this application also provide a computer program that, when executed by a processor, implements the methods described in the various embodiments of this application.
[0128] 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.
[0129] 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 instance, 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 coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.
[0130] 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.
[0131] 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.
[0132] 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 described in 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 (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.
[0133] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.
Claims
1. A method for predicting the risk of a vehicle, characterized in that, include: In the event of a system change in a vehicle, acquire the vehicle's status data and the corresponding system change data; Based on the change data, the status data, and the digital twin model of the vehicle, target status data is generated, wherein the target status data is used to represent the status data of the vehicle after the system change, and the digital twin model is used to simulate the operating status of the vehicle and the performance degradation process of the components in the vehicle. Based on the target state data, the vehicle is risk-predicted to obtain a risk prediction result, wherein the risk prediction result is used to indicate whether the vehicle has a preset risk in the future time period.
2. The method according to claim 1, characterized in that, Based on the change data, the status data, and the digital twin model of the vehicle, target status data is generated, including: Based on the change data and the status data, a target test scenario is determined from multiple preset test scenarios; The target test scenario, the change data, and the status data are input into the digital twin model, and the target status data is generated using the digital twin model.
3. The method according to claim 2, characterized in that, Based on the change data and the status data, a target test scenario is determined from multiple preset test scenarios, including: Based on the change object type in the change data, at least one candidate test scenario is determined from the plurality of preset test scenarios, wherein the scenario identifier of the at least one candidate test scenario matches the change object type; Based on the current operating condition in the state data, the target test scenario corresponding to the current operating condition is determined from the at least one candidate test scenario.
4. The method according to claim 2, characterized in that, The target test scenario, the change data, and the status data are input into the digital twin model, and the target status data is generated using the digital twin model, including: The digital twin model is updated based on the changed data to obtain the target digital twin model; Based on the state data, component state data of multiple components in the target digital twin model are determined, wherein the component state data is used to represent the real-time degradation state of the multiple components; The scenario data of the target test scenario, the change data, and the component status data are input into the target digital twin model for simulation to generate the target status data.
5. The method according to claim 4, characterized in that, The digital twin model is updated based on the changed data to obtain a target digital twin model, including: Determine the data type of the changed data; The target update method for the digital twin model is determined based on the data type of the changed data; The digital twin model is updated based on the target update method and the changed data to obtain the target digital twin model.
6. The method according to claim 1, characterized in that, Based on the target state data, a risk prediction is performed on the vehicle to obtain a risk prediction result, including: Feature extraction is performed on the target state data to obtain at least one vehicle performance feature; The at least one vehicle performance feature is compared with the corresponding preset performance benchmark to obtain a performance comparison result, wherein the performance comparison result is used to indicate whether there are any abnormal indicators in the at least one vehicle performance feature; If the performance comparison result indicates that the abnormal indicator exists in at least one of the vehicle performance characteristics, the risk prediction result is determined to be that the vehicle has the preset risk in the future time period.
7. The method according to claim 6, characterized in that, The at least one vehicle performance characteristic is compared with a corresponding preset performance benchmark to obtain performance comparison results, including: If at least one vehicle performance feature satisfies the corresponding preset performance benchmark, the performance comparison result is determined to be that there is no abnormal indicator in the at least one vehicle performance feature. If any one of the at least one vehicle performance features does not meet the corresponding preset performance benchmark, the performance comparison result is determined to be that the at least one vehicle performance feature contains the abnormal index.
8. The method according to any one of claims 1 to 6, characterized in that, The method further includes: If the risk prediction result indicates that the vehicle will experience the preset risk in the future time period, determine the target component status data and historical status data of the target component corresponding to the abnormal indicator. Based on the target component status data and the historical status data, risk prediction is performed to generate the risk occurrence time. Determine risk response strategies based on the timing of the risk occurrence; Output the aforementioned risk response strategy.
9. A vehicle, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 8.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the storage medium is located to perform the method according to any one of claims 1 to 8.