本文约5,600字，建议收藏阅读
作者 | 汽车与基础软件
出品 | 汽车电子与软件
需求先行，可能你现在做的控制器还用不到时间同步，所以很难去理解，所以这里说以下为什么要用时间同步，当了解了为什么要用时间同步，那么就能自己产生时间同步应该是什么有的，应该要去解决什么样的问题了。域控制器，中央控制器是未来汽车电子电气架构的发展趋势，域控制器上可能会包含MCU、SOC还有各种外设，比如摄像头、各种雷达等，需要自动驾驶系统各部分有一个统一的时间基准，以保证系统处理的是同一时刻的信号，这就需要时间同步来实现。
TSN
时间敏感系统，统一的信号源，不同的输出，输出应该需要在同一时刻进行输出。先看见闪电，在听见打雷，这给人的感觉就是不同步。看电视一样，声音和视频要一致，才有比较好的体验感。AVB
不同输入，输入到同一个ECU进行处理，这就需要相同的时间刻度。不然的话， 比如相机是前一时刻的信息，雷达是这一时刻的信息，那么处理器就很难办了。
那么对于我们汽车上面的时间同步方案。从上面的介绍可以看出来，依赖于两个东西，一个是通信 一个是 协议。在车上 ECU与ECU 交互的最多的就是CAN 和ETH。对于协议 在autosar的规范里面说到了gPTP 协议。本文将主要讲gPTP.
既然是车上用的了，那么就有可能存在外部购买的设备和车上的设备不完全兼容的现象，因为外部的商用产品可能是支持其他的协议没有完全支持gPTP。所以我们下面对PTP 与 gPTP 进行了一些比较。
PTP 和 gPTP 区别
| | | | | |
| | | | | 因为TC时钟没有master 和 slave port的概念，只有转发的概念，那么这个转发就意味着自己体内有报文过去了，这个时间必须要考虑到。也就是所谓的驻留时间。所以需要在follow up 报文的correction 里面添加这个信息。否则 时间在这个节点消耗了，对于下个节点来说 需要知道的。 |
| | | | | 硬件时间戳指的是报文里面包含报文出去时刻的时间信息。这个时间信息需要很准。且为真实的。所以在发出来的时候 打时间戳，这本身对硬件 算法就是一个考验。 |
| | | | | 路径 和 peerdelay 啥意思呢？这后面可能要说到E2E 和 peer delay。从左边也能看出来，gPTP 只支持peer delay 也就是说不支持E2E. 那么E2E 是啥？一个链路中 不止连个节点的时候，中间的switch 可以 是当作对等节点 还是 当作 一个简单的路。这样的计算方式是不一样的。peer delay 计算的是 两个相邻节点之间的路径延迟。E2E 计算的是 master 和 slave 之间的 路径延迟。 |
| | | | | 因为gPTP 只走L2 层协议，也就是说 这个 switch 需要识别到 时间同步的相关报文，不能当作普通的报文转发了。里面会有sequence, clockid 来区分 报文是给哪个节点的。所以switch需要直到。而且peer delay 是对等的，这里需要switch 来 作为一个对等节点 发送，恢复peer delay 报文。 |
| | | | | |
先罗列以下现在的L2, L2+， L3-， 以至于以后可能有的L4 都是应该有哪些智能器件。
算例超强的SOC 芯片
安全可靠的MCU 芯片
这些设备之间需要进行一定的连接。那么在连接就会产生不同的连接方式。对应的gPTP 的每个节点角色可能就是不一样的。
所以gPTP 里面大概有什么样的角色呢?
gPTP 各个时钟角色
主时钟是整个gPTP域的时间基准，负责发送校时用的时间信息，是整个系统的时间源。主时钟的时钟源一般具有高精度，能够与世界时（如GPS）保持同步。主时钟发送的Sync和Follow_Up报文，用于实现主从端口的时间同步。
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是一种同时具有多个端口且每个端口都可以作为从端口（接收同步信息）或主端口（发送同步信息）的时钟设备。它可以在多个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的过程。模型
因为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
我们将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大洋。仔细捋清楚，整篇不用看了。为什么放在这里才放出这张图，因为看到这里的同志们，才有可能不止仅仅收藏，而是真的想学习一下，了解一下。
前面的章节我们已经见其形，识其体。这里我们来对内部的时间戳，以及前面提到的驻留延迟，路径延迟给计算一遍。
一共有哪些时间是需要计算的呢？在同步的过程可以把每一步拆解开。如下图。路径延迟计算
计算路径延迟，需要对端的节点也支持gPTP。具体的测量过程如下拆解
•Request 端主动发送请求报文。并且记录自身的这个时间戳，这里我们记作T1经过一段时间之后，bridge 收到这个请求报文•Bridge 收到请求报文，并且进行回复。记录收到的时刻为T2. 并且通过response 报文把T2 信息发回来。发回来的同时记录自己这时刻的时间戳T3.•请求端收到response报文 记录自己的收到时刻T4.•Bridge 继续跟一帧follow up 报文来说明自己的T3 时刻。有了这些时间。我们可以算出来发送与接收报文的总时间。这里简单的进行 /2 来当作 单向的延迟。公式如下：注意这里多了一个参数 r, 这个 r是什么呢？前面我们想当然的认为左右两个节点的时钟频率是一样的。实际上他们可能是不一样的。也意思就是左边说自己过了100个tick, 右边也说自己过了100个tick，但是实际上的时间可能是不一样的。所以我们有必要让他们的tick 表示的实际时间长度 做到统一坐标轴。
但是如何去计算这个具体的数值呢？想一想我们需要请求和响应端对同一个报文进行计算。当然这里我们需要假定传输本身的延迟 不会波动太大，如果这个传输本身的波动太大可能会影响结果。所以我们也可以增加帧间隔来计算，这样能有效的降低传输本身的波动对r计算的影响。
这里我们采用sync 报文，假设10个sync报文计算一次。
这里我们就通过这个时间信息来算一下r
这里计算出来了r.
透明时钟下的时间信息
上面已经算出来了路径延迟。当然延迟还有驻留延迟。这个时间就不是协议通过外部的报文能算的出来的时间了，需要节点自己在内部进行计算。
那么我们在透明时钟下，sync 和 follow up 是如何被使用到的呢？
首先解释一下上图，上图是由master 节点发出sync 与 follow up 报文，随后经过一个bridge 节点，最后传给了slave 节点。注意这里的sync 是原来的那个sync. 但是follow up 已经不是那个followup 了。可以仔细看一下，第一段是correctionfield 1. 第二段变成了2.
也就是说在bridge 里面会修改followup 报文内部的correction field 信息。
这个correction field 内容是什么呢。
• 驻留时间
–在switch 中，ingress 到 engress 的时间长。就是switch 处理这个 报文从接收到发送的时候 这个时间长度。这个完全去觉得switch 内部的逻辑以及性能。这个时间是有比较计算进去的。
• 路径延迟
–在上一章节已经详细的进行了计算
• 传输时长
–以太网报文我们都知道 一个MTU 其实是很长的，而且 传输过程中是有带宽的。所以比如1400个byte的数据， 是一个一个信息出去的。如果是100M 的 和 1000M 的相比，传输所需要的时间肯定是不相同的。这里为了很精细化，也计算进来。有了这三个参数，我们就可以计算整体的一个correction 了。如下
/ END /
招募 | 特约撰稿人（兼职）
