CN116760893A - 一种消息通信方法、装置、电子设备以及存储介质 - Google Patents

Abstract

本公开涉及一种消息通信方法、装置、电子设备以及存储介质。其中，消息通信方法包括：获取来自应用层的第一待发送数据；响应于第一待发送数据需要被保护，对第一待发送数据进行处理，得到携带验证信息的第二待发送数据；其中，验证信息是基于第一待发送数据生成的；指示消息发布者将第二待发送数据进行发布，以使消息订阅者获取第二待发送数据。

Description

一种消息通信方法、装置、电子设备以及存储介质

技术领域

本公开涉及车载通信技术领域，尤其涉及一种消息通信方法、装置、电子设备以及存储介质。

背景技术

数据分发服务(DDS，Data Distribution Service)中间件广泛应用于分布式系统和实时数据处理领域，其发布-订阅模式为各种应用提供了高效的数据交换和通信方式。然而，由于DDS中间件的开放性和分布式特性，在利用DDS中间件进行数据传输的过程中，存在着通信数据被篡改、丢失、破坏等安全问题。相关技术中，尚缺少可以安全、高效的利用DDS协议进行通信的方案。

因此，如何安全、高效的利用DDS协议进行通信，是亟待解决的技术问题。

发明内容

为克服相关技术中存在的问题，本公开提供一种消息通信方法、装置、电子设备以及存储介质。

根据本公开实施例的第一方面，提供一种消息通信方法，所述方法应用于车辆的通信系统的中间层，所述车辆的通信系统的中间层部署了DDS协议，所述方法包括：获取来自应用层的第一待发送数据；响应于所述第一待发送数据需要被保护，对所述第一待发送数据进行处理，得到携带验证信息的第二待发送数据；其中，所述验证信息是基于所述第一待发送数据生成的；指示消息发布者将所述第二待发送数据进行发布，以使消息订阅者获取所述第二待发送数据。

在一些实施例中，所述对所述第一待发送数据进行处理，得到携带验证信息的第二待发送数据，包括：调用接口函数，生成所述第一待发送数据的验证信息；以及根据所述第一待发送数据和所述验证信息，得到所述第二待发送数据。

在一些实施例中，所述验证信息为E2E字段；其中，所述E2E字段至少包括所述第一待发送数据的CRC校验码、所述第一待发送数据的数据标识、所述第二待发送数据的长度以及计数值；所述生成所述第一待发送数据的验证信息，包括：调用E2E服务，根据所述第一待发送数据，生成所述E2E字段。

在一些实施例中，所述第一待发送数据携带有标识，所述响应于所述第一待发送数据需要被保护，包括：根据对预先设置的目标配置文件进行解析的解析结果，得到保护数据标识列表；其中，所述保护数据标识列表记录了需要被保护的来自应用层的数据的标识；通过以下方式确定所述第一待发送数据是否需要被保护：对所述第一待发送数据的标识与所述保护数据标识列表中的每一个数据的标识进行匹配操作；响应于所述匹配操作的结果为第一结果，确定所述第一待发送数据需要被保护。

根据本公开实施例的第二方面，提供一种消息通信方法，所述方法应用于车辆的通信系统的中间层，所述车辆的通信系统的中间层部署了DDS协议，所述方法包括：获取来自消息发布者的第一待接收数据；响应于所述第一待接收数据需要被解析，对所述第一待接收数据进行拆包处理，得到第二待接收数据和基于所述第二待接收数据生成的验证信息；根据所述验证信息，对所述第二待接收数据进行校验；响应于所述第二待接收数据的校验结果为通过，将所述第二待接收数据发送给目标数据接收者。

在一些实施例中，所述对所述第一待接收数据进行拆包处理，包括：调用接口函数，根据所述第一待接收数据的封装格式，从所述第一待接收数据中解析出所述第二待接收数据和所述验证信息。

在一些实施例中，所述验证信息为E2E字段；其中，所述E2E字段至少包括所述第二待接收数据的CRC校验码、所述第二待接收数据的数据标识、所述第一待接收数据的长度以及计数值；所述根据所述第一待接收数据的封装格式，从所述第一待接收数据中解析出所述第二待接收数据和所述验证信息，包括：利用E2E服务，对所述第一待接收数据进行解析，得到所述第二待接收数据和基于所述第二待接收数据生成的E2E字段。

在一些实施例中，所述响应于所述第一待接收数据需要被解析，包括：根据对预先设置的目标配置文件进行解析的解析结果，得到保护数据标识列表；其中，所述保护数据标识列表记录了需要被保护的来自应用层的数据的标识；通过以下方式确定所述第一待接收数据是否需要被解析：对所述第一待接收数据的标识与所述保护数据标识列表中的每一个数据的标识进行匹配操作；响应于所述匹配操作的结果为第一结果，确定所述第一待接收数据需要被解析。

根据本公开实施例的第三方面，提供一种消息通信装置，所述装置部署了DDS协议，所述装置包括：获取模块，用于获取来自应用层的第一待发送数据；生成模块，用于响应于所述第一待发送数据需要被保护，对所述第一待发送数据进行处理，得到携带验证信息的第二待发送数据；其中，所述验证信息是基于所述第一待发送数据生成的；发送模块，用于指示消息发布者将所述第二待发送数据进行发布，以使消息订阅者获取所述第二待发送数据。

根据本公开实施例的第四方面，提供一种消息通信装置，所述装置部署了DDS协议，所述装置包括：获取模块，用于获取来自消息发布者的第一待接收数据；处理模块，用于响应于所述第一待接收数据需要被解析，对所述第一待接收数据进行拆包处理，得到第二待接收数据和基于所述第二待接收数据生成的验证信息；校验模块，用于根据所述验证信息，对所述第二待接收数据进行校验；发送模块，用于响应于所述第二待接收数据的校验结果为通过，将所述第二待接收数据发送给目标数据接收者。

根据本公开实施例的第五方面，提供一种车辆，存储有一组指令集，所述指令集被所述车辆执行，以实现本公开第一方面所提供的消息通信方法。

根据本公开实施例的第六方面，提供一种电子设备，包括：处理器；用于存储所述处理器可执行指令的存储器；所述处理器，用于从所述存储器中读取所述可执行指令，并执行所述指令以实现本公开第一方面和第二方面所提供的消息通信方法。

根据本公开实施例的第七方面，提供一种计算机可读存储介质，其上存储有计算机程序指令，该程序指令被处理器执行时实现本公开第一方面和第二方面所提供的消息通信方法的步骤。

本公开的实施例提供的技术方案可以包括以下有益效果：

本公开提供的实施例中，获取来自应用层的第一待发送数据；响应于第一待发送数据需要被保护，对第一待发送数据进行处理，得到携带验证信息的第二待发送数据；其中，验证信息是基于第一待发送数据生成的；指示消息发布者将第二待发送数据进行发布，以使消息订阅者获取第二待发送数据。从而可以安全、高效的利用DDS协议进行通信。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1是根据一示例性实施例示出的一种消息通信方法的流程图。

图2是根据一示例性实施例示出的确定第一待发送数据需要被保护的方法的流程图。

图3是根据一示例性实施例示出的又一种消息通信方法的流程图。

图4是根据一示例性实施例示出的确定第一待接收数据需要被解析的方法的流程图。

图5是根据一示例性实施例示出的应用层通过DDS网络进行通信的示意图。

图6是根据一示例性实施例示出的一种消息通信装置的框图。

图7是根据一示例性实施例示出的又一种消息通信装置的框图。

图8是根据一示例性实施例示出的一种车辆的框图。

图9是根据一示例性实施例示出的一种电子设备的框图。

具体实施方式

下面将结合附图详细地对示例性实施例进行描述说明。

应当指出，相关实施例及附图仅为描述说明本公开所提供的示例性实施例，而非本公开的全部实施例，也不应理解本公开受相关示例性实施例的限制。

应当指出，本公开中所用术语“第一”、“第二”等仅用于区别不同步骤、设备或模块等。相关术语既不代表任何特定技术含义，也不表示它们之间的顺序或者相互依存关系。

应当指出，本公开中所用术语“一个”、“多个”、“至少一个”的修饰是示意性而非限制性的。除非在上下文另有明确指出，否则应该理解为“一个或多个”。

应当指出，本公开中所用术语“和/或”，用于描述关联对象之间的关联关系，一般表示至少存在三种关联关系。例如，A和/或B，至少可以表示：单独存在A，同时存在A和B，单独存在B这三种关联关系。

应当指出，本公开的方法实施例中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。除非特别说明，本公开的范围不受相关实施例中步骤的描述顺序限制。

需要说明的是，本公开中所有获取信号、信息或数据的动作都是在遵照所在地国家相应的数据保护法规政策的前提下，并获得由相应装置所有者给予授权的情况下进行的。

示例性方法

图1是根据一示例性实施例示出的一种消息通信方法的流程图。

该消息通信方法应用于车辆的通信系统的中间层，该车辆的通信系统的中间层部署了DDS协议。

DDS是一个以数据为中心的中间件协议，位于应用层和操作系统之间。DDS采用发布(Publish)/订阅(Subscribe)通信模式进行实时、高效的数据分发，同时，DDS协议还提供丰富的QoS(Quality of Service，服务品质)策略，可满足分布式实时通信的要求。

如图1所示，该方法包括以下步骤。

在步骤S110中，获取来自应用层的第一待发送数据。

如图5所示，应用层可以为接入DDS网络的任一应用程序。例如，应用层可以为具有音视频播放功能的A车的车载娱乐程序A。又例如，某汽车驾驶系统内有两个ECU(电子控制单元)，ECU A和ECU B，分别位于两个ECU上的应用程序1和应用程序3之间通过DDS网络进行通信，应用程序1要将汽车车速、油门踏板等信号，传给应用程序3，则应用程序1为本步骤中的应用层(即发送端的应用程序)。

第一待发送数据为需要通过DDS网络传送的数据，例如，刹车信号数据、转向信号数据、音视频数据、电池信号数据等。

在具体实施过程中，可以通过多种方式获取来自应用层的第一待发送数据。

在步骤S120中，响应于第一待发送数据需要被保护，对第一待发送数据进行处理，得到携带验证信息的第二待发送数据；其中，验证信息是基于第一待发送数据生成的。

在具体实施过程中，可以通过多种方式确定第一待发送数据是否需要被保护。例如，可以通过第一待发送数据携带的标识，确定第一待发送数据是否需要被保护。又例如，可以通过第一待发送数据对应的应用程序的类型(娱乐程序或控制程序)，确定第一待发送数据是否需要被保护。

关于确定第一待发送数据是否需要被保护的实施例参见图2中的相关内容，这里不再赘述。

在一些实施例中，可以调用接口函数，生成第一待发送数据的验证信息；根据第一待发送数据和验证信息，得到第二待发送数据。

在具体实施过程中，可以通过多种方式根据第一待发送数据和验证信息，得到第二待发送数据。仅作为示例，可以将验证信息和第一待发送数据进行拼接得到第二待发送数据。

在具体实施过程中，可以通过多种方式得到验证信息，例如，可以生成第一待发送数据的循环冗余校核(CRC，Cyclic Redundancy Check)的校验码，将该校验码作为验证信息。

在一些实施例中，验证信息可以为E2E字段，可以调用E2E服务，根据第一待发送数据，生成第一待发送数据对应的E2E字段。

仅作为示例，车辆的通信系统的中间层提供接口函数，应用层可以调用该接口函数，将第一待发送数据作为参数，传递给该接口函数；在接口函数中，可以按照图2实施例中提供的方法确定第一待发送数据是否需要被保护，如果不需要被保护，可以将第一待发送数据返回给应用层，由应用层基于DCPS层，对第一待发送数据进行发布；如果需要被保护，则在接口函数中，调用E2E服务对第一待发送数据进行处理，得到第二待发送数据，并将第二待发送数据返回给应用层，由应用层基于DCPS层，对第二待发送数据进行发布。

E2E服务是可以对数据实现端对端校验(E2E，End to End)的进程/线程或者接口函数。

在具体实施过程中，E2E服务可以由开发人员自行编写实现，也可以使用开源的具有E2E安全保护功能的程序实现，不受本说明书的表述所限。

E2E是autosar规范里规定的一种用于实现安全通信的协议，其包含了CRC校验算法、基于Counter(计数值)的丢包验证方法等数据安全传输的保护机制。按照Autosar规范的要求，E2E存在一系列的Profile(配置)，每种配置在对数据进行保护时，有各自的机制、参数、数据格式，具有非常强的灵活性，用户可以根据实际需要选择配置。

仅作为示例，调用E2E服务，根据第一待发送数据生成的E2E字段包括如下数据字段：

DataId：第一待发送数据的数据标识，用于验证每个被传输的数据元素的身份，其值可以是32位地址空间内的任何值。数据ID在通信系统的网络中是全局唯一的。在使用E2E监管来保护消息(从COM调用)的情况下，接收方COM在接收时仅期望接收特定消息，该消息由E2E使用数据ID进行检查确认。

Length：第二待发送数据的长度，32位，引入Length字段以支持可变大小长度。该字段包括要被保护的数据(第一待发送数据)+E2E字段(CRC+计数器+长度+DataID)。

Counter:计数值，32位，用于保护下一数据的计数器，每次增加1，A将计数值发给B，B可以依据收到的counter值确定是否接收及时。初始值为0，每次调用E2E_P08Protect()时，计数器递增1，直至0xFFFFFFFF。

CRC：循环冗余校验码，32位，对第一待发送数据进行多项式除法计算后得到的余数。

在步骤S130中，指示消息发布者将第二待发送数据进行发布，以使消息订阅者获取第二待发送数据。

DDS主要由以数据为中心的发布订阅层(DCPS，Data-Centric Publish-Subscribe)和数据本地重构层(DLRL，Data Local Reconstruction Layer)两部分组成，其中，DCPS用于处理数据的订阅、发布，应用层利用该层进行数据交互。

DCPS由域(Domian)、参与者(Participant)、发布者(Publisher)、订阅者(Subscriber)、数据写入者(DataWriter)、数据读取者(DataReader)、主题(Topic)、监听器(Listener)等实体(Entity)组成。相关技术术语的释义如下：

(一)Domian

域是DDS的基本结构，是一个通信平面，由唯一DomianID标识。只有在同一个域内的通信实体才能通信(交互数据)。不同域的应用实体，不能通信。

(二)DomianParticipant

DomianParticipant是服务的入口点，应用程序如果要发布、订阅数据，首先，要获取DomianParticipant。只有获取DomianParticipant以后，方能创建、删除或者管理实体(eg：Topic、Publisher、Subscriber等)。

(三)Publisher

用来获取发布数据，并将其发布到对应的域中。Publisher作为发布方，可以包含一个或者多个DataWriter。

(四)Subscriber

接收Publisher发布的数据，并将其传递给对应的上层应用实体。至少包含一个DataReader。

(五)Topic

Topic主要由Name(名称)和Type(类型)构成，用于表示网络中待传输的数据。

TopicName：是一个字符串，且在Domian内唯一标识；

TopicType：数据类型定义，每个主题类型可以指定对应的Key，可以用于区分相同Topic的不同实例。

(六)DataWriter

上层的应用程序如果要发送数据，需要通过DataWriter，将特定的Topic写入指定类型的接口。DataWriter对数据编码，通过Publisher传输。一个DataWriter必须和一个Topic绑定。

(七)DataReader

Subscriber通过DataReader从绑定的Topic中获取数据，然后传递给应用程序。一个DataReader可以绑定多个Topic。

仅作为示例，在DCPS层，执行如下步骤，以指示消息发布者将第二待发送数据进行发布：

1.通过Participant Interface模块和QOS Module获取用户配置的参与者信息和QOS信息。

2.Discovery Module通过调用RTPS的流程，在SPDP、SEDP支持下，负责发现参与者，确认数据读取者。当参与者与数据读取者对应的两个端点互相发现之后，即可以使用Subscriber module，Publisher Module进行数据的订阅和发送。

3.Publish Module将第二待发送数据作为sample(样本)，根据Topic类型发送给Deserialize/Serialize Module，由Serialize Module把该sample转换为二进制数据并发送给Writer Module。

4.Writer Module做统一的调度和处理，并决定序列化后的sample是同步发送还是异步发送，最终Writer Module会把数据发送给WHC Module。

5.WHC Module作为缓存，针对数据丢失，进行消息重传。

6.Queue Service Module负责将数据发送给RTPS ProcessModule，从而将第二待发送数据发布到域中。

本公开提供的实施例中，响应于第一待发送数据需要被保护，对第一待发送数据进行处理，得到携带验证信息的第二待发送数据；基于DCPS层，指示消息发布者将第二待发送数据进行发布，以使消息订阅者获取第二待发送数据。由于消息发布者发布到域中的第二待发送数据是携带验证信息的数据，因此，可以在消息发布者和消息订阅者之间建立安全传输通道，有效保证了基于DDS协议传输数据的安全性；为第一待发送数据添加验证信息后进行传输，带来的通信成本以及计算开销较少，可以有效保持DDS协议传输数据的实时性。

本公开提供的实施例中，通过调用接口函数，生成第一待发送数据的验证信息；以及根据第一待发送数据和验证信息，得到第二待发送数据。从而可以无需对DDS源码进行修改，实现了数据的安全处理与协议处理的隔离，并且可以根据不同的应用场景选择不同的数据保护方式。

图2根据一示例性实施例示出的确定第一待发送数据需要被保护的方法的流程图。

在步骤S210中，对第一待发送数据的标识与保护数据标识列表中的每一个数据的标识进行匹配操作。

在具体实施过程中，第一待发送数据携带有标识。

保护数据标识列表记录了需要被保护的来自应用层的数据的标识，在一些实施例中，可以根据对预先设置的目标配置文件进行解析的解析结果，得到保护数据标识列表。

在具体实施过程中，可以通过多种方式得到保护数据标识列表。仅作为示例，可以由用户确认哪些数据是需要进行安全保护的(例如，刹车信号数据、转向信号数据等)，哪些数据不需要进行安全保护(例如，音视频数据等)，然后将这些信息通过配置文件的方式传达给SOACore.Databus，可以得到保护数据标识列表。

在步骤S220中，响应于匹配操作的结果为第一结果，确定第一待发送数据需要被保护。

仅作为示例，可以将第一待发送数据的标识与保护数据标识列表中的每一个数据的标识进行匹配，如果保护数据标识列表中存在与第一待发送数据的标识相同的数据的标识，则确定匹配操作的结果为第一结果；如果保护数据标识列表中并不存在与第一待发送数据的标识相同的数据的标识，则确定匹配操作的结果为第二结果。

在匹配操作的结果为第一结果的情况下，确定第一待发送数据需要被保护。

