【AutoSAR】 CP 和 AP
概述
AutoSAR,全称为Automotive Open System Architecture(汽车开放系统架构)。是由全球各家汽车制造商、零部件供应商以及各种研究、服务机构共同参与的一种汽车电子系统的合作开发框架，并建立了一个开放的汽车控制器(ECU)标准软件架构。
AutoSAR建立的背景是汽车的电子控制系统一直在高速的发展，面临的挑战也越来越多，主要体现以下几个方面：
- 汽车的电气化电子化程度提高，控制器数量增加，网络复杂度增加。
- 软件功能数量急剧增加
- 硬件平台多样化，软件可复用差
- 软件开发周期缩短且成本占比增加
AUTOSAR当前有两个平台CP（经典平台）和AP（自适应平台）
Classsic AutoSAR
Classic AutoSAR标准在最高抽象级别上将运行在控制器上的软件分为三层：Application,runtime environment(RTE)和Basic software（BSW）。
- Application Layer,不依赖于硬件的
- 软件模块间通过RTE交互，并通过RTE访问BSW
- RTE体现了application的所有接口
- BSW分为3大层和复杂驱动：服务层、ECU抽象层、MCU抽象层
- 服务层又细分为不同的服务组件，比如系统服务、存储服务、通信服务等
CP软件架构图：
Classic AutoSAR主要特点：
- 基于C语言面向过程开发
- FOA架构(function-oriented architecture)
- 基于信号的静态配置通信方式(LIN\CAN…通信矩阵)
- 硬件资源的连接关系局限于线束的连接
- 静态的服务模块，模块和配置在发布前进行静态编译、链接
- 大部分代码静态运行在ROM，所有application共用地址空间
- OSEK OS
- CP用于硬实时的MCU平台
Adaptive AutoSAR
AP标准定义了ARA运行环境。分为两种接口类型：service和APIs。平台由根据服务(Platform Service)和AP基础分组的多个功能栈组成。
每个功能栈：
- 聚合了自适应平台功能
- 定义了功能栈需求规范
- 从应用程序和网络角度描述软件平台的行为
- 但不限制最终在自使用平台中具体的软件架构设计
AP软件架构图：
AP的主要特点:
- 基于C++面向对象开发
- SOA架构(Service-oriented architecture)
- 基于服务的SOA动态通信方式(SOME/IP)
- 硬件资源间的连接关系虚拟化，不局限于通信线束的连接关系(互联网)
- 服务可根据应用需求动态加载，可通过配置文件动态加载配置，并可进行单独更新
- application 加载到RAM运行，每个application独享（虚拟）一个地址空间
- POSIX-basedOS,兼容性广，可移植性高
- AP用于高算力的MPU平台
Adaptive AutoSAR核心组件
AutoSAR的核心组件，也称功能集群，简称FC：
Communication Middleware：通信中间件
Execution manager:执行管理
IAM: 权限管控
Diagnostic Manager：诊断
Network Manager：网络管理
Update Manager：升级
Log Manager：Log管理
Health Manager：健康状态监控
核心组件功能描述：
Execution Manager：执行管理，执行不同状态之间的转移
- 搜寻指定路径下所有可用的Executables并加入进程列表中，启动阶段按进程依赖顺序加载所有配置在默认功能组的进程
- 当发生功能组状态切换时，终止未定义在新功能组的进程，并按照进程加载依赖顺序重新加载新功能组的所有进程。
- 当功能组内的状态发生迁移时，驱动所有被加载的进程往相应的状态迁移。
State Manager：状态管理，处理时间，事件/请求优先级等以设置对应的内部状态的功能
- 请求将功能组设置为某一状态
- 请求激活/关闭(部分)网络
- 执行项目特定的操作
IAM：为应用访问及控制AutoSAR资源提供身份鉴权
- 用户需事先PolicyDescision Point(Grant或Deny的Policy)策略
- IAM把应用Application的身份鉴权请求，对接到用户的Policy策略，并给出鉴权结果回给Application
Platform Health Manager：管理被监控运行实体的健康状态
- 监测及判断运行实体的运行状态
- 当检测到异常状态时，按照定义执行RecoveryAction
- 管理各个被监控简称报告的健康状况，并生成PHM的监控及状态切换结果给到用户Application,以便用户执行最终如Watchdog等自定义的决策
Log Manager：提供Log前台打印API及后台Log存储服务
- 可提供CONSOLE/FILE/DLT/SYSLOG等工作模式
- 可配置多级别Verbose/Debug/Info/Warn/Error/Fatal的打印控制
Communication Manager：提供SOME IP Protocol的通信功能
- 支持以SOME IP/IPC binding模式为offer Service及Find Service提供发送及接收Service Discovery Message的能力
- 管理着所有Provided Services及Requeired Services,并为每个Service Interface定义的Event/Method/Field建立映射列表
- 作为所有基于SOME IP protocol Message Broker，为sender和receiver提供router服务
Diagnostics Manager:提供诊断服务处理及内存地址管理功能
- 支持多种诊断传输协议，如DoIP或者用户自定义的传输协议
- 提供多个诊断服务，并支持多个诊断会话并行处理
- 支持UDS定义的标准服务及用户自定义服务
Persistence：提供存储服务
- 提供基于文件存储的读写功能
- 提供基于Key-ValueDatabase的访问及保持功能
UCM：负责对ApaptiveApplication的安装、更新和删除(比如OTA)
- 升级包自身需包含完整的如版本、依赖、认证及签名等信息
- UCM接收来自AA的升级请求，传输用于升级的目标软件包，对软件包进行验签及完整性校验，根据Manifest的描述将目标文件安装到指定路径下/删除指定路径下目标文件
AP优势
ECU更加智能：基于SOA通信使得AP中ECU可以动态的同其他ECU提供或获取服务，动态同其他ECU进行连接更强大计算能力：基于SOA架构使得AP能够更好支持多核、多ECU、多SoCs并行处理，提供更强大的计算能力
更加安全：基于SOA架构使得AP中各个服务模块独立，可独立加载，IAM管理访问权限
敏捷开发：Adaptive AUTOSAR服务不局限于部署在ECU本地可分布于车载网络中，使得系统模块可灵活部署，并可后期灵活独立更新（FOTA）
高通信带宽：基于Ethernet等高通信带宽的总线通信
更易物联：基于以太网的SOA通信，更易实现无线、远程、云连接，部署Car-2-X应用
系统兼容：通过SOME\IP等协议AP可以同CP/Non-AUTOSAR等ECU
参考来源：
https://www.autosar.org/standards/adaptive-platform/
https://zhuanlan.zhihu.com/p/414590426
https://zhuanlan.zhihu.com/p/130668798