autosar 时间同步on以太网

wwj557

公众号回复· “以太网时间同步” 获取vector以太网时间同步手册

本文主要是说一下报文的本身，具体的细节还需要自己跟着手册去研究源码。



01

overview Ethtsyn

    时间同步 on 以太网。以太网作为传输介质，来给控制器做时间同步。时间同步管理模块 Stbm 实际上是不依赖于具体的role，不依赖于具体的传输介质。

本文只写以太网的时间同步。EthTsyn



时间同步的节点。可以是 主节点，从节点， 转发节点。这个在之前的文章有说到过。



我们知道以太网的报文是有类型去别的。

以太网的时间同步报文类型为

0x88F7 所以在看到以太网的报文时，发现类型是0x88F7 就知道，这个是时间同步报文。目前autosar 使用的是gPTP （PTPv2 抓包显示）

时间同步的通信是多播的形式，不是针对固定的IP 来发报文，，还是指定一个MAC 地址。所有的节点都可以收到。而且这个MAC 地址是固定的 即：

01：80：C2：00：00：0E

下面我们来具体介绍一下gPTP 的以太网时间同步



02

报文类型

在同步过程中，主要有以下五种类型的报文。



可以分为 event 类型 和 general 类型，下面我们来解释 为什么。

2.1

sync

同步报文，同步报文本身的内容实际上是不包含任何时间信息的报文。只是发送方（master）在发送出来的那一刻，在自己的txconfirmation 中断中，记录自己的发送时刻，这个称之为 egress_time.

接收端接收到sync报文，记录自己接收到的时刻，称之为igress_time.

为什么叫事件呢，因为这算是一个通知事件，master端通知slave,我开始时间同步了，后面要跟着牛逼的报文了。这个跟着的报文就是 follow_up 报文。



2.2

pdelay_req

这个报文是slave 端主动触发发送的报文，也算是一个事件，slave端 告诉 master, 我现在想计算一下传输延迟。因为前面的sync 和 followup 实际上是单向的同步，其中有传输延迟是没有办法计算的。

这里从端主动发一下 pdelay 。然后master端需要回两帧 报文，一帧是 pdelay_resp 告诉slave,我下面要发送带时间信息的报文了。pdelay_resp_follow_up 报文，这个是具有时间信息的报文，即：发送pdelay_resp 的具体时间。



2.3

pdelay_resp

如上面所说，master端响应，通知slave 我接下来要告诉你 这一帧报文从我这里出去的egress_time 是多少了。这个是在pdelay_resp_follow_up报文中体现



2.4

follow_up

follw_up 报文是 master方 紧跟着 sync报文发出的报文，这报文的内部数据包含了 sync的 egress_time 信息。

preciseOriginTimestamp



注意，我的宝

注意这里面的TLV, 这个TLV 和传统以太网的可能不一样。所以如果说你配置的autosar gPTP 没有选择遵循传统的标准，而且遵循autosar的标准的gPTP 这样可能和 传统的gPTP设备无法进行时间同步。

2.5

pdelay_resp_follow_up

这里面是master方 发送，包含了pdelay_resp 的egress_time 的报文。

问大家一个问题。为什么总是第二帧 follow_up 来带着上一帧的报文时间呢？

因为想记录的是发送方真实发送报文到总线上了。这时候软件已经无能为力改变报文内部的具体数字了，所以需要第二个周期来把时间信息回读到follow up 报文中。



上面的五个报文解释应该清晰了。下面对应着图看一下会更清晰。



3

利用vector工具配置 master / slave

偷一下懒。具体直接发文档发给大家吧。哈哈