Alarm management device based on rail transit distributed dispatching system

By introducing alarm generation, management, and notification modules into the rail transit distributed scheduling system, and utilizing message queue communication mechanisms and alarm rule engines, the problems of system scalability and high maintenance costs are solved, achieving easily scalable and low-cost alarm management.

CN115567364BActive Publication Date: 2026-02-06TRAFFIC CONTROL TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202211035778.7
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-08-26
Publication Date
2026-02-06
Estimated Expiration
2042-08-26

AI Technical Summary

Technical Problem

In the distributed dispatching system of rail transit, the existing alarm management service is difficult to expand and has high maintenance costs, and cannot meet the integration and dynamic configuration requirements of multi-vendor systems.

Method used

A message queue-based communication mechanism is adopted, and alarm generation, alarm management, and alarm notification modules are designed. Alarm data is configured and published through an alarm rule engine, thereby decoupling the alarm function from business functions and reducing system complexity.

Benefits of technology

It implements an easily expandable and maintainable alarm function in the distributed dispatching system for rail transit, reduces system complexity and development and maintenance costs, and meets the integration needs of multi-vendor systems.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115567364B_ABST
    Figure CN115567364B_ABST
Patent Text Reader

Abstract

The application relates to the field of rail transit technology and provides an alarm management device based on a rail transit distributed scheduling system, which comprises the following: an alarm generation module connected with a business module and a third-party system in the system based on a first message queue, which is used for acquiring alarm data; an alarm management module connected with the alarm generation module based on a second message queue and connected with an application module in the rail transit distributed scheduling system based on a third message queue, which is used for generating event alarm data and / or threshold alarm data and publishing the event alarm data and / or the threshold alarm data to the third message queue for subscription by the application module; and an alarm notification module connected with the alarm management module based on a fourth message queue, which is used for generating an alarm notification and determining a notification strategy and a notification mode of the alarm notification based on an alarm level of the alarm notification. The device provided by the application realizes the separation design of the alarm function and business implementation, realizes low coupling, and is easy to expand.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the field of rail transit technology, and in particular to an alarm management device based on a rail transit distributed dispatching system. BACKGROUND

[0002] Traditional rail transit dispatching systems are basically single-line dispatching management systems, which are connected with various vendor systems through proprietary interfaces. The technologies, architectures and interfaces adopted by each vendor system are different, making it difficult for multiple vendor systems to be integrated. Most systems use traditional technology stacks, and the system architecture basically adopts a monolithic system architecture. These technologies are no longer the mainstream development technologies. The alarm management service of the system only considers limited business scenarios, the design is not standardized and is difficult to expand; the function is simple and is mostly implemented by hard coding, which cannot be dynamically configured and has high maintenance costs.

[0003] The rail transit distributed dispatching system is a dispatching management system for multiple lines or line networks, and the system is a distributed system implemented by using microservices and Internet mainstream open source technologies. Due to the great differences between the distributed dispatching system and the traditional dispatching system in terms of design and technical implementation, the original alarm management service cannot be implemented in the distributed dispatching system.

[0004] Therefore, how to provide an alarm function service that is easy to expand and has low maintenance costs in the rail transit distributed dispatching system has become a technical problem to be solved in the industry. SUMMARY

[0005] The present application provides an alarm management device based on a rail transit distributed dispatching system, which is used to solve the technical problem of how to provide an alarm function service that is easy to expand and has low maintenance costs in the rail transit distributed dispatching system.

[0006] The present application provides an alarm management device based on a rail transit distributed dispatching system, comprising:

[0007] An alarm generation module, which is communicatively connected with a business module in the rail transit distributed dispatching system and a third-party system based on a first message queue, and is configured to obtain alarm data;

[0008] An alarm management module, which is communicatively connected with the alarm generation module based on a second message queue, and is communicatively connected with an application module in the rail transit distributed dispatching system based on a third message queue, and is configured to configure the alarm data based on an alarm rule engine, generate event alarm data and / or threshold alarm data, and publish the event alarm data and / or the threshold alarm data to the third message queue for subscription by the application module;

[0009] The alarm notification module is connected with the alarm management module based on a fourth message queue, and is configured to generate an alarm notification based on the event alarm data and / or the threshold alarm data, and determine a notification strategy and a notification mode of the alarm notification based on an alarm level of the alarm notification.

[0010] The alarm management device based on the distributed scheduling system of the rail transit is provided, and the alarm generation module is specifically configured to:

[0011] Obtain initial alarm data sent by the business module or the third-party system;

[0012] Analyze the initial alarm data to determine a message type, an alarm type, an alarm source, an alarm classification and an alarm level corresponding to the initial alarm data.

[0013] Generate the alarm data based on the message type, the alarm type, the alarm source, the alarm classification and the alarm level corresponding to the initial alarm data.

[0014] The alarm management device based on the distributed scheduling system of the rail transit is provided, and the alarm management module specifically includes:

[0015] An alarm configuration sub-module is configured to configure the alarm data based on an alarm rule engine, generate event alarm data and / or threshold alarm data.

[0016] An alarm storage sub-module is connected with the alarm configuration sub-module, and is configured to store the event alarm data and the threshold alarm data into a database.

[0017] An alarm publishing sub-unit is connected with the alarm configuration sub-module, and is configured to publish the event alarm data and / or the threshold alarm data to the third message queue.

[0018] The alarm management device based on the distributed scheduling system of the rail transit is provided, and the alarm management module further specifically includes:

[0019] An alarm management sub-module is connected with the alarm storage sub-module and the alarm configuration sub-module, and is configured to perform data management on the event alarm data and / or the threshold alarm data in the database, and perform dynamic configuration on the alarm rule engine.

