AUTOSAR 时间同步之gPTP详解+应用

01 为什么要gPTP

需求先行，可能你现在做的控制器还用不到时间同步，所以很难去理解，所以这里说以下为什么要用时间同步，当了解了为什么要用时间同步，那么就能自己产生时间同步应该是什么有的，应该要去解决什么样的问题了。

域控制器，中央控制器是未来汽车电子电气架构的发展趋势，域控制器上可能会包含MCU、SOC还有各种外设，比如摄像头、各种雷达等，需要自动驾驶系统各部分有一个统一的时间基准，以保证系统处理的是同一时刻的信号，这就需要时间同步来实现。

TSN

时间敏感系统，统一的信号源，不同的输出，输出应该需要在同一时刻进行输出。先看见闪电，在听见打雷，这给人的感觉就是不同步。看电视一样，声音和视频要一致，才有比较好的体验感。

AVB

不同输入，输入到同一个ECU进行处理，这就需要相同的时间刻度。不然的话，比如相机是前一时刻的信息，雷达是这一时刻的信息，那么处理器就很难办了。

那么对于我们汽车上面的时间同步方案。从上面的介绍可以看出来，依赖于两个东西，一个是通信一个是协议。在车上 ECU与ECU 交互的最多的就是CAN 和ETH。对于协议在autosar的规范里面说到了gPTP 协议。本文将主要讲gPTP.

既然是车上用的了，那么就有可能存在外部购买的设备和车上的设备不完全兼容的现象，因为外部的商用产品可能是支持其他的协议没有完全支持gPTP。所以我们下面对PTP 与 gPTP 进行了一些比较。

02 时间同步协议

PTP 和 gPTP 区别

03 车载的各种设备是如何部署的

先罗列以下现在的L2, L2+， L3-，以至于以后可能有的L4 都是应该有哪些智能器件。

算例超强的SOC 芯片

安全可靠的MCU 芯片

传感器

激光雷达
毫米波雷达
超声波雷达
惯性导航
云端
摄像头
等等

通信

ETH
CAN
SPI
CSI
等等

网络

switch
多个switch

这些设备之间需要进行一定的连接。那么在连接就会产生不同的连接方式。对应的gPTP 的每个节点角色可能就是不一样的。

所以gPTP 里面大概有什么样的角色呢?

gPTP 各个时钟角色

GMC 主时钟

主时钟是整个gPTP域的时间基准，负责发送校时用的时间信息，是整个系统的时间源。

主时钟的时钟源一般具有高精度，能够与世界时（如GPS）保持同步。

主时钟发送的Sync和Follow_Up报文，用于实现主从端口的时间同步。

OC 普通时钟

OC是gPTP域中的一般设备，它们不具备GMC那样的时间基准功能，但能够接收GMC或其他OC的同步信息，并调整自己的本地时钟以保持同步。

接收GMC或BC发送的Sync和Follow_Up报文，并根据这些信息调整自己的本地时钟。

如有需要，可以发送Delay_Req报文以测量网络延迟。

TC（Transparent Clock，透明时钟）

TC是一种特殊的时钟设备，它不对gPTP报文进行时间戳的添加或修改，而是简单地将gPTP报文转发到下一个节点，并计算报文在其内部的驻留时间（residence time），然后将这个驻留时间添加到PTP报文的校正域中。

提高大规模网络中的时间同步精度，减少网络延迟对同步的影响。

支持两种类型的透明时钟：E2E（End-to-End，端到端）透明时钟和P2P（Peer-to-Peer，点对点）透明时钟。但是上面提到过，在gPTP 里面是只有P2P 这种方式的。不过不耽误介绍TC 本身。因为TC 不仅仅在gPTP中使用。

BC（Boundary Clock，边界时钟）

BC是一种同时具有多个端口且每个端口都可以作为从端口（接收同步信息）或主端口（发送同步信息）的时钟设备。它可以在多个gPTP域之间起到桥梁作用。

接收来自一个gPTP域的同步信息，并将其转发到另一个gPTP域。

在转发过程中，BC可以对同步信息进行必要的调整，以确保接收域的从时钟能够正确同步。

有了这些对角色的认知之后呢，我们在实际的应用场景中，就要根据实际不同的布置，来进行我们的授时配置。

这里面不同的报文走向也是不一样的。

网络基础知识

switch

在复杂的整车网络中，switch 尤为重要。这里给基础薄弱的同学们说一下switch是个啥子。

switch 走的内容协议是L2层协议，所以每个Port(看得见摸的着的硬件口)是都有自己的MAC 地址的。因为i在这里就没有IP等上面的一些数据的概念。和网口的布置如下（网络找的图）

不过他这个图没有说明具体的连接方式。不重要了，能表示出switch所属的位置即可。

MAC直连MAC，中间的接口总线一般为SMII/GMII/RMII/SMII，除SMII外都是并行的
PHY直连PHY，是物理层接口，或为RJ45或为光纤接口等，是串行的，编码方式不同。

因为后面用得到一些switch相关的知识点，所以这里我（致敬了一篇）网上看的文章来介绍以下switch的过程。

模型

PC1 想通过switch 给 PC2 发送报文

因为Swtich 是二层协议，所以这里写的192.168 这俩IP 对于Switch 是没什么用的。那么Switch 需要直到什么呢？

他需要直到PC1 的mac 和收到PC1的MAC需要往哪发。所以他需要直到PC1 和 PC2 mac的关系，与两个MAC。

所以switch中应该有个地址表。

MAC地址表

MAC地址表是交换机内部维护的一张表，用于记录网络中各个设备的MAC地址与交换机端口的对应关系。

MAC地址表通常包含动态MAC地址、静态MAC地址和黑洞MAC地址等类型。动态MAC地址由交换机通过学习数据帧中的源MAC地址自动获得，静态MAC地址则由网络管理员手动配置。

1.数据转发

–当交换机收到一个数据帧时，它会检查数据帧中的目的MAC地址，并在MAC地址表中查找该地址对应的端口。

–如果找到匹配的条目，交换机将数据帧直接转发到对应的端口，实现数据的快速、准确传输。

–如果未找到匹配的条目，交换机可能会采取广播方式将数据帧发送到所有端口（除了接收端口），以寻找目的设备。

2.提高网络效率

–通过维护MAC地址表，交换机能够避免不必要的广播，减少网络拥塞和碰撞，从而提高网络的整体效率。

3.网络安全

–静态MAC地址的配置可以帮助网络管理员控制哪些设备可以接入网络，增强网络的安全性。

–某些情况下，网络管理员还可以将特定MAC地址设置为黑洞MAC地址，以阻止来自该地址的数据帧在网络中传播。

4.网络监控与管理

–通过查看MAC地址表，网络管理员可以了解哪些设备已经连接到网络，以及它们连接到哪个端口。

–这有助于管理员进行网络监控、故障排查和性能优化等工作。

VLAN

vlan 可以理解为分组。

我们将PC1和PC3划分为VLAN10，PC2和PC4划分为VLAN20，那么相同的VLAN之间可以通信，不同VLAN之间二层不可以通信。

除了这种方法外，还可以使用基于MAC 地址划分 VLAN 、基于 IP 地址划分 VLAN 、基于协议划分 VLAN 、基于策略划分 VLAN 等方法来划分 VLAN。

回归正文。有了对switch的初步认识，我们知道了MAC转发有根据vlan的“限制”，因为是mac 所以有组播mac, 广播mac, 单播mac.

报文在MAC层

广播，单播，组播

MAC 的格式

单播 MAC 地址是指第一个字节的最低位是 0 的 MAC 地址。

组播 MAC 地址是指第一个字节的最低位是 1 的 MAC 地址。

广播 MAC 地址是指每个比特都是 1 的 MAC 地址。广播 MAC 地址是组播 MAC 地址的一个特例。

到这里我们对传输，节点，连接，部署都有了初步的基础知识了解。我们进一步说一下实际的场景。

应用场景

由上面可以直到，我们的应用场景和配置是自由的，所以下面举了两种例子

TC 场景

前面已经介绍了GMC, TC, OC 的一些意思，不清楚的可以回去看一下。这里的TC 可以认为是车上的switch. 下面的好多个OC 就是不同的ECU。那么问题来了，这样的结构是如何去授时的呢。或者说是gPTP 允许不允许这样的操作呢。如果允许需要给TC 设置成什么样，可以回头读一下前面，有答案。

有了这样的系统部署，我们分析以下应该的报文流向。无用至于 GMC 发出sync, followup 报文。最终到达OC。

前面有提到E2E 和 peer delay 的两种方式，gPTP 只支持peer delay 但是这里我们都说一下。

peerdelay

下面描绘的是GC 与 OC 之间走的是TC，并且用的是PeerDelay. 可以看出来sync 和 followup 的报文时串联下来的。但是中间多了个RT。这个RT 我们暂时先不着急说，后面会仔细说一下协议本身。

