车载基础软件——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。


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

愿你我相信时间的力量，
做一个长期主义者!