Rail transit full interface signal object consistency supervision and logic checking method

Abstract

This application provides a method for consistency supervision and logical verification of all interface signal objects in rail transit. The method includes: establishing a complete set of signal objects and generating object attribute update events; responding to object attribute update events, determining at least two interfaces associated with the corresponding signal object through interface mapping relationships, extracting the state values ​​of the corresponding signal object at each interface from the original data records and comparing them, generating a state consistency alarm when the state values ​​are inconsistent; responding to object attribute update events, determining the object category and the updated attribute items of the signal object corresponding to the object attribute update event, calling configurable rules matching the object category and attribute items, verifying the attribute relationship between the signal object and at least one associated signal object, and generating a logical consistency alarm when the configurable rules are not met. This application can improve the coverage of full interface supervision, increase the accuracy of complex logical anomaly identification, and enhance the efficiency of alarm tracing and location.

Description

Technical Field

[0001] This application relates to the field of monitoring technology for rail transit signaling systems, and in particular to a method for monitoring and logically verifying the consistency of all interface signal objects in rail transit. Background Technology

[0002] Rail transit signaling systems are used to ensure the safe and efficient operation of trains. They typically include equipment such as a train control center, a wireless block signaling center, a temporary speed limit server, computer interlocking, and centralized dispatching. These devices exchange data via various interface protocols such as Ethernet, serial ports, and fieldbus, forming a complex signal transmission network. To ensure the safe and reliable operation of the system, it is necessary to monitor and verify the consistency of data from each interface and the logical correctness of the signal object states.

[0003] In existing technologies, common solutions include: deploying data acquisition and protocol parsing modules for a single interface to achieve interface byte stream parsing and anomaly threshold judgment; verifying and alarming the local logical relationships of a small number of signal objects based on fixed rules; and independently supervising single object types such as track sections and signals. These solutions generally suffer from limited interface coverage, lack of cross-interface linkage supervision capabilities, rigid rules that are difficult to adapt to different line conditions, equipment types, and test scenarios, and a single supervision dimension that makes it difficult to simultaneously achieve cross-interface consistency and verification of complex logical relationships between objects. Furthermore, signal object sets often rely on pre-configuration, making real-time updates difficult with dynamic changes such as temporary speed limits and direction changes. Interface data, object data, and alarm information are stored in a scattered manner, lacking the ability to trace and correlate data, objects, rules, and alarms, which is detrimental to fault location and problem investigation. Summary of the Invention

[0004] In view of this, this application provides a method for monitoring and verifying the consistency of all interface signal objects in rail transit, in order to solve the problems of incomplete interface coverage, poor adaptability of fixed rules, and lack of dual verification of consistency and logic in the prior art.

[0005] A first aspect of this application provides a method for consistency supervision and logical verification of signal objects across all interfaces in rail transit, comprising: receiving data messages from multiple interfaces of a rail transit signaling system via a message queue, and uniformly encapsulating the data messages to obtain raw data records containing time identifiers and data source identifiers; establishing a complete set of signal objects based on pre-configured line condition data, the complete set of signal objects including multiple signal objects and object identifiers, object categories, attribute sets, and interface mapping relationships corresponding to each signal object; parsing the data messages according to the interface mapping relationships, writing the parsed attribute values ​​into the attribute set of the corresponding signal object, and generating an object attribute update event when the attribute values ​​are updated; and responding to the object attribute update event. The system first identifies at least two interfaces associated with a corresponding signal object through an interface mapping relationship. It then extracts the state values ​​of the corresponding signal object at each interface from the original data record and compares them. If the state values ​​are inconsistent, a state consistency alarm is generated. Next, it responds to an object attribute update event, determines the object category of the signal object corresponding to the event and the updated attribute item, calls a configurable rule matching the object category and attribute item, and verifies the attribute relationship between the signal object and at least one associated signal object. If the configurable rule is not satisfied, a logical consistency alarm is generated. Finally, it associates the original data record, the signal object's attribute data, the configurable rule identifier, and the state consistency alarm and / or logical consistency alarm to form an association record and stores it.

[0006] A second aspect of this application provides a rail transit full-interface signal object consistency monitoring and logic verification device, comprising: a receiving module, configured to receive data messages from multiple interfaces of a rail transit signaling system via a message queue, and uniformly encapsulate the data messages to obtain original data records containing time identifiers and data source identifiers; an establishing module, configured to establish a complete set of signal objects based on pre-configured line condition data, the complete set of signal objects including multiple signal objects and object identifiers, object categories, attribute sets, and interface mapping relationships corresponding to each signal object; a parsing module, configured to parse the data messages according to the interface mapping relationships, write the parsed attribute values ​​into the attribute set of the corresponding signal object, and generate an object attribute update event when the attribute values ​​are updated; and a comparison module, configured to respond to... The object attribute update event identifies at least two interfaces associated with the corresponding signal object through interface mapping. It extracts the state values ​​of the corresponding signal object at each interface from the original data record and compares them. If the state values ​​are inconsistent, a state consistency alarm is generated. The verification module responds to the object attribute update event, determines the object category of the signal object corresponding to the object attribute update event and the updated attribute item, calls the configurable rules that match the object category and attribute item, and verifies the attribute relationship between the signal object and at least one associated signal object. If the configurable rules are not met, a logical consistency alarm is generated. The association module associates the original data record, the attribute data of the signal object, the configurable rule identifier, and the state consistency alarm and / or logical consistency alarm to form an association record and stores it.

[0007] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0008] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0009] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects:

[0010] The system receives data messages from multiple interfaces of the rail transit signaling system via a message queue, and encapsulates these messages to obtain raw data records containing time and data source identifiers. Based on pre-configured line condition data, a complete set of signal objects is established, including multiple signal objects and their corresponding object identifiers, object categories, attribute sets, and interface mapping relationships. Data messages are parsed according to the interface mapping relationships, and the parsed attribute values ​​are written into the attribute set of the corresponding signal object. An object attribute update event is generated when an attribute value is updated. In response to the object attribute update event, the system determines the corresponding signal object's associated interface mapping relationship. This method reduces the number of interfaces by extracting the status values ​​of corresponding signal objects from the original data records at each interface and comparing them. A status consistency alarm is generated when the status values ​​are inconsistent. In response to object attribute update events, the method determines the object category of the signal object corresponding to the update event and the updated attribute items. It then calls configurable rules matching the object category and attribute items to verify the attribute relationship between the signal object and at least one associated signal object. A logical consistency alarm is generated when the configurable rules are not met. Finally, the original data records, signal object attribute data, configurable rule identifiers, and status consistency alarms and / or logical consistency alarms are associated to form an associated record, which is then stored. This application improves the coverage of full interface supervision, increases the accuracy of complex logical anomaly identification, and enhances the efficiency of alarm tracing and location. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart illustrating the consistency supervision and logic verification method for all interface signal objects in rail transit provided in this application embodiment;

[0013] Figure 2 This is a schematic diagram of the structure of the rail transit full-interface signal object consistency supervision and logic verification device provided in the embodiments of this application;

[0014] Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0015] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0016] The rail transit signaling system is the core component ensuring the safe and efficient operation of trains. It comprises several key devices, including the Train Control Center (TCC), Radio Block Center (RBC), Temporary Speed ​​Limit Server (TSRS), Computer Interlocking System (CBI), and Centralized Traffic Control System (CTC). These devices interact with each other via various interface protocols such as Ethernet, serial ports, and CAN cards, forming a complex signal transmission network. To ensure the safety and reliability of the signaling system, it is necessary to monitor and verify the consistency of interface data between devices and the logical correctness of signal object states.

[0017] Currently, there are various monitoring or verification technologies for rail transit signal interfaces in the industry, which can be mainly divided into the following categories:

[0018] 1. Single-interface data monitoring technology

[0019] Specific structure: This type of technology typically deploys an independent monitoring module for a specific interface (such as TCC-CTC interface, TCC-CBI interface), and the core includes an interface data acquisition unit, a protocol parsing unit, and a status display unit;

[0020] Working principle: By collecting byte stream data from a single interface, parsing it according to a fixed interface protocol, extracting local status information of the signal equipment (such as track section occupancy status and signal display status), and determining whether the data is abnormal by simply comparing it with preset thresholds or fixed standard values;

[0021] Typical applications include interface monitoring functions in centralized railway signal monitoring systems (CSM), which only collect data and display status for specific interfaces that have been connected, and do not involve multi-interface linkage verification.

[0022] 2. Fixed-rule local logic verification techniques

[0023] Specific structure: This type of technology includes a fixed rule storage module, a data input module, and a logic judgment module. The rule storage module pre-stores simple logical relationships of a small number of core signal objects (such as the relationship between a red signal light and track section occupancy).

[0024] Working principle: By collecting signal data within a limited range, it matches the data with pre-stored fixed logic rules. If the rules are not met, an alarm is triggered.

[0025] Typical limitations: Once the rules are fixed, they cannot be modified and can only be adapted to specific lines or specific equipment types, resulting in poor versatility.

[0026] 3. Independent Supervision Technique for Signal Objects

[0027] Specific structure: Independent monitoring modules are designed for single-type signal objects such as track sections and signal machines, and there is no data interaction between the modules;

[0028] Working principle: It independently monitors only one attribute of a single type of signal object (such as the occupancy status of a track section or the filament status of a signal), without considering the correlation logic between signal objects (such as the linkage between the departure direction and the occupancy status of the track section).

[0029] Typical problem: The supervision dimension is too singular and cannot cover the full-link logic verification requirements of the signal system.

[0030] Although existing technologies have achieved partial monitoring functions for rail transit signal interfaces, the following core shortcomings still exist in meeting the full-scenario supervision requirements of train control systems involving "multiple interfaces, multiple signal objects, and complex logical relationships":

[0031] Incomplete interface coverage and lack of full-interface linkage supervision capability: Existing technologies mostly monitor single or a few interfaces, failing to achieve synchronous acquisition and linkage verification of full-interface data such as TCC-TCC, TCC-CBI, TCC-CTC, TCC-TSRS, TCC-TC, TCC-LEU, and TCC-IO. This makes it impossible to detect inconsistencies in the status of signal objects across interfaces (such as the same track section showing "occupied" on the TCC-CTC interface but "idle" on the TCC-CBI interface).

