Intelligent building fire candidate event determination and alarm method and system

Abstract

The application relates to a kind of intelligent building fire candidate event determination and alarm method and system, comprising: in the edge node of running real-time operating system, access sensor;Through sensor drive adaptation unit, complete multi-source sensor registration, state monitoring and original data reading;Through edge data standardization module, different types of sensor data are converted into uniform data frame;Through real-time task scheduling module, scheduling is carried out to collection task, data standardization task, fire candidate event determination task, local alarm task, remote communication task and optional visual detection trigger task;Through fire candidate event determination module, the risk level of fire candidate event is determined;Finally, according to risk level, continue to monitor, maintain early warning, trigger local alarm or remote alarm communication is executed.The application can realize the unified access of multi-source sensor data, real-time processing and hierarchical alarm on the edge node of intelligent building, improve the real-time performance and reliability of fire candidate event response.

Description

Technical Field

[0001] This invention relates to intelligent buildings, edge computing, embedded real-time operating systems, and fire early warning technology, and particularly to a method and system for determining and alarming candidate fire events in intelligent buildings. Background Technology

[0002] With the development of smart buildings, smart parks, and IoT technologies, environmental monitoring, equipment linkage, and safety early warning within buildings are gradually evolving from traditional centralized systems to edge computing systems. Fire early warning, as a key link in smart building safety management, typically relies on multi-source sensing devices such as temperature sensors, smoke sensors, carbon monoxide sensors, combustible gas sensors, and video surveillance equipment to monitor environmental conditions.

[0003] Existing intelligent building fire detection methods have the following main shortcomings:

[0004] First, the types of multi-source sensors are complex, and the data formats are not uniform. The sampling units, sampling periods, measurement ranges, anomaly judgment conditions, and communication interfaces of temperature, smoke, carbon monoxide, and combustible gas sensors differ. If edge nodes directly process the raw data, it will increase the complexity of the fire candidate event judgment logic and will not be conducive to unified uploading to the building management terminal or cloud platform.

[0005] Second, existing systems often employ fixed sampling periods or fixed task priorities, making it difficult to promptly prioritize critical tasks when abnormal events occur. When early signs of a fire appear, sensor acquisition, data analysis, alarm output, and remote communication tasks require higher real-time performance and more stable coordination, while ordinary polling or non-real-time scheduling methods are prone to causing alarm delays.

[0006] Third, threshold determination based on a single sensor is prone to false alarms or missed alarms. For example, short-term smoke interference, kitchen steam, local temperature fluctuations, or sensor aging can all cause single-point threshold anomalies. Relying solely on instantaneous threshold overflows cannot fully reflect the fire evolution process, especially failing to comprehensively consider time-dimensional characteristics such as the number of consecutive anomalies and the rate of change per unit time.

[0007] Fourth, while vision-based fire detection methods can identify flame and smoke areas, their detection results are easily affected by lighting conditions, occlusion, camera angle, smoke morphology, and limitations in model deployment resources. Relying solely on vision detection is susceptible to the computing power of edge devices and changes in the scene. However, using vision detection as a verification mechanism after sensor anomalies can improve the reliability of risk level determination while controlling computational overhead.

[0008] Therefore, there is a need to provide a method for identifying and alarming fire candidate events that is suitable for deployment on edge nodes of smart buildings. This method should be able to achieve multi-source sensor access, data standardization, real-time task scheduling, risk score calculation, optional visual verification, and local and remote alarm linkage based on a real-time operating system, so as to improve the real-time performance, stability, and scalability of fire candidate event identification in smart buildings. Summary of the Invention

[0009] To address the problems of inconsistent data, high complexity, inaccurate calculations, and insufficient real-time performance in existing intelligent building fire detection methods, this invention provides a method and system for determining and alarming candidate fire events in intelligent buildings. This method uses edge nodes running a real-time operating system as the execution entity. Through multi-source sensor access, unified data frame encapsulation, real-time task scheduling, hierarchical determination of fire candidate events, and optional visual detection correction, it achieves edge-side determination and alarming of early fire risks in intelligent building scenarios. It is applicable to intelligent buildings, park buildings, laboratories, computer rooms, and other scenarios requiring edge fire early warning.

