CN113301122A - 医疗机器人分布式***实时通信方法、装置及电子设备 - Google Patents

Abstract

本发明涉及一种医疗机器人分布式***实时通信方法、装置及电子设备的技术方案，包括：任意两两医疗机器人的客户端进行通信时，以通信发起方作为服务端；服务端与客户端根据报文协议、数据发送协议及配置文件，与通信接收方进行握手连接、终端连接及通信实时检测，以完成实时通信。本发明的有益效果为：具有较高的适应性，可实现同一局域网线任意设备间的通信传输，为当前任意需要进行通信的传输提供需要。

Description

医疗机器人分布式***实时通信方法、装置及电子设备

技术领域

本发明涉及医疗和计算机领域，具体涉及了一种医疗机器人分布式***实时通信方法、装置及电子设备。

背景技术

随着现代社会的进步和发展，医疗机器人的研究与应用也越来越重要。与传统手术相比，医疗机器人的使用可以代替医生在屏蔽室进行操作，从而避免由于射线辐射引发的一系列疾病。目前，一台医疗机器人不能同时满足手术需要的所有功能，而且机器人价格昂贵，不能普遍应用于各个医院，如何将医院现有设备资源集合起来，实现医院现有设备的实时通信，构建一个医疗机器人***，将有效辅助临床手术的进行。另外，对于不同临床手术，对应的机器人的操作方式也各不相同，如何实现多个设备之间的通信及任意数据的传输，是构建一个医疗机器人***的关键。因此设计一个统一的传输通信协议是很有必要的。

OpenIGTLink致力于为图像引导治疗环境构建标准化、可扩展的网络协议，为设备和软件之间的通信提供了标准，以共享和转换信息，这些信息被归纳为三种类型:成像、控制、跟踪。但是，该协议没有提到处理实时会话管理，例如节点之间的握手、脱离过程，以及最重要的:网络拥塞时的调度策略和故障处理过程。此外，它的消息协议主要依赖于消息的功能:***控制、图像、跟踪。随着医疗机器人的普及，它不能覆盖所有的信息。机器人***的不断增长将导致***的消息类***，这将使通信模块在应用程序的设计中变得非常大，成本和实施难度比较高。

发明内容

本发明的目的在于至少解决现有技术中存在的技术问题之一，提供了一种医疗机器人分布式***实时通信方法、装置及电子设备，实现同一局域网的任意医疗机器人的通信。

本发明的技术方案包括一种医疗机器人分布式***实时通信方法，其特征在于，该方法包括：任意两两医疗机器人的客户端进行通信时，以通信发起方作为服务端；所述服务端与所述客户端根据报文协议、数据发送协议及配置文件，与通信接收方进行握手连接、终端连接及通信实时检测，以完成实时通信。

根据所述的医疗机器人分布式***实时通信方法，其中任意两两医疗机器人的客户端进行通信包括：所述客户端之间以TCP/IP方式进行点对点通信。

根据所述的医疗机器人分布式***实时通信方法，其中报文协议包括公共信息及定制数据，所述公共信息用于确定唯一的报文发起方，所述公共信息包括报文ID、通信接收方ID、时间戳及数据链路控制；所述时间戳用于记录通信过程的时间信息，以及，用于为通信诊断提供时间查询功能；所述报文ID包括账号ID及***定制信息，所述账号ID包括设备的物理信息；所述***定制信息包括可定制的通信信息。

根据所述的医疗机器人分布式***实时通信方法，其中***定制信息包括：在每个所述医疗机器人设置有对应的配置文件，所述配置文件用于描述所述医疗机器人不同类型定制信息，所述配置文件可以自定义设置数据类型；所述配置文件被可以背读取，所述***定制信息的长度根据每次读取的所述内包括的最长的所述***定制信息长度决定。

根据所述的医疗机器人分布式***实时通信方法，其中报文协议还包括报文传输，所述报文传输将报文设置为请求头和请求体，所述请求头用于存储公共信息包括报文ID、通信接收方ID、时间戳及数据链路控制；所述请求体用于存储目标医疗机器人的地址、端口及设备唯一标识；所述报文传输的数据包大小为1024字节，所述请求头为1004字节，所述请求体为20字节；所述请求头第0-7位为报文ID，第8-11位为账号ID，第12-15位对应的时间戳，第16-19位为数据链路控制。

根据所述的医疗机器人分布式***实时通信方法，其中服务端与所述客户端的通信通过多个通信模块实现，所述通信模块包括接收通道、发送通道及实时诊断任务；所述接收通道用于管理接收的报文信息，包括报文编码任务、报文接收队列以及用于接收报文管理线程；所述发送通道用于管理接收的报文信息，包括报文编码任务、报文接收队列以及用于接收报文管理线程；所述实时诊断任务用于通信过程中的通信状态实时检测；所述通信模块的所述接收通道、所述发送通道及所述实时诊断任务通过多线程实现。

根据所述的医疗机器人分布式***实时通信方法，其中握手连接包括：当任意两个医疗机器人需要进行通信传输时，通信发起方将连接相关类中的报文编码成相应的报文信息发送给通信接收方，实现两医疗机器人的握手连接，同时为当前连接的通信两段间建立对应的所述通信模块，所述相关类包括握手连接消息、握手连接确认消息以及建立通信模块的消息；具体地，当任意两个医疗机器人需要进行通信时，设备第一医疗机器人会作为客户端请求连接第二医疗机器人的服务器端，将第一医疗机器人的IP地址赋值给的定制数据信息部分的前四个字节，通过解码任务将所述握手连接消息编码成相应的握手报文，开启传输任务线程，将握手报文发送给服务器端；当所述服务器端收到握手报文，通过解码任务将此报文解码获取客户端的IP地址，然后第二医疗机器人的客户端会根据IP地址进行反连第二医疗机器人的服务器端，同时编码握手连接确认消息发送握手确认报文。

根据所述的医疗机器人分布式***实时通信方法，其中终端连接包括：创建中断连接类消息，所述中断连接类消息包括断开连接信息、确认断开连接信息、关闭通信模块信息；当通信两端的一方需要进行中断通信传输时，将中断连接类信息编码成对应的报文，发送给另一端即可中断本次通信；具体地，对于正在进行通信的第三医疗机器人和第四医疗机器人，当第三医疗机器人需要中断数据传输通信时，将断开连接信息编码成对应的报文发送给第四医疗机器人，第四医疗机器人收到断开连接信息时，将确认断开连接信息编码成断开确认报文发送给第三医疗机器人，当第三医疗机器人收到断开确认信息会对关闭通信模块信息进行编码，将对应的编码信息发给第四医疗机器人，确认中断通信模块。

根据所述的医疗机器人分布式***实时通信方法，其中通信实时检测包括：当通信连接建立成功且通信模块建立，将诊断类信息编码成对应报文，通信两端周期性的进行互相发送，来实时检测连接状态；

所述实时诊断类信息用于通信模块状态的实时检测，在通信两端握手连接成功且通信模块建立的情况下，开启诊断任务，对通信模块进行实时检测；所述诊断任务通过心跳报文实时计算收到的消息长度来检测通信状态，根据接收报文的时间，对通信模块的通信传输连接是否出现异常进行判断；当传输时间超过设置阈值时，执行连接修复的过程。

本发明的技术方案还包括一种医疗机器人分布式***实时通信装置，该装置包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现任一项所述的方法步骤。

本发明的技术方案还包括一种电子设备，其特征在于，包括如任一项所述的方法步骤。

本发明的技术方案还包括一种嵌入式通用集成电路卡的***升级装置，该装置包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现上述任一项的方法步骤。

本发明的技术方案还包括一种电子设备，包括上述一项的方法步骤。

本发明的有益效果为：具有较高的适应性，可实现同一局域网线任意设备间的通信传输，为当前任意需要进行通信的传输提供需要。

附图说明

下面结合附图和实施例对本发明进一步地说明；

图1所示为根据本发明实施方式的总体流程图。

图2所示为现有技术的本地设备间通信架构示意图。

图3所示为根据本发明实施方式的本地设备间通信架构示意图。

图4所示为根据本发明实施方式的公共信息组成示意图。

图5所示为根据本发明实施方式的报文ID信息组成示意图。

图6所示为根据本发明实施方式的配置文档示例。

