Equipment abnormity alarm method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of equipment detection, and provides an equipment abnormity alarm method and device, electronic equipment and a storage medium. The method comprises the following steps: receiving state information sent by at least two different access devices in the building automation control system; determining an alarm rule corresponding to each access device, and verifying the state information corresponding to each access device through the alarm rule corresponding to each access device; and if the verification result of the state information of any access device is abnormal, generating device abnormity alarm information corresponding to any access device. According to the method and the device, the state information and the alarm rule of the access devices are managed in a centralized manner in the upper computer monitoring system, so that unified analysis and processing of alarm states of multiple devices are realized; therefore, the efficiency of fault positioning and abnormal response is improved, and the overall monitoring capability and the operation and maintenance management level of the building automation system are improved. The problem that troubleshooting is affected due to the fact that the alarm information of the access equipment is managed by respective equipment engines is avoided.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of device detection, and in particular to a device exception alarm method and device, an electronic device, and a storage medium. BACKGROUND

[0002] In a building automation control system, a plurality of types of devices are usually connected, including but not limited to temperature sensors, humidity sensors, lighting systems, and heating, ventilation, and air conditioning systems. In the prior art, alarm information of connected devices is usually managed by respective device engines, and alarm information is scattered, lacking a unified centralized management and coordination monitoring mechanism. This scattered alarm processing method makes it difficult for monitoring personnel to timely and comprehensively grasp the status of all connected devices, is not conducive to rapid response to device exceptions and unified troubleshooting of system-level faults, and affects the operation efficiency and management level of the building automation system. SUMMARY

[0003] Therefore, the embodiments of the present application provide a device exception alarm method and device, an electronic device, and a storage medium to solve the problem that alarm information of connected devices is managed by respective device engines in the prior art, affecting troubleshooting.

[0004] In a first aspect, a device exception alarm method is provided, which includes receiving state information sent by at least two different connected devices in a building automation control system, determining alarm rules corresponding to each connected device, and verifying state information corresponding to each connected device through alarm rules corresponding to each connected device. If the verification result of the state information of any connected device is abnormal, device exception alarm information corresponding to any connected device is generated.

[0005] In a second aspect, a device exception alarm device is provided, which includes a receiving module configured to receive state information sent by at least two different connected devices in a building automation control system, a verification module configured to determine alarm rules corresponding to each connected device and verify state information corresponding to each connected device through alarm rules corresponding to each connected device, and an alarm module configured to generate device exception alarm information corresponding to any connected device if the verification result of the state information of any connected device is abnormal.

[0006] In a third aspect, an electronic device is provided, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of the above method when executing the computer program.

[0007] In a fourth aspect, the present application provides a computer readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the method described above.

[0008] Compared with the prior art, the method provided in the embodiments of the present application has the beneficial effects that: the method provided in the embodiments of the present application receives state information sent by at least two different access devices in a building automation control system; determines an alarm rule corresponding to each access device, and verifies state information corresponding to each access device through the alarm rule corresponding to each access device; if the verification result of the state information of any access device is abnormal, device abnormality alarm information corresponding to the access device is generated, the present application centrally manages the state information and the alarm rule of the access device in the host computer monitoring system, realizes unified analysis and processing of the alarm state of multiple devices, avoids the information dispersion problem caused by the alarm information of the access device being respectively managed by the device engine of each device, thereby improving the efficiency of fault positioning and abnormal response, and helps to improve the overall monitoring capability and operation and maintenance level of the building automation system. The alarm information of the access device is respectively managed by the device engine, which avoids affecting fault locating. BRIEF DESCRIPTION OF DRAWINGS

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

[0010] Figure 1 is a flow diagram of a device abnormality alarm method provided by the embodiments of the present application;

[0011] Figure 2 is a structural diagram of a device abnormality alarm apparatus provided by the embodiments of the present application;

