Intelligent patrol method and device based on cloud SOP dynamic plan and data capitalization

Abstract

According to the intelligent patrol method and device based on the cloud SOP dynamic plan and the data capitalization, a label authentication system is innovatively designed, and safe and reliable identity authentication is achieved through secret key dispersion and dynamic authentication. And a rule engine mechanism is constructed, and reasonable job management is established in combination with multi-dimensional features and conflict resolution. Urban fusion is introduced, and the effectiveness of collaboration is ensured through event processing and data sharing. According to the method, the defects of the traditional technology in the aspects of label authentication, rule engine, cross-domain collaboration and the like are effectively overcome, and technical guarantee is provided for intelligent patrol.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of data processing, in particular to an intelligent patrol method and device based on cloud SOP dynamic plan and data assetization. BACKGROUND

[0002] The existing intelligent patrol method has obvious deficiencies. The traditional system performs poorly in label authentication and security protection, and cannot effectively guarantee data security, affecting the reliability of patrol.

[0003] In addition, the existing technology has bottlenecks in rule engine and job management. Most systems lack a perfect feature extraction mechanism and rule conflict processing strategy, resulting in unreasonable job instructions.

[0004] The existing system has technical shortcomings in cross-domain collaboration. Lack of in-depth processing of urban events, it is difficult to achieve effective collaboration through data sharing, affecting emergency response. The solution to these problems is of great significance to improve the level of patrol management. SUMMARY

[0005] In view of the problems in the prior art, the present application provides an intelligent patrol method and device based on cloud SOP dynamic plan and data assetization, which can effectively solve the deficiencies of traditional technology in label authentication, rule engine and cross-domain collaboration, and provide technical support for intelligent patrol.

[0006] In order to solve at least one of the above problems, the present application provides the following technical scheme: In a first aspect, the present application provides an intelligent patrol method based on cloud SOP dynamic plan and data assetization, comprising: Construct a label authentication security link, collect patrol point data, deploy a near field communication label to the point, generate a scattered key based on a master key, write the scattered key into a label control unit, enable a dynamic ciphertext generation module, set a counter initial value, record the tenant identifier and point code of the label, write the identifier and code into a point database; read the dynamic parameters output by the label, calculate the label key according to the tenant identifier, verify the counter value and message authentication code of the dynamic parameters, remove the replay data based on a sliding window bitmap, generate a session token, and write the session token into an authentication database; Construct a job rule engine, collect multi-source environmental data, extract time dimension features, climate dimension features, space dimension features, load dimension features, and operation dimension features, search a job rule library based on the features, obtain a candidate rule set, calculate a rule priority matrix, resolve rule conflict relationships, generate a structured job instruction, issue the job instruction to a mobile terminal, collect execution data returned by the mobile terminal, extract execution scoring indicators, and write the scoring indicators into an evaluation database; A city-wide integrated gateway is constructed to access city platform events. Signature verification and timestamp protection are performed on the events, a standard event model is generated, affected areas are matched based on geofences, cross-domain collaborative instructions are generated, the collaborative instructions are broadcast to target tenants, mutual assistance execution data is collected, settlement entries are generated, the settlement entries are written to the audit database, the execution data is anonymized, and the anonymized execution data is written to the shared database.

[0007] Furthermore, it also includes: collecting patrol point data, constructing a key generation module, calculating the combined hash value of the tenant identifier and the key version number, extracting the master key from the key management system based on the hash value, performing key derivation calculation on the master key and the unique identifier of the point to generate a distributed key, encrypting and packaging the distributed key to generate a key configuration data packet, writing the configuration data packet into the control unit of the near-field communication tag, recording the initial configuration parameters of the tag, constructing a deployment record table containing the point code, tenant identifier, and configuration time, and writing the deployment record table into the point database; The control unit of the near-field communication tag is read, a dynamic ciphertext generation module is constructed, the dynamic ciphertext generation module is written into the tag storage area, the initial value of the counter of the dynamic ciphertext generation module is configured, an anti-tampering protection unit is constructed, the anti-tampering protection unit is written into the tag configuration area, the anti-tampering write protection mechanism is enabled, a security configuration table containing anti-tampering status, counter value, and protection parameters is generated, the integrity of the security configuration table is verified, and the security configuration table is written into the security database.

[0008] Furthermore, it also includes: reading the dynamic parameters output by the tag, constructing a key calculation module, inputting the tenant identifier and key version number into the key derivation function to generate a tag key, decrypting the tag key to obtain a counter value and a message authentication code, combining the counter value and the authentication code into an authentication data packet, constructing a verification record table containing authentication time, authentication location, and device identifier, and writing the verification record table into the authentication database; The system reads the verification record table, constructs a sliding window module, calculates the sliding range of the counter value, generates a window bitmap matrix, performs deduplication on the bitmap matrix, removes replay data, generates a session token, binds the session token to the device identifier, constructs an authorization record table containing the token identifier, validity period, and geofence, performs encryption signing on the authorization record table, and writes the authorization record table into the token database.

[0009] Furthermore, it also includes: constructing a multi-source data acquisition module, accessing meteorological monitoring data, traffic flow data, population density data, energy consumption monitoring data, and equipment status data, normalizing the monitoring data to generate a feature vector matrix, grouping the feature matrix by dimension, constructing an acquisition record table containing data type, acquisition time, and data source, and writing the acquisition record table into an environmental database; The feature matrix in the environmental database is read, a feature extraction module is constructed, time period features, temperature and humidity features, spatial distribution features, load level features, and activity status features are calculated, the features are combined into feature description vectors, the job rule base is retrieved based on the feature vectors, a similarity calculation unit is constructed, a candidate rule set is generated, and the candidate rule set is written into the rule database.

[0010] Furthermore, it also includes: reading a set of candidate rules, constructing a priority calculation module, quantifying and assigning values ​​to rule attributes, generating a rule scoring vector, converting the scoring vector into a priority matrix, detecting rule conflict items based on the priority matrix, constructing a conflict resolution unit, generating a conflict-free rule sequence, converting the rule sequence into a structured job instruction, digitally signing the job instruction, and sending the job instruction to a mobile terminal. The system reads the execution data returned by the mobile terminal, constructs a scoring calculation module, extracts quantitative indicators such as task completion rate, execution time, and operation standardization, generates an execution scoring vector, normalizes the scoring vector, constructs an evaluation record table containing execution time, execution location, and execution personnel, performs data verification on the evaluation record table, and writes the evaluation record table into the evaluation database.

[0011] Furthermore, it also includes: constructing a city event access module to receive meteorological events, fire events, traffic events, and emergency events pushed by the city platform, extracting event signature data, verifying the validity of the signature, constructing a timestamp verification unit to perform timestamp protection on the event, generating a standard event model that includes event type, severity, and impact period, and writing the standard event model into the event database; Read the standard event model, construct a geofence matching module, calculate the polygonal area of ​​the event's impact range, generate a spatial index matrix, match the affected parks and tenants based on the spatial index, construct a cross-domain collaborative instruction generator, convert the event model into collaborative instructions, group and encode the collaborative instructions, generate a tenant-oriented broadcast table, and write the broadcast table into the instruction database.

[0012] Furthermore, it also includes: reading tenant mutual assistance execution data, constructing a data integration module, extracting statistical data on mutual assistance duration, number of personnel, and equipment usage, generating a resource consumption matrix, converting the resource matrix into settlement entries, constructing a settlement record table containing mutual assistance number, execution time, and resource details, performing integrity verification on the settlement record table, and writing the settlement record table into an audit database; Read the mutual aid execution data, construct a data anonymization module, anonymize the fields of personnel identity information, equipment number, and location coordinates, generate an anonymized dataset, classify and label the anonymized dataset, construct a shared license table containing sharing scope, protection level, and authorization period, perform access control on the shared license table, and write the shared license table into the shared database.

[0013] Secondly, this application provides an intelligent patrol device based on cloud-based SOP dynamic contingency plans and data assetization, comprising: The communication encryption module is used to construct a secure tag authentication link, collect patrol point data, deploy near-field communication tags to the points, generate a distributed key based on the master key, write the distributed key into the tag control unit, enable the dynamic ciphertext generation module, set the initial value of the counter, record the tenant identifier and point code of the tag, and write the identifier and code into the point database; read the dynamic parameters output by the tag, calculate the tag key based on the tenant identifier, verify the counter value and message authentication code of the dynamic parameters, remove replay data based on the sliding window bitmap, generate a session token, and write the session token into the authentication database; The patrol operation module is used to build an operation rule engine, collect multi-source environmental data, extract time dimension features, climate dimension features, spatial dimension features, load dimension features, and operation dimension features, retrieve the operation rule library based on the features, obtain a set of candidate rules, calculate the rule priority matrix, resolve rule conflict relationships, generate structured operation instructions, send the operation instructions to the mobile terminal, collect the execution data returned by the mobile terminal, extract the execution scoring indicators, and write the scoring indicators into the evaluation database. The collaborative execution module is used to build a city-wide integrated gateway, access city platform events, perform signature verification and timestamp protection on the events, generate standard event models, match affected areas based on geofences, generate cross-domain collaborative instructions, broadcast the collaborative instructions to target tenants, collect mutual assistance execution data, generate settlement entries, write the settlement entries to the audit database, perform anonymization processing on the execution data, and write the anonymized execution data to the shared database.

[0014] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of the intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization.

[0015] Fourthly, this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization.

[0016] Fifthly, this application provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization.

[0017] As can be seen from the above technical solution, this application provides an intelligent patrol method and device based on cloud-based SOP dynamic contingency plans and data assetization. Through an innovative design of a tag authentication system, and by using key distribution and dynamic authentication, it achieves secure and reliable identity verification. A rule engine mechanism is constructed, combining multi-dimensional features and conflict resolution to establish reasonable operation management. Urban integration is introduced, ensuring the effectiveness of collaboration through event processing and data sharing. This method effectively solves the shortcomings of traditional technologies in tag authentication, rule engines, and cross-domain collaboration, providing technical support for intelligent patrol. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating the intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization in the embodiments of this application. Figure 2 This is a structural diagram of the intelligent patrol device based on cloud-based SOP dynamic contingency plans and data assetization in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the electronic device in the embodiments of this application.

[0020] Figure label: Electronic device 9600, central processing unit 9100, memory 9140, communication module 9110, input unit 9120, audio processor 9130, display 9160, power supply 9170, buffer memory 9141, application / function storage unit 9142, data storage unit 9143, driver storage unit 9144, antenna 9111, speaker 9131, microphone 9132. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] The acquisition, storage, use, and processing of data in this application comply with relevant laws and regulations.

[0023] In view of the problems existing in the prior art, this application provides an intelligent patrol method and device based on cloud-based SOP dynamic contingency plans and data assetization. It achieves secure and reliable identity verification through an innovatively designed tag authentication system, using key distribution and dynamic authentication. A rule engine mechanism is constructed, combining multi-dimensional features and conflict resolution to establish reasonable operation management. Urban integration is introduced, ensuring the effectiveness of collaboration through event processing and data sharing. This method effectively solves the shortcomings of traditional technologies in tag authentication, rule engines, and cross-domain collaboration, providing technical support for intelligent patrol.

[0024] To effectively address the shortcomings of traditional technologies in areas such as tag authentication, rule engines, and cross-domain collaboration, and to provide technical support for intelligent patrol systems, this application provides an embodiment of an intelligent patrol method based on cloud-based SOP dynamic plans and data assetization. See [link to relevant documentation]. Figure 1 The intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization specifically includes the following: Step S101: Construct a tag authentication security link, collect patrol point data, deploy near-field communication tags to the points, generate a distributed key based on the master key, write the distributed key into the tag control unit, enable the dynamic ciphertext generation module, set the initial value of the counter, record the tenant identifier and point code of the tag, and write the identifier and code into the point database; read the dynamic parameters output by the tag, calculate the tag key according to the tenant identifier, verify the counter value and message authentication code of the dynamic parameters, remove replay data based on the sliding window bitmap, generate a session token, and write the session token into the authentication database; This embodiment is designed for a real-world environment of nighttime patrols in a park, where staff use mobile devices to mark checkpoints along a pre-defined route. We first establish a secure tag authentication link: Patrol point data is retrieved from the asset management system, with fields including point code, geographic coordinates, tenant, equipment installation conditions, and risk level. To reduce construction errors, this embodiment generates a unique tag serial number and installation work order for each point before deploying the near-field communication tags. The installation app verifies GPS and tile orientation to prevent incorrect placement or obstruction of metal, which could lead to unstable reading distances. After the tag is powered on, it enters a configuration state. The cloud-based key management system maintains the master key by tenant. This embodiment uses a hash index to extract the master key from "tenant identifier + key version number," then calculates a distributed key using the unique point ID as a derivation factor. The distributed key is then encrypted and packaged by a hardware security module and written to the tag control unit. Considering the patrol scenario's preference for tamper-proofing, we enable the dynamic encrypted generation module on the tag side, initialize a monotonically increasing counter to c0, and write the tenant identifier, point code, and configuration time into the point database, forming a traceable deployment record.

[0025] In this embodiment, the static ID is not exposed over the air interface during terminal-tag interaction. When the operator's mobile phone approaches the tag, the tag outputs a one-time dynamic parameter frame containing the current counter value, random salt, and message authentication code. The mobile terminal retrieves the tenant identifier read from the cloud authentication service, calculates the tag key using the same derived function, and completes the verification link within the session. The logic here is: if the tag is indeed a configured device for the tenant and the location, then both the cloud and the tag can correctly reconstruct the authentication code using the same source key, and the counter should be greater than or equal to the value recorded in the last successful session. Before authentication, we check the location database to confirm that the tag is still valid, has not been reported lost or migrated, to prevent old tags from being misused.

[0026] The legality review of dynamic parameters in this embodiment is carried out in two steps. The first step is the counter check. Take out the counter value c reported by the tag and compare it with the most recently confirmed counter value c_last maintained by the server for this tag. If c < c_last, it is directly determined as replay or rollback. If c is within the sliding window range of [c_last + 1, c_last + W], it enters the second step. The second step is to verify the message authentication code based on the session key. The random salt r in the tag and the counter c are spliced to form the message body, and the cloud calculates and compares the authentication code with the derived tag key. Only when both steps pass can it be regarded as a valid marking. The window width W here is comprehensively determined by the on-site delay and the possible offline cache length. If it is too small, legal late arrivals will be wrongly accused. If it is too large, there will be a gap for replay. After successful verification, we generate a session token containing the device identifier, geographical fence, and validity period, and send it to the terminal offline cache. The token is two-way bound to the device to avoid cross-device abuse after being intercepted.

[0027] In this embodiment, a bitmap matrix is used to maintain the arrival situation within the window in sliding window deduplication. For each tag dimension, a circular bitmap with a length of W is maintained, and the index i = (c mod W) is mapped to the bit. If the bit has been set to 1 and the corresponding counter has been confirmed, it is determined as duplicate. If the bit is 0 or the timestamp falls within a new window period, it is allowed to pass and the bit is set. To prevent the counter from rolling back in extreme cases, in this embodiment, while storing c_last on the server side, the hash digest and timestamp of the last K successful sessions are recorded. When a large-scale rollback occurs, a risk warning is triggered, and the tag is marked as "suspected reset" and awaits on-site re-inspection.

[0028] In this embodiment, the coherence of the patrol path is considered in the generation and preservation of the session token. The token structure carries the tenant identifier t, point code p, device ID d, valid period Δ, geographical fence G, and signature σ. When the terminal approaches the same tag again within Δ, there is no need to repeat the handshake, and it can quickly confirm and send back the marking according to the token. We write the token and the marking event into the authentication database, and the fields include the marking time, position deviation, and RSSI intensity, which are used for subsequent evaluation and quality inspection. Here, we emphasize a natural law: the RSSI and position deviation near the card reader are positively correlated with "the person has really been to the point". We use them for anomaly screening in the background, and events with weak signals and excessive deviations will be downgraded.

[0029] This embodiment also handles the boundary situation of multi-tenant and cross-regional patrols. The park has both in-house teams and third-party security companies. The tag's distributed key is derived from the tenant's master key to prevent one company's leak from affecting another. When an external team is entrusted with temporary patrols, the platform temporarily authorizes them with a collaboration token. This authorization token must be linked to the target tenant and have a short validity period, without accessing the tag's long-term distributed key. The rationale behind this is simple: a temporary key opens a temporary door, leaving no future problems. For locations that have been deregistered or relocated, the system marks their distributed key as frozen, and any dynamic parameters, even if the counter is within the window, will no longer generate session tokens.

[0030] This embodiment encountered two common anomalies during engineering implementation. First, the tag's counter returned to its initial value due to static electricity or low temperature reset. Upon first discovering that c≈c0 and the tag's most recent communication distance was very short, we did not immediately reject the request. Instead, we allowed the terminal to initiate a "synchronization mode," and the server, according to its security policy, allowed a one-time window increase, wrote back the new anchor point value, and recorded the need for manual verification. Second, channel congestion caused the same marker to be read multiple times. Bitmap deduplication quickly suppressed duplicate writes to the database. The authentication database only retained the first valid record, marking the rest as duplicates and attaching the original frame digest for easy evidence collection.

[0031] This embodiment effectively addresses two key issues: first, it reliably binds each physical location to the tenant's identity, eliminating the potential risks of "taking the wrong tag" or "copying a tag"; second, the combination of dynamic counters and sliding windows filters out delays and replays, making patrol and point recording both smooth and clean. To ensure audit traceability, all token, counter evolution, and anomaly handling are linked in a chain record in the authentication database, allowing for complete reproducibility of the interaction trajectory at a specific location on a specific day. Thus, step S101 forms a self-consistent closed loop, from key generation, tag configuration, dynamic authentication, deduplication to token issuance and archiving, perfectly aligning with the operational rhythm of the park's nighttime patrols.

[0032] Step S102: Construct an operation rule engine, collect multi-source environmental data, extract time dimension features, climate dimension features, spatial dimension features, load dimension features, and operation dimension features, search the operation rule library based on the features, obtain a set of candidate rules, calculate the rule priority matrix, resolve rule conflict relationships, generate structured operation instructions, send the operation instructions to the mobile terminal, collect the execution data returned by the mobile terminal, extract the execution scoring indicators, and write the scoring indicators into the evaluation database; This embodiment focuses on the alternation of nighttime and holiday scenarios in the park. First, the operational rules engine is built, and then it is allowed to "breathe" within real data. The engine's entry point is multi-source environmental data, categorized into five types: duty calendars and holiday schedules forming the time dimension; weather stations and micro-weather poles providing the climate dimension; park GIS and building POIs forming the spatial dimension; energy consumption and vehicle / pedestrian flow measurements forming the load dimension; and equipment status, alarms, and on-duty personnel characterizing the operational dimension. After the data enters, it is not directly pieced together. We first define the sampling period and alignment strategy for each source. The time dimension extracts hourly / weekly locations, legal holiday markers, and day / night transitions; the climate dimension provides temperature, humidity, rainfall level, and wind force discretization; the spatial dimension projects points onto floors, entrances / exits, and blind spot grids; the load dimension calculates pedestrian flow lag and energy consumption anomalies; and the operational dimension aggregates work order backlog and patrol gaps. All quantities are summarized into a feature vector x, with source and timestamp appended, and written to the feature table of the environmental database for subsequent playback.

[0033] The retrieval action in this embodiment is not keyword matching, but rather a metric mapping of x to a rule vector space. Each rule r in the job rule base contains triggering conditions, priority factors, resource requirements, and applicable scope. We encode the five components of x as comparable features, construct similarity calculation units, and first perform a coarse screening by tenant and region, then evaluate each condition expression item by item. For example, the combination of "nighttime + rainfall + reduced pedestrian flow near entrances and exits" will match the rule candidate "increased frequency of field patrols and carrying anti-slip devices". To avoid false triggers, we add constraints during the retrieval stage: if there are high-priority alarms within the spatial radius, we prioritize "alarm handling" rules over regular patrol rules. At this step, we obtain a candidate rule set R, all of which include version and validity period.

[0034] This embodiment requires sorting R into an executable sequence. The key is to compress the complex, multi-dimensional state into a priority matrix P. We decompose the priority of each rule into four components: risk weight wr, timeliness weight wt, resource accessibility wrsc, and historical completion quality wh, and then perform a weighted synthesis. Considering interpretability and deployment, we provide a simple form: Score = α·wr + β·wt + γ·wrsc + δ·wh, where α, β, γ, and δ represent the adjustment coefficients of the four weights, wr reflects the probability of a safety event occurring, wt reflects the urgency of the trigger window, wrsc describes the availability of required personnel and equipment in the current shift, and wh comes from the average completion quality of the rule in similar scenarios in the evaluation database. To prevent extreme values ​​from skewing the sequence, we use quantile scaling for each component. The relationship here is straightforward: heavy rain and strong winds, numerous blind spots, and shortages of personnel and equipment will cause the Score to either increase due to high risk or decrease due to unavailable resources, ultimately presenting a balance between "risk and executability".

[0035] This embodiment resolves conflicts without relying on manual decision-making, instead constructing a conflict graph. Edges represent the mutual exclusion relationship between two rules in terms of resources, time, or space. For example, the same team cannot cover two far-away grids within 10 minutes, or two instructions require mutually exclusive operations on the same device. We project P onto the conflict graph to approximate the solution of the weighted maximum independent set, and then combine this with time windows to split the task into batches. For rules with subordinate relationships (such as "block first, then investigate"), we use pre-constraints to sort their topology, avoiding ineffective work caused by reversed execution order. For mandatory rules (regulatory compliance), they are retained regardless of their score, while other rules give way, and a reason explanation is added to the instructions for easy on-site understanding.

[0036] This embodiment structures conflict-free rule sequences into work instructions. Each instruction includes a summary of trigger conditions, specific actions, location information, required consumables, estimated duration, feedback fields, and safety prompts. We encode GIS paths, geofences, and floor switching nodes within the instructions, enabling offline navigation on mobile terminals. For field tasks under special weather conditions, we add "alternative actions," such as "if rainfall exceeds the threshold, switch to access control infrared verification." The instruction set is signed with the tenant's key and, when sent to the terminal, is assigned based on personnel qualifications and on-duty status, avoiding assigning elevator machine room tasks to patrol personnel without electrician licenses. Upon receiving the instruction, the terminal executes it according to the instruction card, generating a feedback stream of location, time, images, and sensor readings.

[0037] This embodiment transforms the returned data into evaluation metrics within a closed loop. The scoring calculation module extracts single task completion rate (whether it meets the target within the time window), execution time deviation, operational standardization (action steps, photo quality, completeness of required fields), path deviation, and device reading reliability. We standardize these metrics and aggregate them into an execution score vector y, which is then written into the evaluation database, corresponding to rule IDs and scene features x. To enable the engine to better understand the environment through use, we introduce a simple learning logic: under the same or similar x, if a rule consistently scores low, either the resource assumption is invalid or the action design is not suitable for the environment. In the next round, the engine will reduce its weight or replace it with a similar but easier-to-execute rule. The inherent relationship here is natural: rules that are difficult to execute and have poor feedback should have less exposure; conversely, rules with consistently high scores will be used as templates and promoted in adjacent areas.

[0038] This embodiment provides two actionable scenarios. When a yellow rainstorm warning is triggered, the spatial dimension shows low-lying grids overlapping at two entrances / exits. The load dimension shows a sudden drop in pedestrian traffic but an abnormal energy consumption curve. The engine retrieves the combination of "drainage channel verification + weak current room leakage inspection + entrance / exit anti-slip patch replenishment". The conflict diagram shows that the same shift cannot perform them in parallel, so the entrance and weak current room are issued first, and then the next shift handles the distant grids. Another scenario is when the temperature is low at night, the wind is strong, and manpower is limited. The engine increases the outdoor patrol frequency from 15 minutes to 20 minutes, replacing it with "long-range thermal imaging inspection + random spot checks", and clearly defines the replacement conditions and fallback conditions in the instruction to avoid leaving execution ambiguity.

[0039] Step S103: Construct a city-wide integrated gateway, access city platform events, perform signature verification and timestamp protection on the events, generate a standard event model, match affected areas based on geofences, generate cross-domain collaborative instructions, broadcast the collaborative instructions to target tenants, collect mutual assistance execution data, generate settlement entries, write the settlement entries into the audit database, perform desensitization processing on the execution data, and write the desensitized execution data into the shared database.

[0040] This embodiment addresses the scenario of coordinated handling between the park and the city-level platform. The city-integrated gateway is first placed on an edge node, enabling it to receive city events and understand the park's internal rules and asset dictionary. The access link uses the city platform's message bus and subscription topics. Event frames include event ID, source organization, occurrence time, latitude and longitude, event type, and signature block. To prevent contamination by forged traffic, signature verification is performed first: the gateway has a built-in public key version family of the city platform. It selects the public key according to the version number in the event header and verifies the signature block against the original payload. Passing the signature verification is not the end; we compare the event timestamp with the gateway's local NTP time difference. If the difference exceeds the tolerance, it enters a "late arrival buffer," only participating in analysis in scenarios requiring traceability, preventing delayed events from disrupting the current scheduling. Under high-concurrency conditions, timestamp protection is further enhanced with checks on the event sequence number and replay bitmap, consistent with the dynamic counter in S101, and the logic is the same: old frames should not affect new decisions.

