CN117193092A - 工控设备之间的数据互联方法、装置和工控设备 - Google Patents

Abstract

本申请提供了工控设备之间的数据互联方法、装置和工控设备，工控设备被部署至少一服务，以一工控设备运行的服务为获取数据的目标服务，相对数据的获取，运行目标服务的工控设备为数据接收端，发送数据的其他工控设备则为数据发送端，工控设备之间数据互联的方法包括，数据发送端在自身所部署的服务中获取待传递数据，数据有适用的通信模式，数据发送端根据通信模式，向数据接收端发送待传递数据，目标服务获取数据接收端所接收的待传递数据，完成工控设备之间的数据互联。本申请通过自身所被部署的服务进行数据互联，从而实现交互，解决了当前各领域依赖复杂的应用程序，来使大量工控设备之间进行数据互联的问题。

Description

工控设备之间的数据互联方法、装置和工控设备

技术领域

本申请涉及数据处理领域，具体涉及工控设备之间的数据互联方法、装置和工控设备。

背景技术

随着工控领域的发展与应用，工控领域已经进入到社会生活中各个领域，来为这些领域在生活中的具体应用提供辅助。例如，交通领域中的地铁交通，通过多个工控设备的相互配合来实现闸机自动识别用户、扣取余额、开闸，进而辅助地铁交通正常运营。

现如今，工空设备对各个领域辅助功能的实现需要借助多个工控设备之间的交互配合来实现。常见的，通过应用程序控制多个工控设备，工控设备以应用程序为“中转站”进行数据互联，然后工控设备根据数据互联获得的数据运行，从而实现其辅助功能。

但是随着各个领域的技术的发展，对各个领域的辅助需要借助越来越多的工控设备进行交互配合，这需要大大提高应用程序的复杂程度，应用程序才能胜任工控设备数据互联“中转站”这一任务，进而实现大量工控设备之间的交互配合，最后完成对各个领域辅助功能。上述方法，不仅仅需要对应用程序适配更好的计算资源配置以实现应用程序的正常运行，也增加了应用程序开发与维护的应用成本。

由上可知，大量工控设备之间的交互配合依赖于复杂应用程序，才能完成工控设备之间的数据互联。最后实现对各个领域的辅助功能。

因此，如何不依赖复杂的应用程序，来使大量工控设备之间数据互联是当前所亟待需要解决的困境。

发明内容

本申请的旨在解决如何不依赖复杂的应用程序，来使大量工控设备之间数据互联的技术问题。

根据本申请实施例的一方面，本申请提供了一种工控设备之间数据互联方法，所述工控设备被部署至少一服务，以一工控设备运行的所述服务为获取数据的目标服务；

相对所述数据的获取，运行所述目标服务的所述工控设备为数据接收端，发送所述数据的其他工控设备则为数据发送端；

所述工控设备之间数据互联的方法包括：

所述数据发送端在自身所部署的服务中获取待传递数据，所述数据有适用的通信模式；

数据发送端根据所述通信模式，向数据接收端发送所述待传递数据；

所述目标服务获取数据接收端所接收的所述待传递数据，完成所述工控设备之间的数据互联。

根据本申请实施例的一方面，所述通信模式包括发布订阅模式，所述数据发送端在自身所部署的服务中获取待传递数据之前，所述方法还包括：

所述数据接收端向所述数据发送端发送消息主题的订阅信息，获得所述消息主题的订阅成功应答，所述消息主题变换为所述数据接收端的已订阅主题；

所述数据发送端记录所述数据接收端上目标服务的逻辑地址，所述逻辑地址用于所述数据发送端的数据发送。

根据本申请实施例的一方面，所述数据发送端在自身所部署的服务中获取待传递数据，包括：

部署在所述数据发送端的服务运行于容器内，待所述服务支持的所述已订阅主题有新数据产生；

所述数据发送端对所述服务获取产生的新数据为待传送数据。

根据本申请实施例的一方面，所述通信模式包括请求应答模式，所述数据发送端在自身所部署的服务中获取待传递数据之前，所述方法还包括：

所述数据接收端向所述数据发送端发送消息主题的请求信息，所述消息主题变换为所述数据接收端的已请求主题，所述数据发送端支持所述已请求主题的既存数据为所述数据发送端应答所述请求信息的待传递数据。

根据本申请实施例的一方面，所述通信模式包括请求应答模式和发布订阅模式，所述数据发送端在自身所部署的服务中获取待传递数据之前，所述方法还包括：

部署在数据发送端的服务根据所述数据接收端发送的请求信息或订阅信息，获取所述数据接收端的权限等级信息；

所述部署在数据发送端的服务通过所述数据接收端的权限等级信息执行鉴权，以确定数据接收端为数据开放对象，所述数据开放对象被授权获取所述待传递数据。

根据本申请实施例的一方面，所述数据发送端根据所述通信模式，向数据接收端发送所述待传递数据，包括：

对获取的所述待传递数据，所述数据发送端根据所述数据适用的通信模式在对应消息队列执行数据缓存以新增队列消息，新增的所述队列消息包括所述目标服务的逻辑地址、消息主题以及所述数据；

对所述消息队列逐一拆分所述队列消息，以所得通信模式为标识符对所述消息主题和数据封包获得待传递消息；

根据所述目标服务的逻辑地址由所述通信模式向数据接收端传送封包所得待传递消息，完成服务间的消息传递。

根据本申请实施例的一方面，所述根据所述通信模式在对应消息队列执行数据缓存以新增队列消息，包括：

在发布订阅模式下对已订阅主题产生的新数据，遍历所述已订阅主题记录的逻辑地址，为所述逻辑地址的已订阅主题新数据传递在所述发布订阅模式对应的消息队列新增队列消息。

根据本申请实施例的一方面，本申请提供了一种工控设备之间数据互联装置，包括：

相对所述数据的获取，运行所述目标服务的所述工控设备为数据接收端，发送所述数据的其他工控设备则为数据发送端；

所述工控设备之间数据互联的装置包括：

获取模块，用于所述数据发送端在自身所部署的服务中获取待传递数据，所述数据有适用的通信模式；

发送模块，用于数据发送端根据所述通信模式，向数据接收端发送所述待传递数据；

接收模块，用于所述目标服务获取数据接收端所接收的所述待传递数据，完成所述工控设备之间的数据互联。

根据本申请实施例的一方面，所述发送模块包括：

