4. 车载软件分类与分层

在软件定义汽车（SDV）的架构中，车载软件不再是“一个程序跑在一个ECU上”的简单形态，而是由多个层次、多种职责的软件共同构成的复杂系统。理解这些软件的分类与分层，是进行架构设计、接口定义、团队分工和平台选型的前提。本节将车载软件划分为基础软件、中间件、功能软件、应用软件和算法软件五个层次，并说明AUTOSAR CP与AP在其中的角色定位。

一、五层软件栈的核心职责

从最贴近硬件到最贴近用户，车载软件可以抽象为一条纵向的软件栈。每一层解决不同的问题，层与层之间通过标准化接口解耦，从而实现软硬件分离和软件的可复用、可升级。

• 基础软件（Basic Software, BSW）：直接管理MCU/SoC的硬件资源，包括启动引导、驱动、操作系统内核、通信协议栈、诊断、存储、电源管理等。它屏蔽硬件差异，向上提供统一的服务接口。
• 中间件（Middleware）：位于基础软件与上层业务之间，提供进程间通信、服务发现、数据分发、时间同步、日志、健康管理等通用能力。它是分布式软件组件能够“互相找到并通信”的关键。
• 功能软件（Functional Software）：实现车辆级或域级的功能逻辑，如车身控制、能量管理、驾驶模式仲裁、故障降级策略等。它通常不直接处理传感器原始数据，而是编排和协调多个应用与算法。
• 应用软件（Application Software）：面向具体用户可见功能或场景，如车窗控制、空调调节、导航、语音交互、OTA客户端等。它关注业务逻辑和用户体验。
• 算法软件（Algorithm Software）：承载感知、融合、定位、规划、控制、诊断预测等计算密集型或模型驱动型逻辑，通常以库、模型或独立进程形式存在，被功能软件或应用软件调用。

需要强调的是，这五层并非严格的“上下级调用”关系，而是职责分层。算法软件可能被功能软件调用，也可能直接通过中间件订阅数据；应用软件也可能直接使用基础软件提供的诊断接口。分层的目的是明确边界，而不是制造壁垒。

二、AUTOSAR CP与AP的角色差异

AUTOSAR Classic Platform（CP）和Adaptive Platform（AP）是AUTOSAR标准针对不同计算场景提出的两套平台规范。它们并不是简单的“新旧替代”，而是面向不同确定性、算力和通信需求的互补方案。

对比维度	AUTOSAR CP	AUTOSAR AP
典型硬件	MCU，资源受限，单核或锁步核	高性能SoC，多核，带MMU，支持POSIX
操作系统	OSEK/VDX OS，静态任务调度	POSIX PSE51，动态进程与线程
通信模型	信号导向，CAN/LIN/FlexRay/Ethernet	服务导向，SOME/IP、DDS、IPC
软件更新	整体刷写，通常需停机	支持增量、动态更新与进程重启
典型软件层	基础软件 + 功能软件 + 少量应用	中间件 + 功能软件 + 应用 + 算法
确定性	强实时、高确定性	软实时、面向高吞吐与灵活部署

在SDV架构中，CP通常负责车身、底盘、动力等对实时性和安全等级要求高的控制节点；AP则部署在中央计算平台或域控制器上，承载智能座舱、自动驾驶、OTA、车云协同等需要高算力和灵活迭代的业务。两者通过车载以太网和网关进行跨平台通信。

三、分层视角下的数据流与调用关系

为了更直观地理解五层软件与AUTOSAR平台之间的关系，下面用一张结构关系图展示从硬件到应用的纵向分层，以及CP与AP在其中的覆盖范围。

从图中可以看出，CP的覆盖范围集中在基础软件和功能软件，强调对硬件的直接管理和强实时控制；AP则从中间件向上覆盖到应用和算法，强调服务化、动态性和高算力。两者在功能软件层存在交叠，实际项目中需要根据具体功能的实时性、安全等级和算力需求选择部署平台。

四、典型场景：一次自动泊车功能的软件分层落地

以自动泊车功能为例，可以清晰看到五层软件如何协同工作：

1. 算法软件：超声波/视觉感知算法输出车位检测结果，路径规划算法生成泊车轨迹，控制算法计算方向盘转角和车速指令。
2. 功能软件：泊车功能状态机管理“搜索车位—确认—泊入—完成”的流程，仲裁驾驶员接管请求，处理故障降级。
3. 应用软件：向用户展示泊车界面、接收用户确认、提供语音提示和OTA升级入口。
4. 中间件：通过SOME/IP或DDS在感知、规划、控制、人机交互进程之间传递数据，保证时间同步和通信可靠性。
5. 基础软件：在CP侧驱动超声波传感器、EPS电机和制动执行器；在AP侧管理SoC的摄像头输入、GPU推理和进程调度。

五、常见误区与复盘

在实际架构工作中，关于软件分层和AUTOSAR平台角色，常见以下误区：

• 误区一：把AP当作CP的升级版。AP并非CP的替代品，二者面向不同场景。CP的强实时和安全机制在底盘、动力领域仍不可替代；AP更适合高算力、非强实时、需要频繁迭代的业务。
• 误区二：认为中间件只是“通信库”。AP中间件还承担服务发现、生命周期管理、安全通信、资源监控等职责，是服务化架构的运行时基础。
• 误区三：算法软件必须独立成层。算法软件可以以库、模型或独立进程形式存在，其部署位置取决于算力、实时性和复用需求，不必强行独立为一个物理层。
• 误区四：功能软件和应用软件边界模糊。功能软件关注车辆级功能逻辑和状态仲裁，应用软件关注用户交互和业务场景。边界清晰才能避免功能逻辑散落在多个应用中。

复盘来看，分层的目的不是画出一张漂亮的架构图，而是让每一层有明确的职责、接口和演进节奏。基础软件追求稳定和标准化，中间件追求通用和可替换，功能软件追求车辆级逻辑的集中管理，应用软件追求快速迭代，算法软件追求精度和性能。只有各层各司其职，SDV的软件架构才能支撑持续OTA和功能创新。

分层设计检查清单：
[ ] 基础软件是否屏蔽了硬件差异，向上提供稳定接口？
[ ] 中间件是否支持服务发现、时间同步和跨平台通信？
[ ] 功能软件是否集中管理车辆级状态和降级策略？
[ ] 应用软件是否与具体硬件解耦，可独立升级？
[ ] 算法软件是否有明确的输入输出契约和性能指标？
[ ] CP与AP的边界是否根据实时性、安全等级和算力确定？
[ ] 跨CP/AP通信是否有明确的时延预算和安全校验？