A model and data driven vehicle software fault diagnosis method and system

Abstract

This invention provides a model- and data-driven method and system for diagnosing onboard software faults, relating to the field of rail transit operation control technology. The method includes: verifying fault diagnosability based on program control timing and model mutation operators; configuring middleware from the interface between the actual software and the model based on the verification results, establishing a mapping relationship between physical symbols and real data streams; acquiring measured data of the onboard software to be diagnosed; inputting the measured data into the physical model, and outputting fault versions with different mutation operators based on the mapping relationship between physical symbols and real data streams; analyzing the fault versions using a time relative consistency relationship detection algorithm to generate fault diagnosis results; extracting statement execution feature data through a data model to form program execution spectrum information; and predicting the suspiciousness of the program entities of the diagnosed module based on metaheuristic algorithms and neural network algorithms to obtain a suspiciousness ranking list for fault location.

Description

Technical Field

[0001] This invention relates to the field of rail transit operation control technology, and in particular to a model- and data-driven method and system for diagnosing onboard software faults. Background Technology

[0002] Model and data-driven approaches refer to using both model and data methods to drive the fault diagnosis process. Onboard software faults refer to abnormalities or errors in the software running in the train's onboard system, which prevent it from performing its intended functions or operations. Onboard software faults can seriously affect the train's control, monitoring, and safety systems, thereby impacting the train's operation.

[0003] Software faults in the new train operation control system (hereinafter referred to as the new train control system) with onboard as the core are an important factor affecting train operation safety. Therefore, it is of great significance to carry out efficient, accurate and different-granular fault diagnosis in the onboard software development stage.

[0004] However, traditional vehicle software fault diagnosis mainly relies on offline testing of test case sets and manual debugging, which has problems such as insufficient real-time and completeness of fault detection, low fault location efficiency and low fault detection accuracy, making it difficult to meet the high standards of safety and reliability required by current intelligent transportation and train control systems. Summary of the Invention

[0005] To address the shortcomings of existing technologies, such as insufficient real-time performance and completeness of fault detection, low fault location efficiency, and low fault detection accuracy in traditional vehicle software fault diagnosis methods that primarily rely on offline testing of test case sets and manual debugging, which fail to meet the high standards of safety and reliability required by current intelligent transportation and train control systems, this invention provides a model- and data-driven method and system for vehicle software fault diagnosis.

[0006] The technical solutions provided by the embodiments of the present invention are as follows:

[0007] First aspect

[0008] This invention provides a model- and data-driven method for diagnosing in-vehicle software faults, comprising:

[0009] S1: Verify fault diagnosability based on program-controlled timing and model mutation operators;

[0010] S2: Based on the fault diagnosability verification results, complete the middleware configuration from the actual software and model interface, and establish the mapping relationship between physical symbols and real data flow;

[0011] S3: Obtain the measured data of the vehicle software to be diagnosed;

[0012] S4: Input the measured data into the vehicle software fault diagnosis physical model, and output the fault version with different mutation operators based on the mapping relationship between physical symbols and real data stream;

[0013] S5: Analyze the faulty version using a time relative consistency relationship detection algorithm to generate fault diagnosis results for the vehicle software to be diagnosed;

[0014] S6: Extract statement execution feature data during the execution of the vehicle software fault diagnosis physical model through the vehicle software fault diagnosis data model to form program execution spectrum information;

[0015] S7: Based on metaheuristic algorithms and neural network algorithms, the suspicion level of the program entities of the diagnosed module is predicted, a suspicion level ranking list is obtained, and fault location is performed.

[0016] Second aspect

[0017] This invention provides a model- and data-driven in-vehicle software fault diagnosis system, comprising:

[0018] processor;

[0019] The memory stores computer-readable instructions, which, when executed by the processor, implement the model- and data-driven vehicle software fault diagnosis method of the first aspect.

[0020] Third aspect

[0021] The present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the model- and data-driven vehicle software fault diagnosis method as described in the first aspect.

[0022] The beneficial effects of the technical solutions provided by the embodiments of the present invention include at least the following:

[0023] In this invention, the fault diagnosability of the system is determined by verifying the program control timing and model mutation operators. Based on the fault diagnosability verification results, physical symbols and actual data streams are associated. Then, the acquired measured data is input into the vehicle software fault diagnosis physical model. Based on the mapping relationship between physical symbols and real data streams, fault versions with different mutation operators are output. The fault versions are analyzed by a time relative consistency relationship detection algorithm to generate fault diagnosis results for the vehicle software to be diagnosed. Furthermore, during the fault diagnosis process, the feature information of program execution is extracted using the vehicle software fault diagnosis data model to form a program execution spectrum, providing in-depth information for fault location. Finally, by combining metaheuristic algorithms and neural network algorithms, a suspiciousness ranking list for fault location is generated to achieve fault location. This method, based on a novel model- and data-driven approach for diagnosing onboard software faults in train control systems, employs a parallel and fusion structure. It utilizes both data and physical models to perform onboard software fault version analysis and fault diagnosis, offering excellent flexibility and high detection efficiency. It effectively avoids the generation of numerous test kits while ensuring detection accuracy, and significantly improves program debugging efficiency and fault location detection rate. It is particularly suitable for diagnosing software defects in a small sample code fragment from a large number of fault versions, enabling accurate online fault diagnosis of onboard software faults in the novel train control system. This provides safety protection for train operation, greatly improving the accuracy, real-time performance, and adaptability of the diagnosis, and enhancing fault location efficiency. Attached Figure Description

[0024] 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. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 A flowchart illustrating a model- and data-driven method for diagnosing vehicle software faults, provided in an embodiment of the present invention.

[0026] Figure 2 A schematic diagram of a model- and data-driven in-vehicle software fault diagnosis method provided in an embodiment of the present invention;

