Test simulation system, method and equipment for TSRS (Temporary Speed Rate Server) and medium

Abstract

The invention discloses a test simulation system, method and device for a temporary speed limit server (TSRS) and a medium, and the system comprises a configuration message processing module which carries out the analysis and packaging of a message interacting with a tested temporary speed limit server based on a configuration file; the subpackage message CRC management module is used for identifying subpackage messages in the same group, merging data fields of the subpackage messages and calculating a unified whole message level CRC value; the hierarchical verification collaboration module is used for calculating the subpackage data level CRC and the whole message level CRC, and intelligently selecting to adopt a real-time calculation value or a preset value according to the setting of the CRC fault injection module when the whole message CRC is calculated; and the CRC fault injection module is used for respectively setting a subpackage data level CRC and a whole message level CRC to be in an automatic or manual mode through an independent control interface. Compared with the prior art, the method has the advantages that efficient, reliable and manageable automatic testing in a complex data interaction scene between temporary speed-limiting servers is realized through configuration message processing and a multi-level CRC (cyclic redundancy check) intelligent cooperation framework.

Description

Technical Field

[0001] This invention relates to the field of railway signaling system testing, and in particular to a test simulation system, method, equipment, and medium for a Temporary Speed ​​Limiting Server (TSRS). Background Technology

[0002] Temporary Rate Limiting Servers (TSRS) are critical safety devices in the CTCS train control system. Adjacent Rate Limiting Servers refer to two TSRSs that communicate with each other; the other is considered an adjacent Rate Limiting Server. As a SIL4 level safety device, TSRSs require rigorous indoor simulation testing before being deployed in the field. In indoor simulation testing, the simulated adjacent Rate Limiting Server is a dedicated software system. Its core task is to simulate a real adjacent TSRS in the test environment, establish communication with the TSRS under test, exchange data according to the protocol, and implement various normal or pre-designed abnormal test cases to verify whether the functionality, performance, and security mechanisms of the TSRS under test meet the requirements.

[0003] With the development of high-speed railway technology, the data exchanged between adjacent speed limit servers has become increasingly complex. It has evolved from exchanging simple data such as speed limit commands in the past to exchanging various complex data such as gradient curves, static speed curves, station distance curves, and temporary speed limit curves. These complex data have characteristics such as deeply nested field structures, dynamic arrays, and packet transmission, and require multi-level CRC checks to ensure data integrity.

[0004] Existing simulated adjacency rate limiting servers are mainly designed for simple rate limiting command interactions, and they have the following technical problems when dealing with complex data testing: 1. Message format scalability issues: The message format is fixed in the code and cannot flexibly adapt to new and complex data formats. Every time a new message type is added, the code needs to be modified and recompiled, resulting in poor system scalability and high maintenance costs.

[0005] 2. Issues with the accuracy of CRC calculation for packetized messages: Complex data requires packetized transmission, and existing systems lack a CRC management mechanism for packetized messages. Current technologies face the following technical challenges in CRC calculation for packetized messages: They cannot automatically identify packets scattered throughout the configuration; they struggle to correctly handle the existing packet-level CRC values ​​when calculating the entire message-level CRC; and they cannot accurately merge fields from multiple packets and exclude control information, leading to unreliable cross-packet CRC verification results.

[0006] 3. Multi-level CRC collaborative management problem: Complex data requires multi-level CRC verification. Existing systems lack a collaborative management mechanism for multi-level CRC, and cannot independently control CRC calculation and fault injection at different levels. In existing technologies, multi-level CRC calculation faces the following technical challenges: (1) Handling the dependency relationship between packet data level CRC and whole message level CRC: The calculation of whole message level CRC depends on the packet data level CRC of each packet, but the existing technology cannot distinguish between the automatically calculated packet data level CRC and the CRC value manually filled in by the user, resulting in inaccurate whole message level CRC calculation. (2) Independent fault injection of multi-level CRC: When testing the ability of TSRS equipment to handle CRC errors at different levels, it is necessary to be able to independently control the calculation mode of packet data level CRC and whole message level CRC (automatic calculation or manual filling), but the existing technology cannot achieve this independent control; (3) Multi-level CRC coordination in packet transmission scenario: In the packet transmission scenario, the whole message level CRC needs to be calculated across packets, but the packet data level CRC of each packet may have been calculated or filled in by the user. How to correctly handle the packet data level CRC of each packet when calculating the whole message level CRC is a technical challenge.

