在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、DDS、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函数功能相同见下表:
ara::tsync API |
StbM API |
now |
StbM_GetCurrentTime |
calculateTimeDiff |
StbM_ GetCurrentTimeDiff |
setTime |
StbM_SetGlobalTime |
updateTime |
StbM_UpdateGlobalTime |
setUserData |
StbM_SetUserData |
setOffset |
StbM_SetOffset |
getOffset |
StbM_GetOffset |
getRateDeviation |
StbM_GetRateDeviation |
setRatecorrection |
StbM_SetRatecorrection |
timeLeap |
StbM_GetTimeLeap |
getTimeBasestatus |
StbM_GetTimeBasestatus |
startTimer |
StbM_StartTimer |
updateCount |
StbM_GetTimeBaseUpdateCounter |
(via status flags) |
StbM_GetMasterConfig |
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的相互补充,一同合作!
AUTOSAR AP 与 CP 的差异在哪里?