一种协议的调度使用方法及装置与流程

本发明属于车载以太网技术领域，尤其涉及一种协议的调度使用方法及装置。

背景技术：

随着智能驾驶技术的发展，以太网技术，特别是基于以太网的中间件技术在智能驾驶领域中的应用越来越多，其中，zeromq由于其自身的高性能、分布式、跨平台等特性，使其在众多中间件技术中脱颖而出，广泛的应用于智能驾驶的研发，测试等过程。

在传统的汽车领域中，用户如果需要在智能驾驶控制算法的研发过程中使用zeromq协议栈，通常需要根据zeromq的开源代码，通过编写相应的调用逻辑代码来调度和使用zeromq协议栈。然而，智能驾驶的控制算法通常基于matlabsimulink开发，而zeromq协议栈是基于c++语言代码实现的，matlab与传统的c/c++在语法(如指针的定义、数据类型等方面)、约束等方面均存在相应差异，这就导致zeromq协议栈在传统汽车行业中的应用并不太友好，存在zeromq协议栈在使用过程中调用复杂易出错、对从业人员的编码能力要求高等问题。

从而，如何提供一个在一种环境(如上述的matlab环境)中对基于另一种环境(如上述的c++环境)实现的协议栈进行使用的解决方案，以使得将该基于另一种环境所实现的协议栈的使用过程简洁化，友好化，成为当前亟待解决的技术问题。

技术实现要素：

有鉴于此，本发明的目的在于提供一种协议的调度使用方法及装置，以解决在一种环境中使用基于另一种环境的协议栈时存在的调用复杂易出错、对从业人员的编码能力要求高等问题，使得将该基于另一种环境所实现的协议栈的调用过程简洁化，友好化。

为此，本发明公开如下技术方案：

一种协议的调度使用方法，包括：

获取图形接口上配置的界面参数；

基于所述界面参数，按相应的处理流程调用第一自封装接口；

基于所述第一自封装接口，调用与所述第一自封装接口对应的n个第一协议接口；

其中，所述图形接口和所述第一自封装接口为预先构建的，所述第一自封装接口中包括所述n个第一协议接口间的调度关系，n为大于等于1的整数；

所述图形接口基于第一环境实现，所述第一自封装接口和所述第一协议接口基于第二环境实现。

上述方法，优选的，所述图形接口包括：用于发送数据信息的发送接口和用于接收数据信息的接收接口；

所述发送接口的数量为至少一个，用于分别向相同或不同的端口发送消息报文；

所述接收接口的数量为至少一个，用于分别接收相同或不同的端口传输的消息报文。

上述方法，优选的，所述消息报文为预先按照json文件形式所定义的消息格式；

所述消息格式包括消息头及消息体，所述消息头包括数据总线类型、数据传输的通道及数据类型中的一种或多种，所述消息体包括消息形成时间的时间戳、节点名称、数据收发类型、节点的互联网协议地址、数据传输的端口号、数据包的长度及有效荷载信息中的一种或多种。

上述方法，优选的，所述图形接口还包括：配置接口，所述配置接口与所述端口一一对应；

所述配置接口用于生成数据信息传输所需的端口描述符；所述端口描述符或所述端口描述符的地址信息存放在全局内存中，以供具有相同端口需求的至少一个发送接口共享使用。

上述方法，优选的，所述发送接口发送消息报文，包括：

从全局内存中获取所述端口描述符，或者，从全局内存中获取所述端口描述符的地址信息并基于所述地址信息获取所述端口描述符；

基于所述端口描述符，利用相应协议将所述消息报文发送至所需的端口。

上述方法，优选的，所述从全局内存中获取所述端口描述符的地址信息，包括：

获得所需的端口描述符的标识信息；

从全局内存中获取对应于所述标识信息的端口描述符的地址信息，所述地址信息的数据类型为对应于所述第一环境的第一数据类型；

将所述地址信息的数据类型转换为第二数据类型，所述第二数据类型为对应于所述第二环境的第二数据类型。

上述方法，优选的，所述第一环境包括matlab环境，所述第二环境包括c++环境。

一种协议的调度使用装置，包括：

获取单元，用于获取图形接口上配置的界面参数；

