A method and system for closed-loop debugging of vehicle functions and a computing device

Abstract

This invention provides a method for closed-loop debugging of vehicle functions. The method includes: acquiring and parsing engineering files of mass-production software and a vehicle reference model to obtain a first set of parsing results and a second set of parsing results; establishing a mapping relationship between mass-production software signals and vehicle reference model signals; generating a co-simulation interface layer based on the mapping relationship; driving the vehicle reference model to execute debugging tasks through the co-simulation interface layer; synchronously sending the same vehicle operating condition to two execution environments, and collecting a first output result and a second output result from the two execution environments; comparing the consistency of the two output results, and if a result deviation is detected, locating the source of the deviation based on the signal dependency relationship. According to the technical solution of this invention, the workload of manual interface configuration can be reduced, the efficiency of vehicle function debugging can be improved, the consistency between simulation results and actual operating results can be enhanced, the source of problems can be automatically located, and the problem analysis cycle can be shortened.

Description

Technical Field

[0001] This invention relates to the fields of vehicle electronic and electrical architecture, vehicle function debugging and simulation verification technology, and specifically to a method, system and computing device for closed-loop debugging of vehicle functions. Background Technology

[0002] With the development of vehicle electrification, intelligence, and software-defined vehicle technologies, vehicle control functions are typically accomplished collaboratively by multiple electronic control units, multiple software components, and multiple sensors and actuators. Mass production-grade software architectures achieve standardized development of vehicle software through software components, port interfaces, runtime entities, runtime environments, and basic software configurations. Vehicle reference models (such as MATLAB / Simulink) are widely used for control algorithm modeling, vehicle dynamics simulation, and functional logic verification.

[0003] During vehicle function development, engineers typically need to compare and debug the vehicle reference model with the mass production software to verify the consistency of functional logic, interface definitions, signal scaling, scheduling cycles, and calibration parameters. Existing methods often rely on manually establishing signal mappings, manually configuring test scripts, manually aligning simulation timing sequences, and judging the causes of differences based on experience. This approach suffers from problems such as a large workload for configuration, repetitive work, slow problem localization, and insufficient consistency verification.

[0004] Especially in vehicle functions such as torque control, thermal management, regenerative braking, vehicle mode management, and driver assistance control, the scheduling order of runnable entities, the read / write timing of runtime environment data interfaces, communication signal cycles, and calibration parameters within mass-production software engineering directly affect the functional output. If the vehicle reference model only runs according to the normal model step size without reflecting the scheduling semantics of mass-production software, the simulation results may have unexplainable deviations from the actual electronic control unit (ECU) operation results.

[0005] Furthermore, when the ECU output differs from the vehicle reference model's reference output, existing tools typically only provide waveform differences, failing to pinpoint whether the difference stems from interface mapping errors, data type or scaling errors, inconsistent runnable entity cycles, asynchronous calibration parameters, or functional logic discrepancies. Therefore, a closed-loop vehicle function debugging solution is needed that can automatically parse production-grade software engineering and vehicle reference models, automatically generate co-simulation interfaces, perform synchronous simulation according to production-grade software scheduling semantics, and automatically locate the cause of the differences.

[0006] Therefore, a technical solution is needed that can reduce the workload of manual interface configuration, improve the efficiency of vehicle function debugging, improve the consistency between simulation results and actual operation results, automatically locate the source of problems, and shorten the problem analysis cycle. Summary of the Invention

[0007] The present invention aims to provide a method, system and computing device for closed-loop debugging of vehicle functions, which can reduce the workload of manual interface configuration, improve the efficiency of vehicle function debugging, improve the consistency between simulation results and actual operation results, automatically locate the source of problems and shorten the problem analysis cycle.

[0008] According to one aspect of the present invention, a method for closed-loop debugging of vehicle functions is provided, the method comprising:

[0009] Obtain and parse the project files of the mass-production software to obtain the first set of parsing results;

[0010] The vehicle reference model is acquired and parsed to obtain the second set of parsing results.

[0011] Based on the first set of analytical results and the second set of analytical results, a mapping relationship between mass-production software signals and vehicle reference model signals is established.

[0012] Based on the mapping relationship, a co-simulation interface layer is generated;

[0013] Based on the mass production-level software task cycle and / or event triggering conditions, the vehicle reference model is driven to perform debugging tasks through the co-simulation interface layer.

[0014] The same vehicle operating condition is synchronously sent to the software execution environment of the mass production software and the vehicle reference model execution environment through the co-simulation interface layer, and the first output result and the second output result output in the two execution environments are collected.

[0015] The consistency of the first output result and the second output result is compared. If a deviation is detected, the source of the deviation is located based on the signal dependency relationship.

[0016] According to some embodiments, the first parsing result set includes the software components, port interfaces, data interfaces, task scheduling information of runnable entities, communication signals, read / write relationships of runtime environment data, and calibration parameters of the mass-production software;

[0017] The second set of analytical results includes the model input port, model output port, model sampling time, model parameters, and internal state variables.

[0018] According to some embodiments, based on the first set of parsing results and the second set of parsing results, a mapping relationship between mass-production-grade software signals and vehicle reference model signals is established, including:

[0019] The mass-production software signals and the vehicle reference model signals are normalized to remove naming prefixes, suffixes, and case differences; and / or

[0020] The mapping confidence score is calculated based on at least two items from each port's name, signal name and direction, data type, unit, and scaling factor in the first and second parsing result sets; and / or

[0021] If the mapping confidence level is greater than a first preset threshold, the mapping relationship is automatically confirmed; and / or

[0022] If the mapping confidence is greater than the second preset threshold and less than or equal to the first preset threshold, then the output is a candidate mapping relationship.

[0023] According to some embodiments, when multiple candidate mapping relationships exist, the candidate mapping relationships are sorted according to the software component to which the runnable entity belongs, the interface to which the port belongs, and the communication signal association relationship, and the sorting result is output as a verifiable mapping configuration.

[0024] According to some embodiments, the co-simulation interface layer includes a signal adapter, a data type converter, a scaling converter, a timestamp aligner, a virtual runtime environment data read / write interface, and a result acquisition interface.

[0025] The co-simulation interface layer is used to: handle the conversion between mass-production software data types and vehicle reference model data types; eliminate data type barriers between the software execution environment of the mass-production software and the execution environment of the vehicle reference model; convert signal values ​​according to the scaling factor in the signal definition of the mass-production software; synchronize the model simulation time with the task scheduling time of the mass-production software; simulate the communication behavior of the runtime environment data in the execution environment of the vehicle reference model; and be responsible for data capture and comparison preparation during the closed-loop debugging process.

[0026] According to some embodiments, based on the mass production software task cycle and / or event triggering conditions, the vehicle reference model is driven to perform debugging tasks through the co-simulation interface layer, including:

[0027] The operating system task cycle, the execution order of the runnable entities, and the model sampling time are converted into a co-simulation scheduling table;

[0028] The simulation time is advanced according to the co-simulation schedule. When the period of the runnable entity is N times the basic simulation step size of the model, the input sampling and output writing of the corresponding runnable entity are triggered once every N model steps.

[0029] According to some embodiments, the same vehicle operating condition is synchronously sent to the mass production software execution environment and the vehicle reference model execution environment through the co-simulation interface layer, and the first output result and the second output result output in the two execution environments are collected, including:

[0030] Historical data, model-in-the-loop test scripts, or playback data collected from actual vehicles are used as vehicle operating condition input data.

[0031] The vehicle operating condition input data is simultaneously injected into the sensor interface of the mass production software execution environment and the model input port through the co-simulation interface layer.

[0032] The output of the communication signal and the diagnostic status of the mass-production software execution environment are collected as the first output result, and the control output and the internal state variables of the vehicle reference model are collected as the second output result.

[0033] According to some embodiments, a consistency comparison is performed between the first output result and the second output result. If a result deviation is detected, the source of the deviation is located based on signal dependency, including:

[0034] The first output result and the second output result are time-aligned, and the consistency comparison of waveform phase and value is performed based on the simulation step size, timestamp or communication frame sequence number. The consistency comparison includes signal value deviation comparison, waveform phase deviation comparison, state machine state transition comparison, threshold trigger time comparison and diagnostic state comparison.

[0035] If a result deviation is detected, a signal dependency graph is constructed, and the earliest signal node with the deviation is determined by tracing back from the time when the output deviation occurred.

[0036] According to another aspect of the present invention, a system for closed-loop debugging of vehicle functions is provided, the system comprising:

[0037] The mass production software parsing module is used to acquire and parse the project files of mass production software to obtain the first parsing result set;

[0038] The vehicle reference model parsing module is used to acquire and parse the vehicle reference model to obtain a second parsing result set;

[0039] The signal mapping module is used to establish a mapping relationship between mass-production software signals and vehicle reference model signals based on the first set of parsing results and the second set of parsing results.

[0040] A co-simulation interface generation module is used to generate a co-simulation interface layer based on the mapping relationship;

[0041] The co-simulation scheduling module is used to drive the vehicle reference model to perform debugging tasks through the co-simulation interface layer according to the mass production software task cycle and / or event triggering conditions.

[0042] The result acquisition module is used to synchronously send the same vehicle operating condition to the software execution environment of the mass production software and the vehicle reference model execution environment through the co-simulation interface layer, and to acquire the first output result and the second output result output in the two execution environments;

[0043] The consistency analysis module is used to compare the consistency between the first output result and the second output result. If a result deviation is detected, the source of the deviation is located based on the signal dependency relationship.

[0044] According to another aspect of the present invention, a computing device is provided, comprising:

[0045] Processor; and

[0046] A memory that stores a computer program, which, when executed by the processor, implements the method as described in any of the preceding methods.

[0047] According to an embodiment of the present invention, a first set of analytical results and a second set of analytical results are obtained by parsing the engineering files of the mass-production software and the vehicle reference model. Based on the first and second sets of analytical results, a mapping relationship between the signals of the mass-production software and the signals of the vehicle reference model is established, and a co-simulation interface layer is generated based on this mapping relationship. According to the task cycle and / or event triggering conditions of the mass-production software, the vehicle reference model is driven to perform debugging tasks through the co-simulation interface layer. The same vehicle operating condition is synchronously sent to the software execution environment of the mass-production software and the execution environment of the vehicle reference model through the co-simulation interface layer, and the first and second output results output in the two execution environments are collected. Finally, the consistency of the first and second output results is compared. If a deviation is detected, the source of the deviation is located based on the signal dependency relationship. This invention can reduce the workload of manual interface configuration, improve the efficiency of vehicle function debugging, improve the consistency between simulation results and actual operating results, automatically locate the source of problems, and shorten the problem analysis cycle.

[0048] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit the invention. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below.

[0050] Figure 1 A flowchart illustrating a method for closed-loop commissioning of vehicle functions according to an example embodiment is shown.

[0051] Figure 2 A schematic diagram of the co-simulation interface layer according to an example embodiment is shown.

[0052] Figure 3 This diagram illustrates the architecture of the joint simulation of mass-production software and a vehicle reference model.

[0053] Figure 4 A schematic diagram of signal mapping and differential root localization is shown.

[0054] Figure 5 A schematic diagram of a system for closed-loop commissioning of vehicle functions according to an example embodiment is shown.

[0055] Figure 6 A block diagram of a computing device according to an exemplary embodiment is shown. Detailed Implementation

[0056] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that the invention will be thorough and complete, and the concept of the exemplary embodiments will be fully conveyed to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.

[0057] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a full understanding of embodiments of the invention. However, those skilled in the art will recognize that the technical solutions of the invention can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of the invention.

[0058] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0059] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0060] It should be understood that although the terms first, second, third, etc., may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one component from another. Therefore, the first component discussed below may be referred to as the second component without departing from the teachings of the present invention. As used herein, the term "and / or" includes all combinations of any one and more of the associated listed items.

