Vehicle congestion detection method and system based on multi-source data fusion, equipment and medium

Abstract

The application provides a vehicle congestion detection method and system based on multi-source data fusion, equipment and medium, belonging to the field of vehicle congestion detection. The method comprises the following steps: acquiring visual perception data, vehicle positioning data and terminal service instruction data, and mapping to construct a multi-source fusion object; constructing a dynamic operation mask to verify the legality of the multi-source fusion object; removing functional blocking objects; performing logical conflict judgment on the remaining multi-source fusion objects after verification, and marking objects with physical state of static and service intention indication of driving, idle non-parking or operation timeout retention as abnormal retention nodes; calculating node clustering density and tail reverse spread rate, confirming congestion situation and outputting detection results. The vehicle congestion detection method and system based on multi-source data fusion, equipment and medium provided by the application fuse service instructions and physical perception, and accurately distinguish functional blocking from pathological congestion based on logical conflict.

Description

Technical Field

[0001] This application belongs to the field of vehicle congestion detection technology, and more specifically, it relates to vehicle congestion detection methods, systems, equipment, and media based on multi-source data fusion. Background Technology

[0002] With the explosive growth of modern port logistics throughput, the efficiency of horizontal transportation within port areas and enclosed logistics hubs has become a key factor restricting overall operational efficiency. The operational status of container trucks, automated guided vehicles (AGVs), and other transport vehicles within the port area, operating in a high-density mixed road network, directly affects the terminal's dispatch response capability and the continuity of the operational chain. Unlike open urban road traffic, traffic flow within ports has strong task-driven characteristics and tidal effects. Vehicle trajectories are highly coupled with the production activities of operational nodes such as quay cranes, storage yards, and gates. This unique production environment makes port roads not only carriers of vehicle traffic but also often the direct sites of production operations. Therefore, accurately monitoring traffic operation status in complex scenarios where operational and traffic spaces highly overlap is the foundation for achieving intelligent port management.

[0003] In existing technologies, location-based trajectory analysis or regional clustering methods are commonly used to monitor traffic congestion or node delays. For example, Chinese invention patent authorization announcement number CN113822513B, entitled "A Port Congestion Monitoring Method Based on Automatic Anchorage and Berth Identification Algorithm," describes a technical solution that obtains dynamic location reports of objects, uses density clustering algorithms to perform spatial analysis of berths, thereby distinguishing between waiting areas (anchorages) and operating areas (berths), and calculates congestion indicators based on the duration of object stay in the waiting area. The core logic of this method lies in using the physical isolation of geographic space to distinguish between the "waiting state" and "operating state" of objects. That is, stationary positions within a specific queuing area are considered congestion or delays, while stationary positions within the operating area are considered normal production. This logic has good applicability in seaside vessel scheduling scenarios.

[0004] However, the aforementioned existing technologies have significant technical shortcomings when applied to port landside vehicle congestion detection. The main reason is that there is no clear physical separation between "anchorage" and "berth" in the port's collection and distribution system, making it difficult for monitoring methods that rely solely on physical sensing data to define the essential difference between functional blockage and pathological congestion. Specifically, in scenarios such as quay crane loading and unloading, weighbridge weighing, or gate inspection, vehicles must remain stationary or move at extremely low speeds on the road for extended periods to facilitate production operations. This physical "stationary" state is a necessary element of production operations (i.e., functional blockage). If existing technologies rely on geofencing or speed thresholds for discrimination, these normal productive queuing behaviors can be misjudged as severe traffic congestion events due to vehicles remaining stationary for extended periods at zero speed, leading to numerous false alarms. Conversely, if the monitoring sensitivity of the operational area is simply relaxed to avoid false alarms, the system struggles to identify abnormal targets from the massive number of normally parked vehicles when vehicles actually break down, lock up, or experience non-productive congestion due to scheduling conflicts (i.e., pathological congestion) in the operational lanes, resulting in missed reports or delayed responses to congestion events. This strong coupling between production operation logic and traffic flow logic in the spatiotemporal dimensions prevents existing technologies from discerning the true semantics of vehicle congestion through the apparent movement of vehicles in a single physical space dimension, thus hindering the construction of an accurate congestion discrimination mechanism that meets the actual production needs of ports. Summary of the Invention

[0005] The purpose of this application is to provide a vehicle congestion detection method, system, device, and medium based on multi-source data fusion, which integrates business commands and physical perception, and accurately distinguishes between functional blockage and pathological congestion based on logical conflicts.

[0006] A first aspect of this application provides a vehicle congestion detection method based on multi-source data fusion, comprising: The system acquires visual perception data collected by port area monitoring equipment, vehicle positioning data provided by vehicle self-positioning equipment, and terminal business instruction data issued by the terminal operating system. The system then maps the visual perception data, vehicle positioning data, and terminal business instruction data to a unified benchmark to construct a multi-source fusion object that combines physical state and business intent. A dynamic operation mask is constructed based on the real-time status of the operating equipment in the terminal business instruction data. The legality of the multi-source fusion object is verified by the dynamic operation mask: functional obstruction objects that fall into the operation coverage area and whose static duration does not exceed the preset exemption threshold are removed. For the remaining multi-source fusion objects after verification, perform logical conflict judgment between physical state and business intent, and mark objects whose physical state is stationary and whose business intent is driving, idle non-stopping or operation timeout as abnormal lingering nodes. Based on the spatiotemporal distribution of the abnormally delayed nodes, the node cluster density and the tail-end backward propagation rate are calculated. When the node cluster density exceeds a preset clustering threshold and the tail-end backward propagation rate exceeds a preset alarm threshold or exhibits a static deadlock state, the congestion situation is confirmed and the detection results are output.

[0007] In one possible implementation, mapping the visual perception data, vehicle positioning data, and terminal business instruction data to a unified benchmark to construct a multi-source fusion object that combines physical state and business intent includes: The visual perception data is converted into geographic coordinates, and the spatial distance between the geographic coordinates and the vehicle positioning data is calculated. When the spatial distance is less than a preset identity threshold, an identity binding relationship is established between the visual target and the positioning target, and the positioning identifier is extracted; The task attributes in the terminal business instruction data are matched with the location identifier, and the task attributes are injected into the identity binding relationship to generate the multi-source fusion object.

[0008] In another possible implementation, constructing a dynamic operation mask based on the real-time status of the operating equipment in the terminal business instruction data includes: The terminal business instruction data is parsed to obtain the equipment type and real-time coordinates, and the corresponding operating radius is matched to construct a dynamic spatial envelope. Extract the operation instruction type from the terminal business instruction data to determine the standard operation duration, and calculate the preset exemption threshold using a preset leniency coefficient; Generate the dynamic job mask that covers the dynamic spatial envelope and whose effective time period is limited by the preset exemption threshold.

[0009] In another possible implementation, the step of performing a logical conflict determination between the physical state and business intent on the remaining multi-source fusion objects after verification includes: If the instantaneous velocity of the remaining multi-source fusion object remains below a preset stationary velocity threshold for a preset continuous monitoring period, it is determined to be in a physically stationary state. The terminal business instruction data is analyzed. If the task status is driving, or the task status is idle and located in a non-parking area, or the task status is in operation but the stationary time has exceeded the preset exemption threshold, it is defined as a non-stationary business intention. When the physical static state and the non-static business intent are simultaneously satisfied, the corresponding multi-source fusion object is marked as the abnormal lingering node.

