Design method and design system for track traffic signal system fault test

Abstract

The application discloses a design method and a design system for track traffic signal system fault testing, belongs to the technical field of track traffic signal testing, and aims at the technical problems of insufficient test universality and low iteration response efficiency caused by the difficulty of the prior art in giving consideration to protocol diversity and frequent iteration. The core capability standardization of fault injection is agglomerated in the measured system, external general test tools are relied on to send fault injection instructions containing structured fields, six types of standardized fault injection operations of error code, insertion, out-of-order and the like are executed on specific links or target messages after instruction recognition, rule analysis and storage, and accurate message matching, the processed messages are sequentially transmitted through a periodic sending thread, the generalization adaptation of the test tool, full-scene coverage of fault types and significant reduction of iteration cost are realized, normal communication and fault testing are ensured to be parallel without contradiction, and the test efficiency and the comprehensiveness of reliability evaluation are greatly improved.

Description

Technical Field

[0001] This invention relates to the field of rail transit signal testing technology, and more specifically, to a design method and system for fault testing of rail transit signal systems. Background Technology

[0002] In the field of communication testing for rail transit signaling systems, existing technologies generally employ independently developed testing tools to simulate the peer end for specific communication protocols and manually inject faults such as errors and delays to verify the system's protection capabilities. However, existing solutions have systemic flaws: First, due to the diversity and frequent iterations of signaling system protocols, dedicated tools must be developed and maintained separately for each type of protocol, resulting in high development costs and complex deployment. Second, the test logic is hard-coded into the tool, requiring redevelopment and re-release of the tool when the protocol format or interaction mechanism changes, making it difficult to match the rapid iteration pace of R&D. Third, the lack of a unified fault injection mechanism makes it impossible to dynamically configure the combinations of fault types such as insertion, out-of-order, duplication, delay, and errors required by the EN50159 standard, resulting in incomplete fault coverage. These flaws not only significantly increase the investment of testing resources but also lead to low fault verification efficiency and insufficient system reliability assessment, failing to adapt to the rapid iteration pace of development and high reliability testing requirements of rail transit signaling systems. Therefore, there is an urgent need for a universal fault injection mechanism that can be uniformly managed, flexibly configured, and loosely coupled with the system under test to solve the problems of insufficient test universality and efficiency bottlenecks.

[0003] The information disclosed in the background section is only intended to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0004] The purpose of this invention is to address the technical problems of insufficient test versatility and low iterative response efficiency caused by the difficulty of balancing protocol diversity and frequent iterations in existing technologies. A design method and system for fault testing of rail transit signaling systems are proposed. The core capability of fault injection is extracted and standardized from multiple external dedicated testing tools and integrated into the system under test. This allows for flexible adaptation to different communication protocols and message formats simply by sending different command parameters through external tools. This fundamentally solves the problems of redundant development and high maintenance costs of testing tools caused by protocol differences and rapid iterations, significantly improving the versatility of testing and iterative response efficiency.

[0005] In a first aspect, one technical solution provided in this embodiment of the invention is: a design method for fault testing of rail transit signaling systems, comprising the following steps: Receive communication data from external testing tools and determine whether the communication data is a fault injection instruction; If it is a fault injection command, then the fault injection command is parsed to obtain the fault injection rule; the fault injection rule includes the target link identifier, the fault type identifier, and the target packet matching condition; If it is not a fault injection instruction, the communication data is determined to be normal communication data, processed according to the standard communication processing procedure, and placed into the data buffer to be sent. During the periodic processing of packets, packets flowing through are filtered and matched in real time according to the target link identifier and target packet matching conditions in the fault injection rules. According to the target fault type indicated by the fault type identifier, the corresponding fault injection operation is performed on the successfully matched message, and the message after the operation is placed into the data buffer to be sent. The sending thread periodically retrieves messages from the data buffer to be sent and sends them to the corresponding communication object.

[0006] As a preferred technical solution, the step of receiving communication data from an external testing tool and determining whether the communication data is a fault injection command is as follows: Receive raw data frames transmitted through an established communication link; check the start and end flags of the raw data frames; If the start flag and the end flag are respectively a predefined first specific value and a second specific value, then the communication data is determined to be a fault injection instruction.

[0007] As a preferred technical solution, if the instruction is a fault injection command, the steps for parsing the fault injection command to obtain the fault injection rules are as follows: The communication data identified as fault injection instructions is parsed to extract its internal structured field information; The target link identifier, fault type identifier, and target packet matching conditions in the fault injection rule are determined and recorded based on the structured field information. The fault injection rules, which record the target link identifier, fault type identifier, and target message matching conditions, are stored.

[0008] As a preferred technical solution, the process of parsing the fault injection instruction further includes: Determine whether the fault injection command contains a clear command identifier; If included, clear all stored fault injection rules and related fault injection states.

[0009] As a preferred technical solution, the structured field information includes at least: a link field for indicating the communication link in which the fault is effective, a type field for specifying any one of the fault types such as error, insertion, out-of-order, deletion, duplication or delay, a matching condition field for defining the message matching conditions, and a parameter field containing parameters such as the offset, length, content or delay time to be modified.

