Intelligent driving multi-level simulation test method and system

Abstract

This invention relates to a multi-level simulation testing method and system for intelligent driving. The method includes: hierarchically labeling different test scenarios based on a six-dimensional complexity evaluation model to obtain expected functional safety scenario events and functional safety failure events; generating precise timestamps corresponding to the expected functional safety scenario events and functional safety failure events; synchronously triggering the expected functional safety scenario events and functional safety failure events based on the precise timestamps to simulate corresponding risk scenarios; selecting the verification level of the risk scenario based on the type of functional safety failure event and executing the corresponding simulation instance to obtain test data; and conducting risk assessment based on the test data using a risk assessment model. This application achieves joint injection of scenarios and failures, continuous accumulation of multi-level verification data, and composite risk quantification assessment, improving the comprehensiveness and efficiency of safety verification for intelligent driving systems.

Description

Technical Field

[0001] This invention relates to the field of intelligent driving testing and verification technology, and in particular to a multi-level simulation testing method and system for intelligent driving. Background Technology

[0002] Safety verification of intelligent driving systems is a key challenge for the industry. Currently, functional safety (ISO 26262) and expected functional safety (ISO 21448 / SOTIF) are usually verified separately, resulting in low verification efficiency and an inability to cover complex risk scenarios.

[0003] Traditional verification methods suffer from the following drawbacks: First, functional safety verification focuses on known failure modes, while expected functional safety verification focuses on performance limitations. The two types of verification data are not interoperable, making it impossible to identify interactive risks. Second, existing simulation platforms lack precise time synchronization mechanisms, making it difficult to simulate complex risk scenarios where multiple events occur simultaneously. Third, test scenarios lack systematic complexity assessment standards, leading to uneven resource allocation and insufficient verification of important scenarios. Finally, data is fragmented between verification levels (Model-in-the-Loop (MiL), Software-in-the-Loop (SiL), Hardware-in-the-Loop (HiL), and Vehicle-in-the-Loop (ViL), making it impossible to achieve continuous accumulation of verification results.

[0004] Although both ISO 26262 (2018) and ISO 21448 (2021) are automotive safety standards, they were developed by different working groups and their technical approaches are completely separate: ISO 26262 is based on Fault Tree Analysis (FTA) and Failure Mode and Effects Analysis (FMEA), focusing on known faults; ISO 21448 is based on scenario coverage analysis, focusing on performance limitations. In industry practice, the verification toolchains are also completely separate. For example, dSPACE is used for functional safety verification, while CARLA is used for expected functional safety verification. Their data formats are incompatible, and verification results cannot be automatically integrated. This technological fragmentation makes it impossible to identify complex risk scenarios, becoming a long-standing unresolved technical problem in the industry.

[0005] In existing technologies, the Baidu Apollo open-source project provides a scenario library based on real-world data, but does not consider the joint verification of functional safety faults and expected functional safety scenarios; the CARLA + Open SCENARIO solution supports the standardization of scenario descriptions, but lacks complex quantification assessment and risk priority scheduling; the four-level verification process MiL-SiL-HiL-ViL recommended by ISO 26262 Part 6 does not solve the problem of consistency of verification conditions between different levels. Summary of the Invention

[0006] Therefore, the purpose of this invention is to provide a multi-level simulation testing method and system for intelligent driving to address the shortcomings of existing technologies.

[0007] To achieve the above objectives, the present invention provides a multi-level simulation testing method for intelligent driving, the method comprising: Based on a six-dimensional complexity evaluation model, different test scenarios are graded and labeled to obtain expected functional safety scenario events and functional safety failure events. The programmable logic device generates precise timestamps corresponding to the expected functional safety scenario events and the functional safety failure events, and synchronously triggers the expected functional safety scenario events and functional safety failure events based on the precise timestamps to simulate the corresponding risk scenarios. Based on the type of the functional safety failure event, the verification level of the risk scenario is selected, and the simulation instance corresponding to the verification level is executed to obtain test data. Based on the test data, a risk assessment is performed through a risk assessment model, and a unified verification report is generated.

[0008] The beneficial effects of this invention are as follows: Different test scenarios are hierarchically labeled using a six-dimensional complexity evaluation model to obtain expected functional safety scenario events and functional safety fault events. Then, precise timestamps corresponding to the expected functional safety scenario events and functional safety fault events are generated using programmable logic devices. Based on these precise timestamps, the expected functional safety scenario events and functional safety fault events are synchronously triggered to simulate corresponding risk scenarios. Furthermore, based on the type of functional safety fault event, the verification level of the risk scenario is selected, and the simulation instance corresponding to that verification level is executed to obtain test data. Based on the test data, a risk assessment model is used to conduct a risk assessment and generate a unified verification report. Unlike existing technologies, this invention achieves joint injection of scenarios and faults, continuous accumulation of multi-level verification data, and composite risk quantification assessment, thereby improving the comprehensiveness and efficiency of safety verification for intelligent driving systems.

[0009] Furthermore, the step of synchronously triggering expected functional safety scenario events and functional safety failure events based on the precise timestamp to simulate the corresponding risk scenarios includes: When the difference between the occurrence time of the expected functional safety scenario event and the occurrence time of the functional safety failure event does not exceed a preset event threshold, it is defined as a composite risk scenario, and the verification level of the composite risk scenario is selected as hardware-in-the-loop verification or vehicle-in-the-loop verification based on the type of the functional safety failure event. When the difference between the occurrence time of the expected functional safety scenario event and the occurrence time of the functional safety failure event exceeds the preset event threshold, it is defined as a normal risk scenario, and the verification level of the normal risk scenario is selected as model-in-the-loop verification or software-in-the-loop verification based on the type of the functional safety failure event.

[0010] Furthermore, the topology of the risk assessment model includes a bottom-level evidence node layer, an intermediate latent variable layer, and a top-level output node layer. The steps of conducting risk assessment based on the test data using the risk assessment model and generating a unified verification report include: The test data is divided into functional safety indicators and expected functional safety indicators. The functional safety indicators and expected functional safety indicators are respectively input into discrete nodes and continuous nodes in the underlying evidence node layer. The functional safety indicators and expected functional safety indicators are then fused through a probability transformation interface to obtain fused data. Based on the fused data, risk aggregation is performed through the risk propagation path in the intermediate hidden variable layer to obtain risk aggregated data; Based on the aggregated risk data, risk assessment results are generated through the top-level output node layer. The risk assessment results include acceptable risks, risks requiring review, and unacceptable risks, and a unified verification report that meets the requirements of ISO 26262 and ISO 21448 standards is generated.

[0011] Furthermore, the method also includes: An initial risk assessment model is constructed based on a three-layer Bayesian network. The ASIL level elements of ISO 26262 and the SOTIF hazard index of ISO 21448 are used as two input data. The two input data are fused using a Gaussian mixture model, and the initial risk assessment model is trained based on the fusion result to obtain the risk assessment model.

[0012] Furthermore, the risk assessment model is used to evaluate multiple dimensions of indicators, including severity, exposure probability, controllability, SOTIF uncertainty, and system robustness. The expression of the risk assessment model is shown below:

[0013]

[0014]

[0015] in, and All represent the final output value of the risk assessment model. This represents the risk amplification factor. This represents the time difference between the expected functional safety scenario event and the functional safety failure event. Indicates severity, Indicates the probability of exposure. Indicates controllability, This indicates SOTIF uncertainty. Indicates system robustness. These represent the weights for severity, exposure probability, controllability, SOTIF uncertainty, and system robustness, respectively.

[0016] Furthermore, the six-dimensional space of the six-dimensional complexity evaluation model mainly includes the road layer, traffic facility layer, temporary traffic event layer, traffic participant layer, environmental condition layer, and information layer. Each layer has five levels defined according to custom rules. The steps for hierarchical labeling of different test scenarios based on the six-dimensional complexity evaluation model include: Based on a predefined quantization threshold, different test scenarios are automatically classified to generate variant scenarios to cover the main areas of the six-dimensional complexity space. The variant scenarios include hot scenarios and cold data. The hot scenarios are stored in memory or SSD through a tiered storage architecture, while the cold data is stored in a large-capacity disk array. The hot scenarios are test scenarios whose access frequency exceeds a preset threshold, and the cold data are test scenarios whose access frequency does not exceed the preset threshold. The incremental changes of the scene parameters in the test scenario are compressed and stored using Delta encoding technology. Combined with the R* tree spatial index structure, the scene parameters are hierarchically organized, and test resources are dynamically classified through an adaptive priority scheduling mechanism.

[0017] Furthermore, the verification levels include model-in-the-loop verification, software-in-the-loop verification, hardware-in-the-loop verification, and vehicle-in-the-loop verification; The model-in-the-loop verification is performed in MATLAB or Simulink tools using pure software simulation of the algorithm model, without relying on code or hardware, to verify whether the logic of the early verification algorithm is correct. The software-in-the-loop verification involves running the C or C++ code generated by the algorithm on a PC or virtual machine, interacting with the simulation environment, and verifying whether the code behavior is consistent with the model, thereby verifying whether the code implementation is consistent with the model. The hardware-in-the-loop verification involves connecting a real ECU controller to a real-time simulation platform, using simulated sensors or vehicle dynamic signals to drive the ECU, and testing its real response to verify the functional safety performance of the ECU in a near-real electrical, communication, or timing environment. The vehicle-in-the-loop verification involves placing a real vehicle (or test bench) in a controlled environment and fusing virtual traffic participants with real sensors to achieve a "semi-real vehicle" closed-loop test, thereby verifying the system's comprehensive performance under real sensors, actuators, and environmental interference.

[0018] Furthermore, the method also includes: When simulating the composite risk scenario, the scenario injection interface corresponding to the expected functional safety scenario event and the fault injection interface corresponding to the functional safety failure event are driven in the same hardware.

[0019] Furthermore, the method also includes: When the deviation between the test data and the historical real vehicle data exceeds a preset verification threshold, the current verification level test is terminated, and the lower-level time event sequence is loaded synchronously to start the higher-level simulation instance for corresponding simulation testing.

[0020] To achieve the above objectives, the present invention also provides a multi-level simulation test system for intelligent driving, the system comprising: The acquisition module is used to hierarchically label different test scenarios based on a six-dimensional complexity evaluation model in order to obtain expected functional safety scenario events and functional safety failure events. The triggering module is used to generate precise timestamps corresponding to the expected functional safety scenario event and the functional safety failure event through a programmable logic device, and to synchronously trigger the expected functional safety scenario event and the functional safety failure event based on the precise timestamps to simulate the corresponding risk scenarios. The simulation and generation module is used to select the verification level of the risk scenario based on the type of the functional safety failure event, execute the simulation instance corresponding to the verification level, obtain test data, perform risk assessment through the risk assessment model based on the test data, and generate a unified verification report. Attached Figure Description

[0021] Figure 1 This is a flowchart of a multi-level simulation test method for intelligent driving according to an embodiment of the present invention; Figure 2 This is a structural diagram of a risk assessment model according to an embodiment of the present invention; Figure 3 This is a structural block diagram of an intelligent driving multi-level simulation test system according to an embodiment of the present invention.

[0022] The following detailed description, in conjunction with the accompanying drawings, will further illustrate the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0024] Obviously, the accompanying drawings described below are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar scenarios based on these drawings without any inventive effort. Furthermore, it is understood that although the efforts made in this development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, any changes to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.

