Adaptive Platform AUTOSAR(AP)平台设计(1)——范围和方法

Hello!大家好!
欢迎来到《搞一下汽车电子》
之前我们分享了一系列与 AP AUTOSAR 平台设计相关的文章,但是之前分享的内容是基于R1810 AUTOSAR版本的。由于AUTOSAR版本的更新,内容也发生了改动,因此从本篇开始,小编将会基于最新版本(R1911)重新进行一次分享。
整理不易,如果觉得不错,点赞分享支持一下吧~

AP和CP相关资料获取和工具咨询,可关注微信公众号“搞一下汽车电子”。

邮箱:[email protected]

微信:shactiontech


1.背景

传统ECU:控制软件为目标车辆而设计在车辆使用寿命期间不会发生重大变化

智能ECU:高度自动驾驶的到来车辆中高性能CPU的引入OTA技术的搭载

AUTOSAR经典平台(CP)标准满足了深度嵌入式ECU的需求,而智能ECU的需求无法满足。因此,AUTOSAR指定了另一个软件平台,即AUTOSAR自适应平台(AP)。AP主要提供高性能的计算和通信机制,并提供灵活的软件配置,例如支持OTA技术。


2.技术驱动因素

① 以太网
车载网络不断增长的带宽要求导致引入了以太网。
与传统的车载通信技术(例如CAN)相比,以太网具有高带宽并具有交换网络、可以更有效地传输长消息、实现点对点通信等 。
CP尽管支持以太网,但主要是针对传统通信技术而设计的,并且已经为此进行了优化,因此很难充分利用基于以太网的通信功能并从中受益。

② 处理器
随着汽车的智能化程度越来越高,处理器的性能要求也大大提高。原本为单核MCU设计的CP虽然可以支持多核,但它设计起来却力不从心。
随着越来越多的处理元件(例如多核处理器)被组合在一个芯片中,这些处理元件之间的通信变得比传统的ECU间通信更快,更高效新型的处理器互连技术(如片上网络NoC)使这成为可能。
更大的处理能力和更快的芯片内通信速度的这种综合效果,也促使人们需要一种新的平台,以适应不断增长的系统要求。

扫描二维码关注公众号,回复: 11216878 查看本文章

3.AP的特点

AP采用了各种传统上尚未被ECU充分利用的成熟技术。


C++
AP中使用C++对应用程序进行编程,可以更快地适应新算法并提高应用程序开发效率。

SOA
AP遵循面向服务的体系结构SOA(service-oriented-architecture)。
SOA基于以下概念:
系统由一组服务组成,其中一个服务可以依次使用另一个服务,应用程序可以根据其需要使用一个或多个服务。
服务可以驻留在应用程序运行的本地ECU上,也可以位于正在运行AP另一个实例的远程ECU上。

并行处理
由于不同的应用程序使用不同的服务集,因此SOA具有并行处理的特点。

利用现有标准
开发AP规范的重点是,不会仅仅因为现有标准提供了所需的功能就随意引入了新的接口。

Safety和Security
AP设计的系统通常需要某种级别的安全性,可能是最高级别。
AP结合了架构、功能和程序方法。该体系结构基于SOA的分布式计算,从而使每个组件变得更加独立且不受意外干扰、有助于实现Safety和Security的专用功能、以及使用C ++编码来促进安全性。

计划动态
AP支持应用程序的增量部署,这意味着可以动态管理资源和通信,以减少软件开发和集成的工作量,从而缩短迭代周期。
计划的动态示例可能是: 
·仅将动态内存分配限制为启动阶段
·除了基于优先级的计划外,还需要公平的计划策略
·将进程固定分配给CPU内核
·仅访问文件系统中的现有文件
·应用程序对AP API使用的限制
·仅执行经过验证的代码

敏捷开发
敏捷开发至关重要的一点是,系统的基础体系结构是可增量伸缩的,并且有可能在部署系统后对其进行更新。AP的体系结构可以实现这一点,能应对快速变化需求的软件开发。


4.经典、自适应和非AUTOSAR ECU的集成

AP不会取代CP平台或IVI/COTS中的非AUTOSAR平台。 相反,它将与这些平台和外部后端系统(如路边基础架构)进行交互,以形成一个集成系统。

图1 不同平台的示例性部署
图2 AP和CP的示例性交互
原创文章 32 获赞 107 访问量 7548

猜你喜欢

转载自blog.csdn.net/DJAction/article/details/105487815