Intelligent property comprehensive management method and system

Abstract

The application relates to a smart property comprehensive management method and system, and relates to the technical field of smart community management. The method comprises the following steps: acquiring real-time original data streams of each subsystem in a property scene, performing standardized conversion and timestamp alignment to generate fusion data snapshots; extracting an abnormal feature vector based on the snapshots and determining an event priority label to generate a hierarchical result; searching for matching rules in a cross-system rule engine and generating a linkage instruction set containing an execution time sequence; sequentially issuing instructions and receiving execution receipts; comparing the receipts with preset completion conditions, and if the conditions are not met, triggering a compensation instruction to re-execute until a closed loop is formed. The application can realize real-time collaborative linkage and closed-loop management among multiple subsystems, and improve the response speed and disposal accuracy of property safety events.

Description

Technical Field

[0001] This application belongs to the field of smart community management technology, specifically a smart property comprehensive management and control method and system. Background Technology

[0002] Currently, in the field of smart property management, business segments such as security monitoring, access control, energy dispatching, and equipment maintenance are typically managed using independent subsystems. While each subsystem has relatively complete internal functions, the lack of a unified data exchange channel and collaborative linkage mechanism leads to widespread information barriers between systems. When emergencies occur in a property setting, the subsystems cannot establish real-time information sharing and collaborative response capabilities, a problem particularly prominent in emergency response scenarios. For example, when a security system detects unauthorized entry into the community, the access control system cannot simultaneously obtain this information and automatically take restrictive measures, and the video surveillance system cannot immediately adjust its monitoring focus for targeted tracking. Property staff must switch back and forth between multiple operating interfaces to complete the coordinated operation. This information isolation between systems stretches what should be a multi-system collaborative response within seconds to several minutes or even longer, resulting in low efficiency in cross-system collaborative response and severely limiting the emergency response capabilities and resource allocation rationality of property management.

[0003] More complicated by the fact that different subsystems operate within their own business logic frameworks, lacking a unified rule engine to define triggering conditions and execution actions between systems, property managers find it difficult to quickly build automated cross-system processing workflows even when they recognize the need for multi-system collaboration. Due to the lack of a unified data fusion and event classification mechanism, alarms and status information generated by each subsystem are fragmented, failing to create a global situational awareness and making it difficult for managers to make accurate decisions when facing concurrent or related events.

[0004] Therefore, the key issue in improving the overall management and control efficiency of smart property is how to break down information barriers between subsystems, establish a basic channel to support real-time data exchange among multiple business segments, and build a collaborative mechanism that can automatically trigger cross-system linkage operations based on business scenarios, so that security, energy, equipment, services and other management and control links can form a closed-loop response link. Summary of the Invention

[0005] To address the above issues, this application provides a smart property management integrated control method and system to solve the technical problems of delayed abnormal response, difficulty in cross-system collaboration, and uncontrollable and unverifiable linkage links caused by information silos in various property subsystems.

[0006] To achieve the above objectives, the technical solution adopted in this application is as follows:

[0007] The first aspect of this application provides a smart property integrated management and control method, the method comprising: acquiring real-time raw data streams of various subsystems in a property scenario; standardizing and aligning the real-time raw data streams with timestamps; merging them to generate a fused data snapshot; extracting anomaly feature vectors based on the fused data snapshots; determining priority labels for events based on the anomaly feature vectors; generating event classification results carrying category labels and priority labels; retrieving triggering rules matching the event classification results in a pre-established cross-system rule engine; activating the triggering rules if matching rules exist; generating a linkage instruction set containing target subsystem identifiers, action types, and execution sequences; parsing the linkage instruction set; issuing action instructions to each target subsystem according to the parsed target subsystem identifiers and action types, and receiving execution receipts from each target subsystem; comparing the execution receipts with preset completion conditions; determining that the linkage response link is closed and complete if the execution receipts of all target subsystems meet the preset completion conditions; and triggering compensation instructions and re-executing them until the closed-loop conditions are met if there are target subsystems that do not meet the preset completion conditions.

[0008] The second aspect of this application provides a smart property integrated management and control system, the system comprising: a data fusion module configured to acquire real-time raw data streams from various subsystems in a property scenario, perform standardization transformation and timestamp alignment on the real-time raw data streams, and merge them to generate a fused data snapshot; an event classification module configured to extract abnormal feature vectors based on the fused data snapshot, determine the priority labels of events according to the abnormal feature vectors, and generate an event classification result carrying category labels and priority labels; and a rule matching and instruction generation module configured to retrieve triggering rules matching the event classification result from a pre-established cross-system rule engine; if a matching triggering rule exists, it is activated. The triggering rule generates a set of linkage instructions containing target subsystem identifiers, action types, and execution sequences. The instruction issuance and receipt receiving module is configured to parse the linkage instruction set, issue action instructions to each target subsystem according to the parsed target subsystem identifier and action type, and receive execution receipts from each target subsystem. The closed-loop verification and compensation module is configured to compare the execution receipts with preset completion conditions. If the execution receipts of all target subsystems meet the preset completion conditions, the linkage response link is determined to be closed and complete. If there is a target subsystem that does not meet the preset completion conditions, a compensation instruction is triggered and re-executed until the closed-loop conditions are met.

[0009] This application provides a smart property management integrated control method and system. The solution acquires real-time raw data streams from various subsystems within a property scenario, performs standardization and timestamp alignment, and merges them to generate a fused data snapshot. This eliminates format differences and temporal discrepancies between multi-source heterogeneous data, providing a unified data foundation for subsequent analysis. Based on the fused data snapshot, anomaly feature vectors are extracted, and combined with equipment status and environmental parameters to construct a comprehensive anomaly feature vector input to an event classification model. Then, based on the attribution probability and regional weight coefficient, event priority labels are determined, generating event classification results carrying category and priority labels. This makes risk identification more accurate and adaptable to different scenarios. The system first retrieves trigger rules matching the event classification results from a pre-established cross-system rule engine. Activating these rules generates a set of linkage instructions containing target subsystem identifiers, action types, and execution sequences. This decouples business logic from execution actions and orchestrates the responses of multiple systems. Next, the linkage instruction set is parsed, and action instructions are sent to each target subsystem according to the execution sequence. Execution receipts are received and compared with preset completion conditions. If all target subsystem execution receipts meet the preset completion conditions, the linkage response chain is considered complete. If any target subsystem fails to meet the conditions, a compensation instruction is triggered and re-executed until the closed-loop conditions are met. This effectively solves the problems of delayed linkage responses, low collaboration efficiency, and lack of closed-loop verification mechanisms caused by information silos in traditional property management systems. It avoids delays and errors caused by manual intervention and improves the reliability, consistency, and automation level of property security incident handling. Attached Figure Description

[0010] Figure 1 A flowchart of a smart property management and control method provided in this application;

[0011] Figure 2 A flowchart illustrating the acquisition and fusion of multi-source real-time raw data streams in the smart property integrated management and control method provided in this application;

[0012] Figure 3 A flowchart illustrating the cross-system field completion process in the intelligent property integrated management and control method provided in this application;

[0013] Figure 4 A flowchart illustrating the extraction of abnormal feature vectors based on visual analysis in the intelligent property management and control method provided in this application;

[0014] Figure 5 A flowchart illustrating the process of determining event priority labels and generating hierarchical results in the intelligent property management and control method provided in this application;

[0015] Figure 6 A flowchart illustrating the process of retrieving and matching triggering rules and generating a set of linkage instructions in the smart property integrated management and control method provided in this application;

[0016] Figure 7 A flowchart illustrating the parsing of linkage instruction sets and the issuance of execution receipts in the intelligent property integrated management and control method provided in this application;

[0017] Figure 8 A flowchart illustrating the complete closure of the comparison execution receipt determination linkage response link in the smart property integrated management and control method provided in this application;

[0018] Figure 9 A flowchart illustrating the process of triggering compensation instructions until the closed-loop conditions are met in the smart property integrated management and control method provided in this application;

[0019] Figure 10 A block diagram of a smart property management system provided in this application. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solution, the present application will be described in detail below with reference to the embodiments. The description in this section is only exemplary and explanatory, and should not be used to limit the scope of protection of the present application in any way.

[0021] This application provides a smart property management and control method, the overall technical solution of which is shown in the embodiments of this application. The method mainly covers the following core technical aspects: standardized processing and fusion of real-time raw data streams, event classification based on abnormal feature vectors, matching and linkage instruction generation via cross-system rule engines, time-sequential execution of instructions and receipt reception, and a closed-loop verification and compensation mechanism based on receipt comparison. These aspects work together to constitute the overall technical solution of this application, aiming to solve the technical problems of data heterogeneity, information silos, and delayed linkage response among existing property management subsystems, and to achieve real-time collaboration and closed-loop management and control across systems.

[0022] like Figure 1 The diagram shown is a flowchart of a smart property management and control method according to an embodiment of this application. The method includes:

[0023] Step S101: Obtain the real-time raw data streams of each subsystem in the property scenario, perform standardized transformation and timestamp alignment on the real-time raw data streams, and merge them to generate a fused data snapshot.

[0024] In practical applications, subsystems in property management scenarios typically include, but are not limited to, various types such as security monitoring, access control, energy metering, environmental monitoring, and equipment operation and maintenance. These subsystems often employ different communication protocols and data formats. This step eliminates heterogeneous differences through a unified data access layer and aggregates discrete multi-source data under a unified time benchmark. The fused data snapshot is not merely a simple collection of data, but a unified spatiotemporal benchmark for all subsequent intelligent decisions. By encapsulating multi-dimensional information such as video streams, status bits, and metering values ​​within the same data structure, the system can examine the current scene status from a global perspective, effectively avoiding misjudgments caused by incomplete or misaligned data from a single subsystem, and providing a high-quality data foundation for subsequent anomaly detection.

[0025] Specifically, such as Figure 2 The diagram shown is a flowchart illustrating the acquisition and fusion of multi-source real-time raw data streams in a smart property integrated management and control method provided in this application embodiment. The method specifically includes:

[0026] Step S201: Obtain the raw data streams carrying device identifiers and timestamps reported by security cameras, access controllers, energy metering devices and equipment sensors. Parse the data packets according to the access protocol type of each raw data stream, extract the device status parameters and business data fields carried by each protocol, and obtain the initial data set.

[0027] Establish communication links with various underlying hardware devices in the property management scenario to receive raw data streams reported in real time from security cameras, access controllers, energy metering devices, and equipment sensors. These raw data streams represent the operational status of different physical subsystems and are high-frequency heterogeneous signal sequences. The device identifiers and timestamps carried within them constitute key index information for subsequent data tracing and time-series alignment. Specifically, the data streams from security cameras include video frames or captured images, the data streams from access controllers include card swipe records and switch status bits, energy metering devices report voltage, current, and power values, and equipment sensors report analog quantities such as temperature, humidity, or operating speed.

