Hybrid operation of production units in a hybrid plant

Abstract

The invention provides a method of integrating a module into a hybrid modular factory comprising a discrete manufacturing part and a continuous manufacturing part. The method comprises integrating the discrete part into the continuous part, comprising constructing (401; 501) at least one module definition file (400, 500) mapping one or more discrete part cells (202) of the discrete part to a continuous part module (102) and importing (402; 502) the module definition file (400, 500) into a orchestration layer (108) of the continuous part. Alternatively, the method comprises integrating the continuous part into the discrete part, comprising constructing one or more interfaces (610) representing each continuous part module (102) as one or more corresponding discrete part cells (202).

Description

Technical Field

[0001] This invention relates to integrating modules into modular factories, such as hybrid modular factories. Background Technology

[0002] In process industries, Modular Type Packaging (MTP) is an established standard used to describe module functionality and regulate communication between modules and orchestration systems. In discrete manufacturing, Packaging Machine Language (PackML) is a standard commonly used to monitor and orchestrate production modules and production lines. In hybrid facilities that combine elements of process and discrete manufacturing, such as in food and beverage or battery cell production, both standards (PackML, MTP) can be used to describe and operate cells / machines. These standards have different integration and operation methods. Summary of the Invention

[0003] There is a need to facilitate the integration of modules into hybrid modular plants that include discrete manufacturing and process industry components. This need is satisfied by the subject matter of the independent claims. Optional features are stated in the dependent claims.

[0004] This disclosure provides a general method for interfacing between several module standards. It implements a transparent interface between an orchestration layer (e.g., an MTP process orchestration layer or a POL) and modules described by various (incompatible) standards, thereby facilitating access to hybrid automation and allowing users to mix modules in greenfield plants, as well as connect existing modules to the POL. In other words, this disclosure enables hybrid modular plants (i.e., plants involving modules described by different standards) to operate from a common orchestration layer. Examples of these standards are MTP and PackML. However, it is to be understood that this disclosure is not limited to these standards. An automatic or semi-automatic mapping of the conceptual description of modules and runtime transformations built into the orchestration layer are proposed to achieve interoperability between standards. Since standards all rely on common communication protocols such as OPC UA as the backbone for communication and information exchange, this disclosure allows enabling the PackML interface within the POL at a relatively low cost.

[0005] The present invention may include one or more aspects, examples or features, whether disclosed in isolation or in combination.

[0006] Other aspects, examples, and features of the invention will become apparent and will be illustrated by referring to the embodiments described below. Attached Figure Description

[0007] A detailed description will now be given by way of example only, with reference to the accompanying drawings, in which:

[0008] Figure 1The diagram illustrates the structure of a modular factory based on the MTP standard;

[0009] Figure 2 The diagram illustrates the physical model of the modular factory and recipe management based on PackML;

[0010] Figure 3 The diagram illustrates the cell interconnections that form a production line in PackML;

[0011] Figure 4 The diagram illustrates a method for integrating a single PackML machine into the MTP process orchestration layer;

[0012] Figure 5 The diagram illustrates the steps that can be executed to import multiple interconnected PackML machines into the MTP process orchestration layer;

[0013] Figure 6 and Figure 7 The diagram illustrates a method for integrating an MTP module into PackML by representing the MTP module via the PackML interface; and

[0014] Figure 8 The illustration shows a computing device that can be used according to the systems and methods disclosed herein. Detailed Implementation

