Method and device for processing and testing parking position information packet

Abstract

The invention discloses a processing test method and device for a parking position information packet, relates to the technical field of train control system testing, and mainly aims to comprehensively and efficiently verify whether a function of deleting the information packet by vehicle-mounted equipment in a corresponding scene is correct or not. According to the main technical scheme, the method comprises the steps that the test requirement of a train for a parking position information packet is acquired; a corresponding target test scene is matched in a preset test scene matrix based on the test requirement, the test scene matrix is a test scene set constructed according to test point combination corresponding to the parking position information packet, and test points comprise train self-state test points and external input state test points; each test scene corresponds to one expected processing result; for the target test scene, executing corresponding processing operation on the parking position information packet to obtain a test processing result; and comparing the test processing result with an expected processing result to verify whether the processing operation on the parking position information packet in the target test scene is correct or not.

Description

Technical Field

[0001] This application relates to the field of train control system testing technology, and in particular to a method and apparatus for processing and testing parking location information packets. Background Technology

[0002] In the rail transit sector, CTCS (China Train Control System) is a critical system for ensuring safe train operation. The CTCS Level 2 train control system transmits train operation permission information based on track circuits and transponders, employing a target distance continuous speed control mode to monitor train operation. The parking position information packet (CTCS-13 packet), as an important component of this system, provides precise parking position intervals and platform-side information, assisting in accurate train stopping and door opening / closing operations, directly impacting operational safety and efficiency.

[0003] Currently, the onboard equipment of the existing CTCS2 level train control system has basic CTCS-13 information packet deletion logic. That is, when a transponder group with a known direction is received and there is no valid CTCS-13 information packet in the group, all stored CTCS-13 information packets will be cleared. At the same time, the industry has reached a basic consensus on the judgment of "transponder group with a known direction" (such as multiple transponder groups are judged by the order of reception, and single transponder groups are judged by the link information) and "valid CTCS-13 information packet" (such as a valid CTCS-13 information packet containing information packets and no message errors).

[0004] However, although the onboard equipment has the logic to delete the CTCS-13 information packet, the existing technology lacks standardized testing for the function of deleting the CTCS-13 information packet by the onboard equipment, which cannot fully verify the safety and reliability of the deletion function and poses a potential risk to train operation. Summary of the Invention

[0005] In view of the above problems, this application provides a method and apparatus for processing and testing parking location information packets. The main purpose is to comprehensively and efficiently verify whether the function of deleting the information packet by the on-board equipment is correct in the corresponding scenario, thereby ensuring the security and reliability of the deletion function.

[0006] Comprehensive and efficient verification of the vehicle-mounted equipment's ability to delete the information packet correctly in the corresponding scenario ensures the security and reliability of the deletion function. To solve the above-mentioned technical problems, this application proposes the following solution: Firstly, this application provides a method for processing and testing parking location information packets, the method comprising: Test requirements for obtaining train parking location information packets; Based on the test requirements, the corresponding target test scenario is matched in the preset test scenario matrix. The test scenario matrix is ​​a set of test scenarios constructed by combining test points corresponding to the parking position information package. The test points include test points of the train's own state and test points of external input state. Each test scenario corresponds to an expected processing result. For the target test scenario, perform corresponding processing operations on the parking location information packet to obtain the test processing results; The test processing results are compared with the expected processing results to verify whether the processing operation of the parking location information packet is correct under the target test scenario.

[0007] Secondly, this application provides a testing apparatus for processing parking location information packets, the apparatus comprising: The acquisition unit is used to acquire the test requirements of the train's parking position information packet; The matching unit is used to match the corresponding target test scenario in the preset test scenario matrix based on the test requirements obtained by the acquisition unit. The test scenario matrix is ​​a set of test scenarios constructed according to the test points corresponding to the parking location information package. The test points include the train's own state test points and external input state test points. Each test scenario corresponds to an expected processing result. The testing unit is used to perform corresponding processing operations on the parking location information packet for the target test scenario obtained by the matching unit, and obtain the test processing result; The verification unit is used to compare the test processing result obtained by the test unit with the expected processing result obtained by the matching unit to verify whether the processing operation of the parking location information packet is correct in the target test scenario.

[0008] To achieve the above objectives, according to a third aspect of this application, a storage medium is provided, the storage medium including a stored program, wherein, when the program is executed, the device where the storage medium is located is controlled to perform the processing and testing method for the parking location information packet of the first aspect described above.

[0009] To achieve the above objectives, according to a fourth aspect of this application, a processor is provided, the processor being configured to run a program, wherein the program, when running, executes the processing test method for the parking location information packet of the first aspect described above.

[0010] Using the above technical solution, this application provides a method and apparatus for processing and testing parking location information packets. When testing the deletion of parking location information packets by onboard equipment, the method first obtains the train's testing requirements for the parking location information packets. Then, based on the testing requirements, it matches the corresponding target test scenario in a preset test scenario matrix. The test scenario matrix is ​​a set of test scenarios constructed from test points corresponding to the parking location information packets. The test points include test points for the train's own state and test points for external input states. Each test scenario corresponds to an expected processing result. Next, for the target test scenario, the method performs corresponding processing operations on the parking location information packets to obtain the test processing result. Finally, the test processing result is compared with the expected processing result to verify whether the processing operation on the parking location information packets under the target test scenario is correct. The technical solution provided in this application fills the gap in the existing technology regarding the lack of standardized testing methods for the function of deleting parking location information packets by onboard equipment. It provides a clear and systematic operational framework for testing this function. Furthermore, the test scenario matrix constructed based on the combination of test points of the train's own state and external input state can comprehensively cover the key dimensions affecting the function of deleting parking location information packets, avoiding the loopholes caused by the lack of clear dimensions in existing tests. At the same time, each test scenario in the matrix corresponds to a unique expected processing result, making the matching of target test scenarios more accurate and effectively reducing the situation of repeated testing or missed testing. Through the closed-loop process of executing processing operations and comparative verification, the correctness of the onboard equipment's processing operations of parking location information packets in different scenarios can be verified efficiently and in a standardized manner, fully ensuring the safety and reliability of the deletion function, thereby reducing the operational hazards caused by the residual information packets.

[0011] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0012] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart of a testing method for processing parking location information packets provided in an embodiment of this application is shown; Figure 2 A flowchart of another testing method for processing parking location information packets provided in an embodiment of this application is shown; Figure 3This diagram shows a block diagram of a testing apparatus for processing parking location information packets according to an embodiment of this application. Figure 4 A block diagram of a testing apparatus for processing parking location information packets, as provided in an embodiment of this application, is shown. Detailed Implementation

[0013] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0014] Currently, the onboard equipment of existing CTCS2-level train control systems already possesses basic CTCS-13 packet deletion logic. Specifically, when a transponder group with a known direction is received and that group contains no valid CTCS-13 packets, all stored CTCS-13 packets are cleared. Furthermore, there is a basic consensus within the industry regarding the determination of "transponder groups with known directions" (e.g., multiple transponder groups are determined by reception order, single transponder groups by link information) and "valid CTCS-13 packets" (e.g., packets containing information without message errors are considered valid). However, despite the onboard equipment's CTCS-13 packet deletion logic, the existing technology lacks standardized testing methods for this function, making it impossible to fully verify the safety and reliability of the deletion function, thus posing potential risks to train operation.

[0015] Research into this technical problem revealed that a test scenario matrix covering key scenarios can be constructed by combining the processing logic of the parking location information package under different train self-states (such as onboard operation mode and storage state) and external input states (such as consistency of running direction and transponder group state). By matching target test scenarios based on test requirements, executing corresponding processing operations, and comparing test results with expected results, a standardized test method can be formed to fully verify the safety and reliability of the deletion function and eliminate potential train operation hazards.

[0016] Based on the above considerations, this application provides a method for processing and testing parking location information packets. This method can comprehensively and efficiently verify whether the function of deleting the information packet by the in-vehicle device is correct in the corresponding scenario, thereby ensuring the security and reliability of the deletion function. The execution subject of this embodiment is the in-vehicle device, and its specific execution steps are as follows: Figure 1 As shown, it includes: 101. Test requirements for obtaining train parking location information packets.

[0017] In this embodiment, the parking position information packet (CTCS-13 packet) refers to the message packet in the China Train Control System used to provide precise parking position intervals and platform information, and is the core basis for precise train parking and door opening / closing operations. It not only contains precise parking position information, but also covers platform location and platform door information. The driver can perform manual door opening / closing operations based on its content, or the onboard system can automatically complete the door opening / closing actions.

