A method for generating a query pertaining to an industrial automation control system

Abstract

The present embodiments relate to a computer-implemented method for generating a query for querying an ontology pertaining to at least one component of an industrial automation control system, wherein the ontology may be a result of a transformation of a node set defined by a graph-based information model for industrial automation purposes. The present embodiments use known large language models or LLMs to generate queries. Although queries generated by generally known large language models may a prima vista appear appropriate in their structure, they are not correctly representing the domain-specific or industry-specific industrial contents and structure, which means the underlying industrial graph-based information model. The present embodiments therefore add one or more steps of preprocessing including a step for connecting entities included in a prompt to appropriate ontology elements thereby taking advantage of an OPC UA browse path in order to enable the large language models to generate correct a correct SPARQL query. In this way, the embodiments elevate the accuracy of generated SPARQL queries and makes them highly reliable to apply in production or industrial use cases.

Description

[0001] Description

[0002] A method for generating a query pertaining to an industrial automation control system

[0003] Technical Field

[0004] The disclosed embodiments generally relate to the field of industrial automation control systems. Specifically, the disclosed embodiments relate to a computer-implemented method for generating a query for querying an ontology pertaining to at least one component of an industrial automation control system.

[0005] Background Art

[0006] Industrial automation control systems are designed to capture real-world instrumentation data - e.g., sensor data - and actuate responses in real time, while operating reliably and safely. In recent times, semantic web technologies including a usage of semantic information models have gained a predominant role in specifying communicative and behavioral aspects of such components. Industrial automation standards such as OPC UA (Open Platform Communications Unified Architecture) enable semantic interoperability between industrial machines from diverse domains by providing information models. These information models may be defined in formats such as XML (Extensible Markup Language), a textual format that is both human-readable and machine-readable. The industrial automation standard OPC UA provides rich semantics defined by domain experts in terms of its information models.

[0007] Information modelling is a key concept in the quest to enable industrial automation control systems not only to deliver or consume data but also the express a meaning of data. Accordingly, semantic web formats such as RDF (Resource Description Framework), RDFS (RDF Schema), OWL (Web Ontology Language), SPARQL - a recursive acronym for SPARQL Protocol and RDF Query Language - etc. along with a large number of tools to efficiently create, store and query information models have been developed by semantic web communities. In the area of factory automation, OPC UA is one of the most important standards for device communication and promised to lift low-level signal exchange schemes onto a semantic level, contributing to the realization of flexible manufacturing scenarios.

[0008] Today the automation domain is faced with huge standardized OPC UA information models with detailed descriptions of the underlying physical automation devices. This introduces promising opportunities for a lot of use cases like analytics and human machine interfaces or HMI, which may be programmed against standardized information models, enabling the deployment on each machine independent of the manufacturer without major additional engineering effort.

[0009] One important part to use such information models is still underdeveloped. Without some kind of query functionality it will remain impossible to find necessary data points on the aggregating layers - edge or cloud layer - and bind them to applications such as a predictive maintenance application for an engine which of course needs some field values, like temperature, power et cetera. Although OPC UA itself offers a query language for querying in the graph of the OPC UA information model, this OPC UA specific query language has turned out as an impractical solution as it requires to search the graph node by node for each application. One major reason of this impracticability is that ten-thousands of OPC UA nodes on a cloud level may have to be queried by hundreds of applications in parallel.

[0010] Another problem is that the OPC UA specific query language is so complex that engineers have even designed an internal domain-specific language for constructing OPC UA Queries. Rather than inventing a new query language from scratch or directly implementing OPC UA Query, other query languages with already existing implementations have been applied, whereby SPARQL turned out to be the most suitable query language. Accordingly, one preferred method of choice is to create a sematic artifact - i.e. a machine-actionable formalization of a conceptualization, enabling sharing and reuse by humans and machines - such as an ontology from an OPC information model. Or, in other words, at least parts of an OPC UA information model or a nodeset defined by a OPC UA information model are beneficially transformed into an ontology representation of which may then queried using SPARQL.

[0011] Querying a transformed ontology - i.e., an ontology being a result of a transformation of a nodeset defined by a graph-based OPC UA information model - is still challenging because an engineer formulating the query has to be both a semantic expert to formulate the SPARQL query and an OPC UA expert to understand the semantics defined in the OPC UA nodeset. Although accessing a node under consideration (e.g., for determining parameters or components assigned to said node under consideration) using the transformed ontology is much faster than accessing the node under consideration in the underlying graph-based OPC UA information model, a formulation of a query for parsing the specific node under consideration remains intricate, because the query structure to parse the node under consideration has to describe the path across the entire node hierarchy.

[0012] As a primary contribution, the Applicant of the present Application has disclosed a method of generating a query pertaining to an industrial automation control system as described in an International Patent Application WO2023 / 232964 being incorporated herein by reference in its entirety. Still today, however, it is a very challenging task to query meaningful information or live data from industrial machines based on the standardized semantics defined in an OPC UA information model and its industrial use case appendices being captioned as OPC UA companion specifications. In summary, it is both intricate to create the OPC UA information models and it also highly complex to retrieve information from them.

[0013] Accordingly, there is a need in the art for a computer-implemented or at least computer- assisted method for generating a query for querying a representation of an ontology based on an OPC UA information model.

[0014] Summary of the Invention

[0015] The present invention relates to a computer-implemented method for generating a query for querying an ontology pertaining to at least one component of an industrial automation control system, wherein the ontology may be a result of a transformation of a nodeset defined by a graph-based information model for industrial automation purposes. The method includes the steps of: receiving a first representation of at least one domain ontology by a large language model chatbot; receiving, by a prompt preprocessing module, at least one prompt including natural language instructions outlining an expected return of the query, retrieving, by the prompt preprocessing module, at least one entity within the prompt and classify the at least one entity by at least one concept of the at least one domain ontology, associating, by the prompt preprocessing module, the at least one classified entity within the prompt with at least one concept to generate a preprocessed prompt, outputting, by the prompt preprocessing module, at least one preprocessed prompt enriched with associations to at least one concept of the at least one domain ontology; obtaining, by a knowledge graph preprocessing module, a second representation of said at least one domain ontology, the second representation comprising a graph-based information model being expressed by a Resource Description Framework (RDF) format, determining, by the knowledge graph preprocessing module, at least one browse path for at least one node in in the graph-based information model, said at least one node being in conformance with at least one classified entity, outputing, by the knowledge graph preprocessing module, the at least one browse path; receiving, by the large language model, the at least one preprocessed prompt and the at least one browse path and generating the at least one query, structuring the at least one query by a semantic query language.

[0016] The present invention further relates to an engineering computing system for generating a query pertaining to at least one component of an industrial automation control system, the engineering computing system comprising: a memory having a plurality of application modules stored thereon; and; a processor for executing the application modules, the application modules comprising: a large language model chatbot configured to receive a first representation of at least one domain ontology; a prompt preprocessing module coupled to the large language model chatbot, the prompt preprocessing module configured to: receive at least one prompt including one or more natural language instructions outlining an expected return of the query; retrieve at least one entity within the prompt and classify the at least one entity by at least one concept of the at least one domain ontology, associate the at least one classified entity within the prompt with at least one concept to generate a preprocessed prompt, output at least one preprocessed prompt enriched with associations to at least one concept of the at least one domain ontology; a knowledge graph preprocessing module coupled to the large language model chatbot, the knowledge graph preprocessing module configured to: obtain a second representation of said at least one domain ontology, the second representation comprising a graph-based information model being expressed by a Resource Description Framework (RDF) format, determine at least one browse path for at least one node in in the graphbased information model, said at least one node being in conformance with at least one classified entity, output the at least one browse path; the large language model chatbot configured to receive the at least one preprocessed prompt and the at least one browse path and to generate the at least one query structuring the at least one query by a semantic query language.

[0017] The present embodiments for querying a representation of an ontology based on an OPC UA information model are characterized by a high syntactical and structural accuracy for generating the formal query. Accuracy is particularly crucial for the intended industrial use cases as they will be related to production. The generated queries are advantageously correct and accurate, and they retrieve the industrial information correctly.

[0018] Brief Description of the Drawing

[0019] The objects as well as further advantages of the present invention will become more apparent and readily appreciated from the following description of the preferred embodiments, taken in conjunction with the accompanying drawing accompanying drawing of which:

[0020] FIG. 1 : is a process diagram illustrating a generation of a query according to an embodiment; and;

[0021] FIG. 2: is a schematic representation of a graph-based hierarchical node set.

[0022] Description of Examples

[0023] Until today formulating a search query for querying a representation of an ontology has to be solved manually, where experts skilled in both, Semantic Web technologies and OPC UA information models, manually formulate the SPARQL queries, which is a tedious and time taking task. The ontology may be loaded in a triple store supporting a maximum query efficiency. The ontology may be provided in an RDF (Resource Description Framework) representation as directed graph composed of triple statements, which may be provided in a serialized data format such as RDF / XML and XML-based (Extended Markup Language) syntax that was the first standard format for serializing RDF or RDF / JSON, an alternative syntax for expressing RDF triples using a simple JSON (JavaScript Object Notation) notation. The ontology may be provided in an OWL (Web Ontology Language) representation.

[0024] Serialization is understood as a process of translating the data structure of an ontology - or its object state - into a format which may be stored - e.g. as a file in a storage device or in a data buffer in in a cache - or transmitted - e.g. as a data stream over computer networks) and reconstructed later (possibly in a different computer environment).

