AUTOSAR性能优化进入度量时代

从配置优化到运行时可观测：AUTOSAR性能优化进入"度量时代"

真正拖慢AUTOSAR项目的，从来不是AUTOSAR本身，而是我们不知道系统到底在干什么。

过去几年，


技术论坛


上总少不了这样的抱怨："AUTOSAR太重了。""


CPU


为什么一直跑满？""换更大的


MCU


吧。"很多团队遇到性能问题的第一反应，就是升级硬件。

但真正参与过量产项目的人都清楚，CPU利用率高，并不意味着CPU真的不够；很多时候，只是系统配置没有做好，或者团队根本不知道性能浪费在哪里。

如今，越来越多OEM和


Ti


er1开始意识到：AUTOSAR的性能优化，已经从"经验配置"进入"数据驱动"阶段。真正有效的方法，不再是反复修改配置、烧录、测试，而是建立一套完整的优化闭环——静态配置负责避免浪费，动态Tr


ac


e负责发现浪费。

这也是近年来AUTOSAR Efficiency


Te


mplate与各类Runtime Trace工具愈发受重视的根本原因。

一、为什么传统方法不够用了？

在传统ECU时代，一个


控制器


可能只有几十个Runnable、几个OS Task。出了问题，


工程师


还能凭经验判断：周期配置太快？Task优先级有误？RTE


通信


过于频繁？试几次配置，大多能解决。

但进入域控制器和中央计算平台后，局面彻底改变。一颗SoC往往同时承载上百个OS Task、数千个Runnable，还要处理多核调度、Cache共享、中断嵌套、Service调用、SOME/IP通信、Diagnostics、OTA、Logging、Security……系统已经复杂到——人无法再靠直觉理解整个运行过程。

于是项目陷入一种熟悉的循环：CPU高了，调周期；还高，改优先级；再改OS配置；仍然高。最后——"换颗CPU吧。"问题真的解决了吗？很多时候并没有，只是换了一颗更快的CPU，把真正的问题掩盖了。

第一步：先把静态配置做到"不浪费"

AUTOSAR并非一套固定的软件，而是一套高度可配置的平台。同样一个BSW，不同配置间的CPU开销可能相差数十个百分点。因此，大多数AUTOSAR供应商都会提供Efficiency Template，帮助项目规避常见的性能陷阱。

① 尽量采用Implicit Communication

很多


开发者


默认使用Explicit Communication，每次读取数据都经过RTE


接口


，若多个Runnable同时访问，还需同步保护——每一次读写都是一笔额外开销。

Implicit Communication则不同：Runnable启动时一次性复制输入数据，结束时统一更新输出，运行期间直接访问本地副本。这不仅减少了RTE调用次数，也降低了锁竞争和系统调用频率，对高频Runnable效果尤为明显。

② 不要让Runnable"白跑"

不少项目存在这样的Runnable：每1ms执行一次，真正有意义的数据却10ms才更新。结果CPU一直在运转，实际业务却什么都没干。很多时候，仅仅重新梳理Runnable周期，就能显著降低CPU占用。

Core0的CPU总负载约为 8.327%。

为了探究负载的构成，他启用了CPU负载的详细分类显示。负载被分解为以下几种状态：

FTD (Fetch Time Delay): 取指延迟

SD


F (Stall Data Fetch): 数据获取停顿

O


VR


(Overhe


ad


): 额外开销

IA (Instruction Active): 指令执行

CV (CV): （具体含义需查阅工具文档，可能与向量或缓存相关）

ICS (Instruction Cache Stall): 指令缓存停顿

RDR (RDR)

AS (AS)

DMU (DMU)

FR (FR)

启用后，甘特图上的执行条变成了彩色的分段条，每一段颜色代表一种CPU状态。这使得开发者可以精确地看到在任务执行期间，CPU具体在做什么，从而定位性能瓶颈（例如，大量的缓存停顿ICS或数据获取停顿SDF）。

③ 合理利用Single Stack Model

RAM


