实验室管理系统的制作方法

本发明涉及计算机技术领域，特别是涉及一种实验室管理系统。

背景技术：

随着国内对科技创新重视程度的逐步提高，科研单位纷纷建立了不同领域的实验室。尤其是一些大型的科研机构，实验室数量众多，形成了庞大规模的实验室群，为实验室的管理带来困难。为了规范化实验室管理，满足cnas(chinanationalaccreditationserviceforconformityassessment中国合格评定国家认可委员会)的认可要求，衍生出了实验室管理系统，用于对实验室设备数据、实验过程数据和实验记录数据等实验室数据进行管理。

传统的实验室管理系统采用的是一体化的单体管理系统，即根据实验室的功能需求和对应的实验室编译的一体化应用，一体化应用执行实验室的业务功能逻辑，汇总根据业务功能逻辑所生成的实验室数据，以便于管理人员进行管理。在实验室的实际使用中，实验室的功能需求或实验室数量常常需要变更和拓展，导致管理系统应用层的业务功能逻辑的变更，然而传统的一体化的单体管理系统的耦合程度高、内部程序结构复杂，不便于针对业务运行需求的变更作整体改造和升级。

技术实现要素：

基于此，有必要针对传统的一体化的单体管理系统的耦合程度高、内部程序结构复杂，不便于针对业务运行需求的变更作整体改造和升级的缺陷，提供一种实验室管理系统。

本发明所提供的技术方案如下：

一种实验室管理系统，包括：

一个或多个独立应用容器和数据管理平台；其中，数据管理平台分别与独立应用容器连接。

数据管理平台将设定的配置参数发送至独立应用容器，独立应用容器根据设定的配置参数生成用于执行实验室中一项业务功能逻辑的独立应用。

独立应用将执行业务功能逻辑所生成的实验室数据发送至数据管理平台。

本发明所提供的技术方案，数据管理平台分别与每个独立应用容器连接，将设定的配置参数发送至对应的独立应用容器，以使独立应用容器生成对应的独立应用，通过独立应用来执行实验室中的对应一项业务功能逻辑，生成实验室数据并将实验室数据发送至数据管理平台便于管理人员进行处理。基于此，在实验室的功能需求或实验室数量变更或拓展时，能够灵活配置用于运行变更或拓展后的业务功能逻辑的独立应用，便于进行实验室管理系统相应的改造和升级。

附图说明

图1为实施例一的实验室管理系统结构示意图；

图2为实施例二的实验室管理系统结构示意图；

图3为优选实施例二的实验室管理系统结构示意图；

图4为实施例三的实验室管理系统结构示意图；

图5为优选实施例三的实验室管理系统结构示意图；

图6为微服务构建技术架构示意图。

具体实施方式

为了更好地理解本发明的目的、技术方案以及技术效果，以下结合附图和实施例对本发明进行进一步的讲解说明。同时声明，以下所描述的实施例仅用于解释本发明，并不用于限定本发明。

在实施例一中，如图1所示，为实施例一的实验室管理系统结构示意图，包括：

一个或多个独立应用容器101和数据管理平台102；其中，数据管理平台102分别与独立应用容器101连接。

其中，独立应用容器101可通过容器技术独立构建，容器技术包括基于java的容器技术和基于docker引擎的应用容器技术等。

其中，根据不同的应用场景，可以为实验室管理系统构建不同的终端设备结构。可以在同一计算机设备上运行实验室管理系统，计算机设备同时运行对应的独立应用容器101和数据管理平台102。

搭建针对分布式实验室的终端设备结构，在各个实验室搭建一台计算机设备，用于运行指定的一部或全部独立应用容器101，在服务器搭建数据管理平台102，通过在计算机设备和服务器间连接的方式，实现数据管理平台102与计算机设备的数据交互，使实验人员可以在各实验室中独立操作对应的独立应用。

在指定的终端设备上搭建独立应用容器101，在服务器搭建数据管理平台102。基于此，提高实验室数据管理系统的使用灵活性。

数据管理平台102将设定的配置参数发送至对应的独立应用容器101，独立应用容器101根据设定的配置参数生成用于执行实验室的一项业务功能逻辑的独立应用。

其中，独立应用执行一项业务功能逻辑，对应满足一项实验室功能需求的执行。