第一调用单元，用于基于所述界面参数，按相应的处理流程调用第一自封装接口；

第二调用单元，用于基于所述第一自封装接口，调用与所述第一自封装接口对应的n个第一协议接口；

其中，所述图形接口和所述第一自封装接口为预先构建的，所述第一自封装接口中包括所述n个第一协议接口间的调度关系，n为大于等于1的整数；

所述图形接口基于第一环境实现，所述第一自封装接口和第一协议接口基于第二环境实现。

上述装置，优选的，所述图形接口包括：用于发送数据信息的发送接口和用于接收数据信息的接收接口；

所述发送接口的数量为至少一个，用于分别向相同或不同的端口发送消息报文；

所述接收接口的数量为至少一个，用于分别接收相同或不同的端口传输的消息报文。

上述装置，优选的，所述图形接口还包括：配置接口，所述配置接口与所述端口一一对应；

所述配置接口用于生成数据信息传输所需的端口描述符；所述端口描述符或所述端口描述符的地址信息存放在全局内存中，以供具有相同端口需求的至少一个发送接口共享使用。

由以上方案可知，本发明提供的协议的调度使用方法及装置，预先构建了图形接口及第一自封装接口，所构建的第一自封装接口包括n个(大于等于1的整数)第一协议接口间的调度关系信息；所述图形接口基于第一环境实现，所述第一自封装接口、第一协议接口基于第二环境实现；在此基础上，可基于图形接口的形式配置所需的各界面参数，并通过对自封装接口的调用来实现对所需的一个或多个协议接口的调用。由此可见，本发明实现了对协议调用的图形化操作，并实现了将预定协议栈中各协议接口的复杂的调度关系信息封装为更简洁的自封装接口，从而可使得不必在第一环境中编写对第二环境的原始协议栈的各协议接口的复杂调用代码，仅对更为简洁的自封装接口进行调用代码的设计即可，大大降低了对协议栈使用的难度及出错率，降低了对从业人员的编码能力要求，可使得所述第二环境的协议栈的使用过程更为简洁化，友好化。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1是本发明实施例提供的协议的调度使用方法的一种流程图；

图2是本发明实施例提供的发送接口、自封装接口及zeromq协议栈的各协议接口间的调用关系示意图；

图3是本发明实施例提供的适用于汽车行业的can报文信息的一种消息格式示例；

图4是本发明实施例提供的zeromq协议栈图形化的实现过程示意图；

图5是本发明实施例提供的发送接口发送消息报文的实现流程示意图；

图6(a)是多个发送接口需同时向同一个端口发送数据时所造成的端口冲突的情况示意图；

图6(b)是本发明实施例提供的通过创建的配置接口实现多个发送接口同时向同一个端口发送数据的示意图；

图7是本发明实施例提供的基于本发明的三类图形接口及自封装接口对zeromq协议接口进行调用进而使用zeromq协议的原理示意图；

图8是本发明实施例提供的协议的调度使用装置的一种结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明提供了一种协议的调度使用方法及装置，旨在解决汽车领域中在第一环境(如matlab环境等)中使用基于第二环境实现的协议栈(如基于c++环境实现的zeromq协议栈等，其中，zeromq协议栈所包括的协议及对应的协议接口均基于c++环境实现)时所存在的调用复杂易出错、对从业人员的编码能力要求高等问题，使得将协议栈的使用过程简洁化，友好化，该方法及装置可适用于但不限于基于采集的整车数据对智能驾驶的控制算法进行开发、测试及验证的应用场景中，以下将通过具体实施例，对本发明的协议的调度使用方法及装置进行详述。

参考图1，为本发明实施例提供的协议的调度使用方法的一种流程图，在本实施例中，如图1所示，所述协议的调度使用方法包括以下处理过程：

步骤101、获取图形接口上配置的界面参数。

本实施例将主要以在matlab环境(智能驾驶的控制算法研发所常用的环境)中对基于c++环境实现的zeromq协议栈进行调度使用为例，对本发明的方案进行说明，其中，zeromq指的是类似于socket的一系列接口，主要用于数据传输。