本公开提供的实施例中，根据对预先设置的目标配置文件进行解析的解析结果，得到保护数据标识列表；对第一待发送数据的标识与保护数据标识列表中的每一个数据的标识进行匹配操作；响应于匹配操作的结果为第一结果，确定第一待发送数据需要被保护。从而可以根据用户的意愿，对数据进行有选择的安全保护，既保证了重要数据传输的安全性，又不至于占用过多的通信资源。

图3是根据一示例性实施例示出的又一种消息通信方法的流程图。

该消息通信方法应用于车辆的通信系统的中间层，车辆的通信系统的中间层部署了DDS协议。

如图3所示，该方法包括如下步骤。

在步骤S310中，获取来自消息发布者的第一待接收数据。

第一接收数据为需要通过DDS网络传送的数据，例如，刹车信号数据、转向信号数据、音视频数据、电池信号数据等。

在具体实施过程中，消息订阅者可以从域中按主题获取来自消息发布者的第一待接收数据。

关于消息订阅者、域以及消息发布者的详细描述，参见步骤S130中的相关内容，这里不再赘述。

仅作为示例，在DCPS层，执行如下步骤，获取来自消息发布者的第一待接收数据。

1.通过Participant Interface模块和QOS Module获取客户配置的参与者信息和QOS信息。

2.Discovery Module调用RTPS的流程，在SPDP、SEDP支持下，发现参与者，确认数据发送者。当两个端点互相发现之后，就可以使用Subscriber module，Publisher Module进行数据的订阅和发送。

3.RTPS Process Module收到消息之后，通过Unicast Module/Muticast Module处理，转入RHC Module存储。

4.RHC Module收到数据就会调用Deserialize/Serialize Module把二进制数据转换为对应的sample数据，并发送给Reader模块，由Reader模块把数据(第一待接收数据)分发给Subscriber Module。

在步骤S320中，响应于第一待接收数据需要被解析，对第一待接收数据进行拆包处理，得到第二待接收数据和基于第二待接收数据生成的验证信息。

在具体实施过程中，可以通过多种方式确定第一待接收数据是否需要被解析。例如，可以通过第一待接收数据携带的标识，确定第一待接收数据是否需要被解析。又例如，可以通过第一待接收数据对应的应用程序的类型(娱乐程序或控制程序)，确定第一待接收数据是否需要被解析。

关于确定第一待接收数据是否需要被解析的实施例参见图4中的相关内容，这里不再赘述。

在一些实施例中，可以调用接口函数，根据第一待接收数据的封装格式，从第一待接收数据中解析出第二待接收数据和验证信息。

在一些实施例中，验证信息为E2E字段，可以利用E2E服务，对第一待接收数据进行解析，得到第二待接收数据和基于第二待接收数据生成的E2E字段。

关于E2E字段和E2E服务的详细描述参见步骤S120中的相关内容，这里不再赘述。

仅作为示例，验证信息包括：第二待接收数据的CRC校验码、第二待接收数据的数据标识、第一待接收数据的长度以及计数值，可以根据上述各数据字段的长度，从第一待接收数据的起始位开始依次解析出各个数据字段。

在步骤S330中，根据验证信息，对第二待接收数据进行校验。

仅作为示例，针对步骤S120中的E2E字段的示例，E2E服务可以通过以下步骤，根据验证信息，对第二待接收数据进行校验：

(1)数据接收端在等待收到新的数据的过程中，处于STATUS NONEWDATA状态，第二待接收数据和基于第二待接收数据生成的E2E字段出现，则进入步骤(2)。

(2)接收端接收到第二待接收数据后，调用CRC算法，计算第二待接收数据的CRC值，并将其与接收到的E2E字段中的CRC进行比较，如果不同，判定数据状态为STATUS_ERROR；如果相同，进入步骤(3)。

(3)接收端通过读取接收到的E2E字段中的DatalD识别数据，根据此DatalD的配置信息获取数据的相关信息用于后续逻辑判断，并配置计时器。如果该DatalD不在配置信息中，判定数据状态为STATUS ERROR。如果该DatalD在配置信息中，该DataID计时器清0，进入步骤(4)

(4)接收端解析第二待接收数据的Length与该DataID配置信息的Length进行比较，如果不相等，判定数据状态为STATUS ERROR。如果相等，进入步骤(5)。

(5)接收端计算DeltaCounter，用当前接收到的该DatalD的Counter值减去该DataID在接收端上次接收的Counter值，进入步骤(6)。

(6)如果DeltaCounter大于等于0同时小于配置的MaxDeltaCounter(DeltaCounter容忍范围，可配置)，进入步骤(7)，否则判定数据状态为STATUSWRONGSEOUENCE(DeltaCounter超出容忍范围)

(7)如果DeltaCounter大于0，进入步骤(8)，否则DeltaCounter等于0，判定数据状态为STATUS REPEATED。

(8)如果DeltaCounter等于1，判断数据状态为E2E PO8STATUS OK，否则判定数据态为STATUS OKSOMELOST。