[0025] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0026] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “a,” “an,” “an,” “the,” and similar words used in this application do not indicate quantity limitation and may indicate singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units not listed, or may include other steps or units inherent to these processes, methods, products, or devices. The terms “connected,” “linked,” “coupled,” and similar words used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following objects are in an "or" relationship. The terms "first," "second," and "third" used in this application are merely to distinguish similar objects and do not represent a specific ordering of the objects.

[0027] Example 1 Please see Figure 1 Here is a flowchart of the intelligent driving multi-level simulation test method in the first embodiment of the present invention, the method comprising the following steps: Step S101: Based on the six-dimensional complexity evaluation model, different test scenarios are graded and labeled to obtain expected functional safety scenario events and functional safety failure events; Each of the expected functional safety scenario events corresponds to a structured test scenario that meets the coverage requirements of the ISO 21448 standard, and each test scenario is described using the Open SCENARIO 1.0 or a later version standard.

[0028] Based on historical intelligent vehicle faults, functional safety fault events are obtained. The types of functional safety fault events include hardware fault modes and software fault modes. The fault types in the hardware fault modes and the software fault modes are respectively matched with corresponding fault injection methods, impact ranges and expected response indicators. For example, for a millimeter-wave radar signal loss fault, the fault injection method is to disconnect the radar power supply or shield the signal, the impact range is the obstacle detection function ahead, and the expected response indicator is that the system should switch to the backup sensor or activate the minimum risk strategy within a specified time.

[0029] A functional safety fault library is constructed based on functional safety fault events. The functional safety fault library stores various hardware fault modes and software fault modes in accordance with the ISO26262 standard, including a set of fault types that meet the ASIL level requirements, such as sensor failure, actuator jamming, communication delay, and computing unit overload.

[0030] It should be noted that during the test case design phase, the types, parameters (such as light intensity and obstacle speed) and trigger times of expected functional safety scenario events, as well as the types, failure modes and trigger times of functional safety failure events, are defined through the software coordination unit.

