Resource management for modular devices

Abstract

Various embodiments of the present disclosure relate to resource management for modular devices. There is a need for more efficient resource planning for modular devices. Accordingly, a computer-implemented resource management method for a modular device is provided, the method comprising: receiving data identifying desired module types to be assembled into the modular device as part of a module pipeline comprising one or more modules; and executing an optimization algorithm to select a module for inclusion in the module pipeline from a plurality of modules having the desired module types based on one or more predetermined optimization criteria.

Description

Technical Field

[0001] The present invention relates to a resource management system for modular equipment. Background Art

[0002] The Modular Type Package (MTP) standard for modular automation systems creates a framework for interoperability between modules and orchestration systems, allowing industrial process equipment to be built and designed in a more modular manner. The goal is to simplify process equipment design and lifecycle management. These advantages are achieved through prefabricated and fully tested modules called PEAs (Process Equipment Assemblies), which can be easily put together in different combinations to implement different recipes.

[0003] In today's modular equipment, modules are often individually defined and created, then manually integrated into the overall equipment by equipment engineers. Integrating modules into equipment is a significant design effort, involving ensuring input and output flow compatibility, proper calibration of process parameters, and accurate alarm management. Equipment operators often invest significant time and resources in integrating modules into equipment. Summary of the Invention

[0004] Therefore, there is a need for more efficient resource planning and management of modular equipment. This need is met by the subject matter of the independent claims. Optional features are set out in the dependent claims.

[0005] According to a first aspect, a computer-implemented resource management method for a modular device is provided. The method includes receiving data identifying a desired module type to be assembled into the modular device as part of a module pipeline comprising one or more modules; and executing an optimization algorithm to select a module for inclusion in the module pipeline from a plurality of modules of the desired module type based on one or more predetermined optimization criteria. The data identifying the desired module type may include data identifying a module of that type.

[0006] The optimization algorithm may simulate the operation of one or more candidate pipelines, each of the one or more candidate pipelines including at least one module from a plurality of modules having a desired module type. In particular, where the optimization criteria include one or more of capacity, energy consumption, and service time, the optimization algorithm may identify one or more bottlenecks or inefficiencies in the simulated operation of the candidate pipelines.

[0007] The method may include presenting the results of the simulation to a user and receiving a user selection of the candidate pipeline.

[0008] The optimization algorithm may utilize a machine learning model that is trained to select modules for inclusion in the module pipeline based on one or more of module properties and collected usage data related to the modules.

[0009] The optimization algorithm may perform a local optimization to optimize only the aforementioned module pipelines, or a global optimization to select a plurality of modules of a desired type to be assembled into corresponding module pipelines in the modular device.

[0010] The optimization algorithm may utilize one or more of the following: (i) module attributes of the plurality of modules, and (ii) collected usage data associated with previous usage of the plurality of modules in the modular equipment (the collected usage data associated with one or more of the following: mean time between failures; module uptime; service and equipment utilization; previous calibration parameters; frequent equipment background; maintenance performed; material / media handling; application objectives and limitations of chemical reactions; module availability schedules; maintenance cycles / intervals). Additionally or alternatively, the optimization algorithm may utilize data indicative of performance of previous module combinations to select modules for inclusion in the module pipeline.

[0011] The optimization algorithm may select a plurality of candidate modules for inclusion in the module pipeline from a plurality of modules having a desired module type and rank the candidate modules according to one or more predetermined optimization criteria.

[0012] Any feature or sub-aspect of any of the second to fourth aspects (in particular those described with reference to the optimized component) may also apply mutatis mutandis to the first aspect and vice versa.

[0013] According to a second aspect, a resource management system for modular devices is provided. The system comprises a database providing a module library or repository of semantic modules (module representations) representing corresponding modules in a module pool, at least one of the above-mentioned semantic modules comprising a semantic description of the corresponding module, wherein the semantic description comprises abstract data conforming to a semantic data model, and wherein the abstract data describes properties of the corresponding module that are not found in a standard description file for the module. Thus, the semantic description extends the standard description file of the corresponding module, for example by using a wrapper containing the semantic description. Module attributes may comprise any suitable data or parameters defining the module. For example, module attributes may comprise one or more of the following: input / output attributes; module functionality; module parameters; process parameters; calibration parameters.

[0014] Thus, the resource management system provides equipment operators with an intelligent, information-enhanced unit pool. The resource management system provides equipment operators with improved usability and greater comfort using software tools, reduces the error rate of unit settings within the equipment, and optimizes equipment performance.

[0015] The semantic description may also include usage data collected related to previous usage of the corresponding module in the modular device. The collected usage data may include any suitable data characterizing previous module performance, usage, or configuration, and may relate to previously measured key performance indicators, including one or more of the following: mean time between failures; module uptime; service and equipment utilization; previous calibration parameters; frequent equipment background; maintenance performed; material / media handling; application purpose and limitations of chemical reactions; module availability schedule; and maintenance cycles / intervals.

[0016] In this way, the resource management system can assist equipment operators in supervising / managing their inventory of existing modules (e.g., 12 metering units and 10 reaction units, etc.). Some modules may currently be in use in the equipment, while others are not. For the modules in use, data about their usage (e.g., what materials are processed) or the performance of their components (e.g., uptime, valve material wear), maintenance key performance indicators (KPIs, such as module life cycle), etc. can be collected and continuously added to the database. When a new equipment is to be built or an existing equipment is to be reconfigured, the equipment operator can view the module pool via a module library or repository and select the best module for a given function with reference to the semantic description and the collected usage data. For example, the equipment operator can simply select an available module that processes the same material as the material that the module being sought is expected to process and has the longest time before the next scheduled maintenance.

[0017] The semantic description may also include previous configuration data related to the configuration of the corresponding module in at least one previous modular device, the previous configuration data being usable to configure the module for use in another modular device. The previous configuration data may be related to previous design data that accelerates module reuse.

[0018] Therefore, with the help of this technology platform, equipment operators can select and reuse pre-configured modules. In this way, it not only facilitates the reuse of individual modules, but also facilitates the reuse of larger functional blocks, thus simplifying the task of module design and modular equipment assembly.

[0019] In addition, via the semantic description and the collected usage data, a mechanism is provided for automatically finding and recommending optimal module and process pipeline combinations for modular equipment. In one example, the resource management system may also include a module pipeline generation engine configured to receive input data indicating at least one precondition and at least one postcondition of a desired pipeline for the modular equipment, and generate a suggested semantic module pipeline representing one or more modules capable of converting the at least one precondition to the at least one postcondition. The module pipeline generation engine may be configured to select one or more semantic modules to be included in the semantic module pipeline from a module library based on module attributes contained in the semantic description of the selected semantic module. The present disclosure contemplates various module attributes that may be used to select modules.

[0020] In particular, the module pipeline generation engine can be configured to determine a sequence of one or more semantic modules to form a semantic module pipeline based on the input / output properties of the semantic modules in the module library, wherein the input properties of the first semantic module in the sequence match at least one precondition and the output properties of the last semantic module in the sequence match at least one postcondition. The module pipeline generation engine can be configured to generate a semantic module pipeline using multiple modules selected from the module library to provide inter-module compatibility of the selected modules. The module pipeline generation engine can be configured to determine inter-module compatibility based on the corresponding module properties. The module properties indicating inter-module compatibility may include input and output properties of the selected modules. The module pipeline generation engine can therefore be configured to select modules for inclusion in the proposed pipeline based on the input and output compatibility of the selected modules. In the module sequence thus determined, the modules are therefore selected so that the output properties of the modules match the input properties of any subsequent modules and so that the input properties of the modules match the output properties of any previous modules. Input and output properties can be compared and matched in this manner using semantic data describing properties that conform to a semantic data model (i.e., using the language and vocabulary of the semantic data model).