[0010] As a preferred technical solution, the steps for real-time filtering and matching of flowing packets during the periodic packet processing process are as follows: Determine whether the fault injection targets all communication links based on the target link identifier; If not, then in the packet stream of the specific link indicated by the target link identifier, determine whether the packet type and the byte content at the specified offset position match according to the target packet matching conditions; If so, then in the message stream of all communication links, determine whether the message type and the byte content at the specified offset position match according to the target message matching conditions.

[0011] As a preferred technical solution, the step of performing the corresponding fault injection operation on the successfully matched message according to the target fault type indicated by the fault type identifier is as follows: Obtain the target fault type and corresponding operation parameters according to the stored fault injection rules; based on the target fault type, select and perform one of the following operations: When the target fault type is a code error fault, modify the byte content at the specified offset position in the successfully matched message according to the operation parameters, and selectively recalculate or directly modify the message checksum according to the rules. When the target fault type is an insertion fault, the matched message is copied, the target address corresponding to the message is modified to an invalid address, and then sent to the buffer. When the target fault type is an out-of-order fault, the sequence number field in the successfully matched message is adjusted according to the operation parameters. When the target fault type is a deletion fault, the successfully matched message is discarded. When the target fault type is a duplicate fault, the successfully matched message is copied or its sequence number is modified to create a duplicate transmission effect. When the target fault type is a delay fault, modify the timestamp field inside the successfully matched message, or start a timer to delay its actual transmission time.

[0012] Secondly, an embodiment of the present invention also provides a technical solution: a design system for fault testing of rail transit signaling systems, applicable to the design method for fault testing of rail transit signaling systems as described in any one of the first aspects, comprising: The communication interface module is used to establish and maintain a communication link with external testing tools and to receive communication data transmitted through the communication link. A communication instruction identification module, connected to the communication interface module, is used to determine whether the received communication data is a fault injection instruction; The rule parsing and storage module is connected to the instruction recognition module and is used to parse the communication data to extract the fault injection rules and store them when the communication data is determined to be a fault injection instruction. A normal communication processing module, connected to the instruction recognition module, is used to process the communication data according to the standard communication processing procedure when the communication data is determined not to be a fault injection instruction. The message matching engine, connected to the rule parsing and storage module, is used to perform real-time filtering and matching of the flowing messages according to the stored fault injection rules during the periodic message processing process. The fault injection module is connected to the message matching engine and the rule parsing and storage module, and is used to perform the corresponding fault injection operation on the successfully matched message according to the rules. The message sending module is connected to the normal communication processing module and the fault injection execution module, respectively. It is used to receive and buffer the processed messages, and periodically send them to the corresponding communication objects through the sending thread.

[0013] Thirdly, one technical solution provided in the embodiments of the present invention is: an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor, when calling the computer program in the memory, implements the steps of a design method for fault testing of a rail transit signaling system as described in any one of the first aspects.

[0014] Fourthly, one technical solution provided in this embodiment of the invention is: a storage medium storing computer-executable instructions, wherein when the computer-executable instructions are loaded and executed by a processor, the steps of a design method for fault testing of a rail transit signaling system as described in any one of the first aspects are implemented.

[0015] The present invention has at least the following substantial beneficial effects: (1) In view of the problem of high cost of repeated development and maintenance of test tools due to the diversity of protocols and rapid iteration, this application integrates the core capability of fault injection into the system under test and builds a dynamic parameter configuration interface based on external instructions. It simplifies the simulation of specific communication protocols and injection logic into sending structured control instructions, and realizes the real-time parsing and execution mechanism of fault injection rules. There is no need to develop dedicated test tools for each type of communication protocol, which significantly reduces the investment in test resources and maintenance costs, and enables the testing of rail transit signaling systems to efficiently adapt to protocol iteration requirements and meet high reliability verification requirements.

[0016] (2) In view of the problem of incomplete fault coverage caused by the lack of a unified fault injection mechanism in the existing test scheme, this application defines six types of standardized fault injection logic: error code, insertion, out-of-order, deletion, duplication, and delay. Combined with precise positioning of message offset, dynamic recalculation or direct modification of check code, and fine parameter configuration such as timer delay scheduling, it supports single field / multi-field combination modification and flexible combination of fault types. It realizes high-precision, full-scenario simulation of various potential hazards in the communication process of rail transit signal system, ensures that fault testing is highly consistent with industry standard requirements, effectively improves the comprehensiveness and accuracy of system reliability assessment, and solves the technical bottleneck of insufficient fault simulation in traditional test methods.

[0017] (3) To address the problem of low testing efficiency caused by the difficulty of traditional testing tools in matching the rapid iterative development pace, this application designs a structured storage and instruction-based clearing mechanism for fault injection rules, which supports clearing historical configurations with a single click using a specific identifier. At the same time, combined with the collaborative scheduling of the periodic message matching engine and the data buffer to be sent, it realizes the closed-loop management of dynamic activation of fault injection, accurate message screening and matching, and orderly sending. This not only avoids tool reconstruction due to changes in communication protocols or adjustments to test scenarios, significantly reducing iterative maintenance costs, but also ensures the controllability and stability of the fault injection process through partitioning and periodic scheduling of normal communication data and fault injection data, avoiding interference with the normal communication process of the system under test, and improving the safety and reliability of the testing process.

[0018] The above description of the invention is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0019] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings. The drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings.

