一种配置管理方法、配置管理系统及具有存储功能的装置与流程

本申请涉及计算机技术领域，特别是涉及一种配置管理方法、配置管理系统及具有存储功能的装置。

背景技术：

当前通信设备被广泛应用于各种环境中，面临着越来越复杂的工序，用户对产品的质量、效率要求也越来越高。随着行业发展和细化，现有技术通常采用多种类型的设备协同操作。现有技术中通常使用配置(编程)软件对设备进行参数配置。

本申请的发明人在长期的研发过程中，发现现有的配置(编程)软件存在如下不足：

1)由于不同类型的设备有不同的特性(如dmr、tetra等)，而这些设备的配置(编程)软件采用不同语言开发(c++、c#等)，导致各个配置功能和操作存在差异；

2)在实际应用中，一种配置(编程)软件仅针对一种待配置设备操作，当用户需要对多种设备进行管理时，需要分别操作多个配置(编程)软件，极其不便，不能满足用户快速配置终端的需求。

技术实现要素：

本申请主要解决的技术问题是提供一种配置管理方法、配置管理系统及具有存储功能的装置，能够有效提高设备配置管理的效率，并提高了设备配置管理的灵活性和方便性。

为解决上述技术问题，本申请采用的一个技术方案是：提供一种配置管理方法，该方法包括：从待配置设备获取待配置设备的类型信息；查找与类型信息对应的插件的程序包；调用与类型信息对应的插件的程序包；显示与待配置设备对应的操作界面，接收在操作界面输入的配置参数；处理配置参数，将处理后的配置参数推送给待配置设备，以根据配置参数对待配置设备进行参数配置。

其中，查找与类型信息对应的插件的程序包，包括：以预设格式保存至少一个插件的程序包；根据类型信息，从已保存的插件的程序包中查找与类型信息对应的插件的程序包。

其中，在从待配置设备获取类型信息步骤之前，该方法还包括：设置宿主程序与插件进行交互的协议；建立宿主程序与插件之间的进程间通信通道。

其中，在调用与类型信息对应的插件的程序包步骤之前，方法还包括：验证与类型信息对应的插件的程序包是否为合法的插件的程序包。

其中，验证与类型信息对应的插件的程序包是否为合法的插件的程序包，包括：加载插件，以启动插件；通过进程间通信通道将一协议格式的验证消息发送给插件；若插件解析并回应验证消息，则与类型信息对应的插件的程序包为合法的插件的程序包；其中，协议格式为协议定义的消息格式。

其中，在显示与待配置设备对应的操作界面步骤之前，方法包括：通过进程间通信通道将操作消息包发送给插件；解析操作消息包，并识别操作类型；在插件识别出操作类型后，根据操作类型显示与待配置设备对应的操作界面。

其中，处理配置参数，包括：根据协议将配置参数封装成统一协议消息，并通过进程间通信通道将统一协议消息发送给宿主程序；解析统一协议消息以获取配置参数；宿主程序将配置参数封装成统一的设备配置数据；其中，设备配置数据至少包括配置参数和待配置设备的类型信息。

其中，将处理后的配置参数推送给待配置设备，包括：解析设备配置数据，以根据待配置设备的类型信息确定待配置设备；通过网络或远程服务器将配置参数推送给所确定的待配置设备，以根据配置参数对待配置设备进行参数配置。

为解决上述技术问题，本申请采用的另一个技术方案是：提供一种配置管理系统，该系统用于对待配置设备进行参数配置，该系统包括：处理器、收发器、存储器和显示器；处理器分别耦接收发器、存储器和显示器；收发器用于从待配置设备获取待配置设备的类型信息；处理器用于查找与类型信息对应的插件的程序包，并调用与类型信息对应的插件的程序包；显示器用于显示与待配置设备对应的操作界面，并接收在操作界面输入的配置参数；处理器还用于处理配置参数；收发器还用于将处理后的配置参数推送给待配置设备，以根据配置参数对待配置设备进行参数配置；存储器用于保存待配置设备的类型信息、插件的程序包、配置参数以及处理后的配置参数。

为解决上述技术问题，本申请采用的又一个技术方案是：提供一种具有存储功能的装置，该装置存储有程序数据，程序数据能够被执行以实现上述的配置管理方法。

