Autosar AP – AP和CP差异

■ 硬件：

     1. 芯片类型：

         ▪ CP AUTOSAR一般运行在8bit、16bit、32bit的微控制器（MCU）中，如英飞凌的TC3xx，瑞萨的RH850等。

         ▪ AP AUTOSAR可以运行在64bit的高性能处理器（MPU）、CPU等中，如瑞萨的H3，英伟达的Xavier等。除此之外，AP AUTOSAR也可以运行在虚拟硬件上。

     2. 芯片算力：

         ▪ 运行CP AUTOSAR 的芯片算力一般低于1000 DMIPs

         ▪ AP AUTOSAR可以运行在算力高于20000 DMIPs的芯片上

■ OS：

      1. OS类型：

          ▪ CP AUTOSAR OS是基于OSEK标准的。

          ▪ AP AUTOSAR OS是POSIX OS(UNIX, linux)，且至少应包含PSE51子集。

      2. 开发商:

          ▪ CP AUTOSAR OS一般由CP AUTOSAR供应商开发，如AUBASS、VECTOR等。

          ▪ AP AUTOSAR 配套的OS一般是由专门的OS厂商开发的，如eSOL的eMCOS、黑莓的QNX等

■ 架构：

     1. CP AUTOSAR

         软件分为三层：Application，runtime environment(RTE)和basic software(BSW)。

          ▪ Application Layer，不依赖于硬件的

          ▪ 软件模块间通过RTE交互，并通过RTE访问BSW

          ▪ RTE体现了application的所有接口

          ▪ BSW又分为3大层和复杂驱动：服务层、ECU抽象层、MCU抽象层

          ▪ 服务层又细分为不同的服务组件，比如系统服务、存储服务、通信服务等

■ 架构：

     2. AP AUTOSAR

         Adaptive AUTOSAR标准定义了一个ARA运行环境，分为两种接口类型：service和APIs。平台由根据服务（Platform Service）和Adaptive AUTOSAR基础（Platform Foundation）分组的多个功能栈（功能集群）组成。

         ▪ 聚合了自适应平台功能

         ▪ 定义了功能栈需求规范

         ▪ 从应用程序和网络角度描述软件平台的行为

         ▪ 但不限制最终在自适应平台中的具体软件架构设计

 

 

■ 架构设计原则：

     1. CP AUTOSAR设计原则：

         ▪ CP AUTOSAR将于硬件相关的以及通用系统功能定义为BSW模块

         ▪ 应用功能定义为独立的软件组件SWC

         ▪ RTE分离SWC和BSW
         ▪ BSW可配置，并且可以被多个产品线的ECU重复使用

         ▪ 不开源

     2. AP AUTOSAR设计原则：

         ▪ 遵循面向服务的架构SOA设计范式（理念）

         ▪ 充分利用其他领域软件成熟技术，重用软件市场成熟组件，缩短开发周期

         ▪ 充分利用各种开源软件

■ 开发流程

     从开发流程来看，AP和CP都主要包括以下三个阶段：

         ▪ 设计阶段：设计ARXML

         ▪ 代码生成：基于ARXML生成代码

         ▪ 集成：集成Application，编译调试等

    不同点

         ▪ 在AP AUTOSAR设计阶段，需要进行Service与Manifest的设计。

         ▪ CP则不用。CP需要进行ECU配置设计，而AP没有ECU配置这个设计项。

         ▪ 在代码生成时，CP是生成基础软件模块相关的代码，AP生成的是FC相关的代码和Manifest，需要注意的是，AP中不是所有的FC都会生成相关的代码和Manifest。(橙色是CP，绿色是AP)

 

■ 接口

     ▪ CP AUTOSAR常用的接口是Sender-Receiver，Client-Server等

     ▪ AP AUTOSAR常用的接口是Service Interface等

     当设计CP AUTOSAR与AP AUTOSAR之间的通信时，需要进行信号到服务的转换设计，当前能提供该功能模块的只   有ETAS的Signal2Service Function Cluster。

     Signal-2-Service功能集群：

     ▪ 从信号到服务（CP到AP）Signal2Service

     ▪ 从服务到信号（AP到CP）Service2Signal

