关于AP AUTOSAR 的核心知识点

1.背景

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

2.技术驱动因素

①以太网

车载网络不断增长的带宽要求导致引入了以太网。

与传统的车载通信技术（例如CAN）相比，以太网具有高带宽并具有交换网络、可以更有效地传输长消息、实现点对点通信等 。

CP尽管支持以太网，但主要是针对传统通信技术而设计的，并且已经为此进行了优化，因此很难充分利用基于以太网的通信功能并从中受益。

②处理器

随着汽车的智能化程度越来越高，处理器的性能要求也大大提高。原本为单核MCU设计的CP虽然可以支持多核，但它设计起来却力不从心。

随着越来越多的处理元件（例如多核处理器）被组合在一个芯片中，这些处理元件之间的通信变得比传统的ECU间通信更快，更高效新型的处理器互连技术（如片上网络NoC）使这成为可能。

更大的处理能力和更快的芯片内通信速度的这种综合效果，也促使人们需要一种新的平台，以适应不断增长的系统要求。

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不同平台的示例性部署

图2AP和CP的示例性交互

1.逻辑视图

① ARA

图1表示的是AP的体系结构。从图中可以看出以下几点：

1. 自适应应用程序（AA）在自适应应用程序的AUTOSAR运行时（ARA）之上运行。

2. ARA由功能群集提供的应用程序接口组成，这些群集属于Adaptive Platform Foundation或Adaptive Platform Services。Adaptive Platform Foundation提供AP的基本功能，而Adaptive Platform Services提供AP的平台标准服务。

3. 任何AA也可以向其他AA提供服务，在图中以非平台服务形式说明。

从AA的角度来看，功能集群的接口（无论是Adaptive Platform Foundation的接口还是Adaptive Platform Services的接口）都无所谓——它们仅提供指定的C ++接口或AP将来可能支持的任何其他语言的接口。

另外，请注意，在ARA接口下，包括在AA上下文中调用的ARA库，可以使用ARA以外的其他接口来实现AP规范，这取决于AP实现的设计。

图3AP架构逻辑视图

②语言绑定，C++标准库和POSIX API

这些API是基于C ++，并且C ++标准库也作为ARA的一部分提供。

关于OS API，AA只可使用PSE51接口

建议不要将C ++标准库线程接口与本机PSE51线程接口混合使用，以避免复杂化。

但是，C ++标准库没有涵盖所有PSE51功能，例如设置线程调度策略。在这种情况下，可能需要同时使用两个接口。

③ 应用程序启动和关闭

应用程序的生命周期由执行管理（EM）管理。

应用程序的加载/启动是通过使用EM的功能进行管理的，并且需要在系统集成时或运行时进行适当的配置才能启动应用程序。

实际上，从EM的角度来看，所有功能集群都是应用程序，除了EM本身以外，它们也以相同的方式启动。图2应用程序说明了AP内部和AP上不同类型的应用程序。

图4应用程序类型

EM不会决定应用程序的启动时间和终止时间。

应用程序的启动时间和终止时间是状态管理（SM）控制的，SM是一种特殊的FC，它根据系统的设计命令EM，仲裁不同的状态，从而控制整个系统的行为。

SM还与其他FC交互以协调整体机器行为。SM应该仅使用标准ARA接口来维护不同AP堆栈实现之间的可移植性。

④应用程序交互

AA之间没有直接进行交互的接口，不能通过IPC（进程间通）进行直接交互。

AA之间要想交互需要通过通信管理（CM）

AA可以直接调用POSIX OS的PSE51接口，但是不能调用POSIX OS的非PSE51接口

CM还为Machine内和Machine间提供面向服务的通信

注意：其他ARA接口可能在内部触发AA之间的交互，但是，这不是显式的通信接口，而只是相应ARA接口提供的功能的副产品

⑤ 非标准接口

AA和功能集群可以使用任何非标准接口，只要它们不与标准AP功能冲突，并且它们符合项目的安全性要求即可。

除非它们是纯的应用程序本地运行时库，否则应注意使此类使用最少，因为这将影响软件在其他AP实现上的可移植性。

2.物理视图

在此讨论AP的物理体系结构。

注意：本节中的大多数内容仅用于说明目的，并且不构成AP的正式要求规范。

①操作系统，进程和线程

每个AA被实现为一个独立的进程，具有自己的逻辑内存空间和名称空间。