[0020] Figure 1 This is a simplified flowchart of a design method for fault testing of a rail transit signaling system according to an embodiment of the present invention.

[0021] Figure 2 This is a detailed flowchart of a design method for fault testing of a rail transit signaling system according to an embodiment of the present invention.

[0022] Figure 3 This is a structural block diagram of the design system according to an embodiment of the present invention.

[0023] Figure 4 This is a user operation flowchart of the design system according to an embodiment of the present invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only one preferred embodiment of this invention and are only used to explain this invention. They do not limit the scope of protection of this invention. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0025] Before discussing the exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the operations (or steps) as sequential processes, many of the operations (or steps) can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but it may also have additional steps not included in the figures; the process may correspond to a method, function, procedure, subroutine, subroutine, etc.

[0026] Example 1: As Figure 1 As shown in the figure, one technical solution provided in this embodiment of the invention is: a design method for fault testing of rail transit signaling systems, comprising the following steps: First, receive communication data from an external testing tool and determine whether the communication data is a fault injection instruction.

[0027] As a preferred technical solution, the steps for receiving communication data from an external testing tool and determining whether the communication data is a fault injection command are as follows: Receive raw data frames transmitted through an established communication link; check the start and end flags of the raw data frames; If the start flag and the end flag are respectively a predefined first specific value and a second specific value, then the communication data is determined to be a fault injection instruction.

[0028] Understandably, in order to achieve high-precision identification and secure isolation of fault injection commands in the communication link and avoid confusion with regular communication data leading to false triggering or system interference, this embodiment embeds a lightweight frame structure verification mechanism in the communication protocol processing flow, using the predefined flag bit features of the data frame header and trailer for rapid identification. Specifically, after receiving the original data frame, by comparing in real time whether the start flag bit S and the end flag bit E are equal to the preset FE and EF respectively (for example, in actual deployment, this flag bit sequence is uniformly configured by the test system to match the EN50159 standard command format), zero-false-judgment of fault injection commands is achieved, thereby ensuring the immediate parsing and execution of fault commands while ensuring the continuity of normal communication, significantly improving the reliability of command processing and system robustness.

[0029] Furthermore, if it is a fault injection instruction, the fault injection instruction is parsed to obtain fault injection rules; the fault injection rules include target link identifier, fault type identifier, and target packet matching conditions.

[0030] As a preferred technical solution, if the instruction is a fault injection command, the steps for parsing the fault injection command to obtain the fault injection rules are as follows: The communication data identified as fault injection instructions is parsed to extract its internal structured field information; The target link identifier, fault type identifier, and target packet matching conditions in the fault injection rule are determined and recorded based on the structured field information. The fault injection rules, which record the target link identifier, fault type identifier, and target message matching conditions, are stored.

[0031] Understandably, to address the issues of unclear fault injection targets and chaotic execution logic caused by the lack of standardized parsing mechanisms and the difficulty in accurately extracting core control information from fault injection instructions, this embodiment first performs structured parsing on the identified fault injection instructions to accurately extract structured field information such as link field, type field, matching condition field, and parameter field (for example, a link field value of 0x02 indicates communication link 2, a type field value of 0x05 specifies a repeated fault type, and the matching condition field defines the message type as 0x10 and the byte content at offset 0x06 as 0x34). Based on the extracted structured field information, the core elements of the fault injection rule are determined and recorded one by one, such as the target link identifier (clarifying the scope of fault effectiveness), the fault type identifier (specifying the fault injection method), and the target message matching condition (locking the message to be processed). Finally, the complete fault injection rule is stored in a dedicated storage unit for subsequent use.

[0032] In this embodiment, a standardized definition and solidified storage mechanism for fault injection rules are established through hierarchical parsing of structured fields and targeted extraction of key information. This ensures that rule elements are free of redundancy, omissions, and are traceable. The parsing step enables the orderly decomposition of instruction information, avoiding information loss due to field confusion. The record determination step clarifies the core execution basis for fault injection, providing support for subsequent precise operations. The storage step enables the persistence and rapid retrieval of rules. Ultimately, this achieves standardized, precise definition and efficient management of fault injection rules, laying a solid foundation for the orderly implementation of periodic message matching and fault injection operations.

[0033] As a preferred technical solution, the process of parsing the fault injection instruction further includes: Determine whether the fault injection command contains a clear command identifier; If included, clear all stored fault injection rules and related fault injection states.

[0034] Understandably, to address the issue of old, stored fault injection rules and related states causing interference with new test logic and reduced test accuracy when switching test scenarios or changing fault injection requirements, this embodiment adds a targeted judgment step for clearing instruction identifiers to the fault injection instruction parsing process. A specific structured field (e.g., an identifier with the second byte set to 0) is predefined as a dedicated identifier for the clear instruction. When this identifier is parsed, a global clearing mechanism is triggered, clearing all stored fault injection rules, including target link identifiers, fault type identifiers, and packet matching conditions, as well as corresponding fault switch states and packet matching caches. The system thoroughly clears the state by binding a unique identifier to the global clearing logic, establishing a rapid reset mechanism for fault injection rules to ensure the accuracy and comprehensiveness of the clearing operation. The judgment step clearly distinguishes between clearing requirements and normal rule configuration requirements, avoiding accidental clearing. The clearing step ensures that rules and states are completely cleared without residue, ultimately achieving dynamic and flexible management of fault injection rules. This allows for rapid adaptation to the switching needs of different test scenarios, ensuring that each test is conducted based on a clean initial state. This significantly improves the independence of the test logic and the accuracy of the results, while simplifying the operation process for multi-scenario testing and reducing the complexity of test configuration.

