CN118264729A - 多协议通信装置、方法、设备、介质及车辆 - Google Patents
多协议通信装置、方法、设备、介质及车辆 Download PDFInfo
- Publication number
- CN118264729A CN118264729A CN202211695560.4A CN202211695560A CN118264729A CN 118264729 A CN118264729 A CN 118264729A CN 202211695560 A CN202211695560 A CN 202211695560A CN 118264729 A CN118264729 A CN 118264729A
- Authority
- CN
- China
- Prior art keywords
- communication
- protocol
- control unit
- communication unit
- unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000004891 communication Methods 0.000 title claims abstract description 332
- 238000000034 method Methods 0.000 title claims abstract description 60
- 238000004590 computer program Methods 0.000 claims description 14
- 230000009977 dual effect Effects 0.000 claims description 9
- 238000004458 analytical method Methods 0.000 claims description 7
- 230000006870 function Effects 0.000 abstract description 11
- 238000006243 chemical reaction Methods 0.000 abstract description 8
- 238000010586 diagram Methods 0.000 description 13
- 238000005538 encapsulation Methods 0.000 description 8
- 230000008569 process Effects 0.000 description 7
- 238000005516 engineering process Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
Abstract
本公开涉及一种多协议通信装置、方法、设备、介质及车辆,其中方法包括:基于第一通信协议,接收第一通信单元发送的通信报文;通过所述支持双协议栈的协议层,将所述通信报文基于第二通信协议发送至第二通信单元。本公开通过在微控制单元中配置支持双协议栈的协议层,基于双协议栈功能实现系统级芯片与电子控制单元之间的直接通信,避免了不同协议之间相互转换,无需消耗大量的内存和计算资源,为跨协议通信提供了一种高效经济的解决方案。
Description
技术领域
本公开涉及车辆通信领域,尤其涉及一种多协议通信装置、方法、设备、介质及车辆。
背景技术
现有的智能汽车一般使用数据分发服务(Data Distribution Service,DDS)协议作为中间件作用于整车的通信系统,为整车的迭代开发提供便利性。
但是,DDS建立在TCP/IP协议栈的传输层协议之上,因而依赖于以太网的网络协议栈,这就使得DDS只能在以太网上使用。而车辆中的电子控制单元(Electronic ControlUnit,ECU)工作于CAN总线上,因此DDS不能直接运行在ECU之上。如果控制器需要和ECU之间建立通信,则需要实现协议互转(如CAN通信),增加了通信的复杂度,消耗大量的系统资源。
发明内容
为了解决上述技术问题,本公开提供了一种多协议通信方法、装置、设备及计算机可读存储介质,实现高效经济的跨协议通信。
第一方面,本公开实施例提供一种多协议通信装置,所述多协议通信装置包括第一通信单元、第二通信单元、微控制单元;
所述微控制单元中配置有支持双协议栈的协议层;
所述第一通信单元与所述微控制单元基于第一通信协议通信连接;
所述第二通信单元与所述微控制单元基于第二通信协议通信连接;其中所述第一通信协议与所述第二通信协议为数据分发服务协议与CAN/CANFD链路协议中的一种,且所述第一通信协议与所述第二通信协议不同。
第二方面,本公开实施例提供一种多协议通信方法,所述方法应用于微控制单元中,所述微控制单元中配置有支持双协议栈的协议层,所述方法包括:
基于第一通信协议,接收第一通信单元发送的通信报文;
通过支持双协议栈的协议层,将所述通信报文基于第二通信协议发送至第二通信单元。
在一些实施例中,在所述基于第一通信协议,接收第一通信单元发送的通信报文之前,所述方法还包括:
根据主题服务表完成服务发现,得到服务发现结果;
所述通过支持双协议栈的协议层,将所述通信报文基于第二通信协议发送至第二通信单元,包括:通过支持双协议栈的协议层,将所述通信报文基于第二通信协议发送至所述服务发现结果对应的第二通信单元。
在一些实施例能够,所述根据主题服务表完成服务发现,包括:
接收第二通信单元根据所述主题服务表发起的注册申请;
根据所述注册申请发布代理需求信息;
接收第一通信单元的代理请求,将所述代理请求发送至第二通信单元,完成服务发现。
在一些实施例中,所述通过支持双协议栈的协议层,将所述通信报文基于第二通信协议发送至所述服务发现结果对应的第二通信单元,包括:
根据所述服务发现结果,确定多个所述第二通信单元中的目标通信单元;
通过所述支持双协议栈的协议层,将所述通信报文基于第二通信协议发送至目标通信单元。
在一些实施例中,所述方法还包括:
对所述通信报文进行解析,得到解析结果;
基于所述解析结果,对所述主题服务表进行动态更新。
在一些实施例中,所述方法还包括:
基于所述服务发现结果,实现多个所述第一通信单元之间的通信和/或实现多个所述第二通信单元之间的通信,所述多个第一通信单元运行于不同的子网环境中,所述多个第二通信单元运行于不同的子网环境中。
第三方面,本公开实施例提供一种电子设备,包括:
存储器;
处理器;以及
计算机程序;
其中,所述计算机程序存储在所述存储器中,并被配置为由所述处理器执行以实现如第一方面所述的方法。
第四方面,本公开实施例提供一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行以实现第一方面所述的方法。
第五方面,本公开实施例提供一种车辆,包括如上所述的装置、电子设备或计算机可读存储介质。
本公开实施例提供的多协议通信装置、方法、设备、介质及车辆,通过在微控制单元中配置支持双协议栈的协议层,基于双协议栈功能实现系统级芯片与电子控制单元之间的直接通信,避免了不同协议之间相互转换,无需消耗大量的内存和计算资源,为跨协议通信提供了一种高效经济的解决方案。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本公开的实施例,并与说明书一起用于解释本公开的原理。
为了更清楚地说明本公开实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,对于本领域普通技术人员而言,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为本公开实施例提供的多协议通信方法流程图;
图2为本公开实施例提供的一种多协议通信装置的示意图;
图3为本公开另一实施例提供的多协议通信方法流程图;
图4为本公开另一实施例提供的一种应用场景的示意图;
图5为本公开实施例提供的LiminiDDS跨网络通信安全隧道示意图;
图6为本公开实施例提供的一种跨子网通信场景示意图;
图7为本公开实施例提供的多协议通信系统的结构示意图;
图8为本公开实施例提供的电子设备的结构示意图。
具体实施方式
为了能够更清楚地理解本公开的上述目的、特征和优点,下面将对本公开的方案进行进一步描述。需要说明的是,在不冲突的情况下,本公开的实施例及实施例中的特征可以相互组合。
在下面的描述中阐述了很多具体细节以便于充分理解本公开,但本公开还可以采用其他不同于在此描述的方式来实施;显然,说明书中的实施例只是本公开的一部分实施例,而不是全部的实施例。
本公开实施例提供了一种多协议通信方法,下面结合具体的实施例对该方法进行介绍。
图1为本公开实施例提供的多协议通信方法流程图。该方法可以应用于图2所示的一种多协议通信装置中,该多协议通信装置包括第一通信单元、第二通信单元、微控制单元(Micro Controller Unit、MCU);所述微控制单元中配置有支持双协议栈的协议层;所述第一通信单元与所述微控制单元基于第一通信协议通信连接;所述第二通信单元与所述微控制单元基于第二通信协议通信连接。其中,第一通信单元和第二通信单元可以是系统级芯片(System on Chip,SoC)、电子控制单元(Electronic Control Unit,ECU)中的一个,且第一通信单元与第二通信单元不同,其中,电子控制单元可以是一个或多个,每个电子控制单元分别负责控制车辆中的不同功能,本公开实施例以其中一个电子控制单元为例进行说明。在本公开实施例中,示例性地,将支持多协议通信装置的通信协议命名为LiminiDDS,该通信协议综合了DDS通信协议与CAN/CANFD链路协议,其中系统级芯片与微控制单元之间通过基于以太网(Ethernet)的DDS协议进行通信,微控制单元与电子控制单元之间使用基于CAN/CANFD链路的协议进行通信。在系统级芯片中,LiminiDDS协议层运行在传输层之上;在微控制单元中,配置支持双协议栈的LiminiDDS协议层,与系统级芯片相连的一端运行在以太网上,与电子控制器相连的一端(即与CAN/CANFD链路相连端)运行在数据链路层上,CAN/CANFD作为LiminiDDS的基础服务层,实现透明传输;在电子控制单元上,LiminiDDS协议层运行在数据链路层和应用层之间。其中,终端设备可以是车机或车载设备。可以理解的是,本公开实施例提供的多协议通信方法还可以应用在其他场景中,本公开实施例所提供的通信协议命名(LiminiDDS)也不应作为本公开的限定。
下面结合图2所示的多协议通信装置,对图1所示的多协议通信方法进行介绍,该方法包括的具体步骤如下:
S101、基于第一通信协议,接收第一通信单元发送的通信报文。
S102、通过所述支持双协议栈的协议层,将所述通信报文基于第二通信协议发送至第二通信单元。
第一通信单元与微控制单元通过第一通信协议进行通信,第二通信单元与微控制单元通过第二通信协议进行通信。其中微控制单元中预先配置有支持双协议栈的协议层,该协议层同时两种不同的通信协议,例如在本公开实施例中,该协议层支持第一通信协议以及第二通信协议。
在一些实施例中,例如在如图2所示的场景中,第一通信单元可以是如系统级芯片或是电子控制单元其中的一个,第二通信单元可以是系统级芯片或是电子控制单元中除第一通信单元中的另外一个。例如,当系统级芯片作为第一通信单元时,电子控制单元即为第二通信单元;当电子控制单元作为第一通信单元时,系统级芯片即为第二通信单元。需要说明的是,本公开实施例中的通信单元可以是任意的具有通信功能的系统组件,而并非专用于通信功能的系统组件。
当第一通信单元需要将通信报文发送至电子控制单元时,通过第一通信单元与微控制单元之间的协议层,基于第一通信协议将通信报文发送至微控制单元。微控制单元中的协议层支持双协议栈,与第一通信单元相连的一端使用第一通信协议,接收第一通信单元发送的通信报文,与第二通信单元相连的一端使用第二通信协议,将接收到的通信报文直接基于第二通信协议转发至第二通信单元,在此过程中无需进行第一协议与第二协议的转换。
在一些实施例中,例如在如图2所示的场景中,以系统级芯片作为第一通信单元,电子控制单元作为第二通信单元为例,系统级芯片与微控制单元之间使用基于以太网的DDS协议通信,微控制单元与电子控制单元之间使用基于CAN/CANFD链路之间的通信。系统级芯片向微控制单元发送通信报文时,通信报文从系统级芯片中的LiminiDDS协议层经由系统级芯片与微控制单元之间的以太网(Ethernet)链路到达微控制单元中LiminiDDS协议层与系统级芯片相连的一端,然后通过与CAN/CANFD链路相连端转发至电子控制单元。
本公开实施例通过配置有支持双协议栈的协议层的微控制单元基于第一通信协议,接收第一通信单元发送的通信报文;通过所述支持双协议栈的协议层,将所述通信报文基于第二通信协议发送至第二通信单元在微控制单元中配置支持双协议栈的协议层,基于双协议栈功能实现系统级芯片与电子控制单元之间的直接通信,避免了不同协议之间相互转换,无需消耗大量的内存和计算资源,为跨协议通信提供了一种高效经济的解决方案。
本公开实施例提出一种新的车载通信协议LiminiDDS,基于DDS的发布订阅特性,既支持DDS数据共享灵活性,也可以打通不同平台和系统之间的互操作性问题。
图3为本公开另一实施例提供的多协议通信方法流程图。该方法可以应用于图4所示的应用场景。如图4所示,车内的系统级芯片(Soc)之间、系统级芯片与微控制单元(MCU)之间使用基于以太网的DDS协议通信,微控制单元与多个电子控制单元(ECU1、ECU2…ECUn)之间分别使用基于CAN/CANFD链路的协议通信。
下面结合图4所示的应用场景,对图3所示的多协议通信方法进行介绍,该方法包括的具体步骤如下:
S301、根据主题服务表完成服务发现,得到服务发现结果。
具体的,接收第二通信单元根据所述主题服务表发起的注册申请;根据所述注册申请发布代理需求信息;接收第一通信单元的代理请求,将所述代理请求发送至第二通信单元,完成服务发现。
在系统中,通信单元可以对外发布主题,或是向其他通信单元订阅主题。发布主题是指当前通信单元采集到系统中的某些数据后对外公布,以使系统中其他需要这些数据的模块或单元能够根据需要获取相应的参数或数据;订阅主题是指当前通信单元根据自身所需要获取的数据,向能够提供相应数据的通信单元订阅相关的主题,订阅成功后,能够提供相应数据的通信单元在获取数据后将其发送至当前通信单元。
每个通信单元配置其对应的主题服务表,其中的表项为该通信单元对外发布的全部主题以及需要订阅的全部主题的相关信息。主题服务表的结构如下所示:
服务方式 | 名称 | source/destination |
订阅 | Topic1 | IP1(D) |
订阅 | Topic2 | IP2(D) |
订阅 | … | |
订阅 | Topicn | IP1(D) |
发布 | Topic1 | {IP1(S),IP2(S)} |
发布 | Topic2 | {IP1(S)} |
发布 | … | |
发布 | Topicn | {IP2(S),IP4(S)} |
如上表所示,主题服务表中的信息包括主题的服务方式(订阅或发布)、主题名称以及主题对应信息的来源或去向。除此之外,主题服务表中还可以包括各个主题的服务质量(Quality of Service,QOS)信息。QOS指一个网络能够利用各种基础技术,为指定的网络通信提供更好的服务能力,是网络的一种安全机制,是用来解决网络延迟和阻塞等问题的一种技术。
用户可以在设备的内存中,根据各个通信单元的业务需求为各个通信单元配置各自对应的主题服务表。该主题服务表支持在磁盘中实现持久化读写操作,在系统上电或唤醒时,各个通信单元读取磁盘文件并完成各自主题服务表的加载。同时,主题服务表还支持手动编辑。
在系统上电或唤醒后,第二通信单元根据主题服务表向微控制单元发起注册申请,微控制单元在接收到注册申请后,向第二通信单元发送确认信息,完成注册。然后微控制单元根据第二通信单元的注册申请,向外以组播的形式发布代理需求信息。第一通信单元根据代理需求信息,向微控制单元发起相应的代理请求,微控制单元接收到代理请求后转发给相应的第二通信单元,完成服务发现的全部过程,得到服务发现结果。
在一些实施例中,例如如图2所示的场景中,电子控制单元首先根据主题服务表向微控制单元发起注册申请,微控制单元收到电子控制单元的注册请求后进行确认,向电子控制单元发送确认信息完成注册。可选的,仅在系统初始化阶段进行上述注册过程,首次注册成功后即可将注册信息持久化,后续系统启动时即可直接加载注册信息,无需再次注册。
当电子控制单元的注册申请内容为“需要发布主题”,则由微控制单元根据电子控制单元的注册申请向外周期进行主题发布;如果电子控制单元的注册申请内容为“需要订阅主题”,则由微控制单元根据电子控制单元的注册申请向网络中其他通信单元(系统级芯片)发起代理需求信息。系统级芯片收到代理需求信息时,若满足代理条件,则确认代理需求信息并将代理请求返回至微控制单元,由微控制单元将代理请求发送至电子控制单元,完成服务发现。
S302、基于第一通信协议,接收第一通信单元发送的通信报文。
当第一通信单元需要将通信报文发送至电子控制单元时,通过第一通信单元与微控制单元之间的协议层,基于第一通信协议将通信报文发送至微控制单元。例如,以系统级芯片作为第一通信单元,系统级芯片与微控制单元之间使用基于以太网的DDS协议通信,系统级芯片向微控制单元发送通信报文时,通信报文从系统级芯片中的LiminiDDS协议层经由系统级芯片与微控制单元之间的以太网(Ethernet)链路到达微控制单元中LiminiDDS协议层与系统级芯片相连的一端。
S303、根据所述服务发现结果,确定多个所述第二通信单元中的目标通信单元。
接收到通信报文后,微控制单元基于通信报文的内容,确定其所对应的主题,根据服务发现结果确定该通信报文需要去到的地址,或是已经订阅该主题的目标通信单元。
在一些实施例中,可以对通信报文进行解析,得到解析结果;基于所述解析结果,对所述主题服务表进行动态更新。
在系统运行过程中可能会产生新的业务需求,而这些新增的业务需求并未被配置在主题服务表中。此时微控制单元可以基于对往来的通信报文的解析结果,自动学习一些频繁被发布或订阅的主题,并将这些主题更新至相应的主题服务表中,实现对于主题服务表的动态更新。
S304、通过所述支持双协议栈的协议层,将所述通信报文基于第二通信协议发送至目标通信单元。
当第一通信单元需要对多个第二通信单元中的目标通信单元进行通信时,将通信报文发送至微控制单元,微控制单元根据服务发现结果确定该通信报文对应的目标通信单元,并通过支持双协议栈的协议层将通信报文通过第二通信协议发送至目标通信单元,在此过程中无需进行第一协议与第二协议的转换。
在一些实施例中,以系统级芯片作为第一通信单元,电子控制单元作为第二通信单元为例,系统级芯片与微控制单元之间使用基于以太网的DDS协议通信,微控制单元与电子控制单元之间使用基于CAN/CANFD链路之间的通信。系统级芯片向微控制单元发送通信报文时,通信报文从系统级芯片中的LiminiDDS协议层经由系统级芯片与微控制单元之间的以太网(Ethernet)链路到达微控制单元中LiminiDDS协议层与系统级芯片相连的一端,然后通过与CAN/CANFD链路相连端转发至电子控制单元。
在一些实施例中,例如如图4所示的场景中,在系统级芯片需要发送数据时,微控制单元根据服务发现结果确定订阅该数据所对应主题的目标电子控制单元,通过双协议栈功能将数据发送至目标电子控制单元;当电子控制单元需要发送数据时,电子控制单元通过CAN/CANFD链路将数据发送给微控制单元,由微控制单元根据主题服务表确定订阅该数据所对应主题的系统级芯片,基于以太网完成数据传输。
本公开实施例通过根据主题服务表完成服务发现,得到服务发现结果;基于第一通信协议,接收第一通信单元发送的通信报文;根据所述服务发现结果,确定多个所述第二通信单元中的目标通信单元;通过所述支持双协议栈的协议层,将所述通信报文基于第二通信协议发送至目标通信单元,通过配置主题服务表完成通信单元之间的主题订阅以及发布,使得不同协议下的通信单元能够基于服务发现机制完成通信,同时支持在微控制单元中配置支持双协议栈的协议层,避免不同协议之间相互转换,节省大量的内存和计算资源。
在上述实施例的基础上,若上述多协议通信方法实现于车载设备中,还可以为车端至云端建立通信安全隧道。图5为本公开实施例提供的LiminiDDS跨网络通信安全隧道示意图。如图5所示,在车端至云端或工厂服务器之间基于虚拟专用网络(VPN)技术建立一条互联网安全协议(Internet Protocol Security,IPSec)隧道,将DDS服务发现组播报文进行通用路由封装(Generic Routing Encapsulation,GRE)将组播包转换为单播包,进一步再对GRE数据进行IPSec加密封装,形成一条安全隧道,从而实现车端和云端的LiminiDDS服务直接通信。
具体的,在DDS服务发现阶段,车端DDS服务发现组播报文,然后进入组播报文封装阶段,对组播报文进行GRE封装,对GRE封装后的组播报文再次进行加密封装,经由IPSec安全隧道发送至云端或工厂端服务器。云端或工厂端服务器接收到加密封装后的GRE封装后的组播报文之后,进行解封装操作,最终得到DDS服务发现组播报文,完成车端和云端DDS通信。
本公开实施例通过将通信报文进行协议封装实现跨网络通信,当车端和有云端通信的需求时,同上述实施例中所介绍的本地通信单元之间的通信类似,无需通过多链路多协议之间的转换,也无需考虑到跨网络通信的复杂场景即可实现跨网络通信。
在上述实施例的基础上,本公开提供的多协议通信方法还可以用于如图6所示的跨子网通信场景中。当存在多个运行在不同子网环境下的第一通信单元时,或是存在多个运行在多个不同子网环境下的第二通信单元时,各个第一通信单元之间或是各个第二通信单元仍可以基于上述实施例中的服务发现机制进行通信。以多个通信单元soc为例,如图6所示,soc1节点与soc2节点在子网192.168.1.0/24下通信,soc2节点与soc3节点在子网192.168.2.0/24下通信。如果Soc2节点需要发布主题,则可以直接同时向两个不同的网段分别发布。但若要实现soc1节点与soc3节点需要进行通信,则需要实现跨子网通信。例如,soc1节点发布主题topic1,soc3节点有订阅主题topic1的需求,在这种情况下,soc3节点向soc2节点发起注册申请,由soc2节点对注册申请进行确认,并代理soc3节点向soc1节点进行主题订阅。soc1节点收到订阅请求后进行确认,将代理信息发送回soc2节点,再由soc2节点将代理信息转发至soc3节点,完成服务发现。此后,soc1节点与soc3节点即可在不同子网环境(子网192.168.1.0/24、子网192.168.2.0/24)下实现跨子网通信。
以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解,本公开中所涉及的公开范围,并不限于上述技术特征的特定组合而成的技术方案,同时也应涵盖在不脱离上述公开构思的情况下,由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。
此外,虽然采用特定次序描绘了各操作,但是这不应当理解为要求这些操作以所示出的特定次序或以顺序次序执行来执行。在一定环境下,多任务和并行处理可能是有利的。同样地,虽然在上面论述中包含了若干具体实现细节,但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地,在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。
图7为本公开实施例提供的多协议通信系统的结构示意图。该多协议通信系统可以是如上实施例所述的终端设备,或者该多协议通信系统可以是该终端设备中的部件或组件。本公开实施例提供的多协议通信系统可以执行多协议通信方法实施例提供的处理流程,如图7所示,多协议通信系统70包括:接收模块71、发送模块72;接收模块71用于基于第一通信协议,接收第一通信单元发送的通信报文;发送模块72用于通过所述支持双协议栈的协议层,将所述通信报文基于第二通信协议发送至第二通信单元。
可选的,多协议通信系统70包括服务发现模块73,用于根据主题服务表完成服务发现。
可选的,服务发现模块73包括接收单元731、发布单元732、完成模块733;接收单元731用于接收第二通信单元根据所述主题服务表发起的注册申请;发布单元732用于根据所述注册申请发布代理需求信息;完成模块733用于接收第一通信单元的代理请求,将所述代理请求发送至第二通信单元,完成服务发现。
可选的,发送模块72包括确定单元721、发送单元722;确定单元721用于根据所述主题服务表,确定多个所述第二通信单元中的目标通信单元;发送单元722用于通过所述支持双协议栈的协议层,将所述通信报文基于第二通信协议发送至目标通信单元。
可选的,多协议通信系统70还包括更新模块74,用于对所述通信报文进行解析,得到解析结果;基于所述解析结果,对所述主题服务表进行动态更新。
可选的,服务发现模块73还用于基于所述服务发现结果,实现多个所述第一通信单元之间的通信和/或实现多个所述第二通信单元之间的通信,所述多个第一通信单元运行于不同的子网环境中,所述多个第二通信单元运行于不同的子网环境中。
图7所示实施例的多协议通信系统可用于执行上述方法实施例的技术方案,其实现原理和技术效果类似,此处不再赘述。
此外,本公开实施例还提供一种车辆,该车辆包括如上实施例所述的多协议通信装置。
图8为本公开实施例提供的电子设备的结构示意图。该电子设备可以是如上实施例所述的终端设备。本公开实施例提供的电子设备可以执行多协议通信方法实施例提供的处理流程,如图8所示,电子设备80包括:存储器81、处理器82、计算机程序和通讯接口83;其中,计算机程序存储在存储器81中,并被配置为由处理器82执行如上所述的多协议通信方法。
另外,本公开实施例还提供一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行以实现上述实施例所述的多协议通信方法。
此外,本公开实施例还提供了一种计算机程序产品,该计算机程序产品包括计算机程序或指令,该计算机程序或指令被处理器执行时实现如上所述的多协议通信方法。
可以以一种或多种程序设计语言或其组合来编写用于执行本公开的操作的计算机程序代码,上述程序设计语言包括但不限于面向对象的程序设计语言—诸如Java、Smalltalk、C++,还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中,远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机,或者,可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
附图中的流程图和框图,图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
需要说明的是,在本文中,诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上所述仅是本公开的具体实施方式,使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下,在其它实施例中实现。因此,本公开将不会被限制于本文所述的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
Claims (10)
1.一种多协议通信装置,其特征在于,所述多协议通信装置包括第一通信单元、第二通信单元、微控制单元;
所述微控制单元中配置有支持双协议栈的协议层;
所述第一通信单元与所述微控制单元基于第一通信协议通信连接;
所述第二通信单元与所述微控制单元基于第二通信协议通信连接;其中,所述第一通信协议与所述第二通信协议为数据分发服务协议与CAN/CANFD链路协议中的一种,且所述第一通信协议与所述第二通信协议不同。
2.一种多协议通信方法,其特征在于,所述方法应用于如权利要求1所述的多协议通信装置中,所述方法包括:
基于第一通信协议,接收第一通信单元发送的通信报文;
通过支持双协议栈的协议层,将所述通信报文基于第二通信协议发送至第二通信单元。
3.根据权利要求2所述的方法,其特征在于,在所述基于第一通信协议,接收第一通信单元发送的通信报文之前,所述方法还包括:
根据主题服务表完成服务发现,得到服务发现结果;
所述通过支持双协议栈的协议层,将所述通信报文基于第二通信协议发送至第二通信单元,包括:通过支持双协议栈的协议层,将所述通信报文基于第二通信协议发送至所述服务发现结果对应的第二通信单元。
4.根据权利要求4所述的方法,其特征在于,所述根据主题服务表完成服务发现,包括:
接收第二通信单元根据所述主题服务表发起的注册申请;
根据所述注册申请发布代理需求信息;
接收第一通信单元的代理请求,将所述代理请求发送至第二通信单元,完成服务发现。
5.根据权利要求3所述的方法,其特征在于,所述通过支持双协议栈的协议层,将所述通信报文基于第二通信协议发送至所述服务发现结果对应的第二通信单元,包括:
根据所述服务发现结果,确定多个所述第二通信单元中的目标通信单元;
通过所述支持双协议栈的协议层,将所述通信报文基于第二通信协议发送至目标通信单元。
6.根据权利要求3所述的方法,其特征在于,所述方法还包括:
对所述通信报文进行解析,得到解析结果;
基于所述解析结果,对所述主题服务表进行动态更新。
7.根据权利要求4所述的方法,其特征在于,所述方法还包括:
基于所述服务发现结果,实现多个所述第一通信单元之间的通信和/或实现多个所述第二通信单元之间的通信,所述多个第一通信单元运行于不同的子网环境中,所述多个第二通信单元运行于不同的子网环境中。
8.一种电子设备,其特征在于,包括:
存储器;
处理器;以及
计算机程序;
其中,所述计算机程序存储在所述存储器中,并被配置为由所述处理器执行以实现如权利要求2-7中任一项所述的方法。
9.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现如权利要求2-7中任一项所述的方法。
10.一种车辆,包括:如权利要求1所述的多协议通信装置;或者如权利要求8所述的电子设备;或者,如权利要求9所述的计算机可读存储介质。
Publications (1)
Publication Number | Publication Date |
---|---|
CN118264729A true CN118264729A (zh) | 2024-06-28 |
Family
ID=
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11765000B2 (en) | Method and system for virtual and physical network integration | |
US11201814B2 (en) | Configuration of networks using switch device access of remote server | |
US10142342B2 (en) | Authentication of client devices in networks | |
US9813291B2 (en) | Shortest path bridging (SPB) configuration of networks using client device access of remote | |
CN109474936B (zh) | 应用于多个lora网关之间的物联网通讯方法及系统 | |
EP3622405A1 (en) | Iot device connectivity, discovery, and networking | |
US10693668B2 (en) | Operation method of communication node in network | |
US20130176903A1 (en) | Methods and Apparatus for Establishing a Tunneled Direct Link Setup (TDLS) Session Between Devices in a Wireless Network | |
US9819574B2 (en) | Concerted multi-destination forwarding in a joint TRILL fabric and VXLAN/IP fabric data center | |
US9584411B2 (en) | Power save mechanism for low-power network devices | |
CN107645433B (zh) | 报文转发方法及装置 | |
US20150271016A1 (en) | Configuration of networks with server cluster device | |
JPH11196112A (ja) | マルチキャスト送信方法 | |
CN115189920A (zh) | 跨网络域通信方法和相关装置 | |
CN111010329A (zh) | 一种报文传输方法及装置 | |
US20120300776A1 (en) | Method for creating virtual link, communication network element, and ethernet network system | |
CN118264729A (zh) | 多协议通信装置、方法、设备、介质及车辆 | |
CN112953808B (zh) | Vpn数据传输方法、装置及服务器 | |
WO2021019860A1 (ja) | 中継装置、車両、通信方法および通信プログラム | |
WO2016180141A1 (zh) | 虚拟机状态管理方法及装置 | |
CN114221895A (zh) | 传输数据的方法、装置及网络设备 | |
CN113497767A (zh) | 传输数据的方法、装置、计算设备及存储介质 | |
CN104702708A (zh) | 获取地址解析协议信息的方法、设备、系统及网络虚拟化端点 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication |