Vehicle-mounted network time synchronization method, device and vehicle-mounted network system

Abstract

This application provides a method, apparatus, and system for time synchronization in a vehicle network, relating to the field of communication network technology. The method includes: after a target node starts up, reading time synchronization parameters from a memory; wherein the time synchronization parameters are stored in the memory by the target node before it stops operating, and are used for time synchronization with a reference node; the reference node is a vehicle-mounted device equipped with a real-time clock, which has an independent power supply; then, based on the time synchronization parameters, determining the clock offset of the target node relative to the reference node, and calibrating the local clock of the target node according to the clock offset, thereby completing time synchronization between the target node and the reference node. Through this method, the target node can complete time synchronization with the reference node in a very short time, improving the startup efficiency of the vehicle network system.

Description

Technical Field

[0001] This application relates to the field of communication network technology, and in particular to a method, apparatus and system for time synchronization of in-vehicle network. Background Technology

[0002] With the development of intelligent driving technology, the generalized precise time protocol (gPTP) has become the mainstream standard for high-precision time synchronization in vehicles. The time required to restore time synchronization after a vehicle wakes up from sleep directly affects the activation of functions such as advanced driving assistance systems (ADAS), thus necessitating a solution to the problem of rapid recovery.

[0003] In existing technologies, high-precision time synchronization reconstruction often requires processes such as hardware initialization, best master clock algorithm (BMCA) reselection, link delay retesting, and offset correction. However, this method takes hundreds of milliseconds to several seconds to converge, making it difficult to meet the requirements for fast startup. Summary of the Invention

[0004] This application provides a method, apparatus, and system for vehicular network time synchronization, which can complete the time synchronization of each node in the vehicular network in a very short time, thereby improving the startup efficiency of the vehicular network system.

[0005] In a first aspect, embodiments of this application provide a time synchronization method for an in-vehicle network, applied to a target node, which is any in-vehicle device in the in-vehicle network. The method includes: after the target node starts up, reading time synchronization parameters from a memory; the time synchronization parameters are parameters stored in the memory by the target node before it stops running, used for time synchronization with a reference node; the reference node is an in-vehicle device equipped with a real-time clock, which has an independent power supply; determining the clock offset of the target node relative to the reference node based on the time synchronization parameters; and calibrating the local clock of the target node based on the clock offset to complete time synchronization between the target node and the reference node.

[0006] The vehicle network time synchronization method provided in this application reads the time synchronization parameters stored in the local memory before the target node stopped operating after the target node starts up. Since the reference node has an independently powered real-time clock, the reference time remains valid during the target node's downtime. This ensures that the stored synchronization parameters accurately reflect the time relationship with the reference node after restarting. Therefore, the target node can directly obtain a valid synchronization basis without re-initiating time synchronization message exchanges, avoiding communication delays and network overhead after startup. Furthermore, the clock offset of the target node relative to the reference node is directly determined based on these time synchronization parameters, eliminating the need for real-time measurement and compensation calculations, and enabling rapid acquisition of the required correction value. Finally, the local clock is calibrated based on this clock offset, allowing the target node to complete time synchronization with the reference node in a very short time, improving the startup efficiency of the vehicle network system.

[0007] In one possible implementation, the clock offset of the target node relative to the reference node is determined based on the time synchronization parameters, including: obtaining the reference node's sending timestamp when sending the synchronization message and the target node's receiving timestamp when receiving the synchronization message; and determining the clock offset based on the reference node's sending timestamp, the target node's receiving timestamp, and path delay information.

[0008] Based on the above technical means, this application determines the clock offset by combining the time stamp sent by the reference node and the time stamp received by the target node with the path delay information. This can eliminate the impact of message transmission time on time difference calculation, thereby obtaining the time deviation of the target node relative to the reference node, and providing an accurate basis for subsequent calibration.

[0009] In one possible implementation, the method further includes: when the vehicle network enters a pre-sleep state, acquiring the time synchronization parameters used by the target node and the reference node for time synchronization, and storing the acquired time synchronization parameters in a memory.

[0010] Based on the above technical means, this application acquires and stores time synchronization parameters when the vehicle network enters a pre-sleep state, which can save the latest synchronization status information in a timely manner, so that the target node can directly reuse the parameters to complete fast synchronization when it starts up next time.

[0011] In one possible implementation, storing the acquired time synchronization parameters in a memory further includes: performing cyclic redundancy check on the acquired time synchronization parameters to obtain a check value; and associating the check value with the time synchronization parameters and storing it in the memory.

[0012] Based on the above technical means, this application performs cyclic redundancy check on the time synchronization parameters and stores the check values ​​in association. This can effectively detect unexpected changes in the parameters during storage or retrieval, prevent parameter errors caused by abnormal storage media, and thus ensure the integrity of the stored synchronization parameters and the reliability of subsequent use.

[0013] In one possible implementation, after reading the time synchronization parameters from the memory, the method further includes: verifying the read time synchronization parameters according to a check value; if the time synchronization parameters pass the verification, determining the clock offset of the target node relative to the reference node based on the time synchronization parameters; if the time synchronization parameters fail the verification, re-acquiring the path delay information from the target node to the reference node.

[0014] Based on the above technical means, this application first uses the check value to verify the integrity when reading the time synchronization parameters. It only uses the check value for synchronization when the check passes. Otherwise, it re-acquires the path delay. This can avoid errors caused by clock calibration based on damaged parameters. At the same time, it has the ability to repair itself, which enhances the fault tolerance and reliability of time synchronization.

[0015] In one possible implementation, obtaining the path delay information from the target node to the base node includes: starting from the target node, determining the link delay hop by hop along the communication path between the target node and the base node; and accumulating the link delays determined hop by hop to obtain the path delay information from the target node to the base node.