请注意，单个AA可以包含多个进程，并且可以将其部署到单个AP Instance上或分布在多个AP Instance上。

每个进程都由OS从可执行文件实例化。可以从单个可执行文件实例化多个进程。同样，AA可以构成多个可执行文件。

功能集群通常也被实现为进程。功能集群也可以用单个过程或多个（子）过程来实现。自适应平台服务和非平台服务也被实现为进程。

所有这些进程可以是单线程进程或多线程进程。但是，根据进程所属的逻辑层，它们可以使用的OS API有所不同。如果它们是运行在ARA之上的AA，则它们只能使用PSE51。

如果该进程是功能集群之一，则可以自由使用任何可用的OS接口。

综上所述，从操作系统的角度来看，AP和AA只是形成一组进程，每个进程包含一个或多个线程——这些进程之间没有区别。这些进程确实通过IPC或任何其他可用的OS功能相互交互。请注意，AA进程可能不会直接使用IPC，而只能通过ARA进行通信。

② 基于库或基于服务的功能集群实施

如图1 AP体系结构逻辑视图中所示，功能集群可以是Adaptive Platform Foundation模块或Adaptive Platform Service。如前所述，这些通常都是进程。为了使它们与AA（也是进程）交互，它们需要使用IPC。有两种替代设计可以实现此目的。

一种是“基于库”的设计，其中由功能集群提供并链接到AA的接口库直接调用IPC。

另一个是“基于服务”的设计，该进程使用通信管理功能，并且具有链接到AA的Server Proxy库。Proxy库调用通信管理接口，该接口在AA进程和服务器进程之间协调IPC。请注意，AA是仅通过通讯管理直接执行IPC，还是通过Proxy库与Server 直接IPC混合，由实施定义。

选择功能性集群设计的一般指导原则是，如果仅在AP实例中本地使用它，则基于库的设计会更合适，因为它更简单且效率更高。

如果以分布式方式从其他AP实例中使用它，则建议采用基于服务的设计，因为无论客户端AA和服务的位置如何，通信管理都将提供透明的通信。顾名思义，属于Adaptive Platform Foundation的功能集群是“基于库的”，而Adaptive Platform Services是“基于服务的”。

注意：允许FC的实现以库的形式实现，即：AA和FC之间的交互将是常规进程调用，而不是如前所述基于IPC。

③ 功能集群之间的交互

功能集群之间的一种典型交互模型是使用功能集群的受保护接口来提供实现功能集群的特殊功能所需的特权访问。

从AP18-03开始，引入了功能间群集（IFC）接口的新概念。它描述了FC提供给其他FC的接口。注意，它不是ARA的一部分，也不构成AP实施的正式规范要求。这些接口在相应的FC SWS的附件中进行了描述。

④ 机器/硬件

AP将运行在其上的硬件视为一台Machine。其背后的原理是获得一致的平台视图，而不考虑可能使用的任何虚拟化技术。该Machine可能是一台真正的物理Machine，一台全虚拟化的Machine，一台半虚拟化的OS，一个OS级虚拟化的容器或任何其他虚拟化环境。

在硬件上，可以有一个或多个Machine，并且在一台Machine上仅运行一个AP实例。通常认为，该“硬件”包含一个芯片，可容纳一台或多台Machine。但是，如果AP允许的话，也有可能多个芯片组成一台Machine。

3.方法论和Manifest

对功能应用程序的分布式，独立和敏捷开发的支持需要一种标准化的开发方法。

AUTOSAR自适应方法论涉及工作产品的标准化，用于描述诸如服务，应用程序，Machine及其配置之类的工件。以及定义这些工作产品应如何交互以实现针对自适应平台产品开发所需的各种活动的设计信息交换的相应任务。

图3给出了如何实施自适应方法的概述草案。

图5AP开发流程

4.Manifest

Manifest代表一段AUTOSAR模型描述，该描述是为了支持AUTOSAR AP产品的配置而创建的，并且会上载到AUTOSAR AP产品中，并可能与其他包含Manifest文件的可执行代码的工件（如二进制文件）结合使用。

Manifest的使用仅限于AUTOSAR AP。但是，并不是说在针对AUTOSAR AP的开发项目中生成的所有ARXML都会自动被视为清单。

一辆典型的汽车很可能还配备了许多在AUTOSAR CP上开发的ECU，因此，整个汽车的系统设计必须同时涵盖两个方面——在AUTOSAR CP上构建的ECU和在AUTOSAR AP上创建的ECU。

