Claims:
1. A processor implemented method (200) comprising:
capturing (202) a plurality of knowledge elements associated with a plurality of components, a plurality of faults and a plurality of processes of an industrial plant in a knowledge base, via one or more hardware processors, each of the plurality of knowledge elements associated with one of a problem domain and a solution domain corresponding to the problem domain, wherein the solution domain includes tools for the problem domain;
organizing (204) the plurality of knowledge elements in a knowledge ontology of the knowledge base using a plurality of ontological meta-models, via the one or more hardware processors, wherein the plurality of ontological meta-models utilizes a contextual information associated with the industrial plant for organizing the plurality of knowledge elements in the knowledge ontology;
translating (206) the knowledge ontology to an intermediate domain representation of the solution domain, via the one or more hardware processors, wherein the intermediate domain representation provides a fault detection view of the industrial plant, and wherein translating the knowledge ontology to the intermediate domain representation comprises:
identifying (208) a set of knowledge elements from amongst the plurality of knowledge elements from the problem domain using a set of semantic queries;
identifying (210), from a knowledge repository, semantics and syntax of an intermediate solution domain model instance associated with the solution domain;
mapping (212) the set of knowledge elements identified from the problem domain to the semantics of the intermediate solution domain model instance using a domain specific language (DSL) to generate an intermediate domain model; and
validating (214) the intermediate solution domain model for a plurality of validation parameters using a plurality of validation algorithms; and
translating (216) the intermediate solution domain model to a fault state machine model using a set of translation templates created using one or more model transformation techniques, via the one or more hardware processors, wherein the fault state machine model comprises a plurality of hierarchical states, and wherein each hierarchal state comprises a set of parallel states enabling tracing of a plurality of fault states at each level of hierarchical state from amongst the plurality of hierarchical states, and wherein the fault state machine model is used for executing and performing fault detection.

2. The method of claim 1, wherein the plurality of hierarchical states of the state machine model comprises one or more of process states, failure states, failure mode states and root cause states.

3. The method of claim 1, wherein the intermediate solution domain model comprises one of a process model, a control system model, an energy flow model, a data model and a storage model.

4. The method of claim 1, wherein the plurality of knowledge elements are captured using a constrained natural language, wherein the constrained natural language populates natural language statements derived from the plurality of sources into an OWL based ontology, and specifies a plurality of fault detection rules by inferring system state from sensor data associated with the industrial plant.

5. A system (501), comprising:
a memory (515) storing instructions;
one or more communication interfaces (503); and
one or more hardware processors (502) coupled to the memory (515) via the one or more communication interfaces (503), wherein the one or more hardware processors (502) are configured by the instructions to:
capture a plurality of knowledge elements associated with a plurality of components, a plurality of faults and a plurality of processes of an industrial plant in a knowledge base, each of the plurality of knowledge elements associated with one of a problem domain and a solution domain corresponding to the problem domain, wherein the solution domain includes tools for the problem domain;
organize the plurality of knowledge elements in a knowledge ontology of the knowledge base using a plurality of ontological meta-models, wherein the plurality of ontological meta-models utilizes a contextual information associated with the industrial plant for organizing the plurality of knowledge elements in the knowledge ontology;
translate the knowledge ontology to an intermediate domain representation of the solution domain, wherein the intermediate domain representation provides a fault detection view of the industrial plant, and wherein to translate the knowledge ontology to the intermediate domain representation, the one or more hardware processors are configured by the instructions to:
identify a set of knowledge elements from amongst the plurality of knowledge elements from the problem domain using a set of semantic queries; -
identify, from a knowledge repository, semantics and syntax of an intermediate solution domain model instance associated with the solution domain;
map the set of knowledge elements identified from the problem domain to the semantics of the intermediate solution domain model instance using a domain specific language (DSL) to generate an intermediate domain model; and
validate the intermediate solution domain model for a plurality of validation parameters using a plurality of validation algorithms; and
translate the intermediate solution domain model to a fault state machine model using a set of translation templates created using one or more model transformation techniques, wherein the fault state machine model comprises a plurality of hierarchical states, and wherein each hierarchal states comprises a set of parallel states enabling tracing of a plurality of fault states at each level of hierarchical state from amongst the plurality of hierarchical states, and wherein the fault state machine model is used for executing and performing fault detection.

6. The system of claim 5, wherein the plurality of hierarchical states of the state machine model comprises one or more of process states, failure states, failure mode states and root cause states.

7. The system of claim 5, wherein the intermediate solution domain model comprises one of a process model, a control system model, an energy flow model, a data model and a storage model.

8. The system of claim 5, wherein the plurality of knowledge elements are captured using a constrained natural language, wherein the constrained natural language populates natural language statements derived from the plurality of sources into a web ontology language (OWL) based ontology, and specifies a plurality of fault detection rules by inferring system state from sensor data associated with the industrial plant.
, Description:FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003

COMPLETE SPECIFICATION
(See Section 10 and Rule 13)

