A manufacturing middleware device and cloud manufacturing architecture system for intelligent production lines

Abstract

The present invention discloses a manufacturing middleware device and a cloud manufacturing architecture system for intelligent production lines, wherein the manufacturing middleware device includes a workflow management module, a component management module and a model warehouse; the workflow management module defines, monitors and calls the execution order of component services through workflows; the component management module completes the dynamic registration and deletion of components; the model warehouse is used for the storage and display of domain models, semantic models and application models; the workflow management module obtains a service resource directory, matches resources according to process definitions, allocates each activity in a business process to service resources, executes workflows and monitors the execution process; the workflow management module creates an OPC UA client to call the service according to the basic information of the service, and triggers the variables and method nodes of the OPC UA server in the adapter. The present invention provides an agile deployment method for assets, so that assets can be quickly deployed and integrated into a manufacturing system, and can be quickly combined for production through the workflow management module.

Description

Technical Field

[0001] The present invention relates to the field of cloud manufacturing technology, and in particular to a manufacturing middleware device and a cloud manufacturing architecture system for an intelligent production line. Background Art

[0002] Networked manufacturing refers to a production model that integrates distributed resources to undertake manufacturing tasks, and services are considered to be an effective way to solve the distributed architecture in networked manufacturing, and cloud computing is an intelligent technology for service-oriented architecture. In cloud computing, everything is treated as a service (i.e., XaaS), which defines a hierarchical system structure for cloud computing, namely IaaS (Infrastructure as a Service), PaaS (Platform as a Service), and SaaS (Software as a Service). In the infrastructure layer IaaS, computing power, storage space, network services, and other basic infrastructure resources are defined as standardized services, on which cloud providers' customers can deploy and run operating systems and software. The middle layer PaaS provides abstractions and services for developing, testing, deploying, hosting, and maintaining applications in an integrated development environment. The application layer SaaS provides a complete set of software applications.

[0003] Similar to cloud computing, the three service modes in cloud manufacturing are IaaS, PaaS and SaaS. PaaS hides the component interactions and dynamic management of services involved in the service, and only provides a higher-dimensional and easy-to-use visual human-computer interaction interface and a low-code development platform. Developers only need to perform graphical programming and parameter configuration of manufacturing resources to form specific production scenario applications. In the cyber-physical system, PaaS, as a common interface between various subsystems, is crucial for the connection between various production factors. It can receive and convert data from each component and forward it to other components.

[0004] However, networked manufacturing currently lacks centralized operational management of services, making it difficult for manufacturing resources and computing resources to adapt to the requirements of seamless, stable and high-quality interaction. Secondly, in the traditional service distributed manufacturing environment, there is almost no coordination management between service providers and service demanders. Summary of the invention

[0005] In order to overcome the defects and shortcomings of the prior art, the present invention provides a manufacturing middleware device and a cloud manufacturing architecture system for intelligent production lines. The manufacturing middleware device of the present invention provides an agile deployment method for assets, so that assets can be quickly deployed and integrated into the manufacturing system, and can be quickly combined for production through a workflow management module.

[0006] In order to achieve the above object, the present invention adopts the following technical solutions:

[0007] A manufacturing middleware device for intelligent production lines, comprising: a workflow management module, a component management module and a model warehouse;

[0008] The workflow management module defines, monitors and calls the execution order of component services through workflow;

[0009] The component management module is a basic module for plug-and-play production of components in the workshop scheduling system, and completes dynamic registration and deletion of components;

[0010] The model warehouse is used to store and display domain models, semantic models and application models;

[0011] The service resource directory is stored in the component management module. The workflow management module sends a request to the component management module to obtain the service resource directory, matches resources according to the process definition, allocates each activity in the business process to the service resource, executes the workflow and monitors the execution process;

[0012] When the workflow management module makes a service call, it creates an OPC UA client based on the basic information of the service to call the service, triggering the variables and method nodes of the OPC UA server in the adapter to respond to the service function requirements.

[0013] As a preferred technical solution, resource matching based on process definition specifically includes:

[0014] The service resource directory stores the working status and service description of all service nodes. Newly added service nodes are registered with the component management module, and the service directory is updated in real time.

[0015] The workflow management module sends a request to the component management module, and the component management module matches the updated service resource directory with the organization or role defined in the business process, and feeds back the matching result information to the workflow system.

[0016] As a preferred technical solution, the allocation of each activity in the business process to the service resources specifically includes:

[0017] After the workflow is created, a workflow specification is generated. The workflow specification includes the activity definition generated by the decomposed workflow, the execution order between activities, and the constraint information of the activities;

[0018] The workflow management module generates a task list based on the constraints between activities and distributes them to the corresponding service resources in sequence.

[0019] As a preferred technical solution, the execution workflow and monitoring the execution process specifically include:

[0020] When the workflow starts executing, the workflow management module checks whether the service resources required for the activity have been transmitted to the service node before the task is executed. It monitors the workflow execution process in real time, supervises whether the interdependencies between workflow tasks are destroyed, and whether the workflow service quality can be met. At the same time, it performs exception handling and error recovery, and collects and stores the data transmitted by each service node into the elastic stack for data management.

[0021] As a preferred technical solution, the workflow management module includes: automatic process modeling tool, workflow engine, task list manager, monitoring interface, user interface;

[0022] The automatic process modeling tool generates a visual interface of the process model based on a metamodel of process modeling, wherein the process modeling metamodel sets a set of initial basic object types and determines more object types through set extensions or by defining additional functions at the same level;

[0023] The automatic process modeling tool automatically generates business process models and workflow control data based on the product information model;

[0024] Process modeling uses an organization or role model to specify services. When modeling processes, activities correspond to related organization entities and role functions. The workflow engine connects organization entities or role functions with specific service participants in the runtime environment.

[0025] The workflow engine interprets the business process model established by the user and controls the instantiation of the process and the sequence of activities, adds activities to the work list, and calls the corresponding application services;

[0026] The workflow engine controls the navigation of the individual activity steps in the process according to the process definition model established by the user, provides information about the entry and exit criteria of the individual activity steps, the options for parallel or sequential execution of different activities, and the software and hardware resource services associated with each activity;

[0027] During the process execution, the workflow engine parses the process definition model and places the activities on the work list, which is then transferred to the task list manager for processing;

[0028] The task list manager handles the interaction between the workflow engine and workflow participants, opens the task list to participants with different permissions, controls the distribution of work between users, and supports the interaction between the workflow engine and service participants;

[0029] The user interface is used to generate the appearance of the user dialogue and control the local interface for contacting the user. The user interface is used in combination with the work list manager to interact with multiple different workflow engines and integrate the tasks from different workflow engines into a unified task list;

[0030] The administrator interface supports workflow engine supervision permissions, provides supervision functions for the entire workflow system, interacts with multiple distributed workflow engines, provides a unified management interface, performs batch operations on multiple workflow engines, and controls activities to switch between different workflow engines.

[0031] As a preferred technical solution, the workflow engine sets a unified service interface to call the services required by the activity and receive feedback when the service is running or completed;

[0032] As a preferred technical solution, the workflow engine is also used to maintain internal control data distributed in the workflow engine, including internal state information associated with various processes and activity instances being executed, as well as checkpoint and recovery restart information used by the workflow engine to coordinate and recover from failure states.

[0033] A cloud manufacturing architecture system for intelligent production lines, provided with the above-mentioned manufacturing middleware device for intelligent production lines, further comprising asset components, product components and software tool components, wherein the asset components, product components and software tool components are all managed in the form of adapters, and service registration and discovery modules are provided in each type of adapter;

[0034] When a component enters the intelligent production line system, the component management module discovers the component and registers it in the component management table. When the component exits the workshop scheduling system, the component management module deletes the corresponding information in the component management table.

[0035] The component management module maintains the component management table and periodically polls the health status of each component, including checking the program running status, network status, and sensor status of the component;

[0036] When a component needs to be used, if there are other healthy components, the component management module will convert the task request to call another component of the same type. When a component fails, the component management module will mobilize other components that provide the same function to complete the production task.

[0037] When the asset component enters the production line, the adapter sends the information model and basic service information of the component to the model warehouse and component management module respectively;

[0038] The information model is stored in the model repository in the form of an AML domain model, and the adapter generates an OPC UA service for the asset based on the AML model of the asset;

[0039] Before service registration, the adapter provides the component management module with basic service information of the component, including service GUID, service name, service IP and port, and service granularity;

[0040] When the component's service registration begins, the adapter converts the information model into an information instance that matches the component's communication protocol;

[0041] During the production execution process, the manufacturing middleware also performs periodic health checks on component services through the component management module to obtain the online or offline status of the components.

[0042] As a preferred technical solution, the model warehouse adopts a decentralized shared-nothing architecture, object data is stored in different nodes, a unified namespace access is provided to the outside world, and load balancing is achieved among various servers through load balancing or DNS polling.

[0043] As a preferred technical solution, the model warehouse performs distributed lock management to control data consistency, specifically including:

[0044] When a node generates a lock request, it notifies all healthy data storage servers in the cluster in the form of broadcast;

[0045] If more than half of the data storage servers agree to the lock request, the data lock is acquired successfully;

[0046] Each data storage server is equal and detects the current server status and lock holding status of each other.

[0047] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0048] (1) The present invention applies the three-tier architecture of cloud computing to the manufacturing field, which can realize the service-oriented nature of assets, the sharing of configurable assets such as manufacturing-related software tools and hardware resources, and the on-demand use of assets according to actual usage scenarios.

[0049] (2) The manufacturing middleware in the present invention provides an agile deployment method for assets, so that assets can be quickly deployed and integrated into the manufacturing system, and can be quickly combined for production through the workflow management module.

[0050] (3) The cloud manufacturing architecture in the present invention can realize dynamic management of services, load balancing and allocation of manufacturing resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 It is a schematic diagram of the process of operation control of the intelligent production line of the present invention;

[0052] Figure 2 A flowchart of the asset component service access and call process of the present invention;

[0053] Figure 3 A schematic diagram of the flow of interaction between the workflow management module and the component management module of the present invention;

[0054] Figure 4 This is a schematic diagram of the architecture of the workflow management module of the present invention;

[0055] Figure 5 ER schematic diagram of the process modeling metamodel of the present invention;

[0056] Figure 6 Schematic diagram of the component management module architecture of the present invention. DETAILED DESCRIPTION

[0057] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0058] like Figure 1 As shown in the figure, the operation control process of the intelligent production line is as follows:

[0059] Customers submit personalized demand orders on the order interface, and the order analysis tool is used to decompose the product process and describe the process characteristics. Before production, the function and performance of the production line are analyzed and verified through calculation simulation tools. After simulation verification, the resource scheduling tool is used to assign resources to the planned production tasks, and the system issues relevant resource instructions. After receiving the instructions, the resources start processing and upload the process data to the system. The resource scheduling tool updates and readjusts the production plan according to production anomalies.

[0060] Based on the operation control process of the above-mentioned intelligent production line, this embodiment provides a cloud manufacturing architecture for intelligent production lines, including three levels: assets, manufacturing middleware and applications, which correspond to IaaS, PaaS and SaaS in the cloud computing architecture respectively;

[0061] In this embodiment, assets are a collection of various production factors. According to the type of production factor, assets are divided into two types: hardware assets and software assets. Hardware assets mainly include physical production factors such as manufacturing resources (such as equipment, workstations, etc.) or products, and software assets mainly include production tools in software form. Each asset has its AutomationML model description. All assets can be connected to manufacturing middleware through adapters. Similarly, corresponding to different production factors, adapters are divided into resource adapters, product adapters, and software adapters.

[0062] In this embodiment, the manufacturing middleware implements a unified communication layer in each asset component to obtain a common communication infrastructure, which includes standardized communication protocols, the ability of the middleware to store and operate data, conversion between different data formats, etc., to ensure that different asset components parse the transmission information obtained in the correct way. In addition, the middleware can also use multi-granularity and loosely coupled services to build application scenarios that meet personalized needs. Through the service-oriented integration of different types of components, the manufacturing system can be dynamically deployed in an agile manner. There are services such as demand forecasting, product ontology analysis, process matching, etc. The services are registered to the component management module, and then they can be strung together through the workflow management module of the middleware to form a large-scale planning and scheduling service. The manufacturing middleware will unify and integrate a large number of heterogeneous components in the design and operation life cycle of the production line, build services of components of different types and granularities, and deploy various functional modules of the middleware on this basis to verify the digital simulation verification of the intelligent production line during design, the synchronization of digital models during operation, the continuous integration to deployment when resources change dynamically, and provide predictive maintenance and other effects as digital infrastructure in the entire life cycle of the factory. The manufacturing middleware includes a workflow management module, a component management module and a model warehouse. The function of the workflow management module is to define, monitor and call the execution order of component services through workflows; the component management module is the basic module to realize the plug-and-play production of components in the workshop scheduling system, and is responsible for the dynamic registration and deletion of components; the model warehouse is responsible for the storage and display of domain models, semantic models and application models. Under the joint action of the workflow management module, component management module and model warehouse in the manufacturing middleware, centralized operation management of services is realized, so that manufacturing resources and computing resources can adapt to the requirements of seamless, stable and high-quality interaction.

[0063] In this embodiment, the manufacturing middleware implements a unified communication layer within each asset component to obtain a common communication infrastructure. The communication layer uses gRPC as a unified standard service interface. gRPC is a high-performance, general-purpose open source RPC (Remote Procedure Call) framework developed by Google mainly for mobile application development. It is designed based on the HTTP / 2 protocol standard, developed based on the ProtoBuf (Protocol Buffers) serialization protocol, and supports many development languages. Like many RPC systems, gRPC is based on the idea of ​​defining services, can specify parameters and return types for remote calls, and can quickly create distributed applications and services. On the server side, a gRPC interface server is running to handle client calls, and there is a stub on the client that provides the same request and response methods as the server.

[0064] By default, gRPC uses the Google protocol buffers compiler to serialize the data exchanged by gRPC. The communication protocol conversion module sends and receives instructions according to the format standard of the globally defined proto file. The proto file contains a serialized data definition structure. When sending instructions, the proto buffer data will be constructed as a key-value pair of instructions containing a series of information. Correspondingly, when receiving instructions, different instructions need to be parsed according to the proto format standard.

[0065] In this example, the communication layer selected gRPC as the unified service interface due to its excellent features such as fast, easy to use, bandwidth efficient, support for multiple languages, and automatic generation of API code.

[0066] However, there are many other communication protocols, the most commonly used are Http, and the most commonly used in the Internet of Things is MQTT. In this example, the communication layer supports the conversion between these two protocols. The gRPC driver interface is used to connect to the workflow management module of the middleware as a unified service interface; the HTTP driver interface is used to connect to software that supports cloud services; and the MQTT driver interface is used to connect to software tools that support Internet of Things related protocols.

[0067] Generally, after receiving a message, gRPC will encode and decode the message according to the protobuf buffer encoder. However, inside the communication protocol conversion module, it needs to receive instructions as a server and send instructions as a client. When the received instruction is gRPC, when the instruction is forwarded inside the communication protocol conversion module, it does not need to be encoded or decoded in any form. At this time, only a buffer encoder that is unaware of the protocol and only forwards it is needed to shield the decoding part of the gRPC built-in buffer encoder; when the received instruction is HTTP or MQTT, when the instruction is forwarded inside the communication protocol conversion module, the instruction needs to be re-parsed into a Proto request, and the encoder needs to be re-implemented.

[0068] Due to the differences in the implementation principles and methods of HTTP and MQTT protocols, different implementation methods also correspond to re-encoding and decoding.

[0069] In this embodiment, the application is a series of software tool services suitable for the operation control of personalized customized production lines. These software tools can meet the requirements of operation control of personalized customized production lines by adapting the computing, simulation, and optimization software with high versatility in the manufacturing system. At the same time, the application and manufacturing middleware have good versatility, making the integration and service arrangement based on application software services more convenient and with very good scalability. The business process model of the product includes functional components such as order processing, computing simulation, resource scheduling, and operation monitoring.

[0070] like Figure 2 As shown in the figure, in the process of asset component access to manufacturing middleware, when the asset component enters the production line, the adapter sends the information model and the basic service information of the component to the model warehouse and the component management module respectively. The information model is stored in the model warehouse in the form of an AML domain model. The adapter generates the OPC UA service of the asset based on the AML model of the asset. Before service registration, the adapter needs to provide the basic service information of the component to the component management module, including service GUID, service name, service IP and port, service granularity, etc. When the service registration of the component begins, the adapter converts the information model into an information instance that adapts to the component communication protocol. During the production execution process, the manufacturing middleware can also perform periodic health checks on the component service through the component management module to obtain the online / offline status of the component.

[0071] like Figure 3 As shown in FIG. 1 , the interactive operation process of the workflow management module and the component management module includes the following specific steps:

[0072] (1) The workflow management module obtains the service resource directory and matches resources according to the process definition.

[0073] The workflow needs to obtain the service resource directory at the beginning of the operation. The service resource directory is stored in the component management module. The directory saves the working status and service description of all service nodes. Newly added service nodes will be registered in the component management module, and the service directory will be updated in real time. At the beginning of the operation, the workflow management module sends a request to the component management module. The component management module matches the updated service resource directory with the organization / role defined in the business process and feeds back the matching result information to the workflow system.

[0074] (2) Allocate each activity in the business process to service resources.

[0075] After the workflow is created, a series of workflow specifications will be generated, which include the activity definitions generated by the decomposed workflow, the execution order between activities, and the constraint information of the activities. The workflow management module will generate a specific task list based on the constraints between these activities, and finally allocate them to the corresponding service resources in order.

[0076] (3) Execute the workflow and monitor the execution process.

[0077] When the workflow starts to execute, the workflow management module will check whether the service resources required for the activity have been transmitted to the service node before the task is executed. The workflow engine will also monitor the workflow execution process in real time, supervise whether the interdependencies between workflow tasks are destroyed, and whether the workflow service quality can be met. At the same time, the workflow management module will also perform exception handling and error recovery. In the process of monitoring the execution of workflows, a large amount of data will be generated between services, including product data generated by user orders, resource data generated by equipment and sensors, log data generated during application operation, and monitoring data of cloud servers. These data are very important for scenarios such as workshop scheduling, predictive maintenance, and software tool updates and iterations. The workflow management module will collect the data transmitted by each service node and store it in the elastic stack for data management. At the same time, the data can also be called by managers or software tools for data analysis.

[0078] The interactive operation process between resource services and assets is as follows:

[0079] When the workflow management module needs to make a service call, it creates an OPC UA client based on the basic information of the service to call the service, triggering the variables and method nodes of the OPC UA server in the adapter to respond to the service function requirements.

[0080] In this embodiment, the workflow management module is used to define the execution order of services, the content of data transmission between services, the starting point and end point of data transmission, the event execution order, etc. Therefore, data storage, data routing and event management are all implemented by the workflow management module. Workflow is an abstract and general description of the business rules between the workflow and its various operation steps. It is a concept proposed for business process activities. The purpose is to decompose the work into well-defined tasks or roles, implement and monitor these tasks according to certain principles and processes, so as to achieve the purpose of improving efficiency, controlling processes, and enhancing effective management of business processes.

[0081] like Figure 4 As shown in the figure, the architecture of the workflow management module can be divided into the following three types:

[0082] (1) The workflow management module has various functional software components, including automatic process modeling tools, workflow engines, task list managers, monitoring interfaces, and user interfaces;

[0083] (2) various types of model definitions and control data, including process definitions, organizational / role model data, workflow control data, task lists, and workflow-related data;

[0084] (3) The operation objects of the workflow management module include various applications and application databases;

[0085] In this embodiment, the process modeling contains all necessary information about the process so that it can be recognized and executed by the workflow engine. The automatic process modeling tool provides users with a visual interface for easily generating process models based on the metamodel of process modeling, avoiding a lot of repetitive work when users perform process modeling, and providing verification for the process models established by users. The process modeling metamodel determines a set of initial basic object types. When establishing a process modeling model, users can determine more object types through specific extensions or by defining additional functions at the same level.

[0086] The process modeling metamodel includes: workflow type definition, user activities to be executed in the workflow, start and completion conditions of the activity, rules for navigation between activities, workflow-related data that may need to be referenced, roles referenced by the activity, applications that may be called, etc.

[0087] like Figure 5 As shown in the figure, we get the ER relationship of each part. The activity is the main body of the process modeling metamodel. The activity contains the transition conditions, which are composed of workflow type definitions, involving role / organization data, and using workflow-related data and called applications at runtime. The workflow type definition and called applications also use workflow-related data.

[0088] The details are shown in Table 1 below:

[0089] Table 1 Parts of the process modeling metamodel

[0090]

[0091]

[0092] In this embodiment, the process modeling uses the Organization / Role model to specify services. The Organization / Role model contains information about the organizational structure and roles within the organization, usually in the form of an organizational directory. This allows activities to correspond to related organizational entities and role functions when modeling processes, without specifying specific participants. At runtime, the workflow engine is responsible for linking organizational entities or role functions with specific service participants in the runtime environment.

[0093] Process modeling tools often use BPMN as the business process modeling language. BPMN provides symbols that are easily understood by all business users, from business analysis to create process outlines to process implementation, building a standardized bridge between business process design and process implementation.

[0094] Different from the workflow management module architecture provided by the Workflow Management Alliance, due to the requirements of personalized product customization, the process modeling tool needs to automatically generate a business process model based on the product information model, while also including relevant workflow control data.

[0095] In this embodiment, the workflow engine interprets the business process model established by the user and controls the instantiation of the process and the order of activities, adds activities to the work list, and calls corresponding application services as needed. The workflow engine part can be implemented through the cooperation of one or more distributed workflow management engines, each of which manages the execution of a single instance of each business process.

[0096] The workflow engine controls the navigation of the individual activity steps in the process according to the process definition model established by the user, provides information about the entry and exit criteria of individual activity steps, the options for parallel or sequential execution of different activities, the software and hardware resource services related to each activity, etc. If the process definition includes structures related to these service types, it may need to access organization / role data. Therefore, the workflow engine includes a unified service interface to call specific services required by the activity and receive feedback during service runtime or after completion.

[0097] The workflow engine is also responsible for maintaining internal control data distributed in the workflow engine, including internal state information associated with the various processes and activity instances being executed, and may also include checkpoint and recovery restart information used by the workflow engine to coordinate and recover from failure states.

[0098] In this embodiment, during the process execution, the workflow engine will place the activity on the work list when parsing the process definition model, and hand it over to the task list manager for processing. The task list manager is responsible for processing the interaction between the workflow engine and the workflow participants. The task list manager can choose to open the task list to participants with different permissions. For general users, they only have the permission to view the task list. The task list will display the next task to be executed in sequence and check the task completion status; for administrators, they have the permission to select an activity from the task list to execute independently.

[0099] The task list manager can be just a receiver and storage of the results of the workflow engine execution, and notify the results to each service to wait for execution. In addition to the simple receiving function, the task list manager can also control the distribution of work among a group of users to provide functions such as load balancing and work redistribution. It also supports the workflow engine to interact with a wider range of service participants, including the login and logout of specific user services, user requests for specific service executors, changes to user request priorities (such as inserting orders), etc.

[0100] In this embodiment, the user interface is responsible for the appearance of the dialogue with the user and controls the local interface for contacting the user. Unlike the task list manager, the user interface is not directly controlled by the workflow engine and is invisible to the workflow engine.

[0101] The user interface is used in combination with the work list manager. The user interface interacts with multiple different workflow engines, so that tasks from different workflow engines can be integrated into a unified task list for public user presentation. The user interface can also integrate other local application services to support other functions necessary for product workflow execution, such as order processing.

[0102] In this embodiment, the administrator interface provides many supervisory functions for the entire workflow system based on the support of workflow engine supervisory authority, such as enabling the workflow engine to change task assignment rules, specifying participants of specific organizational roles in the process, tracking alerts for delayed deadlines or other events, tracking the history of specific process instances, and querying work throughput or other statistical data.

[0103] In this embodiment, like the user management interface, the administrator interface can also interact with multiple distributed workflow engines, provide a unified management interface, perform batch operations on multiple workflow engines, and control activities to switch between different workflow engines.

[0104] In this embodiment, there are asset components, product components and software tool components in the cloud manufacturing architecture. All these components are managed in the form of resource adapters, product adapters and software adapters. Each type of adapter includes a service registration and discovery module. The service registration and discovery module runs an agent in each component and is connected to the component management module.

[0105] In this embodiment, the component management module is a basic module for realizing plug-and-play production, and can dynamically register and delete asset components. When a component enters the intelligent production line system, the component management module discovers the component and registers it in the component management table. When a component exits the workshop scheduling system, the component management module deletes the corresponding information in the component management table.

[0106] In addition, component management also needs to maintain the component management table. The component management module will periodically poll the health status of each component, including checking the program running status, network status, sensor status, etc. of the component. When a component needs to be used, if there are other healthy components, the component management module will convert such task requests into calling another component of the same type. For example, when an asset component is abnormal (such as obtained through the resource active maintenance function), the component management module will automatically mobilize other components that provide the same function to complete the production task, thereby realizing the switch of component production without stopping the workshop.

[0107] The component management module can be composed of multiple data centers. The data of each data center is managed and shared separately, and together they form a service registration and discovery center. The component management module architecture refers to the Consul architecture, such as Figure 6 As shown in the figure, two data centers are used as examples, namely "Data Center 1" and "Data Center 2". In each data center, there is a mixture of servers and clients. As the number of servers increases, the speed at which the data center obtains "consensus" will slow down, while the number of clients has no effect. Therefore, after weighing the availability and performance in the failure scenario, the ideal number of servers in each data center is 3 to 5.

[0108] In the same data center, all nodes will participate in the gossip protocol. In other words, each data has a gossip pool, which contains all agents in the data center. The benefits of managing by data center are as follows:

[0109] (1) The service registration and discovery modules of each adapter do not require additional configuration of the server address. As long as the component is in the data center, it can be automatically discovered.

[0110] (2) The work of detecting proxy failures is distributed, and does not have to be done entirely on the server side, which is more reliable and efficient than centralized heartbeat detection. Similarly, if the component's proxy cannot reach the server, then the component node may have failed.

[0111] (3) The data center as a whole sends a message to the component management module, such as when the leader election is successful.

[0112] Each server in each data center jointly elects a leader to handle all queries and transactions. After the leader receives the RPC request, it copies the request to all other nodes participating in the consensus protocol for execution. After the follower receives the RPC request, it needs to forward the request to the leader.

[0113] In response to the high latency of the Internet, a chat pool is established through the local area network (LAN) in each data center so that components in the same data center can discover each other more quickly.

[0114] A chat pool is established between data centers through the wide area network (WAN). All servers in all data centers are in the WAN chat pool, so servers in different data centers can implement cross-data center requests. In the WAN chat pool, when a server receives a request from a different data center, it forwards the request to the local leader, and then the leader forwards it to the correct data center.

[0115] In general, requests are not replicated between different data centers. When a request is made to a node in another data center, the local server forwards the RPC request to the remote server and returns the result. If the remote data center is unavailable, then these resources are also unavailable, but this does not affect the local data center. In some special cases, a limited subset of data can be replicated. For example, the client's agent may cache data from the server and make it available locally to improve performance and reliability. Even if the connection to the server is interrupted or the server is temporarily unavailable, the local agent can continue to respond to some queries from the cache, such as service discovery or connection authorization.

[0116] Therefore, the coupling between data centers is very low, and it can handle fault detection, connection cache reuse, cross-data center requests, etc., and is relatively fast and reliable.

[0117] In the whole life cycle of intelligent production lines, models from many different fields are involved. The model warehouse can store and display domain models, semantic models, and application models. It supports multiple text formats, such as AML, Json, OWL, CPN, XML, etc. In addition to storage, it can also display various types of text in the form of Web services.

[0118] The model warehouse adopts a decentralized shared-nothing architecture. Object data is stored on multiple hard disks in different nodes, providing external unified namespace access and achieving load balancing between servers through load balancing or DNS polling. Because there are no special nodes, the damage of any node will not affect the communication between the nodes of the entire cluster.

[0119] Similar to distributed databases, model warehouses also face the problem of data consistency. When one client is reading an object, another client may be modifying or deleting the object. In order to avoid data inconsistency, distributed lock management needs to be implemented to control data consistency. The implementation method of distributed lock management is as follows:

[0120] When any node generates a lock request, it notifies all healthy data storage servers in the cluster in the form of broadcast;

[0121] If more than half of the data storage servers agree to the lock request, the data lock is acquired successfully;

[0122] Each data storage server is equal and detects the current server status and lock holding status of each other.

[0123] For each data storage server, it is very necessary to ensure the security of data. The model warehouse uses erasure code and checksum to protect data from hardware failure and data loss. Even if half of the storage blocks are lost, the data can still be recovered.

[0124] In this embodiment, a specific implementation method of the manufacturing middleware is specifically introduced, and the implementation of the manufacturing middleware is only for better explanation, but not to limit the implementation of the manufacturing middleware.

[0125] In the cloud server, Kubernetes is deployed, which provides the basis for building manufacturing middleware. Therefore, other modules are installed on top of Kubernetes to jointly implement the manufacturing middleware system.

[0126] The model repository, workflow management module, and component management module of the manufacturing middleware all use third-party tools. Helm is a package management tool for Kubernetes. Most third-party tools provide Helm packages, which can be searched in the Helm application center and installed directly to Kubernetes using Helm.

[0127] Deployment of workflow management module: Zeebe is a free open source workflow engine for microservice orchestration. It provides visibility into the end-to-end workflow status of the production line, including the number of running workflows, average workflow duration, current errors in the workflow, etc.

[0128] Zeebe is one of the few workflow engines that uses a microservice architecture. Because it uses a universal cross-language RPC protocol, Zeebe can be written in different languages ​​and run in different environments. Zeebe uses the standard business process model BPMN 2.0, which can intuitively define processes.

[0129] Zeebe is deployed using Docker and Kubernetes, enables building processes that react to messages from Kafka and other message queues, can scale horizontally to handle very high throughput, and does not rely on a relational database.

[0130] Zeebe uses ElasticSearch as the runtime data search and analysis engine. Elasticsearch can also be seen as a workflow control data database. When Zeebe is running, it will input the operation log into Elasticsearch in JSON format through the data exporter. Each JSON file will establish a connection between a set of keys (the names of fields or attributes) and their corresponding values ​​(data types such as strings, numbers, Boolean values, dates, etc.).

[0131] You can use Helm, the package manager for Kubernetes, to install Zeebe. You can control the installation configuration of Zeebe, such as the number of server replicas, by configuring Helm's installation value parameters. Zeebe uses ElasticSearch as a search engine (which can also be seen as a database for storing workflow operation data), which will also be installed when using Helm.

[0132] Deployment of component management module: The component management module of the manufacturing middleware is implemented based on the service mesh Consul. Consul is a service mesh solution that is distributed, highly available, and horizontally scalable for implementing service discovery and configuration of distributed systems. It can realize functions such as registration and discovery of components and services, and can uniformly query service IP addresses and ports, query service operation status, response speed, etc. In order to integrate the content of all nodes into this mesh, all nodes in the information-physical system, including edge processing units and cloud servers, from resource nodes to product nodes, need to be added to the Consul service mesh, which requires the installation of Consul agents on all nodes. In addition, Consul also requires a data plane that supports both proxy and native integration models. Since Consul comes with a simple built-in agent, everything can be used directly.

[0133] Consul supports installation using Helm. By default, applications installed to Kubernetes can automatically register services in Consul, which provides service discovery capabilities within the cluster subnet. Since services need to be exposed outside the cluster, you can install an independent Consul program outside of Kubernetes and form another data center to connect to the Consul server inside the cluster to jointly provide service discovery capabilities. Since the inside and outside of the cluster are not in the same subnet segment, Consul needs to be installed inside and outside the cluster respectively and configured as different data centers. Both data centers need to install servers on the same node, and in this way, two different data centers are connected to form a service mesh.

[0134] Deployment of the model repository: The model repository is provided by MinIO. Again, MinIO is installed on Kubernetes using Helm. MinIO provides high-performance, S3-compatible object storage. MinIO is native to Kubernetes and is the only object storage suite available for every public cloud, every Kubernetes distribution, private cloud, and edge. MinIO supports the widest range of use cases in the largest number of environments. MinIO can provide a range of use cases, including AI / ML, analytics, backup / recovery, and modern web and mobile applications.

[0135] MinIO was born for cloud technologies and architectures, including containerization, Kubernetes orchestration, microservices, and multi-tenancy. MinIO is almost the only choice for object storage services for Kubernetes. In addition, MinIO is the fastest object storage server in the world. With read / write speeds of 183GB / s and 171GB / s on standard hardware, object storage can run as the primary storage layer for a variety of workloads. The diversity of its deployment strengthens the software in a way that proprietary software can never provide, so MinIO is very suitable for manufacturing enterprises.

[0136] MinIO is suitable for large-scale storage of unstructured data, such as pictures, videos, log files, backup data, etc., and is very lightweight. The selected model object storage service MinIO meets the following characteristics: 1) Using erasure coding, the model object can be divided into data and check blocks with configurable redundancy levels, and distributedly stored on different hard disks. When reading the model object, the complete model can be reconstructed from these distributed stored data. Because the erasure code has redundancy and verification mechanisms, in the case of partial data loss, the model can be completely reconstructed as long as the amount of lost data does not exceed the configured redundancy level. 2) Real-time error detection and recovery. The model is the basis of the personalized manufacturing system. Even if the hard disk is strictly preserved, the data of the model may still be destroyed in unexpected circumstances. In order to ensure data stability, a hash algorithm should be used for data verification. When erroneous data is detected, the erroneous data block can be quickly restored through other data provided by the erasure code.

[0137] The above embodiments are preferred implementation modes of the present invention, but the implementation modes of the present invention are not limited to the above embodiments. Any other changes, modifications, substitutions, combinations, and simplifications that do not deviate from the spirit and principles of the present invention should be equivalent replacement methods and are included in the protection scope of the present invention.

Claims

