Engineering and operation support systems and methods

Abstract

The invention relates to engineering and operation support systems and methods. A support system for defining a model representing at least a portion of an industrial automation system is provided herein. The support system is configured to: obtain a user-provided definition of at least a portion of the model; processing the user-provided definition to verify correctness or integrity of at least a portion of the model with reference to the at least one knowledge base; and in response to determining that the user-provided definition includes incorrect or incomplete information, providing a system output, where the system output includes a definition that prompts the user to provide correct or complete information for inclusion in at least a portion of the model.

Description

Field of the Invention

[0001] The present invention relates to an intent-based engineering support system and method. Background Art

[0002] In the field of process and automation engineering, intent-based approaches are gradually replacing requirements-based approaches for the design and engineering of modular process plants. Various tools have been developed in recent years to support intent-based engineering of modular process plants, such as ontology editors for creating formal representations of engineering intent as ontologies. Nevertheless, existing manual methods for creating representations of engineering intent using such ontology editors are prone to errors. Missing, ambiguous or inconsistent information in the representation of engineering intent may lead to problems during the design, commissioning and / or operation of modular process plants. Summary of the invention

[0003] To better address one or more of these concerns, a support system is provided in a first aspect of the present invention for defining a model representing at least a portion of an industrial automation system, wherein the support system is configured to:

[0004] obtaining a user-provided definition of at least a portion of a model;

[0005] processing the user-provided definition to verify the correctness or completeness of at least a portion of the model with reference to at least one knowledge base; and

[0006] In response to determining that the user-provided definition includes incorrect or incomplete information, providing a system output, wherein the system output includes prompting the user to provide correct or complete information for inclusion in the definition of at least a portion of the model.

[0007] In this way, the system provides systematic and knowledge-based support for the engineering and operation of industrial automation systems.

[0008] The support system may be configured to trigger validation of at least a portion of the model in response to the occurrence of at least one trigger condition. In one example, the support system is configured to trigger validation in response to the absence of any user input within a predetermined time period. Additionally or alternatively, the support system may be configured to trigger validation occasionally or periodically.

[0009] The support system may provide a user interface to enable a user to define at least a portion of a model. The user interface may form part of an editor or editing tool for creating, editing, saving and / or exporting a definition of at least a portion of a model. The user interface may include a graphical user interface. Additionally or alternatively, the user interface may include a natural language user interface (NLUI). The natural language user interface may include a ChatBot function.

[0010] The support system may be configured to execute a model validation algorithm for verifying the correctness or completeness of at least a portion of the model. The model validation algorithm may be configured to traverse a graph structure of at least a portion of the model to identify incorrect or incomplete information. Traversing the graph structure may include traversing a hierarchical tree structure of at least a portion of the model. Traversing the graph structure may include traversing all nodes, or traversing at least a predetermined subset of all nodes. Traversing the graph structure may include traversing along any relationship of the graph structure in any dimension. Where the graph structure includes a hierarchical tree structure, traversing the hierarchical tree structure may include breadth iterations of nodes, depth iterations of nodes, or any combination thereof.

[0011] The model validation algorithm may include applying a rule-based or logic-based algorithm to identify incorrect or incomplete information. The rule-based or logic-based algorithm may be configured to identify incorrect or incomplete information based on one or more criteria that define a correct or complete model. The criteria may be derived from at least one knowledge base. The knowledge base may include at least a portion of a knowledge graph and its underlying TBox representation. Therefore, the knowledge base referenced for performing validation may contain a TBox representation. The knowledge base or any portion thereof may belong to at least one domain of interest. The criteria that define a correct or complete model may be derived or obtained from the TBox representation. The model validation algorithm may be configured to identify incorrect or incomplete information by comparing an ABox representation of a model provided by a user with a TBox representation. Comparing the ABox representation with the TBox representation may include identifying at least one element of the TBox representation that the user has not yet instantiated in order to identify the incomplete information. Comparing the ABox representation with the TBox representation may include identifying at least one element that the user has incorrectly instantiated in order to identify the incorrect information.

[0012] System output, for example including prompting a user to provide correct or complete information to be included in the definition of at least a portion of the model, may be output via the user interface. The support system may be configured to obtain supplemental input including correct or complete information from the user and incorporate the supplemental information into the definition of at least a portion of the model. The supplemental input may again be obtained via the user interface. Where the user interface includes a NLUI, information may be exchanged between the user and the system in an intuitive manner.