[0061] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of exemplary embodiments, and the modules or processes in the drawings are not necessarily essential for implementing the present invention, and therefore cannot be used to limit the scope of protection of the present invention.

[0062] As the automotive industry accelerates its evolution towards the "new four modernizations" (electrification, connectivity, intelligence, and sharing), the modern automotive electronic and electrical architecture is undergoing profound changes. Under the trend of Software-Defined Vehicles (SDV), vehicle control functions are becoming increasingly complex, typically involving the collaborative work of multiple domain controllers, including powertrain, chassis control, body electronics, and driver assistance systems. In this development paradigm, AUTOSAR, a mass-production-grade software, serves as the industry-standard software architecture. Through layered design (application layer, runtime environment data, and basic software layer BSW), it decouples software components from the underlying hardware, becoming the mainstream choice for mass production code development. Meanwhile, MATLAB / Simulink, a vehicle reference model, remains the preferred tool for control strategy algorithm design and vehicle dynamics simulation due to its powerful graphical modeling capabilities.

[0063] In the actual development process of vehicle functions, in order to ensure a lossless transformation of control strategies from "algorithm models" to "mass production code," engineers typically need to conduct a large amount of comparative debugging work. This requires joint simulation or closed-loop testing of embedded software developed based on mass production-grade software architecture with the vehicle reference model to verify the consistency of functional logic, interface definitions, signal scaling factors, task scheduling cycles, and calibration parameters.

[0064] However, existing debugging and verification technologies face serious challenges in practical applications, mainly in the following aspects:

[0065] First, there are configuration barriers and efficiency bottlenecks in heterogeneous environments. Mass production software engineering and vehicle reference models belong to two completely different technological ecosystems. The former is based on C code, ARXML description files, and complex RTE (Runtime Environment Data) interaction mechanisms, while the latter is based on modular block diagrams and matrix operations. Existing methods often rely on engineers manually sorting out the correspondences of hundreds or thousands of signals and manually writing scripts for interface matching. This is not only extremely labor-intensive, but also highly susceptible to human error leading to incorrect or missing signal connections. The fixed-point numbers and complex scaling methods (CompuMethod) widely used in mass production software have a natural gap with the default floating-point operations of some vehicle reference models, making manual configuration of conversion rules time-consuming, labor-intensive, and difficult to maintain.

[0066] Second, simulation distortion caused by the lack of scheduling semantics. In timing-sensitive functions such as torque control, battery thermal management, regenerative braking, and vehicle mode management, the execution timing of the software directly determines the accuracy of the control results. Vehicle reference models typically operate based on fixed discrete sampling times, representing an idealized continuous or discrete system; however, production-grade software runs on a real-time operating system, subject to strict constraints such as task scheduling tables, interrupt priorities, Runnable mapping relationships, and RTE read / write mechanisms. If the co-simulation fails to reproduce the scheduling semantics of the production-grade software (e.g., failing to consider the synchronization mechanism of multi-rate tasks, or failing to simulate RTE data holding or update behavior), the simulation results will not reflect the actual operating characteristics of the ECU. This deviation introduced by "timing model inconsistency" is often misjudged as an algorithmic logic error, leading to a large amount of invalid troubleshooting.

[0067] Third, there are difficulties in attributing discrepancies and a lack of closed-loop verification. When the ECU output differs from the vehicle reference model output, existing toolchains typically only provide a visual comparison at the waveform level, lacking in-depth root cause analysis capabilities. Engineers struggle to quickly determine whether the source of the deviation is an interface mapping error, data type truncation, scaling factor misalignment, inconsistent calibration parameter versions, or data races caused by differences in Runnable scheduling order. The troubleshooting process often requires repeated jumps between the code and model layers, relying on experience for "guessing-the-muzzle" debugging, severely slowing down software iteration and problem closure efficiency.

[0068] In summary, existing technologies lack an automated closed-loop debugging solution capable of breaking down the heterogeneous barriers between mass-production software and vehicle reference models, automatically analyzing and establishing mappings, accurately reproducing the scheduling sequence of mass-production software, and intelligently locating the root causes of differences. Therefore, a new closed-loop debugging method and system for vehicle functions is urgently needed to solve the aforementioned problems of cumbersome configuration, simulation distortion, and difficulty in localization.

[0069] To address this, the present invention proposes a method and system for closed-loop debugging of vehicle functions, which can reduce the workload of manual interface configuration, improve the efficiency of vehicle function debugging, enhance the consistency between simulation results and actual operating results, automatically locate the source of problems, and shorten the problem analysis cycle.

[0070] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention.

[0071] Figure 1 A flowchart illustrating a method for closed-loop commissioning of vehicle functions according to an example embodiment is shown.

[0072] See Figure 1 In S101, the project files of the mass production software are acquired and parsed to obtain the first parsing result set.

[0073] According to some embodiments, the first parsing result set includes software components, port interfaces, data interfaces, task scheduling information of runnable entities, communication signals, read / write relationships of runtime environment data, and calibration parameters of mass-production software.

[0074] Specifically, the mass production-level software engineering files may include at least one of the following: ARXML configuration files, SWC description files, interface definition files, communication configuration files, OS (operating system) task configuration files, runtime environment data generation files, diagnostic configuration files, calibration description files, and compilation generation files.

[0075] According to some embodiments, production-grade software engineering files are parsed to obtain software components, ports, interfaces, data elements, communication signals, Runnable entities, Runnable trigger events, OS Tasks, RTE (Runtime Environment Data) read / write relationships, client service call relationships, and calibration parameters. The parsed results can be organized into a production-grade software engineering semantic model, which includes signal nodes, interface nodes, Runnable nodes, task nodes, calibration parameter nodes, and diagnostic nodes. These nodes are connected through read / write relationships, call relationships, periodic relationships, and dependency relationships.

[0076] In S103, the vehicle reference model is acquired and parsed to obtain the second parsing result set.