[0032] Supervision rules are fixed and have poor adaptability: The verification rules of existing technologies are mostly fixed in the system through code, and cannot be customized according to different line conditions, different test scenarios, and different signal equipment types. This makes it difficult to adapt to diverse rail transit signal systems (such as the interface protocol differences between CTCS-2 and CTCS-3 train control systems, and the differences in signal layout of different stations).

[0033] The supervision dimension is singular, lacking a dual verification of "consistency + logic": Existing technologies can only achieve simple comparison of the state consistency of signal objects (such as whether the data before and after the same interface is consistent), or single logical relationship verification (such as the association between the red light of the signal and the occupancy of the track section). It has not formed a dual verification system of "supervision of the state consistency of signal objects across interfaces + verification of the logical association between signal objects", and cannot detect complex logical errors (such as the logical mismatch between the low frequency code sequence of the track section and the displayed state of the signal, and the logical conflict between the departure gate change and the section locking state).

[0034] Insufficient dynamic adaptation capability of signal objects: Existing technologies require the pre-definition of a fixed set of signal objects, and cannot automatically generate or update the complete set of signal objects according to dynamic changes in interface data (such as the addition of temporary speed limit commands or the switching of section directions), resulting in "observation omissions" during the supervision process (such as newly added temporary speed limit signal objects not being included in the supervision scope).

[0035] Weak data traceability and correlation capabilities: Existing technologies store interface data, line condition data, and alarm information independently, without establishing a full-link correlation of "data-object-rule-alarm". When an abnormal alarm occurs, it is impossible to quickly trace the original interface data, associated signal objects, and applicable supervision rules corresponding to the alarm, which is not convenient for fault location and problem investigation.

[0036] In summary, existing rail transit signal interface supervision technologies suffer from problems such as narrow coverage, poor adaptability, single supervision dimension, and insufficient dynamic response, making it difficult to meet the high-precision supervision and verification requirements of the train control system across all interfaces and scenarios. There is an urgent need for a signal object supervision method that supports rule configuration, covers all interfaces, and has dual verification capabilities.

[0037] To address the core shortcomings of existing rail transit signal interface monitoring technologies, this application proposes a consistency monitoring and logic verification method for all rail transit interface signal objects. This application aims to solve the following five key technical problems:

[0038] 1. How to achieve synchronous acquisition and linkage supervision of all interface data of the train control system based on message queue, covering all key interfaces of national railway ground equipment such as TCC-TCC, TCC-CBI, and TCC-CTC, and avoid missing the problem of inconsistent status of cross-interface signal objects;

[0039] 2. How to design a flexible rule configuration mechanism based on Lua scripts, allowing users to directly edit and view rules in the system interface, adapt to the custom supervision needs of different lines, test scenarios, and device types, and improve the adaptability and versatility of the technical solution;

[0040] 3. How to construct a dual verification system of "cross-interface state consistency + signal object logical correlation" to solve the problems of insufficient supervision dimension and complex logic error identification capability of existing technologies;

[0041] 4. How to achieve dynamic generation and updating of the entire set of signal objects to adapt to dynamic changes in interface data (such as the addition of temporary speed limits and switching of section directions) and avoid supervision of "observation item omission";

[0042] 5. How to establish a full-link associated storage of "interface data - signal object - supervision rules - alarm information" to improve the efficiency of fault tracing and location of abnormal alarms.

[0043] The core concept of this application is to construct a closed-loop monitoring system consisting of "RabbitMQ message queue full data access - Lua scripting rule configuration - dual verification - dynamic object management - full-link associated storage". This system overcomes the shortcomings of existing technologies through modular design. The overall architecture is as follows:

[0044] 1. Full-interface data access layer: Based on the RabbitMQ message stack, it receives interface data from all sources, such as line condition simulation, interface simulation, and maintenance terminal, to achieve synchronous collection and unified distribution of multi-source and full-interface data, providing a stable data foundation for cross-interface linkage supervision;

[0045] 2. Rule Configuration Layer: A visual Lua script rule configuration module is designed, which allows users to edit, view, and modify supervision rules in the system interface according to the hierarchy of "signal object - change attribute - involved interface - logical relationship". The rules are stored in the form of Lua scripts and can be quickly loaded and taken effect without modifying the system code;

[0046] 3. Core Verification Layer: Build a "State Consistency Verification Module + Logical Consistency Verification Module". First, verify the state consistency of the same signal object in different interfaces, and then call the custom rules in the Lua script to verify the logical relationship between signal objects, forming a double guarantee;

[0047] 4. Dynamic Object Management Layer: Based on the interface data distributed by RabbitMQ, a complete set of signal objects is dynamically generated (if there is line condition simulation data, it can be directly reused; otherwise, it is generated by aggregating data from multiple interfaces), and the object set is updated in real time according to data changes to ensure that no supervision is missed.

[0048] 5. End-to-end storage and output layer: Associates raw data, signal object data, Lua script rules, and alarm information with storage interface, and synchronously supports real-time alarm display, reverse feedback to the line condition simulation system, and Excel export, taking into account both real-time monitoring and traceability needs.

[0049] This application overcomes the shortcomings of existing technologies at their root through targeted technical design, and the specific correspondence is as follows:

[0050] 1. Solving the problem of "incomplete interface coverage": The technical solution uses RabbitMQ message stack as the core of data access, which does not rely on direct binding of physical communication methods. It can uniformly receive data from all sources such as line condition simulation, interface simulation, and maintenance terminal, covering all key interfaces such as TCC, CBI, CTC, TSRS, TC, and LEU, realizing synchronous collection and linkage processing of all interface data, and avoiding interface coverage omissions from the data access level;

[0051] 2. Solve the problem of "fixed rules and poor adaptability": Innovatively adopt Lua script to store supervision rules, combined with the visual operation of the system interface, users can directly edit complex logic rules (such as the association conditions between signal objects and the verification threshold), and the rules will take effect without restarting the system after modification. It perfectly adapts to the customized needs of CTCS-2 / 3 level train control system, different station layouts, and diverse test scenarios, and greatly improves the versatility of the solution.

[0052] 3. Solve the problem of "single supervision dimension": Construct a dual verification system of "state consistency + logical consistency" - the state consistency verification module specifically compares the state differences of the same signal object at different interfaces, and the logical consistency verification module covers the complex logical relationships of core signal objects such as track sections, block sections, signals, and departure gates by calling custom rules in Lua scripts. The dual verification works together to comprehensively identify simple state conflicts and complex logical errors.

[0053] 4. Solve the problem of "insufficient dynamic adaptation capability": Design a dynamic signal object generation mechanism. The complete set of signal objects is not fixed in advance, but is dynamically added / updated based on the interface data distributed in real time by RabbitMQ (such as automatically creating the corresponding signal object and including it in the supervision when a new temporary rate limit command is added), ensuring that the supervised object is synchronized with the interface data in real time, and completely avoiding "observation omission".

[0054] 5. Solving the problem of "weak data traceability and correlation capabilities": The technical solution establishes a correlation index in the storage stage for "interface raw data - RabbitMQ message log - signal object - Lua script rule - alarm information". During storage, key information such as line, station, timestamp, and data version are synchronously correlated. When an alarm occurs, the corresponding raw data, the triggered Lua script rule, and the associated signal object attributes can be quickly traced, which greatly improves the efficiency of fault location.

[0055] In summary, this application, through its targeted design of "RabbitMQ full data access, Lua scripting rule configuration, dual verification, dynamic object management, and full-link association," systematically overcomes the core defects of existing technologies and achieves comprehensiveness, flexibility, accuracy, and traceability in the supervision of rail transit signal interfaces.

[0056] The technical solution of this application will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0057] Figure 1 This is a flowchart illustrating the consistency supervision and logic verification method for all interface signal objects in rail transit provided in this application embodiment. Figure 1 As shown, the method may specifically include:

[0058] S101 receives data messages from multiple interfaces of the rail transit signaling system through a message queue, and encapsulates the data messages in a unified manner to obtain the original data record containing time identifier and data source identifier;

[0059] S102, establish a complete set of signal objects based on pre-configured line condition data. The complete set of signal objects includes multiple signal objects and the object identifier, object category, attribute set and interface mapping relationship corresponding to each signal object.

[0060] S103, parse the data message according to the interface mapping relationship, write the parsed attribute values ​​into the attribute set of the corresponding signal object, and generate an object attribute update event when the attribute values ​​are updated;

[0061] S104, respond to the object attribute update event, determine at least two interfaces associated with the corresponding signal object through the interface mapping relationship, extract the state value of the corresponding signal object in each interface from the original data record and compare them, and generate a state consistency alarm when the state values ​​are inconsistent.

[0062] S105, respond to the object attribute update event, determine the object category of the signal object corresponding to the object attribute update event and the updated attribute item, call the configurable rule that matches the object category and attribute item, verify the attribute relationship between the signal object and at least one associated signal object, and generate a logical consistency alarm when the configurable rule is not met.

[0063] S106, associate the original data record, the attribute data of the signal object, the configurable rule identifier, and the status consistency alarm and / or logical consistency alarm to form an association record and store it.

[0064] In some embodiments, the data message is uniformly encapsulated to obtain a raw data record containing a time identifier and a data source identifier, including:

[0065] When a data message is received through the message queue, the receiving time of the data message is obtained and a time stamp corresponding to the receiving time is generated;

[0066] Determine the data source identifier corresponding to the data message based on the message queue to which the data message belongs and / or the interface identifier information carried by the data message;

[0067] The time stamp, data source stamp, and message payload of the data message are combined to generate the original data record, which is then written to the cache storage area for subsequent retrieval and association.

[0068] Specifically, in practical applications, the interfaces of the rail transit signaling system send signal data messages through message queues. These messages contain data from different devices. To ensure data integrity and subsequent correct processing, the system first uniformly encapsulates each received data message.

