AUTOSAR_EXP_ARAComAPI的3章节笔记
返回目录
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依赖。
3.2 API Design Visions and Guidelines
新的中间件API设计的一个目标是让它尽可能精简。也就是说，它应该只提供支持基于服务的通信范例所需的最小功能集，包括基本机制:Method、Event和Filed。此处，我们对“尽可能精简”这一概念的定义是:本质上，API应该只处理在服务消费者和服务提供者实现端处理Mechod、Filed和Event通信的功能。
如果我们决定提供比这更多的东西，那么原因通常是“如果在我们的API上层不能有效地解决某个与通信相关的问题，我们将解决方案作为ara::com API层的一部分提供。”因此，ara::com不提供任何类型的组件模型或框架，这些模型或框架将负责组件生命周期、程序流管理或根据应用程序的正式组件描述简单地设置ara::com API对象。所有这些都可以很容易地构建在基本的ara::com API之上，并且不需要标准化来支持典型的协作模型。
在API的设计阶段，我们不断质疑我们草案的每一部分，它是否允许来自AutoSar AP供应商的高效IPC实现，因为我们知道，您可以很容易地在API抽象级别上破坏它，这使得实现性能良好的绑定很难或几乎不可能。
API的中心设计点之一是(如导言中所述): 新的API同样需要支持轮询和事件驱动编程范例。因此，您将在后面的章节中看到，应用程序开发人员在使用ara::com时，可以自由选择最适合其应用程序设计的方法，而与实现通信关系的是服务消费者还是服务提供者无关。这允许支持严格实时调度的应用程序（最关键的是：需要完全控制在何时何地做什么,而无需进行不必要的上下文切换）。另一方面，也完全支持更宽松的基于事件的应用程序（只要通信层有数据可用，这些应用程序就会收到通知）。 AUTOSAR决定真正支持C++11/C++14（PS: C++11/C++14非常适合ara::com API设计）。为了增强可用性、舒适性和优雅，ara::com API利用了C++的一些特性，如智能指针、模板函数和类、异步操作的成熟概念以及合理的操作符重载。