Vehicle time synchronization fault-tolerant method, system, and vehicle

Abstract

The embodiment of the application provides a vehicle-mounted time synchronization fault-tolerant method, system and vehicle, and relates to the technical field of vehicle communication. The method is applied to a slave node, and comprises the following steps: receiving a state packet sent by a master node, wherein the state packet is sent by the master node based on the state thereof; in the case that a recovery field contained in the state packet represents a recovery state after being offline, restarting a time synchronization protocol stack; and in the case that the time synchronization protocol stack is restarted, performing time synchronization with the master node based on a time synchronization packet sent by the master node. The effect of improving the fault tolerance of time synchronization is achieved.

Description

Technical Field

[0001] This application relates to the field of vehicle network communication technology, and in particular to an on-board time synchronization fault-tolerant method, system and vehicle. Background Technology

[0002] Time-Sensitive Networking (TSN) is a core technology of vehicle communication systems. It ensures time synchronization between multiple nodes through a high-precision time synchronization protocol. Specifically, between the master node and the slave node, clock alignment across the entire network is achieved through Ethernet packets.

[0003] In related technologies, when the master node is offline, the slave node enters a free-running state due to the loss of its clock source. If the slave node loses its clock source for a long time, its time synchronization accuracy may exceed the threshold, which may cause the master node and slave node to be unable to restore time synchronization, resulting in the failure of related functions and a problem of low fault tolerance in time synchronization. Summary of the Invention

[0004] This application provides an in-vehicle time synchronization fault-tolerant method, system, and vehicle to improve the fault tolerance of time synchronization.

[0005] In a first aspect, embodiments of this application provide an on-board time synchronization fault-tolerant method applied to a slave node, comprising: receiving a status message sent by a master node, the status message being sent by the master node based on its status; restarting the time synchronization protocol stack when the recovery field contained in the status message indicates the recovery status after offline; and, after completing the restart of the time synchronization protocol stack, performing time synchronization with the master node based on the time synchronization message sent by the master node.

[0006] In some embodiments, restarting the time synchronization protocol stack when the recovery field in the status message indicates a recovery status after offline includes: updating the continuous count value when the recovery field in the status message indicates a recovery status after offline, the continuous count value representing the number of consecutively received status messages whose recovery field indicates a recovery status after offline; if the updated continuous count value is a preset value, then restarting the time synchronization protocol stack.

[0007] In some embodiments, after receiving the status message sent by the master node, the method further includes: sending a time synchronization failure message to the Ethernet based on the status message.

[0008] In some embodiments, sending a time synchronization failure message to the Ethernet according to a status message includes: sending a first time synchronization failure message to the Ethernet if the recovery field contained in the status message indicates a recovery status after offline, wherein the recovery receive field contained in the first time synchronization failure message is used to indicate that a status message indicating a recovery status after offline has been received.

[0009] In some embodiments, sending a time synchronization failure message to the Ethernet according to a status message includes: sending a second time synchronization failure message to the Ethernet if the recovery field contained in the status message indicates a normal state, wherein the recovery receive field contained in the second time synchronization failure message is used to indicate that the status message indicating the recovery state after offline was not received.

[0010] In some embodiments, restarting the time synchronization protocol stack includes:

[0011] Determine the time synchronization accuracy; if the time synchronization accuracy is less than or equal to the preset offset threshold, terminate the stop time synchronization protocol stack, set the time synchronization stability flag of the time synchronization protocol stack to an unstable state, and reinitialize the time synchronization protocol stack; if the time synchronization accuracy is greater than the preset offset threshold, set the time synchronization stability flag of the time synchronization protocol stack to an unstable state, and reinitialize the time synchronization protocol stack.

[0012] In some embodiments, after time synchronization with the master node based on the time synchronization message, the method further includes setting the time synchronization stability flag to a stable state.

[0013] Secondly, embodiments of this application provide an on-board time synchronization fault-tolerant method, applied to a master node, including:

[0014] The master node sends status messages to the slave node based on its status. In the case where the recovery field in the status message represents the recovery status after being offline, the status message is used to instruct the slave node to restart the time synchronization protocol stack.

[0015] Send a time synchronization message to the slave node. The time synchronization message is used to instruct the slave node to synchronize time with the master node after completing the restart of the time synchronization protocol stack.

[0016] In some embodiments, sending status messages to slave nodes based on the status of the master node includes: determining that the master node is in an offline recovery state in response to an offline recovery signal; and continuously sending multiple frames of status messages to slave nodes, representing the offline recovery state, when the master node is in an offline recovery state.

[0017] In some embodiments, sending a status message to a slave node based on the status of the master node includes: when the master node is in a normal state, sending a status message to the slave node with a recovery field representing the normal state.

[0018] Thirdly, embodiments of this application provide an in-vehicle time synchronization fault-tolerant system, including a master node and a slave node;

[0019] The master node is used to send status messages to the slave nodes based on its own status.

[0020] The slave node is used to receive status messages and restart the time synchronization protocol stack when the recovery field contained in the status message indicates that the offline status has been restored.

[0021] The master node is also used to send time synchronization messages to slave nodes;

[0022] The slave node is also used to synchronize time with the master node based on the time synchronization message sent by the master node after the time synchronization protocol stack has been restarted.

[0023] Fourthly, embodiments of this application provide a slave node, including:

[0024] The status receiving module is used to receive status messages sent by the master node, which are sent by the master node based on its status.

[0025] The processing module is used to restart the time synchronization protocol stack when the recovery field in the status message indicates the recovery status after offline.

[0026] The synchronization module is used to synchronize time with the master node based on the time synchronization message sent by the master node after the time synchronization protocol stack has been restarted.

[0027] Fifthly, embodiments of this application provide a master node, including:

[0028] The first sending module is used to send status messages to the slave nodes according to the status of the master node. In the case where the recovery field contained in the status message represents the recovery status after offline, the status message is used to instruct the slave node to restart the time synchronization protocol stack.

[0029] The second sending module is used to send time synchronization messages to the slave node. The time synchronization message is used to instruct the slave node to synchronize time with the master node after completing the restart of the time synchronization protocol stack.

[0030] Sixthly, embodiments of this application provide a vehicle, including: a processor, and a memory communicatively connected to the processor;

[0031] The memory stores instructions that the computer executes;

[0032] The processor executes computer execution instructions stored in memory to implement the methods described above.

[0033] In a seventh aspect, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided above.

[0034] Eighthly, embodiments of this application provide a computer program product, including computer execution instructions, which, when executed by a processor, implement the method provided above.

[0035] The vehicle-mounted time synchronization fault-tolerant method, system, and vehicle provided in this application, in a vehicle-mounted time-sensitive network, add a linked processing process where the master node sends a status message to the slave node, and triggers the slave node to restart the time synchronization protocol stack and resynchronize time based on the time synchronization message. This allows the master node to explicitly transmit its offline recovery status to the slave node via a status message when it comes back online due to sleep wake-up, abnormal restart, power switch, or link recovery, triggering the slave node to restart its time synchronization protocol stack and then re-aligning the master and slave clocks based on a new time synchronization message. Compared to the slave node initiating an inquiry and the master node responding after recovery, where the slave node receives the master node's response to determine if the master node is in an offline recovery state, in this embodiment, the master node acts as an active notification mechanism, directly sending a message representing its status to the slave node upon detecting that it is in an offline recovery state. The nodes can promptly determine whether the master node is in an offline recovery state, reducing the latency required for state synchronization between master and slave nodes. This avoids further degradation of time synchronization accuracy due to failure to promptly determine the master node's recovery, thus improving the efficiency and reliability of time synchronization recovery. This application embodiment establishes a mechanism at the system level for slave nodes to be aware of the master node's state, and triggers the reconstruction of time synchronization between master and slave nodes based on the master node's offline recovery state. In scenarios where the master node recovers from offline, this improves the fault tolerance of time synchronization, thereby solving the technical problem that slave nodes continue to run in a free clock state and are difficult to synchronize after the master node has been offline for a long time. Furthermore, after the slave node completes the restart of the time synchronization protocol stack, it performs time synchronization based on the time synchronization message sent by the master node, reducing interference from the old synchronization context on the new synchronization process and improving the success rate and convergence speed of time synchronization recovery. Attached Figure Description

[0036] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0037] Figure 1 A flowchart illustrating the fault-tolerant method for executing on-board time synchronization from a slave node, as provided in this application;

[0038] Figure 2 A flowchart illustrating the restart time synchronization protocol stack provided in this application;

[0039] Figure 3 A flowchart illustrating the in-vehicle time synchronization fault-tolerant method provided in this application in a specific example;

[0040] Figure 4 A flowchart illustrating the onboard time synchronization fault-tolerant method implemented by the master node provided in this application;

