Introduction to the Principle of Vehicle-mounted GPSP Synchronization

PTP/GPTP

In the car, vehicle time uses gptp to synchronize vehicle time. gptp is a simplified version of ptp. The specification definition comes from IEEE 802.1AS. Theoretically, it can achieve ns-level error. The comparison between different ptp versions and gptp is as follows:

1. GPTP synchronization principle

For gptp, all slave nodes are synchronized with the clock of the master (grandmaster); in the automotive field, master nodes are statically specified, and from the perspective of functional safety, MCUs with functional safety will be selected as master nodes. Therefore, gw (gateway) or tbox will generally be selected as the master, and the selection of gw or tbox will have an impact on the subsequent time management strategy of the entire vehicle.

The sync message (sync+follow up, hereinafter referred to as sync message) of the master node will use the second-layer message to spread throughout the clock tree. In gptp, the sync message uses the second-layer message, and the mac address is the specified broadcast mac address, but in fact the sync message is sent to the next hop node in the form of unicast. If the next node is Bridage, the correctionField (the time consumed by routing processing) will be re-corrected, and then the original information will be added to the sync message to route to the next hop node until it reaches the terminal node--End-Station. The sync message will contain master preciseOriginTimestamp, correctionField, etc. As shown in the following figure:

The slave node will adjust its clock frequency and offset according to the preciseOriginTimestamp and correctionField in the sync message. In order to eliminate the transmission delay on the bus, the slave node will send a delay measurement message. Since there is a gptp protocol stack in each hop on the vehicle, the clock synchronization measured in theory is unidirectional and accurate, as shown in the following figure:

Pdelay=((t(4)-t(1))-(t(3)-t(2)))/2

Pdelay measures only the transmission delay between two adjacent hops, so Pdelay will not penetrate the Bridge. From the above, we can see that compared with can tsync, gptp not only eliminates the transmission delay and processing delay when routing messages, but also the timestamp is added by hardware, so its clock synchronization accuracy is much greater than can tsync.

With the above foundation, we put all the gptp messages together, as shown below, and derive the formulas used by the slave node for amplitude modulation and phase modulation.

C Pdelay = ((t6-t3)-(t5-t4))/2 Gm = t1 + Pdelay + CorrectionField //Master clock time + cable transmission time + time spent on routing messages TimeOffset = t2 - Gm //Used for phase or amplitude modulation Ratio = (Gm-Gm_last) / (t2-t2_last) //Gm_last and t2_last can be earlier. FreqOffset = (1-Ratio)*1e9 //Used for frequency modulation

According to the specification, sync messages are generally sent every 125ms; and Pdelay messages are sent every 1s, or each sync message can trigger a Pdelay message. In general, the synchronization accuracy is configurable, and the local clock is adjusted only when the threshold is exceeded. The clock adjusted by gptp (gptp clock) is a clock tree endpoint at the same level as the network card clock source. It is generally abstracted into a device on Linux, that is, /dev/ptpx; when using hardware clock stamps, when the sampling point of network message sending or receiving arrives, the timestamp will be obtained from the gptp clock. The sampling points are shown in the figure below:

Additional: The above figure not only shows the sampling point, but also the latency. If you want to achieve ultra-high-precision clock synchronization, you need to compensate ingress_latency and egress_latency in the actual calculation.

The gptp message format is slightly complicated and will not be expanded here. From the perspective of understanding the gptp principle, you don't need to pay attention to the message format for the time being.