An automatic driving simulation index generation method and system based on index configuration

Abstract

The application discloses an automatic driving simulation index generation method and system based on index configuration and belongs to the technical field of intelligent traffic. The method comprises the following steps: converting original data of different scene simulation tools into standardized data through a tool adapter and writing the standardized data into a unified data interface bus; acquiring an index configuration file of a target index, wherein the file at least comprises input requirements, a calculation entry and an output format; filtering and distributing bus data according to a simulation analysis task and the input requirements, and generating index input data packets; determining calculation logic according to the calculation entry and performing calculation to obtain index results; and encapsulating and outputting the results according to the output format. For new indexes, the system supports generating structured semantic rules through natural language description combined with a large model and mapping the structured semantic rules to a tool operator library to generate executable index plans. The application realizes decoupling among simulation tools, index calculation and result display, and improves the automation degree of index access and generation.

Description

Technical Field

[0001] This invention relates to the field of intelligent transportation and autonomous driving simulation testing technology, and more specifically to a method and system for generating autonomous driving simulation indicators based on indicator configuration. Background Technology

[0002] With the development of intelligent driving, intelligent connected vehicles, and autonomous driving systems, scenario-based simulation testing has gradually become an important means of evaluating vehicle safety, traffic efficiency, behavioral rationality, and risk levels. Scenario simulation tools can construct roads, vehicles, traffic participants, traffic signals, and environmental conditions in a virtual environment, and generate data such as vehicle trajectories, speeds, accelerations, relative distances, collision events, and traffic signal states through simulation. Based on this data, analytical indicators such as collision risk, traffic efficiency, comfort, rule compliance, and risk field intensity can be further calculated.

[0003] However, existing scene simulation and analysis systems typically have the following problems.

[0004] First, different simulation tools have significantly different data structures. Data such as vehicle status, road geometry, traffic participants, traffic light status, and simulation events often use different fields, coordinate systems, and data organization methods. When analysis metrics need to be migrated from one simulation tool to another, it is usually necessary to rewrite the data parsing, field mapping, and metric calling logic, resulting in poor system reusability.

[0005] Second, existing indicator calculation modules are often highly coupled with the system's main program or specific simulation tools. Adding, replacing, or deleting indicators requires modifying the main program code, which is not conducive to the expansion of the indicator library and the access of third-party indicators. Third, when users need to add an analysis metric that is not yet pre-configured in the system, developers usually need to write new metric calculation code, which has a long development cycle, high manpower costs, and makes it difficult to quickly respond to temporary analysis needs during the testing process. Therefore, there is an urgent need in this field for a new scenario simulation analysis method that decouples simulation tool access, indicator definition, and data acquisition. Summary of the Invention

[0006] In view of the above problems, the present invention is proposed to provide a method for generating autonomous driving simulation indicators based on indicator configuration that overcomes or at least partially solves the above problems.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: S1. Obtain raw simulation data output by at least one scene simulation tool, perform field mapping and unit conversion on the raw simulation data through a tool adapter to generate standardized data, and write the standardized data into a unified data interface bus; S2. Obtain the indicator configuration file corresponding to the target indicator. The indicator configuration file includes at least input requirements, calculation entry point and output format. The input requirements are used to describe the data fields required by the target indicator. The calculation entry point is used to describe the acquisition path of the calculation logic of the target indicator. The output format is used to describe the output structure of the calculation result of the target indicator. S3. Based on the simulation analysis task and the input requirements in the indicator configuration file, the standardized data in the unified data interface bus is filtered and distributed to generate the input data package corresponding to the target indicator; the simulation analysis task includes at least the simulation scenario to be analyzed, the vehicle under test, the simulation time range, and the target indicator set; the filtering and distribution includes at least extracting data from the unified data interface bus according to the data theme and object identifier; S4. Based on the calculation entry in the indicator configuration file, determine the calculation logic that accurately corresponds to the target indicator, and use the calculation logic to process the input data packet to obtain the original calculation result of the target indicator; S5. According to the output format in the indicator configuration file, encapsulate the original calculation result and output the encapsulated indicator result.

[0008] Preferably, in step S1, the field mapping includes converting the original field names in different scenario simulation tools into unified field names; the unit conversion includes converting the data units in different scenario simulation tools into unified data units. The tool adapter is also used to perform coordinate transformation and time synchronization processing on the original simulation data; The coordinate transformation is used to convert the local coordinates, map coordinates, or vehicle coordinates used by different scene simulation tools into a unified coordinate system; The time synchronization is used to align different data sources to the same simulation moment or the same time window.

[0009] Preferably, in step S3, the data topic includes at least one of vehicle status topic, road structure topic, traffic participant topic, traffic signal topic, trajectory data topic, and simulation event topic; The filtering and triage are also performed according to at least one of the following methods: time window, sampling frequency, and event triggering conditions.

[0010] Preferably, in step S4, the determination of the calculation logic includes: When the calculation entry in the indicator configuration file points to a preset calculation file, the preset calculation file is directly called as the calculation logic. When the calculation entry in the indicator configuration file does not point to a preset calculation file, the indicator description text input by the user is obtained, the indicator description text is converted into structured indicator semantic rules using a large model, the structured indicator semantic rules are validated for legality, and after the validation is passed, the structured indicator semantic rules are mapped to a preset simulation indicator tool operator library to generate an executable indicator plan composed of at least one event determination tool and / or statistical tool, which serves as the calculation logic.

[0011] Preferably, the validity verification includes at least one of field validity verification, object validity verification, event validity verification, and tool callability verification; The event determination tool includes at least one of the following: collision determination tool, lane crossing determination tool, red light violation determination tool, lane cutting determination tool, and rapid deceleration determination tool; the statistical tool includes at least one of the following: maximum value statistical tool, minimum value statistical tool, mean statistical tool, variance statistical tool, and duration statistical tool.

[0012] Preferably, in step S3, when the input requirements of multiple target indicators overlap, data filtering is performed only once on the unified data interface bus, and the same input data packet obtained from the filtering is distributed to the execution channels corresponding to the multiple target indicators respectively.

[0013] Preferably, the indicator configuration file further includes a set of adjustable parameters, each of which has a value range and a step size. Multiple parameter combinations are generated based on the value range and step size of each adjustable parameter. Steps S4 and S5 are executed for each parameter combination to obtain batch calculation results. Based on the batch calculation results, a sensitivity analysis is performed on each adjustable parameter to determine the degree of influence of each adjustable parameter on the index calculation results. The adjustable parameters are sorted according to their sensitivity, and key parameters, recommended parameter ranges, or parameter adjustment priorities are determined based on the sorting results.

[0014] Preferably, when there are multiple target indicators, an indicator execution graph is constructed based on the data dependencies between the target indicators. The computational tasks corresponding to multiple target indicators that do not have data dependencies are assigned to different computing units for parallel execution, and the computational tasks corresponding to target indicators that have data dependencies are executed sequentially according to the topological order of the indicator execution graph.

[0015] Preferably, the indicator configuration file further includes a visualization configuration, which includes at least one of chart type, horizontal axis field, vertical axis field, and spatial coordinate field; according to the visualization configuration, the encapsulated indicator results are rendered into corresponding visualization charts for display.

[0016] Based on the same inventive concept, this invention also discloses an autonomous driving simulation index generation system based on index configuration, used to execute any of the above-mentioned autonomous driving simulation index generation methods, including: A tool adapter is used to acquire raw simulation data output by at least one scene simulation tool, perform field mapping and unit conversion on the raw simulation data, and generate standardized data. A unified data interface bus, connected to the tool adapter, is used to receive and store the standardized data; The indicator manager is connected to the unified data interface bus. The indicator manager includes: The indicator configuration parsing module is used to read and parse the indicator configuration file corresponding to the target indicator. The indicator configuration file includes at least the input requirements, calculation entry and output format. The bus filtering and distribution module is connected to the unified data interface bus and the indicator configuration parsing module. It is used to filter and distribute the standardized data in the unified data interface bus according to the input requirements in the simulation analysis task and the indicator configuration file, and generate the input data package corresponding to the target indicator. The simulation analysis task includes at least the simulation scenario to be analyzed, the vehicle under test, the simulation time range, and the target indicator set. The indicator execution module, connected to the bus filtering and distribution module and the indicator configuration parsing module, is used to determine the calculation logic that accurately corresponds to the target indicator based on the calculation entry in the indicator configuration file, and to process the input data packet using the calculation logic to obtain the original calculation result of the target indicator. The result encapsulation module is connected to the indicator execution module and the indicator configuration parsing module. It is used to encapsulate the original calculation result according to the output format in the indicator configuration file and output the encapsulated indicator result.

[0017] The beneficial effects of the above-described technical solutions provided in the embodiments of the present invention include at least the following: First, this invention constructs a unified data interface bus to convert information such as vehicle status, road structure, traffic participants, traffic signals, trajectory data, simulation events, sensor data, and simulation time output by different scenario simulation tools into a standardized data interface. This eliminates the direct dependence of the indicator calculation module on the data structure of any specific simulation tool. Compared to existing technologies that require writing separate data parsing and field adaptation logic for different simulation tools, this invention reduces the secondary development costs when accessing and switching between multiple simulation tools and improves the compatibility of the scenario simulation analysis system with multiple simulation tools. Secondly, this invention drives data filtering and distribution on a unified data interface bus through simulation analysis tasks and indicator configuration files, enabling the system to automatically determine indicator input data packets based on data themes, object identifiers, time windows, sampling frequencies, and event triggering conditions. Compared to methods that obtain data solely from fixed interfaces or manually specified fields, this approach is more suitable for the continuous spatiotemporal data and event-triggered indicator calculation needs in autonomous driving simulations. It reduces the workload of manually configuring indicator input data and avoids repeated data retrieval and conversion. Third, this invention establishes an independent indicator configuration file for each analysis indicator, declaratively describing the indicator input requirements, output format, calculation entry point, visualization configuration, adjustable parameters, and sub-indicator dependencies. This eliminates the need to modify the main system program when adding, deleting, replacing, or updating indicators. The indicator manager performs data matching, field integrity verification, unit consistency verification, time synchronization verification, and object matching verification based on the indicator configuration file and simulation analysis task, thereby improving the automation level of indicator access, data matching, and indicator invocation. Fourth, this invention, through a structured indicator semantic rule generation mechanism, transforms the description of new indicators into rule expressions including objects, event types, judgment conditions, time windows, statistical methods, and output fields, and performs field, object, event, time window, and tool callability verification on the rules. Compared to directly generating the final code from a large model, this invention generates indicator execution logic through structured semantic rules—legality verification—tool operator mapping, which improves the controllability, interpretability, and reusability of the new indicator generation process. Fifth, this invention maps structured indicator semantic rules to event judgment tools such as collision detection, entry detection, following detection, and line-crossing detection, as well as statistical tools such as maximum value, minimum value, average value, duration, and first trigger time, through a simulation indicator tool operator library, generating an executable indicator plan. This approach enables common event judgment and statistical calculation to form reusable tool units, improving the efficiency of indicator construction and reducing the workload of repeatedly writing calculation code when adding new indicators; Sixth, this invention further supports serial-parallel scheduling based on indicator dependencies, tool call sequences, and input data sharing relationships. For indicator nodes without dependencies, the system can execute them in parallel; for indicator nodes with dependencies, the system can execute them sequentially; and for multiple indicators sharing the same input data packet, the system can reuse filtered data. This reduces redundant data retrieval and computation, improving the efficiency of autonomous driving simulation analysis under conditions of multiple indicators, multiple objects, multiple sub-indicators, and multiple parameter combinations. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0019] Figure 1 The following is a logic diagram of an autonomous driving simulation index generation method based on index configuration provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating the data access and standardization process of the simulation tool provided in this embodiment of the invention. Figure 3 This is a flowchart of the indicator configuration file parsing and indicator manager scheduling process provided in this embodiment of the invention; Figure 4 This is a flowchart illustrating the generation of executable indicator code based on semantic rules, as provided in this embodiment of the invention. Figure 5 This is a framework diagram of an autonomous driving simulation index generation system based on index configuration provided in an embodiment of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Example 1 This invention discloses a method for generating autonomous driving simulation indicators based on indicator configuration, comprising the following steps: S1. Obtain the raw simulation data output by at least one scenario simulation tool, perform field mapping and unit conversion on the raw simulation data through the tool adapter, generate standardized data, and write the standardized data into the unified data interface bus; S2. Obtain the indicator configuration file corresponding to the target indicator. The indicator configuration file includes at least the input requirements, calculation entry point and output format. The input requirements describe the data fields required by the target indicator. The calculation entry point describes the acquisition path of the calculation logic of the target indicator. The output format describes the output structure of the calculation result of the target indicator. S3. Based on the input requirements in the simulation analysis task and indicator configuration file, filter and distribute the standardized data in the unified data interface bus to generate the input data package corresponding to the target indicator; the simulation analysis task includes at least the simulation scenario to be analyzed, the vehicle under test, the simulation time range, and the set of target indicators; the filtering and distribution includes at least extracting data from the unified data interface bus according to the data theme and object identifier; S4. Based on the calculation entry in the indicator configuration file, determine the calculation logic that accurately corresponds to the target indicator, and use the calculation logic to process the input data packet to obtain the original calculation result of the target indicator. S5. Based on the output format in the indicator configuration file, encapsulate the original calculation results and output the encapsulated indicator results.

[0022] The core idea of ​​this invention is to decouple the definition, data acquisition, calculation, and result display of autonomous driving simulation indicators through a configuration-driven approach, so that the entire analysis process no longer depends on specific simulation tool types and hard-coded implementations of indicators. To achieve this, this invention constructs a complete technical solution from data access to result output.

[0023] For ease of technical understanding, such as Figure 1 As shown, the overall implementation process of the present invention can be divided into five sequentially connected stages.

[0024] The first phase is the data access and standardization phase. This phase is responsible for interfacing with different scenario simulation tools, converting their heterogeneous raw data into a unified, standardized data format within the system through tool adapters, and storing it in a unified data interface bus. This phase resolves the issue of data structure differences between different simulation tools, ensuring that subsequent processing stages are no longer concerned with the source tool of the data.

[0025] The second stage is the indicator configuration reading and parsing stage. This stage reads the indicator configuration file corresponding to the target indicator and parses out information such as the indicator's input requirements, calculation entry point, output format, visualization configuration, and adjustable parameters. This stage is the basis for all subsequent operations; that is, the system executes whatever is declared in the configuration file.

[0026] The third stage is the data filtering, distribution, and input data packet generation stage. This stage builds upon the input requirements parsed in the second stage, combining them with the current simulation analysis task (such as scenario type, time range, target object, etc.) to precisely filter and distribute the standardized data in the unified data interface bus, automatically generating the input data packets required for each indicator. This stage automates data acquisition, eliminating the traditional method of manually specifying fields.

[0027] The fourth stage is the determination and execution stage of the indicator calculation logic. Based on the calculation entry point in the configuration file, this stage determines how to obtain the calculation logic. If a preset calculation file exists, it is called directly; if it is a newly added indicator, executable code is generated through structured semantic rules to generate the link. Then, the input data packet is calculated to obtain the original indicator result.

[0028] The fifth stage is the result encapsulation, visualization, and parameter analysis stage. In this stage, the calculation results are uniformly encapsulated according to the output format declared in the configuration file, and charts are automatically rendered according to the visualization configuration. At the same time, it supports users to interactively adjust adjustable parameters and perform batch sensitivity analysis.

[0029] The five stages described above are interconnected, with the output of the previous stage becoming the input of the next. The specific implementation methods for each stage are described in detail below with reference to the accompanying drawings.

[0030] Phase 1: Data Access and Standardization Processing for Simulation Tools The purpose of this stage is to shield the data format differences between simulation tools for different scenarios, providing a unified data access interface for upper-level indicator calculations. For example... Figure 2 As shown, the data access and standardization process for simulation tools includes the following steps.

[0031] First, it's important to note that the raw data output by different scenario simulation tools (such as CarSim, VTD, Prescan, or self-developed tools) often differs significantly in field naming, data units, coordinate system definitions, and timestamp representation. For example, tool A uses "x" to represent vertical position, while tool B uses "pos_x"; tool A uses "km / h" to represent speed, while tool B uses "m / s". Without masking these differences, each subsequent index calculation module would require different data reading logic for different simulation tools, making the system difficult to expand and maintain. Therefore, this invention designs a tool adapter to handle data conversion.

[0032] S11: Obtain the raw data output by the simulation tool.

[0033] The tool adapter acquires the raw data output by the scene simulation tool. The scene simulation tool can be an autonomous driving simulation tool, traffic flow simulation tool, vehicle dynamics simulation tool, sensor simulation tool, or a self-developed scene simulation tool. This invention does not limit the specific type of simulation tool; its key point is that different scene simulation tools can all be integrated into the subsequent analysis process through a unified tool adaptation mechanism.

[0034] Raw data can originate from the simulation tool's real-time interface, offline simulation files, message queues, log files, databases, or data callback interfaces during simulation execution. The raw data output by the scenario simulation tool can include vehicle status data, road structure data, traffic participant data, traffic signal data, trajectory data, collision event data, sensor data, and simulation time data, etc.

[0035] Since the above data has not been uniformly processed, its field names, data units, coordinate systems, time expression methods, and object identification methods may differ depending on the simulation tool. Therefore, the data output in this step cannot be directly called by the indicator manager, but is used as input for subsequent field mapping, unit conversion, coordinate conversion, and time synchronization processing.

[0036] S12: Parse the fields and establish field mapping relationships.

[0037] After obtaining the raw data, the tool adapter parses the fields of the raw data and establishes a correspondence between the raw fields and the standard fields according to the preset mapping relationship. Specifically: In one embodiment, the field representing the lateral coordinates of a vehicle in one simulation tool may be 'x', while in another simulation tool it may be 'pos_x' or 'location_x'. The tool adapter maps these fields uniformly to the standard field 'position_x'. The field mapping relationship can be pre-stored in the tool adaptation configuration file, or it can be stored in a database, interface description file, or other configuration files that can be read by the system.

[0038] The purpose of field mapping is to unify the semantics of data from different simulation tools, avoiding the need to write separate field reading logic for different simulation tools in the index calculation files. After completing field mapping, all data has achieved uniformity at the field name level, but further processing is still needed to address differences in units and coordinate systems.

[0039] S13: Perform unit conversion, coordinate conversion and time synchronization.

[0040] After completing the field mapping, the tool adapter further performs unit conversion, coordinate transformation, and time synchronization on the data. The purpose of these three operations is to ensure the consistency and comparability of data from different tools in terms of units, spatial references, and time references.

[0041] In one embodiment, unit conversion is used to ensure that the same field has consistent dimensions and units across different simulation tools. Velocity is standardized to m / s, distance to m, time to s, and angle to rad or degree; the tool adapter performs the conversion according to preset conversion relationships.

[0042] Coordinate transformation is used to convert local coordinates, map coordinates, vehicle coordinates, or world coordinates used by different simulation tools into a unified coordinate expression form for the system.

[0043] Time synchronization is used to align data from different sources to a unified simulation time or a unified time window. For the first... A simulation tool, which at simulation time The original output data can be represented as:

[0044] in, Indicates the first A simulation tool at time The original simulation data output. This represents vehicle status data. Represents road structure data, Represents traffic participant data, This represents simulation event data.

[0045] If the timestamps of the two input data are respectively and The maximum allowable time synchronization error for the indicator is Then the time synchronization condition can be expressed as:

[0046] When the time error meets the above conditions, the system considers the corresponding data suitable for the same metric calculation. If the time error does not meet the conditions, the system may perform time interpolation, nearest neighbor matching, wait for data supplementation, or return a time synchronization error message. Through time synchronization processing, the system ensures that information from different data sources is aligned in the time dimension, thereby avoiding metric calculation errors caused by time misalignment.

[0047] S14: Generate standardized data structures.

[0048] The tool adapter organizes the data, after field mapping, unit conversion, coordinate transformation, and time synchronization, into a standardized data structure. This structure includes at least object identifier, timestamp, field name, field value, data unit, and coordinate system information.

[0049] A standardized data structure can be represented as:

[0050] in, Represents the object identifier. Represents data timestamps, Indicates the field name. Indicates the field value. Indicates the unit of data. Represents coordinate system information.

[0051] The above data, after being fully converted by the corresponding simulation tool adapter, forms standardized data:

[0052] in, This indicates that the unified data interface bus is at time... Standardized data that is saved Indicates the first Data conversion functions corresponding to each simulation tool This indicates the interface conversion configuration corresponding to the simulation tool, including field mapping relationships, coordinate system conversion relationships, unit conversion relationships, and time synchronization rules.

[0053] Through this standardized data structure, the system can manage data from different simulation tools in a unified manner, and provide a unified data foundation for subsequent data matching, field validation and indicator calculation in the indicator manager.

[0054] S15: Publish standardized data to the unified data interface bus.

[0055] The tool adapter publishes standardized data to the unified data interface bus. The unified data interface bus can organize data according to data themes, including vehicle status, road structure, traffic participants, traffic signals, trajectory data, simulation events, sensor data, and simulation time. Each type of data uses a unified structure description, including at least object identifier, timestamp, field name, field value, data unit, and coordinate system information.

[0056] After this step is completed, the raw data of the simulation tool and the indicator calculation module are no longer directly coupled. The indicator manager only needs to access the unified data interface bus to obtain data that meets the indicator input requirements. Therefore, when a new simulation tool needs to be connected, only an adapter configuration needs to be added to that tool, and the subsequent indicator calculation module does not require any changes.

[0057] Phase Two: Indicator Configuration Reading and Analysis After completing the standardized data access, the next step is to address the issues of indicator access, scheduling, and execution. This invention declares all operational requirements for each indicator in a separate configuration file, which automatically handles data matching, calculation calls, and result output, rather than hard-coding the indicator logic into the main system program.

[0058] like Figure 3 As shown, the indicator configuration file parsing and indicator manager scheduling process includes the following steps executed sequentially. These steps take over the standardized data bus output from the first stage and, based on this, complete the transformation from indicator definition to indicator result.

[0059] S21: Read the indicator configuration file.

[0060] First, the indicator manager reads the indicator configuration file corresponding to the target indicator. The indicator configuration file is the basis for the operation of the indicator access system. It is not only a static description of the data, but also a dynamic set of instructions that drives the system to acquire data, perform calculations, and display results.

[0061] In this invention, each indicator can have its own independent configuration file. When a new indicator needs to be added, simply add the corresponding indicator configuration to the specified directory. The indicator manager will automatically recognize the indicator during system startup or dynamic scanning, without requiring any modification to the main system program. This means that the indicator access method has changed from traditional hard coding to configuration-driven, thus giving the indicator system excellent scalability and maintainability.

[0062] S22: Parse input requirements, calculation entry points, output format, and adjustable parameters.

[0063] The indicator manager parses the input requirements, calculation entry points, output formats, and adjustable parameters in the indicator configuration file.

[0064] For the Each indicator, and its indicator configuration file can be represented as follows:

[0065] in, Indicates the first The indicator configuration file for each indicator; This indicates the input requirements for the metrics, including the required data subject, field name, field type, time window, and object matching rules; This indicates the output format of the indicator, including output fields, output units, output data structure, and risk level mapping method; This indicates the entry point for metric calculation, including the location of the calculation file, function name, calling method, and dependent files; This indicates the visualization configuration, including chart type, horizontal axis field, vertical axis field, spatial coordinate field, color mapping field, and layer field; This represents a set of adjustable parameters, including parameter name, default value, value range, step size, and constraints. This indicates the dependency relationship between sub-indicators, used to describe the calling relationship between the current indicator and other sub-indicators.

[0066] Phase 3: Data filtering and sorting, and input data packet generation S23: Match and verify the indicator input data from the unified data interface bus, and perform bus filtering and routing.

[0067] The indicator manager is based on the input requirements in the indicator configuration file. The system matches the input data from the unified data interface bus. However, the bus stores a full and continuous simulation data stream. To extract data directly from it, it is necessary to first confirm whether the required fields are available before precise filtering can be performed.

[0068] Therefore, the indicator manager first needs to determine whether the bus currently has the basic data conditions required by the indicator. Specifically: If the unified data interface bus can provide the following set of data fields at the current moment: The required field set for the indicator is The indicator manager first performs a field existence check:

[0069] If this condition is not met, the indicator manager will return information indicating a missing field or wait for data to be supplemented, and will not perform any further operations. This judgment is an admission condition, the purpose of which is to avoid unnecessary and invalid operations at the very beginning.

[0070] After the field existence check passes, the indicator manager further combines the simulation analysis task and indicator configuration file to filter and distribute the continuous simulation data in the unified data interface bus. Filtering and distribution refers to the system selecting data that meets the indicator calculation requirements from the unified data interface bus according to the data theme, object identifier, time window, sampling frequency, and event triggering conditions required by the target indicator, and then distributing the filtered data to the corresponding indicator execution channel.

[0071] The above bus data filtering and distribution process can be represented as:

[0072] in, Indicators At any moment The input data packet, This represents standardized simulation data within the unified data interface bus. This represents the simulation analysis task. This indicates the indicator configuration file. This represents the bus data filtering and distribution function.

[0073] Furthermore, the bus data filtering and splitting function can be expressed as:

[0074] in, The data topics required to represent the target indicators may include one or more of the following: vehicle status, road structure, traffic participants, traffic signals, trajectory data, simulation events, sensor data, and simulation time. This indicates the constraints on the objects involved in the target indicators, including the vehicle being measured, the target vehicle, pedestrians, non-motorized vehicles, or other traffic participants; Indicates the time window corresponding to the target indicator; This indicates the event triggering conditions, including event conditions such as collision, cutting in, following, crossing the line, running a red light, sudden deceleration, or approaching a target; This indicates the data sampling frequency required to represent the target indicator.

[0075] Through the above filtering and distribution process, the system can automatically determine the input data required for each indicator from the continuous simulation data stream, without requiring manual specification of the data source for each field. For different indicators with the same or partially the same input requirements, the indicator manager can reuse the filtered data and distribute the same input data package to multiple indicator execution channels. For different indicators with different input requirements, the indicator manager constructs corresponding input data packages based on the configuration files of each indicator.

[0076] In one embodiment, before generating the indicator input data package, the indicator manager can also perform field integrity, unit consistency, time synchronization, and object matching checks on the filtered data. Field integrity checks determine whether all required fields for the target indicator are present (unlike the previous existence check, this checks whether the data for a field is complete and free of missing values ​​within a specific time window); unit consistency checks determine whether the data units meet the indicator calculation requirements; time synchronization checks determine whether multiple input data points are at the same simulation moment or within the same time window; and object matching checks determine whether the correspondence between the tested vehicle, target vehicle, traffic participant, road unit, or event object is correct.

[0077] It should be noted that the difference between the above-mentioned validation and the field existence check before filtering and sorting is that the former checks the basic condition of whether the field exists; the latter checks whether the filtered data meets the requirements in terms of quality and semantics. Although both validations include the phrase "field integrity," their granularity differs. The former only checks whether the field exists on the bus, while the latter requires that the filtered data is not missing within a specific time window.

[0078] Once all the above checks pass, the indicator manager will organize the filtered data into a standardized indicator input data package. This data is then passed to subsequent indicator calculation files, structured semantic rule execution plans, or sub-indicator calculation files. In this way, the input data for the target indicator is automatically determined by both the simulation analysis task and the indicator configuration file, realizing a complete process of data filtering, distribution, and indicator input generation within a unified data interface bus.

[0079] Phase 4: Determining and Executing the Calculation Logic S24: Call the indicator calculation file or sub-indicator file.

[0080] After completing data filtering and distribution and generating input data packets, the indicator manager needs to perform calculations based on the configuration file. To perform indicator calculations.

[0081] First, the indicator manager checks the calculation entries in the configuration file. This determines whether the calculation file for the indicator has been pre-set in the system.

[0082] For metrics with pre-configured calculation files in the system, the metric manager further examines the sub-metric dependencies in the configuration file. : like If empty, it means that the indicator is a basic indicator, that is, an indicator that does not depend on any sub-indicators and can be calculated independently from the bus data, such as "vehicle instantaneous speed", "root mean square value of acceleration", "time to collision (TTC)" etc. The indicator manager directly calls the calculation file corresponding to the indicator and passes in the input data packet. and current parameters The indicator calculation file can be a local script file, function module, dynamic link library, service interface, or other callable calculation unit. The indicator calculation process can be represented as follows:

[0083] in, Indicators At any moment The calculation results This refers to the indicator calculation function declared in the indicator configuration file. This indicates the set of parameters currently used for this indicator.

[0084] like If the value is not empty, it indicates that the indicator is a composite indicator, meaning it is a combination of multiple sub-indicators. The indicator manager first iterates through these sub-indicators. All sub-indicator identifiers recursively execute processes S23 to S24, that is, complete the data filtering, distribution, calculation, and call for each sub-indicator to obtain the results of each sub-indicator. .

[0085] After all sub-indicators have been calculated, the indicator manager takes the set of sub-indicator results as input, calls the fusion calculation file of the current comprehensive indicator, and completes the calculation of the comprehensive indicator.

[0086] in, This represents the comprehensive index results. This represents the comprehensive evaluation function. This indicates the weight or fusion parameter corresponding to each sub-indicator.

[0087] In one embodiment, the comprehensive indicator is the comprehensive risk score, which is configured in the comprehensive risk score configuration file. It includes three sub-indicators: collision risk, line crossing frequency, and number of sudden decelerations. When the indicator manager executes this comprehensive indicator, it first calls the calculation files of the three sub-indicators to obtain their respective scores, and then calls the fusion function of the comprehensive risk score to sum the results of the three sub-indicators according to certain weights to obtain the final comprehensive score.

[0088] This step enables the system to support both the independent operation of individual basic indicators and the combination of multiple sub-indicators to form a comprehensive indicator. For sub-indicators with different dimensions, the system can perform normalization processing before fusion; for sub-indicators with different risk attributes, the system can use methods such as forward normalization, reverse normalization, hierarchical mapping, or rule mapping for unified expression.

[0089] For new indicators that do not yet have pre-set calculation files, regardless of whether the indicator is a basic indicator or a comprehensive indicator, Without pointing to any pre-set calculation file, the system proceeds to the structured semantic rule generation chain from S31 to S38. This chain generates structured semantic rules from a large model, matches interfaces and operators, performs validation, assembles templates to generate code, tests, and performs semantic backchecks, ultimately producing executable indicator code. Once a new indicator is generated, the system registers it in the indicator library, and subsequent calls to it will treat it as an indicator from a pre-set calculation file.

[0090] As described above, the basic / comprehensive indicators and the preset / new indicators are two independent dimensions. Any combination may appear in practical applications, and the system can handle them correctly.

[0091] Phase 5: Results Encapsulation, Visualization, and Parameter Analysis S25: Encapsulate the index results according to the output format.

[0092] The system outputs according to the output format specified in the indicator configuration file. The calculation results of the indicators are encapsulated. The encapsulated content may include indicator name, calculation time, indicator value, data unit, object identifier, risk level, spatial location, statistical value, event marker or comprehensive score, etc.

[0093] By encapsulating results in a unified manner, the output results of different indicators have a consistent data structure. This enables subsequent visualization modules, parameter analysis modules, and external system calls to process all indicator results in a unified way, without the need to write separate parsing logic for each indicator.

[0094] S26: Display, batch calculate, and perform sensitivity analysis based on visualization configuration and adjustable parameters.