还有一组报文就是pDelay Req 与 Res。这个好像是两组了。没错，因为这里用的是peer delay 对等的实体的delay延迟计算。换句话就是相邻的两个节点。所以说各扫门前雪，大家都扫干净了，整体就不会差。不过这也就有个问题，假设TC 和 GMC 之间的 delay 没有计算对，这也会影响到OC 最终的时间计算。因为i这个计算出来的delay 会被当作correction 放在follow up 的报文里面传送到最后的OC 里面。大家还是管好自己吧，不要影响其他人。所以说，在tire1 的ECU 多数是OC，这里通过peer delay 的报文是不应该能发现GMC 的mac地址的。

注意这里的报文都是通过二层协议出来的

E2E

E2E 和上图就有很大的区别就是pdelay 的报文从OC 直达了GMC，确实牛逼果然强，不过如果节点很多的话，这样其实是很难保证的一个操作。在gPTP 里面是没有这样的操作的。因为在MAC转发的时候是根据MAC转发的。协议本身是2层协议。不支持L4层协议。这里只作为与前面的对比介绍，所以在你们实际的项目当中，如果最终的OC 发现了GMC 的mac 在peer delay 中出现了，一点要小心。

VLAN

在使用VLAN 的时候，TC 节点是不应该可以跨VLAN 传输时间同步报文的。可以理解为一个二层协议的报文，本来就需要根据实际的VALN tag 进行转发报文。所以这样对于整车的节点也是一种很好的表现，不要让时间的port 和数据的port 相互干扰。这样可能会出现一些不可预知的问题。

BC 场景

前面介绍了这么多TC 的内容，这里BC 可能就很容易理解了，BC 与TC 的区别在于BC 有自己的master port 与 slave port。所以说 BC 之后的节点可以说和前面的GMC 就没有什么关系了。BC 的slave 接受时间， master 进行授时。就和我们autosar中间件似的。接收数据，ASW调用com接口，鬼知道这个接口是什么协议来的。（可能例子不恰当，不过是这个意思）。BC 就不会有所谓的E2E 的概念了，毕竟我们俩就是 M 与 S。对于同步报文也比较简单。因为就是port 对 port的概念。

授时

可以看出这里就没有 BC 与 OC 了，因为在这一层级的系统里面，只有M 与 S 的关系，所以一切都变得清晰明了。不过具体下面的T1,T2,T3,T4,T,,,,, 后面慢慢说到。不着急。先明白了机制，再去了解算法，再去实际分析报文

VLAN

vlan还是有的，不过与前面的GMC 就没有关系了，因为正如前面所说后面的授时和GMC 没有关系了，后面的VLAN 和前面的VLAN 都不是一个东西，完全可以把VLAN tag 去掉都行。一切都有BC 管控。因为BC 有自己的M。屌的一批。这里也是和TC 的主要区别之一。

总结

GMC, BC, TC, OC 在一个系统中的表现如下。具体的报文走向，配置，mac的分发，vlan的设计可以依赖于前面的章节进行分析设计。这里不赘述。

下图价值100大洋。仔细捋清楚，整篇不用看了。为什么放在这里才放出这张图，因为看到这里的同志们，才有可能不止仅仅收藏，而是真的想学习一下，了解一下。

04 同步原理

前面的章节我们已经见其形，识其体。这里我们来对内部的时间戳，以及前面提到的驻留延迟，路径延迟给计算一遍。

一共有哪些时间是需要计算的呢？在同步的过程可以把每一步拆解开。如下图。

我们逐个进行计算分析

路径延迟计算

计算路径延迟，需要对端的节点也支持gPTP。具体的测量过程如下拆解

Request 端主动发送请求报文。并且记录自身的这个时间戳，这里我们记作T1经过一段时间之后，bridge 收到这个请求报文
Bridge 收到请求报文，并且进行回复。记录收到的时刻为T2. 并且通过response 报文把T2 信息发回来。发回来的同时记录自己这时刻的时间戳T3.
请求端收到response报文记录自己的收到时刻T4.
Bridge 继续跟一帧follow up 报文来说明自己的T3 时刻。

有了这些时间。我们可以算出来发送与接收报文的总时间。这里简单的进行 /2 来当作单向的延迟。公式如下：

注意这里多了一个参数 r, 这个 r是什么呢？前面我们想当然的认为左右两个节点的时钟频率是一样的。实际上他们可能是不一样的。也意思就是左边说自己过了100个tick, 右边也说自己过了100个tick，但是实际上的时间可能是不一样的。所以我们有必要让他们的tick 表示的实际时间长度做到统一坐标轴。