[0007] 4. Insufficient testing capabilities: The existing system lacks a flexible fault injection mechanism, making it impossible to effectively test the TSRS device's ability to handle CRC check errors.

[0008] A search revealed Chinese Patent Publication No. CN112099478A, which discloses an automatic testing method and apparatus for temporary speed limit messages from a train control center. This method automatically generates test cases using engineering data tables and sends test data to the train control center using simulators such as computer interlocking simulation and temporary speed limit server simulation. It then obtains the messages returned by the train control center and compares them with the expected results for consistency, thereby automating the testing process. However, this method primarily focuses on automating the testing process and managing the generation of test cases, without addressing the simulation processing of complex data exchanged between temporary speed limit servers, such as nested fields and dynamic arrays.

[0009] Therefore, how to achieve efficient, reliable, and controllable automated testing in complex, packet-splitting, and multi-level verification data interaction scenarios between temporary rate-limiting servers is a technical problem that needs to be solved. Summary of the Invention

[0010] The purpose of this invention is to overcome the defects of the prior art by providing a test simulation system, method, device and medium for Temporary Rate Limiting Server (TSRS).

[0011] The objective of this invention can be achieved through the following technical solutions: According to a first aspect of the present invention, a test simulation system for a Temporary Rate Limiting Server (TSRS) is provided, which is communicatively connected to a real temporary rate limiting server under test. The test simulation system includes: The configurable message processing module parses and encapsulates messages exchanged with the temporary rate-limiting server under test, based on a predefined configuration file. The packet message CRC management module is used to identify multiple packet messages belonging to the same message group, merge the data fields in the multiple packet messages, and generate a cross-packet whole message level CRC value for verification based on the merged data. The hierarchical verification collaboration module is used to calculate the packet-level CRC for independent data blocks in the message, and to calculate the whole message-level CRC based on the merged data fields, so as to provide a multi-level verification benchmark. The CRC fault injection module is used to independently control the calculation mode of the packet data-level CRC or the whole message-level CRC, so as to inject controllable CRC check errors into the tested temporary rate-limiting server. When calculating the whole message-level CRC, the hierarchical verification collaboration module decides whether to use the real-time calculated packet-level CRC value or the preset packet-level CRC value, based on the current control mode of the CRC fault injection module for the packet-level CRC.

[0012] As a preferred technical solution, the configurable message processing module includes: The configuration management submodule is used to load and manage configuration files containing message type, field definition, data format and field length information. The configuration file defines a temporary rate-limiting server message format containing nested fields and dynamic arrays. The message formatting submodule converts the structured data input by the user into a byte stream according to the configuration file; The message parsing submodule parses the received byte stream into structured data according to the configuration file.

[0013] As a preferred technical solution, the packet message CRC management module includes: The packet identification submodule uses a bidirectional traversal algorithm to automatically identify and collect all packet messages belonging to the same group from the configuration list based on the total number of packets and the packet location information in the message. The field merging submodule is used to merge the fields of all sub-packet messages collected in the same group in order of packet number, and exclude the control fields used for grouping; The unified CRC calculation submodule is used to calculate the CRC value of the merged fields in a unified manner, so as to obtain the whole message-level CRC value across sub-packets.

[0014] As a preferred technical solution, the bidirectional traversal algorithm includes: starting from the currently processed message, traversing the message list forward and backward simultaneously, collecting packets in the same group by matching message type and consecutive packet sequence numbers, and stopping traversal when the conditions do not match.

[0015] As a preferred technical solution, the hierarchical verification collaboration module includes: The sub-module for calculating the CRC value of a data block at the data level is used to traverse the fields of the data block and exclude the CRC field itself before calculating the CRC value of the data block. The whole-message-level CRC calculation submodule is used to perform packet identification and collection when calculating the whole-message-level CRC. According to the current control mode of the CRC fault injection module for the packet data-level CRC, it intelligently determines the value method of each packet data-level CRC: if it is the automatic calculation mode, it recalculates the packet data-level CRC of each packet; if it is the manual filling mode, it uses the preset CRC value in the message field of each packet; then, it merges the fields and calculates the whole-message-level CRC. The CRC status management submodule is used to manage multiple CRC values ​​in a message in a unified manner, and provides update, query and reset functions.

[0016] As a preferred technical solution, the CRC fault injection module provides independent user interface controls for switching between the calculation modes of packet-level CRC and whole-message-level CRC; wherein, the manual filling mode allows users to directly input the desired CRC value for message packet assembly.

[0017] As a preferred technical solution, the system further includes a hybrid message parsing module, which selects to parse the received message using a predefined fixed format or a dynamic format based on the configuration file, depending on the message type.

[0018] According to a second aspect of the present invention, a test simulation method based on the system is provided, comprising: Load the message structure configuration file and receive test instructions, which include message content and configuration for CRC calculation mode; The message content is processed according to the configuration file. If it is a packetized message, the packet management steps are executed, and multi-level CRC coordination and fault injection logic is executed according to the configuration of the CRC calculation mode to generate a message to be sent. Send the message to be sent to the temporary speed limit server under test; Receive and parse the response message from the temporary rate-limiting server under test, and determine the test result based on the response content.

[0019] As a preferred technical solution, the subcontracting management steps include: A bidirectional traversal algorithm is used to identify all packets in the same group from the test sequence based on the group control field in the message; Merge the valid data fields of each subpackage and remove the group control fields; Calculate the whole message-level CRC for the merged complete data.

[0020] As a preferred technical solution, the step of executing multi-level CRC coordination and fault injection logic according to the configuration of the CRC calculation mode specifically includes: If the sub-packet data level CRC is configured to be automatically calculated, then the correct CRC value will be calculated for each data block; if it is configured to be manually filled, then the preset CRC value will be used. When calculating the whole message-level CRC, if it is configured to be automatically calculated, the value is obtained according to the configuration mode of the packet data-level CRC: when the packet data-level CRC is in automatic calculation mode, the real-time calculated packet data-level CRC value is used; when the packet data-level CRC is in manual filling mode, the preset packet data-level CRC value is used; and then the correct whole message-level CRC value is calculated based on the obtained value.

[0021] According to a third aspect of the present invention, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the program to implement the method described thereon.

[0022] According to a fourth aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method described thereon.

[0023] Compared with the prior art, the present invention has the following advantages: 1. This invention achieves efficient, reliable, and controllable automated testing in complex data interaction scenarios between temporary rate-limiting servers through the collaborative design of a configurable message processing module, a packet message CRC management module, a hierarchical verification collaboration module, and a CRC fault injection module. Among them, configurable processing enables dynamic expansion of message formats, packet message CRC management ensures the accuracy of cross-packet verification, and multi-level CRC collaboration and an independent and controllable fault injection mechanism jointly guarantee the depth and credibility of the test.

[0024] 2. This invention adopts a configuration file-based message processing architecture, which decouples message format definitions from core code. When adding or modifying message types, only the configuration file needs to be updated without recompiling the program, which improves the scalability and maintainability of the system and reduces the cost of long-term iteration.

[0025] 3. This invention uses a bidirectional traversal algorithm to intelligently identify scattered packets within the same group, and ensures the absolute accuracy of the overall cross-packet verification value by performing unified CRC calculation on the combined data. This solves the problem of inaccurate CRC calculation at the whole message level in packet scenarios, and ensures the effectiveness and reliability of the test.

