Comprehensive management method and system for smart park

Abstract

The invention relates to the related technical field of smart park comprehensive management, in particular to a smart park comprehensive management method and system. The method comprises the following steps: acquiring park space data and an Internet of Things equipment asset list, carrying out space equipment binding, multi-domain event probe configuration and acquisition cycle arrangement, and generating a park scene event flow structure; performing behavior, energy consumption and operation event node extraction and multi-domain event graph construction, and generating a target event set through rule matching and clustering division; business feature extraction and business process template matching are carried out, execution instance generation, task scheduling and system action issuing are carried out, and a process execution state record is generated; processing data summarization and strategy parameter calculation are conducted, and parameter updating of the multi-domain event graph and the process template is achieved. According to the invention, through multi-domain event fusion and closed-loop adaptive optimization, complex events can be intelligently identified, the business process is automated, the self-evolution ability of the system is improved, and the park management efficiency and the collaborative response level are significantly improved.

Description

Technical Field

[0001] This invention relates to the technical field of integrated management of smart parks, and in particular to a method and system for integrated management of smart parks. Background Technology

[0002] In the field of smart park integrated management technology, existing solutions typically build separate management systems around park spatial data and IoT device asset lists. These systems collect, store, and display behavior-related records, energy consumption-related records, and operation-related records separately, handling alarm triggering and business processing only within their respective systems. They lack a unified processing link that integrates spatial device binding, multi-domain event probe configuration, and the organization of collection cycles and anchor points. This results in limitations such as the fragmentation of behavior events, energy consumption events, and operation events, difficulty in forming a park scenario event flow structure, and unclear correspondence between business processes and underlying events. Existing methods largely rely on pre-defined rules within each business domain and the experience of management personnel, judging and distributing tasks to local data separately in decentralized systems. In park scenarios requiring unified analysis and scheduling based on cross-domain data, problems arise such as difficulty in timely correlation of multi-source data, inconsistent granularity of behavior, energy consumption, and operation event node extraction, and opaque triggering conditions for target events. These solutions fail to meet the stable implementation requirements for building and managing park scenario event flow structures based on park spatial data and IoT device asset lists. For the joint processing of event flow structures, multi-domain event graphs, target event sets, and process execution status record sets in park scenarios, existing technologies generally suffer from common shortcomings in areas such as the extraction of behavioral energy consumption operation event nodes, rule-based event association determination, business-oriented process template invocation, and policy updates. These shortcomings include fragmented links, reliance on manual intervention for data synchronization, and a lack of unified version management for cross-system configurations. As a result, it is difficult to form a continuous processing flow around data collection, event extraction, target event generation, task scheduling, and policy updates in smart park integrated management application scenarios. Consequently, the event flow structure in park scenarios is difficult to utilize continuously, the connection between the target event set and business processes is not tight, and the updates of multi-domain event graphs and process template parameters cannot reflect changes in park operations in a timely manner. This leads to problems of delayed response and insufficient collaboration in park operation management, energy consumption management, and behavior management. Summary of the Invention

[0003] To address the aforementioned technical problems, this invention provides a smart park integrated management method, comprising:

[0004] Acquire spatial data and an IoT device asset list for the park, bind spatial devices, configure multi-domain event probes, organize and process collection cycles and anchor point fields, and generate a park scene event flow structure.

[0005] Based on the event flow structure of the park scene, the system performs behavioral energy consumption operation event node extraction, multi-domain event graph generation, rule matching and clustering processing to generate a target event set.

[0006] Based on the target event set, business feature extraction and business process template matching are performed, and instance generation, task scheduling and system action issuance are executed to generate a process execution status record set structure.

[0007] Based on the process execution status record set structure, the system summarizes the disposal process data, calculates and processes the strategy update parameters, and performs multi-domain event graph and process template parameter update processing to generate event graph and strategy update result structure.

[0008] Furthermore, the list of spatial data and IoT device assets in the park includes:

[0009] The park spatial data includes the park boundary range, road and square areas, green areas, topographic elevation information, the outer contour of each building, floor structure, room partitions, and spatial location markings of major ancillary facilities.

[0010] The IoT device asset list includes a unique device identifier, device type, subsystem to which it belongs, device manufacturer and model, installation location description, network access method, application layer communication protocol parameters, access control identifier, and business domain identifier.

[0011] Furthermore, the process of extracting behavioral energy consumption operation event nodes, generating multi-domain event graphs, and performing rule matching and clustering to generate the target event set also includes:

[0012] Read the node set and edge set from the multi-domain event graph, perform combination matching on the nodes and edges, and when a set of nodes and edges that satisfy the pattern constraints is found, mark the set of nodes and edges as candidate subgraphs of rule hits, and assign candidate event identifiers to each candidate subgraph.

[0013] Furthermore, the process after rule matching is completed also includes:

[0014] For the candidate subgraphs that the rules hit and other graph structures that are not explicitly covered by the rules, the degree of association between nodes is calculated based on the node's time anchor point, spatial object number, session identifier, and edge relationship between nodes. Nodes with high degree of association, close spatiotemporal distance, and close business relationship are merged into the same event subgraph to divide the initial structure of the multi-domain event graph into a series of non-overlapping or partially overlapping event subgraphs.

[0015] Furthermore, the process after obtaining the event subgraph also includes:

[0016] The event subgraphs are summarized in terms of attributes and labels are calculated. The number of nodes, node type distribution, time window, set of spatial objects involved, and rule pattern identifiers of the subgraphs are extracted from the subgraphs. The event subgraphs are classified into risk levels and business impact types. For each event subgraph, a target event object is generated that includes a target event identifier, main spatial object number, time window, risk level label, and business impact label.

[0017] Furthermore, the process of summarizing the handling process data, calculating and processing the strategy update parameters, and performing multi-domain event diagram and process template parameter update processing to generate the event diagram and strategy update result structure also includes:

[0018] Copy the structure metadata and key configuration items of the current effective version to the candidate version structure, perform modification operations on the candidate version, and switch to the effective version after the candidate version passes the consistency check and runnability check, and transfer the original effective version identifier to the historical version list.

[0019] Furthermore, the operability verification process also includes:

[0020] Replay the historical target event set, extract representative events from the historical target event set, and re-execute rule matching and clustering, business feature extraction, business process template matching, process instance generation and task scheduling on the representative events to verify whether the target event set generation result and the business process instance generation result meet expectations.

[0021] Furthermore, the process of updating parameters for multi-domain event graphs and process templates also includes:

[0022] Filter out the parameter update subset of the multi-domain event graph, and parse the target edge identifier, target node identifier, suggested adjustment direction, suggested adjustment range, and applicable business scenario type for each parameter record; for parameter records involving edge weight adjustment, find the corresponding edge entries in the candidate version of the multi-domain event graph, and update their risk weight field, importance weight field, or similarity relationship weight field.

[0023] Furthermore, the process of updating parameters for multi-domain event graphs and process templates also includes:

[0024] Filter out the subset of process template parameter updates, locate the corresponding template entries in the candidate version process template knowledge base; for parameter records that suggest adjusting the task order, find the specified task node in the task node definition set of the template, update the order field of the task node to the new order value, and update its related preceding task list field.

[0025] Furthermore, a smart park integrated management system, applied to any of the methods described above, includes:

[0026] The spatial device binding and event flow generation module is used to access park spatial data and IoT device asset list, construct spatial object set and spatial device binding set, access multi-domain event probe configuration set, perform time anchor registration, spatial anchor binding and session number marking processing on collected data, form park scene event flow structure, and transmit park scene event flow structure to event classification and event graph construction module;

[0027] The event classification and event graph construction module is used to extract records related to behavioral events, energy consumption events and operational events from the event flow structure of the park scene, generate a set of behavioral, energy consumption and operational event nodes, parse, encode and associate the node attribute fields and spatiotemporal relationship fields in the set of behavioral, energy consumption and operational event nodes, construct the initial structure of the multi-domain event graph, and transmit the initial structure of the multi-domain event graph to the target event generation module.

[0028] The target event generation module is used to call a preset rule set in the initial structure of the multi-domain event graph, perform rule matching processing on the initial structure of the multi-domain event graph, obtain a set of candidate event subgraphs, perform clustering and label sorting processing on the set of candidate event subgraphs, generate a set of target events, and output the set of target events to the business process generation and execution module.

[0029] The business process generation and execution module is used to extract business feature fields and spatial fields from the target event set, generate a business process template matching request set, search and match the business process template matching request set in the preset business process template library to form a business process instance set, perform task splitting, sequential arrangement and permission verification processing on the business process instance set, issue control commands and interaction commands through communication connections with the park equipment control interface, park management interface, housekeeper self-service terminal and mobile application, record the action execution results and manual confirmation results, generate a process execution status record set structure, and output the process execution status record set structure to the closed loop feedback indicator summary module;

[0030] The closed-loop feedback indicator summary module is used to extract the processing time, equipment action records, alarm closing records, cost adjustment records and user feedback records from the process execution status record set structure, associate and collect them according to target events, spatial objects and business process instance identifiers to form the closed-loop feedback original indicator set, perform abnormal data removal and missing field filling on the closed-loop feedback original indicator set, and output the closed-loop feedback original indicator set to the event graph and strategy update module;

[0031] The event graph and strategy update module extracts key performance and risk fields from the original indicator set of closed-loop feedback, generates a strategy update parameter set, and updates the edge weights, node risk levels, and event label parameters in the initial structure of the multi-domain event graph according to the strategy update parameter set, forming an updated multi-domain event graph. It also updates the triggering conditions, task order, automatic execution flags, and timeout thresholds in the preset business process template library, generating the event graph and strategy update result structure. The event graph and strategy update result structure is then fed back to the event classification and event graph construction module and the business process generation and execution module for use in the subsequent multi-domain event graph construction and business process generation process.

[0032] The following are its main beneficial effects:

[0033] (1) By binding spatial devices, configuring multi-domain event probes, and organizing and processing collection cycle and anchor point fields, the park spatial data and IoT device asset list that were originally managed separately in different systems are uniformly mapped to the park scene event flow structure. Compared with the existing technology of independently collecting and displaying data in behavior management, energy consumption management and operation management systems, the fragmentation of multi-source data in time and space is reduced, so that when extracting behavior, energy consumption and operation event nodes, it no longer depends on manual comparison of data between multiple systems, thus forming a stable input foundation for the park scene event flow structure in the smart park comprehensive management scenario.

[0034] (2) By performing behavior, energy consumption, and operation event node extraction, rule matching, and clustering processing in the multi-domain event graph, behavior events, energy consumption events, and operation events are transformed from scattered alarms and scattered records into a structured set of target events. Compared with the existing technology that responds locally to a single alarm or a single threshold, the spatial, temporal, and business relationships between behavior events, energy consumption events, and operation events can be directly reflected in the multi-domain event graph. This allows the set of target events to carry multi-domain information in the event flow structure of the park scenario, which can be directly called by business feature extraction, business process template matching, and instance generation, thereby reducing the omissions and delays caused by manually splicing multi-source data.

[0035] (3) By summarizing the disposal process data and calculating the strategy update parameters based on the process execution status record set structure, the parameters of the multi-domain event diagram and the process template are updated and processed. The event diagram and strategy update results are fed back to the multi-domain event diagram and the business process template. Compared with the existing technology that relies on managers to manually adjust rules and processes based on statistical reports, this technology enables the multi-domain event diagram and process template parameter updates to form a traceable correspondence with the disposal process data in the process execution status record set structure. In the continuous operation of smart park comprehensive management, the generation logic of the target event set and the arrangement logic of matching the business process template and the instance generation can be synchronously adjusted with the changes in the process execution status record set structure. This reduces the problems of insufficient utilization of the park scene event flow structure and deviation between the target event set and actual business needs caused by long-term fixed rules and lagging process configuration. Attached Figure Description

[0036] Figure 1 A flowchart illustrating a smart park integrated management method provided in this application embodiment;

[0037] Figure 2 This is a structural block diagram of a smart park integrated management system provided in an embodiment of this application. Detailed Implementation

[0038] Example 1: Refer to Figure 1 This is a flowchart illustrating a smart park integrated management method provided in an embodiment of the present invention. The process may include at least steps S100-S400:

[0039] S100: Obtain park spatial data and IoT device asset list, bind spatial devices, configure multi-domain event probes, organize and process collection cycle and anchor point fields, and generate park scene event flow structure;

[0040] S200: Based on the event flow structure of the park scene, extract behavioral energy consumption operation event nodes, generate multi-domain event graphs, perform rule matching and clustering, and generate a target event set.

[0041] S300: Based on the target event set, perform business feature extraction, business process template matching, and execute instance generation, task scheduling, and system action issuance to generate a process execution status record set structure.

[0042] S400: Based on the process execution status record set structure, perform data aggregation of the disposal process, calculation and processing of strategy update parameters, and execute multi-domain event graph and process template parameter update processing to generate event graph and strategy update result structure.

[0043] Step S100 includes at least steps S110-S130:

[0044] S110. Obtain park spatial data and IoT device asset list, perform spatial object extraction processing, and obtain spatial device binding set;

[0045] In this implementation step, the park spatial data serves as one of the inputs, derived from the two-dimensional master plan, building information model data, geographic information system data, and spatial mapping data obtained during the park's construction and operation through drone aerial photography and ground laser scanning. This park spatial data includes at least the park's boundary range, road and plaza areas, green areas, topographic elevation information, the outer contours of each building unit, floor structures, room partitions, and spatial location markings of major ancillary facilities. The IoT device asset list serves as another input, jointly output by the park's IoT platform and asset management system. This list records for each physical device its unique identifier, device type, subsystem, manufacturer and model, installation location description, network access method, application layer communication protocol parameters, access control identifier, and business domain label. The system periodically retrieves or incrementally receives the aforementioned park spatial data and IoT device asset list from the digital twin server via the spatial data access module. When a data version number change or the addition of a building or device record is detected, the spatial object extraction processing flow of this step is automatically triggered. Simultaneously, the change log recording module records the time, reason, and participating data sources for each trigger, forming an auditable processing chain.

[0046] Specifically, the spatial object extraction process is executed by a spatial modeling engine deployed in the park management cloud platform. This engine first identifies the format of the park's spatial data in different formats and unifies the coordinate system, mapping 2D site plans, building information model data, geographic information system data, and survey point cloud data to a unified park coordinate system and constructing a basic spatial grid internally. Subsequently, according to the park's planning zoning rules, the spatial modeling engine segments individual buildings, outdoor public areas, and infrastructure areas. For each building, it divides it into building unit objects, floor objects, and room objects; for outdoor areas, it divides them into road sub-zones, plaza sub-zones, parking sub-zones, and green space sub-zones; and for infrastructure areas, it divides them into objects such as power distribution rooms, machine rooms, and garbage collection stations. During the extraction process, a unique spatial object number, name, spatial type, parent-child topological relationship, geometric boundary expression, and usage description are generated for each spatial object, forming a spatial object table. For 3D scene display requirements, the spatial modeling engine also adds texture mapping reference information to building facades and key indoor areas without changing the primary key structure of the spatial object table, serving as optional extended fields for subsequent 3D display.

[0047] Based on spatial object extraction, the device location parsing module reads device records one by one from the IoT device asset list. For device records that already contain precise coordinates, it directly locates the boundary of the spatial object in the unified park coordinate system based on the coordinates and establishes an association between the device and the matched spatial object. For device records that only contain a natural language description of the installation location, the device location parsing module performs word segmentation and pattern matching on the description field using a rule base and dictionary. It compares the building name, floor number, room number, and area name in the description with the name field in the spatial object table. When multiple candidate spatial objects exist, a distance-first or confidence-score strategy is used to select the best matching spatial object. At the same time, the matching text fragments and confidence values ​​during the parsing process are recorded in a temporary log for subsequent manual inspection or correction. In scenarios where the coordinates of some devices are inconsistent with the natural language description, the device location parsing module marks the record as pending manual confirmation and does not write it into the formal spatial device binding set. Instead, the record is output to the manual review queue, where maintenance personnel review it using 3D scenes and on-site photos before triggering the rebinding operation.

[0048] After completing the parsing of spatial objects and device locations, the binding relationship generation module creates a spatial device binding record for each parsed device. The spatial device binding record includes at least the device unique identifier, device type, business domain, spatial object number, spatial object type, relative position parameters of the device in the spatial object, device orientation parameters, device communication access parameters, device status data address, and configuration version identifier. Among them, the device unique identifier, spatial object number, business domain, and device communication access parameters constitute the minimum set of fields required for the core improvement of this invention. The remaining relative position parameters, orientation parameters, and 3D rendering related fields are preferred fields, used to render device locations with high precision in the digital twin 3D scene. The binding relationship generation module summarizes all binding records to form a space device binding set and stores the space device binding set in the space binding relationship database. At the same time, it assigns a joint version number of the current space data and device asset data to the space device binding set, records the version generation time and trigger source. When S120 extracts device records of each business domain from the space device binding set, it uses this version number to complete the configuration version management. The event graph and policy update result structure generated by S430 in the future achieves traceability and auditability of the evolution process by referencing the version number of the space device binding set.

[0049] In one embodiment, the smart park comprises two office buildings, one dormitory building, and one canteen. The park's spatial data originates from Building Information Modeling (BIM) files created during the architectural design phase and 3D scan data collected after construction. The IoT device asset list is derived from the security system, energy metering system, and property management system. Upon initial deployment, the spatial modeling engine imports this data, generating a spatial object table containing office buildings, dormitories, the canteen, roads, plazas, and parking areas. The device location resolution module completes initial binding based on the camera installation coordinates and the room markings of the power distribution room sensors. Subsequently, as a research and development building and several smart trash cans are added to the park, the asset management system outputs a new version of the IoT device asset list. Upon detecting the new building information, the spatial modeling engine re-extracts spatial objects, and the device location resolution module binds the new devices to the research and development building spatial objects and the trash collection area spatial objects according to rules, updating the version number of the spatial device binding set. Through this automatic triggering and version management mechanism, the spatial device binding set maintains continuous updates during park structural evolution and device changes, providing unified and stable spatial foundation data for subsequent multi-domain event probe configuration.

[0050] S120. Extract device records from each business domain from the space device binding set, perform multi-domain event probe parameter configuration processing, and generate a multi-domain event probe configuration set.

[0051] In this implementation step, the spatial device binding set comes from the output of S110 mentioned above. It contains the binding relationships between various IoT devices and spatial objects and is the sole device source for multi-domain event probe configuration processing. The system deploys a business domain segmentation module in the park management cloud platform. Combined with the business domain configuration table pre-maintained by the park management, the devices in the spatial device binding set are classified according to their respective business domains. The business domain configuration table at least distinguishes between security domain, energy consumption domain, operation settlement domain, and logistics service domain, and can be extended to include visitor service domain, parking management domain, and other extended business domains as needed for the project. The business domain segmentation module parses the business domain identifier and device type field in the spatial device binding record. It classifies devices such as cameras, access controllers, and all-in-one card gates into the security domain; devices such as electricity meters, water meters, gas meters, heating and cooling meters, and environmental monitoring probes into the energy consumption domain; devices and logical objects related to lease contracts and fee settlement interfaces into the operation settlement domain; and objects such as work order terminals, self-service terminals, and trash can status sensors into the logistics service domain. When a device is associated with multiple business domains, it generates multiple business domain device records and establishes a correspondence between these records and the original spatial device binding records through the business domain device record number, forming a set of device records for each business domain.

[0052] After completing the business domain division, the event probe configuration module performs multi-domain event probe parameter configuration processing for each business domain device record. In this invention, an event probe is defined as an event acquisition and conversion unit for a specific physical device or logical object, divided into two categories: physical event probes and logical event probes. Physical event probes interface with the data acquisition interfaces of physical devices such as cameras, access controllers, energy meters, and environmental sensors, responsible for acquiring real-time data from the underlying devices according to the configuration and converting it into standardized event entries. Logical event probes interface with the interfaces of business systems such as the lease contract management system, bill settlement system, and work order dispatch system, responsible for extracting business events such as contract status changes, bill status changes, and work order status changes from the business systems and converting them into standardized event entries as well. For security domain device records, the event probe configuration module configures video event probe parameters for each camera device, specifying the video stream access address, decoding method, behavior analysis algorithm link identifier, alarm event type list, and output field mapping rules. For access controllers and smart card gate devices, it configures access event probe parameters, specifying the card swipe record acquisition frequency, blacklist matching rules, and abnormal access judgment conditions. For energy consumption domain equipment records, the event probe configuration module configures the collection cycle, meter reading mode, data accuracy requirements, and over-limit detection rules for each energy metering device, and configures the sampling cycle, sampling time alignment strategy, and data smoothing processing parameters for environmental sensors. For the operation and settlement domain, the event probe configuration module configures contract event probes for each type of contract object, obtaining event records such as contract signing, lease commencement, rent adjustment, expiration, and renewal from the contract system interface; and configures billing event probes for bill objects, obtaining event records such as bill generation, payment, overdue, and reduction from the fee settlement system. For the logistics service domain, the event probe configuration module configures work order event probes for work order objects, collecting node events such as work order creation, dispatch, response, and follow-up, and configures interactive event probes for self-service terminals, collecting employee service operation behaviors on the terminals.

[0053] When configuring various event probe parameters, the event probe configuration module uniformly defines the event primary key field, time anchor field, spatial anchor field, device or object identifier field, event type field, and source system identifier field as the minimum field set for multi-domain event probe configuration. It also adds necessary extended fields for different business domains. For example, for the security domain, it adds a behavior analysis algorithm identifier field and a video clip index field; for the energy consumption domain, it adds a metering cycle identifier field and a reading unit field; for the operation and settlement domain, it adds a contract number field and a bill number field; and for the logistics service domain, it adds a work order number field and a service terminal number field. The event probe configuration module writes the above field definitions, collection strategies, alarm judgment conditions, and interface access parameters together into the event probe configuration record, forming a multi-domain event probe configuration set. Simultaneously, the event probe configuration module associates each event probe configuration record with the corresponding device record or logical object record in the spatial device binding set, ensuring that each event probe carries spatial object number and spatial object type information for spatial anchor binding during subsequent multi-domain event graph construction.

[0054] In one embodiment, for the aforementioned smart park including office buildings, dormitories, and a canteen, the business domain segmentation module automatically scans newly added device records after the space device binding set version is updated. It categorizes the newly added camera equipment on the roof of the R&D building into the security domain, the newly added water meters and cooling meters in the canteen into the energy consumption domain, the contract objects corresponding to newly signed long-term lease contracts into the operation settlement domain, and the newly added trash can overflow sensors into the logistics service domain. The event probe configuration module configures video event probes for the R&D building camera equipment based on preset templates, setting a high-frequency behavior analysis strategy during office hours and a key area loitering detection strategy at night; it configures energy consumption event probes for the canteen water meters and cooling meters, setting different collection cycles and abnormal fluctuation thresholds; it configures contract event probes for the new long-term lease contracts, binding the contract number and the leased floor space object number; and it configures logistics event probes for the trash can overflow sensors, setting the status collection cycle and overflow judgment conditions. In this embodiment, the multi-domain event probe configuration set updates its version number after the event probe configuration module completes the above configuration. Subsequently, when performing collection cycle integration and anchor point field sorting in S130, the statistical fields and configuration fields are directly read from the multi-domain event probe configuration set.

[0055] S130. Perform collection cycle integration and anchor point field sorting on the multi-domain event probe configuration set to generate the park scene event flow structure.

[0056] In this implementation step, the multi-domain event probe configuration set comes from the output of S120 mentioned above. It contains the collection strategies, field definitions, and spatial binding information of event probes in each business domain, and serves as the direct basis for constructing a unified event flow for the park. The collection scheduling module first scans all event probe records in the multi-domain event probe configuration set. Based on the collection period field, trigger condition field, and business domain field in each record, the event probes are divided into three categories: periodic collection event probes, change-driven event probes, and manually triggered event probes. For periodic collection event probes, the collection scheduling module constructs a unified collection time slice on the timeline, aligning different collection periods to a unified time anchor point for the park. For change-driven event probes, the collection scheduling module generates subscription relationships and callback configurations based on the change notification mechanism of the event source system. For manually triggered event probes, the collection scheduling module registers them in the manual operation interface and the automated script interface, recording the roles and conditions that can trigger the operation. The data acquisition and scheduling module integrates the above classification and scheduling information to form a data acquisition task plan, and then hands the data acquisition task plan over to the data acquisition execution engine running on the park IoT gateway cluster and cloud data access service. When the trigger time slice arrives or a change notification is received, the data acquisition execution engine connects to the corresponding device or business system according to the event probe configuration, pulls the underlying data and generates an initial event message.

[0057] During the data collection and execution process, the event standardization module reads the timestamp, device or object identifier, event type, and raw data fields from the initial event message output by the data collection and execution engine. Based on the field mapping rules in the multi-domain event probe configuration set, it converts the time, spatial, and status fields output by different systems and devices into unified format time anchor fields, spatial anchor fields, and event status fields. The time anchor field uses the park's unified time base, recording both the event occurrence time and the collection time. The spatial anchor field records the spatial object number, spatial object type, and optional spatial coordinate offset information corresponding to the event. The event status field records the event type, event source, and business domain information. The event standardization module also performs data cleaning on the raw data according to the configuration, including missing field filling, outlier marking, and field value range verification. Fields that cannot be normalized are recorded in the abnormal event log, marking the cause of the anomaly and the associated event probe configuration record for subsequent strategy optimization and data quality analysis. The standardized event message is written to the intermediate event buffer queue, with the event probe configuration version identifier and spatial device binding version identifier attached to the message, providing a basis for subsequent event tracing and configuration evolution analysis.

[0058] During the anchor field processing phase, the scene event construction module reads standardized event messages from the intermediate event buffer queue and performs logical verification and connection completion processing on the time anchor field and spatial anchor field. For multiple events occurring within consecutive time slices for the same spatial object, the scene event construction module sorts and aggregates the events according to time order and event type, identifies event sequences belonging to the same event session, and generates a session identifier field for each event session, writing this field into all event records belonging to the same session. For events involving multiple spatial objects simultaneously, such as cross-floor personnel movement events or cross-regional energy consumption linkage events, the scene event construction module calculates the event impact range based on the spatial object topology and records the relevant spatial object numbers in the event impact range field. Through the above processing, the scene event construction module generates park scene event records containing event primary key, time anchor field, spatial anchor field, session identifier field, event status field, and source configuration version identifier field, and continuously writes these event records into the event stream storage system in chronological order, forming a park scene event stream structure. The event flow structure of the park scene serves as the unified event input format in this invention. Its field definitions maintain a one-to-one correspondence with the subsequent construction of the behavior energy consumption operation event node set in S210. In S210, the system directly reads the event primary key, time anchor, spatial anchor, and event status fields from the park scene event flow structure to generate the behavior energy consumption operation event node set.

[0059] In one embodiment, for a smart park including office buildings, dormitories, and a canteen, the multi-domain event probe configuration sets the video event probe acquisition cycle of the centralized R&D building camera equipment to short time slices, the energy consumption event probe acquisition cycle of the canteen energy consumption meter to longer time slices, and the logistics event probe of the garbage bin overflow sensor to a change-driven mode. When constructing the acquisition task plan, the acquisition scheduling module schedules the camera acquisition tasks for each short time slice and the energy consumption meter acquisition tasks for each longer time slice, and configures state change subscription and callback notifications for the garbage bin overflow sensor. The acquisition execution engine executes the acquisition tasks according to the plan and receives callback notifications. The event standardization module converts camera behavior alarms, energy consumption readings, and garbage bin state changes into standardized event messages, filling in the time anchor field and spatial anchor field. The scene event construction module groups the events into multiple event sessions based on the office building space object number, the R&D building space object number, and the garbage collection area space object number, and writes them into the park scene event stream structure. Subsequently, in S210, the system generates behavioral event nodes, energy consumption event nodes, and logistics service event nodes based on the event flow structure of the park scene for abnormal loitering behavior at night in the R&D building, abnormal energy consumption fluctuations in the canteen, and overflowing garbage bins.

[0060] Step S200 includes at least steps S210-S230:

[0061] S210. Obtain the event flow structure of the park scene, perform event classification processing, and obtain the set of behavioral energy consumption operation event nodes;

[0062] In this implementation step, the event classification and processing module runs on the application service layer of the park's integrated management platform. This module uses the park scene event stream structure generated and stored in the event stream storage system in S130 as the sole input event source. It obtains newly added standardized event records through a message subscription mechanism or a timed scanning mechanism. Each event record in the park scene event stream structure contains at least an event primary key, a time anchor field, a spatial anchor field, a session identifier field, an event status field, and a source configuration version identifier field, and retains the business domain field to which the event belongs and the event source system identifier field. Specifically, the event classification and processing module first determines the processing mode according to the processing strategy configured by the park management. In high real-time scenarios, a streaming incremental processing mode is adopted, and classification is triggered synchronously when writing the event stream. In analysis periodic scenarios, a time window batch processing mode is adopted, and event records are pulled from the event stream in batches according to a fixed time window. At the start of the classification process, the module performs basic checks on the event records read from the event stream structure of the park scene, removes abnormal records with missing time anchors, inconsistent versions of spatial anchors and spatial device binding sets, or duplicate event primary keys, and writes the abnormal records to the classification abnormal log, recording the abnormal type and the associated event probe configuration number, so as to be analyzed later in the policy update phase.

[0063] After completing basic verification, the event classification and processing module identifies the business meaning of each qualified event record through a built-in event type mapping table and business domain mapping table. The event type mapping table is configured by park maintenance personnel during system initialization, based on the event coding rules of each subsystem. It maps behavior alarm codes output by the security subsystem to behavior event categories, readings and limit-breaking alarms output by the energy consumption metering system to energy consumption event categories, and status changes output by the contract management system, billing settlement system, and work order management system to operation event categories. It also supports mapping abnormal states related to logistics services to operation sub-categories. The event classification and processing module categorizes different types of events, such as camera device behavior alarms, access control records, energy consumption readings, billing status changes, contract status changes, and work order status changes, according to the event source system and event status field. Behavior-related events belonging to the security domain are grouped into the behavior event subset, metering and limit-breaking events belonging to the energy consumption domain are grouped into the energy consumption event subset, and contract, bill, work order, and service terminal interaction events belonging to the operation settlement domain and logistics service domain are grouped into the operation event subset. For novel events whose categories cannot be directly identified through the mapping table, the event classification processing module marks them as events to be identified and outputs them to the manual annotation queue. After the manual annotation is completed, the event type mapping table is updated, and the classification is performed again.

[0064] Furthermore, the event classification and processing module performs scene association analysis on classified events based on time anchor and spatial anchor fields. It aggregates behavioral events, energy consumption events, and operational events occurring within the same spatial object, adjacent spatial objects, or the same session identifier for subsequent construction of integrated behavioral, energy consumption, and operational event nodes. Internally, the module generates an event node object for each event. The minimum attribute set of the event node object includes the event primary key, event category identifier, business domain, time anchor, spatial object number, and session identifier. Optional attribute sets include fields such as event level, event source system, alarm level, associated device type, key business identifier, and metering value summary. The event classification and processing module maps the same event record to an event node object and assigns the object a behavioral node, energy consumption node, or operational node label based on the business domain and event category. A behavioral node represents abnormal human or object behavior generated by security equipment such as video analytics and access control; an energy consumption node represents energy consumption readings or anomalies generated by energy metering equipment; and an operational node represents status changes generated by operational systems such as contracts, bills, and work orders. After the above processing, the event classification processing module constructs a set of behavioral event nodes, a set of energy consumption event nodes, and a set of operational event nodes in memory or persistent storage, and logically merges the three types of node sets into a set of behavioral, energy consumption, and operational event nodes.

[0065] In a specific scenario, the event flow structure of a smart park during a certain nighttime period includes multiple abnormal loitering alarm events output by a camera on a certain floor of the R&D building, a sudden increase in load output by the electricity meter, and a newly created work order event in the work order system for "abnormal air conditioning in a certain laboratory of the R&D building". The event classification and processing module pulls the event records for that time period according to the time window, classifies the camera alarms as behavioral events, the electricity meter over-limit events as energy consumption events, and the newly created work order events as operational events through the event type mapping table, and binds the three types of events to the same floor space object number and the adjacent room space object number according to the spatial anchor point field. For each event, a behavioral event node, an energy consumption event node, and an operational event node are created and written into the behavioral, energy consumption, and operational event node set. Finally, the set of behavioral energy consumption operation event nodes output in this step serves as a unified node input. In subsequent S220, the multi-domain event graph generation and processing module reads the node attribute fields and spatiotemporal relationship fields to construct the initial structure of the multi-domain event graph. At the same time, the set of behavioral energy consumption operation event nodes can also be used in the closed-loop feedback phase of subsequent S400 to track the node update status and achieve the traceability of the event graph and policy update result structure.

[0066] S220. Extract node attribute fields and spatiotemporal relationship fields from the set of behavioral energy consumption operation event nodes, perform multi-domain event graph generation processing, and generate the initial structure of the multi-domain event graph.

[0067] In this implementation step, the multi-domain event graph generation and processing module runs on the graph analysis engine of the park's integrated management platform. It takes the set of behavioral energy consumption operation event nodes output from S210 as direct input, and simultaneously references the spatial object table and spatial device binding set established in S110, as well as the business association rule base configured in the park, to expand a single event node into a multi-domain graph structure containing spatial, temporal, and business relationships. Specifically, the multi-domain event graph generation and processing module first extracts attributes from each node object in the behavioral energy consumption operation event node set, reading basic attributes such as event category identifier, business domain, time anchor, spatial object number, session identifier, and event source system. These basic attributes are then organized into a set of node attribute fields, and a unique node identifier is generated for each node, serving as the primary key for the node in the multi-domain event graph. Based on this, the multi-domain event graph generation and processing module can add extended attribute fields such as event level, measurement value summary, and key business identifier to the node object according to business needs. However, the node unique identifier, event category identifier, business domain, time anchor point, and spatial object number constitute the minimum node attribute set of the multi-domain event graph generation and processing of this invention. These attributes are used to describe the basic position and business meaning of the node in the multi-domain event graph.

[0068] After extracting node attributes, the multi-domain event graph generation module generates spatiotemporal relationship fields based on the time anchor field and the spatial object number field. The module first uses the spatial object topology maintained in the spatial object table to determine whether two nodes are located in the same spatial object, a superior / inferior spatial object, or adjacent spatial objects. Nodes belonging to the same spatial object are marked as spatial co-locations, nodes in a parent-child hierarchy are marked as spatial hierarchical relationships, and nodes on adjacent spatial objects are marked as spatial proximity relationships. Subsequently, the multi-domain event graph generation module determines the temporal proximity and session association relationships between events based on the time anchor field and the session identifier field. Within the same session identifier, consecutive events are marked as time sequence relationships according to time order. Different behavior nodes and energy consumption nodes are marked as time predecessors and successors based on time differences. Time response relationships are set between operation nodes and behavior nodes, and energy consumption nodes, according to constraints in the business rule base. The module encodes the aforementioned spatial and temporal relationships into spatiotemporal relationship fields. These fields contain at least a relationship type identifier, an associated node identifier, and a relationship strength rating. The relationship strength can be determined by a range of values ​​from the rule base based on the temporal distance, spatial distance, or historical co-occurrence frequency between nodes, without the need to introduce specific mathematical expressions.

[0069] Understandably, after obtaining the node attribute fields and spatiotemporal relationship fields, the multi-domain event graph generation and processing module begins to construct the initial structure of the multi-domain event graph. In this invention, the initial structure of the multi-domain event graph is defined as a graph data structure composed of a node set and an edge set. The node set corresponds to each node object in the behavioral energy consumption operation event node set, and the edge set corresponds to the spatiotemporal and business relationships between nodes. The module first writes all behavioral event nodes, energy consumption event nodes, and operation event nodes into the graph node storage area. Each node records a node identifier, event category identifier, business domain, time anchor, spatial object number, session identifier, and optional extended attributes. Subsequently, the multi-domain event graph generation and processing module traverses the spatiotemporal relationship fields, creating a graph edge record for any pair of nodes with a relationship. The graph edge record includes at least a starting node identifier, a target node identifier, a relationship type identifier, and a relationship strength field. Relationship types cover spatial co-location, spatial proximity, spatial hierarchy, time series, time predecessor / successor, and session association. For business dependencies explicitly defined in the business rule base, such as a contract status change having an explanatory or constraining relationship with a certain type of energy consumption anomaly event, the multi-domain event graph generation and processing module will also generate business relationship edges based on the business rule base, connecting operation nodes with relevant behavior nodes or energy consumption nodes according to business dependency types. The field definitions of these business relationship edges are consistent with those of spatiotemporal relationship edges, but the relationship type field takes the business relationship identifier value, and the relationship strength field provides a level or range based on the rule base.

[0070] In one embodiment, for the aforementioned abnormal scenario in the R&D building at night, the multi-domain event graph generation and processing module reads behavioral event nodes representing nighttime loitering, energy consumption event nodes representing increased load, and operational event nodes representing newly created work orders from the behavioral energy consumption operational event node set. After extracting the node attribute fields, it determines through the spatial object table that the spatial object numbers of the three nodes belong to the same floor of the R&D building or adjacent rooms, generating spatial co-location edges. Based on the time anchor point field, it calculates that the occurrence time of the behavioral event precedes the energy consumption event, and the energy consumption event precedes the work order creation event, generating time predecessor and successor edges from the behavioral event to the energy consumption event and from the energy consumption event to the work order event. Simultaneously, based on the session identifier field or the rule in the business rule base that "work orders are automatically triggered by energy consumption anomalies," it generates business relationship edges from energy consumption nodes to operational nodes. The multi-domain event graph generation and processing module organizes the above nodes and edges into a connected subgraph and writes this subgraph as part of the initial structure of the multi-domain event graph into the graph database. Ultimately, the initial structure of the multi-domain event graph output in this step includes all behavioral nodes, energy consumption nodes, and operation nodes of the park within a specified time range or event range, as well as their spatiotemporal and business relationships. This initial structure of the multi-domain event graph is directly read by the rule matching and clustering partitioning module in subsequent S230 to generate the target event set. It can also be used to update the attributes of nodes and edges during the policy update process in subsequent S400.

[0071] S230. Perform rule matching and clustering on the initial structure of the multi-domain event graph to generate the target event set;

[0072] In this implementation step, the rule matching and clustering processing module runs on top of the multi-domain event graph analysis engine. It takes the initial structure of the multi-domain event graph output by S220 as input and, combined with the park's configured rule base, clustering configuration parameters, and risk label library, performs structured analysis on the multi-domain event graph to identify target event sets worthy of inclusion in business process orchestration. Specifically, the rule matching and clustering processing module first reads the node set and edge set from the initial structure of the multi-domain event graph. Based on the pattern descriptions in the rule base, it defines a series of candidate event patterns. Each event pattern consists of specific node combinations, relationship type combinations, and constraints. For example, one event pattern can be described as "within the same spatial object, within a short time window, there exists at least one high-level behavior node, one energy consumption anomaly node, and one operational complaint node connected by time predecessor / successor edges and business relationship edges." Another event pattern can be described as "within the same session identifier, there is a concentration of business relationship edges between multiple energy consumption anomaly nodes and multiple contract adjustment nodes." The rule matching and clustering partitioning module traverses the initial structure of the multi-domain event graph and performs combination matching of nodes and edges according to the pattern description. When a set of nodes and edges that satisfy the pattern constraints is found, the set of nodes and edges is marked as a candidate subgraph for rule matching, and a candidate event identifier is assigned to each candidate subgraph.

[0073] After completing rule pattern matching, the rule matching and clustering module further performs clustering, dividing the rule-hit candidate subgraphs and other graph structures not explicitly covered by the rules into a series of non-overlapping or partially overlapping event subgraphs. During clustering, the module calculates the degree of association between nodes based on their temporal anchors, spatial object numbers, session identifiers, and edge relationships. Nodes with high association, close spatiotemporal distance, and strong business relationships are merged into the same event subgraph, while nodes with low association, large spatiotemporal distance, or weak business relationships are divided into different subgraphs. Without introducing specific mathematical formulas, the degree of association can be evaluated using hierarchical rules based on the number of edges, relationship type, and historical co-occurrence frequency. For example, "node pairs with both spatial co-occurrence edges and business relationship edges are considered highly associated," and "node pairs with only temporal predecessor / successor edges are considered moderately associated." The rule matching and clustering module can be implemented in two ways: In technical solution one, the module first performs rule pattern matching, and then further subdivides each candidate subgraph into multiple sub-events based on the degree of association; in technical solution two, the module first performs clustering based on the degree of association on the entire multi-domain event graph, uses the clustering results as subgraphs, and then performs rule matching on each subgraph to determine whether there are target events that satisfy a specific pattern; in technical solution three, the module adopts a rule-first approach for some high-risk business domains and a clustering-first approach for low-risk or large-data-volume business domains, running the above two strategies in parallel within the same engine. Regardless of the approach adopted, the module will eventually obtain a set of event subgraphs, each containing several behavior nodes, energy consumption nodes, operation nodes, and the relationships between them.

[0074] After obtaining the event subgraph set, the rule matching and clustering module performs attribute summarization and label calculation for each event subgraph. The module extracts information from the subgraph, including the number of nodes, node type distribution, maximum and minimum time anchors, the set of spatial objects involved, the set of session identifiers involved, the types of relationships contained, and the matched rule pattern identifiers. Based on the risk label library, the module classifies the event subgraphs into risk levels and business impact types. Risk levels can be determined by factors such as the number of high-level alarms in behavioral nodes, the magnitude of anomalies in energy consumption nodes, and the types of complaints in operational nodes, using the rule library to provide a classification result. Business impact types can be categorized into security risks, energy consumption deviations, contract performance risks, cost disputes, and service quality anomalies. Based on the above calculation results, the rule matching and clustering module generates a target event object for each event subgraph. This target event object contains at least the following fields: target event identifier, main space object number, time window, node list reference, risk level label, and business impact label. The target event identifier, main space object number, time window, risk level label, and business impact label constitute the minimum set of fields required for subsequent business process template matching. The node list reference and rule hit information are preferred fields, which can be used for subsequent process instantiation and visualization. The module organizes all target event objects into a target event set and writes the target event set into the target event storage structure. It also records the initial structure version number of the multi-domain event graph and the rule base version number referenced during generation to support subsequent versioning adjustments to rules and event graphs in the S400 based on closed-loop feedback.

[0075] In one embodiment, for the aforementioned abnormal nighttime scenario in the R&D building, the initial structure of the multi-domain event graph contains a subgraph comprising nodes representing nighttime loitering behavior, nodes representing increased energy consumption due to increased load, and nodes representing newly created work orders. The rule matching and clustering module, based on the rule base's pattern of "abnormal nighttime behavior, abnormal energy consumption, and concentrated occurrence of work orders," marks this subgraph as a candidate subgraph for rule matching. During the clustering phase, multiple behavior nodes and energy consumption nodes within this subgraph are clustered into a single event subgraph based on temporal and spatial proximity. Subsequently, the module calculates the time window of this event subgraph as a certain period during the night, the main spatial object number as a certain floor of the R&D building, and the node types involved as behavior nodes, energy consumption nodes, and operation nodes. Based on the risk label library, the event is marked as a high-level security and energy consumption composite risk, and the business impact type is marked as a superposition of security risk and energy consumption deviation. The module generates the corresponding target event object and writes it into the target event set. Subsequently, in S310, the business feature extraction and processing module will read the main space object number, time window, risk level label, and business impact label fields of the target event object from the target event set, construct a business process template matching request set, and realize cross-step connection from the multi-domain event graph analysis results to the business process orchestration input. Simultaneously, in the closed-loop feedback phase of S400, the system can use the target event identifier to trace back the node list and rule hit information corresponding to the target event object, and update the rule base and multi-domain event graph parameters.

[0076] In summary, the technical effects of this step are as follows: By performing rule matching and clustering on the initial structure of the multi-domain event graph, a large number of heterogeneous behavior nodes, energy consumption nodes, and operation nodes scattered in the graph are combined into a set of target events with clear spatial range, time window, risk level, and business impact labels. This allows subsequent business process template matching and process instance generation to target events that have undergone comprehensive multi-domain analysis, rather than alarms from a single subsystem. Compared to the existing technology that manually filters alarms from subsystems one by one, this establishes a structured bridge between the event level and the business level, providing a unified and traceable target event input for business process orchestration and closed-loop management.

[0077] Step S300 includes at least steps S310-S330:

[0078] S310. Obtain the target event set, perform business feature extraction processing, and obtain the business process template matching request set;

[0079] In this implementation step, the business feature extraction and processing module runs on the business orchestration layer of the smart park integrated management platform. This module retrieves target event records to be processed from the target event set generated and stored in the target event storage structure in S230. Each target event record includes at least the following fields: target event identifier, main space object number, time window, risk level label, business impact label, reference to the list of involved nodes, version identifier of the associated multi-domain event graph, and rule base version identifier. Specifically, the business feature extraction and processing module reads target events in the target event set that are in the state of pending orchestration from the target event set through timed polling or event triggering, and constructs these target events into internal event objects in memory as input objects for this step. The module first performs format and version checks on the input target event objects. The checks include whether the target event identifier is unique in the current batch, whether the main space object number still exists in the latest space object table, whether the time window falls within the unified time axis configuration range of the park, and whether the risk level label and business impact label are consistent with the label dictionary in the current rule base version. For target events that fail the checks, the business feature extraction processing module records them in the abnormal event queue and adds an abnormal status mark to the target event set, and they do not participate in the subsequent business feature extraction process.

[0080] After completing the basic verification, the business feature extraction and processing module extracts core features directly related to the business process selection from the target event records and the initial structure of the multi-domain event graph for each target event that passes the verification. These core features include at least the target event identifier, main space object number, time window start and end information, risk level label, business impact label, set of involved business domains, and set of participating entity types. The set of involved business domains is automatically derived based on the node types covered by the target event. For example, when both behavioral and energy consumption nodes exist, the set includes security and energy consumption domains; when both operational nodes exist, the set also includes operational settlement or logistics service domains. The set of participating entity types is automatically derived based on information such as contract parties, leasing units, and responsible departments referenced in the node list, and is recorded as categories such as park management, tenants, and third-party service providers. The business feature extraction and processing module can also parse the key equipment types and quantities associated with the target event from the initial structure of the multi-domain event graph, summarizing this information into an equipment overview field for subsequent selection of equipment control actions to be linked in the business process template. For parks that require it, a business feature extraction and processing module can be configured to synchronously read the lease contract attributes corresponding to the main space object number from the contract management system and the lease file system. These attributes include the remaining time in the contract period, the unit rent, and the service level terms, forming contract attribute fields to support the subsequent matching of fee-related process templates.

[0081] Furthermore, after extracting the aforementioned core fields, the business feature extraction and processing module categorizes the target events into business scenarios according to the park's preset scenario classification rules. These scenario classification rules are stored in a business scenario rule base, including typical scenario names, corresponding risk level combinations, business impact tag combinations, time window features, and spatial range features. For example, the rule base can define scenarios with abnormal nighttime behavior accompanied by abnormal energy consumption as nighttime collaborative handling scenarios, scenarios with prolonged high energy consumption during peak hours but no security anomalies as daytime energy consumption adjustment scenarios, and scenarios with concentrated complaints and billing disputes as fee dispute handling scenarios. The business feature extraction and processing module matches each target event against the business scenario rule base, based on its risk level tag, business impact tag, time window start and end information, and main spatial object number. Target events that meet a certain scenario rule are marked as the corresponding business scenario type and recorded in the business scenario type field. If a target event simultaneously meets multiple scenario rules, the module selects the scenario with the higher priority as the primary business scenario type based on scenario priority configuration, and records the secondary scenario type in the auxiliary scenario field for subsequent selection of templates containing extended sub-processes during the process template matching stage.

[0082] In one embodiment, for the aforementioned target event consisting of abnormal nighttime behavior, abnormal energy consumption, and newly created work orders in the R&D building, the business feature extraction and processing module parses the following from the target event records: the main space object number is a certain floor of the R&D building; the time window is a certain period at night; the risk level label is high; the business impact label is the superposition of security risk and energy consumption deviation; the set of business domains involved is the security domain, energy consumption domain, and operation settlement domain; and the set of participating entity types is the park security department, energy management department, and specific tenants. The module, combined with the business scenario rule base, identifies that this combination of features matches the configuration of a nighttime collaborative handling scenario, sets the business scenario type field to a nighttime R&D building composite risk scenario, and marks the presence of important experimental equipment in the scenario. After completing the above classification, the business feature extraction and processing module constructs a business process template matching request object for each target event. The minimum field set of the request object includes the request identifier, associated target event identifier, main space object number, time window, risk level label, business impact label, business scenario type, and set of involved business domains; the optional field set includes the set of participating entity types, key equipment type overview, contract attribute field, and secondary business scenario field. The business feature extraction processing module aggregates all request objects into a business process template matching request set and writes it into the business process template matching request storage structure. Simultaneously, it records the status indicator of the target event having completed business feature extraction in the target event set. Finally, the business process template matching request set output in this step will directly serve as input to the subsequent business process template matching and instance generation processing module in S320, driving the matching process in subsequent steps through the event tag field and spatial field.

[0083] S320. Extract the event tag field and space field from the business process template matching request set, perform business process template matching and instance generation processing, and generate a business process instance set.

[0084] In this implementation step, the business process template matching and instance generation processing module runs on the process engine of the park's integrated management platform. This module reads request objects with a pending matching status from the business process template matching request set output by S310 and accesses a pre-built process template knowledge base. The process template knowledge base stores multiple types of cross-domain business process templates. Each template includes at least the following information: template identifier, set of applicable business scenario types, applicable risk level range, set of applicable business impact tags, definition of applicable spatial range, set of involved business domains, set of task node definitions, set of role definitions, set of automatically executable actions definitions, set of manually confirmed node definitions, and template version identifier. The business process template matching and instance generation processing module first extracts the event tag field and spatial field of each request object from the business process template matching request set. The event tag field includes risk level tags, business impact tags, business scenario type, set of involved business domains, and set of participating entity types. The spatial field includes the main spatial object number, spatial hierarchy information, and spatial importance level field. The module constructs a matching condition set based on these fields to retrieve suitable templates from the process template knowledge base.

[0085] Understandably, the business process template matching and instance generation module can employ various template matching schemes during implementation. In one technical solution, the module selects templates according to rule-based matching. Based on the pre-configured matching rules for each template in the process template knowledge base, it checks each event tag field and spatial field in the business process template matching request to see if they fall within the template's applicable scope. For example, it checks if the business scenario type matches one of the applicable business scenario types defined by the template, if the risk level tag is within the applicable risk level range defined by the template, if the set of involved business domains covers the set of mandatory business domains defined by the template, and if the spatial level corresponding to the main spatial object number belongs to the spatial level allowed by the template. If all key conditions are met, the template is considered a fully matched template; if only some conditions are met, the module can decide whether to use the template as a candidate template based on the park configuration and record the matching degree level. In another technical solution, the business process template matching and instance generation module can adopt a weighted scoring strategy, comprehensively scoring each candidate template according to dimensions such as tag overlap, business domain coverage, and spatial matching degree, and selecting the template with the highest score exceeding a preset threshold as the preferred template. For multiple templates with similar scores, the module can prioritize the newer version or sort them according to the preference rules configured by the park's operations and maintenance personnel. In some complex scenarios, the module can also decide whether to combine some templates into a composite process based on the set of participating entity types. For example, it can simultaneously generate security handling templates and energy consumption adjustment templates, and then build them into a composite process instance with multiple sub-processes linked in the subsequent instance generation stage.

[0086] After template selection is completed, the business process template matching and instance generation module constructs a business process instance based on the selected template and the business process template matching request object. The construction process includes binding the target event, instantiating task nodes, instantiating participating roles, and generating a cross-system action list. Specifically, the module first creates a new process instance record for each template, generates a process instance identifier field, and writes the associated target event identifier, main space object number, time window, business scenario type, and template version identifier into the basic information of the process instance. Subsequently, according to the task node definition set in the template, each logical task node is copied as an instance task node. The instance task node records fields such as instance task identifier, belonging process instance identifier, task order, list of preceding tasks, associated business domain, default execution system, whether automatic execution is required, and whether manual confirmation is required. When instantiating participating roles, the module matches the set of participating subject types in the request object and the park's organizational structure configuration according to the business process template, and maps the role placeholders in the template to specific organizational units or positions. For example, the security manager role in the template is mapped to the security team leader of the responsible floor, the energy management role is mapped to the duty personnel of the energy management center, and the tenant contact person role is mapped to the floor administrator or designated contact person of the tenant corresponding to the main space object number.

[0087] Furthermore, during instance generation, the business process template matching and instance generation module generates a system action list based on the set of automatically executable actions defined in the template, binding each automatically executable action to a specific subsystem interface and device object. For example, for an action requiring adjustment of air conditioning settings, the module locates the corresponding air conditioning control point in the energy management subsystem based on the device overview field and device space binding relationship, and records the target device identifier, target operating parameters, and execution priority in the system action list. For an action requiring adjustment of access control policies, the module locates the corresponding access control point in the security subsystem based on the main space object number and area access control configuration. For actions requiring the generation of work orders, adjustment of bills, or updating of contract status, the module binds the corresponding actions to the service interfaces of the work order management system, bill settlement system, and contract management system, and records the source of the required input fields. For example, the risk level label of the target event will be mapped to the urgency field of the work order, and the business scenario type will be mapped to the work order category field. The module also pre-sets actions related to subsequent AI butler terminal interactions in the process instance, such as generating a task to notify tenants to confirm the energy consumption adjustment plan, binding it to the AI ​​butler terminal and mobile application front-end interface.

[0088] In one embodiment, for a business process template matching request in a complex risk scenario of a nighttime R&D building, the business process template matching and instance generation processing module selects a nighttime R&D building anomaly collaborative handling template from the process template knowledge base based on the business scenario type, risk level label, and the set of business domains involved in the request. This template includes a security patrol sub-process, an energy consumption adjustment sub-process, and a work order and expense recording sub-process. During instantiation, the module generates a unique process instance identifier for the template, sets the main space object number to the corresponding number of the R&D building, writes the target event identifier into the associated field, and generates several instance task nodes according to the task sequence defined in the template. For example, it generates tasks such as "remotely reviewing nighttime behavior video", "issuing patrol tasks", "issuing air conditioning load adjustment tasks", "generating temporary work orders and recording the energy consumption deviation of this event", and "sending event descriptions and energy-saving plan confirmation tasks to tenants". The above instance task nodes, along with the bound automatic execution actions and manual confirmation actions, constitute a business process instance. The business process template matching and instance generation processing module writes all generated instance records into the business process instance storage structure, thereby forming a business process instance set, providing complete instance input for subsequent task scheduling and system action issuance processing in S330. Ultimately, the business process instance set output in this step includes basic information, task node information, participating role mapping information, and system action list information for each process instance.

[0089] S330. Perform task scheduling and system action issuance processing on the business process instance set to generate a process execution status record set structure.

[0090] In this implementation step, the task scheduling and system action issuance processing module runs on the scheduling and execution layer of the park's integrated management platform. This module obtains process instance records with a pending execution status from the business process instance set output by the aforementioned S320, and interacts with the park's unified task queue component and the adapters of various business subsystems to realize the distribution of instance tasks, the issuance of control commands, and the collection of execution process status. Specifically, the task scheduling and system action issuance processing module first traverses each process instance in the business process instance set, constructs a task queue entry based on the instance task node information, and the task queue entry includes at least the following fields: instance task identifier, belonging process instance identifier, associated business domain, target execution system, target execution entity, list of preceding tasks, priority, whether to automatically execute flag, estimated completion time limit, and alarm threshold. Based on the preceding task list fields and the task order defined within the process instance, the module calculates whether each task currently meets the triggering conditions. For tasks where all preceding tasks have been completed and have not been marked as terminated, the status is set to schedulable, and the corresponding task queue entry is written to the unified task queue component.

[0091] For tasks marked as automatically executable, the task scheduling and system action distribution module selects the corresponding system adapter based on the target execution system field in the task queue entry. The system adapter then converts the system action list, pre-built during the business process instance generation phase, into specific control messages or service call requests, which are sent to the security subsystem, energy management subsystem, work order management system, billing settlement system, contract management system, or IoT access platform. After sending the request, the system adapter listens for the execution result response returned by the subsystem. The response includes the execution start time, execution end time, execution result status, and optional key parameter snapshots (e.g., post-execution device operating status, meter reading snapshot, work order number, or bill number). Based on the received execution result, the task scheduling and system action distribution module updates the execution status of the corresponding instance task node, changing the task status from pending execution to executing or completed. It records the execution start time and execution end time, and marks the exception type and error message when an exception or timeout occurs. Based on the task configuration, it decides whether to trigger an automatic retry action or generate a new manual processing task.

[0092] For tasks requiring manual intervention or those handled by the AI ​​Butler terminal and mobile application, the task scheduling and system action distribution module pushes task queue entries to the corresponding front-end systems. For park staff and managers, the module displays a task list through the operations and maintenance console or mobile application console, showing the process instance identifier, main space object number, business scenario type, risk level label, and detailed task description. It also provides an operation entry point, allowing personnel to perform actions such as confirmation, rejection, supplementary explanations, or uploading on-site images based on the situation. For tenant-side tasks, the module displays the task content through the AI ​​Butler self-service terminal and mobile application front-end, prompting tenants with the current event background and suggested energy consumption adjustments or cost handling solutions, guiding tenants to confirm or raise objections. These manual operations are then fed back to the task scheduling and system action distribution module through the front-end system. The module records this feedback as part of the task execution result, marking the executing entity as a specific person or tenant account, and updating the status of the instance task node. In different implementations, the task scheduling and system action distribution processing modules can adopt a centralized scheduling architecture, where a single scheduling core uniformly controls the distribution and status management of all tasks; or they can adopt a distributed scheduling architecture, where the task scheduling logic of different business domains is pushed down to the corresponding business domain sub-scheduling modules, and a unified scheduling core coordinates the dependencies between the sub-scheduling modules. Regardless of the architecture adopted, the instance task identifier, the process instance identifier, the execution status field, and the time field in the core field set remain consistent to support subsequent unified closed-loop feedback analysis.

[0093] In one embodiment, for the set of business process instances corresponding to the complex risk scenario in a nighttime R&D building, the task scheduling and system action issuance processing module reads instance task nodes such as "remote review of nighttime behavior video task," "issuance of patrol task," "issuance of air conditioning load adjustment task," "generation of temporary work order and recording of energy consumption deviation for this event task," and "sending event description and energy-saving solution confirmation task to tenant" from the business process instances. First, it issues the "remote review of nighttime behavior video task" to the on-duty security personnel. The execution status of the corresponding task is reported by the security personnel through the operation and maintenance console after completing the video review. After receiving the completion status of this task, the module automatically triggers the "issuance of patrol task"... The scheduling of "Check Task" and "Issue Air Conditioner Load Adjustment Task" sends access control policy adjustment requests and air conditioner setpoint adjustment requests through the security subsystem and energy management subsystem adapters, respectively, and updates the task status after obtaining the execution results. At the same time, the module automatically generates temporary work orders and energy consumption deviation records based on the energy consumption reading snapshots returned by the energy management subsystem, and writes the work order number and deviation record into the execution result field of the corresponding task. Finally, the module pushes the event description and energy-saving solution to the relevant tenants through the AI ​​Butler terminal. The tenants' confirmation or comments on the terminal are written into the process execution status record as the execution result of "Send Event Description and Energy-Saving Solution Confirmation Task to Tenant".

[0094] During the aforementioned automated and manual collaborative execution processes, the task scheduling and system action issuance processing module generates one or more execution status records for each task status change and system action execution. These records include fields such as process instance identifier, instance task identifier, associated target event identifier, execution subject identifier, execution start time, execution end time, execution result status, error category (if any), and key parameter snapshots. Additionally, the currently used process template version identifier and rule base version identifier are appended to trace the correspondence between each action and the current version configuration in subsequent analysis. After these execution status records are aggregated according to the process instance dimension, a process execution status record set structure is formed. This structure serves as the output data structure for this step. On one hand, it provides management personnel with a data source for process operation monitoring at the business orchestration layer. On the other hand, it is directly read by the closed-loop feedback raw indicator aggregation processing module in subsequent S410 to construct the closed-loop feedback raw indicator set, thereby driving the continuous optimization and parameter updates of the entire smart park integrated management method in the S400 module.

[0095] In summary, the technical effects of this step are as follows: By scheduling and processing the execution tasks and issuing system actions to the business process instance set, abstract business process instances are transformed into specific tasks that can be automatically and collaboratively executed across multiple systems, including the security subsystem, energy management subsystem, contract and settlement subsystem, work order management system, and AI butler terminal. Simultaneously, a process execution status record set structure containing snapshots of execution time, execution subject, and key parameters is generated. This allows subsequent closed-loop feedback analysis to reuse instance-level execution information on the same data structure. Compared to the existing technology of manually recording the execution status of each subsystem in a decentralized manner, this step forms a complete and reusable foundation in terms of consistent recording of process execution trajectories and traceability of cross-system actions.

[0096] Step S400 includes at least steps S410-S430:

[0097] S410. Obtain the process execution status record set structure, perform data aggregation and processing of the disposal process, and obtain the closed-loop feedback original indicator set.

[0098] In this implementation step, the closed-loop feedback aggregation unit operates in the data analysis layer of the smart park integrated management platform. The closed-loop feedback aggregation unit reads the execution status records corresponding to the completed business process instances from the process execution status record storage structure generated and stored in the aforementioned S330, according to a preset scheduling cycle or event triggering conditions. Specifically, the closed-loop feedback aggregation unit first groups the process execution status record set structure based on the process instance identifier field, aggregating multiple instance task execution records belonging to the same business process instance into a process-level handling trajectory set. Each instance task execution record includes at least the following fields: instance task identifier, associated target event identifier, business domain, execution subject identifier, execution start time, execution end time, execution result status, error category, key parameter snapshot, process template version identifier, and rule base version identifier. The closed-loop feedback aggregation unit performs integrity checks on the grouping results. Process instances that are still in execution are not included in this round of aggregation. For process instances that have exceeded the preset maximum execution time but have not received all task results, timeout flags and missing task list fields are added to the record, and the process instance handling trajectory set is marked as an incomplete closed loop type for differentiation during subsequent strategy updates.

[0099] After the processing trajectory set is constructed, the closed-loop feedback aggregation unit summarizes and calculates the original execution status records for each process instance in both time and task dimensions. In the time dimension, the closed-loop feedback aggregation unit obtains the total processing time range for the process instance based on the start time of the first task and the end time of the last task. It then calculates the execution duration distribution for each type of task based on the start and end time fields of each instance's tasks, such as the duration of security sub-process tasks, energy consumption adjustment sub-process tasks, and work order generation and cost recording sub-process tasks, and records these as process-level time indicator fields in the summary results. In the task dimension, the closed-loop feedback aggregation unit, based on the execution result status and error category fields, counts the number of successful tasks, failed tasks, automatically executed tasks, manually participated tasks, and tasks requiring retries in the process instance. This data is then broken down by business domain category to obtain task completion indicators for the security domain, energy consumption domain, operation settlement domain, and logistics service domain. For tasks involving AI butler terminal interaction, the closed-loop feedback summary unit will also count the number of tenant responses, the response time range, and whether there are any tenant rejections or objections, and write these statistical results into the tenant interaction-related fields.

[0100] Furthermore, the closed-loop feedback aggregation unit aggregates indicators related to energy consumption, carbon emissions, and costs based on the key parameter snapshot field. Specifically, for records with energy consumption reading snapshots in the task execution status record, the closed-loop feedback aggregation unit groups by process instance, reconstructs the energy consumption readings at each time point before and after the event handling into an energy consumption trajectory in chronological order, and statistically analyzes the differences of key nodes in the trajectory to obtain the energy consumption change field associated with the process instance; in scenarios with carbon emission factor configuration, the closed-loop feedback aggregation unit converts the energy consumption change into carbon emission change based on the energy consumption trajectory and the park's carbon emission factor configuration dictionary, generating a carbon emission change field; for instance task records related to cost adjustments, the closed-loop feedback aggregation unit extracts the cost adjustment amount, discount amount, or penalty amount associated with this event from the key parameter snapshot, and writes it into the total cost adjustment field after accumulating it at the process level. For execution status records containing service evaluations or satisfaction scores, the closed-loop feedback aggregation unit aggregates them into a satisfaction level field based on the evaluation options or scores, and statistically analyzes the proportion of satisfied, average, and dissatisfied entries at the process level to form the satisfaction indicator field corresponding to this process instance.

[0101] In one embodiment, for the aforementioned business process instance corresponding to the complex risk scenario of the nighttime R&D building, the closed-loop feedback aggregation unit retrieves all task execution records associated with the process instance identifier from the process execution status record set structure. These records include tasks such as remotely reviewing nighttime behavior videos, issuing patrol tasks, issuing air conditioning load adjustment tasks, generating temporary work orders and recording energy consumption deviations, and sending event descriptions and energy-saving solution confirmations to tenants. The closed-loop feedback aggregation unit calculates the handling time of the security sub-process based on the execution time of the remote review of nighttime behavior videos and the issuance of patrol tasks. It calculates the start time and effective time interval of the energy consumption adjustment action based on the execution time of the issued air conditioning load adjustment task and the returned snapshot of the operating parameters. It calculates the energy consumption change based on the energy consumption reading difference field in the snapshot of the key parameters of the generated temporary work order and recorded energy consumption deviation task. Finally, it extracts the difference in estimated costs before and after the event from the execution records of the settlement system bound to the process and stores the cost change in the corresponding field. For tasks involving sending event descriptions and energy-saving solution confirmations to tenants, the closed-loop feedback summary unit compiles statistics on the tenant's confirmation time, whether any objections were raised, and the final confirmation opinion, recording these as the tenant response time field and the tenant response type field for use in subsequent policy updates.

[0102] Understandably, in large-scale park scenarios, the number of process execution status records may increase dramatically over time. The closed-loop feedback aggregation unit can process data using two methods: incremental aggregation and windowed aggregation. In incremental aggregation, the unit only processes newly added process execution status records since the last scheduling in each scheduling cycle. It maintains a persistent intermediate result structure of the processing trajectory for each process instance, and outputs complete closed-loop feedback raw indicators all at once when the process instance enters the final state. In windowed aggregation, the unit defines time windows based on park management strategies, such as by day, week, or month. It performs centralized aggregation processing on all completed process instances within the window and adds a time window identifier field to the output record, facilitating subsequent selection of closed-loop feedback raw indicators at different time granularities by the S420. In both methods, the closed-loop feedback aggregation unit retains the process template version identifier and rule base version identifier in the aggregation results for subsequent tracking of the actual operational performance corresponding to a specific version strategy.

[0103] After summarizing the time, task, and energy cost dimensions, the closed-loop feedback summarization unit organizes the summary results of each process instance into a structured record. This structured record includes at least the following fields: process instance identifier, associated target event identifier, handling time indicator field, task completion indicator field divided by business domain, energy consumption change field, carbon emission change field (when carbon emission factors are configured in the park), total cost adjustment field, tenant satisfaction indicator field, process template version identifier, and rule base version identifier. All structured records of process instances constitute the closed-loop feedback original indicator set. The closed-loop feedback summarization unit writes the closed-loop feedback original indicator set into the closed-loop feedback original indicator storage structure and marks the corresponding process instance as having completed closed-loop summarization in the process execution status record storage structure. The output field of this step is named the closed-loop feedback original indicator set. This set will be used as input by the subsequent S420 strategy update parameter calculation and processing module to extract key performance fields and risk fields. It can also be directly accessed in the S400 module's operation monitoring interface to display the handling performance by version and business domain.

[0104] S420. Extract key performance fields and risk fields from the original indicator set of closed-loop feedback, perform strategy update parameter calculation and processing, and generate a strategy update parameter set.

[0105] In this implementation step, the strategy update parameter calculation module runs on the strategy decision layer of the smart park integrated management platform. This module outputs from the aforementioned S410 and stores the closed-loop feedback original indicator set in the closed-loop feedback original indicator storage structure. Based on the triggering conditions of the strategy optimization task, it reads the closed-loop feedback original indicator records that need to participate in this round of strategy update in batches. The triggering conditions can be a strategy evaluation command manually initiated by the park administrator on the strategy management interface, a periodic strategy evaluation task automatically triggered by the system based on time-based strategies, or an emergency strategy evaluation task automatically initiated by the risk monitoring module when multiple high-risk events or user dissatisfaction events occur consecutively. When reading the closed-loop feedback original indicator records, the strategy update parameter calculation module limits the scope of this evaluation based on the process template version identifier and rule base version identifier fields to avoid confusion caused by mixing data from different strategy versions in the same round of update calculation.

[0106] Specifically, the strategy update parameter calculation module first extracts key performance fields directly related to business performance from the original closed-loop feedback indicator set. These key performance fields include at least the total processing time of process instances, the processing time of each business domain sub-process, the proportion of automatically executed tasks, the proportion of failed tasks, the number of retried tasks, energy consumption changes, carbon emission changes (in scenarios with configured carbon emission factors), total cost adjustments, and tenant satisfaction indicators. Simultaneously, the strategy update parameter calculation module also extracts risk fields related to potential risks from the original closed-loop feedback indicator set. These risk fields include process instance identifiers marked as incompletely closed loops, the number of tasks that timed out, error category statistics, processing delay records for high-risk level events, and statistical results of repeatedly occurring similar target events. Through the joint selection of key performance fields and risk fields, the strategy update parameter calculation module forms the input data set required for this round of strategy update calculations.

[0107] After the key performance and risk fields are extracted and loaded into memory, the strategy update parameter calculation module groups and statistically analyzes these fields according to the strategy optimization rules configured in the park. Specifically, the strategy update parameter calculation module uses the process template identifier and business scenario type as the main grouping keys to divide the original closed-loop feedback indicator records into multiple template scenario combinations. Each combination corresponds to the performance of a specific business process template under a specific business scenario. Under the same combination, the strategy update parameter calculation module statistically analyzes the total processing time distribution of all process instances within the combination, the processing time distribution of each business domain sub-process, the distribution of energy consumption changes and carbon emission changes, the total cost adjustment distribution, and the tenant satisfaction distribution. It also calculates representative values ​​reflecting the central tendency, such as selecting the processing time value in the middle position after sorting as the typical processing time, and the energy consumption change range where most instances are clustered as the typical energy consumption change range. Finally, it statistically analyzes the percentage of satisfaction at each level based on the satisfaction index. In terms of risk, the strategy update parameter calculation module counts the frequency of various error categories, the proportion of timeout events, the proportion of incomplete closed-loop process instances, and the timeout situation of high-risk target events during the handling process. It aggregates the same type of target events that occur repeatedly to form a field of the number of times the same type of event occurs and a corresponding field of the stability of the handling result.

[0108] Furthermore, the strategy update parameter calculation module generates strategy update parameters based on the deviation between the aforementioned statistical results and the currently effective strategy parameters, using strategy optimization rules. These strategy optimization rules are jointly configured by park experts and system integrators during the system deployment phase. They include target ranges for performance indicators, tolerance ranges for risk indicators, and the types of strategy adjustment actions triggered by different combinations of indicators. For example, when the total processing time of a certain template scenario combination is significantly higher than the upper limit of the target range for multiple consecutive rounds, the strategy update parameter calculation module generates candidate parameters involving adjustments to task order or task automation configuration based on the rules. When the representative values ​​of energy consumption changes and carbon emission changes are consistently high while tenant satisfaction remains within an acceptable range, the module generates candidate parameters to increase the sensitivity of energy consumption alarms or increase the frequency of energy-saving strategy pilots. When the proportion of incomplete closed-loop process instances or the frequency of error categories exceeds the risk tolerance range, the module generates candidate parameters to add manual review nodes, extend the timeout time for some tasks, or add anomaly record fields. The candidate parameters mentioned above are generated with fields such as applicable process template identifier, identifier of relevant edges or nodes in the multi-domain event graph, suggested adjustment direction, and suggested adjustment range.

[0109] In one implementation, the strategy update parameter calculation module categorizes the generated candidate parameters into a multi-domain event graph parameter update subset and a process template parameter update subset based on their target objects. The multi-domain event graph parameter update subset is primarily used to adjust edge weights and node risk weights in the multi-domain event graph. For example, based on the statistical results of high-risk event handling delays, it increases the risk weight of edges related to specific spatial objects and specific behavior types, or adjusts the importance weight of energy consumption anomaly event nodes based on energy consumption change distribution. The process template parameter update subset is primarily used to adjust the execution order, automatic execution flags, task priorities, and alarm thresholds of task nodes in the process template. For example, when a certain type of security sub-process shows significant time consumption in manual approval steps in multiple instances, the aforementioned process template parameter update subset can suggest that the approval step be executed in parallel with some automatic actions, or allow the system to automatically approve according to rules when certain conditions are met. When the strategy update parameter calculation module forms the above two subsets, it adds a target version number field and an effective condition field to each parameter record. The target version number field is used to mark the multi-domain event graph version or process template version to which the parameter applies, and the effective condition field is used to indicate the scenario combination in which the parameter is applied, such as adjusting the priority of a security task only in the complex risk scenario of the R&D building at night.

[0110] In one embodiment, for the closed-loop feedback raw indicators of the aforementioned complex risk scenario in the R&D building at night, the strategy update parameter calculation module detected that the total handling time of the corresponding process template in multiple instances was significantly higher than the upper limit of the target handling time range preset by the park. Simultaneously, the energy consumption change decreased significantly within a certain period after the air conditioning load adjustment was initiated. Tenant satisfaction statistics showed that tenants generally accepted this type of energy-saving intervention. Based on this combined result, the strategy update parameter calculation module generated two types of candidate parameters in the process template parameter update subset. One type of parameter suggested triggering the air conditioning load adjustment task in advance and shortening its waiting time window for manual confirmation. The other type of parameter suggested parallel execution of the task of sending energy-saving solution confirmation to tenants and the task of generating temporary work orders to reduce the overall handling time. In the multi-domain event graph parameter update subset, based on the records of recurring high-risk events in this scenario, the strategy update parameter calculation module suggested increasing the risk weight related to abnormal nodes in the R&D building's nighttime behavior, thereby enhancing the attention paid to such events when generating the subsequent S230 target event set. The aforementioned candidate parameters are organized into the policy update parameter set and written into the policy update parameter storage structure. The policy update parameter set serves as the data structure output from this step for subsequent use by S430.

[0111] The output field for this step is named "Strategy Update Parameter Set." This set comprises two main parts: a multi-domain event graph parameter update subset and a process template parameter update subset. Each parameter record is bound to the source information of the original closed-loop feedback indicator, the target object identifier, and version control information. These parameters are parsed and applied sequentially during subsequent multi-domain event graph and process template parameter updates. The Strategy Update Parameter Set can be used by the S430's event graph and strategy update modules, and can also be viewed and manually filtered by operations and maintenance personnel in the park management backend interface. It constitutes the core intermediate product of data-driven strategy adjustment in the smart park integrated management method.

[0112] S430. Perform multi-domain event graph parameter update and process template parameter update processing on the strategy update parameter set to generate an event graph and strategy update result structure.