[0041] This embodiment standardizes the original events to generate a unified standard event model. The model fields we define include a normalized event type code, confidence level, influence radius, start and end time windows, spatial semantic labels (roads, subway entrances, substations, etc.), potentially dependent external resources, and linkage priority. The original events are processed through a mapping table and a lightweight rule translator. For example, "City Operations - Flooding Yellow Notice" is expanded to "Flooding Risk, radius R estimated by rainfall and terrain, high priority," and assigned the spatial semantics of "low-lying roads, underpasses." The key to model generation is giving events execution meaning; only in this way can subsequent cross-domain collaboration have a basis. To maintain interpretability, the mapping table version is updated according to the city's seasonal releases and dictionary updates; older versions can still be reproduced during audit playback.

[0042] This embodiment uses geofencing to match affected areas for spatial positioning. The standard event model provides a center point and an impact radius. The gateway performs intersection calculations with the fence database of the park and its surroundings. The granularity of the fences is three-layered: park level, functional area level, and location level. We first filter out intersecting parks and functional areas, and then determine whether key facilities at the location level are matched. Objects such as transformer rooms, stormwater and sewage pumping stations, and main entrances are marked as "critical assets" to increase their priority for subsequent coordination. When the event is a linear entity (such as road closure), the gateway buffers the polyline into a strip-shaped area before matching to avoid missed detections due to differences in geometric representation. The matching result is not only a set, but also carries weights. The weights are synthesized from event confidence, asset importance, and current operational status, and are used to sort the coordination order.

[0043] This embodiment emphasizes "who comes, what to do, and where to do it" in cross-domain collaboration, thus generating collaborative instruction packages starting from standard events. The instruction package includes the collaboration type (flood drainage support, emergency power, traffic control), target fence, expected arrival time window, task list, required qualifications and equipment, feedback field structure, and clear settlement and metering standards. The generation process references the output of the operation rule engine formed in S102 to ensure that tasks within the park do not conflict with city-wide collaboration. For example, if there is already a drainage linkage task within the park, the collaborative instruction will be converted to "border defense + road intersection monitoring" to avoid two parties competing for the same pump. For multi-tenant parks, the gateway filters target tenants who can undertake such emergency tasks and have available capacity based on tenant qualification files, forming a targeted broadcast list with different action thresholds and confirmation timeouts to reduce noise caused by over-broadcasting.

[0044] In this embodiment, targeted broadcasting utilizes a tenant-side message tunnel. Before sending, messages are signed by the gateway with the park's private key and carry a one-time session token. The token undergoes bidirectional verification with the authentication database in S101 to ensure that only the named terminal can unpack the message. Upon receiving the collaborative instruction, the terminal enters the acknowledgment stage: acceptance, partial acceptance, or rejection, along with the reason. The gateway dynamically reorders tasks based on the acknowledgments. If no one accepts a critical task, the interface between the backup tenant and social emergency resources is triggered. During execution, mutual aid data is continuously transmitted back, including arrival time, photos, equipment readings, consumable requisition, task status changes, and location information. The gateway aligns these data with predetermined fields to form a unified execution data stream.

[0045] This embodiment converts execution data into settlement entries, a step that must be verifiable and auditable. The entry structure includes task ID, resource usage, working hours, difficulty level, event level, verification evidence index, and applicable settlement rule version. The measurement scope is not determined arbitrarily, but rather generated by cross-referencing the measurement definitions in the instruction package with the returned facts; for example, "mobile pump truck operation" is measured by the hour, and "sandbag laying" by the meter. If the returned data lacks evidence or is contradictory, the entry is marked "pending verification," and the hash and timestamp of the original evidence are linked in the audit database for easy external audit review. When writing to the audit database, we maintain an append-only, non-modification paradigm to ensure traceability.

[0046] This embodiment takes privacy compliance into account in the data sharing process. Before entering the shared database, the data from the mutual aid operation is anonymized, removing direct identifiers such as individual names, phone numbers, and facial images. Location information is downsampled to the fence level, and timestamps are slightly jittered without disrupting the causal sequence of events. To maintain data availability, statistical fields such as task type, consumable category, and response time range are retained; these form the "skeleton" needed for cross-park review. The anonymized data is written to the shared database for the city platform to conduct macro-level assessments and policy reviews. The original detailed rules are only retained in the audit database, ensuring clear access boundaries.

[0047] This embodiment provides two implementation scenarios for key technical points. First, during a rainstorm, the city platform pushes an "orange alert for urban flooding." The fusion gateway matches the south gate of Park A and the underground parking garage fence of Park B, broadcasting the alert to the two tenants with flood drainage qualifications. After accepting the order, Park A reports that the pump truck has arrived. Park B refuses due to equipment maintenance. The gateway immediately dispatches the park's public emergency team and splits the "sandbag laying at the underground parking garage entrance" task to a third tenant who can provide support. The execution data is then filed into the audit database. Second, municipal power grid maintenance triggers a "planned power outage" event. The fence hits the substation on the west side of the park. The coordinated instruction is changed to "UPS load reduction before the gate + critical business switching," and the expected load gap is simultaneously sent to the two data center tenants. The settlement items are measured by emergency man-hours and backup power fuel consumption. After anonymization, only the energy consumption type and response range are retained.

[0048] The technical effects of this embodiment are reflected in three points: trusted entry of urban events relies on signatures and timestamps for protection; the standard event model transforms "information" into "executable semantics"; geofencing and targeted broadcasting bring collaborative resources to the forefront; and the "two-database governance" of mutual assistance, auditing, and sharing not only settles accounts but also accumulates usable public experience. S103 echoes the preceding S101 and S102: S101 ensures the credibility of on-site identities, S102 produces internal operational baselines, and S103 weaves external disturbances into the same scheduling, ensuring that the park is neither disconnected from urban coordination nor thrown into chaos at critical moments.

[0049] As described above, the intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization provided in this application can achieve secure and reliable identity verification through innovative label authentication system design, key distribution, and dynamic authentication. It constructs a rule engine mechanism, combining multi-dimensional features and conflict resolution to establish reasonable operation management. By introducing city integration, it ensures the effectiveness of collaboration through event processing and data sharing. This method effectively addresses the shortcomings of traditional technologies in label authentication, rule engines, and cross-domain collaboration, providing technical support for intelligent patrol.

[0050] In one embodiment of the intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization in this application, the following specific contents may also be included: Step S201: Collect patrol point data, construct a key generation module, calculate the combined hash value of tenant identifier and key version number, extract the master key from the key management system based on the hash value, perform key derivation calculation on the master key and the unique identifier of the point to generate a distributed key, encrypt and package the distributed key to generate a key configuration data packet, write the configuration data packet into the control unit of the near-field communication tag, record the initial configuration parameters of the tag, construct a deployment record table containing point code, tenant identifier, and configuration time, and write the deployment record table into the point database; Step S202: Read the control unit of the near-field communication tag, construct a dynamic ciphertext generation module, write the dynamic ciphertext generation module into the tag storage area, configure the initial value of the counter of the dynamic ciphertext generation module, construct an anti-tampering protection unit, write the anti-tampering protection unit into the tag configuration area, enable the anti-tampering write protection mechanism, generate a security configuration table containing anti-tampering status, counter value, and protection parameters, perform integrity verification on the security configuration table, and write the security configuration table into the security database.

[0051] This embodiment focuses on the application of park patrol. First, patrol point data is aggregated and verified. The point data originates from the asset management system and on-site survey applications, and its fields include point code, unique identifier, geographic coordinates, tenant, equipment environment, and installation conditions. To prevent dirty data from entering the key process, the server performs a uniqueness check using the point code as the primary key and compares the coordinates with the building POI for geographic constraints. If duplicate points with the same coordinates but different tenants or adjacent points within the same tenant are found, manual verification is required. After the data is verified, a key generation module is constructed. This module receives the tenant identifier t and the key version number v, calculates the combined hash h = H(t||v), where H represents a collision-resistant hash function, t is the tenant's globally unique identifier within the platform, and v is the currently valid key version index. Based on h, a read-only request is initiated to the Key Management System (KMS) to extract the tenant's master key Kmaster, and the audit sequence number and valid range returned by the KMS are recorded to ensure subsequent traceability.

[0052] In this embodiment, after obtaining the master key, it is not directly used for the tag password, but rather for distributed derivation. For each patrol point, its unique identifier pid is taken, and Kdiv=F(Kmaster, pid) is executed according to the tenant-level derivation function F. This function uses HKDF or the equivalent of the national cryptographic standard, including salt value and context binding items, to avoid the risk of key co-patterning across tenants or points. Considering the limited bandwidth and hardware security requirements of the deployment end, the server completes the encrypted packaging of Kdiv within the HSM. The encapsulated content includes the Kdiv ciphertext, algorithm identifier, version number, validity period, and tag serial number binding fields, finally generating a key configuration data package Pkg. The Pkg is signed by the platform's private key before transmission, and the signature digest is written into the deployment log to prevent man-in-the-middle substitution. To address the risk of mis-labeling during construction, the Pkg embeds "binding point code + GIS hash". When the tag is powered on for configuration, it verifies the distance threshold between the scanned GPS / Bluetooth fingerprint and this hash. If the distance is too large, the data is rejected, reducing mis-labeling.

[0053] In this embodiment, the Pkg is written to the control unit of the near-field communication tag via a wired configurator or BLE channel. The writing process consists of four steps: handshake, authentication, programming, and readback. In the handshake phase, random numbers are exchanged and a short-term session key is established. In the authentication phase, the Pkg signature is verified using a KMS signature public key. In the programming phase, the Kdiv ciphertext and metadata are written to the protected page, and access policies are set. In the readback phase, key registers are sampled and verified; if the hash verification is inconsistent, the process is immediately rolled back and the tag is marked as a suspected fault. After successful configuration, the initial tag configuration parameters are recorded, including tenant identifier, location code, tag serial number, configuration time, installer, and equipment model, forming a deployment record table. The deployment record table is written to the location database in immutable log form and a foreign key is established with the authentication database in S101, which can be used for subsequent counter anomaly tracing.

[0054] This embodiment transitions to writing the dynamic ciphertext generation module. After reading the tag control unit and confirming the normal status of the controlled page and key area, the dynamic module code body and parameter area are sent to the tag storage area. The dynamic module takes "counter c, random salt r, and time slice marker τ" as input and outputs a one-time session ciphertext and authentication code. The algorithm identifier and Kdiv version are also permanently stored for easy cloud reconstruction. To reduce the risk of over-the-air leakage, c uses a monotonically increasing counting model, with an initial value of c0 set during initial configuration and written to the increment-only register; r is generated using the tag's internal TRNG and written to the volatile register, updated after each session; τ is used to mitigate replay detection under extreme latency. After the module is written, a self-test is performed, including TRNG entropy source health, counter write protection effectiveness, and code area CRC check. Only after passing the self-test does it return to the "available" state.

[0055] To combat disassembly and replication, this embodiment constructs an anti-tamper protection unit and writes it into the tag configuration area. This unit enables multi-channel detection: casing crack sensing, power interruption counting, magnetic interference threshold detection, and temperature exceeding limits. Any trigger will set the tamper status bit to 1 and freeze the counter write-back, allowing only one-time reporting and entry into the observation state. To prevent excessive errors caused by low temperature or electrostatic discharge, the protection unit is equipped with debouncing and short-window buffering parameters, which are calibrated by the field operating conditions. The anti-disassembly write protection mechanism enables a write lock at the controller level, allowing only one-way operation on the key page and counter page. The unlock password for the write lock is derived from Kdiv and requires secondary authorization in the cloud to prevent on-site tools from bypassing the write.

[0056] This embodiment generates a security configuration table during the configuration phase, encapsulating the initial values ​​of the anti-tampering status, the initial values ​​of the counter, protection parameters, algorithm version, entropy source health, and configuration time in a structured format. The security configuration table is written to the security database after integrity verification. The verification is performed in two steps: the tag side performs CRC and MAC encapsulation on the table body, and the server side verifies the signature using the platform's public key to ensure that the table body has not been tampered with. To facilitate subsequent auditing, a two-way reference is established between the security configuration table and the deployment record table. The security database stores the original table body and index hash, while the location database stores a lightweight digest for easy high-frequency queries without exposing details.

