Traffic control method and device based on multi-source data fusion, equipment and medium

Abstract

The embodiment of the invention discloses a traffic control method and device based on multi-source data fusion, equipment and a medium. A specific implementation mode of the method comprises the following steps: acquiring internal traffic flow data and external linkage data in real time; fusing the acquired internal traffic flow data with the external linkage data to obtain a fused data flow; performing flow prediction on the obtained fused data flow to obtain a first prediction result; performing risk prediction on the obtained fused data stream to obtain a second prediction result; based on the obtained first prediction result and the second prediction result, carrying out collaborative decision-making to obtain a structured strategy instruction set; performing task decomposition on the obtained structured strategy instruction set to obtain task information; and controlling each traffic management and control device based on the obtained task information. According to the implementation mode, a feasible core technical scheme is provided for constructing a new-generation intelligent and collaborative urban traffic management system.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the field of computer technology, and more specifically to traffic control methods, apparatus, devices, and media based on multi-source data fusion. Background Technology

[0002] With the increasing demand for intelligent urban traffic management, traffic control systems have evolved from early fixed-time signal control to adaptive control based on real-time sensing (such as SCATS and SCOOT systems). Current mainstream systems collect real-time traffic flow data by deploying detectors such as loop detectors and radar, and use mathematical models to dynamically optimize signal timing at individual intersections or main roads. Some advanced systems are also attempting to integrate more data sources (such as GPS floating cars and video surveillance) to enhance situational awareness.

[0003] However, existing technological solutions still have fundamental limitations in addressing the complex and dynamic challenges of urban traffic. First, these systems generally rely on historical and real-time traffic flow data, making it difficult to effectively integrate event data from external systems such as ticketing, policing, and large-scale event management that reflect dramatic changes in future traffic demand. This results in a lack of predictability in decision-making and an inability to proactively allocate resources for known large-scale events (such as the end of a concert). Second, their optimization cores are mostly based on classical control models or simple prediction algorithms, making it difficult to simultaneously and collaboratively handle the two key objectives of traffic efficiency (flow, congestion) and safety (accident risk). Furthermore, they cannot simulate and optimize collaborative strategies across intersections and control methods (signals, lanes, guidance) in a digital environment. Finally, there is a significant gap between generating strategies and actually changing the physical world: existing architectures lack a standardized, closed-loop execution mechanism to automatically parse, decompose, and drive the coordinated actions of heterogeneous traffic control equipment (such as traffic lights, variable lane signs, and information boards) using unified collaborative strategies. This heavily relies on manual intervention and manual operation of multiple systems, resulting in slow response and poor coordination.

[0004] The information disclosed in this background section is only intended to enhance the understanding of the background of the inventive concept, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0006] Some embodiments of this disclosure propose traffic control methods, apparatuses, electronic devices, and computer-readable media based on multi-source data fusion to address one or more of the technical problems mentioned in the background section above.

[0007] In a first aspect, some embodiments of this disclosure provide a traffic control method based on multi-source data fusion, including: acquiring internal traffic flow data and external linkage data in real time; fusing the acquired internal traffic flow data and external linkage data to obtain a fused data stream; performing traffic flow prediction on the obtained fused data stream to obtain a first prediction result, wherein the obtained first prediction result includes traffic flow prediction values, speed prediction values, and congestion probability prediction values ​​for each node; performing risk prediction on the obtained fused data stream to obtain a second prediction result, wherein the obtained second prediction result includes the accident risk probability for each road segment; performing collaborative decision-making based on the obtained first prediction result and second prediction result to obtain a structured strategy instruction set; performing task decomposition on the obtained structured strategy instruction set to obtain task information for each task; and controlling each traffic control device based on the obtained task information for each task.

[0008] Secondly, some embodiments of this disclosure provide a traffic control device based on multi-source data fusion, comprising: an acquisition unit configured to acquire internal traffic flow data and external linkage data in real time; a fusion unit configured to fuse the acquired internal traffic flow data and external linkage data to obtain a fused data stream; a first prediction unit configured to perform traffic flow prediction on the obtained fused data stream to obtain a first prediction result, wherein the obtained first prediction result includes traffic flow prediction values, speed prediction values, and congestion probability prediction values ​​for each node; a second prediction unit configured to perform risk prediction on the obtained fused data stream to obtain a second prediction result, wherein the obtained second prediction result includes the accident risk probability for each road segment; a decision unit configured to perform collaborative decision-making based on the obtained first prediction result and second prediction result to obtain a set of structured strategy instructions; a decomposition unit configured to decompose the obtained set of structured strategy instructions into tasks to obtain task information; and a control unit configured to control each traffic control device based on the obtained task information.

[0009] Thirdly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any implementation of the first aspect above.

[0010] Fourthly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method described in any of the implementations of the first aspect above.

[0011] Fifthly, some embodiments of this disclosure provide a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the implementations of the first aspect above.

[0012] The above embodiments of the present invention have the following beneficial effects: Through the traffic control method based on multi-source data fusion of the present invention, a complete technical closed loop from data perception, intelligent prediction, collaborative decision-making to automated execution is constructed. This systematically solves the core defects of traditional traffic control systems in terms of predictability, collaboration, and automated execution, thereby significantly improving the operational efficiency, safety level, and overall response capability to emergencies of urban road networks. Specifically, traditional solutions cannot predict the impact of known events due to a single data source, struggle to collaboratively optimize efficiency and safety due to model limitations, and suffer from a disconnect between decision-making and physical control due to the lack of automated links. Based on this, some embodiments of the traffic control method based on multi-source data fusion disclosed herein include: First, real-time acquisition of internal traffic flow data and external linkage data. This step breaks through the closed data boundaries of traditional systems, actively integrating macro-level event information reflecting dramatic changes in future traffic demand, providing the system with the ability to understand the root causes of traffic flow changes, and laying the data foundation for global intelligent decision-making. Second, the acquired internal traffic flow data and external linkage data are fused to obtain a fused data stream. By standardizing, structuring, and spatiotemporally aligning multi-source heterogeneous data, a unified, high-quality data foundation is formed, ensuring the consistency and reliability of subsequent prediction and decision-making model inputs. Next, traffic flow prediction is performed on the obtained fused data stream, yielding the first prediction result. By injecting future event characteristics into the spatiotemporal prediction model, accurate and forward-looking calculations of future road network traffic flow, speed, and congestion probability are achieved, enabling the system to possess the critical time lead required for proactive intervention. Simultaneously, risk prediction is performed on the obtained fused data stream, yielding the second prediction result. Through parallel analysis of historical accident patterns and real-time traffic parameters, an accident risk probability distribution for the future road network is generated, expanding the control objective from a single focus on traffic efficiency optimization to a dual optimization emphasizing both efficiency and safety. Then, based on the obtained first and second prediction results, collaborative decision-making is performed to obtain a structured set of policy instructions. In a digital twin environment integrating microscopic traffic simulation, multi-agent reinforcement learning is used to perform global collaborative simulation and optimization of various control measures such as traffic lights, reversible lanes, and guidance screens. This outputs a global strategy that achieves an optimal balance between efficiency and safety goals and can be executed collaboratively, fundamentally overcoming the problems of localized optimization perspectives and fragmented methods in traditional solutions. Subsequently, the obtained structured strategy instruction set is decomposed into tasks, yielding individual task information. A workflow engine automatically parses and decomposes the macroscopic collaborative strategy into specific, operable tasks for different execution departments and subsystems, achieving a crucial transformation from a unified intelligent strategy to discrete departmental instructions, providing precise input for cross-system collaborative execution. Finally, based on the obtained task information, various traffic control devices are controlled.Through standardized application programming interfaces (APIs), the decomposed control commands are automatically and reliably sent to physical execution devices such as intersection signal controllers, variable lane indicators, and traffic information boards, ultimately achieving a complete mapping and reliable execution from intelligent decision-making in the digital space to collaborative management actions in the physical world. In summary, this invention, by constructing a complete technology chain of "multi-source fusion perception, dual forward-looking prediction, digital twin collaborative decision-making, and automated task decomposition and execution," not only effectively alleviates traffic congestion caused by planned events such as large-scale activities and reduces accident risks, but also achieves a systematic improvement in road network efficiency, safety resilience, and emergency response capabilities through dynamic optimization of global resources and automated cross-departmental collaboration. This provides a feasible core technology solution for building a new generation of intelligent and collaborative urban traffic management systems. Attached Figure Description

[0013] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0014] Figure 1 This is a flowchart of some embodiments of the traffic control method based on multi-source data fusion according to the present disclosure; Figure 2 These are schematic diagrams of some embodiments of a traffic control device based on multi-source data fusion according to this disclosure; Figure 3 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0015] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0016] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0017] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0018] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0019] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0020] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0021] Figure 1 A flowchart 100 is shown, illustrating some embodiments of a traffic control method based on multi-source data fusion according to this disclosure. This traffic control method based on multi-source data fusion includes the following steps: Step 101: Obtain internal traffic flow data and external linkage data in real time.

[0022] In some embodiments, the implementing entity (e.g., a computing device) of the traffic control method based on multi-source data fusion can acquire internal traffic flow data and external linkage data in real time. The acquired internal traffic flow data includes vehicle flow information, vehicle speed information, location information, and traffic light status information. The acquired external linkage data includes information on large-scale events, planned events, and control requirements. The aforementioned internal traffic flow data can be core parameters reflecting the real-time operating status of roads, collected by various sensing devices deployed in the urban road network. Vehicle flow information can be the statistical analysis of the number of vehicles at various detection points or road sections within a specific time interval in a target area (such as the entire city, a certain administrative district, or a specific road segment), used to characterize the traffic load and distribution of the road network. Vehicle speed information can be the average or median value of vehicle speed in the aforementioned area or road segment, used to assess the traffic efficiency of the road network. Location information can be latitude and longitude coordinates, instantaneous speed, and heading angle data periodically reported by floating cars (such as taxis, buses, and ride-hailing vehicles) through a Global Navigation Satellite System (GNSS), used to obtain the continuous trajectory of individual vehicles. Traffic light status information can be real-time control parameters directly obtained from the signal controllers at each intersection, including the current operating phase, the remaining duration of each phase, the signal cycle length, and the current status of each traffic light (such as red, green, and yellow). The aforementioned external linkage data can be planned or event-based information from outside the transportation industry that can significantly impact future traffic demand and control patterns. Information on large-scale events can include the time, location, expected number of participants, and end time of public events such as concerts and sporting events. Planned events can be foreseeable events that will cause significant changes in the spatiotemporal distribution of traffic flow, such as train / flight arrival and departure schedules. Control demand information can be temporary traffic organization or control requirements generated by public security, emergency response, and other departments for specific support tasks. In practice, the aforementioned implementing entities can perform this step by deploying dedicated data acquisition agents and API (Application Programming Interface) gateways. First, a connection is established with fixed detection equipment (such as inductive loop detectors, microwave radar, and video vehicle detectors) covering the city's main road network via a dedicated traffic network or IoT protocol. This allows for real-time acquisition of cross-sectional traffic flow, average vehicle speed, and time occupancy data for each detection point or road segment using polling or streaming methods. This data is then spatially aggregated to form a regional traffic flow view. Second, services provided by floating car data service providers (such as floating car data platforms offered by map service providers like Gaode and Baidu) are accessed via mobile communication networks to receive GNSS positioning and speed data streams periodically reported by their vehicles. Simultaneously, communication with the regional signal control system is established via standard protocols (such as NTCIP) to synchronize the real-time status of signal controllers at each intersection, acquiring all parameters including the aforementioned signal statuses.For external data, the executing entity establishes connections with external platforms such as ticketing systems (e.g., Damai.cn, Maoyan.com), airport / train station operation databases, and public security command systems through an API gateway, in accordance with predetermined data specifications and security protocols, to asynchronously obtain structured data on future events and management needs in a request-response or message subscription model. For example, the implementing entity can obtain aggregated information such as "the current average speed on the main roads in the city's core area is 25 km / h, and the northbound traffic flow is 1200 vehicles / hour" through video vehicle detectors deployed on roads; obtain status details such as "the intersection of Beijing Road and Zhongshan Road is currently in the east-west straight-ahead green light phase, with 15 seconds remaining and a total cycle length of 120 seconds" through the signal control system; obtain JSON format data such as "a concert will be held at the National Stadium tonight at 19:30, with 80,000 tickets sold and an estimated end time of 22:00" from the open interface of a performance ticketing platform; and receive instructions from the local police platform that "due to a large-scale event, the roads surrounding the National Stadium will be under Level 3 security duty starting at 18:00." This multi-dimensional data will serve as the data input source for the entire method.

