AUTOSAR图解==＞AUTOSAR_AP_EXP_ARAComAPI

AUTOSAR ara::com API详解

自适应平台通信API技术详解

目录

• 1. 概述
• 2. ara::com API架构
  • 2.1 Proxy/Skeleton架构
  • 2.2 通信方式
  • 2.3 服务连接方式
• 3. 详细API说明
  • 3.1 Proxy类
  • 3.2 Skeleton类
  • 3.3 实例标识符
  • 3.4 通信组
• 4. ara::com API状态管理
  • 4.1 服务生命周期
  • 4.2 事件与方法状态管理
• 5. 总结

---

1. 概述

AUTOSAR Adaptive Platform (AP) 中的ara::com API是用于服务导向通信的核心组件，为应用程序提供了标准化的接口，支持组件间的透明通信。该API采用面向服务的架构，支持多种通信模式，包括：事件、方法调用、字段访问等。

ara::com API的主要目标是实现：

• 应用程序与通信机制的解耦
• 标准化的服务发现与连接方式
• 支持同步和异步通信模式
• 提供灵活的错误处理机制

ara::com API在AUTOSAR AP中的定位是作为应用程序通信的基础设施，支持车载系统中各组件（如传感器、控制单元、HMI等）之间的高效数据交换。

---

2. ara::com API架构

2.1 Proxy/Skeleton架构

ara::com API采用Proxy/Skeleton架构模式，这种模式将通信双方分为服务使用方（Client）和服务提供方（Server）。

图2.1 ara::com API整体架构

图2.1展示了ara::com API的整体架构，包括以下核心组件：

1. 应用层：

   • 应用程序通过Proxy类使用远程服务
   • 应用程序通过Skeleton类实现并提供服务

2. ara::com API层：

   • Proxy类：客户端用于查找和使用远程服务的接口
   • Skeleton类：服务端用于提供服务实现的框架
   • 事件处理：支持发布-订阅模式的通信
   • 方法调用：支持同步/异步的远程方法调用
   • 字段访问：支持远程属性的读写操作
   • 触发器：支持基于触发器的通信模式
   • 实例标识符：用于唯一标识服务实例
   • 通信组：用于服务分组管理

3. 底层通信服务：

   • 通信绑定：负责实际的通信传输
   • 服务发现：负责服务的注册和发现

这种分层架构使得应用程序可以专注于业务逻辑，而无需关心底层通信细节。通过标准化的接口，ara::com支持不同通信技术的平滑替换，同时保证应用程序代码的稳定性。

2.2 通信方式

ara::com API支持多种通信模式，适应不同的应用场景需求：

1. 基于事件的通信：

   • 实现发布-订阅模式
   • 支持一对多的数据分发
   • 适用于状态变化通知、数据更新等场景

2. 基于方法的通信：

   • 支持请求-响应模式
   • 提供同步和异步调用选项
   • 支持取消操作和超时处理
   • 适用于命令执行、查询操作等场景

3. 基于字段的通信：

   • 提供远程属性访问机制
   • 支持Get/Set操作
   • 适用于配置参数、状态变量等场景

4. 基于触发器的通信：

   • 支持条件触发的通信
   • 适用于特定条件下的通知机制

图2.2 ara::com API服务交互序列

图2.2展示了ara::com API中的服务交互序列，包括以下关键流程：

1. 服务提供：

   • 服务端创建Skeleton实例
   • 向服务发现组件注册服务实例
   • 确认服务已提供

2. 服务发现：

   • 客户端通过调用FindService查找服务
   • 服务发现组件返回服务实例标识符
   • 返回代理实例给客户端

3. 事件订阅：

   • 客户端调用Subscribe()方法
   • 建立事件订阅关系
   • 服务端确认订阅

4. 事件通知：

   • 服务端触发事件
   • 通过通信绑定传递事件数据
   • 客户端接收事件通知

5. 方法调用：

   • 客户端调用远程方法
   • 通信绑定转发方法调用
   • 服务端执行方法实现
   • 返回方法结果给客户端