[0015] Figure 1The diagram illustrates the structure of a modular factory 100 according to the MTP standard. In the context of process automation, the modular factory 100 comprises different modules 102 (modules in MTP are also referred to as process equipment assemblies - PEAs), thereby encapsulating components 104 (such as devices and apparatuses, also composed of process controllers and instruments). Each module 102 has a built-in controller 106 responsible for automating the functions provided by the module 102, as well as troubleshooting and other automated tasks. Each module 102 implements at least one process function, which is encapsulated and provided as a service. All modules 102 have process connections to other modules 102 and information connections to the process orchestration layer (POL) 108. Communication between the PEA 102 and POL 108 is achieved using the OPC UA communication protocol (OPC Unified Architecture, a machine-to-machine communication protocol for industrial automation regulated by the OPC Foundation). A key element within the modular production plant area is the standardization of the automation system interface between the modular automation system 110 and the POL 108. This has allowed for the standardization of Module Type Package (MTP), module description, or definition files that allow the integration of module 102 into POL 108. The MTP file typically describes the Human-Machine Interface (HMI) of module 102, its structure resembling a Piping and Instrumentation Diagram (P&ID) 102, describing the module's services and providing a list of built-in devices. The MTP is a vendor-independent description, defining the interface to module 102 in AutomationML (AML) format. Therefore, it can be used to integrate module 102 into POL 108 regardless of the vendor and type of the controller 106 used for module 102.

[0016] Figure 2 The diagram illustrates a physical model of a modular factory and recipe management based on PackML. PackML is an industrial automation standard for controlling packaging machines, developed collaboratively by the Organization for Machine Automation and Control (OMAC) and the International Association of Automation (ISA). PackML presents a standard program architecture and programming methodology designed to provide operators and technicians with a consistent look and feel for packaging machines. The standard's three main elements are a state machine model, tags for consistent terminology (PackTag), and a modular program architecture, Make2Pack. The state machine model can be used in virtually any industrial machine, as states and transitions are not unique to packaging machines. Modular machine code using PackML matches the three lower levels of the ISA88 / IEC 61512 physical model: Unit 202, Equipment Module (EM) 204, and Control Module (CM) 206, as shown below. Figure 2As shown. PackML unit 202 can also be referred to as a machine. The recommended method for inter-module and row-to-module communication is to use OPC UA. A recipe is the only set of essential information that uniquely defines the production requirements of a specific product. The relationship between recipes and equipment is as follows: Figure 2 As shown. Specifically, the control formula describes the parameters that need to be set in unit 202 in order to produce a specific product. An example could be a stacker crane unit 202, which receives three process-related parameters from a production order: packing pattern, number of layers, and interlayer inserts.

[0017] Within the MTP, POL 108 is required, for example, to coordinate modules 102 used in the modular plant 100 by executing process recipes. In PackML, operation is primarily based on inter-cell communication. Therefore, PackML does not require a POL, but can be implemented by simply connecting cells 202 in production line 210, for example... Figure 3 As shown. It has proven to be a challenge for the industry to reconcile these two opposing operational concepts in a hybrid plant.

[0018] This document describes methods for integrating modules into a hybrid modular plant (comprising discrete and continuous manufacturing sections) by implementing PackML-to-MTP mapping (e.g., by providing a mapping from a PackML packer to an MTP package for runtime packaging for engineering and runtime orchestration) or by implementing MTP-to-PackML mapping (e.g., by creating an MTP-compatible packager for a PackML cell). This packaging enables transparent engineering, monitoring, and orchestration of the PackML module 202 in MTP POL 108 and the PackML-based production line 210, respectively, via the PackML interface, or monitoring and control of the MTP module 102. Control sequences or recipes running in the continuous section can be configured to perform services of the discrete section, and / or control sequences or recipes running in the discrete section can be configured to perform services of the continuous section.

[0019] According to the first example, PackML to MTP mapping is implemented to integrate discrete parts of a hybrid modular plant (including those units 202 interconnected using PackML) into a continuous part of the modular plant (including MTP module 102) called POL 108. Therefore, the following description focuses on the PackML to MTP method for wrapping PackML for use in the MTP-based POL 108. Variations of the first example or PackML to MTP mapping include mapping individual PackML units 202 as separate MTP modules 102 to the MTP POL 108 one after another, and mapping multiple PackML units combined into production line 210 as a single MTP module 102 to the MTP POL 108. Of course, in a single hybrid plant, some PackML modules can be integrated individually, while others are integrated into the production line. PackML machines 202 are imported at runtime or during design / engineering time. When a machine is imported at runtime, it appears and can be browsed via the OPC UA interface. Importing machines during design / engineering time depends on machine availability: any available OPCUA information model for PackML machine 202 is used, for example via an OPC UA NodeSet file; alternatively, a standard set of machine states, operating modes, and PackTags are assumed, where additional modifications such as labels or operating modes can be used for export, for example via a spreadsheet file (such as Excel).