一直是MCU最昂贵的资源之一。传统做法中，每个Task拥有独立栈空间，但大部分Task并不会同时运行。因此像ETAS RTA-OS等实现采用了Single Stack Model，让多个B


asic


Task共享栈空间，利用任务不会并发执行的特点提高RAM利用率，对资源受限的平台尤其可观。

④ 不要滥用同步Client/Server调用

同步调用写起来最简便，却也最容易隐藏性能问题。高优先级Runnable调用低优先级服务，服务未返回，整个Runnable就一直等待，最终形成高优先级等待低优先级的倒挂，系统响应越来越慢。将部分接口改为异步调用，往往能明显改善整体响应时间。

配置做好之后，问题真的解决了吗？

许多工程师会说："我已经按照最佳实践配置了。"但项目后期依然可能遇到CPU偶尔100%、周期抖动、Watchdog Reset、某些Task偶尔超时……

为什么？因为真正影响系统性能的，还有很多运行时因素：Cache Miss、多核竞争、总线冲突、中断嵌套、数据访问热点、动态调度……这些问题，配置文件里根本看不到。

这时候，就需要进入第二阶段：Runtime Observability（运行时可观测性）。

第二步：让系统"自己告诉你发生了什么"

现代AUTOSAR开发越来越强调一句话：Don't Guess. Measure. 借助GLIWA T1、ETAS Pe


rf


ormance Analyzer等Trace工具，工程师能够直接观察系统运行过程，而非依赖日志或GPIO翻转间接推断。整个分析通常包含五个步骤。

第一步：实时采集系统Trace

建立与目标芯片的Trace连接，无需修改业务逻辑。系统运行中可持续记录Task切换、中断、Runnable执行、CPU利用率、Core负载等信息，真正做到非侵入式测量。

第二步：把时间轴"画出来"

相比一堆数字，甘特图更容易发现问题。多个CPU Core、多个Task、多个Interrupt全部按时间排列——某个1ms任务为何突然变成1.3ms？某次周期为何出现明显抖动？一眼便知。

第三步：不要只看CPU利用率

CPU 90%然后呢？真正重要的是这90%到底在忙什么。如果Instruction Cache Stall比例很高，说明CPU不是在计算，而是在等指令；如果Memory Stall持续增加，瓶颈可能来自数据访问。这比一句"CPU太高"有意义得多。

第四步：聚焦真正可疑的模块

发现异常后，直接定位具体函数，如EcuM_MainFunction或某个诊断服务，只观察它，过滤掉其它背景任务，才能找到真正的热点代码。

第五步：分析执行时间，而不是平均值

许多Bug都藏在平均值之外。平均执行时间80μs，最大执行时间720μs——真正导致系统超时的，往往就是那一次720μs。因此，除了CPU占用，还需重点关注Worst Case Execution Time（WCET）、Response Time、Jitter、Execution Distribution。这些指标，才真正决定系统能否满足实时要求。

二、从"配置"走向"度量"，AUTOSAR正在发生变化

过去，AUTOSAR开发更关注配置是否正确；今天，越来越多团队开始关注系统运行得怎么样。这背后，是汽车软件行业整体趋势的演进——以前的软件开发强调"把代码写出来"，现在则强调"把系统运行状态看得见"。

传统“试错”配置 vs. 现代“度量驱动”开发

可观测性（Observability）已成为


云计算


、大数据、


AI


平台的基础能力，如今正进入汽车软件领域。对于AUTOSAR而言，Efficiency Template解决的是"如何少浪费资源"，Runtime Trace解决的则是"资源究竟浪费在哪里"。两者并非替代关系，而是性能优化闭环中的两个阶段：

配置负责建立高效基础，Trace负责持续验证效果；

配置决定系统的起点，度量决定系统能够走多远。

未来，真正高效的AUTOSAR项目，不会依赖经验，不会依赖试错，也不会等到CPU跑满才开始排查问题，而是在开发过程中，让每一次配置修改、每一次代码提交，都能够通过真实的运行数据得到验证。

只有能够被度量的性能，才能真正被优化。