Multi-source fire-fighting data fusion and fire analysis monitoring system

Abstract

The invention relates to the technical field of fire-fighting fire alarm monitoring, in particular to a multi-source fire-fighting data fusion and fire analysis monitoring system, which comprises a dynamic protocol self-adaptive module for generating standardized sensor data; the multi-factor fusion module obtains a fusion result F; the causal and joint criterion module is used for outputting a fire judgment result; the three-chain traceability module is used for obtaining the three-chain evidence and carrying out cross check to obtain a three-chain cross check result; and the self-evolution optimization module is used for carrying out on-line re-calibration on the mapping parameters of the three-chain cross check result and the fire judgment result, the causal correlation degree C and the threshold value of the combined fire index J, and carrying out closed-loop updating under the constraint of retrieval complexity and performance. According to the method, the continuity of data analysis, the credibility of fusion calculation, the accuracy of fire judgment and the traceability of a result are realized in a complex dynamic environment, and the method has a long-term adaptive evolution capability.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of fire-fighting fire alarm monitoring technology, and in particular to a multi-source fire-fighting data fusion and fire analysis monitoring system. BACKGROUND

[0002] The existing multi-source fire-fighting monitoring system usually collects environmental information through temperature, smoke, carbon monoxide and other sensors, and performs simple weighted fusion or threshold determination on the platform side. However, this kind of system has a common problem: when the device firmware or communication protocol changes, the sensor health state decreases or the environmental interference increases, the system lacks a unified adaptive mechanism. The specific performance is as follows:

[0003] When the firmware of the detection device is upgraded or the communication protocol is adjusted, the original parsing rule is invalid, and manual modification and maintenance are often required, which is easy to cause data interruption or misinterpretation;

[0004] The sensor may have degradation problems such as packet loss and drift in long-term operation, and there are dust, humidity, strong light and other interference factors in the environment, and the traditional fusion method lacks dynamic correction of these "data reliability", resulting in high false alarm and false alarm rates;

[0005] Fire condition determination usually relies on static threshold or simple parallel conditions, and fails to combine the causal relationship and rate characteristics of parameter changes, so it is difficult to balance the rapid response to real fire and the inhibition of environmental interference;

[0006] The alarm result lacks cross-checking across data, devices and operation dimensions, and the credibility is insufficient, which is difficult to support post-tracing and parameter optimization.

[0007] Therefore, the prior art cannot simultaneously ensure the continuity of data analysis, the reliability of fusion calculation, the accuracy of fire condition determination and the traceability of results in a complex dynamic environment. How to build an overall system architecture with protocol adaptation, fusion correction, causal determination, traceability and self-evolution optimization ability has become a technical problem to be solved in this field. SUMMARY

[0008] In order to overcome the deficiencies of the prior art in protocol adaptation, fusion reliability, fire condition determination accuracy, result traceability and system self-evolution optimization, the purpose of the present application is to provide a multi-source fire-fighting data fusion and fire analysis monitoring system to realize the continuity of data analysis, the reliability of fusion calculation, the accuracy of fire condition determination and the traceability of results in a complex dynamic environment, and has long-term self-adaptive evolution ability.

[0009] The present application discloses a multi-source fire-fighting data fusion and fire analysis monitoring system, comprising:

[0010] a dynamic protocol adaptation module, configured to learn online and generate parsing rules when device firmware or communication protocol changes, and to parse raw data collected by each sensor to generate standardized sensor data;

[0011] a multi-factor fusion module, configured to fuse the standardized sensor data to obtain a fusion result F:

[0012]

[0013] wherein, is an initial weight of the i-th channel; is a device health degree of the i-th channel; is an environmental interference intensity of the i-th channel; is the standardized sensor data of the i-th channel, is a modified channel weight; and n is a total number of sensor channels;

[0014] a cause-effect and joint criterion module, configured to calculate a cause-effect correlation degree C and a joint fire condition index J according to time series of fire condition-related key parameters contained in the fusion result F, and to perform fire condition confirmation on the fusion result F in combination with the cause-effect correlation degree C and the joint fire condition index J by using a double threshold to output a fire condition determination result;

[0015] a three-chain traceability module, configured to maintain data chains, device chains and operation chains in parallel to obtain three-chain evidences, and to cross-check the fire condition determination result and the three-chain evidences on a unified time axis to obtain a three-chain cross-check result;

[0016] an evolutionary optimization module, configured to perform online re-calibration on mapping parameters of 、 、 and threshold values of the cause-effect correlation degree C and the joint fire condition index J based on the three-chain cross-check result and the fire condition determination result, and to perform closed-loop updating under constraints of search complexity and performance.

[0017] Preferably, the dynamic protocol adaptation module comprises:

[0018] a feature flow extraction unit, configured to extract protocol-related feature parameters from the raw data;

[0019] a change detection unit, configured to count the feature parameters and calculate a change rate within a sliding window:

[0020]

[0021] wherein, is a feature field frequency at a current time point; is a feature field frequency at a previous time point.​ a rate of change, the protocol update signal being generated when the rate of change exceeds a threshold value;

[0022] a rule self-generating unit configured to generate a new parsing rule within a first preset time window according to the protocol update signal, and transmit the new parsing rule to the data collection unit to parse subsequent raw data according to the protocol.

[0023] Preferably, the multi-factor fusion module comprises a communication quality detection unit and a sensor self-calibration unit, and the device health degree is calculated based on:

[0024] the communication quality detection unit is configured to count the number of lost packets and the total number of packets of the data communication link of the sensor of the ith channel within a second preset time window to obtain a communication loss rate of the ith channel;

[0025] the sensor self-calibration unit is configured to obtain a drift amount of the sensor of the ith channel by means of built-in reference signal injection , and compare the drift amount with a maximum allowed drift allowed value of the sensor of the ith channel;

[0026] the device health degree is defined as:

[0027]

[0028] wherein, and is a statistical value of the sensor of the ith channel within a third preset time window;

[0029] when the communication loss rate or the drift amount exceeds a threshold value, a rejection signal is generated to prohibit the raw data of the sensor of the ith channel from being parsed according to the protocol.

[0030] Preferably, the multi-factor fusion module further comprises a dust detection unit, an illumination detection unit, a humidity detection unit, and an interference factor synthesis unit, and the environmental interference intensity is calculated based on:

[0031] the dust detection unit is configured to receive a dust concentration parameter in the standardized sensor data , and output a dust interference factor when > 50 ;

[0032] the illumination detection unit is configured to receive an illumination intensity parameter in the standardized sensor data , and output an illumination interference factor when > 5000 ;

[0033] humidity detection unit for receiving a humidity parameter in the normalized sensor data , and outputting a humidity disturbance factor when the humidity parameter is greater than 80% ;

[0034] disturbance factor synthesis unit for synthesizing a dust disturbance factor , a light disturbance factor , and a humidity disturbance factor into an environmental disturbance intensity ;

[0035] environmental disturbance intensity is only updated when the three-chain traceability module confirms that the sensor is affected by environmental factors.

[0036] Preferably, the multi-factor fusion module further comprises:

[0037] hysteresis logic control unit for monitoring the stability of the i-th channel within a continuous observation time threshold when the raw data of the sensor of the i-th channel is prohibited from protocol parsing due to device health or environmental disturbance intensity ;

[0038] when the stability is satisfied, outputting a recovery signal to gradually restore the raw data of the sensor of the i-th channel to protocol parsing.

[0039] Preferably, the causal correlation degree C is defined as:

[0040]

[0041] wherein: is the change amount of the temperature signal within the third preset time window relative to the reference value; is the change amount of the smoke concentration signal within the preset time window relative to the reference value; is the minimum time difference between the temperature signal reaching the temperature threshold change point and the smoke signal reaching the smoke threshold change point.

[0042] Preferably, the joint fire index J is defined as:

[0043]

[0044] wherein, is the change amount of the temperature signal within the third preset time window relative to the reference value; is the change amount of the smoke concentration signal within the third preset time window relative to the reference value; a change amount of the carbon monoxide signal relative to a reference value within a third preset time window; a time interval required for the temperature signal to reach a temperature threshold change point within the third preset time window; a time interval required for the smoke signal to reach a smoke threshold change point within the third preset time window; a time interval required for the carbon monoxide signal to reach a carbon monoxide threshold change point within the third preset time window; 、 、 is a weighting coefficient, and .

[0045] Preferably, the three-chain traceability module comprises:

[0046] a data chain management unit for storing and invoking full-process data;

[0047] a device chain management unit for storing and invoking full-amount data related to the health status of the device firmware;

[0048] an operation chain management unit for storing and invoking manual or automatic control instructions;

[0049] a consistency verification unit for performing k-take-2 consistency verification on the three-chain cross-verification result and the fire condition determination result within a sliding time window , and generating a high-confidence traceability evidence as the three-chain cross-verification result if at least two chains remain consistent;

[0050] wherein k = 3, is a preset verification window length.

[0051] Preferably, the three-chain traceability module further comprises a block generation unit for concatenating an event summary , a timestamp , a determination summary , and a previous block hash and calculating a new block hash value , with the calculation formula being:

[0052]

[0053] wherein, is a cryptographic hash function; represents a byte concatenation operation in a predetermined order.

[0054] Preferably, the self-evolution optimization module comprises:

[0055] A performance monitoring unit is configured to retrieve the fire determination result, the three-chain cross-verification result and the standardized sensor data under the time slice index, and record the time length required for retrieval as a query time delay, and when the query time delay meets the existing parameters are kept, otherwise the parameter re-calibration is triggered; wherein, the query time delay is the sample quantity is;

[0056] A parameter updating unit is configured to update the calculation parameters of the parsing rule, the device health degree , the environmental interference intensity and the criterion threshold of the causal correlation degree C and the joint fire index J when the re-calibration is triggered, and feed back the updated calculation parameters to the dynamic protocol adaptive module and the multi-factor fusion module through the shadow deployment and rollback mechanism to replace the original parameters and take effect in subsequent protocol parsing and fusion, and feed back the updated criterion threshold to the causal and joint criterion module to replace the original criterion threshold and take effect in subsequent criterion.

[0057] After the above technical scheme is adopted, compared with the prior art, the following beneficial effects are obtained:

[0058] 1. In the prior art, when the device firmware is upgraded / communication protocol is adjusted, the protocol change needs to be manually checked and the parsing rule needs to be manually modified, which takes 1-2 weeks; the data is prone to be interrupted (the interruption rate is 30%+) or misparsed (the misparsing rate is 15%) due to manual operation; in the present application, the dynamic protocol adaptive module detects the protocol change in real time through the "self-evolution protocol engine" and the sliding window algorithm (the details are not described herein) to automatically generate a new parsing rule, so that the protocol adaptation does not need manual intervention, the adaptation time is shortened from 1-2 weeks to ≤3 minutes, the data interruption rate is reduced to 0, and the misparsing rate is reduced to below 1%, thereby ensuring the continuity of data parsing.

[0059] 2. In the prior art, fixed weighting / simple average fusion is adopted, the sensor health degradation (packet loss, drift) and the environmental interference (dust, strong light) are ignored, and unreliable data dominates the fusion result, the false alarm rate is 30%+, and the false alarm rate is 25%+; in the present application, the multi-factor fusion module dynamically calculates the weight (details are not described herein) by using the "device health degree " (combined with the packet loss rate and the drift amount) and the "environmental interference intensity " (combined with the dust, light and humidity) to passively compress the weight of unreliable data, and the credibility of the fusion result is improved by 80%; the false alarm rate is reduced from 30%+ to below 5%, and the false alarm rate is reduced from 25%+ to below 3%.

[0060] ​​3. Existing technologies rely on static thresholds (such as alarms for temperatures > 60℃) or simple parallel conditions, without considering the causal relationship and rate characteristics of parameters. This results in a delayed early fire response (≥ 5 seconds) and a false alarm rate of 40%+. In this invention, the causal joint criterion module uses "causal correlation degree C" (… ) Quantitative parameter correlation, "Joint Fire Index J" ( The combined rate of change and dual-threshold fire detection shorten the early fire response time from ≥5 seconds to ≤1.5 seconds; the interference misjudgment rate is reduced from 40%+ to below 3%, taking into account both "rapid response" and "interference suppression".

[0061] 4. In existing technologies, alarm results lack cross-dimensional verification, relying solely on single data points, resulting in a lack of evidence for post-event tracing (tracing time ≥ 2 hours), making it impossible to optimize the system based on historical data, leading to long-term performance stagnation. In this embodiment, the three-chain tracing module uses cross-verification of the data chain, device chain, and operation chain, along with blockchain hashing. Solidify evidence; the self-evolutionary optimization module monitors performance and dynamically updates parameters, reducing the post-event tracing time from ≥2 hours to ≤10 minutes, and ensuring 100% credibility of evidence (meeting legal requirements); the system performance is continuously optimized, and the false alarm rate decreases by another 20% after one month of operation.

[0062] 5. Existing technologies can only adapt to fixed equipment and stable environments. When the type of equipment increases (such as adding an AI flame sensor) or environmental interference changes (such as increased seasonal dust), modules need to be redeveloped, resulting in high adaptation costs (≥100,000 RMB / time). In this invention, protocol adaptation (adapting to new equipment), persistence logic (recovering abnormal sensors), and self-evolution optimization (adapting to environmental changes) work together, eliminating the need for redeveloping modules. This enables adaptation to 20+ brands of equipment and 5+ types of environmental interference. The adaptation cost is reduced to 0 when new equipment / environment changes, and the adaptability of the monitoring system is improved by 90%. Attached Figure Description

[0063] Figure 1 This is a flowchart illustrating a multi-source fire data fusion and fire situation analysis and monitoring system according to the present invention. Detailed Implementation

[0064] The advantages of the present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments.

[0065] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0066] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0067] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0068] In the description of this invention, it should be understood that the terms "longitudinal", "lateral", "up", "down", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0069] In the description of this invention, unless otherwise specified and limited, it should be noted that the terms "installation", "connection" and "linking" should be interpreted broadly. For example, they can refer to mechanical or electrical connections, or internal connections between two components. They can be direct connections or indirect connections through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms according to the specific circumstances.

[0070] In the following description, suffixes such as "module," "part," or "unit" used to denote elements are used only for the convenience of the description of the invention and have no specific meaning in themselves. Therefore, "module" and "part" can be used interchangeably.

[0071] See Figure 1 As shown, this embodiment provides a multi-source fire data fusion and fire situation analysis monitoring system (hereinafter referred to as the monitoring system), including: a dynamic protocol adaptive module, used to learn and generate parsing rules online when the device firmware or communication protocol changes, and to perform protocol parsing on the raw data collected by each sensor to generate standardized sensor data; a multi-factor fusion module, used to process the standardized sensor data... Weighting is used to obtain the fusion result F: in, Let be the initial weight of the i-th channel; The device health status for the i-th channel; The environmental interference intensity of the i-th channel; For the standardized sensor data of the i-th channel, The corrected channel weights are defined as follows: n represents the total number of sensor channels; the causality and joint criterion module calculates the causal correlation degree C and the joint fire index J based on the time series of key fire-related parameters contained in the fusion result F, and uses a dual-threshold approach to confirm the fire situation by combining the fusion result F with the causal correlation degree C and the joint fire index J, outputting the fire situation determination result; the three-chain tracing module maintains the data chain, equipment chain, and operation chain in parallel to obtain three-chain evidence, and performs cross-validation between the fire situation determination result and the three-chain evidence using a unified timeline to obtain the three-chain cross-validation result; the self-evolutionary optimization module optimizes the fire situation based on the three-chain cross-validation result and the fire situation determination result. , , The mapping parameters and the thresholds of the causal correlation degree C and the joint fire index J are recalibrated online and updated in a closed loop under the constraints of retrieval complexity and performance.

[0072] In this embodiment, the dynamic protocol adaptation module will be described in detail. The dynamic protocol adaptation module is used to learn and generate parsing rules online when the device firmware or communication protocol changes, and to perform protocol parsing on the raw data collected by various sensors to generate standardized sensor data.

[0073] In this embodiment, the device firmware refers to the program built into fire protection equipment (such as fire alarm controllers, temperature / smoke / carbon monoxide sensors, etc.), which includes core operating instructions such as device communication logic and data encoding rules. When the manufacturer upgrades the device firmware, it may change the data transmission protocol logic (such as field definitions and transmission timing).

[0074] The communication protocol mentioned in this embodiment is a set of rules for data transmission between devices (such as general protocols like Modbus and RS485, or manufacturer-specific protocols). Variations include changes to protocol field mapping relationships (e.g., in the original protocol, the "0x05" field represented temperature, but after firmware upgrades, it represents smoke concentration), adjustments to baud rate / data bits / checksum methods (e.g., changing from 9600 baud rate to 19200 baud rate), and reconstruction of data frame formats (e.g., changes to the positions of frame header and frame length fields).

[0075] In this embodiment, the online learning mentioned refers to extracting protocol-related feature parameters (such as command headers, field lengths, and numerical conversion rules of data frames) from the raw data through a "feature stream extraction unit"; the "change detection unit" calculates the rate of change of feature parameters in a sliding window (calculation formula). , The frequency of the feature field at the current time. (The frequency of the feature field at the previous moment); when the rate of change exceeds the preset threshold, a protocol update signal is generated. The rule self-generation unit, within the first preset time window, reversely derives new parsing rules based on the protocol update signal (such as determining the starting byte of the temperature field in the new protocol, conversion formula: temperature value = (byte segment value × 0.1) - 10).

[0076] The sensors mentioned in this embodiment are typical sensors covering fire monitoring scenarios, such as temperature sensors (monitoring ambient temperature), smoke concentration sensors (monitoring smoke density), carbon monoxide sensors (monitoring CO concentration), and flame sensors (monitoring flame light signals).

[0077] In this embodiment, the raw data refers to the raw communication messages that have not been parsed by the protocol after being collected by the sensor. For example, the raw digital messages containing temperature information output by a temperature sensor (such as hexadecimal data "0xAA0x010x23..."), and the raw concentration messages of a smoke sensor, etc.

[0078] In this embodiment, the protocol parsing mentioned refers to parsing and converting the original message according to the parsing rules generated by the rule generation unit. For example, if the parsing rule defines "the 3rd byte after the frame header 0xAA is the temperature value, and the conversion formula is temperature value = (byte value × 0.1) - 10", then the corresponding byte segment in the original message will be converted into a readable value such as "25℃" according to this rule.

[0079] The standardized sensor data mentioned in this embodiment refers to structured data in a unified format after protocol parsing. For example, sensor data is organized in the form of "parameter name + value + unit + timestamp" (e.g., "temperature: 25℃, event: 2025-09-01 10:00:00" "smoke concentration: 10%LEL, time: 2025-09-01 10:00:01"), providing a unified input format for the subsequent multi-factor fusion module.

[0080] In this embodiment, the multi-factor fusion module will be described in detail. The multi-factor fusion module is used to process the standardized sensor data generated by the aforementioned dynamic protocol adaptive module. Calculate the corrected channel weights Then through Calculate the fusion result F. Wherein, Let be the initial weight of the i-th channel; The device health status for the i-th channel; The environmental interference intensity of the i-th channel; For the standardized sensor data of the i-th channel, is the corrected channel weight; n is the total number of sensor channels.

[0081] Initial weights The "inherent weight" of the i-th sensor channel is determined by the sensor's factory accuracy (e.g., a temperature sensor with an accuracy of ±5℃ has a higher initial weight than a sensor with an accuracy of ±1℃).

[0082] Device health It is determined by two parts: 1. Communication quality (in the formula) 1. The percentage of packet loss in sensor data transmission within the second preset time window; 2. Sensor self-calibration drift (in the formula) , This represents the actual drift of the sensor. The maximum allowable drift for this sensor, such as a temperature sensor. =2℃).

[0083] Environmental disturbance intensity In this embodiment, interference is synthesized from three types: dust, light, and humidity. 1. Dust interference (when dust concentration...) >50 Output dust interference factor ); 2. Light interference (when the light intensity >5000 Output light interference factor ); 3. Humidity interference (when humidity Output humidity interference factor when >80% The three types of factors are synthesized into the final environmental disturbance intensity through a "piecewise linear sum function connector". Furthermore, when the three-chain traceability module confirms that "the interference is purely caused by environmental factors," it will affect the intensity of environmental interference. Update.

[0084] Corrected channel weights Initial weights Equipment health Environmental interference intensity The product of these values ​​reflects the effective weight of the sensor under the condition of "its own health status + the degree of environmental interference" (the weight of channels with low health status or strong interference will be reduced to reduce the adverse impact on the fusion result F).

[0085] Fusion result F: The weighted sum of standardized data from multiple sensors. For example, fused temperature (weighted sum). ), smoke concentration (weight) ), carbon monoxide concentration (weight) After that, a comprehensive index reflecting the fire trend in the area is obtained (such as "Comprehensive Fire Index: 85").

[0086] In this embodiment, the causality and joint criterion module will be described in detail. The causality and joint criterion module is used to calculate the causal correlation degree C and the joint fire index J based on the time series of fire-related key parameters contained in the fusion result F obtained by the multi-factor fusion module in the above embodiment, and to determine the fire situation by combining the fusion result F with the causal correlation degree C and the joint fire index J using a dual-threshold approach, thereby outputting the fire situation determination result.

[0087] The key parameters related to the fire situation mentioned in this embodiment refer to core parameters directly related to the fire situation, such as temperature ( ), smoke concentration ( ), carbon monoxide concentration ( )wait.

[0088] The time series mentioned in this embodiment refers to a continuous data sequence of the aforementioned key parameters changing over time. For example, the time change process of temperature in a certain area from 25℃→30℃→40℃, and the time change process of smoke concentration from 5%LEL→15%LEL→30LEL.

[0089] The causal correlation degree C mentioned in this embodiment is calculated using the formula... Calculation, where It is the change in temperature relative to a "reference value" (such as normal ambient temperature). It is the change in smoke concentration relative to a "baseline value". It is the minimum time difference between "temperature reaching the threshold change point" and "smoke reaching the threshold change point". This indicator is used to measure the causal relationship between temperature and smoke changes (in real fires, there is usually a time correlation between temperature rise and smoke generation; if there is only a sudden change in smoke (such as kitchen fumes) and no corresponding change in temperature, the C value is extremely low and can be judged as interference).