[0013] The support system may also include an automatic suggestion function configured to suggest information to be included in the definition of at least a portion of the model, for example, to correct or complete information already present in the model, more specifically, to correct or complete information in the ABox portion of the model through TBox information already present in the model. The automatic suggestion function may be configured to use historical data to provide suggestions. The historical data may include previous models, whether in text form or in an ontology representation. More specifically, the historical data may include examples of historical models, such as engineering intent expressed in text form and / or an ontology representation of engineering intent. Based on the historical data, the support system is configured to suggest information to be included in the definition of at least a portion of the model, for example, included in a statement currently being edited, included in a statement that has been edited, and / or included in a statement that has not yet been edited. The support system may be configured to compare the current definition with at least one historical definition and suggest information to be included in the current definition based on at least one difference determined during the comparison. Any such suggestion may form part of the prompt disclosed herein, or may be output together with the prompt as part of the system output.

[0014] The support system may include a machine learning model trained to identify incorrect or incomplete information in a definition of at least a portion of a model. The model may be trained to identify incorrect or incomplete information based on training data sets, each training data set including at least one user-provided definition of at least a portion of the model, at least one knowledge base or portion thereof (e.g., an ontology representation or (e.g., a local) knowledge graph), and at least one prompt to a user. The model may be trained to identify incorrect or incomplete information using supervised learning. The model may be further trained using reinforcement learning to reward or penalize results based on the supplemental information provided by the user in response to a prompt, for example, by penalizing a prompt to provide complete information in response to the supplemental information indicating that it is not possible to provide complete information.

[0015] The system output may also include at least one confidence metric. At least one confidence metric may indicate the confidence of the determination that the user-provided definition contains incorrect or incomplete information. For example, in the case of using a machine learning model, a confidence score may also be determined and provided as part of the system output to indicate the likelihood that the determination is correct. The determination of the confidence metric may include using at least one domain-representation-based logical reasoner to reason whether the input information is correct and complete, such as by identifying matches or mismatches between elements, excluding elements, identifying unexpected or inconsistent elements, or any combination thereof. The support system may be further configured to increase the confidence of determining that the user-provided definition contains incorrect or incomplete information in response to the user (e.g., after being prompted by the system) entering further information. Providing confidence metrics in this manner provides further assistance to engineers in further completing representations and becoming aware of possible inconsistencies.

[0016] The support system may include a machine learning model trained to interact with a user via a user interface, such as a large language model trained to converse with a user via a NLUI.

[0017] According to a second aspect, there is provided an industrial automation system or part thereof manufactured according to a model defined using the support system of the first aspect.

[0018] According to a third aspect, there is provided a module for an industrial automation system manufactured according to a model defined using the support system of the first aspect.

[0019] The model of the second aspect or the third aspect may include the intent model described herein.

[0020] According to a fourth aspect, there is provided a supporting method for defining a model representing at least a part of an industrial automation system, the method comprising:

[0021] obtaining a user-provided definition of at least a portion of a model;

[0022] processing the user-provided definition to verify the correctness or completeness of at least a portion of the model with reference to at least one knowledge base; and

[0023] In response to determining that the user-provided definition includes incorrect or incomplete information, providing a system output, wherein the system output includes prompting the user to provide correct or complete information for inclusion in the definition of at least a portion of the model.

[0024] Any optional feature or sub-aspect of the first to third aspects may form part of the fourth aspect.

[0025] According to a fifth aspect, a manufacturing method for an industrial automation system is provided, the method comprising manufacturing at least a part of the industrial automation system according to a model defined using the supporting method of the fourth aspect.

[0026] "Manufacturing" at least a portion of an industrial automation system may include producing or assembling at least a portion of an industrial automation system from components or raw materials. Additionally or alternatively, "manufacturing" at least a portion of an industrial automation system may include configuring (e.g., reprogramming or repurposing) at least a portion of a pre-existing industrial automation system.

[0027] At least a portion of the industrial automation system manufactured according to the intent model may include a module for the automation system. The method of the fifth aspect may include integrating the module into the industrial automation system.

[0028] According to a sixth aspect, there is provided an operating method for an industrial automation system, the method comprising operating at least a part of the industrial automation system to perform an industrial process according to a model defined using the supporting method of the fourth aspect.

[0029] The method of any of the fourth to sixth aspects may be at least partially computer-implemented.

[0030] According to a seventh aspect, there is provided a computing system configured to perform the method of any of the fourth to sixth aspects.

[0031] According to an eighth aspect, there is provided a computer program (product), the program comprising instructions which, when executed by a computing system, enable or cause the computing system to perform any of the methods of the fourth to sixth aspects.