[0012] Figure 3 is a structural diagram of an electronic device provided by the embodiments of the present application. DETAILED DESCRIPTION

[0013] In the following description, specific details such as specific device structures, techniques, etc. are presented in order to thoroughly understand the embodiments of the present application. However, it should be clear to those skilled in the art that the present application can also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known devices, devices, circuits and methods are omitted to avoid unnecessary details that hinder the description of the present application.

[0014] A device abnormality alarm method and device according to an embodiment of the present application will be described in detail below with reference to the accompanying drawings.

[0015] Figure 1 A device abnormality alarm method according to an embodiment of the present application is shown in FIG. 1. Figure 1 The method comprises the following steps.

[0016] S101, receiving state information sent by at least two different access devices in a building automation control system;

[0017] S102, determining an alarm rule corresponding to each access device, and verifying state information corresponding to each access device through the alarm rule corresponding to each access device;

[0018] S103, if the verification result of the state information of any access device is abnormal, generating device abnormality alarm information corresponding to the access device.

[0019] It can be understood that the device abnormality alarm method provided by the present application is applied to a host computer monitoring system, and is used for realizing real-time monitoring of the state of multiple access devices in a building automation control system and triggering an alarm.

[0020] In some examples, the building automation control system adopts a Building Automation and Control Network (Bacnet) protocol for device communication, and the access devices support a state information reporting mechanism based on a Change of Value (COV) feature.

[0021] Specifically, each access device periodically (or in real time) monitors its own running state, and when the state information it monitors changes, it sends the state information to the host computer monitoring system based on the COV feature of the Bacnet protocol. The state information includes but is not limited to temperature, humidity, pressure, current, voltage, device running state, switch state, and other parameters. In some examples, the access device can also periodically send state information to the host computer monitoring system based on the COV feature of the Bacnet protocol, regardless of whether its running state changes.

[0022] The host computer monitoring system provides a graphical or configuration interface for relevant personnel (such as a system administrator) to configure alarm rules. The alarm rules can set trigger conditions for different types of access devices and different application scenarios, such as temperature exceeding a threshold value, device state being faulty, humidity change rate exceeding a preset rate, etc. The alarm rules can include but are not limited to the following: alarm trigger conditions (such as threshold value judgment, trend judgment, state change, etc.); associated access device identifier; alarm level (such as prompt, warning, serious); alarm delay, confirmation method, etc.

[0023] After the host computer monitoring system receives the state information sent by the access device, the host computer monitoring system verifies the state information of the access device according to the corresponding alarm rule pre-configured for the access device. The verification method can include numerical comparison, state matching, logic expression evaluation, etc.

[0024] If the state information of the access device is verified as abnormal, the host computer monitoring system generates corresponding device abnormal alarm information. The device abnormal alarm information can include: access device identifier; alarm triggering time; corresponding state parameter and its value; alarm rule number triggered; alarm level and recommended treatment measures, etc.

[0025] According to the scheme provided by the embodiments of the present application, the state information sent by at least two different access devices in the building automation control system is received; the alarm rule corresponding to each access device is determined, and the state information corresponding to each access device is verified through the alarm rule corresponding to each access device; if the verification result of the state information of any access device is abnormal, the device abnormal alarm information corresponding to any access device is generated. The present application centrally manages the state information and alarm rules of the access devices in the host computer monitoring system, realizes unified analysis and processing of the alarm states of multiple devices, avoids the problem of information dispersion caused by the alarm information of the access devices being managed by the respective device engines, thereby improving the efficiency of fault location and abnormal response, and helping to improve the overall monitoring capability and operation and maintenance level of the building automation system. The alarm information of the access devices is managed by the respective device engines, which avoids affecting fault troubleshooting.

[0026] In some examples, the alarm rule includes a state threshold value corresponding to each device state corresponding to the access device; the host computer monitoring system realizes fine alarm judgment of the state information by configuring the threshold range of multiple different device state parameters. The state information corresponding to each access device is verified through the alarm rule corresponding to each access device, including: determining each type of device state included in the state information and the detection time of the device state; in the case that the detection time is within a preset time period, verifying whether the device state satisfies the state threshold value corresponding to the device state.