[0016] Based on the above technical means, this application determines the path delay by determining the delay of each link segment hop by hop along the communication path and accumulating them. This can reflect the actual transmission time of the multi-hop network, avoid the coarseness of end-to-end measurement, and thus provide a more accurate delay basis for the accurate calculation of clock offset, effectively improving synchronization accuracy.

[0017] In one possible implementation, the time synchronization parameters include the identification information of the reference node, the path delay information from the target node to the reference node, and the frequency offset compensation coefficient of the target node's local crystal oscillator relative to the reference node.

[0018] Based on the above technical means, the time synchronization parameters stored in this application simultaneously include path delay information and frequency offset compensation coefficient, so that after the target node restarts, it can not only correct the phase offset, but also compensate for the frequency drift of the local crystal oscillator. It can coordinately calibrate the local clock from the two dimensions of time difference and frequency to achieve higher precision time synchronization.

[0019] In one possible implementation, the reference node is also used to start at a preset period when the vehicle is in a dormant state, obtain a standard timestamp via a satellite positioning system and / or a network time protocol, and calibrate the real-time clock according to the standard timestamp.

[0020] Based on the aforementioned technical means, this application periodically wakes up the reference node during vehicle hibernation and calibrates its real-time clock using satellite positioning or network time protocols. This continuously corrects the cumulative drift of the reference clock, ensuring the long-term accuracy and stability of the reference time, thereby providing a reliable time reference for other nodes and ensuring the effectiveness of rapid synchronization after system restart.

[0021] Secondly, embodiments of this application provide an in-vehicle network time synchronization device applied to a target node, which is any in-vehicle device in the in-vehicle network. The device includes: a data reading module, a deviation determination module, and a clock calibration module. The data reading module is used to read time synchronization parameters from a memory after the target node starts up. The time synchronization parameters are stored in the memory by the target node before it stops running, and are used for time synchronization with a reference node. The reference node is an in-vehicle device equipped with a real-time clock, which has an independent power supply. The deviation determination module is used to determine the clock offset of the target node relative to the reference node based on the time synchronization parameters. The clock calibration module is used to calibrate the local clock of the target node based on the clock offset to complete time synchronization between the target node and the reference node.

[0022] In one possible implementation, the deviation determination module is specifically used to obtain the reference node sending timestamp recorded when the reference node sends the synchronization message and the target node receiving timestamp recorded when the target node receives the synchronization message; and to determine the clock offset based on the reference node sending timestamp, the target node receiving timestamp, and path delay information.

[0023] In one possible implementation, the device further includes a data storage module, used to acquire time synchronization parameters used for time synchronization between the target node and the reference node when the vehicle network enters a pre-sleep state, and to store the acquired time synchronization parameters in a memory.

[0024] In one possible implementation, the data storage module is further configured to perform cyclic redundancy check on the acquired time synchronization parameters to obtain a check value; and associate the check value with the time synchronization parameters and store it in the memory.

[0025] In one possible implementation, the deviation determination module is further configured to: verify the read time synchronization parameters based on the verification value; if the time synchronization parameters pass the verification, determine the clock offset of the target node relative to the reference node based on the time synchronization parameters; if the time synchronization parameters fail the verification, reacquire the path delay information from the target node to the reference node.

[0026] In one possible implementation, the deviation determination module is further configured to determine the link delay hop-by-hop along the communication path between the target node and the reference node, starting from the target node; and to accumulate the link delays determined hop-by-hop to obtain the path delay information from the target node to the reference node.

[0027] In one possible implementation, the time synchronization parameters include the identification information of the reference node, the path delay information from the target node to the reference node, and the frequency offset compensation coefficient of the target node's local crystal oscillator relative to the reference node.

[0028] In one possible implementation, the reference node is also used to start at a preset period when the vehicle is in a dormant state, obtain a standard timestamp via a satellite positioning system and / or a network time protocol, and calibrate the real-time clock according to the standard timestamp.

[0029] Thirdly, this application provides an in-vehicle network system, including a reference node and multiple slave nodes; wherein the reference node includes a real-time clock with an independent power supply for providing a time synchronization reference; the slave nodes are communicatively connected to the reference node through the in-vehicle network and include a memory and a processor, the processor being used to execute the method in the first aspect or any possible implementation of the first aspect.

[0030] Fourthly, this application provides a computer-readable storage medium storing a computer program or instructions that, when executed on a device, cause the device to perform the method of the first aspect or any possible implementation thereof.

[0031] Fifthly, this application provides a computer program product, which includes a computer program or instructions that, when executed on a device, cause the device to perform the method in the first aspect or any possible implementation of the first aspect.

[0032] The second to fifth aspects described above correspond to the technical solutions of the first aspect of the embodiments of this application. The beneficial effects achieved by each aspect and its corresponding feasible implementation are similar, and will not be repeated here. It should be noted that various possible implementations of any aspect described above can be combined, provided that the solutions do not contradict each other. Attached Figure Description

[0033] Figure 1 This application provides a schematic diagram of the architecture of an in-vehicle network system. Figure 2 This is a schematic diagram of the structure of an in-vehicle network provided in an embodiment of this application; Figure 3A flowchart illustrating a vehicle network time synchronization method provided in an embodiment of this application; Figure 4 A timing diagram for determining path delay information between nodes is provided in an embodiment of this application; Figure 5 A detailed flowchart illustrating a vehicle network time synchronization method provided in this application embodiment; Figure 6 A schematic diagram illustrating the implementation process of a time synchronization method in a vehicle network system provided in this application embodiment; Figure 7 A schematic diagram of one component of an in-vehicle network time synchronization device provided in an embodiment of this application; Figure 8 This is a schematic diagram of a vehicle network time synchronization device provided in an embodiment of this application. Detailed Implementation

[0034] The embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Those skilled in the art will recognize that, with the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0035] Before describing the embodiments of this application in detail, the technical terms involved in this application will be explained first in order to facilitate the understanding of the technical solutions of the embodiments of this application.

