CN112486504A - 交互方法、上位机和计算机可读存储介质 - Google Patents

Abstract

本发明实施例涉及通信技术领域，公开了一种交互方法、上位机和计算机可读存储介质。本发明中，上述交互方法包括：向下位机发送指令，并接收所述下位机对所述指令的响应信息；根据所述响应信息，获取所述下位机的类型；根据所述下位机的类型，确定与所述下位机的类型对应的功能插件；配置与所述下位机的类型对应的功能插件，并根据配置的所述功能插件与所述下位机进行交互，使得可以降低上位机软件各功能模块的耦合度，方便了对上位机软件的功能进行维护和扩展。

Description

交互方法、上位机和计算机可读存储介质

技术领域

本发明实施例涉及通信技术领域，特别涉及一种交互方法、上位机和计算机可读存储介质。

背景技术

上位机软件通常是指运行在上位机中，用于用户控制、数据处理以及数据显示等的软件。用户使用上位机软件发出的命令通过RS2232串口协议或TCP/IP网络协议等通讯协议传输给下位机，下位机再根据该命令解释成相应的时序信号直接控制对应的设备；下位机读取设备状态数据(一般为模拟量)，转化为数字信号反馈给上位机。最后，上位机再将数字信号进行处理并采用不同的形式展示给用户。比如，上位机要通过下位机去采集温度，上位机可以发送命令给下位机，下位机根据该命令直接控制对应的温度传感器去采集温度。

然而，发明人发现相关技术中至少存在如下问题：随着技术的进步与业务需求的增加，上位机软件必定会承担越来越多的功能，然而传统上位机软件在实现过程中，各功能模块之间高度依赖，耦合性高，很难对上位机的功能进行维护和扩展。

发明内容

本发明实施方式的目的在于提供一种交互方法、上位机和计算机可读存储介质，使得可以降低上位机软件各功能模块的耦合度，方便了对上位机软件的功能进行维护和扩展。

为解决上述技术问题，本发明的实施方式提供了一种交互方法，包括以下步骤：向下位机发送指令，并接收所述下位机对所述指令的响应信息；根据所述响应信息，获取所述下位机的类型；根据所述下位机的类型，确定与所述下位机的类型对应的功能插件；配置与所述下位机的类型对应的功能插件，并根据配置的所述功能插件与所述下位机进行交互。

本发明的实施方式还提供了一种上位机，包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述的交互方法。

本发明的实施方式还提供了一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时实现上述的交互方法。

本申请发明人发现，传统上位机中运行的上位机软件在实现过程中，上位机软件在启动之前就人为预先设置好与对应的下位机进行交互所需要的功能模块。上位机软件启动后预先设置的各功能模块在上位机软件运行过程中不能修改，如果需要更新、增加或删除某个功能模块，则要终止运行上位机软件后才能更新、增加或删除，其他功能模则块也要终止工作，这导致各功能模块之间高度依赖，耦合性高，很难对上位机软件的功能进行维护和扩展。本发明实施方式相对于现有技术而言，采用插件式开发机制，先向下位机发送指令，并接收下位机对指令的响应信息；根据响应信息，获取下位机的类型；根据下位机的类型，确定与下位机的类型对应的功能插件，确定的功能插件即为上位机与该类型的下位机进行交互时所需的功能插件。然后配置与下位机的类型对应的功能插件，并根据配置的功能插件与下位机进行交互。即上位机可以自动配置所需的功能插件，而无需通过人为预先设置的功能模块，就能实现上位机与下位机之间的交互。而且，由于实现不同功能的功能插件之间通常互相独立，互不依赖，因此更新、增加或删除某个功能插件均无需在终止上位机软件运行后再更新、增加或删除，不会影响其他功能插件的正常运行，降低了上位机软件界面各功能模块之间的耦合度，方便了对上位机软件的维护和扩展。

另外，配置与所述下位机的类型对应的功能插件，包括：根据所述下位机的类型，获取与所述下位机的类型对应的功能插件的配置信息；根据所述配置信息安装所述功能插件，并启动安装的所述功能插件。本发明实施方式提供了一种配置与下位机的类型对应的功能插件的实现方式，便于实现对功能插件的配置。

