Vehicle-mounted software fault diagnosis method and system based on model and data driving

Abstract

The invention provides a vehicle-mounted software fault diagnosis method and system based on model and data driving, and relates to the technical field of rail transit operation control, and the method comprises the steps: carrying out fault diagnosability verification based on a program control time sequence and a model mutation operator; based on a verification result, finishing the configuration of middleware from actual software and a model interface, and establishing a mapping relation between a physical symbol and a real data stream; acquiring actual measurement data of the to-be-diagnosed vehicle-mounted software; inputting measured data into the physical model, and outputting fault versions of different mutation operators based on a mapping relation between a physical symbol and a real data stream; analyzing the fault version through a time relative consistency relation detection algorithm, and generating a fault diagnosis result; extracting statement execution characteristic data through the data model to form program execution spectrum information; and on the basis of a meta-heuristic algorithm and a neural network algorithm, performing suspicion degree prediction on a program entity of the diagnosed module to obtain a suspicion degree sorting list, and performing fault positioning.

Description

Technical Field

[0001] The present invention relates to the technical field of rail transit operation control, and in particular to a model- and data-driven on-board software fault diagnosis method and system. Background Art

[0002] Model and data-driven refers to the use of both models and data to jointly drive the fault diagnosis process, while on-board software failure refers to an abnormality or error in the software running in the train's on-board system, which causes it to be unable to perform the expected functions or operations normally. On-board software failure will seriously affect the train's control, monitoring and safety systems, thereby affecting the train's operation.

[0003] Software failure of the new train operation control system (referred to as the new train control system) with vehicle-mounted software as the core is an important factor affecting the safety of train operation. It is of great significance to carry out efficient, accurate and different granularity fault diagnosis in the vehicle-mounted software development stage.

[0004] However, traditional on-board software fault diagnosis is mainly based on offline testing of test case sets and manual debugging. It has problems such as insufficient real-time and completeness of fault detection, low fault location efficiency and low fault detection accuracy. It is difficult to meet the high standards of safety and reliability of current intelligent transportation and train control systems. Summary of the invention

[0005] In order to solve the technical problem that the traditional on-board software fault diagnosis in the prior art is mainly based on offline testing and manual debugging of test case sets, which has the problems of insufficient real-time and completeness of fault detection, low fault location efficiency and low fault detection accuracy, and is difficult to meet the high standards of safety and reliability required by current intelligent transportation and train control systems, the present invention provides a model- and data-driven on-board software fault diagnosis method and system.

[0006] The technical solution provided by the embodiment of the present invention is as follows:

[0007] First aspect

[0008] An embodiment of the present invention provides a vehicle software fault diagnosis method based on model and data driving, comprising:

[0009] S1: Fault diagnosability verification based on program control timing and model mutation operators;

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

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

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

[0013] S5: Analyze the fault version through the time relative consistency relationship detection algorithm to generate the fault diagnosis result of the vehicle software to be diagnosed;

[0014] S6: extracting 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 the meta-heuristic algorithm and the neural network algorithm, the suspicion of the program entity of the diagnosed module is predicted, and a suspicion ranking list is obtained to locate the fault.

[0016] Second aspect

[0017] An embodiment of the present invention provides a model- and data-driven vehicle software fault diagnosis system, comprising:

[0018] processor;

[0019] A memory having computer-readable instructions stored therein, which, when executed by a processor, implements the model-based and data-driven vehicle software fault diagnosis method as described in the first aspect.

[0020] The third aspect

[0021] An embodiment of the present invention provides a computer-readable storage medium, on which a computer program is stored. When the program is executed by a processor, the model- and data-driven vehicle software fault diagnosis method according to the first aspect is implemented.

[0022] The beneficial effects brought about by the technical solution provided by the embodiment of the present invention include at least:

[0023] In the present invention, the fault diagnosability of the system is judged by verifying the program control timing and model mutation operators, and the physical symbols and the actual data streams are associated based on the fault diagnosability verification results. Then, the acquired measured data is input into the vehicle software fault diagnosis physical model, and based on the mapping relationship between the physical symbols and the real data streams, the fault versions of different mutation operators are output. The fault versions are analyzed by the time relative consistency relationship detection algorithm to generate the fault diagnosis results of the vehicle software to be diagnosed. Furthermore, in the fault diagnosis process, the vehicle software fault diagnosis data model is used to extract the characteristic information of program execution, and the program execution spectrum is formed to provide deep information for fault location. Finally, the meta-heuristic algorithm and the neural network algorithm are combined to generate a suspicion ranking list of fault location to achieve fault location. This method is based on a new type of on-board software fault diagnosis method for train control systems driven by both models and data, and adopts a parallel fusion structure. That is, the data model and the physical model are used together to realize on-board software fault version analysis and fault diagnosis. It has good flexibility and high detection efficiency, effectively avoids the generation process of a large number of test suites and ensures detection accuracy, and can effectively improve program debugging efficiency and fault location inspection rate. It is particularly suitable for the diagnosis of small sample code snippets of large-scale software fault versions to discover software defects in most fault versions. It can realize online and accurate diagnosis of on-board software faults of new train control systems during runtime, provide safety protection for driving operation, thereby greatly improving the accuracy, real-time and adaptability of diagnosis, and improving fault location efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0025] Figure 1 A flowchart of a vehicle software fault diagnosis method based on model and data driving provided by an embodiment of the present invention;