[0025] About one hundred and twenty OPC UA companion specifications currently exist and more OPC UA companion specifications are currently under development. There are already thousands of devices using the OPC UA standard. Given these figures, it seems neither feasible nor scalable to maintain the present practice of manually formulating SPARQL queries. Embodiments disclosed herein are aiming to automate formulating theses queries from OPC UA information model in general or, specifically from OPC UA companion specifications.

[0026] Throughout this description, compound names with one or more medial capitals - e.g., the compound name »BrowsePath« as introduced below - are used to refer to authoritative names used in the specification »OPC Unified Architecture® of the OPC Foundation. These authoritative names are assumed to be known and for a person skilled in the art. Hereinafter, these authoritative names are, therefore, introduced without explanation.

[0027] An important aspect of the present embodiments is a usage of a browse path - or »BrowsePath« in OPC conventions - of one or more nodes defined by the OPC Foundation or a companion specification. The following section illustrates the browse path or BrowsePath® concept. A BrowsePath defines a path from a root node of an OPC UA nodeset to a node under consideration. Accordingly, the BrowsePath is an ordered set of nodes referenced from a root node to the current node under consideration.

[0028] FIG. 2 shows a graphical representation of a graph-based hierarchical node set. Specially, a part of a robot model defined in OPC UA companion specification for robotics is depicted. Essentially rectangular shaped objects as shown in FIG. 2 form a respective node. Two or more nodes connected by a line as shown in the drawing form an ordered hierarchy, with an exemplary BrowsePath passing along multiple line-connected nodes. A root of the robotics model is a MotionDeviceType which has a component called Axes being a container for representing one or more of each axis of a robot. A query must follow this path defined in the companion specification in order to retrieve the information about axes of a robot. However, in the query generated by a large language model this is not correct as the large language model lacks the knowledge about the path definition. It would be, therefore, desirable to enable the large language model to use correct paths as defined the ontology then query generation can be significantly improved.

[0029] The root node named »MotionDeviceType« may be defined by an OPC UA companion specification for robotics. Such OPC UA companion specifications are defined or at least published by the OPC foundation.

[0030] The SPARQL query is not imposed to the genuine OPC UA information model but to a transformation of the OPC UA information mode into a formal semantic representation of an ontology, e.g., an OWL ontology. The ontology itself may be loaded in a triple store supporting a maximum query efficiency.

[0031] Regardless of this transformation, the initial graph based structure of the original OPC UA nodeset structure, however, remains in the structure of the transformed ontology, in that the ordered nodes along the browse path are modelled by instantiating respective OWL restrictions of a respective OWL class. A code snippet appended at the end of this description shows excerpts of a possible source code of the transformed ontology - transformation of the OPC UA information mode into a formal ontology representation - written in OWL.

[0032] In order to create a SPARQL query for querying the node under consideration named »ActualPosition« within the ontology, the SPARQL query needs to describe the path to that node. Once the path to the node under consideration is generated, information about the references, attributes of the node can be easily retrieved, or filters or aggregate functions can be applied on the node. In this way, any node (e.g., ObjectType, VariableType, Variable, Object, Method etc.) can be accessed using an automated generated SPARQL query and its attributes, references and current values can be retrieved using the queries.

[0033] With the latest advancements in generative artificial intelligence, or Al, a general task of formulating a query may be approached in an apparently efficient and time-saving manner. Generative artificial intelligence methods using large language models or LLMs may aid a process of optimizing a query generation process using instructions issued by a domain expert in the generation process. Although large language models already contribute to authoring longer lines of code in a selectable programming language along with subsequent options of revising, amending and verifying the artificially generated code after a first attempt - i.e. first output of the large language model - a generation or synthesis of a formal query pertaining to an industrial automation control system encounters inherent problems, which are shown below using an example.

[0034] A »regular« - or default-deployed - large language model instructed to output a SPARQL query for returning a count of all axes of a robot as specified in an OPC UA robotics specification, thereby using an OPC UA robotics companion specification - which will be discussed further in the description of Figure 2 below - may return a query as follows:

[0035] 1. PREFIX opc: <http: / / your-opc-ua-ontology-namespace#>

[0036] 2. SELECT ?axisCount

[0037] 3. WHERE {

[0038] 4. ?robot opc:hasAxis ?axis.

[0039] 5. BIND (COUNT(?axis) AS TaxisCount)

[0040] 6. }

[0041] The instruction which has returned the resulting query as shown above may have been formulated in the form of a natural language, whereby a natural language prompt may also be referred to as an NLQ or Natural Language Query. One possible prompt or Natural Language Query or prompt may be an instruction as follows: »Get the count of axis of the robot« or, more specifically: »Generate a SPARQL query based on OPC UA robotics specification for the following sentence: 'Get the count of axis of a robot*«.

