Modular Automation Support System

Abstract

This invention provides a modular automation support system for modular factories. The system includes an automation engineering support system comprising a feedback processing component configured to modify the operation of one or more other components of the automation engineering support system based on user feedback.

Description

TECHNICAL FIELD

[0001] The present invention relates to a modular automation support system for a modular plant. BACKGROUND

[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 to build and design industrial process plants in a modular way during the automation engineering phase, with the goal to simplify automation engineering. These advantages are achieved by pre-fabricated and well-tested modules, called PEA (Process Equipment Assembly), which can be easily put together in different combinations, allowing different recipes.

[0003] Existing systems can provide support to the plant owner during the automation engineering phase. However, these can not always fully account for all the situations that occur in a real plant environment. Moreover, solutions providing support during the control engineering phase, i.e. during plant operation and production planning, are rare. SUMMARY

[0004] There is therefore a need for a more effective modular automation support system for a modular plant. This need is met by the modular automation support system as described and claimed herein. Dependent claims set out optional features. Corresponding methods, including computer implemented methods, are also provided.

[0005] According to another aspect, there is provided a computing device comprising a processor, the computing device being configured to perform a computer implemented method as described herein.

[0006] According to another aspect, there is provided a computer program product comprising instructions which, when executed by a computing device, cause the computing device to perform a computer implemented method as described herein.

[0007] According to yet another aspect, there is provided a computer readable medium comprising instructions which, when executed by a computing device, cause the computing device to perform a computer implemented method as described herein.

[0008] There is also provided a modular plant comprising any of the systems described herein, and a method of operating a modular plant comprising performing any of the methods described herein.

[0009] The invention can include one or more aspects, examples, or features alone or in combination, whether or not specifically disclosed.

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

[0011] A detailed description will now be given with reference only to the accompanying drawings, in which:

[0012] Figure 1 The illustration shows a modular automation support system according to this disclosure;

[0013] Figure 2 The diagram illustrates a semantic pipeline that represents the physical pipeline of an industrial modular factory through a series of interconnected semantic modules.

[0014] Figure 3 The diagram illustrates a semantic pipeline automatically generated by a pipeline generation engine for transforming a specific product into a given product.

[0015] Figure 4 The diagram illustrates the optimization of the pipeline generation engine for automatically generated semantic pipelines;

[0016] Figure 5 The diagram illustrates factory operation optimization;

[0017] Figure 6 The diagram illustrates the learning process of pipeline sequencing;

[0018] Figure 7 The diagram illustrates the updates to the rules repository; and

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

[0020] Modular Automation Support System

[0021] Figure 1 This describes a modular automation support system 10 for a modular factory. The modular automation support system 10 includes one or more of an automation engineering support system 100 (for providing support to automation engineers) and a control engineering support system 150 (for providing support to control engineers). The modular automation support system 10 can be implemented in software, firmware, hardware, or any combination thereof, for example, using references herein. Figure 8 The described computing device. The modular automation support system 10 may be part of or include engineering tools or dashboards for planning, configuring, managing and / or operating a modular plant.

[0022] Automated Engineering Support System

[0023] The automated engineering support system 100 includes one or more of the following components: (i) a module library 102, including a semantic annotation module; (ii) a pipeline generation engine 104; (iii) a pipeline optimization component 106; and (iv) a simulation component 108.

[0024] Semantic data model

[0025] As further described below, the modular automation support system 10 implements a semantic data model to provide an abstract representation of modules, modular pipelines, or modular factories.

[0026] Module library 102 contains one or more semantic modules stored in a repository such as a database. Semantic modules include instance data that represents, describes, or defines modules that are modular factories 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 "in the context" and "in the context" are used interchangeably. Module library 102 can further store heterogeneous data items (such as specifiers, comments, values, and history) related to semantic modules. Module library 102 thus acts as a place (or knowledge representation system) for collecting global and local domain knowledge about modules. Module library 102 can be implemented using a database involving any centralized or distributed data storage. For example, one or more data storage units provided by automation engineering support system 100, the modules themselves, or other components of the modular plant can be used to implement a database. In particular, data storage device 808 described below can be used to implement a database. Semantic modules stored in module library 102 can represent real or virtual, owned (owned by the plant operator) or not yet owned (e.g., available for purchase), available (currently used in the plant), or potentially available modules. Thus, 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 module library 102, it is possible to later search and discover semantic modules and select modules to be combined into the process flow. In particular, module library 102 can provide search functionality to help plant operators locate suitable modules.

[0027] 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. Real modules can be implemented in 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 the real module, 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 engineering knowledge through fields within the template.

[0028] Therefore, semantic descriptions conforming to a semantic data model are used to describe modules. A semantic description can specify any one or more module attributes of a module. 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 including one or more of the following: input / output attributes, module functionality; module components; module parameters; module usage; process parameters; calibration parameters; and data from module inputs, processing, and outputs. Semantic descriptions provide a common interface for the semantic web stack (i.e., a RESTful API, accessible via HTTP, etc.). Process pipelines can be generated manually or automatically through semantic description matching between modules, as described in more detail below. Semantic descriptions can also include previously configured data associated with the configuration of a corresponding module in at least one previous modular factory, which can be used to configure the module for use in another modular factory. Previously configured data can be associated with previously engineered data that accelerates the reuse of modules.

[0029] Semantic descriptions can specify the relationship between a module's inputs and outputs. Specifically, a semantic description can specify one or more preconditions and one or more postconditions for the module. Preconditions and postconditions specify conditions that can, 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 transform at least one precondition into at least one postcondition. For example, in materials processing, a precondition can be a product, and a postcondition can be a finished product. "Description" can refer to any substance, composition, or material that will react with at least one other product to form a product. Therefore, the module transforms a product into a finished product, i.e., it transforms the material properties. A module can, for example, transform one material state into another by heating, stirring, refining, etc. "Will" refers to any property, characteristic, or condition that refers to a single material, not just an aggregated state. A semantic description can further specify one or more conditions or constraints by which the module transforms preconditions into postconditions. Alternatively, preconditions and postconditions can specify one or more of the form, structure, or connection method of the module's inputs and outputs.

[0030] For real modules, the semantic description may also include collected usage data related to previous use of the real module in the modular factory. The collected usage data may include any suitable data characterizing the performance, use, or configuration of the previous module. The collected usage data may include, for example, any one or more of the following: previous engineering data; previous calibration parameters; frequent factory environments; maintenance performed; materials / media processed; application purpose and limitations of chemical reactions. The collected usage data can be used to expedite the configuration of the module for use in another modular factory. For example, one value in the real module template may identify the last processed material (e.g., nuts, which may be important for a factory 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, a value indicating "Service FanOven is broken, but Top & Bottom Plate Heat Baking is still possible").

[0031] 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 usage; availability schedule; maintenance cycle / interval. Many other examples will be familiar to those skilled in the art. As further described below, such performance data can be used to optimize pipeline module selection.

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

[0033] As used herein, "semantic data refers to abstract data that can represent any property of a module, production line, plant, or material, particularly the input / output properties of a module represented by material properties (e.g., input / output materials) or material states (e.g., raw or refined materials, cooled or heated liquids or solids). 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: functionality; 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."

[0034] 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:

[0035] - Zero Dimension: Attribute Type: "Material Class = 0"

[0036] -One-dimensional: Material: "Steel = 76,

[0037] - Two-dimensional: Aggregation state: "Solid state = 3,

[0038] - 3D: Durability: "Superior Performance = 10,

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

[0040] The purification process module may require steel as input. Specifically, it may require liquid steel as a precondition: [0,76,2,-], where "2" indicates the polymer state: "liquid" in the three dimensions and "-" indicates no requirement for durability properties. Therefore, it can be easily determined that a given steel [0,76,3,10] does not match the module's precondition [0,76,2,-]. Therefore, the process pipeline will require a previous melting module that melts the solid material to convert the solid steel [0,76,3,10] into liquid steel [0,76,2,10] to match 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 input pipe diameter, inflow liquid pressure, etc.

[0041] In another example, including a cake baking plant, white and black dough (products) can be processed to produce a marble cake (product). Here, the white dough 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 in a rationed state can be represented by [0,1,2,1], where 0 represents material, 1 represents dough, 2 represents black (dough), and 1 represents rationed state. Both are processed separately to obtain a mixed white dough [0,1,1,2] and a mixed black dough [0,1,2,2] (where the last component with a value of 2 represents the "final state" of the dough). Then, these two are combined and baked to produce an ready-to-eat cake [0,63,-,-,1,10], where 0 represents material, 63 encodes "cake material", the two blank dashes indicate that the state and color are not defined, 1 indicates the cake type: "marble cake type", and 10 indicates "marble cake".

[0042] Similarly, chemical or physical processes (including additional conditions such as reaction components, temperature, or pressure) can be fully described by abstract condition vectors.

[0043] The semantic data model implemented by the modular automation support system 10 defines the meaning of each component 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, one dimension can describe the overall context, such as: material / function / information flow / energy flow. Two dimensions and the following dimensions can include additional 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.

[0044] Semantic data models can extend n-dimensional conditional vectors by implementing link conditions, such as through (inner or outer) vector products or cross products. In an example of processing raw hot steel into refined hot steel, since the steel needs to be kept at a high temperature, not only the material composition but also the heat transfer that occurs is important. Here, both material and heat transfer can be represented by conditional vectors, and since they influence each other, they can also be represented by vector products.

[0045] Based on the component order defined in the condition vector, the automation engineering support system 100 can, for example, prioritize one component over others in a pipeline generation algorithm, as further described below.

[0046] Furthermore, the semantic data model can define a semantic factory schema, where at least one attribute, represented by components of an n-dimensional vector, defines a constraint or range, such as a [min / max] value or an [operatingPoint+ / -epsilon] value. The constraint can be represented as a function of other parameters, such as a temperature-dependent min-max-pressure p: p_min / max = f(temp). This constraint can be automatically obtained from factory specification documents (e.g., MTP files) or provided by the factory operator or factory engineer. Schema definition facilitates advanced schema verification and module control.

[0047] In addition, semantic data models can provide semantic descriptions of modules that specify multiple services provided by modules, and / or nesting of modules (modules within modules, such as a stirring module within a heating module).

[0048] Therefore, the modular automation support system 10 is configured to implement a semantic data model that provides one or more of the following: modeling preconditions and postconditions using one or more attributes, each with optional additional annotations, optionally recursively; matching preconditions and postconditions, optionally with multi-indexed components and annotations; feedforward / feedback of preconditions and postconditions (e.g., if the stirring module needs to dispense components at a temperature of 45 degrees as a precondition, it feeds it back to the previous heating module to set the target temperature).

[0049] 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 in the semantic factory process context and has been processed / manipulated, but is still available in this semantic factory process context (possibly in a different state (unprocessed refined oil) or with different annotations (hot or cooled)).

[0050] Semantic descriptions of plant equipment, such as modules, can be built upon information available in documentation related to that plant equipment. For example, for modules, standard description files, such as MTPs defining associated modules, can be used. A module's semantic description can include information taken from documentation and translated 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 of description specifying a 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 may be the same for all MTPs but has services indicating actual usage status), services (name only), and recipes. However, a module provider may not necessarily know the applications or plant processes that can use the module. Therefore, an MTP does not provide descriptive fields for all attributes of interest to plant operators. Therefore, to cover process knowledge and provide a standardized vocabulary to describe this process knowledge, module library 102 wraps or extends the MTP with a wrapper that includes an extended semantic description of the module.

[0051] Figure 2 This describes multiple semantic modules 202 that have been assembled to form a semantic pipeline 204. Here, "semantic module" can be understood as instance data of a pipeline that uses a semantic data model to describe one or more semantic modules, or it can be referred to as "using a semantic data model to describe one or more semantic modules," or it can be referred to as "using a semantic data model to describe one or more semantic modules." Each semantic module 202 can be based on a standard description file for module 202 (MTP in a non-limiting example). Module library 102 includes a semantic control layer that utilizes a wrapper to extend the MTP, which includes extended semantic descriptions of the modules according to the semantic data model. The underlying MTP is hidden and not necessarily directly accessible. The semantic description is machine-readable and machine-processable. Figure 2The semantic description shown extends the MTP by including, among other things, the following attributes: input / output attributes, functionality, 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 a set of basic operations, as defined in SkaMPi (VDIRichtlinie 2776). SkaMPi comes with 15 basic operations, whose description 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.) are used for comparison and consistency between process requirements and FEA / PEA capabilities. Furthermore, the parameters and setpoints of these basic operations may be correlated to link and check the basic operations in one module relative to those in another module, such as parameters, values, minimum-maximum values, etc. These can be used to describe more complex module services / functionality, 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.

