Hello！大家好！
本篇是AP AUTOSAR平台设计(2)——架构
AP和CP相关资料获取和工具咨询、更多精彩内容欢迎订阅微信公众号“搞一下汽车电子”
整理不易，如果觉得不错，点赞分享支持一下吧~
微信：shactiontech
1.逻辑视图
① ARA
图1表示的是AP的体系结构。从图中可以看出以下几点：
1. 自适应应用程序（AA）在自适应应用程序的AUTOSAR运行时（ARA）之上运行。
2. ARA由功能群集提供的应用程序接口组成，这些群集属于Adaptive Platform Foundation或Adaptive Platform Services。Adaptive Platform Foundation提供AP的基本功能，而Adaptive Platform Services提供AP的平台标准服务。
3. 任何AA也可以向其他AA提供服务，在图中以非平台服务形式说明。
从AA的角度来看，功能集群的接口（无论是Adaptive Platform Foundation的接口还是Adaptive Platform Services的接口）都无所谓——它们仅提供指定的C ++接口或AP将来可能支持的任何其他语言的接口。
另外，请注意，在ARA接口下，包括在AA上下文中调用的ARA库，可以使用ARA以外的其他接口来实现AP规范，这取决于AP实现的设计。
② 语言绑定，C++标准库和POSIX API
这些API是基于C ++，并且C ++标准库也作为ARA的一部分提供。
关于OS API，AA只可使用PSE51接口
建议不要将C ++标准库线程接口与本机PSE51线程接口混合使用，以避免复杂化。
但是，C ++标准库没有涵盖所有PSE51功能，例如设置线程调度策略。在这种情况下，可能需要同时使用两个接口。
③ 应用程序启动和关闭
应用程序的生命周期由执行管理（EM）管理。
应用程序的加载/启动是通过使用EM的功能进行管理的，并且需要在系统集成时或运行时进行适当的配置才能启动应用程序。
实际上，从EM的角度来看，所有功能集群都是应用程序，除了EM本身以外，它们也以相同的方式启动。图2应用程序说明了AP内部和AP上不同类型的应用程序。
EM不会决定应用程序的启动时间和终止时间。
应用程序的启动时间和终止时间是状态管理（SM）控制的，SM是一种特殊的FC，它根据系统的设计命令EM，仲裁不同的状态，从而控制整个系统的行为。
SM还与其他FC交互以协调整体机器行为。SM应该仅使用标准ARA接口来维护不同AP堆栈实现之间的可移植性。
④ 应用程序交互
AA之间没有直接进行交互的接口，不能通过IPC（进程间通）进行直接交互。
AA之间要想交互需要通过通信管理（CM）
AA可以直接调用POSIX OS的PSE51接口，但是不能调用POSIX OS的非PSE51接口
CM还为Machine内和Machine间提供面向服务的通信
注意：其他ARA接口可能在内部触发AA之间的交互，但是，这不是显式的通信接口，而只是相应ARA接口提供的功能的副产品
⑤ 非标准接口
AA和功能集群可以使用任何非标准接口，只要它们不与标准AP功能冲突，并且它们符合项目的安全性要求即可。
除非它们是纯的应用程序本地运行时库，否则应注意使此类使用最少，因为这将影响软件在其他AP实现上的可移植性。
2.物理视图
在此讨论AP的物理体系结构。
注意：本节中的大多数内容仅用于说明目的，并且不构成AP的正式要求规范。
① 操作系统，进程和线程
每个AA被实现为一个独立的进程，具有自己的逻辑内存空间和名称空间。
请注意，单个AA可以包含多个进程，并且可以将其部署到单个AP Instance上或分布在多个AP Instance上。
每个进程都由OS从可执行文件实例化。可以从单个可执行文件实例化多个进程。同样，AA可以构成多个可执行文件。
功能集群通常也被实现为进程。功能集群也可以用单个过程或多个（子）过程来实现。自适应平台服务和非平台服务也被实现为进程。
所有这些进程可以是单线程进程或多线程进程。但是，根据进程所属的逻辑层，它们可以使用的OS API有所不同。如果它们是运行在ARA之上的AA，则它们只能使用PSE51。
如果该进程是功能集群之一，则可以自由使用任何可用的OS接口。
综上所述，从操作系统的角度来看，AP和AA只是形成一组进程，每个进程包含一个或多个线程——这些进程之间没有区别。这些进程确实通过IPC或任何其他可用的OS功能相互交互。请注意，AA进程可能不会直接使用IPC，而只能通过ARA进行通信。
② 基于库或基于服务的功能集群实施
如图1 AP体系结构逻辑视图中所示，功能集群可以是Adaptive Platform Foundation模块或Adaptive Platform Service。如前所述，这些通常都是进程。为了使它们与AA（也是进程）交互，它们需要使用IPC。有两种替代设计可以实现此目的。
一种是“基于库”的设计，其中由功能集群提供并链接到AA的接口库直接调用IPC。
另一个是“基于服务”的设计，该进程使用通信管理功能，并且具有链接到AA的Server Proxy库。Proxy库调用通信管理接口，该接口在AA进程和服务器进程之间协调IPC。请注意，AA是仅通过通讯管理直接执行IPC，还是通过Proxy库与Server 直接IPC混合，由实施定义。
选择功能性集群设计的一般指导原则是，如果仅在AP实例中本地使用它，则基于库的设计会更合适，因为它更简单且效率更高。
如果以分布式方式从其他AP实例中使用它，则建议采用基于服务的设计，因为无论客户端AA和服务的位置如何，通信管理都将提供透明的通信。顾名思义，属于Adaptive Platform Foundation的功能集群是“基于库的”，而Adaptive Platform Services是“基于服务的”。
注意：允许FC的实现以库的形式实现，即：AA和FC之间的交互将是常规进程调用，而不是如前所述基于IPC。
③ 功能集群之间的交互
功能集群之间的一种典型交互模型是使用功能集群的受保护接口来提供实现功能集群的特殊功能所需的特权访问。
从AP18-03开始，引入了功能间群集（IFC）接口的新概念。它描述了FC提供给其他FC的接口。注意，它不是ARA的一部分，也不构成AP实施的正式规范要求。这些接口在相应的FC SWS的附件中进行了描述。
④ 机器/硬件
AP将运行在其上的硬件视为一台Machine。其背后的原理是获得一致的平台视图，而不考虑可能使用的任何虚拟化技术。该Machine可能是一台真正的物理Machine，一台全虚拟化的Machine，一台半虚拟化的OS，一个OS级虚拟化的容器或任何其他虚拟化环境。
在硬件上，可以有一个或多个Machine，并且在一台Machine上仅运行一个AP实例。通常认为，该“硬件”包含一个芯片，可容纳一台或多台Machine。但是，如果AP允许的话，也有可能多个芯片组成一台Machine。
3.方法论和Manifest
对功能应用程序的分布式，独立和敏捷开发的支持需要一种标准化的开发方法。
AUTOSAR自适应方法论涉及工作产品的标准化，用于描述诸如服务，应用程序，Machine及其配置之类的工件。以及定义这些工作产品应如何交互以实现针对自适应平台产品开发所需的各种活动的设计信息交换的相应任务。
图3给出了如何实施自适应方法的概述草案。
4.Manifest
Manifest代表一段AUTOSAR模型描述，该描述是为了支持AUTOSAR AP产品的配置而创建的，并且会上载到AUTOSAR AP产品中，并可能与其他包含Manifest文件的可执行代码的工件（如二进制文件）结合使用。
Manifest的使用仅限于AUTOSAR AP。但是，并不是说在针对AUTOSAR AP的开发项目中生成的所有ARXML都会自动被视为清单。
一辆典型的汽车很可能还配备了许多在AUTOSAR CP上开发的ECU，因此，整个汽车的系统设计必须同时涵盖两个方面——在AUTOSAR CP上构建的ECU和在AUTOSAR AP上创建的ECU。
在应用程序设计时，有必要将术语Manifest的定义细分为三个不同的分区：
应用设计 这种描述指定了所有与设计相关的方面，这些方面适用于为AUTOSAR AP创建应用程序软件。不一定需要将其部署到自适应平台Machine，但是应用程序设计有助于在执行Manifest和服务 Instance Manifest中定义应用程序软件的部署。
执行Manifest 这种Manifest用于指定在AUTOSAR AP上运行的应用程序的与部署相关的信息。执行Manifest与实际的可执行代码捆绑在一起，以支持将可执行代码集成到计算机上。
服务Instance Manifest 此类Manifest用于根据基础传输协议的要求指定如何配置面向服务的通信。服务Instance Manifes与实际的可执行代码捆绑在一起，该可执行代码实现了面向服务的通信的相应用法。
Machine Manifest 这种Manifest应该描述与部署相关的内容，这些内容仅适用于运行AUTOSAR AP的基础计算机（即，该计算机上没有运行任何应用程序）的配置。Machine Manifest与用于建立AUTOSAR AP实例的软件捆绑在一起。
不同种类的Manifest的定义（和用法）之间的时间划分得出这样的结论：在大多数情况下，将使用不同的物理文件来存储这三种Manifest的内容。
除了应用程序设计和不同种类的Manifest外，AUTOSAR方法论还支持系统设计，它有可能在一个单一模型中描述将在系统中使用的两个AUTOSAR平台的软件组件。
不同的AUTOSAR平台的软件组件可以以面向服务的方式相互通信。但是也有可能描述信号到服务的映射，以在面向服务的通信与基于信号的通信之间建立桥梁。
5.应用设计
应用程序设计描述了所有与设计相关的建模，这些建模适用于为AUTOSAR AP创建应用程序软件。应用程序设计侧重于以下方面：
1) 用于对软件设计和实现的信息进行分类的数据类型
2) Service Interface是面向服务的通信的关键要素
3) 定义应用程序如何访问面向服务的通信
4) Persistency接口是访问持久性数据和文件的关键要素
5) 定义应用程序如何访问持久性存储
6) 定义应用程序如何访问文件
7) 定义应用程序如何访问加密软件
8) 定义应用程序如何访问平台运行状况管理
9) 定义应用程序如何访问Time Base
10) 序列化属性，用于定义如何序列化数据以在网络上传输的特征
11) REST Service Interface是通过REST模式与Web服务进行通信的关键要素
12) Client 和Server 功能的描述
13) 对应用程序进行分组，以简化软件的部署。
在应用程序设计中定义的工件独立于应用程序软件的特定部署，因此可以简化针对不同部署场景的应用程序实现的重用。
6.执行Manifest
执行Manifest的目的是提供将应用程序实际部署到AUTOSAR AP所需的信息。
总体思路是保持应用程序软件代码与部署方案尽可能独立，以增加应用程序软件可以在不同部署方案中重用的几率。
通过执行Manifest，可以控制应用程序的实例化，因此可以：
1) 在同一台计算机上多次实例化同一应用程序软件，或者
2) 将应用程序软件部署到多台计算机上，并在每台计算机上实例化应用程序软件。
执行Manifest集中于以下方面：
1) 启动配置，定义应如何启动应用程序实例。启动包括启动选项和访问角色的定义。每次启动可能取决于Machine状态和/或Function Groups状态。
2) 资源管理，尤其是资源组分配。
7.服务Instance Manifest
在网络上实现面向服务的通信需要特定于所使用的通信技术（例如SOME / IP）的配置。由于通信基础结构在服务的提供者和请求者上的行为相同，因此服务的实现必须在双方上都兼容。
服务Instance Manifest集中于以下方面：
1) Service Interface部署，用于定义如何在特定的通信技术上表示服务。
2) Service Instance 部署，以为特定的提供和所需的服务实例定义通信技术所需的凭据。
3) E2E保护的配置
4) Safety保护的配置
5) 日志和跟踪的配置
8.Machine Manifest
Machine Manifest允许配置运行在特定硬件（机器）上的实际自适应平台实例。
Machine Manifest 集中于以下方面：
1) 配置网络连接并定义网络技术的基本凭据（例如，对于以太网，这涉及设置静态IP地址或定义DHCP）。
2) Service Discovery技术的配置（例如，对于SOME / IP，这涉及要使用的IP端口和IP多播地址的定义）。
3) 使用的Machine状态的定义
4) 使用的Function Group的定义
5) 自适应平台功能集群实现的配置（例如，操作系统提供具有特定权限的OS用户列表）。
6) 加密平台模块的配置
7) 平台健康管理的配置
8) 时间同步的配置
9) 可用硬件资源的文档（例如，可用的RAM数量；可用的处理器核数量）
