A gate access, vehicle and security device access management method for a smart park

Abstract

The application relates to the technical field of intelligent management, in particular to a gate access, vehicle and security device access management method for a smart park. The method comprises the following steps: collecting real-time running state data streams of various access devices in the park, and performing heterogeneous protocol analysis and unified identification mapping to generate standardized device metadata; constructing a dynamic topology relationship graph of the access devices based on the standardized device metadata and generating a correlation coupling matrix; inputting the correlation coupling matrix into a pre-trained traffic prediction model for learning to generate a park network traffic prediction distribution graph in a future time window; dynamically adjusting according to the park network traffic prediction distribution graph to generate an access scheduling strategy; and issuing configuration instructions to each device through an edge gateway based on the access scheduling strategy, and feeding back device execution feedback in real time, so that the collaborative access management of various devices in the park is realized. The application can improve the intelligent level of park device management and control and the network resource utilization efficiency.

Description

Technical Field

[0001] This invention relates to the field of intelligent management technology, and in particular to a method for managing access control, vehicle and security equipment in smart parks. Background Technology

[0002] Smart parks, relying on IoT, edge computing, and intelligent sensing technologies, achieve automated, digital, and intelligent management of park security, personnel access, and vehicle entry and exit, and are a core unit of modern smart city construction. Access control equipment, vehicle gate equipment, and security camera equipment are the most critical and widely deployed front-end sensing and control terminals in smart parks, undertaking key tasks such as personnel authorization verification, vehicle entry and exit scheduling, and panoramic security monitoring of the park. These devices are numerous, diverse, have varying data interaction frequencies, and exhibit significant heterogeneity in communication protocols. Their access stability, the rationality of network resource allocation, and the level of collaborative device management directly determine the overall operational efficiency, security response capabilities, and network reliability of the smart park.

[0003] Currently, traditional smart park equipment access management systems suffer from severe problems of poor device heterogeneity compatibility and significant data fragmentation. Park access control systems, vehicle gates, and security cameras are mostly deployed independently by different manufacturers, with inconsistent communication protocols, data formats, and device identification systems, representing typical heterogeneous IoT terminals. Traditional management platforms lack standardized protocol parsing and unified identifier mapping mechanisms, making it impossible to normalize the operational data streams of multi-source heterogeneous devices. This results in chaotic device metadata and non-standardized ledger information, preventing the platform from fully grasping the actual operational status of all park terminal devices. Consequently, the level of granular device access management is low, reducing network resource utilization. Summary of the Invention

[0004] Therefore, the present invention needs to provide a method for access control, vehicle and security equipment access management for smart parks to solve at least one of the above-mentioned technical problems.

[0005] To achieve the above objectives, a method for managing access control, vehicle, and security equipment in smart parks includes the following steps: Step S1: Collect real-time operating status data streams of each access device in the park, and perform heterogeneous protocol parsing and unified identifier mapping on the real-time operating status data streams to generate standardized device metadata containing device type, physical address and communication protocol; Step S2: Construct a dynamic topology graph of access devices based on standardized device metadata, and generate an association coupling matrix representing the collaborative dependency relationship between devices according to the connection strength and data exchange frequency of each node in the dynamic topology graph; Step S3: Input the correlation coupling matrix into the pre-trained traffic prediction model, and learn the spatiotemporal dependency pattern between access devices through the graph convolutional network layer inside the traffic prediction model to generate a campus network traffic prediction distribution map within the future time window. Step S4: Based on the predicted distribution map of the park's network traffic, dynamically adjust the access permissions and data sampling frequency of the park's access control, vehicle gates, and security cameras to generate an access scheduling strategy; Step S5: Based on the access scheduling policy, configuration instructions are sent to each device through the edge gateway, and the device execution feedback is transmitted back in real time, thereby realizing collaborative access management of multiple types of devices in the park.

[0006] The beneficial effects of this invention are: The access control, vehicle, and security equipment access management method for smart parks proposed in this invention offers several advantages over existing technologies. Firstly, by collecting real-time operational status data streams from all access devices in the park and performing heterogeneous protocol parsing and unified identifier mapping, the method can normalize and integrate raw data from access control, vehicle gates, and security camera devices of different manufacturers and types. Secondly, by unifying data processing standards, this step organizes and integrates core information such as device type, physical address, and communication protocol to form standardized and unified device metadata. This completely breaks down data barriers between multi-source heterogeneous devices, solving the problems of poor adaptability and fragmented, disordered data in traditional models. It provides complete, standardized, and accurate basic data support for subsequent device topology construction, traffic analysis, and intelligent scheduling, effectively improving the standardization of data management for park terminal devices and addressing the inefficient use of network resources from the source. Thirdly, by building a dynamic topology graph based on standardized device metadata and generating an association coupling matrix by combining device node connection strength and data exchange frequency, the method specifically addresses the shortcomings of traditional park device management, such as the lack of a systematic topology architecture and the inability to identify device collaborative dependencies. This step reconstructs the overall device access architecture through a visualized and dynamic topology map, quantifies the frequency of data exchange and the tightness of connections between devices, and transforms abstract device collaboration relationships into a quantifiable coupling matrix. It clearly presents the spatiotemporal correlations and operational dependencies of various core terminal devices, compensating for the lack of device linkage analysis capabilities in traditional systems. This provides core correlation features to support subsequent intelligent prediction of network traffic and solidifies the data analysis foundation for device collaborative management. By importing the device correlation coupling matrix into a pre-trained traffic prediction model and using graph convolutional network layers to learn device spatiotemporal dependency patterns, a future time window campus network traffic prediction distribution map is generated. This effectively solves the problems of traditional campuses lacking proactive traffic prediction capabilities and passively lagging network resource allocation. Based on the previously quantified device collaboration coupling relationships, this step deeply explores the spatiotemporal variation patterns and traffic transmission characteristics of device operation, enabling proactive prediction of the overall network traffic situation in the campus. It deduces the differences in traffic demand of various terminal devices at different times, providing a scientific data basis for subsequent dynamic adjustment of device operating parameters and optimization of network resource allocation, significantly improving the foresight and rationality of campus network resource allocation. By dynamically adjusting access permissions and data sampling frequencies for access control systems, vehicle gates, and security cameras based on network-wide traffic prediction and distribution trends, this approach addresses industry pain points such as fixed equipment parameters, rigid resource allocation, and low operational efficiency in traditional industrial parks. This step adapts equipment operating parameters to future traffic trends, optimizing access permissions during peak traffic periods to ensure stable operation of core security and access control equipment, and reducing redundant sampling frequencies and ineffective data transmission during off-peak traffic periods. This enables on-demand allocation of network resources, adapting to the operational needs of equipment in different scenarios, and comprehensively improving the intelligence level of industrial park equipment management and network resource utilization efficiency.By relying on established access scheduling strategies and issuing configuration commands through edge gateways, combined with real-time device execution feedback to form a closed-loop management system, this approach completely solves the problems of lagging device management, large execution deviations, and weak collaborative operation and maintenance capabilities in traditional park systems. This step leverages edge computing technology to achieve rapid command issuance and localized execution, shortening device control response time. Simultaneously, by transmitting execution feedback data in real time, it dynamically verifies the effectiveness of the scheduling strategy, promptly corrects device operational deviations, and achieves integrated collaborative management of access control, gate barriers, and security cameras. This constructs a fully intelligent management system encompassing perception, analysis, scheduling, and feedback, significantly improving the overall operation and maintenance efficiency of park equipment, security response speed, and network stability. Attached Figure Description

