AP AUTOSAR CM模块介绍

目录

一、概述

二、面向服务的通信

三、语言绑定和网络绑定

四、基于C++生成Proxies和Skeletons

五、静态配置和动态配置

六、服务契约版本控制

七、原始数据流接口

---

本文章主要来自于对相关规范的翻译解读

一、概述

 通信管理是AP中一个负责处理应用程序间通信的模块。目标是屏蔽底层的通信机制细节，使应用程序的开发人员能够专注于实现他们应用程序的具体功能，而不需要关注通信的具体实现。通信管理提供了一种抽象的方式来连接通信伙伴，使应用程序能够通信。

二、面向服务的通信

服务的概念意味着为应用程序提供了基础软件所未提供的功能。通信管理软件提供一种机制，用于机器内部和机器间互相通信进行服务的提供/消费。一个服务由Events、Methods和Fields的组合构成。通信伙伴之间的通信路径可以在设计时、启动时或运行时建立。

服务注册表是这个机制中的一个重要组成部分，它充当一个经纪人的角色，它负责管理服务的提供和消费，并帮助应用程序找到需要的服务以及与其他应用程序进行通信。

                                                               图1：面向服务的通信 

 当一个应用程序提供某项服务时，它会在服务注册表中登记该服务的相关信息。其他需要使用该服务的应用程序可以通过查询服务注册表来找到并获取该服务。这个过程就是常说的服务发现。

三、语言绑定和网络绑定

通信管理提供了标准化的API，用于将定义的服务呈现给应用程序实现者（上层，语言绑定），以及在网络上呈现服务数据的方式（下层，网络绑定）。这确保了源代码的可移植性，以及编译后的服务在平台的不同实现之间的兼容性。

语言绑定定义了如何将服务的方法、事件和字段通过目标编程语言的便利特性转换为直接可访问的标识符。性能和类型安全（在目标语言支持的范围内）是主要目标。因此，语言绑定通常是通过一个由服务接口定义提供输入的源代码生成器(比如vector的达芬奇)来实现的。

图2：语言绑定与网络绑定示例 

 网络绑定定义了如何将配置的服务的实际数据序列化并绑定到特定的网络上。网络绑定的实现可以依赖于通信管理配置，并且可以根据特定的服务定义进行配置，也可以直接生成序列化代码来完成。目前，通信管理支持SOME/IP、DDS、IPC（进程间通信）或任何其他自定义绑定，信号PDU（基于信号的网络绑定）和基于信号的静态网络绑定。此外，本地服务注册表也是网络绑定的一部分，用于管理本地服务的信息。

 需要注意的是，语言绑定和网络绑定之间的接口被视为通信管理软件内部的私有接口，目前没有规范性规定来定义这个接口。平台供应商可以自行定义这个接口，以便于在其平台实现中支持不同的语言绑定和网络绑定。

四、基于C++生成Proxies和Skeletons

C++语言绑定的上层接口提供了AUTOSAR元模型中定义的服务的面向对象映射。开发工具中的生成器具有一项功能，可以根据每个服务的字段、事件和方法，自动生成对应的C++类。而这些生成的类是类型安全的，也就是说它们在编译时就能够检测到类型不匹配的错误，从而提供了更加可靠和安全的编程环境。这样的功能可以帮助开发人员快速生成与服务相关的代码框架，减少手动编写代码的工作量，提高开发效率。

在服务实现方面，这些生成的类被称为服务提供者骨架。在客户端方面，它们被称为服务请求者代理。对于Methods，服务请求者代理提供了同步调用（阻塞调用者直到服务器返回结果）和异步调用（调用函数立即返回）的机制。调用者可以并行启动其他活动，并在服务器返回值可通过Core Type ara::core::Future的特殊特性获取时收到结果.

平台实现可以配置生成器，使其创建模拟类，以便在相应服务器尚不可用时轻松开发客户端功能。同样的机制也可以用于对客户端进行单元测试。尽管代理类可以直接被客户端使用，但C++绑定的服务提供者骨架只是抽象基类。服务实现应从生成的基类派生，并实现相应的功能。

ara::com的接口还可以为与安全相关的端到端保护通信提供代理和骨架。这些接口设计得与应用程序兼容，无论端到端保护是否打开都能够保证兼容性。

五、静态配置和动态配置

通信路径的配置可以在设计时、启动时或运行时进行，并因此被认为是静态或动态的。

1. 完全静态配置：服务器知道所有客户端，客户端也知道服务器。在这种情况下，完全不需要服务发现，因为所有的通信路径在配置时已经确定了。

2. 应用程序代码中没有发现：客户端知道服务器，但服务器不知道客户端。这种情况下，应用程序中唯一的动态通信模式是事件订阅。客户端能够订阅事件，但服务器无法主动识别和与客户端进行通信。

3. 应用程序中的完全服务发现：在配置时不知道任何通信路径。服务发现的 API 允许应用程序在运行时选择服务实例。这意味着应用程序可以根据需要动态选择要与之通信的服务实例。

这些不同的配置方式提供了在设计、启动和运行时进行灵活配置通信路径的选项。具体选择哪种方式取决于系统的需求和设计目标。

六、服务契约版本控制

在面向服务体系架构（SOA）中，服务的客户端和提供者依赖于一份契约，其中包括了服务接口行为的规范。在开发过程中，服务的接口行为可能会随时间而发生变化。因此，引入了服务契约版本控制来区分不同版本的服务。

AUTOSAR自适应平台支持对服务的设计阶段和部署阶段进行契约版本控制。此外，客户端的服务发现可以配置以支持向后兼容的版本。这意味着，如果提供的服务版本与客户端所需的服务版本向后兼容，客户端服务可以连接到不同的服务版本。

七、原始数据流接口

除了面向服务的通信（Service Oriented Communication），通信管理（Communication Management）还提供了一个独立的API，用于处理面向外部ECU（例如ADAS系统中的传感器）的原始二进制数据流。该API是静态的，并实现了客户端应用程序建立与服务器之间的通信通道以及服务器应用程序等待来自客户端的连接的功能。该API为客户端和服务器提供了销毁通信通道、读取和写入原始数据（字节流）的功能。通过应用部署信息，集成者可以配置原始数据流通道，其中包含网络端点信息和选定的协议等。目前，TCP/IP套接字被用作传输层，但在将来可以添加其他替代方案。原始数据流接口在命名空间ara::com::raw中可用。