[0026] 4. This invention provides independent control over both packet-level CRC and whole-message-level CRC through a CRC fault injection module, allowing testers to accurately simulate single or compound CRC check error scenarios. This flexible fault injection mechanism can effectively verify the security protection and error handling capabilities of TSRS devices under various abnormal conditions. Attached Figure Description

[0027] Figure 1 This is a system architecture diagram of the present invention; Figure 2 This is a flowchart of the configurable message processing of the present invention; Figure 3 This is a flowchart of the CRC management process for sub-packet messages in this invention; Figure 4 This is a flowchart of the multi-level CRC collaborative calculation process of the present invention; Figure 5 This is a flowchart of the method of the present invention; Detailed Implementation

[0028] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0029] Example 1: This embodiment provides a test simulation system for Temporary Rate Limiting Servers (TSRS). For example... Figure 1 As shown, the system adopts a layered architecture, including a user interface layer, a business logic layer, a data layer, and a communication layer. Its core lies in the business logic layer, which consists of the following modules: Configurable message processing module 1: This module forms the foundation for the entire system's flexible message format adaptation. Based on a JSON configuration file, it dynamically defines and processes complex message formats interacting with TSRS, enabling bidirectional conversion between structured data and network byte streams. Its processing flow is as follows: Figure 2 As shown.

[0030] The key attributes of the configuration file include: byte_order: Defines the byte order (big_endian or little_endian); messages: This is an array containing the definitions of multiple messages. Each message definition includes a display_name and fields field. fields: Defines a list of fields for the message. Each field contains attributes such as name (field name), value_format (data format), and length (length). Nested fields: By defining a field array within fields, arbitrary depth of field nesting is supported; Dynamic arrays: A field name is specified through the count_by attribute. The value of this field determines the length of the current array field. For example, the length of the data_items array is dynamically determined by the value of the data_items_count field. Multiple data formats: hex (hexadecimal), decimal (decimal), binary (binary), str (string); Byte order configuration: Defined via the byte_order field.

[0031] The configurable message processing module specifically includes: Configuration Management Submodule: Responsible for loading, parsing and managing the above JSON configuration file. When a new message type is added, only the corresponding definition needs to be added to the configuration file. This module can be dynamically loaded without restarting the system or modifying the code. The message formatting submodule: When a message needs to be sent, it recursively traverses the structured data input by the user according to the configuration, converting it into a precise byte stream according to the field definitions. For example, it converts the field {"name": "message_type", "value": "0x1303", "value_format": "hex", "length": 2} into the byte sequence [0x13, 0x03]; Message parsing submodule: When a byte stream is received, this submodule first identifies the message type, looks up the corresponding configuration, and then recursively parses the byte stream into visualized structured data according to the order and structure defined in the configuration, for users to view and analyze.

[0032] Sub-packet message CRC management module 2: This module is specifically designed to handle complex messages such as 0x1303 that require packet transmission, ensuring the accuracy of CRC calculations across packet messages. The core workflow is as follows: Figure 3 As shown, it includes: The packet identification submodule employs a bidirectional traversal algorithm, with the following specific steps: Read positioning information: Read total_packages (total number of packages) and package_position (current package number) from the currently processed message; Forward packet collection: Set the expected position expected_pos = package_position – 1; Iterate from the current message position towards the beginning of the list; For each message encountered, check if its message_type is 0x1303 and if its package_position is equal to expected_pos; If a match is found, the message is added to the same group list, expected_pos is decremented by 1, and the process continues to traverse forward. If the types do not match or the ordinal numbers are not consecutive, stop traversing in this direction immediately. Collect packages backward: Set the expected position expected_pos = package_position + 1; Iterate from the current message position towards the end of the list; The matching logic is the same as the forward collection; if a match is successful, expected_pos is incremented by 1 and the process continues. Stop immediately if a mismatch is encountered; The result returned is a complete list of packets collected forward and backward, arranged in the order of package_position.

