Vehicle-mounted time synchronization method and device

Abstract

The invention provides a vehicle-mounted time synchronization method and device, and the method is applied to a vehicle-mounted network, and comprises the steps: obtaining the topology of the vehicle-mounted network, and determining a master clock and slave equipment according to the topology of the vehicle-mounted network; wherein the master clock and the slave device are connected through a network interface supporting a precise time protocol; broadcasting a synchronization message to the slave device through a preset frequency by using the master clock, wherein the synchronization message at least comprises a first timestamp of a moment when the synchronization message leaves the master clock through the network interface; receiving the synchronization message by using the slave device, and determining a second timestamp of the moment when the synchronization message reaches the slave device through the network interface; and pre-determining propagation delay, determining clock skew of the slave device according to the first timestamp, the second timestamp and the propagation delay, and synchronizing a local clock of the slave device according to the clock skew. The synchronization delay is avoided, and the time synchronization efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of data communication technology, and in particular to a vehicle-mounted time synchronization method and device. Background Art

[0002] Modern highway maintenance and inspection vehicles, including new energy vehicles, integrate a variety of sensors to acquire comprehensive road information. For example, these vehicles incorporate ground-penetrating radar (GPR), road surface damage monitoring systems, road grading systems, rutting systems, GNSS positioning systems, wheel speed encoders, cameras, and inertial navigation units (IMUs). Effective data fusion and analysis require precise temporal and spatial alignment of sensor data. This requires a unified, high-precision time base for each device in the vehicle network. Summary of the Invention

[0003] In view of this, the purpose of this application is to propose a vehicle-mounted time synchronization method and device that overcomes the above-mentioned problems or at least partially solves the above-mentioned problems.

[0004] Based on the above objectives, the first aspect of the present application provides a vehicle-mounted time synchronization method, which is applied to a vehicle-mounted network. The method includes: Obtaining an in-vehicle network topology, and determining a master clock and a slave device based on the in-vehicle network topology; wherein the master clock and the slave device are connected via a network interface supporting a precision time protocol; Broadcasting a synchronization message to the slave device using the master clock at a preset frequency, the synchronization message including at least a first timestamp of a time when the synchronization message leaves the master clock through the network interface; receiving the synchronization message by the slave device, and determining a second timestamp of a time when the synchronization message arrives at the slave device through the network interface; A propagation delay is predetermined, a clock deviation of the slave device is determined according to the first timestamp, the second timestamp, and the propagation delay, and a local clock of the slave device is synchronized according to the clock deviation.

[0005] Optionally, broadcasting a synchronization message to the slave device using the master clock at a preset frequency, the synchronization message including at least a first timestamp of a moment when the synchronization message leaves the master clock through the network interface, includes: generating the synchronization message using the master clock and broadcasting the synchronization message to the slave device via the network interface; The network interface is used to capture the time when the synchronization message leaves the master clock and enters the network interface, and the time is filled into the synchronization message as a first timestamp.

[0006] Optionally, the synchronization message further includes: a message header, the message header including at least a synchronization message type; and a port number of the master clock broadcasting the synchronization message; broadcasting a synchronization message to the slave device using the master clock at a preset frequency, the synchronization message including at least a first timestamp of the time when the synchronization message leaves the master clock through the network interface, and then further comprising: identifying a data flow between the master clock and the slave device using the network interface; In response to the message type in the field of the data stream being a synchronous message type; or In response to the port number in the field of the data stream being the port number of the master clock broadcasting the synchronization message, the data stream is determined to be a synchronization message, and the priority tag of the synchronization message is set to the first priority for broadcasting using the network interface.

[0007] Optionally, receiving the synchronization message by the slave device and determining a second timestamp of a time when the synchronization message arrives at the slave device through the network interface includes: The slave device is used to capture the moment when the synchronization message leaves the network interface and enters the slave device, and the moment is used as a second timestamp and synchronized to the local slave device.

[0008] Optionally, predetermine the propagation delay, including: generating a delay request message in advance using the slave device and broadcasting it to the master clock via the network interface; capturing, by using the network interface, a moment when the delay request message leaves the slave device and enters the network interface, and filling the moment as a third timestamp into the delay request message; Using the master clock to capture the moment when the delay request message leaves the network interface and enters the master clock, and synchronizing the moment as a fourth timestamp to the master clock locally; broadcasting the fourth timestamp to the slave device using a master clock; determining, using the slave device, a propagation delay based on the first timestamp, the second timestamp, the third timestamp, and the fourth timestamp; The propagation delay is expressed as: Propagation_Delay = [(T4 - T1) - (T2 - T3)] / 2), Among them, T1, T2, T3, and T4 represent the first timestamp, the second timestamp, the third timestamp, and the fourth timestamp, respectively.

[0009] Optionally, determining a clock deviation of the slave device according to the first timestamp, the second timestamp, and the propagation delay, and synchronizing a local clock of the slave device according to the clock deviation includes: determining a clock deviation of the slave device relative to the master clock based on a difference between the second timestamp, the first timestamp, and the propagation delay; synchronizing the local clock of the slave device using the sum of the current local clock of the slave device and the clock deviation; The clock offset is expressed as: Offset = T2 - T1 - Propagation_Delay.