[0052] In an exemplary semantic description of a module that includes a tank, the MTP includes the tank’s input / output characteristics and describes the tank’s functionality 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.

[0053] In another exemplary semantic description of the module including the reactor, the MTP allows for the definition of inputs and outputs, while the extended semantic description defines, for example, the ratio of the two inputs H2 and O2 (e.g., 2 / 3 H2 and 1 / 3 O2) that will react in the reactor, as well as optionally the desired / optimal reaction temperature and pressure (and potential critical values / thresholds). Furthermore, the semantic description can further specify that the pipe connecting this reactor to any other possible preceding or subsequent unit in the production line has a diameter of 0.5 meters, necessitating a translation flange in cases where the connecting unit has input / output pipes with a diameter of only 0.25 meters.

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

[0055] As will be described in more detail below, semantic description enables—among other possibilities—semantic module-to-module matching (pipeline generation), robustness checks useful for pipeline generation, plant process simulation (i.e., providing initial inputs and obtaining the final output of the simulation to determine whether the plant is operating as expected), plant and module-based optimization, and calibration and automation (e.g., identifying bottlenecks, such as if module 1 connected to module 2 is set to produce higher outputs, causing module 2 to reach or exceed its tolerance boundaries and enter a critical state).

[0056] Module Library 102 helps plant operators manage / process their existing module inventory (e.g., 12 metering units and 10 reaction units). Some modules may currently be in use at the plant, while others may not. For modules in use, data related to their usage (e.g., what materials they process), component performance (e.g., uptime, valve material wear), maintenance key performance indicators (KPIs, such as module lifecycle), etc., may be collected and continuously added to the database. When building a new plant or reconfiguring an existing one, plant operators can consult Module Library 102 and refer to semantic descriptions including the collected usage data to select the best module for a given functionality. For example, a plant operator could simply select an available module that processes the same materials as the module being sought is expected to process and has the longest lifespan before the next scheduled maintenance.

[0057] Using module library 102, factory operators can select from the pool and directly reuse predefined (pre-configured) existing modules, thereby reducing the amount of engineering work required. In this way, not only is the reuse of individual modules beneficial, but also the reuse of larger functional blocks, thus simplifying the tasks of module engineering and modular factory assembly.

[0058] Furthermore, when the actual versions of the modules in the pool are not yet available, System 100 can provide functionality that allows plant operators to determine whether a specific production line can be assembled for a given new plant using the 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 production lines for newly planned modular plants. These recommendations can be based not only on the compatibility of the modules determined through semantic descriptions, but also on specific optimization criteria, as explained further below.

[0059] Therefore, a module-based virtual engineering solution for factory processes is provided. Module library 102 thus provides factory operators with an intelligent, information-enhanced pool of cells. This lays the foundation for improving the usability and comfort of factory operators using software tools, reducing error rates in cell setup within the factory, and optimizing factory performance. All information within the factory environment can be collected / aggregated in module library 102, providing an access point and a unified interface for overall information within the factory environment. This makes information searchable and reveals optimization potential, while providing the basis for other AI-based applications and algorithms (e.g., for pipeline generation or optimization) to operate.

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