图7所示为根据本发明实施方式的报文信息组成示意图。

图8所示为根据本发明实施方式的通信模块组成示意图。

图9所示为根据本发明实施方式的通信模块建立时序图。

图10所示为根据本发明实施方式的握手连接时序图。

图11所示为根据本发明实施方式的中断连接时序图。

图12所示为根据本发明实施方式的通信检测时序图。

图13所示为根据本发明实施方式的装置图。

具体实施方式

本部分将详细描述本发明的具体实施例，本发明之较佳实施例在附图中示出，附图的作用在于用图形补充说明书文字部分的描述，使人能够直观地、形象地理解本发明的每个技术特征和整体技术方案，但其不能理解为对本发明保护范围的限制。

本发明的描述中，除非另有明确的限定，设置等词语应做广义理解，所属技术领域技术人员可以结合技术方案的具体内容合理确定上述词语在本发明中的具体含义。

参考图1，本发明的技术方案包括以下流程：任意两两医疗机器人的客户端进行通信时，以通信发起方作为服务端；服务端与客户端根据报文协议、数据发送协议及配置文件，与通信接收方进行握手连接、终端连接及通信实时检测，以完成实时通信。其中医疗机器人为分布式设备。

图2为传统TCP/IP通信示意图，传统的TCP/IP通信方式在握手连接上有一定的滞后与延时，数据传输的实时性得不到保障。考虑到实际通信需求，同时为满足分布式***下多种组件间的实时通信需要，我们这里对此通信方式进行来改进，将需要连接的点对点双方都设计成客户端和服务器端，即发送请求连接的客户端同时也是被请求的服务器端，不仅可以做到点与点之间的双向通信，同时在通信传输效率上也得到了提高。

参考图3，本发明的技术方案包括：

会话控制，采用改进的TCP/IP通信模式可对通信连接两端进行单独管理，而且不会影响其中某一方向的通信传输。

报文协议设计，本发明技术方案设计的报文协议主要包括两个方面:LienaMessage(报文设计)和LienaDatagram(报文传输)。下面将对本通信协议的报文设计进行详细介绍：

LienaMessage消息设计。LienaMessage设计为需要进行传输的数据，为了统一有效识别与统一传输的数据内容，这里将LienaMessage分成两块来进行设计，分别为公共信息设计和定制化信息设计。下面将分别对这两块进行详细介绍。

公共信息，公共信息即在通信连接两端设备公有的信息属性，这一块在数据传输过程中起着重要作用，本设计的公共信息数据部分的目的是为了把各个通信的设备的共有属性进行特定化、唯一化，通过识别公共信息，就可以对应到特定具体的某一台设备。

为了方便且准确的对应某一台具体设备，这是把公共信息设计为以下四个部分，即message ID、target ID、DLC、timeStamps。整体设计如图4所示：

其中target ID长度设计为4个字节，代表的是被连接端的ID信息。timeStamps长度设计为4个字节，用于记录通信过程中的时间记录，同时也可用于辅助通信诊断等。

由于目前设备在种类和数量上的多样性，以及设备的更新换代等现实因素，这里我们把message ID的长度设计为8个字节，由Origin ID(账号ID)和system customizedmessage两个部分组成。其中Origin ID的长度设计为4个字节，代表连接端设备的物理属性信息，包括设备分类、生产商、设备类型、版本等；system customized message的长度同样为4个字节，包括了一些定制化的通信信息。其原理结构示意图如图5所示。

同时，本发明的技术方案根据机器人***的功能划分，这里我们把机器人***整体分为“手、眼、脑、臂”四类。“手”代表机器人的执行单元，“眼”代表机器人信号采集单元，“脑”即机器人***控制指令单元，“臂”即信号传输单元，实现将“脑”的指令送至“手”实现相应操作。对于每一个类别下的设备，我们都可以按照其生产商、设备类型、设备的生产版本号以及生产号等信息来特定化设备，另外同一厂家下同一设备的不同生产批次等信息的加载保证来此设备编号的唯一性。

此外，system customized message为信息定制预留部分，可根据实际需要来进行补充数据。

