CN117009105B - Method for pre-alarming state of subway vehicle-mounted equipment based on storm flow calculation in real time - Google Patents
Method for pre-alarming state of subway vehicle-mounted equipment based on storm flow calculation in real time Download PDFInfo
- Publication number
- CN117009105B CN117009105B CN202310916612.4A CN202310916612A CN117009105B CN 117009105 B CN117009105 B CN 117009105B CN 202310916612 A CN202310916612 A CN 202310916612A CN 117009105 B CN117009105 B CN 117009105B
- Authority
- CN
- China
- Prior art keywords
- topic
- message
- alarm
- storm
- rule
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 26
- 238000005070 sampling Methods 0.000 claims abstract description 68
- 238000012795 verification Methods 0.000 claims abstract description 13
- 238000012544 monitoring process Methods 0.000 claims abstract description 7
- 238000012545 processing Methods 0.000 claims description 30
- 238000003491 array Methods 0.000 claims description 6
- 230000007423 decrease Effects 0.000 claims description 6
- 230000005540 biological transmission Effects 0.000 claims description 3
- 230000000593 degrading effect Effects 0.000 claims description 3
- 238000011835 investigation Methods 0.000 abstract description 2
- 230000008569 process Effects 0.000 description 4
- 230000008439 repair process Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000036541 health Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G08—SIGNALLING
- G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
- G08B21/00—Alarms responsive to a single specified undesired or abnormal condition and not otherwise provided for
- G08B21/18—Status alarms
- G08B21/182—Level alarms, e.g. alarms responsive to variables exceeding a threshold
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Emergency Management (AREA)
- Alarm Systems (AREA)
Abstract
The invention discloses a method for pre-alarming subway vehicle-mounted equipment states in real time based on storm flow calculation, which comprises the steps of setting different kafka clusters according to classification of vehicle-mounted equipment, and setting a plurality of topic queues in each kafka cluster; setting a sampling interval and a pre-alarm index of a topic queue through a monitoring alarm prediction platform, and storing the set sampling interval and pre-alarm index into a Zookeeper cluster; the storm flow type computing platform reads the message of the topic queue in the kafka cluster through a kafkaspout component and performs format and time interval verification on the message read by a kafkaspout component by utilizing a validBolt component; the storm streaming computing platform uses pre-alarm indicators stored in the Zookeeper cluster to adapt messages in the topic. The method solves the problems that the operation state of the equipment cannot be detected in real time, the dimension index of alarm investigation is single, and the alarm parameters cannot be effectively controlled in real time in the subway vehicle-mounted equipment alarm method in the prior art.
Description
Technical Field
The invention relates to urban rail transit, in particular to a method for pre-alarming subway vehicle-mounted equipment state in real time based on storm flow calculation.
Background
The existing equipment alarming method in urban rail transit generally adopts hardware equipment to directly transmit alarming states when faults occur, and the method has the following problems: the running state of the equipment cannot be detected in real time, and the health condition and the alarm trend of the equipment cannot be predicted in advance; the alarm can be given after the fault occurs, and certain time is needed for the repair equipment to release the alarm, so that the repair equipment has certain hysteresis; the dimension index of alarm investigation is single, and the method is not suitable for equipment needing multidimensional and multi-index comparison; some devices which do not have an alarm function cannot actively analyze own data and alarm; massive data are difficult to process, and the alarm parameters cannot be effectively controlled in real time; different devices cannot be processed according to the priority.
Disclosure of Invention
The invention aims to: the invention aims to provide a method for pre-alarming subway vehicle-mounted equipment state based on stop flow calculation, which improves the alarming efficiency and accuracy of urban rail transit equipment and better ensures the operation safety and equipment reliability.
The technical scheme is as follows: in order to achieve the purpose, the method for pre-alarming the state of the subway vehicle-mounted equipment based on the storm flow calculation comprises the following steps:
Step S1: different kafka clusters are set according to the classification of the vehicle-mounted equipment, and a plurality of topic queues are set in each kafka cluster and used for storing messages generated by different vehicle-mounted equipment;
Step S2: setting a sampling interval and a pre-alarm index of a topic queue through a monitoring alarm prediction platform, and storing the set sampling interval and pre-alarm index into a Zookeeper cluster;
Step S3: the storm flow type computing platform reads the message of the topic queue in the kafka cluster through a kafkaspout component and performs format and time interval verification on the message read by a spout component by utilizing a validBolt component;
Step S4: the storm streaming computing platform uses pre-alarm indicators stored in the Zookeeper cluster to adapt messages in the topic.
And step S1, naming rules of the topic queue names are English abbreviations of different vehicle-mounted devices.
The time unit of the sampling interval in the step S2 is millisecond, when the sampling interval is increased, the message processing priority of the topic queue is reduced, and when the sampling interval is reduced, the message processing priority of the topic queue is increased; the sampling interval is stored in the "/store/config/{ topic }/TIMEINTERVAL" node in the ZooKeeper cluster, where topic is a variable and refers to a specific topic queue name.
When the sampling time interval increases, the message processing priority of the topic queue decreases, and when the sampling time interval decreases, the message processing priority of the topic queue increases, specifically: the monitoring alarm prediction platform realizes the functions of upgrading or degrading the topic service by controlling the sampling interval time, when the sampling interval of the topic queue is enlarged, the sampling frequency is reduced, the data volume of the acquired message is reduced, and the message is discarded more; when the sampling interval is set to infinity, the data acquisition of the topic message is closed, and the service level of the equipment is the lowest; when the sampling interval is reduced, the sampling frequency is increased, the sampling data volume is increased, and the message is preferably focused and pre-warned.
When the data volume of the message to be processed in one type of topic queue is large and the importance is low, the sampling interval of the topic queue is set to infinity.
The pre-alarm indexes in the step S2 are set to be 0-N and are in json array format, and the specific form is as follows: each json object in the array is a rule index, and the rule format of the json object is { "rule number": "," rule type ":", "rule description": "," rule symbol ":", "rule threshold": "," reference value ":", "rule unit": "," processing suggestion ":", "sampling time": timestamp }; the pre-alarm index is stored in a "/store/config/{ topic }/alarmIndex" node in the ZooKeeper cluster, wherein topic is a variable and refers to a specific topic name.
And step S3, the storm real-time computing platform reads the message in the topic queue through the kafkaspout component, and performs format and time interval verification on the message read by the spout component by utilizing the validBolt component, wherein each spout component is responsible for reading the designated topic queue, meanwhile, the output of the spout component is input into the designated Bolt component, and the Bolt component performs data format and time interval verification on the message read by the spout component.
The Bolt component performs data format and time interval verification on the message read by spout, specifically: the Bolt component checks the json data format of the message output by the spout component; if the json format is met, continuing to check the sampling interval, wherein the validBolt component reads node information in the Zookeeper cluster according to the topic which is responsible for the sampling interval, and the nodes comprise the sampling interval in the/store/config/{ topic }/TIMEINTERVAL,
The last processing time of the topic in the/storm/config/{ topic }/PREHADLETIME, if the interval between the current processing time and the last processing time is greater than or equal to the set sampling interval, forwarding the message to ComputeBolt, and updating the processing time to the/storm/config/{ topic }/PREHADLETIME node; wherein the output of each valid Bolt component is input into the specified ComputeBolt components.
The transmission of the message of topic in the kafka cluster, the time interval stored in the ZooKeeper cluster, the rule index and the alarm result, and the message in spout component, validBolt component and computeBolt component all adopt json format.
The storm flow computing platform in step S4 uses pre-alarm indexes stored in a Zookeeper cluster to adapt messages in a topic queue, which means that the pre-alarm indexes, that is, json arrays, [ { }, { }, … { }, are read, each json object rule format in the arrays is { "rule number": "," rule type ":", "rule description": "," rule symbol ":", "rule threshold": "," reference value ":", "rule unit": "," processing advice ":", "sampling time": timestamp }, and each message in the topic queue is computed by using the indexes, specifically:
When (|device status value-reference value|/reference value) > = rule threshold and type is alarm, the message is an alarm message; when (|equipment state value-reference value|/reference value) > = rule threshold and type is early warning, the result is early warning message;
after the message traversal in all topic queues is finished, counting traversal results, writing a first-level alarm in a ZooKeeper cluster when the number of alarm bars is more than 0, and notifying related personnel through a short message;
When the number of alarm bars is 0 and the number of early warning bars=1, three-level early warning is performed, and early warning grades are written in a ZooKeeper node;
when the number of alarm bars is 0 and the number of early warning bars=2, the alarm bars are secondary early warning, and early warning grades are written in a ZooKeeper node;
When the number of alarm bars is 0 and the number of early warning bars > =3, the early warning is first-level, the early warning level is written in the ZooKeeper node, and relevant personnel are notified through short messages.
The beneficial effects are that: the invention has the following advantages: 1. according to the invention, the storm flow type computing platform is utilized to analyze and process mass data of the state of the vehicle-mounted equipment, and the running state of the equipment is early warned in real time. Meanwhile, by setting sampling intervals of different topic queues and adjusting the priority of early warning, the state change of equipment can be managed and responded better, the time cost is saved for equipment repair, and the running safety of the equipment is improved;
2. The real-time early warning method can be independently deployed or container deployed according to the actual field environment, so that the equipment state data can be quickly and effectively received and analyzed, and a foundation is provided for the application of the intelligent operation and maintenance system of the vehicle.
Drawings
FIG. 1 is a schematic diagram of a framework for a storm streaming computing platform to process messages;
fig. 2 is a flow chart of a storm streaming computing platform processing a message.
Detailed Description
The technical scheme of the present invention will be described in detail with reference to the following examples and the accompanying drawings.
As shown in fig. 1, the method for pre-alarming the state of the subway vehicle-mounted equipment based on the storm flow calculation comprises the following steps:
Step S1: different kafka clusters are set according to the classification of the vehicle-mounted equipment, and a plurality of topic queues are set in each kafka cluster and used for storing messages generated by different vehicle-mounted equipment;
Step S2: setting a sampling interval and a pre-alarm index of a topic queue through a monitoring alarm prediction platform, and storing the set sampling interval and pre-alarm index into a Zookeeper cluster;
Step S3: the storm flow type computing platform reads the message of the topic queue in the kafka cluster through a kafkaspout component and performs format and time interval verification on the message read by a spout component by utilizing a validBolt component;
Step S4: the storm streaming computing platform uses pre-alarm indicators stored in the Zookeeper cluster to adapt messages in the topic.
And step S1, naming rules of the topic queue names are English abbreviations of different vehicle-mounted devices.
The time unit of the sampling interval in the step S2 is millisecond, when the sampling interval is increased, the message processing priority of the topic queue is reduced, and when the sampling interval is reduced, the message processing priority of the topic queue is increased; the sampling interval is stored in the "/store/config/{ topic }/TIMEINTERVAL" node in the ZooKeeper cluster, where topic is a variable and refers to a specific topic queue name.
When the sampling time interval increases, the message processing priority of the topic queue decreases, and when the sampling time interval decreases, the message processing priority of the topic queue increases, specifically: the monitoring alarm prediction platform realizes the functions of upgrading or degrading the topic service by controlling the sampling interval time, when the sampling interval of the topic queue is enlarged, the sampling frequency is reduced, the data volume of the acquired message is reduced, and the message is discarded more; when the sampling interval is set to infinity, the data acquisition of the topic message is closed, and the service level of the equipment is the lowest; when the sampling interval is reduced, the sampling frequency is increased, the sampling data volume is increased, and the message is preferably focused and pre-warned.
When the data volume of the message to be processed in one type of topic queue is large and the importance is low, the sampling interval of the topic queue is set to infinity.
The pre-alarm indexes in the step S2 are set to be 0-N and are in json array format, and the specific form is as follows: each json object in the array is a rule index, and the rule format of the json object is { "rule number": "," rule type ":", "rule description": "," rule symbol ":", "rule threshold": "," reference value ":", "rule unit": "," processing suggestion ":", "sampling time": timestamp }; the pre-alarm index is stored in a "/store/config/{ topic }/alarmIndex" node in the ZooKeeper cluster, wherein topic is a variable and refers to a specific topic name.
As shown in fig. 2, in step S3, the storm real-time computing platform reads the message in the topic queue through the kafkaspout component, and performs format and time interval verification on the message read by the spout component by using the validBolt component, where each spout component is responsible for reading the designated topic queue, and meanwhile, the output of the spout component is input to the designated Bolt component, and the Bolt component performs data format and time interval verification on the message read by spout.
The Bolt component performs data format and time interval verification on the message read by spout, specifically: the Bolt component checks the json data format of the message output by the spout component; if the json format is met, continuing to check the sampling interval, wherein the validBolt component reads node information in the Zookeeper cluster according to the topic which is responsible for the sampling interval, and the nodes comprise the sampling interval in the/store/config/{ topic }/TIMEINTERVAL,
The last processing time of the topic in the/storm/config/{ topic }/PREHADLETIME, if the interval between the current processing time and the last processing time is greater than or equal to the set sampling interval, forwarding the message to ComputeBolt, and updating the processing time to the/storm/config/{ topic }/PREHADLETIME node; wherein the output of each valid Bolt component is input into the specified ComputeBolt components.
The transmission of the message of topic in the kafka cluster, the time interval stored in the ZooKeeper cluster, the rule index and the alarm result, and the message in spout component, validBolt component and computeBolt component all adopt json format.
The storm flow computing platform in step S4 uses pre-alarm indexes stored in a Zookeeper cluster to adapt messages in a topic queue, which means that the pre-alarm indexes, that is, json arrays, [ { }, { }, … { }, are read, each json object rule format in the arrays is { "rule number": "," rule type ":", "rule description": "," rule symbol ":", "rule threshold": "," reference value ":", "rule unit": "," processing advice ":", "sampling time": timestamp }, and each message in the topic queue is computed by using the indexes, specifically:
When (|device status value-reference value|/reference value) > = rule threshold and type is alarm, the message is an alarm message; when (|equipment state value-reference value|/reference value) > = rule threshold and type is early warning, the result is early warning message;
after the message traversal in all topic queues is finished, counting traversal results, writing a first-level alarm in a ZooKeeper cluster when the number of alarm bars is more than 0, and notifying related personnel through a short message;
When the number of alarm bars is 0 and the number of early warning bars=1, three-level early warning is performed, and early warning grades are written in a ZooKeeper node;
when the number of alarm bars is 0 and the number of early warning bars=2, the alarm bars are secondary early warning, and early warning grades are written in a ZooKeeper node;
When the number of alarm bars is 0 and the number of early warning bars > =3, the early warning is first-level, the early warning level is written in the ZooKeeper node, and relevant personnel are notified through short messages.
According to the invention, the storm flow type computing platform is utilized to analyze and process mass data of the state of the vehicle-mounted equipment, and the running state of the equipment is early warned in real time. Meanwhile, by setting sampling intervals of different topic queues and adjusting the priority of early warning, the state change of the equipment can be managed and responded better, and the running safety of the equipment is improved.
The invention can be independently deployed or container deployed according to the actual environment of the site, and the like, so as to quickly and effectively receive and analyze the equipment state data, and provide a foundation for the application of the intelligent operation and maintenance system of the vehicle.
Claims (9)
1. A method for pre-alarming the state of subway vehicle-mounted equipment based on storm flow calculation is characterized by comprising the following steps:
Step S1: different kafka clusters are set according to the classification of the vehicle-mounted equipment, and a plurality of topic queues are set in each kafka cluster and used for storing messages generated by different vehicle-mounted equipment;
Step S2: setting a sampling interval and a pre-alarm index of a topic queue through a monitoring alarm prediction platform, and storing the set sampling interval and the pre-alarm index into a Zookeeper cluster, wherein the time unit of the sampling interval is millisecond, when the sampling interval is increased, the message processing priority of the topic queue is reduced, and when the sampling interval is reduced, the message processing priority of the topic queue is increased; the sampling interval is stored in the "/storm/config/{ topic }/TIMEINTERVAL" node in the ZooKeeper cluster;
Step S3: the storm flow type computing platform reads the message of the topic queue in the kafka cluster through the kafka spout component, and performs format and time interval verification on the message read by the kafka spout component by using the valid Bolt component;
Step S4: the storm flow computing platform utilizes pre-alarm indexes stored in a Zookeeper cluster to adapt messages in the topic, namely, json arrays, including { }, { }, … { }, wherein each json object rule format in the arrays is { "rule number": "," rule type ":", "rule description": "," rule symbol ":", "rule threshold": "," reference value ":", "rule unit": "," processing advice ":", "sampling time": timestamp }, and each message in the topic queue is computed by application index according to the rule indexes, namely:
When (|device status value-reference value|/reference value) > = rule threshold and type is alarm, the message is an alarm message; when (|equipment state value-reference value|/reference value) > = rule threshold and the type is early warning, the message is an early warning message;
After the message traversal in all topic queues is finished, counting traversal results, writing a first-level alarm in a ZooKeeper cluster when the number of alarm bars is more than 0, and notifying related personnel through a short message;
when the number of alarm bars is 0 and the number of early warning bars=1, three-level early warning is performed, and early warning grades are written in a ZooKeeper node;
When the number of alarm bars is 0 and the number of early warning bars=2, the alarm bars are secondary early warning, and early warning grades are written in a ZooKeeper node;
When the number of alarm bars is 0 and the number of early warning bars > =3, the early warning is first-level, the early warning level is written in the ZooKeeper node, and relevant personnel are notified through short messages.
2. The method for real-time pre-alarming of subway vehicle equipment states based on storm-stream calculation according to claim 1, wherein the rule of naming the names of the topic queues in step S1 is english abbreviations of different vehicle-mounted equipment.
3. The method for real-time pre-alarming of subway vehicle equipment status based on stop flow calculation according to claim 1, wherein in the step S2, the "/stop/config/{ topic }/TIMEINTERVAL" node is defined, wherein topic is a variable, and refers to a specific topic queue name.
4. A method for real-time pre-alarming of a subway vehicle device status based on a stop stream calculation according to claim 3, wherein the message processing priority of the topic queue decreases when the sampling time interval increases, and the message processing priority of the topic queue increases when the sampling time interval decreases, specifically: the monitoring alarm prediction platform realizes the functions of upgrading or degrading the topic service by controlling the sampling interval time, when the sampling interval of the topic queue is enlarged, the sampling frequency is reduced, the data volume of the acquired message is reduced, and the message is discarded more; when the sampling interval is set to infinity, the data acquisition of the topic message is closed, and the service level of the equipment is the lowest; when the sampling interval is reduced, the sampling frequency is increased, the sampling data volume is increased, and the message is preferably focused and pre-warned.
5. The method for real-time pre-alarming of subway vehicle equipment states based on storm-stream calculation according to claim 3, wherein when the data amount of the message to be processed in one type of the topic queue is large and the importance is low, the sampling interval of the topic queue is set to infinity.
6. The method for real-time pre-alarming of the state of the subway vehicle-mounted equipment based on the storm-based flow calculation according to claim 1, wherein in the step S2, the pre-alarming indexes are set to be 0-N and are in json array format, and the pre-alarming indexes are stored in "/storm/config/{ topic }/alarmIndex" nodes in a ZooKeeper cluster, wherein topic is a variable and refers to a specific topic name.
7. The method for real-time pre-alarming of the state of the subway vehicle-mounted equipment based on the storm-based stream calculation according to claim 1, wherein in step S3, the storm-based stream calculation platform reads the message in the topic queue through kafka spout components and performs format and time interval verification on the message read by spout components by using valid Bolt components, wherein each spout component is responsible for reading the designated topic queue, meanwhile, the output of spout components is input into the designated Bolt components, and the Bolt components perform data format and time interval verification on the message read by spout.
8. The method for real-time pre-alarming of the state of the subway vehicle-mounted equipment based on the storm-flow calculation according to claim 7, wherein the Bolt component performs data format and time interval verification on the message read by spout, specifically: the Bolt component checks the json data format of the message output by the spout component; if the json format is met, continuing to check the sampling interval, reading node information in the Zookeeper cluster by the valid Bolt component according to the topic the valid Bolt component is responsible for, wherein the node comprises the sampling interval in the/store/config/{ topic }/TIMEINTERVAL,/store/config/{ topic }/PREHADLETIME and the last processing time of the topic, if the interval between the current processing time and the last processing time is greater than or equal to the set sampling interval, forwarding the message to the computer Bolt, and updating the processing time to the node of the/store/config/{ topic }/PREHADLETIME; wherein the output of each valid Bolt component is input into a specified computer Bolt component.
9. The method for real-time pre-alarming of the state of the subway vehicle-mounted equipment based on the storm flow calculation according to claim 8, wherein the transmission of the message of the topic in the kafka cluster, the time interval and the rule index stored in the ZooKeeper cluster and the alarming result, and the message in the spout component, the valid Bolt component and the computer Bolt component all adopt json formats.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310916612.4A CN117009105B (en) | 2023-07-25 | 2023-07-25 | Method for pre-alarming state of subway vehicle-mounted equipment based on storm flow calculation in real time |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310916612.4A CN117009105B (en) | 2023-07-25 | 2023-07-25 | Method for pre-alarming state of subway vehicle-mounted equipment based on storm flow calculation in real time |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN117009105A CN117009105A (en) | 2023-11-07 |
| CN117009105B true CN117009105B (en) | 2024-07-02 |
Family
ID=88570348
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310916612.4A Active CN117009105B (en) | 2023-07-25 | 2023-07-25 | Method for pre-alarming state of subway vehicle-mounted equipment based on storm flow calculation in real time |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117009105B (en) |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109801399A (en) * | 2018-12-29 | 2019-05-24 | 北京理工新源信息科技有限公司 | New energy vehicle failure Realtime Alerts method and system |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103220173B (en) * | 2013-04-09 | 2015-10-21 | 北京搜狐新媒体信息技术有限公司 | A kind of alarm monitoring method and supervisory control system |
| US9965330B2 (en) * | 2015-09-18 | 2018-05-08 | Salesforce.Com, Inc. | Maintaining throughput of a stream processing framework while increasing processing load |
| US11005933B2 (en) * | 2016-03-17 | 2021-05-11 | International Business Machines Corporation | Providing queueing in a log streaming messaging system |
| CN106778033B (en) * | 2017-01-10 | 2019-03-26 | 南京邮电大学 | A kind of Spark Streaming abnormal temperature data alarm method based on Spark platform |
| CN110035096A (en) * | 2018-01-12 | 2019-07-19 | 中科院微电子研究所昆山分所 | A kind of vehicle early warning processing system and early warning system based on Storm |
| CN110570012B (en) * | 2019-08-05 | 2022-05-20 | 华中科技大学 | A Storm-based fault warning method and system for power plant production equipment |
| CN112463543B (en) * | 2020-12-17 | 2024-08-23 | 江苏苏宁云计算有限公司 | Monitoring method of service data, rule data generation method, device and system |
| CN116368355A (en) * | 2021-09-05 | 2023-06-30 | 汉熵通信有限公司 | IoT system |
-
2023
- 2023-07-25 CN CN202310916612.4A patent/CN117009105B/en active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109801399A (en) * | 2018-12-29 | 2019-05-24 | 北京理工新源信息科技有限公司 | New energy vehicle failure Realtime Alerts method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN117009105A (en) | 2023-11-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US12086165B2 (en) | Cloud-based vehicle fault diagnosis method, apparatus, and system | |
| CN110196850B (en) | Vehicle data processing platform | |
| CN111651505B (en) | Equipment operation situation analysis and early warning method and system based on data driving | |
| CN106656590A (en) | Method and device for processing network equipment alarm message storm | |
| KR20180108446A (en) | System and method for management of ict infra | |
| CN115270933A (en) | Regional energy consumption monitoring data abnormity early warning method, system, device and storage medium | |
| CN105184084A (en) | Method and system for predicting fault type of electric power metering automation terminal | |
| CN114267178A (en) | Intelligent operation maintenance method and device for station | |
| CN115848463A (en) | Intelligent operation and maintenance system and method | |
| CN103034207A (en) | Infrastructure health monitoring system and implementation process thereof | |
| CN109445304A (en) | A kind of intelligent fault analysis system and method based on cab signal | |
| CN118052141A (en) | Operation data driven wind driven generator gear box fault early warning method and system | |
| CN118331239A (en) | Cloud computing-based new energy automobile remote diagnosis method and system | |
| CN119202534A (en) | A nuclear power closed bus intelligent monitoring model based on big data | |
| CN101807314A (en) | Method for processing embedded vehicle working condition hybrid heterogeneous data information in real time | |
| CN117009105B (en) | Method for pre-alarming state of subway vehicle-mounted equipment based on storm flow calculation in real time | |
| Feng et al. | Research of Deep Learning and Adaptive Threshold-Based Signaling Storm Prediction and Top Cause Tracking | |
| CN118550709B (en) | A method and system for efficiently processing and analyzing intelligent inspection data | |
| CN116578941A (en) | Unsupervised learning algorithm for improving power equipment abnormality alarm effective diagnosis capability | |
| CN117690296A (en) | Intelligent lightning protection detection system for traffic road conditions | |
| CN113988687B (en) | Nuclear power plant state monitoring method and system | |
| CN116863664A (en) | Real-time monitoring method and system for gas equipment | |
| CN101923605B (en) | Railway disaster prevention wind early warning method | |
| CN114861830A (en) | Automatic fault diagnosis method for vehicle-mounted equipment of subway signal system | |
| CN116522213A (en) | Service state level classification and classification model training method and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant |