Method and system for root-cause analysis using ontological knowledge graph

Abstract

system (200) and method (100) for performing root-cause analysis of an anomalous behaviour in an asset are disclosed. The method comprises implementing, by a processor (204), a knowledge graph (600) comprising at least one of simulation data from a design phase of the asset and diagnosis data for past anomalous behaviour(s) of the asset, in form of verification requests. The method further comprises configuring, by the processor, an user-interface to receive an input indicative of symptoms related to the anomalous behaviour in the asset. The method further comprises generating, by the processor, a vectorized sub-graph based on the received input. The method further comprises searching, by the processor, the knowledge graph to identify one or more verification requests matching the generated vectorized sub-graph. The method further comprises providing, by the processor, an output comprising the identified one or more verification requests.

Description

[0001] METHOD AND SYSTEM FOR ROOT-CAUSE ANALYSIS USING ONTOLOGICAL KNOWLEDGE GRAPH DESCRIPTION The present invention generally relates to management of assets, such as a machine and, more specifically, to a method and system for root-cause analysis of anomalous behaviour or faults in an asset using ontological knowledge graph comprising simulation data and diagnosis data of the asset. In engineering and manufacturing industries, it is important to understand root-cause of any anomalous behaviour (problem) that arise during operation of an asset. Identifying the root-cause is essential to devise appropriate solutions, prevent reoccurrence of the problem, and thereby improve quality and reliability of the asset. However, it can be a challenging task as the anomalous behaviour is often complex to diagnose and may be caused by multiple factors. Traditional root-cause analysis relies on the experience of the operator or maintenance personnel, manual analysis of data, and documentation that may be improperly recorded. This often results in a high level of coupling between field service personnel and observation and remedy. In other words, the existing approach to root-cause analysis is manual and relies heavily on experience and proper documentation. However, the lack of standardized documentation can lead to a high dependency on experienced field service personnel, resulting in a loss of efficiency when they depart. In light of the above, the present invention seeks to overcome these challenges by leveraging existing simulation data generated during the design phase, and diagnosis data comprising past diagnosis and remedies deployed, as available for the asset to provide a more efficient and effective solution for root-cause analysis of an anomalous behaviour thereof. The proposed solution relies on an ontology to capture observations, reasoning, and supporting materials such as simulations and measurements, as well as the remedies deployed. The object of the present invention is achieved by a computer- implemented method for performing root-cause analysis of an anomalous behaviour in an asset. The method comprises implementing, by a processor, a knowledge graph comprising at least one of simulation data from a design phase of the asset and diagnosis data for past anomalous behaviour(s) of the asset, in form of verification requests. The method further comprises configuring, by the processor, an user-interface to receive an input indicative of symptoms related to the anomalous behaviour in the asset. The method further comprises generating, by the processor, a vectorized sub-graph based on the received input. The method further comprises searching, by the processor, the knowledge graph to identify one or more verification requests matching the generated vectorized sub-graph. The method further comprises providing, by the processor, an output comprising the identified one or more verification requests. In one or more embodiments, the method further comprises organizing, by the processor, the verification requests in the knowledge graph utilizing a predefined ontology connecting the at least one of the simulation data from the design phase of the asset and the diagnosis data for past anomalous behaviour(s) of the asset based on one or more of matching boundary conditions, materials, CAD designs. In one or more embodiments, the method further comprises configuring, by the processor, the user-interface to define the symptoms indicative of the anomalous behaviour in the asset based on the predefined ontology. In one or more embodiments, the method further comprises fetching, by the processor, sensor data from one or more sensors associated with the asset in response to the received input, to be added therein. In one or more embodiments, the method further comprises configuring, by the processor, the user-interface to receive the input in form of one or more of Natural Language Processing (NLP) queries or SPARQL queries. In one or more embodiments, the method further comprises generating, by the processor, the vectorized sub-graph based on the received input by implementing a vectorization function. In one or more embodiments, the method further comprises ranking, by the processor, the identified one or more verification requests based on a degree of match with the generated vectorized sub- graph; and providing, by the processor, the output in form of a list of the identified one or more verification requests based on the ranking thereof. In one or more embodiments, the method further comprises storing, by the processor, the knowledge graph in a database configured in one or more of a cloud server and a local server. The object of the present invention is also achieved by a system for performing root-cause analysis of an anomalous behaviour in an asset. The system comprises a database storing a knowledge graph comprising at least one of simulation data from a design phase of the asset and diagnosis data for past anomalous behaviour(s) of the asset, in form of verification requests. The system also comprises an user-interface configured to receive an input indicative of symptoms related to the anomalous behaviour in the asset. The system further comprises a processor. The processor is configured to generate a vectorized sub-graph based on the received input; search the knowledge graph to identify one or more verification requests matching the generated vectorized sub-graph; and provide an output comprising the identified one or more verification requests. In one or more embodiments, the processor is further configured to organize the verification requests in the knowledge graph utilizing a predefined ontology connecting the at least one of the simulation data from the design phase of the asset and the diagnosis data for past anomalous behaviour(s) of the asset based on one or more of matching boundary conditions, materials, CAD designs. In one or more embodiments, the processor is further configured to define the symptoms indicative of the anomalous behaviour in the asset based on the predefined ontology. In one or more embodiments, the processor is further configured to fetch sensor data from one or more sensors associated with the asset in response to the received input, to be added therein. In one or more embodiments, the processor is further configured to generate the vectorized sub-graph based on the received input by implementing a vectorization function. In one or more embodiments, the processor is further configured to: rank the identified one or more verification requests based on a degree of match with the generated vectorized sub-graph; and provide the output in form of a list of the identified one or more verification requests based on the ranking thereof. In one or more embodiments, the database is configured in one or more of a cloud server and a local server. The object of the present invention is further achieved by a computer-program product, having machine-readable instructions stored therein, that when executed by a processor, cause the processor to perform steps of the method described above. The object of the present invention is further achieved by a computer readable medium on which program code sections of a computer program are saved, the program code sections being loadable into and / or executable in a system to make the system execute the method steps as described above when the program code sections are executed in the system. Still other aspects, features, and advantages of the invention are readily apparent from the following detailed description, simply by illustrating a number of particular embodiments and implementations, including the best mode contemplated for carrying out the invention. The invention is also capable of other and different embodiments, and its several details may be modified in various obvious respects, all without departing from the scope of the invention. Accordingly, the drawings and description are to be regarded as illustrative in nature, and not as restrictive. A more complete appreciation of the present invention and many of the attendant aspects thereof will be readily obtained as the same becomes better understood by reference to the following description when considered in connection with the accompanying drawings: FIG 1 is a flowchart representation of a computer-implemented method for performing root-cause analysis of an anomalous behaviour in an asset, in accordance with one or more embodiments of the present invention; FIG 2 is a block diagram representation of a system for performing root-cause analysis of an anomalous behaviour in an asset, in accordance with one or more embodiments of the present invention; FIG 3 is a schematic representation of a process for generation of a knowledge graph, in accordance with one or more embodiments of the present invention; FIG 4 is a depiction of verification request objects, in accordance with one or more embodiments of the present invention; FIG 5 is a schematic representation of a workflow for generating a knowledge graph containing diagnosis data, in accordance with one or more embodiments of the present invention; FIG 6 is a depiction of an exemplary knowledge graph, in accordance with one or more embodiments of the present invention; and FIG 7 is a schematic representation of a workflow for implementation of the steps of the method for performing root-cause analysis of an anomalous behaviour in an asset, in accordance with one or more embodiments of the present invention. Various embodiments are described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for the purpose of explanation, numerous specific details are set forth in order to provide thorough understanding of one or more embodiments. It may be evident that such embodiments may be practiced without these specific details. Examples of a method, a system, and a computer-program product for performing root-cause analysis of an anomalous behaviour in an asset are disclosed herein. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the invention. It is apparent, however, to one skilled in the art that the embodiments of the invention may be practiced without these specific details or with an equivalent arrangement. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the embodiments of the invention. Typically, a large number of simulations are performed during the design phase to validate and verify the design of an asset. Such simulation data can provide a wealth of information and knowledge, which may be utilized in operation to identify the root-cause of any anomalous behaviour in the asset. Further, details of field observations and deployed troubleshooting from the diagnosis data related to an asset can provide resourceful information for the root-cause of any anomalous behaviour in the asset. Herein, the field observations may be made either digitally in the form of error codes tracked by the monitoring set-up or as observations made by a service personnel. The present invention employs an ontological data structure to structurally store the simulation data and the diagnosis data, which allows for the efficient storage and retrieval of information. The present invention further provides an user- interface which enables users to search a database using symptoms and retrieve relevant simulations and / or past reports of field observations, analysis, and remedy. This approach is designed to streamline the process of identifying the root-cause of issues, as it allows for the efficient retrieval of relevant past reports and analyses. In particular, to leverage the simulation data and the diagnosis data for root-cause-analysis, a knowledge graph is employed. The knowledge graph is a data structure that links information and knowledge from different sources, enabling meaningful search and inference. In this case, the knowledge graph is built using verification requests, which are data structures representing formal requirements for an implementation, together with simulation models and past diagnosis, and corresponding simulation output and deployed remedies to prove the requirement. The verification requests are collected from the design phase and field observations, and organized into the knowledge graph using a predefined ontology. An ontology is a way of structurally storing and linking information and knowledge from different sources, such as the design tool, simulation software, and PLM (Product Lifecycle Management) tool. The knowledge graph is then saved in cloud or locally. Now, when a problem arises during operation, the operator can use the observed symptoms of the problem (based on the measurement data and the data displayed by the machine) as input to run a search through the knowledge graph. The ontology for defining observations and service is employed to create a sub-graph, which is then vectorized using a vectorization function, such as graph2vec framework, and compared against the past observations of similar anomalies. The search is performed either by using NLP (natural language processing) or SPARQL queries. The knowledge graph is searched for verification requests that match the observed symptoms. The verification requests that displayed similar behaviour as the observed symptoms are identified and the best candidates are provided as output to the operator, which may further be ranked by degree of similarity with the observed symptoms. The operator can choose the most likely verification request to identify the problem and decide the next steps. If further analysis is needed, a Design Engineer can make use of the existing (similar) simulation identified by the search and suggest design or operational changes. In summary, the proposed methodology of leveraging simulation data and diagnosis data using a knowledge graph technology for root- cause-analysis can be a powerful tool to support the analysis of complex problems in engineering and manufacturing industries. By connecting information and knowledge from different sources, the proposed methodology can enable a meaningful search and inference to identify the root-cause of an anomalous behaviour in an asset and support the design of appropriate solutions. FIG 1 is a flowchart of a method (as represented by reference numeral 100) for performing root-cause analysis of an anomalous behaviour in an asset, in accordance with an embodiment of the present invention. As used herein, in an example, the asset may be an industrial asset which refers to any physical equipment or facility used in the production, manufacturing, or processing of goods or services in an industrial setting. In such case, the asset may include machinery, tools, vehicles, buildings, and other types of infrastructure used to support industrial operations. In general, industrial assets may range from small machines to large manufacturing plants, and are critical components of many industries such as manufacturing, mining, energy, and transportation. In other examples, the asset may be a digital asset, such as a computer system, network device, or physical equipment, without departing from the scope and the spirit of the present invention. Further, as used herein, an anomalous behaviour in the asset refers to any unusual or unexpected activity or behaviour that deviates from its normal or expected pattern of behaviour. For example, in case of the industrial asset, the anomalous behaviour may manifest in various ways such as unusual vibrations, fluctuations in power consumption, abnormal noise, or changes in the machine's operating parameters. For example, if a machine typically operates within a specific range of temperature, pressure, or speed, an anomalous behaviour could be an unexpected increase or decrease in any of these parameters. These deviations may be an indication of a potential fault or failure in the machine, which may lead to a breakdown or outage. In other examples, in case of the digital asset, the anomalous behaviour may be in the form of a security breach, system failure, or malfunction of a computing device. For instance, if a network device suddenly starts sending large amounts of traffic to an external IP address that is not known or authorized, this would be considered anomalous behaviour. Root-cause analysis of an anomalous behaviour in an asset refers to the process of identifying the underlying cause or causes that led to the deviation from the normal or expected behaviour of the asset. The purpose of root-cause analysis is to determine the underlying problem or problems that need to be addressed in order to prevent similar anomalies from occurring in the future. The root-cause analysis involves a systematic investigation that considers all possible causes and factors that may have contributed to the anomalous behaviour, such as mechanical failures, environmental conditions, operator error, or maintenance issues. The analysis typically involves data collection, hypothesis testing, and the use of various analytical tools to pinpoint the most likely cause or causes of the anomalous behaviour. By identifying the root-cause of an anomaly, organizations can take targeted corrective actions to prevent similar incidents from occurring in the future and improve the reliability and performance of their asset. Referring to FIG 2, illustrated is a block diagram of a system 200 for performing the root-cause analysis of the anomalous behaviour in the asset, in accordance with one or more embodiments of the present invention. It may be appreciated that the system 200 described herein may be implemented in various forms of hardware, software, firmware, special purpose processors, or a combination thereof. One or more of the present embodiments may take a form of a computer program product comprising program modules accessible from computer-usable or computer-readable medium storing program code for use by or in connection with one or more computers, processors, or instruction execution system. For the purpose of this description, a computer-usable or computer-readable medium may be any apparatus that may contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium may be electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation mediums in and of themselves as signal carriers are not included in the definition of physical computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, random access memory (RAM), a read only memory (ROM), a rigid magnetic disk and optical disk such as compact disk read-only memory (CD-ROM), compact disk read / write, and digital versatile disc (DVD). Both processors and program code for implementing each aspect of the technology may be centralized or distributed (or a combination thereof) as known to those skilled in the art. In an example, the system 200 may be embodied as a computer-program product 200 programmed for performing the said purpose. The system 200 may be incorporated in one or more physical packages (e.g., chips). By way of example, a physical package includes an arrangement of one or more materials, components, and / or wires on a structural assembly (e.g., a baseboard) to provide one or more characteristics such as physical strength, conservation of size, and / or limitation of electrical interaction. It is contemplated that in certain embodiments the computing device may be implemented in a single chip. As illustrated, the system 200 includes a communication mechanism such as a bus 202 for passing information among the components of the system 200. The system 200 includes a processor 204 and a memory 206. Generally, the memory 206 is communicatively coupled to the processor 204. In an example, the memory 206 may be embodied as a computer readable medium on which program code sections of a computer program are saved, the program code sections being loadable into and / or executable in a system to make the system 200 execute the steps for performing the said purpose. Generally, as used herein, the term “processor” refers to a computational element that is operable to respond to and processes instructions that drive the system 200. Optionally, the processor includes, but is not limited to, a microprocessor, a microcontroller, a complex instruction set computing (CISC) microprocessor, a reduced instruction set (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or any other type of processing circuit. Furthermore, the term “processor” may refer to one or more individual processors, processing devices and various elements associated with a processing device that may be shared by other processing devices. Additionally, the one or more individual processors, processing devices and elements are arranged in various architectures for responding to and processing the instructions that drive the system 200. Herein, the memory 206 may be volatile memory and / or non-volatile memory. The memory 206 may be coupled for communication with the processor 204. The processor 204 may execute instructions and / or code stored in the memory 206. A variety of computer-readable storage media may be stored in and accessed from the memory 206. The memory 206 may include any suitable elements for storing data and machine-readable instructions, such as read only memory, random access memory, erasable programmable read only memory, electrically erasable programmable read only memory, a hard drive, a removable media drive for handling compact disks, digital video disks, diskettes, magnetic tape cartridges, memory cards, and the like. In particular, the processor 204 has connectivity to the bus 202 to execute instructions and process information stored in the memory 206. The processor 204 may include one or more processing cores with each core configured to perform independently. A multi- core processor enables multiprocessing within a single physical package. Examples of a multi-core processor include two, four, eight, or greater numbers of processing cores. Alternatively, or in addition, the processor 204 may include one or more microprocessors configured in tandem via the bus 202 to enable independent execution of instructions, pipelining, and multithreading. The processor 204 may also be accompanied with one or more specialized components to perform certain processing functions and tasks such as one or more digital signal processors (DSP), and / or one or more application-specific integrated circuits (ASIC) (as represented by reference numeral 208). The DSP 208 may be configured to process real-world signals (e.g., sound) in real time independently of the processor 204. Similarly, the ASIC 208 may be configured to performed specialized functions not easily performed by a general purposed processor. Other specialized components to aid in performing the inventive functions described herein include one or more field programmable gate arrays (FPGA) (not shown), one or more controllers (not shown), or one or more other special-purpose computer chips. The system 200 also includes a database 210. As used herein, the database 210 is an organized collection of structured data, typically stored in a computer system and designed to be easily accessed, managed, and updated. The database 210 may be in form of a central repository of information that can be queried, analysed, and processed to support various applications and business processes. In the system 200, the database 210 provides mechanisms for storing, retrieving, updating, and deleting data, and typically includes features such as data validation, security, backup and recovery, and data modelling. The system 200 further includes an input device 212 and an output device 214. The input device 212 may take various forms depending on the specific application of the system 200. In an example, the input device 212 may include one or more of a keyboard, a mouse, a touchscreen display, a microphone, a camera, or any other hardware component that enables the user to interact with the system 200. Further, the output device 214 may be in the form of a display. It is to be understood that, when reference is made in the present invention to the term “display” this refers generically either to a display screen on its own or to the screen and an associated housing, drive circuitry and possibly a physical supporting structure, of which all, or part of is provided for displaying information. In the present system 200, the processor 204 and accompanying components have connectivity to the memory 206 via the bus 202. The memory 206 includes both dynamic memory (e.g., RAM, magnetic disk, writable optical disk, etc.) and static memory (e.g., ROM, CD-ROM, etc.) for storing executable instructions that when executed perform the method steps described herein for performing root-cause analysis of an anomalous behaviour in an asset. In particular, the memory 206 includes a module arrangement 216 to perform steps for performing root-cause analysis of an anomalous behaviour in an asset. Also, in the system 200, the memory 206 may be configured to store the data associated with or generated by the execution of the inventive steps. Referring to FIGS 1 and 2 in combination, the various steps of the method 100 as described hereinafter may be executed in the system 200, or specifically in the processor 204 of the system 200, for performing root-cause analysis of an anomalous behaviour in an asset. It may be appreciated that although the method 100 is illustrated and described as a sequence of steps, it may be contemplated that various embodiments of the method 100 may be performed in any order or a combination and need not include all of the illustrated steps. For purposes of the present invention, the method 100 and the system 200 involves organizing, by the processor 204, verification requests related to each asset in a knowledge graph utilizing a predefined ontology connecting at least one of simulation data from a design phase of the asset and diagnosis data for past anomalous behaviour(s) of the asset. As used herein, the “ontology” is a way of defining the concepts, data, and entities that belong to a specific domain or area of knowledge, and how they are related to each other. The ontology may be defined based on, but not limited to, one or more of matching boundary conditions, materials, CAD designs of the asset, and the like. On the other hand, as used herein, the “knowledge graph” may refer to a way of organizing data and information about a specific domain or area of interest, using a set of concepts and relationships that are defined by the ontology. The knowledge graph based on the predefined ontology may help to reason about the domain and to discover new insights from the data. For the purpose of present invention, the “simulation data” may refer to information generated through the use of simulation software in the design phase, which is used to model and simulate the behaviour of a product or system under various conditions. The simulation software may be used to simulate the performance of a wide range of products or systems, including but not limited to mechanical, electrical, and software systems. Simulation data typically comprises a range of inputs, including physical parameters such as material properties, geometrical dimensions, and operating conditions. The simulation data may be used to optimize the design of the product or system, to identify potential issues or failures, and to validate the design against the specified requirements. Also, the “diagnosis data” may refer to information collected during the operational phase of an asset that helps to identify and diagnose anomalous behaviour. This data may include, for example, sensor readings, error codes, maintenance logs, and other relevant information that can be used to identify the root cause of a problem or failure. By analysing this diagnosis data, engineers and operators can gain insights into the health and performance of the asset and take corrective actions to prevent or mitigate future issues. The diagnosis data can also be used to refine simulation models and verify the accuracy of the simulations, leading to continuous improvement of asset design and performance. In an example, the diagnosis data may include logs that can provide valuable information about the history of an asset, including repairs, replacements, and inspections. By analysing such maintenance logs, it may be possible to identify patterns of failures or anomalies that can help diagnose the root cause of a current issue. As discussed, in an aspect, the present invention aims to use simulation data of the asset, including simulation models generated during design phase of the asset, to support root-cause analysis of the anomalous behaviour thereof by reproducing the expected behaviour of the asset and verifying its compliance with the requirements. In general, for complex products, multiple simulation models are needed for each design iteration, covering different physical domains, levels of detail and scope. Such simulation data generated during the design phase is not utilized in the operational phase of the product. The present invention aims to address this issue by enabling or facilitating the (partial) reuse of simulations created during the design of previous or related products or product variants for purposes of the root-cause analysis of the anomalous behaviour in the asset. That is, instead of basing the root-cause-analysis solely on measurement data and experience, the present invention leverage the existing simulation data generated during the design phase of the asset. Currently, simulation models need to be created from scratch or earlier (partially) reusable models need to be found by manual search, on databases with varying amounts of structuring or through extensive discussions with other simulation experts. In the best- case scenario, simulation models are stored in Product Lifecycle Management (PLM) application (such as Teamcenter®) or equivalent Simulation Process & Data Management (SPDM) software. Even with a PLM Application, search capabilities are limited and dependent on how diligently such software is used, i.e., whether users typically organize and label their work properly. In practice, simulation data is rarely well organized, and reuse of simulations requires time consuming searches of the correct simulation model, many times relying on direct communication with the original model’s author. This also limits the potential of reusability of models when the model author is not available (e.g., too busy with other tasks, left the organization, etc.). In embodiments of the present invention, at step 110, the method 100 includes implementing, by the processor 204, the knowledge graph comprising at least one of simulation data from a design phase of the asset and diagnosis data for past anomalous behaviour(s) of the asset, in form of verification requests. Herein, for each asset designed through simulation, a knowledge graph is built using the corresponding verification requests generated in the PLM application (or comparable SPDM software) and the data contained in it (Requirements, Parameters, CAD, simulation results and failed / passed flags). Herein, the verification request is a data structure, representing a formal requirement for the system, together with simulation models and the simulation output to prove the requirement. An ontology is defined to structurally store and then link information and knowledge from disparate sources such as the design tool, the simulation software and the PLM tool. Referring to FIG 3, illustrated is a schematic representation of a process (as represented by reference numeral 300) for generation of a knowledge graph, in accordance with an embodiment of the present invention. For this purpose, the process 300 may involve a PLM (Product Lifecycle Management) system 302 which is required to store and organize simulation data. The PLM system 302 consists of a database that stores all PLM information, including detailed product information, simulation models of the product, product requirements, and verification request objects (like verification request objects 400 as depicted in FIG 4). In the exemplary illustration of FIG 4, the verification request objects 400 is shown to include verification requests for thermal analysis (referred by reference numeral 402), verification requests for mechanical analysis (referred by reference numeral 404), and verification requests for system analysis (referred by reference numeral 406). Referring back to FIG 3, additionally, a PLM user interface (UI) 304 is available for the user to create, upload, retrieve, and manage such information. An ontology that covers the domains of simulation and requirements management is also utilized, along with a graph data generator 306. Further, a recommendation system 308 is utilized in the process 300 that can quantify the relevance of any simulation object with respect to a given verification request. Herein, the PLM system 302 may contain historical data including several instances of the said items, including the detailed product information, the simulation models of the product, the product requirements, and the verification request objects. For each of these items, the data stored in the PLM system 302 may include a combination of structured metadata (referred by reference numeral 302a) and unstructured raw data (referred by reference numeral 302b). The structured metadata 302a is easily searchable and managed by the PLM system 302 and includes qualitative and quantitative properties of the different instances of object described above. Typically, the structured metadata 302a may exist in tabular form inside a relational database system. The unstructured raw data 302b may include individual files (text or binary) whose internal structures are not visible to or searchable with the PLM system 302. Usually, the structured metadata 302a may only contain relations or links that allow the PLM system 302 to download the file onto the user's computer. Further, some relevant examples of the unstructured raw data 302b may include technical drawings, 3D geometry files, simulation model files, simulation results files, and technical reports. In the process 300, the graph data generator 306 may provide structured data translator (referred by reference numeral 306a) for processing the structured metadata 302a. Also, the graph data generator 306 may utilize specialized software, separate from the PLM system 302, for unstructured data parsing (referred by reference numeral 306b), as may be required to view and edit the unstructured raw data 302b. Further, the recommendation system 308 may implement a recommender algorithm to generate a relevance score for each simulation model stored in the graph database 310. Herein, the algorithm may work with heuristics, with machine learning (ML), or with a combination of both. The heuristic methods used to generate the relevance score include similarity of tested parameters, similarity of product context, rate of success of past verification requests (VRs), similarity of simulation domain or simulation type, similarity of input parameters, similarity of simulation setup, geometrical similarity, same Simulation Engineer, and natural language similarity within free text fields. As may be appreciated, the machine learning (ML) methods work best in cases where the database of past VRs (including simulation models) is large, and elements of existing VRs, as well as the corresponding simulation models, may be used to train a ML algorithm. Herein, the elements of existing VRs, as well as the corresponding simulation models may be used to train a classification algorithm (possibly in the form of a deep artificial neural network). This classification algorithm, given new, incomplete VR, may be able to predict for each simulation model whether the said elements are a good match, with a certain confidence. The confidence of the classifier can function as the relevance score. Heuristics may be used in combination with the ML classifier to pre-filter candidate models. This may make the generation of recommendations more efficient (necessary for providing fast responses and therefore a good user experience). As discussed, the recommendation system 308 is utilized in the process 300 that can quantify the relevance of any simulation object with respect to a given verification request. For this purpose, the recommendation system 308 may provide recommended model IDs (referred by reference numeral 308a) to the PLM UI 304, and in turn receive the verification request ID (referred by reference numeral 308b) therefrom. Herein, the verification request (VR) is a key element for the functioning of the process 300. The purpose of VR is to support the process of simulation- based verification by facilitating the communication between a System Designer and a Simulation Engineer and by documenting the verification process. The VR consists of one or more elements, such as a description of the verification that needs to be executed, a description of the product context, an owner or Product Designer, an assignee or Simulation Engineer, and a list of requirements to be verified. Each requirement may also include: (a) a list of zero or more design parameters and the values for which the verification needs to be run (e.g., geometrical parameters, material properties), (b) a list of zero or more parameters defining the (virtual) testing condition and the values for which the simulation needs to be run (e.g., ambient temperature, wind speed), and (c) a list of one or more output parameters and ranges which define the passing or failing of the requirement (e.g., maximum stress, power consumption). Further, in some examples, the VR may include a simulation model used to "run" the verification, and a result calculated automatically by comparing results from the simulation with the ranges in the VR. A typical VR workflow starts with the System Designer preparing a VR and filling elements thereof (as described above). After that, a Simulation Engineer takes over the VR. The Simulation Engineer may then create or find a simulation model that is appropriate for the verification, associate this model with the VR, run the simulation and enter the resulting output parameter values into the VR. To extract relevant data from the PLM system 302, a translation component is necessary to map relational data in the PLM system 203 into the graph data generator 306, and specific data-analysis routines are required that can generate relevant graph data of information not contained in the PLM system 302. The structure of generated knowledge graph is dictated by the corresponding ontology. The generated knowledge graph may then be stored in a graph database 310 (equivalent to the database 210 as described above). In another example, the proposed solution employs an ontological graph to structurally store details of field observations and deployed troubleshooting. Such a solution relies on an ontology to capture the observations, the reasoning and supporting material such as simulations and measurements used and also the remedy deployed. FIG 5 depicts a schematic representation of a workflow (as represented by reference numeral 500) for generating a knowledge graph containing diagnosis data. Herein, when an error 502 is encountered, a root-cause analysis (as represented by reference numeral 504) is performed by a service personnel, and the resultant analysis details (as represented by reference numeral 506) are stored which may include information about observations and notes (referred by reference numeral 506a), and troubleshooting and remedies deployed (referred by reference numeral 506b). The analysis typically results in unstructured information in the form of various simulations across tools, reports in tools such as word and excel which need to be stored in a structured fashion. This information is digitized (as represented by reference numeral 508) using the predefined ontology (as represented by reference numeral 10). The ontology 10 is designed to capture all the observations, the analysis carried out by the user along with supporting material such as simulations, and the troubleshooting activity performed on the asset. The digitized information is used to generate a knowledge graph which may then be stored in a graph database 510 (equivalent to the database 210 as described above). FIG 6 depicts an exemplary knowledge graph (as represented by reference numeral 600) that may be generated as per embodiment of the present invention. In an example, the knowledge graph 600 may have a structure that may include nodes which represent entities, edges which represent the relationships between entities, attributes which are additional pieces of information associated with nodes and edges, and labels which are used to classify nodes and edges into different types or categories. The knowledge graph 600 is a knowledge representation that encodes information about entities, their attributes, and their relationships with other entities. The knowledge graph 600 is typically represented as a directed graph, where nodes represent entities and edges represent relationships between them. In the example illustration of FIG 6, the knowledge graph 600 may implement multiple verification requests, such as the verification requests 402, 404, 406 (as described) to connect various nodes which may include, but not limited, multiple CAD models (as represented by 602, 604, 606), multiple materials (as represented by 608, 610), and various conditions, like hot condition (as represented by 612), cold condition (as represented by 614), etc. The method 100 and the system 200 of the present invention also involves storing, by the processor 204, the knowledge graph in a database (such as, the database 210) configured in one or more of a cloud server and a local server. That is, the ontological knowledge graph can either be saved in the cloud and be accessible from multiple locations or locally for example in a control system. Cloud server refers to using a third-party provider to host and manage the database, while local server involves storing the database on a machine or server that is managed by the user. Cloud storage offers several benefits, including scalability, accessibility, and security. With cloud storage, users can easily scale their database up or down to meet changing needs, and can access it from anywhere with an internet connection. Additionally, cloud providers often offer robust security measures and backup and recovery options to protect the database from data loss or breaches. On the other hand, local storage offers more control and customization options. With local storage, users have complete control over the database and can tailor it to their specific needs. Local storage also typically offers faster performance and lower latency than cloud storage, since the database is stored on a local machine rather than being accessed over the internet. The decision to store the knowledge graph in the cloud or locally will depend on a variety of factors, including the size and complexity of the database, the specific requirements of the application, and the user's budget and resources. At step 120, the method 100 includes configuring, by the processor 204, an user-interface to receive an input indicative of symptoms related to the anomalous behaviour in the asset. It may be appreciated that the input may be received via the input device 212 of the system 200. Herein, the system 200 provides the user- interface (not depicted) to receive the input indicative of symptoms related to the anomalous behaviour in the asset. That is, when an anomalous behaviour or a fault is observed in an asset, the said user-interface provided by the system may allow to receive the observations made digitally in the form of error codes tracked by the monitoring set-up or as observations made by a service personnel. Such user-interface may provide a comprehensive list of possible symptoms related to anomalous behaviour in the asset. This list may be organized in a logical and easy-to-navigate manner, allowing users to quickly find the symptom(s) they are experiencing. Such user-interface may further allow the user to rank severity of the symptom. This will help the user to determine the urgency of the situation and prioritize actions accordingly. In the present embodiments, the method 100 involves configuring, by the processor 204, the user-interface to define the symptoms indicative of the anomalous behaviour in the asset based on the predefined ontology. For this purpose, the user-interface may require users to input their symptoms using terms defined in a predefined ontology. In other words, the predefined ontology would provide a standardized terminology for the symptoms, which would reduce ambiguity and help ensure that users enter accurate and consistent information. In some examples, the user-interface may further validate user inputs and ensure that they conform to the terms and definitions in the ontology. This helps ensure consistency and accuracy in the symptoms being reported, as well as for conducting the required search (as described later in the description). In some embodiments, the method 100 involves configuring, by the processor 204, the user-interface to receive the input in the form of one or more of Natural Language Processing (NLP) queries or SPARQL queries. That is, the user-interface may be equipped with NLP / NLU capabilities to understand and process natural language queries. This would involve using algorithms and models to analyse the structure and meaning of the user's input and convert it into a machine-readable format. The user-interface may also support SPARQL queries, a structured query language used to retrieve and manipulate data. This would allow users to formulate complex queries to retrieve specific data about the asset's anomalous behaviour. In some examples, the user-interface may also include query suggestions or autocomplete features to help users formulate their queries more quickly and accurately. In some embodiments, the method 100 involves fetching, by the processor, sensor data from one or more sensors associated with the asset in response to the received input, to be added therein. That is, when the processor 204 receives input indicative of symptoms related to anomalous behaviour in an asset, it may need to fetch sensor data from one or more sensors (not shown) associated with the asset to help diagnose the issue. This may involve connecting to one or more databases or APIs to retrieve the data. The fetched sensor data may then be added to the received input for further processing. It may be appreciated that by integrating the sensor data with the input, it may be able provide a more comprehensive view of the issue, enabling a more accurate root—cause analysis and thereby appropriate action. At step 130, the method 100 includes generating, by the processor 204, a vectorized sub-graph based on the received input. As used herein, the vectorized sub-graph refers to a way of optimizing the performance of certain computations in a graph by grouping together multiple operations into a single vectorized operation. Generating the vectorized sub-graph may involve mapping the user's symptoms to nodes in the knowledge graph and generating a sub-graph that represents the relationships between those nodes. The sub-graph may then need to be vectorized to enable efficient searching. This may involve representing the sub-graph as a vector of features or attributes that can be compared to other vectors in the knowledge graph. In an embodiment, the method 100 includes generating, by the processor 204, the vectorized sub-graph based on the received input by implementing a vectorization function. As discussed, when the processor 204 receives input indicative of symptoms related to anomalous behaviour in an asset, it may need to generate a vectorized sub-graph based on the input to search the knowledge graph for verification requests. One approach to generating vectorized sub-graphs is to use a graph2vec framework. Graph2vec is a framework for learning distributed representations of graphs, inspired by the word2vec model for learning word embeddings. This may involve combining the node embeddings to generate a graph embedding that captures the semantics of the sub-graph as a whole. Using the graph2vec framework to generate vectorized sub-graphs would enable the processor 204 to efficiently and accurately search the knowledge graph for relevant verification requests. At step 140, the method 100 includes searching, by the processor 204, the knowledge graph to identify one or more verification requests matching the generated vectorized sub-graph. That is, the processor 204 is configured to search the knowledge graph to identify one or more verification requests that match the vectorized sub-graph generated from the received input. The search is based on the similarity between the vectorized sub-graph and the sub-graphs of the verification requests stored in the knowledge graph. Herein, the sub-graphs of the verification requests are generated based on the observations, analysis, simulations, and remedies related to previously identified problems in assets. Herein, the search may be performed using either natural language processing (NLP) or SPARQL queries. If NLP is used, an additional NLP layer may be added to the knowledge graph to enable the processing of natural language queries. The NLP layer is designed to map the natural language queries to graph-based queries that may be executed against the knowledge graph. In some examples, the knowledge graph may use one or more techniques such as graph indexing, query optimization, and caching to speed up the search process to allow for performing this search efficiently. Herein, the graph indexing involves creating an index of the graph data to make it faster to search and retrieve information. The query optimization involves optimizing the search query to make it more efficient and to reduce the amount of time it takes to return results. Further, the caching involves storing frequently used query results in memory to reduce the time it takes to retrieve them in the future. At step 150, the method 100 includes providing, by the processor 204, an output comprising the identified one or more verification requests. As discussed, the processor 204 searches the knowledge graph for verification requests that match the symptoms observed in the asset. The identified verification requests may then be outputted for reference of the user for performing root-cause analysis of the anomalous behaviour in the asset. Herein, in an example, the best matching verification requests are presented to the operator as the output of the system 200. It may be understood that the system 200 may provide the said output via the output device 214. In an embodiment, the method 100 may involve ranking, by the processor 204, the identified one or more verification requests based on a degree of match with the generated vectorized sub- graph. Further, the method 100 may involve providing, by the processor 200, the output in form of a list of the identified one or more verification requests based on the ranking thereof. That is, after searching the knowledge graph to identify one or more verification requests matching the generated vectorized sub-graph, the processor 204 provides an output in the form of a list of the identified verification requests. The verification requests in the list are ranked based on their degree of similarity with the observed symptoms of the anomalous behaviour in the asset. The ranking algorithm could be based on various factors, such as the number of similar symptoms between the observed symptoms and the symptoms described in the verification request, the severity of the anomalous behaviour in the asset, the relevancy of the verification request to the type of asset or industry, and other factors that may be deemed relevant. The operator can review the list of identified verification requests and choose the one that is most likely to be relevant to the current situation based on the ranking provided. Referring to FIG 7, illustrated is a schematic representation of a workflow (as represented by reference numeral 700) for implementation of the steps 110-150 of the method 100 of the present invention. Herein, when an error 702 is encountered, the observations either made digitally in the form of error codes tracked by the monitoring set-up or as observations made by a service personnel are recorded. These observations are then digitized (as represented by reference numeral 704) using the predefined ontology 10 (as discussed). The ontology 10 for defining observations and service is employed to create a sub-graph. This sub-graph is then vectorized using a vectorization function (as represented by reference numeral 706), such as graph2vec set-up. The vectorized sub-graph is then compared using a similarity function (as represented by reference numeral 708) against a knowledge graph (such as, the knowledge graph 600) from a graph database 710 (equivalent to the database 210, as described above). Herein, the knowledge graph comprises at least one of simulation data from a design phase of the asset and diagnosis data for past anomalous behaviour(s) of the asset (such as, the past observations of damage), in form of verification requests, to identify one or more verification requests matching the generated vectorized sub- graph. The most similar analysis are then retrieved from the graph as ranked results (as represented by reference numeral 712) in the form of observation and notes (referred by reference numeral 712a), and troubleshooting and remedies deployed (referred by reference numeral 712b). In an implementation, the method 100 and the system 200 of the present disclosure may be utilized for an exemplary real-world workflow involving an issue with an asset such as, excessive heating in a wind turbine, for performing root-cause analysis of an anomalous behaviour. Herein, when an alarm for the issue is generated, an Engineer (such as, a Service Engineer) may be notified of the alarm and corresponding anomalous data for the issue. The Engineer may use the techniques as proposed in the present disclosure to speed up root-cause analysis and the decision making process, like changes to be made in the way the asset is operated (e.g., reduce the speed, increase cooling, change the load and the like). If further analysis is needed to find a solution, a Design Engineer may make use of the existing (similar) simulation identified by the search and suggest design changes (reinforce some component, change the material of some parts and the like). The present invention proposes a solution for efficient root-cause analysis of an anomalous behaviour in an asset. The proposed solution employs an ontological graph to structurally store details of field observations and deployed troubleshooting. The proposed solution involves an user-interface that enables the user to search the database using symptoms and retrieve past reports of field observations, analysis done, and remedy implemented. The proposed solution also involves a recommendation engine that suggests design changes or changes to be made in the way the asset is operated based on the existing (similar) simulation identified by the search. Herein, the large number of simulations performed during the design phase and the knowledge contained in it are reused in operation to perform a root-cause analysis. The knowledge graph is employed to connect the simulation data and allow meaningful search, and to automatically point to the most relevant simulation / analysis model. The proposed solution also relies on field observations that are recorded in a form or some other source of information, which are then populated in a knowledge graph. This enables an efficient structured matching of the error observed along with the context of the operation, such as nature of asset, number of starts, stops, etc. The proposed solution would boost the efficiency of identifying precedence in resolving a defect or anomaly. In addition, the remedies suggested by the system 200 would also provide the field outcomes of the solutions, enabling user confidence in the recommendation. The present invention provides several advantages over the traditional approach to root-cause analysis of operational anomalies in industrial assets, including improved efficiency of identifying precedence in resolving a defect or anomaly; increased accuracy and speed in the decision-making process; increased user confidence in the recommendation; reuse of large amounts of data generated during the design phase to perform root-cause analysis during the operational phase; ability to automatically point to the most relevant simulation model(s), and the like. While the present invention has been described in detail with reference to certain embodiments, it should be appreciated that the present invention is not limited to those embodiments. In view of the present invention, many modifications and variations would be present themselves, to those skilled in the art without departing from the scope of the various embodiments of the present invention, as described herein. The scope of the present invention is, therefore, indicated by the following claims rather than by the foregoing description. All changes, modifications, and variations coming within the meaning and range of equivalency of the claims are to be considered within their scope.

[0002] Reference Numerals ontology 10 method 100 step 110 step 120 step 130 step 140 step 150 system 200 bus 202 processor 204 memory 206 DPS / ASIC 208 database 210 input device 212 output device 214 module arrangement 216 process 300 PLM system 302 structured metadata 302a unstructured raw data 302b PLM user interface 304 graph data generator 306 structured data translator 306a unstructured data parsing 306b recommendation system 308 graph database 310 verification request objects 400 verification requests for thermal analysis 402 verification requests for mechanical analysis 404 verification requests for system analysis 406 workflow 500 error 502 root-cause analysis 504 resultant analysis details 506 observations and notes 506a troubleshooting and remedies deployed 506b digitization 508 graph database 510 knowledge graph 600 CAD model 1 602 CAD model 2 604 CAD model 3 606 Material 1 608 Material 2 610 hot condition 612 cold condition 614 workflow 700 error 702 observations digitization 704 vectorization function 706 similarity function 708 graph database 710 ranked results 712 observation and notes 712a troubleshooting and remedies deployed 712b

Claims

PATENT CLAIMS 1. A computer-implemented method (100) for performing root- cause analysis of an anomalous behaviour in an asset, the method (100) comprising: implementing, by a processor (204), a knowledge graph (600) comprising at least one of simulation data from a design phase of the asset and diagnosis data for past anomalous behaviour(s) of the asset, in form of verification requests; configuring, by the processor (204), an user-interface to receive an input indicative of symptoms related to the anomalous behaviour in the asset; generating, by the processor (204), a vectorized sub-graph based on the received input; searching, by the processor (204), the knowledge graph (600) to identify one or more verification requests matching the generated vectorized sub-graph; and providing, by the processor (204), an output comprising the identified one or more verification requests.

