2.1.2 物理架构
接下来介绍和讨论AP的物理架构。
提醒：本节中的大部分内容仅用于说明目的，并不构成AP的正式需求规范，因为AP的内部是实现定义的。对应用程序实现的任何正式要求都是明确声明的。
1.OS、进程与线程之间的关系
AP的操作系统需要具有能够提供多进程同时运行的能力。每个AA都是作为一个独立的进程实现的，它们都有自己的逻辑内存空间和命名空间。请注意，单个AA可能包含多个进程，这可能部署到单个AP实例上，也可能分布在多个AP实例上。从模块组织的角度来看，每个进程都是由操作系统从可执行文件实例化的。多个进程也可以从同一个可执行文件实例化。此外，AA可以构成多个可执行文件。功能集群通常也作为进程来实现，功能集群也可以用单个或多个进程来实现。自适应平台服务和非平台服务也可以作为进程实现。
所有这些进程可以是单线程进程，也可以是多线程进程。但是，根据进程所属的逻辑层的不同，它们可以使用的操作系统API也不同。如果它们是在ARA之上运行的AA，那么它们应该只使用PSE51。如果进程是功能集群之一，则可以自由使用任何可用的操作系统接口。
总之，从操作系统的角度来看，AP和AA只是形成了一组进程，每个进程包含一个或多个线程——这些进程之间没有区别，尽管提供任何类型的分区取决于AP的实现。这些进程通过IPC或任何其他可用的操作系统功能相互作用。
注意：AA进程可能不直接使用IPC，只能通过ARA进行通信。
功能集群可以是自适应平台基础模块或自适应平台服务。如前所述，这些通常都是进程。它们需要使用IPC才能让其与同样是进程的AA进行交互。有两种替代设计可以实现这一点：一种是“基于库”的设计，由功能集群提供链接到AA的接口库，直接调用IPC；另一种是“基于服务”的设计，其中进程使用CM的功能函数，并有一个链接到AA的服务器代理库。代理库调用CM接口，该接口协调AA进程和服务器进程之间的IPC。
注意：它是由实现定义的，是AA仅通过CM直接执行IPC或通过混合有代理库与服务器的直接执行的IPC。
为功能集群选择设计的一般准则是，如果它仅在本地使用AP应用程序实例，那么基于库的设计更合适，因为它更简单，效率更高。如果以分布式方式从其他AP实例使用它，则建议采用基于服务的设计，因为CM提供透明的通信，而不管客户端AA和服务具体的位置如何。自适应平台基础所属的功能集群是“基于库的”，自适应平台服务是“基于服务的”。关于“基于服务”的和“基于库”的内容还需要注意的是，FC的实现是可以不包含有进程的，可以以库的形式实现，在AA的进程中运行时，只要它满足FC定义的RS和SWS。在这种情况下，AA和FC之间的交互将是常规的过程调用，而不是前面描述的基于IPC的。
2.FC之间的交互
一般来说，功能集群可以以特定于应用程序实现的方式相互交互，因为它们没有绑定限制使用IPC的ARA接口。例如PSE51，它确实可能使用其他功能集群的ARA接口，这些接口是“public”接口。功能集群之间的一个典型交互模型是使用自适应平台设计的功能集群的“protected”接口来提供实现功能集群的特殊功能所需的访问权限。此外，从AP18-03开始，引入了功能间集群（IFC）接口的新概念。请注意，它不是ARA的一部分，也不构成对AP实现的正式规范要求。提供这些是为了通过阐明FC之间的交互来促进AP规范的开发，并且它们还可以为AP规范的用户提供更好的AP架构视图。接口在各自附加的FC SWS中进行了描述。
在上文中提到了机器（Machine），接下来讲解一下机器的概念。
AP将其运行的平台视为机器，机器可以是真实的物理机器、完全虚拟化的机器、半虚拟化的操作系统、操作系统级虚拟化的容器或任何其他虚拟化的环境。在硬件上，可以有一台或多台机器，一台机器上只能运行一个应用程序实例。通常假设这个“硬件”包括一个芯片，运行一台或多台机器。然而，如果AP允许，也有可能多个芯片组成一台机器。
在AP的物理架构中，还有很重要的一环是清单（Manifest）。清单是AUTOSAR模型描述的一部分，它是为支持AUTOSAR AP产品的配置而创建的，并被上传到AUTOSAR AP产品，可能与包含清单适用的可执行代码的其他文件（如二进制文件）相结合，清单的使用仅限于自动搜索应用程序。然而，这并不意味着在以AUTOSAR AP为目标的开发项目中产生的所有ARXML都自动被视为清单。事实上，一个车辆项目一般不会仅仅使用AUTOSAR AP，很可能还会配备许多在AUTOSAR CP上开发的ECU，因此，整车的系统设计必须涵盖这两者——在AUTOSAR CP上构建的ECU和在AUTOSAR AP上创建的ECU。
原则上，清单可以这样定义，即在概念上只有一个“清单”，并且每个部署都将在这个清单的内容中处理。但是这似乎不合适，因为清单相关的模型元素存在于开发项目的不同阶段。在应用程序设计之后有必要将清单（Manifest）一词的定义细分为三个不同的部分。
1）执行清单（Execution Manifest）：这种清单用于指定在AUTOSAR AP上运行的应用程序的部署相关信息。执行清单与实际的可执行代码捆绑在一起，以支持将可执行代码集成到机器上。
2）服务实例清单（Service Instance Manifest）：这种清单用于指定如何根据底层传输协议的要求配置面向服务的通信。服务实例清单与实际的可执行代码捆绑在一起，实现面向服务的通信的各自用法。
3）机器清单（Machine Manifest）：这种清单应该描述与部署相关的内容，这些内容只适用于运行AUTOSAR应用程序的底层机器（即没有任何应用程序在机器上运行）的配置。机器清单与用来建立AUTOSAR应用程序实例的软件捆绑在一起。
不同种类清单的定义（和使用）之间的时间划分导致这样的结论：在大多数情况下，不同的文件将被用来存储三种清单的内容。除了应用程序设计和不同种类的清单之外，AUTOSAR方法支持系统设计，可以描述将在一个单一模型的系统中使用的两个AUTOSAR平台的软件组件。不同AUTOSAR平台的软件组件可以以面向服务的方式相互通信。但是也可以描述信号到服务的映射，从而在面向服务的通信和基于信号的通信之间建立桥梁。
应用程序设计描述了应用于AUTOSAR AP应用程序软件创建的所有与设计相关的建模。应用程序设计侧重于以下方面：
1）用于对软件设计和实现的信息进行分类的数据类型。
2）作为面向服务通信的关键元素的服务接口。
3）定义应用程序如何访问面向服务的通信存储接口。
4）作为访问存储数据和文件的关键元素。
5）定义应用程序如何访问存储。
6）定义应用程序如何访问文件。
7）定义加密软件如何访问应用程序。
8）定义应用程序如何访问平台健康管理。
9）定义应用程序如何访问时基。
10）定义序列化属性。
11）定义数据的特征如何序列化以在网络上传输。
12）描述客户端和服务器功能。
13）对应用程序进行分组以简化软件部署。
应用程序设计中定义的工件独立于应用程序软件的特定部署，因此便于在不同的部署场景中重用应用程序实现。
下面来详细介绍各个清单部分。
（1）执行清单的目的是提供在AUTOSAR AP上实际部署应用程序所需的信息
总的想法是保持应用软件代码尽可能独立于部署场景，以增加应用软件在不同部署场景中的复用性。通过执行清单，应用程序的实例化受到控制，因此可以：①在同一台机器上多次实例化同一个应用软件；②将应用软件部署到几台机器上，并在每台机器上实例化应用软件。
执行清单侧重于以下几个方面：
1）启动配置，以定义如何启动应用程序实例。启动包括启动选项和访问角色的定义。每次启动可能取决于机器状态/功能组状态。
2）资源管理，特别是资源组分配。
（2）服务实例清单在网络上实现面向服务的通信需要特定于所使用的通信技术（例如SOME/IP）的配置
由于通信基础设施在服务的提供者和请求者上的行为应该是相同的，因此服务的实现必须是双方兼容的。
服务实例清单侧重于以下方面：
1）服务接口部署，定义服务在特定通信技术上的表现方式。
2）服务实例部署，为特定提供和要求的服务实例定义通信技术所需的凭证。
3）E2E保护的配置。
4）安全保护的配置。
5）日志和跟踪的配置。
（3）机器清单允许配置在特定硬件（机器）上运行的实际自适应平台实例
机器清单侧重于以下方面：
1）网络连接的配置和定义网络技术的基本凭证（例如，对于以太网，涉及静态IP地址的设置或DHCP的定义）。
2）服务发现技术的配置（例如，对于SOME/IP，涉及要使用的IP端口和IP多播地址的定义）。
3）已用机器状态的定义。
4）已用功能组的定义自适应平台功能集群实现的配置（例如，操作系统提供具有特定权限的操作系统用户列表）。
5）加密平台模块的配置。
6）平台健康管理的配置。
7）时间同步的配置。
8）可用硬件资源的文档（例如，有多少内存可用；有多少处理器内核可用）。