Real-time data acquisition and processing method for digital twin park fused with edge computing

Abstract

The application discloses a digital twin park real-time data acquisition and processing method based on fusion edge computing, belongs to the technical field of data processing, and comprises the following steps: step 1, deploying a P4 programmable switching device between a data acquisition terminal and an edge computing node of a digital twin park, and forwarding a de-duplicated message to a corresponding edge computing node through a multi-stage series P4 flow table; step 2, deploying a hybrid expert processing architecture comprising a route distributor and a plurality of expert processing units in each edge computing node; and step 3, constructing a Petri net synchronization coordination model. The application effectively solves the problems in the prior art that a network forwarding layer cannot perform content-level de-duplication classification, an edge processing layer lacks a multi-expert routing mechanism that is deployed on demand, abnormal detection relies on fixed thresholds and cannot adapt to fluctuations in operating states, and when a plurality of edge nodes concurrently push data to a digital twin model, there is a lack of global timing consistency coordination.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method for real-time data acquisition and processing of digital twin campuses that integrates edge computing. Background Technology

[0002] Digital twin technology has gained widespread attention and rapid development in the field of smart parks in recent years. A digital twin park constructs a 3D model in virtual space that corresponds one-to-one with the physical park, and continuously injects real-time data collected by various sensors, instruments, and terminals in the physical park into the virtual model. This allows park managers to intuitively observe the park's operational status, identify abnormal events, and assist in decision-making on a digital platform. With the continuous expansion of park scale and the increasing variety of data collection terminals, the number of data collection terminals operating simultaneously in a single park has grown from dozens in the early days to hundreds or even thousands, covering various types such as temperature and humidity sensors, power monitoring instruments, vibration sensors, access control controllers, video encoders, and personnel positioning tags. These terminals continuously generate massive amounts of data packets with their own different sampling frequencies and communication protocols. How to efficiently collect, transmit, and process this multi-source heterogeneous data and synchronize the processing results to the digital twin model in a timely manner has become a key technical bottleneck restricting the real-time performance and availability of digital twin parks.

[0003] In the data acquisition and transmission stage, existing technologies generally use traditional network switching equipment to aggregate data packets from campus terminals and send them to the cloud or data center for centralized processing. This centralized architecture can operate normally in scenarios with a small number of terminals and a small amount of data. However, in scenarios with a large number of terminals and concurrent reporting, the aggregation layer switching equipment only undertakes simple packet forwarding functions and cannot perform intelligent classification, filtering, and scheduling of data streams. This results in a large number of redundant packets and duplicate data being pushed to upper-layer processing nodes without modification, causing a serious waste of network bandwidth and computing resources. Some improvement solutions attempt to configure access control lists or traffic policies on the aggregation layer switching equipment for coarse-grained traffic filtering. However, the data plane functions of traditional switching equipment are fixed and defined by chip firmware, which cannot flexibly customize packet parsing logic and matching actions according to the needs of campus business. It is difficult to achieve fine-grained classification based on packet payload content and duplicate determination based on data content characteristics. Although the emergence of software-defined networking technology has enabled the network control plane to be programmable, the packet processing of the data plane still relies on the fixed-function pipeline of the switching chip, and cannot perform custom hash operations and probabilistic data structure queries under line-speed conditions. Summary of the Invention

[0004] The purpose of this invention is to provide a method for real-time data acquisition and processing of digital twin parks that integrates edge computing. This method effectively solves the problems in the prior art, such as the inability of the network forwarding layer to perform content-level deduplication and classification, the lack of a multi-expert routing mechanism for on-demand allocation in the edge processing layer, the inability of anomaly detection to adapt to fluctuations in operating status due to reliance on fixed thresholds, and the lack of global temporal consistency coordination when multiple edge nodes concurrently push data to the digital twin model.

[0005] To address the aforementioned technical problems, this invention provides a method for real-time data acquisition and processing in a digital twin campus that integrates edge computing. This method includes the following steps: Step 1: Deploy P4 programmable switching equipment between the data acquisition terminal and the edge computing node in the digital twin park. Configure multi-level serial P4 flow table in the P4 programmable switching equipment to perform source identifier matching, message type classification and forwarding scheduling on the data flow in sequence. In the pipeline stage of the multi-level serial P4 flow table, call the hardware hash engine to generate data fingerprint signature for the message. Send the data fingerprint signature to the dual-window rotating Bloom filter to perform deduplication judgment. Forward the message that has passed the deduplication to the corresponding edge computing node through the multi-level serial P4 flow table. Step 2: Deploy a hybrid expert processing architecture, including a route distributor and multiple expert processing units, in each edge computing node. The route distributor determines the main active expert processing unit based on the type tag value in the packet metadata and determines whether to activate the auxiliary expert processing unit simultaneously based on the packet's payload characteristics. The feature vector output by the expert processing unit is sent to the constant false alarm rate adaptive detection layer. The constant false alarm rate adaptive detection layer maintains independent detection sequences according to data types and determines the adaptive detection threshold through a sliding detection window. Based on the detection results, it generates an abnormal event report or a normal update report. Step 3: Construct a Petri net synchronization coordination model, encapsulate abnormal event reports and normal update reports into tokens of different priorities and inject them into the edge output repository. The synchronization transition executes immediate or batch transmission to the twin receiving repository according to the token priority, driving the corresponding digital twin sub-model to perform state update. After the global coordination transition collects the completion tokens of all twin receiving repositories, it triggers the consistency merging of the global view of the park-level digital twin.

[0006] Furthermore, in step 1, the multi-level concatenated P4 flow table includes a first-level source identifier matching flow table, a second-level message type classification flow table, and a third-level forwarding scheduling flow table, which are sequentially concatenated. The first-level source identifier matching flow table uses the device address of the data acquisition terminal as the matching key. After a match is found, the device area code to which the data acquisition terminal belongs is written into the message metadata. The second-level message type classification flow table uses the combination of the Ethernet type field and the custom protocol identifier field of the message as the matching key to divide the data flow into three types: environmental awareness, device operation, and personnel activity. The corresponding type tag value is written into the message metadata, where environmental awareness corresponds to type tag value 1, device operation corresponds to type tag value 2, and personnel activity corresponds to type tag value 3. The third-level forwarding scheduling flow table uses the combination of type tag value and device area code as the matching key to forward the deduplicated message to the designated ingress port of the corresponding edge computing node.

[0007] Furthermore, in step 1, during the P4 hardware pipeline stage between the Level 2 message type classification flow table and the Level 3 forwarding scheduling flow table, the hardware hash engine built into the P4 programmable switch is invoked. The fixed-length protocol header field sequence extracted by parsing the Level 2 message type classification flow table is combined with the device area code and type tag value as input to perform a hardware-level CRC32 hash operation, generate a 32-bit data fingerprint signature, and write the 32-bit data fingerprint signature into the signature field of the message metadata.

[0008] Furthermore, in step 1, the dual-window rotating Bloom filter includes a currently active window and a backup window. After each preset rotation cycle, the backup window is cleared and a new currently active window is switched to, while the original currently active window is downgraded to a backup window. During existence determination, both the currently active window and the backup window are queried. Only when the 32-bit data fingerprint signature exists in both windows is it determined to be a duplicate message and directly discarded in the P4 hardware pipeline stage. Otherwise, the 32-bit data fingerprint signature is inserted into the currently active window and the message is sent to the level 3 forwarding scheduling flow table.

[0009] Furthermore, in step 2, the hybrid expert processing architecture includes one route distributor and three expert processing units. The three expert processing units preload feature extraction models for environmental perception, equipment operation, and personnel activity data, respectively.

[0010] Furthermore, in step 2, the route distributor directly determines the main activation expert processing unit based on the type tag value. Simultaneously, it extracts the number of payload fields and the total length of payload bytes after parsing the packet. The number of payload fields is compared to a preset field count threshold, and the total length of payload bytes is compared to a preset byte length threshold. When both the number of payload fields and the total length of payload bytes exceed their respective thresholds, the packet is classified as high-complexity. The main activation expert processing unit and one auxiliary expert processing unit adjacent to the main activation expert processing unit's type tag value are activated. The main activation expert processing unit and the auxiliary expert processing unit independently extract feature vectors and then concatenate them end-to-end in dimensional order to form a joint feature vector. When neither exceeds its corresponding threshold, the packet is classified as standard-complexity, and only the main activation expert processing unit performs feature extraction.

[0011] Furthermore, in step 2, the constant false alarm rate adaptive detection layer maintains independent detection sequences according to the data types corresponding to the type label values, and arranges the feature vectors of the same type into the corresponding type detection sequences in order of arrival. A sliding detection window is set on each detection sequence. The sliding detection window is centered on the target feature vector to be detected, and a protection unit and a reference unit are set on both sides of the target feature vector. The protection unit is adjacent to the target feature vector, and the reference unit is located outside the protection unit.

[0012] Furthermore, two protection units and eight reference units are set on each side of the target feature vector; the constant false alarm rate adaptive detection layer reads the magnitude value of each feature vector in all 16 reference units, performs an arithmetic mean operation on the 16 magnitude values ​​to obtain the reference mean, and multiplies the reference mean by the preset constant false alarm rate sensitivity coefficient to obtain the adaptive detection threshold; the magnitude value of the target feature vector is compared with the adaptive detection threshold, if it exceeds the adaptive detection threshold, the corresponding data is marked as an abnormal event and an abnormal event report is generated, if it is below the adaptive detection threshold, it is marked as a normal state and a normal update report is generated.

[0013] Furthermore, in step 3, the Petri net synchronization coordination model sets up one edge output repository for each edge computing node and one twin receiving repository for each sub-model in the digital twin park model. A synchronization transition is set up between each pair of edge output repositories and their corresponding twin receiving repositories. Abnormal event reports are encapsulated as red tokens and injected into the corresponding edge output repositories, and normal update reports are encapsulated as green tokens and injected into the corresponding edge output repositories. When there is at least one red token in the edge output repository, the synchronization transition is immediately triggered and all red tokens are transferred to the corresponding twin receiving repository at once, so that the corresponding digital twin sub-model immediately performs a state update. When there are only green tokens in the edge output repository and the cumulative number reaches the preset batch trigger threshold, the synchronization transition is triggered and green tokens are transferred in batches to the corresponding twin receiving repository, so that the corresponding digital twin sub-model performs a batch state update.

[0014] Furthermore, in step 3, the Petri net synchronization coordination model divides the synchronization period into fixed intervals and sets up a global coordination transition connected to all twin receivers. Within each synchronization period, twin receivers that have completed at least one state refresh or batch state update output a completion token to the global coordination transition. When an edge output receiver has not generated any tokens before the end of the current synchronization period, the edge output receiver that has not generated a token automatically sends an idle token to the corresponding twin receiver. After receiving the idle token, the twin receiver directly outputs a completion token to the global coordination transition. The global coordination transition is triggered after collecting completion tokens from all twin receivers, and sends a synchronization completion signal to the global state manager of the digital twin campus model. The global state manager then performs the consistency merging of the campus-level digital twin global view.

[0015] The real-time data acquisition and processing method for digital twin campuses integrating edge computing, as presented in this invention, has the following beneficial effects: By deploying P4 programmable switching devices and configuring multi-level serialized P4 flow tables on the network forwarding path between the data acquisition terminal and the edge computing node, this method achieves line-rate classification, labeling, and targeted scheduling of multi-source heterogeneous data streams within the campus at the hardware level. This avoids the limitation of traditional fixed-function switching devices being unable to perform content-level processing of data packets. Simultaneously, by calling a hardware hash engine to generate data fingerprint signatures and combining this with a dual-window rotating Bloom filter to perform deduplication, the filtering operation of duplicate data packets is moved from the software level of the edge computing node to the hardware level of the network forwarding device. This achieves high-throughput data deduplication without consuming the general-purpose processor resources of the edge computing node, effectively reducing the proportion of invalid data received by the edge computing node and allowing the processing resources of the edge computing node to be concentrated on in-depth analysis of valid data. The window aging switching mechanism of the dual-window rotating Bloom filter avoids the problem of a single Bloom filter gradually saturating its bit vectors and causing a continuous increase in the false positive rate due to long-term operation. Simultaneously, the dual-window joint judgment strategy reduces the probability of valid data being misclassified as duplicate data and lost, balancing deduplication efficiency and data integrity. Within the edge computing node, the hybrid expert processing architecture determines the main active expert processing unit based on the type tag value through the routing distributor. This ensures that each packet undergoes feature extraction by a specialized model strictly matching its data type, overcoming the shortcomings of a single general-purpose model in terms of insufficient accuracy in feature extraction for various heterogeneous data. The mechanism by which the routing distributor determines whether to activate the auxiliary expert processing unit based on the packet's payload characteristics ensures that the allocation of computing resources matches the actual complexity of the packet. For standard complexity packets, unnecessary multi-expert parallel computing overhead is avoided, while for high-complexity packets, more comprehensive feature representation is obtained through multi-expert joint feature extraction. The constant false alarm rate adaptive detection layer maintains independent detection sequences for each data type, avoiding interference from differences in the magnitude distribution of different data types on the accuracy of background estimation. This ensures that the detection threshold truly reflects the current fluctuation level of each data type, maintaining a stable false alarm probability even when the park's operational status fluctuates with external conditions. This overcomes the problem of drastic changes in false alarm and missed detection rates in fixed-threshold detection methods during different fluctuation periods. The Petri net synchronization coordination model uses a priority distinction mechanism of red and green tokens to ensure that abnormal event reports are delivered instantly while routine update reports are aggregated and delivered in batches. This ensures rapid response to abnormal events while reducing the computational and rendering resource consumption of the digital twin sub-model due to frequent updates of routine data.The global coordination transition, combined with the idle token mechanism, ensures that the states of all digital twin sub-models are on the same time plane at the end of each synchronization cycle, enabling the global view of the park-level digital twin to have temporal consistency, and providing a reliable data foundation for comprehensive situational analysis and coordinated decision-making based on the global view. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the data processing principle of a 3-level serial P4 flow table hardware pipeline provided in an embodiment of the present invention. Figure 2 This is a schematic diagram of the constant false alarm rate adaptive detection sliding window provided in an embodiment of the present invention; Figure 3 The diagram shows the topology of the Petri net synchronization and coordination model provided in this embodiment of the invention. Detailed Implementation

[0017] A method for real-time data acquisition and processing in a digital twin campus integrating edge computing, comprising the following steps: Step 1: Deploy P4 programmable switching equipment between the data acquisition terminal and the edge computing node in the digital twin park. Configure multi-level serial P4 flow table in the P4 programmable switching equipment to perform source identifier matching, message type classification and forwarding scheduling on the data flow in sequence. In the pipeline stage of the multi-level serial P4 flow table, call the hardware hash engine to generate data fingerprint signature for the message. Send the data fingerprint signature to the dual-window rotating Bloom filter to perform deduplication judgment. Forward the message that has passed the deduplication to the corresponding edge computing node through the multi-level serial P4 flow table. Step 2: Deploy a hybrid expert processing architecture, including a route distributor and multiple expert processing units, in each edge computing node. The route distributor determines the main active expert processing unit based on the type tag value in the packet metadata and determines whether to activate the auxiliary expert processing unit simultaneously based on the packet's payload characteristics. The feature vector output by the expert processing unit is sent to the constant false alarm rate adaptive detection layer. The constant false alarm rate adaptive detection layer maintains independent detection sequences according to data types and determines the adaptive detection threshold through a sliding detection window. Based on the detection results, it generates an abnormal event report or a normal update report. Step 3: Construct a Petri net synchronization coordination model, encapsulate abnormal event reports and normal update reports into tokens of different priorities and inject them into the edge output repository. The synchronization transition executes immediate or batch transmission to the twin receiving repository according to the token priority, driving the corresponding digital twin sub-model to perform state update. After the global coordination transition collects the completion tokens of all twin receiving repositories, it triggers the consistency merging of the global view of the park-level digital twin.

[0018] In the actual deployment environment of a digital twin park, data acquisition terminals are diverse and spatially distributed. In a typical scenario, hundreds or even thousands of acquisition terminals may operate simultaneously in a single park, including temperature and humidity sensors, vibration sensors, power monitoring instruments, access control controllers, video encoders, and personnel positioning tags. These terminals continuously generate data packets with their own independent sampling frequencies and communication protocols, which are then aggregated to the aggregation layer switching equipment in the park network. If all raw data packets are directly sent to the edge computing nodes for processing, a severe traffic bottleneck will form in a short period of time, especially when terminals in multiple areas report simultaneously during peak hours. The receiving queue of the edge computing nodes is prone to overflow and packet loss, causing critical event data to be submerged in a large number of redundant packets. Therefore, an intelligent traffic splitting and preprocessing mechanism based on P4 programmable switching equipment is introduced between the data acquisition terminals and the edge computing nodes. This mechanism can complete data classification, labeling, duplicate filtering, and targeted scheduling at line speed on the network forwarding path, accurately delivering the preprocessed valid packets to the target edge computing nodes, thereby significantly reducing the burden of invalid data processing on the edge computing nodes.

[0019] The core difference between P4 programmable switches and traditional fixed-function switches lies in the user-defined data plane pipeline. Specifically, the P4 language allows developers to define the parsing logic of the packet parser, the matching fields and actions of the match-action table, and the output format of the packet reassembler. In this embodiment, the P4 programmable switch is deployed at the campus aggregation layer. Its uplink ports connect to the access switches where each data acquisition terminal is located, and its downlink ports connect to different edge computing nodes. The P4 programmable switch is internally configured with three levels of cascaded P4 flow tables. After a data packet enters from the ingress port, it sequentially passes through the first-level source identifier matching flow table, the second-level packet type classification flow table, and the third-level forwarding scheduling flow table. After each flow table completes specific matching judgments and metadata writing operations, the packet is sent to the next level flow table for further processing. The three levels of flow tables pass intermediate processing results through packet metadata fields. The entire pipeline is executed in a pipelined manner at the hardware level, and the processing latency of a single packet from the ingress port to the egress port can be controlled at the microsecond level.