[0010] In another possible implementation, the calculation of node cluster density and tail-back propagation rate based on the spatiotemporal distribution of the abnormally loitering nodes includes: The distribution density of the abnormally delayed nodes in a preset neighborhood is calculated as the node cluster density. When the density exceeds a preset clustering threshold, an abnormal congestion cluster is generated. The displacement of the tail coordinates of the abnormal congestion cluster within a preset time slice is tracked to construct the tail displacement vector; If the tail displacement vector is reversed and its magnitude is greater than the preset spread threshold, or if the tail displacement vector magnitude shows to be stationary but the node clustering density of the abnormal congestion cluster remains higher than the preset clustering threshold within a preset monitoring period, the congestion situation is confirmed.

[0011] In another possible implementation, after confirming the congestion situation, closed-loop feedback control is performed, including: Based on the spatial location of the abnormal congestion cluster, the congested road segment is determined, and an alarm command containing the congested road segment identifier is sent to the dock operating system to trigger an increase in the path planning weight of the congested road segment. Continuously monitor the node cluster density of the abnormal congestion cluster; In response to the node cluster density being lower than the preset clustering threshold, the dock operating system is instructed to restore the path planning weights.

[0012] Another possible implementation also includes performing environment-adaptive degradation: Monitor the confidence level of the visual perception data; if it is lower than a preset validity threshold, activate the downgraded detection mode. In the degraded detection mode, the logical conflict determination is made only based on the vehicle positioning data and the terminal business instruction data; Specifically, when performing the physical static state determination in the logical conflict determination, the preset drift suppression time increment is used to increase the determination of the duration threshold required for the instantaneous speed to remain below the preset static speed threshold.

[0013] A second aspect of this application provides a vehicle congestion detection system based on multi-source data fusion, comprising: The multi-source fusion mapping module is configured to acquire visual perception data, vehicle positioning data, and terminal business instruction data, and map the visual perception data, vehicle positioning data, and terminal business instruction data to a unified benchmark to construct a multi-source fusion object that combines physical state and business intent. The dynamic mask filtering module is configured to construct a dynamic operation mask based on the real-time status of the operating equipment in the terminal business instruction data, and use the dynamic operation mask to perform legality verification on the multi-source fusion object, and remove functional blocking objects that fall within the operation coverage area and whose static duration does not exceed the preset exemption threshold. The logical conflict verification module is configured to perform logical conflict judgment between physical state and business intent on the remaining multi-source fusion objects after verification, and mark objects whose physical state is stationary and whose business intent is driving, idle non-stop, or operation timeout as abnormal lingering nodes. The congestion status confirmation module is configured to calculate the node cluster density and the tail-end back-spreading rate based on the spatiotemporal distribution of the abnormally delayed nodes. When the node cluster density exceeds a preset clustering threshold and the tail-end back-spreading rate exceeds a preset alarm threshold or exhibits a static deadlock state, the congestion status is confirmed and the detection results are output.

[0014] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the above-described vehicle congestion detection method based on multi-source data fusion.

[0015] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the vehicle congestion detection method based on multi-source data fusion described above.

[0016] The beneficial effects of the vehicle congestion detection method, system, device, and medium based on multi-source data fusion provided in this application are as follows: 1. This application effectively solves the core problem of misjudging and missing vehicle congestion in enclosed operation scenarios such as ports due to the high overlap between production and traffic spaces. By deeply integrating vehicle physical perception data with terminal business instruction data, and pre-eliminating functionally stationary vehicles caused by normal production processes such as loading, unloading, and weighing based on a dynamic operation mask, it accurately identifies abnormal lingering nodes from the remaining objects whose physical state and business intent logically conflict. This penetrates the appearance of stationary vehicles, fundamentally distinguishing between necessary production delays and abnormal pathological congestion, significantly improving the accuracy and practicality of congestion detection.

[0017] 2. This application achieves closed-loop management from congestion perception to proactive control, enhancing the system's intervention timeliness and overall traffic efficiency. After confirming a congestion situation, the system automatically sends an alarm command containing specific road segment information to the terminal operating system, triggering a dynamic increase in the route planning weights of the congested road segments. This guides subsequent vehicles to detour, suppressing the spread of congestion at its source. The weights are automatically restored after the congestion dissipates, ensuring a balanced road network load. This linkage mechanism between detection and scheduling upgrades traditional passive monitoring to a proactive process optimization step.

[0018] 3. This application demonstrates excellent environmental adaptability and system robustness, ensuring the continuity of the detection function under complex operating conditions. By monitoring the confidence level of visual perception data, in harsh environments such as heavy rain and fog that degrade image quality, a degraded detection mode can be automatically activated, relying instead on more stable positioning and operational data for core judgments, and adjusting the judgment parameters to suppress data drift interference. This design reduces dependence on a single data source, enabling the system to operate stably and reliably in diverse port environments. Attached Figure Description

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

[0020] Figure 1 A flowchart illustrating a vehicle congestion detection method based on multi-source data fusion provided in an embodiment of this application; Figure 2 A structural block diagram of a vehicle congestion detection system based on multi-source data fusion provided in an embodiment of this application; Figure 3 This is a schematic block diagram of an electronic device provided in an embodiment of this application.

[0021] Reference numerals: 201, Multi-source fusion mapping module; 202, Dynamic mask filtering module; 203, Logical conflict verification module; 204, Congestion status verification module; 300, Electronic device; 301, Processor; 302, Input device; 303, Output device; 304, Memory; 305, Communication bus. Detailed Implementation

[0022] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0023] It is understood that in the embodiments of this application, data such as user information are involved. When the embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with relevant laws, regulations and standards.

[0024] It should be noted that the terms "first," "second," etc., used in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in sequences other than those illustrated or described herein.

[0025] Existing technologies have significant technical limitations when applied to port landside vehicle congestion detection. The main reason is that there is no clear physical separation between "anchorage" and "berth" in the port's collection and distribution system, making it difficult for monitoring methods that rely solely on physical sensing data to define the essential difference between functional blockage and pathological congestion. Specifically, in scenarios such as quay crane loading and unloading, weighbridge weighing, or gate inspection, vehicles must remain stationary or move at extremely low speeds on the road for extended periods to facilitate production operations. This physical "stationary" state is a necessary element of production operations (i.e., functional blockage). If existing technologies rely on geofencing or speed thresholds for discrimination, these normal productive queuing behaviors can be misjudged as severe traffic congestion events due to vehicles remaining stationary for extended periods at zero speed, leading to numerous false alarms. Conversely, if the monitoring sensitivity of the operational area is simply relaxed to avoid false alarms, the system struggles to identify abnormal targets from the massive number of normally parked vehicles when vehicles actually break down, lock up, or experience non-productive congestion due to scheduling conflicts (i.e., pathological congestion) in the operational lanes, resulting in missed reports or delayed responses to congestion events. This strong coupling between production operation logic and traffic flow logic in the spatiotemporal dimensions prevents existing technologies from discerning the true semantics of vehicle congestion through the apparent movement of vehicles in a single physical space dimension, thus hindering the construction of an accurate congestion discrimination mechanism that meets the actual production needs of ports.

[0026] To address the aforementioned technical issues, this application provides a vehicle congestion detection method based on multi-source data fusion, which integrates business commands and physical perception to accurately distinguish between functional blockages and pathological congestion based on logical conflicts.

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the following description will be provided in conjunction with the accompanying drawings and specific embodiments.

[0028] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating a vehicle congestion detection method based on multi-source data fusion according to an embodiment of this application. The vehicle congestion detection method based on multi-source data fusion provided in this embodiment can be executed by a vehicle congestion detection system based on multi-source data fusion. The method may include: S1 constructs a multi-source fusion object that combines physical state and business intent.

[0029] The core of this step is to achieve deep integration of three types of data—visual perception, vehicle positioning, and terminal business instructions—through a unified benchmark. This breaks the limitation that a single data source can only capture physical appearances, allowing the system to simultaneously understand the "state" of a vehicle and "what task it should perform," thus laying a solid data foundation for accurately distinguishing between functional blockages and pathological congestion.

[0030] Geographic coordinate transformation of S11 visual perception data.

[0031] The system collects visual perception data output from the port area monitoring equipment in real time. This data is initially expressed in pixel coordinates. Presentation format. To achieve spatial alignment with vehicle positioning data, the pixel coordinates of the two-dimensional image plane need to be mapped to the geographic coordinates of the two-dimensional road surface plane using the principle of perspective transformation.

[0032] First, select at least four non-collinear feature points (such as intersections of road markings, corners of equipment bases, etc.) in the video image as calibration references, and record the pixel coordinates of each feature point. and the corresponding GIS map's actual geographic coordinates .

[0033] Establishing a pixel coordinate system to a geographic coordinate system homography matrix The matrix The geometric transformation relationship of camera imaging is encapsulated, and its physical meaning is shown in the following formula:

[0034] The physical meaning of each element in the matrix is ​​as follows: (Rotation and scaling parameters): These mainly characterize the rotation angle and scale ratio of the image plane relative to the geographic plane, reflecting the influence of the camera's shooting position and focal length. (Translation parameter): Characterizes the spatial displacement of the origin of the world coordinate system relative to the center of the image; (Perspective projection parameters): Used to correct perspective distortion (i.e., trapezoidal distortion) caused by shooting angle, where objects appear larger when closer and smaller when farther away. (Normalization factor): Usually set to 1, used to unify the scale benchmark.

[0035] Constructing a mapping equation using homogeneous coordinates:

[0036] The matrix is ​​solved by minimizing the projection error using the least squares method. The parameters. After obtaining the calibrated matrix. Then, the pixel coordinates of any visual target are... Substituting into the above equation and calculating using homogeneous coordinate normalization, we obtain the transformed geographic coordinates. :

[0037]

[0038] Final geographic coordinates The unit is set to meters (m) to ensure consistency with the unit of subsequent vehicle positioning data, providing a unified dimensional basis for spatial distance calculation.

[0039] S12 Spatial distance calculation between visual target and localization target.

[0040] The system synchronously collects positioning data output from the GNSS positioning modules of all vehicles within the port area, which includes latitude and longitude information. First, using a GIS coordinate transformation tool, the latitude and longitude information of the location data is converted into planar geographic coordinates. The conversion process must strictly follow the same projection parameters and coordinate origin as the visual perception data in step S11 to ensure that the two types of data are on the same spatial reference plane.

[0041] Based on this, spatial correlation calculations are performed between visual targets and localized targets.

[0042] Visual target definition: refers to the target with independent geographic coordinates identified by the visual algorithm in step S11. The system identifies physical objects (e.g., a container truck turning left or a stationary automated guided vehicle) in the surveillance footage. At this point, the system only knows their physical location and has not yet confirmed their vehicle ID.

[0043] Distance calculation logic: Since multiple visual targets and multiple localized targets exist simultaneously in a port scenario, the system needs to calculate the spatial deviation between the "observed position" and the "reported position." This involves calculating the coordinates of each visual target. Iterate through the coordinates of all candidate localization targets received at the current moment. Calculate the Euclidean distance between the two respectively. :

[0044] This distance This characterizes the physical spatial proximity between the visually perceived vehicle position and the GNSS-reported vehicle position. The system constructs a distance matrix using the above calculations. This will serve as the core quantitative basis for determining whether two heterogeneous data sources point to the same physical vehicle (i.e., identity binding) in step S13.

[0045] S13 Identity Binding and Vehicle Unique Identifier Extraction.

[0046] The preset identity threshold is set at 5m. This value is determined in full consideration of the actual needs of port operation scenarios: the normal width of port vehicles is between 2.5m and 3m, the typical error range of GNSS positioning is ±1m, and the pixel coordinate transformation error of visual recognition is about ±0.8m. Taking into account the lateral offset margin when vehicles are operating, the threshold of 5m can ensure accurate matching of different data sources for the same vehicle, and can also effectively avoid misbinding of data sources for different vehicles, thus balancing matching accuracy and fault tolerance.

[0047] When the calculated spatial distance When the distance is less than 5 meters, the system determines that the corresponding visual target and the positioning target are the same vehicle, and then establishes an identity binding relationship between the two to achieve complementary fusion of physical state data—visual data can provide detailed information such as vehicle appearance and outline, while positioning data can provide precise spatial location and motion parameters. A unique vehicle identifier is extracted from the vehicle positioning data. This identifier uses a uniformly assigned coding format within the port area (e.g., "TRK-2024001"), possessing global uniqueness, and providing a precise association key for subsequent association with terminal business instruction data.

[0048] S14 Business Attribute Matching and Multi-Source Fusion Object Generation.

[0049] The system obtains terminal business instruction data from the terminal operating system in real time through a standardized API interface. This interface ensures the stability and real-time nature of data transmission. The obtained data includes core fields such as vehicle unique identifier, task type, task status, geographical coordinates of the target work point, and task issuance time, comprehensively reflecting the vehicle's business execution intent.

[0050] Using the vehicle's unique identifier as the association key, the physical status data bound to the identity is precisely matched with the terminal's business instruction data, ensuring that each set of physical status data corresponds to a unique business attribute. The matched task attributes are injected into the identity binding relationship to generate a complete multi-source fusion object. This object simultaneously contains the vehicle's physical status information (real-time geographic coordinates, instantaneous speed) and business intent information (task type, task status, target work point), achieving semantic-level fusion of physical perception and business instructions.

[0051] This fusion approach addresses the core data blind spot of traditional technologies, which can only sense whether a vehicle is "stationary" but cannot know "why it is stationary." It upgrades the system from a mere "physical observer" to a "business understander," providing crucial data support for subsequent judgment of the nature of congestion based on logical conflicts.

[0052] S2 constructs a dynamic job mask and performs a validity check.

[0053] This step follows the multi-source fusion object generated in S1. Targeting the core scenario where port operation space and passage space highly overlap, it constructs a dynamically adaptable operation mask through terminal business instruction data. This accurately filters and eliminates functional obstruction objects caused by normal production operations, thus avoiding the problem of misjudging congestion due to static operations from the source. This design breaks through the limitations of existing technologies that rely on fixed geofences and cannot adapt to dynamic port operations.

[0054] S21 Dynamic Spatial Envelope Construction.