[0036] 1. Non-volatile memory (NVM): A type of memory that stores data without losing it after power failure, used to persistently store critical information such as configuration and programs.

[0037] 2. Real-time Clock (RTC): A hardware module that continuously keeps time and provides a precise absolute time reference.

[0038] 3. gPTP Master (GM): The highest time synchronization source in the vehicle network, which distributes the time reference to the vehicle network. In this application, it can be regarded as the reference node.

[0039] 4. gPTP End Point (EP): A terminal node in the vehicular network that connects a single synchronous link, which can be regarded as the target node in this application.

[0040] 5. gPTP Bridge: A relay node in the vehicular network that connects to gPTP endpoints in the network link. It should be understood that, in this application, a gPTP bridge can also serve as a type of gPTP endpoint in the vehicular network.

[0041] 6. Prepare Bus Sleep Mode (PBSM): This is a pre-preparation state before the vehicle network bus enters a low-power sleep state, used to coordinate nodes to complete the cleanup operations before hibernation.

[0042] 7. Repeated Message State (RMS): Used to identify and manage the running status of repeatedly sent messages, avoiding the accumulation of redundant messages in the network.

[0043] This application can be applied to in-vehicle network systems for vehicles equipped with intelligent driving functions. This in-vehicle network system includes multiple electronic control units (ECUs) and domain controllers as in-vehicle network nodes. These in-vehicle network nodes can be interconnected via in-vehicle Ethernet and perform high-precision time synchronization based on the IEEE 802.1AS (gPTP) protocol to support intelligent driving functions with stringent time requirements.

[0044] In the aforementioned vehicle network system, there are various time synchronization scenarios involving vehicle sleep / wake-up, such as: Scenario 1: Vehicle wake-up and startup after long-term parking. After the vehicle has been parked for an extended period of time (e.g., several days or weeks) after being turned off and put into sleep mode, when the user wakes the vehicle, the vehicle network will switch from sleep mode to working mode. Each ECU / domain controller needs to quickly complete clock synchronization to support the immediate startup of functions such as panoramic imaging and radar perception.

[0045] Scenario 2: Temporary wake-up of intelligent driving functions. When a vehicle is in sleep mode but needs to perform certain scheduled tasks (such as environmental monitoring in sentry mode, remote video viewing, etc.), the onboard network system will temporarily wake up some nodes to perform the tasks. After the tasks are completed, the system will return to sleep mode. During this process, the woken-up nodes need to quickly establish time synchronization to ensure the validity of the timestamps on the perception data.

[0046] The above scenarios all point to the same technical problem: how to enable all nodes in the vehicle network to complete gPTP clock synchronization in a very short time after the vehicle wakes up from hibernation, so as to meet the rapid startup requirements of time-sensitive functions such as advanced driver assistance systems.

[0047] To solve the above problems, the existing technology mainly adopts the following solutions: One approach is to use the IEEE 802.1AS (gPTP) standard procedure for complete time synchronization. After each wake-up, the vehicle network needs to complete the best master clock election (BMCA) and link latency measurement. However, this approach often takes 125ms to 3s to converge, which cannot meet the fast startup requirements of time-sensitive functions in vehicles.

[0048] Secondly, a hierarchical multi-clock source backup scheme is adopted. The vehicle network system can achieve unified clock synchronization in the vehicle through the main and auxiliary clock sources. However, after waking up, the synchronization negotiation process still needs to be fully executed to confirm the optimal clock source and link status. The problem of rapid recovery after waking up has not been solved, and the convergence time is too long.

[0049] To address the aforementioned shortcomings, this application proposes a time synchronization method for vehicular networks. After the target node starts up, it reads the time synchronization parameters stored in its local memory before it stopped operating. Since the reference node has an independently powered real-time clock, the reference time remains valid during the target node's downtime. This ensures that the stored synchronization parameters accurately reflect the time relationship with the reference node after restarting. Therefore, the target node can directly obtain valid synchronization information without re-initiating time synchronization message exchanges, avoiding communication delays and network overhead after startup. Furthermore, the clock offset of the target node relative to the reference node is directly determined based on these time synchronization parameters, eliminating the need for real-time measurement and compensation calculations, and enabling rapid acquisition of the required correction value. Finally, the local clock is calibrated based on this clock offset, allowing the target node to complete time synchronization with the reference node in a very short time, improving the startup efficiency of the vehicular network system.

[0050] It should be noted that, in this embodiment of the application, the vehicle network system may select a vehicle network node with an independent power supply and real-time clock as a reference node to provide a time reference to other vehicle network nodes in the vehicle network system.

[0051] For example, the reference node can be a telematics box (TBOX), a smart driving domain controller, a cockpit domain controller, an in-vehicle gateway, or other in-vehicle devices with an independently powered real-time clock; this application does not impose any specific limitations on this.

[0052] Taking TBOX as the base node as an example, see [link / reference]. Figure 1 The architecture of the vehicle network system in this embodiment can be as follows: The TBOX acts as a GM node, internally equipped with modules such as NVM and RTC to provide a time synchronization basis for the master clock. The TBOX can connect to multiple domain controllers (ECUs), each ECU acting as an EP node and equipped with an NVM memory. Some EP nodes can also act as Bridges connecting to downstream EP nodes.

[0053] For ease of understanding, see [link to relevant documentation]. Figure 2 The embodiments provided in this application are as follows: Figure 1 The vehicular network system shown has a structure with only a single Only GM node and all other terminals are EP nodes. Clock signals can be distributed between EP nodes through hierarchical links, and the entire network is synchronized and calibrated by a single master clock.

[0054] The in-vehicle network time synchronization method provided in this application will be described below with reference to specific embodiments. These embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0055] Figure 3 This is a flowchart illustrating one embodiment of the vehicle network time synchronization method provided in this application. (Refer to...) Figure 3 The vehicle network time synchronization method provided in this application embodiment may include: S301. After the target node starts up, read the time synchronization parameters from the memory.

