Method of operating plurality of edge production resources by manufacturing execution system

Abstract

It is an object of the present invention to provide a method for operating a plurality of edge production resources by a manufacturing execution system that requires less investment on a centralized MES architecture and ensures low latency in data transmission and high throughput of manufactured products. According to the invention, this object is achieved by a method for operating a plurality of edge production resources by a manufacturing execution system, the method comprising the steps of: a) providing a plurality of interlocking edge applications and tracking and tracing edge applications to the production resources at a plant level; b) providing a plurality of higher-level interlocking applications and higher-level tracking and tracing applications, which are also related to the edge production resources, at the elevated level of supervision wherein the edge application provides only a subset of functions compared to a central higher-level application of the elevated level of supervision; c) creating a process manifest at the elevated supervision level, thereby defining a plurality of products to be produced on at least one of the edge production resources; d) loading data for a subset of the plurality of products defined in the production process list into caches of the corresponding edge production resources; e) producing, by the respective edge production resources, a subset of the plurality of products according to the defined process list; f) during the production of the subset, exchanging data between the edge application and the higher layer application according to the functionality defined in the edge application and the higher layer application; g) after completion of the production of the subset of products, deleting all data relating to the subset of products in the cache of the edge production resources, and h) in the higher-level applications, processing data relating to the subset of products according to functions provided by the higher-level applications. Thus, the method provides a way to distribute tracking and tracing as well as interlocking functions in an intelligent manner on the MES architecture, thereby benefiting from small and flexible edge structures as well as reliable and powerful higher-level structures. In particular, the deletion of all data related to finished products enables the edge applications to be "reset" and refresh them in terms of functionality and storage for the production of the next batch of products.

Description

[0001] The present invention relates to a method for operating a plurality of edge production resources by a manufacturing execution system.

[0002] In the field of process automation and process monitoring, standard automation systems for controlling the widest range of production resources, machines and plants (MOM objects) are state-of-the-art. This technology particularly covers the development of Siemens in the field of Manufacturing Operations Management (MOM) through its The broad product range offered by the product portfolio. A wide range of products for solving the relevant technological tasks (such as counting, measurement, positioning, motion control, closed-loop control and cam control) enhances the performance capabilities of the appropriate process controller. A variety of configurations enable flexible machine concepts.

[0003] In this context, there is a wide range of IT solutions that connect the actual hardware close to the technical and / or logistical processes to the application layer on the client side that drives the installation.

[0004] Consequently, Manufacturing Execution Systems (MES) were developed to meet all the requirements of a Service-Oriented Architecture (SOA) for seamless integration into Totally Integrated Automation (TIA). This success is based on a plug-and-play architecture, where individual functions can be configured and easily combined with one another, simplifying the complex structures required to control manufacturing plants, for example. These IT solutions are governed by various industry standards, such as the established ANSI standards ISA-95, ISA-88, and ISA-106, specifically for discrete, batch, and continuous industries.

[0005] These requirements often require fairly complex and sophisticated software solutions within the backbone network to achieve a fully integrated automation approach. For this reason, software engineers often use production modeling software to define the factory model and its standard operating procedures, and create corresponding new software using a high-level graphical language that identifies the workflow of activities within the software.

[0006] The string / term in the high-level graphical language is then translated into a client-based software language that can be executed at the machine language level. This translation requires significant programming effort and rigorous testing to check whether the translated program behaves consistently with the original string / term in the high-level graphical language.

[0007] Nonetheless, there is a continuous need to minimize the risk of non-compliance and achieve cost-effective compliance. Therefore, there is a need to integrate quality control into the manufacturing of products in discrete, process or hybrid industries. However, ensuring quality during each stage of manufacturing is challenging. On the one hand, production systems should achieve several key performance indicators (KPIs) such as production throughput, short cycle time, capacity utilization, first-time- right rate or overall equipment effectiveness (OEE). On the other hand, they need to ensure business continuity at all times and avoid production line downtime.

[0008] The state of the art follows established ANSI standards such as ISA-95, ISA-88 and ISA-106 for discrete, batch and continuous industries, respectively. The consensus is to use a rather centralized architecture where there are typically three different levels:

[0009] (i) a centralized enterprise resource planning (ERP) that usually resides in a remote location supervising multiple factories,

[0010] (ii) a centralized manufacturing execution system (MES) at the factory level, and

[0011] (iii) a control system that collects production data at the shop floor.

[0012] Figure 1 An overview of such a system architecture representing a MES that controls and monitors the entire manufacturing process that takes place in work centers such as single production lines and / or production cells is shown. With the real-time architecture and the powerful traceability of the MES, manufacturers implement interlocked material verification of products and processes according to defined product routes and quality. Therefore, they can detect possible faults during each stage of manufacturing in real-time and provide early corrective measures. For example, if a quality tolerance is outside the acceptable range, the MES stops production and subsequently records traceability and links it to the pedigree of the product being produced for real-time or later analysis.

[0013] For larger factories with hundreds of production machines, the centralized interlocking mechanism of the MES requires horizontal and vertical scaling of computing resources to address a large number of interlocking checks per production step (i.e., work operation, production segment). To ensure good response times to these requests, thereby achieving high production throughput and short cycle time KPIs, a low-latency / high-throughput network infrastructure must be established between the production machines and the central MES, which can even be deployed in a public or private cloud. However, the total cost of ownership of such a network infrastructure, i.e., installation, configuration, commissioning and maintenance, is high. Moreover, the MES must meet high availability requirements to avoid any production downtime. Finally, all such requirements regarding low latency, high throughput and availability increase the total cost in a centralized MES.

[0014] It is therefore the object of the present application to provide a method for operating a plurality of edge production resources by a manufacturing execution system, which requires less investment into a centralized MES architecture and which guarantees low latency in data transmission and high throughput of manufactured products.

[0015] According to the present application, this object is achieved by a method for operating a plurality of edge production resources by a manufacturing execution system, the method comprising the steps of:

[0016] a) providing a plurality of interlocked edge applications and a track and trace edge application to production resources at a shop floor level;

[0017] b) providing a plurality of higher level interlocked applications and higher level track and trace applications at a promoted supervisory level, which are also related to the edge production resources, wherein the edge applications provide only a subset of the functionalities compared to the applications at the central higher level of the promoted supervisory level;

[0018] c) creating a process list at the promoted supervisory level, thereby defining a plurality of products to be produced on at least one of the edge production resources;

[0019] d) loading data for producing a subset of the plurality of products defined in the process list into a cache of the respective edge production resource;

[0020] e) producing the subset of the plurality of products by the respective edge production resource according to the defined process list;

[0021] f) exchanging data between the edge applications and the higher level applications according to the functionalities defined in the edge applications and the higher level applications during production of the subset;

[0022] g) deleting all data related to the subset of products in the edge production resource cache after completion of the production of the subset of products, and

[0023] h) processing data related to the subset of products in the higher level applications according to the functionalities provided by these higher level applications.

[0024] The present method thus provides a way of distributing track and trace and interlocked functionalities in an intelligent way on a MES architecture, thereby benefiting from small and flexible edge structures and reliable and powerful higher level structures. In particular, deleting all data related to the produced products enables to "reset" the edge applications and refresh them in terms of functionalities and storage for the production of the next batch of products.

[0025] Preferably, only data related to the current product and to products to be produced in the future are downloaded in the cache of the edge production resources.

[0026] Another preferred embodiment of the present application can provide a synchronization mechanism that is able to send periodic updates from edge applications of a first plurality of edge production resources to a higher level application that then publishes the newly received updates to topics that are subscribed by edge applications of a second plurality of other edge production resources.

[0027] Preferably, the publish / subscribe mechanism can be combined with a caching mechanism, wherein received data is cached at the location of the deployed edge application before a specific production start.

[0028] In another preferred embodiment of the present application, aggregated data is transmitted from a higher level track and trace application down to edge applications, and wherein the higher level track and trace application handles all work orders, and wherein the aggregated data is extracted into a plurality of groups related to production lines at the shop floor level, enabling edge applications to subscribe to data of only the respective edge production resources of the respective production line.

[0029] Alternatively or additionally, the aggregated data can be categorized into a plurality of topics based on a bill of process (BOP) of all products to be manufactured, providing any edge track and trace application the possibility to subscribe to topics of aggregated data only for products that need to be able to perform operations by edge production resources in a specific production line.

[0030] Preferred embodiments of the present application are given in the dependent claims.

[0031] The preferred embodiments are described in more detail below, with reference to the attached drawings, which depict:

[0032] Figure 1 schematically represents an overview of a system architecture of an MES system that controls and monitors the entire manufacturing process that takes place in work centers, i.e. production lines or production units;

[0033] Figure 2 schematically shows an example of a hybrid or layered deployment of an MES application with a modular layered design for quality assurance and track and trace of manufactured products;

[0034] Figure 3 schematically shows an example of data model differences in the various levels of an MES; and

[0035] Figure 4 schematically shows data caching on edge devices at the shop floor level.

[0036] This invention represents a modern, modular architecture for a Manufacturing Execution System (MES), based on a microservices architecture. This architecture enables the decomposition of various MES functions into applications. In fact, modular MES applications can be independently developed and deployed anywhere within the deployment scope: in the cloud, on-premises, and on edge devices. Due to the interlocking and traceability (also known as track and trace) nature of MES, it is highly desirable to run and maintain these functions at the shop floor level in production to achieve low latency, high throughput, and increased availability of MES data.

[0037] Therefore, the present invention provides interlocking and track and trace functionality as separate applications, deploying them on edge devices and enabling them to run directly on the shop floor. This concept aligns particularly well with the fundamental premise of the edge computing paradigm, which is to move functionality closer to the edge of the network to improve response times and achieve low latency. Furthermore, the distributed nature of the applications enables the deployment of multiple instances at the edge level of the MES architecture, while also enabling instances to run at higher levels, either at the factory level or in the cloud.

[0038] Figure 2 Depicts an example of a hybrid or tiered deployment of an MES application with a modular, tiered design for quality assurance and track and trace of manufactured products. In the diagram, there are two work centers on the shop floor, each with interlocking applications and track and trace applications running on their own edge devices, and a central track and trace application and quality management application running at the regional, plant, or enterprise level.

[0039] Especially in a tiered deployment, the application instances running on the edge devices may differ in functionality and therefore in data models and APIs from instances running at higher levels. Figure 2 In the Track & Trace instance, a dedicated work center receives traceability data only for each product instance processed in that work center. An application instance running in a higher-level layer doesn't necessarily receive traceability data for each product instance directly from a machine or human operator. Instead, it aggregates the data collected in each edge-tier instance and provides a higher-level view.

[0040] Figure 3 The following provides examples of how data models differ at different layers. Here are specific examples of tracking and tracing data models at different layers. For example, the Work Order entity in the application data model, deployed at a higher layer, can track the entire production of a product batch if deployed at the regional level, or track information from the entire enterprise if deployed at the enterprise / plant level. However, the Product entity in the edge application data model only stores tracking data for a single product within a batch during production within the corresponding work center. Individual products within the batch are identified by their serial numbers.

[0041] In addition, according to a particularly preferred feature of the present invention, the amount of data and the data retention time in edge and higher-level applications are different. Figure 3 In the example, an application deployed on a higher layer may be able to save data on all products of a work order (batch) depending on the layer and its capabilities. However, since at the edge layer, the tracking and tracing application is deployed on a resource-constrained device, it can only store a limited amount of data. Therefore, the edge instance can store data on the products processed in the corresponding work center for a limited time, and the stored data changes with the production progress. For the interlocking function, it is assumed that the real-time data required by the interlocking edge instance can be provided by the tracking and tracing application running locally on the edge. Therefore, the edge application can tolerate temporary interruptions in the connection between the edge and higher layers because the real-time data is mostly available locally.

[0042] In order to develop and customize tracking and tracing and interlocking functionalities at various deployment levels, the model-based design and metadata-driven architecture of modern MES applications are utilized. Given a default configurable model of, for example, tracking and tracing functionality, a low-code engineering approach is used to customize and extend the default functionality to various hierarchical levels. Note that edge instances can also be different from each other. More specifically, customization involves the adaptation of data entities, message objects (discussed below), and API endpoints. Due to the limited resources on edge devices, edge applications only provide a subset of the functionality of central, higher-level applications as described above. Therefore, edge applications are referred to as or developed as sub-models of higher-level applications.

[0043] Publish / subscribe mechanism to synchronize edge and higher layers

[0044] In order to function properly, interlocking applications and track and trace applications require data from other MES applications or systems running at higher levels (such as areas or plants). For example, they need up-to-date information about active work orders or quality measures, as well as information about the status of other work centers within the shop floor. In addition, to maintain the benefits of a central MES system and reduce the possibility of data loss due to edge device failures, information must be sent regularly from applications deployed at the edge to higher-level instances, for example, in the form of time-based data updates or updates based on the number of batches / lots of products. For the former, the update granularity can be chosen based on a certain time, while in the latter case, we can send updates after a certain amount of products has been processed in a given batch / lot. Therefore, the publish / subscribe communication pattern is used to enable deployed applications to subscribe to information / data from higher levels that are only relevant to the managed production machines (and vice versa), using specific logical channels for publishing messages called topics.

[0045] A communication mechanism based on the aforementioned publish / subscribe communication pattern is proposed to enable information exchange between applications deployed at the edge and other layers. The proposed mechanism has two goals: first, it enables edge applications to retrieve relevant data about operations, products, and materials (see Figure 3 ) takes into account the capabilities of the managed production line—that is, what operations the line can perform, for what products, and what materials are required to perform these operations. Secondly, it enables edge applications to send production updates to higher-level applications. Therefore, specific topics are created to transmit only relevant data. Topics are needed to send and receive data to applications deployed at higher levels. However, the creation of such topics differs between the two data transmission directions.