[0069] First, when the message queue receives data messages from different rail transit signaling system devices, the system immediately records the moment the message was received. Specifically, the system generates a timestamp corresponding to the moment of receipt using the message queue's receive timestamp. The timestamp is accurate to milliseconds to ensure precise time-series management of the data. This ensures that the system can process and correlate data messages in chronological order during subsequent processing.

[0070] Furthermore, each data message carries interface identification information, indicating the message's source. The system determines the specific source of the data message by parsing the interface identification information or by checking the message queue's ownership information. For example, the data may originate from equipment such as the Train Control Center (TCC) or Computer Interlocking System (CBI). The system uses this identification information to generate a data source identifier to trace the data's origin and help accurately identify data from different devices and interfaces during subsequent processing.

[0071] Furthermore, after obtaining the time identifier and data source identifier, the system combines these two identifiers with the actual payload of the data message to generate a complete raw data record. The data payload includes specific signal data, such as track section occupancy status and signal status. At this point, the generated raw data record includes: a time identifier, a data source identifier, and a message payload. The combination of these three ensures the uniqueness and timeliness of each data record.

[0072] Finally, the system writes the generated raw data records to a cache storage area for later retrieval and further processing. These data records will be temporarily stored until the system needs to use them for signal object parsing, cross-interface state consistency verification, and logical verification, at which point it can quickly call and associate the relevant data.

[0073] Through the above process, this embodiment ensures the integrity, timing, and traceability of data messages sent by each interface in the rail transit signaling system, providing an efficient and reliable data foundation for subsequent signal object parsing and verification.

[0074] In some embodiments, a complete set of signal objects is established based on pre-configured line condition data, including:

[0075] Based on the signal object definition information, generate multiple signal objects and configure an object identifier, object category, and a set of attributes to carry the object attribute values ​​for each signal object;

[0076] Based on the mapping information, an interface mapping relationship is established for each signal object. The interface mapping relationship is used to indicate the set of interfaces associated with the signal object, as well as the mapping relationship used to map fields in the data message to corresponding attribute items in the attribute set.

[0077] Write multiple signal objects and their corresponding interface mappings into the complete set of signal objects for parsing data messages and subsequent consistency monitoring and logic verification calls.

[0078] Specifically, in a rail transit signaling system, a signal object refers to various signal elements that need to be monitored and verified, such as track sections, signals, and block sections. The system first generates multiple signal objects based on their definition information. For example, for a track section object, the system will generate a unique object identifier (e.g., "track section 01") and assign it an object category (e.g., "track section"). Each signal object needs a set of attributes to carry its different state information, such as "occupancy status" and "signal display status." The system configures an attribute set containing multiple attribute items for each signal object to ensure that it can store various dynamic information related to that signal object.

[0079] In some examples, each signal object not only has its own independent identifier, category, and attribute set within the system, but also needs to interact with different interfaces. To achieve cross-interface data integration and verification, the system establishes an interface mapping relationship for each signal object based on pre-configured line condition data. This mapping relationship indicates which interfaces a signal object is associated with and further defines how fields in data messages are mapped to the attribute set of the signal object. For example, the "track occupancy status" field in the TCC and CTC interfaces can be mapped to the "occupancy status" attribute item of the "track section 01" signal object through the interface mapping relationship. In this way, the system can correctly map data fields from different interfaces to the corresponding attributes of the signal object, ensuring data accuracy and consistency.

[0080] Furthermore, multiple signal objects and their corresponding interface mappings are written into the complete set of signal objects. The complete set of signal objects is a collection containing all signal objects, their attributes, and interface mappings; it forms the basis for the system's data message parsing, state consistency checks, and logical verification. In subsequent data processing, the system can quickly locate the relevant signal objects and their corresponding attribute items based on this complete set of signal objects and execute the appropriate verification logic.

[0081] Through the above implementation method, this embodiment effectively manages the definition and mapping relationship of signal objects and their associated interfaces in a unified manner, ensuring that the system can efficiently parse data messages from different interfaces and perform accurate logical verification. This structured set of signal objects provides a solid data foundation for subsequent data consistency supervision and complex logical verification, greatly improving the data processing efficiency and reliability of the rail transit signaling system.

[0082] In some embodiments, the data message is parsed according to the interface mapping relationship, the parsed attribute values ​​are written into the attribute set of the corresponding signal object, and an object attribute update event is generated when the attribute values ​​are updated, including:

[0083] The interface corresponding to the data message is determined based on the data source identifier in the original data record, and the target signal object and the corresponding attribute item mapping information are determined in the interface mapping relationship based on the interface;

[0084] The message payload of the data message is parsed according to the attribute item mapping information to obtain at least one attribute value corresponding to the attribute item mapping information.

[0085] Write at least one attribute value into the attribute item corresponding to the attribute item mapping information in the attribute set of the target signal object, and obtain the attribute value after writing and the attribute value before writing;

[0086] When the attribute value after writing is inconsistent with the attribute value before writing, an object attribute update event is generated. The object attribute update event includes the object identifier of the target signal object and the identifier of the attribute item that was updated.

[0087] Specifically, this embodiment is based on the collaborative operation of the data access module, signal object dynamic management module, and end-to-end storage module in the system architecture of this application. The data access module receives data messages sent by the line condition simulation system, interface simulation system, maintenance terminal, etc., through a message queue, and has formed an original data record for each data message according to the implementation method. The original data record includes at least a time identifier and a data source identifier. The data source identifier is used to characterize the source and interface type of the data message, such as "interface simulation - train control center and centralized dispatching interface" or "interface simulation - train control center and computer interlocking interface".

[0088] In this embodiment, "interface mapping relationship" refers to a pre-established mapping set in the line condition data, used to establish a correspondence between fields, addresses, or tag numbers in different interface protocol messages and attribute items of signal objects, and also to indicate the set of interfaces involved in a certain signal object. This interface mapping relationship is generated and exported from the original line data and interface files pre-stored by the data verification system. The signal object dynamic management module directly reuses this mapping relationship at runtime, thus eliminating the need for additional configuration of parsing rules.

[0089] "Attribute mapping information" is a detailed entry in the interface mapping relationship, used to describe how specific fields in the message payload are transformed and written into specified attribute items of the target signal object, such as field offset, length, data type, enumeration value mapping or unit conversion rules, etc.

[0090] "Object attribute update event" refers to an event record generated when the new value written to a certain attribute item of a signal object is inconsistent with the old value. It is used to drive the triggering of subsequent state consistency supervision and logical verification. In this embodiment, the event content is fixed to include the object identifier of the target signal object and the identifier of the updated attribute item to ensure that the event semantics are clear and traceable.

[0091] In some examples, when the signal object dynamic management module receives a data message to be parsed from the data access module, it first reads the data source identifier in the original data record and determines the interface corresponding to the data message accordingly. For example, when the data source identifier indicates that the message comes from "Interface Simulation - Train Control Center and Dispatch Centralization Interface," the signal object dynamic management module classifies the message as data from the Train Control Center and Dispatch Centralization Interface; when the data source identifier indicates that the message comes from "Interface Simulation - Train Control Center and Computer Interlocking Interface," it classifies it as data from the Train Control Center and Computer Interlocking Interface. Subsequently, the signal object dynamic management module uses this interface as an index to search the interface mapping relationship, locates one or more target signal objects associated with this interface, and further reads the attribute item mapping information corresponding to each target signal object. This process enables the system to clearly define "which attribute items of which signal objects should be updated for a certain type of message from this interface."

[0092] After determining the target signal object and attribute mapping information, the signal object dynamic management module parses the message payload of the data message according to the attribute mapping information. In this embodiment, the parsing method is consistent with the aforementioned implementation method, and can adopt a combination of deserialization and field mapping: first, the message payload is deserialized according to the message structure specified in the interface file to obtain the message field set; then, the corresponding field values ​​are extracted from the field set according to the attribute mapping information, and the field values ​​are converted into attribute values ​​according to the enumeration mapping rules defined in the attribute mapping information.

[0093] For example, the track segment occupancy status byte stream sent by the interface simulation system, after deserialization, yields fields such as "segment identifier" and "occupancy status." Attribute mapping information can map the "occupancy status field value 0 / 1" to the attribute value "idle / occupied," and write it to the "occupancy status" attribute item of the corresponding track segment signal object. As another example, for low-frequency code sequence related fields of the track segment, attribute mapping information can convert the code sequence field into a predefined code sequence status value and write it to the "low-frequency code sequence" attribute item of the track segment signal object for subsequent script logic verification.

[0094] When writing at least one attribute value obtained from parsing into the attribute set of the target signal object, the signal object dynamic management module first reads the existing value of the target attribute item as the attribute value before writing, and then reads the value of the attribute item again as the attribute value after writing. To avoid meaningless triggering caused by instantaneous duplicate writing, this embodiment uses "the attribute value after writing is inconsistent with the attribute value before writing" as the update judgment condition. When an update is determined, the signal object dynamic management module generates an object attribute update event, which includes the object identifier of the target signal object and the identifier of the updated attribute item. This object attribute update event is then submitted to the subsequent dual verification module as a trigger input. Simultaneously, to ensure consistency in subsequent traceability, the signal object dynamic management module can also establish a correspondence between the object attribute update event and the timestamp of the original data record that generated the event, enabling subsequent alarms to be traced back to the specific message time point that triggered the update.

[0095] To illustrate with an example: When the interface simulation system sends a track section status message from the train control center to the scheduling center interface to the message queue, the signal object dynamic management module determines the interface type based on the data source identifier of the original data record and locates the "track section A" signal object and its "occupancy status" attribute mapping information in the interface mapping relationship. The module parses the message payload and obtains the attribute value "occupied," which is inconsistent with the previous attribute value "idle." Therefore, a new value is written, and an object attribute update event is generated. The event records the object identifier as "track section A" and the attribute item identifier as "occupancy status." This event then triggers the status consistency verification module to compare the status values ​​of "track section A" on multiple interfaces, such as the train control center and scheduling center interface, and the train control center and computer interlocking interface. It further triggers the logic consistency verification module to call the track section low-frequency logic script to complete the subsequent processing link.

[0096] Through the above implementation method, this embodiment utilizes the pre-established interface mapping relationship in the line condition data to achieve unified parsing and object attribute update management of multi-interface data messages. By connecting "data access - parsing update - verification trigger" into an event-driven link through object attribute update events, the accuracy and traceability of signal object attribute updates are improved, and the timeliness and processing efficiency of subsequent consistency supervision and logical verification are enhanced.

[0097] In some embodiments, the state values ​​of the corresponding signal objects at each interface are extracted from the original data records and compared. When the state values ​​are inconsistent, a state consistency alarm is generated, including:

[0098] The object identifier of the target signal object is determined based on the object attribute update event, and the set of interfaces associated with the target signal object is determined based on the interface mapping relationship of the target signal object;

[0099] For each interface in the interface set, obtain the status value corresponding to the object identifier based on the time identifier and data source identifier in the original data record;

[0100] The consistency of each state value obtained from the interface set is compared. If at least two state values ​​are different, a state consistency alarm is generated.

[0101] Associate state consistency alarms with object identifiers, interface sets, and inconsistent state values ​​for subsequent association processing.

[0102] Specifically, this embodiment is based on the collaborative operation of the signal object dynamic management module, the state consistency verification submodule, and the end-to-end storage module in the system architecture of this application. After completing data message parsing and signal object attribute updating, the signal object dynamic management module generates an object attribute update event when the attribute value changes, and sends the object attribute update event to the state consistency verification submodule in the dual verification module to drive the cross-interface consistency supervision process.

[0103] "State consistency" refers to the consistency of the same signal object's state values ​​reflected from different interface perspectives, or the fulfillment of predetermined consistency rules. In basic scenarios without introducing additional constraints, the consistency rule can be understood as the state values ​​corresponding to each interface should be the same. For interfaces with different protocol encodings, the consistency rule can also be given by a unified normalized mapping based on the interface mapping relationship in the line condition data, so that the state values ​​of each interface are converted into a unified state expression before comparison.

[0104] "Status consistency alarm" refers to an alarm record generated when the consistency comparison result indicates inconsistency. It is used to identify the signal object and the interface involved in the inconsistency, and to provide a basis for subsequent full-link associated storage and tracing.

[0105] In some examples, the state consistency verification submodule first receives an object attribute update event and reads the object identifier from the event to determine the target signal object. Subsequently, the state consistency verification submodule searches for the target signal object in the entire set of signal objects and reads the interface mapping relationship corresponding to the target signal object. In this embodiment, the interface mapping relationship is provided by the line condition data exported by the data verification system, which at least indicates the set of interfaces associated with the target signal object. For example, for track section signal objects, the interface set may include the interface between the train control center and the dispatching center, the interface between the train control center and the computer interlocking system, the interface between the train control center and the temporary speed limit server, and the interface between train control centers, etc.; for objects such as departure gates or block sections, the interface set may correspondingly include the interface set between the train control center and related equipment. Through this method, the system can automatically determine the cross-interface comparison range without manually configuring the association relationship between objects and interfaces one by one.

[0106] After determining the interface set, the state consistency verification submodule retrieves the state value corresponding to the object identifier from the original data record for each interface in the interface set. To ensure the temporal comparability of data from multiple interfaces, this embodiment combines the time identifier and data source identifier in the original data record for retrieval and filtering: the data source identifier is used to limit the interface source corresponding to the original data record, and the time identifier is used to limit the comparison time point or comparison time window corresponding to the object attribute update event.

[0107] For example, in one implementation, the state consistency verification submodule uses the timestamp corresponding to the trigger time of the object attribute update event as a benchmark, and selects the most recent original data record for each interface within a preset time window. In another implementation, if the original data record contains an interface-side message sequence number or period identifier, the corresponding record for each interface can be determined by combining the timestamp and the message sequence number. Subsequently, the state consistency verification submodule extracts the state field of the target signal object from the selected original data record according to the field mapping defined in the interface mapping relationship, and obtains a comparable state value according to a unified encoding rule.

[0108] For example, the occupancy of track sections in the interface between the train control center and the centralized dispatching may be represented by binary codes, while the occupancy in the interface between the train control center and the computer interlocking may be represented by enumerated codes. The status consistency verification submodule can convert different codes into unified status values ​​such as "occupancy / idle" based on the normalized mapping provided by the interface mapping relationship before comparison.

[0109] After obtaining the status values ​​corresponding to each interface in the interface set, the status consistency verification submodule performs a consistency comparison on each status value. When at least two status values ​​are different, a status consistency alarm is generated. In this embodiment, the status consistency alarm can record the object identifier, the set of interfaces involved, and the status values ​​corresponding to each interface to clarify the location and content of the inconsistency. Subsequently, the status consistency verification submodule associates the status consistency alarm with the object identifier, the set of interfaces, and the inconsistent status values, and submits this association information to the end-to-end storage module so that it can form a "data-object-alarm" association record together with the original data record, subsequent logical consistency alarms, and configurable rule identifiers.

[0110] To illustrate with an example: When the "Occupancy Status" attribute of "Track Section A" is updated and triggers an object attribute update event, the status consistency verification submodule reads the object identifier as "Track Section A" and determines the set of interfaces to be compared based on the interface mapping relationship. These interfaces include the train control center and dispatching center interfaces, as well as the train control center and computer interlocking interfaces. Using the time stamp of the object attribute update event as a benchmark, the verification submodule extracts the status value of "Track Section A" from the original data records corresponding to each interface. If the extraction results show that the status of the train control center and dispatching center interface is "Occupied," while the status of the train control center and computer interlocking interface is "Idle," then a discrepancy is determined, a status consistency alarm is generated, and the alarm is associated with the object identifier, the involved interfaces, and the two inconsistent status values ​​for subsequent storage, interface display, export, and other processing.

[0111] Through the above implementation method, this embodiment automatically determines the cross-interface comparison range based on the interface mapping relationship provided by the line condition data under the drive of object attribute change events, and uses the time identifier and data source identifier in the original data record to realize the comparable extraction of multiple interface status values, thereby enabling timely detection of abnormal situations where the cross-interface status of the same signal object is inconsistent, improving the coverage of cross-interface supervision and the traceability and location efficiency of alarm information.

[0112] In some embodiments, responding to an object attribute update event involves determining the object category of the signal object corresponding to the object attribute update event and the attribute item that has been updated, including:

[0113] Retrieve the object identifier and property item identifier from the object property update event;

[0114] The target signal object is retrieved based on the object identifier in the complete set of signal objects, and the object category corresponding to the target signal object is read.

[0115] In the attribute set of the target signal object, determine the attribute item that has been updated based on the attribute item identifier, and obtain the attribute name and the updated attribute value of the attribute item;

[0116] The object category and attribute name are output as rule trigger information, which is used to match the rule corresponding to the rule trigger information in the configurable rules and perform logical verification.

[0117] Specifically, this embodiment relies on the collaborative operation of the signal object dynamic management module, the configurable rule management module, and the logical consistency verification submodule in the system architecture of this application. After parsing the data message according to the interface mapping relationship and writing it into the signal object attribute set, the signal object dynamic management module generates an object attribute update event when it detects that the attribute value after writing is inconsistent with the attribute value before writing, and sends the object attribute update event to the dual verification module to drive subsequent rule matching and logical verification.

[0118] "Object category" is an abstract classification of signal object types, used to categorize different objects at the rule level, such as track sections, block sections, signals, departure gates, temporary speed limits, etc. In this embodiment of the application, the object category is determined by the signal object definition information provided by the track condition data and is written into the metadata of each signal object when the complete set of signal objects is established.

[0119] "Attribute item" refers to a specific field in the attribute set of a signal object, used to express a state or parameter of the object, such as the occupancy status of a track section, low-frequency code sequence, section direction and locking status of the departure gate, and the speed limit value and effective status of a temporary speed limit.

[0120] "Rule trigger information" is a set of key-value pairs used to trigger configurable rule matching. In this embodiment, object category and attribute name are used as rule trigger information to realize the mechanism of "automatically triggering corresponding rules when object attributes change", avoiding manual binding of rules to each object.

[0121] Upon receiving an object attribute update event, the logical consistency verification submodule first retrieves the object identifier and attribute item identifier from the event. The object identifier uniquely locates the target signal object within the entire set of signal objects; the attribute item identifier uniquely locates the updated attribute item within the target signal object's attribute set. In one implementation, the object identifier is the object number or object code defined in the line condition data; the attribute item identifier is the field identifier or field index within the attribute set, and the correspondence between the attribute item identifier and the attribute name is pre-configured in the signal object definition information.

[0122] Subsequently, the logical consistency verification submodule performs a search based on the object identifier in the complete set of signal objects to obtain the target signal object corresponding to the object identifier, and reads the object category corresponding to the target signal object. Since the complete set of signal objects in this embodiment is established from line condition data, the target signal object in the complete set not only includes the object category, but also includes attribute sets and interface mapping relationships, etc. Therefore, reading the object category can directly reflect which type of signal object the object belongs to, and can be used for subsequent rule filtering.

[0123] Next, the logical consistency verification submodule determines the updated attribute item in the attribute set of the target signal object based on the attribute item identifier, and obtains the attribute name and updated attribute value of that attribute item. The attribute name is used to characterize the semantic name of the attribute item at the rule level, such as "occupancy status", "low-frequency code sequence", "interval direction", "locked status", "speed limit value", etc.; the updated attribute value is used as one of the input data for subsequent rule verification. In some implementations, to ensure the interpretability and traceability of rule execution, the logical consistency verification submodule can also form an "attribute change snapshot" together with the attribute name, the updated attribute value, and the object identifier, and pass this snapshot to the configurable rule management module or the rule matching process within the logical consistency verification submodule.