[0028] Subsystems typically employ various heterogeneous communication protocols. For example, security cameras may use ONVIF (Open Network Video Interface Forum) or RTSP (Real Time Streaming Protocol) to transmit video streams and metadata. Access controllers and energy metering devices often use Modbus TCP (Modbus Transmission Control Protocol) or BACnet (Building Automation and Control Networks) to transmit register values, while environmental monitoring sensors may use MQTT (Message Queuing Telemetry Transport) or CoAP (Constrained Application Protocol) to report JSON-formatted data. Because different protocols have significantly different data packet encapsulation structures, encoding methods, and field definitions, directly mixing them will lead to parsing errors. This step involves constructing a unified data access layer with built-in protocol parsing adapters to decapsulate raw data in different formats, such as binary streams, XML (eXtensible Markup Language) messages, or JSON objects. It extracts atomic data items containing unique device identifiers, acquisition timestamps, and specific business values ​​(such as switch status, temperature, current, voltage, and video frame data), forming an initial data set. This process eliminates the heterogeneity of the underlying communication protocols, providing a standardized data input interface for upper-layer applications.

[0029] Step S202: Based on the preset field mapping relationship table, perform a unified conversion of field names for device identifiers, measurement values ​​and status flags of different protocol types in the initial data set, retain records with missing fields or abnormal markers, and add missing markers to them to obtain an intermediate data set with consistent field structure.

[0030] Different manufacturers, and even different models from the same manufacturer, often use inconsistent naming conventions for fields representing the same physical quantity. For example, a field representing ambient temperature might be named "temp," "temperature," "wendu," or "reg_40001." This application pre-constructs a field mapping table covering mainstream equipment types. This table is determined as follows: during system initialization, for each subsystem and equipment type involved in the property scenario, a set of original field names used by each subsystem is collected. Different original field names corresponding to the same physical quantity are mapped to standard field names within the same system, forming key-value pair mapping entries. The same standard field name corresponds to multiple original field names. For newly added equipment types or uncovered fields, the field mapping table supports dynamic expansion via a rule editor, and newly added mapping entries take effect immediately after import.

[0031] Based on this field mapping table, all non-standard field names are uniformly converted into standard internal field names (e.g., "env_temperature"). Simultaneously, records with missing key fields or values ​​exceeding reasonable ranges (e.g., temperature value -999) discovered during parsing are not discarded directly; instead, they are retained and marked with "MISSING" or "INVALID" in the corresponding field. This approach ensures both the uniformity of the data structure and the preservation of explicit information regarding data integrity issues, preventing subsequent algorithms from making incorrect inferences due to silent data loss. The resulting intermediate dataset presents a wide table structure at the logical level, with each row representing an event record at a given moment and each column representing a standardized semantic dimension, thus providing a solid structured input foundation for cross-system data fusion.

[0032] Step S203: Based on the timestamp and transmission frequency attributes of each record in the intermediate data set, the data of different reporting periods are time-series aligned using the time window alignment method to obtain an aligned data set with a unified time base.

[0033] The sampling frequencies of various subsystems in a property management system differ significantly. For example, video streams typically run at 25 or 30 frames per second, access control card swipe events are triggered discretely at the millisecond level, while temperature and humidity sensors may only report data once every 5 minutes. Directly splicing these data together would lead to severe timing misalignment. This embodiment employs a sliding time window alignment mechanism, setting a uniform time granularity (e.g., 100 milliseconds) as the alignment baseline window. For high-frequency data (such as video), keyframes are selected or statistical features are calculated within this window. Optionally, statistical features include any one of the mean, median, maximum, minimum, or standard deviation of the data within the window. The specific statistical feature selected is pre-configured based on the data characteristics of the corresponding field type. For low-frequency data (such as sensor data), linear interpolation or nearest neighbor filling algorithms are used to map it to the current window. For discrete events (such as access control), they are precisely placed into the corresponding time slots.

[0034] Furthermore, the system synchronizes all subsystem clocks to millisecond-level precision via the NTP protocol, ensuring the comparability of timestamps. This step transforms the previously unevenly distributed multi-source data along the timeline into a unified, aligned data set with a consistent time base, enabling the complete representation of the scene state at any given moment by a set of synchronized data slices.

[0035] Step S204: Merge the security video stream frame sequence, access control status bit sequence, energy metering value sequence and equipment operation parameter sequence in the alignment data set into the same data structure according to the timestamp, and generate a fused data snapshot.

[0036] Based on the aligned data set obtained from the above steps, the final data merging operation is performed. Specifically, the security video stream frame sequence, access control status bit sequence, energy meter value sequence, and equipment operating parameter sequence in the aligned data set are associated using timestamps as the primary key and merged into the same data structure. This same data structure can be a JSON object, an XML document, a database record row, or a custom binary data block. In this structure, each row of data corresponds to a unique timestamp, and the columns of that row contain complete information on all relevant dimensions within the property scenario at that time.

[0037] In the specific merging and mapping process, the security video stream frame sequence typically stores the video frame's storage address URL, feature vector encoding, or keyframe index; the access control status bit sequence stores the door's open / closed and locked status in binary or enumerated value form; the energy metering value sequence stores floating-point power and electricity values; and the equipment operating parameter sequence stores continuous quantities or discrete states such as temperature, pressure, and speed.

[0038] The fused data snapshot is the smallest data unit for all subsequent intelligent analyses in this application. It encapsulates comprehensive perceptual information from multiple dimensions, including vision, physical access, energy consumption, and environment, at the same moment, constructing a digital twin image that reflects the global state at a given moment. This highly structured data organization breaks the fragmented model of independent storage and on-demand querying of data in traditional solutions, enabling anomaly detection algorithms to comprehensively analyze multi-dimensional clues within the same spatiotemporal context, significantly improving the accuracy and robustness of perception.

[0039] Furthermore, as a preferred implementation, after merging and generating the fused data snapshot, a cross-system field completion process is also included. In actual operation, due to network jitter, equipment failure, or sensor blind spots, some fields are inevitably missing in the fused data snapshot. Simply filling missing values ​​with zero or null values ​​can easily lead to misjudgments. For example, filling a missing temperature value with zero will trigger an anti-freeze alarm, and filling a missing power value with zero will be mistakenly interpreted as a power outage. Therefore, this embodiment designs a differentiated completion strategy based on semantic understanding. Specifically, as follows... Figure 3 As shown, it includes:

[0040] Step S301: Determine whether all fields in the data structure of the fused data snapshot have been filled with valid values; if there are empty field values, mark the field as a field to be filled, and obtain a candidate fused data snapshot with the field to be filled.

[0041] After obtaining the fused data snapshot generated in the previous step, the system first performs an integrity check to determine whether all fields in the data structure have been filled with valid values. If any field has an empty value (e.g., due to device offline, communication packet loss, or protocol mismatch, resulting in a NULL or undefined value), the field is marked as a field to be completed, thus obtaining a candidate fused data snapshot with the field to be completed annotation.

[0042] This field to be completed not only identifies the location of missing data, but also characterizes the availability status of the data in the current time slice and its potential impact on the overall data association, serving as the index basis for subsequent execution of differentiated repair strategies.

[0043] Step S302: Based on the subsystem type and field semantics of each field to be completed in the candidate fused data snapshot, retrieve the filling strategy corresponding to the field from the preset default filling rule library. If the field belongs to the status bit type field, fill it with the preset previous valid status value as the default value; if the field belongs to the measurement value or operation parameter type field, fill it with the historical average value of the field in the preset sliding window as the default value; if the field belongs to the cross-system related field, fill it with the missing field by reverse association inference based on the actual perception data of other subsystems in the current time window, and obtain a complete fused data snapshot with all fields valid.

[0044] In practical applications, different data types have different physical laws and spatiotemporal correlations, therefore a one-size-fits-all approach to completion is not suitable. This application pre-defines three core completion strategies:

[0045] The first strategy applies to status bit type fields. If the field is a status bit type (such as access control switch, valve start / stop, alarm trigger flag, etc.), the preset previous valid status value is used as the default value. This is because the status of physical devices is time-continuous; the status usually remains unchanged without new control commands or external triggers. Using the valid value from the previous moment is more consistent with physical reality than filling in zero or a random value, and can effectively avoid false alarms caused by instantaneous packet loss due to status jumps.

[0046] The second strategy applies to fields of measurement value or operating parameter type. If the field is a measurement value or operating parameter type (such as continuously changing quantities like temperature, humidity, voltage, and speed), the historical average value of the field within a preset sliding window is used as the default value. The duration of the preset sliding window is dynamically adjusted based on the data sampling frequency and fluctuation characteristics. For example, for slowly changing ambient temperature data, the window can be set to 10 minutes; for power load data with large fluctuations, the window can be set to 1 minute. This type of data usually has a certain inertia and smoothing characteristics. Using the historical average value within the sliding window to fill the window can maintain the continuity of the data while filtering out single-point abnormal noise, thus better restoring the true trend of the parameter.

[0047] The third strategy applies to cross-system related fields. If the field is a cross-system related field (such as personnel ID, region code, or other contextual information), then the missing field is inferred and completed by reverse correlation based on the actual perceived data of other subsystems within the current time window, resulting in a complete and fused data snapshot with all fields effectively completed. This is the most innovative completion method in this embodiment, making full use of the redundancy and complementarity of multi-source data.

[0048] In terms of specific algorithm implementation, the reverse association inference and completion adopts a "spatiotemporal feature alignment and multimodal confidence fusion" mechanism. First, the system extracts the spatiotemporal anchor point (i.e., the timestamp and spatial coordinates / device ID of the event) of the record containing the missing field, and retrieves adjacent node data with strong correlation to the anchor point in a preset cross-system knowledge graph. Second, the spatiotemporal similarity weight of the candidate related data is calculated: in the time dimension, a Gaussian decay function is used to evaluate the proximity of the timestamp, and in the spatial dimension, a spatial decay coefficient is calculated based on topological distance or physical coordinates. Finally, the original confidence of the candidate data is multiplied by the spatiotemporal similarity weight, and the highest score data with a product exceeding a preset threshold is selected as the inference result for backfilling. For example, when an access control card swipe record lacks an employee ID field, the system uses the timestamp of the swipe event and the access control ID as anchors to retrieve face recognition results from video streams within the same time window (e.g., ±2 seconds) and the same physical space. If the product of the recognition confidence (e.g., 0.92) and the current spatiotemporal similarity weight (e.g., 0.95) is greater than a set threshold, the matched employee ID is backfilled into the access control record. Similarly, when a meter reading lacks a region code, the system queries a pre-set topology table based on the meter's device ID, or uses the region codes of other normally reporting devices within the same distribution cabinet, combined with a spatial attenuation coefficient, to perform mode inference. This reverse inference mechanism not only repairs missing data but also strengthens the logical connections between subsystems, making the completed fused data snapshot semantically more complete and reliable.

[0049] It should be understood that the above three completion strategies are merely illustrative examples. In practical applications, other strategies such as time series prediction completion based on machine learning and interpolation completion based on spatial proximity can also be introduced according to specific business scenarios. As long as the purpose of repairing missing data based on the semantic differences of fields can be achieved, they all fall within the protection scope of this application.

[0050] Step S102: Based on the fused data snapshot, extract the abnormal feature vector, determine the priority label of the event according to the abnormal feature vector, and generate the event classification result carrying the category label and priority label.

[0051] Extracting anomalous feature vectors based on fused data snapshots refers to identifying characteristic indicators that deviate from normal operating modes from a global state view and combining them into a multi-dimensional vector to represent abnormal states. The extraction process can be implemented using a pre-defined rule-based filtering algorithm or a machine learning model. In rule-based filtering mode, the system compares data items in the fused data snapshot with a pre-defined threshold range (e.g., elevator operating current exceeding 1.2 times the rated value, or fire smoke detection concentration exceeding a specific threshold), extracting anomalous data points exceeding the threshold and their associated attributes (e.g., location, duration, and magnitude of change) as components of the feature vector. In machine learning mode, the fused data snapshot can be input into a pre-trained isolated forest or autoencoder model, and anomalous feature vectors can be extracted by calculating reconstruction error or anomaly scores.

[0052] Optionally, the extraction of abnormal feature vectors adopts a combination of preset rule filtering and machine learning. The rule filtering identifies explicit anomalies based on threshold comparison logic, while the machine learning model identifies implicit anomalies based on reconstruction error.

[0053] Determining the priority label of an event based on its anomaly feature vector can refer to classifying events into levels according to the severity, scope of impact, and urgency of the anomaly features. The priority label setting is based on a multi-dimensional weighted scoring algorithm, which comprehensively considers factors such as anomaly type (e.g., fire is the highest level, illegal intrusion is medium level, equipment failure is low level), affected area (e.g., public areas are higher than private areas), number of devices involved, and potential risks. The system calculates a comprehensive score for the anomaly feature vector according to a preset weight configuration and maps the score to the corresponding priority label. Priority labels can be set to four levels: urgent, high, medium, and low, or use a numerical level (e.g., Level 1 to Level 4, with lower numbers indicating higher priority).

[0054] Event classification results are structured event description records carrying category and priority labels. Their generation process involves encapsulating extracted anomaly feature vectors with determined priority labels. The data format of the event classification results includes a unique event identifier, occurrence time, a list of associated subsystems, anomaly feature vector content, and priority labels. By generating event classification results with category and priority labels, the system can achieve differentiated resource scheduling.

[0055] In one alternative embodiment, such as Figure 4 The diagram shown is a flowchart of a method for extracting abnormal feature vectors based on visual analysis, provided in an embodiment of this application. The method specifically includes:

[0056] Step S401: Based on the video frame sequence in the fused data snapshot, a preset visual analysis model is used to extract spatiotemporal features from the continuous frames to obtain a trajectory feature sequence.

[0057] The visual analysis model here does not refer to a specific neural network architecture, but rather to a collection of algorithms capable of extracting motion information from temporal image data. For example, 3D convolutional neural networks (such as 3D-ResNet and SlowFast) can be used to directly extract features in the spatiotemporal dimension; optical flow estimation networks (such as PWC-Net and RAFT) can be used to calculate the pixel displacement field between adjacent frames, encode the horizontal and vertical displacement amplitudes into a dual-channel heatmap, and then concatenate it with the RGB feature map in the channel dimension to form a fused feature tensor; in addition, a Transformer-based temporal modeling architecture can be used to capture long-distance motion dependencies.

[0058] In a preferred implementation, the visual analysis model can perform stereo scanning on a normalized video frame sequence using an internally integrated 3D convolutional kernel and residual connection module. The convolutional kernel slides within a time window to extract the pixel displacement field between adjacent frames. When the target object moves in the scene, the response center point in the feature map is calculated by the post-processing module, thereby solving for the time-varying region coordinates (such as x, y pixel coordinates based on the image origin) and motion direction vectors (such as a two-dimensional vector containing horizontal and vertical velocity components).

[0059] Regardless of the specific model used, the core objective is to transform unstructured video pixel streams into structured trajectory feature sequences that contain the movement path and motion trends of the target object in physical space. This transformation allows subsequent anomaly detection to no longer rely on repeated processing of the original pixels, but rather on analysis based on highly abstract motion semantics, significantly reducing computational redundancy and improving the system's real-time response capability.

[0060] Step S402: Determine whether the spatial location code in the trajectory feature sequence falls within the preset area intrusion boundary range. If it does, assign an intrusion area activation mark to the spatial location code that falls within the preset area intrusion boundary range, and combine the spatial location codes with activation marks to generate a frame-level feature set with intrusion area activation marks.

[0061] This step is the key innovation that distinguishes this application from traditional purely visual behavior recognition solutions. Traditional anomaly detection often only focuses on "what a person is doing," ignoring the crucial context of "where a person is doing it." This leads to normal walking in legal areas (such as public corridors) being misjudged as intrusion, or minor anomalies in sensitive areas (such as restricted areas in server rooms) being missed. This embodiment achieves a deep integration of algorithm logic and business scenarios by explicitly embedding the spatial constraints of the physical world into the feature extraction process.

[0062] In practice, the region intrusion boundary can be a polygonal region pre-marked in the camera's field of view (e.g., a geometric structure composed of a set of ordered two-dimensional coordinate points), or a dynamic mask generated in real time by a semantic segmentation model. When the coordinate points in the trajectory features are determined to be inside the boundary by geometric algorithms such as ray casting or mask indexing, the system will place an activation signal in the corresponding feature channel or a specific marker bit (e.g., write a binary marker 0 / 1 into a specified channel of the feature map, or merge it as a key-value pair with the coordinate points in chronological order).

[0063] It is important to emphasize that this intrusion area activation marker is not merely a simple Boolean flag; it is directly injected into the subsequent classification network as strong prior information. This forces the model to consider spatial legitimacy when calculating behavior confidence, thereby significantly reducing false alarms caused by scene irrelevance. Through this mechanism, the system can automatically filter out key segments involving sensitive areas from continuous motion trajectories, transforming ordinary trajectories without specific locational meaning into frame-level feature data with security semantics, providing a focused object for subsequent refined analysis.

[0064] Step S403: Based on the frame-level feature set with intrusion region activation markers, extract the human body structure features of the target object to obtain the body posture recognition vector.

[0065] While trajectory features alone can reflect macroscopic motion, they are insufficient to distinguish subtle differences in movements with similar postures (such as "squatting down to tie shoelaces" versus "crouching to dodge"). Therefore, this step introduces the perception of fine-grained structures of the human body.

[0066] Specifically, lightweight pose estimation subnets (such as HRNet and OpenPose) can be used to perform heatmap regression on human keypoints (such as 17 keypoints including the head, shoulders, elbows, knees, and ankles). After obtaining the coordinates of the keypoints, the relative angles between the keypoints (such as the angle between the upper arm and forearm), limb extension ratios, and skeletal topological features are further calculated. Subsequently, these geometric features are encoded and compressed through fully connected layers or global average pooling layers to generate fixed-dimensional numerical vectors (such as 128-dimensional or 256-dimensional floating-point arrays), which are the posture recognition vectors.

[0067] It should be understood that the generation of posture recognition vectors is not limited to keypoint detection. In other embodiments, a mesh-based Skinned Multi-Person Linear model (SMPL) can be used to directly extract body shape and 3D pose parameters, or the contour features of instance segmentation masks can be used as posture representations. Crucially, this vector provides complementary information describing individual morphological changes independently of global motion, effectively overcoming interference from lighting variations and occlusion, thus laying a solid feature foundation for accurately distinguishing complex behaviors.

[0068] Step S404: Input the body posture recognition vector and trajectory feature sequence into the behavior classification network, output the confidence value corresponding to each behavior category, and mark the behavior category with a confidence value higher than the preset confidence threshold as a valid behavior category, and generate an abnormal feature vector containing spatial location encoding and valid behavior category.

[0069] Specifically, behavior classification networks typically consist of an input fusion layer, a temporal modeling layer (such as an RNN (Recurrent Neural Network), LSTM (Long Short-Term Memory), or an attention mechanism module), and a fully connected classification layer. Their role is to deeply fuse and reason about the aforementioned macroscopic trajectory features, spatial constraint labels, and microscopic body features. This network is trained on a large-scale behavior recognition dataset containing video samples with behavior labels. Weights are updated using a cross-entropy loss function and backpropagation algorithm to learn the semantic associations of multimodal features. During the inference phase, the network's output layer, after Softmax normalization, outputs a probability distribution vector. The values ​​in this vector reflect the model's confidence that the current segment belongs to a predefined behavior category (such as normal walking, area intrusion, a person falling, climbing, fighting, etc.).

[0070] It is important to emphasize that the preset confidence threshold in this embodiment is not a uniform fixed value for all behavior categories, but rather is configured differently based on the risk level and historical false alarm rate of each behavior. Specifically, the determination method includes: plotting Precision-Recall curves for each category by collecting historical test data, and finding the optimal balance between false positive and false negative rates in conjunction with the tolerance of the business scenario. For example, for high-frequency, low-risk behaviors such as "normal walking," a higher threshold (e.g., 0.85) can be set to avoid frequent alarm triggering; while for high-risk behaviors such as "person falling" or "area intrusion," the threshold is appropriately lowered (e.g., 0.68 or 0.72) to improve recall, adhering to the principle of "better to have a false alarm than a false negative." Only when the confidence level of a category exceeds its specific threshold will it be marked as a valid behavior category.

[0071] The resulting anomaly feature vector is a composite data structure that not only contains the confirmed valid behavior category labels but also retains the original spatial location encoding information. This design enables the downstream event classification module to not only know "what happened" but also precisely "where it happened," providing complete and self-consistent data support for subsequent priority determination based on regional weights.

[0072] In yet another embodiment, such as Figure 5The diagram shown is a flowchart illustrating a method for determining event priority labels and generating hierarchical results according to an embodiment of this application. The method specifically includes:

[0073] Step S501: Obtain the equipment status parameters and environmental operation parameters of each subsystem in the current property scenario, and construct a multi-dimensional comprehensive anomaly feature vector by combining the anomaly feature vector.

[0074] The anomaly feature vectors generated in the preceding steps primarily focus on visual behavioral and trajectory representations. However, in complex property scenarios, visual information alone is often insufficient to accurately determine the true nature and urgency of an event. For example, a visually recognized "person falling to the ground" could be a sudden illness or a normal squatting posture during cleaning work; a visually recognized "area intrusion" could be an illegal entry or a normal inspection by authorized personnel during a specific time period. To eliminate the ambiguity of single-modal perception, this step introduces multi-dimensional contextual information from the physical world for cross-validation and enhancement.

[0075] Specifically, equipment status parameters include, but are not limited to, the on / off status of access control controllers, card swipe records, lock feedback signals, instantaneous power, voltage fluctuations, and current harmonics of energy metering devices, and the operating frequency and valve opening of HVAC equipment; environmental operating parameters include temperature and humidity, light intensity, smoke concentration, and noise levels. For these time-series physical quantities, the system first performs normalization processing to map them to a preset numerical range (e.g., 0 to 1), and extracts the statistical features (including mean, variance, and peak value) of each parameter within a preset time window (e.g., the last 60 seconds). Subsequently, these statistical features are aligned with the preceding visual anomaly feature vector within the time window and concatenated along the feature dimension to form a comprehensive anomaly feature vector integrating "visual semantics + physical state + environmental background."

[0076] For example, when a visual model detects the "personnel intrusion" feature, if it simultaneously acquires the "unauthorized forced opening" status signal from the access control system and the "abnormal shutdown" signal from the area's lighting system, these physical features will be encoded and appended to the visual features, significantly improving the distinguishability of the representation vector for real intrusion events. This multimodal fusion mechanism ensures that subsequent classification decisions no longer rely solely on image recognition results, but are based on collaborative verification of multidimensional perception (visual, auditory, and tactile). This fundamentally reduces the false alarm rate caused by visual occlusion, changes in lighting, or interference from similar actions, providing a solid data foundation for subsequent accurate classification and event grading.

[0077] Step S502: Based on the pre-trained event classification model, input the comprehensive abnormal feature vector into the event classification model, output the attribution probability value corresponding to each preset event category, and determine the event category corresponding to the highest attribution probability value as the abnormal event category.

[0078] The event classification model here can be implemented using various algorithms such as Naive Bayes classifier, random forest, support vector machine, or deep neural network. Its core function is to map high-dimensional comprehensive features to a predefined event category space. During the model training phase, the system acquires a large amount of sample data from a historical event database. This sample data contains historical comprehensive anomaly feature vectors and their corresponding real event labels. By inputting the sample data into the model, the error between the predicted result and the real label is calculated using the cross-entropy loss function (for neural networks) or maximum likelihood estimation (for Bayesian classifiers). The backpropagation algorithm or statistical iterative method is used to continuously update the weight matrix or prior probability parameters within the model until the model converges, thus completing the pre-training.

[0079] Unlike traditional hard classification outputs, this embodiment requires the trained model to output the corresponding probability values ​​for each preset event category (such as illegal intrusion, hardware failure, personnel fall, violation of regulations, environmental anomalies, etc.), i.e., the posterior probability distribution. This probabilistic output retains the uncertainty information of the model's predictions, providing a quantitative basis for subsequent weighted decision-making. Specifically, in the implementation using a Naive Bayes classifier, the system uses the prior probabilities of each category obtained from the historical event database, combined with the conditional probabilities of each dimension of the current comprehensive anomaly feature vector, to calculate the posterior probability of each event category. For example, for a comprehensive vector containing features such as "high deviation in card swipe time, large response delay, and severe voltage fluctuations," the model may calculate the probability of "hardware failure" as 0.907, "illegal intrusion" as 0.070, and "misoperation" as 0.023. The system selects "hardware failure," which has the highest probability value, as the current anomaly event category.

[0080] It should be understood that the calculation of attribution probability is essentially a process of Bayesian inference or feature space distance measurement of multi-source heterogeneous evidence. It transforms discrete sensor readings into event semantic labels with clear business implications. Compared to traditional hard judgments based solely on a single alarm signal, this probabilistic model comprehensively considers the contribution of multi-dimensional features. Even in cases of feature ambiguity or noise interference, it can still output classification results with statistical confidence, significantly improving the robustness of event characterization.

[0081] Step S503: Obtain the preset area weight coefficient of the physical area where the abnormal event occurred, and perform a weighted calculation by combining the basic security level corresponding to the category with the preset area weight coefficient.

[0082] This step is crucial for achieving "dynamic prioritization" in this embodiment. In traditional solutions, event priority is often determined solely by event type, ignoring the differences in the importance of the location where the event occurs. However, in actual property management, the same type of event occurring in different areas can have drastically different risk levels and urgency. For example, "personnel loitering" in a regular office area might be a low-priority concern, but if it occurs in a core data center or finance office, it should be escalated to a high-priority security threat.

[0083] To this end, this application pre-establishes a regional weight configuration table, assigning a weight coefficient reflecting the importance and sensitivity of each physical area within the property scenario. Specifically, the determination of the preset regional weight coefficient adopts a multi-index quantitative evaluation model, with the following steps: First, extracting the static attribute characteristics and dynamic operational characteristics of each physical area. The static attribute characteristics include the area's asset value density and legal security compliance level, while the dynamic operational characteristics include the peak frequency of personnel flow and the frequency of historical security event triggers. Second, assigning preset evaluation weights to the above characteristics, normalizing the actual values ​​of each characteristic, and then multiplying and summing them with the corresponding evaluation weights to calculate the comprehensive sensitivity score of each physical area. Finally, mapping the comprehensive sensitivity score to a preset weight range (e.g., 0.5 to 2.0) to determine the preset regional weight coefficient for that physical area. Based on this determination method, high-sensitivity areas such as core computer rooms and power distribution rooms can be mapped to higher weight coefficients (e.g., 1.5 or higher), ordinary office areas can be mapped to standard weights (e.g., 1.0), and open areas such as public corridors can be mapped to lower weights (e.g., 0.8).

[0084] After determining the weighting coefficients, each event category is associated with a basic security level score, which reflects the inherent severity of the event. For example, "illegal intrusion" has a basic score of 8 points, "hardware failure" has 6 points, and "personnel loitering" has 3 points. The system multiplies the basic security level of the category by the weighting coefficient of the region where the event occurred to obtain a weighted security score. For example, when "hardware failure" (basic score 6 points) occurs in the "core computer room" (weight 1.5), its weighted security score is 6 × 1.5 = 9 points; while when "illegal intrusion" (basic score 8 points) occurs in the "public corridor" (weight 0.8), its weighted security score is 8 × 0.8 = 6.4 points. Through this weighted calculation, the system successfully transforms static event classification into dynamic, scenario-based risk assessment, enabling resource scheduling to accurately match actual business risks and avoiding resource misallocation caused by a "one-size-fits-all" approach to event categorization.

[0085] Step S504: Determine whether the weighted calculation result is higher than the preset classification boundary threshold. If so, assign a high priority label type; otherwise, assign a low priority label type and generate an event classification result containing category labels and priority labels.

[0086] The preset classification boundary threshold serves as a decision-making watershed between emergency events and routine events. The determination of this preset classification boundary threshold involves: first, acquiring emergency response data within a preset historical time period, including the weighted calculation results of each historical event and its corresponding actual response level; second, performing statistical analysis on the emergency response data to extract the percentile values ​​(e.g., 75th or 90th percentile) for historical events requiring high-level coordinated responses; and finally, determining the preset classification boundary threshold based on these percentile values ​​and considering the overall security strategy and emergency resource capacity of the current property management. Furthermore, the preset classification boundary threshold can be dynamically adjusted during operation according to seasons and time periods (e.g., holidays, nighttime mode) to adapt to different levels of security sensitivity and resource availability.

[0087] For example, if the grading boundary threshold is set to 8 points, the hardware failure that occurs in the core computer room (weighted score of 9 points) will be given a "high priority" label, triggering an immediate alarm and automated work order dispatch; while the illegal intrusion that occurs in the public corridor (weighted score of 6.4 points) is a security event, but because the weighted score does not reach the threshold, it will be given a "low priority" label, and will only be logged or processed later.

[0088] The final generated event classification result is a structured data object, containing at least two core fields: "Abnormal Event Category" (e.g., hardware failure) and "Priority Tag Type" (e.g., high priority). This result will directly serve as the retrieval index for downstream cross-system rule engines, determining the matching and execution strategy of subsequent linkage instruction sets. It should be understood that, in addition to the two-level classification, multiple threshold intervals can be set in other embodiments to achieve multi-level priority classification (e.g., P0 / P1 / P2 / P3), as long as the core logic is still based on the weighted judgment mechanism of "basic level × regional weight", it falls within the protection scope of this application.

[0089] Step S103: In the pre-established cross-system rule engine, retrieve the triggering rule that matches the event classification result; if a matching triggering rule exists, activate the triggering rule and generate a set of linkage instructions containing the target subsystem identifier, action type and execution sequence.

[0090] The cross-system rule engine is a core component for decoupling business logic from control execution. It allows administrators to flexibly configure complex composite trigger conditions without modifying the underlying code. The cross-system rule engine is pre-built during system initialization. Its rule base contains multiple trigger rules, each defined in a structured format of "if (condition), then (action)". The condition part is associated with the category and priority labels in the event hierarchy results, while the action part is bound to the target subsystem identifier, action type, and execution sequence parameters. Administrators can add, modify, or delete trigger rules through the rule editor; rule changes take effect immediately without requiring a system restart. Composite trigger conditions are constructed by combining multiple sub-conditions using logical operators to achieve fine-grained adaptation to complex property scenarios.

[0091] During the retrieval phase, the system inputs the event classification results into the cross-system rule engine. Through an efficient reasoning process based on pattern matching or the Rete algorithm, it searches the rule base for applicable triggering rules. If a matching triggering rule exists, the system activates that rule, assigns it a unique execution context, locks relevant resources to prevent concurrent conflicts, and then parses the action sequence defined in the rule.

[0092] It is particularly important to emphasize that the generated linkage instruction set clearly defines the execution sequence, which is crucial for ensuring the security of the physical world. For example, in an unauthorized intrusion scenario, it is essential to ensure that the door locking action precedes the activation of lighting or the sound and light alarm to prevent intruders from escaping or causing damage. Through the sequential arrangement of instructions, the system transforms abstract linkage strategies into an ordered sequence of operations that conforms to physical causality, ensuring the logical correctness and security of multi-system collaborative actions.

[0093] Specifically, such as Figure 6 The diagram shown is a flowchart illustrating the process of retrieving and matching trigger rules and generating a linkage instruction set in a smart property integrated management and control method provided in this application embodiment. The method includes:

[0094] Step S601: Obtain the pre-set linkage rule library in the cross-system rule engine, and perform matching and retrieval in the linkage rule library according to the category label and priority label in the event classification result.

[0095] The linkage rule base stores all predefined automated handling strategies in property management scenarios. It is organized using a multi-dimensional index structure, with each triggering rule bound to a target subsystem identifier list, action type, and execution timing parameters. The target subsystem identifier list identifies the specific physical devices or logical systems that need to participate in the linkage when the rule takes effect; the action type defines the specific operation that each target subsystem must perform; and the execution timing parameters specify the order, delay time, and synchronization relationship between the actions of each subsystem to ensure the logical rigor of the linkage process.

