Intelligent Fire Door Status Perception Control System and Method Based on Internet of Things Platform

Abstract

This invention discloses an intelligent fire door status perception control system and method based on an Internet of Things (IoT) platform, specifically relating to the field of IoT monitoring and control. It addresses the problems of existing fire doors only reporting open / closed status, lacking quantitative assessment of controllability, and being prone to issuing control commands to abnormal terminals. The system constructs basic door status records on a patrol bus through a monitoring controller, generates door-level heartbeat results within the patrol cycle, and forms door-level status identifiers on the IoT platform. During control execution, these door-level status identifiers serve as control access conditions, issuing control commands only to fire door terminals in a controllable state. Furthermore, within the control result analysis time window, the system calculates control response state matching parameters and heartbeat continuity stability parameters, inputting both into a pre-trained decision tree model to obtain controllability coefficients. Based on these controllability coefficients, the door-level status identifiers are dynamically adjusted, thereby achieving continuous assessment and reliable control of fire door controllability.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) monitoring and control, and more specifically, to an intelligent fire door status sensing control system and method based on an IoT platform. Background Technology

[0002] In large buildings and important locations, fire doors are typically connected to the fire control room via dedicated monitoring systems. Some solutions involve installing door sensors, image acquisition devices, and other front-end devices on the fire doors. These devices, transmitted via local controllers, upload the door's open / closed status and any abnormal openings to a management platform, enabling remote viewing and alarm notifications. A representative solution is the intelligent monitoring system for normally closed fire doors, which combines IoT technology and video recognition to display the door's basic status and any anomalies on the platform. On the other hand, some fire door monitoring systems employ a patrol-based bus communication method. The fire door monitor periodically polls each terminal to collect the operating status of each fire door, emphasizing the stability of local bus communication and the reliable acquisition of terminal status. As building fire protection systems increasingly integrate with IoT platforms, more and more engineering practices are connecting these patrol-based bus monitors to a unified platform via gateways. This allows the platform to centrally perceive the status of fire doors across multiple buildings and areas and to intelligently control and coordinate these systems, seemingly forming an integrated framework from front-end detection and on-site control to remote platform management.

[0003] However, existing solutions still suffer from a critical software-level technical problem: after introducing a patrol-type bus and gateway, the platform lacks detailed status management capabilities for individual fire doors. The platform typically only displays the online status of a single monitor and the current reported status of each fire door, but lacks a clear door-level state machine and heartbeat discrimination mechanism. It cannot accurately distinguish between a fire door failure and a broken branch connecting to that door based solely on limited key status variables, nor can it determine whether the door is currently in a safe controllable state. For systems aiming to achieve intelligent status perception and coordinated control, if the online and fault states of individual fire doors cannot be clearly distinguished at the control system level, the platform lacks reliable data when executing control strategies such as automatic door closing, prohibiting opening, and coordinating with other fire-fighting equipment. It can only rely on manual experience or conservative handling, making it difficult to truly leverage the advantages of IoT-based intelligent fire door status perception control systems and methods in unified monitoring and centralized control.

[0004] To address the aforementioned problems, a technical solution is provided. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide an intelligent fire door status perception control system and method based on an Internet of Things (IoT) platform. This system constructs basic door status records on an inspection bus through a monitoring controller, generates door-level heartbeat results within the inspection cycle, and forms door-level status identifiers on the IoT platform side. During control execution, the door-level status identifiers are used as control access conditions, and control commands are only issued to fire door terminals in a controllable state. Furthermore, within the control result analysis time window, control response state matching parameters and heartbeat continuity stability parameters are calculated. These parameters are input into a pre-trained decision tree model to obtain controllability coefficients. The door-level status identifiers are dynamically adjusted based on these controllability coefficients, thereby achieving continuous assessment and reliable control of fire door controllability, thus solving the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] A method for status sensing and control of intelligent fire doors based on an IoT platform includes the following steps:

[0008] S1, obtain the working status and terminal address of the fire door terminal through the inspection bus, and generate a basic door status record;

[0009] S2, within the inspection cycle, judges whether the door working status changes as expected based on the door basic status record, generates door-level heartbeat results and marks them as normal or abnormal.

[0010] S3, the door basic status record, door-level heartbeat result and monitoring controller online status are combined to form door status reporting data and sent to the IoT platform to generate door-level status identifier;

[0011] S4, when executing control, the IoT platform reads the door-level status identifier of the target fire door, and issues control commands when the door is in a controllable state;

[0012] S5. Within the control result analysis time window, based on the control command, record the gate basic state record and the gate-level heartbeat result record, obtain the control response state matching degree parameter and the heartbeat continuity stability parameter. Input the control response state matching degree parameter and the heartbeat continuity stability parameter into the pre-trained decision tree model to obtain the controllability coefficient. Adjust the gate-level state identifier corresponding to the terminal address identifier according to the relationship between the controllability coefficient and the threshold.

[0013] In a preferred embodiment, step S1 includes setting a preset terminal address list and maintaining an inspection cycle identifier, sending an inspection request message containing the inspection cycle identifier and the terminal address through the inspection bus, the fire door terminal returning a status response message containing the terminal address and working status and the inspection cycle identifier, and parsing the status response message to generate a basic door status record.

[0014] In a preferred embodiment, step S2 includes reading the door basic status record corresponding to the previous inspection cycle identifier and the current inspection cycle identifier according to the terminal address identifier; retrieving the most recent control instruction record between two inspection cycles according to the terminal address identifier; determining the expected working state and allowed transition state set of the current inspection cycle based on the working state and control instruction record of the previous inspection cycle; comparing the working state of the current inspection cycle with the allowed transition state set to generate a door-level heartbeat result record; and writing the terminal address identifier, inspection cycle identifier, and heartbeat flag field into the door-level heartbeat result record.

[0015] In a preferred embodiment, the logic for obtaining the allowed transition state set includes reading the reference working state from the gate basic state record of the previous inspection cycle and the target working state from the control instruction record; determining the standard transition path from the reference working state to the target working state in the state transition table; locating the current desired working state on the standard transition path according to the control instruction issuance time and the current inspection cycle; selecting a subset of states containing the current desired working state and its adjacent transition working states from the standard transition path to generate the allowed transition state set; and, when there is no control instruction record, using the reference working state of the previous inspection cycle to form the allowed transition state set separately.

[0016] In a preferred embodiment, step S3 includes generating an online status field for the monitoring controller, uploading door status reporting data to the IoT platform by using the terminal address identifier and the inspection cycle identifier to form door status reporting data, and generating and updating the door status identifier corresponding to the terminal address identifier by the IoT platform.

[0017] In a preferred embodiment, step S4 includes the IoT platform receiving a control request, parsing the control scenario identifier and target filtering conditions to generate a target terminal address identifier set, determining whether each terminal address identifier is in a controllable state according to the gate-level status identifier in the gate-level status identifier table, generating a control instruction record and sending a control instruction message for the controllable state, and generating an abnormal control record for the uncontrollable state.

[0018] In a preferred embodiment, the control response state matching degree parameter is obtained by constructing an ideal working state time series based on control command records and state transition tables within the control result analysis time window, and then extracting the actual working state time series from the gate basic state records. High-quality response positions that continuously advance towards the target working state encoding along the transition path without long-term stagnation or reverse fluctuations are identified. The proportion of the number of high-quality response positions to the total number of inspection positions within the window is used as the value of the control response state matching degree parameter.