缓存模块，用于对获取的所述待传递数据，所述数据发送端根据所述数据适用的通信模式在对应消息队列执行数据缓存以新增队列消息，新增的所述队列消息包括所述目标服务的逻辑地址、消息主题以及所述数据；

拆分模块，用于对所述消息队列逐一拆分所述队列消息，以所得通信模式为标识符对所述消息主题和数据封包获得待传递消息；

传递单元，用于根据所述目标服务的逻辑地址由所述通信模式向数据接收端传送封包所得待传递消息，完成服务间的消息传递。

根据本申请实施例的一方面，本申请提供了一种工控设备，包括：

存储器，存储有工控设备的可读指令；

处理器，读取存储器存储的工控设备可读指令，以执行上述任意一个所述的方法。

在本申请实施例中，为实现应用程序对大量工控设备之间交互，每一工控设备都被部署至少一服务，以一工控设备运行的服务为获取数据的目标服务，相对所述数据的获取，运行所述目标服务的所述工控设备为数据接收端，发送所述数据的其他工控设备则为数据发送端，工控设备之间数据互联的方法包括，首先数据发送端在自身所部署的服务中获取待传递数据，数据有适用的通信模式。其次数据发送端根据通信模式，向数据接收端发送所述待传递数据，最后目标服务获取数据接收端所接收的所述数据，完成所述工控设备之间的数据互联。

通过工控设备被部署的服务来实现工控设备之间的数据互联，避免了通过应用程序作为“中转站”来实现工控设备之间的数据互联，所以即使再多的工控设备，也不需要应用程序使用大量的计算资源来帮助工控设备之间实现数据互联，一方面避免了数据互联的实现中对应用程序的依赖，另一方面，由于不需要应用程序作为工控设备之间数据互联的“中转站”，提高工控设备之间交互配合的效率。

本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。

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

附图说明

通过参照附图详细描述其示例实施例，本申请的上述和其他目标、特征及优点将变得更加显而易见。

图1示出了根据本申请一个实施例的一种体系架构图。

图2示出了根据本申请一个实施例的三种通信模式对应的标识符的示意图。

图3示出了根据本申请一个实施例的待传递消息的示例图。

图4示出了根据本申请一个实施例的一种工控设备之间数据互联方法的流程图。

图5示出了根据本申请一个实施例的数据发送端使用广播模式发送待传递消息的粗略示意图。

图6示出了根据本申请一个实施的数据发送端使用广播模式发送待传递消息的具体示意图。

图7示出了根据本申请一个实施例的数据接收端和数据发送端之间的通信模式为广播模式时，数据发送端发起广播以进行设备发现的流程图。

图8示出了根据本申请一个实施例的数据发送端使用广播模式进行设备下线的流程图。

图9示出了根据本申请一个实施例的通信模式包括发布订阅模式，所述数据发送端在自身所部署的服务中获取待传递数据之前，一种工控设备之间数据互联方法的流程图。

图10示出了根据本申请一个实施例的数据发送端在自身所部署的服务中获取待传递数据的流程图。

图11示出了根据本申请一个实施例的数据发送端在自身所部署的服务中获取待传递数据之前，一种工控设备之间数据互联方法的流程图。

图12示出了根据本申请一个实施例的数据发送端根据所述通信模式，向数据接收端发送所述待传递数据的流程图。

图13示出了根据本申请一个实施例的数据接收端与数据发送端之间的通信模式是发布订阅模式时，数据接收端与数据发送端数据互联的粗略流程图。

图14示出了根据本申请一个实施例的数据接收端与数据发送端之间的通信模式是发布订阅模式时，数据互联的详细流程图。

图15示出了根据本申请一个实施例的数据接收端与数据发送端之间的通信模式是发布订阅模式时，数据接收端向数据发送端订阅数据发送端运行信息的示意图。

图16示出了根据本申请一个实施例的数据接收端与数据发送端之间的通信模式是请求应答模式时，数据接收端与数据发送端数据互联的粗略流程图。

图17示出了根据本申请一个实施例的数据接收端与数据发送端之间的通信模式为请求应答模式时，数据接收端与数据发送端数据互联的详细流程图。

图18示出了根据本申请一个实施例的数据接收端与数据发送端之间的通信模式是请求应答模式时，数据接收端请求数据发送端硬件资源信息的示意图。

图19示出了根据本申请另一个实施例的硬件资源信息的示意图。

图20示出了根据本申请一个实施例的数据接收端与数据发送端之间的通信模式是请求应答模式时，数据接收端请求数据发送端硬件资源信息进行鉴权的流程图。

图21示出了根据本申请一个实施例的数据接收端与数据发送端之间的通信模式是请求应答模式时，数据接收端请求控制数据发送端的示意图。

图22示出了根据本申请一个实施例的工控设备之间数据互联装置的示意图。

图23示出了根据本申请一个实施例的发送模块的示意图。

图24示出了根据本申请一个实施例的可以运行一种工控设备之间互联方法的工控设备的结构图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些示例实施方式使得本申请的描述将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本申请的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多示例实施方式中。在下面的描述中，提供许多具体细节从而给出对本申请的示例实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而省略所述特定细节中的一个或更多，或者可以采用其他的方法、组元、步骤等。在其它情况下，不详细示出或描述公知结构、方法、实现或者操作以避免喧宾夺主而使得本申请的各方面变得模糊。

附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

请参阅图1，图1示出了根据本申请一个实施例的一种体系架构图。该体系架构可以包括：至少一个工控设备作为数据发送端11，以及至少一个工控设备作为数据接收端12，用以接收数据发送端11发送的数据，通过本申请所实现方法的执行来实现数据发送端11与数据接收端12之间的数据互联。

本申请实施例的一些技术方案可以基于如图1所示的体系架构或其变形架构来具体实施。

本申请中描述的工控设备之间数据互联方法，是通过部署在工控设备上的服务而完成的。需要明确的是工控设备是指在工业生产中被工控机控制的用以实现自动化或者半自动化运行的机器设备，如纺织器械、起重器械、印刷器械、交通器械。详细的，如交通器械中的控制人流进出站口的闸机。

在进行工控设备之间的数据互联之前，根据工控设备的使用需求，在各个工控设备上部署对应该使用需求的服务。需要明确的是，服务是指被部署在工控设备操作系统上的程序代码，用于直接接收用户操作指令，或者接收部署在计算机上的应用程序的操作指令，以此驱动工控设备实现特定功能。