[0042] The resulting query as shown above is formally wrong, or wrongly generated by the large language model in that it does not consider the complexity and particularity of the underlying OPC UA ontology, or more specifically, of the ontology which has been built upon an OPC UA information model. Accordingly, the query as depicted above would return an incorrect result. However, it is worth understanding which aspects have led to an incorrect result.

[0043] In this simple example as shown above, lines 1 and 4 are domain specific parts - i.e. pertaining to a specific domain of an OPC UA information model being a basis of the ontology to be queried - while lines 2, 3, 5 and 6 are domain agnostic parts. Domain agnostic hereby means, that lines 2, 3, 5 and 6 are syntactically correct SPARQL instructions instructing general SPARQL operations without a specific reference to the OPC UA information model underlying the domain ontology to be queried.

[0044] In summary, the large language model may be able to generate a SPARQL query for domain agnostic parts accurately, but domain specific parts are not correctly generated. The following domain specific parts needs to be corrected in the generated query as shown above:

[0045] Prefix in line 1 : The prefix generated in the query is not a correct prefix of the OPC UA robotics specification.

[0046] Path to ?robot in line 4: The path to the root element ?robot is not correct as per OPC UA robotics specification.

[0047] Path to ?axis in line 4: the path to axis element is also wrong and needs to be corrected.

[0048] Relationship opc:hasAxis in line 4: Is not defined in the OPC UA robotics specification and needs to be corrected.

[0049] It is an object of the invention to address the present inaccuracies associated with a usage of regular large language models and to enable an engineering computing system for generating a query pertaining to at least one component of an industrial automation control system to correctly generate queries for domain specific use cases.

[0050] FIG. 1 shows an engineering computing system for generating a query GQY pertaining to at least one component of an industrial automation control system, the engineering computing system comprising a memory having a plurality of application modules PPP, GPP, LLM stored thereon, and a processor - not shown in the drawing - for executing the application modules PPP, GPP, LLM. The application modules PPP, GPP, LLM may comprise a large language model chatbot LLM configured to receive a first representation of at least one domain ontology ONT, a prompt preprocessing module PPP and a knowledge graph preprocessing module GPP both of which may be at least temporarily coupled to the large language model chatbot LLM.

[0051] The prompt preprocessing module PPP may be configured to receive at least one prompt NLQ including one or more natural language instructions outlining an expected return of the query. The prompt preprocessing module PPP may be configured to retrieve or to extract at least one entity within the prompt NLQ or, in other words, to extract entity names ENN from the prompt NLQ. This retrieval - step 102 as shown in the drawing - may result in a collection of entity names ENN which may then, in a subsequent step 104, be classified by at least one concept of at least one underlying domain ontology to obtain at least on ontology entity OEN. Ontology entities OEN classified within the prompt NLQ may be associated with at least one concept of the domain ontology in order to generate a preprocessed prompt PPQ. The preprocessed prompt PPQ may be enriched with associations to at least one concept of the at least one domain ontology and output as an input to the large language model chatbot LLM.

[0052] The knowledge graph preprocessing module GPP coupled to the large language model chatbot LLM may be configured to obtain - i.e. to receive or to generate - a second representation of the at least one domain ontology, the second representation comprising a knowledge graph KNG or, more generally, a graph-based information model being expressed by a Resource Description Framework or RDF format. The knowledge graph preprocessing module GPP may be configured to determine at least one browse path for at least one node in in the graph-based information model - corresponding with an entity name EN N and / or an ontology entity OEN of the domain ontology - and to output the at least one browse path as an input to the large language model chatbot LLM. The knowledge graph preprocessing module GPP may be further configured to infer at least one relation and to output one or more relations as an input to the large language model chatbot LLM.

[0053] The knowledge graph preprocessing module GPP may further, alternatively or additionally, be configured to use the knowledge graph KNG for preparing a preprocessed knowledge graph PKN by applying a preparation step 106 including an act of simplifying axioms of the ontology underlying the knowledge graph PKN. The previously described steps for determining a browse path and inferring at least one relation may also be automated inserting queries to simplify OWL axioms in the knowledge graph KNG for preparing the preprocessed knowledge graph PKN. The queries may include one or more of the following three queries in a code snippet as listed below.

[0054] Queryl :

[0055] INSERT { ? s ?p ?o} WHERE {

[0056] ?s rdf s : subClassOf ?r .

[0057] ?r rdf : type owl : Restriction .

[0058] ?r owl : allValuesFrom ?o .

[0059] ?r owl : onProperty ?p . }

[0060] Query2 :

[0061] INSERT { ? s ?p ?o} WHERE {

[0062] ?s rdf s : subClassOf ?r .

[0063] ?r rdf : type owl : Restriction .

[0064] ?r owl : onProperty ?p .

[0065] ?r owl : hasValue ?o .

[0066] }

