2021-08-01

转载：https://blog.csdn.net/usstmiracle/article/details/110405088

19-03版本

关于自适应AutoSAR 平台

适应autosar 平台实现了adaptive applications的运营环境。它提供了两种接口，一种是service, 一种是API。平台功能分成两部分：service部分和adaptive AUTOSAR basis.

功能集合包括

1. 自适应平台的功能集合

2. 定义需求描述

3. 从应用和网络角度描述软件平台的行为

4. 但是并不限制adaptive 平台的软件架构设计。

每个(虚拟)机器上只要要有一个自适应AUTOSAR平台基础部分的示例。service 部分没有必要， 可以分布在车里面的网络里面。

和classic AUTOSAR相比，Adaptive AUTOSAR可以在运行时动态链接服务和客户端。

智能ECU的前景

传统的ECU主要实现的功能是dada替换或加强机电系统。ECU的嵌入式软件基于输入来控制电信号的输出。这些输入和信号来自车内网络其他的ECU。大部分软件设计和实现的目标是汽车，而且在整个汽车生命周期内不会有大的改动，

新的汽车功能， 比如自动化驾驶，将会引入高度复杂的计算资源。这就要求车内的软件必须严格满足完整性和安全行需求。这些软件实现诸如环境感知和行为规划的功能，并将汽车集成到外部后端和基础设施系统中。由于外部系统或功能提升， 这些车中的软件需要在汽车的生命周期内更新。

传统的AUTOSAR 解决了嵌入式ECU的需求，但是不能满足上面描述的需求。因此，AUTOSAR　定义了第二个平台，自适应AUTOSAR(AP). AP提供高性能计算和通信机制，并且还提供灵活的软件配置，比如支持软件通过OTA更新。为CP特别定义的特性，比如接入电信号和汽车专用总线系统，可集成进入AP但不是标准化的重点。

技术驱动

主要有两个技术驱动，一个是ethernet,一个是处理器。

汽车网络日志增长的带宽需求导致引入了ethernet. 跟传统的车内通信技术比如CAN相比， Ethernet可以提供更高的带宽和交换网络，能够更高效的传输长消息，支持点对点通信。CP虽然能够支持ethernet，但它主要是为传统通信技术设计的，所以很难充分利用Ethernet通信。

同样的，由于汽车变得越来越智能化，对处理器的性能要求也大幅度的增长。多核处理器已经用于CP 当中，但是对处理能力的要求超越多核。

Adaptive 平台特征

C++开发

面向服务架构

并发处理

复用已有标准

safety and security

计划动态

可以动态的管理资源和通信来降低软件开发和集成的工作量。

可以继承AP,CP和非AUTOSAR　ECU

3 架构

3.1 逻辑层架构

下面显示了AP的逻辑架构．AA（adaptive application)在ARA (AUTOSAR Runtime for Adaptive Applications) 上运行. ARA包含了所有功能集合的应用接口.这些功能属于 Adaptive Platform foundation 和 Adaptive Platform Service. 任何AA多可以为其他AA提供服务．

这些功能接口对应用程序来说没啥差别，不论这些功能属于Adaptive Platform Foundation还是Adaptive Platform Service. 这些接口仅提供C++接口或者将来AP将来支持的其他语言接口。这两个部分内部实现肯定是有差别的。并且，AA调用的ARA的库中，可以使用ARA之外的接口来实现AP规范。这取决于AP的实现

需要注意的是为了展现一个更好的整体架构，图3-1显示的AP架构逻辑层包含的功能集合不是当前发布的AP的一部分。在这里没有显示的新功能会加入到未来发布的AP中。

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

这些API使用的语言是C++，并且C++标准库是ARA的一部分。关于OS API, 仅PSE51接口是ARA的一部分。PSE51是POSIX标准的单进程配置文件。PSE51被选来实现POSIX应用程序的移植以实现应用程序之间的免打扰。

C++标准库包含很多基于POSIX的接口，多线程API也包含在内。不推荐C++标准库的线程接口和PSE51的线程接口混合使用。不行的，c++标准库并不能cover所有的PSE51的功能，比如设置一个线程的调度策略。在这种情况下混合起来是使用是很有必要的。

应用程序启动和关闭

应用程序的生命周期是由EM(execution management )来管理的。应用程序的加载和关闭是有EM提供的功能来管理的。启动一个应用程序需要再在系统集成和运行时间内进行正确的配置。实际上，除了EM自己，所有的功能对于EM来说都是一样的应用，加载方式都一样。图3-2展示了AP 内不同的应用程序类型。

事实上决定应用程序启动和关闭的并不是EM 。SM (state management )才是控制着者。SM 会基于整个系统的设计命令EM , 仲裁不同的状态从而控制整个系统的行为。这里的系统指的是整个机器AP 和其应用程序的内部行为，因此SM的实现是基于特定项目的。SM 也会和其他功能模块交互来协调整个机器的行为。SM 应当使用标准的ARA 接口来维护不同的AP stack 之间的可移植行。

应用程序交互

关于AA之间的交互，PSE51并不包括IPC (inter process communication ), 因为并没有直接的接口实现AA 之间的交互。CM (communication management )提供机器内和机器之间面向服务的通信。不管服务和客户端程序的部署拓补结构，CM 都可以处理服务 request/replies 的路由。其他的ARA 接口也可以内部触发AA之间的交互，但是这并不是一个显示的通信接口，仅仅是其他ARA接口提供的一个附带功能。

非标准接口

AA和功能组合也可以调用非标准接口，只要他们和标准AP 功能不冲突，并且他们也能符合项目对safety 和security 的要求。特别是那些纯的应用程序本地运行库，尽量保证使用范围最小，因为它会影响其它AP 实现的软件可移植性。

3.2 物理架构

这里讨论的物理层架构仅以解释为目的，不包含任何的AP 的正式的软件需求。任何AP 实现的正式需求都会明确说明。

OS, 进程和线程

AP 操作系统必须能够提供多进程的POSIX OS . 每一个AA的实现都是一个独立的进程，有自己独立的逻辑内存空间和命名空间。一个单独的AA有可能包含多个进程，他们有可能部署成一个单独的实例或者分布式部署成多个AP 实例。从模块组织的角度，每个进程会被OS 实例成一个可执行文件。多个进程可以从一个可执行文件实例出来。并且一个AA 有可能包含多个可执行文件。

功能簇也被实现为进程。一个功能簇可以被实现成一个进程或多个进程。Adaptive 平台的服务和非adaptive的服务也被实现为进程。

所有的这些进程可以是单线程的1也可以是多线程的。根据这些进程所属的逻辑层的不同使用不同的OS API. 如果这些进程是运行在ARA 之上的进程，他们应该使用PSE51.如果这些进程是其中一个功能簇，可以自由使用OS 的API.

总而言之，从OS的角度，AP 和AA 只是一个进程的集合。每个进程包含一个或多个线程。尽管它们取决于AP的实现来提供任何类型的分区，但这些进程之间没啥差别。这些进程之间的交互通过IPC 或其它OS 可用的功能。说明一下，AA 进程也可能不用IPC 而仅通过ARA 通信

基于库或基于服务的功能簇的实现

根据图3-1的AP 逻辑架构，一个功能簇可以是一个Adaptive 平台的功能模块或是Adaptive 平台的服务。根据之前的描述，这些都是进程，需要通过IPC 和AA 进行交互。这里有两种方式可以实现。一个是基于库的设计。功能簇提供接口库，链接到AA, 直接调用IPC. 另外一种是基于service的设计。进程会使用CM的功能-有一个server代理库链接到AA。代理库调用CM接口，协调AA和Server进程之间的IPC。实现功能的时候可以定义是选择AA仅使用CM直接实现IPC或者使用server通过代理库实现IPC。

对于如何为功能簇选择设计，一个通用的指导意见是如果是本地单一AP实力，基于库的设计可能更合适因为它更简单且效率更高。如果是分别是的AP实例，建议使用基于service的色剂，因为CM提供透明的通信无论是否是本地的AA还是service. 属于Adaptive 平台的功能簇都是基于库的，Adaptive平台都是基于service就像名字所显示的那样。

最后，对于FC的实现是允许不以库的形式实现而不是以进程的方式实现，只要能满足FC定义的RS和SWS的需求。在这种情况下，AA和FC之间的交互就是一般的进程调用，而不是像之前描述的那样是基于IPC的。

功能簇之间的交互，

通常来讲，FC之间可以交互以AP特定的实现方式，因为它们不给ＡＲＡ接口束缚。比如PSE51 禁止使用PIC。它可以使用其他FC的ARA public的接口。其他FC之间的接口，为了实现FC一些特殊的功能，可以使用protected 的接口提供优先访问权限.

并且，从AP 18-03开始，一个新的概念引入，是Inter-Functional-Cluster(IFC)。它描述了FC提供给其FC的接口。注意它既不是ARA的一部分, 也不包括AP 实现正式的规范需求。通过澄清FC 之间的接口，它的出现只是为了促进AP 规范的开发。对于AP规范的使用者来说，它提供了一个更好的AP 架构视图。这些接口的描述在对应的FC SWS 的附录中。

机器/硬件

AP 允许的硬件被称为一个machine。背后的原理是不论使用何种虚拟技术，都可以达成一个一致的平台。这个机器可以是一个真实的物理机器，也可以是一个虚拟机，或者是一个半虚拟化的OS, 或者是一个OS级别虚拟的container, 亦或者是其他虚拟环境。

硬件上面可以有一个或多个machine.一个machine 上运行一个CP 实例。一般假设就是一个硬件也就是一个芯片，上面运行一个或多个machine .如果AP 实现允许的话，也可以是多个芯片组成一个machine.

3.3 方法论和清单 methodology and manifest

为了能够功能应用分布式，独立和敏捷开发，需要标准的开发方式。AUTOSAR adaptive方法论为像服务，应用，机器和配置这些东西提供标准和对应的task。这些对应的task定义了在adaptive平台上开发产品，不同的活动如何交互可以达到交换设计信息的目的。图3－3是一个草稿图，说明了adaptive的方法论是如何实现的。详细的细节在参考文档3中。

3.4 清单

清单Manifest是AUTOSAR 模型的描述。它用来支持AUTOSAR AP产品的配置。Manifest可以上传到AP 产品，和它对应的文件比如二进制文件结合在一起。

Manifest的使用被限制在AP平台。但是这并不意味着在AP 项目开发过程中产生的ARXML会自动被认为是manifest. 事实上，在汽车项目组中，AUTOSAR AP 不是被唯一使用的。

一个典型的汽z车也包含许多部署CP 的ECU。因此，一个整车的系统设计是包含两者的，即部署CP的ECU 和部署AP的ECU.

原则上，manifest这个词可以定义为在概念上只有一个。所有的部署都可以在这个上下文中处理。这看起来显然是不合理的。因为模型相关的元素存在于典型项目开发的不同阶段。

这部分是应用设计的主要动机。把manifest 细分成三种不同的类型是很有必要的。

应用设计. 这种描述详细描述了适用AP 应用软件创建所有设计相关的部分。它不是必须部署在adaptive 平台机器上。但是应用设计在执行清单上和服务实例清单上能够帮助应用软件部署的定义。

执行清单。这种清单地方是用来详细说明AP应用程序运行时部署相关的信息。执行清单是和实际执行的code绑定在一起用来支持可执行程序在机器上的集成。

服务实例清单。这种清单是用来说明如何根据传输协议的要求面向服务的通信是如何配置的。服务实例清单是和实际的可执行code绑定在一起的来实现面向服务的的使用。

机器清单。这种清单应该用来说明运行AP应用程序的机器的部署相关的配置的。机器清单和创建AP实例的软件绑定在一起。

这种临时定义的不用清单的用处会导致困惑。大多数情况下不同的文件用来存储三中清单。

