Multi-source data processing method, system and device for city-level digital twinning

Abstract

The application discloses a multi-source data processing method, system and equipment for city-level digital twinning, and relates to the field of data processing. The method comprises the following steps: in response to an original data stream obtained from a multi-source sensing device, generating an intelligent data packet encapsulating original sensing data and computing task description information; injecting the intelligent data packet into an in-transit computing network; starting from an entry edge node, each heterogeneous computing node on the computing path performs dynamic decision-making of the computing node based on the computing task description information and the real-time load of the node itself, and generates a computing path; on the nodes of the computing path, data processing tasks are executed, and the result data packet is mapped to the corresponding entity state in the city digital twinning model in real time. The application solves the technical problems of rigid scheduling of computing power resources, and difficulty in balancing data processing time delay and resource utilization in existing multi-source data processing, and achieves the technical effects of flexible scheduling of computing power resources, and balancing of low time delay and high resource utilization in data processing.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to multi-source data processing methods, systems and equipment for city-level digital twins. Background Technology

[0002] The construction and operation of city-level digital twins heavily rely on the real-time processing and accurate mapping of multi-source sensing data. This directly determines the response efficiency and decision-making accuracy of core management scenarios such as urban emergency dispatch, traffic control, and municipal operations and maintenance, serving as a key support for the digital and intelligent upgrade of smart cities. Currently, the mainstream data processing for this scenario adopts two technical approaches: centralized cloud processing and independent local processing at edge nodes. Centralized cloud processing involves uniformly transmitting all sensing data back to the central cloud platform for computing power scheduling and data computation. Independent local processing at the edge involves each edge node collecting data locally and performing single-machine local computation without cross-node collaborative scheduling. Centralized cloud processing suffers from high network bandwidth consumption and significant transmission latency due to the long-distance transmission of massive amounts of data. Simultaneously, central cloud nodes are prone to computing power bottlenecks, failing to meet the low-latency requirements of emergency scenarios. Independent local processing at the edge lacks inter-node state coordination and dynamic computing power scheduling, making it difficult to coordinate the computing resources of heterogeneous nodes. This can lead to an imbalance where some nodes are overloaded while others are idle, and the limited computing power of a single node makes it difficult to complete complex data processing tasks.

[0003] At present, the processing of multi-source sensing data in city-level digital twins faces technical challenges such as rigid scheduling of computing resources and difficulty in balancing data processing latency and resource utilization. Summary of the Invention

[0004] This application provides a multi-source data processing method, system, and device for city-level digital twins. It employs a method that responds to the raw data stream acquired by multi-source sensing devices, generates intelligent data packets encapsulating the raw sensing data and corresponding computational task descriptions, and injects these packets into an in-transit computing network composed of multiple heterogeneous computing nodes. Starting from the entry edge node, each passing heterogeneous computing node dynamically generates a computational path based on the computational task descriptions and its own real-time load. Corresponding data processing tasks are executed at the nodes corresponding to the computational paths, and the outflowing result data packets are mapped in real-time to the corresponding entity states of the city's digital twin model. These technical means solve the existing technical problems of rigid computing resource scheduling and the difficulty in balancing data processing latency and resource utilization in city-level digital twin multi-source sensing data processing. This achieves the technical effect of flexible scheduling of computing resources while balancing low data processing latency and high resource utilization.

[0005] This application provides a multi-source data processing method for city-level digital twins, comprising: generating an intelligent data packet encapsulating the original sensing data and corresponding computational task description information in response to the raw data stream acquired from multi-source sensing devices; injecting the intelligent data packet into an in-transit computing network, wherein the in-transit computing network consists of multiple heterogeneous computing nodes, and each heterogeneous computing node along the path from the entry edge node performs dynamic decision-making based on the computational task description information and its own real-time load to generate a computational path; and executing a data processing task corresponding to the computational task description information at the nodes of the computational path, thereby mapping the result data packet flowing out of the in-transit computing network to the corresponding entity state in the city digital twin model in real time.

[0006] In a possible implementation, the following processing is performed: the computation task description information includes a processing step identifier, the type and scale of computational resources required for the processing step, and a processing priority label.

[0007] In a possible implementation, each heterogeneous computing node along the path starting from the entry edge node performs dynamic decision-making based on the computing task description information and its own real-time load, generates a computing path, and performs the following processing: the entry edge node parses the task description information of the smart data packet, extracts the identifier of the step to be processed and the required resources; the entry edge node evaluates its own real-time load and resource availability, and queries the status information of neighboring nodes to form a local network view; based on the local network view, the identifier of the step to be processed and the required resources, it calculates the action utility value of local processing, forwarding to each neighboring node, and decomposing into subtasks for parallel processing, determines the execution node with the highest utility value, and generates the computing path.

[0008] In a possible implementation, the ingress edge node assesses its own real-time load and resource availability, queries the status information of neighboring nodes, forms a local network view, and performs the following processing: the in-transit computing network is deployed with a distributed state synchronization protocol, and the ingress edge node broadcasts its own real-time load and resource availability through the distributed state synchronization protocol, and receives similar information from neighboring nodes to construct the local network view.

