2、车载电子电气架构：从分布式到SOA
做车载测试这些年，我最大的感受就是——架构变了，测试的玩法也跟着变了。
早期我们测一个雨刮控制器，单独测就行。现在呢？一个功能可能要跨三四个域控制器，还要跟云端打交道。你想想看，如果不搞清楚架构，测试用例根本写不透。
这一章，我就带你把这四种架构捋一遍。尤其是面试时，面试官最爱问的就是：“你们现在的车用的是什么架构？SOA落地了吗？”
2.1 分布式架构：每个功能一个“小黑盒”
这是最传统的架构。每个功能对应一个独立的ECU（电子控制单元）。
比如车窗控制一个ECU，雨刮一个ECU，门锁一个ECU。它们之间通过CAN/LIN总线通信。
核心特点：
- 功能与硬件强绑定——一个ECU坏了，这个功能就没了
- 通信靠信号——一个ECU发一个CAN信号，另一个ECU接收
- 软件升级困难——每个ECU单独刷写，OTA基本不可能
我在2018年测过一个项目，全车有40多个ECU。光是整理CAN信号矩阵就花了两周。最头疼的是，改一个功能可能要动三四个ECU的软件，联调效率极低。
测试避坑：
我曾经遇到过一个问题：两个ECU同时发同一个CAN信号，导致总线冲突。后来我们加了一条规则——每个信号只能有一个发送节点。但分布式架构下，这种“信号打架”的问题很常见。测试时一定要检查信号矩阵的发送方唯一性。
2.2 域集中式架构：把功能“收编”到几个域里
为了解决分布式架构的痛点，行业开始把功能相近的ECU合并到一个“域控制器”里。
常见的域有：
| 域名称 | 包含功能 | 典型芯片 |
|---|---|---|
| 动力域 | 发动机、变速箱、电池管理 | Infineon TC3xx |
| 底盘域 | 制动、转向、悬架 | NXP S32K |
| 车身域 | 车窗、门锁、灯光、雨刮 | TI TDA4 |
| 智能座舱域 | 仪表、中控、HUD、语音 | 高通SA8155 |
| 智驾域 | 摄像头、雷达、规划控制 | 英伟达Orin |
说白了，域集中就是把原来分散的ECU，按功能域“打包”到几个高性能控制器里。域内通信走高速总线（如CAN FD、以太网），域间通信走网关。
注意：域集中架构下，网关成了关键节点。我测过一个项目，网关转发延迟超标，导致智驾域发来的制动指令晚了200ms。200ms在高速上就是十几米。所以测试时，网关的延迟和吞吐量必须重点测。
2.3 中央计算平台架构：一个“大脑”管所有
域集中还不够极致。现在的高端车型开始用中央计算平台。
一个或两个超级芯片（如英伟达Thor、高通Snapdragon Ride Flex），接管所有域的功能。原来的域控制器变成了“区域控制器”，只负责IO采集和执行。
架构变化：
- 中央计算平台：运行所有应用软件，做决策
- 区域控制器：采集传感器信号，执行指令
- 通信：全部走车载以太网，带宽可达10Gbps
我个人习惯把这种架构叫做“手机模式”。你想想看，手机一个SoC搞定所有——通信、拍照、游戏、支付。车也一样，一个中央大脑搞定智驾、座舱、车身控制。
测试上，中央计算平台最大的挑战是资源隔离。智驾功能要实时性，座舱功能要流畅性，它们跑在同一个芯片上，怎么保证不互相干扰？
测试要点：
我曾经测过一个中央计算平台的项目，智驾模块占用了太多CPU资源，导致座舱的仪表刷新率掉到15fps。后来我们加了CPU分区和优先级调度。测试时一定要做资源争抢场景——比如同时开导航、播放视频、开启自适应巡航，看系统会不会卡顿或延迟。
2.4 SOA架构：把功能变成“服务”
SOA（面向服务的架构）不是硬件架构，而是软件架构。但它跟硬件架构强相关——只有中央计算平台或高性能域控，才能跑得起SOA。
SOA的核心思想：把功能拆成独立的服务，服务之间通过标准接口（如SOME/IP、DDS）通信。
举个例子：
- 传统架构：按一下车窗按钮 → CAN信号 → 车窗ECU → 电机动作
- SOA架构：车窗控制服务发布接口“setWindowPosition(0.5)” → 任何服务都可以调用它 → 车窗电机动作
SOA的关键特性：
- 服务化：每个功能是一个独立服务，可单独开发、部署、升级
- 松耦合：服务之间不依赖具体硬件，换硬件不影响上层服务
- 可发现：服务启动后自动注册，其他服务可以“发现”它
- 标准化接口：接口定义清晰，跨平台、跨语言调用
我测过的一个SOA项目，空调控制被拆成了三个服务：温度控制服务、风量控制服务、模式控制服务。每个服务独立测试，然后做集成测试。好处是——改一个服务不影响其他服务。坏处是——服务之间的调用链变长了，延迟问题更突出。
SOA测试的坑：
我曾经遇到一个场景：温度控制服务调用风量控制服务，风量控制服务又调用鼓风机驱动服务。三个服务之间的调用超时设置不一致，导致用户调节温度时，风量要等2秒才响应。测试时一定要画服务调用链图，检查每个环节的超时和重试机制。
2.5 四种架构对比
| 维度 | 分布式 | 域集中 | 中央计算 | SOA |
|---|---|---|---|---|
| ECU数量 | 30-50+ | 5-10个域控 | 1-2个中央+区域 | 同左 |
| 通信方式 | CAN/LIN | CAN FD + 以太网 | 车载以太网 | SOME/IP / DDS |
| 软件升级 | 难（逐个刷写） | 域内可OTA | 全车OTA | 服务级OTA |
| 功能耦合度 | 高 | 中 | 低 | 极低 |
| 测试复杂度 | 低（单ECU） | 中（域内集成） | 高（资源争抢） | 极高（服务编排） |
2.6 架构演进路线图
下面这张图，是我自己总结的架构演进路线。面试时画出来，能加分不少。
2.7 对测试的影响
架构变了，测试策略必须跟着变。我总结了几点：
- 分布式架构：重点测单个ECU的功能、CAN信号、诊断。测试工具：CANoe、PCAN。
- 域集中架构：重点测域内集成、域间通信、网关转发。测试工具：CANoe + 以太网卡。
- 中央计算平台：重点测资源争抢、任务调度、安全隔离。测试工具：Linux perf、Trace32。
- SOA架构：重点测服务接口、服务调用链、超时重试、服务发现。测试工具：vTESTstudio、Python + SOME/IP库。
我的建议：
面试时，如果被问到架构相关的问题，不要只背概念。结合你实际测过的项目讲。比如：“我测过一个域集中架构的项目，网关转发延迟超标，我们怎么定位的……” 这样比干巴巴讲定义强得多。