[0010] Optionally, obtaining an in-vehicle network topology and determining a master clock and a slave device according to the in-vehicle network topology includes: Determining the number of industrial control computers according to the vehicle network topology; In response to the number of the industrial control computer being one and the industrial control computer being connected to a timing satellite, determining the industrial control computer as a master clock, and determining the sensor device connected to the master clock via a network interface as a slave device; In response to the fact that there are multiple industrial control computers, the industrial control computer connected to the timing satellite is determined to be the master clock, and the remaining industrial control computers are determined to be slave devices; and the sensor connected to the master clock and the slave device through the network interface is determined to be the slave device.

[0011] Optionally, the method further includes: Between any two synchronization messages, using the slave device to determine a clock drift rate of the slave device according to a ratio of a difference between the second timestamp and the first timestamp to an inverse of a preset frequency; In response to the clock drift rate being less than a preset threshold, reducing the preset frequency; In response to the clock drift rate being greater than or equal to a preset threshold, the preset frequency is increased, and the slave device is used to predictively compensate the local clock of the slave device between any two synchronization messages according to the clock drift rate.

[0012] Optionally, the method further includes: In response to any sensor not supporting the precise time protocol and being connected to the master clock, determining a local clock of the master clock and sharing the local clock of the master clock with the sensor; In response to any sensor not supporting the precise time protocol and being connected to the slave device, a synchronized local clock of the slave device is determined, and the synchronized local clock of the slave device is shared with the sensor.

[0013] In a second aspect of the present application, a vehicle-mounted time synchronization device is provided, comprising: a determination module, configured to obtain an in-vehicle network topology and determine a master clock and a slave device based on the in-vehicle network topology; wherein the master clock and the slave device are connected via a network interface supporting a precision time protocol; a sending module, configured to broadcast a synchronization message to the slave device using the master clock at a preset frequency, the synchronization message including at least a first timestamp of a moment when the synchronization message leaves the master clock through the network interface; a receiving module, configured to receive the synchronization message using the slave device, and determine a second timestamp of a time when the synchronization message arrives at the slave device through the network interface; A synchronization module is configured to predetermine a propagation delay, determine a clock deviation of the slave device according to the first timestamp, the second timestamp, and the propagation delay, and synchronize a local clock of the slave device according to the clock deviation.

[0014] From the above, it can be seen that the vehicle-mounted time synchronization method provided by the present application utilizes a mode of one-way broadcast synchronization messages from the master clock to the slave device, thereby saving the response time of the slave device. At the same time, the one-way broadcast is combined with the obtained hardware timestamps, namely the first timestamp and the second timestamp, to achieve end-to-end rapid synchronization message transmission between the master clock and the slave device, thereby avoiding synchronization delays. It is suitable for use scenarios with high real-time requirements, especially in-vehicle scenarios. At the same time, the hardware timestamp has higher accuracy, which avoids delays caused by software processing and greatly improves the accuracy of time synchronization. At the same time, the mode of one-way broadcast synchronization messages reduces network bandwidth occupancy and node processing burden, and is more suitable for vehicle-mounted networks with limited bandwidth and computing resources. It further ensures the priority transmission of synchronization messages and reduces synchronization delays caused by network congestion. Finally, for devices that do not support the precise time protocol, synchronization is performed through local clock sharing to achieve data alignment.

[0015] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are specifically listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions in this application or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are merely embodiments of this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0017] Figure 1 This is a flow chart of a vehicle-mounted time synchronization method 100 according to an embodiment of the present application; Figure 2 A schematic diagram of an in-vehicle network topology according to an embodiment of the present application; Figure 3 This is a flowchart of determining a first timestamp according to an embodiment of the present application; Figure 4 This is a schematic diagram of determining clock deviation according to an embodiment of the present application; Figure 5 A schematic diagram of synchronizing a local clock of a slave device according to an embodiment of the present application; Figure 6 A schematic diagram of a vehicle-mounted time synchronization device according to an embodiment of the present application; Figure 7 This is a schematic diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0018] In order to make the objectives, technical solutions and advantages of this application more clear, this application is further described in detail below in combination with specific embodiments and with reference to the accompanying drawings.

[0019] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present application should have the usual meanings understood by people with ordinary skills in the field to which this application belongs. The "first", "second" and similar words used in the embodiments of the present application do not indicate any order, quantity or importance, but are only used to distinguish different components. "Include" or "comprise" and similar words mean that the elements or objects appearing before the word cover the elements or objects listed after the word and their equivalents, without excluding other elements or objects. "Connect" or "connected" and similar words are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. "Up", "down", "left", "right" and the like are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0020] In some embodiments, network time synchronization protocols include the Network Time Protocol (NTP) and the Precision Time Protocol (PTP). NTP is complex to configure, supports limited devices, and has poor compatibility. While PTP can achieve sub-microsecond synchronization accuracy, its standard protocol stack is relatively complex and it uses bidirectional message exchange for time synchronization.

[0021] However, for in-vehicle networks, where the network topology is relatively fixed, the network environment is controllable, and the number of network devices is limited, the PTP protocol also has the following shortcomings: First, the protocol overhead is high: realizing two-way message exchange inevitably requires the two parties exchanging messages to implement a two-way handshake, which increases the network communication burden and the computational complexity of the two-way nodes.

[0022] Second, potential delay increase: The request / response pattern in the two-way handshake itself introduces additional interaction delay.

[0023] Third, complex configuration: PTP has many parameters, and the optimized configuration for a specific environment is relatively complex.

[0024] Fourth, management in a multi-IPC environment: In a complex in-vehicle network containing multiple industrial computers (IPCs), standard PTP management and the stability of the master clock face challenges.

[0025] Therefore, considering the characteristics of in-vehicle networks, a more efficient, low-latency and high-precision time synchronization solution is needed.

[0026] Based on this, an embodiment of the present application provides an in-vehicle time synchronization method, which is applied to an in-vehicle network. The method includes: obtaining an in-vehicle network topology and determining a master clock and a slave device based on the in-vehicle network topology; wherein the master clock and the slave device are connected via a network interface that supports the Precision Time Protocol; utilizing the master clock to broadcast a synchronization message to the slave device at a preset frequency, wherein the synchronization message includes at least a first timestamp of the time when the synchronization message leaves the master clock via the network interface; utilizing the slave device to receive the synchronization message and determine a second timestamp of the time when the synchronization message arrives at the slave device via the network interface; predetermining a propagation delay, determining a clock deviation of the slave device based on the first timestamp, the second timestamp, and the propagation delay, and synchronizing the local clock of the slave device based on the clock deviation. The method utilizes a one-way broadcast mode of the synchronization message from the master clock to the slave device, thereby saving the response time of the slave device. At the same time, the one-way broadcast is combined with the obtained hardware timestamps, namely the first timestamp and the second timestamp, to achieve end-to-end rapid synchronization message transmission between the master clock and the slave device, avoiding synchronization delay. The method is suitable for use scenarios with high real-time requirements, especially in-vehicle scenarios. At the same time, the hardware timestamp has higher accuracy, avoiding delays caused by software processing, and significantly improving the accuracy of time synchronization. The one-way broadcast synchronization message model reduces network bandwidth usage and node processing burden, making it more suitable for in-vehicle networks with limited bandwidth and computing resources. This further ensures the priority transmission of synchronization messages, reducing synchronization delays caused by network congestion. Finally, for devices that do not support the Precision Time Protocol, synchronization is achieved through local clock sharing, thereby achieving data alignment.

[0027] refer to Figure 1As shown, an in-vehicle time synchronization method 100 provided in an embodiment of the present application is applied to an in-vehicle network. The method 100 starts with step S101, obtains the in-vehicle network topology, and determines the master clock and the slave device according to the in-vehicle network topology, wherein the master clock and the slave device are connected through a network interface that supports the precision time protocol.

[0028] In an exemplary embodiment, an in-vehicle network includes various devices, such as industrial computers and sensors. Precise temporal alignment of sensor data is essential. The industrial computer then fuses this precisely aligned data to achieve precise spatial registration, facilitating subsequent operations. For example, a camera and a ground-penetrating radar (GPR) are used as sensors. If sensor data indicates a pothole on the road ahead, the camera and GPR data are synchronized and aligned. The industrial computer then determines the spatial location of the pothole, i.e., its distance from the pothole, based on this aligned data. Subsequently, actions such as deceleration or stopping are performed based on the pothole's location. If the industrial computer, camera, and GPR are not synchronized, the collected data will also be out of sync, impacting subsequent operations.

[0029] It can be understood that the synchronization message is a time synchronization message.

[0030] In some embodiments, obtaining a vehicle network topology and determining a master clock and a slave device based on the vehicle network topology includes: Determine the number of industrial control computers based on the vehicle network topology.

[0031] It is understood that in an in-vehicle network, industrial computers enable intelligent management of vehicle systems through hardware integration and software algorithms. Their functions include real-time monitoring and vehicle control, data communication and network collaboration, intelligent services and functional expansion, environmental adaptation and safety assurance, energy efficiency optimization, and operations and maintenance management. Due to the corresponding functions of the industrial computer, in this embodiment of the application, the industrial computer is determined to be the master clock.

[0032] In response to the fact that there is one industrial control computer and the industrial control computer is connected to a timing satellite, the industrial control computer is determined to be a master clock, and the sensor device connected to the master clock through a network interface is determined to be a slave device.

[0033] In an exemplary embodiment, the industrial control computer is connected to the timing satellite via PPS (Pulse Per Second) timing. It is understood that PPS timing is a high-precision time synchronization technology based on GNSS receivers and will not be described in detail here.

[0034] Only one industrial control computer is connected to the timing satellite. The main control computer serves as the master clock. The master clock's local clock is precisely trained using the PPS signal from the timing satellite, ensuring the accuracy of the master clock's local clock. The master clock then uses a one-way broadcast synchronization message to the slave device, reducing the slave's response time. This one-way broadcast, combined with the acquired hardware timestamps (primary and secondary timestamps), enables fast, end-to-end synchronization message delivery between the master clock and the slave device, avoiding synchronization delays.

[0035] In response to the fact that there are multiple industrial control computers, the industrial control computer connected to the timing satellite is determined to be the master clock, and the remaining industrial control computers are determined to be slave devices; and the sensor connected to the master clock and the dynamic device through the network interface is determined to be the slave device.

[0036] refer to Figure 2 The figure shows a schematic diagram of a vehicle network topology provided by an embodiment of the present application, wherein the network topology includes three industrial control computers and other sensors such as wheel encoders, cameras, and ground penetrating radars. The industrial control computer connected to the timing satellite is determined to be the master clock, i.e. Figure 2 The master IPC in the system is the master IPC, and the remaining two industrial computers are slave devices. The wheel encoder connected to the master clock and the camera and ground penetrating radar connected to the slave devices are also slave devices.

[0037] In the prior art, when multiple industrial computers are present, each is connected to a timing satellite. This means that each computer acts as a master clock, implementing a two-way handshake with a slave device. This increases the network communication burden and computational complexity of the two-way nodes (master clock and slave device). Furthermore, each computer requires a corresponding GNSS receiver to receive PPS timing from the timing satellite, increasing costs.

[0038] In this embodiment, when there are multiple industrial computers, one is designated as the master clock. This master clock's local clock is accurately trained using the PPS signal from a timing satellite. This ensures the accuracy of the master clock's local clock. The master clock then uses a unidirectional broadcast synchronization message to the slave devices (the remaining industrial computers and sensors), reducing the slave device's response time. This unidirectional broadcast, combined with the acquired hardware timestamps (i.e., the first and second timestamps), enables fast, end-to-end synchronization message delivery between the master clock and the slave devices, avoiding synchronization delays.

[0039] In an exemplary embodiment, the network interface may be a network card supporting the Precision Event Protocol, or an Ethernet switch supporting the Precision Time Protocol, which is not specifically limited herein.

[0040] In an exemplary embodiment, the precision time protocol may be the IEEE 1588 protocol.

[0041] Thereafter, in step S102 , the master clock is used to broadcast a synchronization message to the slave device at a preset frequency. The synchronization message includes at least a first timestamp of the moment when the synchronization message leaves the master clock through the network interface.

[0042] In this embodiment, when the master clock unidirectionally broadcasts a synchronization message to a slave device, the synchronization message includes capturing the moment when the synchronization message leaves the master clock using a network interface that supports the Precision Time Protocol as a first timestamp. It is understood that the first timestamp is directly acquired using the network interface, that is, directly acquired by hardware. This unidirectional broadcast reduces the number of interactions between the master clock and the slave device and the master clock's load. The master clock does not need to wait for the slave device to respond and return data, which reduces synchronization latency and improves synchronization efficiency. This is suitable for network environments with high real-time requirements. Combined with direct hardware acquisition of the first timestamp, the first timestamp is more accurate, significantly improving the accuracy of time synchronization.

[0043] In some exemplary embodiments, the preset period may be 10 ms.

[0044] In some embodiments, reference Figure 3 As shown, the master clock is used to broadcast synchronization messages to the slave devices at a preset frequency, specifically including: S201: Generate a synchronization message using a master clock and broadcast it to slave devices through a network interface.

[0045] In this step, the synchronization message generated by the master clock does not include the first timestamp.

[0046] In some embodiments, the synchronization message may include a message header, the message header including at least the synchronization message type; and a port number of the master clock broadcasting the synchronization message.

[0047] In an exemplary embodiment, the message header may further include a version number, a synchronization message length, and the like.

[0048] In an exemplary embodiment, the synchronization message may further include a sequence number and a checksum, wherein the sequence number may identify the broadcast order of the synchronization message, and the slave device may use the checksum to verify the integrity of the synchronization message.

[0049] S202: Use the network interface to capture the moment when the synchronization message leaves the master clock and enters the network interface, and fill the moment as a first timestamp into the synchronization message.

[0050] In this step, the network interface is used to capture the precise moment when the synchronization message is about to be sent out through the network interface, and the moment is used as the first timestamp. The first timestamp is included in the synchronization message and broadcasted to the slave device along with the synchronization message.

[0051] In an exemplary embodiment, the network interface supports the Precision Time Protocol. Accordingly, the network interface also includes a hardware clock supporting the Precision Time Protocol, that is, a PHP hardware clock. The first timestamp is directly captured using the PHP hardware clock.

[0052] In an exemplary embodiment, the OSI seven-layer model is a conceptual framework for network communications proposed by the International Organization for Standardization, comprising the physical layer, data link layer, network layer, transport layer, session layer, presentation layer, and application layer. The PHP hardware clock can capture the first timestamp of synchronization messages directly at the physical layer, eliminating protocol stack processing delays.

[0053] In some embodiments, after step S102, the method further includes: The data flow between the master clock and the slave devices is identified using the network interface.

[0054] It is understood that in addition to broadcasting synchronization messages to slave devices, the master clock and slave devices may also exchange data, such as broadcasting control instructions and other data streams. To ensure the priority of synchronization messages in network transmission and reduce synchronization message transmission delays caused by other data streams occupying network bandwidth, this embodiment requires distinguishing between synchronization messages and other data streams.