[0055] The system parses terminal business instruction data and extracts information on currently executing equipment, including equipment type and real-time geographic coordinates. Equipment types cover mainstream port operation equipment such as quay cranes, gantry cranes, weighbridges, and gate equipment. Real-time geographic coordinates are consistent with the unified geographic coordinate system in S1, with units in meters, ensuring the accuracy of spatial location correlation.

[0056] The system matches a specific operating radius based on the operational characteristics and safety operating procedures of different equipment. The operating radius for quay cranes is set at 30m, based on the quay crane's maximum coverage of 25m, combined with a 5m safety buffer distance required for vehicle parking, ensuring complete coverage of the work area while avoiding the risk of collisions between equipment and vehicles. The operating radius for gantry cranes is set at 20m, referencing the typical 18m span of gantry cranes, with a 2m operating passage space reserved to accommodate the flow of vehicles entering and exiting the work area. The operating radius for weighbridges is set at 15m, matching the physical dimensions of the weighbridge area while also covering reasonable space for vehicle queuing. The operating radius for gate equipment is set at 10m, based on the actual area of ​​the gate inspection area and the safe distance between adjacent vehicles, ensuring orderly gate operations.

[0057] The system constructs a dynamic spatial envelope centered on the real-time geographic coordinates of the operating equipment and within a matched operating radius. This spatial envelope accurately covers the reasonable area for equipment operation and vehicle waiting, and updates in real time as the operating equipment moves, perfectly matching the actual dynamic movement of port operating equipment.

[0058] S22 Preset Exemption Threshold Calculation.

[0059] The system extracts the types of operation instructions from the terminal business instruction data. These instructions cover loading, unloading, container transfer, weighing, and gate inspection, with significant differences in the operational procedures and time consumption for different types of operations. Based on long-term accumulated port operational efficiency statistics, the system determines the standard operating time for each type of operation: 8 minutes for a single container loading / unloading by quay crane, based on the industry average efficiency of 7 to 8 containers handled stably per hour by quay cranes, consistent with the port's actual operational capacity; 3 minutes for a single weighbridge operation, referencing the total time spent on document verification, weight collection, and data upload during a single weighing process at the port; 2 minutes for a single gate inspection operation, based on the conventional time for gate document verification, security checks, and issuance of release instructions; and 5 minutes for a single container transfer operation, taking into account the actual time spent on gantry crane container transfer operations and vehicle start-stop coordination.

[0060] The system has a preset leniency coefficient of 1.5. This coefficient is determined to fully consider various uncertainties in port operations, including equipment start-up and shutdown fluctuations, differences in cargo characteristics, and personnel skill levels. It provides a reasonable buffer for normal operational fluctuations while avoiding missed detections due to an excessively large coefficient. The preset exemption threshold is calculated by multiplying the standard operation time by the preset leniency coefficient. The formula is derived based on the reasonable extension requirements of operation time: Preset Exemption Threshold = Standard Operation Time × Preset Leniency Coefficient, with the unit being uniformly min. For example, the preset exemption threshold for quay crane loading and unloading operations is 8 min × 1.5 = 12 min, and the preset exemption threshold for weighbridge weighing operations is 3 min × 1.5 = 4.5 min. This ensures that the exemption threshold is highly compatible with the actual time consumption of various operations, guaranteeing the accuracy of functional blockage detection.

[0061] S23 Dynamic Operation Mask Generation.

[0062] This step combines the physical space dimension (dynamic spatial envelope) constructed in step S21 with the temporal logic dimension (preset exemption threshold) calculated in step S22 to generate a dynamic job mask for filtering legal static elements. In this scenario, the dynamic job mask is not a simple static image mask, but a spatiotemporal logic filter with a lifecycle overlaid on the port area GIS map.

[0063] The specific generation and maintenance process is as follows: Mask instantiation: The system creates a mask object instance in memory. The object contains spatial properties. With time attribute .

[0064] Spatial attribute mapping: The dynamic spatial envelope (a circular or rectangular area centered on real-time geographic coordinates and with the operating radius as its range) constructed in step S21 is directly mapped to the spatial attributes of the mask. This means that on a GIS map, The covered area is marked as a "work exemption zone".

[0065] Temporal attribute injection: The preset exemption threshold calculated in step S22 is injected into the mask object as its temporal attribute. This attribute defines the maximum legal duration of stillness allowed within this area.

[0066] Dynamic association and refresh: Spatial tracking: The system updates in real time at a frequency of 1Hz. The center coordinates are synchronized with the real-time coordinates of the operating equipment in the terminal's operational instruction data. When the quay crane or gantry crane moves, the masked area shifts accordingly, ensuring that the "exemption zone" always covers the current physical location of the operating equipment.

[0067] Lifecycle Management: The lifecycle of a mask is strongly tied to the status of a work instruction. When the work instruction status is "in execution," the mask is active; when the work instruction status changes to "completed" or "cancelled," the system immediately destroys the corresponding mask instance, releases the congestion exemption for that area, and restores normal traffic monitoring logic.

[0068] Through the above process, the system constructs a dynamically changing "whitelist" layer. Logically, this mask is expressed as: "In the current..." Within the covered geographical area, any stationary behavior of a vehicle for a certain duration Less than This means that any operation deemed legitimate is ignored by the system. This mechanism ensures that the congestion detection algorithm can adapt to the complex working conditions of frequent port equipment movement and varied operation types.

[0069] S24 Legality verification and removal of functionally blocked objects.

[0070] The system performs real-time matching and verification between the multi-source fusion object generated by S1 and the dynamic job mask. First, it determines whether the real-time geographic coordinates of the multi-source fusion object fall within the spatial range of the dynamic job mask. If the geographic coordinates are within the mask's spatial range, the system further calculates the static duration of the multi-source fusion object within that spatial range.

[0071] If a multi-source fusion object falls within the operational coverage area and its stationary duration does not exceed the corresponding preset exemption threshold, the system determines that the object is a functionally blocked object. Functional blockage is a necessary part of port production operations, such as vehicles waiting to load or unload at the quay crane, queuing to weigh at the weighbridge, or waiting for inspection at the gate. Such stationary behaviors are unrelated to traffic congestion. The system removes these functionally blocked objects to prevent them from entering the subsequent congestion determination process.

[0072] By using dynamic operation masks for precise filtering, most stationary vehicles in normal operation states can be effectively eliminated, significantly reducing the risk of false alarms in the subsequent congestion assessment process. At the same time, it accurately retains non-operational stationary objects that truly need attention, laying a solid foundation for the subsequent accurate identification of pathological congestion.

[0073] S3 logic conflict determination abnormal stuck node.

[0074] This step closely follows the dynamic mask filtering results of S2, focusing on the remaining multi-source fusion objects that no longer have clear operational support. By determining the logical conflict between physical state and business intent, it accurately identifies abnormally delayed vehicles lacking reasonable business reasons, providing core node data for subsequent congestion situation analysis. This semantic conflict-based discrimination approach breaks through the limitations of traditional technologies that rely solely on physical parameters, allowing the system to penetrate the appearance of stationary vehicles and uncover the true reasons behind them.

[0075] S31 Physical static state determination.

[0076] The system acquires instantaneous velocity data of the remaining multi-source fusion objects. This data comes from the GNSS positioning module on the vehicle, which collects data in real time at a frequency of 1Hz. The 1Hz sampling frequency ensures both the continuity and timeliness of the velocity data without causing unnecessary data redundancy, perfectly meeting the real-time monitoring needs of port scenarios.