[0124] Subsequently, the object category and attribute name are output as rule trigger information, used to match the rules corresponding to the trigger information in the configurable rules and perform logical verification. For example, the configurable rules adopt the form of scripted rules. The rule management module has a built-in basic script library for multiple types of signal objects and supports users to edit custom script rules in the system interface. Each script rule is configured with trigger conditions, which at least include the applicable object category and the trigger attribute name, so that when a specific attribute under a certain object category changes, the corresponding script can be automatically triggered to execute.

[0125] For example, when the "occupancy status" of a track section object changes, the rule trigger information can be "track section + occupancy status," and the rule management module can match the low-frequency logic script for the track section. When the "section direction" of a departure gate object changes, the rule trigger information can be "departure gate + section direction," and the rule management module can match the logic verification script related to the change of direction and locking. When the "speed limit status" of a temporary speed limit object changes, the rule trigger information can be "temporary speed limit + speed limit status," and the rule management module can match the consistency and logic verification script related to the temporary speed limit. In the second method scenario, if the user has configured custom scripts with the same trigger condition in the custom script directory, the rule management module can prioritize returning the custom script as the target rule, thereby achieving rapid adaptation to test scenarios such as special line layouts or disaster simulations.

[0126] To illustrate with an example: The interface simulation system sends a message involving "track section A". After parsing, the "low-frequency code sequence" attribute of "track section A" changes from one tracking code sequence to another. The signal object dynamic management module generates an object attribute update event, which includes the object identifier "track section A" and the attribute item identifier corresponding to "low-frequency code sequence". After receiving this event, the logic consistency verification submodule retrieves the target signal object category "track section" from the entire set of signal objects, determines the attribute name as "low-frequency code sequence" from the attribute set, and the updated attribute value as the new code sequence. Subsequently, it outputs the rule trigger information "track section + low-frequency code sequence". The rule management module matches this information to the low-frequency logic script of the track section, and enters the subsequent script execution and logic consistency verification process. For another example, when the maintenance terminal triggers a section direction switch, causing the "section direction" attribute of "departure point B" to be updated, the system outputs the rule trigger information "departure point + section direction", thereby triggering the execution of script rules related to section locking and change conditions.

[0127] Through the above implementation method, this embodiment abstracts the change of object attributes into rule triggering information composed of object category and attribute name, and realizes the automatic generation of triggering information based on the retrieval of the entire set of signal objects and the location of attribute items. This enables rule matching and logic verification to be automatically triggered as the signal object attributes change and accurately locate the corresponding rule, reducing the dependence on manual configuration, improving the accuracy of rule triggering and the system's adaptability to multiple scenarios and multiple objects, and providing clear and traceable input basis for subsequent script verification.

[0128] In some embodiments, configurable rules matching the object category and attribute items are invoked to validate the attribute relationship between the signal object and at least one associated signal object. A logical consistency alarm is generated when the configurable rules are not met, including:

[0129] Based on the rule triggering information, the target configurable rule with the same triggering condition as the rule triggering information is retrieved from the configurable rule base. The target configurable rule is a script rule, and the script rule has a rule identifier.

[0130] Based on the preset object association relationships in the target configurable rules, at least one associated signal object that has a logical association with the signal object is determined from the line condition data, and the attribute data corresponding to the signal object and at least one associated signal object is obtained as rule input data.

[0131] The script execution engine is invoked to load and execute script rules, and the input data based on the rules is output as the validation result.

[0132] When the verification result indicates that the attribute relationship does not meet the script rules, a logical consistency alarm is generated.

[0133] Specifically, the "configurable rule base" is a logical collection used to centrally store rules. It includes at least two parts: a built-in rule base and a custom rule base, and stores metadata such as the triggering conditions, rule identifier, script content, and input / output conventions for each rule.

[0134] "Script rules" are logical verification rules expressed in script form, which can be interpreted and executed by a script execution engine. Script rules can contain structures such as conditional judgments, loops, and function calls to support the expression of complex logical relationships.

[0135] "Rule ID" is a unique identifier for script rules, used to locate the specific rule that is triggered during alarm, storage, and tracing processes.

[0136] "Object association" refers to the object dependencies that are declared or implied in the script rules. It is used to indicate which associated signal objects and their attribute data need to be referenced when verifying the attribute relationships of a certain signal object, such as adjacent track sections, associated signals, associated block sections, associated departure gates, temporary speed limit objects, etc.

[0137] "Rule input data" is a structured data set provided to the script rules. It includes at least the attribute data of the signal object and the attribute data of the associated signal object, and may carry necessary contextual information such as line, station, and time identifiers to ensure that the script can complete the judgment under a unified semantics.

[0138] In some examples, the logical consistency verification submodule first performs a search in the configurable rule base based on the rule triggering information to obtain target configurable rules whose triggering conditions match the rule triggering information. In the aforementioned embodiments, the rule triggering information consists of object category and attribute name. The triggering conditions of the target configurable rule at least include the corresponding object category and triggering attribute name, thus enabling one-to-one or one-to-many matching in the rule base.

[0139] For example, in one implementation, if matching rules exist in both the custom rule base and the built-in rule base, the rule management module can be configured to prioritize returning the custom rule to meet the complex scenario adaptation requirements described in Method 2. In another implementation, the rule management module can also be configured to select and return the rule with higher priority based on the rule priority field. After the search is completed, the target configurable rule is determined to be a script rule, and the rule identifier and script content corresponding to the script rule are read for subsequent execution.

[0140] Subsequently, the logical consistency verification submodule, based on the preset object association relationships in the target configurable rules, determines at least one associated signal object logically related to the signal object from the line condition data, and obtains the attribute data corresponding to the signal object and at least one associated signal object as rule input data. Here, the line condition data, derived from the data verification system in this embodiment, includes information such as the complete set of signal objects, station topology relationships, and interface mapping relationships, and therefore can be used to determine the "set of associated objects."

[0141] For example, the track section logic verification script can declare the need for associated objects such as "adjacent section," "rear section," and "corresponding direction protection signal" in the object association relationship; the departure gate reversal and locking logic script can declare the need for "section direction object," "section locking status object," and "related blockage zone" as associated objects; the disaster scenario or foreign object intrusion logic script can declare the need for "blockage zone," "foreign object intrusion status," and "related signal display" as associated objects. Based on this, the logic consistency verification submodule locates the associated signal objects from the complete set of signal objects and further extracts the specified attribute values ​​of each object, assembling them into rule input data. In some implementations, the rule input data can also include a timestamp provided by the original data record to ensure that the data referenced by the script belongs to a snapshot of data within the same time window, thereby avoiding misjudgment caused by mixing data across periods.

[0142] Furthermore, after assembling the rule input data, the logical consistency verification submodule calls the script execution engine to load and execute the script rules. In this embodiment, the script execution engine is a script interpretation and execution environment, capable of injecting the rule input data into the script execution context, executing the script line by line or by function entry point, and outputting the verification results. The verification results can be in the form of a combination of Boolean judgments and descriptive information, such as outputting "pass / fail" and a corresponding description of the conflict reason; or they can output preset error codes or alarm type identifiers for subsequent alarm classification and processing. If the verification result indicates that the attribute relationship does not meet the script rules, the logical consistency verification submodule generates a logical consistency alarm and submits the logical consistency alarm to the end-to-end storage and output module for subsequent associated storage, interface display, feedback, and export processing.

[0143] To illustrate with an example: In the basic scenario of Method 1, when the occupancy status of "track section A" is updated, the system generates rule trigger information "track section + occupancy status" and matches it with the "track section low-frequency logic script" in the configurable rule library as the target configurable rule. This script pre-determines the required associated objects such as "adjacent section behind track section A" and "related signal display status" in the object association relationship. Based on this, the logic consistency verification submodule determines the adjacent section behind track section B from the line condition data, and obtains attribute data such as the occupancy status of track section A, the occupancy status of track section B, and the display status of the protective signal to form the rule input data, which is then injected into the script execution engine for execution.

[0144] The script judges the relationship between low-frequency code sequence, occupancy status, and signal display based on preset logic. If the script outputs that the predetermined code sequence rule is not met after the occupancy section, the verification result is a failure, and the system generates a logical consistency alarm. For example, in the complex scenario of Method Two, the user edits the "Blocking Section Foreign Object Intrusion Linkage Script" through the system interface and sets the trigger condition to "Blocking Section + Foreign Object Intrusion Status". When the foreign object intrusion status attribute of the blocking section object is updated, the system first retrieves this custom script as the target rule, further extracts the associated signal and adjacent blocking section attributes from the line condition data as input, executes the script, and generates a logical consistency alarm if the linkage logic is not met.

[0145] Through the above implementation, this embodiment realizes rapid script rule retrieval based on rule trigger information, automatic determination of associated objects based on line condition data and assembly of input data, and verification of complex logical relationships based on script execution engine, thereby improving the ability to identify complex logical anomalies and the efficiency of rule adaptation, and enabling logical consistency alarms to clearly identify the corresponding trigger scenarios and verification links, thereby improving the efficiency of subsequent tracing and location.

[0146] The implementation process and principles of the technical solution of this application are explained below with examples in specific scenarios. This application provides three typical implementable methods, covering three core scenarios: "basic full interface supervision," "complex logic custom verification," and "dynamic scenario adaptation." Each method is based on a unified system architecture, differing only in the emphasis on rule configuration, object management, and verification logic. All steps can be implemented using existing technologies.

[0147] Method 1: Dual Supervision Method for Basic Full-Interface Signal Objects (Core General Scenarios)

[0148] (a) The system / device and relationships on which computer programs operate

[0149] 1. System Components

[0150] Core modules: Data access module (integrated RabbitMQ message stack), Lua script rule management module (built-in preset script library), signal object dynamic management module, dual verification module (state consistency verification submodule + logical consistency verification submodule), end-to-end storage module, and data output module;

[0151] External associated devices: line condition simulation system, interface simulation system, maintenance terminal, data verification system (with pre-stored original line data and interface files provided by the design institute, generating line condition data), SQL Server 2008 R2 database;

[0152] Hardware requirements: PC with a 64-bit x86 CPU with a clock speed of 1.6GHz or higher, 4GB or more of RAM, and 20GB or more of hard drive space;

