CN115115329A - 一种面向智能生产线的制造中间件及云制造架构 - Google Patents

Abstract

本发明公开了一种面向智能生产线的制造中间件及云制造架构，该制造中间件包括工作流管理模块、组件管理模块和模型仓库；工作流管理模块通过工作流对组件服务的执行顺序进行定义、监控和调用；组件管理模块完成组件的动态注册与删除；模型仓库用于领域模型、语义模型和应用模型的存储和展示；工作流管理模块获得服务资源目录，并依据流程定义进行资源匹配，将业务流程中的各活动分配到服务资源，执行工作流并监控执行过程；工作流管理模块根据服务的基本信息创建OPC UA的客户端对服务进行调用，触发适配器中OPC UA服务器的变量和方法节点。本发明提供了资产的敏捷部署的方式，使资产能快速部署并集成到制造系统，并通过工作流管理模块使其可以被快速组合生产。

Description

一种面向智能生产线的制造中间件及云制造架构

技术领域

本发明涉及云制造技术领域，具体涉及一种面向智能生产线的制造中间件及云制造架构。

背景技术

网络化制造是指整合分布式资源来承担制造任务的生产模式，而服务被认为是解决网络化制造中分布式架构的有效方式，而云计算就是面向服务架构的智能技术。在云计算中，一切都被当作一种服务(即XaaS)，这些服务为云计算定义了一个分层系统结构，分别为IaaS(基础设施即服务)、PaaS(平台即服务)和SaaS(软件即服务)。在基础设施层IaaS，运算能力、存储空间、网络服务和其他基本基础设置资源都被定义标准化服务，云供应商的客户可以在此基础上部署和运行操作系统和软件。中间层PaaS为开发、测试、部署、托管和维护集成开发环境中的应用提供抽象和服务。应用层SaaS提供完整的软件应用集。

与云计算类似，云制造中的三种服务模式分别为IaaS、PaaS和SaaS。PaaS会将服务涉及到的组件交互和服务的动态管理隐藏，仅提供更高维和易用的可视化人机交互界面和低代码量的开发平台。开发者只需对制造资源进行图形化编程和参数配置即可形成特定的生产场景应用。在信息物理系统中，PaaS作为各个子系统之间的通用接口，对于各生产要素之间的连接至关重要，能够从每个组件接收和转换数据并将其转发到其他组件。

但目前网络化制造尚缺少对服务的集中化操作管理，使得制造资源和计算资源难以适应无缝、稳定和高质量的交互要求。其次，在传统的服务分布式制造环境中，服务提供者和服务需求之间几乎没有协调管理。

发明内容

为了克服现有技术存在的缺陷与不足，本发明提供一种面向智能生产线的制造中间件及云制造架构，本发明的制造中间件提供了资产的敏捷部署的方法，使资产能快速部署并集成到制造系统，并通过工作流管理模块使其可以被快速组合生产。

为了达到上述目的，本发明采用以下技术方案：

一种面向智能生产线的制造中间件，包括：工作流管理模块、组件管理模块和模型仓库；

所述工作流管理模块通过工作流对组件服务的执行顺序进行定义、监控和调用；

所述组件管理模块作为车间调度系统中组件即插即生产的基本模块，完成组件的动态注册与删除；

所述模型仓库用于领域模型、语义模型和应用模型的存储和展示；

服务资源目录存在组件管理模块中，所述工作流管理模块向组件管理模块发出请求，获得服务资源目录，并依据流程定义进行资源匹配，将业务流程中的各活动分配到服务资源，执行工作流并监控执行过程；

当工作流管理模块进行服务调用时，根据服务的基本信息创建OPC UA的客户端对服务进行调用，触发适配器中OPC UA服务器的变量和方法节点，以响应服务功能需求。

作为优选的技术方案，所述依据流程定义进行资源匹配，具体包括：

所述服务资源目录保存了所有服务节点的工作状态和服务描述，新加入的服务节点注册到组件管理模块，服务目录实时更新；

所述工作流管理模块向组件管理模块发出请求，组件管理模块将更新后的服务资源目录与业务流程中定义的组织或角色进行匹配，并将匹配的结果信息反馈给工作流系统。

作为优选的技术方案，所述将业务流程中的各活动分配到服务资源，具体包括：

工作流创建后，生成工作流规范，工作流规范包括分解工作流生成的活动定义、活动间的执行顺序以及活动的约束信息；

工作流管理模块依据活动相互之间的约束关系生成任务列表，按顺序分配到相应的服务资源上。

作为优选的技术方案，所述执行工作流并监控执行过程，具体包括：

在工作流开始执行时，工作流管理模块检查活动所需的服务资源在任务执行前是否已经被传送到了服务节点上，实时监控工作流执行的过程，监督工作流任务之间的相互依赖关系是否被破坏，以及工作流服务质量是否能被满足，同时进行异常处理和错误恢复，将各服务节点传输的数据收集存入弹性堆栈进行数据管理。

作为优选的技术方案，所述工作流管理模块包括：自动流程建模工具、工作流引擎、任务列表管理器、监控界面、用户界面；

自动流程建模工具根据流程建模的元模型，生成流程模型的可视化界面，所述流程建模元模型设定了一组初始基本对象类型，通过设定的扩展或通过定义同级别的附加功能确定更多的对象类型；

自动流程建模工具根据产品信息模型自动生成业务流程模型，以及工作流控制数据；

流程建模采用了组织或角色模型指定服务，流程建模时，活动与相关的组织实体和角色功能对应，工作流引擎将组织实体或角色功能与运行时环境内的特定服务参与者进行联系；

工作流引擎解释用户建立的业务流程模型并控制流程的实例化和活动的顺序，将活动添加到工作列表中，并调用对应的应用程序服务；

工作流引擎根据用户建立的流程定义模型，控制流程中各个活动步骤的导航，提供有关单个活动步骤的进入和退出标准、不同活动的并行或顺序执行选项的信息、与每个活动相关的软件和硬件资源服务；

在流程执行过程中，工作流引擎解析流程定义模型时将活动放置到工作列表上，传输至任务列表管理器处理；

任务列表管理器处理工作流引擎与工作流参与者的交互，将任务列表对不同权限的参与者开放，还控制用户之间的工作分配，以及支持工作流引擎与服务参与者进行交互；

用户界面用于生成用户对话的外观，控制与用户联系的本地界面，用户界面与工作列表管理器组合使用，与多个不同的工作流引擎进行交互，使来自不同工作流引擎的任务整合到一个统一的任务列表中；

管理员界面基于工作流引擎监督权限的支持，为整个工作流系统提供监督功能，与分布式的多个工作流引擎进行交互，提供统一的管理界面，对多个工作流引擎进行批量操作，以及控制活动在不同工作流引擎之间进行切换。

作为优选的技术方案，所述工作流引擎设置了统一服务接口，调用活动所需的服务，并接收服务运行时或完成后的反馈；

作为优选的技术方案，所述工作流引擎还用于维护分布在工作流引擎中的内部控制数据，包括与正在执行的各种流程和活动实例相关联的内部状态信息，以及工作流引擎用于协调和从故障状态中恢复的检查点和恢复重启信息。

一种面向智能生产线的云制造架构，其特征在于，设有上述面向智能生产线的制造中间件，还包括资产组件、产品组件和软件工具组件，所述资产组件、产品组件和软件工具组件均以适配器的方式进行管理，在各类型适配器中均设有服务注册与发现模块；

在组件进入智能生产线系统时，组件管理模块对组件进行发现并注册到组件管理表中，在组件退出车间调度系统时，组件管理模块删除组件管理表中的相应信息；

组件管理模块维护组件管理表，定时轮询每个组件的健康状态，包括检查组件的程序运行状态、网络状态和传感器状态；

当需要使用一个组件时，若存在其他健康的组件，组件管理模块会将把任务请求转为调用另一个相同类型的组件，当组件出现异常时，组件管理模块将调动提供相同功能的其他组件完成生产任务；

在资产组件进入产线的时刻，适配器分别向模型仓库和组件管理模块发送信息模型和组件的基本服务信息；

所述信息模型以AML领域模型的形式存储在模型仓库中，适配器根据资产的AML模型，生成资产的OPC UA服务；

在服务注册之前，适配器向组件管理模块提供组件的基本服务信息，包括服务GUID、服务名称、服务IP和端口和服务粒度；

当组件的服务注册开始时，适配器将信息模型转换为与组件通信协议匹配的信息实例；

在生产执行过程中，制造中间件还通过组件管理模块对组件服务进行周期性的健康检查，以获取组件的在线或离线状态。

作为优选的技术方案，所述模型仓库采用去中心化的无共享架构，对象数据被存放在不同节点，对外提供统一命名空间访问，并通过负载均衡或者DNS轮询在各个服务器之间实现负载均衡。

作为优选的技术方案，所述模型仓库进行分布式锁管理以控制数据一致性，具体包括：

节点产生锁请求时，以广播的形式通知集群内的所有健康的数据存储服务器；

如果超过半数的数据存储服务器同意该锁请求，则获取数据锁成功；

每个数据存储服务器都是平等的，互相之间检测当前服务器的状态以及锁的持有情况。

本发明与现有技术相比，具有如下优点和有益效果：

(1)本发明将云计算三层架构应用到制造领域，能实现资产的服务化，能实现对可配置资产，如制造相关的软件工具、硬件资源等的共享，能实现根据实际使用场景对资产的按需使用。

(2)本发明中制造中间件提供了资产的敏捷部署的方法，使资产能快速部署并集成到制造系统，并通过工作流管理模块使其可以被快速组合生产。

(3)本发明中云制造架构能实现服务的动态管理，负载均衡并分配制造资源。

附图说明

图1为本发明智能生产线的运行管控的流程示意图；

图2为本发明资产组件服务接入和调用过程的流程示意图；

图3为本发明工作流管理模块与组件管理模块交互的流程示意图；

图4为本发明工作流管理模块的架构示意图；

图5为本发明流程建模元模型ER示意图；

图6为本发明组件管理模块架构示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

如图1所示，智能生产线的运行管控流程为：

客户在订单界面提交个性化需求订单，经订单解析工具实现产品工艺的分解以及工艺特征描述；生产前，先通过计算仿真工具对订单需求进行生产线的功能与性能的分析验证；通过仿真验证后，经资源调度工具实现对计划生产任务的资源指派，系统下发相关的资源指令；资源接受指令后开始加工并将过程数据上传至系统，资源调度工具根据生产异常对生产计划进行更新和再调整。

基于上述智能生产线的运行管控流程，本实施例提供一种面向智能生产线的云制造架构，包括资产、制造中间件和应用三个层次，分别对应于云计算架构中的IaaS、PaaS和SaaS；

在本实施例中，资产为各生产要素的集合，根据生产要素存在形式的类型，资产分为2种：硬件资产和软件资产。硬件资产主要包括制造资源(如设备、工作站等)或产品等物理生产要素，软件资产主要包括软件形式的生产工具。每个资产都有其AutomationML模型描述。所有资产都能通过适配器连接到制造中间件，同样地，对应于生产要素的不同，适配器分成资源适配器、产品适配器、软件适配器。

在本实施例中，制造中间件在每个资产组件内实现统一的通信层，从而获得通用的通信基础结构，这包括标准化的通信协议，中间件存储和操作数据的能力，不同数据格式之间的转换等，以确保不同的资产组件以正确的方式解析得到的传输信息。此外，中间件还可以使用多粒度和松耦合的服务来构建满足个性化需求的应用场景，通过不同种类组件的服务化集成，使制造系统得以敏捷方式动态部署，有需求预测、产品本体分析、工艺匹配等等的服务，服务都注册到组件管理模块，然后可以通过中间件的工作流管理模块串起来，组成一个大粒度的规划调度服务。制造中间件将统一集成生产线设计和运行生命周期内的大量异构组件，构建不同种类、不同粒度组件的服务，在此基础上部署中间件的各功能模块以验证智能生产线在设计时的数字仿真验证、运行时的数字模型同步、资源动态变化时的持续集成到部署，以及提供预测性维护等工厂全生命周期中作为数字基础设施的效果。制造中间件包括工作流管理模块、组件管理模块和模型仓库。工作流管理模块的功能是通过工作流对组件服务的执行顺序进行定义、监控和调用；组件管理模块是实现车间调度系统中组件即插即生产的基本模块，负责组件的动态注册与删除；模型仓库负责领域模型、语义模型和应用模型的存储和展示。在制造中间件中的工作流管理模块、组件管理模块和模型仓库共同作用下，实现了对服务的集中化操作管理，使得制造资源和计算资源适应无缝、稳定和高质量的交互要求。

在本实施例中，制造中间件在每个资产组件内实现统一的通信层，从而获得通用的通信基础结构，通信层使用gRPC作为统一的标准服务接口。gRPC是一个高性能、通用的开源RPC(Remote Procedure Call，远程过程调用)框架，其由Google主要面向移动应用开发，基于HTTP/2协议标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发，且支持众多开发语言。与许多RPC系统一样，gRPC基于定义服务的思想，能指定参数和返回类型进行远程调用，能快速地创建分布式应用程序和服务。在服务器端，运行着一个gRPC接口服务器来处理客户端调用，同时在客户端有一个桩(stub)，提供与服务器相同的请求与回应方法，

在默认情况下，gRPC使用谷歌协议缓冲区编码器(Google protocol bufferscompiler)来对gRPC交换的数据进行序列化。通信协议转换模块根据全局已定义proto文件，根据proto文件的格式标准发送和接收指令。proto文件包含着序列化的数据定义结构，在发送指令时，proto缓冲区数据会被构造为包含一系列信息的键值对的指令。相应地，在接收指令时也需要按照proto格式标准对不同的指令进行解析。

由于gPPC快速、易于使用、带宽高效、支持多语言、自动生成API代码等优秀特性，本实例中通信层选择了gRPC作为统一服务接口。

但目前还有很多其他的通信协议，比较常用的有Http，物联网方面常用的有MQTT，本实例中通信层支持这两种协议的互相转换。gRPC驱动接口用于连接中间件的工作流管理模块，作为统一服务接口；HTTP驱动接口用于连接支持云服务的软件；MQTT驱动接口用于连接支持物联网相关协议的软件工具。

一般情况下，gRPC在收到消息后，会根据protobuf的缓冲区编码器来对消息进行编解码。然而，在通信协议转换模块的内部，其既需要作为server端接收指令，又需要作为client端发送指令。当接收到的指令为gRPC时，其指令在通信协议转换模块内部转发的时候，不需要对其进行任何形式的编解码，此时只需要一个对协议的无感知仅作转发的缓冲区编码器，对gRPC自带缓冲区编码器的解编码部分进行屏蔽即可；当接收到的指令为HTTP、MQTT时，其指令在通信协议转换模块内部转发的时候，则需要对指令重新解析成Proto请求，此时需要重新实现编码器。

由于HTTP与MQTT协议实现原理及方式的不同，在进行重编解码时，也对应着不同的实现方法。

在本实施例中，应用为一系列适用于个性化定制生产线运行管控的软件工具服务。这些软件工具通过具有较高通用性的计算、仿真、优化软件在制造系统的适配，可以满足个性化定制生产线的运行管控的要求。同时，应用与制造中间件具有良好的通用性，使得基于应用软件服务的集成和服务编排变得更加方便，具有非常好的扩展性。在产品的业务流程模型中，包含了订单处理、计算仿真、资源调度、运行监控等功能组件。

如图2所示，在资产组件接入制造中间件的过程，在资产组件进入产线的时刻，适配器分别向模型仓库和组件管理模块发送信息模型和组件的基本服务信息。信息模型以AML领域模型的形式存储在模型仓库中，适配器根据资产的AML模型，生成资产的OPC UA服务。在服务注册之前，适配器需要向组件管理模块提供组件的基本服务信息，包括服务GUID、服务名称、服务IP和端口、服务粒度等。当组件的服务注册开始时，适配器会将信息模型转换为适应组件通信协议的信息实例。在生产执行过程中，制造中间件还可通过组件管理模块对组件服务进行周期性的健康检查，以获取组件的在线/离线状态。

如图3所示，工作流管理模块与组件管理模块的交互运行过程，具体步骤包括：

(1)工作流管理模块获得服务资源目录，并依据流程定义进行资源匹配。

工作流在运行开始时需要获得服务资源目录，服务资源目录存在组件管理模块中，目录中保存了所有服务节点的工作状态和服务描述，新加入的服务节点都会注册到组件管理模块，服务目录实时更新。运行初期，工作流管理模块向组件管理模块发出请求，组件管理模块将更新后的服务资源目录与业务流程中定义的组织/角色进行匹配，并将匹配的结果信息反馈给工作流系统。

(2)将业务流程中的各活动分配到服务资源。

工作流创建后，会生成一系列工作流规范，规范中包含了分解工作流生成的活动定义、活动间的执行顺序以及活动的约束信息。工作流管理模块会将这些活动依据相互之间的约束关系生成具体的任务列表，最后按顺序分配到相应的服务资源上。

(3)执行工作流并监控执行过程。

在工作流开始执行时，工作流管理模块会检查活动所需的服务资源在任务执行前已经被传送到了服务节点上。工作流引擎也会实时监控工作流执行的过程，监督工作流任务之间的相互依赖关系是否被破坏，以及工作流服务质量是否能被满足，同时工作流管理模块还要进行异常处理和错误恢复。在监控工作流执行过程中，各服务之间会产生大量数据，包括用户订单产生的产品数据、设备和传感器产生的资源数据、应用运行过程中产生的日志数据、云服务器的监控数据等。这些数据对于车间调度、预测维护、软件工具更新迭代等场景十分重要，工作流管理模块则会将各服务节点传输的数据收集存入弹性堆栈进行数据管理，同时数据也能被管理人员或软件工具调用以便分析数据。

资源服务与资产的交互运行过程如下：

当工作流管理模块需要进行服务调用时，根据服务的基本信息创建OPC UA的客户端对服务进行调用，触发适配器中OPC UA服务器的变量和方法节点，以响应服务功能需求。

在本实施例中，工作流管理模块用于定义服务的执行顺序、服务间的数据传输的内容、数据传输的起点和终点、事件执行顺序等。因此，数据存储、数据路由和事件管理均由工作流管理模块实现。工作流是对工作流程及其各操作步骤之间业务规则的抽象和概括描述，是针对业务流程活动而提出的概念，目的是根据将工作分解成定义良好的任务或角色，根据一定的原则和过程来实施并监控这些任务，达到提高效率、控制过程、增强有效管理业务流程等目的。

如图4所示，工作流管理模块的架构中，可以分成以下三种类型：

(1)工作流管理模块设有各种功能的软件组件，包括自动流程建模工具、工作流引擎、任务列表管理器、监控界面、用户界面；

(2)各种类型的模型定义和控制数据，包括过程定义、组织/角色模型数据、工作流控制数据、任务列表、工作流相关数据；

(3)工作流管理模块的操作对象，包括各应用程序和应用程序数据库；

在本实施例中，流程建模包含有关流程中所有必要的信息，使其能够由工作流引擎识别并执行。自动流程建模工具根据流程建模的元模型，给用户提供了简便生成流程模型的可视化界面，避免了用户进行流程建模时大量重复的工作，同时对用户建立的流程模型提供检验。流程建模元模型确定了一组初始基本对象类型，用户在建立流程建模模型时，可以通过特定的扩展或通过定义同级别的附加功能来确定更多的对象类型。

流程建模元模型包括：工作流类型定义、工作流的要执行的用户活动、活动的开始和完成条件、活动间导航的规则、可能需要引用的工作流相关数据、活动所引用的角色、可能被调用的应用程序等。

如图5所示，得到各部分ER关系，活动是流程建模元模型的主体，活动包含了转换条件，由工作流类型定义组成，涉及了角色/组织数据，在运行时使用到了工作流相关数据以及调用的应用程序。工作流类型定义和调用的应用程序同样会使用到工作流相关数据。

具体如下表1所示：

表1流程建模元模型各部分

在本实施例中，流程建模采用了组织/角色(Organisation/Role)模型来指定服务，组织/角色模型包含了有关组织结构和组织内的角色信息，通常表现形式为组织目录。这使得在流程建模时，活动可以与相关的组织实体和角色功能对应，而无需指定特定的参与者。在运行时，工作流引擎负责将组织实体或角色功能与运行时环境内的特定服务参与者联系起来。

流程建模工具常采用BPMN作为业务流程建模语言。BPMN提供了被所有业务用户容易理解的符号，从创建流程轮廓的业务分析到流程实现，在业务流程设计与流程实现之间搭建了一条标准化的桥梁。

与工作流管理联盟提供的工作流管理模块架构不同的是，因个性化产品定制的要求，流程建模工具需要根据产品信息模型自动生成业务流程模型，同时还包括相关的工作流控制数据。

在本实施例中，工作流引擎解释用户建立的业务流程模型并控制流程的实例化和活动的顺序，将活动添加到工作列表中，并根据需要调用相应的应用程序服务。工作流引擎部分可以通过一个或多个分布式工作流管理引擎合作实现的，每个工作流引擎管理各业务流程的单个实例的执行。

工作流引擎根据用户建立的流程定义模型，控制流程中各个活动步骤的导航，提供有关单个活动步骤的进入和退出标准、不同活动的并行或顺序执行选项的信息、与每个活动相关的软件和硬件资源服务等。如果流程定义包括与这些服务类型相关的结构，则可能需要访问组织/角色数据。因此，工作流引擎包括了统一服务接口，调用活动所需的特定服务，并接收服务运行时或完成后的反馈。

工作流引擎还负责维护分布在工作流引擎中的内部控制数据，包括与正在执行的各种流程和活动实例相关联的内部状态信息，还可能包括工作流引擎用于协调和从故障状态中恢复的检查点和恢复重启信息。

在本实施例中，在流程执行过程中，工作流引擎解析流程定义模型时会将活动放置到工作列表上，交给任务列表管理器处理。任务列表管理器负责处理工作流引擎与工作流参与者的交互。任务列表管理器可以选择将任务列表对不同权限的参与者开放，对于一般用户，只有查看任务列表的权限，任务列表将按顺序显示下一个要执行的任务，并查看任务完成情况；对于管理员，则有权限从任务列表中选择某个活动独立执行。

任务列表管理器，可以只是一个工作流引擎执行结果的接收器、存储器，并把结果通知到各服务以等待执行。除了简单的接收功能之外，任务列表管理器还能控制一组用户之间的工作分配，以提供负载平衡和工作重新分配等功能，同时还支持工作流引擎与更广泛的服务参与者进行交互，包括特定用户服务的登录和注销，用户请求特定的服务执行者，对用户请求优先级做出改变(比如插单)等。

在本实施例中，用户界面负责与用户对话的外观，并控制与用户联系的本地界面。与任务列表管理器不同，用户界面不受工作流引擎的直接控制，对工作流引擎不可见。

用户界面与工作列表管理器组合使用，用户界面与多个不同的工作流引擎进行交互，从而使来自不同工作流引擎的任务能够整合到一个统一的任务列表中，以便通过公共用户演示。用户界面还可以集成本地的其他应用程序服务，支持产品工作流执行所必须的其他功能，比如订单处理的功能。

在本实施例中，管理员界面基于工作流引擎监督权限的支持，为整个工作流系统提供许多监督功能。比如使工作流引擎更改任务分配规则，指定流程中特定组织角色的参与者，跟踪延误截止日期或其他事件的警报，跟踪特定流程实例的历史情况，查询工作吞吐量或其他统计数据等。

在本实施例中，同用户管理界面，管理员界面还能与分布式的多个工作流引擎进行交互，提供统一的管理界面，对多个工作流引擎进行批量操作，以及控制活动在不同工作流引擎之间进行切换。

在本实施例中，云制造架构中有资产组件、产品组件和软件工具组件，所有这些组件都以资源适配器、产品适配器、软件适配器的方式进行管理，在各类型适配器中，均包含了服务注册与发现模块。服务注册与发现模块在每个组件中运行一个代理(Agent)，与组件管理模块相连。

在本实施例中，组件管理模块是实现即插即生产的基本模块，可对资产组件进行动态注册与删除。在组件进入智能生产线系统时，组件管理模块对组件进行发现并注册到组件管理表中。在组件退出车间调度系统时，组件管理模块删除组件管理表中的相应信息。

此外，组件管理还需维护组件管理表，组件管理模块会定时轮询每个组件的健康状态，包括检查组件的程序运行状态、网络状态、传感器状态等。当需要使用一个组件时，如果存在其他健康的组件，组件管理模块会将把此类任务请求转为调用另一个相同类型的组件。如当资产组件出现异常时(如通过资源主动维护功能获取)，组件管理模块将自动调动提供相同功能的其他组件来完成生产任务，从而实现车间不停机切换组件生产。

组件管理模块可以由多个数据中心组成，各个数据中心数据分别管理、数据共享，共同组成服务注册与发现中心。组件管理模块架构参考Consul架构，如图6所示，以两个数据中心为例说明，分别为“数据中心1”和“数据中心2”。在每个数据中心内，都有服务器(Server)和客户端(Client)的混合，随着服务器的增加，数据中心获取“共识”(Consensus)的速度会变慢，而客户端的数量没有影响。因此，在权衡故障场景下的可用性和性能两者后，每个数据中心理想的Server数为3～5个。

在同一数据中心内，所有的节点都会参加闲聊协议(gossip protocol)，换言之，就是每个数据都有1个闲聊池(Gossip Pool)，里面包含了该数据中心内的所有代理(Agent)。以数据中心为单位进行管理的好处有以下3点：

(1)各适配器的服务注册与发现模块不需要额外配置服务器的地址，只要组件在该数据中心内，便能自动发现。

(2)检测代理故障的工作是分布式的，不必全在服务器端检测，这比集中式的心跳检测可靠且效率更高。同理，若组件的代理无法到达服务器，那么该组件节点可能已经发生了故障。

(3)数据中心作为整体对组件管理模块发出消息，如领导者(Leader)选举成功时。

每个数据中心的各服务器共同选出一个领导，负责处理所有查询和事务。领导收到RPC请求后，将该请求复制到所有参与共识协议的其他节点执行。而随从(Follower)收到RPC请求后，需将请求转发给领导者。

针对互联网的较高延迟现状，在各自的数据中心中，都是通过局域网(LAN)建立闲聊池，这样在同一数据中心内的各组件能更快地发现彼此。

在数据中心之间，通过广域网(WAN)建立闲聊池，所有数据中心的所有服务器都在广域网闲聊池里，因此不同数据中心的服务器均可以实现跨数据中心的请求。在广域网闲聊池里，当某个服务器收到来自不同数据中心的请求后，会将请求转发给本地领导者，然后由领导者再转发给正确的数据中心。

一般情况下，不同的数据中心之间不会复制请求。当对另一个数据中心的节点进行请求时，本地服务器会将该RPC请求转发给远程服务器，并返回结果。如果远程数据中心不可用，那么这些资源也不可用，但这不会影响本地数据中心。在一些特殊情况下，可以复制有限的数据子集，比如客户端的代理可能会从服务器上缓存数据，使其在本地可用，以提高性能和可靠性，即使与服务器的连接中断或服务器暂时不可用，本地Agent仍然可以继续从缓存中响应一些查询，如服务发现或连接授权。

因此，数据中心之间的耦合度很低，能应对故障检测、连接缓存复用、跨数据中心请求等情况，相对快速可靠。

在智能生产线全生命周期中，涉及到许多不同领域的模型。模型仓库可以对领域模型、语义模型和应用模型进行存储和展示，其支持多种文本格式，如AML、Json、OWL、CPN、XML等格式。除存储外，还能对各种类型的文本通过Web服务的形式进行文本展示。

模型仓库采用去中心化的无共享架构，对象数据被存放在不同节点的多块硬盘，对外提供统一命名空间访问，并通过负载均衡或者DNS轮询在各个服务器之间实现负载均衡。因为没有特殊的节点，所以任何节点的损坏都不会影响整个集群节点之间的通信。

与分布式数据库类似，模型仓库同样面临着数据一致性的问题，当一个客户端在读取一个对象的同时，另一个客户端可能正在修改或者删除这个对象。为了避免出现数据不一致的情况，还需要实现分布式锁管理以控制数据一致性。分布式锁管理的实现方法如下：

任何节点产生锁请求时，都以广播的形式通知集群内的所有健康的数据存储服务器；

如果超过半数的数据存储服务器同意该锁请求，则获取数据锁成功；

每个数据存储服务器都是平等的，互相之间检测当前服务器的状态以及锁的持有情况。

对于每个数据存储服务器，保证数据的安全性是非常必要的，模型仓库采用纠删码erasure code和checksum来保护数据免受硬件故障和数据损耗，即使丢失一半数量的存储块，仍然可以恢复数据。

在本实施例中，具体介绍制造中间件的具体实施方式，其制造中间件的实施也只是为了更好地说明，而非限制制造中间件的实施。

在云服务器中，部署了Kubernetes，Kubernetes提供了构建制造中间件的基础。因此，在Kubernetes之上安装其他模块来共同实现制造中间件系统。

制造中间件的模型仓库、工作流管理模块和组件管理模块，均采用第三方工具。Helm是Kubernetes的包管理工具。第三方工具大多提供了Helm包，可以在Helm的应用中心搜索这些第三方包，并使用Helm直接安装到Kubernetes。

工作流管理模块的部署：Zeebe是微服务编排的免费开源工作流引擎。它提供了生产线端到端工作流程状态的可见性，包括运行中工作流程的数量、平均工作流程持续时间、工作流程中的当前错误等。

Zeebe是为数不多采用微服务架构的工作流引擎，由于使用了跨语言通用的RPC协议，使得Zeebe可以用不同语言编写、运行在不同环境的各个组件。Zeebe采用了标准的业务流程模型BPMN 2.0，能够直观地定义流程。

Zeebe使用Docker和Kubernetes进行部署，能够构建对来自Kafka和其他消息队列的消息做出反应的进程，能进行水平扩展以处理非常高的吞吐量，而且不依赖关系数据库。

Zeebe采用ElasticSearch作为运行时的数据搜索和分析引擎，Elasticsearch也可看作工作流控制数据数据库。Zeebe在运行时，会通过数据导出器将运行日志以JSON的格式输入到Elasticsearch中。每个JSON文件都会在一组键(字段或属性的名称)和它们对应的值(字符串、数字、布尔值、日期等类型的数据)之间建立联系。

可以使用Kubernetes的包管理器Helm来安装Zeebe。可以通过配置Helm的安装值参数来控制Zeebe的安装配置，如服务器副本数目。Zeebe使用ElasticSearch作为搜索引擎(也可看作存储工作流运行数据的数据库)，使用Helm时也会一并安装。

组件管理模块的部署：制造中间件的组件管理模块是基于服务网格Consul实现。Consul是一种服务网格解决方案，特征是分布式的、高可用的、可横向拓展的用于实现分布式系统的服务发现和配置，可实现组件和服务的注册、发现等功能，可统一查询服务IP地址、端口，查询服务运行情况、响应速度等。为了将所有节点的内容集成到这个网格中，需要在信息物理系统中的所有节点，包括边缘处理单元和云服务器，包括资源节点到产品节点，全部加入到Consul的服务网格中，这就要求在所有节点上安装Consul代理。另外，Consul还需要一个数据平面，它支持代理和本机集成模型。由于Consul附带了一个简单的内置代理，因此一切都可以直接使用。

Consul支持使用Helm安装。默认情况下，安装到Kubernetes的应用能够将服务自动注册到Consul中，Consul在集群子网内提供服务发现功能。由于需要将服务暴露给集群外部，可以在Kubernetes之外安装独立的Consul程序，并组建成另一个数据中心，与集群内部的Consul服务器连接，共同提供服务发现功能。由于集群内和集群外不在同一个子网段，需要分别在集群内和集群外安装Consul，并配置为不同的数据中心。两个数据中心都需要在同一个节点上安装服务器，并通过这种方式将两个不同的数据中心连接起来，形成一个服务网格。

模型仓库的部署：模型仓库由MinIO提供。同样，MinIO使用Helm安装的Kubernetes上。MinIO提供高性能、S3兼容的对象存储。MinIO原生于Kubernetes，是唯一可用于每个公共云、每个Kubernetes发行版、私有云和边缘的对象存储套件。MinIO在最大数量的环境中支持最广泛的用例。MinIO可以提供一系列用例，包括AI/ML、分析、备份/恢复以及现代Web和移动应用程序。

MinIO是为云的技术和架构而生的，其中包括容器化、Kubernetes编排、微服务和多租户。MinIO几乎是用于Kubernetes的对象存储服务的唯一选择。另外，MinIO是世界上最快的对象存储服务器。凭借标准硬件上183GB/s和171GB/s的读/写速度，对象存储可以作为主要存储层运行，适用于各种工作负载。其部署的多样性以专有软件永远无法提供的方式强化了软件，因此，MinIO非常适合制造企业。

MinIO适合大规模存储非结构化的数据，例如图片、视频、日志文件、备份数据等，而且非常轻量。选用的模型对象存储服务MinIO满足以下特征：1)使用抹除编码，可将模型对象划分为带有可配置冗余级别的数据和校验块，分布式地存储到不同硬盘上。读取模型对象时，可由这些分布式存储的数据重建出完整模型。由于纠删码带有冗余和校验机制，在数据部分丢失的情况下，只要丢失数据量不超过配置的冗余级别，模型就能被完整重建。2)实时错误检测和恢复。模型是个性化制造系统的基础，即使硬盘严格保存，模型的数据仍有可能在意外情况下被破坏。为了保证数据稳定性，应采用哈希算法进行数据校验。在检测到错误数据的时候，可以通过纠删码所提供的其他数据快速地恢复错误数据区块。

上述实施例为本发明较佳的实施方式，但本发明的实施方式并不受上述实施例的限制，其他的任何未背离本发明的精神实质与原理下所作的改变、修饰、替代、组合、简化，均应为等效的置换方式，都包含在本发明的保护范围之内。

Claims (10)

1.一种面向智能生产线的制造中间件，其特征在于，包括：工作流管理模块、组件管理模块和模型仓库；

所述工作流管理模块通过工作流对组件服务的执行顺序进行定义、监控和调用；

所述组件管理模块作为车间调度系统中组件即插即生产的基本模块，完成组件的动态注册与删除；

所述模型仓库用于领域模型、语义模型和应用模型的存储和展示；

服务资源目录存在组件管理模块中，所述工作流管理模块向组件管理模块发出请求，获得服务资源目录，并依据流程定义进行资源匹配，将业务流程中的各活动分配到服务资源，执行工作流并监控执行过程；

当工作流管理模块进行服务调用时，根据服务的基本信息创建OPC UA的客户端对服务进行调用，触发适配器中OPC UA服务器的变量和方法节点，以响应服务功能需求。

2.根据权利要求1所述的面向智能生产线的制造中间件，其特征在于，所述依据流程定义进行资源匹配，具体包括：

所述服务资源目录保存了所有服务节点的工作状态和服务描述，新加入的服务节点注册到组件管理模块，服务目录实时更新；

所述工作流管理模块向组件管理模块发出请求，组件管理模块将更新后的服务资源目录与业务流程中定义的组织或角色进行匹配，并将匹配的结果信息反馈给工作流系统。

3.根据权利要求1所述的面向智能生产线的制造中间件，其特征在于，所述将业务流程中的各活动分配到服务资源，具体包括：

工作流创建后，生成工作流规范，工作流规范包括分解工作流生成的活动定义、活动间的执行顺序以及活动的约束信息；

工作流管理模块依据活动相互之间的约束关系生成任务列表，按顺序分配到相应的服务资源上。

4.根据权利要求1所述的面向智能生产线的制造中间件，其特征在于，所述执行工作流并监控执行过程，具体包括：

在工作流开始执行时，工作流管理模块检查活动所需的服务资源在任务执行前是否已经被传送到了服务节点上，实时监控工作流执行的过程，监督工作流任务之间的相互依赖关系是否被破坏，以及工作流服务质量是否能被满足，同时进行异常处理和错误恢复，将各服务节点传输的数据收集存入弹性堆栈进行数据管理。

5.根据权利要求1所述的面向智能生产线的制造中间件，其特征在于，所述工作流管理模块包括：自动流程建模工具、工作流引擎、任务列表管理器、监控界面、用户界面；

自动流程建模工具根据流程建模的元模型，生成流程模型的可视化界面，所述流程建模元模型设定了一组初始基本对象类型，通过设定的扩展或通过定义同级别的附加功能确定更多的对象类型；

自动流程建模工具根据产品信息模型自动生成业务流程模型，以及工作流控制数据；

流程建模采用了组织或角色模型指定服务，流程建模时，活动与相关的组织实体和角色功能对应，工作流引擎将组织实体或角色功能与运行时环境内的特定服务参与者进行联系；

工作流引擎解释用户建立的业务流程模型并控制流程的实例化和活动的顺序，将活动添加到工作列表中，并调用对应的应用程序服务；

工作流引擎根据用户建立的流程定义模型，控制流程中各个活动步骤的导航，提供有关单个活动步骤的进入和退出标准、不同活动的并行或顺序执行选项的信息、与每个活动相关的软件和硬件资源服务；

在流程执行过程中，工作流引擎解析流程定义模型时将活动放置到工作列表上，传输至任务列表管理器处理；

任务列表管理器处理工作流引擎与工作流参与者的交互，将任务列表对不同权限的参与者开放，还控制用户之间的工作分配，以及支持工作流引擎与服务参与者进行交互；

用户界面用于生成用户对话的外观，控制与用户联系的本地界面，用户界面与工作列表管理器组合使用，与多个不同的工作流引擎进行交互，使来自不同工作流引擎的任务整合到一个统一的任务列表中；

管理员界面基于工作流引擎监督权限的支持，为整个工作流系统提供监督功能，与分布式的多个工作流引擎进行交互，提供统一的管理界面，对多个工作流引擎进行批量操作，以及控制活动在不同工作流引擎之间进行切换。

6.根据权利要求5所述的面向智能生产线的制造中间件，其特征在于，所述工作流引擎设置了统一服务接口，调用活动所需的服务，并接收服务运行时或完成后的反馈。

7.根据权利要求5所述的面向智能生产线的制造中间件，其特征在于，所述工作流引擎还用于维护分布在工作流引擎中的内部控制数据，包括与正在执行的各种流程和活动实例相关联的内部状态信息，以及工作流引擎用于协调和从故障状态中恢复的检查点和恢复重启信息。

8.一种面向智能生产线的云制造架构，其特征在于，设有权利要求1-7任一项所述的面向智能生产线的制造中间件，还包括资产组件、产品组件和软件工具组件，所述资产组件、产品组件和软件工具组件均以适配器的方式进行管理，在各类型适配器中均设有服务注册与发现模块；

在组件进入智能生产线系统时，组件管理模块对组件进行发现并注册到组件管理表中，在组件退出车间调度系统时，组件管理模块删除组件管理表中的相应信息；

组件管理模块维护组件管理表，定时轮询每个组件的健康状态，包括检查组件的程序运行状态、网络状态和传感器状态；

当需要使用一个组件时，若存在其他健康的组件，组件管理模块会将把任务请求转为调用另一个相同类型的组件，当组件出现异常时，组件管理模块将调动提供相同功能的其他组件完成生产任务；

在资产组件进入产线的时刻，适配器分别向模型仓库和组件管理模块发送信息模型和组件的基本服务信息；

所述信息模型以AML领域模型的形式存储在模型仓库中，适配器根据资产的AML模型，生成资产的OPC UA服务；

在服务注册之前，适配器向组件管理模块提供组件的基本服务信息，包括服务GUID、服务名称、服务IP和端口和服务粒度；

当组件的服务注册开始时，适配器将信息模型转换为与组件通信协议匹配的信息实例；

在生产执行过程中，制造中间件还通过组件管理模块对组件服务进行周期性的健康检查，以获取组件的在线或离线状态。

9.根据权利要求8所述的面向智能生产线的云制造架构，其特征在于，所述模型仓库采用去中心化的无共享架构，对象数据被存放在不同节点，对外提供统一命名空间访问，并通过负载均衡或者DNS轮询在各个服务器之间实现负载均衡。

10.根据权利要求8所述的面向智能生产线的云制造架构，其特征在于，所述模型仓库进行分布式锁管理以控制数据一致性，具体包括：

节点产生锁请求时，以广播的形式通知集群内的所有健康的数据存储服务器；

如果超过半数的数据存储服务器同意该锁请求，则获取数据锁成功；

每个数据存储服务器都是平等的，互相之间检测当前服务器的状态以及锁的持有情况。

Images