[0027] For example, for a certain temperature sensor device, the alarm rule can configure the "temperature upper threshold value" as 30℃ and the "temperature lower threshold value" as 15℃; for a certain humidity sensor device, the "humidity abnormal change rate" can be configured as 10% per minute; for the running state of the air conditioning system, the "continuous downtime threshold value" can be configured as 10 minutes, etc.

[0028] In actual operation, the access device sends state information to the host computer through the Change of Value (COV) feature in the Bacnet protocol. The state information includes device state parameters and their corresponding detection times.

[0029] After receiving the state information, the host computer monitoring system first identifies each type of device state and its corresponding detection time, for example: temperature = 32.5°C, detection time = 09:17:24.

[0030] Next, the host computer monitoring system determines whether the detection time is within the preset time period. For example, the system is configured with a preset time period of 08:00 to 20:00 every day to determine whether an alarm event is triggered during working hours.

[0031] In the case where the detection time is within the preset time period, further threshold comparison is performed on the device state parameter: for example, if the temperature = 32.5°C exceeds the set upper limit of 30°C, it can be determined that the state information does not meet the state threshold corresponding to the temperature state, and thus the state of the access device is determined to be abnormal.

[0032] Once the state threshold is not met, the host computer monitoring system generates corresponding device abnormal alarm information and outputs it in a preset manner, such as interface highlighting, recording logs, and pushing notifications.

[0033] In this way, the host computer monitoring system can dynamically alarm and judge in combination with the time dimension and parameter threshold, achieving more accurate and scenario-based device abnormality identification, and improving the intelligence and practicality of the monitoring system.

[0034] In some examples, the alarm rule can be combined with multiple conditions, such as temperature exceeding the threshold and humidity being below the threshold.

[0035] In an embodiment, the alarm rule includes not only the state threshold corresponding to the device state of the target access device, but also the state threshold of the associated access device associated with the access device. The associated access device refers to other access devices that have an association relationship with the target access device in terms of physical structure, functional logic, or operational dependence.

[0036] For example, in a heating, ventilation, and air conditioning system, a supply fan in a certain area and the corresponding temperature and humidity sensor form a linkage relationship: when the supply fan is in the "on" state, the temperature in the corresponding area should fluctuate within a certain range; otherwise, it can be determined as a potential supply abnormality or adjustment failure.

[0037] Based on this, when the host computer monitoring system receives the state information of an access device (such as a supply fan), it not only verifies based on its own alarm rule (such as “the running state should be on”), but also further acquires the state information of the temperature sensor associated with it, and judges whether the temperature meets the state threshold corresponding to the sensor (such as “20℃≤temperature≤26℃”).

[0038] Specifically, the host computer monitoring system can perform the following steps: identifying one or more associated access devices associated with the target access device (the target device is the access device that sends the state information); extracting the device state parameter of each associated access device from the state information; judging whether the device state of the associated access device is in the preset time period at the detection time (optional); comparing the state value of each associated access device with its corresponding state threshold to verify whether the condition is met. If it is found that the device state of any associated access device does not meet the corresponding state threshold, it can be considered that the running state of the target access device has potential abnormalities, thereby triggering the generation of device abnormal alarm information.

