# 车载电子电气(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 最顺;但对车厂软件能力要求极高,单点失效防护(冗余)必须做足。 - **取向**:行业整体向中央集中演进,**但节奏取决于组织的软件能力**——架构领先于能力 = 灾难([组织即架构](../../tutorial/15-组织即架构.md) 在汽车业的体现:供应链关系就是旧架构的形状)。 **决策 2:安全域和娱乐域怎么隔离?⭐** - 物理隔离(各自芯片):最硬的边界,认证简单;成本高、跨域通信慢。 - 单芯片虚拟化(Hypervisor 分区):省钱省空间;但要证明「娱乐崩了绝不影响仪表」,认证成本极高。 - **取向**:**关键显示(仪表)倾向独立小系统兜底,大算力域间用虚拟化**。原则不变:**QM 级软件的任何行为,都不得影响 ASIL 级软件的资源和时序**。 **决策 3:OTA 全量推,还是差分 + 灰度?** - 全量包:简单可靠,但一次整车升级几个 GB,蜂窝流量成本 × 百万辆。 - 差分包 + 分批灰度:省 90% 流量,先推千辆观察再放量;代价是版本组合矩阵管理复杂。 - **取向**:差分 + 灰度 + 失败率熔断是量产标配,同 [IoT 平台](../iot-platform/README.md) 的 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 营销活动)。 - 💡 **两种流量两张网**:大带宽走高吞吐链路,小而关键走确定性链路——「控制面与数据面分离」的物理版。 - 💡 **影子模式 = 用真实流量免费验证新版本**:先旁观、比差异、再放权,任何高风险替换(风控模型、推荐算法)都适用。 - 💡 **失败要有「安全状态」可去**:跛行回家模式的思想——系统降级后停在哪,是设计出来的,不是碰运气([为失败而设计](../../tutorial/12-为失败而设计.md))。 - 💡 **软硬解耦 + 配置激活**:一套软件伺候 N 种硬件配置,SKU 管理的终极答案(同 [嵌入式固件](../embedded-device/README.md) 决策 4)。 ## 🎯 随堂检验 --- ## 参考原型与延伸阅读 > 本模板基于以下**真实开源项目**与**行业标准**整理。 **🔧 开源原型(可直接读代码):** - [commaai/openpilot](https://github.com/commaai/openpilot) — 开源辅助驾驶系统,跑在真车上:感知→规划→控制闭环、通过 CAN 与整车交互、安全监控独立进程,是普通工程师读得到的最真实车载软件。 **📖 行业标准 / 框架:** - [AUTOSAR 官网](https://www.autosar.org/) — 汽车软件架构的行业标准组织:Classic(安全实时域)与 Adaptive(高算力域)两套平台,正对应本模板「两种价值观的软件」。 - [Uptane 官网](https://uptane.org/) — 汽车 OTA 安全更新的开放框架(多级签名、防降级、部分失陷仍安全),对应第 6 节场景二与第 10 节。 --- > 📌 一句话记住车载 E/E:**一辆车里住着两种软件——「稳如磐石」的安全件和「迭代如飞」的体验件,全部架构功力都花在让它们同居而互不伤害:分级隔离、两张网、受控 OTA。所有设计都在回答:『娱乐怎么疯,刹车都不受影响。』**