[0020] The Level 1 Source Identifier Matching Flow Table is responsible for identifying the source device of a data packet and marking its region. During the campus deployment phase, maintenance personnel pre-write the mapping relationship between the device address of each data acquisition terminal and the device region code of its physical installation location into the entries of the Level 1 Source Identifier Matching Flow Table. Device addresses typically use 48-bit Media Access Control addresses in Ethernet environments, and may use 64-bit extended unique identifiers in Industrial IoT environments, depending on the access protocol type of the campus network. When a data packet arrives at the ingress port of the P4 programmable switch, the packet parser first extracts the source device address field of the packet. The Level 1 Source Identifier Matching Flow Table uses the source device address field as the matching key to perform an exact match or longest prefix match in the configured entries. After a match is found, the Level 1 Source Identifier Matching Flow Table performs a write operation, writing the pre-stored device region code from the corresponding entry into the specified field position of the packet metadata. The device region code is represented by a 16-bit unsigned integer. For example, the code value for the first floor of Building A in the park is 0x0101, the code value for the third floor of Building B is 0x0203, and so on. This code value will be continuously used in subsequent flow tables and downstream edge computing nodes to identify the spatial ownership of data. If a match is not found, it indicates that the packet comes from an unregistered terminal device. The Level 1 source identifier matching flow table performs a default action on the packet, that is, writes the device region code to the reserved value 0xFFFF and continues to forward it to the Level 2 packet type classification flow table, where downstream links decide whether to accept or discard it.

[0021] The purpose of the Level 2 message type classification flow table is to distinguish data streams into different service types based on the protocol characteristics of the messages. In a digital twin park, different types of data acquisition terminals typically use different communication protocols or different application identifiers within the same protocol framework. For example, environmental sensing sensors may report data via a lightweight messaging protocol, equipment operation instruments may report data after conversion via an industrial fieldbus protocol gateway, and personnel activity tags may report data via an ultra-wideband positioning protocol. To achieve unified classification processing in the P4 programmable switching device, this implementation defines a custom protocol identifier field in the reported messages of the park's data acquisition terminals. This field is 8 bits long and embedded at the beginning of the Ethernet payload of the message. In messages from environmental sensing terminals, this field is filled with a value of 0x01; in messages from equipment operation terminals, it is filled with a value of 0x02; and in messages from personnel activity terminals, it is filled with a value of 0x03. The Level 2 message type classification flow table performs exact matching using the combination of the Ethernet type field and the custom protocol identifier field as the matching key. Upon a successful match, the Level 2 message type classification flow table writes a type tag value into the message metadata. The environmental awareness category corresponds to type tag value 1, the device operation category to type tag value 2, and the personnel activity category to type tag value 3. The type tag value is represented by an 8-bit unsigned integer and written to a fixed offset position in the message metadata for subsequent pipeline stages and downstream edge computing nodes to read and use.

[0022] In one optional implementation, if the protocol architecture of the data acquisition terminals within the park is relatively uniform and they all use the same application layer protocol, the Level 2 message type classification flow table can also use only a single field of the custom protocol identifier field as the matching key, eliminating the need for combined matching of the Ethernet type field, thereby reducing the entry width and matching latency of the flow table. In another optional implementation, if there are more than three data types within the park, such as energy consumption monitoring and security alarm types, the value range of the custom protocol identifier field and the number of types of type flag values ​​can be expanded accordingly, and the number of entries in the Level 2 message type classification flow table will increase accordingly.

[0023] refer to Figure 1 It demonstrates the complete processing path of data packets from entering the P4 programmable switching device to completing classification, deduplication filtering, and forwarding scheduling. Figure 1 The top of the image shows the structure of the original data packet, which consists of five areas arranged sequentially: destination address, source device address, Ethernet type field, custom protocol identifier field, and payload. Below the packet structure is the packet metadata area, which contains three fields: a 16-bit device area code, an 8-bit type tag value, and a 32-bit data fingerprint signature. These three fields are not carried by the original packet itself, but are written step-by-step by the flow tables and hardware hash engine at each stage of the pipeline processing. Figure 1 Five processing stages are arranged horizontally in the middle of the flow chart, from left to right according to the data flow sequence: Level 1 Source Identifier Matching Flow Table, Level 2 Message Type Classification Flow Table, Hardware Hash Engine CRC32 Operation, Dual-Window Round Robin Bloom Filter, and Level 3 Forwarding Scheduling Flow Table. Adjacent processing stages are connected by directed arrows, indicating that the message flows through each stage sequentially in the hardware pipeline. An arrow pointing from the source device address field in the message structure to the Level 1 Source Identifier Matching Flow Table indicates that the Level 1 Source Identifier Matching Flow Table extracts the source device address as the matching key to perform table entry matching. Dashed arrows pointing from the Level 1 Source Identifier Matching Flow Table, Level 2 Message Type Classification Flow Table, and Hardware Hash Engine to the corresponding fields in the metadata area indicate that each processing stage writes the result to the corresponding location in the message metadata after completing the matching or operation. The Level 1 source identifier matching flow table writes the device region code obtained after a match into the first field of the metadata. The Level 2 packet type classification flow table writes the type tag value determined after classification into the second field of the metadata. The hardware hash engine writes the 32-bit data fingerprint signature generated by CRC32 operation into the third field of the metadata. Two paths are derived from the dual-window round-robin Bloom filter stage: one leads to the output end marked as "discarded duplicate packets," indicating that packets determined as duplicates by the Bloom filter are directly discarded at the hardware level and do not enter further processing; the other leads to the Level 3 forwarding scheduling flow table, indicating that packets that pass the deduplication check continue to enter the forwarding scheduling stage. The Level 3 forwarding scheduling flow table leads down to the output end marked as "forwarded to edge computing nodes," indicating that valid packets that have completed all pipeline processing are forwarded to the corresponding edge computing nodes. Figure 1 The lower left corner shows the data acquisition terminal's message input, connected by an upward arrow to the Level 1 source identifier matching flow table, indicating the starting point for the raw data message to enter the pipeline from the acquisition terminal. The entire diagram clearly shows the step-by-step processing of messages in the P4 programmable switch through three levels of flow tables and a hardware hash engine, as well as the data flow relationship where metadata fields are sequentially filled in each processing stage.

[0024] After a packet is classified through the Level 2 packet type classification flow table, it enters the P4 hardware pipeline stage between the Level 2 packet type classification flow table and the Level 3 forwarding scheduling flow table. In this stage, the P4 programmable switch calls its built-in hardware hash engine to generate a data fingerprint signature for the packet. The hardware hash engine is a commonly integrated functional unit in P4 switching chips, capable of performing hash operations on packet content at line speed without consuming general-purpose processor resources.

[0025] In this embodiment, the input to the hardware hash engine consists of three parts: the first part is a fixed-length protocol header field sequence extracted by the packet parser of the Level 2 packet type classification flow table; the second part is the device area code written by the Level 1 source identifier matching flow table; and the third part is the type tag value written by the Level 2 packet type classification flow table. These three parts are concatenated byte-wise to form a continuous input data segment. The hardware hash engine performs a 32-bit Cyclic Redundancy Check (CRC32) hash operation on this input data, outputting a 32-bit hash value as a data fingerprint signature. The CRC32 operation is chosen instead of a cryptographic hash algorithm because its hardware implementation complexity is extremely low, allowing calculations to be completed within a single clock cycle, making it suitable for high-throughput network forwarding paths. On a P4 switching chip with a throughput of 100 gigabits per second, approximately 148.8 million packets need to be processed per second (based on a minimum Ethernet frame length of 64 bytes). The CRC32 operation can keep up with this processing rate without introducing additional pipeline bubbles. The 32-bit signature space provides approximately 4.29 billion distinct values, offering a sufficiently low collision probability for duplicate data filtering in campus data collection scenarios. The generated 32-bit data fingerprint signature is written into the signature field of the message metadata, occupying a reserved 32-bit width in the message metadata.

[0026] In one optional implementation, the specific content of the fixed-length protocol header field sequence can be flexibly configured according to the protocol structure of the campus data packets. For example, if the data packet uses Internet Protocol version 4 (IPL) encapsulation, the fixed-length protocol header field sequence may include a 13-byte five-tuple field containing the source IPL address, destination IPL address, protocol number, source port number, and destination port number. If the data packet uses a campus-defined lightweight IoT protocol encapsulation, the fixed-length protocol header field sequence may include fields such as terminal serial number, sampling timestamp, and data object identifier. In another optional implementation, the hardware hash engine can also use CRC16 operations to generate a 16-bit data fingerprint signature to save metadata storage space, but the signature space is reduced to approximately 65,000 possible values, and the collision probability increases accordingly. This is suitable for small campuses with a small number of terminals and a low data reporting frequency.

