📚 课程目录第2章车载软件架构基础

2. 车载软件架构基础

车载中间件并不是孤立存在的软件层，它必须“嵌入”在整车电子电气架构与操作系统之间。理解 AUTOSAR Classic、AUTOSAR Adaptive、SOA、POSIX 与 Hypervisor 这几类架构概念，以及中间件在其中的位置与交互关系，是后续讨论性能与可靠性的前提。本节从分层视角出发，梳理这些架构的定位、边界与协作方式。

一、核心原理：从“分层”到“分域”的架构观

现代车载软件通常可以抽象为五层：硬件与芯片、Hypervisor/OS、运行时与中间件、应用框架、应用功能。不同架构标准在这五层中占据不同位置：

AUTOSAR Classic Platform（CP）：面向深嵌入式、硬实时控制场景，如发动机、制动、车身控制。其核心是 RTE（Runtime Environment）与 BSW（基础软件），中间件能力主要体现在 COM、PduR、CanIf 等通信栈与诊断、存储服务中。
AUTOSAR Adaptive Platform（AP）：面向高性能计算、动态部署、SOA 服务化场景，如自动驾驶域控、座舱域控。其核心是 ARA（AUTOSAR Runtime for Adaptive Applications），中间件以 ara::com、ara::exec、ara::per 等形式提供面向服务的通信与执行管理。
SOA（面向服务架构）：不是某一层软件，而是一种设计范式。服务提供者与消费者通过服务接口解耦，中间件负责服务发现、序列化、传输与生命周期管理。
POSIX：为 Adaptive 应用提供类 Unix 的进程、线程、文件、信号、时钟等抽象，是 AP 应用可移植性的基础。
Hypervisor：在硬件之上划分多个虚拟机（VM），让 Classic、Adaptive、Linux、QNX 等不同 OS 共存于同一 SoC，实现安全隔离与资源分区。

关键理解：Classic 与 Adaptive 不是替代关系，而是“实时控制”与“高性能服务”的互补关系；Hypervisor 则是让二者在同一芯片上安全共存的“底座”。

二、中间件在架构中的位置与交互关系

中间件位于 OS 与应用之间，向上提供统一通信、调度、诊断、存储、安全等能力，向下屏蔽 OS 与硬件差异。在 Classic 中，中间件能力由 BSW 与 RTE 共同承担；在 Adaptive 中，中间件由 ARA 与通信守护进程承担。下图给出一个典型的“Hypervisor + 双平台”架构，展示中间件所处的位置与主要交互路径。

从图中可以看到，中间件在 Classic 侧以 RTE+BSW 形式存在，在 Adaptive 侧以 ARA 形式存在，两者通过 SOME/IP 或 DDS 等协议跨 VM 通信。Hypervisor 负责把实时核与高性能核隔离，避免非实时任务干扰控制回路。

三、方法流程：从需求到架构选型的判断路径

面对一个具体功能，如何判断它应落在 Classic、Adaptive 还是两者协作？可参考以下流程：

实时性要求：周期小于 1ms、抖动要求微秒级 → 优先 Classic；周期 10ms 以上、允许动态调度 → 可考虑 Adaptive。
功能安全等级：ASIL C/D 且逻辑简单 → Classic 更成熟；ASIL B 以下且算法复杂 → Adaptive 更灵活。
通信模式：信号级、固定周期、CAN/LIN → Classic；服务级、请求响应、以太网 → Adaptive + SOA。
部署与更新：静态编译、刷写升级 → Classic；动态部署、OTA 增量更新 → Adaptive。
资源需求：小内存 MCU → Classic；大算力 SoC → Adaptive + Hypervisor。

实践建议：不要试图用一套架构覆盖所有域。常见做法是“实时控制用 Classic，智能服务用 Adaptive，Hypervisor 做隔离”，中间件负责把两侧的数据流打通。

四、案例与场景：域控制器中的协作

以智能驾驶域控制器为例：前向雷达与摄像头数据由 Adaptive 侧的感知应用处理，输出目标列表；规划模块计算轨迹后，通过 SOME/IP 服务调用发送给 Classic 侧的底盘控制 SWC，由后者以 1ms 周期驱动制动与转向执行器。中间件在此过程中承担三件事：

服务发现：Adaptive 侧 ara::com 发布“轨迹服务”，Classic 侧通过服务代理订阅。
序列化与传输：SOME/IP 将结构体序列化为以太网帧，经 Hypervisor 虚拟交换机转发。
超时与降级：若服务在 20ms 内未响应，Classic 侧触发安全降级，切换至默认轨迹。

下表对比两类平台在中间件层面的关键差异：

对比维度	AUTOSAR Classic	AUTOSAR Adaptive
调度方式	静态配置、时间触发	动态调度、事件触发
通信中间件	COM / PduR / CanIf	ara::com（SOME/IP、DDS）
OS 抽象	OSEK/VDX	POSIX PSE51
部署单元	SWC + RTE	Adaptive Application + 进程
典型芯片	MCU（TC3xx、RH850）	SoC（Orin、8155）
更新方式	整包刷写	OTA 增量更新

五、误区与复盘

常见误区一：认为 Adaptive 会完全取代 Classic。实际上安全气囊、制动等硬实时回路仍长期依赖 Classic，二者是分工而非替代。

常见误区二：把 SOA 等同于“上以太网”。SOA 的核心是服务接口与生命周期管理，即使底层仍是 CAN，也可以通过服务化封装实现解耦。

常见误区三：忽视 Hypervisor 的资源开销。虚拟化会引入上下文切换与内存隔离成本，若分区配置不当，反而会恶化实时性。

复盘要点：架构选型应回到“实时性、安全等级、通信模式、更新方式、资源预算”五个维度，中间件的位置决定了它必须同时理解上层服务语义与下层 OS 约束。只有把 Classic、Adaptive、SOA、POSIX、Hypervisor 放在同一张分层图中看待，才能准确判断性能瓶颈与可靠性风险究竟出在哪一层。

典型跨域服务调用链（简化）：
Adaptive 感知进程
  → ara::com 发布 /perception/objects
  → SOME/IP 序列化
  → Hypervisor 虚拟交换机
  → Classic COM 接收
  → RTE 映射到底盘 SWC
  → 1ms 周期执行器输出