[0057] This embodiment emphasizes a chain-like security model of "master key - distributed key - one-time ciphertext" in its technical principle, which is closely linked to the dynamic authentication of S101. The hash index h binds the tenant and version to the same namespace, preventing the misuse of the old version master key; Kdiv, derived with pid as the domain, isolates the possibility of lateral movement between points from the root; the counter c and the random salt r together constitute the unique source of the session. The cloud reconstructs the verification path based on the deployment record and security configuration table. Even if the tag is copied, its counter evolution trajectory, TRNG characteristics, and anti-tampering status will leave differences in the authentication database, making it easy to identify.

[0058] This embodiment provides two engineering segments that closely match the actual site conditions. In the underground parking garage, where metal reflections are strong, the construction team reads the GIS hash within the Pkg using an app before applying the tags and aligns it with the Bluetooth fingerprint. When the reading distance is unstable, they switch to far-field patches and note "metal obstruction" in the deployment log. The S101 will then adjust the RSSI threshold accordingly. During a cold snap, some tags reset due to low temperatures and reported c≈c0. The safety configuration table showed the temperature exceeded the limit, but the outer casing did not crack. The system determined this to be an environmental trigger, allowing "synchronization mode" to raise the window and write a new anchor point, marking it "re-inspection required" to ensure uninterrupted nighttime patrols.

[0059] The technical effects of this embodiment are reflected in three aspects: on the deployment side, it reduces the risk of mislabeling and replication; on the operation side, it provides reliable session entropy and counting anchors for dynamic authentication; and on the audit side, it constructs a reproducible chain of evidence based on deployment records and security configuration tables. S201 and S202 form a closed loop from key injection to dynamic capability activation. The former anchors the identity of "who and where," while the latter solidifies the mechanism of "how to generate verifiable sessions." The two combined provide a trusted foundation for subsequent command issuance by the operation rule engine and cross-domain collaboration with the city fusion gateway.

[0060] In one embodiment of the intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization in this application, the following specific contents may also be included: Step S301: Read the dynamic parameters output by the tag, construct a key calculation module, input the tenant identifier and key version number into the key derivation function to generate a tag key, decrypt the tag key to obtain the counter value and message authentication code, combine the counter value and authentication code into an authentication data packet, construct a verification record table containing authentication time, authentication location and device identifier, and write the verification record table into the authentication database. Step S302: Read the verification record table, construct a sliding window module, calculate the sliding range of the counter value, generate a window bitmap matrix, perform deduplication processing on the bitmap matrix, remove replay data, generate a session token, bind the session token to the device identifier, construct an authorization record table containing the token identifier, valid time, and geofence, perform encryption signing on the authorization record table, and write the authorization record table into the token database.

[0061] This embodiment focuses on the online verification process for patrol personnel arrival. After the on-site reader is placed close to the near-field tag, it first reads the tag's output dynamic parameter set, including the current counter value *c*, the tag's random salt *r*, the time slice marker *τ*, and the message authentication code (MAC) calculated based on a distributed key. To complete the verification without exposing the master key, the server constructs a key calculation module. It retrieves the corresponding master key from the key management system based on the tenant identifier *t* and the key version number *v*, encapsulates it, and then generates the tag key *Kdiv* using a derived function bound to the unique identifier *pid* of the location. Within the hardware security boundary, the key module decrypts the tag's encrypted field to obtain the counter *c* and the MAC field for this session. It then recombines *c* with the MAC, *τ*, and *r* into an authentication data packet, including the acquisition device identifier *devid*, the acquisition time *t_auth*, and the location *loc*. The authentication data packet enters the verification unit, where the expected MAC is recalculated using Kdiv and compared with the value sent by the tag. If they match, it is considered as passing. Subsequently, a verification record table is constructed, with fields covering authentication time, authentication location, device identifier, tenant identifier, location code, counter snapshot, and tag anti-tampering status summary. This record is written to the authentication database as the original credential for subsequent risk control and traceability.

[0062] This embodiment considers the jitter and user errors in the near-field environment, meaning a single pass is insufficient to determine a valid visit. Therefore, a sliding window mechanism based on a counter sequence is introduced in S302. The system periodically reads the verification record table, buckets it by location and tenant dimension, and constructs a sliding window module. The window length is adaptively estimated based on the patrol strategy and the tag counter growth rate. Subsequently, the sliding interval [c_min, c_max] of the counter value is calculated and mapped to a window bitmap matrix B, where each bit corresponds to whether a counter value has been occupied. To identify replays, the module calculates the counter index i=c for newly entered records. If B[i] is already set, c_min is considered a replay candidate. A second round of filtering is then performed using the time slice τ and the geographic location deviation threshold to avoid false positives in extreme scenarios (such as short-term repeated readings caused by electromagnetic interference). After deduplication, a session token is generated from the records, and the token is strongly bound to the device identifier devid. Simultaneously, the geofence ID and valid time interval are linked to form an authorization record table. This table contains the token identifier, bound device, tolerance time window, fence constraints, and revocation hook. The table body is written to the token database after being signed with the platform's private key and witnessed by a timestamp, for subsequent operation instructions and city collaboration module queries. To facilitate auditing, the authentication database and the token database establish a reference relationship through verification record key values. Once token use outside the fence is detected, the specific counter trajectory and reading device can be quickly traced back.

[0063] The key to this embodiment lies in closing the causal chain between dynamic parameters and the key system. The MAC generated on the tag side is determined by Kdiv, c, r, and τ. The server uniquely reconstructs Kdiv using t, v, and pid. During verification, only the MAC needs to be compared to identify whether it is a genuine trigger for that location. The monotonicity of the counter c is naturally consistent with the "number of visits". The sliding window encodes the "recently used counting axis segments" into a bitmap, which can accurately remove replay data without relying on complex models, preventing previously captured packets from being impersonated as valid visits again after the network transition. On the other hand, the superimposed constraints of geofencing and token validity time limit the space and time window for cross-regional abuse by stealing tokens. Once the token expires or leaves the geofence, the task confirmation interface on the job side will reject the token.

[0064] This embodiment considers various boundary scenarios during engineering implementation. In underground parking garages with strong signal reflection, the reader might read two nearly identical data entries within seconds. The sliding window bitmap and time slice τ are used for cross-checking; the first entry is stored, while the second, due to bitmap repetition with τ, is marked as a replay and discarded. During patrols in heavy rain, security guards use backup handheld terminals to read data. Tokens are bound to devid to prevent another unregistered terminal from reusing the token to "crash" adjacent locations. If individual tags experience a drop in c due to low-temperature reset but tamper is not triggered, the system judges it as an environmental event based on the low-temperature threshold recorded during deployment. The window module temporarily opens the synchronization channel in the c0 neighborhood, generates a short-term token, and marks it as "requires re-inspection," thus preserving security without interrupting the work cycle.

[0065] This embodiment also describes S301 and S302 in conjunction with the preceding S201 and S202. The distributed key derived from S201 and the initial value of the counter written in S202 determine the key reconstruction path and verification baseline of S301. After the anti-tampering status bit of S202 enters the verification record table of S301, it becomes the parameter tuning reference for the sliding window of S302. For example, when tamper=1, the window width is narrowed, the token validity period is shortened, and a stricter fence is forcibly bound. The cross-step design is not a mere accumulation, but rather a combined solution to the three questions of "who has been there, where they have been there, and whether it is genuine", forming a chain of evidence that can be replayed and audited at the data structure level.

[0066] The calculation process in this embodiment uses only necessary mathematical components to avoid black-box operations. If a formal characterization is needed, the session validity score can be defined as S = I(MAC_valid)·I(B[c]=0)·I(loc∈Fence)·I(Δt≤T), where I(·) is the indicator function, MAC_valid indicates that the authentication code recalculated based on Kdiv is consistent, B[c]=0 indicates that the counter bitmap is not occupied, loc∈Fence indicates that the reading location is within the geofence, and Δt≤T indicates that the authentication time is within the allowed window. A token is generated when S=1, and falls into an alarm or discard path when S=0. The physical meaning of each parameter is consistent with observable measurements on-site, follows natural constraints, and does not introduce inferences that contradict common sense.

[0067] In terms of technical effectiveness, this embodiment solves three common problems: first, the replay of peripheral devices being copied or messages being captured is naturally resolved by using a counter bitmap and MAC binding; second, token abuse under multi-terminal collaboration is addressed by tightening the usage domain through device binding and fence constraints; and third, "false denials" caused by extreme working conditions are prevented by recording the status and environment adjustment window as a risk event, allowing subsequent audits to trace the decision-making basis based on the records. In the patrol scenario, the visit of the on-duty personnel is precisely characterized as a verifiable session, which the operating system then uses to trigger the closed-loop instruction of S102 and the external linkage of S103. The link is clear and not easily bypassed.

[0068] In one embodiment of the intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization in this application, the following specific contents may also be included: Step S401: Construct a multi-source data acquisition module, access meteorological monitoring data, traffic flow data, population density data, energy consumption monitoring data, and equipment status data, normalize the monitoring data, generate a feature vector matrix, group the feature matrix by dimension, construct an acquisition record table containing data type, acquisition time, and data source, and write the acquisition record table into the environmental database. Step S402: Read the feature matrix in the environmental database, construct a feature extraction module, calculate time period features, temperature and humidity features, spatial distribution features, load level features, and activity status features, combine the features into a feature description vector, retrieve the job rule base based on the feature vector, construct a similarity calculation unit, generate a candidate rule set, and write the candidate rule set into the rule database.

[0069] This embodiment focuses on the real-time linkage between park patrols and facility operation and maintenance. First, a multi-source data acquisition module is built on S401, clearly defining the data access order and cleaning logic. Meteorological monitoring data comes from the city platform and the park's micro-weather poles, including rainfall, wind speed, temperature, and humidity; traffic flow data is obtained from surrounding road detectors and entrance / exit channel counters; pedestrian density data is provided by video passenger flow algorithms and Bluetooth / AP probes; energy consumption monitoring data is divided into electricity, water, and cooling / heating metering; equipment status data includes the operating conditions, alarms, and health status of key equipment. Each source undergoes source-side verification before entering the bus, with verification dimensions including timestamp freshness, structural integrity, and coarse screening of outliers. After entering the acquisition module, data is aligned to the smallest sampling granularity Δt according to a unified time scale, and a hybrid strategy of "upsampling interpolation + downsampling aggregation" is used to eliminate asynchrony. For comparability, different dimensions are normalized; stable variables are processed using z-score, and long-tailed variables are scaled using quantiles; discrete events such as alarm counts are performed using in-time window counting and exponential smoothing. This constructs a feature vector matrix X, where rows correspond to time slices and columns correspond to standardized feature dimensions. Considering source tracing on the operations side, the matrix is ​​grouped by dimension, such as meteorological, traffic, pedestrian flow, energy consumption, and equipment groups, with each group accompanied by metadata. A data collection record table records the data type, collection time, data source identifier, cleaning rule version, and missing data filling flag. The version number of the table is consistent with that of X and written to the environmental database for playback and compliance auditing.

[0070] This embodiment incorporates fault tolerance and causal protection to address the reality of inconsistent data quality. Row-level holes are handled through a combination of "adjacent window multivariate interpolation + business constraints," such as ensuring that pedestrian density does not suddenly increase when battery is zero. Source conflicts are weighted by a consistency checker, and this weight is used for noise reduction during subsequent feature extraction. To prevent short-term anomalies from skewing the overall data, the acquisition module calculates a robustness scale (such as MAD) for each group and outputs a health field before data entry. Time slices with low health scores have reduced weights in subsequent similarity searches to avoid misinterpreting a single camera shake as a sudden increase in pedestrian flow.

[0071] In this embodiment, after reading the feature matrix from the environmental database, a feature extraction module is constructed in S402. First, time-period features are extracted, including hourly, weekly, holiday, and day / night transition markers. Temperature and humidity features are used to logically calculate the "hot / cold pressure index" based on temperature, relative humidity, and dew point, which is used to determine the impact on outdoor work intensity. Spatial distribution features project pedestrian flow and equipment alarms onto park grids or functional area fences, calculating the G-values ​​or simple density gradients of hot and cold spots to reflect "where is busier." Load level features are constructed from the deviation of energy consumption and flow, comparing the current value with the same period last week and the near-window average, outputting the direction and magnitude labels of "exceeding the threshold." Activity status features combine equipment status, alarm levels, and the number of personnel on duty to form a "work accessibility" characterization. The above features are combined into a feature description vector φ, maintaining interpretable field naming and value ranges to ensure traceability during rule retrieval.