[0077] The system is set to a preset stationary speed threshold of 3 km / h. This value is designed to fully reflect the actual operating conditions within the port area: the speed limit on roads within the port area is usually between 10 km / h and 15 km / h. Speeds below 3 km / h are close to a stationary state for vehicles, which can effectively distinguish between normal driving and stationary conditions, while avoiding misjudging low-speed vehicles used for operations as stationary, thus balancing detection accuracy and scenario adaptability.

[0078] The system also sets the continuous speed monitoring duration to 30 seconds. This duration is based on the typical duration of common situations such as instantaneous braking and temporary start-stop of vehicles. Most vehicles' temporary stops will not exceed 30 seconds, and using this standard can effectively eliminate false judgments caused by short stops. When the instantaneous speed of the remaining multi-source fusion object remains below 3 km / h for 30 seconds, the system determines that the object is physically stationary.

[0079] S32 Business Non-Static Intent Definition.

[0080] The system analyzes the task status of remaining multi-source fusion objects in the terminal business instruction data and combines this with the object's real-time geographic coordinates to comprehensively define its business intent. The boundary of the non-parking area is pre-marked through the port area electronic map and stored in the system, specifically referring to the area outside the planned access roads, operation channels, and equipment operation radius within the port area. If the vehicle's task status is clearly "driving," it means that it has received the driving instruction from the terminal operating system and needs to proceed to the target operation point according to the planned path, thus having a clear driving requirement. If the vehicle's task status is "idle," the system will further determine whether its current geographic coordinates are located in the non-parking area. If it is located in the non-parking area, there is no legal basis for it to remain stationary. If the vehicle's task status is "operating" (such as loading / unloading, weighing, etc.), but it has not been removed by the dynamic operation mask because its stationary time has exceeded the preset exemption threshold corresponding to step S2, it means that its lingering behavior has exceeded the scope of normal operation. When a vehicle meets any of the following three conditions: its task status is "driving," its task status is "idle" and it is located in the non-parking area, or its task status is "operating" but it is a case of excessive lingering, the system defines the object as having a non-stationary business intent, that is, the vehicle has no reasonable reason to remain stationary in the current scenario.

[0081] S33 Logical Conflict Confirmation and Abnormal Node Marking.

[0082] The core of logical conflict determination is to capture the essential contradiction between physical state and business intent. When an object simultaneously satisfies both a physically static state and a non-static business intent, it means that the physical stillness and the business need for movement form an irreconcilable logical conflict.

[0083] This logical conflict directly indicates that the vehicle's stationary state lacks reasonable business support and is considered a non-productive delay, possibly caused by abnormal situations such as vehicle breakdown, conflicting dispatch instructions, or road blockage, rather than a normal state required for port operations.

[0084] At this point, the system marks the object as an abnormally stagnant node, which is a core element constituting pathological congestion. By combining business semantics with physical state to determine logical conflicts, the system achieves accurate detection of potential congestion risks, completely solving the problem that traditional technologies cannot distinguish static semantics based solely on physical parameters, making anomaly identification more targeted and accurate.

[0085] S4 calculates the node cluster density and the backward propagation rate at the tail of the queue to confirm the congestion situation.

[0086] This step follows up on the abnormally delayed nodes marked by S3. A single abnormally delayed node may be an occasional event such as a driver temporarily stopping or briefly handling business, and is not a true congestion. By quantitatively determining the clustering and spread of abnormally delayed nodes in a two-dimensional manner, the system can accurately confirm the congestion situation and avoid false alarms caused by occasional anomalies. This dual-verification design breaks through the limitations of traditional technologies that rely solely on node density or delay duration to judge congestion, making congestion detection more closely aligned with the actual operation scenario of the port and significantly improving reliability.

[0087] S41 node cluster density calculation and abnormal congestion cluster generation.

[0088] The system sets a preset neighborhood of 50m. This range aligns with the actual operational scenario of port roads: the width of a single or double lane in the port area is typically between 4m and 6m, and the safe and reasonable spacing for queuing vehicles is 2m to 3m. A 50m range can accommodate 10 to 15 queuing vehicles, accurately reflecting the clustering characteristics of the vehicles without distorting the clustering results due to an excessively large range, thus ensuring the accuracy of clustering determination. The system calculates the number of other abnormally delayed nodes (denoted as N) within the 50m preset neighborhood for each abnormally delayed node. The neighborhood area is calculated as 2500m² (50m × 50m). In this embodiment, to achieve direct comparison with subsequent empirical thresholds, the system directly uses the number of abnormally delayed nodes N within this neighborhood as the quantitative representation of node cluster density (i.e., node cluster density D = N), in units of vehicles. This processing method can intuitively reflect the degree of vehicle congestion in the local micro-space, avoiding numerical distortion caused by over-normalization. The system sets a preset clustering threshold of 5 vehicles. This value is determined based on the basic carrying capacity of a single road in the port area. When more than 5 vehicles are abnormally stranded within a 50m radius, it indicates that vehicles have formed a significant cluster and exhibit basic characteristics of congestion. When the node cluster density exceeds a preset clustering threshold, the system classifies these spatially highly clustered abnormally stranded nodes into an abnormal congestion cluster. This cluster represents a localized vehicle clustering phenomenon on the road, providing a clear core analysis unit for subsequent spread analysis and making subsequent monitoring more targeted.

[0089] S42 tail displacement vector construction.

[0090] The system is set to a preset time slice of 1 minute. This time length balances the real-time performance of congestion detection with data stability: the 1-minute time interval can promptly capture the trend of congestion spread, avoiding excessive errors in displacement data due to too short a time, while also preventing delays in congestion response due to too long a time, thus fully meeting the real-time scheduling needs of port congestion monitoring.

[0091] The system continuously tracks the geographic coordinates of the tail node of the abnormal congestion cluster. The tail node is defined as the abnormally stuck node at the very end of the congestion cluster along the road travel direction. Specifically, it compares the geographic coordinates of all abnormally stuck nodes in the congestion cluster with the projection values ​​of the road travel direction. The node with the smallest projection value is the tail node, ensuring that the system tracks the extended endpoint of the congestion queue and avoiding the impact of node selection bias on the judgment of the spread trend.