[0033] Field merging submodule: The identified packages in the same group are arranged in order of package_position. The module recursively collects all valid data fields in each package except for control fields (such as message_type, device_id, total_packages, package_position, general_data_file_crc, etc.) and merges them into a complete data block. Unified CRC Calculation Submodule: For the complete data block output by the field merging submodule, call the CRC calculation function (such as calcu_revrse_crc32, polynomial 0x8151b04b, initial value 0xFFFFFFFF) to calculate a unified CRC value once. This value is the whole message-level CRC across all packets.

[0034] Hierarchical verification collaboration module 3: This module is responsible for managing the calculation and coordination of packet-level CRC and whole-message-level CRC. The core workflow is as follows: Figure 4 As shown, it includes: The packet-level CRC calculation submodule is responsible for calculating the CRC value of a specific data block (such as line_data) within a message. During calculation, it iterates through all fields of the data block, excluding the CRC field itself, and calculates the CRC after generating the data block byte stream. The whole-message-level CRC calculation submodule is responsible for calculating the CRC of the entire data file. Its calculation process relies on the packet message CRC management module: first, it identifies and merges packets; then, before calculation, it performs a key decision: checking the current calculation mode of the packet data-level CRC (set by the CRC fault injection module). If it is in automatic calculation mode, it triggers a recalculation of the packet data-level CRC for each packet to ensure the whole-message-level CRC is based on the correct underlying values; if it is in manual input mode, it directly uses existing field values ​​(which may be intentionally entered incorrect values ​​by the user for testing purposes). Finally, it calculates the whole-message-level CRC for the merged complete data. CRC Status Management Submodule: For messages containing multiple CRC fields (such as 0x1304), this submodule maintains a CRC value dictionary, which includes: ato_slope_curve_crc (ATO slope curve CRC) ato_static_speed_curve_crc (ATO static speed curve CRC) ato_station_distance_crc (ATO inter-station distance CRC) ato_temp_speed_crc (ATO temporary speed limit CRC) general_data_file_crc (General Data File CRC); This submodule provides methods such as update_crc(), get_crc(), get_all_crc_values(), and reset_all() to achieve unified updating, querying, and resetting of multiple CRC values.

[0035] CRC Fault Injection Module 4: This module is used to simulate CRC check errors, and it includes: Automatic / Manual Switching Submodule: Provides independent checkboxes on the user interface (such as "Automatically calculate CRC of data 1-4" and "Automatically calculate CRC of general data file"), allowing testers to control the calculation modes of packet-level CRC and whole-message-level CRC respectively; Multi-level CRC independent control submodule: Implements the above control logic to ensure that the mode settings of data-level and whole-message-level CRC are completely independent and do not interfere with each other; Fault Injection Strategy Submodule: Passes the user-defined mode to the hierarchical verification and coordination module, guiding it to make the correct decision when calculating the whole message-level CRC, thereby achieving accurate fault injection.

[0036] Hybrid Message Parsing Module 5: To ensure compatibility with both new and old protocols, this module selects a parsing strategy based on the message type, which includes: Message type identification submodule: Parses the message header and extracts the message type field; Traditional format parsing submodule: For old messages with fixed and simple formats (such as 0x0306), it uses predefined struct format strings for efficient parsing; Configurable Format Parsing Submodule: For complex new messages (such as 0x1303), it calls the parsing submodule of the configurable message processing module for dynamic parsing.

[0037] User interface module: Provides a graphical user interface, including: Main interface submodule: Provides the main test view, manages TSR requests and responses, and displays communication status, etc. The message editing interface submodule provides a dedicated editor for complex messages (such as 0x1303), which visualizes nested fields in a tree structure to facilitate data editing and integrates the aforementioned CRC control checkboxes. Cross-frame communication submodule: Enables data synchronization and communication between the main interface and the message editing interface through mechanisms such as message queues.

[0038] This invention system solves the problems of rigid message format, inaccurate packet verification, difficulty in multi-level collaboration, and insufficient testing capabilities in existing testing technologies through four core modules: configurable message processing, packet message CRC management, multi-level CRC collaborative calculation, and CRC fault injection. It achieves efficient, accurate, and comprehensive automated testing of TSRS devices in complex data interaction scenarios.