[0056] The time synchronization parameters are stored in the memory of the target node before it stops operating, and are used for time synchronization with the reference node. The reference node is an on-board device equipped with a real-time clock, which has an independent power supply.

[0057] In this embodiment, the target node refers to any in-vehicle device in the vehicular network that requires time synchronization. It can be an electronic control unit, domain controller, in-vehicle gateway, or other in-vehicle communication node with clock synchronization requirements. The startup of the target node refers to the process of switching the target node from a dormant state or a power-off state to an active state.

[0058] In some embodiments, the time synchronization parameters may include identification information for identifying the reference node. This identification information may specifically be the media access control address, Internet protocol address, device serial number, or node number configured in the vehicle network of the reference node, which enables the target node to determine which reference node it should synchronize with after being woken up.

[0059] In some embodiments, the time synchronization parameters may also include path delay information from the target node to the base node. This path delay information reflects the time required for the time synchronization message to be transmitted on the communication path between the target node and the base node. This time may be the total one-way path delay from the target node to the base node, or it may be a cumulative value obtained by accumulating the hop-by-hop link delay.

[0060] In some embodiments, the time synchronization parameters may also include a frequency offset compensation coefficient for the target node’s local crystal relative to the reference node. This compensation coefficient is used to characterize the ratio of the deviation between the actual oscillation frequency of the target node’s local clock crystal and the clock frequency of the reference node, in order to compensate for frequency drift caused by crystal manufacturing tolerances, aging, or changes in ambient temperature.

[0061] In addition, in other embodiments, the time synchronization parameters may also include the synchronization domain number to which the target node belongs and a list of source port identifiers that are allowed to synchronize with the target node, so as to accurately identify available synchronization sources when there are multiple time synchronization domains or ports.

[0062] In one possible implementation, the target node can execute a bootloader or startup firmware through its configured processor. Before or during the loading of the operating system kernel, it can call the memory read interface to read time synchronization parameters from a designated storage area of ​​non-volatile memory according to a preset storage address offset. Specifically, in the early stages of startup after hardware initialization, the target node can have the startup management unit locate the storage location of the time synchronization parameters based on a parameter index table stored in a specific memory partition. The parameter data can then be read from non-volatile memory into the system's running memory via direct memory access, and the parameter data structure can be parsed to extract specific values.

[0063] As can be seen from S301, since the time synchronization parameters are pre-stored by the target node before it stops running, and the real-time clock of the reference node is continuously maintained by an independent power supply during the target node's shutdown, the target node can directly obtain the data basis required for time synchronization by reading the parameters from the memory after startup without waiting for the transmission and interaction of network packets.

[0064] S302. Determine the clock offset of the target node relative to the reference node based on the time synchronization parameters.

[0065] In the embodiments of this application, the clock offset refers to the difference between the local clock time of the target node and the clock time of the reference node. This difference is used to characterize the time deviation between the local timing of the target node and the standard timing provided by the reference node.

[0066] In some embodiments, the clock offset can be a value obtained by subtracting path delay information from the difference between the time the target node receives the synchronization message and the time the reference node sends the synchronization message. This value can be a signed time difference, the sign of which indicates the speed of the target node's local clock relative to the reference node's clock.

[0067] In addition, in other embodiments, the clock offset may also include a set of historical offset values ​​obtained after multiple synchronization calculations, for use in subsequent frequency drift trend analysis.

[0068] In some embodiments, the target node can obtain path delay information by parsing the time synchronization parameters read from the memory, and record the receiving time using a hardware timestamp unit when receiving the synchronization message sent by the reference node. Then, the receiving time is compared with the sending time of the reference node carried in the synchronization message, and the clock offset is calculated by combining the path delay information.

[0069] In some embodiments, before determining the clock offset, the target node may pre-compensate the clock frequency of the local crystal oscillator according to the frequency offset compensation coefficient in the time synchronization parameters, so as to eliminate the influence of the cumulative counting error introduced by the crystal oscillator frequency deviation on the offset calculation result.

[0070] In other embodiments, the target node may also obtain the correction value in the correction field carried by the reference node in the synchronization message, which is used to compensate for the additional time consumption introduced by asymmetric delay or dwell time during link transmission, and incorporate the correction value into the calculation of clock offset.

[0071] In one possible implementation, after the target node reads the time synchronization parameters from memory, it can estimate the clock offset of the target node's local clock relative to the reference node's reference clock by using the difference between the current local clock count and the reference time value of the reference node recorded in the time synchronization parameters at the moment the target node stopped running, combined with the frequency offset compensation coefficient of the local crystal oscillator. For example, the target node can obtain the difference between the current local clock count and the local clock count stored before stopping operation, subtract the time error accumulated by the frequency offset compensation coefficient during the target node's downtime from this difference, and obtain the current clock offset of the target node relative to the reference node.

[0072] In another possible implementation, the target node can determine the clock offset based on the reference node's sending timestamp (recorded when the reference node sends the synchronization message) and its own receiving timestamp (recorded when it receives the synchronization message), combined with the path delay information from the target node to the reference node included in the time synchronization parameters. For example, the target node can calculate the clock offset relative to the reference node according to the operation logic that the clock offset equals the target node's receiving timestamp minus the reference node's sending timestamp, minus the path delay information, and a correction field.

[0073] It should be understood that since the path delay information is pre-read from the memory, the target node can directly determine the clock offset without re-initiating the link delay measurement after being woken up.

[0074] As can be seen from S302, since the target node directly reads the time synchronization parameters from the local memory to determine the clock offset, it does not need to wait for multiple round trips of the real-time link delay measurement message between the target node and the reference node. This avoids the uncertainty and time consumption caused by network transmission delay and protocol state machine transition, thus enabling the accurate clock offset to be obtained in a very short time after startup. This provides a reliable deviation basis for the subsequent rapid completion of clock calibration and shortens the time synchronization convergence time after the vehicle network system is woken up.