[0153] Software environment: Windows 7 or later operating system, .NET Framework 4.8, Lua script execution engine, RabbitMQ client.

[0154] 2. Relationship between the module and external devices

[0155] The data access module subscribes to the message queues of the line condition simulation system, interface simulation system, maintenance terminal, and data verification system through the RabbitMQ message queue to receive interface data from all sources in real time.

[0156] The Lua script rule management module has built-in basic verification scripts for 14 types of signal objects. No manual association is required, and the corresponding scripts can be automatically triggered according to changes in the attributes of the signal objects.

[0157] The signal object dynamic management module receives the data to be parsed from the data access module and directly reuses the line condition data (including the complete set of signal objects and attribute mapping) from the data verification system, without having to generate the basic objects again.

[0158] The alarm results of the dual verification module are synchronized to the data output module (interface display, reverse feedback) and the end-to-end storage module;

[0159] The end-to-end storage module establishes a connection with the SQL Server database to achieve persistent data storage (automatically associates data without requiring additional configuration of association rules).

[0160] (ii) Necessary configurations before program execution

[0161] 1. RabbitMQ Configuration: Create three dedicated message queues in the RabbitMQ server (corresponding to line condition simulation, interface simulation, and maintenance terminal respectively), configure the message persistence strategy of the queues (to avoid data loss), and set the queue subscription permissions of the data access module;

[0162] 2. Storage Configuration: Configure database connection parameters (IP, port, username, password) in the end-to-end storage module. The system defaults to enabling the "automatic data association" mechanism (automatically associating interface data, object data, script rules, and alarm information by signal object ID, timestamp, and rule ID).

[0163] 3. Data verification system linkage configuration: Confirm that the data verification system has exported the line condition data (including the basic attributes and interface mapping relationships of signal objects such as track sections and signal lights), and the system will automatically load this data as the supervision benchmark.

[0164] (III) Detailed Implementation Steps

[0165] 1. Data access and preprocessing (automatically executed after program startup)

[0166] Step 1.1: The data access module starts the RabbitMQ client, subscribes to the three preset message queues, and starts the message listening mode;

[0167] Step 1.2: When external devices such as the line condition simulation system and the interface simulation system generate data, they send byte stream data through their respective queues (e.g., the interface simulation system sends the track section occupancy data byte stream of the TCC-CTC interface).

[0168] Step 1.3: After receiving the message, the data access module automatically adds a timestamp (accurate to milliseconds) and a data source identifier (such as "interface simulation-TCC-CTC"), and forwards the raw data to the end-to-end storage module for temporary caching. At the same time, it distributes the data to be parsed to the signal object dynamic management module.

[0169] 2. Associating and updating signal object attributes

[0170] Step 2.1: The signal object dynamic management module receives the data to be parsed and directly reuses the line condition data provided by the data verification system (which already contains the complete set of signal objects and attribute mapping).

[0171] Step 2.2: Convert the byte stream data to be parsed into the attribute values ​​of specific signal objects using deserialization technology (no additional parsing rules need to be configured, relying on the interface file mapping relationship provided by the data verification system).

[0172] Step 2.3: Monitor attribute changes in real time (such as the track section occupancy status changing from "idle" to "occupied", or the addition of a temporary speed limit command), automatically update the attributes of the corresponding signal object, and trigger the associated script in the Lua script rule management module.

[0173] 3. Double verification execution (automatically triggered by built-in script)

[0174] Step 3.1: The state consistency verification submodule responds to the update of the signal object attributes and automatically extracts all interfaces involved in the object (based on the interface mapping relationship in the line condition data).

[0175] Call the interface status retrieval function to obtain the object's status value (such as "occupied" or "idle") for each interface;

[0176] If any inconsistencies are found when comparing all status values ​​(e.g., the TCC-TCC interface displays "occupied" while the TCC-CBI interface displays "idle"), an alarm message (including object ID, involved interface, and status difference) is generated, and the alarm type is marked as "status inconsistency anomaly".

[0177] Step 3.2: The logical consistency verification submodule automatically calls the corresponding verification script in the built-in Lua script library based on the changes in the signal object's attributes.

[0178] Taking the low-frequency code sequence verification of track sections as an example: After the track section occupancy status is updated, the "track section low-frequency logic script" is automatically triggered. The script is input with the occupancy status of the track section, the status of adjacent sections, and the signal display status (all extracted from the line condition data).

[0179] The Lua script execution engine runs the script to determine whether the low-frequency code conforms to the logic of "sending HU code after the occupied segment" and "sending code in the tracking code sequence in the idle segment";

[0180] If the logic is not met (e.g., no HU code is issued after the occupied section), an alarm message is generated (including object ID, trigger script name, and logical conflict description), and the alarm type is marked as "Logical Consistency Anomaly".

[0181] 4. End-to-end storage and data output

[0182] Step 4.1: The end-to-end storage module receives the verified signal object data and alarm information, associates them with the corresponding original interface data (timestamp + data source identifier) ​​and built-in Lua script (trigger script name) according to the system's default automatic association mechanism, and stores them in the SQL Server database;

[0183] Step 4.2: The data output module displays the alarm information in real time on the system interface (including device type, station, involved interface, and alarm description).

[0184] Step 4.3: Feedback the alarm information back to the line condition simulation system via RabbitMQ message queue so that it can adjust the simulation strategy;

[0185] Step 4.4: Support users to trigger Excel export operations. The data output module extracts alarm information for a specified time period from the database and generates an Excel file in the format of "alarm time-object type-device name-alarm type-alarm content".

[0186] Method 2: Custom Complex Logic Validation Method in Lua Script (Adapted for Complex Scenarios)

[0187] (a) Applicable Scenarios

[0188] It is suitable for scenarios that require the addition of complex logic rules, such as special line layouts (e.g., stations with multiple branch lines, sections without junction stations) and customized testing needs (e.g., disaster scenario simulation verification) (built-in scripts cannot cover these scenarios).

[0189] (ii) Dependent systems / devices and relationships

[0190] Completely identical to Method 1, except that a "Custom Script Editing Submodule" (including a Lua syntax checking plugin) has been added to the Lua script rule management module, allowing users to add scripts and automatically associate them with signal object properties.

[0191] (III) Pre-run configuration (new / differentiated configuration)

[0192] 1. In addition to the basic configuration of Method 1, enable "Custom Edit Mode" in the Lua script rule management module to support complex syntax such as loops, conditional statements, and nested functions;

[0193] 2. Customize Lua script rules for system interface editing;

[0194] 3. Verify the script using the syntax checker plugin, correct syntax errors, save it to the "Custom Script Directory", and set script trigger conditions (such as automatically triggering when the "Obstruction Partition - Foreign Object Intrusion Status" attribute changes).

[0195] (iv) Detailed implementation steps (differentiated steps)

[0196] Steps 1-2: Completely consistent with Method 1 (data access, signal object attribute association and update);

[0197] Step 3: Complex logic verification execution (core differentiation);

[0198] Step 3.1: The signal object dynamic management module detects the change in the "foreign object intrusion status" attribute of the block section, automatically identifies the triggering conditions, and prioritizes calling the custom scripts in the "custom script directory";

[0199] Step 3.2: The Lua script execution engine parses the script, automatically extracts the associated signal object data from the line condition data, and inputs it into the script for execution verification;

[0200] Step 3.3: Execute the script line by line and output the verification results;

[0201] Step 3.4: If the verification fails, generate an alarm message containing a "custom script identifier" and synchronize it to the storage and output modules;

[0202] Step 4: Completely consistent with Method 1 (storage and output).

[0203] Method 3: Dynamic Scene Adaptation Supervision Method (Signal Object Temporarily Changes Scene)

[0204] (a) Applicable Scenarios

[0205] It is suitable for dynamic scenarios such as frequent changes in temporary speed limit orders, frequent switching of section direction, and addition / deletion of signal objects (e.g., line modification testing, temporary construction supervision).

[0206] (ii) Dependent systems / devices and relationships

[0207] Similar to Method 1, only a new "Object Change Monitoring Submodule" has been added to the Signal Object Dynamic Management module, which can capture the addition of signal objects / attribute changes in line condition data in real time.

[0208] (III) Pre-run configuration (new / differentiated configuration)

[0209] 1. Enable the "Dynamic Object Auto-Adaptation" function: Set the trigger threshold for adding / changing signal objects (e.g., "Add Temporary Speed ​​Limit Command → Automatically Create Temporary Speed ​​Limit Signal Object").

[0210] 2. Configure a custom script auto-matching strategy: When a new signal object is added, the system automatically matches the associated script in the built-in script library (such as the "temporary rate limit status consistency script") according to the object type (such as "temporary rate limit"), without the need for manual binding.

[0211] (iv) Detailed implementation steps (differentiated steps)

[0212] Step 1: Data access and dynamic triggering;

[0213] Steps 1.1-1.2: Consistent with Method 1;

[0214] Step 1.3: After receiving dynamic data such as "temporary rate limit command", the data access module synchronizes it to the object change monitoring submodule to trigger the dynamic adaptation process.

[0215] Step 2: Dynamic update of signal objects (core differentiation)

[0216] Step 2.1: The object change monitoring submodule receives the trigger signal, synchronizes the latest line condition data from the data verification system, and updates the signal object.

[0217] New scenario: Automatically create temporary speed limit signal objects, reuse basic attributes such as lines, stations, and mileage markers in the data verification system, and assign unique IDs;

[0218] Change scenario: Update the "section direction" and "locking status" attributes of the departure gate signal object and synchronize the associated interface mapping relationship;

[0219] Step 2.2: The system automatically matches script rules: After adding a temporary rate limit object, the built-in "Temporary Rate Limit Status Consistency Script" is automatically triggered; after the attribute is changed, the corresponding logic verification script is automatically triggered.

[0220] Steps 3-4: Same as Method 1 (double verification, storage and output).

[0221] IV. Relevant Supplementary Explanations

[0222] 1. System architecture for program execution