[0035] As a preferred technical solution, the structured field information includes at least: a link field for indicating the communication link in which the fault is effective, a type field for specifying any one of the fault types such as error, insertion, out-of-order, deletion, duplication or delay, a matching condition field for defining the message matching conditions, and a parameter field containing parameters such as the offset, length, content or delay time to be modified.

[0036] Understandably, to address the issues of unclear fault injection scope, ambiguous types, and insufficient operational parameters caused by chaotic fault injection command parameter definitions and missing or inconsistent key control information, this embodiment defines a standardized set of structured fields, specifying that it contains at least four core functional fields: link field, type field, matching condition field, and parameter field. The link field precisely indicates the communication link where the fault takes effect (e.g., a value of 0x00 represents all communication links, and a value of 0x03 represents a specific communication link, number 3; this field directly limits the scope of the fault's effect, avoiding mismatches). The type field uniquely specifies one of six fault types (e.g., a value of 0x01 corresponds to an error code fault, 0x02 to an insertion fault, and 0x06 to a delay fault, achieving standardized identification of fault types and ensuring accurate correspondence in the injection logic). The matching condition field explicitly defines the target message filtering rules (e.g., defining the message type as 0x...). 20. The specified offset 0x08 byte content is 0x45, achieving precise locking of the target message and avoiding misprocessing of irrelevant messages. The parameter field provides specific parameters for the fault operation (e.g., for error code faults, it includes the offset to be modified 0x0A, length 2 bytes, target content 0x7890; for delay faults, it includes the delay time 50ms, providing a refined execution basis for fault injection). Through precise subdivision and standardized definition of field functions, a complete information chain covering fault scope, fault type, target message, and operation parameters is constructed, ensuring that the fault injection instruction contains all necessary execution elements and has a unified format. Ultimately, the standardized and refined definition of fault injection rules is achieved, avoiding deviations in fault injection execution due to missing parameters or chaotic formats. This provides comprehensive and reliable information support for subsequent message matching and accurate implementation of fault operations. At the same time, the standardized field design reduces the difficulty of instruction parsing and improves the scalability and adaptability of fault injection.

[0037] Furthermore, if it is not a fault injection instruction, the communication data is determined to be normal communication data, processed according to the standard communication processing procedure, and placed into the data buffer to be sent.

[0038] Understandably, to avoid interference from the identification and processing of fault injection commands with the transmission of normal communication data, and to ensure that the normal communication functions of the tested rail transit signaling system are not affected by the testing activities, this embodiment first clearly classifies the communication data that is determined to be non-fault injection commands after command identification, defining it as normal communication data (this determination step achieves strict separation of fault injection data and normal communication data, avoiding transmission anomalies caused by mixed processing of the two types of data). Then, a standardized processing procedure is executed according to the standard communication protocol corresponding to the rail transit signaling system (such as train control-related communication protocols), including message format verification, data integrity verification, and protocol field compliance checks (for example, verifying the message frame header, data segment, and checksum one by one to ensure that the data conforms to the communication protocol). Following defined format requirements, this processing step ensures the validity and compliance of normal communication data. Finally, the processed normal communication data is stored in a dedicated buffer for data to be sent. Through the design logic of accurate data type determination, standardized compliance processing, and temporary storage in a dedicated buffer, normal communication data and fault injection-related data are physically isolated and flow independently. Ultimately, this ensures that normal communication data is processed according to the established protocol specifications, guaranteeing the stability and reliability of the normal communication functions of the system under test. At the same time, the temporary storage mechanism of the buffer for data to be sent provides an orderly data storage foundation for the periodic retrieval and transmission of data by the subsequent sending thread, avoiding data transmission congestion or loss. Furthermore, it complements the fault injection data processing flow, enabling the parallel operation of testing activities and normal communication.

[0039] Furthermore, during the periodic processing of messages, the messages flowing through are filtered and matched in real time according to the target link identifier and target message matching conditions in the fault injection rules.

[0040] As a preferred technical solution, the steps for real-time filtering and matching of flowing packets during the periodic packet processing process are as follows: Determine whether the fault injection targets all communication links based on the target link identifier; If not, then in the packet stream of the specific link indicated by the target link identifier, determine whether the packet type and the byte content at the specified offset position match according to the target packet matching conditions; If so, then in the message stream of all communication links, determine whether the message type and the byte content at the specified offset position match according to the target message matching conditions.

[0041] Understandably, to address the issues of lack of directionality and low matching accuracy in traditional fault injection message filtering, which leads to the misprocessing of irrelevant messages or the omission of target messages, thus affecting the targeting and efficiency of fault testing, this embodiment constructs a two-layer filtering mechanism in the periodic message processing flow: link range pre-screening + precise message attribute matching. First, the link range is determined based on the target link identifier in the fault injection rules (e.g., a target link identifier value of 0x00 indicates it applies to all communication links, while a value of 0x01 indicates it applies to specific communication link 1; this step achieves targeted locking of the fault's scope, avoiding inefficient processing caused by indiscriminate traversal of the entire link). If it is determined to be a specific link, the message flow of that link is focused; if it is all links, the entire message flow is covered. Then, double verification is performed based on the target message matching conditions. The execution logic of the double verification is: first, determine whether the message type matches the pre-screening criteria... Assuming consistent message types (e.g., a preset message type of 0x30, matching only messages of this type), the byte content at a specified offset position of the message is then verified to meet the requirements (e.g., the byte content at offset 0x05 must be 0x67, precisely locking the target message). The filtering base is narrowed by limiting the link range beforehand, and a precise matching standard is established through dual attribute verification of message type and byte content. This achieves a message filtering logic with controllable range and precise attributes. The link range determination step significantly reduces the amount of data filtered, improving processing efficiency. The dual message verification step ensures accurate identification of the target message, avoiding mismatches and missed matches. Ultimately, this achieves efficient and accurate filtering of target messages for fault injection, providing precise processing objects for subsequent targeted fault injection operations, significantly improving the targeting and execution efficiency of fault testing, while avoiding invalid processing of irrelevant messages and reducing the resource consumption of the tested system.

[0042] Furthermore, based on the target fault type indicated by the fault type identifier, the corresponding fault injection operation is performed on the successfully matched message, and the processed message is placed into the data buffer to be sent.

[0043] As a preferred technical solution, the step of performing the corresponding fault injection operation on the successfully matched message according to the target fault type indicated by the fault type identifier is as follows: Obtain the target fault type and corresponding operation parameters according to the stored fault injection rules; based on the target fault type, select and perform one of the following operations: When the target fault type is a code error fault, modify the byte content at the specified offset position in the successfully matched message according to the operation parameters, and selectively recalculate or directly modify the message checksum according to the rules. When the target fault type is an insertion fault, the matched message is copied, the target address corresponding to the message is modified to an invalid address, and then sent to the buffer. When the target fault type is an out-of-order fault, the sequence number field in the successfully matched message is adjusted according to the operation parameters. When the target fault type is a deletion fault, the successfully matched message is discarded. When the target fault type is a duplicate fault, the successfully matched message is copied or its sequence number is modified to create a duplicate transmission effect. When the target fault type is a delay fault, modify the timestamp field inside the successfully matched message, or start a timer to delay its actual transmission time.

[0044] Understandably, to address the problem of traditional fault injection methods being limited by their single type and rigid operational logic, making it difficult to accurately simulate various communication faults required by the EN50159 standard, resulting in incomplete coverage and insufficient verification depth in fault testing scenarios for rail transit signaling systems, this embodiment first precisely extracts the target fault type and corresponding operational parameters from pre-stored fault injection rules (this step provides a clear execution basis for fault injection, ensuring no deviation between the operation direction and parameters), and then constructs a standardized execution mechanism to trigger the corresponding injection logic based on the target fault type: When it is an error code fault, the corresponding bytes of the message are modified according to the operational parameters (such as specifying offset 0x0C, length 3 bytes, target content 0x123456), and the CRC checksum is recalculated or the checksum field is directly modified according to the rules (for example, recalculating the CRC when modifying the data field, and directly changing the 2-byte checksum at offset 0x1F to 0xABCD when simulating a checksum fault), achieving dual simulation of data content and checksum faults; when it is an insertion fault, the target address is modified to an invalid value (such as 0xFFFF) after copying the matching message and then sent to the buffer to simulate illegal message insertion. The system is designed to simulate various scenarios. For out-of-order faults, the sequence number is adjusted according to operation parameters (e.g., offsetting the sequence number field by 0x08, adding 2) to create a message out-of-order effect. For deletion faults, matching messages are directly discarded to simulate data loss. For duplicate faults, duplicate content or identifiers are implemented by copying messages or modifying the sequence number (e.g., decrementing the sequence number by 1). For delay faults, either the message timestamp field is modified (e.g., reduced by 50ms), or a timer is started to delay transmission by 100ms, accurately simulating transmission delay. This system defines specific operation logic for six types of faults, combined with... Parameterized configuration enables refined and scenario-based control of fault injection. Among them, the parameter extraction step ensures the accuracy of operation, and various dedicated operation steps realize high-fidelity simulation of the corresponding faults. In the end, it achieves accurate reproduction of all types of faults required by the EN50159 standard, which greatly improves the comprehensiveness and depth of fault testing. At the same time, standardized operation logic ensures the consistency and repeatability of fault injection, providing reliable fault simulation support for the verification of system protection capabilities. The storage of the message after operation in the data buffer to be sent ensures the orderly transmission of fault messages and avoids data chaos.

[0045] Furthermore, the sending thread periodically retrieves messages from the data buffer to be sent and sends them to the corresponding communication object.

[0046] Example 2, as a further description of the implementation details of Example 1, also provides an implementation method as follows: Figure 2 As shown, specifically in steps one through seventeen: Step 1: The platform software starts up, initializes all connections according to the configuration information, and establishes communication links, including communication between various modules within the system and communication with the testing tools; Step Two: Once the communication links are established, the platform software begins receiving and sending data through the various internal communication links. The testing tool writes scripts according to the agreed-upon rules and sends test data to the software platform. Step 3: Parse the data received in Step 2. First, parse the flag bits. Based on the flag bits, it can be determined whether the current communication data is normal communication data or fault injection data sent by the test tool. Step 4: Determine if the first byte of the flag parsed in Step 3 is 0xFE and the last byte is 0xEF. If so, it means that the data is fault injection data, then proceed to Step 5. If not, it means that the data is normal communication data, then continue to Step 11. Step 5: Pass the data to the fault injection logic layer and parse the data according to the agreed structure; Step Six: Determine if the second byte in Step Five is 0. If it is, clear all fault settings; otherwise, proceed to Step Seven. Step 7: Turn on the fault switch and check if the third byte in Step 5 is 0. The third byte represents the fault type setting: 0 represents no fault injection, 1 represents a code error fault, 2 represents an insertion fault, 3 represents an out-of-order fault, 4 represents a deletion fault, 5 represents a duplicate fault, and 6 represents a delay fault. If it is 0, exit the fault setting logic; otherwise, continue to Step 8. Step 8: Determine if the fourth byte in Step 5 is 0. If it is 0, exit the fault setting logic; otherwise, continue to Step 9. Step 9: Determine if the fifth to eighth bytes in Step 5 are 0. If they are 0, it means that fault injection is performed on all links; if they are not 0, it means that fault injection is performed on a specific link. In the two-by-two architecture communication of the software platform, there are four communication links at the same time. By setting faults using this method, a more comprehensive test of each state machine of the communication link can be performed. Step 10: Store the link number parsed in Step 5, the type of message to be modified, the content of the specified location of the message to be modified, the fault injection type, the delay time, etc. Steps five through ten above are for turning on the fault injection switch and storing the fault type and settings, or turning off the fault injection switch and clearing the fault injection data; Step 11: Determine if the fault switch is open. If yes, continue to Step 12; otherwise, proceed to Step 2. Step 12: Determine if the current fault setting applies to all communication links. If yes, proceed to Step 13; otherwise, proceed to Step 17. Step 13: Pass the data to the fault injection logic layer and parse the data; Step Fourteen: Determine if the current message type is the specified fault message type. If yes, proceed to Step Fifteen; otherwise, pass the data to the next layer. Step 15: Determine if the content at the specified position of the current data matches the content to be matched in the fault injection settings. If they match, proceed to Step 16; otherwise, pass the data to the next layer. The matching content here can include a specified offset of 1, a specified byte length of 1, a specified byte content of 1, ..., a specified offset of n, a specified byte length of n, and a specified byte content of n. Step Sixteen: Execute the fault according to the fault type in Step Seven: Step 17: The sending thread periodically retrieves data from the data buffer to be sent and sends it to various communication objects on the software platform; Steps 11 to 17 involve fault injection matching and setting faults in the communication messages of the platform under test. This method can not only perform security testing on the communication protocol, but also perform security testing on various functions of the software platform under test through fault codes, deletion faults, out-of-order faults, delay faults, etc. During the continuous communication process, repeat steps two through seventeen.

[0047] It should be noted that when the fault type is an insertion fault, the fault data stored in step ten includes the communication link ID and whether the CRC field is updated. This fault involves copying the matched data, modifying the link ID to a non-existent ID, updating the data CRC, and then placing it in the data buffer to be sent. This fault injection method is applicable to communication hazard testing for all protocols. For external communication protocols, the sid or did needs to be modified to an unconfigured ID; for internal communication protocols, the link ID needs to be modified to an unspecified ID. This allows for testing whether security protection is provided for insertion faults in communication hazards.

[0048] It should be noted that when the fault type is out-of-order fault, the fault data stored in step ten includes the specified field offset, length, addition / subtraction of a specified value, and whether to update the CRC field. This fault involves adding or subtracting a certain value from the sequence number in the matched data, updating the data CRC, and then placing the data into the data buffer to be sent. This method achieves the effect of out-of-order delivery by adding or subtracting values ​​from the sequence number, first increasing and then decreasing it, and then checking whether the platform verifies it, thereby testing whether security protection is provided for out-of-order faults in communication hazards.

[0049] It should be noted that when the fault type is deletion fault, the fault data stored in step ten includes the specified sequence number offset, byte length, and whether the CRC is updated. This fault will directly discard the matched data and not put it into the data buffer to be sent. This method achieves packet loss through faulting, thereby testing whether deletion faults, which pose a threat to communication, provide security protection.

[0050] It should be noted that when the fault type is a duplicate fault, the fault data stored in step ten includes whether to copy the message, specify the sequence number offset, byte length, and whether to update the CRC. This fault includes duplicate sequence numbers and duplicate data content. If it is a duplicate sequence number, the sequence number obtained from the fault content of the matched data is decremented by 1 to make the sequence number consistent with the last sent sequence number, and the CRC is updated and saved to the data buffer to be sent; if it is a duplicate data content, the matched data is copied and placed into the data buffer to be sent. This method tests whether security protection is implemented for duplicate faults in communication hazards by setting the message sequence numbers to be consistent in two cycles or receiving two completely identical messages in the same cycle.

[0051] It should be noted that when the fault type is a delay fault, the fault data stored in step ten includes whether to delay the message, the specified sequence number offset, byte length, timestamp offset, byte length, expected delay time, and whether to update the CRC. This fault is divided into faults that reduce the sending timestamp in the message by a specified time and faults that delay the message transmission. If it is a message timestamp modification, the sending timestamp field is obtained according to the stored fault content, and the timestamp is reduced to make its transmission time exceed the configured tolerance value, and the data is placed in the data buffer to be sent. If it is a message delay fault, a timer is started according to the time stored in the fault content, the matched data is waited for the specified delay time, the timer is stopped, and the data is placed in the data buffer to be sent. This method tests whether security protection is provided for delay faults in communication hazards by modifying the sending timestamp field in the message and delaying the actual transmission time of the message.

[0052] Example 3, another embodiment provided in this invention is: a design system for fault testing of rail transit signaling systems, applicable to a design method for fault testing of rail transit signaling systems as described in any one of Examples 1 or 2, such as... Figure 3 As shown, it includes: The communication interface module is used to establish and maintain a communication link with external testing tools and to receive communication data transmitted through the communication link. A communication instruction identification module, connected to the communication interface module, is used to determine whether the received communication data is a fault injection instruction; The rule parsing and storage module is connected to the instruction recognition module and is used to parse the communication data to extract the fault injection rules and store them when the communication data is determined to be a fault injection instruction. A normal communication processing module, connected to the instruction recognition module, is used to process the communication data according to the standard communication processing procedure when the communication data is determined not to be a fault injection instruction. The message matching engine, connected to the rule parsing and storage module, is used to perform real-time filtering and matching of the flowing messages according to the stored fault injection rules during the periodic message processing process. The fault injection module is connected to the message matching engine and the rule parsing and storage module, and is used to perform the corresponding fault injection operation on the successfully matched message according to the rules. The message sending module is connected to the normal communication processing module and the fault injection execution module, respectively. It is used to receive and buffer the processed messages, and periodically send them to the corresponding communication objects through the sending thread.

[0053] Understandably, to address the lack of modular and collaborative architecture support in existing fault testing, which leads to poor fault injection process integration, severe functional coupling between stages, and difficulty in efficiently adapting to the needs of generalized and precise fault testing, this embodiment constructs a full-link modular collaborative system encompassing "communication access - command recognition - rule parsing - data splitting - message matching - fault injection - data transmission." Through modular functional decomposition and targeted linkage, a closed-loop collaborative architecture covering the entire fault testing process is built. Each module has a focused function and standardized interfaces, ensuring smooth process integration. Ultimately, this achieves standardized and efficient operation of the fault testing process. The collaborative cooperation of each module ensures both the accuracy and comprehensiveness of fault injection (such as the standardized execution of 6 types of faults) and the stable transmission of normal communication data. At the same time, the modular design improves the system's scalability and maintainability, perfectly adapting to the needs of generalized fault testing in rail transit signaling systems, and significantly reducing the implementation complexity and resource consumption of fault testing.

[0054] Example 4, based on the design methods described in Examples 1 and 2 and the design system described in Example 3, such as Figure 4 As shown, those skilled in the art perform fault testing using the following methods: Step A: The user writes script information, including but not limited to the link information to be injected with faults and fault data; Step B: The user starts the test platform; Step C: Start the testing tool; Step D: Perform the test; Step E: Wait for the test to finish; Step F: Analyze the test results; Step D: End the test.

[0055] Understandably, to standardize the execution process of fault testing for rail transit signaling systems, ensure repeatable test operations and traceable results, and fully leverage the advantages of the aforementioned design methods and systems in terms of generalization and precision fault injection, this embodiment constructs a standardized test operation process of "script configuration - environment startup - test execution - result analysis - process closure." This standardized operation connects external script configuration with internal system module collaboration, ensuring precise adaptation of the test process to the aforementioned design methods and system architecture. Ultimately, it achieves standardized and efficient execution of fault testing, lowering the user's operational threshold while fully leveraging the advantages of generalized fault injection through precise coordination of each step, ensuring the accuracy and reliability of test results, and providing practical operational support for verifying the protection capabilities of rail transit signaling systems.

[0056] Example 5, one embodiment of the present invention is: an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor, when calling the computer program in the memory, implements the steps of a design method for fault testing of a rail transit signaling system as described in any one of Examples 1 or 2.

[0057] Example 6: One embodiment of the present invention is a storage medium storing computer-executable instructions. When the computer-executable instructions are loaded and executed by a processor, they implement the steps of a design method for fault testing of a rail transit signaling system as described in any one of Examples 1 or 2.

[0058] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the specific device can be divided into different functional modules to complete all or part of the functions described above.

[0059] In the embodiments provided in this application, it should be understood that the disclosed structures and methods can be implemented in other ways. For example, the structural embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another structure, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between structures or units, and may be electrical, mechanical, or other forms.

[0060] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0061] Furthermore, in the embodiments of this application, the functional units can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

[0063] The specific embodiments described above are preferred embodiments of the design method and design system for fault testing of rail transit signaling systems of the present invention, and are not intended to limit the specific scope of the present invention. The scope of the present invention includes but is not limited to the specific embodiments described above. All equivalent changes made in accordance with the shape and structure of the present invention are within the protection scope of the present invention.

Claims

1. A design method for fault testing of rail transit signaling systems, characterized in that: Includes the following steps: Receive communication data from external testing tools and determine whether the communication data is a fault injection instruction; If it is a fault injection command, then the fault injection command is parsed to obtain the fault injection rule; the fault injection rule includes the target link identifier, the fault type identifier, and the target packet matching condition; If it is not a fault injection instruction, the communication data is determined to be normal communication data, processed according to the standard communication processing procedure, and placed into the data buffer to be sent. During the periodic processing of packets, packets flowing through are filtered and matched in real time according to the target link identifier and target packet matching conditions in the fault injection rules. According to the target fault type indicated by the fault type identifier, the corresponding fault injection operation is performed on the successfully matched message, and the message after the operation is placed into the data buffer to be sent. The sending thread periodically retrieves messages from the data buffer to be sent and sends them to the corresponding communication object.

2. The design method for fault testing of rail transit signaling systems according to claim 1, characterized in that: The step of receiving communication data from an external testing tool and determining whether the communication data is a fault injection command is as follows: Receive raw data frames transmitted through an established communication link; check the start and end flags of the raw data frames; If the start flag and the end flag are respectively a predefined first specific value and a second specific value, then the communication data is determined to be a fault injection instruction.

3. The design method for fault testing of rail transit signaling systems according to claim 1, characterized in that: If the instruction is a fault injection command, the steps for parsing the fault injection command to obtain the fault injection rule are as follows: The communication data identified as fault injection instructions is parsed to extract its internal structured field information; The target link identifier, fault type identifier, and target packet matching conditions in the fault injection rule are determined and recorded based on the structured field information. The fault injection rules, which record the target link identifier, fault type identifier, and target message matching conditions, are stored.

4. A design method for fault testing of rail transit signaling systems according to claim 1 or 3, characterized in that: The process of parsing the fault injection instruction also includes: Determine whether the fault injection command contains a clear command identifier; If included, clear all stored fault injection rules and related fault injection states.

5. The design method for fault testing of rail transit signaling systems according to claim 3, characterized in that: The structured field information includes at least: a link field for indicating the communication link in which the fault is effective, a type field for specifying any one of the fault types, such as error, insertion, out-of-order, deletion, duplication, or delay, a matching condition field for defining message matching conditions, and a parameter field containing parameters such as offset, length, content, or delay time to be modified.

6. The design method for fault testing of rail transit signaling systems according to claim 1, characterized in that: During the periodic packet processing process, the steps for real-time filtering and matching of flowing packets based on the target link identifier and target packet matching conditions in the fault injection rules are as follows: Determine whether the fault injection targets all communication links based on the target link identifier; If not, then in the packet stream of the specific link indicated by the target link identifier, determine whether the packet type and the byte content at the specified offset position match according to the target packet matching conditions; If so, then in the message stream of all communication links, determine whether the message type and the byte content at the specified offset position match according to the target message matching conditions.

7. The design method for fault testing of rail transit signaling systems according to claim 1, characterized in that: The steps for performing the corresponding fault injection operation on the successfully matched message according to the target fault type indicated by the fault type identifier are as follows: Obtain the target fault type and corresponding operation parameters according to the stored fault injection rules; based on the target fault type, select and perform one of the following operations: When the target fault type is a code error fault, modify the byte content at the specified offset position in the successfully matched message according to the operation parameters, and selectively recalculate or directly modify the message checksum according to the rules. When the target fault type is an insertion fault, the matched message is copied, the target address corresponding to the message is modified to an invalid address, and then sent to the buffer. When the target fault type is an out-of-order fault, the sequence number field in the successfully matched message is adjusted according to the operation parameters. When the target fault type is a deletion fault, the successfully matched message is discarded. When the target fault type is a duplicate fault, the successfully matched message is copied or its sequence number is modified to create a duplicate transmission effect. When the target fault type is a delay fault, modify the timestamp field inside the successfully matched message, or start a timer to delay its actual transmission time.

8. A design system for fault testing of rail transit signaling systems, applicable to the design method for fault testing of rail transit signaling systems as described in any one of claims 1 to 7, characterized in that: include: The communication interface module is used to establish and maintain a communication link with external testing tools and to receive communication data transmitted through the communication link. A communication instruction identification module, connected to the communication interface module, is used to determine whether the received communication data is a fault injection instruction; The rule parsing and storage module is connected to the instruction recognition module and is used to parse the communication data to extract the fault injection rules and store them when the communication data is determined to be a fault injection instruction. A normal communication processing module, connected to the instruction recognition module, is used to process the communication data according to the standard communication processing procedure when the communication data is determined not to be a fault injection instruction. The message matching engine, connected to the rule parsing and storage module, is used to perform real-time filtering and matching of the flowing messages according to the stored fault injection rules during the periodic message processing process. The fault injection module is connected to the message matching engine and the rule parsing and storage module, and is used to perform the corresponding fault injection operation on the successfully matched message according to the rules. The message sending module is connected to the normal communication processing module and the fault injection execution module, respectively. It is used to receive and buffer the processed messages, and periodically send them to the corresponding communication objects through the sending thread.

9. An electronic device, characterized in that: It includes a memory and a processor, wherein the memory stores a computer program, and the processor, when calling the computer program in the memory, implements the steps of a design method for fault testing of a rail transit signaling system as described in any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium stores computer-executable instructions, which, when loaded and executed by a processor, implement the steps of a design method for fault testing of a rail transit signaling system as described in any one of claims 1 to 7.

Images