[0019] In a preferred embodiment, the heartbeat continuity stability parameter is determined by obtaining the heartbeat marker time series sorted by inspection cycle from the gate-level heartbeat result record within the control result analysis time window, gradually shifting the time series with a sliding window of preset length, and comparing the proportion of abnormal heartbeat markers with the abnormal proportion threshold within each sliding window to determine stable and unstable windows, and using the proportion of stable windows to the total number of sliding windows as the heartbeat continuity stability parameter value.

[0020] In a preferred embodiment, based on the relationship between the controllability coefficient and the upper and lower thresholds, and combined with the control results, the actual working state in the gate basic state record at the end of the time window is analyzed to determine whether the target working state code has been reached. When the controllability coefficient is not lower than the upper threshold and the actual working state has reached the target working state code, the gate-level status identifier corresponding to the terminal address identifier is updated to a controllable state. When the controllability coefficient is not higher than the lower threshold or the actual working state has not reached the target working state code for a long time, the gate-level status identifier is updated to an uncontrollable state. When the controllability coefficient is between the upper and lower thresholds and the actual working state has reached the target working state code, the gate-level status identifier remains unchanged.

[0021] The intelligent fire door status sensing and control system based on the Internet of Things platform includes:

[0022] Inspection and filing module: Obtains the working status and terminal address of the fire door terminal through the inspection bus, and generates basic door status records;

[0023] Heartbeat determination module: During the inspection cycle, it determines whether the door's working status changes as expected based on the door's basic status record, generates door-level heartbeat results, and marks them as normal or abnormal.

[0024] Status reporting module: It sends the door status reporting data, consisting of the door basic status record, door-level heartbeat result and monitoring controller online status, to the IoT platform and generates a door-level status identifier;

[0025] Access control module: When executing control, the IoT platform reads the door-level status identifier of the target fire door and issues control commands when the door is in a controllable state;

[0026] Controllable evaluation module: Within the control result analysis time window, based on the control command, record the gate basic state record and gate-level heartbeat result record, calculate the control response state matching degree parameter and heartbeat continuity stability parameter, input the control response state matching degree parameter and heartbeat continuity stability parameter into the pre-trained decision tree model to obtain the controllability coefficient, and adjust the gate-level state identifier corresponding to the terminal address identifier according to the relationship between the controllability coefficient and the threshold.

[0027] The technical effects and advantages of the intelligent fire door status sensing control system and method based on the Internet of Things platform of this invention are as follows:

[0028] This invention connects basic door status records, door-level heartbeat results, door status reporting data, door-level status identifiers, and controllability coefficients into a complete data chain, enabling fire doors to operate in a closed loop under a unified logic from on-site inspection and platform sensing to control execution and result feedback. This allows fire door terminals with communication abnormalities or insufficient execution capabilities to be filtered out before remote control, significantly reducing the risk of linkage failure caused by erroneous command issuance.

[0029] Meanwhile, by introducing control response state matching parameters and heartbeat continuity stability parameters within the control result analysis time window, and then converting them into controllability coefficients through a pre-trained decision tree model and dynamically adjusting the door-level status identifier, the controllability of the fire door terminal is no longer based on a static judgment of a single inspection or report, but is gradually corrected over a long period of time based on multiple control behaviors. This improves the accuracy of the IoT platform in identifying the true controllable status of the fire door, which is beneficial for subsequent linkage strategies to control the fire door according to the degree of risk and for maintenance personnel to conduct targeted investigations of potential hazards. Attached Figure Description

[0030] Figure 1 This is a flowchart illustrating the intelligent fire door status sensing and control method based on an Internet of Things platform according to the present invention.

[0031] Figure 2 This is a schematic diagram of the intelligent fire door status perception and control system based on the Internet of Things platform of the present invention. Detailed Implementation

[0032] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0033] Example 1: Figure 1 The present invention provides a smart fire door status sensing and control method based on an Internet of Things platform, comprising:

[0034] S1, obtain the working status and terminal address of the fire door terminal through the inspection bus, and generate a basic door status record;

[0035] S2, within the inspection cycle, judges whether the door working status changes as expected based on the door basic status record, generates door-level heartbeat results and marks them as normal or abnormal.

[0036] S3, the door basic status record, door-level heartbeat result and monitoring controller online status are combined to form door status reporting data and sent to the IoT platform to generate door-level status identifier;

[0037] S4, when executing control, the IoT platform reads the door-level status identifier of the target fire door, and issues control commands when the door is in a controllable state;

[0038] S5. Within the control result analysis time window, based on the control command, record the gate basic state record and the gate-level heartbeat result record, obtain the control response state matching degree parameter and the heartbeat continuity stability parameter. Input the control response state matching degree parameter and the heartbeat continuity stability parameter into the pre-trained decision tree model to obtain the controllability coefficient. Adjust the gate-level state identifier corresponding to the terminal address identifier according to the relationship between the controllability coefficient and the threshold.

[0039] Although existing intelligent fire door monitoring solutions have deployed monitoring controllers and inspection buses, and can obtain fire door opening and closing information and fault information to a certain extent, they have initially established the hardware foundation for remote monitoring and control. However, this information often exists in the form of scattered messages and has not formed structured data that can be directly retrieved in both time and address dimensions. It also lacks a unified data entry point that can directly support door-level heartbeat result calculation and controllability assessment. However, subsequent steps require stable and reliable raw data as the basis for continuous analysis of the working status of a single fire door in different inspection cycles. Therefore, step S1 needs to transform the requests and responses on the bus into a set of door basic status records with fixed format and clear index through a complete inspection.

[0040] S1.1 Initialize the inspection cycle identifier and terminal address list.

[0041] Before being put into use, the monitoring controller has a pre-configured list of terminal addresses in its internal storage area. Each entry in the terminal address list corresponds to a fire door terminal, and the entry contains a terminal address identifier, which is used to uniquely identify the logical location of the fire door terminal in the inspection bus.

[0042] The monitoring controller internally maintains an inspection cycle counter. This counter employs an incrementing strategy, assigning an initial value during the first inspection and incrementing it at the start of each new inspection cycle. The current count value serves as the identifier for this inspection cycle and is written into all subsequent data structures related to this cycle. The inspection cycle identifier is only allowed to monotonically increase along the time direction to distinguish different inspection cycles and ensure a clear chronological order.

[0043] S1.2 Construction and transmission of inspection request message.

[0044] At the start of a new inspection cycle, the monitoring controller reads the terminal address list and constructs a corresponding inspection request message for each terminal address in the list. The inspection request message includes an inspection cycle identifier field, a terminal address field, and a message type field. The inspection cycle identifier field records the current inspection cycle identifier, the terminal address field records the terminal address identifier of the target fire door terminal, and the message type field indicates that the message is for inspection request purposes.

[0045] The monitoring controller sends the constructed inspection request messages sequentially via the inspection bus according to the terminal address list. When the fire door terminal receives the inspection request message on the inspection bus, it compares the terminal address field in the message with the locally stored terminal address identifier. If they match, it confirms that the message is used to request the current status information of the fire door terminal.