另外，所述功能插件的类型包括：通讯插件和显控插件；其中，所述通讯插件用于从所述下位机获取数据，并将获取的数据发送至所述显控插件；所述显控插件用于显示从所述下位机获取的所述数据并控制所述下位机。通过上位机中的通讯插件和显控插件有利于实现上位机与下位机之间进行交互所需要的显控功能和通讯功能。

另外，在所述确定与所述下位机的类型对应的功能插件之后，还包括：若确定的所述功能插件的数量为多个，且检测到不同的所述功能插件之间需要通信，则根据预设的插件框架中存储的所述不同的功能插件之间的通信协议进行通信。由于，现有技术中上位机中的各功能模块之间要进行通信需了解对方是如何实现的，然后配置双方的通信协议，实现过程比较复杂。本发明实施方式中，由于插件框架中预置有不同功能插件之间的通讯协议，因此功能插件之间在进行通信时无需了解对方是如何实现的，实现过程更加简单。

另外，所述显控插件的数量为多个，不同的显控插件具有不同的显控功能，各所述显控插件之间通过标识不同的主题进行消息交换，相互独立没有依赖，耦合度低，各显控插件之间的通信简单清晰。

另外，所述通讯插件与各所述显控插件之间通过标识同一主题进行消息交换；其中，所述同一主题与各所述显控插件之间进行消息交换所标识的主题均不相同，使得所有显控插件都能接收到通讯插件的消息，与通讯插件进行消息交换。

另外，在所述根据配置的所述功能插件与所述下位机进行交互之后，还包括：若检测到与所述上位机交互的下位机的类型变更，则根据变更后的下位机的类型，确定与所述变更后的下位机的类型对应的变更功能插件；配置所述变更功能插件，并根据配置的所述变更功能插件与类型变更后的下位机进行交互。也就是说，当上位机要和其他类型的下位机交互时，不需要重新编译上位机软件，只需根据需要配置变更功能插件，就可以利用变更功能插件实现上位机与新的类型的下位机进行交互，更加简单方便。

另外，在所述确定与所述变更后的下位机的类型对应的变更功能插件之后，还包括：确定所述变更功能插件与变更前的下位机的类型对应的功能插件中是否存在相同的功能插件；若确定存在所述相同的功能插件，则所述配置所述变更功能插件，具体为：配置所述变更功能插件中除去所述相同的功能插件之外的功能插件。也就是说，当下位机的类型变更时，若存在上述相同的功能插件，则变更类型后的下位机与上位机交互时可以复用上述相同的功能插件，无需在下位机的类型变更时再次配置上述相同的功能插件。

另外，若检测到与所述上位机交互的下位机的类型变更，则还包括：卸载变更前的下位机的类型对应的功能插件。可以理解的是，下位机的类型变更后，变更类型前的下位机对应的功能插件可能不再需要，这些不需要的功能插件可在不关闭上位机软件的情况下，实现功能插件的动态卸载，有利于节省人力成本和时间成本。

附图说明

一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定，附图中具有相同参考数字标号的元件表示为类似的元件，除非有特别申明，附图中的图不构成比例限制。

图1是根据本发明第一实施方式中的交互方法的流程图；

图2是根据本发明第一实施方式中的上位机中运行的上位机软件程序的模块图；

图3是根据本发明第二实施方式中的交互方法的流程图；

图4是根据本发明第二实施方式中的功能插件之间通信的示意图；

图5(a)是根据本发明第二实施方式中的上位机与类型变更前的下位机进行交互的示意图；

图5(b)是根据本发明第二实施方式中的上位机与类型变更后的下位机进行交互的示意图；

图6是根据本发明第二实施方式中的功能插件的生命周期状态转换图；

图7是根据本发明第三实施方式中的上位机的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的各实施方式进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明各实施方式中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本申请所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本发明的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。

本发明的第一实施方式涉及一种交互方法，应用于上位机，本实施方式中的交互方法主要指的是上位机与下位机的交互方法。下面对本实施方式的交互方法的实现细节进行具体的说明，以下内容仅为方便理解提供的实现细节，并非实施本方案的必须。

本实施方式中的交互方法的流程图可以如图1所示，具体包括：

步骤101：向下位机发送指令，并接收下位机对指令的响应信息。

具体的说，上位机与下位机之间可以预先配置消息协议，配置该消息协议后，下位机收到上位机发送的该消息协议指示的指令后，需要向上位机返回自身的类型。即上位机可以向下位机下发指令，下位机接收到该指令后响应该指令，向上位发送响应信息。下位机发送响应信息时可以携带自身的类型，上位机则可以接收到下位机发送的携带自身的类型的响应信息。其中，上位机发送的指令可以根据实际需要进行设置，本实施方式对此不做具体限定。

