RBC data version management, line acquisition and message verification method

Abstract

A version management, line acquisition and message verification method for RBC data is characterized in that the RBC data is organized into a multi-layer tree structure to be managed in a database according to service dimensions, the multi-layer tree structure sequentially comprises a line layer, a data version layer and an RBC device layer from top to bottom, each layer in the multi-layer tree structure has a respective attribute identifier, and the line layer and the data version layer are connected with each other. Wherein each hierarchy is uniquely determined through a respective management identifier, and the management identifier of each hierarchy comprises attribute identifiers of all upper hierarchies and an attribute identifier of the hierarchy; wherein when the version of the data of the target hierarchy needs to be updated, all the existing data of the target hierarchy stored in the database are matched and deleted based on the management identifier corresponding to the target hierarchy; after the deletion operation is completed, inserting updated data of the target hierarchy into the database; wherein the deletion operation and the insertion operation are packaged in the same database transaction, so that the atomicity of the version updating operation is ensured, and the reliability and efficiency of data management are improved.

Description

Technical Field

[0001] This article relates to rail transit technology, specifically a method for version management, route acquisition, and message verification of RBC data. Background Technology

[0002] In railway signaling systems, the Radio Block Center (RBC), as a key train control device, relies on a series of fundamental data with complex interrelationships for its operation and testing. This data typically exhibits multi-level and multi-version characteristics, making it challenging to manage.

[0003] Existing technologies rely on complex version association tables to record and maintain the relationships between data items. While this approach attempts to preserve historical data relationships, frequent version iterations and an increase in data levels lead to a sharp rise in database storage costs. More importantly, these complex relationships are highly susceptible to becoming chaotic, inconsistent, or broken during continuous updates and maintenance, making it difficult to guarantee data integrity and reliability.

[0004] The second approach is to perform a full overwrite of the target data during version updates. While this method is simple, it completely destroys the historical state of the data, making it impossible to trace and reproduce any historical versions. Furthermore, this crude update method is highly susceptible to cross-level data inconsistencies or conflicts within complex, multi-layered data contexts, posing a potential risk to the stable operation of the entire system.

[0005] Therefore, how to manage RBC data versions is a technical problem that urgently needs to be solved. Summary of the Invention

[0006] This application provides a method for RBC data version management, line acquisition, and message verification.

[0007] A method for version management of RBC data, wherein the RBC data is organized in a multi-level tree structure in a database according to business dimensions for management. The multi-level tree structure, from top to bottom, includes a line layer for marking each railway line, a data version layer for marking different versions of RBC data within that railway line, and an RBC device layer for marking each RBC device under each version of RBC data. Each level in the multi-level tree structure has its own attribute identifier, and each level is uniquely identified by its own management identifier. The management identifier of each level includes the attribute identifiers of all its parent levels and the attribute identifier of the current level. The method includes: When it is necessary to update the data at the target level, based on the management identifier corresponding to the target level, match and delete all existing data of the target level stored in the database. After the deletion operation is completed, the updated data of the target level is inserted into the database; The deletion and insertion operations are encapsulated within the same database transaction to ensure the atomicity of the version update operation.

[0008] A method for obtaining a driving permit route includes: Starting with the designated initial transponder as the calculation starting point, and based on the line data maintained by the method described above, the forward extension step and the backtracking replacement step are executed iteratively until all stations reachable from the initial transponder have been traversed; wherein: The forward extension step is as follows: starting from the starting point along the direction of travel, extend the path forward according to the route data. When the extension reaches the station, filter all legal receiving routes according to the station port information, and match the corresponding departure route for each receiving route before continuing to extend until the extension distance reaches the distance threshold of the current route, thereby generating a permitted route for travel. The backtracking and replacement step is as follows: backtrack from the current route endpoint to the route selection node of the nearest station, replace it with a valid receiving route that has not been traversed, and match it with the corresponding departure route. Output all permitted routes generated during the output loop.

[0009] An RBC message verification method, comprising: Obtain the actual test messages and the expected messages preset by the test cases collected under the test scenario corresponding to the driving permit route, wherein the driving permit route is generated by the method described above; The actual test message and the expected message are compared at the field level to identify the difference fields. The difference fields are then associated with the test intent of the test case that generated the expected message to obtain the association result. The test intent describes what function, logic, or behavior of the RBC system is to be tested by executing the test case. Based on a preset difference classification rule base, the difference fields in the association results are classified. The difference classification rule base predefines at least one of the following categories: key functional field differences, non-core configuration field differences, and format compliance differences. Among them, key functional fields are fields that directly affect driving safety and control logic; non-core configuration fields are fields that do not affect safety logic. Based on the classification results of the difference fields, obtain and output product problem investigation direction information that matches the classification results and is determined by the test intent.

[0010] A storage medium storing a computer program, wherein the computer program is configured to execute the method described above when run.

[0011] An electronic device includes a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the methods described above.

[0012] In this embodiment, a hierarchical management identification system is constructed to achieve precise positioning of multi-dimensional data; through the atomic operation process of "targeted deletion + incremental insertion", efficient version iteration is achieved while ensuring data consistency and correlation integrity.

[0013] By constructing and executing a scalable traversal loop of "forward extension" and "backward replacement", a systematic exhaustive search of all possible train routes under complex line topology is realized. This effectively solves the problems of incomplete path calculation coverage and easy omission of legal route combinations in the existing technology, ensuring that the RBC can make safety decisions based on complete line information. It significantly improves the completeness, automation and reliability of train operation permission calculation, and provides a more solid technical guarantee for train operation safety.

[0014] By linking the difference fields and test intent in a two-dimensional way, business intelligence is injected into the difference analysis. The rule-driven automatic classification achieves efficient and accurate priority ranking, and finally intelligently synthesizes the direction of problem investigation. This not only significantly improves the automation level and analysis efficiency of RBC system testing and verification, but also ensures the consistency and reliability of verification results through standardized analysis processes, providing strong technical support for the high-quality delivery and secure operation of RBC system.

[0015] Other features and advantages of this application will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the application. Other advantages of this application can be realized and obtained by means of the embodiments described in the description and the accompanying drawings. Attached Figure Description

[0016] The accompanying drawings are used to provide an understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0017] Figure 1 A flowchart illustrating the RBC data version management method provided in Embodiment 1 of this application; Figure 2 This is a flowchart illustrating the method for obtaining a driving permit route provided in Embodiment 2 of this application; Figure 3 This is a flowchart illustrating the RBC message verification method provided in Embodiment 3 of this application. Detailed Implementation

[0018] This application describes several embodiments, but these descriptions are exemplary and not limiting, and it will be apparent to those skilled in the art that many more embodiments and implementations are possible within the scope of the embodiments described herein. Although many possible combinations of features are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature or element of any embodiment may be used in combination with, or may replace, any feature or element of any other embodiment.

[0019] This application includes and contemplates combinations of features and elements known to those skilled in the art. The embodiments, features, and elements disclosed in this application can also be combined with any conventional features or elements to form unique inventive solutions. Any feature or element of any embodiment can also be combined with features or elements from other inventive solutions to form another unique inventive solution. Therefore, it should be understood that any feature shown and / or discussed in this application can be implemented individually or in any suitable combination. Therefore, the embodiments are not limited except by the limitations imposed by the appended claims and their equivalents. Furthermore, various modifications and changes can be made within the scope of the appended claims.

[0020] Furthermore, in describing representative embodiments, the specification may have presented methods and / or processes as a specific sequence of steps. However, the method or process should not be limited to the specific order of steps described herein, to the extent that it does not depend on such a specific order. As will be understood by those skilled in the art, other sequences of steps are also possible. Therefore, the specific order of steps set forth in the specification should not be construed as a limitation of the claims. Moreover, the claims concerning the method and / or process should not be limited to the steps performed in the written order, and those skilled in the art will readily understand that these orders can be varied and still remain within the spirit and scope of the embodiments of this application.