在应用程序设计时，有必要将术语Manifest的定义细分为三个不同的分区：

应用设计

这种描述指定了所有与设计相关的方面，这些方面适用于为AUTOSAR AP创建应用程序软件。不一定需要将其部署到自适应平台Machine，但是应用程序设计有助于在执行Manifest和服务 Instance Manifest中定义应用程序软件的部署。

执行Manifest

这种Manifest用于指定在AUTOSAR AP上运行的应用程序的与部署相关的信息。执行Manifest与实际的可执行代码捆绑在一起，以支持将可执行代码集成到计算机上。

服务InstanceManifest此类Manifest用于根据基础传输协议的要求指定如何配置面向服务的通信。服务Instance Manifes与实际的可执行代码捆绑在一起，该可执行代码实现了面向服务的通信的相应用法。

Machine Manifest这种Manifest应该描述与部署相关的内容，这些内容仅适用于运行AUTOSAR AP的基础计算机（即，该计算机上没有运行任何应用程序）的配置。Machine Manifest与用于建立AUTOSAR AP实例的软件捆绑在一起。

不同种类的Manifest的定义（和用法）之间的时间划分得出这样的结论：在大多数情况下，将使用不同的物理文件来存储这三种Manifest的内容。

除了应用程序设计和不同种类的Manifest外，AUTOSAR方法论还支持系统设计，它有可能在一个单一模型中描述将在系统中使用的两个AUTOSAR平台的软件组件。

不同的AUTOSAR平台的软件组件可以以面向服务的方式相互通信。但是也有可能描述信号到服务的映射，以在面向服务的通信与基于信号的通信之间建立桥梁。

5.应用设计

应用程序设计描述了所有与设计相关的建模，这些建模适用于为AUTOSAR AP创建应用程序软件。应用程序设计侧重于以下方面：

1)用于对软件设计和实现的信息进行分类的数据类型

2) Service Interface是面向服务的通信的关键要素

3) 定义应用程序如何访问面向服务的通信

4) Persistency接口是访问持久性数据和文件的关键要素

5) 定义应用程序如何访问持久性存储

6)定义应用程序如何访问文件

7) 定义应用程序如何访问加密软件

8) 定义应用程序如何访问平台运行状况管理

9) 定义应用程序如何访问Time Base

10) 序列化属性，用于定义如何序列化数据以在网络上传输的特征

11) REST Service Interface是通过REST模式与Web服务进行通信的关键要素

12) Client 和Server 功能的描述

13)对应用程序进行分组，以简化软件的部署。

在应用程序设计中定义的工件独立于应用程序软件的特定部署，因此可以简化针对不同部署场景的应用程序实现的重用。

6.执行Manifest

执行Manifest的目的是提供将应用程序实际部署到AUTOSAR AP所需的信息。

总体思路是保持应用程序软件代码与部署方案尽可能独立，以增加应用程序软件可以在不同部署方案中重用的几率。

通过执行Manifest，可以控制应用程序的实例化，因此可以：

1)在同一台计算机上多次实例化同一应用程序软件，或者

2)将应用程序软件部署到多台计算机上，并在每台计算机上实例化应用程序软件。

执行Manifest集中于以下方面：

1)启动配置，定义应如何启动应用程序实例。启动包括启动选项和访问角色的定义。每次启动可能取决于Machine状态和/或Function Groups状态。

2)资源管理，尤其是资源组分配。

7.服务Instance Manifest

在网络上实现面向服务的通信需要特定于所使用的通信技术（例如SOME / IP）的配置。由于通信基础结构在服务的提供者和请求者上的行为相同，因此服务的实现必须在双方上都兼容。

服务Instance Manifest集中于以下方面：

1) Service Interface部署，用于定义如何在特定的通信技术上表示服务。

2) Service Instance 部署，以为特定的提供和所需的服务实例定义通信技术所需的凭据。

3) E2E保护的配置

4) Safety保护的配置

5) 日志和跟踪的配置

8.Machine Manifest

Machine Manifest允许配置运行在特定硬件（机器）上的实际自适应平台实例。

Machine Manifest 集中于以下方面：

1)配置网络连接并定义网络技术的基本凭据（例如，对于以太网，这涉及设置静态IP地址或定义DHCP）。