[0007] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart illustrating the steps of the access control, vehicle and security equipment access management method for smart parks according to the present invention. Figure 2 for Figure 1 A detailed flowchart of step S1; Figure 3 for Figure 1 A detailed flowchart of step S2. Detailed Implementation

[0008] The technical method of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0009] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0010] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0011] To achieve the above objectives, please refer to Figure 1 This invention provides a method for access control, vehicle and security equipment access management in smart parks, including the following steps: Step S1: Collect real-time operating status data streams of each access device in the park, and perform heterogeneous protocol parsing and unified identifier mapping on the real-time operating status data streams to generate standardized device metadata containing device type, physical address and communication protocol; Step S2: Construct a dynamic topology graph of access devices based on standardized device metadata, and generate an association coupling matrix representing the collaborative dependency relationship between devices according to the connection strength and data exchange frequency of each node in the dynamic topology graph; Step S3: Input the correlation coupling matrix into the pre-trained traffic prediction model, and learn the spatiotemporal dependency pattern between access devices through the graph convolutional network layer inside the traffic prediction model to generate a campus network traffic prediction distribution map within the future time window. Step S4: Based on the predicted distribution map of the park's network traffic, dynamically adjust the access permissions and data sampling frequency of the park's access control, vehicle gates, and security cameras to generate an access scheduling strategy; Step S5: Based on the access scheduling policy, configuration instructions are sent to each device through the edge gateway, and the device execution feedback is transmitted back in real time, thereby realizing collaborative access management of multiple types of devices in the park.

[0012] Furthermore, as an embodiment of the present invention, reference is made to... Figure 2 As shown, Figure 1 A detailed flowchart of step S1 is shown below. In this embodiment, step S1 includes the following steps: Step S11: By deploying IoT gateways in various areas of the park, listen to and capture raw data packets from different access control systems, vehicle gates, and security cameras in real time; Step S12: Extract the protocol header field and payload data from the original data packets, and perform pattern matching through the protocol feature library to identify the private or standard communication protocol type to which each original data packet belongs; Step S13: Based on the identified private or standard communication protocol type, call the corresponding protocol parsing plugin to decode the payload data, and reconstruct the decoded data fields according to a unified metadata template to generate an intermediate data unit containing a unique device identifier, function status code and timestamp. Step S14: Cross-compare the device unique identifier in the intermediate data unit with the pre-registered device asset database. If the comparison is successful, assign a globally unique logical address label to the intermediate data unit and mark its device category and security level. Step S15: Serialize and encapsulate the intermediate data unit carrying the logical address tag to generate standardized device metadata.

[0013] In this embodiment, multiple IoT gateways are deployed within the smart park, distributed across various entrances and exits, parking lot entrances and exits, main passageways, and key monitoring areas. Each IoT gateway is equipped with multi-protocol network interfaces, including but not limited to RS485 bus interfaces, Ethernet RJ45 interfaces, wireless RF modules, and fiber optic transceivers, to simultaneously connect to access control controllers, vehicle gate control boards, and security cameras from different manufacturers. The IoT gateway continuously runs a background monitoring process, which calls libpcap library functions at the operating system level to capture data frames passing through all network interfaces of the gateway. For data streams on the serial bus, it reads the serial port buffer contents through polling. When a person swipes their card to open the door, the access control controller sends a binary message via the RS485 bus to the gateway. This message contains a preamble, device address code, command code, data segment, and checksum. Similarly, when a vehicle approaches the gate and triggers the ground loop coil, the gate control board sends a JSON-formatted HTTP POST request message via a TCP connection, containing the license plate number, entry timestamp, and gate number fields. The security camera continuously pushes H.264 encoded video streams via the RTSP protocol and sends an additional ONVIF protocol event notification message when a moving target is detected. After capturing all these raw data packets, the IoT gateway first strips the physical layer frame header and trailer to extract the complete IP data packet or serial data frame. Next, it calls a protocol signature library for pattern matching. This library pre-stores signatures for various proprietary protocols, such as the specific start byte sequence 0xAA55 for a certain brand's access control protocol, and signatures for standard protocols such as the "POST / api / access" string in the HTTP header. For packets that cannot match any known features, a heuristic classification is performed based on packet length distribution, port number range, and payload entropy value, temporarily classifying them as unknown types and recording the original hexadecimal dump. After protocol identification, the gateway loads the corresponding protocol parsing plugin. Each plugin is an independently compiled dynamic link library file specifically designed to handle the decoding logic of a particular protocol. For example, for a certain brand's access control protocol plugin, its internal implementation includes cyclic redundancy check verification, address field mapping, and data segmentation rules. It extracts the card number, reader number, door opening status code, and timestamp fields from the payload one by one. The gateway then fills these fields into a unified metadata template. This template defines a fixed key-value structure, including a device unique identifier field, a function status code field, and a timestamp field. The device unique identifier is formed by concatenating the device type prefix with the MAC address or factory serial number. The function status code is uniformly encoded as an integer, for example, 0 indicates normal door opening, 1 indicates access denied, and 2 indicates timeout. The timestamp uses UTC format, accurate to the millisecond level.The gateway then cross-references the unique device identifier in the generated intermediate data unit with the pre-registered device asset database, which is stored in a locally embedded SQLite table. Each record contains fields for device ID, device category, installation location, and security level. If the comparison is successful, the gateway assigns a globally unique logical address tag to the intermediate data unit. This tag consists of three segments: park number, area number, and device serial number, in the form of PK01-A03-017. Simultaneously, the gateway marks the device category of the intermediate data unit as one of access control, barrier gate, or camera, and the security level as ordinary, important, or critical. Finally, the gateway calls the Protocol Buffers serialization library to compress and encode the intermediate data unit with the logical address tag into binary format, then adds a TLV encapsulation layer to generate standardized device metadata. This standardized device metadata is ultimately pushed to a message queue for further processing.

[0014] Furthermore, as an embodiment of the present invention, reference is made to... Figure 3 As shown, Figure 1 A detailed flowchart of step S2 is shown below. In this embodiment, step S2 includes the following steps: Step S21: Extract the physical installation location information and logical address tags of each access device from the standardized device metadata, and use the physical installation location information and logical address tags as node attributes to create corresponding device node instances in the graph database; Step S22: Traverse all device node instances, analyze whether there is a data interaction record between any two nodes in the historical time period. If there is, create an undirected edge between the two nodes and calculate the initial connection strength of the edge based on the number of interactions and the size of the data packet. Step S23: For node pairs with undirected edges, further analyze the periodicity of their data interaction to extract the main frequency component of the interaction frequency, and use the amplitude of the main frequency component as a synchronization coefficient to measure the degree of collaborative dependence between access devices. Step S24: Perform coupling analysis on the initial connection strength and synchronization coefficient to generate associated coupling weights, and use the associated coupling weights as the coupling edge weights of the corresponding undirected edges to update the graph database, thereby forming a dynamic topological relationship graph; Step S25: Extract the coupling edge weights of all edges in the dynamic topology graph and arrange them into a two-dimensional matrix. The row and column indices of this two-dimensional matrix correspond to the device nodes that initiate and receive the interaction, respectively. The matrix elements are the associated coupling weights, thereby generating the associated coupling matrix.

[0015] In this embodiment, by consuming standardized device metadata from the message queue, the physical installation location information of each device's metadata is first parsed. This information originates from the floor, room number, and coordinate grid number recorded in the device asset database, such as the fire escape door on the east side of the 3rd floor of Building A. Simultaneously, the three-segment code in the logical address label is extracted. The server starts the Neo4j graph database client and executes the Cypher creation statement to create a new node instance for each device. The node's attribute dictionary contains the device ID, logical address label, installation location string, device category enumeration value, and security level integer value. For example, creating an access control node would have the attributes {id: “PK01-A03-017”, label: “A3-FireDoor”, location: “Fire escape door on the east side of the 3rd floor of Building A”, category: “door”, securityLevel: 2}. After all device nodes are created, the server begins traversing all node pairs. The traversal process uses a double loop: the outer loop traverses all nodes, while the inner loop starts from the next node after the current node and continues to the end, avoiding redundant calculations. For each pair of nodes, the server queries the historical data interaction record table, a wide table stored in PostgreSQL, which records the interaction flow of standardized device metadata for each transaction, including the source device logical address label, the target device logical address label, the interaction timestamp, and the packet size in bytes. The query conditions are either the source device equals node A and the target device equals node B, or the source device equals node B and the target device equals node A, with the time range limited to the past 30 days. If the query result set is not empty, it indicates that there is data interaction between the two nodes, and the server creates an undirected edge for these two nodes in the graph database. The edge attributes are initially empty. Then, the server counts the number of records in the query result set as the number of interactions and sums the sizes of all packets to obtain the total number of bytes. The initial connection strength is calculated by multiplying the number of interactions by 100 and then dividing the total number of bytes by 1024 and rounding down. This value reflects the basic level of data exchange activity between the two devices. Next, the server performs periodic analysis on the interaction timestamp sequence of the two nodes, extracts all interaction timestamps, sorts them in ascending order of time, and calculates the difference between adjacent timestamps to obtain a set of time intervals. Discrete Fourier Transform (DFT) is applied to these time interval sequences, and Fast Fourier Transform (FFTW) is performed using FFTW library functions to obtain spectral data. The time interval corresponding to the frequency component with the highest amplitude in the spectrum is the main cycle of interaction between the devices, for example, an interaction occurs every 5 minutes. The amplitude of this main frequency component is normalized and used as the synchronization coefficient. The normalization method is to divide the amplitude by the sum of the amplitudes of all frequency components, so that the synchronization coefficient is between 0 and 1. A higher synchronization coefficient indicates that the working rhythm of the two devices is more consistent. For example, if the camera immediately captures an image after each time the barrier gate is raised, this close cooperation will be reflected in a high synchronization coefficient.Then, the initial connection strength and synchronization coefficient are coupled and analyzed. The coupling formula is the initial connection strength multiplied by 1 plus the square of the synchronization coefficient. This preserves the basic activity level while amplifying the impact of collaborative dependencies. The calculation result is used as the association coupling weight, assigned to the weight attribute of this undirected edge, and updated in the graph database. After traversing all node pairs, a dynamic topology graph containing hundreds of nodes and thousands of edges is formed in the graph database. The server then queries the graph database for the source and target nodes and weight values ​​of all edges, constructing an N x N two-dimensional matrix, where N is the total number of device nodes. The element in the i-th row and j-th column of the matrix equals the weight of the edge from node i to node j; if no edge exists, it is filled with zero. Since the edges are undirected, the matrix is ​​symmetric, i.e., the element in the i-th row and j-th column equals the element in the j-th row and i-th column. This two-dimensional matrix is ​​the association coupling matrix, which fully characterizes the interaction strength and collaborative dependencies between all access devices in the campus.

[0016] Furthermore, step S23 includes the following steps: Step S231: From the historical data interaction records, filter out the interaction timestamp sequence belonging to the same device pair, and calculate the time interval between adjacent timestamps to generate an irregular interaction time interval sequence; Step S232: Interpolate the irregular interaction time interval sequence to convert it into a standard time series signal sampled at equal time intervals. The value range of the standard time series signal represents the number of interactions that occur per unit time. Step S233: Apply Fast Fourier Transform to the standard time-series signal to transform it from the time domain to the frequency domain and obtain a spectrum. The horizontal axis of the spectrum is the frequency, and the vertical axis is the amplitude of the corresponding frequency component. Step S234: Locate the frequency component with the largest amplitude in the spectrum diagram, define the frequency component as the main frequency component, and use its corresponding amplitude as the main rhythm intensity index of data exchange between the devices. Step S235: Compare the main rhythm intensity index with the preset rhythm threshold. If the main rhythm intensity index exceeds the rhythm threshold, it is determined that the device has a strong cooperative dependency relationship, and the main rhythm intensity index is used as the synchronization coefficient.

[0017] In this embodiment, all interaction records belonging to the same device pair are filtered from the historical data interaction record table. This device pair is uniquely identified by a pair of logical address tags; for example, access control PK01-A03-017 and camera PK01-C05-022 constitute a device pair. The server executes an SQL query statement, with the WHERE condition specifying the source device tag and the target device tag as these two tags, or vice versa, and the ORDER BY condition sorting the interaction timestamps in ascending order. The query result returns a list of timestamps, the length of which may range from tens to thousands, depending on the activity level of the device pair. Subtracting adjacent timestamps yields a series of time interval values. These time intervals are non-uniform, with some intervals only a few seconds and others lasting several hours, forming an irregular time interval sequence. For frequency domain analysis, the server needs to convert this irregular sequence into a standard time-series signal with equal time interval sampling. The sampling frequency is set to once per hour, i.e., 3600 seconds as a sampling period. The server first determines the entire time span, the total number of seconds from the first timestamp to the last timestamp, and divides this by 3600 to obtain the number of sampling points. Then, create an array of length equal to the number of sampling points, initially all values ​​being zero. For each sampling interval, count the number of interactions falling within that interval and fill the corresponding position in the array. This results in a counting sequence in hours, for example, [3,0,1,5,2,...], indicating 3 interactions in the first hour, no interactions in the second hour, 1 interaction in the third hour, and so on. This sequence is the standard time-series signal, and its value range represents the number of interactions per unit time. The server applies a Fast Fourier Transform (FFT) to this time-series signal, calling the r2r transform function of the FFTW library, taking a real number array as input and outputting a complex spectrum array. The length of the spectrum array is equal to half the number of sampling points plus one, and each element contains a real part and an imaginary part. Calculate the amplitude of each frequency component, which is equal to the square root of the sum of the squares of the real and imaginary parts. The frequency resolution is equal to the sampling frequency divided by the number of sampling points. Here, the sampling frequency is 1 / 3600 Hz, so the frequency resolution is very small, capable of distinguishing rhythms with periods of several hours. The server iterates through the amplitude of all frequency components, finds the frequency index corresponding to the maximum value, and multiplies this index by the frequency resolution to obtain the actual frequency value of the dominant frequency component. For example, if the dominant frequency component is 0.0000463 Hz, which translates to a period of approximately 6 hours, it means that this device pair experiences an interaction peak approximately every 6 hours. The amplitude of the dominant frequency component is the primary rhythm intensity index, which reflects the rhythmicity of data exchange between the device pairs. If the amplitude is large, it indicates that the interaction time is highly concentrated in certain periods, exhibiting obvious periodicity; if the amplitude is small, it indicates that the interaction time is evenly distributed, with no obvious rhythm. The server compares the primary rhythm intensity index with a preset rhythm threshold, which is set to the average of the primary rhythm intensity indices of all device pairs multiplied by 1.5.If the primary rhythm strength index of the device pair exceeds the rhythm threshold, it is determined that the device pair has a strong cooperative dependency, and the primary rhythm strength index is output as the synchronization coefficient. Otherwise, it is determined to be a weak cooperative dependency, and the synchronization coefficient is set to zero. This synchronization coefficient is then used to update the attributes of the edges in the graph database, and also serves as the basis for subsequent anomaly detection and predictive maintenance. For example, a sudden drop in the synchronization coefficient between an access control system and a camera may indicate a camera malfunction or increased network latency, allowing maintenance personnel to intervene and troubleshoot in advance.

