CN110300040A - 一种通信方法及相关设备 - Google Patents

Abstract

本申请实施例公开了一种通信方法及相关设备，该方法包括：调用总线驱动接口将待发送队列中的第一请求报文发送给第一目标从设备；获取第一目标从设备针对第一请求报文发送的应答报文的应答时间，若应答时间满足第一预设条件，且发送队列中存在第二请求报文，则调用总线驱动接口向第二目标从设备发送第二请求报文，第二请求报文为待发送队列中与第一请求报文相邻的后一个请求报文。由此可见，当满足不再允许或不再需要为了处理第一请求报文而需要占用主线的第一预设条件时，主设备自动将第一应用程序占用的总线释放，从而避免了主设备中安装的某个应用程序对总线的占用时间过长，从而影响其它应用程序的通信及时性的问题，提高用户体验。

Description

一种通信方法及相关设备

技术领域

本申请涉及通信领域，尤其涉及一种通信方法及相关设备。

背景技术

多个设备可以通过总线(bus)连接在一起形成通信网络，并按照一定的总线通信协议进行通信。通常将发送请求的设备称为主设备，接收请求的设备称为从设备。通过一条总线，一个主设备可以与多个从设备连接在一起。例如主设备可以是物联网关，从设备可以是诸如智能冰箱、智能空调等物联终端。主设备通过总线向从设备发起通信请求，并在同一时刻仅允许一个从设备应答。

在实际应用，例如，在边缘计算网关中，当主设备被允许安装多个应用程序(application，APP)时，多个应用程序均需要利用总线向从设备发起通信请求，为了避免通信冲突，多个应用程序会抢占对总线的使用权，获取到总线使用权的应用程序独占该总线，并通过总线向从设备发起通信请求。

然而，在以往的技术中，应用程序对总线的占用时间由应用程序来决定，若某个应用程序对总线的占用时间过长，则会影响到其他应用程序的通信及时性，进而导致用户体验较差。

发明内容

本申请提供了一种通信方法及相关设备，能够避免主设备中安装的某个应用程序对总线的占用时间过长，影响其它应用程序的通信及时性的问题，提高用户体验。

本申请第一方面提供一种通信方法，其中，该方法应用于主设备，所述方法包括：

首先，调用总线驱动接口将待发送队列中的第一请求报文发送给第一目标从设备；然后，获取第一目标从设备针对第一请求报文发送的应答报文的应答时间，判断该应答时间是否满足第一预设条件，在满足第一预设条件的前提下，若待发送队列中存在第二请求报文，则调用总线驱动接口向第二目标从设备发送第二请求报文。其中，第一请求报文为待发送队列中排序第一的待发送请求报文，第二请求报文为待发送队列中与第一请求报文相邻的后一请求报文。第一预设条件是指，第一请求报文和第一目标从设备针对该第一请求报文发送的应答报文不被允许继续占用总线时对应的条件；或，第一请求报文和第一目标从设备针对该第一请求报文发送的应答报文不再需要继续占用总线时对应的条件。

由此可见，在本申请提供的通信方法中，若主设备中安装有多个应用程序，则将待发送的请求报文进行排序，将排序后的待发送请求报文存储在待发送队列中，当满足不再允许或不再需要为了处理第一请求报文而需要占用主线的第一预设条件时，主设备自动将第一应用程序占用的总线释放，以便主设备中安装的其它应用程序使用该总线。从而避免了主设备中安装的某个应用程序对总线的占用时间过长，从而影响其它应用程序的通信及时性的问题，提高用户体验。

在一些可能的实现中，所述第一预设条件，包括：

从所述第一请求报文发送的时刻开始计时，在第一预设时间段内未接收到所述应答报文；

需要说明的是，在第一预设时间段内未接收到来自第一目标从设备的应答报文，是指，主设备向第一目标从设备发送第一请求报文之后，未收到第一目标从设备的任何响应。换言之，主设备向第一目标从设备发送第一请求报文之后，总线一直被第一应用程序占用，但是，总线上并未出现任何有效数据。若第一应用程序为自身设置了一个很长的对总线的占用时间，那么，在第一应用程序设置的对总线的占用时间未达到时，总线一直处于等待第一目标从设备发送应答报文的状态。对于这种情况，首先，其它应用程序不能利用总线与其它从设备进行通信，从而影响了其它应用程序的通信及时性。其次，总线在一段时间内实际上并未用于传输数据，从而造成了总线利用率低的问题。

因此，当从所述第一请求报文发送的时刻开始计时，在第一预设时间段内未接收到所述应答报文时，主设备自动将第一应用程序占用的总线释放，以便主设备中安装的其它应用程序使用该总线。从而避免了主设备中安装的某个应用程序对总线的占用时间过长，从而影响其它应用程序的通信及时性的问题，提高用户体验。

在一些可能的实现中，所述第一预设条件，包括：

从所述第一请求报文发送的时刻开始计时，在第二预设时间段内获取到所述应答报文的帧尾。

需要说明的是，第一目标从设备发送应答报文时，一般会预先将发送的应答报文封装好，然后通过总线发送该封装好的应答报文。一般来讲，应答报文中会包含一个结束标志，即应答报文的帧尾。若第一目标从设备已经通过总线将帧尾发送出去，则表示该应答报文已经发送完毕。鉴于此，若主设备获取到应答报文的帧尾，则说明第一应用程序和第一目标从设备之间的通信已经完成。此时，主设备自动将第一应用程序占用的总线释放，以便主设备中安装的其它应用程序使用该总线。从而避免了主设备中安装的某个应用程序对总线的占用时间过长，从而影响其它应用程序的通信及时性的问题，提高用户体验。

在一些可能的实现中，所述第一预设条件，包括，

从获取到所述应答报文中一个最小传输单位的数据的时刻开始计时，在第三预设时间段内未接收到下一个所述最小传输单位的数据。

需要说明的是，若从主设备获取到应答报文中其中一个最小传输单位的数据的时刻开始计时，在第三预设时间段内未获取到下一个最小传输单位的数据，则说明总线针对第一请求报文的应答报文的处理已经完成。此时，主设备自动将第一应用程序占用的总线释放，以便主设备中安装的其它应用程序使用该总线。从而避免了主设备中安装的某个应用程序对总线的占用时间过长，从而影响其它应用程序的通信及时性的问题，提高用户体验。

在一些可能的实现中，所述第一请求报文中包括所述第一请求报文的优先级；

在所述第一请求报文被发送之前，所述方法还包括：

根据所述第一请求报文的优先级确定所述第一请求报文在所述待发送队列中的存储位置。

需要说明的是，考虑到实际应用中，一方面，主设备上安装的各个应用程序的重要程度不同，另一方面，各个待发送请求报文的紧急程度不同。因此应用程序在向主设备发送待发送请求报文时，可以根据该待发送请求报文的紧急程度和/或重要程度设置该待发送请求报文的优先级，以便于主设备根据该待发送请求报文的优先级确定该待发送请求报文在多个待发送请求报文中的排序位置，进而确定该待发送请求报文在待发送队列中的存储位置，使得优先级高的待发送报文能够被优先处理。

在一些可能的实现中，所述第一请求报文中还包括目标应用程序的标识，所述根据所述第一请求报文的优先级确定所述第一请求报文在所述待发送队列中的存储位置包括：

根据所述目标应用程序的标识，以及应用程序标识与优先级范围之间的对应关系，得到所述目标应用程序的目标优先级范围；

若所述第一请求报文的优先级在所述目标优先级范围内，则根据所述第一请求报文的优先级确定所述第一请求报文在所述待发送队列中的存储位置。

需要说明的是，在实际应用中，可能存在应用程序恶意竞争总线，将待发送的请求报文的优先级设置的很高，以达到其发送的待发送请求报文被优先处理的目的。鉴于此，在本申请中，主设备接收到应用程序发送的待发送请求报文之后，可以对该待发送请求报文中携带的优先级进行验证，判断该优先级是否在合理的优先级范围内。这样一来，一方面可以使得优先级高的待发送报文被优先处理，另一方面，还可以避免应用程序恶意竞争总线。

在一些可能的实现中，所述方法还包括：

获取所述第一请求报文对应的目标应用程序的通信地址集合，所述通信地址集合包括至少一个与所述目标应用程序通信的从设备的通信地址；

从所述第一请求报文中解析得到所述第一目标从设备的通信地址；

若所述第一目标从设备的通信地址存在于所述通信地址集合中，则执行所述通过总线将待发送队列中的第一请求报文发送给第一目标从设备的步骤。

需要说明的是，一条总线上可以连接一个主设备和多个从设备。当主设备上安装有多个应用程序时，用户期望各个应用程序只能通过总线和被授权的从设备通信。采用本申请实施例提供的方法，可以控制应用程序只与其既定的从设备进行通信，而不能与其它从设备进行通信。

在一些可能的实现中，所述从所述第一请求报文中解析得到所述第一目标从设备的通信地址包括：

获取所述目标应用程序对应的报文发送规则；

若所述第一请求报文符合所述报文发送规则，则从所述第一请求报文中解析得到所述第一目标从设备的通信地址。