[0020] The alarm management device based on the distributed scheduling system of the rail transit is provided, and the alarm management module further specifically includes:

[0021] An alarm silencing submodule, connected with the alarm configuration submodule, configured to stop publishing the event alarm data and / or the threshold alarm data to the third message queue in a preset silencing period corresponding to a preset silencing condition, in a case that the event alarm data and / or the threshold alarm data meets the preset silencing condition.

[0022] The alarm management device based on the distributed scheduling system of the rail transit according to the present application is provided with an alarm configuration submodule, which is specifically configured to:

[0023] determine the alarm type of any alarm data;

[0024] in a case that the alarm type is an event alarm, determine the event table and the event alarm table corresponding to the any alarm data;

[0025] determine the event alarm data corresponding to the any alarm data based on the event table and the event alarm table.

[0026] The alarm management device based on the distributed scheduling system of the rail transit according to the present application is provided with an alarm configuration submodule, which is specifically configured to:

[0027] determine the alarm type of any alarm data;

[0028] in a case that the alarm type is a threshold alarm, analyze the any alarm data to determine the index information and the threshold information corresponding to the any alarm data;

[0029] based on the alarm rule engine, calculate and verify the index information and the threshold information corresponding to the any alarm data to generate the threshold alarm data corresponding to the any alarm data.

[0030] The alarm management device based on the distributed scheduling system of the rail transit according to the present application is provided with an alarm publishing submodule, which is specifically configured to:

[0031] determine the subject of the event alarm data and / or the threshold alarm data; the content of the subject includes the code of a business module, the code of a corresponding submodule of the business module, the code of alarm data and the index name;

[0032] publish the subject to the third message queue, so that the application module subscribes to the event alarm data and / or the threshold alarm data based on the subject.

[0033] The alarm management device based on the distributed scheduling system of the rail transit according to the present application is provided with a database, in which the event alarm data and the threshold alarm data are respectively stored in different data tables.

[0034] The alarm management device based on the distributed scheduling system of rail transit provided by the application comprises an alarm generating module, an alarm management module and an alarm notification module.

[0035] determining an alarm level of the alarm notification;

[0036] in the case that the alarm level is emergency, determining that the notification mode of the alarm notification comprises telephone notification, short message notification, email notification and instant messaging software notification;

[0037] in the case that the alarm level is warning, determining that the notification mode of the alarm notification comprises short message notification, email notification and instant messaging software notification;

[0038] in the case that the alarm level is prompt, determining that the notification mode of the alarm notification comprises email notification and instant messaging software notification.

[0039] The alarm management device based on the distributed scheduling system of rail transit provided by the application comprises an alarm generating module, an alarm management module and an alarm notification module. BRIEF DESCRIPTION OF DRAWINGS

[0040] In order to more clearly illustrate the technical solutions in the application or prior art, the drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description are some embodiments of the application, and other drawings can be obtained by those skilled in the art without any creative effort on the basis of these drawings.

[0041] Figure 1 The structural schematic diagram of the alarm management device based on the distributed scheduling system of rail transit provided by the application;

[0042] Figure 2 The structural schematic diagram of the alarm management module provided by the application;

[0043] Figure 3 An alarm management schematic diagram of the rail transit distributed dispatching system provided by the present application.

[0044] The drawings show:

[0045] 101: first message queue; 102: second message queue; 103: third message queue; 104: fourth message queue; 110: alarm generation module; 120: alarm management module; 130: alarm notification module; 140: business module; 150: application module; 160: third-party system; 121: alarm configuration sub-module; 122: alarm storage sub-module; 123: alarm publishing sub-unit. DETAILED DESCRIPTION

[0046] In order to make the objects, technical solutions and advantages of the present application clearer, the technical solutions in the present application will be described clearly and completely below in combination with the drawings in the present application. Obviously, the described embodiments are some of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0047] It should be noted that the terms "first", "second" and the like in the present application are used to distinguish similar objects, and do not necessarily have to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units does not have to be limited to those steps or units clearly listed, but can include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0048] Figure 1 The structure schematic diagram of the alarm management device based on the rail transit distributed dispatching system provided by the present application is shown in Figure 1 The device includes an alarm generation module 110, an alarm management module 120 and an alarm notification module 130. The dashed line in the figure represents a communication connection.

[0049] The alarm generation module 110 is in communication connection with the business module 140 in the rail transit distributed dispatching system and the third-party system 160 based on the first message queue 101, and is used to obtain alarm data;

[0050] The alarm management module 120 is in communication connection with the alarm generation module 110 based on the second message queue 102 and in communication connection with the application module 150 in the rail transit distributed dispatching system based on the third message queue 103, is used for configuring alarm data based on an alarm rule engine, generating event alarm data and / or threshold alarm data, and publishing the event alarm data and / or the threshold alarm data to the third message queue 103 for subscription by the application module 150;

[0051] The alarm notification module 130 is in communication connection with the alarm management module 120 based on the fourth message queue 104, is used for generating an alarm notification based on the event alarm data and / or the threshold alarm data, and determining a notification strategy and a notification mode of the alarm notification based on an alarm level of the alarm notification.

[0052] Specifically, the rail transit distributed dispatching system (hereinafter referred to as a distributed dispatching system) is a dispatching management system facing multiple lines and a line network, and the system is a distributed system realized by using micro services and mainstream open source technologies on the Internet. The distributed dispatching system has great differences in design and technical implementation from a traditional dispatching system, and needs to be designed and selected in technology in combination with the characteristics of the distributed system. The alarm management device in the distributed dispatching system needs to meet the global alarm demand; can access alarm data of three-party systems and be compatible with heterogeneous alarm data; alarm rules can be dynamically configured to reduce system development and maintenance costs.