[0018] Furthermore, step S234 includes the following steps: Extract all frequency components and their corresponding amplitude lists from the spectrum graph, and sort the amplitude list in descending order to obtain an ordered sequence of amplitudes from largest to smallest; Take the first-ranked amplitude in the ordered sequence as the candidate maximum amplitude and record its corresponding candidate main frequency; Check whether the candidate main frequency falls within the frequency range corresponding to the typical interaction cycle of the equipment in the park. This frequency range is preset based on the daily operation and rest pattern of the park. If the candidate frequency is within the frequency range, then the candidate frequency is confirmed as an effective frequency component, and the maximum amplitude of the candidate frequency is used as the main rhythm intensity index. If the candidate main frequency is not within the frequency range, the next amplitude and its corresponding frequency in the ordered sequence are selected in sequence, and the frequency range check is repeated until a frequency that fits the frequency range is found, and its corresponding amplitude is used as the main rhythm intensity index.

[0019] In this embodiment, all frequency components and their corresponding amplitude lists are extracted from the generated spectrogram. The spectrogram is generated by Fast Fourier Transform, and the frequency components are stored in memory as an array. Each frequency component corresponds to a frequency value represented by a floating-point number and an amplitude value represented by another floating-point number. The server calls a sorting function from the standard library to sort the amplitude list in descending order. The sorting algorithm used is quicksort, with a time complexity of O(n log n), ensuring efficient processing even for large-scale spectrum data. After sorting, an ordered sequence of amplitudes from largest to smallest is obtained. For example, the first amplitude is 875.32, the second is 423.17, the third is 198.64, and so on, decreasing sequentially. The server takes the first-ranked amplitude in the ordered sequence as the candidate maximum amplitude and records the corresponding frequency value as the candidate dominant frequency. For example, the candidate maximum amplitude is 875.32, and the corresponding candidate dominant frequency is 0.0000463 Hz. The server then checks whether the candidate dominant frequency falls within the frequency range corresponding to the typical interaction cycle of the equipment in the park. This frequency range is pre-set based on the park's daily operating schedule. The park is typically active from 8:00 AM to 6:00 PM on weekdays and dormant at night. Therefore, typical interaction cycles are concentrated between half an hour and two hours, corresponding to a frequency range of 0.0001389 Hz to 0.0005556 Hz. Additionally, specific cycle patterns occur during lunch breaks and peak commuting hours, extending the frequency range to cover 0.0000231 Hz, corresponding to a 12-hour cycle. The server compares the candidate frequency of 0.0000463 Hz with the preset lower limit of the frequency range (0.0000231 Hz) and upper limit (0.0005556 Hz). Finding that 0.0000463 Hz falls within this range, the server confirms the candidate frequency as a valid frequency component and uses the candidate's maximum amplitude of 875.32 as the primary rhythm intensity indicator. If a candidate frequency is not within the frequency range—for example, a candidate frequency of 0.0000012 Hz corresponding to an approximately 230-hour cycle, which clearly exceeds the park's operational patterns—the server will select the next amplitude and its corresponding frequency from the ordered sequence and repeat the frequency range check. Assuming the second amplitude is 423.17, corresponding to a frequency of 0.0001200 Hz, this frequency falls within the range of 0.0000231 Hz to 0.0005556 Hz, thus confirming it as a valid frequency component, and using 423.17 as the primary rhythm strength indicator. If the second frequency still does not meet the criteria, the process continues to the third, fourth, and so on, until the first frequency falling within the frequency range is found. This step-by-step screening mechanism ensures that the extraction of the primary rhythm strength indicator always aligns with the actual operational patterns of the park, avoiding false frequency interference from random noise or occasional events that could affect the accuracy of the synchronization coefficient. For example, the periodic start-stop of an air conditioner in the park might generate a low-frequency component, but this component is unrelated to the interaction with access control and cameras, and can be excluded through frequency range filtering.The final output of the main rhythm intensity index is transmitted to calculate the synchronization coefficient between the device pairs, which in turn affects the construction of the correlation coupling matrix.

[0020] Furthermore, step S3 includes the following steps: Step S31: Obtain the correlation coupling matrix and concatenate it with a tensor containing historical traffic data to form a multidimensional input feature tensor that integrates device relationships and historical load; Step S32: Input the multidimensional input feature tensor into the spatiotemporal graph convolutional network based on the attention mechanism. The encoder part of the spatiotemporal graph convolutional network first captures the spatial dependency features between access devices through graph convolution operations and generates spatial embedding vectors. Step S33: Input the spatial embedding vector into the gated loop unit, and capture the long-term and short-term dependency patterns of device flow over time through the loop gating mechanism of the gated loop unit to generate a temporal hidden state vector. Step S34: Input the temporal hidden state vector into the fully connected decoding layer. The fully connected decoding layer maps the hidden state to the output space of multiple future time steps through linear transformation, generating a preliminary sequence of future traffic prediction values. Step S35: Apply a smoothing constraint to the preliminary future traffic forecast sequence to suppress abnormal spikes in the forecast results and generate a campus network traffic forecast distribution map within the future time window.

[0021] In this embodiment, a multidimensional input feature tensor is constructed based on the correlation coupling matrix and historical traffic data stored in a time-series database. The correlation coupling matrix is ​​an N x N two-dimensional matrix, where N is the total number of device nodes, and the matrix elements are floating-point numbers between 0 and 1, representing the correlation coupling weights between device pairs. The historical traffic data is stored in time-series format, with each record containing a timestamp, device logical address label, and number of traffic bytes, with a time granularity of one sampling point per minute. The server first reshapes the historical traffic data into a three-dimensional tensor, with the dimension being the time step multiplied by the number of devices multiplied by 1. The time step takes 1440 sampling points from the past 24 hours, and the number of devices is N. Then, the server copies and expands the correlation coupling matrix to the same time step dimension, i.e., each time step has an identical correlation coupling matrix, forming a tensor with a dimension of time step multiplied by N multiplied by N. Next, the server concatenates these two tensors along the feature dimension, resulting in a multidimensional input feature tensor with a dimension of time step multiplied by N multiplied by (N+1). Each time slice of this tensor contains an N x N correlation coupling matrix and an N x 1 historical traffic vector, fusing static relationship structure and dynamic traffic change information between devices. The server inputs this multidimensional input feature tensor into a spatiotemporal graph convolutional network based on an attention mechanism. The encoder part of this network first performs graph convolution operations with a kernel size of 3, aggregating information from 3rd-order neighbors within the neighborhood of each node. The graph convolutional layer uses the ReLU activation function, with an output dimension of 128, generating a spatial embedding vector. The dimension of the spatial embedding vector is time step multiplied by N multiplied by 128. Each node has a 128-dimensional spatial feature representation at each time step, capturing the topological dependencies between the node and its surrounding devices. For example, if an access control node is surrounded by multiple cameras and barriers, the graph convolution operation will weight and sum the features of neighboring nodes and incorporate them into the representation of the access control node, with the weights determined by the element values ​​of the correlation coupling matrix. The server then inputs the spatial embedding vector into a gated recurrent unit, with a hidden layer dimension of 256 and two layers. The gated recurrent unit iterates progressively along the time dimension. At each time step, it receives the spatial embedding vector of the current moment and the hidden state of the previous moment. It controls the forgetting and retention of information through reset and update gates. The reset gate determines how much historical information to ignore, and the update gate determines how much new information to write into the hidden state. After 1440 time steps of iteration, the gated recurrent unit outputs the temporal hidden state vector of the last time step, with a dimension of N multiplied by 256. This hidden state vector encapsulates the long-term trend and short-term fluctuation patterns of device traffic throughout the entire historical window; for example, the traffic surge pattern during weekday morning rush hours and the low-traffic characteristics on weekends are both encoded within it.The server inputs the temporal hidden state vector to the fully connected decoding layer, which consists of two linear transformation layers. The first layer maps the 256-dimensional vector to 128-dimensional vectors, and the second layer maps the 128-dimensional vectors to the number of future prediction time steps multiplied by 1. The number of future prediction time steps is set to 60, meaning the traffic situation is predicted for the next 60 minutes. The output of the fully connected decoding layer is reshaped into a matrix of dimension N multiplied by 60, with each row corresponding to the predicted traffic value for each device per minute over the next 60 minutes, forming a preliminary sequence of future traffic predictions. The server applies a smoothing constraint to this preliminary prediction sequence. The smoothing constraint is calculated by applying a second-order difference penalty to the prediction sequence for each device, i.e., calculating the sum of the squares of the differences between the prediction values ​​at adjacent time steps, multiplying it by a regularization coefficient of 0.1, and then adding this penalty to the original loss function. During the inference phase, the server directly performs post-processing on the preliminary prediction sequence, using a moving average filter with a window size of 5 to perform convolutional filtering on the prediction sequence for each device, eliminating abnormal spikes at individual time steps. For example, if the predicted value for a device suddenly jumps to 10 times the normal value at the 30th minute, it will be brought back to a reasonable range by the values ​​of the preceding and following time steps after a moving average. The final generated campus network traffic prediction distribution map within the future time window is an N-row, 60-column matrix, where each element represents the expected number of bytes of traffic for the corresponding device within the corresponding minute.

[0022] Furthermore, step S4 includes the following steps: Step S41: Analyze the predicted distribution map of the campus network traffic within the future time window, identify bottleneck areas and peak periods where the predicted traffic will exceed the preset threshold, and generate an early warning list containing hotspot locations and busy time periods. Step S42: Based on the warning list, temporarily increase the processing priority of authentication requests for access control devices located in hotspot locations, and reduce the frequency of non-critical status reporting, thereby generating a first access policy for the access control system. Step S43: Based on the warning list, enable the fast lifting mode for vehicle gates during busy periods and suspend non-emergency license plate secondary recognition processes to generate a second access strategy for the vehicle access system. Step S44: Based on the warning list, temporarily reduce the encoding bitrate of the video stream of security cameras covering hotspot locations by one level, and prioritize ensuring the clarity of images in key areas, generating a third access strategy for the security monitoring system. Step S45: Integrate the first access policy, the second access policy and the third access policy into a composite instruction set that includes device identifier, policy effective time and specific parameter adjustment items. This composite instruction set is the access scheduling policy.

[0023] In this embodiment, the network traffic prediction distribution map of the campus within a future time window is analyzed. This distribution map is an N-row, 60-column matrix, where N is the total number of devices and 60 is the number of future minutes. The server iterates through each column of the matrix, summing the predicted traffic values ​​of all devices for each minute to obtain the total predicted traffic value for the entire campus for that minute. The server compares the total predicted traffic value for the entire campus with a preset total bandwidth threshold for the entire campus, which is set to 70% of the uplink capacity of the core switch. When the predicted total traffic value for the entire campus for a certain minute exceeds this threshold, that minute is marked as a busy period. At the same time, the server individually judges each device, marking the moment when the predicted traffic value of a device exceeds 80% of the device's rated bandwidth as a hotspot moment, and recording the location of the device as a hotspot location. All busy periods and hotspot locations are summarized to generate an early warning list containing hotspot locations and busy periods. The early warning list is stored in tabular form, with each row containing the area number of the hotspot location, the start and end times of the busy period, the list of devices involved, and the percentage of traffic expected to exceed the limit. For example, one record in the warning list indicates that between 8:15 AM and 8:45 AM, the traffic from access control devices and cameras in the lobby area of ​​Building A will exceed 120% of the rated bandwidth. The server generates a first access policy for the access control system based on the warning list. For access control devices located in hotspots, the server raises the processing priority of their authentication requests from the default medium to the highest. Specifically, this involves modifying the weight factor of the access control device in the message queue consumer from 1 to 3, ensuring that requests from this access control are consumed first. Simultaneously, the server reduces the reporting frequency of non-critical statuses for this access control device, including battery level, temperature readings, and firmware version, from once every 5 minutes to once every 30 minutes, reducing unnecessary network overhead. The server packages these adjustment parameters into a policy record, including the device identifier, the policy effective time range, and the specific parameter change values. The server then generates a second access policy for the vehicle access system based on the warning list. For vehicle access gates during peak hours, the server activates a fast-opening mode. This mode eliminates the secondary license plate recognition process upon vehicle entry, performing only a single initial recognition before opening the gate. The secondary license plate recognition is then completed when the vehicle leaves. Simultaneously, the server reduces the resolution of the gate's captured images from 1920x1080 to 1280x720, minimizing the amount of data uploaded per instance. These adjustments are also recorded as policy logs, including the gate device identifier, the start and end times of peak hours, and the parameter changes. Based on the alert list, the server generates a third-party access policy for the security monitoring system.For security cameras covering hotspot locations, the server temporarily reduces the bitrate of their video stream by one level, for example, from 4 Mbps in the main stream to 2 Mbps in the sub-stream, while maintaining the encoding quality of critical areas. The critical area is defined as the central 60% of the image, where higher quantization parameters are used to ensure clarity, while lower quantization parameters are used in edge areas to save bandwidth. The server also suspends the motion detection alarm upload function for this camera to avoid a large number of alarm screenshots consuming network resources. These adjusted parameters are also recorded as policy records. The server integrates the first, second, and third access policies into a composite instruction set, which is a JSON array. Each element contains a device identifier field, a policy effective start time field, a policy effective end time field, and a parameter adjustment dictionary field. The parameter adjustment dictionary field lists all device configuration items that need to be modified and their target values. The server sends this composite instruction set to the campus IoT management platform. After parsing the instruction set, the platform sends configuration update commands to the target devices one by one via the MQTT protocol. Upon receiving the command, the device immediately executes the parameter adjustments, thereby achieving dynamic scheduling and control of access traffic.

[0024] Furthermore, step S42 includes the following steps: Step S421: Extract the unique identifier of all access control devices from the warning list, and query the device capability description table to obtain the maximum number of concurrent processing threads supported by each access control device and the average response latency baseline; Step S422: Based on the maximum number of concurrent processing threads and the baseline of average response latency, calculate the theoretical remaining processing capacity of each access control device under the current predicted traffic, and generate device load margin parameters; Step S423: Compare the equipment load margin parameter with the preset tension threshold, and filter out access control devices whose equipment load margin parameter is lower than the tension threshold to form a high-risk access control device list; Step S424: For each access control device in the list of high-risk access control devices, generate a temporary policy instruction that requires the access device to switch its internal task queue scheduling algorithm from fair round-robin mode to priority preemption mode; Step S425: Bind the temporary policy instruction to the rollback timer. The rollback timer's duration is equal to the length of the busy period. Once the timer ends, the device's original scheduling algorithm is automatically restored, thereby generating the first access policy.