[0023] Step 102: The acquired internal traffic flow data and external linkage data are fused to obtain a fused data stream.

[0024] In some embodiments, the aforementioned executing entity may fuse the acquired internal traffic flow data with external linkage data to obtain a fused data stream.

[0025] In some optional implementations of certain embodiments, the aforementioned executing entity may fuse the acquired internal traffic flow data with external linkage data through the following steps to obtain a fused data stream: Step one involves standardizing the acquired internal traffic flow data to obtain standardized traffic data. This standardization process includes cleaning, formatting, and spatiotemporally aligning the internal traffic flow data (i.e., traffic flow information, vehicle speed information, location information, and traffic light status information). In practice, firstly, the executing entity can perform quality checks on the traffic flow and speed information, removing outliers within a preset reasonable range (e.g., vehicle speed 0-200 km / h), and filling in short-term gaps caused by communication interruptions using the average or interpolation of data from adjacent time periods. Secondly, the internal traffic flow data from different sources such as inductive loop detectors, radar, video detectors, floating car positioning platforms, and signal controllers can be converted according to a predefined standard format. This standard format includes unified fields such as: road segment / area ID, timestamp, flow rate, speed, occupancy rate, and traffic light phase code. The executing entity converts the field names and units (e.g., converting speed units from meters per second to kilometers per hour) from different data sources to this standard format. Third, the timestamps of all data records are calibrated to a unified network time, and each data point is mapped to a unified road network segment or traffic zone using a Geographic Information System (GIS) based on the location of the detection point or the floating car trajectory point. Finally, the data is aggregated in fixed time windows (e.g., 5 minutes). Through the above operations, a set of cleaned, transformed, and precisely aligned data in time and space, describing the traffic status of each unit of the road network in a unified format, is obtained, which is the aforementioned standardized traffic data. For example, the above-mentioned execution entity takes a record from a video detector, "Camera C01, 2023-10-27 08:03:21, number of vehicles passing through 12, average speed 8.5 m / s", cleans it, converts the speed unit (8.5 m / s ≈ 30.6 km / h), aligns the time to the 08:00-08:05 time window, and maps it to road segment "RS1001", generating a standardized record. This record, along with all other similarly processed records, constitutes standardized traffic data.

[0026] Step two involves structuring the acquired external linkage data to obtain structured event data. This structuring process transforms the external linkage data (i.e., information on large-scale events, planned events, and control requirements) into machine-readable data objects with unified and clearly defined fields. In practice, firstly, the executing entity can define a data model to describe the event. This model specifies a series of standard fields, such as: event ID, event type, event name, location description, geographic coordinates (latitude and longitude), a list of associated road network area IDs, start time, end time, expected impact intensity, and data source. Secondly, for text-formatted external linkage data (such as notifications from a ticketing system), rule matching or keyword extraction techniques are used to extract information such as event type, location, time, and scale from the text and fill them into the corresponding fields of the data model. For data that already has some structure (such as JSON data returned from a database interface), direct mapping and conversion between fields are performed. Third, for the "Location Description" field, a geocoding service is used to convert it into precise latitude and longitude coordinates. Based on these coordinates and a preset influence radius, a spatial query is used to determine the affected, predefined road network areas or traffic zones, and their IDs are entered into the "Associated Road Network Area ID List" field, thereby establishing a connection between the event and the specific road network space. Through the above operations, a set of event records with a unified format, containing precise spatiotemporal attributes and the road network influence range is obtained, which is the aforementioned structured event data. For example, the executing entity receives the text information "Jacky Cheung Concert, December 24, 2023, 19:30, Beijing Workers' Stadium, estimated audience of 40,000" from a ticketing platform. After processing, a structured event record is generated, which includes the event type "large-scale concert", the location coordinates as 116.435 degrees east longitude and 39.929 degrees north latitude, the associated road network areas including "Z003", "Z004", etc., and specific time and intensity information. The set of such records constitutes the structured event data.

[0027] Step three involves performing spatiotemporal correlation processing on the obtained standardized traffic data and structured event data to obtain a fused data stream. This spatiotemporal correlation processing can be described as aligning and stitching the standardized traffic data and structured event data onto a uniformly divided spatiotemporal grid to generate a comprehensive data sequence that combines historical state and known future event information. In practice, firstly, the implementing entity can establish a unified spatiotemporal grid. This grid uses the entire target road network as its spatial scope, pre-dividing it into multiple traffic zones as basic spatial units; it covers the entire time range of historical, current, and future target prediction periods, dividing it into multiple consecutive time slices at fixed intervals (e.g., 15 minutes). Second, for each "time slice-traffic zone" unit in the spatiotemporal grid, feature extraction and splicing operations are performed: from the standardized traffic data mentioned above, statistical features such as average traffic flow and average speed of the traffic zone in the corresponding historical time slice (such as the same working day and time period in the previous week) are extracted to form a traffic feature vector; simultaneously, from the structured event data mentioned above, events whose "associated road network area ID list" contains the traffic zone and whose time attributes (start time, end time) overlap or are adjacent to the current time slice are queried, and features such as the event type code and expected impact intensity (which can be normalized to a scalar value) are extracted to form an event feature vector; if no relevant event is found, the event feature vector is filled with zero values. Subsequently, the obtained traffic feature vector and event feature vector are spliced ​​to form the fused feature vector of the spatiotemporal unit. Third, according to the time slice order, the fused feature vectors of all traffic zones are arranged to form a three-dimensional data array covering the entire road network and spanning multiple time slices in the past, present, and future. Through the above operations, a spatiotemporally gridded data array is obtained, organically combining historical traffic patterns with event information from externally linked data at the feature level; this is the aforementioned fused data stream. The key is that for each unit of a future time slice, its fused feature vector explicitly includes event feature vectors contributed by the aforementioned structured event data, serving as known contextual information for the future state of that unit. For example, for the future time slice unit "Traffic Zone Z005, 2023-12-24 20:00-20:15", its fused feature vector contains two parts: features from standardized traffic data (such as historical traffic flow of 300 vehicles / 15 minutes during the same period) and features from structured event data (such as event type "concert ended", event intensity of 0.8). After these fused feature vectors from all spatiotemporal units are arranged sequentially, they constitute the fused data stream that serves as the core input to the subsequent prediction model.

[0028] Step 103: Perform traffic prediction on the obtained fused data stream to obtain the first prediction result.

[0029] In some embodiments, the aforementioned executing entity may perform traffic prediction on the obtained fused data stream to obtain a first prediction result. The first prediction result includes traffic flow predictions, speed predictions, and congestion probability predictions for each node (e.g., intersections or road segments).

[0030] In some optional implementations of certain embodiments, the aforementioned execution entity may perform traffic prediction on the obtained fused data stream through the following steps to obtain a first prediction result: Step 1: Extract historical features from the obtained fused data stream to obtain a historical traffic feature sequence. This historical feature extraction can be the process of extracting the traffic state features of each node from the fused data stream across multiple consecutive historical time slices prior to the target prediction time. In practice, the executing entity can, for each node in the fused data stream, obtain the fused feature vectors of that node in multiple consecutive historical time slices (e.g., eight consecutive 15-minute time slices) in chronological order, based on a preset historical time window length (e.g., the past two hours). Then, separate the corresponding traffic feature vector components (e.g., historical baseline flow rate, historical baseline speed, etc.) from each fused feature vector. Through these operations, the resulting set of feature sequences arranged in chronological order, reflecting the historical traffic state evolution of each node, constitutes the aforementioned historical traffic feature sequence. For example, for node N001, extract its historical traffic features from time slices T-8 to T-1 (T being the current time), forming a feature sequence with eight time steps. All such sequences for all nodes constitute the historical traffic feature sequence.

[0031] Step two involves real-time feature extraction from the obtained fused data stream to obtain a real-time traffic feature sequence. This real-time feature extraction can be the process of extracting the latest traffic state features of each node from the fused data stream at one or a few recent time slices immediately preceding the target prediction time. In practice, the executing entity can obtain the fused feature vector of each node in the fused data stream at the current time slice and the previous time slice (e.g., T and T-1), and separate its corresponding traffic feature vector components (e.g., recent average traffic flow, real-time speed, etc.). The resulting set of feature sequences reflecting the latest traffic state of each node constitutes the real-time traffic feature sequence. For example, for node N001, its real-time state features at time slices T-1 and T are extracted to form a feature sequence of length 2; such sequences for all nodes constitute the real-time traffic feature sequence.

[0032] Step 3: Extract future event feature vectors from the obtained fused data stream to obtain event feature vectors. This extraction can be a process of extracting the event feature portions contributed by the structured event data associated with each node in the future prediction time slice from the fused data stream obtained in step 102. In practice, the executing entity can obtain the fused feature vector (generated in step 102) for each node in the fused data stream in the future prediction time slice (the next time slice T+1). Then, the event feature vector portion generated by the structured event data mapping generated in step 2 (e.g., event type encoding, expected impact strength coefficient, etc.) is separated from this fused feature vector. Through the above operations, the resulting feature set describing the influence of known events on each node in the future prediction time slice is the event feature vector. For example, for node N001, extract its corresponding feature vector from the structured event data in the future time slice T+1 to obtain a fixed-dimensional event feature vector; such vectors from all nodes constitute the event feature vector.

[0033] Step four involves performing spatiotemporal graph convolution processing on the obtained historical traffic feature sequences, real-time traffic feature sequences, and event feature vectors to obtain spatiotemporal fused features. This spatiotemporal graph convolution processing can be a computation based on a graph neural network model, used to simultaneously capture spatial dependencies and temporal evolution patterns in the traffic network, and to fuse external event features as contextual information. This model uses the road network topology as a graph, where each traffic node (intersection or road segment) is a vertex, and the physical connections or functional associations between nodes (such as upstream / downstream, adjacency relationships) are edges. The structure of the model can include the following components: (1) Input feature organization: For each node, its historical traffic feature sequence (shape [N,T_hist,F_hist], where N is the total number of nodes, T_hist is the historical time step, and F_hist is the historical feature dimension) is concatenated with its real-time traffic feature sequence (shape [N,T_real,F_real], where T_real is the real-time time step and F_real is the real-time feature dimension) in the time dimension or processed by an independent stream. At the same time, the event feature vector of each node (shape [N,F_event], where F_event is the event feature dimension) is mapped to a feature space that matches the spatiotemporal feature sequence through a learnable linear transformation layer or an embedding layer, so as to be injected into the model as a node-level static feature or a time-slice-level enhanced feature. (2) Spatiotemporal graph convolutional module (ST-GCN Module): This module is the core of the model and is usually composed of multiple spatiotemporal graph convolutional blocks (ST-Conv Blocks) stacked together. Each ST-Conv Block can contain the following sub-layers: Temporal Convolutional Layer: Applies one-dimensional convolution (1D-CNN) or gated temporal convolution (Gated TCN) to the feature sequence of each node to capture the local patterns and trends of the node's traffic state over time. Spatial Graph Convolutional Layer: Based on the constructed road network graph structure, performs graph convolution operations on the node features after temporal convolution. This can be achieved through graph convolution with Chebyshev polynomial approximation, graph convolution based on attention mechanisms (such as GAT), or message passing neural networks (MPNN), with the aim of aggregating information from neighboring nodes to model the spatial correlation in the road network.Activation function and normalization: Non-linear activation functions (such as ReLU) and batch normalization or layer normalization are usually used after each convolutional layer to accelerate training and improve model performance. Residual connection: Residual connections may be introduced within each ST-Conv Block or between blocks to alleviate the gradient vanishing problem in deep networks. (3) Feature fusion and readout layer: After processing by multiple ST-Conv Blocks, the model will output a high-dimensional feature representation of each node at the last time step. In order to fuse event features more deeply, the transformed event feature vector can be added element-wise with the spatiotemporal features or concatenated again and then fused through a fully connected layer. Finally, the fused features of each node are mapped to the target output dimension through one or more fully connected layers. During the training phase, the aforementioned spatiotemporal graph convolutional network model uses a fused data stream of historical time periods (including historical traffic features, real-time traffic features, and corresponding event features) as input, and uses actual observed traffic flow, speed, and congestion status (defined according to speed thresholds or service levels) for the same future time period as supervision labels. The model parameters are optimized through backpropagation. Commonly used loss functions include Mean Squared Error Loss (MSE Loss) for regression tasks and Binary Cross-Entropy Loss (BCE Loss) for probabilistic prediction. The overall loss can be a weighted sum of the losses from each task. In practice, the aforementioned execution entity inputs the aforementioned historical traffic feature sequence, real-time traffic feature sequence, and event feature vectors into the pre-trained spatiotemporal graph convolutional network model with the aforementioned structure. The model calculates through forward propagation and outputs a high-dimensional representation of each node after deep spatiotemporal feature extraction and fusion with the event context. Through these operations, the resulting set of high-dimensional feature vectors generated for each node, deeply fusing its own spatiotemporal pattern and the influence of external events, is the aforementioned spatiotemporal fusion feature. For example, the model outputs a 256-dimensional feature vector for node N001. This vector comprehensively encodes its historical patterns, recent state, and future known event information. All such vectors of all nodes constitute spatiotemporal fusion features.