[0090] The combined fire index J mentioned in this embodiment is obtained through the formula... Calculate, where: It is the time interval between when the temperature reaches the "threshold change point". It is the time interval at which the smoke reaches the "threshold change point". It is the time interval at which carbon monoxide reaches the "threshold change point". , , Weighting coefficients (satisfying) By combining the "rate of change" and "time characteristics" of multiple parameters, a more comprehensive judgment can be made as to whether the fire is real.

[0091] The dual thresholds mentioned in this embodiment refer to the thresholds of "causal correlation degree C" and "joint fire index J" (these thresholds are recalibrated online by the self-evolutionary optimization module). A fire will only be confirmed when both C and J meet their respective thresholds.

[0092] The fire situation determination result mentioned in this embodiment is to output a conclusion of "fire" or "no fire", along with information such as the confidence level of the determination and the change curve of key parameters, to provide a basis for subsequent early warning and tracing.

[0093] In this embodiment, the three-chain tracing module will be described in detail. The three-chain tracing module is used to maintain the data chain, device chain, and operation chain in parallel to obtain three-chain evidence, and to cross-verify the fire situation determination results output by the above-mentioned causal and joint criterion module with the three-chain evidence using a unified timeline to obtain the three-chain cross-verification results.

[0094] For the data chain mentioned in this embodiment, the "data chain management unit" stores and retrieves the entire process data, including: raw data (original sensor messages), standardized sensor data (data after protocol parsing), fusion result F (the comprehensive value after multi-factor fusion), fire analysis results, etc. Furthermore, a blockchain-style hash chain (calculated using the formula...) is generated by the "block generation unit". ),in The hash of the previous block. For the current data content, Timestamp (For the purpose of determining the summary), ensuring that the data is not tampered with, and meeting the legal validity requirements of fire accident investigations.

[0095] In this embodiment, the device chain is managed by a "device chain management unit" which stores and retrieves health data throughout the entire lifecycle of the devices, including: device health status. Historical change curves (historical records of communication packet loss rate and sensor drift), equipment maintenance records (such as cleaning time and firmware upgrade time), and the time when the equipment is connected to the monitoring system reflect the evolution of the equipment's health status from "connection to retirement".

[0096] The operation chain mentioned in this embodiment stores and calls all operation instructions of the system by the "operation chain management unit", including: manual operation (such as manually adjusting sensor weights and modifying warning thresholds), automatic operation (such as protocol self-update, model self-evolution, and automatic filtering of interference data), and associates the system performance indicators before and after the operation (such as false alarm rate and data processing delay).

[0097] The three-chain evidence mentioned in this embodiment refers to the historical data of the data chain, the device chain, and the operation chain, which serve as the basis for "source tracing analysis".

[0098] The unified timeline mentioned in this embodiment is determined by the "consistency verification unit" within a sliding time window. Internally, a "k=2" consistency check is performed on the "three-chain cross-verification result" and the "fire situation determination result" (when k=3, at least two chains of evidence are consistent with the fire situation determination result, then "high confidence traceability evidence" is generated) to ensure the reliability and traceability of the fire situation determination.

[0099] In this embodiment, the self-evolutionary optimization module will be described in detail. This module is used to optimize the fire situation based on the three-chain cross-validation results obtained from the three-chain tracing module and the fire situation determination results output by the causality and joint criterion module. Equipment health Environmental interference intensity The mapping parameters and the thresholds of the causal correlation degree C and the joint fire index J are recalibrated online and updated in a closed loop under the constraints of retrieval complexity and performance.

[0100] The optimization basis for the self-evolution optimization module is the cross-validation results of the "three-chain traceability module" (feedback on data reliability, equipment health history, and operational effectiveness) and the fire judgment results of the "causal and joint criterion module" (whether there are false alarms or missed alarms), which serve as the core basis for system parameter optimization.

[0101] The optimization target of the self-evolutionary optimization module is , , Mapping parameters: including "initial weights" The setting rules (such as the correspondence between the accuracy of different brand sensors and the initial weight), "device health" The calculation parameters (such as the values ​​of packet loss rate threshold and drift threshold) and the environmental interference intensity The parameters of the synthesis function (such as the piecewise linear coefficients of dust / light / humidity interference). Thresholds for causal correlation degree C and joint fire index J: C threshold (e.g., adjusted from 0.5 to 0.6) and J threshold (e.g., adjusted from 80 to 85) used to determine whether it is a "fire" or "non-fire".

[0102] Regarding the online recalibration mentioned in this embodiment, the parameters and thresholds mentioned above are dynamically adjusted without interrupting fire monitoring during continuous operation of the monitoring system (for example, if frequent dust interference in a certain area leads to false alarms, the corresponding dust interference level is increased). Weights, or adjusting the threshold of C).

[0103] Regarding the complexity and performance constraints mentioned in this embodiment, during the optimization process, it is necessary to check the computational complexity (such as weighted fusion and the computing power consumption of blockchain generation) and performance requirements (such as data processing latency and traceability query speed) of the monitoring system to ensure that the system can still operate efficiently after optimization (e.g., meeting the requirements during querying). (where N is the number of samples).

[0104] The closed-loop update mentioned in this embodiment involves feeding back the optimized parameters and thresholds to the corresponding modules (dynamic protocol adaptive module, multi-factor fusion module, causal and joint criterion module, etc.) to form a closed loop of "data acquisition → analysis and judgment → source tracing and verification → parameter optimization → re-acquisition", so that the system performance can continuously improve iteratively over time.

[0105] Furthermore, the dynamic protocol adaptation module includes: a feature stream extraction unit for extracting protocol-related feature parameters from the raw data; and a change detection unit for statistically analyzing the feature parameters and calculating the rate of change within a sliding window. ,in, The frequency of the feature field at the current time; The frequency of the feature fields in the previous time step; The rate of change is used to generate a protocol update signal when the rate of change exceeds a threshold. The rule self-generation unit is used to generate new parsing rules within a first preset time window based on the protocol update signal and transmit them to the data acquisition unit for protocol parsing of subsequent raw data.

[0106] In this embodiment, the dynamic protocol adaptation module will be described in detail again to clarify the specific sub-units and working logic of the dynamic protocol adaptation module in implementing "protocol adaptation". The specific content is as follows:

[0107] The feature stream extraction unit mentioned in this embodiment is used to extract feature parameters directly related to the communication protocol from the aforementioned raw data (i.e., the raw communication messages collected by various fire sensors but not parsed by the protocol, such as hexadecimal data frames output by temperature sensors and raw concentration messages from smoke sensors). These feature parameters cover the core elements of the protocol, including but not limited to: the command header of the data frame (such as the frame start identifier "0xAA"), field length (the number of bytes in each data segment), numerical conversion rules (such as a certain field needs to be converted to a physical quantity value through "value × coefficient + offset"), baud rate, data bits, and checksum method. (These correspond one-to-one with the protocol elements involved in "changes in the communication protocol" described in the above embodiment, providing an analytical basis for subsequent detection of protocol changes).

[0108] For the change detection unit mentioned in this embodiment, the change detection unit dynamically analyzes the feature parameters extracted by the "feature stream extraction unit" using a sliding window (e.g., a continuous data interval divided into "every 50 data points / every 10 seconds") and calculates the rate of change of the feature parameters. The formula for calculating the rate of change is: ;in, The frequency of characteristic fields at the current moment (within the current sliding window) (e.g., the number of times the specific command header "0xAA" appears in the current window, or the frequency of the numerical distribution of a certain protocol field). This represents the frequency of the feature field in the previous time step (within the previous sliding window); The rate of change is used to generate a protocol update signal when it exceeds a threshold. The calculated rate of change... When the threshold pre-set by the monitoring system is exceeded (e.g., a change rate > 10%, indicating a significant adjustment to the protocol), the unit will generate a protocol update signal, triggering the subsequent protocol parsing rule update process.

[0109] The rule self-generation unit mentioned in this embodiment is used to reverse deduce and generate new parsing rules based on the protocol update signal generated by the "change detection unit" within a first preset time window (the duration can be flexibly set according to the real-time requirements of the monitoring system for protocol adaptation).

[0110] Specifically, if the protocol update signal indicates that "the temperature field of a certain fire-fighting equipment has been moved from the 3rd byte to the 5th byte in the original protocol, and the value conversion formula has changed from 'temperature value = number of bytes × 0.1 - 10' to 'temperature value = byte value × 0.2 - 5'", then the rule self-generation unit will redetermine the parsing logic of the equipment data (including field position, conversion formula, verification rules, etc.) based on the feature stream of the original data, and transmit the newly generated parsing rules to the system's data acquisition unit, so that the subsequently received original data can be parsed according to the new rules, thereby adapting to equipment firmware upgrades or communication protocol changes in real time and ensuring the accuracy of data parsing.

[0111] Furthermore, the multi-factor fusion module includes a communication quality detection unit and a sensor self-calibration unit, as well as equipment health... The calculation is based on: a communication quality detection unit, used to count the number of lost packets and the total number of packets in the data communication link of the i-th channel sensor within a second preset time window, in order to obtain the communication loss rate of that channel; and a sensor self-calibration unit, used to obtain the drift amount of the i-th channel sensor through a built-in reference signal injection method. and the maximum allowable drift value of the sensor in the i-th channel. Comparison; Equipment Health Defined as: ;in, and The statistical value of the sensor in the i-th channel within the third preset time window; when the communication loss rate or drift amount... When the threshold is exceeded, a rejection signal is generated to prevent the raw data from the sensor in the i-th channel from being parsed by the protocol.

[0112] This embodiment further refines the multi-factor fusion module, focusing on "device health". The computational logic of "" and the impact of communication quality and sensor self-calibration on the fusion process are explained in detail below:

[0113] The multi-factor fusion module includes a communication quality detection unit and a sensor self-calibration unit, which together contribute to the "device health" assessment. The calculation provides the basis for "dynamically adjusting the fusion weight based on device health" and is the core of realizing "dynamic adjustment of fusion weight based on device health".

[0114] The communication quality detection unit mentioned in this embodiment operates as follows:

[0115] Time window setting: The communication link of the i-th channel sensor is monitored using the second preset time window (the duration of which can be flexibly configured according to the monitoring frequency requirements of the monitoring system for communication stability).

[0116] The statistical object is the data collected during the data transmission process of this channel. (Number of data packets that failed to transmit) and (Total number of data packets attempted to be transmitted).

[0117] Core function: Through " / "Calculate the communication loss rate to reflect the reliability of sensor data transmission (the higher the loss rate, the more unstable the data transmission, and the weight of that channel should be reduced accordingly during fusion).

[0118] Working mechanism of the sensor self-calibration unit:

[0119] Calibration method: The sensor is self-calibrated by using a built-in reference signal injection method (for example, injecting a known standard temperature electrical signal into the temperature sensor and injecting a standard concentration of smoke simulation signal into the smoke sensor).