[0092] The system records the tail coordinates of the queue at the start time of the preset time slice in real time. ) and the coordinates of the tail of the queue at the end time ( The displacement difference between the two is calculated by subtracting the starting time coordinate from the ending time coordinate. ), and then construct the tail displacement vector ( , The displacement unit is uniformly set to meters (m), consistent with the geographic coordinate unit mentioned earlier, to ensure data relevance and calculation accuracy.

[0093] S43 reverse spread determination and congestion status confirmation.

[0094] This step, based on the tail displacement vector constructed in step S42 and combined with the node clustering density calculated in step S41, analyzes the movement trend of the tail of the queue to accurately determine whether there is substantial congestion on the current road. Based on the characteristics of port traffic flow, the system defines two conditions for triggering congestion alarms: dynamically spreading congestion and static deadlock congestion.

[0095] The specific judgment logic is as follows: Spread direction verification: The system reads the port area electronic map data to obtain the standard travel direction vector of the current road segment. The tail displacement vector constructed in step S42 is calculated. With respect to the standard travel direction vector of the road The angle between .like In The interval indicates that the tail of the queue is moving along the road direction (i.e., vehicles are dispersing normally) and does not exacerbate congestion; if In The interval indicates that the tail of the queue is moving in the opposite direction (i.e., the queue length is increasing), and there is a risk of congestion spreading.

[0096] Dual determination of congestion situation: The system calculates the magnitude of the tail displacement vector. (i.e., the spread rate), combined with node cluster density. (From step S41), the following determination is performed. The system confirms that the current situation is congested as long as any of the following conditions are met: Condition 1: Dynamically spreading congestion. Criterion: Node cluster density. Preset clustering threshold and included angle Indicates reverse and >Preset spread threshold. Physical meaning: At this point, not only is the vehicle density on the road high, but the tail of the queue is also extending rapidly backward at a speed exceeding 10m / min (for example). This situation usually occurs in the early stages of traffic congestion caused by operational bottlenecks, and immediate warning is required to prevent it from affecting upstream intersections.

[0097] Condition 2: Static deadlock congestion. Judgment criterion: Node cluster density. Preset clustering threshold and (Or less than the minimum threshold) and the duration of this high-density state is greater than the preset deadlock confirmation duration. Physical meaning: At this point, the tail of the queue is almost no longer moving, but the vehicle density is still extremely high. This indicates that the congestion has worsened from "spreading" to "deadlock," and vehicles are completely stuck and unable to move. To prevent misjudgments caused by vehicles temporarily stopping, the system introduces a "preset deadlock confirmation duration" (e.g., 60 seconds) for time-domain filtering. Only when the high-density static state persists is it confirmed as deadlock congestion.

[0098] Detection Result Output: When any of the above conditions is triggered, the system officially confirms the congestion situation and generates a detection result containing rich semantics. The detection result specifically includes: congested road segment ID (located to a specific GIS road segment), congestion pattern identifier ("dynamic spread" or "static deadlock"), coordinates of the congestion cluster center, the current geographical location of the tail of the queue, and the current spread rate. This detection result will serve as the direct input for the closed-loop feedback control in step S5.

[0099] S5 closed-loop feedback control.

[0100] This step closely follows the congestion situation confirmed by S4, proactively mitigating congestion spread and improving port traffic efficiency by establishing a complete closed-loop linkage mechanism of "detection-control-recovery" with the terminal operating system. This design, which directly transforms congestion detection results into scheduling intervention actions, overcomes the limitations of existing technologies that can only passively detect congestion but cannot proactively intervene and control it, making congestion management more timely and targeted, and fully demonstrating the practicality of the solution.

[0101] S51 congestion section identification and alarm command transmission.

[0102] Based on the spatial location information of abnormal congestion clusters generated by S4, and combined with road segmentation data from the port area's electronic map, the system accurately pinpoints specific congested road segments. The road segmentation data from the port area's electronic map includes core attributes such as road segment ID, start coordinates, end coordinates, and number of lanes. The system uses a point-to-line distance judgment algorithm to match the center coordinates of the abnormal congestion cluster with the line segment formed by the start and end coordinates in the road attributes. When the distance is less than 5 meters, the system determines the congested road segment to which the center coordinates belong, ensuring accurate location of congested road segments and providing precise spatial basis for subsequent control measures.

[0103] The system generates alarm commands containing key information, including the congested road segment ID, congestion level, and congestion start time. The congestion level is determined by a combination of node cluster density calculated by S4 and the backward spread rate of the queue tail; higher density and faster spread rate result in a higher congestion level, providing a basis for differentiated control by the terminal operating system. Alarm commands are sent to the terminal operating system via a standardized POST-type API interface. This interface has undergone stability testing to ensure real-time, lossless transmission of congestion information, guaranteeing timely control actions.

[0104] Upon receiving an alarm command, the terminal operating system immediately triggers a route planning weight adjustment mechanism. The system increases the route planning weight of congested road segments from the default 1.0 to 2.0. The adjustment range dynamically adapts to the congestion level; the higher the congestion level, the larger the weight adjustment, with a maximum of 3.0. The core logic of this weight setting is that the route planning weight directly determines the priority of road segment selection. After increasing the weight of congested road segments, the terminal operating system will prioritize non-congested road segments with lower weights when planning routes for subsequent vehicles, thereby reducing the number of new vehicles entering congested areas and cutting off the path of congestion spread at its source.

[0105] Continuous monitoring of the cluster density of nodes in the S52 abnormally congested cluster.

[0106] After the alarm command is sent, the system initiates real-time monitoring of the cluster density of nodes in the abnormal congestion cluster, with a monitoring frequency set to 1Hz. This 1Hz monitoring frequency ensures that the dynamic changes in node cluster density are captured once per second, allowing for timely understanding of congestion mitigation or exacerbation, while avoiding data redundancy and excessive system resource consumption due to overly frequent monitoring, thus balancing real-time monitoring with system stability. During monitoring, the system collects the number of abnormally stuck nodes within the abnormal congestion cluster in real time. Combined with the density calculation logic set in S41, the system directly uses the real-time number of abnormally stuck nodes within this range as the node cluster density for continuous calculation. All monitoring data is synchronized in real-time with the terminal operating system through the system's local cache, ensuring that the terminal operating system can obtain congestion dynamics in real time. This provides continuous and accurate data support for subsequent maintenance or adjustment of control strategies, preventing a disconnect between control actions and actual congestion conditions.

[0107] S53 path planning weight recovery.

[0108] The system sets a preset monitoring duration of 30 seconds for node cluster density. When the node cluster density of an abnormally congested cluster is detected to be below the preset clustering threshold of 5 vehicles set by S41 for 30 consecutive seconds, it indicates that the congestion has been effectively alleviated or completely dissipated. The 30-second continuous judgment duration can effectively filter out false judgments caused by temporary fluctuations in congestion, avoid hastily restoring the weights due to a short-term decrease in the number of nodes, which could lead to a rebound in congestion, and ensure the rationality of the timing of weight restoration.

[0109] At this point, the system immediately sends a weight restoration command to the terminal operating system, explicitly instructing it to restore the route planning weight of this road segment to the default value of 1.0. After the weight is restored, the route planning priority of this road segment returns to the normal level, ensuring the balance of the overall route planning of the port area road network, avoiding overloading of other road segments due to the long-term excessive weight of a certain road segment, thus preventing new congestion and ensuring the smooth circulation of traffic flow in the port area.

[0110] S6 environmental adaptability downgrade.

[0111] This step serves as a crucial supplement to the overall inspection process, specifically addressing scenarios where visual perception data fails due to complex environments such as heavy rain, dense fog, insufficient nighttime lighting, and dust obstruction. By activating targeted degraded inspection modes, it maintains the continuity and robustness of congestion detection, resolving the issue of decreased detection accuracy in extreme environments. This allows the entire solution to adapt to diverse port operating environments, breaking through the dependence of traditional inspection methods on a single data source and significantly improving the system's environmental adaptability.

[0112] S61 Visual Perception Data Confidence Monitoring.

[0113] The confidence score of the visual perception data is directly output by the vehicle target detection algorithm. It is mainly used to reflect the reliability of the vehicle recognition result. Its value ranges from 0 to 1, and the higher the value, the more reliable the recognition result.

[0114] The system sets a preset validity threshold of 0.7. This threshold is determined based on a large number of environmental tests and statistical data: Under normal conditions, the confidence level of visual perception data is generally higher than 0.85. At this time, the false detection rate and false negative rate of vehicle recognition are both less than 5%, which can stably support the detection work. However, in severe environments such as heavy rain and fog, the confidence level of the visual sensor will decrease significantly due to factors such as light and obstruction. When the confidence level is lower than 0.7, the false detection rate and false negative rate of vehicle recognition will exceed 30%, which can no longer reliably support subsequent congestion determination.

[0115] The system monitors the confidence level of visual perception data in real time and sets a continuous judgment period of 5 seconds. If the confidence level is lower than the preset validity threshold of 0.7 for 5 consecutive seconds, the visual perception data is deemed insufficiently valid, and a downgraded detection mode needs to be activated. The 5-second continuous judgment period effectively filters out false triggers caused by instantaneous environmental fluctuations, ensuring the accuracy of the downgrade mode activation and avoiding frequent switching of the detection process due to brief interference.

[0116] S62 downgrade detection mode activated.

[0117] When the validity of visual perception data is insufficient, the system automatically activates a degraded detection mode. In this mode, the system suspends the use of visual perception data and only performs logical conflict determination based on vehicle positioning data and terminal business instruction data. This determination logic is completely consistent with the logical conflict determination of physical state and business intent in S3, ensuring the uniformity of detection standards and avoiding deviations in determination results due to mode switching.

[0118] Vehicle positioning data is collected via a GNSS positioning module, unaffected by severe environments such as heavy rain and fog, and can stably provide the vehicle's real-time geographic coordinates and instantaneous speed. Terminal business instruction data is obtained through a standardized API interface, ensuring data transmission is unaffected by environmental interference and fully reflecting the vehicle's mission status and business intent. The stable combination of these two technologies ensures that core detection functions are not affected by visual data failure, maintaining the basic performance of the detection system and preventing the entire detection process from being interrupted due to the failure of a single data source.

[0119] S63 duration threshold adjustment.

[0120] Vehicle positioning data may experience slight drift in harsh environments, with a typical drift range of ±0.5m. This drift may cause irregular fluctuations in instantaneous speed calculations, thereby affecting the accuracy of determining the physical stationary state.

[0121] To effectively filter interference caused by positioning drift, the system sets a preset drift suppression time increment of 20 seconds. In degraded detection mode, the duration threshold required to determine a physically stationary state in S31 is increased from 30 seconds to 50 seconds (the calculation logic is 30 seconds + 20 seconds = 50 seconds). The 20-second drift suppression time increment is determined based on the typical impact duration of positioning drift. This approach can both offset the impact of instantaneous speed fluctuations on the determination results by extending the continuous monitoring time, ensuring the accuracy of the physically stationary state determination, and avoid delays in congestion detection response due to excessive duration, thus balancing determination accuracy and real-time performance.

[0122] Based on the same inventive concept, this application also provides a vehicle congestion detection system based on multi-source data fusion for implementing the vehicle congestion detection method based on multi-source data fusion described above. The solution provided by this system is similar to the solution described in the above method. Therefore, the specific limitations in the embodiments of the vehicle congestion detection system based on multi-source data fusion provided below can be found in the limitations of the vehicle congestion detection method based on multi-source data fusion described above, and will not be repeated here.

[0123] This application provides a vehicle congestion detection system based on multi-source data fusion, such as... Figure 2 As shown, this vehicle congestion detection system based on multi-source data fusion mainly includes the following four core functional modules: The multi-source fusion mapping module 201 serves as the system's data foundation, with its core function being the construction of a holographic perspective. It is responsible for real-time access to three types of heterogeneous data: visual perception data, vehicle positioning data, and port business instruction data. By mapping this data to a unified benchmark, this module can bind the physical world's vehicle location and appearance information with the digital world's business task attributes (such as task type and target work point), thereby generating a multi-source fusion object that combines "physical state" and "business intent," providing complete data support for subsequent logical judgments.

[0124] The dynamic mask filtering module 202 primarily performs legality verification, aiming to eliminate functional obstructions. Based on the real-time status of operating equipment (such as quay crane loading / unloading and weighbridge weighing) in the terminal business instruction data, it constructs a dynamic operation mask that changes with the movement of operating equipment and the type of operation. This mask performs dual spatial and temporal filtering on multi-source fusion objects: any vehicle falling within the operation coverage area and remaining stationary for no more than a preset exemption threshold is identified as a normal stopover (i.e., a functional obstruction object) and eliminated, effectively preventing false alarms caused by normal operation queuing.

[0125] The logical conflict verification module 203 is the core discrimination unit of the system, responsible for identifying pathological congestion. For the remaining objects after dynamic mask filtering, this module performs logical conflict judgment between physical state and business intent. Its detection principle lies in capturing contradictions: if an object is physically stationary, but its business intent indicates driving, idle non-stop, or operation timeout, a logical conflict exists, and the system marks the object as an abnormally stalled node.

[0126] The congestion situation confirmation module 204 is responsible for the final macro-level situation confirmation. It is no longer limited to the abnormal state of individual vehicles, but calculates the node cluster density and the backward spread rate of the queue tail based on the spatiotemporal distribution characteristics of abnormally delayed nodes. Only when the vehicle aggregation density in a local area exceeds a threshold, accompanied by a trend of queue backward spread (or high-density deadlock), will the module officially confirm the congestion situation and output detection results including the congested road segment, length, and level, ensuring a high confidence level for the alarm.

[0127] See Figure 3 , Figure 3 This is a schematic block diagram of an electronic device provided according to an embodiment of this application. Figure 3 The electronic device 300 in this embodiment may include one or more processors 301, one or more input devices 302, one or more output devices 303, and one or more memories 304. The processors 301, input devices 302, output devices 303, and memories 304 communicate with each other via a communication bus 305. The memories 304 store computer programs, including program instructions. The processors 301 execute the program instructions stored in the memories 304. Specifically, the processors 301 are configured to invoke the program instructions to perform the functions of each module / unit in the above-described device embodiments, for example... Figure 2 The functions of the multi-source fusion mapping module 201, dynamic mask filtering module 202, logical conflict verification module 203, and congestion status verification module 204 are shown.

[0128] It should be understood that, in the embodiments of this application, the processor 301 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0129] Input device 302 may include a touchpad, a fingerprint sensor (for collecting the user's fingerprint information and fingerprint orientation information), a microphone, etc., and output device 303 may include a display (LCD, etc.), a speaker, etc.

[0130] The memory 304 may include read-only memory and random access memory, and provides instructions and data to the processor 301. A portion of the memory 304 may also include non-volatile random access memory. For example, the memory 304 may also store device type information.

[0131] In specific implementations, the processor 301, input device 302, and output device 303 described in the embodiments of this application can execute the implementation method described in the vehicle congestion detection method based on multi-source data fusion provided in the embodiments of this application, or they can execute the implementation method of the electronic device described in the embodiments of this application, which will not be repeated here.

[0132] In another embodiment of this application, a computer-readable storage medium is provided. This computer-readable storage medium stores a computer program, which includes program instructions. When executed by a processor, the program instructions implement all or part of the processes in the methods described above. Alternatively, the computer program can instruct related hardware to implement these processes. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include any entity or device capable of carrying computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0133] The computer-readable storage medium can be an internal storage unit of the electronic device in any of the foregoing embodiments, such as a hard disk or memory of the electronic device. The computer-readable storage medium can also be an external storage device of the electronic device, such as a plug-in hard disk, SmartMediaCard (SMC), Secure Digital (SD) card, FlashCard, etc., equipped on the electronic device. Furthermore, the computer-readable storage medium can include both internal and external storage units of the electronic device. The computer-readable storage medium is used to store computer programs and other programs and data required by the electronic device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0134] Those skilled in the art will recognize that the modules / units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0135] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the electronic devices and units described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0136] In the several embodiments provided in this application, it should be understood that the disclosed electronic devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of modules / units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules, units, or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces or modules / units, or it may be an electrical, mechanical, or other form of connection.