[0041] Figure 5 A flowchart illustrating the fault-tolerant method for in-vehicle time synchronization through interaction between the master and slave nodes provided in this application;

[0042] Figure 6 A schematic diagram of the on-board time synchronization fault-tolerant system provided in this application. Figure 1 ;

[0043] Figure 7 A schematic diagram of the on-board time synchronization fault-tolerant system provided in this application. Figure 2 ;

[0044] Figure 8 This application provides a schematic diagram of the slave node structure.

[0045] Figure 9 This application provides a schematic diagram of the structure of the master node;

[0046] Figure 10 This is a structural diagram of the vehicle provided in this application.

[0047] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0048] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0049] Time-Sensitive Networking (TSN) technology is widely used in automotive electronic and electrical architectures to carry data interactions related to chassis control, body control, domain controller collaboration, and intelligent driving. In such scenarios, automotive Ethernet typically needs to achieve high-precision, low-jitter, and deterministic time alignment between multiple nodes to ensure that control commands, sensor information, and status feedback are transmitted according to strict timing requirements.

[0050] Existing vehicle-mounted TSN time synchronization solutions typically rely on the master node periodically sending synchronization messages, and the slave nodes calculating the deviation based on the timestamps of the synchronization messages and continuously correcting their local clocks. When the network is stable, this can meet the synchronization accuracy requirements relatively well. However, during actual vehicle operation, the master node may go offline due to reasons such as hibernation, restart, or communication link interruption and cannot provide a clock source. In this case, the slave nodes are in a free-running state. As time goes by, the deviation between the slave node's local clock and the master clock will continue to accumulate. If the time synchronization accuracy exceeds the threshold, even if the master node comes back online, the slave nodes cannot restore the time synchronization state, affecting the timing consistency of related functions and the stability of services. Existing time synchronization solutions have the problem of poor fault tolerance.

[0051] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0052] It should be noted that the vehicle-mounted TSN may include one or more master nodes and one or more slave nodes. Each master node in the vehicle-mounted TSN can execute the embodiments of this application, and each slave node can execute the embodiments of this application. For ease of explanation, the embodiments of this application are described using the interaction between a single slave node corresponding to a single master node. It is understood that the embodiments of this application are also applicable to other master nodes and other slave nodes in the vehicle-mounted TSN to realize the recovery time synchronization between the master node and the corresponding multiple slave nodes.

[0053] Figure 1 This is a flowchart illustrating the on-board time synchronization fault-tolerant method provided in this application. This method is applied to slave nodes, such as... Figure 1 As shown, the on-board time synchronization fault-tolerant method includes:

[0054] S101. Receive status messages sent by the master node. The status messages are sent by the master node based on its status.

[0055] The master node is the clock source node in the vehicle-mounted time-sensitive network, which provides a unified time reference to the slave nodes in the network; the slave nodes are nodes that receive clock information from the master node and perform local clock calibration.

[0056] In practical applications, the master node can be the vehicle's domain controller, central computing unit, or gateway node with a high-precision clock source. Correspondingly, the slave node can be a PTP (Precision Time Protocol) slave clock node, body controller, chassis controller, intelligent driving execution unit, or other terminal controllers connected to the vehicle's Ethernet.

[0057] Among them, status messages are control messages sent by the master node to the slave node based on its current operating status.

[0058] Optionally, the master node periodically sends status messages to the slave node. For example, at preset intervals, the master node checks its status and sends status messages to the slave node.

[0059] Optionally, the master node sends status messages to the slave node according to a preset period and the changes in the master node's status. For example, the master node checks its own status in real time or periodically. If it detects that the master node's status has not changed, it sends a status message every preset period. If it detects that the master node's status has changed, it sends a status message to the slave node.

[0060] Among them, the status message is sent by the master node based on its status. This means that the status message contains fields that reflect the status of the master node. The slave node can determine the current status of the master node and the status changes of the master node based on the received status message.

[0061] S102. If the recovery field in the status message indicates the recovery status after offline, restart the time synchronization protocol stack.

[0062] The recovery field is used to characterize whether the master node is in an offline recovery state. The offline recovery state refers to the state in which the master node was previously offline and has now been restored to online. For example, the master node may be in an offline recovery state because it has previously experienced hibernation, abnormal reset, power outage, link loss or software stack restart, and now has regained the ability to provide clock services.

[0063] In practical applications, the status message includes a Resume field. If the Resume field is 1 or the first preset code, the Resume field in the status message indicates that the master node is in the offline recovery state. If the Resume field is 0 or the second preset code, the Resume field in the status message indicates that the master node is not in the offline recovery state (i.e., the master node is in the normal state).

[0064] The time synchronization protocol stack is a set of software protocols used on slave nodes to perform TSN time synchronization. It is used to implement functions such as message reception, message timestamp capture, offset calculation, frequency deviation estimation, local clock adjustment, synchronization stability flag maintenance, and state machine management.

[0065] The purpose of restarting the time synchronization protocol stack is to clear the historical synchronization status, accumulated error, and other data of the slave nodes after the master node returns to offline status, so that the slave nodes can re-execute time synchronization with a clean protocol context.

[0066] Specifically, the slave node parses the status messages sent by the master node. If the slave node parses the status message and finds that the recovery field indicates the recovery status after offline, it performs a restart operation on the time synchronization protocol stack.

[0067] In one specific implementation, when a slave node receives a status message from the master node, if it detects that the recovery field in the status message indicates a recovery status after offline, it sends a protocol stack restart request to the time synchronization management task. After receiving the request, the time synchronization management task pauses the current task of the time synchronization protocol stack, clears historical data, and then reinitializes the time synchronization protocol stack to restart the time synchronization message receiving channel, timestamp acquisition channel, and offset calculation task. The time synchronization protocol stack is then marked as having completed the restart and enters a state of waiting for subsequent time synchronization messages from the master node.

[0068] In related technologies, when the master node is offline, it cannot send synchronization messages. The slave node will enter a free-running state because it does not receive synchronization messages. In the free-running state, the local clock of the slave node will gradually deviate from the master clock due to the crystal oscillator frequency offset. Since the slave node will always be online within the same vehicle ignition cycle, the time synchronization accuracy of the slave node will gradually deteriorate, and may even exceed the preset offset threshold.

[0069] During this process, if the time synchronization accuracy has not exceeded the preset offset threshold, the slave node will wait for the synchronization message sent by the master node after it recovers from offline operation, in order to restore the time synchronization between the master and slave nodes. However, the slave node needs a long time to restore the time synchronization with the master node based on its local clock which has already deviated, resulting in low efficiency in restoring time synchronization.

[0070] If the time synchronization accuracy exceeds the preset offset threshold, the slave node will exit the free-running state and terminate the time synchronization protocol stack. In this case, even if the master node returns to online, the slave node will not be able to respond to the synchronization message, and thus time synchronization cannot be restored. The entire vehicle needs to be powered off and then powered on again so that both the master and slave nodes can be restarted in order to restore time synchronization between the master and slave nodes.

[0071] It should be noted that the slave node will terminate the time synchronization protocol stack if the time synchronization accuracy exceeds the preset offset threshold for the following reasons:

[0072] 1) In an in-vehicle time synchronization system, if the time synchronization accuracy of a slave node exceeds a preset offset threshold, the slave node's data (such as sensor data and control data) is still used to participate in the control of related intelligent driving functions. This can lead to a mismatch between the slave node's data and the actual vehicle status, resulting in incorrect intelligent driving decisions and affecting driving safety.

[0073] 2) In an in-vehicle time synchronization system, if the time synchronization accuracy of a slave node exceeds a preset offset threshold, it takes a long time to recover from the state where the time synchronization accuracy exceeds the preset offset threshold to the state that meets the synchronization requirements. For example, it may take several hours or even longer for the time synchronization accuracy to recover from greater than 10ms to 1us. During this period, the intelligent driving functions related to the slave node cannot be used or are downgraded. It can be seen that under this situation, it is not very meaningful for the slave node to continue to run freely in an attempt to restore time synchronization.

[0074] Therefore, in order to ensure driving safety and save system resources, existing technologies limit slave nodes to exit the free-running state, terminate the time synchronization protocol stack, and disable related intelligent driving functions when their time synchronization accuracy exceeds a preset offset threshold, rather than continuing time synchronization indefinitely.

[0075] In this embodiment, a process is added whereby the master node periodically sends status messages to the slave node, and the slave node responds to the status messages to perform corresponding restart operations. Specifically, after the master node wakes up from hibernation or restarts due to a software error reset, it sets the recovery field in the periodically sent status messages to 1. In order to ensure that the slave node can stably receive the recovery status messages, the master node can continuously send N frames of status messages with the recovery field set to 1. At the same time, the slave node responds quickly to the status messages: when the slave node receives a status message with the recovery field set to 1 from the master node, it actively restarts the time synchronization protocol stack, so that the time synchronization protocol stack can re-establish time synchronization between the master and slave nodes in the initial state.

[0076] S103. After completing the restart of the time synchronization protocol stack, synchronize the time with the master node based on the time synchronization message sent by the master node.

[0077] Among them, the time synchronization message is a message sent by the master node to the slave node to complete the clock alignment; the time synchronization message is the time synchronization frame in the TSN network, which belongs to the relevant message of the IEEE (Institute of Electrical and Electronics Engineers) 802.1AS protocol, and can specifically include synchronization messages and follow-up messages.

[0078] It should be noted that the master node periodically sends status messages and time synchronization messages. The sending periods for status messages and time synchronization messages can be the same or different, and status messages and time synchronization messages can be sent alternately. When the master node recovers after going offline, the master node can send status messages first and then send time synchronization messages.

[0079] The slave node first restarts the time synchronization protocol stack based on the status message. If the restart of the time synchronization protocol stack is not completed, the slave node does not respond to the time synchronization message sent by the master node. After the restart of the time synchronization protocol stack is completed, the slave node performs time synchronization with the master node based on the time synchronization message sent by the master node.

[0080] Specifically, after the slave node completes the restart of the time synchronization protocol stack, it enters the synchronization listening state and receives the first time synchronization message from the master node. When the time synchronization message arrives at the Ethernet controller, the slave node's hardware timestamp unit records the reception time t2 of the time synchronization message, and at the same time, it parses the master node's transmission time t1 from the time synchronization message payload.

[0081] In practical applications, if a two-step synchronization mechanism is used, the time synchronization message includes a Sync message and a Follow_Up message. The slave node first receives the Sync message and then receives the Follow_Up message corresponding to the Sync message to obtain the receiving time and the sending time of the master node. If a single-step synchronization mechanism is used, the receiving time and the sending time of the master node are obtained directly from the time synchronization message.

[0082] The offset is calculated based on the receiving time and the master node's sending time. For example, offset = (t2 - t1) - delay, where offset is the offset, t2 is the receiving time, t1 is the master node's sending time, and delay is the link propagation delay.

[0083] After obtaining the offset, the slave node can determine the time synchronization strategy based on the offset. For example, if the absolute value of the offset is less than or equal to a preset threshold, the slave node will use frequency skew or gradual time synchronization based on the first time synchronization message from the master node and the subsequent time synchronization messages to reduce the disturbance to the upper-layer real-time tasks. If the offset is greater than the preset threshold, a step adjustment will be performed based on the first time synchronization message to make the slave node's time quickly approach the master node. Then, based on the subsequent time synchronization messages sent by the master node, the slave node will complete the final accurate synchronization through frequency skew or gradual time synchronization.

[0084] The vehicle-mounted time synchronization fault-tolerant method provided in this application adds a linked processing process in a vehicle-mounted time-sensitive network, where the master node sends a status message to the slave node, and triggers the slave node to restart the time synchronization protocol stack and resynchronize the time based on the time synchronization message. This allows the master node to explicitly transmit its offline recovery status to the slave node via a status message when it comes back online due to sleep wake-up, abnormal restart, power switch, or link recovery, triggering the slave node to restart its time synchronization protocol stack and then re-aligning the master and slave clocks based on the new time synchronization message. Compared to the previous method where the slave node initiates an inquiry and the master node responds after recovery, with the slave node receiving the master node's response to determine if the master node is in an offline recovery state, in this application embodiment, the master node acts as an active notification mechanism. Upon detecting that it is in an offline recovery state, it directly sends a message representing its status to the slave node, enabling the slave node to... This allows for timely determination of the master node's offline recovery state, reducing the latency required for state synchronization between master and slave nodes. It also prevents further degradation of time synchronization accuracy due to failure to promptly determine the master node's recovery, thus improving the efficiency and reliability of time synchronization recovery. This application establishes a system-level mechanism for slave nodes to perceive the master node's state, and triggers the reconstruction of time synchronization between master and slave nodes based on the master node's offline recovery state. In scenarios where the master node recovers from offline status, this improves the fault tolerance of time synchronization, thereby solving the technical problem of slave nodes continuously operating in a free-clock state and struggling to recover synchronization after the master node has been offline for an extended period. Furthermore, after the slave node completes the restart of the time synchronization protocol stack, it performs time synchronization based on the time synchronization message sent by the master node, reducing interference from the old synchronization context on the new synchronization process and improving the success rate and convergence speed of time synchronization recovery.

[0085] It should be noted that in related technologies, in order to avoid the time synchronization accuracy of slave nodes dropping to an out-of-tolerance level during the master node's offline period, resulting in the unusability of slave node-related functions, redundant nodes are set up. During the master node's offline period, redundant nodes provide the master clock to maintain the time synchronization accuracy of slave nodes. However, this method requires additional nodes, and the master node needs to use a high-performance chip that supports multiple clock domains, resulting in a complex architecture of the vehicle time synchronization network and high hardware costs. However, the embodiment of this application does not require additional hardware. Only the software logic of the master node and slave node needs to be added, which can quickly restore the time synchronization between the master and slave nodes in the scenario of master node recovery after offline, making the architecture of the vehicle time synchronization network simple and reducing costs.

[0086] In some embodiments, when the status message contains a recovery field after offline status, restarting the time synchronization protocol stack includes: updating a continuous count value when the recovery field in the status message indicates a recovery status after offline status, wherein the continuous count value represents the number of consecutively received status messages whose recovery field indicates a recovery status after offline status; and restarting the time synchronization protocol stack if the updated continuous count value is a preset value.

[0087] The continuous count value represents the number of consecutive status messages received, where the recovery field represents the recovery status after offline status. The continuous count value is a preset value, which is the number of consecutive status messages received from the node that represent the recovery status after offline status. The specific value of the preset value can be set according to actual needs. For example, the preset value can be 3.

[0088] It should be noted that consistency is confirmed through continuous count values ​​to reduce the probability of false alarms in a single frame.

[0089] Specifically, when a node receives a status message, it parses the status message. If it determines that the recovery field contained in the status message represents the recovery status after offline, it increments the counter by 1 to obtain the updated continuous count value. It then checks whether the updated continuous count value is a preset value. If the updated continuous count value is not a preset value, the time synchronization protocol stack is not restarted temporarily, and the node waits for subsequent status messages to arrive. If the updated continuous count value is a preset value, it is determined that the master node is in the recovery status after offline, and the time synchronization protocol stack is restarted.

[0090] Optionally, after restarting the time synchronization protocol stack, the continuous count value is set to 0; in addition, if the recovery field contained in the status message received from the node indicates a normal state (i.e., the master node is not in a recovery state after being offline), the continuous count value is set to 0.

[0091] For example, when a slave node receives three consecutive status messages with the Resume field set to 1 from the master node, it determines that the master node is in an offline recovery state. Based on the first status message with the Resume field set to 1, it restarts the time synchronization protocol stack and discards the last two status messages.

[0092] In the above embodiments, when multiple frames of recovery fields representing the recovery status after offline are received continuously, the time synchronization protocol is restarted. This can filter out misjudgments caused by occasional message errors, link jitter, or single state disturbances. By determining whether the continuous count value is a preset value, the slave node can re-establish the synchronization processing link only when it is determined that the master node is in a stable state after offline recovery, thereby improving the reliability of restarting the time synchronization protocol stack.

[0093] In some embodiments, restarting the time synchronization protocol stack includes: determining the time synchronization accuracy; if the time synchronization accuracy is less than or equal to a preset offset threshold, terminating the time synchronization protocol stack, setting the time synchronization stability flag of the time synchronization protocol stack to an unstable state, and reinitializing the time synchronization protocol stack; if the time synchronization accuracy is greater than the preset offset threshold, setting the time synchronization stability flag of the time synchronization protocol stack to an unstable state, and reinitializing the time synchronization protocol stack.

[0094] Time synchronization accuracy refers to the offset between the clock of the slave node and the clock of the master node. A time synchronization accuracy less than or equal to a preset offset threshold indicates that the slave node's time synchronization accuracy is within acceptable limits; a time synchronization accuracy greater than the preset offset threshold indicates that the slave node's time synchronization accuracy is beyond acceptable limits. In practical applications, the preset offset threshold can be set according to actual needs; for example, the preset offset threshold is 10ms.

[0095] The termination of the time synchronization protocol stack refers to exiting the existing main function for calculating the time synchronization offset, releasing the initialization timestamp parameters that can receive time synchronization algorithm functions, and preparing for subsequent re-initialization.

[0096] For example, terminating the time synchronization protocol stack includes: 1) stopping the main control task and clock servo algorithm of the protocol stack; 2) stopping message sending and receiving processing; 3) clearing the internal state machine and running data; 4) releasing system resources; by terminating the time synchronization protocol stack, a clean environment is provided for subsequent re-initialization.

[0097] The time synchronization stability flag is used to characterize whether the time synchronization convergence result is stable. Setting the time synchronization stability flag to an unstable state means switching the time synchronization stability flag from a stable state to an unstable state, indicating to the upper-layer control unit that the current time synchronization result has failed and time synchronization convergence needs to be performed again. The time synchronization stability flag can be set to an unstable state through the status register, software status variable or diagnostic cache field inside the time synchronization protocol stack.

[0098] Reinitializing the time synchronization protocol stack refers to rebuilding the runtime resources, cached data, timers, state machines, and initial configuration of the time synchronization protocol stack, restoring it to its initial state awaiting resynchronization.

[0099] It should be noted that terminating the time synchronization protocol stack can be understood as shutting down the time synchronization software or service, while reinitializing the time synchronization protocol stack can be understood as restarting the time synchronization software or service.

[0100] Specifically, refer to Figure 2When the recovery field in the status message represents the recovery status after offline, the slave node determines its time synchronization accuracy and determines whether the time synchronization accuracy is less than or equal to the preset offset threshold.

[0101] If the time synchronization accuracy is less than or equal to the preset offset threshold, it means that the time synchronization accuracy of the slave node has not reached the out-of-tolerance level. The slave node's time synchronization protocol stack is still running. At this time, the running time synchronization protocol stack is terminated, the time synchronization stability flag is set to an unstable state, the state machine in the time synchronization protocol stack is reinitialized, and the slave node's time synchronization protocol stack is made to re-enter the working mode of acquiring time synchronization messages.

[0102] It should be noted that if the time synchronization accuracy is less than or equal to the preset offset threshold, restarting the time synchronization protocol stack allows the slave node to resynchronize in a clean state, which can quickly restore time synchronization. If the time synchronization protocol stack is not restarted and time synchronization is restored based on the current time synchronization accuracy, it will take a long time to restore time synchronization. Therefore, when the time synchronization accuracy is less than or equal to the preset offset threshold, restarting the time synchronization protocol stack significantly reduces the time required to restore time synchronization compared to not restarting the time protocol stack, thus improving the efficiency of time synchronization restoration.

[0103] If the time synchronization accuracy is greater than the preset offset threshold, it means that the time synchronization accuracy of the slave node has reached the level of being out of tolerance. According to the original control logic of the slave node, the slave node has terminated the time synchronization protocol stack. In order to restore the time synchronization between the master node and the slave node, the slave node sets the time synchronization stability flag to an unstable state, reinitializes the state machine in the time synchronization protocol stack, and enables the slave node's time synchronization protocol stack to re-enter the working mode of receiving and responding to time synchronization messages.

[0104] It should be noted that, according to the original control logic of the slave node, the slave node will terminate the time synchronization protocol stack when the time synchronization accuracy reaches a preset offset threshold, instead of attempting synchronization deviations indefinitely. The termination of the time synchronization protocol stack by the slave node causes it to be unable to receive or respond to time synchronization messages sent by the master node, thus preventing the restoration of time synchronization. In related technologies, the entire vehicle needs to be powered off and then powered on again to restore time synchronization between the master and slave nodes. However, in this embodiment, when the slave node's time synchronization accuracy reaches the preset offset threshold and the slave node terminates the time synchronization protocol stack, the slave node can restart the time synchronization protocol stack based on the status message with the Resume field set to 1 sent by the master node. This eliminates the need for a complete vehicle power-off and power-on, significantly shortening the duration of time asynchrony between the master and slave nodes and reducing the impact on the slave node's related functions.

[0105] Optionally, if the time synchronization protocol stack includes a hardware timestamp unit, restarting the time synchronization protocol stack also includes synchronously clearing the historical timestamps and lock flags in the hardware registers to avoid old parameters interfering with the new round of time synchronization.

[0106] In the above embodiment, when the slave node determines that the master node is in the offline recovery state through the status message, if the slave node determines that its time synchronization accuracy is greater than the preset offset threshold, it sets the time synchronization stability flag to unstable and reinitializes the state machine in the time synchronization protocol stack. Compared with the prior art, when the time synchronization accuracy exceeds the tolerance, clock synchronization can only be re-achieved by powering on, which reduces the impact on the slave node's related functions.

[0107] By pausing the old time synchronization protocol stack, setting the time synchronization stability flag, and reinitializing the time synchronization protocol stack, the slave nodes can resynchronize in a clean state when the master node recovers from offline operation. This reduces the possibility of time synchronization convergence failure caused by old synchronization parameters, and improves the stability and efficiency of time synchronization recovery in scenarios where the master node is offline.

[0108] In some embodiments, after time synchronization with the master node based on the time synchronization message, the method further includes: setting the time synchronization stability flag to a stable state when time synchronization converges.

[0109] The time synchronization stability flag is switched from an unstable state to a stable state to indicate to the upper-layer business that time synchronization convergence has been re-achieved.

[0110] Specifically, after receiving the time synchronization message sent by the master node, the slave node calculates the deviation between its local clock and the master node's clock based on the timestamp of the time synchronization message, corrects its local clock according to the deviation, determines the time synchronization accuracy, and performs local clock correction and time synchronization accuracy calculation for several synchronization cycles in this manner until the time synchronization accuracy meets the preset accuracy, determines that the time synchronization has converged, and then switches the time synchronization stability flag from an unstable state to a stable state.

[0111] In practical applications, the time synchronization stability flag can be written to the PTP status register or the synchronization status table in the software layer so that it can be read by the diagnostic unit, communication management unit or upper-level controller.

[0112] In the above embodiments, the time synchronization stability flag indicates whether the slave node has achieved time synchronization with the master node. When the time synchronization stability flag is set to a stable state, the upper-layer unit determines that the current network time reference can be used for time-sensitive functions such as chassis control, body control or sensor fusion, thereby avoiding the activation of related functions when time synchronization has not converged and improving the stability of related functions that depend on time synchronization.

[0113] In some embodiments, after receiving the status message sent by the master node, the method further includes: sending a time synchronization failure message to the Ethernet based on the status message.

[0114] Among them, the time synchronization fault message is used to report the current time synchronization status of the slave node to the master node, other nodes, diagnostic modules or monitoring units in the Ethernet, so that the network side can know the impact of the master node status change on time synchronization.

[0115] Specifically, after receiving the status message, the slave node parses the status message to obtain the recovery field, generates a time synchronization fault message based on the recovery field, and sends it to the Ethernet via the vehicle Ethernet interface.

[0116] In possible implementations, after receiving a status message, the slave node can generate a time synchronization failure message based on the recovery field contained in the status message and the slave node's current time synchronization status, and send the time synchronization failure message to the Ethernet. Alternatively, the slave node can periodically send time synchronization failure messages to the Ethernet, for example, every time the fault reporting interval is reached, it can generate a time synchronization failure message based on the recovery field contained in the most recent received status message frame and the slave node's current time synchronization status, and send the time synchronization failure message to the Ethernet.

[0117] In practical applications, the encapsulation method and fault reporting duration of clock synchronization fault messages can be configured according to the vehicle network architecture, and this application embodiment does not limit this.

[0118] Optionally, the time synchronization failure message includes a recovery receive field, and may also include at least one of the following: slave node identifier field, current time field, time synchronization accuracy field, invalid reason field, stability flag field, stable time field, accurate source time field of the message, and correction time field of the message.

[0119] The recovery reception field indicates whether the slave node has received the status message representing the recovery status after offline status; the slave node identifier field can be the name of the slave node; the current time field can be the slave node's gPTP (generalized Precision Time Protocol) time, that is, the time of the slave node's local clock after time synchronization according to the generalized precision time protocol; the time synchronization precision field can be the time synchronization offset; the invalid reason field can be the reason for the invalid time synchronization precision; the stability flag field is the time synchronization stability flag; the stable time field is the gPTP time when the time synchronization stability flag is stable; the precise source time field of the message is the precise source time contained in the time synchronization message sent by the master node; and the corrected time field of the message is the corrected time contained in the time synchronization message sent by the master node.

[0120] In the above embodiments, the slave node sends a time synchronization fault message to the Ethernet according to the status message sent by the master node, so that other nodes and the master controller can know the time synchronization status, thereby improving the observability of the time synchronization status in the vehicle time-sensitive network.