[0018] It should be noted that the onboard equipment's deletion logic for CTCS-13 packets is as follows: when the onboard equipment receives a transponder group with a known direction but no valid CTCS-13 packet, all stored parking position information packets will be cleared. Here, "known direction" means the receiving order of the transponder group clearly indicates the direction of travel (e.g., for multiple transponder groups, the direction is determined by the receiving order; for a single transponder group, the direction is determined by the link information). A valid CTCS-13 packet means that the transponder group contains a CTCS-13 packet without message errors (if a message error occurs, it is considered invalid).

[0019] In this step, the test requirement specifically refers to the verification requirement for the onboard equipment's function of deleting CTCS-13 information packets. This includes, but is not limited to, the test scope, test objectives, and test priorities. The test scope specifies the boundaries of the specific scenarios to be verified, such as specific operational phases like "after the train leaves the station," "while the train is stopped at the platform," or "when the train enters sleep mode." The test objective refers to the specific functional logic to be verified, such as "confirming whether the onboard equipment can correctly delete the stored parking location information packet when it receives a transponder group with a known direction that does not contain a CTCS-13 information packet." The test priority indicates the urgency of the test, such as "prioritizing the verification of the deletion function in sleep mode" (because the onboard equipment does not process link information in sleep mode, which can easily lead to misoperation). This test requirement can be set up with a front-end interface, which can contain all test points corresponding to the parking location information packet. The test requirement can be obtained through user selection or input, or the test points can be further combined according to certain key scenarios. The test requirement can be obtained by selecting a scenario; this embodiment does not limit this.

[0020] 102. Match the corresponding target test scenario in the preset test scenario matrix based on the test requirements.

[0021] The test scenario matrix is ​​a set of test scenarios constructed based on the test points corresponding to the parking location information package. The test points include test points of the train's own status and test points of external input status. Each test scenario corresponds to an expected processing result.

[0022] In this step, the train's own status test points include the onboard operating mode and the status of the onboard stored parking position information packets. The external input status test points include the consistency between the onboard running direction and the parking position information direction, and the status of the transponder group received by the train. In the train's own status test points, the onboard operating mode includes: hibernation mode (no link information processing), fully monitored mode (manual door opening and closing), and AM mode (automatic operation, ATO automatic door opening and closing); the status of the onboard stored parking position information packets includes: "Valid CTCS-13 information packet stored," "Never received," and "Received but deleted." In the external input status test points, the consistency between the onboard running direction and the parking position information direction includes: "Direction unknown," "Direction known and consistent," and "Direction known but inconsistent"; the status of the transponder group received by the train includes: "No CTCS-13 information packet and no message error," "CTCS-13 information packet present and no error," "Non-CTCS-13 information packet message error," and "CTCS-13 information packet message error." These test points are combined to form different row and column dimensions, and the test scenario matrix can be obtained by cross-referencing them. The expected processing result specifically refers to whether a deletion operation was performed on the parking location information packet under the corresponding test scenario.

[0023] Once the test requirements are obtained, corresponding test points can be extracted. These extracted test points are used as a matching benchmark to find the matching test scenario in the test scenario matrix; this is the target test scenario. For example, if the test requirement is "verify the deletion function in sleep mode," then the target test scenario is the intersection of the "sleep mode" column and the "same direction + no CTCS-13 information packet" row in the matrix. 103. For the target test scenario, perform the corresponding processing operations on the parking location information packet to obtain the test processing results.

[0024] In this step, since the target test scenario that meets the test requirements has been determined, the corresponding processing operation can be performed on the parking location information package under the target test scenario. That is, the test operation is performed under simulated actual operating conditions. Specifically, the test operation refers to whether the parking location information package triggers its deletion logic under the target test scenario, that is, whether the deletion operation is performed.