为了使得将zeromq等协议栈的使用过程简洁化，友好化，本发明预先在第一环境如matlab环境的相应软件工具(如matlabsimulink)中构建了多个面向zeromq协议栈的图形接口s-function，对应于在使用所述zeromq协议栈对数据进行传输时的数据收(接收)、发(发送)两种类型，所述图形接口至少包括以下两种：

1)用于发送数据信息的发送接口(sfunc_zmqtransmit)

所述发送接口的数量为至少一个，用于分别向相同或不同的端口发送消息报文。

2)用于接收数据信息的接收接口(sfunc_zmqrcv)

所述接收接口的数量为至少一个，用于分别接收相同或不同的端口传输的消息报文。

在具体实施中，每种类型的图形接口可根据实际需要预先构建一个或多个，所述发送接口及所述接收接口分别提供有多个界面参数，以供用户在具备数据信息的处理需求(如对数据信息的发送处理需求或接收处理需求等)时进行配置，其中，所述发送接口(sfunc_zmqtransmit)及所述接收接口(sfunc_zmqrcv)所提供的各界面参数及各界面参数的相关描述信息、来源信息具体可参考以下表1所提供的示例：

表1

当用户需使用相应图形接口时，可基于相应操作调用所需的图形接口，所调用的图形接口可以是所述发送接口或所述接收接口。

在调用所需的图形接口后，可由用户进一步根据实际需求在所调用的图形接口上进行界面参数的配置，以所调用的图形接口为发送接口为例，则可获得在该发送接口上配置的上述表1中的ip(internetprotocol，互联网协议)地址、端口、传输超时参数、消息类型、通道、消息id(identity，身份标识号码)、消息大小等各个界面参数的参数值，其中，各界面参数的参数值具体可采用json配置文件的方式进行配置获取。

所获取的各界面参数的参数值可在对数据信息进行传输处理(如发送数据信息或接收数据信息)时使用。

其中，所接收的数据信息可以是来自汽车的整车数据，所述整车数据可以包括但不限于汽车上的各监控部件(雷达、摄像头等)所提供的can数据报文或ethernet数据报文，所发送的数据信息可以是利用开发的相应控制算法对所述整车数据进行相关处理后所得的结果数据。

步骤102、基于所述界面参数，按相应的处理流程调用第一自封装接口；其中，所述图形接口和所述第一自封装接口为预先构建的，所述第一自封装接口中包括所述n个第一协议接口间的调度关系，n为大于等于1的整数。

具体地，本申请预先构建了至少一个自封装接口，每个自封装接口包括：预定协议栈的至少一个协议接口间的调度关系信息，且每个自封装接口基于所述第二环境如c/c++环境实现；所述处理流程包括多个处理环节，所述多个处理环节中的至少一个环节需要对预先构建的自封装接口中的第一自封装接口进行调用；所述第一自封装接口为基于所述界面参数，按相应的处理流程处理至相应环节时，该环节所需调用的自封装接口。

第一协议接口为与第一自封装接口有对应关系的n个协议接口。所述至少一个第一协议接口间的调度关系信息，可以包括但不限于所述与所述第一自封装接口对应的n个协议接口间的引用关系信息和/或先后执行顺序信息。所述处理流程可以是数据发送处理流程或者数据接收处理流程，以发送数据为例，根据matlab提供的约束，所述数据处理流程可以包括图形接口运行时的资源配置(mdlsetupruntimeresources)、初始化(mdlstart)、数据信息的输出发送(mdloutputs)、图形接口运行时的资源释放(mdlcleanruntimeresources)及结束(mdlstop)这几个处理环节。

在上述各处理环节中的至少一个环节需通过调用zeroqm协议栈中的相应协议来实现该环节的处理，例如，上述的图形接口运行时的资源配置(mdlsetupruntimeresources)环节需调用zeroqm协议栈中的mq::init()(初始化)及zmq::bind()(绑定)这两个协议api(applicationprogramminginterface,应用程序编程接口)来实现该环节所需的处理；数据信息的输出发送(mdloutputs)环节需调用zeroqm协议栈中的zmq::poll()(超时等待)、zmq::encode_header()(头文件编码)、zmq::encode_data()(数据编码)、zmq::send()(发送)这几个协议api来实现该环节所需的处理；图形接口运行时的资源释放(mdlcleanruntimeresources)环节需调用mq::close()(关闭)协议api来实现该环节所需的处理等等。