[0034] Step 5: Perform forward prediction processing on the obtained spatiotemporal fusion features to obtain preliminary prediction results. The forward prediction processing can be the process of inputting the spatiotemporal fusion features into a multi-task prediction layer to generate initial versions of traffic flow prediction, speed prediction, and congestion probability prediction values ​​for each node in the future prediction time slice. The specific structure of the multi-task prediction layer can be designed as follows: (1) Input layer: Receives the spatiotemporal fusion features from step 4, with a shape of [N, D], where N is the number of nodes and D is the dimension of the spatiotemporal fusion features. (2) Shared Feature Transformation Layers: Consists of one or more fully connected layers, each typically followed by a nonlinear activation function (such as ReLU) and a possible dropout layer to prevent overfitting. This part is responsible for further abstracting and refining the spatiotemporal fusion features to extract shared high-order features that are useful for multiple prediction tasks. (3) Task-specific Output Heads: These consist of multiple parallel branches, each responsible for a specific prediction task. Common branch structures may include: Traffic flow prediction branch: Typically composed of one or more fully connected layers, with the last layer using a linear activation function (or no activation function) to output a scalar value representing the initial value of the traffic flow prediction for the node in the future prediction time slice (unit: vehicles / hour). Speed ​​prediction branch: Similar in structure to the traffic flow prediction branch, the last layer also typically uses a linear activation function to output a scalar value representing the initial value of the average speed prediction for the node in the future prediction time slice (unit: kilometers / hour). Congestion probability prediction branch: Can consist of one or more fully connected layers, with the last layer using a sigmoid activation function to compress the output to the (0,1) interval, representing the initial value of the probability prediction that the node will experience congestion in the future prediction time slice (which can be defined according to a preset speed or traffic flow threshold). During the training phase of this model, the multi-task prediction layer and the spatiotemporal graph convolutional network in step four are trained end-to-end. The total loss function (L_total) is usually a weighted sum of the loss functions of each task. For example: L_flow = MSE(predicted flow, actual flow) L_speed = MSE(predicted speed, actual speed) L_congestion = BCE(predicted congestion probability, actual congestion label) L_total=α*L_flow+β*L_speed+γ*L_congestion where α, β, and γ are the loss weight coefficients of each task, used to balance the importance and dimensional differences of different tasks.In practice, the aforementioned execution entity inputs the spatiotemporal fusion feature vector of each node into the multi-task prediction layer of the above structure. This layer, through forward propagation, simultaneously and in parallel outputs the initial values ​​of traffic flow prediction, speed prediction, and congestion probability prediction for the node in the future prediction time slice. Through the above operations, the resulting set containing the initial values ​​of future traffic flow prediction, speed prediction, and congestion probability prediction for each node constitutes the preliminary prediction result. For example, for node N001, this step simultaneously outputs three initial scalar values: initial value of traffic flow prediction V_f (e.g., 450 vehicles / 15 minutes), initial value of speed prediction V_s (e.g., 32 km / h), and initial value of congestion probability prediction P_c (e.g., 0.15). These three types of initial values ​​for all nodes constitute the preliminary prediction result.

[0035] Step six involves calibrating the obtained preliminary prediction results to obtain the first prediction result. This calibration process can be a systematic correction of the initial values ​​of traffic flow, speed, and congestion probability predictions in the preliminary prediction results, based on real-time observation feedback. In practice, the executing entity can continuously maintain a rolling time window record of prediction errors. Specifically, for each node, the error (which can be calculated as a difference or ratio) between the corresponding preliminary prediction values ​​and actual observation values ​​of traffic flow and speed over the most recent consecutive historical time slices (e.g., the past 30 minutes) is calculated. When a new preliminary prediction result needs calibration, the recent moving average error of the corresponding indicators for each node is first calculated (e.g., the average ratio of flow error and the average difference of speed error). Then, these moving averages are used to correct the new initial prediction values: for speed, the average of the speed error differences is added to the initial prediction value; for flow, the average of the flow error ratios is multiplied. The initial value of the congestion probability prediction can be adjusted in the same direction according to the calibrated speed trend, or re-estimated using a predefined lookup table. The above operations result in a set of final traffic flow, speed, and congestion probability predictions for each node, corrected by real-time error feedback. This set constitutes the first prediction result. For example, for node N001, if its recent average speed prediction is 5 km / h higher (error difference -5) and its average traffic flow prediction is 2% lower (error ratio 1.02), and the initial prediction is (traffic flow 450, speed 32, probability 0.15), then after calibration, the speed is adjusted to 27 km / h (32-5), the traffic flow is adjusted to 459 (450*1.02), and the congestion probability is adjusted to 0.22 based on the decreasing speed trend. The results of all nodes calibrated in this way constitute the first prediction result.

[0036] Step 104: Perform risk prediction on the obtained fused data stream to obtain the second prediction result.

[0037] In some embodiments, the aforementioned executing entity may perform risk prediction on the obtained fused data stream to obtain a second prediction result. The obtained second prediction result includes the accident risk probability for each road segment. In some optional implementations of certain embodiments, the aforementioned execution entity may perform risk prediction on the obtained fused data stream through the following steps to obtain a second prediction result: Step 1: Extract traffic features from the obtained fused data stream to obtain a traffic feature sequence. This traffic feature extraction can be the process of extracting traffic flow-related features for each road segment from the fused data stream across multiple consecutive historical time slices prior to the target prediction time. In practice, the executing entity can, for each road segment in the fused data stream, obtain the fused feature vector for that road segment across multiple consecutive historical time slices (e.g., four consecutive 15-minute time slices) in chronological order, based on a preset historical time window length (e.g., the past hour). Then, separate the corresponding traffic feature vector components from each fused feature vector and extract traffic-related features, such as traffic value, traffic change rate, and the ratio of traffic to historical data for the same period. Through these operations, the resulting feature sequence, arranged chronologically and reflecting the historical traffic changes of each road segment, constitutes the aforementioned traffic feature sequence. For example, for road segment S001, extract its traffic features from time slices T-4 to T-1 (T being the current time), forming a feature sequence with four time steps. All such sequences for all road segments constitute the traffic feature sequence.

[0038] Step two involves extracting speed features from the obtained fused data stream to obtain a speed feature sequence. This speed feature extraction can be a process of extracting the vehicle speed-related features of each road segment from the fused data stream across multiple consecutive historical time slices prior to the target prediction time. In practice, the executing entity can obtain the fused feature vectors of each road segment in the fused data stream in chronological order across multiple consecutive historical time slices. Then, the corresponding traffic feature vector components are separated from each fused feature vector, and speed-related features such as average speed value, speed standard deviation, and speed change rate are extracted. Through these operations, the resulting feature sequence, arranged chronologically and reflecting the historical speed changes of each road segment, is the aforementioned speed feature sequence. For example, for road segment S001, its speed features are extracted from time slices T-4 to T-1, forming a feature sequence with four time steps. Such sequences for all road segments constitute the speed feature sequence.

[0039] Step 3: Extract volatility features from the obtained fused data stream to obtain a volatility feature sequence. This volatility feature extraction can be the process of extracting the traffic flow volatility features of each road segment from the fused data stream across multiple consecutive historical time slices prior to the target prediction time. In practice, the executing entity can obtain the fused feature vectors for each road segment in the fused data stream in chronological order across multiple consecutive historical time slices. Then, the corresponding traffic feature vector components are separated from each fused feature vector, and features reflecting traffic flow instability, such as vehicle speed variance and flow rate variation coefficient, are extracted. Through these operations, the resulting feature sequence, arranged chronologically and reflecting the historical traffic flow volatility of each road segment, is the aforementioned volatility feature sequence. For example, for road segment S001, its volatility features at time slices T-4 to T-1 are extracted, forming a feature sequence with four time steps. Such sequences for all road segments constitute the volatility feature sequence.

[0040] Step four involves acquiring historical accident data. This historical accident data can be records of accidents that occurred on various road segments within the target road network over a past period (e.g., the past year), obtained from the traffic accident database of the traffic management department. Each accident record may include: the accident location, the time of the accident, the type of accident, the severity of the accident, weather conditions, lighting conditions, and road geometry. In practice, the implementing entity can periodically synchronize or obtain this data in real time from the relevant accident database through a data interface, and then clean and format it for subsequent use.

[0041] Step 5: Extract environmental correlation features from the acquired historical accident data and the fused data stream to obtain environmental risk features. These environmental risk features include historical environmental risk features and real-time environmental risk features. The above-mentioned environmental correlation feature extraction can be seen as the process of associating environmentally relevant factors in historical accident data with current and future environmental states and quantifying them as features. In practice, the implementing entity can perform the following operations: First, based on the aforementioned historical accident data, statistically analyze the frequency or severity of accidents on each road segment under different combinations of environmental conditions (such as weather, lighting, and road type), and construct a quantitative mapping table or risk coefficient model of "environmental conditions-accident risk". For the target prediction period, based on weather forecast information, astronomical time, and the inherent attributes of the road segment, query or calculate the corresponding baseline risk coefficient from this mapping table or model as historical environmental risk features. Second, real-time environmental risk feature extraction: extract the environmental features corresponding to each road segment in the current time slice and future prediction time slice from the aforementioned fused data stream. These features can originate from the portion of the fused data stream that is associated with external linked data, such as real-time weather conditions, real-time lighting conditions, and real-time road conditions (e.g., slippery). These environmental conditions are then encoded or quantified to form real-time environmental risk features. Through the above operations, a comprehensive set of features reflecting the impact of environmental factors on accident risk is obtained, namely the aforementioned environmental risk features. For example, for road segment S001, if the target prediction period is nighttime and rain is forecast, its historical environmental risk feature is "nighttime rainy day risk coefficient 0.15" derived from historical statistics, while its real-time environmental risk features are "Weather: Rain (Code 1), Lighting: Nighttime (Code 2), Road Surface Condition: Slippery (Code 1)".