[0032] According to a ninth aspect, a computer readable (storage) medium is provided, the computer readable (storage) medium comprising instructions which, when executed by a computing system, enable or cause the computing system to perform any of the methods of the fourth to sixth aspects. The computer readable medium may be transient or non-transient, volatile or non-volatile.

[0033] The term "domain" as used herein may relate to any industry domain or industrial field in which automation systems are applied, such as process industry, energy, oil and gas, chemical, petrochemical, etc. In one example, the domain may include the process and automation engineering (P&AE) domain.

[0034] An “automated system” refers to a system used for process automation, factory automation, or warehouse automation. An automated system may include an industrial facility, such as a production plant or a processing plant for performing an industrial process. An industrial process may be a continuous, batch, or discrete process. An automated system may include one or more pipelines for converting one or more pipelines or raw materials into a product. Additionally or alternatively, an automated system may include one or more assembly lines for assembling one or more components into a product. An automated system may be modular or monolithic (i.e., non-modular).

[0035] As used herein, the term "model" may refer to any model of at least a portion of an industrial automation system defined using a formal modeling approach.

[0036] In one example, the model includes an intent model. In this example, the support system can be described as an intent-based engineering support system. The term "intent model" refers to a formalized representation of engineering intent. The intent model can include a textual representation of engineering intent. Additionally or alternatively, the intent model can include an ontological representation of engineering intent. Additionally or alternatively, the intent model can include a graph-based representation of engineering intent.

[0037] The model can be used during any phase of the plant life cycle, from the engineering phase (process engineering and / or automation engineering) to the operational phase, i.e. from design time to runtime. For example, during the operational phase, the model can be used when implementing a new process recipe. In this case, the support system can be described as an operational support system, or in case of cross-phase use as an engineering and operational support system.

[0038] The term "module" as used herein refers to a process unit that packages equipment, instruments, and / or controllers to facilitate the combination of automation systems in a modular manner. In some contexts, a module may be referred to as a process equipment assembly (PEA). The functionality of a module may be accessed through one or more services. Module services may be orchestrated by a monitoring system, which may be a distributed control system. Module services may be described in a standardized manner, such as via a module type package (MTP).

[0039] As used herein, the term "support system" may be referred to as an "engine," "unit," or "tool," as appropriate, and may refer to hardware, firmware, and / or software configured to perform any of the operations or algorithms described herein. Hardware may include, alone or in any combination, hardwired circuits, programmable circuits, such as a computer processor including one or more separate instruction processing cores, or state machine circuits. Firmware may be embodied as code, instructions, and / or data stored or hard-coded in a storage device (e.g., a non-volatile storage device). Software may be embodied as a software package, code, instructions, and / or data recorded on at least one transient or non-transient computer-readable storage medium.

[0040] As used herein, the term "acquire" may include, for example, receiving from another system, device, or process; receiving via interaction with a user; loading or retrieving from storage or memory; measuring or capturing using a sensor or other data acquisition device.

[0041] As used herein, the term "determining" includes a wide variety of actions and may include, for example, computing, calculating, processing, deriving, investigating, looking up (e.g., looking up in a table, a database, or another data structure), determining, etc. Furthermore, "determining" may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), etc. Furthermore, "determining" may include solving, selecting, choosing, establishing, etc.

[0042] The indefinite article "a" or "an" does not exclude a plural form. In addition, the articles "a" and "an" as used herein should generally be interpreted as "one or more", unless otherwise specified or clear from the context to indicate a singular form.

[0043] Unless otherwise specified or clear from the context, the phrases "one or more of A, B, and C," "at least one of A, B, and C," and "A, B, and / or C" as used herein are intended to refer to all possible permutations of one or more of the listed items. That is, the phrase "A and / or B" means (A), (B), or (A and B), and the phrase "A, B, and / or C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C).

[0044] The term "comprising" does not exclude other elements or steps. In addition, the terms "including", "comprising", "having" and the like are used interchangeably in this document.

[0045] The present invention may include one or more aspects, embodiments or features in isolation or combination, regardless of being specifically disclosed in that combination or in isolation.Any optional feature or sub-aspect of one of the above aspects may be applied to any other aspect as appropriate.

[0046] The above-described aspects will become apparent and elucidated by reference to the detailed description provided hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0048] Figure 1 illustrates a modular automation system in which the systems and methods disclosed herein may be practiced;

[0049] Figure 2 The diagram shows the Figure 1 A non-limiting example of an intent model for a modular automation system is shown in;

[0050] Figure 3 illustrates a non-limiting example of a modular intent model created by decomposing a larger intent model;

[0051] Figure 4 The diagram can be used to create Figure 2 or Figure 3 A subset of the T-Box of the intent engineering ontology of the intent model shown in ;

[0052] Figure 5 Pictured Figure 4 The T-Box is instantiated to create a non-limiting example of an intent model for an oil and gas industry use case;

[0053] Figure 6 schematically illustrates the support systems and workflows along the main engineering stages from process to automation engineering according to the present disclosure; and

[0054] Figure 7 A computing system that can be used in accordance with the systems and methods disclosed herein is illustrated. DETAILED DESCRIPTION

[0055] Figure 1A modular automation system 100 is illustrated in connection with which the systems and methods disclosed herein may be practiced. The modular automation system 100 includes a module layer 102 and an orchestration layer 104. The module layer 102 includes a plurality of process modules 106, each of which includes a controller that executes control logic for the module 106. Each module 106 provides a set of encapsulated process functions, called services, such as mixing, tempering, or heating, which may be orchestrated by the orchestration layer 104. The orchestration layer 104 includes an operator console 108 and a monitoring system 110. Communication between entities in the module layer 102 and the orchestration layer 104 occurs via an infrastructure network 112, for example using the OPC UA (Unified Architecture) protocol. The orchestration layer 104 integrates the process modules 106 so that they are combined into a process plant. By controlling the services in the correct manner, the monitoring system 110 ensures that the modules 106 cooperate to meet the needs of the modular automation system 100 in executing an industrial process.

[0056] The design and / or manufacture of the modular automation system 100 and / or the individual modules 106 may be performed using an intent-based approach. Intent-based engineering typically starts with intent modeling, where the intent of the plant operator is formulated through a formalized intent model, which will be used later during the plant design. The intent model typically contains several levels of elements: at least one plant goal, defined to be independent of later realizations (e.g., independent of the type or number of possible modules); at least one realization for achieving the goal; and at least one requirement associated with each realization. Associations exist between the different elements in order to model dependencies and causal relationships between the elements. The goals may initially be formulated using a controlled natural language. In a non-limiting exemplary use case, hereinafter referred to as Example 1, the formulated goals of a process engineering system may be: "I want to achieve separation of input products"; "I want to achieve constant pressure in a container"; "I want to prevent gas from leaking from a container". The realization reflects the application of general knowledge of known problems (e.g., selecting standardized PEA types for frequently occurring process steps, using PEA databases, process flow diagrams, etc.). Depending on the modularity and overall plant parts, the realization may represent specific functions, technologies, or decisions. Finally, requirements are established in terms of parameters (products and process steps), required technical resources and products. These requirements represent specific knowledge related to the planning and realization of a specific modular factory (e.g., specific required process parameters such as temperature, or specific required equipment such as pressure valves). Requirements can constrain the realization or specify the realization.

[0057] The information about goals, implementations and requirements obtained in this way is then formalized to produce an intent model, which may take the form of an ontology (e.g. stored in .owl format) providing a formal mapping of the relationships between the various elements of the intent. It will be appreciated that other formalization methods are possible, such as using other graph-based formats.

[0058] Figure 2 Diagram showing the separation of oil, gas and water such as Figure 1 One non-limiting example of an intent model 200 of a modular automation system is shown.

[0059] In order to be able to set requirements for the individual modules 106, the intent model 200 may be modularized.

[0060] Figure 3 Illustrated is a non-limiting example of a modular intent model 300 created by decomposing a larger intent model into smaller sub-models or partial models.

[0061] After the goals, implementations and requirements of individual modules are modeled using such a local model 300, abstract services and module representations can be extracted therefrom for use by module manufacturers as a basis for designing and developing appropriate services for the module.

[0062] The creation of such an ontological (or graph-based) intent model 200, 300 is typically performed by an engineer using an ontology editor (or other tools for similar purposes). The specification of an ontology intent model starts with a TBox, which is a term box. TBox is a statement form used in a knowledge base to describe a domain of interest by defining concepts, attributes and their relationships as a domain vocabulary. TBox statements can be likened to object-oriented classes. Engineers instantiate the TBox in order to create an ABox for the specific use case at hand, where the ABox - the assertion component - describes an instance associated with a TBox element. ABox statements must be compatible with the TBox: they are assertions using the vocabulary defined by the TBox. Together, the ABox and TBox statements constitute a knowledge base or knowledge graph.

[0063] Figure 4 The diagram shows how to create Figure 2 or Figure 3 A non-limiting example of a subset of TBox 400 of an ontology intent model is shown.

[0064] By instantiating elements of the TBox 400, engineers are able to create an ABox that models the ontology's intent for the (specific / single) use case at hand.