[0072] This embodiment uses φ as the query key to retrieve the operation rule base. Rules are stored as a quadruple of "trigger condition—scope of application—resource requirement—priority factor." Each rule is parsed into a computable predicate upon entry into the database, such as "nighttime ∧ rainfall level ≥ moderate ∧ decreased pedestrian flow at entrances and exits ∧ abnormal energy consumption at underground pumping stations." For robust matching, we construct a similarity calculation unit containing two types of operators: one is constraint-satisfaction type, which performs Boolean evaluation on discrete conditions; the other is metric nearest neighbor type, which calculates a weighted distance for continuous features, with weights derived from domain knowledge and historical performance evaluation. The outputs of the two types of operators are robustly aggregated to obtain a similarity score s, and a candidate rule set R is selected based on a threshold of s and the rule's validity period. Here, black-box inference is not introduced; the correspondence between features and rule conditions aligns with physical intuition. For example, higher temperature and humidity increase the likelihood of a reduction in field operation intensity; a sudden drop in pedestrian density at the main entrance without a decrease in energy consumption suggests an increase in security patrol frequency. Such judgments stem from the natural correlation between indicators.

[0073] This embodiment considers conflict and coverage both before and after candidate generation to avoid selected rules competing for resources or having insufficient spatial overlap. The feature extraction stage has already produced "job reachability," and we reduce the matching score of high-resource-consuming rules during resource-scarce periods in the similarity score. The hotspot grid output by spatial distribution features is used to select "local scene rules" from the rule base instead of "campus-wide broadcast rules," narrowing the hit range and improving execution accuracy. When the candidate rule set R is written into the rule database, a retrieval context is attached, including the hash of φ, feature weight vector, matching threshold, and conflict resolution summary. Subsequent sorting and distribution stages can use this to explain why a rule appears or is suppressed.

[0074] This embodiment provides two real-world scenarios to illustrate the technical principles. A sudden afternoon downpour occurred, with the rainfall intensity exceeding the threshold set by the meteorological team. The pedestrian flow showed a rapid decline at the west gate, and the energy consumption showed a jump in power consumption at the underground pump station. The spatial characteristics indicated a shift of the hot zone to the low-lying fenced area. The search matched the combination of "anti-slip deployment at entrances / exits + inspection of backup power supply for underground pump stations + deployment of road flood barriers." Resource characteristics showed a low number of on-duty personnel. The system retained the first two items, postponed the barrier deployment task to the next shift, and recorded the reason for the decision in the candidate set. At night, the temperature was low and the wind was strong. The temperature and humidity characteristics marked the "thermal and cold pressure index" as high. The pedestrian flow was sparse along the outdoor ring road. The rule "increase outdoor patrol pace and switch to long-range thermal imaging spot checks" in the rule base obtained a higher S-value. After being matched, it was combined with "critical computer room temperature control inspection," covering the natural risk of failure due to low-temperature equipment.

[0075] This embodiment inserts a learnable feedback channel between data engineering and rule retrieval, but does not rely on an uninterpretable black-box model. Historical execution results are represented by a scoring vector in the rule database, containing information such as completion time deviation, arrival rate, and alarm-to-cancellation ratio. The weights of similarity units are slightly updated under non-critical conditions, based on the principle that "if a rule consistently has a low execution score within the same φ neighborhood, its weight is reduced." This adjustment follows common sense: strategies that are difficult to execute or have poor returns are exposed less frequently. The input data remains the same five types of monitoring; the output only affects the weights without altering the triggering semantics of the rules, maintaining interpretability throughout the entire process.

[0076] The technical challenges of this embodiment lie in the spatiotemporal alignment, dimensional unification, and noise suppression of multi-source heterogeneous data. The solutions are reflected in sampling alignment, robust normalization, and health annotation. Secondly, it maps complex environments to executable semantics, bridging them with explicit feature families and physically meaningful similarities. Finally, it ensures that candidate rules are reviewable and replayable, grounding each hit in evidence through a data collection record table and retrieval context. The overall technical effectiveness is reflected in two aspects: the on-site tasks are more environmentally aligned, reducing resource and spatial conflicts; the decision-making chain in the background is clearly traceable, facilitating the reuse of the same set of features and context in the sorting and distribution in S102 and cross-domain collaboration in S103, resulting in stable and non-rigid system behavior. In one embodiment of the intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization in this application, the following specific contents may also be included: Step S501: Read the candidate rule set, construct a priority calculation module, quantify and assign values ​​to rule attributes, generate a rule scoring vector, convert the scoring vector into a priority matrix, detect rule conflict items based on the priority matrix, construct a conflict resolution unit, generate a conflict-free rule sequence, convert the rule sequence into a structured operation instruction, digitally sign the operation instruction, and send the operation instruction to the mobile terminal. Step S502: Read the execution data returned by the mobile terminal, construct a scoring calculation module, extract quantitative indicators such as task completion rate, execution time, and operation standardization, generate an execution scoring vector, normalize the scoring vector, construct an evaluation record table containing execution time, execution location, and execution personnel, verify the execution data in the evaluation record table, and write the evaluation record table into the evaluation database.

[0077] This embodiment starts with the candidate rule set for park patrol and facility operation and maintenance, and unfolds S501. The system reads the candidate rule set R from the rule database. Each rule includes attributes such as triggering conditions, applicable area, resource consumption profile, time constraints, and risk level. The first step in building the priority calculation module is to quantify the above attributes into comparable scalars: risk level is mapped to risk score, resource consumption is generated based on the number of personnel, equipment occupancy time slots, and energy consumption tags to generate resource cost, time constraints are given by the reciprocal of the remaining validity period to give urgency, and spatial coverage is given by the overlap rate with hotspot grids to give benefit. Based on this, the module forms a rule scoring vector s_i=[risk score, urgency, benefit, resource cost]. Then, according to the weight w set by the operation strategy (derived from management system and historical evaluation data), it calculates the comprehensive score and converts it into a priority matrix P. The matrix acts as rules, and the columns are the evaluation dimensions and the comprehensive column. To avoid the single dimension from hijacking the ranking, the module uses a saturation function for abnormally large resource costs or extreme urgency to suppress the influence of noise.

[0078] This embodiment proceeds to conflict detection after obtaining P. Conflicts mainly manifest in three categories: resource, space, and time: competition for the same personnel or equipment within the same time window; different rules pointing to mutually exclusive actions within the same geofence (e.g., mutually exclusive switch operations); and contradictory dependencies across rules. The system constructs a conflict graph G based on P, where nodes represent rules, edges represent conflict relationships, and edge weights are derived from conflict intensity (resource overlap ratio, fence overlap area, and time window overlap). The conflict resolution unit performs a restricted maximum independent set approximation on G: prioritizing rules with high comprehensive scores and low edge weights for inclusion in set S; when encountering strong dependency chains, topological sorting constraints are introduced to bring dependencies to the forefront. If two rules have similar benefits but resources are scarce, the "alternative action" field of the candidate rule is used for downgrading and replacement, for example, replacing "full-scale inspection" with "spot inspection of key locations," and recording the reason for the replacement for auditing. This outputs a conflict-free rule sequence Q, which retains the execution order, concurrent batches, and necessary waiting conditions.

[0079] This embodiment converts Q into a structured work instruction. The instruction body uses standard fields: token identifier, task type, required location / equipment, operation steps, verification method, geofence, validity period, required material list, and feedback template. To ensure that the terminal executes according to regulations, verifiable checkpoints are embedded in the steps, such as photo hash, NFC secondary contact, and threshold reading range. Before issuance, the instruction is digitally signed by the platform's private key and includes a timestamp and revocation list version number to prevent tampering or expired reuse. During the issuance process, the instruction is pushed to the bound mobile terminal via the message bus. The terminal needs to verify the signature and validity period; only after successful verification is the instruction displayed and allowed to be accepted. Considering weak network conditions and offline operation, the system generates a read-only cache for the same instruction, which is automatically cleared after expiration to avoid repeated offline execution.

[0080] In this embodiment, step S502 reads the execution data packet returned by the mobile terminal. The packet includes task node completion markers, start and end times, trajectory sampling, on-site photos or readings, anomaly descriptions, and environmental details. When constructing the scoring calculation module, corresponding evaluation templates are first loaded for different task types: the task completion rate is derived from the achievement rate of mandatory nodes and the success rate of key checkpoints; execution time is measured by the deviation between planned and actual execution time, with tolerance adjustments considering traffic and weather fields; operational standardization is calculated based on the step sequence, trajectory and fence consistency, photo hash, and NFC reach matching degree. If there are out-of-bounds errors or step jumps, the score is reduced. These three indicators are quantified to form an execution score vector e = [completion rate, time evaluation, standardization]. To facilitate cross-task comparison, e is normalized using interval scaling or robust standardization, and missing items are marked "unevaluable" to avoid misjudgment.

[0081] This embodiment generates an evaluation record table before scoring is implemented. Fields include execution time, execution location trajectory summary, executor and equipment identifiers, task ID, scoring vector, anomaly label, and original evidence index. Data verification is performed in two layers: one layer is format and signature verification to ensure the data packet has not been rewritten; the other layer is business consistency verification. For example, the execution location must fall within the task fence. If it deviates but the weather is heavy rain and roads are congested, and the trajectory detour is reasonable, it is marked as "reasonable detour" rather than directly judged as a violation. Records that pass verification are written to the evaluation database. Foreign keys and instruction IDs / token IDs are maintained between records to facilitate subsequent traceability, statistics, and weight iteration.

[0082] The key technical point of this embodiment lies in the closed loop of "quantification—conflict graph—structuring of instructions—verifiable execution". Quantification translates abstract risks and timeliness into scalars; the conflict graph makes resource and space contradictions explicit; the maximum independent set approximation reduces collisions while ensuring execution value; structured instructions and digital signatures solidify the plan into an undeniable execution unit; the feedback score uses verifiable evidence bundles to constrain human arbitrariness and avoids verbal information such as "completed". Taking the scenario of low temperature and sparse traffic at night as an example, high-risk data center temperature control inspection and medium-risk field inspection will be differentiated in P, and conflict resolution will prioritize the former; if there are insufficient personnel, field inspection is replaced by "remote thermal imaging inspection", which satisfies coverage without overwhelming resources.

[0083] This embodiment sets up a lightweight learning channel for long-term operation, but adheres to physical intuition and institutional constraints. The scoring history enters the weight updater, affecting non-critical components of w. For example, task types with consistently low standardization have their resource cost weights increased, making the ranking more biased towards solutions that are easier to execute in a standardized manner. The combination of completion rate and anomaly labels is used to identify unreasonable rule conditions, which are fed back to the rule base for manual review. Here, execution is not directly determined by a black-box model; the input is a quantitative indicator, and the output is merely a fine-tuning of weights. The trend of change is consistent with natural laws: difficult, complex, and low-return strategies receive less exposure, while simple, critical, and stable-return strategies are more frequently adopted.

[0084] The technical effects of this implementation are concentrated in three aspects: First, to address resource bottlenecks caused by multi-task competition, the system reduces overlap through conflict graphs and serialized delivery. Second, to address differences in terminal execution, scoring and verification transform "whether execution is in accordance with regulations" from subjective judgment to evidence-driven analysis. Third, to address environmental variability, quantification and alternative actions allow the plan to converge flexibly without losing control. The sequence Q and the evaluation record table form a closed-loop index in the database, allowing any anomaly to be replayed to the candidate set, weights, and resolution decisions at that time, providing verifiable evidence for operation and maintenance management.

[0085] In one embodiment of the intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization in this application, the following specific contents may also be included: Step S601: Construct a city event access module to receive meteorological events, fire events, traffic events, and emergency events pushed by the city platform, extract event signature data, verify the validity of the signature, construct a timestamp verification unit, perform timestamp protection on the event, generate a standard event model containing event type, severity, and impact period, and write the standard event model into the event database. Step S602: Read the standard event model, construct a geofence matching module, calculate the polygonal area of ​​the event's impact range, generate a spatial index matrix, match the affected parks and tenants based on the spatial index, construct a cross-domain collaborative instruction generator, convert the event model into collaborative instructions, group and encode the collaborative instructions, generate a tenant-oriented broadcast table, and write the broadcast table into the instruction database.

