AUTOSAR_EXP_PlatformDesign - 07 Communication Management
【translated by sky8336, 2019.06.07, Shanghai】
7 Communication Management
7.1 Overview
通信管理负责分布式实时嵌入式环境中应用程序之间通信的各个方面。
其背后的概念是从实际的机制中抽象出来的,以便找到和连接通信伙伴,从而使应用程序软件的实现者能够专注于其应用程序的特定目的。
7.2 Service Oriented Communication
服务的概念意味着提供给应用程序的功能超出了基本操作软件已经提供的功能。管理软件提供了提供或使用这些服务的机制,用于机器内部通信和机器间通信。
服务由以下的组合组成:
- 事件(Events)
- 方法(Methods)
- 字段(Fields)
通信伙伴之间的通信路径可以在设计时、启动时或运行时建立。该机制的一个重要组成部分是服务注册中心(Service Registry),它充当代理实例,也是通信管理软件。
每个提供服务的应用程序都在服务注册表注册他们的服务。要使用一个服务,消费应用程序需要查询服务注册表来查找请求的服务,这个过程称为服务发现(Service Discovery)。
7.3 Language binding and Network binding
通信管理提供了标准化的方法,即如何将定义的服务呈现给应用程序实现人员(上层是语言绑定),以及在网络上服务的数据的各自表示形式(下层是网络绑定)。这确保了在跨平台的不同实现之间,源代码的可移植性和编译后的服务的兼容性。
语言绑定定义了如何使用目标编程语言的方便特性将服务的方法、事件和字段转换为可直接访问的标识符。性能和类型安全性(只要目标语言支持)是主要目标。因此,语言绑定通常由服务接口定义提供的源代码生成器实现。
网络绑定定义如何序列化已配置服务的实际数据并将其绑定到特定的网络。它可以基于通信管理配置(AUTOSAR元模型的接口定义)来实现,要么解释生成的特定于服务的配方,要么直接生成序列化代码本身。
本地服务注册表(Service Registry)也是网络绑定的一部分。
请注意:语言绑定与网络绑定之间的接口被认为是通信管理软件内部的私有接口。因此,定义此接口的规范规范目前超出了范围。尽管如此,平台供应商被鼓励为他们的软件独立定义这样一个接口,以方便实现除c++之外的其他语言绑定以及平台实现中的其他网络绑定。
7.4 Generated Proxies and Skeletons of C++ Language Binding(生成c++语言绑定的代理和框架)
c++语言绑定的上层接口提供了AUTOSAR元模型(meta model)接口描述中定义的服务的面向对象映射。
作为通信管理软件开发工具的一部分的生成器生成c++类,该类包含各个服务的字段、事件和方法的类型安全表示。
在服务实现一侧,这些生成的类被命名为服务提供者骨架。在客户端侧,它们被称为服务请求者代理。
对于服务方法,服务请求者代理提供同步(在服务器返回结果之前阻塞调用者)和异步调用(被调用的函数立即返回)的机制。调用者可以并行地启动其他活动,并在服务器的返回值通过核心类型ara:: Core::future的特殊特性可用时接收结果。见18.1章。
可以配置平台实现,使生成器创建模型类,以便在各自的服务器不可用时方便地开发客户机功能。同样的机制也可以用于对客户机进行单元测试。
虽然客户端可以直接使用代理类,但是用于c++绑定的服务提供者框架(Service Provider Skeletons)只是抽象的基类。一个服务实现应从生成的基类派生并实现相应的功能。
ara::com的接口还可以为saftey相关的E2E保护通信提供代理和框架。这些接口的设计确保了应用程序的兼容性独立于E2E保护是打开还是关闭。
7.5 Static and dynamic configuration
通信路径的配置可以发生在设计时、启动时或运行时,因此可以认为是静态的或动态的
- 全部静态配置(Full static configuration):
根本不需要服务发现,因为服务器知道所有客户机,客户机也知道服务器。
- 应用代码没有发现功能(No discovery by application code):
客户机知道服务器,但是服务器不知道客户机。事件订阅是应用程序中惟一的动态通信模式。
- 应用程序中的完整服务发现(Full service discovery in the application):
在配置时不知道通信路径。用于服务发现的API允许应用程序代码在运行时选择服务实例。
---------------
【end-2019.06.07】