2. The method according to claim 1, further comprising: organizing, by the processor (204), the verification requests in the knowledge graph (600) utilizing a predefined ontology connecting the at least one of the simulation data from the design phase of the asset and the diagnosis data for past anomalous behaviour(s) of the asset based on one or more of matching boundary conditions, materials, CAD designs.

3. The method according to claim 2, further comprising:configuring, by the processor (204), the user-interface to define the symptoms indicative of the anomalous behaviour in the asset based on the predefined ontology.

4. The method according to any of the preceding claims, further comprising: fetching, by the processor (204), sensor data from one or more sensors associated with the asset in response to the received input, to be added therein.

5. The method according any of the preceding claims, further comprising: configuring, by the processor (204), the user-interface to receive the input in form of one or more of Natural Language Processing (NLP) queries or SPARQL queries.

6. The method according to any of the preceding claims, further comprising: generating, by the processor (204), the vectorized sub-graph based on the received input by implementing a vectorization function.

7. The method according to any of the preceding claims, further comprising: ranking, by the processor (204), the identified one or more verification requests based on a degree of match with the generated vectorized sub-graph; and providing, by the processor (204), the output in form of a list of the identified one or more verification requests based on the ranking thereof.

8. The method according any of the preceding claims, further comprising: storing, by the processor (204), the knowledge graph (600) in a database (210) configured in one or more of a cloud server and a local server.

9. A system (200) for performing root-cause analysis of an anomalous behaviour in an asset, the system (200) comprising: a database (210) storing a knowledge graph (600) comprising at least one of simulation data from a design phase of the asset and diagnosis data for past anomalous behaviour(s) of the asset, in form of verification requests; an user-interface configured to receive an input indicative of symptoms related to the anomalous behaviour in the asset; a processor (204) configured to: generate a vectorized sub-graph based on the received input; search the knowledge graph (600) to identify one or more verification requests matching the generated vectorized sub-graph; and provide an output comprising the identified one or more verification requests.

10. The system according to claim 9, wherein the processor (204) is further configured to organize the verification requests in the knowledge graph (600) utilizing a predefined ontology connecting the at least one of the simulation data from the design phase of the asset and the diagnosis data for pastanomalous behaviour(s) of the asset based on one or more of matching boundary conditions, materials, CAD designs.

11. The system according to claim 10, wherein the processor (204) is further configured to define the symptoms indicative of the anomalous behaviour in the asset based on the predefined ontology.

12. The system according to any of the preceding system-based claims, wherein the processor (204) is further configured to fetch sensor data from one or more sensors associated with the asset in response to the received input, to be added therein.

13. The system according to any of the preceding system-based claims, wherein the processor (204) is further configured to: rank the identified one or more verification requests based on a degree of match with the generated vectorized sub-graph; and provide the output in form of a list of the identified one or more verification requests based on the ranking thereof.

14. A computer program product, comprising computer program code which, when executed by a computer system, cause the computer system to carry out the method (100) of one of the claims 1 to 8.

15. A computer-readable medium comprising a computer program product comprising computer program code which, when executed by a computer system, cause the computer system to carry out the method (100) of one of the claims 1 to 8.

Images