[0031] Specifically, the failure types of functional safety failure events include: sensor signal loss, actuator jamming, ECU crash, communication delay, etc.; the failure modes of functional safety failure events include: permanent, transient, and intermittent; and the failure severity of functional safety failure events includes: such as CAN bus packet loss rate and the degree of radar signal-to-noise ratio degradation, etc.

[0032] Step S102: Generate precise timestamps corresponding to the expected functional safety scenario event and the functional safety failure event through a programmable logic device, and synchronously trigger the expected functional safety scenario event and the functional safety failure event based on the precise timestamps to simulate the corresponding risk scenarios; The generation of accurate timestamps requires the joint implementation of hardware and software. On the hardware side, programmable logic devices are used as the system's main clock source, while on the software side, the IEEE 1588 transparent clock mechanism and high-precision time synchronization protocol are adopted. After the software coordination unit parses the user configuration, it sends the trigger command to the hardware timestamp unit to achieve hardware-software collaboration.

[0033] It should be noted that if anticipated functional safety scenario events and functional safety failure events occur close together or simultaneously, they may trigger system-level failures. Traditional testing methods typically verify anticipated functional safety scenario events (such as glare-induced perception failure, reduced target recognition rate in rainy or foggy weather, and performance-limited scenarios like ghosting) and functional safety failure events (such as sensor power failure, ECU communication timeout, and random hardware failures like brake actuator jamming) separately, neglecting their coupling effect. Therefore, this step uses high-precision timestamps to achieve controllable, repeatable, and synchronous triggering of both types of events to expose potential system vulnerabilities.

[0034] By triggering expected functional safety scenario events and functional safety failure events with precise timestamps, the time synchronization accuracy error is reduced, ensuring that expected functional safety scenario events (such as severe weather and complex traffic participant behavior) and functional safety failure events (such as sensor failure and communication delay) can physically occur simultaneously, thereby simulating possible complex risk scenarios in reality.

[0035] Step S103: Based on the type of the functional safety failure event, select the verification level of the risk scenario, execute the simulation instance corresponding to the verification level, obtain test data, perform risk assessment through the risk assessment model based on the test data, and generate a unified verification report.

[0036] Furthermore, such as Figure 2 As shown, the topology of the risk assessment model includes a bottom-level evidence node layer, an intermediate latent variable layer, and a top-level output node layer. The steps of conducting risk assessment based on the test data using the risk assessment model and generating a unified verification report include: The test data is divided into functional safety indicators and expected functional safety indicators. The functional safety indicators and expected functional safety indicators are respectively input into discrete nodes and continuous nodes in the underlying evidence node layer. The functional safety indicators and expected functional safety indicators are then fused through a probability transformation interface to obtain fused data. Based on the fused data, risk aggregation is performed through the risk propagation path in the intermediate hidden variable layer to obtain risk aggregated data. The risk propagation path is, in order, perception, decision-making, control, and system integration. Based on the aggregated risk data, risk assessment results are generated through the top-level output node layer. The risk assessment results include acceptable risks, risks requiring review, and unacceptable risks, and a unified verification report that meets the requirements of ISO 26262 and ISO 21448 standards is generated.

[0037] Through the above steps, different test scenarios are hierarchically labeled based on a six-dimensional complexity evaluation model to obtain expected functional safety scenario events and functional safety failure events. Then, precise timestamps corresponding to the expected functional safety scenario events and functional safety failure events are generated through programmable logic devices. Based on the precise timestamps, the expected functional safety scenario events and functional safety failure events are synchronously triggered to simulate the corresponding risk scenarios. Then, based on the type of functional safety failure event, the verification level of the risk scenario is selected, and the simulation instance corresponding to the verification level is executed to obtain test data. Based on the test data, risk assessment is performed through a risk assessment model, and a unified verification report is generated. Unlike existing technologies, this approach achieves joint injection of scenarios and failures, continuous accumulation of multi-level verification data, and composite risk quantification assessment, thereby improving the comprehensiveness and efficiency of safety verification for intelligent driving systems.

[0038] Furthermore, the step of synchronously triggering expected functional safety scenario events and functional safety failure events based on the precise timestamp to simulate the corresponding risk scenarios includes: When the difference between the occurrence time of the expected functional safety scenario event and the occurrence time of the functional safety failure event does not exceed a preset event threshold, it is defined as a composite risk scenario, and the verification level of the composite risk scenario is selected as hardware-in-the-loop verification or vehicle-in-the-loop verification based on the type of the functional safety failure event. The term "composite risk scenario" specifically refers to a risk scenario that simultaneously includes functional safety (ISO 26262) failure factors and expected functional safety (ISO 21448) performance limitations. Specifically, this includes: the superposition of system failures and performance limitations; the cascading effect of multiple independent failures; the interaction between human intervention and system failures; and the superposition of V2X information delays / losses and local perception limitations. It does not include single-type risks or purely human-operated factors. It should be noted that in this embodiment, the preset event threshold is 100ms. When defined as a composite risk scenario, the risk level assessment weight is automatically increased to identify potential amplification effects of composite risks.

[0039] When the difference between the occurrence time of the expected functional safety scenario event and the occurrence time of the functional safety failure event exceeds the preset event threshold, it is defined as a normal risk scenario, and the verification level of the normal risk scenario is selected as model-in-the-loop verification or software-in-the-loop verification based on the type of the functional safety failure event.

[0040] The verification levels, from lowest to highest, are: Model-in-the-Loop (MIL) verification, Software-in-the-Loop (Software-in-the-Loop) verification, Hardware-in-the-Loop (HIL) verification, and Vehicle-in-the-Loop (VIL) verification. If the current verification is in MIL or Software-in-the-Loop and a composite event (composite risk scenario) is detected, it will automatically switch to Hardware-in-the-Loop (HIL) verification. When the risk assessment result of the test data exceeds the safety boundary, a level transition is also automatically triggered. Examples of switching conditions are as follows: Risk score ≥ threshold T (e.g., T = 0.85 / 1.0); System response time > safety tolerance window (e.g., AEB trigger delay > 300 ms); Redundancy mechanisms fail (e.g., after the primary sensing fails, the backup system is still unable to identify the target). At this point, even if no functional safety fault event is explicitly injected, the system is upgraded to a higher fidelity verification level to confirm the actual performance simply because an expected functional safety scenario event causes the system to be in a critical state.

[0041] Furthermore, when low-level simulations cannot provide sufficient confidence, a forced switch to a higher level is initiated. Typical scenarios include: The algorithm under test depends on hardware-specific behaviors (such as GPU inference latency and CAN bus arbitration). The low-level model does not include key nonlinear elements (such as the hydraulic response of the braking system and the torque fluctuation of the motor). The simulation results deviated significantly from historical real vehicle data (as determined by the consistency verification module). In such cases, the system will proactively terminate the current level of testing and launch a higher-level simulation instance to obtain more reliable verification evidence.

[0042] Furthermore, the method also includes: An initial risk assessment model is constructed based on a three-layer Bayesian network. The ASIL level elements of ISO 26262 and the SOTIF hazard index of ISO 21448 are used as two input data. The two input data are fused using a Gaussian mixture model, and the initial risk assessment model is trained based on the fusion result to obtain the risk assessment model.

[0043] The risk assessment model's topology includes a bottom-level evidence node layer, an intermediate hidden variable layer, and a top-level output node layer. The bottom-level evidence node layer comprises 20 nodes, divided into 10 functional safety observation variables and 10 expected functional safety observation variables. The heterogeneous design of the bottom-level evidence node layer addresses the issue of data characteristic differences. Specifically, a heterogeneous node design is adopted: the functional safety observation nodes use a discrete probability distribution model, while the expected functional safety observation nodes use a continuous probability distribution model. A Gaussian mixture model is used to achieve probability transformation between nodes, resolving the problem of incompatible mathematical representations. The integration method for functional safety indicators and expected functional safety indicators is as follows: considering the different importance of the two types of safety standards in the safety chain, a higher weight is assigned to functional safety failure indicators, and a lower weight is assigned to expected functional safety indicators. The final risk value is a weighted sum plus a composite risk interaction term, used to characterize the amplification effect when both types of risks occur simultaneously. The intermediate latent variable layer comprises four nodes: a perception risk node, a decision risk node, a control risk node, and a system integration risk node. The specific structure of this layer addresses the risk propagation path modeling problem. Specifically, the topology design of the three-layer Bayesian network is based on the risk propagation mechanism of intelligent driving systems: in intelligent driving systems, risks first affect the perception module (e.g., sensor failure or performance degradation), then propagate to the decision module (e.g., planning algorithm errors), and then affect the control module (e.g., execution delays or deviations), ultimately manifesting as system-level risks. The intermediate latent variable layer (four nodes) of this invention is designed according to this physical risk propagation path, rather than an arbitrary mathematical layering. This structural design allows risk assessment results to directly correspond to system improvement directions. For example, a high value at the perception risk node indicates a need to enhance sensor redundancy; a high value at the control risk node indicates a need to optimize the actuator fault tolerance mechanism. This technical feature solves the problem that traditional risk assessment methods struggle to map results to specific improvement measures. The top-level output node layer consists of three nodes: acceptable risk node, risk node requiring review, and unacceptable risk node. The top-level output node layer provides actionable security decisions.

[0044] This design is not a conventional application of Bayesian networks, but a customized technical solution for the specific needs of intelligent driving safety verification, solving the fundamental problem of the disconnect between the two types of safety standard systems. In particular, by mapping risk propagation paths to the network structure, a direct link between technical effects and engineering improvements is achieved, which is impossible with traditional black-box risk assessment models.

[0045] Specific implementation example: When the system simultaneously faces partial camera obstruction and communication delays in the braking system, the bottom-level evidence node layer captures parameters such as decreased perception accuracy, increased decision-making delay, and prolonged braking response time. The Bayesian network, through conditional probability inference, calculates the perception risk node value, control risk node value, and system integration risk node value. If the final risk output exceeds a preset threshold, it is determined to be an unacceptable risk, requiring immediate triggering of the minimum risk strategy. Because the intermediate hidden variable layer is designed according to the information flow of perception-decision-control-system integration, the risk assessment results can directly pinpoint weak points and guide system improvement.

[0046] Furthermore, the risk assessment model is used to evaluate multiple dimensions of indicators, including severity, exposure probability, controllability, SOTIF uncertainty, and system robustness. The expression of the risk assessment model is shown below:

[0047]

[0048]

[0049] in, and All represent the final output value of the risk assessment model. This represents the risk amplification factor. This represents the time difference between the expected functional safety scenario event and the functional safety failure event. Indicates severity, Indicates the probability of exposure. Indicates controllability, This indicates SOTIF uncertainty. Indicates system robustness. These represent the weights for severity, exposure probability, controllability, SOTIF uncertainty, and system robustness, respectively.

[0050] It should be noted that when If the value is less than 0.3, it is considered low risk, the current verification level passes, and it is recorded as "covered"; if 0.3 ≤ If the value is less than 0.7, it indicates medium risk; it is recommended to repeat the test or increase the perturbation parameter. If the value is ≥0.7, it is considered high risk and will automatically switch to a higher level of verification.

[0051] Furthermore, the severity reflects the degree of severity of the accident's consequences, estimated based on a physical collision model. The formula for expressing this is as follows:

[0052] in, Indicates the kinetic energy of the collision system. Indicates the reference kinetic energy threshold. Indicates the equivalent collision mass (kg). This indicates the relative speed (m / s) between the main vehicle and the target.

[0053] The exposure probability represents the frequency of occurrence of this scenario in the real world, and this exposure probability can be normalized to... High-frequency scenarios The expression for the exposure probability E is as follows:

[0054] in, This indicates the number of times this type of test scenario appears in the natural driving dataset. This represents the number of test scenario samples corresponding to the total effective driving mileage.

[0055] The controllability is used to measure the ability of a driver or system to intervene before a hazard occurs. The expression is as follows:

[0056] in, This indicates the time from when the system issues a warning to when a collision occurs. This represents the minimum controllable time window, typically 1.5s-2.0s.

[0057] The SOTIF uncertainty is used to reflect the probability of unsafe behavior caused by limitations in perception or decision-making performance. The expression is as follows:

[0058] in, The weighting coefficients represent the target false negative rate. Indicates the target false negative rate. The weighting coefficients represent the standard deviation of the positioning. This represents the standard deviation, which is normalized to [0,1]. The weighting coefficients represent the confidence levels of the planning module. This indicates the confidence level of the planning module. .

[0059] The system robustness is used to measure the ability to maintain safe functions under functional safety failures. The expression is as follows:

[0060] in, This indicates the time during which the system still meets safety constraints during a failure. R represents the duration of a functional safety failure. If the system fails immediately, R=0; if it remains safe throughout, R=1. The corresponding robustness risk is... .

[0061] Furthermore, the step of hierarchically labeling different test scenarios based on the six-dimensional complexity evaluation model includes: Based on a predefined quantization threshold, different test scenarios are automatically classified to generate variant scenarios to cover the main areas of the six-dimensional complexity space. The variant scenarios include hot scenarios and cold data. All test scenarios are graded and labeled based on a six-dimensional complexity evaluation model, which includes a road layer, a traffic facility layer, a temporary traffic event layer, a traffic participant layer, an environmental condition layer, and an information layer. Each layer is defined with a score of 1-5 according to specific rules, and the total complexity score is the sum of the scores of each layer, which is used to guide test priority scheduling.