步骤102：根据响应信息，获取下位机的类型。

其中，上位机可以根据响应信息，获取响应信息中携带的下位机的类型。

在一个例子中，下位机的类型可以为指纹识别类型的指纹芯片、蓝牙传输类型的蓝牙芯片等，上位机可以为电脑。电脑可以向指纹芯片、蓝牙芯片均发送预设的指令，指纹芯片和蓝牙芯片均会响应该指令，返回携带各自的类型的响应信息，使得电脑可以根据接收的响应信息得到下位机的类型。

步骤103：根据下位机的类型，确定与下位机的类型对应的功能插件。

其中，功能插件可以实现上位机所需要的相关功能，功能插件可以是是基于C++/Qt的一个共享库，包含了资源文件和元数据，具体表现为一个动态链接库文件，对外提供统一的服务接口，在Windows平台下表现为.dll文件，在Linux平台下表现为.so文件。动态链接库文件不会被包含在最终的可执行文件中，只有在程序运行时才会被加载，其中，最终的可执行文件可以理解为.exe文件。由于，功能插件的修改或者更新属于相对独立的操作，并不会影响.exe文件，因此，对某个功能插件的修改或者更新都不会影响到其他的功能插件，也无需重新编译上位机中运行的上位机软件，大大提高了上位机软件功能的可维护性与可扩展性。每个功能插件都包含了自己的资源文件和元数据，其中，资源文件是一些可扩展标记语言XML(Extensible Markup Language，简称XML)、图像文件存储PNG(PortableNetwork Graphic，简称PNG)等文件。元数据用于准确描述功能插件的特征，由功能插件的唯一标识符和可读信息组成，可读信息如：插件的名称、插件的版本、插件的描述等，可读信息能帮助更好的理解和使用插件。

在一个例子中，功能插件的类型可以包括：显控插件和通讯插件，通讯插件用于从下位机获取数据，并将获取的数据发送至显控插件。显控插件用于显示从下位机获取的数据并控制下位机。需要说明的是，本实施方式中功能插件的类型只是以显控插件和通讯插件为例，但在具体实现中并不以此为限，本领域技术人员可以根据实际需要的功能开发实现相应功能的功能插件。

具体的说，上位机中可以预先存储不同的下位机类型与功能插件的对应关系，其中，一种下位机类型可以对应多个用于实现不同功能的功能插件，比如，一种类型的下位机可以对应有该类型的下位机为了与上位机实现交互所需要的显控插件和通讯插件。上位机可以根据预存的对应关系确定与上位机交互的下位机的类型对应的功能插件。在一个例子中，上位机可以为电脑，下位机可以为不同类型的芯片，但在具体实现中并不以此为限。

步骤104：配置与下位机的类型对应的功能插件，并根据配置的功能插件与下位机进行交互。

具体的说，上位机运行的上位机软件程序中可以存储有针对不同类型的下位机的配置文件，该配置文件中包括该类型的下位机与上位机进行交互时所需的功能插件的配置信息。上位机根据运行的上位机软件程序中针对不同类型的下位机存储的配置文件获取与该下位机类型对应的功能插件的配置信息。配置信息可以包括插件的名字、插件的数量、插件的路径等。在获取到与下位机类型对应的功能插件的配置信息后，可以根据功能插件的配置信息安装功能插件，并启动安装的功能插件。

在一个例子中，配置功能插件的方式可以为：在获取功能插件的配置信息后，可以先启动预设的插件框架，然后，根据获取的配置信息在上述的插件框架中安装并启动功能插件。其中，插件框架可以是一个可复用的设计构件，它规定了功能插件的体系结构，表现为一组抽象类以及其插件实例之间协作的方法，它为构件复用提供了上下文关系，插件框架要解决的主要问题就是插件的动态加载能力，这里可以使用共享库的动态加载技术，从而为插件提供所需服务。

进一步的，配置好功能插件后，上位机可以根据配置的功能插件与下位机进行交互。具体的，上位机可以根据功能插件的不同类型，调用功能插件的接口函数，通过接口函数来获取功能插件实例。其中，同种类型的功能插件可以继承自同一接口函数，在一个例子中，显控插件可以调用用于实现窗口的显示、关闭等功能的接口函数，从而可以将显控插件以标签页的形式显示在上位机软件窗口的指定位置，或关闭显示在上位机软件窗口的指定位置处的功能插件。通讯插件可以调用用于实现与下位机连接、断开等功能的接口函数，从而与下位机建立通信连接或断开通信连接。在具体实现中，不同类型的下位机可以对应有相应的通讯协议，通讯插件可以根据上位机与下位机之间适用的通讯协议进行数据交互。

为方便对本实施方式的理解，下面以图2中的框图为例进行举例说明，图2可以理解为上位机中运行的上位机软件程序的模块图，包括：主框架模块201、插件管理模块202和功能插件模块203，功能插件模块203可以具体分为显控插件2031和通讯插件2032。其中，主框架模块201主要用于根据与上位机进行交互的下位机的类型，获取对应的功能插件的配置信息，并启动插件框架。插件管理模块202主要用于根据配置信息在插件框架中安装并启动功能插件。功能插件模块203主要用于根据功能插件的不同类型，调用对应的接口函数，以实现功能插件对应的功能。显控插件2031主要用于控制下位机并从下位机获取数据；通讯插件2032主要用于连接下位机，利用上位机与下位机之间合适的通讯协议与下位机进行数据交互。

在一个例子中，下位机为蓝牙传输类型的蓝牙芯片，上位机为电脑。蓝牙芯片对应的功能插件可以包括显控插件和通讯插件。比如，电脑要通过蓝牙芯片去获取室内温度，那么，首先电脑可以利用显控插件，向蓝牙芯片发送控制命令；蓝牙芯片再根据此命令解释成相应时序信号，从而控制温度传感器去采集室内温度；蓝牙芯片可以读取温度传感器采集的温度(一般为模拟量)，转换成数字信号后，通过通讯插件将采集的室内温度传输给电脑；电脑再利用显控插件将接收到的温度显示在显示屏上。

需要说明的是，本实施方式中的上述各示例均为为方便理解进行的举例说明，并不对本发明的技术方案构成限定。

可以理解的是，传统上位机软件是在人为编写软件的时候，就确定了有哪些功能模块，将这些功能模块的代码整体写在上位机软件中，即各功能模块是人为设置所形成的一个整体。发布上位机软件时这些功能模块就已经预先设置好了，启动上位机软件的时候，功能模块对应的页面就直接显示出来了。比如，在具体实现中，上位机软件可以有几个页面，每个页面相当于一个功能模块，根据当前时刻需要实现的功能，上位机的显示界面可以显示对应的页面。传统上位机软件在发布的时候，这些页面是一个整体，都是固定的，如果要修改某个页面，或者增加页面，就需要重新发布整个上位机软件。也就是说，由于各功能模块作为一个整体存在，所以在上位机软件运行的过程中，无法对其中一个进行修改或是增加新的功能模块。

而相对于传统上位机软件，本实施方式可以理解为，上位机自动确定与之进行交互的下位机的类型，并配置与该类型对应的功能插件，上位机可以自动完成配置功能插件的过程，无需人为介入。上位机软件启动时需要哪一个功能插件工作，就去加载该功能插件。比如，如果需要显控功能，则加载显控插件，那么上位机的显示界面会显示该显控插件对应的页面，如果需要通讯功能，则加载通讯插件，就可以利用该通讯插件去实现上位机与下位机之间的数据传输。其中，每个页面可以对应一个单独的显控插件，各显控插件之间相互独立，使得各个页面之间也相互独立。另外，由于功能插件对外提供服务接口，可以被随时删除，插入和修改，所以结构很灵活，容易修改，方便软件的升级和维护。也就是说，各显控插件对应的页面并不是固定的，如果需要修改或者增加某个页面，只需要利用显控插件对外提供的服务接口重新发布该页面对应的显控插件，而不需要像传统上位机软件那样，在需要修改或者增加某个页面时重新发布整个上位机软件。

与现有技术相比，本实施方式采用插件式开发机制，由于实现不同功能的功能插件之间通常互相独立，互不依赖，因此更新、增加或删除某个功能插件均无需在终止上位机软件运行后再更新、增加或删除，不会影响其他功能插件的正常运行，降低了上位机软件界面各功能模块之间的耦合度，方便了对上位机软件的维护和扩展。