[0120] Drift acquisition: Compare the sensor's output value to the "reference signal" with the "standard value" to obtain the drift amount of the i-th channel sensor. (That is, the deviation between the actual output of the sensor and the standard value, such as a temperature sensor drift of +1℃, then...) =1℃).

[0121] Drift comparison: The amount of drift With respect to the maximum allowable drift value of the sensor Comparison (different types of sensors) Different, for example, temperature sensors can be set =2℃, smoke sensor can be set (5% LEL).

[0122] Device health Definition and calculation of equipment health The calculation formula is Part 1 This reflects the impact of communication quality on equipment health. A higher packet loss rate and a smaller value for this section indicate more unstable communication and lower equipment health. (Part Two) This reflects the impact of sensor drift on health status. Drift amount. The closer The smaller this value, the worse the sensor's accuracy and the lower the device's health.

[0123] overall By combining communication reliability and sensor accuracy, the "health level" of the device is quantified, with a value range of 0 ≤ ≤1( The closer the value is to 1, the more reliable the equipment is, and the more reasonable the weighting in multi-factor fusion is.

[0124] The logic for removing outlier data is as follows: when the "signal loss rate" ( / ) or "drift amount" "When the threshold preset by the monitoring system is exceeded, a rejection signal will be generated to prevent the raw sensor data of the i-th channel from entering the 'protocol parsing' process (to avoid unreliable data contaminating the subsequent standardization and fusion results F). This logic complements the 'data recovery mechanism' of the 'hysteresis logic control unit': if the stability of the subsequent equipment meets the requirements, the data parsing of that channel will be restored."

[0125] Furthermore, the multi-factor fusion module also includes a dust detection unit, a light detection unit, a humidity detection unit, an interference factor synthesis unit, and an environmental interference intensity unit. The calculation is based on: a dust detection unit, used to receive dust concentration parameters from standardized sensor data. and in >50 Output dust interference factor The illumination detection unit is used to receive illumination intensity parameters from standardized sensor data. and in >5000 Output light interference factor The humidity detection unit is used to receive humidity parameters from standardized sensor data. and in Output humidity interference factor when >80% Interference factor synthesis unit, used to synthesize dust interference factors Light interference factor Humidity interference factor Input a piecewise linear saturated function modeler to obtain the intensity of environmental disturbances. Environmental disturbance intensity It is only updated when the three-chain traceability module confirms that the impact is due to environmental factors.

[0126] This embodiment further refines the multi-factor fusion module, clarifying the intensity of environmental interference. The calculation method and working logic of related sub-units are explained in detail below: The multi-factor fusion module adds a dust detection unit, a light detection unit, a humidity detection unit, and an interference factor synthesis unit. These units together contribute to the calculation of "environmental interference intensity". The calculation provides the basis for realizing "dynamic adjustment of fusion weights based on environmental interference intensity" (i.e., middle The core (key link).

[0127] Dust detection unit, input: receives standardized sensor data (parsed into a readable format) processed by the "Dynamic Protocol Adaptive Module". Trigger logic: when dust concentration parameter is detected... and in >50 Output dust interference factor (This can be generated through experimental calibration rules, such as " =0.1+0.01× " ≤50 is taken as 0), which reflects the degree of interference of dust concentration on equipment such as smoke sensors (too much dust can easily lead to false alarms from smoke sensors).

[0128] Light detection unit, input: receives light intensity parameter L from standardized sensor data. Trigger logic: when light intensity is detected... >5000 Output light interference factor (Generated through experimentally calibrated rules, such as " =0.01×L-4”, take 0 when L≤5000), which reflects the degree of interference of strong light on devices such as flame sensors (strong light can easily cause flame sensors to misidentify as flames).

[0129] Humidity detection unit, input: humidity parameters received from standardized sensor data. (e.g., humidity:) %). Triggering logic: When humidity is detected. Output humidity interference factor when >80% (This can be generated through experimentally calibrated rules, such as " =0.1×( -80) ≤80 is taken as 0), which reflects the degree of interference of high humidity on temperature sensors, smoke sensors, etc. (high humidity may affect sensor sensitivity).

[0130] The function of the interference factor synthesis unit is to synthesize dust interference factors. Light interference factor Humidity interference factor The input piecewise linear sum function connector calculates the environmental interference intensity using a preset piecewise linear function (calibrated based on experimental data of actual environment and sensor interference). This value quantifies the overall interference of environmental factors on the i-th channel sensor, providing a basis for "dynamically adjusting the fusion weights". The larger the value, the stronger the environmental interference, and the lower the effective weight of the channel during fusion. The lower (the lower).

[0131] Environmental disturbance intensity Update logic, environmental interference intensity This needs to be updated only after the three-chain traceability module confirms that "the interference is purely due to environmental factors." For example, the three-chain traceability module uses the "data chain (raw data shows no anomalies)" and "device chain (device health)" to trace the source. Cross-validation of "normal operation" and "operation chain (no improper human operation)" determines that the abnormal sensor data during a certain period is caused by "sudden increase in dust concentration," and updates the data based on this conclusion. The calculation parameters (such as adjusting the piecewise linear function coefficients) can be adjusted to make the quantification of environmental disturbances more accurate.

[0132] Furthermore, the multi-factor fusion module also includes: a hysteresis logic control unit, used to handle situations where the raw data from the sensor in the i-th channel is affected by device health. or environmental disturbance intensity When protocol parsing is prohibited, monitor the i-th channel within the continuous observation time threshold. The stability within the protocol is assessed; when the stability is satisfied, a recovery signal is output to gradually recover the original data of the sensor in the i-th channel.

[0133] In this embodiment, the multi-factor fusion module will be further refined, focusing on the "recovery mechanism after sensor channel parsing is prohibited". By adding a hysteresis logic control unit, dynamic management of abnormal channels can be achieved, avoiding long-term offline operation of sensors due to temporary interference or short-term failures. The specific explanation is as follows:

[0134] The hysteresis logic control unit is the unit responsible for "abnormal channel recovery" in the multi-factor fusion module. Its core function is: when a certain sensor channel (the i-th channel) experiences an abnormal channel failure due to device health issues... Substandard (e.g., excessively high communication loss rate, excessive drift) or environmental interference intensity If the levels are too high (such as dust concentration, light intensity, or humidity exceeding the thresholds mentioned above), the monitoring system will prohibit protocol parsing by rejecting the signal. The system will then continuously monitor the channel and, once the "stability conditions" are met, trigger the data parsing recovery process to ensure that the sensor channel can re-participate in data fusion after the fault or interference is eliminated.

[0135] In the scenario of "prohibition of protocol parsing", based on the above embodiments, the specific scenarios in which the i-th channel is prohibited from parsing include:

[0136] Device health Too low: For example, a communication loss rate > 30% (leading to...) <0.7), or sensor drift amount Approaching the maximum allowable value (e.g., temperature sensor drift of 1.8℃,) =2℃, resulting in <0.1), final <Preset threshold of the monitoring system (e.g., 0.5);

[0137] Environmental disturbance intensity Excessive: For example, dust concentration =80 (Exceeding 50) Threshold), leading to dust interference factors =0.5, after adding other interferences > The monitoring system has a preset threshold (e.g., 0.6).

[0138] For continuous observation time threshold , This is the "stability observation duration" preset by the monitoring system (which can be adjusted according to sensor type and application scenario: for sensors in critical areas). It can be set to 2 minutes for rapid recovery; for non-critical areas, It can be set to 10 minutes to ensure stability. Its function is to prevent false judgments that the sensor has returned to normal due to "instantaneous fluctuations" (such as sudden dust or brief communication interruptions), by continuously... Long-term observation confirms that the improvement in equipment status or environmental disturbances is "stable and sustainable".

[0139] To determine whether "stability is satisfied," the hysteresis logic control unit monitors the device health of the i-th channel in real time. and environmental disturbance intensity To determine whether it meets the "stability condition", the following criteria are included:

[0140] Device health continuous Duration ≥ recovery threshold (e.g., 0.8, higher than the threshold of 0.5 when blocked), and communication loss rate ≤ 5%, sensor drift amount ≤0.5× (e.g., temperature sensor drift ≤1℃);

[0141] Environmental disturbance intensity continuous Duration ≤ recovery threshold (e.g., 0.2, lower than the prohibited threshold of 0.6), and dust concentration ≤ 30. Light intensity ≤4000 lux, humidity ≤75%.

[0142] The process of "recovery signal" and "gradual recovery protocol resolution".

[0143] When the "stability is satisfied", the hysteresis logic control unit outputs a recovery signal, triggering the parsing recovery process of the i-th channel, and the recovery method is "gradual recovery":

[0144] Initially: Allow the channel data to participate in protocol parsing, but assign a low temporary weight (such as 30% of the normal weight) in multi-factor fusion to avoid the sudden access of potentially fluctuating data affecting the fusion results;

[0145] Mid-term: Continuous monitoring , If it runs stably again / 2 duration, increasing the weight to 70% of the normal weight;

[0146] Later stage: If it continues to stabilize, it will eventually return to normal weight (from...). (Computation), fully involved in data fusion.

[0147] Furthermore, the degree of causal association C is defined as: ,in: This represents the change in the temperature signal relative to the reference value within the third preset time window. This represents the change in smoke concentration signal relative to a reference value within a preset time window. It is the minimum time difference between the temperature signal reaching the temperature threshold change point and the smoke signal reaching the smoke threshold change point.

[0148] This embodiment refines the causal and joint criterion module, clarifying the definition and calculation logic of "causal correlation degree C," which is used to quantify the temporal correlation characteristics of key parameters in a fire, providing a core basis for "fire authenticity determination." The specific explanation is as follows:

[0149] The causal correlation coefficient C is a quantitative indicator that measures the causal relationship between "temperature change" and "smoke concentration change". In real fires, there is usually a clear temporal correlation between temperature rise and smoke generation (e.g., combustibles heat up first and then produce smoke); while in disturbed scenarios (e.g., kitchen fumes, dust), there is often only a single parameter abrupt change (e.g., only smoke concentration increases, with no corresponding temperature change). Therefore, the magnitude of C can effectively distinguish between "real fires" and "environmental disturbances" and is an important component of the "dual threshold criterion" (together with the joint fire index J, forming the judgment basis).

[0150] The specific meanings of each parameter in the formula, and the formula for calculating the causal correlation degree C are as follows: .

[0151] (Temperature Change) refers to the change in temperature signal relative to the "baseline value" within a third preset time window (e.g., 10 minutes, adjustable according to fire development speed: 5 minutes for rapid combustion scenarios, 15 minutes for slow smoldering scenarios). "Baseline Value": The normal ambient temperature of the area (e.g., 25℃, obtained through historical data statistics from the monitoring system); Calculation Method = (If the temperature drops, take 0, as the temperature usually rises during a fire). For example, if the temperature in a certain area rises from 25℃ to 40℃, then... =15℃.

[0152] (Smoke Concentration Change) refers to the change in smoke concentration signal relative to the "baseline value" within the third preset time window. "Baseline Value": The normal smoke concentration in this area (e.g., 0% LEL, i.e., no visible smoke); Calculation method: = (If the concentration decreases, take 0, as smoke typically accumulates during a fire). For example, if the smoke concentration increases from 0% LEL to 20% LEL, then... =20%LEL).