除了用用程序设计和三种不同的清单，AUTOSAR方法论还支持系统设计。用来描述AUTOSAR平台的软件模块。这些软件模块用来在一个系统中一个模型中。不同AUTOSAR平台的软件模块会以面向服务的形式互相通信。但是描述一个信号到服务的映射可以在面向服务的通信和信号通信之间搭建一座桥梁。

3.5 应用程序设计清单

应用程序的设计描述了所有AP应用软件创建的设计相关的模型。

应用设计关注一下几个方面。

1. 数据类型用来说明软件设计和实现的信息
2. 服务接口作为面向服务的通信的关键元素
3. 定义应用如何访问面向服务的通信
4. 持久接口是访问持久数据和文件的关键元素
5. 定义用用程序如何访问持久存储
6. 定义应用程序如何访问文件
7. 定义应用程序如何访问加密软件
8. 定义应用程序如何访问PHM模块
9. 定义应用程序如何访问时间基数
10. 序列化属性用来定义如何序列化网络传输上的数据
11. REST服务接口是通过REST模式与web服务通信的关键元素
12. 客户端和服务器功能的描述
13. 分组应用程序以简化软件的部署
14. 应用程序设计中定义的构件独立于应用程序软件的特定部署，从而简化了对不同部署场景的应用程序实现的重用。

3.6 执行清单

执行清单的目的是为了提供AP应用程序实际部署需要的信息。这种想法是为了尽可能的保持代码和特定的部署场景独立，以增加在不同的部署场景中重用应用程序软件的可能性。

使用可执行清单可以控制应用程序的实例化， 因此，

1. 在同一台计算机上多次实例化相同的应用程序软件
2. 将应用程序软件部署到多台计算机上，并为每台计算机实例化应用程序软件。

执行清单关注一下几个方面

1. 启动配置，以定义如何启动应用程序实例。启动包括启动选项和访问角色的定义。每个启动可能依赖于机器状态和/或功能组状态。
2. 资源管理，特别是资源组分配。

3.7 服务实例清单

在网络上实现面向服务的通信需要特定于所使用的通信技术(例如SOME/IP)的配置。由于通信基础设施在服务的提供者和请求者上的行为应该相同，所以服务的实现必须保证双方都兼容。

服务实例清单关注以下几个方面。

1. 服务接口部署，以定义如何在特定的通信技术上表示服务
2. 服务实例部署，为特定的服务实例定义所使用的通信技术要求的证书
3. E2E保护的配置
4. 信息安全保护的配置
5. Log和trace的配置

3.8 机器清单

机器清单允许配置在特定硬件(机器)上运行的实际AP实例。

机器清单关注以下几个方面

• 配置网络连接和定义网络技术的基本证书(例如，对于以太网，这涉及到设置静态IP地址或定义DHCP)。
• 服务发现技术的配置（比如，对于SOME/IP，这涉及所使用的IP端口和IP组播地址的定义）
• 定义使用的机器状态
• 定义使用的功能组
• 自适应平台功能集群实现的配置(例如，操作系统提供具有特定权限的OS用户列表)
• 配置密码平台模块
• 配置PHM
• 配置时间同步
• 可用硬件资源的文档(例如可用内存大小;有多少个处理器核可用)

4.操作系统

4.1 概述

操作系统负责运行时间调度，资源管理和AP所有应用的进程间通信。OS和EM模块一起工作。EM负责平台初始化和使用OS执行应用的启动和关闭。

AP平台不会为高性能处理器指定新的操作系统。而是它定义了adaptive 程序使用的执行上下文和操作系统接口（OSI）。

OSI规范包含应用程序接口，它们是AP应用程序的标准应用程序接口ARA的一部分。操作系统本身可以很好地提供其他接口，例如创建进程，这些接口是EM启动应用程序所需的。但是，提供这些功能的接口，除了其他功能外，不能作为ARA的一部分使用，它被定义为依赖于平台实现。

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

POSIX

市场上有几种提供POSIX兼容接口的操作系统，例如Linux。但是，与平台服务和基础相比，应用程序使用操作系统API受限。

一般的假设是，用户应用程序应该使用PSE51作为操作系统接口，而平台应用程序可以使用完整的POSIX。如果在应用程序级别上需要更多的特性，那么这些特性将来自POSIX标准，而不是在可能的情况下新指定的。

Adaptive Platform Foundation和Adaptive Platform Services功能的实现可能会使用将来的POSIX调用。特定调用的使用将对实现者开放，而不是标准化。

4.3 调度

操作系统支持多线程和多进程。标准的调度是POSIX标准的SCHED_FIFO和SCHED_RR。其他的调度策略比如SCHED_DEADLINE或者其他的操作系统特定的策略是被允许的。而限制是不同AP实现不能移植。

4.4 内存管理

多进程支持背后的其中一个原因是实现不同功能集合和AA之间的免打扰。OS的多进程支持迫使每个进程在一个独立的地址空间中，与其他进程隔离和保护。同一个可执行文件的两个实例在不同的地址空间中运行，这样它们可以共享相同的入口点地址和代码，以及在启动时的数据值。但是，这些数据实在内存中不同的物理页中。

4.5 设备管理

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

5 执行管理。execution management (EM)

5.1 概述

EM负责系统执行管理的所有方面，包括平台初始化和应用的启动和关闭。EM和OS一起工作执行应用运行时间的调度。

5.2 系统调度

当机器启动时，将首先初始化操作系统，然后作EM为操作系统的初始进程之一启动。其他的功能集合和AP foundation的平台级的应用由EM启动。在AP foundation建立并运行后，EM将继续启动AA。平台级应用程序和AA的启动顺序由EM根据机器清单和执行清单信息确定。

5.3 EM的责任

EM负责AP 执行管理的所有方面。应用程序执行管理包括：

1. 平台生命周期管理

执行管理作为Adaptive平台启动阶段的一部分启动，并负责初始化Adaptive平台和已部署的应用程序。

2. 应用程序生命周期管理

执行管理负责已部署应用程序的有序启动和关闭。EM根据机器清单和执行清单中的信息确定已部署的应用程序集，并根据已声明的应用程序依赖项派生启动/关闭的顺序。根据机器状态和功能组状态，部署的应用程序在自适应平台启动期间或之后启动，但是，由于许多应用程序将向其他应用程序提供服务，因此并不能期望所有这些应用程序都立即开始活动工作，因此需要等待并“侦听”传入的服务请求。

EM不负责应用程序运行时间的调度因为这是OS的责任。但是， EM负责OS的初始化和配置以便OS能够根据EM中机器清单和执行清单的信息进行必要的时间调度。

5.4 决定执行

确定执行提供了一种计算机制，即是用给定的输入数据集合能够一直在有限的时间内产生一致的输出。执行管理区别于时间和数据决定论。输出的前者状态一直在最后期限前生成，而后者状态能够从相同的输入数据集和内部状态产生一致的输出。执行管理提供的支持侧重于数据决定论，因为它假设时间决定论已经通过提供足够的资源来处理。对于数据决定论，EM提供 DeterministicClient APIs 来支持控制进程内部周期，决定工作池，激活时间戳和随机数。在软件锁步的情况下，DeterministicClient 与一个可选的软件锁步框架进行交互，以确保冗余执行的过程具有相同的行为。DeterministicClient与CM进行交互，使数据处理与周期激活同步。

图5-2 决定客户端说明了 DeterministicClient 支持的API以及和应用程序的交互

5.5 资源限制

Adaptive 平台允许多个Adaptive应用在同一个机器上运行因此保证免打扰是一个系统属性。因此行为不正确的Adaptive 应用应该被限制以免影响其他应用。比如，应该防止应用程序消耗的CPU时间超过规定的时间，因为这可能会对其他应用程序的正常运行造成影响。

执行管理通过将应用程序进程分配给一个或多个ResourceGroup来避免干扰。每个ResourceGroup分配有限的CPU时间和内存来限制应用的可用资源。

5-6 应用恢复

执行管理负责进程启动/停止的状态依赖管理，所以它必须有特殊的权限能够启动和停止进程。PHM模块监控进程，如果任何进程的行为不在指定的参数范围内，则可以触发恢复操作。恢复操作由软件集成商根据PHM的软件架构需求来定义并且在执行清单中配置。

7 Communication Management 通信管理

7.1 概述

在分布式的实时嵌入式环境中，CM模块负责应用之间通信的所有方面。

其背后的概念是从实际的机制中抽象出寻找和连接通信伙伴的机制，以便应用程序软件的实现者能够专注于其应用程序的特定目的。

7.2 面向服务的通信

服务的概念意味着提供给应用程序的功能超出了基本操作软件已经提供的功能。通信管理软件提供了使用这些服务的机制，以便进行机内通信和机间通信

服务由Event, Method, Field 组合组成

通信伙伴之间的通信路径可以在设计，启动和运行的时候建立。这个机制一个重要的模块是Service Registry. Service Registry 作为CM软件的一部分充当代理实例。

提供服务的每个应用在Service Registry中注册这些服务。 为了使用服务，一个消费应用需要通过查询 Service Registry找到这些服务， 这个进程是Service Discovery。

7.3 语言绑定和网络绑定

通信管理提供了标准化的方法，即如何将定义的服务呈现给应用程序实现者(上层，语言绑定)，以及服务在网络上的数据的各自表示形式(下层，网络绑定)。这确保了源代码的可移植性和编译后的服务在平台的不同实现之间的兼容性。

语言绑定定义了如何使用目标编程语言的方便特性将服务的methods、event和field转换为可直接访问的标识符。性能和类型安全性(只要目标语言支持)是主要目标。因此，语言绑定通常由服务接口定义提供的源代码生成器实现。

网络绑定定义如何序列化配置服务的实际数据并将其绑定到特定网络。它可以基于通信管理配置(AUTOSAR元模型的接口定义)实现，方法是解释生成的特定于服务的配方，或者直接生成序列化代码本身。

本地Service Registry也是网络绑定的一部分。

note: 语言绑定和网络绑定之间的接口是CM软件的私有接口。因此定义这些接口不在范围之内。但是，平台供应商被鼓励为他们的软件独立定义这样一个接口，以方便实现除c++之外的其他语言绑定，以及在他们的平台实现内部的其他网络绑定。

7.4 生产C++绑定的代理和框架

C++语言绑定的上层接口提供了在AUTOSAR元模型的接口描述中定义的面向对象的服务映射。

生成器是CM软件开发工具的一部分。生成器生成C++类，包含 field, event, method和类型安全表示和每个服务的方法。

在服务实现端，这些生成的类被叫做服务提供框架。 在客户端，他们被称为服务请求代理。

对于服务方法，服务请求代理提供同步和异步调用。调用者可以并行地启动其他活动，并在服务器的返回值通过核心类型ara:: Core::future的特殊特性可用时接收结果。看 18.1 章

平台实现要可以配置以便生成器在各自服务器还不可用的时候创建模拟类以便于客户端功能的开发。相同的机制也可用于客户端的单元测试。

代理类可以被客户直接使用，而c++绑定的服务提供者框架只是抽象的基类。服务实现应该从生成的基类派生并实现相应的功能。

ara::com的接口也可以为安全相关的E2E保护通信提供代理和框架。这些接口的设计保证了应用程序的兼容性，不管E2E保护是打开还是关闭。

7.5 静态和动态配置

通信路径的配置可以发正在设计，启动和运行阶段。因此考虑静态或动态

• 全静态配置

服务发现不再需要因为服务器知道所有的客户端，客户端也知道服务端。

• 程序没有发现代码

客户端知道服务器但服务器不知道客户端。Event 订阅是应用唯一的动态配置形式。

• 应用程序中的完整服务发现

在配置时不知道通信路径。服务发现的API允许应用程序代码去选在运行时的服务实例。

