3.1 Approach
为什么AUTOSAR发明了另一种通信中间件API/技术，而市场上有几十种——尤其是AutoSar AP的指导方针之一是重用现有的经过验证的技术？在提出新的中间件设计之前，我们确实评估了现有的技术，乍一看，这些技术似乎是有效的候选技术。其中包括:
-
ROS API
-
DDS API
-
CommonAPI (GENIVI)
-
DADDY API(Bosch)
之所以最终决定开发新的AUTOSAR专用通信管理API，是因为现有解决方案并不能满足我们所有的关键需求:
-
我们需要一种通信管理，它不局限于具体的网络通信协议。它必须支持SOME/IP协议，但必须有交换的灵活性。
-
AUTOSAR服务模型将服务定义为所提供的Method、Event和Filed的集合，应自然/直接得到支持。
-
API应支持事件驱动和轮询模式，以同样良好地访问通信数据。后者通常是实时应用程序所需要的，以避免不必要的上下文切换，而前者对于没有实时要求的应用程序来说要方便得多。
-
无缝集成E2E保护以满足ASIL要求。
-
支持静态(预配置)和动态(运行时)选择服务实例进行通信。
因此，在最终的ara::com API规范中，读者会发现一些概念(我们将在接下来的章节中深入描述)，这些概念可能是他所熟悉的，来自我们已经评估过的技术，甚至来自现有的Autosar CP:
-
proxy/Skeleton方法(CORBA，Ice，CommonAPI，Java RMI，...)
-
独立于协议的API (CommonAPI，Java RMI)
-
通过可配置的接收端缓存进行排队通信(DDS、DADDY、Classic平台)
-
支持零拷贝的API，可以将内存管理转移到中间件(DADDY)
-
数据接收滤波(DDS，DADDY)
既然我们已经建立了一个新的中间件API的介绍，我们将在接下来的章节中详细介绍这些API。 以下陈述基本上是所有AUTOSAR AP规范的基础，但在此应再次明确指出:ara::com只定义了对应用程序开发人员可见的API签名及其行为。提供这些API和底层中间件传输层的实现是AUTOSAR AP供应商的责任。
对于与AUTOSAR CP的粗略比较，ara::com可被视为满足AUTOSAR AP中的功能要求，类似于AUTOSAR CP中RTE API涵盖的功能要求，如Rte_Write、Rte_Read、Rte_Send、Rte_Receive、Rte_Call、Rte_Result。
建模元素及其相互关系概述: ServiceInterface、部署、依赖于所提供的部署信息的实际生成(例如，稍后将生成的ServiceInterface元素与ServiceInstance Manifest的关系)。AUTOSAR AP方法解释了构建系统所需的流程以及它们之间的相互关系。它定义了交付或进行的活动和工作产品以及原始设备制造商和供应商所扮演的角色。
开发适应性软件的主要步骤是：
-
架构和设计
-
AP软件开发
-
集成和部署
AP应用软件运行在ARA层之上，并使用ServiceInterface和端口交换信息。ara::com API工作的重要贡献是在自适应方法的集成和部署步骤中体现的。它支持ServiceInterface描述的ARXML文件生成，该文件集合了ServiceInterface和端口。服务接口是由Event、Method和Filed定义的面向服务通信。这是独立于底层通信的软件组件或传输层来完成的。AUTOSAR AP支持两种类型的端口，即提供者端口和请求者端口。ServiceInterface与用于生成服务框架类的提供者端口细节和用于生成代理类的请求者端口细节伴随此出现的。形象的如下图表示。
Proxy Class和Skeleton Class使用ara::com API与其他AutoSar AP集群和AutoSar AP应用程序进行通信。形象的如下图表示。
配置服务实例，都要将ServiceInterface绑定到选定的传输层，无论是提供者或请求者特定的服务实例，以及是否存在于专用Machine的映射。服务实例的配置显示在ServiceInstance Manifest中。AP软件的Executable通过Execution Manifest。这里的实例化意味着将Executable绑定到操作系统的特定Process的上下文中。根据Machine Mode，每个Process可能以不同的start-up configuration开始。此外，Execution Manifest还定义了软件Process依赖。