[0086] This embodiment focuses on cross-domain collaboration in a park operation and maintenance scenario. First, a city event access module is built in the S601, connecting to four themes on the city platform: meteorology, fire protection, traffic, and emergency response. To ensure source trustworthiness, each event message received by the module carries a platform signature and certificate chain. The access end verifies the certificate validity and revocation status using a trust anchor, and then verifies the signature of the message body. Failed verification results in the message being discarded and an alarm is triggered. After successful signature verification, event signature data is extracted, including event ID, upstream timestamp t_city, event type, severity, spatial range sketch, and auxiliary fields (such as source system and handling suggestions). Considering cross-system clock errors, a timestamp verification unit is constructed: the access end maintains the time synchronization deviation δ between itself and the city platform, conserved through NTP / local GPS dual-source checks; for each event, |t_city| is calculated. t_ingest If the time stamp value exceeds a reasonable threshold, it is marked as "time sequence abnormal" and placed in an isolation queue for review to prevent old events from being misjudged as new triggers. Timestamp protection also covers replay detection; the access end establishes a short-term sliding window index for the event ID and hash, counting duplicate messages with identical signatures only once. After passing through these safeguards, the system organizes original city events into a standard event model. Core fields include event type, severity, impact period, spatial primitives, triggering reason, and evidence summary. The model, signature verification metadata, and time sequence annotations are written together into the event database to form an auditable original source.

[0087] This embodiment focuses on the reproducibility of the evidence chain; the standard event model is not a simple mapping. Taking meteorological events as an example, the platform may push a "blue rainstorm warning." The access module translates the severity into an internal classification, and the impact period is expanded according to the warning start and end and uncertainty. Spatial primitives are converted from administrative boundary to vector polygons. Fire events usually include point or line targets (buildings on fire, evacuation routes), which need to be expanded into buffer polygons before being entered into the database for subsequent spatial matching. Traffic events provide road congestion sections and control periods, and the model records the different impact weights on motor vehicles and pedestrians. For emergency events, in addition to regular fields, cross-departmental instruction reference numbers are added to facilitate the retrieval of upstream handling requirements in subsequent collaboration stages. The above conversion process is written into the field source mapping table to ensure that any internal field can be traced back to the external original text and its signature.

[0088] In this embodiment, when reading the event database in S602, spatial and temporal information is first extracted from the standard event model to construct a geofence matching module. For complex impact areas (polygons, perforated areas, linear buffers), the module calculates a unified polygon set and performs topological correction to avoid missed matches caused by self-intersections and gaps. Subsequently, a spatial index matrix is ​​generated. The bottom layer adopts a hybrid structure of layered grid and R-tree: the coarse layer divides the urban area into fixed grids using a grid, and the fine layer maintains a polygon R-tree index in each cell. The index matrix entries record the polygon ID and severity weight. Parks and tenants pre-maintain fences (park boundaries, multi-building fences, and special area sub-fences). During matching, the coarse-layer grid is used to first delineate candidates, and then polygon overlap calculation is performed in the fine layer. The output includes a list of affected parks, the corresponding tenant set, and the degree of overlap. To avoid "flickering" caused by boundary jitter, the module introduces a fence buffer zone to maintain stable matching within a small offset. The buffer parameters are derived from historical positioning error statistics.

[0089] This embodiment constructs a cross-domain collaborative instruction generator based on spatial matching, converting event models into executable collaborative instructions within the park. The conversion process is driven by two parts: first, mapping event type and severity to collaborative templates in the rule base, such as "moderate rainstorm + low-lying fence → drainage pump linkage, setting up warning tapes at basement entrances and exits, and increasing nighttime patrol density"; second, tenant attribute constraints, including business type, interruptible business, and a list of critical equipment, determine the applicability and priority of the instruction. The generator superimposes the degree of spatial overlap and the impact period into a spatiotemporal priority factor, determining the effective window and execution batch of the instruction. If there are conflicting instructions in the same multi-tenant area (e.g., traffic control requiring the closure of entrances and exits, and merchants requesting to maintain business flow), the mandatory instruction is retained according to the administrative priority of the city event, and alternative path notifications are generated for the suppressed tenants. The instruction body is structured into an action set, target fence, validity period, checkpoint, and cancellation conditions, maintaining consistency with the aforementioned operational instruction system, facilitating direct execution via mobile terminals.

[0090] This embodiment considers the distribution costs across parks and tenants, requiring event coordination instructions to be grouped and encoded. The generator first groups affected tenants by business type and geographical cluster, calculating the common instruction subset and differences for each group; the common parts are packaged into group instructions, and the differences are treated as tenant-customized patches. Group encoding uses a "group instruction ID + list of difference patch IDs" format to reduce redundancy. Subsequently, a tenant-directed broadcast table is generated, with fields including group ID, tenant ID, instruction digest, validity period, spatial fence, administrative priority, revocation hook, and signature digest. Before being stored in the database, the broadcast table is signed with the platform's private key and marked with the signature fingerprint of the event source to ensure the integrity of the cross-domain forwarding chain. Finally, it is written into the instruction database for low-latency push of the message bus and retrieval by offline terminals.

[0091] This embodiment illustrates the role of key technologies through two engineering scenarios. When a rainstorm event escalates to a higher severity level on the city platform, the access module extends the affected period to the forecast window. Geographic matching reveals a high degree of overlap in the underground fences of three parks, but the fence of Building A in one of the parks is located within the existing flood control platform area. After overlaying the facility layer with the spatial index matrix, its spatiotemporal priority factor is lowered. The collaborative command only issues observation-type actions to this building without initiating high-power drainage. Another example is when urban traffic control covers the western main road. The matching module outputs that multiple commercial office tenants are affected. The collaborative generator generates an alternative path for logistics tenants ("relocate scheduled delivery to the north gate") and a flexible suggestion for general office tenants ("prioritize flexible work hours and online meetings"). Both are encoded as differential patches of the same set of instructions, reducing redundant broadcasts.

[0092] The technical challenges addressed in this embodiment primarily focus on three aspects: First, ensuring reliable access and timing of cross-domain messages by employing signature verification, certificate checking, and timestamp protection to prevent replay of old messages or forged events from interfering with park policies. Second, achieving efficient and accurate matching of spatial impacts by using polygon topology correction and hierarchical index matrices to translate complex city boundaries into computable overlaps within park / tenant fences. Third, ensuring the implementation of collaborative instructions from "city semantics" to "park executable semantics" by leveraging templates and tenant attribute tailoring to avoid a one-size-fits-all approach. The overall technical effectiveness is reflected in traceable response chains, fine-grained distribution, verifiable conflict resolution, and seamless integration with prior rules and instruction systems, ensuring that park operations and maintenance in the event of emergencies both comply with the city-level handling framework and maintain business continuity for each tenant.

[0093] In one embodiment of the intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization in this application, the following specific contents may also be included: Step S701: Read the tenant mutual assistance execution data, build a data integration module, extract statistical data on mutual assistance duration, number of personnel, and equipment usage, generate a resource consumption matrix, convert the resource matrix into settlement entries, build a settlement record table containing mutual assistance number, execution time, and resource details, perform integrity verification on the settlement record table, and write the settlement record table into the audit database. Step S702: Read the mutual assistance execution data, construct a data anonymization module, anonymize the fields of personnel identity information, equipment number, and location coordinates, generate an anonymized dataset, classify and label the anonymized dataset, construct a shared license table containing sharing scope, protection level, and authorization period, perform access control on the shared license table, and write the shared license table into the shared database.

[0094] This embodiment addresses mutual assistance actions between different tenants within the park, establishing a settlement evidence chain in S701 based on the original feedback from the execution side. The system first reads mutual assistance execution data, sourced from preceding work instructions and execution feedback from mobile terminals, recording the assisted tenant, assisting tenant, task number, start and end times, visit trajectory, equipment used, consumable distribution, and anomaly descriptions. When constructing the data integration module, it first aligns the mutual assistance number with the timeline to eliminate duplicate segments across terminals; then, it identifies "billing units" based on instruction templates, such as tiered statistics of labor hours by job level, equipment usage calculated by model and power curve, and consumables summarized by batch and outbound order number. For missing downtime or abnormal interruptions, the module uses trajectory and sensor heartbeats to fill in the "on-site but not operating" periods, avoiding billing gaps. After aggregation, three types of statistics are extracted: mutual assistance duration (calculated separately by personnel granularity and equipment occupancy granularity), number of personnel (distinguishing between the total number on site and the actual number of operators), and equipment usage (duration × power or number of times × working condition coefficient). An exception marker field is added to distinguish between "emergency timeout" and "normal working hours".

[0095] This embodiment generates a resource consumption matrix M after completing the statistics. The matrix rows correspond to the mutual aid task number, and the columns correspond to resource dimensions, such as work hours for Category A personnel, work hours for Category B personnel, machine hours for critical equipment, usage of general tools, and consumable items. The matrix elements are standardized measurement values. To ensure cross-tenant comparability and facilitate settlement, the data integration module maps M to settlement items according to the platform's settlement rules. Each item includes the unit of measurement, billing caliber, and tax percentage, and incorporates contextual information such as nighttime / statutory holiday coefficients and emergency level coefficients. However, these coefficients are traceable to previous instructions and the environment database and cannot be freely adjusted. Subsequently, a settlement record table is constructed. Core fields include the mutual aid number, aiding and receiving tenant identifiers, execution start and end times, resource details (expanded by matrix columns), settlement caliber version, and evidence index (trajectory, photos, equipment logs, consumable in / out slips). A hash fingerprint for auditing is then written to ensure a one-to-one correspondence during subsequent verification.

[0096] This embodiment performs integrity verification before data entry, which consists of three layers. The first layer is structural verification: all fields are complete, the time series is not reversed, and the numbering relationship is correct. The second layer is business consistency verification: resource details match instruction constraints; for example, unauthorized devices cannot appear in usage records, personnel qualifications must match task types, and consumable batches must have corresponding outbound records in the warehousing system. The third layer is evidence verification: the trajectory covers all locations, the power on / off time in the device log matches the usage duration, and the photo hash matches the original document uploaded at the time. After successful verification, the settlement record table is written to the audit database. The database retains the version trajectory, and any correction must include the correction reason and approval chain to prevent subsequent tampering.

[0097] This embodiment proceeds to S702. Addressing the compliance requirements when sharing mutual aid data, a data anonymization module is constructed to anonymize personnel identity information, device numbers, and location coordinates at the field level. The personnel field employs a dual-track mechanism: reversible aliases in the audit domain and irreversible hashes in the sharing domain. Names and ID numbers are salted and hashed, with the salt derived from the tenant domain and date, ensuring no cross-period association. Job titles and qualifications are retained, but identifiable details are removed. Device numbers use prefix retention and sequence perturbation to retain device type and capability labels while removing unique identifiers. Location coordinates are generalized at the grid / fence level, selecting grid precision according to the sharing scope. Within a park, functional area level is used; across parks, administrative street level is used to avoid exposing precise locations. To reduce the risk of re-identification, the anonymization module applies k-anonymity constraints to rare combinations. If the personnel-device-location combination within a certain time slice does not meet the threshold, the time window is merged or the dimensionality is reduced to a coarser granularity.

[0098] This embodiment generates an anonymized dataset D based on the desensitized results and assigns hierarchical labels. The hierarchical rules are provided by the platform's governance strategy. For example, L1 is used for industry-wide statistical disclosure, with fields only retaining time slices, functional areas, total resource consumption, and task type; L2 is used for park-level collaboration, adding equipment capability tags and job levels, but excluding individual characteristics; L3 is used for bilateral debriefing between tenants, allowing viewing of reversible anonymizations and more granular time windows under audit authorization. To ensure sharing remains under control, a sharing permission table is constructed, with fields including the sharing scope (visible entity list or tenant group), protection level (corresponding to L1 / L2 / L3), authorization period (start and end times and renewal policy), usage purpose description, and permitted secondary processing operations (e.g., for statistical purposes only, individual identification models cannot be trained). The sharing permission table is bound to access control policies. The access layer matches the accessor's identity and purpose, granting the minimum necessary view. The access process is recorded in the audit log, and abnormal queries will trigger alarms and freezes.

[0099] This embodiment considers boundary scenarios in mutual assistance scenarios. During a sudden power outage at night, a tenant calls upon an emergency electrician and generator from a neighboring building. Due to missing equipment logs in the execution data, the data integration module uses temporarily accessed energy consumption monitoring curves and trajectories to supplement the equipment usage, marking it with confidence tags and noting "alternative evidence" in the settlement entry. In another scenario, a collaborative exercise between a medical enterprise and a data center involves highly sensitive locations. The desensitization module coarses the location to the park-level fence while reducing the time resolution to a half-hour window to avoid inferring the server room location based on continuous trajectories. The shared license is set to Level 2, with the authorization period limited to the exercise month; access is automatically revoked upon expiration.