[0026] Figure 2 A schematic diagram of the structure of a vehicle software fault diagnosis method based on model and data drive provided by an embodiment of the present invention;

[0027] Figure 3 A schematic diagram of a vehicle software fault detection principle provided by an embodiment of the present invention;

[0028] Figure 4 A schematic diagram of a vehicle software fault location principle provided by an embodiment of the present invention;

[0029] Figure 5A schematic diagram of the structure of a model- and data-driven vehicle software fault diagnosis system provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0030] The technical solution of the present invention is described below in conjunction with the accompanying drawings.

[0031] In the embodiments of the present invention, words such as "exemplarily" and "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "example" in the present invention should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of the word "example" is intended to present the concept in a specific way. In addition, in the embodiments of the present invention, the meaning expressed by "and / or" can be both, or it can be either of the two.

[0032] In order to make the technical problems, technical solutions and advantages to be solved by the present invention more clear, a detailed description will be given below with reference to the accompanying drawings and specific embodiments.

[0033] Reference Manual Attached Figure 1 , showing a flow chart of a model- and data-driven vehicle software fault diagnosis method provided in an embodiment of the present invention.

[0034] Reference Manual Attached Figure 2 , showing a structural diagram of a model- and data-driven vehicle software fault diagnosis method provided in an embodiment of the present invention.

[0035] Figure 2 In the process, the measured data of the vehicle software to be diagnosed is input into the vehicle software fault diagnosis data model. The measured data is processed by the data model and used to analyze the operating status of the system and provide a basis for fault diagnosis. The vehicle software fault diagnosis data model extracts features and models the input data to help identify potential abnormalities and fault behaviors. The vehicle software fault diagnosis physical model is a normative model of the vehicle software function. 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 vehicle software fault diagnosis data model and the vehicle software fault diagnosis physical model, different fault versions are formed. The fault version is a plurality of different fault models generated by code-level mutation and model mutation. These fault versions are used for further fault location. The type and location of the specific fault are determined by comparison and analysis with the measured data. After the fault version analysis is completed, the obtained fault diagnosis and location results are output. This result includes the type, location and suspiciousness ranking of the fault, providing a reference for subsequent fault repair.

[0036] The embodiment of the present invention provides a vehicle software fault diagnosis method based on model and data drive, which can be implemented by a vehicle software fault diagnosis device based on model and data drive, and the vehicle software fault diagnosis device based on model and data drive can be a terminal or a server. The processing flow of the vehicle software fault diagnosis method based on model and data drive can include the following steps:

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

[0038] Among them, program control timing refers to the time flow of each functional module executing in a predetermined order during the software operation. 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") in the model, the fault response capability of the system is tested. It helps 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 verifying whether different fault types can be identified through the combination of timing and mutation operators, diagnosable fault types are screened out, the efficiency and accuracy of subsequent diagnosis are improved, and it is ensured 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 a possible implementation, S1 specifically includes:

[0041] S101: Based on the program control timing and model mutation operator, the I / O channel behavior of the vehicle equipment software specification function model is mutated.

[0042] Among them, the vehicle-mounted equipment software specification functional model is a software functional model of the vehicle-mounted equipment. It describes the various functional requirements of the vehicle-mounted software in a standardized form. The model can simulate the normal operation of the software and various possible fault states, providing a basis for diagnosis. The I / O channel refers to the input or output channel, which is the path for exchanging data between the vehicle-mounted equipment software and the external environment or hardware. The behavior of the input or output channel directly affects the software operation state of the vehicle-mounted equipment and is very critical in fault detection.

[0043] S102: construct a diagnosable fault model based on the fault behavior model, and perform fault diagnosability verification in combination with 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 system faults under specific circumstances.

[0045] It should be noted that by mutating the standard functional model of the vehicle software and combining it with the verification theorem, the diagnosability of the fault behavior is 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, complete the configuration of the middleware from the actual software and model interface, and establish the mapping relationship between physical symbols and real data flows.

[0047] Among them, the fault diagnosability verification result is the result after the fault diagnosability verification, including which fault types can be recognized by the system. These verification results provide a basis for the 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 applications and operating systems. In this step, the middleware is used to connect the interface between the actual software and the functional model, and help establish the data flow mapping between the software and the physical system, so that the fault diagnosis model can receive real data for analysis. The physical symbol is an abstract representation of the actual hardware or physical objects in the system, which is used to represent the physical entities or parameters of the vehicle system in the model. The real data flow refers to the actual operating data collected from the vehicle system, including sensor data, control signals, etc. These data flows provide a real source of information for the fault diagnosis model.

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

[0049] S3: Obtaining actual measured data of the vehicle software to be diagnosed.

[0050] Among them, the vehicle-mounted software to be diagnosed is the software in the vehicle-mounted system that needs to be diagnosed for faults. 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. The measured data refers to the 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-mounted system, and include information such as vehicle status, operating parameters and environmental feedback, providing real data support for fault analysis.