[0062] The specific scoring criteria for the six-dimensional complexity assessment model are as follows: The scoring criteria for the road layer are determined based on road geometry, number of lanes, and traffic control methods; the scoring criteria for the traffic facility layer are determined based on the density and complexity of traffic facilities per unit length; the scoring criteria for the temporary traffic event layer are determined based on the degree and duration of the event's interference with traffic flow; the scoring criteria for the traffic participant layer are determined based on vehicle density and the diversity of traffic participants; the scoring criteria for the environmental conditions layer are determined based on visibility, road surface adhesion coefficient, and light intensity; and the scoring criteria for the information layer are determined based on V2X information coverage, map accuracy, and sensor information integrity.

[0063] Specifically, the scoring criteria for road levels are as follows: Level 1 corresponds to expressways (design speed ≥ 100 km / h, fully enclosed); Level 2 corresponds to urban expressways (design speed 80 km / h, partially enclosed); Level 3 corresponds to urban arterial roads (design speed 60 km / h, with traffic lights); Level 4 corresponds to urban secondary arterial roads (design speed 40 km / h, mixed traffic); and Level 5 corresponds to rural roads without road markings (design speed < 40 km / h, no traffic control).

[0064] The scoring criteria for traffic facility layers are as follows: Level 1 corresponds to a facility density of <5 facilities / km (basic road markings only); Level 2 corresponds to a facility density of 5-10 facilities / km (including basic signs); Level 3 corresponds to a facility density of 10-20 facilities / km (including traffic lights); Level 4 corresponds to a facility density of 20-30 facilities / km (including complex grade-separated intersections); and Level 5 corresponds to a facility density of >3 facilities / km (dense signaling systems + intelligent transportation facilities). The facility density calculation includes the number of traffic signs, traffic lights, monitoring equipment, roadside units, etc., per kilometer.

[0065] The scoring criteria for temporary traffic incidents are as follows: Level 1 corresponds to no temporary incidents; Level 2 corresponds to minor disturbances (such as temporary parking on one side, lasting less than 1 minute); Level 3 corresponds to moderate disturbances (such as construction on one side, occupying one lane, lasting 1-5 minutes); Level 4 corresponds to significant disturbances (such as construction in both directions, occupying 50% of the road width, lasting 5-15 minutes); and Level 5 corresponds to severe disturbances (such as road closures and detours, or sudden accidents, lasting more than 15 minutes).

[0066] The scoring criteria for traffic participants are as follows: Level 1 corresponds to a vehicle density of <10 vehicles / km / lane, with no pedestrians / non-motorized vehicles; Level 2 corresponds to a vehicle density of 10-20 vehicles / km / lane, with occasional pedestrians; Level 3 corresponds to a vehicle density of 20-40 vehicles / km / lane, with a small number of non-motorized vehicles; Level 4 corresponds to a vehicle density of 40-60 vehicles / km / lane, with a relatively large number of pedestrians / non-motorized vehicles; Level 5 corresponds to a vehicle density >60 vehicles / km / lane, and includes more than 3 different types of traffic participants. In intersection scenarios, a conflict point count assessment can be used as an alternative: Level 1 corresponds to 0-2 conflict points, Level 2 corresponds to 3-5 conflict points, Level 3 corresponds to 6-8 conflict points, Level 4 corresponds to 9-12 conflict points, and Level 5 corresponds to >12 conflict points.

[0067] The scoring criteria for the environmental condition layers are as follows: Level 1 corresponds to visibility >1000m, dry road surface (adhesion coefficient >0.8), and sufficient sunlight (>10000 lux); Level 2 corresponds to visibility 500 m - 1000m, slightly wet road surface (adhesion coefficient 0.6-0.8), and good sunlight (1000 lux - 10000 lux); Level 3 corresponds to visibility 200m - 500m, wet road surface (adhesion coefficient 0.4-0.6), and moderate sunlight (100 lux - 1000 lux); Level 4 corresponds to visibility 50m - 200m, slippery road surface (adhesion coefficient 0.2-0.4), and poor sunlight (10 lux - 100 lux); Level 5 corresponds to visibility <50m, icy / waterlogged road surface (adhesion coefficient <0.2), and extremely poor sunlight (<10 lux).

[0068] The scoring criteria for the information layer are as follows: Level 1 corresponds to V2X coverage >95%, high-precision map accuracy <0.1m, and no sensor obstruction; Level 2 corresponds to V2X coverage 80%-95%, high-precision map accuracy 0.1m-0.3m, and slight sensor obstruction <10%; Level 3 corresponds to V2X coverage 60%-80%, high-precision map accuracy 0.3m-0.5m, and partial sensor obstruction 10%-30%; Level 4 corresponds to V2X coverage 30%-60%, high-precision map accuracy 0.5m-1.0m, and significant sensor obstruction 30%-60%; Level 5 corresponds to V2X coverage <30%, high-precision map accuracy >1.0m, and severe sensor obstruction >60%.

[0069] It should be noted that the above-mentioned quantification thresholds are only a reference standard for this embodiment. In actual applications, they can be appropriately adjusted according to factors such as road type, regional characteristics, and vehicle type composition. Based on the scene coverage requirements specified in Section 7.4.2 of ISO 21448, theoretical calculations show that the six-dimensional complexity space has 5^6 = 15625 basic combinations. Considering that each dimension requires at least 3 parameter variants to cover boundary conditions, theoretically approximately 46875 scenes are needed. Furthermore, according to the requirements of Annex D of ISO 21448 regarding long-tail risks, an additional 20% of edge scenes need to be covered, totaling approximately 56250 scenes. This system architecture design meets this theoretical requirement.

[0070] The hot scenarios are stored in memory or SSD through a tiered storage architecture, while the cold data is stored in a large-capacity disk array. The hot scenarios are test scenarios whose access frequency exceeds a preset threshold, and the cold data are test scenarios whose access frequency does not exceed the preset threshold. The incremental changes of the scene parameters in the test scenario are compressed and stored using Delta encoding technology. Combined with the R* tree spatial index structure, the scene parameters are hierarchically organized, and test resources are dynamically classified through an adaptive priority scheduling mechanism.

[0071] The preset threshold is determined based on actual scenarios, and Delta encoding technology is used to compress and store incremental changes in scenario parameters, significantly reducing redundant data. Combined with an improved R* tree spatial index structure, the scenario parameters are hierarchically organized, reducing the retrieval complexity from O(n) to O(log n). These techniques work together to support rapid retrieval, enabling the system to respond in real-time to query requests from a large-scale scenario library, providing a technical foundation for the safety verification of intelligent driving systems.