[0055] In response to the message type in the field of the data stream being a synchronization message type; or in response to the port number in the field of the data stream being the port number of the master clock broadcasting the synchronization message, the data stream is determined to be a synchronization message, and the priority mark of the synchronization message is set to the first priority for broadcasting using the network interface.

[0056] In this embodiment, the synchronization message type and the port number of the master clock broadcasting the synchronization message are determined and unique. By determining the field in the message header of the synchronization message, determining that the message type is the synchronization message type or determining that the synchronization message is broadcast through the port number of the synchronization message, it can be determined that the data stream is the synchronization message, and the synchronization message is marked as the first priority for broadcasting, ensuring the priority of the synchronization message in the network transmission and reducing the synchronization message transmission delay caused by other data streams occupying the network bandwidth.

[0057] In an exemplary embodiment, priorities include first, second, third, fourth, and fifth priorities, where the first priority may include synchronization messages. The second priority may include key point control instructions and sensor data with extremely high real-time requirements, such as key frame images / video streams. The third priority may include ordinary sensor data, such as ground penetrating radar sensor data, road surface damage system data, and smoothness system data. The fourth priority may include diagnostic information from different nodes (master clock or slave device) in the vehicle network topology, log file transmission, and other data. The fifth priority may include background traffic of the vehicle network, such as the need for background basic data. When data streams are transmitted simultaneously, the first priority has the highest priority and the fifth priority has the lowest priority.

[0058] In an exemplary embodiment, the priority broadcasting of synchronization messages may also be achieved by supporting a Quality of Service (QoS) mechanism through a network interface.

[0059] Thereafter, in step S103 , the synchronization message is received by the slave device to determine a second timestamp of the moment when the synchronization message reaches the slave device through the network interface.

[0060] In this embodiment, the principle behind the first timestamp is the same: the master clock unidirectionally broadcasts synchronization messages to the slave devices to synchronize the slave devices with the master clock. The second timestamp is the moment when the synchronization message reaches the slave device, captured by the slave device. This second timestamp is directly acquired by the slave device, i.e., directly by hardware. This second timestamp offers greater precision, significantly improving time synchronization accuracy.

[0061] In some embodiments, determining, by receiving a synchronization message from a slave device, a second timestamp of a time when the synchronization message reaches the slave device through a network interface includes: The slave device is used to capture the moment when the synchronization message leaves the network interface and enters the slave device, and the moment is used as the second timestamp to be synchronized to the local slave device.

[0062] Then, in step S104 , a propagation delay is predetermined, and a clock deviation of the slave device is determined according to the first timestamp, the second timestamp, and the propagation delay. The local clock of the slave device is synchronized according to the clock deviation.

[0063] Based on the first timestamp, the second timestamp and the propagation delay, the clock deviation of the second timestamp relative to the first timestamp, that is, the clock deviation of the slave device, can be determined. Based on the clock deviation, the local clock of the slave device is adjusted to achieve time alignment of the local clock of the slave device with the local clock of the master device.

[0064] For example, if the first timestamp is 10:30:33, the second timestamp is 10:30:33, and the propagation delay is 1 second, then the local time of the slave device is obviously 1 second faster than the local time of the master clock. The local clock of the slave device is adjusted to be 1 second slower.

[0065] It will be understood that the 1s delay is merely an example and is not a limitation to the embodiments of the present application.

[0066] In some embodiments, reference Figure 4 、 Figure 5 As shown, the propagation delay is predetermined and includes: A delay request message is generated in advance by a slave device and broadcasted to the master clock via a network interface.

[0067] In this step, the delay request message Delay_Req may be a low-frequency bidirectional exchange message.

[0068] This pre-process can occur when the vehicle network is started or during regular maintenance.

[0069] The network interface is used to capture the moment when the delay request message leaves the slave device and enters the network interface, and the moment is filled into the delay request message as a third timestamp.

[0070] It is understandable that the acquisition principle of the third timestamp is the same as that of the first timestamp, except that the first timestamp is the moment when the synchronization message leaves the master clock, while the third timestamp is the moment when the delay request message leaves the slave device.

[0071] The master clock is used to capture the moment when the delay request message leaves the network interface and enters the master clock, and the moment is synchronized to the master clock locally as the fourth timestamp.

[0072] It can be understood that the acquisition of the fourth timestamp is the same as that of the second timestamp, except that the second timestamp is the time when the synchronization message enters the local slave device, while the fourth timestamp is the time when the delay request message enters the local master clock.

[0073] The fourth timestamp is broadcasted to the slave devices using the master clock.

[0074] It can be understood that the slave device obtains the third timestamp in advance and obtains the first timestamp and the second timestamp through the synchronization message. The purpose of the embodiment of the present application is to achieve time synchronization between the slave device and the master clock. Therefore, the fourth timestamp is broadcast to the slave device to facilitate the slave device to calculate the local clock deviation, thereby synchronizing the local clock.

[0075] The above process of obtaining the third timestamp and the fourth timestamp is a preset process, which avoids bandwidth occupation during the delay request message broadcast, affecting the synchronization message broadcast, or temporarily obtaining the third timestamp and the fourth timestamp, causing time waste in subsequent calculation and propagation delay.

