夜雨聆风"
AutoSar 这张分层图劝退了很多人,但每一行规范背后,都是有人替你踩过坑之后才写出来的。
—— 一线 AutoSar 工程师
做了这么些年新能源车 ECU 软件研发,我见过太多新同事第一次打开 AutoSar 官方规范时的表情:盯着那张 53 个模块的分层架构图看十分钟,默默关掉 PDF。
每次带新人我都会问一句:"你看懂了多少?"回答几乎一致:"太复杂了,没头绪。"我通常跟他们说,这张图不是给你一次看懂的,是给你将来随时回来查的。
AutoSar 给人的第一印象就是"复杂"。但做了这么多年下来,我越来越觉得,这"复杂"两个字背后还藏着一句话:每一行规范,都是有人替你踩过坑之后写出来的。
这篇是 AutoSar 系列的开篇,讲清楚三件事:它是什么、为什么这么复杂、怎么入门。
📌 本文看点
01
AutoSar 凭什么叫"汽车软件宪法"
02
新人为什么容易被劝退
03
CP 分层架构 + RH850 实战路线
WHAT IS AUTOSAR
一、AutoSar 是什么:不只是规范,是汽车软件的"宪法"
1. 一个让 Tier1 头疼的问题
讲 AutoSar 之前,先讲一个行业里的真实场景。早些年一家 Tier1 给大众供应车身控制器,代码基于自家私有架构写。后来又拿到通用的订单,通用的 ECU 架构、诊断协议、网络管理都跟大众不一样,工程师只能把应用层扒下来重写一遍 BSW。
更要命的是,过几年通用又换了平台,底层从一颗芯片换到另一颗,整个 BSW 几乎全部推倒重来。每接一个新项目,应用层都要为新 BSW 适配一次;每换一颗芯片,底层都要重写一遍。这就是没有 AutoSar 之前 Tier1 的日常。
2. AutoSar 的诞生:让软件和硬件解耦
2003 年,宝马、博世、大陆、戴姆勒-克莱斯勒、西门子 VDO、大众联合发起了 AutoSar(AUTomotive Open System ARchitecture)联盟。目标用一句话讲:
「让应用软件不依赖具体 ECU 硬件,让 BSW 不依赖具体芯片,让 OEM/Tier1/芯片厂各司其职。」
拆开来看,有三层意思:
应用层复用:同一套电池管理 SWC,既能跑在这颗 MCU 上,也能跑在那颗 MCU 上,不用改代码
BSW 复用:同一套 BSW 配置,既能配瑞萨 RH850 也能配其他芯片,只需换 MCAL
协同分工:OEM 出系统描述,Tier1 出 ECU 配置,芯片厂出 MCAL,各方拿到的接口是标准化的
AutoSar 把这件事做成了规范,而不是产品。规范里定义了 SWC 怎么描述、RTE 怎么生成、BSW 各模块的 API 长什么样、ARXML 应该用什么 schema。任何厂商按规范实现,理论上就能互换。
很多人把 AutoSar 称为汽车软件的"宪法",意思就是它不直接产代码,但它规定了所有人怎么写代码。
3. 谁在推:OEM + Tier1 + 工具厂商三方博弈
AutoSar 联盟现在的核心成员分三类:OEM(BMW、Ford、GM、Toyota、PSA、大众、奔驰……国内蔚来、小鹏、理想也都在跟进);Tier1(Bosch、Continental、ZF、Denso……);工具厂商(Vector、ETAS、EB、Mentor、KPIT……)。
三方博弈的结果是 AutoSar 规范越做越厚(现在 CP 4.x 版本规范文档加起来超过 2 万页),但也越来越接地气。每一条规则背后都有某个 Tier1 真实踩过的坑。所以学 AutoSar 的时候看到一些看起来很绕的机制,先别急着吐槽。它之所以这么设计,大概率是因为不这么设计的方案,有人替你试错过并付出了代价。
PITFALLS FOR NEWCOMERS
二、为什么新人容易被劝退
工作这些年,我发现 AutoSar 的劝退点几乎是固定的。每个人都会卡在同样的几个地方。这一节把我反复观察到的四个劝退点写出来。
1. 分层图太复杂,看一眼就想关
第一次打开 AutoSar 官方文档,看到那张"经典平台分层架构图":左边一栏 Application Layer、AUTOSAR Runtime Environment (RTE)、Basic Software (BSW)、Microcontroller 四层;右边一栏 Services、I/O、Communication、Memory、Complex Drivers 几个组;中间还塞着 OS、MEM、COM、DIAG、ECU M、COM M、NM 一堆缩写。
第一次看的人本能反应是这图谁画的,是不是想吓跑新人。后来我才明白,这张图本来就不是给一次看懂的,是给将来随时回来查的。每个方框对应一个 BSW 模块,每个箭头对应一组 API,图越复杂说明分工越细。这是工业级软件的特征。
我常跟新人说:别试图一次读懂这张图。先记住 SWC/RTE/BSW 三层,其他用到的时候再回来看。
2. ARXML 看起来像 XML 但又看不懂
第二劝是 ARXML。新人第一次打开一个 ECU Extract,看到满屏的:
<APPLICATION-SW-COMPONENT-TYPE>
<SHORT-NAME>BmsCore</SHORT-NAME>
<PORTS>
<P-PORT-PROTOTYPE>
<SHORT-NAME>SoCOut</SHORT-NAME>
<PROVIDED-INTERFACE-TREF DEST="SENDER-RECEIVER-INTERFACE">
/Interfaces/IfSoC
</PROVIDED-INTERFACE-TREF>
</P-PORT-PROTOTYPE>
</PORTS>
</APPLICATION-SW-COMPONENT-TYPE>
"这不就是 XML 吗?"很多人一开始是这么想的。直到改一个端口名字,改完整个工程就生成不出来了。ARXML 不是 XML。准确说,它是 XML 写的"汽车软件元数据"。它背后有一套严格的 MetaModel(元模型),规定哪些元素能嵌套哪些、REF 指向必须满足什么类型约束、PATH 必须怎么解析。
改一个字符可能让整个 ECU 配置失效。这就是 ARXML 的可怕之处,也是它的价值所在:强制约束,让配置错误在生成阶段就暴露,而不是在车上。ARXML 不是用来手写的,是用来读懂的。把 MetaModel 的概念先建立起来,再去读 ARXML,你会发现它是"带类型的 XML"。
3. 工具链贵到怀疑人生
第三劝是工具链。几套主流商业工具的授权基本都是六位数起步,对个人学习就是劝退门槛。新人的第一反应通常是:没工具怎么学?光看文档和 PPT 能学懂?
后来我发现,个人学习有几条野路子:
app4mc / AMALTHEA:Eclipse 开源项目,可以读写部分 ARXML
ArcCore:一个开源的 AutoSar 实现参考,代码可读
公开 ECU Extract 样例:Vector 和 EB 官网都有 demo ARXML 可下载
公司里的工程:只要合规允许范围内看代码看配置,是最直接的教材
工具不是学习的必要条件。真工程 + 公开规范 + 一颗想搞懂的心,才是。没有达芬奇也能学 AutoSar。先读懂 ARXML 和规范,工具等进了公司再上手,不会卡太久。
4. 先学 CP 还是 AP?资料打架
第四劝来自"选哪条路"。网上有人说 AP 是未来,CP 要被淘汰了;有人说 AP 还没成熟,先学 CP 不亏。两边都有道理,但新人不知道该信谁。
我的判断是,CP 和 AP 不是替代关系,是分工关系:
新能源车一个典型配置:1 个中央计算(AP)+ 3-5 个域控制器(部分 AP 部分 CP)+ 几十个 MCU(ECU 全是 CP)。所以学哪个取决于你想做什么岗位。做 MCU 软件的,CP 是必经之路;做域控或智驾的,AP 才是主战场。我自己长期在 MCU 软件一线,所以本系列主攻 CP。AP 会在最后一篇用一篇速览带过。CP 和 AP 不是单选题。先把一个吃透,再回头看另一个会快很多。
WHY CP MATTERS
三、为什么坚持做 CP:MCU 量产的刚需
既然劝退点这么多,为什么还要学?讲三个让我觉得"必须学"的理由。
1. 新能源车的 ECU 软件市场有多大
一辆燃油车大概 70-100 个 ECU;一辆新能源智能车大概 100-150 个 ECU。每个 ECU 里跑的软件,大部分都是 AutoSar CP 架构。
具体到车型:一个中端新能源车,VCU、BMS、MCU、DCDC、OBC、CMU、热管理、门控、座椅、灯光、PEPS、ABS/ESP、EPS、SRS……这些 ECU 加起来至少 60-80 个,其中 80% 以上跑 AutoSar CP。这不是"未来市场",是"现在的市场"。2025 年中国新能源车年销已经突破 1000 万辆,每辆车背后都是几十个 AutoSar ECU 在跑。
2. 招聘市场的信号
打开招聘 App 搜"AutoSar 工程师",你会看到:
普通嵌入式工程师:15-25k
会 AutoSar 的嵌入式工程师:25-45k
AutoSar 平台负责人:60k+
这不是营销号数据,是我自己的真实感受。AutoSar 是汽车电子行业少有的"技术壁垒 + 薪资溢价"双高的方向。为什么贵?因为 AutoSar 学习曲线陡、新人培养周期长、能独立交付核心模块的人少。一个能独立配置 ComM + CanNm + EcuM 的工程师,几乎可以独立负责一个 ECU 的 BSW 交付。
3. CP 的护城河:OSEK 之上的成熟生态
有人会说现在汽车软件都在往 SOA 走,CP 还有几年好日子?我的判断是至少 10 年。理由有三:
MCU 的算力天花板还没被突破:智驾域、座舱域确实在 AP 化,但车身控制、底盘、动力这些对实时性要求高的 ECU,AP 暂时进不来
CP 已经形成规模效应:芯片厂出厂自带 MCAL,工具厂有成熟工具链,OEM 有成熟配置,这个生态不是几年能替代的
安全合规壁垒:ISO 26262 的工具链认证、流程认证,新建一套体系成本极高
所以未来 5-10 年,MCU 级 ECU 软件市场依然是 CP 的天下。现在学 CP 不是夕阳方向,是稳健的高薪方向。
CP LAYERED ARCHITECTURE
四、CP 分层架构一图流
劝退点讲完,正式进入 AutoSar CP 的世界。先把心智地图建起来。
1. 三层架构:SWC / RTE / BSW
AutoSar CP 的核心就是三层:
┌─────────────────────────────────────┐
│ SWC (Software Component) │ ← 应用层
│ BmsCore / VcuStrategy / McuCtrl │
├─────────────────────────────────────┤
│ RTE (Runtime Environment) │ ← 运行时环境
│ Rte_<Swc>_<Runnable> │
├─────────────────────────────────────┤
│ BSW (Basic Software) │ ← 基础软件
│ ┌─────────┬─────────┬─────────┐ │
│ │ Service │ I/O │ COM │ │
│ │ OS/EcuM │ Dio/Adc │ Can/Com │ │
│ │ ComM/Nm │ Pwm/Gpt │ PduR │ │
│ ├─────────┴─────────┴─────────┤ │
│ │ MCAL (芯片抽象层) │ │
│ │ Mcu/Port/Can/Dio/Adc... │ │
│ └─────────────────────────────┘ │
├─────────────────────────────────────┤
│ Microcontroller (RH850 / ...) │ ← 硬件
└─────────────────────────────────────┘
SWC(应用层)是写业务逻辑的工程师的地盘,不直接调任何硬件 API,只通过端口和外界通信;RTE(运行时环境)是 SWC 和 BSW 之间的"翻译官",代码不是手写的,是用 DaVinci 等工具根据 ARXML 配置生成出来的;BSW(基础软件)是工程量最大的一层,底层驱动、通信栈、诊断栈、存储栈、状态管理都在这里,又细分为 Service、I/O、Communication、Memory 四大组,加上最底层的MCAL(微控制器抽象层)。
2. SWC:应用层只认端口
SWC 是 AutoSar 应用层的基本单元。有端口(Port):PPort(提供)和 RPort(需求);有接口(Interface):Sender-Receiver(数据)、Client-Server(调用)、ModeSwitch(模式);有 Runnable:被 RTE 调度的最小执行单元。
举个真实场景:一个电池管理 SWC BmsCore,它有一个 PPort SoCOut,通过 SR 接口对外提供电池剩余电量;有一个 RPort CellVoltIn,通过 SR 接口从底层 ADC SWC 拿电芯电压。
/* RTE 自动生成的接口 */
void Rte_Write_SoCOut_SoC(uint8 SoC);
uint16 Rte_Read_CellVoltIn_Voltage(void);
/* Runnable:周期 10ms */
void BmsCore_Run10ms(void)
{
uint16 volt = Rte_Read_CellVoltIn_Voltage();
uint8 soc = CalcSoC(volt);
Rte_Write_SoCOut_SoC(soc);
}
注意 SWC 代码里没有一个 Can_Write或 Adc_ReadGroup。SWC 不知道也不关心数据从哪来、到哪去。AutoSar 的<span leaf=">" 应用层复用"<="" span="">就是这么落地的。
3. RTE:层间胶水
RTE 是 AutoSar 最神秘的一层,因为它不在源码里手写,在配置阶段生成。RTE 生成器读取 SWC 描述(每个 SWC 有什么端口、什么 Runnable)、ECU 配置(端口被映射到哪些 PDU、Runnable 被映射到哪些 Task)、系统描述(信号在哪个 I-PDU、I-PDU 走哪条总线)。
然后生成 Rte_Swc_xxx.c/ Rte_Swc_xxx.h,里面有端口读写 API、Client-Server 调用 API、Runnable 的入口包装函数(被 OS 的 Task 调用)。RTE 把"SWC 之间怎么通信"这件事从应用层完全剥离出来。应用工程师只写 Runnable,通信走什么总线、走什么 PDU,由配置决定。
4. BSW:四大组 + MCAL
BSW 是 AutoSar 工程量最大的一层,粗略分四大组:
| Service | ||
| I/O | ||
| Communication | ||
| Memory |
最底层还有一层 MCAL(Microcontroller Abstraction Layer),直接和芯片寄存器打交道。MCAL 通常由芯片厂提供,比如瑞萨官方提供 RH850 的 MCAL 包,API 按规范走,实现完全针对 RH850 的寄存器。
5. 第一张"心智地图"
学 AutoSar 我建议这样建心智地图:三个角色,各管一层——应用工程师写 SWC、BSW 配置工程师用达芬奇配 BSW、MCAL/BSP 工程师对接芯片厂。RTE 和 BSW 的服务层是连接点。AutoSar 的核心价值,就是让这三个角色可以并行开发、独立替换。
TWO HARDWARE PLATFORMS
五、两个实战例子:RH850 和 ESP32-S3 在系列里的角色
光讲架构容易空,本系列会贯穿两个实战例子。这里先把它们的角色说清楚。
1. RH850:真实工程主战场
瑞萨 RH850 是我日常在公司项目里用的主战场。它有几个特点适合做 AutoSar CP 平台:
算力够用
多核 RH850(比如 F1KM 系列)能跑完整 BSW + RTE + 多个 SWC
外设丰富
CAN FD、ADC、PWM、GPT 这些 AutoSar 工程常用的外设都齐全
AutoSar 生态成熟
瑞萨官方提供完整的 MCAL 包,Vector DaVinci 有现成的 Static Code
车规级认证
ISO 26262 ASIL D 流程认证齐全
在后续篇章里,凡是涉及达芬奇配置、CanNm 抓包、EcuM 上下电时序、MCAL BringUp 这些真实工程场景,我都会以 RH850 平台为例。截图来自真实工程,配置片段来自真实 BSWMD。
出于合规考虑,我分享的截图和配置都会做脱敏处理,去掉项目相关的关键信息。读者看到的是"工程经验",不是"某个车型的源码"。
2. ESP32-S3:概念对照与跨平台类比
ESP32-S3 是本系列的"概念对照板"。选它有三个原因:没有 AutoSar 工具链门槛(用 ESP-IDF 就能跑)、架构和 RH850 差异大(Xtensa 双核、WiFi/BLE、无 Flash 模拟 EEPROM,正好做对照)、适合做"轻量化等价概念"(比如用 FreeRTOS 任务模拟 AUTOSAR OS 调度表、用 ESP32 的 CAN 控制器模拟 CanIf + CanTp 链路)。
ESP32-S3 不会用来跑完整 AutoSar 栈(也没法跑),它的角色是:
这个对照不是"等价实现",是帮助理解。读者在 ESP32-S3 上跑通对照 demo,再回头看 RH850 的真实配置,会发现 AutoSar 这么复杂,本质就是这件事。这就是概念对照的价值。
3. 为什么不用更多板子
有人可能会问:为什么不加 GD32、TC3xx 这些?我的考虑是,板子越多概念越散。本系列的核心目标是让读者搞懂 AutoSar,不是评测硬件。两块板子,一块真工程(RH850)、一块概念对照(ESP32-S3),足够覆盖所有场景。再多就是炫技,反而分散注意力。
CP VS AP
六、CP 和 AP:一句话讲清差异
很多人一上来纠结 CP 和 AP 选哪个。我用一段话讲清:
CP 是为 MCU 量身定制的 RTOS 软件架构,AP 是为 HPC 量身定制的 Linux 软件架构。CP 跑在 OSEK 风格的 OS 上,任务静态配置、内存静态分配、通信走 CAN/LIN/FlexRay;AP 跑在 POSIX OS 上,进程动态部署、内存动态分配、通信走 SOME/IP / DDS。
一个新能源车里,AP 管"大脑"(智驾、座舱),CP 管"小脑和神经"(底盘、动力、车身)。短期内谁也替代不了谁。
这就是为什么本系列主攻 CP。MCU 软件市场是 CP 的主场,而 MCU 软件工程师是市场需求最大、薪资溢价最高的人群。AP 我们会在系列最后用一篇速览带过,把 EM/SM/DM 三件套和 CP 的对应关系讲清楚,够 CP 工程师建立基本认知即可。
SERIES ROADMAP
七、这一系列会怎么走
1. 17 篇 7 阶段的路线图
这是整个系列的路线图:
| 三·通信栈 ★ | |||
| 四·BringUp ★ | |||
★ 标记的两个阶段是本系列的核心差异化。通信栈全链路 + RH850 BringUp,会有大量实战经验分享。
2. 工具链生态
本系列的工程截图和配置讲解都以达芬奇为主。但工具只是壳,配置背后的 AutoSar 规范是工具无关的,换一套工具照样能落地。
THE END
八、写在最后:给入门者的几句话
回到标题那句话,AutoSar 不是规范,是汽车软件的"宪法"。
我在工作中常被问:"AutoSar 这么复杂,到底怎么入门?"我的答案一直没变:别想着一次搞懂,先搞懂最小一块。
我自己真正入门的转折点,是在 RH850 台架上调试一帧 CAN 报文。盯着 CanIf 的回调函数,看到一帧报文从底层进来,经过 PduR 路由,最后被 COM 解包成信号,推到 RTE,SWC 在 Runnable里 Rte_Read_xxx()拿到数据。那一刻我突然意识到,AutoSar 的所有复杂度,都是为了把这一帧报文安全、可配置、可追溯地送到应用层。
从那以后我每学一个新模块,都先问自己一个问题:这个模块在替谁解决什么问题?答案有了,模块就活了。
「AutoSar 不难,难的是第一次跨进工业级软件的世界。心态过了,后面就是体力活。」
下一篇我会讲工具链。没有 Vector License,个人怎么学 AutoSar?我们会一起打开一个 ARXML,把它读明白,把 MetaModel 的概念建起来,然后在 ESP32-S3 上跑一个"伪 ARXML"概念 demo。
欢迎在评论区告诉我:
你正在哪个阶段被劝退?
最想先搞懂哪个模块?
公司用什么工具链、什么芯片?
APPENDIX
速查表:AutoSar CP 入门第一课
1. 三层架构一句话版
2. AutoSar CP vs AP 对比卡
3. 劝退者自救清单
4. RH850 vs ESP32-S3 角色卡
5. 系列路线图速览
01 开篇 → 02 工具链
03 分层 → 04 SWC → 05 RTE → 06 OS
07 Can → 08 ComM → 09 CanNm → 10 EcuM+BswM
11 达芬奇 → 12 Mcu BringUp → 13 MCAL 外设
14 UDS → 15 NvM
16 ISO 26262 → 17 BMS/VCU/MCU 案例
18 AP 速览
我是 {{AI与嵌入式OS系统应用}},新能源车操作系统研发工程师。AutoSar 系列第 01 篇。写给所有被那张分层图劝退过的同行,希望它能让你少走点弯路。
如果你觉得今天这篇有收获,欢迎点赞、在看、转发三连,我们下篇见。