[0046] S1.3 Fire door terminal working status acquisition and status response message generation.

[0047] After confirming that the terminal address field of the inspection request message matches the local terminal address identifier, the fire door terminal reads the current operating status code from the local status register. The operating status code is represented by a discrete enumeration method to at least distinguish different operating states of the fire door, such as open, closed, and faulty.

[0048] The fire door terminal fills its local terminal address identifier into the terminal address field, its current operating status code into the operating status field, and writes the same inspection cycle identifier field as the inspection request message into the status response message, forming a complete status response message. The status response message is sent back to the monitoring controller via the inspection bus to provide feedback on the operating status of the fire door terminal within the current inspection cycle.

[0049] S1.4 Status Response Message Parsing and Validity Verification.

[0050] The monitoring controller sets a waiting time window for each sent inspection request during the current inspection cycle, and receives the returned status response messages from the inspection bus within the waiting time window. For each status response message, the monitoring controller first performs a message parsing operation, extracting the terminal address field, working status field, and inspection cycle identifier field, and checking whether all of these fields exist. Then, it performs a validity check operation, verifying whether the inspection cycle identifier field matches the current inspection cycle identifier, whether the terminal address field belongs to the set of valid terminal address identifiers in the terminal address list, and whether the working status field belongs to the predefined set of working status codes.

[0051] When all three fields exist and their values ​​are valid, the status response message is marked as a valid response. When fields are missing, values ​​are not in the valid set, or the inspection cycle identifier does not match, the status response message is marked as an invalid response, and an error log is recorded in the monitoring controller. The error log must include at least the terminal address identifier, the inspection cycle identifier, and a description of the error cause for subsequent diagnostic purposes. For fire door terminals marked as having invalid responses, the monitoring controller can re-initiate an inspection request in the next inspection cycle to complete the missing basic door status records.

[0052] S1.5 gate basic state record construction and composite index establishment.

[0053] For each status response message marked as a valid response in step S1.4, the monitoring controller constructs a basic door status record according to a unified structure. The basic door status record, as a single record entity, consists of four fields: terminal address field, operating status field, inspection cycle identifier field, and timestamp field. The terminal address field records the terminal address identifier obtained from parsing the status response message, used to identify the fire door terminal to which the record belongs; the operating status field records the operating status code obtained from parsing the status response message, used to indicate the operating status of the fire door terminal within the corresponding inspection cycle; the inspection cycle identifier field records the current inspection cycle identifier, used to indicate the time cycle of the record; and the timestamp field records the local time when the monitoring controller receives the status response message, used to precisely describe the time position in which the record was generated.

[0054] The monitoring controller constructs a combined index in its internal storage structure using terminal address identifiers and inspection cycle identifiers. The combination of these identifiers serves as the index key, while the basic door status records are stored as index values. This indexing method allows subsequent steps to accurately retrieve the basic door status records for any fire door terminal in any inspection cycle by specifying the terminal address identifier and inspection cycle identifier. This provides a stable data source for calculating door-level heartbeat results and control response status matching parameters.

[0055] After step S1 is completed, the monitoring controller has obtained a set of basic door status records covering all fire door terminals. Each record in this set is bound to the terminal address identifier in the address dimension, and is jointly identified by the inspection cycle identifier and timestamp field in the time dimension. The working status field gives the actual operating status of the fire door within the corresponding inspection cycle. Through this structured acquisition and storage process, the physical inspection communication results are transformed into a data foundation that can directly participate in logical judgment and control decision-making, providing complete and clear input conditions for subsequent door-level heartbeat result generation and controllability assessment steps.

[0056] In step S1, a basic door status record has been established for each terminal address identifier and each inspection cycle identifier, recording the working status of the fire door terminal in different time cycles. A joint index is used to achieve accurate retrieval by terminal address identifier and inspection cycle identifier. Although the basic door status record fully reflects the status information at the moment of a single inspection, for subsequent intelligent control based on the Internet of Things platform, it is necessary to determine at the control logic level whether the fire door responds to the control command between adjacent inspection cycles. It is also necessary to compress this response into a concise normal or abnormal result so as to generate the door-level status identifier and controllability coefficient. Step S2 is based on the above data, and by comparing the basic door status record and control command record of adjacent inspection cycles, a door-level heartbeat result corresponding to each terminal address identifier and each inspection cycle identifier is generated.

[0057] S2.1 Gate basic status record pairing and control command record retrieval.

[0058] In the initial stage of step S2, for each terminal address identifier in the terminal address list, the monitoring controller reads the door basic status record corresponding to the current inspection cycle identifier from its internal storage structure, and simultaneously reads the door basic status record corresponding to the previous inspection cycle identifier. If there is no door basic status record under the previous inspection cycle identifier, the monitoring controller selects the most recent door basic status record from the earlier inspection cycle identifier as the preceding working status record, so that each terminal address identifier has a historical working status record in the current inspection cycle.

[0059] The monitoring controller then accesses the control command record table, using the terminal address identifier as the search condition, to search for a control command record within the time interval between the previous inspection cycle identifier and the current inspection cycle identifier. If multiple control command records exist, the monitoring controller selects the control command record closest in time to the current inspection cycle identifier as the reference control behavior for this round of judgment, based on the order of command issuance time. This control command record contains a target operating status field and a command issuance time field. The monitoring controller combines the door basic status record from the previous inspection cycle, the door basic status record from the current inspection cycle, and the most recent control command record into a data set to describe the changes in operating status and control behavior of the same terminal address identifier within adjacent inspection cycles, providing a complete input background for subsequent calculation of the desired operating status and construction of the allowable transition state set.

[0060] S2.2 Generation of the expected working state and the set of allowed transition states.

[0061] After obtaining the basic door status records of the previous and current inspection cycles, as well as the most recent control command record, the monitoring controller needs to determine the desired operating state and the set of permissible transition states for each terminal address identifier at the time corresponding to the identifier in the current inspection cycle. The monitoring controller first reads the operating state field from the basic door status record of the previous inspection cycle, treating this operating state as the reference operating state. When a control command record exists, the monitoring controller reads the target operating state field from the control command record and then searches the internal state transition table for the standard transition path from the reference operating state to the target operating state. The standard transition path is a sequence of operating states arranged chronologically, used to describe the order of state changes in the ideal control process.

[0062] The monitoring controller locates the node corresponding to the current time position in the standard transition path based on the time interval between the control command issuance time and the time corresponding to the current inspection cycle identifier. The operating state of this node is defined as the expected operating state for the current inspection cycle. A set of operating states surrounding this node is selected in the standard transition path to form a set of permissible transition states. This set includes the expected operating state and several transitional operating states considered reasonable during control actions, such as briefly maintaining the reference operating state or briefly being in an intermediate state feedback. When there is no control command record between the previous and current inspection cycle identifiers, the monitoring controller directly designates the reference operating state as the expected operating state and constructs a set of permissible transition states containing only this expected operating state.

[0063] Through the above processing, each terminal address identifier has a clear expected working state and a set of allowed transition states corresponding to time and location in the current inspection cycle, providing clear judgment conditions for subsequent comparisons.

