前言

Hello！大家好！
欢迎来到《搞一下汽车电子》

本期为《搞一下 AP AUTOSAR 平台设计》第6期：通信管理

更多精彩内容欢迎订阅微信公众号 " 搞一下汽车电子小助手 "

一、概述

通信管理负责分布式实时嵌入式环境中应用程序之间的所有通信。

背后的概念是从实际机制中抽象出来，以查找和连接通信伙伴，以便应用程序软件的实现者可以专注于其应用程序的特定目的。

二、面向服务的通信

服务的概念是指提供给应用程序的功能超出了基本操作软件已经提供的功能。通信管理软件提供了为机器内通信以及机器间通信提供或使用此类服务的机制。

服务包含以下各项的组合

· Events

· Methods

· Fields

可以在设计时，启动时或运行时建立通信伙伴之间的通信路径。该机制的重要组成部分是服务注册中心，它充当中介实例，并且也是通信管理软件的一部分。

图1 面向服务的通信

提供服务的每个应用程序都在服务注册表中注册这些服务。要使用服务，Costumer应用程序需要通过查询服务注册表来找到请求的服务，此过程称为服务发现。

三、语言绑定和网络绑定

通信管理提供了标准化的手段，将定义的服务呈现给应用程序实现者（上层，语言绑定）以及网络上服务数据的相应表示（下层，网络绑定）。这确保了源代码的可移植性以及跨平台的不同实现的已编译服务的兼容性。

语言绑定定义如何通过使用目标编程语言的便捷功能将服务的Method，Event和Field转换为可直接访问的标识符。性能和类型安全性（就目标语言所支持的程度而言）是主要目标。因此，语言绑定通常由由Service Interface定义提供的源代码生成器实现。

图2 语言和网络绑定示例

网络绑定定义了如何将已配置服务的实际数据序列化并绑定到特定网络。可以基于通信管理配置（AUTOSAR元模型的接口定义），通过解释生成的服务特定配方或直接生成序列化代码本身来实现。当前，通信管理支持SOME / IP，DDS，IPC（进程间通信或任何其他自定义绑定）和Signal PDU（基于信号的网络绑定）。

本地服务注册表也是网络绑定的一部分。

注意：语言绑定和网络绑定之间的接口被视为Communication Management软件内部的专用接口。因此，定义此接口的规范目前不在范围内。但是，鼓励平台供应商为其软件独立定义这样的接口，以允许轻松实现除C ++之外的其他语言绑定以及其平台实现内的其他网络绑定。

四、C ++语言绑定生成的代理和骨架

C ++语言绑定的上层接口提供了AUTOSAR元模型的接口描述中定义的服务的面向对象的映射。

作为Communication Management软件开发工具一部分的生成器生成C ++类，这些类包含每个相应服务的Field，Event和Method的类型安全表示。

在服务实现方面，这些生成的类称为Service Provider Skeletons。在Client，它们称为Service Requester Proxies。

对于服务Methods，服务Requester Proxy提供了同步（阻止调用者直到服务器返回结果）和异步调用（被调用函数立即返回）的机制。当Server的返回值通过Core Type ara :: core :: future的特殊功能可用时，调用者可以并行启动其他活动并接收结果。参见后面的文章《AP AUTOSAR平台设计(17)——Core Types》。

可以配置平台实现，以便当相应的Server尚不可用时，生成器创建模型类，以便于Client功能的轻松开发。相同的机制也可以用于对Client进行单元测试。

Client可以直接使用proxy类，而C ++绑定的 Service Provider Skeleton 只是抽象基类。服务实现应从生成的基类派生并实现各自的功能。

ara :: com的接口还可以为安全相关的E2E受保护的通信提供Proxy和Skeleton 。这些接口的设计可确保无论E2E保护是打开还是关闭，都可以确保与应用程序的兼容性。

五、静态和动态配置

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

完全静态配置：

由于Server知道所有Client，而Client也知道Server，因此根本不需要发现Service。

没有通过应用程序代码发现:

Client知道Server，但是Server不知道Client。事件订阅是应用程序中唯一的动态通信模式。

在应用程序中发现全面服务:

在配置时，尚无通信路径。用于服务发现的API允许应用程序代码在运行时选择服务实例。

六、服务Contract Versioning

在SOA环境中， Client和Server的provider通过Service Interface和behavior连接在一起。