[0223] The program operation system architecture of this application adopts a layered and modular design, which is divided into four major layers: "data access layer, core processing layer, storage layer, and output layer". Each layer interacts through standardized interfaces, relies on RabbitMQ message queue to realize data flow, and combines Lua script engine to realize dynamic rule adaptation, thus building a stable, efficient and scalable rail transit signal interface supervision system.

[0224] 2. Core Module Functions of the Program

[0225] External input devices: line condition simulation system, interface simulation system, maintenance terminal, data verification system;

[0226] Core Adaptation: The data verification system provides line condition data, avoiding repeated import of parsing rules; the Lua script rule management module automatically associates signal object attributes, eliminating the need for manual configuration.

[0227] This application, through its core technical solution of "RabbitMQ full-interface data access, Lua script automatic association verification, dynamic object management, and full-link associated storage," systematically addresses the core deficiencies of existing technologies from five dimensions: interface coverage, adaptation flexibility, supervision accuracy, dynamic response, and fault tracing. This results in significant technical advantages, as detailed below:

[0228] 1. Synchronized access to all interfaces completely resolves the issue of "incomplete interface coverage".

[0229] Technical effect: It realizes the synchronous acquisition of data from all key interfaces of the rail transit train control system, including TCC-TCC, TCC-CBI, TCC-CTC, TCC-TSRS, TCC-TC, TCC-LEU, and TCC-IO, with an interface coverage rate of 100%, completely avoiding the omission of cross-interface signal object status inconsistencies.

[0230] The underlying principle is based on the RabbitMQ message stack's publish-subscribe mechanism. It does not require binding to a specific physical communication method and can uniformly receive data from all sources, including line condition simulation, interface simulation, maintenance terminals, and data verification systems. The data access latency is controlled within 5ms, ensuring the synchronization and integrity of data from multiple interfaces.

[0231] Comparative advantages: Compared with the limitations of existing technologies that only cover 3-5 core interfaces, this solution achieves "no dead angle" interface coverage and improves the cross-interface anomaly recognition rate by more than 80% (for example, if there is a state conflict between the TCC-CTC and TCC-CBI interfaces in the track section, the existing technology has a false detection rate of more than 60%, while this solution can identify 100%).

[0232] 2. Lua scripting rule configuration significantly improves adaptability and versatility.

[0233] Technical benefits: It allows users to directly edit, modify, enable / disable supervision rules in the system interface without modifying the core system code. It is compatible with CTCS-2 / 3 level train control systems, different station layouts, disaster simulations and other diverse scenarios. The rule update effective time is ≤3s, and the maintenance cost is reduced by at least 70%.

[0234] Underlying principles: It has a built-in Lua script library with 14 core signal objects, and also supports the writing of custom scripts with complex logic (including loops, conditional statements, and nested functions). The scripts are automatically associated with changes in the properties of the signal objects and are triggered automatically, without the need for manual binding and configuration.

[0235] Comparative advantages: Existing technical rules are fixed, and adapting to new scenarios requires redeveloping code (with a cycle of 1-2 weeks). This solution uses Lua scripts for rapid adaptation, shortening the adaptation cycle to 1-2 hours and significantly improving versatility.

[0236] 3. The "dual verification" system significantly improves the accuracy of anomaly detection.

[0237] Technical results: The dual system of "cross-interface state consistency verification + signal object logical correlation verification" can not only identify simple state conflicts, but also accurately capture complex logical errors, and the overall anomaly identification accuracy is greatly improved compared with the original manual identification.

[0238] The underlying principle is that the state consistency verification module automatically compares the state values ​​of the same signal object across multiple interfaces, while the logic consistency verification module executes refined rule verification through Lua scripts (such as low-frequency code sequence in track sections, signal wire breakage protection, and linkage in foreign object disaster scenarios). The dual verification collaboratively covers both "simple anomalies" and "complex anomalies".

[0239] Comparative advantages: Existing technologies can only identify single-dimensional anomalies (state conflicts or simple logical errors), and the recognition rate of complex logical errors is less than 30%. This solution can fully cover the complex logical rules of core objects such as track sections, block sections, signals, and departure gates, and supports manual supplementary configuration.

[0240] 4. Dynamic object management completely avoids "observation omissions".

[0241] Technical effect: The complete set of signal objects is dynamically generated / updated based on interface data, automatically adapting to dynamic scenarios such as the addition of temporary speed limits, switching of interval directions, and addition or removal of signal objects, and the supervision of "observation coverage" can be effectively maintained.

[0242] The underlying principle is to reuse the line condition data (including basic attributes and interface mappings of signal objects) pre-stored in the data verification system, and update the interface data to the corresponding signal objects in real time through deserialization technology. When a new signal object is added, the associated script rules are automatically matched without manual intervention.

[0243] Advantages: Existing technologies require pre-defining a fixed set of signal objects, and there may be omissions of observation items in dynamic scenarios (such as temporary speed limit commands not being included in supervision after being added). This solution dynamically adapts without omissions, ensuring comprehensive supervision.

[0244] 5. End-to-end associative storage significantly improves the efficiency of fault tracing and location.

[0245] Technical benefits: By establishing a full-link association index of "raw interface data - signal object - Lua script rule - alarm information", the original data, triggering rules and associated objects corresponding to the anomaly can be quickly located during fault tracing, and the fault location time is shortened from 1-2 hours to less than 5 minutes.

[0246] Supporting principle: Automatically associates timestamps, signal object IDs, rule IDs, and data source identifiers during storage, eliminating the need for additional association rules. The SQL Server database supports reverse tracing of all associated data based on alarm information, with a data query response time of ≤1 second.

[0247] Advantages: Existing technologies store data independently, and fault tracing requires manual verification across modules (inefficient and prone to errors). This application achieves "one-click tracing" through end-to-end association, improving fault handling efficiency by more than 90%.

[0248] 6. Lightweight architecture design, balancing operational stability and ease of use.

[0249] Technical Performance: The system is developed based on the Windows operating system and .NET Framework 4.8, with low hardware requirements (a CPU with a main frequency of 1.6GHz or higher and 4GB of memory are sufficient to run it). It can run continuously for 72 hours without any lag or data loss, and the system stability reaches 99.9%. The user interface is visual and can be operated without professional programming knowledge to complete operations such as rule configuration and data export.

[0250] Supporting principles: Modular design reduces coupling between modules; RabbitMQ message queue enables asynchronous data processing to avoid data congestion; end-to-end storage module adopts data compression and index optimization to reduce storage overhead (data storage of a single alarm-related data ≤ 5KB).

[0251] Advantages: Existing monitoring systems have high hardware requirements (requiring server-level configuration) and complex operation (requiring professional personnel for maintenance). This solution's lightweight design is more suitable for laboratory testing and on-site operation and maintenance scenarios, and its ease of use is significantly improved.

[0252] In summary, this application, through targeted technical design, has achieved significant breakthroughs in interface coverage, adaptability flexibility, anomaly identification accuracy, dynamic response capability, and fault tracing efficiency, effectively solving the core defects of existing technologies and providing a more reliable, efficient, and flexible monitoring solution for the safe operation of rail transit signaling systems.

[0253] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0254] Figure 2 This is a schematic diagram of the structure of the rail transit full-interface signal object consistency supervision and logic verification device provided in the embodiments of this application. Figure 2 As shown, the rail transit full-interface signal object consistency monitoring and logic verification device includes:

[0255] The receiving module 201 is used to receive data messages from multiple interfaces of the rail transit signaling system through a message queue, and to encapsulate the data messages in a unified manner to obtain the original data record containing time identifier and data source identifier;

[0256] Module 202 is used to establish a complete set of signal objects based on pre-configured line condition data. The complete set of signal objects includes multiple signal objects and the object identifier, object category, attribute set and interface mapping relationship corresponding to each signal object.

[0257] The parsing module 203 is used to parse the data message according to the interface mapping relationship, write the parsed attribute values ​​into the attribute set of the corresponding signal object, and generate an object attribute update event when the attribute values ​​are updated.

[0258] The comparison module 204 is used to respond to object attribute update events, determine at least two interfaces associated with the corresponding signal object through the interface mapping relationship, extract the status values ​​of the corresponding signal object in each interface from the original data record and compare them, and generate a status consistency alarm when the status values ​​are inconsistent.

[0259] The verification module 205 is used to respond to object attribute update events, determine the object category of the signal object corresponding to the object attribute update event and the updated attribute item, call the configurable rules that match the object category and attribute item, verify the attribute relationship between the signal object and at least one associated signal object, and generate a logical consistency alarm when the configurable rules are not met.

[0260] The association module 206 is used to associate the original data records, the attribute data of the signal objects, the configurable rule identifiers, and the status consistency alarms and / or logical consistency alarms to form an association record and store it.

[0261] In some embodiments, Figure 2 When the receiving module 201 receives a data message through the message queue, it obtains the receiving time of the data message and generates a time identifier corresponding to the receiving time; it determines the data source identifier corresponding to the data message based on the message queue to which the data message belongs and / or the interface identifier information carried by the data message; it combines the time identifier, the data source identifier and the message payload of the data message to generate the original data record, and writes the original data record into the cache storage area for subsequent retrieval and association.

[0262] In some embodiments, Figure 2The establishment module 202 generates multiple signal objects based on the signal object definition information, and configures an object identifier, object category, and attribute set for each signal object to carry the object attribute values; based on the mapping information, it establishes an interface mapping relationship for each signal object, which is used to indicate the set of interfaces associated with the signal object, and to map fields in the data message to corresponding attribute items in the attribute set; multiple signal objects and their corresponding interface mapping relationships are written into the complete set of signal objects for parsing the data message and subsequent consistency supervision and logical verification calls.

[0263] In some embodiments, Figure 2 The parsing module 203 determines the interface corresponding to the data message based on the data source identifier in the original data record, and determines the target signal object and the attribute item mapping information corresponding to the target signal object in the interface mapping relationship based on the interface; it parses the message payload of the data message according to the attribute item mapping information to obtain at least one attribute value corresponding to the attribute item mapping information; it writes at least one attribute value into the attribute set of the target signal object corresponding to the attribute item mapping information, and obtains the attribute value after writing and the attribute value before writing; when the attribute value after writing is inconsistent with the attribute value before writing, it generates an object attribute update event, which includes the object identifier of the target signal object and the identifier of the updated attribute item.