[0051] It should be noted that by using the actual collected data, the system can more accurately simulate the fault characteristics and reactions of the vehicle under different working conditions, providing accurate input basis for subsequent fault analysis and location. The application of such measured data not only increases the practicality of the diagnostic model, but also helps identify real fault scenarios that may not be covered in the experimental data.

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

[0053] Train monitoring terminal data, on-board monitoring terminal data, dispatching monitoring terminal data and monitoring data output by trackside monitoring terminals.

[0054] Reference Manual Attached Figure 3 , showing a schematic diagram of the principle of vehicle-mounted software fault detection provided by an embodiment of the present invention.

[0055] Figure 3 In this paper, the I / O channel behavior of the vehicle equipment software specification functional model is mutated based on the program control timing and model mutation operators, a diagnosable fault model is constructed on the fault behavior model, and a Zeno type verification is performed in combination with the verification theorem, that is, fault diagnosability verification is performed, so as to obtain various diagnosable fault behaviors. On this basis, the configuration of the middleware is completed from the actual software and model interface, and the mapping relationship between physical symbols and real data streams is established. The code-level mutation corresponding to the model mutation behavior is performed on the actual vehicle equipment software to obtain the fault version of different mutation operators, so as to carry out the online fault detection process under the stimulation of the environmental model based on the time automaton and the time relative consistency relationship detection algorithm. During the execution process, 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 physical model of vehicle software fault diagnosis, and output the fault versions of different mutation operators based on the mapping relationship between physical symbols and real data streams.

[0057] Among them, the physical model of vehicle software fault diagnosis is a model that simulates the actual operating environment and conditions of the vehicle, and is specifically used to detect and analyze software faults. This physical model combines physical symbols and data flow mapping, and 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 capabilities to different fault modes.

[0058] It should be noted that different mutation operators are used to generate a variety of fault scenarios, so that the diagnostic model can simulate and analyze various potential failure modes. This method enhances the fault tolerance and robustness of the system, enabling it to effectively deal 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 authenticity in the simulation environment, thereby improving the accuracy of fault detection and analysis.

[0059] S5: Analyze the fault version through the time relative consistency relationship detection algorithm to generate the fault diagnosis result of 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 the vehicle-mounted software conforms to the expected time series. By comparing the actual behavior with the predefined time consistency relationship, it can detect the abnormal performance of the software at different time points to identify faults. The fault version refers to the specific instance of the vehicle-mounted software fault model generated in the previous step. Through these fault versions, the behavior of the software under different fault conditions can be simulated to facilitate diagnosis and analysis. The fault diagnosis result is the judgment result obtained by the system after analyzing the fault version, which 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 analyzing the faulty version of the vehicle software through the time relative consistency detection algorithm, the diagnostic system can capture anomalies in the time series more carefully. This method can not only identify obvious faults, but also detect subtle deviations from expected behaviors, thereby improving the sensitivity and accuracy of diagnosis. At the same time, time consistency analysis provides richer timing information for fault diagnosis, allowing the system to not only determine the existence of a fault, but also understand the evolution of the fault at different time points, thereby providing more comprehensive support for subsequent fault location and processing.

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

[0063] Taking the speed protection function module as an example, we select its top-level functional timing state model, use the MoMut tool to mutate the I / O observable channel, and obtain a set of possible defect behavior models. Then, we select one mutation model of each mutation operator as an example to construct the execution path after mutation, establish the model, and form a time automaton network through the I / O behavior and environment model. Finally, we use the diagnosability lemma to Verify on.

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

[0065] S501: Through the time relative consistency relationship detection algorithm, taking the overspeed protection function as the research object, analyzing the I / O environment interface parameters and the requirement specifications of the key sub-modules in the overspeed protection function.

[0066] Among them, the overspeed protection function is a safety protection function in the vehicle system, which is used to monitor and limit the vehicle speed to prevent it from exceeding the safety range. The overspeed protection function contains multiple key modules, and its normal operation is crucial to the safe operation of the vehicle system. The I / O environment interface parameters refer to various parameter data in the input / output interface of the vehicle system that support the operation of the overspeed protection function. These parameters usually include speed, acceleration, environmental conditions and other information, which are transmitted to the vehicle software through the I / O interface to assist in the judgment and control of the overspeed protection function. The key sub-module is the core component of the overspeed protection function and is responsible for executing the key logic of the function. The normal operation of the key sub-module directly affects the effectiveness and safety of the overspeed protection function, so it needs to be focused on in diagnosis.

[0067] S502: According to the requirement specifications and in combination with the environmental parameters, the line topology structure of the model detection application phase is designed, and the environmental model and the implementation model are divided.

[0068] Among them, the requirement specification is a description document of the expected behavior, performance and safety requirements of the on-board system functions. It guides system design and functional verification to ensure that the actual performance meets the design expectations. It is a reference standard for judging on-board software failures. Environmental parameters refer to external condition data that affects the system function during vehicle operation, such as speed, temperature, position and track information. Environmental parameters are used to simulate the actual operating environment of the vehicle and help analyze the performance of the system under different conditions. The line topology refers to the structure that describes the geographical distribution, connection method and layout relationship of the train running track. The line topology directly affects the vehicle's driving status and the response mode of the on-board system, so it is an important consideration in the overspeed protection function.