[0096] In order to improve the real-time performance of retrieval under massive rules, the present application adopts a dual-condition indexing mechanism, that is, "category labels" and "priority labels" are used as joint primary keys to construct a hash index or inverted index structure. When an event classification result is received, the system does not need to traverse the entire rule base, but directly locates the candidate rule subset associated with the category and priority through the index. For example, for an "illegal intrusion-high priority" event, the system can lock all disposal rules for high-level security events at the millisecond level, and automatically filter out low-priority environmental alarm rules or equipment operation and maintenance rules. This retrieval mechanism not only significantly reduces computational overhead, but also ensures the deterministic delay of system response in sudden emergencies.

[0097] Step S602: when a candidate triggering rule is matched, verify whether the current scene state satisfies all the triggering conditions defined in the candidate triggering rule, and if yes, determine the candidate triggering rule as an activated triggering rule.

[0098] This step is called "compound condition verification", which is a key line of defense to ensure linkage accuracy. In actual property scenarios, only relying on event category and priority is often not enough to determine whether a specific linkage needs to be performed immediately, and real-time environmental context is also required to be combined. Therefore, the triggering rules in the present application support defining compound conditional expressions containing logical operators (such as AND, OR, NOT).

[0099] During the verification process, the system first obtains real-time context information of the current scene (including current system time, status of equipment in each area, readings of environmental sensors, etc.), and forms a multi-source heterogeneous data fusion snapshot that reflects the overall operation situation of the property management and control system. Then, the system substitutes the corresponding parameters in the snapshot into the candidate triggering rule for calculation. For example, a linkage rule for intrusion into a data center defines a compound triggering condition: "threat value greater than 80 AND current time period is 20:00 to 06:00 the next day AND area attribute is key protection area". After retrieving the candidate rule, the system reads the clock signal, area configuration table and threat value field in event details in real time, and verifies each sub-condition one by one. For a condition set with logical AND (AND) relationship, the rule is only confirmed to be activated when all sub-conditions are calculated as true; if any condition is not satisfied, the rule is abandoned and the next candidate rule continues to be verified.

[0100] This design effectively avoids wrong linkage caused by single-dimensional judgment, for example, prevents the highest-level nighttime blockade plan from being mistakenly triggered due to personnel entering and exiting during normal daytime operation and maintenance, which significantly improves the intelligence level of the system and user experience.

[0101] Step S603: Parse the activation trigger rules and extract the target subsystem identifier list, the action type and execution timing parameters corresponding to each subsystem bound in the rule definition.

[0102] The activation rule is essentially a structured control template. During the parsing phase, the system transforms the high-dimensional logical rules into a set of atomic instructions that can be understood by the underlying execution engine. The "Target Subsystem Identifier List" specifies the device objects that need to participate in the linkage (such as access controller ID, camera IP, lighting circuit number, etc.), clarifying the routing scope for instruction issuance; the "Action Type" defines the specific operation instructions (such as locking, focusing, dimming, start / stop, etc.). During parsing, these predefined function codes are mapped to specific communication protocol instruction codes to drive the underlying physical devices.

[0103] The "execution timing parameter" is the core feature that distinguishes this application from traditional concurrency control schemes. This parameter can be expressed in various forms, including but not limited to relative delay time (such as T+500ms), absolute timestamps, or sequence markers based on dependencies (such as Step1, Step2). By parsing the execution timing parameter, the system can reconstruct the complete timeline of the coordinated actions. The introduction of this parameter makes the coordinated action no longer a simple stacking of multiple actions, but an ordered sequence with strict causal logic, thereby ensuring the logical correctness and safety of cross-system collaborative actions in the physical world.

[0104] Step S604: If the same triggering rule is bound to multiple target subsystem identifiers, then sort the target subsystem identifiers according to the execution timing parameters to generate an ordered linkage instruction set, so that each target subsystem executes actions in the order of response determined by the linkage instruction set.

[0105] In the physical world, the sequence of actions of multiple systems often directly affects the effectiveness and even security of the response. For example, when dealing with unauthorized intrusion, the priority should be to lock the access control system to restrict the movement of people, followed by turning on the lighting to assist in monitoring and evidence collection, and finally activating the audible and visual alarms to drive away the intruder. If the order is reversed, the intruder may escape before the door locks are closed, or the alarm may be triggered in the dark, causing chaos.

[0106] This step uses the parsed timing parameters to reorganize the originally parallel subsystems and actions into a linear instruction queue with timing constraints. During the sorting process, the system strictly arranges instructions according to time priority, placing those with shorter delays or marked as immediately executable at the front. If there are strict dependencies (such as waiting for a door lock to close before turning on the lights), the final order is determined based on the dependency chain. The resulting linkage instruction set is stored using a serialized data structure, which not only includes "what to do" (action type) and "who does it" (target subsystem identifier), but also specifies "when to do it" and "order of execution" (predetermined execution time), thus ensuring the logical correctness and physical execution security of cross-system linkage.

[0107] Step S104: Parse the linkage instruction set, and according to the parsed target subsystem identifier and action type, issue action instructions to each target subsystem in the execution sequence, and receive the execution receipts from each target subsystem.

[0108] This step is the core execution stage in industrial control software, transforming an ordered set of instructions into actual physical control signals. During the instruction issuance phase, the system first performs syntax analysis and deserialization on the linkage instruction set, extracting the target subsystem identifier, action type parameters, and execution timing information for each node. Subsequently, the system looks up the corresponding communication protocol configuration (such as Modbus, OPC UA, MQTT, or HTTP / RESTful API) based on the target subsystem identifier, and encapsulates the action type parameters into action instruction data packets conforming to the protocol specifications. Regarding timing control, the system maintains a priority queue or time wheel through a task scheduler, strictly adhering to the planned execution timestamp to trigger instruction transmission. For parallel actions, asynchronous I / O mechanisms are used for concurrent issuance to improve response speed; for serial actions, the logic of confirming the preceding action before sending subsequent actions is strictly followed, effectively avoiding concurrency conflicts.

[0109] During the feedback reception phase, after the action command is issued, the system monitors the uplink data channel of the target subsystem in real time. When a feedback message containing the corresponding command sequence number is captured, the system parses it into an execution feedback, which includes the command reception status, the start and end times of the action execution, the result code, and a snapshot of the current device status. This two-way feedback mechanism transforms the originally open-loop control commands into an observable state flow, enabling the system to monitor the implementation of linkage commands by each subsystem in real time, thus providing indispensable factual evidence for subsequent closed-loop verification and anomaly handling.

[0110] Specifically, such as Figure 7 The diagram shown is a flowchart illustrating the parsing of a linkage instruction set and the issuance of an execution receipt in a smart property integrated management and control method provided in this application embodiment. The method further includes:

[0111] Step S701: Based on the parsed execution sequence, the linkage instruction set is disassembled and sorted to generate an instruction queue to be issued; wherein, each instruction in the instruction queue carries the corresponding target subsystem identifier and action type.

[0112] Although the linked instruction set generated in the preliminary steps is already ordered, it still needs to be broken down into independent atomic instruction units that can be processed by the underlying communication protocol stack before actual delivery. The purpose of constructing this instruction queue is to mitigate resource contention and channel conflicts that may arise during concurrent responses from multiple systems through a strict timing control mechanism. This queue is not a simple list of instructions, but an ordered scheduling structure built based on priority logic and time constraints. Its underlying architecture can combine a priority queue with a time wheel, consisting of a memory buffer, linked list indexes, and scheduling pointers. Internally, it maps the target subsystem identifier to a specific network address through hash mapping and retains a predefined execution timestamp field.

[0113] In the specific generation process, the system extracts the execution timing parameters of each instruction from the linkage instruction set, calculates the absolute trigger timestamp based on the relative delay, and then performs topological sorting and time slicing using the execution timing as the primary key and the target subsystem identifier as the secondary key. The sorted atomic instructions are then loaded into a send buffer pool with a circular buffer structure. The scheduling pointer scans the buffer pool at a preset period (e.g., 50 milliseconds), and once the current system time matches the absolute trigger time of the instruction, the send action is triggered.

[0114] Furthermore, during dynamic execution, the system can dynamically adjust the transmission rhythm based on the arbitration results of the real-time transmission bus (such as the CAN bus). When the bus load rate exceeds a preset threshold (e.g., 85%; this threshold is set based on the stability boundary of bus communication and supports dynamic configuration according to the actual network environment), the queue scheduler automatically suspends the transmission of low-priority instructions, prioritizing the channel occupancy rights of high-priority instructions. For example, when access control and video surveillance streams simultaneously compete for bus bandwidth, the system automatically determines the priority of access control instructions, and video stream transmission automatically backs off. Compared to traditional simple polling or broadcast instruction issuance, this queued management and dynamic arbitration mechanism achieves deterministic scheduling under limited communication bandwidth, ensuring the timeliness of critical control actions.

[0115] Step S702: Based on the target subsystem identifier and action type carried by each instruction in the instruction queue, issue the corresponding action instructions to the corresponding target subsystem in sequence.

[0116] Based on the scheduling logic of the instruction queue, control intentions are accurately transmitted to physical devices through a defined communication link. Using a pre-established device address mapping table, the target subsystem identifier of the instruction currently awaiting transmission in the instruction queue is resolved into a specific physical address (such as an IP address, Modbus slave address, or CAN node ID), and then encapsulated into a data packet conforming to the target device's protocol specifications, combined with the action type (such as locking, unlocking, adjusting brightness). The transmission process strictly follows the atomic operation flow of polling-verification-transmission: first, the communication link status of the target subsystem is checked; if the link is normal, the encapsulated instruction is sent to the target subsystem through the communication protocol stack, and then the system waits for an acknowledgment signal.

[0117] In practice, protocol stacks such as TCP / IP or Modbus RTU are used to issue locking commands to the access control controller and full-brightness commands to the lighting controller, following the order of the command queue. The interval between each command is strictly controlled by the execution timing parameters to ensure that the actions have the necessary logical sequence. For example, the access control system is locked first, then the high-brightness lighting is turned on to assist in image capture, and finally the audible and visual alarm is activated to deter intruders. This time-sequential command method couples the originally discrete subsystem operations into a coherent tactical action sequence, enabling previously independent devices to collaboratively execute complex security plans.

[0118] Step S703: After receiving the action instruction, each target subsystem executes the corresponding action and generates an execution receipt containing an execution status identifier and a timestamp; wherein, the execution status identifier includes an action success identifier, a status no change identifier, or an execution failure identifier.

[0119] Execution receipts, as feedback reports from each target subsystem on the execution results of action commands, are essentially projections of physical world state changes into digital space. They are used to transform the internal hardware state into structured data that can be read by upper-level systems. Receipts employ a fixed message structure, specifically including the device ID, execution status identifier, timestamp, and necessary feedback parameters (such as the current opening / closing angle and actual power value). The execution status identifier is an enumerated value representing the execution result, used to clearly distinguish the actual completion status of the action, rather than simple Boolean feedback.