Title of invention:
SYSTEMS AND METHODS FOR KNOWLEDGE DRIVEN FEMA ANALYSIS OF TARGET SYSTEM IN INDUSTRIAL PLANT

Applicant:
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th Floor,
Nariman Point, Mumbai 400021,
Maharashtra, India

The following specification particularly describes the invention and the manner in which it is to be performed.
TECHNICAL FIELD
[001] The disclosure herein generally relates to the field of failure modes and effects analysis (FEMA) for industrial plants, and, more particularly, to systems and methods for knowledge driven fault mode and effect analysis of a target system in an industrial plant.

BACKGROUND
[002] In industrial plants such as power plants, it is crucial to detect and predict potential faults associated with various systems thereof. The detection and prediction of faults require not only the contextual knowledge of the industrial plants, but also knowledge about the various components and processes that are typically deployed in the plants and how they are orchestrated by a control system towards goal achievement.
[003] Typically, fault detection and predictions involve gathering data from the components and processes from the industrial plants and cross checking the data against a predefined ‘model’ of the expected behavior of the plant. However, it is often seen that such predefined expected behavior is formulated manually by experienced domain experts of the plant systems along with the control system engineers based on their experience and understanding of the respective domains. The models are often specified in the form of conditions or rules along with some specification about the implication of the conditions on the plant state and control strategy. Such manual identification and specification of rules and actions are error prone, and is insufficient to determine how foolproof the fault detection and handling strategy is.

