Multi-source heterogeneous traffic light data fusion optimization method based on vehicle and road cloud
By using a multi-source data fusion optimization method involving vehicle cameras, V2X communication, and cloud services, the problems of low accuracy and excessive latency in vehicle-mounted visual perception, roadside unit broadcasting, and cloud platform recognition have been solved, achieving highly reliable and low-latency traffic light data services and improving driving safety and traffic efficiency.
Patent Information
- Application Number
- CN202511711653.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-20
- Publication Date
- 2026-02-03
AI Technical Summary
In existing technologies, vehicle-mounted visual perception, roadside unit broadcasting, and cloud-based traffic management platforms suffer from low recognition accuracy, unreliable communication, and excessive latency in multi-source heterogeneous data environments. This leads to inconsistent traffic light status and reduced traffic efficiency, posing driving safety risks.
By employing a multi-source data fusion optimization method that integrates vehicle cameras, V2X communication, and cloud services, including data cleaning, quality assessment, and dynamic priority scheduling, high-reliability and low-latency fusion of traffic light data can be achieved.
In a multi-source heterogeneous environment, it provides stable and reliable traffic light data services, achieving service availability of over 99.9% and average latency of less than 100ms, supporting city-scale deployment and improving driving safety and traffic efficiency.
Smart Images

Figure CN121459604A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of vehicle-road cooperative technology, specifically to a method for optimizing multi-source heterogeneous traffic light data fusion based on vehicle-road-cloud. Background Technology
[0002] With the rapid development of intelligent connected vehicles (ICV) and vehicle-to-everything (V2X) technologies, accurate perception and real-time display of traffic lights have become core requirements for driver assistance and autonomous driving systems. Existing technologies primarily rely on three types of data sources:
[0003] Vehicle-mounted visual perception: Traffic light status is identified through vehicle-mounted cameras, but it is easily affected by factors such as lighting, occlusion, and viewing angle deviation. The recognition accuracy drops significantly in complex environments (such as strong backlight or bad weather).
[0004] Roadside Unit (RSU) broadcasting: Traffic light information is obtained based on V2X communication (such as C-V2X / DSRC), but there is a risk of communication interruption when there is network congestion or edge device failure;
[0005] Cloud-based traffic management platform: Provides global scheduling data, but due to the long data transmission link, the inherent latency can reach more than 500ms, which cannot meet the real-time control requirements (such as vehicles needing to respond accurately to traffic at intersections within 100ms).
[0006] Current technological bottlenecks:
[0007] Multi-source data conflict: The collection frequency, accuracy and latency of each data source are significantly different (e.g., visual recognition frequency of 30Hz vs. cloud transmission frequency of 1Hz), resulting in inconsistent status information;
[0008] Communication unreliability: V2X wireless channels are susceptible to interference, with a packet loss rate as high as 5%-10%, causing signal light displays to change or disappear.
[0009] Cumulative delay impact: The cumulative end-to-end delay (sensing + transmission + processing) may exceed 1 second, causing a serious mismatch between the traffic light status known to the vehicle and the actual intersection status.
[0010] The aforementioned defects directly lead to driving safety risks (such as accidentally running a red light) and reduced traffic efficiency (due to conservative driving strategies). Therefore, there is an urgent need for a technical solution that can achieve highly reliable, low-latency fusion and display of traffic light status in a multi-source heterogeneous data environment. Summary of the Invention
[0011] The purpose of this invention is to provide a method for optimizing multi-source heterogeneous traffic light data fusion based on vehicle-road-cloud. The specific steps of this method are as follows:
[0012] S01: Traffic light data collection:
[0013] There are three ways to collect traffic light data: using cameras to perceive and identify traffic lights, using V2X short-range communication to obtain traffic light data at intersections, and using cloud-based traffic light data services to obtain traffic light data.
[0014] The first method uses a vehicle's forward-facing camera to identify the target light pole's light color status (red / yellow / green) and countdown information in real time. Through continuous periodic monitoring, it records the maximum red / green / yellow light duration for each turning phase and corrects the total countdown duration and phase calibration in the next cycle to generate a complete periodic phase timing sequence.
[0015] The second method receives V2X broadcast messages through the PC5 interface, parses the SPAT (Signal Light Phase and Time) and MAP (Intersection Map Topology) data, matches the current intersection ID, road segment ID, lane ID and phase ID based on the vehicle location and MAP data, and then extracts the real-time status information of the corresponding light group through the phase index.
[0016] The third method establishes an interactive channel with the traffic cloud platform through cellular networks (V2N). Vehicles report their own position, heading angle, and other motion status information in real time, and the platform determines the target intersection and approach direction based on road segment-level map matching (without requiring high-precision positioning).
[0017] S02: Data Cleaning
[0018] Traffic light data is a core element of intelligent transportation systems, and its quality directly affects the accuracy of traffic signal control and road safety. Given the multi-source and heterogeneous nature of traffic light data, it is necessary to establish a systematic data cleaning process and quality assessment system. The data has different characteristics, which also brings different data quality problems, requiring systematic cleaning and quality assessment.
[0019] 1) Vehicle-sensing traffic light data cleaning:
[0020] Deep learning-based methods can effectively optimize traffic light status data. By using an LSTM prediction model based on historical normal traffic light status changes, the normal variation patterns of traffic light color, position, and timing are described. The real-time recognition results are compared with the model predictions, and residual scores are calculated. For color recognition, classification cross-entropy loss is used, and for position and timing data, mean squared error is used. When the residual exceeds an adaptive threshold, it is marked as an anomaly. For the recognition results of consecutive frames in the video stream, a majority voting mechanism is used to determine the final state.
[0021] Vehicle perception data is often missing due to occlusion, changes in lighting, and other reasons. The following data completion strategies can be adopted to address different missing scenarios:
[0022] Short-term missing data (<3 seconds): Use linear interpolation or a completion method based on the signal periodicity. For example, if the traffic light cycle is known to be 120 seconds and 2 seconds of data are missing, the current state (red or green) can be inferred based on the cycle characteristics.
[0023] Long-term missing data (≥3 seconds): Marked as invalid data and not completed to avoid introducing excessive errors. The system can switch to relying on roadside or cloud data;
[0024] Time synchronization: Corrects clock deviations in vehicle-mounted equipment to ensure accurate timestamps. PTP or NTP is used to achieve millisecond-level synchronization between the vehicle system and GPS time, avoiding time base discrepancies between data from different vehicles.
[0025] After undergoing the above cleaning process, the vehicle perception data provides a reliable foundation for subsequent multi-source heterogeneous data fusion and traffic decision-making.
[0026] 2) Roadside data cleaning:
[0027] Signal strength monitoring: Receive signal strength indication, i.e. RSSI, reflects the status of the communication link. When RSSI < -85dBm, the link quality is considered poor and the data reliability should be reduced.
[0028] Bit error rate detection: Cyclic redundancy check is used to detect data packet errors. For data packets that fail the check, retransmission can be requested or they can be marked as invalid.
[0029] Data freshness assessment: Calculate the difference between message generation time and reception time. When the delay is >100ms, the data freshness is considered insufficient, especially when the remaining time is short (<5 seconds).
[0030] Packet loss monitoring: Real-time statistical packet continuity. When two packets are lost consecutively, the communication quality is considered unreliable. When three packets are received consecutively, the data is considered usable. In the case of continuous data, the data packets are monitored based on the message sequence number increasing in the range of 0-127, and outliers are removed.
[0031] Redundant data elimination:
[0032] Message deduplication: Identify and discard duplicate messages based on message sequence number and traffic light ID;
[0033] Incremental update: Only fields that have changed since the last reception are processed, reducing processing overhead. When only the remaining time is updated, only time-related parameters need to be recalculated.
[0034] Sliding window aggregation: Aggregates multiple messages from the same traffic light within a short time window, taking the latest or average value of each field;
[0035] 3) Cloud-based data cleaning:
[0036] Cloud platform data is delivered via cellular V2N networks, which presents transmission latency issues, especially during cross-regional scheduling.
[0037] Delay detection and time alignment: The end-to-end delay is calculated by comparing the generation timestamp and the reception timestamp in the data packet. When the delay is lower than the threshold, the compensation mechanism is activated.
[0038] Traffic light status prediction: For time-series data with significant delays, linear prediction or compensation algorithms based on signal period models are used. For example, if the red light is known to last for 30 seconds, and the received data is delayed by 2 seconds, and the original data indicates "10 seconds left on the red light", then it is corrected to "8 seconds left on the red light".
[0039] Heartbeat mechanism and clock synchronization: The platform periodically sends heartbeat signals, and the vehicle uses these signals to calibrate its local clock deviation, ensuring time synchronization accuracy within 50ms. NTP combined with PTP can achieve microsecond-level synchronization.
[0040] 4) Data quality assessment methods:
[0041] The steps for constructing a comprehensive scoring model based on the analytic hierarchy process are as follows:
[0042] Constructing the judgment matrix: Ten domain experts were invited to compare each quality dimension pairwise to construct the judgment matrix. For autonomous driving applications, accuracy was considered slightly more important than timeliness, with a weighting ratio of 3:1.
[0043] S03: Multi-source data fusion
[0044] Multi-source heterogeneous data fusion mainly involves fusing traffic light data perceived by vehicles, traffic light data from roadside communication, and traffic light data from platform communication.
[0045] The fusion method includes prioritizing the use of basic traffic light data based on data quality, using the highest priority basic data as the basis for updating the current data source, and using extended traffic light data according to the strategy of using it only when available and not using it when not available. When both the roadside and the platform have phase information for the next stage, the extended traffic light information in the cloud is used first. When updating the extended traffic light information, the validity and update timestamp of the extended data are updated.
[0046] 1) Traffic light data update strategy:
[0047] Once the latest traffic light data is obtained for the first time, the traffic light data for the current phase is updated to the system traffic light data, and the traffic light self-update strategy is enabled, recording the initial timestamp as a baseline reference.
[0048] When the current traffic light data is not obtained for the first time, compare the current countdown time and light color of the system. If they are consistent, do not update, but update the timestamp of the system traffic light data.
[0049] If there is a discrepancy, that is, when the current traffic light data and the system traffic light data change, it is assumed that the current data has been updated. If the current traffic light countdown is not 1 second, it is determined whether the countdown data before and after the traffic light is a whole second difference. If the traffic light countdown before and after the current data is not a whole second difference, it indicates that the current system traffic light countdown is abnormal. The original self-updating data starting point needs to be updated and aligned with the current external traffic light time. The current traffic light data source data is used to update the current system traffic light time, and the system traffic light data timestamp is updated at the same time.
[0050] 2) Traffic light data self-update strategy:
[0051] After the initial data acquisition, the system started updating the usage time and system traffic light status timer every second. Currently, the timer is full. If no data is received from an external source when the time is >=1s, it is considered that there is an abnormal delay in the current traffic light data and the data cannot be updated through step 1). In this case, the system traffic light countdown adopts a self-update strategy, automatically updates the countdown status, the traffic light color of each phase remains unchanged, the traffic light countdown is automatically decremented by 1, and the system basic data update time is updated.
[0052] When the countdown of a traffic light is 1, it is considered that the countdown of that light color in the current phase is about to end. Then, it is checked whether the countdown information of the traffic light in the next phase is valid. If it is valid, the countdown of the traffic light in the next phase is started, all traffic light colors and countdowns are updated, and the countdown of the traffic light in the next phase is set to invalid.
[0053] If extended traffic light information cannot be obtained at the moment, and the light color and countdown of the next phase cannot be obtained, the current phase state will not be updated, the current light color will be maintained, the traffic light countdown will be 1, and the maximum duration will be 3 seconds, after which a data timeout warning will be triggered.
[0054] 3) Data delay compensation update:
[0055] To ensure the lowest possible delay error between the HMI display and the actual display time, and to fully consider the impact of end-to-end communication delay in the traffic light data transmission process, a delay compensation strategy is added to the self-update strategy. This strategy compensates for the second jump time based on the original traffic light cycle second jump time, that is, it makes the traffic light time jump second earlier, ensuring that the HMI second jump time is as aligned as possible with the traffic light time on site.
[0056] Depending on the data source, the estimated communication latency may vary slightly. Therefore, the self-update logic performs corresponding latency compensation on the traffic light data. For data with a latency less than 500ms, latency compensation is performed in the self-update strategy. The corresponding latency compensation time is shortened during the initial execution time timing, i.e., the timing time becomes... = The timer then returned to normal. This means that communication delay compensation for the current traffic light time can be achieved;
[0057] Data with excessively high communication latency will be given a low score in the data quality assessment process and will generally not be used with high priority. If the latency is too high, there may be whole-second errors. The data update strategy will be updated according to the whole-second errors. In such cases, poor data quality, unstable data updates, and phenomena such as skipped seconds will occur.
[0058] When a traffic light color changes and extended traffic light information is not obtained, the countdown of the last second will be extended until the traffic light data is updated in the next second, and a delay compensation will be performed again on the first time after the color change.
[0059] 4) Data source switching:
[0060] When the current system traffic light data time exceeds 3 seconds of valid use, the system will invalidate the current traffic light data and select the traffic light data source with the second score from the backup data source to update the traffic light data;
[0061] S04: HMI Data Display: Every 500ms, the system sends valid traffic light status information, current light color, countdown, data source identifier, data reliability indicator (high / medium / low), and data quality score to the HMI.
[0062] Real-time push notifications for abnormal statuses, automatic update activation, and signal source loss detection;
[0063] Time smoothing: The countdown display uses an interpolation algorithm to avoid abrupt changes;
[0064] State transition animation: Add a gradient effect when the phase changes to enhance the driving experience.
[0065] Preferably, in step SO1, the first method further categorizes the processing based on the type of lamp assembly:
[0066] Disc lights: Identify the overall traffic status of the approach lane, including straight ahead, left turn, right turn, and U-turn; the countdown timer remains consistent for all directions.
[0067] Arrow lights: Identify the independent light color status and countdown for each direction of traffic (left turn, straight, right turn) according to the turn indicator.
[0068] Preferably, in step SO1, in the first method, SPAT represents the phase and time of the traffic light, and the countdown information in the SPAT data supports two expression mechanisms:
[0069] Relative Time Mode: Directly provides the current phase light color, remaining duration, and countdown and duration for the start and end of the next phase;
[0070] Absolute timestamp mode: Based on UTC timestamps, the start time, theoretical end time, and most likely end time of the current phase are marked, and can be extended to the start and end timestamps of the next phase;
[0071] The two modes are essentially the same: both map phase timing through time parameters. The only difference is the time base. If the SPAT data contains the start and end times of the next phase, whether in relative or absolute form, then the current traffic light information is determined to have complete phase timing, and the maximum duration of each phase light color state is recorded synchronously.
[0072] Preferably, in step SO1, in the first method, the following data is obtained through the phase list index associated with the inlet channel:
[0073] Real-time phase status: The light colors and countdown information for each direction of traffic at the current approach lane;
[0074] Extended timing data: If the platform supports it, synchronously obtain forward-looking information such as the pre-switching light color and duration of the next phase;
[0075] The cloud platform will distribute the integrated traffic light data to the vehicle terminal via V2N (UU), and the vehicle equipment will complete the data parsing and status update.
[0076] Preferably, the weights of the indicators are calculated using the eigenvector method. Typical values are:
[0077] accuracy 40%
[0078] consistency 25%
[0079] Timeliness 15%
[0080] Integrity 12%
[0081] Availability 8%
[0082] Indicator normalization: Normalizing indicators with different dimensions to the range of 0-1.
[0083] Accuracy: Raw values were used directly (98% → 0.98)
[0084] Delay: Inverse S-shaped function mapping is used (delay 100ms → 0.95, 500ms → 0.60)
[0085] Completeness: Linear mapping (90% → 0.90)
[0086]
[0087] The basic information and scoring information of the traffic light status for each data source i were obtained using the method described above. .
[0088] Compared with existing technologies, the beneficial effects of this invention are: by collaboratively integrating three data sources—vehicle-side perception, roadside broadcasting, and cloud services—a highly reliable traffic light information service system is constructed. It effectively solves key problems in existing technologies: 1) overcoming the problems of low recognition accuracy, occlusion, and failure under adverse weather conditions in vehicle-side perception; 2) compensating for the limited coverage and insufficient communication distance of roadside equipment; and 3) optimizing the high latency problem of cloud data. Through intelligent data fusion algorithms and dynamic priority scheduling mechanisms, it can provide stable and reliable traffic light data services for vehicles over a large area, possessing the following technical advantages: 1) achieving service availability of over 99.9%; 2) controlling the average latency to within 100ms; and 3) supporting city-scale deployment. In extreme cases, such as when communication latency fluctuates significantly, brief display delays or second skips may occur, but the system can still ensure basic service continuity through a data compensation mechanism. Attached Figure Description
[0089] Figure 1 This is a flowchart of the present invention. Detailed Implementation
[0090] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.
[0091] Example 1
[0092] A method for optimizing multi-source heterogeneous traffic light data based on vehicle-road-cloud computing is characterized by the following specific steps:
[0093] S01: Traffic light data collection:
[0094] There are three ways to collect traffic light data: using cameras to perceive and identify traffic lights, using V2X short-range communication to obtain traffic light data at intersections, and using cloud-based traffic light data services to obtain traffic light data.
[0095] The first method uses a vehicle-facing camera to identify the target light pole's light color status (red / yellow / green) and countdown information in real time. Through continuous periodic monitoring, it records the maximum red / green / yellow light duration for each turning phase, and corrects the total countdown duration and phase calibration in the next cycle to generate a complete cyclical phase timing sequence; it is then processed according to the light group type.
[0096] Disc lights: Identify the overall traffic status of the approach lane, including straight ahead, left turn, right turn, and U-turn; the countdown timer remains consistent for all directions.
[0097] Arrow lights: Identify the independent light color status and countdown for each direction of traffic (left turn, straight, right turn) according to the turn indicator;
[0098] The second method receives V2X broadcast messages via the PC5 interface, parses the SPAT (Signal Light Phase and Time) and MAP (Intersection Map Topology) data, matches the vehicle location with the MAP data to obtain the current intersection ID, road segment ID, lane ID, and phase ID, and then extracts the real-time status information of the corresponding light group through the phase index; SPAT stands for signal light phase and time, and the countdown information in the SPAT data supports two expression mechanisms:
[0099] Relative Time Mode: Directly provides the current phase light color, remaining duration, and countdown and duration for the start and end of the next phase;
[0100] Absolute timestamp mode: Based on UTC timestamps, the start time, theoretical end time (maximum / minimum boundary value), and most likely end time of the current phase are marked, and can be extended to the start and end timestamps of the next phase;
[0101] The two modes are essentially the same: both map phase timing through time parameters. The only difference is the time base (relative duration vs. absolute clock). If the SPAT data contains the start and end times of the next phase, whether in relative or absolute form, it is determined that the current traffic light information has complete phase timing, and the maximum duration of each phase light color state (such as the maximum red light duration) is recorded synchronously.
[0102] The third method establishes an interactive channel with the traffic cloud platform via cellular network (V2N). Vehicles report their location, heading angle, and other motion status information in real time. The platform determines the target intersection and approach direction based on road segment-level map matching (without requiring high-precision positioning); through the phase list index associated with this approach, it obtains the following data:
[0103] Real-time phase status: The light colors and countdown information for each direction of traffic (left turn / straight / right turn / U-turn) at the current approach lane;
[0104] Extended timing data: If the platform supports it, synchronously obtain forward-looking information such as the pre-switching light color and duration of the next phase;
[0105] The cloud platform will distribute the integrated traffic light data to the vehicle terminal via V2N (UU), and the vehicle equipment will complete the data parsing and status update.
[0106] The aforementioned vehicle-mounted visual perception, RSU broadcast (PC5), and cloud platform interaction (V2N) are currently mainstream traffic light data acquisition solutions, but the scope of this patent is not limited to these. Any traffic light information acquisition solution based on heterogeneous sensing devices (such as LiDAR, roadside millimeter-wave radar, and infrared sensors) or extended communication protocols (such as NR-V2X, UWB, and Wi-Fi 6 direct connection) is a derivative implementation of the technical framework of this patent and is subject to the scope of protection of the claims.
[0107] S02: Data Cleaning
[0108] Traffic light data is a core element of intelligent transportation systems, and its quality directly affects the accuracy of traffic signal control and road safety. Given the multi-source and heterogeneous nature of traffic light data, a systematic data cleaning process and quality assessment system are needed. This paper details the cleaning methods for three types of traffic light data sources: vehicle perception, roadside PC5 communication, and cloud platform distribution. A quantifiable data quality scoring model is proposed to provide reliable data support for intelligent transportation systems. The diverse characteristics of each data source also bring different data quality issues, necessitating systematic cleaning and quality assessment.
[0109] Vehicle perception data originates from sensors such as cameras and LiDAR mounted on the vehicle. Using computer vision technology, vehicles can identify the real-time status of traffic lights (red, green, yellow), remaining time, and the location of traffic lights. This type of data is characterized by its rich raw information but is greatly affected by the environment—rain, snow, changes in lighting, and obstructions can all impact recognition accuracy. Furthermore, differences in sensor configurations and recognition algorithms among different vehicle models can lead to inconsistent data quality. In complex environments, the error rate of vehicle-perceived traffic light recognition will further increase.
[0110] Roadside PC5 communication data is broadcast directly from the roadside unit (RSU) to surrounding vehicles via V2X communication technologies (such as DSRC and C-V2X). This type of data typically uses a standardized SPAT (Signal Phase and Timing) message format, containing structured information such as signal phase and timing. While PC5 communication data offers strong real-time performance and a uniform format, it may face issues such as communication delays and data packet loss. Particularly in high-density traffic scenarios, communication channel congestion can lead to a decrease in data update frequency, affecting the timeliness of information.
[0111] Data distributed from the cloud platform is processed centrally by the traffic management center before being allocated to vehicles, exhibiting global and integrated characteristics. The cloud platform typically integrates signal control data from multiple intersections and may incorporate historical data for optimization. However, this type of data, due to long transmission links, may experience synchronization issues due to network latency. Furthermore, differences in platform data processing algorithms can also affect the accuracy and completeness of the data.
[0112] The main factors to consider when cleaning data include data integrity, accuracy, consistency, timeliness, and availability.
[0113] 1) Cleaning of vehicle-sensing traffic light data
[0114] Common anomalies in vehicle-perceived traffic light data include color misjudgments (identifying a green light as a green light, a sign as a traffic light, and incorrect recognition of remaining time, etc.). Traditional threshold detection methods struggle to identify these complex anomalies. Deep learning-based methods can effectively optimize traffic light status data. An LSTM (Long Short-Term Memory) prediction model, based on historical normal traffic light status changes, describes the normal variation patterns of traffic light color, position, and timing. Real-time recognition results are compared with model predictions, and residual scores are calculated. For color recognition, a classification cross-entropy loss is used; for position and timing data, mean squared error is used. Anomalies are marked when the residual exceeds an adaptive threshold (e.g., 3 times the moving average standard deviation). For continuous frame recognition results in the video stream, a majority voting mechanism is used to determine the final state. For example, a green light status is confirmed only if at least 3 out of 5 consecutive frames are identified as "green," effectively suppressing instantaneous recognition errors.
[0115] Vehicle perception data is often missing due to occlusion, changes in lighting, and other reasons. The following data completion strategies can be adopted to address different missing scenarios:
[0116] Short-term missing data (<3 seconds): Linear interpolation or completion methods based on signal periodicity are used. For example, if the traffic light cycle is known to be 120 seconds and 2 seconds of data are missing, the current state (red or green) can be inferred based on the cycle characteristics.
[0117] Long-term missing data (≥3 seconds): Marked as invalid data and not completed to avoid introducing excessive errors. The system can switch to relying on roadside or cloud data.
[0118] Time synchronization: Corrects clock deviations in in-vehicle equipment to ensure accurate timestamps. Employs PTP (Precision Time Protocol) or NTP (Network Time Protocol) to achieve millisecond-level synchronization between the in-vehicle system and GPS time, avoiding time base discrepancies between data from different vehicles.
[0119] After undergoing the cleaning process described above, the vehicle perception data provides a reliable foundation for subsequent multi-source heterogeneous data fusion and traffic decision-making.
[0120] 2) Roadside data cleaning
[0121] PC5 communication data typically uses the standardized SPAT (Signal Phase and Timing) message format, containing fields such as all phases within the traffic light intersection, remaining time, and next phase. Message content is generally broadcast according to standard protocols and communication methods, achieving secure data transmission through unified security trust and digital authentication. Data that fails security authentication or has missing required fields is filtered, effectively reducing the impact of abnormal data on subsequent data fusion.
[0122] Signal Strength Monitoring: Received Signal Strength Indication (RSSI) reflects the status of the communication link. When RSSI < -85dBm, the link quality is considered poor, and the data reliability should be lowered. Studies have shown that RSSI is strongly correlated with packet loss rate (correlation coefficient approximately 0.87).
[0123] Error rate detection: Cyclic redundancy check (CRC) is used to detect packet errors. For packets that fail the check, retransmission can be requested or they can be marked as invalid.
[0124] Data freshness assessment: Calculate the difference between message generation time and reception time (i.e., end-to-end latency). When the latency is >100ms, the data freshness is considered insufficient, especially when the remaining time is short (<5 seconds).
[0125] Packet loss monitoring: Real-time statistical packet continuity is monitored. Communication quality is considered unreliable after two consecutive packet losses, and data is considered usable after three consecutive packets are received. Furthermore, in the case of continuous data transmission, packet loss is monitored based on the message sequence number (sequenceNumber) incrementing within the range of 0-127, and abnormal sequenceNumber values are discarded.
[0126] Redundant data elimination
[0127] Message deduplication: Identify and discard duplicate messages based on the message sequence number and traffic light ID.
[0128] Incremental updates: Only fields that have changed since the last reception are processed, reducing processing overhead. For example, when only the remaining time is updated, only time-related parameters need to be recalculated.
[0129] Sliding window aggregation: Aggregates multiple messages from the same traffic light within a short time window (e.g., 1 second) and takes the latest or average value of each field.
[0130] 3) Cloud-based data cleaning
[0131] Traffic light data distributed by cloud platforms is typically a high-level product resulting from the integration of multi-source information by traffic management centers, possessing global and decision-support characteristics. While this type of data generally undergoes preliminary processing, it still suffers from issues such as network transmission delays, information asynchrony, and data aggregation errors, requiring specialized cleaning processes to ensure its quality.
[0132] Cloud platform data is delivered via cellular V2N networks, which presents transmission latency issues, especially during cross-regional scheduling.
[0133] Latency detection and time alignment: End-to-end latency is calculated by comparing the generation and reception timestamps in the data packets. When the latency is below a threshold (e.g., 500ms), a compensation mechanism is activated.
[0134] Traffic light status prediction: For time-series data with significant delays, linear prediction or compensation algorithms based on signal period models are used. For example, if the red light is known to last 30 seconds, and the received data is delayed by 2 seconds, and the original data indicates "10 seconds remaining on the red light," then it is corrected to "8 seconds remaining on the red light."
[0135] Heartbeat mechanism and clock synchronization: The platform sends a heartbeat signal periodically (e.g., every 1 second), and the vehicle uses this signal to calibrate its local clock deviation, ensuring time synchronization accuracy within 50ms. NTP (Network Time Protocol) combined with PTP (Precision Time Protocol) can achieve microsecond-level synchronization.
[0136] 4) Data quality assessment methods
[0137]
[0138] The steps for constructing a comprehensive scoring model based on the Analytic Hierarchy Process (AHP) are as follows:
[0139] Constructing the judgment matrix: Ten domain experts were invited to compare each quality dimension pairwise to construct the judgment matrix. For example, for autonomous driving applications, accuracy was considered slightly more important than timeliness (weight ratio 3:1).
[0140] Calculate indicator weights: Calculate the weights of each dimension using the eigenvector method. Typical values are:
[0141] accuracy 40%
[0142] consistency 25%
[0143] Timeliness 15%
[0144] Integrity 12%
[0145] Availability 8%
[0146] Indicator normalization: Normalizing indicators with different dimensions to the range of 0-1, for example:
[0147] Accuracy: Use the original value directly (e.g., 98% → 0.98)
[0148] Delay: Inverse S-shaped function mapping is used (delay 100ms → 0.95, 500ms → 0.60)
[0149] Completeness: Linear mapping (90% → 0.90)
[0150]
[0151] The basic information and scoring information of the traffic light status for each data source i were obtained using the method described above. .
[0152] Traffic light information obtained via PC5 or V2N may include extended traffic light information, such as the light color and duration for the next phase of each phase. This information allows the HMI to maintain accurate light color status even during brief data loss when light colors change, and ensures alignment with current traffic light data after data recovery. This further reduces data issues related to abnormal traffic light display.
[0153] S03: Multi-source data fusion
[0154] Multi-source heterogeneous data fusion mainly involves fusing traffic light data perceived by vehicles, traffic light data from roadside communication, and traffic light data from platform communication.
[0155] The fusion method includes prioritizing the use of basic traffic light data based on data quality, and using the highest-priority basic data as the basis for updating the current data source. Extended traffic light data is used on an "available if available, not available if not" basis. When both the roadside and platform have phase information for the next phase, the cloud-based extended traffic light information is used first, and the validity and timestamp of the extended data are updated when updating the extended traffic light information.
[0156] 1) Traffic light data update strategy
[0157] Once the latest traffic light data is obtained for the first time, the traffic light data for the current phase is updated to the system traffic light data, and the traffic light self-update strategy is enabled, recording the initial timestamp as a baseline reference.
[0158] When the current traffic light data is not obtained for the first time, compare the current countdown time and light color of the system. If they are consistent, do not update, but update the timestamp of the system traffic light data.
[0159] If there is a discrepancy, that is, if the current traffic light data and the system traffic light data change, it is assumed that the current data has been updated. If the current traffic light countdown is not 1 second, it is determined whether the countdown data before and after the traffic light is a whole second difference. If the traffic light countdown before and after the current data is not a whole second difference, it indicates that the current system traffic light countdown is abnormal. The original self-updating data starting point needs to be updated and aligned with the current external traffic light time. The current traffic light data source data is used to update the current system traffic light time, and the system traffic light data timestamp is updated at the same time.
[0160] 2) Traffic light data self-update strategy
[0161] After the initial data acquisition, the system starts a timer that displays the usage time per second and updates the system's traffic light status timer. Currently, the timer has reached its maximum. If no data is received from an external source when the time is >=1s, it is considered that there is an abnormal delay in the current traffic light data and the data cannot be updated through step 1). In this case, the system traffic light countdown adopts a self-update strategy, automatically updates the countdown status, the traffic light color of each phase remains unchanged, the traffic light countdown is automatically decremented by 1, and the system basic data update time is updated.
[0162] When the countdown timer for a traffic light is 1, it is assumed that the countdown for that light color in the current phase is about to end. Therefore, a check is performed to determine if the countdown information for the next traffic light phase is valid.
[0163] If effective, start the countdown for the traffic lights in the next phase, update the current colors and countdowns of all traffic lights, and disable the countdown for the traffic lights in the next phase.
[0164] If extended traffic light information cannot be obtained at the moment, and the light color and countdown of the next phase cannot be obtained, the current phase state will not be updated, the current light color will be maintained, the traffic light countdown will be 1, and the maximum duration will be 3 seconds, after which a data timeout warning will be triggered.
[0165] 3) Data delay compensation update
[0166] To ensure the lowest possible delay error between the HMI display and the actual display time, and to fully consider the impact of end-to-end communication delays in the traffic light data transmission process, a delay compensation strategy is added to the self-update strategy. This strategy compensates for the second jump time based on the original traffic light cycle jump time, allowing the traffic light time to jump ahead of time, thus ensuring that the HMI jump time is as aligned as possible with the actual traffic light time.
[0167] Depending on the data source, the estimated communication latency may vary slightly. Therefore, the self-update logic performs corresponding latency compensation on the traffic light data. For data with a latency less than 500ms, latency compensation is performed in the self-update strategy. The corresponding latency compensation time is shortened during the initial execution time timing, i.e., the timing time becomes... = The timer then returned to normal. This means that communication delay compensation for the current traffic light time can be achieved.
[0168] Data with excessively high communication latency will receive a low score in the data quality assessment process and will generally not be used with high priority. If the latency is too high, it may result in whole-second errors, which will be considered in the data update strategy. In such cases, poor data quality, unstable data updates, and second skipping may occur.
[0169] When a traffic light color changes and extended traffic light information is not obtained, the countdown of the last second will be extended until the traffic light data is updated in the next second, and a delay compensation will be performed again on the first time after the color change.
[0170] 4) Data source swapping
[0171] When the current system traffic light data time exceeds the valid usage time (3s), the system invalidates the current traffic light data and selects the second-highest score traffic light data source from the backup data source to update the traffic light data.
[0172] S04: HMI Data Display
[0173] At regular intervals (every 500ms), send valid traffic light status information from within the system to the HMI, including the current light color, countdown timer, data source identifier (e.g., Vision / RSU / Cloud), and data reliability indicator (high / medium / low, based on data quality score).
[0174] Real-time push notifications for abnormal statuses (such as self-update activation, signal source loss, etc.).
[0175] Time smoothing: The countdown display uses an interpolation algorithm to avoid abrupt changes;
[0176] State transition animation: Add a gradient effect when the phase changes to enhance the driving experience.
[0177] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.
Claims
1. A method for optimizing multi-source heterogeneous traffic light data based on vehicle-road-cloud architecture, characterized in that: The specific steps of the optimization method based on vehicle-road-cloud multi-source heterogeneous traffic light data fusion are as follows: S01: Traffic light data collection: There are three ways to collect traffic light data: using cameras to perceive and identify traffic lights, using V2X short-range communication to obtain traffic light data at intersections, and using cloud-based traffic light data services to obtain traffic light data. The first method uses a vehicle-facing camera to identify the light color status and countdown information of the target light pole in real time. Through continuous periodic monitoring, it records the maximum red / green / yellow light duration for each turning phase, and corrects the total countdown duration and phase calibration in the next cycle to generate a complete periodic phase timing sequence. The second method receives V2X broadcast messages through the PC5 interface, parses the SPAT and MAP data in them, matches the current intersection ID, road segment ID, lane ID and phase ID based on the vehicle location and MAP data, and then extracts the real-time status information of the corresponding light group through the phase index. The third method establishes an interactive channel with the traffic cloud platform through cellular network (V2N). Vehicles report their own position, heading angle and other motion status information in real time. The platform determines the target intersection and the direction of the approach lane based on road segment-level map matching. S02: Data Cleaning Traffic light data is a core element of intelligent transportation systems, and its quality directly affects the accuracy of traffic signal control and road safety. Given the multi-source and heterogeneous nature of traffic light data, it is necessary to establish a systematic data cleaning process and quality assessment system. The data has different characteristics, which also brings different data quality problems, requiring systematic cleaning and quality assessment. 1) Vehicle-sensing traffic light data cleaning: Deep learning-based methods can effectively optimize traffic light status data. By using an LSTM prediction model based on historical normal traffic light status changes, the normal variation patterns of traffic light color, position, and timing are described. The real-time recognition results are compared with the model predictions, and residual scores are calculated. For color recognition, classification cross-entropy loss is used, and for position and timing data, mean squared error is used. When the residual exceeds an adaptive threshold, it is marked as an anomaly. For the recognition results of consecutive frames in the video stream, a majority voting mechanism is used to determine the final state. Vehicle perception data is often missing due to occlusion, changes in lighting, and other reasons. The following data completion strategies can be adopted for different missing scenarios: Short-term missing data (<3 seconds): Use linear interpolation or a completion method based on the signal periodicity. For example, if the traffic light cycle is known to be 120 seconds and 2 seconds of data are missing, the current state (red or green) can be inferred based on the cycle characteristics. Long-term missing data (≥3 seconds): Marked as invalid data and not completed to avoid introducing excessive errors. The system can switch to relying on roadside or cloud data; Time synchronization: Correct the clock deviation of the vehicle equipment to ensure the accuracy of the timestamp. Use PTP or NTP to achieve millisecond-level synchronization between the vehicle system and GPS time, providing a reliable foundation for subsequent multi-source heterogeneous data fusion and traffic decision-making. 2) Roadside data cleaning: Signal strength monitoring: Receive signal strength indication, i.e. RSSI, reflects the status of the communication link. When RSSI < -85dBm, the link quality is considered poor and the data reliability should be reduced. Bit error rate detection: Cyclic redundancy check is used to detect data packet errors. For data packets that fail the check, retransmission can be requested or they can be marked as invalid. Data freshness assessment: Calculate the difference between message generation time and reception time. When the delay is >100ms, the data freshness is considered insufficient, especially when the remaining time is short (<5 seconds). Packet loss monitoring: Real-time statistical packet continuity. When two packets are lost consecutively, the communication quality is considered unreliable. When three packets are received consecutively, the data is considered usable. In the case of continuous data, the data packets are monitored based on the message sequence number increasing in the range of 0-127, and outliers are removed. Redundant data elimination: Message deduplication: Identify and discard duplicate messages based on message sequence number and traffic light ID; Incremental update: Only fields that have changed relative to the previous reception are processed, reducing processing overhead. When only the remaining time is updated, only time-related parameters need to be recalculated. Sliding window aggregation: Aggregates multiple messages from the same traffic light within a short time window, taking the latest or average value of each field; 3) Cloud-based data cleaning: Cloud platform data is delivered via cellular V2N networks, which presents transmission latency issues, especially during cross-regional scheduling. Delay detection and time alignment: The end-to-end delay is calculated by comparing the generation timestamp and the reception timestamp in the data packet. When the delay is lower than the threshold, the compensation mechanism is activated. Traffic light status prediction: For time-series data with significant delays, linear prediction or compensation algorithms based on signal period models are used. Heartbeat mechanism and clock synchronization: The platform periodically sends heartbeat signals, and the vehicle uses these signals to calibrate its local clock deviation, ensuring time synchronization accuracy within 50ms. NTP combined with PTP can achieve microsecond-level synchronization. 4) Data quality assessment methods: The steps for constructing a comprehensive scoring model based on the analytic hierarchy process are as follows: Constructing the judgment matrix: Ten domain experts were invited to compare the quality dimensions pairwise to construct the judgment matrix. For autonomous driving applications, accuracy was considered slightly more important than timeliness, with a weight ratio of 3:
1. S03: Multi-source data fusion Multi-source heterogeneous data fusion mainly involves fusing traffic light data perceived by vehicles, traffic light data from roadside communication, and traffic light data from platform communication. The fusion method includes prioritizing the use of basic traffic light data based on data quality, using the highest priority basic data as the basis for updating the current data source, and using extended traffic light data according to the strategy of using it only when available and not using it when not available. When both the roadside and the platform have phase information for the next stage, the extended traffic light information in the cloud is used first. When updating the extended traffic light information, the validity and update timestamp of the extended data are updated. 1) Traffic light data update strategy: Once the latest traffic light data is obtained for the first time, the traffic light data for the current phase is updated to the system traffic light data, and the traffic light self-update strategy is enabled, recording the initial timestamp as a baseline reference. When the current traffic light data is not obtained for the first time, compare the current countdown time and light color of the system. If they are consistent, do not update, but update the timestamp of the system traffic light data. If there is a discrepancy, that is, when the current traffic light data and the system traffic light data change, it is assumed that the current data has been updated. If the current traffic light countdown is not 1 second, it is determined whether the countdown data before and after the traffic light is a whole second difference. If the traffic light countdown before and after the current data is not a whole second difference, it indicates that the current system traffic light countdown is abnormal. The original self-updating data starting point needs to be updated and aligned with the current external traffic light time. The current traffic light data source data is used to update the current system traffic light time, and the system traffic light data timestamp is updated at the same time. 2) Traffic light data self-update strategy: After the initial data acquisition, the system started updating the usage time and system traffic light status timer every second. Currently, the timer is full. If no data is received from an external source when the time is >=1s, it is considered that there is an abnormal delay in the current traffic light data and the data cannot be updated through step 1). In this case, the system traffic light countdown adopts a self-update strategy, automatically updates the countdown status, the traffic light color of each phase remains unchanged, the traffic light countdown is automatically decremented by 1, and the system basic data update time is updated. When the countdown of a traffic light is 1, it is considered that the countdown of that light color in the current phase is about to end. Then, it is checked whether the countdown information of the traffic light in the next phase is valid. If it is valid, the countdown of the traffic light in the next phase is started, all traffic light colors and countdowns are updated, and the countdown of the traffic light in the next phase is set to invalid. If extended traffic light information cannot be obtained at the moment, and the light color and countdown of the next phase cannot be obtained, the current phase state will not be updated, the current light color will be maintained, the traffic light countdown will be 1, and the maximum duration will be 3 seconds, after which a data timeout warning will be triggered. 3) Data delay compensation update: To ensure the lowest possible delay error between the HMI display and the actual display time, and to fully consider the impact of end-to-end communication delay in the traffic light data transmission process, a delay compensation strategy is added to the self-update strategy. This strategy compensates for the second jump time based on the original traffic light cycle second jump time, that is, it makes the traffic light time jump second earlier, ensuring that the HMI second jump time is as aligned as possible with the traffic light time on site. Depending on the data source, the estimated communication latency may vary slightly. Therefore, the self-update logic performs corresponding latency compensation on the traffic light data. For data with a latency less than 500ms, latency compensation is performed in the self-update strategy. The corresponding latency compensation time is shortened during the initial execution time timing, i.e., the timing time becomes... = The timer then returned to normal. This means that communication delay compensation for the current traffic light time can be achieved; Data with excessively high communication latency will be given a low score in the data quality assessment process and will generally not be used with high priority. If the latency is too high, there may be an error of an integer second. The data update strategy will be updated according to the error of an integer second. In this case, the data quality will be poor, the data update will be unstable, and the phenomenon of skipping seconds will occur. When a traffic light color changes and extended traffic light information is not obtained, the countdown of the last second will be extended until the traffic light data is updated in the next second, and a delay compensation will be performed again on the first time after the color change. 4) Data source switching: When the current system traffic light data time exceeds 3 seconds of valid use, the system will invalidate the current traffic light data and select the traffic light data source with the second score from the backup data source to update the traffic light data; S04: HMI Data Display: Every 500ms, the system sends valid traffic light status information, current light color, countdown, data source identifier, data reliability indicator (high / medium / low), and data quality score to the HMI. Real-time push notifications for abnormal statuses, automatic update activation, and signal source loss detection; Time smoothing: The countdown display uses an interpolation algorithm to avoid abrupt changes; State transition animation: Add a gradient effect when the phase changes to enhance the driving experience.
2. The method for optimizing multi-source heterogeneous traffic light data based on vehicle-road-cloud as described in claim 1, characterized in that: In step SO1, the first method further categorizes and processes light clusters based on their type: Disc lights: Identify the overall traffic status of the approach lane, including straight ahead, left turn, right turn, and U-turn; the countdown timer remains consistent for all directions. Arrow lights: Identify the independent light color status and countdown for each direction of traffic by following the turn indicator.
3. The method for optimizing multi-source heterogeneous traffic light data fusion based on vehicle-road-cloud as described in claim 1, characterized in that: In step SO1, in the first method, SPAT represents the phase and time of the traffic light. The countdown information in the SPAT data supports two expression mechanisms: Relative Time Mode: Directly provides the current phase light color, remaining duration, and countdown and duration for the start and end of the next phase; Absolute timestamp mode: Based on UTC timestamps, the start time, theoretical end time, and most likely end time of the current phase are marked, and can be extended to the start and end timestamps of the next phase; The two modes are essentially the same: both map phase timing through time parameters. The only difference is the time base. If the SPAT data contains the start and end times of the next phase, whether in relative or absolute form, then the current traffic light information is determined to have complete phase timing, and the maximum duration of each phase light color state is recorded synchronously.
4. The method for optimizing multi-source heterogeneous traffic light data fusion based on vehicle-road-cloud as described in claim 1, characterized in that: In step SO1, in the first method, the following data is obtained through the phase list index associated with the inlet channel: Real-time phase status: The light colors and countdown information for each direction of traffic at the current approach lane; Extended timing data: If the platform supports it, synchronously obtain forward-looking information such as the pre-switching light color and duration of the next phase; The cloud platform will distribute the integrated traffic light data to the vehicle terminal via V2N (UU), and the vehicle equipment will complete the data parsing and status update.
5. The method for optimizing multi-source heterogeneous traffic light data fusion based on vehicle-road-cloud as described in claim 1, characterized in that: Calculate indicator weights: Calculate the weights of each dimension using the eigenvector method. Typical values are: accuracy 40%; consistency 25%; Timeliness 15%; Integrity 12%; Availability 8%; Indicator normalization: Normalizing indicators with different dimensions to the range of 0-1. Accuracy: Raw values were used directly (98% → 0.98); Delay: Inverse S-curve function mapping is used (delay 100ms → 0.95, 500ms → 0.60); Completeness: Linear mapping (90% → 0.90); The basic information and scoring information of the traffic light status for each data source i were obtained using the method described above. .
Citation Information
Cited By
Dynamic traffic light information service method and system for intelligent network connection vehicle
CN121921987A