智能驾驶的控制算法通常基于matlabsimulink开发，而zeromq协议是基于c++语言代码实现的，matlab与传统的c/c++在语法(如指针的定义、数据类型等方面)、约束等方面均存在相应差异，这就导致zeromq协议栈在传统汽车行业中的应用并不太友好。具体表现为：一方面，zeromq协议栈给出的api接口形式(即协议接口)不一定便于matlab的图形接口s-function调用；另一方面，matlab的图形接口s-function可能会调用zeromq协议栈的多个api接口，从而使得调用过程显得繁琐。

另外，s-function作为matlab环境下的图形接口，不仅要求用户熟悉s-function的框架，还存在编码约束以及数据类型的使用方面的诸多限制，从开发的易用性和可维护性角度考虑，尽量不要对s-function作过多修改，基于这些方面的考虑，为了使得在matlab环境下对基于c++环境实现的zeromq协议栈的协议调用更加方便简洁，本发明提出了对zeromq协议栈的协议接口基于c++环境进行进一步api自封装的技术思路，并具体基于zeromq协议栈的各协议接口之间的逻辑关联，将关联较强的各协议接口封装为一体形成一个自封装接口(自封装api)，且在自封装接口中体现了各协议接口之间的引用关系和/或先后执行顺序等调度关系信息，最终得到分别封装有至少一个协议接口及其调度关系信息的多个自封装接口。具体地，比如，可将上述的图形接口运行时的资源配置(mdlsetupruntimeresources)环节所需调用的mq::init()及zmq::bind()这两个协议api及其调度关系信息封装为一体得到自封装接口zmqserveron()，将数据信息的输出发送(mdloutputs)环节所需调用的zmq::poll()、zmq::encode_header()、zmq::encode_data()、zmq::send()这几个协议api封装为一体得到自封装接口zmqsend()，将图形接口运行时的资源释放(mdlcleanruntimeresources)环节需调用的mq::close()这一协议api封装为一个自封装接口zmqserveroff()等等。

在将zeromq协议栈的各协议接口进一步封装为各个自封装接口的基础上，当在matlab环境下进行发送接口(sfunc_zmqtransmit)、接收接口(sfunc_zmqrcv)等的图形接口设计时，仅需在其中设计对相应自封装接口(基于c++环境实现)的调用代码即可，而不必再对zeromq协议栈的各协议接口(基于c++环境实现)的复杂调用代码进行设计；且无论是zeromq协议栈修改还是升级，仅需对zeromq自身协议接口进行修改和/或对自封装接口的相关代码进行修改即可，而不需要修改图形接口s-function的代码，由此，将zeromq协议栈的协议接口进一步自封装的优势显而易见。

参考以下的表2，表2示出了发送接口(sfunc_zmqtransmit)的各处理环节所对应的自封装接口，以及各自封装接口所对应封装的zeroqm协议栈的各协议接口：

表2

具体的，当所述处理流程包括的处理环节需调用协议栈如zeromq协议栈的相应协议接口时，本发明并不直接对调用过程进行代码的编写和修改，而是调用对应于所需协议接口的第一自封装接口，以处理环节为资源配置(mdlsetupruntimeresources)环节为例，则执行至该环节时具体调用所述zmqserveron()自封装接口，同理，若所述需调用自封装接口的相应环节为所述数据信息的输出发送(mdloutputs)环节，则执行至该环节时具体调用zmqsend()自封装接口，若所述需调用自封装接口的环节为所述图形接口运行时的资源释放(mdlcleanruntimeresources)环节，则执行至该环节时具体调用所述zmqserveroff()自封装接口。

步骤103、基于所述第一自封装接口，调用与所述第一自封装接口对应的n个第一协议接口。

如上表2所示，以第一自封装接口为zmqserveron()为例，此时第一协议接口包括两个，分别是zmq::init()和zmq::bind()。