[0077] According to some embodiments, the second parsing result set includes model input port, model output port, model sampling time, model parameters, and internal state variables.

[0078] Specifically, the vehicle reference model is obtained, and the model's input ports, output ports, sampling time, model parameters, state variables, observation signals, subsystem hierarchical paths, and model callback scripts are parsed. The parsed results can be organized into a model semantic model.

[0079] In S105, a mapping relationship between mass-production software signals and vehicle reference model signals is established based on the first set of analytical results and the second set of analytical results.

[0080] According to some embodiments, the mass-production software signals and the vehicle reference model signals are normalized to remove naming prefixes, suffixes, and case differences. A mapping confidence score is calculated based on at least two items from each port's name, signal name and direction, data type, unit, and scaling factor in the first and second parsing result sets. If the mapping confidence score is greater than a first preset threshold, the mapping relationship is automatically confirmed; if the mapping confidence score is greater than a second preset threshold and less than or equal to the first preset threshold, a candidate mapping relationship is output.

[0081] Specifically, the mapping relationship between mass-production software signals and vehicle reference model signals can be determined by a combination of name matching, data type matching, unit matching, value range matching, interface direction matching, and context matching.

[0082] Before matching, the raw signal data from the ARXML configuration file and the stored simulation model format files of the vehicle reference model need to be cleaned and standardized preprocessed to eliminate interference from differences in naming conventions. Preprocessing includes name cleaning, data format unification, and feature vectorization. Based on the preprocessed features, a matching score between the production-grade software signals and the vehicle reference model signals is calculated from six dimensions: name similarity, data type matching, unit consistency, scaling factor matching, interface direction matching, and contextual association. The matching results from each dimension are then weighted and fused to calculate the mapping confidence of each pair of potential mapped signals.

[0083] Based on the calculated confidence level, a three-level judgment is performed using a first preset threshold and a second preset threshold. If the confidence level is greater than the first preset threshold, a mapping relationship is directly established in the background, generating a definite interface configuration file without manual intervention. If the confidence level is greater than the second preset threshold but less than or equal to the first preset threshold, the mapping relationship is marked as a "candidate mapping" and stored in the pending confirmation list. If the confidence level is less than or equal to the second preset threshold, it is considered as no match or an incorrect match, and is not displayed or marked as a disconnected signal.

[0084] According to some embodiments, when multiple candidate mapping relationships exist, the candidate mapping relationships are sorted according to the software component to which the Runnable belongs, the interface to which the port belongs, and the communication signal association relationship, and the sorting result is output as a verifiable mapping configuration.

[0085] Specifically, when multiple candidate mapping relationships exist, the following sorting strategies are implemented to assist human decision-making, including: context-priority sorting, which prioritizes the display of signals belonging to the same software component or the same interface cluster; communication association sorting, which prioritizes the display of signals that frequently appear in pairs in the communication matrix; and comprehensive score sorting, which arranges signals from high to low confidence.

[0086] In S107, a co-simulation interface layer is generated based on the mapping relationship.

[0087] According to some embodiments, the co-simulation interface layer synchronizes production-grade software calibration parameters, NVM default values, A2L calibration variables, or XCP online calibration parameters with the vehicle reference model working area parameters.

[0088] According to some embodiments, the co-simulation interface layer includes a signal adapter, a data type converter, a scaling converter, a timestamp aligner, a virtual RTE read / write interface, and a result acquisition interface. The co-simulation interface layer is used to handle the conversion between production-grade software data types and vehicle reference model data types; eliminate data type barriers between the software execution environment of the production-grade software and the execution environment of the vehicle reference model; convert signal values ​​according to the scaling coefficients in the signal definition of the production-grade software; synchronize model simulation time with the task scheduling time of the production-grade software; simulate the communication behavior of the RTE in the vehicle reference model execution environment; and be responsible for data capture and comparison preparation during closed-loop debugging.

[0089] According to some embodiments, the virtual runtime environment data interface is used to simulate at least one of the following interface behaviors in a vehicle reference model environment: RTE read (Rte_Read), RTE write (Rte_Write), RTE call (Rte_Call), RTE internal read (Rte_IRead), and RTE internal write (Rte_IWrite).

[0090] According to some embodiments, the mass production-grade software execution environment includes a software-in-the-loop execution environment, a hardware-in-the-loop execution environment, a real vehicle ECU execution environment, or a simulation execution environment built from RTE source code.

[0091] Figure 2 A schematic diagram of the co-simulation interface layer according to an example embodiment is shown.

[0092] See Figure 2 The co-simulation interface layer architecture includes six core components, each of which performs a specific function in achieving seamless integration between mass-production-level software engineering and vehicle reference models.

[0093] Specifically, the signal adapter is responsible for handling the structural differences between production-grade software signals and vehicle reference model signals. It controls the behavior of the control logic by writing formulas and creating signals. In co-simulation, it is responsible for decomposing or recombining complex data structures from production-grade software engineering into input / output port formats that the vehicle reference model can recognize, ensuring correct signal interfacing and transmission between the two heterogeneous environments.

[0094] Data type converters are responsible for eliminating data type barriers between two environments. Production-level software engineering typically uses strict C language primitive types (such as uint8, sint16, float32, etc.), while vehicle reference models often use double or single for floating-point operations. This converter, according to preset mapping rules, forcibly converts data from production-level software types to types supported by the vehicle reference model before it enters the model, and performs the reverse conversion during data output to prevent compilation errors or runtime data truncation due to type mismatches.

[0095] The scaling converter is responsible for the mathematical mapping between physical quantities and raw digital quantities. In production-grade software, sensor data is typically transmitted as raw analog-to-digital converter (ADC) code values, while the vehicle reference model requires actual physical quantities. The scaling converter, based on the CompuMethod defined in the production-grade software dictionary, applies a linear scaling formula to perform numerical conversion, ensuring that the data received by the model has the correct physical meaning and dimensions.