[0027] Figure 3 This is a schematic diagram illustrating the principle of vehicle-mounted software fault detection provided in an embodiment of the present invention;

[0028] Figure 4 This is a schematic diagram illustrating the principle of vehicle software fault location provided in an embodiment of the present invention;

[0029] Figure 5This is a schematic diagram of a model- and data-driven vehicle software fault diagnosis system provided in an embodiment of the present invention. Detailed Implementation

[0030] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0031] In embodiments of the present invention, words such as "exemplarily," "for example," etc., are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0032] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0033] Reference manual attached Figure 1 The diagram illustrates a flowchart of a model- and data-driven in-vehicle software fault diagnosis method provided by an embodiment of the present invention.

[0034] Reference manual attached Figure 2 The diagram shows a structural schematic of a model- and data-driven in-vehicle software fault diagnosis method provided by an embodiment of the present invention.

[0035] Figure 2 In this process, measured data of the onboard software to be diagnosed is input into the onboard software fault diagnosis data model. The measured data is processed by the data model to analyze the system's operating status and provide a basis for fault diagnosis. The onboard software fault diagnosis data model extracts features and models the input data to help identify potential anomalies and fault behaviors. The onboard software fault diagnosis physical model is a standardized model of the onboard software functions. Different fault behavior models are generated through mutation operations. This model provides a verification mechanism based on program control timing and consistency relationships to check whether the software meets the expected behavior standards. Under the synergy of the onboard software fault diagnosis data model and the onboard software fault diagnosis physical model, different fault versions are formed. Fault versions are multiple different fault models generated by code-level mutation and model mutation. These fault versions are used for further fault localization. By comparing and analyzing with the measured data, the specific fault type and location are determined. After the fault version analysis is completed, the obtained fault diagnosis and localization results are output. This result includes the fault type, location, and suspicion ranking, providing a reference for subsequent fault repair.

[0036] This invention provides a model- and data-driven method for diagnosing vehicle software faults. This method can be implemented using a model- and data-driven vehicle software fault diagnosis device, which can be a terminal or a server. The processing flow of the model- and data-driven vehicle software fault diagnosis method may include the following steps:

[0037] S1: Fault diagnosability verification is performed based on program-controlled timing and model mutation operators.

[0038] Among them, program control timing refers to the time flow in which each functional module is executed in a predetermined order during the operation of software. Control timing is crucial for fault diagnosis because abnormal timing may mean system failure. Model mutation operator is a means of simulating faults. By artificially introducing changes (or "mutations") into the model, the fault response capability of the system can be tested. It helps to diagnose the performance of the system under different fault conditions in order to verify the diagnosability of the fault.

[0039] It should be noted that by combining timing and mutation operators to verify whether different fault types can be identified, diagnosable fault types are screened out, which improves the efficiency and accuracy of subsequent diagnosis, ensures that the system can effectively respond to various expected faults, thereby reducing the blindness in diagnosis and improving the reliability of the overall diagnosis process.

[0040] In one possible implementation, S1 specifically includes:

[0041] S101: Based on program control timing and model mutation operators, mutate the I / O channel behavior of the functional model of the on-board equipment software specification.

[0042] Among them, the vehicle equipment software specification functional model is a software functional model of vehicle equipment. It describes the various functional requirements of vehicle software in a standardized form. This model can simulate the normal operation of the software and various possible fault states, providing a basis for diagnosis. I / O channels refer to input or output channels, which are the paths for exchanging data between vehicle equipment software and external environment or hardware. The behavior of input or output channels directly affects the operating status of vehicle equipment software and is very important in fault detection.

[0043] S102: Construct a diagnosable fault model based on the fault behavior model, and verify the diagnosability of the fault by combining the verification theorem to obtain various diagnosable fault behaviors.

[0044] Among them, the fault behavior model is a model used to describe software faults. It constructs specific fault scenarios, including changes in I / O behavior, so that the diagnostic system can identify, detect and analyze these fault modes. The verification theorem is a method used in system verification to determine whether the system meets specific conditions. It is usually combined with mathematical or logical methods to ensure the detectability of faults in the system under specific conditions.

[0045] It should be noted that by modifying the standard functional model of the vehicle software and combining it with verification theorems, the diagnosticability of fault behavior can be constructed and tested. This method helps to build a model that can effectively simulate various faults, laying the foundation for the entire fault diagnosis process.

[0046] S2: Based on the fault diagnosability verification results, the middleware configuration is completed from the actual software and model interface to establish the mapping relationship between physical symbols and real data streams.

[0047] Among them, the fault diagnosability verification results are the results after fault diagnosability verification, which include which fault types can be identified by the system. These verification results provide a basis for subsequent middleware configuration, ensuring that the diagnostic system can effectively detect and distinguish known faults. Middleware is a software layer that provides functional support between the application and the operating system. In this step, the middleware is used to connect the interface between the actual software and the functional model, helping to establish a data flow mapping between the software and the physical system, so that the fault diagnosis model can receive real data for analysis. Physical symbols are abstract representations of the actual hardware or physical objects in the system, used to represent the physical entities or parameters of the vehicle system in the model. Real data flow refers to the actual operating data collected from the vehicle system, including sensor data, control signals, etc. These data flows provide the fault diagnosis model with real information sources.

[0048] It should be noted that by establishing a mapping relationship between the actual data flow of the vehicle software and the physical symbols, the diagnostic model can accurately identify and interpret data from the actual system. This mapping relationship improves the realism and reliability of the diagnostic system, enabling the system to perform more accurate fault location and analysis based on input from the real environment. At the same time, by configuring middleware, seamless integration between the software and the model is ensured, enhancing the applicability and efficiency of the diagnosis.