[0065] Figure 5ABox 500 is illustrated as a non-limiting example of an intent model for the Oil and Gas Industry Use Case Example 1. Goal 1 "Achieve Oil and Gas Separation" is decomposed into two different goals: Goal 1.1 "Achieve Constant Pressure" and Goal 1.2 "Achieve High Gas Quality". In addition, Implementation 1 "Gas Outlet Pressure Control" satisfies Goal 1.1, but requires a "Pressure Controller" as specified in Requirement 1.

[0066] The present disclosure is based on the recognition that the manual process that engineers perform to define intent models using ontology editors often results in incorrect or incomplete specifications of ontology intent models. Knowledge may be forgotten, ambiguities or inconsistencies may arise, or errors may occur, especially as the model becomes more complex.

[0067] Therefore, the present disclosure proposes an intent-based engineering support system that uses the knowledge of the underlying ontology to help engineers specify a correct and complete ontology intent model.

[0068] Figure 6 The diagram illustrates an intent-based engineering support system 602 in context. The intent-based engineering support system 602 assists engineers in intent modeling, intent formalization, generation of abstract service and module representations, and output of specifications. Figure 6 In the non-limiting example shown, the intent-based engineering support system forms part of a larger process and automation engineering support system 600, providing further support services for use during one or more other phases of the plant life cycle (optionally including the operation phase). Specifically, the process and automation engineering support system 600 also includes a module pipeline generation system 604, which is configured to generate module pipelines using the specifications output by the intent-based engineering support system 602 to perform optimizations and parameter adjustments related to the module pipelines, and output specifications describing the plant topology. The process and automation engineering support system 600 also includes an orchestration design system 606, which is configured to perform processing and operational tasks related to the orchestration related to the plant topology received from the module pipeline generation system 604 to create control software instances and export these instances to the target control system of the automation system 100. The process and automation engineering support system 600 also includes a semantic simplification and integration layer 608, which is configured to provide a common domain vocabulary and concepts, a common knowledge graph, and a common API for the process engineering and automation engineering phases of plant design. The process and automation engineering support system 600 may also include an operations support system configured to support an operations team during an operations phase of the industrial automation system 100 .

[0069] The intent-based engineering support system 602 provides an ontology editor for creating, editing, and saving an ontology intent model using a user interface. The user interface in one example includes a graphical user interface (GUI). Additionally or alternatively, the user interface may include a natural language user interface (NLUI, such as using a ChatBot function) to enable more intuitive interaction with engineers, which may take the form of a guided conversation.

[0070] Returning to Example 1, the engineer uses the NLUI to input the intents, “I want to separate oil and gas” and “I want to achieve constant pressure”. The intent-based engineering support system 602 creates corresponding target elements, using ontology statements “separation of oil and gas”, “constant pressure” to represent these intents in the ontology intent model. The ontology statements can be set explicitly via the ontology editor (for example, by defining a set of triples: “concept node, attribute edge, concept node”), or implicitly through a temporary GUI or NLP conversion layer. Detail elements of arbitrary depth can be created in this way according to the wishes of the P&AE engineer.

[0071] At one or more points during specification of the ontology intent model, the intent-based engineering support system 602 is triggered to review the correctness and / or completeness of the model specified thus far and to provide assistance to the user as necessary.

[0072] The intent-based engineering support system 602 is configured to trigger the intent model validation algorithm in response to the absence of any user input within a predetermined time period. In this way, the intent-based engineering support system 602 can act immediately when the engineer stops inputting information. At this time, based on the ontology model, for example, if the engineer stops inputting information at the target statement level, the system 602 can prompt the engineer to input information that is missing so far in the specification of the intent model at the implementation statement level.

[0073] Additionally or alternatively, intent-based engineering support system 602 may be configured to occasionally or periodically trigger the intent model validation algorithm, for example to provide early detection of inconsistencies in information input via a user interface.

[0074] The intent model validation algorithm may be configured to perform validation of the correctness of a partial or full specification of the intent model. Additionally or alternatively, the intent model validation algorithm may be configured to perform validation of the integrity of the intent model specification.

[0075] Performing verification of correctness or completeness may include traversing a graph structure, such as a hierarchical tree structure, of the intent model specified so far to identify incorrect or incomplete information. Traversing the tree structure may include traversing all nodes. Traversing the tree structure may include breadth iterations and depth iterations over the nodes.

[0076] The intent model validation algorithm may include a rule-based or logic-based algorithm configured to identify incorrect or incomplete information. The rules or logic may be configured to identify incorrect or incomplete information based on one or more criteria that define a correct or complete ontology or other type of semantic information model. The criteria for defining a correct or complete ontology may be based on, for example, the TBox described herein. For example, the algorithm may be configured to identify incomplete information by identifying TBox elements that the engineer has not yet instantiated with data to create an ABox representation. For example, in the case where an engineer enters information that specifies a target statement for the intent model, the intent model validation algorithm may identify the lack of an implementation statement on the basis that the implementation elements of the TBox have not yet been instantiated.

[0077] After identifying incorrect or incomplete information, intent-based engineering support system 602 may be configured to prompt the engineer to take action, such as entering correct or complete information.

[0078] As described above, the user interface can include a GUI and / or a NLUI. In the latter case, returning to Example 1, the intent-based engineering support system 602 may prompt the engineer, for example, asking, "How do you want to achieve 'constant pressure'?", using appropriate relational fillers, "how" and "achieve". The engineer can then provide the requested information explicitly or implicitly, for example, by using the NLUI to enter the information, "I want to maintain a constant pressure at the gas outlet using a module with pressure control". In this way, the engineer is able to use the system 602 to enhance the triggered engineering intent representation to further complete it.

[0079] The intent-based engineering support system 602 may also include an automatic suggestion function that is configured to suggest information to be included in the intent model, such as correct or complete information that already exists in the intent model. The automatic suggestion function may be configured to use historical data to provide suggestions. The historical data may include previous intent models, whether in textual form or in ontological representation. More specifically, the historical data may include (carefully designed) examples of typical engineering intents expressed in textual form (e.g., "separate oil and gas", "optimize energy consumption", "maintain pressure", etc.), and / or use appropriate relevant ontological models (i.e., goals, implementations, requirements represented by domain-specific concepts, such as separators, tanks, reactors, pressure, etc.), or even already have specific module specifications (separator modules, reactionary modules, etc.). Based on the historical data, the system 602 is configured to suggest content that is suitable for the statement currently being edited or the next statement to be edited, such as by comparing the current situation with similar historical situations.

[0080] Therefore, in Example 1, in addition to prompting by asking the engineer "How do you want to achieve 'constant pressure'?", in the case where the target sentence is "I want to achieve constant pressure", the system 602 can suggest a module with pressure control at the gas outlet as the instantiation value of the implementation sentence based on similar situations and implementations found in historical data. The system 602 then outputs a prompt in the form of automatic suggestions, which in the case of NLUI can be: "Do you want to maintain constant pressure by using a module with pressure control at the gas outlet?", using appropriate relational filler words such as "achieve", "by", and the concept of "module with gas outlet pressure control".

[0081] The automatic suggestion function can be configured to filter the historical data to include only those entries that are populated by instance values ​​that are the same or similar to the current ABox. Based on the additional information in the historical instantiations, the algorithm is configured to suggest to the engineer of the current plant that the information that has been missing so far (e.g. at the demand level) can be filled by the instantiation data present in the historical data, such as the instance values ​​that occur most frequently in the (filtered) historical data. The automatic suggestion function can be configured to prompt the engineer to indicate the current plant context, and / or to indicate the plant context when making a suggestion, such as suggesting that for plants in a first field (e.g., pharmaceutical / chemical), a first instance value is found to occur most frequently, and for plants in a second field (e.g., oil and gas plants), a second instance value is found to occur most frequently in the historical data.

[0082] The intent-based engineering support system 602 may include a machine learning model trained to identify incorrect or incomplete information in the intent model. More specifically, the model may be trained to engage in a GUI or NLUI-based dialogue with an engineer to identify incorrect or incomplete information in the intent model and propose, extract, or further define an engineering representation.

[0083] Training models can use supervised learning and / or out-of-the-box instructions to tune LLMs (Large Language Models), followed by optional (domain-specific) fine-tuning based on training data containing one or more of the following:

[0084] - Ontology (ABox) representation of engineering intent formulas, such as Figure 5 As shown;

[0085] - Overall ontology domain model representation (complete TBox), partly as Figure 4 As shown;

[0086] - Prompts (in a format suitable for a graphical or natural language UI) to correct or complete an ontology (ABox) representation (given a complete TBox) (examples are provided in the example dialogue above).

[0087] In this way, the model can be trained to output prompts to enter correct or complete information, taking as input the engineering intent representation (ABox), while being trained to process the answer appropriately (i.e., the reward can be based on whether it is possible to enhance the ABox of the ontology representation). The training can further penalize the result with a penalty term when the concept and / or relationship does not exist in the entire ontology representation (TBox).

[0088] In cases where the user interface includes a NLUI, the intent-based engineering support system 602 may include a machine learning model (e.g., a large language model (LLM) with NLP question-answering capabilities, such as one of the many open source free commercial use out-of-the-box instruction-tuned LLMs (large language models), such as DOLLY) trained to conduct conversations with engineers.

[0089] While Example 1 described above relates to application of support system 602 during an engineering phase, it will be appreciated that the present disclosure is not so limited and support system 602 may additionally or alternatively find application during an operational phase, as will now be described with reference to Example 2.

[0090] In Example 2, the operator inputs the intent into the NLUI, “I want to maintain a constant oil level in the separator for the next 12 hours”, on which the intent representation is defined and mapped to an ontology statement (triplet concept / relation / concept set): “Oil and gas separation”; “constant level”; 12h. As mentioned above, this can be done by explicitly setting the ontology statement via the ontology editor (by defining a set of “concept node, attribute edge, concept node” triples), or implicitly via an ad hoc GUI or NLP transformation layer. This intent representation can be performed to an arbitrary depth of detail, depending on the amount of information input by the operator.

[0091] As described above, once the operator stops inputting information or observes that the input information is inconsistent (via the GUI / NLUI), the support system 602 triggers an action. At this point, based on the ontology model, for example, if the operator stops inputting information at the "target statement" level, the ontology can be used to determine whether the typical operating intention further requires an "achievement statement" (which has been missing so far). Now, using the NLUI, the ontology-driven support system 602 may ask the operator for further information about the intent specification: "How do you want to achieve 'constant level'?", plus appropriate relation fillers such as "how", "achieve". Alternatively, the GUI can be used to prompt the operator what is missing. The operator can again provide the requested information explicitly or implicitly (in the above manner): "I want to maintain a constant level using the level controller of the partition container xyz"; "I want to maintain a constant level by setting the corresponding level controller parameters"; "I want to switch the parameters back to the default values ​​after 12 hours". The support system 602 can then switch the level controller to the required mode and set the parameters accordingly to maintain a constant level during operation.

[0092] In summary, the present disclosure provides an ontology-driven intent-based engineering support system (optionally using a graphical or natural language user interface) that assists process and automation engineers in creating formalized representations of ontology engineering intent. Correctly formulated representations, in turn, have the effect of reducing or minimizing the occurrence of technical problems or failures during automation system commissioning and operation.

[0093] In the specific example disclosed herein, the system checks the ontology ABox representation of the current specific instance with the ontology overall TBox representation of the domain of interest, thereby combining and further supplementing the ontology ABox (concept instantiation) by checking where the TBox (abstract concepts and relationship / property descriptions) have not been instantiated. In addition, based on a machine learning model (e.g., based on a large language model (LLM) and NLP question-answering capabilities), the system can interact with engineers (e.g., through a graphical UI or through a natural language dialogue) to make suggestions (based on similar historical data) and expand / supplement the engineering intent representation.

[0094] Figure 7An exemplary computing system 800 that can be used in accordance with the systems and methods disclosed herein is illustrated. The computing system 800 can form or include a portion of any desktop, laptop, server, or cloud-based computing system. The computing system 800 includes at least one processor 802 that executes instructions stored in a memory 804. The instructions can be, for example, instructions for implementing functions described as being performed by one or more components described herein, or instructions for implementing one or more methods described herein. The processor 802 can access the memory 804 via a system bus 806. In addition to storing executable instructions, the memory 804 can also store session inputs, scores assigned to session inputs, and the like.

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

[0096] It is contemplated that external devices that communicate with the computing system 800 through the input interface 810 and the output interface 812 may be included in an environment that provides substantially any type of user interface with which a user may interact. Examples of user interface types include graphical user interfaces, natural user interfaces, and the like. For example, a graphical user interface may accept input from a user using an input device such as a keyboard, a mouse, a remote control, and provide output on an output device such as a display. In addition, a natural user interface may enable a user to interact with the computing system 800 in a manner that is not constrained by input devices such as a keyboard, a mouse, a remote control, and the like. In contrast, a natural user interface may rely on speech recognition, touch and stylus recognition, gesture recognition on and near the screen, gestures, head and eye tracking, voice and speech, vision, touch, gestures, machine intelligence, and the like.

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