[0096] The timestamp aligner is responsible for resolving timing synchronization issues in multi-rate systems. Since the OS Task cycle (e.g., 10ms) of mass-production software often differs from the basic sampling step size (e.g., 1ms) of the vehicle reference model, the timestamp aligner ensures that low-speed signals can be transmitted to the high-speed model losslessly and deterministically by inserting rate conversion logic. It guarantees strict alignment of the time axes of the two environments in co-simulation, avoiding waveform phase deviations or data loss caused by different sampling rates.

[0097] The virtual RTE read / write interface is responsible for simulating the communication behavior of the production-grade software runtime environment within the vehicle reference model environment. It intercepts and simulates standard RTE API calls (such as Rte_Read, Rte_Write, Rte_IRead, etc.). When the model reaches the data reading step, the virtual RTE interface retrieves the latest production-grade software signal values ​​from the external buffer and injects them into the model. When the model outputs data, it captures the results and writes them to the output buffer, thus making it believe it is running on real ECU hardware.

[0098] The results acquisition interface is responsible for data capture and comparison preparation during the closed-loop debugging process. It monitors the output streams of both the mass-production software execution environment and the vehicle reference model execution environment in parallel, acquiring key data such as communication signals, control variables, internal state variables, and diagnostic tic-trick (DTC) status in real time. After acquisition, the interface timestamps the output results from both environments and packages the data for output to the consistency analysis module, providing a standardized data source for subsequent waveform phase comparison, numerical deviation calculation, and root cause localization.

[0099] In S109, the vehicle reference model is driven to perform debugging tasks through the co-simulation interface layer according to the mass production software task cycle and / or event triggering conditions.

[0100] According to some embodiments, the operating system task cycle, the execution order of the runnable entities, and the model sampling time are converted into a co-simulation schedule. The simulation time is advanced according to the co-simulation schedule. When the cycle of the runnable entity is N times the basic model simulation step size, the corresponding input sampling and output writing of the runnable entity are triggered once every N model steps.

[0101] According to some embodiments, the OS Task cycle, Runnable execution order, Runnable triggering events, and model sampling time are converted into a co-simulation schedule, and the simulation time is advanced according to the co-simulation schedule.

[0102] Specifically, the OS Task period (e.g., 10ms), Runnable execution order, and triggering events are parsed from the ARXML file. Simultaneously, the basic simulation step size of the vehicle reference model (e.g., 1ms) is obtained. A global "co-simulation schedule table" is generated using the model's basic step size as the time base. For example, if the OS Task period is 10ms, then 0ms, 10ms, 20ms... are marked as task activation points in the schedule table. During simulation runtime, the co-simulation interface layer advances the simulation time in units of model steps (1ms). When the simulation time reaches a task activation point in the schedule table, the interface layer triggers a virtual OS Task wake-up mechanism. The virtual RTE calls each Runnable sequentially according to the pre-configured execution order.

[0103] When the current step size is determined to meet the N-times cycle trigger condition of a certain Runnable (i.e., triggered once every N model steps), the virtual RTE extracts the latest production-grade software signal value from the external data cache and injects it into the corresponding input port of the vehicle reference model. After the Runnable completes execution, the virtual RTE immediately captures the latest calculation result of the corresponding output port of the vehicle reference model, packages it and writes it into the output data cache, waiting for the arrival of the next communication cycle or read cycle.

[0104] In S111, the same vehicle operating condition is synchronously sent to the software execution environment of the mass production software and the vehicle reference model execution environment through the co-simulation interface layer, and the first output result and the second output result output in the two execution environments are collected.

[0105] According to some embodiments, historical data, model-in-the-loop (MIL) test scripts, or playback data collected from actual vehicles are used as vehicle operating condition input data. This vehicle operating condition input data is simultaneously injected into the sensor interface of the production-grade software execution environment and the model input port via a co-simulation interface layer. The output of the communication signals and diagnostic status of the production-grade software execution environment are collected as the first output result, and the control output and internal state variables of the vehicle reference model are collected as the second output result.

[0106] According to some embodiments, vehicle function test conditions, boundary value test conditions, or fault injection conditions are automatically generated based on the data type, value range, unit, initial value, invalid value, and fault association information in the mass production software signal definition.

[0107] Figure 3 This diagram illustrates the architecture of the joint simulation of mass-production software and a vehicle reference model.

[0108] See Figure 3 Test conditions are automatically generated based on metadata in the mass-production software signal definition. This process transforms static configuration information into dynamic test stimuli. Test conditions include, but are not limited to, vehicle function test conditions, boundary value test conditions, and fault injection test conditions.

[0109] The vehicle function test condition is mainly used to verify whether the system's functional logic meets expectations under normal input conditions. Utilizing the signal value range and data type, input signals are divided into valid and invalid equivalence classes. Combining the initial values ​​of the signal definitions and fault association information, for vehicle mode management, an event sequence triggering state transitions is automatically generated, ensuring that all valid state transition paths are covered.

[0110] Boundary value test cases are used to test boundary conditions. They can automatically generate boundary test cases based on the signal's value range and data type precision, automatically extract the signal's allowed minimum and maximum values ​​and their adjacent values, customize the signal's maximum and minimum values ​​and step size, and generate test cases in batches.

[0111] To verify the robustness and functional safety mechanism of the system, it is necessary to generate abnormal test conditions using invalid values ​​and fault association information in the signal definition. The signal values ​​are directly and forcibly replaced with invalid values ​​or over-range values ​​in the mass production software definition to verify whether the ECU can correctly identify and execute the degradation strategy. Combined with fault association information, test conditions simulating sensor open circuit, short circuit to ground, CAN message loss, or fault code (DTC) status bit flipping are generated.