需要说明的是，在实际应用中，目标应用程序与第一目标从设备进行通信时，发送的第一请求报文需要符合一定的报文发送规则。如果目标应用程序未按照规定的报文发送规则向第一目标从设备发送第一请求报文，即使第一请求报文通过总线发送出去，第一目标从设备也不能正确解析该第一请求报文，从而导致目标应用程序和第一目标从设备通信失败。因此，在本申请中，首先判断第一请求报文是否满足目标应用程序的报文发送规则，在第一请求报文是否满足目标应用程序的报文发送规则的前提下，才执行对第一请求报文进行解析、通过总线发送等动作，若不满足，则丢弃该第一请求报文，在一定程度上可以避免该第一请求报文占用总线。

在一些可能的实现中，所述方法还包括：

统计在第四预设时间段内发送所述第一请求报文对应的通信资源使用信息；

若所述通信资源使用信息满足不合理使用条件，则禁止与所述第一请求报文对应的应用程序利用所述总线再次发送所述第一请求报文。

需要说明的是，在实际应用中，当主设备安装有多个应用程序时，一般来讲，各个应用程序对通信资源的使用情况应该比较均匀，很少出现一些应用程序过多的占用通信资源的情况，若一些应用程序过多的占用通信资源，则该应用程序可能是流氓应用程序，应该禁止该流氓应用程序继续占用通信资源。鉴于此，在本申请中，主设备还可以监控通信资源的使用情况，当发现流氓应用程序时，禁止该流氓应用程序继续占用通信资源，避免流氓应用程序不合理占用总线。

在一些可能的实现中，所述通信资源使用参数至少包括以下任意一种：

所述第一请求报文的数据量、所述应答报文的数据量、从所述第一请求报文被发送之后到停止获取所述应答报文所花费的时间、从开始获取所述应答报文到停止获取所述应答报文所花费的时间，以及所述第一请求报文被发送的次数。

当主设备监控到上述通信资源的使用情况异常时，可以禁止导致该通信资源使用异常的应用程序继续占用通信资源，避免该应用程序不合理占用总线。

在一些可能的实现中，若在第二预设时间段内未接收到完整的所述应答报文，则所述方法还包括：

进行记录、报警和/或累计未接收到完整的应答报文的次数。

需要说明的是，若从第一请求报文发送的时刻开始计时，在第二预设时间段内未接收到完整的应答报文。则说明，总线被第一应用程序占用的时间过长。因此，在本申请中，对于这种总线被不合理占用的异常情况，主设备可以对该异常情况进行记录，以便于对总线异常情况进行维护修复时，通过查看该记录信息，从而确定引起总线异常的原因。主设备也可以报警，以提示用户总线出现异常，以便于用户及时对总线异常情况进行处理。主设备还可以累计未接收到第一目标从设备针对第一请求报文发送的完整的应答报文的次数，从而确定第一应用程序导致总线异常的次数。

本申请第二方面提供了一种通信装置，所述装置应用于主设备，具体对应于上述第一方面提供的通信方法的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的单元，所述单元可以是软件和/或硬件。

在一些可能的实现中，所述装置包括：第一请求报文发送单元和应答报文获取单元；所述第一请求报文发送单元，用于调用总线驱动接口将待发送队列中的第一请求报文发送给第一目标从设备；

所述应答报文获取单元，用于获取所述第一目标从设备针对所述第一请求报文发送的应答报文的应答时间，若所述应答时间满足第一预设条件，且所述发送队列中存在第二请求报文，则调用所述总线驱动接口向第二目标从设备发送所述第二请求报文，所述第二请求报文为所述待发送队列中与所述第一请求报文相邻的后一个请求报文。

在一些可能的实现中，所述第一预设条件，包括：

从所述第一请求报文发送的时刻开始计时，在第一预设时间段内未接收到所述应答报文；

或者，

从所述第一请求报文发送的时刻开始计时，在第二预设时间段内获取到所述应答报文的帧尾；

或者，

从获取到所述应答报文中一个最小传输单位的数据的时刻开始计时，在第三预设时间段内未接收到下一个所述最小传输单位的数据。

在一些可能的实现中，所述第一请求报文中包括所述第一请求报文的优先级；

所述装置还包括：

存储位置确定单元，用于在所述第一请求报文被发送之前，根据所述第一请求报文的优先级确定所述第一请求报文在所述待发送队列中的存储位置。

在一些可能的实现中，所述第一请求报文中还包括目标应用程序的标识，所述存储位置确定单元包括：目标优先级范围得到子单元和存储位置确定子单元；

所述目标优先级范围得到子单元，用于根据所述目标应用程序的标识，以及应用程序标识与优先级范围之间的对应关系，得到所述目标应用程序的目标优先级范围；

所述目标优先级范围得到子单元，用于当所述第一请求报文的优先级在所述目标优先级范围内时，根据所述第一请求报文的优先级确定所述第一请求报文在所述待发送队列中的存储位置。

在一些可能的实现中，所述装置还包括：通信地址集合获取单元，通信地址解析单元；

所述通信地址集合获取单元，用于获取所述第一请求报文对应的目标应用程序的通信地址集合，所述通信地址集合包括至少一个与所述目标应用程序通信的从设备的通信地址；

所述通信地址解析单元，用于从所述第一请求报文中解析得到所述第一目标从设备的通信地址；

所述第一请求报文发送单元，用于当所述第一目标从设备的通信地址存在于所述通信地址集合中时，执行所述通过总线将待发送队列中的第一请求报文发送给第一目标从设备的步骤。

在一些可能的实现中，所述通信地址解析单元，具体用于获取所述目标应用程序对应的报文发送规则；

当所述第一请求报文符合所述报文发送规则时，从所述第一请求报文中解析得到所述第一目标从设备的通信地址。

在一些可能的实现中，所述装置还包括：资源使用信息统计单元和禁止使用总线单元；

所述资源使用信息统计单元，用于统计在第四预设时间段内发送所述第一请求报文对应的通信资源使用信息；

所述禁止使用总线单元，用于当所述通信资源使用信息满足不合理使用条件时，禁止与所述第一请求报文对应的应用程序利用所述总线再次发送所述第一请求报文。

在一些可能的实现中，所述通信资源使用参数至少包括以下任意一种：

所述第一请求报文的数据量、所述应答报文的数据量、从所述第一请求报文被发送之后到停止获取所述应答报文所花费的时间、从开始获取所述应答报文到停止获取所述应答报文所花费的时间，以及所述第一请求报文被发送的次数。

在一些可能的实现中，若在第二预设时间段内未接收到完整的所述应答报文，则所述装置还包括：记录单元；

所述记录单元，用于进行记录、报警和/或累计未接收到完整的应答报文的次数。

本申请第三方面提供了一种通信设备，所述设备包括：处理器和存储器；

所述存储器，用于存储指令；

所述处理器，用于执行所述存储器中的所述指令，执行以上第一方面任意一项所述的方法。

本申请第四方面提供了一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行以上第一方面任意一项所述的方法。

本申请第五方面提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行以上第一方面任意一项所述的方法。

附图说明

图1为本申请实施例提供的一个应用场景示意图；

图2为本申请实施例提供的一种通信方法的流程示意图；

图3为本申请实施例提供的又一种通信方法的流程示意图；

图4为本申请实施例提供的主设备监控通信资源的使用情况的流程示意图；

图5为本申请实施例提供的又一个应用场景示意图；

图6为本申请实施例提供的一种通信方法的信令交互示意图；

图7为本申请实施例提供的一种通信装置的结构示意图；

图8为本申请实施例提供的一种通信设备的结构示意图。

具体实施方式

本申请实施例提供了一种通信方法及相关设备，能够避免主设备中安装的某个应用程序对总线的占用时间过长，从而影响其它应用程序的通信及时性的问题，提高用户体验。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在实际应用中，当主设备被允许安装多个应用程序时，多个应用程序均需要利用总线向从设备发起通信请求，为了避免通信冲突，多个应用程序抢占对总线的使用权，获取到总线使用权的应用程序独占该总线，并通过总线向从设备发起通信请求，在同一时刻仅允许一个从设备应答。为了不影响主设备中安装的各个应用程序的通信及时性，一般不允许若某个应用程序对总线的占用时间过长。但是，现有的一些总线，例如，推荐标准(recommended standard，RS)RS-485总线、仪表总线(Meter BUS，M-BUS)等总线，当主设备和从设备通过这些总线进行通信时，并不能解决上述某个应用程序对总线的占用时间过长，影响主设备中安装的其他应用程序的通信及时性的问题。

例如，可结合图1进行理解，图1示出了本申请实施例的一个应用场景示意图。在图1所示的应用场景中，主设备100和从设备通过RS-485总线300进行通信。其中，主设备100中安装有多个应用程序，分别为应用程序110、应用程序120、应用程序130和应用程序140；从设备包括从设备210、从设备220、从设备230、从设备240和从设备250。应用程序110、120、130和140可以自主设置其自身对RS-485总线300的占用时间。其中，应用程序110可以利用RS-485总线300和从设备210通信；应用程序120可以利用RS-485总线300和从设备220通信；应用程序130可以利用RS-485总线300和从设备230通信；应用程序140既可以利用RS-485总线300和从设备240通信，又可以利用RS-485总线300和从设备250通信。可以理解的是，当应用程序110利用RS-485总线300和从设备210通信时，不允许其它应用程序利用该RS-485总线300通信。为了不影响主设备中安装的其它应用程序的通信及时性，不允许应用程序110对RS-485总线300的占用时间过长，而若应用程序110为自己设置了较长的对RS-485总线300的占用时间，则在应用程序110占用RS-485总线300总线时，可能会影响其它应用程序，例如应用程序120的通信及时性。

为了解决上述问题，本申请实施例提供一种通信方法及相关设备，能够避免主设备中安装的某个应用程序对总线的占用时间过长，影响其它应用程序的通信及时性的问题，改善了用户体验。本申请实施例中的总线包括但不限于RS-485总线、M-BUS总线等独占式且不具备冲突检测机制的总线。

参见图2，该图为本申请实施例提供的一种通信方法的流程示意图。以下对本申请实施例中提供的通信方法进行详细介绍。

本申请实施例提供的通信方法，应用于主设备，该方法可以通过步骤201-202实现。

步骤201：调用总线驱动接口将待发送队列中的第一请求报文发送给第一目标从设备。

步骤202：获取第一目标从设备针对第一请求报文发送应答报文的应答时间，判断该应答时间是否满足第一预设条件，如果是，执行步骤203。

如前文所述，在本申请实施例中，主设备可以为物联网关。主设备上可以安装多个应用程序，各个应用程序通过总线访问对应的从设备。本申请实施例不具体限定该从设备，例如，从设备可以为智能电视机、智能冰箱、智能空调等设备。

本申请实施例对总线驱动接口不做具体限定，总线驱动接口与总线相关。例如，当总线为RS-485总线时，总线驱动接口为RS-485总线驱动接口。

为方便描述，将与第一目标从设备通信的应用程序称为第一应用程序。

在本申请实施例中，第一请求报文为第一应用程序调用总线驱动接口发送给第一目标从设备的请求报文，也就是说，第一请求报文来自于第一应用程序，第一请求报文的既定接收方为第一目标从设备。

需要说明的是，在本申请实施例中，若主设备中安装有多个应用程序，当应用程序需要利用总线向对应的从设备发送请求报文时，可以先由主设备对待发送的请求报文进行排序，并将排序后的待发送请求报文存储在待发送队列中。

所述第一请求报文为所述待发送队列中当前待发送的请求报文，当总线处理完第一请求报文之后，发送所述待发送队列中下一条待发送的请求报文。

需要说明的是，前文提及的总线处理完第一请求报文，至少可以包括以下三种情况：

第一种情况：总线向第一目标从设备发送第一请求报文之后，在第一预设时间段内未接收到来自第一目标从设备的应答报文。也就是说，从第一请求报文发送的时刻开始计时，在第一预设时间段内未接收到来自第一目标从设备的应答报文。

本申请实施例中的第一预设时间段为预先设置的，本申请实施例对该第一预设时间段的具体取值不做限定，该预设时间段的具体取值可以根据第一应用程序所实现的功能进行确定，也可以根据其它条件确定。

需要说明的是，本申请实施例中，在第一预设时间段内未接收到来自第一目标从设备的应答报文，是指，主设备向第一目标从设备发送第一请求报文之后，未收到第一目标从设备的任何响应。换言之，主设备向第一目标从设备发送第一请求报文之后，总线一直被第一应用程序占用，但是，总线上并未出现任何有效数据。若第一应用程序为自身设置了一个很长的对总线的占用时间，那么，在第一应用程序设置的对总线的占用时间未达到时，总线一直处于等待第一目标从设备发送应答报文的状态。对于这种情况，首先，其它应用程序不能利用总线与其它从设备进行通信，从而影响了其它应用程序的通信及时性。其次，总线在一段时间内实际上并未用于传输数据，从而造成了总线利用率低的问题。

因此，在本申请实施例中，若从第一请求报文发送的时刻开始计时，在第一预设时间段内未接收到来自第一目标从设备的应答报文，则主设备就认为对第一请求报文的处理已经结束，可以处理下一条请求报文。

也就是说，在本申请实施例中，由主设备为第一应用程序设置对总线的占用时间，而并不是由应用程序自身设置对总线的占用时间，从而使得在第一目标从设备接收到主设备发送第一请求报文之后，未做出任何响应的情况下，释放第一应用程序占用的总线，利用该总线处理待发送队列中的其它待发送请求报文，而不是使总线一直处于等待接收第一目标从设备发送应答报文的状态。

第二种情况，总线向第一目标从设备发送第一请求报文之后，在第二预设时间段内获取到应答报文的帧尾。

可以理解的是，第一目标从设备发送应答报文时，一般会预先将发送的应答报文封装好，然后通过总线发送该封装好的应答报文。一般来讲，应答报文中会包含一个结束标志，即应答报文的帧尾。若第一目标从设备已经通过总线将帧尾发送出去，则表示该应答报文已经发送完毕。鉴于此，判断第一应用程序和第一目标从设备之间的通信已经完成，可以对接收到的应答报文进行解析，获取应答报文的帧尾，若获取到应答报文的帧尾，则说明应答报文已经发送完毕。换言之，若总线获取到的应答报文中包含应答报文的帧尾，则说明第一应用程序和第一目标从设备之间的通信已经完成。此时，第一应用程序应该将其占用的总线释放，以便其他应用程序利用该总线和对应的从设备通信。

若第一应用程序为自身设置了一个很长的对总线的占用时间，那么，即使第一应用程序和第一目标从设备之间的通信已经完成，第一应用程序也不会主动释放该总线，从而导致其它应用程序不能利用总线通信，进而影响了其它应用程序的通信及时性。

因此，在本申请实施例中，若总线向第一目标从设备发送第一请求报文之后，在第二预设时间段内获取到了来自第一目标从设备发送的应答报文的帧尾。则主设备就认为对第一请求报文的处理已经结束，可以处理下一条请求报文。也就是说，从第一请求报文发送的时刻开始计时，若在第二预设时间段内获取到应答报文的帧尾，则主设备就认为对第一请求报文的处理已经结束，可以处理下一条请求报文。需要说明的是，之所以限定在第二预设时间段内获取到来自第一目标从设备发送的应答报文的帧尾，是为了避免总线被第一应用程序占用的时间过长。从而影响其它应用程序的通信及时性。例如，第一请求报文的数据量很大，导致发送该第一请求报文的时间很长；或者，第一目标从设备发送的应答报文数据量很大，导致发送该应答报文的时间过长。故而，总线一直被第一应用程序占用，从而无法处理其它应用程序的待发送请求报文。

也就是说，在本申请实施例中，主设备向第一目标从设备发送第一请求报文，并获取到了来自第一目标从设备发送的应答报文的帧尾之后，主设备即控制第一应用程序释放其占用的总线，从而可以利用该总线处理待发送队列中的其它待发送请求报文。避免了第一应用程序长时间占用总线的问题。

第三种情况，从获取到应答报文中一个最小传输单位的数据的时刻开始计时，在第三预设时间段内未接收到下一个最小传输单位的数据。

可以理解的是，如前文所述，第一目标从设备发送应答报文时，可以预先将发送的应答报文封装好，然后通过总线发送该封装好的应答报文。因此，该封装好的应答报文在总线上传输时是连续的，该封装好的报文中在总线上传输的两个相邻最小传输单位的数据之间的时间间隔应该比较小。相应的，主设备获取到两个相邻最小传输单位的数据之间的时间间隔应该比较小。换言之，若主设备获取到两个相邻最小传输单位的数据之间的时间间隔比较大，则可以认为接收到的两个相邻最小传输单位的数据并非是同一条应答报文中的数据。也就是说，若从主设备获取到应答报文中其中一个最小传输单位的数据的时刻开始计时，在第三预设时间段内未获取到下一个最小传输单位的数据，则说明总线针对第一请求报文的应答报文的处理已经完成。例如，第一目标从设备将应答报文进行封装，封装后的应答报文包括10字节。第一目标从设备将这10个字节的应答报文数据通过总线发送出去，应答报文的最小传输单位的数据为一字节数据，因此，这10个字节数据在总线上传输时，两个相邻字节数据之间的发送时间间隔应该比较小，主设备获取到两个相邻字节数据之间的时间间隔也比较小。若主设备获取到两个相邻字节数据的时间间隔比较大，可以认为主设备获取到的两个相邻字节数据并非是同一条应答报文中的数据。也就是说，若从主设备获取到应答报文中其中一个字节数据的时刻开始计时，在第三预设时间段内未获取到下一字节数据，则说明总线对该应答报文的处理已经完成。

本申请实施例中的第三预设时间段为预先设置的，本申请实施例对该第三预设时间段的具体取值不做限定，该预设时间段的具体取值可以根据总线的波特率确定，也可以根据其它条件确定。

需要说明的是，本申请实施例不具体限定最小传输单位的数据，虽然上文中以最小传输单位的数据为字节数据来进行说明，但这并不构成对本申请实施例的限定，本申请实施例中提及的最小传输单位的数据还可以为比特数据，也可以为双字节数据等。

第一预设条件需要说明的是，本申请实施例中，判断应答时间是否满足第一预设条件，是为了判断总线是否处理完了第一请求报文。其中，第一预设条件是指，第一请求报文和第一目标从设备针对该第一请求报文发送的应答报文不被允许继续占用总线时对应的条件；或，第一请求报文和第一目标从设备针对该第一请求报文发送的应答报文不再需要继续占用总线时对应的条件。

本申请实施例中提及的应答时间，是指，与第一目标从设备针对第一请求报文发送应答报文相关的时间。

在一种可能的实现方式中，本申请实施例中的应答时间，包括：应答报文等待时间。

应答报文等待时间，是指，等待第一目标从设备向主设备发送应答报文的时间。也就是说，从第一请求报文发送的时刻开始计时，记录从第一请求报文发送的时刻到接收到第一目标从设备发送的应答报文的时刻之间的时间。相应的，应答时间满足第一预设条件，具体为：从第一请求报文发送的时刻开始计时，若在第一预设时间段内未接收到应答报文，则该应答时间满足第一预设条件。可以理解的是，当应答时间为应答报文等待时间时，该应答时间满足第一预设条件，表示主设备向第一目标从设备发送第一请求报文之后，在第一预设时间段内未收到第一目标从设备的任何响应。此时，可以认为总线已经处理完了第一请求报文，即不允许为了处理第一请求报文再占用总线。

需要说明的是，关于应答时间为应答报文等待时间，且应答时间满足第一预设条件时，以认为总线已经处理完了第一请求报文部分的具体描述可以参考步骤201中“第一种情况”中的描述部分，在此不再赘述。

在另一种可能的实现方式中，本申请实施例中的应答时间，包括：帧尾获取时间。

本申请实施例中提及的帧尾获取时间，是指，从第一请求报文发送的时刻开始计时，到获取到应答报文的帧尾时刻之间的时间，即发送第一请求报文和接收第一目标从设备发送的应答报文的总时间。具体地，当应答时间为帧尾获取时间时，应答时间满足第一预设条件，是指，从第一请求报文发送的时刻开始计时，在第二预设时间段内获取到应答报文的帧尾。也就是说，当获取到应答报文的帧尾之后，就不需要为处理第一请求报文继续占用总线了。

需要说明的是，判断是否获取到了来自第一目标从设备发送的应答报文的帧尾的描述可以参考参考以上“第二种情况”中的描述部分，在此不再赘述。

需要说明的是，关于应答时间为帧尾获取时间，且应答时间满足第一预设条件时，可以认为总线已经处理完了第一请求报文部分的具体描述可以参考以上“第二种情况”中的描述部分，在此不再赘述。

在又一种可能的实现方式中，本申请实施例中的应答时间，包括：最小传输单位获取间隔时间。

本申请实施例中提及的最小传输单位获取间隔时间，是指，从获取到应答报文中一个最小传输单位的数据的时刻开始计时，直到未接收到下一个最小传输单位的数据之间的时间。具体地，当应答时间为最小传输单位获取间隔时间时，应答时间满足第一预设条件，是指，从获取到应答报文中一个最小传输单位的数据的时刻开始计时，在第三预设时间段内未接收到下一个所述最小传输单位的数据。

需要说明的是，关于应答时间为最小传输单位获取间隔时间，且应答时间满足第一预设条件时，可以认为总线已经处理完了第一请求报文部分的具体描述可以参考以上“第三种情况”中的描述部分，在此不再赘述。

步骤202中判断应答时间满足第一预设条件之后，执行步骤203。

步骤203：判断待发送队列中是否存在第二请求报文；如果待发送队列中存在第二请求报文，执行步骤204；若待发送队列中不存在第二请求报文，则结束流程。

步骤204：调用总线驱动接口向第二目标从设备发送第二请求报文，其中，第二请求报文为待发送队列中与第一请求报文相邻的后一个请求报文。

步骤204中提及的“总线驱动接口”与步骤201中提及的“总线驱动接口”相同，具体描述可以参考步骤201中关于“总线驱动接口”的描述，在此不再赘述。

关于步骤203和204，需要说明的是，当总线已经处理完了第一请求报文时，表示第一应用程序已经将其占用的总线释放，从而其它应用程序可以利用该总线与其它的从设备进行通信。也就是说，当待发送队列中存在第二请求报文时，即可利用总线向第二目标从设备发送第二请求报文。

在本申请实施例中，第二请求报文为第二应用程序通过总线发送给第二目标从设备的请求报文，也就是说，第二请求报文来自于第二应用程序，第二请求报文的既定接收方为第二目标从设备。需要说明的是，在本申请实施例中，第一应用程序和第二应用程序可以是同一个应用程序，也可以是不同的应用程序。本申请实施例对此不做限定。第一目标从设备和第二目标从设备可以是同一个从设备，也可以是不同的从设备，本申请实施例对此不做限定。

如前文所述，主设备将待发送的请求报文进行排序，将排序后的待发送请求报文存储在待发送队列中，以便于总线处理完第一请求报文之后，根据待发送队列中的待发送请求报文，确定下一条待处理的请求报文。而第二请求报文为待发送队列中与第一请求报文相邻的后一个请求报文，故而，总线处理完第一请求之后，即可确认第二请求报文为下一条待处理的请求报文。

本申请实施例提供的通信方法，当主设备通过总线将待发送队列中的第一请求报文发送给第一目标从设备时，监控第一目标从设备针对第一请求报文发送的应答报文的应答时间。若该应答时间满足第一预设条件，则判断报文发送序列中是否存在第二请求报文，若存在，则向第二目标从设备发送第二请求报文。也就是说，利用本申请实施例提供的通信方法，当满足不再允许或不再需要为了处理第一请求报文而需要占用主线的第一预设条件时，主设备自动将第一应用程序占用的总线释放，以便主设备中安装的其它应用程序使用该总线。从而避免了主设备中安装的某个应用程序对总线的占用时间过长，从而影响其它应用程序的通信及时性的问题，提高用户体验。

如前文所述，在本申请实施例中，若主设备中安装有多个应用程序，当存在多条请求报文需要利用总线传输时，主设备可以将待发送的请求报文进行排序，将排序后的待发送请求报文存储在待发送队列中。以便于总线处理完待发送队列中的第一请求报文之后，根据待发送队列中的待发送请求报文，确定下一条处理的请求报文。以下将介绍主设备将待发送的待发送请求报文进行排序，并将排序后的待发送请求报文存储在待发送队列中的具体实现方法。

如前文所述，当应用程序需要利用总线向对应的从设备发送请求报文时，可以先将待发送的请求报文发送给主设备，由主设备对待发送的请求报文进行排序，并将排序后的待发送请求报文存储在待发送队列中。

一般来讲，对多个请求报文进行排序，可以按照主设备接收到应用程序发送的待发送请求报文的时间排序。主设备获取到应用程序发送的待发送请求报文的时间越早，该待发送请求报文在多个待发送请求报文中的排序越靠前，该待发送请求报文通过总线发送至对应的从设备的时间越早。例如，可结合图1进行理解，主设备100于11:30分接收到应用程序110发送的请求报文1，主设备100于当天11:31分接收到应用程序120发送的请求报文2，主设备100于当天11:32分接收到应用程序110发送的请求报文3。则按照主设备100接收到三个待发送请求报文的时间顺序对这三个待发送请求报文进行排序，排序结果为请求报文1、请求报文2、请求报文3。并将请求报文1、请求报文2和请求报文3存储在待发送队列中。当总线处理完上一条请求报文之后，再处理请求报文1，总线处理完请求报文1之后，再处理请求报文2，总线处理完请求报文2之后，再处理请求报文3。

可以理解的是，在实际应用中，一方面，主设备上安装的各个应用程序的重要程度不同，另一方面，各个待发送请求报文的紧急程度不同。因此，若只是按照主设备接收到应用程序发送的请求报文的时间对待发送请求报文进行排序，一方面，不能优先处理重要应用程序对应的待发送请求报文，另一方面，不能优先处理紧急程度高的待发送请求报文。

鉴于此，在本申请实施例中，应用程序在向主设备发送待发送请求报文时，可以根据该待发送请求报文的紧急程度和/或重要程度设置该待发送请求报文的优先级，以便于主设备根据该待发送请求报文的优先级确定该待发送请求报文在多个待发送请求报文中的排序位置，进而确定该待发送请求报文在待发送队列中的存储位置。具体地，应用程序向主设备发送待发送请求报文时，可以将该待发送请求报文的优先级添加到该待发送请求报文中，以便于主设备获取该请求报文的优先级。从而确定该待发送请求报文在多个待发送请求报文中的排序位置，进而确定该待发送请求报文在待发送队列中的存储位置。

但是，考虑到实际应用中，可能存在应用程序恶意竞争总线，将待发送的请求报文的优先级设置的很高，以达到其发送的待发送请求报文被优先处理的目的。鉴于此，在本申请实施例中，主设备接收到应用程序发送的待发送请求报文之后，可以对该待发送请求报文中携带的优先级进行验证，判断该优先级是否在合理的优先级范围内。所谓该优先级在合理的优先级范围内，是指，该优先级在主设备为该应用程序设置的优先级范围之内。并根据对待发送请求报文中携带的优先级验证的结果确定该待发送请求报文在多个待发送请求报文中的排序位置，进而确认该待发送请求报文在待发送队列中的存储位置。

