A comprehensive operation and maintenance system of a railway signal centralized monitoring system

Abstract

The application provides a comprehensive operation and maintenance system of a railway signal centralized monitoring system, comprising: a multi-dimensional data acquisition module, which acquires the running state data of each component part of the CSM in real time through various monitoring protocols and interfaces; a hierarchical network topology graph construction and visualization module, which constructs and displays a hierarchical network topology graph; a device account model establishment and hierarchical management module, which performs hierarchical management on the devices of the centralized monitoring system itself; an alarm information and operation log centralized storage module, which centrally stores the collected alarm information and the operation log of the system; an abnormal alarm generation and reporting module, which generates and reports alarm information; an external interface and acquisition board card state graphical display module, which uses a graphical method to display the current state of the collected external interface state and acquisition board card / module state in real time; and a fault matching and auxiliary decision-making module, which matches in a preset case library and outputs the possible cause, positioning information and processing suggestion of the fault.

Description

Technical Field

[0001] This invention relates to the field of railway signaling equipment operation and maintenance technology, and in particular to a comprehensive operation and maintenance system for a centralized railway signaling monitoring system. Background Technology

[0002] CSM (Conductivity Management System) is a crucial signaling equipment for monitoring the status of signaling equipment, identifying potential problems, analyzing and diagnosing faults, ensuring the security of information at signaling subsystem interfaces, assisting and guiding on-site maintenance and troubleshooting, and improving the operational quality and maintenance level of electrical system equipment. Currently, CSMs are installed in over 10,000 stations across the railway network, becoming a key infrastructure for ensuring railway transportation safety.

[0003] However, the CSM itself is a complex system composed of numerous network devices, servers, software, and databases. These devices include switches, routers, firewalls, application servers, database servers, storage devices, and data acquisition cards, all working together to perform real-time monitoring of signal equipment. If the CSM itself malfunctions, such as due to network outages, server crashes, insufficient database space, or data acquisition module failures, it will directly lead to missing or delayed monitoring data from signal equipment, severely impacting the electrical department's fault diagnosis and emergency response capabilities.

[0004] Currently, there is a lack of unified and effective monitoring and management tools for the operational status of CSM (Common Management System). On-site maintenance typically relies on regular manual inspections and reactive fault reporting, a model with the following shortcomings:

[0005] Inefficient: Manual inspections cannot achieve 24 / 7 real-time monitoring, and the inspection cycle is long, making it difficult to detect potential hazards in a timely manner;

[0006] Delayed fault detection: Faults are often only discovered when they have already affected signal equipment monitoring, resulting in passive emergency response;

[0007] Fault localization is difficult: CSM has many internal devices with complex relationships, and there is a lack of effective correlation analysis methods when a fault occurs, making it time-consuming to locate the root cause.

[0008] Lack of a unified view: Network devices, servers, databases, virtualization platforms, etc. are monitored independently, making it impossible for operations and maintenance personnel to intuitively grasp the overall operating status of the system.

[0009] Therefore, there is an urgent need for a solution that can comprehensively maintain and manage CSM itself, enabling all-round, visualized, and intelligent operation and maintenance management of the CSM system, thereby improving system reliability and maintenance efficiency. Summary of the Invention

[0010] This invention aims to solve the problem of the lack of unified monitoring and management of the CSM's own operating status in the existing technology, and provides a comprehensive operation and maintenance system for a railway signal centralized monitoring system.

[0011] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0012] A comprehensive operation and maintenance system for a centralized railway signal monitoring system includes:

[0013] The multi-dimensional data acquisition module is configured as follows:

[0014] The system collects real-time operational status data of various components within the Centralized Railway Signal Monitoring System (CSM) through multiple monitoring protocols and interfaces. These components include network devices, application servers, databases, internal business logic connections, acquisition boards / modules, and external system interfaces.

[0015] The hierarchical network topology graph construction and visualization module is configured as follows:

[0016] Based on the collected network device data, the network connection relationship is automatically discovered, a hierarchical network topology map is constructed and displayed, and the status of each network device and interface is visualized in real time on the topology map.

[0017] The equipment ledger model establishment and hierarchical management module is configured as follows:

[0018] Establish a monitoring system equipment ledger model to classify and manage the equipment of the centralized monitoring system itself, and record the attribute information of the equipment to provide basic data support for equipment maintenance and fault diagnosis;

[0019] The alarm information and operation log centralized storage module is configured as follows:

[0020] The system centrally stores alarm information generated by abnormal states and system operation logs to ensure data traceability and provide a basis for subsequent statistical analysis and fault tracing.

[0021] The abnormal alarm generation and reporting module is configured as follows:

[0022] When any collected operational status data exceeds a preset threshold or an anomaly occurs, an alarm message is generated and reported to remind staff to respond and handle the situation quickly.

[0023] The external interface and data acquisition board status graphical display module is configured as follows:

[0024] The current status of the collected external interface status and the status of the acquisition board / module are displayed in a graphical manner in real time, improving the readability and intuitiveness of the status information;

[0025] The fault matching and decision support module is configured as follows:

[0026] It receives fault symptoms input by users, matches them in a pre-set case library based on fault matching technology, and outputs possible causes, location information and handling suggestions for the fault, assisting staff in efficiently troubleshooting faults.

[0027] Existing technologies lack unified monitoring and management tools for the CSM (Communication Management System) itself, leading to low maintenance efficiency and delayed fault response. This invention comprehensively acquires the status of each component of the CSM through multi-dimensional data collection; provides an intuitive presentation of the network structure through topology construction and visualization; standardizes equipment information through hierarchical management of ledgers; ensures data traceability through centralized storage of alarms and logs; achieves real-time response through abnormal alarm generation and reporting; enhances status readability through graphical displays; and realizes intelligent fault handling through fault matching and decision support. This achieves comprehensive monitoring, visualized operation and maintenance, and intelligent fault handling of the CSM system, effectively improving the maintenance efficiency and system reliability of the power sector.

[0028] Furthermore, the multi-dimensional data acquisition module specifically includes:

[0029] The system collects basic identity information, real-time interface status, traffic statistics, performance metrics, error statistics, IP address tables, routing tables, and other information about network devices via the SNMP protocol. It also collects basic identity information, CPU performance metrics, memory usage, disk storage information, network interface status, system load, and process data of server hardware.

[0030] The IPMI protocol is used to collect information such as hardware status parameters and event log records of the server hardware.

[0031] AWR is used to collect information on Oracle database time model metrics, load overview, wait event statistics, SQL execution statistics, instance efficiency, resource usage, top-level SQL, and object access statistics. ASH is used to collect information on Oracle database session status, wait events, SQL execution information, object information, blocking relationships, resource consumption, and time dimensions. DEM / KMonitor is used to collect information on host system resources (CPU utilization, memory usage, disk I / O performance, network interface status) and database instance performance metrics (database running status, system uptime, instance name, database version, transactions per second, queries per second, database CPU utilization, memory usage, total number of sessions, number of active sessions, and number of inactive sessions) for DM and Kingbase databases respectively.

[0032] Libvirt / internal monitoring collects basic virtual machine status information (running status, maximum memory configuration, current memory usage, number of virtual CPUs, CPU time), CPU performance metrics (CPU utilization, CPU time statistics, vCPU core usage), memory usage statistics (available memory, used memory, memory utilization rate, memory balloon status), disk I / O performance (disk read / write speed, IOPS statistics, disk latency, queue depth), and network interface status (network throughput, network latency, packet loss rate, network error statistics), etc.

[0033] Information such as business logic connection status, external interface status, and collection board / module status is collected through a dedicated interface.

[0034] To comprehensively and efficiently collect operational data from various heterogeneous components within the CSM (Comprehensive Management System), this invention employs industry-standard or dedicated interfaces for different components. For example, SNMP is used to collect data from network devices, IPMI from hardware, AWR / ASH from Oracle databases, DEM / KMonitor from domestic databases, Libvirt from virtualization platforms, and dedicated interfaces for business logic and data acquisition cards. This achieves full coverage data collection for all key components of the CSM, eliminating monitoring blind spots and providing a complete data foundation for upper-level analysis and decision-making.

[0035] Furthermore, the hierarchical network topology graph construction and visualization module specifically includes:

[0036] The SNMP protocol is used to read the MIB table of LLDP (Link Layer Discovery Protocol) or CDP (CiscoDiscovery Protocol) to obtain neighbor information. The collection strategy uses SNMP GETBULK for batch reading, and sets the timeout (e.g., 5-10 seconds) and the number of retries (e.g., 1 time) to reduce the CPU load on the device.