[0021] Additionally or alternatively, the module pipeline generation engine can be configured to determine a sequence of one or more modules to form a module pipeline based on functional attributes of semantic modules in the module library, the functional combination of which is to convert at least one precondition into at least one postcondition. In this case, the attributes indicating compatibility between modules may include attributes defining module functionality, and wherein the module pipeline generation engine is configured to generate a suggested pipeline based on the functional compatibility between the selected modules. For example, where a module requires a minimum temperature at an input, the pipeline generation engine may select a heater module as the previous module in the suggested pipeline. Similarly, semantic data describing attributes that conform to a semantic data model can be used to compare and match attributes defining module functionality.

[0022] Pipeline generation can thus take the form of a rule-based data-driven execution engine (or composition engine), where exemplary rules include input-output compatibility and functional compatibility, etc. The rules themselves can be defined by semantic data according to a semantic data model or can use semantic data.

[0023] In either of these approaches, the system provides the facility operator with automatic generation of suitable / feasible pipeline recommendations as to how to construct a new pipeline for a given purpose.

[0024] A resource management system may include an optimization component configured to: receive data identifying desired module types to be assembled into a modular device as part of a module pipeline comprising one or more modules; and execute an optimization algorithm to select semantic modules representing modules for inclusion in the module pipeline from a plurality of modules of the desired module types in a module library based on one or more predetermined optimization criteria. A module pipeline generation engine may be configured to generate a plurality of proposed pipelines for comparison based on the one or more predetermined criteria. The optimization algorithm may be configured to perform local optimization to optimize only the module pipeline or to perform global optimization to select a plurality of modules of the desired type to assemble into the corresponding module pipeline in the modular device. The predetermined optimization criteria may include one or more of the following: product quality; throughput; capacity; resource / material efficiency; energy efficiency; energy consumption; service time; uptime; equipment availability; mean time between failures; service and equipment utilization; and minimizing module usage. In particular, where the collected usage data includes previously measured key performance indicators, this may be used to determine an optimal or preferred selection and sequence of modules for converting precondition(s) into postcondition(s) when the predetermined criteria are met. In the case where the optimization component selects multiple candidate modules for inclusion in a module pipeline from multiple modules having a desired module type, the optimization component can rank the candidate modules according to one or more predetermined optimization criteria (using, for example, the ranking component described herein) and output the ordered candidate modules for user selection.

[0025] To assist the equipment operator in locating the appropriate module, the database may be configured to provide a search function to allow searching of the module library.

[0026] To assist the facility operator in validating module / pipeline selection, the resource management system may include a simulation component configured to provide simulation functionality to allow simulation of the operation of a modular pipeline comprising one or more modules in the modular facility. Additionally or alternatively, the resource management system may include a ranking component configured to facilitate the facility operator in selecting the best module from a set of possible pipeline options with respect to a given optimization criterion.

[0027] According to a third aspect, a computer-implemented resource management method for a modular device is provided. The method includes providing a module library via a database, the module library storing semantic modules representing corresponding modules in a module pool, at least one of the semantic modules including a semantic description of the corresponding module, wherein the semantic description includes abstract data conforming to a semantic data model, and wherein the abstract data describes properties of the corresponding module not found in a standard description file for the module. Any features or sub-aspects of the second aspect may also apply, mutatis mutandis, to the third aspect.

[0028] According to a fourth aspect, a computer-implemented resource management method for a modular device is provided. The method comprises (e.g., using the module pipeline generation engine described herein): receiving input data indicating at least one precondition and at least one postcondition for a desired pipeline for the modular device; and determining a proposed module pipeline comprising one or more modules capable of converting the at least one precondition into the at least one postcondition. Any features or sub-aspects of the first to third aspects (particularly those described with reference to the module pipeline generation engine) may also apply, mutatis mutandis, to the fourth aspect.

[0029] According to a fifth aspect, a method for managing resources for a modular device is provided. The method includes using a resource management system or method as described herein to perform one or more of the following actions: (i) accessing a repository to select one or more modules from a module pool for inclusion in a module pipeline comprising one or more modules; (ii) performing automatic pipeline generation to generate a proposed module pipeline comprising the one or more modules; (iii) optimizing the module pipeline comprising the one or more modules; (iv) ranking the module pipelines according to various optimization criteria; and (v) simulating operation of the module pipeline comprising the one or more modules. The method may also include assembling the module pipelines into a modular device.

[0030] According to a sixth aspect, there is provided a method for creating and / or maintaining the resource management system of the second aspect, the method comprising: collecting usage data related to the use of modules in a modular device; and uploading the collected usage data to a database for inclusion in a wrapper of the module.

[0031] According to a seventh aspect, there is provided a computing device comprising a processor configured to perform a computer-implemented method as described herein.

[0032] According to an eighth aspect, there is provided a computer program product comprising instructions which, when executed by a computing device, enable / cause the computing device to perform a computer-implemented method as described herein.

[0033] According to a ninth aspect, there is provided a computer-readable medium comprising instructions which, when executed by a computing device, enable / cause the computing device to perform a computer-implemented method as described herein.

[0034] According to a tenth aspect, there is provided a modular apparatus assembled at least in part using the method of the fifth aspect.

[0035] The present invention may include one or more aspects, examples or features alone or in combination, whether specifically disclosed in that combination or alone.

[0036] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0038] Figure 1 illustrates a semantic pipeline representing a physical pipeline of an industrial modular device via a series of interconnected semantic modules;

[0039] Figure 2 illustrates a semantic pipeline automatically generated by a pipeline generation engine to transform a specific educt into a given product;

[0040] Figure 3 illustrates the optimization of the automatically generated semantic pipeline by the pipeline generation engine; and

[0041] Figure 4 Illustrated is a computing device that may be used in accordance with the systems and methods disclosed herein. DETAILED DESCRIPTION

[0042] Described herein is a resource management system for modular devices. The resource management system includes one or more of the following components: (i) a module library including semantically annotated modules; (ii) a pipeline generation engine; (iii) an optimization component; and (iv) a simulation component. The resource management system may also be referred to as a resource planning system. The resource management system may be implemented in software, firmware, hardware, or any combination thereof, for example using a computing device as described herein. The resource management system may form part of, or include, a design tool or dashboard for planning, configuring, and / or managing modular devices. As further described below, the resource management system implements a semantic data model to provide an abstract representation of a module, a pipeline of modules, or a modular device.

[0043] The module library contains one or more semantic modules stored in a repository such as a database. A semantic module includes instance data that represents, describes, or defines a module of a modular device using a semantic data model. A semantic module can also be described as a module representation, module description, or module definition. In the context of this disclosure, the terms "module" and "unit" can be used interchangeably. The module library can store other heterogeneous data items related to the semantic module (such as descriptors, annotations, values, and history). Therefore, the module library serves as a place (or knowledge representation system) for collecting global and local domain knowledge about the module. The module library can be implemented using a database involving any centralized or distributed data storage. For example, one or more data storage units provided by a resource management system, the module itself, or other elements of the modular device can be used to implement the database. In particular, the data storage 808 described below can be used to implement the database. The semantic modules stored in the module library can represent real or virtual, owned (owned by the device operator) or not yet owned (for example, available for purchase), available (currently in use in the device), or potentially available modules. Therefore, a module pool or repository that can be described as a pool of intelligent units is provided. By creating semantic modules and storing and registering them in a module library, semantic modules can be searched and found later and modules can be selected to form a process pipeline. In particular, to assist equipment operators in locating appropriate modules, the module library can provide a search function.