在步骤S340中，响应于第二待接收数据的校验结果为通过，将第二待接收数据发送给目标数据接收者。

目标数据接收者可以为订阅了第二待接收数据的，接入DDS网络的任一应用程序。仅作为示例，步骤S110示例中的应用程序3(参见图5)可以为本步骤中的目标接收者。

在具体实施过程中，当消息订阅者接收到第一待接收数据之后，可以通过侦听器或者条件触发的方式，通知目标接收者，有数据可用，然后目标接收者可以调用通信中间层提供的接口函数，在该接口函数中，利用图4实施例中提供的方法，确定第一待接收数据是否需要被解析，在第一待接收数据需要被解析的情况下，利用该接口函数对第一待接收数据进行拆包处理，将通过校验的第二待接收数据返回给目标接收者；在第一待接收数据不需要被解析的情况下，该接口函数直接将第一待接收数据返回给目标接收者。

本公开提供的实施例中，获取来自消息发布者的第一待接收数据；响应于第一待接收数据需要被解析，对第一待接收数据进行拆包处理，得到第二待接收数据和基于第二待接收数据生成的验证信息；根据验证信息，对第二待接收数据进行校验；响应于第二待接收数据的校验结果为通过，将第二待接收数据发送给目标数据接收者。因此，可以对由消息发布者发布到域中的第二待接收数据进行校验，确保第二待接收数据的传输过程中未发生篡改、丢失或者破坏等数据安全问题。从而可以在消息发布者和消息订阅者之间建立安全传输通道，有效保证了基于DDS协议传输数据的安全性。

图4是根据一示例性实施例示出的确定第一待接收数据需要被解析的方法的流程图。

在步骤S410中，对第一待接收数据的标识与保护数据标识列表中的每一个数据的标识进行匹配操作。

在具体实施过程中，第一待接收数据携带有标识。保护数据标识列表记录了需要被解析的来自应用层的数据的标识，在一些实施例中，可以根据对预先设置的目标配置文件进行解析的解析结果，得到保护数据标识列表。仅作为示例，可以由用户确认哪些数据是需要进行安全保护的(例如，刹车信号数据、转向信号数据等)，哪些数据不需要进行安全保护(例如，音视频数据等)，然后将这些信息通过配置文件的方式传达给SOACore.Databus，可以得到保护数据标识列表。

在步骤S420中，响应于匹配操作的结果为第一结果，确定第一待接收数据需要被解析。

仅作为示例，可以将第一待接收数据的标识与保护数据标识列表中的每一个数据的标识进行匹配，如果保护数据标识列表中存在与第一待接收数据的标识相同的数据的标识，则确定匹配操作的结果为第一结果；如果保护数据标识列表中并不存在与第一待接收数据的标识相同的数据的标识，则确定匹配操作的结果为第二结果。

在匹配操作的结果为第一结果的情况下，确定第一待接收数据需要被解析。

本公开提供的实施例中，对第一待接收数据的标识与保护数据标识列表中的每一个数据的标识进行匹配操作；响应于匹配操作的结果为第一结果，确定第一待接收数据需要被解析。因此，可以确定接收到的第一待接收数据是否需要被解析，从而可以根据用户的意愿，对数据进行有选择的安全保护，既保证了重要数据传输的安全性，又不至于占用过多的通信资源。

示例性装置

图6是根据一示例性实施例示出的一种消息通信装置框图。参照图6，该装置600包括获取模块610、生成模块620和发送模块630。

获取模块610，用于获取来自应用层的第一待发送数据。

生成模块620，用于响应于所述第一待发送数据需要被保护，对所述第一待发送数据进行处理，得到携带验证信息的第二待发送数据；其中，所述验证信息是基于所述第一待发送数据生成的。

发送模块630，用于基于DCPS层，指示消息发布者将所述第二待发送数据进行发布，以使消息订阅者获取所述第二待发送数据。

在一些实施例中，所述对所述第一待发送数据进行处理，得到携带验证信息的第二待发送数据，包括：调用接口函数，生成所述第一待发送数据的验证信息；以及根据所述第一待发送数据和所述验证信息，得到所述第二待发送数据。

在一些实施例中，所述验证信息为E2E字段；其中，所述E2E字段至少包括所述第一待发送数据的CRC校验码、所述第一待发送数据的数据标识、所述第二待发送数据的长度以及计数值；所述生成所述第一待发送数据的验证信息，包括：调用E2E服务，根据所述第一待发送数据，生成所述E2E字段。

在一些实施例中，所述第一待发送数据携带有标识，所述响应于所述第一待发送数据需要被保护，包括：根据对预先设置的目标配置文件进行解析的解析结果，得到保护数据标识列表；其中，所述保护数据标识列表记录了需要被保护的来自应用层的数据的标识；通过以下方式确定所述第一待发送数据是否需要被保护：对所述第一待发送数据的标识与所述保护数据标识列表中的每一个数据的标识进行匹配操作；响应于所述匹配操作的结果为第一结果，确定所述第一待发送数据需要被保护。