[0053] The distributed dispatching system is a WEB technology architecture realized by micro services, involves business requirements of comprehensive monitoring, integrates multiple third-party systems 160, and the alarm management function needs to meet the business requirements of the entire system. From the aspects of technology, business, architecture and application, a standard alarm data specification and alarm processing flow are formulated, the best alarm management scheme is designed, new technologies are combined to reduce the design and implementation complexity of the system, and the complex alarm management of the distributed system is solved.

[0054] The alarm management device based on the rail transit distributed dispatching system provided in the embodiment of the application can be used as a part of the distributed dispatching system to realize alarm management in the entire rail transit. From the structure, the device comprises the alarm generation module 110, the alarm management module 120 and the alarm notification module 130 connected in sequence.

[0055] The alarm generation module 110 is in communication connection with the business module 140 in the distributed dispatching system and the third-party system 160 based on the first message queue 101, is used for acquiring alarm data sent by the business module 140 and the third-party system 160. The alarm data is an alarm signal generated when a device or a system fails.

[0056] The business module 140 is a functional module for performing related business in the distributed dispatching system, and can include, for example, a dispatching service module, a running graph module, an auxiliary decision-making module, and the like. The third-party system 160 is another auxiliary functional module existing in the rail transit, and can include, for example, an automatic train supervision system (ATS), a train internet automatic system (TIAS), a video monitoring system (CCTV), a building automation system (BAS), a fire alarm system (FAS), an automatic fare collection system (AFC), and the like.

[0057] The business module 140 and the third-party system 160 can send the generated alarm data to the alarm generation module 110 through the first message queue 101. Message queue communication is a communication method between applications, and the message can be returned immediately after being sent, and the message system is used to ensure reliable delivery of the message. The first message queue 101 can be implemented through a message middleware RabbitMQ or Kafka. The message queue shields the complexity of communication for the application, and improves the asynchronous communication and expansion decoupling capability of the system.

[0058] The alarm management module 120 is communicatively connected with the alarm generation module 110 based on the second message queue 102, for receiving alarm data, and configuring the alarm data according to an alarm rule engine to generate event alarm data and / or threshold alarm data. Meanwhile, the alarm management module 120 is also communicatively connected with the application module 150 in the distributed dispatching system based on the third message queue 103, for publishing the event alarm data and / or the threshold alarm data to the third message queue 103 for subscription by the application module 150. The second message queue 102 and the third message queue 103 can also be implemented through a message middleware RabbitMQ or Kafka.

[0059] The alarm rule engine is used to process the alarm data to obtain event alarm data and threshold alarm data. The threshold alarm data refers to alarm data triggered by setting a threshold for monitoring index data or using a related operation on the threshold. Alarm data other than the threshold alarm data can be classified as event alarm data. It can also be considered that alarm data triggered by a logical event generated by the operation of a device or a system is event alarm data.

[0060] The application module 150 is an interface module for providing application functions to users in the distributed dispatching system, and can include a display module and the like. The alarm management module 120 publishes the event alarm data and / or the threshold alarm data to the third message queue 103, and the application module 150 obtains the alarm data through a subscription mechanism, thereby decoupling the alarm service and the business application.

[0061] The alarm notification module 130 is in communication connection with the alarm management module 120 based on the fourth message queue 104, and is configured to generate an alarm notification based on the event alarm data and / or the threshold alarm data, and determine a notification strategy and a notification mode of the alarm notification based on an alarm level of the alarm notification. The fourth message queue 104 can also be implemented through the message middleware RabbitMQ or Kafka.

[0062] The notification strategy can include a notification period, a notification valid time period, a notification condition, a notification channel, and a notification object, and the like. The notification period refers to a sending period of the alarm notification. If the resource is always in an alarm state and has not recovered to normal, how long is the interval for sending the next notification. Several options are provided, such as 5 minutes, 10 minutes, 15 minutes, 30 minutes, 1 hour, 3 hours, 6 hours, 12 hours, and 24 hours. The notification valid time period refers to a time period for limiting the sending event of the alarm notification. The alarm notification is only sent within the specified time range, and by default, the alarm notification is sent all day. The notification condition refers to a prerequisite condition for sending the alarm notification. Two scenarios, “alarm” and “recovery to normal”, are provided, and by default, only the alarm state is sent, and the notification condition must be specified. The notification channel includes email, instant messaging software, short message, and telephone, and the like. By default, the sending is selected according to the alarm level, and can be selected as needed. The notification object is a contact or a contact group that needs to be notified, and the like. The notification mode is a combination of the notification channels.

[0063] The alarm management device based on the rail transit distributed dispatching system provided in the embodiments of the present application includes an alarm generation module, an alarm management module, and an alarm notification module. The alarm generation module is configured to obtain alarm data. The alarm management module is configured to configure the alarm data based on an alarm rule engine, generate event alarm data and / or threshold alarm data, and publish the event alarm data and / or the threshold alarm data to a third message queue for subscription by an application module. The alarm notification module is configured to generate an alarm notification based on the event alarm data and / or the threshold alarm data, and determine a notification strategy and a notification mode of the alarm notification based on an alarm level of the alarm notification. The connection of the modules and the connection of the modules with the rail transit distributed dispatching system and a third-party system are implemented through a communication queue. The publication of the alarm data is implemented through a subscription mechanism. The alarm function is separated from the business implementation. The system is easy to expand, and the coupling is low. The combination of the three modules implements the processing flow of the alarm data, reduces the system complexity of the alarm management device and the rail transit distributed dispatching system, and implements the alarm function in the rail transit distributed dispatching system.