[0046] Here, we first consider the scenario where data is transferred from a higher-level tracking and tracing application down to an edge instance (see Figure 2 Since the higher level track and trace application handles all work orders (see Figure 3 ), so the entire data cannot be published to a single topic. Considering that the subscribers reside on resource-constrained edge devices, using one topic would be impractical. Therefore, the aggregated data needs to be extracted into multiple groups related to each production line at the shop floor level. This is a key step to enable edge applications to subscribe only to relevant data. The first approach can be based on creating a separate topic for each production line. In this example (see Figure 2 ), the algorithm creates two different topics, such as / workcenters / ProductionLineA / requests and / workcenters / ProductionLineB / requests, each of which consists of data related to each production line, such as the requested operation, related materials, and target products.

[0047] In the second (more advanced) approach, the algorithm creates multiple topics based on the bill of process (BOP) for all products to be manufactured, such as / products / <id> / products / * / bop / operations / <operation_name> provides the possibility for any edge tracking and tracing application to subscribe to data only for the products that need the operation that can be performed by the production machines in a specific production line. An example of such a subscription can be / products / * / bop / operations / assemble (the asterisk * means any product ID) that enables an edge application in a production line with assembly robots to get data only for the products that need to be assembled. The second approach provides better production flexibility, agility and reduces engineering effort, as which production line performs the required work order operations is done automatically at runtime based on the actual operation requirements and the availability of production machines. In both approaches, when a work order for a new product is created in a higher level tracking and tracing application, the edge tracking and tracing applications will automatically receive and cache all the required data before the physical production on "their" production line starts.

[0048] In the second transfer data scenario, all the data created in the edge level (e.g. results of performed operations, collection of throughput) has to be published to the higher level in general. Therefore, one single topic can be created for each production line where the whole information that has been stored locally on the edge device is added, e.g. / workcenters / ProductionLineA / responses.

[0049] Caching mechanism for providing data locally at the edge

[0050] In order to benefit from deploying applications on edge devices, it has to be ensured that each application has local access to the required information / data - retrieving information from higher levels each time does not shorten the response time. To improve on this, the above mentioned publish / subscribe mechanism is combined with a caching mechanism, where the received data is cached at the location of the deployed application before a specific production starts (see Figure 4 ). As the information for each application is filtered, the limited resources of the edge device can store everything that is needed for the application of one certain product. However, it can be the case that multiple different products are produced on the same set of production machines controlled by one single application. Therefore, the information needed for each single product has to be downloaded, eventually reaching the limit of the cache and increasing the likelihood of cache misses.

[0051] The possibility of cache misses can be minimized by adopting the solution proposed below, in which only the information required for the current and future products is saved in the cache. This solution monitors the information available in the cache and the products already produced, and before production starts, all the products that will be produced on the relevant production machine are known. In this case, every time a product is completed, the information it required is deleted and new information for the future products is retrieved from the higher level.

[0052] For example, it can be assumed that a trace and trace application and an interlock application are deployed on an edge device that supervises a plurality of production machines that are part of the production steps of N different products. Therefore, before production starts, all the information required for all the products must be retrieved and stored locally in the cache. However, due to limited resources, only a part of the information, i.e. the information required for the first K products, can be stored locally at this time. It must be noted that if the cache is not somehow updated at runtime, some products will cause an increase in production time due to cache misses, forcing the production device to request the required information from the higher level. However, with this solution, there is always a buffer of information required for the next K products, so that no cache misses occur. In order to keep this buffer in the cache, when the production of the first product is completed, the information stored in the cache related to this first product is deleted and the information required for the K+1 products is retrieved from the application at the higher level.

[0053] Note that in the example above we considered the most common scenario, i.e. the products can only be produced using the production machines supervised by one instance of the trace and trace application and the interlock application. However, a situation can arise in which a product requires specific production machines supervised by a separate set of applications. For example, in Figure 2 there are two production lines A and B, each of which has a different interlock and trace and trace instance deployed. Suppose a product must be produced that requires both production lines, it must be noted that in this case the product has only one bill of process (BOP). Therefore, one needs to ensure that when the product reaches production line B, the progress made on production line A is known by the application deployed on production line B, one is not interested in the details of the entire history of the product, but in the last step completed. Otherwise, the interlock application cannot check the quality of the product correctly with the old information received at the start of production, and if the progress is not synchronized, the interlock application will not allow the production to continue, as the first part of the bill of process is missing.

[0054] Here, the proposed synchronization mechanism can be used to track the progress on multiple application instances by propagating the required information. As mentioned before, with our synchronization mechanism, regular updates about the progress of a product on production line A can be sent to the higher level. The higher level application then publishes the newly received update to the topic that the application of production line B is subscribed to. Thereby, the information of production line B can also be updated.

[0055] However, there is one edge case that has to be considered, depending on the frequency of the regular updates, it can happen that the progress update is sent while there is at least one process left to be completed on production line A. Therefore, the application deployed on production line B will only have a partial update of the progress, resulting in an incorrect quality check of the first process completed in production line B. To solve this potential problem, it has to be ensured that the update is sent to the higher level application after the interlocked application of production line A approves the last available production step on this production line. Therefore, production line B will be updated with the correct progress including the last step completed in production line A.

[0056] It is worth mentioning that with the proposed caching and synchronization mechanism, the probability of a cache miss is significantly reduced. For example, because of the use of the publish / subscribe communication pattern, it can be determined that the relevant data transferred between the two production lines A and B is faster than the time required to transfer the physical product between the two production lines. Therefore, when the product arrives at production line B, the two instances of tracking and tracing and interlocking will have the latest information about the product saved in the cache, so the production can continue without any delay.

[0057] However, there can still be cases where a cache miss cannot be avoided, i.e. production line A has completed the work on the product and the product is ready to continue on production line B. In this case, the relevant information is sent to the higher level application, which eventually stores the information in the cache of production line B. However, the worker can observe that the product has a problem and takes it away to fix the problem. During this time, several other products are produced, changing the cache information of production line B. When the worker puts the repaired product on production line B to continue the production, the cache will not have the information required for this product, so it is necessary to retrieve the information from the higher level application, introducing an additional delay due to the cache miss in this less common case.

[0058] In summary, in the present invention, edge computing is used, which requires the scaling down of MES functionality to resource-constrained edge devices. Also, distributed computing is used, which enables running applications on the edge and in the cloud, the communication mechanism publish / subscribe, and finally, caching and data replication.< / id>

Claims

1. A method for operating a plurality of edge production resources by a manufacturing execution system, the method comprising the following steps: a) Provide multiple interlocking edge applications and tracking and tracing edge applications to production resources at the shop floor level; b) providing a plurality of higher-level interlocking applications and higher-level tracking and tracing applications also related to said edge production resources at an elevated supervisory level, wherein said edge applications provide only a subset of functionality compared to the central higher-level applications of said elevated supervisory level; c) creating a process manifest at the elevated supervisory level defining a plurality of products to be produced on at least one of the edge production resources; d) loading data for producing a subset of the plurality of products defined in the process list into a cache of a corresponding edge production resource; e) producing a subset of the plurality of products by the corresponding edge production resource according to a defined process list; f) exchanging data between the edge application and the higher-level application during production of the subset according to functions defined in the edge application and the higher-level application; g) after completing production of the subset of the plurality of products, deleting all data related to the subset of products in the cache of the edge production resource, and h) processing, in the higher-level applications, data relating to the subset of the plurality of products according to functionality provided by the higher-level applications.