[0049] S3: Obtain the actual test data of the vehicle software to be diagnosed.

[0050] Among them, the vehicle software to be diagnosed is the software in the vehicle system that needs to be diagnosed. It is usually used to control or monitor various functions of the vehicle. In fault diagnosis, the goal is to identify abnormal or faulty behavior of the software during operation. Measured data refers to unprocessed real-time data collected from the actual operation of the vehicle. These data come from the sensors, control units and external interfaces of the vehicle system, including information such as vehicle status, operating parameters and environmental feedback, which provide real data support for fault analysis.

[0051] It should be noted that by using actually collected data, the system can more accurately simulate the fault characteristics and reactions of vehicles under different operating conditions, providing precise input for subsequent fault analysis and localization. This application of measured data not only increases the practicality of the diagnostic model but also helps identify real-world fault scenarios that may not be covered in experimental data.

[0052] In one possible implementation, the measured data includes:

[0053] Data from train monitoring terminals, on-board monitoring terminals, dispatch monitoring terminals, and trackside monitoring terminals.

[0054] Reference manual attached Figure 3 The diagram illustrates a schematic representation of an in-vehicle software fault detection principle provided by an embodiment of the present invention.

[0055] Figure 3 In this study, the I / O channel behavior of the functional model of the vehicle equipment software specification is mutated based on program control timing and model mutation operators. A diagnosable fault model is constructed on the fault behavior model. Zeno type verification is performed in combination with verification theorems, i.e., fault diagnosability verification is performed, thereby obtaining various diagnosable fault behaviors. On this basis, the middleware configuration is completed from the interface between the actual software and the model, and the mapping relationship between physical symbols and real data flow is established. Code-level mutations corresponding to the model mutation behaviors are performed on the actual vehicle equipment software to obtain fault versions with different mutation operators. Then, based on the time automaton and time relative consistency relationship detection algorithm, the online fault detection process is carried out under the stimulation of the environmental model. During the execution, the log information generated by the tron ​​tool is combined with the fault detection standard MTS (Modular Test System) to evaluate the model-based online fault detection effect in terms of time performance and accuracy.

[0056] S4: Input the measured data into the vehicle software fault diagnosis physical model, and output the fault version with different mutation operators based on the mapping relationship between physical symbols and real data stream.

[0057] Among them, the vehicle software fault diagnosis physical model is a model that simulates the actual operating environment and conditions of a vehicle. It is specifically designed for detecting and analyzing software faults. This physical model combines physical symbols and data flow mapping, which can accurately simulate the performance of the software under different fault scenarios. The fault version of the mutation operator refers to the "fault version" of the vehicle software generated by introducing different types of mutation operators. These versions simulate the behavior of the vehicle software under various potential fault conditions and are used to test the diagnostic system's response capability to different fault modes.

[0058] It should be noted that by using different mutation operators to generate various fault scenarios, the diagnostic model can simulate and analyze various potential fault modes. This method enhances the system's fault tolerance and robustness, enabling it to effectively cope with a variety of complex fault situations. At the same time, based on the mapping relationship between physical symbols and real data streams, the model achieves a high degree of realism in the simulation environment, thereby improving the accuracy of fault detection and analysis.

[0059] S5: Analyze the faulty version using a time-relative consistency relationship detection algorithm to generate fault diagnosis results for the vehicle software to be diagnosed.

[0060] Among them, the time relative consistency relationship detection algorithm is an algorithm used to analyze whether the behavior of vehicle software conforms to the expected time series. By comparing the actual behavior with the predefined time consistency relationship, it can detect abnormal behavior of the software at different time points to identify faults. Fault version refers to a specific instance of the vehicle software fault model generated in the previous step. Through these fault versions, the behavior of the software under different fault states can be simulated, which is convenient for diagnosis and analysis. The fault diagnosis result is the judgment result obtained by the system after analyzing the fault version. It contains information about the fault location, type and severity. It is the core output of the fault diagnosis process and directly reflects the diagnostic capability of the system.

[0061] It should be noted that by using a time-relative consistency detection algorithm to analyze the faulty version of the vehicle software, the diagnostic system can capture anomalies in the time series more meticulously. This method can not only identify obvious faults, but also detect subtle deviations from expected behavior, thereby improving the sensitivity and accuracy of diagnosis. At the same time, time consistency analysis provides richer temporal information for fault diagnosis, enabling the system not only to determine the existence of a fault, but also to understand the evolution of the fault at different points in time, thus providing more comprehensive support for subsequent fault location and handling.

[0062] Specifically, the fault diagnosability verification process is as follows:

[0063] Taking the speed protection module as an example, its top-level functional timing state model is selected. The MoMut tool is used to mutate the I / O observable channels, resulting in a set of possible defect behavior models. Then, one mutation model from each mutation operator is selected as an example to construct a model based on the mutated execution path. A time automaton network is formed by combining I / O behavior with the environment model. Finally, the diagnosability lemma is used... Verification above.

[0064] In one possible implementation, S5 specifically includes:

[0065] S501: Using a time relative consistency relationship detection algorithm, this study focuses on overspeed protection function and analyzes the I / O environment interface parameters and the requirements specifications of key sub-modules in the overspeed protection function.

[0066] Overspeed protection is a safety feature in vehicle systems used to monitor and limit vehicle speed to prevent it from exceeding safe limits. It comprises several key modules, and their proper operation is crucial for the safe operation of the vehicle system. I / O environment interface parameters refer to various parameter data in the vehicle system's input / output interfaces that support the operation of overspeed protection. These parameters typically include information such as speed, acceleration, and environmental conditions, which are transmitted to the vehicle software through the I / O interface to assist in the judgment and control of overspeed protection. Key submodules are the core components of overspeed protection, responsible for executing the function's critical logic. The normal operation of these key submodules directly affects the effectiveness and safety of overspeed protection, and therefore requires close attention during diagnostics.