[0112] According to some embodiments, before the operating condition data is injected into the vehicle reference model, a data type converter converts the data type of the production-grade software to floating-point type supported by the vehicle reference model. A scaling converter, based on the CompuMethod defined in ARXML, converts the raw analog-to-digital converter code values ​​into real physical quantities (such as voltage, temperature, and speed), ensuring that the vehicle reference model receives input with correct physical meaning. After the input data is injected into the virtual RTE from the vehicle reference model, the vehicle reference model solver performs a discrete state update based on a fixed step size. The algorithm modules within the model perform calculations according to the topological connections within the vehicle reference model, update the internal state variables, and output a second output result.

[0113] Furthermore, the physical quantity control commands output after vehicle reference model simulation are inversely converted into the raw data format of mass production software by a scaling converter, and then restored to the corresponding data type by a data type converter. The result acquisition interface simultaneously captures communication messages or fault code statuses in the mass production software execution environment, as well as intermediate variables and final control quantities within the vehicle reference model, at the same simulation time (timestamp aligned), and outputs the first output result.

[0114] The collected dual-end data is sent to the consistency analysis module. The accuracy of the co-simulation is verified in real time by waveform phase alignment and numerical tolerance comparison. When deviations are found, root cause backtracking is performed based on the signal dependency graph.

[0115] In S113, a consistency comparison is performed between the first output result and the second output result. If a result deviation is detected, the source of the deviation is located based on the signal dependency relationship.

[0116] According to some embodiments, the first output result and the second output result are time-aligned, and the consistency of waveform phase and value is compared based on the simulation step size, timestamp, or communication frame sequence number. The consistency comparison includes signal value deviation comparison, waveform phase deviation comparison, state machine state transition comparison, threshold trigger time comparison, and diagnostic state comparison. If a result deviation is detected, a signal dependency graph is constructed, and the earliest signal node with deviation is determined by tracing back from the time the output deviation occurred.

[0117] According to some embodiments, consistency comparison includes at least one of the following: comparing signal numerical deviation, waveform phase deviation, state machine state transition, threshold trigger time, fault response result, diagnostic status, and control output quantity.

[0118] Specifically, see Figure 4 The logic for comparing signal numerical deviations is as follows: Under the same input stimulus, compare the absolute or relative errors of the output signals at both ends. Since mass production software typically suffers from ADC code quantization errors and CompuMethod scaling truncation, while vehicle reference models mostly use high-precision floating-point operations, dynamic tolerance must be introduced for numerical comparison.

[0119] The logic for comparing waveform phase deviations involves assessing the synchronization of signals at both ends on the time axis and detecting any time delays or jitter. In co-simulation, because the scheduling cycle of the OS Task is N times the basic step size of the vehicle reference model, signal updates naturally have discretization delays. Phase deviation comparisons need to be combined with the co-simulation scheduling table to verify whether the waveform transition times are strictly aligned with the expected Runnable trigger points. After excluding normal scheduling delays, the system should then assess whether there are any abnormal timing misalignments.

[0120] The comparison logic for state machine state transitions is as follows: compare the state transition paths of the two state machines under the same event trigger. It is necessary not only to compare whether the current state is consistent, but also to verify the transition conditions and the execution order of the transition actions.

[0121] The threshold trigger comparison logic compares the precise time points at which signals with hysteresis or anti-jitter logic cross a set threshold. Vehicle control frequently employs trigger conditions such as "vehicle speed > 20 km / h for 500 ms". Consistency comparisons must verify the alignment of timestamps at both ends when the threshold is reached, and whether the reset and accumulation logic of the anti-jitter timer are fully synchronized to prevent premature or delayed triggering due to time base drift.

[0122] The comparison logic for fault response results is as follows: After injecting abnormal stimuli, the safety degradation strategies or fault handling behaviors at both ends are compared. It verifies whether both ends can correctly execute the preset alternative value strategy, safety state switching, or actuator cut-off action when the input signal exceeds the value range or triggers an invalid value, ensuring the equivalence of the functional safety mechanism.

[0123] The comparison logic for diagnostic status is as follows: By comparing the changes in the 8 bits of the DTC status byte and the fault counter, it is necessary to verify whether the diagnostic event management module (DEM module) on the mass production software side and the diagnostic model on the vehicle reference model side are in the same operation cycle under specific operating conditions, and whether the synchronous setting and the progressive logic of fault confirmation and aging counter are completely matched.

[0124] The comparison logic for control outputs involves comparing the final physical control commands sent to the underlying actuators. Control outputs represent the final manifestation of the system's closed loop. Besides comparing target values ​​(such as desired torque or desired braking pressure), it's also necessary to monitor whether the output rate of change limit is in effect. If there are deviations in the outputs at both ends, root cause analysis using a signal dependency graph is required to determine whether the issue stems from differences in algorithmic logic or inconsistencies in underlying parameter configurations.

[0125] According to some embodiments, the dependency graph includes read / write edges from the mass production software port to the Runnable, output edges from the Runnable to the communication signal, and signal propagation edges from the vehicle reference model. By tracing back from the moment the output deviation occurred, the earliest signal node where the deviation occurred is determined.

[0126] According to some embodiments, based on the mass production software port mapping relationship, Runnable read-write dependency relationship, vehicle reference model signal propagation path and output deviation occurrence time, the earliest signal node with deviation is determined, and the cause of deviation is classified as interface mapping abnormality, data scaling abnormality, scheduling timing abnormality, calibration parameter abnormality, fault injection configuration abnormality or functional logic abnormality.

[0127] According to some embodiments, the signal dependency graph is a directed acyclic graph (DAG) used to accurately map the flow paths of data between heterogeneous systems. The nodes in the graph represent algorithm modules within the vehicle reference model, input / output ports of the vehicle reference model, Runnable entities of software components in the production-grade software, and RTE ports of the production-grade software. The edges of the graph represent the flow and dependencies of data, including signal propagation edges from the vehicle reference model, read / write edges from production-grade software ports to Runnables, and output edges from Runnables to communication signals, etc.

