本发明涉及物联网领域，尤其涉及一种报文转换系统和报文转换方法。
背景技术：
随着物联网事业的不断发展，嵌入式设备越来越多的被应用到物联网中。为了让嵌入式设备组成的下位机平台与云平台中的上位机进行更好的连接，通常需要使用报文转换系统将两个平台进行对接。然而，现有的报文转换系统多无法有效实现多种终端平台的转换。同时，面对大量上位机的接入与多种下位设备的链接，现有报文转换系统的鲁棒性(robust，又称顽健性)并不高，大多数现有报文转换系统的报文转化机制中，对报文预处理并不完善，使得系统转换效率不高。
技术实现要素：
本发明解决的问题是提供一种报文转换系统和报文转换方法，以克服现有报文转换系统和转换方法转换效率不高的问题。
为解决上述问题，本发明提供了一种报文转换系统，包括：与上位机进行数据通信的上位机接入服务端；与设备进行数据通信的设备接入服务端；消息管理器，所述消息管理器用于接收和转发来自所述上位机接入服务端和所述设备接入服务端的消息；协议管理控制器，所述协议管理控制器用于接收从所述消息管理器转发来的消息，并用于将接收后的消息转发至设备接入服务端或上位机接入服务端。
可选的，所述设备接入服务端包括tcp服务模块和udp服务模块。
可选的，所述udp服务模块包括会话控制模块和端口列表。
可选的，所述设备接入服务端接收来自于所述设备的设备协议报文。
可选的，所述消息管理器包括消息队列模块和线程池模块。
可选的，所述协议管理控制器包括协议管理器和协议适配器。
可选的，所述协议管理器包括服务映射列表。
可选的，所述上位机接入服务端包括应用层协议服务端和应用层客户端；所述应用层协议服务端用于接收来自于所述上位机的应用层协议报文；所述应用层协议服务端为http服务端；所述应用层客户端用于向所述上位机发送应用层协议报文；所述应用层客户端为http客户端。
可选的，还包括第一线程组、第二线程组和第三线程组；所述第一线程组包括第一线程池，用于给所述应用层协议服务端提供线程；所述第二线程组包括第二线程池，用于给所述设备接入服务端提供线程；所述第三线程组包括第三线程池，用于给所述消息管理器和所述协议管理控制器提供线程。
为解决上述问题，本发明还提供了一种报文转换方法，包括：对符合应用层协议的第一请求报文进行解析以产生第一请求消息；将所述第一请求消息放入消息队列中；从所述消息队列中读取所述第一请求消息，进行协议转换与统一，形成符合设备协议的第一转换报文；对符合设备协议的第二请求报文进行解析以产生第二请求消息；将所述第二请求消息放入所述消息队列中；从所述消息队列中读取所述第二请求消息，进行协议转换与统一，形成符合应用层协议的第二转换报文。
可选的，所述第二请求报文为登录包时，所述登录包括设备uid号码、ip地址和端口号；所述对第二格式的第二请求报文进行解析以产生第二请求消息，包括：生成ip地址和端口号的组合列表；将第二请求报文中携带的ip地址和端口号与所述组合列表中的信息进行比较和修改处理，将包括uid号码信息的指针与所述第二请求报文捆绑；以捆绑所述指针的所述第二请求报文产生所述第二请求消息。
本发明技术方案的其中一个方面中，通过在上位机与设备(下位机)之间设置一种新的报文转换系统，所述报文转换系统具有消息管理器和协议管理控制器，解决了现有应用端(上位机)与设备(物联网设备)报文转换效率低的问题，解决多设备、大数据量并发处理问题，提高数据(报文)转换的效率，兼容不同厂商不同设备的通信方式，实现数据转换的高效性，提高设备与上位机通信的响应速度，解决上位机处理报文的负担，使得上位机高效处理信息。
附图说明
图1是本发明实施例提供的报文转换系统示意图；
图2是本发明另一实施例提供的报文转换系统示意图；
图3是图2所示报文转换系统的部分结构示意图。
具体实施方式
现有报文转换系统对报文的转换效率不高。
为此，本发明提供一种提供报文转换系统，用于实现对大工程量实施中,设备(下位机)与上位机的稳定通信，并且实现接收大量报文数据，以及对通信链路保存与维护，并对数据进行统一管理与处理，方便上位机(应用端)做数据集群处理。
为更加清楚的表示，下面结合附图对本发明做详细的说明。
本发明实施例提供一种报文转换系统，如图1所示，包括：上位机接入服务端310、设备接入服务端320、消息管理器330和协议管理控制器340。上位机接入服务端310用于与上位机100进行数据通信。设备接入服务端320用于与设备200进行数据通信。消息管理器330用于接收和转发来自上位机接入服务端310和设备接入服务端320的消息。协议管理控制器340用于接收从消息管理器330转发来的消息，并且，协议管理控制器340用于将接收后的消息(报文)进行转换之后，转发至“转换后报文”对应的设备接入服务端320或上位机接入服务端310。
上位机接入服务端310用于与上位机100进行数据通信，因此，上位机接入服务端310与上位机100通信连接。
设备接入服务端320用于与设备200进行数据通信，因此，设备接入服务端320与设备200通信连接。
消息管理器330用于接收由于能够接收和转发来自上位机接入服务端310和设备接入服务端320的消息，因此，消息管理器330与上位机接入服务端310和设备接入服务端320均通信连接。
协议管理控制器340一方面能用于接收从消息管理器330转发来的消息，另一方面能用于将接收后的消息转发至设备接入服务端320或上位机接入服务端310，因此，协议管理控制器340与消息管理器330、设备接入服务端320和上位机接入服务端310分别通信连接。
上位机接入服务端310用于接收来自于上位机100的应用层协议报文(应用层协议报文即符合应用层协议的报文)。同时，上位机接入服务端310也用于向上位机100发送符合应用层协议的报文。
设备接入服务端320用于接收来自于设备200的设备协议报文(设备协议报文即符合设备协议的报文)。同时，设备接入服务端320也可以用于向设备200发送符合设备协议的报文。
由于上位机接入服务端310与上位机100之间交换的是应用层协议报文，而设备接入服务端320与设备200之间交换的是设备协议报文，因此，在本实施例所提供的报文转换系统中，在上位机接入服务端310与设备接入服务端320之间，需要实现对应用层协议报文和设备协议报文的转换。本实施例中，采用消息管理器330和协议管理控制器340两个结构配合工作的方式，高效地实现这一功能。
首先，无论是上位机接入服务端310产生的消息，还是设备接入服务端320产生的消息，均转发至消息管理器330，经由消息管理器330的接收和转发，再发送给协议管理控制器340。消息管理器330能够对上位机接入服务端310和设备接入服务端320的消息均进行接收和转发，因此，此时相当于两个服务端能够并行不悖地将消息发送给消息管理器330(后续再由消息管理器330发送给协议管理控制器340处理)，因此，解决现有上位机(或称应用端)与设备(或称下位机，例如物联网设备)的报文转换问题，解决多设备、大数据量并发处理问题，提高数据转换的效率，并且可以兼容不同厂商不同设备的通信方式，实现数据转换的高效性，提高设备200与上位机100通信的响应速度，解决上位机100处理报文(报文转换)的负担，使得上位机100高效处理信息。
本实施例所提供的报文转换系统具体可以运用于各种场景中。例如，可以运用于智慧路灯控制系统的实施。此时，相应的上位机100可以为路灯监控云平台(上位机100进一步可以为云平台的应用终端)，设备200(下位机)可以为智慧路灯(设备200进一步可以为智慧路灯终端)，其中的报文转换系统如图1中位于上位机100和设备200之间的结构所示，所述报文转换系统提供了路灯监控云平台与智慧路灯终端的链接。由上述内容可知，所述报文转换系统可以对设备报文的预处理，再实现对设备报文与云平台指令的报文转换，实现对多设备，大数据量并发处理问题，实现兼容不同厂商不同通信方式的终端管理。
本发明实施例提供另一种报文转换系统，如图2和图3所示。
所述报文转换系统包括：上位机接入服务端(未标注，包括后续提到的应用层协议服务端611和应用层客户端612)、设备接入服务端(未标注，包括后续提到的tcp服务模块621和udp服务模块622)、消息管理器630(请结合参考图3，包括后续提到的图2所示消息队列模块和线程池模块632)和协议管理控制器640(请结合参考图3，包括后续提到的图2所示协议管理器641和协议适配器642)。
所述上位机接入服务端用于与上位机400进行数据通信。所述设备接入服务端用于与设备500进行数据通信。消息管理器630用于接收和转发来自所述上位机接入服务端和所述设备接入服务端的消息。协议管理控制器640用于接收从消息管理器630转发来的消息，并且，协议管理控制器640用于将接收后的消息(报文)进行转换之后，转发至“转换后报文”对应的所述设备接入服务端或上位机接入服务端(本实施例进一步是转发至上位机接入服务端的应用层客户端612)。
更多关于上述结构的性质和优点，可参考前述实施例相应内容。例如，本实施例中，所述上位机接入服务端用于接收来自于上位机100的应用层协议报文。相应的，所述上位机接入服务端也可以用于向上位机100发送应用层协议报文。所述设备接入服务端用于接收来自于设备500的设备协议报文。相应的，所述设备接入服务端也可以用于向设备500发送设备协议报文。并且，相应的处理过程高效且不会相互影响，其原理可以参考前述实施例相应内容。
本实施例中，上位机400可以是来自云平台中。设备500(下位机)可以是嵌入式设备，例如嵌入式智慧终端。上位机400和设备500的个数均可以为多个。
本实施例中，图2显示，所述上位机接入服务端可以包括应用层协议服务端611和应用层客户端612。应用层协议服务端611用于接收来自于上位机400的应用层协议报文。应用层协议服务端611可以为http服务端。。应用层客户端612用于向上位机400发送符合应用层协议的报文。应用层客户端612可以为http客户端。可知，当应用层协议服务端611为http服务端，且应用层客户端612为http客户端时，在所述上位机接入服务端和上位机400之间交互的报文，为符合http协议的报文。
本实施例中，图2显示，所述设备接入服务端包括tcp服务模块621和udp服务模块622。并且图2进一步显示，本实施例是所述设备接入服务端通过udp服务模块622与设备500进行报文交互。但其它实施例中，所述设备接入服务端也可以是通过tcp服务模块621与设备500进行报文交互。
本实施例中，图2显示，所述报文转换系统还包括第一线程组651、第二线程组652和第三线程组653；所述第一线程组651包括第一线程池(未标注)，用于给应用层协议服务端611提供线程；第二线程组652包括第二线程池(未标注)，用于给所述设备接入服务端提供线程；第三线程组653包括第三线程池(未标注)，用于给消息管理器630和协议管理控制器640(具体可以为协议管理控制器640的协议管理器641)提供线程。
图3是图2所示报文转换系统的部分结构示意图。
图2和图3均显示了消息管理器630，消息管理器630包括消息队列模块(未示出)。
图3中显示了udp服务模块622进一步包括会话控制模块6221和端口列表6222(udpportlist)。
图3中显示了协议管理控制器640，协议管理控制器640包括图2中所示的协议管理器641和协议适配器642。协议管理控制器640包括协议管理器641(protocolmanager)和协议适配器642(protocolconvertadapter)，可以结合参考图2和图3。协议管理器641包括服务映射列表6411(或称报文转换表)。
图3也中设备500与报文转换系统中udp服务模块622、消息管理器630和协议管理控制器640的通信连接关系示意图。
本实施例所提供的报文转换系统的一种运行过程可以为：
上位机400发送http请求，具体可以为发送json报文给报文转换系统；其中，报文转换系统可以采用boost.asio编程实现服务器，此时，http服务端可以调用boost.asio异步读/写接口，接收上位机400发送的http请求；http服务端验证请求消息并解析出json报文的命令内容；http服务端创建一条上位机400请求消息放入消息队列模块的消息队列(messagequeue)中；这个过程中，第一线程组651创建一定数量的线程，并提供给http服务端，以保证http服务端(即应用层协议服务端611)实现相应功能；
消息管理器630中的消息队列模块接收上位机400消息，并提供安全的同步阻塞读/写接口；这个过程中，第三线程组653将创建一定数量的线程，用于从消息队列模块读取消息，交给协议管理控制器640处理(若没有收到上位机400的报文，则相应线程被消息队列模块阻塞住，直到有新消息过来)；
协议管理控制器640将负责管理协调各模块，处理协议转换与统一，形成转换后的报文；协议管理控制器640还维护设备500信息，这些信息包括设备类型、厂商、tcp连接地址、对应上位机400地址等信息；协议管理控制器640还解析出设备500(嵌入式设备)的id(例如ccuid)，以及基本包格式；协议管理控制器640还处理json报文通用头，根据ccuid调用对应的协议适配器642转换成例如设备协议；若相应的设备在线，则可以调用所述设备接入服务端tcp服务模块621将消息发送给相应的设备；与此同时，协议管理控制器640还可以处理设备500连接断开消息，维护相应设备的上/下线状态，响应设备的登录/心跳包等；这个过程中，第三线程组653创建一定数量的线程，并提供给协议管理控制器640，以保证协议管理控制器640实现相应功能；
所述设备接入服务端在向设备500发送转换后的相应报文时，第二线程组652将创建一定数量的线程，提供给所述设备接入服务端，保证所述设备接入服务端实现相应功能。
本实施例所提供的报文转换系统的一种运行过程可以为：
设备500发送十六进制报文(或二进制报文)给报文转换系统，可以是tcp服务模块621或udp服务模块622接收至例如相应的设备中；相应设备回复或上报命令，创建一条下位机消息放入消息队列模块的消息队列；这个过程中，第二线程组652将创建一定数量的线程，提供给所述设备接入服务端，保证所述设备接入服务端实现相应功能。
消息队列模块接收来自嵌入式设备(设备500)的消息，并提供线程安全的同步阻塞读/写接口；第三线程组653中的线程池将创建一定数量的线程，以用于从消息队列模块的消息队列中读取消息，交给协议管理控制器640处理(若没有收到相应设备的报文确认，则相应线程被消息队列模块阻塞住，直到有新消息过来)；
当消息队列模块读取消息，并交给协议管理控制器640后，协议管理控制器640将负责管理协调各模块，处理协议转换与统一，并调用协议适配器642验证消息格式是否符合包格式，之后转换成json报文；若相应设备有对应的上位机400地址，则通过http客户端，将消息发给上位机400，http客户端可以采用异步非阻塞io设计，并采用定时读/写上位机400回复数据，并写入日志(log)。
从上述第一线程组651、第二线程组652和第三线程组653的配合作用可知，本实施例提供的报文转换系统采用多线程技术，提出线程组的线程管理机制。所述报文转换系统将消息放入到消息队列中后，等待报文转换系统分配线程读取队列消息，当报文转换系统分配完线程读取完消息之后，会分派线程将报文依照服务映射列表进行映射，当报文映射完毕后，根据报文类型发送到http客户端、tcp服务模块621或udp服务模块622中，然后传递到相应的终端设备或是云平台等应用。
也就是说，本实施例所提供的报文转换系统可以具有多线程的线程组管理机制，在多线程处理时，可以根据功能的不同进行线程分组，通过将线程进行分组管理，可以方便管理整个报文转换系统的线程管理，当某个模块的线程出现堵塞或崩溃等现象时，报文转换系统的其他模块功能不受影响，可以进行正常工作。
由于采用多线程技术、线程组的线程管理机制和多线程的线程组管理机制，本实施例所提供的报文转换系统可以应对多设备以及大数据量并发处理的问题，提升报文转换系统的鲁棒性(顽健性)和稳定性。同时，所述报文转换系统采用多并发协议漏洞机制，使得报文转换系统与云平台(上位机400)连接更加稳定高效。
此外，利用udp协议的设备的端口经常改变，如果采用传统方式，会造成线程浪费。并且，现有传统方式中，当udp协议的处理线程出现堵塞时，会造成协议管理控制器整体瘫痪，最终导致报文转换系统无法工作。
本实施例中，如前面所提到的，所述设备接入服务端包括tcp服务模块621和udp服务模块622，并且，udp服务模块622包括会话控制模块6221和端口列表6222。通过在udp服务模块622设置会话控制模块6221和端口列表6222，本实施例形成一种udp服务端链路预处理机制，使得报文转换系统在处理udp协议时，减轻整个系统因链路经常更改而对系统造成的负荷。
具体的，请结合参考图3，显示了会话控制模块6221和端口列表6222实现udp服务端链路预处理的机制，相应的配合工作过程如下：
当设备500将登录包(报文)提供给报文转换系统后，设备500的uid号码会与登录的ip地址和端口号进行绑定，并将消息保存到udp服务模块622；此后，此设备500发送报文给报文转换系统，系统会生成一个包括uid消息的指针捆绑在报文主体里；从此，此设备500的地址变换与更改不会在协议管理器641进行管理，每次上报携带的ip地址和端口号被会话控制模块6221接收后，都会在udp服务模块622中与端口列表6222进行比较和修改等相应处理(如果比较结果一致，则不需要修改；如果比较结果不一致，将新的ip地址和端口号组合更新修改到列表中，以达到对端口号改变的应对)；报文在后续的协议管理控制器640里，只会进行内容修改(不会对地址做处理)，对应的地址为uid指针，当报文消息处理好，传输回此设备时，根据这个uid指针映射相应的ip地址和端口号。通过这种工作机制，本实施例的报文转换系统能够减少协议管理器641的内存损耗，提高系统的稳定性。
也就是说，本实施例中，由于在udp服务模块622设置了会话控制模块6221和端口列表6222，能够实现对udp服务模块622中添加端口对比修正机制，将原本容易造成堵塞的端口修正，设置在消息进入协议管理控制器640之前进行，减少协议管理控制器640处理udp端口号(变化)的工作线程，提升报文转换系统的工作效率，提升报文转换系统的稳定性。
本发明实施例还提供了一种报文转换方法，包括：
对符合应用层协议的第一请求报文进行解析以产生第一请求消息；将第一请求消息放入消息队列中；从消息队列中读取第一请求消息，进行协议转换与统一，形成符合设备协议的第一转换报文；
对符合设备协议的第二请求报文进行解析以产生第二请求消息；将第二请求消息放入消息队列中；从消息队列中读取第二请求消息，进行协议转换与统一，形成符合应用层协议的第二转换报文。
第一请求报文和第二转换报文均可以为json报文。第一转换报文和第二请求报文可以为二进制或十六进制报文，总之，可以是符合各类设备协议的报文。
本实施例中，第二请求报文为登录包时，登录包括设备uid号码、ip地址和端口号。
本实施例中，上述对第二格式的第二请求报文进行解析以产生第二请求消息的过程，可以具体包括以下步骤：
生成ip地址和端口号的组合列表；
将第二请求报文中携带的ip地址和端口号与组合列表中的信息进行比较和修改处理，将包括uid号码信息的指针与第二请求报文捆绑；
以捆绑指针的第二请求报文产生第二请求消息。
上述比较和修改处理的过程可以包括：将第二请求报文中携带的ip地址和端口号这一对组合，与组合列表中已经存储的ip地址和端口号组合进行对比，如果是已有的组合(即这一对组合与已有的某对组合相同)，则不在这个组合列表中修改相应信息，即不必增加这一对组合于组合列表中；反之，如果这一对组合没有在组合列表中，这将这一对组合的信息更新到组合列表中。由此可知，第一对ip地址和端口号的组合会加入空白的组合列表中。
虽然本发明披露如上，但本发明并非限定于此。任何本领域技术人员，在不脱离本发明的精神和范围内，均可作各种更动与修改，因此本发明的保护范围应当以权利要求所限定的范围为准。