导文
作者Action：某Tier 1 AUTOSAR资深工程师，具备3年以上的AUTOSAR研究和应用开发经验，参与过多个知名OEM的AUTOSAR项目的研发工作，开发AP AUTOSAR相关工具，对新能源汽车AUTOSAR实施问题点均有深刻的研究，熟悉主流的BOSCH/ETAS、Vector、EB等工具，熟悉Infienon、NXP等MCU的开发，在此也感谢Action的热心分享。
楼主之前已经分享了两篇关于AP的文章。在开始阅读之前，如果你对已介绍的内容还不了解的话，可以先阅读以下文章快速熟悉一下~
Adaptive AUTOSAR
Adaptive AUTOSAR 2
这篇主要分享AP中操作系统、执行管理、状态管理、通讯管理四部分内容，想获取详细文档的同学可在文末问卷中填写有关信息免费获取。
操作系统
操作系统（OS）负责AP上所有应用程序的运行调度、资源管理（包括内存管理和时间控制）以及进程通信。操作系统与执行管理一起工作，执行管理负责系统初始化，并依靠操作系统进行应用程序的启动和关闭。自适应平台没有为高性能处理器指定新的操作系统，但它定义了一个执行环境和操作系统接口（OSI），以供自适应应用程序使用。
OSI标准包含应用程序接口，它是自适应应用程序的标准接口（ARA的一部分）。操作系统本身可以很好地提供其他接口，例如创建执行管理以及启动应用程序所需的进程。OSI提供了C和C 接口，对于C程序，应用程序的主要源代码包含在POSIX标准中定义的C函数，即IEEE1003.13[1]中定义的PSE51。在编译期间，编译器来确定平台操作系统中的哪个库提供这些C函数，并且应用程序可执行文件应在运行时链接。如果是C 程序的话，应用软件组件的源代码包括C 标准中定义的函数调用及其标准C 库。
POSIX
目前市场上有很多操作系统，例如Linux，它提供了与POSIX兼容的接口。然而，与平台服务和基础相比，应用程序需要使用更为封闭的API来操作系统。假设用户的应用程序使用PSE51作为操作系统接口，而平台应用程序则可使用完整的POSIX。如果在应用程序级别上了解更多的特性，它们将从POSIX标准中获取，而不是去重新定义。自适应平台基础和自适应平台服务功能的实现可通过进一步调用POSIX来实现。具体怎么调用是由用户去实现的，而不是通过标准强制规定。
Scheduling调度
操作系统支持多线程和多进程。标准调度方式是由POSIX标准定义的SCHED_FIFO和SCHED_RR。其他调度方式（如SCHED_DEADLINE或任何其他操作系统特定方式）是允许的，但不好的地方是，这可能无法在不同的AP间移植。
内存管理
支持多进程的原因之一是实现了不同功能集群和AA之间的“无干扰”。操作系统在自适应平台上对多进程的支持使得每个进程位于独立的地址空间中，与其他进程分离并对它加以保护。同一可执行文件的两个实例在不同的地址空间中运行，以便它们在启动时共享相同的入口地址和代码，但是，数据在内存中的不同物理层中。
设备管理
设备管理是在POSIX PSE51接口下提供的。详细信息请参阅POSIX标准。
执行管理
执行管理负责系统执行管理的各个方面，包括系统初始化和应用程序的启动与关闭。执行管理与操作系统协同工作，以进行应用程序的运行时调度。
系统启动
当机器启动时，操作系统首先初始化，然后启动执行管理。通过执行管理启动自适应平台基础的其他功能集群和平台应用。在自适应平台基础运行起来之后，执行管理继续启动自适应应用程序。平台应用程序和自适应应用程序的启动顺序由执行管理根据机器清单和执行清单来确定。
执行管理职责
执行管理负责自适应平台执行管理和应用程序执行管理的各个方面，包括：
1. 平台生命周期管理：执行管理作为自适应平台启动阶段的一部分，负责初始化自适应平台和部署的应用程序。
2. 应用程序生命周期管理：执行管理负责按顺序启动和关闭部署的应用程序。执行管理根据机器清单和执行清单中的信息确定部署的应用程序集，并根据声明的应用程序依赖性派生启动/关闭顺序。根据机器状态和功能组状态，部署的应用程序在自适应平台启动或更高版本启动期间启动，但由于许多应用程序将向其他应用程序提供服务，因此不希望所有应用程序都立即开始活动工作，因此等待并“侦听”传入的服务请求。
执行管理不负责应用程序的运行时调度，因为这是操作系统的责任。但是，执行管理负责操作系统的初始化配置，使其能够根据执行管理从机器清单和执行清单中提取的信息执行必要的运行时调度。
确定性执行
确定性执行提供了一种机制，使得使用给定输入数据集的计算总是在限定时间内生成一致的输出。执行管理区分时间和数据决定论。前者表示输出总是在截止日期前生成，后者表示从相同的输入数据集和内部状态生成相同的输出。
执行管理提供的支持侧重于数据决定论，因为它假定时间决定论通过提供足够的资源来处理。对于数据确定性，执行管理提供确定性客户端API来支持对进程内部周期、确定性工作池、激活时间戳和随机数的控制。在软件锁步骤的情况下，确定性客户机与可选的软件锁步骤框架交互，以确保冗余执行的过程的行为相同。确定性客户端与通信管理交互，以使数据处理与循环激活同步。确定性客户端支持的API及其与应用程序的交互如图所示。
资源限制
自适应平台允许在同一台机器上执行多个自适应应用程序，从而确保系统不受干扰。因此，行为不正确的自适应应用程序应限制其影响其他应用程序的能力，例如，由于可能对其他应用程序的正确运行产生后续影响，应防止应用程序消耗比指定时间更多的CPU时间。
执行管理通过配置分配给应用程序进程的一个或多个资源组来支持不受干扰。然后可以为每个资源组分配CPU时间或内存限制，以限制应用程序的可用资源。
状态管理
状态管理提供了一种机制来定义自适应平台的操作状态。状态管理授予对要执行的应用程序集的完全控制权，并确保仅在需要时执行进程（从而分配资源）。机器状态和功能组状态定义当前运行的进程集。每个进程在其执行清单中声明，其中说明该进程应处于活动状态，四种不同的状态与执行管理相关：
• 机器状态
机器状态主要用于控制机器生命周期（启动/关闭/重启）、平台级进程和其他基础设施。每台机器上必须存在几个强制机器状态。其他特定于机器的机器状态可以在机器清单中定义
• 功能组状态
功能组状态主要用于单独启动和停止功能一致的用户级应用程序进程组。它们可以在机器清单中配置
• 过程状态
流程状态用于应用程序生命周期管理，由执行管理内部状态机实现。
• 执行状态
执行状态表征应用程序可执行文件（即进程）的任何实例的内部生命周期。每个进程必须向执行管理报告执行状态更改。
应用程序恢复
执行管理负责过程启动/停止的状态相关管理，因此它必须拥有启动和停止过程的特殊权利。平台运行状况管理监视进程，并在任何进程的行为不在指定参数范围内时触发恢复操作。恢复操作由集成器根据平台健康管理的软件体系结构需求定义，并在执行清单中进行配置。
状态管理
状态管理是一个功能集群，负责定义机器状态和功能组状态的当前集合，并通过从执行管理请求它们来启动状态转换。执行管理根据当前状态执行状态转换并控制实际运行的进程集。
状态管理是请求新机器状态和功能组状态以及仲裁请求的中心点，包括协调来自不同来源的矛盾请求。仲裁时可能需要考虑其他数据和事件。 状态更改请求可以由以下人员发出：
• 平台健康管理触发错误恢复，例如激活回退功能
• 诊断，将系统切换到诊断状态
• 更新和配置管理，将系统切换到可以更新软件或配置的状态。
• 网络管理以协调所需功能和网络状态
• 授权应用程序，例如可能位于不同机器或不同ECU上的车辆状态管理器
状态更改请求可以由其他功能集群通过ara::com服务接口发出。由于状态管理功能是关键的，因此必须保护来自其他功能集群或应用程序的访问，例如IAM（身份和访问管理）。状态管理由平台健康管理监控。状态管理提供接口来请求有关当前状态的信息。此外，状态管理还提供以更细粒度的方式控制流程的功能，例如支持延迟的“唤醒”、执行特定于应用程序的重置操作或控制应用程序的通信行为。所有这些都是在不需要从内存中删除进程的情况下完成的，并且使用不同的启动参数组重新加载/重新启动它们。
状态管理功能是高度特定于项目的，AUTOSAR决定暂时不指定类似于自适应平台的经典平台BswM这样的功能。计划只指定一组基本服务接口，将实际仲裁逻辑封装成项目特定的代码（如库），可以插入状态管理框架，框架与仲裁逻辑之间有标准化接口，可以在不同的平台上重用。仲裁逻辑代码可以根据标准化配置参数单独开发或（部分）生成。
通讯管理
通信管理负责分布式实时嵌入式环境中应用程序之间通信的各个方面。背后的概念是从实际机制中抽象出来，以找到和连接通信伙伴，从而使应用软件的实现者能够专注于其应用程序的特定目的。
面向服务的通讯
服务的概念意味着为应用程序提供的功能超出了基本操作软件已经提供的功能。通信管理软件提供为机内通信和机间通信提供或使用此类服务的机制。
一组服务包括
• 事件
• 方法
• 地点
通信伙伴之间的通信路径可以在设计、启动或运行时建立。该机制的一个重要组件是充当代理实例的服务注册中心，也是通信管理软件的一部分。
提供服务的每个应用程序都在服务注册表中注册这些服务。要使用服务，使用应用程序需要通过查询服务注册表来查找请求的服务，此过程称为服务发现。
语言和网络绑定
通信管理提供了标准化的方法，即如何向应用程序实现者（上层，语言绑定）提供定义的服务，以及服务数据在网络上的各自表示（下层，网络绑定）。这确保了源代码的可移植性和跨平台不同实现的已编译服务的兼容性。语言绑定定义了如何使用目标编程语言的方便功能将服务的方法、事件和字段转换为直接可访问的标识符。性能和类型安全（只要目标语言支持）是主要目标。因此，语言绑定通常由服务接口定义提供的源代码生成器实现。
网络绑定定义如何序列化已配置服务的实际数据并将其绑定到特定网络。它可以基于通信管理配置（AUTOSAR元模型的接口定义）通过解释生成的特定于服务的配方或直接生成序列化代码本身来实现。
本地服务注册表也是网络绑定的一部分。 要注意到，语言绑定和网络绑定之间的接口被视为通信管理软件内部的私有接口。因此，定义此接口的规范性规范目前已超出范围。然而，平台供应商被鼓励独立地定义这样的接口，以允许他们的软件易于实现其他语言绑定，而不是C 与平台实现中的其他网络绑定。
生成C 语言绑定代理和骨架
C 语言绑定的上层接口为AutoSar元模型的接口描述中定义的服务提供了面向对象的映射。作为通信管理软件开发工具的一部分的生成器生成C 类，该类包含每个相应服务的字段、事件和方法的类型安全表示。
在服务实现方面，这些生成的类被命名为服务提供者骨架。在客户端，它们被称为服务请求者代理。
对于服务方法，服务请求者代理提供同步（在服务器返回结果之前阻止调用方）和异步调用（被调用函数立即返回）的机制。调用方可以并行启动其他活动，并在服务器的返回值通过核心类型ara::core::future的特殊功能可用时接收结果。
平台实现可以配置为生成器创建模拟类，以便在各自的服务器尚不可用时轻松开发客户端功能。同样的机制也可以用于对客户机进行单元测试。
虽然代理类可以直接由客户端使用，但服务提供者对C 绑定的骨架只是抽象的基类，服务实现应从生成的基类派生并实现各自的功能。
ara:com的接口还可以为安全相关的e2e保护通信提供代理和骨架，这些接口的设计确保了与应用程序的兼容性，无论E2E保护是打开还是关闭。
静态和动态配置
通信路径的配置可以在设计、启动或运行时进行，因此被认为是静态的或动态的：
• 完整静态配置：
根本不需要服务发现，因为服务器知道所有客户机和客户机都知道服务器。
• 应用程序代码未发现：
客户机知道服务器，但服务器不知道客户机，事件订阅是应用程序中唯一的动态通信模式。
• 应用程序中的完整服务发现：
配置时不知道通信路径，服务发现的API允许应用程序代码在运行时选择服务实例。