[0128] When the consistency comparison module detects a deviation at the output, it triggers a reverse backtracking mechanism. First, using the timestamps in the co-simulation scheduling table, the signal waveforms of the production-grade software and the vehicle reference model are strictly aligned on the time axis to accurately pinpoint the earliest time of deviation. Starting from the output node where the deviation occurred, the algorithm traverses backward along the dependency graph. During the traversal, the algorithm checks the data status of all upstream input nodes of that node at the earliest time of deviation. If the values ​​of the upstream nodes are consistent, the algorithm continues to trace upstream. Once it finds that an upstream node has a numerical deviation or abnormal state at the earliest time of deviation (or the previous time after considering computational delay), and all its upstream inputs are normal, that node is identified as the earliest signal node with deviation.

[0129] By identifying the earliest point of deviation, it is possible to instantly determine whether the problem lies in the algorithm logic layer of the vehicle reference model (e.g., incorrect formulas or parameter configurations) or in the interface mapping layer of the mass production software (e.g., CompuMethod scaling errors or missing port mappings). The causes of deviation can be categorized as interface mapping anomalies, data scaling anomalies, scheduling timing anomalies, calibration parameter anomalies, fault injection configuration anomalies, or functional logic anomalies, thereby significantly shortening the time for problem localization.

[0130] This invention's method can automatically establish signal mapping relationships based on mass-production-level software engineering and vehicle reference models, reducing manual configuration workload and human error. It drives model execution according to mass-production-level software task cycles, Runnable cycles, and event triggering conditions, making the simulation timing closer to the actual ECU runtime timing.

[0131] This invention synchronously sends the same vehicle operating condition input to dual execution environments and performs consistency comparison on the output results, improving the efficiency of vehicle function verification. Based on signal dependencies and Runnable call chains, it locates the source of deviations, shortening the analysis cycle for interface, calibration, scheduling, and functional logic problems. This invention also supports calibration parameter synchronization, fault injection, and test condition generation, enabling higher reusability of MIL (Model-in-the-Loop), SIL (Software-in-the-Loop), HIL (Hardware-in-the-Loop), and real-vehicle debugging configurations.

[0132] Figure 5 A schematic diagram of a system for closed-loop commissioning of vehicle functions according to an example embodiment is shown.

[0133] See Figure 5 The vehicle function closed-loop debugging system includes a mass production-level software parsing module 01, a vehicle reference model parsing module 02, a signal mapping module 03, a co-simulation interface generation module 04, a co-simulation scheduling module 05, a result acquisition module 06, and a consistency analysis module 07.

[0134] According to some embodiments, the mass production software parsing module 01 is used to acquire and parse the engineering files of the mass production software to obtain a first parsing result set. The vehicle reference model parsing module 02 is used to acquire and parse the vehicle reference model to obtain a second parsing result set. The signal mapping module 03 is used to establish a mapping relationship between the mass production software signals and the vehicle reference model signals based on the first and second parsing result sets. The co-simulation interface generation module 04 is used to generate a co-simulation interface layer based on the mapping relationship. The co-simulation scheduling module 05 is used to drive the vehicle reference model to perform debugging tasks through the co-simulation interface layer according to the mass production software task cycle and / or event triggering conditions. The result acquisition module 06 is used to synchronously send the same vehicle operating condition to the software execution environment of the mass production software and the execution environment of the vehicle reference model through the co-simulation interface layer, and acquire the first and second output results output in the two execution environments. The consistency analysis module 07 is used to compare the consistency of the first and second output results, and if a result deviation is detected, the source of the deviation is located based on the signal dependency relationship. Figure 3 The system shown is Figure 1 The methods shown correspond to each other, and the same content will not be repeated.

[0135] Figure 6 A block diagram of a computing device according to an exemplary embodiment is shown.

[0136] like Figure 6 As shown, the computing device 30 includes a processor 12 and a memory 14. The computing device 30 may also include a bus 22, a network interface card 16, and an I / O interface 18. The processor 12, memory 14, network interface card 16, and I / O interface 18 can communicate with each other via the bus 22.

[0137] Processor 12 may include one or more general-purpose CPUs (Central Processing Units), microprocessors, or application-specific integrated circuits, for executing relevant program instructions. According to some embodiments, computing device 30 may also include a high-performance display adapter (GPU) 20 for accelerating processor 12.

[0138] Memory 14 may include a machine system readable medium in the form of volatile memory, such as random access memory (RAM), read-only memory (ROM), and / or cache memory. Memory 14 is used to store one or more programs containing instructions, as well as data. Processor 12 may read the instructions stored in memory 14 to perform the methods described above according to embodiments of the present invention.

[0139] The computing device 30 can also communicate with one or more networks via a network interface card 16. The network interface card is used for data processing or external communication, and the central processing unit is used for processing data scheduled by the network interface card. The network interface card includes a root system-on-a-chip (SoC) and multiple interfaces, through which the SoC performs data communication. The SoC includes a processor and a memory, on which a computer program is stored. When the processor runs the computer program stored in the memory, it implements the method according to an embodiment of the present invention.

[0140] Bus 22 can include address bus, data bus, control bus, etc. Bus 22 provides a path for exchanging information between components.

[0141] It should be noted that, in specific implementations, the computing device 30 may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the device described above may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0142] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method. The computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, DVDs, CD-ROMs, microdrives, as well as magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic cards or optical cards, nanosystems (including molecular memory ICs), network storage devices, cloud storage devices, or any type of medium or device suitable for storing instructions and / or data.

[0143] This invention also provides a computer program product comprising a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments.

[0144] Those skilled in the art will clearly understand that the technical solutions of the present invention can be implemented by means of software and / or hardware. In this specification, "unit" and "module" refer to software and / or hardware capable of independently performing or cooperating with other components to perform a specific function, wherein the hardware may be, for example, a field-programmable gate array (FPGA), an integrated circuit, etc.

[0145] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

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

[0147] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some service interface; the indirect coupling or communication connection between devices or units may be electrical or other forms.

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

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

[0150] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention.

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