[0064] S2.3 Gate-level heartbeat result determination and record generation.

[0065] After the expected working state and the set of allowed transition states are generated, the monitoring controller reads the current working state code from the door basic state record of the current inspection cycle for each terminal address identifier, and then compares the current working state code with the expected working state and the set of allowed transition states obtained in the previous step.

[0066] If the current working status code is completely consistent with the expected working status, or if the current working status code belongs to any working status in the set of allowed transitional states, the monitoring controller will recognize the response result of this round as a normal response and generate a gate-level heartbeat result record for the current inspection cycle. The gate-level heartbeat result record includes the terminal address identifier, the current inspection cycle identifier, and the heartbeat flag field. The heartbeat flag field is set to normal.

[0067] If the current operating status code is neither equal to the expected operating status nor included in the set of allowed transitional states, the monitoring controller will classify the response result of this round as an abnormal response and generate a gate-level heartbeat result record. This record includes the terminal address identifier, the current inspection cycle identifier, and a heartbeat flag field indicating an abnormal value. The monitoring controller uses the same indexing rules as the gate-level basic status record when storing the gate-level heartbeat result record, using the terminal address identifier and inspection cycle identifier as the retrieval key. This links the gate-level heartbeat result record with the corresponding gate-level basic status record, allowing subsequent steps to access both operating status information and heartbeat result information simultaneously through the same index.

[0068] After step S2 is completed, for each combination of terminal address identifier and each inspection cycle identifier, there exists a door-level heartbeat result record corresponding to the door's basic status record. The door-level heartbeat result record, through a heartbeat marker field, comprehensively reflects the degree of matching between the reference working state, control commands, and the current working state in a normal or abnormal form, compressing the complex state evolution process into a Boolean conclusion that can be directly used for subsequent judgment. Subsequently, when generating door-level status identifiers and calculating controllability coefficients, the IoT platform can directly read the heartbeat marker field from the door-level heartbeat result record to quickly identify whether the fire door responded as expected according to the control strategy within a certain inspection cycle. Simultaneously, it further analyzes the response process by combining the door's basic status record and control command record, thus establishing the fire door's controllability assessment on a clear and traceable state comparison link.

[0069] In steps S1 and S2, basic door status records and door-level heartbeat result records indexed by terminal address identifiers and inspection cycle identifiers have been established on the monitoring controller side. These two types of records fully present the local operation status of the fire door terminal from the time and response dimensions. The IoT platform has not yet directly grasped this information and still lacks a status transmission link from on-site recording to platform judgment. However, subsequent steps require the IoT platform to generate door-level status identifiers based on the reporting data in a unified format, using the door-level status identifiers as a prerequisite for automatic control. Therefore, step S3 constructs door status reporting data based on the online status field of the monitoring controller, basic door status records, and door-level heartbeat result records, uploads it to the IoT platform through the communication channel, and then generates door-level status identifiers that correspond one-to-one with the terminal address identifiers within the IoT platform, providing direct input for subsequent control steps.

[0070] S3.1 Monitoring controller online status field acquisition and locking.

[0071] When the door status reporting process is initiated in the current inspection cycle, it is necessary to first determine whether the monitoring controller itself is in a state capable of reliably performing inspections and sending and receiving data. The monitoring controller reads the processor's operating status, storage resource read / write status, and handshake results with the IoT platform communication link through its internal operation monitoring logic, inputting the results of these checks into the operation monitoring logic for unified evaluation. The operation monitoring logic outputs a single conclusion: an "online" conclusion indicates that the monitoring controller meets the computational and communication requirements in the current inspection cycle; an "offline" conclusion indicates that the monitoring controller has computational or communication anomalies in the current inspection cycle. Based on this, the monitoring controller generates an "online status" field, writes the conclusion into this field, and references the same "online status" field in all door status reporting data within this inspection cycle, achieving a single determination for multiple uses and ensuring consistency between the door status reporting data and the monitoring controller's operating status.

[0072] S3.2 Gate Status Reporting Data Record Construction.

[0073] After the monitoring controller's online status field is locked, it enters the door status reporting data construction phase. For each terminal address identifier in the terminal address list, the monitoring controller reads the door basic status record corresponding to the current inspection cycle identifier from the door basic status record set in step S1, and reads the door-level heartbeat result record corresponding to the current inspection cycle identifier from the door-level heartbeat result record set in step S2. The two records are paired using the terminal address identifier and the inspection cycle identifier. Based on the pairing result, the monitoring controller constructs a door status reporting data record, setting six items in the record structure: terminal address field, inspection cycle identifier field, working status field, heartbeat flag field, monitoring controller online status field, and timestamp field. The terminal address field is directly taken from the terminal address field in the door basic status record; the inspection cycle identifier field is taken from the inspection cycle identifier field in the door basic status record; the working status field is taken from the working status field in the door basic status record; the heartbeat flag field is taken from the heartbeat flag field in the door-level heartbeat result record; the monitoring controller online status field is taken from the single monitoring controller online status field generated in step S3.1; and the timestamp field is taken from the timestamp field in the door basic status record. The monitoring controller performs one round of traversal on the terminal address list, constructing a door status reporting data record for each terminal address identifier, forming a door status reporting data set corresponding to the current inspection cycle.

[0074] S3.3 gate status reporting data is sent and parsed and stored in the IoT platform.

[0075] After completing the construction of the status reporting data records for all departments within the current inspection cycle, the monitoring controller encapsulates these door status reporting data records into a batch of upload units and sends them to the IoT platform via wired or wireless communication links according to the preset reporting cycle. A reliable transmission protocol with an acknowledgment handshake mechanism is used during transmission to prevent data loss during the upload process.

[0076] The IoT platform parses each uploaded unit according to a predefined message format at the receiving end. For each door status report data record, it extracts the terminal address field, inspection cycle identifier field, working status field, heartbeat flag field, monitoring controller online status field, and timestamp field, and writes these fields into the device status cache structure within the IoT platform. The device status cache structure uses the terminal address identifier and inspection cycle identifier as retrieval keys. Accessing the corresponding door status report data record through the key values ​​provides the original source for subsequent generation of door-level status identifiers. During the parsing process, the IoT platform records the upload time information and compares it with the timestamp field for subsequent diagnosis of communication latency.

[0077] S3.4 Gate-level status identifier generation and update storage.

[0078] After parsing and storing the door status reporting data, the IoT platform performs door-level status identifier generation for each door status reporting data record under the latest inspection cycle identifier in the device status cache structure. The IoT platform reads the online status field and heartbeat flag field of the monitoring controller from the door status reporting data record. When the online status field of the monitoring controller is "online" and the heartbeat flag field is "normal," the door-level status identifier for the corresponding terminal address is set to a controllable state. When the online status field of the monitoring controller is "offline" or the heartbeat flag field is "abnormal," the door-level status identifier for the corresponding terminal address is set to an uncontrollable state.

[0079] The IoT platform internally maintains a gate-level status identifier table. Each row uses the terminal address identifier as an index to store a gate-level status identifier corresponding to the latest inspection cycle. For the same terminal address identifier's gate status reporting data in different inspection cycles, the IoT platform recalculates the gate-level status identifier each time based on the new round of gate status reporting data, and overwrites the original record in the gate-level status identifier table with the new result, thus ensuring that the gate-level status identifier table always reflects the judgment result of the current inspection cycle. Subsequent automatic control steps, when deciding whether to issue a control command to the target terminal address identifier, read the corresponding gate-level status identifier from the gate-level status identifier table, and only execute the control command issuance when the gate-level status identifier is in a controllable state.