本发明的第二实施方式涉及一种交互方法，本实施方式中重点介绍不同功能插件之间如何实现通信。下面对本实施方式的交互方法的实现细节进行具体的说明，以下内容仅为方便理解提供的实现细节，并非实施本方案的必须。

本实施方式中的交互方法的流程图可以如图3所示，具体包括：

步骤301：向下位机发送指令，并接收下位机对指令的响应信息。

步骤302：根据响应信息，获取下位机的类型。

步骤303：根据下位机的类型，确定与下位机的类型对应的功能插件。

步骤304：配置与下位机的类型对应的功能插件，并根据配置的功能插件与下位机进行交互。

需要说明的是，步骤301至步骤304与第一实施方式中步骤101至步骤104大致相同，为避免重复，在此不再赘述。

步骤305：若确定的功能插件的数量为多个，且检测到不同的功能插件之间需要通信，则根据预设的插件框架中存储的不同的功能插件之间的通信协议进行通信。

需要说明的是，本实施方式中只是以先执行步骤304再执行步骤305为例，在具体实现中还可以先执行步骤305再执行步骤304，然而本实施方式对此不做限定。

具体的说，1个功能插件可以注册1个或者多个服务到插件框架中，注册时可以指定一个主题(topic)和可选的属性信息。主题用于定义事件的性质，主题名通常放在一个层次化的命名空间中(如：org/goodix/plugins/event，其中斜杠用于分割级别)。属性信息用于描述事件的一组信息，数据结构为字典(Map)类型，本实施例中的属性信息可以用于表示注册服务的功能插件的信息。如果多个功能插件在同一个主题下注册服务，则可以通过其属性信息进行区分。如果一个功能插件在插件框架中注册了一个服务，那么其他功能插件就可以绑定该服务，绑定服务时也可以指定一个主题，同时绑定该服务的功能插件也可以监听该服务，在该服务出现或者消失以后通知绑定该服务的功能插件，使得绑定该服务的功能插件能够监听得到注册该服务的功能插件的信息，实现两个功能插件之间的通信。通过上述描述可以得知，若检测到不同的功能插件中的一个功能插件绑定了其他功能插件在插件框架中注册的服务，并监听绑定的服务，则可以判定不同的功能插件之间需要通信。

进一步的，插件框架中可以预存不同的功能插件之间进行通信所适用的通信协议，当检测到两个功能插件之间需要通信时，可以通过查询预存的不同的功能插件之间进行通信所适用的通信协议得到这两个功能插件之间适用的通信协议，根据查询到的通讯协议实现这两个功能插件之间的通信。

在一个例子中，可以参考图4，图4示出了两个不同的功能插件之间通信的动态服务模型。其中，功能插件A在插件框架中注册了服务，功能插件B绑定了功能插件A在插件框架中注册的服务，并对绑定的该服务进行了监听，当检测到该服务出现或是消失后可以向功能插件B发送通知信息。

另外，在根据配置的功能插件与下位机进行交互之后，还可以包括：若检测到与上位机交互的下位机的类型变更，则根据变更后的下位机的类型，确定与变更后的下位机的类型对应的变更功能插件。配置变更功能插件，并根据配置的变更功能插件与类型变更后的下位机进行交互。

为方便理解，可以参考图5(a)和5(b)，5(a)和5(b)为一个例子中，上位机与类型变更后的下位机进行交互的示意图。其中，下位机1为类型变更前的下位机，下位机2为类型变更后的下位机。功能插件501为下位机1对应的功能插件，功能插件501中包括显控插件502和通讯插件503。显控插件502可以包括插件1、插件2、插件3，其中，插件1、插件2、插件3可以分别实现不同的显控功能。功能插件504为下位机2对应的功能插件，功能插件504中包括显控插件505和通讯插件506。显控插件505可以包括插件1、插件4、插件5，其中，插件1、插件4、插件5可以分别实现不同的显控功能。插件1可以为通用的显控插件，可以理解为上位机与下位机1或下位机2进行交互时均需要的显控插件。若与上位机进行交互的下位机的类型从下位机1的变更为下位机2的类型，则可以根据下位机2的类型确定对应的变更功能插件，图5(b)中的功能插件504即为变更功能插件。接着，可以获取变更功能插件的配置信息，即获取显控插件505和通讯插件506的配置信息，然后显控插件505和通讯插件506的配置信息，配置显控插件505和通讯插件506。最后，根据显控插件505和通讯插件506与下位机2进行交互。可以看出，当需要上位机适用于下位机2时，不需要重新编译上位机软件，只需要在上位机软件程序运行之前加载下位机2的通讯插件2和相关的插件4、插件5，通用的插件1可以继续使用。

值得一提的是，在确定与变更后的下位机的类型对应的变更功能插件之后，还可以包括：确定变更功能插件与变更前的下位机的类型对应的功能插件中是否存在相同的功能插件；若确定存在相同的功能插件，则配置所述变更功能插件，具体为：配置变更功能插件中除去相同的功能插件之外的功能插件。参考图5(a)和5(b)，变更功能插件即为下位机2对应的功能插件504，变更前的下位机的类型对应的功能插件即为下位机1对应的功能插件501。可以看出，功能插件501和功能插件504中相同的功能插件为插件1，则在配置功能插件504时可以配置除去插件1之外的功能插件，即只需配置通讯插件2、插件4和插件5，插件1可以继续使用下位机1对应的插件1。本实施方式中，当与上位机交互的下位机类型变更时，若变更功能插件与变更前的下位机的类型对应的功能插件中存在相同的功能插件，则可以复用该相同的功能插件。

在具体实现中，显控插件的数量通常为多个，各显控插件之间通过标识不同的主题进行消息交换，通讯插件与各显控插件之间可以通过标识同一主题进行消息交换；其中，同一主题与各显控插件之间进行消息交换所标识的主题均不相同。如图5(a)和5(b)中，显控插件502可以包括插件1、插件2、插件3，显控插件505可以包括插件1、插件4、插件5。显控插件之间通过标识不同的主题类别，进行消息交换。如插件1与插件2之间通过主题A(topicA)进行消息交换，插件2和插件3之间通过主题B(topicB)进行消息交换，插件1和插件4之间通过主题A(topicA)进行消息交换，插件4和插件5之间通过主题B(topicB)进行消息交换。为了使所有显控插件都能接收到通讯插件的消息，通讯插件与各显控插件之间可以通过同一主题类别C(topicC)进行消息交换。可以看到，各功能插件间没有相互依赖，耦合度低，通信简单清晰。在使用过程中，用户还可以根据实际需要加载或者卸载显控插件，从而能够动态定制功能插件实现所需的功能。

在一个例子中，若检测到与上位机交互的下位机的类型变更，则还可以包括：卸载变更前的下位机的类型对应的功能插件。功能插件可以在不关闭上位机软件程序的情况下卸载，即可以实现动态卸载不需要的功能插件，有利于节省人力成本和时间成本。

在一个例子中，还可以根据实际所需实现功能插件的更新，比如若检测到有功能插件需要更新，可以获取更新的功能插件的配置信息，根据更新的所述配置信息对功能插件进行更新。

为方便理解，下面介绍本实施方式中的功能插件的生命周期，生命周期主要用于管理插件的安装、启动、停止、更新和卸载。可以参考图6中的生命周期状态转换图，插件有以下几种状态：卸载UNINSTALLED、安装INSTALLED、就绪RESOLVED、启动STARTING、停止STOPPING、激活ACTIVE，插件只能在状态为STARTING、STOPPING、ACTIVE时才能执行代码。其中，INSTALLED表示插件已经安装；RESOLVED表示插件依赖的程序集或者依赖的插件已经满足，这个插件可以被正常启动；ACTIVE则表示插件已经被成功激活，可以执行代码；UNINSTALLED表示插件已经被卸载。插件的各个状态是可以相互转化的，比如插件在执行安装install操作后会进入INSTALLED状态，install成功随后进入RESOLVED状态；再执行start操作并成功后，插件进入ACTIVE状态；在ACTIVE状态下执行停止stop操作后，插件又回到RESOLVED状态；最后执行卸载uninstall操作，此时插件就进入UNINSTALLED状态。通过以上生命周期状态的转换，就可以实现在上位机软件运行过程中动态增加或删除功能插件，从而增加或删除相应的功能。

现有技术中，上位机软件发布后，其界面和功能已经定型，用户在使用中不能对界面和功能的组合进行定制，也不能进行功能扩展，因此开发出的上位机系统难以应付频繁变更的业务需求，不能胜任多样化的任务。与现有技术相比，本实施方式中，，可以在不关闭上位机软件的情况下安装、更新和卸载功能插件，动态定制上位机软件的功能插件，实现上位机所需的相关功能，方便了对上位机软件的功能进行维护和扩展。而且，现有技术中一款上位机软件通常只能适用于特定的下位机，若想要控制不同的下位机，则需要重新开发对应的上位机软件，开发成本高，本实施方式中，当上位机要和其他类型的下位机交互时，不需要重新开发上位机软件，只需根据需要配置变更功能插件，就可以利用变更功能插件实现上位机与新的类型的下位机进行交互，更加简单方便，解决了传统上位机软件与下位机关联性强，功能模块耦合性高，无法实现复用等技术问题。

上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。

本发明第三实施方式涉及一种上位机，如图7所示，包括至少一个处理器701；以及，与至少一个处理器701通信连接的存储器702；其中，存储器702存储有可被至少一个处理器701执行的指令，指令被至少一个处理器701执行，以使至少一个处理器701能够执行第一、或第二实施方式中的交互方法。

其中，存储器702和处理器701采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器701和存储器702的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器701处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器701。

处理器701负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器702可以被用于存储处理器701在执行操作时所使用的数据。

本发明第四实施方式涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例。

即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施方式是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。

Claims (12)

1.一种交互方法，其特征在于，应用于上位机，包括：

向下位机发送指令，并接收所述下位机对所述指令的响应信息；

根据所述响应信息，获取所述下位机的类型；

根据所述下位机的类型，确定与所述下位机的类型对应的功能插件；

配置与所述下位机的类型对应的功能插件，并根据配置的所述功能插件与所述下位机进行交互。

2.如权利要求1所述的交互方法，其特征在于，所述配置与所述下位机的类型对应的功能插件，包括：

根据所述下位机的类型，获取与所述下位机的类型对应的功能插件的配置信息；

根据所述配置信息安装所述功能插件，并启动安装的所述功能插件。

3.如权利要求1所述的交互方法，其特征在于，所述功能插件的类型包括：通讯插件和显控插件；

其中，所述通讯插件用于从所述下位机获取数据，并将获取的数据发送至所述显控插件；所述显控插件用于显示从所述下位机获取的所述数据并控制所述下位机。

4.如权利要求1所述的交互方法，其特征在于，在所述确定与所述下位机的类型对应的功能插件之后，还包括：

若确定的所述功能插件的数量为多个，且检测到不同的所述功能插件之间需要通信，则根据预设的插件框架中存储的不同的所述功能插件之间的通信协议进行通信。

5.如权利要求4所述的交互方法，其特征在于，所述检测到不同的所述功能插件之间需要通信，具体为：

若检测到不同的所述功能插件中的一个功能插件绑定了其他功能插件在所述插件框架中注册的服务，并监听绑定的所述服务，则判定不同的所述功能插件之间需要通信。

6.如权利要求3所述的交互方法，其特征在于，所述显控插件的数量为多个，各所述显控插件之间通过标识不同的主题进行消息交换。

7.如权利要求6所述的交互方法，其特征在于，所述通讯插件与各所述显控插件之间通过标识同一主题进行消息交换；其中，所述同一主题与各所述显控插件之间进行消息交换所标识的主题均不相同。

8.如权利要求1所述的交互方法，其特征在于，在所述根据配置的所述功能插件与所述下位机进行交互之后，还包括：

若检测到与所述上位机交互的下位机的类型变更，则根据变更后的下位机的类型，确定与所述变更后的下位机的类型对应的变更功能插件；

配置所述变更功能插件，并根据配置的所述变更功能插件与类型变更后的下位机进行交互。

9.如权利要求8所述的交互方法，其特征在于，在所述确定与所述变更后的下位机的类型对应的变更功能插件之后，还包括：

确定所述变更功能插件与变更前的下位机的类型对应的功能插件中是否存在相同的功能插件；

若确定存在所述相同的功能插件，则所述配置所述变更功能插件，具体为：

配置所述变更功能插件中除去所述相同的功能插件之外的功能插件。

10.如权利要求8所述的交互方法，其特征在于，若检测到与所述上位机交互的下位机的类型变更，则还包括：

卸载变更前的下位机的类型对应的功能插件。

11.一种上位机，其特征在于，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至10中任一所述的交互方法。

12.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至10中任一项所述的交互方法。

Images