[0039] The association relationship between the access device and the associated access device can be established by any of the following ways: static association based on system topology configuration: through the configuration platform of the building automation control system or the system drawing in the design stage, the physical location and the belonging subsystem of each access device are preset. The belonging subsystem can be based on spatial location proximity or functional module division, and a certain access device is automatically associated to one or more logically or physically adjacent devices. For example: the supply fan B, exhaust valve C, and air conditioning panel D in the room where the temperature sensor A is located will be identified as its associated access devices. Logical association based on manual rule configuration: the host computer monitoring system can provide a configuration interface, and the administrator manually sets the associated access device set corresponding to a certain access device and its association type (such as master-slave, dependent-feedback, etc.). For example: the administrator can configure “when the state of device X is abnormal, the states of devices Y and Z should be detected whether they are within the range”. Intelligent learning association based on the running data of the host computer monitoring system: through historical running data to mine the linkage relationship between devices, such as through state change correlation, time series analysis, etc. to construct a dynamic association model, which is used to supplement or optimize manual configuration. The system can find from the running log that “when the historical record of device A running abnormally, more than 80% of the time is accompanied by device B state deviation”, thereby prompting the user to establish or adjust the association relationship.

[0040] In some examples, in the case that the verification result of the state information corresponding to the plurality of access devices is abnormal, the method further comprises: determining an alarm priority order according to the severity level of each device abnormal alarm information; and outputting the plurality of device abnormal alarm information in turn according to the alarm priority order. That is, the host computer monitoring system can determine the output priority order of each device abnormal alarm information based on the severity level of each device abnormal alarm information, so as to improve the efficiency and rationality of monitoring response.

[0041] Specifically, the system can perform the following processing steps: extracting the severity level of the device abnormal alarm information; each piece of device abnormal alarm information includes a corresponding severity level parameter, which can be set by the system administrator when configuring the alarm rule, or automatically calculated and generated by the system according to the degree of deviation of the device state, the associated device condition, etc. The severity level can adopt a multi-level classification manner, such as: prompt level, general level, warning level, and severe level.

[0042] Establishing an alarm priority order: the host computer monitoring system sorts the device abnormal alarm information generated by all abnormal devices at present, and forms an alarm priority order from high to low according to their respective severity levels. The sorting algorithm can be realized based on a fixed weight mapping relationship, for example: the severe level corresponds to the priority 1; the warning level corresponds to the priority 2; the general level corresponds to the priority 3; and the prompt level corresponds to the priority 4.

[0043] Outputting the alarm information in turn: according to the above priority order, the host computer monitoring system outputs the plurality of device abnormal alarm information in turn. The output method can include but is not limited to: sorting and displaying in the monitoring interface from high to low priority; preferentially pushing high-priority alarms to alarm terminals or operation and maintenance personnel; cooperating with sound and light prompts, emails, short messages and other channels to give priority to severe level alarms.

[0044] Optional rhythm control and alarm fusion processing: in the case that the number of alarms is too large or the level is highly concentrated, the system can adopt a rhythm control mechanism (such as throttling output, batch display), or a fusion output mechanism (such as aggregation into a system-level alarm), to avoid information redundancy and interface congestion.

[0045] In the above manner, the embodiment can reasonably arrange the output order according to the importance of the alarm event, improve the response efficiency of abnormal processing and the rationality of personnel decision-making, avoid key alarms being overwhelmed by low-level alarms, and thus enhance the intelligent monitoring capability and practicality of the building automation control system.

[0046] In some examples, after generating the device abnormal alarm information corresponding to any access device, the method further comprises: sending the device abnormal alarm information to a pre-set alarm terminal, so as to realize real-time notification and disposal linkage of the alarm event, and the device abnormal alarm information includes device name, device state, alarm time, alarm type, and alarm priority.

[0047] The alarm terminal can include but is not limited to: a host computer monitoring interface; a mobile terminal alarm push client; an alarm SMS gateway or an email system; an audible and visual alarm device; a third-party integrated system interface (such as a smart building management platform, a BMS system, etc.). In order to ensure the integrity and availability of the alarm information, the device abnormal alarm information includes the following contents: device name: indicating the name of the access device that triggers the alarm, which is used to assist in positioning and management; device state: indicating the state value of the device when the alarm is triggered, such as "temperature: 34.2°C", "operation state: off", etc. Alarm time: indicating the timestamp when the device state is determined to be abnormal by the system, usually the state information reporting time or the system determination completion time; alarm type: indicating the abnormal type to which the alarm belongs, such as "temperature overrun", "associated device mismatch", "multi-device linkage abnormality", etc.; alarm priority: indicating the degree of urgency or response level of the alarm, which usually corresponds to the "severity level" mentioned in claim 4, such as "severity level", "warning level", etc.