[0095] After encapsulation, the system uses the visual configuration in the indicator configuration file. Output the indicator results to the corresponding visualization component. Visualization configurations can include chart type, horizontal axis field, vertical axis field, spatial coordinate field, color mapping field, and layer field, specifically: When the visualization type is a line chart, the system reads the horizontal axis and vertical axis fields and maps the indicator output data to line chart data; when the visualization type is a planar trajectory map, the system reads the spatial coordinate field and object identifier field and overlays the indicator results onto the scene planar map; when the visualization type is a heat map, the system reads the spatial coordinate field and intensity field and maps the indicator results to spatial distribution results.

[0096] Meanwhile, the system is configured according to adjustable parameters. Supports parameter adjustment, batch parameter calculation, and sensitivity analysis. Set indicators. The set of adjustable parameters is as follows:

[0097] in, Indicators A set of adjustable parameters Indicates the first There are 10 adjustable parameters. Each parameter has a corresponding default value, minimum value, maximum value, step size, and constraint conditions in the indicator configuration file.

[0098] When the user adjusts the parameters, the indicator manager passes the new parameter values ​​to the indicator calculation function, re-executes the calculation in step S24, and updates the visualization results.

[0099] The system can also generate multiple sets of parameter combinations based on the parameter range and step size:

[0100] in, Represents a set of parameter combinations. Indicates the first Parameter combinations. The system performs index calculations for each parameter combination, establishing a correspondence between the parameter combination and the index output results.

[0101] For each parameter combination, index calculations are performed separately to establish a correspondence between the parameter combinations and the output results. Sensitivity analysis is then conducted based on this. For the... The local sensitivity of a parameter can be expressed as:

[0102] in, Indicates the first The sensitivity of each parameter to the indicator output. This indicates the amount of perturbation to the parameter. The system can sort parameters based on their sensitivity values ​​to help users identify key parameters, recommend parameter ranges, or determine parameter adjustment priorities. It should be noted that this invention does not limit sensitivity analysis to the aforementioned local perturbation method; analysis of variance, correlation analysis, global sensitivity analysis, or other methods that can reflect the degree of influence of parameter changes on the indicator output can also be used.

[0103] In one embodiment, S23 to S24 describe the execution flow of a single indicator. In practical applications, simulation analysis tasks often involve multiple target indicators simultaneously, and these indicators may have different dependencies and overlapping input data. In this case, if each indicator independently reads data from the bus and queues for calculation independently, it will lead to redundant data retrieval and wasted computing resources, reducing overall analysis efficiency.

[0104] Therefore, in a preferred embodiment, the system performs serial-parallel scheduling based on the dependencies between indicators, the sharing of input data, and the combination of parameters. This scheduling strategy is dynamically applied during the execution of S23 and S24, without changing the basic logic of the aforementioned steps, but rather optimizing the task execution order and resource allocation in multi-indicator scenarios.

[0105] Specifically, the system first determines the sub-indicator dependencies based on the configuration files for each indicator. The processing logic diagram of the structured indicator semantic rules and the input requirements of each indicator. Based on the overlapping relationships between them, construct an indicator execution graph:

[0106] Where G represents the indicator execution graph, N represents the set of indicator nodes, sub-indicator nodes, or tool calculation sub-nodes, and E represents the data dependencies between nodes.

[0107] Based on this execution graph, the system makes the following scheduling decisions: (i) Parallel Execution Strategy. If there is no direct or indirect data dependency between two indicator nodes, and their respective input data packets have been prepared by the filtering and distribution module in S23, the system will divide the computation tasks of these two nodes into parallel executable tasks and allocate them to different computing units for simultaneous execution. For example, indicator A calculates collision risk, and indicator B calculates line crossing frequency; since they are independent of each other, they can be computed in parallel.

[0108] (ii) Serial execution strategy. If a comprehensive indicator depends on the results of multiple sub-indicators (i.e., those in its configuration file)... If the result is not empty, the system will execute the calculation tasks of each sub-indicator according to the topological order of the indicator execution graph. After all sub-indicators are completed, the fusion calculation of the main indicator will be executed. This strategy is consistent with the comprehensive indicator execution logic described in S24, that is, in terms of execution order, sub-indicators take precedence over main indicators, and preceding nodes take precedence over following nodes.

[0109] (III) Input Data Reuse Strategy. If multiple indicator nodes have input requirements... If there is data overlap, such as multiple indicators requiring the vehicle's speed and location data within the same time period, the system will only filter the data from the bus once during the filtering and distribution phase in S23. Then, the input data packet is reused and distributed to multiple indicator execution channels. This reuse mechanism avoids repeated data retrieval and conversion, significantly reducing bus read counts and data conversion overhead in multi-indicator scenarios.

[0110] (iv) Scheduling strategy for batch parameter calculation. For calculations involving adjustable parameters... The system automatically generates multiple parameter combinations based on the parameter value range and step size declared in the configuration file. Each parameter combination corresponds to an independent computation task. These tasks typically do not have data dependencies because the input data packets are the same, only the parameters differ. Therefore, the system allocates the computation tasks corresponding to different parameter combinations to different computing units for parallel execution, thereby significantly reducing the total time spent on batch parameter computation.

[0111] Based on the aforementioned S23 and S24, the above scheduling strategy further supports the optimization of computing resources in scenarios with multiple indicators, multiple sub-indicators, multiple tool operators, and multiple parameter combinations, thereby improving the overall execution efficiency of autonomous driving simulation analysis.

[0112] Example 2 As before, when When no pre-set calculation file is pointed to (i.e., a newly added indicator scenario), the system needs to generate executable indicator code by generating links through structured semantic rules. The technical solution disclosed in this embodiment is a complete expansion of the specific implementation method in the case of a newly added indicator in S24 where no pre-set calculation file has been provided.

[0113] Combination Figure 4 As shown, the overall logic of the entire generation chain is as follows: The large model is constrained through an interface list and an operator list, causing it to output only structured rule descriptions and logic diagrams. Then, the system generates the final code based on these validated rules using templates, rather than having the large model directly write the final code. This design leverages the semantic understanding capabilities of the large model while ensuring the controllability and reliability of the generated results, and includes the following steps: S31: Constructing the Interface and Operator List In one embodiment, the system first generates an interface list from the unified data interface bus. The interface list is used to define the input fields that large models can use, preventing large models from generating non-existent objects or states out of thin air.

[0114]

[0115] The system also generates an operator list from the tool operator library. The operator list is used to limit the processing components that large models can call.

[0116]

[0117] The system can continuously accumulate tool components during operation. Event judgment code, spatial calculation code, time window extraction code, statistical code, and result encapsulation code, after being manually confirmed or verified by sample testing, can be registered in the tool operator library to form reusable tools.

[0118] S32: Generate parsing prompt words The system combines three types of information into prompts: a description of the natural language indicators entered by the user; a list of data bus interfaces; and a list of tool operator libraries.

[0119] The prompts require the large model to complete two tasks: First, output structured semantic rules in JSON format. Second, output a processing logic graph in node-edge form.

[0120] Prompt words should have the following explicit constraints:

[0121] S33: Generating Semantic Rules The system generates structured indicator semantic rules based on the natural language description of the newly added indicators, the data bus interface list, and the tool operator library list. These structured indicator semantic rules are not final code, but rather intermediate rules used to describe the indicator's calculation object, input fields, event window, calculation logic, decision conditions, statistical methods, and output results.

[0122] Structured metric semantic rules should include at least the following fields:

[0123] S34: Matching Data Interface and Tool Operators For the input status fields in the structured rules, the system matches them with the data bus interface list to obtain the corresponding data interface identifier. For example, "vehicle speed" is matched to the vehicle speed interface, "target vehicle position" is matched to the target vehicle position interface, and "simulation time" is matched to the simulation time interface.

[0124] For the event semantics, calculation logic, statistical methods, and judgment conditions in the structured rules, the system matches them with the tool operator library list to obtain the corresponding operator identifier and code storage location. Specifically: "follow-the-carriage event" is matched to the follow-the-carriage judgment operator, "TTC calculation" is matched to the TTC calculation operator, "minimum value statistics" is matched to the minimum value statistics calculation operator, and "below the threshold" is matched to the threshold judgment operator.

[0125] The matching results must include at least semantic fields, matching interfaces or operators, matching methods, matching confidence levels, and matching status. If there are unmatchable input fields, object relationships, or tool operators, or if the matching confidence level is lower than a preset threshold, the system generates a list of missing items and initiates a manual verification process. After manual confirmation, missing interfaces, missing operators, or alias mapping relationships can be added and updated to the interface list or tool operator library.

[0126] The tool operator library can be continuously updated during system operation. For event judgment code, spatial calculation code, time window extraction code, indicator calculation code, statistical code, and result encapsulation code that have been manually confirmed or verified through sample scenario testing, the system can register them as reusable tool components for subsequent use in the process of generating new indicators.

[0127] S35: Verify structured rules and processing logic diagrams The system validates the semantic rules and processing logic diagrams of structured indicators based on the input and output requirements of the tool operators. Validation includes at least field completeness, object validity, unit consistency, event validity, time window validity, operator callability, and node connectivity.

[0128] For each node in the processing logic diagram, the system checks whether the input required by the node has been provided by the preceding node or data interface, whether the output of the node can be received by the subsequent node, and whether the final output field is consistent with the user's original indicator description.

[0129] If missing input exists, the system will prioritize completion based on the default configuration rules. Specifically: if the user has not specified the TTC threshold, the system will read the indicator configuration file or the system's default threshold; if the user has not specified the statistical time window, the system will use the time range or event window in the simulation analysis task; if the user has not specified the subject object, the system will default to using the tested vehicle object. If the missing item cannot be completed using the default rules, the missing item will be output and the system will proceed to the manual verification process.

[0130] S36: Generating executable code based on template assembly After the structured indicator semantic rules, processing logic diagram, interface matching results, and operator matching results have all passed verification, the system generates executable code for the newly added indicator. In this step, the system does not allow large models to freely write indicator code without constraints. Instead, it takes the determined rules, interfaces, operators, and code templates as input, and the code generation module completes the template assembly and interface adaptation.

[0131] Specifically, the input to the code generation module includes at least: (1) Complete structured indicator semantic rules, used to limit indicator objects, input states, event windows, calculation logic, judgment conditions, statistical methods and output fields; (2) Processing logic diagram, used to define the execution order, data transfer relationship and conditional branch relationship of each processing node; (3) Matched data interface identifiers, used to determine which fields the code reads from the unified data interface bus; (4) The matched tool operator identifier and operator code storage location are used to determine which verified tool components the code calls; (5) Code parsing template, used to limit the code structure, including data reading segment, input validation segment, operator call segment, conditional branch segment, statistical calculation segment and result encapsulation segment; (6) Output format requirements, which are used to limit the final output fields, field units, result structure and exception return form.

[0132] In this step, the code generation module does not reinterpret the user's natural language metric description, nor does it redesign the metric algorithm. Instead, based on the already verified processing logic diagram, it fills the data interface calls and tool operator calls into the corresponding positions in the code template to form runnable metric code.

[0133] S37: Test Runnable Code The system extracts sample scenarios from the scenario library and connects them with corresponding simulation data to test the generated executable performance plan or runnable code. The test content includes at least syntax checking, interface call checking, operator input / output checking, result format checking, and typical scenario rationality checking.

[0134] If any issues arise during testing, such as missing interfaces, operator call errors, inconsistent inputs and outputs, code syntax errors, or abnormal results, the system will input the error information and context into the programming agent or code repair module for correction. If the test still fails after a preset number of rounds (N) of repairs, the system will summarize the error information and suspected causes and initiate a manual verification process.

[0135] S38: Semantic back-check and output results After the executable metric plan or runnable code passes the sample scenario test, the system calls the large model again to perform a semantic summary of the final execution logic. The summary includes the actual objects used, input states, event windows, calculation logic, decision conditions, statistical methods, and output results.

[0136] The system will compare the summarized results with the user's initial natural language indicator description. If they match, the system will output the final executable indicator plan or runnable code and register it in the indicator configuration file or indicator library; if they do not match, the system will output a difference explanation and initiate a manual verification process.

[0137] Example 3 like Figure 5 As shown, this invention provides an autonomous driving simulation index generation system based on index configuration, used to execute the above-described autonomous driving simulation index generation method, including: A tool adapter is used to acquire raw simulation data output by at least one scenario simulation tool, perform field mapping and unit conversion on the raw simulation data, and generate standardized data. A unified data interface bus, connected to a tool adapter, is used to receive and store standardized data; The indicator manager connects to the unified data interface bus and is configured to execute any of the methods mentioned above.

[0138] Furthermore, the indicator manager includes: The indicator configuration parsing module is used to read and parse the input requirements, calculation entry points, and output formats in the indicator configuration file; The bus filtering and distribution module, connected to the unified data interface bus and the indicator configuration parsing module, is used to filter and distribute standardized data according to the simulation analysis task and input requirements, and generate input data packets. The indicator execution module, connected to the bus filtering and distribution module and the indicator configuration parsing module, is used to determine the calculation logic based on the calculation entry point and to process the input data packet using the calculation logic to obtain the original calculation result. The result encapsulation module, connected to the indicator execution module and the indicator configuration parsing module, is used to encapsulate the original calculation results according to the output format.