[0061] As described above, the automation engineering support system 100 allows factory operators to select and combine units from a module library 102 to form an assembly line. Using the semantic descriptions of the modules provided by the module library 102, factory operators can determine module compatibility based on various module attributes. For example, such as... Figure 2 As shown, the factory operator selects semantic module 202 based on its I / O compatibility to form semantic pipeline 204 (i.e., a representation of the physical pipeline).

[0062] Pipeline generation engine

[0063] However, as mentioned above, semantic descriptions and collected usage data provide a mechanism for automatically finding and recommending (e.g., consistent and optimal) modular combinations of modules and process lines in a modular factory. For this purpose, refer again... Figure 1The automated engineering support system 100 may further include a modular pipeline generation engine 104, configured to receive input data indicating at least one precondition and at least one postcondition for a required pipeline in a modular factory, and to generate one or more suggested modular pipelines, including one or more modules capable of translating at least one precondition into at least one postcondition. The pipeline generation engine 104 may also be referred to as a pipeline composition engine. The pipeline generation engine 104 may be configured to select one or more semantic modules from the module library 102 for inclusion in the modular pipeline based on module attributes included in the semantic descriptions in the module library 102. Specifically, the pipeline generation engine 104 may be configured to access the module library 102, where each semantic module has semantically annotated preconditions and postconditions (e.g., deliverables and products), and determine whether a connection (i.e., a path) can be found / built from preconditions to postconditions through a progressive or incremental process of module groups / chains. For example, each module takes one (or more) inputs as preconditions and transforms them into one (or more) outputs as postconditions. These postconditions then become the input (i.e., precondition) of the next module, which in turn becomes the next output (i.e., postcondition), and so on. The pipeline generation engine 104 ensures module-to-module and thus pipeline compatibility by definition, as only modules compatible according to their semantic descriptions are allowed to be grouped into a single line. The generated suggested pipeline can include parallel and / or sequentially connected sub-pipelines.

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

[0065] Specifically, the pipeline generation engine 104 can be configured to determine a sequence of one or more semantic modules based on the input / output attributes of the semantic modules to form a module pipeline, 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 pipeline generation engine 104 can be configured to generate a module pipeline using multiple semantic modules selected from a module library 102 to provide inter-module compatibility for the respective modules. The pipeline generation engine 104 can be configured to determine inter-module compatibility based on the attributes of the respective modules. Module attributes indicating inter-module compatibility may include the input-output attributes of the selected semantic modules. The pipeline generation engine 104 can therefore be configured to select semantic modules to include in the proposed pipeline based on the input-output compatibility of the respective modules. In the thus determined sequence of modules, modules are 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. The determination of matching preconditions and postconditions, as well as inter-module compatibility, is preferably, but not essentially, performed using an n-dimensional condition vector, as described above in the reference semantic data model, and optionally using any pattern or priority implemented by the model.

[0066] Alternatively, the pipeline generation engine 104 can be configured to determine a sequence of one or more modules to form a module pipeline based on the functional attributes of the modules in the pool, whose functional combinations transform at least one precondition into at least one postcondition. In this case, attributes indicating inter-module compatibility may include attributes defining the functionality of the modules, and the module pipeline generation engine is configured to generate the proposed pipeline based on the functional compatibility between the selected modules. For example, if a module requires a minimum temperature at its input, the pipeline generation engine may select a heater module as the preceding module in the proposed pipeline. Similarly, semantic data describing those attributes that conform to a semantic data model can be used to compare and match attributes defining the functionality of the modules.

[0067] Therefore, the pipeline generation engine 104 is configured to automatically use the semantic descriptions of the modules provided by the module library 102 to generate the proposed pipelines for the plant operators (otherwise they would have to manually select, combine and assemble the modules).

[0068] The pipeline generation engine 104 may include one or more of the following: (1) a graph generation and pathfinding algorithm; (2) a rule-based algorithm.

[0069] Graph generation and pathfinding algorithms (or graph construction algorithms) are configured to connect starting nodes (e.g., products of a factory process) to ending nodes (e.g., finished products of a factory process). The graph and its nodes represent modules connected by 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 propagation and / or backward propagation using preconditions and postconditions. Forward propagation can be performed to construct a graph (graph data structure) whose edges and nodes are suitable for direct further processing, possibly a parallel subpipeline merged into one, or a pipeline split into two or more parallel subpipelines, etc. The algorithm may include storage functionality for storing processed edges, for example, to facilitate selection among alternative compositions. Undirected graphs can be supported.

[0070] Rule-based algorithms can form part of an expert system or be configured as part of a domain knowledge representation system that implements expert rules. As described above, rule-based algorithms can use the same vocabulary / ontology as defined by a semantic data model. Rules can be defined or use semantic data based on the semantic data model. Exemplary rules include those requiring the aforementioned input-output compatibility and functional compatibility. Other rules can describe process knowledge or engineering knowledge (e.g., chemical process knowledge, or pipe-to-module flange engineering knowledge). Other rules can specify, for example, that certain plant processes always require a refining module, which may not necessarily change the I / O materials but requires higher quality product results, and specific process technology rules (e.g., a separator module should separate liquids by distillation and solids by sieving). Other rules can describe best practices (e.g., a well-functioning sub-pipeline in a previous plant, a well-calibrated module in a previous plant, etc.). Other rules can indicate contextual relevance, e.g., a separator module in a batch process uses 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 subpipeline 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 example, for a cake baking pipeline that uses black and white dough to make a marble cake, a rule might indicate that the black and white dough need to be prepared separately before the baking step (i.e., in a parallel subpipeline). The pipeline generation engine 104 can therefore include a rule-based, data-driven execution engine.

[0071] The pipeline generation engine 104 can be configured to execute additional data and knowledge-driven algorithms, as well as optimization procedures and sorting algorithms, to support the modular pipeline connection process, and to integrate and process KPIs, module characteristics, and all other kinds of available and useful data.

[0072] Figure 3 The automatically generated suggested semantic pipeline 304 is shown, comprising a series of semantic modules 202 from given inputs, here "Product A" and "Product B", to the desired output "Product Z". A pool of intelligent units 300 provided by a module library 102 is also shown, from which semantic modules 202 can be selected. As described above, each semantic module 202 can be based on the MTP of the corresponding module, which is wrapped by an extended semantic description and optionally collected usage data.

[0073] In this example, given input materials (product A and product B), the plant operator desires to obtain an output material (product Z). Therefore, the plant operator inputs the input and output materials as preconditions and postconditions, respectively, into the pipeline generation engine 104. The proposed pipeline 304 for transforming products A and B into product Z is generated by the pipeline generation engine 104 by recognizing the selection of a semantic module 202, which transforms product A into intermediate material C, then into intermediate material D, combined with intermediate material E obtained from product B, to obtain intermediate F, and so on, until product Z is obtained. The proposed pipeline 304 is based on semantic representations of knowledge about what the underlying modules do—that is, what inputs they accept and what outputs they produce, or what functions they have, as explained elsewhere in this document. In this example, the pipeline generation engine 104 uses a rule-based, data-driven execution engine that checks the compatibility of modules (e.g., I / O compatibility) and runs through pipeline 304 as it determines 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 3 The I / O compatibility of the modules in the proposed pipeline 304 is further illustrated by using hash indicators to indicate different I / O attributes. In this way, the pipeline generation engine 104 simplifies factory engineering and reduces engineering workload.

[0074] While the modules in the above example are linked in the pipeline based on I / O compatibility, it should be understood that the pipeline generation engine 104 can be configured to suggest pipelines based on other attributes (such as functionality, parameters, and other properties), which can be automatically linked together in the pipeline, and or use compatible I / O processing chains. By leveraging semantic descriptions, the pipeline generation engine 104 is configured to construct pipelines based on any type of module attributes and corresponding preconditions and postconditions.

[0075] As described above, one of these exemplary attributes is functionality. Therefore, the pipeline generation engine 104 can generate pipelines based on a functional sequence 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 properties of the material X remain substantially unchanged). The pipeline generation engine 104 is configured to generate pipelines of semantic modules whose functionality is built upon one another: for example, first a grinding module, then a heating module, then a stirring module, and finally a cooling module. The precondition for the first module is that it is configured to generate a pipeline of semantic modules whose functionality is built upon one another: for example, first the grinding module, then the heating module, then the mixing module, and finally the cooling module. The precondition for the first module is that rules can indicate allowed and disallowed combinations of sub-pipelines; 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 example, for a cake baking pipeline that uses black and white dough to make a marble cake, a rule might indicate that the black and white dough need to be prepared separately before the baking step (i.e., in parallel sub-streams). These sub-stream attributes can be used by the pipeline generation engine 104 to perform matching and pathfinding based on the preconditions and postconditions of the module's functionality.

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

[0077] Through any of these methods, system 100 provides factory operators with the automatic generation of suitable / feasible production line suggestions on how to compose a new production line for a given purpose.

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

[0079] Streamline optimization components

[0080] Refer again Figure 1The automated engineering support system 100 may include a pipeline optimization component 106. The pipeline optimization component 106 is configured to: receive data identifying the desired module type to be assembled into a modular factory as part of a module pipeline comprising one or more modules; and execute an optimization algorithm to select one module from a plurality of modules having the desired module type in a module library 102 to be included in the module pipeline based on one or more predetermined optimization criteria. The module pipeline generation engine 104 may be configured to generate a plurality of suggested pipelines for comparison according to one or more predetermined criteria. The pipeline optimization component 106 may be configured to compare or sort (using, for example, a sorting component) a plurality of pipelines (e.g., pipelines suggested by the pipeline generation engine 104) according to one or more predetermined criteria. The optimization algorithm may be configured to perform local optimization to optimize only the module pipelines, or global optimization to select a plurality of modules of the desired type to be assembled into a corresponding module pipeline in the modular factory. 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; utilization rate of service and equipment; and maximization. In particular, where the collected usage data includes previously measured key performance indicators, these can be used to determine the optimal or preferred selection and sequence of modules for translating preconditions into postconditions while meeting predetermined criteria.

[0081] Regardless of whether the pipeline is generated manually or automatically, the module library 102 may include several specific types of semantic modules from which one or more are best suited for a given purpose. For example, these replaceable modules may have different characteristics; one module may be larger, i.e., have a greater capacity in terms of how much liquid it can distill, or another module may have less remaining runtime before being put into use. Therefore, the question arises when planning the production process: which module to use? To address this, the pipeline optimization component 106 is configured to optimize the pipeline based on one or more predetermined criteria (where multiple unit selections are available). As described above, each semantic module in the module library 102 includes a semantic description describing or representing the underlying module, thereby enriching the underlying module with real data semantically mapped in a structured manner. The pipeline optimization component 106 is configured to perform optimization using the module attributes contained in the semantic description.

[0082] 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, optionally including 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 a unit, equipment availability, unit availability, unit schedule (when it can be reused), mean time between failures (MTBF) of a unit or its equipment, utilization of service and equipment (e.g., frequency of valve opening or closing), resource / material efficiency, minimization of module usage, or any other suitable KPI. The automated engineering support system 100 may also (e.g., in the same database) store data related to previously used module combinations, indicating results in terms of quality, throughput, efficiency, or other KPIs in the modular plant to help assess whether modules in a particular combination have performed successfully. The optimization component 106 uses these criteria to intelligently and automatically select modules that are usable or best suited for the modular plant to be designed or assembled. For example, data identifying which medium flows through a module can be used to determine whether extensive cleaning is required before a module can be used in another plant. The collected data can be used to find the best possible modules for the current plan based on their respective optimization criteria.

[0083] Pipeline optimization component 106 is configured to receive pipelines that are manually or automatically generated as described above and include one or more representations of real or virtual modules or their types. An optimization algorithm is executed to optimize relative to selected criteria using semantic data describing different characteristics and constraints of the modules, thereby minimizing / maximizing one or more selected optimization criteria over a set 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 receiving (input) pipeline, or replacing or exchanging these modules with alternative, more suitable modules. Based on a semantic description including, for example, collected usage data (such as KPIs), the optimization algorithm finds the combination of modules that results in, for example, the highest product quality, highest throughput, highest energy efficiency, etc.

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

[0085] 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.

[0086] If more than one criterion is optimized, the result may be two or more locally optimal pipelines. These pipelines are suggested to the plant operator to determine which criterion is considered more important as the global optimum. The pipeline optimization component 106 can again use the sorting functionality (i.e., the sorting component) to sort the two or more pipelines according to selected or predetermined criteria.

[0087] Optimization can be local, targeting only a given pipeline, or global, instructing how to allocate available module resources across multiple pipelines. For example, if a module has limited remaining runtime before service, which may still be sufficient for planned batch production, then from a global optimization perspective, it's best to use this module so that other similar modules with more remaining runtime can still be used 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 processes that might require it.

[0088] The modules selected by the pipeline optimization component 106 may include real modules and / or virtual modules. For example, virtual pipeline A may be superior to virtual pipeline B because it consumes less energy overall and does not require reference to real module data for optimization. However, real modules may be selected to consider specific optimization criteria based on the collected usage data, such as determining whether a real module is actually available in the real cell pool or, for example, whether it is undergoing maintenance.

[0089] Figure 4 This illustrates an example of using pipeline optimization component 106 to optimize the semantic pipeline 404 of the semantic module. For example... Figure 4 As shown, the smart cell pool managed by module library 102 includes a virtual cell pool 400 and a real cell pool 402. Virtual cell pool 400 includes virtual cells in the form of Semantic Functional Modules (SFMs). As described above, in a non-limiting example, an SFM can be represented by a Module Type Encapsulation (MTP) that defines a module type. Each module type appears only once in virtual cell pool 400. Figure 4The diagram shows module types SFM1-SFMn. The real cells in the real cell pool 402 correspond to the types found in the virtual cell pool 400 and can be associated with the collected usage data. In this example, the plant operator has multiple real cells of different types; here, there are 3 real metering cells and 2 real reaction cells. In the first step, an implicit pipeline 404 is generated manually or automatically (as described above) using certain types of virtual cells, and in the second step, the pipeline optimization component 106 executes an optimization algorithm according to given optimization criteria to replace these virtual cells with representations of real cells of a given type selected from the real cell pool 402, prioritizing one real cell over another. The optimization results are displayed to allow the plant operator to view different plant composition alternatives and their advantages and disadvantages. Figure 4 In the example shown, pipeline optimization component 106 identifies two candidate reaction units (of module type SFM1 selected as the first module in the pipeline) and three candidate metering units (of module type SFM4 selected as the second unit in the pipeline) from the real module pool 402, which can be used to obtain a specific product. In this example, pipeline optimization component 106 selects reaction unit 406 and metering unit 408 for pipeline 404 based on collected usage data stored in the semantic descriptions of the respective semantic units and predetermined optimization criteria. For example, if the predetermined criterion is to maximize module uptime, the optimization algorithm may select units 406 and 408 because those units have a longer MTBF than other candidate units, and / or a longer time until the next predetermined maintenance.

[0090] The pipeline optimization component 106 can be additionally or alternatively used to optimize pipelines that include semantic modules corresponding to actual modules, such as modules input by engineers. In another example of a local optimization scenario, where the pipeline in the initial production plan developed by the engineer includes selected distillation modules that are too large and therefore consume too much energy, the pipeline optimization component 106 selects alternative, smaller distillation modules that meet the planned batch size.

[0091] Although the above references include a semantic description of the collected and used data, which describes the pipeline optimization component 106 as being based on a semantic data model, it should be understood that data from any other suitable source and in any suitable format can be used for optimization.

[0092] Simulation components

[0093] Refer again Figure 1To help plant operators validate module / production line selections, the automation engineering support system 100 may include a simulation component 108 or simulation tool configured to provide simulation functionality to allow simulation of the operation of a modular production line, including one or more modules in a modular plant (whether the production line is manually or automatically generated, and whether it is automatically optimized), for example, to identify potential bottlenecks and inefficiencies, try alternative modules to determine if this optimizes the simulation, or generally simulate 'hypothetical' scenarios. For example, planning may begin with an initial process diagram in the form of a user-generated production line, representing the modules and how they are connected to define the type of process the user envisions. This production line is likely not optimal. The user can leverage the simulation component 108 to simulate different hypothetical 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 one with a longer service time. The simulation component 108 can be automatically configured to simulate different hypothetical scenarios (i.e., alternative configurations / arrangements) and compare the results. The number of scenarios in practice may depend on, for example, the time the planner wants to invest in the simulation.

[0094] Feedback processing unit

[0095] Refer again Figure 1 The automation engineering support system 100 may also include a feedback processing component 110. The feedback processing component 110 can be configured to modify the operation of one or more other components 104-108 of the automation engineering support system 100 based on user feedback. Users may be plant owners or operators, automation engineers, maintenance personnel, development team members, service team members, etc.

[0096] Feedback processing unit 110 can be configured to receive user feedback regarding module or pipeline ordering provided by pipeline optimization unit 106, and use the user feedback to provide subsequently generated improved pipeline ordering. As described above, pipeline optimization unit 106 can be configured to order multiple candidate modules or pipelines according to predetermined optimization criteria. Specifically, feedback processing unit 110 is configured to provide user feedback and the generated pipelines involved in the user feedback as training data to a machine learning model, use the training data to train the model, and use the trained model to generate improved ordering. In this case, user feedback may include, for example, modifications or reordering of the generated ordering.

[0097] Figure 6The feedback processing unit 110 is used to train a machine learning model to provide an improved ranking of the pipeline recommendations generated by the pipeline generation unit 104. In step 1, the optimization unit 106 generates the ranking of the generated pipeline recommendations based on one or more predetermined criteria (in this case, KPI energy cost (in joules) and minimum SFM lifetime (in days)). Figure 6 Two generated pipeline recommendations, 502 and 504, are shown, indicating their ranking in this manner. In step 2, the user (in this example, the owner of three modular factories) provides user feedback 506 regarding the ranking. In the example, the user prefers the second-ranked pipeline recommendation 504 and states the reasons for this preference (reasons and relevance or relational data). In step 3, pipeline recommendations 502 and 504, along with user feedback 506, are fed into a machine learning model by the feedback processing unit 110 as training data to train the model to generate rankings that better meet user preferences.

[0098] In a specific, unrestricted example of training the model, optimization component 106 ranks a set of two alternative pipelines for a chemical plant based on given / suggested optimization criteria, energy costs, and minimum SFM lifetime or service time, similar to the example above. However, optimization component 106 and its underlying algorithms (including the ranking algorithm) do not yet incorporate expert knowledge (which plant owners may possess), particularly regarding the fault tolerance of the chemical plant, where modular parallelism is highly desirable. Therefore, feedback from these chemical plant owners suggests that the second-ranked pipeline in the example above is still preferable (because it contains two identical and functionally identical modules, making production more reliable and safer (i.e., one module might fail, but the other can still function and keep the process active, even at lower throughput)). Thus, the human-understandable rationale in this example includes information about additional expert knowledge—important, yet unmentioned, KPIs for this type of specific plant (chemical plant) that are being considered from now on and heavily weighted in the future. The data and labels (i.e., training data) required to implement and execute this updated sorting behavior will include the initial sorting of the two previously obtained alternative pipeline proposals 502 and 504, and the updated sorting associated with these two alternative pipelines. However, this is not the only example; there are many examples that allow the ML component to recognize the pattern that "two or more parallel modules of the same type are always preferred for a chemical plant." Once recognized by the ML component, it eventually becomes part of the ML model, i.e., part of the updated sorting algorithm.

[0099] Feedback processing component 110 can be configured to use interpretable AI (X-AI). In the specific example above, the human-readable statement corresponding to the aforementioned machine learning / recognition pattern, "If we are dealing with a chemical plant, then modular parallelism is desirable," can be provided as X-AI reasoning support or an interpretable AI justification. Feedback processing component 110 can be configured to obtain such an explanation using a suitable known X-AI method. A non-limiting example could use an inherently interpretable decision tree (since all branches in the tree can be traced back to if-else statements), but it should be understood that other methods are contemplated in this disclosure.

[0100] In this way, the model can be continuously updated based on newly received user feedback used as training data. Learning to sequence modules or pipelines in this manner simplifies the process of generating pipelines in a modular factory, reduces the task of automation engineers, and allows for transparent and evidence-based sequencing recommendations, thereby building trust in system 100. More broadly, optimization component 106 can be configured to analyze the performance of modules or pipelines in a factory and recommend better pipelines based on at least two types of information: that is, not only information containing clear reasons (such as the statement "If we are dealing with a chemical plant, then modular parallelism is desirable"), but also heterogeneous data / evidence that can identify and infer patterns (again, referring to the example above, for the same statement, this would be data / labels about the two alternative pipeline recommendations mentioned above).

[0101] In another example, the feedback processing unit 110 can be configured to use user feedback, not to modify the sorting, but to provide supplementary information accompanying the sorting, such as in the form of a 'transparent suggestion'. The transparent suggestion can include sorting in addition to previous user feedback regarding that sorting or similar sorting. More specifically, the transparent suggestion could take the form of something like, "We sorted the automatically generated pipeline as follows… but other automation engineers or plant owners at this point actually used the XYZ module… and obtained a pipeline with an even higher sorting." (Refer to the above regarding…) Figure 6 The same example given aims to reveal and expose identified patterns (i.e., the statement "If we are dealing with a chemical plant, then modular parallelism is desirable"). Therefore, in this non-restrictive example, the transparent suggestion could be as follows: -

[0102] “We will sort the automatically generated pipelines into sort 1 and sort 2 based on your (i.e., the plant owner’s) optimization criteria (i.e., energy cost and minimum SFM life / service time in this case). But other automation engineers or plant owners follow the pattern of ‘if we are dealing with a chemical plant, then modular parallelism is desirable’, so the enhanced / improved evidence-based sorting would be: ‘the pipeline of sort 2 is an even higher sorting pipeline’.”

[0103] Feedback processing unit 110 can be configured to adjust the algorithm used by pipeline generation engine 104 to generate the proposed pipeline based on user feedback. As described above, pipeline generation engine 104 can operate using a rule-based algorithm configured to implement expert rules for generating the pipeline. Feedback processing unit 110 can be configured to allow adjustment of the rule-based algorithm based on user feedback. For example, feedback processing unit 110 can be configured to facilitate the addition of new rules, modification of existing rules, or deletion of rules (in the rule list or in the rule repository 112). Rules in rule repository 112 can include formalized dependencies as well as rules that can be edited in the same way. Figure 7 The rule repository 112 is described as being updated based on user feedback. In the example shown, the feedback processing unit 110 receives feedback from a user requesting that rule Y be added to the rule repository 112. Another user requests that rule X be modified to rule X". Examples of rules that can be added or modified include, for example, using similar / identical nominal pressures or tank sizes or I / O connections / ports; or metering first, then mixing and heating, followed by storage and cooling; or, if the reactor module has two identical input terminals / connections, then it requires two identical metering modules for the two products.

[0104] The rule-based algorithm can be adjusted based on direct user feedback regarding the requested action. For example, user suggestions can be received from users such as administrators, developers, and vendors. These suggestions can be approved, verified, sorted, and / or weighted automatically by the suggesting user, other users, a human administrator of repository 112, or by the feedback processing unit 110. Alternatively, adjustments to the rule-based algorithm can be inferred based on modifications made by users to the generated pipeline. Such adjustments can be inferred manually by administrators, developers, vendors, etc., analyzing the modifications, or automatically by the feedback processing unit 110.