2) Service Discovery技术的配置（例如，对于SOME / IP，这涉及要使用的IP端口和IP多播地址的定义）。

3)使用的Machine状态的定义

4)使用的Function Group的定义

5)自适应平台功能集群实现的配置（例如，操作系统提供具有特定权限的OS用户列表）。

6)加密平台模块的配置

7)平台健康管理的配置

8)时间同步的配置

9) 可用硬件资源的文档（例如，可用的RAM数量；可用的处理器核数量）

1.概述

操作系统（OS）负责Adaptive Platform上所有应用程序的运行时调度，资源管理（包括策略内存和时间限制）以及进程间通信。

执行管理负责平台的初始化，操作系统与执行管理协同工作，执行应用程序的启动和关闭。

Adaptive Platform没有为高性能处理器指定新的操作系统。而是定义了操作系统接口（OSI），供自适应应用程序使用。

OSI规范包含作为ARA（自适应应用程序的标准应用程序接口）一部分的应用程序接口。OS本身可能会提供执行管理启动应用程序所需的其他接口，例如创建进程。但是，提供此类功能的接口尤其不能作为ARA的一部分使用，并且应定义为与平台实现有关。

OSI提供C和C ++接口。对于C程序，应用程序的主要源代码业务逻辑包括POSIX标准中定义的C函数调用，即IEEE1003.13 [1]中定义的PSE51。在编译期间，编译器会确定平台操作系统中的哪个C库提供了这些C函数，并且应在运行时链接应用程序可执行文件。对于C ++程序，应用程序软件组件的源代码包括在C ++标准及其标准C ++库中定义的函数调用。

2.POSIX

市场上有几种操作系统，例如 提供POSIX兼容接口的Linux。但是，与平台Service和Foundation相比，应用程序对操作系统使用会更受限制。

一般的假设是，Application-Level类型的应用程序应使用PSE51作为OS接口，而Platform-Level类型的应用程序则可以使用完整的POSIX。

如果Application-Level类型的应用程序需要更多功能，这些功能将取自POSIX标准，并且在可能的情况下不会重新指定。

Adaptive Platform Foundation和Adaptive Platform Services功能的实现可以使用其他POSIX调用。特定调用的使用将对实施者开放，并且不会标准化。

3.调度

操作系统提供了多线程和多进程支持。标准调度策略是SCHED_FIFO和SCHED_RR，它们由POSIX标准定义。

允许使用其他调度策略（例如SCHED_DEADLINE或任何其他特定于操作系统的策略），但要注意的是，这可能无法在不同的AP产品上实现移植。

4.内存管理

支持多进程的原因之一是要实现不同功能集群和AA之间的“无干扰”。

OS的多进程支持迫使每个进程位于一个独立的地址空间中，并与其他进程分开并加以保护。同一可执行文件的两个Instance在不同的地址空间中运行，因此它们可以在启动时共享相同的入口点地址和代码以及数据值，但是，数据将位于内存中的不同物理页中。

5.设备管理

设备管理将在POSIX PSE51接口下提供。有关详细信息，请参阅POSIX规范。

1.概览

执行管理负责系统执行管理的所有方面，包括平台初始化和应用程序的启动/关闭。

执行管理与操作系统结合使用，以执行应用程序的运行时调度。

2.系统启动

启动计算机后，将首先初始化操作系统，然后启动执行管理作为操作系统的初始过程之一。然后，执行管理将启动Adaptive Platform Foundation的其他功能集群和Application-Level类型的应用程序。

Adaptive Platform Foundation启动并运行后，执行管理将继续启动Adaptive Applications。Platform-Level类型的应用程序和Application-Level类型的应用程序的启动顺序由执行管理根据Machine Manifest和执行Manifest信息确定。

图6AP启动顺序

执行管理（可选）支持经过身份验证的启动，其中从信任“锚”开始，在保持信任链的同时启动Adaptive Platform。在经过身份验证的启动过程中，Execution Management会验证应用程序的真实性和完整性，如果检测到违规，将阻止其执行。

通过这些机制，可以建立可信平台。

3.执行管理责任

执行管理负责Adaptive Platform执行管理和应用程序执行管理的所有方面，包括：

① 平台生命周期管理

执行管理是Adaptive Platform启动阶段的一部分，它负责对Adaptive Platform和已部署的应用程序进行初始化。

②应用程序生命周期管理

执行管理负责部署的应用程序的有序启动和关闭。执行管理根据Machine Manifest和执行Manifest中的信息确定已部署应用程序的集合，并根据声明的应用程序依赖性导出启动/关闭的顺序。根据Machine状态和Function Group状态，已部署的应用程序会在Adaptive Platform启动或更高版本期间启动，但是，由于许多应用程序将为其他应用程序提供服务，因此，预计不会所有的Application立即开始活动工作。

执行管理不负责应用程序的运行时调度，因为这是操作系统的事。

但是，执行管理负责OS的初始化/配置，以使其能够根据执行管理从Machine Manifest和Execution Manifest中提取的信息执行必要的运行时调度。

4.确定性执行

确定性执行提供了一种机制，使得使用给定输入数据集进行的计算始终在限定时间内产生一致的输出。执行管理区分时间和数据确定性。前者指出输出总是在截止日期之前产生的，而后者则指从相同的输入数据集和内部状态产生相同的输出。

执行管理提供的支持集中于数据确定性，因为它假定时间确定性已通过提供足够的资源来处理。对于数据确定性，执行管理提供了DeterministicClient API，以支持对内部流程的控制，确定性工作人员池，激活时间戳和随机数。对于软件锁步，DeterministicClient与可选的软件锁步框架进行交互，以确保冗余执行的流程具有相同的行为。DeterministicClient与Communication Management进行交互，以使数据处理与周期激活同步。

图7 Deterministic Client说明了DeterministicClient支持的API及其与应用程序的交互

5.资源限制

自适应平台允许在同一台机器上执行多个自适应应用程序，因此确保不受干扰是系统属性。因此，行为不当的自适应应用程序应受到影响其他应用程序的能力的限制，例如，应避免某个应用程序消耗比指定时间更多的CPU时间，因为这可能对其他应用程序的正常运行产生潜在影响。

执行管理通过配置一个或多个分配了应用程序进程的ResourceGroup来支持不受干扰。然后，可以为每个ResourceGroup分配CPU时间或内存限制，以限制应用程序的可用资源。

6.应用程序恢复

执行管理负责流程启动/停止的状态相关管理，因此它必须具有启动和停止流程的特殊权限。平台运行状况管理会监视进程，并可以触发恢复操作，以防任何进程的行为不在指定参数之内。集成商根据平台运行状况管理的软件体系结构要求定义恢复操作，并在执行清单中进行配置。

7.受信任的平台

为了保证系统的正确功能，确保平台上执行的代码具有合法来源至关重要。保留此属性使集成商可以构建受信任的平台。

实施受信任平台的系统的关键属性是信任“锚”（也称为信任根）。信任“锚”通常被实现为存储在安全环境中的公钥。在不可修改的永久内存或HSM中。

系统设计者负责确保至少系统以信任“锚”开始，并保持信任直到启动执行管理。根据系统设计者选择的建立信任链的机制，可能已在系统启动时检查了整个系统的完整性和真实性。但是，如果系统设计者仅确保已经检查过已执行的软件的完整性和真实性，则执行管理在接管系统控制权时将接管继续信任链的责任。在这种情况下，系统集成商负责确保正确配置了执行管理。

从信任“锚”向操作系统和自适应平台传递信任的一个示例（即建立信任链）可能看起来像这样：信任“锚”-根据定义是一个真实的实体-在启动引导程序之前对引导程序进行身份验证。在引导过程的每个后续步骤中，应首先对要启动的可执行文件进行身份验证。真实性检查应由已经过身份验证的实体完成，例如，真实性检查可以通过以下方式完成：例如，由先前启动的可执行文件或某些外部实体（例如HSM）决定。

操作系统可靠启动后，它将启动执行管理作为其第一个过程。在启动执行管理之前，操作系统应确保执行管理的真实性已由已经过身份验证且因此可信赖的实体进行了验证。

注意：如果未通过Trust Anchor本身的功能（根据定义是真实的）检查身份验证，则在应用该软件之前必须对用于验证可执行文件真实性的软件进行身份验证。例如，如果将使用Crypto API来验证可执行文件的身份验证，则在使用Crypto API本身之前，必须先由某些受信任实体对Crypto API进行身份验证。

执行管理现在负责启动自适应应用程序，然后再启动它们。但是，存在不止一种可能性来验证可执行代码的完整性和真实性。在SWS_ExecutionManagement中，提供了完成此任务的可能机制的列表。