■ 通信方式

     ▪ CP AUTOSAR是基于信号的通信，主要包括CAN、Lin、FlexRay等。

     ▪ AP AUTOSAR是面向服务的通信，支持基于以太网的SOME/IP、IPC、RPC等。

     CP AUTOSAR虽然可以支持SOME/IP，但是CP AUTOSAR中SOME/IP只不过是把Sender-Receiver的CAN通信转换成了Client-Server的以太网通信，整个通信链路仍是静态配置的，并不是真正的面向服务的通信。

■ 调度方式

     ▪ 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主要通过以下三种状态来进行状态管理：

        ▪ Function Group（FG）State：功能组状态

        ▪ Process State：进程状态，EM通过Function Group来改变Process State

        ▪ Execution State：进程的执行状态

■ 状态管理

CP状态管理

 

AP状态管理

 

■ Safety

     1. CP AUTOSAR中的Safety机制主要有：

          ▪ 与OS相关的Safety机制：内存保护，时序保护，硬件保护

          ▪ E2E保护：End to End，端到端的通信保护，为防止通信链路中可能存在的故障HW/SW）， 在 通信节点 之间 执行的 一种数据保护协议/机制。

          ▪ 看门狗管理器： Alive 监视， Deadline 监视， Logic 监视

          ▪ 硬件诊断： Core Test， RAM Test， Flash Test

      2. AP AUTOSAR中ara::com支持E2E。

■ Security

     1. CP AUTOSAR中的Security方案主要包括：

          ▪ SecOC：Secure Onboard Communication

          ▪ CSM：Crypto Service Manager

        

         主要流程为：

          ▪ 添加/验证身份验证信息

          ▪ 实现上下层模块的接口

          ▪ 由PduR路由配置解决

          ▪ 维护缓冲区以存储和修改安全的I-PDU

      2. AP AUTOSAR中与Security相关的模块主要为：

          ▪ ara::iam：身份验证管理

          ▪ ara::crypto：用于通用加密操作和安全密钥管理

             -> 为Adaptive Application提供接口，负责加密原语的构建和监督

             -> 提供了通过标准化接口访问加密算法的多种实现的基础结构

             -> 该规范对加密堆栈的内部体系结构和实现没有任何限制

■ 时间同步

     ▪ CP AUTOSAR与时间同步相关的模块为StbM。

     ▪ AP AUTOSAR与时间同步相关的模块为ara::tsync

■ 开发语言

     ▪ CP AUTOSAR主要使用的是C语言，相关的标准是MISRA C

     ▪ AP AUTOSAR主要使用的是C++语言，相关的标准是ISO/IEC 14882:2014

■ 代码执行

     ▪ CP AUTOSAR上的应用程序直接从ROM执行代码

     ▪ AP AUTOSAR上的应用程序则是从持久性内存加载到RAM中运行

■ 地址空间

     ▪ CP AUTOSAR所有应用程序具有相同的地址空间，其Safety主要通过内存保护单元（MPU）支持。

     ▪ AP AUTOSAR上，每个应用程序都有自己的（虚拟）地址空间，这是通过内存管理单元（MMU）来支持的。

 

■ Update

     ▪ CP AUTOSAR自身是不支持OTA的，这就意味着要更新在CP AUTOSAR上运行的应用程序，就必须更新这个ECU的代码。通过其他控制器对运行CP AUTOSAR的控制器进行更新不算CP AUTOSAR自身的OTA。

     ▪ AP AUTOSAR是自身支持OTA的，AP AUTOSAR可以自己删除/更新/增加单个Application，而且AP AUTOSAR也可以更新某个功能集群(FC)的代码，只是这种用例比较少见。

■ 应用场景

     ▪ CP AUTOSAR一般应用在对实时性要求高、对功能安全要求高、对算力要求较低的场景中，如引擎控制、制动系统等。

    ▪ AP AUTOSAR一般应用在对实时性有一定要求、对功能安全有一定要求，对算力要求较高的场景中，如：

        ① 传感器融合处理、运行时动态更新

        ② 自动驾驶中

        ③ OTA