[0009] In a possible implementation, the following processing is performed: Reference metrics for calculating the action utility values ​​of local processing, forwarding to neighboring nodes, and decomposing into parallel subtasks include task execution latency, result quality, and node energy consumption; wherein, the action utility value for decomposing into parallel subtasks is calculated only if and only if the action utility values ​​of local processing and forwarding to neighboring nodes are both within a preset low utility value range. Specifically, based on the pending step identifier in the task description information and according to task dependencies, the current computation task is split into multiple independently executable subtasks, and sub-data packets are generated for each subtask; the sub-data packets of the multiple subtasks are distributed to multiple downstream nodes, one of which has a convergence node identifier, multiple sub-paths are determined, the sum of the utility values ​​of each sub-path is calculated based on the reference metrics, and the decomposition and synchronization overhead is subtracted to obtain the action utility value for decomposing into parallel subtasks.

[0010] In a possible implementation, before calculating the action utility value for local processing, forwarding to each neighbor node, and decomposing into subtasks for parallel processing, the following processing is also performed: at the entry edge node, the processing priority label in the computation task description information is checked. If it is the highest priority, the action utility value calculation is skipped, and the local preemptive computation is directly entered or forwarded to the neighbor node with the best resources.

[0011] In a possible implementation, the following process is performed: each of the multiple heterogeneous computing nodes is equipped with a lightweight computing sandbox, and through the lightweight computing sandbox, a data processing task corresponding to the computing task description information is executed.

[0012] In a possible implementation, at the nodes of the computing path, a data processing task corresponding to the computing task description information is executed, and the following processing is performed: the node identifies the task identifier to be executed based on the processing step identifier in the computing task description information; it searches for the executable module corresponding to the task identifier in the local micro-task library, and if no match is found, it initiates a pull request to the central repository; the executable module is instantaneously loaded in a lightweight computing sandbox, and the original perception data in the intelligent data package is loaded into the sandbox memory space for data processing.

[0013] This application also provides a multi-source data processing system for city-level digital twins, including: an intelligent data packet generation module, used to generate intelligent data packets encapsulating the original sensing data and corresponding computing task description information in response to the raw data stream obtained from multi-source sensing devices; a computing path generation module, used to inject the intelligent data packets into an in-transit computing network, the in-transit computing network being composed of multiple heterogeneous computing nodes, each heterogeneous computing node along the path starting from the entry edge node performing dynamic decision-making based on the computing task description information and its own real-time load, and generating a computing path; and an entity state mapping module, used to execute data processing tasks corresponding to the computing task description information at the nodes of the computing path, and to map the result data packets flowing out of the in-transit computing network to the corresponding entity states in the city digital twin model in real time.

[0014] This application also provides an electronic device, including: a memory for storing executable instructions; and a processor for implementing a multi-source data processing method for city-level digital twins when executing the executable instructions stored in the memory.

[0015] The proposed method, system, and device for multi-source data processing in city-level digital twins, as described in this application, first responds to the raw data stream acquired from multi-source sensing devices by generating an intelligent data packet encapsulating the raw sensing data and corresponding computational task description information. Then, the intelligent data packet is injected into an in-transit computing network, which consists of multiple heterogeneous computing nodes. Each heterogeneous computing node along the path, starting from the entry edge node, performs dynamic decision-making based on the computational task description information and its own real-time load, generating a computational path. Finally, at the nodes along the computational path, a data processing task corresponding to the computational task description information is executed, and the result data packet flowing out of the in-transit computing network is mapped in real-time to the corresponding entity state in the city's digital twin model. Through this process, the proposed method, system, and device achieve flexible scheduling of computing resources while balancing low latency and high resource utilization in data processing. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings of the embodiments of the present invention will be briefly described below. Flowcharts are used in this application to illustrate the operations performed by the system according to the embodiments of the present application. It should be understood that the preceding or following operations are not necessarily performed precisely in sequence. Instead, various steps can be processed in reverse order or simultaneously as needed. Furthermore, other operations can be added to these processes, or one or more steps can be removed from these processes.

[0017] Figure 1This is a flowchart illustrating a multi-source data processing method for city-level digital twins provided in an embodiment of this application.

[0018] Figure 2 This is a schematic diagram of the structure of a multi-source data processing system for city-level digital twins provided in an embodiment of this application.

[0019] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0020] Explanation of reference numerals in the attached drawings: Intelligent data packet generation module 10, calculation path generation module 20, entity state mapping module 30, input device 301, processor 302, memory 303, output device 304. Detailed Implementation

[0021] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided below.

[0022] This application provides a multi-source data processing method for city-level digital twins, such as... Figure 1 As shown, the method includes: Step S100: In response to the raw data stream obtained from the multi-source sensing device, an intelligent data packet is generated that encapsulates the raw sensing data and the corresponding computing task description information, wherein the computing task description information includes a processing step identifier, the type and scale of computing resources required for the processing step, and a processing priority label.

