我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师（Wechat：gongkenan2013）。

老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：

本就是小人物，输了就是输了，不要在意别人怎么看自己。江湖一碗茶，喝完再挣扎，出门靠自己，四海皆为家。人生的面吃一碗少一碗，人生的面见一面少一面。人生就是一次次减法，来日并不方长。自己的状态就是自己最好的风水，自己的人品就是自己最好的运气。简单点，善良点，努力点，努力使每一天都开心，不为别人，只为自己。

本文大体如下：

1、AP架构

2、应用程序的启动和关闭

3、OS、Process和线程

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

5、方法和Manifest

一、AP架构

如图显示了AP的架构。自适应应用程序(AA)运行在 ARA(AUTOSAR自适应应用程序运行时)之上。ARA由功能集群提供的应用接口组成，功能集群属于自适应平台基础或自适应平台服务。自适应平台基础提供 AP 的基本功能，自适应平台服务提供AP 的平台标准服务。任何 AA 也可以向其他 AA 提供服务，如图中的非平台服务。

从AA的角度来看，功能集群的接口，无论是自适应平台基础还是自适应平台服务的接口，都无关紧要–它们只是提供指定的C++接口或AP未来可能支持的任何其他语言绑定。在引擎盖下确实存在差异。此外，请注意，在ARA（AUTOSAR Runtime for Adaptive applications）接口之下，包括在AA上下文中调用的 ARA（AUTOSAR Runtime for Adaptive applications） 库，可以使用 ARA 之外的其他接口来实现 AP 的规范，这取决于AP实现的设计。

POSIX API的语言绑定基于C++，C++标准库也是ARA（AUTOSAR Runtime for Adaptive applications）的一部分。关于OS API，只有PSE51接口(POSIX 标准的单Process 配置文件)作为ARA（AUTOSAR Runtime for Adaptive applications）的一部分可用。选择PSE51 的目的是为现有的 POSIX 应用程序提供可移植性，并实现应用程序之间的无千扰。

请注意，C++标准库包含许多基于POSIX的接口，包括多线程APIS。建议不要将C++标准库的线程接口与本地PSE51线程接口混用，以避免复杂化。遗憾的是，C++标准库并未涵盖 PSE51 的所有功能，如设置线程调度策略。在这种情况下，可能需要同时使用这两个接口。

支持的协议、安全和安保功能

自适应平台支持一系列众所周知的协议、安全和安保功能。下图和表格提供了概述。

二、应用程序的启动和关闭

应用程序的生命周期由执行管理(EM)管理。应用程序的加载/启动通过使用EM的功能进行管理，需要在系统集成时或运行时进行适当配置才能启动应用程序。事实上，从EM的角度来看，所有功能集群都是应用程序，除了EM本身外，它们也以同样的方式启动。图 4.2 展示了 AP 内和 AP 上不同类型的应用程序。

请注意，应用程序何时启动或终止不是由EM决定的。名为状态管理(SM)的特殊FC是控制器，它根据系统设计对EM发出指令，对不同状态进行仲裁，从而控制整个系统的行为。由于这里的系统指的是AP及其应用程序运行的整台Machine，因此内部行为的实现是针对具体项目的。SM还与其他 FCs交互，以协调整个Machine的行为。SM 只应使用标准 ARA 接口，以保持不同 AP 栈实现之间的可移植性。

应用程序交互

关于AAs之间的交互，PSE51不包括IPC(Inter-ProcessCommunication)，因此AAs之间没有直接的交互接口。通信管理(CM)是唯一明确的接口。CM 还为 Machine 内和Machine 间提供面向服务的通信，这对应用程序是透明的。无论服务和客户端应用程序的拓扑部署如何，CM 都会处理服务请求/回复的路由选择。请注意，其他 ARA 接口可能会在内部触发 AAs 之间的交互，但这并不是一个明确的通信接口，而只是各 ARA 接口所提供功能的副产品。

非标准接口

AA 和功能集群可使用任何非标准接口，但这些接口不得与标准 AP 功能相冲突，并且必须符合项目的 Safety/Security要求。除非它们是纯应用本地运行库，否则应注意尽量减少使用，因为这将影响软件在其他 AP 实现中的可移植性。

这里讨论的是AP的物理架构。请注意，本节中的大部分内容仅供参考，并不构成 AP的正式要求规范，因为AP的内部结构是由实现定义的。明确说明了对AP实施的任何正式要求。作为额外的信息来源，请参阅其中更详细地描述了AP的内部结构。

三、OS、Process和线程

需要 AP 操作系统才能提供多进程 POSIX 操作系统功能。每个 AA 都是作为一个独立的进程实现的，具有自己的逻辑存储器space和 namespace。请注意，单个AA可能包含多个进程，这可以部署在单个AP实例上，也可以分布在多个AP实例上。从模块组织的角度来看，每个进程都由操作系统从可执行文件实例化。可以从单个可执行文件实例化多个进程。此外，AA 可能构成多个可执行文件。

功能集群通常也是以Process（进程）的形式实现的。一个功能集群也可以用一个 Process（进程） 或多个(子)Process（进程）来实现。自适应平台服务和非平台服务也以 Process（进程）的形式实现,

所有这些 Process（进程）都可以是单线程 Process（进程） 或多线程 Process（进程）。不过，根据 Process（进程）所属逻辑层的不同，它们可以使用的OS API也不同。如果 Process（进程）是运行在 ARA 上的 AAs,则只能使用PSE51。如果 Process（进程）属于功能集群，则可以自由使用任何可用的 OS 接口。总之，从 OS 的角度来看，AP 和 AA 只是一组Process（进程），每个 Process（进程）都包含一个或多个线程–这些 Process（进程）之间没有任何区别，但是否提供任何分区取决于 AP 的实现。这些Process（进程）通过 IPC 或任何其他可用的 OS 功能进行交互。请注意，AA Process（进程）不能直接使用IPC，只能通过ARA进行通信。

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

如下图所示，功能集群可以是自适应平台基础模块或自适应平台服务。如前所述，它们通常都是Process。要与同为Process 的 AAs 交互，它们需要使用 IPC。为此，有两种可供选择的设计方案。一种是"基于库"的设计，即由功能集群提供并链接到 AA 的接口库直接调用 IPC。另一种是"基于服务"的设计，即 Process 使用通信管理功能，并将服务端代理库链接到 AA。代理库调用通信管理接口，在 AA Process 和服务端 Process之间协调 IPC。请注意，AA 是直接使用通信管理功能执行IPC，还是通过代理库与服务端直接混合执行 IPC，这取决于实施情况。

选择功能集群设计的一般准则是，如果只在本地 AP 实例中使用，则基于库的设计更合适，因为它更简单、更高效。如果从其他 AP 实例以分布式方式使用，建议采用基于服务的设计，因为无论客户 AA 和服务位于何处，通信管理都能提供透明的通信。属于自适应平台基础的功能集群是"基于库"的，而自适应平台服务则是"基于服务"的，正如其名称所示。

最后要注意的是，只要FC符合定义的RS和SWS，就允许FC的实现不包含Process,而是以库的形式实现，并在 AA Process 的上下文中运行。在这种情况下，AA 与 FC之间的交互将是常规的过程调用，而不是如前所述的基于IPC的交互。

功能集群之间的交互

一般来说，功能集群之间可以通过 AP 的特定实现方式进行交互，因为它们不受限于ARA 接口，例如 PSE51 就限制了 IPC 的使用。事实上，它可以使用其他功能集群的ARA 接口，这些接口都是公共接口。功能集群之间的一种典型交互模式是使用功能集群的受保护接口，提供实现功能集群特殊功能所需的特权访问。

此外，AP18-03 引入了 Inter-Functional-Cluster(IFC)接口的新概念。它描述了 FC 向其他 FCs 提供的接口。请注意，它不是 ARA 的一部分，也不构成对 AP 实施的正式规范要求。提供这些接口的目的是通过明确 FCs 之间的交互来促进 AP 规范的制定，同时也可为 AP 规范的用户提供更好的 AP 架构视图。FC SWS 的附件中描述了这些接口。

Machine/硬件

AP将其运行的硬件视为 Machine 。这样做的理由是为了实现一致的平台视图，而不考虑可能使用的任何虚拟化技术。 Machine 可以是真正的物理 Machine 、完全虚拟化的Machine、准虚拟化的 OS、OS 级虚拟化容器或任何其他虚拟化环境。在硬件上，可以有一台或多台 Machine ，一台 Machine 上只能运行一个 AP 实例。一般认为，这种"硬件"包括一个芯片，承载一个或多个 Machine 。不过，如果 AP 实现允许，也可以由多个芯片组成一台Machine 。

五、方法和Manifest

要支持功能应用程序的分布式、独立和敏捷开发，就必须采用标准化的开发方法。AUTOSAR 自适应方法论涉及到服务、应用程序、Machine 及其配置等工件描述工作产品的标准化，以及定义这些工作产品如何交互的相应任务，以实现自适应平台产品开发所需的各种活动的设计信息交换。

如图展示了如何实施自适应方法的概览草案。有关这些步骤的详细信息，请参见

应用的分布式、独立、敏捷开发要求开发方法论的标准化。AUTOSAR Adaptive 方法论包括两部分：

用于描述 Service、Application、Machine 的 Work Product 的标准化以及他们的配置

定义 Work Product 如何交互，以交换设计信息的任务

Manifest

Manifest 代表了一个 AUTOSAR 的模型描述，上传到 AP 产品，用以支持 AP 产品的配置。上传到 AP 时，可能结合其他该 Manifest 适用的文件，如含有可执行代码的二进制文件。

Manifest 只限于 AP，但这不意味着 AP 项目中所有产生的 ARXML 都是 Manifest。事实上，AUTOSAR AP is usually not exclusively used in a vehicle project 不只是应用于汽车领域。

典型的车辆还会有很多基于 AUTOSAR CP 开发的 ECU，因此整车系统设计要同时考虑基于 AUTOSAR CP 和 AP 的 ECU。

原则上，术语 Manifest 在概念上可以定义为单一的 Manifest，部署的各个方面都会在这个 Manifest 的上下文中处理。但是这样现实中并不可行，因为项目中和 Manifest 相关的模型存在于整个项目的各个不同阶段。出于这个原因，除了 Application Design 之外，Manifest 又可以细分为三类：

Application Design

描述所有应用设计相关的方面，不需要部署到 AP 机器上，但 Application Design 会辅助在 Execution Manifest 和 Service Instance Manifest 中定义应用软件的部署。

Execution Manifest

描述应用部署相关的信息。和可执行代码绑定，以支持将可执行代码集成到机器。

Service Instance Manifest

描述针对特定的传输协议（如 SOME/IP），进行面向服务通信的配置。和可执行代码绑定。

Machine Manifest

描述运行 AUTOSAR AP 的机器。和共同组成 AP 实例的软件绑定。

按照定义（和用法）划分 Manifest 导致使用了不同的物理文件来存储三类 Manifest 的内容。除了 Application Design 和不同的 Manifest，AUTOSAR 方法论支持系统设计，可以在单一模型中描述系统中 CP、AP 两个平台的软件模块。不同平台中软件模块可以通过面向服务的方式通信。但是也可以描述一个信号到服务的映射，在面向服务的通信和基于信号的通信之间搭建一个桥梁。

清单

一个 Manifest 代表一段 AUTOSAR 模型描述，它是为支持 AUTOSAR AP 产品的配置而创建的，并被上传到 AU-TOSAR AP 产品，可能与其他包含 Manifest 适用的可执行代码的工件(如二进制文件)结合在一起。

清单的使用仅限于 AUTOSAR AP。但这并不意味着在以 AUTOSAR AP 为目标的开发项目中产生的所有 ARXML 都会自动被视为清单。事实上，AUTOSAR AP 通常不会专门用于车辆项目。

一辆典型的车辆很可能还配备了许多在 AUTOSAR CP 基础上开发的 ECUs，因此整辆车的系统设计必须同时涵盖在 AUTOSAR CP 基础上开发的 ECUs 和在 AUTOSAR AF基础上开发的 ECUS。

原则上，“Manifest"一词可以这样定义，即概念上只有一个"Manifest”，每个部署方面都将在此背景下处理。但这似乎并不合适，因为在典型的开发项目中，与清单相关的模型元素显然存在于完全不同的阶段。

因此，在应用程序设计之外，有必要将清单一词的定义细分为三个不同的部分:

-> 应用设计这种描述规定了适用于为 AUTOSAR AP 创建应用软件的所有设计相关方面。它不一定需要部署到自适应平台 Machine 上，但应用设计有助于在执行清单和服务实例清单中定义应用软件的部署;

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

-> 服务实例清单这种清单用于指定如何根据底层传输协议的要求配置面向服务的通信。服务实例清单与实际的可执行代码捆绑在一起，以实现面向服务通信的各种用途;

-> Machine 清单这种清单用于描述与部署相关的内容，这些内容只适用于运行AUTOSAR AP 的底层 Machine (即 Machine 上不运行任何应用程序)的配置。Machine 清单与用于建立 AUTOSAR AP 实例的软件捆绑在一起。不同类型的清单在定义(和使用)上的时间划分导致在大多数情况下使用不同的物理文件来存储三种清单的内容。

除了应用程序设计和不同类型的清单之外，AUTOSAR方法论还支持系统设计，可以在一个模型中描述系统中使用的两个 AUTOSAR 平台的软件组件。不同 AUTOSAR 平台的软件组件可以面向服务的方式相互通信。但也可以描述信号到服务的映射，从而在面向服务的通信和基于信号的通信之间架起一座桥梁。

应用设计

应用设计描述了所有与设计相关的建模，这些建模适用于为 AUTOSAR AP 创建应用软件。

应用设计侧重于以下方面:

-> 用于软件设计和实施信息分类的数据类型

-> 服务接口是面向服务通信的关键要素

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

-> 持久性接口是访问持久数据和文件的关键要素

-> 定义应用程序如何访问持久存储

-> 定义应用程序如何访问文件

-> 定义应用程序如何访问加密软件

-> 定义应用程序如何访问平台健康管理

-> 定义应用程序如何访问时间库

-> 序列化属性，用于定义数据在网络传输中的序列化特性

-> 描述客户端和服务端功能

-> 对应用程序进行分组，以方便软件的部署。

应用程序设计中定义的工件与应用软件的具体部署无关，因此便于在不同部署情况下重复使用应用程序实现。

执行清单

执行清单的目的是提供在 AUTOSAR AP 上实际部署应用程序所需的信息。总体思路是使应用软件代码尽可能独立于部署方案，以增加应用软件在不同部署方案中重复使用的几率。

执行清单可控制应用软件的实例化，因此可以在同一台Machine 上多次实例化同一应用软件，或将应用软件部署到多台 Machine上，并在每台 Machine 上实例化应用软件。

执行清单侧重于以下几个方面:

1、启动配置:定义应用程序实例的启动方式。启动包括启动选项和访问角色的定义。每次启动都可能取决于 Machimne 状态和/或功能组状态。

2、资源管理，特别是资源组分配。

服务实例清单

在网络上实施面向服务的通信需要针对所使用的通信技术(如 SOME/P)进行配置。由于通信基础设施对服务提供者和请求者的作用相同，因此服务的实现必须在双方都兼容。

服务实例清单侧重于以下几个方面:

-> 服务接口部署，定义服务在特定通信技术上的表现形式。

-> 服务实例部署:为特定提供的和所需的服务实例定义通信技术所需的凭证。

-> E2E 保护配置

-> 安全保护配置

-> 日志和跟踪配置

Machine 清单

Machine 清单允许配置在特定硬件(Machine )上运行的实际自适应平台实例。Machine 清单侧重于以下方面:

1、配置网络连接和定义网络技术的基本凭证(例如，对于以太网，这涉及到设置静态 IP 地址或定义 DHCP)；

2、配置服务发现技术(例如，对于 SOME/IP，这涉及到IP端口和IP多播地址的定义；

3、配置网络连接和定义网络技术的基本凭证(例如，对于以太网，这涉及到设置静态 地址或定义 DHCP)。

4、配置服务发现技术(例如，对于 SOME/P，这涉及到 正 端口和 IP 多播地址的定义)

5、定义使用的 Machine 状态

6、定义使用的功能组

7、配置自适应平台功能组实施(例如，操作系统提供具有特定权限的 OS用户列表)。

8、加密平台模块的配置

9、平台健康管理的配置

10、时间同步的配置

11、可用硬件资源文档(例如，有多少RAM 可用;有多少处理器内核可用)

搁笔分享完毕！

愿你我相信时间的力量

做一个长期主义者！