[0121] In some embodiments, sending a time synchronization failure message to the Ethernet according to a status message includes: sending a first time synchronization failure message to the Ethernet if the recovery field contained in the status message indicates a recovery status after offline, wherein the recovery receive field contained in the first time synchronization failure message is used to indicate that a status message indicating a recovery status after offline has been received.

[0122] The recovery receive field is used to indicate whether the slave node has received a status message indicating the recovery status after offline. For example, the time synchronization failure message includes a recovery receive (GetResume_Flag) field. If the GetResume_Flag field is 1 or a third preset code, the recovery receive field indicates that the status message indicating the recovery status after offline has been received. This time synchronization failure message is recorded as the first time synchronization failure message.

[0123] In a specific example, if the status message received by the slave node contains a Resume field of 1, the slave node sends a first-time synchronization failure message to the Ethernet. The first-time synchronization failure message contains a GetResume_Flag field of 1.

[0124] Optionally, if the recovery field in the status message indicates that the node has recovered from being offline, the slave node restarts the time synchronization protocol stack and sends a first time synchronization failure message to the Ethernet.

[0125] In the above embodiments, the slave node sends the received status message representing the recovery status after offline to the Ethernet via the first-time synchronization fault message. This allows the network side to determine that the master node's recovery status after offline has been synchronized to the slave node, and to determine the correspondence between the slave node's clock synchronization fault and the master node's recovery status after offline. This improves the observability of the time synchronization recovery process and the comprehensiveness of time synchronization fault reporting, thereby enhancing the stability and fault tolerance of the vehicle-mounted time-sensitive network in the scenario of master node recovery after offline.

[0126] In some embodiments, sending a time synchronization failure message to the Ethernet according to a status message includes: sending a second time synchronization failure message to the Ethernet if the recovery field contained in the status message indicates a normal state, wherein the recovery receive field contained in the second time synchronization failure message is used to indicate that the status message indicating the recovery state after offline was not received.

[0127] For example, a time synchronization failure message includes a GetResume_Flag field. If the GetResume_Flag field is 0 or a fourth preset code, then the recovery receive field indicates that no recovery has been received and the recovery field indicates the recovery status after offline. This time synchronization failure message is recorded as the second time synchronization failure message.

[0128] In a specific example, if the Resume field in the status message received by the slave node is 0, the slave node sends a second time synchronization failure message to the Ethernet, and the GetResume_Flag field in the second time synchronization failure message is 0.

[0129] It should be noted that when the master node is in a normal state or an offline state, if the slave node does not receive a status message with the recovery field indicating the recovery status after offline, it will send a first time synchronization fault message to the Ethernet. When the master node is in an offline recovery state, if the slave node receives a status message with the recovery field indicating the recovery status after offline, it will send a second time synchronization fault message to the Ethernet.

[0130] In the above embodiments, when the master node is running normally or offline, the slave node sends the information that it has not received the status message indicating the recovery status after offline via the second time synchronization fault message to the Ethernet, so that the network side can determine the relationship between the clock synchronization fault of the slave node and the status of the master node, thereby improving the accuracy and traceability of time synchronization monitoring.

[0131] Optionally, if the recovery field in the status message represents the recovery status after offline, the time synchronization accuracy is determined. If the time synchronization accuracy is greater than a preset offset threshold, the time synchronization accuracy is determined to be invalid, and a third time synchronization failure message is sent to the Ethernet. The recovery receive field in the third time synchronization failure message is used to represent that a status message representing the recovery status after offline has been received. The invalidity reason field in the third time synchronization failure message is used to represent that the time synchronization message was lost and became invalid.

[0132] The third time synchronization failure message also includes a time synchronization precision field, which is a preset invalid value.

[0133] For example, if the Resume field in the status message received by the slave node is 1, and the time synchronization accuracy of the slave node is greater than the preset offset threshold, then the slave node sends a third time synchronization failure message to the Ethernet. The GetResume_Flag field in the third time synchronization failure message is 1, and the invalid reason field (Offset_invalid_reason) field is 0x1 (indicating that the time synchronization message was lost and became invalid).

[0134] Optionally, if the recovery field in the status message represents the recovery status after offline, the time synchronization accuracy is determined. If the time synchronization accuracy is less than or equal to a preset offset threshold, the time synchronization accuracy is determined to be valid, and a fourth time synchronization fault message is sent to the Ethernet. The recovery receive field in the fourth time synchronization fault message is used to represent that the status message representing the recovery status after offline has been received. The invalid reason field in the fourth time synchronization fault message is used to represent that the time synchronization accuracy is valid.

[0135] The fourth time synchronization failure message also includes a time synchronization precision field, which specifies the time synchronization precision.

[0136] For example, if the Resume field in the status message received by the slave node is 1, and the time synchronization accuracy of the slave node is less than or equal to a preset offset threshold, the slave node sends a fourth time synchronization failure message to the Ethernet. The GetResume_Flag field in the fourth time synchronization failure message is 1, and the invalid reason field (Offset_invalid_reason) field is 0x0 (indicating that the time synchronization accuracy is valid).

[0137] In the above embodiments, the slave node sends information to the Ethernet via a third time synchronization fault message, indicating that the master node has been received as offline and the slave node's time synchronization accuracy has reached the tolerance level. The slave node sends information to the Ethernet via a fourth time synchronization fault message, indicating that the master node has been received as offline and the slave node's time synchronization accuracy has not reached the tolerance level. This improves the observability of the time synchronization recovery process and the comprehensiveness of time synchronization fault reporting.

[0138] Optionally, if the recovery field in the status message indicates a normal state, the time synchronization accuracy is determined. If the time synchronization accuracy is less than or equal to a preset offset threshold, a fifth time synchronization failure message is sent to the Ethernet. The recovery receive field in the fifth time synchronization failure message is used to indicate that the status message indicating the recovery state after offline is not received. The invalid reason field in the fifth time synchronization failure message is used to indicate that the time synchronization accuracy is valid.

[0139] The fifth time synchronization failure message also includes a time synchronization precision field, which specifies the time synchronization precision.

[0140] Optionally, if the recovery field in the status message represents a normal state, the time synchronization accuracy is determined. If the time synchronization accuracy is greater than a preset offset threshold, a sixth time synchronization failure message is sent to the Ethernet. The recovery receive field in the sixth time synchronization failure message is used to represent a status message that has not received the recovery field, which represents the recovery status after going offline. The invalid reason field in the sixth time synchronization failure message is used to represent the invalidity caused by the slave node itself.

[0141] The sixth time synchronization failure message also includes a time synchronization precision field, which is a preset invalid value.

[0142] In the above embodiments, the fifth time synchronization fault message sends information to the Ethernet indicating that the slave node has not received the master node's offline state and that the slave node's time synchronization accuracy has not reached the tolerance level. The sixth time synchronization fault message sends information to the Ethernet indicating that the slave node has not received the master node's offline state and that the slave node's time synchronization accuracy has reached the tolerance level due to its own reasons. This improves the observability of the time synchronization recovery process and the comprehensiveness of time synchronization fault reporting.

[0143] In some embodiments, a time synchronization failure message includes: a slave node identifier field, a current time field, a time synchronization accuracy field, an accuracy invalidation reason field, a stability flag field, a stable time field, a precise source time field of the message, a correction time field of the message, and a recovery reception field.

[0144] For example, the fields included in a time synchronization failure message are shown in Table 1.

[0145] Table 1

[0146]

[0147] Number1 is the slave node identifier field, which is used to write the name of the slave node and has a length of 1 byte.

[0148] Gptp_TimeStamp is the current time field, used to write the gPTP time of the slave node. It is 10 bytes long, with the first 6 bytes in seconds (s) and the last 4 bytes in nanoseconds (ns).

[0149] Offset is a time synchronization precision field used to write the time synchronization offset (represented by a positive value). It is 8 bytes long. If the time synchronization offset cannot be calculated, it is filled with a preset invalid value (e.g., 0xFFFFFFFFFFFFFFFF).

[0150] Offset_invalid_reason is the invalid reason field, used to write the reason why the time synchronization offset is a preset invalid value. The length is 1 byte. For example, if the time synchronization offset is valid, fill in 0x0; if it is invalid due to the loss of time synchronization message frames, fill in 0x1; if it is invalid due to the slave node itself, fill in 0x2.

[0151] FirstPTP_stable is a stability flag field containing a time synchronization stability flag (the flag indicating that time synchronization is stable for the first time after the master node comes online). It is 1 byte long. If the time synchronization between the slave node and the master node is unstable, fill in 0x00; if the time synchronization is stable, fill in 0x01. For example, when the master node comes online (power-on, wake-up, or recovery), fill in 0x00; when the time synchronization between the slave node and the master node is stable through multiple time synchronization messages, fill in 0x01.

