管理系统开发公司 车载基础软件——AUTOSAR CP典型哄骗案例SOME/IP和TSN时间同步

车载基础软件——AUTOSAR CP典型哄骗案例SOME/IP和TSN时间同步我是穿拖鞋的汉子，魔都中坚合手永远主义的一个屌丝工程师！今天是2023年2月7日，上海还鄙人着雨，估量是到了梅雨时节（提前到来？），真想说句我劝天公重安排，不让梅雨早时来！！！老轨则共享一段可爱的笔墨，幸免我方成为高常识低文化的工科男：“

咱们只需作念的，是走好咫尺的路，不急于求成，你只消专注于流程才会结出好果。无东谈主问津也好，技不如东谈主也罢，你都要试着适意下来，去作念我方该作念的事，而不是让内心惊慌、慌乱，淹没你本就未几的存眷和定力。定好主见，给我方少许时间，去千里淀，奋力成为更好的东谈主!

”Return to today's topic!本章节将共享几个基于 AUTOSAR CP 基础条约栈的典型哄骗案例供读者参考。

图片

凡哥双色球第2024079期红球奖号分析：

一、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 所示。

图片

app开发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 序列化模式收受大端一字节对王人。因为一字节对王人是最浅薄的对王人模式，erp，oa系统开发大多编译器很容易已毕；何况收受一字节对王人，序列化后莫得冗尾数据，报文的有用负载段都是专诚想兴味的数据，是以总体传输恶果获得了一定晋升。另外，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。

注：如上本色仅是我方在查询贵寓作念的汇总，拱同业作念初学学习！

愿你我确信时间的力量，

作念一个永远主义者！管理系统开发公司

本站仅提供存储奇迹，统统本色均由用户发布，如发现存害或侵权本色，请点击举报。

• 管理系统开发公司
• 车载
• 基础
• 软件
• AUTOSAR