AP AUTOSAR 平台设计总体框架全解
本规范描述了技术范围和方法，AP背景、逻辑和物理视图的架构AUTOSAR自适应平台设计的总体框架。全文3.2万多字，建议收藏阅读。
传统ECU主要实现取代或增强机电系统的功能。这些深度嵌入ECU根据连接到车辆网络的其他软件ECU输入信号和信息控制电气输出信号。大多数控制软件都是为目标车辆设计和实施的，在车辆使用寿命内不会发生重大变化。
新的车辆功能，如高度自动驾驶，将引入高度复杂的软件和严格的计算资源要求，必须满足严格的完整性和安全要求，实现环境感知和行为规划，并将车辆集成到外部后端和基础设施系统中。由于外部系统的不断发展或功能改进，车辆中的软件需要在车辆的整个生命周期内更新。
AUTOSAR 经典平台（CP）深嵌式解决了标准 ECU 以上问题 ECU 需求无法满足。因此，AUTOSAR 指定了第二个软件平台，即 AUTOSAR 自适应平台（AP）。AP提供支持无线软件更新等高性能计算和通信机制。专门为 CP 定义的功能(如访问电信号和汽车专用总线系统)可以集成到 AP 但不是标准化的重点。
背后有两种技术驱动因素。一种是以太网，另一种是处理器。
随着车载网络带宽需求的不断增加，Ethernet的引入，Ethernet与传统车载通信技术(如CAN）可以更有效地传输长信息、点对点通信等。CP虽然支持以太网，但主要为传统通信技术设计，优化了传统通信技术，难以充分利用以太网的通信功能并从中受益。
同样，近年来，随着车辆变得越来越智能，对处理器的性能要求也显著提高。多核处理器已与 CP 一起使用，但不仅需要多核处理能力。多核处理器具有数十到数百个核心，GPGPU（通用GPU）、FPGA由于它们提供的性能比传统的性能更好，特殊加速器正在兴起MCU比数量级高几个。越来越多的内核压倒了CP的设计，CP 最初是单核MCU尽管它可以支持多核，但它是设计的。此外，随着计算能力的扩大，即使在数据中心，电源效率也成为一个问题。事实上，这些智能ECU这一点更重要。从半导体和处理器技术的角度来看，受波拉克规则的限制，物理上不可能无休止地增加处理器的频率。扩展性能的唯一方法是使用多个核心并行执行。此外，众所周知，最佳的每瓦性能是通过混合使用不同的计算资源（如多核、协处理器、GPU、FPGA 和加速器一起实现。这叫异构计算 - 现在正在HPC在(高性能计算)中使用这些内容无疑远远超出了CP的范围。
还值得一提的是，处理器和更快的通信具有综合效应。随着越来越多的处理元件像多核处理器一样组合在单个芯片中，这些处理元件之间的通信正变得比传统的更加传统ECU间通信更快更高效。通过新的处理器互连技术(如片上网络)（NoC））实现的。芯片中处理能力更高、通信速度更快的综合效应也促使人们需要一个新的平台，可以扩展系统需求。
AP第三是特征.1节和第3.第二节所述的因素决定了。这种模式不可避免地需要更多的计算能力，而技术趋势为满足这些需求提供了基准。HPC在安全相关字段的空间中，虽然功率和成本效益也非常重要，但它本身带来了各种新的技术挑战。
要解决这些问题，AP采用传统ECU各种不能充分利用的成熟技术，同时允许AP利用创新技术实现最大自由。
可以从上到下使用C 编程。它现在是软件行业和学术界开发新算法和应用软件的首选语言。如果正确使用，应能够更快地适应新算法，提高应用开发的生产力。
为了支持复杂的应用，同时在处理分发和计算资源分配时允许最大的灵活性和可扩展性，AP 遵循面向服务的架构（SOA）。SOA 基于这样一个概念，系统由一组服务(一个服务可以依次使用另一个服务)和一个或多个服务的应用组成。通常，SOA系统化系统的特点，AP也有这些特点。例如，服务可能停留在应用程序同时运行的本地ECU你也可以在远程停留ECU上，该ECU也正在运行AP另一个例子。在这两种情况下，应用代码是相同的，通信基础设施将处理透明通信的差异。另一种看待这种架构的方法是分布式计算，通过某种形式的信息传输进行通信。一般来说，这些都代表着同一个概念。由于快速和高带宽通信(如以太网)的兴起，这种消息传递和基于通信的架构也可以受益。
分布式计算本质上是平行的。不同的应用程序使用不同的服务，SOA 有这个特点。多核处理器和异构计算提供了利用计算能力匹配固有并行性的技术机会。因此，随着多核异构计算技术的进步，AP具有扩展其功能和性能的架构能力。事实上，硬件和平台接口规范只是等式的一部分。操作系统/虚拟机管理程序技术和开发工具（如自动并行工具）的进步也至关重要，这将是由AP实现供应商和行业/学术生态系统。AP也旨在适应这些技术。
重新发明轮子是没有意义的，特别是当涉及到规格而不是实现时。与第3.3.1节中所述，AP采取重用和调整现有开放标准的策略，促进AP从现有标准的生态系统中受益，本身发展更快。因此，在开发中AP在规范中，一个关键点不是引入现有标准提供的新替换功能。例如，这意味着新接口不会随意引入，因为现有标准提供了所需的功能，但接口表面上不容易理解。
AP目标系统通常需要一定程度的安全性和安全性，可能处于最高水平。尽管实现这些要求并不容易，但引入新概念和技术不应破坏这些要求。要应对这一挑战，AP 结合架构、功能和工艺方法。该架构基于SOA分布式计算本质上使每个组件更加独立，不受意外干扰。特殊功能有助于实现功能安全和信息安全，如C 编码指南等指南有助于安全可靠地使用C 等复杂语言。
AP支持应用程序的增量部署，包括动态管理资源和通信，以减少软件开发和集成的脆弱性，从而实现较短的迭代周期。增量部署还支持探索性软件开发阶段。
对于产品交付，AP 允许系统集成商精细限制动态行为，以消除不必要或不良影响的风险，从而实现安全评估。应用程序的动态行为将受到执行清单中所述限制的限制(见第一次 4.6 节）。在设计过程中，多个应用清单的相互作用可能会导致这种情况。然而，资源和通信路径的动态分配只能在配置范围内定义。
AP 动态功能可以从软件配置中进一步删除。动态规划的例子可以是：
-
提前确定服务发现过程
-
动态内存分配仅限于启动阶段
-
除优先调度外，还有公平的调度策略
-
固定过程分配 CPU 内核
-
仅访问文件系统中预先存在的文件
-
应用对 AP API 使用的约束
-
只执行身份验证的代码
平台功能虽然没有直接反映，但是AP旨在适应不同的产品开发流程，特别是基于敏捷的流程。对于基于敏捷的开发，至关重要的是，系统的底层架构是可增量扩展的，并且可在部署后更新系统。AP 应允许这样做。作为概念证明，AP规范和演示（AP演示实现)都是用的Scrum开发的。
如前几节所述，AP 不会取代 IVI/COTS 中的 CP 或非 AUTOSAR 平台。相反，它将与这些平台和外部后端系统(如路边基础设施)互动，形成集成系统(见图 2.1 和 2.2）。例如，CP已经包含了AP支持某些// IP以及其他本地协议。
图 2.1:不同平台的示例部署
图 2. 2 ：AP 和 CP 的示例性交互
AP 定义了运行时系统架构、平台的构成以及它提供的功能和接口。它还定义了用于开发此类系统的机器可读模型。规范应提供有关使用平台开发系统的必要信息，以及实现平台本身需要满足的内容。
图 3.1 显示了 AP 的架构。运行在 （之上。ARA由功能集群提供的应用接口组成，属于或。提供自适应平台基础AP提供自适应平台服务的基本功能AP平台标准服务。AA也可以去别人AA如图所示，提供服务。
无论是自适应平台基础还是自适应平台服务，功能集群接口都来自AA的度来看都是无所谓的 - 它们只提供指定的C++接口或AP将来可能支持绑定的任何其他语言的接口。在接口下层确实存在差异。另外请注意，在 ARA 接口下，包括在 AA 上下文中调用的 ARA 库，可以使用 ARA 以外的其他接口来实现 AP 规范，这取决于 AP 实现的设计。
图 3.1：AP 架构逻辑视图
请注意，图 3.1 包含不属于当前 AP 版本的功能集群，以便更好地了解整体结构。此处未显示的其他新功能集群很可能在 AP 的未来版本中添加。
这些 API 的语言绑定基于C++，C++标准库也可作为 ARA 的一部分提供。关于OS API只有PSE51接口，POSIX标准的singleprocess配置文件作为ARA的一部分提供。选择 PSE51 是为了为现有的 POSIX 应用提供可移植性，并实现应用之间的免干扰性。
请注意，C++标准库包含许多基于 POSIX 的接口，包括多线程 API。建议不要将C++标准库线程接口与本机 PSE51 线程接口混合使用，以避免复杂情况。遗憾的是，C++标准库并未涵盖所有 PSE51 功能，例如设置线程调度策略。在这种情况下，可能需要结合使用这两个接口。
应用的生命周期由执行管理（EM）管理。应用的加载/启动是使用 EM 的功能进行管理的，并且需要在系统集成时或运行时进行适当的配置才能启动应用。事实上，从EM的角度来看，除了EM本身之外，所有功能集群都是应用，它们也以相同的方式启动。图 3.2 说明了 AP 内部和 AP 上不同类型的应用。
图 3.2：应用
请注意，EM 不会决定应用启动或终止的时间和时间。一种特殊的 FC，称为状态管理（SM）控制器，根据系统的设计命令 EM，仲裁不同的状态，从而控制整体系统行为。由于这里的系统是指整个机器AP及其应用正在运行，因此实现的内部行为是特定于项目的。SM 还与其他 FC 交互，以协调整体机器行为。SM 应仅使用标准 ARA 接口，以保持不同 AP 堆栈实现之间的可移植性。
关于AA之间的交互，PSE51不包括IPC（进程间通信），因此AA之间没有直接的接口进行交互。通信管理（CM）是唯一的显式接口。CM 还为机器内部通信和机器间通信提供面向服务的通信机制，这对应用是透明的。CM 处理服务请求/响应的路由，而不管服务和客户端应用的拓扑部署如何。请注意，其他ARA接口可能会在内部触发AA之间的交互，但是这不是一个显式通信接口，而只是各个ARA接口提供的附件的副产品。
AA 和功能群集可以使用任何非标准接口，前提是它们不与标准 AP 功能冲突，并且符合项目的安全/安保要求。除非它们是纯应用本地运行时库，否则应注意此类应用方式保持在最低限度，因为这将影响软件对其他AP实现的可移植性。
[1] 这里讨论了AP的物理架构。请注意，本节中的大多数内容仅用于说明目的，并不构成 AP 的正式需求规范，因为 AP 的内部结构是由具体实现定义的。对 AP 实现的任何正式要求都已明确说明。作为附加信息来源请参阅 [4]，其中更详细地描述了 AP 内部架构。
AP 操作系统需要提供多进程 POSIX 操作系统功能。每个 AA 都实现为一个独立的进程，具有自己的逻辑内存空间和命名空间。请注意，单个 AA 可能包含多个进程，这可以部署到单个 AP 实例上，也可以分布在多个 AP 实例上。从模块组织的角度来看，每个进程都是由操作系统从可执行文件中实例化的。可从单个可执行文件实例化多个进程。此外，AA 可能构成多个可执行文件。
功能群集通常也作为进程实现。功能集群也可以通过单个进程或多个（子）进程实现。自适应平台服务和非平台服务也作为流程实现。
所有这些进程都可以是单线程进程或多线程进程。但是，它们可以使用的 OS API 会有所不同，具体取决于进程所属的逻辑层。如果他们是在ARA上运行的AA，那么他们应该只使用PSE51。如果进程是功能群集之一，则可以自由使用任何可用的操作系统接口。
总之，从操作系统的角度来看，AP和AA只是一组进程，每个进程包含一个或多个线程 - 这些进程之间没有区别，尽管AP的实现可以提供任何类型的分区。这些进程确实通过 IPC 或任何其他可用的操作系统功能相互交互。请注意，AA 进程不能直接使用 IPC，只能通过 ARA 进行通信。
如图 3.1 所示，功能群集可以是自适应平台基础或自适应平台服务。如前所述，这些通常都是过程。为了让他们与AA（也是进程）进行交互，他们需要使用IPC。有两种替代设计来实现这一点。一种是“基于库”的设计，其中由功能集群提供并链接到AA的接口库直接调用IPC。另一种是“基于服务”的设计，其中进程使用通信管理功能并具有链接到AA的代理库调用。通信管理接口在AA进程和服务器进程之间协调IPC。请注意，它是 AA 仅通过通信管理直接执行 IPC，还是通过代理库与服务器直接 IPC 混合使用，这是实现定义的。
为功能集群选择设计的一般准则是，如果仅在AP实例中本地使用，则基于库的设计更合适，因为它更简单有效。如果以分布式方式从其他AP实例使用它，建议采用基于服务的设计，因为无论客户端AA和服务的位置如何，通信管理都能提供透明的通信。属于 Adaptive Platform Foundation 的功能集群是“基于库的”，自适应平台服务是“基于 Service 的”，顾名思义是正确的。
最后，请注意, 只要FC的实现满足FC定义的RS和SWS，FC实现允许不具有进程而是以库的形式实现在AA进程的上下文中运行，在这种情况下，AA 和 FC 之间的交互将是常规过程调用，而不是如前所述基于 IPC 的交互。
通常，功能集群可以以特定于AP实现的方式相互交互，因为它们不绑定到ARA接口，例如PSE51限制了IPC的使用。它确实可能使用其他功能集群的ARA接口，这些接口是公共接口。功能群集的一个典型交互模型是使用功能群集的受保护接口来提供实现功能群集的特殊功能所需的特权访问。
此外，从AP18-03开始，引入功能间集群（IFC）接口的新概念。它描述了 FC 提供给其他 FC 的接口。请注意，它不是 ARA 的一部分，也不构成 AP 实现的正式规范要求。提供这些是为了通过阐明FC之间的交互来促进AP规范的开发，并且它们还可以为AP规范的用户提供更好的AP架构视图。这些接口在相应的FC SWS的附件中进行了描述。
AP 将运行它的硬件视为机器。基本原理是实现一致的平台视图，而不管可能使用的任何虚拟化技术。机器可以是真实的物理机、完全虚拟化的机器、半虚拟化的操作系统、操作系统级虚拟化容器或任何虚拟化环境。
在硬件上，可以有一台或多台机器，并且只有一台 AP 实例在一台机器上运行。通常认为，这种“硬件”包括单个芯片，托管一台或多台机器。但是，如果AP实现允许，则多个芯片形成一台机器也是可能的。
支持功能应用的分布式、独立和敏捷开发需要对开发方法采用标准化的方法。AUTOSAR自适应方法涉及标准化，用于描述服务，应用，机器及其配置等结构；以及定义这些工作产品如何交互以实现设计信息交换的相应任务，实现为自适应平台开发产品所需的各种活动的设计信息交换。
图 3.3 说明了如何实施适应性方法的概述草案。有关这些步骤的详细信息，请参阅 [3]。
图 3.3：AP 开发工作流
清单表示一段 AUTOSAR 模态描述，该描述是为支持 AUTOSAR AP 产品的配置而创建的，该描述将上载到 AUTOSAR AP 产品，可能与包含清单适用的可执行代码的其他项目（如二进制文件）结合使用。
清单的使用仅限于 AUTOSAR AP。但是，这并不意味着在面向 AUTOSAR AP 的开发项目中生成的所有 ARXML 都将自动被视为清单。事实上，AUTOSAR AP通常不专门用于车辆项目。
一辆典型的车辆很可能还配备了许多在AUTOSAR CP上开发的ECU，因此，整个车辆的系统设计必须涵盖两者 - 基于AUTOSAR CP构建的ECU和在AUTOSAR AP之上创建的ECU。
原则上，可以将术语“清单”定义为在概念上只有一个“清单”，并且每个部署方面都将在此上下文中处理。这似乎不合适，因为很明显，与清单相关的模型元素存在于典型开发项目的完全不同的阶段中。
出于这方面的主要动机，即在应用设计旁边，有必要将术语清单的定义细分为三个不同的分区：
-
这种描述指定了适用于为 AUTOSAR AP 创建应用软件的所有与设计相关的方面。不一定需要部署到 adaptive 平台机器，但应用设计有助于在执行清单和服务实例清单中定义应用软件的部署。
-
他的清单类型用于指定在 AUTOSAR AP 上运行的应用的部署相关信息。执行清单与实际的可执行代码捆绑在一起，以支持将可执行代码集成到机器上。
-
此类清单用于指定如何根据基础传输协议的要求配置面向服务的通信。服务实例清单与实际的可执行代码捆绑在一起，该代码实现面向服务的通信的相应用法。
-
这种清单应该描述与部署相关的内容，这些内容仅适用于运行 AUTOSAR AP 的基础机器（即机器上没有任何运行应用）的配置。机器清单与用于建立 AUTOSAR AP 实例的软件捆绑在一起。
不同种类的清单的定义（和用法）之间的时间划分导致的结论是，在大多数情况下使用不同的物理文件来存储三种清单。
除了应用设计和不同类型的清单之外，AUTOSAR方法还支持可以描述在单个模型中使用的两个AUTOSAR平台的软件组件。不同 AUTOSAR 平台的软件组件可以以面向服务的方式相互通信。但是，也可以描述信号到服务的映射，以在面向服务的通信和基于信号的通信之间创建桥梁。
应用设计描述了适用于为 AUTOSAR AP 创建应用软件的所有与设计相关的建模。
应用设计侧重于以下几个方面：
-
用于对软件设计和实现的信息进行分类的数据类型
-
服务接口是面向服务通信的关键元素
-
定义应用如何访问面向服务的通信
-
持久性接口是访问持久性数据和文件的关键元素
-
定义应用如何访问持久性存储
-
定义应用如何访问文件
-
定义应用如何访问加密软件
-
定义应用如何访问平台运行状况管理
-
定义应用如何访问时基
-
序列化属性，用于定义如何为网络上的传输序列化数据的特征
-
客户端和服务器功能的说明
-
对应用进行分组，以便于软件的部署。
应用设计中定义的工件独立于应用软件的特定部署，因此便于在不同的部署方案中重用应用实现。
执行清单的目的是提供将应用实际部署到 AUTOSAR AP 上所需的信息。
一般的想法是使应用软件代码尽可能独立于部署方案，以增加应用软件可以在不同部署方案中重用的几率。
通过执行清单，应用的实例化受到控制，因此可以
-
在同一台机器上多次实例化同一应用软件，或
-
将应用软件部署到多台机器，并为每台机器实例化应用软件。
执行清单侧重于以下几个方面：
-
用于定义如何启动应用实例的启动配置。启动包括启动选项和访问角色的定义。每个启动可能依赖于机器状态和/或功能组状态。
-
资源管理，特别是资源组分配。
在网络上实现面向服务的通信需要特定于所用通信技术（例如 SOME/IP）的配置。由于通信基础结构在服务提供者和服务请求者上的行为应相同，因此服务的实现必须在两端兼容。
服务实例清单侧重于以下几个方面：
-
服务接口部署，用于定义服务在特定通信技术上的表示方式。
-
服务实例部署，用于为特定提供和必需的服务实例定义通信技术所需的凭据。
-
端到端保护的配置
-
安全防护的配置
-
日志和跟踪的配置
机器清单允许配置在特定硬件（机器）上运行的实际自适应平台实例。
机器清单侧重于以下几个方面：
-
网络连接的配置和网络技术的基本凭据的定义（例如，对于以太网，这涉及静态IP地址的设置或DHCP的定义）。
-
服务发现技术的配置（例如，对于 SOME/IP，涉及要使用的 IP 端口和 IP 多播地址的定义）。
-
已用机器状态的定义
-
所用功能组的定义
-
自适应平台功能集群实现的配置（例如，操作系统提供具有特定权限的操作系统用户列表）。
-
加密平台模块的配置
-
平台运行状况管理的配置
-
时间同步的配置
-
文档化可用的硬件资源（例如，有多少 RAM 可用;有多少个处理器内核可用）
操作系统（OS）负责自适应平台上所有应用的运行时调度、资源管理（包括监管内存和时间限制）和进程间通信。该操作系统与执行管理结合使用，执行管理负责平台初始化，并使用操作系统执行应用的启动和关闭。
自适应平台不会为高性能处理器指定新的操作系统。相反，它定义了供自适应应用使用的执行上下文和操作系统接口（OSI）。
OSI 规范包含作为 ARA（自适应应用的标准应用接口）一部分的应用接口。操作系统本身很可能提供执行管理启动应用所需的其他接口，例如创建进程。但是，提供此类功能的接口等不能作为ARA的一部分使用，并且它被定义为依赖于平台实现。
OSI 提供 C 和 C++ 接口。对于 C 程序，应用的主要源代码业务逻辑包括 POSIX 标准中定义的 C 函数调用，即 IEEE1003.13 [1] 中定义的 PSE51。在编译过程中，编译器确定平台操作系统中的哪个C库提供这些C函数，并且应用可执行文件应在运行时链接。对于C++程序，应用软件组件的源代码包括C++标准及其标准C++库中定义的函数调用。
市场上有几种操作系统，例如 Linux，提供符合POSIX标准的接口。但是，与平台服务和基础相比，应用需要对操作系统使用更受限制的 API。
一般假设是用户应用应使用PSE51作为操作系统接口，而平台应用可以使用完整的POSIX。如果在应用级上需要更多功能，则它们将从 POSIX 标准中获取，并且尽可能不新指定。
自适应平台基础和自适应平台服务功能的实现可能会使用进一步的 POSIX 调用。特定调用将留给实现者，而不是标准化的。
操作系统提供多线程和多进程支持。标准调度策略由 POSIX 标准定义，SCHED_FIFO和 SCHED_RR。允许使用其他调度策略（如SCHED_DEADLINE或任何其他操作系统特定策略），但限制是这些策略可能无法跨不同的 AP 实现进行移植。
多进程支持背后的原因之一是实现不同功能集群和AA之间的“免干扰性”。操作系统的多进程支持强制每个进程位于独立的地址空间中，与其他进程分开并受到保护。同一可执行文件的两个实例在不同的地址空间中运行，以便它们可以在启动时共享同一入口点地址和代码以及数据值，但是，数据将位于内存中的不同物理页中。
设备管理在很大程度上是特定于操作系统的。有意为之，自适应平台基础倾向于创建服务以公开主要系统功能。
虽然目前没有计划标准化设备驾驶员本身的具体 API，但此类驾驶员实现的更高级功能可以通过自适应平台服务实现标准化。
多台机器之间以及与其他传感器之间的主要互连机制预计将基于以太网。因此，清楚地描述了基于 TCP/IP 和 UDP/IP 的协议的使用。因此，预计操作系统将提供这样的网络堆栈。
通过使用通信管理，应用将透明地受益于网络支持。作为自适应平台基础的一部分， VLAN、IPSEC 等其他功能正在实现系统内部和系统之间的安全通信。
执行管理负责系统执行管理的各个方面，包括自适应平台的初始化和进程的启动/关闭。执行管理与操作系统结合使用，以配置进程的运行时规划。
当机器启动时，操作系统将被初始化，随后执行管理将作为平台的初始过程启动。然后，自适应平台基础的其他平台级流程（代表功能集群）由执行管理启动。在自适应平台基础启动并运行后，执行管理将继续启动自适应应用的流程。平台级和应用级进程的启动顺序由执行管理根据机器清单和执行清单中指定的依赖项确定。
图 5.1：AP 启动顺序
自适应应用可以由多个可执行文件元素组成，这些元素通常对应于文件系统上的可执行文件。每个可执行文件可以有多个进程配置（以及启动配置），具体取决于可执行文件处于活动状态的功能组状态。
执行管理可选地支持经过身份验证的启动，其中从信任锚启动自适应平台，同时保持信任链。在经过身份验证的启动期间，执行管理将验证应用的真实性和完整性，并在检测到违规时（可选）阻止其执行。通过这些机制建立一个受信任的平台。
执行管理负责自适应平台执行管理和应用执行管理的各个方面，包括：
-
执行管理作为自适应平台启动阶段的一部分启动，负责自适应平台和已部署应用的初始化。
-
执行管理负责已部署应用的有序启动和关闭。执行管理根据机器清单和执行清单中的信息确定已部署的应用集，并根据声明的执行依赖关系派生启动/关闭顺序。根据机器状态和功能组状态，已部署应用的进程在自适应平台启动期间或之后启动，但是，并非所有应用都将立即开始活动工作，因为许多应用将向其他应用提供服务，因此等待并“侦听”传入的服务请求。
执行管理不负责应用的运行时调度，因为这是操作系统的责任。但是，执行管理负责配置 OS，以使 OS 能够根据执行管理从机器清单和执行清单中提取的信息执行必要的运行时规划。
确定性执行提供了一种机制，使得使用给定输入数据集的计算始终产生一致的输出，而不考虑干扰。执行管理区分时间和数据确定性。前者声明输出始终在截止时间之前生成，而后者是指从相同的输入数据集和内部状态生成相同的输出。
执行管理提供的支持侧重于数据确定性，因为时间确定性是通过提供足够的资源来处理的。对于数据确定性，执行管理提供了确定性客户端 API，以支持对过程内部周期、确定性工作线程池、激活时间戳和随机数的控制。确定性客户端与通信管理交互，以将数据处理与周期激活同步。确定性客户端支持的 API 及其与应用的关联如图 5.2 所示。
图 5.2：确定性客户端
除了进程本地确定性客户端之外，执行管理还支持确定性SyncMaster，该管理器提供多个确定性客户端实例之间的协调，以确保其确定性执行是同步的。
自适应平台允许在同一台机器上执行多个自适应应用，因此确保不受干扰是系统属性。因此，行为不正确的自适应应用应受到它影响的其他应用的能力的限制，例如，应防止应用进程消耗比指定更多的CPU时间，因它会对其他应用的正常运行产生后续影响。
执行管理通过配置一个或多个将应用进程分配到的资源组来支持不受干扰。然后，为每个资源组分配一个 CPU 时间或内存限制，以允许限制应用的可用资源。
执行管理负责进程启动/停止的状态相关管理，因此它必须具有启动和停止进程的特殊权限。平台运行状况管理监视进程，如果任何进程的行为不在指定参数范围内，则可能会触发恢复操作。恢复操作由集成商根据平台运行状况管理的软件架构要求定义，并在执行清单中进行配置。
为了保证系统的正确功能，确保在平台上执行的代码具有合法来源至关重要。保留此属性允许集成商构建受信的平台。
实现可信平台的系统的关键属性是信任锚（也称为信任根）。信任锚通常被实现为存储在安全环境中的公钥，例如在不可修改的持久内存或 HSM 中。
系统设计人员负责确保至少系统从信任锚开始，并且信任一直保持到执行管理启动。根据系统设计人员为建立信任链而选择的机制，在系统启动的此时，可能已经检查了整个系统的完整性和真实性。但是，如果系统设计人员仅确保已执行的软件已检查完整性和真实性，则执行管理在接管系统控制权时将接管继续信任链的责任。在这种情况下，系统集成商负责确保正确配置执行管理。
将信任从信任锚传递到操作系统和自适应平台（即建立信任链）的一个示例可能如下所示：信任锚 - 根据定义，作为一个真实的实体 - 在启动引导加载程序之前对引导加载程序进行身份验证。在引导过程的每个后续步骤中，应首先对要启动的可执行文件进行身份验证。这种真实性检查应由已经过身份验证的实体完成，即真实性检查可以由先前启动的可执行文件或由某些外部实体（如HSM）完成，例如示例。
操作系统真实启动后，它将启动执行管理作为其首批进程之一。在启动执行管理之前，操作系统应确保执行管理的真实性已经过验证，并且是经过身份验证的，因此是值得信赖的实体。
注意：如果信任锚本身的功能（根据定义是真实的）未检查身份验证，则在应用可执行文件之前，必须对应用于验证可执行文件真实性的软件进行身份验证。例如，如果加密 API 用于验证可执行文件的身份验证，则加密 API 本身在使用之前应由某个受信任的实体进行身份验证。
执行管理现在接管了在启动自适应应用之前对其进行身份验证的责任。但是，验证可执行代码的完整性和真实性的可能性不止一种。在 [6] 中，提供了完成此任务的可能机制列表。
状态管理是一个独特的功能集群，主要用于特定于ECU开发项目，通常，最终实现将由系统集成商执行。它负责 AUTOSAR 自适应平台操作状态的所有方面，包括处理传入事件、确定这些事件/请求的优先级以设置相应的内部状态。状态管理可能由一个或多个状态机组成，具体取决于项目需求。
状态管理通过特定于项目的 ara::com 服务接口与自适应应用进行交互，该接口由“字段”组成，如下所述。状态管理与其他功能集群之间的交互应通过每个功能集群定义的标准化接口来完成。
图 6.1：状态管理交互
状态管理可以请求以下效果：
-
可以请求将功能组设置为专用状态
-
（部分）可以请求取消/激活网络
-
可以请求关闭或重新启动机器
-
其他自适应（平台）应用的行为可能会受到影响
-
可以执行特定于项目的操作
-
从平台运行状况管理或执行管理通知（监督）错误中恢复
-
根据诊断请求，根据诊断地址执行项目特定的重置
-
准备和验证软件集群，以便根据更新和配置管理中的请求进行安装、更新或删除
-
影响正在运行的进程的行为，以实现机器（部件）内的同步行为（例如电源模式）
为了实现同步行为，状态管理通过通信管理的通信组的范围生成ara::com 方法和字段，提供定义的消息和回复的消息。
状态管理通过 ara::com 提供一组“触发器”和“通知程序”字段。SM 实质上侦听“触发器”，并在内部执行特定于实现的统计处理，并为“通知程序”字段（如果有）提供结果。
由于状态管理功能至关重要，因此必须通过 IAM（身份和访问管理）来保护来自其他功能集群或应用的访问。状态管理由平台运行状况管理监视和监督。
状态管理功能是高度特定于项目的，AUTOSAR 决定暂时不为自适应平台指定经典平台 BswM 等功能。计划仅指定一组基本服务接口，并将行为仲裁逻辑封装到特定项目的代码中。
仲裁逻辑代码可以单独开发，也可以（部分）基于标准化的配置参数生成。
通信管理适用于分布式实时嵌入式环境中应用之间通信的各个方面。
背后的概念是从实际机制中抽象出来，以查找和连接通信伙伴，以便应用软件的实施者可以专注于其应用的特定目的。
服务的概念是指向应用提供的功能超出了基本操作软件已经提供的功能。通信管理软件提供了为机器内通信以及机器间通信提供或使用此类服务的机制。
服务由以下各项组合组成：
-
事件
-
方法
-
字段
通信参与者之间的通信路径在设计、启动或运行时建立。该机制的一个重要组成部分是充当代理实例的服务注册表，也是通信管理软件的一部分。
图 7.1：面向服务的通信
提供服务的每个应用都在服务注册表中注册这些服务。若要使用服务，应用需要通过查询服务注册表来查找请求的服务，此过程称为服务发现。
通信管理提供了标准化的方法，即向应用实现者提供定义的服务（上层，语言绑定）以及服务在网络上的相应表示形式（下层，网络绑定）。这确保了源代码的可移植性和跨平台不同实现的编译服务的可比较性。
语言绑定定义如何使用目标编程语言的便捷功能将服务的方法、事件和字段转换为可直接访问的标识符。性能和类型安全（只要目标语言支持）是主要目标。因此，语言绑定通常由服务接口定义馈送的源代码生成器实现。
Figure 8.2：示例语言和网络绑定
网络绑定定义如何序列化已配置服务的实际数据并将其绑定到特定网络。它可以基于通信管理配置（AUTOSAR 元模型的接口定义）实现，方法是解释生成的特定于服务的配方或直接生成序列化代码本身。目前，通信管理支持 SOME/IP、DDS、IPC（进程间通信或任何其他自定义绑定）、信号 PDU（基于信号的网络绑定）和基于信号的静态网络绑定。
本地服务注册表也是网络绑定的一部分。
请注意：语言绑定和网络绑定之间的接口被视为通信管理软件中的专用接口。因此，定义此接口的规范目前超出了范围。尽管如此，鼓励平台供应商为其软件独立定义这样的接口，以便轻松实现其他语言绑定，而不是在其平台实现中与其他网络绑定一起C++。
C++语言绑定的上层接口提供 AUTOSAR 元模型的接口说明中定义的服务的面向对象映射。
生成器是通信管理软件开发工具的一部分，可生成C++类，这些类包含每个相应服务的字段、事件和方法的类型安全表示。
在服务实现端，这些生成的类被命名为“服务提供框架”。在客户端，它们称为服务请求代理。
对于服务方法，服务请求代理提供同步（在服务器返回结果之前阻止调用方）和异步调用（被调用的函数立即返回）的机制。调用方可以并行启动其他活动，并在服务器的返回值通过 Core Type ara::core::Future 的特殊功能可用时接收结果（请参见第 16.1.4 节）。
可以配置平台实现，以便生成器创建模型类，以便在相应的服务器尚不可用时轻松开发客户端功能。相同的机制也可用于对客户端进行单元测试。
虽然代理类可以由客户端直接使用，但C++绑定的服务提供框架只是抽象基类。服务实现应派生自生成的基类并实现相应的功能。
ara::com的接口还可以为安全相关的E2E保护通信提供代理和骨架。这些接口的设计旨在确保与应用的兼容性，无论 E2E 保护是打开还是关闭。
通信路径的配置可以在设计时、启动时或运行时进行，因此被视为静态或动态：
-
根本不需要服务发现，因为服务器会知道所有客户端且客户端都知道服务器。
-
客户端知道服务器，但服务器不知道客户端。事件订阅是应用中唯一的动态通信模式。
-
在配置时没有已知的通信路径。用于服务发现的 API 允许应用代码在运行时选择服务实例。
在 SOA 环境中，服务的客户端和提供者依赖于涵盖服务接口和行为的契约。在服务开发过程中，服务接口或行为可能会随时间而变化。因此，引入了服务协定版本来区分服务的不同版本。AUTOSAR Adaptive 平台支持服务的设计和部署阶段的协定版本控制。此外，客户端的“服务发现”应配置为支持版本向后兼容性。这意味着，如果客户端服务版本与客户端所需的服务版本向后兼容，则这些服务可以连接到不同版本的服务提供者。
除了面向服务的通信外，通信管理还提供了一个独立的API，用于处理指向外部ECU的原始二进制数据流，例如ADAS系统中的传感器。该 API 是静态的，它为客户端应用实现功能建立与服务器的通信通道，并为服务器应用实现等待来自客户端的传入连接的功能。该 API 为客户端和服务器提供用于关闭通信通道，以及通过通信通道读取和写入原始数据（字节流）的功能。原始数据流通道可由集成商通过应用部署信息进行配置，例如包含网络端点信息和所选协议。目前，TCP/ IP socket用作传输层，将来可添加其他替代方案。原始数据流接口在命名空间 ara::com::raw 中可用。
诊断管理（DM）实现了基于ISO 14229-1（UDS）和ISO 13400-2（DoIP）的ISO 14229-5（UDSonIP）。
诊断管理表示基础层上自适应平台的功能群集。
该配置基于经典AUTOSAR平台的诊断提取模板（DEXT）。
支持的传输层是 DoIP。DoIP 是一种虚拟发现协议，设计用于与诊断基础结构（诊断客户端、生产/车库测试人员）进行板外通信。
车载或远程诊断通常使用其他传输协议，因此提供了一个API来扩展具有自定义传输层的平台。
UDS通常用于车辆的生产和车库内，以便能够修理车辆。
原子可更新/可扩展部件由软件集群s （SWCL）管理。软件集群涵盖与更新已安装或部署一组特定新功能/应用相关的所有内容。因此，自适应诊断管理器支持为每个已安装的软件集群提供自己的诊断地址。但它也支持整个机器的单个诊断地址或两者之间的任何诊断部署。因此，自己的诊断地址始终具有自己的诊断服务实例。每个软件集群自己的诊断服务实例也为诊断提供了独立的开发文件，例如自己的独立ODX文件。请注意，此软件集群还与 UCM 的软件包相结合，以便软件集群可以更新或引入新机器。
诊断通信子集群实现诊断服务（如经典平台的 DCM）。目前，支持的服务有限，但对更多 UDS 服务的支持将在将来的版本中扩展。
DM 支持根据 ISO 14229-1 处理多客户端。可满足现代车辆架构的需求，包括用于数据收集的多个诊断客户端（测试仪），从后端访问以及最后的一些经典车库和生产用例。
DM分发器作为诊断服务接收诊断请求（如例程控制或DID服务）到相应AA的映射提供端口。
为了实现这一点，AA需要提供专门的诊断端口接口。
诊断端口接口有不同的抽象级可用：
-
例程控件消息可用作
-
API 签名包括所有请求和响应消息参数及其基元类型。DM 负责序列化。此 API 特定于特定的例程控件消息。
-
API 签名仅包含请求和响应消息的字节向量。应用负责请求和响应消息序列化。同一 API 可用于多个例程控制消息。
-
-
数据标识符消息可用作
-
API 签名包括所有请求-（用于写入）和响应消息（用于读取）参数及其基元类型。DM 负责序列化。
-
API 签名仅包含请求和响应消息的字节向量。应用负责请求和响应消息序列化。
-
每个请求和响应消息参数都有自己的接口。这是诊断通讯接口抽象的最高级，即请求和响应消息结构中的任何更改都不会对API产生影响。此外，同一诊断消息的参数可能位于不同的进程中。
-
由于 DM 需要如上所述的伪并行处理，因此它支持诊断对话，以反映诊断客户端和诊断服务之间的不同对话。诊断服务由相应 UDS 请求的目标地址标识，并在自适应平台的运行时动态分配。
事件内存子集群负责诊断故障代码（DTC）管理（类似于经典平台的 DEM）。
活动 DTC 表示车辆中肯定检测到的问题（通常对生产或车库很重要）。DM 管理 DTC 及其配置的快照记录（关于 DTC 发生事件的一组已配置环境数据）和/或扩展数据记录（属于 DTC 的统计数据，如重复发生的次数）的存储。
DTC 的检测逻辑称为诊断监视器。此类监视器将其最近的测试结果报告给 DM 中的诊断事件。UDS DTC 状态派生自一个或多个诊断事件。
DTC 可以分配给主存（可通过 2006 年 4 月 19 日访问）或可配置的用户存储（可通过 0x19 17/18/19 访问）。
支持计数器和时基反跳。此外，DM 还提供有关内部转换的通知：相关方将收到有关 DTC 状态字节更改、监视诊断事件重新初始化的需要以及快照器扩展数据记录是否已更改的通知。
如果 DTC 在配置的操作周期数内未处于活动状态，则 DTC 可能会从 DTC 内存中消失。
DM 支持对启用条件进行通用处理。启用条件可用于在特殊条件下控制 DTC 的更新，例如在欠压条件下禁用所有网络负载 DTC。
持久性为自适应平台的应用和其他功能集群提供了将信息存储在自适应机器的非易失性内存中的机制。数据可在启动和点火循环期间获得。持久性提供标准接口来访问非易失性内存。
持久性 API 将存储位置标识符作为应用中的参数，以寻址不同的存储位置。可用存储位置分为两类：
-
键值存储
-
文件存储
每个应用都可以使用多个这些存储类型的组合。
图 9.1：自适应应用中持久性的典型用法
持久性数据始终专用于单一应用的单一进程。没有可用于使用持久性在不同进程之间共享数据的机制。此决定是为了防止在通信管理所提供的功能下出现第二条通信路径。
持久性已准备好处理来自同一应用的多个线程的并发访问，这些线程在同一进程的上下文中运行。要创建对键值存储或文件存储的共享访问，OpenKeyValueStorage 和 OpenFileStorage 返回的 SharedHandle 可以传递（即复制）到另一个线程，或者 OpenKeyValueStorage 和 OpenFileStorage 可以分别在相同的键值存储或文件存储的独立线程中调用。
持久性能够处理存储数据的完整性。它使用冗余信息来检测数据损坏。冗余信息由 CRC 代码、哈希值和“M out of N”架构组成。这些机制既可以共用，也可以单独使用。
持久性也提供安全的存储。这基本上是使用冗余实现的，但具有额外的功能，即让应用知道存储的数据是否存在任何问题，使它可以使用冗余数据进行恢复。
持久性提供有关已用资源数的应用统计信息。
持久性为存储的数据提供加密，以确保敏感数据在存储在物理设备上之前进行加密。
键值存储提供了一种机制，用于在一个存储位置存储和检索多个键值对。键值存储直接支持以下三种数据类型：
-
SWS_AdaptivePlatformTypes [7] 中定义的数据类型。
-
由应用中复杂类型的流式处理生成的简单字节数组。
-
通过 dataType引用的所有实现数据类型由
PersistencyKeyValueStorage在应用设计中接口或专用于该接口的持久性数据元素。
对于每个键值存储，这些键必须是唯一的，并且由应用使用持久性提供的方法进行定义。
并非所有与持久性存储相关的数据都以键值存储这样一种存储机制方式构建。
对于此类数据，引入文件存储机制。文件存储端口允许应用访问存储位置并在其中创建一个或多个访问器。这些访问器再由字符串格式的唯一键标识。
与文件系统的比较会对理解有所帮助：文件存储端口可以理解为允许应用创建多个文件（访问器）的文件系统目录。
通常，UCM 中支持三个主要用例，用于在 ECU 或自适应机器的生命周期内处理自适应应用。
-
将新的应用软件安装到自适应机器
-
将现有应用软件更新到自适应机器
-
从自适应机器卸载现有应用软件
在前两种情况下，UCM 通过 EM 触发应用以验证安装/更新，然后触发持久性以根据清单中持久性的配置部署/更新应用的持久性数据。
在第三种情况下，UCM 使用持久性配置中的 URI 删除剩余的持久性数据。
持久性支持以下方案，用于将持久性数据部署到键值存储和文件存储。
-
持久性应能够部署在自适应应用安装期间由应用 designer 定义的持久性数据。
-
持久性应能够部署由集成商更改的持久性数据。
-
持久性应能够部署由集成商定义的持久性数据。
-
持久性应能够在安装新版本的应用时，根据为键值存储或文件存储配置的更新策略覆盖或保留持久性数据。
通常，持久性层是在应用设计和部署期间配置的。持久性应能够使用部署阶段配置来覆盖应用设计配置。如果缺少部署阶段配置，则将考虑应用设计中的配置以部署持久性数据。
当需要跨分布式系统关联不同事件时，不同应用和/或ECU之间的时间同步（TS）至关重要，以便能够及时跟踪此类事件或在准确的时间点触发它们。
因此，向应用提供了时间同步 API，以便它可以检索与其他实体/ECU 同步的时间信息。
然后，通过不同的“时基资源”（从现在开始称为TBR）提供时间同步功能，这些资源通过预构建配置存在于系统中。
对于自适应平台，考虑以下三种不同的技术来满足所有必要的时间同步要求：
-
经典平台的 StbM
-
库 chrono - std::chrono （C++11）或 boost::chrono
-
时间 POSIX 接口
在分析了这些模块的接口及其涵盖的时间同步功能之后，动机是设计一个时间同步API，该API提供围绕经典平台的StbM模块的功能，但具有类似std::chrono的风格。
时间同步模块考虑以下功能方面：
-
启动行为
-
关机行为
-
构造函数行为（初始化）
-
正常运行
-
错误处理
在后续版本中将考虑以下功能方面：
-
错误分类
-
版本检查
应用将有权访问每个 TBR 的不同专用类实现。
TBR分为不同的类型。这些类具有与同步时基管理器规范 [8] 中提供的时基类型的等效设计。分类如下：
-
同步主时基
-
偏移主时基
-
同步从时基
-
偏移从时基
与 StbM 一样，时间同步模块（从现在开始，TS）提供的 TBR 也与分布式系统其他节点上的其他时基同步。
通过此句柄，应用将能够查询所提供的时基类型（应为上面介绍的四种类型之一），然后获得该类型时基的专用类实现。此外，该应用还可以直接创建计时器。
TS 模块本身不提供将 TBR 同步到其他节点和/或 ECU 上的时基的方法，如网络时间协议或时间同步协议。
TBR的实现具有专用的周期功能，该功能从时间同步以太网模块或类似模块中检索时间信息以同步TBR。
应用使用 TBR 提供和管理的时间信息。
因此，TBR 充当时基代理，提供对同步时基的访问。通过执行此过程，TS 模块从“真实”时基提供程序中抽象出来。
AUTOSAR NM 基于分散的网络管理策略，这意味着每个网络节点独立执行活动，仅取决于通信系统内接收和/或传输的 NM 消息。
AUTOSAR NM 算法基于周期性 NM 消息，群集中的所有节点都通过多播消息接收这些消息。
接收 NM 消息表示发送节点希望使 NM 群集保持唤醒状态。如果所有节点已准备好进入休眠模式，它将停止发送 NM 消息，但只要收到来自其他节点的 NM 消息，它就会推迟到休眠模式的转换。最后，如果专用计时器由于不再接收 NM 消息而过期，则所有节点都会执行到休眠模式的转换。
如果 NM 群集中的任何节点需要总线通信，它可以通过启动传输 NM 消息来使 NM 群集保持唤醒状态。
自适应平台规范独立于所使用的底层通信媒介，描述 AUTOSAR 自适应平台的功能、API 设计和配置以及网络管理。目前只考虑以太网，但架构保持总线独立。
网络管理（NM）旨在通过状态管理进行控制，因为部分网络的控制需要通过 SM 控制的 EM 功能组状态与相关应用集进行协调。本章中的内容尚未反映设计方面。
图 11.1：NM概览
其主要目的是在内部协调状态机中协调底层网络（部分网络、VLAN 或物理信道）的正常运行和总线休眠模式之间的转换。
它为状态管理提供了一个服务接口，用于请求和释放网络以及查询其实际状态。它协调不同实例（网络句柄）的请求，并通过网络提供聚合的机器请求。
如果使用部分网络功能，则 Nm 消息可以包含部分网络（PN）请求，从而使 ECU 可以忽略请求与 ECU 不相关的任何 PN 的 Nm 消息。这提供了关闭ECU（或其部分）的可能性，尽管其他部分网络中的通信仍在进行。
AUTOSAR自适应平台的公开目标之一是通过无线更新（OTA）灵活更新软件及其配置的能力。为了支持自适应平台上的软件更改，更新和配置管理（UCM）提供了处理软件更新请求的自适应平台服务。
UCM 负责在自适应平台上更新、安装、删除和保留软件的重新记录。它的作用类似于 Linux 中的 dpkg 或 YUM 等已知包管理系统，具有额外的功能，可确保以安全可靠的方式更新或修改自适应平台上的软件。
UCM Master提供标准的自适应平台解决方案，以无线方式或通过诊断测试仪更新车辆软件。它在车辆内协调和分发多个UCM之间的包。因此，可以将 UCM Master视为 AUTOSAR 标准 UCM 客户端。
图 12.1：车辆更新架构
UCM 和 UCM Master 服务旨在支持车辆诊断的软件配置管理，并支持在安全、可靠和资源高效的更新过程中在自适应平台中执行更改。为了满足支持来自多个客户端的更新并启用快速下载的要求，UCM 需要能够将软件包处理（UCM 输入）与软件包数据传输分开处理。
数据传输是通过 ara::com 完成的。这样就可以将数据传输到 UCM 或 UCM Master，而无需在从后端或诊断测试仪传输数据的过程中缓冲数据。UCM 可以将包存储到本地存储库中，在该存储库中，可以按照 UCM 客户端或 UCM Master请求的顺序处理包。
传输阶段可以与处理阶段分开，UCM支持从多个客户端接收数据，没有限制。
UCM Master 依赖于与 UCM 相同的传输 API，但可通过其自己的专用服务接口进行访问。它允许UCM功能操作，如暂停或恢复并行传输。
作为 UCM 输入的安装单元是软件包。
例如，软件包包括一个或多个（自适应）应用的可执行文件、操作系统或固件更新，或应部署在自适应平台上的更新配置和校准数据。这构成了软件包中的可更新软件包内容，并包含要在自适应平台中添加或更改的实际数据。除了应用和配置数据外，每个软件包还包含一个软件包清单，提供软件包名称、版本、依赖项等元数据，以及处理软件包时可能出现的一些特定供应商的信息。
规范未指定软件包的格式，这使得可以使用不同类型的解决方案来实现UCM。软件包包括要在软件和元数据中执行的更新。此内容由 UCM 供应商工具进行压缩，生成可由目标 UCM 处理的软件包。
图 13.2.. 概述软件包
UCM 根据提供的元数据处理特定供应商的软件包。您可以在下面找到软件包清单中必须包含的字段的说明，以供参考：
通用信息
-
包名称：完全符合条件的短名称。
-
版本：软件群集模型