[0075] S303. Based on the clock offset, calibrate the local clock of the target node to complete the time synchronization between the target node and the reference node.

[0076] In some embodiments, calibrating the local clock may include two aspects: phase calibration and frequency calibration. Phase calibration refers to a single correction of the current local time value to eliminate accumulated time deviations. Frequency calibration refers to adjusting the division factor or counting rate of the local clock crystal oscillator to ensure that the running rate of the target node's local clock is consistent with that of the reference node's clock, thereby maintaining synchronization accuracy during the operational phase after calibration.

[0077] In some embodiments, after completing local clock calibration, the target node can also continuously monitor the synchronization deviation between the local clock and the reference node clock at a preset period, and trigger a resynchronization process if the synchronization deviation exceeds a preset threshold.

[0078] In one possible implementation, the target node can add the clock offset to the current time value of the local clock, and write the added time value back to the hardware timer of the local clock as the calibrated local clock time. Then, the frequency division coefficient of the local clock crystal oscillator is adjusted synchronously according to the frequency offset compensation coefficient carried in the time synchronization parameters, so that the calibrated local clock time remains synchronized with the reference node clock during subsequent operation.

[0079] As can be seen from S303, since the target node calibrates its local clock based on the clock offset determined by the time synchronization parameters directly read from the memory, the entire calibration process does not require waiting for additional network measurement messages, allowing the calibration action to be completed in a very short time after startup. After completing the calibration, the target node can have a time reference consistent with the reference node, thereby enabling the upper-layer applications and communication protocol stack on the target node to immediately use the accurate synchronization clock to start working, effectively shortening the overall time for each node to enter normal working state after the vehicle network system is woken up.

[0080] In this embodiment of the application, before step S301 above, the target node needs to store the time synchronization parameters in the memory before the vehicle network enters pre-sleep mode.

[0081] For example, when the vehicle network enters a pre-sleep state, the target node can obtain the time synchronization parameters used for time synchronization with the reference node and store the obtained time synchronization parameters in the memory.

[0082] In this embodiment of the application, the pre-sleep state refers to the intermediate transition state in which the vehicle network switches from the normal operation state to the complete sleep state.

[0083] In some embodiments, the pre-sleep state may specifically include a pre-bus sleep mode defined by a network management protocol. In this mode, the target node's communication protocol stack has stopped receiving new application layer messages but has not yet disconnected the physical layer connection, and the processor still has the computing power required to perform storage operations.

[0084] In some embodiments, the target node can obtain a notification to enter a pre-sleep state by monitoring the state machine state changes of the vehicular network management protocol. For example, when the state machine of the vehicular network management protocol switches from the normal operation state to the pre-sleep state, the network management application layer program of the target node receives a callback notification of the state switch, and the target node then responds to the callback notification to obtain the time synchronization parameters currently in use.

[0085] In some embodiments, the target node can also obtain a pre-sleep state indication by communicating with the power management hardware, which sends a pre-sleep signal to the target node via a hardware interrupt pin before preparing to cut off part of the power supply.

[0086] In some embodiments, when storing time synchronization parameters, the target node may first perform cyclic redundancy check on the acquired time synchronization parameters to obtain a check value, and then associate the check value with the time synchronization parameters and store it in the memory.

[0087] In some embodiments, the target node may also send a storage completion confirmation to the vehicle network management protocol after storing the time synchronization parameters, so that the vehicle network management protocol can only enter the next stage of complete dormancy after receiving storage completion confirmations from all nodes.

[0088] In one possible implementation, when the vehicular network enters a pre-sleep state, the target node acquires the following time synchronization parameters to be stored: the whitelist of reference node clock identifiers it maintains, the currently used synchronization domain number, the list of source port identifiers allowed for time synchronization, the frequency offset compensation coefficient of the local crystal oscillator relative to the reference node, and the total path delay value to the reference node. It then performs cyclic redundancy check (CRC) calculations on each acquired parameter value to obtain a checksum. Subsequently, each parameter value and the associated checksum are written to a designated storage area of ​​non-volatile memory according to a preset data structure format. After writing is complete, a storage completion flag is reported to the network management protocol. The network management protocol, after confirming that all nodes have completed storage, controls each node to enter a sleep state.

[0089] In this embodiment, since the target node completes the acquisition and storage of time synchronization parameters when the vehicle network enters the pre-sleep state, the parameters can be persistently stored in the non-volatile memory even after the target node is completely powered off or enters a low-power state. When the target node is woken up again, the stored parameters can be directly read from the memory, avoiding the need to obtain these parameters again through message interaction after wake-up, thus providing a data foundation for fast time synchronization after wake-up.

[0090] In this embodiment, the time synchronization parameters are associated with a check value based on cyclic redundancy check. Based on this, after reading the time synchronization parameters, the target node can first check the time synchronization parameters and then implement the subsequent time synchronization process according to the check result.

[0091] For example, if the time synchronization parameters pass verification, the target node can determine its clock offset relative to the base node based on the time synchronization parameters. Alternatively, if the time synchronization parameters fail verification, the path delay information from the target node to the base node can be reacquired.

[0092] In one possible implementation, after the target node reads the time synchronization parameters from the memory, it can first calculate the checksum of the read parameter data according to the cyclic redundancy check algorithm used when storing the time synchronization parameters. The calculated checksum is then compared with the checksum stored in conjunction with the time synchronization parameters. If they match, the checksum is confirmed to have passed, and the node continues with step S102 to determine the clock offset using the time synchronization parameters. If they do not match, the checksum is confirmed to have failed. In this case, the target node no longer uses the time synchronization parameters but instead remeasures the path delay information by exchanging link delay measurement messages with adjacent nodes on the communication path. After obtaining the new path delay information, the target node can use this new path delay information to replace the invalid path delay information in the pre-stored parameters. Combined with the sending timestamp carried in the synchronization message received from the reference node and its own recorded receiving timestamp, the target node re-executes the clock offset determination operation.

[0093] For example, the target node can exchange link delay measurement messages with its adjacent upstream node. During the interaction, the hardware records the sending timestamp and receiving timestamp of the message respectively. Based on these timestamps, the link delay value between the target node and the adjacent node is obtained according to the link delay calculation formula defined by the standard time synchronization protocol. If there are multiple intermediate nodes, the above measurement is performed hop by hop and the link delay of each segment is accumulated to finally obtain the total path delay information from the target node to the reference node.

[0094] For example, refer to Figure 4 This application provides a timing diagram for determining path delay information between nodes. For example... Figure 4 As shown, the GM node first sends a Sync message to the EP / Bridge node. Then, the GM sends a Pdelay_Req message to trigger the hardware counter to record timestamp T1. The EP / Bridge then receives the Pdelay_Req message, triggering the hardware counter to record timestamp T2, and then sends T2 back to the GM via Pdelay_Resp, simultaneously recording timestamp T3. The EP / Bridge then sends timestamp T3 to the GM via a Pdelay_Follow_Up message. Finally, the GM receives the Pdelay_Follow_Up message, triggering the hardware counter to record timestamp T4. The EP / Bridge can calculate the total path delay based on the calculated link delay and then calibrate its local global time.

[0095] It should be understood that the above link latency can be determined in the following ways: .

[0096] The total path delay can be obtained by superimposing the link delays between each node on the communication link from the target node to the base node.

[0097] In this embodiment, the read time synchronization parameters are verified, and if the verification passes, the pre-stored parameters are used to complete fast synchronization. If the verification fails, the system automatically reverts to re-acquiring path delay information. This ensures that fast synchronization can be achieved using pre-stored parameters in most cases, while avoiding synchronization errors caused by blindly using pre-stored parameters that have become invalid due to storage anomalies, data corruption, or environmental changes. This enhances the fault tolerance and reliability of the vehicular network time synchronization solution.

[0098] In this embodiment of the application, in order to avoid the real-time clock of the reference node from deviating from its own time reference due to the accumulation of timing errors caused by crystal oscillator temperature drift during vehicle sleep, the reference node can also actively perform periodic calibration of its real-time clock to maintain the accuracy and long-term stability of its own time reference.

[0099] For example, when the vehicle is in a dormant state, the reference node can be pre-set to start periodically and obtain a standard timestamp through a satellite positioning system and / or network time protocol, and then calibrate the real-time clock according to the standard timestamp.

[0100] In some embodiments, the preset period can be determined based on the frequency stability characteristics of the real-time clock crystal used by the reference node. When the frequency stability of the crystal is high, the preset period can be set to be relatively long, and when the frequency stability of the crystal is low, the preset period can be set to be relatively short.

[0101] In some embodiments, the preset cycle can also be dynamically adjusted according to the degree of change in the ambient temperature of the vehicle. In seasons or regions with large changes in ambient temperature, the preset cycle can be shortened to calibrate the real-time clock more frequently, while under relatively stable ambient temperature conditions, the preset cycle can be extended to reduce power consumption.

[0102] In addition, in some other embodiments, the preset period can be adaptively adjusted according to the actual cumulative drift of the real-time clock. The reference node can record the deviation value of the real-time clock relative to the standard timestamp during each calibration. If the deviation values ​​of multiple consecutive calibrations are small, the preset period is gradually extended. If the deviation value of a certain calibration is large, the preset period is shortened in subsequent stages.

[0103] It should be understood that the specific value of the preset cycle can be manually calibrated by R&D personnel based on historical experience and adaptively adjusted in accordance with the above method. This application does not impose specific restrictions on this.

[0104] In some embodiments, the timestamps provided by the satellite positioning system can have nanosecond-level time accuracy and can serve as an absolute time reference source for calibrating real-time clocks.

[0105] In some embodiments, the timestamps provided by the network time protocol can originate from mobile communication base stations or network time servers, and their time accuracy is typically on the order of milliseconds to tens of milliseconds. They can serve as a substitute or supplementary reference source for satellite positioning systems in scenarios where satellite signals are unavailable.

[0106] In some embodiments, the reference node can implement timing for a preset period using an internally configured timer or wake-up timer. This timer continues to run even when the reference node enters a sleep state and generates a wake-up interrupt signal when the preset period value is reached. Subsequently, the reference node switches from a low-power mode to an operating mode in response to this wake-up interrupt signal. After entering the operating mode, the reference node can search for and receive satellite signals through its satellite positioning receiver, parse the standard timestamp from the satellite signals, or send a time request message to a network time server through its network communication interface and receive a response message carrying the standard timestamp, calibrating its real-time clock according to the parsed standard timestamp.

[0107] In one possible implementation, the reference node is activated every 24 hours by a wake-up interrupt signal from its internal timer while the vehicle is in sleep mode. Upon activation, it activates its satellite positioning receiver to search for satellite signals from the Global Positioning System (GPS) or the BeiDou Navigation Satellite System (BDS), and parses the current standard timestamp from the received satellite signals. Then, it compares the standard timestamp with the current count value of the reference node's real-time clock, calculates the time deviation between the real-time clock and the standard timestamp, and adjusts the internal count value of the real-time clock by writing to the real-time clock's register to eliminate the deviation. After calibration, the reference node re-enters sleep mode, awaiting wake-up in the next preset cycle.

[0108] In this embodiment, since the reference node is periodically started during the vehicle's sleep period and obtains a standard timestamp through a satellite positioning system or network time protocol to calibrate its real-time clock, it can effectively compensate for the frequency drift accumulated by the crystal oscillator over a long period of time and the real-time clock timing deviation caused by changes in ambient temperature. This allows the real-time clock of the reference node to maintain high time accuracy even after the vehicle has been parked for a long time. Consequently, the reference time reference in the time synchronization parameters read from the memory by the target node after waking up has higher reliability, ensuring the synchronization accuracy of the fast synchronization scheme.