第一自封装接口中同时包括了n个第一协议接口间的调度关系信息，参考图2示出的发送接口、自封装接口及zeromq协议栈的各协议接口间的调用关系示意图，可通过调用所述相应环节需调用的第一自封装接口，来进一步实现对所述需调用的第一自封装接口中所对应的各个第一协议接口的调用，参考表2，以所述相应环节为所述数据信息的输出发送(mdloutputs)为例，则通过对所述zmqsend()的调用，可进一步实现对所述zeromq协议栈的zmq::poll()、zmq::encode_header()、zmq::encode_data()、zmq::send()这几个协议接口的调用，进而可基于对这几个协议接口的调用，实现对所需的超时等待、头文件编码、数据编码、数据发送等协议的使用。

以上述表2所示的zmqsend()这一自封装接口为例，若不采用此自封装接口，则在利用发送接口(sfunc_zmqtransmit)进行数据发送时，必然需先调用zeromq协议栈的zmq::poll()协议接口，然后再依次调用协议栈的zmq::encode_header()、zmq::encode_data()、zmq::send()等协议接口来依次实现头文件编码、数据编码及数据发送等处理，显然协议接口的调用较为繁琐，调用代码相应较复杂，另外为了满足超时等待的特性，还需要在matlab的图形接口s-function中加入对事件event的判断逻辑代码，从而牵涉到了额外的代码量，除此之外，在matlab的图形接口s-function中直接调用这些协议接口，还需要在图形接口s-function中额外添加这些协议接口的头文件，这会使得图形接口对协议接口的整个调用过程的设计较复杂，而采用本发明的上述自封装技术思路对协议栈的各协议接口进行上述自封装后，能够很好的解决这些问题。

基于以上方案可知，本实施例实现了对协议调用的图形化操作，并实现了将预定协议栈中各协议接口的复杂的调度关系信息封装为了更为简洁的自封装接口，从而可使得不必在第一环境中编写对第二环境的原始协议栈的各个协议接口的复杂调用代码，仅对更为简洁的自封装接口进行调用代码的设计即可，大大降低了对协议栈使用的难度及出错率，降低了对从业人员的编码能力要求，可使得所述第二环境的协议栈的使用过程更为简洁化，友好化。

在本发明的一可选实施例中，所述发送接口在发送消息报文时，具体将待发送的数据信息封装为预定义格式的消息报文，并发送所述消息报文。

zeromq协议栈是顶层协议栈，为了保证其普适性，对消息的定义比较抽象，没有定义规范的数据字段的类型，以及其解析方式和方法，在实际应用时需要用户自行定义。具体地，在实际应用中，用户只需要定义消息的ip地址，源端口和目的端口，即可以进行数据的收发，对于数据的具体业务内容并不做规范，本发明为了使得zeromq消息能够更好地适应汽车行业开发常用的数据类型，如can报文，以及ethernet报文等，采用json文件对zeromq传输的消息进行了格式自定义。

can报文通常会包含如下属性：

·can_channel/can通道：无规范；

·can_id/can报文id：小于3字节(can标准帧)；

·can_msg_dlc/can报文长度：1字节；

·can_datapayload/can报文数据内容：1～8字节；

ethernet报文通常会包含如下属性：

·eth_channel/eth通道：无规范；

·eth_pdu_id/pdu报文id：4字节；

·eth_pdu_length/pdu报文长度：4字节；

·eth_pdu_datapayload/pdu数据内容：0～1464字节。

根据以上特性，进行抽象，可以将zeromq消息格式定义为包括消息头及消息体。

以汽车行业通用的can报文信息为例，可以将json文件中的zeromq消息的各字段定义为包括但不限于以下字段中的一种或多种：

·<nodename>：节点名称；

·<nodetype>：发送或是接收；

·<endpoint>：节点ip地址；

·<port>：数据传输的端口号；

·<bustype>：数据总线类型；

·<channel>：数据传输的通道；

·<id>：数据类型，can数据或者以太网数据；

·<payloadsize>：数据包的长度；

·<payload>：有效荷载信息；

·<timestamp>：消息形成时间的时间戳；

其中，可将上述各字段中的<bustype>、<channel>及<id>中的一种或多种设计在消息头中，而剩余各字段即<nodename>、<nodetype>、<endpoint>、<port>、<payloadsize>、<payload>及<timestamp>中的一种或多种则可设计在消息体中，参考图3，图3示出了本发明所定义的适用于汽车行业的can报文信息的一种消息格式示例。

