AUTOSAR下网络时间（CAN）与本地 RTC 同步。

1. 时间同步的重要性

汽车电子等嵌入式系统中，RTC 时间同步的核心作用是实现多 ECU / 多设备的时间统一与事件溯源 ，保障系统协同工作的准确性、可追溯性和安全性。

汽车上分布着数十个 ECU（如 VCU、BCM、ADAS 控制器、娱乐系统等，不同的控制器，对精度的要求是不同的），每个 ECU 都有本地 RTC，但受晶振漂移、温度变化影响，本地时间会逐渐产生偏差。

若没有时间同步，不同 ECU 记录的同一事件（如踩刹车、车门解锁）会出现时间戳不一致的情况。
同步后，所有 ECU 以 CAN 网络的全局时间为基准，确保同一事件在各 ECU 中的时间戳完全对齐 ，支撑跨 ECU 的协同功能：
- 例如 ADAS 系统的传感器数据融合：摄像头、雷达、激光雷达的检测数据需基于统一时间戳才能准确匹配，实现目标识别与跟踪；
- 例如整车能量管理：VCU、BMS、MCU 需同步时间，精准控制充放电时机、电机启停逻辑。
- 同时DTC故障的发生具体时间也可以被记录下来，用于后续问题排查。

2. RTC时间与网络时间概念

在 AUTOSAR 架构中，RTC（Real-Time Clock，实时时钟）和 CAN 总线上传输的时间（通常是网络时间）是两个不同的时间，但是在开发中，会经常遇到RTC时间需要同步网络时间，二者的定位和作用不同：

RTC（实时时钟） ：属于本地硬件时间，通常是外部 RTC 芯片（这个芯片独立供电）提供，用于记录本地的真实时间（年、月、日、时、分、秒)，ECU的休眠唤醒断电均不影响这个时间。
CAN 总线上的时间 ：属于网络全局时间，通常由总线上的「时间主节点（Time Master）」生成并广播，其他节点（Time Slave）接收该时间，用于实现多 ECU 之间的时间协同（如事件同步、数据采集时间戳对齐等）。对于每个供应商来说，大家只需要从TM中取到时间信号，传输到自己的模块中去使用即可。

最终：让本地RTC时间 = CAN 网络上的时间。

3. 时间同步（不涉及时间精度）

3.1 触发方式

两种触发方式:

周期性同步网络时间。（例如1个小时同步一次，时间间隔不可太小。）
事件性同步网络时间。（例如ECU休眠唤醒，常用）
不可同步太频繁，否则会导致 RTC 时间频繁波动，影响故障时间戳的准确性。

3.2 接收链路

CanDrv-> CanIf -> CanTp -> PduR -> Com ->Rte 链路，将时间数据解析后传递给本地 RTC处理模块。属于传统的应用报文接收方式。

3.3 同步具体步骤

1. 检查CAN网络是否被唤醒（只在唤醒时同步）
2. 检查是否接收到CAN网络上时间同步的报文（需要设置标志位，代表同步报文已接收）
3. 检查只同步一次时间的标志位是否被置上（需要不被置上，代表没有同步）
4. 从RTE接口中获取到CAN报文上的（年、月、日、时、分、秒)
5. 获取本地RTC设置的时间。
6. 本地RTC与网络时间进行对比，同步，补偿。
7. 将同步，补偿后的时间设置成本地RTC时间。

4. 常用的接口

接口	定义
Gpt_GetGlobalTimeStamp	获取本地RTC时间
Gpt_SetGlobalTimeStamp	设置本地RTC时间

5. 注意事项

调用Gpt_SetGlobalTimeStamp时，必须先停止 RTC 计数器，再写入时间，RTC_StopTimer() → 写入时间 → RTC_StartTimer()。
严禁在初始化其他的地方调用 RTC_Init()。
同步时间之前需要进行时间合理性检查，不可月份大于12，天数大于31，小时大于24等。
本地要设置RTC的初始化时间，虽然不够真实，但是设置了不影响程序的功能，总得给个初始值吧！
不可周期同步太频繁。
时间同步时，可以补偿一些时间，因为CAN总线上的时间与APP层接收的时间不可能完全一致。