[0025] In this embodiment, unique identifiers for all access control devices are extracted from the warning list. The warning list records hotspot locations and peak hours. The server iterates through each row of the warning list, filters records where the device type field is "door," and collects the device identifier field from these records to form a list of access control device identifiers. This list contains dozens to hundreds of device IDs, such as PK01-A03-017, PK01-B02-011, etc. The server then queries the device capability description table, which is stored in a MySQL database. The table structure includes the device identifier, the maximum number of concurrent processing threads, and the average response latency baseline. The maximum number of concurrent processing threads is determined by the access control controller's hardware specifications. For example, a certain model of access control controller is equipped with a quad-core ARM processor, and the firmware layer supports a maximum of 16 concurrent processing threads. This value is manually entered by the administrator when the device is registered in the database. The average response latency baseline is the average value accumulated during normal device operation through periodic ping tests and transaction time statistics, for example, 200 milliseconds. The server executes an SQL query, with the WHERE clause specifying that the device identifier must be within the list of access control device identifiers. The SELECT statement retrieves two fields: the maximum number of concurrent processing threads and the average response latency baseline. After the query results are returned, the server calculates the theoretical remaining processing capacity for each access control device. The formula for calculating the theoretical remaining processing capacity is the maximum number of concurrent processing threads minus the current predicted traffic divided by the average response latency baseline. The current predicted traffic is taken from the predicted value of the corresponding device during the busy period in the future traffic prediction distribution map generated in step S22, in the unit of requests per second. For example, if an access control device has a maximum number of concurrent processing threads of 16, an average response latency baseline of 0.2 seconds, and a predicted traffic of 50 requests per second, then the theoretical remaining processing capacity is 16 minus 50 multiplied by 0.2 equals 16 minus 10 equals 6. This means that the device has 6 idle threads. The calculation result is used as a device load margin parameter, which is a floating-point number. The server compares the device load margin parameter with a preset stress threshold, which is set to 2. When a device's load margin parameter is less than 2, it indicates that the device has fewer than 2 idle threads, facing an overload risk. The server filters out all access control devices that meet the condition of a load margin parameter less than 2, forming a high-risk access control device list. For example, the list includes device PK01-A03-017 with a load margin parameter of 1.2, and device PK01-B02-011 with a load margin parameter of 0.8. For each access control device in the high-risk access control device list, the server generates a temporary policy instruction. The content of the temporary policy instruction is a structured text containing a device identifier field, an instruction type field, and a parameter field.The instruction type field is fixed as "SCHEDULER_SWITCH", and the parameter field contains a target scheduling mode identifier, "PRIORITY_PREEMPTIVE", representing priority preemption mode. This temporary policy instruction requires the access control device to switch its internal task queue scheduling algorithm from the current fair round-robin mode to priority preemption mode. In fair round-robin mode, all authentication requests are queued in the order of arrival and assigned to idle threads for processing, with each request receiving an equal CPU time slice. In priority preemption mode, the task queue is no longer ordered according to the first-come, first-served principle, but is rearranged according to the priority tag carried by each request. Higher-priority requests can jump to the front of the queue and obtain thread resources first. The server binds the temporary policy instruction to a backoff timer, which is a scheduled task object whose timer duration is equal to the length of the busy time period corresponding to the access control device in the warning list. For example, if the busy time period is from 8:15 AM to 8:45 AM, lasting 30 minutes, the backoff timer is set to 30 minutes. The server creates a key-value pair in Redis, where the key is the device identifier plus the suffix "_rollback_timer", and the value is the current timestamp plus the future timestamp corresponding to 30 minutes. Simultaneously, the server starts a background thread that checks all rollback timer key-value pairs in Redis every second. When the current timestamp exceeds the future timestamp stored in the key-value pair, the thread automatically sends a recovery command to the device. The command type field is "SCHEDULER_RESTORE", and the parameter field is empty, requesting the device to revert to fair round-robin mode. The resulting first access policy includes the complete configuration of the temporary policy command and the rollback timer.

[0026] Furthermore, step S424 includes the following steps: Obtain the historical authentication logs of a specific access control device from the list of high-risk access control devices, and extract the average authentication time data corresponding to different personnel identity tags from the historical authentication logs; Based on average verification time data, a mapping table between personnel identity and verification priority is established, and personnel identity tags with longer verification times are assigned higher processing priority. The mapping table and temporary policy instructions are encapsulated to generate a configuration data package containing priority rules. This configuration data package specifies how the task queue should be sorted according to personnel identity in priority preemption mode. The configuration data package is sent to the firmware layer of the access control device and loaded and executed by the task scheduler of the firmware layer. This enables priority processing of personnel access requests with more complex verification processes during peak hours, thereby switching the internal task queue scheduling algorithm from fair round-robin mode to priority preemption mode.

[0027] In this embodiment, a specific access control device, such as device PK01-A03-017, is selected from the list of high-risk access control devices. The server queries the historical authentication logs of this access control device. These logs are stored in an Elasticsearch index, partitioned by day. The log documents contain a timestamp field, a personnel identification tag field, and a verification time field. The personnel identification tag is an employee ID, visitor appointment number, or temporary pass number. The verification time is the time elapsed from the card reader sensing the card to the access control controller returning the door opening result, measured in milliseconds. The server constructs an Elasticsearch query request, limiting the query scope to the past 90 days, matching the device identifier field to PK01-A03-017, and performing aggregation operations grouping by personnel identification tag, calculating the average verification time for each group. The query results return a bucket set, with each bucket containing a personnel identification tag and its corresponding average verification time value. For example, the personnel identity label in bucket 1 is "EMP00321", with an average verification time of 150 milliseconds; the personnel identity label in bucket 2 is "VISITOR_20260820_005", with an average verification time of 850 milliseconds; and the personnel identity label in bucket 3 is "TEMP_GUEST_007", with an average verification time of 620 milliseconds. Based on these average verification time data, the server establishes a mapping table between personnel identity and verification priority. The mapping table is structured as a hash dictionary, with the key being the personnel identity label string and the value being a priority-encoded integer. The detailed process of establishing the mapping table is described in step S33; here, the overall encapsulation process is described first. After the mapping table is generated, the server encapsulates the mapping table with the temporary policy instruction generated in step S31 to generate a configuration data packet containing priority rules. The configuration data packet uses the MessagePack binary serialization format and contains three fields: instruction type field, backoff timer field, and priority mapping field. The instruction type field reuses "SCHEDULER_SWITCH" from step S31, the backoff timer field stores the timestamp of the end of the busy period, and the priority mapping field stores all key-value pairs in the mapping table. The server sends this configuration data packet to the firmware layer of the access control device via the MQTT protocol to a message channel with the device identifier as the topic. The firmware program running on the access control device subscribes to this topic and parses the configuration data packet upon receiving the message. The task scheduler in the firmware layer, which was originally running a fair round-robin scheduling loop, stops its current scheduling loop upon receiving the configuration data packet, reads the rules from the priority mapping table, and initializes a priority queue data structure. The priority queue is implemented using a binary heap, where the top element is always the task with the smallest priority code value.When a new authentication request arrives, the task scheduler looks up the priority mapping table based on the personnel identification tag carried in the request, obtains the corresponding priority code, and then packages the request into a task node and inserts it into the priority queue. The task node contains a request data pointer, a priority code, and an insertion timestamp. The scheduler retrieves a task node from the head of the priority queue each time and assigns it to an idle thread for execution, thus prioritizing more complex personnel access requests during peak hours. For example, visitor authentication involves facial recognition and appointment information verification, taking an average of 850 milliseconds, and is assigned a high-priority code of 1, while employee authentication only requires card swiping and verification, taking an average of 150 milliseconds, and is assigned a normal-priority code of 3. In high-concurrency scenarios, visitor requests are processed before employee requests, reducing visitor waiting time at the entrance.