[0067] Query3 :

[0068] INSERT { ? s ?p ?o} WHERE {

[0069] ?s rdf s : subClassOf ?r .

[0070] ?r rdf : type owl : Restriction .

[0071] ?r owl : minQuali f iedCardinal ity ?t .

[0072] ?r owl : onProperty ?p .

[0073] ?r owl : onClass ?o .

[0074] }

[0075] The large language model chatbot LLM may be configured to receive the at least one preprocessed prompt PPQ and the at least one browse path and / or preprocessed knowledge graph PKN to generate the at least one query GQY structuring the at least one query by a semantic query language, preferably SPARQL.

[0076] According to an embodiment, an approach for preprocessing and / or training an LLM is disclosed in order to empower the large language model chatbot LLM to generate accurate domain-specific queries. In FIG. 1 , exemplary embodiments with additional functional units or modules are shown. Further optional preprocessing modules and / or method steps may be exchanged or added to improve the accuracy of query generation. Some method steps are described in the following.

[0077] Several OPC UA ontologies may exist in a knowledge graph. Therefore, it may be difficult for a general large language model to correctly identify a required ontology element and generate the query accordingly. An primary step of linking key entities from the NLQ to the entities defined in the ontology may be beneficial to improve the query generation process. Subsequently the NLQ and said key entities may be given as input to a query generation by the LLM. These steps - or sub-tasks in the following - may be referred to as Named Entity Recognition or NER, Named Entity Disambiguation or NED, and Entity Linking or EL. These sub-tasks are determined by gradually identifying the inputs and outputs. They are briefly described in the following:

[0078] A first sub-task is to extract pertinent words and phrases from sentences of the N LQ and prepare them as query parameters for a further usage. The process of extracting pertinent entities from sentences is referred to as NER or Named Entity Recognition. Named Entity Recognition is a subtask within the process of information extraction for identifying and classifying named entities of the text into predefined categories such as person names, organizations, locations, medical codes, time expressions, quantities, monetary values, percentages, etc. Named Entity Recognition plays a crucial role in various natural language processing applications, including question answering, machine translation, text summarization, sentiment analysis, and more. For the present embodiment, numerous domain specific terms and phrases may be used as key entities.

[0079] After obtaining the entities, the next step may be a determination which element in the ontology they represent. Such a determination may not always be straightforwardly or unambiguously achieved through direct matching. For instance, in an ontology, the term »MachineVisionType« may directly correspond to an entity designated »MachineVisionType« in a companion specification document. However, variations such as » Machinevision type®, »MachineVisionTypes«, or smachine vision type« may also represent the same concept. Another problematic example is that keywords such as »include« and »contain« may represent a relationship between entities, which could be formally defined in an ontology with keywords such as »HasProperty«, »HasComponent« etc.

[0080] In order to resolve complexities as mentioned above, sub-tasks of a Named Entity Disambiguation (NED) and Entity Linking (EL) may be implemented. Named Entity Disambiguation may be used to accurately identify and disambiguate entities in a text. It may involve analyzing context, relationships with other entities, and information in the ontology in order to determine an appropriate representation for each entity. Entity Linking (EL) may be used for linking entities in a text to relevant concepts in an ontology. Using these sub-traks, key entities in a natural language sentence may be linked to entities formally defined in an ontology. This step may turn out crucial in formal query generation for domain-specific use cases. According to an embodiment, an approach for preprocessing and / or training an LLM is disclosed in order to empower the large language model chatbot LLM to generate more accurate domain-specific queries at the first time. According to this embodiment a preprocessing step is provided which may generate a path to each entity in the ontology and relationships between the entities prior to receiving a respective preprocessed prompt or, alternatively or additionally, before starting the regular operation of the large language model chatbot and its environment, the application modules. The later step of initially preparing the large language model for a regular operation is also known as training of the large language model. The large language model may then accurately generate the paths and relationships. An exemplary ontology used for experiments of the inventors is inlucded at the end of this description. Sample paths and relationships generated by the large language model are based on said exemplary ontology. Said paths and relationships may again be fed as inputs to the large language model chatbot LLM in addition to the ontology ONT.

[0081] In the following, an exemplary prompt is shown for a training ad / or preprocessing - both of which may be distinctive - the large language model chatbot LLM: by using this ontology: { schema }

[0082] 1. first generate the paths and relations.

[0083] 2. create a mapping between labels and nodelds of entities in the given ontology, when user gives a query with label then replace it with nodeld and generate the SPARQL query using the nodelD.

[0084] Then generate sparql query using those paths, relations and the mapping between labels and nodelds { prompt } Instructions :

[0085] Define all the necessary prefix fully and use only those prefix in the query, use precise prefix while generating SPARQL query, do not give multiple options for prefixes in the use hasProperty relation while generating the SPARQL query to get to a variable node. use hasComponent relation while generating the SPARQL query to get to an object node . always useAAxsd: string for labels and add xsd prefix to the generated query.

[0086] According an embodiment, two instructions or preprocessing steps may be added to a preprocessed prompt PPQ as shown above - or having been trained in advance - regarding a handling of two relations captioned »hasComponent« and »hasProperty«. This has the following background: In OPC UA there are mainly two types of relations between entities: A relation captioned »hasComponent« refers from an Object node to another Object node and a relation captioned »hasProperty« refers from an Object node to a variable node. As regular large language models may not use these OPC UA relationships correctly in order to generate the formal SPARQL query GQY, an additional instruction or preprocessing operation on how to make use of these domain specific information is advantageous. The »hasProperty« relation may be used while generating a SPARQL query GQY for retrieving a variable node, the »hasComponent« relation may be used while generating a SPARQL query GQY for retrieving an object node.***

[0087] An exemplary sample of generated paths and relationships which has been generated from a sample ontology based on Robotics companion specification is included at the end of this description.

[0088] Accuracy is crucial in industrial use cases as they will be related to production. The generated queries should be correct and accurate, and they should retrieve the information required for the user correctly. Our approach takes advantage of large language models to generate queries. However, the queries generated by them have a basic structure but for domain specific / industry specific use cases they are not correct. We train the LLMs with our domain know-how, connect the natural language entities from the query to appropriate ontology elements, we take advantage of OPC UA browse path to support LLMs to generate correct SPARQL query from the NLQ. In this way, our approach elevates the accuracy of generated SPARQL queries and makes them highly reliable to apply in production or industrial use cases.

[0089] A code snippet below shows excerpts of a possible source code of the transformed ontology, i.e. a transformation of the OPC UA information mode into a formal ontology representation written in OWL used as an exemplary ontology by the inventors:

[0090] ©pref ix owl : <http : / / www . w3 . org / 2002 / 07 / owl #> . ©prefix NS3: ehttp : / / example . kuka . robot / >

[0091] ©prefix opcua: ehttp: / / opcf oundation.org / UA /

[0092] NS 2 : MotionDeviceSystemType a owl: Class ; rdf s : comment "Contains the set of controllers and motion devices in a closely-coupled motion device system." ; rdfs: label "MotionDeviceSystemType" ; rdf s : subClassOf NS1 : ComponentType .

[0093] Snbsp ; ehttp: / / example .kuka .robot / iSOOlu a me: Object , NS2 : MotionDeviceSystemType ; rdfs: label "KUKABfr" ; ia : browseName "http : / / example , kuka . robot / KUKABf r "AAxsd : anyURI ;

[0094] NSO : hasComponent ehttp : / / example . kuka . robot / 15003> , ehttp : / / example . kuka . robot / 15002 > , ehttp : / / example . kuka . robot / 15004 > . ehttp : / / example .kuka . robot / i5003> a merObject , NSO : FolderType ; rdfs : label "MotionDevices" ; ia : accessRestrictions " 0 "A Axsd : unsignedShort ; ia: browseName ehttp : / / example .kuka .robot / 15006> a NS2 : MotionDeviceType , me: Object ■ rdfs: label "MotionDevice_l " ; i a : b r ow s e Nam e ehttp : / / example .kuka . robot / i5013 > a NSO : FolderType , me: Object ; rdfs : label "PowerTrains" ; ia : accessRestriCtioris " 0 "A Axsd : unsignedShort ; ia throws eName chttp : / / example .kuka . robot / T50170 > a NS2 :AxisType , me::Object ; r d f s : 1 ab e 1 " Ax i s_2 " ; chttp : / / example . kuka . robc>t / parameterSet> chttp : / / example . kuka . robot / 150200 > ; ta: isObject true ;

[0095] NS 2 : actual Posit ion chttp : / / example . kuka . robot / 16029 > ; NS0 : hasComponent chttp : / / example . kuka . robot / 16029 > ta: isObject true ;

[0096] NS 2 : actual Posit ion chttp : / / example . kuka . robot / 160290 > ;

[0097] NS0 : has Component chttp : / / example . kuka . robot / i 60290 > .

[0098] NS3: 15004 NS2 : cPUFanSpeed NS2 : 117371 ;

[0099] NS 2 : cabinet FanSpeed NS2 : 117365 ;

[0100] NS2 : inputVol tags NS2 : 117377 ;

[0101] NS2 : startUpTime NS2: 115366 ;

[0102] NS2 : temperature NS2 : 117383 ;

[0103] NS2 : totalEnergyConsumptioh NS2 : 117359 ;