[0152] FirstPTP_TimeStamp is a stable time field used to write the first stable gPTP time during time synchronization. It is 10 bytes long, with the first 6 bytes in seconds (s) and the last 4 bytes in nanoseconds (ns).

[0153] PTP_preciseTiStamp is the precise source time field of the message, used to write the precise source time (preciseOriginTimestamp) contained in the time synchronization message sent by the master node. It is 10 bytes long, with the first 6 bytes in seconds (s) and the last 4 bytes in nanoseconds (ns).

[0154] The correction time field of the PTP_CorrectionField message is used to write the correction time (correctionFeild) contained in the time synchronization message sent by the master node. It is 8 bytes long and the unit is nanoseconds (ns).

[0155] GetResume_Flag is the recovery reception field, with a length of 1 byte. If a status message indicating the recovery status after offline is received, 1 is written; if a status message indicating the normal status is received, or if no status message is received, 0 is written.

[0156] Optionally, when sending a time synchronization failure message, big-endian byte order padding is used.

[0157] The time synchronization status and performance can be determined by periodically sending time synchronization fault messages.

[0158] For example, after GetResume_Flag is set from 0 to 1 and time synchronization is re-performed, the time synchronization precision field in subsequent time synchronization failure messages can be observed to show that the time synchronization precision has converged from greater than 10ms to less than 1us.

[0159] In the above embodiments, the time synchronization fault message reported by the slave node to the Ethernet can not only report the time synchronization status of the slave node, but also report the cause of the time synchronization anomaly and the process of restoring time synchronization, thereby improving the observability of time synchronization and the accuracy of fault reporting.

[0160] In some embodiments, where the recovery field in the status message represents the recovery status after offline, after restarting the time synchronization protocol stack, the method further includes: measuring the time synchronization accuracy and sending a time synchronization accuracy signal to the Ethernet based on the time synchronization accuracy.

[0161] The time synchronization accuracy signal includes the time synchronization accuracy of the slave node. The time synchronization accuracy signal is used to observe whether the slave node achieves the synchronization accuracy within a specified time period. The specified time period can be set according to actual needs. The synchronization accuracy can be achieved when the time error between the master node and the slave node is less than 1µs.

[0162] For example, in a specific example, such as Figure 3As shown, the vehicle-mounted time synchronization fault-tolerant method includes: S301, the master node receives the offline recovery signal and sets the recovery field in the status message periodically sent to the slave node to 1; S302, the slave node receives the status message, determines that the recovery field contained in the status message is 1, then restarts the time synchronization protocol stack and sends a time synchronization fault message to the Ethernet; S303, the slave node performs time synchronization with the master node according to the clock synchronization message periodically sent by the master node, and during the time synchronization with the master node, it sends a time synchronization accuracy signal to the Ethernet according to the time synchronization accuracy.

[0163] In the above embodiments, the observability of time synchronization in the vehicle-mounted time-sensitive network is improved by sending a synchronization accuracy signal.

[0164] The vehicle-mounted time synchronization fault-tolerant method provided in this application adds a linked processing process in a vehicle-mounted time-sensitive network, where the master node sends a status message to the slave node, and triggers the slave node to restart the time synchronization protocol stack and resynchronize the time based on the time synchronization message. This allows the master node to explicitly transmit its offline recovery status to the slave node via a status message when it comes back online due to sleep wake-up, abnormal restart, power switch, or link recovery, triggering the slave node to restart its time synchronization protocol stack and then re-aligning the master and slave clocks based on the new time synchronization message. Compared to the previous method where the slave node initiates an inquiry and the master node responds after recovery, with the slave node receiving the master node's response to determine if the master node is in an offline recovery state, in this application embodiment, the master node acts as an active notification mechanism. Upon detecting that it is in an offline recovery state, it directly sends a message representing its status to the slave node, enabling the slave node to... This allows for timely determination of the master node's offline recovery state, reducing the latency required for state synchronization between master and slave nodes. It also prevents further degradation of time synchronization accuracy due to failure to promptly determine the master node's recovery, thus improving the efficiency and reliability of time synchronization recovery. This application establishes a system-level mechanism for slave nodes to perceive the master node's state, and triggers the reconstruction of time synchronization between master and slave nodes based on the master node's offline recovery state. In scenarios where the master node recovers from offline status, this improves the fault tolerance of time synchronization, thereby solving the technical problem of slave nodes continuously operating in a free-clock state and struggling to recover synchronization after the master node has been offline for an extended period. Furthermore, after the slave node completes the restart of the time synchronization protocol stack, it performs time synchronization based on the time synchronization message sent by the master node, reducing interference from the old synchronization context on the new synchronization process and improving the success rate and convergence speed of time synchronization recovery.

[0165] Figure 4 This is a flowchart illustrating the on-board time synchronization fault-tolerant method provided in this application. This method is applied to the master node, such as... Figure 4 As shown, the on-board time synchronization fault-tolerant method includes:

[0166] S401. Send a status message to the slave node according to the status of the master node. Wherein, if the recovery field contained in the status message represents the recovery status after offline, the status message is used to instruct the slave node to restart the time synchronization protocol stack.

[0167] Specifically, the master node determines its own status and sends a status message to the slave node based on its status. If the master node's status is offline recovery status, the master node sends a status message to the slave node, and the recovery field contained in the status message represents the offline recovery status. If the master node's status is normal status, the master node sends a status message to the slave node, and the recovery field contained in the status message represents the normal status.

[0168] In practical applications, the master node periodically sends status messages to the slave node, for example, every 100ms. When the master node is in a normal state, the Resume field in the status message is 0; when the master node is in an offline recovery state, the Resume field in the status message becomes 1.

[0169] The slave node receives status messages sent by the master node, parses the status messages, and if the slave node parses the status message and finds that the recovery field contained in the status message represents the recovery status after offline, it executes the restart operation of the time synchronization protocol stack; the specific process executed by the slave node can be referred to the specific description in the above embodiment.

[0170] S402. Send a time synchronization message to the slave node. The time synchronization message is used to instruct the slave node to synchronize time with the master node after completing the restart of the time synchronization protocol stack.

[0171] Among them, the time synchronization message is used to complete clock alignment. The time synchronization message is the time synchronization frame in the TSN network, which belongs to the relevant message of the IEEE 802.1AS protocol. Specifically, it can include the Sync message and the Follow_Up message.

[0172] Specifically, the master node periodically sends status messages and time synchronization messages. The sending periods for status messages and time synchronization messages can be the same or different, and status messages and time synchronization messages can be sent alternately. When the master node recovers after going offline, it can send status messages first and then send time synchronization messages.

[0173] After the slave node completes the restart of the time synchronization protocol stack, the slave node synchronizes its time with the master node based on the time synchronization message sent by the master node; the specific process of the slave node synchronizing its time with the master node based on the time synchronization message can be referred to the specific description in the above embodiment.

[0174] The vehicle-mounted time synchronization fault-tolerant method provided in this application adds a linkage process in a vehicle-mounted time-sensitive network, where the master node sends a status message to the slave node, and triggers the slave node to restart the time synchronization protocol stack and resynchronize the time based on the time synchronization message. This ensures that when the master node comes back online due to sleep wake-up, abnormal restart, power switch, or link recovery, the master node's offline recovery status is explicitly transmitted to the slave node through the status message, triggering the slave node to restart the time synchronization protocol stack, and then the master and slave clocks are re-aligned based on the new time synchronization message. This application embodiment establishes a system-level... A mechanism was established to make the slave node aware of the master node's state, and to trigger the reconstruction of time synchronization between the master and slave nodes based on the master node's offline recovery state. In scenarios where the master node recovers from offline, the fault tolerance of time synchronization is improved, thereby solving the technical problem that when the master node is offline for a long time, the slave node continues to run in a free clock state and it is difficult to restore synchronization. In addition, after the slave node completes the restart of the time synchronization protocol stack, it performs time synchronization based on the time synchronization message sent by the master node, which reduces the interference of the old synchronization context on the new synchronization process and improves the success rate and convergence speed of time synchronization recovery.

[0175] In some embodiments, sending status messages to slave nodes based on the status of the master node includes: determining that the master node is in an offline recovery state in response to an offline recovery signal; and continuously sending multiple frames of status messages to slave nodes, representing the offline recovery state, when the master node is in an offline recovery state.

[0176] Among them, the offline recovery signals include, but are not limited to: sleep wake-up signals and abnormal restart signals; based on the offline recovery signals.

[0177] Specifically, if the master node receives a sleep wake-up signal or an abnormal restart signal, it will continuously send multiple frames of status messages containing an offline Resume field of 1 to the slave node.