[0023] Specifically, multi-source sensing devices refer to various data collection terminals deployed in the city, and the raw data stream is the unprocessed basic data collected in real time by these terminals. The computing task description information is a set of processing instructions bound to the data, the processing step identifier is used to mark the specific processing operations that need to be performed on the data, the computing resource type and scale limit the hardware, computing power and other resources required to complete the processing, and the processing priority label is used to distinguish the urgency of the task.

[0024] Specifically, data acquisition drivers adapted to different sensing devices are deployed, including dedicated drivers for urban sensing devices such as cameras, traffic radar, weather sensors, fire smoke detectors, and manhole cover monitoring sensors, to achieve compatible access to raw data streams with different protocols and formats. A task description information template is constructed, with fixed fields for processing step identifiers, computing resource type and scale, and processing priority labels. The processing step identifier uses preset string encodings, such as data cleaning encoding, target recognition encoding, spatial positioning encoding, and anomaly detection encoding. The computing resource type and scale field uses quantitative indicators, such as the number of CPU cores, memory capacity, GPU computing power, and network bandwidth. The processing priority label uses hierarchical identification, such as Level 1 (highest priority), Level 2 (normal priority), and Level 3 (low priority). A serialization encapsulation protocol is used to package the raw sensing data and the completed computing task description information into a unified format smart data packet, such as using the Protobuf serialization protocol. A unique data packet ID is generated for each smart data packet for subsequent tracking and management.

[0025] For example, smoke detectors in urban fire zones collect raw data on smoke concentration. The data acquisition driver accesses the raw data stream via the 485 serial port protocol. The processing step identifier is filled with anomaly detection code. The computing resource type and scale are labeled as single-core CPU and 512MB memory. The processing priority label is labeled as the highest priority level. The data is encapsulated through the Protobuf protocol to generate a smart data packet with a unique ID.

[0026] Step S200: Inject the intelligent data packet into the in-transit computing network. The in-transit computing network consists of multiple heterogeneous computing nodes. Each heterogeneous computing node along the route, starting from the entry edge node, performs dynamic decision-making based on the computing task description information and its own real-time load to generate a computing path. Each of the multiple heterogeneous computing nodes is equipped with a lightweight computing sandbox. Through the lightweight computing sandbox, data processing tasks corresponding to the computing task description information are executed.

[0027] Specifically, the in-transit computing network is a distributed computing network built for processing urban digital twin data. Heterogeneous computing nodes refer to computing devices in the network with different computing power, hardware architectures, and deployment locations; edge nodes, cloud servers, and gateway devices all belong to this type of node. Lightweight computing sandboxes are isolated operating environments deployed on each node to securely execute data processing tasks and avoid interference between different tasks.

[0028] Specifically, the physical and network architecture of the in-transit computing network is constructed using fiber optics, 5G, and industrial Ethernet to build network communication links. Heterogeneous computing nodes, such as edge computing gateways, street-level edge servers, district-level cloud computing nodes, and city-level cloud data centers, are networked together. Each node is pre-installed with a lightweight computing sandbox runtime environment. A communication handshake mechanism is established between nodes. After a smart data packet arrives at the entry edge node, it first undergoes network identity verification. Once verification is successful, it is officially injected into the in-transit computing network, initiating a dynamic node decision-making mechanism. Each passing node periodically obtains its own load data and neighbor node status data, and combines this with the computing task description information in the smart data packet to perform node selection, task forwarding, or task decomposition operations, gradually constructing the computing path.

[0029] For example, a smart camera at an intersection acts as a sensing device, and its corresponding edge computing gateway acts as an entry edge node. Smart data packets are injected into the in-transit computing network through a 5G link. The gateway first completes identity verification, and then initiates status interaction with the adjacent street edge server and district-level cloud node to start a dynamic decision-making process.

[0030] In one possible implementation, each heterogeneous computing node along the path from the entry edge node performs dynamic decision-making based on the computing task description information and its own real-time load, generating a computing path. Step S200 further includes step S210, where the entry edge node parses the task description information of the smart data packet to extract the identifier of the step to be processed and the required resources. Specifically, the entry edge node is pre-installed with a deserialization parsing module corresponding to S100, which supports parsing smart data packets in serialization formats such as Protobuf. The parsing module decomposes the data packet according to the field structure of the preset task description information template, and extracts the encoding of the identifier of the step to be processed, the hardware category corresponding to the computing resource type, and the quantized value corresponding to the computing resource scale through string matching and field index positioning. After parsing, the extracted information is stored in the node's local cache, such as DDR4 high-speed memory, for use in the decision-making process. At the same time, data packets that fail to be parsed are marked to trigger retransmission or exception reporting mechanisms.

[0031] For example, the ingress edge node runs a Protobuf deserialization program to parse the smart data packet, locate the processing step identifier field, extract the target recognition code, and extract information such as the computing resource type being GPU, the computing scale being 4G of video memory, and the single-core computing power being 10TOPS. This information is then stored in the node's local 16GB high-speed cache.