[0020] As mentioned above, in a variant of the first example, PackML units 202 are integrated one after another into MTP POL 108. In one example, control sequences or recipes running in the continuous section may not be applied to the discrete section. Integrating PackML units 202 requires wrapping / mapping the description of a single PackML machine 202 into an MTP-compatible abstraction, including one or more of the following steps: monitoring information about the PackML machine 202, such as current status, available transitions, and error / alarm information, via an MTP-compatible interface; performing changes in the operating mode and state of the PackML machine 202 using the state abstraction of MTP POL 108 and MTP module 102; accessing non-functional information (included in the PackML PackTag), such as machine speed or custom machine parameters, via PackML's DataAssembly or ServiceParameter constructs, allowing them to be used in the transitions of POL recipes; and summarizing multiple actions of the PackML machine 202 into dedicated MTP services or procedures (e.g., setting machine mode, writing a custom set of machine parameters, modifying machine speed).

[0021] The contents of the PackML module can be summarized as follows: a state model (standardized, but can also be extended through custom sub-states); a list of machine modes (three standardized modes, such as manual, automatic, and additional custom modes); read-only status PackTags describing machine conditions, such as machine speed, including some machine-specific standard parameters and some custom parameters); write-only command PackTags that allow the machine's state and mode (such as machine speed) to be affected, including some machine-specific standard parameters and some custom parameters; and read-only management PackTags containing some standardized OEE data (such as total product count and defective product count) and some machine-specific warning data.

[0022] Figure 4 The illustration shows the steps of a method that can be performed to import a single PackML machine 202 into an MTP POL 108. The method includes the following steps: constructing an MTP file 400 401; importing the file 400 into the POL 108 and parameterizing it 402; and runtime conversion between PackML and MTP communication 403.