在对zeromq的消息报文进行上述格式定义的基础上，对数据信息进行处理时，通过调用所述相应环节需调用的自封装接口实现了对相应协议接口的调用后，可基于相应协议对所述数据信息进行处理，如进行延时等待、编码处理等，并最终将处理结果封装为上述预定义格式的消息报文，进而发送所述消息报文，例如将利用相应控制算法对整车数据进行相关处理后所得的结果数据从当前pc机按所述预定义格式发送至用于对所述结果数据进行测试、验证的pc机上等。

具体实施中，如图4所示，可通过制作json配置文件(用于描述zeromq消息)、制作图形接口s-function、针对协议栈的协议接口进行自封装接口的构建等，最终能够通过调用自封装接口调用协议接口、进而进行数据处理，可使得zeromq的消息格式能够更好地适配传统汽车行业的常用通信数据格式(如can/以太网pdu)要求。

在实际应用场景中，matlab环境下的所述发送接口的数量可能为多个，进一步可能会存在多个发送接口需同时向同一个端口发送数据的情况，如图6(a)所示，发送接口s-function1需要向ip地址为1.2.3.4、端口号为1001的端口发送数据msg1和数据msg2，而同时发送接口s-function2同样需要向该ip地址为1.2.3.4、端口号为1001的端口发送数据msg3和数据msg4，然而，受限于matlab的图形接口s-function的资源共享机制，在发送数据时，一个s-function创建一个供自身可见的porthandle(端口描述符，为一个c++对象，在发送数据时需使用该端口描述符)后，另一个s-function则不能够再创建相同的porthandle，由此，当多个发送接口需同时向同一个端口发送数据时，会造成端口的冲突。

为了解决该问题，在本发明的一可选实施例中，还提供了一种用于生成数据信息传输时所需的端口描述符的配置接口(sfunc_zmqsetup)，也即，所述预先构建的图形接口还可以包括所述配置接口，所述配置接口同样提供有多个可配置的界面参数，示例性地，所述配置接口的界面参数可以包括但不限于节点ip地址、端口等参数，参考以下的表3，以下表3示例性提供了本实施例的配置接口及上文所提供的两类接口(发送接口、接收接口)的界面参数及其描述信息、来源信息：

表3

所述配置接口的数量与各个发送接口发送数据时对应所需的端口数量相同，以图6(a)的示例为例，由于发送接口s-function1及发送接口s-function2对应一个端口，从而如图6(b)所示，可以针对s-function1、s-function2，创建一个配置接口，该所创建的配置接口提供为s-function1、s-function2创建端口描述符porthandle的功能，并能将所创建的porthandle或所创建的porthandle的地址信息存放于matlab的全局内存中，由于配置接口所创建的porthandle或所创建的porthandle的地址信息存放于matlab的全局内存中，从而所存放的porthandle或porthandle的地址信息对于各发送接口如所述s-function1及s-function2均是可见的，可供所述s-function1及s-function2共享使用。

具体地，所述端口描述符porthandle标识信息可定义为由所需端口的ip地址和端口号组成的字符串，在此基础上，如图6(b)所示，可进一步采用一写功能函数如mxsetdata()函数将此porthandle或此porthandle的地址信息写入到matlab的全局内存(workspacememory)中。

在本发明的一可选实施例中，参考图5示出的发送接口发送消息报文的实现流程示意图，所述发送接口具体可以通过以下的处理过程实现对消息报文的发送：

步骤501、从全局内存中获取所述端口描述符，或者，从全局内存中获取所述端口描述符的地址信息并基于所述地址信息获取所需的端口描述符；

步骤502、基于所述端口描述符，利用相应协议接口所对应的协议将所述消息报文发送至所需的端口。

当需要向某一端口发送数据信息时，如需要利用发送接口将控制算法的处理结果信息对应的消息报文从当前pc机发送至用于对所述处理结果进行测试、验证的另一pc机的端口时，则可根据所需端口的porthandle的标识信息从matlab的全局内存中获取所需的端口描述符，或者，可根据所需端口的porthandle的标识信息从matlab的全局内存中获取所需的porthandle的地址信息，进而基于所述地址信息获取所需的porthandle，在此基础上，最终可基于所述porthandle，利用zeromq协议栈中的相应协议将所述消息报文发送至所需的端口；其中，所述端口描述符的标识信息可以是但不限于端口描述符的全局唯一标识。

