4. 车载软件架构
车载软件架构是SDV（软件定义汽车）车云协同平台的“地基”。如果把一辆智能汽车比作一座城市，那么AUTOSAR Classic负责控制交通信号灯、刹车、发动机等实时性极高的“市政设施”，AUTOSAR Adaptive则负责处理自动驾驶、车联网、OTA等需要大算力与灵活通信的“商业中心”，而Hypervisor与车载操作系统则像城市的分区规划与土地管理，让不同安全等级、不同操作系统的软件在同一硬件上互不干扰地运行。理解这四者之间的关系，是掌握车云协同软件平台工程的第一步。
一、核心原理：从Classic到Adaptive的分层协作
AUTOSAR Classic Platform（CP）面向深嵌入式实时控制，采用静态配置、OSEK/VDX操作系统、RTE（运行时环境）与BSW（基础软件）分层结构。它的软件组件（SWC）通过端口与RTE连接，通信以CAN、LIN、FlexRay等信号为主，强调确定性、可预测性和功能安全（ISO 26262 ASIL-D）。典型应用包括发动机控制、车身控制、制动系统等。
AUTOSAR Adaptive Platform（AP）面向高性能计算与动态服务，采用POSIX操作系统（如Linux、QNX）、C++14/17、面向服务的通信（SOME/IP、DDS），支持动态加载、OTA升级和SOA架构。AP的软件组件称为Adaptive Application，通过ara::com进行服务发现与调用，强调灵活性、可扩展性和高算力。
SOA（面向服务的架构）是AP的核心思想：将功能封装为可被远程调用的服务，服务提供者与消费者通过服务接口解耦。例如，一个“车窗控制服务”可以被座舱域、车身域甚至云端同时调用，而不需要知道对方的具体实现。这种松耦合、可复用的特性，正是车云协同的基础。
二、Hypervisor与车载操作系统：一芯多屏的隔离术
随着域集中式与中央计算架构的普及，一颗SoC上需要同时运行仪表、座舱、ADAS、网关等多个系统。Hypervisor（虚拟机管理器）通过硬件虚拟化技术，将物理资源划分为多个虚拟机（VM），每个VM运行独立的操作系统。Type 1 Hypervisor直接运行在硬件上，性能损耗小，是车载主流方案（如QNX Hypervisor、COQOS、ACRN）。
车载操作系统分为三类：实时操作系统（RTOS，如OSEK、FreeRTOS、QNX）、通用操作系统（Linux、Android）和混合关键性系统。中间件则位于操作系统与应用之间，提供通信、诊断、持久化、时间同步等公共服务。AUTOSAR AP的ara::com、SOME/IP、DDS、Iceoryx等，都是典型的车载中间件。
三、方法流程：从需求到架构落地的关键步骤
- 需求分类：将功能按实时性、安全等级、算力需求分为硬实时控制类、高性能计算类、通信服务类。
- 平台选型：硬实时控制类部署到Classic CP；自动驾驶、座舱、车云通信部署到Adaptive AP。
- 虚拟化规划：确定哪些OS需要隔离，划分VM资源（CPU核、内存、外设直通）。
- 服务设计：基于SOA定义服务接口、服务发现机制、QoS策略（延迟、可靠性）。
- 中间件配置：配置SOME/IP或DDS的序列化、传输协议、安全策略。
- 集成验证：在HIL台架与实车上验证跨VM、跨平台的通信时延与功能安全。
四、案例场景：中央计算平台上的多系统协作
某车企的中央计算平台采用一颗高性能SoC，通过Type 1 Hypervisor运行四个VM：VM1运行QNX RTOS负责仪表与实时控制，VM2运行Android负责座舱娱乐，VM3运行Linux负责ADAS感知与规划，VM4运行AUTOSAR Adaptive负责车云通信与OTA。四个VM通过共享内存与虚拟网络通信，中间件采用SOME/IP进行服务调用。当云端下发“开启空调”指令时，VM4的Adaptive应用通过服务发现调用VM2的座舱服务，VM2再通过CAN网关将控制信号转发给Classic CP的车身控制器。整个链路涉及SOA服务调用、Hypervisor隔离、跨OS通信与Classic/Adaptive协同。
五、误区与复盘
常见误区：认为Adaptive会完全取代Classic。实际上，Classic在硬实时、功能安全、成本敏感的场景中仍不可替代；Adaptive更适合高算力、动态服务、OTA场景。两者是互补关系，而非替代关系。
复盘要点：架构设计时，先明确“哪些功能必须硬实时、哪些可以软实时”，再决定平台划分。Hypervisor的隔离粒度、SOA的服务粒度、中间件的QoS策略，都会直接影响系统性能与安全。建议在早期用架构仿真工具验证跨VM通信时延，避免后期返工。
六、关键参数与工具清单
| 类别 | 典型对象 | 关键参数/指标 | 常用工具 |
|---|---|---|---|
| AUTOSAR Classic | RTE、BSW、OSEK OS | 任务周期、抖动、ASIL等级 | DaVinci Configurator、EB tresos |
| AUTOSAR Adaptive | ara::com、SOME/IP、DDS | 服务发现时延、QoS、吞吐量 | Vector MICROSAR Adaptive |
| Hypervisor | Type 1 Hypervisor、VM | CPU核分配、内存隔离、中断延迟 | QNX Hypervisor、ACRN |
| 车载OS | QNX、Linux、Android | 实时性、启动时间、安全认证 | Yocto、Buildroot |
| 中间件 | SOME/IP、DDS、Iceoryx | 序列化开销、传输协议、安全策略 | vsomeip、Fast DDS |
# 示例：Adaptive Platform 服务接口定义（ara::com 伪代码）
service WindowControl {
method void open(uint8 percentage);
method void close();
event WindowStatus status;
}
# 服务发现配置（SOME/IP）
service_id = 0x1234
instance_id = 0x0001
protocol = SOME/IP
qos = { latency: 10ms, reliability: reliable }掌握Classic与Adaptive的分工、SOA的服务化思想、Hypervisor的隔离机制以及车载OS与中间件的选型方法，是构建车云协同软件平台的核心能力。在实际工程中，架构决策需要兼顾实时性、安全性、成本与可扩展性，并通过仿真与实测持续验证。