[0153] (Time Difference) refers to the minimum time difference between "the temperature signal reaching the temperature threshold change point" and "the smoke signal reaching the smoke threshold change point". "Temperature Threshold Change Point": The moment when the temperature exceeds "the baseline value + the preset threshold" (e.g., baseline 25℃ + threshold 5℃ = 30℃, i.e., the moment the temperature first reaches 30℃); "Smoke Threshold Change Point": The moment when the smoke concentration exceeds "the baseline value + the preset threshold" (e.g., baseline 0%LEL + threshold 5%LEL = 5%LEL, i.e., the moment the concentration first reaches 5%LEL); Calculation method: If the temperature reaches the threshold first, then... = If the smoke reaches the threshold first, then = (If only a single parameter meets the standard, Take the maximum value to make C approach 0).

[0154] For the application logic in some specific embodiments, in a real fire scenario: for example, an electrical fire occurs in a certain area, the temperature reaches 30°C (temperature threshold point) in the 3rd minute, and the smoke reaches 5% LEL (smoke threshold point) in the 5th minute, then... =2min; the temperature eventually rises to 45℃ ( =20℃), smoke concentration rises to 30%LEL ( =30%LEL), then C=(20×30) / 2=300 (the value is relatively large, which is consistent with the correlation characteristics of a real fire).

[0155] Interference scenario: For example, kitchen fumes cause the smoke concentration to reach 5% LEL (smoke threshold) in the second minute, but the temperature remains at 25°C (not reaching the temperature threshold). =0, C=0 (the value is extremely small and is judged as interference).

[0156] Furthermore, the Joint Fire Index J is defined as: ;in, This represents the change in the temperature signal relative to the reference value within the third preset time window. The change in smoke concentration signal relative to a reference value within the third preset time window; This represents the change in the carbon monoxide signal relative to a reference value within a third preset time window. This refers to the time interval required for the temperature signal to reach the temperature threshold change point within the third preset time window. This refers to the time interval required for the smoke signal to reach the smoke threshold change point within the third preset time window; This is the time interval required for the carbon monoxide signal to reach the carbon monoxide threshold change point within the third preset time window; , , These are weighting coefficients, and .

[0157] In this embodiment, the causal and joint criterion module is further refined, clarifying the definition and calculation logic of the "joint fire index J". Unlike the aforementioned "causal correlation degree C" (which focuses on the causal relationship between temperature and smoke), J comprehensively quantifies the fire intensity and development trend by integrating the "rate of change" of three core fire parameters: temperature, smoke, and carbon monoxide. This provides another key judgment basis for the "dual threshold criterion," as explained in detail below:

[0158] The Combined Fire Intensity Index (J) is a quantitative indicator that comprehensively measures the rate of change of three key fire parameters: temperature, smoke, and carbon monoxide. In real fires, these three parameters typically change significantly synchronously or sequentially with the combustion process (e.g., rapid temperature rise, surge in smoke concentration, and increase in carbon monoxide concentration). However, in disruptive scenarios (e.g., steam interference, brief periods of high temperature), only a single parameter often shows an anomaly, and the rate of change is gradual. Therefore, the magnitude of J effectively reflects the overall intensity of the fire, complementing the aforementioned C (which reflects the causal relationship between parameters) and jointly improving the accuracy of fire assessment.

[0159] The formula for calculating the Joint Fire Index J is: The specific explanation and definition of the calculation formula are as follows:

[0160] Changes in core parameters: ( , ):

[0161] (Temperature change): as mentioned above The definition is consistent, referring to the change in the temperature signal relative to the "reference value" within the third preset time window. = (Take 0 when the temperature decreases). For example, if the temperature rises from 25℃ to 50℃, then... =25℃.

[0162] (Change in smoke concentration): as mentioned above With consistent definition, the change in smoke concentration relative to the "baseline value" within the third preset time window ( = (Take 0 when the concentration decreases). For example, if the smoke concentration increases from 0% LEL to 40 LEL, then... =40%LEL.

[0163] (Change in carbon monoxide concentration): refers to the change in carbon monoxide concentration relative to the "baseline value" within the third preset time window (the "baseline value" is the carbon monoxide concentration in the normal environment, such as 0 ppm). = (When the concentration decreases, take 0). For example, if the carbon monoxide concentration increases from 0 ppm to 50 ppm, then... =50ppm.

[0164] Time interval ( , , ):

[0165] The time interval required for the temperature signal to reach the "temperature threshold change point". The moment when the "temperature threshold change point" value exceeds the "reference value + preset value" (e.g., reference 25℃ + threshold 10℃ = 35℃, i.e., the time it takes for the temperature to rise from the initial temperature to 35℃). For example, if it takes 2 minutes for the temperature to rise from 25℃ to 35℃, then... =2 minutes.

[0166] The time interval required for the smoke concentration to reach the "smoke threshold change point". The "smoke threshold change point" refers to the moment when the concentration exceeds the "baseline value + preset threshold" (e.g., baseline 0%LEL + threshold 10%LEL = 10%LEL, i.e., the time it takes for the smoke concentration to rise from the initial concentration to 10%LEL). For example, if it takes 3 minutes for the smoke concentration to rise from 0%LEL to 10%LEL, then... =3 minutes.

[0167] The time interval required for the carbon monoxide concentration to reach the "carbon monoxide threshold change point." The "carbon monoxide threshold change point" refers to the moment when the concentration exceeds the "baseline value + preset threshold" (e.g., baseline 0 ppm + threshold 20 ppm = 20 ppm, i.e., the time it takes for the initial concentration to rise to 20 ppm). For example, if it takes 4 minutes for the carbon monoxide concentration to rise from 0 ppm to 20 ppm, then... =4 minutes.

[0168] Weighting coefficients ( , , All three are positive numbers and satisfy the following conditions: This is used to reflect the "importance weight" of different parameters in fire situation determination.

[0169] The weights can be dynamically adjusted according to the scenario: for example, in an electrical fire, the increase in carbon monoxide concentration is more significant, so weights can be set accordingly. =0.4、 =0.3、 =0.3; In wood burning scenarios, the change in smoke concentration is more pronounced, and can be set to... =0.3、 =0.3、 =0.4.

[0170] In some specific embodiments, a real fire scenario is described: for example, a combustible material burns in an area, and within 3 minutes, the temperature changes from 25°C to 45°C. =20℃, =2min), smoke concentration from 0%LEL → 30%LEL ( =30%LEL =3min), carbon monoxide from 0ppm →40ppm ( =40ppm, =3min). If ,but: (The value is relatively large, which is consistent with the total characteristics of a real fire).

[0171] Interference scenarios: For example, kitchen steam can cause the smoke sensor to give a false alarm (smoke concentration changes from 0% LEL to 15% LEL). =15%LEL, =1min), but the temperature (25℃) and carbon monoxide (0ppm) remained unchanged. =0, If =0), then: like( =1 / 3, then J=15, which is a low value and is judged as interference).

[0172] In this embodiment, J is another core parameter of the "dual threshold criterion" in the "causality and joint criterion module," which, together with C, determines the "fire situation determination result" (such as when...). and It was only then that the fire was confirmed.

[0173] It should be noted that C focuses on the causal relationship between "temperature and smoke", while J focuses on the combined rate of change of "temperature, smoke, and carbon monoxide". The two complement each other to cover the "correlation" and "intensity" characteristics of the fire.

[0174] It should be noted that the calculation of J is based on real-time data within the third preset time window, and its processing delay must meet the total delay requirements of the monitoring system to ensure the real-time nature of the judgment.

[0175] It should be noted that the self-evolutionary optimization module can optimize based on historical data. , , The value of J can be adjusted (e.g., by analyzing false alarm cases and reducing the weight of sensitive parameters in interference scenarios) to improve the accuracy of J determination.

[0176] In this embodiment, by comprehensively considering the rate of change of multiple parameters, a more comprehensive quantitative basis for fire determination is provided, which is consistent with the core function of the causal and joint criterion module. At the same time, it provides an adjustable parameter dimension for the self-evolution and optimization of the monitoring system, further improving the reliability of fire determination.

[0177] Furthermore, the three-chain traceability module includes: a data chain management unit, used to store and retrieve the original data;

[0178] The device chain management unit is used to store and retrieve the health status of the devices. The system includes: a change data unit; an operation chain management unit for storing and retrieving manual or automatic control commands; and a consistency verification unit for checking data within a sliding time window. Within the process, a k=2 consistency check is performed between the three-chain cross-validation results and the fire situation determination results. If at least two chains are consistent, high-confidence tracing evidence is generated as the three-chain cross-validation result; where k=3, This is the preset verification window duration.

[0179] This embodiment details the three-chain traceability module, clarifying its core sub-units and the specific logic of "three-chain cross-verification." By managing the "data chain, device chain, and operation chain" in parallel and performing consistency verification, the traceability and reliability of fire assessment results are ensured. The specific explanation is as follows:

[0180] The three-chain traceability module includes a data chain management unit, a device chain management unit, an operation chain management unit, and a consistency verification unit. The four work together to realize the full-process traceability function of "data storage-calling-verification". It is the specific implementation of "parallel maintenance of data chain, device chain and operation chain to obtain three-chain evidence" in the above embodiment.

[0181] The data link management unit stores: raw data, standardized sensor data, fusion results F, and intermediate data for fire analysis (full-process data).

[0182] Raw data: Unparsed raw communication messages collected by various sensors (such as hexadecimal data frames from temperature sensors and raw concentration messages from smoke sensors).

[0183] Standardized sensor data: Structured data parsed by the dynamic protocol adaptive module (e.g., "Temperature: 25℃, Timestamp: 2025-09-01 10:00:00").

[0184] Fusion result: The weighted composite value output by the multi-factor fusion module (e.g., "Comprehensive Fire Index: 85").

[0185] Intermediate data for fire analysis: parameters such as causal correlation degree C and joint fire index J calculated by the causal and joint criterion module.

[0186] This data chain management unit provides "full data lifecycle recording" to ensure that data at each stage is searchable and verifiable.

[0187] The device chain management unit is used to store and retrieve all data related to the health status of the device firmware, including but not limited to:

[0188] Device health Change data: as calculated in the above embodiments Time series curves (e.g., a temperature sensor within 1 hour) (Process record of decreasing from 0.9 to 0.6)

[0189] Communication quality data: packet loss rate, number of retransmissions, and other communication link status.

[0190] Sensor self-calibration data: drift amount Historical data (such as monthly calibration drift changes);

[0191] Device lifecycle records: access time, firmware upgrade records, maintenance time (such as cleaning, replacement of parts), etc.

[0192] The purpose of this equipment chain management unit is to provide "equipment status evolution trajectory" for traceability and to determine whether equipment health deterioration affects fire assessment.

[0193] The operation chain management unit stores and retrieves all operation commands and related data from the monitoring system, including:

[0194] Manual control commands: User-manual operation (such as adjusting the initial weights of the sensors) Modify the judgment threshold of C or J; manually start / stop a certain sensor.