[0072] It should be noted that a tiered storage architecture is adopted: frequently accessed hot scenarios are stored in memory or SSDs, while infrequently accessed cold data is stored in a large-capacity disk array; Delta encoding technology is used to compress the storage space of similar scenarios, preserving only parameter differences; and an improved R* tree index structure is used to organize high-dimensional complexity parameters, supporting fast retrieval. The system architecture design follows the principle of horizontal scaling, adding storage nodes to cope with the growth in the number of scenarios, ensuring the engineering feasibility of the storage solution. This storage architecture resolves the technical contradiction that traditional scenario libraries cannot simultaneously meet the requirements of large capacity and fast retrieval.

[0073] Furthermore, the verification levels include model-in-the-loop verification, software-in-the-loop verification, hardware-in-the-loop verification, and vehicle-in-the-loop verification; The model-in-the-loop verification is performed in MATLAB or Simulink tools using pure software simulation of the algorithm model, without relying on code or hardware, to verify whether the logic of the early verification algorithm is correct. The software-in-the-loop verification involves running the C or C++ code generated by the algorithm on a PC or virtual machine, interacting with the simulation environment, and verifying whether the code behavior is consistent with the model, thereby verifying whether the code implementation is consistent with the model. The hardware-in-the-loop verification involves connecting a real ECU controller to a real-time simulation platform, using simulated sensors or vehicle dynamic signals to drive the ECU, and testing its real response to verify the functional safety performance of the ECU in a near-real electrical, communication, or timing environment. The vehicle-in-the-loop verification involves placing a real vehicle (or test bench) in a controlled environment and fusing virtual traffic participants with real sensors to achieve a "semi-real vehicle" closed-loop test, thereby verifying the system's comprehensive performance under real sensors, actuators, and environmental interference.

[0074] Furthermore, the method also includes: When simulating the composite risk scenario, the scenario injection interface corresponding to the expected functional safety scenario event and the fault injection interface corresponding to the functional safety failure event are driven in the same hardware.

[0075] The software coordination unit sends the event schedule to the FPGA. When the global time reaches the triggering time of the expected functional safety event, the FPGA immediately triggers the scene injection interface (such as inputting a blurred image into the perception model). Simultaneously (or within a preset small offset), when the global time reaches the triggering moment of the functional safety fault event, the fault injection interface is triggered (e.g., cutting off the radar CAN signal).

[0076] Since all operations are driven by the same hardware clock, software uncertainties such as operating system scheduling jitter and network latency are avoided, ensuring that the event synchronization accuracy is ≤1 ms.

[0077] It should be noted that, based on previous simulation data or online risk assessment models, the system can dynamically decide whether to trigger functional safety failure events. For example, if the current expected functional safety scenario event has brought the system to the decision boundary (such as AEB about to be triggered but with low confidence), then a sensor failure fault will be automatically injected to test the system's robustness.

[0078] Furthermore, the method also includes: When the deviation between the test data and the historical real vehicle data exceeds a preset verification threshold, the current verification level test is terminated, and the lower-level time event sequence is loaded synchronously to start the higher-level simulation instance for corresponding simulation testing.

[0079] The mechanism for transitioning from a lower level to a higher level is as follows: Parameter mapping and adaptation: Idealized model parameters in lower levels need to be mapped to physically executable parameters in higher levels. Example: "Camera image blurring" in Model-in-the-Loop (MiL) validation → "Injecting a noisy real image stream" in Hardware-in-the-Loop (HiL) validation; Timestamp alignment and replay: The global precise timestamp generated by the FPGA is used as the anchor point; when the high-level simulation platform starts, it synchronously loads the low-level time event sequence and replays it with the same time base; ensuring that the "same test case" has a completely consistent event triggering sequence at different levels (error ≤ 1 ms, i.e., the preset verification threshold is 1 ms).

[0080] Results Comparison and Difference Analysis: The system automatically compares the output responses of low-level and high-level systems: If the behaviors are consistent, it is marked as "verified" and the priority of high-level tests can be reduced; if the behaviors are inconsistent (e.g., Model-in-the-Loop (MiL) verification successfully avoids obstacles, while Hardware-in-the-Loop (HiL) verification fails), root cause analysis is triggered, and the low-level model may be modified retrospectively.

[0081] Verification evidence accumulation: The test results at each level are tagged with a unique scenario ID and timestamp; all results at all levels are aggregated into a unified verification database; and finally, an integrated verification report conforming to ISO 26262 and ISO 21448 is generated.

[0082] Example 2 Please see Figure 3 Here is a structural block diagram of the intelligent driving multi-level simulation test system according to the second embodiment of the present invention. The system includes: The acquisition module 10 is used to hierarchically label different test scenarios based on a six-dimensional complexity evaluation model in order to obtain expected functional safety scenario events and functional safety failure events. The triggering module 20 is used to generate precise timestamps corresponding to the expected functional safety scenario event and the functional safety failure event through a programmable logic device, and to synchronously trigger the expected functional safety scenario event and the functional safety failure event based on the precise timestamps to simulate the corresponding risk scenarios. The simulation and generation module 30 is used to select the verification level of the risk scenario based on the type of the functional safety failure event, execute the simulation instance corresponding to the verification level, obtain test data, perform risk assessment through the risk assessment model based on the test data, and generate a unified verification report.

[0083] In practical implementation, a six-dimensional complexity assessment model is used to hierarchically label different test scenarios to obtain expected functional safety scenario events and functional safety failure events. Then, a programmable logic device generates precise timestamps corresponding to the expected functional safety scenario events and functional safety failure events. Based on these precise timestamps, the expected functional safety scenario events and functional safety failure events are synchronously triggered to simulate corresponding risk scenarios. Then, based on the type of functional safety failure event, the verification level of the risk scenario is selected, and the simulation instance corresponding to the verification level is executed to obtain test data. Based on the test data, a risk assessment model is used to conduct risk assessment and generate a unified verification report. Unlike existing technologies, this approach achieves joint injection of scenarios and failures, continuous accumulation of multi-level verification data, and composite risk quantification assessment, thereby improving the comprehensiveness and efficiency of safety verification for intelligent driving systems.

[0084] Furthermore, the triggering module 20 includes: The first definition unit is used to define a composite risk scenario when the difference between the occurrence time of the expected functional safety scenario event and the occurrence time of the functional safety failure event does not exceed a preset event threshold, and to select the verification level of the composite risk scenario as hardware-in-the-loop verification or vehicle-in-the-loop verification based on the type of the functional safety failure event. The second definition unit is used to define a common risk scenario when the difference between the occurrence time of the expected functional safety scenario event and the occurrence time of the functional safety failure event exceeds the preset event threshold, and to select the verification level of the common risk scenario as model-in-the-loop verification or software-in-the-loop verification based on the type of the functional safety failure event.