[0042] Step six involves performing risk inference on the obtained traffic flow feature sequence, speed feature sequence, volatility feature sequence, and environmental risk features to obtain the initial risk probability. This risk inference can be described as inputting the extracted multidimensional features into a risk prediction model to calculate the probability of an accident occurring on each road segment within the future prediction period. This risk prediction model is a machine learning model based on ensemble learning, its core being the combination of multiple simple prediction models (called "base learners") to obtain a more powerful and stable overall model. Before inputting these features into the risk prediction model, the following steps are required: Construct a unified input feature vector for each road segment, called the comprehensive risk feature vector. This vector is generated as follows: First, for the traffic flow feature sequence, speed feature sequence, and volatility feature sequence, calculate their key statistics in the time dimension, such as mean, standard deviation, maximum value, minimum value, and the value of the most recent time slice, to obtain a set of statistical features characterizing the stability and trend of historical traffic conditions. Then, this set of statistical features is concatenated with the above-mentioned environmental risk features (including historical environmental risk coefficients and real-time environmental codes) to form a fixed-dimensional comprehensive risk feature vector, which serves as the input to the model. In this embodiment, the above-mentioned risk prediction model can adopt gradient boosting decision tree as its specific implementation architecture. The structure of the model can include the following components: (1) Base learner: The basic building block of the model is the decision tree. Each decision tree maps the input feature vector to a specific predicted value (i.e., the "tree branch") through a series of judgments based on feature values ​​(i.e., "tree branches"). (2) Integration method (gradient boosting): The model constructs multiple decision trees in a sequential manner. The first tree learns a preliminary prediction model based on the original data. After that, the construction goal of each new tree is to learn and predict the residual (i.e., error) between the prediction result of the previous tree and the true value. Through this iterative "correction of preceding errors", the prediction results of multiple trees are accumulated to form a more accurate final prediction. (3) Probability output: When used for binary classification risk prediction, the outputs of all decision trees are accumulated to obtain a score. To convert this score into a probability, it is input into a sigmoid function for mapping, compressing the continuous scores and mapping them to the (0,1) interval. The result is the initial risk probability of that road segment. During the training phase, the risk prediction model uses a large number of comprehensive risk feature vectors generated from historical time periods as input samples, and uses whether an accident actually occurred on each road segment within the corresponding time period as the supervision label (1 for an accident, 0 for no accident). The training process is carried out by optimizing the binary cross-entropy loss function, which directly measures the difference between the probability distribution predicted by the model and the actual accident label distribution.By employing optimization algorithms such as gradient descent, the structure and parameters of each decision tree in the model are iteratively adjusted to minimize the loss function, enabling the model to learn to identify patterns that increase accident risk from complex feature combinations. In practice, the aforementioned execution entity inputs the comprehensive risk feature vector of each road segment into the pre-trained risk prediction model. The model, through forward computation, outputs the initial probability value of a traffic accident occurring on each road segment within the next predicted time slice (e.g., the next 15 minutes). Through the above operations, the initial accident probability value for each road segment output by the model is the aforementioned initial risk probability. For example, for road segment S001, the model outputs an initial risk probability of 0.08 based on its feature vector.

[0043] Step seven involves performing time smoothing on the obtained initial risk probabilities to obtain the second prediction result. This time smoothing process can be a filtering of the initial risk probability sequence to eliminate random fluctuations and improve the stability of the result. In practice, the executing entity can use a moving average method over time for each road segment. Specifically, the initial risk probability obtained at the current moment is averaged with the initial risk probabilities obtained for that road segment over several consecutive time slices (e.g., the past two time slices) using a simple moving average to obtain a smoothed risk probability value. Through these operations, the more stable accident risk probabilities for each road segment obtained after time smoothing are the second prediction result. For example, the current initial risk probability of road segment S001 is 0.08, and the initial risk probabilities of the past two time slices are 0.05 and 0.06 respectively. After using a simple moving average, the smoothed value is (0.08 + 0.05 + 0.06) / 3 ≈ 0.063. The smoothed risk probabilities of all road segments constitute the second prediction result.

[0044] Step 105: Based on the obtained first and second prediction results, perform collaborative decision-making to obtain a set of structured strategy instructions.

[0045] In some embodiments, the aforementioned executing entity may make collaborative decisions based on the obtained first prediction result and second prediction result to obtain a set of structured strategy instructions.

[0046] In some optional implementations of certain embodiments, the aforementioned execution entity can perform collaborative decision-making based on the obtained first prediction result and second prediction result through the following steps to obtain a structured policy instruction set: Step one involves weighted fusion of the first and second prediction results to obtain a comprehensive traffic situation map. This weighted fusion process involves normalizing and weighting the first prediction result (reflecting traffic efficiency) and the second prediction result (reflecting traffic safety risk) to generate a computable map that simultaneously quantifies the "efficiency" and "safety" status of the road network. In practice, the implementing entity can first normalize the congestion probability prediction for each road segment in the first prediction result and the accident risk probability for the corresponding road segment in the second prediction result, mapping all probability values ​​to a continuous interval of [0, 1]. Next, based on current control strategy preferences (such as ensuring smooth traffic during peak hours or ensuring safety during rain and snow) or preset rules, dynamically determine the efficiency dimension weight α and the safety dimension weight β (satisfying α + β = 1). Then, for each basic calculation unit in the road network (usually a road segment), perform a weighted summation calculation: Comprehensive situation value = α × normalized congestion probability + β × normalized accident risk probability. Finally, the comprehensive situation value of all road segments is bound to their geographic coordinates, and a comprehensive traffic situation map is generated using the Geographic Information System (GIS) rendering module. This map visually represents the severity of the situation through a color gradient (e.g., from green to red). For example, for the road segment "East Section of Beijing West Road," its normalized congestion probability is 0.75, its normalized accident risk probability is 0.40, and α=0.6, β=0.4, then its comprehensive situation value = 0.75×0.6 + 0.40×0.4 = 0.61. This value is mapped to orange-red and rendered and displayed at the corresponding geographic location on the situation map.

[0047] Step two involves constructing a digital twin decision-making environment based on the obtained comprehensive traffic situation map. This digital twin decision-making environment can be based on the initial state described by the comprehensive traffic situation map, creating a virtual environment in a simulation platform that is highly consistent with the real road network in terms of structure, state, and dynamic behavior, for strategy simulation testing. In practice, the executing entity first loads the road network topology file (e.g., .osm format) of the target area from the City Information Model (CIM) database, parsing out all roads, intersections, lanes, and their connections. Next, the comprehensive traffic situation values ​​generated in step one are used as initial traffic state parameters and injected into the simulation attributes of the corresponding road segments (e.g., a lower expected speed can be set for road segments with high situation values). Simultaneously, based on the traffic flow and speed prediction values ​​from the first prediction result, the origin-destination (OD) matrix for future time periods is calculated using a traffic demand generator and converted into a vehicle departure list required for simulation. Finally, all the above data is imported and configured into a microscopic traffic simulation kernel (such as the SUMO simulator) to form a digital twin decision-making environment that is synchronized with the real world in time and space, carries the prediction of traffic flow, and is interactively controllable.

[0048] Step 3: In the constructed digital twin decision-making environment, intelligent agent modeling is performed for each intersection traffic light and each variable lane. This intelligent agent modeling involves abstracting each independently controllable traffic facility into an intelligent agent with autonomous decision-making capabilities, and formally defining its observable states, executable actions, and rules for interacting with the environment. In practice, this executive agent can create a corresponding intelligent agent object for each physical traffic facility. For example, for an intersection traffic light intelligent agent, its state space is defined as a vector including information such as the current signal phase, the duration of each phase, the real-time queue length of each approach lane, and the average speed of adjacent upstream road segments. Its action space is defined as a set of discrete operations including maintaining the current phase, switching to the next phase, extending the current green light by 10 seconds, and initiating early green light activation in a specific direction. For a variable lane intelligent agent, its state space includes the current lane directional arrow state, the traffic flow of the current lane and adjacent lanes, and its action space includes switching the directional arrow to straight, switching to left turn, and switching to no-entry. Each agent embeds a policy network (such as a neural network) to select actions based on its perceived state and shared global situational information (integrated traffic situation map).

[0049] Step four involves collaborative policy exploration for the modeled agents to obtain a candidate policy set. This collaborative policy exploration can be achieved by applying a multi-agent reinforcement learning algorithm, allowing all agents to explore a set of joint action plans that optimize the global objective through trial and error, collaboration, and competition within a digital twin environment. In practice, the executing agents employ a centralized training-distributed execution MARL framework, such as the QMIX algorithm. In each training iteration, the central coordinator collects the states of all agents and outputs action suggestions for each agent based on the joint policy network, collectively forming a joint control policy for the entire road network. This policy defines the phase sequence of all traffic lights and the guidance settings for all reversible lanes within a future decision cycle (e.g., 15 minutes). Through thousands of such simulation exploration iterations, the system generates a large number of different joint control policies, and the set of all these policies constitutes the candidate policy set. After each exploration, the environment calculates a global reward value (e.g., based on a reduction in the average travel time across the entire domain and a decrease in the number of conflict points) and feeds it back to the algorithm to update the policy network parameters and guide the exploration direction.

[0050] Step 5 involves performing micro-level traffic simulation processing on each candidate strategy in the obtained candidate strategy set to obtain simulation results. This micro-level traffic simulation processing can involve loading each strategy scheme in the candidate strategy set as fixed control logic into the digital twin environment, running a complete prediction time-period simulation, and collecting detailed vehicle-level and system-level output data. In practice, the executing agent can iterate through the candidate strategy set. For each candidate strategy: First, the digital twin environment is reset to a unified initial state defined by the integrated traffic situation map. Then, the strategy file of the candidate strategy (containing all agent action sequences) is loaded into the simulation kernel, overriding the dynamic control logic of the environment. Next, the micro-level traffic simulation is started and run until the preset end point of the future time period (e.g., one hour later). After the simulation ends, the simulation kernel outputs raw simulation results data containing time series, typically including: vehicle trajectory files (recording the position and speed of each vehicle per second), traffic light status logs, lane usage statistics, and conflict event records, etc.

[0051] Step 6: Extract performance indicators from the obtained simulation results to obtain execution performance indicators. The above performance indicator extraction can be to calculate and synthesize a series of key performance indicators reflecting the operational efficiency of the traffic system from the original simulation results data. In practice, the above execution entity can read the original simulation results data and execute a series of calculation scripts. Specifically, it can: (1) analyze vehicle trajectory files and calculate the average travel time and total mileage of all vehicles in the entire region; (2) count the total number of vehicles passing through the road network during the entire simulation period; (3) identify the total length and proportion of road segments in a congested state according to the preset congestion threshold (such as speed <20km / h); (4) analyze the traffic light status log and calculate the green light time utilization rate. Finally, combine these calculated indicator values ​​into a multi-dimensional execution performance indicator vector to quantify the effect of the strategy in improving traffic efficiency.

[0052] Step 7: Extract risk indicators from the obtained simulation results to obtain execution risk indicators. Among them, the above risk indicator extraction can be used to analyze and quantify the potential safety risk level in the traffic flow operation process from the original data of the simulation results. In practice, the above execution entity can read the original data of the above simulation results and perform a series of safety analysis calculations. Specifically, it can: (1) apply the post-intrusion time model or time approximation model to analyze the vehicle trajectory file, identify potential conflict events between vehicles, count the total number of conflicts, and further distinguish the number of serious conflicts (such as post-intrusion time less than 1.5 seconds) and general conflicts; (2) calculate the standard deviation or coefficient of variation of vehicle speed in each road segment as a quantitative indicator of traffic flow stability. The greater the fluctuation, the higher the risk; (3) count the frequency and spatial distribution of emergency braking (such as deceleration exceeding a certain threshold) events during the simulation process; (4) combine the accident risk probability map in the second prediction result to analyze the traffic flow changes of high-risk road segments under the candidate strategy and assess the changes in the degree of risk exposure. Finally, combine these calculated safety-related indicator values ​​into a multi-dimensional execution risk indicator vector to quantify the impact of the strategy on traffic safety. For example, simulation analysis shows that a certain candidate strategy leads to 12 serious conflicts across the entire road network, an average road segment speed standard deviation of 8.5 km / h, and a 15% increase in traffic flow on high-risk road segments. These values ​​together constitute the risk profile of the strategy.