在开发服务期间，Service Interface或behavior可能会随时间而改变。因此，已引入服务Contract Versioning以区分服务的不同版本。 AUTOSAR自适应平台支持Contract 的Versioning设计，以用于服务的设计和部署阶段。

此外，Client的Service discovery可以配置为支持版本向后兼容。这意味着，如果Client Service与Client 的required service版本向后兼容，则它们可以连接到不同版本的ProvidedService版本。

七、原始数据流接口

除了面向服务的通信外，通信管理还提供了一个独立的API，用于处理朝向外部ECU（例如，ECU）的原始二进制数据流。 ADAS系统中的传感器。该API是静态的，并为Client实现建立通信通道，破坏通信通道以及在通信通道上读取和写入原始数据（字节流）的功能。

原始数据流通道可以由集成商通过应用包含例如以下内容的部署信息来配置。网络端点信息和所选协议。当前，TCP / IP套接字将用作传输层，但将来可以添加其他替代方案。 Raw Data Stream接口在名称空间ara :: com :: raw中可用。

本期分享就到这里~

联系我们

微信：shactiontech
邮箱：support@shactiontech.com

Adaptive AUTOSAR (AP) 平台设计(6)——通信管理相关推荐

Adaptive AUTOSAR (AP) 平台设计(9)——Persistency
前言 Hello!大家好! 欢迎来到<搞一下汽车电子> 本期为<搞一下 AP AUTOSAR 平台设计>第9期:Persistency 更多精彩内容欢迎订阅微信公众号 &quo ...
Adaptive AUTOSAR (AP) 平台设计(12)——UCM
前言 Hello!大家好! 欢迎来到<搞一下汽车电子> 本期为<搞一下 AP AUTOSAR 平台设计>第12期:UCM 更多精彩内容欢迎订阅微信公众号 " 搞一下汽 ...
Adaptive AUTOSAR (AP) 平台设计(8)——诊断
前言 Hello!大家好! 欢迎来到<搞一下汽车电子> 本期为<搞一下 AP AUTOSAR 平台设计>第8期:诊断更多精彩内容欢迎订阅微信公众号 " 搞一下汽车电 ...
Adaptive AUTOSAR (AP) 平台设计(2)——架构
前言 Hello!大家好! 欢迎来到<搞一下汽车电子> 本期为<搞一下 AP AUTOSAR 平台设计>第2期:架构更多精彩内容欢迎订阅微信公众号 " 搞一下汽车电 ...
Adaptive AUTOSAR (AP) 平台设计(3)——操作系统
前言 Hello!大家好! 欢迎来到<搞一下汽车电子> 本期为<搞一下 AP AUTOSAR 平台设计>第3期:操作系统更多精彩内容欢迎订阅微信公众号 " 搞一下汽 ...
ETAS Adaptive AUTOSAR 自适应平台示例视频教程
ETAS AP AUTOSAR自适应平台示例视频教程本系列文章旨在提供一个详细的操作指南,以构建ETAS AP AUTOSAR自适应平台的示例.实践练习的目标是加强AUTOSAR自适应平台中的理论概 ...
基于Matlab的模拟通信实验平台设计,【通信原理仿真实验】通信原理虚拟实验仿真平台的设计和实现_玛雅作文网...
作文「通信原理虚拟实验仿真平台的设计和实现」共有 4564 个字,其中有 2704 个汉字,1316 个英文,162 个数字,382 个标点符号.作者佚名,请您欣赏.玛雅作文网荟萃众多优秀学生作文,如 ...
【AutoSAR】【ComM】通信管理
目录一.ComM在Autosar架构里的位置二.ComM详述三.ComM与其他模块的关系四.ComM状态机
基于Adaptive AUTOSAR平台的OTA解决方案
随着软件定义汽车时代的来临,AUTOSAR技术正不断发展进步以适用汽车智能化,网联化等普遍需求,特别是Adaptive AUTOSAR技术的产生更是让这些需求落地成为了可能,再加上汽车OTA升级需求对 ...

Adaptive AUTOSAR (AP) 平台设计(6)——通信管理

前言

一、概述

二、面向服务的通信

三、语言绑定和网络绑定

四、C ++语言绑定生成的代理和骨架

五、静态和动态配置

六、服务Contract Versioning

七、原始数据流接口

本期分享就到这里~

联系我们

Adaptive AUTOSAR (AP) 平台设计(6)——通信管理相关推荐

最新文章

热门文章