【经纬恒润】车载通信与DDS标准解读系列(1):DDS-RPC

文章来源:https://blog.csdn.net/Hirain1234/article/details/134338471?spm=1001.2014.3001.5501

▎RPC & DDS-RPC

RPC:Remote Procedure Call,远程过程调用

远程过程调用是一种进程间通信,它允许计算机程序在另一个地址空间中执行子程序,就好像用别人的东西像用自己的一样,常用于分布式系统。

远程过程调用常用的通信方式为Request/Reply,即请求方发送Request向另一个地方请求执行某程序,被请求方执行相关操作后,返回Reply给请求方。

DDS广泛应用于分布式系统中是以数据为中心的发布/订阅,消息是单向从Publisher发送到Subscriber的,但是大型分布式系统通常不止是一种通信方式,例如Request/Reply这种远程调用的通信方式,使用多种中间件框架通常会带来更加复杂,高成本等问题。因此,为了实现可移植性和互操作性,需要在DDS基础上开发Request/Reply通信的标准机制——DDS-RPC。

DDS-RPC是OMG组织在2017年4月推出的DDS扩展协议,目前仅有v1.0版本。

▎DDS-RPC架构

如何利用DDS的基础模块实现RPC中Request/Reply通信模式呢?

简单来说,由于DDS是单向传输Topic的,满足双向的Request/Reply通信只需要将单向的两个Topic关联起来,标记发送Reply的消息是回复哪个Request的。

在DDS-RPC架构中(如下图),Client端和Server端都具备一个Data Writer和Data Reader。Client端利用Data Writer写Call Topic(Request),Server的Data Reader可以读取Call Topic并做处理,之后调用Server的Data Writer写Return Topic(Reply),并由Client的Data Reader读取。Call Topic在总线上发送时会携带GUID+SN,当Return Topic发送时,也会携带相对应的Call Topic的GUID+SN,表明此条报文回复的是哪条请求。

在这里插入图片描述

▎服务映射

根据上面的DDS-RPC架构描述,DDS可以把Request和Reply对应的Call Topic和Return Topic联系起来实现RPC,那么RPC的服务如何映射到这两个Topic上呢?

DDS-RPC中定义了两种映射方式:Basic Service Mapping和Enhanced Service Mapping,这两种映射方式都需要对Topic名称和Topic Types进行映射。

Topic名称

三种指定Topic名称方式:

  • 默认Topic名称:<topic_name>::=<interface_name>““<service_name>””[“Request”|“Reply”]|<user_def_alpha_num>
  • 注释的方式指定Request Topic和Reply Topic
  • 调用相关函数指定Topic名称

Topic Types

- Basic Service Mapping

在这里插入图片描述
在这里插入图片描述

  • Enhanced Service Mapping

在这里插入图片描述
在这里插入图片描述

▎服务发现

在DDSI-RTPS中,Reader和Writer需要先完成服务发现,才能进一步发送定义的Topic数据,DDS-RPC中的Call Topic和Return Topic对应的Reader和Writer也需要先完成服务实现,这个过程依赖RTPS对服务发现互操作性的要求。

Basic Service Mapping

依赖DDSI-RTPS内置Topic进行服务发现,可能会导致丢失Reply。

Enhanced Service Mapping

依赖DDSI-RTPS内置Topic进行服务发现,但是对Topic数据进行了扩展,能保证Client发送Request之前,Client的Reader能够与Server的Writer完成服务发现。

▎小结

DDS-RPC定义了在DDS基础上实现RPC通信的标准机制:用两个Topic分别对应RPC机制中的Request和Reply,并进行标记使得Reply与Request绑定,对于这两个Topic与RPC服务的映射也给出了要求。DDS-RPC结合了DDS的数据分发功能和RPC的远程调用功能,支持QoS设置,也满足了互操作性,丰富了DDS的使用场景。

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
经纬汽车CAN总线通信矩阵设计是指针对汽车CAN总线通信系统的设计方案。CAN总线通信矩阵是一个重要的组成部分,用于管理和控制CAN总线上多个节点之间的通信。 在设计CAN总线通信矩阵时,首先需要确定所需的节点数量和节点类型,包括ECU(电子控制单元)、传感器、执行器等。然后,需要根据系统的架构和硬件布局,将这些节点映射到合适的总线通道上。一般来说,CAN总线通信矩阵的设计应满足以下几个方面的考虑: 1. 数据传输速率:根据系统的需求和性能要求,确定CAN总线通信的速率。数据传输速率决定了节点之间的通信效率和实时性。 2. 通信优先级:不同的节点可能具有不同的通信优先级,例如,安全相关的节点需要具有较高的优先级。因此,在设计过程中,需要为节点分配适当的通信优先级,以便在通信冲突时能够进行正确的数据传输。 3. 总线冲突处理:CAN总线是多主控制的总线系统,可能存在多个节点同时发送数据的情况。因此,在设计总线通信矩阵时,需要考虑冲突检测和冲突处理机制,例如使用帧前缀或仲裁字段进行冲突检测,并采用仲裁算法(如基于标识符的仲裁)来解决冲突。 4. 容错和纠错能力:由于汽车CAN总线通信环境复杂,可能存在噪声、干扰等干扰因素。因此,在设计过程中,需要考虑容错和纠错能力,采用适当的错误检查和错误处理措施,例如使用CRC校验来检测传输错误,采用重发机制来纠正错误。 5. 系统稳定性和可扩展性:设计的总线通信矩阵应具备稳定性和可扩展性,能够满足汽车系统的需求,并且能够随着系统功能的增加而扩展。 总的来说,经纬汽车CAN总线通信矩阵的设计需要综合考虑系统需求、通信效率、通信优先级、冲突处理、容错能力和系统稳定性等方面。通过合理的设计,可以实现高效、可靠的汽车CAN总线通信系统。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值