进一步需要明确的是，通过获取数据发送端消息主题的数据，抑或是控制数据发送端的功能运行，来实现多个工控设备之间交互配合的服务为目标服务。工控设备上目标服务的配置和承载可以是基于应用程序功能实现的需要，也可以是基于用户需求欲实现工控设备之间某一配合效果而配置。对于需要工控设备之间交互配合才能实现的功能，将以至少一个服务为目标服务，该目标服务用以实现应用程序或者用户欲实现的功能，目标服务的数量至少为一个。

被部署目标服务的工控设备作为数据接收端；通过自身所被部署的服务为目标服务提供数据或功能支持的工控设备为数据发送端。数据接收端与数据发送端采用本申请所描述的数据互联方法，进行数据互联，进而完成工控设备之间的交互配合。

进一步需要明确的是，在本申请一实施例中数据接收端与数据发送端之间进行数据互联时，均使用特定的通讯协议，该通讯协议支持上述的广播模式、发布订阅模式和请求应答模式。

具体的，在该通讯协议下，待传递消息的格式包括三个部分，这三个部分分别是：(1)标识符，标识符用来表示待传递数据适用的通信模式；(2)主题，主题用来表示代传递消息中待传递数据的所属消息主题；(3)待传递数据。

请参阅图2，图2示出了根据本申请一个实施例的三种通信模式对应的标识符的示意图。其中，Publish/Subscribe(Encrypted)表示发布订阅模式；Reuqest/Response(Encrypted)表示请求应答模式；Broadcast(Encrypted)表示广播模式；Encrypted表示在上述模式中对数据部分加密。

请参阅图3，图3示出了根据本申请一个实施例的待传递消息的示例图。如图所示，一条待传递消息包括标识符、消息主题、待传递数据，并使用空格作为间隔，待传递数据分为未加密模式和加密两种模式。

在待传递消息的发送与接收中，使用上述特定协议，一方面兼容了请求应答模式、发布订阅模式、广播模式三种通信模式，不必因为各工控设备使用不同的通信模式而对待传递消息的消息格式的进行转变，另一方面，也避免了在多个工控设备的数据互联中，由于使用的通讯协议不同，而导致无法进行数据互联的情况。

具体请参阅图4，图4示出了根据本申请一个实施例的一种工控设备之间数据互联方法的流程图。每个工控设备被部署至少一服务，以一工控设备运行的所述服务为获取数据的目标服务，相对所述数据的获取，运行所述目标服务的所述工控设备为数据接收端，发送所述数据的其它工控设备则为数据发送端。本申请实施例提供了一种工控设备之间数据互联方法的步骤，包括：

步骤S410，数据发送端在自身所部署的服务中获取待传递数据，数据有适用的通信模式；

步骤S420，数据发送端根据所述通信模式，向数据接收端发送待传递数据；

步骤S430，目标服务获取数据接收端所接收的数据，完成工控设备之间的数据互联。

下面对以上3个步骤进行详细描述。

在步骤S410中，数据发送端是指为目标服务的功能实现提供功能响应与数据支持的工控设备，数据发送端被部署了对目标服务响应的服务，该服务根据目标服务的需求，获取其所在工控设备也即数据发送端中的对应数据为待传递数据。待传递数据用于向数据接收端发送，以实现对目标服务需求的数据支持或功能响应的反馈。

需要明确的是，对于功能响应的反馈可以具体体现为，当目标服务需要数据发送端运行自身所配置的特定功能，用以实现数据发送端与数据接收端的交互配合时，目标服务所在的工控设备作为数据接收端，会通过目标服务的运行向数据发送端发送控制请求，进而控制数据发送端中对应功能的运行；数据发送端会就控制请求向数据接收端提供相应的反馈，也就是功能响应的反馈，如，请求成功反馈，或请求失败反馈以及请求失败的原因。

进一步需要明确的是，数据发送端获取的待传递数据包括数据发送端对目标服务相关请求或订阅而产生的反馈数据，以及部署在数据发送端上的服务基于自身设定所发出的广播数据，如进行下线广播，用以标示数据发送端下线，不再提供数据支持和功能响应。

进一步需要明确的是，每一待传递数据都具有对应的通信模式，包括发布订阅模式、请求应答模式以及广播模式。待传递数据采用何种通信模式，取决于数据接收端以何种通信模式向数据接收端要求数据支持或功能响应。例外的，在广播模式下，数据发送端可以在数据发送端没有向数据发送端要求数据支持或者功能响应的情况下，数据发送端可以自主地选择通过广播模式向数据接收端发送待传递数据。

在本申请一实施例中，当待传递数据的通信模式为广播时，部署在数据发送端的服务，将待传递数据和待传递数据所属的消息主题，输入到数据发送端的广播消息队列进行缓存，得到队列消息。

数据接收端的消息广播单元将对应广播模式的标识符、待传递数据，以及待传递数据所属的消息主题封装得到待传递消息，消息广播单元向所有局域网内的工控设备发送待传递消息。消息广播单元指数据发送端在使用广播模式进行工控设备之间的互联中，用以发送待传递消息，以及接收其他工控设备广播的待传递消息的一个功能单元。

同一局域网内的工控设备若被设置为可接受广播的待传递消息，则自动接收数据发送端广播的待传递消息。示例性的，请参阅图5，图5示出了根据本申请一个实施例的数据发送端使用广播模式发送待传递消息的粗略示意图。如图5所示，数据发送端无差别发送待传递消息(主题+数据)，工控设备若配置可接受广播主题，则会接收数据发送端广播发送的待传递消息。若未被配置可接受广播主题，则不会接收数据发送端广播发送的待传递消息。请参阅图6，图6示出了根据本申请一个实施的数据发送端使用广播模式发送待传递消息的具体示意图。如图6所示，数据发送发送端直接向数据接收端发送待传递消息，待传递消息包括：broadcast(对应于通讯协议中的标识符)、topic data(对应于通讯协议中的消息主题，以及数据)。其中，broadcast：广播；topic data：主题数据。

在本申请另一实施例中，数据发送端在下线时，广播设定次数或设定时间的下线消息，下线消息表示该数据发送端不再响应数据的请求或订阅，也不再响应目标服务的功能控制请求。数据发送端在上线时，广播设定次数或设定时间的上线消息，表示该数据发送端可以响应数据的请求或订阅，也可以响应目标服务的功能控制请求。需要明确的是，上述数据发送端通过广播传递待传递消息的方式，不仅仅可以在局域网中进行，还可以在广域网中进行。示例性的，在广播传输中，数据接收端将待传递消息发送到广播地址，网络上的所有设备都可以通过访问广播地址，获取待传递消息。

其中，广播地址是指网络中以广播模式发送的待传递消息的所在地址。广播地址是一个特殊的IP地址(Internet Protocol Address，互联网协议地址)，用于标识网络上的所有工控设备。当待传递消息到达网络中的路由器或交换机时，它们会将待传递消息转发到网络上的所有接口，以确保所有工控设备都能接收到待传递消息。

请参阅图7，图7示出了根据本申请一个实施例的数据接收端和数据发送端之间的通信模式为广播模式时，数据发送端发起广播以进行设备发现的流程图。需要明确的是，数据发送端在进行广播在线信息时，携带自身的硬件资源信息，可以是基于数据发送端本身的设置。

如图7所示，部署在数据发送端上的服务以自身的硬件资源信息作为待传递消息，向同一局域网中其他工控设备进行广播，其他工控设备接收到数据发送端广播的待传递消息后，便可以明确数据发送端已经上线，可以被请求哪些数据或者进行哪些功能响应。以便于数据接收端上的目标服务向数据发送端订阅或请求，令数据发送端提供数据支持或者功能响应。

其中，数据发送端的待传递消息包括：broadcast(是标识符)、device-info(是消息主题)、(basic、device_id、os、container、hw、uart、res、pl)为待传递数据内容。其中，broadcast：广播(标识符，表示了通信模式)；device-info：设备信息(消息主题)；basic：设备基础信息；device_id：设备ID；os：操作系统；container：是否在容器内运行；hw：硬件资源列表；uart：设备串口；res：串口可操作的端口列表；pl：端口操作权限(控制设备权限大于此数值可操作串口)。

当数据发送端不想要直接广播自身的硬件资源信息时，数据发送端在广播待传递消息中隐蔽自己的硬件资源信息，待传递数据中只含有数据发送端的broadcast(是标识符)、device-info(是消息主题)、(basic、device_id、os、container)为待传递数据内容。其中broadcast：广播(标识符，表示了通信模式)；device-info：设备信息(消息主题)；basic：设备基础信息；device_id：设备ID；os：操作系统；container：是否在容器内运行。

在本申请另一实施例中，数据发送端还通过上述方式，告知其他共控设备数据发送端已经下线，将不再提供数据支持和功能响应。请参阅图8，图8示出了根据本申请一个实施例的数据发送端使用广播模式进行设备下线的流程图。如图8所示出的，数据发送端向数据接收端发送下线广播。

待传递数据中只含有数据发送端的broadcast(是标识符)、device-info(是消息主题)、(basic、device_id、os、container)为待传递数据内容。

其中broadcast：广播(标识符，表示了通信模式)；device-info：设备信息(消息主题)；basic：设备基础信息；device_id：设备ID；os：操作系统；container：是否在容器内运行。

在本申请另一实施例中，当数据接收端以发布订阅模式，向数据发送端发送订阅消息，以进行数据发送端消息主题的订阅时。正如前述所描述的待传递数据的通信模式，取决于数据接收端何种通信模式向数据接收端要求数据支持或功能响应。那么在当前实施例中，待传递数据的通信模式则对应于数据接收端的对消息主题的订阅，为发布订阅模式。

具体地，请参阅图9，图9示出了根据本申请一个实施例的通信模式包括发布订阅模式，所述数据发送端在自身所部署的服务中获取待传递数据之前，一种工控设备之间数据互联方法的流程图。本申请提供了一种工控设备之间数据互联方法的流程图的步骤，包括：

步骤S301，数据接收端向数据发送端发送消息主题的订阅信息，获得消息主题的订阅成功应答，消息主题变换为所述数据接收端的已订阅主题；

步骤S302，数据发送端记录数据接收端上目标服务的逻辑地址，逻辑地址用于所述数据发送端的数据发送。

下面对上述两个步骤进行详细描述。

在步骤S301中，当数据接收端与数据发送端之间数据的通信模式为发布订阅模式时，目标服务将订阅信息和数据发送端的逻辑地址，在数据发送端发布订阅模式的消息队列中执行缓存，得到对应的队列消息。订阅信息中包括数据接收端欲订阅的消息主题，以及数据接收端基础信息。消息主题指示了目标服务向数据发送端订阅数据的消息主题。

在本申请一实施例中数据接收端基础信息包括：设备ID、操作系统、是否在容器内运行。

数据接收端的消息订阅单元对队列消息进行拆分得到消息主题、数据接收端基础信息和数据发送端的逻辑地址，生成对应发布订阅模式的标识符，将消息主题、数据接收端基础信息、标识符重新封包得到到订阅信息，最后数据接收端根据数据发送端的逻辑地址将订阅信息发送到数据发送端的消息发布单元。需要明确的是，消息订阅单元指数据接收端在使用发布订阅模式与数据发送端数据互联的过程中，发送订阅信息，以及接收数据发送端发布的待传递消息的一个功能单元。消息发布单元是指数据发送端在使用发布订阅模式与数据接收端数据互联的过程中，接收订阅信息，以及发布待传递消息的一个功能单元。

数据发送端的消息发布单元在接收订阅消息时获取订阅消息的来源，也即数据接收端的逻辑地址，数据发送端的消息发布单元根据标识符将得到的数据发送端的逻辑地址以及订阅信息，载入至数据发送端订阅发布模式的消息队列以执行缓存，得到对应的队列消息。

部署在数据发送端的服务从订阅发布模式的消息队列中读取队列消息，对订阅消息进行应答，得到订阅消息所订阅消息主题的订阅成功应答，与此同时，部署在数据发送端的服务将被订阅的消息主题变换为所述数据接收端的已订阅主题。

部署在数据发送端的服务将订阅成功应答和数据接收端的逻辑地址在发布订阅模式的消息队列中执行缓存，得到对应的队列消息。数据发送端的消息发布单元获取队列消息，对队列消息进拆分，得到订阅成功应答与数据接收端的逻辑地址。数据发送端的消息发布单元根据数据接收端的逻辑地址向数据接收端发送订阅成功答应。

在步骤S302中，数据发送端在根据数据接收端的逻辑地址向数据接收端发送订阅成功应答后，将数据发送端的逻辑地址进行记录，用于数据发送端在需向数据接收端发送数据时，提供数据接收端的逻辑地址。