[0025] For example, in the scenario of "sleep mode + stored parking position information packet + consistent direction + no parking position information packet": The train is simulated to enter sleep mode (disabling the onboard equipment's link processing function); a valid CTCS-13 information packet is manually stored in the onboard equipment; the train is simulated to receive a transponder group with a known direction when leaving the station (e.g., the receiving order of multiple transponder groups is "first 1 then 2"), and this group does not contain a CTCS-13 information packet. The processing operations include: simulating the onboard equipment receiving the transponder group information; triggering the deletion logic (according to the CTCS-2 level train control system specification, when "direction is known + no valid CTCS-13 information packet", the stored CTCS-13 information packet should be deleted); and recording the actual processing operation performed by the onboard equipment (e.g., "delete information packet" or "retain information packet").

[0026] 104. Compare the test results with the expected results to verify whether the processing of the parking location information packet is correct in the target test scenario.

[0027] In this step, the test results from step 103 are compared with the expected test results corresponding to the target test scenario. If they match, it indicates that the processing operation of the parking location information packet in the target test scenario is correct, i.e., the verification passes. If they do not match, it indicates that the processing operation of the parking location information packet in the target test scenario is incorrect, i.e., the verification fails. At this point, a test report can be generated and the fault point can be located. For example, if the test finds that "the CTCS-13 information packet was not deleted in sleep mode," it is fed back to the vehicle equipment development team to correct the deletion logic. If all scenarios pass the verification, it is confirmed that the vehicle equipment deletion function meets the safety requirements.

[0028] Based on the above Figure 1 As can be seen from the implementation method, the parking location information packet processing test method provided in this application fills the gap in the existing technology for the lack of a standardized test method for the function of deleting parking location information packets (CTCS-13 information packets) by onboard equipment. It provides a clear and systematic operation framework for testing this function. Moreover, the test scenario matrix constructed based on the combination of test points of the train's own state and external input state can comprehensively cover the key dimensions affecting the parking location information packet deletion function, avoiding the loopholes caused by the lack of clear dimensions in existing tests. At the same time, each test scenario in the matrix corresponds to a unique expected processing result, making the matching of target test scenarios more accurate and effectively reducing the situation of repeated testing or missed testing. Through the closed-loop process of executing processing operations and comparative verification, the correctness of the onboard equipment's processing operations of parking location information packets in different scenarios can be verified efficiently and in a standardized manner, fully ensuring the safety and reliability of the deletion function, thereby reducing the operational hazards caused by the residual information packets.

[0029] Furthermore, the preferred embodiments of this application are based on the above... Figure 1 Based on this, a detailed explanation of the processing and testing process for parking location information packets is provided, with the specific steps as follows: Figure 2 As shown, it includes: 201. Determine the test point corresponding to the parking location information package.

[0030] The test points include the train's own status test points and external input status test points. The train's own status test points include the onboard operating mode and the status of the onboard stored parking position information packet. The external input status test points include the consistency between the onboard running direction and the parking position information direction and the status of the transponder group received onboard.

[0031] In this step, test points are determined by analyzing the system elements affecting packet deletion logic extracted from the CTCS-2 level train control system specifications. For example, the specifications explicitly state key logic points such as: "Onboard equipment does not process transponder link information in sleep mode," and "Stored packets should be deleted when the direction is known and there are no valid CTCS-13 packets." Based on the system specifications, test points are divided into two main categories: Train self-state test points: variables reflecting the internal state of onboard equipment; Onboard operating modes: including sleep mode (equipment does not process link information), fully monitored mode (doors can be manually opened and closed), AM mode (automatic operation, ATO automatic door opening and closing); Status of onboard stored parking position packets: including "Valid CTCS-13 packets stored" (packets are complete and error-free), "Never received" (equipment has not stored any packets), and "Received but deleted" (stored but cleared). External input state test points: variables reflecting the train operating environment. Consistency between the vehicle's running direction and the parking position information direction: including "Unknown direction" (the receiving order of the transponder group cannot be determined), "Known and consistent direction" (the receiving direction matches the direction of the stored information packet), and "Known but inconsistent direction" (the receiving direction conflicts with the direction of the stored information packet). The status of the transponder group received by the vehicle: including "No CTCS-13 information packet and no message error", "CTCS-13 information packet present and no error", "Non-CTCS-13 information packet message error", and "CTCS-13 information packet message error".

[0032] Instantiate the above test points. For example, for the "vehicle operation mode" test point, it is specified as three verifiable state values: sleep mode, full monitoring mode, and AM mode. For the "direction known and consistent" test point, it is specified as: when the receiving order of multiple transponder groups clearly indicates the operating direction (such as "1 then 2") and is consistent with the direction of the stored information packet. For the "transponder group status" test point, it is specified as: the transponder group contains CTCS-13 information packets and the message verification passes.

[0033] 202. Construct a test scenario matrix based on the cross-combination of test points, and set the corresponding expected processing results for each test scenario in the test scenario matrix.

[0034] In this step, after determining the test points, a test scenario matrix can be constructed based on the cross-combination of the test points. The specific execution process is as follows: the combination of the vehicle operation mode and the status of the parking location information packet saved by the vehicle is used as the column dimension, and the combination of the consistency between the vehicle operation direction and the parking location information direction and the status of the transponder group received by the vehicle is used as the row dimension; the test scenario matrix is ​​constructed based on the row dimension and column dimension.

[0035] In this step, an initial test scenario matrix (3×3×3×4=108 scenarios) is generated using Cartesian product, with "Vehicle Operation Mode" (3 states) and "Information Packet State" (3 states) as column dimensions, and "Directional Consistency" (3 states) and "Transponder Group State" (4 states) as row dimensions. Once the test scenario matrix is ​​obtained, the expected processing result, i.e., whether to trigger deletion logic, can be set for different test scenarios based on the combination of their row and column dimensions.

[0036] Since the initial test scenario matrix may contain some redundant test scenarios, these can be removed or merged. For example, "never received" and "received but deleted" are logically equivalent in deletion and can be merged into a single state "packet not stored," thus merging these equivalent test scenarios. In the "inconsistent direction" scenario, the on-board equipment does not parse the transponder content and does not need to check the transponder group status, so these invalid test scenarios can be directly removed.

[0037] Regarding the above description of merging or removing "meaningless," "equivalent," or "identical" test scenarios from the initial test scenario matrix, there are three specific scenarios, which will be explained below.

[0038] Case 1: Determine if there are identical test scenarios in the test scenario matrix that have the same processing operation on the parking location information packet; if so, remove duplicates from the identical test scenarios.

[0039] In this context, identical test scenarios refer to test scenarios that are logically equivalent in terms of system processing. They trigger the system to perform the exact same processing operations; for example, under the same conditions, the system will execute either "delete CTCS-13 information packet" or "retain CTCS-13 information packet." These scenarios lead to duplicate verification during testing, wasting test resources. For instance, under the condition of "direction known and consistent + no CTCS-13 information packet," sleep mode, full monitoring mode, and AM mode will all trigger the "delete information packet" operation, and the processing logic of these three scenarios is completely identical. Under the condition of "information packet already stored + direction known and consistent + no CTCS-13 information packet," the system should perform the deletion operation regardless of the vehicle's operating mode. Therefore, system state machine analysis can be used to determine which dimension combinations are logically equivalent. The test scenario matrix identifies that under the scenario of "direction known and consistent + no CTCS-13 information packet," the processing logic of the three operating modes (sleep, full monitoring, AM) is identical. Scenarios with the same processing logic under the three operating modes are merged into one representative scenario. For example, "sleep mode" is retained as the representative (because it is the most critical for verifying the deletion logic). The specific representative scenario to be retained is: sleep mode + already stored + direction known and consistent + no CTCS-13 information packet.

[0040] Case 2: Determine if there are any invalid test scenarios in the test scenario matrix where the processing operation of the parking location information packet cannot be executed; if so, delete the invalid test scenarios.

[0041] In this context, invalid test scenarios refer to those where the system cannot perform processing operations under specific conditions. These scenarios will not occur in actual system operation, or the system will actively skip the processing logic, thus requiring no testing. For example, under the condition of "direction known but inconsistent," the system does not parse the transponder content, so the deletion operation will not be triggered regardless of the transponder group state. Under the condition of "direction unknown," the system does not process CTCS-13 packets, and the transponder group state does not need to be considered. Therefore, system state machine analysis can be used to determine which scenarios will cause the system to skip processing logic. Identify all combinations of transponder group states (4 types) under the "direction known but inconsistent" scenario. For example: direction known but inconsistent × transponder group state (no CTCS-13 packet, CTCS-13 packet with no error, non-CTCS-13 packet with error, CTCS-13 packet with error), a total of 4 scenarios. Directly remove these invalid test scenarios from the test scenario matrix.

[0042] Case 3: Determine if there are equivalent test scenarios with the same expected processing results in the test scenario matrix; if so, merge the equivalent test scenarios.

[0043] In this context, equivalent test scenarios refer to test scenarios that differ in system logic but have the same expected processing result. Although these scenarios have different input conditions, the system will provide the same processing result, and therefore can be combined into one test scenario. For example, under the condition of "direction known and consistent," both "no CTCS-13 packet" and "CTCS-13 packet present but message error" will trigger the deletion operation. Under the condition of "direction known but inconsistent," all transponder group states will cause the system not to perform the deletion operation. Therefore, according to the system specification, the expected processing result under different input conditions should be determined. For example, under the condition of "direction known and consistent," the system will delete the packet regardless of whether the transponder group state is "no CTCS-13 packet" or "CTCS-13 packet present but message error." Under the condition of "known and consistent direction", identify the test scenarios of "no CTCS-13 packet" and "CTCS-13 packet present but message error" in the transponder group status, and merge these two scenarios into a single test scenario of "known and consistent direction + no valid CTCS-13 packet in the transponder group". This reserved representative scenario is specifically: known and consistent direction + no valid CTCS-13 packet in the transponder group.

[0044] By performing deduplication, removal, and merging on different test scenarios in the test scenario matrix using the above three methods, the number of test scenarios can be reduced, duplicate verification can be avoided, test resources can be wasted, comprehensive verification of the CTCS-13 packet processing function can be ensured, and test efficiency and resource utilization can be significantly improved.

[0045] 203. Test requirements for obtaining train parking location information packets.

[0046] This step combines the description of step 101 in the above method, and the same content will not be repeated here.

[0047] 204. Match the corresponding target test scenario in the preset test scenario matrix based on the test requirements.

[0048] This step combines the description of step 102 in the above method, and the same content will not be repeated here.

[0049] 205. Use the combination of test points of the target test scenario as a test prerequisite.

[0050] In this step, the test preconditions characterize the system state, environment, or data conditions that must be met before test execution, ensuring that the test is performed in the correct initial state and avoiding interference from external factors. The combined test points of the target test scenario are mapped to system-recognizable parameter values. For example, the vehicle operation mode is mapped to the system's internal status code (run_mode=0 for sleep mode), the packet status is mapped to the stored status bit (info_status=1 for a stored valid CTCS-13 packet), the direction consistency is mapped to the direction matching flag (dir_match=1 for known and consistent directions), and the transponder group status is mapped to the status code (resp_status=0 for no CTCS-13 packet). In a simulation test platform (such as a CTCS-2 simulation environment based on MATLAB / Simulink), the test environment is initialized through the system API, the above parameter values ​​are set, and a status check script is executed to verify whether the preconditions are correctly configured. If the system state does not meet the preset conditions, the environment reset process is automatically triggered and the parameters are reconfigured to ensure the precise consistency of the test starting point, providing a reliable foundation for subsequent operations.

[0051] 206. Simulate the processing operation of the parking location information packet under the test conditions and obtain the test processing results.

[0052] In this step, the core of the simulation test operation lies in generating a sequence of transponder group reception events that meet the test prerequisites. For example, when the test conditions are that the direction is known and consistent and there is no CTCS-13 information packet, a transponder message containing a direction consistency identifier and no data content is constructed. This event is injected through a test framework (such as a Java test class) to trigger the system processing logic, while simultaneously monitoring key nodes of the entire process in real time: when the system receives a message, it records a direction consistency verification log; when the judgment logic triggers a deletion operation, it outputs a deletion command; when the deletion operation is executed, it records the packet ID information; and after updating the state machine, it confirms that the information packet status is deleted. The processing result is obtained through system log parsing and state machine API query. For example, the key information "Delete CTCS-13 info package" is extracted from the log, and the information packet status is queried through the API to verify successful deletion. The result is stored in structured data form, such as JSON format, containing scenario ID, prerequisites, operation result, and timestamp to ensure traceability.

[0053] Meanwhile, to handle test anomalies, a circuit breaker mechanism is implemented: if an operation fails, it automatically retryes up to three times; if it still fails, a critical error is recorded and the test is marked as failed, avoiding test interruptions caused by manual intervention. For example, in a sleep mode test scenario, after the system correctly executes the deletion operation, the log outputs "DeleteCTCS-13 info package (ID:0x1A3F)", and the API query returns the status "deleted". This implementation significantly improves test efficiency and result reliability through automated simulation and structured result capture.

[0054] 207. Compare the test results with the expected results to verify whether the processing of the parking location information packet is correct in the target test scenario.

[0055] This step combines the description of step 104 in the above method, and the same content will not be repeated here.

[0056] Furthermore, as a response to the above Figure 1-2 The implementation of the method embodiment shown in this application provides a testing device for processing parking location information packets. This device is used to comprehensively and efficiently verify whether the function of deleting the information packet by the on-board equipment in the corresponding scenario is correct, thereby ensuring the security and reliability of the deletion function. The embodiment of this device corresponds to the aforementioned method embodiment. For ease of reading, this embodiment will not repeat the details of the aforementioned method embodiment, but it should be clear that the device in this embodiment can correspondingly implement all the contents of the aforementioned method embodiment. Specifically, as shown... Figure 3 As shown, the device includes: A testing device for processing parking location information packets, characterized in that the device comprises: Acquisition unit 31 is used to acquire the test requirements of the train's parking position information packet; The matching unit 32 is used to match the corresponding target test scenario in the preset test scenario matrix based on the test requirements obtained by the acquisition unit 31. The test scenario matrix is ​​a set of test scenarios constructed according to the test points corresponding to the parking position information package. The test points include the train's own state test points and external input state test points. Each test scenario corresponds to an expected processing result. Test unit 33 is used to perform corresponding processing operations on the parking location information packet for the target test scenario obtained by the matching unit 32, and obtain test processing results; The verification unit 34 is used to compare the test processing result obtained by the test unit 33 with the expected processing result obtained by the matching unit to verify whether the processing operation of the parking location information packet is correct in the target test scenario.

[0057] Furthermore, such as Figure 4 As shown, the device further includes: The determining unit 35 is used to determine the test point corresponding to the parking position information packet before the matching unit 32. The test point includes the train's own status test point and the external input status test point. The train's own status test point includes the on-board operating mode and the status of the parking position information packet stored on-board. The external input status test point includes the consistency between the on-board operating direction and the parking position information direction and the status of the transponder group received on-board. The construction unit 36 ​​is used to construct a test scenario matrix based on the cross combination of the test points obtained by the determining unit, and to set corresponding expected processing results for each test scenario in the test scenario matrix.

[0058] Furthermore, such as Figure 4 As shown, the building unit 36 ​​includes: Processing module 361 is used to take the combination of the vehicle operation mode and the status of the parking location information packet stored in the vehicle as the column dimension, and the combination of the consistency between the vehicle operation direction and the parking location information direction and the status of the transponder group received by the vehicle as the row dimension. The construction module 362 is used to construct the test scenario matrix based on the row dimension and column dimension obtained by the processing module 361.

[0059] Furthermore, such as Figure 4 As shown, the test unit 33 includes: The determination module 331 is used to take the combined test points of the target test scenario as test prerequisites; The test module 332 is used to simulate the processing operation of the parking location information packet under the test premise conditions obtained by the determination module 331, and obtain the test processing result.

[0060] Furthermore, such as Figure 4 As shown, the device further includes: The first processing unit 37 is used to determine, after the construction unit 36, whether there is a identical test scenario in the test scenario matrix that has the same processing operation on the parking location information packet; if so, the identical test scenario is deduplicated.

[0061] Furthermore, such as Figure 4 As shown, the device further includes: The second processing unit 38 is used to determine, after the construction unit 36, whether there is an invalid test scenario in the test scenario matrix where the processing operation of the parking location information packet cannot be executed; if so, the invalid test scenario is deleted.

[0062] Furthermore, such as Figure 4 As shown, the device further includes: The third processing unit 39 is used to determine, after the construction unit 36, whether there is an equivalent test scenario in the test scenario matrix with the same expected processing result; if so, the equivalent test scenarios are merged.

[0063] Furthermore, embodiments of this application also provide a storage medium for storing a computer program, wherein the computer program, when running, controls the device where the storage medium is located to execute the above-described... Figure 1-2 The testing method for processing parking location information packets described herein.

[0064] Furthermore, embodiments of this application also provide a processor for running a program, wherein the program executes the above-described... Figure 1-2 The testing method for processing parking location information packets described herein.

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

[0066] It is understood that the relevant features in the above methods and apparatus can be referenced interchangeably. Furthermore, the terms "first," "second," etc., in the above embodiments are used to distinguish between embodiments and do not represent the superiority or inferiority of any particular embodiment.

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

[0068] The algorithms and displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, this application is not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of this application.

[0069] In addition, the memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0070] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0071] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0072] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0073] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0074] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0075] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0076] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0077] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0078] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0079] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for processing and testing parking location information packets, characterized in that, The method includes: Test requirements for obtaining train parking location information packets; Based on the test requirements, the corresponding target test scenario is matched in the preset test scenario matrix. The test scenario matrix is ​​a set of test scenarios constructed by combining test points corresponding to the parking position information package. The test points include test points of the train's own state and test points of external input state. Each test scenario corresponds to an expected processing result. For the target test scenario, perform corresponding processing operations on the parking location information packet to obtain the test processing results; The test processing results are compared with the expected processing results to verify whether the processing operation of the parking location information packet is correct under the target test scenario.