[0104] NS2 : totalPowerOnTime NS2 : 117358 ;

[0105] NS2 ■ upsState NS2:115365 ; opcua : hasTypeDef ini t ion opcua : BaseOb j ectType chttp : / / example . kuka .robot / i 6029> a NSO : AnalogUnitType , me: Variable ; rdf s : comment "The axis position inclusive Unit and

[0106] RangeOf Motion ; rdf s : label " Actual Posit ion" ; ia : accessLevel " 3 "AAxsd : unsignedlnt ; ia : accessLevelEx " 3 "AAxsd : unsignedlnt ; ia : accessRestrictions " 0 "A Axsd lUnsignedShort ; ia : browseName ia: nodeClass "2"AAxsd:int ; t a : i s I n s t an c e D e c 1 a r a t i on false ; ta: isVariable true ;

[0107] NSO : engineeringunits ehttp: / / example . kuka . robot / 16034 > ;

[0108] NSO : hasProperty ehttp : / / example . kuka . robot / 16034 > . chttp : / / example . kuka .robot / i 60290 > a NSO : AnalogUnitType , me: Variable ; rdfsicomment "The axis position inclusive Unit and

[0109] RangeOf Motion . " ; rdfs: label "ActualPosition" ; ia : writeMask " 0 "AAxsd : unsignedlnt ta: i slnstanceDeclaration false ; ta : invariable true ;

[0110] NSO : engineeringunits ehttp : / / example . kuka . robot / i 6034 > ;

[0111] NSO : has Property ehttp : / / example . kuka .robot / 16034 > .

[0112] An exemplary sample below shows a collection paths and relationships which has been generated from a sample ontology based on Robotics companion specification: 1. KUKABfr (http : / / example . kuka . robot / 15001 ) is a MotionDeviceSystemType and has components : o MotionDe vices (http : / / example . kuka . robot / 15003 ) o Unknown components

[0113] (http : / / example . kuka . robot / 15002 , http : / / example . kuka . robot / 15004:)

[0114] 2. MotionDevices (http : / / example . kuka .robot / 15003 ) is a FolderType and has a component : o MotionDevice_l (http : / / example . kuka . robot / 15006 )

[0115] 3. MotionDevice_l (http : / / example . kuka .robot / 15006 ) is a MotionDeviceType and has components : o PowerTrains (http: / / example . kuka .robot / 15013 )

[0116] O Unknown components

[0117] (http: / / example .kuka . robot / 15011 , http: / / example . kuka .robot / 15012 )

[0118] 4. PowerTrains (http : / / example . kuka . robot / 15013 ) is a FolderType and has a component : o PowerTrain_ 1 (http : / / example .kuka .robot / 15018 )

[0119] 5. PowerTrain_l (http : / / example , kuka . robot / 15018 ) is a PowerTrainType and moves : o Axis_l (http : / / example . kuka . robot / 15017) o Axis_2 (http : / / example . kuka .robot / 150170 )

[0120] 6. Axis_ 1 (http : / / example . kuka . robot / 15017 ) is an AxisType .and has a parameter set: o Parameterset (http : / / example .kuka .robot / i5020 )

[0121] 7. Axis_2 (http : / / example .kuka .robot / 150170 ) is an AxisType and has a parameter set : o ParameterSet (http : / / example .kuka .robot / 150200 )

[0122] 8. ParameterSet (http : / / example .kuka . robot / 15020) is a BaseObj ectType and has a component : o ActualPosition (http : / / example . kuka . robot / 16029)

[0123] 9. ParameterSet (http : / / example .kuka . robot / 150200 ) is a BaseObj ectType and has a component : o ActualPosition (http : / / example . kuka . robot / 160290)

[0124] 10. ActualPosition (http : / / example . kuka . robot / 16029 ) is an AnalogUnitType and has a property:

[0125] Unknown property (http : / / example .kuka .robot / 16034) 11 . Actualposition (http : / / example . kuka . robot / i 60290 ) is an AjaalogUni tType and has a property : o Unknown property (http : / / exampl e . kuka . robot / 16034 )

[0126] 12 . Unknown obj ect (http : / / example . kuka . robot / i5004 ) has various properti e s related to CPU f an speed , cabinet f an speed , input voltage , start -up time , temperature , total energy consumpt ion , total power-on time , and UPS state .

[0127] The present embodiments use known large language models to generate queries. Although queries generated by generally known large language models may a prima vista appear appropriate in their structure, they are not correctly representing the domain-specific or industry-specific industrial contents and structure, which means the underlying industrial graph-based information model. The present embodiments therefore add one or more steps of preprocessing including a step for connecting entities included in a prompt to appropriate ontology elements thereby taking advantage of an OPC UA browse path in order to enable the large language models to generate correct a correct SPARQL query. In this way, the embodiments elevate the accuracy of generated SPARQL queries and makes them highly reliable to apply in production or industrial use cases.