需要说明的是，matlab的全局内存中所存储的porthandle地址信息的数据类型为适用于matlab环境的第一数据类型，而所获取的porthandle的地址信息最终是供c++环境下zeromq协议栈中的相应协议使用的，从而需将porthandle的地址信息的数据类型，由匹配于matlab环境的第一数据类型转换为匹配于c++环境的、可供zeromq协议使用的第二数据类型。

参考图7，图7示出了基于本发明所提供的上述三类图形接口及所提供的自封装接口对zeromq协议接口进行调用进而使用zeromq协议的原理示意图。

本实施例通过创建用于生成数据信息传输所需的端口描述符的配置接口，并将配置接口所创建的端口描述符或端口描述符的地址信息存放于matlab的全局内存中，解决了matlab环境下多个发送接口需同时向同一个端口发送数据时的端口冲突问题，可有效实现matlab环境中在多个发送接口同时向同一个端口发送数据。

对应于上述的协议的调度使用方法，本发明实施例还提供了一种协议的调度使用装置，参考图8示出的协议的调度使用装置的结构示意图，该装置可以包括：

获取单元801，用于获取图形接口上配置的界面参数；

第一调用单元802，用于基于所述界面参数，按相应的处理流程调用第一自封装接口；

第二调用单元803，用于基于所述第一自封装接口，调用与所述第一自封装接口对应的n个第一协议接口；

其中，所述图形接口和所述第一自封装接口为预先构建的，所述第一自封装接口中包括所述n个第一协议接口间的调度关系，n为大于等于1的整数；

所述图形接口基于第一环境实现，所述第一自封装接口、第一协议接口基于第二环境实现。

在本发明实施例的一可选实施方式中，所述图形接口包括：用于发送数据信息的发送接口和用于接收数据信息的接收接口；所述发送接口的数量为至少一个，用于分别向相同或不同的端口发送消息报文；所述接收接口的数量为至少一个，用于分别接收相同或不同的端口传输的消息报文。

在本发明实施例的一可选实施方式中，所述消息报文为预先按照json文件形式所定义的消息格式；

所述消息格式包括消息头及消息体，所述消息头包括数据总线类型、数据传输的通道、数据类型中的一种或多种，所述消息体包括消息形成时间的时间戳、节点名称、数据收发类型、节点的互联网协议地址、数据传输的端口号、数据包的长度及有效荷载信息中的一种或多种。

在本发明实施例的一可选实施方式中，所述图形接口还包括：配置接口，所述配置接口与所述端口一一对应；

所述配置接口用于生成数据信息传输所需的端口描述符；所述端口描述符或所述端口描述符的地址信息存放在全局内存中，以供具有相同端口需求的至少一个发送接口共享使用。

在本发明实施例的一可选实施方式中，所述发送接口发送消息报文，包括：

从全局内存中获取所需的端口描述符，或者，从全局内存中获取所需的端口描述符的地址信息并基于所述地址信息获取所需的端口描述符；

基于所述端口描述符，利用相应协议接口所对应的协议将所述消息报文发送至所需的端口。

在本发明实施例的一可选实施方式中，所述发送接口从全局内存中获取所需的端口描述符的地址信息，包括：

获得所述端口描述符的标识信息；

从全局内存中获取对应于所述标识信息的端口描述符的地址信息，所述地址信息的数据类型为对应于所述第一环境的第一数据类型；

将所述地址信息的数据类型转换为第二数据类型，所述第二数据类型为对应于所述第二环境的第二数据类型。

对于本发明实施例公开的协议的调度使用装置而言，由于其与上文各实施例公开的协议的调度使用方法相对应，所以描述的比较简单，相关相似之处请参见上文各实施例中协议的调度使用方法部分的说明即可，此处不再详述。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

为了描述的方便，描述以上系统或装置时以功能分为各种模块或单元分别描述。当然，在实施本发明时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。

最后，还需要说明的是，在本文中，诸如第一、第二、第三和第四等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。