[0100] The key technical points of this embodiment lie in the standardization and traceable mapping of the resource consumption matrix, and the hierarchical sharing and access control closed loop after anonymization. The former unifies "people, time, things, and energy" into a settlementable matrix expression, eliminating ambiguity in the accounting standards of different tenants; the latter reduces the risk of re-identification through field-level anonymization and k-anonymity constraints, and is further supplemented by hierarchical permissions and minimal views to ensure that external sharing is both useful and restrained. In order to formally characterize the generation of settlement entries, the settlement value of a single task can be defined as V=Σ_j α_j·m_j, where m_j represents the standard measurement value of the resource consumption matrix in the j-th dimension, and α_j is the pricing coefficient of this dimension under the current settlement standard. The pricing coefficient comes from the platform's public rules and time scenario correction items (such as night shift, emergency). V is not a black box calculation, and the physical meaning of each parameter is clear: m_j is a verifiable measurement, α_j is a queryable rule, and both have version and evidence binding in the audit database.

[0101] This embodiment addresses three practical problems in terms of technical effectiveness. First, the root cause of discrepancies in mutual aid accounts lies in inconsistent measurement standards and lack of evidence. By binding settlement records with M and evidence indexes, disputes can be traced back to the original data. Second, privacy risks associated with cross-tenant sharing are mitigated through anonymization and tiered licensing, ensuring that external parties can only see the minimum facts required for the task, not individual details. Third, governance enforceability is ensured through access control and audit logs. When access exceeds the authorized period or calls exceed the sharing scope, the system can immediately reject and record the request based on the sharing license table. By linking S701, S702, and the issuance and evaluation of preceding rules, mutual aid can be reasonably priced and reviewed within confidentiality boundaries, thus strengthening the trustworthy foundation for park collaboration.

[0102] To effectively address the shortcomings of traditional technologies in areas such as tag authentication, rule engines, and cross-domain collaboration, and to provide technical support for intelligent patrol systems, this application provides an embodiment of an intelligent patrol device based on cloud-based SOP dynamic planning and data assetization, used to implement all or part of the aforementioned intelligent patrol method based on cloud-based SOP dynamic planning and data assetization. See [link to embodiment]. Figure 2 The intelligent patrol device based on cloud-based SOP dynamic contingency plans and data assetization specifically includes the following: The communication encryption module 10 is used to construct a secure tag authentication link, collect patrol point data, deploy near-field communication tags to the points, generate a distributed key based on the master key, write the distributed key into the tag control unit, enable the dynamic ciphertext generation module, set the initial value of the counter, record the tenant identifier and point code of the tag, and write the identifier and code into the point database; read the dynamic parameters output by the tag, calculate the tag key based on the tenant identifier, verify the counter value and message authentication code of the dynamic parameters, remove replay data based on the sliding window bitmap, generate a session token, and write the session token into the authentication database; The patrol operation module 20 is used to build an operation rule engine, collect multi-source environmental data, extract time dimension features, climate dimension features, spatial dimension features, load dimension features, and operation dimension features, search the operation rule library based on the features, obtain a set of candidate rules, calculate the rule priority matrix, resolve rule conflict relationships, generate structured operation instructions, send the operation instructions to the mobile terminal, collect the execution data returned by the mobile terminal, extract the execution scoring indicators, and write the scoring indicators into the evaluation database. The collaborative execution module 30 is used to construct a city integration gateway, access city platform events, perform signature verification and timestamp protection on the events, generate a standard event model, match affected areas based on geofences, generate cross-domain collaborative instructions, broadcast the collaborative instructions to target tenants, collect mutual assistance execution data, generate settlement entries, write the settlement entries into the audit database, perform desensitization processing on the execution data, and write the desensitized execution data into the shared database.

[0103] As described above, the intelligent patrol device based on cloud-based SOP dynamic contingency plans and data assetization provided in this application embodiment can achieve secure and reliable identity verification through an innovatively designed tag authentication system, using key distribution and dynamic authentication. It constructs a rule engine mechanism, combining multi-dimensional features and conflict resolution to establish reasonable operation management. Furthermore, it introduces urban integration, ensuring effective collaboration through event processing and data sharing. This method effectively addresses the shortcomings of traditional technologies in tag authentication, rule engines, and cross-domain collaboration, providing technical support for intelligent patrol.

[0104] From a hardware perspective, in order to effectively address the shortcomings of traditional technologies in areas such as tag authentication, rule engines, and cross-domain collaboration, and to provide technical support for intelligent patrol, this application provides an embodiment of an electronic device for implementing all or part of the aforementioned intelligent patrol method based on cloud-based SOP dynamic plans and data assetization. The electronic device specifically includes the following components: The system comprises a processor, memory, a communications interface, and a bus; wherein the processor, memory, and communications interface communicate with each other via the bus; the communications interface is used to realize information transmission between the intelligent patrol device based on cloud-based SOP dynamic contingency plans and data assetization and core business systems, user terminals, and related databases and other related devices; the logic controller can be a desktop computer, tablet computer, or mobile terminal, etc., and this embodiment is not limited to these. In this embodiment, the logic controller can be implemented with reference to the embodiments of the intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization, and the embodiments of the intelligent patrol device based on cloud-based SOP dynamic contingency plans and data assetization, the content of which is incorporated herein, and repeated details will not be described again.

[0105] It is understood that the user terminal may include smartphones, tablet computers, network set-top boxes, portable computers, desktop computers, personal digital assistants (PDAs), in-vehicle devices, smart wearable devices, etc. Among these, the smart wearable devices may include smart glasses, smartwatches, smart bracelets, etc.

[0106] In practical applications, the intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization can be partially executed on the electronic device side as described above, or all operations can be completed on the client device. The choice can be made based on the processing power of the client device and the limitations of the user's usage scenario. This application does not impose any limitations on this. If all operations are completed on the client device, the client device may further include a processor.

[0107] The aforementioned client device may have a communication module (i.e., a communication unit) that can communicate with a remote server to achieve data transmission with the server. The server may include a server on the task scheduling center side; in other implementation scenarios, it may also include a server on an intermediate platform, such as a server on a third-party server platform that has a communication link with the task scheduling center server. The server may include a single computer device, a server cluster consisting of multiple servers, or a distributed server structure.

[0108] Figure 3 This is a schematic block diagram illustrating the system configuration of the electronic device 9600 according to an embodiment of this application. Figure 3 As shown, the electronic device 9600 may include a central processing unit 9100 and a memory 9140; the memory 9140 is coupled to the central processing unit 9100. It is worth noting that... Figure 3This is an example; other types of structures can also be used to supplement or replace this structure to achieve telecommunications functions or other functions.

[0109] In one embodiment, the intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization can be integrated into the central processing unit 9100. The central processing unit 9100 can be configured to perform the following controls: Step S101: Construct a tag authentication security link, collect patrol point data, deploy near-field communication tags to the points, generate a distributed key based on the master key, write the distributed key into the tag control unit, enable the dynamic ciphertext generation module, set the initial value of the counter, record the tenant identifier and point code of the tag, and write the identifier and code into the point database; read the dynamic parameters output by the tag, calculate the tag key according to the tenant identifier, verify the counter value and message authentication code of the dynamic parameters, remove replay data based on the sliding window bitmap, generate a session token, and write the session token into the authentication database; Step S102: Construct an operation rule engine, collect multi-source environmental data, extract time dimension features, climate dimension features, spatial dimension features, load dimension features, and operation dimension features, search the operation rule library based on the features, obtain a set of candidate rules, calculate the rule priority matrix, resolve rule conflict relationships, generate structured operation instructions, send the operation instructions to the mobile terminal, collect the execution data returned by the mobile terminal, extract the execution scoring indicators, and write the scoring indicators into the evaluation database; Step S103: Construct a city-wide integrated gateway, access city platform events, perform signature verification and timestamp protection on the events, generate a standard event model, match affected areas based on geofences, generate cross-domain collaborative instructions, broadcast the collaborative instructions to target tenants, collect mutual assistance execution data, generate settlement entries, write the settlement entries into the audit database, perform desensitization processing on the execution data, and write the desensitized execution data into the shared database.

[0110] As described above, the electronic device provided in this application embodiment achieves secure and reliable identity verification through an innovatively designed tag authentication system, utilizing key distribution and dynamic authentication. A rule engine mechanism is constructed, combining multi-dimensional features and conflict resolution to establish reasonable operation management. Urban integration is introduced, ensuring the effectiveness of collaboration through event processing and data sharing. This method effectively addresses the shortcomings of traditional technologies in tag authentication, rule engines, and cross-domain collaboration, providing technical support for intelligent patrol systems.

[0111] In another implementation, the intelligent patrol device based on cloud-based SOP dynamic planning and data assetization can be configured separately from the central processing unit 9100. For example, the intelligent patrol device based on cloud-based SOP dynamic planning and data assetization can be configured as a chip connected to the central processing unit 9100, and the intelligent patrol method function based on cloud-based SOP dynamic planning and data assetization can be realized through the control of the central processing unit.

[0112] like Figure 3 As shown, the electronic device 9600 may further include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is worth noting that the electronic device 9600 does not necessarily need to include these components. Figure 3 All components shown; in addition, the electronic device 9600 may also include Figure 3 For components not shown, please refer to existing technology.

[0113] like Figure 3 As shown, the central processing unit 9100, sometimes also referred to as a controller or operating control, may include a microprocessor or other processor device and / or logic device, which receives inputs and controls the operation of various components of the electronic device 9600.

[0114] The memory 9140 may be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It may store the aforementioned failure-related information, and also store a program for executing that information. The central processing unit 9100 may execute the program stored in the memory 9140 to perform information storage or processing, etc.

[0115] Input unit 9120 provides input to central processing unit 9100. Input unit 9120 may be, for example, a keypad or touch input device. Power supply 9170 provides power to electronic device 9600. Display 9160 displays images and text. Display may be, for example, an LCD display, but is not limited thereto.

[0116] The memory 9140 can be a solid-state memory, such as a read-only memory (ROM), random access memory (RAM), a SIM card, etc. It can also be a memory that retains information even when power is off, can be selectively erased, and contains more data; examples of this type of memory are sometimes referred to as EPROMs. The memory 9140 can also be some other type of device. The memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application / function storage unit 9142 for storing application programs and function programs or processes for executing the operation of the electronic device 9600 via the central processing unit 9100.

[0117] The memory 9140 may also include a data storage unit 9143 for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit 9144 of the memory 9140 may include various drivers for the electronic device for communication functions and / or for performing other functions of the electronic device (such as messaging applications, address book applications, etc.).

[0118] The communication module 9110 is a transmitter / receiver that sends and receives signals via the antenna 9111. The communication module 9110 (transmitter / receiver) is coupled to the central processing unit 9100 to provide input signals and receive output signals, which is the same as in a conventional mobile communication terminal.

[0119] Based on different communication technologies, multiple communication modules 9110 can be configured in the same electronic device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication module 9110 (transmitter / receiver) is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide audio output via the speaker 9131 and receive audio input from the microphone 9132, thereby realizing typical telecommunications functions. The audio processor 9130 may include any suitable buffer, decoder, amplifier, etc. Additionally, the audio processor 9130 is coupled to a central processing unit 9100, enabling on-device recording via the microphone 9132 and on-device playback of stored audio via the speaker 9131.

[0120] Embodiments of this application also provide a computer-readable storage medium capable of implementing all steps of the intelligent patrol method based on cloud-based SOP dynamic planning and data assetization, where the execution subject is a server or client, as described in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the intelligent patrol method based on cloud-based SOP dynamic planning and data assetization, where the execution subject is a server or client, as described in the above embodiments. For example, when the processor executes the computer program, it implements the following steps: Step S101: Construct a tag authentication security link, collect patrol point data, deploy near-field communication tags to the points, generate a distributed key based on the master key, write the distributed key into the tag control unit, enable the dynamic ciphertext generation module, set the initial value of the counter, record the tenant identifier and point code of the tag, and write the identifier and code into the point database; read the dynamic parameters output by the tag, calculate the tag key according to the tenant identifier, verify the counter value and message authentication code of the dynamic parameters, remove replay data based on the sliding window bitmap, generate a session token, and write the session token into the authentication database; Step S102: Construct an operation rule engine, collect multi-source environmental data, extract time dimension features, climate dimension features, spatial dimension features, load dimension features, and operation dimension features, search the operation rule library based on the features, obtain a set of candidate rules, calculate the rule priority matrix, resolve rule conflict relationships, generate structured operation instructions, send the operation instructions to the mobile terminal, collect the execution data returned by the mobile terminal, extract the execution scoring indicators, and write the scoring indicators into the evaluation database; Step S103: Construct a city-wide integrated gateway, access city platform events, perform signature verification and timestamp protection on the events, generate a standard event model, match affected areas based on geofences, generate cross-domain collaborative instructions, broadcast the collaborative instructions to target tenants, collect mutual assistance execution data, generate settlement entries, write the settlement entries into the audit database, perform desensitization processing on the execution data, and write the desensitized execution data into the shared database.