[0039] Example 2: like Figure 5 As shown, this embodiment provides a test simulation method for running on the above system, mainly including: Step S1: Configurable Message Processing When the system starts, it loads a predefined JSON message configuration file, which defines nested fields and dynamic array structures for messages such as 0x1303. When sending: After the user fills in the message content through the tree-shaped editing interface, the system recursively converts all field values ​​into byte streams according to the corresponding message's JSON configuration. For example, message_type: "0x1303" is converted into 2 bytes [0x13, 0x03]. Upon receiving the byte stream: after identifying the type based on the message header, find the corresponding JSON configuration, and recursively parse out the structured data display.

[0040] Step S2: CRC Management of Packet Messages Starting with the current message, read its total_packages and package_position fields; The bidirectional traversal algorithm searches forward and backward in the message list to be processed and collects all packets in the same group (with the same message_type and consecutive package_position). Merge all valid data fields of packages in the same group, excluding control fields such as message_type and package_position in the process; A one-time CRC calculation is performed on the merged complete data block to obtain an accurate initial CRC value at the whole message level.

[0041] Step S3: Multi-level CRC collaborative calculation Calculate the CRC at the packet data level: Traverse all subfields of the target data block, excluding data_crc itself, generate a byte stream and calculate the CRC, and fill the result into the data_crc field; Calculate the CRC at the whole message level: First, execute step S2 to complete packet identification and merging; Key decision point: Check the switch status of "Sub-package data level CRC calculation mode"; If in automatic mode, the packet data-level CRC of each packet collected in S2 is recalculated and updated; If in manual mode, the existing sub-packet data-level CRC values ​​(which may be erroneous) in each sub-packet will be retained. Finally, based on the data after the above decision, the final whole message-level CRC is calculated; For messages with multiple CRC fields, the updating and retrieval of each CRC value are managed within a unified logical unit.

[0042] Step S4: CRC Fault Injection Users can independently set the on / off switch for packet-level CRC and whole-message-level CRC through the interface. For example, they can turn off automatic calculation of packet-level CRC and turn on automatic calculation of whole-message-level CRC.

[0043] When a certain level of CRC switch is turned on, the system automatically calls the CRC calculation function in the corresponding step to generate the correct value and fill it in; When a certain level of CRC switch is turned off, the system skips automatic calculation and directly uses the value that the user has pre-filled in the corresponding field (which can be intentionally entered incorrectly). By combining different switch states, test scenarios can be precisely constructed, such as: CRC error at the packet data level only; CRC error at the whole message level only; and both errors, to comprehensively test the CRC check fault tolerance capability of TSRS. Test Scenario 1: Packet-level CRC error, whole-message-level CRC correct. Operation: Set the calculation mode of the packet data level CRC to manual and manually configure the error check value (e.g., 0x12345678) in the data_crc field; at the same time, set the calculation mode of the whole message level CRC to automatic calculation. System behavior: When assembling packets, the system will adopt the CRC value of manually entered incorrect packet data; at the same time, it will automatically call the internal algorithm to calculate and enter the correct whole message CRC value. Test objective: To verify the specific detection capability of the TSRS device under test for CRC check errors at the packet data level, and whether it can return corresponding error indications (such as 0x0307 error receipt) according to the protocol specifications.

[0044] Test Scenario 2: Packet-level CRC is correct, but the entire message-level CRC is incorrect. Operation: Set the calculation mode of the packet data level CRC to automatic calculation; at the same time, set the calculation mode of the whole message level CRC to manual filling, and manually configure the error check value in the general_data_file_crc field; System behavior: The system automatically calculates and fills in the correct CRC value at the packet data level; at the same time, it adopts the manually entered incorrect CRC value at the whole message level. Test objective: To verify the ability of the tested TSRS device to detect and handle CRC check errors at the whole message level, and to examine the effectiveness of its global data integrity verification mechanism.