[0109] In summary, see Figure 5The detailed process of the vehicle network time synchronization method provided in this application is as follows. The vehicle network time synchronization method is divided into the TBOX side and the ECU side. Before entering sleep mode, the ECU is in PBSM state, and after configuring the time synchronization parameters, it enters sleep mode. The TBOX side will send the first Sync frame 500ms after the TBOX wakes up. After receiving the Sync message sent by the TBOX, the ECU is woken up, enters RMS state, loads the time synchronization parameters, and then performs CRC verification and ID validity verification of the data. If the verification is invalid, the link delay is recalculated and resynchronization is performed. If the verification is valid, time synchronization is performed according to the stored data.

[0110] For ease of understanding, see [link to relevant documentation]. Figure 6 The implementation process of time synchronization in the vehicular network system is as follows. The TBOX acts as the GM (Master Timer). During GM sleep mode, it relies on a local RTC for low-power timing and wakes up every 24 hours to connect to the satellite system for time synchronization, thus maintaining the master clock's time accuracy. Before going into sleep mode, the domain controller ECU is in PBSM mode, storing the time synchronization parameters in the NVM (Non-Vision Controller). After storage, it enters sleep mode. Upon GM wake-up, it sends the first Sync message. The ECU receives the message, wakes up, reads the time synchronization parameters from the NVM, and finally quickly completes local time synchronization based on the read data.

[0111] It should be noted that the processing of data protected by the laws and regulations of relevant countries and regions involved in the embodiments of this application (e.g., collection, storage, use, processing, transmission, provision and disclosure) complies with the relevant laws and regulations of the relevant countries and regions.

[0112] The in-vehicle network time synchronization method according to the embodiments of this application has been described above. The apparatus for performing the above method provided in the embodiments of this application is described below. Those skilled in the art will understand that the methods and apparatus can be combined with and referenced by each other. The related apparatus provided in the embodiments of this application can perform the steps in the above-described in-vehicle network time synchronization method. The related apparatus can be referred to in the following description: Figure 7This is a schematic diagram illustrating one component of an in-vehicle network time synchronization device provided in an embodiment of this application. The in-vehicle network time synchronization device 700 may include: a data reading module 701, a deviation determination module 702, and a clock calibration module 703. The data reading module 701 is used to read time synchronization parameters from a memory after the target node starts up. These time synchronization parameters are stored in the memory by the target node before it stops running, and are used for time synchronization with a reference node. The reference node is an in-vehicle device equipped with a real-time clock, which has an independent power supply. The deviation determination module 702 is used to determine the clock offset of the target node relative to the reference node based on the time synchronization parameters. The clock calibration module 703 is used to calibrate the local clock of the target node based on the clock offset to complete time synchronization between the target node and the reference node.

[0113] In this embodiment of the application, the deviation determination module 702 is specifically used to obtain the reference node sending timestamp recorded when the reference node sends the synchronization message and the target node receiving timestamp recorded when the target node receives the synchronization message; and determine the clock offset based on the reference node sending timestamp, the target node receiving timestamp, and path delay information.

[0114] In this embodiment of the application, the device further includes a data storage module, which is used to acquire the time synchronization parameters used by the target node and the reference node for time synchronization when the vehicle network enters a pre-sleep state, and to store the acquired time synchronization parameters in a memory.

[0115] In this embodiment of the application, the data storage module is further configured to perform cyclic redundancy check on the acquired time synchronization parameters to obtain a check value; and associate the check value with the time synchronization parameters and store it in the memory.

[0116] In this embodiment of the application, the deviation determination module 702 is further configured to: verify the read time synchronization parameters according to the verification value; if the time synchronization parameters pass the verification, determine the clock offset of the target node relative to the reference node according to the time synchronization parameters; if the time synchronization parameters fail the verification, re-acquire the path delay information from the target node to the reference node.

[0117] In this embodiment of the application, the deviation determination module 702 is further configured to determine the link delay hop by hop along the communication path between the target node and the reference node, starting from the target node; and to accumulate the link delays determined hop by hop to obtain the path delay information from the target node to the reference node.

[0118] In this embodiment of the application, the time synchronization parameters include the identification information of the reference node, the path delay information from the target node to the reference node, and the frequency offset compensation coefficient of the target node's local crystal oscillator relative to the reference node.

[0119] In this embodiment of the application, the reference node is also used to start at a preset period when the vehicle is in a dormant state, obtain a standard timestamp through a satellite positioning system and / or a network time protocol, and calibrate the real-time clock according to the standard timestamp.

[0120] This application also provides an in-vehicle network time synchronization device, referring to... Figure 8 The vehicle network time synchronization device 800 may include a memory 810, a processor 820, and a communication interface 830. The memory 810, processor 820, and communication interface 830 are connected via an internal connection path. The memory 810 stores instructions, and the processor 820 executes the instructions stored in the memory 810 to control the communication interface 830 to acquire information, thereby enabling the vehicle network time synchronization device 800 to implement the aforementioned vehicle network time synchronization method. Optionally, the memory 810 may be coupled to the processor 820 via an interface, or it may be integrated with the processor 820.

[0121] It should be noted that the communication interface 830 described above uses a transceiver device, such as, but not limited to, a transceiver. The communication interface 830 may also include an input / output interface.

[0122] The processor 820 stores one or more computer programs, which include instructions. When the instructions are executed by the processor 820, the in-vehicle network time synchronization device 800 performs the methods described in the above embodiments.

[0123] In implementation, each step of the above method can be completed by the integrated logic circuits in the hardware of the processor 820 or by instructions in software form. The method disclosed in the embodiments of this application can be directly implemented by the hardware processor, or by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory 810, and the processor 820 reads the information in memory 810 and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are not provided here.