[0044] As used herein, the term "virtual module" refers to a type or category of module, while the term "real module" refers to an instance of a specific type of module. A real module can be implemented in software, firmware, hardware, or any combination thereof. A software module that provides control configuration for a hardware module can be referred to as a "functional module". For virtual modules, a semantic module can be implemented as a template for a specific type of module, such as a heating module, a metering module, a mixing module, etc. The template can include fields that hold fixed values that are valid for all modules of a specific type. The template can also include one or more placeholders for values that can be set for a real module, and / or one or more preset values that can be changed later. For a real module, a semantic module can include a template for the relevant module type, but supplemented with one or more values that represent the real module. In this way, the template accommodates process knowledge or design knowledge via fields in the template.

[0045] Therefore, modules are described using semantic descriptions that conform to a semantic data model. The semantic description may specify any one or more module attributes of the module. Module attributes (also referred to as annotations, properties, characteristics, descriptors, or features) may include any suitable data describing the module. For example, a semantic description may describe a module based on module attributes, which may include one or more of the following: input / output attributes, module functionality; module components; module parameters; module usage; process parameters; calibration parameters; data input, processing, and output of the module. The semantic description provides a common interface for preserving a semantic web stack (i.e., a RESTful API, accessible via HTTP, etc.). Through matching semantic descriptions between modules, process pipelines may be generated manually or automatically, as described in more detail below.

[0046] A semantic description can specify the relationship between a module's inputs and outputs. Specifically, the semantic description can specify one or more preconditions and one or more postconditions for the module. Preconditions and postconditions specify conditions that may, should, or must exist at the module's inputs and outputs. Preconditions can be described in terms of input attributes or characteristics, while postconditions can be described in terms of output attributes or characteristics. Preconditions and postconditions can, for example, specify attributes such as the identity or state of the material input to and output from the module, respectively. A module can thus convert at least one precondition into at least one postcondition. For example, in materials processing, a precondition can be an educt, and a postcondition can be a product. An "educt" refers to any substance, composition, or material that reacts with at least one other educt to form a product. Thus, a module converts an educt into a product, i.e., the material properties are transformed. A module can, for example, transform one material state into another through heating, stirring, refining, etc. "State" in this context refers to any property, characteristic, or condition of a single material, not just the aggregate state. The semantic description may also specify one or more conditions or constraints under which the module converts preconditions into postconditions. Additionally or alternatively, preconditions and postconditions may specify one or more of the form, structure, or connection modality of the module's inputs and outputs.

[0047] For real modules, the semantic description may also include collected usage data related to previous uses of the real module in a modular device. The collected usage data may, for example, include any one or more of the following: previous design data; previous calibration parameters; frequent device backgrounds; maintenance performed; material / media handling; application purposes and limitations of chemical reactions. The collected usage data may be used to accelerate the configuration of the module for use in another modular device. For example, one value in the template of a real module may identify the last processed material (e.g., nuts, which is important for a device that processes groceries but also wants to produce groceries for people with nut allergies). Another value may identify a non-functional service of the real module (e.g., for an oven module, a value indicates "Service Fan Oven (FanOven) is damaged, but top and bottom plate heat baking (Top & Bottom Plate Heat Baking) is still possible").

[0048] The collected usage data may include performance data. For example, the collected usage data may include one or more previously measured key performance indicators (KPIs). Measurable KPIs may include, for example, one or more of the following: mean time between failures; uptime; service and equipment utilization; availability schedules; and maintenance cycles / intervals. Many other examples are known to those skilled in the art. As described further below, such performance data may be used to optimize the selection of modules for the pipeline.

[0049] The semantic data model provides a common or standardized vocabulary or ontology (connecting the vocabulary with pre-existing knowledge and rules) for describing modules, modular pipelines, and modular devices, as will now be described. A semantic data model can also be described as a conceptual or abstract data model. A semantic data model structures data in a specific logical way using semantic information that adds meaning to the data and the relationships within the data.

[0050] As used herein, "semantic data" is abstract data that can represent any property of a module, pipeline, equipment, or material, in particular input / output properties of a module expressed in terms of material identity (e.g., input / output material) or material state (e.g., whether the material is in a raw or refined state, cooled or heated, liquid or solid). Semantic data can represent entities at different levels of abstraction. For example, at the highest level of data abstraction, semantic data can represent properties such as: function; material; signal; energy; information; module specifications, etc. At lower levels, semantic data can represent properties such as: power; capacity; temperature, such as optimal temperature; material identifier; material characteristics; durability; heat transfer; input pipe diameter; tank capacity; maximum reactor pressure; maximum capacity, etc.

[0051] An example of semantic data may include one or more attributes encoded by an n-dimensional vector or a conditional vector. In one example, a solid steel having a particular ultra-high durability may be represented as:

[0052] -Zeroth dimension: Property type: "Material" = 0

[0053] -First dimension: Material: "Steel" = 76,

[0054] - Second dimension: aggregation state: "solid" = 3,

[0055] -Third dimension: Durability: "Ultra High" = 10,

[0056] Produces the vector [0,76,3,10].

[0057] A purification process module might require steel as input. Specifically, it might require molten steel: [0,76,2,-] as a precondition, where "2" represents the polymer state: "liquid" and "-" in the third dimension indicates that no durability properties are required. Therefore, it's easy to determine that the given steel [0,76,3,10] does not match the module's precondition [0,76,2,-]. Therefore, the process pipeline requires a precondition melting module that melts the solid material to convert the solid steel [0,76,3,10] into liquid steel [0,76,2,10], thus matching the purification process module's precondition [0,76,2,-]. Specifically, the melting module should have preconditions: [0,-,3,-] and postconditions: [0,-,2,-]. In this example, only four dimensions are specified, but more or fewer properties can of course be specified as conditions or constraints, such as the input pipe diameter, the pressure of the inflowing liquid, and so on.

[0058] In another example involving a cake bakery, white and black doughs (separates) can be processed to produce marble cakes (products). Here, the quantitative state of the white dough material can be represented by [0,1,1,1], where 0 represents the material, 1 represents the dough, 1 represents the white (dough), and 1 represents the quantitative state, and the quantitative state of the black dough material can be represented by [0,1,2,1], where 0 represents the material, 1 represents the dough, 2 represents the black (dough), and 1 represents the quantitative state. The two are processed separately, and the stirred white dough [0,1,1,2] and the stirred black dough [0,1,2,2] are obtained (where the last component with a value of 2 represents the "stirred" state of the dough. Next, the two are combined and baked together to obtain the ready-to-eat cake [0,63,-,-,1,10], where 0 represents the material, 63 encodes "cake", two blank dashes indicate that the state and color are not defined, 1 represents the cake type: "marble cake", and 10 represents "very hot".

[0059] Similarly, a chemical or physical process, including reaction components, side conditions such as temperature or pressure, etc., can be completely described by an abstract condition vector.

[0060] The semantic data model implemented by the resource management system defines the meaning of individual components within an n-dimensional vector and the order in which they appear, ensuring consistency across different instances of semantic data. In one example, the first dimension can describe the overall context, such as material, function, information flow, or energy flow. The second and subsequent dimensions can include additional attributes based on their level of abstraction and statistical significance. In one example, attributes can be specified in the following order: steel, heating, value propagation, and heat transfer.

[0061] The semantic data model can extend the n-dimensional condition vector by implementing linked conditions, such as through (inner or outer) cross products or cross products. In one example, when processing raw hot steel into hot refined steel, not only is the material composition important, but also the heat transfer that occurs, as the steel must remain hot. Here, both the material and the heat transfer can be represented via the condition vector, and because they influence each other, they can also be represented via cross products.

[0062] Based on the order in which the components are defined in the condition vector, the resource management system can prioritize one component over other components, such as in a pipeline generation algorithm, as described further below.

[0063] Furthermore, the semantic data model can define semantic device patterns, where at least one attribute represented by a component of an n-dimensional vector defines a limit or range, such as a [minimum / maximum] value or an [operating point + / - minimum] value. The limit can be expressed as a function of other parameters, such as the minimum and maximum pressure p depending on temperature: p_min / max = f(temp). The limit can be automatically derived from device specification documents such as MTP files or can be provided by the device operator or device engineer. Pattern definitions can facilitate high-level pattern verification and module control.

[0064] Furthermore, the semantic data model may provide a semantic description of a module specifying a plurality of services provided by the module, and / or nesting of modules (modules within modules, eg, a stirring module within a heating module).

[0065] The resource management system is therefore configured to implement a semantic data model that provides one or more of the following: modeling of preconditions and postconditions with one or more attributes, each attribute with optional further annotations, optionally recursive; matching of preconditions and postconditions, optionally with multi-indexed components and annotations; feedforward / feedback of pre / postconditions (for example, if a stirring module requires a dispensing component at a temperature of 45 degrees as a precondition, this is fed back to the previous heating module to set the target temperature).

[0066] In this way, the semantic module can consume and produce semantic data using the semantic data model, as described above. The semantic data is available and processed / manipulated in the context of the semantic device process but remains available in the context of the semantic device process (perhaps in a different state (raw material for refined oil) or with different annotations (hot or cooled)).

[0067] The semantic description of equipment (such as modules) can be based on information available in the documentation related to the equipment. For example, for modules, a standard description file, such as the MTP that defines the associated modules, can be used. The semantic description of a module can include information taken from the documentation and converted to conform to the semantic data model. However, it should be understood that the semantic description disclosed herein can be based on standards other than the MTP. The MTP can be considered a type description that specifies the construction plan for the module. For example, the MTP specifies module I / O (information technology terms, material technology terms; each with a name and ID), module topology, HMI, state machine (this can be the same for all MTPs, but with services indicating which states are actually used), services (only names), and recipes. However, the module provider does not necessarily understand the applications or equipment processes in which the module can be used. Therefore, the MTP does not provide description fields for all attributes of interest to equipment operators. Therefore, to cover process knowledge and provide a standardized vocabulary to describe this process knowledge, the module library wraps or extends the MTP with a wrapper that includes an extended semantic description of the module.

[0068] Figure 1 A plurality of semantic modules 102 are shown that have been assembled to form a semantic pipeline 104. Here, a "semantic pipeline" may be understood as instance data that describes a pipeline of one or more semantic modules using a semantic data model, and may also be referred to as an "implicit pipeline", "pipeline representation", "pipeline description" or "pipeline definition". As shown, each semantic module 102 is based on a standard description file (here MTP) for the semantic module 102. The module library 100 includes a semantic control layer that extends the MTP according to the semantic data model using a wrapper that includes an extended semantic description of the module. The underlying MTP is implicit and cannot be directly accessed. The semantic description is machine readable and machine processable. As shown in FIG. Figure 1The semantic description shown extends the MTP by including, among other attributes, input / output attributes, functions, parameters, and collected usage data. However, it should be understood that this arrangement is not intended to be limiting. The semantic description can be further extended by including mappings to, for example, the Asset Management Shell (AAS) IEC-63278-1ACD, ISO-15926, IEC-62424, Blanco-XML, and PA-DIM. The semantic description can be further extended by including a set of basic operations, such as those defined in SkamPi (VDI Richtlinie 2776). SkamPi comes with 15 basic operations that describe services (e.g., homogenization, heating, metering, etc.) and their typical process technology attributes (e.g., pressure, volume, current, pressure gradient, heating power, accuracy, concentration, etc.) to enable comparison and consistency between process requirements and FEA / PEA capabilities. Furthermore, the parameters and setpoints of these elementary operations can be related, allowing elementary operations in one module to be linked and checked against elementary operations in another module, such as parameters, values, minimum and maximum values, etc. These can be used to describe more complex module services / functionality, for example, as a chain of subsequent elementary operations. For example, a high-temperature mixing module can be represented as a series of heating and mixing elementary operations.

[0069] In an exemplary semantic description of a module including a tank, the MTP contains the input / output characteristics of the tank and describes the functionality of the tank in terms of its liquid storage capacity, while an extended semantic description covers other aspects such as pressure limits, minimum / maximum temperatures, other tolerance boundaries, etc.

[0070] In another exemplary semantic description of a module including a reactor, the MTP allows for the definition of inputs and outputs, while the extended semantic description defines, for example, the ratio of two inputs H2 to O2 to be reacted in the reactor (e.g., 2 / 3 H2 and 1 / 3 O2), and optionally the desired / optimal reaction temperature and pressure (and potential critical values / thresholds). Furthermore, the semantic description can also specify that the pipeline connecting the reactor to possible other preceding or subsequent units in the pipeline has a diameter of 0.5 meters, so that a translation flange is required in the case where the connecting unit has an input / output pipe with a diameter of only 0.25 meters.

[0071] The extended semantic description can distinguish between continuous and batch processing units: for example, a batch processing module can process 100 L of liquid per execution, while a continuous process module processes 100 L of liquid per hour and must therefore be (continuously) supplied with liquid to avoid downtime.

[0072] As will be described in more detail below, the semantic description allows—among other possibilities—semantic module-to-module matching (pipeline generation), sanity checks useful for pipeline generation, device process simulation (i.e., providing initial inputs and obtaining simulated final outputs to determine whether the device operates as expected), device- and module-based optimization, and calibration and automation (e.g., finding bottlenecks, such as what would happen if module 1, which is connected to module 2, was set to produce a higher output such that module 2 reached or exceeded its tolerance boundary and entered a critical state).

[0073] The module library can assist the equipment operator in supervising / managing the inventory of existing modules (e.g., 12 metering units and 10 reaction units, etc.). Some modules may be currently in use in the equipment, while others are not. For the modules in use, data about their usage (e.g., what materials are processed) or the performance of their components (e.g., uptime, valve material wear), maintenance key performance indicators (KPIs, such as module life cycle), etc. can be collected and continuously added to the database. When a new equipment is to be built or an existing equipment is to be reconfigured, the equipment operator can review the module library and refer to the semantic description including the collected usage data to select the best module for a given function. For example, the equipment operator can simply select an available module that processes the same material as the material that the module being sought is expected to process and has the longest time before the next scheduled maintenance.

[0074] Using a module library, equipment operators can select and reuse predefined (preconfigured) existing modules from a pool, reducing the required design effort. In this way, not only the reuse of individual modules but also the reuse of larger functional blocks is facilitated, thus simplifying the task of module design and modular equipment assembly.

[0075] Furthermore, in cases where a real version of a module is not yet available in the pool, the system can provide functionality that allows a facility operator to determine whether a particular pipeline can be assembled for a given new facility using virtual modules in the pool. By providing semantic descriptions of modules, a mechanism is provided for manually and / or automatically finding and recommending feasible or optimal module and pipeline combinations for a newly planned modular facility. These recommendations can be based not only on the compatibility of the modules as determined via the semantic descriptions, but also on specific optimization criteria, as explained further below.

[0076] Thus, a module-based virtual design of equipment processes is provided. The module library thus provides equipment operators with an intelligent, information-enhanced pool of units. This improves the usability and comfort of software tools for equipment operators, reduces errors in unit setup within the equipment, and optimizes equipment performance. All information within the equipment environment can be collected and aggregated in the module library, providing a single access point and unified interface for comprehensive information within the equipment context. This makes the information searchable and reveals optimization potential, while also providing a foundation upon which other AI-based applications and algorithms, such as pipeline generation or optimization, can operate.

[0077] It should be understood that the examples given herein are for illustrative purposes only, and that many forms of semantic descriptions are possible depending on the module being described. In any case, the extended semantic descriptions disclosed herein are provided to encompass design knowledge, including any or all important design facts, that are useful to the device operator so that the unit is fully describable semantically.

[0078] As mentioned above, the resource management system allows equipment operators to select and combine units from the module library to form pipelines. Using the module semantic description provided by the module library, the equipment operator can determine the compatibility of modules based on various module properties. For example, Figure 1 As shown, a device operator selects semantic modules 102 based on their I / O compatibility to form a semantic pipeline 104 (ie, a representation of a physical pipeline).

[0079] However, as described above, a mechanism is provided for automatically finding and recommending (e.g., consistent and optimal) module and process pipeline combinations for modular devices via semantic descriptions and collected usage data. To this end, the resource management system may also include a module pipeline generation engine configured to receive input data indicating at least one precondition and at least one postcondition of a pipeline required for the modular device, and generate one or more recommended module pipelines, including one or more modules capable of converting at least one precondition into at least one postcondition. The pipeline engine may also be referred to as a pipeline combination engine. The module pipeline generation engine may be configured to select one or more semantic modules from a module library for inclusion in the module pipeline based on module properties contained in the semantic description of the module library. In particular, the pipeline generation engine may be configured to access the module library, each semantic module in the module library having semantically annotated preconditions and postconditions (e.g., (multiple) educts and (multiple) products), and determine whether a connection (i.e., a path) can be found / built from (multiple) preconditions to (multiple) postconditions through a set / chain of modules through progressive or incremental processing. For example, each module takes one (or more) inputs as preconditions and transforms them into one (or more) outputs as postconditions, which in turn are inputs (i.e., preconditions) for the next module, which are then processed into the next outputs (i.e., postconditions), and so on. The pipeline generation engine ensures module-to-module and pipeline compatibility by definition, as it only allows modules that are compatible according to the semantic description to be combined into a row. The generated proposed pipeline can include sub-pipelines connected in parallel and / or sequentially.

[0080] This disclosure contemplates various module properties that may be available for selecting a module.

[0081] In particular, the module pipeline generation engine can be configured to determine a sequence of one or more semantic modules to form a module pipeline based on the input / output properties of the semantic modules, wherein the input properties of the first module in the sequence match at least one precondition and the output properties of the last module in the sequence match at least one postcondition. The module pipeline generation engine can be configured to generate a module pipeline using a plurality of semantic modules selected from a module library to provide inter-module compatibility of the corresponding modules. The module pipeline generation engine can be configured to determine inter-module compatibility based on the corresponding module properties. The module properties indicating inter-module compatibility can include input and output properties of the selected semantic modules. The module pipeline generation engine can therefore be configured to select semantic modules for inclusion in the proposed pipeline based on the input and output compatibility of the corresponding modules. Within the module sequence thus determined, modules are thus selected such that the module's output properties match the input properties of any subsequent module and the module's input properties match the output properties of any preceding module. Matching preconditions and postconditions and determining inter-module compatibility are preferably, but not necessarily, performed using an n-dimensional condition vector, as described above with reference to the semantic data model, optionally using any pattern or priority implemented by the model.

[0082] Additionally or alternatively, the module pipeline generation engine can be configured to determine a sequence of one or more modules to form a module pipeline based on functional attributes of the modules in the pool, the functional combination of the module pipeline to convert at least one precondition to at least one postcondition. In this case, the attributes indicating compatibility between the modules can include attributes defining the module functions, and the module pipeline generation engine is configured to generate a proposed pipeline based on the functional compatibility between the selected modules. For example, where a module requires a minimum temperature at an input, the pipeline generation engine can select a heater module as the previous module in the proposed pipeline.

[0083] Thus, the pipeline generation engine is configured to use the semantic descriptions of the modules provided by the module library to automatically generate suggested pipelines to be provided to equipment operators (who would otherwise have to manually select, combine and assemble the modules).

[0084] The pipeline generation engine may include one or more of the following: (1) graph generation and path finding algorithms; (2) rule-based algorithms.

[0085] The graph generation and path finding algorithm (or graph construction algorithm) is configured to connect the starting node (e.g., the educt of the equipment process) to the end node (e.g., the product of the equipment process). The graph and its nodes represent modules connected via edges representing module-to-module connections. The algorithm can be used alone or in combination with other algorithms to speed up pre / postcondition matching by limiting the set of modules to be matched. Typically, the algorithm can be configured to perform forward propagation and / or backward propagation using preconditions and postconditions. Forward propagation can be performed to construct a graph (graph data structure) with edges and nodes suitable for direct further processing, possible parallel sub-pipelines merged into one, or a pipeline split into two or more parallel sub-pipelines, etc. The algorithm may include a memory function for remembering processed edges, for example to facilitate selection between alternative combinations. Non-directed graphs can be supported.

[0086] Rule-based algorithms can form a part of an expert system or domain knowledge representation system configured to implement expert rules. As mentioned above, rule-based algorithms can use the same vocabulary / ontology as defined by the semantic data model. Exemplary rules include rules that require the above-mentioned input-output compatibility and functional compatibility. Other rules can describe process knowledge or design know-how (e.g., chemical process knowledge, or pipe-to-module flanging design know-how). Other rules can specify that, for example, some equipment processes always need a refinement module, which does not necessarily change the I / O material, but is necessary for higher quality product results, and some equipment processes always need specific process technology rules (e.g., a separator module should separate liquids by a distillation process and separate solids by a screening process). Other rules can describe best practices (e.g., a sub-pipeline that runs well in the previous device, a module that is well calibrated in the previous device, etc.). Other rules can indicate context dependencies, for example, a separator module in a batch process converts solids with a sieve, and a separator module in a continuous process converts liquids with a distiller. Other rules can indicate allowed and disallowed sub-pipeline combinations. For example, a rule can specify that in a cake baking pipeline, a baking module should not be used before a mixing module. Other rules can indicate requirements for sequential or parallel processing. For example, for a cake baking pipeline that uses black and white dough to produce marble cakes, a rule can indicate that the black and white doughs need to be prepared separately (i.e., in parallel sub-pipelines) until the baking step. The pipeline generation engine can therefore include a rule-based, data-driven execution engine.

[0087] The pipeline generation engine may be configured to execute other data and knowledge driven algorithms that support the module pipeline connection process, as well as optimization processes and ranking algorithms that integrate and process KPIs, module characteristics and all other types of available useful data.

[0088] Figure 2An automatically generated suggested semantic pipeline 204 is shown, comprising a series of semantic modules 102 from given inputs (here, "educt A" and "educt B") to a desired output "product Z." Also shown is a pool of intelligent units 200 provided by a module library from which semantic modules 102 can be selected. As described above, each semantic module 102 is based on the MTP of the corresponding module wrapped by an extended semantic description together with optional collected usage data.

[0089] In this example, given input materials, educt A and educt B, the plant operator desires to obtain output material, product Z. Therefore, the plant operator inputs the input and output materials as preconditions and postconditions, respectively, to the pipeline generation engine. A suggested semantic pipeline 204 for transforming educts A and B into product Z is generated by the pipeline generation engine by identifying a selection of semantic modules 102 that transform educt A into intermediate material C, then into intermediate material D, in the specific order shown. Intermediate material D is combined with intermediate material E obtained from educt B to obtain intermediate F, and so on, until product Z is obtained. The suggested semantic pipeline 204 is based on knowledge of the semantic representations of what the underlying modules do, i.e., what inputs they accept and what outputs they produce, or what functions they have, as explained elsewhere herein. The pipeline generation engine in this example uses a rule-based, data-driven execution engine that checks the compatibility of modules (e.g., I / O compatibility) and runs through the suggested semantic pipeline 204 while determining the input for the next module until the entire pipeline is automatically generated to process the given input material into the requested output material. Figure 2 The I / O compatibility of the modules in the proposed semantic pipeline 204 is further illustrated by using hashes to indicate the different I / O properties of the modules. In this way, the pipeline generation engine simplifies the design of the device and reduces the design effort.

[0090] Although the modules in the above examples are linked in a pipeline based on I / O compatibility, it will be appreciated that the pipeline generation engine can be configured to suggest pipelines based on other attributes (such as functionality, parameters, and other properties) that can be automatically linked together in a pipeline and use or replace compatible I / O processing chains. By utilizing semantic descriptions, the pipeline generation engine is configured to build pipelines based on any type of module attributes and corresponding pre- and post-conditions.

[0091] As mentioned above, one such exemplary attribute is functionality. Thus, the pipeline generation engine can generate a pipeline based on a sequence of functions to achieve the overall functionality of the planned pipeline. In another example, only one material, X, will be processed from an initial raw state to a final refined state within the newly generated process pipeline (while the material's identity as Material X remains essentially unchanged). The pipeline generation engine is configured to generate a pipeline of semantic modules whose functions build upon each other: for example, first a grinding module, then a heating module, then a stirring module, and finally a cooling module. The first module has a precondition of "raw material in raw state," and its postcondition is "material grounded." The second module has a precondition of "material grounded," and its postcondition is "material heated and stirred." Along with this, there may be parameters that can be manipulated to specify the temperature. The third module is for stirring, with a precondition of "material hot enough for stirring," the same threshold parameters as in the second module, and a postcondition of "material stirred, ready for cooling." The final module has a precondition of "material ready for cooling" and a postcondition of "material in transportable state," possibly with a temperature parameter. In this case, the “function” attribute in the semantic description can be used by the pipeline generation engine to perform matching and path finding based on the pre- and post-conditions of the module functions.

[0092] The semantic modules selected by the pipeline generation engine for inclusion in the proposed pipeline can correspond to real and / or virtual modules. In the event that at least one real module is included in the proposed pipeline, the pipeline generation engine can act to prevent the real module from being reused (at least temporarily) in another manually or automatically generated pipeline. Thus, the pipeline generation engine automatically accounts for shared operator activities while ensuring that a globally optimal solution for the generated pipeline can be found (as explained in more detail below).

[0093] In either of these approaches, the system provides the facility operator with automatic generation of suitable / feasible pipeline suggestions as to how to construct a new pipeline for a given purpose.

[0094] Although pipeline generation has been described with reference to a module library and its semantic data model, it will be appreciated that other data sources and forms may be used to define the modules and their inputs / outputs and functionality.

[0095] As described above, the resource management system may include an optimization component. The optimization component is configured to: receive data identifying the desired module type to be assembled into a modular device as part of a module pipeline comprising one or more modules; and execute an optimization algorithm to select modules for inclusion in the module pipeline from a plurality of modules having the desired module type in a module library based on one or more predetermined optimization criteria. The module pipeline generation engine may be configured to generate a plurality of suggested pipelines for comparison based on the one or more predetermined criteria. The optimization component may be configured to compare or rank (using, for example, a ranking component) a plurality of pipelines (e.g., pipelines suggested by the pipeline generation engine) based on the one or more predetermined criteria. The optimization algorithm may be configured to perform local optimization to optimize only the aforementioned module pipelines, or to perform global optimization to select a plurality of modules of the desired type to be assembled into corresponding module pipelines in the modular device. The predetermined optimization criteria may include one or more of the following: product quality; throughput; capacity; resource / material efficiency; energy efficiency; energy consumption; service time; uptime; equipment availability; mean time between failures; service and equipment utilization; minimizing module usage. In particular, where the collected usage data includes previously measured key performance indicators, these may be used to determine the best or preferred selection and sequence of modules for converting precondition(s) to postcondition(s) when predetermined criteria are met.

[0096] Regardless of whether the pipeline is generated manually or automatically, the module library may include several semantic modules of a specific type, from which a choice can be made as to which one or which one is most suitable for a given purpose. For example, these replaceable modules may have different characteristics, for example, one module may be larger, i.e. have a larger capacity with respect to how much liquid it can distill, or one module may have less operating time remaining before being put into use. Therefore, when planning a production process, the question arises which module to use. To this end, the design tool also includes an optimization component that is configured to optimize the pipeline (wherein a plurality of unit selections are available) based on one or more predetermined criteria. As described above, each semantic module in the module library includes a semantic description that describes or represents the underlying module, whereby the underlying module is enriched with real data that is semantically mapped in a structured manner. The optimization component is configured to perform the optimization using the module properties contained in the semantic description.

[0097] The present disclosure contemplates various optimization criteria that can be used by the optimization algorithm. The optimization criteria can correspond to, relate to, or be based on the content of the semantic description above, optionally including the collected usage data. Exemplary optimization criteria include: uptime, capacity, energy efficiency, energy consumption, maintenance intervals / cycles, service time, the material or medium most recently used in the unit or its type, equipment availability, unit availability, unit schedule (when it becomes reusable), mean time between failures (MTBF) of the unit or its equipment, service and equipment utilization (e.g., frequency of valve opening or closing), resource / material efficiency, minimizing module usage, or any other suitable KPI. The resource management system can also store (e.g., in the same database) data related to previously used module combinations, which indicates the results of the modular equipment in terms of quality, throughput, efficiency, or other KPIs to assist in evaluating whether the modules in a particular combination are operating successfully together. The optimization component uses these criteria to make intelligent and automatic selections of modules that are available or best suited for the modular equipment to be designed or assembled. For example, data identifying the medium flowing through a module can be used to determine whether a module requires extensive cleaning before it can be used in another equipment. The collected usage data can be used to find the best possible module for the current plan according to the respectively selected optimization criteria.

[0098] The optimization component is configured to receive a pipeline that is manually or automatically generated as described above and includes one or more representations of real or virtual modules or their types. Minimize / maximize the selected one or more optimization criteria on the set of modules in the pipeline by executing an optimization algorithm that utilizes semantic data describing the different characteristics and constraints of the modules to optimize the selected criteria. The optimization algorithm is therefore configured to find the best module combination for the pipeline. This may involve completely excluding one or more modules in the received (input) pipeline from the pipeline, or replacing or exchanging these modules with alternative more suitable modules. Based on the semantic description, including, for example, collected usage data (e.g., KPIs), the optimization algorithm finds the module combination that results in, for example, the highest quality of the product, the highest throughput, the highest energy efficiency, etc.

[0099] The optimization algorithm can be implemented using a machine learning model that is trained to select modules based on semantic descriptions of the modules and optionally also based on data indicating how combinations of modules have performed in the past, e.g., which modules have been selected frequently to coexist in the past and which modules coexist well.

[0100] The optimization results can be visualized to the user, optionally including instructions on how to find the best configuration of modules. The user then selects the final configuration.

[0101] If more than one criterion is optimized, the result may be two or more locally optimal generation pipelines that are suggested to the equipment operator to decide which criterion is considered more important for global optimization. The optimization component may again use a ranking function (i.e., a ranking component) to rank the two or more pipelines according to the selected or predetermined criterion.

[0102] The optimization can be local, targeting only a given pipeline, or it can be a global optimization that dictates how available module resources should be distributed across multiple pipelines. For example, if a module has little remaining runtime before service, it may turn out that this runtime is still long enough for the planned batch production, so from a global optimization perspective it would be best to use that module, leaving other similar modules with more runtime available for other possible batch production processes. Alternatively, it could be the case that a module is flexible and could theoretically be used for many production processes, while another more specialized, interchangeable module would perform the same function, so global optimization would recommend using the more specialized module to save the more flexible module for other possible processes that might be needed.

[0103] The modules selected by the optimization component can include real and / or virtual modules. For example, virtual pipeline A may be preferred over virtual pipeline B because it consumes less energy overall, without requiring optimization based on real module data. However, real modules can be selected to account for specific optimization criteria based on collected usage data, such as to determine whether a real module is actually available in the real unit pool or is subject to maintenance, for example.

[0104] Figure 3 An example of a semantic pipeline 304 using an optimization component to optimize a semantic module is shown. Figure 3 As shown, the smart unit pool 200 managed by the module library includes a virtual unit pool 300 and a real unit pool 302. The virtual unit pool 300 includes virtual units in the form of module type packages (MTPs) that define module types. Each module type appears only once in the virtual unit pool 300 ( Figure 3Shown are the module types defined by MTP1-MTPn). The real units in the real unit pool 302 correspond to the types found in the virtual unit pool 300 and can be associated with the collected usage data. In this example, the equipment operator has multiple real units of different types, here 3 real metering units, 2 real reaction units. In a first step, implicit pipelines are generated manually or automatically (as described above) using certain types of virtual units, and in a second step, the optimization component executes an optimization algorithm to replace these virtual units by representations of real units of a given type selected from the real unit pool 302 in order to prefer one real unit over another real unit according to a given optimization criterion. The optimization results are displayed to allow the equipment operator to view different equipment composition alternatives and their advantages and disadvantages. In Figure 3 In the example shown, the optimization component identifies two candidate reaction units (a reaction unit of module type MTP1 selected as the first module of the pipeline) and three candidate metering units (a metering unit of module type MTP4 selected as the second module of the pipeline) from the pool of real units 302 that can be used to obtain a specific product. In this example, the optimization component selects reaction unit 306 and metering unit 308 for pipeline 304 based on the collected usage data stored in the semantic descriptions of the corresponding semantic units, together with a predetermined optimization criterion. For example, if the predetermined criterion is to maximize module uptime, the optimization algorithm may select units 306 and 308 because they have a longer MTBF and / or a longer time to the next scheduled maintenance than the other candidate units.

[0105] The optimization component can additionally or alternatively be used to optimize a pipeline that includes semantic modules corresponding to real modules, such as a pipeline input by an engineer. In another example of a local optimization scheme, where the pipeline for the initial production plan prepared by the engineer includes a selected distillation module that is oversized and therefore consumes too much energy, the optimization component selects an alternative, smaller distillation module that is sufficient to meet the planned batch size.

[0106] Although the optimization component is described above with reference to the use of semantic descriptions including collected usage data, which is described above as conforming to a semantic data model, it will be appreciated that data from any suitable other source and in any suitable format may be used for optimization.

[0107] To assist plant operators in validating module / pipeline selections, the resource management system may include a simulation component or tool configured to provide simulation functionality to allow simulation of the operation of a modular pipeline comprising one or more modules in a modular plant (whether the pipeline is manually or automatically generated, and whether or not automatically optimized), for example, to identify possible bottlenecks and inefficiencies, try alternative modules to determine whether this optimizes the simulation, or generally simulate "what-if" scenarios. For example, a plan may begin with an initial flow diagram in the form of a pipeline manually generated by a user to represent the modules and how they are connected, defining the type of flow the user has in mind. This pipeline is likely suboptimal. The user can utilize the design tool's simulation functionality to simulate different what-if scenarios to discover suboptimal configurations. For example, the user can simulate what would happen if an alternative distillation module were used instead of the currently selected larger distillation module or a distillation module with a longer service life. The simulation component can be automatically configured to simulate different what-if scenarios (i.e., alternative configurations / arrangements) and compare the results. The number of scenarios may depend, in practice, on, for example, the time the planner wants to invest in the simulation.

[0108] A resource management system as described herein may be provided:-

[0109] Serves as a central unit pool for multiple equipment operators. This central pool includes a set of semantic modules that correspond to modules previously used by equipment operators and include semantic descriptions as well as usage data collected from delegated equipment. This facilitates both local unit-centric optimization and global, contextual optimization of the pipeline within each unit. This solution is cloud-based, scalable, and easily accessible.

[0110] o As a private unit pool managed by the equipment operator. A private unit pool allows the equipment operator to manage and oversee a collection of semantic modules corresponding to the equipment operator's real modules. Parameters, KPIs, and other collected usage data (best practices, calibration parameter combinations, maintenance intervals, MTBF, last maintenance completed, last material used, cleaned or not, active / available / unused, etc.) are collected from the real modules and uploaded to a database to enable the application of the system's pipeline generation engine and optimization components. Both on-premises implementations and cloud-based solutions are possible, depending on the equipment operator's wishes and requirements.

[0111] oAs an internal product to reduce costs for equipment operators, or as an offer to clients to reduce their own costs.

[0112] The topics described in this article can find particular application in module-based production and resource planning. This is especially true in the production of small pharmaceutical batches, where module resources are frequently exchanged between batches. When planning a new batch, or redesigning the module setup for an existing batch (e.g., because the production load has changed and the existing module selection appears to be a bottleneck), the topics described in this article will allow planners to identify and select the correct, i.e., most suitable, modules.

[0113] The topics described in this article can find other applications in module maintenance planning. Modules require periodic maintenance and have characteristics such as "service time," which indicates how much operating time remains before the next scheduled service inspection. Here, optimization and what-if simulations can assist in determining the optimal maintenance schedule for a module. For example, with the help of a known production schedule that specifies how different modules will be used in the near future, an example optimization scenario would be to perform maintenance on a module earlier than planned because it would not be in use at that time, ultimately resulting in better utilization and process output.

[0114] Thus, the benefits provided by the resource management system described herein include, among others, (1) reuse of modules and hence reduction of design effort through a searchable module pool; and (2) simplified or automatic generation of viable pipelines that are (i) directly compatible through semantic checking and control, and (ii) capable of being optimized for various criteria, such as uptime, maintenance intervals, availability, etc.

[0115] Now refer to Figure 4 , shows a high-level diagram of an exemplary computing device 800 that can be used in accordance with the systems and methods disclosed herein. In particular, the computing device 800 can be used to implement the resource management system or design tool described above, along with its pipeline generation engine and optimization components. The computing device 800 includes at least one processor 802 that executes instructions stored in a memory 804. For example, the instructions can be instructions for implementing the functions described as being performed by one or more of the components described above, or instructions for implementing one or more of the methods described above. The processor 802 can access the memory 804 via a system bus 806. In addition to storing executable instructions, the memory 804 can also store session inputs, scores assigned to session inputs, and the like.

[0116] The computing device 800 further includes a data store 808 accessible by the processor 802 via the system bus 806. The data store 808 may include executable instructions, log data, etc. The data store 808 may be used to implement the module library and its database described above.

[0117] The computing device 800 also includes an input interface 810 that allows external devices to communicate with the computing device 800. For example, the input interface 810 can be used to receive instructions from external computer devices, users, etc. The computing device 800 also includes an output interface 812 that interfaces the computing device 800 with one or more external devices. For example, the computing device 800 can display text, images, etc. through the output interface 812. It is contemplated that in an environment that provides essentially any type of user interface with which a user can interact, an external device that communicates with the computing device 800 via the input interface 810 and the output interface 812 can be included. Examples of user interface types include graphical user interfaces, natural user interfaces, etc. For example, a graphical user interface 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. In addition, a natural user interface can enable a user to interact with the computing device 800 in a manner that is not constrained by input devices such as a keyboard, mouse, remote control, etc. In contrast, natural user interfaces can rely on speech recognition, touch and stylus recognition, gesture recognition on and near the screen, mid-air gestures, head and eye tracking, voice and sound, vision, touch, gestures, machine intelligence, and more.

[0118] Furthermore, although shown as a single system, it should be understood that the computing device 800 may be a distributed system. Thus, for example, several devices may communicate via a network connection and may jointly perform the tasks described as being performed by the computing device 800.

[0119] The various functions described herein can be implemented in hardware, software, or any combination thereof. If implemented in software, these functions can be stored on or transmitted through a computer-readable medium as one or more instructions or codes. Computer-readable media include computer-readable storage media. A computer-readable storage medium can be any available storage medium that a computer can access. As an example and not limitation, such a computer-readable storage medium can include RAM, ROM, EEPROM, CD-ROM, or other optical disk storage, magnetic disk storage, or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of an instruction or data structure and can be accessed by a computer. The disks and optical disks used herein include compact disks (CDs), laser disks, optical disks, digital versatile disks (DVDs), floppy disks, and Blu-ray disks (BDs), wherein disks typically reproduce data magnetically, while optical disks typically reproduce data optically with lasers. In addition, propagation signals are not included within the scope of computer-readable storage media. Computer-readable media also include communication media, including any medium that facilitates the transmission 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 a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies (such as infrared, radio, and microwave), then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies (such as infrared, radio, and microwave) are included in the definition of communications media. Combinations of the above should also be included within the scope of computer-readable media.

[0120] Alternatively or additionally, the functions described herein may be performed at least in part by one or more hardware logic components. For example, and not limitation, 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 chip (SOCs), complex programmable logic devices (CPLDs), and the like.

[0121] While the above description is provided in the context of the MTP standard, it should be understood that the present disclosure is not limited to the use of MTP in defining units and other standardized module descriptions may be used.

[0122] Applicants hereby disclose individually each individual feature described herein, as well as any combination of two or more such features, to enable such feature or combination to be implemented according to the common general knowledge of those skilled in the art based on the specification as a whole, regardless of whether such feature or combination of features solves any problem disclosed herein, and without limiting the scope of the claims. Applicants indicate that aspects of the present invention may consist of any such individual feature or combination of features.

[0123] Although the present invention has been described and illustrated in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative rather than restrictive. The present invention is not limited to the disclosed embodiments. Other variations to the disclosed embodiments may be understood and effected by one skilled in the art by studying the drawings, the disclosure, and the appended claims.

[0124] In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single processor or other unit may perform the functions of several items recited in a claim. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. A computer program may be stored / distributed on a suitable medium, such as an optical storage medium or solid-state medium provided with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless communication systems.

[0125] Any reference signs in the claims should not be construed as limiting the scope.

Claims

1. A computer-implemented resource management method for a modular device, the method comprising: receiving data identifying a desired module type to be assembled into the modular device as part of a module pipeline comprising one or more modules, the one or more modules being packaged by a semantic description and the collected usage data, the data including preconditions and postconditions of the module pipeline; executing an optimization algorithm to select a module for inclusion in the module pipeline from a plurality of modules having a desired module type and based on the data based on one or more predetermined optimization criteria and module properties of the modules; as well as Based on input properties and output properties of each module in the one or more modules, a sequence of modules in the module pipeline is determined to match preconditions and postconditions of the module pipeline. 2 . The method of claim 1 , further comprising simulating operation of one or more candidate pipelines, each of the one or more candidate pipelines comprising at least one module of the plurality of modules having the desired module type.

3. The method of claim 2, wherein the optimization criteria comprises one or more of capacity, energy consumption, and service time, and wherein the optimization algorithm identifies one or more bottlenecks or inefficiencies in the simulated operation of the candidate pipeline. 4 . The method according to claim 2 , comprising presenting the results of the simulation to a user and receiving a selection of the candidate pipeline by the user.

5. The method of any one of claims 1 to 3, wherein the optimization algorithm utilizes a machine learning model that is trained to select modules for inclusion in a module pipeline based on one or more of module attributes and collected usage data related to the modules.

6. The method according to any one of claims 1 to 3, wherein the optimization algorithm performs local optimization to optimize only the module pipeline.

7. The method according to any one of claims 1 to 3, wherein the optimization algorithm performs a global optimization to select a plurality of modules of a desired type to be assembled into corresponding module lines in the modular device.

8. A method according to any one of claims 1 to 3, wherein the predetermined optimization criteria include one or more of the following: product quality; throughput; capacity; resource / material efficiency; energy efficiency; energy consumption; service time; uptime; equipment availability; mean time between failures; service and equipment utilization; minimization of module usage.

9. A method according to any one of claims 1 to 3, wherein the optimization algorithm utilizes module properties of the plurality of modules, the module properties comprising one or more of the following: module functionality; module parameters; module usage data; input / output properties; process parameters; calibration parameters.

10. A method according to any one of claims 1 to 3, wherein the optimization algorithm utilizes usage data collected related to previous usage of the multiple modules in the modular equipment, and the collected usage data is related to one or more of the following items: mean time between failures; module uptime; service and equipment utilization; previous calibration parameters; frequent equipment background; maintenance execution; material / media handling; application purpose and limitations of chemical reactions; module availability schedule; maintenance cycles / intervals.

11. The method of any one of claims 1 to 3, wherein the optimization algorithm utilizes data indicative of performance of previous module combinations to select the modules for inclusion in the module pipeline.

12. The method of any one of claims 1 to 3, wherein the optimization algorithm selects a plurality of candidate modules for inclusion in the module pipeline from the plurality of modules having the required module type and ranks the candidate modules according to the one or more predetermined optimization criteria.

13. A computing device comprising a processor configured to perform the method according to any one of the preceding claims.

14. A computer-readable medium comprising instructions which, when executed by a computing device, enable the computing device to perform the method according to any one of claims 1 to 12.

Images