[0085] Furthermore, the topology of the risk assessment model includes a bottom-level evidence node layer, an intermediate latent variable layer, and a top-level output node layer, and the simulation and generation module 30 includes: A partitioning unit is used to partition the test data into functional safety indicators and expected functional safety indicators. The functional safety indicators and expected functional safety indicators are respectively input into discrete nodes and continuous nodes in the underlying evidence node layer. The functional safety indicators and expected functional safety indicators are fused through a probability transformation interface to obtain fused data. The risk aggregation unit is used to aggregate risks based on the fused data and through the risk propagation path in the intermediate latent variable layer to obtain risk aggregated data. The risk propagation path is, in order, perception, decision-making, control, and system integration. The generation unit is used to generate risk assessment results based on the risk aggregation data and through the top-level output node layer. The risk assessment results include acceptable risks, risks requiring review, and unacceptable risks, and generate a unified verification report that meets the requirements of ISO26262 and ISO 21448 standards.

[0086] Furthermore, the system also includes: The module is used to build an initial risk assessment model based on a three-layer Bayesian network. It takes the ASIL level elements of ISO 26262 and the SOTIF hazard index of ISO 21448 as two input data, fuses the two input data through a Gaussian mixture model, and trains the initial risk assessment model based on the fusion result to obtain the risk assessment model.

[0087] Furthermore, the risk assessment model is used to evaluate multiple dimensions of indicators, including severity, exposure probability, controllability, SOTIF uncertainty, and system robustness. The expression of the risk assessment model is shown below:

[0088]

[0089]

[0090] in, and All represent the final output value of the risk assessment model. This represents the risk amplification factor. This represents the time difference between the expected functional safety scenario event and the functional safety failure event. Indicates severity, Indicates the probability of exposure. Indicates controllability, This indicates SOTIF uncertainty. Indicates system robustness. These represent the weights for severity, exposure probability, controllability, SOTIF uncertainty, and system robustness, respectively.

[0091] Furthermore, the first acquisition module includes: The generation unit is used to automatically classify different test scenarios based on a predefined quantization threshold and generate variant scenarios to cover the main areas of the six-dimensional complexity space. The variant scenarios include hot scenarios and cold data. The storage unit is used to store the hot scenarios in memory or SSD through a hierarchical storage architecture, and to store the cold data in a large-capacity disk array. The hot scenarios are test scenarios whose access frequency exceeds a preset threshold, and the cold data are test scenarios whose access frequency does not exceed the preset threshold. The organization and classification unit is used to compress and store the incremental changes of the scene parameters of the test scenario using Delta encoding technology, combine the R* tree spatial index structure to hierarchically organize the scene parameters, and dynamically classify test resources through an adaptive priority scheduling mechanism.

[0092] Furthermore, the verification levels include model-in-the-loop verification, software-in-the-loop verification, hardware-in-the-loop verification, and vehicle-in-the-loop verification; The model-in-the-loop verification is performed in MATLAB or Simulink tools using pure software simulation of the algorithm model, without relying on code or hardware, to verify whether the logic of the early verification algorithm is correct. The software-in-the-loop verification involves running the C or C++ code generated by the algorithm on a PC or virtual machine, interacting with the simulation environment, and verifying whether the code behavior is consistent with the model, thereby verifying whether the code implementation is consistent with the model. The hardware-in-the-loop verification involves connecting a real ECU controller to a real-time simulation platform, using simulated sensors or vehicle dynamic signals to drive the ECU, and testing its real response to verify the functional safety performance of the ECU in a near-real electrical, communication, or timing environment. The vehicle-in-the-loop verification involves placing a real vehicle (or test bench) in a controlled environment and fusing virtual traffic participants with real sensors to achieve a "semi-real vehicle" closed-loop test, thereby verifying the system's comprehensive performance under real sensors, actuators, and environmental interference.

[0093] Furthermore, the system also includes: The driver module is used to drive the scenario injection interface corresponding to the expected functional safety scenario event and the fault injection interface corresponding to the functional safety fault event in the same hardware when simulating the composite risk scenario.

[0094] Furthermore, the system also includes: The startup module is used to terminate the current verification level test and synchronously load the lower-level time event sequence when the deviation between the test data and the historical real vehicle data is greater than a preset verification threshold, so as to start the higher-level simulation instance for corresponding simulation test.

[0095] Example 3 In the third embodiment of the present invention, based on the same inventive concept, the present invention proposes a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the intelligent driving multi-level simulation test method of the above embodiments. The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means containing storage, communication, propagation, or transmission programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples of computer-readable media (a non-exhaustive list) include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0096] The memory may include a large-capacity storage device for data or instructions. For example, and not limitingly, the memory may include a hard disk drive (HDD), a floppy disk drive, a solid-state drive (SSD), flash memory, an optical disk drive, a magneto-optical disk drive, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory may include removable or non-removable (or fixed) media. Where appropriate, the memory may be internal or external to the data processing device. In a particular embodiment, the memory is non-volatile memory. In a particular embodiment, the memory includes read-only memory (ROM) and random access memory (RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), an electrically alterable read-only memory (EAROM), or flash memory, or a combination of two or more of these. Where appropriate, the RAM can be Static Random-Access Memory (SRAM) or Dynamic Random-Access Memory (DRAM). DRAM can be Fast Page Mode Dynamic Random-Access Memory (FPMDRAM), Extended Data Out Dynamic Random-Access Memory (EDODRAM), Synchronous Dynamic Random-Access Memory (SDRAM), etc.

[0097] Example 4 In the fourth embodiment of the present invention, based on the same inventive concept, the present invention proposes a terminal, the terminal comprising: a processor and a memory; the processor and the memory communicate with each other; the memory is used to store instructions; the processor is used to execute the instructions in the memory to execute the intelligent driving multi-level simulation test method of the above embodiment.

[0098] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0099] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0100] Without causing conflict, those skilled in the art can freely combine and use the above-mentioned additional technical features.