8 Restful Communication

8.1 概述

两个通信展ara::com 和 ara::rest可以在Adaptive 应用之间建立通信路径。ara::rest 是建立Restful API和API之上特定服务的框架。它没有定义开箱即用的特定API来直接构造RESTful服务。这个框架是模块化的，它允许开发人员直接访问Restful消息事务中涉及的不同层。相反，ara::com的重点是提供一个传统的函数调用接口，并隐藏事务的所有细节。另外一个重要的不同点是ara::rest可以保证和非AUTOSAR节点的互操作性。比如，ara::rest服务可以和移动HTTP/JSON客户端通信，反之亦然。

8.2 架构

ara::rest的架构基于模块化设计，它支持API级别和服务设计的开发人员。下面的图署说明了一个通用的设计。它描述了如何在ara::rest中组成服务应用程序。

通用的ara::rest的REST层只提供了三个基本的抽象：一个树形结构的消息payload, URI 和请求方法（类似HPPT的GET 或 POST）。通过这些基本的原语，可以组成特定域的RESTful API，这些API定义了通过对象图、URI和方法进行交互的具体高级协议。它的目的是为访问特定域数据定义规则和为应用提供抽象(C++)接口。除了使用这个域API，Adaptive应用程序还可以在不需要进一步抽象时直接使用ara::rest。

8.2 组件

ara::rest 由以下模块组成

对象图(Object Graph)是一个协议绑定的独立树形数据结构，它是ara::rest所有通信的基石。它的目的是映射协议格式比如JSON到C结构。这个能最大化与非ARA通信节点和Classic AUTOSAR的兼容性。对象图在全从具体的底层协议绑定抽象的消息中传输。如果需要，它们仍然允许用户访问特定于协议的细节。

消息将请求/应答通信周期的整个上下文封装在ara::rest的异步编程模型中。

路由概念提供了将请求(包括请求方法和URI)映射到用户定义的处理函数的方法。路由是将抽象从通用REST提升到特定类型RESTful API的基石。

Uri是一种通信的与RFC兼容但高效的URI表示。

ara::rest为服务器和客户端通信提供了所谓的(网络)端点，它们都提供了相当程度的资源控制。两者都是为了在单核和多核系统上提供快速和有效的通信能力而设计的。

整个框架的设计都是为了能够最大化资源控制。所有的计算和分配都是严格控制的，并根据应用程序(部署)的精确需求进行定制。

9 诊断

9.1 概述

诊断管理实现了基于ISO 14229-1 (UDS)和ISO 13400-2 (DoIP)的ISO 14229-5 (UDSonIP)。

诊断管理使用ara::com表示服务层上的自适应平台的功能集群。它是独立于语言的，将来可能会与其他语言绑定(如Java)一起提供自适应应用程序。

配置是基于Classic平台的AUTOSAR诊断提取模板(DEXT)。DEXT开始进入市场，并已被多家OEM和供应商使用和支持。

支持的传输层是DoIP。Adaptive平台将来会支持其他传输层比如CAN。可能还计划支持定制传输层，因为DoIP通常不用作车载协议。

范围是从Adaptive应用程序中抽象诊断协议。这些接口与Classic平台(例如SetEventStatus)保持一致，以便为Classic平台开发人员提供方便的更改。

通常在AUTOSAR Classic 平台中，诊断是针对一个物理的带微控制器的ECU运行DCM和DEM功能。 但是，AUTOSAR adaptive 平台考虑将来的多个处理单元（多个微控制器、微处理器、gpu等）的ECU的用例和应用程序将来的动态扩展性。这将需要一种新的机制来处理AP机器的不同部分。

原子更新/扩展部分由软件集群SoftwareCluster(SWCL)管理。软件集群包含与更新安装或部署一组特定的新功能/应用程序相关的所有部分。因此，Adaptive Diagnostics Manager为每个已安装的SoftwareCluster支持一个自己的诊断服务器实例，该实例具有自己的诊断地址。请注意，这个软件集群还与UCM的软件包耦合，以便软件集群可以更新或新引入到机器中。

9.2 诊断通信子集

诊断通信子集群类似Classic平台的DCM，它实现了诊断服务器。目前支持的服务是有限的，但是在未来的版本中，将进一步扩展对UDS服务的支持。

除了ISO 14229-1的伪并行客户机处理之外，还扩展了诊断管理器(DM)，以支持对不同诊断客户机的完全并行处理。这满足了现代汽车架构的需要包括用于数据收集的多个诊断客户端(测试人员)、来自后端的访问、SOTA(软件无线传输)，以及最后的经典研讨会和生产用例。

诊断感知Adaptive应用程序(AA)

在这种情况下，DM将一个传入的诊断请求(通常是常规控制或DID相关服务)发送给AA，AA提供了显示的诊断相关接口（UDS服务类型的特定服务接口，比如日常控制服务接口包含"start", “requestResult"和"Stop”.并且如应用程序错误一样每个方法都定义了特定的UDS错误码）。

AA从UINT8-Array解析参数或序列化成UINT8-Array

在这个用例中，以请求中的data-parameter#1开始的整个UDS数据参数，和以正响应中的data-parameter#1开始的整个UDS数据参数作为In /OUT参数作为服务方法的UINT8 Vectors以输入/输出参数给出。对于这样的用例，没有特定的映射到UDS请求，只是简单的转发，并且具有非常灵活的请求处理方式，所以引入了GenericUDSService接口。

方法参数以输入/输出形式给出

在这个用例中，根据与DiagExt中的数据参数#N相关的diagnostics dataelement的类型定义，以请求中的data-parameter#1开始的整个UDS数据参数，和以正响应中的data-parameter#1开始的整个UDS数据参数作为In /OUT参数以不同的输入/输出参数给出。

9.2.1 诊断对话

如上面提到的那样由于DM要求伪并行和全并行客户端处理，因此它支持在诊断客户端和诊断服务器之间映射一个不同的对话。诊断服务器由相应UDS请求的目标地址标识，并在Adaptive平台的运行期间动态分配。

注意：关于ara::diag部分的开发讨论正在进行。到目前为止，还没有指定任何内容。

9.3 时间内存子集

时间内存自己就像Classic平台的DEM一样，它负责DTC的管理

支持的功能和接口与Classic平台一样。诊断监控表示为(诊断）事件可以和DTC结合。DTC可以分配主内存（通过 19 02/04/06访问）来配置用户内存（通过0x19 17/18/19访问）。DTC可以存储Snapshot- 和ExtendedDataRecords.

支持Counter-和Timebase Debouncing。另外，DM提供关于内部转换的通知：感兴趣的各方会被告知DTC状态字节变化，监控诊断事件重新初始化的需要以及Snapshot- 或ExtendedDataRecord是否改变。

操作周期变化对老化和敏捷计算非常重要，需要转发给DM。

同样适用于存储和 启用条件。变化需要转发给DM。通过启用条件, DTC的一般便哈可以被控制。比如 在电压条件下禁用所有网络相关监视器。通过存储条件，DTC不能存储在DTC存储器中。

10 持久性

10.1 概述

持久性给Adaptive平台的应用程序和功能簇提供了一种机制，让它们将信息存储在Adaptive 机器的非易失内存。这些数据在启动和点火周期内也是可用的。持久性提供了标准的接口访问非易失内存。

持久性API将存储位置标识符作为来自应用程序的参数，以定位不同的存储位置。

可用的存储位置分为两类

• 键值存储
• 文件存储

每个应用程序都可以使用多种存储类型的组合。

持久性数据对一个应用程序来说是私有的。没有任何可用的机制使用Persistency在不同的应用程序之间分享数据。此决定是为了防止在通信管理提供的功能下出现第二个通信路径。

持久性为存储数据提供了加密保证敏感数据在存储到物理设备之前都是加密的。

10.2 键值存储

键值存储提供了一种机制能够在一个存储位置存储和获取多个键值。键值存储直接支持下面三种数据类型。

• 在SWS_AdaptivePlatformTypes中定义的数据类型
• 由应用程序中复杂类型流产生的简单字节数组。
• 所有通过“PersistencyKeyValueDatabaseInterface”引用的“dataTypeForSerialization”实现的数据类型，或者在应用程序设计中专门用作该接口的PersistencyDataElements

键值对每个键值数据库是唯一的，这些键值使用Persistency提供的方法由应用程序定义。

对于定义在应用程序设计中的AUTOSAR数据类型增加基于应用程序和平台特定的序列化代码在计划当中。

10.3 文件代理存储

并不是所有与持久性存储相关的数据都是按键值数据库合适的存储机制的方式构造的。

对于这种数据，引进了文件存储的机制。一个文件存储端口允许一个应用程序来访问一个存储位置，并且在应用程序内创建一个或多个访问评估者。这些评估者以字符串的形式被唯一的键值标识。

跟文件系统的对比可以帮助更好的理解这种机制。文件存储端口可以理解为一个文件夹，应用程序可以在这个文件夹中创建多个文件(assessors).

由于文件存储和经典的文件系统系统访问接近，所以API是C++ std::iostream的一个子集，具有类似的行为。

10.4 UCM模块处理持久性数据的用例

在UCM过程中通过Peristency来处理UCM的持久性数据/持久性文件纯粹依赖于持久性配置

通常情况下 ，在CAR ECU 或adaptive机器的整个生命中期中，UCM支持三种主要的用例来处理adaptive 应用程序。

• 在Adaptive机器上安装新的adaptive 应用软件
• 在Adaptive机器上更新存在的adaptive 应用软件
• 从Adaptive机器上卸载存在的adaptive 应用软件

在这所有的三种场景中，Persistency被UCM用来部署/删除/更新应用程序的持久性数据。Perer

Persistency 支持下面提到的场景

• Persistency 能够在Adaptive 应用安装时将持久性数据部署到应用程序设计人员定义的键值数据库或文件代理中
• Persistency 能够在Adaptive 应用安装时将持久性数据部署到集成人员更改的键值数据库或文件代理中
• Persistency 能够在Adaptive 应用安装时将持久性数据部署到集成人员定义的键值数据库或文件代理中
• 安装新版本应用程序的时候，Persistency 能够根据键值或文件代理配置的更新策略将数据覆盖或保留到键值数据库或文件代理中。
• Peristency能够在卸载应用程序的时候删除键值数据库或文件代理中的持久性数据。

通常，Persistency层是在应用程序设计和部署的期间配置的。Persistency应该能够使用部署阶段配置来覆盖应用程序设计配置。如果部署配置信息丢失，应用程序设计的配置信息会被认为是部署永久数据。

Persistency会在集成到键值数据数据库或文件代理之前检查新安装和更新的持久数据

11 时间同步

11.1 概述

当需要分布式系统不同事件关联的时候，不同应用程序或ECU之间时间同步（TS)是最重要的，不论是及时跟踪这些事件或及时在在精确的时间点出发它们。

基于这个原因, 给应用程序给时间同步API， 因此它可以检索与其他实体/ ECU同步的时间信息。

时间同步功能由系统预构建的不同的时间基础资源（TBR)来提供。

11.2 设计

对Adaptive 平台来说，为了满足所有必要的时间同步的需求，可以考虑下面三种不同的技术

• Classic平台的StbM
• chrono库-无论是std::chrono(C++11)或boost::chrono
• Time POSIX 接口

分析完这些模块的接口和它们覆盖的功能之后，设计时间同步的动机是提供一个类似std::chorono 风格 , 封装Classic平台的StbM模块提供的功能。

时间同步模块考虑下面几个方面的功能：

• 启动行为
• 构建行为（初始化）
• 正常操作
• 错误处理

在将来的发布版本会考虑下面几个方面的功能

• 关闭行为
• 错误分类
• 版本检查

11.3 架构