本申请的有益效果是：区别于现有技术，本申请通过从待配置设备获取待配置设备的类型信息，并在多个插件的程序包中查找与该类型信息对应的插件的程序包，通过调用该对应的插件的程序包对待配置设备进行配置管理。本申请的配置管理方法能够对多种类型的待配置设备进行配置管理，不需要分别操作多个配置(编程)软件，能够有效提高设备配置管理的效率，并提高了设备配置管理的灵活性和方便性，降低人力成本。同时，本申请不需要开发全新的插件程序，能够降低开发成本。

附图说明

为了更清楚地说明本申请实施方式中的技术方案，下面将对实施方式描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。其中：

图1是本申请配置管理方法一实施方式的流程示意图；

图2是图1中步骤s12的流程示意图；

图3是本申请配置管理方法另一实施方式的流程示意图；

图4是本申请中宿主程序与插件一实施方式的结构示意图；

图5是本申请配置管理方法又一实施方式的流程示意图；

图6是图5中步骤s50的流程示意图；

图7是本申请配置管理方法再一实施方式的流程示意图；

图8是图1中步骤s15的流程示意图；

图9是图1中步骤s16的流程示意图；

图10是本申请配置管理系统一实施方式的结构示意图；

图11是本申请具有存储功能的装置一实施方式的结构示意图。

具体实施方式

下面将结合本申请实施方式中的附图，对本申请实施方式中的技术方案进行清楚、完整地描述，显然，所描述的实施方式仅仅是本申请一部分实施方式，而不是全部实施方式。基于本申请中的实施方式，本领域普通技术人员在没有做出创造性的劳动前提下所获得的所有其他实施方式，都属于本申请保护的范围。

参阅图1，图1是本申请配置管理方法一实施方式的流程示意图，该方法包括：

步骤s11：从待配置设备获取待配置设备的类型信息。

本实施方式的配置管理方法用于管理多台不同品牌、不同型号的待配置设备，其中，待配置设备可以为通信设备，例如多模终端、数字对讲机、手持对讲机、数字中转台。待配置设备的类型信息可以为待配置设备的品牌信息、型号信息、版本信息中的至少一种，在此不做限定。本实施方式中，配置管理系统可以通过扫描待配置设备的条形码或二维码获取待配置设备的型号信息；也可以根据用户输入的选择指令，从预设的设备型号库里获取待配置设备的型号信息。

步骤s12：查找与类型信息对应的插件的程序包。

具体地，插件是会随着宿主程序的启动而自动执行的程序。其中，插件的程序包可以为现有的配置(编程)软件(commonprogramingsoftware，cps)中的插件的程序包，也可以为用户重新开发的插件的程序包，在此不做限定。

各插件的程序包对应一台待配置设备，插件具有对待配置设备进行参数配置的功能，一个宿主程序能调用多个插件的程序包，宿主程序与各个插件分离，宿主程序和多个插件之间可以通过各自保存的对方接口实体完成交互操作。

本实施方式中，各插件根据用户需求进行配置，配置管理系统能随时添加或移除插件，同时插件列表也会随着各插件的变化而更新。配置管理系统可以根据待配置设备的类型信息，通过待配置设备的类型信息与插件的程序包的对应关系，获取与类型信息对应的插件的程序包。需要说明的是，类型信息与插件的程序包的对应关系需要提前预置。该对应关系可以预置在配置管理系统中，也可以预置在网络服务器中。由于目前待配置设备产品的更新换代非常频繁，需要不断更新该对应关系。

步骤s13：调用与类型信息对应的插件的程序包。

在宿主程序中，安装相关的插件后，宿主程序能够直接调用插件的程序包，通过直接调用与待配置设备的类型信息对应的插件的程序包，以使当前插件在宿主程序中实现与当前插件对应的功能，从而对该待配置设备进行参数配置。

步骤s14：显示与待配置设备对应的操作界面，接收在操作界面输入的配置参数。

具体地，配置管理系统可以以视窗化的操作界面形式进行呈现给用户，其中，操作界面可以具有点击、滑动、拖拽等功能，以使用户进行配置参数的输入。在调用与待配置设备的类型信息对应的插件的程序包之后，配置管理系统向用户显示与待配置设备对应的操作界面，配置管理系统通过该操作界面接收用户输入的配置参数。

步骤s15：处理配置参数。

具体地，配置管理系统可以将配置参数的数据模板及文件数据按照预设格式封装为参数包，其中，数据模板用于待配置设备按照该数据模板导入文件数据并进行参数配置。

步骤s16：将处理后的配置参数推送给待配置设备，以根据配置参数对待配置设备进行参数配置。

在本实施方式中，配置管理系统可以通过有线或无线网络、数据接口将处理后的配置参数推送给待配置设备。在其他实施方式中，配置管理系统可以将步骤s15中封装得到的参数包上传至服务器，从而使得待配置设备在下载参数配置的文件数据时，可以以参数包的方式下载该文件数据，并在下载后能够根据数据模板导入文件数据进行参数配置，从而避开了待配置设备直接下载参数配置文件数据所具有的各种不便步骤。

区别于现有技术，本实施方式通过从待配置设备获取待配置设备的类型信息，并在多个插件的程序包中查找与该类型信息对应的插件的程序包，通过调用该对应的插件的程序包对待配置设备进行配置管理。本实施方式的配置管理方法能够对多种类型的待配置设备进行配置管理，不需要分别操作多个配置(编程)软件，能够有效提高设备配置管理的效率，并提高了设备配置管理的灵活性和方便性，降低人力成本。同时，本实施方式不需要开发全新的插件程序，能够降低开发成本。

参阅图2，图2是图1中步骤s12的流程示意图，步骤s12还包括：

子步骤s121：以预设格式保存至少一个插件的程序包。

具体地，由于各个插件的程序包中的程序语言不同，导致插件的程序包的格式和存储方式具有较大差异，为了使宿主程序能够成功调用插件的程序包，本实施方式的配置管理系统可以将插件的程序包以预设格式保存在非易失性存储器中。该预设格式的插件的程序包至少包括插件的信息、插件的版本号、插件的程序包名、数据文件、数据包。

子步骤s122：根据类型信息，从已保存的插件的程序包中查找与类型信息对应的插件的程序包。

具体地，可以通过遍历方法从已保存的插件的程序包中查找与类型信息对应的插件的程序包。在其他实施方式中，也可以通过对照方法从已保存的插件的程序包中查找与类型信息对应的插件的程序包。

参阅图3和图4，图3是本申请配置管理方法另一实施方式的流程示意图，图4是本申请中宿主程序与插件一实施方式的结构示意图。在步骤s11之前，该配置管理方法还包括：

步骤s31：设置宿主程序20与插件10进行交互的协议。

具体地，所设置的协议中含有宿主程序20与插件10的信息交互方法，例如：宿主程序20调用插件10的方法和插件10自身信息描述方法，在宿主程序20调用插件10的方法中，插件10供宿主程序20调用的参数可以包括：插件10的id或标识串，插件10的功能id，插件10的32位数据参数，如数据结构指针等。宿主程序20可通过上述参数调用插件10。插件10自身信息描述方法至少包括：输出自身id或标识串，输出自身每个功能项的功能id和文字描述，和/或输出自身每个功能项的功能id和图标等。若宿主程序20调用插件10，则本插件10可输出自身的相应信息。

步骤s32：建立宿主程序20与插件10之间的进程间通信通道。

具体地，宿主程序20、插件10之间和进程间通信通道的关系可以参考图4，各插件10和宿主程序20分离，各插件10的进程与宿主程序20的进程是分开独立运行的。宿主程序20可以调用插件10，两者之间通过进程间通信(inter-processcommunication，ipc)通道进行通讯。宿主程序20给每个不同类型的待配置设备及其插件10都分配一个独立线程处理，使得宿主程序20能同时接收并进行处理不同插件10发送的消息。

在第一类型设备插件10通过该进程间通信通道传输数据时，可以按照步骤s31中所设置的协议将第一类型设备插件10发送的数据转换成通信使用的数据流，形成字节码数据。在宿主程序20经过该进程间通信系统接收第一类型设备插件10传输的数据时，可以按照步骤s31中所设置的协议再将该字节码数据转换为与第一类型设备插件10发送的数据相同的数据。

通过上述方式，在宿主程序20与插件10之间建立进程间通信，采用统一定义的数据通信协议进行数据交互，实现兼容多种类型的、不同开发语言异构的配置(编程)软件的兼容接入，不需要全新开发插件10程序，降低开发新类型设备配置软件接入的成本，提高了设备参数配置的效率及使用体验。

请参阅图5，图5是本申请配置管理方法又一实施方式的流程示意图。其中，与图1相比，在步骤s13之前，该配置管理方法还包括：

步骤s50：验证与类型信息对应的插件的程序包是否为合法的插件的程序包。

具体地，因为插件可能会被非法篡改，也可能在网络传输过程中出现数据错误，为了保证插件的正常使用，避免因为出现异常而导致反复下载或加载而增加的时间成本和流程成本，可以在处理中增加验证插件的合法性步骤。验证下载得到的插件的合法性可以通过多种方法来实现，例如，当插件的程序包在被调用时，宿主程序可以通过验证其签名信息确认插件是否安全，从而避免恶意插件对用户信息的泄露，保证了用户的信息安全。

参阅图6，图6是图5中步骤s50的流程示意图。上述步骤s50包括：

子步骤s51：加载插件，以启动插件。

具体地，在宿主程序接收到加载插件的请求时，宿主程序可以调用插件加载方法对目标插件进行加载，以启动目标插件。加载插件可以采用常见的加载方法，例如，采用系统提供的类加载器，如引导加载器(bootstrapclassloader，bcl)、扩展加载器(extensionsclassloader，ecl)、系统加载器等等。可以理解的是，加载插件还可以采用自定的类加载器来实现加载。例如，通过继承java.lang.classloader类的方式实现的类加载器，从而满足特殊的需求。具体的加载过程本申请对此并不限制。其中，至少一个加载阶段可以包括插件信息的获取、插件资源的加载、插件代码的加载。

子步骤s52：通过进程间通信通道将一协议格式的验证消息发送给插件。

具体地，宿主程序通过进程间通信通道将一协议格式的验证消息发送给插件。由于宿主程序与插件要进行通信，所以宿主程序与插件之间传递的数据需要遵循步骤s31中所设置的协议，按照此协议对传递的数据进行构造，即将验证消息按照步骤s31中所设置的协议构造得到协议格式的验证消息。其中，协议格式为协议定义的消息格式。

子步骤s53：若插件解析并回应验证消息，则与类型信息对应的插件的程序包为合法的插件的程序包。

具体地，若该插件解析该协议格式的验证消息得到对应的数据，并根据数据消息进行相应的响应处理，则与类型信息对应的插件的程序包为合法的插件的程序包。若该插件无法解析该协议格式的验证消息，则与类型信息对应的插件的程序包为不合法的插件的程序包，此时，可以返回错误信息给配置管理系统。

参阅图7，图7是本申请配置管理方法再一实施方式的流程示意图。在步骤s14之前，该配置管理方法还包括：

步骤s61：通过进程间通信通道将操作消息包发送给插件。

具体地，宿主程序通过进程间通信通道将操作消息包发送给插件。操作消息包中包括设备类型、版本号、用于表示请求配置参数的指示、用于表示请求配置参数的信令、配置参数的参数信息中的至少一种。其中，配置参数可以进一步包括现有的配置参数和全新配置参数中的至少一种；配置参数的参数信息可以包括参数名称和参数值。

步骤s62：解析操作消息包，并识别操作类型。

具体地，插件遵循步骤s31中所设置的协议，按照此协议对操作消息包进行解析，得到操作类型。该操作类型可以包括增加配置参数、修改配置参数和删除配置参数等。

步骤s63：在插件识别出操作类型后，根据操作类型显示与待配置设备对应的操作界面。

具体地，在插件识别出操作类型之后，配置管理系统根据操作类型向用户显示与待配置设备对应的操作界面，配置管理系统通过该操作界面接收用户输入的配置参数，从而实现增加配置参数、修改配置参数和删除配置参数等操作。

参阅图8，图7是图8中步骤s15的流程示意图。步骤s15包括：

子步骤s151：将配置参数封装成统一协议消息，并通过进程间通信通道将统一协议消息发送给宿主程序。

具体地，在接收用户输入的配置参数后，插件遵循步骤s31中所设置的协议，将该配置参数封装成统一协议消息，并通过进程间通信通道将统一协议消息发送给宿主程序。该统一协议消息包括设备类型、版本号和配置参数的参数信息中的至少一种。其中，配置参数可以进一步包括现有的配置参数和全新配置参数中的至少一种；配置参数的参数信息可以包括参数名称和参数值。

子步骤s152：解析统一协议消息以获取配置参数。

具体地，在插件将需要解析的统一协议消息发送到宿主程序后，宿主程序遵循步骤s31中所设置的协议，按照此协议对统一协议消息进行解析以获取上述的配置参数。