上述消息通信装置的实施例中，各模块的具体处理及其带来的技术效果可分别参考对应方法实施例中的相关说明，在此不再赘述。

图7是根据一示例性实施例示出的又一种消息通信装置框图。参照图7，该装置700包括获取模块710、处理模块720、校验模块730和发送模块740。

获取模块710，用于获取来自消息发布者的第一待接收数据。

处理模块720，用于响应于所述第一待接收数据需要被解析，对所述第一待接收数据进行拆包处理，得到第二待接收数据和基于所述第二待接收数据生成的验证信息。

校验模块730，用于根据所述验证信息，对所述第二待接收数据进行校验。

发送模块740，用于响应于所述第二待接收数据的校验结果为通过，将所述第二待接收数据发送给目标数据接收者。

在一些实施例中，所述对所述第一待接收数据进行拆包处理，包括：调用接口函数，根据所述第一待接收数据的封装格式，从所述第一待接收数据中解析出所述第二待接收数据和所述验证信息。

在一些实施例中，所述验证信息为E2E字段；其中，所述E2E字段至少包括所述第二待接收数据的CRC校验码、所述第二待接收数据的数据标识、所述第一待接收数据的长度以及计数值；所述根据所述第一待接收数据的封装格式，从所述第一待接收数据中解析出所述第二待接收数据和所述验证信息，包括：利用E2E服务，对所述第一待接收数据进行解析，得到所述第二待接收数据和基于所述第二待接收数据生成的E2E字段。

在一些实施例中，所述响应于所述第一待接收数据需要被解析，包括：根据对预先设置的目标配置文件进行解析的解析结果，得到保护数据标识列表；其中，所述保护数据标识列表记录了需要被保护的来自应用层的数据的标识；通过以下方式确定所述第一待接收数据是否需要被解析：对所述第一待接收数据的标识与所述保护数据标识列表中的每一个数据的标识进行匹配操作；响应于所述匹配操作的结果为第一结果，确定所述第一待接收数据需要被解析。

上述消息通信装置的实施例中，各模块的具体处理及其带来的技术效果可分别参考对应方法实施例中的相关说明，在此不再赘述。

示例性车辆

图8是根据一示例性实施例示出的一种车辆800的框图。该车辆800可以是燃油车辆、混合动力车辆、电动车辆、燃料电池车辆或者其他类型的车辆。

参照图8，车辆800可包括多个子系统，例如，驱动系统810、控制系统820、感知系统830、通信系统840、信息显示系统850以及计算处理系统860。车辆800还可以包括更多或更少的子系统，且各个子系统还可以包括多个部件，在此不一一赘述。

该驱动系统810，包括为车辆800提供动力运动的组件。例如，发动机、能量源、传动装置等。

该控制系统820，包括为车辆800提供控制的组件。例如，车辆控制、座舱设备控制、驾驶辅助控制等。

该感知系统830，包括为车辆800提供周边环境感知的组件。例如，车辆定位系统、激光传感器、语音传感器、超声波传感器、摄像设备等。

该通信系统840，包括为车辆800提供通信连接的组件。例如，移动通信网络(如，3G、4G、5G网络等)、WiFi、蓝牙、车联网等。

该信息显示系统850，包括为车辆800提供各种信息显示的组件。例如，车辆信息显示、导航信息显示、娱乐信息显示等。

该计算处理系统860，包括为车辆800提供数据计算和处理能力的组件。计算处理系统860可包括至少一个处理器861和存储器862。处理器861可以执行存储在存储器862中的指令。

处理器861可以是任何常规的处理器，诸如商业可获得的CPU。处理器还可以包括诸如图像处理器(Graphic Process Unit，GPU)，现场可编程门阵列(Field ProgrammableGate Array，FPGA)、片上系统(System on Chip，SOC)、专用集成芯片(ApplicationSpecific Integrated Circuit，ASIC)或它们的组合。

存储器862可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

在本公开实施例中，存储器862中存储有一组指令集，处理器861可以执行该指令集，以实现上述示例性实施例中任一所述的消息通信方法的全部或部分步骤。

示例性电子设备

图9是根据一示例性实施例示出的一种电子设备900的框图。该电子设备900可以是车辆控制器、车载终端、车载计算机或者其他类型的电子设备。

参照图9，电子设备900，可包括至少一个处理器910和存储器920。处理器910可以执行存储在存储器920中的指令。处理器910通过数据总线与存储器920通信连接。除存储器920外，处理器910还可通过数据总线与输入设备930、输出设备940、通信设备950通信连接。