[0120] The execution receipt is generated by the control module of the target subsystem after completing the corresponding action. Taking an access control controller as an example: after the controller completes the action of driving the electromagnetic lock, it reads the level signal of the latch sensor; if the level signal indicates that the latch is in place, the execution status flag is set to the action success flag; if the door is detected to be in a locked state, the status is set to the no-change flag, indicating that the device status meets expectations and there is no need to drive the mechanical mechanism again; if an abnormal current or mechanical jamming is detected during the driving process, the execution failure flag is set. Through this refined status feedback mechanism, the upper-level control system can accurately distinguish between the status changes driven by instructions and the existing status facts, effectively avoiding invalid mechanical actions and communication resource waste caused by repeated instructions, and providing high-fidelity status basis for subsequent closed-loop judgment.

[0121] Step S704: Obtain the execution receipts returned by each target subsystem, align and arrange them according to the timestamps carried by each execution receipt, and merge them to generate a cross-system execution status set.

[0122] The cross-system execution state set is a macroscopic mapping of the final state of the entire collaborative process, used to resolve data misalignment issues caused by differences in the response speeds of different subsystems. This set is not a simple data stack, but a multi-dimensional state matrix reconstructed based on a unified time benchmark. In its implementation, this set uses a data structure indexed by timestamps and with subsystem identifiers as fields, providing a unique source of facts for subsequent loop closure determinations.

[0123] During the generation process, the system uses a sliding window alignment algorithm to handle asynchronously arriving receipts: the system uses the time of the linkage instruction issuance or the system clock as a reference to define a sliding window of a preset width (such as 500 milliseconds) on the time axis, and aggregates the receipts that fall into the window; if there are missing receipts in the window, the subsystem is marked as not ready in the corresponding status record. This mark triggers a compensation mechanism in the subsequent closed-loop verification, and finally merges them into a global status record.

[0124] Through the alignment mechanism described above, the system integrates asynchronous and discrete feedback signals into a unified set of states with a consistent time base, eliminating data deviations caused by network latency and clock asynchrony, and providing a solid data foundation for subsequent closed-loop verification and anomaly compensation.

[0125] Step S105: Compare the execution receipt with the preset completion conditions. If the execution receipts of all target subsystems meet the preset completion conditions, the linkage response link is determined to be closed and complete. If there is a target subsystem that does not meet the preset completion conditions, a compensation instruction is triggered and re-executed until the closed-loop conditions are met.

[0126] The preset completion conditions include execution result code verification (e.g., the status code must be successful), action execution time deviation verification (e.g., response time must be within the allowable range), and post-execution device status threshold verification (e.g., the current access control status must be closed). The system checks the execution receipts returned by each target subsystem one by one to ensure that they meet the above conditions, thereby accurately identifying failed links or timeouts in the linkage execution process. When the execution receipts of all target subsystems meet the preset completion conditions, the linkage response chain is deemed to be completely closed, marking the successful completion of the cross-system collaborative management and control task.

[0127] If any target subsystem fails to meet the conditions, the system automatically triggers a compensation mechanism: based on the type of incomplete item, it retrieves the corresponding retry strategy or alternative solution (such as increasing the number of transmissions, switching to a backup control link, issuing a reset command, etc.) from the preset compensation rule base, generates a compensation instruction set, and issues it again. The system continuously monitors the execution status of each subsystem, cyclically performing comparison and compensation operations until all subsystems meet the closed-loop conditions. This mechanism ensures that the property management system still possesses highly reliable closed-loop response capabilities when facing network jitter or occasional equipment failures.

[0128] Specifically, such as Figure 8 The diagram shown is a flowchart of a method for determining the complete closure of a linkage response chain by comparing execution receipts according to an embodiment of this application. The method further includes:

[0129] Step S801: Obtain the preset completion standard set corresponding to the linkage instruction set. The preset completion standard set includes the status threshold and response time limit corresponding to each target subsystem.

[0130] The preset completion standard set is a structured dataset uniquely bound to the linkage instruction set. It defines the quantitative indicators and time limits that each target subsystem must meet for successful execution. In its implementation, the preset completion standard set is stored in JSON or XML format, using the target subsystem identifier as the primary key and the status threshold and response time limit as secondary keys. The status threshold precisely describes the physical boundaries that the device's operational results must meet, while the response time limit defines the maximum allowable delay from instruction issuance to status feedback. This set provides an objective and quantifiable benchmark for subsequent closed-loop determination.

[0131] This preset set of completion criteria is pre-defined during the rule engine configuration phase. Its data sources include operating parameter manuals provided by equipment manufacturers, safety operation standards established by property management, and empirical values ​​derived from historical operational data. The preset set of completion criteria is determined by configuring corresponding status thresholds and response time limits for each subsystem based on its equipment type, linkage action type, and business security level. The status thresholds are set based on the reasonable range of physical quantities under normal operating conditions and the feedback status code upon successful execution; the operating parameter manuals provided by the equipment manufacturers serve as the primary reference. Depending on the verification method, status thresholds are divided into three types: first, interval thresholds, where the status value must fall between the preset upper and lower limits (e.g., the door lock opening angle must be between 85° and 95°); second, boundary thresholds, where the status value must reach or exceed a preset critical value (e.g., water pressure must be no less than 0.4 MPa); and third, precision thresholds, where the status value must be completely consistent with the preset value (e.g., the access control feedback status code must be 107). Different types of thresholds are determined by the physical characteristics and security standards of the target subsystem, and the corresponding judgment logic is executed according to the threshold type during verification.

[0132] The response time limit is set based on the subsystem's standard response time and the maximum delay allowed by safety regulations; the safety operation standards established by property management can serve as the primary basis. Within the same set of linkage instructions, different target subsystems can be configured with different status thresholds and response time limits, and the same target subsystem can also be configured with different completion standards under different types of linkage instructions. The determined set of preset completion standards is bound to the corresponding set of linkage instructions during the rule engine configuration phase and stored in the system configuration database.

[0133] When executing a linkage command, the system retrieves the corresponding preset completion standard set from the database or configuration center in real time based on the unique identifier in the command set. For example, for the fire sprinkler subsystem, the status threshold can be set to a water pressure value between 0.4MPa and 0.6MPa and a sprinkler status code between 200 and 210, with a response time limit set to within 5 seconds after the command is issued; for the access control subsystem, the status threshold can be set to a door lock closing angle between 85 degrees and 95 degrees and a feedback code of 107, with a response time limit set to 2 seconds. By loading the above preset completion standard set, the system can compare and verify the execution receipts of each subsystem item by item.

[0134] Step S802: Compare the execution receipts of each target subsystem with the preset completion standard set one by one. If the status code in the execution receipt meets the status threshold requirements and the response time does not exceed the response time limit, the corresponding target subsystem is marked as qualified; otherwise, it is marked as unqualified.

[0135] After obtaining the preset set of completion criteria and the execution receipts from each target subsystem, the system performs a step-by-step correlation and comparison operation. The core intention of this step is to transform the ambiguous physical execution results into precise logical judgments, thereby effectively eliminating abnormal situations such as "false success" or "partial failure".

[0136] During the correlation comparison process, the system first indexes the corresponding completion standard entry in the preset completion standard set based on the target subsystem identifier carried in the execution receipt, establishing a precise mapping relationship. Then, it extracts the status code and timestamp fields from the execution receipt and performs dual verification logic.

[0137] The first dimension is status compliance verification: determining whether the status code in the execution receipt falls within the valid range of the status thresholds defined in the preset completion standard set. For example, if the execution receipt of an energy device returns a status code of 200, and the preset status threshold requirement is 200-204, then this dimension is considered to have passed; if the returned status code is 500, then it is considered to have failed.

[0138] The second dimension is process timeliness verification: calculate the difference between the timestamp in the execution receipt and the timestamp of the instruction issuance, and determine whether the difference is less than or equal to the preset response time limit. For example, if the response time limit of a lighting device is 1 second, but the actual receipt takes 1.2 seconds, even if its status code is correct, it will be judged as failing to meet the timeliness standard.

[0139] The system will only mark the internal state of the target subsystem as compliant when both of the above dimensions are simultaneously satisfied; if either dimension is not satisfied, it will be strictly marked as non-compliant. This marking result will be updated in real time and written to the global state table in the system memory for subsequent decision-making. Through this dual verification mechanism, the system can effectively identify hidden faults such as those that return a success status code but actually time out, or those that respond extremely quickly but have physical deviations in the execution result (such as a valve not being fully closed). This ensures that the evaluation of the subsystem's execution capability considers both the correctness of the result and the timeliness of the process, providing high-fidelity local state information for global closed-loop determination.

[0140] Step S803: If all target subsystems are marked as compliant, obtain the closed verification rules corresponding to the linkage instruction set. The closed verification rules define the dependency relationships and execution order constraints between each target subsystem.

[0141] When all target subsystems are marked as compliant, it means that each subsystem has met the requirements at the independent execution level. However, this is not enough to prove that the entire linkage process is successful. Since cross-system linkage is often subject to complex logical constraints and timing dependencies, this step introduces a closure verification rule to perform a secondary verification of the logical integrity of the linkage link from a global perspective.

[0142] The closed-loop verification rule is a set of logical predicates defined on the linkage instruction set. Its physical essence is a mathematical abstraction of the dependencies in business processes in the real world. The rule mainly includes two types of core constraints: First, dependencies, which describe the preconditions between the actions of different subsystems. For example, the video surveillance system should only start recording after the access control system has successfully locked, or the evacuation broadcast system can only be de-silenced after the water pressure of the fire sprinkler system reaches the standard. Second, execution order constraints, which strictly limit the order in which the actions of each subsystem occur. For example, in a nighttime arming scenario, the standard process must be "lights on → camera focused → alarm triggered". Any reverse or disordered actions may lead to linkage failure or even cause a safety accident.

[0143] In a practical implementation, the closure verification rule can be obtained, for example, by reading it from the rule engine's database. In the database design, each linked instruction set record has a corresponding rule identifier field, through which the corresponding closure verification rule script can be loaded. The underlying data structure of this rule script can be a Directed Acyclic Graph (DAG), where nodes represent the actions of each subsystem, and directed edges represent the execution order or dependency conditions. By introducing closure verification rules, this step upgrades the single point-to-point state check to a link-level logical verification, effectively preventing disordered actions caused by communication delays between factor systems, and ensuring that the entire physical world's response process strictly conforms to the expected business logic and security specifications.

[0144] Step S804: Check whether the actual execution order of each target subsystem conforms to the execution order constraint in the closure verification rule according to the timestamp order. If it does, it is determined that the cross-system linkage response link is complete.

[0145] After obtaining the closure verification rules, the system further performs timing verification. This step aims to verify, through time-dimensional backtracking, whether the actual action sequence of each subsystem strictly follows the preset execution logic, thereby ensuring that the linkage response link is not only closed in terms of result, but also rigorous in process.