[0098] The various functions described herein can be implemented in hardware, software, or any combination thereof. If implemented in software, these functions can be stored on a computer-readable medium or transmitted as one or more instructions or codes. Computer-readable media include computer-readable storage media. Computer-readable storage media can be any available storage medium that a computer can access. As an example and not limitation, such computer-readable storage media can include FLASH storage media, RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage or other magnetic storage devices, or any other medium that can be used to carry or store the required program code in the form of an instruction or data structure and can be accessed by a computer. Disks and optical disks used herein include optical disks (CDs), laser optical disks, optical disks, digital versatile disks (DVDs), floppy disks, and blue-ray disks (BDs), wherein disks usually copy data magnetically, and optical disks usually copy data optically with lasers. In addition, propagated signals can be included within the scope of computer-readable storage media. Computer-readable media also include communication media, including any media that facilitates the transfer of computer programs from one place to another. For example, a connection can be a communication medium. For example, if the software is transmitted from a website, server or other remote source via coaxial cable, fiber optic, twisted pair, digital subscriber line (DSL), or wireless technology such as infrared, radio, microwave, etc., then the definition of communications media includes coaxial cable, fiber optic, twisted pair, DSL, or wireless technology such as infrared, radio, microwave, etc. Combinations of the above should also be included within the scope of computer-readable media.

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

[0100] Applicants hereby disclose each individual feature described herein in isolation and any combination of two or more such features, as long as such features or combinations can be made according to the general knowledge of a person skilled in the art based on this specification as a whole, regardless of whether such features or combinations of features solve any problem disclosed herein, and are not limited to the scope of the claims. Applicants indicate that aspects of the present invention may consist of any such individual feature or combination of features.

[0101] It must be noted that embodiments of the present invention are described with reference to different categories. In particular, some examples are described with reference to methods, while other examples are described with reference to devices. However, a person skilled in the art will gather from the description that, unless otherwise notified, any combination of features belonging to one category is considered to be disclosed in this application. However, all functions can be combined to provide a synergistic effect greater than the simple sum of the functions.

[0102] Although the present invention has been described in detail in the drawings and the above description, such description and illustration should be considered as illustrative rather than restrictive. The present invention is not limited to the disclosed embodiments. Other variations of the disclosed embodiments can be understood and implemented by those skilled in the art through study of the drawings, the present disclosure and the appended claims.

[0103] The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

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

Claims

1. A support system for defining a model representing at least a portion of an industrial automation system, wherein the support system is configured to: obtaining a user-provided definition of at least a portion of the model; processing the user-provided definition to verify the correctness or completeness of the at least a portion of the model with reference to at least one knowledge base; as well as In response to determining that the user-provided definition includes incorrect or incomplete information, providing a system output, wherein the system output includes prompting a user to provide correct or complete information for inclusion in the definition of the at least a portion of the model. 2 . The support system of claim 1 , further configured to trigger the verification in response to an absence of any user input within a predetermined time period.

3. The support system according to claim 1 or 2, further configured to trigger the verification occasionally or periodically.

4. The support system according to any of the preceding claims, further configured to provide a user interface to enable the user to define the at least part of the intent model, wherein the user interface comprises a natural language user interface or a graphical user interface.

5. The support system according to any one of the preceding claims, further configured to execute an intention model validation algorithm for validating the correctness or completeness of the at least part of the intention model.

6. The support system of claim 5, wherein the intent model validation algorithm comprises traversing a graph structure of the at least a portion of the intent model to identify incorrect or incomplete information.

7. A support system according to claim 5 or 6, wherein the intent model validation algorithm is configured to identify incorrect or incomplete information by comparing an ABox representation of the intent model provided by the user with a TBox representation.

8. The support system according to any of the preceding claims, further configured to obtain supplementary input including the correct or complete information from the user, and to incorporate the supplementary information into the definition of the at least part of the intent model.

9. The support system according to any of the preceding claims, further comprising an automatic suggestion function configured to suggest information to be included in the definition of the at least part of the intent model.

10. The support system of claim 9, wherein the auto-suggest functionality is configured to use historical data to provide suggestions.

11. The support system of any of the preceding claims, further comprising a machine learning model trained to identify incorrect or incomplete information in the definition of at least a portion of the intent model.

12. The support system of any of the preceding claims, further comprising a machine learning model trained to converse with the user via a natural language user interface.

13. A method for defining a model representing at least a portion of an industrial automation system, the method comprising: obtaining a user-provided definition of at least a portion of the model; processing the user-provided definition to verify the correctness or completeness of the at least a portion of the model with reference to at least one knowledge base; as well as In response to determining that the user-provided definition includes incorrect or incomplete information, providing a system output, wherein the system output includes prompting a user to provide correct or complete information for inclusion in the definition of the at least a portion of the model.

14. A manufacturing method for an industrial automation system, the method comprising manufacturing at least a part of the industrial automation system according to the model defined using the supporting method according to claim 13.

15. An operating method for an industrial automation system, the method comprising operating at least a part of the industrial automation system to perform an industrial process according to the model defined using the supporting method according to claim 13.

Images