在2003年AUTOSAR组织刚成立的时候，只有一个AUTOSAR标准，没有AP（Adaptive Platform）与CP（Classic Platform）之分。
在2005年，AUTOSAR组织推出了第一个AUTOSAR版本1.0
在2017年，AUTOSAR组织推出了第一个AP AUTOSAR版本R1703，这是第一次外界看到AP AUTOSAR，AUTOSAR也是从这个时候起被分为AP与CP。此时，CP AUTOSAR版本命名为R4.x.x。
在外界看来，AP 与CP是在2017年被区分开的，但是早在2015年，AUTOSAR组织内部就已经进行了区分。
还有一个时间点是在2019年11月份，将AP、CP以及FO（Foundation）版本号进行了统一命名：AP AUTOSAR R1911、CP AUTOSAR R1911等。
AUTOSAR组织一般只发布CP AUTOSAR的标准。
AP AUTOSAR方面，AUTOSAR组织除了发布相关的标准外，还为AUTOSAR会员提供了APD（Adaptive Platform Demonstration），APD中包含仅供参考的AP AUTOSAR工具、代码包等。
无论是AP AUTOSAR还是CP AUTOSAR，总体目标是一致的：
更好的管理数量增多，功能复杂度增加的汽车ECU
改善ECU软件质量和可靠性
提升产品升级灵活性，缩短产品推向市场的时间
可拓展的架构解决方案
CP AUTOSAR与AP AUTOSAR倡议内容是相同的：
汽车软件架构标准设计
详细的底层软件模块设计
汽车产品各域标准化数据描述
适用于此架构的过程定义和软件工具链
CP AUTOSAR一般运行在8bit、16bit、32bit的微控制器（MCU）中，如英飞凌的TC3xx，瑞萨的RH850等。
AP AUTOSAR可以运行在64bit的高性能处理器（MPU）、CPU等中，如瑞萨的H3，英伟达的Xavier等。除此之外，AP AUTOSAR也可以运行在虚拟硬件上。
PS：有些公司可能会将某种POSIX OS移植到如TC3xx中，进而在TC3xx中使用AP，这种例子很少见，且不推荐，所以这里不做细究。
运行CP AUTOSAR 的芯片算力一般低于1000 DMIPs
AP AUTOSAR可以运行在算力高于20000 DMIPs的芯片上
这里的算力是指逻辑算力DMIPs，还有另一种TOPS，一般是指AI芯片的指标，一般是指矩阵运算算力。
CP AUTOSAR OS是基于OSEK标准的。
AP AUTOSAR OS是POSIX OS，且至少应包含PSE51子集。
CP AUTOSAR OS一般由CP AUTOSAR供应商开发，如AUBASS、VECTOR等。
AP AUTOSAR 配套的OS一般是由专门的OS厂商开发的，如eSOL的eMCOS、黑莓的QNX等。
CP AUTOSAR是分层的软件架构，有较为明显的上下层关系，如下图所示：
从下到上依次为：
1、微控制器层（HW）
2、基础软件层（BSW）
微控制器抽象层
ECU抽象层
服务层
复杂驱动
3、RTE层
4、Application层
AP AUTOSAR一般是指ARA（AUTOSAR Runtime for Adaptive Applications），主要由两部分组成（Foundation和Service），如下图所示：
上图中，所有的模块都称为功能集群（Functional Clusters, FC）。
上图中，蓝色的FC属于Foundation的部分，橘色的部分属于Service的部分。
无论是Foundation部分的FC，还是Service部分的FC，都不是上下层关系。
CP AUTOSAR架构设计原则为：
CP AUTOSAR将与硬件相关的以及通用系统功能定义为BSW模块
应用功能定义为独立的软件组件SWC
RTE分离SWC和BSW
BSW可配置，并且可以被多个产品线的ECU重复使用
不开源
AP AUTOSAR架构设计原则为：
遵循面向服务的架构SOA设计范式（理念）
充分利用其他领域软件成熟技术，重用软件市场成熟组件，缩短开发周期
充分利用各种开源软件
开发流程来看，CP与AP都主要都包括以下三个阶段：
设计阶段：设计ARXML
代码生成：基于ARXML生成代码
集成：集成Application，编译调试等
主要有以下不同：
在AP AUTOSAR设计阶段，需要进行Service与Manifest的设计，而CP则不用。CP需要进行ECU配置设计，而AP没有ECU配置这个设计项。
当然，CP 与AP都需要进行系统设计，诊断设计，具体的不同体现在设计时。
在代码生成时，CP是生成基础软件模块相关的代码，AP生成的是FC相关的代码和Manifest，需要注意的是，AP中不是所有的FC都会生成相关的代码和Manifest。
集成时，AP AUTOSAR需要考虑 OEM Application Cloud，而CP则不用。
CP 与AP开发流程如下图所示：
蓝色虚线框表示CP AUTOSAR的开发流程，绿色表示AP AUTOSAR的开发流程。
上图中，在代码生成阶段没有体现AP要生成Manifest，实际开发时需要。
上图中，只是一个简单的整理，并没有涵盖AUTOSAR所有需要设计的内容。
CP AUTOSAR常用的接口是Sender-Receiver，Client-Server等
AP AUTOSAR常用的接口是Service Interface等
当设计CP AUTOSAR与AP AUTOSAR之间的通信时，需要进行信号到服务的转换设计！当前能提供该功能模块的只要有ETAS，Signal2Service Function Cluster
CP AUTOSAR是基于信号的通信，主要包括CAN、Lin、FlexRay等。
AP AUTOSAR是面向服务的通信，支持基于以太网的SOME/IP、IPC、RPC等。
CP AUTOSAR虽然可以支持SOME/IP，但是CP AUTOSAR中SOME/IP只不过是把Sender-Receiver的CAN通信转换成了Client-Server的以太网通信，整个通信链路仍是静态配置的，并不是真正的面向服务的通信。
这也是为什么AUTOSAR官方说AP AUTOSAR是SOA，但从来不会说CP AUTOSAR是SOA。
CP AUTOSAR OS采用固定的任务调度配置。在OS Task中调度BSW Main Functions以及SWC的Runnable Entities，按既定规则顺序执行。并协同BSW Modules和App SWC的模式切换。
AP AUTOSAR 支持多种动态调度策略，配置在运行时完成，配置信息在Manifest文件中体现。
AP AUTOSAR中与调度相关的模块主要为执行管理（EM）和状态管理（SM），应用程序运行在Process、Thread中。
CP AUTOSAR中，任务的调度周期可以到us级别。而AP AUTOSAR是在ms（一般是几十上百）级。
CP AUTOSAR 通过模式开关组件处理不同的状态：
BSW模式（Network Online, Offline）
Application模式（Normal等）
Vehicle 模式（Active，Inactive）
AP AUTOSAR主要通过以下三种状态来进行状态管理：
1、Function Group（FG）State：功能组状态
Machine State：Machine状态是一种特色的功能组状态
2、Process State：进程状态，EM通过Function Group来改变Process State。
3、Execution State：进程的执行状态
根据AUTOSAR官方的说法，在功能安全上，CP AUTOSAR可以支持高达ASIL-D的系统开发。AP可以支持高达ASIL-B的系统开发。
当然，这并不意味着，使用AP时，最多只能设计出ASIL-B的系统。
更深的内容就跟功能安全有关了，建议参考以下ISO26262以及CP & AP AUTOSAR与功能安全相关的文档。
CP AUTOSAR中的Safety机制主要有：
1、与OS相关的Safety机制：
内存保护
时序保护
硬件保护
2、E2E保护，如下图所示
3、看门狗管理器
Alive 监视
Deadline 监视
Logic 监视
4、硬件诊断
Core Test
RAM Test
Flash Test
AP AUTOSAR中ara::com支持E2E。
同时也在ara::phm中提供了以下恢复措施：
请求SM切换到指定Function Group状态
请求EM重新启动指定进程
将错误信息转发到应用程序
……
CP AUTOSAR中的Security方案主要包括：
SecOC：Secure Onboard Communication
CSM：Crypto Service Manager
CP AUTOSAR中使用Security方案时的流程如下图所示：
主要流程为：
添加/验证身份验证信息（针对/来自较低层）
实现上下层模块的接口
由PduR路由配置解决
维护缓冲区以存储和修改安全的I-PDU
AP AUTOSAR中与Security相关的模块主要为：
ara::iam：身份验证管理
ara::crypto：用于通用加密操作和安全密钥管理
ara::crypto主要功能如下：
为Adaptive Application提供接口，负责加密原语的构建和监督
提供了通过标准化接口访问加密算法的多种实现的基础结构。
该规范对加密堆栈的内部体系结构和实现没有任何限制。
CP AUTOSAR与时间同步相关的模块为StbM。
AP AUTOSAR与时间同步相关的模块为ara::tsync
CP AUTOSAR与AP AUTOSAR使用相同的时间同步协议，
CP中的StbM提供的API函数与AP中的ara::tsync所提供的API函数在功能上基本是相同的，具体哪个StbM的API函数与哪个ara::tsync的API函数功能相同见下表：
CP AUTOSAR主要使用的是C语言，相关的标准是MISRA C。当然，应用软件、基础软件都使用C语言。这里是为了文章结构放到了应用层章节进行说明，不代表只有应用层是C语言。
AP AUTOSAR也是如此，只是为了文章结构而放到这里进行说明。
AP AUTOSAR主要使用的是C++语言，相关的标准是ISO/IEC 14882:2014。当前支持C++11、C++14，也支持一定的C++17。
需要注意的是，根据1003.13-2003，AP中的操作系统接口（OSI）必须通过POSIX PSE51接口提供OS的功能，这些POSIX PSE51是C接口。
也就意味着，使用AP AUTOSAR时，需要使用C++开发应用程序，但是这些C++应用程序需要将PSE51 C接口与C++库（包含C++标准库）结合在一起使用。
CP AUTOSAR上的应用程序直接从ROM执行代码。
AP AUTOSAR上的应用程序则是从持久性内存加载到RAM中运行。
CP AUTOSAR所有应用程序具有相同的地址空间，其Safety主要通过内存保护单元（MPU）支持。
AP AUTOSAR上，每个应用程序都有自己的（虚拟）地址空间，这是通过内存管理单元（MMU）来支持的。
CP AUTOSAR自身是不支持OTA的，这就意味着要更新在CP AUTOSAR上运行的应用程序，就必须更新这个ECU的代码。通过其他控制器对运行CP AUTOSAR的控制器进行更新不算CP AUTOSAR自身的OTA。
AP AUTOSAR是自身支持OTA的，AP AUTOSAR可以自己删除/更新/增加单个Application，而且AP AUTOSAR也可以更新某个功能集群（FC）的代码，只是这种用例比较少见。
CP AUTOSAR与AP AUTOSAR主要的不同是在应用场景上。
CP AUTOSAR一般应用在对实时性要求高、对功能安全要求高、对算力要求较低的场景中，如引擎控制、制动系统等。
AP AUTOSAR一般应用在对实时性有一定要求、对功能安全有一定要求，对算力要求较高的场景中，如：
1、传感器融合处理、运行时动态更新
2、自动驾驶中：
与交通基础设施的通信
与云服务器进行通信
3、域控制器的车辆架构
车身域
娱乐域
动力域
4、OTA
5、跨域计算平台、智能手机集成等等
以上便是对CP AUTOSAR与AP AUTOSAR进行的简单对比，除此之外还有其他很多可以对比的地方，如标定、诊断、部署等等。大家可以参考相关的标准。
总的一句话，AP AUTOSAR是CP AUTOSAR的相互补充，一同合作！
最前沿的电子设计资讯