[0137] The modules / units described as separate components may or may not be physically separate. Similarly, the components shown as modules / units may or may not be physical modules / units; they may be located in one place or distributed across multiple network modules / units. Some or all of the modules / units can be selected to achieve the purpose of the embodiments of this application, depending on actual needs.

[0138] Furthermore, the functional modules / units in the various embodiments of this application can be integrated into one processing module / unit, or each module / unit can exist physically separately, or two or more modules / units can be integrated into one module / unit. The integrated modules / units described above can be implemented in hardware or in the form of software functional modules / units.

[0139] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A vehicle congestion detection method based on multi-source data fusion, characterized in that, include: The system acquires visual perception data collected by port area monitoring equipment, vehicle positioning data provided by vehicle self-positioning equipment, and terminal business instruction data issued by the terminal operating system. The system then maps the visual perception data, vehicle positioning data, and terminal business instruction data to a unified benchmark to construct a multi-source fusion object that combines physical state and business intent. A dynamic operation mask is constructed based on the real-time status of the operating equipment in the terminal business instruction data. The legality of the multi-source fusion object is verified by the dynamic operation mask: functional obstruction objects that fall into the operation coverage area and whose static duration does not exceed the preset exemption threshold are removed. For the remaining multi-source fusion objects after verification, perform logical conflict judgment between physical state and business intent, and mark objects whose physical state is stationary and whose business intent is driving, idle non-stopping or operation timeout as abnormal lingering nodes. Based on the spatiotemporal distribution of the abnormally delayed nodes, the node cluster density and the tail-end backward propagation rate are calculated. When the node cluster density exceeds a preset clustering threshold and the tail-end backward propagation rate exceeds a preset alarm threshold or exhibits a static deadlock state, the congestion situation is confirmed and the detection results are output.

