Autosar AP – 概要

未来E/E架构的发展有如下需求：

互联：连接车辆需要高带宽的动态数据连接，以进行故障管理、路边基础设施互动、实时更新前方道路状况的 ADAS 系统、空中软件更新OTA等。

自动驾驶：自动驾驶和辅助系统(ADAS)旨在减少驾驶员的工作量。ADAS 系统要求 E/E 架构集成先进的传感器和支持算法，涉及高性能计算机处理(HPC) ，如计算机视觉、传感器融合的对象模型等。

共享：代理服务、移动即服务、应用程序

电气化：新的动力总成要求，电池管理

这些需求被称为 CASE ——互联、自动驾驶、共享、电气化的缩写。

已经尝试使用经典 AUTOSAR 来满足 CASE 需求。例如，相对简单的驾驶辅助系统，如车道跟踪和自适应巡航控制已经成功地实现了使用经典 AUTOSAR。然而，当多个这样的系统定义在一辆车的结果是，许多 ECUs 可以决定影响车辆的安全，如是否加速或停止！为了确保没有冲突发生，协调多个决策所需要的开销导致系统复杂性和所需测试的大量增加。因此，需要一个新的高性能、高灵活性的平台，支持高性能计算、动态通信和增量变化，能够在离开传统 AUTOSAR 平台的车辆内执行集中决策任务，以满足功能性 ECUs 的实时性和安全性要求。

Autosar Adaptive应运而生。

什么是AP AUTOSAR？第一个概念，它是一个中间件。

没有中间件的APP开发是直接基于OS的，中间件就是将Application与硬件进行分离。当然，AP AUTOSAR也将Application与OS进行了分离。如下图所示。

这里的中间件被称为Runtime For Adaptive Application（ARA），主要由两部分组成，Foundation 和 Service。OS在Foundation中，其中，AP AUTOSAR规定，OS需要使用符合POSIX OS标准的OS，如Linux，MCOS，QNX等。

将当前的汽车 ECUs 可以分为功能性 ECUs 或信息娱乐。

AUTOSAR 经典平台已经被开发为非常适合于功能性 ECUs。这些 ECU 的特点是拥有属性强的实时性和强大的安全要求ASIL-D。它们通常也有低资源可用性(无论是 CPU，RAM 或 Flash) ，需要完全静态配置的最佳使用。

相比之下，信息娱乐 ECUs 运行在一个高资源环境中，通常是由于用户界面的要求。一个信息娱乐 ECU 通常不是一个实时系统，一个信息娱乐 ECU 通常运行在一个嵌入式 PC 上，运行成熟的操作系统，例如 Linux，而不是汽车操作系统。

Adaptive AUTOSAR 的设计是为了搭建两个世界之间的桥梁，提供一个具有灵活软件和高资源可用性的实时执行环境。Adaptive平台 ECU 的特点是具有软实时性和一些安全要求 -- AUTOSAR 打算为Adaptive平台提供中等级别的 ASIL，尽管实现可以选择符合更高级别的 ASIL，或者可以使用诸如安全分解等体系结构技术来实现更高级别的 ASIL (拥有属性)。然而，与 Classic 不同的是，它的目的是使用基于 POSIX 标准的多核、动态操作系统的高资源环境。

Adaptive平台的实现可以使用有计划的动态来限制平台的动态方面，以支持可预测的执行或资源消耗。Planned dynamics 可能会将动态内存分配限制在启动阶段，预先确定服务发现过程，将应用程序分配给特定的核心，或者确保只访问文件系统中预先存在的文件。

■ Autosar经典平台和自适应平台比较, 在3.2 autosar ap和cp差异中详细阐述。

经典平台Autosar CP	自适应平台Autosar AP
通信基于信号，并且通过通信总线网络(例如CAN，LIN)来实现	基于服务通信，利用以太网SOME/IP作为物理介质
深入嵌入功能实现	高性能和计算密集功能的实现
应用案例：引擎控制，制动系统	应用案例：OTA，传感器融合数据处理
无法在运行时进行软件更新，SWC通讯是硬连线	自适应autosar RTE独立于应用程序，可以在线更新
更新意味替换整个ECU代码	提供了在ECU中删除/更新单个应用程序的选项
架构的灵活性低	提供了灵活的集成环境
严格的实时处理要求(usec)，并且要满足最后期限	实时的软件要求（msec为单位）
C语言	C++语言
实施不需要操作系统，OSEK OS	基于POSIX操作系统
利用RTE进行SWC的调度以及它们之间的通信	应用程序利用操作系统进行调度和通信
静态的服务模块，模块和配置在发布前进行静态编译、链接	服务可根据应用需求动态加载，可通过配置文件动态加载配置，并可进行单独更新
FOA架构（function-oriented architecture）	SOA架构（service-oriented architecture）
大部分代码静态运行在ROM，所有application共用一个地址空间	application加载到RAM运行，每个application独享（虚拟）一个地址空间

■ Adaptive AUTOSAR优势：

▪ 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通讯

Autosar AP – 概要相关推荐

Adaptive AUTOSAR (AP) 平台设计(2)——架构
前言 Hello!大家好! 欢迎来到<搞一下汽车电子> 本期为<搞一下 AP AUTOSAR 平台设计>第2期:架构更多精彩内容欢迎订阅微信公众号 " 搞一下汽车电 ...
AUTOSAR AP与 CP 有什么差异？
1标准概况不同 1.1 时间在2003年AUTOSAR组织刚成立的时候,只有一个AUTOSAR标准,没有AP(Adaptive Platform)与CP(Classic Platform)之分. 在 ...
Adaptive AUTOSAR (AP) 平台设计(6)——通信管理
前言 Hello!大家好! 欢迎来到<搞一下汽车电子> 本期为<搞一下 AP AUTOSAR 平台设计>第6期:通信管理更多精彩内容欢迎订阅微信公众号 " 搞一下汽 ...
Adaptive AUTOSAR (AP) 平台设计(9)——Persistency
前言 Hello!大家好! 欢迎来到<搞一下汽车电子> 本期为<搞一下 AP AUTOSAR 平台设计>第9期:Persistency 更多精彩内容欢迎订阅微信公众号 &quo ...
Adaptive AUTOSAR (AP) 平台设计(12)——UCM
前言 Hello!大家好! 欢迎来到<搞一下汽车电子> 本期为<搞一下 AP AUTOSAR 平台设计>第12期:UCM 更多精彩内容欢迎订阅微信公众号 " 搞一下汽 ...
Adaptive AUTOSAR (AP) 平台设计(8)——诊断
前言 Hello!大家好! 欢迎来到<搞一下汽车电子> 本期为<搞一下 AP AUTOSAR 平台设计>第8期:诊断更多精彩内容欢迎订阅微信公众号 " 搞一下汽车电 ...
Autosar AP – AP和CP差异
■ 硬件: 1. 芯片类型: ▪ CP AUTOSAR一般运行在8bit.16bit.32bit的微控制器(MCU)中,如英飞凌的TC3xx,瑞萨的RH850等. ▪ AP AUTOSAR可以运行在6 ...
Adaptive AUTOSAR (AP) 平台设计(3)——操作系统
前言 Hello!大家好! 欢迎来到<搞一下汽车电子> 本期为<搞一下 AP AUTOSAR 平台设计>第3期:操作系统更多精彩内容欢迎订阅微信公众号 " 搞一下汽 ...
AP Autosar平台设计 15 加密Cryptography16 日志和跟踪Log and Trace
目录 15.1安全架构 15.2密钥管理体系结构 15.3关于API扩展的备注 16日志和跟踪Log and Trace 16.1概述 16.2架构 AP支持用于常见加密操作和安全密钥管理的API.A ...

Autosar AP – 概要

Autosar AP – 概要相关推荐

最新文章

热门文章