[0027] After the 32-bit data fingerprint signature is generated, it is immediately sent to the dual-window rotating Bloom filter maintained inside the P4 programmable switch for existence determination. A Bloom filter is a probabilistic data structure based on multiple independent hash functions and bit vectors, capable of determining whether an element might exist in a set in constant time. The determination result is divided into two types: if the Bloom filter reports that an element does not exist, then the element is definitely not in the set; if the Bloom filter reports that an element exists, then the element may or may not be in the set, the latter being a false positive. The false positive rate is related to the bit vector length of the Bloom filter, the number of hash functions, and the number of elements already inserted. In a campus data acquisition scenario, a false positive means that a completely new data packet is mistakenly judged as a duplicate packet and discarded, leading to the loss of valid collected data.

[0028] To alleviate this issue, this implementation uses a dual-window round-robin Bloom filter instead of a single Bloom filter. The dual-window round-robin Bloom filter maintains two independent Bloom filter instances, referred to as the current active window and the standby window. Both windows have the same bit vector length and hash function configuration. During operation, all newly arriving 32-bit data fingerprint signatures are only inserted into the current active window, but existence queries are performed simultaneously in both the current active window and the standby window. The determination logic is as follows: only when the 32-bit data fingerprint signature is reported as present in both the current active window and the standby window is the packet ultimately determined to be a duplicate packet and directly discarded in the P4 hardware pipeline stage. If it is reported as not present in either window, the packet is determined to be a non-duplicate packet, the 32-bit data fingerprint signature is inserted into the current active window, and the packet continues to be sent to the Level 3 forwarding scheduling flow table. Compared to a single-window Bloom filter, this dual-window joint decision mechanism, under the same bit vector length and number of hash functions, can reduce the false positive rate from the level of a single window to the product level of the false positive rates of two windows, thereby significantly reducing the probability of valid data being mistakenly discarded.

[0029] Every preset rotation cycle, the dual-window rotating Bloom filter performs a window switching operation: after clearing all bit vectors of the backup window, it switches the backup window to the new active window, while demoting the original active window to a backup window. This ensures that the number of elements accumulated by each Bloom filter instance covers at most two rotation cycles, avoiding the problem of bit vector saturation and a continuously rising false positive rate due to prolonged operation. The rotation cycle value can be determined based on the actual configuration of the park's data reporting frequency and the Bloom filter bit vector length. For example, in a park with 500 data acquisition terminals, each reporting one data entry per second, if the Bloom filter bit vector length is configured to 1,048,576 bits and uses three independent hash functions, the false positive rate will be approximately one percent when the number of inserted elements reaches about 50,000, and the corresponding rotation cycle can be set to 100 seconds. In another implementation, the rotation cycle can also be dynamically adjusted based on the real-time monitored Bloom filter bit vector fill rate, triggering window switching in advance when the fill rate exceeds a preset upper limit threshold.

[0030] In one alternative implementation, the dual-window rotating Bloom filter can also be extended to a three-window rotating structure, that is, simultaneously maintaining three Bloom filter instances: the currently active window, the previous period window, and an earlier period window. Existence determination requires the 32-bit data fingerprint signature to be reported as present in all three windows before it is considered a duplicate, further reducing the false positive rate, but correspondingly increasing storage resource consumption.

[0031] Packets that pass the deduplication check ultimately enter the Level 3 forwarding scheduling flow table. The Level 3 forwarding scheduling flow table performs exact matching using a combination of type flag value and device region code as the matching key. Upon a match, port forwarding is executed, sending the packet from the designated outgoing port of the P4 programmable switch to the designated incoming port of the corresponding edge computing node. The forwarding scheduling mapping relationship is pre-configured by operations personnel during the deployment phase based on the park's regional divisions and the processing capabilities of the edge computing nodes. For example, a packet with a type flag value of 1 and a device region code belonging to Building A is forwarded to incoming port 1 of edge computing node 1, and a packet with a type flag value of 2 and a device region code belonging to Building B is forwarded to incoming port 3 of edge computing node 2. In an optional implementation, if the data traffic of the same type and region exceeds the processing capacity of a single edge computing node, the Level 3 forwarding scheduling flow table can also be configured to perform equal-cost multi-path distribution of the traffic according to the low-order bits of the 32-bit data fingerprint signature, distributing the packets to multiple edge computing nodes to achieve load balancing.

[0032] After the above three-level serialized P4 flow table and hardware hash signature offloading process, the original multi-source mixed data stream has completed source marking, type classification, duplicate filtering and targeted delivery on the network forwarding path. The data packets arriving at the edge computing node all carry three metadata information items: device area code, type mark value and 32-bit data fingerprint signature, providing structured input conditions for the hybrid expert processing architecture in the subsequent edge computing node.

[0033] Each data packet arriving at the edge computing node after step 1 already carries three structured annotations in its metadata: device region code, type tag value, and 32-bit data fingerprint signature. The edge computing node needs to perform deep feature extraction and anomaly identification on these packets locally. Different types of data packets differ significantly in payload structure, numerical range, and semantic meaning. For example, environmental perception packets typically contain sampled values ​​of continuous physical quantities such as temperature, humidity, and air pressure; equipment operation packets typically contain mechanical and electrical parameters such as rotational speed, current, and vibration amplitude; and personnel activity packets typically contain discrete location information such as positioning coordinates, movement speed, and area identifiers. If a single general feature extraction model is used to process all types of packets, the model needs to simultaneously consider multiple distinct data distributions and semantic spaces, often resulting in unsatisfactory feature extraction accuracy for various data types in actual operation. Therefore, this implementation deploys a hybrid expert processing architecture in each edge computing node. Multiple specialized expert processing units perform feature extraction for different types of data, and a unified detection layer then identifies anomalies in the extraction results.

[0034] The hybrid expert processing architecture comprises one route distributor and three expert processing units (EPUs). Each EPU is pre-loaded with feature extraction models for environmental perception, equipment operation, and personnel activity data, respectively. Before deployment, each feature extraction model has been offline trained using data collected from the corresponding type of campus environment, and its network structure and parameters are embedded in the inference accelerator of the edge computing node. The three EPUs share the computing resources of the edge computing node, but at any given time, only the active EPU occupies the computing channels of the inference accelerator; inactive EPUs remain dormant and do not consume computing resources. This on-demand activation mode enables the edge computing node to simultaneously possess specialized processing capabilities for multiple data types under limited hardware computing power.

[0035] When a data packet arrives at the edge computing node, the route distributor first reads the type tag value from the packet's metadata. The correspondence between the type tag value and the primary active expert processing unit is deterministic: when the type tag value is 1, the primary active expert processing unit is an environment-aware expert processing unit; when the type tag value is 2, the primary active expert processing unit is a device operation expert processing unit; and when the type tag value is 3, the primary active expert processing unit is a personnel activity expert processing unit. This deterministic mapping ensures that each packet is processed by at least one expert processing unit whose data type strictly matches its data type, avoiding the risk of type mismatch that may arise from probabilistic routing.

[0036] After determining the primary active expert processing unit, the routing distributor further determines whether an auxiliary expert processing unit needs to be activated simultaneously to process the same message in parallel. This determination is based on the message's payload characteristics, specifically the number of payload fields and the total length of the payload bytes. The routing distributor performs protocol parsing on the payload area of ​​the message, counting the number of independent data fields contained within as the payload field count, and simultaneously counting the total number of bytes in the payload area as the total payload byte length. These two indicators are chosen as the basis for complexity determination because in campus data acquisition practices, when a message contains a large number of different types of data fields and has a large payload volume, the message often originates from a multi-functional composite acquisition terminal or data aggregation gateway, and its payload content may span the boundaries of multiple data categories. For example, a composite monitoring terminal installed on a distribution cabinet may simultaneously report electrical parameters and ambient temperature in the same message. In this case, processing by only the equipment operation expert processing unit may miss the characteristic information of the environmental perception data. By activating the auxiliary expert processing unit for parallel feature extraction, heterogeneous features in the message payload can be captured simultaneously from multiple professional perspectives.

[0037] The route distributor compares the number of payload fields with preset field count thresholds and the total payload byte length with preset byte length thresholds. In a typical campus deployment scenario, the field count threshold can be set to 8, and the byte length threshold can be set to 256 bytes. When both the number of payload fields and the total payload byte length exceed their respective thresholds, the route distributor classifies the packet as a high-complexity packet. When neither exceeds its threshold, the route distributor classifies the packet as a standard-complexity packet. The reason for requiring both conditions to be met simultaneously for a packet to be classified as high-complexity is that a high number of fields may simply indicate dense sampling points with each field having a single meaning, and a large byte length may simply indicate high numerical precision in a single field or the inclusion of a long timestamp. Only when both exceed their respective thresholds can it reliably indicate that the packet payload indeed possesses cross-type complexity.

