Method for deploying software modules in a manufacturing operations management system

Abstract

It is an object of the present invention to provide a method for deploying software modules in a MOM system, which does not require an operator to know where within the network of addressable / accessible computing resources within the MOM system to deploy the software modules. This object is achieved by a method for deploying software modules in a manufacturing operations management system (MOM system). The method comprises the steps of: a) providing a plurality of software modules to be deployed, each software module comprising a set of metadata; b) providing a plurality of computing resource tiers; each resource tier comprising a plurality of computing resources and being capable of communicating tier-specific data, the tier-specific data comprising at least data representing resource availability information; c) executing a deployment instance that evaluates the metadata and the tier-specific data; d) determining from the metadata and the tier-specific data a computing resource tier and a computing resource at which the software module is to be deployed; e) executing the software module on the determined computing resource within the determined computing resource tier.

Description

Technical Field

[0001] This invention relates to a method for deploying software modules in a manufacturing operations management system (hereinafter referred to as a MOM system). Background Technology

[0002] In the fields of process automation and process monitoring, standard automation systems for controlling the widest range of conceivable production resources, machines, and plants (MOM objects) are the existing technology. Such technology specifically encompasses Siemens' expertise in Manufacturing Operations Management (MOM). The product family offers a wide range of products. A large product line enhances the performance capabilities of appropriate process controllers by addressing the technical tasks discussed, such as counting, measurement, positioning, motion control, closed-loop control, and CAM control. Various configurations enable flexible machine concepts.

[0003] In this context, a wide range of IT solutions exist to connect the physical hardware, which is close to the technical and / or logical processes, to the application layer of the client-side drive. Therefore, Manufacturing Execution Systems (MES) have been developed to meet all the requirements of Service-Oriented Architecture (SOA) for seamless integration into Totally Integrated Automation (TIA). The plug-and-play architecture, where individual functions can be configured and easily combined with each other, forms the basis of this success, thereby simplifying the complex structures controlling manufacturing plants, etc.

[0004] These requirements typically necessitate sophisticated and complex software solutions within the framework that enable fully integrated automation. Consequently, software engineers often use production modeling software to define the factory model and its standard operating procedures, and then create the corresponding new software using a high-level graphical language that identifies the workflow of activities within the software. This high-level graphical language string / item is then translated into a client-based software language that can be executed at the machine language level. This translation requires a significant amount of programming work and rigorous testing to verify that the translated program behaves identically to the original high-level graphical language string / item.

[0005] Within this MES environment, software for detailed production scheduling (PDS) is provided, which involves the sequencing and timing of production operations across all manufacturing resources. The purpose of this software is to create executable and optimized production schedules that will be executed in production. Before calculating the schedule, the PDS software needs to be provided with key inputs from the plant database, such as:

[0006] a) Factory logical layout and logistical constraints;

[0007] b) Standard productivity of equipment and personnel;

[0008] c) Availability, schedules, and status of equipment and personnel;

[0009] d) Knowledge of production methods (formulas, routes, etc.), processes, and business constraints;

[0010] e) Skills provided by production resources.

[0011] Using this information, the PDS software builds a model of its internal factory and the production processes within that factory. Then, by applying a scheduling algorithm to this internal factory model of the factory's resources (MOM objects) and production processes, the PDS software calculates an executable production schedule that does not violate any physical, logical, and / or business constraints and optimizes manufacturing performance.

[0012] At this stage, it's easy to understand that many factory and / or machine operators need to interact with the MOM system via a user interface (UI), which is set up on a customizable MES screen (UI client) displayed on fixed workstations and / or mobile tablets. Typically, these factory and / or machine operators need to deploy new software modules and / or update existing ones. Due to the complexity of modern MOM systems, the concept of a single software instance deployed within a single data center of the MOM system no longer exists. MOM software is modularized and distributed across many different levels (machine level, edge device level, data center level, factory level, cloud (private or public), etc.).

[0013] Despite the foregoing, software modules in a MOM system require simple manual installation by IT administrators. These operations are time-consuming, and the software modules themselves do not offer any ability to automatically suggest the correct tiers they can / should install. MOM business and IT roles must work together to determine the optimal deployment scenario, and for this purpose, they need to know the resource requirements and business scope of the planned software modules. This collaborative process is time-consuming and cannot be repeated frequently. Summary of the Invention

[0014] Therefore, the object of the present invention is to provide a method for deploying software modules in a MOM system, which does not require the operator to know where the software modules are deployed within the network of addressable / accessible computing resources in the MOM system.

[0015] According to the present invention, this objective is achieved by a method for deploying software modules in a manufacturing operations management system (MOM system), the method comprising the following steps:

[0016] a) Provide multiple software modules to be deployed, wherein each software module includes a set of metadata, the metadata including multiple deployment criteria;

[0017] b) Provide multiple computing resource layers, each resource layer including multiple computing resources and capable of transmitting layer-specific data, the layer-specific data including at least data representing resource availability information;

[0018] c) Execute deployment instances that evaluate metadata and layer-specific data;

[0019] d) Determine the computing resource layer and computing resources on which software modules will be deployed, based on metadata and layer-specific data; and

[0020] e) Execute the software module on the determined computing resources within the determined computing resource layer.

[0021] Therefore, this invention provides new functionality in MOM systems, enabling (IT) operators to deploy new and / or updated software modules that provide detailed knowledge of where to install them through their metadata. Furthermore, operators no longer need to distribute software modules themselves or know the requirements of each module (in terms of data, business, needs, etc.), because the deployment instance now knows this and can automatically install the software modules in the correct layer of the typically very complex distributed architecture of the computing resources in the MOM system.

[0022] In a preferred embodiment of the invention, layer-specific data enables deployment instances to determine the available computing resources within the determined computing resource layer.

[0023] Furthermore, the quality of the metadata assigned to each software module is crucial for the successful and correct deployment of that module. A sufficiently clear structure for the metadata can be achieved when the deployment criteria in the metadata are one or more of the following:

[0024] a) Digital twin distance, which defines the proximity of functions between a software module and a module within a MOM system;

[0025] b) Required resource capacity, which defines the capacity required for computing resources to run the software module, including a set of computing-related values ​​such as computing references, memory references, network references and / or data volume references;

[0026] c) Required resource capabilities, which define the basic capabilities required for computing resources to run the software module. These required resource capabilities include a set of relevant capability data, such as security, redundancy, and / or availability; and / or

[0027] d) Priority value, which indicates the priority of the software module to be deployed.

[0028] The term "digital twin distance" may seem like a rather abstract definition, but it actually provides an idea of ​​the logical distance between actual production and the computational layer where software modules can be deployed. A simple example is a new software module that controls the movement / trajectory of a production robot and another software module that calculates a new set of production-related KPIs. Clearly, the digital twin distance of the first module is zero or nearly zero, meaning that this software module must execute within the computational resources controlling that particular robot. For the latter software module, the digital twin distance can be considerably larger, as the KPI calculation tool can run at the factory / site level alongside the IT backbone, or even at a higher level as a service in a cloud environment (private or public cloud).

[0029] Therefore, a preferred embodiment of the present invention can be achieved when the digital twin distance includes the following values:

[0030] a) The value “0 or twin” indicates that the software module needs to physically run in the same place where the business logic of the software module is executed, that is, physically run in the smart device that complies with the operator and / or the edge device installed with production resources, resulting in a software-to-business distance close to or equal to “zero”, which means that there is no delay introduced by the communication network and the risk of disconnection is minimized.

[0031] b) A value of "1 or near" indicates that the software module needs to be physically installed in the same environment, that is, the software module is installed in a factory or regional data center, and the operator accesses the software module through a client.

[0032] c) The value "2 or remote" indicates that the software module is physically installed in a remote environment, that is, the software module is installed in the regional headquarters data center, and the operator accesses the software module through a client; and / or

[0033] d) The value “3 or global” indicates that the software module is usually installed in the cloud (private cloud or public cloud) and the allocation / creation of resources is highly dynamic and theoretically unlimited. Each computing layer can usually have dynamic costs based on the use of computing resources.

[0034] In another preferred embodiment of the invention, each computing resource layer is assigned a predetermined value for the digital twin distance. This assignment facilitates identification using the digital twin distance values ​​included in the metadata of the software modules to consistently identify the appropriate computing environment for the deployment of the software modules.

[0035] Other preferred embodiments of the invention can be obtained from the remaining dependent claims. Attached Figure Description

[0036] Preferred embodiments of the invention will now be discussed in detail with reference to the accompanying drawings, which depict:

[0037] Figure 1 It is a schematic overview of the manufacturing operations management system and the computing resources distributed within the MOM system;

[0038] Figure 2 This is an illustrative example of multiple software modules and related metadata sets;

[0039] Figure 3 It is based on Figure 1 A schematic overview of the computing resources present in the MOM system;

[0040] Figure 4 It is based on Figure 1 A schematic overview of an MOM system with an additional deployer module; and

[0041] Figure 5 It is based on Figure 4 A schematic overview of an MOM system with multiple deployed software modules. Detailed Implementation

[0042] Figure 1 A schematic overview of a manufacturing operations management system (hereinafter referred to as MOM system 2) is shown, which includes multiple computing resources C0 to C3 organized in different computing resource layers L0 to L3. In layer L0 at the shop floor level (hereinafter referred to as the digital twin layer), multiple operators 4 work in a direct digital twin environment using industrial PCs, industrial handheld devices, barcode scanners, etc., which serve as computing resources C0. Operators 4 require these computing resources C0 to control and monitor the industrial production process at the closest possible distance to the actual production operations.

[0043] In the office-level layer L1 (hereinafter referred to as the nearby environment layer L1), multiple operators 6 use industrial PCs, industrial tablets, smartphones, etc., as computing resources C1 to work in a location relatively close to the actual production process within the factory (remote site) as supervisors or other personnel (main site). Operators 6 need these computing resources C1, for example, to monitor the KPIs of the industrial production process in close proximity to the actual production operations.

[0044] In Layer L2 (hereinafter referred to as Remote Environment Layer L2), which is at the HQ / data center level, multiple remote users 8 use PCs, industrial PCs, industrial tablets, smartphones, etc., as computing resources C2 to work in environments far removed from the actual production process, in roles such as administrators, IT experts, engineers, schedulers, and managers. Remote users 8 require these computing resources C2, for example, to model production and its steps at a distance from actual production operations, schedule production operations, manage data repositories used in industrial processes, manage all relevant process data, resources, personnel, and operate the Enterprise Resource Planning (ERP) system and its links to the MOM system 2.

[0045] At the global level (private or public cloud), in layer L3 (hereinafter referred to as global environment layer L3), multiple remote users 10 use PCs, industrial PCs, industrial tablets, smartphones, etc., as computing resources C3 to work in a global environment far removed from the actual production process, in roles such as CEO, CFO, department head, administrator, IT expert, engineer, scheduler, and manager. Operators 8 need these computing resources C3, for example, to check KPIs, manage the enterprise, and provide data to government and / or life science organizations (such as the Drug Administration (FDA)) further away from the actual production operation, as well as to manage all relevant process data, resources, personnel, and to run the managed Enterprise Resource Planning (PLN) system ERP and its link to the MOM system 2.

[0046] All computing resources C0 to C3 are wired and / or wirelessly connected to the corporate network EN and / or the Internet 12 via their respective network devices N1, N2 (e.g., routers, servers, etc.).

[0047] Figure 2 An overview of multiple software modules SM1 to SM6 and the corresponding metadata MD sets assigned to each software module SM1 to SM6 is now shown. Specifically, the metadata MDs include multiple deployment criteria listed in the table for the metadata MDs. In the left column, digital twin distance values ​​are given, which define the proximity of the functionality of the software module SM to the modules within MOM system 2. In this example, the digital twin distance may include the following values:

[0048] a) The value “0 or twin” indicates that the software module needs to physically run in the same place where the business logic of the software module is executed, that is, physically run in the intelligent (IM) device that complies with the operator and / or the edge device installed with production resources, resulting in a software-to-business distance close to or equal to “zero”, which means that there is no delay introduced by the communication network and the risk of disconnection is minimized.

[0049] b) The value “1 or near (NEAR)” indicates that the software module needs to be physically installed in the same environment, that is, the software module is installed in a factory or regional data center, and the operator accesses the software module through a client.

[0050] c) The value "2 or REMOTE" indicates that the software module is physically installed in a remote environment, that is, the software module is installed in the regional headquarters data center, and the operator accesses the software module through a client; and / or

[0051] d) The value “3 or GLOBAL” indicates that the software module is typically installed in the cloud (private or public cloud) and the allocation / creation of resources is highly dynamic and theoretically unlimited. Each computing layer can typically have dynamic costs based on the use of computing resources.

[0052] The second column lists the required resource capacity, defining the capacity of computing resources needed to run the software module. This required resource capacity includes a set of computation-related values ​​such as computational quotes, memory references, network references, and / or data volume references. The third column lists the required resource capabilities, defining the basic capabilities required of computing resources to run the software module. These required resource capabilities include a set of relevant capability data such as security, redundancy, and / or availability. The right column provides priority values, indicating the priority of the software module to be deployed.

[0053] The Deployer Module (DM) analyzes the metadata (MD) to determine the compute resource layers (L0 to L3) where the corresponding software modules (SM1 to SM6) need to be deployed.

[0054] Figure 3 This presents a schematic overview of the compute resource layers L0 through L3 and the layer-specific data RDs. The layer data includes, in the left column, the digital twin distances that can be provided by the corresponding layer. The second column provides information about compute-related values ​​such as compute references, memory references, network references, and / or data volume references. The right column provides information about the available capabilities provided by the corresponding layer. Therefore, this layer-specific data RD is sufficient to enable the deployer module DM to map the metadata MDs provided by each software module SD1 through SD6 to the intended compute resource layers L0 through L3.

[0055] Figure 4 Now, schematically, it is shown that according to Figure 1 An overview of the MOM system 2 with the additional deployer module DM and software module store 14, in which software modules SM1 to SM6 are awaiting deployment. For simplicity, the accompanying drawings are omitted. Figure 4 and Figure 5 In the already Figure 1 The reference numerals for the components described in the diagram.

[0056] Thanks to the capabilities of the Deployer Module DM, the customer (i.e., IT user 16) can access the software module repository 14 and automatically select software modules SM1 through SM6 and distribute them to compute resource layers L0 through L3. This is achieved using a simple algorithm (see below) to allocate software modules to compute resources C0 through C3 by analyzing the relevant metadata MD of the software modules. Since each software module is designed for a specific business scope, the software module "knows" its specific requirements by presenting its metadata MD to the Deployer Module DM. This metadata MD, used by the Deployer Module DM, is shipped along with the software module itself.

[0057] Deployer Module Algorithm

[0058]

[0059]

[0060] Figure 5 The final positions of the currently deployed software modules SM1 through SM6 within different computing resource layers L0 through L3 are now schematically illustrated. For example, software module SM1, dedicated to the Trace and Track (TNT) function, has a digital twin distance “TWIN” and a priority of “1”, meaning that SM1 is the first software module to be deployed. Based on its metadata, the Deployer Module (DYM) deploys software module SM1 in digital twin layer L0. Software module SM2 has dispatch (DSP) functionality and has been deployed to the nearby environment layer L1 based on its metadata MD. Software module SM3 has plant model (FTM) functionality and has been deployed to the remote environment layer L2 based on its metadata MD. The same applies to software module SM4, which has material model (MTM) functionality. These software modules SM3 and SM4 are more precisely engineering type modules, which classifies them into the remote environment layer L2. Software modules SM5 and SM6 also have project types, but their functionality is quite applicable in a more general and global manner, which classifies them as candidates for deployment in the global environment layer L3. This assignment is currently "nailed" to these software modules SM5 and SM6 via their respective metadata MDs.