[0146] Specifically, the system extracts all execution receipts collected in previous steps, sorts them in ascending order according to the timestamps carried in the receipts, and generates an actual action sequence arranged in chronological order. Then, the actual action sequence is input into a rule parsing engine, and is checked by matching one by one against the execution order constraints defined in the closed verification rules. For example, if the closed verification rule stipulates that action A must come before action B, but the timestamp of action B is found to be earlier than that of action A in the actual sequence, it is determined that there is a conflict in the execution order constraint; for another example, for actions with dependency relationships, the system checks whether the completion time of the dependent action is earlier than the start time of the depending action, and if the execution timestamp of the depending action is found to be earlier than the completion timestamp of its dependent action, it is also regarded as a violation.

[0147] Only when the actual execution order of all target subsystems fully complies with all execution order constraints and dependency relationships in the closed verification rules can the closed integrity of the current cross-system linkage response link be determined. This determination mechanism means that even if all subsystems return a compliance status, as long as the sequence of actions is disordered, the system will still determine that the linkage fails, and may trigger a retry or alarm mechanism. Through this strict timing verification, logical confusion caused by network jitter, instruction queuing or differences in device processing speed can be effectively avoided, ensuring that the coordinated actions of multi-subsystem linkage present an orderly and controllable causal chain on the physical timeline, thereby guaranteeing the logical rigor and operational reliability of property management when responding to emergencies.

[0148] Further, as Figure 9 shows, it is a flowchart of a method for triggering compensation instructions until the closed-loop condition is satisfied provided by the embodiment of the present application, and the method further includes:

[0149] Step S901: If there is an execution item marked as unfinished in the cross-system execution state set, retrieve the compensation instruction corresponding to each unfinished execution item from the preset compensation rule base, and obtain the set of to-be-compensated subsystem identifiers and the corresponding compensation instruction execution sequence.

[0150] The pre-defined compensation rule base differs from conventional linkage rule bases; it specifically stores repair strategies for various execution failure scenarios. These strategies not only include retry parameters for the original command but also cover alternative handling solutions. For example, when an access control controller returns to an "execution failure" state due to a power supply module failure, the corresponding compensation command in the compensation rule base does not resend the "lock" command but instead "switch to the UPS backup power circuit." Similarly, when the main camera network times out and cannot transmit tracking frame positions, the compensation command might be "activate adjacent redundant cameras to take over the monitoring area." After retrieving the compensation commands corresponding to each fault point, the system sorts the commands according to pre-defined fault priorities and business urgency, placing compensation commands related to core security (such as access control and fire protection) first, forming an ordered sequence of compensation command execution. Through this differentiated command retrieval and sorting mechanism, the system can take targeted measures against the root cause of the fault, effectively avoiding blindly repeating ineffective operations and significantly improving the success rate of fault recovery and the orderliness of collaborative response.

[0151] The pre-built compensation rule base is constructed offline and continuously optimized during the system deployment phase. Its construction process is as follows: First, execution failure cases and corresponding operation and maintenance logs recorded in the historical operation of each target subsystem are collected, supplemented by fault manuals provided by the vendor and expert experience, to construct an initial fault-compensation mapping rule set. Second, for fault scenarios lacking historical data, system response characteristics are obtained through fault injection testing (simulating typical anomalies such as power outages, communication timeouts, and resource exhaustion). Operation and maintenance experts then label each type of fault with a compensation strategy based on the business security level. Subsequently, the above rules are stored in a key-value pair structure (the key is the error code or status identifier, and the value is the corresponding compensation instruction set), and a rule identifier field is attached to associate it with the subsystem and business scenario. After construction, typical fault combinations need to be injected into the simulation environment to verify the correctness of the compensation logic and avoid secondary conflicts between compensation instructions (e.g., simultaneous execution of backup power switching and main power restoration instructions causing loop oscillation). Only rule sets that pass verification can be solidified as the pre-built compensation rule base and loaded at runtime. In addition, the rule base supports an incremental update mechanism—when a new failure scenario occurs during operation and the existing rules cannot cover it, the system records the anomaly and adds new rules after review by the operations and maintenance personnel, so that the compensation capability continues to evolve as operational data accumulates.

[0152] Step S902: Based on the state dependencies between each target subsystem, dynamically adjust the execution sequence of compensation instructions to obtain an executable compensation instruction set; wherein, the dynamic timing adjustment includes: adjusting compensation instructions with pre-dependent relationships to be triggered after the execution of their pre-dependent instructions.

[0153] This step is the core feature that distinguishes it from traditional fixed-sequence retry schemes. In anomaly compensation scenarios, the dependencies between instructions often change or new constraints are added. For example, in the access control power failure scenario mentioned above, "switching to backup power" becomes a prerequisite for "access control locking"; at the same time, the "lighting on" action, which is normally parallel to access control, will be adjusted to be delayed after the power switch stabilizes in order to avoid the impact of backup power overload.

[0154] To address the aforementioned complex scenarios, the system constructs a real-time state dependency graph and employs a topological sorting algorithm to rearrange the execution sequence of compensation instructions. Specifically, the system introduces a causal reasoning model to dynamically infer effective dependency edges between instructions based on the actual state of each subsystem (such as voltage values, network connectivity, and machine positions). Dependency constraints that fail due to equipment offline are eliminated, and newly generated strong dependencies are inserted at the beginning of the sequence. This dynamic timing adjustment ensures that the execution of compensation instructions strictly adheres to the causal laws of the physical world, effectively avoiding secondary failures or resource contention caused by out-of-order compensation, and guaranteeing the safety and efficiency of the emergency response process.

[0155] Step S903: According to the executable compensation instruction set, reissue the corresponding compensation instruction to each subsystem to be compensated; if a subsystem to be compensated does not return to the execution completion status within the preset response period, mark it as an incomplete item again and trigger the secondary compensation process.

[0156] In its implementation, the preset response period is not a fixed value, but is determined using a weighted calculation strategy of 'basic physical latency + dynamic network jitter'. The system first parses the device's physical model, extracting the mechanical action time or electronic processing delay as the basic latency; then, it combines the current real-time network round-trip time (RTT) with the network jitter value to calculate a flexible response waiting window through weighted summation. This adaptive period setting can automatically scale according to device aging and network congestion, effectively avoiding timeout misjudgments caused by network fluctuations.

[0157] When an incomplete task is detected again, the system will not infinitely loop through the same level of compensation, but will trigger an escalated secondary compensation process. This secondary compensation process may include: expanding the compensation scope (e.g., escalating from single-device compensation to regional-level degraded operation), extending the response waiting window, or generating a manual intervention work order and pushing it to the maintenance terminal. For example, if the backup power switching command does not return a successful status within a preset response period, the secondary compensation process may trigger a deeper strategy of 'cutting off non-core loads to ensure access control power supply', while simultaneously sending the highest-level alarm to on-duty personnel.

[0158] This tiered and progressive compensation mechanism not only ensures the "best effort" of automated processing but also reserves a manual backup channel for extreme anomalies, effectively preventing the system from getting stuck and ensuring the overall security and business continuity of cross-system collaboration under extreme failures.

[0159] Step S904: Continuously poll the execution status of each subsystem to be compensated until the execution status of all subsystems is marked as completed. Determine that the cross-system execution status set meets the closed-loop condition, output the closed-loop completion mark, and terminate the compensation process.

[0160] In its implementation, the status polling employs an asynchronous, non-blocking mechanism, scanning the incomplete items in the cross-system execution status set at fixed intervals (e.g., 50 milliseconds) to avoid high-frequency queries consuming main control computing resources. During the polling process, the system updates the status flags of each subsystem in real time. Once it detects that the status of all participating subsystems (including original execution items and compensation execution items) has changed to "action successful" or "status does not need to be changed," it determines that the closed-loop condition is met. At this point, the system outputs a closed-loop completion flag containing a final state snapshot, total time consumption, and compensation path records, and writes this flag to a persistent log for subsequent auditing and optimization analysis.

[0161] It should be understood that although this embodiment describes the ideal closed-loop logic of "until all subsystems are completed," in actual engineering deployments, to prevent the system from getting stuck in deadlock or anomaly propagation, a maximum number of compensation attempts or a global timeout threshold can be set as a safety circuit breaker mechanism. When the circuit breaker condition is met, the system will forcibly terminate the compensation process and automatically switch to fault isolation mode to ensure the continuity of core business. This design, which balances ideal closed-loop and engineering robustness, enables the cross-system linkage method of this application to remain controllable and reliable in complex and ever-changing real-world environments.

[0162] In summary, the complete technical loop constituted by the above-mentioned retrieval compensation strategy, dynamic temporal rearrangement, hierarchical compensation execution, and continuous state polling endows the system with strong self-healing capabilities in the face of equipment failures or network fluctuations in engineering applications.

[0163] In this closed loop, incomplete execution items serve as triggering conditions, driving dynamic timing adjustment logic to intelligently sort compensation instructions, ensuring that the execution order of compensation actions strictly conforms to the physical constraints and logical dependencies between multiple subsystems; the issuance of executable compensation instruction sets and the introduction of secondary compensation processes build multiple fault-tolerant barriers for the system, effectively distinguishing and mitigating transient and permanent faults; finally, the continuous status polling mechanism serves as the last checkpoint, providing reliable verification of the recovery results of each stage.

[0164] The synergistic effect of the aforementioned technologies enables cross-system collaborative tasks that might otherwise be interrupted due to a single point of failure to automatically return to normal operation without human intervention, thereby significantly improving the stability, robustness, and business continuity of the smart property management system in complex environments.

[0165] Furthermore, an exemplary embodiment of this application also provides a smart property integrated management and control system.

[0166] Figure 10 A block diagram of an exemplary embodiment of the intelligent property management system of this application is illustrated schematically. (Reference) Figure 10 The smart property integrated management and control system 1000 according to an exemplary embodiment of this application may include: a data fusion module 1001, an event classification module 1002, a rule matching and instruction generation module 1003, an instruction issuance and receipt receiving module 1004, and a closed-loop verification and compensation module 1005.

[0167] Specifically, the data fusion module 1001 is configured to acquire real-time raw data streams from various subsystems within a property management scenario, perform standardization and timestamp alignment on the real-time raw data streams, and merge them to generate a fused data snapshot; the event classification module 1002 is configured to extract abnormal feature vectors based on the fused data snapshot, determine the priority labels of events according to the abnormal feature vectors, and generate event classification results carrying category and priority labels; the rule matching and instruction generation module 1003 is configured to retrieve triggering rules that match the event classification results from a pre-established cross-system rule engine; if a matching triggering rule exists, the triggering rule is activated, and a package is generated. The system includes a set of linkage instructions containing target subsystem identifiers, action types, and execution sequences. The instruction issuance and receipt receiving module 1004 is configured to parse the linkage instruction set, issue action instructions to each target subsystem according to the parsed target subsystem identifiers and action types, and receive execution receipts from each target subsystem. The closed-loop verification and compensation module 1005 is configured to compare the execution receipts with preset completion conditions. If the execution receipts of all target subsystems meet the preset completion conditions, the linkage response link is determined to be closed and complete. If there is a target subsystem that does not meet the preset completion conditions, a compensation instruction is triggered and re-executed until the closed-loop conditions are met.