[0032] In step S220, the ingress edge node assesses its own real-time load and resource availability, and queries the status information of neighboring nodes to form a local network view. Specifically, the ingress edge node deploys a system resource monitoring component, which collects real-time operating indicators such as CPU utilization, remaining memory capacity, GPU utilization, network bandwidth utilization, and disk I / O rate. Resource availability is determined using preset resource thresholds; for example, a CPU utilization exceeding 85% is considered high load and resource unavailability. Simultaneously, a neighbor node status query mechanism is initiated. Through a dedicated communication port between nodes, status query commands are sent to pre-configured directly connected neighboring nodes in the network topology, and the node receives load and resource indicators of the same type from its neighbors. The node then structures its own indicator data and the indicator data of all neighboring nodes, storing them in a format based on node identifier, resource type, load rate, and availability to form a local network view. This view data is stored in a relational database on the node, such as an SQLite database.

[0033] For example, the resource monitoring component of the ingress edge node collects its own data every 100 milliseconds. If it detects that its CPU utilization is 70% and memory is 30% remaining, it determines that the resources are available. Then, it sends query commands to two neighboring nodes with IP addresses of 192.168.1.10 and 192.168.1.11. After receiving the feedback load data, it organizes the metrics of the three nodes into structured data, generates a local network view, and writes it to the local SQLite database.

[0034] In one possible implementation, the ingress edge node assesses its own real-time load and resource availability, and queries the status information of neighboring nodes to form a local network view. Step S220 further includes step S221, in which the in-transit computing network is deployed with a distributed state synchronization protocol. The ingress edge node broadcasts its own real-time load and resource availability through the distributed state synchronization protocol and receives similar information from neighboring nodes to construct the local network view.

[0035] Specifically, a mature distributed state synchronization protocol, such as the Raft distributed consensus protocol, is selected and deployed across all nodes in the on-the-go computing network, configuring a unified multicast address and synchronization period. The ingress edge node encapsulates its real-time load and resource availability data into state synchronization messages according to the configured synchronization period, e.g., 50 milliseconds, and broadcasts them to all neighboring nodes via multicast. Upon receiving the broadcast message, the neighboring node verifies the message; if verification is successful, it parses and stores the state data within the message, and simultaneously feeds back its own state data to the ingress edge node using the same multicast method. The ingress edge node deduplicates and verifies the received state data from all neighboring nodes, removing timeout and erroneous data, and then combines this with its own state data to complete the construction and real-time updating of the local network view.

[0036] For example, all nodes in the on-the-go computing network deploy the Raft protocol, configure the multicast address 224.0.0.10, and have a synchronization period of 50 milliseconds. Every 50 milliseconds, the ingress edge node multicasts a status message indicating its own CPU utilization of 70% and remaining memory of 30%. After receiving and verifying the message, neighboring nodes return their own status data indicating CPU utilization of 40% and 90%. The ingress edge node then removes timeout data and integrates the valid data to complete the real-time update of the local network view.

[0037] Step S230: Based on the local network view, the identifier of the step to be processed, and the required resources, calculate the action utility value for local processing, forwarding to neighboring nodes, and decomposing into subtasks for parallel processing. Determine the execution node with the highest utility value and generate the calculation path. Specifically, a multi-factor utility value calculation model is pre-constructed. The model inputs include node state data in the local network view, task complexity corresponding to the identifier of the step to be processed, and matching degree of required resources. The model normalizes each input indicator to eliminate differences in units. For the two processing methods, local processing and forwarding to neighboring nodes, the normalized indicator data is substituted to calculate the corresponding action utility value. Compare all calculated utility values, select the processing method with the highest value, determine the corresponding execution node, and determine the link from the entry edge node to the execution node as the calculation path. If the utility values ​​of the first two methods are both in the low utility range, then start the calculation of the utility value of task decomposition.

[0038] For example, the pre-built utility value calculation model sets task complexity, resource matching degree, and node response speed as core input factors. After normalization, the local processing utility value is calculated to be 65 points, and the forwarding to the neighbor node 192.168.1.10 utility value is 88 points. 88 points is the most efficient value. Therefore, the neighbor node is determined as the execution node, and the calculation path from the entry edge node to the node is generated.

[0039] In one possible implementation, step S230 further includes step S231, where reference indicators for calculating the action utility value of local processing, forwarding to neighboring nodes, and decomposition into subtasks for parallel processing include task execution latency, result quality, and node energy consumption. Specifically, a quantitative acquisition and calculation method is set for each reference indicator. Task execution latency is obtained through the node's task processing timing component, recording the time difference from task reception to task output, in milliseconds. Result quality is quantified according to the task type; for example, for image recognition tasks, recognition accuracy is used as the result quality indicator, and a score is calculated by comparing the processing result with a standard sample library, ranging from 0 to 100 points. Node energy consumption is collected from the node's power management chip in real-time power consumption data, in watts, and then combined with the task execution time to calculate the total energy consumption of the task execution. These three indicators are incorporated into the utility value calculation model, with weight allocation rules set, such as a 40% weight for general task latency, a 40% weight for result quality, and a 20% weight for energy consumption. The final action utility value is calculated by weighted summation.