[0010] The technical solution of this invention is as follows: A method for determining and alarming potential fire events in intelligent buildings, comprising: Step S1: Connect multi-source building sensors to the edge node running the real-time operating system. The edge node includes a multi-source sensor access module, a sensor driver adaptation unit, an edge data standardization module, a real-time task scheduling module, a fire candidate event determination module, and an edge alarm and communication module. The multi-source building sensors include temperature sensors, smoke sensors, carbon monoxide sensors, and combustible gas sensors. Step S2: The sensor driver adapter unit identifies, registers, monitors the status of, and reads the raw data of the multi-source building sensor; Step S3: Convert the raw data collected by different types of sensors into a unified data frame through the edge data standardization module, and write the unified data frame into the edge cache queue; Step S4: Schedule temperature acquisition tasks, smoke acquisition tasks, gas acquisition tasks, data standardization tasks, fire candidate event determination tasks, local alarm tasks, remote communication tasks, and visual detection triggering tasks through the real-time task scheduling module. Step S5: Read the unified data frame through the fire candidate event determination module, and calculate the sensor anomaly score based on the threshold crossing degree, the number of consecutive anomalies, and the rate of change per unit time; Step S6: Determine the risk level of the fire candidate event based on the sensor anomaly score, and trigger the edge alarm and communication module when the risk level meets the preset conditions; Step S7: When the edge node has a camera or image source and meets the visual detection triggering conditions, call the visual detection interface to obtain the visual fire confidence level, and correct the risk level according to the visual fire confidence level; Step S8: Based on the revised risk level, perform continued monitoring, maintain alerts, trigger local alarms, or remote alarm communications.

[0011] Furthermore, step S2 includes: Step S2.1: Load the corresponding sensor driver according to the sensor interface type; Step S2.2: Assign sensor numbers to the connected sensors and record the sensor type, installation location, sampling period, and alarm threshold; Step S2.3: Periodically check the sensor's online status, data reading status, and communication status; Step S2.4: When a sensor is detected to be offline, reading fails, or data exceeds the effective range, set the device status and abnormal flag bit in the corresponding unified data frame.

[0012] Furthermore, step S3 includes: Step S3.1: Perform unit conversion and format conversion on the raw data collected by different sensors; Step S3.2: Add a timestamp to each sensor data point; Step S3.3: Generate a unified data frame based on the sensor number, sensor type, installation location, timestamp, collected value, unit of measurement, device status, and anomaly flag. Step S3.4: Write the unified data frame into the edge buffer queue for the fire candidate event determination task to read.

[0013] Furthermore, the real-time task scheduling module executes the acquisition task according to the first sampling period under normal conditions; when a fire candidate event is triggered, the real-time task scheduling module increases the priority of the fire candidate event judgment task, the local alarm task, and the remote communication task, and adjusts the sampling period of the relevant sensors from the first sampling period to the second sampling period, wherein the second sampling period is shorter than the first sampling period.

[0014] Furthermore, the sensor anomaly score is calculated as follows: R_sensor = a × R_threshold + bR_count + c × R_rate Where R_sensor is the sensor anomaly score, R_threshold is the threshold overrun component, R_count is the number of consecutive anomalies component, R_rate is the rate of change per unit time component, and a, b, and c are weighting coefficients, and a, b, and c are all greater than or equal to 0. The threshold out-of-bounds component is determined based on the degree of deviation of the collected value from the preset threshold; the number of consecutive abnormal occurrences component is determined based on the number of times that multiple sensors in the same sensor or the same area are in an abnormal state consecutively; and the rate of change per unit time component is determined based on the magnitude of change of the sensor collected values ​​in adjacent sampling periods.

[0015] Preferably, the visual detection triggering conditions include at least one of the following: the sensor anomaly score is higher than the visual trigger value; the number of consecutive anomalies of the smoke sensor or gas sensor reaches a preset number; the rate of change of the temperature acquisition value per unit time is higher than the rate of change threshold; or the building management terminal issues a visual verification instruction.

[0016] Preferably, the visual detection interface calls the YOLO series target detection model to perform target detection on the camera image or image source, and outputs the flame area, smoke area, and visual fire confidence score.

[0017] Furthermore, the revised risk level is determined based on a comprehensive fire risk score, which is calculated as follows: R_total = m × R_sensor + n × R_vision Where R_total is the comprehensive fire risk score, R_sensor is the sensor anomaly score, R_vision is the visual fire confidence score, and m and n are weighting coefficients, and m and n are both greater than or equal to 0. Based on the comprehensive fire risk score, the building fire risk level is divided into normal state, early warning state, and alarm state. When in normal state, the edge node continues to perform periodic monitoring. When in early warning state, the edge node maintains high-frequency sampling and uploads early warning information. When in alarm state, the edge node triggers local alarm devices and sends alarm data to the building management terminal or cloud platform.

[0018] Furthermore, the data uploaded by the remote communication task includes: edge node number, sensor number, sensor type, installation location, timestamp, collected value, sensor anomaly score, visual fire confidence level, comprehensive fire risk score, and risk level.

[0019] A smart building fire candidate event determination and alarm system, used to implement the method described above, including: An edge node running a real-time operating system is connected to a building management terminal or cloud platform and to a local alarm device. The edge node is used to access temperature sensors, smoke sensors, carbon monoxide sensors, combustible gas sensors, or cameras or image sources deployed inside the smart building. The multi-source sensor access module is used to interface with temperature sensors, smoke sensors, carbon monoxide sensors and combustible gas sensors, and to complete sensor driver adaptation, sensor registration, status monitoring and raw data reading. The edge data standardization module is used to convert raw data collected by different types of sensors into a unified data frame; The real-time task scheduling module is used to schedule sensor acquisition tasks, data standardization tasks, fire candidate event determination tasks, local alarm tasks, remote communication tasks, and optional visual detection triggering tasks. The fire candidate event determination module is used to calculate the sensor anomaly score based on the degree of threshold violation, the number of consecutive anomalies, and the rate of change per unit time, and to determine the risk level of the fire candidate event. The edge alarm and communication module is used to trigger local alarm devices and send alarm data to the building management terminal or cloud platform according to the risk level; The visual detection interface module is used to call the target detection model to output the visual fire confidence score and correct the risk level of the fire candidate event when the visual detection trigger conditions are met.

[0020] The beneficial effects of this invention are as follows: 1. This invention converts heterogeneous sensor data such as temperature, smoke, carbon monoxide, and combustible gas into unified data frames through a sensor-driven adaptation unit and an edge data standardization module, thereby reducing the complexity of multi-source sensor data processing and improving the consistency of event determination at the edge.

[0021] 2. This invention sets up multiple real-time tasks based on a real-time operating system, and dynamically increases the priority of the fire candidate event judgment task, local alarm task, and remote communication task after a fire candidate event is triggered, while adjusting the sampling period of relevant sensors, thereby improving the real-time response under abnormal conditions.

[0022] 3. This invention not only determines risk based on a single threshold crossing, but also incorporates the number of consecutive anomalies and the rate of change per unit time into the calculation of sensor anomaly scores, which helps to reduce false alarms caused by short-term noise, single-point interference, or occasional sampling anomalies.

[0023] 4. This invention sets the visual detection interface as an optional module, and only calls the target detection model for verification when the sensor anomaly score reaches the trigger condition. This can improve the reliability of risk level correction while controlling the computational overhead of edge nodes.

[0024] 5. This invention enables local alarms and remote communication at building edge nodes, and is applicable to application scenarios that require multi-source sensing and edge early warning, such as smart buildings, smart parks, computer rooms, laboratories, and warehouse spaces. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the overall system structure in an embodiment of the present invention; Figure 2 This is a schematic diagram of the multi-source sensor access and data standardization process in an embodiment of the present invention; Figure 3 This is a schematic diagram of the task scheduling process in an embodiment of the present invention; Figure 4 This is a schematic diagram of the fire candidate event determination process in an embodiment of the present invention; Figure 5 This is a schematic diagram of the visual inspection interface and risk level correction process in an embodiment of the present invention. Detailed Implementation

[0026] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. These embodiments are based on the technical solution of the present invention and provide detailed implementation methods and specific operating procedures. However, the scope of protection of the present invention is not limited to the following embodiments.

[0027] like Figure 1 As shown, the intelligent building fire candidate event determination and alarm method provided in this embodiment of the invention runs on an edge node. The edge node runs a real-time operating system, which is an embedded real-time operating system with task scheduling, device driver management, communication management, and timer management capabilities. In one embodiment, the real-time operating system is the XiUOS real-time operating system.

[0028] The edge node communicates with the building management terminal or cloud platform and connects to local alarm devices. The edge node accesses temperature sensors, smoke sensors, carbon monoxide sensors, and combustible gas sensors deployed within the smart building. Internally, the edge node includes a multi-source sensor access module, a sensor driver adaptation unit, an edge data standardization module, a real-time task scheduling module, a fire candidate event determination module, and an edge alarm and communication module. In embodiments where the edge node accesses a camera or image source, it also includes a visual inspection interface module.

