本发明设计半导体测试领域,具体涉及一种支持多种通信协议的可扩展通信框架及通信方法。
背景技术:
现有技术中对于不同的通信协议使用相应的通信库来开发,从而建立与设备的通信。比如socket(tcp/udp)、gpib、com等,每一类协议在不同的开发语言(c/c++/java/c#等)都有各自的接口函数定义(包括名称和参数)。
由于协议本身的不同和开发语言的不同,相关通信库的接口定义也是五花八门,各有不同(主要体现在函数名称和参数),比如同样表示连接,有的叫open,有的叫connect;同样表示断开连接,有的叫close,有的叫disconnect。
通信库接口的不同,会导致在集成不同协议开发时,业务逻辑层的代码需要面对同功能却不同名称的接口函数调用,这无疑是破坏了程序的可读性和可维护性。业界存在对于不同通信协议的封装,也囊括了诸多协议(包括各个领域的应用),比如visa。该技术方案重点是在于对不同通信协议的可扩展支持,但缺少对不同业务模型的抽象设计。
现有技术中软件平台在与设备通信时,面临的主要问题是因设备的不同带来的通信协议不同,导致通信流程的实现无法统一和标准化,包括通信接口不统一和通信模型不统一。因此,设计一种通信协议和通信模型同时可扩展的通信框架是非常有必要的。
技术实现要素:
本发明的目的是提供一种支持多种通信协议的可扩展通信框架及通信方法,当导入不同通信协议的不同设备时,只需根据既定的统一通信接口来实现新增的通信协议,上层业务逻辑代码不会受到任何影响,这使得软件代码维护和功能新增变得极为方便,最终使得产品软件质量有了保障。
为了实现上述目的,本发明采用如下技术方案:一种支持多种通信协议的可扩展通信框架,用于连接软件平台和设备,包括通信接口和通信模型,其中,所述通信接口包括设备接口、通道接口和协议接口,所述通信模型在通信时调用设备接口、通道接口和协议接口;
当所述软件平台连接设备时,在所述设备接口中新建类,且所述类继承自所述设备接口;在所述通道接口中新建通道协议,且所述通道协议继承自所述通道接口;在所述协议接口中新建子协议接口,且所述子协议接口继承自所述协议接口;所述软件平台和设备之间通过所述通信模型进行通信,且在通信过程中调用类、通道协议和子协议接口。
进一步地,所述通信模型包括数据下发事务命令模型和数据接收服务命令模型。
进一步地,所述协议接口包括ichannelsender接口,用于实现数据的发送;isendagreement接口,用于定义数据发送时的规约;ichannelreceiver接口,用于实现数据的接收;ireceiveagreement接口,用于定义数据接收时的规约。
进一步地,当所述软件平台连接设备时,在所述协议接口中新建sender接口,sendagreement接口,receiver接口和receiveagreement接口。
进一步地,所述设备包括至少一个通道,每个通道在所述通信框架中对应一个通道协议和一个子协议接口。
一种支持多种通信协议的可扩展通信框架进行设备通信的方法,包括如下步骤:
s01:在设备接口中新建类,所述类继承自所述设备接口;设备通过类连接软件平台;其中,所述通信框架用于连接软件平台和设备;
s02:在通道接口中新建通道协议,所述通道协议继承自所述通道接口,设备通过通道协议连接软件平台;
s03:在协议接口中新建子协议接口,所述子协议接口继承自所述协议接口,设备通过子协议接口与软件平台实现进行数据发送和接收;
s04:所述设备和软件平台采用通信模型进行通信,且在通信过程中,调用类、通道协议和子协议接口。
进一步地,所述通信模型包括数据下发事务命令模型和数据接收服务命令模型。
进一步地,所述协议接口包括ichannelsender接口,用于实现数据的发送;isendagreement接口,用于定义数据发送时的规约;ichannelreceiver接口,用于实现数据的接收;ireceiveagreement接口,用于定义数据接收时的规约;所述步骤s03中在协议接口中新建sender接口,sendagreement接口,receiver接口和receiveagreement接口。
进一步地,所述数据下发事务命令模型通过同步调用发送和接收完成通信,具体流程如下:
s011:与指定设备的通道协议建立连接;
s012:调用sender接口,发送指令消息;
s013:同步调用receiver接口,接收数据;
s014:解析接收到的数据。
进一步地,所述数据接收服务命令模型通过同步调用发送和监听完成通信,具体流程如下:
s011:与指定设备的通道协议建立连接;
s012:调用sender接口,发送指令消息;
s013:同步调用listen,进行轮询监听数据返回,直至被调用停止监听;其中,对于基于tcp的监听,则先监听链接,再基于链接来监听数据;对于基于udp的监听,则直接监听指定ip和端口上的数据;
s014:解析接收到的数据。
本发明的有益效果为:本发明统一定义设备接口、通道接口和协议接口,当导入不同通信协议的不同设备时,只需根据既定的统一通信接口来实现新增的通信协议,上层业务逻辑代码不会受到任何影响,这使得软件代码维护和功能新增变得极为方便,最终使得产品软件质量有了保障。
附图说明
附图1为本发明一种支持多种通信协议的可扩展通信框架的示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面结合附图对本发明的具体实施方式做进一步的详细说明。
如附图1所示,本发明提供的一种支持多种通信协议的可扩展通信框架,用于连接软件平台和设备,包括统一定义的通信接口和统一定义的通信模型,其中,通信接口包括设备接口、通道接口和协议接口,通信模型在通信时调用设备接口、通道接口和协议接口。
本发明的核心之处在于统一定义通信接口,其中通信接口具体包括设备接口、通道接口和协议接口;通过定义标准的通信接口,对不同设备和协议进行封装,解决的问题是不同设备的通信协议各有不同,各个通信协议(包括tcp/udp/gpib/com等)的各种语言(c/c++/c#/java等)的实现上存在接口定义不一致,这不利于产品软件开发的标准化控制。
当设备通过通信框架与软件平台连接时,设备类统一继承自设备接口,即附图1中icommunicationdevice接口,设备的通信通道类统一继承自通道接口,即附图1中icommunicatingchannel接口,一个设备可以包含多个通道,设备类通过调用connect接口来创建一个可通信的通道。
具体地,设备接口,即icommunicationdevice接口,定义设备具有的属性和行为。属性包括id、name、通信模式(tcp/udp/gpib/com等)、通信状态(interrupt、error、communicating)、类型(虚拟设备、物理设备)、设备规格信息(厂家、型号、条码等);行为包括connect、send、recive和excute(send+receive)。
通道接口,即icommunicatingchannel接口,定义通信通道的属性和行为。属性包括通道名称、通信模式(tcp/udp/gpib/com等)、通信目标(如ip:port)、发送缓冲区大小、接收缓冲区大小、槽位、组别(用于对不同通道类别的分组)和所属设备;行为包括setoption、connect。
协议接口,包括ichannelsender接口,用于实现数据的发送;isendagreement接口,用于定义数据发送时的规约,比如发送数据的指令(command)、发送数据的分块机制、发送超时机制;ichannelreceiver接口,用于实现数据的接收;ireceiveagreement接口,用于定义数据接收时的规约,主要是对数据进行解析。
当软件平台连接设备时,在设备接口中新建类,且类继承自设备接口;在通道接口中新建通道协议,且通道协议继承自通道接口;在协议接口中新建子协议接口,且子协议接口继承自协议接口,其中,当软件平台连接设备时,在协议接口中新建sender接口(继承自ichannelsender接口),sendagreement接口(继承自isendagreement接口),receiver接口(继承自ichannelreceiver接口)和receiveagreement接口(继承自ireceiveagreement接口);软件平台和设备之间通过通信模型进行通信,且在通信过程中调用类、通道协议和子协议接口。
本发明的核心之处还在于统一定义通信模型,区分routine和service两种类型,前者设计适用于一次性事务的通讯需求,其关键是强调发送和接收的同步;后者设计适用于服务的通讯需求,其关键是强调发送和接收的异步,通信模型是基于通信接口之上,根据实际的业务需求来继承自的通信方案,即把以下两个command类作为基类继承自,那么用户的子类中就无须关心数据的发送和接收流程。本发明中通信模型包括数据下发事务命令模型distributeroutinecommand和数据接收服务命令模型acceptservicecommand。
数据下发事务命令模型distributeroutinecommand通过同步调用发送和接收完成通信,具体流程如下:
s011:与指定设备的通道协议建立连接;
s012:调用sender接口,发送指令消息;
s013:同步调用receiver接口,接收数据;
s014:解析接收到的数据。
数据接收服务命令模型acceptservicecommand通过同步调用发送和监听完成通信,具体流程如下:
s011:与指定设备的通道协议建立连接;
s012:调用sender接口,发送指令消息;
s013:同步调用listen,进行轮询监听数据返回,直至被调用停止监听;其中,对于基于tcp(transmissioncontrolprotocol,传输控制协议)的监听,则先监听链接,再基于链接来监听数据;对于基于udp(userdatagramprotocol,用户数据报协议)的监听,则直接监听指定ip和端口上的数据;其中,listen为service(acceptservicecommand)接口。
s014:解析接收到的数据。
统一定义通信模型,产品软件的业务需求围绕着以上方案中的2种通信模型展开,虽然通信指令、通信数据会改变,但是通信层的处理逻辑都是其中的一种模型,这使得上层业务逻辑功能开发时无需关心通信层的处理逻辑,使得代码层次清晰,在提高了开发效率的同时,同样使得产品软件指令有了保障。
本发明提供的一种支持多种通信协议的可扩展通信框架进行设备通信的方法,,包括如下步骤:
s01:当引入一类新的通信设备时,在设备接口中新建类(比如devicea),类继承自设备接口;设备通过类连接软件平台;实现icommunicationdevice接口,实现connect接口,因为不同设备的连接方式和过程是不同的;
s02:创建用于和该设备通信的通道协议(比如channela),在通道接口中新建通道协议,通道协议继承自通道接口;实现connect,因为不同协议的连接方式和过程是不同的;
s03:在协议接口中新建子协议接口,子协议接口继承自协议接口,设备通过子协议接口与软件平台实现进行数据发送和接收;
具体地,创建sender接口和sendagreement接口,分别继承自ichannelsender接口和isendagreement接口;创建receiver接口和receiveagreement接口,分别继承自ichannelreceiver接口和ireceiveagreement接口。
s04:设备和软件平台采用通信模型进行通信,且在通信过程中,调用类、通道协议和子协议接口。
本发明中通信模型包括数据下发事务命令模型distributeroutinecommand和数据接收服务命令模型acceptservicecommand。
数据下发事务命令模型distributeroutinecommand通过同步调用发送和接收完成通信,具体流程如下:
s011:与指定设备的通道协议建立连接;
s012:调用该设备对应的sender接口,发送指令消息;
s013:同步调用该设备对应的receiver接口,接收数据;
s014:解析接收到的数据。
数据接收服务命令模型acceptservicecommand通过同步调用发送和监听完成通信,具体流程如下:
s011:与指定设备的通道协议建立连接;
s012:调用该设备对应的sender接口,发送指令消息;
s013:同步调用该设备对应的listen,进行轮询监听数据返回,直至被调用停止监听;其中,对于基于tcp的监听,则先监听链接,再基于链接来监听数据;对于基于udp的监听,则直接监听指定ip和端口上的数据;
s014:解析接收到的数据。
统一定义通信模型,产品软件的业务需求围绕着以上方案中的2种通信模型展开,虽然通信指令、通信数据会改变,但是通信层的处理逻辑都是其中的一种模型,这使得上层业务逻辑功能开发时无需关心通信层的处理逻辑,使得代码层次清晰,在提高了开发效率的同时,同样使得产品软件指令有了保障。
以上所述仅为本发明的优选实施例,所述实施例并非用于限制本发明的专利保护范围,因此凡是运用本发明的说明书及附图内容所作的等同结构变化,同理均应包含在本发明所附权利要求的保护范围内。