Vehicle-mounted time sequence information bidirectional synchronization system

Abstract

The application provides a vehicle-mounted time sequence information bidirectional synchronization system, wherein a first node is configured to maintain first time sequence information based on a first time source and periodically broadcast the first time sequence information with a first identifier through a CAN bus; a second node is configured to generate second time sequence information based on a second time source independent of the first node, listen to the first time sequence information broadcast by the first node, compare the second time sequence information with the first time sequence information, and send a calibration message containing the second time sequence information to the first node through the CAN bus with a second identifier different from the first identifier when the comparison result meets a preset condition. Through the application, bidirectional closed-loop automatic deviation correction of the whole vehicle time sequence is realized, and when the time or time zone of the main timing node deviates, the supervisory node actively calibrates in reverse, so that the whole vehicle time sequence disorder problem can be eliminated without hardware modification.

Description

Technical Field

[0001] This application relates to the field of vehicle timing management technology, and more specifically, to a two-way synchronization system for vehicle timing information. Background Technology

[0002] In the current vehicle CAN bus timing architecture, the TBOX or dashcam acts as the sole time synchronization master node. After acquiring the standard time via GPS and network, it broadcasts it unidirectionally to the CAN bus in the form of periodic messages for synchronization by all downstream nodes such as the cockpit domain controller, instrument cluster, and body ECU. This unidirectional time synchronization architecture has significant drawbacks: all vehicle ECUs can only passively receive time information. If the TBOX itself malfunctions due to RTC hardware drift, accidental erasure of time zone parameters, or firmware abnormalities, it can cause systemic problems throughout the vehicle, such as instrument display errors, maintenance timing deviations, log timestamp errors, and abnormal vehicle network reporting. Due to the lack of reverse verification and correction mechanisms, these errors cannot be automatically recovered or are recovered lag-wise on the TBOX side, often requiring hardware replacement or factory repair to resolve. Summary of the Invention

[0003] In view of this, the purpose of this application is to provide a vehicle-mounted timing information bidirectional synchronization system, which aims to overcome at least one of the above-mentioned defects.

[0004] In one aspect, this application provides a vehicle-mounted time-series information bidirectional synchronization system, including a first node and a second node; The first node is configured to maintain first timing information based on a first time source and periodically broadcast the first timing information via a CAN bus using a first identifier; The first node is also configured to receive a calibration message from the second node, including second timing information, to update the first timing information according to the second timing information, and to resume periodic broadcasting with the first identifier after the update is completed; The second node is configured to generate the second timing information based on a second time source independent of the first node, listen to the first timing information, compare the second timing information with the first timing information, and when the comparison result meets a preset condition, send a calibration message containing the second timing information to the first node through the CAN bus with a second identifier that is different from the first identifier, and stop sending the calibration message after confirming that the first node has updated according to the second timing information.

[0005] In one possible implementation, the preset conditions include: The difference between the second system time in the second timing information and the first system time in the first timing information exceeds a preset threshold, and the number of consecutive cycles exceeding the threshold reaches a preset number. Alternatively, the second time zone parameter in the second timing information may be inconsistent with the first time zone parameter in the first timing information.

[0006] In one possible implementation, the first identifier and the second identifier are different CAN message identifiers. The message sent by the first node with the first identifier is received by all nodes in the vehicle, and the calibration message sent by the second node with the second identifier is only parsed and processed by the first node.

[0007] In one possible implementation, the second node confirms that the first node has been updated by at least one of the following methods: The second node detects that the first timing information broadcast by the first node through the first identifier has been updated to be consistent with the second timing information; The second node receives the response frame sent by the first node after completing the update; When the first node resumes periodic broadcasting with the first identifier, it carries a calibration confirmation flag in the first timing information of the broadcast. The second node confirms that the first node has been updated by recognizing the calibration confirmation flag.

[0008] In one possible implementation, the first node is further configured to: Before updating the first timing information of this node according to the second timing information, the second timing information in the calibration message is validated for legality. The validation includes checking whether the second timing information exceeds a preset reasonable value range. During the update, if the deviation between the current first system time and the second system time exceeds a preset jump threshold, the system time will be smoothly transitioned to the second system time through gradual adjustment. During the update, the updated system time and time zone parameters are synchronously written to the RTC real-time clock of this node to correct the timing deviation of the RTC real-time clock caused by power failure or drift.

[0009] In one possible implementation, the second time source includes a plurality of independent time sources; The second node is further configured as follows: The validity of each of the multiple independent time sources is verified. The time sources that pass the verification are arbitrated according to a preset priority, and the timing information output by the time source with the highest priority is used as the second timing information.