[0080] After step S3 is completed, the basic door status record and door-level heartbeat result record generated by the monitoring controller have been completely transmitted to the IoT platform through the door status reporting data. The IoT platform stores the door status reporting data indexed by terminal address identifier and inspection cycle identifier in the device status cache structure, and generates a door-level status identifier for the current inspection cycle for each terminal address identifier in the door-level status identifier table. The door-level status identifier summarizes the controllable and uncontrollable status results through the online status field and heartbeat flag field of the monitoring controller. This allows subsequent automatic control steps to filter out target fire door terminals with remote control conditions simply by referencing the door-level status identifier when dealing with a large number of fire doors, improving the response efficiency and stability of the IoT platform at the status judgment and control decision level.

[0081] In steps S1 and S2, a basic door status record and a door-level heartbeat result record indexed by the terminal address identifier and the inspection cycle identifier have been formed. In step S3, the IoT platform has generated a door-level status identifier from the door status reporting data and written it into the door-level status identifier table. At this time, the IoT platform has the ability to identify the current controllable or uncontrollable state of each terminal address identifier. However, if the control process does not explicitly reference the door-level status identifier when performing automatic control or linkage control, it is difficult to restrict the control command to only act on the fire door terminal in the controllable state from the source. Step S4 constructs a control link constrained by the door-level status identifier around the control request, the door-level status identifier table and the control command record table, so that each control action is filtered for controllable state before reaching the fire door terminal.

[0082] S4.1 Control request reception and target terminal address identifier set are formed.

[0083] When an automatic control scenario or a linkage control scenario is triggered, the IoT platform receives a control request from the higher-level control logic. The control request includes a control scenario identifier and target filtering conditions. The control scenario identifier is used to indicate the scenario type to which this control belongs, and the target filtering conditions are used to limit the range of fire doors involved in the control, such as using building number, floor number, area number, or functional zone as filtering attributes.

[0084] The IoT platform first reads the target operating status code from the control scenario configuration table based on the control scenario identifier. The target operating status code indicates the operating status that the fire door should achieve under the current control scenario, such as being kept closed or unlocked. Subsequently, the IoT platform performs a query operation in the device file table, using the target filtering conditions as the query criteria, and selects all terminal address identifiers whose attributes meet the target filtering conditions from the device file table, forming a set of target terminal address identifiers.

[0085] The IoT platform registers a control task record for each terminal address identifier in the target terminal address identifier set. The control task record contains the terminal address identifier, control scenario identifier, target working status code, and control request generation time. The control task record serves as the basic input for subsequent determination of whether to generate a control instruction record.

[0086] S4.2 Generation and message distribution of control command records based on gate-level status identifiers.

[0087] Given a defined set of target terminal address identifiers, the IoT platform reads the current gate-level status identifier from the gate-level status identifier table for each terminal address identifier in the set. The IoT platform then determines the gate-level status identifier; if it is in a controllable state, it generates a control command record for the corresponding terminal address identifier. This record includes the terminal address identifier, target operating status code, control scenario identifier, and control command generation time, and is assigned a unique control command identifier. After the control command record is written to the control command record table, the IoT platform constructs a control command message based on the record. This message contains at least three fields: terminal address identifier, target operating status, and control command identifier, and is sent via the communication link with the monitoring controller.

[0088] After receiving the control command message, the monitoring controller locates the target fire door terminal based on the terminal address identifier field in the message and sends a front-end control command to the corresponding fire door terminal, causing the local control device of the fire door terminal to adjust its status according to the target working status code. The control command log table stores the core information of all issued control commands. Subsequent steps, when analyzing the door basic status record and door-level heartbeat result record, can establish a correspondence between the control command identifier and the specific control behavior.

[0089] S4.3 An abnormal control record is generated corresponding to the terminal address identifier of the uncontrollable state.

[0090] When the IoT platform processes the target terminal address identifier set sequentially, whenever a terminal address identifier with an uncontrollable gate status is read from the gate status identifier table, the IoT platform does not generate a control command record or construct a control command message. Instead, it creates a new abnormal control record in the abnormal control record table. The abnormal control record contains the terminal address identifier, the current gate status identifier, the control scenario identifier, and the abnormal record time. It can also read the online status field and heartbeat flag field of the monitoring controller from the most recent gate status reporting data record and write them into the abnormal control record to explain that the uncontrollable state is caused by the monitoring controller being offline or an abnormal gate-level heartbeat result.

[0091] The abnormal control log serves as a record of the reasons for control failures, allowing maintenance personnel to distinguish between fire door terminals that normally participate in control and those that did not participate in control due to their door status being marked as uncontrollable when reviewing control execution results.

[0092] After processing the target terminal address identifier set, the IoT platform can compare the number of abnormal control records with the number of control task records to count the number of fire doors that failed to execute control commands due to uncontrollable conditions in this control request, providing data support for subsequent maintenance work.

[0093] In step S4, the IoT platform introduces gate-level status identifier constraints into the control decision-making chain. This narrows the target terminal address identifier set from the coarse-grained range passed from the upper-level control logic to a controllable target set filtered based on the gate-level status identifiers. Control command records are generated and sent only to terminal address identifiers with a controllable gate-level status identifier. For terminal address identifiers with an uncontrollable gate-level status identifier, an abnormal control record is generated without sending any control command messages. In this way, the automatic control and linkage control process forms a clear path on the platform side from the control scenario identifier, target working state code, gate-level status identifier to control command record. This reduces the risk of applying control actions to fire door terminals with communication anomalies or malfunctions, and provides complete and traceable control behavior input for calculating the control response state matching degree parameters based on the control command record and the basic door status record in step S5.

[0094] In steps S1 to S4, the entire process of acquiring data from inspections, generating basic door status records and door-level heartbeat result records, forming door-level status identifiers on the IoT platform, and using these identifiers to constrain the issuance of control commands has been completed. The IoT platform can determine whether the fire door is in a controllable state before control is implemented. However, the actual operational performance after the control command is executed has not yet been quantified and absorbed into the subsequent judgment logic. The door-level status identifiers remain relatively static and lack a dynamic correction mechanism based on time-series feedback. Step S5, based on the control command records, basic door status records, and door-level heartbeat result records, quantifies the state changes and heartbeat stability within the control result analysis time window, generating control response state matching parameters and heartbeat continuity stability parameters. Then, a controllability coefficient is output through a pre-trained decision tree model, and the controllability coefficient is used to drive the update of the door-level status identifier, enabling the IoT platform to base its assessment of the fire door's controllability on long-term control performance.

[0095] S5.1 Determination of the time window for control result analysis and processing of sequence data.

[0096] After the control command is issued from the IoT platform through the monitoring controller, an analysis interval covering the entire control action process needs to be defined for the target terminal address identifier for subsequent parameter calculation.