[0040] Step S232: If and only if the utility values ​​of the local processing and forwarding to each neighbor node are all within a preset low utility value range, then the utility values ​​of the actions decomposed into parallel processing of subtasks are calculated. Specifically, based on the pending step identifier in the task description information and according to the task dependency relationship, the current calculation task is split into multiple independently executable subtasks, and a sub-data packet is generated for each subtask. The sub-data packets of the multiple subtasks are distributed to multiple downstream nodes, one of which has a convergence node identifier. Multiple sub-paths are determined, and the sum of the utility values ​​of each sub-path is calculated based on reference indicators. The decomposition and synchronization overhead is then subtracted to obtain the utility values ​​of the actions decomposed into parallel processing of subtasks. Specifically, a low utility value range is preset, for example, 0-60 points. First, it is determined whether the utility values ​​of the local processing and forwarding to neighbor nodes all fall within this range. If the condition is met, based on the pending step identifier, the task dependency relationship database is queried. This database stores the subtask splitting rules and dependency constraints for different processing steps, and the main task is split into subtasks that are independent and have no circular dependencies. For each subtask, a sub-data packet carrying the subtask identifier and resource requirements is generated. This sub-data packet is then distributed to downstream nodes via a network distribution protocol, with the downstream node bearing the aggregation node identifier designated as the sub-result aggregation node. The utility value of each sub-path is calculated separately, summed, and then subtracted from the computational overhead of task decomposition and the network overhead of sub-data packet synchronization to obtain the action utility value of the decomposition process. Comparing the decomposition processing utility value with the previous utility value, the most efficient scheme is selected, generating a computation path containing multiple sub-paths.

[0041] In one possible implementation, before calculating the action utility value of local processing, forwarding to each neighbor node, and decomposing into subtasks for parallel processing, step S200 further includes step S240, whereby at the entry edge node, the processing priority label in the computation task description information is checked. If it is the highest priority, the action utility value calculation is skipped, and the local preemptive computation is directly entered or forwarded to the neighbor node with the best resources.

[0042] Specifically, a priority verification module is deployed at the ingress edge node. This module directly reads the processing priority tag field value from the smart data packet and matches it with the preset highest priority identifier. If the match is the highest priority, a resource preemption mechanism is immediately initiated. The local computing resource scheduling component terminates the processes of low-priority tasks, releasing core resources such as CPU, memory, and GPU, and allocating them to the current highest priority task for local preemptive computing. If local resources are insufficient, an optimal neighbor node selection algorithm is activated. Based on the remaining resources and network latency indicators in the local network view, the algorithm selects the neighbor node with the most abundant resources and the lowest network latency. The smart data packet is then directly forwarded to this node via a dedicated high-priority communication link without performing any utility value calculations.

[0043] For example, the priority label for the fire emergency anomaly detection task is Level 1, the highest priority. After the priority verification module successfully matches the task, the node resource scheduling component immediately terminates the low-priority task of urban environmental data statistics in the background, freeing up 80% of the CPU and 2GB of memory for local execution of fire data anomaly detection. If local resources are insufficient, the neighboring node with the lowest network latency and the most remaining resources is selected and the intelligent data packets are directly forwarded through a high-priority dedicated communication link.

[0044] Step S300: At the node of the computing path, execute the data processing task corresponding to the computing task description information, and map the result data packets flowing out from the computing network in real time to the corresponding entity status in the city digital twin model.

[0045] Specifically, a city digital twin model is a digital mapping model of a city's physical entities, spaces, and events. It maps the processed result data packets to the corresponding entity states in the model in real time, enabling the city digital twin model to synchronize with the real state of the physical city in real time, supporting business applications such as urban management and emergency response.

[0046] Specifically, after receiving the intelligent data packet, the target node on the computation path launches a lightweight computation sandbox, performs data processing according to the computation task description information, and generates a standardized result data packet. A digital twin model interface adapter component is deployed, which is compatible with the city digital twin platform's API interface specifications, converting the result data packet into data formats such as JSON and GeoJSON that the model can recognize. Based on the location identifiers and entity identifiers in the result data packet, the data is pushed to the corresponding geospatial location and physical entity modules of the city digital twin model via interface calls, updating the model's entity status data. Simultaneously, a real-time rendering module is activated to complete the visual update of the model's status.

[0047] For example, the result data packet of traffic flow processing contains information such as intersection number, number of vehicles, and congestion level. The interface adaptation component converts it into GeoJSON format and pushes it to the traffic entity module of the corresponding intersection in the model through the open API of the digital twin platform, so as to update the visualization of the congestion status of the intersection in real time.