[0064] Based on the above embodiments, the alarm generation module is specifically used for:

[0065] Obtaining initial alarm data sent by a service module or a third-party system;

[0066] Parsing the initial alarm data to determine the message type, alarm type, alarm source, alarm classification, and alarm level corresponding to the initial alarm data;

[0067] Generating alarm data based on the message type, alarm type, alarm source, alarm classification, and alarm level corresponding to the initial alarm data.

[0068] Specifically, the service module and each third-party system in the distributed dispatching system generate alarm data in different ways. The generation rules of these alarm data are not unified, and the data structures are different, which will result in low utilization rate of the alarm data. These alarm data can be adjusted.

[0069] According to the data communication specification in the distributed dispatching system, a message model can be established to adjust the initial alarm data sent by the service module or the third-party system.

[0070] The distributed dispatching system defines a standard data communication specification: unified message model, communication instruction, communication process, and timeout mechanism. The message model includes seven message types, among which the alarm and information types are related to the alarm function. The alarm message includes alarm data, and the threshold alarm function extracts index information from the information message.

[0071] The data communication specification specifically defines the message type, alarm type, alarm source, alarm classification, and alarm level.

[0072] The initial alarm data can be transmitted in the form of a communication data packet, for example, in JSON format.

[0073] The message types include command, information, alarm, notification, response, receipt, and heartbeat. The command is a control command that requests to perform an operation. The execution party sends a receipt message after receiving the command message, and sends a response message after the command is executed. The information is data information and reported data. The receipt message is optional according to the requirements. The alarm is an alarm information sent by the system when a fault or emergency occurs. The notification is a progress feedback of the control process execution. The heartbeat is a heartbeat packet sent at regular intervals to maintain the alive state and ensure the connection effective mechanism. The receipt is a feedback to the received communication instruction. The response is the execution result of the command.

[0074] The alarm types include threshold alarm and event alarm.

[0075] The alarm sources include the distributed dispatching system and the third-party system connected to the distributed dispatching system.

[0076] The alarm classification includes service alarm and system alarm. The service alarm refers to alarm data related to service. The system alarm refers to alarm data related to system monitoring. For example, monitoring alarms generated by Prometheus, including server resource (CPU, memory, disk space, etc.) alarms, alarms generated by middleware, database, service application exception, etc.

[0077] The alarm level includes critical, warning and info, and the corresponding alarm levels are 1, 2 and 3 respectively, and the alarm severity relationship is 1>2>3.

[0078] For critical alarms, the failure of this level affects the services provided by the system, and corresponding actions need to be taken immediately. For example, a device or resource is completely unavailable, and recovery is required, even if the failure occurs during non-working hours, measures need to be taken immediately.

[0079] For warning alarms, the failure of this level affects the quality of service, and urgent actions need to be taken. For example, the quality of service of a device or resource is reduced, and it needs to be restored to full capacity, and measures need to be taken immediately during working hours.

[0080] For prompt alarms, the failure of this level has not yet affected the quality of service, but in order to avoid more serious failures, it needs to be handled or further observed at an appropriate time.

[0081] The initial alarm data is parsed to determine the message type, alarm type, alarm source, alarm classification and alarm level corresponding to the initial alarm data, and then alarm data is generated according to these information. For example, the generated alarm data can be embodied in the form of a table, as shown in Table 1.

[0082] Table 1 Alarm data

[0083]

[0084]

[0085] The alarm management device based on the rail transit distributed dispatching system provided by the embodiment of the application formulates a unified alarm data specification, including message type, alarm type, alarm source, alarm classification and alarm level, and improves the data utilization rate of alarm data.

[0086] Based on any of the above embodiments, Figure 2 The structure diagram of the alarm management module provided by the application is shown as Figure 2 The alarm management module specifically includes:

[0087] The alarm configuration submodule 121 is configured to configure alarm data based on an alarm rule engine, generate event alarm data and / or threshold alarm data.

[0088] The alarm storage submodule 122 is connected with the alarm configuration submodule 121 and is configured to store the event alarm data and the threshold alarm data into a database.

[0089] The alarm publishing submodule 123 is connected with the alarm configuration submodule 121 and is configured to publish the event alarm data and / or the threshold alarm data to a third message queue.

[0090] Specifically, the alarm configuration submodule is mainly configured to configure alarm data based on an alarm rule engine, generate event alarm data and / or threshold alarm data. Each alarm data of the distributed scheduling system needs to be configured in the alarm service module, and the alarm data uploaded by the third-party system also needs to be configured. The event alarm and the threshold alarm are generated in different ways, and the configuration methods are also different. The threshold alarm utilizes the rule engine mechanism to achieve dynamic configuration. The alarm notification can also be dynamically configured.

[0091] For the alarm rule engine, the generation rules of the event alarm and the threshold alarm are different. The event alarm generation rules of different business modules (including the third-party system) are diverse, and even there is no fixed mode. Therefore, the event alarm is generated by the business module according to the alarm data specification, and the alarm data is uploaded to the alarm service module through the alarm message (the data format of the alarm data of the third-party system is converted before being uploaded to the alarm service module). The threshold alarm utilizes the rule engine mechanism to achieve dynamic configuration. In the alarm management submodule, the index information, the threshold information, the calculation rule and the rule SQL statement are configured. The business module calls the threshold alarm interface provided by the alarm management submodule, and transmits the information message as a parameter, so as to generate the threshold alarm, and upload the threshold alarm to the alarm management submodule.