[0045] Test Scenario 3: Both data-level and whole-message-level CRC errors Operation: Set the calculation mode of both packet data-level CRC and whole message-level CRC to manual, and manually configure the error check value in the data_crc and general_data_file_crc fields respectively; System behavior: The system will fully adopt the two-level error CRC values ​​manually configured by the user for message packet assembly and transmission; Test objective: To verify the comprehensive fault handling and security response mechanism of the TSRS device under test when faced with multi-level and composite CRC check errors.

[0046] Step S5: Message sending, receiving and verification The processed message byte stream is framed according to a communication protocol (such as RSSP) and sent to the TSRS device under test. The system receives responses from TSRS, and the hybrid message parsing module selects between traditional parsing and configurable parsing based on the message type. Analyze the message content of the TSRS response (such as whether an error receipt 0x0307 is returned), determine whether the behavior of the device under test under specific fault injection is as expected, and record the test results.

[0047] The method of this invention formats and parses test messages through a predefined configuration file; it uses a bidirectional traversal algorithm to identify and merge valid data packets in the same group, and calculates an accurate whole-message-level CRC accordingly; based on an independently set fault injection mode, when performing whole-message-level CRC calculation, it intelligently decides whether to use the real-time calculated packet data-level CRC value or the preset value, thereby achieving controllable verification error injection; finally, it completes message encapsulation, sending, receiving and verification, thereby comprehensively testing the data processing and security fault tolerance capabilities of the TSRS device.

[0048] Example 3: The electronic device of this invention includes a central processing unit (CPU), which can perform various appropriate actions and processes according to computer program instructions stored in read-only memory (ROM) or loaded from a storage unit into random access memory (RAM). The RAM may also store various programs and data required for device operation. The CPU, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0049] Multiple components in the device are connected to the I / O interface, including: input units such as keyboards and mice; output units such as various types of displays and speakers; storage units such as disks and optical discs; and communication units such as network interface cards (NICs), modems, and wireless transceivers. The communication unit allows the device to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0050] The processing unit executes the various methods and processes described above, such as methods S1 to S5. For example, in some embodiments, methods S1 to S5 may be implemented as computer software programs tangibly contained in a machine-readable medium, such as a storage unit. In some embodiments, part or all of the computer program may be loaded and / or installed on the device via ROM and / or a communication unit. When the computer program is loaded into RAM and executed by the CPU, one or more steps of methods S1 to S5 described above may be performed. Alternatively, in other embodiments, the CPU may be configured to execute methods S1 to S5 by any other suitable means (e.g., by means of firmware).

[0051] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0052] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0053] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0054] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A test simulation system for a Temporary Rate Limiting Server (TSRS), communicating with a real temporary rate limiting server under test, characterized in that, The test simulation system includes: The configurable message processing module parses and encapsulates messages exchanged with the temporary rate-limiting server under test, based on a predefined configuration file. The packet message CRC management module is used to identify multiple packet messages belonging to the same message group, merge the data fields in the multiple packet messages, and generate a cross-packet whole message level CRC value for verification based on the merged data. The hierarchical verification collaboration module is used to calculate the packet-level CRC for independent data blocks in the message, and to calculate the whole message-level CRC based on the merged data fields, so as to provide a multi-level verification benchmark. The CRC fault injection module is used to independently control the calculation mode of the packet data-level CRC or the whole message-level CRC, so as to inject controllable CRC check errors into the tested temporary rate-limiting server. When calculating the whole message-level CRC, the hierarchical verification collaboration module decides whether to use the real-time calculated packet-level CRC value or the preset packet-level CRC value, based on the current control mode of the CRC fault injection module for the packet-level CRC.

2. The test simulation system for a Temporary Rate Limiting Server (TSRS) according to claim 1, characterized in that, The configurable message processing module includes: The configuration management submodule is used to load and manage configuration files containing message type, field definition, data format and field length information. The configuration file defines a temporary rate-limiting server message format containing nested fields and dynamic arrays. The message formatting submodule converts the structured data input by the user into a byte stream according to the configuration file; The message parsing submodule parses the received byte stream into structured data according to the configuration file.

