Resource management for modular devices

Abstract

Embodiments of the present disclosure relate to resource management for modular devices. There is a need for more efficient resource planning for modular devices. Therefore, a resource management system for modular devices is provided. The system comprises a database providing a library of semantic modules representing respective modules in a pool of modules, at least one of the semantic modules comprising a semantic description of the respective module, wherein the semantic description comprises abstract data conforming to a semantic data model, and wherein the abstract data describes properties of the respective module not found in a standard description file for the module. Based thereon, the system facilitates the automatic generation and optimization of a module pipeline.

Description

Technical Field

[0001] This invention relates to a resource management system for modular equipment. Background Technology

[0002] The Modular Type Package (MTP) standard in the field of 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, with the goal of simplifying process equipment design and lifecycle management. These advantages are achieved through prefabricated and well-tested modules called PEAs (Process Equipment Assemblies), which can be easily placed together in different combinations to achieve different formulations.

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

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

[0005] According to a first aspect, a resource management system for modular devices is provided. The system includes a database that provides a library or repository of semantic modules (module representations) representing corresponding modules in a module pool. At least one of the aforementioned semantic modules includes 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 attributes of the corresponding module 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 include any suitable data or parameters defining the module. For example, module attributes may include one or more of the following: input / output attributes; module functionality; module parameters; process parameters; calibration parameters.

[0006] Therefore, the resource management system provides equipment operators with an intelligent, information-enhanced pool of cells. The resource management system offers improved usability and greater comfort for equipment operators using software tools, reduces the error rate of cell setup within the equipment, and optimizes equipment performance.

[0007] The semantic description may also include usage data collected in relation to the prior use of the corresponding modules in the modular equipment. The collected usage data may include any suitable data characterizing the previous module performance, use, 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 context; maintenance execution; material / media handling; application purpose and limitations of chemical reactions; module availability schedule; maintenance cycles / intervals.

[0008] In this way, the resource management system can assist equipment operators in monitoring / managing their existing module inventory (e.g., 12 metering units and 10 reaction units). Some modules may currently be in use on the equipment, while others may not. For modules in use, data on their usage (e.g., what materials they process) or the performance of their components (e.g., uptime, valve material wear), maintenance key performance indicators (KPIs, such as module lifecycle), etc., can be collected and continuously added to the database. When building new equipment or reconfiguring existing equipment, equipment operators can view the module pool via the module library or repository and select the best module for a given function by referring to semantic descriptions and the collected usage data. For example, an equipment operator can simply select an available module that processes the same material as the sought module is expected to process and has the longest lifespan before the next scheduled maintenance.

[0009] The semantic description may also include prior configuration data related to the configuration of a corresponding module in at least one previous modular device, which can be used to configure the module for use in another modular device. The prior configuration data may relate to prior design data for accelerating module reuse.

[0010] Therefore, this technology platform enables equipment operators to select and reuse pre-configured modules. This facilitates not only the reuse of individual modules but also the reuse of larger functional blocks, thereby simplifying the tasks of module design and modular equipment assembly.

[0011] Furthermore, a mechanism is provided, through semantic descriptions and collected usage data, for automatically finding and recommending optimal combinations of modules and process pipelines for modular devices. 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 for the desired pipeline of the modular device, and to generate suggested semantic module pipelines representing one or more modules capable of translating at least one precondition into at least one postcondition. The module pipeline generation engine can 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 modules. This disclosure contemplates various module attributes that can be used to select modules.

[0012] Specifically, 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 attributes of semantic modules in a module library. In this semantic module pipeline, the input attribute of the first semantic module in the sequence matches at least one precondition, and the output attribute of the last semantic module in the sequence matches 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 for the selected modules. The module pipeline generation engine can be configured to determine inter-module compatibility based on corresponding module attributes. Module attributes indicating inter-module compatibility can include the input and output attributes of the selected modules. The module pipeline generation engine can therefore be configured to select modules to be included in the proposed pipeline based on the input and output compatibility of the selected modules. In the thus determined sequence of modules, modules are selected such that the module's output attribute matches the input attribute of any subsequent module and the module's input attribute matches the output attribute of any previous module. Semantic data describing attributes conforming to a semantic data model (i.e., using the language and vocabulary of a semantic data model) can be used to compare and match input and output attributes in this way.

[0013] 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 the functional attributes of semantic modules in a module library. This module pipeline's functionality is combined to transform at least one precondition into at least one postcondition. In this case, attributes indicating inter-module compatibility may include attributes defining module functionality, and the module pipeline generation engine is configured to generate suggested pipelines based on the functional compatibility between the selected modules. For example, if a module requires a minimum temperature at an input, the pipeline generation engine could select a heater module as the preceding module in the suggested pipeline. Similarly, semantic data describing attributes conforming to a semantic data model can be used to compare and match attributes defining module functionality.

[0014] Pipeline generation can therefore take the form of a rule-based, data-driven execution engine (or composition engine), where exemplary rules include input / output compatibility and functional compatibility. The rules themselves can be defined by semantic data based on a semantic data model or can utilize semantic data.

[0015] In any of these approaches, the system provides the equipment operator with the automatic generation of suitable / feasible pipeline recommendations on how to construct new pipelines for a given purpose.

[0016] The resource management system may include an optimization component 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 semantic modules representing modules to be included 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. A module pipeline generation engine may be configured to generate multiple suggested pipelines for comparison based on 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 multiple modules of the desired type to be assembled into the corresponding module pipeline in the modular device. 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. Specifically, where the collected usage data includes previously measured key performance indicators, these may be used to determine the optimal or preferred selection and sequence of modules for converting (multiple) preconditions into (multiple) postconditions when the predetermined criteria are met. When the optimization component selects multiple candidate modules from a number of modules having the desired module type to include in the module pipeline, 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 ordered candidate modules for the user to select.

[0017] To assist equipment operators in locating the appropriate modules, the database can be configured to provide search functionality to allow searching the module library.

[0018] To assist equipment operators in validating module / pipeline selections, the resource management system may include a simulation component configured to provide simulation capabilities to allow simulation of the operation of a module pipeline that includes one or more modules from a modular equipment. Additionally or alternatively, the resource management system may include a ranking component configured to facilitate the selection by the equipment operator of the optimal module from a set of possible pipeline options based on a given optimization criterion.

[0019] According to a second aspect, a resource management method for a computer implementation of 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 attributes of the corresponding module not found in a standard description file for the module. Any feature or sub-aspect of the first aspect may also be applied to the second aspect with necessary modifications.

[0020] According to a third aspect, a resource management method for a computer implementation of a modular device is provided. The method includes (e.g., using module pipeline generation as described herein): receiving input data indicating at least one precondition and at least one postcondition for a desired pipeline of the modular device; and determining a proposed module pipeline comprising one or more modules capable of converting at least one precondition into at least one postcondition. Any feature or sub-aspect of the first or second aspect (particularly those described with reference to the module pipeline generation engine) may also be applied to the third aspect with necessary modifications.

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

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

[0023] The method may include presenting the simulation results to the user and receiving the user's selection of the candidate pipelines.

[0024] The optimization algorithm can leverage machine learning models, which are trained to select modules to be included in the module pipeline based on one or more of the module attributes and the collected usage data related to the modules.

[0025] The optimization algorithm can perform local optimization to optimize only the aforementioned module pipeline, or perform global optimization to select multiple desired types of modules to be assembled into the corresponding module pipelines in the modular device.

[0026] The optimization algorithm may utilize one or more of the following: (i) module attributes of multiple modules, and (ii) usage data collected relating to previous use of multiple modules in the modular equipment (the collected usage data relating to one or more of the following: 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 cycle / interval). Additionally or alternatively, the optimization algorithm may utilize data indicative of the performance of previous module combinations to select modules for inclusion in the module pipeline.

[0027] The optimization algorithm can select multiple candidate modules from multiple modules with the desired module type to be included in the module pipeline, and rank the candidate modules according to one or more predetermined optimization criteria.

[0028] Any feature or sub-aspect of the first to third aspects (especially those described with reference to the optimized component) may also be applied to the fourth aspect with necessary modifications, and vice versa.