[0010] In one possible implementation, the second node is further configured as follows: If the first node is not confirmed to have been updated within a preset timeout period after the calibration message is sent, the calibration message is resent until the update is confirmed to be successful or the preset resentment limit is reached. If the second time source fails during the calibration process, the transmission of the calibration message will be stopped, and the first timing information broadcast by the first node will be used as the timing reference for this node.

[0011] In one possible implementation, the initial values ​​of the first time zone parameter and / or the second time zone parameter are configured and stored permanently via the UDS diagnostic interface; The second node is further configured as follows: A time zone setting interface is provided, which receives the time zone setting manually entered by the user, and uses the time zone manually set by the user as the second time zone parameter to trigger reverse synchronization to the first node.

[0012] In one possible implementation, the remaining nodes of the vehicle are configured as follows: Only messages with the first identifier are identified and received, while messages with the second identifier are ignored, so that the transmission and reception of the calibration message only occurs between the first node and the second node.

[0013] In one possible implementation, the second node is further configured as follows: When the first timing information broadcast by the first node is detected to revert to the preset default value, the second timing information is resent to the first node via the second identifier.

[0014] This application provides a two-way synchronization system for vehicle timing information, comprising a first node and a second node. The first node is configured to maintain first timing information based on a first time source and periodically broadcast the first timing information via a CAN bus using a first identifier. The second node is configured to generate second timing information based on a second time source independent of the first node, listen to the first timing information broadcast by the first node, compare the second timing information with the first timing information, and when the comparison result meets preset conditions, send a calibration message containing the second timing information to the first node via the CAN bus using a second identifier different from the first identifier. The second node stops sending calibration messages after confirming that the first node has updated according to the second timing information. This application achieves bidirectional closed-loop automatic correction of the vehicle's timing. When the time or time zone of the main time synchronization node deviates, the supervisory node actively performs reverse calibration, eliminating the vehicle's timing disorder problem without hardware modifications.

[0015] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is one of the structural schematic diagrams of a vehicle-mounted timing information bidirectional synchronization system provided in an embodiment of this application; Figure 2 This is a second schematic diagram of the structure of a vehicle-mounted timing information bidirectional synchronization system provided in an embodiment of this application; Figure 3 This is a flowchart of the bidirectional synchronization method for vehicle timing information provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.

[0019] First, the applicable application scenarios of this application are introduced. This application can be applied to the technical field of vehicle timing management.

[0020] Research has revealed that the vehicle's CAN bus time reference is typically provided by a TBOX or dashcam as the sole master time synchronization node. The TBOX or dashcam obtains the standard time through network time and GPS positioning time, and uses its own RTC clock for power-off timing. Upon power-up, it synchronizes the RTC time to the system and then sends it to the CAN bus in periodic messages, allowing all downstream nodes, including the cockpit domain controller, instrument cluster, body ECU, and chassis ECU, to synchronize their time and time zone information. Current industry solutions employ a one-way time synchronization architecture, where the TBOX or dashcam sends the time and time zone to the vehicle's CAN bus, and all domain controllers and ECUs passively receive this information. In typical vehicle time synchronization scenarios, the accuracy of timing relies entirely on the external signal from the TBOX and the precision of the RTC hardware.

[0021] Existing one-way CAN time synchronization solutions suffer from unavoidable technical flaws in numerous real-world vehicle scenarios. Since the vehicle's ECUs can only receive time from the TBOX or recorder in one direction, a malfunction in the reference source can trigger systemic problems across the entire vehicle, including incorrect instrument panel time display, discrepancies in vehicle maintenance timing, incorrect timestamps in the vehicle logs, abnormal timing of vehicle network reporting, and time zone mismatches leading to discrepancies between the vehicle's calendar and regional time. While TBOX time source errors are typically resolved by the TBOX itself, any problem may result in its inability to recover or delayed recovery. The risk of unilateral anomalies under a one-way time synchronization architecture cannot be eliminated through a single-way mechanism. Existing solutions only support time zone transmission in one direction. When the vehicle travels across regions, the TBOX time zone is incorrectly fixed, or the RTC loses time zone parameters, the vehicle cannot automatically restore the correct time zone. Traditional error correction solutions rely on replacing TBOX hardware, optimizing the RTC circuit, and adding a backup clock module. These hardware modifications are costly and require long platform adaptation cycles, making it impossible to solve the problem at low cost through pure software. Furthermore, when vehicles are sold overseas without TBOX or recorders, the vehicle directly loses its time and time zone source.

[0022] Based on this, this application provides a two-way synchronization system for vehicle timing information, breaking away from the traditional single master node timing architecture of TBOX or recorder. It leverages the advantages of multi-source timing from the cockpit domain controller to construct a two-way closed-loop timing system with forward timing from the TBOX or recorder and reverse calibration from the cockpit domain controller. In scenarios where TBOX time or time zone fails, drifts, or becomes disordered, the cockpit domain controller actively outputs standard time and standard time zone to reverse-correct the CAN bus reference, achieving automatic time and time zone correction for the entire vehicle without hardware modifications. This solves the common problem of one-way timing errors and time zone anomalies in the entire vehicle.

[0023] Please see Figure 1 , Figure 1 This is one of the structural schematic diagrams of a vehicle-mounted timing information bidirectional synchronization system provided in an embodiment of this application. The vehicle-mounted timing information bidirectional synchronization system provided in this embodiment includes a first node 100 and a second node 200.

[0024] Specifically, the first node 100 is configured to maintain first timing information based on a first time source and periodically broadcast the first timing information with a first identifier via the CAN bus. The first node 100 is also configured to receive calibration messages including second timing information from the second node 200, update the first timing information of this node according to the second timing information, and resume periodic broadcasting with the first identifier after the update is completed.

[0025] The second node 200 is configured to generate second timing information based on a second time source independent of the first node 100, listen to the first timing information broadcast by the first node 100, compare the second timing information with the first timing information, and when the comparison result meets the preset conditions, send a calibration message containing the second timing information to the first node 100 through the CAN bus with a second identifier that is different from the first identifier, and stop sending the calibration message after confirming that the first node 100 has updated according to the second timing information.

[0026] The first node 100 can be a TBOX or a dashcam, and is the main time synchronization node of the entire system under normal conditions. The first timing information refers to the timing reference parameters maintained and broadcast by the first node 100, including the first system time and the first time zone parameters.

[0027] The second node 200 can be a cockpit domain controller, and is a supervisory node independent of the first node 100 with multi-source timing capabilities. The second timing information refers to the timing reference parameters generated by the second node 200 based on its own independent time source, including the second system time and the second time zone parameters. The first identifier is the message identifier on the CAN bus used to carry forward timing messages, i.e., the first CAN ID specific to the TBOX. The second identifier is the message identifier on the CAN bus used to carry reverse calibration messages, i.e., the second CAN ID specific to the cockpit domain controller, and is independent and functionally isolated from the first identifier.

[0028] The first node 100 has an RTC, a 4G or 5G communication module, a GNSS positioning module, and supports UDS diagnostic configuration. Internally, the first node 100 includes a time acquisition and calibration module, a time synchronization and calibration module, and a CAN transceiver module. The time acquisition and calibration module obtains network time and positioning time from the 4G or 5G module and the GNSS module, and configures and fixes the time zone through the UDS. The time synchronization and calibration module obtains time from the RTC and time and time zone from the time acquisition and calibration module, performs time calibration, and then sends it to the CAN transceiver module. The CAN transceiver module sends the time and time zone to the CAN bus and simultaneously listens for reverse calibration messages sent by the second node 200, sending the time and time zone from the reverse calibration message to the time acquisition and calibration module. Upon receiving the time and time zone from the reverse calibration message, the time acquisition and calibration module performs calibration and then updates the time and time zone to the time synchronization and calibration module.

[0029] The second node 200 has a 4G or 5G communication module, a GNSS positioning module, and a WiFi communication module in its hardware. Internally, the second node 200 includes a CAN transceiver module, a time acquisition module, and a time calibration module. The time acquisition module obtains network time and positioning time from the 4G or 5G module, GNSS module, and WiFi module to obtain a unique standard time after arbitration. The time acquisition module also obtains the stored time zone based on the user's manually set time zone. The initial time zone is configured via UDS, and subsequent time zone updates are obtained from forward synchronization messages and user-set time zones. The time acquisition module obtains the CAN bus time and time zone from the CAN transceiver module and sends this data to the time calibration module. The time calibration module is responsible for calibrating the CAN bus time and time zone, as well as the time and time zone acquired by the second node 200 itself.

[0030] Please see Figure 2 , Figure 2 This is a second schematic diagram of a vehicle-mounted timing information bidirectional synchronization system provided in an embodiment of this application. The CAN bus also connects to the remaining 300 nodes of the vehicle, including the body ECU, cockpit ECU, chassis ECU, gateway, etc.

[0031] The remaining nodes 300 in the vehicle only recognize and receive messages with the first identifier, ignoring messages with the second identifier. The remaining nodes only receive the time and time zone sent to the CAN bus by the first node 100 and do not participate in the bidirectional calibration process. Only the first node 100 parses the calibration message from the second node 200, achieving the effect of calibrating only the timing reference source without interfering with the remaining nodes in the vehicle. This requires no modification to the programs of the remaining nodes 300 in the vehicle, demonstrating extremely high adaptability.

[0032] The time zone parameter configuration is not based on the positioning longitude. The first node's 100 time zone is generally configured and fixed through UDS, while the second node's 200 time zone can also be configured through UDS or default to East 8 zone. A time zone setting interface is also provided for users to change the time zone settings. The initial values ​​of the first time zone parameter and / or the second time zone parameter are configured and fixedly stored through the UDS diagnostic interface.

[0033] The following is combined Figure 3 This application provides a detailed description of the complete interactive process of the vehicle timing information bidirectional synchronization method provided in the embodiments of this application.

[0034] Please see Figure 3 , Figure 3 This is a flowchart of a method for bidirectional synchronization of vehicle timing information provided in an embodiment of this application.

[0035] S101, the first node 100 is powered on and initialized, obtains the time source and starts forward time synchronization.

[0036] Specifically, after the vehicle is powered on, the first node 100 completes the power-on initialization earlier than the second node 200. The first node 100 first reads the RTC time and determines whether the RTC time is within a reasonable range. If the RTC time reverts to the factory default value due to reasons such as battery depletion, the local RTC time is discarded and the next time it is obtained is waited.

[0037] Simultaneously, the first node 100 obtains external network time and satellite time from the first external time source via a 4G or 5G module or GNSS module, determines whether the time offset is within the allowable range, and checks the validity of the satellite or network time. If the external time is valid, it obtains the system UTC time as a reference; if invalid, it abandons the satellite or network time and waits for the next acquisition. The first node 100 also reads the UDS time zone configuration, determines whether a UDS time zone configuration exists, reads the UDS time zone configuration and calculates the time if it exists, and abandons the UDS time zone configuration time if it does not exist. After obtaining an available time source, the first node 100 determines whether the UDS time zone configuration is valid. If valid, it calculates the time difference between the RTC time, external time, and UDS time. If the time difference exceeds a preset threshold, the first node 100 sends a time synchronization request message using a first identifier via the CAN transceiver module, encapsulating the instruction into a CAN message. If the difference does not exceed the threshold, it maintains the current local time state without processing. Regardless of whether the synchronization request is successful, the first node 100 continues to execute the subsequent broadcast process based on the currently selected time source.

[0038] After initialization, the first node 100 periodically broadcasts the first timing information to the CAN bus using the first identifier, serving as the timing reference for the entire vehicle. When the first node 100 is not connected to 4G or 5G, or has not established a GNSS connection, it preferentially acts as the initial master time synchronization node, reading local RTC clock data and fixed time zone parameters to generate the initial vehicle time and time zone information, which is then sent to the CAN bus via the first identifier at a 1-second frame interval. After the first node 100 establishes a 4G or 5G, or GNSS connection and establishes a GNSS connection, it obtains the network and positioning time for time updates. If a preceding synchronization request fails, the first node 100 records a synchronization failure log and continues broadcasting using the currently available time source.

[0039] S102, the second node 200 is powered on and initialized, passively receiving the first timing information.

[0040] Specifically, after the second node 200 and the remaining nodes 300 in the vehicle are powered on, they by default receive the first timing information broadcast by the first node 100 to complete the initial time synchronization. When the second node 200 is not connected to the network and is not located, it first updates its own system time with the received first timing information.

[0041] S103, the second node 200 acquires multiple independent time sources in parallel, performs validity verification and priority arbitration, and generates second time series information.

[0042] Specifically, the second node 200 activates its onboard GNSS module, 4G or 5G module, and WiFi module as second external time sources, acquiring three independent time sources in parallel. The second node 200 performs a rigorous triple check on each time source. For GNSS time, it sequentially checks whether the GNSS time is valid, whether the GNSS time offset is valid, and whether the GNSS time zone configuration is valid. If all three checks pass, the GNSS time and time zone are synchronized, and the GNSS time is included as a candidate; if any check fails, the GNSS time is discarded.

