# A Data-Knowledge Hybrid Driven Method for Gas Turbine Gas Path Diagnosis
## 4 Non-operational consequence, which only involves the economic loss in repair costs.
### Development of Ontology Model and Diagnosis Reasoning  
In this section, the ontology model is developed based on the extracted fault diagnosis knowledge. The fault diagnosis ontology model is constructed using Protege 5.5 software. As an excellent ontology model construction tool, Protege 5.5 has both application types of GUI and API interface and can construct _Class_, _Property_, _Individual_, and _Rule_[36].  
Figure 11: Maintenance logic decision diagram.  
Figure 12 demonstrates the fault diagnosis ontology model and the reasoning rules in Protege 5.5. Figure 12A shows the developed fault diagnosis ontology model. The classes of _FaultCriteria_, _FMCA_, and _MaintenanceAnalysis_ are built first. Then, the corresponding sub-classes are constructed to formalize the basic concepts of the fault diagnosis knowledge. Furthermore, the individuals and object properties are created in sequence to represent the fault knowledge. Figure 12B shows the hierarchical structure of the developed classes and sub-classes using the _OntoGraf_ plug-in [37]. As shown in Figure 12B, the _FaultCriteria_ class has the sub-classes of _FeatureCriteria_ and _FaultMode_. Finally, the mapping rule and five diagnosis reasoning rules are also encoded in the Protege 5.5, as shown in Figure 12C.  
Figure 13 demonstrates the reasoning process of the fault diagnosis ontology model. Firstly, the mapping rule with \(DG_{\textit{ref}}=1\%\) and \(DE_{\textit{ref}}=5\%\) (generated in Section 4.3) is triggered to identify the corresponding _FeatureCriteria_ individual. As a result, the _FCta_comp_003_ is identified, and its data property _hasHappened_ is modified to \"_true_\".  
Figure 12: Fault diagnosis ontology and rule base. (**A**) Fault diagnosis ontology; (**B**) Ontology hierarchy structure; (**C**) Rule base.  
Figure 13: Reasoning results with the fault diagnosis ontology model.  
Next, the _FaultMode_ individual of _FMAd_comp_003_ (_compressor foreign object damage_) is reasoned out by rule 1, with the object property of _FCTA_has_FMA_ in the _FeatureCriteria_ individual. The data property of _hasHappened_ in _FMAd_comp_003_ is also set to \"_true_\" by rule 1.  
After identifying the FMAd_comp_003, rule 2 is triggered to reason out the fault information, such as FE_comp_003 (FaultEffect), FCFi_comp_003 (FaultCriticality: \"High\"), FDet_comp_003 (FaultDetectability: \"YES\"), FCon_comp_003 (FaultConsequence: \"Operational\"). The reasoning results show that the local effect corresponding to FMAd_comp_003 is \"Reducing compressor efficiency sharply,\" the higher-level effect is \"Causing damage on compressor, combustor, and turbine, Reducing compressor power consumption\", and the system effect is \"Reducing system economy and lifetime\". The reasoning results are consistence with the FMECA knowledge in Table 5, which proves that the developed fault diagnosis ontology model is effective to represent the FMECA knowledge.  
Rule 3 is triggered with the input of _FE_comp_003_. The fault location _FL_comp_001_ is reasoned out to locate the fault effects on different physical structure levels. The data properties (_Component: \"compressor blades\"_, _Subsystem: \"compressor\"_, _System: \"Gas turbine gas path system\"_) of _FL_comp_001_ are reasoned out.  
Rule 4 reasons out the maintenance strategy FMs_comp_001 (\"condition-based maintenance\") with the input of FDet_comp_003, FCFi_comp_003, and FCon_comp_003.  
Rule 5 reasons out the maintenance priority _FMP_comp_001_ (\"_high_\") with the input of _FCri_comp_003_. Therefore, the maintenance priority of the \"_compressor foreign object damage_\" fault mode is \"_high_\".