SUMMARY
[004] Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems. For example, in one embodiment, a method for knowledge driven fault mode and effect analysis of target system in an industrial plant is provided. The method includes capturing a plurality of knowledge elements associated with a plurality of components, a plurality of faults and a plurality of processes of an industrial plant in a knowledge base via one or more hardware processors. Each of the plurality of knowledge elements are associated with one of a problem domain and a solution domain corresponding to the problem domain, wherein the solution domain includes tools for the problem domain. Further the method includes organizing the plurality of knowledge elements in a knowledge ontology of the knowledge base using a plurality of ontological meta-models, via the one or more hardware processors, wherein the plurality of ontological meta-models utilizes a contextual information associated with the industrial plant for organizing the plurality of knowledge elements in the knowledge ontology. Furthermore, the method includes translating the knowledge ontology to an intermediate domain representation of the solution domain, via the one or more hardware processors, wherein the intermediate domain representation provides a fault detection view of the industrial plant, Translating the knowledge ontology to the intermediate domain representation includes identifying a set of knowledge elements from amongst the plurality of knowledge elements from the problem domain using a set of semantic queries; identifying, from a knowledge repository, semantics and syntax of an intermediate solution domain model instance associated with the solution domain; mapping the set of knowledge elements identified from the problem domain to the semantics of the intermediate solution domain model instance using a domain specific language (DSL) to generate an intermediate domain model; and validating the intermediate solution domain model for a plurality of validation parameters using a plurality of validation algorithms. Moreover the method includes translating the intermediate solution domain model to a fault state machine model using a set of translation templates created using one or more model transformation techniques, via the one or more hardware processors, wherein the fault state machine model comprises a plurality of hierarchical states, and wherein each hierarchal states comprises a set of parallel states enabling tracing of a plurality of fault states at each level of hierarchical state from amongst the plurality of hierarchical states, and wherein the fault state machine model is used for executing and performing fault detection.
[005] In another aspect, a system for knowledge driven fault mode and effect analysis of target system in an industrial plant is provided. The system includes a memory storing instructions, one or more communication interfaces; and one or more hardware processors coupled to the memory via the one or more communication interfaces, wherein the one or more hardware processors are configured by the instructions to capture a plurality of knowledge elements associated with a plurality of components, a plurality of faults and a plurality of processes of an industrial plant in a knowledge base, each of the plurality of knowledge elements associated with one of a problem domain and a solution domain corresponding to the problem domain, wherein the solution domain includes tools for the problem domain. The one or more hardware processors are further configured by one or more instructions to organize the plurality of knowledge elements in a knowledge ontology of the knowledge base using a plurality of ontological meta-models, wherein the plurality of ontological meta-models utilizes a contextual information associated with the industrial plant for organizing the plurality of knowledge elements in the knowledge ontology. The one or more hardware processors are further configured by one or more instructions to translate the knowledge ontology to an intermediate domain representation of the solution domain, wherein the intermediate domain representation provides a fault detection view of the industrial plant, and wherein to translate the knowledge ontology to the intermediate domain representation. To translate the knowledge ontology to an intermediate domain representation of the solution domain, the one or more hardware processors are configured by the instructions to identify a set of knowledge elements from amongst the plurality of knowledge elements from the problem domain using a set of semantic queries; identify, from a knowledge repository, semantics and syntax of an intermediate solution domain model instance associated with the solution domain; map the set of knowledge elements identified from the problem domain to the semantics of the intermediate solution domain model instance using a domain specific language (DSL) to generate an intermediate domain model; and validate the intermediate solution domain model for a plurality of validation parameters using a plurality of validation algorithms. The one or more hardware processors are configured by the instructions to translate the intermediate solution domain model to a fault state machine model using a set of translation templates created using one or more model transformation techniques, wherein the fault state machine model comprises a plurality of hierarchical states, and wherein each hierarchal states comprises a set of parallel states enabling tracing of a plurality of fault states at each level of hierarchical state from amongst the plurality of hierarchical states, and wherein the fault state machine model is used for executing and performing fault detection.
[006] In yet another aspect, a non-transitory computer readable medium for a method for knowledge driven fault mode and effect analysis of target system in an industrial plant is provided. The method includes capturing a plurality of knowledge elements associated with a plurality of components, a plurality of faults and a plurality of processes of an industrial plant in a knowledge base via one or more hardware processors. Each of the plurality of knowledge elements are associated with one of a problem domain and a solution domain corresponding to the problem domain, wherein the solution domain includes tools for the problem domain. Further the method includes organizing the plurality of knowledge elements in a knowledge ontology of the knowledge base using a plurality of ontological meta-models, via the one or more hardware processors, wherein the plurality of ontological meta-models utilizes a contextual information associated with the industrial plant for organizing the plurality of knowledge elements in the knowledge ontology. Furthermore, the method includes translating the knowledge ontology to an intermediate domain representation of the solution domain, via the one or more hardware processors, wherein the intermediate domain representation provides a fault detection view of the industrial plant, Translating the knowledge ontology to the intermediate domain representation includes identifying a set of knowledge elements from amongst the plurality of knowledge elements from the problem domain using a set of semantic queries; identifying, from the knowledge repository, semantics and syntax of an intermediate solution domain model instance associated with the solution domain; mapping the set of knowledge elements identified from the problem domain to the semantics of the intermediate solution domain model instance using a domain specific language (DSL) to generate an intermediate domain model; and validating the intermediate solution domain model for a plurality of validation parameters using a plurality of validation algorithms. Moreover the method includes translating the intermediate solution domain model to a fault state machine model using a set of translation templates created using one or more model transformation techniques, via the one or more hardware processors, wherein the fault state machine model comprises a plurality of hierarchical states, and wherein each hierarchal states comprises a set of parallel states enabling tracing of a plurality of fault states at each level of hierarchical state from amongst the plurality of hierarchical states, and wherein the fault state machine model is used for executing and performing fault detection.
[007] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS
[008] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles:
[009] FIG. 1 illustrates a network implementation of a method for knowledge driven fault mode and effect analysis of target system in an industrial plant according to some embodiments of the present disclosure.
[010] FIGS. 2A-2B illustrates a flow diagram of a method for knowledge driven fault mode and effect analysis of target system in an industrial plant, in accordance with an example embodiment.
[011] FIGS. 3A-3E illustrates an example scenario for method for knowledge driven fault mode and effect analysis of target system in an industrial plant in accordance with some embodiments of the present disclosure.
[012] FIGS. 4A-4D illustrates another example scenario for method for knowledge driven fault mode and effect analysis of target system in an industrial plant in accordance with some embodiments of the present disclosure.
[013] FIG. 5 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS
[014] Various embodiments disclosed herein provides a method and system for systematically capturing domain knowledge about various plant domains in terms of their components and processes. The domain knowledge also includes information about various conditions and rules for detecting component and process failures in the industrial plant (herein after referred to as a ‘plant’).
[015] An intermediate domain specific meta model (for instance a control domain meta model) allows this knowledge to be captured and expressed for a specific context. The intermediate domain specific meta model ensures capturing fault handling information about the context in a correct manner and provides a clear view of how complete the fault handling strategy is from the control system point of view. It allows the fault handling strategies to be validated both by model checking and simulation at the component as well as at the systems level.
[016] Exemplary embodiments are described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the scope of the disclosed embodiments.
[017] Referring now to the drawings, and more particularly to FIG. 1 through 5, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments and these embodiments are described in the context of the following exemplary system and/or method.
[018] FIG. 1 illustrates an example network implementation 100 of a system for knowledge driven fault mode and effect analysis of target system in an industrial plant, in accordance with an example embodiment. In one embodiment, the network implementation 100 includes one or more devices, for example, devices 102-1, 102-2, …102-N (hereinafter referred to as devices 102), a server 104, and a communication network 108. It will be noted herein that the number of devices, illustrated in FIG. 1, is provided for explanatory purposes only. In practice or some example scenarios, there may be additional or fewer devices than those illustrated in FIG. 1. The devices 102 and/or networks of the network implementation 100 may interconnect via wired connections, wireless connections, or a combination of wired and wireless connections over the communication network 108.
[019] In an embodiment, the communication network 108 may be a wireless or a wired network, or a combination thereof. In an example, the communication network 108 can be implemented as a computer network, as one of the different types of networks, such as virtual private network (VPN), intranet, local area network (LAN), wide area network (WAN), the internet, and such. The communication network 108 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), and Wireless Application Protocol (WAP), to communicate with each other. Further, the network 108 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices. The network devices within the network 108 may interact with the server 104 through communication links.
[020] The network environment 100 supports various communication links or connectivity options such as BLUETOOTH®, USB, ZigBee and other cellular services. The network environment enables connection of devices 102 with the server 104, and accordingly with the database 112 using any communication link including Internet, WAN, MAN, and so on.
[021] As discussed above, the system 106 may be implemented in a computing device, such as a hand-held device, a laptop or other portable computer, a tablet computer, a mobile phone, a PDA, a smartphone, and a desktop computer. The system 106 may also be implemented in a workstation, a mainframe computer, a server, and a network server. In an embodiment, the system 106 may be coupled to a knowledge repository, for example, a database 112. The database 112 may store data processed, received, and generated by the system 106. In an alternate embodiment, the system 106 may include the database/ knowledge repository 112. The components and functionalities of the system 106 are described further in detail with reference to FIGS. 2A-6.
[022] FIGS. 2A-2B illustrates a flow diagram of a method 200 for knowledge driven fault mode and effect analysis of target system in an industrial plant, in accordance with an example embodiment. Operations of the flowchart, and combinations of operation in the flowchart, may be implemented by various means, such as hardware, firmware, processor, circuitry and/or other device associated with execution of software including one or more computer program instructions. For example, one or more of the procedures described in various embodiments may be embodied by computer program instructions. In an example embodiment, the computer program instructions, which embody the procedures, described in various embodiments may be stored by at least one memory device of a system and executed by at least one processor in the system. Any such computer program instructions may be loaded onto a computer or other programmable system (for example, hardware) to produce a machine, such that the resulting computer or other programmable system embody means for implementing the operations specified in the flowchart. It will be noted herein that the operations of the method 200 are described with help of system 106. However, the operations of the method 200 can be described and/or practiced by using any other system.
[023] As is understood, failure mode and effect analysis (FMEA) is a systematic method for evaluating a process to identify where and how the process might fail and further to assess a relative impact of different failures, in order to identify the parts of the process that are most in need of change. FMEA process is applied at various industrial plants for analysis and risk assessment of processes and components at the industrial plants. An automated process for knowledge driven FMEA of a target system in an industrial plant is described further with reference to the steps of the flowchart 200 below. Herein, the target system may refer to a system that gets implemented to realize the solution. A target system is a solution to a problem. For example, a thermal power plant is a system which solves the problem of electricity generation, which belongs to the problem domain of energy generation. The target system is implemented using the elements from the solution domain. The solution domain consists of approaches and technologies like state-machines, JavaTM etc.
[024] At step 202, the method 200 includes capturing, in a knowledge repository, a plurality of knowledge elements associated with a plurality of components, a plurality of faults and a plurality of processes of an industrial plant in a knowledge base. For instance, the knowledge may include information about conditions and rules for detecting component and process failures in the plant. In an embodiment, the knowledge may be captured using one or more textual languages that may facilitate in capturing the knowledge about various components and processes in a domain (for instance an industrial plant domain) using a control natural language as well as a domain specific language. Said languages ensure capturing knowledge about components in terms of their capabilities and processes in terms of activity chains. Both the component and processes fault conditions may be captured using these languages.
[025] Each of the plurality of knowledge elements is associated with one of a problem domain and a solution domain corresponding to the problem domain. Here, the solution domain includes tools for the problem domain. For instance, the problem domain may refer to the domain of industrial plants and the solution domain may refer to FMEA.
[026] At step 204, the method 200 includes organizing the plurality of knowledge elements in a knowledge ontology of the knowledge base using a plurality of ontological meta-models. The plurality of ontological meta-models utilizes a contextual information associated with the industrial plant for organizing the plurality of knowledge elements in the knowledge ontology. In an embodiment, the plurality of knowledge elements may be organized in form of (a) components, their properties such as data streams produced by them, commands/responses, events and alarms (b) processes in terms of the sequence of activities which in turn invoke the specific component capabilities used in that context. For example, a control domain specific ontological meta-model may allow the knowledge to be captured and organized for a specific context. Said meta model ensures capturing fault handling information about the context in an appropriate manner and provides a clear view of how complete the fault handling strategy is from the control system point of view. An example of capturing the knowledge with respect to a control structure using a Constrained Natural Language, SADL is shown in FIG. 3A. As illustrated in FIG. 3A, SADL can be used to specify fault detection rules by inferring state of the system from the sensor data. SADL is a generic language which captures knowledge by populating the English-like statements into an web ontology language (OWL) based ontology. In the aforementioned example, SADL is shown to be used to specify fault detection rules by inferring state of the system from the sensor data.
[027] At step 206, the method 200 includes translating the knowledge ontology to an intermediate domain representation of the solution domain. The intermediate domain representation provides a fault detection view of the industrial plant. The disclosed method translates the context specific details of the problem domain (for instance the industrial plant) into a control strategy describing how the faulty conditions are arranged hierarchically. Said translation provides insights into how the faults are dependent on each other, what are their implications on the component and system state, what control actions need to be taken to mitigate the faults, and so on. The process of translating the knowledge ontology to the intermediate domain representation is explained further with reference to steps 208-214.
[028] At step 208, the method 200 includes identifying a set of knowledge elements from amongst the plurality of knowledge elements from the problem domain using a set of semantic queries. The set of semantic queries fetches a set of knowledge elements from the knowledge ontology for a specific given domain such as FMEA. For instance, a semantic query “select element where element is a type of fault”, is a domain query for FMEA domain.
[029] At step 210, the method 200 includes identifying, from the knowledge repository, semantics and syntax of an intermediate solution domain model instance associated with the solution domain. In an embodiment, the identification of the semantics and syntax of an intermediate solution domain model instance is performed by describing the semantics and syntax using a domain specific language. The domain specific language captures the syntax of the intermediate model. The DSL to explicate the solution domain syntax is novel because the same DSL is then processed to translate the knowledge to the intermediate model. Alternatively, semantics and syntax of an intermediate solution domain model instance may be performed by manually explicating said knowledge.
[030] At step 212, the method 200 includes mapping the set of knowledge elements identified from the problem domain to the semantics of the intermediate solution domain model instance using a domain specific language (DSL) to generate an intermediate domain model. Examples of mapping the set of knowledge elements to the semantics of the intermediate solution domain model instance using DSL are described further with reference example scenarios describe in FIGS. 3A-3E, and FIGS. 4A-4D.
[031] At step 214, the method 200 includes validating the intermediate solution domain model for a plurality of validation parameters using a plurality of validation algorithms. The plurality of validation parameters include, but are not limited to, a completeness parameter, a correctness parameter, a semantic validation parameter, and so on. The algorithm for completeness parameter checking if the intermediate domain model is complete. For example, the algorithm checks whether all the knowledge elements present in the domain model. For instance, a control systems model without the elements for state transition is incomplete.
[032] In an example embodiment, the input to the algorithm for correctness check includes Knowledge Elements and Control Systems Meta-Model, and the output is Boolean. At step 1, the Knowledge elements ate translated to control systems model (using algorithm 1):
Algorithm 1 for translating knowledge elements to control systems model
Input: Queries
Output: cntrl_mdl
/* instantiate a new control system model */
set cntrl_mdl ? new ControlModel
for query : Queries do
knowl_ele ? query.execute() // get knowledge elements
for ke : knowl_ele do /* check type of instance */
if ke is a Fault then
if ke is a FaultLevel and ke.level ==0 then
cntrl_mdl.initStates ? new State(ke.name)/* Map lowest level faults to init states */
else
f State ? new State(ke.name) trans ? new StateTransition
trans.rules ? ke.Rules trans.nextStates ? ke.NextFault f State.transitions ? trans cntrl_mdl.states ? f State
if i instanceof SensorData then
cntrl_mdl.data ? ke.sensor_data
return cntrl_mdl
[033] The Control Systems Model is compared against Control Systems Meta-Model for Model Correctness. This depends on what are the embedded correctness checks for the Control Systems Meta-Model. For example, the Control Systems Meta-Model has marked Cyclic State Machines as errors, then any instance Control Systems Model that has cyclic state machines in it’s description is incorrect. Depending on the nature of the problems, validations may change. Below is a generic algorithm to check for any correctness changes.
[034] Algorithm 2: Algorithm for checking correctness changes
Meta-model = Control Systems Meta Model
for element : Control Systems Model
if(element isValid in Meta-model )
continue;
else
return FALSE
return TRUE
[035] The correctness checks can be manual or automated. The correctness can be checked by a correctness algorithm. The correctness algorithm checks if the domain model is correct with respect to the stakeholder views (i.e. solution domain representation). For example, a control system model having a cyclic state transition in it can be incorrect for a control view. An algorithm for the correctness check is as below:
[036] Algorithm 3: Algorithm for completeness check
Input: Knowledge Elements, Control Systems Meta-Model
Output: Boolean
Step 1: Translate Knowledge Elements to Control Systems Model (Algorithm 1)
Step2: Compare Control Systems Model against Control Systems Meta-Model
isComplete = TRUE
for element : Control Systems Meta-Model
if(element isMandatory)
element_instance = Control Systems Model.getElementsOfType(element)
if(element_instance.length == element.mandatoryNumberOfInstances)
continue;
else
return FALSE
return TRUE
[037] The semantic validation parameter can be checked by semantic validation algorithm. The semantic validation algorithm checks whether the domain model is semantically correct with respect to the domain semantics. In an embodiment, the semantic validations may be a combination of correctness and completeness validations.
[038] The semantic validation parameter can be checked by semantic validation algorithm. The semantic validation algorithm checks whether the domain model is semantically correct with respect to the domain semantics.
[039] At step 216, the method 200 includes translating the intermediate solution domain model to a fault state machine model using a set of translation templates created using one or more model transformation techniques. The transformation techniques may include, but is not limited to, Xtend framework. The fault state machine model includes a plurality of hierarchical states such that each hierarchal states includes a set of parallel states enabling tracing of a plurality of fault states at each level of hierarchical state from amongst the plurality of hierarchical states. The fault state machine model is used for executing and performing fault detection. Example scenarios illustrating the method for knowledge driven fault mode and effect analysis of target system in an industrial plant is described further with reference to FIGS. 3A-3E and 4A-4D.
[040] Referring to FIGS. 3A-3E, an example scenario illustrating a method for knowledge driven fault mode and effect analysis of target system in an industrial plant is described. As previously explained, there may be a possibility of capturing wrong, incomplete or inconsistent knowledge with respect to a certain domain (e.g. process, storage, control system etc.) in the knowledge base. To validate the captured knowledge before translating the knowledge into the target implementation platform associated with the solution domain, it is essential to reason the correctness, completeness and consistency with respect to a particular domain view. This can be achieved by mapping the knowledge to domain view molds (domain containers) which convert the knowledge to an intermediate solution domain representation. The intermediate solution domain representation populates an intermediate solution domain representation model instance from the knowledge (or the knowledge elements) so that the intermediate solution domain representation model instance could be subjected to numerous solution domain specific operations such as a) Correctness b) Completeness c) Simulation, d) Model Checking Analysis. The aforementioned solution domain specific operations may be carried out using the tools and/or techniques for the domain models, including, but not limited to, Open ModelicaTM, MatlabTM, DSEPTM, PeacockTM, and so on. Results from these solution domain operations are then studied to decide if the knowledge is captured correctly and satisfies the domain checks. Based on the results, the intermediate solution domain representation model instance may be transformed to a solution domain artefact or the captured knowledge may be modified to satisfy the domain requirements. Examples for implementation of the aforementioned process for multiple solution domains are presented below.
[041] In an example scenario, assuming that the problem domain includes ‘faulty state detection for a diesel generator’. As illustrated in FIG. 3A, the diesel generator component may receive data from physical sensors installed in the industrial plant. The state machine view may include a logic that:
a. RPM is in idle state if the total feed (Physical sensor) = 0 and power consumption by Main Motor (Physical sensor) is < 200KW/hour
b. The diesel generator is not functioning if the total feed (Physical sensor) < 713 and Engine load feedback (Physical sensor) is > 500KW and < 5400KW
[042] The aforementioned knowledge may be captured in form of a plurality of knowledge elements using SADL as shown in FIG. 3A. The captured knowledge is translated to an intermediate solution domain representation, which in this case is a control systems view, as represented in FIG. 3B. In an embodiment, the intermediate solution domain representation includes a control systems view. The control systems manage plant operations to perform device control, data sensing, fault handling, and so on. Translating the knowledge to a control system model enables a validation mechanism for the captured domain knowledge against the control systems domain and vocabulary. Any gap or inconsistency in the translated control system model implies gaps in the knowledge source that needs to get updated accordinglyThe translation of the knowledge to a control system model ensures that the knowledge from which the auto generation of the FMEA solution is being attempted is correct. As is understood, the knowledge may be captured manually by receiving inputs from the experts, and hence is prone to human error. Alternatively, such knowledge may be incomplete. The control system model facilitates in validating said information. Since the CS model is constructed from the knowledge base, while constructing the CS model, it may be determined that all the relevant information is not available in the knowledge base. For example, for a fault mentioned in the knowledge base, any condition/rule may not be specified that can help to detect it.
[043] In the example illustrated in FIG. 3B, the ‘top controller’ is the overall controller for the industrial plant control system. The parent controllers, (i.e. parent controller 1 and parent controller 2) and controllers 1, 2 and 3 may be responsible for operations such as Command-Response, Alarms-Handling, Events-Handling, Data-Handling, State Machine, and so on. Herein, the plurality of knowledge elements are organized in a knowledge ontology of the knowledge base using ontological meta models, for example a control system meta-model illustrated in FIG. 3C. FIG. 3D illustrates an example of translating the translating the knowledge ontology to an intermediate domain representation of the solution domain by identifying a set of knowledge elements from the problem domain (such as engine sensor and load sensor) and mapping the identified knowledge elements to the semantics of the intermediate solution domain model instance (such as data load feedback and data RPM, respectively). Thereafter, validating the intermediate solution domain model for a plurality of validation parameters using a plurality of validation algorithms. As previously described, the validation parameters may include but are not limited to completeness parameter, correctness parameter, semantic validation parameter, and so on. The intermediate solution domain model is then translated to a fault state machine model, as shown in FIG. 3E. In an embodiment, the intermediate solution domain model may be translated to the fault state machine model using Janino JavaTM Code.
[044] Another example of the disclosed method illustrating FMEA for fault tree is described further with reference to FIGS. 4A-4D. FIG. 4A illustrates a process flow for a process of FMEA for fault tree capturing using the knowledge in a knowledge base using multiple rules. Using the knowledge, an intermediate solution domain model instance (which in this case is control systems alarm propagation view) for the process flow is identified, as illustrated in FIG. 4B. The knowledge elements (identified from the problem domain) and the rules are captured using SADL. The knowledge elements are mapped to the semantics of the intermediate solution domain model instance to generate an intermediate domain model, as illustrated in FIG. 4C. The intermediate domain model is validated for various validation parameters and the validated intermediate solution domain model is translated to a fault state machine model using a set of translation templates, as illustrated in FIG. 4D. The translation templates may be obtained using model to model translation frameworks such as Xtend.
[045] FIG. 5 is a block diagram of an exemplary computer system 501 for implementing embodiments consistent with the present disclosure. The computer system 501 may be implemented in alone or in combination of components of the system 106 (FIG. 1). Variations of computer system 501 may be used for implementing the devices included in this disclosure. Computer system 501 may comprise a central processing unit (“CPU” or “hardware processor”) 502. The hardware processor 502 may comprise at least one data processor for executing program components for executing user- or system-generated requests. The processor may include specialized processing units such as integrated system (bus) controllers, memory management control units, floating point units, graphics processing units, digital signal processing units, etc. The processor may include a microprocessor, such as AMD AthlonTM, DuronTM or OpteronTM, ARM’s application, embedded or secure processors, IBM PowerPCTM, Intel’s Core, ItaniumTM, XeonTM, CeleronTM or other line of processors, etc. The processor 502 may be implemented using mainframe, distributed processor, multi-core, parallel, grid, or other architectures. Some embodiments may utilize embedded technologies like application specific integrated circuits (ASICs), digital signal processors (DSPs), Field Programmable Gate Arrays (FPGAs), etc. The processor 502 may be a multi-core multi-threaded processor.
[046] Processor 502 may be disposed in communication with one or more input/output (I/O) devices via I/O interface 503. The I/O interface 503 may employ communication protocols/methods such as, without limitation, audio, analog, digital, monoaural, RCA, stereo, IEEE-1394, serial bus, universal serial bus (USB), infrared, PS/2, BNC, coaxial, component, composite, digital visual interface (DVI), high-definition multimedia interface (HDMI), RF antennas, S-Video, VGA, IEEE 802.11 a/b/g/n/x, Bluetooth, cellular (e.g., code-division multiple access (CDMA), high-speed packet access (HSPA+), global system for mobile communications (GSM), long-term evolution (LTE), WiMax, or the like), etc.
[047] Using the I/O interface 503, the computer system 501 may communicate with one or more I/O devices. For example, the input device 504 may be an antenna, keyboard, mouse, joystick, (infrared) remote control, camera, card reader, fax machine, dongle, biometric reader, microphone, touch screen, touchpad, trackball, sensor (e.g., accelerometer, light sensor, GPS, gyroscope, proximity sensor, or the like), stylus, scanner, storage device, transceiver, video device/source, visors, etc.
[048] Output device 505 may be a printer, fax machine, video display (e.g., cathode ray tube (CRT), liquid crystal display (LCD), light-emitting diode (LED), plasma, or the like), audio speaker, etc. In some embodiments, a transceiver 506 may be disposed in connection with the processor 502. The transceiver may facilitate various types of wireless transmission or reception. For example, the transceiver may include an antenna operatively connected to a transceiver chip (e.g., Texas Instruments WiLink WL1283, Broadcom BCM4750IUB8, Infineon Technologies X-Gold 618-PMB9800, or the like), providing IEEE 802.11a/b/g/n, Bluetooth, FM, global positioning system (GPS), 2G/3G HSDPA/HSUPA communications, etc.
[049] In some embodiments, the processor 502 may be disposed in communication with a communication network 508 via a network interface 507. The network interface 507 may communicate with the communication network 508. The network interface may employ connection protocols including, without limitation, direct connect, Ethernet (e.g., twisted pair 10/100/1000 Base T), transmission control protocol/internet protocol (TCP/IP), token ring, IEEE 802.11a/b/g/n/x, etc. The communication network 508 may include, without limitation, a direct interconnection, local area network (LAN), wide area network (WAN), wireless network (e.g., using Wireless Application Protocol), the Internet, etc. Using the network interface 507 and the communication network 508, the computer system 501 may communicate with devices 509 and 510. These devices may include, without limitation, personal computer(s), server(s), fax machines, printers, scanners, various mobile devices such as cellular telephones, smartphones (e.g., Apple iPhone, Blackberry, Android-based phones, etc.), tablet computers, eBook readers (Amazon Kindle, Nook, etc.), laptop computers, notebooks, gaming consoles (Microsoft Xbox, Nintendo DS, Sony PlayStation, etc.), or the like. In some embodiments, the computer system 501 may itself embody one or more of these devices.
[050] In some embodiments, the processor 502 may be disposed in communication with one or more memory devices (e.g., RAM 513, ROM 514, etc.) via a storage interface 512. The storage interface may connect to memory devices including, without limitation, memory drives, removable disc drives, etc., employing connection protocols such as serial advanced technology attachment (SATA), integrated drive electronics (IDE), IEEE-1394, universal serial bus (USB), fiber channel, small computer systems interface (SCSI), etc. The memory drives may further include a drum, magnetic disc drive, magneto-optical drive, optical drive, redundant array of independent discs (RAID), solid-state memory devices, solid-state drives, etc. Variations of memory devices may be used for implementing, for example, any databases utilized in this disclosure.
[051] The memory devices may store a collection of programs or database components, including, without limitation, an operating system 516, user interface application 517, user/application data 518 (e.g., any data variables or data records discussed in this disclosure), etc. The operating system 516 may facilitate resource management and operation of the computer system 501. Examples of operating systems include, without limitation, Apple Macintosh OS X, Unix, Unix-like system distributions (e.g., Berkeley Software Distribution (BSD), FreeBSD, NetBSD, OpenBSD, etc.), Linux distributions (e.g., Red Hat, Ubuntu, Kubuntu, etc.), IBM OS/2, Microsoft Windows (XP, Vista/7/8, etc.), Apple iOS, Google Android, Blackberry OS, or the like. User interface 517 may facilitate display, execution, interaction, manipulation, or operation of program components through textual or graphical facilities. For example, user interfaces may provide computer interaction interface elements on a display system operatively connected to the computer system 501, such as cursors, icons, check boxes, menus, scrollers, windows, widgets, etc. Graphical user interfaces (GUIs) may be employed, including, without limitation, Apple Macintosh operating systems’ Aqua, IBM OS/2, Microsoft Windows (e.g., Aero, Metro, etc.), Unix X-Windows, web interface libraries (e.g., ActiveX, Java, Javascript, AJAX, HTML, Adobe Flash, etc.), or the like.
[052] In some embodiments, computer system 501 may store user/application data 518, such as the data, variables, records, etc. as described in this disclosure. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as Oracle or Sybase. Alternatively, such databases may be implemented using standardized data structures, such as an array, hash, linked list, structured text file (e.g., XML), table, or as hand-oriented databases (e.g., using HandStore, Poet, Zope, etc.). Such databases may be consolidated or distributed, sometimes among various computer systems discussed above. It is to be understood that the structure and operation of any computer or database component may be combined, consolidated, or distributed in any working combination.
[053] Additionally, in some embodiments, (the server, messaging and instructions transmitted or received may emanate from hardware, including operating system, and program code (i.e., application code) residing in a cloud implementation. Further, it should be noted that one or more of the systems and methods provided herein may be suitable for cloud-based implementation. For example, in some embodiments, some or all of the data used in the disclosed methods may be sourced from or stored on any cloud computing platform.
[054] The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims.
[055] Various embodiments disclosed herein provides method and system for knowledge driven fault mode and effect analysis of target system in an industrial plant. Conventionally, much of the fault detection and predictions involve gathering data from the components and processes from the plants and cross checking that against a predefined ‘model’ of the expected behavior of the plant. However, it is mostly seen that this predefined expected behavior is formulated manually by experienced domain experts of the plant systems along with the control system engineers based on their experience and understanding of the respective domains. The models are often specified in the form of conditions or rules along with some specification about the implication of the conditions on the plant state and control strategy. Such manual identification and specification of rules and actions are error prone and does not give a good idea in terms of how full proof is the fault detection and handling strategy.
[056] The embodiments of present disclosure herein address unresolved problem of manually gathering the knowledge, for instance, to build an FMEA solution for an industrial plant such as power plant, which is a time consuming and effort intensive process. The embodiments provide systematic approach towards capturing domain knowledge about various plant domains in terms of their components and processes, and thus auto generates an FMEA solution for industrial plants.
[057] As a first step, the disclosed system capture knowledge of a system that solves a problem in the problem domain. In order to generate energy, thermal power plants are used, hence in order to auto generate FMEA solutions for thermal power plants, knowledge regarding thermal power plants, its components, data streams they produce, faults that they can generate, how to infer the faults by utilizing rules and conditions on the data streams, identification of rules and conditions and so on, are captured. The disclosed system facilitates in automatically generating the FMEA solution from the captured knowledge in a two-step translation process. As a first step, the correct elements are extracted from the knowledge graph to populate a control system model. Capturing of the knowledge allows to make sure that the information that is required to build an FMEA solution has been correctly captured in the knowledge repository. The control system model serves as a representation that can be validated by using various reasoning tools and techniques.
[058] The control system model is then translated into an FMEA solution in a subsequent step. As is understood, typically FMEA solutions are handwritten in code in C++, Python, Java etc. The disclosed system however translates the model into the representation of a state machine instead of translating our control system model into code in Java/C++ etc. The disclosed system may use the off-the shelf SCXML format to translate the control system model into SCXML state machine representation, generate the FMEA. This makes the generated SCXML format to be also continuously validated, monitored, checked and visualized automatically.
[059] It is to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g., any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g., hardware means like e.g., an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g., an ASIC and an FPGA, or at least one microprocessor and at least one memory with software processing components located therein. Thus, the means can include both hardware means and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g., using a plurality of CPUs.
[060] The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various components described herein may be implemented in other components or combinations of other components. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[061] The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
[062] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
[063] It is intended that the disclosure and examples be considered as exemplary only, with a true scope of disclosed embodiments being indicated by the following claims.