引入车载以太网之后,很好地解决了有大量数据交换或者发布/订阅模式需求的场景,不过呢,车内也有不少对通信过程中包含时间约束的应用场景,本文将介绍Classic AUTOSAR中和时间同步有关的内容。
首先,我们考虑以下场景:
无论是哪一种情况,关键词就是“同步”,我们需要有一个模块来管理同步时间基准。当然,在AUTOSAR的规范里,被称作为StbM——Synchronized Time-base Manager。
时间基准既可以代表运行时长,时间基准来源,也可以是真实世界时间。例如:
我们首先来看一下官方文档如何说明这个模块的。
作为管理模块,StbM并不会指定,也不提供任何网络时间协议,一切和总线类型和时间协议有关的工作都需要由上图蓝色框所示的
收到
作为时间基准的“代理”,StbM提供的时间信息,会提供给对应的“消费者”(OS & SWC)。
一般地,硬件参考时钟被用来作为基准时间的实现。由于硬件参考时钟达到寄存器最大值时会“溢出”再次从0开始增加,软件中会增加计数器共同来实现虚拟本地时间。
引入频分(Rate Deviation)以及偏移(Offset)之后,虚拟本地时间可以用来作基准时间。
还是这张图,我们来看看各个消费者是如何与StbM进行交互的。
Active Customer
Triggered Customer
Notification Customer
在汽车当中,为了完成时间同步,我们会定义不同的Master与Slave,它们之间靠
例如上图,我们可以有一个系统级的Master---Global time master,其他的ECU可以形成不同的time domain,并定义各自的time master与slave。
如上图所示,Master提供时间基准给其他ECU,由于同步前每个ECU都有自己的基准时间,为了能够更新本地的基准时间保持和Master同步,需要知道两个基准时间的偏移量(offset)。
Master周期性地发送Sync帧给Slave,那么Slave能够在t2时间收到Sync帧并记录t2时间。由于发送时的t1时间只有发送时刻才能得到,t1时间是无法和Sync帧一块儿发送的,因此需要再发送一次Followup帧,将t1时间作为数据传送给Slave。
Slave收到之后就能根据t2-t1-d得出这个offset,修正自己的基准时间,完成同步。
不过呢,你肯定会发现一个问题,就是总线上传输时间d,包括经由路由或交换机的延时没有被考虑在内,算式虽有,可还是无法完成计算。
为了计算出d的大小,我们可以采取这样的方案:
如果以太网控制器集成有时钟,能够为以太网消息加上硬件时间戳,那么时间同步的精确度可以进一步提高。如果你使用的是EB的以太网驱动,那么有无硬件时钟的两种情况,都能支持。
在实际工程中,为了精确度或是冗余度,可能会存在多个Master的情况,这个时候需要用到BMCA算法。
Master会发送Announce消息,来向各个Slave声明自己是主时钟,Slave会选择更好的那一个。
查了下我司软件,如果同时配置了本节点为Master和Slave,那么就会作为Gateway的角色参与时间同步。(强烈要求广告费= =..)
之前有说到,OS是目前定义的唯一一个triggered customer,需要提供接口给到Stbm做调度表同步,也即修改调度表对应的Time Base。
在同步之前,Stbm会检查OS调度表的状态,只有当状态处于WAITING,RUNNING或者RUNNING_SYNCHRONOUS时才能进行同步操作。
待更新
以太网时间同步机制基于PTP (Precision Time Protocol) ,在IEEE1588和IEEE802.1AS 中有对应描述。
IEEE802.1AS, 也被称作gPTP (generalized Precision Time Protocol), 可以被视为IEEE1588的一个子集。
然而, 无论是IEEE1588还是IEEE802.1AS,本身都不是基于车载需求而开发出来的,因此,目前所用的以太网时间同步机制基于IEEE802.1AS有一定的扩展以及限制。
由于车载以太网中,硬件拓扑,ECU等都是静态的,所以BMCA算法往往也是不需要的。