TN-14 · 2026-09-12 · 测试工程系列 · 第 7 篇

Classic 与 Adaptive AUTOSAR：不是替代，是分工

汽车软件里有两个 AUTOSAR：Classic 和 Adaptive。常被问起的一个问题是”Adaptive 是不是 Classic 的换代”——不是。CP 管”控制”，AP 管”计算”：一个守车身底盘的确定性，一个扛智驾域控的算力。这篇把两个平台逐维度摆开，讲清它们在现代车上怎么共存，以及对测试工程师意味着什么。

一、逐维度对比

一句话画像：CP 是”编译期就把一辈子定死的劳模”——确定、可认证、不许惊喜；AP 是”上线后还能长身体的平台”——动态、可更新，代价是确定性让位。

二、现代车上怎么共存

E/E 架构里两边都在，甚至同一颗域控内共存：SoC 跑 Linux + AP 做感知规划，旁边挂一颗 MCU 跑 CP 当”安全岛”——AP 算出的规划指令，由 CP 侧做安全监控与兜底执行。两边之间靠网关做信号↔服务翻译（CAN ↔ SOME/IP）：

┌──────────────────── 域控制器 ────────────────────┐
│  SoC：Linux + AP —— 感知融合 / 规划 / OTA        │
│          │ 规划指令                              │
│          ▼                                       │
│  MCU：CP 安全岛（ASIL D）——                      │
│       安全监控 / 兜底执行                        │
└─────────┬────────────────────────────────────────┘
          │
      网关：信号 ↔ 服务（CAN ↔ SOME/IP）
          │
      车身 / 底盘 ECU 群（CP）

“AP 会不会取代 CP”是伪命题：只要车上还有刹车和转向要控制，CP 就在。两个平台的分工不是时间轴上的新旧替代，而是同一辆车上的空间分工——算力归 AP，确定性归 CP。

三、对测试工程师的含义

• 测 CP 的对象：总线信号激励与观测（CAN/LIN/FlexRay）、UDS 诊断、故障注入——传统 HIL 主战场；PIL 刚需也在这边（定点、TASKING 编译器）；
• 测 AP 的对象：服务接口（SOME/IP）、以太网流量、日志追踪、状态管理、OTA 流程；AP 应用大量先在 Linux 容器里做 SIL——AP 域控的 SIL 占比远高于 CP 时代，这直接改变了测试平台的形态：接入层从总线接口卡变成以太网和容器，纯软件仿真能覆盖的用例比例大幅上升；
• 两边通用：测试方法论（场景、判定、回归）在两边完全一致，变的只是接入层；
• 概念对应：CP 的 SWC ↔ AP 的 Adaptive Application；CP 的 RTE ↔ AP 的 ara::com。

CP 把确定性焊死在编译期，AP 把灵活性留到运行时——车上的分工由此而来：性命攸关的控制回路交给”不许惊喜”的 CP，吃算力的智能功能交给”能长身体”的 AP。测试工程师要做的不是选边，而是两套接入层都会，一套方法论通吃。

附：名词解释（按出场顺序）