当在主设备中为应用程序设置优先级范围之后，主设备存储该应用程序标识与优先级范围之间的对应关系。因此，为了便于主设备根据应用程序发送的待发送请求报文确定该应用程序对应的优先级范围，应用程序向主设备发送待发送请求报文时，可以将其自身的标识添加到该待发送请求报文中，即，该应用程序向主设备发送的待发送请求报文中，携带有该应用程序的标识，以便于主设备根据该待发送请求报文中携带的应用程序标识，以及该应用程序标识和优先级范围的映射关系，确定该应用程序的优先级范围。

以第一应用程序利用总线向第一目标从设备发送第一请求报文为例进行说明。首先，第一应用程序在安装时，主设备为第一应用程序设置一个优先级范围，并保存第一应用层程序标识和第一应用程序优先级范围之间的映射关系。当第一应用程序向主设备发送第一请求报文时，在第一请求报文中添加该第一请求报文的优先级以及第一应用程序的标识，即第一请求报文中携带有第一请求报文的优先级以及第一应用程序的标识。主设备接收到该第一请求报文之后，获得第一请求报文中携带的第一应用程序的标识，利用第一应用程序的标识和第一应用程序的优先级范围之间的对应关系获取第一应用程序的优先级范围，并判断第一请求报文中携带的第一请求报文的优先级是否在第一应用程序的优先级范围之内，若第一请求报文中携带的第一请求报文的优先级在第一应用程序的优先级范围之内，说明该第一请求报文中携带的第一请求报文的优先级在合理的优先级范围之内。此时，可以根据第一请求报文中携带的第一请求报文的优先级确定第一请求报文在多个待发送请求报文中的排序位置，从而确定第一请求报文在待发送队列中的存储位置。若第一请求报文中携带的第一请求报文的优先级不在第一应用程序的优先级范围之内，则主设备可以为该第一请求报文设置一个在合理优先级范围内的优先级，并根据主设备为该第一请求报文设置的优先级确定第一请求报文在多个待发送请求报文中的排序位置，从而确定第一请求报文在待发送队列中的存储位置。

本申请实施例不具体限定主设备为第一请求报文设置在合理优先级范围内的优先级的具体取值，作为一种示例，主设备可以设置第一应用程序对应的优先级范围中的最高优先级作为第一请求报文的优先级。

需要说明的是，在本申请实施例中，若待发送请求报文的优先级相同，则可以根据主设备接收到待发送请求报文的时间顺序对待发送请求报文进行排序，从而确定待发送请求报文在待发送队列中的存储位置。

需要说明的是，在本申请实施例中，待发送请求报文在待发送队列中的存储位置，可以表征待发送请求报文在多个待发送请求报文中的排序位置。但是，本申请实施例不具体限定待发送队列的实现方式，例如可以是链表结构。

为方便理解，以下结合具体实例和对本申请实施例提供的主设备将待发送的请求报文进行排序，并将排序后的待发送请求报文存储在待发送队列中的方法进行介绍。

11:30时，待发送队列中的最后一条待发送请求报文正在通过总线发送给相应的从设备，即当前总线处于被占用状态。主设备100于11:31分接收到应用程序110发送的请求报文4，主设备100于当天11:32分接收到应用程序120发送的请求报文5，主设备100于当天11:32分接收到应用程序110发送的请求报文6。其中，请求报文4、请求报文5以及请求报文6中携带的优先级均在合理的优先级范围内，且请求报文4的优先级为5级，请求报文5的优先级为6级，请求报文6的优先级为5级，优先级数值越大，表示优先级越高。则当主设备接收到请求报文4时，由于请求报文4是唯一一条待发送请求报文，故主设备将请求报文4排在待发送请求报文中的第一位；当主设备接收到请求报文5时，由于请求报文5的优先级高于请求报文4，故而主设备将请求报文5排在待发送请求报文中的第一位，将请求报文4排在待发送请求报文中的第二位；当主设备接收到请求报文6时，由于请求报文6的优先级低于请求报文5，故而请求报文6排在请求报文5之后，又因为请求报文6的优先级和请求报文4的优先级相同，但主设备接收到请求报文4的时间比接收到6请求报文的时间早，故而。主设备将请求报文6排在请求报文4之后，即主设备将请求报文5排在待发送请求报文中的第一位，将请求报文4排在待发送请求报文的第二位，将请求报文6排在待发送请求报文的第三位。并根据这三个待发送请求报文的排序确定这三个待发送请求报文在待发送队列中的存储位置。

需要说明的是，对于第一请求报文而言，以上介绍的主设备将第一请求报文进行排序，并将排序后的第一请求报文存储在待发送队列中的具体实现方法，可以在步骤201之前执行。也就是说，在本申请实施例中，当第一请求报文中携带有第一请求报文的优先级时，在步骤201主设备通过总线向第一目标从设备发送待发送队列中的第一请求报文之前，还可以包括步骤A和步骤B。

步骤A：主设备获取与第一请求报文对应的目标应用程序的目标优先级范围。

步骤B：若第一请求报文的优先级在目标应用程序的目标优先级范围内，则根据第一请求报文的优先级确定第一请求报文在待发送队列中的存储位置。

具体地，步骤A在具体实现时，主设备可以根据第一请求报文中携带的目标应用程序的标识，以及目标应用程序标识与目标应用程序的优先级范围之间的映射关系，得到目标应用程序的目标优先级范围。

其中，第一请求报文对应的目标应用程序是指，向主设备发送第一请求报文的应用程序，即，第一应用程序。目标应用程序的目标优先级范围，是指，主设备为目标应用程序设置的优先级范围。即，第一应用程序的优先级范围。目标应用程序的标识，是指，第一应用程序的标识，可以用于唯一标识第一应用程序。

需要说明的是，若第一请求报文的优先级不在第一应用程序的目标优先级范围之内，则主设备可以为该第一请求报文重新确认一个在目标优先级范围内的优先级，并根据主设备为该第一请求报文重新确认的优先级确定第一请求报文在多个待发送请求报文中的排序位置，从而确定第一请求报文在待发送队列中的存储位置。

比如说，第一请求报文的优先级为6，不在第一应用程序的目标优先级范围(1-3)之内时，可以将预先设定的一个在第一应用程序的目标优先级范围内的优先级，例如2，作为该第一请求报文重新确认的优先级。

本申请实施例提供的主设备将待发送的请求报文进行排序，并将排序后的待发送请求报文存储在待发送队列中的方法，考虑了应用程序重要程度和/或待发送请求报文的紧急程度来对待发送请求报文进行排序，从而使得重要应用程序对应的待发送请求报文能够被优先处理，和/或，紧急程度高的待发送请求报文也能够被优先处理。

如前文所述，一条总线上可以连接一个主设备和多个从设备。当主设备上安装有多个应用程序时，用户期望各个应用程序只能通过总线和被授权的从设备通信。例如，可结合图1进行理解，用户期望应用程序110智能利用RS-485总线300和从设备210通信，而不能和其它从设备进行通信；应用程序120只能利用RS-485总线300和从设备220通信，而不能和其它从设备进行通信；应用程序130可以利用RS-485总线300和从设备230通信，而不能和其它从设备进行通信；应用程序140既智能利用RS-485总线300和从设备240通信以及从设备250通信，不能和从设备210、从设备220以及从设备230通信。

鉴于此，在本申请实施例中，主设备在接收到应用程序发送的待发送请求报文时，还可以验证该待发送的请求报文是否是向该应用程序授权的从设备发送的。若该待发送地请求报文是向该应用程序授权的从设备发送的，才通过总线将该待发送请求报文发送给对应的从设备。也就是说，在本申请实施例中，在步骤201之前，还可以包括步骤301至步骤303。

步骤301：获取第一请求报文对应的目标应用程序的通信地址集合，该通信地址集合中至少包括一个与目标应用程序通信的从设备的通信地址。

本申请实施例中提及的第一请求报文对应的目标应用程序是指，向主设备发送第一请求报文的应用程序，即，第一应用程序。目标应用程序的通信地址集合，是指该目标应用程序的授权从设备的通信地址的集合。可以理解的是，目标应用程序的授权从设备可以为一个从设备，也可以为多个从设备。当目标应用程序的授权的从设备为1个时，目标应用程序的通信地址集合中包括该授权的一个从设备的通信地址，当目标应用程序的授权的从设备为多个时，目标应用程序的通信地址集合中包括授权的多个从设备的通信地址。例如，可结合图1进行理解，若目标应用程序为应用程序110，则目标应用程序的通信地址集合中包括从设备210的通信地址；若目标应用程序为应用程序140，则目标应用程序的通信地址集合中包括从设备240的通信地址以及从设备250的通信地址。