[0048] In a specific implementation, the host computer monitoring system can encapsulate the above information into a unified data structure and send it to the corresponding alarm terminal through a pre-set message push mechanism. The sending method can be synchronous push (such as API interface call), asynchronous notification (such as message queue, email system), or support for subscription mechanism (such as WebSocket, MQTT, etc.).

[0049] In addition, the system can support flexible configuration and management of the alarm terminal, including terminal type, receiving personnel, push time period, filtering conditions, etc., so as to realize individualized and hierarchical alarm response strategies.

[0050] In the above manner, the present embodiment can realize instant communication and multi-terminal linkage of device abnormal events, which helps to improve the system operation and maintenance response efficiency and the timeliness of fault handling, and enhances the maintainability and intelligent level of the building automation control system.

[0051] In some examples, the device abnormal alarm method provided by the present application further includes: counting the received device abnormal alarm information and generating alarm logs and reports. Specifically, when the system detects that any access device in the heating, ventilation and air conditioning system has abnormal operating parameters, and generates device abnormal alarm information accordingly, the system writes the alarm information into a log record module. The alarm log includes but is not limited to the following fields: alarm time, device name, device state, alarm type, alarm priority, whether it has been processed, etc. Through the structured management of log data, the system can realize the query, tracking and auditing functions of historical alarm information.

[0052] Further, the host computer monitoring system can also generate a device abnormality alarm report at a set period (e.g., daily, weekly, or monthly). The report is based on the statistical module's classification and analysis of alarm events in the recent period, supporting the output of different alarm types in the form of a table, including the occurrence frequency, the number of affected devices, the number of unprocessed alarms, the response time, and other statistical indicators. In addition, the report can also display the overall trend of system operation abnormalities through trend charts and column charts. This report can be used for fault pattern recognition and maintenance strategy development by the operation and maintenance team, which helps to improve system reliability and maintenance efficiency.

[0053] In an optional implementation, the generated alarm report can be pushed to the operation and maintenance terminal through a graphical interface, or exported in PDF, Excel, or other formats for offline archiving or analysis.

[0054] In this application, the building automation control system uses the Building Automation and Control Network (Bacnet) protocol for device communication, and the access device reports state information based on the Change of Value (COV). By using a reliable message delivery mechanism, the timely and accurate delivery of alarm information is ensured, avoiding delays and losses.

[0055] In some examples, this application introduces a message queue mechanism in the host computer monitoring system to cache and manage device abnormality alarm information, ensuring the order and integrity of the alarm information. Redundancy mechanisms are set at key nodes in the alarm information transmission path to ensure that device abnormality alarm information can still be delivered normally in the event of network or device failure.

[0056] Specifically, to ensure that device abnormality alarm information can be delivered to the target alarm terminal in a timely and accurate manner, the system uses a reliable message delivery mechanism, which includes the following:

[0057] Message queue mechanism: The host computer monitoring system has a message queue module (e.g., Kafka, RabbitMQ, ActiveMQ, etc.) integrated internally to cache and manage all device abnormality alarm information to be sent. This module can ensure.

[0058] Order of alarm information: Multiple alarms are processed in the order of their generation time.

[0059] Completeness of alarm information: Ensures that partial information is not lost due to concurrent processing or system restart.

[0060] Supports persistent storage, which automatically recovers uncompleted alarm tasks after system abnormality recovery.