[0048] In one possible implementation, at the nodes of the computing path, a data processing task corresponding to the computing task description information is executed. Step S300 further includes step S310, whereby the node identifies the task identifier to be executed based on the processing step identifier in the computing task description information. Specifically, each heterogeneous computing node locally stores a task identifier mapping table, which stores a one-to-one correspondence between processing step identifier strings and local task identifiers. After receiving a smart data packet, the node calls the data reading component to extract the processing step identifier, matches it in the local task identifier mapping table using a hash lookup algorithm, quickly identifies the corresponding task identifier, and stores the task identifier in the node's task scheduling queue, awaiting subsequent execution.

[0049] For example, the local task identifier mapping table stores the task identifier task_003 corresponding to the target identification code. After the node extracts the processing step identifier as the target identification code, it quickly identifies the task identifier as task_003 through hash lookup and adds it to the task scheduling queue.

[0050] Step S320: Search for the executable module corresponding to the task identifier in the local microtask library. If no match is found, initiate a pull request to the central repository. Specifically, each node builds a local microtask library using a key-value pair storage structure, with the task identifier as the key and the corresponding executable binary module or script file as the value. The node's task scheduling module traverses the task scheduling queue and performs a key-value search in the local microtask library based on the task identifier. If a match is found, the executable module is directly retrieved; if no match is found, the node initiates a network request module and initiates a pull request to the municipal digital twin central repository via HTTPS encryption protocol. The request parameters include the task identifier and node hardware architecture information. After verifying the request information, the central repository pushes the corresponding executable module to the node. The node receives the module, stores it in its local microtask library, and updates its local mapping table.

[0051] For example, if a node needs to execute task_003, it searches its local microtask library but finds no corresponding executable module. It then sends a pull request via HTTPS to the central repository at https: / / twin-city-center.com, carrying task_003 and the ARM64 hardware architecture parameters. The central repository pushes the corresponding ARM architecture executable module, which the node receives and stores in its local microtask library.

[0052] Step S330: The executable module is instantaneously loaded into a lightweight computing sandbox, and the raw perception data from the intelligent data packet is loaded into the sandbox memory space for data processing. Specifically, lightweight container technology is used to build the lightweight computing sandbox, such as a Docker simplified container or a WebAssembly sandbox environment. Each sandbox has a preset independent memory space, file system, and network permissions, isolated from the node's main system. After receiving the executable module, the node's sandbox management module completes the creation of the sandbox instance and the loading of the executable module within 1 second. Then, the raw perception data from the intelligent data packet is read from the node's storage area into the sandbox's dedicated memory space. The executable module is started and performs operations such as data cleaning, feature extraction, target detection, and anomaly detection according to the preset processing logic. After processing, the result data is encapsulated into a result data packet and sent out of the sandbox. At the same time, the current sandbox instance is destroyed, releasing the occupied resources.

[0053] For example, WebAssembly is used as a lightweight computing sandbox, with a default 512MB of dedicated memory and restricted external network access. The sandbox management module quickly creates a sandbox instance, loads the executable module corresponding to task_003, loads the raw concentration data from the smoke detector into the sandbox memory, and performs smoke anomaly detection processing. After processing, an anomaly alarm result data packet is generated, transmitted out of the sandbox, and the instance is immediately destroyed to release memory resources.

[0054] This application's embodiments employ a response to the raw data stream acquired by multi-source sensing devices, generating intelligent data packets that encapsulate the raw sensing data and corresponding computational task description information. These packets are then injected into an in-transit computing network composed of multiple heterogeneous computing nodes. Starting from the entry edge node, each passing heterogeneous computing node dynamically generates a computational path based on the computational task description information and its own real-time load. Corresponding data processing tasks are executed on the nodes corresponding to the computational paths, and the outflowing result data packets are mapped in real-time to the corresponding entity states of the city's digital twin model. These technical means solve the technical problems of rigid computing resource scheduling and difficulty in balancing data processing latency and resource utilization in existing city-level digital twin multi-source sensing data processing. This achieves the technical effect of flexible scheduling of computing resources while balancing low data processing latency and high resource utilization.

[0055] In the above text, refer to Figure 1 A multi-source data processing method for city-level digital twins according to embodiments of the present invention is described in detail. Next, reference will be made to... Figure 2 A multi-source data processing system for city-level digital twins is described according to an embodiment of the present invention.

[0056] The multi-source data processing system for city-level digital twins according to embodiments of the present invention addresses the technical problems of rigid computing resource scheduling and the difficulty in balancing data processing latency and resource utilization in existing city-level digital twin multi-source sensing data processing. It achieves flexible scheduling of computing resources while maintaining low data processing latency and high resource utilization. The multi-source data processing system for city-level digital twins includes: an intelligent data packet generation module 10, a computation path generation module 20, and an entity state mapping module 30.

[0057] The intelligent data packet generation module 10 is used to generate an intelligent data packet that encapsulates the original sensing data and the corresponding computing task description information in response to the raw data stream obtained from the multi-source sensing devices; the computing path generation module 20 is used to inject the intelligent data packet into the in-transit computing network, which is composed of multiple heterogeneous computing nodes. Each heterogeneous computing node along the path, starting from the entry edge node, performs dynamic decision-making based on the computing task description information and its own real-time load to generate a computing path; the entity state mapping module 30 is used to execute data processing tasks corresponding to the computing task description information at the nodes of the computing path, and to map the result data packet flowing out of the in-transit computing network to the corresponding entity state in the city digital twin model in real time.