[0121] As described above, the computer-readable storage medium provided in this application embodiment achieves secure and reliable identity verification through an innovatively designed tag authentication system, utilizing key distribution and dynamic authentication. A rule engine mechanism is constructed, combining multi-dimensional features and conflict resolution to establish reasonable operation management. Urban integration is introduced, ensuring the effectiveness of collaboration through event processing and data sharing. This method effectively addresses the shortcomings of traditional technologies in tag authentication, rule engines, and cross-domain collaboration, providing technical support for intelligent patrol systems.

[0122] Embodiments of this application also provide a computer program product capable of implementing all steps of the intelligent patrol method based on cloud-based SOP dynamic planning and data assetization, where the execution subject is a server or client, as described in the above embodiments. When executed by a processor, this computer program / instruction implements the steps of the intelligent patrol method based on cloud-based SOP dynamic planning and data assetization. For example, the computer program / instruction implements the following steps: Step S101: Construct a tag authentication security link, collect patrol point data, deploy near-field communication tags to the points, generate a distributed key based on the master key, write the distributed key into the tag control unit, enable the dynamic ciphertext generation module, set the initial value of the counter, record the tenant identifier and point code of the tag, and write the identifier and code into the point database; read the dynamic parameters output by the tag, calculate the tag key according to the tenant identifier, verify the counter value and message authentication code of the dynamic parameters, remove replay data based on the sliding window bitmap, generate a session token, and write the session token into the authentication database; Step S102: Construct an operation rule engine, collect multi-source environmental data, extract time dimension features, climate dimension features, spatial dimension features, load dimension features, and operation dimension features, search the operation rule library based on the features, obtain a set of candidate rules, calculate the rule priority matrix, resolve rule conflict relationships, generate structured operation instructions, send the operation instructions to the mobile terminal, collect the execution data returned by the mobile terminal, extract the execution scoring indicators, and write the scoring indicators into the evaluation database; Step S103: Construct a city-wide integrated gateway, access city platform events, perform signature verification and timestamp protection on the events, generate a standard event model, match affected areas based on geofences, generate cross-domain collaborative instructions, broadcast the collaborative instructions to target tenants, collect mutual assistance execution data, generate settlement entries, write the settlement entries into the audit database, perform desensitization processing on the execution data, and write the desensitized execution data into the shared database.

[0123] As described above, the computer program product provided in this application, through an innovative design of a tag authentication system, achieves secure and reliable identity verification via key distribution and dynamic authentication. It constructs a rule engine mechanism, combining multi-dimensional features and conflict resolution to establish reasonable operation management. Furthermore, it introduces city integration, ensuring the effectiveness of collaboration through event processing and data sharing. This method effectively addresses the shortcomings of traditional technologies in tag authentication, rule engines, and cross-domain collaboration, providing technical support for intelligent patrol systems.

[0124] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0125] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0126] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0127] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0128] Specific embodiments have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A smart patrol method based on cloud-based SOP dynamic contingency plans and data assetization, characterized in that, The method includes: A secure tag authentication link is constructed, patrol point data is collected, near-field communication tags are deployed to the points, a distributed key is generated based on the master key, the distributed key is written into the tag control unit, the dynamic ciphertext generation module is enabled, the initial value of the counter is set, the tenant identifier and point code of the tag are recorded, and the identifier and code are written into the point database; the dynamic parameters output by the tag are read, the tag key is calculated based on the tenant identifier, the counter value of the dynamic parameters and the message authentication code are verified, replay data is removed based on the sliding window bitmap, a session token is generated, and the session token is written into the authentication database; A work rule engine is constructed, multi-source environmental data is collected, and time-dimensional features, climate-dimensional features, spatial-dimensional features, load-dimensional features, and operational-dimensional features are extracted. Based on the features, the work rule library is searched to obtain a set of candidate rules, a rule priority matrix is ​​calculated, rule conflict relationships are resolved, structured work instructions are generated, the work instructions are sent to a mobile terminal, the execution data returned by the mobile terminal is collected, execution scoring indicators are extracted, and the scoring indicators are written into an evaluation database. A city-wide integrated gateway is constructed to access city platform events. Signature verification and timestamp protection are performed on the events, a standard event model is generated, affected areas are matched based on geofences, cross-domain collaborative instructions are generated, the collaborative instructions are broadcast to target tenants, mutual assistance execution data is collected, settlement entries are generated, the settlement entries are written to the audit database, the execution data is anonymized, and the anonymized execution data is written to the shared database.

2. The intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization as described in claim 1, characterized in that, The process of constructing a tag authentication security link involves collecting patrol point data, deploying near-field communication tags to the points, generating distributed keys based on the master key, writing the distributed keys into the tag control unit, enabling the dynamic ciphertext generation module, setting an initial counter value, recording the tenant identifier and point code of the tag, and writing the identifier and code into the point database. Collect patrol point data, construct a key generation module, calculate the combined hash value of tenant identifier and key version number, extract the master key from the key management system based on the hash value, perform key derivation calculation on the master key and the unique identifier of the point to generate a distributed key, encrypt and package the distributed key to generate a key configuration data packet, write the configuration data packet into the control unit of the near-field communication tag, record the initial configuration parameters of the tag, construct a deployment record table containing point code, tenant identifier and configuration time, and write the deployment record table into the point database; The control unit of the near-field communication tag is read, a dynamic ciphertext generation module is constructed, the dynamic ciphertext generation module is written into the tag storage area, the initial value of the counter of the dynamic ciphertext generation module is configured, an anti-tampering protection unit is constructed, the anti-tampering protection unit is written into the tag configuration area, the anti-tampering write protection mechanism is enabled, a security configuration table containing anti-tampering status, counter value, and protection parameters is generated, the integrity of the security configuration table is verified, and the security configuration table is written into the security database.

3. The intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization as described in claim 1, characterized in that, The steps include reading the dynamic parameters output by the tag, calculating the tag key based on the tenant identifier, verifying the counter value of the dynamic parameters and the message authentication code, removing replay data based on a sliding window bitmap, generating a session token, and writing the session token into the authentication database. Read the dynamic parameters output by the tag, construct a key calculation module, input the tenant identifier and key version number into the key derivation function to generate a tag key, decrypt the tag key to obtain the counter value and message authentication code, combine the counter value and authentication code into an authentication data packet, construct a verification record table containing authentication time, authentication location and device identifier, and write the verification record table into the authentication database. The system reads the verification record table, constructs a sliding window module, calculates the sliding range of the counter value, generates a window bitmap matrix, performs deduplication on the bitmap matrix, removes replay data, generates a session token, binds the session token to the device identifier, constructs an authorization record table containing the token identifier, validity period, and geofence, performs encryption signing on the authorization record table, and writes the authorization record table into the token database.

4. The intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization as described in claim 1, characterized in that, The aforementioned operation rule engine collects multi-source environmental data, extracts time-dimensional features, climate-dimensional features, spatial-dimensional features, load-dimensional features, and operational-dimensional features, and retrieves a set of candidate rules from the operation rule base based on these features, including: A multi-source data acquisition module is constructed to access meteorological monitoring data, traffic flow data, population density data, energy consumption monitoring data, and equipment status data. The monitoring data is normalized to generate a feature vector matrix. The feature matrix is ​​grouped by dimension to construct an acquisition record table containing data type, acquisition time, and data source. The acquisition record table is written into an environmental database. The feature matrix in the environmental database is read, a feature extraction module is constructed, time period features, temperature and humidity features, spatial distribution features, load level features, and activity status features are calculated, the features are combined into feature description vectors, the job rule base is retrieved based on the feature vectors, a similarity calculation unit is constructed, a candidate rule set is generated, and the candidate rule set is written into the rule database.

5. The intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization as described in claim 1, characterized in that, The calculation rule priority matrix resolves rule conflicts, generates structured job instructions, sends the job instructions to the mobile terminal, collects the execution data returned by the mobile terminal, extracts execution scoring indicators, and writes the scoring indicators into the evaluation database, including: Read the candidate rule set, construct a priority calculation module, quantify and assign values ​​to rule attributes, generate a rule scoring vector, convert the scoring vector into a priority matrix, detect rule conflict items based on the priority matrix, construct a conflict resolution unit, generate a conflict-free rule sequence, convert the rule sequence into a structured operation instruction, digitally sign the operation instruction, and send the operation instruction to the mobile terminal. The system reads the execution data returned by the mobile terminal, constructs a scoring calculation module, extracts quantitative indicators such as task completion rate, execution time, and operation standardization, generates an execution scoring vector, normalizes the scoring vector, constructs an evaluation record table containing execution time, execution location, and execution personnel, performs data verification on the evaluation record table, and writes the evaluation record table into the evaluation database.

6. The intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization as described in claim 1, characterized in that, The process of constructing a city-wide integrated gateway, accessing city platform events, performing signature verification and timestamp protection on the events, generating a standard event model, matching affected areas based on geofencing, generating cross-domain collaboration instructions, and broadcasting the collaboration instructions to target tenants includes: A city event access module is constructed to receive meteorological events, fire events, traffic events, and emergency events pushed by the city platform, extract event signature data, verify the validity of the signature, construct a timestamp verification unit to perform timestamp protection on the event, generate a standard event model containing event type, severity, and impact period, and write the standard event model into the event database. Read the standard event model, construct a geofence matching module, calculate the polygonal area of ​​the event's impact range, generate a spatial index matrix, match the affected parks and tenants based on the spatial index, construct a cross-domain collaborative instruction generator, convert the event model into collaborative instructions, group and encode the collaborative instructions, generate a tenant-oriented broadcast table, and write the broadcast table into the instruction database.

7. The intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization as described in claim 1, characterized in that, The process of collecting mutual assistance execution data, generating settlement entries, writing the settlement entries into the audit database, de-identifying the execution data, and writing the de-identified execution data into the shared database includes: Read tenant mutual aid execution data, build a data integration module, extract statistical data on mutual aid duration, number of personnel, and equipment usage, generate a resource consumption matrix, convert the resource matrix into settlement entries, build a settlement record table containing mutual aid number, execution time, and resource details, perform integrity verification on the settlement record table, and write the settlement record table into the audit database; Read the mutual aid execution data, construct a data anonymization module, anonymize the fields of personnel identity information, equipment number, and location coordinates, generate an anonymized dataset, classify and label the anonymized dataset, construct a shared license table containing sharing scope, protection level, and authorization period, perform access control on the shared license table, and write the shared license table into the shared database.

8. A smart patrol device based on cloud-based SOP dynamic contingency plans and data assetization, characterized in that, The device includes: The communication encryption module is used to construct a secure tag authentication link, collect patrol point data, deploy near-field communication tags to the points, generate a distributed key based on the master key, write the distributed key into the tag control unit, enable the dynamic ciphertext generation module, set the initial value of the counter, record the tenant identifier and point code of the tag, and write the identifier and code into the point database; read the dynamic parameters output by the tag, calculate the tag key based on the tenant identifier, verify the counter value and message authentication code of the dynamic parameters, remove replay data based on the sliding window bitmap, generate a session token, and write the session token into the authentication database; The patrol operation module is used to build an operation rule engine, collect multi-source environmental data, extract time dimension features, climate dimension features, spatial dimension features, load dimension features, and operation dimension features, retrieve the operation rule library based on the features, obtain a set of candidate rules, calculate the rule priority matrix, resolve rule conflict relationships, generate structured operation instructions, send the operation instructions to the mobile terminal, collect the execution data returned by the mobile terminal, extract the execution scoring indicators, and write the scoring indicators into the evaluation database. The collaborative execution module is used to build a city-wide integrated gateway, access city platform events, perform signature verification and timestamp protection on the events, generate standard event models, match affected areas based on geofences, generate cross-domain collaborative instructions, broadcast the collaborative instructions to target tenants, collect mutual assistance execution data, generate settlement entries, write the settlement entries to the audit database, perform anonymization processing on the execution data, and write the anonymized execution data to the shared database.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the intelligent patrol method based on cloud-based SOP dynamic contingency plans and data assetization as described in any one of claims 1 to 7.

Images