[0043] For 4G or 5G time, the validity of 4G or 5G time, the legality of time offset, and the legality of time zone configuration are checked in sequence. If all three are passed, the 4G or 5G time and time zone are synchronized and included in the candidate. If any one fails, the 4G or 5G time is abandoned.

[0044] For WiFi time, the system sequentially checks the validity of the WiFi time, the legality of the time offset, and the legality of the time zone configuration. If all three pass, the WiFi time and time zone are synchronized and included in the candidate list; otherwise, the WiFi time is discarded. After the three time sources are verified, the second node 200 arbitrates according to a preset priority from high to low (GNSS priority over 4G or 5G priority over WiFi), selecting the time source with the highest priority that has passed all verifications as the second timing information. If all external time sources are invalid, the second node 200 continues to use the first timing information as the reference.

[0045] The time source invalidity determination is divided into four dimensions: hardware link failure verification, source data validity verification, multi-source difference anti-jump verification, and service credibility threshold verification, covering four types of clock sources: GNSS, 4G or 5G, WiFi, and RTC. The general pre-emptive invalidity determination applies to all sources; if any one of these criteria is met, the source is directly determined to be unusable. The first is module hardware or link failure, including no module response, communication timeout, message CRC check failure, module power-on self-test failure, chip reported fault, or reset alarm. The second is illegal message data, including time field all zeros or all FF, year exceeding a reasonable automotive-grade range (e.g., less than 2000 or greater than 2050), month, day, hour, minute, and second exceeding limits (e.g., month 13 or minute 65), and checksum failure. Thirdly, there is the synchronization timeout. If a valid time is not returned after a fixed waiting window following the initiation of the timing request, the source will become invalid. The GNSS cold start window is 90 seconds, and the warm start window is 30 seconds. The NITZ read timeout is 10 seconds, and the NTP request timeout for cellular or WiFi is 15 seconds.

[0046] GNSS time, as the highest priority source, undergoes the most stringent verification. Positioning status verification requires 3D positioning lock and at least four valid satellites before accepting the time; time is discarded if the satellite signal-to-noise ratio is too low. In time quality index verification, if the UTC time validity flag in the module's output message is zero, the time is unreliable; if the estimated time accuracy reported by the module exceeds 100 milliseconds, it is considered excessive drift, and the system time will not be updated. In jump difference verification, the GNSS output UTC is compared with the current system reference time; if the absolute value of the difference exceeds 30 minutes, it is considered an abnormal jump, the GNSS time is invalid, and large time rollbacks are prohibited; single time rollbacks exceeding 2 seconds are discarded to prevent log timing errors.

[0047] In determining invalid 4G or 5G cellular time, invalid NITZ base station broadcast time conditions include: the cellular module is not attached to the network; the base station does not send NITZ messages or the UTC offset or local time zone in the field is illegal; the difference between the NITZ time and the local trusted time exceeds 30 minutes, indicating an abnormal base station broadcast and discarding it; frequent cell reselection causing NITZ time to jump back and forth, and if the difference exceeds 1 minute twice consecutively, the NITZ source is temporarily blocked for 5 minutes. Invalid cellular NTP conditions include: the cellular data link is not activated; the NTP server connection fails or DNS resolution fails; the NTP return timestamp delay is too large, i.e., the round-trip delay exceeds 2 seconds, indicating severe network jitter and insufficient time accuracy; the difference between the NTP time and the system reference exceeds the limit, i.e., exceeds ±30 minutes, and synchronization is rejected. When both NITZ and NTP return times at the same time, NITZ is given priority; only when NITZ is invalid is cellular NTP accepted.

[0048] WiFi NTP time serves as a supplementary backup time source. Invalid time sources include: WiFi not connected, incorrect password, weak or disconnected hotspot signal; normal WiFi link but abnormal NTP service (e.g., router disconnected from the internet or NTP server unreachable); NTP round-trip latency exceeding 3 seconds (excessive network latency); substandard time accuracy; and a difference of more than 20 minutes between the WiFi NTP time and the current master clock (GNSS or cellular time). In such cases, the time source is discarded and cannot overwrite the master time. When WiFi frequently disconnects while the vehicle is in motion, the software disables WiFi time synchronization by default while the vehicle is in motion, enabling it only when parked.