[0029] The multi-source sensor access module is used to connect temperature sensors, smoke sensors, carbon monoxide sensors, and combustible gas sensors.

[0030] The sensor driver adaptation unit loads the corresponding driver program according to the sensor interface type and sensor model, encapsulates the low-level reading functions of different sensors, and provides a unified data reading interface to the upper-level tasks.

[0031] The edge data standardization module is used to convert data collected by different types of sensors into a unified data frame. The unified data frame includes sensor number, sensor type, installation location, timestamp, collected value, unit of measurement, device status, and anomaly flag.

[0032] The real-time task scheduling module manages multiple tasks within the real-time operating system, including temperature acquisition, smoke acquisition, gas acquisition, data standardization, fire candidate event determination, local alarm, remote communication, and visual detection triggering tasks. These tasks can be scheduled according to priority, sampling period, and event triggering conditions.

[0033] The fire candidate event determination module is used to read the unified data frame, calculate the sensor anomaly score based on the degree of threshold violation, the number of consecutive anomalies and the rate of change per unit time, and determine the risk level accordingly.

[0034] The edge alarm and communication module is used to perform local alarms and remote communication when the risk level reaches a warning or alarm state. Local alarm devices include buzzers, audible and visual alarms, or indicator lights; remote communication targets include building management terminals, gateway servers, or cloud platforms.

[0035] In embodiments where cameras or image sources are accessed at edge nodes, the visual detection interface module calls the You Only Look Once (YOLO) series target detection model after the triggering conditions are met, outputs the flame area, smoke area, and visual fire confidence score, and provides the visual fire confidence score to the fire candidate event determination module for risk level correction.

[0036] like Figure 2 As shown, the multi-source sensor access and data standardization process includes multi-source sensor input, sensor driver adaptation, sensor registration, status monitoring and raw data reading, unit conversion and format conversion, timestamp addition, anomaly flag setting, unified data frame encapsulation, and edge cache queue writing.

[0037] During the multi-source sensor input phase, temperature sensors, smoke sensors, carbon monoxide sensors, and combustible gas sensors each provide raw data to the edge node. This raw data is input via General Purpose Input / Output (GPIO), Analog-to-Digital Converter (ADC), Integrated Circuit Bus Interface (I2C), Serial Peripheral Interface (SPI), Universal Asynchronous Receiver / Transmitter (UART), or RS-485 serial communication interface. The data format, units, and readout period may differ between the different sensors.

[0038] During the sensor driver adaptation phase, edge nodes load the corresponding driver program based on the sensor interface type and sensor model. The sensor driver adaptation unit encapsulates the low-level read functions for different sensors, enabling upper-layer tasks to read sensor data using a unified interface.

[0039] During the sensor registration phase, the edge node assigns a unique sensor number to each sensor and records the sensor's type, installation location, sampling period, normal measurement range, warning threshold, alarm threshold, and communication interface information. The installation location may include floor, room number, corridor area, equipment room, computer room, or other spatial location information.

[0040] During the status monitoring and raw data reading phase, edge nodes periodically read sensor data and simultaneously detect the sensor's online status, data reading status, and communication status. When a sensor goes offline, fails to read data, returns an invalid value, or the acquired value exceeds the effective range, the edge node sets the corresponding device status and anomaly flag in a unified data frame.

[0041] During the unit conversion and format conversion stage, the edge data standardization module converts the raw values ​​collected by different sensors into a unified format. For example, temperature data can be standardized to degrees Celsius, smoke data can be converted to concentration or relative sensor output values, and carbon monoxide and combustible gas data can be converted to concentration values ​​or standardized ratio values.

[0042] During the timestamp addition phase, edge nodes add a collection timestamp to each piece of data. The timestamp can be provided by the system clock of the real-time operating system, a hardware timer, or network synchronization time.

[0043] During the anomaly flag setting phase, the edge data standardization module sets anomaly flags based on device status, data validity, and preliminary threshold check results. The anomaly flags indicate whether the data entry exhibits any device offline anomaly, data reading anomaly, communication anomaly, or value out-of-bounds anomaly.

