1. 课程导入
现代汽车早已不是“四个轮子加沙发”的机械产品，而是一台装有上百个电子控制单元（ECU）、运行数千万行代码、通过多种车载网络协同工作的移动计算平台。支撑这些电子系统有序协作的整体设计，就是汽车电子/电气架构（Electrical/Electronic Architecture，简称E/E架构）。它规定了整车电子系统的功能分配、软硬件部署、通信网络拓扑、电源与接地、线束布置以及诊断与安全机制，是整车电子工程的“总蓝图”。
一、E/E架构的定义与核心组成
E/E架构可以从“功能—逻辑—物理”三个层次理解。功能层描述整车要实现的功能（如自动紧急制动、远程解锁）；逻辑层描述功能如何分配到各个ECU与软件组件，以及它们之间的信号与数据交互；物理层则描述ECU安装位置、线束走向、连接器、网络拓扑与供电回路。三者相互约束，任何一层的变更都可能牵动全局。
从工程对象看，E/E架构通常包含以下核心要素：
- 电子控制单元（ECU）：执行具体控制逻辑的计算节点，如发动机控制器、车身控制器、域控制器。
- 车载网络：CAN、CAN FD、LIN、FlexRay、Automotive Ethernet等，承担节点间通信。
- 电源与接地系统：12V/48V供电、保险丝、继电器、搭铁点，是电子系统可靠工作的基础。
- 线束与连接器：整车最重、最贵的“硬件之一”，直接影响装配、重量与故障率。
- 诊断与刷写接口：OBD-II、UDS、DoIP、OTA通道，用于故障读取、标定与软件升级。
- 安全机制：功能安全（ISO 26262）、信息安全（ISO/SAE 21434）、网络管理与休眠唤醒策略。
二、发展历程：从分布式到集中式
汽车E/E架构的演进，本质上是“功能增加”与“复杂度控制”之间的博弈。早期车辆采用纯分布式架构，每个功能对应一个独立ECU，通过CAN总线互联。这种架构开发灵活，但线束长、节点多、协同困难。随着智能座舱、ADAS、车联网的兴起，架构逐步走向域集中式：按动力、底盘、车身、座舱、智驾等域设置域控制器，域内集成多个功能，域间通过高速骨干网通信。当前行业正加速向中央计算+区域控制演进：中央计算平台负责全局算力与逻辑，区域控制器就近管理传感器与执行器，进一步减少线束、提升软件迭代效率。
架构演进主线：分布式ECU → 功能域集中 → 跨域融合 → 中央计算+区域控制。每一次演进都伴随着通信带宽提升、软件复杂度上升，以及安全与诊断要求的同步升级。
三、安全与诊断工程为什么重要
架构越集中，软件与网络承担的功能越多，失效的影响面也越大。安全工程关注“系统在故障时是否仍能保持可接受的安全状态”，诊断工程关注“系统能否被观测、被定位、被修复、被升级”。两者共同构成E/E架构可运维、可信任的基础。
具体而言，安全与诊断工程的价值体现在以下场景：
- 功能安全：制动、转向、动力等关键系统需要满足ASIL等级要求，具备故障检测、降级运行与安全状态切换能力。
- 信息安全：防止非法刷写、报文伪造、远程攻击，保护车辆控制权与用户隐私。
- 诊断与售后：通过UDS服务读取DTC、执行例程、刷写软件，缩短维修时间，降低误换件率。
- OTA与全生命周期管理：支持远程升级、版本回滚、升级失败恢复，是智能汽车持续迭代的前提。
学习提示：安全与诊断不是“附加功能”，而是架构设计阶段就必须纳入的约束条件。后期补安全、补诊断，成本往往成倍增加。
四、核心原理：架构、安全与诊断的三角关系
E/E架构、安全工程与诊断工程三者相互支撑。架构决定安全机制与诊断通道的部署位置；安全需求反过来约束架构的冗余、隔离与监控设计；诊断则是验证安全机制是否有效、定位故障根因的手段。可以用下面的关系图理解三者的耦合关系。
五、方法流程：从需求到验证的闭环
在工程实践中，E/E架构的安全与诊断设计通常遵循一条闭环流程。理解这条流程，有助于把后续章节的知识点串成体系。
- 需求分析：从整车功能出发，识别安全目标、诊断需求与法规要求。
- 架构设计：分配ECU、网络、电源与诊断接口，确定冗余与隔离策略。
- 安全与诊断机制设计：定义DTC、监控策略、安全状态、刷写流程与访问控制。
- 实现与集成：完成软件配置、网络通信矩阵、诊断数据库（CDD/ODX）与刷写脚本。
- 测试与验证：通过HIL、台架与实车测试，验证故障注入、诊断响应与安全降级。
- 运维与迭代：通过OTA与售后诊断持续收集数据，反哺架构优化。
六、案例场景：一次远程升级失败带来的启示
某车型通过OTA升级座舱域控制器，升级过程中因电源波动导致写入中断，车辆重启后座舱黑屏。若架构设计阶段已考虑双分区备份、升级失败回滚与电源保持策略，该问题可在后台自动恢复；若诊断工程未定义升级状态DTC与恢复例程，售后只能更换硬件。这个案例说明：安全机制决定系统“扛不扛得住”，诊断能力决定系统“能不能被救回来”，两者都必须在架构层面提前规划。
常见误区：把诊断简单等同于“读故障码”；把安全等同于“加个加密芯片”。真正的安全与诊断工程需要覆盖需求、设计、实现、测试、运维全链路，并与E/E架构同步演进。
七、学习目标与课程框架
本课程围绕“架构—安全—诊断”三条主线展开，共30章。学习完成后，你应能够：
- 描述E/E架构的分层模型、典型拓扑与演进趋势；
- 解释功能安全与信息安全的核心概念、标准与工程落地方法；
- 掌握CAN/LIN/Ethernet等车载网络的诊断协议与刷写流程；
- 设计DTC、诊断服务、安全访问与OTA升级方案；
- 使用诊断工具与测试方法定位典型E/E架构故障。
| 模块 | 主要内容 | 典型产出 |
|---|---|---|
| 架构基础 | E/E架构定义、拓扑、域控与区域控制、线束与电源 | 架构框图、通信矩阵 |
| 安全工程 | ISO 26262、ISO/SAE 21434、安全机制与降级策略 | 安全概念、TARA分析 |
| 诊断工程 | UDS、DTC、OBD-II、DoIP、刷写与OTA | 诊断规范、CDD/ODX |
| 测试与运维 | HIL测试、故障注入、售后诊断、数据闭环 | 测试报告、诊断脚本 |
典型诊断请求示例（UDS over CAN）：
请求： 02 10 03 // 进入扩展会话
响应： 06 50 03 00 32 01 F4
请求： 03 22 F1 90 // 读取VIN
响应： 62 F1 90 4C 53 56 43 31 32 33 34 35 36 37 38 39 30
说明： 10=会话控制，22=按标识符读数据，F190=VIN数据标识符