CN115913809B - 数据分发通信方法、***、计算机设备及存储介质 - Google Patents
数据分发通信方法、***、计算机设备及存储介质 Download PDFInfo
- Publication number
- CN115913809B CN115913809B CN202211180655.2A CN202211180655A CN115913809B CN 115913809 B CN115913809 B CN 115913809B CN 202211180655 A CN202211180655 A CN 202211180655A CN 115913809 B CN115913809 B CN 115913809B
- Authority
- CN
- China
- Prior art keywords
- data
- communication
- control unit
- management message
- message communication
- 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.)
- Active
Links
- 238000004891 communication Methods 0.000 title claims abstract description 439
- 238000000034 method Methods 0.000 title claims abstract description 93
- 230000007246 mechanism Effects 0.000 claims abstract description 29
- 238000007781 pre-processing Methods 0.000 claims abstract description 17
- 230000003993 interaction Effects 0.000 claims description 45
- 230000006870 function Effects 0.000 claims description 17
- 238000012545 processing Methods 0.000 claims description 13
- 238000004590 computer program Methods 0.000 claims description 10
- 238000009960 carding Methods 0.000 claims description 9
- 230000036961 partial effect Effects 0.000 claims description 6
- 238000001914 filtration Methods 0.000 claims description 3
- 238000005516 engineering process Methods 0.000 abstract description 2
- 238000007726 management method Methods 0.000 description 139
- 238000013461 design Methods 0.000 description 21
- 230000004044 response Effects 0.000 description 10
- 238000010586 diagram Methods 0.000 description 7
- 238000000638 solvent extraction Methods 0.000 description 7
- 238000005538 encapsulation Methods 0.000 description 6
- 230000002829 reductive effect Effects 0.000 description 6
- 230000008569 process Effects 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 4
- 238000004458 analytical method Methods 0.000 description 2
- 238000003491 array Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000000670 limiting effect Effects 0.000 description 2
- 238000013468 resource allocation Methods 0.000 description 2
- 238000004088 simulation Methods 0.000 description 2
- 206010063385 Intellectualisation Diseases 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 230000004083 survival effect Effects 0.000 description 1
Landscapes
- Computer And Data Communications (AREA)
Abstract
本申请涉及车载技术领域，特别涉及一种数据分发通信方法、***、计算机设备及存储介质，其中，方法包括：根据预设通信机制，确定微控制单元所能承载的管理消息通信方式；利用微控制单元中的数据对管理消息通信方式进行划分；对数据进行预处理；利用划分后的管理消息通信方式对处理后的数据进行数据分发，以利用分发后的数据进行通信。由此，解决了相关技术中MCU的运存资源有限无法搭载DDS协议栈，导致了在MCU中不能使用大量的管理消息通信方式，且仅在MPU上部署DDS协议栈，会导致整车通信架构复杂，通信延时高等问题。
Description
技术领域
本申请涉及车载技术领域，特别涉及一种数据分发通信方法、***、计算机设备及存储介质。
背景技术
随着智能化、网联化的快速发展，汽车网络上承载的交互数据越来越多，使用传统的控制器局域网络(Controller Area Network，CAN)和局域互联网络(LocalInterconnect Network，LIN)来传输这些数据已远远不足，车载以太网的加入使车载网络架构发生了很大的变化，同时面向服务架构(service-oriented architecture，SOA)设计使***设计更加去中心化，因此采用通信中间件去解耦上层设计与底层传输的问题至关重要。在车载领域先后出现了一些通信中间件协议，数据分发服务(Data DistributionService，DDS)作为通信中间件越来越受主机厂青睐。现阶段各主机厂已逐步使用DDS作为车载通信中间件来解耦控制器应用层和底层传输的联系，推进SOA架构设计，完成整车以太网数据的传输。
但是，在微控制单元(Micro Control Unit，MCU)上使用DDS协议栈仍有很多局限性，如MCU中有限的运存资源导致了在MCU中不能使用大量的管理消息通信方式(topic)，使大部分主机厂无法或无意愿在MCU上部署DDS协议栈，而仅在MPU(Microprocessor Unit，微处理器)上部署DDS协议栈，会导致整车通信架构复杂，通信延时高。
如何在MCU上部署DDS协议栈实现能够使用大量的管理消息通信方式以进行整车通信是亟需解决的问题。
发明内容
本申请提供一种数据分发通信方法、***、计算机设备及存储介质，以解决相关技术中MCU的运存资源有限无法搭载DDS协议栈，导致了在MCU中不能使用大量的管理消息通信方式，且仅在MPU上部署DDS协议栈，会导致整车通信架构复杂，通信延时高等问题。
本申请第一方面实施例提供一种数据分发通信方法，应用于微控制单元，包括以下步骤：根据预设通信机制，确定所述微控制单元所能承载的管理消息通信方式；利用所述微控制单元中的数据对所述管理消息通信方式进行划分；对所述数据进行预处理；利用划分后的管理消息通信方式对所述处理后的数据进行数据分发，以利用分发后的数据进行通信。
根据上述技术手段，本申请实施例可以根据预设通信机制确定微控制单元所能承载的管理消息通信方式，利用微控制单元中的数据对管理消息通信方式进行划分，对数据进行预处理，利用划分后的管理消息通信方式对处理后的数据进行数据分发，以利用分发后的数据进行通信，可以在微控制单元中使用大量的管理消息通信方式(topic)，使整车中的以太网节点在微控制单元芯片能够正常运行数据分发服务协议栈，完成以太网通信。
可选地，在本申请的一个实施例中，在所述根据预设通信机制，确定所述微控制单元所能承载的管理消息通信方式之前，包括：制定客户端控制单元的所述管理消息通信方式的名称和标识；在域参与者发现阶段，将需要通信的实体放在一个域中，使得所述通信的实体相互之间完成简单参与者发现协议；在端点发现阶段，根据所述管理消息通信方式的名称和标识，建立服务端控制单元与所述客户端控制单元的管理消息通信方式的通信连接，以完成简单端点发现协议；根据所述简单参与者发现协议和所述简单断点发现协议建立所述预设通信机制。
根据上述技术手段，本申请实施例可以通过完成简单参与者发现协议和简单端点发现协议，建立预设通信机制，从而在MCU芯片与MPU芯片中可以承载的topic数量是不一样的情况下，完成两者之间的正常通信。
可选地，在本申请的一个实施例中，所述在端点发现阶段，根据所述管理消息通信方式的名称和标识，建立服务端控制单元与所述客户端控制单元的管理消息通信方式的通信连接包括：在服务端控制单元收到客户端控制单元的远程过程调用协议请求时，根据所述服务端控制单元的方法哈希标识过滤所述远程过程调用协议请求，得到与所述服务器控制单元相符的远程过程调用协议请求；在所述客户端控制单元收到服务端控制单元的远程过程调用协议回复时，根据所述客户端控制单元的全局唯一标识符过滤所述远程过程调用协议回复，得到与所述客户端控制单元相符的远程过程调用协议请求，以建立所述服务端控制单元与所述客户端控制单元的管理消息通信方式的通信连接。
根据上述技术手段，本申请实施例可以在服务器端控制单元收到客户端控制单元的调用协议请求时，根据方法哈希标识过滤不属于自己的请求，客户端控制单元收到服务端控制单元的调用协议回复时，根据全局唯一标识符过滤掉不属于自己的应答，从而建立客户端和服务器端的通信连接，方便加载并显示数据，并可以根据需求筛选数据，减少数据量。
可选地，在本申请的一个实施例中，所述对所述数据进行预处理包括：根据所述微控制单元中的数据通信通道，进行不同域之间的数据通信；根据所述微控制单元中的数据交互通道，进行不同通信协议之间的数据交互；对经过所述数据通信和所述数据交互后的数据进行冗余处理，得到所述处理后的数据。
根据上述技术手段，本申请实施例可以通过搭建数据通信通道和数据交互通道，进行不同域之间的数据通信及不同通信协议之间的数据交互，并经过冗余处理得到处理后的数据，可以实现在微控制单元中随意使用服务质量策略(Quality ofService，QoS)，以保障数据进行实时、高效、灵活地分发，可满足各种分布式实时通信应用需求。
可选地，在本申请的一个实施例中，在所述根据所述微控制单元中的数据通信通道，进行不同域之间的数据通信之前，包括：制定域之间通信的第一路由表；根据所述第一路由表建立不同域的通信的实体之间的通信连接，以创建所述数据通信通道。
根据上述技术手段，本申请实施例可以通过制定域之间通信的路由表，建立通信连接，使不同域之间的实体能够建立通信。
可选地，在本申请的一个实施例中，在根据所述微控制单元中的数据交互通道，进行不同通信协议之间的数据交互之前包括：制定不同通信协议之间通信的第二路由表；根据所述第二路由表建立不同通信协议之间的通信连接，以创建所述数据交互通道。
根据上述技术手段，本申请实施例可以通过制定不同通信协议之间的路由表，从而根据路由表的内容过滤无关CAN报文，仅接收和转发路由表中的CAN报文。
可选地，在本申请的一个实施例中，所述利用所述微控制单元中的数据对所述管理消息通信方式进行划分包括：确定所述微控制单元芯片承载的所述管理消息通信方式的数量的最大值；梳理所述微控制单元芯片中承载数据的数据类型；按照预设原则对所述管理消息通信方式进行划分后，判断根据所述数据类型对所述管理消息通信方式进行划分后的所述管理消息通信方式的数量是否达到所述最大值，所述预设原则为所述数据类型与所述管理消息通信方式一一对应进行配置；当划分后的所述管理消息通信方式的数量未达到所述最大值且预留了部分数量的管理消息通信方式用于后期功能扩展时，根据所述数据类型对所述管理消息通信方式进行划分。
根据上述技术手段，本申请实施例可以对微控制单元芯片中承载数据的数据类型与管理消息通信方式一一对应划分，便于数据区分和解析。
可选地，在本申请的一个实施例中，所述利用所述微控制单元中的数据对所述管理消息通信方式进行划分包括：当划分后的所述管理消息通信方式的数量未达到所述最大值，或划分后的所述管理消息通信方式的数量达到所述最大值而未预留部分数量的管理消息通信方式用于后期功能扩展时，判断所述管理消息通信方式是否满足面向服务架构的服务定义；若所述管理消息通信方式满足所述面向服务架构的服务定义，按照所述面向服务架构的特点对所述微控制芯片的数据进行分类，将同一类型的所述数据划分到一个管理消息通信方式中，并对每个数据进行标记。
根据上述技术手段，本申请实施例可以根据服务定义特点，可将数据按照请求、响应、通知进行分类，划分到3个topic(管理消息通信方式)中，按照服务的特点对数据进行分类，减少topic使用的个数，可以降低通信延时。且在此情况下，由于一个topic中包含了大量的数据，通信双方需要对不同的数据进行标记，便于数据区分和解析。
可选地，在本申请的一个实施例中，所述利用所述微控制单元中的数据对所述管理消息通信方式进行划分包括：若所述管理消息通信方式满足所述面向服务架构的服务定义，按照功能安全等级对所述数据进行分类，将属于同一功能安全等级的所述数据划分到一个管理消息通信方式中，并对每个数据进行标记。
根据上述技术手段，本申请实施例可以按照功能安全等级对数据进行分类，减少topic使用的个数，可以降低通信延时。且在此情况下，由于一个topic中包含了大量的数据，通信双方需要对不同的数据进行标记，便于数据区分和解析。
本申请第二方面实施例提供一种数据分发通信***，包括：确定模块，用于根据预设通信机制，确定所述微控制单元所能承载的管理消息通信方式；划分模块，用于利用所述微控制单元中的数据对所述管理消息通信方式进行划分；预处理模块，用于对所述数据进行预处理；数据分发通信模块，用于利用所述处理后的数据对划分后的管理消息通信方式进行数据分发，以利用分发后的数据进行通信。
可选地，在本申请的一个实施例中，包括：第一制定模块，用于在所述根据预设通信机制，确定所述微控制单元所能承载的管理消息通信方式之前，制定客户端控制单元的所述管理消息通信方式的名称和标识；处理模块，用于在域参与者发现阶段，将需要通信的实体放在一个域中，使得所述通信的实体相互之间完成简单参与者发现协议；第一建立模块，用于在端点发现阶段，根据所述管理消息通信方式的名称和标识，建立服务端控制单元与所述客户端控制单元的管理消息通信方式的通信连接，以完成简单端点发现协议；第二建立模块，用于根据所述简单参与者发现协议和所述简单断点发现协议建立所述预设通信机制。
可选地，在本申请的一个实施例中，所述第一建立模块，进一步用于在服务端控制单元收到客户端控制单元的远程过程调用协议请求时，根据所述服务端控制单元的方法哈希标识过滤所述远程过程调用协议请求，得到与所述服务器控制单元相符的远程过程调用协议请求；
在所述客户端控制单元收到服务端控制单元的远程过程调用协议回复时，根据所述客户端控制单元的全局唯一标识符过滤所述远程过程调用协议回复，得到与所述客户端控制单元相符的远程过程调用协议请求，以建立所述服务端控制单元与所述客户端控制单元的管理消息通信方式的通信连接。
可选地，在本申请的一个实施例中，所述预处理模块，进一步用于根据所述微控制单元中的数据通信通道，进行不同域之间的数据通信；根据所述微控制单元中的数据交互通道，进行不同通信协议之间的数据交互；对经过所述数据通信和所述数据交互后的数据进行冗余处理，得到所述处理后的数据。
可选地，在本申请的一个实施例中，还包括：第二制定模块，用于在所述根据所述微控制单元中的数据通信通道，进行不同域之间的数据通信之前，制定域之间通信的第一路由表；第三建立模块，用于根据所述第一路由表建立不同域的通信的实体之间的通信连接，以创建所述数据通信通道。
可选地，在本申请的一个实施例中，还包括：第三制定模块，用于在根据所述微控制单元中的数据交互通道，进行不同通信协议之间的数据交互之前，制定不同通信协议之间通信的第二路由表；第四建立模块，用于根据所述第二路由表建立不同通信协议之间的通信连接，以创建所述数据交互通道。
可选地，在本申请的一个实施例中，所述划分模块，进一步用于确定所述微控制单元芯片承载的所述管理消息通信方式的数量的最大值；梳理所述微控制单元芯片中承载数据的数据类型；按照预设原则对所述管理消息通信方式进行划分后，判断根据所述数据类型对所述管理消息通信方式进行划分后的所述管理消息通信方式的数量是否达到所述最大值，所述预设原则为所述数据类型与所述管理消息通信方式一一对应进行配置；当划分后的所述管理消息通信方式的数量未达到所述最大值且预留了部分数量的管理消息通信方式用于后期功能扩展时，根据所述数据类型对所述管理消息通信方式进行划分。
可选地，在本申请的一个实施例中，所述划分模块，进一步用于当划分后的所述管理消息通信方式的数量未达到所述最大值，或划分后的所述管理消息通信方式的数量达到所述最大值而未预留部分数量的管理消息通信方式用于后期功能扩展时，判断所述管理消息通信方式是否满足面向服务架构的服务定义；若所述管理消息通信方式满足所述面向服务架构的服务定义，按照所述面向服务架构的特点对所述微控制芯片的数据进行分类，将同一类型的所述数据划分到一个管理消息通信方式中，并对每个数据进行标记。
可选地，在本申请的一个实施例中，所述划分模块，进一步用于若所述管理消息通信方式满足所述面向服务架构的服务定义，按照功能安全等级对所述数据进行分类，将属于同一功能安全等级的所述数据划分到一个管理消息通信方式中，并对每个数据进行标记。
本申请第三方面实施例提供一种计算机设备，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现如上述实施例所述的数据分发通信方法。
本申请第四方面实施例提供一种有计算机程序的非易失性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行，以用于实现如上述实施例所述的数据分发通信方法。
由此，本申请至少具有如下有益效果：
1、本申请实施例可以根据预设通信机制确定微控制单元所能承载的管理消息通信方式，利用微控制单元中的数据对管理消息通信方式进行划分，对数据进行预处理，利用划分后的管理消息通信方式对处理后的数据进行数据分发，以利用分发后的数据进行通信，可以在微控制单元中使用大量的管理消息通信方式(topic)，使整车中的以太网节点在微控制单元芯片能够正常运行数据分发服务协议栈，完成以太网通信。
2、本申请实施例可以通过完成简单参与者发现协议和简单端点发现协议，建立预设通信机制，从而在MCU芯片与MPU芯片中可以承载的topic数量是不一样的情况下，完成两者之间的正常通信。
3、本申请实施例可以在服务器端控制单元收到客户端控制单元的调用协议请求时，根据方法哈希标识过滤不属于自己的请求，客户端控制单元收到服务端控制单元的调用协议回复时，根据全局唯一标识符过滤掉不属于自己的应答，从而建立客户端和服务器端的通信连接，方便加载并显示数据，并可以根据需求筛选数据，减少数据量。
4、本申请实施例可以通过搭建数据通信通道和数据交互通道，进行不同域之间的数据通信及不同通信协议之间的数据交互，并经过冗余处理得到处理后的数据，可以实现在微控制单元中随意使用服务质量策略(Quality ofService，QoS)，以保障数据进行实时、高效、灵活地分发，可满足各种分布式实时通信应用需求。
5、本申请实施例可以通过制定域之间通信的路由表，建立通信连接，使不同域之间的实体能够建立通信。
6、本申请实施例可以通过制定不同通信协议之间的路由表，从而根据路由表的内容过滤无关CAN报文，仅接收和转发路由表中的CAN报文。
7、本申请实施例可以对微控制单元芯片中承载数据的数据类型与管理消息通信方式一一对应划分，便于数据区分和解析。
8、本申请实施例可以根据服务定义特点，可将数据按照请求、响应、通知进行分类，划分到3个topic(管理消息通信方式)中，按照服务的特点对数据进行分类，减少topic使用的个数，可以降低通信延时。且在此情况下，由于一个topic中包含了大量的数据，通信双方需要对不同的数据进行标记，便于数据区分和解析。
9、本申请实施例可以按照功能安全等级对数据进行分类，减少topic使用的个数，可以降低通信延时。且在此情况下，由于一个topic中包含了大量的数据，通信双方需要对不同的数据进行标记，便于数据区分和解析。
本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。
附图说明
本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
图1为根据本申请实施例提供的一种数据分发通信方法的流程图；
图2为根据本申请实施例提供的简单的DDS通信***结构框图；
图3为根据本申请实施例提供的一种MCU芯片中topic划分设计的流程图；
图4为根据本申请实施例提供的一种MCU芯片中搭建不同domain之间数据通信通道的流程图；
图5为根据本申请实施例提供的一种MCU芯片中搭建CAN与DDS不同通信协议之间的数据交互通道的流程图；
图6为根据本申请实施例提供的数据封装格式示意图；
图7为根据本申请实施例提供的一种MCU芯片中完成基于DDS的以太网通信冗余设计的流程图；
图8为根据本申请实施例提供的一种MCU芯片中topic不对等通信机制设计的流程图；
图9为根据本申请实施例提供的一种数据分发通信***的方框示意图；
图10为根据本申请实施例提供的计算机设备的结构示意图。
附图标记说明：确定模块-100、划分模块-200、预处理模块-300、数据分发通信模块-400、存储器-1001、处理器-1002、通信接口-1003。
具体实施方式
下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。
下面参考附图描述本申请实施例的数据分发通信方法、***、计算机设备及存储介质。针对上述背景技术中提到的问题，本申请提供了一种数据分发通信方法，应用于微控制单元，在该方法中，根据预设通信机制确定微控制单元所能承载的管理消息通信方式，利用微控制单元中的数据对管理消息通信方式进行划分，对数据进行预处理，利用划分后的管理消息通信方式对处理后的数据进行数据分发，以利用分发后的数据进行通信，可以在微控制单元中使用大量的管理消息通信方式(topic)，使整车中的以太网节点在微控制单元芯片能够正常运行数据分发服务协议栈，完成以太网通信。由此，解决了相关技术中MCU的运存资源有限无法搭载DDS协议栈，导致了在MCU中不能使用大量的管理消息通信方式，且仅在MPU上部署DDS协议栈，会导致整车通信架构复杂，通信延时高等问题。
具体而言，图1为本申请实施例所提供的一种数据分发通信方法的流程示意图。
为解决在MCU上部署DDS协议栈的问题，本申请实施例提供一套基于MCU芯片上DDS通信***设计方法，使整车中的以太网节点不管是MCU芯片，还是MPU芯片都能正常运行DDS协议栈，完成以太网通信。如图2所示，通过一种简单的***结构示意图用于显示本申请实施例的一个通信***结构框图，包括CAN节点、以太网节点，对此不做具体限定，后期设计可在此基础上进行扩展。在本申请实施例的通信***中，S201代表CAN节点，S202代表该ECU既有CAN通信能力，又有以太网通信能力，其中S201和S202通过CAN网段连接，按照传统的CAN通信方式进行数据交互；S202和S203中通过以太网连接，且均采用DDS协议栈作为通信中间件。
如图1所示，该数据分发通信方法包括以下步骤：
在步骤S101中，根据预设通信机制，确定微控制单元所能承载的管理消息通信方式。
DDS数据分发服务，是新一代分布式实时通信中间件协议，采用发布/订阅体系架构，强调以数据为中心，提供丰富的QoS服务质量策略，以保障数据进行实时、高效、灵活地分发，可满足各种分布式实时通信应用需求。在通信双方状态确认方面，DDS协议栈中的各个实体具有自动保活和声明存活的机制，本申请实施例可以根据预设通信机制，确定微控制单元所能承载的管理消息通信方式，使通信双方可以实时知晓对端的生命周期和存活性，及时做出处理。
在步骤S102中，利用微控制单元中的数据对管理消息通信方式进行划分。
在本申请的一个实施例中，利用微控制单元中的数据对管理消息通信方式进行划分包括：确定微控制单元芯片承载的管理消息通信方式的数量的最大值；梳理微控制单元芯片中承载数据的数据类型；按照预设原则对管理消息通信方式进行划分后，判断根据数据类型对管理消息通信方式进行划分后的管理消息通信方式的数量是否达到最大值，预设原则为数据类型与管理消息通信方式一一对应进行配置；当划分后的管理消息通信方式的数量未达到最大值且预留了部分数量的管理消息通信方式用于后期功能扩展时，根据数据类型对管理消息通信方式进行划分。
其中，预设原则可以为一种数据类型或一类数据分配一个topic。
为了便于数据区分和解析，本申请实施例可以根据MCU芯片中的资源分配情况，合理的计算部署DDS协议栈、DDS各个实体占用的资源情况，通过计算或仿真得到在MCU芯片中可用的资源情况下，MCU芯片可承载的最大topic数量，一个topic承载一种数据类型的通信数据，根据整车的服务或功能设计，梳理需要通过DDS协议栈传输的数据类型；按照一种数据类型或一类数据分配一个topic的原则进行计算，判断是否满足MCU芯片可承载的最大topic梳理；如果数据和topic可以匹配，则可以按照要求将一种数据类型放入一个topic中；当现阶段设计的数据不满足要求且预留了部分数量的topic用于后期功能扩展时，本申请实施例可以判断是否满足MCU芯片可承载的最大topic梳理，并根据数据类型对MCU芯片中topic进行划分。
在本申请的一个实施例中，利用微控制单元中的数据对管理消息通信方式进行划分包括：当划分后的管理消息通信方式的数量未达到最大值，或划分后的管理消息通信方式的数量达到最大值而未预留部分数量的管理消息通信方式用于后期功能扩展时，判断管理消息通信方式是否满足面向服务架构的服务定义；若管理消息通信方式满足面向服务架构的服务定义，按照面向服务架构的特点对微控制芯片的数据进行分类，将同一类型的数据划分到一个管理消息通信方式中，并对每个数据进行标记。
具体而言，当划分后的topic数量未达到最大值或未预留部分topic数量用于后期功能扩展时，由于现阶段汽车行业的通信都是基于SOA(Service-Oriented Architecture，面向服务的架构)架构定义的服务，因此，本申请实施例可以通过判断topic是否满足面向服务架构的服务定义，若满足，本申请实施例可以按照服务的特点将数据按照请求、响应、通知进行分类，划分到3个topic中，减少topic使用的个数，可以降低通信延时。且在此情况下，由于一个topic中包含了大量的数据，通信双方需要对不同的数据进行标记，便于数据区分和解析。
在本申请的一个实施例中，利用微控制单元中的数据对管理消息通信方式进行划分包括：若管理消息通信方式不满足面向服务架构的服务定义，按照功能安全等级对数据进行分类，将属于同一功能安全等级的数据划分到一个管理消息通信方式中，并对每个数据进行标记。
可以理解的是，在topic不满足面向服务架构的服务定义时，本申请实施例还可以按照功能安全等级对数据进行分类，减少topic使用的个数，可以降低通信延时，并参考上述实施例的实现方式对不同的数据进行标记，便于数据区分和解析。
综上，根据数据类型进行划分，如果不满足最大数量需求，可以按照基于RPC(Remote Procedure Call Protocol，远程过程调用协议)框架的SOA服务特性，将SOA服务中所有的请求映射到请求topic，所有的响应映射到响应topic，所有的通知映射到通知topic；当划分后的管topic数量未达到最大值，可以按照安全等级进行topic划分；在完成划分后，本申请实施例还可以对国标数据、云平台管控数据、车载内部的文件数据等进行划分，按照数据类型分别分配单独的topic。
下面结合图3对本申请实施例的步骤S102进行详细说明，具体包括以下步骤：
S301：根据MCU芯片中的资源分配情况，合理的计算部署DDS协议栈、DDS各个实体占用的资源情况，然后通过计算或仿真得到在MCU芯片中可用的资源情况下，MCU芯片可承载的最大topic数量；
S303：一个topic承载一种数据类型的通信数据，根据整车的服务或功能设计，梳理需要通过DDS协议栈传输的数据类型；
S303：按照一种数据类型或一类数据分配一个topic的原则进行计算，判断是否满足MCU芯片可承载的最大topic梳理；
S304：当现阶段设计的数据满足要求，还需要考虑后期功能扩展等需求，预留部分topic数量，在这种情况下判断是否满足MCU芯片可承载的最大topic梳理；
S305：如果数据和topic可以匹配，则可以按照要求将一种数据类型放入一个topic中；
S306：当S303不满足需求时，由于现阶段汽车行业的通信都是基于SOA架构定义的服务，故考虑可以按照服务的特点对数据进行分类，减少topic使用的个数；
S307：根据服务定义特点，可将数据按照请求、响应、通知进行分类，划分到3个topic中；在此情况下，一个topic中包含了大量的数据，通信双方需要对不同的数据进行标识，便于数据区分和解析；
S308：梳理整车中是否存在不适用于SOA服务的数据，例如log数据等；
S309：对于整车中存在很多不适用于SOA服务的数据，此类数据可以在topic部署数量足够的情况下，合理的分配到单独的topic中；
S310：当整车中如果不是按照SOA服务进行数据定义时，还可以按照功能安全等级对数据进行分类，同时需要参考S307对不同的数据进行标识，便于数据区分和解析。
在步骤S103中，对数据进行预处理。
在本申请的一个实施例中，对数据进行预处理包括：根据微控制单元中的数据通信通道，进行不同域之间的数据通信；根据微控制单元中的数据交互通道，进行不同通信协议之间的数据交互；对经过数据通信和数据交互后的数据进行冗余处理，得到处理后的数据。
由于不同域之间是无法进行数据交互的，但是在实际应用中，不可避免的会存在某些数据确实需要跨域交互，在这种情况下，本申请实施例可以在服务发现阶段，网关分别与不同域(domain)中需要交互数据的实体建立连接。在数据通信过程中，网关通过在源domain中建立的订阅者实体读取源ECU数据，然后网关通过在目的domain中建立的发布者实体发送数据给目的ECU数据。
需要说明的是，本申请实施例可以MCU芯片中搭建不同domain之间数据通信通道，进行不同domain之间的数据通信，如图4所示，具体步骤如下：
S401：制定domain之间通信的路由表，路由表中需要包括：需要路由的通信数据、数据的收发节点、数据所在的domain、数据的DDS实体信息，也可以根据实际情况增加内容；
S402：网关分别与不同域的实体完成服务发现，建立通信连接。当数据发端为A，数据收端为B，A与B在不同的domain时，在网关内创建两个实体X、Y，X和A在一个domain里面，且两个实体能建立通信连接，可正常进行数据交互；Y与B在一个domain里面，且两个实体能建立通信连接，可正常进行数据交互，X与Y作为网关中进行不同domain数据交换的实体；
S403：网关完成不同domain直接数据的交互。在数据通信时，如果网关收到A发给X的数据，通过X实体A的数据，然后调用实体Y将数据发给实体B，完成数据路由；
S404：Qos兼容性匹配。由于实际通信的双方为A与B，故A与B的Qos需要考虑兼容性问题，同时作为X与Y的Qos需要和A、B配合，避免由于Qos的设计问题导致通信故障。如当A为reliability时，B可以为best_effert，其中X就可以为reliability或best_effert，但是Y必须为best_effert。
进一步地，本申请实施例可以根据微控制单元中的数据交互通道，进行不同通信协议之间的数据交互，主要是在MCU芯片中搭建CAN与DDS不同通信协议之间的数据交互通道，针对CAN转DDS，可以做到转发特定CAN报文，转发延时可控，转发条件设计、数据封装格式设计、CAN报文对应的topic设计等。
其中，转发特定CAN报文主要是避免无效负载，过滤掉无关的数据；转发时延需要根据转发条件、硬件处理能力等评估，同时数据使用方需要根据转发延时判断数据的可用性；转发条件是要求网关需要按照设计转发条件进行数据收发，避免不同网关之间不同步；数据封装格式设计是为了保证收发双方数据可读，发送方需要按照报文封装格式进行数据的封包，接收方需要按照封装格式进行解包；CAN报文对应的topic设计是为了兼容不同的通信协议。如图5所示，具体步骤如下：
S501：设计CAN转DDS路由表，根据功能需求，制定路由表；
S502：网关过滤无关CAN报文。网关根据CAN转DDS路由表中的内容过滤掉来自源网段的无效CAN报文，只接收和转发路由表中的CAN报文；
S503：网关转发条件设计。为保证转发的及时和考虑MCU中资源的限制，网关内设置转发条件为：1)当CAN报文周期小于等于50ms时，转发时间T＝5ms，网关每5ms转发一次收到的CAN报文，当数据转发后，T置位重新计时；如果转发周期内未收到任何数据，则本周期内不转发，计时器置位。2)当CAN报文周期大于50ms时，转发时间T＝10ms，网关每10ms转发一次收到的CAN报文，当数据转发后，T置位重新计时；如果转发周期内未收到任何数据，则本周期内不转发，计时器置位；
S504：topic设计。当存在一个MCU接入多个CAN网段，同时需要转发多CAN网段的数据，则一个topic需要设计多个不同类型的子集去去承载不同CAN网段的数据，即一个CAN网段数据封装到一个数据子集中；
S505：数据封装。为保证双方都能正确解析及识别数据，需要设计统一的封装格式，如图6所示。其中，Payload部分内容如下表所示，表1为是数据封装格式中Payload部分信息表；
表1
S506：当转发条件满足后，网关调用DDS协议栈将数据封装到RTPS(real-timePolling Service，实时轮询服务)数据包中，发送到以太网网段给接收方；
S507：转发时延计算。当转发时间T＝5ms时，单个CAN报文的最大转发时延为5ms；当转发时间T＝10ms时，单个CAN报文的最大转发时延为10ms。
进一步地，经过数据通信和数据交互后的数据都会存在主数据和冗余数据，本申请实施例可以通过对冗余数据进行处理，来完成主数据和冗余数据的识别，从而达到DDS冗余设计要求。
具体而言，在CAN与以太网同时存在的通信架构中，同时CAN数据主要承载安全相关的内容，在CAN数据中对行车安全的内容都会存在一个主数据，一个冗余数据来满足安全要求，同时主路和冗余路CAN的信号都需要通过CAN转以太网发给同一个以太网节点(如智驾控制模块)。如图7所示，本申请实施例对MCU芯片中完成基于DDS的以太网通信冗余数据预处理进行详细说明，包括以下步骤：
S701：CAN节点数据根据安全需要，主信号发往主CAN网段，冗余信号发往冗余CAN网段；
S702：网关根据信号的接收通道，将数据放入对应的topic中，其中网关接收主CAN网段数据后放入主topic中；网关接收冗余CAN网段的数据后放入冗余topic中；
S703：在网关中，对来自主CAN网段的数据主topic中的writer设计Qos，分别为OWNERSHIP.kind＝EXCLUSIVE，OWNERSHIP_STRENTH.value＝10，对来自冗余CAN网段的数据冗余topic中的writer设计Qos，分别为OWNERSHIP.kind＝EXCLUSIVE，OWNERSHIP_STRENTH.value＝2；其中OWNERSHIP_STRENTH.value可以根据需求进行配置，value越大，接收端优先处理；
S704：当S603中的两个topic数据同时发往接收端时，接收端根据OWNERSHIP_STRENTH.value的大小，判断主数据和冗余数据，其中接收端处理的是拥有OWNERSHIP_STRENTH.value值最大的发送端发送的topic数据，如果OWNERSHIP_STRENTH.value最大的发送端失效后，则会获取value值相对较低的发送端发送的数据。
在步骤S104中，利用划分后的管理消息通信方式对处理后的数据进行数据分发，以利用分发后的数据进行通信。
在对管理消息通信方式进行合理划分后，本申请实施例可以利用划分后的管理消息通信方式对处理后的数据进行数据分发，以利用分发后的数据进行通信，可以在微控制单元中使用大量的管理消息通信方式(topic)，使整车中的以太网节点在微控制单元芯片能够正常运行数据分发服务协议栈，完成以太网通信。
在本申请的一个实施例中，在根据预设通信机制，确定微控制单元所能承载的管理消息通信方式之前，包括：制定客户端控制单元的管理消息通信方式的名称和标识；在域参与者发现阶段，将需要通信的实体放在一个域中，使得通信的实体相互之间完成简单参与者发现协议；在端点发现阶段，根据管理消息通信方式的名称和标识，建立服务端控制单元与客户端控制单元的管理消息通信方式的通信连接，以完成简单端点发现协议；根据简单参与者发现协议和简单断点发现协议建立预设通信机制。
根据上述背景技术中提到的各芯片的资源情况可知，MCU芯片与MPU芯片中可以承载的topic数量是不一样的，为了完成两者之间的正常通信，需要完成简单参与者发现协议和简单端点发现协议。在域参与者发现阶段，本申请实施例需要所有的参与者在一个域(domain)里面，因此，需要交互的MCU芯片中部署的域参与者和MPU芯片中部署的域参与者可以放在一个domain中，使得通信的实体相互之间完成简单参与者发现协议；在端点发现阶段，MPU芯片中部署的所有的DDS实体需要与MCU芯片中部署的DDS实体进行发现匹配，MPU芯片中部署的实体需要发送其所有信息给MCU芯片中部署的实体，信息包括：topic_name、type_name，writerID等，MCU芯片中部署的实体根据自身需要，选择性学习接收到的topic_name，同时按照学习到的topic_name和type_name信息发送EDP报文给需要建立连接的MPU芯片中部署的实体，完成端点发现，在完成两个发现阶段后就完成了不对等通信的机制。
下面结合图8对本申请实施例的建立预设通信机制的实现过程进行详细说明，具体步骤如下：
S801：在设计前期阶段，当MCU作为客户端时，将各个MCU自身需要调用的服务或方法集中放在一个请求topic、一个响应topic、一个通知topic中，但是这些topic的名称前需要增加标识“MCU_C”，便于完成SEDP(简单端点发现协议)。；
S802：在域参与者发现阶段，所有的MCU、MPU在一个domain中，相互之间可以完成SPDP(简单参与者发现协议)；
S803：在端点发现阶段，客户端MCU发送带有“MCU_C topic name”的数据，服务端MCU/服务端MPU选择自身可以提供给客户端MCU对应的topic，这些topic需要强制与客户端MCU的topic进行匹配，建立连接，同时服务端MCU或服务端MPU通过topic_data发送携带自身具有的topic name和method hash id至客户端MCU，客户端MCU根据method hash id匹配需要的服务方法，完成SEDP(简单端点发现协议)。
可选地，在本申请的一个实施例中，在端点发现阶段，根据管理消息通信方式的名称和标识，建立服务端控制单元与客户端控制单元的管理消息通信方式的通信连接包括：在服务端控制单元收到客户端控制单元的远程过程调用协议请求时，根据服务端控制单元的方法哈希标识过滤远程过程调用协议请求，得到与服务器控制单元相符的远程过程调用协议请求；在客户端控制单元收到服务端控制单元的远程过程调用协议回复时，根据客户端控制单元的全局唯一标识符过滤远程过程调用协议回复，得到与客户端控制单元相符的远程过程调用协议请求，以建立服务端控制单元与客户端控制单元的管理消息通信方式的通信连接。
本申请实施例可以在服务器端控制单元收到客户端控制单元的调用协议请求时，根据方法哈希标识过滤不属于自己的请求，客户端控制单元收到服务端控制单元的调用协议回复时，根据全局唯一标识符过滤掉不属于自己的应答，从而建立客户端和服务器端的通信连接，方便加载并显示数据，并可以根据需求筛选数据，减少处理的数据量。具体实现如图8所示的步骤S804：在数据通信阶段：服务端MCU/服务端MPU收到客户端MCU的RPC(Remote Procedure Call，远程过程调用)请求时，根据method hash id过滤掉不属于自己的请求；客户端MCU侧收到服务端MCU/服务端MPU的RPC回复时，根据GUID(Globally UniqueIdentifier，全局唯一标识符)过滤掉不属于自己的应答。
在本申请的一个实施例中，在根据微控制单元中的数据通信通道，进行不同域之间的数据通信之前，包括：制定域之间通信的第一路由表；根据第一路由表建立不同域的通信的实体之间的通信连接，以创建数据通信通道。
本申请实施例中第一路由表中可以包括：需要路由的通信数据、数据的收发节点、数据所在的domain、数据的DDS实体信息，也可以根据实际情况增加内容。根据路由表不同域的实体完成服务发现，建立通信连接，使不同域之间的实体能够建立通信。
可选地，在本申请的一个实施例中，在根据微控制单元中的数据交互通道，进行不同通信协议之间的数据交互之前包括：制定不同通信协议之间通信的第二路由表；根据第二路由表建立不同通信协议之间的通信连接，以创建数据交互通道。
本申请实施例中的第二路由表是CAN转DDS路由表，可以根据功能需求进行制定，不做具体限定。利用本申请实施例第二路由表建立不同通信协议之间的通信连接，从而根据路由表的内容过滤来自源网段的无效CAN报文，仅接收和转发路由表中的CAN报文。
根据本申请实施例提出的数据分发通信方法，根据预设通信机制确定微控制单元所能承载的管理消息通信方式，利用微控制单元中的数据对管理消息通信方式进行划分，对数据进行预处理，利用划分后的管理消息通信方式对处理后的数据进行数据分发，以利用分发后的数据进行通信，可以在微控制单元中使用大量的管理消息通信方式(topic)，使整车中的以太网节点在微控制单元芯片能够正常运行数据分发服务协议栈，完成以太网通信。由此，解决了相关技术中MCU的运存资源有限无法搭载DDS协议栈，导致了在MCU中不能使用大量的管理消息通信方式，且仅在MPU上部署DDS协议栈，会导致整车通信架构复杂，通信延时高等问题。
其次参照附图描述根据本申请实施例提出的一种数据分发通信***，应用于微控制单元。
图9是本申请实施例的一种数据分发通信***的方框示意图。
如图9所示，该数据分发通信***10包括：确定模块100、划分模块200、预处理模块300和数据分发通信模块400。
其中，确定模块100，用于根据预设通信机制，确定微控制单元所能承载的管理消息通信方式；划分模块200，用于利用微控制单元中的数据对管理消息通信方式进行划分；预处理模块300，用于对数据进行预处理；数据分发通信模块400，用于利用处理后的数据对划分后的管理消息通信方式进行数据分发，以利用分发后的数据进行通信。
在本申请的一个实施例中，本申请实施例的***10还包括：第一制定模块、处理模块、第一建立模块和第二建立模块。
其中，第一制定模块，用于在根据预设通信机制，确定微控制单元所能承载的管理消息通信方式之前，制定客户端控制单元的管理消息通信方式的名称和标识；处理模块，用于在域参与者发现阶段，将需要通信的实体放在一个域中，使得通信的实体相互之间完成简单参与者发现协议；第一建立模块，用于在端点发现阶段，根据管理消息通信方式的名称和标识，建立服务端控制单元与客户端控制单元的管理消息通信方式的通信连接，以完成简单端点发现协议；第二建立模块，用于根据简单参与者发现协议和简单断点发现协议建立预设通信机制。
在本申请的一个实施例中，第一建立模块进一步用于在服务端控制单元收到客户端控制单元的远程过程调用协议请求时，根据服务端控制单元的方法哈希标识过滤远程过程调用协议请求，得到与服务器控制单元相符的远程过程调用协议请求；在客户端控制单元收到服务端控制单元的远程过程调用协议回复时，根据客户端控制单元的全局唯一标识符过滤远程过程调用协议回复，得到与客户端控制单元相符的远程过程调用协议请求，以建立服务端控制单元与客户端控制单元的管理消息通信方式的通信连接。
在本申请的一个实施例中，预处理模块300进一步用于根据微控制单元中的数据通信通道，进行不同域之间的数据通信；根据微控制单元中的数据交互通道，进行不同通信协议之间的数据交互；对经过数据通信和数据交互后的数据进行冗余处理，得到处理后的数据。
在本申请的一个实施例中，本申请实施例的***10还包括：第二制定模块和第三建立模块。
其中，第二制定模块，用于在根据微控制单元中的数据通信通道，进行不同域之间的数据通信之前，制定域之间通信的第一路由表；第三建立模块，用于根据第一路由表建立不同域的通信的实体之间的通信连接，以创建数据通信通道。
在本申请的一个实施例中，本申请实施例的***10还包括：第三制定模块和第四建立模块。
其中，第三制定模块，用于在根据微控制单元中的数据交互通道，进行不同通信协议之间的数据交互之前，制定不同通信协议之间通信的第二路由表；第四建立模块，用于根据第二路由表建立不同通信协议之间的通信连接，以创建数据交互通道。
可选地，在本申请的一个实施例中，划分模块200进一步用于确定微控制单元芯片承载的管理消息通信方式的数量的最大值；梳理微控制单元芯片中承载数据的数据类型；按照预设原则对管理消息通信方式进行划分后，判断根据数据类型对管理消息通信方式进行划分后的管理消息通信方式的数量是否达到最大值，预设原则为数据类型与管理消息通信方式一一对应进行配置；当划分后的管理消息通信方式的数量未达到最大值且预留了部分数量的管理消息通信方式用于后期功能扩展时，根据数据类型对管理消息通信方式进行划分。
在本申请的一个实施例中，划分模块200进一步用于当划分后的管理消息通信方式的数量未达到最大值，或划分后的管理消息通信方式的数量达到最大值而未预留部分数量的管理消息通信方式用于后期功能扩展时，判断管理消息通信方式是否满足面向服务架构的服务定义；若管理消息通信方式满足面向服务架构的服务定义，按照面向服务架构的特点对微控制芯片的数据进行分类，将同一类型的数据划分到一个管理消息通信方式中，并对每个数据进行标记。
在本申请的一个实施例中，划分模块200进一步用于若管理消息通信方式满足面向服务架构的服务定义，按照功能安全等级对数据进行分类，将属于同一功能安全等级的数据划分到一个管理消息通信方式中，并对每个数据进行标记。
需要说明的是，前述对数据分发通信方法实施例的解释说明也适用于该实施例的数据分发通信***，此处不再赘述。
根据本申请实施例提出的数据分发通信***，根据预设通信机制确定微控制单元所能承载的管理消息通信方式，利用微控制单元中的数据对管理消息通信方式进行划分，对数据进行预处理，利用划分后的管理消息通信方式对处理后的数据进行数据分发，以利用分发后的数据进行通信，可以在微控制单元中使用大量的管理消息通信方式(topic)，使整车中的以太网节点在微控制单元芯片能够正常运行数据分发服务协议栈，完成以太网通信。由此，解决了相关技术中MCU的运存资源有限无法搭载DDS协议栈，导致了在MCU中不能使用大量的管理消息通信方式，且仅在MPU上部署DDS协议栈，会导致整车通信架构复杂，通信延时高等问题。
图10为本申请实施例提供的计算机设备的结构示意图。该计算机设备可以包括：
存储器1001、处理器1002及存储在存储器1001上并可在处理器1002上运行的计算机程序。
处理器1002执行程序时实现上述实施例中提供的数据分发通信方法。
进一步地，计算机设备还包括：
通信接口1003，用于存储器1001和处理器1002之间的通信。
存储器1001，用于存放可在处理器1002上运行的计算机程序。
存储器1001可能包含高速RAM(Random Access Memory，随机存取存储器)存储器，也可能还包括非易失性存储器，例如至少一个磁盘存储器。
如果存储器1001、处理器1002和通信接口1003独立实现，则通信接口1003、存储器1001和处理器1002可以通过总线相互连接并完成相互间的通信。总线可以是ISA(IndustryStandard Architecture，工业标准体系结构)总线、PCI(Peripheral Component，外部设备互连)总线或EISA(Extended Industry Standard Architecture，扩展工业标准体系结构)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图10中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
可选的，在具体实现上，如果存储器1001、处理器1002及通信接口1003，集成在一块芯片上实现，则存储器1001、处理器1002及通信接口1003可以通过内部接口完成相互间的通信。
处理器1002可能是一个CPU(Central Processing Unit，中央处理器)，或者是ASIC(Application Specific Integrated Circuit，特定集成电路)，或者是被配置成实施本申请实施例的一个或多个集成电路。
本申请实施例还提供一种包含有计算机程序的非易失性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上的数据分发通信方法。
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不是必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或N个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“N个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。
流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更N个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。
应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，N个步骤或方法可以用存储在存储器中且由合适的指令执行***执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列，现场可编程门阵列等。
本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。
尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。
Claims (10)
1.一种数据分发通信方法，应用于微控制单元，其特征在于，包括以下步骤：
根据预设通信机制，确定所述微控制单元所能承载的管理消息通信方式；
利用所述微控制单元中的数据对所述管理消息通信方式进行划分；
对所述数据进行预处理；
利用划分后的管理消息通信方式对处理后的数据进行数据分发，以利用分发后的数据进行通信；
在所述根据预设通信机制，确定所述微控制单元所能承载的管理消息通信方式之前，包括：
制定客户端控制单元的所述管理消息通信方式的名称和标识；
在域参与者发现阶段，将需要通信的实体放在一个域中，使得所述通信的实体相互之间完成简单参与者发现协议；
在端点发现阶段，根据所述管理消息通信方式的名称和标识，建立服务端控制单元与所述客户端控制单元的管理消息通信方式的通信连接，以完成简单端点发现协议；
根据所述简单参与者发现协议和所述简单端点发现协议建立所述预设通信机制；
所述利用所述微控制单元中的数据对所述管理消息通信方式进行划分包括：
确定所述微控制单元芯片承载的所述管理消息通信方式的数量的最大值；
梳理所述微控制单元芯片中承载数据的数据类型；
按照预设原则对所述管理消息通信方式进行划分后，判断根据所述数据类型对所述管理消息通信方式进行划分后的所述管理消息通信方式的数量是否达到所述最大值，所述预设原则为所述数据类型与所述管理消息通信方式一一对应进行配置；
当划分后的所述管理消息通信方式的数量未达到所述最大值且预留了部分数量的管理消息通信方式用于后期功能扩展时，根据所述数据类型对所述管理消息通信方式进行划分。
2.根据权利要求1所述的方法，其特征在于，所述在端点发现阶段，根据所述管理消息通信方式的名称和标识，建立服务端控制单元与所述客户端控制单元的管理消息通信方式的通信连接包括：
在服务端控制单元收到客户端控制单元的远程过程调用协议请求时，根据所述服务端控制单元的方法哈希标识过滤所述远程过程调用协议请求，得到与所述服务端控制单元相符的远程过程调用协议请求；
在所述客户端控制单元收到服务端控制单元的远程过程调用协议回复时，根据所述客户端控制单元的全局唯一标识符过滤所述远程过程调用协议回复，得到与所述客户端控制单元相符的远程过程调用协议请求，以建立所述服务端控制单元与所述客户端控制单元的管理消息通信方式的通信连接。
3.根据权利要求1所述的方法，其特征在于，所述对所述数据进行预处理包括：
根据所述微控制单元中的数据通信通道，进行不同域之间的数据通信；
根据所述微控制单元中的数据交互通道，进行不同通信协议之间的数据交互；
对经过所述数据通信和所述数据交互后的数据进行冗余处理，得到所述处理后的数据。
4.根据权利要求3所述的方法，其特征在于，在所述根据所述微控制单元中的数据通信通道，进行不同域之间的数据通信之前，包括：
制定域之间通信的第一路由表；
根据所述第一路由表建立不同域的通信的实体之间的通信连接，以创建所述数据通信通道。
5.根据权利要求3所述的方法，其特征在于，在根据所述微控制单元中的数据交互通道，进行不同通信协议之间的数据交互之前，包括：
制定不同通信协议之间通信的第二路由表；
根据所述第二路由表建立不同通信协议之间的通信连接，以创建所述数据交互通道。
6.根据权利要求1所述的方法，其特征在于，所述利用所述微控制单元中的数据对所述管理消息通信方式进行划分包括：
当划分后的所述管理消息通信方式的数量未达到所述最大值，或划分后的所述管理消息通信方式的数量达到所述最大值而未预留部分数量的管理消息通信方式用于后期功能扩展时，判断所述管理消息通信方式是否满足面向服务架构的服务定义；
若所述管理消息通信方式满足所述面向服务架构的服务定义，按照所述面向服务架构的特点对所述微控制单元的数据进行分类，将同一类型的所述数据划分到一个管理消息通信方式中，并对每个数据进行标记。
7.根据权利要求6所述的方法，其特征在于，所述利用所述微控制单元中的数据对所述管理消息通信方式进行划分包括：
若所述管理消息通信方式满足所述面向服务架构的服务定义，按照功能安全等级对所述数据进行分类，将属于同一功能安全等级的所述数据划分到一个管理消息通信方式中，并对每个数据进行标记。
8.一种数据分发通信***，应用于微控制单元，其特征在于，用于实现权利要求1-7任一项所述的数据分发通信方法，包括：
确定模块，用于根据预设通信机制，确定所述微控制单元所能承载的管理消息通信方式；
划分模块，用于利用所述微控制单元中的数据对所述管理消息通信方式进行划分；
预处理模块，用于对所述数据进行预处理；
数据分发通信模块，用于利用处理后的数据对划分后的管理消息通信方式进行数据分发，以利用分发后的数据进行通信。
9.一种计算机设备，其特征在于，所述计算机设备包括处理器和存储器，所述存储器上存储有计算机程序，当所述计算机程序被所述处理器执行时，实现权利要求1-7任一项所述的数据分发通信方法。
10.一种包含有计算机程序的非易失性计算机可读存储介质，其特征在于，当所述计算机程序被一个或多个处理器执行时，实现权利要求1-7任一项所述的数据分发通信方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211180655.2A CN115913809B (zh) | 2022-09-26 | 2022-09-26 | 数据分发通信方法、***、计算机设备及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211180655.2A CN115913809B (zh) | 2022-09-26 | 2022-09-26 | 数据分发通信方法、***、计算机设备及存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115913809A CN115913809A (zh) | 2023-04-04 |
| CN115913809B true CN115913809B (zh) | 2024-05-03 |
Family
ID=86471566
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211180655.2A Active CN115913809B (zh) | 2022-09-26 | 2022-09-26 | 数据分发通信方法、***、计算机设备及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115913809B (zh) |
Citations (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR101551702B1 (ko) * | 2014-07-01 | 2015-09-11 | 국방과학연구소 | Dds를 기반으로 한 비행체의 시공간 위치정보 실시간 전달 장치 및 방법 |
| CN106411972A (zh) * | 2015-07-29 | 2017-02-15 | 中国科学院沈阳自动化研究所 | 一种基于Openflow协议的实时数据分发***和方法 |
| CN106412023A (zh) * | 2016-09-05 | 2017-02-15 | 南京臻融软件科技有限公司 | 一种基于发布订阅机制的多源数据分发方法 |
| KR20180026301A (ko) * | 2016-09-02 | 2018-03-12 | 주식회사 포스코아이씨티 | 스마트 팩토리를 위한 빅데이터 분석 시스템 |
| CN107844325A (zh) * | 2017-10-27 | 2018-03-27 | 上海斐讯数据通信技术有限公司 | 一种分布式数据的获取方法及*** |
| CN109474471A (zh) * | 2018-11-30 | 2019-03-15 | 中国人民解放军陆军工程大学 | 一种dds网络的rtps协议加速方法及其节点和*** |
| CN109547543A (zh) * | 2018-11-15 | 2019-03-29 | 上海赫千电子科技有限公司 | 车载以太网的分布式运行***及运行方法 |
| CN110086891A (zh) * | 2019-06-25 | 2019-08-02 | 奥特酷智能科技(南京)有限公司 | 基于dds协议在自动驾驶中实现分布式通信的方法 |
| CN110225074A (zh) * | 2019-01-04 | 2019-09-10 | 国网浙江省电力有限公司 | 一种基于设备地址域的通讯报文分发***及分发方法 |
| CN110688383A (zh) * | 2019-09-26 | 2020-01-14 | 中国银行股份有限公司 | 数据采集方法及*** |
| CN111934840A (zh) * | 2020-06-29 | 2020-11-13 | 北京百度网讯科技有限公司 | 客户端和服务端的通信方法、网关、电子设备及存储介质 |
| CN112367233A (zh) * | 2020-09-27 | 2021-02-12 | 上海赫千电子科技有限公司 | 基于面向服务的架构下车载网络ecu通信方法及装置 |
| CN112688952A (zh) * | 2020-12-28 | 2021-04-20 | 京信网络***股份有限公司 | 消息处理方法、装置、射频拉远单元和介质 |
| CN113794582A (zh) * | 2021-08-10 | 2021-12-14 | 中国电子科技集团公司电子科学研究院 | 一种天地一体化网络通信管理协议和方法 |
| CN113810475A (zh) * | 2021-08-30 | 2021-12-17 | 中国电子科技集团公司第五十四研究所 | 一种基于大数据架构的Wifi探针设备管控*** |
| KR20220027716A (ko) * | 2020-08-27 | 2022-03-08 | (주)구름네트웍스 | 기록매체 |
| CN114401269A (zh) * | 2021-12-08 | 2022-04-26 | 国电南瑞科技股份有限公司 | 一种业务数据分发方法、***及物联管理平台 |
| KR102396923B1 (ko) * | 2021-12-29 | 2022-05-12 | 한화시스템 주식회사 | 데이터 분산 서비스에서 성능 검증 방법 |
| CN114745364A (zh) * | 2022-03-28 | 2022-07-12 | 重庆长安汽车股份有限公司 | 基于mqtt协议的车联网数据分发***及方法 |
| CN114866528A (zh) * | 2022-04-01 | 2022-08-05 | 广东美味鲜调味食品有限公司 | 一种基于MQTT和Websocket的数据通讯方法 |
-
2022
- 2022-09-26 CN CN202211180655.2A patent/CN115913809B/zh active Active
Patent Citations (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR101551702B1 (ko) * | 2014-07-01 | 2015-09-11 | 국방과학연구소 | Dds를 기반으로 한 비행체의 시공간 위치정보 실시간 전달 장치 및 방법 |
| CN106411972A (zh) * | 2015-07-29 | 2017-02-15 | 中国科学院沈阳自动化研究所 | 一种基于Openflow协议的实时数据分发***和方法 |
| KR20180026301A (ko) * | 2016-09-02 | 2018-03-12 | 주식회사 포스코아이씨티 | 스마트 팩토리를 위한 빅데이터 분석 시스템 |
| CN106412023A (zh) * | 2016-09-05 | 2017-02-15 | 南京臻融软件科技有限公司 | 一种基于发布订阅机制的多源数据分发方法 |
| CN107844325A (zh) * | 2017-10-27 | 2018-03-27 | 上海斐讯数据通信技术有限公司 | 一种分布式数据的获取方法及*** |
| CN109547543A (zh) * | 2018-11-15 | 2019-03-29 | 上海赫千电子科技有限公司 | 车载以太网的分布式运行***及运行方法 |
| CN109474471A (zh) * | 2018-11-30 | 2019-03-15 | 中国人民解放军陆军工程大学 | 一种dds网络的rtps协议加速方法及其节点和*** |
| CN110225074A (zh) * | 2019-01-04 | 2019-09-10 | 国网浙江省电力有限公司 | 一种基于设备地址域的通讯报文分发***及分发方法 |
| CN110086891A (zh) * | 2019-06-25 | 2019-08-02 | 奥特酷智能科技(南京)有限公司 | 基于dds协议在自动驾驶中实现分布式通信的方法 |
| CN110688383A (zh) * | 2019-09-26 | 2020-01-14 | 中国银行股份有限公司 | 数据采集方法及*** |
| CN111934840A (zh) * | 2020-06-29 | 2020-11-13 | 北京百度网讯科技有限公司 | 客户端和服务端的通信方法、网关、电子设备及存储介质 |
| KR20220027716A (ko) * | 2020-08-27 | 2022-03-08 | (주)구름네트웍스 | 기록매체 |
| CN112367233A (zh) * | 2020-09-27 | 2021-02-12 | 上海赫千电子科技有限公司 | 基于面向服务的架构下车载网络ecu通信方法及装置 |
| CN112688952A (zh) * | 2020-12-28 | 2021-04-20 | 京信网络***股份有限公司 | 消息处理方法、装置、射频拉远单元和介质 |
| CN113794582A (zh) * | 2021-08-10 | 2021-12-14 | 中国电子科技集团公司电子科学研究院 | 一种天地一体化网络通信管理协议和方法 |
| CN113810475A (zh) * | 2021-08-30 | 2021-12-17 | 中国电子科技集团公司第五十四研究所 | 一种基于大数据架构的Wifi探针设备管控*** |
| CN114401269A (zh) * | 2021-12-08 | 2022-04-26 | 国电南瑞科技股份有限公司 | 一种业务数据分发方法、***及物联管理平台 |
| KR102396923B1 (ko) * | 2021-12-29 | 2022-05-12 | 한화시스템 주식회사 | 데이터 분산 서비스에서 성능 검증 방법 |
| CN114745364A (zh) * | 2022-03-28 | 2022-07-12 | 重庆长安汽车股份有限公司 | 基于mqtt协议的车联网数据分发***及方法 |
| CN114866528A (zh) * | 2022-04-01 | 2022-08-05 | 广东美味鲜调味食品有限公司 | 一种基于MQTT和Websocket的数据通讯方法 |
Non-Patent Citations (5)
| Title |
|---|
| A DDS-based distributed simulation approach for engineering-level models;Dohyung Kim;《Proceedings of the Winter Simulation Conference 2014》;20150126;全文 * |
| 基于Actor模型的数据分发***的设计与实现;黄善柒;《中国优秀硕士论文全文数据库》;20180315;全文 * |
| 基于DDS的传感器数据分发***的设计与实现;韩军;王永生;;舰船电子工程;20181020(第10期);全文 * |
| 基于数据分发服务的远程过程调用机制的研究与实现;严静;《中国优秀硕士论文全文数据库》;20180415;全文 * |
| 实时数据分发服务***重构正确性保证研究;杨曙辉;王小非;陈龙;;舰船电子工程;20090120(第01期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115913809A (zh) | 2023-04-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6434612B1 (en) | Connection control interface for asynchronous transfer mode switches | |
| US7594052B2 (en) | Integrated circuit and method of communication service mapping | |
| US7733841B2 (en) | Vehicle network with time slotted access and method | |
| CN110474792B (zh) | 网络配置方法、设备及*** | |
| WO2022222901A1 (zh) | 一种基于autosar实现dds通信的***架构、通信方法及设备 | |
| CN112491984A (zh) | 基于虚拟网桥的容器编排引擎集群管理*** | |
| JP4820940B2 (ja) | ポート群を動的に専用化するプロセッサ間通信ネットワーク | |
| CN112671914B (zh) | 一种基于actor模型的物联网设备通讯方法和*** | |
| CN115913809B (zh) | 数据分发通信方法、***、计算机设备及存储介质 | |
| US10893001B2 (en) | Method for coordinating access to a resource of a distributed computer system, computer system and computer program | |
| CN114866467A (zh) | 一种集群通信方法、装置、***、设备及可读存储介质 | |
| CN113110111B (zh) | 基于ns3的分布式半实物仿真*** | |
| CN115361337B (zh) | 一种基于通信路由和星型网络的通信方法及*** | |
| CN115174687B (zh) | 服务调用方法、装置、电子设备及存储介质 | |
| WO2023035777A1 (zh) | 网络配置方法、代理组件、控制器、电子设备和存储介质 | |
| WO2023246127A1 (en) | System and methods for mission execution in network | |
| CN116248775A (zh) | Dds网关的交互方法、装置、电子设备及存储介质 | |
| Mohamed | Self-configuring communication middleware model for multiple network interfaces | |
| JP2000151739A (ja) | 情報処理装置、分散処理装置およびネットワークシステム | |
| CN115174687A (zh) | 服务调用方法、装置、电子设备及存储介质 | |
| Li et al. | Multicast Transmission in DDS Based on the Client-Server Discovery Model | |
| Kim et al. | A method for improving the reliability of the gateway system by using OSEK and duplication scheme | |
| CN113892247A (zh) | 中继装置、车辆、通信方法以及通信程序 | |
| CN117319220A (zh) | 一种云云接入第三方生态平台的架构设计方法 | |
| CN117081888A (zh) | 物理网络的创建方法、相关装置、电子设备及存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |