车载电子电气(E/E)架构模板
代表产品 / 原型:特斯拉集中式架构、新势力域控架构、传统分布式 ECU;开源原型 openpilot;行业标准 AUTOSAR 一句话定位:把一辆车从「100 个各自为政的小电脑」进化成「一台轮子上的数据中心」——同时保证刹车永远比车机流畅更重要。
1. 一句话定位
车载 E/E 架构 = 一套「安全等级隔离 + 实时总线 + 可整车 OTA」的移动分布式系统。
它可能是普通工程师能接触到的约束最多的架构:硬实时(刹车信号毫秒必达)、功能安全(出错会死人)、成本敏感(一辆车省 10 块钱 × 百万辆)、寿命 15 年、还要像手机一样 OTA 卖新功能。它的核心矛盾只有一个:「娱乐要迭代如飞,安全要稳如磐石」——这两种软件被物理地装在同一辆车上。
2. 业务本质:它在解决什么问题
传统汽车的软件是「买零件送的」:雨刷控制器、车窗控制器、发动机控制器……每个功能一个 ECU(电子控制单元),由不同供应商黑盒交付,车厂只做集成。结果是一辆车 100+ 个 ECU、几公里线束,加一个「下雨自动关窗」功能要协调三家供应商改半年。
「软件定义汽车」翻转了这个格局:车的差异化从马力变成了体验和智驾,软件从成本项变成了收入项(自动驾驶订阅、座舱应用、OTA 付费解锁)。这要求架构从「百个黑盒」收敛为「少数几台大算力计算机 + 软件平台」——车厂必须像互联网公司一样掌握自己的软件栈。
3. 核心需求与约束
功能性需求:
- [ ] 车辆控制:动力、底盘、车身(灯 / 窗 / 门锁)
- [ ] 智能驾驶:感知、规划、控制(传感器 → 决策 → 执行)
- [ ] 智能座舱:仪表、中控娱乐、语音、导航
- [ ] 网联服务:远程控车、车队数据回传、整车 OTA
- [ ] 诊断与售后:故障码、远程诊断
非功能性需求 / 质量属性:
| 质量属性 | 目标 | 为什么对这类系统重要 |
|---|---|---|
| 功能安全 | 关键功能按 ASIL 等级达标 | 刹车失灵不是 bug,是事故 |
| 硬实时 | 控制类信号毫秒级确定送达 | 「平均很快」没用,要「最坏情况也准时」 |
| 可用寿命 | 15 年 / 全生命周期可维护 | 车不是手机,用户不会三年一换 |
| OTA 能力 | 整车可升级、失败可回滚 | 软件收入和缺陷召回都靠它 |
关键约束(不可逾越的边界):
- 🔴 功能安全等级(ASIL):每个功能经危害分析与风险评估(ISO 26262 的 HARA)定出安全等级(刹车相关通常 ASIL-D,车机 QM)——它是行业标准而非法条,但是事实上的准入门槛;高低等级软件不允许互相影响,这是整个架构的第一分割线。
- 🔴 车规硬件:-40℃~105℃、振动、电磁干扰;算力和内存远比消费电子保守。
- 🔴 供应链现实:大量部件仍由 Tier1 供应商交付,架构要在「自研」与「集成」之间划清接口。
- 🔴 成本:单车硬件成本按分计,冗余不能无限堆。
4. 架构全景图
云端:OTA 服务 / 车队数据平台 / 远程诊断
▲ 蜂窝网络(TBox 网关,远程通道的收敛口)
─────────────────────────────┼──────────────────────────────
车内 │
┌──────────────────────────┴──────────────────────────┐
│ 中央计算平台(大算力 SoC) │
│ ┌─────────────────┐ ┌─────────────────────────┐ │
│ │ 智驾域(高实时OS) │ │ 座舱域(Linux/Android) │ │
│ │ 感知/规划/控制 │ │ 仪表(独立RTOS)│中控/娱乐 │ │
│ │ 按ASIL分级隔离 │ │ 安全显示与娱乐硬隔离 │ │
│ └─────────────────┘ └─────────────────────────┘ │
└───────────────┬─────────────────────────────────────┘
│ 车载以太网骨干(高带宽:视频流/大数据)
┌─────────────┼─────────────┬─────────────┐
▼ ▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│区域控制器│ │区域控制器│ │区域控制器│ │区域控制器│ (按车身位置就近接线)
│ 前左 │ │ 前右 │ │ 后左 │ │ 后右 │
└──┬─────┘ └──┬─────┘ └──┬─────┘ └──┬─────┘
│ CAN/LIN 支线(低带宽、高确定性:控制信号)
▼ ▼ ▼ ▼
传感器/执行器:电机 刹车 转向 灯 门窗 座椅 …(物理世界)灵魂在于:两套网络对应两种流量——以太网骨干跑「大数据」(摄像头视频、地图、OTA 包),CAN 支线跑「小而准」的控制信号(刹车指令 8 字节,但必须毫秒级确定送达);区域控制器按位置收线(省几公里线束),中央平台按软件分域(智驾和座舱各管各的)。
5. 组件职责
- 中央计算平台:整车的「大脑」,跑智驾和座舱两大域。为什么需要:软件定义汽车要求算力集中,功能才能跨域协同、统一 OTA。
- 智驾域(高实时 OS + ASIL 隔离):传感器融合 → 规划 → 控制指令。为什么需要:这是安全攸关的软件,必须运行在有实时性和安全认证的环境里,与娱乐彻底隔离。实践中用「ASIL 分解」:神经网络类主算法按 QM/ASIL-B 开发(它们做不了 ASIL-D 认证),旁边配一个 ASIL-D 的安全监控核做合理性校验与降级接管——聪明的部分低等级,兜底的部分高等级。
- 座舱域(Linux / Android):中控、娱乐、语音、应用生态。为什么需要:体验迭代要快,用消费电子的技术栈;但仪表显示(车速 / 告警)单独跑在小 RTOS 上——中控死机,车速表不能黑。
- 区域控制器(Zonal Controller):按物理位置就近接入传感器 / 执行器,做 I/O 汇聚和配电。为什么需要:把「每个功能拉一根线到对应 ECU」变成「就近接入 + 骨干网传输」,线束显著缩短(业界曾提出把数公里线束压到百米级的目标,现实量产的收益是大幅但渐进的)——线束是整车最重的部件之一,也是装配自动化的最大障碍。
- CAN / LIN 总线:控制信号的传输层,广播式、优先级仲裁。为什么需要:刹车信号要的不是带宽,是「最坏情况下也准时」——CAN 在受控的总线负载和优先级设计下能给出可计算的最坏时延(这正是它 40 年不死的原因;代价是低优先级帧在高负载下会被压制,所以总线负载率本身就是设计项)。
- 车载以太网骨干:高带宽流量(视频 / 地图 / OTA)的传输层。为什么需要:一颗 800 万像素摄像头就能挤爆所有 CAN 总线加起来的带宽。默认它是「尽力而为」的网络;若骨干要承载跨区安全信号,就要叠加 TSN(时间敏感网络)一类机制拿到有界时延——中央 + 区域架构正是这么做的。
- TBox / 网联网关:远程蜂窝通道的收敛口 + 内外网防火墙。为什么需要:远程攻击面要有统一卡口。但注意「唯一对外口」并不存在——蓝牙 / Wi-Fi(常在座舱主机)、OBD 诊断口、无钥匙射频都是对外接口,目标是让攻击面可枚举、每个口都有卡口;历史上著名的整车被黑事件,入口正是网联通道。
- OTA 管理(双分区 + 回滚):整车各控制器的固件编排升级。为什么需要:一次 OTA 涉及几十个控制器、依赖关系复杂,「升级到一半没电」必须是被设计过的场景。
6. 关键数据流
场景一:一脚刹车(硬实时链路,毫秒必达)
1. 踏板传感器 → 区域控制器(就近采集,双通道冗余)
2. 经同一低时延网段的 CAN 高优先级帧 → 制动控制器毫秒级收到并执行
(踏板与制动控制器刻意挂在同网段/专用冗余链路;若必须跨区,
骨干要用 TSN 等确定性以太网承载)
3. 智驾域同时收到该信号(它需要知道人接管了)
── 注意什么不在链路上:不经过中央 SoC 的应用层,不依赖任何
「可能在忙别的事」的部件。安全链路要短、要专、要冗余。
── 另注:传统车的行车制动始终有液压/机械主通路兜底,这里描述的是
线控/电子调节链路;纯 brake-by-wire(无机械备份)靠双冗余电子链路。场景二:一次整车 OTA(把「升级失败」设计成安全状态)
1. 云端下发升级活动(签名 + 版本依赖图)→ TBox 校验签名
2. 后台静默下载到各控制器备用分区(用户无感,可断点续传)
3. 安装条件闸门:P 挡 + 电量充足 + 用户确认(绝不在行驶中重启控制器)
4. 按依赖顺序编排安装 → 全部自检通过才整体提交
5. 任一控制器失败 → 整批回滚到旧版本(版本必须整车一致,不能一半新一半旧)场景三:影子模式(百万辆车 = 免费的测试车队)
1. 智驾算法新版本随 OTA 下发,但只「旁观」不控车
2. 新旧算法并行:新算法的决策与人类驾驶/旧算法对比
3. 不一致的场景(新算法想刹车而人没刹)→ 摘取片段回传云端
4. 云端用真实corner case 训练下一版 → 再 OTA → 循环
── 同 [演进与拆分](../../tutorial/14-演进与拆分大型系统.md) 的「影子流量」,
只是流量换成了真实道路7. 数据模型与存储选择
核心数据:信号(总线上的实时值:车速、踏板…);故障码 DTC;标定参数;固件版本矩阵;行驶数据 / 场景片段。
| 数据 | 存储类型 | 为什么 |
|---|---|---|
| 实时信号 | 不落盘,总线广播 + 内存 | 生命周期毫秒级,要的是新鲜不是持久 |
| 故障码 / 事件记录 | 控制器本地 Flash(类黑匣子) | 售后诊断和事故追溯,断电不能丢 |
| 标定参数 | 控制器 Flash,版本化管理 | 每车型 / 每批次不同,OTA 要能改 |
| 固件版本矩阵 | 云端关系型 | 「哪辆车哪个控制器什么版本」,召回和 OTA 的地基 |
| 回传场景数据 | 车端环形缓存 → 云对象存储 | 量大、稀疏有价值,只回传触发片段 |
8. 关键架构决策与权衡 ⭐
决策 1:分布式 ECU → 域集中 → 中央计算,走到哪一步?⭐
- 分布式(100+ ECU):供应链成熟、单点故障影响小;但软件散装、线束爆炸、OTA 几乎不可能。
- 域集中(动力 / 车身 / 座舱 / 智驾各一个域控):软件开始收敛,是当前主流。
- 中央计算 + 区域控制器:软件全集中、线束最省、OTA 最顺;但对车厂软件能力要求极高,单点失效防护(冗余)必须做足。
- 取向:行业整体向中央集中演进,但节奏取决于组织的软件能力——架构领先于能力 = 灾难(组织即架构 在汽车业的体现:供应链关系就是旧架构的形状)。
决策 2:安全域和娱乐域怎么隔离?⭐
- 物理隔离(各自芯片):最硬的边界,认证简单;成本高、跨域通信慢。
- 单芯片虚拟化(Hypervisor 分区):省钱省空间;但要证明「娱乐崩了绝不影响仪表」,认证成本极高。
- 取向:关键显示(仪表)倾向独立小系统兜底,大算力域间用虚拟化。原则不变:QM 级软件的任何行为,都不得影响 ASIL 级软件的资源和时序。
决策 3:OTA 全量推,还是差分 + 灰度?
- 全量包:简单可靠,但一次整车升级几个 GB,蜂窝流量成本 × 百万辆。
- 差分包 + 分批灰度:省 90% 流量,先推千辆观察再放量;代价是版本组合矩阵管理复杂。
- 取向:差分 + 灰度 + 失败率熔断是量产标配,同 IoT 平台 的 OTA 策略——只是这里「变砖」的代价是拖车。
决策 4:智驾数据全回传,还是触发式采集?
- 全回传:数据最全;但一辆车一天几个 TB,流量费和存储费按亿算。
- 触发式(影子模式不一致 / 急刹 / 接管时刻才回传片段):数据量降千倍,且条条是干货。
- 取向:触发式为主。数据的价值密度比数据量重要——corner case 才喂得肥算法。
9. 规模化与瓶颈
汽车的「规模化」= 车型数量 × 保有量 × 15 年生命周期:
- 第一个瓶颈:车型配置爆炸。 一个平台衍生 N 车型 × M 配置,固件版本矩阵指数增长。→ 破解:软硬解耦(同一软件平台 + 配置字激活差异),把「车型差异」从分支变成配置。
- 第二个瓶颈:OTA 车队管理。 百万辆车、蜂窝网络、用户随时熄火。→ 破解:断点续传 + 分批灰度 + 失败熔断 + 版本收敛治理(散版本是长期毒药)。
- 第三个瓶颈:数据回传成本。 → 破解:触发式采集 + 车端预筛 + Wi-Fi 时机回传。
- 第四个瓶颈:15 年维护。 芯片停产、系统过保,车还在路上跑。→ 破解:长供货协议、抽象层隔离硬件、安全补丁通道全生命周期保活。
10. 安全与合规要点
- 功能安全(Safety):ISO 26262 全流程管控,ASIL 分解与隔离;关键执行器双通道冗余;失效进入「安全状态」(如限速跛行回家)而不是直接罢工。
- 信息安全(Security):对外接口逐口设卡(TBox 收敛远程通道,蓝牙 / Wi-Fi / OBD 各有防线)+ 车内网络分区防火墙;总线消息认证(防伪造刹车指令);OTA 全链路签名(参考 Uptane 框架);R155/R156 法规强制要求整车网络安全与软件升级管理体系。
- Safety 和 Security 在车上是一回事的两面:被黑掉的转向系统就是安全事故。远程攻击面(蜂窝 / 蓝牙 / Wi-Fi)→ 车内横移 → 控制总线,每一跳都要设卡。
- 数据合规:行驶轨迹、座舱摄像头是高敏个人数据;各国对地理数据出境有强监管。
11. 常见误区 / 反模式
- ❌ 娱乐系统和控制系统混跑同一环境、共享总线无隔离 → ✅ ASIL 分区 + 网络分段:车机死机绝不能波及仪表和刹车。
- ❌ OTA 不设安装条件,行驶中重启控制器 → ✅ P 挡 + 电量 + 用户确认,失败整批回滚。
- ❌ 拿互联网「快速迭代」直接套安全件(周五下班推个刹车固件)→ ✅ 安全件走完整 V 流程验证;迭代自由度留给座舱和非安全域。
- ❌ 安全链路依赖「平均性能」(以太网今天不堵)→ ✅ 硬实时看最坏情况:控制信号走有界时延的链路——受控负载的 CAN,或叠加 TSN / 时间触发调度的以太网。
- ❌ 车内网络默认互信(进了车内网就随便发指令)→ ✅ 总线消息认证 + 域间防火墙,假设网联模块迟早被攻破。
- ❌ 智驾数据「先全存了再说」 → ✅ 触发式采集,价值密度优先。
12. 演进路线:MVP → 成长期 → 成熟期(不同阶段怎么设置)
| 阶段 | 形态 | 怎么设置(具体) | 此时该操心什么 |
|---|---|---|---|
| 传统起点 | 分布式 100+ ECU | 各功能独立 ECU,供应商黑盒交付,车厂做集成测试 | 集成质量;此阶段谈不上软件平台 |
| 域集中(当前主流) | 4~6 个域控制器 | 动力/车身/座舱/智驾各收敛为域控,座舱智驾先自研,整车 OTA 就位 | 自研与供应商边界、跨域通信标准化、OTA 体系 |
| 中央计算(演进方向) | 中央平台 + 区域控制器 | 软件全集中(服务化架构),区域控制器纯 I/O,软硬解耦按配置激活 | 组织软件能力、冗余设计、百万辆车队的软件运营 |
13. 可复用要点
- 💡 按「失效后果」分级隔离,而不是按「功能模块」:ASIL 混部隔离的思想,适用于一切「关键与非关键混跑」的系统(交易核心 vs 营销活动)。
- 💡 两种流量两张网:大带宽走高吞吐链路,小而关键走确定性链路——「控制面与数据面分离」的物理版。
- 💡 影子模式 = 用真实流量免费验证新版本:先旁观、比差异、再放权,任何高风险替换(风控模型、推荐算法)都适用。
- 💡 失败要有「安全状态」可去:跛行回家模式的思想——系统降级后停在哪,是设计出来的,不是碰运气(为失败而设计)。
- 💡 软硬解耦 + 配置激活:一套软件伺候 N 种硬件配置,SKU 管理的终极答案(同 嵌入式固件 决策 4)。
🎯 随堂检验
为什么刹车信号走 CAN 总线,而摄像头视频走车载以太网?
- ACAN 更新、以太网更老
- B刹车要的是最坏情况下的确定性延迟,视频要的是大带宽——两种需求对应两种网络
- C纯粹是成本原因
参考原型与延伸阅读
本模板基于以下真实开源项目与行业标准整理。
🔧 开源原型(可直接读代码):
- commaai/openpilot — 开源辅助驾驶系统,跑在真车上:感知→规划→控制闭环、通过 CAN 与整车交互、安全监控独立进程,是普通工程师读得到的最真实车载软件。
📖 行业标准 / 框架:
- AUTOSAR 官网 — 汽车软件架构的行业标准组织:Classic(安全实时域)与 Adaptive(高算力域)两套平台,正对应本模板「两种价值观的软件」。
- Uptane 官网 — 汽车 OTA 安全更新的开放框架(多级签名、防降级、部分失陷仍安全),对应第 6 节场景二与第 10 节。
📌 一句话记住车载 E/E:一辆车里住着两种软件——「稳如磐石」的安全件和「迭代如飞」的体验件,全部架构功力都花在让它们同居而互不伤害:分级隔离、两张网、受控 OTA。所有设计都在回答:『娱乐怎么疯,刹车都不受影响。』
💬 评论