[0067] S502: Based on the requirements specifications and combined with environmental parameters, design a model to test the line topology in the application phase, and divide the environmental model and the implementation model.

[0068] The requirements specification is a descriptive document describing the expected behavior, performance, and safety requirements of the onboard system. It guides system design and functional verification, ensuring that actual performance meets design expectations. It serves as a benchmark for judging onboard software faults. Environmental parameters refer to external condition data that affect system functions during vehicle operation, such as speed, temperature, location, and track information. Environmental parameters are used to simulate the actual operating environment of the vehicle and help analyze the system's performance under different conditions. The track topology refers to the structure describing the geographical distribution, connection methods, and layout relationships of the train's running tracks. The track topology directly affects the vehicle's driving state and the onboard system's response mode, and is therefore an important consideration in overspeed protection functions.

[0069] S503: Based on the division results of the environment model and the implementation model, establish a hierarchical model of the environment model and the corresponding functional modules of the diagnostic subsystem, and perform I / O function variation from the perspective of timing status around the top-level functional model of overspeed protection.

[0070] Among them, the environmental model refers to the external conditions simulating the operation of the on-board system, such as track, speed limits, terrain and other factors. The implementation model describes the functions that the system should perform according to the requirements specifications, including the working logic and behavior of each module inside the on-board system. The hierarchical model is a way of modeling different parts of the system in layers according to functional levels. This model can decompose complex systems, structure the top-level functions and bottom-level modules, making system analysis clearer and facilitating fault location. The overspeed protection top-level functional model represents the overall model of the overspeed protection function, which is used to limit the train speed to prevent dangerous situations. The top-level model includes the main logic and control mechanism of this function and is the core of the entire overspeed protection system.

[0071] S504: Construct different variant models and combine them with a diagnosticability verification algorithm to verify the diagnosticability of each variant operator in observable I / O behavior.

[0072] Among them, the variant model is a model version generated by deliberately modifying or perturbing the system model. The variant model is used to simulate possible faults in the system to observe the impact of these faults on the system behavior. The diagnostic verification algorithm is an algorithm used to analyze whether the system can identify and locate specific faults. The diagnostic verification algorithm evaluates the fault diagnosis capability of the system to ensure that it can correctly detect and identify these faults under the fault conditions generated in the variant model. The mutation operator refers to an operational rule used to introduce mutations. The mutation operator can define different modification methods, such as perturbation of the system input, output or internal state, to create specific fault conditions and thus observe the system response. Observable I / O behavior refers to the input and output behavior that can be observed from the outside during the operation of the system.

[0073] S505: Select the component-level fault behavior corresponding to the mutation operator such as the diagnosable change action, and use the mutation tool to perform source code-level mutation on the sub-functions of the overspeed protection function module.

[0074] Among them, component-level fault behavior refers to fault behavior that occurs in a specific component of the system (such as a software module or hardware unit). This type of fault behavior is limited to a specific component, which helps to refine the source of the fault and facilitates more accurate fault diagnosis and location. Mutation tools refer to tools used to automatically generate variants. They can insert mutation operators into the program source code or model to create fault versions. These tools generate various fault scenarios through automated operation in order to more efficiently evaluate the system's response.

[0075] S506: Extract key sub-modules from the simulation test platform and establish a consistency online detection simulation application platform for mutation.

[0076] Among them, the simulation test platform is a computing platform used to simulate the system's operating environment and process. In fault diagnosis, the simulation test platform can generate virtual test scenarios to help verify the system's response performance under different fault scenarios, thereby improving testing efficiency and repeatability. Key sub-modules are modules in the system that are crucial to functionality and safety. Key sub-modules usually undertake core functions, so conducting separate simulation tests and fault diagnoses on them helps identify potential serious problems in the system. Online consistency detection refers to a real-time monitoring technology used to detect whether the system conforms to expected behavior and design specifications during operation. Through online consistency detection, the system can promptly detect anomalies during operation, effectively improving the timeliness and accuracy of fault diagnosis.

[0077] S507: Based on evaluation metrics, compare and analyze the offline mutation methods of test case sets generated by model-based online consistency detection and combined strategy constraint solving algorithms.

[0078] Evaluation metrics are standards or parameters used to measure and evaluate the performance of a fault diagnosis system. Evaluation metrics can include diagnostic accuracy, recall, time cost, etc., to quantify detection efficiency and effectiveness. The combined strategy constraint solving algorithm is a test case generation algorithm based on combined strategies. It aims to generate a set of test cases that cover a wide range of fault modes of the system. The test case set generated by this algorithm can specifically test various possible faults of the system. The test case set is a collection of multiple specific test cases that includes scenarios for testing various aspects of the system's performance. A complete test case set can fully cover system functions and fault modes and is the foundation of fault diagnosis and testing.

[0079] S508: Based on the comparative analysis results, determine the fault diagnosis result of the vehicle software to be diagnosed.

[0080] The fault diagnosis result refers to the final result output after the diagnosis process, which includes the identified fault type, fault location and possible cause. The fault diagnosis result helps maintenance personnel quickly understand the problem and facilitates the implementation of corresponding maintenance measures.

[0081] It should be noted that by establishing a comprehensive model and fault injection method, we can deeply detect potential faults in vehicle software. By using mutation operators to construct different fault scenarios and combining online consistency detection with offline test case set comparison and analysis, we can not only verify the diagnostic effect of each module in complex scenarios, but also improve the accuracy and coverage of diagnostic results. Through comparison and evaluation, we can finally obtain an efficient and accurate fault location method, making the entire fault diagnosis process more systematic and reliable, and providing a clear basis for subsequent maintenance.