需要说明的是，在步骤301的一种可能的实现方式中，主设备在安装目标应用程序时，可以根据目标应用程序的配置信息确定该目标应用程序的授权的从设备的通信地址，并保存目标应用程序的通信地址集合和目标应用程序的标识的映射关系。当主设备接收到第一请求报文时，可以获取第一请求报文中携带的目标应用程序的标识，并根据目标应用程序的标识和目标应用程序的通信地址集合的映射关系，获得第一请求报文对应的目标应用程序的通信地址集合。

步骤302：从第一请求报文中解析得到第一目标从设备的通信地址。

步骤303：判断第一目标从设备的通信地址是否存在于目标应用程序的通信地址集合中，若存在，则执行步骤201；如果否，则执行步骤304，即丢弃第一请求报文。

关于步骤302和步骤303，需要说明的是，一般来讲，第一请求报文中携带有第一目标从设备的通信地址，以便第一目标从设备根据该第一请求报文中携带的第一目标从设备的通信地址，确认该第一请求报文是发送给第一目标从设备的请求报文，从而对该第一请求报文做出响应。

当主设备从第一请求报文中解析得到第一目标从设备的通信地址之后，若该第一目标从设备的通信地址存在于目标应用程序的通信地址集合中，则说明第一目标从设备是目标应用程序的授权的从设备。故而，可以执行步骤201，通过总线向第一目标从设备发送第一请求报文。若该第一目标从设备的通信地址不存在于目标应用程序的通信地址集合中，则说明第一目标从设备不是目标应用程序的授权的从设备，也就是说，目标应用程序不能和第一目标从设备进行通信，此时，可以丢弃该第一请求报文。

需要说明的是，在实际应用中，目标应用程序与第一目标从设备进行通信时，发送的第一请求报文需要符合一定的报文发送规则。如果目标应用程序未按照规定的报文发送规则向第一目标从设备发送第一请求报文，即使第一请求报文通过总线发送出去，第一目标从设备也不能正确解析该第一请求报文，从而导致目标应用程序和第一目标从设备通信失败。

在本申请实施例中，目标应用程序的报文发送规则可以包括：帧头、帧尾、帧长度、目标应用程序的标识、第一目标从设备的通信地址等信息中的部分或全部信息，以及具体的组帧方式。本申请实施例不具体限定目标应用程序的报文发送规则，具体报文发送规则可以根据目标应用程序的具体类型确定。

因此，步骤302在具体实现时，主设备可以先获取目标应用程序对应的报文发送规则，判断第一请求报文的报文发送规则是否满足目标应用程序对应的报文发送规则，如果是，则从第一请求报文中解析得到第一目标从设备的通信地址。

主设备获取目标应用程序对应的报文发送规则的方式与主设备获取目标应用程序的通信地址集合的方式类似，即主设备在安装目标应用程序时，预先保存目标应用程序标识和目标应用程序对应的报文发送规则之间的映射关系，主设备接收到第一请求报文之后，获取第一请求报文中携带的目标应用程序标识，利用目标应用程序标识和目标应用程序对应的报文发送规则之间的映射关系，得到目标应用程序对应的报文发送规则。

本申请实施例提供的方法，主设备可以对应用程序发送的待发送的请求报文进行验证，只有当待发送的请求报文是向该应用程序授权的从设备发送的，才通过总线将该待发送请求报文发送给对应的从设备。若待发送的请求报文不是向该应用程序授权的从设备发送的，则丢弃该待发送请求报文，以便于其他待发送请求报文利用总线与对应的从设备通信。提高总线利用率和其它应用程序的通信及时性。

需要说明的是，在实际应用中，当主设备安装有多个应用程序时，一般来讲，各个应用程序对通信资源的使用情况应该比较均匀，很少出现一些应用程序过多的占用通信资源的情况，若一些应用程序过多的占用通信资源，则该应用程序可能是流氓应用程序，应该禁止该流氓应用程序继续占用通信资源。鉴于此，在本申请实施例中，主设备还可以监控通信资源的使用情况，当发现流氓应用程序时，禁止该流氓应用程序继续占用通信资源。

以监控第一请求报文对应的应用程序是否为流氓应用为例，介绍主设备监控通信资源的使用情况的具体方法。该方法可以通过步骤401到步骤402实现。

步骤401：统计在第四预设时间段内发送第一请求报文对应的通信资源使用信息。

需要说明的是，本申请实施例中提及的通信资源使用信息是指，为了发送第一请求报文而对通信资源进行使用的信息。例如，通信资源使用信息可以为第一请求报文的数据量、针对第一请求报文发送的应答报文的数据量、从第一请求报文被发送之后到停止获取该应答报文所花费的时间、从开始获取该应答报文到停止获取该应答报文所花费的时间，以及在第一请求报文被发送的次数等中的一种或多种。

其中，第一请求报文的数据量可以是第一请求报文的字节总数；应答报文的数据量可以是应答报文的字节总数；从第一请求报文被发送之后到停止获取该应答报文所花费的时间，是指，第一请求报文对应的应用程序与第一目标从设备完成一次交互所使用的时间，可以表征第一请求报文对应的应用程序与第一目标从设备交互时对总线的占用情况；从开始获取该应答报文到停止获取该应答报文所花费的时间，是指，第一目标从设备发送应答报文所使用的时间，可以表征第一目标从设备发送应答报文时对总线的占用情况；第一请求报文被发送的次数，是指，总线用于发送第一请求报文的次数，可以表征第一请求报文对应的应用程序使用总线的频率。

需要说明的是，本申请实施例不具体限定第四预设时间段，第四预设时间段可以根据实际情况具体设置。例如，第四预设时间段所占的时间长度为1小时，第四预设时间段可以为上午10:00至当天上午11:00、上午11:00至当天上午12:00等等；又如，第四预设时间段所占的时间长度为1小时，第四预设时间段为从发送第一请求报文时开始计时，直到累计计时为1小时之间的时间段。

可以理解的是，为了避免过多的占用存储资源，在统计得到在第四预设时间段内发送第一请求报文对应的通信资源使用信息之后，可以将该通信资源使用信息删除。

步骤402：若在第四预设时间段内发送第一请求报文对应的通信资源使用信息满足不合理使用条件，则禁止与第一请求报文对应的应用程序利用总线再次发送第一请求报文。

可以理解的是，在第四预设时间段内发送第一请求报文对应的通信资源使用信息满足不合理使用条件，可以是该通信资源使用信息超过了预设阈值。例如，在第四预设时间段内发送第一请求报文对应的通信资源使用信息满足不合理使用条件，可以是第一请求报文的总数据量大于第一预设数据量阈值；又如，在第四预设时间段内发送第一请求报文对应的通信资源使用信息满足不合理使用条件，可以是针对第一请求报文发送的应答报文的总数据量大于第二预设数据量阈值；再如，在第四预设时间段内发送第一请求报文对应的通信资源使用信息满足不合理使用条件，可以是从第一请求报文被发送之后到停止获取该应答报文所花费的总时间大于第一预设时间阈值；再如，在第四预设时间段内发送第一请求报文对应的通信资源使用信息满足不合理使用条件，可以是从开始获取该应答报文到停止获取该应答报文所花费的总时间大于第二预设时间阈值；再如，在第四预设时间段内发送第一请求报文对应的通信资源使用信息满足不合理使用条件，可以是第一请求报文被发送的次数大于预设次数阈值。

需要说明的是，对于发送其他请求报文时对应的通信资源信息的统计方法，与发送第一请求报文时对应的对通信资源信息地统计方法相同；对应的，判断发送其他请求报文对应的应用程序是否过多占用通信资源的方法，与判断发送第一请求报文对应的应用程序是否过多占用通信资源的方法相同；当发送其他请求报文对应的应用程序过多占用通信资源时的处理措施，与发送第一请求报文对应的应用程序过多占用通信资源时的处理措施相同。在此不再一一赘述。

由此可见，本申请实施例提供的方法，主设备还可以监控通信资源的使用情况，当发现流氓应用程序时，禁止该流氓应用程序继续占用通信资源。

可以理解的是，在实际应用中，主设备上安装的应用程序和对应的从设备进行通信时，可能会出现异常情况。例如，由于从设备故障导致总线一直被不合理占用。此时，主设备还可以针对该异常情况执行相应的处理措施。

具体地，在一种可能的实现方式中，可以从第一请求报文发送的时刻开始计时，若在第二预设时间段内未接收到完整的应答报文，则进行记录、报警和/或累计未接收到完整的应答报文的次数。

需要说明的是，若从第一请求报文发送的时刻开始计时，在第二预设时间段内未接收到完整的应答报文。则说明，总线被第一应用程序占用的时间过长。总线被第一应用程序占用的时间过长的原因有多种。

第一种原因：第一应用程序发送的第一请求报文的数据量很大，导致发送该应答报文的时间过长。故而，总线一直被第一应用程序占用。

第二种原因：第一目标从设备发送的应答报文数据量很大，导致发送该应答报文的时间过长。故而，总线一直被第一应用程序占用。

第三种原因：第一请求报文发送完成之后，第一目标从设备没有立即响应，导致第一目标从设备发送的响应报文未在第二预设时间段内发送完成。

