Dynamic traffic light information service method and system for intelligent network connection vehicle

Abstract

The invention discloses a dynamic traffic light information service method and system for an intelligent network connection vehicle, and belongs to the technical field of vehicle networking information service. The method comprises the following steps: performing real-time compensation and phase calculation on a historical timestamp issued by a cloud through pre-calibrated full-link system time delay, and reconstructing a light color state and countdown; establishing double buffer areas of the current map data and the backup old map data, and when the real-time positioning is not matched with the latest map, automatically switching to the backup old map data for service; the communication request is bound with the vehicle motion state, and cloud query is activated only when the vehicle runs. The system comprises a positioning and data acquisition module, a service scheduling control module, a dynamic state calculation module, a map matching and fault tolerance module and a CAN communication packaging module. According to the method, the problem of information lag caused by network delay is solved, the service continuity and robustness of the vehicle in a positioning easy-drifting scene are improved, on-demand distribution of network traffic and computing resources is realized, and the system power consumption is reduced.

Description

Technical Field

[0001] This invention relates to the field of vehicle networking information service technology, and more specifically to a dynamic traffic light information service method and system for intelligent connected vehicles. Background Technology

[0002] With the development of intelligent connected vehicles, providing vehicles with traffic light information (including light color, countdown, phase, etc.) through cloud services has become a key technology for improving traffic efficiency and driving safety.

[0003] However, existing dynamic traffic light information service solutions have the following main drawbacks: 1. Insufficient real-time performance: Existing service methods usually directly forward the light status and countdown data returned from the cloud with past timestamps, without considering the inherent network transmission delay and vehicle system processing delay in the data queried from the cloud and sent to the vehicle. This results in the information obtained by the driver being out of sync with the actual intersection conditions, posing a safety hazard, and also cannot support advanced applications such as speed guidance.

[0004] 2. Poor reliability: Vehicle GPS positioning has errors, and the matching with high-precision maps may deviate. Existing service methods will directly interrupt the service or provide error information when the vehicle's location deviates briefly from the map's matching route, lacking an effective fault tolerance mechanism and resulting in an unstable user experience.

[0005] 3. Low resource utilization: Regardless of whether the vehicle is moving or stationary, most existing service methods use a fixed frequency to send queries to the cloud. When the vehicle is stationary for a long time, a large number of invalid network requests will be generated, wasting communication traffic and computing resources of the vehicle terminal.

[0006] Therefore, there is an urgent need for a traffic light information service method and system that can compensate for system latency, tolerate positioning errors, and intelligently schedule requests. Summary of the Invention

[0007] This invention provides a method and system for providing dynamic traffic light information services for intelligent connected vehicles, aiming to solve the shortcomings of existing traffic light information services, such as insufficient real-time performance, poor reliability, and low resource utilization.

[0008] The present invention adopts the following technical solution: A method for providing dynamic traffic light information services for intelligent connected vehicles, comprising: (1) In the cloud, the historical timestamps sent from the cloud are compensated and phase is calculated in real time by pre-calibrated full-link system latency, and the static data is dynamically reconstructed into the light color status and countdown synchronized with the current time. (2) Establish a dual buffer between the current map data and the backup old map data. When the real-time positioning does not match the latest map, the system will automatically and seamlessly switch to the backup old map data for service. (3) Communication requests are intelligently bound to the vehicle's motion status, and cloud queries are only activated when the vehicle is in motion.

[0009] Specifically, in step (1) above, the following formula is used to compensate for the historical timestamps sent from the cloud in real time: time_delay = current system time + DELAY_TIME – timestamp; Where time_delay represents the calibration delay; DELAY_TIME is the specified end-to-end system delay; and timestamp represents the absolute time when the cloud server generates the current traffic light data packet.

[0010] In a preferred implementation, the phase calculation is as follows: the relative position within the current period is determined by taking the modulo of the total period from time_delay, so as to determine the current phase; the elapsed time and remaining time within the phase are calculated, where: elapsed = time_delay - sum of previous phase periods; remaining = period[i] – elapsed, where period[i] represents the time period from the current phase to the i-th light color.

[0011] For the countdown, it is also necessary to intelligently handle the special value count_down[i] that may be returned by the cloud. If the original count_down[i] is valid, the current countdown is: max(0, count_down[i] - elapsed); if the original count_down[i] is invalid, then remaining is directly used as the countdown estimate; the light color status is directly mapped to the lamp_status[i] corresponding to phase i, that is, the current phase traverses to the i-th light color.

[0012] In a preferred implementation, in step (2) above, if the vehicle location point falls within the dynamic geofence constructed based on the latest cloud data, it is determined that the real-time location and the latest map are successfully matched, and all the original traffic light data are stored in the current map data area for subsequent dynamic calculation; and the complete data copy is immediately written to the backup old map data area.

[0013] In a preferred embodiment, in step (2) above, if the real-time positioning does not match the latest map or the backup old map due to the continuous deviation of the vehicle position, the system enters the safety protection mode and actively suppresses the sending of traffic light information.

[0014] The present invention also provides a system for a dynamic traffic light information service method for the above-mentioned intelligent connected vehicles, comprising: The positioning and data acquisition module is used to perform preliminary validity verification on the raw GNSS data, and to align and package the WGS-84 coordinates with the vehicle speed, heading and high-precision system timestamps to form a real-time vehicle status package. The service scheduling and control module is used to continuously monitor the vehicle speed signal from the CAN bus and strongly couple external service requests with the vehicle's motion dynamics. It wakes up or notifies the traffic light information query thread that is in a blocked state only when the vehicle speed sensor detects a non-zero value and after a certain filtering time. The dynamic state estimation module receives a local high-precision spatiotemporal reference from the positioning and data acquisition module and a raw data packet containing historical timestamps of the traffic light phase plan returned by the cloud service. It performs real-time compensation and phase calculation on the historical timestamps sent from the cloud and outputs the real-time light color status and accurate countdown. The map matching and fault tolerance module is used to receive vehicle coordinates and map matching points and traffic light locations returned from the cloud. It determines the matching degree by calculating the relationship between the vehicle's current location and the dynamic geofence formed by the matching points and traffic light points, and executes a multi-level map matching and progressive fault tolerance mechanism. The system also includes a CAN communication encapsulation module, which translates and encapsulates the semantically clear traffic light information calculated upstream into automotive-grade CAN extended frame data. This data is then sent to a transmission queue and sent to the specified CAN channel by calling the underlying CAN driver interface.

[0015] As can be seen from the above description of the present invention, compared with the prior art, the present invention has the following advantages: 1. The present invention is a dynamic traffic light status real-time estimation mechanism based on end-link latency compensation: instead of simply forwarding historical data from the cloud, it calibrates the end-link system latency and uses traffic light phase cycle data locally to align the historical timestamps from the cloud to the current time of the vehicle, thereby reconstructing the accurate current light color and countdown at the intersection in real time, fundamentally solving the problem of information lag caused by network latency.

[0016] 2. This invention adopts a multi-level map matching and data-driven service fault tolerance method, and introduces a two-layer structure of the current map and the backup old map. When the real-time positioning does not match the latest map information, it can seamlessly switch to the previous set of valid traffic light data for service, which greatly improves the service continuity and robustness in scenarios where positioning is prone to drift, such as complex urban roads, under overpasses, and tunnel exits.

[0017] 3. The present invention provides an intelligent scheduling strategy for service requests based on vehicle motion status. By associating real-time vehicle speed information, cloud queries are triggered only when the vehicle is in motion and automatically paused when the vehicle is stationary. This achieves on-demand allocation of network traffic and computing resources and reduces the overall power consumption of the system. Attached Figure Description

[0018] Figure 1 This is a system framework diagram of the present invention.

[0019] Figure 2 This is a flowchart of the dynamic traffic light status estimation method of the present invention.

[0020] Figure 3 This is a timing diagram of the multi-level map matching and fault-tolerant processing mechanism of the present invention. Detailed Implementation

[0021] Specific embodiments of the present invention will now be described with reference to the accompanying drawings. Many details are described below to provide a comprehensive understanding of the invention; however, those skilled in the art will not need these details to implement the invention. Well-known components, methods, and processes will not be described in detail below.

[0022] This invention systematically solves the three core problems of latency, drift, and resource efficiency in traffic light information services through a tightly coupled hardware and software co-design.

[0023] The system is integrated into the vehicle-mounted telematics unit (TBOX) in either a pre-installed or aftermarket configuration, running as an independent software middleware on a real-time operating system (such as Linux). It is not simply a data pass-through gateway, but a collaborative information processing hub for the vehicle-cloud-road system, possessing intelligent perception, real-time computing, and decision-making capabilities. Its architecture, from top to bottom, can be divided into a data input layer, a core processing layer, a cloud interaction layer, and a data output layer. Modules within each layer collaborate with data flows through clear interfaces.

[0024] Reference Figure 1 The core processing layer of the system includes five highly specialized functional modules: positioning and data acquisition module, service scheduling and control module, dynamic state calculation module, map matching and fault tolerance module, and CAN communication encapsulation module.

[0025] The positioning and data acquisition module acts as the system's sensory nerve endings. It processes two key inputs in parallel using multi-source heterogeneous data fusion technology: first, the NMEA-0183 protocol stream from the GNSS receiver (GPS / BeiDou), resolving latitude, longitude, altitude, and UTC time; second, subscribing to and decoding specific message frames in real-time from the vehicle's CAN bus via SocketCAN or a similar interface (e.g., 0x0CFE6Cxx for vehicle speed, 0x0Cxxx for heading angle). This module performs preliminary validity checks on the raw GNSS data (e.g., signal-to-noise ratio, visible satellite count), aligns and packages the WGS-84 coordinates with vehicle speed, heading, and high-precision system timestamps, forming a unified real-time vehicle status data packet. This data packet is simultaneously and asynchronously pushed to the dynamic status estimation module and the map matching and fault tolerance module, serving as the spatiotemporal reference for all subsequent calculations.

[0026] The service scheduling and control module internally implements a state machine that continuously monitors vehicle speed signals from the CAN bus. Its core logic lies in strongly coupling external service requests with the vehicle's motion dynamics. Only when the vehicle speed sensor detects a non-zero value (g_pos.speed > 0) and this value persists for a certain filtering time (to prevent false triggering due to jitter), will the module set an internal "enable" flag (such as speedFlag) and generate a "trigger signal" event. This event wakes up or notifies the "traffic light information query thread" that is currently blocked. This design fundamentally avoids vehicles sending a large number of invalid requests to the cloud during long periods of parking or traffic congestion, enabling on-demand allocation of network traffic and computing resources, which is particularly suitable for the stringent operating cost requirements of commercial vehicle fleets.

[0027] The dynamic state estimation module receives two asynchronous data streams: one is a local high-precision spatiotemporal reference from the positioning and data acquisition module; the other is a raw data packet (JSON format) containing historical timestamps from the cloud service, representing the "traffic light phase plan". The core of this module is a deterministic algorithm function called `calculate_current_traffic_light`. The input to this function is not only the raw data, but more importantly, a pre-calibrated, configurable system-level constant `DELAY_TIME` (e.g., 650 milliseconds). This constant, experimentally calibrated, precisely characterizes the fixed end-to-end latency from "constructing a request at the TBOX application layer, transmitting it over the network to the cloud server, processing it, returning it over the network, to the TBOX application layer parsing it, and then preparing it for CAN transmission". The function of this dynamic state estimation module is not data forwarding, but rather performing a time and state transformation calculation.

[0028] The map matching and fault tolerance module addresses the spatial uncertainty matching problem between vehicle positioning signals and high-precision map road networks. This module receives vehicle coordinates (first converted from WGS-84 to the State Bureau of Surveying and Mapping GCJ-02 coordinate system for compatibility with domestic map services) and two key geographic elements returned from the cloud: map matching points (representing the algorithm's most likely road location for the vehicle) and traffic light locations (intersection stop line coordinates). Internally, it maintains a double-buffered storage structure, labeled as: current map data and backup old map data. Upon receiving a new cloud response, the module calls a geometric judgment function (such as get_in_map_info) to determine the degree of matching by calculating the relationship between the vehicle's current location and a dynamic geofence (such as an extended rectangular or fan-shaped area) formed by the matching points and traffic light points. If a match is successful, the current area is overwritten with the new data and synchronously copied to the backup area; if a match fails, the automatic rollback logic is triggered, and the previous set of valid data is loaded from the backup area to provide service, thus providing a smooth and uninterrupted service experience in scenarios such as temporary loss of GPS signal (e.g., under tunnels or overpasses) or road switching.

[0029] CAN communication encapsulation module: It translates and encapsulates semantically clear traffic light information (such as the first lane is straight, the current light is green, 12 seconds remain, and the distance to the intersection is 150 meters) calculated from the upstream into automotive-grade CAN extended frame data in strict accordance with the target vehicle model or industry protocol (such as SAEJ2735 V2X message set or OEM custom protocol). For example, each bit of an 8-byte data frame data[8] is defined: the lower 3 bits of data[0] represent the light color (001-red light, 010-green light...), and the higher 4 bits represent the flow direction; data[1] represents the countdown of the flow direction; data[6] and data[7] encode the distance (in units of 0.1 meters) with 16-bit integers. After encapsulation, the data is sent to a transmission queue managed by an independent high-priority real-time thread. This thread sends the message to the designated CAN channel (such as CAN_CHAN1) by calling the underlying CAN driver interface (such as ReqCanDataSnd) at an absolutely strict 500ms cycle, ensuring that the information is injected into the vehicle’s internal network at a stable and predictable pace for use by the instrument panel, head-up display or autonomous driving domain controller.

[0030] This invention also provides a method for providing dynamic traffic light information services for intelligent connected vehicles, comprising: (1) In the cloud, the historical timestamps sent from the cloud are compensated and phase is calculated in real time by pre-calibrated full-link system latency, and the static data is dynamically reconstructed into the light color status and countdown synchronized with the current time. (2) Establish a dual buffer between the current map data and the backup old map data. When the real-time positioning does not match the latest map, the system will automatically and seamlessly switch to the backup old map data for service. (3) Communication requests are intelligently bound to the vehicle's motion status, and cloud queries are only activated when the vehicle is in motion.

[0031] Reference Figure 2 The above step (1) is mainly a closed-loop prediction-correction process based on time synchronization and phase calculation.

[0032] Triggering Conditions and Data Acquisition (Process Start Point): The entire process begins at a decision point that balances energy saving and efficiency—determining whether the vehicle's speed is greater than 0. If not, the system enters a low-power "sleep, waiting for the next cycle" state. This cycle refers to the polling cycle of the judgment logic itself, not a fixed network request cycle. If yes, it triggers "initiating an HTTP request to obtain raw data from the cloud," meaning the request is dynamically generated through the `build_post_body` function, including longitude, latitude, speed, heading, vehicle unique identifier (VIN code), and current UTC timestamp, ensuring the cloud can perform path calculation based on the most accurate instantaneous state.

[0033] End-to-end latency compensation and time alignment (core calculation): The cloud response contains a crucial field—timestamp—which represents the absolute time when the cloud server generated this set of traffic light data packets, typically a UTC second-level timestamp. The latency compensation calculation formula is as follows: time_delay = current system time + DELAY_TIME - timestamp `time_delay` represents the calibration delay, `DELAY_TIME` is the calibrated inherent system delay, and `timestamp` represents the cloud data timestamp. The sum of the current system time and `DELAY_TIME` constitutes a virtual "aligned time point," which is the time at which the data should have been seen if the request and response had been completed instantaneously. Subtracting the cloud data generation time from this "aligned time point" yields `time_delay`, which is the actual, valid time difference from data generation to the present (after compensation). This step resynchronizes the asynchronous, delayed cloud data to the local timeline.

[0034] Phase calculation and real-time state generation (deterministic calculation): After obtaining the accurate time_delay, the algorithm enters the deterministic calculation stage. First, "time_delay modulo the total period", the total period is the sum of the durations of the four phases returned by the cloud (period[0] to period[3]). The modulo operation ensures that no matter how long the delay is (multiple cycle periods), the relative position within the current period can always be located. This operation determines which phase (Phase_i) is currently in.

[0035] Subsequently, the elapsed time (elapsed = time_delay - sum of previous phase periods) and the remaining time (remaining = period[i] - elapsed) within that phase are calculated. For the countdown, the algorithm also needs to intelligently handle special values ​​that may be returned by the cloud (such as 10000 indicating invalidity): if the original count_down[i] is valid, then the current countdown is max(0, count_down[i] - elapsed), and limited to within 255; if invalid, then remaining is directly used as the countdown estimate. The light color status is directly mapped to the lamp_status[i] corresponding to phase i, that is, the current phase traverses to the i-th light color.

[0036] Output: The final output is "real-time light color + precise countdown". This output is completely different from any raw static value returned from the cloud. It is an estimate of the actual state of the intersection at "this moment", dynamically calculated by the local algorithm based on the principle of time synchronization. This achieves a fundamental leap from "transmitting historical data" to "reconstructing the current state".

[0037] Step (2) above is essentially a multi-level map matching and progressive fault-tolerance mechanism. (Refer to...) Figure 3 ,Should Figure 3 It describes the intelligent fault-tolerant decision chain of the system in response to the real-world challenge of location drift, demonstrating the system's resilience from optimal service to security degradation.

[0038] Time 1 (Ideal Condition: Match Successful): When the vehicle's location falls within the dynamic geofence built based on the latest cloud data, the map matching and fault tolerance module determines that the match is successful. At this time, the system is in its optimal working state. It performs two key operations: First, it stores all the original data of the traffic lights (location, phase, timestamp, etc.) into the current map data area for subsequent dynamic calculations; second, it immediately writes a complete copy of this data to the backup old map data area. This backup action is the foundation of fault tolerance, equivalent to establishing a recovery point for the currently known valid state. At the same time, it authorizes the "CAN Transmission Status" to use this latest and most accurate data for calculations and transmission.

[0039] Time 2 (Common Anomaly: New Data Failure, Backup Activated): In real-world road environments, GNSS signals are affected by multipath effects, urban canyon obstruction, etc., which may cause the instantaneous position reported by vehicles to deviate significantly from the actual lane (i.e., "drift point"). In this case, the drift point will cause "new map matching failure." The system's reaction is not to report an error or stop, but to trigger Level 1 fault tolerance: immediately load a set of verified valid data from the "backup old map data" area. Since vehicles are unlikely to traverse several blocks in a short time (e.g., the first few seconds), the intersection topology described by this backup old map data is still highly reliable. The system then performs [further steps] based on this old map data. Figure 2 The system dynamically calculates the light colors and countdown (as time passes, the light colors and countdown must be recalculated) and sends the command "use old data for calculation" afterward. This mechanism ensures uninterrupted service during short-term location failures, with users experiencing virtually no disruption.

[0040] Time 3 (Severe Anomaly: Both Old and New Data are Invalid, Safety Silence): If the vehicle's location continues to deviate due to navigation replanning, entering an uncovered area, or other reasons, resulting in "both old and new maps failing to match," the system enters Level 2 fault tolerance, i.e., safety protection mode. At this time, the system believes it cannot provide any spatially reliable traffic light information. To avoid transmitting potentially completely incorrect guidance to the driver or autonomous driving system (such as traffic light information for another intersection), the system will proactively "suppress transmission." This suppression decision is configurable, for example, triggered when the number of consecutive matching failures (data_used_count) exceeds a threshold (e.g., 2 times).

[0041] The following are specific embodiments of the present invention for urban public transport passenger acquisition vehicles.

[0042] In a city bus or coach, the system of the present invention runs as a daemon on a high-performance vehicle-mounted TBOX, which has 4G / 5G cellular communication, dual-band GNSS, multiple CAN-FD interfaces, and meets IP54 protection level to adapt to harsh installation environments.

[0043] System initialization: After power-on, the system loads the configuration file, initializes the curl library, CAN socket, and mutex (pthread_mutex_t), and creates two core threads: a high-priority, fixed-period (500ms) CAN transmission thread, and a low-priority, event-driven HTTP query management thread. Global data structures such as g_traffic_light_data are cleared.

[0044] Dynamic service cycle: Step A (Status Awareness): The service scheduling control module reads the vehicle speed in real time from the CAN bus. All queries are paused when the vehicle stops at the station.

[0045] Step B (Triggering Interaction with the Cloud): The vehicle starts moving, and the speed > 0 flag is set. HttpPost_TimerThread is awakened and calls SendTrafficLightDataToCan (this function contains the request construction logic). Using the HttpPost_SendRequest function, it sends an HTTPS POST request to the / probe_lamp interface of api.map.baidu.com, carrying the encrypted AK and real-time location.

[0046] Step C (Data Parsing and Storage): Upon receiving the JSON response, the `parse_road_flow_directions` function parses the data and extracts the raw data (timestamp, period, lamp_status, count_down, and two locations). This raw data is written to the global variable `g_traffic_light_data` in a thread-safe manner (with locking), while its `data_valid` flag is set to 1. This stage stores the "raw materials" used for calculation.

[0047] Step D (Periodic Dynamic Calculation and Sending): An independent 500ms timer triggers, calling the SendTrafficLightDataToCan function again. This function performs the following key operation sequence: ① Obtain the latest vehicle location and speed.

[0048] ② Read the raw “raw materials” from g_traffic_light_data.

[0049] ③ Call the core function calculate_current_traffic_light, and combine the current time with DELAY_TIME to calculate the real-time light color and countdown.

[0050] ④ Simultaneously, call get_in_map_info to perform location matching, based on... Figure 3 The fault tolerance logic determines the final data source used for the calculation (new data, old backup, or no data).

[0051] ⑤ Encapsulate the calculation results (light color, flow direction, countdown, distance) into the data[8] array according to the protocol.

[0052] ⑥The TimeServ500ms() function is called to copy data[8] to the T_CAN_SEND_INFO structure and send it to CAN 1 channel via ReqCanDataSnd.

[0053] Error handling and logging: Throughout the process, any network timeouts, JSON parsing errors, or validation failures are recorded in non-volatile memory via the `log_print` function. Simultaneously, the system state is downgraded (e.g., `data_valid` is set to 0) to ensure that basic vehicle functions are not affected. The CAN transmit thread remains running continuously, and can send "no signal" status frames even without valid data to maintain bus communication activity.

[0054] The above are merely specific embodiments of the present invention, but the design concept of the present invention is not limited thereto. Any non-substantial modifications made to the present invention using this concept shall be considered as infringing upon the protection scope of the present invention.

Claims

1. A method for providing dynamic traffic light information services for intelligent connected vehicles, characterized in that, Includes the following steps: (1) In the cloud, the historical timestamps sent from the cloud are compensated and phase is calculated in real time by pre-calibrated full-link system latency, and the static data is dynamically reconstructed into the light color status and countdown synchronized with the current time. (2) Establish a dual buffer between the current map data and the backup old map data. When the real-time positioning does not match the latest map, the system will automatically and seamlessly switch to the backup old map data for service. (3) Communication requests are intelligently bound to the vehicle's motion status, and cloud queries are only activated when the vehicle is in motion.

2. The method for providing dynamic traffic light information services for intelligent connected vehicles as described in claim 1, characterized in that: In step (1), the following formula is used to compensate for the historical timestamps sent from the cloud in real time: time_delay = current system time + DELAY_TIME – timestamp; Where time_delay represents the calibration delay; DELAY_TIME is the specified end-to-end system delay; and timestamp represents the absolute time when the cloud server generates the current traffic light data packet.

3. The method for providing dynamic traffic light information services for intelligent connected vehicles as described in claim 2, characterized in that, The phase calculation is as follows: the relative position within the current period is located by taking the modulo of the total period by time_delay, so as to determine the current phase; the elapsed time and remaining time within the phase are calculated, where: elapsed = time_delay - sum of previous phase periods; remaining = period[i] – elapsed, period[i] represents the time period for the current phase to traverse to the i-th light color.

4. The method for providing dynamic traffic light information services for intelligent connected vehicles as described in claim 3, characterized in that: For the countdown, it is also necessary to intelligently handle the special value count_down[i] that may be returned by the cloud. If the original count_down[i] is valid, then the current countdown is: max(0, count_down[i] - elapsed); if the original count_down[i] is invalid, then remaining is used directly as the countdown estimate. The light color status is directly mapped to the lamp_status[i] corresponding to phase i, that is, the current phase traverses to the i-th light color.

5. The method for providing dynamic traffic light information services for intelligent connected vehicles as described in claim 1, characterized in that: In step (2), if the vehicle location point falls within the dynamic geofence constructed based on the latest cloud data, it is determined that the real-time location and the latest map are successfully matched, and all the original traffic light data are stored in the current map data area for subsequent dynamic calculation. And immediately write a complete copy of the data to the backup old map data area.

6. The method for providing dynamic traffic light information services for intelligent connected vehicles as described in claim 1, characterized in that: In step (2), if the real-time positioning does not match the latest map or the backup old map due to the continuous deviation of the vehicle position, the system will enter the safety protection mode and actively suppress the sending of traffic light information.

7. A system for a dynamic traffic light information service method for intelligent connected vehicles as described in any one of claims 1 to 6, characterized in that, include: The positioning and data acquisition module is used to perform preliminary validity verification on the raw GNSS data, and to align and package the WGS-84 coordinates with the vehicle speed, heading and high-precision system timestamps to form a real-time vehicle status package. The service scheduling and control module is used to continuously monitor the vehicle speed signal from the CAN bus and strongly couple external service requests with the vehicle's motion dynamics. It wakes up or notifies the traffic light information query thread that is in a blocked state only when the vehicle speed sensor detects a non-zero value and after a certain filtering time. The dynamic state estimation module receives a local high-precision spatiotemporal reference from the positioning and data acquisition module and a raw data packet containing historical timestamps of the traffic light phase plan returned by the cloud service. It performs real-time compensation and phase calculation on the historical timestamps sent from the cloud and outputs the real-time light color status and accurate countdown. The map matching and fault tolerance module is used to receive vehicle coordinates and map matching points and traffic light locations returned from the cloud. It determines the matching degree by calculating the relationship between the vehicle's current location and the dynamic geofence formed by the matching points and traffic light points, and executes a multi-level map matching and progressive fault tolerance mechanism. The system also includes a CAN communication encapsulation module, which translates and encapsulates the semantically clear traffic light information calculated upstream into automotive-grade CAN extended frame data. This data is then sent to a transmission queue and sent to the specified CAN channel by calling the underlying CAN driver interface.

Images