请参阅图10，图10示出了根据本申请一个实施例的数据发送端在自身所部署的服务中获取待传递数据的流程图。本申请提供了数据发送端在自身所部署的服务中获取待传递数据的步骤S410，包括：

步骤S411，部署在数据发送端的服务运行于容器内，待服务支持的已订阅主题有新数据产生；

步骤S412，数据发送端对服务获取产生的新数据为待传送的数据。

下面对上述两个步骤进行详细描述。

需要明确的是，在本申请实施例中每个工控设备上都被设置有容器，使得各个工控设备在操作系统和/或核心处理器不一致的情况下，可以被部署运行相同的应用程序以及服务，进而使得任意一工控设备上所部署的服务，都可以和其他工控设备上所部署的服务进行交互，并且还可以实现对其他工控设备的控制，而不会被工控设备操作系统和/或核心处理器不一致的问题所影响。

在步骤S411中，部署在所述数据发送端的服务运行于容器内，等待已订阅主题产生新的数据。

在步骤S412中，数据发送端获取该已订阅主题产生的数据，也即待传递数据，对应于数据接收端的订阅消息，待传递数据的通信模式为发布订阅模式。

在本申请另一实施例中，当数据发送端与数据接收端之间的通信模式为请求应答模式时，目标服务将请求信息和数据发送端的逻辑地址，在请求应答模式的消息队列中执行缓存，得到对应的队列消息。

请求信息中包括数据接收端基础信息，以及欲请求的消息主题，消息主题表示了目标服务向数据发送端哪一消息主题请求数据。

数据接收端的消息请求单元对队列消息进行拆分得到消息主题、数据接收端基础信息和数据发送端的逻辑地址后，生成对应请求模式的标识符，将消息主题、数据接收端基础信息、标识符封包的重新到请求信息。数据发送端的消息请求单元根据数据接收端的逻辑地址将请求信息发送到数据发送端。

需要明确的是，消息请求单元指数据接收端在使用请求应答模式与数据发送端进行数据互联的过程中，发送请求信息，以及接收数据发送端发布的待传递消息的一个功能单元。与之对应的，数据接收端上还被部署有消息应答单元，消息应答单元是指数据发送端在使用发布订阅模式与数据接收端数据互联的过程中，接收请求信息，以及应答待传递消息的一个功能单元。

数据发送端的消息应答单元根据接收到的请求信息，得到数据发送端的逻辑地址以及订阅信息，并将订阅信息和数据接收端的逻辑地址送入至订阅发布模式的消息队列以执行缓存，得到对应的队列消息。

部署在数据接收端的服务从请求应答模式的消息队列中获取队列消息并拆分队列消息，得到请求信息。该服务读取请求信息，并判断自身是否具有请求信息中所请求的消息主题，若有，则将请求信息中所请求的消息主题更新为数据接收端的已请求主题，然后该服务获取已请求主题的已经产生的数据为待传递数据。该待传递数据的通信模式为请求应答模式。

请参阅图11，图11示出了根据本申请一个实施例的数据发送端在自身所部署的服务中获取待传递数据之前，一种工控设备之间数据互联方法的流程图。通信模式包括请求应答模式和发布订阅模式，本申请提供了一种工控设备之间数据互联方法的步骤，包括：

步骤S501，部署在数据发送端的服务根据数据接收端发送的请求信息或订阅信息，获取数据接收端的权限等级信息；

步骤S502，部署在数据发送端的服务通过数据接收端的权限等级信息执行鉴权，以确定数据接收端为数据开放对象，所述数据开放对象被授权获取所述待传递数据。

下面对上述两个步骤进行详细描述。

在步骤S501中，部署在数据发送端的服务，在从对应通信模式的消息队列中，获取队列消息之后，在对队列消息进行拆分读取得到订阅信息或请求信息，并将订阅消息所订阅的消息主题更新为已订阅主题之前，或者将请求消息所请求的消息主题更新为已请求主题之前，根据订阅信息或请求信息，得到其中包含的数据接收端的权限等级。

在步骤S502中，部署数据接收端的服务将数据接收端的权限等级，与获取消息主题的数据所需权限等级进行比较，若数据接收端的权限等级较小，则部署在数据接收端的服务不再对所收到的订阅消息或请求消息进行任何反馈或应答。

在步骤S420中，数据发送端根据待传递数据的通信模式，对待传递数据进行对应通信模式的封装得到待传递消息，将待传递消息加载到数据发送端的消息队列，以发送到数据接收端。

请参阅图12，图12示出了根据本申请一个实施例的数据发送端根据所述通信模式，向数据接收端发送所述待传递数据的流程图。本申请提供了数据发送端根据所述通信模式，向数据接收端发送所述待传递数据的步骤S420，包括：

步骤S421，对获取的待传递数据，数据发送端根据数据适用的通信模式在对应消息队列执行数据缓存以新增队列消息，新增的队列消息包括目标服务的逻辑地址、消息主题以及所述数据；

步骤S422，对消息队列逐一拆分所述队列消息，以所得通信模式为标识符对消息主题和数据封包获得待传递消息；

步骤S423，根据目标服务的逻辑地址由通信模式向数据接收端传送封包所得待传递消息，完成服务间的消息传递。

下面对上述三个步骤进行详细描述。

在步骤S421中，部署在数据发送端上的服务，在获取待传递数据后，将获取的待传递数据、消息主题以及目标服务的逻辑地址缓存至对应通信模式的消息对队列中，以形成对应的队列消息。

目标服务的逻辑地址源于订阅消息或请求消息；消息主题为产出待处理数据的已订阅主题或已请求主题；待传递数据的通信模式，取决于产生待传递数据的是已订阅主题还是已请求主题。

若产生待传递数据的是已订阅主题，则待传递数据的通信模式就是发布订阅模式；若产生待处理数据的是已请求主题，则待传递数的通信模式就是请求应答模式。

在本申请的一个实施例中，当通信模式是发布订阅模式时，将已订阅主题产生的数据作为待传递数据，遍历所述已订阅主题记录的数据接收端逻辑地址，根据不同数据接收端的逻辑地址，在数据发送端中的发布订阅消息队列中依次进行缓存，分别生成队列消息。

在步骤S422中，数据发送端的消息发送单元从消息队列中得到队列消息，对队列消息进行拆分得到数据接收端的逻辑地址，同时生成表示待处理数据所适用的通信模式的标识符，然后对标识符、待处理数据、消息主题进行封装得到待传递消息。数据发送端的消息发送单元包括消息发布单元和消息应答单元，用于发送待传递消息以及接收数据接收端发送的消息。与之对应的数据接收端上部署有消息接收单元，其包括消息订阅单元和消息请求单元，用于接收待传递消息和向数据发生端发送消息。

在步骤S423中，数据发送端的消息发送单元根据数据接收端的逻辑地址，向数据接收端发送待传递消息。当待传递消息的通信模式是发布订阅模式则使用消息发布单元发送待传递消息；当待传递消息的通信模式是请求应答模式，则使用消息应答单元发送待传递消息。

在步骤S430中，数据接收端信息接收单元接收待传递消息，并进行拆分，识别待传递消息中含有的标识符得到待传递消息所对应的通信模式，然后将得到待传递数据与消息主题在对应通信模式的消息队列中执行缓存得到队列消息，目标服务从消息队列中获取队列消息，并对队列消息进行拆分得到待传递数据。

下面是通过一些具体实施例来对本申请中的方法在具体场景中的应用进行描述。

请参阅图13，图13示出了根据本申请一个实施例的数据接收端与数据发送端之间的通信模式是发布订阅模式时，数据接收端与数据发送端数据互联的粗略流程图。数据接收端向数据发送端发送订阅信息，订阅信息包括订阅主题也即订阅的消息主题，数据发送端根据订阅信息获取订阅主题的待传递数据，向数据发送端发布待传递消息，待传递消息包括订阅主题和订阅主题产生的数据。

请参阅图14，图14示出了根据本申请一个实施例的数据接收端与数据发送端之间的通信模式是发布订阅模式时，数据互联的详细流程图。由图14可知在本申请一实施例中，若数据接收端与数据发送端之间的通信模式是发布订阅模式，数据接收端向数据发送端发送订阅信息，数据发送端接收订阅信息，并向数据接收端发送订阅成功答应，以表示数据发送端接受了数据接收端的数据请求，然后将数据接收端的IP地址进行记录，用以向数据接收端发布其订阅的消息主题所产生的新数据。若有多个数据接收端订阅了相同的消息主题，则将所有数据接收端的IP地址全都记录下来，在数据接收端所订阅的消息主题产生新数据时，将已订阅主题产生的数据作为待传递数据，遍历所述已订阅主题记录的数据接收端逻辑地址，根据不同数据接收端的逻辑地址，在数据发送端中的发布订阅消息队列中依次进行缓存，分别生成队列消息。数据发送端的消息发布单元从消息队列中得到队列消息，对队列消息进行拆分得到数据接收端的逻辑地址，同时生成表示待处理数据所适用的通信模式的标识符，然后对标识符、待处理数据、消息主题进行封装得到待传递消息，向数据接收端发送。

数据接收端的目标服务在获取待传递消息中的待传递数据之后，还将向数据发送端反馈发布接受应答，以表示数据接收端已经接收待传递数据。

但是若在设定时间内，目标服务未向数据发送端反馈发布接受应答，则说明数据接收对端未成功接收待传递数据，此时数据发送端重新向数据接收端重新发送待传递消息，或者发送待传递数据发送失败的提示。

请参阅图15，图15示出了根据本申请一个实施例的数据接收端与数据发送端之间的通信模式是发布订阅模式时，数据接收端向数据发送端订阅数据发送端运行信息的示意图。由图15可知，目标服务经由数据接收端向数据发送端发送订阅信息，以订阅数据发送端的功耗数据，订阅消息中包括：subscribe(对应通讯协议中的标识符)、power-info(对应通讯协议中的消息主题)、(device_id、os、container)数据接收端基础信息，也即通讯协议中的数据部分。

其中subscribe：订阅；power-info功耗信息(以表示数据接收端想要订阅的消息主题)；device_id：设备ID；os：操作系统；container：是否在容器内运行。发送端接收到订阅消息后，将数据接收端订阅的主题更新为已订阅主题，并定时获取已订阅主题产生的新数据，向数据接收端发送。正如图15中所示的，发布的代传递信息包括：publish(通讯协议中的标识符)、power-info(通讯协议中的消息主题)、(device_id、os、container、power、voltage、current)是数据接收端基础信息，也即通讯协议中的数据部分。

publish：发布(通信模式对应的标识符，对应subscribe：订阅)；power-info功耗信息(以表示数据接收端想要订阅的消息主题)device_id：设备ID；os：操作系统；container：是否在容器内运行；power：被订阅消息主题；voltage：电压，219.2v(伏)；current：电流：3.7A(安)。

请参阅图16，图16示出了根据本申请一个实施例的数据接收端与数据发送端之间的通信模式是请求应答模式时，数据接收端与数据发送端数据互联的粗略流程图。数据接收端向数据接收端发送请求信息，请求信息包括请求的消息主题和用于请求的数据，如数据接收端基础信息。数据接收端首先根据请求信息中的请求主题，判断自身是否可以请求主题相关数据，若是可以对该请求信息进行应答，向数据发送端发送待传递消息。

具体的，请参阅图17，图17示出了根据本申请一个实施例的数据接收端与数据发送端之间的通信模式为请求应答模式时，数据接收端与数据发送端数据互联的详细流程图。数据接收端向数据接收端发送请求信息，请求信息包括请求主题和请求的数据，数据接收端首先根据请求信息中的请求主题向数据发送端发送待传递消息。其中，请求信息包括：request、topic data，其中request(请求，对应通信模式)、topic data(请求的消息主题数据)。应答的待传递消息包括：response、topic data，其中response(应答，对应通信模式)、topic data(应答的消息主题数据)。

请参阅图18，图18示出了根据本申请一个实施例的数据接收端与数据发送端之间的通信模式是请求应答模式时，数据接收端请求数据发送端硬件资源信息的示意图。在本申请实施例中，数据发送端以自己的基础信息作为待传递消息，向其他作为数据接收端的工控设备进行广播，数据接收单端得知数据发送端已经上线，可以提供数据支持或者功能响应。

数据接收端向数据发送端发送请求数据发送端的硬件资源信息的请求信息，请求信息中包括request(通讯协议中的标识符)、device-info(通讯协议中的消息主题)、(basic、device_id、os、container、pl)数据接收端基础信息。request：请求(通信模式的标识符，表示请求应答模式)；device-info：设备信息(请求的消息主题)；basic：设备基础信息；device_id：设备ID；os：操作系统；container：是否在容器内运行；pl：端口操作权限(数据接收端权限大于此数值可操作串口)。部署在数据发送端上的服务在接收到请求信息后，判定数据接收端权限是否大于端口操作权限，若是则通过向数据接收端数据发送端的待传递消息向数据接收端发送硬件资源信息。