[0053] Step eight: Based on the obtained execution performance indicators and execution risk indicators, perform multi-objective evaluation processing on each candidate strategy in the obtained candidate strategy set to obtain a strategy evaluation sequence. This multi-objective evaluation processing can employ a multi-objective decision-making method to comprehensively evaluate and rank the performance of each candidate strategy on the often conflicting objectives of "efficiency" and "safety." In practice, the executing entity can first convert the execution performance indicator vector and execution risk indicator vector corresponding to each candidate strategy into a comprehensive performance score and a comprehensive risk score respectively using a preset aggregation formula (such as weighted summation). Subsequently, a multi-objective optimization algorithm (such as a non-dominated sorting genetic algorithm or Pareto front analysis) is applied to process the (performance score, risk score) pairs of all candidate strategies to screen out the Pareto optimal solution set, i.e., those strategies that cannot improve the performance of one side without harming the performance of the other. Next, within the Pareto optimal solution set, based on pre-defined preference rules (such as prioritizing safety or pursuing maximum overall benefit) or using multi-attribute decision-making methods (such as the TOPSIS method, which calculates the closeness of each strategy to the ideal solution), these strategies are finally ranked, resulting in an ordered strategy evaluation sequence. For example, after system calculation, strategy A (efficiency 85, risk 20), strategy B (efficiency 80, risk 15), and strategy C (efficiency 90, risk 25) are obtained. Through Pareto analysis, strategies A and B are optimal solutions (because C is significantly inferior to A and B in terms of risk). If safety is prioritized, the final ranking is strategy B > strategy A.

[0054] Step nine involves sorting the obtained strategy evaluation sequence to obtain the target strategy sequence. This sorting process can determine the priority of strategy execution based on the results of multi-objective evaluation, forming the final strategy selection scheme. In practice, the implementing entity can directly use the strategy evaluation sequence obtained in step eight as the target strategy sequence. Typically, the strategy ranked first in this sequence is considered the globally optimal collaborative control strategy under the current traffic situation and decision preferences, and will be selected as the default execution scheme. Simultaneously, the system can also retain several top-ranked strategies (such as the top three) in the sequence to form a target strategy sequence, providing commanders with a review option or as a backup plan in case the main strategy fails. For example, if the strategy evaluation sequence is [Strategy B, Strategy A, Strategy D], then the target strategy sequence is this list, where Strategy B is the first execution objective.

[0055] Step 10 involves encoding and encapsulating the obtained target strategy sequence to obtain a structured set of strategy instructions. This encoding and encapsulation process converts all control action decisions contained in the target strategy sequence (especially the preferred strategy) into a standardized, structured set of control instructions that can be recognized and executed by specific traffic control equipment. In practice, the executing entity can first parse the target strategy (e.g., the top-ranked strategy) file, extracting the action instructions and execution time windows for each agent (traffic light, reversible lane). Then, these abstract actions are converted into the instruction format required by the corresponding device hardware or software interface. The specific conversion includes: (1) encoding the phase switching and duration adjustment instructions of traffic lights into control instruction frames containing fields such as signal ID, phase scheme, green ratio, and cycle duration, according to the specifications of traffic control protocols (such as NTCIP); (2) encoding the guidance switching instructions of variable lanes into control instruction frames containing fields such as lane sign controller ID, target arrow graphic code, and switching time; (3) encoding the path guidance or warning information to be published into information publishing instruction frames containing fields such as variable information sign (information board) ID, display content text, display priority, and start and end time. Finally, all control instruction frames for different devices and locations are organized, encapsulated, and packaged according to a unified, machine-readable data exchange format (such as JSON or XML) to generate a complete set of structured strategy instructions. This instruction set, as the final output of the collaborative decision-making process, can be directly called and executed by the downstream workflow engine or device control interface. For example, the final generated set of structured strategy instructions may be a JSON array containing dozens of instruction objects, each of which specifies the target device, execution time, specific operation, and parameters.

[0056] Step 106 involves decomposing the obtained structured strategy instruction set into tasks to obtain individual task information. This task decomposition can be described as parsing, classifying, and encapsulating the unified, structured collaborative strategy instruction set into a series of independent, specific operational tasks that can be assigned to specific execution units (such as signal control systems, information board publishing systems, police terminals, etc.) according to predetermined business rules and the responsibilities of the executing entities (departments or systems). In practice, the executing entities can first parse the structured strategy instruction set, identifying the type of control equipment involved in each instruction (such as traffic lights, variable lane signs, traffic information boards), the unique identifier of the equipment, the specific operational content (such as timing parameters, display content, switching actions), and the planned execution time window. Then, based on the pre-configured "equipment-execution system" mapping relationship and business rules, the instructions are categorized into different execution channels or responsible departments. For example, all instructions targeting intersection signal controllers are categorized as "signal control tasks," and all instructions targeting variable message signs are categorized as "information guidance tasks." Then, for each type of task, the aforementioned executing entity aggregates multiple instructions into one or more batches of task packages based on the logical relationships (such as spatiotemporal dependencies) of its internal instructions and the interface requirements of the execution system. For each task package, it generates task information containing metadata such as task ID, execution system identifier, task instruction list, latest issuance time, and expected feedback mechanism. Finally, all generated task information is organized into a task list or queue, awaiting distribution to the corresponding execution system interface. For example, for the dispersal control of a large event, the structured strategy instruction set might contain 50 instructions; after task decomposition, it might generate a "signal optimization task package" containing 15 signal control instructions sent to the signal control platform, an "information board release task package" containing 10 guidance messages sent to the information board management system, and a "police collaboration task package" containing police deployment suggestions sent to the public security police platform.

[0057] Step 107: Based on the obtained task information, control each traffic control device.

[0058] In some embodiments, the aforementioned executing entity may control various traffic control devices based on the obtained task information.

[0059] In some optional implementations of certain embodiments, the aforementioned executing entity may control various traffic control devices based on the obtained task information through the following steps: The first step is to generate a first control instruction set based on the obtained task information. Each first control instruction in this set corresponds to a traffic signal controller. Generating the first control instruction set involves filtering all task packages belonging to the "signal control task" category from the task information and converting their contained operation instructions for a specific intersection signal controller into a standardized instruction format that the signal controller can directly receive and execute. In practice, the executing entity can traverse all task information and identify task packages identified as "signal control." For each such task package, the list of instructions it contains is read. Each instruction typically includes a unique identifier for the target signal controller (such as an IP address or device number) and structured timing parameters. Next, the executing entity, according to the communication protocol supported by the target signal controller (such as NTCIP, the National Transport Communications Protocol ITS), encapsulates the structured parameters in each instruction into a data packet conforming to the application layer data unit format of that protocol (such as a SPA (signal phase and time message) or a TimingPlan object). All such data packets targeting different signal controllers together constitute the first control instruction set. For example, a command can be parsed from a task packet: control the signal controller at "Intersection A - East Entrance" to execute phase scheme "P02" at 10:00, with a cycle length of 120 seconds and an east-west straight-ahead green light ratio of 0.4. The executing entity encapsulates this into an NTCIP setTimingPlan request data packet, which is a first control instruction.

[0060] The second step involves generating a second control instruction set based on the obtained task information. Each second control instruction in this set corresponds to a specific variable lane indicator. Generating the second control instruction set can be achieved by filtering all task packages belonging to the "variable lane control task" category from the task information and converting their contained control commands, which are specific to the lane indicator, into the instruction format required by the hardware device driver interface. In practice, the executing entity can iterate through all task information and identify task packages identified as "variable lane control." For each such task package, its instruction list is read; each instruction contains the device ID of the target lane indicator and the desired arrow state (e.g., the left turn arrow illuminates). Then, according to the communication protocol provided by the device manufacturer (i.e., the communication format, instruction set, and interaction flow agreed upon by both parties), the executing entity encodes the state command (e.g., "display left turn arrow") and the switching time point into a specific instruction byte stream or message (a string of sequentially arranged binary data used to express a complete command). All such messages constitute the second control instruction set. For example, the instruction requires "lane sign number VL-101 to be switched to a left turn arrow at 10:05", and the executing entity encodes it into a protocol frame: 0xAA (frame header) 0x01 (device address high byte) 0x65 (device address low byte) 0x03 (left turn arrow command) 0x0A 0x05 (time parameter) 0x55 (frame tail).

