Train debugging hidden fault identification method, device, equipment and medium
By constructing a debugging permission fault code library and a process step-fault code rule library, the problem of the inability to identify hidden fault codes in a timely manner during the debugging of rail vehicles was solved, achieving efficient screening and identification, reducing the rate of missed and false judgments, and simplifying the fault investigation process.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CRRC TANGSHAN CO LTD
- Filing Date
- 2025-12-30
- Publication Date
- 2026-05-12
AI Technical Summary
During the commissioning of existing rail vehicles, there is a problem that hidden fault codes cannot be identified in a timely manner. Relying on manual experience for judgment is inefficient and prone to omissions, especially for fault codes that are reported in a flash or cleared after a power outage.
By constructing a debug license fault code library and a process-fault code rule library, and filtering based on real-time fault code data, the system identifies real fault codes and hidden fault codes to be verified, achieving efficient screening of fault codes by relying on the basic debug fault dataset.
It reduced the rate of missed and false diagnoses, simplified the troubleshooting process, and improved the efficiency of identifying hidden faults.
Smart Images
Figure CN122024352A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, equipment and medium for identifying latent faults in train debugging. Background Technology
[0002] Existing rail vehicles, such as EMU trains, urban rail vehicles, or other passenger vehicles, have their software fully uploaded and functional during train commissioning at the vehicle factory, and already possess vehicle fault diagnosis capabilities. During vehicle commissioning, a large number of fault codes are generated due to the commissioning work, including some hidden fault codes that cannot be identified in a timely manner.
[0003] Some systems rely on manual recording, electronic input, and statistical analysis of fault codes, but this is inefficient and prone to omissions, especially since they cannot capture fault codes that are reported in a flash or cleared after a power outage in a timely manner. Summary of the Invention
[0004] This application provides a method, apparatus, equipment, and medium for identifying latent faults during train commissioning, in order to improve the efficiency of latent fault identification.
[0005] In a first aspect, embodiments of this application provide a method for identifying latent faults during train commissioning, including:
[0006] Acquire the basic dataset of debugging faults of the target train, the basic support data for the debugging process of the target train, and the real-time fault code data generated during the debugging process of the target train.
[0007] Based on the basic dataset of debugging faults, a debugging license fault code library and a process step-fault code rule library are constructed respectively.
[0008] Based on the basic support data for debugging, the debugging license fault code library, and the process step-fault code rule library, the real-time fault code data is filtered to obtain the real fault codes generated during the target debugging process and the hidden fault codes to be verified.
[0009] Based on the actual fault codes and the hidden fault codes to be verified, the hidden faults generated by the target train during the target commissioning process are identified.
[0010] In one possible implementation, in conjunction with the first aspect, the debugging fault baseline dataset contains multiple historical fault codes and their associated information; the associated information includes routine debugging files, daily operating conditions, special train operating conditions, and historical train faults; based on the debugging fault baseline dataset, a debugging permission fault code library and a step-fault code rule library are constructed, including:
[0011] Based on the historical fault codes and their associated information, the following are generated: the first historical fault code corresponding to each test chapter in the routine debugging file, the second historical fault code corresponding to daily operating conditions, the third historical fault code corresponding to special train operating conditions, and the fourth historical fault code corresponding to actual historical faults of the train.
[0012] Based on the first historical fault code, a trial chapter license fault code library is generated for each trial chapter.
[0013] A daily operation permission fault code library is generated based on the second historical fault code.
[0014] Based on the third historical fault code, a special operating condition permission fault code library is generated.
[0015] A real fault code library is generated based on the fourth historical fault code.
[0016] A debug permission fault code library is constructed based on the experimental chapter permission fault code library, the daily operation permission fault code library, the special working condition permission fault code library, and the real fault code library.
[0017] Based on the relationship between each fault code in the test chapter's permission fault code library and each key step in the test chapter, a step-fault code rule library is generated.
[0018] In one possible implementation, in conjunction with the first aspect, before filtering real-time fault code data based on debugging foundation support data, a debugging license fault code library, and a process-fault code rule library to obtain the actual fault codes generated during the target debugging process and the hidden fault codes to be verified, the method further includes:
[0019] After the target train triggers a preset event, the test chapter's permission fault code library is verified and updated.
[0020] After the debugging process documents in the basic support data are changed, the process step-fault code rule base is improved according to the changed debugging process documents.
[0021] In one possible implementation, in conjunction with the first aspect, after the target train triggers a preset event, the test chapter's permitted fault code library is verified and updated, including:
[0022] Obtain historical fault data for the target train and other trains; the other trains are the same model and software version as the target train listed.
[0023] The historical fault data is compared with the test chapter license fault code library to obtain the verification result of the test chapter license fault code library.
[0024] Receive the audit results for the verification results.
[0025] Based on the review results, update the trial chapter license fault code library.
[0026] In one possible implementation, in conjunction with the first aspect, the basic support data for debugging includes debugging process documents corresponding to the target debugging process, real-time vehicle status data during the target debugging process, and real-time test progress; based on the basic support data for debugging, the debugging permit fault code library, and the step-fault code rule library, the real-time fault code data is filtered to obtain the actual fault codes generated during the target debugging process and the implicit fault codes to be verified, including:
[0027] Based on the debugging process documents and step-fault code rule library corresponding to the target debugging process, a fault code criterion library is generated.
[0028] Based on the real-time test progress during the target debugging process, the fault code criterion library, and the step-fault code rule library, the fault code data is filtered and eliminated to obtain the first candidate fault code set.
[0029] Based on real-time vehicle status data during the target debugging process, a second candidate fault code set is determined from the first candidate fault code set by matching the daily operation permission fault code library and the special working condition permission fault code library.
[0030] The intersection of the actual fault code library and the second candidate fault code set is determined as the actual fault code; and the relative complement of the actual fault code library to the second candidate fault code set is determined as the hidden fault code to be verified.
[0031] In one possible implementation, in conjunction with the first aspect, based on the actual fault codes and the latent fault codes to be verified, latent faults generated by the target train during the target commissioning process are identified, including:
[0032] Receive the verification results of the hidden fault codes to be verified.
[0033] Hidden fault codes that have been verified are identified as verified hidden fault codes.
[0034] Based on the actual fault codes and verified hidden fault codes, the hidden faults generated by the target train during the target commissioning process are identified.
[0035] In one possible implementation, in conjunction with the first aspect, the method further includes:
[0036] Obtain historical fault analysis reports.
[0037] A fault analysis and processing library is built based on historical fault analysis reports.
[0038] Accordingly, after identifying the latent faults generated by the target train during the target commissioning process based on the actual fault codes and the latent fault codes to be verified, the method also includes:
[0039] Based on the fault analysis and processing library, processing strategies corresponding to hidden faults are generated.
[0040] Secondly, embodiments of this application provide a train debugging latent fault identification device, comprising:
[0041] The acquisition module is used to acquire the basic dataset of debugging faults of the target train, the basic support data for the debugging process of the target, and the real-time fault code data generated during the debugging process of the target.
[0042] The building module is used to build a debug license fault code library and a process step-fault code rule library based on the debug fault base dataset.
[0043] The filtering module is used to filter real-time fault code data based on debugging basic support data, debugging license fault code library and process step-fault code rule library to obtain the real fault codes generated during the target debugging process and the hidden fault codes to be verified.
[0044] The identification module is used to identify hidden faults generated by the target train during the target commissioning process based on the real fault codes and the hidden fault codes to be verified.
[0045] In one possible implementation, in conjunction with the second aspect, the debugging fault base dataset includes multiple historical fault codes and associated information for each historical fault code; the associated information includes routine debugging files, daily operating conditions, special train operating conditions, and actual historical train faults; the construction module is specifically used for:
[0046] Based on the historical fault codes and their associated information, the following are generated: the first historical fault code corresponding to each test chapter in the routine debugging file, the second historical fault code corresponding to daily operating conditions, the third historical fault code corresponding to special train operating conditions, and the fourth historical fault code corresponding to actual historical faults of the train.
[0047] Based on the first historical fault code, a trial chapter license fault code library is generated for each trial chapter.
[0048] A daily operation permission fault code library is generated based on the second historical fault code.
[0049] Based on the third historical fault code, a special operating condition permission fault code library is generated.
[0050] A real fault code library is generated based on the fourth historical fault code.
[0051] A debug permission fault code library is constructed based on the experimental chapter permission fault code library, the daily operation permission fault code library, the special working condition permission fault code library, and the real fault code library.
[0052] Based on the relationship between each fault code in the test chapter's permission fault code library and each key step in the test chapter, a step-fault code rule library is generated.
[0053] In one possible implementation, in conjunction with the second aspect, the building module is also used for:
[0054] After the target train triggers a preset event, the test chapter's permission fault code library is verified and updated.
[0055] After the debugging process documents in the basic support data are changed, the process step-fault code rule base is improved according to the changed debugging process documents.
[0056] In one possible implementation, in conjunction with the second aspect, the building module is further specifically used for:
[0057] Obtain historical fault data for the target train and other trains; the other trains are the same model and software version as the target train listed.
[0058] The historical fault data is compared with the test chapter license fault code library to obtain the verification result of the test chapter license fault code library.
[0059] Receive the audit results for the verification results.
[0060] Based on the review results, update the trial chapter license fault code library.
[0061] In one possible implementation, in conjunction with the second aspect, the basic support data for debugging includes the debugging process documents corresponding to the target debugging process, real-time vehicle status data during the target debugging process, and real-time test progress; the screening module is specifically used for:
[0062] Based on the debugging process documents and step-fault code rule library corresponding to the target debugging process, a fault code criterion library is generated.
[0063] Based on the real-time test progress during the target debugging process, the fault code criterion library, and the step-fault code rule library, the fault code data is filtered and eliminated to obtain the first candidate fault code set.
[0064] Based on real-time vehicle status data during the target debugging process, a second candidate fault code set is determined from the first candidate fault code set by matching the daily operation permission fault code library and the special working condition permission fault code library.
[0065] The intersection of the actual fault code library and the second candidate fault code set is determined as the actual fault code; and the relative complement of the actual fault code library to the second candidate fault code set is determined as the hidden fault code to be verified.
[0066] In one possible implementation, in conjunction with the second aspect, the identification module is specifically used for:
[0067] Receive the verification results of the hidden fault codes to be verified.
[0068] Hidden fault codes that have been verified are identified as verified hidden fault codes.
[0069] Based on the actual fault codes and verified hidden fault codes, the hidden faults generated by the target train during the target commissioning process are identified.
[0070] In one possible implementation, in conjunction with the second aspect, the acquisition module is further configured to:
[0071] Obtain historical fault analysis reports.
[0072] Correspondingly, building modules are also used for
[0073] A fault analysis and processing library is built based on historical fault analysis reports.
[0074] Accordingly, the device also includes a generation module for:
[0075] Based on the fault analysis and processing library, processing strategies corresponding to hidden faults are generated.
[0076] Thirdly, embodiments of this application provide an electronic device, including: a processor, and a memory communicatively connected to the processor.
[0077] The memory stores the instructions that the computer executes.
[0078] The processor executes computer execution instructions stored in memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.
[0079] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.
[0080] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.
[0081] This application provides a method, apparatus, device, and medium for identifying latent faults during train commissioning. It acquires a basic dataset of commissioning faults for the target train, basic support data for the target commissioning process, and real-time fault code data generated during the target commissioning process. First, based on the basic dataset, a commissioning permit fault code library and a step-by-step fault code rule library are constructed. Then, based on the basic support data, the commissioning permit fault code library, and the step-by-step fault code rule library, the real-time fault code data is filtered to obtain the actual fault codes generated during the target commissioning process and the latent fault codes to be verified. Finally, based on the actual fault codes and the latent fault codes to be verified, the latent faults generated by the target train during the target commissioning process are identified. These technical means, relying on the basic dataset of commissioning faults to construct the commissioning permit fault code library and the step-by-step fault code rule library, achieve efficient fault code filtering, reduce the rate of missed and false judgments, and simplify the fault investigation process, thereby improving the efficiency of latent fault identification. Attached Figure Description
[0082] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0083] Figure 1 A schematic diagram illustrating a method for identifying latent faults during train commissioning, as provided in this application;
[0084] Figure 2 A flowchart illustrating a method for identifying latent faults during train commissioning provided in this application. Figure 1 ;
[0085] Figure 3 A flowchart illustrating a method for identifying latent faults during train commissioning provided in this application. Figure 2 ;
[0086] Figure 4 A flowchart illustrating a method for identifying latent faults during train commissioning provided in this application. Figure 3 ;
[0087] Figure 5 A flowchart for verifying the licensed fault code library in the experimental section of a method for identifying latent faults during train commissioning, provided in this application;
[0088] Figure 6 A flowchart illustrating the key steps in a method for identifying latent faults during train commissioning, as provided in this application.
[0089] Figure 7 A flowchart illustrating the key steps of a train commissioning latent fault identification method provided in this application;
[0090] Figure 8A flowchart illustrating the latent fault code identification process of a latent fault identification method for train commissioning provided in this application;
[0091] Figure 9 A schematic diagram of a train debugging latent fault identification device provided in this application;
[0092] Figure 10 A schematic diagram of the structure of the electronic device provided in this application.
[0093] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation
[0094] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.
[0095] The application background of the embodiments of this application will be explained below:
[0096] Existing rail vehicles, such as EMU trains, urban rail vehicles, or other passenger cars, have their software fully uploaded and functional during train commissioning at the vehicle factory, and already possess vehicle fault diagnosis capabilities. During vehicle commissioning, a large number of fault codes are generated due to the commissioning work, including some latent fault codes that cannot be identified in a timely manner. Some systems rely on manual recording, electronic entry, and statistical analysis of fault codes, but this depends on human experience to judge the rationality of faults, which is inefficient and prone to omissions, especially in capturing flashing faults and fault codes cleared after power outages.
[0097] To address the aforementioned problems, the inventors investigated whether a dynamically updated commissioning permit fault code library could be constructed, and fault codes could be intelligently filtered based on vehicle status data, thereby solving the issues of low efficiency, high reliance on manual intervention, and insufficient adaptation to dynamic operating conditions in train commissioning. The inventors proposed a method for identifying latent faults during train commissioning. This method involves acquiring a basic dataset of commissioning faults for the target train, basic support data for the target commissioning process, and real-time fault code data generated during the target commissioning process. First, based on the basic dataset of commissioning faults, a commissioning permit fault code library and a step-to-fault code rule library are constructed. Then, based on the basic support data, the commissioning permit fault code library, and the step-to-fault code rule library, the real-time fault code data is filtered to obtain the actual fault codes generated during the target commissioning process and the latent fault codes to be verified. Finally, based on the actual fault codes and the latent fault codes to be verified, the latent faults generated by the target train during the target commissioning process are identified. The above technical means, based on the basic dataset of debugging faults, construct a debugging license fault code library and a process step-fault code rule library, to achieve efficient screening of fault codes, reduce the rate of missed and false judgments, simplify the fault investigation process, and improve the efficiency of hidden fault identification.
[0098] Combination Figure 1 This illustrates the specific application scenario of the latent fault identification method for train debugging provided in this application. For example... Figure 1 As shown, the specific application scenario of this application includes an operation and maintenance data platform 101, an intelligent diagnostic system 102, and a technician terminal 103. The operation and maintenance data platform 101 collects fault codes and vehicle operating status generated during the debugging process and transmits them to the intelligent diagnostic system 102. The intelligent diagnostic system 102 has a built-in debugging permission fault code library, a step-fault code rule library, and a fault analysis and processing library. Based on the fault codes and vehicle operating status, it identifies the actual fault codes and the hidden fault codes to be verified from the fault codes generated during the debugging process, and pushes the hidden fault codes to be verified to the technician terminal 103. The technician verifies the hidden fault codes to be verified, obtains the verified hidden fault codes, and returns the verified hidden fault codes to the intelligent diagnostic system 102 through the technician terminal 103. The intelligent diagnostic system 102 identifies the hidden faults based on the actual fault codes and the verified hidden fault codes, and generates the corresponding processing strategies for the hidden faults.
[0099] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.
[0100] Figure 2 A flowchart illustrating a method for identifying latent faults during train commissioning provided in this application. Figure 1 ,like Figure 2 As shown, the method includes:
[0101] S201. Obtain the basic dataset of debugging faults of the target train, the basic support data for debugging of the target debugging process, and the real-time fault code data generated during the debugging process of the target.
[0102] The debugging fault dataset contains multiple historical fault codes and their associated information; the associated information includes routine debugging files, daily operating conditions, special operating conditions of the train, and actual historical faults of the train.
[0103] The basic support data for debugging includes the debugging process documents corresponding to the target debugging process, real-time vehicle status data during the target debugging process, and real-time test progress.
[0104] S202. Based on the debugging fault dataset, construct a debugging license fault code library and a process step-fault code rule library respectively.
[0105] In this step, based on the basic dataset of debugging faults and the types of fault codes generated during train debugging, a debugging permission fault code library is constructed, which includes a test chapter permission fault code library, a daily operation permission fault code library, a special operating condition permission fault code library, and a real fault code library. Simultaneously, based on the test chapter permission fault code library, a step-by-step fault code rule library is generated, laying the data foundation for subsequent fault identification.
[0106] Specifically, based on the historical fault codes and their associated information, the following are generated in the routine debugging file: the first historical fault code corresponding to each test chapter, the second historical fault code corresponding to daily operating conditions, the third historical fault code corresponding to special train operating conditions, and the fourth historical fault code corresponding to actual historical faults of the train.
[0107] Based on the first historical fault code, a trial chapter permission fault code library is generated for each trial chapter; based on the second historical fault code, a daily operation permission fault code library is generated; based on the third historical fault code, a special operating condition permission fault code library is generated; and based on the fourth historical fault code, a real fault code library is generated.
[0108] Finally, a debugging permission fault code library is constructed based on the experimental chapter permission fault code library, the daily operation permission fault code library, the special working condition permission fault code library, and the real fault code library. Furthermore, a step-fault code rule library is generated based on the association between each fault code in the experimental chapter permission fault code library and each key step in the experimental chapter.
[0109] S203. Based on the debugging foundation support data, the debugging license fault code library, and the process step-fault code rule library, the real-time fault code data is filtered to obtain the real fault codes and hidden fault codes to be verified generated during the target debugging process.
[0110] In this step, a fault code criterion library is first generated based on the debugging process documents and the step-fault code rule library corresponding to the target debugging process. Then, based on the real-time test progress during the target debugging process, the fault code criterion library, and the step-fault code rule library, fault code data is filtered and eliminated to obtain a first candidate fault code set. Next, based on the real-time vehicle status data during the target debugging process, a second candidate fault code set is determined from the first candidate fault code set by matching the daily operation permission fault code library and the special operating condition permission fault code library. Finally, the intersection of the actual fault code library and the second candidate fault code set is determined as the actual fault codes; and the relative complement of the actual fault code library to the second candidate fault code set is determined as the latent fault codes to be verified.
[0111] S204. Based on the actual fault codes and the hidden fault codes to be verified, identify the hidden faults generated by the target train during the target commissioning process.
[0112] In this step, the latent fault codes to be verified are first sent to relevant personnel for verification, and the verification results are received. Latent fault codes whose verification results are confirmed are then identified as verified latent fault codes. Subsequently, based on the actual fault codes and the verified latent fault codes, latent faults generated by the target train during the target commissioning process are identified.
[0113] This application provides a method for identifying latent faults during train commissioning. The method acquires a basic dataset of commissioning faults for the target train, basic support data for the target commissioning process, and real-time fault code data generated during the target commissioning process. First, based on the basic dataset, a commissioning permit fault code library and a step-by-step fault code rule library are constructed. Then, based on the basic support data, the commissioning permit fault code library, and the step-by-step fault code rule library, the real-time fault code data is filtered to obtain the actual fault codes generated during the target commissioning process and the latent fault codes to be verified. Finally, based on the actual fault codes and the latent fault codes to be verified, the latent faults generated by the target train during the target commissioning process are identified. These technical means, relying on the basic dataset of commissioning faults to construct the commissioning permit fault code library and the step-by-step fault code rule library, achieve efficient fault code filtering, reduce the rate of missed and false positives, and simplify the fault investigation process, thereby improving the efficiency of latent fault identification.
[0114] Figure 3A flowchart illustrating a method for identifying latent faults during train commissioning provided in this application. Figure 2 ,like Figure 3 As shown, in this embodiment... Figure 2 Based on the embodiments, S202 will be described in detail. The method includes:
[0115] S301. Based on each historical fault code and its associated information, generate the first historical fault code, the second historical fault code, the third historical fault code, and the fourth historical fault code.
[0116] In this step, based on the historical fault codes and their associated information, and according to the types of fault codes generated during train commissioning, corresponding fault codes are generated by combining routine commissioning documents, daily operating conditions, special operating conditions of the train, and actual historical faults of the train.
[0117] Specifically, based on the historical fault codes and their associated information, the following are generated in the routine debugging file: the first historical fault code corresponding to each test chapter, the second historical fault code corresponding to daily operating conditions, the third historical fault code corresponding to special train operating conditions, and the fourth historical fault code corresponding to actual historical faults of the train.
[0118] S302. Based on the first historical fault code, generate a test chapter license fault code library for each test chapter.
[0119] In this step, the first historical fault code and its corresponding fault code in the test chapter's licensed fault code library are fault codes caused by routine debugging and testing operations, that is, fault codes triggered by debugging personnel following the debugging process documents.
[0120] S303. Generate a daily operation permission fault code library based on the historical second fault code.
[0121] In this step, the historical second fault code and its corresponding fault code in the daily operation permission fault code library are fault codes generated by some daily operations outside of routine tests, such as opening doors and powering off.
[0122] S304. Generate a special operating condition permission fault code library based on the third historical fault code.
[0123] In this step, the third historical fault code and the corresponding fault code in the special operating condition permission fault code library are fault codes that will continue to be generated before leaving the factory due to special operating conditions, in addition to routine tests. For example, faults caused by lack of water, no high pressure, and low vehicle air pressure.
[0124] S305. Generate a real fault code library based on the fourth historical fault code.
[0125] In this step, the fourth historical fault code and its corresponding fault code in the real fault code library are real fault codes, and the corresponding faults are the faults that need to be identified and handled during the debugging phase.
[0126] S306. Based on the experimental chapter license fault code library, the daily operation license fault code library, the special working condition license fault code library, and the real fault code library, construct the debugging license fault code library.
[0127] S307. Based on the relationship between each fault code in the test chapter's permission fault code library and each key step in the test chapter, generate a step-fault code rule library.
[0128] In this step, based on all the fault codes contained in the fault code library of the test chapter, a one-to-one mapping relationship between the key steps and the corresponding fault codes is constructed for each key step divided in the test chapter. Based on this, a step-fault code rule library for fault determination is generated.
[0129] This application provides a method for identifying latent faults during train commissioning. By generating historical first fault codes corresponding to each test chapter in routine commissioning files, historical second fault codes corresponding to daily operating conditions, historical third fault codes corresponding to special train operating conditions, and historical fourth fault codes corresponding to actual train faults, based on historical fault codes and their associated information, the method generates separate libraries for each type of fault code: test chapter permitted fault code library, daily operating condition permitted fault code library, special operating condition permitted fault code library, and actual fault code library. A commissioning permitted fault code library is then constructed based on these four libraries. Simultaneously, a step-fault code rule library is generated based on the association between each fault code in the test chapter permitted fault code library and each key step in the test chapter. These technical means standardize and aggregate multiple types of fault codes, construct a complete fault code library system, establish precise associations between steps and fault codes, and form a standardized rule library. This provides accurate basis for fault screening and diagnosis, achieving the effect of improving commissioning standardization and efficiency.
[0130] Figure 4 A flowchart illustrating a method for identifying latent faults during train commissioning provided in this application. Figure 3 ,like Figure 4 As shown, this embodiment, based on any of the above embodiments, provides a detailed description of a method for identifying latent faults during train commissioning. The method includes:
[0131] S401. Obtain the basic dataset of debugging faults of the target train, the basic support data for debugging of the target, and the real-time fault code data generated during the debugging process of the target.
[0132] For a detailed description of this step, please refer to the relevant content of S201 in the above embodiment, which will not be repeated here.
[0133] S402. Based on the basic dataset of debugging faults, construct a debugging license fault code library and a process step-fault code rule library respectively.
[0134] For a detailed description of this step, please refer to the relevant content in S202 and S301~S307 of the above embodiments, which will not be repeated here.
[0135] S403. Verify and update the test chapter's license fault code library.
[0136] In this step, after the target train triggers a preset event, the permitted fault code library for the test section is verified and updated. The preset event is either the target train completing a full round of commissioning tests, or a change in the version of the target train's onboard control system.
[0137] Specifically, historical fault data of the target train and other trains is obtained, and this historical fault data is compared with the experimental chapter's permitted fault code library to obtain the verification result of the experimental chapter's permitted fault code library. The verification result is sent to relevant personnel, and the personnel's review results are received. Based on the review results, the experimental chapter's permitted fault code library is updated. Note that the other trains listed must be the same model and train software version as the target train.
[0138] In one possible implementation, the verification process for the test chapter permission fault code library of the target train is as follows: Figure 5 As shown, the start and end times of the target test section are first determined from the executed process documents of multiple trains. Then, by going back and delaying by a certain amount of time, the start and end time periods of the fault codes are determined, thus determining the fault code time period.
[0139] Subsequently, based on the process step-fault code rule base, each key process step in the executed process document is mapped to a fault code mapping table. Historical fault codes within the specified time period are retrieved from the target train's historical fault data to form a historical fault code table. It is then determined whether the historical fault code table matches the fault code mapping table. If yes, the next section on fault code verification proceeds; otherwise, it is further determined whether the historical fault code table contains redundant or missing codes compared to the fault code mapping table.
[0140] If there are redundant codes in the historical fault codes, first determine whether they are routine operation codes or special operating condition codes based on the routine operation permission fault code library and the special operating condition permission fault code library. If so, proceed to the next chapter for fault code verification; otherwise, perform multi-dimensional verification:
[0141] First, verify whether the fault codes of the target train (this train) appear regularly within a certain time range before and after the historical fault code appears in other time periods. If the result is yes, give a prompt message and statistical data. If the result is no, then verify whether the same pattern exists in the historical fault data of other trains, and whether there are multiple identical fault codes. If the result is yes, give a prompt message and statistical data. Otherwise, proceed to the next chapter for fault code verification.
[0142] If there are missing codes in the historical fault codes, for the missing fault codes, query the historical fault code data of other trains in the corresponding fault code time period of the target test chapter to see if the missing fault code is also not present. If the result is yes, give a prompt message and statistical data; otherwise, proceed to the next chapter for fault code verification.
[0143] Ultimately, based on the prompts and statistical data, relevant staff decided to update the trial chapter's license fault code library.
[0144] S404, Improve the process steps - fault code rule base.
[0145] In this step, after the debugging process documents in the basic support data are changed, the process step-fault code rule base is improved according to the changed debugging process documents.
[0146] Specifically, when improving the step-fault code rule base based on the revised debugging process documents, the accuracy of the key step descriptions can be verified by comparing the key step similarity between the debugging process documents and other debugging process documents.
[0147] In one possible implementation, the key process verification procedure is as follows: Figure 6 As shown, the process first extracts the target critical step and its corresponding fault code from the process-fault code rule base, and then determines whether there are any critical steps in other debugging process files that are highly similar to the target critical step. If not, the next critical step is verified directly; if so, the same critical step is judged.
[0148] The process for identifying identical key steps is as follows: First, determine the test section of the highly similar step. Then, search the corresponding test section in the step-fault code rule base to determine if there is a key step and fault code in the test section that is completely identical to the target key step. If yes, proceed to verify the next key step keyword; otherwise, determine that the key steps in the step-fault code rule base are incomplete or incorrect, and re-verify the key step information.
[0149] The above technical methods, through cross-process document step similarity comparison and chapter permission fault codes, verify the accuracy of key step descriptions and improve the mapping association between key steps and fault codes.
[0150] S405. Before commissioning begins, a fault code criterion library is generated based on the commissioning process documents and the step-fault code rule library.
[0151] In this step, a fault code criterion library is generated based on the debugging process documents and the step-fault code rule library corresponding to the target debugging process.
[0152] Specifically, before the commissioning begins, the commissioning process document corresponding to this commissioning is matched with the step-fault code rule library, and a fault code criterion library corresponding to each key step in the commissioning process document is formed, with the test chapter as the unit.
[0153] In one possible implementation, if the debugging process document changes after the debugging begins, the changes in the debugging process document are automatically identified, and the fault code criterion library is adjusted accordingly.
[0154] S406. After debugging begins, based on the debugging foundation support data, fault code criterion library, debugging permission fault code library, and process step-fault code rule library, the real-time fault code data is filtered to obtain the real fault codes generated during the target debugging process and the hidden fault codes to be verified.
[0155] In this step, fault code data is first filtered and eliminated based on the real-time test progress during the target debugging process, the fault code criterion library, and the process-fault code rule library to obtain a first candidate fault code set. Then, based on the real-time vehicle status data during the target debugging process, a second candidate fault code set is determined from the first candidate fault code set by matching the daily operation permission fault code library and the special operating condition permission fault code library. Finally, the intersection of the actual fault code library and the second candidate fault code set is determined as the actual fault codes; and the relative complement of the actual fault code library to the second candidate fault code set is determined as the latent fault codes to be verified.
[0156] Specifically, after debugging begins, due to operational habits, work step information generally lags behind fault code information. Therefore, a preliminary judgment is first made on the real-time fault code data using a fault code criterion library. After obtaining the real-time test progress, based on the key work step information in the real-time test progress, codes that do not match the fault code criterion library and the work step-fault code rule library are identified, forming a first candidate fault code set. Subsequently, by matching the daily operation permission fault code library and the special working condition permission fault code library, a second candidate fault code set that does not belong to either of these libraries is determined from the first candidate fault code set. Finally, the intersection of the actual fault code library and the second candidate fault code set is determined as the actual fault code; and the relative complement of the actual fault code library in the second candidate fault code set is determined as the latent fault code to be verified.
[0157] In one possible implementation, key steps need to be vectorized to achieve the key step similarity comparison and fault code criterion generation mentioned above. The key step vector calculation process is as follows: Figure 7 As shown, key steps are first extracted from the debugging process documents, and text preprocessing operations such as word segmentation, cleaning, and normalization are performed sequentially. Then, a pre-trained word embedding model containing industry-specific vocabulary is called to generate numerical word vectors. Subsequently, based on the numerical word vectors, the following processes are performed in sequence: intelligent learning sentence encoding processing (using deep learning sentence encoders such as BERT / LSTM); capturing complex relationships between words through contextual semantic modeling and fusion; and information aggregation processing through pooling. Finally, fixed-dimensional sentence vectors of key steps are obtained, realizing the semantic and numerical representation of key step texts.
[0158] In one possible implementation, the hierarchical screening process from fault codes to latent fault codes to be verified is as follows: Figure 8 As shown, using fault codes as input, the process first involves verifying the permissible codes for each chapter of routine tests (corresponding to the permissible fault code criterion library for each test chapter) to complete the initial screening of the first candidate fault code set. Next, the process sequentially matches the daily operation permissible fault code library and the special operating condition permissible fault code library, incorporating comprehensive vehicle status verification to determine the second candidate fault code set from the first candidate set. In this process, codes conforming to the rules of each library are considered permissible fault codes. Finally, the process matches the actual fault code library, and ultimately, based on the second candidate fault code set, distinguishes between actual fault codes and latent fault codes awaiting verification.
[0159] S407. Based on the hidden fault codes to be verified, the verified hidden fault codes are determined.
[0160] In this step, the hidden fault codes to be verified are first sent to relevant personnel for verification, and the verification results are received. Then, the hidden fault codes whose verification results are confirmed are officially recognized as verified hidden fault codes.
[0161] S408. Based on the actual fault codes and verified hidden fault codes, identify the hidden faults generated by the target train during the target commissioning process.
[0162] In this step, based on the fact that the real fault codes belong to the latent fault codes, the real fault codes and the verified latent fault codes are integrated into the latent fault judgment criteria. Based on the latent fault judgment criteria, the latent faults generated by the target train in the corresponding commissioning stage are identified.
[0163] S409. Generate the handling strategy corresponding to the hidden fault.
[0164] In this step, historical fault analysis reports are first obtained, and a fault analysis and processing library is constructed based on these reports. After identifying latent faults generated during the target train's commissioning process, corresponding processing strategies are generated based on the fault analysis and processing library.
[0165] This application provides a method for identifying latent faults during train commissioning. It acquires a basic dataset of commissioning faults for the target train, basic support data for the target commissioning process, and real-time fault code data generated during the target commissioning process. First, based on the basic dataset, it constructs a commissioning permit fault code library and a step-based fault code rule library. Then, it verifies and updates the test chapter permit fault code library and improves the step-based fault code rule library. Before commissioning begins, a fault code criterion library is generated based on the commissioning process documents and the step-based fault code rule library. After commissioning begins, based on the basic support data, fault code criterion library, commissioning permit fault code library, and step-based fault code rule library, real-time fault code data is filtered to obtain real fault codes and latent fault codes to be verified during the target commissioning process. Subsequently, based on the latent fault codes to be verified, verified latent fault codes are identified. Finally, based on the real fault codes and verified latent fault codes, latent faults generated by the target train during the target commissioning process are identified, and corresponding handling strategies for the latent faults are generated. The above technical means, by constructing a multi-dimensional debugging permission fault code library and a process step-fault code rule library, and dynamically improving both, improve the accuracy of fault screening; by automatically generating corresponding handling strategies for hidden faults, it efficiently assists in debugging and troubleshooting, and achieves the effect of improving debugging accuracy and the efficiency of hidden fault investigation.
[0166] Figure 9 This application provides a structural schematic diagram of a train debugging latent fault identification device, as shown below. Figure 9 As shown, the train debugging latent fault identification device 90 provided in this embodiment includes:
[0167] The acquisition module 901 is used to acquire the basic dataset of debugging faults of the target train, the basic support data of debugging in the target debugging process, and the real-time fault code data generated in the target debugging process.
[0168] Module 902 is used to build a debug license fault code library and a process step-fault code rule library based on the debug fault base dataset.
[0169] The filtering module 903 is used to filter real-time fault code data based on debugging basic support data, debugging license fault code library and process step-fault code rule library to obtain real fault codes generated during the target debugging process and hidden fault codes to be verified.
[0170] The identification module 904 is used to identify hidden faults generated by the target train during the target commissioning process based on the real fault codes and the hidden fault codes to be verified.
[0171] In one possible implementation, the debugging fault base dataset contains multiple historical fault codes and their associated information; the associated information includes routine debugging files, daily operating conditions, special train operating conditions, and actual historical train faults; the construction module 902 is specifically used for:
[0172] Based on the historical fault codes and their associated information, the following are generated: the first historical fault code corresponding to each test chapter in the routine debugging file, the second historical fault code corresponding to daily operating conditions, the third historical fault code corresponding to special train operating conditions, and the fourth historical fault code corresponding to actual historical faults of the train.
[0173] Based on the first historical fault code, a trial chapter license fault code library is generated for each trial chapter.
[0174] A daily operation permission fault code library is generated based on the second historical fault code.
[0175] Based on the third historical fault code, a special operating condition permission fault code library is generated.
[0176] A real fault code library is generated based on the fourth historical fault code.
[0177] A debug permission fault code library is constructed based on the experimental chapter permission fault code library, the daily operation permission fault code library, the special working condition permission fault code library, and the real fault code library.
[0178] Based on the relationship between each fault code in the test chapter's permission fault code library and each key step in the test chapter, a step-fault code rule library is generated.
[0179] In one possible implementation, the building module 902 is further configured to:
[0180] After the target train triggers a preset event, the test chapter's permission fault code library is verified and updated.
[0181] After the debugging process documents in the basic support data are changed, the process step-fault code rule base is improved according to the changed debugging process documents.
[0182] In one possible implementation, the construction module 902 is further specifically used for:
[0183] Obtain historical fault data for the target train and other trains; the other trains are the same model and software version as the target train listed.
[0184] The historical fault data is compared with the test chapter license fault code library to obtain the verification result of the test chapter license fault code library.
[0185] Receive the audit results for the verification results.
[0186] Based on the review results, update the trial chapter license fault code library.
[0187] In one possible implementation, the basic support data for debugging includes the debugging process documents corresponding to the target debugging process, real-time vehicle status data during the target debugging process, and real-time test progress; the screening module 903 is specifically used for:
[0188] Based on the debugging process documents and step-fault code rule library corresponding to the target debugging process, a fault code criterion library is generated.
[0189] Based on the real-time test progress during the target debugging process, the fault code criterion library, and the step-fault code rule library, the fault code data is filtered and eliminated to obtain the first candidate fault code set.
[0190] Based on real-time vehicle status data during the target debugging process, a second candidate fault code set is determined from the first candidate fault code set by matching the daily operation permission fault code library and the special working condition permission fault code library.
[0191] The intersection of the actual fault code library and the second candidate fault code set is determined as the actual fault code; and the relative complement of the actual fault code library to the second candidate fault code set is determined as the hidden fault code to be verified.
[0192] In one possible implementation, the identification module 904 is specifically used for:
[0193] Receive the verification results of the hidden fault codes to be verified.
[0194] Hidden fault codes that have been verified are identified as verified hidden fault codes.
[0195] Based on the actual fault codes and verified hidden fault codes, the hidden faults generated by the target train during the target commissioning process are identified.
[0196] In one possible implementation, the acquisition module 901 is further configured to:
[0197] Obtain historical fault analysis reports.
[0198] Correspondingly, Module 902 is also used for
[0199] A fault analysis and processing library is built based on historical fault analysis reports.
[0200] Accordingly, the device also includes a generation module for:
[0201] Based on the fault analysis and processing library, processing strategies corresponding to hidden faults are generated.
[0202] This embodiment provides a train debugging latent fault identification device, which can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.
[0203] Figure 10 A schematic diagram of the structure of the electronic device provided in this application. Figure 10 As shown, the electronic device 100 provided in this embodiment includes at least one processor 1001 and a memory 1002. Optionally, the device 100 further includes a communication component 1003. The processor 1001, memory 1002, and communication component 1003 are connected via a bus 1004.
[0204] In a specific implementation, at least one processor 1001 executes computer execution instructions stored in memory 1002, causing at least one processor 1001 to perform the above-described method.
[0205] The specific implementation process of processor 1001 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.
[0206] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.
[0207] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.
[0208] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.
[0209] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.
[0210] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.
[0211] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.
[0212] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.
[0213] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.
[0214] 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.
[0215] 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.
[0216] 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.
[0217] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.
[0218] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.
Claims
1. A method for identifying latent faults during train commissioning, characterized in that, include: Acquire the basic dataset of debugging faults of the target train, the basic support data for the debugging process of the target train, and the real-time fault code data generated during the debugging process of the target train; Based on the aforementioned debugging fault dataset, a debugging license fault code library and a process step-fault code rule library are constructed respectively. Based on the aforementioned debugging foundation support data, the debugging license fault code library, and the process step-fault code rule library, the real-time fault code data is filtered to obtain the actual fault codes and hidden fault codes to be verified generated during the target debugging process. Based on the actual fault codes and the hidden fault codes to be verified, the hidden faults generated by the target train during the target commissioning process are identified.
2. The method according to claim 1, characterized in that, The debugging fault dataset contains multiple historical fault codes and their associated information; the associated information includes routine debugging files, daily operating conditions, special train operating conditions, and historical train faults; based on the debugging fault dataset, a debugging permission fault code library and a step-fault code rule library are constructed, including: Based on the historical fault codes and their associated information, the following are generated: the first historical fault code corresponding to each test chapter in the routine debugging file, the second historical fault code corresponding to the daily operating conditions, the third historical fault code corresponding to the special operating conditions of the train, and the fourth historical fault code corresponding to the actual historical fault of the train. Based on the aforementioned historical first fault code, a test chapter license fault code library is generated for each of the aforementioned test chapters; Based on the aforementioned historical second fault codes, a daily operation license fault code library is generated; Based on the aforementioned historical third fault codes, a special operating condition permission fault code library is generated; Based on the aforementioned historical fourth fault code, a real fault code library is generated; Based on the experimental chapter permission fault code library, the daily operation permission fault code library, the special working condition permission fault code library, and the real fault code library, the debugging permission fault code library is constructed. Based on the association between each fault code in the fault code library of the test chapter and each key step in the test chapter, the step-fault code rule library is generated.
3. The method according to claim 2, characterized in that, Before filtering the real-time fault code data based on the debugging foundation support data, the debugging license fault code library, and the process step-fault code rule library to obtain the actual fault codes and the hidden fault codes to be verified generated during the target debugging process, the method further includes: After the target train triggers a preset event, the test chapter's permission fault code library is verified and updated. After the debugging process document in the debugging basic support data is changed, the process step-fault code rule base is improved according to the changed debugging process document.
4. The method according to claim 3, characterized in that, The step of verifying and updating the test chapter's permitted fault code library after the target train triggers a preset event includes: Obtain historical fault data for the target train and other trains; the other trains are the same model and train software version as the target train listed. The historical fault data is compared with the test chapter license fault code library to obtain the verification result of the test chapter license fault code library; Receive the audit result for the verification result; Based on the audit results, update the license fault code library for the experimental section.
5. The method according to claim 2, characterized in that, The basic support data for debugging includes the debugging process documents corresponding to the target debugging process, real-time vehicle status data during the target debugging process, and real-time test progress. Based on the basic support data for debugging, the debugging permission fault code library, and the step-fault code rule library, the real-time fault code data is filtered to obtain the actual fault codes generated during the target debugging process and the hidden fault codes to be verified, including: A fault code criterion library is generated based on the debugging process document corresponding to the target debugging process and the step-fault code rule library. Based on the real-time test progress during the target debugging process, the fault code criterion library, and the process step-fault code rule library, the fault code data is filtered and eliminated to obtain the first candidate fault code set; Based on the real-time vehicle status data during the target debugging process, a second candidate fault code set is determined from the first candidate fault code set by matching the daily operation permission fault code library and the special working condition permission fault code library; The intersection of the real fault code library and the second candidate fault code set is determined as the real fault code; and the relative complement of the real fault code library in the second candidate fault code set is determined as the hidden fault code to be verified.
6. The method according to claim 1, characterized in that, The step of identifying the latent faults generated by the target train during the target commissioning process based on the actual fault codes and the latent fault codes to be verified includes: Receive the verification results of the hidden fault code to be verified; The hidden fault codes to be verified that have been verified are identified as verified hidden fault codes. Based on the actual fault codes and the verified latent fault codes, the latent faults generated by the target train during the target commissioning process are identified.
7. The method according to claim 1, characterized in that, The method further includes: Obtain historical fault analysis reports; Based on the aforementioned historical fault analysis reports, a fault analysis and processing library will be constructed. Accordingly, after identifying the latent faults generated by the target train during the target commissioning process based on the actual fault codes and the latent fault codes to be verified, the method further includes: Based on the fault analysis and processing library, a processing strategy corresponding to the latent fault is generated.
8. A device for identifying latent faults during train debugging, characterized in that, include: The acquisition module is used to acquire the basic dataset of debugging faults of the target train, the basic support data of debugging of the target debugging process, and the real-time fault code data generated during the debugging process of the target. The building module is used to build a debugging license fault code library and a process step-fault code rule library based on the aforementioned debugging fault base dataset. The filtering module is used to filter the real-time fault code data based on the debugging basic support data, the debugging license fault code library, and the process step-fault code rule library to obtain the real fault codes and hidden fault codes to be verified generated during the target debugging process. The identification module is used to identify the hidden faults generated by the target train during the target commissioning process based on the real fault codes and the hidden fault codes to be verified.
9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.