[0049] The local clock (RTC) serves as a fallback source, but its reliability is the lowest. While the RTC itself keeps time, it will be marked as an unreliable and invalid reference in two scenarios. The first is a complete hardware failure of the RTC, including situations where the backup battery voltage is too low and reports a low voltage fault upon power-on, the RTC time reads the factory default value (e.g., January 1, 2000, 00:00), indicating battery depletion and time loss, RTC register read / write failures, or clock crystal oscillator failure causing the time to stop increasing. The second is a logical reliability failure, where the RTC is deemed invalid even at the operational level. This occurs if the entire vehicle experiences 72 consecutive hours without any external time source, or if the cumulative drift between the current time and the last calibration exceeds 5 minutes after each power-on. Meeting any of these conditions will result in the RTC's time reliability level being marked as zero.

[0050] In multi-source cross-verification, in case of conflict, the lower priority source is directly deemed invalid. The core arbitration rule is that when a higher priority source is valid, the lower priority source's action is invalid. The priorities from highest to lowest are GNSS, 4G or 5G cellular, WiFi, and RTC. When GNSS outputs a valid time, even if the cellular or WiFi returns a time, it is directly deemed invalid and not included in the update. When GNSS is lost but 4G NITZ is normal, if the difference between the WiFi NTP time and 4G exceeds 5 minutes, the WiFi source is deemed invalid. When all external sources fail, only RTC is retained, but it is marked as a low-confidence invalid reference. The automotive-grade anomaly protection supplement also includes temporarily blocking the same source for 10 minutes when the time of the same source frequently jumps within a short period of time, i.e., fluctuations exceeding 1 minute within 10 seconds, and the source is deemed short-term invalid. After the source recovers, it needs to return a stable and consistent time three times consecutively before the invalid blocking is lifted and the source is reactivated. In time zone conflict determination, if the time zone calculated by GNSS latitude and longitude differs from the NITZ time zone by no less than 2 hours, one of the source data is deemed abnormal, and the GNSS time zone is given priority, while the cellular time is marked as invalid.

[0051] S104, the second node 200 listens to the first timing information and performs bidirectional comparison and anti-jitter judgment.

[0052] Specifically, after acquiring the second timing information, the second node 200 enters the continuous listening and comparison phase. The second node 200 receives the first timing information broadcast by the first node 100 using the first identifier in real time via the CAN transceiver module, and compares the second system time and second time zone parameters in the second timing information with the first system time and first time zone parameters in the first timing information. The comparison process includes two dimensions of judgment. In terms of time deviation, the difference between the second system time and the first system time is calculated. If the difference exceeds a preset configurable threshold (default 5 seconds, adjustable according to vehicle model calibration), and the number of consecutive cycles exceeding the threshold reaches a preset number (10 consecutive cycles of 1 second per frame, totaling 10 frames), and the difference is greater than the preset threshold for all 10 frames, then the forward timing drift is deemed excessive, and the first timing information becomes invalid.

[0053] Regarding time zone validity, the system checks whether the second time zone parameters are consistent with the first time zone parameters. If the bus time zone does not match the time zone on the second node 200 side, or if the bus time zone parameters are empty, out of bounds, or abnormal, the time zone reference of the first node 100 is deemed invalid. Furthermore, when a user manually changes the time zone through the time zone setting interface provided by the second node 200, the second time zone parameters are updated, which also triggers this time zone validity check. If the first time zone parameters are inconsistent with the updated second time zone parameters, the preset conditions are met.

[0054] S105, when the comparison result meets the preset conditions, the second node 200 triggers reverse calibration and sends a calibration message.

[0055] Specifically, when the comparison result meets the preset conditions, the second node 200 actively triggers the reverse calibration mechanism. The second node 200 first determines whether the time zone is configured successfully. If the configuration fails, it records a time zone configuration failure log and continues execution. If the time zone is configured successfully, it performs a time zone synchronization update. The second node 200 then determines whether the time or time zone is incorrect. If it is determined to be incorrect, it generates a calibration message containing second timing information and continuously sends three frames via the CAN bus using the second identifier. The specific number of frames can be adjusted according to the project to ensure that the first node 100 stably receives calibration data. After sending the calibration message, the second node 200 determines whether the received time zone or time is consistent with the local time. If they are inconsistent, it further determines whether the time difference or time zone deviation is too large. If the deviation is too large, it sends reverse calibration data to the first node 100 again.

[0056] S106, the first node 100 receives the calibration message, performs validity verification, time update, RTC repair, and restores forward time synchronization.

[0057] After the first node 100 listens to and receives the calibration message of the second identifier through the CAN transceiver module, it first performs a legality check on the second timing information in the message. It checks whether each field in the second timing information exceeds the preset reasonable value range. For example, if the data range defined for a certain byte is 0 to 59, but the actual received value is 60, it is determined to be out of range.

