# AUTOSAR_EXP_PlatformDesign_R2011
## 1 本文档引言
### 1.1 内容
本规范描述了AUTOSAR自适应平台（AP）的设计。本文档旨在提供AP的概述，但并非详述AP设计的所有元素。其目的是提供AP的总体设计以及针对AP用户和AP实现者的关键概念。
本文档组织结构如下：首先从技术范围与方法开始，提供AP的一些背景信息，随后是描述AP逻辑视图和物理视图的架构章节。接着是独立的方法论与清单章节以及所有功能集群章节，这些是AP的功能单元，每个章节都包含其概述和关键概念介绍。
对所解释概念的详细规范及讨论，定义在相关的RS、SWS、TR和EXP文档中。
### 1.2 预备阅读
本文档是AUTOSAR的高级概念文档之一。有用的预备阅读材料包括[1] [2] [3]。
### 1.3 与其他AUTOSAR规范的关系
请参阅内容和预备阅读部分。
## 2 技术范围与方法
### 2.1 概述 - 智能ECU的图景
传统上，ECU主要实现替代或增强机电系统的功能。这些深度嵌入式ECU中的软件根据输入信号以及来自连接至车辆网络的其他ECU的信息来控制电输出信号。许多控制软件是为目标车辆设计和实现的，并且在车辆生命周期内不会显著改变。
新的车辆功能，如高度自动化驾驶，将把高度复杂且计算资源需求大的软件引入车辆，并且这些软件必须满足严格的完整性和安全性要求。此类软件实现环境感知、行为规划等功能，并将车辆集成到外部后台和基础设施系统中。由于外部系统的发展或功能的改进，车辆中的软件需要在车辆生命周期内进行更新。
AUTOSAR经典平台（CP）标准满足了深度嵌入式ECU的需求，而上述ECU的需求则无法满足。因此，AUTOSAR规定了第二个软件平台，即AUTOSAR自适应平台（AP）。AP主要提供高性能计算和通信机制，并提供灵活的软件配置，例如支持通过空中接口进行软件更新。为CP特别定义的功能，如访问电信号和汽车专用总线系统，可以集成到AP中，但不是标准化的重点。
### 2.2 技术驱动因素
主要有两大技术驱动因素：一个是以太网，另一个是处理器。
车载网络不断增长的带宽需求导致以太网的引入，与传统的车载通信技术（如CAN）相比，以太网提供了更高的带宽，并通过交换网络，能够更有效地传输长消息、点对点通信等。尽管CP支持以太网，但它主要是为传统通信技术设计的，并已针对此类技术进行了优化，因此很难充分利用以太网通信的能力并获得收益。
同样，近年来随着车辆变得越来越智能，对处理器的性能要求也急剧增长。多核处理器已在CP中使用，但对处理能力的需求不仅仅需要多核。具有数十到数百个核的众核处理器、GPGPU、FPGA以及专用加速器正在兴起，
因为它们提供比传统MCU高几个数量级的性能。核心数量的增加使最初为单核MCU设计的CP（尽管它支持多核）难以应对。此外，随着计算能力的膨胀，即使在数据中心，能效也已成为一个问题，而对于这些智能ECU来说，这实际上更为重要。从半导体和处理器技术的角度来看，受制于Pollack规则，无限提高处理器频率在物理上是不可能的，提升性能的唯一方法是采用多个（和许多）核并并行执行。此外，众所周知，最佳的性能功耗比是通过混合使用不同的计算资源（如众核、协处理器、GPU、FPGA和加速器）来实现的。这被称为异构计算——目前在HPC（高性能计算）中被广泛利用——这无疑远远超出了CP的范围。
值得一提的是，处理器和更快的通信之间存在联合效应。随着众核处理器等更多处理单元被集成到单个芯片中，这些处理单元之间的通信速度比传统的ECU间通信快几个数量级，效率也更高。新型处理器互连技术（如片上网络NoC）使这成为可能。更多的处理能力和芯片内更快的通信的这种联合效应也促使需要一个能够随着系统需求不断增长而扩展的新平台。
### 2.3 自适应平台 - 特性
AP的特性由概述 - 智能ECU的图景和技术驱动因素所塑造。该图景不可避免地要求显著更高的计算能力，而技术趋势提供了满足此类需求的基础。然而，在安全和成本效率同样重要的领域进行高性能计算，其本身就带来了各种新的技术挑战。
为了应对这些挑战，AP采用了传统上未被ECU充分利用的各种成熟技术，同时允许AP实现的最大自由度，以利用创新技术。
#### 2.3.1 C++
从上到下，应用程序可以用C++编程。在软件行业和学术界，它已成为性能关键型复杂应用中开发新算法和应用软件的首选语言。如果使用得当，这应能更快地适应新算法，并提高应用程序开发效率。
#### 2.3.2 服务导向架构（SOA）
为了支持复杂的应用程序，同时允许处理分布和计算资源分配的最大灵活性和可扩展性，AP遵循服务导向架构（SOA）。SOA基于这样一个概念：一个系统由一组服务组成，一个服务可以使用另一个服务，应用程序根据其需要使用一个或多个服务。
SOA经常表现出系统之系统的特性，AP也具有此特性。例如，一个服务可能驻留在应用程序也运行的本地ECU上，或者它可以在远程ECU上，该远程ECU也运行另一个AP实例。在这两种情况下，应用程序代码是相同的——通信基础设施将处理差异，提供透明通信。看待此架构的另一种方式是将其视为分布式计算，通过某种形式的消息传递进行通信。大体上，这些都代表了相同的概念。这种基于消息传递、通信的架构也可以从快速、高带宽通信（如以太网）的兴起中受益。
#### 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 规划的动态性
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已经包含了SOME/IP，AP也支持该协议以及其他一些协议。
图 2-1 不同平台的示例性部署
图 2-2 AP 和 CP 的示例性交互
### 2.5 规范范围
AP定义了运行时系统架构、平台的构成以及它提供的功能和接口。它还定义了在此类系统开发中使用的机器可读模型。该规范应提供使用该平台开发系统所需的信息，以及实现平台本身需要满足的条件。
## 3 架构
### 3.1 逻辑视图
#### 3.1.1 ARA
图3-1 AP架构逻辑视图展示了AP的架构。自适应应用程序（AA）运行在ARA（AUTOSAR自适应应用程序运行时环境）之上。ARA由功能集群提供的应用程序接口组成，这些功能集群属于自适应平台基础或自适应平台服务。自适应平台基础提供AP的基本功能，自适应平台服务提供AP的平台标准服务。任何AA也可以向其他AA提供服务，图中显示为非平台服务。
从AA的角度来看，功能集群（无论是自适应平台基础还是自适应平台服务）的接口是无差别的——它们只提供指定的C++接口或AP未来可能支持的任何其他语言绑定。底层确实存在差异。同时注意，在ARA接口之下，包括在AA上下文中调用的ARA库，可能使用除ARA之外的接口来实现AP的规范，这取决于AP实现的设计。
图 3-1 AP 架构逻辑视图
请注意，图3-1 AP架构逻辑视图包含当前AP版本未包含的功能集群，目的是为了提供更好的整体结构概念。AP的未来版本可能会添加此处未显示的更多新功能集群。
#### 3.1.2 语言绑定、C++标准库和POSIX API
这些API的语言绑定基于C++，C++标准库也作为ARA的一部分提供。关于操作系统API，只有PSE51接口（POSIX标准的单进程配置文件）作为ARA的一部分提供。选择PSE51是为了为现有POSIX应用程序提供可移植性，并实现应用程序间的免于干扰。
注意，C++标准库包含许多基于POSIX的接口，包括多线程API。建议不要混用C++标准库线程接口和原生PSE51线程接口，以避免复杂化。不幸的是，C++标准库并未涵盖所有PSE51功能，例如设置线程调度策略。在这种情况下，可能需要联合使用两种接口。
#### 3.1.3 应用程序启动与关闭
应用程序的生命周期由执行管理（EM）管理。应用程序的加载/启动通过使用EM的功能进行管理，并且需要在系统集成时或运行时进行适当的配置才能启动应用程序。事实上，从EM的角度来看，所有功能集群都是应用程序，它们也以相同的方式启动，EM本身除外。图3-2 应用程序说明了AP内部及之上的不同类型的应用程序。
图 3-2 应用程序
注意，启动或终止应用程序的决定并非由EM做出。一个名为状态管理（SM）的特殊功能集群是控制器，它根据系统设计命令EM，仲裁不同的状态，从而控制整个系统的行为。由于这里的系统指的是AP及其应用程序运行的整个机器，其内部行为及实现因此是项目特定的。SM还与其他功能集群交互，以协调整个机器的行为。SM应仅使用标准ARA接口，以保持在不同AP堆栈实现之间的可移植性。
#### 3.1.4 应用程序交互
关于AA之间的交互，PSE51不包含IPC（进程间通信），因此没有直接的接口用于AA之间交互。通信管理（CM）是唯一的显式接口。CM还为机器内部和机器之间提供服务导向通信，这对应用程序是透明的。CM处理服务请求/响应的路由，无论服务和客户端应用程序的拓扑部署如何。注意，其他ARA接口可能在内部触发AA之间的交互，然而，这不是一个显式的通信接口，而仅仅是各自ARA接口提供功能的副产品。
#### 3.1.5 非标准接口
AA和功能集群可以使用任何非标准接口，前提是它们不与标准AP功能冲突，并且符合项目的安全性/防护性要求。除非是纯粹的应用程序本地运行时库，否则应谨慎使用，并将此类使用降到最低，因为这会影响软件在其他AP实现上的可移植性。
### 3.2 物理视图
这里讨论AP的物理架构。注意，本节大部分内容仅供说明，不构成AP的正式需求规范，因为AP的内部是实现定义的。任何对AP实现的正式要求都已明确陈述。作为额外的信息来源，请参考EXP_SWArchitecture，它更详细地描述了AP的内部架构。
#### 3.2.1 操作系统、进程和线程
AP操作系统需要提供多进程POSIX操作系统能力。每个AA实现为一个独立的进程，拥有自己的逻辑内存空间和命名空间。注意，单个AA可能包含多个进程，并且可以部署到单个AP实例或分布在多个AP实例上。从模块组织的角度来看，每个进程是由操作系统根据可执行文件实例化的。多个进程可以从单个可执行文件实例化。此外，AA可能由多个可执行文件构成。
功能集群通常也实现为进程。一个功能集群也可以用单个进程或多个子进程实现。自适应平台服务和非平台服务也实现为进程。
所有这些进程可以是单线程进程或多线程进程。然而，它们可以使用的操作系统API取决于进程所属的逻辑层。
如果它们是运行在ARA之上的AA，那么它们应仅使用PSE51。如果一个进程是功能集群之一，它可以自由使用任何可用的操作系统接口。
总之，从操作系统的角度来看，AP和AA仅仅构成一组进程，每个进程包含一个或多个线程——这些进程之间没有区别，尽管由AP的实现来决定提供何种分区。这些进程通过IPC或任何其他可用的操作系统功能进行交互。注意，AA进程可能无法直接使用IPC，只能通过ARA进行通信。
#### 3.2.2 基于库或基于服务的功能集群实现
如图3-1 AP架构逻辑视图所示，功能集群可以是自适应平台基础模块或自适应平台服务。如前所述，这些通常都是进程。为了它们与同样作为进程的AA进行交互，需要使用IPC。有两种替代设计可以实现这一点。一种是“基于库”的设计，其中由功能集群提供并链接到AA的接口库直接调用IPC。另一种是“基于服务”的设计，其中进程使用通信管理功能，并有一个服务器代理库链接到AA。代理库调用通信管理接口，通信管理协调AA进程和服务器进程之间的IPC。注意，AA是仅直接与通信管理执行IPC，还是通过代理库与服务器混合直接IPC，这是实现定义的。
为功能集群选择设计的一般准则是：如果仅在AP实例本地使用，基于库的设计更合适，因为它更简单且可能更高效。如果以分布式方式从其他AP实例使用，建议采用基于服务的设计，因为通信管理提供透明通信，无论客户端AA和服务位于何处。属于自适应平台基础的功能集群是“基于库”的，而自适应平台服务正如其名所示是“基于服务”的。
最后，注意，只要满足功能集群已定义的RS和SWS，允许功能集群的实现不设进程，而是以库的形式在AA进程的上下文中运行。在这种情况下，AA和功能集群之间的交互将是常规的过程调用，而不是之前描述的基于IPC的方式。
#### 3.2.3 功能集群之间的交互
通常，功能集群之间可以以AP实现特定的方式进行交互，因为它们不受限于ARA接口（如限制IPC使用的PSE51）。它们确实可以使用其他功能集群的ARA接口，这些是公共接口。功能集群之间一种典型的交互模型是使用功能集群的保护接口，
以提供实现功能集群特殊功能所需的特权访问。
此外，从AP18-03开始，引入了功能集群间（IFC）接口的新概念。它描述了一个功能集群提供给其他功能集群的接口。注意，它不是ARA的一部分，也不构成对AP实现的正式规范要求。提供这些接口是为了通过阐明功能集群之间的交互来促进AP规范的开发，并且它们也可能为AP规范的用户提供更好的AP架构视图。这些接口在各自功能集群SWS的附录中描述。
#### 3.2.4 机器/硬件
AP将其运行的硬件视为一台机器。其背后的原理是，无论是否使用任何虚拟化技术，都能实现一致的平台视图。机器可能是一台真实的物理机、一台全虚拟化机器、一个半虚拟化操作系统、一个操作系统级虚拟化容器或任何其他虚拟化环境。
在硬件上，可以有一台或多台机器，并且一台机器上只运行一个AP实例。通常假设这个“硬件”包括单个芯片，承载一个或多个机器。然而，如果AP实现允许，多个芯片也可以组成一台机器。
### 3.3 方法论与清单
对分布式、独立和敏捷的功能应用程序开发的支持需要标准化的开发方法。AUTOSAR自适应方法论涉及工作产品的标准化，用于描述服务、应用程序、机器及其配置等工件；以及相应的任务，定义这些工作产品如何交互，以实现为自适应平台开发产品所需的各种活动的设计信息交换。图3-3展示了自适应方法论可能如何实现的草案概述。有关这些步骤的详细信息，请参阅[3]。
图 3-3 AP 开发工作流
### 3.4 清单
清单代表了一种AUTOSAR模型描述，其创建目的是为了支持AUTOSAR AP产品的配置，并被上传到AUTOSAR AP产品中，可能与其他工件（如包含可执行代码的二进制文件）结合，清单适用于这些可执行代码。
清单的使用仅限于AUTOSAR AP。然而，这并不意味着在以AUTOSAR AP为目标的开发项目中产生的所有ARXML都自动被视为清单。事实上，AUTOSAR AP在车辆项目中通常不是唯一被使用的。
典型的车辆很可能也配备了许多基于AUTOSAR CP开发的ECU，因此整个车辆的系统设计必须涵盖两者——基于AUTOSAR CP构建的ECU和基于AUTOSAR AP创建的ECU。
原则上，清单的定义可以这样：概念上只有一个“清单”，所有部署方面都在此上下文中处理。这似乎并不合适，因为很明显，清单相关的模型元素存在于典型开发项目的完全不同的阶段。
这一方面是主要的动机，即在应用程序设计之外，有必要将清单的定义细分为三个不同的部分：
**应用程序设计**
此类描述指定了为AUTOSAR AP创建应用软件时所有与设计相关的方面。它不一定需要部署到自适应平台机器上，但应用程序设计有助于在执行清单和服务实例清单中定义应用软件的部署。
**执行清单**
此类清单用于指定在AUTOSAR AP上运行的应用程序的部署相关信息。
一个执行清单与实际的可执行代码捆绑在一起，以支持将可执行代码集成到机器上。
**服务实例清单**
此类清单用于根据底层传输协议的需求，指定服务导向通信的配置方式。
一个服务实例清单与实际实现服务导向通信相应使用的可执行代码捆绑在一起。
**机器清单**
此类清单应描述适用于配置运行AUTOSAR AP的底层机器（即不包含其上运行的任何应用程序）的部署相关内容。一个机器清单与用于建立AUTOSAR AP实例的软件捆绑在一起。
不同类型清单的定义（和使用）之间的时间划分得出以下结论：在大多数情况下，将使用不同的物理文件来存储这三种清单的内容。
除了应用程序设计和不同类型的清单外，AUTOSAR方法论还支持系统设计，可以在一个单一模型中描述将在系统中使用的两种AUTOSAR平台的软件组件。不同AUTOSAR平台的软件组件可以以服务导向的方式相互通信。但也可以描述信号到服务的映射，以在服务导向通信和基于信号的通信之间建立桥梁。
### 3.5 应用程序设计
应用程序设计描述了为AUTOSAR AP创建应用软件时所有与设计相关的建模。
应用程序设计侧重于以下方面：
- 用于软件设计和实现的信息分类的数据类型
- 作为服务导向通信关键要素的服务接口
- 定义应用程序如何访问服务导向通信
- 作为访问持久化数据和文件的关键要素的持久化接口
- 定义应用程序如何访问持久化存储
- 定义应用程序如何访问文件
- 定义应用程序如何访问加密软件
- 定义应用程序如何访问平台健康管理
- 定义应用程序如何访问时间基准
- 定义数据序列化特性，以便在网络传输中定义数据的序列化方式
- 用于通过REST模式与Web服务通信的REST服务接口
- 客户端和服务器能力的描述
- 应用程序分组以简化软件部署
应用程序设计中定义的工件独立于应用软件的特定部署，从而便于在不同部署场景中重用应用程序实现。
### 3.6 执行清单
执行清单的目的是提供将应用程序实际部署到AUTOSAR AP所需的信息。总体思路是保持应用程序软件代码尽可能独立于部署场景，以增加应用程序软件在不同部署场景中被重用的可能性。
通过执行清单，控制应用程序的实例化，因此可以：
在同一台机器上多次实例化同一个应用程序软件，或将应用程序软件部署到多台机器上，并在每台机器上实例化该应用程序软件。
执行清单侧重于以下方面：
- 启动配置，定义应用程序实例应如何启动。启动包括启动选项和访问角色的定义。每次启动可能依赖于机器状态和/或功能组状态。
- 资源管理，特别是资源组的分配。
### 3.7 服务实例清单
在网络中实现服务导向通信需要针对所使用的特定通信技术（例如SOME/IP）进行配置。由于通信基础设施在服务的提供者和请求者上行为应相同，服务的实现必须在两侧兼容。
服务实例清单侧重于以下方面：
- 服务接口部署，定义服务在特定通信技术上的表示方式。
- 服务实例部署，为特定的已提供和所需服务实例定义通信技术所需的凭证。
- E2E保护的配置
- 安全防护的配置
- 日志和跟踪的配置
### 3.8 机器清单
机器清单允许配置在特定硬件（机器）上运行的实际自适应平台实例。
机器清单侧重于以下方面：
- 网络连接的配置和网络技术基本凭证的定义（例如，对于以太网，这涉及设置静态IP地址或定义DHCP）。
- 服务发现技术的配置（例如，对于SOME/IP，这涉及定义IP端口和IP多播地址）。
- 所用机器状态的定义
- 所用功能组的定义
- 自适应平台功能集群实现的配置（例如，操作系统提供具有特定权限的操作系统用户列表）。
- 加密平台模块的配置
- 平台健康管理的配置
- 时间同步的配置
- 可用硬件资源的文档记录（例如，有多少RAM可用；有多少处理器核心可用）
## 4 操作系统
### 4.1 概述
操作系统（OS）负责自适应平台上所有应用程序的运行时调度、资源管理（包括监控内存和时间约束）以及进程间通信。操作系统与执行管理协同工作，执行管理负责平台初始化，并使用操作系统执行应用程序的启动和关闭。
自适应平台并未为高性能处理器指定一个新的操作系统。相反，它定义了自适应应用程序使用的执行上下文和操作系统接口（OSI）。
OSI规范包含了作为ARA（自适应应用程序标准应用程序接口）一部分的应用程序接口。操作系统本身很可能提供其他接口，例如创建进程，这是执行管理启动应用程序所需的。然而，提供此类功能（以及其他功能）的接口不作为ARA的一部分提供，并且被定义为平台实现相关的。
OSI提供C和C++接口。对于C程序，应用程序的主源代码业务逻辑包含POSIX标准中定义的C函数调用，即IEEE1003.13 [1]中定义的PSE51。在编译期间，编译器确定平台操作系统提供的哪个C库提供了这些C函数，并且应用程序的可执行文件将在运行时链接到该库。对于C++程序，应用软件组件的源代码包含C++标准及其标准C++库中定义的函数调用。
### 4.2 POSIX
市场上有几种操作系统，例如Linux，提供符合POSIX的接口。然而，与平台服务和基础相比，应用程序需要使用更受限制的操作系统API。
一般的假设是，用户应用程序应使用PSE51作为操作系统接口，而平台应用程序可以使用完整的POSIX。如果在应用程序级别需要更多功能，将从POSIX标准中获取，并尽可能不进行新的规定。
自适应平台基础和自适应平台服务的实现可以使用更多的POSIX调用。特定调用的使用将由实现者决定，且不会被标准化。
### 4.3 调度
操作系统提供多线程和多进程支持。标准的调度策略是POSIX标准定义的SCHED_FIFO和SCHED_RR。允许使用其他调度策略，如SCHED_DEADLINE或任何其他操作系统特定的策略，但局限性在于这可能无法在不同的AP实现之间移植。
### 4.4 内存管理
支持多进程的原因之一是实现不同功能集群和AA之间的“免于干扰”。操作系统对多进程的支持强制每个进程处于独立的地址空间，与其他进程隔离和保护。同一可执行文件的两个实例在不同的地址空间中运行，这样它们可能在启动时共享相同的入口点地址和代码以及数据值，但是数据将位于内存中不同的物理页面。
### 4.5 设备管理
设备管理在很大程度上是操作系统特定的。自适应平台基础有意倾向于创建服务来公开主要的系统功能。虽然目前没有计划标准化设备驱动程序本身的具体API，但此类驱动程序实现的更高级功能可以通过自适应平台服务进行标准化。
### 4.6 网络
多台机器之间以及与其他传感器之间的主要互连机制预计将基于以太网。因此，明确描述了基于TCP/IP和UDP/IP的协议的使用。因此，预计操作系统将提供这样的网络协议栈。应用程序将通过使用通信管理透明地受益于网络支持。作为自适应平台基础的一部分，VLAN、IPsec等附加功能实现了系统内部及跨系统的安全通信。
## 5 执行管理
### 5.1 概述
执行管理负责系统执行管理的所有方面，包括平台初始化和应用程序的启动/关闭。执行管理与操作系统协同工作，以执行应用程序的运行时调度。
### 5.2 系统启动
当机器启动时，操作系统将首先初始化，然后执行管理作为操作系统的初始进程之一被启动。随后，执行管理启动其他功能集群和自适应平台基础的平台级应用程序。在自适应平台基础启动并运行后，执行管理继续启动自适应应用程序。平台级应用程序和自适应应用程序的启动顺序由执行管理根据机器清单和执行清单中的信息决定。
图 5-1 AP 启动序列
执行管理可选地支持认证启动，从信任根开始，在保持信任链的同时启动自适应平台。在认证启动期间，执行管理验证应用程序的真实性和完整性，如果检测到违规，将阻止其执行。通过这些机制，可以建立一个可信平台。
### 5.3 执行管理职责
执行管理负责自适应平台执行管理和应用程序执行管理的所有方面，包括：
1. **平台生命周期管理**
执行管理作为自适应平台启动阶段的一部分被启动，并负责自适应平台和已部署应用程序的初始化。
2. **应用程序生命周期管理**
执行管理负责已部署应用程序的有序启动和关闭。执行管理基于机器清单和执行清单中的信息确定已部署的应用程序集合，并根据声明的应用程序依赖关系推导出启动/关闭顺序。根据机器状态和功能组状态，已部署的应用程序在自适应平台启动期间或之后启动，但并非所有应用程序都会立即开始主动工作，因为许多应用程序将向其他应用程序提供服务，因此会等待并“监听”传入的服务请求。
执行管理不负责应用程序的运行时调度，因为这是操作系统的责任。然而，执行管理负责初始化/配置操作系统，使其能够基于执行管理从机器清单和执行清单中提取的信息执行必要的运行时调度。
### 5.4 确定性执行
确定性执行提供了一种机制，使得使用给定输入数据集进行的计算总是在有界时间内产生一致的输出。执行管理区分时间确定性和数据确定性。前者指输出总是在截止时间前产生，而后者指从相同的输入数据集和内部状态生成相同的输出。
执行管理提供的支持侧重于数据确定性，因为它假设通过提供足够的资源来处理时间确定性。对于数据确定性，执行管理提供DeterministicClient API，以支持进程内部循环的控制、确定性工作线程池、激活时间戳和随机数。DeterministicClient与通信管理交互，以将数据处理与循环激活同步。DeterministicClient支持的API及其与应用程序的交互在图“5-2 确定性客户端”中说明。
图 5-2 确定性客户端
### 5.5 资源限制
自适应平台允许多个自适应应用程序在同一台机器上执行，因此确保免于干扰是一个系统属性。因此，行为不正确的自适应应用程序应限制其影响其他应用程序的能力，例如，应防止应用程序消耗超过指定限额的CPU时间，因为这可能对其他应用程序的正确运行造成影响。
执行管理通过配置一个或多个资源组（应用程序的进程被分配到这些资源组）来支持免于干扰。然后可以为每个资源组分配CPU时间或内存的限制，从而限制应用程序的可用资源。
### 5.6 应用程序恢复
执行管理负责与状态相关的进程启动/停止管理，因此它必须拥有启动和停止进程的特殊权限。平台健康管理监控进程，并在任何进程行为不符合指定参数时触发恢复操作。恢复操作由集成商根据平台健康管理的软件架构要求定义，并在执行清单中配置。
### 5.7 可信平台
为了保证系统的正确功能，确保平台上执行的代码具有合法来源至关重要。保持这一属性允许集成商构建一个可信平台。
实现可信平台的系统的一个关键属性是信任锚（也称为信任根）。信任锚通常实现为存储在安全环境中的公钥，例如在不可修改的非易失性存储器中或HSM中。
系统设计者负责至少确保系统从信任锚开始启动，并保持信任直至执行管理启动。根据系统设计者选择的建立信任链的机制，在系统启动的这个点，可能已经检查了整个系统的完整性和真实性。然而，如果系统设计者仅确保已执行的软件已经过完整性和真实性检查，那么当执行管理接管系统控制权时，它将继续负责维护信任链。在这种情况下，系统集成商负责确保执行管理被正确配置。
一个将信任从信任锚传递到操作系统和自适应平台（即建立信任链）的示例可能如下：信任锚——根据定义是可信任的实体——在引导加载程序启动之前对其进行认证。在引导过程的每个后续步骤中，待启动的可执行文件应首先被认证。此真实性检查应由一个已认证的实体完成，即真实性检查可以例如由先前启动的可执行文件或由某些外部实体（如HSM）完成。
在操作系统被认证启动后，它将启动执行管理作为其初始进程之一。在启动执行管理之前，操作系统应确保执行管理的真实性已由某个已认证且因此可信的实体验证。
注意：如果认证不是由信任锚本身的功能（信任锚本身是可信的）检查的，那么用于验证可执行文件真实性的软件在应用前必须先被认证。例如，如果使用加密API来验证可执行文件的认证，那么加密API本身在用于任何可信实体之前应被认证。
执行管理现在接管在启动自适应应用程序之前对其进行认证的责任。然而，验证可执行代码的完整性和真实性的方法不止一种。在SWS_ExecutionManagement中，提供了完成此任务的可能机制列表。
## 6 状态管理
状态管理是一个独特的功能集群，其设计意图主要针对ECU开发项目，通常是项目特定的，最终实现通常由系统集成商执行。它负责AUTOSAR自适应平台操作状态的所有方面，包括处理传入事件、对这些事件/请求进行优先级排序以设置相应的内部状态。根据项目需求，状态管理可能包含一个或多个状态机。
状态管理通过项目特定的 ara::com 服务接口与自适应应用程序交互，该接口包含如下所述的“字段”。状态管理与其他功能集群之间的交互应通过每个功能集群定义的标准化接口进行。
图 6-1 状态管理交互
状态管理可以请求以下效果：
- 可以请求将功能组设置为专用状态
- 可以请求停用/激活（部分）网络
- 可以请求关闭或重启机器
- 可以影响其他自适应（平台）应用程序的行为
- 可以执行项目特定的操作
- 当收到平台健康管理或执行管理的错误通知时，从（监控）错误中恢复
- 应诊断请求，按诊断地址执行项目特定的复位
- 应更新和配置管理请求，准备和验证软件集群以供安装、更新或移除
- 影响运行中进程的行为，以实现机器（部分）内的同步行为（例如电源模式）
为了实现同步行为，状态管理提供定义的消息和回复消息，在通信管理的通信组范围内从中生成 ara::com 方法和字段。
状态管理通过 ara::com 提供一组“触发器”和“通知器”字段。SM主要监听“触发器”，内部执行特定实现的状态机处理，并在存在时将效果提供给“通知器”字段。
由于状态管理功能至关重要，来自其他功能集群或应用程序的访问必须得到保护，例如通过IAM（身份与访问管理）。状态管理由平台健康管理监控和监督。
状态管理功能高度项目特定化，AUTOSAR目前决定不像经典平台的BswM那样为自适应平台指定功能。目前计划仅指定一组基本服务接口，并将实际的仲裁逻辑封装到项目特定代码中。
仲裁逻辑代码可以单独开发或（部分）基于标准化配置参数生成。
## 7 通信管理
### 7.1 概述
通信管理负责分布式实时嵌入式环境中应用程序之间通信的所有方面。
其背后的概念是抽象出实际寻找和连接通信伙伴的机制，以便应用软件的实现者可以专注于其应用程序的特定目的。
### 7.2 服务导向通信
服务的概念是指除了基本操作系统软件已提供的功能之外，提供给应用程序的功能。通信管理软件提供了在机器内部通信以及机器间通信中提供或消费此类服务的机制。
一个服务由以下内容的组合构成：
- 事件
- 方法
- 字段
通信伙伴之间的通信路径可以在设计时、启动时或运行时建立。该机制的一个重要组成部分是服务注册表，它充当代理实例，也是通信管理软件的一部分。
图 7-1 服务导向通信
每个提供服务的应用程序都会在服务注册表中注册这些服务。要使用服务，消费应用程序需要通过查询服务注册表来找到请求的服务，这个过程称为服务发现。
### 7.3 语言绑定和网络绑定
通信管理提供了标准化方法，将定义的服务呈现给应用程序实现者（上层，语言绑定），以及服务数据在网络上的相应表示（下层，网络绑定）。这保证了源代码在不同平台实现之间的可移植性以及已编译服务的兼容性。
语言绑定定义了如何使用目标编程语言的便捷特性，将服务的方法、事件和字段转换为可直接访问的标识符。性能和类型安全（在目标语言支持的范围内）是主要目标。因此，语言绑定通常由源代码生成器实现，该生成器接收服务接口定义作为输入。
图 7-2 语言绑定和网络绑定示例
网络绑定定义了如何序列化已配置服务的实际数据并将其绑定到特定网络。它可以基于通信管理配置（AUTOSAR元模型的接口定义）实现，或者通过解释生成的服务特定配方，或者直接生成序列化代码本身。目前，通信管理支持SOME/IP、DDS、IPC（进程间通信或任何其他自定义绑定）以及Signal PDU（基于信号的网络绑定）。
本地服务注册表也是网络绑定的一部分。
请注意：语言绑定和网络绑定之间的接口被视为通信管理软件内部的私有接口。因此，目前规范该接口的标准规范超出范围。尽管如此，鼓励平台供应商为其软件独立定义这样的接口，以便在其平台实现中轻松实现除C++之外的其他语言绑定以及其他网络绑定。
### 7.4 C++语言绑定的生成代理和框架
C++语言绑定的上层接口提供了AUTOSAR元模型接口描述中定义的服务的面向对象映射。
作为通信管理软件开发工具一部分的生成器会生成C++类，这些类包含每个服务字段、事件和方法的安全类型表示。
在服务实现端，这些生成的类称为服务提供者框架。在客户端，它们称为服务请求者代理。
对于服务方法，服务请求者代理提供了同步（阻塞调用者直到服务器返回结果）和异步（调用的函数立即返回）调用机制。调用者可以并行启动其他活动，并在服务器的返回值可用时，通过核心类型 ara::core::future 的特殊功能接收结果。参见第18.1节。
平台实现可以配置生成器，以便在相应服务器尚不可用时，为客户端功能的轻松开发创建模拟类。同样的机制也可用于客户端的单元测试。
代理类可以直接被客户端使用，而C++绑定的服务提供者框架只是抽象基类。服务实现应从生成的基类派生并实现相应的功能。
ara::com 的接口也可以为与安全相关的E2E保护通信提供代理和框架。这些接口的设计确保了无论E2E保护是开启还是关闭，都能保持与应用程序的兼容性。
### 7.5 静态和动态配置
通信路径的配置可以在设计时、启动时或运行时进行，因此被视为静态或动态：
- 完全静态配置：根本不需要服务发现，因为服务器知道所有客户端，客户端也知道服务器。
- 应用程序代码不进行发现：客户端知道服务器，但服务器不知道客户端。事件订阅是应用程序中唯一的动态通信模式。
- 应用程序中的完全服务发现：配置时不知道任何通信路径。用于服务发现的API允许应用程序代码在运行时选择服务实例。
### 7.6 服务契约版本管理
在SOA环境中，服务的客户端和提供者依赖于涵盖服务接口和行为的契约。在服务开发过程中，服务接口或行为可能会随时间变化。因此，引入了服务契约版本管理来区分服务的不同版本。AUTOSAR自适应平台支持服务设计阶段和部署阶段的契约版本管理。此外，客户端的服务发现可以配置为支持版本向后兼容性。这意味着，如果不同提供服务的版本与客户端所需的服务版本向后兼容，则客户端服务可以连接到这些版本。
### 7.7 原始数据流接口
除了服务导向通信，通信管理还提供了一个独立的API，用于处理朝向外部ECU（例如ADAS系统中的传感器）的原始二进制数据流。该API是静态的，并实现了客户端应用程序建立到服务器的通信通道，以及服务器应用程序等待客户端传入连接的功能。该API为客户端和服务器提供了销毁通信通道以及通过通信通道读写原始数据（字节流）的功能。原始数据流通道可以由集成者通过应用部署信息进行配置，例如包含网络端点信息和所选协议。目前，应使用TCP/IP套接字作为传输层，但将来可以添加其他替代方案。原始数据流接口在命名空间 ara::com::raw 中可用。
## 8 RESTful 通信
### 8.1 概述
通信栈 ara::com 和 ara::rest 都可以在自适应应用程序之间建立通信路径。ara::rest 是一个构建RESTful API以及基于此类API的特定服务的框架。它不直接定义一个开箱即用的API来直接构建RESTful服务。该框架是模块化的，使开发者能够直接访问RESTful消息事务中涉及的不同层。相比之下，ara::com 的重点是提供传统的函数调用接口，并隐藏此点之外的所有事务细节。另一个重要的区别是 ara::rest 确保与非AUTOSAR对等体的互操作性。例如，ara::rest 服务可以与移动HTTP/JSON客户端通信，反之亦然。
### 8.2 架构
ara::rest 的架构基于模块化设计，支持API和服务设计层面的开发者。下图展示了其通用设计，描述了服务应用程序在 ara::rest 中是如何组成的。
图 8-1 ara::rest 栈架构概览
ara::rest 的通用REST层只提供了三种基本抽象：树状结构的消息载荷（对象图）、一个URI和一个请求方法（如HTTP中的GET或POST）。从这些基本原语中，可以组合出特定领域的RESTful API，这定义了通过对象图、URI和方法进行交互的具体高级协议。其目的是定义访问特定领域数据模型的规则，并向应用程序提供抽象的(C++)API。当不需要这种进一步的抽象时，自适应应用程序也可以直接使用 ara::rest 来替代使用领域API。
### 8.3 组件
ara::rest 包含以下组件集。
图 8-2 ara::rest 组件
**对象图** 是一个与协议绑定无关的树状数据结构，是所有 ara::rest 通信的基石。其目的是映射到JSON等协议格式以及C结构体。这最大化了与非ARA通信对等体和经典AUTOSAR的兼容性。对象图在消息中传输，消息完全从具体的底层协议绑定中抽象出来。然而，如果需要，它们仍然允许用户访问协议特定的细节。
**消息** 在 ara::rest 的异步编程模型中，封装了请求/回复通信周期的完整上下文。
**路由** 概念提供了一种将请求（包括请求方法和URI）映射到用户定义的处理函数的方法。路由是将抽象从通用REST提升到特定类型RESTful API的基石。
**Uri** 是一个通用的、符合RFC标准但高效的URI表示。
ara::rest 为服务器和客户端通信提供了所谓的（网络）端点，两者都提供了可比较程度的资源控制。两者都旨在为单核和多核系统提供快速高效的通信能力。
整个框架设计严格面向最大程度的资源控制。所有计算和分配都可以被严格控制，并根据应用程序（部署）的精确需求进行定制。
## 9 诊断
### 9.1 概述
诊断管理（DM）实现了ISO 14229-5 (UDSonIP)，该标准基于ISO 14229-1 (UDS) 和 ISO 13400-2 (DoIP)。
诊断管理代表了自适应平台基础层的一个功能集群。
其配置基于经典平台的AUTOSAR诊断提取模板（DEXT）。
支持的传输层是DoIP。DoIP是一种车辆发现协议，设计用于与诊断基础设施（诊断客户端、生产/车间测试仪）进行外部通信。
对于车内或远程诊断，经常使用其他传输协议，因此提供了一个API来扩展平台以支持自定义传输层。
UDS通常在车辆生产期间和车间内使用，以便能够维修车辆。
### 9.2 软件集群
可原子更新/扩展的部分由SoftwareCluster（SWCL）管理。一个SoftwareCluster包含更新已安装或部署特定新功能/应用程序集相关的所有部分。因此，自适应诊断管理器为每个已安装的SoftwareCluster支持一个独立的DiagnosticAddress。注意，此SoftwareCluster也与UCM的SoftwarePackage耦合，以便SoftwareCluster可以被更新或新引入到一台机器。
### 9.3 诊断通信子集群
诊断通信子集群实现了诊断服务器（类似于经典平台的DCM）。当前，支持的服务有限，但未来版本将扩展对更多UDS服务的支持。
除了ISO 14229-1的伪并行客户端处理外，诊断管理器（DM）被扩展以支持在不同诊断客户端的默认会话中完全并行处理。这允许满足现代车辆架构的需求，包括多个诊断客户端（测试仪）用于数据收集、从后台访问，以及一些经典的车间和生产用例。
### 9.4 自适应应用程序（AA）中的诊断
DM作为诊断服务器，将传入的诊断请求（如例程控制或DID服务）分派到相应AA的映射提供端口。为实现这一点，AA需要提供一个专门的 DiagnosticPortInterface。
### 9.5 类型化接口与通用接口
提供了不同抽象级别的 DiagnosticPortInterface：
- **例程控制消息**
- **类型化接口**：API签名包含所有请求和响应消息参数及其原始类型。DM负责序列化。此API对于特定的例程控制消息是个性化的。
- **通用接口**：API签名仅包含请求和响应消息的字节向量。应用程序负责请求和响应消息的序列化。相同的API可用于多个例程控制消息。
- **数据标识符消息**
- **类型化接口**：API签名包含所有请求（用于写入）和响应消息（用于读取）参数及其原始类型。DM负责序列化。
- **通用接口**：API签名仅包含请求和响应消息的字节向量。应用程序负责请求和响应消息的序列化。
- **数据元素独立接口**：每个请求和响应消息参数都有自己的接口。这是最高级别的抽象，即请求和响应消息结构的任何变化都不会影响API。此外，同一诊断消息的参数可以位于不同的进程中。
### 9.6 诊断会话
由于DM需要上述的伪并行处理能力，它支持DiagnosticConversation来反映诊断客户端和诊断服务器之间的不同会话。诊断服务器由相应UDS请求的目标地址标识，并在自适应平台中运行时动态分配。
### 9.7 事件内存子集群
事件内存子集群负责诊断故障码（DTC）管理（类似于经典平台的DEM）。
活动DTC代表了车辆中检测到的某个确定问题（通常对生产或车间很重要）。DM管理DTC及其配置的快照记录（一组在DTC发生时配置的环境数据）和/或扩展数据记录（属于DTC的统计数据，如再次发生的次数）的存储。
检测逻辑称为DiagnosticMonitor。此类监视器将其最近的测试结果报告给DM中的DiagnosticEvent。UDS DTC状态从一个或多个DiagnosticEvent派生而来。
DTC可以分配给PrimaryMemory（可通过19 02/04/06访问）或可配置的UserMemory（可通过0x19 17/18/19访问）。
支持计数器型和时间基准型去抖动。此外，DM提供关于内部转换的通知：感兴趣方会收到DTC状态字节变化、需要监视DiagnosticEvent重新初始化以及快照或扩展数据记录更改的通知。
如果DTC在配置的操作周期数内未处于活动状态，它可以从DTC内存中消失。
DM支持对存储和启用条件的通用处理。启用条件可用于控制在特殊条件下DTC的更新，例如在欠压条件下禁用所有与网络相关的DTC。
## 10 持久化
### 10.1 概述
持久化为应用程序和自适应平台的其他功能集群提供了在自适应机器的非易失性内存中存储信息的机制。数据在启动和点火周期之间可用。持久化提供了访问非易失性内存的标准接口。
持久化API从应用程序接收存储位置标识符作为参数，以寻址不同的存储位置。可用的存储位置分为两类：
- 键值存储
- 文件存储
每个应用程序可以组合使用多种这些存储类型。
持久化数据始终是一个应用程序的一个进程私有的。没有可用的机制允许使用持久化在不同进程之间共享数据。这一决定是为了防止在通信管理提供的功能之外出现第二条通信路径。
持久化已准备好处理来自同一应用程序（在同一进程上下文中运行）的多个线程的并发访问。为了创建对键值存储或文件存储的共享访问，可以将OpenKeyValueStorage和OpenFileStorage返回的SharedHandle传递（即复制）给另一个线程，或者可以在独立线程中为同一个键值存储或文件存储分别调用OpenKeyValueStorage和OpenFileStorage。
持久化能够维护存储数据的完整性。它使用冗余信息来检测数据损坏。冗余信息包括CRC码、哈希值和“N中取M”模式。这些机制可以一起使用，也可以独立使用。
持久化还提供了安全存储。这主要通过冗余来实现，但附加功能是让应用程序知道存储的数据是否有任何问题，即使问题可以通过冗余数据恢复。
持久化向应用程序提供关于已使用资源数量的统计信息。
持久化提供对存储数据的加密，以确保敏感数据在存储到物理设备之前被加密。
### 10.2 键值存储
键值存储提供了一种机制，在一个存储位置存储和检索多个键值对。键值存储直接支持以下三种数据类型：
- SWS_AdaptivePlatformTypes中定义的数据类型。
- 对应用程序中的复杂类型进行流化产生的简单字节数组。
- 通过Application Design中的“dataTypeForSerialization”引用的所有“PersistencyKeyValueDatabaseInterface”的实现数据类型，或专门作为该接口的PersistencyDataElement。
每个键值数据库的键需要是唯一的，并由应用程序使用Persistency提供的方法定义。
计划根据应用程序/平台特定的序列化代码，为Application Design中定义的AUTOSAR数据类型添加序列化/存储支持。
### 10.3 文件存储
并非所有与持久存储相关的数据都被结构化得使其适合用键值数据库作为存储机制。
对于这类数据，引入了文件存储机制。FileStoragePort允许应用程序访问一个存储位置并在其中创建一个或多个访问器。这些访问器再次由字符串格式的唯一键标识。
为了更好地理解此机制，与文件系统进行比较会有所帮助：FileStoragePort可以理解为一个文件系统目录，应用程序被允许在其中创建多个文件（访问器）。
### 10.4 UCM处理持久化数据的用例
UCM用例中持久化数据/持久化文件的处理完全取决于持久化配置。
通常，UCM支持在汽车ECU或自适应机器的生命周期内处理自适应应用程序的三个主要用例。
1. 将新的应用软件安装到自适应机器
2. 更新自适应机器上的现有应用软件
3. 从自适应机器卸载现有应用软件
在前两种情况下，UCM通过EM触发Persistency，以部署/更新应用程序的持久化数据。在第三种情况下，UCM可以使用来自Persistency配置的URI移除剩余的持久化数据。
Persistency应支持以下提及的场景。
- Persistency应能够将持久化数据部署到自适应应用程序安装期间由应用程序设计者定义的键值数据库或文件存储。
- Persistency应能够将持久化数据部署到由集成者更改的键值数据库或文件存储。
- Persistency应能够将持久化数据部署到键值数据库或文件存储。当安装新版本的应用程序时，Persistency应根据为键值数据库或文件存储配置的更新策略，覆盖或保留键值数据库或文件存储中的持久化数据。
通常，持久化层在应用程序设计和部署期间进行配置。Persistency应能够使用部署阶段的配置覆盖应用程序设计配置。如果部署阶段的配置缺失，则将考虑应用程序设计中的配置用于部署持久化数据。
## 11 时间同步
### 11.1 概述
当需要关联分布式系统中不同事件的时间时，无论是在时间上跟踪这些事件还是在准确的时间点触发它们，不同应用程序和/或ECU之间的时间同步（TS）都至关重要。
为此，向应用程序提供了一个时间同步API，以便它可以检索与其他实体/ECU同步的时间信息。
然后，时间同步功能通过系统中存在的不同“时间基准资源”（以下简称TBR）提供，这些资源通过预构建配置存在。
### 11.2 设计
对于自适应平台，考虑了以下三种不同的技术来满足所有必要的时间同步要求：
- 经典平台的StbM
- 库 chrono - 可以是 std::chrono (C++11) 或 boost::chrono
- 时间 POSIX 接口
在分析了这些模块的接口及其覆盖的时间同步功能之后，设计目标是提供一个时间同步API，该API提供围绕经典平台StbM模块包装的功能，但具有类似 std::chrono 的风格。
时间同步模块考虑了以下功能方面：
- 启动行为
- 构造函数行为（初始化）
- 正常操作
- 错误处理
以下功能方面将在未来版本中考虑：
- 关闭行为
- 错误分类
- 版本检查
### 11.3 架构
应用程序将能够访问每个时间基准资源（TBR）的不同专门类实现。
通过这个句柄，应用程序将能够查询所提供的时间基准类型（应为上述五种类型之一），然后获取该时间基准类型的专门类实现。应用程序也可以通过这个句柄直接创建定时器。
TS模块本身不提供将TBR与其他节点和/或ECU上的时间基准（如网络时间协议或时间一致性协议）同步的方法。
TBR的实现可能具有专用的周期性功能，该功能从时间同步以太网模块或类似模块检索时间信息，以同步TBR。
应用程序消费由TBR提供和管理的时间信息。因此，TBR充当时间基准代理，提供对同步时间基准的访问。通过这样做，TS模块从“真实”的时间基准提供者中抽象出来。
## 12 网络管理
### 12.1 网络管理算法概述
AUTOSAR NM基于分散式网络管理策略，这意味着每个网络节点仅依赖于通信系统内接收和/或发送的NM消息独立执行活动。
AUTOSAR NM算法基于周期性的NM消息，这些消息通过多播消息由集群中的所有节点接收。接收NM消息表明发送节点希望保持NM集群唤醒。如果任何节点准备进入睡眠模式，它会停止发送NM消息，但只要接收到来自其他节点的NM消息，它就会推迟进入睡眠模式的转换。最后，如果由于不再接收到NM消息而导致专用定时器超时，每个节点都会执行到睡眠模式的转换。如果NM集群中的任何节点需要总线通信，它可以通过开始发送NM消息来保持NM集群唤醒。
### 12.2 架构
自适应平台规范描述了AUTOSAR自适应平台的网络管理的功能、API设计和配置，独立于所使用的底层通信介质。目前只考虑了以太网，但架构保持与总线无关。
网络管理（NM）旨在通过状态管理进行控制，因为部分网络的控制需要通过与由SM控制的EM的功能组状态协调相关应用集来协调。本章内容尚未反映此设计。
图 12-1 NM 概览
其主要目的是在内部协调的状态机中协调底层网络（部分网络、VLAN或物理通道）的正常操作和总线睡眠模式之间的转换。它为状态管理提供了一个服务接口，用于请求和释放网络以及查询它们的实际状态。它协调不同实例（网络句柄）的请求，并提供一个聚合的机器请求通过网络。
如果使用部分网络特性，NM消息可以包含部分网络（PN）请求，使ECU能够忽略不请求与该ECU相关的任何PN的NM消息。这提供了关闭ECU（或其部分）的可能性，尽管在其他部分网络中通信仍在进行。
## 13 更新与配置管理
### 13.1 概述
AUTOSAR自适应平台的目标之一是能够通过空中更新（OTA）灵活地更新软件及其配置。为了支持自适应平台上软件的变化，更新和配置管理（UCM）提供了一个处理软件更新请求的自适应平台服务。
UCM负责更新、安装、移除和记录自适应平台上的软件。其角色类似于Linux中已知的包管理系统（如dpkg或YUM），并增加了额外功能以确保更新或修改自适应平台上软件的安全可靠方式。
UCM Master提供了一个标准的自适应平台解决方案，用于通过空中更新或通过诊断测试仪更新车辆软件。它协调车辆内多个UCM之间的包分发。因此，UCM Master可以被视为一个AUTOSAR标准的UCM客户端。
## 13.2 更新协议
UCM和UCM Master服务设计用于支持通过车辆诊断进行软件配置管理，并以安全、可靠和资源高效的方式支持在自适应平台上执行更改。为了满足支持来自多个客户端的更新并启用快速下载的要求，UCM需要能够将软件包（UCM输入）的传输与其处理分离开。
### 13.2.1 数据传输
数据传输通过 ara::com 进行流式数据传输。这使得能够将数据传输到UCM或UCM Master，而无需在从后台或诊断测试仪传输的过程中缓冲数据。UCM可以将包存储到本地存储库中，然后可以按照UCM客户端或UCM Master请求的顺序处理这些包。
传输阶段可以与处理阶段分离，UCM支持同时从多个客户端接收数据，没有限制。
UCM Master依赖与UCM相同的传输API，但通过其自己的专用服务接口访问。它支持与UCM相同的流式传输功能，如暂停或恢复并行传输。
### 13.3 包
#### 13.3.1 软件包
作为UCM输入的安装单元是一个Software Package。该包包括，例如，一个或多个（自适应）应用程序的可执行文件、操作系统或固件更新，或应部署在自适应平台上的更新配置和校准数据。这构成了Software Package中的Updatable Package部分，并包含了要添加到自适应平台或在其内部更改的实际数据。除了应用程序和配置数据外，每个Software Package包含一个Software Package Manifest，提供元数据，如包名称、版本、依赖关系以及可能用于处理包的一些供应商特定信息。
Software Package的格式未指定，这允许对UCM的实现使用不同类型的解决方案。Software Package包含要执行的软件更新和元数据。此内容由UCM供应商工具打包，以生成将由目标UCM处理的Software Package。
图 13-1 Software Package 概览
UCM基于提供的元数据处理供应商特定的Software Package。出于信息目的，您可以在下面找到Software Package Manifest中必须包含的字段描述：
**通用信息**
- 包名称：完全限定短名称。
- 版本：来自Software Cluster模型的版本，必须遵循 https://semver.org 的语义化版本规范，但内部版本号对于调试/追踪目的是强制的。使用的原始类型是StrongRevisionLabelString
- deltaPackageApplicableVersion：此增量包可应用的Software Cluster的版本。
- 支持的最小和最大UCM版本：确保UCM能够正确解析Software Package。
- 依赖关系：Manifest Specification文档包含一个模型，描述了Software Cluster在更新或安装后的依赖关系。
**允许检查是否有足够内存的大小：**
- uncompressedSoftwareClusterSize：目标平台中Software Cluster的大小。
- compressedSoftwareClusterSize：Software Package的大小。
**用于信息和追踪目的**
- 供应商：供应商ID
- 供应商认证标签
- 包：供应商ID
- 包认证标签：用于包一致性检查和安全性目的（供UCM检查Software Package是否可信）
- 型式认证：可选，型式认证信息。例如，可以来自UN ECE WP.29的RXSWIN。
- 发布说明：此版本更改的描述。
- 许可证：例如，MIT、GPL、BSD、专有。
**为了将包分发到车辆内正确的UCM：**
- 诊断地址：来自Software Cluster模型，用于例如通过UDS来自测试仪的包。
- 操作类型：可以是更新、安装或移除。
#### 13.3.2 后端包
为了OEM后台能够理解来自多个包供应商的包内容，提出了一个后端包格式，如下图所示：
图 13-2 Backend Package 概览
Software Package格式是供应商特定的。然而，由于Backend Package旨在与供应商无关，Software Package Manifest（图13-2中红色部分）必须使用ARXML文件格式。
#### 13.3.3 车辆包
Vehicle Package通常由OEM后台组装。它包含从后端数据库中存储的Backend Package中提取的Software Package Manifest集合。它还包括一个Vehicle Package Manifest，包含活动编排以及UCM Master在车内分发包所需的其他字段（图13-3）。
图 13-3 Vehicle Package 概览
出于信息目的，您可以在下面找到Vehicle Package Manifest中必须包含的字段描述：
- 仓库：用于历史、追踪和安全性目的的URI、仓库或诊断地址。
- 车辆描述。
- 对于更新活动编排：
- UCM标识符：车辆架构内的唯一标识符，允许UCM Master识别车辆中的UCM。
- Software Package的关联，以描述传输、处理和激活的顺序。
- 车辆驾驶员通知：与车辆驾驶员交互，请求其同意或在车辆更新的几个步骤中通知他。
Vehicle Package可以由车库用于修复例如下载更新有问题的车辆。因此，与Backend Package类似，Vehicle Package Manifest为了实现互操作性，应为ARXML文件格式。
#### 13.3.4 软件发布和打包工作流
为了创建一个Backend Package，集成者必须使用与目标UCM兼容的打包工具。这个包可以由包含目标UCM的自适应平台堆栈供应商提供。在集成者组装
可执行文件、清单、持久化等之后，他使用打包工具创建使用UCM供应商特定格式的Software Package。然后，这个相同的Software Package连同ARXML Software Package Manifest一起被嵌入到一个Backend Package中。Software Package可以由打包工具或集成者签名，并且认证标签包含在Software Package Manifest中。由于Backend Package可能通过集成者和OEM后台之间的互联网传输，Software Package和Software Package Manifest都应被签名到一个容器中，并附带其认证标签，以避免任何Software Package Manifest的修改。
图 13-4 打包步骤
由集成者组装的Backend Package随后可以放入后台数据库或存储库中。当车辆需要更新或新安装时，后台服务器将从Backend Package数据库中查询软件包，并将相关的Software Package Manifest合并到一个Vehicle Package中。在此包中，后台服务器嵌入了一个基于特定车辆电子架构（例如从车辆识别码推断）选择的活动编排。
### 13.4 UCM 处理和激活软件包
安装、更新和卸载操作通过 ProcessSwPackage 接口执行，UCM 从元数据中解析出需要执行的操作。UCM 序列设计用于支持例如 A/B 更新场景或“原地”场景，其中包管理器提供了在需要时回滚到先前版本的可能性。
图 13-6 Software Package 的处理和激活概览
为了保持实现更简单和更健壮，一次只能有一个客户端使用 ProcessSwPackage 方法请求处理 Software Package，将 UCM 状态切换到 PROCESSING。多个客户端可以按顺序请求处理已传输的包。在 A/B 分区更新场景中，多个客户端可以处理正在更新的非活动/B 分区；在软件集群有交叉依赖的情况下，每个客户端必须按顺序更新到“B 分区”中。一旦处理完成，UCM 状态切换到 READY 等待激活或另一次处理。
使用 Activate 方法进行的激活更改是针对所有已处理的包（无论请求客户端是谁）执行的。UCM Master 协调这种多客户端场景。UCM 可能不知道所有目标 Software Package 是否都已处理，但它应执行依赖关系检查，以查看系统是否与“B 分区”中已安装软件的要求一致。如果依赖关系未满足，UCM 应拒绝激活并切换回 READY 状态。
当更新被激活时，UCM 通过 ara::com 向 SM 打开一个 UpdateSession。对于每个受影响的 Software Cluster 中的每个 Function Group，调用 PrepareUpdate 方法。它执行 Function Group 特定的准备步骤。成功后，状态变为 VERIFYING。然后 UCM 根据更新类型，通过 SM 接口请求机器复位或 Function Group 重启。例如，如果更新包括操作系统或功能集群更新，UCM 可能希望复位机器。然而，如果更新仅仅是一个低关键性功能，仅重启 Function Group 可能就足够了，从而减少对驾驶员的干扰。在此阶段，UCM 向 SM 请求验证目标 Function Group 是否正常运行。一旦这些重启成功完成，UCM 切换到 ACTIVATED 状态。
当更新已处于 ACTIVATED 状态时，其他处理请求将被拒绝，直到激活被解决。在此阶段，UCM Client 或 UCM Master 可以调用 Finish 来确认更改，或调用 Rollback 来忽略更改并恢复到软件的先前版本。这适用于例如当此类更新是由 UCM Master 协调的全局更新活动的一部分，而另一个 ECU 的更新失败的情况。调用 Finish 后，UCM 清理所有不必要的资源并返回到 IDLE。
如果调用 Rollback，UCM 切换到 ROLLINGBACK 状态，通过为每个受影响的 Software Cluster 中的每个 Function Group 调用 PrepareRollback 方法，重新激活旧版本的软件集群。例如，在此状态下，在 A/B 分区场景中，UCM 将准备“A 分区”以便在下一次重启时被重新激活/执行。然后，当通过调用 SM 接口发生重启并且“A 分区”被重新激活时，UCM 切换到 ROLLEDBACK 状态。
在回滚和成功激活两种情况下，UCM 必须在 SM 结束更新会话。
UCM 设计支持在处理的同时进行传输，以避免将 Software Package 存储在自适应平台中，从而降低成本和更新时间。例如，如果 Software Cluster 仅包含自适应应用程序，UCM 可以解压缩接收到的块，将文件放置到其目标位置，最后认证和检查 Software Package 的完整性。
## 13.5 UCM Master 更新活动协调
由于 UCM Master 协调车辆内的多个元素，其状态机可通过 CampaignState 字段访问，以降低 UCM Master API 的复杂性。UCM Master 使用 ara::com 的服务发现持续发现车辆中的 UCM 服务实例。
图 13-7 UCM Master 状态机
UCM Master 状态机并不完全匹配 UCM 状态机，因为必须考虑特定的车辆方面。例如，车辆包传输、车辆中可用软件与后台的同步或更新后的车辆完整性检查，这些都是 UCM Master 特有的。
### 13.5.1 自适应应用程序与 UCM Master 交互
车辆更新涉及 OEM 特定内容，因此 OEM 特定方面在设计上被推送到自适应应用程序端。为了使这些应用程序能够与多个供应商平台互操作和交换，UCM Master 接口被标准化为平台服务，类似于 UCM。UCM Master 假定有以下三个应用程序与自身交互，如下所述。
### 13.5.2 OTA 客户端
OTA Client 设置后台和 UCM Master 之间的通信通道。后台和 OTA Client 之间的通信协议未指定。OTA Client 可以包含一个调度器，定期触发包含后台可用软件和车辆中现有软件的数据库（由后台或 UCM Master 管理）的同步。
可更新、可安装或可移除的软件由后台或 UCM Master 中这两个数据库之间的差异计算得出。
如果 UCM Master 发生故障，它可以被车辆中存在的另一个 UCM Master 替换。然后，OTA Client 应包含决策机制来选择与哪个 UCM Master 交互。
### 13.5.3 车辆驾驶员
在更新期间，可能需要与车辆驾驶员交互以：
- 获得下载同意（影响数据传输成本）
- 处理或激活软件（安全措施确认）
- 将车辆置于特定状态（为了保证关键更新期间的安全，可能被要求停止车辆并关闭发动机）
### 13.5.4 车辆状态管理器
Vehicle State Manager 收集来自所有车辆 ECU 的状态，并为 UCM Master 提供一个可供订阅的字段，以及针对 Vehicle Package 中引用的安全策略的判断。如果不满足安全策略，UCM Master 可以决定推迟、暂停或取消更新。
## 13.6 软件信息报告
UCM 提供服务接口，公开功能以检索自适应平台软件信息，例如已传输包（针对已处理但未提交的软件和最后提交的软件）的名称和版本。由于 UCM 更新过程具有明确的状态，UCM 提供每个 Software Package 处理处于哪个状态的信息。
UCM Master 也提供服务接口来公开软件信息，但是在车辆级别，聚合来自多个 UCM 的信息。然后，例如通过 OTA Client 与后台交换此信息，以确定车辆中可以更新哪些软件。此外，UCM Master 提供了一种访问其操作历史记录的方法，例如激活时间和已处理包的结果。后台可以使用此历史记录从车队收集更新活动统计数据，或在车库使用诊断测试仪排查问题。
## 13.7 软件更新一致性和认证
UCM 和 UCM Master 应使用覆盖整个包的认证标签来认证它们各自的包，如图 13-1 和图 13-3 所述。自适应平台应提供必要的校验和算法、加密签名或其他供应商和/或 OEM 特定机制来验证包，否则 UCM 或 UCM Master 将返回错误。实际上，包应由与开发目标 UCM 或 UCM Master 相同的供应商提供的工具打包，以便具有认证算法的兼容性。
由于认证算法使用哈希值，因此在认证包时也检查了一致性。可以在 TransferData、TransferExit 和 ProcessSwPackages 调用时检查包的认证和一致性，以覆盖许多可能的用例和场景，但为了最大安全性，应在 UCM 或 UCM Master 处理任何包之前进行。
## 13.8 保护更新过程
UCM 和 UCM Master 通过 ara::com 提供服务。UCM 和 UCM Master 更新协议中都没有客户端的认证步骤。相反，依赖身份和访问管理来确保通过 ara::com 请求服务的客户端是合法的。
## 13.9 更新过程中的适当状态管理
关于系统设置的可更新状态的定义是 OEM 的责任。基于系统设置和应用程序，系统可能需要切换到“更新状态”，以便它们在更新过程中忽略缺失或错误的消息。
此外，更新后还必须对系统进行最低限度的检查。为此，OEM 特定的诊断应用程序将机器置于“验证状态”，并检查所有相关进程是否已达到 runningState。这提供了在某个进程未能达到 runningState 时执行回滚的机会。图 13-9 提供了此概念的概述。
1. TransferData()
2. SetState(updateState)
3. ProcessSwPackage()
4. Activate()
5. SetState(verificationState)
6. SM 事件通知如果 GetState() == runningState
7. Finish()
8. 否则
9. Rollback()
10. SetState(defaultState)
图 13-9 更新过程中的状态管理
## 14 身份与访问管理
身份与访问管理（IAM）的概念是由日益增长的安全需求驱动的，因为AUTOSAR自适应平台需要与其应用程序建立健壮且定义明确的信任关系。IAM为自适应应用程序引入了权限分离，并防止在发生攻击时权限提升。此外，IAM使集成商能够在部署期间预先验证自适应应用程序对资源的访问请求。身份与访问管理为来自自适应应用程序对服务接口、自适应平台基础的功能集群以及相关模型化资源的请求提供了一个访问控制框架。
### 14.1 术语
为了理解框架的工作原理，必须预先定义几个重要的概念。作为参考，另请参阅RFC3198中的“基于策略的管理的术语”（https://tools.ietf.org/html/rfc3198）。
- **访问控制决策**：访问控制决策是一个布尔值，指示请求的操作是否被允许。它基于调用者的身份和访问控制策略。
- **访问控制策略**：访问控制策略用于定义访问特定对象（例如服务接口）必须满足的约束。
- **策略决策点（PDP）**：PDP做出访问控制决策。它通过检查访问控制策略来确定是否允许自适应应用程序执行请求的任务。
- **策略执行点（PEP）**：PEP在来自自适应应用程序的请求期间中断控制流，向PDP请求访问控制决策，并强制执行此决策。
- **意图**：意图是自适应应用程序身份的一个属性。仅当请求的AA拥有该特定资源所强制要求的所有已承认意图时，才授予对AUTOSAR资源（例如服务接口）的访问权限。意图在其Application Manifest中分配给AA。
- **授权**：在自适应应用程序部署期间，设计阶段请求的每个意图都应被承认。Grant元素在元模型中可用。Grants将支持集成商审查Intents，但其目的并非允许部分接受Intent。
- **中间标识符（IntID）**：一个标识符，能够识别运行中的POSIX进程并将其映射到模型化的AUTOSAR Process。IntID的具体性质取决于用于认证运行中POSIX进程的机制。
- **自适应应用程序身份（AAID）**：自适应应用程序的模型化身份由AUTOSAR Process表示。
- **自适应应用程序标识符**：对AAID（即AUTOSAR Process）的引用，精确指向一个AAID。
### 14.2 IAM框架的范围和焦点
IAM框架为AUTOSAR自适应平台堆栈和自适应应用程序的开发者提供了一种机制，用于建模每个应用程序的意图，在访问请求时提供访问控制决策，并强制执行访问控制。IAM侧重于提供限制自适应应用程序对自适应平台基础接口、服务接口以及与功能集群相关的已定义资源（例如KeySlot）的访问的手段。对系统资源（如CPU或RAM）强制执行配额不在IAM的范围内。
在运行时，IAM的过程对自适应应用程序是透明的，除非请求被拒绝并引发通知。
该框架设计用于在运行时强制执行对AUTOSAR资源的访问控制。假设自适应应用程序将在启动期间被认证，并且现有的受保护运行时环境确保自适应应用程序被适当隔离并防止其提升权限（即绕过访问控制）。
### 14.3 AUTOSAR规范的内容
下表表示了IAM框架的哪些部分将由AUTOSAR定义，哪些部分由开发者实现。
| 描述 | 隶属于 | 部分 |
| :--- | :--- | :--- |
| IAM的需求规范 | AUTOSAR规范 | RS_IdentityAndAccessManagement |
| IAM框架的行为描述（关于接口） | AUTOSAR规范 | SWS_IdentityAndAccessManagement |
| 用于实现PDP的AA与自适应平台中的PEP之间通信的API | AUTOSAR规范 | SWS_IdentityAndAccessManagement |
| 实现PDP的功能集群与自适应平台中的PEP之间通信的API | 未由AUTOSAR指定 | - |
| 应用程序意图和访问控制策略（清单文件信息） | AUTOSAR规范 | TPS_Manifest_Specification |
| 应用程序在授权失败时收到的警告/错误消息的格式和内容 | AUTOSAR规范 | SWS_IdentityAndAccessManagement |
### 14.4 IAM框架的架构
#### 14.4.1 通用框架
IAM架构将授权实体逻辑上划分为决定是否允许自适应应用程序访问资源的实体（PDP）和执行访问控制决策的实体（PEP）。需要限制对其应用程序接口访问的功能集群需要实现PEP，该PEP强制执行由PDP提供的访问控制决策。为此，当自适应应用程序请求访问此类接口时，PEP将与PDP通信。访问控制决策基于请求和应用程序的意图发送回PEP。访问控制决策所需的信息基于发起请求的自适应应用程序的Application Manifest中的意图以及策略。策略代表了适用于接口的规则，即自适应应用程序为了获得访问权限必须满足的先决条件。对于每个受访问控制的资源，策略在功能集群的规范中定义。
### 先决条件和假设
- 应用程序被设计/配置为具有意图（允许它们访问某些资源的属性）。
- 每个意图将在部署期间被承认。
- 已部署的应用程序将被加密签名，以便验证真实性。
- 应用程序与其包含意图的Application Manifest一起部署。
- 受IAM约束的自适应应用程序必须被可靠地启动，并且其清单在部署期间必须被认证。
- PEP解释请求并向PDP请求策略决策（PDP可以在同一进程中实现）。
### 14.4.2 自适应应用程序的识别
为了向PDP请求策略决策，PEP必须确定调用方自适应应用程序的身份。由于每次调用都通过进程间通信进行中介，中间件应支持这种识别。
身份本身是对模型化AA的引用。意图绑定到PortPrototype，因此绑定到SWComponentType（参见Manifest Specification）。
IAM框架未完全指定AA的识别。最合适的解决方案在很大程度上取决于堆栈供应商选择的操作系统和平台。许多现代操作系统确实支持在通信端点上识别对等体（例如Linux中的SO_PEERCRED，QNX中的getpeerid()或消息传递）。在不提供此类机制的平台上，可能适合在消息级别上实现协议。
由于执行管理通过模型化的AUTOSAR Process创建运行中的自适应应用程序实例，它负责跟踪运行中进程的属性（例如运行中自适应应用程序的PID）或分配属性，如设置专用UID或为消息级别实现分配密钥或UUID。执行管理应使PEP能够为每个对PEP的有效请求找到模型化的自适应应用程序。
PEP应在自适应基础中实现，并应与调用方自适应应用程序适当隔离。PDP不应由本身对所请求操作受访问控制约束的自适应应用程序提供。
### 14.4.3 IAM序列
1. 自适应应用程序（AA）发起对资源（例如服务接口）的请求。
2. PEP中断控制流。
3. PEP通过EM解析请求进程的身份。
4. PEP将调用者身份和请求参数传递给PDP。
5. PDP检查AA的意图是否足够，并将访问控制决策返回给PEP。
6. PEP通过阻止或允许请求来强制执行访问控制决策。
图 14-1 IAM 序列
传输库与EM用于识别AA的机制保持一致。以使用POSIX进程ID为例，EM跟踪在调用fork()期间从操作系统获取的PID。EM通过受保护的功能集群接口向PEP提供此信息。当使用UID时，EM应主动设置新POSIX进程的UID。
# 15 加密
AUTOSAR自适应平台支持用于通用加密操作和安全密钥管理的API。该API支持在运行时动态生成密钥和加密作业，以及对数据流进行操作。为了减少存储需求，密钥可以内部存储在加密后端中，或者外部存储并按需导入。
该API设计用于支持将安全敏感操作和决策封装在单独的组件中，例如硬件安全模块（HSM）。通过将密钥约束到特定用途（例如，仅解密）或根据IAM报告限制密钥对单个应用程序的可用性，可以提供对密钥和密钥使用的额外保护。
根据应用程序支持，该API还可用于在处理加密协议（如TLS和SecOC）时保护会话密钥和中间秘密。
功能集群Crypto为应用程序和其他自适应AUTOSAR功能集群提供了一个标准化接口，该接口提供加密和相关计算的操作。这些操作包括加密操作、密钥管理和证书处理。功能集群Crypto处理所有操作的实际实现，包括所有必要的配置以及在请求应用程序和堆栈提供的实现之间的操作代理。标准化接口由CryptoAPI公开。
X.509证书管理提供程序（CMP，命名空间 ara::crypto::x509）负责X.509证书的解析、验证、安全存储和按不同属性的本地搜索。此外，CMP负责证书吊销列表（CRL）和增量CRL的存储、管理和处理。CMP支持为在线证书状态协议（OCSP）准备请求和解析响应。
## 15.1 安全架构
虽然AUTOSAR AP仅定义了向应用程序公开的高级加密堆栈API，但该API是考虑到一个安全架构而定义的，该架构旨在满足上述安全和功能要求。
通用架构如图15-1所示。在最上层，AUTOSAR AP以及本地和混合应用程序，链接到AUTOSAR AP加密堆栈API。API实现可以引用一个中央单元（Crypto Service Manager）来跨应用程序一致地执行平台级任务，如访问控制和证书存储。该实现还可以使用Crypto Service Manager来协调将功能卸载到加密驱动程序（如硬件安全模块HSM）。确实，
以这种方式卸载加密堆栈API的功能是一种典型的实现策略：加密驱动程序可以实现完整的密钥管理和加密功能集，以加速加密操作并保护托管密钥免受恶意应用程序的攻击。
图 15-1 加密堆栈 - 参考架构
为了实现这种分层安全架构，加密堆栈API不仅执行典型的加密操作（如加密和解密），还提供对以下方面的原生支持：
1. 使用加密密钥或密钥句柄进行操作
2. 在可能的应用程序入侵情况下安全地管理密钥
3. 约束应用程序对密钥的访问和允许的操作
## 15.2 密钥管理架构
为了支持在可能的应用程序入侵情况下安全地远程管理密钥，加密堆栈集成了一种密钥管理架构，其中密钥和关联数据以端到端保护的形式进行管理。密钥可以基于现有预置密钥以可信方式引入系统，或通过本地密钥生成以不可信方式引入系统。假设加密后端/驱动程序得到适当保护，应用程序无法修改密钥，除非通过明确定义的授权请求（如密钥更新或撤销）。
## 15.3 关于API扩展的说明
需要引入新的或修改的权限/策略验证逻辑的重要新用途和交互，应绑定到相应的新密钥使用策略标志。例如，可以通过添加相应的新密钥使用策略并在涉及这些新密钥的所有密钥管理操作中强制执行新逻辑，来引入具有不同所有权/权限检查的替代预置密钥。
# 16 日志与跟踪
## 16.1 概述
日志与跟踪功能集群负责管理和检测AUTOSAR自适应平台的日志功能。平台可以在开发期间以及生产中和生产后使用日志和跟踪功能。这两个用例有所不同，日志与跟踪组件允许灵活地配置日志的检测和设置，以覆盖整个范围。日志信息可以根据配置转发到多个接收端，例如通信总线、系统上的文件和串行控制台。提供的日志信息标有严重性级别，日志与跟踪组件可以被配置为仅记录高于特定严重性级别的信息，这使得在日志客户端侧能够进行复杂的过滤和直接的故障检测。对于每个严重性级别，提供了一个单独的方法供自适应应用程序或功能集群使用。AUTOSAR自适应平台和日志功能集群负责维护平台稳定性，以避免系统资源过载。
日志与跟踪依赖于AUTOSAR联盟内标准化的LT协议。该协议确保日志信息被打包成标准化的交付和呈现格式。此外，LT协议可以向日志消息添加附加信息，例如ECU ID。日志客户端可以使用此信息来关联、排序或过滤接收到的日志帧。
此外，还提供了实用方法，例如将十进制值转换为十六进制数制或二进制数制。这些方法是必要的，以使应用程序能够向日志与跟踪提供符合LT协议标准化序列化格式的数据。
## 16.2 架构
日志与跟踪接口在命名空间 ara::log 中提供，供应用程序将日志转发到上述日志接收端之一。
日志与跟踪接口依赖于作为日志框架一部分的后端实现。日志框架可以使用其他功能集群来实现特定功能，例如时间同步或通信管理。
图 16-1 日志与跟踪概览
# 17 安全性
## 17.1 功能安全架构
AUTOSAR提供了安全概述和自适应平台的安全要求，以支持将自适应平台集成到安全项目中。对于本版本，安全概述以解释性文档（AUTOSAR_EXP_SafetyOverview）的形式呈现，安全要求以需求文档（RS_Safety）的形式呈现。
这些文档应帮助功能安全工程师识别AUTOSAR自适应平台中与功能安全相关的主题。以下列表提供了关于如何将RS_Safety和AUTOSAR_EXP_SafetyOverview中的内容映射到ISO 26262中的内容和结构的一般指导：
- AUTOSAR自适应平台假设、目标、场景和用例（AUTOSAR_EXP_SafetyOverview）
- 系统定义、系统上下文和故障考虑（AUTOSAR_EXP_SafetyOverview）
- 危害分析（AUTOSAR_EXP_SafetyOverview）
- 安全目标（AUTOSAR_EXP_SafetyOverview）
- 功能安全概念和功能安全要求（RS_Safety）
- 技术安全要求（RS_Safety）
安全概述文档（AUTOSAR_EXP_SafetyOverview）的目标是陈述顶级安全目标和假定的用例或场景。解释性文档包含假设、示例性项目（如参考模型）和/或对示例性技术解决方案、设备、过程或软件的引用。本文档中包含的任何此类假设或示例性项目仅供说明。这些假设不是AUTOSAR标准的一部分。
需求规范（RS_Safety）详细阐述了写在RS_Main中的高级安全要求。它利用了EXP_PlatformDesign文档中描述的功能。功能安全要求源于EXP_SafetyOverview中提到的安全目标和危害。技术安全要求源于功能安全要求，针对AUTOSAR功能集群和安全相关应用程序。
以下内容计划在后续版本中发布：
- 技术安全概念和技术安全要求
- 安全要求的验证、安全分析和示例性用例
最后一点，使用AUTOSAR自适应平台并不意味着符合ISO 26262标准。使用AUTOSAR自适应平台安全措施和机制仍有可能构建不安全的系统。
AUTOSAR自适应平台的架构，在最好的情况下，也只能被视为“脱离上下文的安全元素”（SEooC）。
## 17.2 信息交换保护（E2E保护）
AUTOSAR内的E2E配置文件将得到支持，以允许AUTOSAR AP和CP实例之间（无论它们是在同一ECU还是不同ECU）的所有组合进行安全通信。在有帮助的地方，将提供机制以允许使用自适应平台内服务导向方法的更多功能进行安全通信。提供的功能使验证从发布者发送并由订阅者接收的信息在传输过程中是否被更改成为可能。根据AUTOSAR CP中的E2E机制，E2E上下文中不提供传输确认和传输安全性。
当在发布者和订阅者之间的通信中使用E2E保护时，在发布者的进程中同步调用E2E保护。在订阅者端，在订阅者进程内接收到数据时调用E2E检查。
对于本版本，E2E支持：
- 轮询模式下的周期性和混合周期性事件
- 方法（有关限制，请参阅AP SWS通信管理）
周期性事件的E2E保护原理是事件的发布者序列化事件数据并添加E2E头。当接收到事件时，订阅者将运行E2E检查，该检查将返回结果，显示在传输期间是否发生了任何可检测的故障（由E2E配置文件定义）。在此检查之后，消息可以被反序列化。
以下内容尚不支持：
- 回调模式下的事件
- 非周期性事件
- 方法（无约束）
可用于E2E保护的配置文件在AUTOSAR基础（AUTOSAR_PRS_E2EProtocol）中描述。
## 17.3 平台健康管理
平台健康管理监督软件的运行。它提供以下监督功能（所有监督功能都可以独立调用）：
- 活动监督
- 截止时间监督
- 逻辑监督
- 健康通道监督
**活动监督**检查被监督实体运行频率是否过高或过低。
**截止时间监督**检查被监督实体中的步骤是否在配置的最小和最大限制时间内执行。
**逻辑监督**检查执行期间的控制流是否与设计的控制流匹配。
活动、截止时间和逻辑监督基于应用程序/非平台服务或功能集群通过API ReportCheckpoint报告检查点来执行。
**健康通道监督**提供将外部监督结果（如RAM测试、电压监控等）连接到平台健康管理的可能性。
健康通道监督基于通过API ReportHealthStatus报告健康状态来执行。
如果在被监督实体中检测到故障，平台健康管理会通知状态管理器。
如果检测到执行管理或状态管理中的故障，平台健康管理可以触发看门狗复位。
本版本已知的限制：
- 对诊断管理器的依赖性尚未定义
CP和AP共享的功能在基础文档中描述，并称为“健康监控”（RS_HealthMonitoring和ASWS_HealthMonitoring）。仅针对AP的额外规范在AP文档中描述，并称为“平台健康管理”（RS_PlatformHealthManagement, SWS_PlatformHealthManagement）。
注意，架构元素EM、SM和PHM与高度安全相关；安全执行管理和安全健康监控是自适应应用程序安全运行的基础。EM、PHM、SM元素相互
依赖并协调其活动，以确保AUTOSAR自适应平台内的功能安全。
# 18 核心类型
Core Types定义了多个功能集群在其公共接口中使用的通用类和功能。定义Core Types的动机之一包括通常用于接口定义的复杂数据类型。
## 18.1 错误处理
### 18.1.1 概述
处理错误对于任何软件开发都是至关重要的。对于安全关键型软件，这甚至更为重要，因为生命可能依赖于它。然而，当前安全关键型软件开发的标准对构建工具链施加了重大限制，特别是关于C++异常。对于ASIL应用程序，由于缺少对ASIL认证C++编译器的异常支持，通常无法使用C++异常。
自适应平台引入了一个概念，可以在不使用C++异常的情况下进行错误处理，并定义了许多C++数据类型来辅助实现这一点。
从应用程序程序员的角度来看，实现此概念的中心类型是 ara::core::ErrorCode 和 ara::core::Result。
### 18.1.2 ErrorCode
ara::core::ErrorCode 的一个实例表示软件中的特定错误情况。它类似于 std::error_code，但在重要方面与其不同。
一个 ErrorCode 总是包含一个枚举值（类型擦除为整数类型）和对一个错误域的引用。枚举值描述错误的特定类型，错误域引用定义了该错误适用的上下文。附加的可选成员是用户定义的消息字符串和供应商定义的补充错误描述值。
在自适应平台内，每个功能集群定义一个或多个错误域。例如，“Core Types”功能集群定义了两个错误域“Core”和“Future”，它们包含针对不同错误情况集的错误代码。
### 18.1.3 Result
类 ara::core::Result 是一个包装类型，它要么包含一个值，要么包含一个错误。由于其模板特性，值和错误都可以是任何类型。然而，错误类型默认为 ara::core::ErrorCode，并且预期在整个自适应平台中保持此分配。
由于错误类型有默认值，大多数 ara::core::Result 的声明只需要给出值的类型，例如 ara::core::Result 表示一个包含 int 或 ara::core::ErrorCode 的 Result 类型。
包含的值或错误可以通过成员函数 Result::Value 或 Result::Error 访问。调用者有责任确保仅在 Result 实例分别包含值或错误时调用这些访问函数。Result 的内容类型（即值是错误）可以通过 Result::HasValue 查询。这些成员函数都不会抛出任何异常，因此可以在不支持C++异常的环境中使用。
除了上述无异常工作流，类 ara::core::Result 允许通过调用 ara::core::Result::ValueOrThrow 将包含的 ara::core::ErrorCode 对象转换为 C++ 异常。此调用按原样返回任何包含的值，但通过抛出相应的异常类型（该类型根据所包含的 ara::core::ErrorCode 的内容自动派生）来处理包含的错误。
### 18.1.4 Future 和 Promise
类似于 ara::core::Result 用作同步函数调用的通用返回类型，ara::core::Future 用作异步函数调用的通用返回类型。
ara::core::Future 紧密模仿 std::future，但已扩展以与 ara::core::Result 互操作。
与 ara::core::Result 类似，ara::core::Future 是一个要么包含值要么包含错误的类。此内容可以通过两种方式提取：
1. 通过调用 ara::core::Future::get，它返回包含的值（如果存在），否则抛出异常。
2. 通过调用 ara::core::Future::GetResult，它返回一个 ara::core::Result 对象，该对象包含 Future 中的值或错误。
这两个调用都将阻塞，直到异步函数调用使值或错误可用。
## 18.2 高级数据类型
除了上一节提到的错误处理数据类型，自适应平台还包含许多其他数据类型和辅助函数。
其中一些类型已包含在 C++11 标准中；然而，行为几乎相同的类型在 ara::core 命名空间内被重新定义。
原因是 std:: 类型的内存分配行为通常不适合汽车用途。因此，ara::core 中的类型定义了自己的内存分配行为。此类数据类型的示例有 Vector、Map 和 String。
在 ara::core 中定义的其他类型已在较新的 C++ 标准中定义或提议，自适应平台将它们包含在 ara::core 命名空间中，因为它们对于支持清单的某些构造是必需的，或者因为它们在 API 中被认为非常有用。此类数据类型的示例有 StringView、Span、Optional 和 Variant。
## 18.3 原始数据类型
存在另一个文档 AUTOSAR_SWS_AdaptivePlatformTypes，它定义了可在 ServiceInterface 描述中使用的原始类型。本文档未来可能会被视为与核心类型文档合并。
## 18.4 全局初始化和关闭函数
以下函数可用于初始化和解初始化 AUTOSAR 自适应应用程序运行时环境的数据结构和线程：
- ara::core::Initialize
- ara::core::Deinitialize
ara::core::Initialize 初始化 AUTOSAR 自适应应用程序运行时环境的数据结构和线程。在此调用之前，无法与 ARA 进行交互。此调用必须在 main() 内部进行，即在能保证静态内存初始化已完成的位置。根据各个功能集群的规范，调用应用程序可能需要提供额外的配置数据（例如，为日志记录设置应用程序 ID）或在调用其他 API 到相应功能集群之前进行额外的初始化调用（例如，在 ara::com 中启动 FindService）。此类调用必须在调用 Initialize() 之后进行。在静态初始化完成之前调用 ARA API 会导致未定义行为。在静态初始化完成后但在调用 Initialize() 之前进行的调用将被功能集群实现拒绝，并返回错误，或者如果没有定义要报告的错误，则导致未定义行为。
ara::core::Deinitialize 销毁 AUTOSAR 自适应应用程序运行时环境的所有数据结构和线程。在此调用之后，无法与 ARA 进行交互。此调用必须在 main() 内部进行，即在能保证静态初始化已完成且静态初始化数据的销毁尚未开始的位置。在调用 ara::core::Deinitialize() 之后但在静态初始化数据销毁之前对 ARA API 的调用将被拒绝并返回错误，或者如果没有定义错误，则导致未定义行为。
在静态初始化数据销毁后对 ARA API 的调用将导致未定义行为。
# 19 参考文献
[1] Glossary, AUTOSAR_TR_Glossary.pdf.
[2] Main Requirement, AUTOSAR_RS_Main.pdf.
[3] Methodology for Adaptive Platform, AUTOSAR_TR_AdaptiveMethodology.pdf.
[4] Design guidelines for using parallel processing technologies on Adaptive Platform, AUTOSAR_EXP_ParallelProcessingGuidelines.pdf.
[5] FCDesign IAM, AUTOSAR_EXP_FCDesignIdentityAndAccessManagement.pdf.
[6] P. Kruchten, "Architectural Blueprints—The "4+ 1" View Model of Software Architecture," IEEE Software, vol. 12, no. 6, pp. 42-50, November 1995.
----