Time updating method, system and storage medium
By introducing time update proposal entries and voting mechanisms into the vehicle's electronic and electrical architecture, the problem of time anomaly propagation is solved, ensuring that time updates take effect only after being approved by a majority of nodes, thus achieving reliability and consistency in time synchronization.
Patent Information
- Application Number
- CN202610730184.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-05-25
- Publication Date
- 2026-07-07
AI Technical Summary
In the vehicle's electronic and electrical architecture, time anomalies propagate rapidly and have a wide impact, making it difficult to effectively control time synchronization.
By generating time update proposal entries on the master node and performing difference calculations and voting mechanisms on the slave nodes, it is ensured that the proposed update time only takes effect when it is approved by a majority of nodes. This, combined with the effective delay mechanism and the hierarchical consistency strategy, reduces the risk of erroneous time propagation.
It effectively suppresses the spread of error timing and abnormal jump propagation, improves the reliability and consistency of time synchronization, and reduces the impact of master node failure or attack.
Smart Images
Figure CN122348792A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of consistency and time-trusted defense technology for vehicle-mounted distributed systems, and in particular to a time update method, system and storage medium. Background Technology
[0002] Currently, in-vehicle electronic and electrical architecture has evolved from traditional multi-domain distributed control to centralized computing and regional control. Multiple high-performance controllers need to share consistent system time for sensor alignment, task scheduling, and log forensics. Related technologies employ a master-slave structure for in-vehicle time synchronization, where the master node selects the time source and broadcasts it to the slave nodes. However, these technologies are prone to causing time anomalies to propagate rapidly and over a wide area. Therefore, addressing these technical shortcomings has become a pressing issue for those skilled in the art. Summary of the Invention
[0003] The purpose of this application is to provide a time update method, system, and storage medium that can reduce the risk of error time propagation.
[0004] To address the aforementioned technical problems, this application provides a time update method applied to a master node, including: Generate a time update proposal entry; the time update proposal entry includes the proposed update time; The time update proposal entry is broadcast so that slave nodes can calculate the difference between the proposed update time and the local reference time and vote based on the difference and the acceptable interval radius; Count the number of votes that agree with the proposed time-update; When the number of votes agreeing to the time update proposal reaches a majority threshold, the time update proposal is submitted and a time update proposal submission notification is broadcast so that the slave nodes update the wall clock time to the proposed update time.
[0005] In some embodiments, the time update proposal entry further includes an activation delay, so that the slave node determines a local activation anchor point based on the activation delay, the monotonic time of the moment the time update proposal entry is received, and a journey delay, and when the local monotonic time reaches the local activation anchor point, the slave node updates the wall clock time to the proposed update time.
[0006] In some embodiments, the acceptable range radius of the slave node is obtained based on the upper bound of network uncertainty, the upper bound of local drift uncertainty, and the upper bound of processing uncertainty; the upper bound of network uncertainty is obtained based on the heartbeat round-trip time delay; the upper bound of local drift uncertainty is obtained based on the upper bound of the drift rate of the slave node and the time interval since the last submission.
[0007] In some embodiments, the local reference time of the slave node at time k is obtained based on the wall clock time and monotonic timing recorded at the last commit time of the slave node, as well as the monotonic timing of the slave node at time k.
[0008] In some embodiments, the master node is elected; when the master node fails, a new master node is elected.
[0009] In some embodiments, it also includes: If the difference between the proposed update time and the original time is less than a preset threshold, then weak consistency broadcasting is used.
[0010] To address the aforementioned technical problems, this application also provides a time update method applied to slave nodes, including: Receive a time update proposal entry broadcast by the master node; the time update proposal entry includes the proposed update time. The difference between the proposed update time and the local reference time is calculated, and a vote is taken based on the difference and the acceptable range radius, so that the master node counts the number of votes that agree with the time update proposal item. When the number of votes that agree with the time update proposal item reaches the majority threshold, the time update proposal item is submitted and a time update proposal item submission notification is broadcast. Receive the notification of submission of the time update proposal entry and update the wall clock time to the proposed update time.
[0011] In some embodiments, updating the wall clock time to the proposed update time includes: The local effective anchor point is determined based on the effective delay specified in the time update proposal entry, the monotonic timing of the moment when the time update proposal entry submission notification is received, and a one-way delay. When the local monotonic timer reaches the local effective anchor point, the wall clock time will be updated to the proposed update time.
[0012] To address the aforementioned technical problems, this application also provides a time update system, comprising: a master node and slave nodes; The master node is used to generate time update proposal entries; the time update proposal entries include the proposed update time; broadcast the time update proposal entries, count the number of votes in favor of the time update proposal entries, and when the number of votes in favor of the time update proposal entries reaches a majority threshold, submit the time update proposal entries and broadcast a time update proposal entry submission notification. The slave node is used to calculate the difference between the proposed update time and the local reference time and to vote based on the difference and the acceptable range radius; to receive the time update proposal entry submission notification and to update the wall clock time to the proposed update time.
[0013] To address the aforementioned technical problems, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the time update method applied to a master node as described above or the time update method applied to a slave node as described above.
[0014] As can be seen, the time update method provided in this application establishes a consensus mechanism among multiple nodes (controllers), submits time updates as time update proposal entries, and the proposed update time only takes effect when it is approved by a majority of nodes. This can reduce the risk of erroneous time propagation caused by single point failure or attack of the master node and suppress the propagation of abnormal jumps.
[0015] The time update system and computer-readable storage medium provided in this application both have the aforementioned technical effects. Attached Figure Description
[0016] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the prior art and embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0017] Figure 1 A flowchart illustrating a time update method provided in an embodiment of this application; Figure 2 This is a schematic diagram of a system architecture provided in an embodiment of this application; Figure 3 A proposal and voting timing diagram provided for an embodiment of this application; Figure 4 This is a flowchart illustrating a time update method provided in an embodiment of this application. Detailed Implementation
[0018] The core of this application is to provide a time update method, system, and storage medium that can reduce the risk of erroneous time propagation.
[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0020] Please refer to Figure 1 , Figure 1This is a flowchart illustrating a time update method provided in an embodiment of this application, applied to a master node, as shown in the reference. Figure 1 As shown, the method includes: S101: Generate a time update proposal entry; the time update proposal entry includes the proposed update time.
[0021] The master node can generate a time update proposal entry after receiving an external time synchronization value. The time update proposal entry includes the proposed update time. It may also include the source, effective delay, etc.
[0022] S102: Broadcast the time update proposal entry so that slave nodes calculate the difference between the proposed update time and the local reference time and vote based on the difference and the acceptable interval radius.
[0023] The master node broadcasts the time update proposal entry. The slave nodes calculate the difference between the proposed update time in the time update proposal entry and the slave node's local reference time, and vote based on this difference and the acceptable range radius.
[0024] In some embodiments, the local reference time of the slave node at time k is obtained based on the wall clock time and monotonic timing recorded at the last commit time of the slave node, as well as the monotonic timing of the slave node at time k.
[0025] Node i records the wall clock time at the moment of its last commit. With monotonous timing The local reference time at any time k is: .
[0026] Let be the local reference time (s) of node i at time k. The most recently submitted wall clock time (s). The monotonic timing (s) for node i. Let k be the monotonic time (s) of node i at the time of submission, where i is the node index (dimensionless) and k is the time index (dimensionless) calculated from the local reference time.
[0027] The local reference time relies solely on monotonic timing increments, which prevents the wall clock from being modified by local software and affecting voting.
[0028] In some embodiments, the acceptable interval radius is obtained based on the upper bound of network uncertainty, the upper bound of local drift uncertainty, and the upper bound of processing uncertainty; the upper bound of network uncertainty is obtained based on the heartbeat round-trip time delay; the upper bound of local drift uncertainty is obtained based on the upper bound of the drift rate of the slave node and the time interval since the last submission.
[0029] Acceptable interval radius of node i for: .
[0030] Let be the acceptable interval radius (s). Let be the upper bound (s) for network uncertainty. This represents the upper bound (s) for local drift uncertainty. To handle the upper bound (s) of uncertainty.
[0031] The upper bound of network uncertainty is estimated using heartbeat RTT. The upper bound of local drift uncertainty is based on the upper bound of the drift rate of node i. Estimated based on the time interval since the last submission, take . Let $i$ be the round-trip time (s) of the heartbeat measured at node $i$. Let be the upper bound of the drift rate of node i (dimensionless, s / s).
[0032] Node i calculates the difference between the proposed update time and the local reference time, using the following formula: .
[0033] The difference (in seconds) between the proposed update time and the local reference time.
[0034] The voting function for node i is: .
[0035] This represents the dimensionless voting result (1 indicates agreement) of node i on the time update proposal item, and 0 indicates rejection.
[0036] The voting function directly rejects callback jumps. For positive transitions, an adaptive interval is used to determine whether they are interpretable. Node i can also reject obviously unreasonable proposals based on local business state constraints and record the reasons for rejection for auditing purposes.
[0037] Constructing a local reference time using monotonic timing and combining it with the network RTT and drift upper bound to estimate the acceptable range helps maintain consistency in judgments under different node drift characteristics.
[0038] S103: Count the number of votes that agree with the proposed time update.
[0039] S104: When the number of votes agreeing to the time update proposal reaches the majority threshold, submit the time update proposal and broadcast the time update proposal submission notification so that the slave node updates the wall clock time to the proposed update time.
[0040] Set majority threshold N represents the number of nodes in the consensus cluster. The master node counts the number of votes in favor. .when When the time update proposal is initiated, the master node commits the entry and broadcasts commit(entry) so that the slave nodes update their wall clocks to the proposed update time. The entry is the time update proposal entry, and commit(entry) is the notification to commit the time update proposal entry.
[0041] When the master node initiates an abnormal proposal, a majority of nodes will reject the proposal due to voting functions or local verification. The master node will not receive enough votes to reach the majority threshold, and the abnormal time will not be submitted to the cluster. In this case, the reason for rejection can be recorded, and degradation of external time sources can be triggered.
[0042] In some embodiments, the time update proposal entry further includes an activation delay, so that the slave node determines a local activation anchor point based on the activation delay, the monotonic time of the moment the time update proposal entry is received, and a journey delay, and when the local monotonic time reaches the local activation anchor point, the slave node updates the wall clock time to the proposed update time.
[0043] To ensure that all nodes switch time as simultaneously as possible in physical terms and to avoid time tearing caused by differences in network transmission, this embodiment adopts a relative delay activation mechanism.
[0044] The master node specifies the effective delay in the time update proposal entry. (For example, 50ms). When each slave node receives a notification to commit a time update proposal entry, it records the local monotonic time of receipt. And combined with the RTT measured by heart rate to estimate the time delay of a single trip. This allows for the calculation of more consistent local effective anchor points, using the following formula: .
[0045] The local monotonic time (s) is given when node i receives the commit notification. The estimated one-way delay (s) for node i. Let be the local effective anchor point (s) for node i. The effective delay is the relative waiting time (in seconds) after submission for the application to take effect.
[0046] Among them, Configure it to a value greater than the upper bound of network latency and leave a margin so that different nodes have similar physical wait times from submission to effectiveness.
[0047] When the local monotonic time reaches When updating the wall clock, the update method is as follows: . Let be the wall clock time (s) of node i.
[0048] Additionally, the commit anchor can be updated synchronously for subsequent reference in time construction, with the update formula as follows: ; .
[0049] Using the above formula, even if the monotonic counters of each node (such as TSC (Time Stamp Counter) or OSTick) are uncorrelated, the effective deviation can be compressed to the order of network jitter and one-way delay estimation error without requiring strict synchronization of hardware clocks; higher accuracy can be achieved under low jitter network (such as TSN (Time-Sensitive Networking)) conditions.
[0050] By calculating the local activation anchor point through a relative delay activation mechanism, the risk of short-term alignment caused by application asynchrony between nodes can be reduced, and the consistency of activation can be improved.
[0051] In some embodiments, the master node is elected; when the master node fails, a new master node is elected.
[0052] When the master node fails, a re-election is triggered after a timeout, and the new master node takes over the process of generating and submitting time update proposal entries, thereby maintaining the continuity of time services.
[0053] In some embodiments, it also includes: If the difference between the proposed update time and the original time is less than a preset threshold, then weak consistency broadcasting is used.
[0054] To reduce the consensus overhead caused by frequent minor adjustments, a hierarchical consensus strategy can be adopted. For minor adjustments (i.e., the difference between the proposed update time and the original time is less than a preset threshold), weak consistency broadcasting is used and audit records are kept. For large jumps exceeding the threshold, a majority voting and unified effective process is forced.
[0055] By employing master node re-election and hierarchical consistency strategies, continuity in master node failure scenarios can be enhanced and consensus overhead can be controlled.
[0056] refer to Figure 2 As shown, the time update method provided in the above embodiments of this application can be based on a system implementation including a cluster management module, a master node election module, a time proposal generation module, a local trusted verification module, a majority submission module, a synchronization application module, and an audit and processing module.
[0057] The system selects N nodes with time synchronization and computing capabilities within the vehicle to form a consensus cluster. The cluster elects a master node responsible for initiating time update proposals. Whenever a synchronized time value is received from an external time source or a transition requiring correction is detected, the master node generates a time update proposal entry and broadcasts it to the slave nodes. Each slave node independently calculates the acceptable interval and votes. Once a majority threshold Q is reached, the time update entry is committed and takes effect across all nodes with a uniform relative delay.
[0058] The cluster management module is used to maintain the node set and communication relationships, and is responsible for member changes and fault isolation.
[0059] The master node election module is used to perform master node election and term management, and provides master node failover.
[0060] The time proposal generation module receives external time synchronization values and source information, generates time update entries, and assigns an index. The local trusted verification module calculates a reference time using monotonic timing and the last commit time, calculates the acceptable range, and votes on the entries. The majority commit module tallies the voting results, determines if a majority has been reached, commits the entry, and generates a commit notification upon reaching a majority. The synchronization application module determines the effective time based on local calculations. The application time is synchronized across all nodes, and the consensus time after submission is output. The audit and handling module records voting results, rejection reasons and source information, and triggers alarms and degradation time-keeping strategies.
[0061] Each node in the system maintains a local reference time based on monotonic timing to prevent modifications to the wall clock from affecting voting. The acceptable range is composed of the node's self-estimated upper bound of drift and heartbeat RTT, reducing dependence on fixed thresholds. A relative effective delay is specified upon submission, and each node calculates its local effective anchor point, reducing application desynchronization caused by network jitter. Optional strategies with different consistency strengths are used for small corrections and large jumps to control real-time overhead.
[0062] refer to Figure 3 As shown, the following describes a specific system workflow: The cluster management module completes node discovery and cluster initialization, while the master node election module elects the master node.
[0063] After receiving the external time synchronization value, the master node generates a time update proposal entry and populates it. src and And broadcast it.
[0064] Each slave node is constructed based on a monotonic timing mechanism. ,calculate And execute the voting function .
[0065] The master node counts the number of votes in favor, V. If the majority threshold Q is reached, the entry is submitted and a submission notification is broadcast.
[0066] All nodes reach the local monotonic timer. Time synchronization application And update the commit anchor.
[0067] The audit and handling module records the voting results and reasons for rejection. If rejections occur consecutively, an alarm or downgrade will be triggered.
[0068] Figure 3 In the sequence diagram, m_apply, i represents the pair of... The abbreviation T_wall,i represents the value in the timing diagram. The abbreviation of .
[0069] In summary, the time update method provided in this application establishes a consensus mechanism among multiple nodes (controllers), submits time updates as time update proposal entries, and the proposed update time only takes effect when a majority of nodes agree. This can reduce the risk of erroneous time propagation caused by single point failure or attack of the master node and suppress the propagation of abnormal jumps.
[0070] Please refer to Figure 4 , Figure 4 This is a flowchart illustrating a time update method provided in an embodiment of this application, applied to a slave node, referenced. Figure 4 As shown, the method includes: S201: Receive the time update proposal entry broadcast by the master node; the time update proposal entry includes the proposed update time.
[0071] S202: Calculate the difference between the proposed update time and the local reference time, and vote based on the difference and the acceptable range radius, so that the master node counts the number of votes in favor of the time update proposal. When the number of votes in favor of the time update proposal reaches the majority threshold, the master node submits the time update proposal and broadcasts the time update proposal submission notification.
[0072] S203: Receive the notification of submission of the time update proposal entry and update the wall clock time to the proposed update time.
[0073] The master node generates a time update proposal entry upon receiving an external time synchronization value. The time update proposal entry includes the proposed update time. It may also include the source, effective delay, etc. The master node broadcasts the time update proposal entry. Slave nodes calculate the difference between the proposed update time in the time update proposal entry and their local reference time, and vote based on this difference and the acceptable interval radius.
[0074] In some embodiments, the local reference time of the slave node at time k is obtained based on the wall clock time and monotonic timing recorded at the last commit time of the slave node, as well as the monotonic timing of the slave node at time k.
[0075] Node i records the wall clock time at the moment of its last commit. With monotonous timing The local reference time at any time k is: .
[0076] Let be the local reference time (s) of node i at time k. The most recently submitted wall clock time (s). The monotonic timing (s) for node i. Let k be the monotonic time (s) of node i at the time of submission, where i is the node index (dimensionless) and k is the time index (dimensionless) calculated from the local reference time.
[0077] The local reference time relies solely on monotonic timing increments, which prevents the wall clock from being modified by local software and affecting voting.
[0078] In some embodiments, the acceptable interval radius is obtained based on the upper bound of network uncertainty, the upper bound of local drift uncertainty, and the upper bound of processing uncertainty; the upper bound of network uncertainty is obtained based on the heartbeat round-trip time delay; the upper bound of local drift uncertainty is obtained based on the upper bound of the drift rate of the slave node and the time interval since the last submission.
[0079] Acceptable interval radius of node i for: .
[0080] Let be the acceptable interval radius (s). Let be the upper bound (s) for network uncertainty. This represents the upper bound (s) for local drift uncertainty. To handle the upper bound (s) of uncertainty.
[0081] The upper bound of network uncertainty is estimated using heartbeat RTT. The upper bound of local drift uncertainty is based on the upper bound of the drift rate of node i. Estimated based on the time interval since the last submission, take . Let $i$ be the round-trip time (s) of the heartbeat measured at node $i$. Let be the upper bound of the drift rate of node i (dimensionless, s / s).
[0082] Node i calculates the difference between the proposed update time and the local reference time, using the following formula: .
[0083] The difference (in seconds) between the proposed update time and the local reference time.
[0084] The voting function for node i is: .
[0085] This represents the dimensionless voting result (1 indicates agreement) of node i on the time update proposal item, and 0 indicates rejection.
[0086] The voting function directly rejects callback jumps. For positive transitions, an adaptive interval is used to determine whether they are interpretable. Node i can also reject obviously unreasonable proposals based on local business state constraints and record the reasons for rejection for auditing purposes.
[0087] Constructing a local reference time using monotonic timing and combining it with the network RTT and drift upper bound to estimate the acceptable range helps maintain consistency in judgments under different node drift characteristics.
[0088] Set majority threshold N represents the number of nodes in the consensus cluster. The master node counts the number of votes in favor. .when When the time is set, the master node commits the entry and broadcasts commit(entry). The slave nodes receive commit(entry) and update the wall clock time to the proposed update time. Entry is the time update proposal entry, and commit(entry) is the notification to commit the time update proposal entry.
[0089] When the master node initiates an abnormal proposal, a majority of nodes will reject the proposal due to voting functions or local verification. The master node will not receive enough votes to reach the majority threshold, and the abnormal time will not be submitted to the cluster. In this case, the reason for rejection can be recorded, and degradation of external time sources can be triggered.
[0090] In some embodiments, updating the wall clock time to the proposed update time includes: The local effective anchor point is determined based on the effective delay specified in the time update proposal entry, the monotonic timing of the moment when the time update proposal entry submission notification is received, and a one-way delay. When the local monotonic timer reaches the local effective anchor point, the wall clock time will be updated to the proposed update time.
[0091] To ensure that all nodes switch time as simultaneously as possible in physical terms and to avoid time tearing caused by differences in network transmission, this embodiment adopts a relative delay activation mechanism.
[0092] The master node specifies the effective delay in the time update proposal entry. (For example, 50ms). When each slave node receives a notification to commit a time update proposal entry, it records the local monotonic time of receipt. And combined with the RTT measured by heart rate to estimate the time delay of a single trip. This allows for the calculation of more consistent local effective anchor points, using the following formula: .
[0093] The local monotonic time (s) is given when node i receives the commit notification. The estimated one-way delay (s) for node i. Let be the local effective anchor point (s) for node i. The effective delay is the relative waiting time (in seconds) after submission for the application to take effect.
[0094] Among them, Configure it to a value greater than the upper bound of network latency and leave a margin so that different nodes have similar physical wait times from submission to effectiveness.
[0095] When the local monotonic time reaches When updating the wall clock, the update method is as follows: . Let be the wall clock time (s) of node i.
[0096] Additionally, the commit anchor can be updated synchronously for subsequent reference in time construction, with the update formula as follows: ; .
[0097] By using the above method, even if the monotonic counters of each node (such as TSC (Time Stamp Counter) or OSTick) are uncorrelated, the effective deviation can be compressed to the order of network jitter and one-way delay estimation error without requiring strict synchronization of hardware clocks; higher accuracy can be achieved under low jitter network (such as TSN (Time-Sensitive Networking)) conditions.
[0098] By calculating the local activation anchor point through a relative delay activation mechanism, the risk of short-term alignment caused by application asynchrony between nodes can be reduced, and the consistency of activation can be improved.
[0099] In summary, the time update method provided in this application establishes a consensus mechanism among multiple nodes (controllers), submits time updates as time update proposal entries, and the proposed update time only takes effect when a majority of nodes agree. This can reduce the risk of erroneous time propagation caused by single point failure or attack of the master node and suppress the propagation of abnormal jumps.
[0100] This application also provides a time update system, including a master node and slave nodes; The master node is used to generate time update proposal entries; the time update proposal entries include the proposed update time; broadcast the time update proposal entries, count the number of votes in favor of the time update proposal entries, and when the number of votes in favor of the time update proposal entries reaches a majority threshold, submit the time update proposal entries and broadcast a time update proposal entry submission notification. The slave node is used to calculate the difference between the proposed update time and the local reference time and to vote based on the difference and the acceptable range radius; to receive the time update proposal entry submission notification and to update the wall clock time to the proposed update time.
[0101] In some embodiments, the time update proposal entry further includes an effective delay; the slave node is configured to determine a local effective anchor point based on the effective delay specified in the time update proposal entry, the monotonic time of the moment when the time update proposal entry submission notification is received, and a journey delay; when the local monotonic time reaches the local effective anchor point, the wall clock time is updated to the proposed update time.
[0102] In some embodiments, the acceptable interval radius is obtained based on the upper bound of network uncertainty, the upper bound of local drift uncertainty, and the upper bound of processing uncertainty; the upper bound of network uncertainty is obtained based on the heartbeat round-trip time delay; the upper bound of local drift uncertainty is obtained based on the upper bound of the drift rate of the slave node and the time interval since the last submission.
[0103] In some embodiments, the local reference time of the slave node at time k is obtained based on the wall clock time and monotonic timing recorded at the last commit time of the slave node, as well as the monotonic timing of the slave node at time k.
[0104] In some embodiments, the master node is elected; when the master node fails, a new master node is elected.
[0105] In some embodiments, the master node is further configured to: If the difference between the proposed update time and the original time is less than a preset threshold, then weak consistency broadcasting is used.
[0106] For a description of the time update system provided in this application, please refer to the above method embodiments; further details will not be provided here.
[0107] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps of the time update method as described in any of the above embodiments.
[0108] The computer-readable storage medium may include 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.
[0109] For a description of the computer-readable storage medium provided in this application, please refer to the above method embodiments; further details will not be repeated here.
[0110] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatuses, devices, and computer-readable storage media disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant details can be found in the method section.
[0111] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0112] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.
[0113] The time update method, system, and storage medium provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.
Claims
1. A time update method, characterized in that, Applied to the master node, including: Generate a time update proposal entry; the time update proposal entry includes the proposed update time; The time update proposal entry is broadcast so that slave nodes can calculate the difference between the proposed update time and the local reference time and vote based on the difference and the acceptable interval radius; Count the number of votes that agree with the proposed time-update; When the number of votes agreeing to the time update proposal reaches a majority threshold, the time update proposal is submitted and a time update proposal submission notification is broadcast, so that the slave node updates the wall clock time to the proposed update time.
2. The time update method according to claim 1, characterized in that, The time update proposal entry also includes an effective delay, so that the slave node determines the local effective anchor point based on the effective delay, the monotonic time of the moment of receiving the time update proposal entry, and a journey delay, and updates the wall clock time to the proposed update time when the local monotonic time reaches the local effective anchor point.
3. The time update method according to claim 1, characterized in that, The acceptable range radius of the slave node is obtained based on the upper bound of network uncertainty, the upper bound of local drift uncertainty, and the upper bound of processing uncertainty; the upper bound of network uncertainty is obtained based on the heartbeat round-trip delay; the upper bound of local drift uncertainty is obtained based on the upper bound of the drift rate of the slave node and the time interval since the last submission.
4. The time update method according to claim 1, characterized in that, The local reference time of the slave node at time k is obtained based on the wall clock time and monotonic time recorded in the last commit time of the slave node, as well as the monotonic time of the slave node at time k.
5. The time update method according to claim 1, characterized in that, The master node is elected; when the master node fails, a new master node is elected.
6. The time update method according to claim 1, characterized in that, Also includes: If the difference between the proposed update time and the original time is less than a preset threshold, then weak consistency broadcasting is used.
7. A time update method, characterized in that, Applied to slave nodes, including: Receive a time update proposal entry broadcast by the master node; the time update proposal entry includes the proposed update time. The difference between the proposed update time and the local reference time is calculated, and a vote is taken based on the difference and the acceptable range radius, so that the master node counts the number of votes that agree with the time update proposal item. When the number of votes that agree with the time update proposal item reaches the majority threshold, the time update proposal item is submitted and a time update proposal item submission notification is broadcast. Receive the notification of submission of the time update proposal entry and update the wall clock time to the proposed update time.
8. The time update method according to claim 7, characterized in that, The step of updating the wall clock time to the proposed update time includes: The local effective anchor point is determined based on the effective delay specified in the time update proposal entry, the monotonic timing of the moment when the time update proposal entry submission notification is received, and a one-way delay. When the local monotonic timer reaches the local effective anchor point, the wall clock time will be updated to the proposed update time.
9. A time update system, characterized in that, include: Master node and slave node; The master node is used to generate time update proposal entries; the time update proposal entries include the proposed update time. Broadcast the time update proposal entry, count the number of votes in favor of the time update proposal entry, and when the number of votes in favor of the time update proposal entry reaches the majority threshold, submit the time update proposal entry and broadcast the time update proposal entry submission notification. The slave node is used to calculate the difference between the proposed update time and the local reference time and to vote based on the difference and the acceptable interval radius; Receive the notification of submission of the time update proposal entry and update the wall clock time to the proposed update time.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the time update method as described in any one of claims 1 to 6 or the steps of the time update method as described in claim 7 or 8.