其中，独立应用容器101本身不具备执行业务功能逻辑的应用逻辑，数据管理平台102将设定的配置参数发送至对应的独立应用容器101后，独立应用容器101根据接收到的设定的配置参数生成用于执行业务功能逻辑的独立应用。

其中，软件编译人员可以根据实验室中不同的功能需求，编译可执行对应业务运行需求的设定的配置参数，并将该设定的配置运存至数据管理平台102。以计量实验室为例，计量实验室中的一项功能需求为计量校准，软件编译人员可以根据软件实验室执行计量校准的过程，编译可执行计量校准的业务运行需求的配置参数，并将该配置参数预存至数据管理平台102，数据管理平台102可以根据该配置参数的信息将该配置参数发送至对应的独立应用容器101。基于此，在实验室的功能需求发生变化时，以配置对应的配置参数，满足不同的功能需求。

同时，各独立应用容器101间是相互独立，各独立应用容器101间不存在数据交互过程。在实验室的功能需求或实验室数量增加时，相应为独立应用容器101配置设定的配置参数，生成执行实验室的一项业务功能逻辑的独立应用，以实现实验室管理系统的灵活拓展。

其中，在实验室的功能需求或实验室数量减少时，相应为独立应用容器101配置设定的配置参数，使对应独立应用容器101中的独立应用停止运行业务运行需求，以降低实验室管理系统的数据冗余。

独立应用将执行业务功能逻辑所生成的实验室数据发送至所述数据管理平台102。

根据业务运行需求，每个独立应用执行对应实验室中对应一项功能需求，将生成的实验室数据发送至数据管理平台102。

每个独立应用执行对应实验室中对应一项功能需求，降低了实验室管理系统的耦合程度，便于进行独立应用的快速更新和部署。

本实施例一所提供的技术方案，数据管理平台102分别与每个独立应用容器101连接，将设定的配置参数发送至对应的独立应用容器101，以使独立应用容器101生成对应的独立应用，通过独立应用来执行实验室中的一项业务功能逻辑，生成实验室数据并将实验室数据发送至数据管理平台102便于管理人员进行处理。基于此，在实验室的功能需求或实验室数量变更或拓展时，能够灵活配置用于运行变更或拓展后业务功能逻辑的独立应用，便于进行实验室管理系统相应的改造和升级。

在实施例二中，如图2所示，为实施例二的实验室管理系统结构示意图，包括：一个或多个独立应用容器101、数据管理平台102和实验室数据管理模块201，实验室数据管理模块201与被管理的实验室一一对应。

数据管理平台102分别与实验室数据管理模块201连接。

实验室数据管理模块201分别与生成用于执行与其对应实验室的业务功能逻辑的独立应用的独立应用容器101连接。

其中，每个实验室数据管理模块201对应一个实验室，用于汇总执行该实验室的业务功能逻辑所生成的实验室数据。可选地，实验室数据管理模块201的数量与实验室数量对应一致。

数据管理平台102通过实验室数据管理模块201将设定的配置参数发送至对应的独立应用容器101，独立应用容器101根据设定的配置参数生成用于执行对应实验室中一项业务功能逻辑的独立应用。

其中，实验室可以分为特高压实验室、信息通信实验室、计量实验室等。不同的实验室包括不同的一个或多个功能需求，各实验室对应配置与其业务功能逻辑对应的独立应用容器101，数据管理平台102将对应特定实验室的设定的配置参数发送至特定实验室所包括的独立应用容器101中。

独立应用将执行业务功能逻辑所生成的实验室数据发送至实验室数据管理模块201，实验室数据管理模块201将实验室数据发送至数据管理平台102。

通过本实施例二所提供的技术方案，将不同实验室的数据分别汇总，便于对实验室管理系统对不同实验室的数据进行分类，提供实验室管理系统的管理效率。

优选地，在实施例二中，如图3所示，为优选实施例二的实验室管理系统结构示意图，实验室管理系统还包括第一数据存储模块301和第二数据存储模块302。

第一数据存储模块301与数据管理平台102连接，用于存储数据管理平台102接收到的实验室数据。

其中，第一数据存储模块301可以为云数据库或本地数据库，在数据管理平台102出现数据丢失时，可通过云数据库或本地数据库进行反向数据恢复，将实验室数据导回数据管理平台102中。

