AP Autosar平台设计 1-2 导言、技术范围与方法

1

目录

1导言

1.1内容

2技术范围和方法

2.1概述–智能ECU的前景

2.2技术驱动因素

2.3自适应平台-特性

2.3.1 C++

2.3.2 SOA

2.3.3并行处理

2.3.4利用现有标准

2.3.5安全和安保

2.3.6计划动态 Planned dynamics

2.3.7敏捷

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

2.5规范范围

---

1导言

1.1内容

本规范描述了AUTOSAR自适应平台（AP）的设计。本文件的目的是概述AP，但不是详细说明AP设计的所有要素。它将为AP用户和AP实施者提供AP的总体设计和关键概念。

 

该文件的组织如下。首先介绍AP的一些背景知识，然后描述AP的逻辑和物理视图。随后是AP的独立章节和所有功能集群，它们是AP的功能单元，每个章节都包含其概述和对其关键概念的介绍。技术范围和方法体系结构方法和清单

 

相关RS、SWS（Software Specification软件规范）、TR和EXP文件中定义了详细规范和对所解释概念的讨论。

2技术范围和方法

2.1概述–智能ECU的前景

传统上，ECU主要实现取代或增强机电系统的功能。这些嵌入式ECU中的软件根据输入信号和连接到车辆网络的其他ECU的信息控制电气输出信号。大部分控制软件是为目标车辆设计和实施的，在车辆寿命期间不会发生显著变化。

 

新的车辆功能，如高度自动化驾驶，将在车辆中引入高度复杂且需要计算资源的软件，并且必须满足严格的完整性和安全性要求。此类软件实现环境感知和行为规划等功能，并将车辆集成到外部后端和基础设施系统中。由于不断发展的外部系统或改进的功能，车辆中的软件需要在车辆生命周期内更新。

 

AUTOSAR经典平台（CP）标准满足了深度嵌入式ECU的需求，但无法满足上述ECU的需求。因此，AUTOSAR指定了第二个软件平台，即AUTOSAR自适应平台（AP）。AP主要提供高性能计算和通信机制，并提供灵活的软件配置，例如支持软件空中更新。为CP专门定义的功能，如对电信号的访问和汽车专用总线系统，可以集成到AP中，但不在标准化的重点范围内。

2.2技术驱动因素

背后有两大类技术驱动因素。一个是以太网，另一个是处理器。

 

车载网络不断增长的带宽需求导致引入以太网，该以太网提供更高的带宽，并与交换网络相结合，与传统的车载通信技术（如CAN）相比，能够更高效地传输长消息、点对点通信等。CP虽然支持以太网，但主要是针对传统通信技术设计的，并且已经为此进行了优化，因此很难充分利用基于以太网的通信能力并从中获益。

 

类似地，随着车辆变得更加智能化，处理器的性能要求近年来也有了巨大的增长。多核处理器已经与CP一起使用，但对处理能力的需求不仅仅是多核。许多具有数十到数百个内核的核心处理器、GPGPU（General Purpose use of GPU）、FPGA和专用加速器正在出现，因为它们提供了比传统MCU高几个数量级的性能。核心数量的增加压倒了CP的设计，CP最初是为单核MCU设计的，尽管它可以支持多核。此外，随着计算能力的膨胀，即使在数据中心，能效也已经成为一个问题，对于这些智能ECU来说，能效更为重要。从半导体和处理器技术的角度来看，受Pollack规则的限制，在物理上不可能无限地增加处理器频率，扩展性能的唯一方法是使用多个（和多个）内核并并行执行。此外，每瓦特（performance-per-watt）的最佳性能是通过混合不同的计算资源实现的，如多核、协处理器、GPU、FPGA和加速器。这被称为异构计算——目前正被HPC（高性能计算）所利用——显然远远超出了CP的范围。

 

还值得一提的是，处理器和更快的通信都会产生综合效应。随着越来越多的处理元件像许多核心处理器一样被组合在一个芯片中，这些处理元件之间的通信比传统的ECU间通信快几个数量级，效率也越来越高。新型处理器互连技术（如Network-on-Chip（NoC））使这一点成为可能。芯片内更高的处理能力和更快的通信速度的综合效应也促使人们需要一种新的平台，该平台可以根据不断增长的系统需求进行扩展。

2.3自适应平台-特性

AP的特性由概述–智能电子技术驱动程序的前景（Overview – landscape of intelligent ECUs and Technology Drivers）阐述。这种情况不可避免地需要更多的计算能力，而技术趋势为满足这些需求提供了一个基准。然而，HPC在安全相关领域的应用虽然功率和成本效率也很重要，但其本身也带来了各种新的技术挑战。

为了解决这些问题，AP采用了各种传统上未被ECU充分利用的成熟技术，同时在AP实施中允许最大限度的自由利用创新技术。