[0044] During the unified data frame encapsulation phase, the edge data standardization module encapsulates the sensor number, sensor type, installation location, timestamp, collected values, unit of measurement, device status, and anomaly flags into a unified data frame. An example structure of the unified data frame is as follows: Sensor ID: Sensor_ID; Sensor type: Sensor_Type; Installation location: Location; Timestamp: Timestamp; Collected value: Value; Unit of measurement: Unit; Device Status: Device_Status; Abnormal flag: Abnormal_Flag.

[0045] In one embodiment, Sensor_ID is an unsigned integer, Sensor_Type and Device_Status are enumerated values, Timestamp is a millisecond-level timestamp, Value is a fixed-point or floating-point number, and Abnormal_Flag is a bitmap; different bits in the bitmap represent device offline, read failure, communication error, and value out of bounds, respectively.

[0046] The edge buffer queue is implemented using a first-in-first-out queue or a circular buffer. Data acquisition and data standardization tasks act as producers, writing unified data frames, while fire candidate event determination tasks act as consumers, reading unified data frames. Concurrency protection for write and read operations is achieved through mutexes, semaphores, or message queue mechanisms provided by the real-time operating system.

[0047] During the edge buffer queue writing phase, unified data frames are written to the edge buffer queue. The fire candidate event determination task reads unified data frames from the edge buffer queue according to the scheduling strategy and calculates risk scores.

[0048] like Figure 3 As shown in this embodiment of the invention, after the edge node is started, it enters the system startup or running state, and various tasks are managed by the real-time task scheduling module.

[0049] Under normal system conditions, the real-time task scheduling module executes temperature acquisition task T1, smoke acquisition task T2, gas acquisition task T3, and data standardization task T4 according to the first sampling cycle. Specifically, T1 is used to acquire temperature data, T2 to acquire smoke data, T3 to acquire carbon monoxide and combustible gas data, and T4 is used to perform unit conversion, format conversion, and unified data frame encapsulation. T3 can also be split into carbon monoxide acquisition tasks and combustible gas acquisition tasks based on the number of sensors.

[0050] Data standardization task T4 converts the raw data generated by the acquisition task into a unified data frame and writes the unified data frame into the edge buffer queue. Fire candidate event determination task T5 reads the unified data frame according to a preset period or event triggering method and calculates the sensor anomaly score.

[0051] When no fire candidate event is triggered, the system remains in normal state and continues to perform sampling and judgment according to the first sampling cycle.

[0052] When a fire candidate event is triggered, the real-time task scheduling module enters the real-time processing flow under abnormal conditions. In this flow, the real-time task scheduling module performs the following operations: First, increase the priority of fire-related tasks. Specifically, raise the priority of fire candidate event determination task T5, local alarm task T6, and remote communication task T7 to a higher priority than data acquisition tasks or background tasks.

[0053] Second, adjust the sampling period. Change the sampling period of sensors related to fire candidate events from the first sampling period to a second sampling period, where the second sampling period is shorter than the first. For example, sample once every 5 seconds under normal conditions and once every 1 second under warning conditions; the specific values ​​can be set according to the building scenario and sensor performance.

[0054] Third, activate the local alarm task T6. When the risk level reaches the warning or alarm state, the local alarm task controls the local alarm device to output a buzzer, flashing light, or a combination of sound and light alarm.

[0055] Fourth, activate the remote communication task T7. When the risk level reaches the warning or alarm state, the remote communication task will upload the alarm information to the building management terminal or cloud platform.

[0056] Fifth, trigger the visual detection task T8 when conditions are met. When an edge node connects to a camera or image source, and the sensor anomaly score reaches the visual trigger threshold, the visual detection trigger task calls the visual detection interface to obtain the visual fire confidence level.

[0057] Through the above task scheduling method, edge nodes can operate under low load under normal conditions and quickly increase the processing priority of critical tasks when fire candidate events occur, thereby improving the real-time performance of edge fire early warning.

[0058] like Figure 4 As shown, the fire candidate event determination process includes reading standardized data frames, extracting data such as temperature, smoke, carbon monoxide and combustible gas, threshold determination, counting of consecutive anomalies, calculating the rate of change per unit time, calculating sensor anomaly scores, determining risk level, triggering edge alarms and communication, and triggering optional visual detection interfaces.

[0059] The fire candidate event determination module first reads a unified data frame from the edge buffer queue and extracts temperature, smoke, carbon monoxide, and combustible gas data according to sensor type. For each type of sensor data, the fire candidate event determination module calculates the threshold overrun component R_threshold, the number of consecutive anomalies component R_count, and the rate of change per unit time component R_rate.

[0060] The threshold deviation component R_threshold is used to represent the degree of deviation of the sensor's collected value from a preset threshold. In one embodiment, if the collected value does not exceed the warning threshold, R_threshold is 0; if the collected value exceeds the warning threshold but does not exceed the alarm threshold, R_threshold is calculated based on the proportion exceeding the warning threshold; if the collected value exceeds the alarm threshold, R_threshold takes a higher value.

[0061] The consecutive anomaly count component R_count represents the number of consecutive anomalies occurring from the same sensor or multiple sensors within the same area. In one embodiment, if the sensor exceeds the warning threshold for N consecutive samples, R_count increases with N; when N reaches a preset count threshold, R_count reaches its corresponding upper limit.

[0062] The rate of change per unit time component R_rate is used to represent the magnitude of change in the sensor's collected values ​​within adjacent sampling periods. In one embodiment, if the temperature rises rapidly within a short period of time, or if the smoke concentration, carbon monoxide concentration, or combustible gas concentration rises rapidly, then R_rate increases.

[0063] The sensor anomaly score R_sensor is calculated as follows: R_sensor = a × R_threshold + b × R_count + c × R_rate Where a, b, and c are weighting coefficients. These weighting coefficients can be set according to different building areas, sensor types, or application scenarios. For example, the weights for smoke, temperature, and gas sensors can differ in different spaces such as kitchens, laboratories, server rooms, and warehouses.

[0064] After calculating the sensor anomaly score, the fire candidate event determination module determines the risk level based on a preset risk level threshold. The risk level can include normal state, warning state, and alarm state.

[0065] When R_sensor is below the first risk threshold, the system determines it to be in a normal state, and the edge node continues to perform periodic monitoring.

[0066] When R_sensor is greater than or equal to the first risk threshold and lower than the second risk threshold, the system determines that it is in an early warning state, the edge node increases the sampling frequency of the relevant sensors, and uploads the early warning information to the building management terminal.

[0067] When R_sensor is greater than or equal to the second risk threshold, the system determines that an alarm state has been triggered, and the edge node triggers the local alarm device and uploads the alarm information to the building management terminal or cloud platform.

[0068] In one embodiment, when R_sensor is in a warning or alarm state, the edge node can also trigger the visual detection interface to obtain visual fire confidence and correct the risk level.

[0069] like Figure 5 As shown, the visual detection interface and risk level correction process are executed after a fire candidate event is triggered. The edge node first determines whether the visual detection conditions are met. These conditions include whether the edge node is connected to a camera, whether it can receive an image source, whether the image source is available, and whether the current computing resources meet the conditions for calling the target detection model.

[0070] If visual detection is not available, the system determines the risk level based solely on the sensor anomaly score R_sensor, and then executes actions such as continuing monitoring, maintaining early warning, or triggering an alarm based on the risk level.

[0071] If visual detection is available, the visual detection interface receives camera images or image detection results and invokes the YOLO series target detection model. The YOLO series target detection model can be used to identify flame areas, smoke areas, or other fire-related visual features in the image. The visual detection interface outputs the visual fire confidence score R_vision.

[0072] After obtaining R_sensor and R_vision, the fire candidate event determination module calculates the comprehensive fire risk score R_total: R_total = m × R_sensor + n × R_vision Where m and n are weighting coefficients. m and n can be set according to the application scenario, camera deployment location, model reliability, sensor reliability, or historical false alarm data.

[0073] When R_total is lower than the first comprehensive risk threshold, the system outputs the monitoring result; when R_total is greater than or equal to the first comprehensive risk threshold but lower than the second comprehensive risk threshold, the system outputs the warning result; when R_total is greater than or equal to the second comprehensive risk threshold, the system outputs the alarm result.

[0074] In this approach, visual detection is not continuously running, but rather serves as a verification or correction mechanism in risk level determination after the sensor anomaly score reaches a trigger condition. This reduces the computational burden on edge nodes that continuously run the visual model, while also improving the reliability of risk level determination by utilizing visual information when fire candidate events occur.

[0075] The edge alarm and communication module performs different actions based on the risk level.

[0076] Under normal conditions, edge nodes do not trigger alarms, but only continue to perform periodic data collection, data standardization, and fire candidate event determination.