[0058] After successful verification, the time acquisition and calibration module immediately updates its own system timing and time zone parameters, and simultaneously sends the calibrated timing and time zone to the time synchronization and calibration module. During the update, if the deviation between the current first system time and the second system time exceeds a preset jump threshold of 30 seconds, the adjtime function is used for smooth and gradual calibration. The time always increases unidirectionally without jumps, with a maximum of 30 seconds added each time for cyclical correction, and finally, a small error is eliminated all at once.

[0059] If the deviation does not exceed 30 seconds and the rollback does not exceed 2 seconds, the underlying set interface is directly called for instantaneous update. During the update, the updated system time and time zone parameters are synchronously written to the local node's RTC real-time clock, refreshing the local RTC storage data to correct timing errors caused by power failure or drift of the RTC real-time clock. The time synchronization and calibration module generates the updated vehicle time and time zone information and sends it to the CAN transceiver module on the first node 100 side. After the update is completed, the first node 100 rebroadcasts the accurate time and time zone message to the vehicle bus through the first identifier, restoring the normal forward timing mode and completing a complete bidirectional synchronization closed loop.

[0060] S107, the second node 200 awaits confirmation, completes the closed-loop handshake or executes a timeout retransmission.

[0061] Specifically, after sending the calibration message, the second node 200 starts a timeout timer to wait for confirmation. If it receives a response frame from the first node 100 within the timeout period, or if it detects that the first timing information broadcast by the first node 100 via the first identifier has been updated to match the second timing information (i.e., the time and time zone in the updated forward time synchronization have changed significantly), the second node 200 knows that the first node 100 has completed the update. Alternatively, if it receives a calibration confirmation flag bit carried by the first node 100 in the forward time synchronization message, indicating that it has responded to the calibration from the second node 200, then it confirms that the first node 100 has completed the update, stops sending calibration messages, exits the reverse calibration mode, and resumes the silent monitoring state. If no confirmation is received within the timeout period, the second node 200 resends the calibration message and restarts the timer.

[0062] S108, the second node 200 performs retry count determination and failure rollback processing.

[0063] Specifically, the second node 200 increments the synchronization or calibration attempt count by one, checks if the retry count has reached the preset limit. If not, it returns to S104 to continue listening and comparing, entering the next round of loop attempts. If the limit is reached, it abandons the current synchronization cycle, records the synchronization failure log, and executes the failure handling logic. If the second time source itself fails during the entire calibration process, the second node 200 stops sending calibration messages and restores the timing reference of the first timing information broadcast by the first node 100. After the calibration process is completed, the second node 200 determines whether exception handling is required. If so, it sends an exception handling command, and then the process ends.

[0064] In addition to the calibration process described above, the second node 200 also continuously performs the following monitoring tasks during normal system operation.

[0065] S109, the second node 200 monitors the first node 100 for fault recovery and automatically triggers recalibration.

[0066] Specifically, the second node 200 continuously listens to the first timing information broadcast by the first node 100. When it detects that the first timing information broadcast by the first node 100 has reverted to a preset default value, for example, when the first node 100's RTC time reverts to the factory default value of 00:00 on January 1, 2000 due to a power failure reset, indicating that the battery is depleted, the second node 200 directly resends the second timing information to the first node 100 through the second identifier, triggering the aforementioned reverse calibration process. This allows the first node 100 to automatically recalibrate to the correct timing when the first timing information is lost or reverts to the default value due to a reset or fault recovery.

[0067] Compared with existing technologies, this application addresses the pain point of systemic problems caused by a single timing source error in the unidirectional timing architecture of the vehicle CAN bus by constructing a timing synchronization system based on a dual-node bidirectional closed loop. By maintaining the first node 100 as the master timing mode under normal conditions to ensure the stability of the vehicle's timing, and using the second node 200 as a temporary high-precision timing master node for reverse correction when the first node 100 fails, the systemic risk of a single timing node failure is resolved. Through a dual-message link design that strictly distinguishes between periodic timing with the first identifier and trigger-based calibration with the second identifier, coupled with differentiated filtering strategies for other nodes, the calibration process does not interfere with other nodes in the vehicle, requiring no adaptation or modification of the entire vehicle's hardware and software, resulting in strong engineering feasibility. By simultaneously supporting dual-dimensional judgment of time deviation threshold and time zone parameter validity, it can be calibrated and adapted according to different vehicle platform models, accurately identifying various timing anomaly scenarios, adapting to all vehicle domain control architectures, and exhibiting strong versatility. It solves long-standing mass production failures in the industry through pure software logic iteration, requiring no new hardware, no circuit modifications, and no adaptation of the remaining 300 nodes in the vehicle, resulting in zero hardware cost. The vehicle timing-related after-sales failure rate can be significantly reduced, completely eliminating time and time zone anomalies caused by long-term vehicle parking, lack of signal in underground parking garages, and RTC power drift. It enables overseas sales of vehicles without the first node 100 to still provide time and time zone information through the second node 200, improving the stability of the vehicle's electronic control system.

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