[0097] The IoT platform first reads the control command identifier, target terminal address identifier, target working status code, and control command generation time corresponding to this control from the control command record table. Then, based on the position of the control command generation time on the inspection time axis, it determines the control start inspection cycle identifier.

[0098] The IoT platform derives the control termination inspection cycle identifier by extrapolating from the preset control observation duration. The start and end inspection cycle identifiers together constitute the control result analysis time window. For each control command event, the IoT platform, based on the target terminal address identifier, retrieves the door basic status record set in the order of the inspection cycle identifier within the control result analysis time window. It then combines the working status field and timestamp field corresponding to each inspection cycle identifier into an actual working status time series in chronological order. Simultaneously, it retrieves the door-level heartbeat result record set, assembling the heartbeat marker field into a heartbeat marker time series in the order of the inspection cycle identifier. This data, along with the target working status code and the control start inspection cycle identifier from the control command record, is packaged into a set of control result analysis data, providing complete input for the calculation of the two parameters.

[0099] S5.2 Obtain the control response state matching degree parameter.

[0100] After the control command is sent from the IoT platform to the monitoring controller and then transferred to the target terminal address identifier by the monitoring controller, the basic status record of the door continuously reflects the evolution of the working status of the fire door within the control result analysis time window. If the working status is only viewed once at the end of the window, only a static conclusion can be obtained as to whether the target working status code has been reached. It is impossible to distinguish whether the intermediate stage is continuously advancing towards the target, or whether it is stagnant for a long time, or whether there are multiple reverse changes.

[0101] In scenarios such as fire-linked door closure and evacuation route adjustments, every small step forward or backward during the control process affects the overall safety assessment. Therefore, it is necessary to re-examine the basic door status records from a time series perspective, divide the control result analysis time window into a series of evolution segments constrained by the state transition table, identify which segments demonstrate stable progress toward the target working state, and which segments only exhibit mechanical lag or repeated fluctuations, screen out the high-quality response positions that truly represent the effective execution process, and construct the control response state matching degree parameter using the coverage of this type of position throughout the entire time period. This allows the parameter to move beyond a simple distinction between success and failure, and instead characterize whether the direction of a control event is clear and the pace of progress is stable throughout the entire process.

[0102] During the calculation of the control response state matching degree parameter, the IoT platform first constructs an ideal working state time series for the target terminal address identifier in the state transition table based on the target working state code in the control command record and the reference working state at the start of the control result analysis time window. At each inspection cycle position, the corresponding ideal working state and allowable transition state set are given.

[0103] Subsequently, the IoT platform reads the working status fields in the basic status record of the door in chronological order within the control result analysis time window to form the actual working status time series. It then determines whether the actual working status is moving towards the target working status on the transition path defined in the status transition table, remaining in the same state, or deviating from the transition path and changing in the opposite direction between two adjacent inspection cycle positions.

[0104] The IoT platform marks segments in the time series that show a unidirectional advancement toward the target working state as advancing segments, segments that remain unchanged over multiple adjacent inspection cycles or recover from the edge of the allowed transition state set as hysteresis segments, and segments that leave the transition path or change in a direction away from the target working state as reversing segments.

[0105] Based on this, the IoT platform removes all inspection positions that fall into sluggish sections and all inspection positions adjacent to reverse sections from the advancement section. The remaining inspection positions are considered high-quality response positions. High-quality response positions demonstrate that the state continues to advance along the transition path without being contaminated by prolonged stagnation or reverse changes. The control response state matching degree parameter is taken as the ratio between the number of high-quality response positions and the total number of inspection positions within the control result analysis time window. The more high-quality response positions there are, the closer the control response state matching degree parameter is to one, indicating that the state advancement behavior is stable and continuous during this control process. Conversely, it indicates that there are frequent stagnation or reverse fluctuations during the state advancement process.

[0106] S5.3 Obtain the heartbeat continuity stability parameters.

[0107] In an environment where the inspection bus operates cyclically, gate-level heartbeat records not only indicate whether communication was successful at a single point in time, but also implicitly address the long-term stability of the communication link within the control result analysis time window. If only the number of abnormal heartbeats is counted, the distribution of abnormalities with the same total number may correspond to completely different risk patterns. Short-term, scattered abnormalities often do not have a serious impact on overall controllability, while long-term, continuous abnormalities may mean a complete loss of feedback capability at critical stages. Therefore, it is necessary to examine heartbeat behavior from the perspective of local time slices. The control result analysis time window is divided into a series of continuous small-scale sliding windows according to the inspection cycle. By examining the proportion of abnormal heartbeats within each sliding window, it is possible to identify which time slices maintain a relatively normal heartbeat and which time slices experience concentrated outbreaks of abnormalities. The coverage ratio of the stable window in all sliding windows is then used to construct a heartbeat continuity stability parameter. This parameter reflects whether abnormal heartbeats occur locally and briefly or exist in patches over a longer period of time, thus providing a more detailed temporal structure description for communication and feedback quality in controllability assessment.

[0108] During the calculation of the heartbeat continuous stability parameter, the IoT platform obtains the heartbeat tag field in the gate-level heartbeat result record according to the inspection cycle identifier in the order of the target terminal address identifier within the control result analysis time window, forming a heartbeat tag time series composed of normal tags and abnormal tags.

[0109] The IoT platform selects a sliding window length determined based on engineering experience and slides it across the heartbeat marker time series with the inspection cycle as the step size. Within each sliding window, it calculates the ratio between the number of inspection locations marked as abnormal and the total number of inspection locations within the sliding window. This ratio is compared with a preset abnormality percentage threshold. When the abnormality percentage of a certain sliding window is lower than the abnormality percentage threshold, the sliding window is marked as a stable window. When the abnormality percentage is higher than the abnormality percentage threshold, the sliding window is marked as an unstable window.

[0110] The sliding process covers all inspection positions within the control result analysis time window. Adjacent sliding windows shift according to one inspection cycle, ensuring that each inspection position is included in different sliding windows for evaluation multiple times. This reflects both the concentration of heartbeat anomalies in local time and the overall stability at the end of the control result analysis time window. The heartbeat continuity stability parameter is the ratio between the number of windows identified as stable during the sliding process and the total number of sliding windows. A higher stable window coverage ratio results in a heartbeat continuity stability parameter closer to one, indicating that heartbeat anomalies occur only briefly in a few local segments without forming long-term continuous interruptions. A lower stable window coverage ratio results in a heartbeat continuity stability parameter closer to zero, indicating the existence of long or multiple densely packed abnormal heartbeat intervals within the control result analysis time window, insufficient continuity of communication links and status feedback, and a substantial impact on the reliability of the control results.

[0111] S5.4 Acquisition of controllability coefficients and dynamic updating of gate-level status indicators.

[0112] Within the control result analysis time window, the control response state matching degree parameter and the heartbeat continuity stability parameter have been calculated from the perspectives of state execution and heartbeat feedback, respectively. In order for the IoT platform to form a quantitative conclusion on the long-term controllability of the target terminal address identifier, it is necessary to map these two parameters into a single controllability coefficient through a pre-trained decision tree model, and adjust the gate-level state identifier according to the controllability coefficient, so that the gate-level state identifier no longer stays at the static judgment level, but is dynamically updated with the cumulative performance of multiple control events.