[0139] For implementation details not described in detail in the above system embodiments, please refer to the relevant descriptions in the foregoing method embodiments, which will not be repeated here.

[0140] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0141] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0142] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for generating autonomous driving simulation indicators based on indicator configuration, characterized in that, Includes the following steps: S1. Obtain raw simulation data output by at least one scene simulation tool, perform field mapping and unit conversion on the raw simulation data through a tool adapter to generate standardized data, and write the standardized data into a unified data interface bus; S2. Obtain the indicator configuration file corresponding to the target indicator. The indicator configuration file includes at least input requirements, calculation entry point and output format. The input requirements are used to describe the data fields required by the target indicator. The calculation entry point is used to describe the acquisition path of the calculation logic of the target indicator. The output format is used to describe the output structure of the calculation result of the target indicator. S3. Based on the simulation analysis task and the input requirements in the indicator configuration file, the standardized data in the unified data interface bus is filtered and distributed to generate the input data package corresponding to the target indicator; the simulation analysis task includes at least the simulation scenario to be analyzed, the vehicle under test, the simulation time range, and the target indicator set; the filtering and distribution includes at least extracting data from the unified data interface bus according to the data theme and object identifier; S4. Based on the calculation entry in the indicator configuration file, determine the calculation logic that accurately corresponds to the target indicator, and use the calculation logic to process the input data packet to obtain the original calculation result of the target indicator; S5. According to the output format in the indicator configuration file, encapsulate the original calculation result and output the encapsulated indicator result.

2. The method according to claim 1, characterized in that, In step S1, the field mapping includes converting the original field names in different scenario simulation tools into unified field names; the unit conversion includes converting the data units in different scenario simulation tools into unified data units. The tool adapter is also used to perform coordinate transformation and time synchronization processing on the original simulation data; The coordinate transformation is used to convert the local coordinates, map coordinates, or vehicle coordinates used by different scene simulation tools into a unified coordinate system; The time synchronization is used to align different data sources to the same simulation moment or the same time window.

3. The method according to claim 1, characterized in that, In step S3, the data topics include at least one of vehicle status topics, road structure topics, traffic participant topics, traffic signal topics, trajectory data topics, and simulation event topics; The filtering and triage are also performed according to at least one of the following methods: time window, sampling frequency, and event triggering conditions.

4. The method according to claim 1, characterized in that, In step S4, the determination method of the calculation logic includes: When the calculation entry in the indicator configuration file points to a preset calculation file, the preset calculation file is directly called as the calculation logic. When the calculation entry in the indicator configuration file does not point to a preset calculation file, the indicator description text input by the user is obtained, the indicator description text is converted into structured indicator semantic rules using a large model, the structured indicator semantic rules are validated for legality, and after the validation is passed, the structured indicator semantic rules are mapped to a preset simulation indicator tool operator library to generate an executable indicator plan composed of at least one event determination tool and / or statistical tool, which serves as the calculation logic.

5. The method according to claim 4, characterized in that, The validity verification includes at least one of the following: field validity verification, object validity verification, event validity verification, and tool callability verification. The event determination tool includes at least one of the following: collision determination tool, lane crossing determination tool, red light violation determination tool, lane cutting determination tool, and rapid deceleration determination tool; the statistical tool includes at least one of the following: maximum value statistical tool, minimum value statistical tool, mean statistical tool, variance statistical tool, and duration statistical tool.

6. The method according to claim 1, characterized in that, In step S3, when the input requirements of multiple target indicators overlap, data filtering is performed only once on the unified data interface bus, and the same input data packet obtained from the filtering is distributed to the execution channels corresponding to the multiple target indicators respectively.

7. The method according to claim 1, characterized in that, The indicator configuration file also includes a set of adjustable parameters, each of which has a value range and a step size. Multiple parameter combinations are generated based on the value range and step size of each adjustable parameter. Steps S4 and S5 are executed for each parameter combination to obtain batch calculation results. Based on the batch calculation results, a sensitivity analysis is performed on each adjustable parameter to determine the degree of influence of each adjustable parameter on the index calculation results. The adjustable parameters are sorted according to their sensitivity, and key parameters, recommended parameter ranges, or parameter adjustment priorities are determined based on the sorting results.

8. The method according to claim 1, characterized in that, When there are multiple target indicators, an indicator execution graph is constructed based on the data dependencies between the target indicators. The computational tasks corresponding to multiple target indicators that do not have data dependencies are assigned to different computing units for parallel execution, while the computational tasks corresponding to target indicators that have data dependencies are executed sequentially according to the topological order of the indicator execution graph.

9. The method according to claim 1, characterized in that, The indicator configuration file also includes visualization configuration, which includes at least one of chart type, horizontal axis field, vertical axis field, and spatial coordinate field; according to the visualization configuration, the encapsulated indicator results are rendered into corresponding visualization charts for display.

10. An autonomous driving simulation index generation system based on index configuration, used to execute the method as described in any one of claims 1-9, characterized in that, include: A tool adapter is used to acquire raw simulation data output by at least one scene simulation tool, perform field mapping and unit conversion on the raw simulation data, and generate standardized data. A unified data interface bus, connected to the tool adapter, is used to receive and store the standardized data; The indicator manager is connected to the unified data interface bus. The indicator manager includes: The indicator configuration parsing module is used to read and parse the indicator configuration file corresponding to the target indicator. The indicator configuration file includes at least the input requirements, calculation entry and output format. The bus filtering and distribution module is connected to the unified data interface bus and the indicator configuration parsing module. It is used to filter and distribute the standardized data in the unified data interface bus according to the input requirements in the simulation analysis task and the indicator configuration file, and generate the input data package corresponding to the target indicator. The simulation analysis task includes at least the simulation scenario to be analyzed, the vehicle under test, the simulation time range, and the target indicator set. The indicator execution module, connected to the bus filtering and distribution module and the indicator configuration parsing module, is used to determine the calculation logic that accurately corresponds to the target indicator based on the calculation entry in the indicator configuration file, and to process the input data packet using the calculation logic to obtain the original calculation result of the target indicator. The result encapsulation module is connected to the indicator execution module and the indicator configuration parsing module. It is used to encapsulate the original calculation result according to the output format in the indicator configuration file and output the encapsulated indicator result.

Images