[0037] A dual mechanism of "automatic discovery + manual confirmation" is adopted to map neighbor information to specific device objects and interface objects. Interface mapping associates local interfaces through ifIndex and establishes mapping rules to handle the difference between port descriptions and actual interface names; device identification uses lldpRemChassisId (usually MAC address) or lldpRemSysName, combined with the device asset database, to match and determine the identity of the peer device.

[0038] A finite state machine (FSM) model is used to manage the discovery process, ensuring data consistency and recoverability. The state transitions include: Undiscovered → Identified (device reachability confirmed via ICMP / Ping) → Connected (successful SNMP authentication, obtaining basic device information) → Completed (all interface and neighbor information collected, topology established).

[0039] An incremental discovery mechanism is adopted, which uses timestamps such as lldpStatsRemTablesLastChangeTime to synchronize only the neighbor information that has changed, thus avoiding the performance overhead caused by full polling.

[0040] To address data inconsistency issues, filtering is performed based on interface status (Up / Down) to exclude historical remnants or non-standardly named LLDP / CDP information. To address performance bottlenecks, an SNMP connection pool is established to reuse UDP sockets, and the number of concurrent queries is limited (e.g., 5-10) to avoid overloading the device.

[0041] By combining the equipment ledger, a network topology diagram of the CSM central layer and each station node is constructed, forming a hierarchical network topology diagram of "three levels and three layers".

[0042] To accurately and efficiently discover the complex network connections within a CSM (Cybernetic Streaming System) and avoid erroneous connections and performance bottlenecks, this invention utilizes a standard link-layer discovery protocol to obtain neighbor information; corrects deviations in automatic discovery through a manual verification mechanism; ensures consistency in the discovery process using a finite state machine; reduces network and device load through incremental discovery; and constructs a hierarchical topology by combining a ledger. This improves the accuracy and efficiency of network topology discovery, and the generated topology map accurately reflects physical connections, providing an intuitive view for fault location and network management.

[0043] Furthermore, the fault matching and auxiliary decision-making module adopts a hybrid architecture of "knowledge graph + causal graph + intelligent agent" to realize an intelligent operation and maintenance closed loop of "fault matching + root cause reasoning + contingency plan generation". Specifically, it includes:

[0044] Knowledge graph construction: Network topology, device configuration, historical alarms, performance indicators and other data are uniformly modeled into a graph structure, where nodes represent devices or services and edges represent connections or causal dependencies.

[0045] Causal discovery and root cause localization: A causal-oriented personalized PageRank algorithm is employed. In a real production environment, this algorithm achieves an accuracy of 82.5% in recommending the top 3 root causes and 93.8% in recommending the top 5. The inference logic combines real-time performance data and historical alerts to perform propagation analysis on a causal graph. By calculating the influence of nodes, the source of the fault is quickly located, and the impact path is traced back.

[0046] Multi-source data fusion: Real-time data (monitoring indicators) is used to trigger anomaly detection and serve as input signals for inference; historical data (alarm logs) is used to verify the stability of causal relationships and improve matching confidence; static data (equipment ledgers such as maintenance records) is used to assist in judging equipment reliability and reduce false alarms.

[0047] Automatic contingency plan generation: A two-layer intelligent agent model combining reinforcement learning and operations research is constructed. Reinforcement learning generates discrete actions (such as "restart service" and "switch links"), while operations research evaluates the feasibility of these actions in a simulation environment to ensure the physical executability of the contingency plan. Input dimensions include fault level (P0 / P1), impact range (single point / network-wide), and on-site personnel skill level (junior / expert). Logically, a detailed step list (including command examples and risk warnings) is output for junior personnel, while key decision points and quick commands are output for expert personnel, reducing redundant information. High-risk scenarios automatically trigger simulation verification to ensure the contingency plan's safety and reliability.

[0048] Recommendations for project implementation: Establish a unified data access standard to ensure real-time synchronization of topology data and monitoring data; establish a feedback mechanism to feed back the results of manual handling into the knowledge graph and continuously optimize the causal model; for large-scale networks, adopt a distributed graph computing framework (such as Spark GraphX) to handle massive node relationships.

[0049] This invention constructs a knowledge graph from topology, configuration, alarms, and performance data, utilizes the causal-guided PageRank algorithm to calculate node influence and pinpoint root causes, and combines real-time, historical, and static data to improve accuracy. Through reinforcement learning and operations research optimization, it generates response plans suitable for different skill levels. This significantly improves the accuracy of root cause identification (reaching 82.5% accuracy for the top 3 root causes) and provides maintenance personnel with personalized, actionable fault handling solutions, shortening fault repair time.