[0124] As one possible implementation, the in-vehicle network time synchronization device 800 can be a physical device. For example, the in-vehicle network time synchronization device 800 may include one or more of the following modules: central processing unit, microprocessor, application-specific integrated circuit, field-programmable gate array, complex programmable logic device (CPLD), coprocessor (assisting the central processing unit in completing corresponding processing and applications), microcontroller unit (MCU), domain controller (DC), vehicle domain controller unit (VDC), electronic control unit (ECU), cockpit domain controller (CDC), vehicle integrated unit (VIU), vehicle control unit (VCU), motor control unit (MCU), etc. Furthermore, the in-vehicle network time synchronization device 800 includes at least one processor integrated in the form of a system-on-chip (SoC), which is commonly referred to as a SoC by those skilled in the art. The SoC may include at least one processor, and when the SoC includes multiple processors, the types of the multiple processors may be different.

[0125] Optionally, Figure 8 The memory 810 in the system can store data collected by sensors deployed on the vehicle, as well as mapping relationships, etc. Figure 8 The processor 820 in the above embodiment can implement the steps in the vehicle network time synchronization method.

[0126] This application also provides a computer-readable storage medium storing program code that, when run on a computer, causes the computer to perform any of the methods described in the above embodiments.

[0127] This application also provides a computer program product, which includes a computer program that, when run, causes the computer to perform any of the methods described in the above embodiments.

[0128] This application also provides a chip, including: a circuit for performing any of the methods in the above embodiments.

[0129] This application also provides a device, including... Figure 7 The vehicle network time synchronization device 700 shown is or Figure 8 The in-vehicle network time synchronization device 800 shown can perform any of the methods in the above embodiments.

[0130] This application also provides a vehicle, including... Figure 7 The vehicle network time synchronization device 700 shown is or Figure 8 The vehicle network time synchronization device 800 shown is shown.

[0131] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0132] 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.

[0133] 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. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0134] 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.

[0135] 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.

[0136] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a 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.

[0137] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included 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.

[0138] The terms "first," "second," etc., used in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the description of embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0139] It is understood that, in the embodiments of this application, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

Claims

1. A method for time synchronization in a vehicle network, characterized in that, Applied to the target node; The target node is any in-vehicle device in the vehicular network; the method includes: After the target node starts up, time synchronization parameters are read from the memory; the time synchronization parameters are stored in the memory by the target node before it stops running, and are used to synchronize time with the reference node; the reference node is an on-board device with a real-time clock, and the real-time clock has an independent power supply. Based on the time synchronization parameters, determine the clock offset of the target node relative to the reference node; Based on the clock offset, the local clock of the target node is calibrated to complete time synchronization between the target node and the reference node.

2. The method according to claim 1, characterized in that, Determining the clock offset of the target node relative to the reference node based on the time synchronization parameters includes: Obtain the reference node sending timestamp recorded when the reference node sends the synchronization message and the target node receiving timestamp recorded when the target node receives the synchronization message; The clock offset is determined based on the timestamp sent by the reference node, the timestamp received by the target node, and the path delay information; the path delay information represents the total link delay from the target node to the reference node.

3. The method according to claim 1, characterized in that, The method further includes: When the vehicle network enters a pre-sleep state, the time synchronization parameters used by the target node and the reference node for time synchronization are obtained, and the obtained time synchronization parameters are stored in the memory.

4. The method according to claim 3, characterized in that, The step of storing the acquired time synchronization parameters into a memory further includes: Perform cyclic redundancy check on the acquired time synchronization parameters to obtain the check value; The verification value is associated with the time synchronization parameter and stored in the memory.

5. The method according to claim 4, characterized in that, After reading the time synchronization parameters from the memory, the method further includes: The time synchronization parameters read are verified based on the verification value. If the time synchronization parameters pass the verification, the clock offset of the target node relative to the reference node is determined based on the time synchronization parameters. If the time synchronization parameters fail the verification, the path delay information from the target node to the reference node is reacquired.

6. The method according to claim 5, characterized in that, The step of obtaining the path delay information from the target node to the reference node includes: Starting from the target node, the link delay is determined hop-by-hop along the communication path between the target node and the reference node; The path delay information from the target node to the reference node is obtained by summing up the delays of each link determined hop by hop.

7. The method according to any one of claims 1-6, characterized in that, The time synchronization parameters include the identification information of the reference node, the path delay information from the target node to the reference node, and the frequency offset compensation coefficient of the target node's local crystal oscillator relative to the reference node.

8. The method according to any one of claims 1-6, characterized in that, The reference node is also used to start at a preset period when the vehicle is in a dormant state, obtain a standard timestamp through a satellite positioning system and / or a network time protocol, and calibrate the real-time clock according to the standard timestamp.

9. A vehicle-mounted network time synchronization device, characterized in that, Applied to the target node; The target node is any in-vehicle device in the vehicular network; the device includes: The data reading module is used to read time synchronization parameters from the memory after the target node is started; the time synchronization parameters are stored in the memory by the target node before it stops running, and are used for time synchronization with the reference node; the reference node is an on-board device with a real-time clock, and the real-time clock has an independent power supply. The deviation determination module is used to determine the clock offset of the target node relative to the reference node based on the time synchronization parameters. The clock calibration module is used to calibrate the local clock of the target node according to the clock offset, so as to complete the time synchronization between the target node and the reference node.

10. A vehicle-mounted network system, characterized in that, include: Reference nodes, including real-time clocks with independent power supplies, are used to provide a time synchronization reference; Multiple slave nodes are communicatively connected to the reference node via an in-vehicle network. Each slave node is an in-vehicle device in the in-vehicle network that relies on the reference node for clock calibration. The in-vehicle device includes a memory and a processor. The processor is configured to perform the method as described in any one of claims 1 to 8.

Images