1. 课程导入
现代汽车早已不是“四个轮子加沙发”的机械产品，而是一台装有上百个电子控制单元（ECU）、数公里线束、数千万行代码的移动计算平台。支撑这些电子电气功能协同工作的“骨架与神经系统”，就是汽车电子/电气架构（E/E Architecture，Electrical/Electronic Architecture）。它定义了整车电子电气系统的功能分配、软硬件部署、通信网络、电源与接地、线束拓扑以及开发与验证规则。
一句话理解：E/E架构回答四个问题——功能由谁实现（ECU/域控制器/中央计算）、它们如何通信（CAN/LIN/FlexRay/以太网）、电从哪来（电源与接地）、以及如何被开发与验证（需求—设计—测试—追溯）。
一、E/E架构的核心构成
从工程视角看，E/E架构不是单一图纸，而是多视图模型的集合。功能视图描述整车功能与逻辑交互；网络视图描述总线、网关与信号路由；拓扑视图描述控制器、传感器、执行器的物理位置与线束连接；电源视图描述蓄电池、配电、接地与休眠唤醒策略；软件视图描述AUTOSAR分层、服务与诊断。MBSE（基于模型的系统工程）正是把这些分散视图统一为可追溯、可仿真、可验证的模型体系。
二、发展历程：从分布式到中央计算
汽车E/E架构的演进，本质是“功能增长”与“复杂度控制”之间的博弈。下表概括了四个典型阶段的特征与代表技术。
| 阶段 | 典型时期 | 架构特征 | 代表技术 | 主要痛点 |
|---|---|---|---|---|
| 分布式 | 1990s–2005 | 一个功能一个ECU，点对点线束 | CAN、LIN、独立控制器 | 线束重、ECU多、难以升级 |
| 集成化 | 2005–2015 | 网关集中、功能集成、域雏形 | CAN FD、FlexRay、网关 | 跨域协同弱、软件耦合高 |
| 域集中 | 2015–2022 | 按动力、底盘、座舱、智驾分域 | 域控制器、车载以太网、AUTOSAR | 域间壁垒、算力孤岛 |
| 中央计算+区域 | 2022至今 | 中央计算平台+区域控制器+SOA | 千兆以太网、SOA、OTA、TSN | 安全、实时、组织流程重构 |
三、MBSE在汽车行业的价值
传统开发中，需求写在文档里，设计画在CAD和网络图中，测试用例散落在Excel中，变更靠邮件传递。当整车功能超过数百项、信号超过数万条时，这种“文档驱动”方式极易产生不一致。MBSE以模型为唯一数据源，把需求、功能、逻辑、物理、测试串成一条可追溯链。
- 早期发现接口冲突：在内部块图中定义端口与流属性，仿真即可暴露信号类型不匹配、带宽不足等问题。
- 需求到测试的闭环：每条需求关联设计元素与测试用例，覆盖率可量化，变更影响可自动分析。
- 多车型变体复用：通过特征模型与配置管理，同一架构模型可派生不同配置，减少重复设计。
- 跨专业协同：系统、软件、硬件、测试使用统一语义，减少“各说各话”。
提示：MBSE不是“画更多图”，而是用模型替代文档作为工程决策的依据。图只是模型的视图，模型背后的语义、关系和约束才是核心资产。
四、学习路径与常见误区
本课程建议按“概念—语言—方法—工具—案例”的路径推进。先理解E/E架构与MBSE的基本概念，再掌握SysML建模语言，随后学习需求、功能、逻辑、物理、验证的建模流程，最后通过工具实操与整车案例贯通。
推荐学习路径：
1. 概念导入 → E/E架构定义、发展、MBSE价值
2. 语言基础 → SysML图类型、语义、建模规范
3. 方法流程 → 需求→功能→逻辑→物理→验证
4. 工具实操 → 建模工具、模型库、追溯矩阵
5. 案例贯通 → 域控制器、区域架构、SOA建模
6. 复盘优化 → 模型评审、度量、持续改进
常见误区：一是把MBSE等同于“画流程图”，忽视模型语义与追溯；二是先建工具再定方法，导致模型无法复用；三是只做设计模型，不关联需求与测试，失去闭环价值；四是追求大而全，忽视迭代与最小可用模型。建议从一条功能链、一个域控制器开始，小步验证、逐步扩展。
掌握E/E架构与MBSE，意味着你能够在功能爆炸与算力集中的时代，用结构化、可追溯、可验证的方式设计汽车的“神经系统”。接下来的章节将逐步展开建模语言、方法与工具，帮助你从概念走向工程实践。