[0105] Feedback processing component 110 can be configured to adjust the rule-based algorithm only in response to receiving adjustment confirmation. Confirmation can be manual and / or automatic. For example, feedback processing component 110 can be configured to prompt users (e.g., administrators of repository 112) to manually confirm the suggested adjustments based on their expert / domain knowledge. Alternatively, feedback processing component 110 can be configured to automatically confirm adjustments by waiting for a predetermined number of users to provide the same or similar suggestions before processing the request. For example, a new rule might be automatically added when five or more users request its addition. Similarly, existing rules can only be automatically modified when adjustments are manually confirmed (e.g., based on our expert / domain knowledge, including determining which features are not yet included in the rule definition) or in response to multiple independent users requesting the same modification.

[0106] Where feedback processing unit 110 is configured to adjust a rule-based algorithm based on user suggestions (e.g., new rules or modifications to rules), feedback processing unit 110 may be further configured to process one or more counter-suggestions before adjusting the rule-based algorithm. A “counter-suggestion” refers to a second suggestion that is at least partially inconsistent with the first suggestion. For example, a counter-suggestion may include a modification to the rule-based algorithm that is opposite to or different from what the first suggestion suggests. Therefore, feedback processing unit 110 may be further configured to determine which adjustments to make in the presence of counter-suggestions for one or more of those adjustments. This determination may be manual or automatic. For example, feedback processing unit 110 may be configured to prompt a user (e.g., an administrator of repository 112) to manually confirm the suggested adjustments based on their expert / domain knowledge in response to one or more counter-suggestions regarding the proposed adjustments. To allow time to receive counter-suggestions, feedback processing unit 110 may be configured to delay adjustments based on user suggestions for a predetermined period. Alternatively or additionally, feedback processing unit 110 may be configured to automatically confirm adjustments by employing a weighted mechanism. For example, a weighting mechanism can be configured to count the number of identical or similar suggestions and the number of counter-suggestions, and adjust the rule-based algorithm accordingly to validate / approve the adjustment only when the number of identical or similar suggestions exceeds a predetermined factor (e.g., around 5) of the number of counter-suggestions. One or more similarity measures can be used to determine or identify when a suggestion is identical or similar to other suggestions.

[0107] This method of modifying rules allows for the generation of continuously improving pipeline recommendations, taking into account constraints affecting the factory, such as the feasibility and usability of general pipelines, ease of use, and conventions. In some variations of the above examples, the rule-based algorithm can be adjusted during production, or only rules deemed critical can be adjusted in response to manual confirmation.

[0108] Feedback processing component 110 can be configured to facilitate modifications to the semantic data model based on user feedback. Specifically, feedback processing component 110 can facilitate extensions to the semantic data model based on user feedback. User feedback may include suggestions to add one or more elements to the semantic data model. Feedback processing component 110 can be configured to facilitate modifications or extensions to the semantic data model to include the suggested elements. Any element of the semantic data model as described herein can be added, including, for example, relationships (e.g., between inputs and outputs, or between functionality and processed material), module features, KPIs, categories, and tags. This allows the semantic data model to be modified in this way to make it scalable, enabling it to reflect broader domain expertise and an understanding of real-world, practical factory environments (ranked by appropriate weights and importance).

[0109] The model can be expanded by adding suggested elements to an existing list of elements of the same type. For example, the KPI catalog of a semantic data model can be expanded by adding user-suggested KPIs. Alternatively, the semantic data model can be expanded by introducing new types of elements. For example, if the semantic data model only covers energy values ​​and pipe connections, it can be expanded to include process technology, procedure experience values, or empirical values. This could be, for example, the forward pressure from one module to another subsequent module, or, for example, a valve that can only be opened incrementally, even if the previous module provides it with input material, and cannot facilitate a direct open / closed state, or, for example, the volume-temperature-pressure-relationship of a reactor that formally allows xyz values, but in practice, it is best and recommended to use them only for 90% workload / utilization.

[0110] Feedback processing unit 110 can be configured to allow users to edit (e.g., add or modify) the features used by the pipeline optimization and / or sorting algorithms described herein. Automation engineering support system 100 can maintain a list, database, or catalog of optimization criteria or KPIs for this purpose. Feedback processing unit 110 can be configured to allow users to edit this criterion catalog. Feature weights can be selected based on the user's KPI importance. In a non-limiting example, if a user wants to focus on energy efficiency, they can instruct the sorting algorithm to attach higher weights to all KPIs related to energy costs. In another non-limiting example, for example, a user can suggest adding / including a KPI to focus on "convenience" in a pipeline, such as "module on casters." Here, "convenience" can be a KPI to be added to the criterion catalog, and then the sorting algorithm will prioritize the KPI "module on casters" when the user commands the sorting algorithm to prioritize the pipeline. Here, "convenient pipeline" refers to a KPI that describes several procedures that would be applicable to the expected process (e.g., different focuses in different industry sectors) but which are not yet depicted / defined in the semantic data model. For example, as mentioned above, this could be used to represent module parallelism as a desirable feature of the pipeline (based on reliability-KPI or module-parallelism-KPI). In other non-limiting examples, users could add industry-specific or use-case-specific elements or element types to the semantic data model. For example, an oil and gas industry user might add a KPI to focus on continuous operation or maintenance, while a pharmaceutical industry user might add a KPI to focus on accuracy (e.g., no variation or outliers in batch processes), and an energy-intensive industry user might add a KPI to focus on energy cost / energy efficiency, such as avoiding peak current.

[0111] In the case of global or subglobal operation of feedback processing component 110, the semantic data model can be modified only in response to a predetermined minimum number of users who suggest the same modification. For example, a new feature or KPI can be integrated only when suggested by 5 or more independent users (e.g., customers, automation engineers, factory owners, etc.), thus ensuring that the modification is significant rather than an outlier or a rare or special desire.

[0112] In one example, the feedback processing component 110 can operate in a plant-centric manner, that is, personalized for each plant owner. In other examples, the feedback processing component 110 can operate globally across multiple plants or subglobally across plants in a specific field (e.g., chemical plant, mining operation) to more broadly cover best practices.

[0113] In summary, the feedback processing component 110 surrounds the other components 104-108 of the automation engineering support system 100, thereby facilitating a scalable, learning, and continuously improving automated pipeline generation and optimization system that adapts to real-world use cases and application domains in response to user evaluations of its outputs.

[0114] application

[0115] It can provide an automated engineering support system 100 as described in this article: -

[0116] O serves as a central pool of units provided to multiple plant operators. This central pool comprises a collection of semantic modules corresponding to modules previously used by plant operators, along with semantic descriptions and usage data collected from the contracting plant. Therefore, it facilitates not only cell-centric local optimization but also global, cell-centric pipeline context optimization. This solution is likely cloud-based, scalable, and easily accessible.

[0117] This serves as a private unit pool managed by the plant operator. The private unit pool allows the plant operator to manage and control a collection of semantic modules corresponding to the actual modules owned by the operator. Parameters, KPIs, and other collected usage data (best practices, calibration parameter combinations, maintenance intervals, MTBF, last maintenance completed, last used material, whether cleaned, active / available / unused, etc.) are collected from the actual modules and uploaded to the database to allow the application system's pipeline generation engine and component optimization. Both on-premises implementation and cloud-based solutions are possible depending on the plant operator's wishes / requirements.

[0118] o as an internal product to reduce costs for factory operators, or as an offer to customers to reduce their own costs.

[0119] The topics described in this article have specific applications in module-based production and resource planning. Particularly in small-batch pharmaceutical production, module resources are frequently exchanged between different batches. When planning new batches or redesigning the module setup for existing batch production (e.g., because the production load has changed and the selection of existing modules appears to create bottlenecks), the topics described in this article will allow planners to identify and select the correct (i.e., the most suitable) modules.