定制数据部分，定制数据部分设计为相关操作需要专门传输的内容，根据不同操作需求其对应的传输内容也不同，而且传输的数据大小长度也各有差别。为了方便多样化格式的数据信息管理，这里我们基于xml设计了一个专门的定制数据信息的xml文档，通过读取此文档来读取对应的message信息。定制数据部分的message的长度根据每次读取的xml文档内包括的最长的message长度决定。本发明技术方案设计的xml文档示例如图6所示。

每一份xml文档对应当前机器人***下的所有设备信息以及每台设备对应的message信息，由于目前数据类型的种类是固定的，我们可以根据每个message所包括内容的数据类型来实现对应数据的读取。以上图示例中的xml文档为例，当前设备device1下面包括了三条message信息，对应message1，其包括了三个int类型的数据，我们知道int型数据的长度为4bytes，这里我们给读取的此条message长度固定为4bytes，由于每个设备对应的message数据长度各不相同，这里我们设计的message长度为此设备下最长的message长度为定制化信息数据的长度。这样，我们只需要知道每个message信息对应的数据类型，就可以对此message进行操作。基于以上标准来设计message，我们可以直接读取获取其信息。对于有需求的相关人员只需要提供给操作人员这样一份xml文档，即可实现message数据信息的加载与读取。

LienaDatagram报文设计，在通信传输过程中，数据是通过字节流的方式来进行传输的，任何需要传输的message都需要编码为报文，才可以被发送出去，同时收到的报文需要解码为message才可以供我们使用。本发明技术方案设计的LienaDatagram报文总长度固定为1024bytes,分为header和body两个部分，其中header部分长度设计为20bytes。同上述LienaMessage设计对应，本发明技术方案LienaDatagram报文设计的前8位即第0-7位对应的是message ID，第8-11位对应Origin ID，第12-15位对应timeStamps，第16-19位代表的是DLC。Body部分的长度为1004bytes。具体body部分每一位代表的数据，根据编码的message数据类型来来确定。其组成结构示意图如图7所示。

因此，服务器端可以直接根据收到的报文信息来进行相应操作，比如，报文的0-7位可以直接编码成message ID，从而获取客户端设备的唯一物理信息，包括请求连接设备的类别、型号等相关参数信息；8-11位编码成Origin ID。对于Body部分的报文读取，会根据此设备对应的message内容来进行编码，从而读取到此报文的body部分。

这样，在进行多个设备之间相互通信时，服务器端就可以直接根据收到的报文信息，获取当前请求连接的客户端信息，包括客户端地址、端口号、设备唯一标识等信息，来进行与特定的设备进行连接通信，做到多个客户端服务端相互通信时互不干扰，不仅提高了通信的传输效率，同时也对当前医疗机器人分布式***的通信提供。

通信实现，参考图8-12

基于以上的实施方法，这里将对本发明技术方案设计的通信实现原理进行详细介绍。为了实现同一局域网环境下的任意两个设备之间的实时通信管理，这里我们为每一个需要进行数据传输的两方专门开一个通信模块，所有的通信两端的操作都在此模块内进行，通信两端可在此模块进行数据传输，同时此通信模块可对当前通信的两端进行管理，包括连接、断开、实时检测仪连接状态。每个通信端都可以既作为客户端请求连接服务器端，又可以作为服务器端与请求的客户端进行连接。当有别的设备需要与正在进行通信的设备连接时，会自动开一个新的通信模块进行通信传输，这样就实现了同一局域网下任意两个设备间的通信，而且不需要在上一个客户端请求连接完成之后在进行连接，任意两设备间通信互不影响。本发明技术方案设计的通信模块原理示意图如下图8所示。

为了实现对各个通信模块的实时有效管理，(多线程管理)这里对每个通信模块都分别设有接收通道、发送通道和实时诊断任务。对于接收通道用来专门管理接收的报文信息，包括报文编码任务decodingTask、报文接收队列inoutQueue以及用于接收报文管理线程receptionTask三个部分；发送通道用于管理报信息发送管理通道，包括编码任务encodingTask、报文输出队列outputQueue以及用于发送报文的线程transmissionTask。除此之外，还设有诊断任务diagnosisTask，用于通信过程中的通信状态实时检测。其实现流程图如下图9通信模块建立时序图所示。

本发明技术方案设计了三类message用于本通信协议，包括连接类message、中断连接类message、实时诊断类message。当任意两个组件需要进行通信传输时，只要将连接相关类中的message编码成相应的报文信息发送给对方，即可实现两组件的握手连接，同时为当前连接的通信两段建立一个通信模块；当通信两端的一方需要进行中断通信传输时，只要将中断连接类message编码成对应的报文，发送给另一端即可中断本次通信；当通信连接建立成功且通信模块建立，将诊断类message编码成对应报文，通信两端周期性的进行互相发送，来实时检测连接状态。下面将对这三个过程的实现进行详细解释：握手连接，基于上述设计的连接类message，本发明技术方案采用三次握手连接。首先客户端发送请求连接至服务器端，当服务器端收到握手请求，会发握手确认信息给客户端，当客户端收到握手确信信息，证明客户端与服务器端成功建立连接，然后基于此通信两端建立一个专门通信管理模块。

这里连接类message包括：握手连接消息handshakeMessage、握手连接确认消息handshakeCommitMessage以及建立通信模块的消息channelOpenedMessage。基于第一节介绍的通信架构，当任意两个设备AB需要进行通信时，设备A会作为客户端请求连接设备B的服务器端，首先设备A的IP地址,将此IP地址赋值给handshakeMessage的定制数据信息部分的前四个字节，通过encodingTask将handshakeMessage编码成相应的握手报文，然后开启transmissionTask线程，将此报文发送给服务器端；当服务器端收到握手报文，通过encodingTask将此报文解码获取客户端的IP地址，然后设备B的客户端会根据此IP地址进行反连设备B的服务器端，同时会编码handshakeCommitMessage发送握手确认报文。当设备A的服务器端收到握手确认报文，会编码channelOpenedMessage并发送给设备B的客户端，同时为设备A、B的通信建立一个专门的通信通信管理模块，并确认设备A、B通信连接成功。具体握手连接实现时序图如图10所示。

中断连接，在实际通信过程中，会出现需要中断通信两方但不断开连接的情况。基于这种情况，中断连接类message的设计用于中断已经建立连接的通信两端，此message类设计包括：断开连接信息disengagementMessage、确认断开连接disengagementCommitMessage、关闭通信模块channelClosedMessage。

对于正在进行通信的两个设备A、B，当其中A需要中断数据传输通信时，会将disengagementMessage编码成对应的报文发送给另一方B，要求停止通信。当另一方B收到断开连接信息时，将disengagementCommitMessage编码成断开确认报文发送给A，当A收到断开确认信息会对channelClosedMessage进行编码，将对应的编码信息发给B，最终确认中断本通信模块。具体中断连接实现时序图如图11所示。

通信实时检测，任意两个进行通信连接的设备，我们需要对其连接状态实时检测，比如当有一方的网络断开时，致使连接两方的通信断开、或者一方的服务器端关闭，导致其只能发送消息而不能接收信息。在这种情况下，并不会影响到当前通信模块的数据传输，而且也不会导致本通信模块异常退出。因此，为了避免此类情况的发生，我们需要对当前模块的通信状态进行检测。

实时诊断类message的设计用于通信模块状态的实时检测，在通信两端握手连接成功且通信模块建立的情况下，我们开启一个诊断任务diagnosisTask，来对本模块进行实时检测，diagnosisTask通过实时计算收到的Message长度来检测通信状态。实时诊断类message设有一个心跳报文heartbeatMessage。当诊断任务开启时，通信两端各自会开启一个编码线程encodingTask，将heartbeatMessage编码成对应的报文发给对方，当另一方收到此报文时，将此报文解码成对应的message信息，当收到的message判断是heartbeatMessage，会同样编码heartbeatMessage成对应的报文发给对方，当diagnosisTask中的收到的报文长度始终大于0，这样证明通信连接状态正常。当diagnosisTask中的收到的报文长度为0，且连续5s的时间报文收到的报文长度始终为0，即超过5s的时间没有收到heartbeatMessage信息，我们会认为本通信模块的通信传输连接出现异常，然后开启连接修复的过程。连接诊断实现流程图如图12所示。