2. The method according to claim 1, characterized in that, Before matching the corresponding target test scenario in the preset test scenario matrix based on the test requirements, the method further includes: The test points corresponding to the parking position information packet are determined. The test points include the train's own status test points and the external input status test points. The train's own status test points include the onboard operating mode and the status of the parking position information packet stored onboard. The external input status test points include the consistency between the onboard running direction and the parking position information direction and the status of the transponder group received onboard. A test scenario matrix is ​​constructed based on the cross-combination of the test points, and corresponding expected processing results are set for each test scenario in the test scenario matrix.

3. The method according to claim 1, characterized in that, A test scenario matrix is ​​constructed based on the cross-combination of the test points, including: The combination of the vehicle operation mode and the status of the parking location information packet stored in the vehicle is used as the column dimension, and the combination of the consistency between the vehicle operation direction and the parking location information direction and the status of the transponder group received by the vehicle is used as the row dimension. The test scenario matrix is ​​constructed based on the row dimension and the column dimension.

4. The method according to claim 1, characterized in that, For the target test scenario, corresponding processing operations are performed on the parking location information packet to obtain the test processing results, including: The combined test points of the target test scenario are used as test prerequisites; The processing operation of the parking location information packet was simulated under the test premises to obtain the test processing result.

5. The method according to claim 2, characterized in that, After setting the corresponding expected processing results for each test scenario in the test scenario matrix, the method further includes: Determine whether there are identical test scenarios in the test scenario matrix that perform the same processing operation on the parking location information packet; If so, then duplicates of the same test scenarios will be removed.