[0101] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A multi-level simulation test method for intelligent driving, characterized in that, The method includes: Based on a six-dimensional complexity assessment model, different test scenarios are graded and labeled to obtain expected functional safety scenario events and functional safety failure events. The six-dimensional complexity assessment model includes a road layer, a traffic facility layer, a temporary traffic event layer, a traffic participant layer, an environmental condition layer, and an information layer. Each layer is defined with a score of 1 to 5, and the sum of the scores of each layer is the total complexity score. The total complexity score is used to guide test priority scheduling. The programmable logic device generates precise timestamps corresponding to the expected functional safety scenario events and the functional safety failure events, and synchronously triggers the expected functional safety scenario events and the functional safety failure events based on the precise timestamps to simulate the corresponding risk scenarios. Based on the type of the functional safety failure event, the verification level of the risk scenario is selected, and the simulation instance corresponding to the verification level is executed to obtain test data. Based on the test data, a risk assessment is performed through a risk assessment model, and a unified verification report is generated. The risk assessment model is used to evaluate multiple dimensions of indicators, including severity, probability of exposure, controllability, SOTIF uncertainty, and system robustness. The expression of the risk assessment model is shown below: in, and All represent the final output value of the risk assessment model. This represents the risk amplification factor. This represents the time difference between the expected functional safety scenario event and the functional safety failure event. Indicates severity, Indicates the probability of exposure. Indicates controllability, This indicates SOTIF uncertainty. Indicates system robustness. These represent the weights for severity, exposure probability, controllability, SOTIF uncertainty, and system robustness, respectively.

2. The intelligent driving multi-level simulation test method according to claim 1, characterized in that, The steps of synchronously triggering expected functional safety scenario events and functional safety failure events based on the precise timestamp to simulate corresponding risk scenarios include: When the difference between the occurrence time of the expected functional safety scenario event and the occurrence time of the functional safety failure event does not exceed a preset event threshold, it is defined as a composite risk scenario, and the verification level of the composite risk scenario is selected as hardware-in-the-loop verification or vehicle-in-the-loop verification based on the type of the functional safety failure event. When the difference between the occurrence time of the expected functional safety scenario event and the occurrence time of the functional safety failure event exceeds the preset event threshold, it is defined as a normal risk scenario, and the verification level of the normal risk scenario is selected as model-in-the-loop verification or software-in-the-loop verification based on the type of the functional safety failure event.

3. The intelligent driving multi-level simulation test method according to claim 1, characterized in that, The risk assessment model's topology includes a bottom-level evidence node layer, an intermediate latent variable layer, and a top-level output node layer. The steps of conducting risk assessment based on the test data using the risk assessment model and generating a unified verification report include: The test data is divided into functional safety indicators and expected functional safety indicators. The functional safety indicators and expected functional safety indicators are respectively input into discrete nodes and continuous nodes in the underlying evidence node layer. The functional safety indicators and expected functional safety indicators are then fused through a probability transformation interface to obtain fused data. Based on the fused data, risk aggregation is performed through the risk propagation path in the intermediate hidden variable layer to obtain risk aggregated data. The risk propagation path is, in order, perception, decision-making, control, and system integration. Based on the aggregated risk data, risk assessment results are generated through the top-level output node layer. The risk assessment results include acceptable risks, risks requiring review, and unacceptable risks, and a unified verification report that meets the requirements of ISO 26262 and ISO 21448 standards is generated.

4. The intelligent driving multi-level simulation test method according to claim 1, characterized in that, The method further includes: An initial risk assessment model is constructed based on a three-layer Bayesian network. The ASIL level elements of ISO 26262 and the SOTIF hazard index of ISO 21448 are used as two input data. The two input data are fused using a Gaussian mixture model. The initial risk assessment model is then trained based on the fusion result to obtain the risk assessment model.

5. The intelligent driving multi-level simulation test method according to claim 1, characterized in that, The steps for hierarchical labeling of different test scenarios based on the six-dimensional complexity evaluation model include: Based on a predefined quantization threshold, different test scenarios are automatically classified to generate variant scenarios to cover the main areas of the six-dimensional complexity space. The variant scenarios include hot scenarios and cold data. The hot scenarios are stored in memory or SSD through a tiered storage architecture, while the cold data is stored in a large-capacity disk array. The hot scenarios are test scenarios whose access frequency exceeds a preset threshold, and the cold data are test scenarios whose access frequency does not exceed the preset threshold. The incremental changes of the scene parameters in the test scenario are compressed and stored using Delta encoding technology. Combined with the R* tree spatial index structure, the scene parameters are hierarchically organized, and test resources are dynamically classified through an adaptive priority scheduling mechanism.

6. The intelligent driving multi-level simulation test method according to claim 1, characterized in that, The verification levels include model-in-the-loop verification, software-in-the-loop verification, hardware-in-the-loop verification, and vehicle-in-the-loop verification. The model-in-the-loop verification is performed in MATLAB or Simulink tools using pure software simulation of the algorithm model, without relying on code or hardware, to verify whether the logic of the early verification algorithm is correct. The software-in-the-loop verification involves running the C or C++ code generated by the algorithm on a PC or virtual machine, interacting with the simulation environment, and verifying whether the code behavior is consistent with the model, thereby verifying whether the code implementation is consistent with the model. The hardware-in-the-loop verification involves connecting a real ECU controller to a real-time simulation platform, using simulated sensors or vehicle dynamic signals to drive the ECU, and testing its real response to verify the functional safety performance of the ECU in a near-real electrical, communication, or timing environment. The vehicle-in-the-loop verification involves placing a real vehicle or test bench in a controlled environment and fusing virtual traffic participants with real sensors to achieve a "semi-real vehicle" closed-loop test, thereby verifying the system's comprehensive performance under real sensors, actuators, and environmental interference.

7. The intelligent driving multi-level simulation test method according to claim 2, characterized in that, The method further includes: When simulating the composite risk scenario, the scenario injection interface corresponding to the expected functional safety scenario event and the fault injection interface corresponding to the functional safety failure event are driven in the same hardware.

8. The intelligent driving multi-level simulation test method according to claim 1, characterized in that, The method further includes: When the deviation between the test data and the historical real vehicle data exceeds a preset verification threshold, the current verification level test is terminated, and the lower-level time event sequence is loaded synchronously to start the higher-level simulation instance for corresponding simulation testing.

9. A multi-level simulation test system for intelligent driving, used to implement the multi-level simulation test method for intelligent driving as described in any one of claims 1-8, characterized in that, The system includes: The acquisition module is used to hierarchically label different test scenarios based on a six-dimensional complexity evaluation model in order to obtain expected functional safety scenario events and functional safety failure events. The triggering module is used to generate precise timestamps corresponding to the expected functional safety scenario event and the functional safety failure event through a programmable logic device, and to synchronously trigger the expected functional safety scenario event and the functional safety failure event based on the precise timestamps to simulate the corresponding risk scenarios. The simulation and generation module is used to select the verification level of the risk scenario based on the type of the functional safety failure event, execute the simulation instance corresponding to the verification level, obtain test data, perform risk assessment through the risk assessment model based on the test data, and generate a unified verification report.

Images