图13,所示为根据本发明实施方式的装置示意图。装置包括存储器100及处理器200，其中处理器200存储有计算机程序，计算机程序用于执行：任意两两医疗机器人的客户端进行通信时，以通信发起方作为服务端；服务端与客户端根据报文协议、数据发送协议及配置文件，与通信接收方进行握手连接、终端连接及通信实时检测，以完成实时通信。其中，存储器100用于存储数据。

应当认识到，本发明实施例中的方法步骤可以由计算机硬件、硬件和软件的组合、或者通过存储在非暂时性计算机可读存储器中的计算机指令来实现或实施。所述方法可以使用标准编程技术。每个程序可以以高级过程或面向对象的编程语言来实现以与计算机***通信。然而，若需要，该程序可以以汇编或机器语言实现。在任何情况下，该语言可以是编译或解释的语言。此外，为此目的该程序能够在编程的专用集成电路上运行。

此外，可按任何合适的顺序来执行本发明技术方案描述的过程的操作，除非本发明技术方案另外指示或以其他方式明显地与上下文矛盾。本发明技术方案描述的过程(或变型和/或其组合)可在配置有可执行指令的一个或多个计算机***的控制下执行，并且可作为共同地在一个或多个处理器上执行的代码(例如，可执行指令、一个或多个计算机程序或一个或多个应用)、由硬件或其组合来实现。所述计算机程序包括可由一个或多个处理器执行的多个指令。

进一步，所述方法可以在可操作地连接至合适的任何类型的计算平台中实现，包括但不限于个人电脑、迷你计算机、主框架、工作站、网络或分布式计算环境、单独的或集成的计算机平台、或者与带电粒子工具或其它成像装置通信等等。本发明的各方面可以以存储在非暂时性存储介质或设备上的机器可读代码来实现，无论是可移动的还是集成至计算平台，如硬盘、光学读取和/或写入存储介质、RAM、ROM等，使得其可由可编程计算机读取，当存储介质或设备由计算机读取时可用于配置和操作计算机以执行在此所描述的过程。此外，机器可读代码，或其部分可以通过有线或无线网络传输。当此类媒体包括结合微处理器或其他数据处理器实现上文所述步骤的指令或程序时，本发明技术方案所述的发明包括这些和其他不同类型的非暂时性计算机可读存储介质。当根据本发明所述的方法和技术编程时，本发明还包括计算机本身。

计算机程序能够应用于输入数据以执行本发明技术方案所述的功能，从而转换输入数据以生成存储至非易失性存储器的输出数据。输出信息还可以应用于一个或多个输出设备如显示器。在本发明优选的实施例中，转换的数据表示物理和有形的对象，包括显示器上产生的物理和有形对象的特定视觉描绘。

上面结合附图对本发明实施例作了详细说明，但是本发明不限于上述实施例，在技术领域普通技术人员所具备的知识范围内，还可以在不脱离本发明宗旨的前提下做出各种变化。

Claims (11)

1.一种医疗机器人分布式***实时通信方法，其特征在于，该方法包括：

任意两两医疗机器人的客户端进行通信时，以通信发起方作为服务端；

所述服务端与所述客户端根据报文协议、数据发送协议及配置文件，与通信接收方进行握手连接、终端连接及通信实时检测，以完成实时通信。

2.根据权利要求1所述的医疗机器人分布式***实时通信方法，其特征在于，所述任意两两医疗机器人的客户端进行通信包括：所述客户端之间以TCP/IP方式进行点对点通信。

3.根据权利要求1所述的医疗机器人分布式***实时通信方法，其特征在于，所述报文协议包括公共信息及定制数据，所述公共信息用于确定唯一的报文发起方，所述公共信息包括报文ID、通信接收方ID、时间戳及数据链路控制；所述时间戳用于记录通信过程的时间信息，以及，用于为通信诊断提供时间查询功能；所述报文ID包括账号ID及***定制信息，所述账号ID包括设备的物理信息；所述***定制信息包括可定制的通信信息。

4.根据权利要求3所述的医疗机器人分布式***实时通信方法，其特征在于，所述***定制信息包括：