6. 字段访问：

   • 客户端请求获取字段值
   • 服务端执行GetHandler
   • 返回字段值给客户端

这种交互模式实现了服务提供方和使用方之间的松耦合通信，提高了系统的灵活性和可扩展性。

2.3 服务连接方式

ara::com API提供了灵活的服务连接机制，主要通过以下方式实现：

1. 实例标识符（InstanceIdentifier）：

   • 用于唯一标识服务实例
   • 支持基于字符串的标识符格式
   • 可在应用程序间传递

2. 实例说明符（InstanceSpecifier）：

   • 扩展了实例标识符
   • 支持元模型标识符
   • 提供更丰富的实例描述信息

3. 服务发现：

   • 支持通过实例标识符查找服务
   • 支持服务属性匹配
   • 提供同步和异步查找选项

4. 通信组：

   • 支持服务的分组管理
   • 简化多服务场景下的通信管理
   • 提高服务管理的灵活性

---

3. 详细API说明

3.1 Proxy类

Proxy类是客户端应用程序访问远程服务的主要接口，提供了一系列用于服务查找、事件订阅、方法调用和字段访问的方法。

图3.1 ara::com API类结构

图3.1展示了ara::com API的核心类结构，其中Proxy类的主要组件和功能包括：

1. 服务查找：

   • FindService()：无参查找，返回所有可用服务实例
   • FindService(InstanceIdentifier)：通过实例标识符查找特定服务
   • FindService(InstanceSpecifier)：通过实例说明符查找服务

2. 事件订阅：

   • Subscribe()：订阅服务事件，返回EventSubscription对象
   • 支持事件缓冲和处理策略配置
   • 提供事件接收回调机制

3. 方法调用：

   • 同步/异步方法调用支持
   • 返回Future对象，支持结果异步处理
   • 支持方法调用取消操作

4. 字段访问：

   • FieldGet()：获取字段值，返回Future对象
   • FieldSet()：设置字段值，返回Future对象

5. 与其他组件的关系：

   • 使用FindServiceHandle管理服务查找过程
   • 返回ServiceHandleContainer存储服务句柄
   • 使用EventSubscription管理事件订阅
   • 使用Sample访问事件数据
   • 通过Future处理异步操作结果
   • 使用InstanceIdentifier和InstanceSpecifier标识服务

Proxy类采用了handle概念，不支持复制操作，仅支持移动语义，确保资源的安全管理。

3.2 Skeleton类

Skeleton类是服务提供方实现服务的框架，负责处理来自客户端的请求并提供相应的服务。

Skeleton类的主要组件和功能包括：

1. 服务提供：

   • ServiceSkeleton(InstanceIdentifier)：构造函数，需要提供实例标识符
   • OfferService()：开始提供服务
   • StopOfferService()：停止服务提供

2. 方法处理：

   • ProcessNextMethodCall()：处理下一个方法调用（轮询模式）
   • RegisterMethodHandler()：注册方法处理函数
   • RegisterFireAndForgetHandler()：注册单向方法处理函数

3. 事件发布：

   • RegisterEventHandler()：注册事件处理函数
   • FireEvent()：触发事件通知

4. 字段处理：

   • RegisterGetHandler()：注册字段获取处理函数
   • RegisterSetHandler()：注册字段设置处理函数

5. 状态更新：

   • Update()：更新服务状态，处理待处理的请求

Skeleton类支持两种处理模式：

• 轮询模式：通过ProcessNextMethodCall()主动处理请求
• 事件驱动模式：通过注册回调函数被动处理请求

3.3 实例标识符

实例标识符是ara::com API中用于标识服务实例的核心组件：

1. InstanceIdentifier：

   • 基本服务实例标识符
   • 支持从字符串构造
   • 提供字符串转换和比较操作

2. InstanceSpecifier：

   • 继承自InstanceIdentifier
   • 扩展了元模型标识符功能
   • 提供GetMetaModelIdentifiers()方法获取元模型标识符
   • 支持通过Create()方法创建实例

实例标识符在以下场景中使用：