[0113] During the pre-training phase, the IoT platform continuously collects historical control event samples during long-term operation. For each historical control event, the control response state matching degree parameter and heartbeat continuity stability parameter are calculated according to the logic described in step S5, forming a pair of feature values. The platform also retrieves whether the control event was ultimately deemed successful and controllable from the engineering operation and maintenance records, using this as a binary label. The IoT platform aggregates a large number of such feature-labeled records to form a training sample set. Then, a decision tree classification method is used to grow a pre-trained decision tree model starting from the root node. At the root node and each internal node, the control response state matching degree parameter or heartbeat continuity stability parameter is used as the splitting feature. The Gini index or information gain ratio is calculated at different threshold positions. The feature and threshold that most significantly improves the purity of the sample label are selected as the splitting condition for the current node, and the sample is divided into left and right child nodes according to the threshold. The tree structure expands recursively from top to bottom until the number of samples in a node drops to a pre-set minimum number of samples, or the label height in the node is consistent, or the tree depth reaches a pre-set maximum depth. At this point, a complete but potentially complex initial decision tree is obtained. Subsequently, the IoT platform introduces a validation set separate from the training set. Starting from the bottom of the tree, pruning is performed. For a given internal node, its left and right subtrees are temporarily merged into a single leaf node. The prediction result of the leaf node is determined by the statistical analysis of the labels of all training samples for that internal node. The classification performance before and after pruning is then evaluated on the validation set. If the accuracy and stability of the validation set do not decrease or even slightly improve after pruning, the pruning result is retained; otherwise, the original subtree structure is restored. Through this bottom-up repetitive operation, branches with limited contribution to validation performance are gradually removed, ultimately resulting in a pre-trained decision tree model with a suitable structure and good generalization ability. After pruning, for each leaf node, the IoT platform calculates the number of successfully controllable samples and the total number of samples in the training samples contained within the leaf node. The ratio of these two values ​​is stored in the leaf node as its controllability coefficient, providing a fixed output for the online phase.

[0114] During the threshold setting phase, the IoT platform extracts all samples labeled as successful and controllable from the training sample set. The controllability coefficient outputs of these samples in the pre-trained decision tree model are collected into a distribution sequence. The controllability coefficient value corresponding to the high quantile position is selected as the upper threshold to identify highly reliable controllable events. Simultaneously, all samples labeled as failed and uncontrollable are extracted, and the controllability coefficient outputs of these samples are collected into another distribution sequence. The controllability coefficient value corresponding to the low quantile position is selected as the lower threshold to identify obviously uncontrollable events. In this way, the upper and lower thresholds are derived from the statistical characteristics of actual operational data and are directly related to the on-site requirements for success rate and safety margin, rather than being arbitrarily specified constants.

[0115] During the online operation phase, each time the IoT platform completes parameter calculations within a control result analysis time window, obtaining the control response state matching degree parameter and heartbeat continuity stability parameter for a specific control event, it constructs an input vector containing two dimensions of features. The control response state matching degree parameter is used as the first dimension, and the heartbeat continuity stability parameter as the second dimension, which is then input into the pre-trained decision tree model. Upon receiving this input, the pre-trained decision tree model starts from the root node and compares the value of the corresponding feature in the input vector with the threshold value based on the partition feature name and threshold configured for the current node. If the feature value is less than or equal to the threshold, it continues down the left child node; if the feature value is greater than the threshold, it continues down the right child node, repeating this process until a leaf node is reached. The IoT platform reads the pre-stored controllability coefficient from this leaf node and considers this controllability coefficient as the statistically significant overall controllability level of the current control event.

[0116] After obtaining the controllability coefficient, the IoT platform needs to map this continuous value back to discrete gate-level state identifiers. The IoT platform first reads the target terminal address identifier and target operating state code corresponding to the current control event from the control command record table, and simultaneously reads the actual operating state of the target terminal address identifier from the gate basic state record at the end of the control result analysis time window. Then, the IoT platform compares the controllability coefficient with the upper and lower thresholds. If the controllability coefficient is not lower than the upper threshold, and the actual operating state at the end of the control result analysis time window is equal to the target operating state code, the gate-level state identifier of the target terminal address identifier is updated to a controllable state in the gate-level state identifier table. This indicates that the target terminal address identifier exhibits high-matching state execution and highly stable heartbeat feedback in the current control event, making it suitable for continuous participation in automatic or linkage control. If the controllability coefficient is not higher than the lower threshold, or if the control response state matching parameter remains at a low level in multiple consecutive control events and the actual working state of the target terminal address identifier fails to reach the target working state code for an extended period, the IoT platform updates the gate-level status identifier in the gate-level status identifier table to an uncontrollable state. This indicates that the target terminal address identifier is no longer suitable for receiving automatic control commands in the current environment and requires manual maintenance by operations and maintenance personnel. For cases where the controllability coefficient falls between the upper and lower thresholds and the actual working state has reached the target working state code, the IoT platform maintains the original gate-level status identifier in the gate-level status identifier table unchanged. This conservative strategy avoids frequent state changes due to a single instance of the behavior falling within an ambiguous range.

[0117] During the aforementioned update process, the IoT platform can also maintain a control failure count for each terminal address identifier in the data structure corresponding to the gate-level status identifier table. Each time a control event is deemed uncontrollable or the control response state matching parameter is extremely low, the control failure count is incremented. When the control failure count exceeds a threshold set based on engineering experience, even if a subsequent control event achieves a controllability coefficient slightly higher than the lower threshold, the gate-level status identifier is not immediately restored to a controllable state. Instead, restoration is only considered after multiple consecutive control events show good performance. This introduces hysteresis protection during the dynamic adjustment of the gate-level status identifier, reducing the control risk caused by frequent fluctuations. Through this series of processes, the controllability coefficient output by the pre-trained decision tree model is no longer just a single analysis result, but continuously influences the control access conditions at the gate-level status identifier level. This allows the IoT platform to determine the controllability of the fire door terminal based on long-term statistical data and current execution results.

[0118] Through step S5, the IoT platform no longer treats the door-level status identifier as a single inspection conclusion. Instead, it expands each control event into a control result analysis time window. Within this time window, control response state matching parameters and heartbeat continuity stability parameters are extracted from the door's basic status record and door-level heartbeat result record. Then, a pre-trained decision tree model is used to generate controllability coefficients. Based on these controllability coefficients, the door-level status identifier is dynamically updated, ensuring that the door-level status identifier takes into account both single control results and long-term control performance. The control response state matching parameter focuses on whether the working state time series changes according to the ideal trajectory, while the heartbeat continuity stability parameter focuses on whether the communication feedback remains continuous and stable over time. The controllability coefficient condenses these two into a single quantitative indicator. The door-level status identifier gradually converges to actual controllability through multiple rounds of control and feedback, thus enabling the entire fire door status perception and control method to possess self-correction capabilities and long-term operational adaptability at the IoT platform level.

[0119] Example 2: Figure 2 The present invention discloses an intelligent fire door status sensing and control system based on an Internet of Things platform, comprising:

[0120] Inspection and filing module: Obtains the working status and terminal address of the fire door terminal through the inspection bus, and generates basic door status records.