应用程序能够访问每个时间基础资源（TBR)不同的专用类实现。

通过这个句柄，应用程序能够查询Time Base提供的类型（上面提到的五种类型之一），然后获得Time Base类型的专用类实现。通过这个句柄，应用程序能够直接创建一个定时器。

在其他节点或ECU，TS模块并不提供同步TBR到Time Base的方式类似网络时间协议或time agreement 协议。

TBRs的实现具有专门的循环功能，用来从时间同步以太网来检索时间信息，类似同步TBR。

应用程序使用TBR提供和管理的时间信息。因此，TBR就像时间基础代理，提供访问同步的Time Base。如此，TS模块可以从实时的Time Base 提供者中抽象。

12 网络管理

12.1 网络管理算法概述

AUTOSAR NM是基于分散的网络管理策略的，意味这每个网络节点根据在通信系统中收到和转发的NM信息独立执行活动。

AUTOSAR NM算法基于周期性的NM消息，这些消息通过多播消息被集群中的所有节点接收。

NM消息的接收表明发送节点希望保持NM集群处于唤醒状态。如果任何节点准备进入睡眠模式，它会停止发送NM消息，但是只要收到来自其它节点的NM消息，它会延迟切换到睡眠模式。最后，如果由于不再接收NM消息而导致专用计时器超时，每个节点都会切换到睡眠模式。

如果NM集群上的任何节点要求总线通信，如果NM集群中的任何节点需要总线通信，它可以通过启动传输NM消息来保持NM集群处于唤醒状态。

12.2 架构

Adaptive平台规范描述了AUTOSAR Adaptive平台的功能、API设计和网络管理的配置，这些都独立于所使用的底层通信媒体。目前只考虑以太网，但体系结构是独立于总线的。

网络管理（NM）是通过状态管理来控制的，因为部分网络节点的控制需要通过SM控制的EM的功能组状态与相关的应用程序集协调。本章的内容还没反应这个设计。

其主要目的是在内部协调的状态机中协调底层网络(部分网络、vlan或物理信道)的正常操作和总线休眠模式之间的转换。

它给状态管理提供了一个服务接口来请求发布网络和查询它们的实际状态。它协调不同实例（网络句柄）的请求，并提供一个通过网络聚合的机器请求。

如果使用部分网络特性，则Nm消息可以包含部分网络(PN)请求，从而使ECU有可能忽略不请求与ECU相关的任何PN的Nm消息。这为关闭ECU(或部分ECU)提供了可能性，尽管通信仍在其他部分网络中进行。

13 更新配置管理

13.1 概述目标

Adaptive AUTOSAR声明的一个目标就是通过OTA(无线，over the air)能够自由的更新软件和它的配置. 为了支持Adaptive平台的软件变化，UCM提供了一个Adaptive平台服务，更够处理软件更新请求。

UCM负责Adaptive 平台的软件更新，安装和删除以及保留软件记录。它的角色类似Linux上著名的包管理器dpkg或YUM。另外附加的功能是确保以安全可靠的方式更新或修改自适应平台上的软件。

13.2 更新协议

UCM服务旨在支持诊断通信子软件集群的诊断用例，并支持在安全、可靠和资源高效更新过程中对自适应平台进行更改。为了满足支持多个客户端更新和支持快速下载的需求，UCM必须将软件包(UCM输入)与它们的处理分开传输。

13.2.1 数据传输

U数据传输是通过ara::com上的数据流来完成的。它能够使数据传输到UCM中，而不需要在UCM外设置数据buffer. UCM把包存储在本地仓库，从而使UCM客户端按照请求数据处理。

由于传输阶段和处理阶段是分开的，UCM支持从多个客户端接收数据。并且这样做的时候没有任何限制。

13.3 包

13.3.1 软件包

安装单元对UCM来说输入是软件包。包包括，比如，一个或几个可执行的（Adaptive)应用程序，操作系统或固件更新，或更新配置和部署在Adaptive平台上的配置数据。这个构成了软件包的可更新部分和Adaptive平台上增加或更改的实际数据。除了应用程序和配置数据，每个软件包包含一个软件manifest. 这个清单中提供包名称，版本，依赖和一些可能的生产厂商特定消息。这些消息用来处理软件包。

软件包的格式并没有指定，对UCM的实现来说，能够使用不同的解决方案。软件包由要在软件和元数据中执行的更新组成。这些内容通过供应商工具来生成将由目标中的UCM处理的软件包。为了部署软件到目标，OEM可以将软件包打包到OEM部署的container中。在目标机器中，特定于OEM的应用程序将接收OEM包，并在将包传递给UCM之前执行可能的解压缩和解密。

UCM根据提供的元数据处理生产商特定的软件包。

13.3.2 后端包

软件包的格式是厂商特定的。但是，尽管后端包是厂商独立的，但是软件包的清单（图13-2中红色部分）必须是ARXML格式。

你可以在以下找到必须包含在软件包清单中的字段的描述，以供参考:

通用信息

• Package name：完全合格的简写
• Version：软件簇的版本必须遵循https://semver.org 的语义版本规范。在这个规范中异常构建号对于调试/跟踪是必需的。StrongRevisionLabelString primitive
• isDeltaPackage: boolean, 如果内容是按照增量包处理的，该字段激活
• Dependencies: 清单模型包含了描述软件包更新或安装后的依赖性模型。如果是增量更新，这个依赖模型会描述当前软件簇版本对比之前版本的依赖性。下面是模型例子：

大小，以允许检查是否有足够的内存可用:

• uncompressedSoftwareClusterSize: 目标平台的软件簇大小
• compressedSoftwareClusterSize：软件包大小

用于信息和跟踪目的

• Vendor: vendor id
• Vendor signature
• Packager: vendor id
• Package signature: 为了包的一致性检查和安全目的。这可以用来对后端包中的软件包进行签名，也可以用来对软件包清单ARXML中包含的数据、可执行文件等进行签名。
• Type approval: 可选的，homologation information
• Release notes: 描述本次发布变化
• License: 比如MIT， GPL，BSD，专有的

为了在车内将包分发给正确的UCM

• Diagnostic address: 比如以防包通过UDS来自tester
• UCM identifier: 车辆架构中的唯一标识符
• Activation action: 可以重新启动，重新启动应用程序还是什么都不做
• Action type: 更新，安装或删除

13.3 汽车包清单

车辆包通常由OEM后端组装。它包含了软件包清单的集合。这些清单是从存储在后端数据库的后端包中提取的。它还包含一个汽车包清单。这个清单包括活动编排和车辆内包分发所需的其他字段。（图13-4）

下面信息描述在汽车包清单中必须包含的字段。

 List of backend packages: SWCL names 列表

 Dependencies: 软件簇之间的依赖性会否决已经在软件包中定义的依赖性。通常由车辆系统集成商用于添加后端包供应商不知道的与车辆系统相关的依赖项。

 Origin: uri, 存储库或诊断地址，用于历史记录、跟踪和安全目的

 Version

 Vehicle target: 版本描述

 Campaign orchestration: 下面是模型例子

比如汽车包可以被车库用来修复下载更新时的问题。因此，类似后端包一样，为了互操作性的目的，汽车包的清单应该时ARXML文件格式。

13.3.4 软件发布和打包流程

为了创建后端包，继承者必须使用和目标UCM 兼容的打包工具。这个打包工具包括目标UCM可以由Adaptive平台栈厂家提供。在集成商装配完可执行程序，清单，持久性等，他可以用这个 打包工具用UCM厂家特定的格式创建一个软件包。接下来软件包会和ARXML软件包清单一起嵌入到后端包中。Adaptive栈厂家打包工具或集成者可以签名这个软件包，签名包含在软件包清单中。由于后端包可以通过以太网在集成者和OEM后端传输，为了避免软件包清单修改，所以软件包和软件包清单以及签名应该被签到一个container中。

被集成者装配的后端包可以放到后端数据库中。当汽车需要更新或新安装文件，后台服务器会从后端数据库查询软件包，然后将软件包清单合并到汽车包的清单中。在这份清单中，后端服务器嵌入根据车辆电子架构选择的活动编排，例如从车辆识别号中扣除。

13.3.5 处理激活软件包

安装、更新和卸载操作是通过ProcessSwPackage接口执行的，在这个接口中UCM能够解析需要执行的操作的元数据。

UCM 序列设计可以支持A/B更新场景或 “in-place”场景（比如 使用OSTree). 如果需要的化，这种设计让包管理者有回滚到之前版本的可能性。

为了让实现更简单健壮，同一时刻只有一个客户端可以使用方法ProcessSwPackage来处理软件包并将UCM状态切换到BUSY。 几个客户端可以按照顺序请求除了传输的包。如果时A/B分区更新场景，多个客户端可以处理正在更新的非活动/B分区; 如果是跨依赖的软件簇，每个客户端必须按序更新B分区。一旦处理结束，UCM的状态会切换到Ready，为了下一次的激活或另一次处理。

不管哪个客户端请求这个，使用Activate方法激活所有已处理的包。为了正确协调多个客户但的场景，可以使用master客户端。UCM可能不知道是否所有的软件都已经被处理了，但是他会执行一个依赖性检查来查看系统是否和在B 分区已安装软件的需求一直。如果依赖性不能被满足，UCM就会拒绝激活并切换到READY状态。

当更新被激活，UCM状态会切换到VERIFYING。然后UCM会根据更新的类型来重置机器或重启功能组合。比如，如果更新包含功能簇操作系统更新，UCM可能需要重启机器。但是，如果更新仅仅是与低重要性的功能相关，仅仅重启功能组合就足够了，来减少驱动的烦恼。在这个阶段，UCM可以从PHM和EM来验证是否目标软件簇可以正常运行。一旦这些重启成功完成，UCM切换到ACTIVATED状态。

当激活更新的时候，其他处理请求会被拒绝直到激活解决。在这个阶段，UCM可以调用Finish或为了或确认这些变化或忽略这些变化回滚（比如这个更新是全局更新的一部分，而另一个ECU更新失败）

调用Finish后，UCM 会清理所有不需要的资源并返回IDLE。

如果调用Rollback， UCM会切换到ROLLING-BACK状态来重新激活旧版本的软件。比如，在这种状态下，如果是A/B分区场景，UCM将会为下一次重启准备A分区来重新激活/执行。

13.4 软件信息报告

为了已处理但未提交的软件和最后提交的软件，UCM提供了服务接口，它公开了检索自适应平台软件信息的功能，比如已传输包的名称和版本号。由于UCM更新过程清理状态，所以UCM提供了每个软件包处理处在哪个状态的信息。

13.5 软件更新一致性和身份验证

UCM会使用覆盖整个软件包的签名来验证软件包如图13-1描述的那样。Adaptive 平台提供了必要的校验和算法， 加密签名或其他厂家/OEM 特定的机制来验证这个包，否则UCM就会返回错误。实际上，为了保证认证算法的兼容性，软件打包工具应该和目标UCM来自同一个厂家。

由于认证算法使用hash，所以当验证软件包的时候也检查了一致性。通过调用TransferData, TransferExit和ProcessSwPackages来验证软件包和检查一致性可以覆盖大部分可能的用例和场景， 但是应在UCM实际处理任何软件包之前执行，以获得最大的安全性。

13.6 保护更新过程

UCM通过ara::com提供服务。在UCM更新协议中没有认证步骤。相反，由身份和访问管理概念来确保通过ara::com请求UCM服务的客户端是合法的。

UCM是不允许在处理时间内更新比目前老的版本软件簇（否则攻击者可以更新一个有已知缺陷的老的包）

13.7 更新进程期间的安全状态管理

与系统设置相关的安全状态的定义是OEM的责任。基于系统设置和应用，系统可能需要切换到一个‘更新状态’，以便它们可以在更新过程中忽略丢失或错误的消息。