2. The method as described in claim 1, characterized in that, The process of mapping the visual perception data, vehicle positioning data, and terminal business instruction data to a unified benchmark to construct a multi-source fusion object that combines physical state and business intent includes: The visual perception data is converted into geographic coordinates, and the spatial distance between the geographic coordinates and the vehicle positioning data is calculated. When the spatial distance is less than a preset identity threshold, an identity binding relationship is established between the visual target and the positioning target, and the positioning identifier is extracted; The task attributes in the terminal business instruction data are matched with the location identifier, and the task attributes are injected into the identity binding relationship to generate the multi-source fusion object.

3. The method as described in claim 1, characterized in that, The step of constructing a dynamic operation mask based on the real-time status of the operating equipment in the terminal business instruction data includes: The terminal business instruction data is parsed to obtain the equipment type and real-time coordinates, and the corresponding operating radius is matched to construct a dynamic spatial envelope. Extract the operation instruction type from the terminal business instruction data to determine the standard operation duration, and calculate the preset exemption threshold using a preset leniency coefficient; Generate the dynamic job mask that covers the dynamic spatial envelope and whose effective time period is limited by the preset exemption threshold.

4. The method as described in claim 1, characterized in that, The step of performing logical conflict determination between the physical state and business intent on the remaining multi-source fusion objects after verification includes: If the instantaneous velocity of the remaining multi-source fusion object remains below a preset stationary velocity threshold for a preset continuous monitoring period, it is determined to be in a physically stationary state. The terminal business instruction data is analyzed. If the task status is driving, or the task status is idle and located in a non-parking area, or the task status is in operation but the stationary time has exceeded the preset exemption threshold, it is defined as a non-stationary business intention. When the physical static state and the non-static business intent are simultaneously satisfied, the corresponding multi-source fusion object is marked as the abnormal lingering node.

5. The method as described in claim 1, characterized in that, The calculation of node cluster density and tail backpropagation rate based on the spatiotemporal distribution of the abnormally loitering nodes includes: The distribution density of the abnormally delayed nodes in a preset neighborhood is calculated as the node cluster density. When the density exceeds a preset clustering threshold, an abnormal congestion cluster is generated. The displacement of the tail coordinates of the abnormal congestion cluster within a preset time slice is tracked to construct the tail displacement vector; If the tail displacement vector is reversed and its magnitude is greater than the preset spread threshold, or if the tail displacement vector magnitude shows to be stationary but the node clustering density of the abnormal congestion cluster remains higher than the preset clustering threshold within a preset monitoring period, the congestion situation is confirmed.

6. The method as described in claim 5, characterized in that, After confirming the congestion situation, closed-loop feedback control is implemented, including: Based on the spatial location of the abnormal congestion cluster, the congested road segment is determined, and an alarm command containing the congested road segment identifier is sent to the dock operating system to trigger an increase in the path planning weight of the congested road segment. Continuously monitor the node cluster density of the abnormal congestion cluster; In response to the node cluster density being lower than the preset clustering threshold, the dock operating system is instructed to restore the path planning weights.

7. The method as described in claim 4, characterized in that, This also includes implementing environment adaptation degradation: Monitor the confidence level of the visual perception data; if it is lower than a preset validity threshold, activate the downgraded detection mode. In the degraded detection mode, the logical conflict determination is made only based on the vehicle positioning data and the terminal business instruction data; Specifically, when performing the physical static state determination in the logical conflict determination, the preset drift suppression time increment is used to increase the determination of the duration threshold required for the instantaneous speed to remain below the preset static speed threshold.

8. A vehicle congestion detection system based on multi-source data fusion, characterized in that, include: The multi-source fusion mapping module is configured to acquire visual perception data, vehicle positioning data, and terminal business instruction data, and map the visual perception data, vehicle positioning data, and terminal business instruction data to a unified benchmark to construct a multi-source fusion object that combines physical state and business intent. The dynamic mask filtering module is configured to construct a dynamic operation mask based on the real-time status of the operating equipment in the terminal business instruction data, and use the dynamic operation mask to perform legality verification on the multi-source fusion object, and remove functional blocking objects that fall within the operation coverage area and whose static duration does not exceed the preset exemption threshold. The logical conflict verification module is configured to perform logical conflict judgment between the physical state and business intent on the remaining multi-source fusion objects after verification, and mark objects whose physical state is static but whose business intent indicates a non-static task as abnormal lingering nodes. The congestion status confirmation module is configured to calculate the node cluster density and the tail-back backward spread rate based on the spatiotemporal distribution of the abnormally delayed nodes. The congestion status is confirmed and the detection result is output only when both the node cluster density and the tail-back backward spread rate exceed a preset alarm threshold.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images