[0082] Reference manual attached Figure 4 The diagram illustrates a schematic representation of the fault location principle of in-vehicle software provided by an embodiment of the present invention.

[0083] Figure 4 First, using small-scale cases of Siemens components and the speed protection module in an on-board equipment simulation platform as case studies, this paper implements fault location methods based on PSO (Particle Swarm Optimization) and RNNs (Recurrent Neural Networks) for single fault cases of different scales. The results are compared with those of several classic program spectrum location methods under imbalanced dataset conditions. Second, in a large-scale on-board equipment simulation platform, the performance of the RNN model based on PSO algorithm in predicting statement suspicion is compared for a single fault version. Third, under multiple fault versions generated by different variants of the speed protection sub-functional module, the statement check rate is analyzed and compared in conjunction with fault location evaluation indicators. Finally, through extensive case studies of multiple fault versions, the paper verifies whether the fault location method based on the PSO and RNN fusion recurrent neural network optimization model can fully integrate dynamic program operation behavior information, effectively narrow the scope of on-board software functional level fault search, and assist on-board software developers in timely fault location after discovering observable faults, thus achieving on-board software fault location based on statement coverage features.

[0084] Specifically, the fault location process based on statement coverage features is as follows:

[0085] First, statement-level coverage analysis is performed on the components to be diagnosed to obtain effective program primitive sequences. Based on this, the coverage analysis report is parsed, data is collected and preprocessed, and statement suspicion is ranked according to each fault version obtained after mutation and detection. The effectiveness of statement-level fault location is analyzed by combining three classic program spectrum-based methods with a method based on PSO and RNNs fusion. The PSO and RNNs fusion process is as follows: the vehicle software to be diagnosed program is selected as the initial sample, and segmented data is extracted to form a test set and a training set. An RNN-type statement suspicion prediction model is then trained using the training set, and the RNN model parameters are optimized and adjusted using the PSO algorithm to quickly converge to form the desired PSO-RNNs model. Next, the effectiveness of the constructed PSO-RNNs-type statement suspicion prediction model is verified using the test set. Finally, the location performance of the constructed prediction model is compared among different methods under multiple fault versions generated by different variants of the speed protection sub-module, combined with the statement check rate analysis of the fault location evaluation index.

[0086] S6: Extract statement execution feature data during the execution of the vehicle software fault diagnosis physical model through the vehicle software fault diagnosis data model to form program execution spectrum information.

[0087] Among them, the vehicle software fault diagnosis data model is a model that contains vehicle software diagnosis-related data to help analyze and extract useful information during the diagnosis process, so as to support the execution and optimization of fault diagnosis. Statement execution feature data reflects the specific behavior data of vehicle software during execution, covering the execution status of different code statements. These feature data provide clues for fault location and support subsequent fault detection and analysis. Program execution spectrum information refers to the record of the execution status of each statement in the software operation and its performance in different fault scenarios, serving as an important basis for fault location and diagnosis.

[0088] It should be noted that by extracting statement features during software execution through the fault diagnosis data model, program execution spectrum information is formed, which helps to locate fault points. By structuring complex execution data, clear fault clues and program performance information are provided for subsequent diagnostic analysis, making the diagnostic process more detailed and targeted, and significantly improving the efficiency and accuracy of fault location.

[0089] S7: Based on metaheuristic algorithms and neural network algorithms, the suspicion level of the program entities of the diagnosed module is predicted, a suspicion level ranking list is obtained, and fault location is performed.

[0090] Among them, metaheuristic algorithms are optimization algorithms based on natural inspiration, used to solve the optimal solution search in complex problems. The metaheuristic algorithm used here is the particle swarm optimization algorithm, which simulates the process of a swarm of particles finding the optimal position, thus improving the efficiency of fault location. Neural network algorithms refer to computational models that simulate the connections of neurons in the human brain, which can automatically learn the complex characteristics of data. The recurrent neural network algorithm used here is suitable for processing sequential data or time-series related data, helping to analyze the running data of vehicle software. The suspicion ranking list is a sorted list used to mark the probability of errors in each code segment (or module) in the program. It sorts different areas in the program from high to low "suspicion" based on suspicion prediction.

[0091] It should be noted that by combining particle swarm optimization and recurrent neural network algorithms for fault location, and by combining suspicion ranking with small-scale case testing, the intelligence and accuracy of the diagnostic process are effectively improved. By utilizing these advanced algorithms and data analysis methods, efficient fault location can still be achieved under conditions of imbalanced data, making the diagnostic results more reliable and significantly shortening the fault investigation time.

[0092] In one possible implementation, the metaheuristic algorithm is a particle swarm optimization algorithm, and the neural network algorithm is a recurrent neural network algorithm.

[0093] In one possible implementation, S7 specifically includes:

[0094] S701: Taking a small-scale case of Siemens components and the speed protection function module in the vehicle equipment simulation platform as research cases.

[0095] Among them, small-scale cases of Siemens components refer to small-scale test cases using standardized test components provided by Siemens. They are usually included in a set of public datasets or standard fault scenarios in software fault diagnosis research, which can verify the effectiveness and accuracy of fault diagnosis and location methods. They are often used for benchmark testing, especially in industrial applications. The vehicle equipment simulation platform is a platform used to simulate the operating environment of vehicle systems and software. It can simulate various working states and operating environments of vehicle equipment, generate relevant operating data and fault information, and be used to test and verify the effectiveness of fault diagnosis algorithms.

[0096] S702: A fault location method is constructed based on a combination of particle swarm optimization and recurrent neural network algorithms.

[0097] Obtain software log data.

[0098] The software log data is cleaned and normalized.

[0099] The processed software log data is used as a training set and input into the recurrent neural network for training.

[0100] The recurrent neural network is optimized using the particle swarm optimization algorithm until a preset number of iterations is reached.

[0101] An RBF neural network is constructed, comprising an input layer, an output layer, and a hidden layer. The hidden layer uses the Gaussian function as the activation function, and the input and output layers contain multiple memory neurons.

[0102] The optimal linear mapping relationship from hidden neurons to output neurons in the RBF neural network is calculated using the Moore-Penrose pseudoinverse.

[0103] The degree of suspicion is calculated based on the optimal linear mapping relationship, and the statements with the degree of suspicion are sorted:

[0104]

[0105] in, This indicates the suspiciousness of statement j. , m represents the total number of statements.

[0106] The statements are sorted from highest to lowest suspicion level until the fault is found.

[0107] The position and velocity of the particles are updated based on performance indicators, and the global optimal solution is recorded at the same time.

[0108] When the stopping condition is met (such as reaching the maximum number of iterations or when the performance improvement is not significant), the optimal model is selected.

[0109] New fault data is input into the trained recurrent neural network model for fault localization.

[0110] Among them, Particle Swarm Optimization (PSO) is an optimization algorithm based on swarm intelligence, simulating the behavior of flocks of birds foraging or schools of fish swimming. The swarm of particles continuously adjusts its position in the search space to seek the optimal solution. In fault location, PSO can be used to explore the most likely location of the fault, improving the efficiency and accuracy of fault diagnosis by continuously optimizing the location process. Recurrent Neural Network (RNN) is a neural network model, particularly suitable for processing sequential or time-series data. RNNs can memorize and use the contextual information of previous data. In vehicle software fault diagnosis, it can analyze the system's time-series data to more accurately locate the time and location of the fault. Fault location method is a method or process for identifying the location of software faults. By combining PSO and RNN algorithms, a fault location method is constructed that can perform in-depth analysis of the program and generate suspicious areas of the fault, thereby quickly and accurately locating the problem area.

[0111] S703: Under the condition of imbalanced dataset, a comparative analysis of the fault location performance of the fault location method and the classic program spectrum location method is conducted.

[0112] Among them, the imbalanced dataset condition refers to the situation where the amount of data of different categories in the dataset is unbalanced. In the fault diagnosis scenario, the amount of fault data of different types or locations may vary greatly, causing the model to tend to detect the fault types that occur more frequently while ignoring the less common faults. The classic program spectrum localization method is a traditional fault localization technique that collects program execution path (i.e., "program spectrum") information and analyzes the execution frequency and behavior of each code segment during runtime to identify the code location that may contain the fault. This method is applicable to a wide range of fault types, but under the condition of imbalanced data, its effect may not be as flexible as modern algorithms.

[0113] S704: Based on the comparative analysis results, the suspicion level of the program entities of the diagnosed module is predicted, and a suspicion level ranking list is obtained.

[0114] Among them, program entities refer to the code modules or functional units that are actually executed in the vehicle software. In fault diagnosis, program entities are the objects of suspicion ranking, that is, each element in the list points to a specific code segment or module in order to locate the fault.

[0115] S705: Based on the list of suspected faults, various fault scenarios are simulated by generating different variant fault versions in the speed protection function module.

[0116] Among them, variant fault versions refer to different versions generated by mutation operations on the original software code (i.e., deliberately introducing minor changes). Each version simulates a possible fault condition. These variant versions are used to test and evaluate the effectiveness of fault diagnosis methods, enabling the diagnostic system to be tested under multiple fault scenarios.

[0117] S706: Apply both the fault location method and the classic fault location method to locate the fault in each variant fault version.

[0118] S707: Based on the location results of different variant faults, the fault location results of the vehicle software to be diagnosed are obtained through a large number of case studies on various variant fault versions.

[0119] It should be noted that by combining metaheuristic algorithms and neural network algorithms, and utilizing a suspiciousness ranking list for efficient fault localization of in-vehicle software, these steps gradually refine the fault analysis process. Starting from real-world cases, a fault localization method is constructed, and various fault scenarios are simulated and verified by generating variant fault versions. Compared with traditional methods, it can more accurately identify and locate faults in complex software systems, improving diagnostic efficiency and accuracy. At the same time, it addresses the problem of imbalanced data and enhances robustness.

[0120] The beneficial effects of the technical solutions provided by the embodiments of the present invention include at least the following:

[0121] In this invention, the fault diagnosability of the system is determined by verifying the program control timing and model mutation operators. Based on the fault diagnosability verification results, physical symbols and actual data streams are associated. Then, the acquired measured data is input into the vehicle software fault diagnosis physical model. Based on the mapping relationship between physical symbols and real data streams, fault versions with different mutation operators are output. The fault versions are analyzed by a time relative consistency relationship detection algorithm to generate fault diagnosis results for the vehicle software to be diagnosed. Furthermore, during the fault diagnosis process, the feature information of program execution is extracted using the vehicle software fault diagnosis data model to form a program execution spectrum, providing in-depth information for fault location. Finally, by combining metaheuristic algorithms and neural network algorithms, a suspiciousness ranking list for fault location is generated to achieve fault location. This method, based on a novel model- and data-driven approach for diagnosing onboard software faults in train control systems, employs a parallel and fusion structure. It utilizes both data and physical models to perform onboard software fault version analysis and fault diagnosis, offering excellent flexibility and high detection efficiency. It effectively avoids the generation of numerous test kits while ensuring detection accuracy, and significantly improves program debugging efficiency and fault location detection rate. It is particularly suitable for diagnosing software defects in a small sample code fragment from a large number of fault versions, enabling accurate online fault diagnosis of onboard software faults in the novel train control system. This provides safety protection for train operation, greatly improving the accuracy, real-time performance, and adaptability of the diagnosis, and enhancing fault location efficiency.

