Adaptive AUTOSAR 学习笔记 12 - 通信管理

最新推荐文章于 2024-02-20 23:32:26 发布

king110108

最新推荐文章于 2024-02-20 23:32:26 发布

阅读量426

点赞数

分类专栏： Adaptive Autosar 文章标签： AP Autosar 通信管理 CM

原文链接：https://www.cnblogs.com/tengzijian/p/15112262.html

版权

Adaptive Autosar 专栏收录该内容

15 篇文章 20 订阅

订阅专栏

本系列学习笔记基于 AUTOSAR Adaptive Platform 官方文档 R20-11 版本 AUTOSAR_EXP_PlatformDesign.pdf。

CM：Communication Management
SOME/IP：Scalable service-Oriented MiddlewarE over IP
DDS：Data Distribution Service
IPC：Inter-Process Communication
PDU：Protocol Data Unit
SOA：Service Oriented Architecture
AP：AUTOSAR Adaptive Platform

7 通信管理

7.1 概述

CM 负责分布式、实时、嵌入式环境下的应用间通信。CM 从实现中抽象出一套发现、连接通信对象的机制。这样应用开发者就能专注于应用软件本身的业务逻辑。

7.2 面向服务通信

Service 即提供给应用的、基础软件之外的功能。CM 提供了 Service 消费者/提供者的机制，支持机器内和跨机器通信。

服务由事件Event、方法Methods、字段Fields的组合构成。通信各方的通信路径可以在设计、启动或者运行时建立。Service Registry 是 CM 软件中的一个重要组件，起到中间人的作用。

每个提供服务的应用向 Service Registry 注册服务。服务的客户端应用先向 Service Registry 查找（find）服务，这一过程叫做服务发现（Service Discovery）。

7.3 语言绑定和网络绑定

CM 标准化了：

服务如何呈现给应用实现者（上层，语言绑定）
服务数据如何在网络中表示（下层，网络绑定）

以上两点保证了源码的可移植性和已编译的服务在不同平台实现的兼容性。

语言绑定定义了：如何将服务的 methods，events，fields 翻译成目标语言中可直接访问的标识符。性能和类型安全（只要目标语言支持）是首要目标。因此，语言绑定一般实现为以服务接口定义为输入的代码生成器。

类型安全：编译时验证类型

网络绑定定义了：服务数据如何序列化以及如何绑定到特定网络。可以实现为基于 CM 的配置（AUTOSAR 元模型接口定义）实现：或通过解释（生成的）服务 recipe，或直接生成序列化代码。

目前 CM 支持 SOME/IP，DDS，IPC 以及 Signal PDU（基于信号的网络绑定）。

本地 Service Registry 也是网络绑定的一部分。

注意：语言绑定和网络绑定之间的接口应当视为 CM 内部的 private 接口。尽管如此，平台供应商应当尽量为其软件定义独立的接口，以便在平台内实现除 C++ 之外的语言绑定。

7.4 C++ 语言绑定 Proxies 和 Skeletons 代码生成

C++ 语言绑定的上层接口提供了（定义在AUTOSAR 元模型接口描述中的）服务的面向对象映射。生成器是部署工具的一部分，用于为 CM 生成包含各个 Service 的 fields、events 和 methods 的类型安全表示的 C++ 类。

在服务实现侧，生成的类叫 Service Provider Skeletons；在客户端侧，叫 Service Requester Proxies。对于服务方法，服务请求代理提供同步（调用者阻塞，直到 Server 返回结果）和异步（被调函数立即返回）调用机制。调用者可以并行执行其他任务，当服务端返回结果时，通过 Core Type 的 ara::core::future 接收结果。平台可以配置生成器生成 mockup 类，当服务尚未开发完成时，便于开发客户端功能，也可用于客户端的单元测试。

客户端可以直接使用代理类，而 Service Provider Skeletons 只是抽象基类，服务实现需要继承自生成的抽象基类，实现相应的功能。

ara::com 接口可以为 proxies 和 skeletons 提供安全相关、受 E2E 保护的通信。这些接口旨在确保与应用程序的兼容性，无论是否开启 E2E 保护。

7.5 静态、动态配置

通信路径的配置可能发生在设计、启动或者运行时。因此配置可以是静态或者动态的：

全静态配置
完全不需要服务发现，服务端知道所有的客户端，客户端也知道服务端。
客户应用无需发现
客户端知道服务端，但服务端不知道客户端。应用中唯一的动态通信方式就是事件订阅。
全服务发现
配置时不知道通信路径。服务发现 API 允许应用代码在运行时选择服务实例。

7.6 服务合同版本控制

SOA（Service Oriented Architecture）环境下，服务的客户端和提供端依赖覆盖服务接口和行为的合同。服务开发过程中，服务的接口和行为会改变。因此，引入服务合同版本控制来区分不同版本的服务。AP 支持设计、部署阶段的服务合同版本控制。不仅如此，客户端的服务发现可配置为向后兼容，即如果服务版本向后兼容客户端请求的服务版本，客户端可以连接到一个不同于其请求版本的服务。