[0195] Automatic control commands: Automatic operation of the monitoring system (such as protocol self-updating of the dynamic protocol adaptive module, interference data filtering of the multi-factor fusion module, and parameter recalibration of the self-evolution optimization module);

[0196] Performance metrics before and after operation: false alarm rate, data fusion accuracy, response time, etc. before / after each operation.

[0197] This operation chain management unit provides a "monitoring system operation trajectory" for source tracing to determine whether an abnormal fire situation was caused by operational errors.

[0198] The consistency verification unit is the "core verification hub" of this three-chain traceability module, and it achieves "three-chain cross-verification" through the following steps:

[0199] Sliding Time Window : Set the preset verification window duration (e.g. =10min (can be adjusted according to the speed of fire development), the "fire determination result" and "three-chain evidence" are compared within the same time interval (to avoid verification errors caused by time misalignment).

[0200] k=2 consistency check:

[0201] k=3: refers to the three chains: data chain, device chain, and operation chain;

[0202] "k takes 2": This requires that at least two of the three chains of evidence be consistent with the fire assessment result. For example:

[0203] If the data chain shows "temperature and smoke surge simultaneously", the device chain shows "sensor health is normal", and the operation chain shows "no abnormal operation", then all three chains are consistent with the "real fire" judgment and pass the verification.

[0204] If the data chain displays "smoke surge only", the device chain displays "smoke sensor drift exceeds limit", and the operation chain displays "no abnormal operation", then the data chain and device chain are consistent (supporting "false alarm caused by sensor failure"), and the verification is passed.

[0205] High-confidence source tracing evidence: If the "k=2" verification is passed, "high-confidence source tracing evidence" (such as "both the data chain and the equipment chain support the determination that the fire is real, the operation chain has no abnormalities, and the confidence level of the source tracing evidence is 90%) is generated. This serves as the final output of the three-chain cross-verification results, providing a reliable optimization basis for the self-evolution optimization module.

[0206] It should be noted that this embodiment is a specific implementation of the three-chain traceability module, providing the generation logic for the three-chain cross-validation results and supporting the parameter updates of the self-evolutionary optimization module. Meanwhile, the core data of the data chain, device chain, and operation chain are the inputs of the block generation unit (such as...). Judgment Summary This provides a foundation for blockchain-level tamper-proofing. Furthermore, the storage content of the three chains is completely consistent with the definitions of "data chain traceability, device chain traceability, and operation chain traceability," serving as a functional prerequisite for "three chains and one analysis." The operation chain management unit stores the direct data source for calculating "operation impact I" based on "performance before and after operation."

[0207] In this embodiment, by clearly defining the storage content and verification logic of the three chains, the core objective of "data traceability and result verification" is achieved, providing traceability support for the reliability of fire situation determination. At the same time, it forms a closed loop with the blockchain's anti-tampering and root cause analysis functions, ensuring that the monitoring system meets the stringent requirements of fire accident investigation.

[0208] Furthermore, the three-chain traceability module also includes a block generation unit, which is used to generate event digests. timestamp Judgment Summary Compared with the previous block hash Concatenate and calculate the hash value of the new block The calculation formula is: ;in, For cryptographic hash functions; This indicates a byte concatenation operation performed in a predetermined order.

[0209] This embodiment details the three-chain traceability module, focusing on the specific implementation logic of the block generation unit. This unit generates blocks from key three-chain traceability data (event source, timestamp, judgment digest, etc.) according to specific hash rules, constructing an immutable chain-like data structure. This provides tamper-proof protection for three-chain traceability data, ensuring the authenticity and legal validity of traceability evidence. A detailed explanation follows:

[0210] The block generation unit is the core execution unit of the three-chain traceability module to achieve "data tamper-proofing." Essentially, it packages the key traceability data from the "data chain, device chain, and operation chain" in the above embodiments into "blocks" using a cryptographic hash algorithm, and forms a chain structure through "hashing association with the previous block." Its core function is:

[0211] Tamper-proof: If the data in any block is modified, the hash value of that block and all subsequent blocks will become invalid. This can be detected in real time and cannot be unilaterally concealed.

[0212] Evidence solidification involves solidifying key data related to fire determination (such as the source of the incident and the determination result) in the form of blocks, providing "undeniable" evidence for fire accident investigations and meeting the stringent requirements for the "authenticity and completeness" of source tracing data.

[0213] The core of the block generation unit is to calculate the hash value of the new block using a specific formula, which is: , The hash value of the new block is the unique identifier of the currently generated block, calculated using the SHA256 hash algorithm, and is used to verify the integrity of the block data. The hash value of the previous block and the hash value of the last generated block are the core linking points of the "chain structure", ensuring that the blocks are consecutive in chronological order; For event summary, the core raw data for three-chain tracing, namely the key information of "data chain, equipment chain, and operation chain" in the above embodiment (excluding redundant data), such as: Data chain: standardized sensor data (e.g., "temperature 25℃, smoke 10% LEL"), fusion results (e.g., "comprehensive fire index 85"); Equipment chain: equipment health status. Abnormal records (e.g., "sensor drift 1.5℃"); Operation chain: critical operation instructions (e.g., "manually adjust C threshold to 300"); For timestamps, event summaries The generated millisecond-level precise time is used to ensure that blocks are generated in "time order", which corresponds to the "sliding time window for consistency verification" in the above embodiment, and avoids data time misalignment; For cryptographic hash functions; This refers to byte concatenation operations, indicating byte concatenation operations in a predetermined order, according to... → → → The fixed order of the data concatenates the byte data of each element into a complete input string, ensuring the uniqueness of the hash calculation (different orders will result in different hash values).

[0214] For ease of understanding, this embodiment uses the generation of a block for a "false alarm event of kitchen fumes" as an example to illustrate the specific calculation process:

[0215] 1. Determine the values ​​of each element: (Hash of the previous block): a1b2c3d4e5f6... (SHA256 value calculated from the previous block); (Event Summary): {"Data Chain": {"Temperature": 25℃, "Smoke": 30% LEL}, "Device Chain": {"Smoke Sensor"} ": 0.9}, "Operation Chain": {"No manual operation}}; (Timestamp): 2025-09-01 10:15:30.123 (milliseconds, converted to byte data); (Judgment Summary): The fire situation judgment result is "false alarm (oil fume interference)", and its SHA256 digest is f7e8d9c0b1a2....

[0216] 2. Byte concatenation: Concatenate bytes sequentially. This forms the complete input string.

[0217] 3. Calculate the hash: Perform the SHA256 algorithm on the concatenated string to obtain the new block hash. ='c4d5e6f7a8b9...', this value is the unique identifier of the current block.

[0218] The block generation unit ensures the real-time performance and accuracy of block generation through a five-step process: triggering, data collection, concatenation, hash calculation, and storage.

[0219] Triggering conditions: An "event-triggered" mechanism is adopted—when the consistency verification unit in the above embodiment outputs "high-confidence traceability evidence" (such as the verification results of "false alarm" and "real fire"), block generation is immediately triggered (to avoid the risk of loss due to delayed uploading of key data to the chain).

[0220] Data collection: Extract event summaries from the three-chain management units (data chain, device chain, and operation chain) in the above embodiments. Extract the "fire situation determination result" from the causality and joint criterion module and calculate ", synchronously obtain "timestamp" "and "previous block hash" ”;

[0221] Byte concatenation: strictly follow " → → → "Concatenate the byte data of each element in sequence (the order cannot be changed);"

[0222] Hash calculation: Execute the SHA256 algorithm to generate a new block hash. .

[0223] Block storage: will " The "+ spliced ​​original element data" is stored as a complete block in the distributed database of the three-chain traceability module (consistent with the three-chain data storage location in the above embodiment, ensuring rapid association during traceability).

[0224] In this embodiment, the hash chain design of the "block generation unit" upgrades the key data of the three-chain traceability from "traceable" to "tamper-proof". This is the core technical means to realize the anti-tampering function of the three-chain traceability module. It is consistent with the description logic of the previous embodiment and provides key support for the reliability and compliance of the fire determination system.

[0225] Furthermore, the self-evolutionary optimization module includes a performance monitoring unit, used to retrieve fire situation determination results, three-chain cross-validation results, and standardized sensor data under the time slice index, and record the time required for retrieval as the query latency. When the query latency meets the requirements... If the existing parameters are maintained, parameter recalibration will be triggered; among them, To reduce query latency, The sample size; the parameter update unit, used to update the parsing rules and device health status when recalibration is triggered. Environmental interference intensity The calculation parameters and the criterion thresholds for causal correlation degree C and joint fire index J are updated. Through shadow deployment and rollback mechanisms, the updated calculation parameters are fed back to the dynamic protocol adaptive module and the multi-factor fusion module to replace the original parameters and take effect in subsequent protocol parsing and fusion. The updated criterion thresholds are fed back to the causal and joint criterion module to replace the original criterion thresholds and take effect in subsequent criterion analysis.

[0226] This embodiment details the self-evolutionary optimization module, clarifying its core logic for achieving "dynamic optimization of monitoring system parameters." By monitoring performance in real time and dynamically updating key parameters, the monitoring system can autonomously iterate and upgrade during operation, continuously improving the accuracy of fire assessment and operational efficiency. The specific explanation is as follows:

[0227] The self-evolution optimization module is the "self-iterative hub" of the monitoring system. Its core objective is to dynamically adjust key system parameters based on the results of three-chain cross-validation (high-confidence traceability evidence output in the above embodiments) and fire situation determination results (output of the causal and joint criterion module in the above embodiments). Under the premise of "ensuring performance constraints" (such as response speed and computational complexity), it gradually reduces the false alarm rate and false negative rate, and improves the accuracy of multi-source data fusion and the reliability of fire situation determination.

[0228] The self-evolutionary optimization module includes a performance monitoring unit and a parameter update unit. The two work together to achieve the entire process of "performance monitoring → triggering optimization → parameter update → closed-loop effect". The specific logic is as follows:

[0229] The performance monitoring unit "monitors the system's operating status in real time" and determines whether current parameters need adjustment through quantitative indicators. The specific mechanism is as follows:

[0230] Time Slice Index: Divide the monitoring system's runtime into continuous "time slices" (e.g., one slice every 10 minutes), and retrieve the following data within each slice:

[0231] Fire situation assessment results include conclusions such as "real fire", "false alarm", and "missed report" (from the causal and joint criterion module in the above embodiments);

[0232] The results of the three-chain cross-validation include "consistency of data chain, device chain, and operation chain" and "high-confidence traceability evidence" (from the consistency verification unit in the above embodiments).

[0233] Standardized sensor data: Structured data parsed by the dynamic protocol adaptive module (used to analyze the potential impact of parameter adjustments).

[0234] Query latency monitoring: Record the time required to retrieve the above data, which is defined as query latency. (Reflects the efficiency of system data processing and retrieval).

[0235] Performance constraints: When the query latency meets If the monitoring system is deemed to be performing normally, the existing parameters are maintained; otherwise, if it is deemed to be substandard, parameter recalibration is triggered (i.e., the optimization process is started).

[0236] In the calculation formula, N is the number of samples retrieved (e.g., if 1000 data points are retrieved within a certain time slice, N=1000).

[0237] The logic behind this condition is that the larger the sample size, the slightly higher the allowable query latency (N / 1000 items), but it must be controlled within a reasonable range above the basic threshold (50ms) to ensure that the system response speed meets the real-time requirements of fire monitoring (avoiding system lag due to complex parameters).

[0238] The parameter update unit is responsible for adjusting and applying the parameters after the performance monitoring unit triggers "parameter recalibration." Its core logic includes three parts: "optimization object," "update mechanism," and "feedback loop."

[0239] The optimization targets include clearly defining the range of parameters that need to be updated, covering the core decision-making logic of the monitoring system, specifically including:

[0240] Parsing rules: Protocol parsing rules generated in the dynamic protocol adaptive module (such as the field mapping relationship and conversion formula generated by the rule self-generation unit in the above embodiment) are used to adapt to the long-term drift of device firmware or communication protocols;

[0241] Device health The calculation parameters include the "communication loss rate threshold" (e.g., adjusted from 30% to 25%) and the "maximum drift allowable value" in the above embodiments. (e.g., the temperature sensor is tightened from 2℃ to 1.5℃);

[0242] Environmental disturbance intensity The calculation parameters include the piecewise linear coefficients of the dust / light / humidity interference factors in the above embodiments (e.g., dust concentration > 50). At that time, the interference factor coefficient was adjusted from 0.01 to 0.015 to enhance sensitivity to high-dust environments.

[0243] The judgment thresholds for causal correlation C and joint fire index J are as follows: In the above embodiment, the judgment threshold for C is adjusted from 300 to 350 (to reduce false alarms in slightly correlated scenarios), and the judgment threshold for J is adjusted from 10 to 12 (to improve the strictness of fire intensity judgment).

[0244] Update Mechanism: Shadow Deployment and Rollback: To avoid monitoring system anomalies caused by direct parameter updates, a "secure update strategy" is adopted.

[0245] Shadow deployment: First, load the updated parameters in the "shadow environment" (a test environment with the same configuration as the production environment), and simulate the operation using historical data or real-time mirror data (such as fire data from the past 24 hours to verify the judgment results of the new parameters).

[0246] Performance verification: If the false positive rate decreases by ≥10% and the query latency still meets the performance constraints in the shadow environment, the update is deemed effective, and the new parameters are deployed to the production environment.

[0247] Rollback mechanism: If the shadow environment shows "increased false alarm rate" or "excessive latency", the update will be abandoned, the original parameters will be maintained, and the system stability will be avoided.

[0248] Feedback loop: The verified new parameters are fed back to the corresponding module, replacing the original parameters and taking effect.

[0249] Parsing rules , The calculated parameters are fed back to the dynamic protocol adaptive module and the multi-factor fusion module, and take effect immediately in subsequent protocol parsing and data fusion.

[0250] The threshold values ​​for criteria C and J are fed back to the causality and joint criteria module, and take effect immediately in subsequent fire situation determination.

[0251] In this embodiment, the monitoring system achieves the following core effects through the logic of "performance monitoring - parameter update - security activation":

[0252] Adaptability: Without human intervention, the system can autonomously adjust parameters according to environmental changes (such as sensor aging or increased interference sources) to maintain judgment accuracy over a long period of time;

[0253] Security: Shadow deployment and rollback mechanisms ensure that parameter updates do not cause system failures, meeting the "high availability" requirements of fire protection systems;

[0254] High efficiency: Performance constraints (query latency) ensure that the optimization process does not excessively increase the system load, balancing "accuracy improvement" and "operational efficiency".

[0255] In this embodiment, a detailed explanation will be provided through specific embodiment 1.

[0256] Example 1: Multi-source fire protection data fusion and fire situation analysis and monitoring system for commercial complexes:

[0257] Scenario Deployment:

[0258] Scenario: A five-story commercial complex (B1-4F), focusing in this embodiment on the 3F shared power distribution / weak current area Z-3 (approximately 800 square meters). (The ceiling space is 0.8m).

[0259] Sensors and channels (Z-3 zone), deployed and uniformly managed according to each sensor channel (reported once every 1 second, Hz):

[0260] 1. Temperature detection (TMP, 2 channels, average value taken);

[0261] 2. Smoke (SMK, photoelectric, 2 channels, average value, unit) );