[0168] Since the functional modules of the smart property integrated management and control system in this application are the same as those in the above-described method implementation, they will not be repeated here.

[0169] It should be noted that, in this document, the terms "comprising," "including," and any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Specific examples have been used in this document to illustrate the principles and implementation methods of the technical solutions of this application. The above examples are only for the purpose of helping to understand the methods and core ideas of this application. The above descriptions are merely preferred embodiments of this application. It should be pointed out that, due to the limitations of written expression and the objective existence of infinite specific structures, those skilled in the art can make several improvements, modifications, or changes without departing from the principles of this application, and can also combine the above technical features in an appropriate manner; these improvements, modifications, changes, or combinations, or the direct application of the concept and technical solutions of this application to other situations without modification, should all be considered within the scope of protection of this application.

Claims

1. A smart property management and control method, characterized in that, The method includes: The system acquires real-time raw data streams from various subsystems within a property management scenario, performs standardized transformation and timestamp alignment on the real-time raw data streams, and merges them to generate a fused data snapshot. Based on the fused data snapshot, anomaly feature vectors are extracted, and priority labels for events are determined according to the anomaly feature vectors, generating event classification results carrying category labels and priority labels; In the pre-established cross-system rule engine, a trigger rule matching the event classification result is retrieved; if a matching trigger rule exists, the trigger rule is activated, and a set of linkage instructions containing the target subsystem identifier, action type, and execution sequence is generated. The linkage instruction set is parsed, and action instructions are issued to each target subsystem according to the parsed target subsystem identifier and action type, and execution receipts are received from each target subsystem. The execution receipts are compared with the preset completion conditions. If the execution receipts of all target subsystems meet the preset completion conditions, the linkage response link is determined to be closed and complete. If there is a target subsystem that does not meet the preset completion conditions, a compensation instruction is triggered and re-executed until the closed-loop condition is met.

2. The method according to claim 1, characterized in that, The process of acquiring real-time raw data streams from various subsystems within a property management scenario, standardizing and aligning the real-time raw data streams with timestamps, and merging them to generate a fused data snapshot includes: Obtain raw data streams carrying device identifiers and timestamps reported by security cameras, access controllers, energy metering devices and equipment sensors; parse the data packets according to the access protocol type of each raw data stream; extract the device status parameters and business data fields carried by each protocol to obtain an initial data set. According to the preset field mapping relationship table, the field names of the device identifiers, measurement values ​​and status flags of different protocol types in the initial data set are uniformly converted, and records with missing fields or abnormal markers are retained and missing markers are added to them to obtain an intermediate data set with consistent field structure. Based on the timestamp and transmission frequency attributes of each record in the intermediate data set, the time window alignment method is used to perform time-series alignment processing on the data of different reporting periods, resulting in an aligned data set with a unified time base. The security video stream frame sequence, access control status bit sequence, energy metering value sequence, and equipment operation parameter sequence in the aligned data set are merged into the same data structure according to timestamps to generate the fused data snapshot.

3. The method according to claim 2, characterized in that, After merging and generating the fused data snapshot, the process also includes cross-system field completion: Determine whether all fields in the data structure of the fused data snapshot have been filled with valid values; if there are empty field values, mark the field as a field to be filled, and obtain a candidate fused data snapshot with the field to be filled. Based on the subsystem type and field semantics of each field to be completed in the candidate fusion data snapshot, the filling strategy corresponding to the field is retrieved from the preset default filling rule library. If the field belongs to the status bit type field, the preset previous valid status value is used as the default value for filling. If the field is a measurement value or operating parameter type field, the historical average value of the field within the preset sliding window is used as the default value to fill in the missing field; if the field is a cross-system related field, the missing field is filled in by reverse correlation inference based on the actual perception data of other subsystems within the current time window, so as to obtain a complete and fused data snapshot of all fields.

4. The method according to claim 1, characterized in that, The step of extracting abnormal feature vectors based on the fused data snapshot includes: Based on the video frame sequence in the fused data snapshot, a preset visual analysis model is used to extract spatiotemporal features from the continuous frames to obtain a trajectory feature sequence. Determine whether the spatial location code in the trajectory feature sequence falls within a preset area intrusion boundary range. If it does, assign an intrusion area activation mark to the spatial location code that falls within the preset area intrusion boundary range, and combine the spatial location codes with activation marks to generate a frame-level feature set with intrusion area activation marks. Based on the frame-level feature set with intrusion region activation markers, the human body structure features of the target object are extracted to obtain the body posture recognition vector; The body posture recognition vector and the trajectory feature sequence are input into the behavior classification network, which outputs the confidence value corresponding to each behavior category. Behavior categories with confidence values ​​higher than a preset confidence threshold are marked as valid behavior categories, generating the abnormal feature vector containing spatial location encoding and valid behavior categories.

5. The method according to claim 1, characterized in that, The step of determining the priority label of the event based on the abnormal feature vector and generating an event classification result carrying category label and priority label includes: Obtain the equipment status parameters and environmental operation parameters of each subsystem in the current property scenario, and construct a multi-dimensional comprehensive anomaly feature vector by combining the aforementioned anomaly feature vector; Based on the pre-trained event classification model, the comprehensive abnormal feature vector is input into the event classification model, the attribution probability value corresponding to each preset event category is output, and the event category corresponding to the highest attribution probability value is determined as the abnormal event attribution category; Obtain the preset area weight coefficient of the physical area where the abnormal event occurred, and calculate the weighted average of the basic security level corresponding to the category and the preset area weight coefficient. Determine whether the weighted calculation result is higher than the preset classification boundary threshold. If so, assign a high-priority label type; otherwise, assign a low-priority label type, and generate the event classification result containing category label and priority label.

6. The method according to claim 5, characterized in that, The process involves retrieving trigger rules from a pre-established cross-system rule engine that match the event classification result; if a matching trigger rule exists, it is activated to generate a set of linked instructions containing the target subsystem identifier, action type, and execution sequence, including: Obtain the pre-set linkage rule library in the cross-system rule engine, and perform matching and retrieval in the linkage rule library according to the category label and priority label in the event classification result; When a candidate trigger rule is matched, it is verified whether the current scene state meets all the trigger conditions defined in the candidate trigger rule. If it does, the candidate trigger rule is determined as the active trigger rule. The activation triggering rule is parsed, and the list of target subsystem identifiers bound in the rule definition, the action type corresponding to each subsystem, and the execution timing parameters are extracted. If the same triggering rule is bound to multiple target subsystem identifiers, the target subsystem identifiers are sorted according to the execution timing parameters to generate an ordered set of linkage instructions, so that each target subsystem executes actions in the order of response determined by the set of linkage instructions.

7. The method according to claim 1, characterized in that, The process of parsing the linkage instruction set, issuing action instructions to each target subsystem according to the parsed target subsystem identifier and action type, and receiving execution receipts from each target subsystem includes: Based on the parsed execution sequence, the linkage instruction set is decomposed and sorted to generate an instruction queue to be issued; wherein, each instruction in the instruction queue carries the corresponding target subsystem identifier and the action type; Based on the target subsystem identifier and action type carried by each instruction in the instruction queue, corresponding action instructions are sequentially issued to the corresponding target subsystem. After receiving the action instruction, each target subsystem executes the corresponding action and generates an execution receipt containing an execution status identifier and a timestamp; wherein, the execution status identifier includes an action success identifier, a status no change identifier, or an execution failure identifier; Obtain the execution receipts returned by each target subsystem, align and arrange them according to the timestamps carried by each execution receipt, and merge them to generate a cross-system execution status set.

8. The method according to any one of claims 1-7, characterized in that, The step of comparing the execution receipt with the preset completion conditions, and determining that the linkage response link is completely closed if the execution receipts of all target subsystems meet the preset completion conditions, includes: Obtain the preset completion standard set corresponding to the linkage instruction set, wherein the preset completion standard set includes the state threshold and response time limit corresponding to each target subsystem; The execution receipts of each target subsystem are compared with the preset completion standard set one by one. If the status code in the execution receipt meets the status threshold requirement and the response time does not exceed the response time limit, the corresponding target subsystem is marked as qualified; otherwise, it is marked as unqualified. If all the target subsystems are marked as compliant, then the closed verification rule corresponding to the linkage instruction set is obtained. The closed verification rule defines the dependency relationship and execution order constraint between each target subsystem. Check whether the actual execution order of each target subsystem conforms to the execution order constraint in the closure verification rule according to the timestamp order. If it does, the cross-system linkage response link is determined to be complete.

9. The method according to claim 7, characterized in that, If there is a target subsystem that does not meet the preset completion condition, a compensation instruction is triggered and re-executed until the closed-loop condition is met, including: If there are execution items marked as incomplete in the cross-system execution status set, then the compensation instructions corresponding to each incomplete execution item are retrieved from the preset compensation rule base to obtain the subsystem identifier set to be compensated and the corresponding compensation instruction execution sequence. Based on the state dependencies between the target subsystems, the execution sequence of the compensation instructions is dynamically adjusted in timing to obtain an executable set of compensation instructions; wherein, the dynamic timing adjustment includes: adjusting the compensation instructions with pre-dependent relationships to be triggered after the execution of their pre-dependent instructions. According to the executable compensation instruction set, the corresponding compensation instruction is reissued to each subsystem to be compensated; if a subsystem to be compensated does not return to the execution completion status within the preset response period, it is marked as an incomplete item again and a secondary compensation process is triggered. The execution status of each subsystem to be compensated is continuously polled until the execution status of all subsystems is marked as completed. The cross-system execution status set is then determined to meet the closed-loop condition, a closed-loop completion mark is output, and the compensation process is terminated.

10. A smart property management system, characterized in that, The system includes: The data fusion module is configured to acquire real-time raw data streams from various subsystems in the property scenario, perform standardized transformation and timestamp alignment on the real-time raw data streams, and merge them to generate a fused data snapshot. The event classification module is configured to extract anomaly feature vectors based on the fused data snapshot, determine the priority label of the event based on the anomaly feature vectors, and generate an event classification result carrying category label and priority label; The rule matching and instruction generation module is configured to retrieve trigger rules that match the event classification result from a pre-established cross-system rule engine; if a matching trigger rule exists, the trigger rule is activated to generate a set of linkage instructions containing the target subsystem identifier, action type, and execution sequence. The instruction issuance and receipt receiving module is configured to parse the linkage instruction set, issue action instructions to each target subsystem according to the parsed target subsystem identifier and action type, and receive execution receipts from each target subsystem. The closed-loop verification and compensation module is configured to compare the execution receipt with the preset completion conditions. If the execution receipts of all target subsystems meet the preset completion conditions, the linkage response link is determined to be closed and complete. If there is a target subsystem that does not meet the preset completion conditions, a compensation instruction is triggered and re-executed until the closed-loop conditions are met.

Images