[0077] In an alert state, edge nodes can perform at least one of the following operations: increase the sampling frequency of relevant sensors; record alert events; send alert information to building management terminals or cloud platforms via communication interfaces; provide low-intensity alerts to management personnel locally; and wait for the next round of sensor sampling and risk score updates.

[0078] In alarm status, edge nodes can perform at least one of the following operations: trigger local audible and visual alarm devices; send alarm data to building management terminals or cloud platforms; upload sensor anomaly scores, visual fire confidence scores, comprehensive fire risk scores, and location information; maintain high-frequency sampling; continuously update risk levels; and receive confirmation, reset, or linkage control commands issued by building management terminals.

[0079] The data uploaded by the remote communication task may include: edge node number, sensor number, sensor type, installation location, timestamp, collected value, device status, anomaly flag, sensor anomaly score, visual fire confidence level, comprehensive fire risk score, and risk level.

[0080] Communication methods may include wired networks, wireless networks, serial gateways, IoT communication modules, or other methods that can be used for building system communication.

[0081] In one specific application, the edge node runs a real-time operating system and connects to temperature sensors, smoke sensors, carbon monoxide sensors, combustible gas sensors, local audible and visual alarm devices, and a building management terminal. After system startup, the edge node completes sensor registration, task creation, and unified data frame encapsulation. When the smoke sensor shows continuous anomalies and the temperature change rate exceeds a threshold, the system calculates the sensor anomaly score and prioritizes the fire candidate event determination task, local alarm task, and remote communication task. If the edge node has a camera, it calls the visual inspection interface to output a visual fire confidence score and calculates a comprehensive fire risk score based on the sensor anomaly score; if no camera is connected, it directly outputs the risk level based on the sensor anomaly score. When the risk level reaches the alarm state, the edge node triggers the local alarm device and sends alarm data to the building management terminal.

[0082] The above-described embodiments are merely one implementation of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the appended claims.

Claims

1. A method for determining and alarming candidate fire events in intelligent buildings, characterized in that, include: Step S1: Connect multi-source building sensors to the edge node running the real-time operating system. The edge node includes a multi-source sensor access module, a sensor driver adaptation unit, an edge data standardization module, a real-time task scheduling module, a fire candidate event determination module, and an edge alarm and communication module. The multi-source building sensors include temperature sensors, smoke sensors, carbon monoxide sensors, and combustible gas sensors. Step S2: The sensor driver adapter unit identifies, registers, monitors the status of, and reads the raw data of the multi-source building sensor; Step S3: Convert the raw data collected by different types of sensors into a unified data frame through the edge data standardization module, and write the unified data frame into the edge cache queue; Step S4: Schedule temperature acquisition tasks, smoke acquisition tasks, gas acquisition tasks, data standardization tasks, fire candidate event determination tasks, local alarm tasks, remote communication tasks, and visual detection triggering tasks through the real-time task scheduling module. Step S5: Read the unified data frame through the fire candidate event determination module, and calculate the sensor anomaly score based on the threshold crossing degree, the number of consecutive anomalies, and the rate of change per unit time; Step S6: Determine the risk level of the fire candidate event based on the sensor anomaly score, and trigger the edge alarm and communication module when the risk level meets the preset conditions; Step S7: When the edge node has a camera or image source and meets the visual detection triggering conditions, call the visual detection interface to obtain the visual fire confidence level, and correct the risk level according to the visual fire confidence level; Step S8: Based on the revised risk level, perform continued monitoring, maintain alerts, trigger local alarms, or remote alarm communications.

2. The method according to claim 1, characterized in that, Step S2 includes: Step S2.1: Load the corresponding sensor driver according to the sensor interface type; Step S2.2: Assign sensor numbers to the connected sensors and record the sensor type, installation location, sampling period, and alarm threshold; Step S2.3: Periodically check the sensor's online status, data reading status, and communication status; Step S2.4: When a sensor is detected to be offline, reading fails, or data exceeds the effective range, set the device status and abnormal flag bit in the corresponding unified data frame.