第二数据存储模块302与实验室数据管理模块201连接，用于存储实验室数据管理模块201接收到的实验室数据。

其中，每个所述第二数据存储模块302对应连接一个实验室数据管理模块201。

其中，第二数据存储模块302可以为云数据库或本地数据库，在实验室数据管理模块201出现数据丢失时，可通过云数据库或本地数据库进行反向数据恢复，将实验室数据导回实验室数据管理模块201中。

本优选实施例二所提供的技术方案，通过第一数据存储模块301和第二数据存储模块302，将全部实验室数据和特定实验室的数据分开保存，有效防止实验室管理系统的数据丢失。

在实施例三中，如图4所示，为实施例三的实验室管理系统结构示意图，包括一个或多个独立应用容器101、数据管理平台102和一个或多个类数据管理模块401。

数据管理平台102分别与类数据管理模块401连接。

每个类数据管理模块401用于与预设的一个或多个独立应用容器101连接。

数据管理平台102通过类数据管理模块401将设定的配置参数发送至对应的独立应用容器101，独立应用容器101根据设定的配置参数生成用于执行实验室的一项业务功能逻辑的独立应用。

其中，每个类数据管理模块401对应连接的独立应用容器101中配置生成的独立应用均为执行同一类功能需求的独立应用。其中，在本实施例二中，将常见的实验室的功能需求分为三大类，包括：实验室cnas质量管理类、实验检测业务类和基础功能支撑类，具体为：

实验室cnas质量管理类的功能需求包括根据实验室cnas质量体系和程序文件的实验室管理构建、实验室组织、管理体系文件控制、合同管理、采购管理、客户投诉、不符合项管理、纠正/预防措施管理、内审、管理评审、设备管理、安全内务、样品/试品管理、能力验证、监督检查、培训等功能需求。

实验检测业务类功能需求为各实验室根据不同的检测领域和检测项，将各实验室特有的试验检测业务抽象独立构建成的功能需求，是各实验室具体开展检测业务的业务功能实体，具体包括：软件测试、数通硬件测试、计量校准和特高压检测等功能需求。

基础功能支撑类功能需求包括身份认证、流程管理、配置管理、综合查询和报表生成等为实验室运行提供基础功能支撑的功能需求。

基于功能需求的分类，类数据管理模块401包括：实验室cnas质量管理类数据管理模块、实验检测业务类管理模块和基础功能支撑类数据管理模块。软件编译人员可以基于功能需求的分类，为每项功能需求编写设定的配置参数，数据管理平台102将同一类功能需求对应的设定的配置参数发送至对应的类数据管理模块401，类数据管理模块401再将每段设定的配置参数发送至对应的独立应用容器101中，生成用于执行实验室的一项业务功能逻辑的独立应用。

独立应用将执行业务功能逻辑所生成的实验室数据发送至类数据管理模块401，类数据管理模块401将实验室数据发送至数据管理平台102。

本实施例三所提供的技术方案，将不同实验室的数据分别汇总，便于对实验室管理系统对不同实验室的数据进行分类，提供实验室管理系统的管理效率。

优选地，在实施例三中，如图5所示，为优选实施例三的实验室管理系统结构示意图，实验室管理系统还包括第一数据存储模块301和第三数据存储模块501。

第一数据存储模块301与数据管理平台102连接，用于存储数据管理平台102接收到的实验室数据。

其中，第一数据存储模块301可以为云数据库或本地数据库，在数据管理平台102出现数据丢失时，可通过云数据库或本地数据库进行反向数据恢复，将实验室数据导回数据管理平台102中。

其中，每个所述第三数据存储模块501对应连接一个类数据管理模块401。

第三数据存储模块501与类数据管理模块401连接，用于存储类数据管理模块401接收到的实验室数据。

其中，每个所述第三数据存储模块501对应连接一个类数据管理模块401。

其中，第三数据存储模块501可以为云数据库或本地数据库，在类数据管理模块401出现数据丢失时，可通过云数据库或本地数据库进行反向数据恢复，将实验室数据导回类数据管理模块401中。

本优选实施例三所提供的技术方案，通过第一数据存储模块301和第三数据存储模块501，将全部实验室数据和不同类的实验室的数据分开保存，有效防止实验室管理系统的数据丢失。

在一实施例中，上述实验室管理模块还包括接口配置模块；