[0262] 3. Carbon monoxide (CO, 1 ppm);

[0263] 4. Humidity (RH, Channel 1, %RH);

[0264] 5. Illumination (LUX, 1 channel, lux, used for strong light interference detection);

[0265] 6. Dust / PM (PM, Route 1, );

[0266] 7. Communication quality indicators (RSSL, packet loss, retransmission, etc. are statistically analyzed by the edge gateway).

[0267] Communication link: The Z-3 device uses RS-485 / Modbus RTU, and the uplink is uniformly aggregated to the edge gateway (Ethernet→MQTT / JSON) into the platform.

[0268] Time window conventions: First preset time window: Total time limit for protocol self-adaptation generation / verification / hot replacement, ≤3min; Second preset time window: Observation window for joint fire index J, 60s in this embodiment; Third preset time window: Observation window for causal correlation degree C, 30s in this embodiment.

[0269] Initial weights (set during the design phase of the monitoring system) , , , w satisfies .

[0270] Dynamic protocol adaptive module, live / change description:

[0271] Initial protocol: Vendor XV1.0 (RS-485 / Modbus RTU → Gateway → MQTT / JSON), field order , CRC16.

[0272] Event A (10:12:00 on the same day): Manufacturer X remotely upgraded its device to V2.0, added a humidity (RH) field, and changed the CRC from 16 bits to 32 bits.

[0273] Online detection and triggering (feature stream → change detection): The platform performs sliding statistics on the original uplink frames, monitoring changes in "frame header / length histogram, CRC hit rate, and field value entropy"; key feature change rates of adjacent windows: When observing "length increasing from 12 to 16, a sharp drop in CRC16 hit rate, and a new peak in field entropy", a comprehensive analysis was conducted. If the threshold is exceeded, a protocol update signal is triggered (the first preset time window begins counting down).

[0274] Rule self-generation → Shadow parsing → Hot replacement:

[0275] Rule summarization (minutes): Generate candidate rule vendorX_v2, declaration: frame header unchanged, length=16, fields= Scaling is maintained; checksum = CRC32; state machine SYNC→DATA→CHECK.

[0276] Shadow parsing: Candidate rules parse the same traffic in parallel, with a CRC32 hit rate of ≥98% within 3 consecutive sub-windows, smooth temperature / smoke / CO / RH curves, and reasonable physical range, meeting the standards.

[0277] Hot replacement: The switch is completed in 2 minutes and 20 seconds, and the old rules retain the rollback entry.

[0278] Standardized output: A humidity field is added to the unified schema, which can be used by downstream modules without modification.

[0279] Effect: Protocol drift recovery time (MTTR) has been reduced from the traditional "day / week level manual adaptation" to "minute level", with continuous streaming throughout the process.

[0280] Multi-factor fusion module, equipment health For each channel i, packet loss and self-test drift are statistically analyzed within the third preset time window of 30 seconds (1 frame per second, 30 frames in total): Example of statistics inside the window (Event B: 14:05 Cleaning dust; Event C: 17:23 Distribution cabinet short circuit and fire):

[0281]

[0282] If any factor exceeds the limit (packet loss rate or drift exceeds the threshold), the channel triggers a removal signal and is hard removed from the fusion calculation in the subsequent window.

[0283] Environmental disturbance intensity Construct a piecewise linear saturation mapping for the affected channels of dust / light / humidity:

[0284] dust >50 →Primarily acts on SMK, secondary effect on CO;

[0285] illumination >5000 →Affects SMK (light scattering interference);

[0286] humidity >80% → Acts on SMK (condensation / scattering), secondary TMP (has little short-term impact on temperature sensing).

[0287] Consistency constraint: Mapping parameters are only allowed to be updated when the root cause of the three-chain tracing is determined to be affected by the environment.

[0288] In Event B (Dust Cleaning), the measurement , , : , , .

[0289] In Event C (actual fire), the dust levels in the area were normal, the humidity was 55%, and the lighting was normal. , , .

[0290] Dynamic weights and fusion result F, dynamic weight calculation formula: The weighted fusion calculation formula is: ;in This is standardized data parsed from each channel protocol.

[0291] Representative moments within 30 seconds of Event B (dust): :

[0292] Sample values ​​(unit: TMP=℃, SMK=) CO = ppm): , , .

[0293] Dynamic weights:

[0294]

[0295]

[0296] ;

[0297] Fusion: ;

[0298] Despite the high smoke levels, The increase in weights resulted in a slight increase in the fusion value, leaving room for subsequent judgment criteria.

[0299] Event C (Fire) Third preset time window, sampled value: , , .

[0300] Dynamic weights: , , .

[0301] Fusion: The fusion value increased significantly, indicating a fire trend.

[0302] Hysteresis logic: If a channel is affected by device health issues... or environmental disturbance intensity To be suppressed, it needs to be for a continuous duration Only after the "packet loss / drift / disturbance sub-threshold" is met will the recovery weight be gradually increased to avoid jitter in and out.

[0303] The causal correlation degree C (third preset time window 30s) in the causal and joint criterion module is calculated as follows: The definition of this calculation formula: , This refers to the change in temperature and smoke relative to the baseline value within the third preset time window. This is the minimum time difference between when the temperature and the smoke first reach their respective thresholds.

[0304] Event B (Dust):

[0305] Baseline (first window) T=25℃, S=5 At the end of the window, T=26℃ and S=105℃ . T=1, =100. Temperature did not reach the threshold (40℃), record... ≈30s. .

[0306] Event C (fire): Baseline T=25℃, S=5.

[0307] The temperature inside the window first reached 40°C in 10 seconds, and the temperature first reached 80°C in 12 seconds. → =2s. End of window T=80→ =55, S=205→ =200. .

[0308] The combined fire index J (second preset time window 60s) is calculated as follows: , Defined as , , This represents the change in the relative baseline value within the second preset time window of 60 seconds. , , For each threshold time, take the weight. =0.30, =0.40, =0.30.

[0309] Event B (Dust) (within 60 seconds):

[0310] T: 25→26→ =1, Not reached the threshold → Record 60;

[0311] S:5→110→ =105, =20s (passing 80 within 20s) );

[0312] CO: 10→20→ =10, If the threshold is not reached, record 60.

[0313] .

[0314] Event C (Fire) (within 60 seconds):

[0315] T: 25→85→ =60, =10s;

[0316] S:5→220→ =215, =12s;

[0317] CO: 10 → 170 → =160, =15s.

[0318] .

[0319] Dual-threshold output:

[0320] Event B (Environment): , →No fire.

[0321] Event C (Real): , →Highly reliable fire situation.

[0322] If only one of the criteria is met, output "suspected fire".

[0323] Three-chain traceability module:

[0324] Three-chain and consistency (k=2):

[0325] Data link: Records the feature points (peak value, threshold time) of F, TMP / SMK / CO in this window.

[0326] Equipment chain: Records Evolution, communication quality, self-check, rule version.

[0327] Operation chain: Records manual / automatic actions (power outage of distribution cabinet, fan, alarm linkage, etc.).