处理器910可以是任何常规的处理器，诸如商业可获得的CPU。处理器还可以包括诸如图像处理器(Graphic Process Unit，GPU)，现场可编程门阵列(Field ProgrammableGate Array，FPGA)、片上系统(System on Chip，SOC)、专用集成芯片(ApplicationSpecific Integrated Circuit，ASIC)或它们的组合。

存储器920可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

在本公开实施例中，存储器920中存储有可执行指令，处理器910可以从所述存储器920中读取所述可执行指令，并执行所述指令以实现上述示例性实施例中任一所述的消息通信方法的全部或部分步骤。

示例性计算机可读存储介质

除了上述方法和装置以外，本公开的示例性实施例还可以是计算机程序产品或存储有该计算机程序产品的计算机可读存储介质。该计算机产品中包括计算机程序指令，该计算机程序指令可被处理器执行，以实现上述示例性实施例中任一方法中描述的的全部或部分步骤。

所述计算机程序产品可以以一种或多种程序设计语言的任意组合来编写用于执行本申请实施例操作的程序代码，所述程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言以及脚本语言(例如Python)。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。

所述计算机可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子包括：具有一个或多个导线电连接的静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘，或者上述的任意合适的组合。

本领域技术人员在考虑说明书及实践本公开后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种消息通信方法，其特征在于，所述方法应用于车辆的通信系统的中间层，所述车辆的通信系统的中间层部署了DDS协议，所述方法包括：

获取来自应用层的第一待发送数据；

响应于所述第一待发送数据需要被保护，对所述第一待发送数据进行处理，得到携带验证信息的第二待发送数据；其中，所述验证信息是基于所述第一待发送数据生成的；

指示消息发布者将所述第二待发送数据进行发布，以使消息订阅者获取所述第二待发送数据。

2.根据权利要求1所述的消息通信方法，其特征在于，所述对所述第一待发送数据进行处理，得到携带验证信息的第二待发送数据，包括：

调用接口函数，生成所述第一待发送数据的验证信息；以及

根据所述第一待发送数据和所述验证信息，得到所述第二待发送数据。

3.根据权利要求2所述的消息通信方法，其特征在于，所述验证信息为E2E字段；其中，所述E2E字段至少包括所述第一待发送数据的CRC校验码、所述第一待发送数据的数据标识、所述第二待发送数据的长度以及计数值；

所述生成所述第一待发送数据的验证信息，包括：

调用E2E服务，根据所述第一待发送数据，生成所述E2E字段。

4.一种消息通信方法，其特征在于，所述方法应用于车辆的通信系统的中间层，所述车辆的通信系统的中间层部署了DDS协议，所述方法包括：

获取来自消息发布者的第一待接收数据；

响应于所述第一待接收数据需要被解析，对所述第一待接收数据进行拆包处理，得到第二待接收数据和基于所述第二待接收数据生成的验证信息；

根据所述验证信息，对所述第二待接收数据进行校验；

响应于所述第二待接收数据的校验结果为通过，将所述第二待接收数据发送给目标数据接收者。

5.根据权利要求4所述的消息通信方法，其特征在于，所述对所述第一待接收数据进行拆包处理，包括：

调用接口函数，根据所述第一待接收数据的封装格式，从所述第一待接收数据中解析出所述第二待接收数据和所述验证信息。

6.一种消息通信装置，其特征在于，所述装置部署了DDS协议，所述装置包括：

获取模块，用于获取来自应用层的第一待发送数据；

生成模块，用于响应于所述第一待发送数据需要被保护，对所述第一待发送数据进行处理，得到携带验证信息的第二待发送数据；其中，所述验证信息是基于所述第一待发送数据生成的；

发送模块，用于指示消息发布者将所述第二待发送数据进行发布，以使消息订阅者获取所述第二待发送数据。

7.一种消息通信装置，其特征在于，所述装置部署了DDS协议，所述装置包括：

获取模块，用于获取来自消息发布者的第一待接收数据；

处理模块，用于响应于所述第一待接收数据需要被解析，对所述第一待接收数据进行拆包处理，得到第二待接收数据和基于所述第二待接收数据生成的验证信息；

校验模块，用于根据所述验证信息，对所述第二待接收数据进行校验；

发送模块，用于响应于所述第二待接收数据的校验结果为通过，将所述第二待接收数据发送给目标数据接收者。

8.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

所述处理器，用于从所述存储器中读取所述可执行指令，并执行所述指令以实现所述权利要求1-5中任一所述的消息通信方法。

9.一种计算机可读存储介质，其上存储有计算机程序指令，其特征在于，该程序指令被处理器执行时，以实现所述权利要求1-5中任一所述的消息通信方法的步骤。

10.一种车辆，其特征在于，

存储有一组指令集，所述指令集被所述车辆执行，以实现所述权利要求1-5中任一所述的消息通信方法。