[0038] For standard complexity packets, the route distributor activates only the primary active expert processing unit (APU), which independently performs feature extraction on the packet payload and outputs a feature vector of one fixed dimension. In one specific implementation, the feature vector output by each APU has 128 dimensions, meaning it contains 128 floating-point components. For high complexity packets, the route distributor activates one auxiliary APU in addition to the primary active APU. The selection rule for the auxiliary APU is as follows: select the APU whose type flag value is adjacent to that of the primary active APU. Specifically, when the primary active APU corresponds to type flag value 1, the auxiliary APU corresponds to type flag value 2; when the primary active APU corresponds to type flag value 2, the auxiliary APU corresponds to either type flag value 1 or type flag value 3. In this implementation, the APU corresponding to type flag value 1 is selected by default; when the primary active APU corresponds to type flag value 3, the auxiliary APU corresponds to type flag value 2. The reason for selecting adjacent expert processing units instead of random selection is that there is a physical correlation between data types in the actual environment of the park. The correlation between environmental perception and equipment operation is usually higher than that between environmental perception and personnel activities. Adjacent expert processing units are more likely to extract complementary and effective features from high-complexity messages. The main active expert processing unit and the auxiliary expert processing unit independently perform feature extraction on the payload of the same message, each outputting a 128-dimensional feature vector. Then, the routing distributor concatenates the two 128-dimensional feature vectors end to end in dimensional order to form a 256-dimensional joint feature vector. The concatenation operation itself does not involve any numerical transformation; it simply arranges the 128 components of the first vector first and the 128 components of the second vector last, forming a continuous 256-dimensional floating-point sequence.

[0039] In one optional implementation, the field number threshold and byte length threshold can be adjusted according to the actual terminal configuration of the park. For example, in an industrial manufacturing park, the message payload reported by equipment operation terminals is generally large, so the byte length threshold can be increased to 512 bytes to avoid too many messages being judged as high-complexity messages and increasing computational overhead. In another optional implementation, the selection of auxiliary expert processing units can also be extended to simultaneously activate two auxiliary expert processing units, that is, all three expert processing units participate in the processing. In this case, the dimension of the joint feature vector is 384 dimensions, but the corresponding computational resource consumption also increases to 3 times.

[0040] After feature extraction by the expert processing unit, the final output for each message is a feature vector: a 128-dimensional feature vector for standard complexity messages and a 256-dimensional joint feature vector for high complexity messages. These feature vectors are then fed into the constant false alarm rate adaptive detection layer for anomaly state identification.

[0041] The core idea of ​​constant false alarm rate (CFAR) detection originates from the field of radar signal processing. In radar systems, receivers need to detect target echoes amidst background signals filled with clutter and noise. Directly setting a fixed detection threshold leads to drastic changes in the false alarm rate when the background noise power fluctuates, severely interfering with subsequent target tracking. CFAR detection uses reference cells around the target unit to estimate the current background statistical level, thereby adaptively adjusting the detection threshold to maintain an approximately constant false alarm probability even under changing background statistical characteristics. Applying this idea to edge data anomaly detection scenarios, the adaptation logic lies in the fact that the normal operation of data acquisition terminals in a park is not static but fluctuates continuously with production cycles, day-night cycles, and seasonal changes. If a fixed threshold is set for anomaly detection, a large number of false alarms will be generated during periods of large normal fluctuations, while real anomalies may be missed during periods of small normal fluctuations. Through the CFAR detection mechanism, the detection threshold can automatically adjust with the current data fluctuation level, balancing detection sensitivity and false alarm suppression.

[0042] The constant false alarm rate (CFAR) adaptive detection layer maintains independent detection sequences for each of the three data types corresponding to the type label values. Feature vectors generated from environmental perception data are placed in the environmental perception detection sequence, feature vectors generated from equipment operation data are placed in the equipment operation detection sequence, and feature vectors generated from personnel activity data are placed in the personnel activity detection sequence. The reason for maintaining separate detection sequences by type, rather than mixing feature vectors from all types into a single sequence, is that the normal feature vector magnitude distribution ranges differ significantly between different data types. The feature vector magnitudes of environmental perception data may be concentrated in a lower value range, while those of equipment operation data may be concentrated in a higher value range. If mixed in the same detection sequence, the mixed magnitudes of different data types in the reference unit would severely distort the accuracy of background estimation, causing the detection threshold to be unable to adapt to either the low-magnitude background of environmental perception data or the high-magnitude background of equipment operation data. After separation by type, the magnitude distribution within each detection sequence is homogeneous, resulting in more accurate background estimation and detection thresholds that better reflect the true fluctuation levels of each data type.

[0043] refer to Figure 2 It uses a bar chart to show the distribution of feature vector magnitudes of each unit within the sliding detection window and the process of determining the adaptive detection threshold. Figure 2 The horizontal axis represents the cell position index in the detection sequence, ranging from 0 to 20, for a total of 21 cell positions. The vertical axis represents the feature vector magnitude. The 21 cells are arranged from left to right according to their position indices: positions 0 to 7 are the 8 reference cells on the left, positions 8 to 9 are the 2 guard cells on the left, position 10 is the target cell to be detected, positions 11 to 12 are the 2 guard cells on the right, and positions 13 to 20 are the 8 reference cells on the right. Figure 2 The bottom of the diagram uses horizontal line segments with endpoints to label the location range and name of each group of elements, clearly dividing the 21 elements into the left reference element area, left protection element area, target element area, right protection element area, and right reference element area. Reference elements are represented by diagonally filled columns, protection elements by gray-filled columns, and target elements by columns filled with intersecting lines. From... Figure 2 It can be intuitively observed that the magnitudes of the 16 reference cells are all distributed in a low range, reflecting the typical fluctuation range of normal background data, while the magnitude of the target cell located at position index 10 is significantly higher than the magnitude of the surrounding reference cells. Figure 2Two horizontal lines are drawn. The first, a dashed line, represents the reference mean, with its vertical axis equal to the arithmetic mean of the modulus values ​​of all 16 reference units, representing the estimated background level. The second, a solid line, represents the adaptive detection threshold, with its vertical axis equal to the reference mean multiplied by a preset constant false alarm rate (CFAR) sensitivity coefficient, representing the current detection threshold. The target unit's column height significantly exceeds the horizontal line containing the adaptive detection threshold. An arrowhead line extends from the top of the target unit's column, with a caption explaining that the target modulus value exceeding the threshold is considered an abnormal event. Protection units are located adjacent to the target unit on both sides. Their purpose is to exclude nearby data points that may be affected by abnormal signal energy leakage from the background estimation, making the data in the reference units closer to a pure background state. This prevents the energy of abnormal signals from raising the background estimate and reducing the detection capability for target anomalies.

[0044] Within each detection sequence, feature vectors are arranged sequentially according to their arrival time at the edge computing nodes, forming a one-dimensional ordered sequence. The constant false alarm rate (CFAR) adaptive detection layer sets a sliding detection window on this sequence. The structure of the sliding detection window is as follows: with the current target feature vector as the center, two guard units and eight reference units are placed in front of and behind the target feature vector. The guard units are adjacent to the two sides of the target feature vector, and the reference units are located outside the guard units. Therefore, the sliding detection window contains a total of 21 units: 1 target unit, 4 guard units, and 16 reference units.

[0045] The setting of protection units is a crucial mechanism in constant false alarm rate (CFAR) detection. If the data corresponding to the target unit does indeed exhibit anomalies, these anomalies often have temporal extensibility, meaning that adjacent data points before and after the anomaly may also be affected by the anomaly and show higher modulus values. If the adjacent data points of the target unit are directly included in the reference unit for background estimation, the energy of the anomaly signal will leak into the background estimate, leading to an overestimation of the background level. This, in turn, raises the detection threshold and reduces the ability to detect the target anomaly. Protection units, acting as an isolation zone between the target unit and the reference unit, exclude potentially affected neighboring data from the background estimation, making the data in the reference unit closer to a pure background state. Setting two protection units on each side is sufficient to isolate the impact range of most short-term anomaly events at the typical temporal resolution of campus data acquisition.

[0046] Each reference cell stores one feature vector. The constant false alarm rate (CFAR) adaptive detection layer reads the magnitude of each feature vector in all 16 reference cells. The magnitude of a feature vector is the square root of the sum of the squares of all its components. For a 128-dimensional feature vector, its magnitude is the square root of the sum of the squares of each of the 128 components. The magnitude is a scalar, reflecting the distance of the feature vector from the origin in the high-dimensional space. During the training of the feature extraction model, the magnitudes of feature vectors generated from normal state data tend to cluster within a relatively stable range, while the magnitudes of feature vectors generated from abnormal state data, deviating from the training distribution, are often significantly higher than the normal range. This characteristic allows the magnitude to be used as a detection statistic.

