在传统汽车时代，车辆的软件架构相对简单。

一个ECU负责一个功能：

  • 发动机控制器控制喷油；
  • ABS控制器负责制动；
  • BCM负责车身功能；
  • 仪表负责显示。

ECU之间主要通过CAN通信。

CAN网络虽然可靠，但它本身并不提供统一时间概念。

每个ECU都有自己的本地时钟：

ECU_A Clock
10:00:00.000

ECU_B Clock
10:00:00.005

ECU_C Clock
10:00:00.010

即使晶振频率一样，经过一段时间运行后，由于：

  • 晶振误差；
  • 温度变化；
  • 电压变化；

不同ECU之间也会产生时钟漂移。

过去：

几个毫秒的差异并不会影响车辆功能。

但是进入智能汽车时代：

车辆的软件架构发生巨大变化。

现在一辆智能汽车中可能存在：

  • 多个摄像头；
  • 激光雷达；
  • 毫米波雷达；
  • IMU；
  • 高性能中央计算平台；
  • 车载以太网交换机。

自动驾驶算法需要：

把不同传感器在同一个时间点采集的数据进行融合。

例如：

摄像头：

Timestamp:
100000 us

毫米波雷达：

Timestamp:
100020 us

两个数据相差20us。

算法知道：

这是同一时刻附近的数据。

但是如果：

Camera:
100000 us

Radar:
120000 us

20ms时间差对应车辆移动：

高速情况下可能达到几十厘米。

融合算法可能认为：

两个传感器看到的是不同位置。

因此智能汽车必须解决一个核心问题：

整辆车必须拥有统一、准确、可靠的时间基准。

这就是AUTOSAR StbM诞生的原因。

第一章 StbM是什么？为什么AUTOSAR需要它？

1.1 StbM的全称

StbM：

System Time Base Manager

系统时间基准管理模块。

它属于AUTOSAR Classic Platform中的基础软件模块。

它的核心职责：

管理整车系统时间，并向其他软件模块提供统一时间基准。

简单理解：

StbM就是汽车软件世界中的“时间管理员”。

它负责：

  • 获取外部时间；
  • 校准本地时间；
  • 管理系统时间；
  • 提供同步状态；
  • 通知应用时间变化。

1.2 StbM在AUTOSAR架构中的位置

典型AUTOSAR架构：

+--------------------------------+
| Application                    |
|                                |
| Sensor Fusion                  |
| ADAS Algorithm                |
+--------------------------------+
              |
              |
+--------------------------------+
| RTE                            |
+--------------------------------+
              |
              |
+--------------------------------+
| BSW Service Layer              |
|                                |
|          StbM                 |
|   System Time Base Manager     |
+--------------------------------+
              |
              |
+--------------------------------+
| Communication Stack            |
|                                |
| EthSM                         |
| EthIf                         |
| Eth Driver                    |
+--------------------------------+
              |
              |
+--------------------------------+
| Ethernet Hardware              |
+--------------------------------+

StbM位于：

BSW Service Layer。

它不负责：

  • Ethernet报文发送；
  • PTP协议解析；
  • MAC驱动。

这些由下面模块完成。

StbM关注的是：

系统时间如何被整个AUTOSAR软件使用。

第二章 StbM和gPTP是什么关系？

很多工程师第一次接触时会有一个疑问：

gPTP是不是直接控制StbM？

答案：

不是。

两者关系：

          gPTP
           |
           |
 Ethernet Time Synchronization
           |
           |
          Eth Driver
           |
           |
        Time Sync Driver
           |
           |
          StbM
           |
           |
 Application

gPTP负责：

网络时间同步

也就是：

如何让网络中的多个ECU时间一致。

例如：

中央计算：

10:00:00.000000

摄像头：

10:00:00.000050

gPTP计算：

Camera需要调整：

-50ns

而StbM负责：

系统时间管理

例如：

应用调用：

StbM_GetCurrentTime()

返回：

123456789 us

应用不需要知道：

这个时间来自：

  • GPS？
  • gPTP？
  • 本地晶振？

这就是软件分层。

第三章 StbM内部核心概念

理解StbM，需要掌握几个关键概念。

3.1 Time Base（时间基准）

StbM管理的是：

System Time Base。

例如：

整车定义：

Vehicle Time Base

所有ECU：

同步到这个时间。

类似：

公司的统一服务器时间。

3.2 Time Base Provider

时间来源。

可能包括：

来源1：gPTP

车载以太网：

GrandMaster Clock
        |
        |
      gPTP
        |
        |
       StbM

来源2：GNSS

自动驾驶车辆：

通常存在：

GNSS时间。

例如：

GPS UTC：

2026-07-08 10:00:00

作为最高级时间源。

来源3：本地时间

如果没有外部同步：

StbM可以运行：

Local Time。

3.3 Synchronized Time 和 Offset

StbM内部通常维护：

本地时间

Local Time：

ECU自己的计数。

例如：

MCU Timer:
123456789

系统时间

Global/System Time：

同步后的时间。

例如：

Vehicle Time:
202607081000000

两者之间：

存在Offset。

公式：

System Time

=
Local Time

+
Offset

gPTP更新：

Offset。

第四章 StbM工作流程解析

下面看一次完整流程。

Step 1：ECU启动

车辆上电：

Power ON

 |
 |
MCU Startup

 |
 |
BSW Init

 |
 |