待传递消息包括：response(对应通讯协议中的标识符)、device-info(对应通讯协议中的消息主题)、(basic、device_id、os、container、hw)硬件资源信息，对应于通讯协议中的数据部分。其中，broadcast：广播；device-info：设备信息；basic：设备基础信息；device_id：设备ID；os：操作系统；container：是否在容器内运行；hw：硬件资源列表；sound：音频端口；led：灯光端口。

请参阅19，图19示出了根据本申请另一个实施例的硬件资源信息的示意图。正如图19所示出，response、device-info、basic、device_id、os、container、hw、uart、res、pl。

其中，response：应答(通信模式的标识符)；device-info：设备信息(被请求的消息主题)，basic：设备基础信息；device_id：设备ID；os：操作系统；container：是否在容器内运行；hw：硬件资源列表；uart：设备串口；res：串口可操作的端口列表；pl：端口操作权限(控制设备权限大于此数值可操作串口)。

请参阅图20，图20示出了根据本申请一个实施例的数据接收端与数据发送端之间的通信模式是请求应答模式时，数据接收端请求数据发送端硬件资源信息进行鉴权的流程图。如图20所示出的数据发送端以广播模式广播待传递消息，待传递消息中包括：broadcast(通讯协议中的标识符)、device-info(通讯协议中的消息主题)、(basic、device_id、os、container、hw)广播的内容，也即通讯协议中的数据部分。其中，broadcast：广播；device-info：设备信息；basic：设备基础信息；device_id：设备ID；os：操作系统；container：是否在容器内运行；hw：硬件资源列表。数据接收端通过获取数据发送端广播的待传递消息，判定数据发送端已上线，且可以进行数据支持或功能响应。

然后，数据接收端向数据发送端发送请求信息，用以请求数据发送端的硬件资源信息，请求信息包括：request(通信协议中标识符，表示请求应答模式)、device-info(请求的消息主题)、(basic、device_id、os、container、pl、hw)数据接收端基础信息。其中basic：设备基础信息；device_id：设备ID；os：操作系统；container：是否在容器内运行；pl：端口操作权限(数据接收端权限大于此数值可操作串口)，hw：硬件资源列表。

数据发送端在接收到数据发送端发送的请求信息之后，向平台侧的认证中心发送数据接收端的pl(权限等级也即端口操作权限)，以对数据接收端进行鉴权，从而明确数据接收端是否有权限，获取数据发送端的硬件资源信息。认证中心在收到数据发送端的鉴权请求后，向数据发送端发送鉴权结果，如图20中，认证中心对数据发送端的鉴权请求的应答结果中的“result：ok”表示认证中心的鉴权结果是肯定的，标示着数据接收端可以获取数据发送端的硬件资源信息。

数据发送端根据认证中心发送的鉴权结果，将包括自身硬件资源信息的待传递消息向数据接收端发送。在本申请实施例中，待传递消息包括：response(通讯协议中的标识符)、device-info(通讯协议中的消息主题)、(basic、device_id、os、container、hw)硬件资源信息，也即通讯协议中的数据部分。其中，response：应答；device-info：设备信息；basic：设备基础信息；device_id：设备ID；os：操作系统；container：是否在容器内运行；hw：硬件资源列表；sound：音频端口；led：灯光端口。

请参阅图21，图21示出了根据本申请一个实施例的数据接收端与数据发送端之间的通信模式是请求应答模式时，数据接收端请求控制数据发送端的示意图。正如图21所示的，目标服务通过数据接收端向数据发送端发送请求控制设备的请求信息，请求信息包括：request(通信协议中标识符，表示请求应答模式)、device-handle(请求的消息主题)、(basic、device_id、os、container、hw、led)数据接收端基础信息，也即通讯协议中的数据部分。其中basic：设备基础信息；device_id：设备ID；os：操作系统；container：是否在容器内运行；hw：硬件资源列表；led(灯)：想要控制的对象；value：off：想要达到的控制结果(把灯关掉)。

部署在数据接收端上的服务获取数据发送端接收端的请求消息，通过数据接收端中部署的硬件接口，形成对数据接收端底层硬件的操作命令。数据接收端的操作系统根据上述操作命令，对数据接收端中的对应硬件，如请求信息中的控制对象——灯，实现请求信息中请求的控制——关掉灯。

紧接着，部署在数据接收端上的服务将控制结果作为待传递数据，待传递数据的内容是，response(通信协议中标识符，表示请求应答模式)、device-handle(请求的消息主题)、(basic、device_id、os、container、hw、led、)控制结果和数据发送端基础信息，也即通讯协议中的数据部分。basic：设备基础信息；device_id：设备ID；os：操作系统；container：是否在容器内运行；hw：硬件资源列表；led(灯)：想被控制的对象；result，ok：控制结果(完成请求消息中欲进行的控制)。

把获取的待传递数据、消息主题以及目标服务的逻辑地址缓存至请求应答模式的消息对队列中，以形成对应的队列消息。数据发送端的消息应答单元从消息队列中得到队列消息，对队列消息进行拆分，得到目标服务的逻辑地址，同时生成表示请求应答模式的标识符，然后对标识符、待处理数据、消息主题进行封装得到待传递消息，最后将包含控制结果的待传递消息发送至数据接收端。

请参阅图22，图22示出了根据本申请一个实施例的工控设备之间数据互联装置的示意图。相对所述数据的获取，运行目标服务的工控设备为数据接收端，发送数据的其他工控设备则为数据发送端，工控设备之间数据互联的装置包括：

获取模块610，用于数据发送端在自身所部署的服务中获取待传递数据，数据有适用的通信模式；

发送模块620，用于数据发送端根据通信模式，向数据接收端发送待传递数据；

接收模块630，用于目标服务获取数据接收端所接收的待传递数据，完成工控设备之间的数据互联。

请参阅图23，图23示出了根据本申请一个实施例的发送模块的示意图。发送模块包括：

缓存模块621，用于对获取的待传递数据，数据发送端根据所述数据适用的通信模式在对应消息队列执行数据缓存以新增队列消息，新增的队列消息包括目标服务的逻辑地址、消息主题以及数据；

拆分模块622，用于对消息队列逐一拆分队列消息，以所得通信模式为标识符对消息主题和数据封包获得待传递消息；

