Adaptive AUTOSAR Communication Management

Adaptive AUTOSAR（一）——Communication Management

前言

Adaptive AUTOSAR是一个比较新的东西，关于它的中文文章或资料都还很稀缺，而英文文章又大多是17或者18 的版本，唯一紧跟最新版本的，只有AUTOSAR官网的资料。我将自己在学习过程中阅读的资料整合并翻译为中文，希望能做一个Adaptive AUTOSAR的系列。

在此特别提示：

1. 本文的主要目的是为作者本人知识的整理提供便利，其次是给有兴趣了解的各位一个参考。
2. 文章内容基于Adaptive AUTOSAR R19-11版本，大部分是由英文资料翻译整合的，中文翻译中我不太确定的部分会以斜体提示并提供英文原文。
3. 文章的末尾有参考资料。

希望大家在阅读的过程中时刻保持怀疑和批判的精神，也欢迎在评论中指正或提出自己的见解。

1.1 简介

为什么在市场上已经有几十种中间件API/技术的情况下，AUTOSAR还要另外再研发一种呢？开发Adaptive AUTOSAR的指导原则就是重用已经存在且已经在相关领域内被证明过的技术吗？

在谈新的中间件的设计之前，我们来评估一下已经存在的，看起来可以被当作候补的技术。它们是：

• ROS API
• DDS API
• CommonAPI（GENIVI）
• DADDY API（Bosch）

最终决定开发新的API是基于以下事实考虑的——并不是所有我们提出的要求都能被现有的技术满足：

• 我们需要一个不受某种特定的网络通信协议限制的Communication Management。它需要支持SOME/IP，同时也能够灵活的进行交换。
• AUTOSAR service model，它以集合的方式定义了许多由方法，事件和字段（field）提供的服务。service model需要被原生/直接支持。
• API需要支持事件驱动或轮询以获取数据。后者主要是为了满足实时应用减少不必要的上下文切换这一要求，而前者对于没有实时性要求的应用来说显然更加方便。
• 为满足ASIL的要求，应能够无缝整合端到端的保护。
• 支持选择静态（实现配置好的）或者动态（运行时）的服务实例作为通信对象

所以，在最终的ara::comAPI细则中，我们能够看到很多从现有的经典平台上提取出来的熟悉的概念：

• Proxy (or Stub)/Skeleton approach (CORBA, Ice, CommonAPI, Java RMI, …)
• Protocol independent API (CommonAPI, Java RMI)
• Queued communication with configurable receiver-side caches (DDS, DADDY,Classic Platform)
• Zero-copy capable API with possibility to shift memory management to the middleware (DADDY)
• Data reception filtering (DDS, DADDY)

1.2 概述

AUTOSAR Adaptive架构将AUTOSAR Adaptive的基础软件以功能簇（cluster）的方式组织起来。这些功能簇（cluster）将常见功能以服务的方式提供给应用。作为"AUTOSAR Runtime for Adaptive Applications"的一部分，Communication Management（CM）就是这样的一个功能簇（cluster）。它负责应用间通信（本地或远程）路径的构建和管理。

CM提供的基础结构使得一台设备上的Adaptive AUTOSAR应用能够和其他设备上的软件实体（如其他的Adaptive AUTOSAR应用或Classic AUTOSAR SWC）进行通信。所有的通信路径都可以在设计或启动或运行时被构建。

1.3 架构层级

Communication Management从逻辑上可以被大致划分为以下子模块：

• Language Binding
• End-to-end communication protection
• Communication / Network binding
• Communication Management software
  

在Communication Management的上下文（context）中，定义了以下接口：

• 公共应用接口：属于Adaptive AUTOSAR的一部分，具体说明在SWS中。这个是标准的ara::com API
• 功能簇交互（Functional Cluster Interactions）：顾名思义，就是存在于功能集群之间的交互。为了让规范更加通俗易懂，也为了让软件集成到实际程序中，这一部分并不严格按照规定实现（上图中虚线箭头）。以及同一功能集群中的元件（element）间的交互（也不是标准的接口），用于Communication Management软件间的通信（图中灰色箭头）。

请注意，尽管Language Binding和Communication Binding依靠整合者（integrator）的具体配置，但是仍需要被部署在应用的二进制文件中（to be deployed within the application binary）。这就导致Communication Binding的序列化（serialization）将会在Adaptive应用运行时的上下文中进行。

1.4 设计约束

对于ARA API的设计，有以下约束条件需要注意：