[0178] Optionally, after continuously sending multiple frames of status messages with recovery fields representing the recovery status after offline to the slave node, the process further includes: periodically sending status messages with recovery fields representing the normal status to the slave node.

[0179] It should be noted that the offline recovery status is a short-term status, representing the stage when the master node has just recovered from offline to online. Once the master node is stably online, it is in a normal state. The sending logic of the status message matches the fact that the offline recovery status is a short-term status. For example, if the master node detects that it is in the offline recovery status, it will send three consecutive status messages with the Resume field set to 1. After the last status message with the Resume field set to 1 is sent, subsequent status messages with the Resume field set to 0 will be sent.

[0180] In the above embodiments, when the master node receives the offline recovery signal, it continuously sends multiple frames of recovery field-characterized status messages to the slave node, making the sending logic of the status messages corresponding to the offline recovery status match the short-term offline recovery status of the master node. Furthermore, by sending multiple frames of recovery field-characterized status messages, misjudgments caused by occasional message errors, link jitter, or single status disturbances can be filtered out, improving the reliability of the slave node's time synchronization protocol stack restart.

[0181] In some embodiments, sending a status message to a slave node based on the status of the master node includes: when the master node is in a normal state, sending a status message to the slave node with a recovery field representing the normal state.

[0182] Specifically, if the master node is online normally, it is determined that the master node is in a normal state. Alternatively, if the master node has been offline for a certain period of time and then recovered, it indicates that the master node is now stably online and is in a normal state.

[0183] When the master node is in a normal state, it periodically sends status messages with the Resume field set to 0 to the slave nodes.

[0184] Optionally, the status message includes a destination address field, a source address field, a frame tag field, a priority field, an address format field, a network segment number field, an Ethernet type field, and a recovery field; for example, the fields included in the status message are shown in Table 2.

[0185] Table 2

[0186]

[0187] The Destination Address field is used to write the physical address (MAC address) of the slave node. The physical address uses a multicast address and is 6 bytes long.

[0188] The Source Address field is used to write the MAC address of the master node, and its length is 6 bytes.

[0189] TPID is the frame tag field used to identify VLAN frames. It is 2 bytes long and has a fixed value of 0x8100.

[0190] PRI is the priority field, used to indicate the priority of a frame. The priority field ranges from 0 to 7, with higher values ​​indicating higher priority; its length is 3 bytes.

[0191] CFI is the address format field, used to reflect whether the MAC address is in a standard format, and its length is 1 byte; if the MAC address is in a standard format, write 0, and if the MAC address is not in a standard format, write 1.

[0192] VlanID is the network segment number field, used to write the VLAN number, and its length is 12 bytes.

[0193] The Ether type field is a 2-byte field with a fixed value of 0x88B8.

[0194] The Resume field is 1 byte long; if the master node is in a recovery state after being offline, write 1; if the master node is in a normal state, write 0.

[0195] Optionally, big-endian byte order padding can be used when sending status messages.

[0196] In the above embodiments, when the master node is in a normal state, it transmits the normal state of the master node to the slave node through a status message, thereby enabling the slave node to perceive the state of the master node. Correspondingly, the slave node sends a second time synchronization fault message to the Ethernet to monitor the time synchronization of the master node and the slave node in the normal state, thereby improving the observability of the time synchronization status in the vehicle time-sensitive network.

[0197] In a specific example, taking the scenario of master node sleep-wake-up or abnormal reset as an example, such as... Figure 5 As shown, the on-board time synchronization fault-tolerant method includes:

[0198] When the master node receives a sleep wake-up signal or an abnormal reset signal, it determines that the master node is in an offline wake-up state and continuously sends three status messages with the Resume field set to 1 to the slave node.

[0199] When a slave node receives a status message sent by a master node, if it detects that the status message contains a Resume field of 1, it increments the counter by 1. It then checks whether the consecutive count value of the counter is 3. If not, it continues to wait for a status message. If it is, it means that it has received 3 consecutive status messages with the Resume field of 1. The slave node processes the first received status message with the Resume field of 1 and discards the subsequent two status messages.

[0200] When a slave node processes a status message with the Resume field set to 1 in the first frame, it restarts the slave node's time synchronization protocol stack, including: stopping the time synchronization protocol stack, setting the time synchronization stability flag (First PTP_stable) to an unstable state, and reinitializing the time synchronization protocol stack.

[0201] The master node sends a time synchronization message to the slave node;

[0202] The slave node receives time synchronization messages and, after restarting the time synchronization protocol stack, synchronizes its time with the master node based on the time synchronization messages.

[0203] The process of a slave node sending a time synchronization failure message to the Ethernet is as follows: Since the slave node receives a status message with the Resume field set to 1, the recovery receive field (GetResume_Flag) in the time synchronization failure message is set to 1; after determining the other data content required for the time synchronization failure message, the slave node generates a time synchronization failure message containing GetResume_Flag set to 1 and sends the time synchronization failure message to the Ethernet.

[0204] It should be noted that in the vehicle-mounted time synchronization fault-tolerant method provided in this application, the master node can periodically send status messages to the slave node and periodically send time synchronization messages to the slave node according to its status. The slave node can periodically send time synchronization fault messages to the Ethernet. In the above example, only some of the messages exchanged between the master node and the slave node are shown.

[0205] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0206] Figure 6 This is a schematic diagram of the structure of the on-board time synchronization fault-tolerant system provided in this application, as shown below. Figure 6 As shown, the on-board time synchronization fault-tolerant system includes:

[0207] This includes master node 5601 and slave node 602;

[0208] Master node 601 is used to send status messages to slave nodes based on the status of the master node.

[0209] Slave node 602 is used to receive status messages and restart the time synchronization protocol stack when the recovery field contained in the status message indicates that the offline status has been restored.

[0210] The master node 601 is also used to send time synchronization messages to the slave nodes;

[0211] Slave node 602 is also used to synchronize time with the master node based on the time synchronization message sent by the master node after the time synchronization protocol stack has been restarted.

[0212] In a specific example, such as Figure 7 As shown, the master node includes a first control unit, and the slave node includes a second control unit. When the master node receives a sleep wake-up signal or an abnormal reset signal, it determines that the master node is in an offline recovery state. It then sends a status message to the slave node through the first control unit. The recovery field in the status message represents the offline recovery state. The slave node receives the status message, restarts the time synchronization protocol stack through the second control unit, and sends a time synchronization fault message to the Ethernet. The recovery receive field in the time synchronization fault message represents the received status message representing the offline recovery state.

[0213] The master node sends a time synchronization message to the slave node through the first control unit. The slave node synchronizes its time with the master node based on the time synchronization message through the second control unit. At the same time, the slave node measures the time synchronization accuracy through the second control unit and sends the time synchronization accuracy signal to the Ethernet.

[0214] The vehicle-mounted time synchronization fault-tolerant system provided in this embodiment executes the above-mentioned vehicle-mounted time synchronization fault-tolerant method through the interaction between the master node and the slave node. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0215] The vehicle-mounted time synchronization fault-tolerant system provided in this application embodiment adds a linkage process in the vehicle-mounted time-sensitive network, where the master node sends a status message to the slave node, and triggers the slave node to restart the time synchronization protocol stack and resynchronize the time based on the time synchronization message. This allows the master node to explicitly transmit its offline recovery status to the slave node via a status message when it comes back online due to sleep wake-up, abnormal restart, power switch, or link recovery, triggering the slave node to restart its time synchronization protocol stack and then re-align the master and slave clocks based on the new time synchronization message. Compared to the slave node initiating an inquiry and the master node responding after recovery, where the slave node receives the master node's response to determine if the master node is in an offline recovery state, in this application embodiment, the master node acts as an active notification mechanism. Upon detecting that it is in an offline recovery state, it directly sends a message representing its status to the slave node, enabling the slave node to... This allows for timely determination of the master node's offline recovery state, reducing the latency required for state synchronization between master and slave nodes. It also prevents further degradation of time synchronization accuracy due to failure to promptly determine the master node's recovery, thus improving the efficiency and reliability of time synchronization recovery. This application establishes a system-level mechanism for slave nodes to perceive the master node's state, and triggers the reconstruction of time synchronization between master and slave nodes based on the master node's offline recovery state. In scenarios where the master node recovers from offline status, this improves the fault tolerance of time synchronization, thereby solving the technical problem of slave nodes continuously operating in a free-clock state and struggling to recover synchronization after the master node has been offline for an extended period. Furthermore, after the slave node completes the restart of the time synchronization protocol stack, it performs time synchronization based on the time synchronization message sent by the master node, reducing interference from the old synchronization context on the new synchronization process and improving the success rate and convergence speed of time synchronization recovery.