[0121] Heartbeat determination module: During the inspection cycle, it determines whether the door's working status changes as expected based on the door's basic status record, generates door-level heartbeat results, and marks them as normal or abnormal.

[0122] Status reporting module: It sends the door status reporting data, consisting of the door's basic status record, door-level heartbeat result, and online status of the monitoring controller, to the IoT platform and generates a door-level status identifier.

[0123] Access control module: When executing control, the IoT platform reads the door-level status identifier of the target fire door and issues control commands when the door is in a controllable state.

[0124] Controllable evaluation module: Within the control result analysis time window, based on the control command, record the gate basic state record and gate-level heartbeat result record, calculate the control response state matching degree parameter and heartbeat continuity stability parameter, input the control response state matching degree parameter and heartbeat continuity stability parameter into the pre-trained decision tree model to obtain the controllability coefficient, and adjust the gate-level state identifier corresponding to the terminal address identifier according to the relationship between the controllability coefficient and the threshold.

[0125] Specifically, the above description is only a preferred embodiment of this application and is not intended to limit this application.

[0126] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0127] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to any specific implementation. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A method for intelligent fire door state sensing control based on an Internet of Things platform, characterized in that, The method comprises the steps of: S1, obtaining the working state and terminal address of the fireproof door terminal through the inspection bus, and generating a door basic state record; S2, determining whether the door working state changes as expected according to the door basic state record in the inspection period, generating a door-level heartbeat result and marking it as normal or abnormal; Step S2 includes reading the door basic state record corresponding to the terminal address identification and the previous inspection period identification and the current inspection period identification, searching the latest control instruction record between the two inspection periods according to the terminal address identification, determining the expected working state and the allowed transition state set of the current inspection period according to the working state of the previous inspection period and the control instruction record, comparing the working state of the current inspection period with the allowed transition state set to generate a door-level heartbeat result record, and writing the terminal address identification, inspection period identification and heartbeat mark field in the door-level heartbeat result record; the allowed transition state set acquisition logic includes reading the reference working state in the previous inspection period door basic state record and the target working state in the control instruction record, determining the standard transition path from the reference working state to the target working state in the state transition table, locating the current expected working state on the standard transition path according to the control instruction issue time and the current inspection period, and selecting a state subset containing the current expected working state and its adjacent transition working state from the standard transition path to generate the allowed transition state set; when there is no control instruction record, the reference working state of the previous inspection period alone constitutes the allowed transition state set; S3, sending the door state reporting data composed of the door basic state record, the door-level heartbeat result and the monitoring controller online state to the Internet of Things platform to generate a door-level state identification; S4, the Internet of Things platform reads the door-level state identification of the target fireproof door when executing control, and issues a control instruction when the state is controllable; S5, according to the control instruction record, the door basic state record and the door-level heartbeat result record, the control response state matching degree parameter and the heartbeat continuous stability parameter are calculated in the control result analysis time window, the control response state matching degree parameter and the heartbeat continuous stability parameter are input into the pre-trained decision tree model to obtain the controllability coefficient, and the controllability coefficient is adjusted according to the threshold relationship to adjust the door-level state identification corresponding to the terminal address identification.

2. The intelligent fireproof door state perception control method based on the Internet of Things platform according to claim 1, wherein: Step S1 includes pre-setting a terminal address list and maintaining an inspection period identification, sending an inspection request message containing the inspection period identification and the terminal address through the inspection bus according to the terminal address, and returning a state response message containing the terminal address and the working state and attached with the inspection period identification by the fireproof door terminal, and analyzing the state response message to generate a door basic state record.

3. The intelligent fireproof door state perception control method based on the Internet of Things platform according to claim 2, wherein: Step S3 includes generating a monitoring controller online state field, uploading the door state reporting data composed of the door basic state record and the door-level heartbeat result record to the Internet of Things platform through the terminal address identification and the inspection period identification, and generating and updating the door-level state identification corresponding to the terminal address identification by the Internet of Things platform.

4. The intelligent fire door state perception control method based on the Internet of Things platform according to claim 3, characterized in that: Step S4 includes that the Internet of Things platform receives the control request, analyzes the control scene identification and target screening condition, generates a target terminal address identification set, judges whether each terminal address identification is in a controllable state according to the door level state identification in the door level state identification table, generates a control instruction record and issues a control instruction message for the controllable state, and generates an abnormal control record for the uncontrollable state.

5. The intelligent fire door state perception control method based on the Internet of Things platform according to claim 4, characterized in that: The control response state matching degree parameter is constructed by constructing an ideal working state time sequence according to the control instruction record and the state transition table within the control result analysis time window, and then extracting an actual working state time sequence from the door basic state record, identifying a high-quality response position where the state continuously advances along the transition path towards the target working state code and does not appear long-term stagnation and reverse fluctuation, and taking the proportion of the number of high-quality response positions to the number of all inspection positions in the window as the numerical value of the control response state matching degree parameter.

6. The intelligent fire door state perception control method based on the Internet of Things platform according to claim 5, characterized in that: The heart beat continuous stability parameter is obtained by obtaining a heart beat mark time sequence sorted by the inspection cycle from the door level heart beat result record within the control result analysis time window, and then gradually shifting a sliding window of a preset length on the time sequence and comparing the proportion of abnormal heart beat marks in each sliding window with an abnormal proportion threshold to determine stable windows and unstable windows, and taking the proportion of the number of stable windows to the number of all sliding windows as the numerical value of the heart beat continuous stability parameter.

7. The intelligent fire door state perception control method based on the Internet of Things platform according to claim 6, characterized in that: According to the relationship between the controllability coefficient and the upper threshold and the lower threshold, and in combination with whether the actual working state in the door basic state record at the end of the control result analysis time window reaches the target working state code, when the controllability coefficient is not lower than the upper threshold and the actual working state reaches the target working state code, the door level state identification corresponding to the terminal address identification is updated to the controllable state, when the controllability coefficient is not higher than the lower threshold or the actual working state does not reach the target working state code for a long time, the door level state identification is updated to the uncontrollable state, and when the controllability coefficient is between the upper threshold and the lower threshold and the actual working state reaches the target working state code, the door level state identification remains unchanged.

8. The intelligent fire door state sensing control system based on the Internet of Things platform, for implementing the intelligent fire door state sensing control method based on the Internet of Things platform according to any one of claims 1-7, characterized in that, It includes: An inspection filing module: obtains the fire door terminal working state and terminal address through the inspection bus, and generates a door basic state record; A heart beat determination module: judges whether the door working state changes as expected according to the door basic state record within the inspection cycle, generates a door level heart beat result and marks it as normal or abnormal; A state reporting module: sends the door basic state record, the door level heart beat result and the monitoring controller online state to the Internet of Things platform to generate a door level state identification; A control access module: the Internet of Things platform reads the door level state identification of the target fire door when executing control, and issues a control instruction for the controllable state. Controllable evaluation module: record gate basic state according to control instruction in control result analysis time window, record gate level heartbeat result, record control response state matching degree parameter and heartbeat continuous stability parameter, input control response state matching degree parameter and heartbeat continuous stability parameter into pre-training decision tree model to obtain controllability coefficient, and adjust gate level state identification corresponding to terminal address identification according to threshold relationship of controllability coefficient.

Images