另外，更新之后必须做一个最小的检查。因此OEM特定的诊断应用程序会将机器设置为‘验证状态’并且检查是否所有相关的进程都是运行状态。如果某些进程没有切到运行状态，有机会可以执行回滚。图13-9 提供了这个概念的概述。

14 身份及访问管理(IAM)

日益增长的信息安全需求驱动了身份和访问管理（IAM）的概念，因为AUTOSAR Adaptive平台需要和应用程序建立健壮和良好定义的信任关系。IAM为Adaptive应用程序引入了特权分离，并针对攻击时的特权升级提供了保护。另外，在部署期间，IAM能够使集成者提前验证Adaptive应用程序要求的资源访问。IAM为来自服务接口，Adaptive平台基础功能簇和相关模型资源的应用程序的请求提供了访问控制的框架。

14.1 术语

为了理解框架如何工作的，必须提前定义一些重要的概念。也可以参考 RFC3189中的“Terminology for Policy-Based Management” (https://tools.ietf.org/html/rfc3198).

• Access Control Decision: 这个值是布尔值来表明操作请求是否被允许。它是基于调用者的身份和访问控制策略。
• Access Control Policy: 为了访问特定的对象（比如服务接口），这个值是用来定义必须满足的约束。
• Policy Decision Point(PDP): PDP做访问控制决定。它通过检查访问控制策略决定了应用程序是否被允许执行请求的任务。
• Policy Enforcement Point(PEP): PEP会通过从PDP请求访问控制策略来打断来自应用程序请求的控制流程。
• Capability: capability是Adaptive应用程序身份的一个属性。对AUTOSAR资源(例如，服务接口)的访问仅在请求AA拥有该特定资源必须具备的所有功能的情况下才被授予。capability在应用程序的manifest中分配。
• Grant: 在Adaptive应用程序部署期间，设计阶段要求的每项能力都应得到确认。Grant元素在元模型中可用。授权将支持集成商审查功能，但不允许接受部分功能。
• Intermediate Identifier (IntID): 一种标识符，它支持标识正在运行的posix进程并将其映射到已建模的AUTOSAR进程。
• Adaptive Application Identity (AAID): Adaptive应用程序的建模标识由AUTOSAR进程标识
• Adaptive Application Identifier: 一个指向AAID的引用程序，即AUTOSAR进程，仅指向一个AAID。

14.2 IAM框架的范围和重点

IAM框架为Adaptive AUTOSAR 栈和Adaptive 应用程序提供了一种机制，这种机制建模每个应用程序功能，根据访问请求提供访问控制决定并执行控制访问。IAM侧重于提供方法来限制Adaptive应用程序对Adaptive平台基础的接口、服务接口和与功能集群相关的定义良好的资源(例如KeySlots)的访问。特别地，对系统资源(如CPU或RAM)的强制配额不包括在IAM中。

在允许期间，IAM的进程对Adptive应用程序是透明的，除非请求被拒绝并发出通知。

远程Adaptive 平台提供的服务实例请求由IAM覆盖的。传入请求的PDPs必须由Adaptive应用程序实现。

这个框架可以在运行期间执行对AUTOSAR资源的访问控制。假设Adaptive 应用程序将在启动时进行身份验证，并且现有的受保护的运行时环境确保Adaptive 应用程序被正确隔离，并且防止它们的特权升级(例如旁路访问控制)。

14.3 AUTOSAR规范的内容

下面表格说明了IAM框架的哪一部分是由AUTOSAR定义的，哪一部分是由开发人员实现决定的。

描述：IAM需求规范； 隶属于：AUTOSAR规范；包含在RS_IdentityAndAccessManagement中

描述：IAM框架的行为描述（跟接口相关）；隶属于：AUTOSAR规范；包含在SWS_IdentityAndAccessManagement中

描述：在Adaptive平台上实现AA PDP和PEP 之间通信的API；隶属于：AUTOSAR规范；包含在SWS_IdentityAndAccessManagement中

描述：在Adaptive平台上实现功能簇 PDP和PEP 之间通信的API；AUTOSAR没有说明；

描述：应用程序功能和访问控制策略（Manifest 文件信息）；隶属于：AUTOSAR规范；包含在TPS_Manifest_Specification中

描述：认证失败应用程序收到的警告和错误信息的格式和内容；隶属于：AUTOSAR规范；包含在SWS_IdentityAndAccessManagement中

描述：活动日志记录的API；隶属于：AUTOSAR规范；还没决定

描述：日志信息的内容；隶属于：AUTOSAR规范；还没决定

描述：Adaptive 应用程序和功能簇之间的接口；AUTOSAR没有说明；

描述：Adaptive应用程序在运行期间的标识；AUTOSAR没有说明；

14.4 IAM 框架的架构

14.4.1 通用架构

IAM架构夹认证实体按照逻辑划分为两个。一个实体来决定Adaptive 应用程序是否被允许访问资源（PDP），一个实体来执行访问控制决定（PEP）。需要限制对其应用程序接口的访问的功能集群需要实现PEP来执行由PDP提供的访问控制决定。由于这个原因，如果Adaptive应用程序请求访问这样的接口，PEP要和PDP通信。基于请求和应用程序功能，访问控制决定发回送给PEP。访问控制决定的必要信息是基于在Adaptive应用程序的应用清单中的功能的。这个应用清单初始化请求和策略。策略表示应用于接口的规则。例如，Adaptive应用程序为了收集访问必须完成的准备工作。对于访问控制下的每个资源，策略都在功能集群的规范中定义。

准备工作和假设

• 应用程序被设计/配置为具有功能(允许它们访问某些资源的属性)。
• 每一个功能都将在部署期间得到确认。
• 部署的应用程序将进行加密签名，以使真实性验证成为可能。
• 应用程序与包含功能的应用程序清单一起部署。
• 受IAM约束的Adaptive应用程序必须按顺序认证启动，其清单必须在部署期间进行身份验证。PEP解释请求并要求PDP做出策略决策（可能在同一个进程中实现）.

14.4.2 Adaptive 应用程序的识别

为了从PDP请求策略决定，PEP不得不决定调用Adaptive应用程序的身份。因为每个调用都是通过进程间通信进行中介的，所以中间件也必须支持这个标识。

标识本身是对已建模的AA的引用。功能绑定到portprototype，因此也绑定到SWComponentType(参见清单规范)。

IAM框架没有完全指定AAs的标识。最合适的解决方案在很大程度上取决于堆栈供应商选择的操作系统和平台。许多现代操作系统确实支持通信端点上对等点的标识(参见Linux中的SO_PEERCRED、getpeerid()或QNX中的消息传递)。在不支持这个机制的平台上，在消息级实现协议可能是合适的。

由于EM创建通过建模的AUTOSAR进程创建Adaptive应用程序的允许实例，它负责跟踪正在运行的进程的属性(即运行Adaptive应用程序的PID)或分配属性如设置专用的UID，或负责为消息级实现分配key或uuid。EM应使PEP能够为对PEP的每个有效请求找到建模的Adaptive应用程序。

PEP应该在Adaptive Foundation中实现，并且应该与调用Adaptive应用程序适当隔离。Adaptive应用程序不应提供PDP，因为其本身受请求操作的访问控制。

14.4.3 IAM序列

1. Adaptive 应用程序(AA)发起对资源的请求（比如服务接口）

2. PEP打断控制流

3. PEP通过EM解析请求进程的标识。

4. PEP将调用者的标识和请求参数传递给PDP。

5. PDP检查AA的功能是否足够，并将访问控制决策返回给PEP。

6. PEP通过阻止或允许请求来执行访问控制决策。

传输库与EM用来识别AAs的机制是一致的。举个例子：通过使用POSIX-Process-IDs，EM在调用fork()期间追踪从操作系统检索的PID。EM通过一个受保护的功能簇接口提供这个消息给PEPs。在使用UID时，EM应该主动地设置新的POSIX进程的UID。

14.4.4 策略决定点的实现

策略决策点为二进制策略决策处理的清单提供接口。这些决策基于定义良好的Adaptive应用程序的功能及其应用程序清单。

功能由单个功能集群特定语义的portprototype建模。因此PDP不得不为这些功能提供特定的接口。IAM框架不推荐也不支持通过功能来处理功能集群的单个方法。相反，能力是以资源为中心的。PDP通过检查对所请求资源的AAs引用来提供策略决策。

Crypto API提供了一个功能示例。通过给KeyOwner分配一个参考特定建模密钥的功能，可以允许对key进行修改操作。

在受信任的Adaptive应用程序实现PDP的应用程序场景是可能的，并且在SWS_IdentityAndAccessManagement中说明。关于这个场景的用例信息在AP18-10提供。

14.5 平台之间的通信

由于应用程序时分布在不同的ECU或虚拟机上，所以我们必须处理跨平台的身份和访问管理。下面的图片举了一个例子。

如上面右手边描述的，平台实例A实现了一个PEP去检查应用程序A的访问权限。在这我们假定PDP是在OEM特定的Adaptive应用程序中实现的。在左边的平台实例B中，我们希望实现第二个PEP，它也连接到OEM特定的PDP。第二个PEP是非常必要的以防在A被破坏并且不再可靠地执行策略时。然后，第二个PEP检查是否至少允许A的一个应用程序访问B上的Adaptive应用程序Y。然后，第二个PEP检查是否至少允许A的一个应用程序访问B上的自适应应用程序Y。

一个实例的所有功能集需要与其他实例同步，以便第二个PEP能够提供正确的实施。由于Adaptive平台没有标准的交换格式，所以我们建议使用OEM特定的格式来描述功能。这允许OEM定义自己的同步协议，即使是非autosar平台。

14.6 IAM的实现和使用

下面列表说明了对FC实现这或系统设计这使用IAM必要的步骤。更多的信息可见AUTOSAR_EXP_FCDesignIdentityAndAccessManagement.pdf。请注意上面文档描述的信息来自AUTOSAR 论证者，仅可被视为实现建议或例子。

准备步骤（在设计的时候）：

• 应用程序被设计/配置为具有功能(允许它们访问某些资源的属性)，并且只能看到特定的服务接口。
• 部署的应用程序将进行加密签名，以使真实性验证成为可能。
• 应用程序和包含功能的执行清单一起部署
• 执行清单还包含诸如应用程序ID，有多少应用程序实例以及这些应用程序实例ID之类的信息。
• FC实现PEP的实施逻辑。
• FC和策略一起部署。这些策略描述了那些功能需要访问提供的服务接口。

使用知道（运行期间）

• 在Adaptive平台启动期间，OEM会提供一个应用程序（实例）IDs和进程IDs 之间的查找表
• 当Adaptive应用程序请求访问配置了访问控制的服务时，需要对其进行身份验证，以使引用其功能成为可能
• PEP 将查询实现PDP进程的请求（可以是同一个进程）
• 然后，PDP检查应用程序ID及其相应的功能，并将其与FC的存储策略进行比较
• PDP发送访问控制请求（yes/no）回答PEP
• PEP实施访问控制请求（基于这个决定授权访问）

总结上述步骤，至少应考虑以下几点:

FC实现者需要：

• 提供下面放在服务清单中的规则

       1. 访问某些服务需要哪些功能(单个或多个功能的组合)
  

• 访问实现PDP进程的逻辑实现

• 实施收到的访问控制决定的逻辑实现

应用程序开发者需要：

• 配置允许访问服务的功能。

15 加密

AUTOSAR Adaptive平台支持通用加密操作和安全密钥管理。API支持动态密钥生成和运行期间的加密工作以及对数据流进行操作。为了降低存储需求，密钥可以存储在加密后端内部，也可以存储在外部并根据需要导入。

API的设计支持在单独的组件中安全敏感操作的封装和决定，比如硬件安全模块（HSM）。可以通过限制特定用法的密钥(例如，仅解密)，或者根据IAM的报告限制单个应用程序的密钥可用性，来提供对密钥和密钥使用的额外保护。

根据应用程序的支持，当处理加密协议比如TLS和SecOC的时候，API也可以用来保护会话密钥和中间隐私。

安全架构

虽然AUTOSAR AP只定义向应用程序公开的高级加密堆栈API，但是该API在定义时考虑了安全体系结构，设计该体系结构是为了满足上述安全性和功能需求。

图15-1描述了通用的架构。在最高层，AUTOSAR AP，以及本地和混合应用程序，链接到AUTOSAR AP加密堆栈API。API实现可以引用一个中央单元(加密服务管理器)来实现平台级的任务，比如跨应用程序的访问控制和证书存储。这个实现也可以使用加密服务管理器来协调加密驱动的负载转移功能，比如硬件安全模块（HSM）。事实上，加密栈API的卸载转移功能，这种方式是一种典型的实现方式：为了加速加密操作和保护托管密钥免受恶意应用程序的攻击，加密驱动可能实现密钥管理和加密功能。

为了实现这个层级的安全架构，Crypto Stack API不仅执行批量加密操作，还为以下功能提供了本地支持:

（1）使用加密密钥或密钥句柄进行操作

（2）安全管理密钥，以防可能有些程序不合格

（3）限制应用程序对密钥的访问并允许对密钥进行操作

密钥管理架构

为了支持密钥的安全远程管理，尽管存在潜在的应用程序危害，Crypto Stack继承了一个密钥管理架构，以端到端的保护方式来管理密钥和相关数据。密钥可以基于现有的配置密钥以受信任的方式引入系统，也可以通过本地密钥生成以不受信任的方式引入系统。假设有适当安全的加密后端/驱动程序，应用程序不能修改密钥，除了能通过定义良好的、经过授权的请求(如密钥更新或撤销)来修改密钥。

API扩展备注

需要引入新的或修改的权限/策略验证逻辑的重要新用法和交互应该绑定到相应的新密钥使用策略标志。例如：通过添加相应的新密钥使用策略并在涉及这些新密钥的所有密钥管理操作中强制执行新逻辑，可以引入具有不同所有权/权限检查的备用密钥。

16 日志跟踪

16.1 概述

日志跟踪功能集合负责管理和装配AUTOSAR Adaptive 平台的日志功能。平台可以在开发和生产中使用日志跟踪功能。这两个用例不同。日志和跟踪组件允许对日志进行灵活的插装和配置，以覆盖整个范围。日志信息可以根据配置转发到多个接收器，比如通信总线，系统中的一个文件和一个串行控制台。提供的日志信息被标记为多个严重等级并且日志和追踪组件可以被装配某个严重等级之上的日志信息，这支持对日志客户端上的问题进行复杂的过滤和直接的故障检测。AUTOSAR Adaptive平台和日志功能集合负责维护平台稳定性，而不是让系统资源过载。

日志和跟踪依赖于AUTOSAR联盟内标准化的LT协议。这个协议保证日志信息打包成标准发布和展示的格式。此外，LT协议可以在日志信息中加入额外的信息，比如ECU ID。这个信息可以被日志客户点用来关联，分类或过滤收到的日志帧。

另外，提供通用的方法。例如 将十进制转换成十六进制或二进制。为了使应用程序能够向日志和跟踪提供符合LT协议的标准化序列化格式的数据，这些是必需的。

16.2 架构

命名空间ara::log提供了日志追踪接口，这样应用程序可以将日志信息转发给之前提到的日志接收器。

日志追踪接口依赖于后端的实现，它是日志框架的一部分。这个日志框架可以使用其他的功能集合来满足某些功能，比如时间同步或通信管理。

17 安全

17.1 安全概述

AUTOSAR提供了Adaptive平台的安全概述来支持在安全项目中Adaptive 平台的集成。这个概述发布在一个解释文档中（AUTOSAR_EXP_SafetyOverview）。

这个文档帮助功能安全工程师在标识在AUTOSAR Adaptive平台中功能安全相关的话题。本文件的内容目前分为以下几个章节，可以根据ISO 26262在内容和结构上进行映射:

• AUTOSAR Adaptive平台目标，用例和使用场景
• 系统定义，系统上下文和假设
• 危害分析
• 安全目标
• 功能安全概念和功能安全需求

这个功能概述的目标是从顶级安全目标和假设的用例或场景中推导出安全需求并将它们分配给项目的架构元素，或者分配给外部度量。使用AUTOSAR Adaptive平台并不意味着遵从ISO 26262。使用AUTOSAR Adaptive平台的安全措施和机制是有可能构建不安全的系统的 。在最好的情况下，AUTOSAR Adaptive平台的架构只能被认为是SEooC。

这个解释文档包含假设，典型的项目，比如参考模型、用例、场景和/或示例技术解决方案、设备、流程或软件的参考。这篇文档里包含的任何嘉禾或参考项仅仅是说明目的。这些假设不是AUTOSAR标准的一部分。

本章功能安全概念和初始功能安全要求仍在开发和开放讨论，不应该被认为是成熟的最终版本。

本章：

• 技术安全概念和技术安全需求
• 安全需求的验证、安全分析和典型用例将安排在以后的版本中。

17.2 信息交互的保护（E2E-Protection)