[0069] S503: According to the division results of the environment model and the implementation model, a hierarchical model of the requirement specification function modules corresponding to the environment model and the diagnosed subsystem is established, and I / O function variation is performed from the timing state around the overspeed protection top-level function model.

[0070] Among them, the environmental model refers to the external conditions that simulate the operation of the on-board system, such as lines, speed limits, terrain and other factors. The implementation model refers to the description of the functions that the system should perform according to the requirements and specifications, including the working logic and behavior of each module within the on-board system. The hierarchical model is a way of modeling different parts of the system in layers according to the functional hierarchy. This model can decompose complex systems, structure the top-level functions and bottom-level modules, make system analysis clearer, and facilitate fault location. The overspeed protection top-level function 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 the function and is the core of the entire overspeed protection system.

[0071] S504: construct different mutant models, and combine them with the diagnosability verification algorithm to verify the diagnosability of each mutant operator on the 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 diagnosability verification algorithm is an algorithm used to analyze whether the system can identify and locate specific faults. The diagnosability 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 operation rule for introducing mutations. The mutation operator can define different modification methods, such as perturbations to the system input, output or internal state to create specific fault conditions, thereby observing the response of the system. Observable I / O behavior refers to input and output behaviors that can be observed from the outside during system operation.

[0073] S505: Select component-level fault behaviors corresponding to mutation operators such as diagnosable change actions, and use mutation tools to perform source code-level mutations on sub-functions of the overspeed protection function module.

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

[0075] S506: Extract key submodules 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 operating environment and operating 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 test efficiency and repeatability. Key sub-modules are modules that are critical to function and safety in the system. Key sub-modules usually assume core functions, so separate simulation tests and fault diagnosis on them help identify potential serious problems in the system. Online consistency detection refers to a real-time monitoring technology used to detect whether the system meets expected behavior and design specifications during operation. Through online consistency detection, the system can promptly detect anomalies in operation and effectively improve the timeliness and accuracy of fault diagnosis.

[0077] S507: Combined with the evaluation index, a comparative analysis is performed on the online consistency detection based on the model and the offline mutation mode of the test case set generated by the combination strategy constraint solving algorithm.

[0078] Among them, the evaluation index is the standard or parameter used to measure and evaluate the performance of the fault diagnosis system. The evaluation index may include diagnostic accuracy, recall rate, time cost, etc., to quantify the detection efficiency and effect. The combination strategy constraint solving algorithm is a test case generation algorithm based on the combination strategy, which aims to generate a set of test case sets with wide coverage according to various failure modes of the system. The test case set generated by this algorithm can test various possible failures of the system in a targeted manner. The test case set is a collection of multiple specific test cases, which includes scenarios of various aspects of the test system. A complete test case set can comprehensively cover system functions and failure modes, and is the basis of fault diagnosis and testing.

[0079] S508: Determine the fault diagnosis result of the vehicle software to be diagnosed according to the comparison and analysis result.

[0080] Among them, the fault diagnosis result refers to the final result output through the diagnostic process, including the identified fault type, fault location and possible cause. The fault diagnosis result helps maintenance personnel quickly understand the problem and take appropriate maintenance measures.

[0081] It should be noted that by establishing a comprehensive model and fault injection method, deeply detecting potential faults of the vehicle-mounted software, using mutation operators to construct different fault scenarios, and combining consistent online detection with offline test case set comparative analysis, not only the diagnostic effect of each module in complex scenarios is verified, but also the accuracy and coverage of the diagnostic results are improved. Through comparison and evaluation, we finally obtain an efficient and accurate fault location method, which makes the entire fault diagnosis process more systematic and reliable, and provides a clear basis for subsequent maintenance.

[0082] Reference Manual Attached Figure 4 , showing a schematic diagram of the principle of vehicle-mounted software fault location provided by an embodiment of the present invention.

[0083] Figure 4 In this paper, firstly, a small-scale case of Siemens components and the speed protection function module in the vehicle equipment simulation platform are used as research cases to realize the fault location method based on PSO (particle swarm optimization) and RNNs (recurrent neural network) under different scale cases of single faults, and the fault location effect of the method is compared with that of several classic program spectrum location methods under the condition of imbalanced data sets. Secondly, in a large-scale vehicle equipment simulation platform, the performance of statement suspicion prediction of the RNN recurrent neural network model based on the particle swarm optimization algorithm is compared in a single fault version. Then, in different methods under multiple fault versions generated by different variants of the speed protection sub-function module, the statement inspection rate analysis and comparison combined with the fault location evaluation index are carried out. Finally, through a large number of case studies and analysis of multiple fault versions, it is verified whether the fault location method based on the recurrent neural network optimization model fused with PSO and RNNs can fully combine the program dynamic running behavior information, effectively narrow the scope of vehicle software function-level fault search, and assist vehicle software developers to timely locate the fault efficiency after discovering observable faults, so as to realize vehicle software fault location based on statement coverage features.

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