[0076] It should be noted that if there are multiple slave devices, the above process of obtaining the third and fourth timestamps must be repeated multiple times. For example, if the slave devices include a camera and a ground-penetrating radar, the third and fourth timestamps of the delay request message broadcast by the camera and the ground-penetrating radar, respectively, must be obtained when the delay request message reaches the master clock. This facilitates the subsequent calculation of propagation delay.

[0077] determining a propagation delay based on the first time stamp, the second time stamp, the third time stamp, and the fourth time stamp using a master clock; The propagation delay is expressed as: Propagation_Delay = [(T4 - T1) - (T2 - T3)] / 2), Among them, T1, T2, T3, and T4 represent the first timestamp, the second timestamp, the third timestamp, and the fourth timestamp, respectively.

[0078] In some embodiments, determining a clock deviation of the slave device based on the first timestamp, the second timestamp, and the propagation delay, and synchronizing a local clock of the slave device based on the clock deviation includes: A clock offset of the slave device relative to the master clock is determined based on a difference between the second timestamp, the first timestamp, and the propagation delay.

[0079] The clock offset is expressed as: Offset = T2 - T1 - Propagation_Delay.

[0080] The local clock of the slave device is synchronized using the sum of the current local clock of the slave device and the clock deviation.

[0081] In this step, for example, if the first timestamp is 10:30:33, the second timestamp is 10:30:33, and the propagation delay is 1s, then the local time of the slave device is obviously 1s faster than the local time of the master clock. The resulting clock deviation is -1s. Using the sum of the second timestamp 10:30:33 and -1s, the local clock of the synchronized slave device is 10:30:32. Figure 5 As shown, it is t0 +Offset.

[0082] At this point, the time synchronization between the slave device and the master clock is completed.

[0083] In some embodiments, the method further comprises: Between any two synchronization messages, the slave device determines the clock drift rate of the slave device according to the ratio of the difference between the second timestamp and the first timestamp to the inverse of the preset frequency.

[0084] It can be understood that the reciprocal of the frequency is the period, that is, the time interval for the master device to broadcast the synchronization message to the slave device.

[0085] The drift rate can be expressed as: A=(T2-T1) / T. T is the period, which is the reciprocal of the frequency.

[0086] In response to the clock drift rate being less than a preset threshold, reducing the preset frequency; In response to the clock drift rate being greater than or equal to a preset threshold, the preset frequency is increased, and the slave device is used to predictively compensate the local clock of the slave device between any two synchronization messages according to the clock drift rate.

[0087] In an exemplary embodiment, the preset threshold may be 0.001.

[0088] It is understandable that the smaller the clock drift rate, the smaller the time deviation of the slave device compared to the master clock, and the preset frequency of the master clock broadcasting synchronization messages to the slave device can be appropriately reduced. The larger the clock offset rate, the greater the time deviation of the slave device compared to the master clock, and the preset frequency of the master clock broadcasting synchronization messages to the slave device can be appropriately increased to avoid excessive clock deviation of the slave device relative to the master clock. At the same time, after completing a synchronization message broadcast, the slave device uses the synchronized local clock to capture a second timestamp for the data. However, there is still a clock deviation in the slave device between the two synchronization messages. The offset rate is used to compensate the local clock of the slave device to avoid excessive clock deviation of the slave device relative to the master clock between the two synchronization messages.

[0089] In some embodiments, the method further comprises: In response to any sensor not supporting the precision time protocol and being connected to a master clock, determining a local clock of the master clock and sharing the local clock of the master clock to the sensor; In response to any sensor not supporting the precision time protocol and being connected to a slave device, a synchronized local clock of the slave device is determined, and the synchronized local clock of the slave device is shared with the sensor.

[0090] In this embodiment, reference Figure 2 As shown, the sensor that does not support precise time includes a wheel encoder, and the wheel encoder itself does not have a local clock. In this case, the wheel encoder is connected to a master clock, and the local clock of the master clock is shared with the wheel encoder to align the transmission data of the wheel encoder with the transmission data of other sensors.

[0091] If the wheel encoder is connected to a slave device, the local clock synchronized by the slave device is shared with the wheel encoder so that the transmission data of the wheel encoder is aligned with the transmission data of other sensors.

[0092] It should be noted that the method of the embodiment of the present application can be performed by a single device, such as a computer or server. The method of this embodiment can also be applied in a distributed scenario and performed by multiple devices working together. In such a distributed scenario, one of the multiple devices may only perform one or more steps of the method of the embodiment of the present application, and the multiple devices will interact with each other to complete the method.

[0093] It should be noted that the above description is limited to some embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in an order different from that described in the above embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0094] Based on the same technical concept, corresponding to any of the above-mentioned embodiment methods, the present application also provides a vehicle-mounted time synchronization device.

[0095] refer to Figure 6 , the vehicle-mounted time synchronization device comprises: Determination module 601, used to obtain the vehicle network topology and determine the master clock and the slave device according to the vehicle network topology; wherein the master clock and the slave device are connected via a network interface supporting the precision time protocol; A sending module 602 is configured to broadcast a synchronization message to a slave device using a master clock at a preset frequency, where the synchronization message includes at least a first timestamp of a time when the synchronization message leaves the master clock through a network interface; A receiving module 603 is configured to receive a synchronization message from a slave device and determine a second timestamp of a time when the synchronization message arrives at the slave device through a network interface; The synchronization module 604 is configured to predetermine a propagation delay, determine a clock deviation of the slave device according to the first timestamp, the second timestamp, and the propagation delay, and synchronize a local clock of the slave device according to the clock deviation.