无论是以上三种原因中的哪一种导致第一应用程序对总线的不合理占用，都会导致其它应用程序无法使用总线与对应的从设备进行通信，从而影响了其它应用程序的通信及时性。

因此，在本申请实施例中，对于这种总线被不合理占用的异常情况，在第一种可能的实现方式中，主设备可以对该异常情况进行记录，例如，记录该异常情况对应的第一应用程序的标识、第一请求报文、该第一请求报文对应的第一目标从设备的标识以及第一目标从设备针对第一请求报文发送的应答报文等信息，以便于对总线异常情况进行维护修复时，通过查看该记录信息，从而确定引起总线异常的原因。

在第二种可能的实现方式中，主设备可以报警，以提示用户总线出现异常，以便于用户及时对总线异常情况进行处理。

在第三种可能的实现方式中，主设备可以累计未接收到第一目标从设备针对第一请求报文发送的完整的应答报文的次数，从而确定第一应用程序导致总线异常的次数。

在第四种可能的实现方式中，主设备可以禁止第一应用程序利用总线与第一目标从设备进行通信，从而防止第一应用程序利用总线进行通信从而导致总线异常。

需要说明的是，当第一应用程序不合理的占用总线时，主设备可以将以上四种实现方式全部执行，也可以执行以上四种实现方式中的一种或多种实现方式，对此，本申请实施例不做具体限定。

需要说明的是，关于如何判断是否接收到了来自第一目标从设备发送的完整的应答报文，可以参考上文中“第二种情况”中的描述部分，在此不再赘述。

以上内容对本申请实施例提供的通信方法进行了描述，请结合图5进行理解，图5为本申请实施例提供的一个应用场景示意图。在该场景下，主设备100为物联网关，网关与多个从设备通过RS-485总线300进行通信，从设备分别为从设备260、从设备270、从设备280和从设备290。物联网关100上安装有多个应用程序，分别为应用程序511、应用程序512、应用程序521和应用程序522。

需要说明的是，物联网关100上安装的多个应用程序可能是由不同的厂商开发的，故而各个应用程序的稳定性和安全性可能不同。故而，在实际应用中，物联网关100往往将应用程序安装到虚拟机中，与物联网关的主系统530隔离，从而防止因为应用程序的缺陷引发主系统530故障。

容器技术是一种常用的将应用程序安装到虚拟机中的技术。容器技术是指，将物联网关中的一部分资源划分出来，用于安装应用程序，这些被划分出来的资源可以形成一个容器，可结合图5进行理解，图5中的510是一个容器，520也是一个容器。容器510和容器520中分别有自己的虚拟文件系统以及相关的资源设备。在物联网关100中，安装了两个容器510和520，容器510和520分别安装了两个应用程序，其中，容器510中安装了应用程序511和应用程序512，容器520中安装了应用程序521和应用程序522。这四个应用程序均需要访问RS-485通信接口。

图5中，容器510中的“RS-485设备驱动”513和容器520中的“RS-485设备驱动”523全部映射到主系统中的“虚拟RS-485设备驱动”531，也就是说，容器510和520中没有真正实现RS-485设备驱动，而是引用了主系统中的“虚拟RS-485设备驱动”531的实现，因此，对容器中的“RS-485设备驱动”513的接口调用，实际上调用的是主系统中“虚拟RS-485设备驱动”531的对应接口。

本申请实施例提供的交互方法，可以由图5中所述的“虚拟RS-485设备驱动”531实现。在该场景下，待发送队列中存储有两条待发送请求报文，分别为第一请求报文和第二请求报文。第一请求报文存储在第二请求报文之前。第一请求报文为应用程序511发送给第一目标从设备260的请求报文，第二请求报文为应用程序521发送给第二目标从设备290的请求报文。下面结合图5所示的应用场景以及图6对本申请实施例提供的通信方法进行描述。

步骤601：虚拟RS-485设备驱动531根据第一请求报文中携带的目标应用程序(即应用程序511)的标识，确定目标应用程序对应的报文发送规则，并确定第一请求报文满足该报文发送规则。

步骤602：虚拟RS-485设备驱动531从第一请求报文中解析得到第一目标从设备的通信地址；根据第一请求报文中携带的目标应用程序的标识，确定目标应用程序的通信地址集合，确定第一目标从设备260的通信地址存在于第一目标应用程序的通信地址集合中。

步骤603：虚拟RS-485设备驱动531调用传统RS-485设备驱动532，利用RS-485总线300向第一目标从设备260发送第一请求报文。

步骤604：第一目标从设备260解析接收到的第一请求报文，确定第一请求报文是发送给自身的请求报文。

步骤605：第一目标从设备260利用RS-485总线300向目标应用程序发送应答报文。

步骤606：虚拟RS-485设备驱动531从获取到该应答报文中其中一个最小传输单位的数据的时刻开始计时，在第三预设时间段内未接收到下一个最小传输单位的数据，确定应答报文接收完毕。

步骤607：虚拟RS-485设备驱动531在待发送队列中查询到第二请求报文。

步骤608：虚拟RS-485设备驱动531调用传统RS-485设备驱动532，利用RS-485总线300向第二目标从设备290发送第二请求报文。

需要说明的是，传统RS-485设备驱动532可以实现将待发送请求报文进行格式转换，转换成符合RS-485通信协议的数据，并通过RS-485总线300发送出去的功能。

需要说明的是，以上场景实施例只是一种示例性的说明，本申请实施例提供的通信方法还可以应用于其它场景，在此不再一一列举说明。

需要说明的是，虽然在以上场景中，应用程序安装在容器中，但是，本申请实施例提供的方法，并不限于以上场景，应用程序不安装在容器中时，依然适用本申请实施例的方案。

为便于更好的实施本申请实施例的上述方案，下面还提供用于实施上述方案的相关装置。

请参考图7所示，本申请实施例提供的一种通信装置700，该通信装置700具体对应于上述提供的通信方法的功能。该通信装置700的功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的单元，单元可以是软件和/或硬件。该装置700可以包括：第一请求报文发送单元710和应答报文获取单元720。

第一请求报文发送单元710，用于调用总线驱动接口将待发送队列中的第一请求报文发送给第一目标从设备；

应答报文获取单元720，用于获取第一目标从设备针对第一请求报文发送的应答报文的应答时间，若应答时间满足第一预设条件，且发送队列中存在第二请求报文，则调用总线驱动接口向第二目标从设备发送第二请求报文，第二请求报文为待发送队列中与第一请求报文相邻的后一个请求报文。

在一种可能的实现中，第一预设条件，包括：

从第一请求报文发送的时刻开始计时，在第一预设时间段内未接收到应答报文；

或者，

从第一请求报文发送的时刻开始计时，在第二预设时间段内获取到应答报文的帧尾；

或者，

从获取到应答报文中一个最小传输单位的数据的时刻开始计时，在第三预设时间段内未接收到下一个最小传输单位的数据。

在一种可能的实现中，第一请求报文中包括第一请求报文的优先级；

该装置700还包括：

存储位置确定单元，用于在第一请求报文被发送之前，根据第一请求报文的优先级确定第一请求报文在待发送队列中的存储位置。

在一种可能的实现中，第一请求报文中还包括目标应用程序的标识，存储位置确定单元，具体用于

根据目标应用程序的标识，以及应用程序标识与优先级范围之间的对应关系，得到目标应用程序的目标优先级范围；

当第一请求报文的优先级在目标优先级范围内时，根据第一请求报文的优先级确定第一请求报文在待发送队列中的存储位置。

在一种可能的实现中，装置700还包括：通信地址集合获取单元，通信地址解析单元；

通信地址集合获取单元，用于获取第一请求报文对应的目标应用程序的通信地址集合，通信地址集合包括至少一个与目标应用程序通信的从设备的通信地址；

通信地址解析单元，用于从第一请求报文中解析得到第一目标从设备的通信地址；

第一请求报文发送单元710，用于当第一目标从设备的通信地址存在于通信地址集合中时，执行通过总线将待发送队列中的第一请求报文发送给第一目标从设备的步骤。

在一种可能的实现中，通信地址解析单元包括：报文发送规则获取子单元和通信地址获得子单元；

报文发送规则获取子单元，用于获取目标应用程序对应的报文发送规则；

报文发送规则获取子单元，用于当第一请求报文符合报文发送规则时，从第一请求报文中解析得到第一目标从设备的通信地址。

在一种可能的实现中，装置700还包括：资源使用信息统计单元和禁止使用总线单元；

资源使用信息统计单元，用于统计在第四预设时间段内发送第一请求报文对应的通信资源使用信息；

禁止使用总线单元，用于当通信资源使用信息满足不合理使用条件时，禁止与第一请求报文对应的应用程序利用总线再次发送第一请求报文。

在一种可能的实现中，通信资源使用参数至少包括以下任意一种：

第一请求报文的数据量、应答报文的数据量、从第一请求报文被发送之后到停止获取应答报文所花费的时间、从开始获取应答报文到停止获取应答报文所花费的时间，以及第一请求报文被发送的次数。

在一种可能的实现中，若在第二预设时间段内未接收到完整的应答报文，则装置700还包括：记录单元；

记录单元，用于进行记录、报警和/或累计未接收到完整的应答报文的次数。