[0029] According to the fifth aspect, a method for managing resources for modular devices is provided. The method includes performing one or more of the following actions using a resource management system or method as described herein: (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 automated pipeline generation to generate a proposed module pipeline comprising one or more modules; (iii) optimizing the module pipeline comprising one or more modules; (iv) ranking the module pipelines according to various optimization criteria; and (v) simulating the operation of the module pipeline comprising one or more modules. The method may also include assembling the module pipeline into a modular device.

[0030] According to the sixth aspect, a method for creating and / or maintaining the resource management system of the first aspect is provided. The method includes: 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 module wrapper.

[0031] According to a seventh aspect, a computing device is provided, the computing device processor including methods configured to perform computer-implemented methods as described herein.

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

[0033] According to a ninth aspect, a computer-readable medium including instructions that, when executed by a computing device, enable / cause the computing device to perform the computer-implemented methods as described herein.

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

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

[0036] These and other aspects of the invention will become clear and illustrated with reference to the embodiments described below. Attached Figure Description

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

[0038] Figure 1 The diagram illustrates a semantic pipeline that represents the physical pipeline of modular industrial equipment via a series of interconnected semantic modules.

[0039] Figure 2 The illustration shows a semantic pipeline automatically generated by the pipeline generation engine to convert a specific segregant into a given product;

[0040] Figure 3 The diagram illustrates the optimization of the pipeline generation engine for automatically generated semantic pipelines; and

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

[0042] This document describes 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 can be implemented as software, firmware, hardware, or any combination thereof, such as using the computing devices described herein. The resource management system may form part of, or include in, design tools or dashboards 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 modules, module pipelines, or modular devices.

[0043] A module library contains one or more semantic modules stored in a repository such as a database. Semantic modules include instance data of modules that represent, describe, or define a modular device using a semantic data model. Semantic modules can also be described as module representations, module descriptions, or module definitions. In the context of this disclosure, the terms "module" and "unit" are used interchangeably. The module library may store other heterogeneous data items (such as specifiers, comments, values, and history) related to the semantic modules. Therefore, the module library serves as a place (or knowledge representation system) for collecting global and local domain knowledge about modules. 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 components of the modular device can be used to implement a database. In particular, the data storage 808 described below can be used to implement a database. Semantic modules stored in the module library can represent real or virtual, owned (owned by the device operator) or not yet owned (e.g., available for purchase), available (currently used in the device), or potentially available modules. Therefore, a module pool or repository, which 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 later be searched and discovered, and modules can be selected to form a process pipeline. In particular, the module library provides a search function to assist equipment operators in locating the appropriate module.

[0044] As used herein, the term "virtual module" refers to a type or category of modules, while the term "real module" refers to an instance of a specific type of module. Real modules can be implemented as software, firmware, hardware, or any combination thereof. Software modules that provide control configuration for hardware modules can be referred to as "functional modules." For virtual modules, semantic modules can be implemented as templates for specific types of modules, such as heating modules, metering modules, hybrid modules, etc. Templates may include fields that store fixed values ​​valid for all modules of a specific type. Templates may also include one or more placeholders for values ​​that can be set for real modules, and / or one or more preset values ​​that can be changed later. For real modules, semantic modules may include templates for the relevant module type, but supplemented with one or more values ​​representing the real module. In this way, templates contain process or design knowledge via fields within the template.

[0045] Therefore, modules are described using semantic descriptions that conform to a semantic data model. A semantic description can specify any one or more module attributes. Module attributes (also referred to as annotations, properties, characteristics, specifiers, or features) can include any suitable data describing the module. For example, a semantic description can describe a module based on module attributes, which include one or more of the following: input / output attributes, module functionality; module components; module parameters; module usage; process parameters; calibration parameters; and the module's data inputs, processing, and outputs. Semantic descriptions provide a common interface for storing the semantic network stack (i.e., RESTful APIs, accessible via HTTP, etc.). Process pipelines can be generated manually or automatically, as described in more detail below, through matching semantic descriptions between modules.

[0046] Semantic descriptions can specify the relationship between the inputs and outputs of a module. Specifically, a 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 based on input attributes or characteristics, while postconditions can be described based on output attributes or characteristics. Preconditions and postconditions can, for example, specify attributes such as the material identity or material state input to and output from the module, respectively. A module can therefore 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 will react with at least one other educt to form a product. Therefore, the module converts an educt into a product; that is, the material properties are transformed. A module can, for example, transform one material state into another via heating, stirring, refining, etc. "State" in this document refers to any property, characteristic, or condition of a single material, not just its polymeric state. Semantic descriptions can also specify one or more conditions or constraints under which a module transforms preconditions into postconditions. Additionally or alternatively, preconditions and postconditions can specify one or more of the form, structure, or connection modes of the module's inputs and outputs.

[0047] For real modules, the semantic description may also include collected usage data related to the real module's previous use in modular equipment. The collected usage data may include, for example, any one or more of the following: previous design data; previous calibration parameters; frequent equipment background; maintenance performed; material / media handling; application purpose 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 material processed (e.g., nuts, which is important for equipment that processes groceries but also wants to produce groceries for people with nut allergies). Another value may identify non-functional services of the real module (e.g., for an oven module, the value indicates "service fan oven (FanOven) is damaged, but top & bottom plate heat baking (Top & BottomPlate 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 one or more of the following: mean time between failures; uptime; service and equipment utilization; availability schedule; maintenance cycle / interval. Many other examples are known to those skilled in the art. As further described below, such performance data can be used to optimize the selection of pipeline modules.

[0049] Semantic data models provide a general or standardized vocabulary or ontology (linking vocabulary to pre-existing knowledge and rules) for describing modules, module pipelines, and modular devices, as will be described now. Semantic data models can also be described as conceptual or abstract data models. A semantic data model uses semantic information to construct data in a specific logical manner, adding meaning to the data and the relationships that exist within it.

[0050] The “semantic data” used in this paper are abstract data that can represent any attribute of a module, pipeline, device, or material, particularly the input / output attributes of a module represented by its material identity (e.g., input / output material) or material state (e.g., raw or refined, 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 attributes such as: function; material; signal; energy; information; module specification, etc. At lower levels, semantic data can represent attributes 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] Instances of semantic data can include one or more attributes encoded by an n-dimensional vector or conditional vector. In one example, solid steel with specific ultra-high durability is represented as:

[0052] - Zeroth Dimension: Attribute Type: "Material" = 0

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

[0054] -Second Dimension: Aggregation State: "solid" = 3

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

[0056] Generate vector [0,76,3,10].

[0057] The purification process module may require steel as input. Specifically, it may require molten steel: [0,76,2,-] as a precondition, where "2" indicates the polymer state, and "liquid" and "-" in the third dimension indicate that no durability properties are required. Therefore, it can be easily determined 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 to melt the solid material in order 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 a precondition: [0,-,3,-] and a postcondition: [0,-,2,-]. In this example, only four dimensions are specified, but more or fewer properties can certainly be specified as conditions or constraints, such as the input pipe diameter, the pressure of the inflowing liquid, etc.

[0058] In another example, including a cake baking plant, white and black dough (separates) can be processed to produce a marble cake (product). Here, the white dough material in a quantitative state can be represented by [0,1,1,1], where 0 represents material, 1 represents dough, 1 represents white (dough), and 1 represents quantitative state. The black dough material in a quantitative state can be represented by [0,1,2,1], where 0 represents material, 1 represents dough, 2 represents black (dough), and 1 represents quantitative state. These two are processed separately, and the white dough [0,1,1,2] and the black dough [0,1,2,2] are obtained by mixing the two portions (where the last component with a value of 2 indicates the "mixed" state of the dough). Next, the two are combined and baked together to obtain an ready-to-eat cake [0,63,-,-,1,10], where 0 represents material, 63 encodes "cake", the two blank dashes indicate that no state or color is defined, 1 indicates the cake type: "marble cake", and 10 indicates "very hot".

[0059] Similarly, chemical or physical processes, including reaction components and secondary conditions such as temperature or pressure, can be fully described by abstract condition vectors.

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

[0061] Semantic data models can extend n-dimensional conditional vectors by implementing link conditions, such as through (internal or external) vector products or cross products. In one example, processing raw hot steel into refined hot steel, not only the material composition is important, but also the heat transfer that occurs because the steel needs to remain hot. Here, both the material and the heat transfer can be represented by conditional vectors, and since they influence each other, they can also be represented by vector products.

[0062] Based on the definition order of components in the condition vector, the resource management system can prioritize one component over others, for example in the pipeline generation algorithm, as further described below.

[0063] Furthermore, the semantic data model can define semantic device patterns, where at least one attribute, represented by components of an n-dimensional vector, defines a constraint or range, such as a [minimum / maximum] value or an [operating point + / - minimum] value. This constraint can be represented as a function of other parameters, for example, the minimum / maximum pressure p depends on the temperature: p_min / max = f(temp). This constraint can be automatically obtained from device specification documents such as MTP files, or it can be provided by the device operator or device engineer. Pattern definition can facilitate advanced pattern verification and module control.

[0064] In addition, semantic data models can provide semantic descriptions of modules that specify multiple services provided by a module, and / or nesting of modules (modules within modules, such as 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 preconditions and postconditions with one or more attributes, each attribute having optional additional annotations, optionally recursively; matching preconditions and postconditions, optionally with multi-indexed components and annotations; feedforward / feedback of preconditions / postconditions (e.g., if the stirring module requires a dispensing component at a temperature of 45 degrees Celsius as a precondition, then feed it back to the previous heating module to set the target temperature).

[0066] In this way, the semantic module is able to consume and generate 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 that context (possibly in a different state (raw material for refined oil) or with different annotations (hot or cooled)).

[0067] Semantic descriptions of equipment rigs (such as modules) can be built upon information available in documentation related to that rig. For example, for modules, standard description files, such as the MTP defining the associated module, can be used. A module's semantic description can include information taken from documentation and transformed to conform to a semantic data model. However, it should be understood that the semantic descriptions disclosed herein can be based on standards other than MTPs. An MTP can be viewed as a type description that specifies the module's construction plan. For example, an MTP specifies module I / O (information technology aspects, materials technology aspects; each has a name and ID), module topology, HMI, state machine (this can be the same for all MTPs, but has services indicating which states are actually used), services (name only), and recipes. However, module providers may not necessarily know the applications or equipment processes that can use the module. Therefore, an MTP does not provide descriptive fields for all attributes of interest to equipment operators. Therefore, to cover process knowledge and provide a standardized vocabulary to describe that process knowledge, the module library uses wrappers that include extended semantic descriptions of the modules to wrap or extend the MTP.

[0068] Figure 1 Multiple semantic modules 102, assembled to form a semantic pipeline 104, are shown. Here, a "semantic pipeline" can be understood as instance data of a pipeline that describes 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, an MTP) for module 102. The module library 100 includes a semantic control layer that extends the MTP using a wrapper that includes an extended semantic description of the module, based on the semantic data model. The underlying MTP is implicit and not directly accessible. The semantic description is machine-readable and machine-processable. Figure 1The semantic description shown extends the MTP by including attributes such as input / output properties, functions, parameters, and collected usage data. However, it should be understood that this arrangement is not intended to be restrictive. The semantic description can be further extended by including mappings to, for example, Asset Management Casings (AAS) IEC-63278-1ACD, ISO-15926, IEC-62424, Blanco-XML, PA-DIM. The semantic description can be further extended by including, for example, a set of basic operations defined in SkaMPi (VDI Richtlinie 2776). SkaMPi comes with 15 basic operations (Grundoperationsen) 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 achieve comparison and consistency between process requirements and FEA / PEA capabilities. Furthermore, the parameters and setpoints of these basic operations can be correlated to link and check basic operations in one module with respect to those in another module, such as parameters, values, minimum and maximum values, etc. These can be used to describe more complex module services / functions, for example, as a chain of subsequent basic operations. For instance, a high-temperature mixing module can be represented as a series of heating and mixing basic operations.

[0069] In an exemplary semantic description of a module that includes a tank, the MTP includes the input / output characteristics of the tank and describes the functionality of the tank based on its liquid storage capacity, while the 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, that will react in the reactor (e.g., 2 / 3 H2 and 1 / 3 O2), and optionally defines the desired / optimal reaction temperature and pressure (as well as potential critical values / thresholds). Furthermore, the semantic description can specify that the pipeline connecting the reactor to any other possible preceding or subsequent unit in the pipeline has a diameter of 0.5 meters, necessitating a sliding flange in cases where the connecting unit has input / output pipes with a diameter of only 0.25 meters.

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

[0072] As will be described in more detail below, 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 the final output of the simulation to determine if the device is operating as expected), device and module-based optimization, and calibration and automation (e.g., finding bottlenecks, such as what would happen if module 1 connected to module 2 were configured to produce higher outputs so that module 2 reaches or exceeds its tolerance boundaries and enters a critical state).

[0073] A module library assists equipment operators in monitoring and managing the inventory of existing modules (e.g., 12 metering units and 10 reaction units). Some modules may currently be in use on the equipment, while others may not. For modules in use, data on their usage (e.g., what materials they process) or the performance of their components (e.g., uptime, valve material wear), maintenance key performance indicators (KPIs, such as module lifecycle), etc., can be collected and continuously added to the database. When building new equipment or reconfiguring existing equipment, equipment operators can consult the module library and refer to semantic descriptions that include the collected usage data to select the best module for a given function. For example, an equipment operator can simply select an available module that processes the same material as the sought module is expected to process and has the longest uptime before the next scheduled maintenance.

[0074] Using a module library, equipment operators can select from a pool and directly reuse predefined (pre-configured) existing modules, reducing the required design work. This approach facilitates not only the reuse of individual modules but also the reuse of larger functional blocks, thus simplifying the tasks of module design and modular equipment assembly.

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

[0076] Therefore, a module-based virtual design for the equipment process is provided here. The module library thus offers equipment operators an intelligent, information-enhanced pool of cells. This improves the usability and comfort of using software tools, reduces the error rate of cell setup within the equipment, and optimizes equipment performance. All information in the equipment environment can be collected / aggregated in the module library to provide an access point and a unified interface for overall information within the equipment context, making information searchable and revealing optimization potential, while providing a foundation for other AI-based applications and algorithms, such as pipeline generation or optimization, to operate.

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

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

[0079] However, as described above, semantic descriptions and collected usage data provide a mechanism for automatically finding and recommending (e.g., consistent and optimal) combinations of modules and process pipelines for modular devices. 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 for the required pipelines of the modular device, and generate one or more suggested 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 attributes contained in the semantic descriptions in the module library. Specifically, the pipeline generation engine may be configured to access a module library where each semantic module has semantically annotated preconditions and postconditions (e.g., multiple isolates and multiple products), and determine whether a connection (i.e., a path) can be found / built from multiple preconditions to multiple postconditions through a progressive or incremental process using a set / chain of modules. For example, each module takes one (or more) inputs as preconditions and transforms them into one (or more) outputs as postconditions. These postconditions are then inputs (or inputs) for the next module, which in turn are processed into the next outputs (or 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 semantically compatible to be grouped into a single line. The generated suggested pipelines can include parallel and / or sequentially connected sub-pipelines.

[0080] This disclosure envisions various module attributes that can be used to select modules.

[0081] Specifically, 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 attributes of the semantic modules, wherein the input attribute of the first module in the sequence matches at least one precondition and the output attribute of the last module in the sequence matches at least one postcondition. The module pipeline generation engine can be configured to generate a module pipeline using multiple semantic modules selected from a module library to provide inter-module compatibility for the respective modules. The module pipeline generation engine can be configured to determine inter-module compatibility based on the attributes of the respective modules. Module attributes indicating inter-module compatibility can include the input and output attributes of the selected semantic modules. The module pipeline generation engine can therefore be configured to select semantic modules to be included in the proposed pipeline based on the input and output compatibility of the respective modules. In the thus determined sequence of modules, modules are therefore selected such that the output attribute of the module matches the input attribute of any subsequent module and the input attribute of the module matches the output attribute of any previous module. Matching preconditions and postconditions and determining inter-module compatibility are preferably, but not essentially, performed using an n-dimensional condition vector, as described above with reference to the semantic data model, and optionally using any patterns or priorities 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 the functional attributes of modules in the pool. This module pipeline combines functions to transform at least one precondition into at least one postcondition. In this case, attributes indicating inter-module compatibility may include attributes defining module functions, and the module pipeline generation engine is configured to generate suggested pipelines based on the functional compatibility between the selected modules. For example, if a module requires a minimum temperature at an input, the pipeline generation engine could select a heater module as the preceding module in the suggested pipeline.

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

[0084] Pipeline generation engines may include one or more of the following: (1) graph generation and pathfinding algorithms; (2) rule-based algorithms.

[0085] Graph generation and pathfinding algorithms (or graph construction algorithms) are configured to connect starting nodes (e.g., the fragments of a device process) to ending nodes (e.g., the products of a device 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 accelerate precondition / postcondition matching by restricting the set of modules to be matched. Typically, the algorithm can be configured to perform forward 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 memory functions for remembering processed edges, for example, to facilitate selection among alternative combinations. Non-directional graphs can be supported.

[0086] Rule-based algorithms can form 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 defined by the semantic data model. Exemplary rules include those requiring the aforementioned input-output compatibility and functional compatibility. Other rules may describe process knowledge or design know-how (e.g., chemical process knowledge, or pipe-to-module flanging design know-how). Other rules may specify, for example, that certain equipment processes always require refinement modules that do not necessarily change I / O materials but are necessary for higher quality product results, and that certain equipment processes always require specific process technology rules (e.g., a separator module should separate liquids by distillation and solids by sieving). Other rules may describe best practices (e.g., sub-pipelines that function well in upstream equipment, modules that are calibrated well in upstream equipment, etc.). Other rules may indicate contextual relevance, such as a separator module in a batch process using sieves to convert solids, while a separator module in a continuous process uses a distiller to convert liquids. Other rules can indicate permitted and prohibited sub-pipeline combinations; for example, a rule could specify that the baking module should not be used before the mixing module in a cake baking pipeline. Other rules can indicate requirements for sequential or parallel processing. For instance, for a cake baking pipeline that uses black and white dough to produce a marble cake, a rule could indicate that the black and white dough need to be prepared separately (i.e., a parallel sub-pipeline) up to the baking step. The pipeline generation engine can therefore include a rule-based, data-driven execution engine.

[0087] The pipeline generation engine can be configured to execute additional data and knowledge-driven algorithms that support the module pipeline connection process, as well as optimization and ranking algorithms that integrate and process KPIs, module features, 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 a given input (here, "isolated product A" and "isolated product B") to the desired output "product Z". A pool of intelligent units 200, provided by a module library from which semantic modules 102 can be selected, is also shown. As described above, each semantic module 102 is based on the MTP of the corresponding module, which is wrapped by an extended semantic description along with optional collected usage data.

[0089] In this example, given input materials A and B, the equipment operator wants to obtain output material product Z. Therefore, the operator inputs the input and output materials as preconditions and postconditions, respectively, to the pipeline generation engine. The proposed pipeline 204 for converting A and B into product Z is generated by the pipeline generation engine through the selection of semantic module 102, which converts precipitate A into intermediate material C, then into intermediate material D, which is combined with intermediate material E obtained from precipitate B to obtain intermediate material F, and so on, until product Z is obtained. The proposed pipeline 204 is based on knowledge of the semantic representation of what the underlying modules do—that is, 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 module compatibility (e.g., I / O compatibility) and runs through pipeline 204 as it determines the input of 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 pipeline 204 is further demonstrated by using hash indicators to indicate different I / O attributes. In this way, the pipeline generation engine simplifies the design of the device and reduces the design workload.

[0090] Although the modules in the examples above are linked in the pipeline according to I / O compatibility, it is understood 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 the pipeline, and to use or replace compatible I / O processing chains. By leveraging semantic descriptions, the pipeline generation engine can be configured to build pipelines based on any type of module attributes and corresponding preconditions and postconditions.

[0091] As described above, one such exemplary attribute is functionality. Therefore, the pipeline generation engine can generate pipelines 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 its initial raw state to its final refined state within the newly generated process pipeline (while the material's identity as material X remains substantially unchanged). The pipeline generation engine is configured to generate pipelines with semantic modules whose functions are interconnected: for example, first a grinding module, then a heating module, then a stirring module, and finally a cooling module. The first module's precondition is "raw material is in its raw state," and its postcondition is "material is grounded." The second module's precondition is "material is grounded," and its postcondition is "material is heated and stirred." Along with this, parameters can be manipulated to specify the temperature. The third module is used for stirring, with the precondition "material is hot enough for stirring," the same threshold as in the second module, and the postcondition "material is stirred and ready to cool." The final module has the precondition "material is ready to cool" and the postcondition "material is in a transportable state," possibly along with a temperature parameter. In this context, the “functionality” attribute in the semantic description can be used by the pipeline generation engine to perform matching and pathfinding based on the preconditions and postconditions of the module functionality.

[0092] The semantic modules selected by the pipeline generation engine for inclusion in the proposed pipeline can correspond to real and / or virtual modules. If the proposed pipeline includes at least one real module, the pipeline generation engine can prevent the reuse (at least temporarily) of that real module in another manually or automatically generated pipeline. Therefore, the pipeline generation engine automatically considers shared operator activities while ensuring that a globally optimal solution for the generated pipeline can be found (explained in more detail below).

[0093] In any of these methods, the system provides the equipment operator with the automatic generation of suitable / feasible pipeline recommendations on how to construct new pipelines for a given purpose.

[0094] Although pipeline generation has been described with reference to the module library and its semantic data model, it should be understood that other data sources and formats can be used to define modules and their inputs / outputs and functions.

[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 of the desired module type from a module library for inclusion in the module pipeline based on one or more predetermined optimization criteria. A module pipeline generation engine may be configured to generate multiple suggested pipelines for comparison based on one or more predetermined criteria. The optimization component may be configured to compare or rank (using, for example, a ranking component) multiple pipelines (e.g., pipelines suggested by the pipeline generation engine) based on 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 multiple modules of the desired type to be assembled into the corresponding module pipeline in the modular device. 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, these can be used to determine the best or preferred selection and sequence of modules for converting (multiple) preconditions into (multiple) postconditions when predetermined criteria are met.

[0096] Whether the pipeline is generated manually or automatically, the module library can include several semantic modules of a specific type, from which choices can be made regarding which one or which is best suited for a given purpose. For example, these replaceable modules can have different characteristics; a module can be larger, i.e., have a larger capacity, involving how much liquid it can distill, or a module can have less remaining runtime before being put into use. Therefore, the question of which module to use arises when planning a production process. To address this, the design tool also includes an optimization component, which is configured to optimize the pipeline (where multiple 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 describing or representing the underlying module, thereby enriching the underlying module with real data that is semantically mapped in a structured manner. The optimization component is configured to perform optimization using the module attributes contained in the semantic description.

[0097] This disclosure envisions various optimization criteria that can be used by optimization algorithms. Optimization criteria may correspond to, relate to, or be based on the content of the semantic description above, and optionally include collected usage data. Exemplary optimization criteria include: uptime, capacity, energy efficiency, energy consumption, maintenance intervals / cycles, service time, materials or media or their types recently used in the unit, equipment availability, unit availability, unit schedule (when becoming 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 may also store (e.g., in the same database) data related to previously used module combinations, indicating the results of modular equipment in terms of quality, throughput, efficiency, or other KPIs, to assist in assessing whether modules in a particular combination operate successfully together. Optimization components use these criteria to intelligently and automatically select 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 extensive cleaning is required before the module can be used in another device. The collected usage data can be used to find the best possible modules for the current plan based on the corresponding selected optimization criteria.

[0098] The optimization component is configured to receive a pipeline, which, as described above, is manually or automatically generated and includes one or more representations of real or virtual modules or their types. An optimization algorithm, associated with selected criteria, is executed to optimize the pipeline by utilizing semantic data describing the different characteristics and constraints of the modules. This minimizes / maximizes one or more selected optimization criteria across a group of modules in the pipeline. The optimization algorithm is thus configured to find the optimal combination of modules for the pipeline. This may involve completely excluding one or more modules from the received (input) 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 combination of modules that results in, for example, the highest product quality, highest throughput, highest energy efficiency, etc.

[0099] The optimization algorithm can be implemented using a machine learning model trained to select modules based on semantic descriptions of the modules and optionally also based on data indicating how well the combination of modules has performed in the past, such as which modules were frequently chosen to coexist in the past and which modules coexist well.

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

[0101] If more than one criterion is optimized, the result can be two or more locally optimal pipelines, which are suggested to the equipment operator to determine which criterion is considered more important for the global optimum. The optimization component can then use the ranking function (i.e., the ranking component) to rank the two or more pipelines based on the selected or predetermined criteria.

[0102] Optimization can be local, targeting only a given pipeline, or it can be global, indicating how to allocate available module resources across multiple pipelines. For example, if a module has limited runtime remaining before service, but this runtime proves sufficient for planned batch production, then from a global optimization perspective, it's best to use that module, allowing other similar modules with more runtime to remain available for other possible batch production processes. Alternatively, a scenario might involve a flexible module that can theoretically be used in many production processes, while a more specialized, interchangeable module will perform the same function; therefore, global optimization might recommend using the more specialized module to reserve the more flexible module for other possible processes that might require it.

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

[0104] Figure 3 An example is shown of a semantic pipeline 304 that optimizes a semantic module using optimization components. For example... 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 3The diagram shows the module types defined by MTP1-MTPn. The real cells in the real cell pool 302 correspond to the types found in the virtual cell pool 300 and can be associated with the collected usage data. In this example, the equipment operator has multiple different types of real cells, here 3 real metering cells and 2 real reaction cells. In the first step, implicit pipelines 304 are generated manually or automatically (as described above) using certain types of virtual cells, and in the second step, the optimization component executes an optimization algorithm to replace these virtual cells with representations of real cells of a given type selected from the real cell pool 302, so that one real cell is preferred over another 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. Figure 3 In the example shown, the optimization component identifies two candidate reaction units (reaction units of module type MTP1 selected as the first module of the pipeline) and three candidate metering units (metering units of module type MTP4 selected as the second unit of the pipeline) from the real module pool 302, which 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 collected usage data stored in the semantic descriptions of the respective semantic units, along with predetermined optimization criteria. 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 until the next predetermined maintenance than other candidate units.

[0105] The optimization component can be used additionally or alternatively to optimize pipelines that include semantic modules corresponding to the actual modules, such as pipelines input by engineers. In other examples of local optimization schemes, where the pipeline in the initial production plan formulated by the engineer includes a selected distillation module that is too large and therefore consumes too much energy, the optimization component selects an alternative, smaller distillation module that is sufficient to meet the planned batch.

[0106] Although the above references include a semantic description of the collected usage data used to describe the optimization component, which is described above as conforming to the semantic data model, it should be understood that data from any other appropriate source and in any appropriate format can be used for optimization.

[0107] To assist equipment operators in validating module / pipeline selections, resource management systems can include simulation components or tools configured to provide simulation capabilities that allow for the simulation of the operation of a modular pipeline comprising one or more modules from a modular equipment (regardless of whether the pipeline is manually or automatically generated, and whether it is automatically optimized). This includes, for example, identifying potential bottlenecks and inefficiencies, trying alternative modules to determine if this optimizes the simulation, or generally simulating "hypothetical" scenarios. For instance, planning can begin with an initial flow chart in the form of a user-generated pipeline, representing the modules and their connections to define the type of process the user envisions. This pipeline is likely not optimal. Users can leverage the simulation capabilities of design tools to simulate different hypothetical scenarios to discover suboptimal configurations. For example, a user could simulate what would happen if an alternative distillation module were used instead of the currently selected larger distillation module or one with a longer service time. Simulation components can be automatically configured to simulate different hypothetical scenarios (i.e., alternative configurations / arrangements) and compare the results. The number of scenarios in practice can depend, for example, on the time the planner wants to invest in the simulation.

[0108] A resource management system as described in this article can be provided: -

[0109] The central pool serves as a central unit pool for multiple equipment operators. This pool comprises a set of semantic modules corresponding to those previously used by the equipment operators, along with semantic descriptions and usage data collected from the entrusted equipment. This facilitates not only cell-centric local optimization but also global intra-cell pipeline context optimization. The solution is cloud-based, scalable, and easily accessible.

[0110] This serves as a private unit pool managed by the equipment operator. The private unit pool allows the equipment operator to manage and oversee a set of semantic modules corresponding to the real modules owned by the operator. Parameters, KPIs, and other collected usage data (best practices, calibration parameter combinations, maintenance intervals, MTBF, last maintenance completed, last material used, cleaning status, activity / availability / unused, etc.) are collected from the real modules and uploaded to a database to allow the application system's pipeline generation engine and component optimization. Both on-premises implementations and cloud-based solutions are possible, depending on the equipment operator's wishes / requirements.

[0111] o as an internal product to reduce costs for equipment operators, or as a quote offered to clients to reduce their own costs.

[0112] The topics described in this article have specific applications in module-based production and resource planning. This is particularly relevant in small-batch pharmaceutical production, where module resources are frequently exchanged between different batches. When planning new batches or redesigning the module setup for existing batch production (e.g., when existing module selection appears to pose a bottleneck due to changes in production load), the topics described in this article will allow planners to identify and select the correct, i.e., the most suitable modules.

[0113] The topics described in this article have other applications in module maintenance planning. Modules require periodic maintenance and have characteristics such as "service time," which indicate how much runtime remains before the next scheduled service check. Here, optimization and hypothetical simulations can assist in determining the optimal maintenance plan for a module. For example, with the help of a known production plan, specifying how different modules will be used in the near future, one example optimization scenario is to perform module maintenance earlier than planned because it will not be used at that time, which ultimately proves to result in better utilization and process output.

[0114] Therefore, the benefits provided by the resource management system described herein include, among other things, (1) the reuse of modules and thus a reduction in design effort through a searchable pool of modules; (2) the simplification or automatic generation of viable pipelines that (i) are directly compatible through semantic checks and controls, and (ii) can be optimized for various criteria such as uptime, maintenance intervals, availability, etc.

[0115] Now for reference Figure 4 A high-level illustration of an exemplary computing device 800, usable according to the systems and methods disclosed herein, is shown. Specifically, the computing device 800 can be used to implement the aforementioned resource management system or design tool along with its pipeline generation engine and optimization components. 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 functions described as being performed by one or more of the aforementioned components, or instructions for implementing one or more of the aforementioned methods. The processor 802 can access memory 804 via system bus 806. In addition to storing executable instructions, memory 804 may also store session inputs, scores assigned to session inputs, etc.

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

[0117] The computing device 800 also includes an input interface 810 that allows external devices to communicate with it. 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 conceivable that in an environment providing virtually any type of user interface that a user can interact with, external devices communicating with the computing device 800 via the input interface 810 and the output interface 812 may be included. Examples of user interface types include graphical user interfaces (GUIs), natural user interfaces (NUAs), etc. 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 natural user interface allows a user to interact with the computing device 800 in a manner unconstrained by input devices such as a keyboard, mouse, remote control, etc. Conversely, natural user interfaces can rely on speech recognition, touch and stylus recognition, on-screen and near-screen gesture recognition, air gestures, head and eye tracking, voice and sound, vision, touch, gestures, machine intelligence, and so on.

[0118] Furthermore, although shown as a single system, it should be understood that computing device 800 can be a distributed system. Therefore, for example, several devices can communicate via a network connection and collaboratively perform tasks described as being performed by 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 code. Computer-readable media include computer-readable storage media. A computer-readable storage medium can be any available storage medium accessible to 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, disk storage 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 that can be accessed by a computer. Disks and optical discs as used herein include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs (BDs), wherein disks typically reproduce data magnetically, while optical discs typically reproduce data optically using lasers. Furthermore, the propagation of signals is not included within the scope of computer-readable storage media. Computer-readable media also include communication media, including 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 all included in the definition of communication 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 limitingly, 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), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), etc.

[0121] Although the above description is provided in the context of the MTP standard, it should be understood that this disclosure is not limited to the use of MTP in defining units and may be described using other standardized modules.

[0122] The applicant hereby separately discloses each individual feature described herein, as well as any combination of two or more such features, so that such features or combinations can be implemented based on this specification as a whole according to the common general knowledge of those skilled in the art, regardless of whether such features or combinations of features solve any problem disclosed herein, and without limiting the scope of the claims. The applicant notes that aspects of the invention can consist of any such single feature or combination of features.

[0123] While the invention has been described and illustrated in detail with reference to the accompanying drawings and the foregoing description, such description and illustration are to be considered exemplary rather than limiting. The invention is not limited to the disclosed embodiments. Other variations to the disclosed embodiments will be understood and implemented by those skilled in the art through study of 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 articles "a" or "an" do not exclude a plural. A single processor or other unit can perform the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not imply that combinations of these measures cannot be advantageously used. Computer programs may be stored / distributed on suitable media, such as optical storage media or solid-state media 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 numerals in the claims should not be construed as limiting the scope.

Claims

1. A resource management system for a modularized plant, the system comprising a database providing a library of semantic modules representing respective modules in a pool of modules, at least one of the semantic modules comprising a semantic description of the respective module, wherein the semantic description comprises abstract data compliant with a semantic data model, and wherein the abstract data describes properties of the respective module not found in a standard description file for the module; wherein the resource management system further comprises a module pipeline generation engine configured to receive input data indicative of at least one pre-condition and at least one post-condition of a required pipeline of the modularized plant, and to generate a suggested semantic module pipeline representing one or more modules capable of transforming the at least one pre-condition into the at least one post-condition, wherein the module pipeline generation engine is configured to select one or more semantic modules to be included in the semantic module pipeline from the library of modules, and the selection of one or more semantic modules is based on module properties contained in the semantic description of the selected semantic module.

2. The resource management system according to claim 1, wherein the properties of the module comprise one or more of: input / output properties; module functionality; module parameters; process parameters; calibration parameters.

3. The resource management system according to claim 1 or 2, wherein the semantic description further comprises collected usage data related to previous usage of the respective module in a modularized plant.

4. The resource management system according to claim 3, wherein the collected usage data relates to previously measured key performance indicators comprising one or more of: mean time between failures; module uptime; service and equipment utilization; previous calibration parameters; frequent plant context; maintenance execution; material / medium handling; application purpose and limitations of chemical reactions; module availability schedule; maintenance period / interval.

5. The resource management system according to any one of claims 1-2, 4, wherein the semantic description further comprises previous configuration data related to configuration of the respective module in at least one previous modularized plant, the previous configuration data being usable for configuring the module for another modularized plant.

6. The resource management system according to any one of claims 1-2 and 4, wherein the module pipeline generation engine is configured to determine a sequence of one or more semantic modules to form the semantic module pipeline based on input / output properties of the semantic modules in the library of modules, in which the sequence of semantic modules the input properties of a first semantic module in the sequence match the at least one pre-condition and the output properties of a last semantic module in the sequence match the at least one post-condition.

7. The resource management system of any one of claims 1-2 and 4, wherein the module pipeline generation engine is configured to determine a sequence of one or more modules to form the module pipeline based on functional attributes of the semantic modules in the module library, the functional combination of the module pipeline to transform the at least one pre-condition to the at least one post-condition.

8. The resource management system of any one of claims 1-2 and 4, comprising an optimization component configured to: receive data identifying a required module type to be assembled into the 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 semantic modules in the module library having the required module type based on one or more predetermined optimization criteria.

9. The resource management system of claim 8, wherein the optimization algorithm is configured to perform a local optimization to optimize only the module pipeline.

10. The resource management system of claim 8, wherein the optimization algorithm is configured to perform a global optimization to select a plurality of semantic modules representing required types of modules to be assembled into respective module pipelines in the modular device.

11. The resource management system of claim 8, wherein the predetermined optimization criteria comprises one or more of: 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.

12. The resource management system of any one of claims 1-2 and 4, wherein the database is configured to provide a search function to allow searching of the module library.

13. The resource management system of any one of claims 1-2 and 4, comprising a simulation component configured to provide a simulation function to allow simulation of operation of a module pipeline comprising one or more modules in a modular device. ​ ​

Images