[0047] The constant false alarm rate (CFAR) adaptive detection layer performs an arithmetic mean operation on the modulus values ​​of 16 reference cells. This involves adding the 16 modulus values ​​and dividing by 16 to obtain the reference mean. The reference mean represents an estimate of the current background level. Subsequently, the reference mean is multiplied by a preset CFAR sensitivity coefficient to obtain the adaptive detection threshold. The CFAR sensitivity coefficient is a constant greater than 1, and its value determines the balance between detection sensitivity and false alarm rate. A larger sensitivity coefficient results in a higher detection threshold, a lower false alarm rate, but an increased false alarm rate; conversely, a smaller sensitivity coefficient results in a lower detection threshold, increased detection sensitivity, but also an increased false alarm rate. In a typical campus deployment configuration, the CFAR sensitivity coefficient is set to 3.5. Under the assumption that the reference cell data follows a Rayleigh distribution, the theoretical false alarm probability is approximately 0.03%. For campus scenarios with higher security requirements, where it is preferable to over-report rather than under-report, the sensitivity coefficient can be reduced to 2.5 to improve detection sensitivity.

[0048] After obtaining the adaptive detection threshold, the constant false alarm rate (CFAR) adaptive detection layer compares the magnitude of the target feature vector with the adaptive detection threshold. If the magnitude of the target feature vector exceeds the adaptive detection threshold, the corresponding data packet is determined to be in an abnormal state. The CFAR adaptive detection layer then encapsulates the packet's payload content, device region code, type marker value, 32-bit data fingerprint signature, the magnitude of the target feature vector, and the adaptive detection threshold value into an anomaly event report. If the magnitude of the target feature vector is lower than the adaptive detection threshold, the corresponding data packet is determined to be in a normal state. The CFAR adaptive detection layer then encapsulates the packet's payload content, device region code, type marker value, and 32-bit data fingerprint signature into a normal update report. The additional magnitude and threshold information included in the anomaly event report facilitates subsequent manual review and anomaly tracing analysis.

[0049] One implementation detail that needs special attention is that when the sliding detection window is at the beginning of the detection sequence, there may not be enough of the eight reference units available before the target feature vector. In this case, the constant false alarm rate (CFAR) adaptive detection layer only uses the reference units after the target feature vector for background estimation, reducing the number of reference units to eight plus the number of actually available reference units in front. When the total number of feature vectors accumulated in the detection sequence is insufficient to form a complete sliding detection window (i.e., less than 21), the CFAR adaptive detection layer does not perform detection judgment on these feature vectors. Instead, it directly marks the corresponding message as a normal state and generates a normal update report. The normal sliding window detection process is then initiated after the sequence has accumulated to a sufficient length.

[0050] In one alternative implementation, the number of protection units can be adjusted based on the typical expansion width of the anomalous event over the time axis. If the anomalous event in the park lasts for a long time, for example, a single equipment failure in equipment operation data may cause dozens of consecutive messages to exhibit anomalous characteristics, the number of protection units on each side can be increased to four or more to ensure that the background estimation is not contaminated by anomalous leakage. In another alternative implementation, the number of reference units can also be adjusted from eight to sixteen per side. In this case, the reference mean is calculated based on 32 moduli, resulting in higher statistical stability of the background estimation. However, the total length of the sliding detection window also increases accordingly to 69 units, requiring a longer detection sequence. In yet another alternative implementation, the calculation of the reference mean can be replaced by an ordered statistic method, that is, the moduli of the 16 reference units are sorted from smallest to largest and the value of the median is taken as the background estimate. This method is more robust to the case where a small number of anomalous data points are mixed in with the reference units, but the computational complexity is slightly higher than that of the arithmetic mean calculation.

[0051] After processing by the constant false alarm rate adaptive detection layer, each data packet entering the edge computing node is ultimately transformed into either an anomaly report or a normal update report. These reports, as the output of step 2, are passed to the Petri net synchronization and coordination model in step 3 to drive the state update of the digital twin park model.

[0052] The abnormal event reports and routine update reports output in Step 2 are generated across various edge computing nodes. The digital twin campus model, as a virtual mapping of the physical campus, needs to systematically aggregate these processing results from different edge computing nodes and reflect them onto the corresponding digital twin sub-models, ultimately forming a globally consistent campus-level virtual view. This aggregation process faces two core challenges. The first challenge is timing coordination: different edge computing nodes have varying processing speeds and data arrival frequencies. Some nodes may generate a large number of reports in a short period, while others may have almost no new reports output during the same time period. If reports from each node are pushed arbitrarily to the digital twin sub-models without coordination, the states of the sub-models in the global view will be on inconsistent timelines, resulting in a loss of consistency. The second challenge is priority differentiation: abnormal event reports represent deviations from the normal state occurring within the campus and need to be reflected in the digital twin model as quickly as possible to support timely alerts and response decisions. Routine update reports, on the other hand, represent the daily evolution of the campus's operational status and have relatively less stringent timeliness requirements. Pushing them one by one in real-time would place an unnecessary burden of frequent refreshes on the digital twin model's rendering and computing engine.

[0053] Petri nets are a formal modeling tool suitable for describing resource flow, synchronization constraints, and conditional triggering relationships in concurrent systems. Petri nets consist of three basic elements: places, transitions, and directed arcs. Places store tokens, which represent resources or information units in the system. Transitions describe events or actions; a transition is enabled and emitted when all tokens in its input places meet its triggering conditions. During emission, tokens are removed from input places and injected into the output place. Directed arcs connect places and transitions, specifying the direction of token flow. Petri nets natively support concurrent semantics; multiple transitions can be emitted simultaneously and independently, provided their respective triggering conditions are met, without requiring a global lock or central scheduler. This characteristic makes them ideal for modeling the synchronization process of multiple edge computing nodes concurrently pushing data to multiple digital twin models.

[0054] The topology of the Petri net synchronization coordination model constructed in this embodiment is as follows. One edge output place is set up for each edge computing node, and one twin receiving place is set up for each sub-model in the digital twin campus model. In a typical campus configuration with 4 edge computing nodes and 4 digital twin sub-models, the Petri net synchronization coordination model includes 4 edge output places and 4 twin receiving places. Each pair of edge output places and its corresponding twin receiving place is connected by a synchronization transition. The input arc of the synchronization transition originates from the edge output place, and the output arc points to the corresponding twin receiving place. Therefore, there are a total of 4 synchronization transitions in the above configuration, each independently responsible for token passing between one pair of edge output places and the twin receiving place. In addition, the Petri net synchronization coordination model also sets up a global coordination transition. All 4 twin receiving places are each connected to the input of the global coordination transition via a directed arc, and the output arc of the global coordination transition points to the global state manager of the digital twin campus model.

[0055] In the token generation phase, the abnormal event report output from step 2 is encapsulated as a red token, and the normal update report is encapsulated as a green token. The difference between red and green tokens in their data payloads is that red tokens, in addition to carrying the message payload content, device region code, type marker value, and 32-bit data fingerprint signature, also carry the magnitude of the target feature vector and an adaptive detection threshold value; green tokens only carry the message payload content, device region code, type marker value, and 32-bit data fingerprint signature. The essential difference between the two types of tokens in the Petri net synchronization coordination model lies not in the difference in data payloads, but in the different priorities indicated by their color attributes. Red tokens have high priority, while green tokens have standard priority. This color attribute identification method borrows from the modeling approach of colored Petri nets, distinguishing different categories of resources by attaching discrete color attributes to tokens. This allows different categories of tokens to be accommodated simultaneously in the same repository, and the transition triggering rules can be differentiated based on the token's color attribute.

[0056] refer to Figure 3 It demonstrates the complete token passing topology from the edge output library through synchronous transition to the twin receiving library, and then through global coordination transition to the global state manager. Figure 3The top of the image shows three edge output locations side-by-side, labeled Edge Output Location 1, Edge Output Location 2, and Edge Output Location 3. Each edge output location is represented by a circle, corresponding to the output cache of one edge computing node. Edge Output Location 1's circle contains two solid small circles, representing that the location currently holds two high-priority tokens, which encapsulate exception event reports. Edge Output Location 2's circle contains three hollow small circles, representing that the location currently holds three standard-priority tokens, which encapsulate normal update reports. Edge Output Location 3's circle is empty, indicating that the location has not received any tokens in the current synchronization cycle. Each of the three edge output locations has a downward-pointing directed arc with an arrow, connecting to three synchronization transitions. Synchronization transitions are represented by horizontal black rectangles, labeled Synchronization Transition 1, Synchronization Transition 2, and Synchronization Transition 3. Above each synchronization transition, its current trigger mode is marked: Synchronization transition 1 is marked as instantaneously triggered because its input edge output storage 1 contains high-priority tokens, satisfying the instantaneous trigger condition; Synchronization transition 2 is marked as batch-triggered because its input edge output storage 2 contains only standard-priority tokens, and will trigger after the accumulated number reaches the batch trigger threshold; Synchronization transition 3 is marked as idle token-triggered because its input edge output storage 3 is empty in the current period, and will automatically send an idle token when the synchronization period is about to end. Each of the three synchronization transitions has a directed arc leading downwards to three twin receiving storages, marked as Twin Receiving Storage 1, Twin Receiving Storage 2, and Twin Receiving Storage 3, respectively. Each twin receiving storage is also represented by a circle, with the corresponding digital twin sub-model's operation in the current period marked inside the circle: immediate state refresh, batch state update, and no update operation. Each of the three twin receiving storages has a directed arc leading downwards, converging to connect to a global coordination transition, which is also represented by a black rectangular bar. Each directed arc is marked with a "completion token" label, indicating that each twin receiver has completed its processing and outputs one completion token to the global coordinated transition. The global coordinated transition is triggered after collecting completion tokens from all three twin receivers, and a directed arc is drawn downwards to the global state manager, with a synchronization completion signal marked next to the arc. The global state manager is represented by a rounded rectangle, and further connected downwards to the global view labeled "Campus-level Digital Twin Global View". Figure 1 The output of the synchronization merge indicates that the global state manager performs a unified merging operation of the states of all digital twin models after receiving the synchronization completion signal.