1. A manufacturing middleware device for intelligent production lines, characterized in that: include: Workflow management module, component management module and model warehouse; The workflow management module defines, monitors and calls the execution order of component services through workflow; The component management module is a basic module for plug-and-play production of components in the workshop scheduling system, and completes dynamic registration and deletion of components; The model warehouse is used to store and display domain models, semantic models and application models; The service resource directory is stored in the component management module. The workflow management module sends a request to the component management module to obtain the service resource directory, matches resources according to the process definition, allocates each activity in the business process to the service resource, executes the workflow and monitors the execution process; The resource matching according to the process definition specifically includes: The service resource directory stores the working status and service description of all service nodes. Newly added service nodes are registered with the component management module, and the service directory is updated in real time. The workflow management module sends a request to the component management module, and the component management module matches the updated service resource directory with the organization or role defined in the business process, and feeds back the matching result information to the workflow system; The allocation of each activity in the business process to the service resources specifically includes: After the workflow is created, a workflow specification is generated. The workflow specification includes the activity definition generated by the decomposed workflow, the execution order between activities, and the constraint information of the activities; The workflow management module generates a task list based on the constraints between activities and distributes them to the corresponding service resources in sequence; The execution workflow and monitoring of the execution process specifically include: When the workflow starts to execute, the workflow management module checks whether the service resources required by the activity have been transmitted to the service node before the task is executed. It monitors the workflow execution process in real time, supervises whether the interdependencies between workflow tasks are destroyed, and whether the workflow service quality can be met. It also handles exceptions and recovers errors, and collects and stores the data transmitted by each service node into the elastic stack for data management. The workflow management module includes: automatic process modeling tool, workflow engine, task list manager, monitoring interface, user interface; The automatic process modeling tool generates a visual interface of the process model based on a metamodel of process modeling, wherein the metamodel of process modeling sets a set of initial basic object types and determines more object types through set extensions or by defining additional functions at the same level; The automatic process modeling tool automatically generates business process models and workflow control data based on the product information model; Process modeling uses an organization or role model to specify services. When modeling processes, activities correspond to related organization entities and role functions. The workflow engine connects organization entities or role functions with specific service participants in the runtime environment. The workflow engine interprets the business process model established by the user and controls the instantiation of the process and the sequence of activities, adds activities to the work list, and calls the corresponding application services; The workflow engine controls the navigation of the individual activity steps in the process according to the process definition model established by the user, provides information about the entry and exit criteria of the individual activity steps, the options for parallel or sequential execution of different activities, and the software and hardware resource services associated with each activity; During the process execution, the workflow engine parses the process definition model and places the activities on the work list, which is then transferred to the task list manager for processing; The task list manager handles the interaction between the workflow engine and workflow participants, opens the task list to participants with different permissions, controls the distribution of work between users, and supports the interaction between the workflow engine and service participants; The user interface is used to generate the appearance of the user dialogue and control the local interface for contacting the user. The user interface is used in combination with the work list manager to interact with multiple different workflow engines and integrate the tasks from different workflow engines into a unified task list; The administrator interface provides supervision functions for the entire workflow system based on the support of workflow engine supervision permissions, interacts with multiple distributed workflow engines, provides a unified management interface, performs batch operations on multiple workflow engines, and controls the switching of activities between different workflow engines; When the workflow management module makes a service call, it creates an OPC UA client based on the basic information of the service to call the service, triggering the variables and method nodes of the OPC UA server in the adapter to respond to the service function requirements.

2. The manufacturing middleware device for intelligent production line according to claim 1 is characterized in that: The workflow engine sets a unified service interface, calls the services required by the activities, and receives feedback when the services are running or completed.

3. The manufacturing middleware device for intelligent production lines according to claim 1 is characterized in that: The workflow engine is also used to maintain internal control data distributed in the workflow engine, including internal state information associated with various processes and activity instances being executed, and checkpoint and recovery restart information used by the workflow engine to coordinate and recover from failure states.

4. A cloud manufacturing architecture system for intelligent production lines, characterized in that: A manufacturing middleware device for intelligent production lines according to any one of claims 1 to 3 is provided, further comprising an asset component, a product component and a software tool component, wherein the asset component, the product component and the software tool component are all managed in the form of adapters, and a service registration and discovery module is provided in each type of adapter; When a component enters the intelligent production line system, the component management module discovers the component and registers it in the component management table. When the component exits the workshop scheduling system, the component management module deletes the corresponding information in the component management table. The component management module maintains the component management table and periodically polls the health status of each component, including checking the program running status, network status, and sensor status of the component; When a component needs to be used, if there are other healthy components, the component management module will convert the task request to call another component of the same type. When a component fails, the component management module will mobilize other components that provide the same function to complete the production task. When the asset component enters the production line, the adapter sends the information model and basic service information of the component to the model warehouse and component management module respectively; The information model is stored in the model repository in the form of an AML domain model, and the adapter generates an OPC UA service for the asset based on the AML model of the asset; Before service registration, the adapter provides the component management module with basic service information of the component, including service GUID, service name, service IP and port, and service granularity; When the component's service registration begins, the adapter converts the information model into an information instance that matches the component's communication protocol; During the production execution process, the manufacturing middleware also performs periodic health checks on component services through the component management module to obtain the online or offline status of the components.

5. The cloud manufacturing architecture system for intelligent production lines according to claim 4 is characterized in that: The model warehouse adopts a decentralized shared-nothing architecture, object data is stored in different nodes, a unified namespace access is provided to the outside world, and load balancing is achieved between various servers through load balancing or DNS polling.

6. The cloud manufacturing architecture system for intelligent production lines according to claim 4 is characterized in that: The model warehouse performs distributed lock management to control data consistency, specifically including: When a node generates a lock request, it notifies all healthy data storage servers in the cluster in the form of broadcast; If more than half of the data storage servers agree to the lock request, the data lock is acquired successfully; Each data storage server is equal and detects the current server status and lock holding status of each other.

Images