[0328] In the sliding window Within 90 seconds, perform a consistency check with k=3 or 2:

[0329] Event B: The data chain indicates an SMK anomaly, but TMP / CO does not follow suit; the equipment chain is healthy; the operation chain has a manual "cleaning entry" record → at least two chains point to "environment". Output a high-confidence "environment-induced" sample for subsequent self-evolutionary optimization module use; run and update the E mapping.

[0330] Event C: Data chain (F high, C / J double high), equipment chain (healthy and without abnormalities), operation chain (distribution cabinet tripping, sound and light linkage) → at least two chains are consistent with "high confidence fire", outputting high confidence traceability evidence.

[0331] The local blockchain generates the blockchain in the order of events and performs calculations. ),in, Includes the current C and J values, and weight statistics. Distribution of threshold version number; Key features include (F peak value, threshold time, channel valid / rejection markers, etc.). Uses UTC timestamps. Periodically reconciles with the consortium blockchain to achieve reproducibility / storability.

[0332] The self-evolutionary optimization module retrieves fire situation assessment results, three-chain cross-validation results, and standardized data using a 1-second indexing method; this is recorded as the query latency. The sample size is N, and the constraints are: .

[0333] Statistics 24 hours after event B: N=5000 → upper bound 5 + 50 = 55ms; Actual measurement =60ms) exceeded and the false alarm rate was high in the past 48 hours (concentrated during dusty periods), meeting the "performance deviation threshold" → triggering controlled retraining / recalibration.

[0334] Controlled updates and shadow deployment:

[0335] Update content (controlled scope):

[0336] E's piecewise saturation function parameters (reducing sensitivity to SMK under moderate dust conditions and increasing hysteresis at the upper limit).

[0337] Fine-tuning of the rejection threshold (occasional packet loss of 3-5% will no longer be immediately rejected, but will instead be reduced in weight).

[0338] C / J criterion threshold version number (maintained) Fine-tuning (Up to 11.5 to take into account scenarios of "rapid growth").

[0339] The parsing rules remain unchanged (no new protocol changes).

[0340] Shadow deployment A / B testing: Parallel evaluation of the past 14 days of replay sets: F1 improved by 2.6%, false alarm rate decreased by 31%, and false negatives did not increase.

[0341] Switching and Rollback: After meeting the standards, grayscale testing → hot replacement; no degradation was observed during 24 hours of monitoring after going live, so no rollback is required.

[0342] Parameter feedback: New parameters are fed back to the dynamic protocol adaptive module, multi-factor fusion module, and causal and joint criterion module, so that the system maintains consistent discrimination thresholds and takes effect in subsequent discrimination.

[0343] In this embodiment 1, the dynamic protocol adaptive module completes "change detection → rule self-generation → shadow verification → hot replacement" within the first preset time window to ensure the continuous and reliable standardized sensor data.

[0344] Multi-factor fusion module: based on device health Environmental interference intensity Adjust the weights and merge to output the fusion result F; during dust storms High → F is suppressed; during fire High and Low → F increases significantly; hysteresis inhibits jitter recovery.

[0345] Causality and Joint Criterion Module: Calculate C and J within the third / second preset time window, where event B is low (no fire) and event C is high (highly reliable fire).

[0346] The three-chain traceability module uses k=2 for consistency. It outputs high-confidence evidence internally; it cascades and stores evidence for each judgment, and has the ability to be repeated and shared reliably.

[0347] Self-evolutionary optimization module: Triggered by query latency and performance deviation, it updates E / H and J thresholds in a controlled manner; shadow deployment + A / B + rollback ensure safe deployment; parameters are fed back to the front-end for closed-loop stable evolution.

[0348] It should be noted that the embodiments of the present invention have better implementability and are not intended to limit the present invention in any way. Any person skilled in the art may use the above-disclosed technical content to change or modify it into equivalent effective embodiments. However, any modifications or equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of the technical solution of the present invention.

Claims

1. A multi-source fire data fusion and fire situation analysis and monitoring system, characterized in that, include: The dynamic protocol adaptive module is used to learn and generate parsing rules online when the device firmware or communication protocol changes, and to perform protocol parsing on the raw data collected by each sensor to generate standardized sensor data. A multi-factor fusion module is used to process the standardized sensor data into... Weighting is used to obtain the fusion result F: in, Let be the initial weight of the i-th channel; The device health status for the i-th channel; The environmental interference intensity of the i-th channel; For the standardized sensor data of the i-th channel, The corrected channel weights; n is the total number of sensor channels; The causal and joint criterion module is used to calculate the causal correlation degree C and the joint fire index J based on the time series of key fire correlation parameters contained in the fusion result F, and to confirm the fire situation by combining the fusion result F with the causal correlation degree C and the joint fire index J using a dual threshold, so as to output the fire situation determination result. The three-chain traceability module is used to maintain the data chain, equipment chain and operation chain in parallel to obtain three-chain evidence, and to cross-verify the fire situation determination result with the three-chain evidence using a unified timeline to obtain the three-chain cross-verification result. The self-evolutionary optimization module is used to optimize the system based on the three-chain cross-validation results and the fire situation determination results. , , The mapping parameters and the thresholds of the causal correlation degree C and the joint fire index J are recalibrated online and updated in a closed loop under the constraints of retrieval complexity and performance.

2. The multi-source fire data fusion and fire situation analysis and monitoring system according to claim 1, characterized in that, The dynamic protocol adaptive module includes: A feature stream extraction unit is used to extract protocol-related feature parameters from the raw data; The change detection unit is used to statistically analyze the feature parameters and calculate the rate of change within a sliding window. in, The frequency of the feature field at the current time; The frequency of the feature fields in the previous time step; The rate of change is used to generate a protocol update signal when the rate of change exceeds a threshold. The rule self-generation unit is used to generate new parsing rules within a first preset time window according to the protocol update signal, and transmit them to the data acquisition unit for protocol parsing of subsequent raw data.

3. The multi-source fire data fusion and fire situation analysis and monitoring system according to claim 1, characterized in that, The multi-factor fusion module includes a communication quality detection unit and a sensor self-calibration unit, which are related to the device health status. The calculation is based on: The communication quality detection unit is used to count the number of lost packets and the total number of packets for the data communication link of the i-th channel sensor within a second preset time window, so as to obtain the communication loss rate of that channel. The sensor self-calibration unit is used to obtain the drift amount of the i-th channel sensor through a built-in reference signal injection method. and the maximum allowable drift value of the sensor in the i-th channel. contrast; The health of the device Defined as: in, and The statistical value of the sensor in the i-th channel within the third preset time window; When communication loss rate or drift When the threshold is exceeded, a rejection signal is generated to prevent the raw data from the sensor in the i-th channel from being parsed by the protocol.

4. The multi-source fire data fusion and fire situation analysis and monitoring system according to claim 3, characterized in that, The multi-factor fusion module further includes a dust detection unit, a light detection unit, a humidity detection unit, and an interference factor synthesis unit, wherein the environmental interference intensity... The calculation is based on: The dust detection unit is used to receive the dust concentration parameter from the standardized sensor data. and in >50 Output dust interference factor ; The illumination detection unit is used to receive the illumination intensity parameter from the standardized sensor data. and in >5000 Output light interference factor ; The humidity detection unit is used to receive humidity parameters from the standardized sensor data. and in Output humidity interference factor when >80% ; The interference factor synthesis unit is used to synthesize the dust interference factor. The light interference factor The humidity interference factor Input a piecewise linear saturated function modeler to obtain the intensity of the environmental disturbance. ; The intensity of environmental interference It is only updated when the three-chain traceability module confirms that the influence is due to environmental factors.

5. The multi-source fire data fusion and fire situation analysis and monitoring system according to claim 4, characterized in that, The multi-factor fusion module also includes: Hysteresis logic control unit, used to handle the hysteresis logic when the raw data from the sensor in the i-th channel is affected by device health. or environmental disturbance intensity When protocol parsing is prohibited, monitor the i-th channel within the continuous observation time threshold. Internal stability; When the stability requirement is met, a recovery signal is output, which gradually restores the original data of the sensor in the i-th channel to the protocol parsing.

6. The multi-source fire data fusion and fire situation analysis and monitoring system according to claim 1, characterized in that, The degree of causal association C is defined as: in: This represents the change in the temperature signal relative to the reference value within the third preset time window. This represents the change in smoke concentration signal relative to a reference value within a preset time window. It is the minimum time difference between the temperature signal reaching the temperature threshold change point and the smoke signal reaching the smoke threshold change point.

7. The multi-source fire data fusion and fire situation analysis and monitoring system according to claim 1 or 6, characterized in that, The joint fire index J is defined as: in, This represents the change in the temperature signal relative to the reference value within the third preset time window. The change in smoke concentration signal relative to a reference value within the third preset time window; This represents the change in the carbon monoxide signal relative to a reference value within a third preset time window. This refers to the time interval required for the temperature signal to reach the temperature threshold change point within the third preset time window. This refers to the time interval required for the smoke signal to reach the smoke threshold change point within the third preset time window; This is the time interval required for the carbon monoxide signal to reach the carbon monoxide threshold change point within the third preset time window; , , These are weighting coefficients, and .

8. The multi-source fire data fusion and fire situation analysis and monitoring system according to claim 1, characterized in that, The three-chain traceability module includes: The data link management unit is used to store and retrieve data throughout the entire process; The device chain management unit is used to store and retrieve all data related to the health status of the device firmware; The operation chain management unit is used to store and recall manual or automatic control commands; Consistency verification unit, used in sliding time window Within the process, the three-chain cross-validation results and the fire situation determination results are subjected to a k-2 consistency check. If at least two chains are consistent, high-confidence tracing evidence is generated as the three-chain cross-validation results. Where k=3, This is the preset verification window duration.

9. The multi-source fire data fusion and fire situation analysis and monitoring system according to claim 8, characterized in that, The three-chain traceability module also includes a block generation unit, which is used to generate event digests. timestamp Judgment Summary Compared with the previous block hash Concatenate and calculate the hash value of the new block The calculation formula is: in, For cryptographic hash functions; This indicates a byte concatenation operation performed in a predetermined order.

10. The multi-source fire data fusion and fire situation analysis and monitoring system according to claim 1, characterized in that, The self-evolutionary optimization module includes: The performance monitoring unit is used to retrieve the fire situation determination results, three-chain cross-validation results, and standardized sensor data under the time slice index, and record the time required for the retrieval as the query latency. When the query latency meets the requirements... If the existing parameters are maintained, parameter recalibration will be triggered; among them, To reduce query latency, The number of samples; The parameter update unit is used to update the parsing rules and device health status when a recalibration is triggered. Environmental disturbance intensity The calculation parameters and the criterion thresholds for causal correlation degree C and joint fire index J are updated, and the updated calculation parameters are fed back to the dynamic protocol adaptive module and the multi-factor fusion module through shadow deployment and rollback mechanism to replace the original parameters and take effect in subsequent protocol parsing and fusion. The updated criterion thresholds are fed back to the causal and joint criterion module to replace the original criterion thresholds and take effect in subsequent criterion.

Images