3. The test simulation system for a Temporary Rate Limiting Server (TSRS) according to claim 1, characterized in that, The sub-packet message CRC management module includes: The packet identification submodule uses a bidirectional traversal algorithm to automatically identify and collect all packet messages belonging to the same group from the configuration list based on the total number of packets and the packet location information in the message. The field merging submodule is used to merge the fields of all sub-packet messages collected in the same group in order of packet number, and exclude the control fields used for grouping; The unified CRC calculation submodule is used to calculate the CRC value of the merged fields in a unified manner, so as to obtain the whole message-level CRC value across sub-packets.

4. The test simulation system for a Temporary Rate Limiting Server (TSRS) according to claim 3, characterized in that, The bidirectional traversal algorithm includes: starting from the currently processed message, traversing the message list forward and backward simultaneously, collecting packets in the same group by matching message type and consecutive packet sequence numbers, and stopping traversal when the conditions do not match.

5. A test simulation system for a Temporary Rate Limiting Server (TSRS) according to claim 1, characterized in that, The hierarchical verification collaboration module includes: The sub-module for calculating the CRC value of a data block at the data level is used to traverse the fields of the data block and exclude the CRC field itself before calculating the CRC value of the data block. The whole-message-level CRC calculation submodule is used to perform packet identification and collection when calculating the whole-message-level CRC. According to the current control mode of the CRC fault injection module for the packet data-level CRC, it intelligently determines the value method of each packet data-level CRC: if it is the automatic calculation mode, it recalculates the packet data-level CRC of each packet; if it is the manual filling mode, it uses the preset CRC value in the message field of each packet; then, it merges the fields and calculates the whole-message-level CRC. The CRC status management submodule is used to manage multiple CRC values ​​in a message in a unified manner, and provides update, query and reset functions.

6. A test simulation system for a Temporary Rate Limiting Server (TSRS) according to claim 1, characterized in that, The CRC fault injection module provides independent user interface controls for switching between the calculation modes of packet-level CRC and whole-message-level CRC; among them, the manual filling mode allows users to directly input the desired CRC value for message packet assembly.

7. A test simulation system for a Temporary Rate Limiting Server (TSRS) according to claim 1, characterized in that, The system also includes a hybrid message parsing module, which selects to call the configurable message processing module or a preset fixed-format parser to parse the message based on the message type of the received message.

8. A test simulation method based on the system described in any one of claims 1-7, characterized in that, include: Load the message structure configuration file and receive test instructions, which include message content and configuration for CRC calculation mode; The message content is processed according to the configuration file. If it is a packetized message, the packet management steps are executed, and multi-level CRC coordination and fault injection logic is executed according to the configuration of the CRC calculation mode to generate a message to be sent. Send the message to be sent to the temporary speed limit server under test; Receive and parse the response message from the temporary rate-limiting server under test, and determine the test result based on the response content.

9. The test simulation method according to claim 8, characterized in that, The subcontracting management steps include: A bidirectional traversal algorithm is used to identify all packets in the same group from the test sequence based on the group control field in the message; Merge the valid data fields of each subpackage and remove the group control fields; Calculate the whole message-level CRC for the merged complete data.

10. The test simulation method according to claim 8, characterized in that, The execution of multi-level CRC coordination and fault injection logic based on the CRC calculation mode configuration specifically includes: If the sub-packet data level CRC is configured to be automatically calculated, then the correct CRC value will be calculated for each data block; if it is configured to be manually filled, then the preset CRC value will be used. When calculating the whole message-level CRC, if it is configured to be automatically calculated, the value is obtained according to the configuration mode of the packet data-level CRC: when the packet data-level CRC is in automatic calculation mode, the real-time calculated packet data-level CRC value is used; when the packet data-level CRC is in manual filling mode, the preset packet data-level CRC value is used; and then the correct whole message-level CRC value is calculated based on the obtained value.

11. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 8 to 10.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 8 to 10.

Images