[0050] Compared with the prior art, the present invention has the following beneficial effects:

[0051] Comprehensive monitoring: Through multi-protocol and multi-interface data collection, it covers all key components of CSM (network, hardware, database, virtualization, business interfaces, and data acquisition cards), eliminating monitoring blind spots.

[0052] Visualized Operations and Maintenance: Automatically discovers and displays the network topology in layers, and graphically presents the status of external interfaces and data acquisition cards, enabling operations and maintenance personnel to intuitively grasp the system's operating status.

[0053] Intelligent fault handling: Based on knowledge graphs and causal reasoning, the root cause can be quickly located, and combined with the intelligent agent to generate differentiated handling plans, the efficiency of fault diagnosis can be significantly improved.

[0054] Centralized management: Equipment ledgers, alarm information, and operation logs are stored in a unified manner, which facilitates traceability and analysis and provides a data foundation for continuous optimization.

[0055] Improve system reliability: Real-time monitoring of the CSM's own health status can promptly identify potential hazards, ensure the continuity and accuracy of signal equipment monitoring data, and indirectly improve railway transportation safety. Attached Figure Description

[0056] Figure 1 This is a diagram of the CSM integrated maintenance system architecture in an embodiment of the present invention.

[0057] Figure 2 This is a network topology diagram of the CSM Bureau Group / Section Layer Monitoring Subsystem in an embodiment of the present invention.

[0058] Figure 3 This is a diagram showing the status of the CSM external interface in an embodiment of the present invention.

[0059] Figure 4 This is a diagram showing the status of the CSM acquisition board in an embodiment of the present invention. Detailed Implementation

[0060] The present invention will now be described in further detail with reference to the accompanying drawings.

[0061] Example 1

[0062] This embodiment provides a comprehensive operation and maintenance system for a centralized railway signal monitoring system, specifically including:

[0063] like Figure 1 As shown, the system of this invention adopts a "three-level, three-layer" architecture, consistent with the CSM system (including the China Railway Corporation (CRC) level monitoring subsystem, the railway bureau / section level monitoring subsystem, and the station level monitoring subsystem). It includes the CRC level integrated maintenance subsystem, the railway bureau / section level integrated maintenance subsystem, and the station level integrated maintenance subsystem. The CRC level and the railway bureau / section level integrated maintenance subsystems belong to the central level. The CRC level integrated maintenance subsystem provides CSM system maintenance functions for CRC-level users, while the railway bureau / section level integrated maintenance subsystem provides CSM system maintenance functions for railway bureau and station / section level users. Both of these central levels have the following functional modules: multi-dimensional data acquisition module, hierarchical network topology diagram construction and visualization module, equipment ledger model establishment and hierarchical management module, alarm information and operation log centralized storage module, abnormal alarm generation and reporting module, external interface and acquisition board status graphical display module, and fault matching and auxiliary decision-making module. The station-level integrated maintenance subsystem is the basic data acquisition unit of the CSM system station level. It can collect the status of the external interfaces and acquisition boards of the CSM system station in real time and send them to the bureau / section-level integrated maintenance subsystem for analysis and display.

[0064] System Architecture and Data Acquisition

[0065] The multi-dimensional data acquisition module collects real-time operational status data from various components (network devices and server hardware) within the Centralized Railway Signal Monitoring System (CSM) through multiple monitoring protocols and interfaces. These components include network devices, application servers, databases, internal business logic connections, acquisition boards / modules, and external system interfaces.

[0066] The specific implementation of the multi-dimensional data acquisition module is as follows:

[0067] Network device and server hardware basic data collection:

[0068] The system periodically (e.g., every 5 minutes) collects basic identity information, real-time interface status, traffic statistics, performance metrics, error statistics, IP address table, and routing table information of network devices (such as switches, routers, firewalls, etc.) in CSM via the SNMP protocol (v2c or v3). At the same time, it collects basic identity information, CPU performance metrics, memory usage, disk storage information, network interface status, system load, and process data of server hardware.

[0069] For servers that support IPMI, the server's hardware status parameters (temperature, voltage, fan speed) and system event logs (SELs) are obtained through the IPMI protocol.

[0070] Database performance data collection:

[0071] AWR collects information such as time model metrics, load overview, wait event statistics, SQL execution statistics, instance efficiency, resource usage, top-level SQL, and object access statistics for Oracle databases.