[0216] This application also provides a slave node, such as Figure 8 As shown, the slave nodes include:

[0217] The status receiving module 801 is used to receive status messages sent by the master node, which are sent by the master node based on its status.

[0218] Processing module 802 is used to restart the time synchronization protocol stack when the recovery field contained in the status message indicates the recovery status after offline;

[0219] Synchronization module 803 is used to synchronize time with the master node based on the time synchronization message sent by the master node after the restart of the time synchronization protocol stack is completed.

[0220] In some embodiments, the processing module 802 is further configured to update the continuous count value when the recovery field contained in the status message indicates the recovery status after offline, the continuous count value representing the number of continuously received status messages whose recovery field indicates the recovery status after offline; if the updated continuous count value is a preset value, then the time synchronization protocol stack is restarted.

[0221] In some embodiments, the processing module 802 is further configured to send a time synchronization fault message to the Ethernet based on the status message.

[0222] In some embodiments, the processing module 802 is further configured to send a first time synchronization fault message to the Ethernet when the recovery field contained in the status message represents the recovery status after offline. The recovery receiving field contained in the first time synchronization fault message is used to represent the receipt of a status message in which the recovery field represents the recovery status after offline.

[0223] In some embodiments, the processing module 802 is further configured to send a second time synchronization fault message to the Ethernet when the recovery field contained in the status message represents a normal state. The recovery receive field contained in the second time synchronization fault message is used to represent a status message that has not received a recovery field representing a recovery state after going offline.

[0224] In some embodiments, the processing module 802 is further configured to determine the time synchronization accuracy; if the time synchronization accuracy is less than or equal to a preset offset threshold, terminate the stop time synchronization protocol stack, set the time synchronization stability flag of the time synchronization protocol stack to an unstable state, and reinitialize the time synchronization protocol stack; if the time synchronization accuracy is greater than the preset offset threshold, set the time synchronization stability flag of the time synchronization protocol stack to an unstable state, and reinitialize the time synchronization protocol stack.

[0225] In some embodiments, the processing module 802 is further configured to set the time synchronization stability flag to a stable state.

[0226] The slave node provided in this embodiment can execute the above-described vehicle time synchronization fault-tolerant method. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0227] This application also provides a slave node, such as Figure 9 As shown, the master node includes:

[0228] The first sending module 901 is used to send a status message to the slave node according to the status of the master node. In the case that the recovery field contained in the status message represents the recovery status after offline, the status message is used to instruct the slave node to restart the time synchronization protocol stack.

[0229] The second sending module 902 is used to send a time synchronization message to the slave node. The time synchronization message is used to instruct the slave node to synchronize time with the master node after completing the restart of the time synchronization protocol stack.

[0230] In some embodiments, the first sending module 901 is further configured to determine that the master node is in the offline recovery state in response to the offline recovery signal; and, when the master node is in the offline recovery state, to continuously send multiple frames of status messages with recovery fields representing the offline recovery state to the slave node.

[0231] In some embodiments, the first sending module 901 is further configured to send a status message representing the normal state by a recovery field to the slave node when the master node is in a normal state.

[0232] The master node provided in this embodiment can execute the above-described vehicle time synchronization fault-tolerant method. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0233] Figure 10 This is a structural diagram of the vehicle provided in this application. Figure 10 As shown, the vehicle 100 provided in this embodiment includes at least one processor 1001 and a memory 1002. Optionally, the device 100 further includes a communication component 1003. The processor 1001, memory 1002, and communication component 1003 are connected via a bus.

[0234] In a specific implementation, at least one processor 1001 executes computer execution instructions stored in memory 1002, causing at least one processor 1001 to perform the above-described method.

[0235] The specific implementation process of processor 1001 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0236] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0237] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0238] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0239] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0240] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0241] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0242] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0243] The division of units is merely a logical functional division; 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 indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

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

[0245] In addition, the functional units in the various embodiments of the present invention 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.

[0246] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part 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 of the various embodiments of this invention. 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.

[0247] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0248] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A vehicle-mounted time synchronization fault-tolerant method, characterized in that, Applied to slave nodes, including: Receive status messages sent by the master node, the status messages being sent by the master node based on its status; If the recovery field in the status message indicates a recovery status after offline operation, restart the time synchronization protocol stack. Once the time synchronization protocol stack has been restarted, time synchronization is performed with the master node based on the time synchronization message sent by the master node.

2. The method according to claim 1, characterized in that, When the recovery field in the status message indicates a recovery status after offline operation, restarting the time synchronization protocol stack includes: If the recovery field in the status message indicates a recovery status after offline, update the continuous count value, which represents the number of consecutively received status messages whose recovery field indicates a recovery status after offline. If the updated continuous count value is the preset value, then restart the time synchronization protocol stack.

3. The method according to claim 1, characterized in that, After receiving the status message sent by the master node, the method further includes: Based on the status message, a time synchronization failure message is sent to the Ethernet.

4. The method according to claim 3, characterized in that, The step of sending a time synchronization failure message to the Ethernet based on the status message includes: When the recovery field contained in the status message indicates a recovery status after offline, a first time synchronization fault message is sent to the Ethernet. The recovery receive field contained in the first time synchronization fault message is used to indicate that a status message indicating a recovery status after offline has been received.

5. The method according to claim 3, characterized in that, The step of sending a time synchronization failure message to the Ethernet based on the status message includes: If the recovery field in the status message indicates a normal state, a second time synchronization failure message is sent to the Ethernet. The recovery receive field in the second time synchronization failure message is used to indicate that the status message indicating the recovery state after offline is not received.

6. The method according to any one of claims 1 to 5, characterized in that, The restart time synchronization protocol stack includes: Determine the time synchronization accuracy; If the time synchronization accuracy is less than or equal to the preset offset threshold, the time synchronization protocol stack is terminated, the time synchronization stability flag of the time synchronization protocol stack is set to an unstable state, and the time synchronization protocol stack is reinitialized. If the time synchronization accuracy is greater than the preset offset threshold, the time synchronization stability flag of the time synchronization protocol stack is set to an unstable state, and the time synchronization protocol stack is reinitialized.

7. The method according to claim 6, characterized in that, After synchronizing time with the master node based on the time synchronization message, the process further includes: When time synchronization converges, the time synchronization stability flag is set to a stable state.

8. A fault-tolerant method for vehicle-mounted time synchronization, characterized in that, Applied to the master node, including: The master node sends status messages to the slave node based on the master node's status. In the case where the recovery field in the status message represents the recovery status after offline, the status message is used to instruct the slave node to restart the time synchronization protocol stack. A time synchronization message is sent to the slave node, which instructs the slave node to synchronize its time with the master node after completing the restart of the time synchronization protocol stack.

9. The method according to claim 8, characterized in that, The step of sending status messages to slave nodes based on the status of the master node includes: In response to the offline recovery signal, it is determined that the master node is in the offline recovery state; When the master node is in an offline recovery state, it continuously sends multiple frames of recovery field status messages to the slave node, representing the offline recovery state.

10. The method according to claim 8, characterized in that, The step of sending status messages to slave nodes based on the status of the master node includes: When the master node is in a normal state, it sends a status message to the slave node, indicating that the normal state is represented by the recovery field.

11. An on-board time synchronization fault-tolerant system, characterized in that, Includes master nodes and slave nodes; The master node is used to send status messages to the slave node according to the status of the master node; The slave node is used to receive the status message and, if the recovery field contained in the status message indicates the recovery status after offline, restart the time synchronization protocol stack. The master node is also used to send time synchronization messages to the slave nodes; The slave node is also used to synchronize time with the master node based on the time synchronization message sent by the master node after the restart of the time synchronization protocol stack is completed.

12. A slave node, characterized in that, include: A status receiving module is used to receive status messages sent by the master node, the status messages being sent by the master node based on its status; The processing module is used to restart the time synchronization protocol stack when the recovery field contained in the status message indicates the recovery status after offline. The synchronization module is used to synchronize time with the master node based on the time synchronization message sent by the master node after the restart of the time synchronization protocol stack is completed.

13. A master node, characterized in that, include: The first sending module is used to send a status message to the slave node according to the status of the master node, wherein, when the recovery field contained in the status message represents the recovery status after offline, the status message is used to instruct the slave node to restart the time synchronization protocol stack. The second sending module is used to send a time synchronization message to the slave node. The time synchronization message is used to instruct the slave node to synchronize its time with the master node after completing the restart of the time synchronization protocol stack.

14. A vehicle, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as claimed in any one of claims 1 to 10.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 10.

16. A computer program product, characterized in that, Includes computer execution instructions, which, when executed by a processor, implement the method as described in any one of claims 1 to 10.

Images