[0061] The third step involves generating a third set of control instructions based on the obtained task information. Each third control instruction in this set corresponds to a specific traffic information board. Generating this third set of control instructions involves filtering all task packages belonging to the "information guidance task" category from the task information and encapsulating their contained display content and attributes specific to a particular information board into standardized information release instructions. In practice, the executing entity can traverse all task information and identify task packages with the task type identifier "information board release." For each task package, each instruction is read, which includes the target information board number, the text / graphic content to be displayed, font color, scrolling method, priority, and display start and end times. The executing entity then encapsulates this content into a complete release instruction according to the common data interaction format of the information board system (such as an extension of the Ministry of Transport's standard JT / T 808 protocol (road transport vehicle satellite positioning system terminal communication protocol), or XML / JSON format). All such instructions constitute the third set of control instructions. For example, an instruction requires the information board (ID: VMS-005) at K10+200 of the Beijing-Shanghai Expressway to display "Congestion ahead, please detour via G2 Beijing-Shanghai Expressway auxiliary road" from 10:00 to 11:00. The executing entity encapsulates this into a JSON object: {"deviceId": "VMS-005", "content": "Congestion ahead, please detour via G2 auxiliary road", "priority": 1, "startTime": "10:00", "endTime": "11:00"}.

[0062] The fourth step involves parsing and processing each first control instruction in the obtained first control instruction set to obtain the target timing control parameters corresponding to each traffic signal controller. These target timing control parameters include: target phase, green light ratio, and cycle duration. The target phase can be the sequence of right-of-way allocated by the traffic light to one or more traffic flows (or pedestrian flows) in a specific direction within a signal cycle. For example, "Phase One" might control east-west straight-ahead vehicles. The green light ratio is the ratio of the effective green light time of a certain phase to the total cycle duration within a signal cycle; it is a key parameter for measuring the proportion of time that phase has to travel. The cycle duration is the total time required for all phases of the traffic light to run once in a set order. This parsing and processing can be considered as extracting the underlying core parameters used to directly drive changes in the traffic light hardware from the encapsulated first control instructions (protocol data packets). In practice, the executing entity can call the corresponding protocol parsing library for each NTCIP or other protocol data packet in the first control instruction set to decode the key parameter fields carried in the data packet. These fields are extracted and reorganized into a series of target timing control parameters, such as: phaseNumber (target phase number), greenSplit (green ratio), cycleLength (cycle length), and possibly offset (phase difference, used to coordinate the time difference of signal light activation at adjacent intersections). Each traffic signal controller will receive a complete set of parameters corresponding to it.

[0063] The fifth step involves controlling the corresponding traffic light groups of each traffic signal controller based on the obtained target timing control parameters. This control process can be described as converting the target timing control parameters into low-level hardware driver instructions for the signal controller, reliably issuing them, and ultimately changing the physical state of the traffic lights. In practice, the executing entity can first convert the target timing control parameters (such as phase, green ratio, and cycle) into executable phase control instruction words (binary encoded data defining the light color state of each phase at each moment within the cycle) within the signal controller. Then, according to the controller's communication interface (such as Ethernet or serial port), the instruction words are packaged into a final traffic control protocol data packet (such as the NTCIP actuateSignal command). The data packet is then sent to the corresponding traffic signal controller via the network. After receiving and verifying the data packet, the controller writes its contents into its internal phase management register (a high-speed storage unit for storing the timing data of the currently active phase). The timer in the controller (a hardware or software module that generates interrupts or signals at a set frequency) begins timing according to the new parameters set in the register. When the timer reaches the preset time, it outputs a corresponding level signal, driving the output circuit (a power switching circuit that controls the on / off state of high-voltage electricity, such as a relay or a thyristor circuit) to switch its conduction state. This, in turn, controls the on / off state of the traffic lights (such as red, green, and yellow lights) connected to the circuit, thus completing the actual adjustment of the signal timing. For example, based on the new parameters, the controller will precisely switch the east-west traffic lights at the intersection of Beijing Road and Zhongshan Road from red to green at 10:00:00 and maintain this for 45 seconds.

[0064] The sixth step involves parsing each second control instruction in the obtained second control instruction set to obtain the target lane indication status information corresponding to each variable lane indicator. This target lane indication status information includes the target directional arrow status and the switching timing. The target directional arrow status can be the traffic instruction represented by the pattern that the LED beads on the variable lane sign need to illuminate, such as a straight arrow, left-turn arrow, right-turn arrow, or a cross indicating no-entry. The switching timing can be the specific time point or triggering condition for switching from the current display state to the target state. The parsing process can be the process of decoding the display content and switching timing information of the variable lane sign from the second control instruction set (instruction byte stream / message). In practice, the executing entity can perform reverse parsing for each second control instruction according to its communication protocol, extracting the key fields from the instruction frame: targetArrowState (target directional arrow status encoding) and switchTiming (switching timing). This information together constitutes the target lane indication status information for a specific variable lane indicator.

[0065] The seventh step involves driving the corresponding LED display units of each variable lane indicator based on the obtained target lane indication status information. This driving process can be described as converting abstract arrow states and timing information into specific circuit signals that control the on / off state of the LED beads, triggering execution at designated times. In practice, the executing entity (or the variable lane control system) first queries a pre-stored display pattern library (a database storing the on / off states of each LED bead in the LED matrix corresponding to various arrow states) based on the target directional arrow state to find the corresponding LED matrix lighting pattern data. Then, at the specified switching timing point, a display command containing this pattern data is sent to the controller of the target lane indicator via a communication link (such as fiber optic or wireless private network). After receiving the command, the lane indicator controller updates its internal display buffer (a memory area for temporarily storing image data to be displayed) with the pattern data and drives its LED display units (display modules composed of a large number of light-emitting diodes arranged in a matrix) to light up according to the new pattern, thereby physically changing the displayed content of the lane guidance sign. For example, at 10:05 sharp, the variable lane sign above a certain road section will be changed from a "straight arrow" to a "left turn arrow".

[0066] Step 8 involves parsing each third control instruction in the obtained third control instruction set to obtain the target guidance display content corresponding to each traffic information board. This target guidance display content includes: target text, graphical guidance information, and display priority. The target text can be the text information to be displayed on the information board. The graphical guidance information can be simple graphic symbols that accompany the text, used to more intuitively indicate directions, road conditions, or warnings, such as arrows, exclamation marks, and construction sign icons. The display priority is a hierarchical identifier used to determine the display order or duration when multiple pieces of information need to be displayed on the same information board; higher-priority information can interrupt or cover lower-priority information. The parsing process involves extracting the specific content elements and their attributes to be presented on the information board from the third control instruction set (such as JSON / XML instructions). In practice, the executing entity can parse each third control instruction, extracting the content field (target text), the graphicInfo field (graphical guidance information encoding), and the priority field (display priority). This content is organized into a target guidance display content object corresponding to each information board.

[0067] The ninth step involves generating display frame data based on the obtained target-guided display content. This generation of display frame data can be a process of rendering the text and graphic information in the target-guided display content into pixel data or character-encoded data in a specific format recognizable by the information board display screen. In practice, the executing entity can call a rendering program or graphics processing software. For text content, the program converts the text string into dot matrix data (using a two-dimensional array to represent the data of each pixel being lit or extinguished) or character encoding of a specific protocol, based on the information board's screen resolution, supported character set, and font size. For graphical guidance information, the program maps the graphic encoding to preset icon bitmap data (a file format or data block that stores image pixel information). Finally, the text dot matrix data and graphic bitmap data are combined according to a predetermined layout to generate the final display frame data (data units representing a complete image on a screen) that can directly drive the screen pixels.

[0068] Step 10: Based on the display priorities of the obtained target guidance display content, the generated display frame data is sent to the corresponding traffic information boards, and the corresponding traffic information boards are driven to visualize the generated display frame data. The sending and visualization process can be a process of scheduling the sending order according to information priority, reliably transmitting the display frame data to the information boards, and finally displaying it on the screen. In practice, the executing entity can first maintain a sending queue (a data structure that temporarily stores tasks to be processed in sequence), put the display frame data to be sent, along with its target information board ID and priority, into the queue, and schedule the sending in descending order of priority. Next, the display frame data packets are sent to the corresponding traffic information boards via a dedicated communication network. After receiving and verifying the data packets, the controller built into the information board loads them into a display cache (used to temporarily store the received display data for use when the screen refreshes), and immediately or at a preset time drives the display screen to refresh, visually presenting the text and graphic information represented by the frame data (meaning converting the data into light signals perceptible to human vision) to road users. For example, high-priority "accident warning ahead" information will be distributed and displayed on information boards along the route before low-priority "regular road condition information".

[0069] Steps one through ten of this disclosure address the technical problem that "existing traffic control systems, during the execution phase, suffer from low efficiency, error-proneness, and slow response due to the diverse protocols of heterogeneous devices, the fragmented generation and parsing of control commands, and reliance on manual or semi-automatic operation. This also prevents the accurate, reliable, and synchronized implementation of policy intentions." Existing technologies have the following shortcomings in the above aspects: Firstly, control commands for different control devices such as traffic lights, reversible lanes, and information boards typically require operators to manually configure and issue commands on different software platforms, resulting in fragmented processes and poor coordination. Secondly, the diverse device protocols (such as NTCIP and vendor-specific protocols) and reliance on manual experience for command conversion easily lead to configuration errors or compatibility issues. Thirdly, the lack of a standardized and automated closed-loop execution link from command issuance to physical device state changes makes it impossible to verify whether commands are correctly executed, resulting in uncertain response delays. Solving these problems can significantly improve the automation level of intelligent transportation system policy execution, the accuracy of cross-device coordination, and the overall response speed, thereby ensuring that macro-level traffic optimization strategies can be efficiently and reliably transformed into micro-level road traffic commands, maximizing control benefits. To achieve this effect, this disclosure proposes the following steps: First, based on the obtained task information, a first control instruction set is generated. This automatically filters "signal control tasks" from the unified task information and automatically encapsulates their contained strategy parameters into device-recognizable data packets according to standard protocols (such as NTCIP), achieving automated and standardized conversion from platform-independent task descriptions to specific signal controller instructions. This solves the inefficiency and error-proneness caused by manual interpretation of strategies and manual configuration of signal controller parameters, ensuring that a unified timing strategy can be accurately and unambiguously delivered to the target intersection. Second, based on the obtained task information, a second control instruction set is generated. This automatically filters "variable lane control tasks" and, according to the specific lane sign's proprietary communication protocol, compiles lane direction switching commands into precise instruction byte streams (such as protocol frames containing addresses, commands, and timing sequences) in real time, achieving standardized access and driving of heterogeneous lane indication devices. This solves the problem of needing separate manual operations and difficulty in coordination due to different device protocols, ensuring that instructions for dynamic adjustment of lane functions can be accurately and promptly issued. The third step involves generating a third set of control instructions based on the obtained task information. This automatically filters "information board publishing tasks" and encapsulates diverse display attributes such as text, graphics, and priority into unified publishing instructions according to standard data interaction formats (such as JT / T 808 extension or JSON), achieving structured and standardized encapsulation of guiding information. This solves the problems of inconsistent formats and cumbersome manual editing when publishing information to information boards from different manufacturers and models, providing a high-quality data source for subsequent efficient and reliable information rendering and publishing.The fourth step involves parsing and processing each first control instruction in the obtained first control instruction set to obtain the target timing control parameters corresponding to each traffic signal controller. Then, by calling a protocol parsing library to decode standard instruction data packets (such as NTCIP), core control parameters such as phase, green ratio, and cycle are extracted, achieving key data conversion and purification from the communication protocol layer to the control logic layer. This solves the problem of interference from the complexity of equipment protocols to the control logic, providing the signal controller with a clear, explicit, and directly usable basis for driving hardware actions. The fifth step involves controlling each traffic light group corresponding to each traffic signal controller based on the obtained target timing control parameters. Thus, by converting the core parameters into phase control instruction words, packaging them into final protocol data packets, and sending them to the controller to drive its internal registers, timers, and output circuits—a series of automated, hardware-level closed-loop operations—high-precision, high-reliability real-time execution of the signal timing scheme from digital parameters to physical light color states is achieved. This completely replaces the inefficient and unreliable traditional mode that relies on manual on-site intervention or semi-automatic system responses, ensuring the determinism and timeliness of strategy execution. The sixth step involves parsing and processing each second control instruction in the obtained second control instruction set to obtain the target lane indication status information corresponding to each variable lane indicator. Thus, by reverse parsing the device-specific instruction frames, the target arrow status and precise switching timing are decoded, realizing the restoration and clarification of the specific control intent from the device instructions. This solves the problem of potential misunderstandings between the instruction flow and the final action, providing precise input for the next step of directly and accurately driving the display hardware. The seventh step involves driving each LED display unit corresponding to each variable lane indicator based on the obtained target lane indication status information. Thus, by querying the display mode library to obtain the corresponding pattern data, and sending instructions through the communication link at a specified timing, the lane sign controller updates the buffer and illuminates the LED unit, achieving end-to-end automated execution and visualization of lane indication status changes. This ensures that traffic management decisions can be translated into continuous and correct visual instructions visible to drivers on the road in real time and accurately, improving the response speed and reliability of dynamic adjustment of road network lane functions. The eighth step involves parsing and processing each third control instruction in the obtained third control instruction set to obtain the target guidance display content corresponding to each traffic information board. Thus, by parsing standardized release instructions, the text content, graphic encoding, and priority attributes to be displayed are extracted, realizing the deconstruction and preparation of information from "structured data packets" to "renderable content elements and display rules." This provides a precise content blueprint and display strategy for the subsequent generation of the final screen image, solving the problem of mixed information content and display logic, which is not conducive to automated processing. The ninth step generates display frame data based on the obtained target-induced display content.Thus, through rendering programs or graphics processing software, text and graphic content are rendered into specific dot matrix data or bitmap data according to screen specifications, completing the transformation of information from abstract content to pixel-level visual encoding. This ensures that regardless of the model and resolution of the information board, the guidance information can be correctly restored to the preset visual style, guaranteeing the accuracy and visual consistency of information dissemination and solving the automation problem of content adaptation. The tenth step involves, based on the display priorities of each target guidance display content, sending the generated display frame data to the corresponding traffic information boards and driving the corresponding traffic information boards to visualize the generated display frame data. Thus, by maintaining a priority sending queue, intelligently scheduling the sending order, and driving the information board controller to refresh the display through reliable communication, intelligent and reliable distribution and final visual presentation of guidance information from the system to the road terminal are achieved. This ensures that important and urgent information can be released first, and that all information can be delivered and displayed on time and completely, solving the problems of congestion, delay, or loss in the information dissemination process, and enabling the effective communication of road network status and control recommendations to road users. In summary, the first to tenth steps supplemented in this embodiment are closely linked and collaborative, forming a complete, automated, and closed-loop collaborative execution chain from "standardized generation, protocol parsing, and parameter extraction of multi-device instructions" to "hardware driving and state synchronization of traffic lights, variable lanes, and information boards," encompassing "task decomposition, instruction generation, protocol parsing, parameter driving, and physical execution." This not only bridges the "last mile" from unified intelligent strategies to distributed physical device execution but also improves the accuracy, synchronization, and overall efficiency of cross-heterogeneous device collaborative control through standardization and automation. This allows macro-level traffic optimization strategies to be mapped more accurately and quickly to the real road space, enhancing the reliability, responsiveness, and overall management benefits of the next-generation intelligent transportation system's execution layer.

[0070] In some optional implementations of certain embodiments, the aforementioned execution entity can control each traffic light group corresponding to each traffic signal controller based on the obtained target timing control parameters through the following steps: The first step involves performing low-level drive instruction conversion on the aforementioned target timing control parameters to obtain the respective phase control instruction words. This low-level drive instruction conversion can be described as converting descriptive timing parameters (such as phase, green ratio, and period) into binary encoded instructions representing specific phase timing logic that can be directly recognized and executed by the signal controller's internal hardware or firmware. In practice, the executing entity can invoke the corresponding instruction conversion algorithm or lookup table based on the target signal controller's model and hardware specifications. This algorithm takes the target timing control parameters as input, calculates the corresponding light color (red, green, yellow) output state for each phase at each moment (usually measured in milliseconds or seconds) within a complete signal cycle, and encodes this series of timing logic into a binary data block with a specific format, namely the phase control instruction word (a machine-readable instruction set containing the switching timing sequence of all light colors within a complete cycle). For example, for a four-phase controller, if the target period is 120 seconds and the green light times for each phase are 30 seconds, 25 seconds, 28 seconds, and 27 seconds (including the yellow light and all-red time), the conversion algorithm will generate an instruction sequence containing 120 time units (one unit per second). Each unit is encoded by one byte (e.g., 0x01 represents phase 1 green light, 0x02 represents phase 1 yellow light, 0x04 represents phase 2 green light, etc.) to encode the output channel that should be activated at that moment. The binary stream formed by arranging all these bytes in chronological order is a phase control instruction word.

[0071] The second step involves generating corresponding traffic control protocol data packets based on the aforementioned phase control command words. This generation of traffic control protocol data packets can be achieved by encapsulating the phase control command words according to a standardized traffic control communication protocol, adding necessary protocol headers, address information, checksums, etc., to form a complete data message that can be transmitted over the network. In practice, the executing entity can follow standard protocols such as NTCIP 1202 (Traffic Controller Unit Standard Protocol). Specifically, the phase control command words obtained in the first step are used as the application layer data payload (i.e., the actual valid data carried in the message). Then, application layer header information as specified by the protocol is added, such as an object identifier (OID, used to uniquely identify the manipulated data object), indicating that this is a "timing plan" setting command. Next, the transport layer (such as TCP / UDP) and network layer header information are encapsulated, with the destination address field filled with the IP address or device identifier of the corresponding traffic signal controller. Finally, a checksum (such as CRC, a mathematical algorithm used to detect errors after data transmission or storage) is calculated for the entire data packet and appended to the end, forming a complete traffic control protocol data packet that can be processed by the network stack. For example, a UDP packet is generated with the destination port being the default NTCIP port, and the data area contains a setTimingPlan request and an encoded phase command word.

[0072] The third step involves sending the aforementioned traffic control protocol data packets to the corresponding traffic signal controllers. This data packet sending process can reliably transmit the encapsulated protocol data packets to the target hardware device via wired or wireless communication networks. In practice, the executing entity can use a communication server deployed in the control center to call a network socket (a programming interface for network communication) programming interface to establish and maintain TCP connections with each traffic signal controller or directly send UDP datagrams. For each signal controller, the executing entity extracts its target network address from the data packet and sends the data packet to the corresponding industrial Ethernet or dedicated fiber optic network channel via a routing device, ultimately reaching the network interface of the signal controller located at the intersection. The system typically records a transmission log and may enable an application-layer confirmation mechanism to ensure instruction delivery.

[0073] The fourth step involves controlling each traffic signal controller to write to its phase management register in response to the traffic control protocol data packets received. Each traffic signal controller includes a phase management register (a high-speed storage unit located inside the controller that stores currently active phase timing data; its contents directly determine the signal output). The process of controlling the phase management register to write is the process by which the signal controller's internal firmware or operating system, after correctly receiving and parsing the protocol data packets, stores the new phase timing data into a specific hardware register. In practice, after receiving the data packets, the executing entity first performs checksum verification and protocol parsing to extract the valid phase control instruction word. Then, the microprocessor (CPU) or dedicated logic circuit in the controller writes the instruction word to the phase management register via the internal data bus. The write operation may involve directly overwriting the old value, or writing to a buffer register first and then switching the effect at a specific time (such as the end of a cycle).

[0074] The fifth step involves controlling the start of each timer in response to the completion of the write operation in the phase management registers. Each traffic signal controller includes a timer (a hardware or software module that generates interrupts or signals at a set frequency for precise timing). The timer start control can be a process of triggering or resetting the internal hardware timer of the controller after ensuring the new phase program is ready, causing it to begin timing according to the period and phase duration of the new program. In practice, after detecting that the phase management register write is complete and valid, the execution entity sends a start or reset command to the timer. This timer is configured to count down or up according to the minimum time unit (e.g., 1 second) defined by the phase control instruction word, and its count value is directly associated with the time index in the phase instruction word, thereby driving the phase switching logic.

[0075] The sixth step involves acquiring the corresponding level output signals of each timer as they start and run to the preset time point. This acquisition of level output signals can be described as the process by which the timer, during operation, queries the phase control instruction word based on the current count value and generates corresponding digital level signals representing the state of each phase light color. In practice, the execution unit continuously compares the current value of the timer with the time-state mapping table in the phase instruction word. When the timing reaches the preset phase switching time point in the instruction word, the logic unit immediately updates a set of level output signals (digital signals using high and low voltages to represent logic "1" and "0"). For example, this set of signals might be a multi-bit parallel digital signal, where each bit represents the expected state of an output channel (corresponding to a specific traffic light group, such as a green light for east-west traffic) (high level indicates "activated / lit", low level indicates "off / extinguished"). These signals are output to the signal latch before the driver circuit or directly to the output interface.

[0076] Step 7: Based on the collected level output signals, switch the conduction state of each output circuit corresponding to each traffic signal controller to obtain the conduction state information of each output circuit. Switching the conduction state of the output circuit involves using level output signals to control the on / off state of power switching devices (such as relays, solid-state relays, or power transistors), thereby changing the electrical state of the circuit connecting the traffic light group. In practice, the execution unit receives level signals from the logic unit. This drive unit contains multiple independent output circuits (electrical loops connecting the traffic light group, containing switching devices for control), each circuit corresponding to one traffic light group. When a high-level signal is received, the optocoupler (an optocoupler used to achieve electrical isolation between the control side and the high-voltage side) or the drive chip in the corresponding output circuit is triggered, thereby controlling the power switching device (such as a thyristor) to conduct, connecting the 220V AC or 24V DC main circuit. After the circuit is turned on, the drive unit can feed back conduction state information (such as confirming the circuit is powered by detecting the loop current), confirming that the physical circuit is in a power-on ready state. Conversely, a low-level signal commands the circuit to shut down.

[0077] Step 8: Based on the conduction status information of each output circuit, switch the on / off state of each traffic light in each of the aforementioned traffic light groups. Switching the on / off state of the traffic lights involves the output circuit transferring electrical energy to the terminal load (traffic light), causing it to actually light up or turn off, ultimately changing the visual indication to traffic participants. This is the final physical effect of the entire control chain. In practice, the executing entity does not need to operate actively. When the output circuit is on, current flows through the traffic light connected in series (such as an LED light group or a halogen bulb), and the light is lit (on). When the circuit is off, the current is interrupted, and the light turns off (off). Multiple traffic light groups at the intersection coordinate their actions according to this mechanism, thus realizing the physical execution of the timing scheme. For example, when the circuit of the east-west straight-ahead green light group is on, the corresponding green LED light panel lights up, informing drivers that they can proceed.

[0078] Steps one through eight of this disclosure address the technical problem that "in existing traffic signal control systems, the transition from high-level timing parameters generated by intelligent decision-making to the final physical state change of intersection traffic light groups is opaque, reliant on specific vendors' hardware and software, and lacks standardized execution links and reliable feedback, resulting in low policy execution accuracy, poor real-time performance, and difficulty in coordination between different systems." Existing technologies have the following shortcomings in the above aspects: Firstly, the conversion from timing parameters to controller-executable instructions is often encapsulated in vendor-specific software, making the process closed and difficult to seamlessly integrate with third-party intelligent decision-making systems. Secondly, the coupling between instruction issuance, parsing, and hardware driving is loose, lacking a unified timing control and state synchronization mechanism, easily causing execution deviations or delays. Thirdly, the final stage from digital instructions to physical light color switching is usually treated as a "black box," making it impossible to confirm whether the policy is executed accurately and completely. Solving these problems allows for the construction of an end-to-end, standardized, and monitorable closed-loop execution link from software parameters to hardware actions, ensuring that intelligent timing policies from any source can be accurately, reliably, and promptly converted into actual traffic instructions at the intersection. To achieve this effect, this disclosure proposes the following steps: First, perform low-level drive instruction conversion on the aforementioned target timing control parameters to obtain each phase control instruction word. Then, through an instruction conversion algorithm or lookup table, descriptive parameters such as phase, green ratio, and period are converted into machine-readable binary encoded sequences (phase control instruction words) that define the light color status of each phase at each moment. This achieves precise and automated mapping from high-level strategy to low-level hardware timing logic, solving the opacity and inflexibility problems caused by relying on manual experience or closed software for instruction orchestration, and providing a unified and deterministic execution blueprint for any compliant controller. Second, generate corresponding traffic control protocol data packets based on the aforementioned phase control instruction words. Then, following standard protocols such as NTCIP 1202, encapsulate the phase control instruction words into network data packets containing complete information such as target address, object identifier (OID), and checksum. This achieves standardized and structured network encapsulation of execution instructions, solving the interoperability problem caused by different communication protocols of different manufacturers' equipment, ensuring that control instructions can be reliably transmitted in the network as standardized data streams, and laying the foundation for remote and centralized control. The third step involves sending the aforementioned traffic control protocol data packets to the corresponding traffic signal controllers. This, through network socket interfaces and routing devices, reliably and directionally transmits the protocol data packets to the network interface of each target signal controller via industrial Ethernet or dedicated fiber optic networks. This achieves precise and reliable network delivery of control commands from the control center to edge devices, and enhances delivery reliability through logging and acknowledgment mechanisms. It resolves potential issues of command loss, out-of-order delivery, or delays during transmission, ensuring the timeliness of control.The fourth step involves the traffic signal controllers receiving the traffic control protocol data packets and controlling the phase management registers to perform write operations. After verifying the checksum, the signal controllers parse the protocol packets, extract the phase control instruction words, and write them to the critical phase management registers via the internal data bus. This ensures the secure loading and readiness of the new timing program within the controller, converting network instructions into memory data that can be directly accessed by the hardware. This resolves the disconnect between instruction reception and hardware execution preparation, a crucial step in implementing the strategy in the hardware. The fifth step involves the phase management registers completing the write operations and controlling the start of each timer. Upon confirming the new program's readiness, the controller's hardware timers are immediately triggered or reset, allowing them to begin precise timing according to the minimum time unit defined by the new instruction word. This achieves high-precision time base synchronization for the timing cycle execution, resolving phase duration errors caused by inaccurate timing or improper start timing. It serves as the "starting gun" for the strict operation of the entire timing logic. The sixth step involves the timers starting and running to the preset time point and acquiring the corresponding level output signals for each timer. Thus, the timer and logic processing unit work together to query the phase instruction word in real time based on the current count value and generate a set of parallel digital level signals representing the switching status of each phase light color. This achieves precise mapping of the passage of time to multiple concurrent control logic signals, solving the instantaneous decision problem of "when to switch" to "what state to switch to," and providing clear and unambiguous instructions for driving the power circuit. The seventh step involves switching the conduction state of each output circuit corresponding to the aforementioned traffic signal controllers based on the acquired level output signals. Thus, through devices such as optocouplers and driver chips, low-power logic level signals are safely converted into drive signals that control the switching of power switching devices (such as relays and thyristors), thereby connecting or disconnecting the high-voltage main circuit connected to the traffic light group. This achieves safe and reliable energy conversion and isolated drive from low-voltage control signals to high-voltage execution actions, solving the physical barrier problem that logic instructions cannot directly drive high-power loads, acting as a "power amplifier" for the digital world controlling the physical world. The eighth step involves switching the on / off state of each traffic light within each of the aforementioned output circuits, based on the conduction status information of each circuit. Thus, when the main circuit is on, current flows through the traffic lights (LEDs or bulbs), illuminating them; when off, they are extinguished. This ultimately achieves the physical visualization of the timing strategy and the issuance of traffic instructions, representing the final output and goal of the entire technology chain. It ensures that all the aforementioned complex digital processing, network communication, and circuit control are accurately reflected in the orderly change of right-of-way at intersections, directly serving the optimized management of traffic flow.In summary, the first to eighth steps supplemented in this embodiment are progressive and interconnected, collectively constructing a transparent, standardized, and fully automated hardware-level closed-loop control pipeline from "software parameters" to "light color changes." This pipeline covers key aspects such as "instruction compilation, protocol encapsulation, network distribution, register loading, timing triggering, logic mapping, power driving, and physical response," enabling reliable execution of intelligent traffic strategies in the physical world. Therefore, it not only ensures to a certain extent that strategies generated by any advanced timing optimization algorithm can be translated into the intersection reality relatively losslessly, accurately, and promptly, but also provides a relatively solid and reliable execution framework for achieving large-scale, cross-vendor, high-concurrency city-level traffic signal collaborative control through standardized interfaces and processes.

[0079] The above embodiments of the present invention have the following beneficial effects: Through the traffic control method based on multi-source data fusion of the present invention, a complete technical closed loop from data perception, intelligent prediction, collaborative decision-making to automated execution is constructed. This systematically solves the core defects of traditional traffic control systems in terms of predictability, collaboration, and automated execution, thereby significantly improving the operational efficiency, safety level, and overall response capability to emergencies of urban road networks. Specifically, traditional solutions cannot predict the impact of known events due to a single data source, struggle to collaboratively optimize efficiency and safety due to model limitations, and suffer from a disconnect between decision-making and physical control due to the lack of automated links. Based on this, some embodiments of the traffic control method based on multi-source data fusion disclosed herein include: First, real-time acquisition of internal traffic flow data and external linkage data. This step breaks through the closed data boundaries of traditional systems, actively integrating macro-level event information reflecting dramatic changes in future traffic demand, providing the system with the ability to understand the root causes of traffic flow changes, and laying the data foundation for global intelligent decision-making. Second, the acquired internal traffic flow data and external linkage data are fused to obtain a fused data stream. By standardizing, structuring, and spatiotemporally aligning multi-source heterogeneous data, a unified, high-quality data foundation is formed, ensuring the consistency and reliability of subsequent prediction and decision-making model inputs. Next, traffic flow prediction is performed on the obtained fused data stream, yielding the first prediction result. By injecting future event characteristics into the spatiotemporal prediction model, accurate and forward-looking calculations of future road network traffic flow, speed, and congestion probability are achieved, enabling the system to possess the critical time lead required for proactive intervention. Simultaneously, risk prediction is performed on the obtained fused data stream, yielding the second prediction result. Through parallel analysis of historical accident patterns and real-time traffic parameters, an accident risk probability distribution for the future road network is generated, expanding the control objective from a single focus on traffic efficiency optimization to a dual optimization emphasizing both efficiency and safety. Then, based on the obtained first and second prediction results, collaborative decision-making is performed to obtain a structured set of policy instructions. In a digital twin environment integrating microscopic traffic simulation, multi-agent reinforcement learning is used to perform global collaborative simulation and optimization of various control measures such as traffic lights, reversible lanes, and guidance screens. This outputs a global strategy that achieves an optimal balance between efficiency and safety goals and can be executed collaboratively, fundamentally overcoming the problems of localized optimization perspectives and fragmented methods in traditional solutions. Subsequently, the obtained structured strategy instruction set is decomposed into tasks, yielding individual task information. A workflow engine automatically parses and decomposes the macroscopic collaborative strategy into specific, operable tasks for different execution departments and subsystems, achieving a crucial transformation from a unified intelligent strategy to discrete departmental instructions, providing precise input for cross-system collaborative execution. Finally, based on the obtained task information, various traffic control devices are controlled.Through standardized application programming interfaces (APIs), the decomposed control commands are automatically and reliably sent to physical execution devices such as intersection signal controllers, variable lane indicators, and traffic information boards, ultimately achieving a complete mapping and reliable execution from intelligent decision-making in the digital space to collaborative management actions in the physical world. In summary, this invention, by constructing a complete technology chain of "multi-source fusion perception, dual forward-looking prediction, digital twin collaborative decision-making, and automated task decomposition and execution," not only effectively alleviates traffic congestion caused by planned events such as large-scale activities and reduces accident risks, but also achieves a systematic improvement in road network efficiency, safety resilience, and emergency response capabilities through dynamic optimization of global resources and automated cross-departmental collaboration. This provides a feasible core technology solution for building a new generation of intelligent and collaborative urban traffic management systems.

[0080] Further reference Figure 2 As an implementation of the methods shown in the above figures, this disclosure provides some embodiments of a traffic control device based on multi-source data fusion. These device embodiments are similar to... Figure 1 Corresponding to the method embodiments shown, the device can be specifically applied to various electronic devices.

[0081] like Figure 2 As shown, a traffic control device 200 based on multi-source data fusion in some embodiments includes: an acquisition unit 201, a fusion unit 202, a first prediction unit 203, a second prediction unit 204, a decision unit 205, a decomposition unit 206, and a control unit 207. The system comprises the following components: an acquisition unit 201, configured to acquire internal traffic flow data and external linkage data in real time; a fusion unit 202, configured to fuse the acquired internal traffic flow data and external linkage data to obtain a fused data stream; a first prediction unit 203, configured to perform traffic flow prediction on the obtained fused data stream to obtain a first prediction result, wherein the obtained first prediction result includes traffic flow prediction values, speed prediction values, and congestion probability prediction values ​​for each node; a second prediction unit 204, configured to perform risk prediction on the obtained fused data stream to obtain a second prediction result, wherein the obtained second prediction result includes the accident risk probability for each road segment; a decision unit 205, configured to perform collaborative decision-making based on the obtained first and second prediction results to obtain a set of structured strategy instructions; a decomposition unit 206, configured to decompose the obtained set of structured strategy instructions into tasks to obtain task information; and a control unit 207, configured to control each traffic control device based on the obtained task information.

[0082] It is understandable that the units described in the device 200 are related to the reference. Figure 1The steps in the described method correspond to each other. Therefore, the operations, features, and beneficial effects described above for the method also apply to the device 200 and the units contained therein, and will not be repeated here.

[0083] The following is for reference. Figure 3 It shows a schematic diagram of the structure of an electronic device 300 suitable for implementing some embodiments of the present disclosure. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0084] like Figure 3 As shown, the electronic device 300 may include a processing unit 301 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0085] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 3 Each box shown can represent a device or multiple devices as needed.