[0057] Each anomaly report or routine update report is immediately encapsulated as a token of the corresponding color upon generation and injected into the edge output repository corresponding to the edge computing node that generated the report. The tokens are arranged in the edge output repository in the order of injection, awaiting consumption by synchronous transitions.

[0058] The triggering rules for synchronous transitions are divided into two operating modes based on the color attribute of the tokens in the edge output library.

[0059] The first operating mode is the instant trigger mode. When the synchronous transition detects at least one red token in the edge output repository at its input end, the synchronous transition is immediately enabled and launched. During launch, the synchronous transition retrieves all the current red tokens in the edge output repository at once and transmits them to the corresponding twin receiver repository. The reason for adopting the strategy of transmitting all red tokens at once rather than one by one is that multiple abnormal event reports may be generated in a concentrated period of time. For example, after a device fails, multiple monitoring parameters associated with it will trigger abnormal detection in a short period of time. By packaging and transmitting these associated abnormal event reports, the digital twin sub-model can obtain all abnormal information at the same time in a single state refresh operation, forming a complete perception of the fault scenario, rather than refreshing in multiple fragmented steps. After receiving the red token, the twin receiver repository drives the corresponding digital twin sub-model to immediately execute the state refresh operation. The state refresh operation refers to the digital twin sub-model reading the data content carried in the red token, updating the virtual entity state parameters maintained internally, and triggering the 3D visualization engine to re-render the visual representation of the affected area.

[0060] It's worth noting that in instant-triggered mode, if both red and green tokens exist in the edge output repository, the synchronization transition will only transmit the red token in this launch, while the green token will remain in the edge output repository awaiting further processing. This design ensures that the transmission of abnormal events is not diluted or delayed by normal data updates.

[0061] The second operating mode is the batch trigger mode. When only green tokens exist in the edge output repository and the cumulative number of green tokens reaches the preset batch trigger threshold, synchronous transition is enabled and emitted, and the green tokens that have reached the threshold number are batch-transmitted to the corresponding twin receiving repository. In a typical configuration, the batch trigger threshold is set to 16 green tokens. The reason for not triggering the transmission of each green token individually is that the normal update report represents the gradual change of the normal operating status of the park, where the state difference between reports at adjacent times is very small. Transmitting them one by one would cause the digital twin sub-model to perform a large number of almost unchanged state refresh operations, wasting computing and rendering resources. After batch-transmitting multiple normal update reports, the digital twin sub-model can directly update to the latest state across multiple sampling times in one operation, reducing the number of meaningless refreshes in the middle. After receiving the batch of green tokens, the twin receiving repository drives the corresponding digital twin sub-model to perform a batch state update operation. The batch state update operation refers to the digital twin sub-model reading the data content carried in all green tokens in sequence, superimposing the state changes in turn, and finally updating the state parameters of the virtual entity to the state reflected by the last normal update report in the batch.

[0062] In one optional implementation, the batch trigger threshold can be configured differently based on the update frequency requirements of different digital twin models. For example, for digital twin models corresponding to critical equipment, the batch trigger threshold can be set to 8 to obtain a higher status update frequency; for digital twin models corresponding to environmental monitoring, the batch trigger threshold can be set to 32 to reduce refresh overhead. In another optional implementation, in addition to the token quantity threshold, batch triggering can also be supplemented with a time expiration condition. That is, when the accumulated number of green tokens has not yet reached the batch trigger threshold, but the earliest green token has resided in the edge output repository for more than the preset maximum residency time (e.g., 10 seconds), the synchronization transition will also trigger the batch transfer of all existing green tokens, avoiding long delays in normal updates during periods of low data reporting frequency.

[0063] The Petri net synchronization coordination model divides synchronization cycles at fixed intervals, with the length of each cycle determined by the campus's requirement for frequent updates to the digital twin's global view. In a campus scenario where the global view refresh rate is required to be once per second, the synchronization cycle is set to 1 second. In scenarios with lower real-time requirements, the synchronization cycle can be set to 5 seconds or 10 seconds. At the start of each synchronization cycle, the Petri net synchronization coordination model broadcasts a cycle start signal to all edge output libraries to mark the time reference for the current cycle.

[0064] The trigger condition for a global coordinated transition is: collecting one completion token from each of the twin receivers within one synchronization cycle. The generation rule for completion tokens is as follows: when a twin receiver completes at least one state refresh (driven by a red token) or one batch state update (driven by a green token) within the current synchronization cycle, that twin receiver outputs one completion token to the global coordinated transition. This means that the digital twin sub-model corresponding to that twin receiver has acquired new data from the edge computing nodes and completed its state update within the current cycle.

[0065] However, not all edge computing nodes generate new reports in each synchronization cycle. For example, data acquisition terminals in a certain area may temporarily stop reporting due to equipment maintenance, or there may be no new data changes in that area during the current cycle. In this case, the corresponding edge output repository will not receive any red or green tokens throughout the entire synchronization cycle. If the global coordination transition waits for the completion token from the twin receiving repository, the global coordination transition will never be triggered, and the global view merging operation at the entire campus level will be blocked indefinitely. To solve this problem, this implementation introduces an idle token mechanism. When an edge output repository has not generated any tokens before the end of the current synchronization cycle, it automatically sends one idle token to the corresponding twin receiving repository. The idle token does not carry any data payload; its only function is to notify the twin receiving repository that the edge computing node has no new data to synchronize during the current cycle. After receiving the idle token, the twin receiving repository does not perform any state update operations on the digital twin sub-model, but directly outputs one completion token to the global coordination transition.

[0066] The timing of sending idle tokens needs to be clearly defined. In the specific implementation, each edge output depot maintains a token counter for one cycle, which is reset to 0 upon receiving the cycle start signal. Thereafter, the counter increments by 1 whenever a red or green token is injected. When the synchronization cycle is about to end (e.g., at 90% of the cycle length), the edge output depot checks the token counter value; if the counter value is still 0, it sends one idle token. Choosing to check at 90% of the synchronization cycle time, rather than exactly at the end of the cycle, allows sufficient time margin for the transmission of idle tokens and the response of the twin receiving depot, ensuring that the globally coordinated transition receives all completion tokens before the end of the current cycle.

[0067] Once the global coordinated transition has collected all completion tokens from the digital twin receiving database within one synchronization cycle, the global coordinated transition triggers a launch. The launch action involves sending a synchronization completion signal to the global state manager of the digital twin campus model. Upon receiving the synchronization completion signal, the global state manager performs a consistency merge operation on the campus-level digital twin global view. The specific process of the consistency merge operation is as follows: the global state manager iterates through the latest state snapshots of all digital twin sub-models, writes the state parameters of each sub-model into the same transaction in the global state database, and commits it, ensuring that the state of each sub-model in the global view reflects data from the same synchronization cycle, rather than a mixture of states from different cycles. Subsequently, the global state manager issues a global refresh command to the 3D visualization engine, which then re-renders the overall virtual scene of the campus based on the latest state in the global state database. In a global view... Figure 1 After the synchronization merge is completed, all completion tokens in the global coordination transition are cleared, and the process enters the waiting state for the next synchronization cycle.

[0068] In one alternative implementation, the triggering condition for a global coordinated transition can be relaxed from strictly collecting all completion tokens to collecting at least a preset percentage of completion tokens. For example, in a large campus with 20 edge computing nodes, if a global coordinated transition is only triggered when all 20 twin receiving sites have received their completion tokens, the merging of the global view will be completely blocked if any node experiences a communication failure or processing timeout. The triggering percentage can be set to 80%, meaning a global coordinated transition is triggered when 16 completion tokens are received. The digital twin sub-models corresponding to the undelivered completion tokens maintain their state from the previous cycle during this global view merging. This approach strikes a trade-off between availability and consistency, making it suitable for scenarios where absolute strict consistency of the global view is not critical but system availability is paramount.

[0069] In another optional implementation, the length of the synchronization period can be dynamically adjusted based on the overall data activity level of the park. When most edge output libraries send idle tokens for several consecutive synchronization periods, indicating a low-activity state for the park, the synchronization period can be doubled to reduce the merging frequency and resource consumption of the global state manager. When most synchronization transitions run in instant-triggered mode for several consecutive synchronization periods, indicating frequent abnormal events, the synchronization period can be shortened to half its original length to improve the timeliness of global view updates.

[0070] After processing by the Petri net synchronization coordination model described above, anomaly event reports and routine update reports from various edge computing nodes are synchronized to the digital twin campus model in an orderly manner through priority differentiation, batch aggregation, and global coordination. Anomalies are transmitted instantly via red tokens, ensuring that the response latency of the digital twin model to campus anomalies is controlled within the time granularity of a single synchronization transition. Routine updates reduce the refresh frequency of the digital twin sub-models through batch transmission of green tokens, reducing the consumption of computing resources while maintaining the accuracy of state tracking. The global coordination transition and idle token mechanism together ensure that the campus-level global view can complete a full consistency merge at the end of each synchronization cycle, avoiding the problem of global view updates being blocked due to some nodes having no data or delays.

[0071] The above description of the embodiments is only for the purpose of helping to understand the method and core idea of ​​the present invention. For those skilled in the art, improvements and modifications can be made to the present invention without departing from the principle of the present invention, and these improvements and modifications also fall within the protection scope of the claims of the present invention.

Claims

1. A method for real-time data acquisition and processing in a digital twin campus integrating edge computing, characterized in that: The method includes the following steps: Step 1: Deploy P4 programmable switching equipment between the data acquisition terminal and the edge computing node in the digital twin park. Configure multi-level serial P4 flow table in the P4 programmable switching equipment to perform source identifier matching, message type classification and forwarding scheduling on the data flow in sequence. In the pipeline stage of the multi-level serial P4 flow table, call the hardware hash engine to generate data fingerprint signature for the message. Send the data fingerprint signature to the dual-window rotating Bloom filter to perform deduplication judgment. Forward the message that has passed the deduplication to the corresponding edge computing node through the multi-level serial P4 flow table. Step 2: Deploy a hybrid expert processing architecture, including a route distributor and multiple expert processing units, in each edge computing node. The route distributor determines the main active expert processing unit based on the type tag value in the packet metadata and determines whether to activate the auxiliary expert processing unit simultaneously based on the packet's payload characteristics. The feature vector output by the expert processing unit is sent to the constant false alarm rate adaptive detection layer. The constant false alarm rate adaptive detection layer maintains independent detection sequences according to data types and determines the adaptive detection threshold through a sliding detection window. Based on the detection results, it generates an abnormal event report or a normal update report. Step 3: Construct a Petri net synchronization coordination model, encapsulate abnormal event reports and normal update reports into tokens of different priorities and inject them into the edge output repository. The synchronization transition executes immediate or batch transmission to the twin receiving repository according to the token priority, driving the corresponding digital twin sub-model to perform state update. After the global coordination transition collects the completion tokens of all twin receiving repositories, it triggers the consistency merging of the global view of the park-level digital twin.

2. The method according to claim 1, characterized in that, In step 1, the multi-level concatenated P4 flow table includes a first-level source identifier matching flow table, a second-level message type classification flow table, and a third-level forwarding scheduling flow table, which are sequentially concatenated. The first-level source identifier matching flow table uses the device address of the data acquisition terminal as the matching key. After a match is found, the device area code to which the data acquisition terminal belongs is written into the message metadata. The second-level message type classification flow table uses the combination of the Ethernet type field and the custom protocol identifier field of the message as the matching key to divide the data flow into three types: environmental awareness, device operation, and personnel activity. The corresponding type tag value is written into the message metadata, where environmental awareness corresponds to type tag value 1, device operation corresponds to type tag value 2, and personnel activity corresponds to type tag value 3. The third-level forwarding scheduling flow table uses the combination of type tag value and device area code as the matching key to forward the deduplicated message to the designated ingress port of the corresponding edge computing node.

3. The method according to claim 2, characterized in that, In step 1, during the P4 hardware pipeline stage between the Level 2 message type classification flow table and the Level 3 forwarding scheduling flow table, the hardware hash engine built into the P4 programmable switch is invoked. The fixed-length protocol header field sequence extracted by parsing the Level 2 message type classification flow table is combined with the device area code and type tag value as input to perform a hardware-level CRC32 hash operation, generate a 32-bit data fingerprint signature, and write the 32-bit data fingerprint signature into the signature field of the message metadata.

4. The method according to claim 3, characterized in that, In step 1, the dual-window rotating Bloom filter includes a currently active window and a backup window. After each preset rotation cycle, the backup window is cleared and a new currently active window is switched to, while the original currently active window is downgraded to a backup window. During existence determination, both the currently active window and the backup window are queried. Only when the 32-bit data fingerprint signature exists in both windows is it determined to be a duplicate message and directly discarded in the P4 hardware pipeline stage. Otherwise, the 32-bit data fingerprint signature is inserted into the currently active window and the message is sent to the level 3 forwarding scheduling flow table.

5. The method according to claim 1, characterized in that, In step 2, the hybrid expert processing architecture includes one route distributor and three expert processing units. The three expert processing units preload feature extraction models for environmental perception, equipment operation, and personnel activity data, respectively.

6. The method according to claim 5, characterized in that, In step 2, the route distributor directly determines the main activation expert processing unit based on the type tag value. Simultaneously, it extracts the number of payload fields and the total length of payload bytes after parsing the packet. It compares the number of payload fields with preset field count thresholds and the total length of payload bytes with preset byte length thresholds. When both the number of payload fields and the total length of payload bytes exceed their respective thresholds, the packet is classified as high-complexity. The main activation expert processing unit and one auxiliary expert processing unit adjacent to the main activation expert processing unit's type tag value are activated. The main activation expert processing unit and the auxiliary expert processing unit independently extract feature vectors and then concatenate them end-to-end in dimensional order to form a joint feature vector. When neither exceeds its corresponding threshold, the packet is classified as standard-complexity, and only the main activation expert processing unit performs feature extraction.

7. The method according to claim 1, characterized in that, In step 2, the constant false alarm rate adaptive detection layer maintains independent detection sequences according to the data types corresponding to the type label values. Feature vectors of the same type are sequentially placed into the corresponding type detection sequences according to their arrival time. A sliding detection window is set on each detection sequence. The sliding detection window is centered on the target feature vector to be detected. A protection unit and a reference unit are set on both sides of the target feature vector. The protection unit is adjacent to the target feature vector, and the reference unit is located outside the protection unit.

8. The method according to claim 7, characterized in that, Two protection units and eight reference units are set on each side of the target feature vector. The constant false alarm rate adaptive detection layer reads the magnitude value of each feature vector in all 16 reference units, performs an arithmetic mean operation on the 16 magnitude values ​​to obtain the reference mean, and multiplies the reference mean by the preset constant false alarm rate sensitivity coefficient to obtain the adaptive detection threshold. The magnitude value of the target feature vector is compared with the adaptive detection threshold. If it exceeds the adaptive detection threshold, the corresponding data is marked as an abnormal event and an abnormal event report is generated. If it is below the adaptive detection threshold, it is marked as a normal state and a normal update report is generated.

9. The method according to claim 1, characterized in that, In step 3, the Petri net synchronization coordination model sets up one edge output vault for each edge computing node and one twin receiving vault for each sub-model in the digital twin park model. A synchronization transition is set up between each pair of edge output vaults and their corresponding twin receiving vaults. Abnormal event reports are encapsulated as red tokens and injected into the corresponding edge output vaults, and normal update reports are encapsulated as green tokens and injected into the corresponding edge output vaults. When there is at least one red token in the edge output library, the synchronous transition is triggered immediately and all red tokens are transferred to the corresponding twin receiver library at once, thus driving the corresponding digital twin sub-model to immediately perform a state refresh. When there are only green tokens in the edge output library and the cumulative number reaches the preset batch trigger threshold, the synchronous transition is triggered and the green tokens are transferred to the corresponding twin receiver library in batches, thus driving the corresponding digital twin sub-model to perform a batch state update.

10. The method according to claim 9, characterized in that, In step 3, the Petri net synchronization coordination model divides the synchronization period into fixed intervals and sets up a global coordination transition connected to all twin receivers. Within each synchronization period, twin receivers that have completed at least one state refresh or batch state update output a completion token to the global coordination transition. When an edge output receiver has not generated any tokens before the end of the current synchronization period, the edge output receiver that has not generated a token automatically sends an idle token to the corresponding twin receiver. After receiving the idle token, the twin receiver directly outputs a completion token to the global coordination transition. The global coordination transition is triggered after collecting completion tokens from all twin receivers, and sends a synchronization completion signal to the global state manager of the digital twin campus model. The global state manager then performs the consistency merging of the campus-level digital twin global view.

Images