[0092] The alarm storage submodule is connected with the alarm configuration submodule and is mainly configured to store the event alarm data and the threshold alarm data into a database. The database can adopt a relational database (PostgreSQL) or a time series database (TimescaleDB). The event alarm data and the threshold alarm data can be stored in different data tables.

[0093] The alarm publishing submodule is connected with the alarm configuration submodule and is mainly configured to publish the event alarm data and / or the threshold alarm data to a third message queue.

[0094] The alarm publishing subunit selects a third message queue to publish event alarm data and / or threshold alarm data, and can realize decoupling of the alarm and the service. The alarm publishing subunit in the alarm management module serves as a producer, and after publishing a piece of alarm data, the alarm management module no longer cares who consumes the alarm data. Multiple application modules can simultaneously subscribe to the alarm data, and each application module processes the alarm event according to its own service.

[0095] Based on any of the above embodiments, the alarm management module further specifically includes:

[0096] The alarm management sub-module is connected with the alarm storage sub-module and the alarm configuration sub-module, and is configured to perform data management on the event alarm data and / or the threshold alarm data in the database, and to perform dynamic configuration on the alarm rule engine.

[0097] Specifically, the alarm management sub-module is connected with the alarm storage sub-module, and can perform operations such as adding, modifying and deleting on the event alarm data and / or the threshold alarm data in the alarm storage sub-module through a database query statement, to realize data management. The alarm management sub-module is connected with the alarm configuration sub-module, and can realize dynamic configuration on the alarm rule engine.

[0098] The alarm management sub-module can provide a visual user interface constructed according to an H5 page, so that a user can complete data management and rule configuration through the interface.

[0099] Based on any of the above embodiments, the alarm management module further specifically includes:

[0100] The alarm silencing sub-module is connected with the alarm configuration sub-module, and is configured to stop publishing event alarm data and / or threshold alarm data to the third message queue within a preset silencing period corresponding to a preset silencing condition, if the event alarm data and / or the threshold alarm data meet the preset silencing condition.

[0101] Specifically, the silencing period refers to a time interval for repeatedly sending alarm notifications if an alarm has not been recovered to normal. The preset silencing condition is a condition for limiting the publishing of alarm data.

[0102] The alarm silencing sub-module judges whether the event alarm data and / or the threshold alarm data meet the preset silencing condition. If it is determined that the preset silencing condition is met, the event alarm data and / or the threshold alarm data are stopped from being published to the third message queue within the silencing period corresponding to the preset silencing condition. At this time, alarm data within the silencing period after triggering the preset silencing condition is only stored in the database, is not published to the third message queue, and alarm notifications are not sent.

[0103] The silencing period can be configured in the threshold table, and the silencing period is in units of minutes.

[0104] Based on any of the above embodiments, the alarm configuration submodule is specifically configured to:

[0105] determine the alarm type of any alarm data;

[0106] in the case of an event alarm, determine the event table and event alarm table corresponding to any alarm data;

[0107] based on the event table and the event alarm table, determine the event alarm data corresponding to any alarm data.

[0108] Specifically, the event alarm data generation rule is determined by the business module or the third-party system, but the event alarm data needs to be sent to the alarm management module for unified management, and the basic configuration information of the event is needed, otherwise it cannot be managed.

[0109] Therefore, in the case of determining that the alarm type of any alarm data is an event alarm, the event table (t_event) and the event alarm table (t_event_alarm) corresponding to the alarm data can be configured, as shown in Table 2 and Table 3.

[0110] Table 2 Event Table

[0111]

[0112] Table 3 Event Alarm Table

[0113]

[0114]

[0115] The alarm configuration submodule provides a rule engine. The rule engine provides a clear and flexible configuration method for alarm management scheme, simplifies the alarm development process, improves user ease of use, and reduces the coupling degree of business modules and alarm management modules; provides an excellent basic framework for distributed scheduling system function customization. The concepts related to the rule engine include: rule, action, resource, and resource type.

[0116] The rule (rule) is composed of a SQL statement and an action list. The action list contains one or more actions and their parameters. The SQL statement is used to filter fields from raw data according to conditions, and to preprocess and convert. The rule describes where the data comes from, how to filter and process the data, and where the processing result goes. Three configurations, that is, a usable rule contains three elements:

[0117] Trigger event: the rule is triggered by an event, and the event injects the context information (data source) of the event into the rule through the FROM clause of the SQL to specify the event type;

[0118] Processing rule (SQL): filter and process data from the context information using the SELECT clause and the WHERE clause and built-in processing functions;

[0119] Response action: if there is a processing result output, the rule will perform the corresponding action, such as persisting to the database, re-publishing the processed message, forwarding the message to the message queue, etc. A rule can be configured with multiple response actions.

[0120] Action is the task executed after the SQL statement is matched. The action defines an operation on the data. The action can be bound to a resource or not.

[0121] Resource is an object instantiated by a resource type as a template, which saves the configuration related to the resource (such as database connection address and port, username and password, etc.) and system resources (such as file handle, connection socket, etc.).

[0122] Resource type is a static definition of the resource, which describes the configuration items required by this type of resource.

[0123] For example, a rule can be represented as:

[0124] {SQL statement, action list: [{action 1, action parameter, bind resource: {resource configuration}}, {action 2, action parameter, bind resource: {resource configuration}}]}.

[0125] For the SQL statement, the basic format is:

[0126] SELECT <field name> FROM <topic> [WHERE <condition>]

[0127] Among them, the FROM clause mounts the rule to a certain topic (triggered when publishing a message to the topic, or triggered when the event occurs if the topic is an event topic); the SELECT clause is used to select the fields in the output result; the WHERE clause is used to filter messages according to the conditions.