接口配置模块与数据管理平台102连接，用于通过数据管理平台102为各独立应用容器101间配置数据交互接口。

在某些特定的独立应用容器101间需要进行数据交互时，可通过接口配置模块为需要进行数据交互的独立应用容器101间配置数据交互接口，实现独立应用容器101间的数据交互，以提升实验室管理系统的灵活性。接口配置模块的具体实现方式参见实施例四中独立应用容器101中构建微服务为例进行解释，在此不予赘述。

在一实施例中，上述实验室管理模块还包括独立应用容器101建立模块；

独立应用容器101建立模块与数据管理平台102连接，用于通过数据管理平台102在预设目标地址的终端设备上搭建独立应用容器101。

在独立应用容器101数量无法满足实验室的功能需求时，通过独立应用容器101建立模块建立新的独立应用容器101。在此以在终端设备上搭建基于docker引擎的应用容器为例，以基于docker引擎的应用容器作为独立应用容器101，独立应用容器101建立模块将建立docker引擎的应用容器通过数据管理平台102发送至目标地址的终端设备web平台上，通过web配置在终端设备的web平台上建立应用容器。

在实施例四中，上述独立应用和数据管理平台102均为基于容器技术的微服务。其中，容器技术包括基于java的容器技术和基于docker引擎的应用容器技术。独立应用和数据管理平台102均为基于java的容器或基于docker引擎的应用容器中构建的微服务。

为了更好解释本实施例，通过基于docker引擎的应用容器技术构建的独立应用容器101为例，对在独立应用容器101中构建微服务的过程进行说明。

如图6所示，为微服务构建技术架构示意图，在独立应用容器101中构建微服务的过程如下：

实验室管理系统通过web配置将httpservletrequest(公共接口类请求)请求统一交由proxy(代理服务器)进行处理。

proxy通过向configmananger(配置类)查询实验室微服务关联配置信息，并根据配置注册的微服务信息将请求转发到相应的微服务上。proxy同时提供运行状态监测、负载均衡等系统功能。

configmananger提供对实验室对应功能需求的设定的配置信息，其中，设定的配置信息包括微服务的名称、ip地址、url(uniformresourcelocator统一资源定位符)、状态和restapi等。其中，通过configmananger获取数据管理平台的设定的配置信息。通过httpservletresponse(公共接口类反馈)将微服务根据业务运行需求执行功能需求产生的实验室数据反馈至数据管理平台。

执行完毕实验室业务功能逻辑的微服务，可通过其开放的url和restapi对其进行访问。

其中，restapi是微服务对外提供服务的接口，通过restapi微服务与微服务及浏览器间可进行消息交互。

同时，构建完成的微服务为一个可用于运行对应业务功能逻辑的独立应用

其中，每个微服务包含ui展示层、业务流程逻辑层和数据层。ui展示层用于面向实验室管理系统的用户，业务逻辑层用于运行对应业务功能逻辑，数据层用于存储相应实验室数据。

其中，每个微服务均可被直接访问和运行，能够完成信息展示、数据输入、输出和统计分析等。

各个微服务用于执行实验室的业务功能逻辑，通过和流程引擎交互具备业务流程控制能力，能够进行业务逻辑运算。

各微服务提供交互restapi，微服务间通过接口进行相互通信完成工作协同。

各微服务方式包括独立的数据，所有微服务间采用共享数据集的方式实现数据互访，以降低实验室数据访问的复杂度。

实施例四所提供的技术方案，通过基于容器技术的微服务实现独立应用和数据管理平台102的搭建，使实验室管理系统可通过轻量级的web应用服务实现，系统内部的数据交互可最大化利用服务器能力，从而支持devops(development和operations的组合)快速开发部署，提升实验室管理系统应对实验室功能需求和实验室数量变化的改造升级能力。同时，基于微服务构建实验室管理系统，在单个微服务出现故障时不影响其它微服务，提升实验室管理系统的稳定性。

在实施例一中，实验室数据管理模块201为基于容器技术的微服务，以使实验室管理系统由微服务搭建，提升实验室管理系统应对实验室功能需求和实验室数量变化的改造升级能力和稳定性。

在实施例一中，类数据管理模块401为基于容器技术的微服务，以使实验室管理系统由微服务搭建，提升实验室管理系统应对实验室功能需求和实验室数量变化的改造升级能力和稳定性。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。