[0152] Exemplary embodiments of the present invention have been specifically shown and described above. It should be understood that the present invention is not limited to the detailed structures, arrangements, or implementations described herein; rather, the present invention is intended to cover various modifications and equivalent arrangements contained within the spirit and scope of the appended provisions.

Claims

1. A method for closed-loop debugging of vehicle functions, characterized in that, The method includes: Obtain and parse the project files of the mass-production software to obtain the first set of parsing results; The vehicle reference model is acquired and parsed to obtain the second set of parsing results. Based on the first set of analytical results and the second set of analytical results, a mapping relationship between mass-production software signals and vehicle reference model signals is established. Based on the mapping relationship, a co-simulation interface layer is generated; Based on the mass production-level software task cycle and / or event triggering conditions, the vehicle reference model is driven to perform debugging tasks through the co-simulation interface layer. The same vehicle operating condition is synchronously sent to the software execution environment of the mass production software and the vehicle reference model execution environment through the co-simulation interface layer, and the first output result and the second output result output in the two execution environments are collected. The consistency of the first output result and the second output result is compared. If a deviation is detected, the source of the deviation is located based on the signal dependency relationship.

2. The method according to claim 1, characterized in that, The first set of parsing results includes the software components, port interfaces, data interfaces, task scheduling information of runnable entities, communication signals, read / write relationships of runtime environment data, and calibration parameters of the mass-production software; The second set of analytical results includes the model input port, model output port, model sampling time, model parameters, and internal state variables.

3. The method according to claim 2, characterized in that, Based on the first and second parsing result sets, a mapping relationship between mass-production-grade software signals and vehicle reference model signals is established, including: The mass-production software signals and the vehicle reference model signals are normalized to remove naming prefixes, suffixes, and case differences; and / or The mapping confidence score is calculated based on at least two items from each port's name, signal name and direction, data type, unit, and scaling factor in the first and second parsing result sets; and / or If the mapping confidence level is greater than a first preset threshold, the mapping relationship is automatically confirmed; and / or If the mapping confidence is greater than the second preset threshold and less than or equal to the first preset threshold, then the output is a candidate mapping relationship.

4. The method according to claim 3, characterized in that, When multiple candidate mapping relationships exist, the candidate mapping relationships are sorted according to the software component to which the runnable entity belongs, the interface to which the port belongs, and the communication signal association relationship, and the sorting result is output as a verifiable mapping configuration.

5. The method according to claim 3, characterized in that, The co-simulation interface layer includes a signal adapter, a data type converter, a scaling converter, a timestamp aligner, a virtual runtime environment data read / write interface, and a result acquisition interface. The co-simulation interface layer is used to: handle the conversion between mass-production software data types and vehicle reference model data types; eliminate data type barriers between the software execution environment of the mass-production software and the execution environment of the vehicle reference model; and convert signal values ​​according to the scaling factor in the signal definition of the mass-production software. Synchronize the model simulation time with the mass production-level software task scheduling time; simulate the communication behavior of the runtime environment data in the vehicle reference model execution environment; Responsible for data acquisition and comparison preparation during the closed-loop debugging process.

6. The method according to claim 2, characterized in that, Based on the mass production software task cycle and / or event triggering conditions, the vehicle reference model is driven to perform debugging tasks through the co-simulation interface layer, including: The operating system task cycle, the execution order of the runnable entities, and the model sampling time are converted into a co-simulation scheduling table; The simulation time is advanced according to the co-simulation schedule. When the period of the runnable entity is N times the basic simulation step size of the model, the input sampling and output writing of the corresponding runnable entity are triggered once every N model steps.

7. The method according to claim 2, characterized in that, The same vehicle operating condition is synchronously sent to the mass production software execution environment and the vehicle reference model execution environment through the co-simulation interface layer. The first output result and the second output result output in the two execution environments are collected, including: Historical data, model-in-the-loop test scripts, or playback data collected from actual vehicles are used as vehicle operating condition input data. The vehicle operating condition input data is simultaneously injected into the sensor interface of the mass production software execution environment and the model input port through the co-simulation interface layer. The output of the communication signal and the diagnostic status of the mass-production software execution environment are collected as the first output result, and the control output and the internal state variables of the vehicle reference model are collected as the second output result.

8. The method according to claim 6, characterized in that, A consistency comparison is performed between the first output result and the second output result. If a deviation is detected, the source of the deviation is located based on the signal dependency relationship, including: The first output result and the second output result are time-aligned, and the consistency comparison of waveform phase and value is performed based on the simulation step size, timestamp or communication frame sequence number. The consistency comparison includes signal value deviation comparison, waveform phase deviation comparison, state machine state transition comparison, threshold trigger time comparison and diagnostic state comparison. If a result deviation is detected, a signal dependency graph is constructed, and the earliest signal node with the deviation is determined by tracing back from the time when the output deviation occurred.

9. A system for closed-loop debugging of vehicle functions, characterized in that, The system includes: The mass production software parsing module is used to acquire and parse the project files of mass production software to obtain the first parsing result set; The vehicle reference model parsing module is used to acquire and parse the vehicle reference model to obtain a second parsing result set; The signal mapping module is used to establish a mapping relationship between mass-production software signals and vehicle reference model signals based on the first set of parsing results and the second set of parsing results. A co-simulation interface generation module is used to generate a co-simulation interface layer based on the mapping relationship; The co-simulation scheduling module is used to drive the vehicle reference model to perform debugging tasks through the co-simulation interface layer according to the mass production software task cycle and / or event triggering conditions. The result acquisition module is used to synchronously send the same vehicle operating condition to the software execution environment of the mass production software and the vehicle reference model execution environment through the co-simulation interface layer, and to acquire the first output result and the second output result output in the two execution environments; The consistency analysis module is used to compare the consistency between the first output result and the second output result. If a result deviation is detected, the source of the deviation is located based on the signal dependency relationship.

10. A computing device, characterized in that, include: processor; as well as A memory storing a computer program that, when executed by the processor, implements the method as described in any one of claims 1-8.

Images