[0120] The topics described in this article can be applied to other aspects of module maintenance planning. Modules require periodic maintenance and have characteristics such as "service time," indicating how much runtime remains before the next scheduled service check. Here, optimization and hypothetical simulations can help determine the optimal maintenance schedule for a module. For example, with the help of a known production plan specifying how different modules will be used in the near future, the example optimization scenario will perform module maintenance earlier than planned because it will not be used then, resulting in ultimately better utilization and process output.

[0121] Therefore, the benefits provided by the automated engineering support system 100 described herein include, among other things, (1) the reuse of modules and a corresponding reduction in engineering workload through a searchable pool of modules; (2) the simplification or automatic generation of feasible pipelines that (i) are directly compatible with semantic checks and controls, and (ii) can be optimized for other criteria such as uptime, maintenance intervals, availability, etc.

[0122] Control Engineering Support System

[0123] While Automation Engineering Support System 100 focuses on supporting automation engineers (during the automation engineering or commissioning phase), Control Engineering Support System 150 focuses on supporting control engineers (i.e., operators or production planners during the operation phase). Return to Reference Figure 1 The control engineering support system 150 includes one or more of the following: execution and control engine 152; plant optimization component 154; quality control component 156; and certification component 158.

[0124] Execution and control engine

[0125] Control and execution engine 152 provides automated semantic pipeline execution capabilities, enabling the system to adjust, control, and / or execute itself. Execution and control engine 152 is configured to operate using the same semantic data model as the automation engineering support system 100, and therefore can operate using semantic pipelines and semantic data as described herein. Execution and control engine 152 can also access data from actual module (e.g., functional module) instances in delegated pipelines within a modular factory. For this purpose, control and execution engine 152 can be configured to receive data from factory-based monitoring infrastructure (including, for example, sensors and other reporting devices), thus enabling real-time monitoring of factory pipeline execution and feeding data to the software-based control and execution engine 152. Control and execution engine 152 can be configured to translate or interpret the data it receives from the monitoring infrastructure into data conforming to the semantic data model. Control and execution engine 152 is configured to run pipelines that may or may not have been generated in the manner described above and subsequently delegated. The control and execution engine 152 can perform some or all of the functions of a manufacturing execution system (MES), and therefore can be configured to perform functions in real time, including, for example, scheduling and resource allocation, scheduling and execution of production orders, collection of production data and production analysis, to supervise, execute and / or control the transformation from product to finished product. The control and execution engine 152 can be configured to track and record processes to record captured data, processes, and process results. The control and execution engine 152 uses data conforming to a semantic data model to perform these functions.

[0126] Referring again to the example above concerning a purification process module with the service "PURIFY," this service requires molten steel as input. This precondition can be represented in a semantic data model by a four-dimensional condition vector [0, 76, 2, -] describing the required input attributes. Here, the zero-dimensional to three-dimensional attributes represent the attribute type (0 = material), material (76 = steel), polymerization state (2 = liquid), and durability (- = unconditionally applicable), respectively. The control and execution engine 152 is configured to immediately initiate the module service "PURIFY" in response to the presence or detection of the input material described by the vector [0, 76, 2, -] at the module's input pipe. In this case, the first module requires input from a second and a third (potentially different or parallel) module (e.g., ...). Figure 5 In another non-limiting example of two (possibly different) inputs (as shown), the control and execution engine 152 can command the first module to execute only (but as soon as possible) after the second and third modules have both provided outputs corresponding to the input preconditions of the first module.

[0127] Other specifiers in the n-dimensional condition vector can be used to represent the services exposed by the module, thus providing a semantic description of these services. The specifiers in the n-dimensional condition vector can be used to distinguish between "service operation" (where the quantity specifier can be used to distinguish the service exposed by the module) and "state model operation" (where the quantity specifier can be used to distinguish the service operation) and "state model operation" (where the quantity specifier can be used to distinguish the service operation) of the services exposed by the module. Information describing the module services can be collected from the state model (including, for example, a causal matrix) as needed. Other specifiers can also be used to distinguish between parallel and sequential execution of services. For example, a module that provides the functionality to run n services in parallel might have the specifier "supports service-level parallelism," and parallelizable services can be given corresponding flags or annotations indicating which other services they can run in parallel with. Some modules may allow parallel execution of services, while others may not. For example, PackML allows only one service or one finite state machine / automaton per unit. Other specifiers can be used to represent dependencies between services. These specifiers can be built on the xCE matrix or can also use other descriptive techniques. For example, in Katharina Gohr et al.'s ATP paper "Technik-Kommunikation leicht gemacht:Cause-and-Effect-Diagramm als" published on January 2, 2014... xCE is described in "". This can be useful in sequential, parallel, or concurrent scenarios.

[0128] The control and execution engine 152 can be configured to respond to a start command or approval received from a human operator (e.g., by clicking the "Run" button 502, as...). Figure 5 (As shown) a production line that operates, or can be configured to run automatically, starting from the availability of various inputs, the fulfillment of maintenance intervals, or other optimization criteria based on automated checks. For example, this could also schedule or time the production of, for example, pharmaceuticals or perishable products, where the final reaction process, such as in a reaction module, should be as late as possible, but logistics should be timely.

[0129] The control and execution engine 152 thus facilitates the control of engineering, operations, and production planning. The control and execution engine 152 therefore provides support for or replaces autonomous or semi-autonomous factory assembly line operations with human operators and production planners. This reduces the need for production scheduling features and allows for simpler production scheduling functionality at higher levels of automation. It alleviates or eliminates the need for MES and scheduling operations.

[0130] Factory operation optimization components

[0131] The factory operation optimization component 154 is configured to use data from a modular factory (e.g., from sensor 504, such as...).Figure 5 The collected data (shown in the diagram) or other KPIs are used to perform real-time, multi-factor, plant-specific optimizations to further optimize its execution. The collected data and KPIs again conform to the semantic data model. Optimizable KPIs include, for example, cost, energy / resources, and maintenance time. In one example of optimizing plant operations based on energy cost, plant operation optimization component 154 knows that a certain quantity of product X will be produced via a specific production line Y, which takes, for example, 20 minutes to produce the product, and the delivery date is tomorrow. Plant operation optimization component 154 can instruct control and execution engine 152 to wait until nighttime, when energy costs are lower. When using multiple factors, user-specified relative importance instructions can be received and used for optimization. For example, the plant owner can specify relative importance by providing a weighted list of KPIs / factors, and plant operation optimization component 154 is configured to calculate the total cost of alternative production line options and the total cost of its planned execution accordingly. For the semantic data model, the cost of the production line can be calculated as...

[0132]

[0133] Where k = 1…n encompasses all SFMs across all production lines, j = 1…m encompasses all types of costs (e.g., energy, next maintenance due date, or CO2 emissions), and i encompasses all production line alternatives, such that c multiplied by v describes the cost c of SFM relative to the amount or volume of material processed, weighted by the corresponding cost KPI importance μ. This allows the plant owner to specifically weigh and prioritize the importance and strength of KPIs relative to each other. Additionally, a penalty factor p can be selected. i >1 (by default p) i =1) For example, penalizing pipelines based on knowledge in the ontology, to explain, for instance, procedures that are environmentally unfriendly or legally prohibited in certain areas. The optimal pipeline is considered to be the one with the lowest total cost among all potentially feasible pipeline alternatives (relative to a given KPI weight). Some parameters may be functions of time, while others may be constants. For example, different electricity prices throughout the day might mean that energy costs could be a function c = f(t), which might resemble a sinusoidal function of rising prices during the day and lower prices at night. Therefore, the cost (Pipe i It may also depend on time; the overall minimum depends not only on the selected pipeline but also on its respective execution time.

[0134] Optimization can be global, industry-specific, or sector-specific (e.g., applicable only to oil and gas plants but not to pharmaceutical plants) or plant-specific.

[0135] Quality control components

[0136] Quality control component 156 serves as an automated semantic quality control system that can automatically evaluate or monitor the semantic results and their quality obtained from the production line, for example, to ensure that the quality of intermediate or final products falls within predetermined tolerances or meets certain thresholds. For example, quality control component 156 can be configured to check whether the pH value of product X is correct within a certain tolerance. The pH value is represented by a specifier in an n-dimensional condition vector conforming to a semantic data model. In a non-limiting example, an acidic liquid material can be semantically represented using a condition vector [0, 32, 2, -, 1.87 (+ / - 0.5)], where attributes in the zero to four dimensions represent attribute type (0 = material), material (32 = sulfuric acid), polymerization state (2 = liquid), durability (- = unconditionally applicable), and pH value (pH = 1.85, tolerance + / - 0.5, representing a range from 1.35 to 2.35).

[0137] Certified components

[0138] The certification component 158 ​​acts as an automated semantic quality control certification system, which can create certifications or protocols for automated quality control. Figure 5 The semantic quality control certification generated by certification component 158 ​​is shown. Assuming this is correct, quality control certification can be obtained directly from the module / SFM settings. In other words, if the SFM settings and calibration are correct, i.e., its I / O pre- / post-conditions, such as pH, durability, temperature, pressure, etc., are correct, then the final product will be exactly known because the pipeline execution and control component 152 will accurately execute the contents of the pipeline that has been specified to have the corresponding module.

[0139] The Control Engineering Support System 150 therefore provides high transparency in automation and control engineering support using semantic data models and evidence-based reaction algorithms, and can be used to complement the Automation Engineering Support System in a way that supports both automation engineers and control engineers. Of course, it should be understood that these two systems can also exist independently.

[0140] Now for reference Figure 8 This is a high-level illustration of an exemplary computing device 800 that can be used according to the systems and methods disclosed herein. Specifically, the computing device 800 can be used to implement the modular automation support system 10 described above. The computing device 800 includes at least one processor 802 that executes instructions stored in memory 804. For example, the instructions may be instructions for implementing functionality described as being performed by one or more 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.

[0141] 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 102 and its database.

[0142] 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 envisioned that external devices communicating with the computing device 800 via the input interface 810 and the output interface 812 can be included in an environment that provides virtually any type of user interface that a user can interact with. Examples of user interface types include graphical user interfaces (GUIs), natural user interfaces (MAAs), etc. For example, a GUI can accept input from a user using 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 speech, vision, touch, gestures, machine intelligence, and so on.

[0143] 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.

[0144] The various functions described herein can be implemented in hardware, software, or any combination thereof. If implemented in software, these functions can be stored or transmitted as one or more instructions or code on a computer-readable medium. A computer-readable medium includes a computer-readable storage medium. A computer-readable storage medium can be any available storage medium accessible to a computer. By way of example and without limitation, this computer-readable storage medium can include RAM, ROM, EEPROM, CD-ROM or other optical disc storage devices, magnetic disk storage devices or other magnetic storage devices, or any other medium capable of storing desired program code in the form of instructions or data structures and accessible to a computer. As used herein, disks and optical discs include compact optical discs (CDs), laser optical discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs (BDs), wherein disks typically magnetically reproduce data, and optical discs typically optically reproduce data with a laser. Furthermore, transmitted 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 transfer of a computer program from one place to another. For example, a connection can be a communication medium. For example, if software is transmitted from a site, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the definition of communication medium includes coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave. The above combinations should also be included within the scope of computer-readable media.

[0145] Alternatively or additionally, the functionality described herein may be performed at least in part by one or more hardware logic components. For example, and without limitation, the 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.

[0146] 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.

[0147] 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 in accordance with knowledge well known to those skilled in the art, regardless of whether such features or combinations of features solve any problem disclosed herein, and not to limit the scope of the claims. The applicant notes that aspects of the invention may consist of any such individual features or combinations of features.

[0148] Although the invention has been described and illustrated in detail in the accompanying drawings and the foregoing description, this description is to be regarded as exemplary and not restrictive. The invention is not limited to the disclosed embodiments. Other variations of 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.

[0149] In the claims, the word "claim" does not exclude other elements or steps, and the indefinite article "" does not exclude multiple. A single processor or other unit can perform the functions of several items listed in the claims. The fact that certain measures are listed in mutually different dependent claims does not indicate that combinations of these measures cannot be used advantageously. Computer programs can be stored / distributed on suitable media (such as optical or solid-state storage media provided with or as part of other hardware), but can also be distributed in other forms, such as via the Internet or other wired or wireless telecommunications systems.

[0150] Any reference marks in the claims should not be construed as limiting the scope.

Claims

1. An automated engineering support system (100) comprising: a pipeline generation engine (104) configured to receive input data indicative of at least one precondition and at least one postcondition for a required pipeline for a modular factory, and to generate a plurality of proposed modular pipeline, each proposed modular pipeline comprising one or more modules capable of transforming the at least one precondition into the at least one postcondition; a pipeline optimization component (106) configured to rank the plurality of proposed modular pipelines proposed by the pipeline generation engine (104) according to one or more predetermined criteria; a feedback processing component (110) configured to modify the operation of one or more other components (104-108) of the automated engineering support system (100) based on user feedback, wherein the feedback processing component (110) is configured to receive the user feedback on the pipeline ranking provided by the pipeline optimization component (106), and to use the user feedback to provide a ranking of improved pipelines subsequently generated by the pipeline generation engine (104), wherein the feedback processing component (110) is configured to provide the user feedback and the generated pipelines to which the user feedback relates as training data to a machine learning model, to train the model using the training data, and to use the trained model to generate an improved ranking.

2. The automated engineering support system (100) of claim 1, wherein the user feedback comprises a modification to the generated ranking.

3. The automated engineering support system (100) of any one of the preceding claims, wherein the feedback processing component (110) is configured to adjust an algorithm used by the pipeline generation engine (104) of the automated engineering support system (100) to generate proposed pipelines based on user feedback.

4. The automated engineering support system (100) of claim 3, wherein the algorithm used by the pipeline generation engine (104) to generate proposed pipelines comprises a rule-based algorithm configured to implement expert rules for generating the pipelines, wherein the feedback processing component (110) is configured to facilitate, based on user feedback requesting or inferring actions, the addition of new rules, the modification of existing rules, or the deletion of rules in a rules repository (112) used by the pipeline generation engine (104).

5. The automated engineering support system (100) of any one of the preceding claims, wherein the automated engineering support system (100) uses a semantic data model for providing an abstract representation of a module, a modular pipeline, or a modular factory, and wherein the feedback processing component (110) is configured to facilitate, based on the user feedback, modifications to the semantic data model.

6. The automation engineering support system (100) of claim 5, wherein the user feedback comprises a suggestion to add one or more elements to the semantic data model, and wherein the feedback processing component (110) is configured to facilitate a modification of the semantic data model to include the suggested elements.

7. The automation engineering support system (100) of claim 5 or 6, wherein the feedback processing component (110) is configured to facilitate the modification of the semantic data model by adding the suggested elements to a list of existing elements of the same type.

8. The automation engineering support system (100) of any one of claims 5 to 7, wherein the feedback processing component (110) is configured to facilitate the modification of the semantic data model by introducing an element of a new type suggested in the user feedback.

9. The automation engineering support system (100) of claim 1, wherein the feedback processing component (110) is configured to allow the user to add or modify a standard in a standard catalog.

10. The automation engineering support system (100) of any one of claims 5 to 8, wherein the feedback processing component (110) is configured to allow the user to suggest an inclusion of an industry-specific or use-case-specific element or element type in the semantic data model.

11. The automation engineering support system (100) of any one of the preceding claims, wherein the feedback processing component (110) operates in a plant-centric manner.

12. The automation engineering support system (100) of any one of the preceding claims, wherein the feedback processing component (110) operates globally across multiple plants or sub-globally across multiple plants in a specific domain.

13. The automation engineering support system (100) of any one of claims 5 to 8, 10 in combination with claim 12, wherein the feedback processing component (110) is configured to allow a modification of the semantic data model only in response to a satisfaction of a predetermined minimum set of criteria.

Images