子步骤s153：将配置参数封装成统一的设备配置数据。

具体地，宿主程序将解析后的配置参数按协议规定的统一存储格式进行封装，得到统一的设备配置数据，其中，设备配置数据至少包括配置参数和待配置设备的类型信息，然后存储到本地存储模块或服务器。

参阅图9，图9是图1中步骤s16的流程示意图。步骤s16包括：

子步骤161：解析设备配置数据，以根据待配置设备的类型信息确定待配置设备。

具体地，宿主程序解析设备配置数据，从而得到配置参数和待配置设备的类型信息。

子步骤162：通过网络或远程服务器将配置参数推送给所确定的待配置设备，以根据配置参数对待配置设备进行参数配置。

具体地，配置管理系统的宿主程序可以通过有线或无线网络、数据接口或远程服务器将处理后的配置参数推送给待配置设备。

参阅图10，图10是本申请配置管理系统一实施方式的结构示意图。

该配置管理系统30用于对待配置设备进行参数配置，该配置管理系统30包括：处理器31、收发器32、存储器33和显示器34；处理器31分别耦接收发器32、存储器33和显示器34。待配置设备可以为通信设备，例如多模终端、数字对讲机、手持对讲机、数字中转台。

收发器32用于从待配置设备获取待配置设备的类型信息。

处理器31用于查找与类型信息对应的插件的程序包，并调用与类型信息对应的插件的程序包。

显示器34用于显示与待配置设备对应的操作界面，并接收在操作界面输入的配置参数。

处理器31还用于处理配置参数；收发器32还用于将处理后的配置参数推送给待配置设备，以根据配置参数对待配置设备进行参数配置。

存储器33用于保存待配置设备的类型信息、插件的程序包、配置参数以及处理后的配置参数。

其中，存储器33还用于以预设格式保存至少一个插件的程序包。

处理器31还用于根据类型信息，从已保存的插件的程序包中查找与类型信息对应的插件的程序包。

其中，处理器31还用于设置宿主程序与插件进行交互的协议，并建立宿主程序与插件之间的进程间通信通道。

其中，处理器31还用于验证与类型信息对应的插件的程序包是否为合法的插件的程序包。

其中，处理器31还用于加载插件，以启动插件。

处理器31还用于通过进程间通信通道将协议格式的验证消息发送给插件，若插件解析并回应验证消息，则与类型信息对应的插件的程序包为合法的插件的程序包，其中，协议格式为协议定义的消息格式。存储器33还用于保存协议格式的验证消息

其中，处理器31还用于通过进程间通信通道将操作消息包发送给插件，解析操作消息包，并识别操作类型。在插件识别出操作类型后，显示器34用于根据操作类型显示与待配置设备对应的操作界面。存储器33还用于保存操作消息包。

其中，处理器31还用于根据协议将配置参数封装成统一协议消息，并通过进程间通信通道将统一协议消息发送给宿主程序。处理器31还用于解析统一协议消息以获取配置参数，并将配置参数封装成统一的设备配置数据；其中，设备配置数据至少包括配置参数和待配置设备的类型信息。存储器33还用于保存统一协议消息、配置参数和设备配置数据。

其中，处理器31还用于解析设备配置数据，以根据待配置设备的类型信息确定待配置设备，并通过网络或远程服务器将配置参数推送给所确定的待配置设备，以根据配置参数对待配置设备进行参数配置。

需要说明的是，本实施方式的配置管理系统30可以执行上述配置管理方法中的步骤，相关内容的详细说明请参见上述方法部分，在此不再赘叙。

参阅图11，图11是本申请具有存储功能的装置一实施方式的结构示意图。该具有存储功能的装置40存储有程序数据41，程序数据41能够被执行以实现上述的配置管理方法，具体执行过程请参见上述方法实施方式的描述，在此不再赘述。具有存储功能的装置40可以是能够携带程序数据41的任何装置，例如u盘、光盘、以及终端、服务器等，在此不做限定。

需要说明的是，在本文中，诸如第一和第二之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个······”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同因素。

本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储装置中，包括若干指令用以使得一台计算机终端(可以是个人计算机，服务器，或者网络终端等)或处理器(processor)执行本申请各个实施方式所述方法的全部或部分步骤。而前述的存储装置包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的装置。

以上实施方式，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施方式对本申请进行了详细的说明，本领域技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施方式所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施方式技术方案的精神和范围，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。