AUTOSAR支持E2E配置文件，以允许AUTOSAR AP和CP实例的所有组合之间进行安全通信，不论它们是在相同或不同的ECU。在有用的地方，将提供机制来允许使用Adaptive平台中面向服务的更多功能进行安全通信。提供的功能提供了在传输过程中验证发送给发布者的信息和收到的订阅者的信息的可能性。根据AUTOSAR CP中的E2E机制，在E2E上下文中不提供传输确认和传输安全。

在发布者和订阅者之间使用E2E保护的时候，发布进程会同步调用E2E保护。在订阅这边，在接收订阅者进程中的数据时调用E2E检查。

这次发布E2E支持：

• 轮询模式中的周期事件和混合周期事件

周期事件E2E保护的原则是事件发布者序列化事件数据和增加E2E头部。当接收事件的时候，订阅者会反序列化消息和允许E2Echeck，E2Echeck会发挥一个结果表明是否在传输过程中发生了任何可检测的故障(由E2E配置文件定义)。

还没有支持的有

• callout模式中的事件
• 非周期性事件
• 方法

E2E保护使用的配置文件在AUTOSAR基础中描述（AUTOSAR_PRS_E2EProtocol）。

17.3 平台健康管理

平台健康管理监管软件的执行。它地宫了下面的监管功能（所有的监管功能可以被单独调用）：

• Alive 监管
• Deadline 监管
• 逻辑监管
• 健康频道监管

Alive监管检查被监管实体的运行不是太频繁，也不是太罕见。

Deadline监管检查被监管实体的步骤是否被在配置的最大和最小限定事件内执行。

逻辑监管检查执行期间的控制流是否和 设计的控制流皮皮额。

健康频道检查提供将外部监控结果(如RAM测试、电压监控等)与平台健康管理挂钩的可能性。

如果在被监管的实体中检测到失败，平台健康管理可以出发一个可配置的恢复动作。

对AUTOSAR Adaptive平台来说，下面的恢复动作是可用的：

• 请求状态管理切换到特地的机器状态，功能组合状态或应用程序状态。
• 请求执行管理强制切换到一个特定的机器状态或功能组合状态（EnterSafeState API). 如果状态管理有被监管机制探测到的问题，这个动作可以配置替代状态管理对应的API。
• 请求执行管理重启特定的进程（ProcessRestart API）。
• 请求watchdog驱动执行watchdog重置（实现者特定API）。
• 给诊断管理报告错误信息：在本次发布中没有说明。
• 转发错误信息给其他的PHM实体或应用程序：在本次发布中没有说明。

本次发布中已知的限制

• 目前仅支持一个PHM实例。当前不支持多个PHM实例和多个实例的菊花链接。
• 诊断管理的依赖性还没有定义
• 监管模式相关的健康管理配置在本次发布中还没有完全支持。

AP和CP共享的功能在基础文档中描述并命名为“Health Monitor” （RS_HealthMonitoring, SWS_HealthMonitoring）。

AP其他的规范在AP仅在AP文档中描述并命名“Platform Health Management” (RS_PlatformHealthManagement, SWS_PlatformHealthManagement).

18 核心类型

核心类型定义了多个功能集合使用的通用类和功能，作为它们公共接口的一部分。定义核心类型的一个原理是包含在接口定义中经常使用的通用复杂数据类型。

18.1 错误处理

概述

对任何软件开发来说错误处理都是一个重要的话题。对于关键安全软件，它更重要，因为软件生命要依靠它。但是，当前的安全关键软件开发标准对构建工具链施加了很大的限制，特别是在c++异常方面。对于ASIL应用程序，使用c++异常通常是不可能的，因为ASIL认证的c++编译器缺乏对异常的支持。

Adaptive 平台引入了一个概念使错误处理没有C++异常，并且定义了大量的C++数据类型来辅助。

从应用程序开发者的角度，实现这个概念的核心类型是ara::core::ErrorCode和ara::core::Result.

错误码

ara::code::ErrorCode的一个实例表示软件内一个特定的错误条件。它类似于std::error_code，但是在很多方面都不相同。

一个错误码一直包含一个枚举类型（将类型擦除为整型）和一个对错误域的引用。枚举值描述一个特定的错误类型，错误域的音乐定义了错误应用的上下文。其它可选的成员是一个用户定义的信息字符串和一个厂家定义的额补充错误描述值。

在Adaptive 平台内部，每个功能集合定义了一个或多个错误域。比如，功能集合“Core Type”定义了错误域“Posix”，这个错误域包含了POSIX 1已经定义的错误码。它们相当于c++ 11标准中的std::errc。

结果

类ara::core::Result是一个打包类型，它包含了一个值或一个错误。因为模板特性，值和错误可以是任何一种类型。但是，错误类型默认为ara::core::ErrorCode，并希望在整个Adaptive平台保持。

因为错误类型有个默认值，所以ara::core::Result大部分的生命仅仅需要给值一个类型。比如 ara::core::Result 包含一个int 或 ara::core::ErrorCode。

包含的值或错误可以通过成员函数Result::Value 或 Result::Error来访问。确保仅当结果实例分别包含一个值或一个错误时才调用这些访问函数是调用者的责任。比如Result::HasValue可以查询一个值或一个错误。没有成员函数抛出异常，因此可以在不支持C++异常的环境中使用。

除了上面描述的无异常工作流之外，类ara::core::Result允许通过调用ara::core::Result::ValueOrThrow将包含ara::core::ErrorCode转换成C++异常。此调用按原样返回任何包含的值，但是通过抛出相应的异常类型来处理包含的错误，该异常类型自动派生自包含的ara::core::ErrorCode的内容。

将来和承诺

与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， 从Future中返回一个包含一个值或一个错误的对象ara::core::Result。

这两条调用会block直到这个值或错误通过异步调用方法可用。

18.2 高级数据类型

除了前面部分提到的AUTOSAR设计的类型，Adaptive平台也包含大量的通用数据类型。

部分这些类型已经包含在C++11标准中；但是，大部分相同行为的类型在ara::core命名空间重新定义。原因是std::types的内存分配行为对汽车来说不适用。因此，ara::core定义了他们自己的内存分配行为。

这种数据类型的例子是vector, map, 和string。

其它定义在ara::core中的类型已经被定义或建议给新的C++标准。Adaptive平台把他们包含进了ara::core命名空间，因为他们对于支持某些清单的构建是必须的，或因为它们被认为在API中非常有用。这种数据类型的例子是string_view, span, optional和variant。

18.3 原始数据类型