[0072] ASH collects information such as session status, wait events, SQL execution information, object information, blocking relationships, resource consumption, and time dimensions of the Oracle database.

[0073] Information such as host system resources (CPU utilization, memory usage, disk I / O performance, network interface status) and database instance performance metrics (database running status, system uptime, instance name, database version, transactions per second, queries per second, database CPU utilization, memory usage, total number of sessions, number of active sessions, and number of inactive sessions) for Dameng Enterprise Manager (DEM) and Kingbase databases are collected through DEM and KMonitor respectively.

[0074] Virtualization platform data collection:

[0075] Libvirt / internal monitoring collects basic virtual machine status information (running status, maximum memory configuration, current memory usage, number of virtual CPUs, CPU time), CPU performance metrics (CPU utilization, CPU time statistics, vCPU core usage), memory usage statistics (available memory, used memory, memory utilization rate, memory balloon status), disk I / O performance (disk read / write speed, IOPS statistics, disk latency, queue depth), and network interface status (network throughput, network latency, packet loss rate, network error statistics), etc.

[0076] Business and interface status data collection: Detect whether the internal business logic connection of CSM (such as the connection between the application server and the database) is normal through dedicated interfaces (such as Socket heartbeat, HTTP probe); detect the connectivity of external interfaces (such as the interface with the scheduling centralized system CTC) by simulating login or ping; detect the working status of the acquisition board / module (such as whether it is offline or whether the sampled value is abnormal) by reading the acquisition machine log or sending diagnostic commands.

[0077] All collected data can be aggregated to the central data processing platform via message queues (such as Kafka) for real-time analysis and storage.

[0078] Hierarchical Network Topology Construction and Visualization