StbM Init

此时：

StbM还没有同步。

状态：

UNSYNC

Step 2：Ethernet建立通信

以太网启动：

Eth Driver

↓

EthIf

↓

EthSM

↓

gPTP

网络发现：

Grandmaster。

例如：

中央计算平台：

GM Clock

Step 3：gPTP完成时间同步

交换：

Sync：

Master ---> Slave

Follow_Up：

Master ---> Slave

Delay_Request：

Slave ---> Master

计算：

  • 链路延迟；
  • 时钟偏差。

Step 4：StbM更新System Time

同步结果：

进入StbM。

例如：

之前：

Local Time:

100000050 ns

同步：

Offset:

-50 ns

修正：

System Time:

100000000 ns

Step 5：应用获取统一时间

ADAS应用：

调用：

StbM_GetCurrentTime()

得到：

100000000 ns

摄像头：

雷达：

激光雷达：

全部基于同一时间。

第五章 StbM提供哪些核心接口？

不同厂商实现可能不同，但典型接口包括：

5.1 StbM_Init()

初始化StbM。

启动：

  • 时间管理；
  • Time Base。

5.2 StbM_GetCurrentTime()

获取当前系统时间。

例如：

应用：

timestamp = StbM_GetCurrentTime();

用于：

  • 数据标记；
  • 日志记录；
  • 传感器融合。

5.3 StbM_GetSyncTime()

获取同步时间。

区别：

Current Time：

当前时间。

Sync Time：

已经同步的时间。

5.4 StbM_GetTimeBaseStatus()

获取同步状态。

例如：

SYNC
ASYNC
TIMEOUT

应用可以判断：

当前时间是否可信。

第六章 StbM和AUTOSAR其他模块关系

6.1 StbM与EthTSyn

车载以太网同步：

通常：

EthTSyn
 |
 |
StbM

EthTSyn负责：

PTP/gPTP协议处理。

StbM负责：

系统时间管理。

6.2 StbM与RTE

应用不会直接访问EthTSyn。

而是：

Application

↓

RTE

↓

StbM

保持AUTOSAR分层。

6.3 StbM与DEM

如果时间同步失败：

例如：

  • Grandmaster丢失；
  • Sync超时；
  • Clock异常。

StbM可以触发：

DEM事件。

例如：

Time Synchronization Lost

第七章 为什么自动驾驶离不开StbM？

场景1：多传感器融合

没有StbM：

Camera Time

Radar Time

Lidar Time

互相不知道。

有StbM：

Vehicle Time

 |
 +---Camera
 |
 +---Radar
 |
 +---Lidar

场景2：数据记录

自动驾驶测试：

需要记录：

Camera Frame
Radar Object
Vehicle Speed
Steering Angle
Brake Command

全部需要：

统一时间。

否则：

无法分析问题。

场景3：功能安全

ISO 26262系统：

需要：

可追溯性。

例如：

事故发生：

T0:
Radar Detect

T+20ms:
Fusion Decision

T+50ms:
Brake

没有统一时间：

无法证明系统行为。

第八章 StbM未来发展：从时间同步到中央计算时代

未来汽车：

趋势：

  • 中央计算；
  • 车载以太网；
  • TSN；
  • 自动驾驶。

时间会越来越重要。

未来：

车辆可能拥有：

             GNSS
              |
              |
        Grandmaster
              |
          gPTP Network
              |
 -------------------------
 |          |             |
Camera    Radar       Compute
              |
             StbM
              |
        Vehicle Software

StbM将成为：

整车软件统一时间入口。

总结：StbM不是“时间读取模块”，而是整车时间基础设施

很多工程师第一次接触StbM，会认为：

它只是一个读取时间的模块。

实际上：

StbM承担的是：

整车时间基础设施管理。

它连接：

  • gPTP时间同步；
  • Ethernet TSN网络；
  • AUTOSAR BSW；
  • RTE应用；
  • 自动驾驶算法。

未来智能汽车的软件复杂度越来越高。

计算能力可以不断提升。

传感器数量可以不断增加。

但是所有数据最终必须回答一个问题：

“这些数据，究竟发生在什么时候？”

而这个问题的答案：

就是：

AUTOSAR StbM提供的统一系统时间。

Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

从Prompt、 ReAct 到 Loop Engineering、Harness：AI Agent 工程化的 8 阶演进与 5 层落地架构

本文从最初的 Prompt 提示词，到提示词工程、到上下文工程、到 CoT 思维链、ReAct 模式，再到如今企业级落地不可或缺的Agent、AgentLoop、 Loop Engineering 与 Harness Runtime，Agent 的技术栈究竟经历了怎样的演进，以及是否有本质区别，要怎么做，进行了阐述

avatar AI Agent技术社区
cover

OpenHands 架构解析：从零实现一个 AI 编程 Agent

avatar AI Agent技术社区

Harness Engineering：AI Agent 稳定落地的核心引擎

摘要 Harness Engineering是AI Agent稳定落地的核心工程体系，旨在解决大模型直接应用于生产环境时的不稳定性问题。本文系统阐述了： 概念定义：Harness Engineering是一套包含目标定义、上下文供给、工具调用、流程编排等要素的AI Agent运行控制体系，将概率性模型能力转化为稳定工程能力。 必要性分析：大模型的概率性输出、信息猜测倾向、状态易失性等特点使其难以独

avatar AI Agent技术社区