[0128] Based on any of the above embodiments, the alarm configuration submodule is specifically configured to:

[0129] determine the alarm type of any alarm data;

[0130] in the case of threshold alarm, parse any alarm data to determine the index information and threshold information corresponding to any alarm data;

[0131] Based on the alarm rule engine, the threshold value information and the index information corresponding to any alarm data are calculated and verified to generate threshold value alarm data corresponding to any alarm data.

[0132] Specifically, the threshold value alarm is dynamically configured by using the rule engine mechanism. In the alarm management module, the index information, the threshold value information, the calculation rule, and the rule SQL statement are configured. The business module calls the threshold value alarm interface provided by the alarm management module, and transmits the information message as a parameter to generate the threshold value alarm and upload the alarm data to the alarm management module.

[0133] The threshold value alarm configuration needs to configure the index information, the threshold value information, and the alarm rule engine.

[0134] When the index information is configured, the index that needs to be threshold value alarmed is configured. The index information belongs to the submodule (similar to the subsystem or the device, etc.), and the submodule belongs to the business module (a business system or a microservice). The business module information and the submodule information need to be configured first when the index information is configured. The business module table (t_module), the submodule table (t_submodule), and the index table (t_quota) are shown in Tables 4, 5, and 6.

[0135] Table 4 Business module table

[0136]

[0137]

[0138] Table 5 Submodule table

[0139] Field Name Type Description id int8 Primary key id name varchar(50) Submodule name code varchar(10) Submodule code module_code int4 Business module code desc varchar(100) Description

[0140] Table 6 Index table

[0141]

[0142] When the threshold value information is configured, the threshold value information of the index that needs to be alarmed is configured, including the threshold value and the calculation rule. The same index can be configured with multiple threshold values, such as the high limit, the low limit, the high-high limit, and the low-low limit, but the configuration conflict needs to be avoided. The threshold table (t_threshold) and the threshold value alarm table (t_threshold_alarm) are shown in Tables 7 and 8.

[0143] Table 7 Threshold table

[0144]

[0145] Table 8 Threshold value alarm table

[0146]

[0147] When configuring the alarm rule engine, the message information table (t_info_msg) and the rule SQL statement need to be configured.

[0148] The alarm service module generates the configuration information of the rule engine table (t_rule_engine) and the rule quota table (t_rule_quota) according to the SQL statement. The main configuration of the rule engine is the configuration of the rule SQL statement, and the key information of the SQL statement configuration is: the information of the extracted indicators (indicator name, indicator value), and the information message id (infoId). The extracted configuration information is written into the rule engine table (t_rule_engine) and the rule engine quota table (t_rule_quota) respectively. The basic format is:

[0149] SELECT <field name> FROM <message message> [WHERE <condition>]

[0150] The information message table (t_info_msg), the rule engine table (t_rule_engine), and the rule quota table (t_rule_quota) are shown in Tables 9, 10, and 11.

[0151] Table 9 Information Message Table

[0152] Field Name Type Description id int8 Primary key id info_id int4 Information message id submodule_code int4 Submodule code desc varchar(100) Description

[0153] Table 10 Rule Engine Table

[0154] Field Name Type Description id int8 Primary key id rule_sql varchar(1000) Rule engine sql info_id int4 Information message id uniformly assigned desc varchar(100) Description

[0155] Table 11 Rule Quota Table

[0156]

[0157]

[0158] For example, to configure a threshold alarm case, the configuration of the indicator information quota1, quota2, the configuration of the threshold information of quota1, quota2, and the configuration of the rule engine information need to be performed. Among them, the configuration of the rule engine information includes:

[0159] (1) Rule SQL statement

[0160] SELECT quota1, quota2 FROM MESSAGE WHERE infoId=100001

[0161] (2) The generated configuration information is written into the tables: t_rule_engine, t_rule_quota

[0162] Indicator name: quota1, quota2

[0163] Information message id: 100001

[0164] The information message data can be written in Json format as

[0165] {"msgId":"1420041600000",

[0166] "msgType":2,

[0167] "serviceId":"service-a",

[0168] "msaId":"service-a-1",

[0169] "routingKey":"service-a-8001",

[0170] "traceId":"1420041600011","spanId":1,

[0171] "sign":"7F138A09169B250E9DCB378140907378",

[0172] "msgTs":"2015-03-05 17:59:00.567",

[0173] "msg":{"infoId":100001,"ack":1,"data":{"quota1":100,"quota2":50.5,"quota3":"2015-03-05 17:59:00.567"}}}

[0174] The business module extracts the indicator information to be alarmed from the information message model through the rule engine, and performs threshold checking according to the indicator information, threshold information, and rule SQL statement configured by the alarm management module to generate corresponding alarm data.

[0175] The threshold alarm data generation process is as follows:

[0176] Step one, the alarm management module configures the indicator information and threshold information of the business module;

[0177] Step two, the alarm management module configures the rule engine information and the rule SQL statement (mainly the indicator and information message id);

[0178] Step three, when the business module receives the information message, call the threshold alarm interface provided by the alarm management module, and need to pass parameter information message (Json);

[0179] Step four, the threshold alarm interface extracts the index information (index name, index value) and information message id (infoId) from the information message (Json) according to the rule engine configuration information; then according to the index and threshold configuration, the threshold alarm verification is carried out according to the calculation rule;

[0180] Step five, the threshold alarm interface generates the threshold alarm data and publishes the alarm message to the message queue (RabbitMQ or Kafka);

[0181] Step six, the alarm management module subscribes to the alarm message through the message queue and processes the corresponding alarm process.

[0182] The threshold alarm data verification process is as follows:

[0183] Step one, the threshold alarm interface extracts infoId = 100001 from the information message data (Json);

[0184] Step two, query the rule index table (t_rule_quota) through infoId (field info_id in data dictionary) to obtain the index name (quota1, quota2) to be extracted by the rule engine;

[0185] Step three, extract the index value (quota1 = 100, quota2 = 50.5) from the information message data (Json);

[0186] Step four, get the corresponding index id from the index table (t_quota) through infoId and index name (quota1, quota2);

[0187] Step five, retrieve the corresponding threshold information from the threshold table (t_threshold) through the index id;

[0188] Step six, perform index alarm threshold verification and generate alarm data;

[0189] Step seven, the threshold alarm data generates the alarm message and publishes it to the message queue (RabbitMQ or Kafka);

[0190] Step eight, the alarm management module consumes the alarm data from the message queue and stores it to the threshold alarm table (t_threshold_alarm).

[0191] Based on any of the above embodiments, the alarm publishing subunit is specifically used for:

[0192] Determine the subject of the event alarm data and / or threshold alarm data; the content of the subject includes the code of the business module, the code of the corresponding sub-module of the business module, the alarm data code and the index name;

[0193] Publish the subject to the third message queue for the application module to subscribe to the event alarm data and / or threshold alarm data based on the subject.

[0194] Specifically, the alarm publishing sub-unit in the alarm management module publishes alarm data through the third message queue, and the application module subscribes to and consumes alarm data through the topic (Topic) from the third message queue. The distributed scheduling system message queue selects RabbitMQ or Kafka, and there are some differences between the Topic of RabbitMQ and Kafka, which can be uniformly adapted.

[0195] The alarm data is published through the topic (Topic) of the third message queue, and each index selects its own topic rule, which is divided into four levels (1-module, 2-submodule, 3-message, and 4-index). The configuration of the topic rule is defined in the index table (t_quota) and the event table (t_event), and the naming rules of the topics at different levels are different. The specific level is configured according to actual needs.

[0196] The format of the topic name can be: / alarm / module code / submodule code / information message id / index name.

[0197] For example, module code (100001), submodule code (200002), information message id (300003), and index name (speed).

[0198] The published topic name is as follows:

[0199] 1-Module: / alarm / 100001

[0200] 2-Submodule: / alarm / 100001 / 200002

[0201] 3-Message: / alarm / 100001 / 200002 / 300003

[0202] 4-Index: / alarm / 100001 / 200002 / 300003 / speed

[0203] The application module selects the subscription topic level according to actual needs. Taking RabbitMQ as an example, the data in the above case is selected.

[0204] The subscription topic name is as follows:

[0205] 1-Module: / alarm / 100001 / #

[0206] 2-Submodule: / alarm / 100001 / 200002 /

[0207] 3-Message: / alarm / 100001 / 200002 / 300003 / *

[0208] 4-Indicator: / alarm / 100001 / 200002 / 300003 / speed

[0209] Based on any of the above embodiments, the event alarm data and the threshold alarm data in the database are stored in different data tables respectively.

[0210] Specifically, since the formats of the event alarm data and the threshold alarm data are different, the two different types of alarm data can be stored in different data tables respectively, which facilitates unified data management.

[0211] Based on any of the above embodiments, the alarm notification module is specifically configured to:

[0212] determine the alarm level of the alarm notification;

[0213] in the case of an emergency alarm level, the notification mode of the alarm notification includes telephone notification, short message notification, email notification and instant messaging software notification;

[0214] in the case of a warning alarm level, the notification mode of the alarm notification includes short message notification, email notification and instant messaging software notification;

[0215] in the case of a prompt alarm level, the notification mode of the alarm notification includes email notification and instant messaging software notification.

[0216] Specifically, the alarm management module sends alarm data to the alarm notification module through the fourth message queue. The alarm notification module can configure communication methods, communication channels, notification strategies, contacts, contact groups, etc.

[0217] The notification mode of the alarm notification can include email notification, instant messaging software notification, short message notification and telephone notification, etc.

[0218] Email notification is not timely and is easy to be ignored; instant messaging software notification is timely, but may be ignored outside office hours; short message notification is cross-application and can be obtained even without network, and is more timely and message-penetrating; telephone notification is the most serious, timely and reliable alarm channel.

[0219] The alarm notification module selects an alarm notification mode according to the alarm level. It can also be modified as needed. In the case of an emergency alarm level, the notification mode includes telephone notification, SMS notification, email notification and instant messaging software notification; in the case of a warning alarm level, the notification mode includes SMS notification, email notification and instant messaging software notification; in the case of a prompt alarm level, the notification mode includes email notification and instant messaging software notification.

[0220] Based on any of the above embodiments, Figure 3 The alarm management schematic diagram of the rail transit distributed dispatching system provided by the present application is as shown in Figure 3 The alarm management function is realized in the rail transit distributed dispatching system, which is embodied in the following aspects:

[0221] 1. A unified alarm data specification is formulated, including alarm messages, alarm types, alarm classifications, alarm sources and message models;

[0222] 2. A standard alarm processing flow is formulated, including alarm generation (three-party system alarm data access), storage, release and notification;

[0223] 3. An independent alarm service is developed to realize alarm-related business requirements, including alarm management, visual configuration, generation, storage, release and notification;

[0224] 4. Alarm rules are dynamically configured, and a rule engine is used to extract index information from the message model to realize dynamic generation of threshold alarms;

[0225] 5. The message queue release / subscription mechanism is used to release alarm data, and the alarm function is decoupled from the business application.

[0226] The beneficial effects are as follows:

[0227] 1. Internet advanced technology is used in combination with traditional technology, and the business module and the application module are integrated with each other;

[0228] 2. A unified alarm data specification is formulated to be compatible with the heterogeneous alarm data of three-party systems;

[0229] 3. A standard alarm processing flow is established to reduce system implementation complexity;

[0230] 4. The alarm function and the business implementation are designed separately, which realizes low coupling and easy system expansion;

[0231] 5. The alarm rules can be dynamically configured to reduce system development and maintenance costs.

[0232] The device embodiments described above are merely illustrative, wherein the units described as separate components can or can not be physically separate, and the components displayed as units can or can not be physical units, i.e., can be located in one place, or can be distributed to multiple network units. Part or all of the modules can be selected to achieve the purposes of the embodiments according to actual needs. Those skilled in the art can understand and implement without creative labor.

[0233] Through the description of the above embodiments, those skilled in the art can clearly understand that the embodiments can be realized by means of software and the necessary general hardware platform, and of course can also be realized by hardware. Based on such understanding, the above technical solutions can be embodied in the form of a software product, which can be stored in a computer readable storage medium, such as a ROM / RAM, a magnetic disk, an optical disk, etc., and includes a plurality of commands for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0234] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. An alarm management device based on a distributed dispatching system for rail transit, characterized in that, include: The alarm generation module communicates with the business modules in the rail transit distributed dispatch system and third-party systems based on the first message queue to obtain alarm data; The alarm management module is connected to the alarm generation module via a second message queue and to the application module in the rail transit distributed scheduling system via a third message queue. It is used to configure the alarm data based on the alarm rule engine, generate event alarm data and / or threshold alarm data, and publish the event alarm data and / or threshold alarm data to the third message queue for the application module to subscribe to. The alarm notification module is connected to the alarm management module via a fourth message queue. It is used to generate alarm notifications based on the event alarm data and / or threshold alarm data, and to determine the notification strategy and notification method of the alarm notification based on the alarm level of the alarm notification. The alarm management module specifically includes: The alarm configuration submodule is used to configure the alarm data based on the alarm rule engine and generate event alarm data and / or threshold alarm data. An alarm storage submodule, connected to the alarm configuration submodule, is used to store the event alarm data and the threshold alarm data in a database. An alarm publishing subunit, connected to the alarm configuration submodule, is used to publish the event alarm data and / or threshold alarm data to the third message queue; the event alarm data is alarm data triggered by logical events generated by the operation of the device or system; The alarm management submodule, connected to the alarm storage submodule and the alarm configuration submodule, is used to manage event alarm data and / or threshold alarm data in the database, and to dynamically configure the alarm rule engine.

2. The alarm management device based on a distributed dispatching system for rail transit according to claim 1, characterized in that, The alarm generation module is specifically used for: Obtain the initial alarm data sent by the business module or the third-party system; The initial alarm data is parsed to determine the message type, alarm type, alarm source, alarm classification, and alarm level corresponding to the initial alarm data; The alarm data is generated based on the message type, alarm type, alarm source, alarm classification, and alarm level corresponding to the initial alarm data.

3. The alarm management device based on a distributed dispatching system for rail transit according to claim 1, characterized in that, The alarm management module also specifically includes: An alarm silencing submodule, connected to the alarm configuration submodule, is used to stop publishing the event alarm data and / or the threshold alarm data to the third message queue within the silencing period corresponding to the preset silencing conditions when the event alarm data and / or the threshold alarm data meet the preset silencing conditions.

4. The alarm management device based on a distributed dispatching system for rail transit according to claim 1, characterized in that, The alarm configuration submodule is specifically used for: Determine the alarm type for any given alarm data; When the alarm type is an event alarm, determine the event table and event alarm table corresponding to any alarm data; Based on the event table and the event alarm table, determine the event alarm data corresponding to any alarm data.

5. The alarm management device based on a distributed dispatching system for rail transit according to claim 1, characterized in that, The alarm configuration submodule is specifically used for: Determine the alarm type for any given alarm data; When the alarm type is a threshold alarm, any alarm data is parsed to determine the corresponding indicator information and threshold information for any alarm data; Based on the alarm rule engine, the indicator information and threshold information corresponding to any alarm data are calculated and verified to generate threshold alarm data corresponding to any alarm data.

6. The alarm management device based on a distributed dispatching system for rail transit according to claim 1, characterized in that, The alarm issuing subunit is specifically used for: Determine the subject of the event alarm data and / or threshold alarm data; the subject includes the code of the business module, the code of the corresponding sub-module of the business module, the alarm data code, and the indicator name; The topic is published to the third message queue so that the application module can subscribe to the event alarm data and / or threshold alarm data based on the topic.

7. The alarm management device based on a distributed dispatching system for rail transit according to claim 1, characterized in that, The event alarm data and the threshold alarm data in the database are stored in different data tables.

8. The alarm management device based on a distributed dispatching system for rail transit according to any one of claims 1 to 7, characterized in that, The alarm notification module is specifically used for: Determine the alarm level of the alarm notification; When the alarm level is emergency, the notification method for the alarm notification includes telephone notification, SMS notification, email notification, and instant messaging software notification. When the alarm level is warning, the notification method for the alarm notification is determined to include SMS notification, email notification, and instant messaging software notification; When the alarm level is set to "prompt", the notification method for the alarm notification is determined to include email notification and instant messaging software notification.

Citation Information

Patent Citations

  • Pre-warning system and method for railway signal equipment

    CN110758478A

  • High-availability distributed real-time alarm processing method and high-availability distributed real-time alarm processing system

    CN112671560A