[0086] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 309, or installed from storage device 308, or installed from ROM 302. When the computer program is executed by processing device 301, it performs the functions defined in the methods of some embodiments of this disclosure.

[0087] It should be noted that, in some embodiments of this disclosure, the computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0088] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0089] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently without being assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: acquire internal traffic flow data and external linkage data in real time; fuse the acquired internal traffic flow data and external linkage data to obtain a fused data stream; perform traffic flow prediction on the obtained fused data stream to obtain a first prediction result, wherein the first prediction result includes traffic flow prediction values, speed prediction values, and congestion probability prediction values ​​for each node; perform risk prediction on the obtained fused data stream to obtain a second prediction result, wherein the second prediction result includes the accident risk probability for each road segment; perform collaborative decision-making based on the obtained first and second prediction results to obtain a structured strategy instruction set; decompose the obtained structured strategy instruction set into tasks to obtain task information; and control various traffic control devices based on the obtained task information.

[0090] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0091] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0092] The units described in some embodiments of this disclosure can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor may be described as including an acquisition unit, a fusion unit, a first prediction unit, a second prediction unit, a decision unit, a decomposition unit, and a control unit. The names of these units do not necessarily limit the specific unit; for example, the acquisition unit may also be described as "a unit that acquires internal traffic flow data and external linkage data in real time."