3. The method according to claim 1, characterized in that, Step S3 includes: Step S3.1: Perform unit conversion and format conversion on the raw data collected by different sensors; Step S3.2: Add a timestamp to each sensor data point; Step S3.3: Generate a unified data frame based on the sensor number, sensor type, installation location, timestamp, collected value, unit of measurement, device status, and anomaly flag. Step S3.4: Write the unified data frame into the edge buffer queue for the fire candidate event determination task to read; The edge cache queue is implemented using a first-in-first-out queue or a circular buffer; the data acquisition task and data standardization task act as producers to write unified data frames, and the fire candidate event determination task acts as consumers to read unified data frames; the write and read operations are protected against concurrency through mutexes, semaphores, or message queue mechanisms provided by the real-time operating system.

4. The method according to claim 1, characterized in that, Under normal conditions, the real-time task scheduling module executes the acquisition task according to the first sampling period. When a fire candidate event is triggered, the real-time task scheduling module increases the priority of the fire candidate event judgment task, the local alarm task, and the remote communication task, and adjusts the sampling period of the relevant sensors from the first sampling period to the second sampling period, wherein the second sampling period is shorter than the first sampling period.

5. The method according to claim 1, characterized in that, The sensor anomaly score is calculated as follows: R_sensor = a × R_threshold + bR_count + c × R_rate Wherein, R_sensor is the sensor anomaly score, R_threshold is the threshold out-of-bounds component, R_count is the consecutive anomaly count component, R_rate is the rate of change per unit time component, and a, b, and c are weighting coefficients, where a, b, and c are all greater than or equal to 0; the threshold out-of-bounds component is determined based on the degree of deviation of the collected value from the preset threshold; the consecutive anomaly count component is determined based on the number of times the same sensor or multiple sensors in the same area are in an abnormal state consecutively; and the rate of change per unit time component is determined based on the change amplitude of the sensor collected values ​​within adjacent sampling periods.

6. The method according to claim 1, characterized in that, The visual detection triggering conditions include at least one of the following: the sensor anomaly score is higher than the visual trigger value; the number of consecutive anomalies of the smoke sensor or gas sensor reaches a preset number; the rate of change of the temperature acquisition value per unit time is higher than the rate of change threshold; or the building management terminal issues a visual verification command.

7. The method according to claim 1, characterized in that, The visual detection interface calls the YOLO series target detection model to perform target detection on camera images or image sources, and outputs flame areas, smoke areas, and visual fire confidence scores.

8. The method according to claim 1, characterized in that, The revised risk level is determined based on a comprehensive fire risk score, which is calculated as follows: R_total = m × R_sensor + n × R_vision Where R_total is the comprehensive fire risk score, R_sensor is the sensor anomaly score, R_vision is the visual fire confidence score, and m and n are weighting coefficients, both of which are greater than or equal to 0. Based on the comprehensive fire risk score, the building fire risk level is divided into normal state, warning state, and alarm state. When in the normal state, the edge node continues to perform periodic monitoring. When in the warning state, the edge node maintains high-frequency sampling and uploads warning information. When in the alarm state, the edge node triggers local alarm devices and sends alarm data to the building management terminal or cloud platform.

9. The method according to claim 1, characterized in that, The data uploaded by the remote communication task includes: edge node number, sensor number, sensor type, installation location, timestamp, collected value, sensor anomaly score, visual fire confidence score, comprehensive fire risk score, and risk level.

10. An intelligent building fire candidate event determination and alarm system, characterized in that, To implement the method as described in any one of claims 1-9, comprising: An edge node running a real-time operating system is connected to a building management terminal or cloud platform and to a local alarm device. The edge node is connected to a temperature sensor, smoke sensor, carbon monoxide sensor and combustible gas sensor through a sensor interface and to a camera or image source through a visual inspection interface module. The multi-source sensor access module is used to interface with temperature sensors, smoke sensors, carbon monoxide sensors and combustible gas sensors, and to complete sensor driver adaptation, sensor registration, status monitoring and raw data reading. The edge data standardization module is used to convert raw data collected by different types of sensors into a unified data frame; The real-time task scheduling module is used to schedule sensor acquisition tasks, data standardization tasks, fire candidate event determination tasks, local alarm tasks, remote communication tasks, and optional visual detection triggering tasks. The fire candidate event determination module is used to calculate the sensor anomaly score based on the degree of threshold violation, the number of consecutive anomalies, and the rate of change per unit time, and to determine the risk level of the fire candidate event. The edge alarm and communication module is used to trigger local alarm devices and send alarm data to the building management terminal or cloud platform according to the risk level; The visual detection interface module is used to call the target detection model to output the visual fire confidence score and correct the risk level of the fire candidate event when the visual detection trigger conditions are met.

Images