[0028] Furthermore, establishing a mapping table between personnel identity and verification priority based on average verification time data includes the following steps: Statistical analysis was performed on the average verification time data to calculate the mean and standard deviation of the average verification time for all identity tags; a high time threshold was defined based on the mean and standard deviation, and identity tags whose average verification time data exceeded the high time threshold were classified as high-priority groups; For other identity tags that are not classified as high-priority groups, the deviation ratio between their average verification time data and the mean is further calculated. Based on the magnitude of this deviation ratio, the remaining identity tags are divided into two levels: medium priority and ordinary priority. In descending order of high priority, medium priority, and ordinary priority, a numeric identifier is assigned to each level as its priority code, and this priority code is associated with and stored with the corresponding identity tag to generate a mapping table.

[0029] In this embodiment, statistical analysis is performed on the acquired average verification time data. The average verification time data is a list containing several records, each containing a person's identity tag and its corresponding average verification time value. The server first calculates the arithmetic mean of all average verification time values, sums all the values, and divides by the total number of records to obtain the mean. For example, the mean is calculated to be 400 milliseconds. The server then calculates the standard deviation, subtracting the mean from each average verification time value, squaring the result, summing all the squares, dividing by the total number of records, and taking the square root to obtain the standard deviation. For example, the standard deviation is calculated to be 180 milliseconds. The server defines a high-time threshold based on the mean and standard deviation, set at the mean plus twice the standard deviation, i.e., 400 plus 360 equals 760 milliseconds. The server iterates through all the average verification time data, classifying identity tags with average verification times exceeding 760 milliseconds into a high-priority group. For example, the visitor identity tag "VISITOR_20260820_005", with an average verification time of 850 milliseconds, is classified into the high-priority group, while the temporary visitor identity tag "TEMP_GUEST_007", with an average verification time of 620 milliseconds, is not classified into the high-priority group. For other identity tags not classified into the high-priority group, the server further calculates the deviation ratio of their average verification time data from the mean. The deviation ratio is calculated by subtracting the mean from the average verification time and then dividing by the mean, with the result being a positive or negative number. For example, the deviation ratio for an average verification time of 620 milliseconds is 620 - 400 divided by 400, which equals 0.55; the deviation ratio for an average verification time of 150 milliseconds is 150 - 400 divided by 400, which equals -0.625. Based on the absolute value of the deviation ratio, the server divides the remaining identity tags into two levels: medium priority and normal priority. The priority classification rule is as follows: identity tags with an absolute deviation ratio greater than 0.3 are classified as medium priority, while those with an absolute deviation ratio less than or equal to 0.3 are classified as normal priority. For example, the identity tag "TEMP_GUEST_007" has a deviation ratio of 0.55, which is greater than 0.3, and is classified as medium priority; the identity tag "EMP00321" also has a deviation ratio of -0.625, which is greater than 0.3, and is also classified as medium priority. Assuming there is another identity tag with an average verification time of 380 milliseconds, a deviation ratio of -0.05, and an absolute value of 0.05 less than 0.3, it is classified as normal priority. The server assigns a numeric identifier as its priority code for each level in descending order of high priority, medium priority, and normal priority. High priority is assigned numeric identifier 1, medium priority is assigned numeric identifier 2, and normal priority is assigned numeric identifier 3. The smaller the number, the higher the priority and the earlier it appears in the priority queue. The server stores each identity tag and its corresponding priority code in association, forming a hash table where the key is the personnel identity tag string and the value is the priority code integer.For example, the hash table contains entries {“VISITOR_20260820_005”: 1, “TEMP_GUEST_007”: 2, “EMP00321”: 2, “EMP00456”: 3}. This hash table is the final mapping table. The server encapsulates this mapping table and temporary policy instructions into a configuration data packet and sends it to the access control device firmware layer. After the firmware layer task scheduler loads this mapping table, whenever it receives an authentication request, it parses the person's identity tag from the request and looks up the corresponding priority code in the mapping table. If the lookup matches, the priority code is used to insert the device into the priority queue; if the lookup does not match, the default priority code 3, i.e., normal priority, is assigned. In this way, during peak hours, visitors with complex verification processes and temporary visitors with longer processing times can receive higher processing priority, thereby shortening the overall queuing time and alleviating congestion at the access control device.

[0030] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0031] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. A method for managing access control, vehicle, and security equipment in smart parks, characterized in that, Includes the following steps: Step S1: Collect real-time operating status data streams of each access device in the park, and perform heterogeneous protocol parsing and unified identifier mapping on the real-time operating status data streams to generate standardized device metadata containing device type, physical address and communication protocol; Step S2: Construct a dynamic topology graph of access devices based on standardized device metadata, and generate an association coupling matrix representing the collaborative dependency relationship between devices according to the connection strength and data exchange frequency of each node in the dynamic topology graph; Step S3: Input the correlation coupling matrix into the pre-trained traffic prediction model, and learn the spatiotemporal dependency pattern between access devices through the graph convolutional network layer inside the traffic prediction model to generate a campus network traffic prediction distribution map within the future time window. Step S4: Based on the predicted distribution map of the park's network traffic, dynamically adjust the access permissions and data sampling frequency of the park's access control, vehicle gates, and security cameras to generate an access scheduling strategy; Step S5: Based on the access scheduling policy, configuration instructions are sent to each device through the edge gateway, and the device execution feedback is transmitted back in real time, thereby realizing collaborative access management of multiple types of devices in the park.

2. The access control, vehicle, and security equipment access management method for smart parks according to claim 1, characterized in that, Step S1 includes the following steps: Step S11: By deploying IoT gateways in various areas of the park, listen to and capture raw data packets from different access control systems, vehicle gates, and security cameras in real time; Step S12: Extract the protocol header field and payload data from the original data packets, and perform pattern matching through the protocol feature library to identify the private or standard communication protocol type to which each original data packet belongs; Step S13: Based on the identified private or standard communication protocol type, call the corresponding protocol parsing plugin to decode the payload data, and reconstruct the decoded data fields according to a unified metadata template to generate an intermediate data unit containing a unique device identifier, function status code and timestamp. Step S14: Cross-compare the device unique identifier in the intermediate data unit with the pre-registered device asset database. If the comparison is successful, assign a globally unique logical address label to the intermediate data unit and mark its device category and security level. Step S15: Serialize and encapsulate the intermediate data unit carrying the logical address tag to generate standardized device metadata.

3. The access control, vehicle, and security equipment access management method for smart parks according to claim 1, characterized in that, Step S2 includes the following steps: Step S21: Extract the physical installation location information and logical address tags of each access device from the standardized device metadata, and use the physical installation location information and logical address tags as node attributes to create corresponding device node instances in the graph database; Step S22: Traverse all device node instances, analyze whether there is a data interaction record between any two nodes in the historical time period. If there is, create an undirected edge between the two nodes and calculate the initial connection strength of the edge based on the number of interactions and the size of the data packet. Step S23: For node pairs with undirected edges, further analyze the periodicity of their data interaction to extract the main frequency component of the interaction frequency, and use the amplitude of the main frequency component as a synchronization coefficient to measure the degree of collaborative dependence between access devices. Step S24: Perform coupling analysis on the initial connection strength and synchronization coefficient to generate associated coupling weights, and use the associated coupling weights as the coupling edge weights of the corresponding undirected edges to update the graph database, thereby forming a dynamic topological relationship graph; Step S25: Extract the coupling edge weights of all edges in the dynamic topology graph and arrange them into a two-dimensional matrix. The row and column indices of this two-dimensional matrix correspond to the device nodes that initiate and receive the interaction, respectively. The matrix elements are the associated coupling weights, thereby generating the associated coupling matrix.