2. The method according to claim 1, wherein In the cache of the edge production resource, only data related to the current product and future products to be produced are downloaded.

3. The method according to claim 1 or 2, wherein: A synchronization mechanism is applied to send periodic updates from the edge applications of the first plurality of edge production resources to the higher-level application, which in turn publishes the newly received updates to topics to which the edge applications of the second plurality of other edge production resources subscribe.

4. A method according to any one of the preceding claims, wherein The publish / subscribe mechanism is combined with a caching mechanism, where the received data is cached at the location of the deployed edge application before a specific production starts.

5. A method according to any one of the preceding claims, wherein Aggregate data is transmitted downward from a higher-level tracking and tracing application to the edge application, and wherein the higher-level tracking and tracing application processes all work orders, and wherein the aggregate data is extracted into multiple groups related to the production line at the shop floor level, thereby enabling the edge application to subscribe only to data for the corresponding edge production resources for the corresponding production line.

6. A method according to any one of the preceding claims, wherein Based on the Bill of Process (BOP) of all products to be manufactured, the aggregated data is categorized into multiple topics, thereby providing any edge tracking and tracing application with the possibility to subscribe to topics of the aggregated data only for the following products, which need to be able to be operated by the edge production resources in a specific production line.

7. The method according to claim 8, wherein The edge applications in the production line including the assembly robot only download topics that provide data only for products that need to be assembled by the assembly robot.

Images