[0079] The system automatically discovers network connectivity via the SNMP protocol, constructs and displays a hierarchical network topology map (e.g., Figure 2 The diagram shows the network topology of the constructed CSM bureau / section-level monitoring subsystem. The specific implementation process is as follows:

[0080] Data Acquisition: The system first reads the LLDP MIB (lldpRemTable in IEEE8023-LAG-MIB) or CDP MIB (CISCO-CDP-MIB) of the network devices via SNMP. Neighbor information is then acquired in batches using the SNMP GETBULK operation, with a timeout of 10 seconds and a retry time of 1 to avoid congestion caused by slow responses from individual devices.

[0081] Relationship mapping:

[0082] Interface mapping: The obtained neighbor port information (such as "GigabitEthernet0 / 1") is mapped to the local interface using ifIndex. For ports with non-standard naming, the system has built-in regular expression conversion rules (such as converting "GigabitEthernet" to "GE").

[0083] Device identification: The Chassis ID (usually a MAC address) or SysName sent by neighboring devices is used for fuzzy matching with the device asset database (already recorded device information). If a match fails, the device is marked as an unknown device and awaits confirmation.

[0084] State machine management: The system maintains a state machine for each device.

[0085] Undetected: The device IP is known but has not yet been detected.

[0086] Identified: Reachable via ICMP ping.

[0087] Connected: SNMP authentication successful, basic information such as sysDescr obtained.

[0088] Completed: All interface and neighbor information collection completed, and topology relationships established.

[0089] Incremental discovery: The system periodically (e.g., every 30 minutes) checks lldpStatsRemTablesLastChangeTime. If a change is found, data is re-collected only for the device that has changed, reducing network load.

[0090] Manual Confirmation: After automatic discovery is complete, the generated topology map will be marked "Pending Confirmation". Maintenance personnel can manually adjust device locations and connections. Once confirmed, the topology map will enter its final state. Subsequent automatic discovery will only update the status based on this initial state and will not overwrite manually adjusted settings.

[0091] The above steps can automatically discover network connection relationships. Combined with the equipment ledger, a network topology map of the CSM central layer and each station node can be constructed, forming a hierarchical network topology map of "three levels and three layers".

[0092] The topology map is displayed in a web-based manner, supporting zooming and dragging. Device icon colors indicate status (green for normal, yellow for alarm, and red for fault). Hovering the mouse over a device displays detailed device information, and clicking it will take you to the device details page.

[0093] Equipment ledger model establishment and hierarchical management

[0094] The system has a built-in equipment ledger management module, supporting hierarchical and categorized management of all CSM equipment according to China State Railway Group, Railway Bureau / Section, and Station. Each equipment category records attributes such as: equipment name, IP address, location, model, serial number, maintenance information, and spare parts information. Ledger data can be manually entered or automatically discovered and updated synchronously. Hierarchical management facilitates quick retrieval and statistics by region and level.

[0095] Alarm information and operation logs are centrally stored

[0096] Alarm information generated by abnormal states collected by the multi-dimensional data acquisition module, along with system operation logs, are uniformly stored in the storage cluster. Alarm information includes: alarm level (critical, major, warning), alarm source, alarm content, occurrence time, and recovery time. Operation logs record user logins, configuration modifications, and fault handling operations. A visual query interface can be provided through Kibana, supporting filtering by time, device, and level, facilitating fault tracing and operational auditing.

[0097] Abnormal alarm generation and reporting

[0098] The system has a built-in threshold rule engine, allowing users to set thresholds for different metrics (such as CPU utilization > 90%, disk space < 10GB, and interface traffic surge > 50%). When real-time metrics exceed the thresholds, an alarm is generated and reported through multiple channels: highlighting the faulty device on the topology map, sending SMS / email / DingTalk / WeChat notifications, and simultaneously writing the alarm to centralized storage. Alarms support suppression and aggregation to avoid duplicate alarms.

[0099] External interface and data acquisition board status graphical display

[0100] like Figure 3 As shown, the status of external interfaces is displayed in the form of signal connection lines: green indicates normal device operation, red indicates device malfunction, and yellow indicates device abnormality. For example... Figure 4 As shown, the status of the data acquisition boards is displayed in a matrix diagram. Each cell represents a board, and the color indicates online / offline / faulty. Hovering the mouse over the board displays the board number, data acquisition machine description, device description, communication status, etc. Maintenance personnel can quickly identify abnormal boards and replace them in a timely manner.

[0101] Fault matching and decision support

[0102] The fault matching module employs knowledge graph technology. First, a knowledge graph is constructed: network topology (devices, interfaces, links), device configurations (IP, version), historical alarms (time, type, level), and performance metrics (CPU, memory) are imported as entities and relationships into a graph database (such as Neo4j). When a user inputs a fault symptom (such as "database connection failed") or the system automatically detects an anomaly, root cause analysis is triggered.

[0103] Root cause analysis process:

[0104] Locate fault-related nodes (such as database servers and network devices) in the knowledge graph.

[0105] A causal-oriented, personalized PageRank algorithm is run, starting from the faulty node, performing a random walk on the causal graph, and calculating the influence score of each node. Nodes with high scores are considered potential root causes. The algorithm formula is as follows:

[0106]

[0107] Where d is the damping factor (usually taken as 0.85), In(u) is the set of nodes pointing to u, L(v) is the out-degree of v, and w v,u The edge weights are based on historical co-occurrence frequencies.

[0108] Integrate multi-source data: If real-time metrics show a device's CPU spike, increase its score; if the device frequently appears in historical alarms, further confirm the situation.

[0109] Output the root cause device and its impact path.

[0110] Emergency response plan generation:

[0111] A two-layer agent model combining reinforcement learning and operations research is constructed. The reinforcement learning agent employs the Deep Q-Network (DQN) algorithm. Its state space includes fault type, device role, and current metrics, while its action space includes actions such as restarting the service, switching between primary and backup links, expanding resource capacity, and notifying on-call personnel. The operations research agent uses linear programming to verify the feasibility of actions (e.g., ensuring sufficient bandwidth on the backup link is crucial when switching links).

[0112] Different levels of detail are generated based on the user's skill level. Basic contingency plans include specific command lines (such as logging into the server and executing `systemctl restart csmservice`), while expert contingency plans only provide policy suggestions (such as recommending switching to a backup database).

[0113] For high-risk operations (such as restarting a core switch), the system automatically calls a simulation environment (based on a network simulator) to verify the impact of the operation. Only if the simulation passes can the operation be executed.

[0114] Through the above steps, this invention achieves comprehensive, visualized, and intelligent operation and maintenance management of the CSM system, effectively improving the maintenance efficiency and system reliability of the electrical engineering department.

[0115] 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 comprehensive operation and maintenance system for a centralized railway signal monitoring system, characterized in that, include: The multi-dimensional data acquisition module is configured as follows: The system collects real-time operational status data of various components within the Centralized Railway Signal Monitoring System (CSM) through multiple monitoring protocols and interfaces. These components include network devices, application servers, databases, internal business logic connections, acquisition boards / modules, and external system interfaces. The hierarchical network topology graph construction and visualization module is configured as follows: Based on the collected network device data, the network connection relationship is automatically discovered, a hierarchical network topology map is constructed and displayed, and the status of each network device and interface is visualized in real time on the topology map. The equipment ledger model establishment and hierarchical management module is configured as follows: Establish a monitoring system equipment ledger model to classify and manage the equipment of the centralized monitoring system itself, and record the attribute information of the equipment to provide basic data support for equipment maintenance and fault diagnosis; The alarm information and operation log centralized storage module is configured as follows: The system centrally stores alarm information generated by abnormal states and system operation logs to ensure data traceability and provide a basis for subsequent statistical analysis and fault tracing. The abnormal alarm generation and reporting module is configured as follows: When any collected operational status data exceeds a preset threshold or an anomaly occurs, an alarm message is generated and reported to remind staff to respond and handle the situation quickly. The external interface and data acquisition board status graphical display module is configured as follows: The current status of the collected external interface status and the status of the acquisition board / module are displayed in a graphical manner in real time, improving the readability and intuitiveness of the status information; The fault matching and decision support module is configured as follows: It receives fault symptoms input by users, matches them in a pre-set case library based on fault matching technology, and outputs possible causes, location information and handling suggestions for the fault, assisting staff in efficiently troubleshooting faults.

2. The integrated operation and maintenance system for the centralized railway signal monitoring system according to claim 1, characterized in that, The multi-dimensional data acquisition module specifically includes: Network device and server hardware basic data collection: The CSM collects basic identity information, real-time interface status, traffic statistics, performance indicators, error statistics, IP address table, and routing table information of network devices via the SNMP protocol. At the same time, it collects basic identity information, CPU performance indicators, memory usage, disk storage information, network interface status, system load, and process data of server hardware. The hardware status parameters and event log information of the server hardware are collected through the IPMI protocol. Database performance data collection: AWR collects time model metrics, load overview, wait event statistics, SQL execution statistics, instance efficiency, resource usage, top-level SQL, and object access statistics for Oracle databases. ASH collects session status, wait events, SQL execution information, object information, blocking relationships, resource consumption, and time-related information of the Oracle database. The host system resources and database instance performance metrics of DM and Kingbase databases were collected using DEM / KMonitor. Virtualization platform data collection: Collect basic status information, CPU performance metrics, memory usage statistics, disk I / O performance, and network interface status information of the virtualization platform through Libvirt or internal monitoring interfaces; Business and Interface Status Data Collection: The system collects business logic connection status, external interface status, and board / module status information through a dedicated interface.

3. The integrated operation and maintenance system for the centralized railway signal monitoring system according to claim 1, characterized in that, The hierarchical network topology construction and visualization module specifically includes: The connection data is obtained by reading the MIB table of LLDP or CDP using the SNMP protocol; A dual mechanism of "automatic discovery + manual confirmation" is adopted to map neighbor information into specific device objects and interface objects; The device discovery process is managed using a finite state machine model, and the state transitions include: Undetected → Identified → Connected → Completed; An incremental discovery mechanism is adopted, which only synchronizes neighbor information that has changed based on timestamps; By combining the equipment ledger, a network topology diagram of the CSM central layer and each station node is constructed, forming a three-level, three-layer hierarchical network topology diagram.

4. The integrated operation and maintenance system for the centralized railway signal monitoring system according to claim 1, characterized in that, The fault matching and auxiliary decision-making module adopts a hybrid architecture of knowledge graph + causal graph + intelligent agent, specifically including: Construct a knowledge graph that includes network topology, device configuration, historical alarms, and performance metrics. Nodes represent devices or services, and edges represent connections or causal dependencies. A causal-oriented personalized PageRank algorithm is used for root cause localization. Real-time performance data and historical alarms are combined to perform propagation analysis on the causal graph, calculate the influence of nodes, locate the source of the fault, and trace the impact path. Integrating real-time data, historical data, and static data for inference improves matching confidence. We construct a two-layer intelligent agent model that combines reinforcement learning and operations research optimization. Reinforcement learning is responsible for generating discrete actions, while operations research optimization is responsible for evaluating the feasibility of actions in a simulation environment. Differentiated response plans are generated based on the fault level, the scope of impact, and the skill level of on-site personnel.

Images