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

车载基础软件——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 类型。自动驾驶域控制器的软件架构如图 2.1-8 所示。

图片

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 一侧。

图片

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

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

愿你我相信时间的力量，

做一个长期主义者！

本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请点击举报。