6. The method according to claim 2, characterized in that, After setting the corresponding expected processing results for each test scenario in the test scenario matrix, the method further includes: Determine whether there are any invalid test scenarios in the test scenario matrix where the processing operation of the parking location information packet cannot be executed; If so, the invalid test scenario will be deleted.

7. The method according to claim 2, characterized in that, After setting the corresponding expected processing results for each test scenario in the test scenario matrix, the method further includes: Determine whether there exists an equivalent test scenario in the test scenario matrix that has the same expected processing result; If so, the equivalent test scenarios will be merged.

8. A device for processing and testing parking location information packets, characterized in that, The device includes: The acquisition unit is used to acquire the test requirements of the train's parking position information packet; The matching unit is used to match the corresponding target test scenario in the preset test scenario matrix based on the test requirements obtained by the acquisition unit. The test scenario matrix is ​​a set of test scenarios constructed according to the test points corresponding to the parking location information package. The test points include the train's own state test points and external input state test points. Each test scenario corresponds to an expected processing result. The testing unit is used to perform corresponding processing operations on the parking location information packet for the target test scenario obtained by the matching unit, and obtain the test processing result; The verification unit is used to compare the test processing result obtained by the test unit with the expected processing result obtained by the matching unit to verify whether the processing operation of the parking location information packet is correct in the target test scenario.

9. A storage medium, characterized in that, The storage medium includes a stored program, wherein, when the program is executed, it controls the device where the storage medium is located to perform the processing test method for the parking location information packet as described in any one of claims 1 to 7.

10. A processor, characterized in that, The processor is used to run a program, wherein the program executes the processing test method for the parking location information packet as described in any one of claims 1 to 7.

Images