目录
3.3方法和清单Methodology and Manifest
3.7服务实例清单Service Instance Manifest
3.1逻辑视图
3.1.1ARA
图3-1AP架构逻辑视图显示了AP的架构。自适应应用程序（AA）运行在ARA之上，ARA（AUTOSARRuntimeforAdaptiveapplications）。ARA由功能集群提供的应用接口组成，它们属于自适应平台基础或自适应平台服务。自适应平台基础提供AP的基本功能，自适应平台服务提供AP的平台标准服务。任何AA也可以向其他AA提供服务，如图中所示为非平台服务。
功能集群的接口，它们是自适应平台基础或自适应平台服务的接口，与AA无关，它们只提供指定的C++接口或任何其他语言绑定AP将来可能支持的功能。另外，在ARA接口下面，包括在AA上下文中调用的ARA库，可能会使用ARA以外的其他接口来实现AP规范，这取决于AP实现的设计。
图3-1AP架构逻辑视图
请注意，图3-1AP架构逻辑视图包含不属于当前AP版本的功能集群，以便更好地了解整体结构。此处未显示的更多新功能集群很可能会在AP的未来版本中添加。
3.1.2语言绑定、C++标准库和POSIXAPI
这些API的语言绑定是基于C++的，C++标准库也可以作为ARA的一部分。关于操作系统API，只有PSE51接口，POSIX标准的单进程配置文件是ARA的一部分。选择PSE51是为了为现有POSIX应用程序提供可移植性，并实现应用程序之间的自由干扰。
（POSIXPSE51是POSIX标准的一个子集，不需要多进程（线程），不需要文件系统。POSIXPSE51是最小的子集。这个子集是为了嵌入式实时系统而创造出来的，详细信息见IEEE1003.13-2003。）
注意，C++标准库包含基于POSIX的许多接口，包括多线程API。建议不要将C++标准库线程接口与本地PSE51线程接口混合，以避免并发问题。不幸的是，C++标准库不包括所有的PSE51函数，例如设置线程调度策略。在这种情况下，可能需要同时使用两个接口。
3.1.3应用程序启动和关闭
应用程序的生命周期由执行管理（ExecutionManagement，EM）管理。应用程序的加载/启动是通过使用EM的功能来管理的，它需要在系统集成时或运行时进行适当的配置才能启动应用程序。事实上，从EM的角度来看，所有功能集群都是应用程序，除了EM本身之外，它们也是以相同的方式启动的。图3-2应用程序说明了AP内和AP上不同类型的应用程序。
图3-2应用程序
请注意，应用程序启动或终止的时间不是由EM决定的。一个称为状态管理（StateManagement，SM）的特殊FC是控制器，根据系统设计命令EM，仲裁不同的状态，从而控制整个系统行为。由于此处的系统指的是整个机器AP及其正在运行的应用程序，因此实现的内部行为是特定于项目的。SM还与其他FC交互，以协调整个机器行为。SM应仅使用标准ARA接口来维护不同AP堆栈实现之间的可移植性。
3.1.4应用程序交互
关于AA之间的交互，PSE51不包括IPC（进程间通信），因此AA之间没有直接的交互接口。
通信管理（CommunicationManagement，CM，com）是唯一明确的接口。CM还为机器内和机器间提供面向服务的通信，这对应用程序是透明的。CM处理服务请求/回复的路由，而不考虑服务和客户端应用程序的拓扑部署。请注意，其他ARA接口可能会在内部触发AA之间的交互，但是，这不是一个明确的通信接口，而是各个ARA接口提供的功能的副产品。
理解就是AA1à>CM1àARAàCM2àAA2;
3.1.5非标准接口
AA和功能集群可使用任何非标准接口，前提是它们不与标准AP功能冲突，并且符合项目的安全/安保要求。除非它们是纯应用程序本地运行库，否则应注意尽量减少此类使用，因为这将影响软件在其他AP实现上的可移植性。
3.2物理视图
这里讨论了AP的物理架构。本节中的大部分内容仅用于说明目的，并不构成AP的正式需求规范，因为AP的内部是实现定义的。明确规定了AP实施的任何正式要求。作为额外的信息来源，请参阅EXP_Swachiture，它更详细地描述了AP的内部架构。
3.2.1操作系统、进程和线程
AP操作系统需要提供多进程POSIX操作系统功能。每个AA都作为一个独立的进程实现，具有自己的逻辑内存空间和名称空间。请注意，一个AA可能有多个进程，这些进程可以部署到单个AP实例上，也可以分布在多个AP实例上。从模块组织的角度来看，每个进程都由操作系统从一个可执行文件实例化。可以从单个可执行文件实例化多个进程。此外，AA可能构成多个可执行文件。
功能集群（FunctionalClusters）(就是中间件)也通常作为进程实现。功能性集群也可以通过单个进程或多个（子）进程来实现。自适应平台服务和非平台服务也作为进程实现。
所有这些进程都可以是单线程进程或多线程进程。
但是，根据进程所属的逻辑层，它们可以使用的操作系统API有所不同。如果他们是在ARA上运行的AAs，那么他们应该只使用PSE51。如果进程是功能集群之一，则可以自由使用任何可用的操作系统接口。
总之，从操作系统的角度来看，AP和AA只是一组进程，每个进程都包含一个或多个线程——这些进程之间没有区别，尽管AP的实现可以提供任何类型的分区。这些过程通过IPC或任何其他可用的操作系统功能相互交互。请注意，AA进程不能直接使用IPC，只能通过ARA进行通信。
3.2.2基于库或基于服务的功能集群实施
如图3-1AP体系结构逻辑视图，功能集群可以是自适应平台基础模块或自适应平台服务。如前所述，这些通常都是进程。为了与AA进行交互（AA也是进程），他们需要使用IPC。有两种可供选择的设计来实现这一点。一种是“基于库”的设计，其中由功能集群提供并链接到AA的接口库直接调用IPC。另一种是“基于服务”的设计，流程使用通信管理功能（Communication Management functionality），并有一个链接到AA的服务器代理库。代理库调用通信管理接口，该接口协调AA进程和服务器进程之间的IPC。注：AA是仅通过通信管理直接执行IPC，还是通过代理库（Proxy Library）与服务器直接IPC混合，这是实现时定义的。
//也就是AA与中间件通信有两种
- 中间件直接提供库，连接到AA，调用IPC
- 中间件和AA之间隔了一个通信管理功能，这上面有个代理库，链接到AA，他协调AA进程和服务器进程之间的IPC
为功能集群选择设计的一般准则是，如果只在AP实例中本地使用，则基于库的设计更合适，因为它更简单、更高效。如果以分布式方式从其他AP实例使用，则建议采用基于服务的设计，因为通信管理提供透明通信，而不考虑客户端AA和服务的位置。属于自适应平台基础的功能集群是“基于库的”，自适应平台服务是“基于服务的”。
最后，请注意，允许FC的实现可以不是进程，而是以库的形式实现，在AA运行在进程中的前提下，只要它满足FC定义的RS和SWS。在这种情况下，AA和FC之间的交互将是常规过程调用，而不是前面描述的基于IPC的。
3.2.3功能集群之间的相互作用
通常，功能集群可以以特定于AP实现的方式彼此进行交互，因为它们不绑定到限制IPC使用的ARA接口，例如PSE51。它实际上可能使用其他功能集群的ARA接口，这些接口是公共接口。功能集群之间的一个典型交互模型是使用功能集群的受保护接口提供实现功能集群特殊功能所需的特权访问。
此外，从AP18-03开始，引入了功能间集群（Inter-Functional-Cluster，IFC）接口的新概念。它描述了一个FC向其他FC提供的接口。注意，它不是ARA的一部分，也不构成AP实现的正式规范要求。通过澄清FC之间的相互作用，提供这些规范以促进AP规范的开发，并且它们还可以为AP规范的用户提供更好的AP架构视图。各FCSWS（SoftwareSpecification软件规范）的附录中描述了接口。
3.2.4机器/硬件
AP将其运行的硬件视为一台机器。这背后的基本原理是实现一致的平台视图，而不考虑可能使用的任何虚拟化技术。该机器可能是真正的物理机器、完全虚拟化的机器、准虚拟化的操作系统、操作系统级虚拟化容器或任何其他虚拟化环境。
在硬件上，可以有一台或多台机器，并且一台机器上只能运行一个AP实例。通常认为该“硬件”包括一个芯片，承载一台或多台机器。然而，如果AP实现允许，多个芯片也可能形成一台机器。
3.3方法和清单Methodology and Manifest
支持功能应用程序的分布式、独立和敏捷开发需要一种标准化的开发方法。AUTOSAR自适应方法涉及工作产品的标准化，用于描述服务、应用程序、机器及其配置等；以及定义这些工作产品如何交互以实现各种活动，图3-3说明了如何实施自适应方法的概述草案。
图3-3AP开发工作流程
3.4清单Manifest
Manifest表示一段AUTOSAR模型描述，该描述用于支持AUTOSARAP产品的配置，并上载到AUTOSARAP产品，可能与包含清单适用的可执行代码的其他成果物（如二进制文件）结合使用。
Manifest的使用仅限于AUTOSARAP。然而，这并不意味着在以AUTOSARAP为目标的开发项目中生成的所有ARXML都自动被视为清单。
事实上，AUTOSARAP通常并非专用于车辆项目。
一辆典型的车辆很可能还配备了在AUTOSARCP上开发的多个ECU，因此，整个车辆的系统设计必须涵盖这两个方面——在AUTOSARCP上构建的ECU和在AUTOSARAP上创建的ECU。
原则上，术语Manifest的定义可以使概念上只有一个“清单”，并且每个部署层面都将在此环境范围中处理。这似乎不合适，因为很明显，清单相关的模型元素存在于典型开发项目的完全不同阶段。
这一方面被视为主要动机，即在应用程序设计之后，有必要将术语清单的定义细分为三个不同的分区：
应用程序设计ApplicationDesign此类描述指定了适用于为AUTOSARAP创建应用软件的所有设计相关方面。它不一定需要部署到adaptiveplatform机器上，但应用程序设计有助于在执行清单和服务实例清单中定义应用程序软件的部署。
执行清单Executionmanifest此类清单用于指定在AUTOSARAP上运行的应用程序的部署相关信息。
执行清单与实际可执行代码捆绑在一起，以支持将可执行代码集成到机器上。
服务实例清单ServiceInstanceManifest这种清单用于指定如何根据底层传输协议的要求配置面向服务的通信。
服务实例清单与实际的可执行代码捆绑在一起，这些代码实现了面向服务通信的各自用法。
机器舱单MachineManifest这种清单应该描述与部署相关的内容，这些内容仅适用于运行AUTOSARAP的底层机器（即，没有任何应用程序在机器上运行）的配置。
机器清单与用于建立的实例的软件捆绑在一起
AUTOSARAP。
不同种类清单的定义（和使用）之间的时间划分导致以下结论：在大多数情况下，将使用不同的物理文件来存储三种清单的内容。
除了应用程序设计和不同种类的清单之外
AUTOSAR方法支持系统设计，可以在单个模型中描述系统中使用的两个AUTOSAR平台的软件组件。不同AUTOSAR平台的软件组件可以以面向服务的方式相互通信。但也可以描述信号到服务的映射，以在面向服务的通信和基于信号的通信之间建立桥梁。
3.5应用程序设计Application Design
应用程序设计描述了适用于为AUTOSARAP创建应用程序软件的所有设计相关建模。
应用程序设计主要关注以下几个方面：
•用于对软件设计和实施信息进行分类的数据类型
•服务接口作为面向服务通信的关键元素
•定义应用程序如何访问面向服务的通信–>接口的通信方式
•Persistency接口作为访问持久性数据和文件的关键元素
•定义应用程序如何访问持久性存储
•定义应用程序如何访问文件
•定义应用程序如何访问加密软件
•定义应用程序如何访问平台健康管理
•定义应用程序如何访问时基TimeBases
•序列化属性，用于定义网络传输数据序列化方式的特征
•REST服务接口是通过REST模式与web服务通信的关键元素
•Descriptionofclientandservercapabilities
•应用程序分组，以简化软件部署。
应用程序设计中定义的构件独立于应用程序软件的特定部署，因此便于在不同部署场景中重用应用程序实现。
3.6执行清单Execution manifest
执行清单的目的是提供在AUTOSARAP上实际部署应用程序所需的信息。
总体思路是使应用软件代码尽可能独立于部署场景，以增加应用软件在不同部署场景中重用的可能性。
通过执行清单，可以控制应用程序的实例化，因此可以在同一台机器上多次实例化同一应用软件，或将应用软件部署到多台机器上，并为每台机器实例化应用软件。
执行清单侧重于以下几个方面：
- 启动配置，用于定义应如何启动应用程序实例。启动包括启动选项和访问角色的义。
- 每次启动可能取决于机器状态和/或功能组状态。
- 资源管理，特别是资源组分配。
3.7服务实例清单Service Instance Manifest
在网络上实现面向服务的通信需要特定于所使用的通信技术（例如，SOME/IP）的配置。由于通信基础设施在服务的提供者和请求者上的行为相同，因此服务的实现必须在双方都兼容。
服务实例清单主要关注以下方面：
•服务接口部署，以定义如何在特定通信技术上表示服务。
•服务实例部署，为特定提供和要求的服务实例定义通信技术所需的凭据。
•E2E保护的配置
•安全保护的配置
•日志和跟踪（Log and Trace）的配置
3.8机器清单Machine Manifest
机器清单允许配置在特定硬件（机器）上运行的实际自适应平台实例。
机器清单主要关注以下方面：
•配置网络连接并定义网络技术的基本凭证（例如，对于以太网，这涉及到静态IP地址的设置或DHCP的定义）。
•服务发现技术的配置（例如，对于SOME/IP，这涉及到要使用的IP端口和IP多播地址的定义）。
•已用机器状态的定义
•所用功能组的定义
•自适应平台功能集群实施的配置（例如，操作系统提供具有特定权限的操作系统用户列表）。
•加密平台模块的配置
•平台健康管理的配置
•时间同步的配置
•可用硬件资源的文档（例如，有多少RAM可用；有多少处理器内核可用）
203
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