[0021] Example 1 This embodiment provides a version management method for RBC data, which can achieve precise and atomic version updates for data at any target level, while having complete historical version tracing capabilities, and eliminating the need to maintain redundant relational tables, thereby significantly improving the reliability and efficiency of data management and reducing storage overhead.

[0022] In this embodiment, the RBC data is organized in the database into a logically clear and hierarchical tree structure. The core design of this structure is that each layer of data not only represents an independent business dimension, but its identity is also uniquely determined by a management identifier, which encodes the complete path information from the root node to the current node.

[0023] In a preferred embodiment, the multi-layered tree structure comprises the following five layers from top to bottom, achieving comprehensive management from macroscopic road network to microscopic test data: Line layer: As the root level of the tree, it represents a specific railway line entity, such as "AA High-speed Railway". Its attribute identifier is usually the line ID (such as Line_001), which constitutes its management identifier.

[0024] Data Version Layer: Belonging to a specific line, it represents a version of a complete set of RBC basic data configuration used by that line, such as "V2.1.5". Its management identifier is composed of the line layer identifier to which it belongs and the data version number of the attribute identifier of this layer, that is, line ID + data version number (such as Line_001 + V2.1.5).

[0025] RBC Device Layer: Belongs to a specific data version and represents a specific RBC device running under that version's configuration, such as "RBC_A". Its management identifier is inherited from the data version layer and is appended with the RBC name attribute of this layer, forming Line ID + Data Version Number + RBC Name (e.g., Line_001 + V2.1.5 + RBC_A).

[0026] Use Case Version Layer: For a specific RBC device, this represents a version of a set of test scenarios used to test that device, such as "Interlocking Interface Test Suite V1.0". Its management identifier is based on the RBC device layer identifier, with the addition of a use case set ID, forming the structure: Line ID + Data Version Number + RBC Name + Use Case Set ID (e.g., Line_001 + V2.1.5 + RBC_A + UC_Set_01).

[0027] Test data layer: Generated during a specific test execution, representing a snapshot of the data for that test, such as "2023-10-27_Stress Test". Its management identifier is based on the test case version layer identifier, with the addition of a test batch ID, ultimately forming the following structure: Line ID + Data Version Number + RBC Name + Test Case Set ID + Test Batch ID (e.g., Line_001 + V2.1.5 + RBC_A + UC_Set_01 + Batch_20231027).

[0028] The technical advantage of the aforementioned hierarchical structure and identifier design lies in achieving precise operational targeting and logical isolation. Since the uniqueness of each layer of data is guaranteed by its complete management identifier chain (i.e., all upper-level identifiers plus the current layer's identifier), the system can achieve extremely precise positioning when performing data operations (such as querying, updating, and deleting). For example, when updating the configuration of the "RBC_A" device in the "V2.1.5" data version under the "AA High-Speed ​​Rail" line, the system can precisely use the management identifier Line_001 + V2.1.5 + RBC_A to match the target. This operation is strictly limited to the range defined by this triplet, and will not affect the RBC_A device in other data versions (such as V2.1.4) under the same line, nor will it affect the data of other RBC devices (such as RBC_B) under the same version, nor will it affect the data of other lines. This design fundamentally avoids cross-level data conflicts that may be caused by ambiguous relationships in traditional solutions.

[0029] In practical applications, a basic three-layer structure, including at least the line layer, data version layer, and RBC device layer, is sufficient to effectively address the version management issue of core data. Extending the structure to a five-layer structure that includes a test case version layer and a test data layer provides the same refined and consistent management framework for the entire lifecycle of RBC device test data, demonstrating the flexibility and scalability of this solution.

[0030] See Figure 1 The method in this embodiment includes steps 11 and 12.

[0031] Step 11: When it is necessary to update the data at the target level, based on the management identifier corresponding to the target level, match and delete all existing data of the target level stored in the database.

[0032] This step precisely clears old version data at the target level, preparing for the insertion of new data and serving as a prerequisite for incremental updates. Specifically, the system generates a corresponding management identifier (e.g., Line_001 + V2.1.5 + RBC_A) based on the target specified in the update request (e.g., updating the configuration of the "RBC_A" device in version "V2.1.5" under the "AA High-Speed ​​Rail" line). Subsequently, a deletion operation is performed on the target data table in the database, with the WHERE condition strictly matching this management identifier. For example, executing the SQL operation: `DELETE FROM rbc_config WHERE line_id = 'Line_001' AND data_version = 'V2.1.5' AND rbc_name = 'RBC_A'` will only delete data rows that exactly match this identifier combination.

[0033] Compared to existing technologies that either require maintaining complex cross-table relationships for cascading deletions (prone to errors and inefficient) or employ full table scans or fuzzy matching (inefficient and prone to accidental deletions), this step achieves crystal oscillator clearing of target data by using management identifiers as precise filtering conditions. It only deletes specific device data under a specific version that needs updating, without affecting other data versions on the same line, other RBC devices under the same version, or data on other lines.

[0034] Through the above operations, high-precision positioning and operation isolation of data updates are achieved, fundamentally avoiding the risk of cross-level data conflicts caused by uncontrolled update scope, and laying the foundation for subsequent atomic insertion.

[0035] Step 12: After the deletion operation is completed, insert the updated data of the target level into the database, wherein the deletion operation and the insertion operation are encapsulated in the same database transaction to ensure the atomicity of the version update operation.

[0036] This step is to complete the insertion of the new version data into the database, realizing version iteration. Specifically, after step S11 is successfully executed, the system immediately inserts the prepared new version data (e.g., the new configuration file for RBC_A) into the same data table. In the inserted data rows, the values ​​of their management identifier fields (such as line_id, data_version, rbc_name) are completely consistent with the identifier used in the deletion operation, ensuring the continuity of data ownership.

[0037] Compared to the "full overwrite update" method, this step is an "incremental insertion". It does not rewrite the entire record or the entire table, but only adds new data rows. Combined with the targeted deletion in step 11, this constitutes a "delete first, then insert" incremental update mode.

[0038] This step completes the actual update of the data content. Because it is executed in conjunction with targeted deletion, it ensures that, logically, the data at the target level is switched cleanly and completely from the old version to the new version.

[0039] In software implementation, database transactions are used to wrap the SQL operations in steps 11 and 12. For example, starting with BEGIN TRANSACTION, the SQL commands for deletion and insertion are executed sequentially, and finally committed with COMMIT. If any operation fails or a system exception occurs during this period, the transaction will be automatically rolled back, restoring the database to its state before the operation.

[0040] Compared to existing technologies where deletion and insertion are performed step-by-step, potentially leading to data loss or inconsistency due to intermediate states (old data deleted, new data not inserted), this step enforces the atomicity of these two operations through database transaction mechanisms. This means that the system's external presentation is either all old data (transaction failure rollback) or all new data (transaction successful commit), completely eliminating any intermediate chaotic states of "data gaps" or "partial updates." This mechanism completely eliminates the risk of data inconsistency during version updates, significantly improving operational reliability and system robustness. Simultaneously, it ensures that the operation only affects the target level and does not impact data at other levels, providing robust ACID (Atomicity, Consistency, Isolation, Durability) support for the management of core business data. Through the RBC data version management method described above, this embodiment achieves accurate positioning of multi-dimensional data by constructing a hierarchical management identification system; and achieves efficient version iteration while ensuring data consistency and correlation integrity through an atomic operation process of "targeted deletion + incremental insertion".

[0041] In one specific embodiment, based on the version management method described above, a historical version tracing method is further provided, aiming to solve the problems of high storage overhead and complex maintenance caused by relying on additional historical version tables in the prior art. This method can achieve fast and accurate tracing and querying of data at any level in the multi-layer tree structure at any historical point in time without redundant storage.

[0042] The core of this method lies in proposing a lightweight tracing mechanism based on the association between operation logs and management identifiers. This method abandons the traditional practice of separately creating and maintaining "historical version tables" or "version-related snapshot tables," instead directly utilizing the operation logs (such as transaction logs) generated and managed by the database system itself. Crucially, under the protection of the management identifier system, every update operation performed by the database on data (i.e., the "targeted deletion + incremental insertion" transaction mentioned above) is recorded in the log, and this record can be precisely associated with the management identifier of the data being operated on. Therefore, by reverse parsing the operation logs and filtering records related to specific management identifiers, any historical version of the data item corresponding to that identifier can be reconstructed.

[0043] The method in this embodiment includes steps 13 and 14.

[0044] Step 13: When performing a data update operation in the database, record the management identifier corresponding to each operation record in the database's operation log; This step prepares the necessary data foundation for accurate historical tracing. Specifically, when an update transaction is executed, the database management system (DBMS) records the transaction's details (such as operation type DELETE / INSERT, operation timestamp, before and after images of affected data rows, etc.) in its transaction log. The system implementing this method needs to ensure that, during the "targeted deletion" and "incremental insertion," the information of the composite management identifier (e.g., line_id='Line_001', data_version='V2.1.5', rbc_name='RBC_A') is clearly recorded in the log entries either as part of the transaction context or through the content of the data rows themselves. This can typically be achieved by ensuring that the operation data includes these identifier fields in the business logic; the database log will naturally record changes in these field values.

[0045] Compared to traditional solutions that require applications to write additional code at the business layer to copy old data to a separate historical table (which doubles the storage and adds to the code maintenance burden), this step directly leverages the database kernel's inherent logging capabilities. It eliminates the need for additional storage operations at the application layer, requiring only that the data being manipulated carries structured management identification information.

[0046] In this way, the system automatically and without loss generates historical operation logs containing complete location information, providing original and reliable operational basis for traceability, without introducing any additional dedicated storage structure.

[0047] Step 14: Based on the management identifier corresponding to the operation record in the operation log, perform historical version tracing for data at any level in the multi-level tree structure.

[0048] This step responds to user queries by extracting and reconstructing the historical state of specific data from the operation logs. Specifically, when a user needs to query the state of a data item (e.g., the RBC configuration with the management identifier Line_001 + V2.1.5 + RBC_A) at a historical point in time T, the traceability module executes the following process: Log parsing and filtering: Read the database transaction log and filter out all log records (mainly INSERT and DELETE records) that occurred before time point T and whose management identifier and target identifier match.

[0049] State reconstruction: Starting from the earliest relevant record, these operations are "replayed" in chronological order. Typically, by applying the "data afterimage" in each INSERT record and the "data beforeimage" in each DELETE record, the specific content of the data row corresponding to the management identifier at a specified historical time T can be gradually derived.

[0050] Result Return: The reconstructed historical data state is returned to the user. This process can be achieved by writing a dedicated log parsing script or by utilizing log analysis tools provided by some database systems (such as SQL Server's CDC feature or time travel queries).

[0051] Compared to querying separate historical tables that may be outdated or have incorrect associations, this step directly performs targeted retrieval and logical calculations within the operation log using management identifiers. Since the log is a core guarantee of database consistency, its integrity and accuracy are extremely high, and it records every state change.

[0052] Through the steps described above, the system can achieve fine-grained tracing at any level and any point in time. For example, it can trace the changes of a specific configuration item on a single RBC device, or it can trace the complete set of a specific version of all data across the entire line. This provides a flexible tracing granularity that is difficult to achieve with traditional snapshot-based historical tables. At the same time, since there is no need to maintain a separate historical table, it greatly reduces the system's storage complexity and long-term maintenance costs.

[0053] By coupling database operation logs with structured management identifiers for business data using the aforementioned historical version tracing method, this embodiment leverages the database's core mechanisms to meet historical data query requirements. This method completely eliminates the traditional approach of separately maintaining historical version tables, thus achieving accurate and flexible historical version tracing while avoiding the resulting increased storage overhead, complex relationship logic, and heavier maintenance burden. It fills the gaps in existing technologies regarding data version traceability in an extremely lightweight, efficient, and reliable manner, significantly improving the completeness and economy of the entire RBC data management system.

[0054] The method in this embodiment is applicable to the parallel development and testing management of RBC data across multiple lines and versions. For example, consider this scenario: A signal system integrator simultaneously develops and maintains RBC systems for multiple lines. Each line's RBC data has multiple iterative versions (e.g., V2.1, V2.2), and each version contains multiple RBC devices (e.g., RBC_A, RBC_B). The testing team needs to frequently update test case sets for specific RBC devices on different lines and versions, and execute automated tests. Based on the "line-version-RBC device-test case set" identification system built using this method, when an update is needed, only the target level data is precisely located and atomically updated. For example, the update operation only targets the data block identified as [line=AA high-speed rail, version=V2.2, RBC device=RBC_A], without affecting other data. Testers can trace the complete data status of the RBC device at any historical moment through logs for problem reproduction or version auditing. This method can support large-scale, highly parallel RBC data development and testing activities, ensuring the security, accuracy and traceability of data operations, and serves as the infrastructure for efficient collaboration in large and complex projects.

[0055] Example 2 In railway signaling systems, the Track Control Center (RBC) is responsible for calculating and authorizing safe operating routes for trains, i.e., authorized routes. This calculation process requires full consideration of all possible paths ahead from the train's current position, especially when passing through complex stations with multiple tracks and route combinations. Ensuring the completeness and accuracy of the generated authorization is directly related to train safety. However, existing methods for calculating authorized routes suffer from incomplete path traversal coverage. Traditional calculation methods typically employ simple linear extensions or limited path selection logic, making it difficult to systematically traverse all possible route combinations. When facing stations with multiple branch routes, they are prone to premature termination or generating paths based on only a few preset rules, resulting in the omission of numerous legal and feasible operating routes. Consequently, the RBC may be unable to provide the train with feasible authorized route options.

[0056] In view of this, this embodiment provides a method for generating train permit routes, which can generate all legal train permit routes without omission by means of a systematic path traversal mechanism when the RBC system is dealing with complex line topologies, especially in scenarios containing multiple access stations.

[0057] The core of this method lies in proposing a scalable traversal computing mechanism based on structured route data. Using the precise, versioned route data maintained in Example 1 as a foundation, and starting with the initial transponder as the search source, the method automatically and systematically traverses all potentially accessible station nodes and their route combinations through a loop logic consisting of "forward extension" to construct a single path and "backward replacement" to explore alternative routes, until the search space is exhausted. Finally, it outputs a complete set of all legally permitted train routes.

[0058] See Figure 2 The method steps 21 and 22 in this embodiment.

[0059] Step 21: Using the set starting transponder as the starting point of the calculation, perform the forward extension step and the backtracking replacement step in a loop based on the line data until all stations that can be reached from the starting transponder have been traversed.

[0060] Specifically, the system receives external input or determines a specific starting transponder as the common origin for all path calculations based on the train's current position. Simultaneously, this method relies on the route database generated and maintained by the method described in Example 1. This data ensures that information such as route topology, station structure, and route port attributes is structurally complete, version-clear, and consistent, providing a reliable data foundation for subsequent accurate calculations.

[0061] In this step, the forward extension and backtracking replacement are organized into a complete loop, which continues to run until all reachable station nodes have been traversed. Specifically, the system places the forward extension step and the backtracking replacement step within a single loop. After each backtracking replacement step, a new forward extension step is immediately triggered, continuing the exploration along the newly replaced path and generating the next route. The loop terminates when, through backtracking, it is found that the system has returned to the starting point, and all legal route choices to all stations reachable from the starting point have been tried (i.e., all decision possibilities for all stations have been traversed).

[0062] Through the above-mentioned loop control logic, it is ultimately ensured that all legal driving permit routes starting from the origin and under the distance threshold constraint can be generated automatically and without omission, thus completely solving the fundamental problem of incomplete path coverage in the background technology.

[0063] For the forward extension step: Starting from the origin and moving in the direction of travel, the path is extended forward based on the route data. When it reaches a station, all legal receiving routes are filtered based on the station port information. For each receiving route, a corresponding departure route is matched and the path continues to extend until the extension distance reaches the distance threshold of the current route, thus generating a permitted route.

[0064] This forward extension step is the "exploration" and "construction" phase of the path. Its function is to search forward from the currently selected route sequence until the termination condition is met, thus forming a complete feasible route. In practice, starting from the origin, the system simulates train movement based on the line topology data. When a station boundary is detected, all currently legal receiving routes are dynamically selected based on port attributes (such as direction and type) and interlocking conditions. For a selected receiving route, the system matches it with a connectable departure route and then continues forward. This process is repeated at subsequent stations. The extension process continuously monitors the extended distance and dynamically determines the type of the current line segment (such as mainline or siding), applying the corresponding distance threshold as one of the termination conditions. Once the distance threshold is reached, a permitted route from the origin to the current point is generated.

[0065] Compared to traditional methods that may use fixed path extensions, ignore some route combinations, or use uniform distance constraints, this step achieves intelligent and compliant single path construction by dynamically filtering and matching routes during traversal and adapting different distance constraints in real time according to the route type.

[0066] This step ensures that single candidate license routes that conform to the rules can be effectively explored and constructed, while its inherent dynamic matching and adaptation capabilities lay the foundation for the subsequent systematic exploration of all such routes.

[0067] Regarding the retrospective replacement steps: Backtrack from the current route's endpoint to the nearest station's route selection node, replace it with a valid pick-up route that has not been traversed, and match it with the corresponding departure route.

[0068] This step is the "backtracking" and "reversal" phase of the path. Its purpose is to automatically return to the nearest decision point after exploring a path, trying different options to explore new possible routes. In practice, starting from the end point of the generated route, it backtracks along the original path to find the nearest previously visited station node where other valid receiving routes have not yet been attempted. Once found, the previous choice at that node is "undone," replaced by a new, untraveled valid receiving route, and a new departure route is matched accordingly.

[0069] Compared to traditional methods that lack systematic backtracking capabilities and result in incomplete path exploration, this step introduces an automated backtracking and replacement mechanism based on the most recent decision point. Through these operations, it is possible to intelligently exit from a completed path and turn to a new, unexplored path branch. This is the core mechanism that ensures the entire method can cover all possible path combinations.

[0070] Step 22: Output all permitted routes generated during the loop.

[0071] After the loop ends, all permitted driving routes generated during the loop will be output as the final result set.

[0072] Through the above-described method for obtaining train operation permits, this embodiment constructs and executes a scalable traversal loop of "forward extension" and "backward replacement" to achieve a systematic exhaustive search of all possible train operation paths under complex line topologies. This effectively solves the problems of incomplete path calculation coverage and easy omission of legal route combinations in the prior art, ensuring that the RBC can make safety decisions based on complete line information. It significantly improves the completeness, automation, and reliability of train operation permit calculation, providing a more solid technical guarantee for train operation safety.

[0073] In one specific embodiment, a route intelligent matching mechanism based on track identifiers is proposed.

[0074] There are complex correspondences between receiving routes and departure routes within a station. Traditional methods often rely on static configuration tables or simplified assumptions to handle this relationship. This approach struggles to dynamically and accurately match all connected legal departure routes for each possible receiving route, thus missing crucial path combinations in the calculation. Consequently, the generated set of permitted routes fails to accurately reflect the full capacity of the line.

[0075] Therefore, this embodiment associates the endpoint of the receiving route with the starting point of the departure route through a common physical and logical track. By identifying the track identifier accessed by the receiving route, it dynamically retrieves and filters all legal departure routes originating from that track from the route database, achieving automatic and accurate matching between routes.

[0076] Specifically, matching each receiving route with a corresponding departure route includes: automatically filtering all legal departure routes originating from the track that the receiving route accesses from the route data, based on the track identifier of that track.

[0077] This step dynamically and accurately establishes the connection between "entry" and "exit" routes within the station, and is a crucial step in generating continuous and feasible train operation permits. Specifically, once a valid receiving route is selected, the system immediately executes this matching operation: Extract track identifier: The system parses the data structure of the receiving route to obtain the destination information of its path, that is, the track identifier that the train finally enters through the route (e.g., "track G3").

[0078] Dynamic database query: The system uses the track identifier as the core query condition to initiate a query to the route database maintained by the method described in Example 1. The goal of the query is to find all routes defined in the data model as starting from this specific track (e.g., "track G3").

[0079] Legality screening: Based on the query results, further filtering is performed from all routes starting from this track, according to real-time signal logic, track occupancy status and other dynamic conditions, to select the currently legal departure routes.

[0080] Result association: The set of legal departure routes selected is used as the currently available connection options for the receiving route and provided to the subsequent path extension logic.

[0081] Compared to existing technologies that rely on pre-compiled fixed train arrival and departure route correspondence tables (which are difficult to maintain and cannot cover all combinations) or manual selection, this step automates and intelligently matches the trains by dynamically querying and filtering data based on track topology. It directly utilizes the inherent physical connections of the track design (tracks as connection points) to ensure that no physically feasible route connection combinations existing in the data model are overlooked.

[0082] The automated matching process described above fundamentally solves the problem of missing legal route combinations due to human error or rigid static rules. It ensures that during the traversal calculation, whenever a receiving route is selected, the system can discover all physically connected and logically legal subsequent passage possibilities without omission, thus guaranteeing the completeness of the final set of permitted routes for the entire vehicle in the station area.

[0083] In one specific embodiment, a multi-threshold dynamic adaptation driving permission distance control mechanism is proposed.

[0084] The length of a driving permit is not a fixed value, but rather has different distance thresholds depending on the type of route section (such as mainline or siding) and other safety rules. Existing calculation methods typically use a uniform fixed distance for extension calculations, failing to dynamically adjust the endpoint of the permit extension based on the type of route being entered in real time during the traversal process. This rigid approach may result in the generated driving permit routes either being non-compliant due to exceeding the siding allowance length or failing to fully utilize the mainline allowance length, thus reducing the accuracy and practicality of the calculation results.

[0085] Therefore, in this embodiment, during the real-time calculation of path extension, the system continuously monitors the line type of the current extension path and dynamically applies the corresponding distance threshold as the upper limit of the remaining distance of the current permitted extension, so as to achieve accurate matching between the permitted length and the line security level.

[0086] The distance threshold is dynamically adapted according to the line type, including setting a first distance threshold for mainline traffic and a second distance threshold for siding traffic, wherein the first distance threshold is greater than the second distance threshold; in the forward extension step, the line type of the current extension path is determined in real time and the corresponding distance threshold is applied.

[0087] The purpose of the above operations is to ensure that the generation of driving permits strictly adheres to the safety principle of "different routes, different standards," thereby guaranteeing the compliance of the output routes. Specifically, in the forward extension step, the system simultaneously executes the following dynamic adaptation process: Threshold preset: According to railway safety rules, two key thresholds are preset in the system: a first distance threshold (e.g., 31 km) for mainline train operation and a second distance threshold (e.g., 15 km) for siding train operation, and the first threshold is greater than the second threshold.

[0088] Real-time route type determination: As the route extends forward, the data attributes of each route segment traversed are continuously accessed. These attributes are provided by the precise route data maintained in Implementation Example 1, clearly identifying whether each segment is a "main line" or a "siding" (or station line).

[0089] Dynamic threshold switching and application: Maintain a variable for "currently available extension distance". When extending into a new line segment, the system immediately determines the type of the segment.

[0090] If the line enters the main line section, the upper limit of the "current available extension distance" will be set or maintained at the first distance threshold.

[0091] If the vehicle enters the flank section, the upper limit of the "current available extension distance" will be immediately switched to the second distance threshold. This means that even if a certain distance has already been extended on the mainline, once the vehicle enters the flank, the subsequent allowable extension distance will be recalculated according to the stricter flank standard.

[0092] Termination judgment: The forward extension continues until the cumulative extension distance reaches the upper limit of the "currently available extension distance" (i.e., the threshold corresponding to the current line type), then the extension of the line will terminate.

[0093] In this embodiment, by sensing the line type in real time and dynamically switching the constraint threshold during the traversal process, synchronization between the calculation rules and the security rules of complex real-world scenarios is achieved. This solves two potential errors of the fixed threshold method: first, generating excessively long and non-compliant licenses on sidelines; and second, failing to fully utilize the allowed license length on mainlines, leading to unnecessary and frequent authorizations.

[0094] Through the aforementioned dynamic adaptation mechanism, it is ensured that the total length and distribution of each generated driving permit route strictly comply with the corresponding safe driving regulations for that route type. This makes the output set of routes not only mathematically possible paths, but also paths permitted under safety regulations, significantly improving the practicality and safety of the driving permit results.

[0095] Based on the above description, the preferred implementation process of this embodiment is as follows: First, perform initial positioning: using the section transponder as the starting point for calculation, and combining it with the line design information, determine the initial direction of train travel (e.g., forward travel).

[0096] The system then enters the forward extension phase: along the direction of travel, the system extends the path segment by segment based on the line data. When extending to a station, it dynamically filters all currently valid receiving routes (e.g., routes that conform to the direction of travel, are signaled, and are not occupied) based on the station's port attributes (e.g., direction, type, status). For each selected receiving route, the system automatically matches all valid departure routes originating from that track based on the track identifier connected to that route; then it continues to extend forward along the matched departure routes. This extension process continues until the cumulative extension distance reaches the distance threshold set for the current line type (e.g., 31 km for the main line, 15 km for the siding). During the extension, the system identifies the line type of the current section in real time and automatically applies the corresponding threshold constraints, thereby generating the first complete permitted line.

[0097] Next, the backtracking and replacement phase is executed: After generating the first route, the system starts from the current extension endpoint and backtracks along the original path to locate the most recently visited station route selection node. At this node, the system replaces a previously untraversed valid receiving route with a corresponding re-matching departure route.

[0098] Finally, the system iterates and outputs the results: It repeatedly executes the cycle of "backtracking to the nearest station node—changing the receiving route—re-extending forward to the threshold" until all legal receiving and departure route combinations have been traversed from the initial transponder. Ultimately, the system outputs all possible train permission route information generated in this way.

[0099] Optionally, during the traversal process, the system can simultaneously perform abnormal path filtering, automatically removing invalid paths that do not conform to driving rules, such as reverse routes and over-limit paths, thereby improving the effectiveness of the output results. The system can also access real-time line status information (such as fault sections and temporary speed limits) to dynamically adjust the set of extendable paths, further enhancing the applicability of the solution in actual operating environments.

[0100] The method provided in this embodiment is applicable to the automatic generation and safety verification of train operation permits at complex railway hubs. For example, a train is about to enter a large railway hub (such as AA East Station), which has multiple platforms and tracks, resulting in extremely complex route combinations. The Railway Traffic Controller (RBC) needs to calculate and generate all possible safe train operation permit routes to accommodate different receiving tracks and departure directions. Starting from the initial transponder ahead of the train, this method is invoked. Based on accurate track data, the method automatically traverses all legal receiving and departure route combinations within the station through a loop of "forward extension + backtracking replacement." During the extension process, the mainline / siding sections are identified in real time, and different distance thresholds such as 31 km / 15 km are dynamically applied. Finally, the output is a complete set of fully compliant train operation permit routes covering all possibilities. This fundamentally eliminates the risk of missing train operation permits due to calculation omissions, especially under complex station conditions, providing a complete and reliable data foundation for the RBC to make optimal and safest train operation authorization decisions, directly improving the level of train operation safety.

[0101] Example 3 In railway signaling systems, the train control messages generated by the Railway Traffic Controller (RBC) are the core carriers of train control commands, and their correctness and reliability directly affect train safety. Therefore, during the development, testing, and maintenance phases of the RBC system, rigorously comparing and analyzing the actual generated train control messages with the expected messages is an indispensable and crucial step in verifying system functionality and locating product defects. However, existing methods typically only perform basic field time comparisons, outputting all inconsistent fields as a simple list. Faced with complex train control messages containing numerous fields, this simplistic listing method forces testers to manually examine each difference one by one, relying on personal experience to judge and distinguish which differences might indicate critical functional defects affecting train safety and which are merely insignificant parameter configurations or format changes. This entire process not only consumes significant manpower and time, but the accuracy and consistency of the analysis results also highly depend on the individual experience and condition of the testers, making it prone to oversights or misjudgments. Furthermore, because the difference information output by existing tools is completely detached from the specific purpose of the test scenario that generated the message, testers cannot directly determine from the difference report whether the message is verifying functions such as "temporary rate limiting" or "route access". In order to locate the problem, testers have to repeatedly cross-reference the test case documents and the difference list and manually establish the correlation, resulting in a roundabout and inefficient troubleshooting path.

[0102] In view of this, this embodiment provides an RBC message verification method that can intelligently compare and analyze massive amounts of messages generated based on complete driving permission scenarios during RBC system testing, automatically associate test intent, classify differences and priorities, and generate standardized problem troubleshooting guidelines accordingly, thereby significantly improving verification efficiency and accuracy and reducing reliance on expert experience.

[0103] The core of this method lies in proposing a two-dimensional association and rule-driven intelligent analysis mechanism. First, it overcomes the limitations of traditional tools that only compare field values ​​by strongly associating identified discrepancies with the testing intent of the test cases that generated the expected message, assigning a clear business scenario context to each discrepancy. Then, based on a predefined discrepancy classification rule base with security impact levels, it automatically and standardizedly classifies discrepancies in associated scenarios. Finally, by comprehensively utilizing the two key dimensions of discrepancy classification results and testing intent, it intelligently determines the direction of product problem investigation, achieving an automated and structured transformation from raw discrepancies to problem clues.

[0104] In this context, test intent refers to the explicit verification goal or business scenario that a test case is designed with in mind during the design phase. It describes which specific function, logic, or behavior of the RBC system the test case aims to verify is correct. It is not the test steps themselves, but rather the purpose that these steps are meant to achieve.

[0105] The aforementioned difference classification rule base is the core knowledge base and judgment engine for realizing intelligent analysis of message differences. This rule base is predefined and configured based on domain knowledge of railway signaling systems, particularly RBC systems, and aims to automate and standardize the classification and prioritization of identified message differences, thereby replacing inefficient and error-prone manual judgment.

[0106] The difference classification rule base mainly predefines at least one of the following difference categories, and each category specifies its judgment criteria and typical field examples: Differences in key functional fields: These differences refer to inconsistencies in fields that directly affect train operation safety, core train control logic, or train operation permission decisions. The criterion for judgment is whether the field directly participates in the generation of safety-related control commands or status determination.

[0107] Typical field examples include: Movement Authority (MA) status, Speed ​​Profile, Emergency Brake command, Temporary Speed ​​Restriction (TSR) information, and validity of train position reports.

[0108] Priority label: Usually marked as critical or high, requiring testers to pay immediate attention and verify.

[0109] Non-core configuration field differences: These differences refer to inconsistencies in fields that do not affect the core logic of driving safety and are mainly used for identification, recording, auxiliary analysis, or interface display. The criterion for judgment is that changes to the field value will not trigger changes to safety-related train control logic.

[0110] Typical field examples: Train ID, message sequence number, log record timestamp, communication session identifier, and certain auxiliary status codes used for statistics or display.

[0111] Priority label: Usually marked as warning or low, and can be temporarily deferred in the initial analysis.

[0112] Format compliance differences: These differences refer to message field values ​​that do not conform to the predefined data format, type, length, or value range syntax specifications, and are not directly related to the correctness of business logic.

[0113] Typical examples include: field length exceeding the maximum / minimum value defined by the protocol, illegal characters in numeric fields, values ​​of enumeration type fields not in the predefined list, incorrect date / time format, and character encoding mismatch.

[0114] Priority label: Usually marked as warning or medium, requiring correction to ensure robustness of inter-system communication.

[0115] Data accuracy difference: This type of difference refers to the deviation between the actual value and the expected value of an index field, which is within the allowable range of engineering or measurement errors and is not considered a functional error.

[0116] Typical examples include: slight deviations in distance measurements at the centimeter or millimeter level (within the range measurement error tolerance), minute offsets in timestamps at the millisecond level (within the system clock synchronization accuracy), and differences in the mantissas of some calculation results.

[0117] Priority label: Usually marked as a warning or negligible, used to distinguish between real defects and acceptable minor fluctuations.

[0118] The application of the difference classification rule base is achieved through the system's automated processing logic, and the specific process is as follows: Rule matching: Once the system identifies a difference field, the classification engine will match it against predefined rules in the rule base based on one or more of the following dimensions: Segment identifier: Matching is performed directly by field name, field ID, or a unique identifier in the message protocol. For example, in the rule base, a difference in the field name MA_Status can be explicitly specified as a critical function field difference.

[0119] Field metadata: Matching is performed using the defined attributes of the fields (such as data type, data range, and business function description). For example, fields marked as "security related" or "control commands" in the metadata are categorized into key categories based on their differences.

[0120] Difference Value Characteristics: Analyze the specific content of the difference values ​​to make a judgment. For example, check whether the numerical value is within the error tolerance range (judging it as a precision difference), or check whether the string conforms to a regular expression (judging format compliance).

[0121] Automatic classification and tagging: Based on the matching results, the system automatically classifies the difference fields into the corresponding categories (critical functions, non-core configurations, format compliance, data accuracy) and automatically associates the corresponding priority tags (such as critical, warning, alert) with the category.

[0122] Structured Output: The classification results are integrated into a structured analysis report. The report not only lists the differences but also clearly indicates the category and priority of each difference, thereby directly guiding testers to focus on high-priority, high-risk issues.

[0123] Preferably, the structured analysis report is presented in a structured tabular format. This table includes, but is not limited to, the following information: comparison fields (fields identifying the differences), test case values ​​(expected values ​​preset by the test cases), test values ​​(values ​​appearing in the actual test messages), difference types (categories determined by the rule base, such as "differences in key functional fields"), associated test scenarios (intent descriptions of the associated test cases), and issue priorities (such as "critical," "warning," etc.). This structured table systematically presents the details of all differences and their business context, enabling testers to quickly and comprehensively grasp the analysis results and significantly improving the efficiency of result review.

[0124] By deploying and applying this predefined difference classification rule base, the automation, standardization, and objectification of message difference analysis are achieved. It fundamentally changes the situation where testers need to manually interpret massive amounts of differences one by one. Through pre-embedded domain knowledge, the system can automatically identify and highlight the most critical security-related issues, greatly improving analysis efficiency, ensuring the consistency of analysis conclusions, and effectively reducing the risk of overlooking critical security vulnerabilities due to human fatigue or lack of experience.

[0125] See Figure 3 The method in this embodiment includes steps 31 to 34.

[0126] Step 31: Obtain the actual test messages and the expected messages preset by the test cases under the test scenario corresponding to the driving permit route, wherein the driving permit route is generated based on the method described in Example 2.

[0127] The purpose of this step is to ensure the accuracy of the analyzed objects (messages) and the authenticity of the scenarios. Specifically, the system calls a complete set of permitted driving routes generated by the scalable traversal method described in Example 2, and performs tests based on these routes to collect actual test messages that reflect the behavior of the RBC system under all possible driving scenarios. Simultaneously, it obtains theoretically correct expected messages predefined for the same scenario from the test cases. This ensures that the verification of the messages is based on a comprehensive and complete set of driving scenarios, avoiding verification blind spots caused by incomplete test scenario coverage.

[0128] Compared to obtaining messages from isolated and potentially incomplete tests, the messages analyzed in this step are directly related to a set of driving scenarios whose completeness is guaranteed by algorithms. This makes the subsequent analysis conclusions more credible and comprehensive, providing a high-quality, high-coverage input data source for subsequent intelligent analysis and ensuring the comprehensiveness and reliability of the analysis conclusions.

[0129] Step 32: Perform a field-level comparison between the actual test message and the expected message, identify the difference fields, and associate the difference fields with the test intent of the test case that generated the expected message to obtain the association result.

[0130] This step injects business semantics into the field differences, bridging the gap between "phenomenon" and "intent." Specifically, the system compares the two messages field by field, accurately identifying all fields with inconsistent values ​​or content. While identifying the differences, the system automatically retrieves the test intent of the test case from the test case management library using the test case identifier (such as the test case ID) carried in the message. For example, the system not only discovers that "the expected value of field A (speed limit value) is 250, and the actual value is 200," but also automatically associates it with the intent of the test case: "verify temporary speed limiting function." The output is upgraded from a simple "Field A: 250 vs 200" to "Field A (speed limit value): expected 250, actual 200 --> associated test scenario: temporary speed limiting function verification."

[0131] Compared to traditional tools that only output a list of differences without background information, this step automatically associates the test cases with their pre-defined intents, giving each difference field a clear business diagnostic context. This allows analysts to immediately understand the business scenario and test objective of each difference, transforming isolated technical phenomena into problem clues with clear functional orientations, thus laying the foundation for accurate classification and localization in the future.

[0132] While identifying discrepancies, the system automatically calls the test case management library using the test case identifier (such as the test case ID) carried in the message to obtain the test intent metadata bound to that ID (such as "This test case aims to verify the 'temporary speed limit' function"). For example, the system not only discovers that "the expected value of field A (speed limit value) is 250, and the actual value is 200", but also automatically attaches the intent of this test case to form an associated result: "Field A (speed limit value): expected 250, actual 200 --> associated test scenario: temporary speed limit function verification".

[0133] Compared to traditional tools that simply output a list of differences without context, this step automatically associates the differences with the pre-defined intent of the test cases, giving each difference field a clear business diagnostic context. This makes it interpretable, achieving a qualitative leap from "phenomenon" to "problem clue," and providing indispensable core input for subsequent scenario-based classification and accurate problem mapping. This allows subsequent analysis to be based on a combination of "difference features + test scenarios," rather than simply processing isolated field differences in a general way.

[0134] Step 33: Under the constraint of the test intent in the association results, classify the difference fields in the association results based on the preset difference classification rule library. The difference classification rule library predefines at least one of the following categories: key function field differences, non-core configuration field differences, and format compliance differences.

[0135] Among them, the key functional fields are those that directly affect driving safety and control logic; the non-core configuration fields are those that do not affect safety logic.

[0136] This step aims to automate and standardize the severity assessment and contextualized categorization of discrepancies based on domain knowledge and testing intent. Specifically, the system has a pre-defined rule base defined by domain experts. The system automatically matches the rule base for more precise "contextualized classification" not only based on the name or metadata of the discrepancy fields but also on their associated testing intent. For example: In the train initialization scenario, differences in the "train position" field might be categorized as differences in critical functional fields. However, in the train number display scenario, differences in the same "train position" field might be considered differences in non-core configuration fields.

[0137] The system automatically categorizes the differences between fields such as "driving permit status" and "emergency braking command" in relevant functional scenarios as critical categories, while categorizing differences such as "log timestamp" as non-core categories.

[0138] Compared to methods that rely entirely on manual judgment or only perform static field classification, this step achieves dynamic and scenario-based automatic classification by combining test intent with a preset rule base, making the classification results more accurately reflect the actual security impact of the differences. In addition, the automatic completion of accurate filtering and prioritization of differences efficiently guides the testers' attention to the key issues that are most likely to affect security in specific scenarios, greatly improving the efficiency and accuracy of analysis.

[0139] Step 34: Based on the classification results of the difference field, obtain and output the product problem investigation direction information that matches the classification results and is determined by the test intent.

[0140] This step integrates the classification results with the test intent, providing testers with targeted troubleshooting suggestions and shortening the time for root cause identification. The system comprehensively utilizes the outputs of the first two steps: the classification results of differences (such as "differences in key functional fields") and the associated test intents (such as "temporary speed limit function verification"). Based on this information, it generates targeted troubleshooting directions through built-in logical judgments or knowledge reasoning. For example, the system might output: [Key Difference] Speed ​​limit value mismatch, occurring in the temporary speed limit function verification scenario. Suggested troubleshooting directions: 1. RBC temporary speed limit logic processing module; 2. Line temporary speed limit data source synchronization status.

[0141] Compared to existing technologies where testers need to deduce the root cause of a problem by combining fragmented information, this step can automatically integrate information from different types and test scenarios, and output structured troubleshooting guidelines.

[0142] By directly providing users with preliminarily analyzed and actionable clues for problem localization, a rapid transition from "discovering differences" to "starting investigation" was achieved, significantly improving the closed-loop efficiency of problem-solving.

[0143] Through the RBC message verification method described above, this embodiment injects business intelligence into the difference analysis by associating the difference fields and test intent in a two-dimensional way. It achieves efficient and accurate priority ranking through rule-driven automatic classification and finally intelligently synthesizes the direction of problem investigation. This not only significantly improves the automation level and analysis efficiency of RBC system testing and verification, but also ensures the consistency and reliability of verification results through standardized analysis processes, providing strong technical support for the high-quality delivery and secure operation of RBC systems.

[0144] In one specific embodiment, a pre-built difference and problem mapping library is introduced and relied upon to obtain product problem troubleshooting direction information.

[0145] The aforementioned mapping library of differences and problems is key to quickly locating the root cause of discrepancies. This mapping library is a structured knowledge base of experience, storing refined expert experience and typical failure modes accumulated from historical testing and problem investigation. It aims to automatically map categorized message differences to potential defective product modules or system failure chains, providing testers with direct and efficient guidance for troubleshooting.

[0146] This mapping library pre-stores the correspondence between various difference characteristics and potential product problem root causes. For example, the mapping library can define rules: if the difference type is "critical function field difference" and the field name is "driving permit status", it is mapped to "RBC driving permit calculation logic anomaly" or "interlocking interface communication failure"; if the difference type is "data accuracy difference" and involves a speed threshold field, it may be mapped to "line data acquisition or processing error".

[0147] Preferably, the mapping library stores the mapping relationship between difference features, test scenario types and potential product defect modules or fault links.

[0148] Specifically, the mapping library between differences and problems is organized in the form of rules or entries. Its core is to establish a mapping relationship between "difference characteristics," "test scenario types," and "potential product defect modules or failure chains." Each mapping rule typically contains the following elements: Triggering condition: Defines what differences will trigger this mapping rule. This is usually a compound condition, including: Differences categorized by key functional fields.

[0149] Specific field identifier: The field name is driving permission status (MA_Status).

[0150] Specific difference patterns or value ranges: For example, the difference is expressed as an expected value of "Granted" and an actual value of "Denied".

[0151] Test scenario types: such as route access verification, temporary speed limit triggering, etc. (this type is determined by the test intent of the test cases).

[0152] Mapping results indicate one or more possible root causes of the problem when the triggering conditions are met. These directions point to specific software modules, hardware units, communication interfaces, or data processing links.

[0153] The processing flow based on the mapping library is as follows: Input reception: Receives structured output from the classification step, which includes at least: difference field identifier, difference classification result, associated test scenario type (test intent), and specific difference details.

[0154] Rule matching and query: The above input information is matched against numerous mapping rules stored in the mapping library. It looks for rules whose "trigger conditions" match or are highly similar to the difference features and scene type of the current input.

[0155] Result generation and sorting: After a successful match, the system extracts the potential problem directions indicated by the "mapping results" section of the corresponding rule. The system may prioritize multiple possible directions based on the rule's preset confidence level, historical trigger frequency, or problem severity.

[0156] Guided output: Provide the identified troubleshooting directions to the testers in a clear and structured manner (such as lists, tree diagrams, or natural language descriptions).

[0157] To illustrate this more clearly, the following is a sample mapping rule and its application process: A rule in the mapping library: Triggering conditions: Differences categorized by key functional fields; Field name: Driving permit status (MA_Status); Difference pattern: Expected value is Granted, actual value is Denied; Test scenario type: Route access verification; Mapping results (potential problem directions): The internal route calculation logic of RBC has a defect, which leads to the error in the generation of driving permits (which can be compared and verified with the driving permit route calculation results described in Example 2).

[0158] An abnormal interface communication between the RBC and the interlocking system led to errors in the acquisition of safety information such as trackside turnouts and signal status.

[0159] A train location report transmission or processing failure caused the RBC to make a decision to deny clearance based on an incorrect train location.

[0160] When system analysis detects a message discrepancy in the "Route Pass Verification" scenario, categorized as a "Key Functional Field Difference" with the field "Train Permit Status" showing an actual value of "Rejected" while the expected value is "Granted," the aforementioned rule will be automatically triggered. The system will then output the following in the analysis report: "[Key Issue Guidance] Train permit was abnormally rejected. It is recommended to prioritize checking: 1. RBC route calculation module; 2. RBC-interlocking communication interface; 3. Train positioning information flow." By deploying and applying this pre-generated difference and issue mapping library, this embodiment achieves intelligent compression and precise guidance of the issue investigation path. This not only significantly shortens the average issue location time and improves testing and verification efficiency, but also reduces reliance on individual senior personnel for issue diagnosis by solidifying expert experience, thereby enhancing problem-solving capabilities.

[0161] The method provided in this embodiment is applicable to automated integration testing and rapid problem localization of RBC systems before they leave the factory. For example, before the delivery of RBC equipment, high-intensity integration testing needs to be performed on an automated testing platform in the laboratory. The testing platform simulates external systems such as trains and interlocking systems, sending various scenario stimuli to the RBC and receiving and recording the RBC's response train operation messages. After each test execution, the automated testing platform automatically calls this method. It compares the actual response message of the RBC with the expected message and automatically associates it with the intent of the test case (such as "testing the overspeed protection function"). Subsequently, based on a rule base, the differences are intelligently classified (such as marking the "emergency braking command" difference as "critical"), and finally, troubleshooting suggestions are directly output through a mapping library (such as: "Critical difference: Braking was not triggered under overspeed. Recommended checks: speed monitoring algorithm module, braking command output interface"). This method can greatly improve testing efficiency and defect detection capabilities, and accelerate the RBC product development iteration and quality assurance process.

[0162] Furthermore, embodiments of this application also provide a storage medium storing a computer program, wherein the computer program is configured to execute the method described above when running.

[0163] This application provides an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described above.

[0164] This electronic device can take many forms, including dedicated or general-purpose computing equipment. For example, it could be a dedicated test server or industrial computer used for RBC system testing and data management; the main control unit of an automated test platform integrated in a railway signal laboratory; or even an engineer's workstation or laptop used for research and development and debugging.

[0165] The following describes several typical functional unit configurations with reference to embodiments. These units are the specific manifestations of the functional logic of the computer program and are integrated into the electronic device to enable it to have more complete, practical and secure data processing and analysis capabilities.

[0166] 1. Electronic device with integrated anomaly filtering function In one exemplary embodiment, the electronic device executing the method for obtaining driving permit routes further includes an anomaly filtering unit in its program logic. This unit operates dynamically during route traversal calculations, and its function is to automatically identify and filter out paths that do not conform to driving rules based on predefined driving safety rules and route topology constraints. For example, it automatically excludes reverse routes (paths opposite to the prescribed driving direction), over-limit paths (paths exceeding a dynamic threshold in length or containing impassable sections), and other logically abnormal path combinations. By integrating this unit, the electronic device can "online" purify the path set during traversal, significantly improving the effectiveness and reliability of the final output driving permit routes and avoiding providing invalid or dangerous path schemes to subsequent control decision modules.

[0167] 2. Electronic devices integrating real-time linkage functions In another exemplary embodiment, the electronic device may further include a real-time linkage unit. This unit functions to correlate and integrate the route traversal calculation process with real-time track status information from an external monitoring system (such as a centralized signal monitoring system). This real-time status information includes, but is not limited to, faulty sections (such as track circuit faults), temporary speed limit (TSR) commands, and electric traction power supply status. Based on this dynamic information, the unit adjusts the "legal route" judgment logic and extendable areas in the traversal calculation in real time, dynamically excluding or marking affected paths. By integrating this unit, the route traversal generated by the electronic device can closely match the real-time operating conditions of the track, greatly improving the practicality and scenario adaptability of the calculation scheme, allowing its results to be directly used to simulate real operating environments or assist in real-time scheduling decisions.

[0168] 3. Electronic devices with integrated access control functions In embodiments involving data management and testing verification, the electronic device further includes an access control unit. This unit centrally manages user access to all data within the device (including basic line data, version data, test cases, message records, and analysis results) based on pre-defined access permission policies for different users or roles. The granularity of managed permissions may include one or any combination of the following: data import / update permissions, data viewing and reading permissions, test execution trigger permissions, and analysis result export permissions. By integrating this unit, the electronic device can ensure the auditability of data operations and system security, prevent unauthorized modifications or leakage of sensitive information, and meet the stringent requirements for data security and process standardization in railway signaling systems at all stages of development, testing, and operation and maintenance.

[0169] In summary, the aforementioned anomaly filtering unit, real-time linkage unit, and access control unit represent the extended functions that the electronic device may possess to meet specific application requirements. Combined with the basic architecture (memory, processor, and basic program) of the core execution method, they together constitute a dedicated electronic device that is adaptable to different scenarios, secure, reliable, and powerful.

[0170] It will be understood by those skilled in the art that all or some of the steps, systems, or apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term "computer storage medium" includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

Claims

1. A version management method for RBC data, characterized in that, The RBC data is organized into a multi-level tree structure in the database according to business dimensions for management. This multi-level tree structure, from top to bottom, includes a line layer for marking each railway line, a data version layer for marking different versions of RBC data within that railway line, and an RBC device layer for marking each RBC device under each version of RBC data. Each level in the multi-level tree structure has its own attribute identifier, and each level is uniquely identified by its own management identifier. The management identifier of each level includes the attribute identifiers of all its parent levels and the attribute identifier of the current level. The method includes: When it is necessary to update the data at the target level, based on the management identifier corresponding to the target level, match and delete all existing data of the target level stored in the database. After the deletion operation is completed, the updated data of the target level is inserted into the database; The deletion and insertion operations are encapsulated within the same database transaction to ensure the atomicity of the version update operation.

2. The method according to claim 1, characterized in that, The multi-layered tree structure, from top to bottom, also includes a test case version layer for the test scenario set version of the RBC device, and a test data layer for marking the data snapshots generated by any test execution.

3. The method according to claim 1 or 2, characterized in that, The method further includes: When performing a data update operation in the database, the management identifier corresponding to each operation record is recorded in the database's operation log. Based on the management identifier corresponding to the operation record in the operation log, historical version tracing is performed on the data at any level in the multi-level tree structure.

4. A method for obtaining a driving permit route, characterized in that, include: Starting from the designated initial transponder, and based on the line data maintained by the method described in any one of claims 1 to 3, the forward extension step and the backtracking replacement step are executed iteratively until all stations reachable from the initial transponder have been traversed; wherein: The forward extension step is as follows: starting from the starting point along the direction of travel, extend the path forward according to the route data. When the extension reaches the station, filter all legal receiving routes according to the station port information, and match the corresponding departure route for each receiving route before continuing to extend until the extension distance reaches the distance threshold of the current route, thereby generating a permitted route for travel. The backtracking and replacement step is as follows: backtrack from the current route endpoint to the route selection node of the nearest station, replace it with a valid receiving route that has not been traversed, and match it with the corresponding departure route. Output all permitted routes generated during the output loop.

5. The method according to claim 4, characterized in that, Matching a corresponding departure route to each receiving route includes: selecting all legal departure routes originating from the track that the receiving route accesses from the route data, based on the track identifier of that track.

6. The method according to claim 4, characterized in that, The distance threshold is determined according to the line type, including setting a first distance threshold for mainline traffic and setting a second distance threshold for siding traffic, wherein the first distance threshold is greater than the second distance threshold; In the forward extension step, the line type of the current extension path is determined in real time and the corresponding distance threshold is applied.

7. An RBC message verification method, characterized in that, include: Obtain the actual test messages and the expected messages preset by the test cases collected under the test scenario corresponding to the driving permit route, wherein the driving permit route is generated based on the method described in any one of claims 4 to 6; The actual test message and the expected message are compared at the field level to identify the difference fields. The difference fields are then associated with the test intent of the test case that generated the expected message to obtain the association result. The test intent describes what function, logic, or behavior of the RBC system is to be tested by executing the test case. Based on a preset difference classification rule base, the difference fields in the association results are classified. The difference classification rule base predefines at least one of the following categories: key functional field differences, non-core configuration field differences, and format compliance differences. Among them, key functional fields are fields that directly affect driving safety and control logic; non-core configuration fields are fields that do not affect safety logic. Based on the classification results of the difference fields, obtain and output product problem investigation direction information that matches the classification results and is determined by the test intent.

8. The method according to claim 7, characterized in that, The product problem troubleshooting direction information is obtained by querying a preset mapping library of differences and problems; The difference and problem mapping library stores the mapping relationship between difference features, test scenario types and potential product defect modules or fault links; wherein the test scenario types are divided according to the test intent.

9. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method according to any one of claims 1 to 8 when it is run.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method according to any one of claims 1 to 8.

Images