[0085] Firstly, the statement-level coverage analysis is performed on the functional components to be diagnosed to obtain the valid program primitive sequence. On this basis, the coverage analysis report is parsed, and data collection and preprocessing are performed. According to each fault version obtained after mutation, the statement suspicion is sorted, and the three classic methods based on program spectrum are combined with the method based on PSO and RNNs fusion to analyze the statement-level fault location effect. The process of PSO and RNNs fusion is as follows: the vehicle software to be diagnosed program is selected as the initial sample, and then the segmentation data is extracted from it to form a test set and a training set. Then, the RNNs type statement suspicion prediction model is constructed by training the training set and the RNNs model parameters are optimized and adjusted by the PSO algorithm to make it converge quickly to form the required PSO-RNNs model. Then, the test set is used to verify the effectiveness of the constructed PSO-RNNs type statement suspicion prediction model. Finally, the location performance of the constructed prediction model is compared in different methods under multiple fault versions generated by different variants of the speed protection sub-function module, combined with the statement inspection rate analysis of the fault location evaluation index.

[0086] S6: extracting 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, which helps to analyze and extract useful information during the diagnosis process to support the execution and optimization of fault diagnosis. The statement execution feature data reflects the specific behavior data of the vehicle software during the execution process, covering the execution status of different code statements. These feature data provide fault location clues and support subsequent fault detection and analysis. The program execution spectrum information refers to the execution status of each statement in the software operation and its performance in different fault scenarios, which serves as an important basis for fault location and diagnosis.

[0088] It should be noted that the fault diagnosis data model is used to extract statement features during software execution to form program execution spectrum information to help locate fault points. By structuring complex execution data, it provides clear fault clues and program performance information for subsequent diagnostic analysis, making the diagnostic process more detailed and targeted, greatly improving the efficiency and accuracy of fault location.

[0089] S7: Based on the meta-heuristic algorithm and the neural network algorithm, the suspicion of the program entity of the diagnosed module is predicted, and a suspicion ranking list is obtained to locate the fault.

[0090] Among them, the meta-heuristic algorithm is an optimization algorithm based on nature inspiration, which is used to solve the search for optimal solutions in complex problems. The meta-heuristic algorithm used here is the particle swarm optimization algorithm, which simulates the process of a particle group searching for the optimal position and improves the efficiency of fault location. The neural network algorithm refers to a computational model that simulates the connection between neurons in the human brain and can automatically learn the complex features of data. The recurrent neural network algorithm used here is suitable for processing sequence data or time-related data, and helps analyze the operating data of vehicle-mounted software. The suspicion sorting list is a sorted list used to mark the possibility of errors in each code segment (or module) in the program. It uses suspicion prediction to sort different areas in the program from high to low according to "suspicion".

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

[0092] In a possible implementation, the meta-heuristic algorithm is a particle swarm optimization algorithm, and the neural network algorithm is a recurrent neural network algorithm.

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

[0094] S701: A small-scale case study of Siemens components and the speed protection function module in the vehicle equipment simulation platform is used as a case study.

[0095] Among them, the small-scale cases of Siemens components refer to small-scale test cases conducted using standardized test components provided by Siemens. They are usually included in a set of public data sets 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 benchmarking in industrial applications. The vehicle-mounted equipment simulation platform is a platform for simulating vehicle-mounted systems and software operating environments. It can simulate various working states and operating environments of vehicle-mounted equipment, generate relevant operating data and fault information, and be used to test and verify the effectiveness of fault diagnosis algorithms.

[0096] S702: Construct a fault location method based on a combination of particle swarm optimization algorithm and recurrent neural network algorithm:

[0097] Get 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 by the particle swarm optimization algorithm until a preset number of iterations is reached.

[0101] A RBF neural network including an input layer, an output layer and a hidden layer is constructed, wherein the hidden layer uses a Gaussian basis function as an activation function, and the input layer and the output layer contain a plurality of memory neurons.

[0102] The optimal linear mapping relationship from hidden neurons to output neurons of the RBF neural network is calculated by Moore-Penrose pseudo-inverse.

[0103] The suspiciousness is calculated according to the optimal linear mapping relationship, and the suspicious statements are sorted:

[0104]

[0105] in, Indicates the suspiciousness of the jth statement, , m represents the total number of statements.

[0106] Sort the statements from most suspicious to least suspicious until you find the fault.

[0107] Update the particle position and velocity based on the performance indicators and record the global optimal solution.

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

[0109] The new fault data is input into the trained recurrent neural network model to locate the fault.

[0110] Among them, the particle swarm optimization algorithm is an optimization algorithm based on swarm intelligence, which simulates the behavior of bird flocks foraging or fish schools swimming. The particle group continuously adjusts its position in the search space to seek the optimal solution. In fault location, the particle swarm optimization algorithm can be used to explore the most likely location of the fault, and improve the efficiency and accuracy of fault diagnosis by continuously optimizing the positioning process. The recurrent neural network algorithm is a neural network model, which is particularly suitable for processing sequence data or time series data. The recurrent neural network can remember and use the context information of previous data. In vehicle software fault diagnosis, it can analyze the system's timing data to more accurately locate the time and location of the fault. The fault location method is a method or process for identifying the location of software faults. By combining the particle swarm optimization algorithm and the recurrent neural network algorithm, a fault location method is constructed, which can perform in-depth analysis of the program and generate suspected areas of faults, thereby quickly and accurately locking the problem area.

[0111] S703: Under the condition of imbalanced data sets, the fault location effect of the fault location method is compared and analyzed with that of the classic program spectrum location method.

[0112] Among them, the imbalanced data set condition refers to the situation where the amount of data of different categories in the data set is unbalanced. In the fault diagnosis scenario, the number of fault data of different types or locations may vary greatly, causing the model to be more inclined to detect fault types with higher frequency and ignore rare faults. The classic program spectrum positioning method refers to a traditional fault positioning technology that collects the execution path (ie, "program spectrum") information of the program and analyzes the execution frequency and behavior of each code segment at runtime to identify the code location that may contain faults. This method is suitable for a wider range of fault types, but under the condition of data imbalance, its effect may not be as flexible as modern algorithms.

[0113] S704: According to the comparison and analysis results, predict the suspicion of the program entity of the diagnosed module to obtain a suspicion ranking list.

[0114] Among them, the program entity refers to the code module or functional unit actually executed in the vehicle software. In fault diagnosis, the program entity is the object of suspicion sorting, that is, each element in the list points to a specific code segment or module to locate the fault.

[0115] S705: According to the suspicion ranking list, various variant fault versions are generated in the speed protection function module to simulate various fault conditions.

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

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

[0118] S707: According to the location results of different variant faults, a large number of cases of various variant fault versions are studied and analyzed to obtain the fault location result of the vehicle software to be diagnosed.

[0119] It should be noted that by combining meta-heuristic algorithms and neural network algorithms, the suspicion-ranked list is used to efficiently locate faults in vehicle software. These steps gradually refine the fault analysis process, starting from actual cases, building a fault location method, and verifying it by generating variant fault versions and simulating multiple fault scenarios. Compared with traditional methods, it can more accurately identify and locate faults in complex software systems, improve diagnostic efficiency and accuracy, and at the same time address data imbalance problems and enhance robustness.

[0120] The beneficial effects brought about by the technical solution provided by the embodiment of the present invention include at least:

[0121] In the present invention, the fault diagnosability of the system is judged by verifying the program control timing and model mutation operators, and the physical symbols and the actual data streams are associated based on the fault diagnosability verification results. Then, the acquired measured data is input into the vehicle software fault diagnosis physical model, and based on the mapping relationship between the physical symbols and the real data streams, the fault versions of different mutation operators are output. The fault versions are analyzed by the time relative consistency relationship detection algorithm to generate the fault diagnosis results of the vehicle software to be diagnosed. Furthermore, in the fault diagnosis process, the vehicle software fault diagnosis data model is used to extract the characteristic information of program execution, and the program execution spectrum is formed to provide deep information for fault location. Finally, the meta-heuristic algorithm and the neural network algorithm are combined to generate a suspicion ranking list of fault location to achieve fault location. This method is based on a new type of on-board software fault diagnosis method for train control systems driven by both models and data, and adopts a parallel fusion structure. That is, the data model and the physical model are used together to realize on-board software fault version analysis and fault diagnosis. It has good flexibility and high detection efficiency, effectively avoids the generation process of a large number of test suites and ensures detection accuracy, and can effectively improve program debugging efficiency and fault location inspection rate. It is particularly suitable for the diagnosis of small sample code snippets of large-scale software fault versions to discover software defects in most fault versions. It can realize online and accurate diagnosis of on-board software faults of new train control systems during runtime, provide safety protection for driving operation, thereby greatly improving the accuracy, real-time and adaptability of diagnosis, and improving fault location efficiency.

[0122] Reference Manual Attached Figure 5 , showing a structural schematic diagram of a model- and data-driven in-vehicle software fault diagnosis system provided by the present invention.

[0123] The present invention further provides a vehicle-mounted software fault diagnosis system 20 based on model and data drive, which is applied to the above-mentioned vehicle-mounted software fault diagnosis method based on model and data drive, comprising:

[0124] Processor 201.

[0125] The memory 202 stores computer-readable instructions. When the computer-readable instructions are executed by the processor 201 , the model-based and data-driven vehicle software fault diagnosis method of the method embodiment is implemented.

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

[0127] The beneficial effects brought about by the technical solution provided by the embodiment of the present invention include at least:

[0128] In the present invention, the fault diagnosability of the system is judged by verifying the program control timing and model mutation operators, and the physical symbols and the actual data streams are associated based on the fault diagnosability verification results. Then, the acquired measured data is input into the vehicle software fault diagnosis physical model, and based on the mapping relationship between the physical symbols and the real data streams, the fault versions of different mutation operators are output. The fault versions are analyzed by the time relative consistency relationship detection algorithm to generate the fault diagnosis results of the vehicle software to be diagnosed. Furthermore, in the fault diagnosis process, the vehicle software fault diagnosis data model is used to extract the characteristic information of program execution, and the program execution spectrum is formed to provide deep information for fault location. Finally, the meta-heuristic algorithm and the neural network algorithm are combined to generate a suspicion ranking list of fault location to achieve fault location. This method is based on a new type of on-board software fault diagnosis method for train control systems driven by both models and data, and adopts a parallel fusion structure. That is, the data model and the physical model are used together to realize on-board software fault version analysis and fault diagnosis. It has good flexibility and high detection efficiency, effectively avoids the generation process of a large number of test suites and ensures detection accuracy, and can effectively improve program debugging efficiency and fault location inspection rate. It is particularly suitable for the diagnosis of small sample code snippets of large-scale software fault versions to discover software defects in most fault versions. It can realize online and accurate diagnosis of on-board software faults of new train control systems during runtime, provide safety protection for driving operation, thereby greatly improving the accuracy, real-time and adaptability of diagnosis, and improving fault location efficiency.

[0129] It should be understood that the processor in the embodiment of the present invention may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0130] It should also be understood that the memory in the embodiments of the present invention may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link 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. When implemented by software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When a computer instruction or computer program is loaded or executed on a computer, a process or function according to an embodiment of the present invention is generated in whole or in part. 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 computer-readable storage medium. For example, computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center by wired (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that contains one or more available media sets. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a tape), an optical medium (for example, a DVD), or a semiconductor medium. The semiconductor medium can be a solid-state hard disk.

[0132] It should be understood that the term "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. A and B can be singular or plural. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship, but it may also indicate an "and / or" relationship. Please refer to the context for specific understanding.

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

[0134] It should be understood that in various embodiments of the present invention, the size of the serial numbers of the above-mentioned processes does not mean 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 appreciate that the units and algorithm steps of each example 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 performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0136] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described equipment, devices and units can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0137] In the several embodiments provided by the present invention, it should be understood that the disclosed devices, apparatuses and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

[0139] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0140] If the function is implemented in the form of 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 the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods of various embodiments of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc., various media that can store program codes.

[0141] An embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon. When the program is executed by a processor, a model- and data-driven vehicle software fault diagnosis method as described in the method embodiment is implemented.

[0142] A computer-readable storage medium provided by the present invention can implement the steps and effects of the model- and data-driven vehicle software fault diagnosis method of the above-mentioned method embodiment. To avoid repetition, the present invention will not go into details.

[0143] The beneficial effects brought about by the technical solution provided by the embodiment of the present invention include at least:

[0144] In the present invention, the fault diagnosability of the system is judged by verifying the program control timing and model mutation operators, and the physical symbols and the actual data streams are associated based on the fault diagnosability verification results. Then, the acquired measured data is input into the vehicle software fault diagnosis physical model, and based on the mapping relationship between the physical symbols and the real data streams, the fault versions of different mutation operators are output. The fault versions are analyzed by the time relative consistency relationship detection algorithm to generate the fault diagnosis results of the vehicle software to be diagnosed. Furthermore, in the fault diagnosis process, the vehicle software fault diagnosis data model is used to extract the characteristic information of program execution, and the program execution spectrum is formed to provide deep information for fault location. Finally, the meta-heuristic algorithm and the neural network algorithm are combined to generate a suspicion ranking list of fault location to achieve fault location. This method is based on a new type of on-board software fault diagnosis method for train control systems driven by both models and data, and adopts a parallel fusion structure. That is, the data model and the physical model are used together to realize on-board software fault version analysis and fault diagnosis. It has good flexibility and high detection efficiency, effectively avoids the generation process of a large number of test suites and ensures detection accuracy, and can effectively improve program debugging efficiency and fault location inspection rate. It is particularly suitable for the diagnosis of small sample code snippets of large-scale software fault versions to discover software defects in most fault versions. It can realize online and accurate diagnosis of on-board software faults of new train control systems during runtime, provide safety protection for driving operation, thereby greatly improving the accuracy, real-time and adaptability of diagnosis, and improving fault location efficiency.

[0145] The above are only specific embodiments of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art who is familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

[0146] There are a few points to note:

[0147] (1) The drawings of the embodiments of the present invention only relate to the structures related to the embodiments of the present invention. Other structures may refer to the general design.

[0148] (2) For the sake of clarity, in the drawings used to describe the embodiments of the present invention, the thickness of layers or regions is exaggerated or reduced, that is, these drawings are not drawn according to the actual scale. It is understood that when an element such as a layer, film, region or substrate is referred to as being "on" or "under" another element, the element may be "directly" "on" or "under" the other element or there may be intermediate elements.

[0149] (3) In the absence of conflict, the embodiments of the present invention and the features therein may be combined with each other to obtain new embodiments.

[0150] The above are only specific embodiments of the present invention, but the protection scope of the present invention is not limited thereto. The protection scope of the present invention shall be based on the protection scope of the claims.

Claims

1. A vehicle software fault diagnosis method based on model and data driving, characterized in that: include: S1: Fault diagnosability verification based on program control timing and model mutation operators; S2: Based on the fault diagnosability verification results, complete the configuration of the middleware from the actual software and model interface, and establish the mapping relationship between physical symbols and real data flows; S3: obtaining actual measured data of the vehicle software to be diagnosed; S4: inputting the measured data into a physical model for vehicle software fault diagnosis, and outputting fault versions of different mutation operators based on a mapping relationship between physical symbols and real data streams; S5: Analyze the fault version through a time relative consistency relationship detection algorithm to generate a fault diagnosis result of the vehicle software to be diagnosed; S6: extracting 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 the meta-heuristic algorithm and the neural network algorithm, the suspicion of the program entity of the diagnosed module is predicted, and a suspicion ranking list is obtained to locate the fault.

2. The vehicle software fault diagnosis method based on model and data drive according to claim 1 is characterized in that: The S1 specifically includes: S101: Based on the program control timing and model mutation operator, the I / O channel behavior of the vehicle equipment software specification function model is mutated; S102: construct a diagnosable fault model based on the fault behavior model, and perform fault diagnosability verification in combination with the verification theorem to obtain various diagnosable fault behaviors.

3. The vehicle software fault diagnosis method based on model and data drive according to claim 1, characterized in that: The measured data include: Train monitoring terminal data, on-board monitoring terminal data, dispatching monitoring terminal data and monitoring data output by trackside monitoring terminals.

4. The vehicle software fault diagnosis method based on model and data drive according to claim 1, characterized in that: The S5 specifically includes: S501: By using the time relative consistency relationship detection algorithm, taking the overspeed protection function as the research object, analyzing the I / O environment interface parameters and the requirement specifications of the key submodules in the overspeed protection function; S502: According to the requirement specification, the line topology structure of the model detection application phase is designed in combination with the environmental parameters, and the environmental model and the implementation model are divided; S503: According to the division results of the environment model and the implementation model, a hierarchical model of the requirement specification function modules corresponding to the environment model and the diagnosed subsystem is established, and the I / O function variation is performed from the timing state around the overspeed protection top-level function model; S504: construct different mutant models, and verify the diagnosability of each mutant operator on the observable I / O behavior by combining the diagnosability verification algorithm; S505: Select component-level fault behaviors corresponding to mutation operators such as diagnosable change actions, and use mutation tools to perform source code-level mutations on sub-functions of the overspeed protection function module; S506: extract key submodules from the simulation test platform, and establish a consistency online detection simulation application platform for mutation; S507: combining the evaluation index, performing comparative analysis on the online consistency detection based on the model and the offline mutation mode of the test case set generated by the combination strategy constraint solving algorithm; S508: Determine the fault diagnosis result of the vehicle-mounted software to be diagnosed according to the comparison and analysis result.

5. The vehicle software fault diagnosis method based on model and data drive 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.

6. The vehicle software fault diagnosis method based on model and data drive according to claim 1, characterized in that: The S7 specifically includes: S701: A small-scale case study of Siemens components and the speed protection function module in the vehicle equipment simulation platform; S702: construct a fault location method based on a combination of a particle swarm optimization algorithm and a recurrent neural network algorithm; S703: Under the condition of an unbalanced data set, a comparative analysis is performed on the fault location effect of the fault location method and the classic program spectrum location method; S704: predicting the suspiciousness of the program entity of the diagnosed module according to the comparison and analysis result, and obtaining a suspicion ranking list; S705: According to the suspiciousness sorting list, various variant fault versions are generated in the speed protection function module to simulate various fault conditions; S706: Apply the fault location method and the classic fault location method respectively to locate the fault of each variant fault version; S707: According to the positioning results of the different variant faults, a large number of cases of each variant fault version are studied and analyzed to obtain the fault positioning result of the vehicle-mounted software to be diagnosed.

7. The vehicle software fault diagnosis method based on model and data drive according to claim 6 is characterized in that: The S702 specifically includes: S7021: Get software log data; S7022: Cleaning and normalizing the software log data; S7023: Using the processed software log data as a training set, and inputting it into the recurrent neural network for training; S7024: Optimizing the recurrent neural network by using the particle swarm optimization algorithm until a preset number of iterations is reached; S7025: constructing an RBF neural network including an input layer, an output layer and a hidden layer, wherein the hidden layer uses a Gaussian basis function as an activation function, and the input layer and the output layer include a plurality of memory neurons; S7026: Calculate the optimal linear mapping relationship from hidden neurons to output neurons of the RBF neural network by using Moore-Penrose pseudo-inverse; S7027: Calculate the suspiciousness according to the optimal linear mapping relationship, and sort the suspicious statements: ； in, Indicates the suspiciousness of the jth statement, , m represents the total number of statements; S7028: Sort the statements from high to low according to the suspicion until the fault is found; S7029: Update the particle position and velocity based on the performance index and record the global optimal solution; S70210: When the stop condition is met, select the optimal model; S70211: Input the fault data into the trained recurrent neural network model to locate the fault.

8. The vehicle software fault diagnosis method based on model and data drive according to claim 7 is characterized in that: The stopping condition is specifically that the maximum number of iterations is reached or the performance improvement is not obvious.

9. A model- and data-driven vehicle software fault diagnosis system, characterized in that: include: processor; A memory having computer-readable instructions stored thereon, wherein when the computer-readable instructions are executed by the processor, the model- and data-driven vehicle software fault diagnosis method according to any one of claims 1 to 8 is implemented.

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

Images