[0122] Reference manual attached Figure 5 The diagram shows a schematic of the structure of a model- and data-driven vehicle software fault diagnosis system provided by the present invention.

[0123] This invention also provides a model- and data-driven vehicle software fault diagnosis system 20, applied to the aforementioned model- and data-driven vehicle software fault diagnosis method, comprising:

[0124] Processor 201.

[0125] The memory 202 stores computer-readable instructions, which, when executed by the processor 201, implement the model- and data-driven vehicle software fault diagnosis method as described in the method embodiment.

[0126] The model- and data-driven vehicle software fault diagnosis system 20 provided by the present invention can execute the above-mentioned model- and data-driven vehicle software fault diagnosis method and achieve the same or similar technical effects. To avoid duplication, the present invention will not elaborate further.

[0127] The beneficial effects of the technical solutions provided by the embodiments of the present invention include at least the following:

[0128] In this invention, the fault diagnosability of the system is determined by verifying the program control timing and model mutation operators. Based on the fault diagnosability verification results, physical symbols and actual data streams are associated. Then, the acquired measured data is input into the vehicle software fault diagnosis physical model. Based on the mapping relationship between physical symbols and real data streams, fault versions with different mutation operators are output. The fault versions are analyzed by a time relative consistency relationship detection algorithm to generate fault diagnosis results for the vehicle software to be diagnosed. Furthermore, during the fault diagnosis process, the feature information of program execution is extracted using the vehicle software fault diagnosis data model to form a program execution spectrum, providing in-depth information for fault location. Finally, by combining metaheuristic algorithms and neural network algorithms, a suspiciousness ranking list for fault location is generated to achieve fault location. This method, based on a novel model- and data-driven approach for diagnosing onboard software faults in train control systems, employs a parallel and fusion structure. It utilizes both data and physical models to perform onboard software fault version analysis and fault diagnosis, offering excellent flexibility and high detection efficiency. It effectively avoids the generation of numerous test kits while ensuring detection accuracy, and significantly improves program debugging efficiency and fault location detection rate. It is particularly suitable for diagnosing software defects in a small sample code fragment from a large number of fault versions, enabling accurate online fault diagnosis of onboard software faults in the novel train control system. This provides safety protection for train operation, greatly improving the accuracy, real-time performance, and adaptability of the diagnosis, and enhancing fault location efficiency.

[0129] It should be understood that the processor in the embodiments of the present invention can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0130] It should also be understood that the memory in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0131] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the flow or function according to the embodiments of the present invention is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. A computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. Available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media. Semiconductor media can be solid-state drives.

[0132] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0133] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single item or multiple items.

[0134] It should be understood that, in various embodiments of the present invention, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0135] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0136] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0137] In the embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods 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 device, 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 interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0138] 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.

[0139] In addition, 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.

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

[0141] This invention provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the model- and data-driven vehicle software fault diagnosis method as described in the method embodiment.

[0142] The present invention provides a computer-readable storage medium that can implement the steps and effects of the model- and data-driven vehicle software fault diagnosis method described in the above method embodiments. To avoid repetition, the present invention will not repeat them.

[0143] The beneficial effects of the technical solutions provided by the embodiments of the present invention include at least the following:

[0144] In this invention, the fault diagnosability of the system is determined by verifying the program control timing and model mutation operators. Based on the fault diagnosability verification results, physical symbols and actual data streams are associated. Then, the acquired measured data is input into the vehicle software fault diagnosis physical model. Based on the mapping relationship between physical symbols and real data streams, fault versions with different mutation operators are output. The fault versions are analyzed by a time relative consistency relationship detection algorithm to generate fault diagnosis results for the vehicle software to be diagnosed. Furthermore, during the fault diagnosis process, the feature information of program execution is extracted using the vehicle software fault diagnosis data model to form a program execution spectrum, providing in-depth information for fault location. Finally, by combining metaheuristic algorithms and neural network algorithms, a suspiciousness ranking list for fault location is generated to achieve fault location. This method, based on a novel model- and data-driven approach for diagnosing onboard software faults in train control systems, employs a parallel and fusion structure. It utilizes both data and physical models to perform onboard software fault version analysis and fault diagnosis, offering excellent flexibility and high detection efficiency. It effectively avoids the generation of numerous test kits while ensuring detection accuracy, and significantly improves program debugging efficiency and fault location detection rate. It is particularly suitable for diagnosing software defects in a small sample code fragment from a large number of fault versions, enabling accurate online fault diagnosis of onboard software faults in the novel train control system. This provides safety protection for train operation, greatly improving the accuracy, real-time performance, and adaptability of the diagnosis, and enhancing fault location efficiency.

[0145] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

[0146] The following points need to be explained:

[0147] (1) The accompanying drawings of the embodiments of the present invention only involve the structures involved in the embodiments of the present invention. Other structures can refer to the general design.

[0148] (2) For clarity, the thickness of layers or regions is enlarged or reduced in the drawings used to describe embodiments of the invention, i.e., these drawings are not drawn to scale. It is understood that when an element such as a layer, film, region or substrate is referred to as being “above” or “below” another element, the element may be “directly” located “above” or “below” the other element or there may be intermediate elements.

[0149] (3) Where there is no conflict, the embodiments of the present invention and the features in the embodiments can be combined with each other to obtain new embodiments.