存在另外一个文档AUTOSAR_SWS_AdaptivePlatformTypes，它定义了可以用在服务接口描述中的原始类型。这个文档将来会考虑和顶到核心类型文档中。

18.4 全局初始化和关闭功能

下面的函数对Adaptive应用程序来说，初始化和反初始化对应的数据结构和AUTOSAR运行事件的线程是非常有用的：

• ara::core::Initialize
• ara::core::Deinitialize

ara::core::Initialize初始化应用程序的数据结构和AUTOSAR Adaptive运行时的线程。在此调用之前，不可能与ARA进行交互。这个调用必须在main()函数中。比如在保证静态内存初始化完成的地方。根据个人功能集合规范，调用应用程序需要提供额外的配置数据（比如日志要求的Application ID)或额外的初始化调用（比如在ara::com中启动FindService），然后才能对相应的功能集群进行其他API调用。这些调用必须在调用Initialize()之后。在静态初始化完成之前调用ARA API可能导致未定义的行为。在静态初始化完成之后但是在Initialize()之前调用会被功能集合实现拒绝并报告错误。如果没有定义报告的错误，会导致未定义的行为。

ara::core::Deinitialize破坏应用程序所有的数据结构和AUTOSAR Adaptive运行时的线程。调用必须在main()函数中，比如在保证静态初始化已经完成并且静态初始化数据析构还没有开始的地方。对ARA API的嗲用在ara::core::Deinitialize()之后但是在静态初始化数据析构之前会被拒绝并报告错误。如果没有定义错误，会导致未定义的行为。在静态初始化数据析构之后调用ARA API会导致未定义的行为。

Adaptive AUTOSAR 平台接口使用指南

1 本文的介绍

1.1 内容

虽然FC的SWS 是ARA接口规范，但有些接口需要如何使用的“指南”。这份指南确实跟规范相关，但是有些是间接的，并且在每个SWS中都包含这些信息，因此读者很难理解其用法。另一个重要的角度是这些指南是AA 遵守的需求，但是FC的SWS是FC的需求规范。因此，在SWS中包含这些内容不太合适，这就是这本文档的目的。

如上所述背景，这份文档的主要内容是应用程序遵守的指南。不是所有的FC在这份文档中有内。当它认为有效时，它们将被添加。

内容是按照相关的话题组织的，但是一般情况下，按照FC组合一起，每个都有独立的章节。并且，请注意这些内容提供在单独的AUTOSAR AP 文档中。如果是这种情况，这种文档会被列出来或引用这份指南。

1.2 预读

这份文档是AP SWS的补充文档。因此，这份文档里的话题相关的SWS应该同步阅读。并且，应该阅读的第一份文档是Explanations of Adaptive Platform Design, AUTOSAR_EXP_PlatformDesign.pdf.，这份文档介绍了AP的架构

1.3 和其他AUTOSAR规范的关系

参考内容和预读

2. 核心类型

2.1 错误处理

错误处理对任何软件开发都是重要的话题。对于安全关键软件，它更重要，因为软件生命要依靠它。但是，目前的标准对安全关键软件的开发加了很多的限制，比如创建工具链，特别是关于C++异常。对ASIL应用程序，使用C++异常通常是不可能的因为缺乏对asil认证的c++编译器的异常支持。

Adaptive平台介绍了一个概念使没有C++异常的错误处理成为可能并定义了大量的c++数据类型来辅助这个概念。

从应用程序编码者的观点来看，核心类型实现这个概念的是 ara::core::ErrorCode和ara::core::Result.

2.1.1 ErrorCode

ara::core::ErrorCode的实例表示软件内的一个特定的错误条件。和std::error_code类似，但是在很多方面都不相同。

ErrorCode一直包含一个枚举值（类型擦除为整型）和一个错误域的引用。这个枚举值描述了错误的特定类型。错误域引用定义了错误应用的上下文。其他可选的成员一个是用户定义的消息字符串，一个是厂商定义的补充错误描述值。

2.1.2 Result

类ara::core::Result遵守来自C++建议 p0786中“ValueOrError”的概念。它包含一个value或一个error。由于模板特性，value和error可以是任何类型。但是，错误类型默认为ara::core::ErrorCode，而且希望整个Adaptive平台都能保持这个分配。

因为ErrorType默认为ara::core::ErrorCode，ara::core::Result的大部分声明仅需要给一个ValueType，比如对Result类型ara::core::Result包含一个int变量或一个ErrorCode.

ARA接口使用ara::core::Result作为可恢复错误函数的返回类型。这个类型或者用来从对象中生成C++异常，或通过未使用异常的观察者方法中提取错误信息。

这部分指导你在应用程序代码中如何处理从ARA接口中返回Result对象。并且指导你如何在自己的Adaptive应用程序中创建新的Result对象。

2.1.2.1 Result的创建

使用嵌入值创建Result，有构造函数允许从ValueType隐式转换。这样用value来定义Result非常直接。

Result res1(42);

Result res2 = 42;

从声明返回Result的函数中返回一个value也是同样的直接。

Result myfunction()

{
return 42;

}

把error放进Result中需要调用显示构造函数，比如：

ErrorCode ec = MyEnum::some_error;

Result res2(ec);

另外，在静态成员函数中构造Result对象也是可能的。比如：

Result res1 = Result::FromValue(42);

Result res2 = Result::FromError(ec);

当Value Type或ErrorType Copy 代价非常昂贵的时候，这些形式是非常有益的。比如，返回的Reslut包换一个BigClass的实例。这个BigClass有两个构造参数"a1"和"a2"构建。像这样：

return Result::FromValue(a1, a2);

对于ErrorType，也允许ErrorCode实例的隐式构建，包含一个自定义错误消息和/或一个支持数据值。

return Result::FromError(

MyEnum::some_error, // ErrorCode enum value

“this operation did not work”, // custom error message

0x12345678 // support data value

);

这种形式构建，只需要 执行一次构造函数。不像普通的构造函数调用，至少要执行两次构造操作，因为预先创建的值必须copy或move到Result实例中。

2.1.2.2 提取value和error

当试图从Result中提取value和error的时候，首先要考虑的是value或error是否真实可用。通常情况下，这是未知的，所以必须小心处理者两种情况。

当没有使用异常工作的时候， 要先查询Result对象是否包含value或error.

Result some_function() { … }

Result res = some_function();

if (res.HasValue()) {
int theValue = res.Value();

} else {
ErrorCode const& ec = res.Error();

}

这段代码在没有异常的环境中也可以完全工作，包括编译器完全不支持异常操作。

当处理异常工作流是，查询代码看起来更像普通的异常代码：

Result some_function() { … }

int theValue = some_function().ValueOrThrow();

由some_function()返回的Result对象通过调用它的ValueOrThrow()成员函数快速归到它的ValueType（int）。事实上，如果Result确实包含一个ErrorCode,会立刻抛出一个对应到嵌入的ErrorCode对象的异常类型。自然，try…catch快应该添加到代码中一个合适的位置。

2.1.2.3 高级话题

提取嵌入的value或error两个借本的方法是Result::Value()和Result::Error()。但是，在调用任何这些函数时，必须确定Result对象确实包含调用这些函数之一所隐含的内容。在前面的部分，首先调用Result::HasValue(), Value()或Error()的调用依赖这个调用的输出。

另外一个访问嵌入value更方便的方式，之前的部分已经提过，通过调用Result::ValueOrThrow, 不需要if语句，整个调用只需要单行语句（不包含try…catch块，这个块可能在其他地方存在）。

其他方便的方法，比如Result::ValueOr提取value, 如果不存在就取默认值。比如：

int res = some_function().ValueOr(42);

Result :: ValueOr的一般化称为Result :: Resolve，它不使用默认值作为参数，而是一个Callable，它可按需创建默认值：

int res = some_function().Resolve([](ErrorCode const& ec){ return 42; });

对这种特殊的例子，使用Result::Resolve而不是Result::ValueOr没有意义。但是当常见默认值代价很昂贵的时候，可能是有意的。通过使用Result::Resolve，只有当确实需要的时候才会创建默认值。

另外一个方便的方法是Result::Bind，允许将包含的value转成另外一个value，甚至是另外一个类型，比如：

Result res = some_function().Bind([](int v){ return v + 1; }).Bind([](int v){ return std::to_string(v); }).Bind([](String const& s) { return “’” + s + “’”); });

第一次调用Result::Bind()获取包含在Result对象中的value，加1之后，放入一个新的Result对象中并返回。

第二次调用Result::Bind()获取包含在Result对象中的value，将它转换成String，返回新的带有此字符串的Result。

最后一次调用Result::Bind()获取包含在新的Result对象中的String对象，加上引号，放入其中并返回新的Result对象。

如果Result没有包含value， 那么这些可调用项都没有，Result对象仅进行类型转换，但保留原始的ErrorCode。

传递给Result :: Bind的Callables必须采用合适的类型作为参数，并且可以直接返回ValueType（如之前所说，或者和前面ValueType相同，或者一个新的，不同的ValueType)，或Result。

3 执行管理

3.1 执行状态

执行状态描述了任何进程的内部生命周期。每个进程都需要给执行管理报告执行状态的变化，使用ExecutionClient::ReportExecutionState()接口。

一旦进程启动，当报告了KRunning状态，执行管理就认为进程初始化完成（见[SWS_EM_01053]）。请注意Service Discovery会引入不确定性的延迟，因此建议在报告kRunning状态后进行；因此进程有可能在报告KRunning状态时初始化还没有完成。

执行管理通过向进程发送SIGTERM信号来启动进程终止。一旦收到SIGTERM，进程通过向执行管理报告kTerminating状态确认状态变化请求（见SWS_EM_01070）。

