Method for operating plurality of production plants by means of regional hub concept of manufacturing execution system solution

Abstract

The aim of the invention is to define a method that allows the management of a particularly large MES / MOM project to be simplified, which may involve a plurality of manufacturing sites and a plurality of servers that require strict guidance regarding as low as possible to hold patches and update thresholds. According to the invention, this object is achieved by a method for operating a plurality of production plants by means of a manufacturing execution system, said method comprising the following steps: a) providing central computing hardware as a regional hub for running MES software; the MES software can manage a production process running through a plurality of production factories; b) configuring a first manufacturing execution system for a first single plant connected to the regional hub; c) creating a respective manufacturing execution system for each other plant by inheriting all configurations of the first manufacturing execution system to the other manufacturing execution systems; and d) configuring these additional plants with existing solutions in the regional hub over time without the need to reinstall the software of the manufacturing execution system and without the need to reapply some configurations that have been executed in the first plant and / or without the need to stop the system. Therefore, the method provides a better value for a multi-plant solution by reducing TCO. Indeed, the same number of servers required to hosting MES / MOM solutions serving a single manufacturing plant in the prior art can now be used to manage multiple plants (as presented in Figure 1). The set of servers constitutes a single MES / MONM solution distributed environment and is hosted by the same regional hub or at least a single "virtual data center" in the event of selecting a public cloud deployment according to the functionality provided by the cloud provider.

Description

Technical Field

[0001] The present invention relates to a method for operating a plurality of production plants by means of a manufacturing execution system. Background Art

[0002] In the field of process automation and process monitoring, standard automation systems for controlling the widest possible variety of production resources, machines and plants (MOM objects) are state of the art. Such technology particularly covers the development of the Manufacturing Operations Management (MOM) technology developed by Siemens AG. A wide range of products available under the product family. A large product line for solving the technical tasks in question such as counting, measuring, positioning, motion control, closed-loop control and cam control increases the performance capabilities of the appropriate process controller. Various configurations make it possible to realize flexible machine concepts.

[0003] In this context, there are a wide range of IT solutions to connect the actual hardware close to the technical and / or logical processes to the application layer of the client that drives the installation. Therefore, the Manufacturing Execution System (MES) has been developed to meet all the requirements of the Service Oriented Architecture (SOA) to integrate seamlessly into Totally Integrated Automation (TIA). The plug-and-play architecture in which the individual functions can be configured and easily combined with each other thus forms the basis for this success, thereby simplifying the complex structure of controlling manufacturing plants and the like.

[0004] These requirements usually require quite complex and sophisticated software solutions in the backbone that can realize the method of fully integrated automation. In view of this, software engineers usually use production modeling software to define the factory model and its standard operating procedures, and create corresponding new software with the help of high-level graphic languages ​​that identify the workflow of activities within the software. Subsequently, the strings / terms of the high-level graphic language are translated into a client-based software language that can be executed at the machine language level. This translation requires a huge amount of work in programming and requires rigorous testing to check whether the translated program behaves the same as the original strings / terms of the high-level graphic language.

[0005] Within this MES environment, software is provided for detailed production scheduling (PDS), which involves the sequencing and timing of production operations on all manufacturing resources. The purpose of this software is to create executable and optimized production schedules to be executed in production. Before the schedule is calculated, the main inputs need to be provided to the PDS software from the factory database, such as:

[0006] a) Factory logical layout and material flow constraints;

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

[0008] c) availability, schedule and status of equipment and personnel;

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

[0010] e) Skills provided by production resources

[0011] Combined with this information, the PDS software builds its internal model of the factory and the production processes within the factory. Subsequently, by applying scheduling algorithms to the factory's resources (MOM objects) and this internal factory model of the 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] Now, it can be realized that the TCO of a MOM solution is related to various factors, some of which are often underestimated at the beginning of a project, even a large one.

[0013] The costs are much higher than those strictly related to the MOM solution itself. The MOM solution is hosted on a server, with the HW and SW required from the MES program e.g. Siemens as a prerequisite From an EX FN point of view, both mean additional costs. The SW must be installed - either the SW or its prerequisites, and the required service time depends on the number of servers. This can be high in the case of large projects (both in terms of the number of physical plants and the number of concurrent users).

[0014] Additional costs are related to the maintenance of the SW over time (both the MES SW and its prerequisites): considerable IT and project team service time is required for the installation of updates and patches. This time increases with the number of servers and has a significant impact on the budget as it occurs regularly. On the other hand, this time is also deducted from activities that can provide real business value (such as user support, implementation of new features or increase in user experience).

[0015] The large number of environments also has indirect consequences. The management of the project is more complex for different reasons: The probability of human errors when installing updates and patches increases with the number of environments that must be updated. As a result, troubleshooting problems occurring on a single system becomes difficult, especially when support is required from professionals who are not involved in the update process (such as GTAC).

[0016] Furthermore, the system configuration is complex and expensive in terms of workload. In fact, when multiple plants are within the scope of the project, the personnel of different plants are accustomed to their specific procedures and are less willing to change them, resulting in a large number of configuration and business logic differences between plants, even if they are not really necessary. Usually, customer stakeholders tend to meet these requests to improve general MOM solution user satisfaction.

[0017] The impact of lack of standardization and coordination of functionality across plants on project costs and MOM solution reliability is often underestimated during the requirements analysis phase because it is difficult to isolate. It emerges later in the project evolution when it becomes clear that guiding workers through the change process will minimize the impact on MOM solution users and bring huge benefits to the success of the project. Summary of the invention

[0018] The object of the invention is therefore to define a method allowing to simplify the management of particularly large MES / MOM projects which may involve multiple manufacturing sites and multiple servers requiring strict guidelines regarding keeping patch and update thresholds as low as possible.

[0019] According to the invention, this object is achieved by a method for operating a plurality of production plants using a manufacturing execution system, the method comprising the following steps:

[0020] a) providing central computing hardware as a regional hub for running MES software capable of managing production processes across multiple production plants;

[0021] b) configuring a first manufacturing execution program for a first single factory connected to the regional hub;

[0022] c) creating a respective Manufacturing Execution System for each additional plant by inheriting all configurations of the first Manufacturing Execution System to these additional Manufacturing Execution Systems; and

[0023] d) Configure these additional plants over time with the existing solution in the regional hub without the need to reinstall the software of the Manufacturing Execution System and without the need to reapply some of the configuration that was already performed in the first plant.

[0024] Therefore, this approach provides better value for multi-plant solutions by reducing TCO. In fact, the same number of servers required to host an MES / MOM solution serving a single manufacturing plant in the prior art can now be used to manage multiple plants (e.g. Figure 1 This group of servers constitutes a single MES / MONM solution distributed environment and, depending on the functionality offered by the cloud provider, is hosted by the same regional hub or in any case by a single “virtual data center” in case of a public cloud deployment.

[0025] Preferred embodiments of the invention are given in the appended claims 2 to 12 . BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Preferred embodiments will be described in more detail hereinafter with reference to the accompanying drawings, in which:

[0027] Figure 1 Schematically the setup of a multi-factory concept now (a) and after implementation of the invention (b);

[0028] Figure 2 Schematically common and plant-specific configurations;

[0029] Figure 3 Schematically shared configuration and data multi-tenancy;

[0030] Figure 4 Schemes schematically illustrated for configurations of common and plant-specific deployments;

[0031] Figure 5 Schematically a state machine for a configured factory;

[0032] Figure 6 Schematically deploy and execute the plan;

[0033] Figure 7 A scheme illustratively used for high-level runtime decomposition; and

[0034] Figure 8 Schematic diagram of interoperability. DETAILED DESCRIPTION

[0035] The present invention is part of an MES / MOM solution, which is for example provided by AG EX FN is a brand name for distribution and is designed to provide better value for multi-factory solutions by reducing TCO. In fact, the same number of servers currently required to host a MOM solution serving a single manufacturing plant will be able to manage multiple plants in the future (such as Figure 1 This group of servers constitutes a single MES / MOM solution distributed environment and will be hosted by the same regional hub (or in the case of a public cloud deployment, a single "virtual data center" anyway, depending on the capabilities provided by the cloud provider). Based on customer IT needs, the servers of this MES / MOM solution distributed environment can alternatively be:

[0036] A physical internal server (local to one of the plants);

[0037] Private cloud virtual machines (hosted by a local virtualization environment such as VMWare, local to one of the factories); and / or

[0038] Public cloud IaaS instances (hosted in a public cloud provider data center).

[0039] Figure 1 An idea of ​​the benefits that customers can gain using the multi-factory approach is provided. First, customers who are ready to adopt this approach will be faster in delivering innovations to the factory, since the speed of introduction will be greatly increased. The increase factors shown here have been measured in real projects.

[0040] When MES / MOM projects start to move from a local installation model to a creative centralized installation approach, it has been measured to be three times faster in terms of deployment, and this is of course a huge benefit to customers because they can deploy new innovative features to the plant in a faster way. In addition, there is no need to spend time on complex upgrades of project plants because all plants should be at the same level in terms of solutions and product versions.

[0041] The administration of all systems will be reduced and this is also a benefit from an IT perspective, not only in terms of hardware, but also in terms of IT resources such as database engineers and system administrators that the customer would have to arrange to manage the MES / MOM system.

[0042] Another benefit is of course the overall infrastructure cost, as less hardware is needed to deploy the same number of plants and implement the solution. Finally, with this approach, customers will reduce implementation costs and achieve a coordinated solution template that delivers the same functionality to more plants with slight differences (if needed) for each plant.

[0043] This feature will be referred to as Multi-Plant Concept / Solution / Support in the following. See the first 5 points below:

[0044]

[0045] Point 1: Regional hubs

[0046] The regional hub operates for all plants, and it is up to the user to select the appropriate regional hub from an infrastructure perspective (CPU, RAM, disk, redundant network, etc.) In this way, the same number of servers that currently need to host a MOM solution serving a single manufacturing plant can manage multiple plants.

[0047] The servers of this MES / MOM solution distributed environment can alternatively be:

[0048] A physical internal server (local to one of the plants);

[0049] Private cloud virtual machines (hosted by a local virtual environment such as VMWare, local to one of the factories);

[0050] Public cloud IaaS instances (hosted in a public cloud provider data center)

[0051] All different stations connected to the same regional hub benefit from:

[0052] -Share the same solution configuration

[0053] - Having separate data in different physical databases

[0054] - Have separate SW processes for business logic execution and data query

[0055] Running a multi-factory scenario has many benefits:

[0056] - Reduced costs due to the limited number of servers to be installed and on which updates and patches must be applied.

[0057] -The overall architecture is simplified, reducing any human errors during system calibration.

[0058] - Reduced the rollout time of new factories.

[0059] - Standardization and harmonization are achieved, which means less configuration work.

[0060] On the other hand, the multi-factory scenario ensures:

[0061] Business continuity: There is no downtime at the plant during updates when other plants need to be stopped and during the rollout of new plants.

[0062] Security and availability: You can view and modify only the data relevant to your plant.

[0063] Robustness: The performance and behavior of one plant is not affected by workload peaks or eventual problems at other plants.

[0064] Multiple languages: You can see both the user interface and data in your own language.

[0065] A better way to configure a multi-plant scenario is to start configuring a single plant connected to a regional hub. Therefore, the creation of the first plant is mandatory. Then, any additional desired plants can be created. These additional plants can be configured over time with the existing solution in the regional hub, without having to reinstall the product and reapply some of the configurations already performed in the first plant. In fact, some configurations are common to all plants, both from an environment and a solution point of view. This means that once performed in one plant, they are automatically applied to all available plants, regardless of when the plant was created. In contrast, other configurations are plant-specific and can be performed according to the needs of the plant.

[0066]

[0067]

[0068] Process data that are relevant to different plants will only be visible to users enabled for the relevant plant. All process data including master data (e.g. materials, master recipes or process bills) are stored in different repositories. If some process data is relevant to multiple plants, it must be exported and imported between the different plant repositories. Of course, there may also be a section in the central database that is shared between the various plants.

[0069] Configuration Process

[0070] Users can create one or more factories served by a centralized regional hub.

[0071] Configure the environment by defining the first factory

[0072] (Optional) Configure and deploy the manufacturing solution for the first factory (if required).

[0073] Additional factories are added via the factory configuration tool, note that there are generic configurations and factory specific configurations.

[0074] Configure and deploy manufacturing solutions to additional plants (see How to Manage Manufacturing Solutions in a Multi-Plant Scenario)

[0075] Key Point 2: How to manage manufacturing solutions in a multi-factory scenario

[0076] There is only one Manufacturing Solution for all available plants. In practice, the user must create and configure that Manufacturing Solution for the first plant. Then, as additional plants become available, that Manufacturing Solution is automatically inherited by any additional plants with all the common configurations implemented. At this point, the user can apply the desired plant-specific configurations based on plant needs. This promotes coordination while still allowing flexibility at the plant level when needed.

[0077] Once the manufacturing solution is configured, users can deploy the manufacturing solution factory by factory and start the manufacturing solution on the runtime host and update the database structure. To do this, the Host Management page will display all available factories, regardless of the factory the user is working on. When the host is stopped, all factory services are automatically stopped. The advantages of parallel deployment (see Point 3: Parallel deployment) are:

[0078] -Deployment to a factory without affecting other factories.

[0079] - Scheduling when the changes will be applied based on factory needs, such as when a shift at one factory does not coincide with another factory's shift.

[0080]

[0081] MES / MOM solutions also allow:

[0082] - Update the database structure on a factory-by-factory basis

[0083] - Launch manufacturing solutions on a factory-by-factory basis on a runtime host

[0084] -Stop a host to continue maintenance operations, such as installing security patches. When you stop a host, all factory services are automatically stopped.

[0085] More details are described in Point 4: Avoiding Single Points of Failure

[0086] Point 3: Parallel deployment

[0087] Since it is in the interest of each site to plan solution change deployments based on their production hours, builds and solution deployments are managed per plant. Generally, there is no downtime for a plant during updates to other plants that require downtime and during rollouts of new plants. As a result, it is possible to:

[0088] -Change solution configuration

[0089] - Build the solution based on the factories to create a package with global and factory-based configuration (in the example below, changes are made for factory N).

[0090] -Deploy the above configuration

[0091] - Perform DB Scaffolding (if required) only for that specific factory.

[0092] From a technical point of view, all executed configurations (security, web ui applications, data archiving, etc.) are stored in the configuration database and contextualized against the factory. The configurations and artifacts required for runtime are merged into the management repository that creates the deployment package.

[0093] The deployment phase then pulls the deployment package from the management repository into the local runtime configuration. In particular, the deployment phase is executed locally by each runtime node (see Figure 4 ). Specific commands are responsible for obtaining a factory-based deployment package, copying all relevant artifacts (assemblies, metadata files, etc.) to the relevant runtime locations, and updating the runtime database. The following scheme shows how to manage registration files and how to divide configuration according to factories.

[0094]

[0095]

[0096]

[0097] The specific commands on each node that control the deployment phase are:

[0098] Stop: This operation stops the factory-based business workers and service layers

[0099] Deploy: A new version of the solution consisting of the common and factory-based configurations is copied locally. Depending on the extent of the changes, a deployment may or may not require stopping and putting the solution for that factory into maintenance state.

[0100] Start: This operation resets maintenance and starts the factory-based business workers and service layer.

[0101] Update Database: This operation creates / updates the runtime and (if configured) archives the factory-based database.

[0102] Disable: Excludes the selected host from the runtime scenario: the host status is set to Offline. This operation is only possible on stopped hosts and will affect all configured factories.

[0103] Enable: Enables any previously disabled host. This action affects all configured factories.

[0104] With the introduction of multiple factories, a state machine is available for each factory, as each factory can assume the state of the state machine during its own solution lifecycle.

[0105] Tip 4: Avoid single points of failure

[0106] Endpoints, software runtime processes, and tenants are specific to each plant to avoid the performance and behavior of one plant being affected by workload spikes or eventual issues in other plants.

[0107] Figure 1 : Deployment and Execution

[0108] The following diagram depicts the main runtime components and their dependencies.

[0109] The components are divided into engineering and management components responsible for the configuration and deployment of the solution and solution runtime components that represent the solution running the MES business logic. In the case of using the same target environment to manage multiple plants, one host can run multiple runtimes of the solution, one for each plant. The life cycle of each instance is completely independent of the other instances, and each runtime accesses only its own data.

[0110] Regarding the runtime of the solution deployed according to the factory (see Figure 7 )”

[0111] The upper client is the UI application that interacts with the system throughout the service layer. Since the runtime application is configured according to the factory, each screen communicates via its own runtime endpoint (runtime and data archive). The service layer is responsible for adapting the backend functionality to the client. It does not perform any logic.

[0112] Workers are responsible for executing logic and they are decoupled from the service layer via the service bus. Runtime worker instances are based on factories.

[0113] At the bottom of the diagram, repositories are depicted. These repositories can be accessed directly from the service layer to read data. Through factory specific endpoints, the system automatically reads data from the correct tenant.

[0114] Workers can modify the data on it. Even in this case, factory-specific workers automatically read and write data with the correct tenant.

[0115] Based on the above, in a multi-factory environment:

[0116] Create an application pool for each factory. The application pool manages the corresponding applications under sit-svc and sit-arch, and has other application pools with the same identity defined by the MES / MOMO solution.

[0117] Under the sit-svc and sit-arch virtual folders, create a new virtual folder with the Id of the factory and this folder contains the Web Application (named "application") and inside:

[0118] Symbolic link to %SITUNIFIEDSYSTEMROOT% svc-runtime\bin folder App_offline.htm

[0119] web.config

[0120]

[0121] For the corresponding physical structure, two new folders plants-web and plants-arch are created, both available in the %SITUnifiedSystemDatal% folder. The folder structure is as follows:

[0122]

[0123] The Web.config file contains information about the factory:

[0124] <appsettings>

[0125] <add key="Plant!d"value="<Plant Id> ">

[0126] < / appSettings

[0127] The same structure was added for the plants-arch folder:

[0128]

[0129]

[0130] Creating a dedicated runtime and archiving endpoints

[0131] (http(s): / / <hostname> / si t-svc / <plantid> / application / <appname> / odata / ; where <plantid>is mapped to a virtual directory, and the application is a Web Application). See below for a list of endpoints in a multi-factory environment.

[0132]

[0133]

[0134] Due to the above dedicated endpoints, any third-party system can easily access the data owned by the factory due to its standard OData layer interface (MES / MOM solution service layer).

[0135] The business logic is called due to its REST API.

[0136] Create a corresponding virtual host on the RabbitMQ server application. Following the RabbitMQ convention, each virtual host provides logical grouping and resource separation, and connections to a virtual host can only operate exchanges, queues, bindings, etc. in that virtual host.

[0137] Dedicated tenants are designed to host the MES data for each plant. The multi-tenant architecture avoids polluting a plant with data related to another site. Thus, each user can only see and can modify data related to his / her plant.

[0138] After deploying the solution on the selected factory, the solution configuration is deployed on the above mentioned folder and the dedicated business workers are instantiated.

[0139] Key Point 5: Diagnosis and Supportability

[0140] The trace and log information generated by the central MES system includes explicit information about the plant it is involved in. In this way, it is easy to troubleshoot what is happening in a given plant, discarding traces and logs of other plants that are not relevant.

[0141] Test manufacturing solutions via OpenAPI tools

[0142] Once your manufacturing solution is deployed and launched, users can inspect and test the public commands exposed by the solution with the help of any OpenAPI tool such as Swagger or Postman.

[0143] During the solution build operation, the system generates a set of meta descriptor files that apply the OpenAPI specification v3.0.3. For multi-factory environments, users can:

[0144] View the commands for the solution: Any OpenAPI tool can interact directly with Foundation APIs in any of the following ways:

[0145] By launching the OpenAPI tool on the remote machine and accessing http: / / <hostname> / sit-svc / <plantid> / Application / $openapi endpoint.

[0146] By launching the OpenAPI tool locally on the MES / MOM solution host and opening the meta descriptor.

[0147] View commands for each application: Inspect commands for each application and related extension applications included in the solution directly from any OpenAPI tool in one of the following ways:

[0148] By launching the OpenAPI tool on the remote machine and accessing the different endpoints of each application as follows: http: / / <hostname> / sit-svc / <plantid> / Application / <appname>

[0149] / odata / $openapi

[0150] By launching the OpenAPI tool locally on the Opcenter EX FN Foundation host and opening the meta descriptor for each required application at the following path:

[0151] %ProgramData%\Siemens\SimaticIT\Unified\Deploy\metadata\ <plantid>\<AppPrefix.AppName> .openapi.json file

[0152] Monitoring worker and host status

[0153] Understanding the status of your MES / MOM solution environment is critical to ensuring system reliability and stability. Information about system health and performance not only helps you confront and resolve issues, but also ensures that actions are taken with confidence.

[0154] One of the best ways to gain this insight within a system is with the help of a robust monitoring system that collects metrics, visualizes data, and alerts operators when problems occur. To this end, the platform provides dedicated endpoints that can be queried from custom web client applications or monitoring tools (e.g., Zabbix) to retrieve information about the environment's hosts and running workers. For a multi-factory environment, a query is performed by sending a GET request specifying the factory Id:

[0155] http: / / <hostname> / sit-svc / monitoring?plantId= <myplantid>< / myplantid> < / hostname> .

[0156] Point 6: How to manage factory differences

[0157] Building on the previous technical features, it will be possible to configure the system to manage plant differences.

[0158]

[0159] Compared to known existing solutions (including the DELMIAApriso solution), the Opcenter EX FN solution addresses the following limitations: Setup and customization per plant: The customer needs to coordinate the solution configuration between plants, but at the same time he / she wants flexibility in configuring for plant specific use cases (when needed).

[0160] Single point of failure: The performance and behavior of one plant is not affected by workload peaks or eventual problems in other plants. In addition, there is no downtime in the plant during updates of other plants that require downtime and during the rollout of new plants. When an MES update is required, there is no need for a synchronized production stop in all plants: the engineering and deployment model must be plant-specific. The customer wants to schedule when changes will be applied based on the needs of the plant, for example when a shift change in one plant may not coincide with a shift change in another plant. The IDs of MES data must not be unique across plants: each user can only see and can modify data relevant to his / her plant. In addition to this, the customer requires that MES objects with the same ID be identified even if they belong to different plants. Dassault Solution: Pros and Cons vs. Existing Solutions on the Market (see summary below; for more information, see the attached slides of AES-Introduction-to-DELMIA-Apriso-Infrastructure-Hardware-and-Virtualization).

[0161] DELMIA Apriso solution; strengths (highlighted in green) and weaknesses (highlighted in red).< / plantid> < / appname> < / plantid> < / hostname> < / plantid> < / hostname> < / plantid> < / appname> < / plantid> < / hostname> < / appsettings>

Claims

1. A method for operating a plurality of production plants by means of a manufacturing execution system, the method The following steps are involved: a) providing central computing hardware as a regional hub for running MES software capable of managing the production process across the plurality of production plants; b) configuring a first manufacturing execution system for a first individual factory connected to the regional hub; c) creating a respective Manufacturing Execution System for each of the other plants by inheriting all configurations of the first Manufacturing Execution System to these other Manufacturing Execution Systems; and d) Configuring these additional plants over time with the existing solution in the regional hub without the need to reinstall the manufacturing execution system's software and without the need to reapply some of the configuration already performed in the first plant.

2. The method according to claim 1, in, Some configurations are common to all factories, where once executed in one factory, they are automatically applied to all available factories, regardless of when the factory was created.

3. The method according to claim 1 or 2, in, Additional configuration is defined at a plant-specific level and performed as per plant needs.

4. The method according to any one of the preceding claims, in, The regional hub operates the Manufacturing Execution System for all factories, and the user selects a suitable regional hub from an infrastructure perspective, such as available CPU, RAM, disk, redundant network, etc., therefore, any server service used in the regional hub to host the software of the factory-specific Manufacturing Execution System solution and manage the multiple factories.

5. The method according to claim 4, in, Server alternatives for the distributed environment of the MES / MOM solution are: a) a physical internal server local to one of the factories; b) a private cloud virtual machine local to one of the factories, hosted by a local virtual environment such as VMWare; c) Public cloud IaaS instances hosted in public cloud provider data centers.

6. The method according to any one of the preceding claims, in, Once the Manufacturing Execution System solution is configured, it is deployed plant by plant and started on a runtime host and the database structure is updated.

7. The method according to any one of the preceding claims, in, The host management page is able to display all available plants, regardless of the plant the user is working on, and preferably, when the host is stopped, all plant services for a particular plant are automatically stopped.

8. The method according to any one of the preceding claims, in, Process data related to different plants are only visible to users enabled for the relevant plant.

9. The method according to any one of the preceding claims, in, All process data including master data such as materials, master recipes or process bills, bills of materials are stored in different data repositories.

10. The method according to claim 9, in, For the case where some process data are related to multiple plants, the process data are exported and imported between different plant repositories.

11. The method according to any one of the preceding claims, in, Part of the central database of the regional hub is shared among the various factories.

12. The method according to any one of the preceding claims, in, All configuration performed, such as security, web UI applications, data archives, etc. are stored in the configuration database for each factory and contextualized; the configuration and artifacts required for runtime are merged into the management repository that creates the deployment package.

Images