[0069] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0070] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0071] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0072] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0073] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A vehicle-mounted time-series information bidirectional synchronization system, characterized in that, Including the first node and the second node; The first node is configured to maintain first timing information based on a first time source and periodically broadcast the first timing information via a CAN bus using a first identifier; The first node is also configured to receive a calibration message from the second node, including second timing information, to update the first timing information according to the second timing information, and to resume periodic broadcasting with the first identifier after the update is completed; The second node is configured to generate the second timing information based on a second time source independent of the first node, listen to the first timing information, compare the second timing information with the first timing information, and when the comparison result meets a preset condition, send a calibration message containing the second timing information to the first node through the CAN bus with a second identifier that is different from the first identifier, and stop sending the calibration message after confirming that the first node has updated according to the second timing information.

2. The system according to claim 1, characterized in that, The preset conditions include: The difference between the second system time in the second timing information and the first system time in the first timing information exceeds a preset threshold, and the number of consecutive cycles exceeding the threshold reaches a preset number. or, The second time zone parameter in the second timing information is inconsistent with the first time zone parameter in the first timing information.

3. The system according to claim 1, characterized in that, The first identifier and the second identifier are different CAN message identifiers. The message sent by the first node with the first identifier is received by all nodes in the vehicle, and the calibration message sent by the second node with the second identifier is only parsed and processed by the first node.

4. The system according to claim 3, characterized in that, The second node confirms that the first node has been updated through at least one of the following methods: The second node detects that the first timing information broadcast by the first node through the first identifier has been updated to be consistent with the second timing information; The second node receives the response frame sent by the first node after completing the update; When the first node resumes periodic broadcasting with the first identifier, it carries a calibration confirmation flag in the first timing information of the broadcast. The second node confirms that the first node has been updated by recognizing the calibration confirmation flag.

5. The system according to claim 2, characterized in that, The first node is also configured as follows: Before updating the first timing information of this node according to the second timing information, the second timing information in the calibration message is validated for legality. The validation includes checking whether the second timing information exceeds a preset reasonable value range. During the update, if the deviation between the current first system time and the second system time exceeds a preset jump threshold, the system time will be smoothly transitioned to the second system time through gradual adjustment. During the update, the updated system time and time zone parameters are synchronously written to the RTC real-time clock of this node to correct the timing deviation of the RTC real-time clock caused by power failure or drift.

6. The system according to claim 1, characterized in that, The second time source includes multiple independent time sources. The second node is further configured as follows: The validity of each of the multiple independent time sources is verified. The time sources that pass the verification are arbitrated according to a preset priority, and the timing information output by the time source with the highest priority is used as the second timing information.

7. The system according to claim 1, characterized in that, The second node is also configured as follows: If the first node is not confirmed to have been updated within a preset timeout period after the calibration message is sent, the calibration message is resent until the update is confirmed to be successful or the preset resentment limit is reached. If the second time source fails during the calibration process, the transmission of the calibration message will be stopped, and the first timing information broadcast by the first node will be used as the timing reference for this node.

8. The system according to claim 2, characterized in that, The initial values ​​of the first time zone parameter and / or the second time zone parameter are configured and stored permanently through the UDS diagnostic interface. The second node is further configured as follows: A time zone setting interface is provided, which receives the time zone setting manually entered by the user, and uses the time zone manually set by the user as the second time zone parameter to trigger reverse synchronization to the first node.

9. The system according to claim 3, characterized in that, The remaining nodes of the entire vehicle are configured as follows: Only messages with the first identifier are identified and received, while messages with the second identifier are ignored, so that the transmission and reception of the calibration message only occurs between the first node and the second node.

10. The system according to claim 1, characterized in that, The second node is also configured as follows: When the first timing information broadcast by the first node is detected to revert to the preset default value, the second timing information is resent to the first node via the second identifier.

Images