[0096] For the convenience of description, the above devices are described as being divided into various modules according to their functions. Of course, when implementing this application, the functions of each module can be implemented in the same or multiple software and / or hardware.

[0097] The device of the above embodiment is used to implement the corresponding vehicle-mounted time synchronization method in any of the above embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be repeated here.

[0098] Based on the same technical concept, corresponding to any of the above-mentioned embodiments, the present application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and runnable on the processor. When the processor executes the program, it implements the vehicle-mounted time synchronization method described in any of the above embodiments.

[0099] Figure 7 A more specific hardware structure diagram of an electronic device provided in this embodiment is shown. The device may include: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040 are communicatively connected to each other within the device via the bus 1050.

[0100] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0101] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage devices, dynamic storage devices, etc. The memory 1020 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0102] The input / output interface 1030 is used to connect to input / output modules to enable information input and output. The input / output modules can be configured as components within the device (not shown) or externally connected to the device to provide corresponding functions. Input devices may include a keyboard, mouse, touch screen, microphone, and various sensors. Output devices may include a display, speaker, vibrator, indicator light, and the like.

[0103] The communication interface 1040 is used to connect to a communication module (not shown) to enable communication between the device and other devices. The communication module can communicate via wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, Wi-Fi, Bluetooth, etc.).

[0104] The bus 1050 comprises a pathway for transmitting information between various components of the device, such as the processor 1010 , the memory 1020 , the input / output interface 1030 , and the communication interface 1040 .

[0105] It should be noted that although the above device only shows the processor 1010, the memory 1020, the input / output interface 1030, the communication interface 1040, and the bus 1050, in a specific implementation, the device may also include other components necessary for normal operation. In addition, it will be understood by those skilled in the art that the above device may only include the components necessary to implement the embodiments of this specification, and does not necessarily include all the components shown in the figure.

[0106] The electronic device of the above embodiment is used to implement the corresponding vehicle-mounted time synchronization method in any of the above embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be repeated here.

[0107] Based on the same technical concept, corresponding to any of the above-mentioned embodiment methods, the present application also provides a non-transitory computer-readable storage medium, which stores computer instructions, and the computer instructions are used to enable the computer to execute the vehicle-mounted time synchronization method described in any of the above embodiments.

[0108] The computer-readable media of this embodiment includes permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device.

[0109] The computer instructions stored in the storage medium of the above embodiment are used to enable the computer to execute the vehicle-mounted time synchronization method described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0110] Based on the same inventive concept, corresponding to the vehicle-mounted time synchronization method described in any of the above embodiments, the present disclosure further provides a computer program product comprising computer program instructions. In some embodiments, the computer program instructions can be executed by one or more processors of a computer to cause the computer and / or the processor to perform the vehicle-mounted time synchronization method. For the execution entities corresponding to the steps in each embodiment of the vehicle-mounted time synchronization method, the processors executing the corresponding steps can belong to the corresponding execution entities.

[0111] The computer program product of the above embodiment is used to enable the computer and / or the processor to execute the vehicle-mounted time synchronization method described in any of the above embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0112] Those skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of the present application (including the claims) is limited to these examples. Within the scope of the present application, the technical features in the above embodiments or different embodiments may be combined, the steps may be implemented in any order, and there are many other variations of the different aspects of the embodiments of the present application as described above, which are not provided in detail for the sake of simplicity.

[0113] In addition, to simplify the description and discussion, and to avoid obscuring the understanding of the embodiments of the present application, well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided figures. Furthermore, devices may be shown in block diagram form to avoid obscuring the understanding of the embodiments of the present application, and this also takes into account the fact that the implementation details of these block diagram devices are highly dependent on the platform on which the embodiments of the present application will be implemented (i.e., these details should be fully understood by those skilled in the art). Where specific details (e.g., circuits) are set forth to describe the exemplary embodiments of the present application, it will be apparent to those skilled in the art that the embodiments of the present application can be implemented without these specific details or with variations therefrom. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0114] Although the present invention has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of these embodiments will be apparent to those skilled in the art based on the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may utilize the discussed embodiments.

[0115] The embodiments of the present application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of the present application should be included in the scope of protection of this application.

Claims

1. A vehicle-mounted time synchronization method, characterized in that: Applied to an in-vehicle network, the method includes: Obtaining an in-vehicle network topology, and determining a master clock and a slave device based on the in-vehicle network topology; wherein the master clock and the slave device are connected via a network interface supporting a precision time protocol; Broadcasting a synchronization message to the slave device using the master clock at a preset frequency, the synchronization message including at least a first timestamp of a time when the synchronization message leaves the master clock through the network interface; receiving the synchronization message by the slave device, and determining a second timestamp of a time when the synchronization message arrives at the slave device through the network interface; A propagation delay is predetermined, a clock deviation of the slave device is determined according to the first timestamp, the second timestamp, and the propagation delay, and a local clock of the slave device is synchronized according to the clock deviation.