[0058] The specific configuration of the intelligent data packet generation module 10 is described in detail below: As mentioned above, the intelligent data packet generation module 10 may further include: the computing task description information includes processing step identifiers, the type and scale of computing resources required for the processing steps, and processing priority tags.

[0059] The detailed description of the specific configuration of the computation path generation module 20 is explained as follows: As mentioned above, each heterogeneous computing node along the path starting from the entry edge node performs dynamic decision-making based on the computation task description information and its own real-time load, generating a computation path. The computation path generation module 20 may further include: a task description information parsing unit used to parse the task description information of the smart data packet at the entry edge node, extracting the identifier of the step to be processed and the required resources; a local network view forming unit used by the entry edge node to evaluate its own real-time load and resource availability, and query the status information of neighboring nodes to form a local network view; and an action utility value calculation unit used to calculate the action utility value of local processing, forwarding to each neighboring node, and decomposition into sub-tasks for parallel processing based on the local network view, the identifier of the step to be processed, and the required resources, determine the execution node with the highest utility value, and generate the computation path.

[0060] The ingress edge node assesses its own real-time load and resource availability, and queries the status information of neighboring nodes to form a local network view. The local network view forming unit may further include: the in-transit computing network is deployed with a distributed state synchronization protocol, and the ingress edge node broadcasts its own real-time load and resource availability through the distributed state synchronization protocol, and receives similar information from neighboring nodes to construct the local network view.

[0061] The action utility value calculation unit may further include: a reference index calculation subunit for calculating the action utility value of local processing, forwarding to neighboring nodes, and decomposition into parallel processing of subtasks, including task execution latency, result quality, and node energy consumption; and a subtask parallel processing action utility value calculation subunit for calculating the action utility value of decomposition into parallel processing of subtasks only when the action utility values ​​of local processing and forwarding to neighboring nodes are both in a preset low utility value range. Specifically, based on the pending step identifier in the task description information, the current calculation task is split into multiple independently executable subtasks according to the task dependency relationship, and a sub-data packet is generated for each subtask. The sub-data packets of the multiple subtasks are distributed to multiple downstream nodes, one of which has a convergence node identifier. Multiple sub-paths are determined, and the sum of the utility values ​​of each sub-path is calculated based on the reference index, and the decomposition and synchronization overhead is subtracted to obtain the action utility value of decomposition into parallel processing of subtasks.

[0062] Before calculating the action utility value of local processing, forwarding to each neighbor node, and decomposing into subtasks for parallel processing, the calculation path generation module 20 may further include: a processing priority label checking unit used to check the processing priority label in the calculation task description information at the entry edge node. If it is the highest priority, the calculation of the action utility value is skipped, and the local preemptive calculation is directly entered or forwarded to the neighbor node with the best resources.

[0063] The computation path generation module 20 may further include: each of the plurality of heterogeneous computing nodes is equipped with a lightweight computing sandbox, through which data processing tasks corresponding to the computation task description information are executed.

[0064] The specific configuration of the entity state mapping module 30 is described in detail below: As mentioned above, at the nodes of the computing path, a data processing task corresponding to the computing task description information is executed. The entity state mapping module 30 may further include: a task identifier identification unit for the node to identify the task identifier to be executed based on the processing step identifier in the computing task description information; an executable module search unit for searching for the executable module corresponding to the task identifier in the local micro-task library, and if not found, initiating a pull request to the central repository; and a data processing unit for instantaneously loading the executable module in the lightweight computing sandbox and loading the original perception data in the intelligent data package into the sandbox memory space to perform data processing.

[0065] The multi-source data processing system for city-level digital twins provided in this embodiment of the invention can execute the multi-source data processing method for city-level digital twins provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method.

[0066] Although this application makes various references to certain modules in the system according to the embodiments of this application, any number of different modules can be used and run on user terminals and / or servers. The various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy distinction between each other and are not used to limit the scope of protection of this invention.

[0067] Based on the foregoing embodiments, this application also provides an electronic device. Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention, showing a block diagram of an exemplary electronic device suitable for implementing the embodiments of the present invention. Figure 3The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present invention. This electronic device is in the form of a general-purpose computing device, and its components may include, but are not limited to, an input device 301, a processor 302, a memory 303, and an output device 304. The processor 302 may be one or more; the memory 303 may include a computer-readable medium and at least one program product having a set (at least one) of program modules configured to perform the functions of the embodiments of this application.

[0068] The memory 303 shown in this embodiment of the invention can be any combination of one or more computer-readable media. The computer-readable storage media can be, but is not limited to, infrared, semiconductor systems, devices or components, or any combination thereof, used to store software programs, computer-executable programs and modules, such as the program instructions / modules corresponding to the multi-source data processing method for city-level digital twins in this embodiment of the invention. The processor 302 executes various functional applications and data processing of the computer device by running the software programs, instructions and modules stored in the memory 303, thereby realizing the above-mentioned multi-source data processing method for city-level digital twins.