如果是自终止进程，进程会通过想执行管理报告kTerminating状态来启动自终止（见[SWS_EM_01071）。

报告kTerminating之后，进程会保存持久数据并释放所有内部使用的资源。进程通过简单的推出表明Terminating状态的完成（伴随合适的退出码）。执行管理不需要进程本身明确的进程终止的通知。

3.2 确定性执行

执行管理支持完全确定的进程多线程执行，因此处理给定的输入数据会在限定的时间内产生一直的输出，比如行为是可重现的。

在AUTOSAR Adaptive平台中，要求这种确定性的用例包括在高安全目标系统的软件Lockstep框架中的冗余执行和重用已验证的软件。更多的细节可以见Specification of Execution Management, AUTOSAR_SWS_StateManagement.pdf，“Deterministic Execution”部分。

可以完全确定地执行的进程必须以某种方式设计，实施和集成，使其独立于其他功能和计算，零星无关事件，竞争条件，偏差随机数等导致的处理器负载。

不确定行为可能有不同的原因造成，比如，计算资源不足或数据的不协调访问，很可能是由多个处理器内核上运行的多个线程造成的。线程访问数据的顺序也会影响结果，是结果不确定。

完全确定的执行包括：

• 时间确定。计算的输出一直在给定的最后期限前产生。进程的资源需求需要以标准的方式描述，所以集成者能给进程分配足够的资源。（见Specification of Execution Management, AUTOSAR_SWS_StateManagement.pdf，“Real-Time Resources”部分）。
• 数据确定。给定相同的输入和内部状态，计算也一直会产生相同的输出。这个部分剩下的部分将会描述如何达到数据确定。

执行管理提供DeterministicClient库功能来支持确定执行。

• 通过等待点API控制流程内部周期WaitForNextActivation()（[SWS_EM_01301]）。当API返回时，进程应执行一个循环，然后再次调用API以等待下一次激活。这个API的返回值控制进程的内部生命周期（比如：初始化，运行，终止），必须对其进行相应的准备。([SWS_EM_01302], [SWS_EM_01303] and [SWS_EM_01304]).
• 阻塞确定性工作程序池API RunWorkerPool（）（[SWS_EM_01305]），用于执行一组容器元素（[SWS_EM_01306]），这些容器元素由同一工作程序运行对象（即应用程序功能）并行或顺序处理。
• APIs GetActivationTime() ([SWS_EM_01310]) 和 GetNextActivationTime() ([SWS_EM_01311]) 提供激活时间戳。这个时间戳不会改变指导进程达到下一个等待点。
• API GetRandom()提供随机数([SWS_EM_01308])。如果从工作程序池中使用，则将随机数分配给特定的容器元素，以允许确定性的冗余执行。

为了保证确定行为，确定性用户进程只可使用只有所有可用API的“确定性”子集，包括工作程序运行对象：

• 进程不允许通过自己使用普通POSIX进程创建线程或直接访问任何其他POSIX APIs，以规避包含不确定行为的风险。
• 进程只允许使用所有可用的ara::com机制的“确定性子集”。稍后将提供此类API和机制的详细列表。
• 只有下面的ara::exec接口被使用：DeterministicClient和ExecutionClient。
• 用户进程不允许访问其他ARA接口。

如果使用工作程序池API RunWorkerPool()，处理容器元素的工作程序运行对象，比如计算工作，需要满足某些实现规则来确保数据确定性：

• 运行对象在它运行的时候不允许交换任何信息。比如，它不会访问可运行对象的其他实例可以更改的数据，以避免出现竞争情况。

原理：运行对象可以物理的并行运行或以任何顺序有序运行。不能保证单个工作程序的时间。操作系统单个调度线程。相同数据的同时影响会导致不确定的结果。

• 除了通过从RunWorkerPool（）返回对于所有工作程序来说通用的联接，没有锁和同步点（例如，没有信号/互斥量，没有锁/阻塞）。

原理：锁定/阻止使Process运行时不确定。提供了工作程序以增加运行时的利用率。 如果需要同步，则必须从RunWorkerPool（）返回。

工作程序池不能用来并行处理多个不同的任务。使用多个可能不同的显式函数（工作程序可运行的对象）可能会增加不必要的复杂性，并可能导致运行时间利用率极不相同，因为每个工作程序有不同的计算时间。这会使资源部署的计划复杂化，这对于黑盒集成来说是必需的。

工作程序池用户的实现例子。比如：工作程序运行对象的例子：

class MyWorker1

public DeterministicClient::WorkerrunnableBase<myContainer::

value_type, MyWorker1>

{
public:

void worker_runnable(myContainer::value_type& container_element,

DeterministicClient::WorkerThread& t)

{
// Get a unique and deterministic pseudo-random number}

uint64_t random_number = t.GetRandom();

}

};

工作程序线程对象：

class DeterministicClient::WorkerThread

{
// returns a deterministic pseudo-random number}

// which is unique for each container element}

uint64_t GetRandom();

…

};

4 状态管理

4.1 AUTOSAR Adaptive（平台）应用程序的交互

4.1.1 基本的状态管理功能

状态管理通过ara :: com提供了一组“Trigger”和“Notifier”字段。状态管理本质上侦听“Trigger”，并在内部执行特定实现的状态机处理，并在“Notifier”字段（如果有）中提供效果。状态管理还通过它们提供的标准接口与其他FC进行交互。

使用这个机制还可以达到下面的效果：

• 可以要求将功能组设置为专用状态。
• （部分）可以请求取消/激活网络
• 可以请求机器关闭或重启。
• 其他Adaptive（平台）应用程序的行为可能会受到影响
• 可以执行项目特定的动作

其中一些功能至关重要。因此，集成者必须通过IAM管理适当地保护对“Trigger”字段的访问，以免意外更改状态管理的内部状态（并因此而改变相关影响）。

状态管理的内部状态通过其提供的“Notifier”字段通知到系统。对这些字段的读取访问权限不太重要，因此，每当状态管理的内部状态发生更改时，每个Adaptive（平台）应用程序都可以注册其事件以收到通知。

因此，当状态管理的状态发生变化时，每个Adaptive（平台）应用程序都可以执行操作（需要时）。

4.1.2 高级状态管理功能

AUTOSAR Adaptive中的一些用例需要在状态管理所管理的状态中支持同步行为。。比如低功耗模式：一个示例可能是低功耗模式：只有当所有参与此低功耗模式场景的Adaptive（平台）应用程序都最终准备好用于低功耗时，状态管理才能最终切换到低功耗状态（例如，持续存在 其信息）。

因此每个要求支持这种同步工作模式的Adaptive（平台）应用程序必须通过ara::com提供这个字段。状态管理器可以通过FindService找到这个字段，状态管理器可以在以后注册，以便在Adaptive（平台）应用程序执行其操作时收到通知。

Adaptive（平台）应用程序必须完成的三件事，才能支持同步方案：

• Adaptive（平台）应用程序应注册状态管理器的相应“触发”现场事件（在满足状态管理中的条件时通知）

• Adaptive（平台）应用程序应为最终状态做任何准备工作

• Adaptive（平台）应用程序应将先前操作的结果写入其提供的字段

4.2.2 面向服务通信

4.2.2.1 应用程序之间的通信

[RS_CM_00200]通信管理应将全合格的服务ID转换成通信协议特定的服务ID

【类型：草稿

描述：通信管理应将全合格的服务ID转换成通信协议特定的服务ID。开发人员在应用程序代码中使用了完全合格的服务ID，需要对其进行定义以启用不同供应商的服务之间的协作。通信协议的特定的服务ID可以在网络上的消息中使用，如果通信协议服务ID空间不是为完全合格的服务ID设计的，则可能需要特定的通信协议服务ID。

原理：应用程序的二进制文件应不知道通信协议特定的服务ID。

依赖：–

用例：多个汽车生产线使用一个平台，但是对于两个汽车生产线，Service ID对平台来说是不一样。通信绑定也是用全合格的服务ID。通信管理将全合格的ID转换成SOME/IP服务ID。

支持材料：见Adaptive平台场景。】

[RS_CM_00204]通信管理应将协议独立的面向服务的通信映射到已配置的协议绑定，并应相应执行协议。

【类型：草稿

描述：通信管理应将协议独立的面向服务的通信映射到已配置的协议绑定，并应相应执行协议。应用程序代码应独立于实际配置的协议使用面向服务的通信。通信管理的责任是实现特定的协议。

原理：应用程序的二进制文件应不知道通信协议特定的服务ID。

依赖：–

用例：多个汽车生产线使用一个应用程序但是在两个汽车生产线上使用的通信协议是不同的。比如：在一个例子中使用SOME/IP，在另一个例子中使用本地IPC。

支持材料：–】

[RS_CM_00315] 通信管理应支持已配置的协议绑定的改变而不需要Adaptive应用程序重新编译。

【类型：草稿

描述：由于特定网络协议绑定的选择是集成商驱动的部署决策，因此特定网络协议绑定选择的任何更改或特定网络协议绑定的各种属性和参数的更改都应是可能的，而无需重新编译涉及的Adaptive应用程序。对所涉及的Adaptive应用程序的要求更改应限于所涉及的Adaptive应用程序的重新链接（静态或动态）。

原理：应用程序的二进制文件不知道具体的配置的协议绑定。具体协议绑定应在应用程序二进制文件的部署时间内可配置/更改。

依赖：–

用例：应用程序的二进制文件应可在各种不同的部署方案中使用。比如在一个部署场景中使用SOME/IP协议绑定，在一些其他的部署场景中使用本地IPC协议。

支持材料：见Adaptive平台场景。】

[RS_CM_00205]通信管理应实现SOME/IP服务发现协议，SOME/IP协议和E2E监控（E2E协议）。

【类型：草稿

描述：通信管理应实现SOME/IP服务发现协议，SOME/IP协议和E2E监控（E2E协议）。在AUTOSAR SOME/IP服务发现协议规范，AUTOSAR SOME/IP协议规范和AUTOSAR E2E协议规范。SOME/IP 协议和E2E协议SOME / IP和E2E协议应实现为独立的协议层，两者之间没有依赖性。

原理：Classic 和 Adaptive AUTOSAR 都支持SOME/IP协议和E2E协议。

依赖：–

用例：雷达，摄像机和SensorFusion应用程序使用SOME / IP协议通过以太网进行通信。安全相关应用程序通过非安全相关总线（例如以太网，CAN）进行通信。

支持材料：–】

[RS_CM_00222]通信管理应将完全合格的服务ID，其实例和事件ID或方法ID转换为E2E数据ID。

【类型：草稿

描述：通信管理应将完全合格的服务ID，其实例和事件ID或方法ID转换为E2E数据ID。

原理：E2E监管独立于总线，并根据数据ID进行操作。

依赖：–

用例：E2E监管用于通信保护和文件系统保护。

支持材料：请参阅基础中的PRS E2E监管】

4.2.2.2 服务发现

[RS_CM_00101]通信管理应提供提供服务的接口

【类型：草稿

描述：应用程序开发人员应能够提供其应用程序提供的服务，以供其他应用程序使用。出于识别目的，应使用完全合格的服务ID提供服务。

原理：为了支持通信，需要一种机制来向其他应用程序提供能够使用它们的服务。

依赖：–

用例：应用程序“ A”为其他应用程序提供挂钟服务。

支持材料：–】

[RS_CM_00102]通信管理应提供发现服务的接口。

【类型：草稿

描述：应用程序开发者应该在运行时能够发现其他应用程序提供的所有服务实例。

原理：为了在运行时建立通信，基于服务的类型和具体的服务实例来发现提供的服务，这样的机制时需要的。

依赖：–

用例：应用程序“ A”搜索另一个应用程序提供的挂钟服务。通信管理找到所有可用的匹配服务实例，应用程序可以选择正确的实例。

支持材料：–】

[RS_CM_00103]通信管理应提供一个接口来订阅由某个服务的实例提供的特定事件

【类型：草稿

描述：应用程序开发人员应能够订阅一个选定服务实例中的一个特定事件。

原理：找到服务类型的实例后，应该可以订阅特定实例的某些事件。

依赖：–

用例：应用程序“ A”订阅了控制点火锁的应用程序的开机事件。

支持材料：–】

[RS_CM_00104]通信管理应提供一个接口，以停止对服务实例事件的订阅

【类型：草稿

描述：应用程序开发人员应能够停止应用程序对服务实例事件的活动订阅。

原理：在订阅了特定服务实例的事件之后，以后应该可以停止订阅。

依赖：–

用例：应用程序“ A”停止订阅开机事件，并且不再接收此类事件。

支持材料：–】

[RS_CM_00106]通信管理应提供一种手段来监视事件的订阅状态

【类型：草稿

描述：应用程序开发人员应能够查询应用程序对服务实例事件的预订的当前状态，或获得有关服务实例事件的预订的当前状态的更改的通知。

原理：应当可以监视/查询预订的实际状态。

依赖：–

用例：应用程序希望跟踪开机事件的订阅状态，并在发生更改时得到通知。

支持材料：–】

[RS_CM_00107]在重新启动提供的服务的情况下，通信管理应提供一种自动更新代理实例的方法

【类型：草稿

描述：通信管理应自动更新服务的代理实例，而客户端不必更新/重新实例化其代理实例。通信管理应自动更新服务的代理实例，而客户端不必更新/重新实例化其代理实例。

原理：可以独立于服务器实例是否已重新启动和/或代理实例的句柄更改而独立使用代理实例。

依赖：–

用例：保存客户端应用程序，以免跟踪订阅状态并在服务器端重新启动的情况下重新订阅

支持材料：–】

[RS_CM_00105]通信管理应提供停止提供服务的接口

【类型：草稿

描述：应用程序开发人员应能够停止该应用程序之前开始提供的服务。

原理：提供服务后，以后应可以停止提供服务。

依赖：–

用例：应用程序“ A”停止提供挂钟服务。

支持材料：–】