• 服务查找和匹配
• 服务实例的唯一标识
• 在应用程序之间传递服务引用

3.4 通信组

通信组（CommunicationGroup）是ara::com API中用于服务分组管理的机制：

1. 基本功能：

   • 通过字符串标识符创建通信组
   • 支持特定服务类型的订阅和取消订阅
   • 提供布尔转换操作符用于状态检查

2. 主要用途：

   • 简化多服务场景下的通信管理
   • 支持基于组的事件订阅
   • 提高服务管理的灵活性
   • 支持远程连接和服务版本管理

通信组机制使开发人员能够更有效地管理多个相关服务，简化通信代码的复杂性。

---

4. ara::com API状态管理

4.1 服务生命周期

ara::com API中的服务实例具有明确定义的生命周期状态，由状态转换管理：

图4.1 ara::com API服务状态转换

图4.1展示了服务实例的状态转换，包括以下主要状态：

1. 代理端状态：

   • 未初始化：代理实例创建前的初始状态
   • 已创建：代理实例已创建但未连接服务
   • 正在查找：正在查找服务过程中
   • 已连接：成功连接到服务
   • 已断开：与服务的连接已断开
   • 错误状态：发生错误时的状态

2. 骨架端状态：

   • 未初始化：骨架实例创建前的初始状态
   • 已创建：骨架实例已创建但未提供服务
   • 服务提供中：正在提供服务
   • 错误状态：服务提供失败时的状态

3. 事件订阅状态：

   • 未订阅：初始状态，未进行订阅
   • 订阅请求中：正在建立订阅
   • 已订阅：订阅成功并活跃
   • 订阅错误：订阅过程中发生错误

4. 方法调用状态：

   • 未调用：初始状态，未发起调用
   • 正在处理：方法调用正在执行
   • 已完成：方法调用成功完成
   • 已取消：方法调用被取消
   • 调用失败：方法调用执行失败

这种明确的状态管理机制确保了服务通信的可靠性和可预测性，同时简化了错误处理和状态监控。

4.2 事件与方法状态管理

除了服务生命周期，ara::com API还提供了事件和方法调用的详细状态管理：

1. 事件状态管理：

   • 通过EventSubscription对象管理订阅状态
   • 提供CheckSubscriptionState()方法检查订阅状态
   • 支持SetReceiveHandler()设置事件接收回调
   • 提供布尔转换操作符判断订阅是否有效

2. 方法调用状态管理：

   • 通过Future对象管理异步方法调用
   • 提供HasValue()方法检查结果是否可用
   • 支持Value()方法获取结果值
   • 提供Cancel()方法取消正在进行的调用
   • 支持SetHandler()设置结果处理回调
   • 提供GetStatus()方法获取当前状态

这些状态管理机制使开发人员能够有效地处理异步通信场景，提高系统的响应性和可靠性。

---

5. 总结

ara::com API是AUTOSAR Adaptive Platform中的核心通信组件，为应用程序提供了标准化、灵活、高效的服务导向通信机制。

主要特点和优势：

1. 标准化接口：

   • 提供统一的服务通信接口
   • 降低应用程序与通信技术的耦合度
   • 支持不同通信技术的无缝替换

2. 多样化通信模式：

   • 支持事件、方法、字段和触发器等多种通信模式
   • 适应不同应用场景的需求
   • 提供同步和异步通信选项

3. 灵活的服务管理：

   • 支持动态服务发现和连接
   • 提供实例标识符机制支持服务实例管理
   • 通过通信组简化多服务场景

4. 完善的状态管理：

   • 明确定义服务生命周期状态
   • 提供详细的事件和方法状态管理
   • 简化错误处理和异常管理

5. 高性能设计：

   • 支持高效的数据传输
   • 优化的资源使用
   • 支持复杂分布式系统需求

ara::com API通过提供这些功能，极大地简化了AUTOSAR Adaptive Platform中应用程序的通信开发，提高了系统的可靠性、灵活性和可维护性，是现代汽车软件架构中不可或缺的组件。