利用本申请实施例提供的通信装置，当满足不再允许或不再需要为了处理第一请求报文而需要占用主线的第一预设条件时，主设备自动将第一应用程序占用的总线释放，以便主设备中安装的其它应用程序使用该总线。从而避免了主设备中安装的某个应用程序对总线的占用时间过长，从而影响其它应用程序的通信及时性的问题，提高用户体验。

需要说明的是，上述装置各模块/单元之间的信息交互、执行过程等内容，由于与本申请实施例方法实施例基于同一构思，其带来的技术效果与本申请实施例方法实施例相同，具体内容可参见本申请实施例前述所示的方法实施例中的叙述，此处不再赘述。

接下来介绍本申请实施例中的通信设备。请参阅图8所示，通信设备800包括：处理器810、通信接口820和和存储器830。其中通信设备800中的处理器810的数量可以一个或多个，图8中以一个处理器为例。本申请实施例中，处理器810、通信接口820和存储器830可通过总线系统或其它方式连接，其中，图8中以通过总线系统840连接为例。

处理器810可以是中央处理器(central processing unit，CPU)，网络处理器(network processor，NP)或者CPU和NP的组合。处理器810还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路(application-specific integrated circuit，ASIC)，可编程逻辑器件(programmable logic device，PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(complex programmable logic device，CPLD)，现场可编程逻辑门阵列(field-programmable gate array，FPGA)，通用阵列逻辑(generic array logic,GAL)或其任意组合。

在申请实施例中，通信接口820可以为支持RS-485通信协议的通信接口。通信接口820可以集成接收和发送数据报文的功能。

存储器830可以包括易失性存储器(英文：volatile memory)，例如随机存取存储器(random-access memory，RAM)；存储器830也可以包括非易失性存储器(英文：non-volatile memory)，例如快闪存储器(英文：flash memory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)；存储器410还可以包括上述种类的存储器的组合。

存储器830用于存储待发送队列，第一预设时间，第二预设时间，第三预设时间等。

可选地，存储器830存储有操作系统和程序、可执行模块或者数据结构，或者它们的子集，或者它们的扩展集，其中，程序可包括各种操作指令，用于实现各种操作。操作系统可包括各种系统程序，用于实现各种基础业务以及处理基于硬件的任务。处理器810可以读取存储器830中的程序，实现本申请实施例提供的通信方法。

总线系统840可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。总线系统840可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。本申请实施例还提供一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行以上方法实施例提供的通信方法。

本申请实施例还提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行以上方法实施例提供的通信方法。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (16)

1.一种通信方法，其特征在于，所述方法应用于主设备，所述方法包括：

调用总线驱动接口将待发送队列中的第一请求报文发送给第一目标从设备；

获取所述第一目标从设备针对所述第一请求报文发送的应答报文的应答时间，若所述应答时间满足第一预设条件，且所述发送队列中存在第二请求报文，则调用所述总线驱动接口向第二目标从设备发送所述第二请求报文，所述第二请求报文为所述待发送队列中与所述第一请求报文相邻的后一个请求报文。

2.根据权利要求1所述的方法，其特征在于，所述第一预设条件，包括：

从所述第一请求报文发送的时刻开始计时，在第一预设时间段内未接收到所述应答报文；

或者，

从所述第一请求报文发送的时刻开始计时，在第二预设时间段内获取到所述应答报文的帧尾；

或者，

从获取到所述应答报文中一个最小传输单位的数据的时刻开始计时，在第三预设时间段内未接收到下一个所述最小传输单位的数据。

3.根据权利要求1所述的方法，其特征在于，所述第一请求报文中包括所述第一请求报文的优先级；

在所述第一请求报文被发送之前，所述方法还包括：

根据所述第一请求报文的优先级确定所述第一请求报文在所述待发送队列中的存储位置。

4.根据权利要求3所述的方法，其特征在于，所述第一请求报文中还包括目标应用程序的标识，所述根据所述第一请求报文的优先级确定所述第一请求报文在所述待发送队列中的存储位置包括：

根据所述目标应用程序的标识，以及应用程序标识与优先级范围之间的对应关系，得到所述目标应用程序的目标优先级范围；

若所述第一请求报文的优先级在所述目标优先级范围内，则根据所述第一请求报文的优先级确定所述第一请求报文在所述待发送队列中的存储位置。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取所述第一请求报文对应的目标应用程序的通信地址集合，所述通信地址集合包括至少一个与所述目标应用程序通信的从设备的通信地址；

从所述第一请求报文中解析得到所述第一目标从设备的通信地址；

若所述第一目标从设备的通信地址存在于所述通信地址集合中，则执行所述通过总线将待发送队列中的第一请求报文发送给第一目标从设备的步骤。

6.根据权利要求5所述的方法，其特征在于，所述从所述第一请求报文中解析得到所述第一目标从设备的通信地址包括：

获取所述目标应用程序对应的报文发送规则；

若所述第一请求报文符合所述报文发送规则，则从所述第一请求报文中解析得到所述第一目标从设备的通信地址。

7.根据权利要求1所述的方法，其特征在于，所述方法还包括：

统计在第四预设时间段内发送所述第一请求报文对应的通信资源使用信息；

若所述通信资源使用信息满足不合理使用条件，则禁止与所述第一请求报文对应的应用程序利用所述总线再次发送所述第一请求报文。

8.根据权利要求7所述的方法，其特征在于，所述通信资源使用参数至少包括以下任意一种：

所述第一请求报文的数据量、所述应答报文的数据量、从所述第一请求报文被发送之后到停止获取所述应答报文所花费的时间、从开始获取所述应答报文到停止获取所述应答报文所花费的时间，以及所述第一请求报文被发送的次数。

9.根据权利要求2所述的方法，其特征在于，若在第二预设时间段内未接收到完整的所述应答报文，则所述方法还包括：

进行记录、报警和/或累计未接收到完整的应答报文的次数。

10.一种通信装置，其特征在于，所述装置应用于主设备，所述装置包括：

第一请求报文发送单元，用于调用总线驱动接口将待发送队列中的第一请求报文发送给第一目标从设备；

应答报文获取单元，用于获取所述第一目标从设备针对所述第一请求报文发送的应答报文的应答时间，若所述应答时间满足第一预设条件，且所述发送队列中存在第二请求报文，则调用所述总线驱动接口向第二目标从设备发送所述第二请求报文，所述第二请求报文为所述待发送队列中与所述第一请求报文相邻的后一个请求报文。

11.根据权利要求10所述的装置，其特征在于，所述第一预设条件，包括：

从所述第一请求报文发送的时刻开始计时，在第一预设时间段内未接收到所述应答报文；

或者，

从所述第一请求报文发送的时刻开始计时，在第二预设时间段内获取到所述应答报文的帧尾；

或者，

从获取到所述应答报文中一个最小传输单位的数据的时刻开始计时，在第三预设时间段内未接收到下一个所述最小传输单位的数据。

12.根据权利要求10所述的装置，其特征在于，所述第一请求报文中包括所述第一请求报文的优先级；

所述装置还包括：

存储位置确定单元，用于在所述第一请求报文被发送之前，根据所述第一请求报文的优先级确定所述第一请求报文在所述待发送队列中的存储位置。

13.根据权利要求12所述的装置，其特征在于，所述第一请求报文中还包括目标应用程序的标识，所述存储位置确定单元包括：目标优先级范围得到子单元和存储位置确定子单元；

所述目标优先级范围得到子单元，用于根据所述目标应用程序的标识，以及应用程序标识与优先级范围之间的对应关系，得到所述目标应用程序的目标优先级范围；

所述目标优先级范围得到子单元，用于当所述第一请求报文的优先级在所述目标优先级范围内时，根据所述第一请求报文的优先级确定所述第一请求报文在所述待发送队列中的存储位置。

14.根据权利要求10所述的装置，其特征在于，所述装置还包括：通信地址集合获取单元，通信地址解析单元；

所述通信地址集合获取单元，用于获取所述第一请求报文对应的目标应用程序的通信地址集合，所述通信地址集合包括至少一个与所述目标应用程序通信的从设备的通信地址；

所述通信地址解析单元，用于从所述第一请求报文中解析得到所述第一目标从设备的通信地址；

所述第一请求报文发送单元，用于当所述第一目标从设备的通信地址存在于所述通信地址集合中时，执行所述通过总线将待发送队列中的第一请求报文发送给第一目标从设备的步骤。

15.根据权利要求14所述的装置，其特征在于，所述通信地址解析单元，具体用于

获取所述目标应用程序对应的报文发送规则；

当所述第一请求报文符合所述报文发送规则时，从所述第一请求报文中解析得到所述第一目标从设备的通信地址。

16.根据权利要求10所述的装置，其特征在于，所述装置还包括：资源使用信息统计单元和禁止使用总线单元；

所述资源使用信息统计单元，用于统计在第四预设时间段内发送所述第一请求报文对应的通信资源使用信息；

所述禁止使用总线单元，用于当所述通信资源使用信息满足不合理使用条件时，禁止与所述第一请求报文对应的应用程序利用所述总线再次发送所述第一请求报文。