[0069] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A multi-source data processing method for city-level digital twins, characterized in that: include: In response to the raw data stream acquired from multi-source sensing devices, an intelligent data packet is generated that encapsulates the raw sensing data and the corresponding computing task description information. The intelligent data packet is injected into the in-transit computing network, which consists of multiple heterogeneous computing nodes. Each heterogeneous computing node along the path, starting from the entry edge node, performs dynamic decision-making based on the computing task description information and its own real-time load, generating a computing path, specifically including: Each heterogeneous computing node along the path from the entry edge node generates a computing path by making dynamic decisions based on the computing task description information and the node's own real-time load, including: The task description information of the smart data packet is parsed at the entry edge node to extract the identifier of the step to be processed and the required resources; The ingress edge node assesses its own real-time load and resource availability, and queries the status information of neighboring nodes to form a local network view; Based on the local network view, the identifier of the step to be processed, and the required resources, calculate the action utility value of local processing, forwarding to each neighbor node, and decomposing into subtasks for parallel processing, determine the execution node with the highest utility value, and generate the calculation path; Reference metrics for calculating the action utility value of local processing, forwarding to neighboring nodes, and decomposition into subtasks for parallel processing include task execution latency, result quality, and node energy consumption. Specifically, the action utility value of decomposing into subtasks for parallel processing is calculated only if and only if the action utility values ​​of local processing and forwarding to each neighbor node are both within a preset low utility value range. Based on the pending step identifier in the task description information, the current computing task is split into multiple independently executable subtasks according to the task dependency relationship, and a sub-data packet is generated for each subtask. The sub-data packets of the multiple subtasks are distributed to multiple downstream nodes. One of the multiple downstream nodes has a convergence node identifier. Multiple sub-paths are determined. The sum of the utility values ​​of each sub-path is calculated based on reference indicators, and the decomposition and synchronization overhead is subtracted to obtain the action utility value of decomposing into parallel processing of subtasks. At the nodes of the computing path, data processing tasks corresponding to the computing task description information are executed, and the result data packets flowing out from the computing network in transit are mapped in real time to the corresponding entity status in the city digital twin model.

2. The multi-source data processing method for city-level digital twins as described in claim 1, characterized in that, The computation task description information includes processing step identifiers, the type and scale of computing resources required for the processing steps, and processing priority tags.

3. The multi-source data processing method for city-level digital twins as described in claim 1, characterized in that, The ingress edge node assesses its own real-time load and resource availability, and queries the status information of neighboring nodes to form a local network view, including: The in-transit computing network is deployed with a distributed state synchronization protocol. The entry edge node broadcasts its real-time load and resource availability through the distributed state synchronization protocol and receives similar information from neighboring nodes to construct the local network view.

4. The multi-source data processing method for city-level digital twins as described in claim 1, characterized in that, Before calculating the action utility value of local processing, forwarding to neighboring nodes, and decomposing into subtasks for parallel processing, the following steps are also included: At the entry edge node, check the processing priority label in the computing task description information. If it is the highest priority, skip the action utility value calculation and directly enter the local preemptive computing or forward it to the neighbor node with the best resources.

5. The multi-source data processing method for city-level digital twins as described in claim 1, characterized in that, Each of the multiple heterogeneous computing nodes is equipped with a lightweight computing sandbox, through which data processing tasks corresponding to the computing task description information are executed.

6. The multi-source data processing method for city-level digital twins as described in claim 5, characterized in that, At the nodes of the computation path, data processing tasks corresponding to the computation task description information are executed, including: The node identifies the task identifier to be executed based on the processing step identifier in the computation task description information; Search for the executable module corresponding to the task identifier in the local microtask library. If no match is found, initiate a pull request to the central repository. The executable module is instantaneously loaded into a lightweight computing sandbox, and the raw perception data in the intelligent data package is loaded into the sandbox memory space for data processing.

7. A multi-source data processing system for city-level digital twins, characterized in that: The system is used to implement the multi-source data processing method for city-level digital twins as described in any one of claims 1-6, the system comprising: The intelligent data packet generation module is used to generate an intelligent data packet that encapsulates the raw sensing data and the corresponding computing task description information in response to the raw data stream obtained from the multi-source sensing devices. The computation path generation module is used to inject the intelligent data packet into the in-transit computation network, which consists of multiple heterogeneous computing nodes. Each heterogeneous computing node along the route, starting from the entry edge node, performs dynamic decision-making based on the computation task description information and the node's own real-time load to generate a computation path. The entity state mapping module is used to execute data processing tasks corresponding to the computing task description information at the nodes of the computing path, and to map the result data packets flowing out of the computing network in real time to the corresponding entity states in the city digital twin model.

8. An electronic device, characterized in that, The electronic device includes: Memory, used to store executable instructions; The processor, when executing executable instructions stored in the memory, implements the multi-source data processing method for city-level digital twins as described in any one of claims 1 to 6.

Images