车载诊断技术 发表于 2023-2-12 22:03:45

车载基础软件——AUTOSAR CP典型应用案例SOME/IP和TSN时间同步

我是穿拖鞋的汉子,魔都中坚持长期主义的一个屌丝工程师!
今天是2023年2月7日,上海还在下着雨,估计是到了梅雨时节(提前到来?),真想说句我劝天公重安排,不让梅雨早时来!!!
老规矩分享一段喜欢的文字,避免自己成为高知识低文化的工科男:

Return to today's topic!
本章节将分享几个基于 AUTOSAR CP 基础协议栈的典型应用案例供读者参考。
一、SOME/IP 应用案例
在自动驾驶项目中,整车和传感器通过 CAN 总线与自动驾驶域控制器的 MCU 进行交互,MCU 再将从 CAN 总线接收到的数据组包转发给 SOC 的各应用模块,MCU 与 SOC 之间则通过基于以太网的 SOME/IP 通信协议进行交互。
常用的 SOME/IP 以太网消息类型有:
-> REQUEST;
-> REQUEST_NO_RETURN;
-> NOTIFICATION;
-> RESPONSE。

其中 REQUEST 为期待响应的请求,客户端有需求时才会向服务端发送请求,且客户端会等待服务端反馈的结果。例如,客户端如果需要向服务端请求 VIN 码,则可发送 REQUEST 类型的消息。RESPONSE 则为响应消息,即服务端的用于响应客户端 REQUEST 类型的报文。例如:客户端向服务端请求 VIN 码,服务端则通过 RESPONSE 类型的消息给客户端回复 VIN 码。REQUEST_NO_RETURN 为不期待响应的请求,客户端有需求时才会向服务端发送请求,但客户端不关注结果。

若客户端如果需要向服务端请求打开车窗,客户端可发送 REQUEST_NO_RETURN 类型的消息。NOTIFICATION 为事件通知,客户端先向服务端订阅消息,服务端当发现被订阅的消息发生变化时则主动通知客户端。例如,客户端向服务端订阅车速信息,服务端如果发现车速变化则可发送 NOTIFICATION 类型的消息给客户端。在本案例中,由于 MCU 与 SOC 的通信数据具有数据量大、通信数据类型确定、数据周期性发送等特点,因此 SOME/IP 消息采用 NOTIFICATION 类型。自动驾驶域控制器的软件架构如图 所示。

MCU一侧基于AUTOSAR CP搭建应用软件, 主 要 包 括 三 个 应 用 模 块:VDC(Vehicle Data Center)将整车相关 CAN 数据做预处理,此类 CAN 数据主要指 VCU、EPS、EPB 等控制器数据;XDC(X Sensor Data Center)将各传感器的 CAN 数据做预处理,此类 CAN 数据主要指毫米波雷达、组合导航、智能摄像头等传感器数据;IDC(Internal Data Center)将预处理后的 CAN 数据转换成以太网数据并通过 SOME/IP 协议发送到 SOC 一侧。

OC 一侧基于 AUTOSAR AP 搭建,其中 SDC(Service Date Center)将以太网数据转换为 SOC 应用模块所需要的数据。在 SOME/IP 通信中,SOC 侧的 SDC 作为客户端,启动后即开始订阅 MCU 侧的所有已知服务,MCU 一侧收到订阅后即开始以固定周期向 SDC 侧发送订阅的报文,为保证实时性,SOME/IP 的数据传输周期与 CAN 报文周期一致。SOME/IP 序列化方式采用大端一字节对齐。因为一字节对齐是最简单的对齐方式,大多编译器很容易实现;并且采用一字节对齐,序列化后没有冗余数据,报文的有效负载段都是有意义的数据,所以总体传输效率得到了一定提升。

另外,SOME/IP 通信报文中的 Payload 也会添加时间戳和 Rolling Counter等信息,SOC 一侧的应用在使用 MCU 传来的数据之前,会先把时间戳取出来,并作数据校验、对齐、分等工作。SOME/IP 报文结构如下图所示。

本案例中的 SOME/IP 协议均基于 UDP 协议开发,它在用户有需求的时候才发送报文,这种方法有以下几点优势:

1、效率高。与 CAN 等周期性的网络相比,总线上不会出现过多不必要的数据,从而减少了资源消耗,点对点的全双工传输模式也让通信效率变得更高。
2、通信速率快。对于雷达这类较大的数据,需要 MCU 能在短时间内及时地将数据传输到 SOC,使用以太网是目前各类总线通信中速率最快的,它最能满足大数据量的通信需求。
3、数据长度长。CAN-FD 报文数据长度最大 64 字节,LIN 报文数据长度最大 8 字节,单帧 Flexray 报文数据长度最大 254 字节,而基于 UDP 的以太网单帧报文长度可达 1500 字节,能满足大数据的通信需求。
4、实现较简单。以太网已有成熟的 TCP/IP 协议栈,基于 Linux 平台还有开源的 Vsomeip 协议栈,可直接移植使用。

二、时间同步应用案例
在智能驾驶中,时间是一个非常重要的参数,各个系统中需要保证时间一致:
-> 车云系统之间时间一致;
-> 域控之间时间一致;
-> 域控与各个 ECU 之间时间一致;
-> ECU 与各个传感器之间时间一致等。

车云系统为保证时间一致,常在车载 ECU 中加装 GPS 模块,ECU 通过 GPS 数据与云平台时间保持一致。车内系统(域控之间、域控与 ECU 之间、ECU 与传感器之间)为保证时间一致主要采用:PTP(PrecisionTime Protocol 高精度时间同步协议)、PPS(同步脉冲信号)、AUTOSAR CP 同步方案等。如下图多传感器融合系统中,Camera ECU 通过高精度摄像头采集车道线、障碍物、标识等信息;Radar ECU 通过毫米波雷达进行障碍物、障碍物速度等信息的采集;

Camera/Radar ECU 通过CAN-FD 将处理的数据交给 ADCU 进行数据融合,ADCU 中自带 GNSS 芯片保证与云端时间一致。由于该系统对数据实时性、真实性要求比较高,所以需要保Camera/Radar ECU 采集的数据时间一致。为了达到该目的,如下图时间同步步骤所示,本案例采用了 AUTOSAR CP 时间同步解决方案,即ADCU 作为 Time Master 实体,Camera/Radar ECU 作为 Time Slave 实体,由 ADCU 对 Camera/Radar ECU 进行时间同步。



时间同步的步骤与方法如下:

1、ADCU 以 1s 为周期发送同步帧,即图中 t1 时刻发送 t0 时刻的时间戳。
2、Camera/Radar ECU 在 t2 时刻收到同步帧后,记录 t2 时刻的时间戳。
3、ADCU 间隔固定时间(100ms)后发送跟随帧,发送内容即 Δt0 时间。
4、Camera/Radar ECU 在 t3 时刻接收到跟随帧后,进行绝对时间计算并将绝对时间更新到 ECU 中,
公式为:t3 = t0 +Δt0 + t3–t2。


注:如上内容仅是自己在查询资料做的汇总,拱同行做入门学习!

愿你我相信时间的力量,
做一个长期主义者!
页: [1]
查看完整版本: 车载基础软件——AUTOSAR CP典型应用案例SOME/IP和TSN时间同步