2. The method according to claim 1, characterized in that Broadcasting a synchronization message to the slave device using the master clock at a preset frequency, the synchronization message including at least a first timestamp of the moment when the synchronization message leaves the master clock through the network interface, including: generating the synchronization message using the master clock and broadcasting the synchronization message to the slave device via the network interface; The network interface is used to capture the time when the synchronization message leaves the master clock and enters the network interface, and the time is filled into the synchronization message as a first timestamp.

3. The method according to claim 2, characterized in that The synchronization message further includes: a message header, the message header including at least a synchronization message type; and a port number of the master clock broadcasting the synchronization message; broadcasting a synchronization message to the slave device using the master clock at a preset frequency, the synchronization message including at least a first timestamp of the time when the synchronization message leaves the master clock through the network interface, and then further comprising: identifying a data flow between the master clock and the slave device using the network interface; In response to the message type in the field of the data stream being a synchronous message type; or In response to the port number in the field of the data stream being the port number of the master clock broadcasting the synchronization message, the data stream is determined to be a synchronization message, and the priority tag of the synchronization message is set to the first priority for broadcasting using the network interface.

4. The method according to claim 1, wherein Receiving the synchronization message by the slave device and determining a second timestamp of a time when the synchronization message arrives at the slave device through the network interface includes: The slave device is used to capture the moment when the synchronization message leaves the network interface and enters the slave device, and the moment is used as a second timestamp and synchronized to the local slave device.

5. The method according to claim 1, wherein Predetermine the propagation delay, including: generating a delay request message in advance using the slave device and broadcasting it to the master clock via the network interface; capturing, by using the network interface, a moment when the delay request message leaves the slave device and enters the network interface, and filling the moment as a third timestamp into the delay request message; Using the master clock to capture the moment when the delay request message leaves the network interface and enters the master clock, and synchronizing the moment as a fourth timestamp to the master clock locally; broadcasting the fourth timestamp to the slave device using a master clock; determining, using the slave device, a propagation delay based on the first timestamp, the second timestamp, the third timestamp, and the fourth timestamp; The propagation delay is expressed as: Propagation_Delay = [(T4 - T1) - (T2 - T3)] / 2), Among them, T1, T2, T3, and T4 represent the first timestamp, the second timestamp, the third timestamp, and the fourth timestamp, respectively.

6. The method according to claim 5, characterized in that Determining a clock deviation of the slave device according to the first timestamp, the second timestamp, and the propagation delay, and synchronizing a local clock of the slave device according to the clock deviation, comprising: determining a clock deviation of the slave device relative to the master clock based on a difference between the second timestamp, the first timestamp, and the propagation delay; synchronizing the local clock of the slave device using the sum of the current local clock of the slave device and the clock deviation; The clock offset is expressed as: Offset = T2 - T1 - Propagation_Delay.

7. The method according to claim 1, characterized in that Obtaining a vehicle network topology and determining a master clock and a slave device based on the vehicle network topology, including: Determining the number of industrial control computers according to the vehicle network topology; In response to the number of the industrial control computer being one and the industrial control computer being connected to a timing satellite, determining the industrial control computer as a master clock, and determining the sensor device connected to the master clock via a network interface as a slave device; In response to the fact that there are multiple industrial control computers, the industrial control computer connected to the timing satellite is determined to be the master clock, and the remaining industrial control computers are determined to be slave devices; and the sensor connected to the master clock and the slave device through the network interface is determined to be the slave device.

8. The method according to claim 1, characterized in that The method further comprises: Between any two synchronization messages, using the slave device to determine a clock drift rate of the slave device according to a ratio of a difference between the second timestamp and the first timestamp to an inverse of a preset frequency; In response to the clock drift rate being less than a preset threshold, reducing the preset frequency; In response to the clock drift rate being greater than or equal to a preset threshold, the preset frequency is increased, and the slave device is used to predictively compensate the local clock of the slave device between any two synchronization messages according to the clock drift rate.

9. The method according to claim 1, further comprising: In response to any sensor not supporting the precise time protocol and being connected to the master clock, determining a local clock of the master clock and sharing the local clock of the master clock with the sensor; In response to any sensor not supporting the precise time protocol and being connected to the slave device, a synchronized local clock of the slave device is determined, and the synchronized local clock of the slave device is shared with the sensor.

10. A vehicle-mounted time synchronization device, characterized in that: include: A determination module, configured to obtain a vehicle network topology and determine a master clock and a slave device according to the vehicle network topology; wherein the master clock and the slave device are connected via a network interface supporting the Precision Time Protocol; a sending module, configured to broadcast a synchronization message to the slave device using the master clock at a preset frequency, the synchronization message including at least a first timestamp of a moment when the synchronization message leaves the master clock through the network interface; a receiving module, configured to receive the synchronization message using the slave device, and determine a second timestamp of a time when the synchronization message arrives at the slave device through the network interface; A synchronization module is configured to predetermine a propagation delay, determine a clock deviation of the slave device according to the first timestamp, the second timestamp, and the propagation delay, and synchronize a local clock of the slave device according to the clock deviation.

Images