【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