[0264] In some embodiments, Figure 2 The comparison module 204 determines the object identifier of the target signal object based on the object attribute update event, and determines the set of interfaces associated with the target signal object based on the interface mapping relationship of the target signal object; for each interface in the interface set, it obtains the status value corresponding to the object identifier based on the time identifier and data source identifier in the original data record; it performs a consistency comparison on each status value obtained in the interface set, and generates a status consistency alarm if at least two status values ​​are different; it associates the status consistency alarm with the object identifier, the interface set, and the inconsistent status values ​​for subsequent association processing.

[0265] In some embodiments, Figure 2 The verification module 205 obtains the object identifier and attribute item identifier from the object attribute update event; retrieves the target signal object based on the object identifier in the complete set of signal objects, and reads the object category corresponding to the target signal object; determines the updated attribute item based on the attribute item identifier in the attribute set of the target signal object, and obtains the attribute name and updated attribute value of the attribute item; outputs the object category and attribute name as rule trigger information, which is used to match the rule corresponding to the rule trigger information in the configurable rules and perform logical verification.

[0266] In some embodiments, Figure 2 The verification module 205, based on rule triggering information, retrieves target configurable rules from the configurable rule base whose triggering conditions match the rule triggering information. The target configurable rules are script rules, and script rules have rule identifiers. According to the preset object association relationships in the target configurable rules, it determines at least one associated signal object that has a logical association with the signal object from the line condition data, and obtains the attribute data corresponding to the signal object and at least one associated signal object as rule input data. It calls the script execution engine to load and execute the script rule, and outputs the verification result based on the rule input data. When the verification result indicates that the attribute relationship does not meet the script rule, a logical consistency alarm is generated.

[0267] Figure 3 This is a schematic diagram of the electronic device 3 provided in an embodiment of this application. Figure 3 As shown, the electronic device 3 of this embodiment includes: a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, it implements the steps in the various method embodiments described above. Alternatively, when the processor 301 executes the computer program 303, it implements the functions of each module / unit in the various device embodiments described above.

[0268] Electronic device 3 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 3 may include, but is not limited to, processor 301 and memory 302. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or different components.

[0269] The processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0270] The memory 302 can be an internal storage unit of the electronic device 3, such as a hard disk or memory of the electronic device 3. The memory 302 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 3. The memory 302 can also include both internal and external storage units of the electronic device 3. The memory 302 is used to store computer programs and other programs and data required by the electronic device.

[0271] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0272] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a readable storage medium (e.g., a computer-readable storage medium). Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which may be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable storage medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0273] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for consistency supervision and logical verification of all interface signal objects in rail transit, characterized in that, include: The system receives data messages from multiple interfaces of the rail transit signaling system via a message queue, and encapsulates the data messages in a unified manner to obtain raw data records containing time identifiers and data source identifiers. A complete set of signal objects is established based on pre-configured line condition data. The complete set of signal objects includes multiple signal objects and the object identifier, object category, attribute set and interface mapping relationship corresponding to each signal object. The data message is parsed according to the interface mapping relationship, the parsed attribute values ​​are written into the attribute set of the corresponding signal object, and an object attribute update event is generated when the attribute value is updated. Respond to object attribute update events, determine at least two interfaces associated with the corresponding signal object through interface mapping relationship, extract the status value of the corresponding signal object in each interface from the original data record and compare them, and generate a status consistency alarm when the status values ​​are inconsistent. In response to an object attribute update event, determine the object category of the signal object corresponding to the object attribute update event and the updated attribute item, call the configurable rule matching the object category and attribute item, verify the attribute relationship between the signal object and at least one associated signal object, and generate a logical consistency alarm when the configurable rule is not met. Associate the original data records, the attribute data of the signal objects, the configurable rule identifiers, and the status consistency alarms and / or logical consistency alarms to form an associated record and store it; The process of calling configurable rules that match the object category and attribute items to verify the attribute relationship between the signal object and at least one associated signal object, and generating a logical consistency alarm when the configurable rules are not met, includes: Based on the rule triggering information, a target configurable rule whose triggering condition is consistent with the rule triggering information is retrieved from the configurable rule base. The target configurable rule is a script rule, and the script rule has a rule identifier. Based on the preset object association relationship in the target configurable rule, at least one associated signal object that has a logical association with the signal object is determined from the line condition data, and the attribute data corresponding to the signal object and the at least one associated signal object is obtained as rule input data. The script execution engine is invoked to load and execute the script rules, and the input data is output based on the rules to determine the verification results. When the verification result indicates that the attribute relationship does not meet the script rule, a logical consistency alarm is generated.

2. The method according to claim 1, characterized in that, The process of uniformly encapsulating data messages to obtain raw data records containing time identifiers and data source identifiers includes: When a data message is received through the message queue, the receiving time of the data message is obtained and a time stamp corresponding to the receiving time is generated; Determine the data source identifier corresponding to the data message based on the message queue to which the data message belongs and / or the interface identifier information carried by the data message; The time stamp, data source stamp, and message payload of the data message are combined to generate the original data record, which is then written to the cache storage area for subsequent retrieval and association.

3. The method according to claim 1, characterized in that, The establishment of a complete set of signal objects based on pre-configured line condition data includes: Based on the signal object definition information, generate multiple signal objects and configure an object identifier, object category, and a set of attributes to carry the object attribute values ​​for each signal object; Based on the mapping information, an interface mapping relationship is established for each signal object. The interface mapping relationship is used to indicate the set of interfaces associated with the signal object, and to map the fields in the data message to the corresponding attribute items in the attribute set. The multiple signal objects and their corresponding interface mappings are written into the complete set of signal objects for parsing data messages and subsequent consistency monitoring and logical verification calls.

4. The method according to claim 1, characterized in that, The step of parsing the data message according to the interface mapping relationship, writing the parsed attribute values ​​into the attribute set of the corresponding signal object, and generating an object attribute update event when the attribute values ​​are updated includes: The interface corresponding to the data message is determined based on the data source identifier in the original data record, and the target signal object and the attribute item mapping information corresponding to the target signal object are determined in the interface mapping relationship based on the interface; The message payload of the data message is parsed according to the attribute item mapping information to obtain at least one attribute value corresponding to the attribute item mapping information. Write the at least one attribute value into the attribute item corresponding to the attribute item mapping information in the attribute set of the target signal object, and obtain the attribute value after writing and the attribute value before writing; When the attribute value after writing is inconsistent with the attribute value before writing, an object attribute update event is generated. The object attribute update event includes the object identifier of the target signal object and the identifier of the attribute item that was updated.

5. The method according to claim 1, characterized in that, The step of extracting the status values ​​of the corresponding signal objects at each interface from the original data records and comparing them, and generating a status consistency alarm when the status values ​​are inconsistent, includes: The object identifier of the target signal object is determined based on the object attribute update event, and the set of interfaces associated with the target signal object is determined based on the interface mapping relationship of the target signal object; For each interface in the interface set, obtain the status value corresponding to the object identifier based on the time identifier and data source identifier in the original data record; The consistency of each state value obtained from the interface set is compared. If at least two state values ​​are different, a state consistency alarm is generated. The status consistency alarm is associated with the object identifier, interface set, and inconsistent status value for subsequent association processing.

6. The method according to claim 1, characterized in that, The response to the object attribute update event determines the object category of the signal object corresponding to the object attribute update event and the attribute item that has been updated, including: Retrieve the object identifier and property item identifier from the object property update event; The target signal object is retrieved from the complete set of signal objects based on the object identifier, and the object category corresponding to the target signal object is read. In the attribute set of the target signal object, the attribute item that has been updated is determined based on the attribute item identifier, and the attribute name and the updated attribute value of the attribute item are obtained; The object category and the attribute name are output as rule trigger information, which is used to match the rule corresponding to the rule trigger information in the configurable rules and perform logical verification.

7. A device for monitoring and verifying the consistency of signal objects across all interfaces in rail transit, characterized in that, include: The receiving module is used to receive data messages from multiple interfaces of the rail transit signaling system through a message queue, and to encapsulate the data messages in a unified manner to obtain raw data records containing time identifiers and data source identifiers; A module is established to build a complete set of signal objects based on pre-configured line condition data. The complete set of signal objects includes multiple signal objects and the object identifier, object category, attribute set and interface mapping relationship corresponding to each signal object. The parsing module is used to parse data messages according to the interface mapping relationship, write the parsed attribute values ​​into the attribute set of the corresponding signal object, and generate an object attribute update event when the attribute values ​​are updated. The comparison module is used to respond to object attribute update events, determine at least two interfaces associated with the corresponding signal object through the interface mapping relationship, extract the status values ​​of the corresponding signal object in each interface from the original data record and compare them, and generate a status consistency alarm when the status values ​​are inconsistent. The verification module is used to respond to object attribute update events, determine the object category of the signal object corresponding to the object attribute update event and the updated attribute items, call configurable rules that match the object category and attribute items, verify the attribute relationship between the signal object and at least one associated signal object, and generate a logical consistency alarm when the configurable rules are not met. The association module is used to associate the original data records, the attribute data of the signal objects, the configurable rule identifiers, and the status consistency alarms and / or logical consistency alarms to form association records and store them; The verification module retrieves a target configurable rule from the configurable rule base whose triggering conditions match the rule triggering information, based on rule triggering information. The target configurable rule is a script rule with a rule identifier. According to the preset object association relationships in the target configurable rule, it determines at least one associated signal object logically related to the signal object from the line condition data, and obtains the attribute data corresponding to the signal object and the at least one associated signal object as rule input data. It then calls the script execution engine to load and execute the script rule, outputting a verification result based on the rule input data. When the verification result indicates that the attribute relationship does not satisfy the script rule, a logical consistency alarm is generated.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 6.

Images