[0061] Redundancy mechanism: configure redundancy system at key nodes in the alarm information transmission link (such as server relay nodes, push service modules, etc.), for example, use master-slave deployment, dual-network card backup, dual-link communication, etc. When the main path is interrupted (such as network interruption, node failure), the system automatically switches to the standby path to continue sending alarm information, ensuring the reliability of the overall alarm link when a local fault occurs.

[0062] Fault tolerance and retry mechanism (optional): the system can also set up an automatic retry mechanism after message sending failure, and record the device abnormal alarm information log of sending failure, to facilitate the system administrator to analyze and intervene.

[0063] Through the above mechanisms, the embodiment significantly improves the stability and robustness of device abnormal alarm information transmission, effectively avoids alarm delay or loss due to network fluctuations, system congestion or single point failure, and thus guarantees the alarm response capability and overall reliability of the building automation control system.

[0064] All the optional technical solutions described above can be combined to form optional embodiments of the present application, which will not be repeated here.

[0065] The following is an apparatus embodiment of the present application, which can be used to execute the method embodiments of the present application. For details not disclosed in the apparatus embodiments of the present application, please refer to the method embodiments of the present application.

[0066] Based on the same concept, the present application also provides a device abnormal alarm apparatus, as shown in Figure 2 The device abnormal alarm apparatus comprises:

[0067] A receiving module 201 is configured to receive state information sent by at least two different access devices in a building automation control system;

[0068] A verification module 202 is configured to determine an alarm rule corresponding to each access device, and verify state information corresponding to each access device through the alarm rule corresponding to each access device;

[0069] An alarm module 203 is configured to generate device abnormal alarm information corresponding to any access device in the case that the verification result of the state information of any access device is abnormal.

[0070] In some examples, the alarm rule comprises a state threshold value corresponding to each device state of the access device; the verification module 202 is further configured to determine the device state in each type included in the state information and the detection time of the device state; and in the case that the detection time is within a preset time period, verify whether the device state meets the state threshold value corresponding to the device state.

[0071] In some examples, the alarm rule further comprises a state threshold of the associated access device associated with the access device, and the verification module 202 is further configured to verify whether the device state of the associated access device meets the corresponding state threshold of the associated access device.

[0072] In some examples, the alarm module 203 is further configured to determine an alarm priority order according to the severity level of each device abnormality alarm information, and sequentially output the plurality of device abnormality alarm information according to the alarm priority order.

[0073] In some examples, the alarm module 203 is further configured to send the device abnormality alarm information to a pre-set alarm terminal, and the device abnormality alarm information comprises a device name, a device state, an alarm time, an alarm type, and an alarm priority.

[0074] In some examples, the alarm module 203 is further configured to count the received device abnormality alarm information, and generate an alarm log and a report.

[0075] According to the scheme provided by the embodiment of the present application, the device abnormality alarm apparatus receives the state information sent by at least two different access devices in the building automation control system, determines the alarm rule corresponding to each access device, and verifies the state information corresponding to each access device through the alarm rule corresponding to each access device. If the verification result of the state information of any access device is abnormal, the device abnormality alarm information corresponding to any access device is generated. The present application centrally manages the state information and the alarm rule of the access device in the upper computer monitoring system, realizes the unified analysis and processing of the alarm state of multiple devices, avoids the information dispersion problem caused by the management of the alarm information of the access device by the respective device engine, thereby improving the efficiency of fault positioning and abnormal response, and helps to improve the overall monitoring capability and operation and maintenance level of the building automation system. According to the scheme provided by the embodiment of the present application, the alarm information of the access device is managed by the respective device engine, which avoids affecting the fault locating.

[0076] Figure 3 is a schematic diagram of an electronic device 3 provided by an embodiment of the present application. As shown in Figure 3 the electronic device 3 of this embodiment includes a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. The processor 301 implements the steps in each of the method embodiments described above when executing the computer program 303. Alternatively, the processor 301 implements the functions of each module / unit in each of the device embodiments described above when executing the computer program 303.