2.3.1 C++

自上而下，应用程序可以用C++编程。它现在是软件行业和学术界在性能关键的复杂应用程序中开发新算法和应用软件的首选语言。如果使用得当，这将加快新算法的适应速度，提高应用程序开发效率。

2.3.2 SOA

为了支持复杂的应用程序，同时在处理分布和计算资源分配方面允许最大的灵活性和可伸缩性，AP遵循面向服务的体系结构（SOA）。SOA基于这样一个概念：一个系统由一组服务组成，其中一个可以依次使用另一个服务，以及根据需要使用一个或多个服务的应用程序。

SOA通常表现出系统的特性，AP也具有这种特性。例如，服务可能位于应用程序也在运行的本地ECU上，也可能位于也在运行另一个AP实例的远程ECU上。在这两种情况下，应用程序代码是相同的–通信基础设施将处理提供透明通信的差异。

看待这种体系结构的另一种方式是分布式计算，通过某种形式的消息传递进行通信。总的来说，所有这些都代表着相同的概念。这种基于消息传递和通信的体系结构还可以受益于快速和高带宽通信（如以太网）的兴起。

2.3.3并行处理

分布式计算本质上是并行的。当不同的应用程序使用不同的服务集时，SOA具有这一特性。提供并行处理能力的多核处理器和异构计算的先进性为利用计算能力来匹配固有的并行性提供了技术机会。因此，随着许多核心异构计算技术的发展，AP具有扩展其功能和性能的体系结构能力。事实上，硬件和平台接口规范只是等式的一部分，操作系统/虚拟机监控程序技术和开发工具（如自动并行化工具）的进步也至关重要，这将由AP提供商和行业/学术生态系统来实现。AP的目标也是适应这些技术。

2.3.4利用现有标准

重新发明轮子是没有意义的，特别是当涉及到规范而不是实现时。如C++中所述，AP采取了重用和调整现有开放标准的策略，以促进AP自身的更快发展，并从现有标准的生态系统中获益。因此，开发AP规范的一个关键重点是不要随意引入现有标准已经提供的新替换功能。例如，这意味着不会仅仅因为现有标准提供了所需的功能而随意引入新接口，但该接口表面上并不容易理解。

2.3.5安全和安保

AP目标系统通常需要一定程度的安全和安保，可能是最高级别。新概念和新技术的引入不应削弱这些要求，尽管实现这些要求并非微不足道。为了应对这一挑战，AP结合了架构、功能和程序方法。该体系结构基于SOA的分布式计算，它固有地使每个组件更加独立，没有意外干扰，有助于实现安全和安全的专用功能，以及诸如C++编码指南等指导方针，有利于像C++那样安全和安全地使用复杂的语言。

2.3.6计划动态 Planned dynamics

AP支持应用程序的增量部署，动态管理资源和通信以减少软件开发和集成的工作量，从而缩短迭代周期。增量部署还支持探索性软件开发阶段。

 

对于产品交付，AP允许系统集成商限制动态行为，以降低不必要或不利影响的风险，从而进行安全鉴定。应用程序的动态行为将受到执行清单中所述约束的限制。多个应用程序清单的相互作用可能会在设计时造成这种情况。然而，在执行时，资源和通信路径的动态分配仅可能以定义的方式进行，例如在配置的范围内。

 

AP的实现可进一步从软件配置中移除动态功能以供生产使用。计划动态的示例可能是：

 

•服务发现过程的预先确定

•仅在启动阶段限制动态内存分配

•除基于优先级的调度外，公平调度策略

•将进程固定分配给CPU核心

•仅访问文件系统中预先存在的文件

•应用程序使用AP API的限制

•仅执行经过身份验证的代码

 

2.3.7敏捷

虽然没有直接反映在平台功能中，但AP旨在适应不同的产品开发过程，特别是基于敏捷的过程。对于基于敏捷的开发，至关重要的是系统的底层体系结构具有增量可伸缩性，并有可能在部署后更新系统。AP的体系结构应该允许这一点。作为概念证明，AP规范本身和演示器（AP的演示性实现）都是使用Scrum开发的。

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

如前几节所述，AP不会取代IVI/COTS中的CP或非AUTOSAR平台。相反，它将与这些平台和外部后端系统（如路边基础设施）交互，形成一个集成系统（图2-1不同平台的示例性部署，图2-2 AP和CP的示例性交互）。例如，CP已经包含了一些IP/IP协议，在其他协议中，AP也支持这些协议。

 

图2-1不同平台的示例性部署

 

 

 

图2-2 AP和CP的示例性交互

 

2.5规范范围

AP定义了运行时系统架构、平台的组成以及它提供的功能和接口。它还定义了用于开发此类系统的机器可读模型。规范应提供使用平台开发系统的必要信息，以及实现平台本身需要满足的条件。