[0061] Therefore, the Deployer Module (DM) algorithm performs installation in the following manner: First, it acquires the software module with the highest priority, and based on the required resources in terms of both capacity and performance, the algorithm selects the nearest compute resource layer (or the one with the same digital twin distance and sufficient available resources to run the software module). Whenever a software module is assigned to a specific compute resource layer, the Deployer Module (DM) automatically calculates the remaining available resources. After the first software module is assigned to a compute resource layer and installed, the Deployer Module (DM) selects the next software modules (SM1 through SM6) based on their assigned priorities, and determines the correct compute resource layer (and installs the software module in the correct compute resource layer) by applying the same algorithm.

[0062] Therefore, this invention provides new functionality in MOM System 2 by leveraging the capabilities of the Deployer Module DM (Deployer Instance), enabling (IT) operators to deploy new and / or updated software modules SM1 to SM6, which, based on their metadata, provide detailed knowledge of where to install the respective software modules. Furthermore, operators no longer need to distribute the software modules themselves or know the requirements of each software module (in terms of data, business, needs, etc.), because the deployment instance now knows this and can automatically install the software modules in the correct layer of the typically very complex distributed architecture of computing resources in MOM System 2.

Claims

1. A method for deploying software modules in a Manufacturing Operations Management System (MOM) system, the method comprising the following steps: a) Provide multiple software modules to be deployed, wherein each software module includes a set of metadata, the metadata including deployment criteria, wherein the deployment criteria in the metadata are at least one of the following criteria: Digital twin distance defines the proximity of the functions of the software module and the modules within the MOM system. The digital twin distance includes at least one of the following values: The value "0 or twin" indicates that the software module needs to physically run in the same place where the business logic of the software module is executed, that is, physically run in the smart device that complies with the operator and / or the edge device installed with production resources, resulting in a software-to-business distance close to or equal to "zero", which means that there is no delay introduced by the communication network and the risk of disconnection is minimized. The value "1 or near" indicates that the software module needs to be physically installed in the same environment, that is, the software module is installed in a factory or regional data center, and the operator accesses the software module through a client. The value "2 or remote" indicates that the software module is physically installed in a remote environment, that is, the software module is installed in the regional headquarters data center, and the operator accesses the software module through a client; and The value "3 or global" indicates that the software module is installed in a private or public cloud, and that the allocation or creation of resources is highly dynamic and theoretically unlimited, thereby enabling the computing resource layer to have dynamic costs based on the use of computing resources. Required resource capacity: Defines the capacity of computing resources required to run the software module, wherein the required resource capacity includes a set of computing-related values; Required resource capabilities, defining the basic capabilities required for computing resources to run the software module, wherein the required resource capabilities include a set of relevant capability data; and Priority value, indicating the priority of the software module to be deployed; b) Provide multiple computing resource layers, each of which includes multiple computing resources and is capable of transmitting layer-specific data, wherein the layer-specific data includes at least data representing resource availability information; c) Execute a deployment instance to evaluate the metadata and the layer-specific data; d) Determine the computing resource layer in which the software module will be deployed, and the computing resources in the plurality of computing resources of the determined computing resource layer, based on the metadata and the layer-specific data; and e) Execute the software module on the determined computing resources within the determined computing resource layer.

2. The method according to claim 1, wherein, The layer-specific data enables the deployment instance to determine the available computing resources within the identified computing resource layer.

3. The method according to claim 1, wherein, The deployment criteria include the required resource capacity, and the computation-related values ​​are computation references, memory references, network references, and / or data volume references.

4. The method according to claim 1, wherein, The deployment criteria include the required resource capabilities, and the relevant capability data are security, redundancy, and / or availability.

5. The method according to any one of claims 1 to 4, wherein, The deployment criteria include the digital twin distance, and each computing resource layer is assigned a predetermined value of the digital twin distance.

Images