在每个所述医疗机器人设置有对应的配置文件，所述配置文件用于描述所述医疗机器人不同类型定制信息，所述配置文件可以自定义设置数据类型；

所述配置文件被可以背读取，所述***定制信息的长度根据每次读取的所述内包括的最长的所述***定制信息长度决定。

5.根据权利要求3所述的医疗机器人分布式***实时通信方法，其特征在于，所述报文协议还包括报文传输，所述报文传输将报文设置为请求头和请求体，所述请求头用于存储公共信息包括报文ID、通信接收方ID、时间戳及数据链路控制；所述请求体用于存储目标医疗机器人的地址、端口及设备唯一标识；所述报文传输的数据包大小为1024字节，所述请求头为1004字节，所述请求体为20字节；所述请求头第0-7位为报文ID，第8-11位为账号ID，第12-15位对应的时间戳，第16-19位为数据链路控制。

6.根据权利要求1所述的医疗机器人分布式***实时通信方法，其特征在于，所述服务端与所述客户端的通信通过多个通信模块实现，所述通信模块包括接收通道、发送通道及实时诊断任务；

所述接收通道用于管理接收的报文信息，包括报文编码任务、报文接收队列以及用于接收报文管理线程；

所述发送通道用于管理接收的报文信息，包括报文编码任务、报文接收队列以及用于接收报文管理线程；

所述实时诊断任务用于通信过程中的通信状态实时检测；

所述通信模块的所述接收通道、所述发送通道及所述实时诊断任务通过多线程实现。

7.根据权利要求6所述的医疗机器人分布式***实时通信方法，其特征在于，所述握手连接包括：

当任意两个医疗机器人需要进行通信传输时，通信发起方将连接相关类中的报文编码成相应的报文信息发送给通信接收方，实现两医疗机器人的握手连接，同时为当前连接的通信两段间建立对应的所述通信模块，所述相关类包括握手连接消息、握手连接确认消息以及建立通信模块的消息；

具体地，当任意两个医疗机器人需要进行通信时，设备第一医疗机器人会作为客户端请求连接第二医疗机器人的服务器端，将第一医疗机器人的IP地址赋值给的定制数据信息部分的前四个字节，通过解码任务将所述握手连接消息编码成相应的握手报文，开启传输任务线程，将握手报文发送给服务器端；

当所述服务器端收到握手报文，通过解码任务将此报文解码获取客户端的IP地址，然后第二医疗机器人的客户端会根据IP地址进行反连第二医疗机器人的服务器端，同时编码握手连接确认消息发送握手确认报文。

8.根据权利要求6所述的医疗机器人分布式***实时通信方法，其特征在于，所述终端连接包括：

创建中断连接类消息，所述中断连接类消息包括断开连接信息、确认断开连接信息、关闭通信模块信息；当通信两端的一方需要进行中断通信传输时，将中断连接类信息编码成对应的报文，发送给另一端即可中断本次通信；

具体地，对于正在进行通信的第三医疗机器人和第四医疗机器人，当第三医疗机器人需要中断数据传输通信时，将断开连接信息编码成对应的报文发送给第四医疗机器人，第四医疗机器人收到断开连接信息时，将确认断开连接信息编码成断开确认报文发送给第三医疗机器人，当第三医疗机器人收到断开确认信息会对关闭通信模块信息进行编码，将对应的编码信息发给第四医疗机器人，确认中断通信模块。

9.根据权利要求6所述的医疗机器人分布式***实时通信方法，其特征在于，所述通信实时检测包括：

当通信连接建立成功且通信模块建立，将诊断类信息编码成对应报文，通信两端周期性的进行互相发送，来实时检测连接状态；

所述实时诊断类信息用于通信模块状态的实时检测，在通信两端握手连接成功且通信模块建立的情况下，开启诊断任务，对通信模块进行实时检测；

所述诊断任务通过心跳报文实时计算收到的消息长度来检测通信状态，根据接收报文的时间，对通信模块的通信传输连接是否出现异常进行判断；当传输时间超过设置阈值时，执行连接修复的过程。

10.一种医疗机器人分布式***实时通信装置，该装置包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至8任一项所述的方法步骤。

11.一种电子设备，其特征在于，包括如权利要求1至9任一项所述的方法步骤。

Images