A parallel test method based on intelligent identification system for fault images of railway motor cars
By constructing a parallel testing method, the problem of low efficiency of manual operation in railway EMU fault detection was solved. It realizes automated and uniform distribution of testing tasks, improves detection efficiency and system reliability, and reduces testing errors.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HARBIN KEJIA GENERAL MECHANICAL & ELECTRICAL CO LTD
- Filing Date
- 2026-04-22
- Publication Date
- 2026-06-30
AI Technical Summary
Current fault detection for railway trains relies on manual operation, resulting in low detection efficiency and difficulty in guaranteeing quality, posing potential safety hazards to train operations. There is a lack of parallel testing methods.
Construct a benchmark test dataset, generate false negative and false positive test datasets, execute test tasks in parallel on multiple servers, automatically monitor key metrics such as CPU and memory, and achieve automated and even distribution of test tasks.
It improved testing efficiency, reduced human resources and time costs, reduced testing errors, improved hardware resource utilization and system reliability, and ensured testing quality.
Smart Images
Figure CN122309380A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of image testing for railway train fault images, and more specifically to a parallel testing method based on an intelligent recognition system for railway train fault images. Background Technology
[0002] Currently, fault detection on high-speed trains is carried out by inspectors within the depot. The detection methods still rely on visual inspection outdoors or manual image review indoors. This method is highly susceptible to factors such as the professional skills, sense of responsibility, and workload of the personnel, making it prone to false positives and false negatives. The quality of the work is difficult to guarantee, and any equipment malfunctions pose significant safety hazards. The company's image recognition project can monitor and alert to potential faults in moving freight trains, reducing the false negative rate and ensuring safe train operation.
[0003] To ensure product quality in image recognition projects, in addition to system testing, performance indicator testing is also required. However, traditional performance indicator testing is mostly based on manual operation, resulting in low automation. Currently, the railway industry lacks a parallel testing method for performance indicator testing based on intelligent image recognition systems for railway train malfunctions. To address this issue, this invention introduces a parallel testing method for intelligent image recognition systems for railway train malfunctions. Summary of the Invention
[0004] This invention aims to address the problem that most existing indicator tests are based on manual operation and have low testing efficiency, and proposes a parallel testing method based on a railway train fault image intelligent recognition system.
[0005] The specific process of a parallel testing method for a railway EMU fault image intelligent recognition system is as follows:
[0006] S1. Construct the indicator test dataset and store each original image in the indicator test dataset according to the rules;
[0007] S2. Construct a false negative test dataset and a false positive test dataset based on the indicator test dataset. The false negative test dataset and the false positive test dataset constitute the project test dataset.
[0008] S3. Execute the project test dataset to obtain the train car number, the start time of the train car inspection, the end time of the train car inspection, and the fault result. Store the train car number of the inspection, the start time of the train car inspection, the end time of the train car inspection, and the fault result in Log 1.
[0009] Execute the project test dataset to obtain the test server identification process status, test server CPU and memory results, and test server overall running status. Store the obtained test server identification process status, test server CPU and memory results, and test server overall running status in Log 2.
[0010] S4. Statistically analyze the false negative test results in Log 1 of S3;
[0011] S5. Statistically analyze the false alarm test results in Log 1 of S3.
[0012] Preferably, in step S1, an indicator test dataset is constructed, and each original image in the indicator test dataset is stored according to rules;
[0013] The specific process is as follows:
[0014] Four cameras are installed on the side of the track, and five cameras are installed at the bottom of the track.
[0015] The original images of the train passing by are captured by a camera, and an indicator test dataset is constructed based on the original images.
[0016] The original image is stored using the following filename format: vehicle_channel_image_number.jpg;
[0017] The car number indicates the number of the carriages in each train, excluding the locomotive at the front.
[0018] The standard for channel number is:
[0019] The image channel number of the L1 camera is 1; the image channel number of the L9 camera is 2.
[0020] The image channel number of an L2 camera is 3; the image channel number of an L8 camera is 4.
[0021] The image channel number captured by the L5 camera is 5;
[0022] The image channel number of the L4 camera is 6; the image channel number of the L6 camera is 7.
[0023] Images captured by the L3 camera have 8 channel numbers; images captured by the L7 camera have 9 channel numbers.
[0024] The image number indicates which image was captured by the camera corresponding to the aisle number of the carriage.
[0025] Preferably, the missed detection test dataset consists of folders at different manufacturer levels;
[0026] Each manufacturer-level folder consists of folders for different car models;
[0027] Each vehicle model folder consists of original images from different sites, vehicle configuration files from different sites, and test cases for different vehicle models;
[0028] Each site's image contains the image's baseline message.
[0029] Preferably, the false alarm test dataset consists of folders at different manufacturer levels;
[0030] Each manufacturer-level folder consists of folders for different car models;
[0031] Each vehicle model folder contains original images from different sites and vehicle profiles from different sites.
[0032] Preferably, the process of obtaining test cases for different vehicle models in the missed detection test dataset is as follows:
[0033] The test case consists of several items: fault name, fault code, vehicle model, station, vehicle passage time, image number, fault mode, image quality and weather factors, expected result, number of faults, person in charge, and fault examples.
[0034] Preferably, the process of obtaining the vehicle passage configuration file in the missed detection test dataset is as follows:
[0035] A database is built based on historical vehicle passage information; the vehicle passage information includes stations and passage times.
[0036] The script is built as follows:
[0037] The script reads the train passing information from the test cases, queries the database for the trains corresponding to the passing information, and stores the passing information and the corresponding trains in an empty data file, which is the passing configuration file.
[0038] Preferably, the process of obtaining the vehicle configuration file in the false alarm test dataset is as follows:
[0039] A database is built based on historical vehicle passage information; the vehicle passage information includes stations and passage times.
[0040] The script is built as follows:
[0041] The script reads the train passing information from the false alarm collection document, queries the database for the train passing information and the corresponding train, and stores the train passing information and the corresponding train in an empty data file. The data file is the train passing configuration file.
[0042] The false alarm collection document includes: vehicle type, station, and vehicle passage time.
[0043] Preferably, in S3, the project test dataset is executed to obtain the train car number, the start time of the train car inspection, the end time of the train car inspection, and the fault result, and the train car number of the inspection, the start time of the train car inspection, the end time of the train car inspection, and the fault result are stored in log 1.
[0044] Execute the project test dataset to obtain the test server identification process status, test server CPU and memory results, and test server overall running status. Store the obtained test server identification process status, test server CPU and memory results, and test server overall running status in Log 2.
[0045] The specific process is as follows:
[0046] S31. Read the vehicle pass configuration data files from all manufacturers and distribute the vehicle pass configuration data files to each test server. Each test server detects the vehicle pass image data and stores the vehicle car number to be inspected, the start time of the vehicle car inspection, the end time of the vehicle car inspection, and the fault result in Log 1.
[0047] S32. Periodically check the test server's identification process status; the process is as follows:
[0048] When the identification process of test server a ends, but the identification process of test server b does not end, the vehicle passing configuration that was not tested by the identification process of test server b is assigned to test server a, and test server a continues to perform the test.
[0049] S33. Simultaneously monitor the CPU and memory usage of the test server, and save the CPU and memory results of the test server to the monitoring log. The log records the current time, test server name, test server identification process status, and process details.
[0050] S34. Simultaneously monitor the overall operating status of the test server; the process is as follows:
[0051] The test server is configured with three statuses: healthy, warning, and dangerous.
[0052] For test server memory metrics, if the test server memory utilization rate is greater than 90%, it is defined as a dangerous state; if the memory utilization rate is greater than 80% and less than or equal to 90%, it is defined as a warning state; otherwise, it is a healthy state.
[0053] For test server disk metrics, if the disk utilization rate is greater than 95%, it is defined as a dangerous state; if the disk utilization rate is greater than 85% and less than or equal to 95%, it is defined as a warning state; otherwise, it is a healthy state.
[0054] For the CPU metrics of the test server, if the CPU utilization is greater than 90%, it is defined as a dangerous state; if the CPU utilization is greater than 80% and less than or equal to 90%, it is defined as a warning state; otherwise, it is a healthy state.
[0055] Determine the overall server status based on the test server's memory, disk, and CPU metrics:
[0056] If any of the test server's memory metrics, disk metrics, or CPU metrics are dangerous, then the test server is dangerous.
[0057] If any of the test server's memory metrics, test server's disk metrics, or test server's CPU metrics are warning, then the test server will issue a warning.
[0058] If all of the test server's memory metrics, disk metrics, or CPU metrics are in a healthy state, then the test server is in a healthy state.
[0059] Set the monitoring cycle interval for timed detection to 1000 seconds, and send a server health alarm when the server status is warning or danger;
[0060] S35. After the test is completed, the process status of the test server in S32, the CPU and memory results of the test server in S33, and the overall running status of the test server in S34 are saved in log 2.
[0061] Preferably, in step S4, the false negative test results in log 1 of S3 are statistically analyzed; the specific process is as follows:
[0062] S41: One test server corresponds to one S31 log file. All S31 log files corresponding to all test servers are integrated and stored in one log file.
[0063] The S31 log includes the train car number inspected, the start time of the inspection, the end time of the inspection, and the fault result.
[0064] S42. Set the name, manufacturer, and vehicle model of the test dataset to be analyzed for missed reports;
[0065] S43. In the log file integrated in S41, sort the fault results in chronological order.
[0066] Get the One fault result;
[0067] The fault results include the test dataset name, manufacturer, vehicle model, vehicle passage time, image number, fault code, fault coordinates, and camera number;
[0068] S44, Determine the first In each fault result, are the test dataset name, manufacturer, and vehicle model the same as the missed test dataset name, manufacturer, and vehicle model set by S42 to be counted?
[0069] If so, retrieve the first baseline message contained in the site image of the vehicle model in the manufacturer in the S42 missed test dataset name, and execute S45;
[0070] If not, Repeat S44 until all fault results integrated into one log file by S41 have been evaluated.
[0071] S45. Determine whether the vehicle passage time, image number, fault code, and camera number in the baseline message match the information provided. The vehicle passage time, image number, fault code, and camera number are consistent in the fault results;
[0072] If so, obtain the baseline message coordinates of S44 and the first... For each fault result, determine the fault coordinates and execute S46.
[0073] If not, retrieve the next baseline message from the site images of the vehicle models in the manufacturers listed in the S42 missed detection test dataset name, and execute S45; if all baseline messages in the site images of the vehicle models in the manufacturers listed in the S42 missed detection test dataset name match the first... The vehicle passage time, image number, fault code, and camera number in the fault results are inconsistent, making... Execute S44;
[0074] S46. Determine whether there is any intersection between the baseline message coordinates and the fault coordinates of the fault result in S45;
[0075] If so, the baseline message is marked as an identification message;
[0076] If not, retrieve the next baseline message contained in the site image of the vehicle model in the manufacturer in the S42 missed test dataset name, and execute S45;
[0077] S47. Extract vehicle passage time, image number, channel number, fault code, vehicle model, and location coordinates from messages marked as identification and those not marked as identification, and store them in the manufacturer's vehicle model statistics table.
[0078] Preferably, in step S5, the false alarm test results in log 1 of S3 are statistically analyzed; the specific process is as follows:
[0079] S51: One test server corresponds to one S31 log file. All S31 log files corresponding to all test servers are integrated and stored in one log file.
[0080] The S31 log includes the train car number inspected, the start time of the inspection, the end time of the inspection, and the fault result.
[0081] S52. Set the name, manufacturer, and vehicle model of the test dataset to be analyzed for missed reports;
[0082] S53. In the log file integrated by S51, sort the fault results in chronological order.
[0083] Get the One fault result;
[0084] The fault results include the test dataset name, manufacturer, vehicle model, vehicle passage time, image number, fault code, fault coordinates, and camera number;
[0085] S54, Determine the first In each fault result, are the test dataset name, manufacturer, and vehicle model the same as the missing test dataset name, manufacturer, and vehicle model set by S52 to be counted?
[0086] If so, from the first Extract the vehicle passage time, image number, channel number, fault code, vehicle model, and location coordinates from each fault result and store them in the manufacturer's vehicle model statistics table;
[0087] If not, Repeat step S54 until all fault results integrated into the log file from step S51 have been evaluated.
[0088] The beneficial effects of this invention are as follows:
[0089] (1) Reduce testing costs: By using parallel testing, test tasks can be automatically assigned to various servers, enabling multiple tasks to be processed simultaneously, thereby reducing human resources and time investment and improving testing efficiency.
[0090] (2) Improve resource utilization: By monitoring task progress and automatically switching test tasks, test tasks can be evenly distributed and hardware resource utilization can be optimized.
[0091] (3) Reduce test errors: By executing test tasks in parallel, the test process can be automated, which can reduce the deviation of test results caused by environmental fluctuations or human operation and ensure test quality.
[0092] (4) Improve system reliability: Real-time monitoring of key indicators such as CPU and memory to detect performance bottlenecks or potential faults in advance.
[0093] (5) Strong scalability and applicability: It can be applied to image recognition model testing for railway freight cars, high-speed trains, and subway rail transit. (See attached diagram for details.)
[0094] Figure 1 This is a flowchart of the present invention. Detailed Implementation
[0095] Specific Implementation Method 1: The specific process of this implementation method for a parallel testing method based on a railway EMU fault image intelligent recognition system is as follows:
[0096] S1. Construct the indicator test dataset and store each original image in the indicator test dataset according to the rules;
[0097] S2. Construct a false negative test dataset and a false positive test dataset based on the indicator test dataset. The false negative test dataset and the false positive test dataset constitute the project test dataset.
[0098] S3. Execute the project test dataset to obtain the train car number, the start time of the train car inspection, the end time of the train car inspection, and the fault result. Store the train car number of the inspection, the start time of the train car inspection, the end time of the train car inspection, and the fault result in Log 1.
[0099] Execute the project test dataset to obtain the test server identification process status, test server CPU and memory results, and test server overall running status. Store the obtained test server identification process status, test server CPU and memory results, and test server overall running status in Log 2.
[0100] S4. Statistically analyze the false negative test results in Log 1 of S3;
[0101] S5. Statistically analyze the false alarm test results in Log 1 of S3.
[0102] The intelligent recognition system based on railway train fault images is based on existing pre-trained recognition systems, such as deep learning models.
[0103] Specific Implementation Method Two: This implementation method differs from Specific Implementation Method One in that, in S1, an indicator test dataset is constructed, and each original image in the indicator test dataset is stored according to rules.
[0104] The specific process is as follows:
[0105] Four cameras are installed on the side of the track, and five cameras are installed at the bottom of the track.
[0106] The original images of the train passing at high speed are captured by a camera, and an indicator test dataset is constructed based on the original images.
[0107] The original image is stored using the following filename format: vehicle_channel_image_number.jpg;
[0108] The car number refers to the number of the carriages in each train excluding the locomotive (e.g., 10 means the 10th carriage counting from the carriages behind the locomotive).
[0109] The standard for channel number is:
[0110] The image channel number of the L1 camera is 1; the image channel number of the L9 camera is 2.
[0111] The image channel number of an L2 camera is 3; the image channel number of an L8 camera is 4.
[0112] The image channel number captured by the L5 camera is 5;
[0113] The image channel number of the L4 camera is 6; the image channel number of the L6 camera is 7.
[0114] Images captured by the L3 camera have 8 channel numbers; images captured by the L7 camera have 9 channel numbers.
[0115] The image number indicates which image was captured by the camera corresponding to the passage number of the carriage (e.g., which photo was taken by the 3rd camera L3 of the 10th carriage).
[0116] Because of the large number of test data images, the test data is stored on a high-speed NAS. During testing, abnormal test image data can be read by mounting the NAS.
[0117] The other steps and parameters are the same as in Specific Implementation Method 1.
[0118] Specific Implementation Method 3: This implementation method differs from Specific Implementation Method 1 or 2 in that the missed detection test dataset is composed of folders at different manufacturer levels;
[0119] Each manufacturer-level folder consists of folders for different car models;
[0120] Each vehicle model folder consists of original images from different sites, vehicle configuration files from different sites, and test cases for different vehicle models;
[0121] Each site's image contains the image's baseline message.
[0122] A baseline message is a bounding box drawn based on the location of the fault, used to identify where the fault is on the image.
[0123] Other steps and parameters are the same as in specific implementation method one or two.
[0124] Specific Implementation Method Four: This implementation method differs from Specific Implementation Methods One to Three in that the false alarm test dataset is composed of folders at different manufacturer levels;
[0125] Each manufacturer-level folder consists of folders for different car models;
[0126] Each vehicle model folder contains original images from different sites and vehicle profiles from different sites.
[0127] The other steps and parameters are the same as those in one of the specific implementation methods one to three.
[0128] Specific Implementation Method Five: This implementation method differs from Specific Implementation Methods One to Four in that the process of obtaining test cases for different vehicle models in the missed detection test dataset is as follows:
[0129] Test cases consist of the following items: fault name (e.g., a fault name corresponds to a broken component), fault code (one fault code corresponds to one fault, and an identification message containing fault code information will be output when a fault is detected), vehicle model, station, vehicle passage time, image number, fault form (the fault form is a fault form designed by the test engineer according to the module identification standard, for example, the identification standard for a broken component is a broken area greater than 200*200, and the fault form is designed to have a broken area equal to 210*210), image quality (image quality refers to the brightness, darkness, and normality of the vehicle passage image, which is judged manually) and weather factors (weather factors refer to the weather conditions under which the vehicle was photographed, such as rain or snow, which may affect fault detection), expected result (the expected result of the test case refers to whether the test case can be identified, usually identifiable), number of faults (the number of faults is how many faults are designed in a test case, usually one, but two or three are also possible), responsible person, and fault example (e.g., the broken form is a faulty image, which is Photoshopped based on the fault example and inserted into the test case).
[0130] When designing test cases, test engineers fill in the fault module name, fault code, and serial number in the test cases according to the requirements document; find the vehicle data images of the vehicle model according to the designed vehicle model, and fill in the vehicle model, station, vehicle passage time, and other information in the test cases; design the fault mode according to the requirements document, find the vehicle passage images involved in the fault mode, and fill in the image number in the test cases.
[0131] The images of passing vehicles were photoshopped to correspond to the fault patterns in the test cases, and these were used as the fault patterns in the test cases.
[0132] Test Case Review: After the test case design and fault image processing are completed, the test cases need to be reviewed. First, the test team conducts an internal review. After discussion among the test team members, if the fault mode of the test case does not match the requirements, it is modified. After modification, the project team organizes an external review. After discussion among the development personnel, if the fault mode of the test case does not match the requirements, it is modified. Finally, the test case version that fails to detect faults is determined.
[0133] The other steps and parameters are the same as those in one of the specific implementation methods one to four.
[0134] Specific Implementation Method Six: This implementation method differs from Specific Implementation Methods One through Five in that the process of obtaining the vehicle passage configuration file in the missed detection test dataset is as follows:
[0135] A database is built based on historical vehicle passage information; the vehicle passage information includes stations and passage times.
[0136] The script is built as follows:
[0137] Retrieve the required vehicle passage information from the database and export the retrieved vehicle passage information as a data file;
[0138] The script reads the train passing information from the test cases, queries the database for the trains corresponding to the passing information, and stores the passing information and the corresponding trains in an empty data file, which is the passing configuration file.
[0139] Once the test cases and datasets are ready, a script needs to be developed to generate vehicle configuration files.
[0140] The other steps and parameters are the same as those in one of the specific implementation methods one to five.
[0141] Specific Implementation Method Seven: This implementation method differs from Specific Implementation Methods One through Six in that the process of obtaining the vehicle passage configuration file in the false alarm test dataset is as follows:
[0142] A database is built based on historical vehicle passage information; the vehicle passage information includes stations and passage times.
[0143] The script is built as follows:
[0144] Retrieve the required vehicle passage information from the database and export the retrieved vehicle passage information as a data file;
[0145] The script reads the train passing information from the false alarm collection document, queries the database for the train passing information and the corresponding train, and stores the train passing information and the corresponding train in an empty data file. The data file is the train passing configuration file.
[0146] The false alarm collection document includes: vehicle type, station, and vehicle passage time.
[0147] The other steps and parameters are the same as those in one of the specific implementation methods one to six.
[0148] Specific Implementation Method Eight: This implementation method differs from Specific Implementation Methods One to Seven in that, in S3, the project test dataset is executed to obtain the train car number, the start time of the train car inspection, the end time of the train car inspection, and the fault result, and the train car number of the inspection, the start time of the train car inspection, the end time of the train car inspection, and the fault result are stored in Log 1.
[0149] Execute the project test dataset to obtain the test server identification process status, test server CPU and memory results, and test server overall running status. Store the obtained test server identification process status, test server CPU and memory results, and test server overall running status in Log 2.
[0150] The specific process is as follows:
[0151] S31. Read the vehicle pass configuration data files from all manufacturers and distribute the vehicle pass configuration data files to each test server. Each test server detects the vehicle pass image data and stores the vehicle car number to be inspected, the start time of the vehicle car inspection, the end time of the vehicle car inspection, and the fault result in Log 1.
[0152] S32. Periodically check the test server's identification process status; the process is as follows:
[0153] When the identification process of test server a ends, but the identification process of test server b does not end, the vehicle passing configuration that was not tested by the identification process of test server b is assigned to test server a, and test server a continues to perform the test.
[0154] S33. Simultaneously monitor the CPU and memory usage of the test server, and save the CPU and memory results of the test server to the monitoring log. The log records the current time, test server name, test server identification process status, and process details (user, process pid, CPU usage, memory usage).
[0155] S34. Simultaneously monitor the overall operating status of the test server; the process is as follows:
[0156] The test server is configured with three statuses: healthy, warning, and dangerous.
[0157] For test server memory metrics, if the test server memory utilization rate is greater than 90%, it is defined as a dangerous state; if the memory utilization rate is greater than 80% and less than or equal to 90%, it is defined as a warning state; otherwise, it is a healthy state.
[0158] For test server disk metrics, if the disk utilization rate is greater than 95%, it is defined as a dangerous state; if the disk utilization rate is greater than 85% and less than or equal to 95%, it is defined as a warning state; otherwise, it is a healthy state.
[0159] For the CPU metrics of the test server, if the CPU utilization is greater than 90%, it is defined as a dangerous state; if the CPU utilization is greater than 80% and less than or equal to 90%, it is defined as a warning state; otherwise, it is a healthy state.
[0160] Determine the overall server status based on the test server's memory, disk, and CPU metrics:
[0161] If any of the test server's memory metrics, disk metrics, or CPU metrics are dangerous, then the test server is dangerous.
[0162] If any of the test server's memory metrics, test server's disk metrics, or test server's CPU metrics are warning, then the test server will issue a warning.
[0163] If all of the test server's memory metrics, disk metrics, or CPU metrics are in a healthy state, then the test server is in a healthy state.
[0164] Set the monitoring cycle interval for timed detection to 1000 seconds, and send a server health alarm when the server status is warning or danger;
[0165] S32, S33, and S34 are performed simultaneously;
[0166] S35. After the test is completed, the process status of the test server in S32, the CPU and memory results of the test server in S33, and the overall running status of the test server in S34 are saved in log 2.
[0167] The other steps and parameters are the same as those in any of the specific implementation methods one to seven.
[0168] Specific Implementation Method Nine: This implementation method differs from Specific Implementation Methods One to Eight in that, in S4, the missed detection test results in Log 1 of S3 are statistically analyzed; the specific process is as follows:
[0169] S41: One test server corresponds to one S31 log file. All S31 log files corresponding to all test servers are integrated and stored in one log file.
[0170] The S31 log includes the train car number inspected, the start time of the inspection, the end time of the inspection, and the fault result.
[0171] S42. Set the name, manufacturer, and vehicle model of the test dataset to be analyzed for missed reports;
[0172] S43. In the log file integrated in S41, sort the fault results in chronological order.
[0173] Get the One fault result;
[0174] The fault results include the test dataset name, manufacturer, vehicle model, vehicle passage time, image number, fault code, fault coordinates, and camera number;
[0175] S44, Determine the first In each fault result, are the test dataset name, manufacturer, and vehicle model the same as the missed test dataset name, manufacturer, and vehicle model set by S42 to be counted?
[0176] If so, retrieve the first baseline message contained in the site image of the vehicle model in the manufacturer in the S42 missed test dataset name, and execute S45;
[0177] If not, Repeat S44 until all fault results integrated into one log file by S41 have been evaluated.
[0178] S45. Determine whether the vehicle passage time, image number, fault code, and camera number in the baseline message match the information provided. The vehicle passage time, image number, fault code, and camera number are consistent in the fault results;
[0179] If so, obtain the baseline message coordinates of S44 and the first... For each fault result, determine the fault coordinates and execute S46.
[0180] If not, retrieve the next (second) baseline message from the site images of the vehicle models in the manufacturers listed in the S42 missed detection test dataset name, and execute S45; if all baseline messages in the site images of the vehicle models in the manufacturers listed in the S42 missed detection test dataset name match the first... The vehicle passage time, image number, fault code, and camera number in the fault results are inconsistent, making... Execute S44;
[0181] S46. Determine whether there is any intersection between the baseline message coordinates and the fault coordinates of the fault result in S45;
[0182] If so, the baseline message is marked as an identification message;
[0183] If not, retrieve the next (third) message in the baseline message contained in the site image of the vehicle model in the manufacturer in the S42 missed test dataset name, and execute S45;
[0184] S47. Extract vehicle passage time, image number, channel number, fault code, vehicle model and location coordinates from messages marked as identification and messages not marked as identification, and store them in the manufacturer's vehicle model statistics table (initially an empty table);
[0185] Baseline messages not marked as identified are all missed reports;
[0186] Confirmation and summary: Communicate and confirm the missing information in the forms with the R&D personnel, record the problems and correct them, and output a test summary.
[0187] The other steps and parameters are the same as those in one of the specific implementation methods one to eight.
[0188] Specific Implementation Method Ten: This implementation method differs from Specific Implementation Methods One to Nine in that, in S5, the false alarm test results in Log 1 of S3 are statistically analyzed; the specific process is as follows:
[0189] S51: One test server corresponds to one S31 log file. All S31 log files corresponding to all test servers are integrated and stored in one log file.
[0190] The S31 log includes the train car number inspected, the start time of the inspection, the end time of the inspection, and the fault result.
[0191] S52. Set the name, manufacturer, and vehicle model of the test dataset to be analyzed for missed reports;
[0192] S53. In the log file integrated by S51, sort the fault results in chronological order.
[0193] Get the One fault result;
[0194] The fault results include the test dataset name, manufacturer, vehicle model, vehicle passage time, image number, fault code, fault coordinates, and camera number;
[0195] S54, Determine the first In each fault result, are the test dataset name, manufacturer, and vehicle model the same as the missing test dataset name, manufacturer, and vehicle model set by S52 to be counted?
[0196] If so, from the first Extract the vehicle passage time, image number, channel number, fault code, vehicle model, and location coordinates from each fault result and store them in the manufacturer's vehicle model statistics table (initially an empty table);
[0197] If not, Repeat step S54 until all fault results integrated into the log file from step S51 have been evaluated.
[0198] The other steps and parameters are the same as those in any of the specific implementation methods one to nine.
[0199] The TEDS intelligent fault identification system for high-speed trains uses deep learning to generate a detection model from images of visible parts of the train body, such as the underside, side skirts, connecting devices, and bogies, collected by trackside equipment. The system then outputs the fault location and issues an alarm. This invention introduces a parallel testing method for this image-based intelligent identification system, improving testing efficiency and ensuring product quality.
[0200] This invention may have other embodiments. Without departing from the spirit and essence of this invention, those skilled in the art can make various corresponding changes and modifications according to this invention, but these corresponding changes and modifications should all fall within the protection scope of the appended claims.
Claims
1. A parallel testing method for a railway EMU fault image intelligent recognition system, characterized in that: The specific process of the method is as follows: S1. Construct the indicator test dataset and store each original image in the indicator test dataset according to the rules; S2. Construct a false negative test dataset and a false positive test dataset based on the indicator test dataset. The false negative test dataset and the false positive test dataset constitute the project test dataset. S3. Execute the project test dataset to obtain the train car number, the start time of the train car inspection, the end time of the train car inspection, and the fault result. Store the train car number of the inspection, the start time of the train car inspection, the end time of the train car inspection, and the fault result in Log 1. Execute the project test dataset to obtain the test server identification process status, test server CPU and memory results, and test server overall running status. Store the obtained test server identification process status, test server CPU and memory results, and test server overall running status in Log 2. S4. Statistically analyze the false negative test results in Log 1 of S3; S5. Statistically analyze the false alarm test results in Log 1 of S3.
2. The parallel testing method for a railway EMU fault image intelligent recognition system according to claim 1, characterized in that: In S1, an indicator test dataset is constructed, and each original image in the indicator test dataset is stored according to rules. The specific process is as follows: Four cameras are installed on the side of the track, and five cameras are installed at the bottom of the track. The original images of the train passing by are captured by a camera, and an indicator test dataset is constructed based on the original images. The original image is stored using the following filename format: vehicle_channel_image_number.jpg; The car number indicates the number of the carriages in each train, excluding the locomotive at the front. The standard for channel number is: The image channel number of the L1 camera is 1; the image channel number of the L9 camera is 2. The image channel number of an L2 camera is 3; the image channel number of an L8 camera is 4. The image channel number captured by the L5 camera is 5; The image channel number of the L4 camera is 6; the image channel number of the L6 camera is 7. Images captured by the L3 camera have 8 channel numbers; images captured by the L7 camera have 9 channel numbers. The image number indicates which image was captured by the camera corresponding to the aisle number of the carriage.
3. The parallel testing method for a railway EMU fault image intelligent recognition system according to claim 2, characterized in that: The missed detection test dataset consists of folders at different manufacturer levels; Each manufacturer-level folder consists of folders for different car models; Each vehicle model folder consists of original images from different sites, vehicle configuration files from different sites, and test cases for different vehicle models; Each site's image contains the image's baseline message.
4. The parallel testing method for a railway EMU fault image intelligent recognition system according to claim 3, characterized in that: The false alarm test dataset consists of folders at different manufacturer levels; Each manufacturer-level folder consists of folders for different car models; Each vehicle model folder contains original images from different sites and vehicle profiles from different sites.
5. The parallel testing method for a railway EMU fault image intelligent recognition system according to claim 4, characterized in that: The process of obtaining test cases for different vehicle models in the missed detection test dataset is as follows: The test case consists of several items: fault name, fault code, vehicle model, station, vehicle passage time, image number, fault mode, image quality and weather factors, expected result, number of faults, person in charge, and fault examples.
6. The parallel testing method for a railway EMU fault image intelligent recognition system according to claim 5, characterized in that: The process of obtaining the vehicle configuration file in the missed detection test dataset is as follows: A database is built based on historical vehicle passage information; the vehicle passage information includes stations and passage times. The script is built as follows: The script reads the train passing information from the test cases, queries the database for the trains corresponding to the passing information, and stores the passing information and the corresponding trains in an empty data file, which is the passing configuration file.
7. The parallel testing method for a railway EMU fault image intelligent recognition system according to claim 6, characterized in that: The process of obtaining the vehicle configuration file in the false alarm test dataset is as follows: A database is built based on historical vehicle passage information; the vehicle passage information includes stations and passage times. The script is built as follows: The script reads the train passing information from the false alarm collection document, queries the database for the train passing information and the corresponding train, and stores the train passing information and the corresponding train in an empty data file. The data file is the train passing configuration file. The false alarm collection document includes: vehicle type, station, and vehicle passage time.
8. The parallel testing method for a railway EMU fault image intelligent recognition system according to claim 7, characterized in that: The test dataset of the project is executed in S3 to obtain the train car number, the start time of the train car inspection, the end time of the train car inspection, and the fault result. The train car number of the inspection, the start time of the train car inspection, the end time of the train car inspection, and the fault result are stored in Log 1. Execute the project test dataset to obtain the test server identification process status, test server CPU and memory results, and test server overall running status. Store the obtained test server identification process status, test server CPU and memory results, and test server overall running status in Log 2. The specific process is as follows: S31. Read the vehicle pass configuration data files from all manufacturers and distribute the vehicle pass configuration data files to each test server. Each test server detects the vehicle pass image data and stores the vehicle car number to be inspected, the start time of the vehicle car inspection, the end time of the vehicle car inspection, and the fault result in Log 1. S32. Periodically check the test server's identification process status; the process is as follows: When the identification process of test server a ends, but the identification process of test server b does not end, the vehicle passing configuration that was not tested by the identification process of test server b is assigned to test server a, and test server a continues to perform the test. S33. Simultaneously monitor the CPU and memory usage of the test server, and save the CPU and memory results of the test server to the monitoring log. The log records the current time, test server name, test server identification process status, and process details. S34. Simultaneously monitor the overall operating status of the test server; the process is as follows: The test server is configured with three statuses: healthy, warning, and dangerous. For test server memory metrics, if the test server memory utilization rate is greater than 90%, it is defined as a dangerous state; if the memory utilization rate is greater than 80% and less than or equal to 90%, it is defined as a warning state; otherwise, it is a healthy state. For test server disk metrics, if the disk utilization rate is greater than 95%, it is defined as a dangerous state; if the disk utilization rate is greater than 85% and less than or equal to 95%, it is defined as a warning state; otherwise, it is a healthy state. For the CPU metrics of the test server, if the CPU utilization is greater than 90%, it is defined as a dangerous state; if the CPU utilization is greater than 80% and less than or equal to 90%, it is defined as a warning state; otherwise, it is a healthy state. Determine the overall server status based on the test server's memory, disk, and CPU metrics: If any of the test server's memory metrics, disk metrics, or CPU metrics are dangerous, then the test server is dangerous. If any of the test server's memory metrics, test server's disk metrics, or test server's CPU metrics are warning, then the test server will issue a warning. If all of the test server's memory metrics, disk metrics, or CPU metrics are in a healthy state, then the test server is in a healthy state. Set the monitoring cycle interval for timed detection to 1000 seconds, and send a server health alarm when the server status is warning or danger; S35. After the test is completed, the process status of the test server in S32, the CPU and memory results of the test server in S33, and the overall running status of the test server in S34 are saved in log 2.
9. The parallel testing method for a railway EMU fault image intelligent recognition system according to claim 8, characterized in that: In step S4, the false negative test results in log 1 of S3 are statistically analyzed; the specific process is as follows: S41: One test server corresponds to one S31 log file. All S31 log files corresponding to all test servers are integrated and stored in one log file. The S31 log includes the train car number inspected, the start time of the inspection, the end time of the inspection, and the fault result. S42. Set the name, manufacturer, and vehicle model of the test dataset to be analyzed for missed reports; S43. In the log file integrated in S41, sort the fault results in chronological order. Get the One fault result; The fault results include the test dataset name, manufacturer, vehicle model, vehicle passage time, image number, fault code, fault coordinates, and camera number; S44, Determine the first In each fault result, are the test dataset name, manufacturer, and vehicle model the same as the missed test dataset name, manufacturer, and vehicle model set by S42 to be counted? If so, retrieve the first baseline message contained in the site image of the vehicle model in the manufacturer in the S42 missed test dataset name, and execute S45; If not, Repeat S44 until all fault results integrated into one log file by S41 have been evaluated. S45. Determine whether the vehicle passage time, image number, fault code, and camera number in the baseline message match the information provided. The vehicle passage time, image number, fault code, and camera number are consistent in the fault results; If so, obtain the baseline message coordinates of S44 and the first... For each fault result, determine the fault coordinates and execute S46. If not, retrieve the next baseline message from the site images of the vehicle models in the manufacturers listed in the S42 missed detection test dataset name, and execute S45; if all baseline messages in the site images of the vehicle models in the manufacturers listed in the S42 missed detection test dataset name match the first... The vehicle passage time, image number, fault code, and camera number in the fault results are inconsistent, making... Execute S44; S46. Determine whether there is any intersection between the baseline message coordinates and the fault coordinates of the fault result in S45; If so, the baseline message is marked as an identification message; If not, retrieve the next baseline message contained in the site image of the vehicle model in the manufacturer in the S42 missed test dataset name, and execute S45; S47. Extract vehicle passage time, image number, channel number, fault code, vehicle model, and location coordinates from messages marked as identification and those not marked as identification, and store them in the manufacturer's vehicle model statistics table.
10. The parallel testing method for a railway EMU fault image intelligent recognition system according to claim 9, characterized in that: In S5, the false alarm test results in Log 1 of S3 are statistically analyzed; the specific process is as follows: S51: One test server corresponds to one S31 log file. All S31 log files corresponding to all test servers are integrated and stored in one log file. The S31 log includes the train car number inspected, the start time of the inspection, the end time of the inspection, and the fault result. S52. Set the name, manufacturer, and vehicle model of the test dataset to be analyzed for missed reports; S53. In the log file integrated by S51, sort the fault results in chronological order. Get the One fault result; The fault results include the test dataset name, manufacturer, vehicle model, vehicle passage time, image number, fault code, fault coordinates, and camera number; S54, Determine the first In each fault result, are the test dataset name, manufacturer, and vehicle model the same as the missing test dataset name, manufacturer, and vehicle model set by S52 to be counted? If so, from the first Extract the vehicle passage time, image number, channel number, fault code, vehicle model, and location coordinates from each fault result and store them in the manufacturer's vehicle model statistics table; If not, Repeat step S54 until all fault results integrated into the log file from step S51 have been evaluated.