[0093] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0094] Some embodiments of this disclosure also provide a computer program product, including a computer program that, when executed by a processor, implements any of the above-described traffic control methods based on multi-source data fusion.

[0095] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A traffic control method based on multi-source data fusion, comprising: Real-time acquisition of internal traffic flow data and external linkage data; The acquired internal traffic flow data and external linkage data are fused to obtain a fused data stream; Traffic flow prediction is performed on the obtained fused data stream to obtain the first prediction result, which includes the traffic flow prediction value, speed prediction value and congestion probability prediction value of each node. Risk prediction is performed on the obtained fused data stream to obtain a second prediction result, which includes the accident risk probability of each road segment. Based on the first and second prediction results, collaborative decision-making is carried out to obtain a set of structured strategy instructions; The obtained structured policy instruction set is decomposed into tasks to obtain information about each task; Based on the obtained task information, control is applied to each traffic control device.

2. The method according to claim 1, wherein, The acquired internal traffic flow data includes vehicle flow information, vehicle speed information, location information, and traffic light status information. The acquired external linkage data includes information on large-scale events, planned events, and control requirements.

3. The method according to claim 1, wherein, The process of fusing the acquired internal traffic flow data with external linkage data to obtain a fused data stream includes: The acquired internal traffic flow data is standardized to obtain standardized traffic data; The acquired external linkage data is processed in a structured manner to obtain structured event data; The obtained standardized traffic data and structured event data are subjected to spatiotemporal correlation processing to obtain a fused data stream.

4. The method according to claim 1, wherein, The step of performing traffic prediction on the obtained fused data stream to obtain a first prediction result includes: Historical features are extracted from the obtained fused data stream to obtain a historical traffic feature sequence; Real-time feature extraction is performed on the obtained fused data stream to obtain a real-time traffic feature sequence; The obtained fused data stream is subjected to future event feature vector extraction to obtain event feature vectors; Spatiotemporal graph convolution is performed on the obtained historical traffic feature sequences, real-time traffic feature sequences, and event feature vectors to obtain spatiotemporal fusion features; The obtained spatiotemporal fusion features are subjected to forward prediction processing to obtain preliminary prediction results; The preliminary prediction results are calibrated to obtain the first prediction result.

5. The method according to claim 1, wherein, The process of performing risk prediction on the obtained fused data stream to obtain a second prediction result includes: Traffic feature extraction is performed on the obtained fused data stream to obtain a traffic feature sequence. Velocity features are extracted from the obtained fused data stream to obtain a velocity feature sequence. Volatility features are extracted from the obtained fused data stream to obtain a volatility feature sequence. Obtain historical accident data; Environmental correlation features are extracted from the acquired historical accident data and the obtained fused data stream to obtain environmental risk features, which include historical environmental risk features and real-time environmental risk features. Risk inference is performed on the obtained flow characteristic sequence, velocity characteristic sequence, volatility characteristic sequence and environmental risk characteristics to obtain the initial risk probability; The initial risk probabilities are smoothed over time to obtain the second prediction result.

6. The method according to claim 1, wherein, Based on the obtained first and second prediction results, collaborative decision-making is performed to obtain a set of structured strategy instructions, including: The first and second prediction results are weighted and fused to obtain a comprehensive traffic situation map. Based on the obtained comprehensive traffic situation map, a digital twin decision-making environment is constructed; In the constructed digital twin decision-making environment, intelligent agent modeling is performed on the traffic lights at each intersection and each reversible lane; Explore collaborative strategies for the modeled agents to obtain a set of candidate strategies; Microscopic traffic simulation is performed on each candidate strategy in the obtained candidate strategy set to obtain simulation results; The performance indicators are extracted from the obtained simulation results to obtain the execution performance indicators; Risk indicators are extracted from the obtained simulation results to obtain execution risk indicators; Based on the obtained execution performance indicators and execution risk indicators, a multi-objective evaluation process is performed on each candidate strategy in the obtained candidate strategy set to obtain a strategy evaluation sequence. The obtained policy evaluation sequence is sorted to obtain the target policy sequence; The obtained target policy sequence is encoded and encapsulated to obtain a structured policy instruction set.

7. A traffic control device based on multi-source data fusion, comprising: The acquisition unit is configured to acquire internal traffic flow data and external linkage data in real time. The fusion unit is configured to fuse the acquired internal traffic flow data with external linkage data to obtain a fused data stream; The first prediction unit is configured to perform traffic prediction on the obtained fused data stream to obtain a first prediction result, wherein the obtained first prediction result includes traffic flow prediction value, speed prediction value and congestion probability prediction value of each node. The second prediction unit is configured to perform risk prediction on the obtained fused data stream to obtain a second prediction result, wherein the obtained second prediction result includes the accident risk probability of each road segment. The decision-making unit is configured to make collaborative decisions based on the obtained first and second prediction results to obtain a set of structured strategy instructions; The decomposition unit is configured to decompose the obtained set of structured policy instructions into tasks to obtain information about each task. The control unit is configured to control various traffic control devices based on the obtained task information.

8. An electronic device, comprising: One or more processors; A storage device on which one or more programs are stored; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 6.

9. A computer-readable medium having a computer program stored thereon, wherein, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 6.

Images