[0023] In step 401, MTP file 400 is constructed. This may require automatic or semi-automatic construction of MTP file 400 based on the PackML (OPC UA) interface during engineering time. File construction can be performed using a user-oriented tool capable of browsing online PackML servers or loading offline representations of PackML (e.g., Nodeset files or spreadsheets) and importing them directly or using intermediate MTP files into MTP POL 108. MTP file 400 can therefore be constructed by scanning the PackML representation and generating an MTP-compatible representation, wherein the MTP file or module contains (i) a cell schema or a program based on a cell schema built into the PackML machine; and (ii) one or more variables contained in the PackTag section within the PackML information model. Additionally, dedicated tags for MTP can be defined, allowing POL 108 to perform runtime transformations in step 403, as further described below. Mapping of existing PackML interfaces can be based on the interface of existing cell 202 (e.g., Figure 4 The mapping is performed using one or more of the following: (as shown) and offline information (such as a NodeSet export from an OPC UA server or an Excel spreadsheet containing PackTags). Mapping includes one or more of the following: service mapping, data assembly mapping, and HMI mapping.

[0024] For service mapping, the primary entity in PackML that can be mapped to MTP services is the unit operation mode. In addition to standard services such as automatic or manual operation, PackML modules can also contain any number of custom operation modes. Automatic mapping can occur based on these services when custom parameters are not mapped. In custom operation modes, user assistance can be obtained to identify which PackML PackTags are used by which operation modes. These PackTags can then be included in the MTP service definition so that they can be set during invocation. This disclosure envisions at least two different mapping strategies: the first strategy is to implement a one-to-one mapping from PackML operation modes to MTP services, allowing fine-grained control over units; the second strategy is to implement a complex mapping of multiple module modes to an MTP service, such as switching from automatic to manual mode, reducing machine speed in between.

[0025] For data assembly mapping, one possibility is to map status or management PackTags to data assembly structures within the MTP module, such as allowing POL 108 to read and process parameters of PackML unit 202, like the current machine speed. This mapping can be implemented manually by engineers, for example, for non-standard PackTags included in the module, or automatically by mapping all non-standard PackTags to service parameters. Any manual mapping can be recorded by the engineering system so that mappings for similar or recurring modules can be implemented automatically.

[0026] In step 402, the import and parameterization of MTP file 400 into MTP POL 108 is performed. Relevant parameters include, for example, the IP address of the MTP instance and parameters for the PackML service, such as the desired machine speed or unit operating mode. Importing the generated packer MTP 400 into POL 108 can be done without significant modifications. As mentioned above, tags can be included in the packer MTP 400 so that POL 108 can react in step 403 and perform runtime transformations. These tags can be set using standardized MTP data structures, such as through a dedicated module type naming scheme or proprietary MTP parameters. Such tags can include one or more prefixes or suffixes mapped to OPC UA items in the MTP, additional non-MTP types mentioned in the AutomationML file, and / or comments at the XML level.

[0027] In step 403, runtime transformation is performed between PackML and MTP communication. After the wrapper MTP 400 is loaded into POL 108, the PackML interface of unit 202 is invoked to trigger the service and monitor parameters. Therefore, POL 108 can be functionally transformed by runtime ( Figure 4 (Not shown) is used to supplement the translation between the MTP and PackML communication interfaces, such as translating the values ​​encoded for the state of unit 202 to overcome the differences between the MTP and PackML runtime information representations. This translation functionality can be implemented within POL 108 or via an additional gateway component located outside POL 108. Based on the markers in the wrapper MTP file 400, POL 108 or the gateway component maps information within PackML unit 202 to a compatible MTP representation. Additionally, optional attributes of distributed control systems (e.g., ABB System 800xA) can be used at runtime. This runtime mapping includes, but is not limited to: state information, such as the current state and available translation states; representations of module operating states and the ability to switch between these modes, similar to module states; and information required for remapping using the data assembly mapping. The mapping of state information can be performed not only on PackML states present in the MTP state model but also on states required by MTP but not present in the MTP module definition, as PackML can omit such states. The same applies to additional states that PackML unit 202 may contain but not be present in the fixed MTP state set. Reading the current state can be performed differently at the POL to module communication level. For example, the PackML OPC UA model defines state transitions via OPC UA method calls, while MTP uses variable writes.

[0028] For HMI mapping, since PackML does not provide specific information about its physical structure, such as necessary or provided product interfaces or internal structures, this information portion of the MTP can be replaced by general placeholders or dedicated unit-specific mappings, for example, for complex machines with multiple product inputs and outputs. Automatic or semi-automatic provisioning can also be performed, for example, by generating parameterized HMI panels based on existing PackTags from PackML.

[0029] As mentioned above, in the second variation of the first example, the discrete portion is integrated into a single MTP module 102 within the continuous portion of the hybrid modular plant. Each PackML machine 202 provides a single service, and production line 210 is represented by a single MTP module 102 that combines all the services of the PackML machines 202 of line 210, such as filling products with various packaging types. The complete production line 210 is controlled by a POL 108 operating in the continuous portion. Furthermore, engineering can be integrated for both discrete and continuous portions. This means that a production line can be defined as a module according to relevant standards (e.g., VDI 2658, Automation Engineering for Modular Systems in Process Industries – General Concepts and Interfaces), and each machine can be a service defined by the same standard. The resulting MTP can be used in the engineering and may only require a wrapper 500 for runtime (primarily converting integers used in PackML to bits used in MTP). The described solution for MTP-to-PackML conversion can also be applied, i.e., representing MTP modules through a PackML interface, as further described below.

[0030] Figure 5 The illustration depicts method steps that can be performed to import multiple interconnected PackML machines 202 into MTP POL 108. The method is performed to represent a production line 210, comprising multiple PackML modules 202, as a single MTP module 102 from the perspective of MTP POL 108. Figure 4 Same, Figure 5 The method includes the following steps: constructing a 501MTP file 500; importing the file 500 into POL 108 and parameterizing it 502; and runtime conversion between PackML and MTP communication 503.

[0031] In addition to the line mappings used in step 501, which are based on line topology 510 (including, for example, the physical order of PackML units 202), the mapping procedure for constructing the MTP file 500 can be performed similarly to the mapping of individual modules described above with respect to step 401. Using the topology information 510, POL 108 can determine the overall state of line 210, for example, the conditions of the entire line 210 can be changed if conditions change in some non-redundant PackML units 202. During engineering time, logic can be defined and wrapped into MTP services, such as starting or stopping the entire line 210 and changing the production processed within line 210. More broadly, wrapping / mapping the descriptions of multiple PackML machines 202 combined into production line 210 into an MTP-compatible abstraction 500 representing production line 210 as an MTP module 102 can include: using the topology information 510 of production line 210 to monitor production line 210, and defining the operating state of production line 210 as the MTP module state, for example, a defect in one module of the line will cause a change in the state of the entire line. For example, the method may include simultaneously reducing the speed of all production line machines or changing the production mode of the line, such as by changing the format or layout of the packaging used.

[0032] Step 502 can be performed as described above regarding step 402.

[0033] Runtime transformation 503 becomes more complex than in step 403 because multiple calls can be marshalled to the PackML interface, and any custom service logic defined in step 501 can be evaluated by POL 108, for example, by running some pre-compiled routines.

[0034] Alternative approaches to mapping production lines involve orchestrating multiple MTP modules 102 converted from PackML using the techniques described above. For some use cases, MTP black-box representation may be a more suitable approach, for example, to reduce complexity within POL 108. Furthermore, custom, complex line-based services can be defined during the mapping / construction process, using a syntax different from POL 108.

[0035] According to the second example, the PackML first method is adopted by implementing an MTP-to-PackML mapping to represent MTP module 102 and allows control of MTP module 102 through the PackML interface.

[0036] Figure 6 and 7 The program for MTP module 102 and the corresponding MTP file 600 is illustrated in more detail.

[0037] In step 601, the MTP file 600 is imported and transformed. The MTP file 600 and MTP instance information (e.g., OPC UA endpoints) can be imported at project time or runtime, for example, by reusing existing POL information. More specifically, in step 601, the runtime agent component 608 uses the imported MTP file 600 and the endpoint addresses of the MTP module 102 for parameterization, and the PackML-compatible representation 202 of module 102 is constructed using a mapping algorithm.

[0038] The mapping algorithm is similar to the mapping algorithm described above for PackML to MTP, and vice versa, and includes one or more of the following steps: (ii) the state model mapping is performed (the MTP state model is not extensible, so it can be mapped almost directly); (iii) the MTP services are mapped to the operating modes of the PackML agent; and (iv) the data ensemble within the MTP is mapped to the PackTag of the PackML unit according to a predefined or user-provided mapping.

[0039] In other words, wrapping / mapping the description of a single MTP module 102 to the PackML interface 610 of a single PackML machine 202 may include one or more of the following steps: monitoring machine information, such as the current status of the MTP module 102, available transformations, and error / alarm information via PackML-compatible interfaces (status, mode, PackTag); changing the operating mode of the MTP module 102 and invoking services via the PackML interface; accessing additional functional and non-functional information of the MTP (e.g., module parameters and DataAssembly) via the PackML PackTag; automatically or semi-automatically generating PackTag documents based on the existing / used MTP structure; and defining the logic between the MTP and PackML parts of the hybrid modular plant represented in POL 108. Defining the logic may include: altering the behavior of the MTP plant parts based on PackML equipment conditions, such as throttling upstream production during brewing, for example, in the event of a downstream failure during filling, or increasing the filling speed based on some brewing process conditions; and collecting data based on conditions and events of both plant parts, for example, for root cause analysis.

[0040] Since MTP can contain multiple services, it may need to be mapped to multiple logical PackML interfaces 610, such as Figure 7 As instructed, Figure 7 Multiple representations of the MTP service are shown as corresponding PackML units 202 (“Unit Services 1 to n”), each unit including a PackML interface 610.

[0041] In step 602, runtime translation is performed. More specifically, runtime agent component 608 starts a PackML-compatible OPC UA server, and then requests to the PackML interface 610 of runtime agent 608 are translated into calls to the MTP interface 612 of MTP module 102. For example, OPC UA method calls of the PackML model are translated into variable reads / writes of the MTP interface.

[0042] Therefore, in order to integrate the continuous portion into the discrete portion, the step of constructing one or more interfaces 610 representing each continuous portion module 102 as one or more corresponding discrete portion units 202 may further include importing and converting (601) a file 600 representing the continuous portion module 102, constructing (601) a discrete portion representation 202 of the continuous portion module 102 associated with the interface 610, and performing (602) runtime conversion of communication between the interface 610 and the interface 612 of the continuous portion module 102.

[0043] This disclosure applies to brewing, pharmaceutical, cell production, and food and beverage applications where process and non-process (discrete) modules are used.

[0044] Now go to Figure 8 The illustration shows a high-level diagram of an exemplary computing system 800 that can be used according to the systems and methods disclosed herein. The computing device 800 includes at least one processor 802 that executes instructions stored in memory 804. For example, the instructions may be instructions for implementing functionality described as being performed by one or more components discussed above, or instructions for implementing one or more methods described above. The processor 802 can access memory 804 via a system bus 806. In addition to storing executable instructions, memory 804 may also store dialogue input, scores assigned to the dialogue input, etc.

[0045] The computing device 800 additionally includes a data repository 808 accessible by a processor 808 via a system bus 806. The data repository 808 may include executable instructions, log data, etc. The computing device 800 also includes an input interface 810 that allows external devices to communicate with it. For example, the input interface 810 may be used to receive instructions from external computer devices, users, etc. The computing device 800 also includes an output interface 812 that connects the computing device 800 to one or more external devices. For example, the computing device 800 may display text, images, etc., through the output interface 812.

[0046] External devices communicating with computing device 800 via input interface 810 and output interface 812 can be included in an environment that provides a user interface of virtually any type that a user can interact with. Examples of user interface types include graphical user interfaces (GUIs), natural user interfaces (NUMAs), and the like. For example, a GUI can accept input from a user using multiple input devices (such as a keyboard, mouse, remote control, etc.) and provide output on an output device (such as a display). Furthermore, a NUMA allows a user to interact with computing device 800 in a manner unconstrained by input devices (such as a keyboard, mouse, remote control, etc.). Instead, a NUMA can rely on speech recognition, touch and stylus recognition, on-screen and near-screen gesture recognition, air gestures, head and eye tracking, voice and speech, vision, touch, gestures, machine intelligence, and the like.

[0047] Additionally, although illustrated as a single system, it is to be understood that computing device 800 can be a distributed system. Thus, multiple devices can communicate via a network connection and collaboratively perform tasks described as being performed by computing device 800.

[0048] The various functions described herein can be implemented in hardware, software, or any combination thereof. If implemented in software, the functions can be stored on or transmitted via a computer-readable medium as one or more instructions or code. Computer-readable media include computer-readable storage media. A computer-readable storage medium can be any available storage medium accessible by a computer. By way of example, and not limitation, such computer-readable storage media can include RAM, ROM, EEPROM, CD-ROM or other optical disc storage devices, disk storage devices or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and is accessible by a computer. As used herein, disks and optical discs include: compact discs (CDs), laser discs, optical discs, digital universal discs (DVDs), floppy disks, and Blu-ray discs (BDs), wherein disks typically magnetically copy data, while optical discs typically optically copy data using lasers. Furthermore, transmitted signals are not included within the scope of computer-readable storage media. Computer-readable media also include communication media, which include any medium that facilitates the transfer of a computer program from one place to another. For example, a connection can be a communication medium. For example, if the software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technology (such as infrared, radio, and microwave), then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technology (such as infrared, radio, and microwave) are included in the definition of communication media. Combinations of the above should also be included within the scope of computer-readable media.

[0049] Alternatively or additionally, the functionality described herein may be performed at least in part by one or more hardware logic components. For example, but not limited to, illustrative types of hardware logic components that may be used include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chips (SoCs), complex programmable logic devices (CPLDs), etc.

[0050] The applicant hereby discloses in isolation each individual feature described herein, as well as any combination of two or more such features, provided that such feature or combination can be performed on the basis of this specification as a whole, given common general knowledge of those skilled in the art, regardless of whether such feature or combination solves any problem disclosed herein, and without limiting the scope of the claims. The applicant indicates that various aspects of the invention may consist of any such individual feature or combination of features.

[0051] While the invention has been illustrated and described in detail in the accompanying drawings and foregoing description, such illustrations and descriptions should be considered exemplary and not restrictive. The invention is not limited to the disclosed embodiments. In view of the foregoing drawings, it will be apparent to those skilled in the art that various modifications can be made within the scope of the invention as defined by the following claims.

Claims

1. A method for integrating modules into a hybrid modular factory, the hybrid modular factory comprising discrete and continuous portions, the method comprising: Integrating the discrete portion into the continuous portion includes constructing (401; 501) at least one module definition file (400, 500) and importing the module definition file (400, 500) into (402; 502) the orchestration layer (108) of the continuous portion, wherein the at least one module definition file (400, 500) maps one or more discrete portion units (202) of the discrete portion to the continuous portion module (102); and Running the hybrid modular factory includes runtime transformations that perform communication between the discrete and continuous parts, wherein the discrete and continuous parts use a common communication protocol.

2. The method of claim 1, wherein integrating the discrete portion into the continuous portion comprises: The continuous part unit (202) is individually integrated into the orchestration layer (108) as the corresponding continuous part module (102).

3. The method according to claim 1 or 2, further comprising: (i) configuring a control sequence or recipe to run in the continuous portion to perform the service of the discrete portion, (ii) configuring a control sequence or recipe to run in the discrete portion to perform the service of the continuous portion, or both (i) and (ii).

4. The method of claim 1, wherein integrating the discrete portion into the continuous portion comprises: The production line (210) of the discrete part is integrated as a single continuous part module (102) within the continuous part of the hybrid modular plant.

5. The method according to claim 4, further comprising: The operating state of the production line (210) is defined as a continuous part module state using topology information (510) related to the discrete part of the production line (210).

6. The method according to claim 1 or 2, wherein constructing (401; 501) the at least one module definition file (400, 500) comprises: Generate a service mapping that maps at least one unit operation mode of the discrete part unit (202) to a continuous part module service.

7. The method of claim 6, comprising: The service mapping is generated as a one-to-one mapping from the individual unit operation mode of the discrete part unit (202) to the continuous part module service.

8. The method of claim 6, comprising: The service mapping is generated as a complex mapping from the multiple unit operation modes to the services of the consecutive partial modules.

9. The method according to claim 1 or 2, wherein constructing (401; 501) the at least one module definition file (400; 500) comprises: Generate a data assembly that maps the annotations or labels of the parameters in the discrete part to equivalent annotations or labels in the continuous part.

10. The method according to claim 1 or 2, wherein constructing (401; 501) the at least one module definition file (400; 500) comprises: The HMI mapping is generated using a general placeholder or a special unit-specific mapping, which maps the HMI elements of the discrete part unit (202) to the equivalent elements of the continuous part module (102).

11. The method of claim 1, wherein the runtime transformation is performed based on tags added to the module definition file (400, 500).

12. The method of claim 1 or 2, wherein the discrete portion includes a PackML portion, the continuous portion includes a modular package MTP portion, and the communication protocol is the OPC Unified Architecture (OPC UA).

13. A method for integrating modules into a hybrid modular factory, the hybrid modular factory comprising discrete and continuous portions, the method comprising: Integrating the continuous portion into the discrete portion includes constructing one or more interfaces (610) that represent each continuous portion module (102) as one or more corresponding discrete portion units (202); and Running the hybrid modular factory includes runtime transformations that perform communication between the discrete and continuous parts, wherein the discrete and continuous parts use a common communication protocol.

14. The method of claim 13, wherein the discrete portion includes a PackML portion, the continuous portion includes a modular package MTP portion, and the communication protocol is an OPC Unified Architecture (OPC UA).

15. A computing device (800) comprising a processor (802) configured to perform the method according to any one of claims 1 to 14.

16. A computer-readable medium (804, 808) including instructions which, when executed by a computing device (800), cause the computing device to perform the method according to any one of claims 1 to 14.

Images