3. 系统架构设计：从需求到实现的桥梁
系统架构设计，说白了就是把上一阶段定义的系统需求，拆解成一个个可实现的模块。我经常跟团队讲，这一步要是走歪了，后面代码写得再漂亮也白搭。
3.1 架构设计的目标：分解与分配
架构设计的核心目标就两个词：分解和分配。
- 功能分解：把整车级功能拆成子系统功能。比如“自动紧急制动”，拆成感知、决策、执行三个子系统。
- 技术分配：把功能分配给具体的硬件和软件。哪个跑在MCU上，哪个跑在SoC上，哪个用AUTOSAR SWC实现。
关键原则：分解要彻底，分配要明确。每个功能最终都要落到一个具体的“责任人”（硬件或软件组件）。
我在项目中遇到过最典型的问题：需求分解到第三层就乱了，有些功能没人认领，有些功能多个模块都在做。嗯，这就是典型的“分解不彻底，分配不清晰”。
3.2 架构设计原则：高内聚低耦合与模块化
这两个原则，我建议你刻在工位上。
高内聚低耦合
说白了就是：内部拧成一股绳，对外只留一个接口。
- 高内聚：一个模块只做一件事，并且把它做好。比如“车速计算模块”只负责算车速，别掺和转向控制。
- 低耦合：模块之间通过定义好的接口通信，别直接访问对方的内部变量。
我的经验：判断耦合度有个土办法——改一个模块的代码，需要改几个其他模块？超过2个，耦合就高了。
模块化
模块化是架构设计的落地手段。每个模块要有清晰的边界、明确的职责、标准的接口。
| 模块化要素 | 说明 | 反面案例 |
|---|---|---|
| 边界清晰 | 模块范围不重叠 | 两个模块都管“车门状态” |
| 职责单一 | 一个模块只做一类事 | “通用处理模块”啥都干 |
| 接口标准 | 使用AUTOSAR RTE或DDS | 自定义私有协议满天飞 |
3.3 常用架构模式
你想想看，汽车电子发展了这么多年，沉淀下来几种成熟的架构模式。我重点讲两个：
分层架构
这是最经典的架构模式。从上到下分三层：
- 应用层：业务逻辑，比如ACC、LKA这些功能算法。
- 中间件层：通信、诊断、网络管理。AUTOSAR RTE就是典型。
- 基础软件层：MCAL、OS、Bootloader。
分层的好处是：上层不关心底层怎么实现。我换一个MCU，只要中间件接口不变，应用层代码一行都不用改。
微服务架构在域控中的应用
这个比较新，但在域控制器上越来越流行。把每个功能做成独立的“服务”，通过轻量级通信协议（比如DDS）互相调用。
注意：微服务不是银弹。我曾经在一个项目里过度拆分，结果服务间通信开销占了30%的CPU。域控上资源有限，别为了“时髦”而滥用。
什么时候用微服务？我建议满足以下条件再考虑：
- 功能之间确实需要独立部署和升级
- 有足够的硬件资源（多核SoC）
- 团队有能力管理分布式系统的复杂度
3.4 架构设计工具
工具选对了，事半功倍。我主要用这两个：
PREEvision
Vector家的老牌工具。适合做整车级架构，从需求到线束都能覆盖。优点是一站式，缺点是贵、学习曲线陡。
SystemWeaver
SystemWeaver更灵活，适合做系统级和软件级架构。我比较喜欢它的元模型定制能力，可以按项目需要定义自己的数据模型。
| 对比项 | PREEvision | SystemWeaver |
|---|---|---|
| 适用阶段 | 整车架构 | 系统/软件架构 |
| 定制性 | 低（固定流程） | 高（可定义元模型） |
| 团队规模 | 大团队（50人+） | 中小团队 |
| 学习成本 | 高 | 中 |
我的建议：如果公司已经有PREEvision的license，就用它。如果从零开始，SystemWeaver更灵活，也更容易上手。
3.5 架构设计核心逻辑
下面这张图，是我自己总结的架构设计核心逻辑。每次做新项目，我都会先画一遍这个图。
这张图的核心逻辑是：从需求出发，逐层分解，最终落到硬件和软件上，再通过接口定义把它们串起来。每一步都离不开高内聚低耦合和模块化这两个原则。
总结一下：系统架构设计不是画几张框图就完事了。它需要你真正理解需求、懂得分解、会分配、能选型。我见过太多项目，架构图画得漂漂亮亮，一到实现就漏洞百出。为什么？因为分解没做透，分配没想清楚。
嗯，这一章的内容就到这里。记住：架构设计是技术活，更是思考活。多问自己几个“为什么”，比多画几张图更有用。