[0128] It is to be understood that the elements and features recited in the appended claims may be combined in different ways to produce new claims that likewise fall within the scope of the present invention. Thus, whereas the dependent claims appended below depend from only a single independent or dependent claim, it is to be understood that these dependent claims can, alternatively, be made to depend in the alternative from any preceding or following claim, whether independent or dependent, and that such new combinations are to be understood as forming a part of the present specification.

[0129] While the present invention has been described above by reference to various embodiments, it should be understood that many changes and modifications can be made to the described embodiments. It is therefore intended that the foregoing description be regarded as illustrative rather than limiting, and that it be understood that all equivalents and / or combinations of embodiments are intended to be included in this description.

Claims

Claims1 . An engineering computing system for generating a query pertaining to at least one component of an industrial automation control system, the engineering computing system comprising: a memory having a plurality of application modules stored thereon; and; a processor for executing the application modules, the application modules comprising: a large language model chatbot configured to receive a first representation of at least one domain ontology; a prompt preprocessing module coupled to the large language model chatbot, the prompt preprocessing module configured to: receive at least one prompt including one or more natural language instructions outlining an expected return of the query; retrieve at least one entity within the prompt and classify the at least one entity by at least one concept of the at least one domain ontology, associate the at least one classified entity within the prompt with at least one concept to generate a preprocessed prompt, output at least one preprocessed prompt enriched with associations to at least one concept of the at least one domain ontology; a knowledge graph preprocessing module coupled to the large language model chatbot, the knowledge graph preprocessing module configured to: obtain a second representation of said at least one domain ontology, the second representation comprising a graph-based information model being expressed by a Resource Description Framework (RDF) format, determine at least one browse path for at least one node in in the graphbased information model, said at least one node being in conformance with at least one classified entity, output the at least one browse path; the large language model chatbot configured to receive the at least one preprocessed prompt and the at least one browse path and to generate the at least one query structuring the at least one query by a semantic query language.

2. The engineering computing system according to claim 1 , wherein the prompt preprocessing module and the knowledge graph preprocessing module are embodied by the same application module.

3. The engineering computing system according to claim 2, the prompt preprocessing module and the knowledge graph preprocessing module being temporarily embodied in the large language model chatbot in order to sequentially or parallelly execute prompt preprocessing operations and knowledge graph preprocessing operations while saving their respective outputs by the large language model chatbot to conclude generation of the at least one query in a formal query language.

4. The engineering computing system according to claim 3, wherein the outputs of the prompt preprocessing module and the knowledge graph preprocessing module are saved for training at least one large language model inside or outside the engineering computing system.

5. The engineering computing system according to one of the preceding claims, wherein the knowledge graph preprocessing module being configured to obtain the second representation of the least one domain ontology includes a configuration to receive and / or generate the second representation of the at least one domain ontology.

6. The engineering computing system according to one of the preceding claims, wherein the domain ontology is at least partially a result of a transformation of a nodeset defined by a graph-based information model for industrial automation purposes.

7. The engineering computing system according to one of the preceding claims, wherein the industrial automation control system is an automation control server.

8. The engineering computing system according to one of the preceding claims, wherein the at least one component of the industrial automation control system is an industrial device.

9. The method according to claim 1 , wherein the graph-based information model is a central or decentral data base for hosting knowledge artefacts, in particular knowledge artefacts known as digital twins.

10. A method for generating a query pertaining to at least one component of an industrial automation control system, the method comprising the steps of: receiving a first representation of at least one domain ontology by a large language model chatbot;receiving, by a prompt preprocessing module, at least one prompt including natural language instructions outlining an expected return of the query, retrieving, by the prompt preprocessing module, at least one entity within the prompt and classify the at least one entity by at least one concept of the at least one domain ontology, associating, by the prompt preprocessing module, the at least one classified entity within the prompt with at least one concept to generate a preprocessed prompt, outputing, by the prompt preprocessing module, at least one preprocessed prompt enriched with associations to at least one concept of the at least one domain ontology; obtaining, by a knowledge graph preprocessing module, a second representation of said at least one domain ontology, the second representation comprising a graph-based information model being expressed by a Resource Description Framework (RDF) format, determining, by the knowledge graph preprocessing module, at least one browse path for at least one node in in the graph-based information model, said at least one node being in conformance with at least one classified entity, outputing, by the knowledge graph preprocessing module, the at least one browse path; receiving, by the large language model, the at least one preprocessed prompt and the at least one browse path and generating the at least one query, structuring the at least one query by a semantic query language.11 . The method according to claim 10, wherein the information model is a central or decentral data base for hosting knowledge artefacts, in particular knowledge artefacts known as digital twins.

Images