[0150] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. The scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A model- and data-driven method for diagnosing in-vehicle software faults, characterized in that, include: S1: Verify fault diagnosability based on program-controlled timing and model mutation operators; Specifically, S1 includes: S101: Based on program control timing and model mutation operators, perform I / O channel behavior mutation on the functional model of the on-board equipment software specification; S102: Construct a diagnosable fault model based on the fault behavior model, and verify the diagnosability of the fault by combining the verification theorem to obtain various diagnosable fault behaviors. S2: Based on the fault diagnosability verification results, complete the middleware configuration from the actual software and model interface, and establish the mapping relationship between physical symbols and real data flow; S3: Obtain the measured data of the vehicle software to be diagnosed; S4: Input the measured data into the vehicle software fault diagnosis physical model, and output fault versions with different mutation operators based on the mapping relationship between physical symbols and real data streams; S5: Analyze the faulty version using a time relative consistency relationship detection algorithm to generate a fault diagnosis result for the vehicle software to be diagnosed; Among them, the time relative consistency relationship detection algorithm is an algorithm used to analyze whether the behavior of vehicle software conforms to the expected time series. By comparing the actual behavior with the predefined time consistency relationship, it can detect abnormal behavior of software at different time points to identify faults. S6: Extract statement execution feature data during the execution of the vehicle software fault diagnosis physical model through the vehicle software fault diagnosis data model to form program execution spectrum information; S7: Based on metaheuristic algorithms and neural network algorithms, the program entities of the diagnosed modules obtained by program execution spectrum information analysis are predicted for suspicion level, and a suspicion level ranking list is obtained for fault location.

2. The model- and data-driven vehicle software fault diagnosis method according to claim 1, characterized in that, The measured data includes: Data from train monitoring terminals, on-board monitoring terminals, dispatch monitoring terminals, and trackside monitoring terminals.

3. The model- and data-driven vehicle software fault diagnosis method according to claim 1, characterized in that, S5 specifically includes: S501: Using a time relative consistency relationship detection algorithm, this paper takes the overspeed protection function as the research object and analyzes the I / O environment interface parameters and the requirement specifications of key sub-modules in the overspeed protection function. S502: Based on the aforementioned requirements specifications and combined with environmental parameters, design a model to detect the line topology in the application phase, and divide the environmental model and the implementation model. S503: Based on the division results of the environment model and the implementation model, establish a hierarchical model of the environmental model and the corresponding functional modules of the required specifications of the diagnosed subsystem, and perform I / O function variation from the perspective of timing state around the top-level functional model of overspeed protection. S504: Construct different variant models and combine them with a diagnosticability verification algorithm to verify the diagnosticability of each variant operator in observable I / O behavior; S505: Select the component-level fault behavior corresponding to the mutation operator such as the diagnosable change action, and use the mutation tool to perform source code-level mutation on the sub-function of the overspeed protection function module. S506: Extract key sub-modules from the simulation test platform and establish a consistency online detection simulation application platform for mutation; S507: Based on evaluation metrics, compare and analyze the offline mutation methods of test case sets generated by model-based online consistency detection and combined strategy constraint solving algorithms; S508: Based on the comparative analysis results, determine the fault diagnosis result of the vehicle software to be diagnosed.

4. The model- and data-driven vehicle software fault diagnosis method according to claim 1, characterized in that, The meta-heuristic algorithm is a particle swarm optimization algorithm, and the neural network algorithm is a recurrent neural network algorithm.

5. The model- and data-driven vehicle software fault diagnosis method according to claim 1, characterized in that, Specifically, S7 includes: S701: Taking a small-scale case study of Siemens components and the speed protection function module in an on-board equipment simulation platform as research cases; S702: A fault location method is constructed based on a combination of particle swarm optimization algorithm and recurrent neural network algorithm; S703: Under the condition of imbalanced dataset, compare and analyze the fault location effect of the above fault location method with that of the classic program spectrum location method; S704: Based on the comparative analysis results, perform a suspicion degree prediction on the program entities of the diagnosed module to obtain a suspicion degree ranking list; S705: Based on the suspiciousness ranking list, various fault scenarios are simulated by generating different variant fault versions in the speed protection function module; S706: Apply the fault location method and the classic program spectrum location method respectively to locate the fault in each variant fault version; S707: Based on the location results of different variant fault versions, the fault location results of the vehicle software to be diagnosed are obtained through research and analysis of a large number of cases of each variant fault version.

6. The model- and data-driven vehicle software fault diagnosis method according to claim 5, characterized in that, Specifically, S702 includes: S7021: Obtain software log data; S7022: Clean and normalize the software log data; S7023: The processed software log data is used as a training set and input into the recurrent neural network for training; S7024: Optimize the recurrent neural network using the particle swarm optimization algorithm until a preset number of iterations is reached; S7025: Construct an RBF neural network including an input layer, an output layer, and a hidden layer, wherein the hidden layer uses the Gaussian function as the activation function, and the input layer and the output layer contain multiple memory neurons; S7026: Calculate the optimal linear mapping relationship from hidden neurons to output neurons in the RBF neural network using the Moore-Penrose pseudoinverse; S7027: Calculate the degree of suspicion based on the optimal linear mapping relationship, and sort the statements based on the degree of suspicion: in, The j-th statement is considered suspicious, where j = 1, ..., m, and m represents the total number of statements. S7028: Sort the statements from highest to lowest suspicion level until the fault is found; S7029: Updates the position and velocity of particles based on performance indicators, and records the global optimal solution; S70210: Select the optimal model when the stopping condition is met; S70211: Input the fault data into the trained recurrent neural network model to locate the fault.

7. The model- and data-driven vehicle software fault diagnosis method according to claim 6, characterized in that, The stopping condition is specifically defined as reaching the maximum number of iterations or when the performance improvement is not significant.

8. A model- and data-driven in-vehicle software fault diagnosis system, characterized in that, include: processor; A memory storing computer-readable instructions, which, when executed by the processor, implement the model- and data-driven vehicle software fault diagnosis method as described in any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the model- and data-driven vehicle software fault diagnosis method as described in any one of claims 1 to 7.

Images