AUTOSAR Adaptive vs Classic — 有何不同，如何共存

AUTOSAR，让我们来做一次梳理

从事汽车软件开发，AUTOSAR这个词是绕不开的。但当有人问"AUTOSAR到底是什么"时，想要干净利落地解释并不容易。知道有Classic和Adaptive两个版本，也知道它们不同，但具体有什么区别、为什么要分成两个，真正了解的人其实并不多。

本文就来做一次系统梳理。

什么是AUTOSAR？

AUTOSAR（AUTomotive Open System ARchitecture）是汽车软件的标准架构。2003年由欧洲主要OEM和Tier1零部件厂商联合成立。目前已有全球350多个合作伙伴组织参与的全球性联盟。

核心目的很简单：将汽车ECU（电子控制单元）中的软件标准化，使硬件变更后软件仍可复用。简单来说，"将硬件和软件分离"就是AUTOSAR的根本哲学。

然而随着汽车的发展，问题出现了。最初制定的标准无法满足自动驾驶、车联网等新需求。于是，Adaptive Platform应运而生。

Classic Platform — 经过验证的基础

Classic Platform（CP）是AUTOSAR的元老。自2003年成立以来持续发展，目前量产车中搭载的AUTOSAR软件绝大多数都是基于CP开发的。

应用场景

CP针对Deeply Embedded ECU进行了优化。包括发动机控制、变速箱控制、制动（ABS/ESC）、安全气囊、车身控制等领域。这些ECU的共同特点是实时性要求极高——制动控制哪怕延迟几毫秒都可能引发事故。

核心特性

CP最大的特点是静态配置（Static Configuration）。一切在构建时确定：哪些软件组件按什么顺序执行、使用多少内存、通信路径如何，全部在编译阶段就已固定。

这为什么重要？因为它能保证实时性。可以实现微秒级的Hard Real-Time响应，并支持ASIL-D（ISO 26262最高安全等级）。如果运行时动态变化，时序保证就会变得困难，而CP从根本上消除了这种不确定性。

通信方式

CP使用CAN、LIN、FlexRay等传统车载网络。这些网络带宽虽然有限，但能保证实时传输，是汽车行业经过数十年验证的技术。

Adaptive Platform — 新时代的需求

Adaptive Platform（AP）于2017年发布了首个版本（R17-03）。它与CP有着完全不同的设计理念。

为什么要创建？

要实现自动驾驶（ADAS/AD）、车联网、OTA（Over-The-Air）更新等功能，需要高性能计算。要实时处理来自摄像头、激光雷达、毫米波雷达的海量传感器数据，并运行复杂的AI算法。CP的静态架构无法胜任。

AP就是为这类高性能计算ECU而设计的。运行在POSIX兼容操作系统（通常基于Linux）之上，使用C++14及更高版本的现代语言。

核心特性：SOA

AP最核心的特性是SOA（Service-Oriented Architecture），即面向服务的架构。CP中软件组件之间的通信是静态连接的，而AP中服务是在运行时动态发现和连接的。

实际工作中是这样的：摄像头服务向网络通告"我可以提供目标识别数据"（Service Discovery），自动驾驶决策模块找到该服务并动态连接。即使添加新传感器或更新算法，也无需重新构建整个系统，只需替换相应的服务即可。

ARA — 标准API

AP定义了ARA（AUTOSAR Runtime for Adaptive Applications）标准API层。应用程序通过ARA访问平台服务。通信管理（Communication Management）、执行管理（Execution Management）、状态管理（State Management）、诊断（Diagnostics）等功能都通过ARA提供。

关键在于：基于ARA开发的应用程序可以在任何实现了ARA的平台上运行。硬件和OS变更后也无需修改应用程序代码。

通信方式

AP主要使用Automotive Ethernet，通过SOME/IP（Scalable service-Oriented MiddlewarE over IP）协议通信。SOME/IP支持服务发现、事件订阅、远程过程调用等SOA通信模式。基于以太网，提供比CAN高数十到数百倍的带宽。

CP vs AP — 核心差异总结

设计理念

• CP：静态配置，构建时确定一切
• AP：动态配置，运行时服务发现和连接

目标ECU

• CP：Deeply Embedded ECU（发动机、变速箱、制动、安全气囊）
• AP：High-Performance Computing ECU（ADAS/AD、信息娱乐、中央网关）

实时性

• CP：Hard Real-Time（微秒级），支持ASIL-D
• AP：Soft Real-Time，针对高性能数据处理优化

操作系统

• CP：AUTOSAR OS（基于OSEK的专用RTOS）
• AP：POSIX兼容OS（基于Linux）

开发语言

• CP：C
• AP：C++14及以上

通信

• CP：CAN、LIN、FlexRay
• AP：Automotive Ethernet、SOME/IP

更新方式

• CP：需要整体刷写
• AP：支持单个服务级别更新（支持OTA）

不是竞争，而是共存

这里有一点必须明确：AP并非要取代CP。两者是共存且协作的关系。

从现实角度来看这是显而易见的。没有理由将制动控制迁移到基于Linux的AP上。需要微秒级Hard Real-Time的安全关键功能，CP已经完美地处理了。反过来，自动驾驶的感知和决策算法也不可能在CP有限的资源上运行。

在实际车辆中，CP ECU和AP ECU通过网关ECU连接。例如，基于AP的ADAS ECU判断"需要紧急制动"时，制动命令通过网关传递给基于CP的制动ECU。AP使用Ethernet通信，CP使用CAN通信，网关负责协议转换。

从2019年R19-11版本开始，CP和AP每年同步发布。最新版本是2024年12月的R24-11。该版本新引入了基于VISS（Vehicle Information Service Specification）协议的Automotive API Gateway，进一步扩展了车内外服务之间的连接。

SDV时代，Adaptive的角色将更加重要

随着SDV（Software-Defined Vehicle）时代的到来，车辆架构正在发生变化。以往按功能分布的ECU正在向由中央计算单元（Central Computing Unit）统一管理多种功能的方向发展。

在这个中央计算单元中，Adaptive Platform扮演着核心角色。得益于SOA架构，可以按服务单位管理功能、通过OTA更新、添加新服务。就像在智能手机上安装和更新应用程序一样的概念，也将应用到汽车上。

但这并不意味着CP会消失。在安全关键功能、实时控制、低功耗ECU方面，CP仍然是核心。ASPICE流程质量标准同样适用于CP和AP的开发。CP + AP的共存架构在未来相当长一段时间内将继续维持。

PopcornSAR的Adaptive AUTOSAR解决方案

PopcornSAR作为Adaptive AUTOSAR专业企业，提供AP开发所需的全套解决方案。

PARA是PopcornSAR开发的Adaptive AUTOSAR中间件平台。实现了ARA规范，在PARA上开发的应用程序可在标准Adaptive AUTOSAR环境中运行。提供通信管理、执行管理、诊断等AP核心服务。

PAIO是基于AI的AUTOSAR设计工具，可从Network Topology到BSW配置自动生成ARXML。用自然语言输入需求即可自动化设计工作，大幅缩短开发时间。

AutoSAR.io是ARXML设计工具，同时支持CP和AP。用于系统架构设计和ARXML管理。

将这些整合在一起的就是Adaptive AUTOSAR Tool Kit。以设计（PAIO / AutoSAR.io）→ 运行时（PARA）作为一套完整解决方案，覆盖Adaptive AUTOSAR开发的全流程。

各产品的详细信息请查看PARA产品页面和PAIO产品页面。如需评估引入方案或技术咨询，请通过联系我们随时沟通。