• 支持应用程序组件的独立性
• 使用以服务为导向的通信而不是依赖于某一具体通信协议
• 使得API尽可能的精简，既不要支持在API之上能够实现的某些特别具体的用例，也不要支持组件模型或更高层级的概念。API应当仅仅支持最核心的通信机制。
• 支持动态通信（dynamic communication）：
  1. 对应用中间件完全不可见。通俗点说，客户端知道服务器，但服务器并不知道客户端。事件订阅（event subscription）是应用动态通信的唯一模式。
  2. 服务发现（service discovery）对应用完全开放。在配置时不会有任何通信路径可见。一个用于服务发现的API使得应用代码能够选择服务实例（service instance）。
• 支持事件/回调和轮询两种风格的API调用来使能classic RTE风格的范例。为了支持事件/回调下的高确定性的交互，应当确保有能力避免不受控制的上下文切换。
• 支持同步回调方式的通信，也支持异步通信。
• 支持客户端/服务器的通信。
• 支持last-is-best和queued semantics的发送者/接收者通信。在queue通信模式下，接收者的缓存是可以配置的。
• 可选条件触发方式来激活任务。
• 安全性扩展。
• Quality of Service扩展。
• 实时操作系统的扩展性。
• 支持内建的端到端通信保护，此种情形下，某些特殊用例可以在ARA API之上完成。

1.5 设计原则

对于ARA API的设计，有以下原则需要遵守：

• 使用Proxy/Skeleton模式：
  • proxy服务代表着可能存在的远程（如其他进程，其他核，其他节点）服务。它是应用/客户端的C++类的本地化实例。
  • skeleton服务是用户提供的服务实现与中间件传输结构的连接。服务实现类是由skeleton服务衍生出来的。
  • 除了proxies/skeletons，可能还会存在一个叫做"Runtime"的类，它提供管理proxies和skeletons的必要组件。但这个组件目前并没有在此文档（R19-11）中详细描述，在以后的发行版中也许会添加进去。

关于proxy/skeleton的总体设计模式和它在中间件实现中的角色，请参考¹，²

• 支持数据接收的回调机制
• API应具备zero-copy（主要目的是减少发送到接收过程中不必要的数据拷贝，具体请参考³的9.1.1 zero-copy impilcations）以及在中间件进行内存管理的能力
• 支持对收到的数据进行筛选
• 它应当与AUTOSAR服务模型（服务，实例，事件，方法等）保持一致，使得API能从该模型中生成代理和框架。
• 在API级别支持全面的发现和服务实例选择（Full discovery and service instance support on API level）。
• 客户端/服务器通信使用C++ 1 1的概念编写（如std::future, std::promise）以支持不同的上下文间的方法调用。
• 从SOME/IP的具体表现中抽象出来，但是支持SOME/IP服务机制，如方法，事件和字段（fields）。
• 支持/实现标准的端到端保护协议，参考⁴和⁵ 。
• 支持Service contract versioning（参考1.7节）。
• 支持以*事件和轮询（Event and Polling）*的方式使用API，从而支持经典的RTstyle范例。
• 为了给应用开发者提供便利和提升易用性，应在API的设计开发中全面使用C++ 11/14的特性。

更多细则和详情请参考³

1.6 通信范例

作为依赖服务的架构（Service-Oriented Architecture, SOA）的一部分，依赖服务的通信（Service-Oriented Communication, SOC），是Adaptive AUTOSAR应用的主要通信模式。它允许在程序运行的同时建立通信路径，因而得以支持未知参与者数量的动态通信。下图展示了依赖服务通信的基本操作原则。

由Service Discovery来决定是建立内部的还是外部的通信。发现策略（discovery strategy）应允许返回特定的或提出请求的服务在请求时能提供的所有实例（无论这些实例是在本地还是远程）。Communication Software软件应当根据服务提供者所在的位置，为Service Discovery和通信连接提供相应的优化。更多关于Service Discovery的内容可以参考⁶。

1.7 Service contract versioning

在依赖服务的架构（Service Oriented Architecture， SOA）中，客户端和服务提供者都依赖于一个包含了服务接口和具体表现的契约（contract）。然而随着时间的流逝，服务接口和具体表现都可能发生变化。因此不同Service contract versioning这一机制被引入。

AUTOSAR Adaptive platform就支持这一特性。在Adative platform中，service contract versioning被划分为设计阶段和部署阶段。这就意味着，任何一个设计层级的服务可能都会有它自己的一个版本号，这个版本号同时会与部署阶段该服务的版本号绑定，反之亦然。这个映射的过程是由服务设计者或整合者手动完成的。

参考资料：

---

1. Middleware for Real-time and Embedded Systems ↩︎

2. Patterns, Frameworks, and Middleware: Their Synergistic Relationships ↩︎

3. Explanation of ara::com API ↩︎ ↩︎

4. Requirements on E2E ↩︎

5. E2E Protocol Specification ↩︎

6. SOME/IP Service Discovery Protocol Specification ↩︎