4. The access control, vehicle, and security equipment access management method for smart parks according to claim 3, characterized in that, Step S23 includes the following steps: Step S231: From the historical data interaction records, filter out the interaction timestamp sequence belonging to the same device pair, and calculate the time interval between adjacent timestamps to generate an irregular interaction time interval sequence; Step S232: Interpolate the irregular interaction time interval sequence to convert it into a standard time series signal sampled at equal time intervals. The value range of the standard time series signal represents the number of interactions that occur per unit time. Step S233: Apply Fast Fourier Transform to the standard time-series signal to transform it from the time domain to the frequency domain and obtain a spectrum. The horizontal axis of the spectrum is the frequency, and the vertical axis is the amplitude of the corresponding frequency component. Step S234: Locate the frequency component with the largest amplitude in the spectrum diagram, define the frequency component as the main frequency component, and use its corresponding amplitude as the main rhythm intensity index of data exchange between the devices. Step S235: Compare the main rhythm intensity index with the preset rhythm threshold. If the main rhythm intensity index exceeds the rhythm threshold, it is determined that the device has a strong cooperative dependency relationship, and the main rhythm intensity index is used as the synchronization coefficient.

5. The access control, vehicle, and security equipment access management method for smart parks according to claim 4, characterized in that, Step S234 includes the following steps: Extract all frequency components and their corresponding amplitude lists from the spectrum graph, and sort the amplitude list in descending order to obtain an ordered sequence of amplitudes from largest to smallest; Take the first-ranked amplitude in the ordered sequence as the candidate maximum amplitude and record its corresponding candidate main frequency; Check whether the candidate main frequency falls within the frequency range corresponding to the typical interaction cycle of the equipment in the park. This frequency range is preset based on the daily operation and rest pattern of the park. If the candidate frequency is within the frequency range, then the candidate frequency is confirmed as an effective frequency component, and the maximum amplitude of the candidate frequency is used as the main rhythm intensity index. If the candidate main frequency is not within the frequency range, the next amplitude and its corresponding frequency in the ordered sequence are selected in sequence, and the frequency range check is repeated until a frequency that fits the frequency range is found, and its corresponding amplitude is used as the main rhythm intensity index.

6. The access control, vehicle, and security equipment management method for smart parks according to claim 1, characterized in that, Step S3 includes the following steps: Step S31: Obtain the correlation coupling matrix and concatenate it with a tensor containing historical traffic data to form a multidimensional input feature tensor that integrates device relationships and historical load; Step S32: Input the multidimensional input feature tensor into the spatiotemporal graph convolutional network based on the attention mechanism. The encoder part of the spatiotemporal graph convolutional network first captures the spatial dependency features between access devices through graph convolution operations and generates spatial embedding vectors. Step S33: Input the spatial embedding vector into the gated loop unit, and capture the long-term and short-term dependency patterns of device flow over time through the loop gating mechanism of the gated loop unit to generate a temporal hidden state vector. Step S34: Input the temporal hidden state vector into the fully connected decoding layer. The fully connected decoding layer maps the hidden state to the output space of multiple future time steps through linear transformation, generating a preliminary sequence of future traffic prediction values. Step S35: Apply a smoothing constraint to the preliminary future traffic forecast sequence to suppress abnormal spikes in the forecast results and generate a campus network traffic forecast distribution map within the future time window.

7. The access control, vehicle, and security equipment access management method for smart parks according to claim 1, characterized in that, Step S4 includes the following steps: Step S41: Analyze the predicted distribution map of the campus network traffic within the future time window, identify bottleneck areas and peak periods where the predicted traffic will exceed the preset threshold, and generate an early warning list containing hotspot locations and busy time periods. Step S42: Based on the warning list, temporarily increase the processing priority of authentication requests for access control devices located in hotspot locations, and reduce the frequency of non-critical status reporting, thereby generating a first access policy for the access control system. Step S43: Based on the warning list, enable the fast lifting mode for vehicle gates during busy periods and suspend non-emergency license plate secondary recognition processes to generate a second access strategy for the vehicle access system. Step S44: Based on the warning list, temporarily reduce the encoding bitrate of the video stream of security cameras covering hotspot locations by one level, and prioritize ensuring the clarity of images in key areas, generating a third access strategy for the security monitoring system. Step S45: Integrate the first access policy, the second access policy and the third access policy into a composite instruction set that includes device identifier, policy effective time and specific parameter adjustment items. This composite instruction set is the access scheduling policy.

8. The access control, vehicle and security equipment access management method for smart parks according to claim 7, characterized in that, Step S42 includes the following steps: Step S421: Extract the unique identifier of all access control devices from the warning list, and query the device capability description table to obtain the maximum number of concurrent processing threads supported by each access control device and the average response latency baseline; Step S422: Based on the maximum number of concurrent processing threads and the baseline of average response latency, calculate the theoretical remaining processing capacity of each access control device under the current predicted traffic, and generate device load margin parameters; Step S423: Compare the equipment load margin parameter with the preset tension threshold, and filter out access control devices whose equipment load margin parameter is lower than the tension threshold to form a high-risk access control device list; Step S424: For each access control device in the list of high-risk access control devices, generate a temporary policy instruction that requires the access device to switch its internal task queue scheduling algorithm from fair round-robin mode to priority preemption mode; Step S425: Bind the temporary policy instruction to the rollback timer. The rollback timer's duration is equal to the length of the busy period. Once the timer ends, the device's original scheduling algorithm is automatically restored, thereby generating the first access policy.

9. The access control, vehicle and security equipment access management method for smart parks according to claim 8, characterized in that, Step S424 includes the following steps: Obtain the historical authentication logs of a specific access control device from the list of high-risk access control devices, and extract the average authentication time data corresponding to different personnel identity tags from the historical authentication logs; Based on average verification time data, a mapping table between personnel identity and verification priority is established, and personnel identity tags with longer verification times are assigned higher processing priority. The mapping table and temporary policy instructions are encapsulated to generate a configuration data package containing priority rules. This configuration data package specifies how the task queue should be sorted according to personnel identity in priority preemption mode. The configuration data package is sent to the firmware layer of the access control device and loaded and executed by the task scheduler of the firmware layer. This enables priority processing of personnel access requests with more complex verification processes during peak hours, thereby switching the internal task queue scheduling algorithm from fair round-robin mode to priority preemption mode.

10. The access control, vehicle and security equipment access management method for smart parks according to claim 9, characterized in that, The process of establishing a mapping table between personnel identity and verification priority based on average verification time data includes the following steps: Statistical analysis was performed on the average verification time data to calculate the mean and standard deviation of the average verification time for all identity tags; a high time threshold was defined based on the mean and standard deviation, and identity tags whose average verification time data exceeded the high time threshold were classified as high-priority groups; For other identity tags that are not classified as high-priority groups, the deviation ratio between their average verification time data and the mean is further calculated. Based on the magnitude of this deviation ratio, the remaining identity tags are divided into two levels: medium priority and ordinary priority. In descending order of high priority, medium priority, and ordinary priority, a numeric identifier is assigned to each level as its priority code, and this priority code is associated with and stored with the corresponding identity tag to generate a mapping table.

Images