[0113] In this implementation, the event graph and policy update module operates between the configuration management layer and the inference engine layer of the smart park integrated management platform. This module reads policy update parameter records with a pending status from the policy update parameter set output by the aforementioned S420, and simultaneously accesses the currently effective multi-domain event graph storage structure and process template knowledge base. Upon startup, the event graph and policy update module determines the execution method for this round of updates based on the version management policy configured in the park. The version management policy at least specifies the update activation method (immediate or timed activation), update scope (entire park or partial spatial objects), and rollback policy (restoring to the previous version's rule base and event graph structure when the new version policy malfunctions). To ensure auditability between versions, before each update round begins, this module generates new candidate version identifiers for the multi-domain event graph and process template knowledge base, and copies the structural metadata and key configuration items of the currently effective version to the candidate version structure. All modification operations of the new version are executed on the candidate version. The new version is switched to the effective version only after passing consistency checks and necessary trial operation verifications.

[0114] Specifically, during the multi-domain event graph parameter update process, the event graph and strategy update module selects a subset of multi-domain event graph parameter updates from the strategy update parameter set, and parses each record's target edge identifier, target node identifier, suggested adjustment direction, suggested adjustment magnitude, and applicable business scenario type. For parameter records involving edge weight adjustments, the event graph and strategy update module searches for the corresponding edge entry in the candidate version of the multi-domain event graph, and updates the risk weight field, importance weight field, or similarity relationship weight field of the edge entry according to the suggested adjustment direction and suggested adjustment magnitude. For parameter records involving node risk level adjustments, the event graph and strategy update module searches for the corresponding event node or spatial node entry in the candidate version of the multi-domain event graph, updates the node's basic risk level field to the new level, and appends the source identifier of the most recent update to the node attribute field for subsequent tracing of the relationship between the node's risk level changes and closed-loop feedback indicators. If a parameter records the applicable business scenario type within a limited range, the event graph and strategy update module will add scenario filtering conditions during the update, and apply the parameter adjustment only to the subgraph structure that meets the business scenario type. For example, only adjust the weights of nodes and edges related to the complex risk scenario in the nighttime R&D building, without affecting the subgraph structure of other buildings or other business scenarios.

[0115] During the process template parameter update process, the event graph and strategy update module filters out a subset of process template parameter updates from the strategy update parameter set. Based on the process template identifier field and target version number field in each parameter record, it locates the corresponding template entry in the candidate version process template knowledge base. For parameter records that suggest adjusting the task order, the event graph and strategy update module searches for the specified task node in the template's task node definition set, updates the order field of the task node to the new order value, and simultaneously updates the related preceding task list field to maintain the integrity of task dependencies. For parameter records that suggest adjusting the automatic execution identifier or priority, the event graph and strategy update module modifies the automatic execution identifier field and priority field of the corresponding task node, so that the task scheduling and system action issuance processing module in S330 can identify the new automatic execution strategy and task priority in the business process instance generated by this template. For parameter records that suggest adjusting the alarm threshold or timeout configuration, the event graph and strategy update module modifies the configuration fields in the template related to alarm triggering or timeout determination, such as shortening the maximum allowable processing time for some tasks in nighttime scenarios or increasing the frequency of repeated alarms in high-risk scenarios. In some implementations, the event graph and policy update module can also add optional sub-process nodes or configure alternative handling paths for the process template based on the extended fields in the policy update parameter set, and mark these sub-process nodes in the template metadata as being enabled only under specific business scenario types.

[0116] Understandably, after completing the parameter modifications to the candidate version's multi-domain event graph and process template knowledge base, the event graph and strategy update module needs to perform consistency and operability verification on the new version structure. Consistency verification includes checking for isolated nodes or dangling edges in the multi-domain event graph, whether multiple edges point to non-existent nodes, and whether there are duplicate identifier conflicts. At the process template level, consistency verification includes checking whether the dependencies between task nodes form closed loops, whether there are paths that cannot reach the termination node, and whether there are task nodes with missing execution subjects or missing target execution systems. Operability verification can be performed by replaying historical target event sets in a sandbox environment. The event graph and strategy update module extracts a certain number of representative events from the historical target event set and re-executes the logic corresponding to S230, S310, S320, and S330 on the new version's multi-domain event graph and new version's process template. It checks whether the generated results of the target event set and the generated results of the business process instance meet expectations, confirming that no abnormal situations occur in key scenarios, such as missed target events or failure to generate business processes. After passing consistency and operability verification, the event graph and policy update module will switch the candidate version identifier to the effective version identifier and transfer the original effective version identifier to the historical version list. The historical version list retains the inheritance relationship and change summary information between versions, supporting subsequent auditing and rollback by version dimension.

[0117] In one embodiment, for the aforementioned complex risk scenario of a research and development building at night, the multi-domain event graph parameter update subset in the strategy update parameter set suggests increasing the risk weight of edges related to abnormal behavior in the research and development building at night and decreasing the weight of some low-risk behavior nodes. In the candidate version of the multi-domain event graph, the event graph and strategy update module increases the risk weight field of the edge connecting abnormal behavior nodes and energy consumption abnormal nodes in the research and development building at night, and adds an update timestamp indicating "from a certain strategy update parameter set" to the attribute field of that edge. Simultaneously, it slightly decreases the risk weight of some edges related to ordinary daytime personnel movement. The process template parameter update subset suggests performing the air conditioning load adjustment task in advance in the nighttime research and development building scenario, and parallelizing the task of sending energy-saving solution confirmation to tenants and the task of generating temporary work orders. Based on this, the event graph and strategy update module adjusts the sequence field of the corresponding task nodes in the candidate version of the nighttime research and development building anomaly collaborative handling template, moving the air conditioning load adjustment task node forward and updating the pre-task list of that task node. Simultaneously, it sets the same pre-task list for both the task of sending energy-saving solution confirmation to tenants and the task of generating temporary work orders, allowing both to be scheduled in parallel by the task scheduling and system action issuance processing modules during process execution. After consistency verification and playback verification of some historical nighttime events in the sandbox environment, the new multi-domain event graph version and template version were switched to the effective version.

[0118] After completing the version switch, the event graph and policy update module writes one or more structured records into the event graph and policy update result structure, consisting of the version identifier of the new version multi-domain event graph, the version identifier of the new version process template knowledge base, and the summary information of the policy update parameter records for this round of application. The event graph and policy update result structure includes at least the following fields: the mapping relationship between the old and new versions of the multi-domain event graph, the mapping relationship between the old and new versions of the process template, a summary of the object type and adjustment direction for each type of parameter adjustment, the policy update effective time, and the potential scope of impact. The event graph and policy update result structure serves as the output data structure for this step, allowing park operations personnel to view and audit it on the configuration management interface. It also serves as one of the inputs for subsequent closed-loop processing in S410. The closed-loop feedback summary unit in S410 can read the version information in the event graph and policy update result structure to associate the newly generated closed-loop feedback original indicators with the corresponding policy versions, thereby forming a complete policy evolution trajectory.

[0119] In summary, the technical effects of this step are as follows: By performing multi-domain event graph parameter update and process template parameter update processing on the policy update parameter set, an event graph and policy update result structure carrying version mapping and change summary information are generated. This enables the event reasoning logic and business orchestration logic in the smart park integrated management system to automatically complete structured policy evolution based on closed-loop feedback data during continuous operation, forming a traceable, rollbackable configuration version system that corresponds one-to-one with the running data. Under the premise of data-driven operation, a stable closed loop from event detection to policy adjustment is achieved.

[0120] Example 2: Figure 2 This diagram illustrates a structural block diagram of a smart park integrated management system according to an embodiment of the present invention. Figure 2 As shown, the structure may include:

[0121] The spatial device binding and event flow generation module 01 is used to access park spatial data and IoT device asset lists, construct spatial object sets and spatial device binding sets, access multi-domain event probe configuration sets, and perform time anchor registration, spatial anchor binding, and session number marking on the collected data to form a park scene event flow structure. This structure is then transmitted to the event classification and event graph construction module. Specifically, the spatial device binding and event flow generation module is deployed in the park's integrated management platform. It receives park spatial data and IoT device asset lists through communication interfaces with the geographic information system, building model management system, and IoT platform gateway. The park spatial data includes park boundary ranges, road and plaza outlines, building unit floor plans, height information, floor division information, room number information, and functional area attribute information. The module internally performs a spatial parsing process, converting the spatial data to a unified three-dimensional coordinate system based on the coordinate system type and projection parameters. Under this coordinate system, it segments spatial units such as building units, floors, rooms, machine rooms, public areas, and entrances / exits. For each spatial unit, it generates a spatial object identifier, geometric outline description, hierarchical relationship, and usage label, thus forming a spatial object set. The IoT device asset list is provided by the asset management system and the IoT platform device registry. It records fields such as device number, device type, owner, access protocol, deployment coordinates, building and floor description, installation height, orientation, and power supply circuit information for each device. After receiving the IoT device asset list, the module performs cross-judgment between the device deployment coordinates and the geometric contours in the spatial object set according to spatial matching rules. If the boundary deviation does not exceed a preset threshold, it generates binding records between the device and the spatial object and organizes these binding records into a spatial device binding set to form searchable spatial device binding entries.

[0122] The event classification and event graph construction module 02 is used to extract records related to behavioral events, energy consumption events, and operational events from the event flow structure of the park scene, generate a set of behavioral, energy consumption, and operational event nodes, parse, encode, and associate the node attribute fields and spatiotemporal relationship fields in the set of behavioral, energy consumption, and operational event nodes, construct an initial structure of a multi-domain event graph, and transmit the initial structure of the multi-domain event graph to the target event generation module. Specifically, the event classification and event graph construction module receives new event notifications through the message queue interface between the spatial device binding and the event flow generation module, reads the event records of the corresponding segment in the event flow structure of the park scene according to the offset position carried by the notification, and parses the event source probe identifier, the business domain to which it belongs, the time anchor point field, the spatial object identifier, and the anomaly marker field for each event record. The module maintains an event type mapping table, which is generated based on the multi-domain event probe configuration set during the system deployment phase. It establishes a fixed mapping between different probe identifiers and event categories such as behavior, energy consumption, and operation. Probe identifiers not in the mapping table are registered as unknown categories and written to the list to be configured, reminding operation and maintenance personnel to supplement the configuration and avoiding the long-term existence of unclassifiable event sources.

[0123] After the event classification and event graph construction module determines the event category based on the event type mapping table, it writes event records belonging to the behavior category into the behavior event buffer, event records collected by energy consumption metering devices into the energy consumption event buffer, and event records generated by logical probes such as contract probes, bill probes, and work order probes into the operation event buffer, supplementing the records with behavior identifier, energy consumption identifier, or operation identifier fields. The module then performs time sorting processing on the event records in the three buffers according to the time anchor field. For cases where multiple event sources exist under the same time anchor, it adds an event sequence number and a cross-source association marker to the record, providing a foundation for subsequent node attribute construction and spatiotemporal relationship construction. The behavior, energy consumption, and operation event node set is constructed based on this, generating corresponding node entries for each type of event. Node entries record attribute fields such as event category, spatial object identifier, device identifier, time anchor field, session number, anomaly marker field, and initial estimate of potential risk level.

[0124] After node entries are generated, the event classification and event graph construction module constructs spatiotemporal proximity relationships based on spatial object identifiers and time anchor point fields. Node entries belonging to the same spatial object with time anchor point differences within a preset window length are marked as temporally proximity groups. Node entries occurring between adjacent floors or adjacent spatial objects with time anchor point differences within another preset window length are marked as spatial proximity groups. The spatiotemporal group identifier field is then registered in the behavior energy consumption operation event node set. Based on the session number field, the module assigns behavior event nodes, energy consumption event nodes, and operation event nodes belonging to the same session to a unified session link. The start and end times of the session link and the number of nodes within the link are recorded in the node attribute field, facilitating the target event generation module to combine composite events from the same session perspective. The initial structure of the multi-domain event graph is built on the behavior energy consumption operation event node set. The event classification and event graph construction module generates a unique node identifier for each node entry and stores the node entries in the node storage area maintained by the graph structure management component. Simultaneously, based on the spatiotemporal proximity group identifier and session link information, edge relationship entries are created between the node storage areas. The edge relationship entry records the starting node identifier, ending node identifier, edge type field, and initial edge weight value. The edge type field indicates whether the edge belongs to a temporal adjacency relationship, spatial adjacency relationship, same session relationship, or other business constraint relationship. The initial edge weight value is assigned through a lookup table based on parameters such as event category combination relationship, time interval, and spatial distance. During the construction of the initial structure of the multi-domain event graph, the module performs encoding processing on the node attribute fields and spatiotemporal relationship fields, converting text-type fields into enumerated codes and mapping numerical ranges to discrete-level codes in a segmented manner. This reduces storage usage and facilitates rule matching by the target event generation module. After construction, the initial structure of the multi-domain event graph is written to the graph database and the in-memory graph structure. The event classification and event graph construction module sends a new graph update notification to the target event generation module via an interface. The notification carries the node range and session range involved in this update. The target event generation module reads the corresponding node and edge records from the initial structure of the multi-domain event graph based on this notification.

[0125] The target event generation module 03 is used to invoke a preset rule set in the initial structure of the multi-domain event graph, perform rule matching processing on the initial structure of the multi-domain event graph to obtain a set of candidate event subgraphs, perform clustering and labeling processing on the candidate event subgraphs to generate a target event set, and output the target event set to the business process generation and execution module. Specifically, the target event generation module and the event classification and event graph construction module share the graph database and in-memory graph structure where the initial structure of the multi-domain event graph is located. After receiving a new graph update notification from the event classification and event graph construction module, the module selects the subgraph region to be processed according to the node range and session range indicated in the notification. The target event generation module internally maintains a preset rule set, which is jointly configured by park management personnel and domain experts during the system deployment phase. Each rule describes a type of combined event pattern, including elements such as the required node category combination, node attribute field constraints, edge type combination, time interval range, spatial relationship category, and event quantity threshold. The module inputs the selected subgraph regions into the rule matching process in batches. During the rule matching process, it traverses the nodes and edges within the subgraph region, judges whether there are node combinations and edge combinations that meet the conditions according to the conditions described by the preset rule set, constructs candidate event subgraphs for combinations that meet the conditions, and records the matched rule number and the estimated matching confidence value.

[0126] After the candidate event subgraph set is formed, the target event generation module performs clustering processing on the candidate event subgraphs according to the needs of different business domains. For rules focusing on security risks, the module groups the candidate event subgraphs according to the proximity of spatial objects and the closeness of time anchor points, merging candidate event subgraphs located in the same building unit or adjacent floors and with overlapping times into the same cluster unit, forming candidate clusters to describe the comprehensive risks of local areas. For rules focusing on energy consumption anomalies and cost impacts, the module aggregates the candidate event subgraphs according to session number and contract identifier, focusing multiple candidate events belonging to the same contract period or the same tenant into the same cluster unit, facilitating the handling of similar events from the tenant's perspective in the subsequent business process generation stage. During the clustering process, the target event generation module calculates statistical fields such as the number of events, the number of spatial objects involved, the number of devices involved, and the number of tenants involved for each cluster unit, and records the corresponding cluster identifier in the candidate event subgraph set, constructing a mapping relationship between candidate event subgraphs and cluster units. Based on the clustering results, the target event generation module performs label processing, generating target event labels for each candidate cluster. During the tagging process, the module summarizes attributes such as event category distribution, maximum risk level estimate, earliest time anchor, latest time anchor, type of spatial object involved, type of equipment involved, type of contract involved, and type of cost adjustment involved from the candidate event subgraph. It then generates event type tags, risk level tags, business impact tags, and handling priority tags according to preset tagging rules. If a cluster corresponds to multiple rule matching results, the module sorts the multiple tag candidate combinations based on rule priority settings and risk level estimates, selecting the highest priority set of tags as the final tag combination for that cluster. Unused tag candidate combinations are saved in the tag history to provide reference data for subsequent strategy update phases. The module constructs a target event set using candidate clusters as entities, encapsulating each cluster identifier, corresponding node set, corresponding edge set, final tag combination, session number, and spatial object range as a target event entry, and writing it into the target event set structure.

[0127] After the target event set is generated, the target event generation module outputs the target event set to the business process generation and execution module through an internal API call. During the output process, the module divides the target event entries into different business domain queues according to the event type label and business impact label. Security-related target events are written to the security handling queue, energy consumption and carbon emission-related target events are written to the energy consumption management queue, and contract and fee-related target events are written to the operation settlement queue. The business process generation and execution module reads the target event entries from each business domain queue in priority order, and converts the event type label, risk level label, business impact label, spatial object scope, and associated session number in the target event entries into the input fields of the business process template matching request set, realizing the connection from the multi-domain event graph analysis stage to the business process orchestration stage. In another type of park operation scenario, the air conditioning branch of an office floor is under high load for a long time. At the same time, multiple tenants on the same floor submit temperature complaint work orders and generate fee dispute records within a short period of time. The event classification and event graph construction module forms a combination of nodes and edges covering several rooms and equipment on the floor in the initial structure of the multi-domain event graph. Based on a preset rule set, the target event generation module matches candidate event subgraphs from the combination that include nodes with abnormal energy consumption, multiple complaint work order nodes, and cost dispute nodes. Then, in the clustering stage, these candidate event subgraphs are grouped into the same clustering unit, and the cluster is marked as a high-priority operational risk event through label processing. Finally, a target event entry for the office floor is formed in the target event set, and the business process generation and execution module initiates the cross-departmental processing process in the subsequent stage.

[0128] The business process generation and execution module 04 is used to extract business feature fields and spatial fields from the target event set, generate a business process template matching request set, search and match the business process template matching request set in a preset business process template library to form a business process instance set, perform task splitting, sequential arrangement and permission verification processing on the business process instance set, issue control commands and interaction commands through communication connections with the park equipment control interface, park management interface, housekeeper self-service terminal and mobile application, record the action execution results and manual confirmation results, generate a process execution status record set structure, and output the process execution status record set structure to the closed-loop feedback indicator summary module. Specifically, the business process generation and execution module reads target event entries from the target event set passed in by the target event generation module, extracts business feature fields and spatial fields such as event type label, risk level label, business impact label, spatial object scope, session number, involved tenant identifier, and involved equipment identifier for each target event entry, and constructs a business process template matching request set accordingly. The pre-defined business process template library is maintained by park administrators during system deployment and operation. Each business process template in the library describes a type of handling and transition plan, including the range of triggering event types, applicable risk level range, applicable business impact category, set of participating roles, set of system interfaces involved, default task order, list of tasks that can be automatically executed, and list of nodes requiring manual confirmation. The business process generation and execution module searches the business process template library based on the business process template matching request set, filters the template set that meets the conditions of event type, risk level, and business impact, selects the target template according to the preset priority and tenant preference strategy when multiple candidate templates exist, and transfers the event to the manual registration queue when no template matches, so that the administrator can create a temporary template or manually arrange the handling steps.

[0129] After template selection, the business process generation and execution module generates a set of business process instances based on the target template content, instantiating one business process instance for each target event item. The instantiation process includes three stages: task splitting, sequence orchestration, and permission verification. In the task splitting stage, the module breaks down the macro-task into several atomic task items based on the task list and event characteristic fields in the template. Each atomic task item records information such as the executing entity's role, the target object being operated on, the system interface being called, and the expected completion time. In the sequence orchestration stage, the module constructs a task dependency graph based on the predecessor-successor relationships, parallel execution conditions, and mutual exclusion conditions between tasks. It then performs topological sorting on the task dependency graph, generating an executable task sequence and concurrent task groups, and records the set of predecessor and successor tasks for each task in the instance. During the permission verification phase, the business process generation and execution module obtains the list of currently available accounts and their permissions from the park's unified identity authentication service and permission management service. It matches the roles required for the task with the permission list, selects a qualified execution account or set of accounts for each task, performs additional multi-level permission verification for tasks involving cross-system calls and control of critical equipment, and suspends tasks that fail the verification and adds them to the list of abnormal tasks for administrator processing.

[0130] After the business process instance set is constructed, the business process generation and execution module issues control and interaction commands according to the task sequence through communication connections with the park equipment control interface, park management interface, concierge self-service terminal, and mobile application. For security handling tasks, the module issues view switching commands, access control restriction commands, and voice broadcast commands to cameras, access control controllers, and broadcasting equipment through the park equipment control interface, and pushes the corresponding event's 3D scene view and task panel to the park management interface. For energy management tasks, the module issues setpoint adjustment commands to air conditioning, lighting, and power distribution devices through the equipment control interface, and displays the energy consumption curves and budget changes before and after the adjustment through the park management interface. For operation settlement and service tasks, the module pushes interactive content such as pending confirmation items, fee adjustment notices, and questionnaires to tenants or employees through the concierge self-service terminal and mobile application, and collects confirmation results or supplementary information. During the instruction issuance process, the business process generation and execution module assigns a unique instruction number to each instruction. It collects action execution results and manual confirmation results from device feedback messages, management interface operation records, self-service terminal feedback records, and mobile application feedback records. These results are then written into the process execution status record set structure according to the instruction number and task number. The process execution status record set structure records fields such as task start time, task end time, execution account, device response status, manual confirmation status, and exception flags for each task. The business process generation and execution module updates the corresponding records after each task is completed and pushes the status record set corresponding to the process instance to the closed-loop feedback indicator aggregation module after the entire process instance is completed.

[0131] The closed-loop feedback indicator aggregation module 05 is used to extract handling time, equipment action records, alarm closure records, cost adjustment records, and user feedback records from the process execution status record set structure. These are then associated and aggregated according to target events, spatial objects, and business process instance identifiers to form a closed-loop feedback original indicator set. The module performs abnormal data removal and missing field completion on the closed-loop feedback original indicator set and outputs it to the event graph and strategy update module. Specifically, the closed-loop feedback indicator aggregation module reads task-level status records from the process execution status record set structure output by the business process generation and execution module, based on the process instance identifier and task identifier. It calculates the task processing time for each task status record based on the task start time and task end time registered therein, and calculates the handling time for the entire process instance based on the start time of the first task and the end time of the last task in the process instance. The calculation results are written into the handling time field of the closed-loop feedback original indicator set. The module simultaneously reads the device action records according to the device identifier and instruction number, extracts the device action type, execution result, response time, and exception flag fields, and associates these records with the corresponding process instance and target event entry to form a subset of device action records.

[0132] For alarm closure records, the closed-loop feedback indicator aggregation module filters alarm confirmation and alarm recovery task status records from the process execution status record set structure, extracts the alarm trigger time, alarm confirmation time, alarm recovery time, alarm source device identifier, and alarm level fields, registers the time interval between alarm confirmation and alarm recovery in the alarm processing duration field of the closed-loop feedback original indicator set, and retains complete timeline information in the alarm closure record. For cost adjustment records, the module synchronously obtains cost change data from the process execution status record set structure and the operation settlement system, extracts the cost adjustment direction, adjustment amount, involved billing period, involved tenant identifier, and adjustment reason fields, and aggregates the cost adjustment records under the corresponding entries in the closed-loop feedback original indicator set according to the target event identifier and process instance identifier. User feedback records are generated by the self-service terminal and mobile application. The closed-loop feedback indicator aggregation module accesses this feedback data through an interface, extracts fields such as feedback time, feedback channel, feedback content summary, satisfaction level or evaluation level, and associates user feedback records with corresponding process instances according to process instance identifier and tenant identifier.

[0133] After forming the initial closed-loop feedback raw indicators, the closed-loop feedback indicator aggregation module performs abnormal data removal and missing field completion processing on the raw indicator set. During abnormal data removal, the module identifies abnormal indicators such as zero handling time, negative task duration, equipment response time exceeding the reasonable upper limit, and alarm handling time far exceeding the normal range according to preset rules. The corresponding records are marked as abnormal and excluded from subsequent statistical calculations. Simultaneously, abnormal records are written to a separate abnormal directory for manual verification. During missing field completion, for process instances with missing handling time fields, the module derives the overall handling time using task-level time information; for process instances with missing equipment response records, it completes the equipment action records using equipment operation logs or periodic inspection records; for process instances with missing user feedback records, it assigns a default level to the user feedback field in the closed-loop feedback raw indicator set or marks it as a non-feedback state, facilitating the event graph and strategy update module's identification of data quality status when analyzing key fields. After completing the removal of abnormal data and the filling of missing fields, the closed-loop feedback indicator summary module groups and organizes the original closed-loop feedback indicator set according to the target event identifier, spatial object identifier, and business process instance identifier. It summarizes a set of handling time, equipment action records, alarm closure records, cost adjustment records, and user feedback records corresponding to each target event into a single item, and then outputs it to the event graph and policy update module through the interface as input data for subsequent parameter updates.

[0134] The event graph and strategy update module 06 is used to extract key performance fields and risk fields from the original closed-loop feedback indicator set, generate a strategy update parameter set, and update the edge weights, node risk levels, and event label parameters in the initial structure of the multi-domain event graph according to the strategy update parameter set to form an updated multi-domain event graph. It also performs parameter update processing on the triggering conditions, task order, automatic execution flags, and timeout thresholds in the preset business process template library to generate the event graph and strategy update result structure. This result structure is then fed back to the event classification and event graph construction module and the business process generation and execution module for use throughout the subsequent multi-domain event graph construction and business process generation processes. Specifically, the event graph and strategy update module reads closed-loop feedback entries from the original closed-loop feedback indicator set output by the closed-loop feedback indicator summary module according to the target event identifier. It performs statistical and normalization processing on the handling time field, alarm handling duration field, equipment action record, cost adjustment record, user feedback record, and other contents in each closed-loop feedback entry to form several key performance fields and risk fields. Key performance fields include average handling time, device response time statistics, completion time statistics by task type, and alarm handling time statistics. Risk fields include the percentage of high-risk events, the number of events causing cost disputes, and the number of negative user feedback. The module builds a strategy update parameter set based on these fields, forming a hierarchical parameter set for different event types, spatial regions, device types, and tenant categories.

[0135] After obtaining the strategy update parameter set, the event graph and strategy update module updates the edge weights, node risk levels, and event label parameters in the initial structure of the multi-domain event graph based on the strategy update parameter set. For target event types with long processing times and involving specific spatial areas, the module increases the risk weight in the corresponding edge relationships of such events, raising the node risk level by one or several levels. For event types with significantly shortened processing times and high satisfaction levels in user feedback records, the module decreases the risk weight in the corresponding edge relationships, appropriately lowering the node risk level. For event types that frequently trigger fee adjustment records or generate fee dispute records, the module adds fee-sensitive labels or operational dispute labels to the event label parameters to assign a higher business impact level to such events in the subsequent target event generation stage. The update process adopts a version number management strategy. The event graph and strategy update module generates a new version number before each parameter update and records the version numbers of the multi-domain event graph and business process template library before the update and the version numbers after the update in a version mapping table for easy audit traceability and rollback operations.

[0136] In addition to updating the multi-domain event graph parameters, the event graph and strategy update module also updates the trigger conditions, task order, automatic execution flags, and timeout thresholds in the preset business process template library based on the strategy update parameter set. For process templates where the critical performance field shows long-term delays, the module tightens the risk level threshold in the trigger conditions, adjusts the task order, moves critical tasks forward, and shortens redundant confirmation steps. For process templates where the equipment action records in the closed-loop feedback indicate that certain control actions are stable and reliable, the module adjusts the relevant tasks to automatic execution tasks in the automatic execution flag field and retains manual confirmation nodes in a few critical steps. For tasks that repeatedly time out in the closed-loop feedback, the module appropriately extends the timeout threshold or adds an early warning task to the template to prompt relevant personnel to intervene when the timeout is approaching. After updating the multi-domain event graph and business process template library, the event graph and strategy update module constructs an update result structure. This structure encapsulates the updated multi-domain event graph version number, business process template library version number, list of affected event types, list of affected templates, and a summary of strategy update parameters into update result entries. These entries are then fed back to the event classification and event graph construction module and the business process generation and execution module via an interface. Upon receiving the update results, the event classification and event graph construction module uses new edge weights and node risk levels when subsequently constructing the multi-domain event graph. The target event generation module references the new event tag parameters during rule matching and tag organization. The business process generation and execution module uses new triggering conditions, task order, and automatic execution flags during template matching and instance generation. This creates an adaptive management mechanism based on closed-loop feedback during long-term system operation.

Claims

1. A smart park integrated management method, characterized in that, include: Acquire spatial data and an IoT device asset list for the park, bind spatial devices, configure multi-domain event probes, organize and process collection cycles and anchor point fields, and generate a park scene event flow structure. Based on the event flow structure of the park scene, the system performs behavioral energy consumption operation event node extraction, multi-domain event graph generation, rule matching and clustering processing to generate a target event set. Based on the target event set, business feature extraction and business process template matching are performed, and instance generation, task scheduling and system action issuance are executed to generate a process execution status record set structure. Based on the process execution status record set structure, the system summarizes the disposal process data, calculates and processes the strategy update parameters, and performs multi-domain event graph and process template parameter update processing to generate event graph and strategy update result structure.

2. The method according to claim 1, characterized in that, The list of spatial data and IoT device assets in the park includes: The park spatial data includes the park boundary range, road and square areas, green areas, topographic elevation information, the outer contour of each building, floor structure, room partitions, and spatial location markings of major ancillary facilities. The IoT device asset list includes a unique device identifier, device type, subsystem to which it belongs, device manufacturer and model, installation location description, network access method, application layer communication protocol parameters, access control identifier, and business domain identifier.

3. The method according to claim 1, characterized in that, The process of extracting behavioral energy consumption operation event nodes, generating multi-domain event graphs, performing rule matching and clustering to generate the target event set also includes: Read the node set and edge set from the multi-domain event graph, perform combination matching on the nodes and edges, and when a set of nodes and edges that satisfy the pattern constraints is found, mark the set of nodes and edges as candidate subgraphs of rule hits, and assign candidate event identifiers to each candidate subgraph.

4. The method according to claim 3, characterized in that, The process after rule matching is completed also includes: For the candidate subgraphs that the rules hit and other graph structures that are not explicitly covered by the rules, the degree of association between nodes is calculated based on the node's time anchor point, spatial object number, session identifier, and edge relationship between nodes. Nodes with high degree of association, close spatiotemporal distance, and close business relationship are merged into the same event subgraph to divide the initial structure of the multi-domain event graph into a series of non-overlapping or partially overlapping event subgraphs.

5. The method according to claim 4, characterized in that, The process after obtaining the event subgraph also includes: The event subgraphs are summarized in terms of attributes and labels are calculated. The number of nodes, node type distribution, time window, set of spatial objects involved, and rule pattern identifiers of the subgraphs are extracted from the subgraphs. The event subgraphs are classified into risk levels and business impact types. For each event subgraph, a target event object is generated that includes a target event identifier, main spatial object number, time window, risk level label, and business impact label.

6. The method according to claim 1, characterized in that, The process of summarizing the handling process data, calculating and processing the strategy update parameters, and performing multi-domain event diagram and process template parameter update processing to generate the event diagram and strategy update result structure also includes: Copy the structure metadata and key configuration items of the current effective version to the candidate version structure, perform modification operations on the candidate version, and switch to the effective version after the candidate version passes the consistency check and runnability check, and transfer the original effective version identifier to the historical version list.

7. The method according to claim 6, characterized in that, The process of operational verification also includes: Replay the historical target event set, extract representative events from the historical target event set, and re-execute rule matching and clustering, business feature extraction, business process template matching, process instance generation and task scheduling on the representative events to verify whether the target event set generation result and the business process instance generation result meet expectations.

8. The method according to claim 1, characterized in that, The process of updating parameters for multi-domain event graphs and process templates also includes: Filter out the parameter update subset of the multi-domain event graph, and parse the target edge identifier, target node identifier, suggested adjustment direction, suggested adjustment range, and applicable business scenario type for each parameter record; for parameter records involving edge weight adjustment, find the corresponding edge entries in the candidate version of the multi-domain event graph, and update their risk weight field, importance weight field, or similarity relationship weight field.

9. The method according to claim 1, characterized in that, The process of updating parameters for multi-domain event graphs and process templates also includes: Filter out the subset of process template parameter updates, locate the corresponding template entries in the candidate version process template knowledge base; for parameter records that suggest adjusting the task order, find the specified task node in the task node definition set of the template, update the order field of the task node to the new order value, and update its related preceding task list field.

10. A smart park integrated management system, applied to the method described in any one of claims 1-9, characterized in that, include: The spatial device binding and event flow generation module is used to access park spatial data and IoT device asset list, construct spatial object set and spatial device binding set, access multi-domain event probe configuration set, perform time anchor registration, spatial anchor binding and session number marking processing on collected data, form park scene event flow structure, and transmit park scene event flow structure to event classification and event graph construction module; The event classification and event graph construction module is used to extract records related to behavioral events, energy consumption events and operational events from the event flow structure of the park scene, generate a set of behavioral, energy consumption and operational event nodes, parse, encode and associate the node attribute fields and spatiotemporal relationship fields in the set of behavioral, energy consumption and operational event nodes, construct the initial structure of the multi-domain event graph, and transmit the initial structure of the multi-domain event graph to the target event generation module. The target event generation module is used to call a preset rule set in the initial structure of the multi-domain event graph, perform rule matching processing on the initial structure of the multi-domain event graph, obtain a set of candidate event subgraphs, perform clustering and label sorting processing on the set of candidate event subgraphs, generate a set of target events, and output the set of target events to the business process generation and execution module. The business process generation and execution module is used to extract business feature fields and spatial fields from the target event set, generate a business process template matching request set, search and match the business process template matching request set in the preset business process template library to form a business process instance set, perform task splitting, sequential arrangement and permission verification processing on the business process instance set, issue control commands and interaction commands through communication connections with the park equipment control interface, park management interface, housekeeper self-service terminal and mobile application, record the action execution results and manual confirmation results, generate a process execution status record set structure, and output the process execution status record set structure to the closed loop feedback indicator summary module; The closed-loop feedback indicator summary module is used to extract the processing time, equipment action records, alarm closing records, cost adjustment records and user feedback records from the process execution status record set structure, associate and collect them according to target events, spatial objects and business process instance identifiers to form the closed-loop feedback original indicator set, perform abnormal data removal and missing field filling on the closed-loop feedback original indicator set, and output the closed-loop feedback original indicator set to the event graph and strategy update module; The event graph and strategy update module extracts key performance and risk fields from the original indicator set of closed-loop feedback, generates a strategy update parameter set, and updates the edge weights, node risk levels, and event label parameters in the initial structure of the multi-domain event graph according to the strategy update parameter set, forming an updated multi-domain event graph. It also updates the triggering conditions, task order, automatic execution flags, and timeout thresholds in the preset business process template library, generating the event graph and strategy update result structure. The event graph and strategy update result structure is then fed back to the event classification and event graph construction module and the business process generation and execution module for use in the subsequent multi-domain event graph construction and business process generation process.

Images