一种多语言健康管理模型的融合方法、装置与流程

本申请涉及故障预测与健康管理技术领域，尤其涉及一种多语言健康管理模型的融合方法、装置。

背景技术：

健康管理模型是实现复杂装备phm(prognosticshealthmanagement，故障预测与健康管理)的核心技术，这些健康管理模型主要用来实现对复杂设备的异常检测、故障诊断、故障预测、维修决策等综合性需求。当针对复杂设备(例如飞机、特种车辆、卫星等)进行健康管理平台开发时，由于复杂设备结构的复杂性，一般的研发团队由于其技术领域的限制，已经无法实现装备级的phm系统开发，需要大量的不同领域、不同专业的研发团队合作，开发满足不同需求的健康管理模型。

这种大量的不同领域、不同专业的研发团队合作，带来的问题在于不同的研发团队使用的技术尤其是开发语言存在较大差异，比如phm系统开发人员普遍采用面向对象的java语音进行web开发，而算法工程师更偏向于采用python和matlab语言进行健康管理模型的开发。当不同领域、不同专业的研发团队数量较多时，统一使用一种开发语言来进行健康管理模型的开发，需要消耗较大的时间和精力，不能充分发挥不同领域、不同专业的研发团队的效率。因此，如何解决这种多语言健康管理模型的融合是当前phm系统开发亟待解决的问题。

技术实现要素：

为了解决上述技术问题或者至少部分地解决上述技术问题，本申请提供了一种多语言健康管理模型的融合方法、装置、服务器及存储介质。

第一方面，本申请提供了一种多语言健康管理模型的融合方法，所述方法包括：

获取多种类型的健康管理模型，其中，多种类型的所述健康管理模型由不同开发语言实现；

针对每种类型的所述健康管理模型，在预设的容器平台中配置对应的运行环境；

针对每种类型的所述健康管理模型进行封装，以使预设的微服务架构进行识别；

将经过封装的每种类型的所述健康管理模型，在预设的微服务架构中进行对应的微服务注册以及发布。

可选的，所述针对每种类型的所述健康管理模型，在预设的容器平台中配置对应的运行环境，包括：

针对每种类型的所述健康管理模型，确定开发语言类型；

基于所述开发语言类型在预设的容器平台中配置对应的运行环境。

可选的，所述针对每种类型的所述健康管理模型进行封装，以使预设的微服务架构进行识别，包括：

针对每种类型的所述健康管理模型确定输入接口以及输出接口；

对所述输入接口以及所述输出接口进行封装，以使预设的微服务架构进行识别。

可选的，所述将经过封装的每种类型的所述健康管理模型，在预设的微服务架构中进行对应的微服务注册以及发布，包括：

确定预设的微服务架构中提供的微服务接口以及微服务注册中心；

将经过封装的每种类型的所述健康管理模型，利用所述微服务接口，在所述微服务注册中心中进行对应的微服务注册以及发布。

可选的，所述方法还包括：

当接收到访问请求时，根据所述访问请求中携带的微服务标识确定目标微服务；

查找与所述目标微服务对应的目标健康管理模型；

将所述访问请求中携带的模型输入参数传输至所述目标健康管理模型；

接收并反馈所述目标健康管理模型返回的运算结果，其中，所述运算结果为所述目标健康管理模型在预设的容器平台中的对应的运行环境，根据所述模型输入参数进行运算得到的结果。

第二方面，本申请提供了一种多语言健康管理模型的融合装置，所述装置包括：

模型获取模块，用于获取多种类型的健康管理模型，其中，多种类型的所述健康管理模型由不同开发语言实现；

环境配置模块，用于针对每种类型的所述健康管理模型，在预设的容器平台中配置对应的运行环境；

模型封装模块，用于针对每种类型的所述健康管理模型进行封装，以使预设的微服务架构进行识别；

微服务注册、发布模块，用于将经过封装的每种类型的所述健康管理模型，在预设的微服务架构中进行对应的微服务注册以及发布。

可选的，所述环境配置模块具体用于：

针对每种类型的所述健康管理模型，确定开发语言类型；

基于所述开发语言类型在预设的容器平台中配置对应的运行环境。

可选的，所述模型封装模块具体用于：

针对每种类型的所述健康管理模型确定输入接口以及输出接口；

对所述输入接口以及所述输出接口进行封装，以使预设的微服务架构进行识别。

第三方面，本申请提供了一种服务器，包括：至少一个处理器、以及与处理器连接的至少一个存储器、总线；其中，所述处理器、所述存储器通过所述总线完成相互间的通信；所述处理器用于调用所述存储器中的程序指令，以执行上述第一方面中任一项所述的多语言健康管理模型的融合方法。

第四方面，本申请提供了一种存储介质，所述存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现上述第一方面中任一项所述的多语言健康管理模型的融合方法。

本申请实施例提供的技术方案，对于每种类型的健康管理模型，在预设的容器平台中配置对应的运行环境，以及对于每种类型的健康管理模型进行封装，并在预设的微服务架构中进行对应的微服务注册以及发布。如此本申请采用容器与微服务架构的方式，能够将健康管理模型的运行环境以及开发语言特效进行隐藏，进而能够从架构层次解决多语言健康管理模型的融合问题，有利于提高phm系统的开发效率。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

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

图1为本申请实施例提供的一种多语言健康管理模型的融合方法的实施流程示意图；

图2为本申请实施例提供的一种docker容器平台中各种开发语言运行时环境的示意图；

图3为本申请实施例提供的一种在eureka发布微服务的示意图；

图4为本申请实施例提供的一种多语言健康管理模型的融合装置的结构示意图；

图5为本申请实施例提供的一种服务器的结构示意图。

具体实施方式

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

目前在故障预测与健康管理技术领域中，为了实现对复杂设备的异常检测、故障诊断、故障预测、维修决策等综合性需求，需要大量的不同领域、不同专业的研发团队合作，开发满足不同需求的健康管理模型。

这种大量的不同领域、不同专业的研发团队合作，带来的问题在于不同的研发团队使用的技术尤其是开发语言存在较大差异，因此对于健康管理模型，每个研发团队使用的开发语言不尽相同，存在多种类型的健康管理模型，即多种类型的健康管理模型由不同开发语言实现。

为了实现多语言健康管理模型的融合，便于多语言健康管理模型的统一调用，本申请实施例对于每种类型的健康管理模型，在预设的容器平台中配置对应的运行环境，以及对于每种类型的健康管理模型进行封装，并在预设的微服务架构中进行对应的微服务注册以及发布。如此本申请采用容器与微服务架构的方式，能够将健康管理模型的运行环境以及开发语言特效进行隐藏，进而能够从架构层次解决多语言健康管理模型的融合问题，有利于提高phm系统的开发效率。

如图1所示，为本申请实施例提供的一种多语言健康管理模型的融合方法的实施流程示意图，该方法具体可以包括以下步骤：

s101，获取多种类型的健康管理模型，其中，多种类型的所述健康管理模型由不同开发语言实现；

对于不同开发语言实现的健康管理模型，由研发人员研发完毕之后，可以存储于磁盘中，本申请实施例获取这些多种类型的健康管理模型，以便于对这些多种类型的健康管理模型进行融合，充分发挥各自开发语言实现的健康管理模型的优势，更高效地实现复杂、综合的装备健康管理需求。

例如，在本申请实施例中，对于多种类型的健康管理模型可以是由c语言实现的健康管理模型、由c++语言实现的健康管理模型、由python语言实现的健康管理模型、由matlab语言实现的健康管理模型等，可以获取上述由c语言实现的健康管理模型、由c++语言实现的健康管理模型、由python语言实现的健康管理模型、由matlab语言实现的健康管理模型。

需要说明的是，对于健康管理模型，可以是当前由任意开发语言实现的健康管理模型，本申请实施例对此不作限定。

s102，针对每种类型的所述健康管理模型，在预设的容器平台中配置对应的运行环境；

对于上述获取的多种类型的健康管理模型，针对每种类型的健康管理模型，本申请在预设的容器平台中配置对应的运行环境。

具体地，针对每种类型的所述健康管理模型，确定开发语言类型，基于所述开发语言类型在预设的容器平台中配置对应的运行环境。

例如，对于由c语言实现的健康管理模型、由c++语言实现的健康管理模型、由python语言实现的健康管理模型、由matlab语言实现的健康管理模型等，可以确定各自对应的开发语言类型：c语言、c++语言、python语言、matlab语言等；

基于上述开发语言类型：c语言、c++语言、python语言、matlab语言等，本申请实施例可以在docker容器平台分别配置由c++语言实现的健康管理模型、由python语言实现的健康管理模型、由matlab语言实现的健康管理模型等各自对应的运行环境，如图2所示。

其中，在本申请实施例中对于docker容器平台，可以在服务器中安装docker工具，以ubuntu为例，可以采用在线安装的方式，执行docker指令即可完成docker的安装，如此可以搭建docker容器平台；

获取docker的linux镜像，作为最基础的系统环境，基于linux镜像，实例化构建docker容器，在多个docker容器中分别配置由c语言实现的健康管理模型、由c++语言实现的健康管理模型、由python语言实现的健康管理模型、由matlab语言实现的健康管理模型等各自对应的运行环境，并配置相关的环境变量，如此各个健康管理模型之间没有耦合性，彼此独立、互不影响。