传递单元623，用于根据目标服务的逻辑地址由通信模式向数据接收端传送封包所得待传递消息，完成服务间的消息传递。

根据本申请实施例的工控设备之间数据互联的方法可以由图24的工控设备来实现。下面参照图24来描述根据本申请实施例的工控设备。图24显示的工控设备仅仅是一个示例，不应对本申请实施例的功能和适用范围带来任何限制。

如图24所示，工控设备或以通用计算设备的形式表现。工控设备的组件可以包括但不限于：上述至少一个处理单元810、上述至少一个存储单元820、连接不同系统组件(包括存储单元820和处理单元810)的总线830。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元810执行，使得所述处理单元810执行本说明书上述示例性方法的描述部分中描述的根据本发明各种示例性实施方式的步骤。例如，所述处理单元810可以执行如图2中所示的各个步骤。

存储单元820可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)8201和/或高速缓存存储单元8202，还可以进一步包括只读存储单元(ROM)8203。

存储单元820还可以包括具有一组(至少一个)程序模块8205的程序/实用工具8204，这样的程序模块8205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线830可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

工控设备也可以与一个或多个外部设备700(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该工控设备交互的设备通信，和/或与使得该工控设备能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口850进行。并且，工控设备还可以通过网络适配器860与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器860通过总线830与工控设备的其它模块通信。应当明白，尽管图中未示出，可以结合工控设备使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本申请实施方式的方法。

在本申请的示例性实施例中，还提供了一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行上述方法实施例部分描述的方法。

根据本申请的一个实施例，还提供了一种用于实现上述方法实施例中的方法的程序产品，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本申请中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本申请实施方式的方法。

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

Claims (10)

1.一种工控设备之间数据互联方法，其特征在于，所述工控设备被部署至少一服务，以一工控设备运行的所述服务为获取数据的目标服务；

相对所述数据的获取，运行所述目标服务的所述工控设备为数据接收端，发送所述数据的其他工控设备则为数据发送端；

所述工控设备之间数据互联的方法包括：

所述数据发送端在自身所部署的服务中获取待传递数据，所述数据有适用的通信模式；

数据发送端根据所述通信模式，向数据接收端发送所述待传递数据；

所述目标服务获取数据接收端所接收的所述待传递数据，完成所述工控设备之间的数据互联。

2.根据权利要求1所述的方法，其特征在于，所述通信模式包括发布订阅模式，所述数据发送端在自身所部署的服务中获取待传递数据之前，所述方法还包括：

所述数据接收端向所述数据发送端发送消息主题的订阅信息，获得所述消息主题的订阅成功应答，所述消息主题变换为所述数据接收端的已订阅主题；

所述数据发送端记录所述数据接收端上目标服务的逻辑地址，所述逻辑地址用于所述数据发送端的数据发送。

3.根据权利要求2所述的方法，其特征在于，所述数据发送端在自身所部署的服务中获取待传递数据，包括：

部署在所述数据发送端的服务运行于容器内，待所述服务支持的所述已订阅主题有新数据产生；

所述数据发送端对所述服务获取产生的新数据为待传送数据。

4.根据权利要求1所述的方法，其特征在于，所述通信模式包括请求应答模式，所述数据发送端在自身所部署的服务中获取待传递数据之前，所述方法还包括：

所述数据接收端向所述数据发送端发送消息主题的请求信息，所述消息主题变换为所述数据接收端的已请求主题，所述数据发送端支持所述已请求主题的既存数据为所述数据发送端应答所述请求信息的待传递数据。

5.根据权利要求2或4所述的方法，其特征在于，所述通信模式包括请求应答模式和发布订阅模式，所述数据发送端在自身所部署的服务中获取待传递数据之前，所述方法还包括：

部署在数据发送端的服务根据所述数据接收端发送的请求信息或订阅信息，获取所述数据接收端的权限等级信息；

所述部署在数据发送端的服务通过所述数据接收端的权限等级信息执行鉴权，以确定数据接收端为数据开放对象，所述数据开放对象被授权获取所述待传递数据。

6.根据权利要求1所述的方法，其特征在于，所述数据发送端根据所述通信模式，向数据接收端发送所述待传递数据，包括：

对获取的所述待传递数据，所述数据发送端根据所述数据适用的通信模式在对应消息队列执行数据缓存以新增队列消息，新增的所述队列消息包括所述目标服务的逻辑地址、消息主题以及所述数据；

对所述消息队列逐一拆分所述队列消息，以所得通信模式为标识符对所述消息主题和数据封包获得待传递消息；

根据所述目标服务的逻辑地址由所述通信模式向数据接收端传送封包所得待传递消息，完成服务间的消息传递。

7.根据权利要求6所述的方法，其特征在于，所述根据所述通信模式在对应消息队列执行数据缓存以新增队列消息，包括：

在发布订阅模式下对已订阅主题产生的新数据，遍历所述已订阅主题记录的逻辑地址，为所述逻辑地址的已订阅主题新数据传递在所述发布订阅模式对应的消息队列新增队列消息。

8.一种工控设备之间数据互联装置，其特征在于，包括：

相对所述数据的获取，运行所述目标服务的所述工控设备为数据接收端，发送所述数据的其他工控设备则为数据发送端；

所述工控设备之间数据互联的装置包括：

获取模块，用于所述数据发送端在自身所部署的服务中获取待传递数据，所述数据有适用的通信模式；

发送模块，用于数据发送端根据所述通信模式，向数据接收端发送所述待传递数据；

接收模块，用于所述目标服务获取数据接收端所接收的所述待传递数据，完成所述工控设备之间的数据互联。

9.根据权利要求8所述的装置，其特征在于，所述发送模块包括：

缓存模块，用于对获取的所述待传递数据，所述数据发送端根据所述数据适用的通信模式在对应消息队列执行数据缓存以新增队列消息，新增的所述队列消息包括所述目标服务的逻辑地址、消息主题以及所述数据；

拆分模块，用于对所述消息队列逐一拆分所述队列消息，以所得通信模式为标识符对所述消息主题和数据封包获得待传递消息；

传递单元，用于根据所述目标服务的逻辑地址由所述通信模式向数据接收端传送封包所得待传递消息，完成服务间的消息传递。

10.一种工控设备，其特征在于，包括：

存储器，存储有工控设备的可读指令；

处理器，读取存储器存储的工控设备可读指令，以执行权利要求1-7中的任意一个所述的方法。