[0077] The electronic device 3 can be a desktop computer, a notebook computer, a palm computer, a cloud server, or the like. The electronic device 3 can include, but is not limited to, a processor 301 and a memory 302. Those skilled in the art can understand that Figure 3 The electronic device 3 is merely an example and does not limit the electronic device 3, which can include more or fewer components or different components than those shown.

[0078] The processor 301 can be a central processing unit (CPU), and can also be other general-purpose processors, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like.

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

[0080] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above functional units and modules is exemplified, and in actual applications, the above functions can be completed by different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiment can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0081] The integrated modules / units, if implemented in the form of software functional units and sold or used as independent products, can be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the above-mentioned embodiment methods can also be completed by a computer program instructing related hardware, and the computer program can be stored in a computer readable storage medium. The computer program can be executed by a processor to implement the steps of the above-mentioned various method embodiments. The computer program can include computer program code, which can be in the form of source code, object code, executable files or some intermediate forms. The computer readable medium can include any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content included in the computer readable medium can be appropriately increased or decreased according to the requirements of the region and the requirements of the patent practice. For example, according to the requirements of the region and the patent practice, the computer readable medium does not include the electric carrier signal and the telecommunication signal in some regions.

[0082] The above embodiments are only used to illustrate the technical solutions of the present application, rather than 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 they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacements 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, and should be included in the protection scope of the present application.

Claims

1. An apparatus abnormality alarm method characterized by comprising: The method comprises: receiving state information sent by at least two different access devices in a building automation control system; determining an alarm rule corresponding to each of the access devices, and verifying the state information corresponding to each of the access devices by the alarm rule corresponding to each of the access devices; if the verification result of the state information of any of the access devices is abnormal, generating device abnormal alarm information corresponding to any of the access devices.

2. The method of claim 1, wherein, The alarm rule comprises a state threshold corresponding to each device state corresponding to the access device; verifying the state information corresponding to each of the access devices by the alarm rule corresponding to each of the access devices comprises: determining each type of device state included in the state information and the detection time of the device state; if the detection time is within a preset time period, verifying whether the device state meets the state threshold corresponding to the device state.

3. The method of claim 2, wherein, The alarm rule further comprises a state threshold of an associated access device associated with the access device, and the method further comprises: verifying whether the device state of the associated access device meets the state threshold corresponding to the associated access device.

4. The method of claim 1, wherein, If the verification result of the state information of a plurality of the access devices is abnormal, the method further comprises: determining an alarm priority order according to the severity level of each of the device abnormal alarm information; outputting the plurality of device abnormal alarm information in turn according to the alarm priority order.

5. The method of claim 1, wherein, After generating the device abnormal alarm information corresponding to any of the access devices, the method further comprises: sending the device abnormal alarm information to a pre-set alarm terminal, wherein the device abnormal alarm information comprises a device name, a device state, an alarm time, an alarm type, and an alarm priority.

6. The method of claim 1, wherein, The method further comprises: counting the received device abnormal alarm information, and generating an alarm log and a report.

7. An apparatus abnormality alarm device characterized by comprising: The device comprises: a receiving module configured to receive state information sent by at least two different access devices in a building automation control system; a verifying module configured to determine an alarm rule corresponding to each of the access devices, and verify the state information corresponding to each of the access devices by the alarm rule corresponding to each of the access devices; an alarm module configured to, if the verification result of the state information of any of the access devices is abnormal, generate device abnormal alarm information corresponding to any of the access devices.

8. The apparatus of claim 7, wherein, The alarm rule comprises a state threshold corresponding to each device state corresponding to the access device; The verifying module is further configured to determine each type of device state included in the state information and the detection time of the device state, and verify whether the device state meets the state threshold corresponding to the device state if the detection time is within a preset time period.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor implements the steps of the method of any one of claims 1 to 6 when executing the computer program.

10. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 9. The computer program, when executed by the processor, implements the steps of the method of any one of claims 1 to 6.

Images