s103，针对每种类型的所述健康管理模型进行封装，以使预设的微服务架构进行识别；

在本申请实施例中，对于上述获取的多种类型的健康管理模型，针对每种类型的健康管理模型，一方面在预设的容器平台中配置对应的运行环境，另一方面进行封装，以使预设的微服务架构进行识别。

其中，在本申请实施例中针对每种类型的所述健康管理模型确定输入接口以及输出接口，对所述输入接口以及所述输出接口进行封装，以使预设的微服务架构可识别。对于每种类型的健康管理模型，因其开发语言的不同，对输入接口以及输出接口的封装方式不同。

例如，对于微服务架构，可以是springcloud架构，在本申请实施例中搭建springcloud架构，构建微服务的开发、运行、管理平台，针对每种类型的所述健康管理模型确定输入接口以及输出接口，对所述输入接口以及所述输出接口进行封装，以使预设的微服务架构可识别：

对于由python语言实现的健康管理模型，确定其输入接口以及输出接口，利用flask框架对输入接口以及输出接口进行封装，便于与springcloud架构进行交互；

对于由matlab语言实现的健康管理模型，确定其输入接口以及输出接口，使用matlab的专业工具librarycompiler，将mtalab代码转化为javapackage，然后以库调用package中的类，用java方法封装相应的输入接口以及输出接口，进而将matlab语言以java接口形式进行封装，便于与springcloud架构进行交互；

对于由c语言实现的健康管理模型、由c++语言实现的健康管理模型，确定其输入接口以及输出接口，如果平台是windows平台，可以将输入接口以及输出接口转换为dll动态链接库，利用jni库对输入接口以及输出接口进行封装，便于与springcloud架构进行交互，如果平台是linux，将输入接口以及输出接口转换为.so动态链接库，利用jni库对输入接口以及输出接口进行封装，便于与springcloud架构进行交互。

s104，将经过封装的每种类型的所述健康管理模型，在预设的微服务架构中进行对应的微服务注册以及发布。

对于上述获取的多种类型的健康管理模型，在对输入接口以及输出接口进行封装之后，可以与微服务架构进行交互，进而可以将经过封装的每种类型的健康管理模型，在预设的微服务架构中进行对应的微服务注册以及发布。

其中，可以利用微服务架构中提供的微服务接口以及微服务注册中心，将经过封装的每种类型的所述健康管理模型，利用所述微服务接口，在所述微服务注册中心中进行对应的微服务注册以及发布。

例如，对于经过封装的由c语言实现的健康管理模型、经过封装的由c++语言实现的健康管理模型、经过封装的由python语言实现的健康管理模型、经过封装的由matlab语言实现的健康管理模型，利用springcloud架构提供的微服务接口，使用eureka(微服务注册中心)进行微服务的注册和发布，如此对于经过封装的由c语言实现的健康管理模型、经过封装的由c++语言实现的健康管理模型、经过封装的由python语言实现的健康管理模型、经过封装的由matlab语言实现的健康管理模型，可以在eureka(微服务注册中心)发现对应的微服务，如图3所示。

对于多种类型的健康管理模型，各自对应一个微服务，存在唯一使用http访问的方法实现微服务的调用，最终实现多语言健康管理模型的融合使用：

当接收到的访问请求(例如http请求)时，根据所述访问请求中携带的微服务标识确定目标微服务；查找与所述目标微服务对应的目标健康管理模型；将所述访问请求中携带的模型输入参数传输至所述目标健康管理模型；接收并反馈所述目标健康管理模型返回的运算结果，其中，所述运算结果为所述目标健康管理模型在预设的容器平台中的对应的运行环境，根据所述模型输入参数进行运算得到的结果。

例如，当接收到的phm业务系统访问请求时，解析该访问请求中携带的微服务标识以及模型输入参数；根据微服务标识确定目标微服务a；查找与目标微服务a对应的目标健康管理模型(由c++语言实现的健康管理模型1)；将访问请求中携带的模型输入参数传输至目标健康管理模型(由c++语言实现的健康管理模型1，已经可以与springcloud架构进行交互)；接收并反馈目标健康管理模型(由c++语言实现的健康管理模型1)返回的运算结果。

其中，目标健康管理模型(由c++语言实现的健康管理模型1)在docker容器平台中的c++语言运行时环境，根据模型输入参数进行运算得到运算结果，并回传至springcloud架构。如此通过http访问的形式可以实现多语言健康管理模型的统一调用。

通过上述对本申请实施例提供的技术方案的描述，对于每种类型的健康管理模型，在预设的容器平台中配置对应的运行环境，以及对于每种类型的健康管理模型进行封装，并在预设的微服务架构中进行对应的微服务注册以及发布。如此本申请采用容器与微服务架构的方式，能够将健康管理模型的运行环境以及开发语言特效进行隐藏，进而能够从架构层次解决多语言健康管理模型的融合问题，有利于提高phm系统的开发效率。

与上述方法实施例相对应，本申请实施例还提供了一种多语言健康管理模型的融合装置，如图4所示，所述装置包括：模型获取模块410、环境配置模块420、模型封装模块430、微服务注册、发布模块440。

模型获取模块410，用于获取多种类型的健康管理模型，其中，多种类型的所述健康管理模型由不同开发语言实现；

环境配置模块420，用于针对每种类型的所述健康管理模型，在预设的容器平台中配置对应的运行环境；

模型封装模块430，用于针对每种类型的所述健康管理模型进行封装，以使预设的微服务架构进行识别；

微服务注册、发布模块440，用于将经过封装的每种类型的所述健康管理模型，在预设的微服务架构中进行对应的微服务注册以及发布。

在本申请实施例的具体实施方式中，所述环境配置模块420具体用于：

针对每种类型的所述健康管理模型，确定开发语言类型；

基于所述开发语言类型在预设的容器平台中配置对应的运行环境。

在本申请实施例的具体实施方式中，所述模型封装模块430具体用于：

针对每种类型的所述健康管理模型确定输入接口以及输出接口；

对所述输入接口以及所述输出接口进行封装，以使预设的微服务架构进行识别。

所述多语言健康管理模型的融合装置包括处理器以及存储器，上述模型获取模块410、环境配置模块420、模型封装模块430、微服务注册、发布模块440等均作为程序模块存储在存储器中，由处理器执行存储在存储器中的上述程序模块来实现相应的功能。

如图5所示，为本发明实施例提供的一种服务器的结构示意图，图5所示的服务器包括：处理器51、通信接口52、存储器53和通信总线54，其中，处理器51，通信接口52，存储器53通过通信总线54完成相互间的通信，

存储器53，用于存放计算机程序；

处理器51，用于执行存储器53上所存放的程序时，实现如下步骤：

获取多种类型的健康管理模型，其中，多种类型的所述健康管理模型由不同开发语言实现；针对每种类型的所述健康管理模型，在预设的容器平台中配置对应的运行环境；针对每种类型的所述健康管理模型进行封装，以使预设的微服务架构进行识别；将经过封装的每种类型的所述健康管理模型，在预设的微服务架构中进行对应的微服务注册以及发布。

上述服务器提到的通信总线可以是外设部件互连标准(peripheralcomponentinterconnect，简称pci)总线或扩展工业标准结构(extendedindustrystandardarchitecture，简称eisa)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信接口用于上述服务器与其他设备之间的通信。

存储器可以包括随机存取存储器(randomaccessmemory，简称ram)，也可以包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器，包括中央处理器(centralprocessingunit，简称cpu)、网络处理器(networkprocessor，简称np)等；还可以是数字信号处理器(digitalsignalprocessing，简称dsp)、专用集成电路(applicationspecificintegratedcircuit，简称asic)、现场可编程门阵列(field－programmablegatearray，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

本发明实施例还提供了一种存储介质(计算机可读存储介质)。这里的存储介质存储有一个或者多个程序。其中，存储介质可以包括易失性存储器，例如随机存取存储器；存储器也可以包括非易失性存储器，例如只读存储器、快闪存储器、硬盘或固态硬盘；存储器还可以包括上述种类的存储器的组合。

当存储介质中一个或者多个程序可被一个或者多个处理器执行，以实现上述在多语言健康管理模型的融合设备侧执行的多语言健康管理模型的融合方法。

所述处理器用于执行存储器中存储的多语言健康管理模型的融合程序，以实现以下在多语言健康管理模型的融合设备侧执行的多语言健康管理模型的融合方法的步骤：

获取多种类型的健康管理模型，其中，多种类型的所述健康管理模型由不同开发语言实现；针对每种类型的所述健康管理模型，在预设的容器平台中配置对应的运行环境；针对每种类型的所述健康管理模型进行封装，以使预设的微服务架构进行识别；将经过封装的每种类型的所述健康管理模型，在预设的微服务架构中进行对应的微服务注册以及发布。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

在一个典型的配置中，设备包括一个或多个处理器(cpu)、存储器和总线。设备还可以包括输入/输出接口、网络接口等。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)，存储器包括至少一个存储芯片。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本发明的实施例可提供为方法、系统或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本发明的实施例而已，并不用于限制本发明。对于本领域技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本发明的权利要求范围之内。