ijcccv11n4.dvi INTERNATIONAL JOURNAL OF COMPUTERS COMMUNICATIONS & CONTROL ISSN 1841-9836, 11(4):507-521, August 2016. An Ontology to Support Semantic Management of FMEA Knowledge Z. Rehman, C. V. Kifor Zobia Rehman* 1. Faculty of Engineering and Management Lucian Blaga University of Sibiu, Romania 2. Department of Computer Science COMSATS Institute of Information Technology, Abbottabad, Pakistan *Corresponding author: zobia.rehman@gmail.com Claudiu V. Kifor Faculty of Engineering and Management Lucian Blaga University of Sibiu, Romania claudiu.kifor@ulbsibiu.ro Abstract: Risk mitigation has always been a special concern for organization’s strategic management. Various tools and techniques have been developed to manage risk in an effective way. Failure Mode and Effects Analysis (FMEA) is one of the tools used for effective assessment of risk. It analyzes all potential failure modes, their causes, and effects on a product or process. Moreover it recommends actions to mitigate failures in order to enhance product reliability. Organizations spend their resources and domain experts make their efforts to complete this analysis. It further helps organizations identify the expected risks and plan strategies in advance to tackle them. But unfortunately the analysis produced after spending a lot of organizational assets and experts’ struggles, is not reusable due to its natural language text based description. Information and communication technology experts proposed some so- lutions but they are associated with some deficiencies. Authors in [13] proposed an ontology based solution to extract and reuse FMEA knowledge from the textual doc- uments, and this article is the first step towards its implementation. In this article we proposed our ontology for Process Failure Mode and Effects Analysis (PFMEA) for automotive domain, along with its implementation, reasoning, and data retrieval through it. Keywords: Ontology, FMEA, Knowledge Management, OWL, Protégé, SPARQL. 1 Introduction Since ever we have been managing our knowledge as best as we could. In beginning the acquisition and storage of knowledge were the biggest issues but Information Technology turned the tables and now just one click on Google search button brings us pools of knowledge we de- sire. Ordinary gadgets can store Gigabyte to Terabytes of information and cloud storage offers access to logical storage of a physical storage spanning over multiple locations. On one hand these advances in technology are making storage and acquisition of knowledge easier and on the other hand it has become awfully essential for organizations to capture, store, apply and share their knowledge in a collective and systematic way, so they could survive and flourish in this knowledge based economy era. Thus the knowledge management has become a dire need of organizations and industry. They need to structure their knowledge and transform it into valuable competencies, products, and services for effective and well-timed utilization in order to make fruitful decisions. Risk management for an organization is a set of strategic level activities that maximizes the chances of objectives being achieved, by systematically understanding and Copyright © 2006-2016 by CCC Publications 508 Z. Rehman, C. V. Kifor evaluating the project level risks. It has become a core part of organization’s strategic manage- ment. Organizations spent the significant share of their investments in handling expected and unexpected risks on a project. Risk management is a process of risk identification, risk assess- ment, risk response and control development [6]. Risk assessment is a critical phase after risk identification as outcome of this phase leads to develop appropriate response and control for a risk. There are different tools available for risk assessment, e.g., scenario analysis for event prob- ability and impact, risk assessment matrix, FMEA, probability analysis, and semi-quantitative scenario analysis. FMEA is a systematic tool to assess the risks associated to a product or process. It highlights all potential failure modes and their impacts on a product in advance so that they could be fixed timely in order to achieve desired goals. In 1960’s for the very first time aerospace industry brought it into use during Apollo mission. In 1974, the US Navy de- veloped MIL-STD-1629 about its use. Since late 1970’s, it is in use in automotive industry for safety and reliability analysis. Nowadays this inductive reasoning tool is extensively being used in almost every engineering sector [14]. It finds all possibilities in which a product or process might go wrong (failure modes), determines the effect(s) of each failure mode along with sever- ity, cause(s) of failure mode along with frequency(occurrence) and also the level of difficulty in order to detect a failure (detection). Further it calculates the Risk Priority Number (RPN) by multiplying magnitude values of severity, occurrence, and detection. Depending on the value of RPN, recommendations are determined and executed along with newly predicted values of severity, occurrence, detection, and RPN [15]. The knowledge produced during the process of Figure 1: Conceptual architecture of ontology based knowledge management system for FMEA [13] FMEA is really valuable. If it is adequately managed and re-utilized, it can reduce cost and ef- fort. Although organizations spend huge cost and effort to apply FMEA method but knowledge acquired during this analysis is neither reused nor shared. Since it is not semantically organized, its interpretation varies from person to person and from situation to situation. It is usually found incomplete but larger in size due to its redundant production and that larger size makes it imprecise as well [9]. Artificial Intelligence proposed different solutions for this problem, e.g., rule based expert systems, case based reasoning, and knowledge based systems with ontological support. Among all these, knowledge based systems with ontological support are found most appropriate as rule based systems are not suitable if domain knowledge is larger enough, because An Ontology to Support Semantic Management of FMEA Knowledge 509 Table 1: FMEA Worksheet [16] Process Failure Mode and Effects Analysis FMEA Number: Team Leader: Process Responsibility: Prepared By: FMEA Date (Orig.): FMEA Date (Rev.): Process Name Potential Failure Mode Effect(s) of Failure SEV Causes OCC Current Controls DET RPN Recom. Action Resp.& Comp. By Action Result Prevention Detection Action SEV OCC DET NRPN its coding, verification, validation, maintenance, and inference through it becomes complex and time consuming [2]. In case based reasoning all probable cases are stored in case library with additional overhead of their attributes and references, moreover the information returned by such engines is not well formatted [8]. Available ontology based approaches to support FMEA also lack some significant aspects, e.g., in (Lee, 2001) authors presented FMEA only as a conceptual model without any inference and rules. Authors in [1] considered the discrepancies left by [7] and proposed a system, based on the combination of knowledge management and quality man- agement concepts but it lacks functional taxonomy. In [10] authors discussed a better ontology based approach for FMEA procedure representation in lead free soldering but this proposal is still being worked on. Moreover no specific ontology is found to address the FMEA knowledge sharing and reuse for automotive domain. To address all these issues authors in [13] presented a conceptual architecture of their proposed system as given in figure 1 and this article in first step towards its implementation. This article is about the ontology we developed for representation and retrieval of PFMEA knowledge. Knowledge of interest used in this ontology is from automo- tive domain. Automotive engineering (vehicle engineering)deals with the design, manufacturing, and operation of vehicles(automobiles, buses, motorcycles etc.). It assimilates various compo- nents from different engineering sectors, e.g., mechanical, electrical, electronics, software, safety and quality engineering. From designing to production there are different kind of activities (be- longing to different fields of engineering)are involved. Productivity of each activity heavily relies on past experiences, expertise of concerned people, and customer feedback. Better management of all this knowledge helps organizations improve time to market and customer satisfaction which not only helps earn better profit but brings sustainability for an organization in the market. In section 2 and 3, tools used to develop and query the ontology, are discussed. Section 4 describes the process of ontology development in detail, section 5 illustrates some query examples, and section 6 concludes the discussion with highlights of future work. 2 Protégé Protégé is an open source software tool by Stanford University to develop domain models and knowledge based systems with ontology. It facilitates with both of the foremost means to model an ontology, e.g., frames and OWL (Web Ontology Language). It has built-in reasoning sup- port for computing the inferred ontology class hierarchy and ontology consistency checking [13]. We used Protégé 5.0 beta version. Using it we developed our OWL ontology with RDF/XML format. RDF/XML format is a syntax defined by W3C to present RDF (Resource Description Format) graph by defining triples of subject, predicate, and object in XML (EXtensible Markup Language) format [12]. We developed ontology in OWL, the language beyond RDF schema that allows machines to perform more useful reasoning on its documents, and created its individuals (instances) in RDF. We got reasoning support from Protégé’s built-in reasoner HermiT version 1.3.8.3. HermiT is an efficient reasoner based on “hypertableau”calculus that takes a few seconds to reason complex ontologies that are written in OWL. It reads an OWL file and determines the consistency of classes and their properties [4] 510 Z. Rehman, C. V. Kifor Figure 2: PFMEA ontology 3 SPARQL and Jena Fuseki Server Jena is an open source Semantic Web framework for Java. It facilitates with an API (Appli- cation Program Interface) for extraction and writing data to/from RDF graphs. The graphs are represented as an abstract model, which can be sourced with data from files, databases, URLs or a combination of these. Fuseki is an http interface to RDF data that supports SPARQL (W3C recommended language to query directed labeled RDF graphs) for querying and updating RDF graphs. We used Apache Jena Fuseki server version 1.1.0. It provides REST-style SPARQL HTTP Update, SPARQL Query, and SPARQL Update by using the SPARQL protocol over HTTP [5]. It can be freely downloaded and runs on port 3030 in web browser. 4 Development of FMEA ontology According to classic definition by [3] the ontology is an explicit specification of conceptualiza- tion. In information science perspective the ontology is a formal representation of the knowledge of a specific domain as a set of concepts within a domain, and the relationship between those concepts. It provides shared vocabulary and common (unambiguous) understanding of a domain and supports reasoning about the concepts. According to W3C definition, ontology is a vocabu- lary that defines concepts, relationship between concepts, and constraints on their usage in order to define and represent domain of discourse [11]. An ontology consists of different components, e.g., classes, properties (relationship of classes), and individuals (instances of the domain of dis- course). In this section all these terms will be discussed in PFMEA perspective. In table 1 a PFMEA worksheet is shown. Using the PFMEA attributes given in that worksheet we designed an ontology given in figure 2. This ontology is based on five different classes whereas all these classes are logically subsumed An Ontology to Support Semantic Management of FMEA Knowledge 511 Figure 3: PFMEA classes and sub-classes in Protégé sub-classes of the root concept “Thing”. According to ISO-15926 “Thing”is a top-level ontology (collection of general concepts same in all knowledge domains) that subsumes abstract object and possible individual classes. Any immaterial object (which exists only as a concept) can be said an abstract object, e.g., information; and any material object (which exists in time and space) is known as possible individual, e.g., a pen. Figure 4: OntoGraph in Protégé Rest of the classes, their attributes with data types, and relationships with one another are described following. • FMEA class represents the header information of FMEA worksheet. Its attributes are FMEA_No (string), FMEA_description (string), process_leader (string), starting_date (dateTime), ending_date (dateTime), and latest_revision_date (dateTime). Object 512 Z. Rehman, C. V. Kifor property examine (inverse: isExaminedBy) connects FMEA class to Process class. • Process class describes a process or a sub-process under analysis. It has a single attribute process_name (string). Object property hasSubProcess connects it to itself, whereas the property hasFailureMode (inverse: isFailureModeOf) connects it to class Failure_mode. • Failure_mode class represents a failure mode, its cause(s) and effect(s). It has three at- tributes failuremode_description (string), effect_description (string) for sub-concept Effect, and cause_description (string) for sub-concept Cause. Different object proper- ties are part of the concept Failure_mode. The hasControlMethod (inverse: isControl- MethodOf) connects it to class Control_method, hasMitigationAction (inverse: isMiti- gationActionOf) connects it to concept Mitigation_action, it is related to class RPN through property hasRPN (inverse: isRPNOf). As a failure causes another failure and inversely a failure is the effect of another failure, therefore the concept Failure_mode is divided into two sub-concepts Cause and Effect. Object properties causes and isCausedBy (inverse of one another) make it distinguished if a failure is a cause or an effect. A failure that demonstrates root cause nature is only responsible to bear the relation with concepts Control_method, Mitigation_action and RPN. • RPN class represents the magnitude impacts of a failure mode, its effect and analysis. Its attributes are severity (integer), occurrence (integer), detection (integer), and their product (integer). • Control_method class describes the controls for detection and prevention of a failure. It has two attributes control_detection (string) and control_prevention (string). • Mitigation_action class describes recommendations and actions taken in order to combat a failure. Its attributes are recommended_action (string), responsible_person (string), target_completion_date (dateTime), and action_taken (string). Object property has- NewRPN (inverse: isNewRPNOf) relates it to the concept RPN and on the basis of new RPN value effectiveness of a mitigation action is evaluated. Figure 5: Object properties in Protégé An Ontology to Support Semantic Management of FMEA Knowledge 513 Figure 4 represents the ontology graph (OntoGraph) of proposed ontology as perceived in Pro- tégé. In figure 5, Protégé is displaying the list of object properties. Each object property is a sub-property of topObjectProperty. Each property connects two classes, known as domain and range. For example the object property hasFailureMode connects two classes the Process and the Failure_mode. It is a relationship from Process to Failure_mode, thus the concept Process is domain of the property and concept Failure_mode is its range. Its inverse property isFailure- ModeOf would be a relation from concept Failure_mode to concept Process. Figure 6 shows the list of data properties, each data property is sub-property of topDataProperty. Data properties are attributes of class which are further used to create variables of instances in order to store some values. Each data property has a domain (the class name it belongs to) and a range (the data type, the type of data it allows to be stored). For example action_taken is an attribute of the concept Mitigation_action and its assertions can have only String data type. Figure 6: PFMEA data properties in Protégé Figure 7 shows an inferred individual of concept Cause in Protégé. It clearly shows that a failure mode is caused by a cause and it further causes an effect, consequently any cause which causes a failure mode is actually responsible for its effect too. Figure 8 shows an instance of concept Effect. Figure 9 is also about an inferred individual of concept Mitigation_action. In figure 10 a complete FMEA ontology instance is shown. Whereas figure 11 shows a few instances of FMEA ontology in RDF form. 5 SPARQL queries to retrieve FMEA information from ontology We used SPARQL with Apache Jena Fuseki server in order to access information from our ontology. Jena Fuseki server provides user friendly Graphical User Interface (GUI) to mount ontologies on server and allows retrieving query results in multiple formats. We chose CSV (Comma-Separated Values) format as original FMEA files are in the same format. Query results in CSV format can be downloaded and saved for further use and can be easily viewed in any CSV viewer. Here are some queries used to extract information from ontology. 514 Z. Rehman, C. V. Kifor Figure 7: PFMEA instances of a sub-class cause in Protégé Figure 8: PFMEA instances of a sub-class effect in Protégé An Ontology to Support Semantic Management of FMEA Knowledge 515 Figure 9: PFMEA instances of a sub-class mitigation_action in Protégé Figure 10: Example of ontology based FMEA instances 516 Z. Rehman, C. V. Kifor Figure 11: Example of an FMEA ontology instance in RDF 5.1 Prefixes Following prefixes are a must for the queries to execute on Jena Fuseki sever, these are used to declare the ontology being used, the language it is developed in and its syntax and schema. PREFIX owl: PREFIX xsd: PREFIX rdf: PREFIX rdfs: PREFIX fmea: 5.2 Query to display FMEA worksheet header information SELECT (STR(?fno) as ?FMEA_No) (STR(?fd) as ?FMEA_Description) (STR(?pl) as ?Pro- cessLeader) (STR(?sd) as ?StartingDate) (STR(?ed) as ?EndingDate) (STR(?ld) as ?LatestRevisionDate) WHERE { ?x fmea:FMEA_No ?fno; fmea:FMEA_description ?fd; fmea:process_leader ?pl; fmea:starting_date ?sd; fmea:ending_date ?ed. OPTIONAL { ?x fmea:latestrevision_date ?ld. } } An Ontology to Support Semantic Management of FMEA Knowledge 517 Output of this query is shown in figure 12. This query helps know very basic information about an FMEA report. For example the description of the process the report is about, its leader,and all important dates about its initiation, completion, and revision. Figure 12: FMEA worksheet header information in CSV viewer 5.3 Query to display complete details of FMEA process SELECT (STR(?pn) as ?Process) (STR(?fmd) as ?FailureMode) (STR(?ed) as ?Effect) (STR(?sv1) as ?SEV) (STR(?cd) as ?Cause) (STR(?oc1) as ?OCC) (STR(?cp) as ?CtrlPrevention) (STR(?cdt) as ?CtrlDetection) (STR(?d1) as ?DET) (STR(?p1) as ?RPN) (STR(?ra) as ?RecommendedAc- tion)(STR(?at) as ?ActionTaken) (STR(?rp) as ?Responsible) (STR(?tcd) as ?TargetComplet- edBy) (STR(?sv2) as ?PSEV) (STR(?oc2) as ?POCC) (STR(?d2) as ?PDET) (STR(?p2) as ?PRPN) WHERE { ?x fmea:process_name ?pn; fmea:hasFailureMode ?fm. ?fm fmea:failuremode_description ?fmd; fmea:causes ?failureEffect; fmea:isCausedBy ?failureCause. ?failureEffect fmea:effect_description ?ed. ?failureCause fmea:cause_description ?cd; fmea:hasControlMethod ?ctrlMethod; fmea:hasRPN ?RPN1; fmea:hasMitigationAction ?mgt. ?ctrlMethod fmea:control_detection ?cdt; fmea:control_prevention ?cp. ?RPN1 fmea:severity ?sv1; fmea:occurrence ?oc1; fmea:detection ?d1; fmea:product ?p1. ?mgt fmea:recommended_action ?ra; fmea:action_taken ?at. OPTIONAL { ?mgt fmea:responsible_person ?rp; fmea:target_completiondate ?tcd; fmea:hasNewRPN ?RPN2. ?RPN2 fmea:severity ?sv2; fmea:occurrence ?oc2; 518 Z. Rehman, C. V. Kifor fmea:detection ?d2; fmea:product ?p2. } } Result was spanning over large window this is why we split it into three as shown in figure 13, 14, and 15. Purpose of this query is to extract all information related to a process. For example its probable failure modes, their causes and effects,magnitude impact of the failure, recommendations and actions taken to reduce impact of failure and the magnitude impact of mitigation made. Figure 13: FMEA Process details in CSV Viewer Figure 14: FMEA Process details in CSV Viewer Figure 15: FMEA Process details in CSV Viewer 5.4 Query to display causes and recommendations for each failure mode SELECT (STR(?fmd) as ?FailureMode) (STR(?cd) as ?Cause) (STR(?ra) as ?RecommendedAc- tion) WHERE { ?fm fmea:failuremode_description ?fmd; fmea:isCausedBy ?failureCause. ?failureCause fmea:cause_description ?cd; fmea:hasMitigationAction ?mgt. ?mgt fmea:recommended_action ?ra; fmea:action_taken ?at. } An Ontology to Support Semantic Management of FMEA Knowledge 519 Output of this query is shown in figure 16. This query helps extract all causes and recom- mendation for each cause for a specific failure mode. Figure 16: Causes and recommendations for each failure mode in CSV Viewer 5.5 Query to display causes, effects and recommendations for a specific fail- ure mode SELECT (STR(?cd) as ?Cause) (STR(?at) as ?ActionTaken) (STR(?sv2) as ?NewSeverity) (STR(?oc2) as ?NewOccurrence) (STR(?d2) as ?NewDetection) (STR(?p2) as ?NewRPN) WHERE { ?x fmea:hasFailureMode ?fmd. ?fmd fmea:failuremode_description ?fd. FILTER regex(?fd,"Insufficient wax coverage over specified surface") ?fmd fmea:isCausedBy ?failureCause. ?failureCause fmea:cause_description ?cd; fmea:hasMitigationAction ?mgt. ?mgt fmea:action_taken ?at. OPTIONAL { ?mgt fmea:responsible_person ?rp; fmea:target_completiondate ?tcd; fmea:hasNewRPN ?RPN2. ?RPN2 fmea:severity ?sv2; fmea:occurrence ?oc2; fmea:detection ?d2; fmea:product ?p2. } } Output of this query is shown in figure 17. This query extracts causes, mitigation actions, and their magnitude impacts for a given failure mode. Figure 17: Causes and mitigation action(s) for a specific failure mode in CSV viewer 520 Z. Rehman, C. V. Kifor 6 Conclusion and future work Nowadays risk management has become a vital part of an organization’s strategic manage- ment. To achieve the organizational objectives it is mandatory to increase the probability of success and decrease the probability of failure for a product or process. It is only possible when an organization knows about all expected risks and has planed policies and actions for its timely avoidance and mitigation. FMEA is one of the tools available for risk assessment. Because of its effectiveness organizations spend a lot to complete its studies. Due to some reasons as mentioned in introduction section, the valuable information produced by FMEA is not reusable. To com- bat this problem authors in [13] proposed a system which would be capable enough to extract information from FMEA documents, store it in a knowledge repository, and help retrieving the required information. In this article we presented an important component of that proposed sys- tem, the ontology and retrieval of information through it. As we want to develop a system which should be capable of disseminating information in a domain of experts unambiguously, for this we need a common vocabulary, understanding and structure of the specified domain knowledge, machine interpret-able descriptions of concepts and their relations, and a barrier between domain knowledge and operational knowledge; therefore we developed and FMEA ontology that qualifies all these specifications. This article not only presents the ontology but also the semantic ways to retrieve information through it. Our next step is to use this ontology for auto-population of a knowledge base from CSV format FMEA worksheets and then we will measure its effectiveness (in terms of completeness and conciseness) by deploying it, so that domain experts could interact with it for required knowledge. Bibliography [1] Dittmann, L. et al (2004); Performing FMEA using ontologies, 18th international workshop on qualitative reasoning, 209-216. [2] Fernandez, B.I.; Saberwal, R. (2010); Knowledge Management: Systems and Processes, M.E. Sharpe. [3] Gruber, T. R. (1993); A translation approach to portable ontology specifications, Knowledge Acquisition, 5(2): 199-220. [4] Horrocks, I. et al (2012); The HermiT OWL Reasoner, emphOWL Reasoner Evaluation Workshop, Manchester. [5] http://jena.apache.org/documentation/serving_data/ [6] Larson, E. W.; Gray, C. F. (2011); Project Management: The Managerial Process, 5th Edi- tion, McGraw Hill. [7] Lee, C.F.; (2001); Using FMEA models and ontologies to build diagnostic models, Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 281-293. [8] Mansouri, D.; Hamdi-Cherif, A. (2011); Ontology-oriented case-based reasoning (CBR) ap- proach for training adaptive delivery, 15th WSEAS Int. Conf. on Computers (CSCC’11), 328-333. [9] Mikos, W.L. et al (2011); A system for distributed sharing and reuse of design and manufac- turing, Elsevier Journal of Manufacturing Systems, 133-143. An Ontology to Support Semantic Management of FMEA Knowledge 521 [10] Molhanec, M. et al (2010); The Ontology based FMEA of Lead Free Soldering Process, Inter- national Spring Seminar on Electronics Technology - ISSE, DOI: 10.1109/ISSE.2009.5206998, 1-4. [11] http://www.w3.org/standards/semanticweb/ontology [12] http://www.w3.org/TR/rdf-syntax-grammar/ [13] Rehman, Z.; Kifor, S. (2014); A Conceptual Architecture Of Ontology Based KM System For Failure Mode And Effects Analysis, International Journal of Computers Communications & Control, 9(4): 463-470. [14] Stamatis, D.H. (2003); Failure mode and effect analysis: FMEA from theory to execution, USA: ASQ Quality Press. [15] Tay, K. M.; Lim, C. P. (2006); Fuzzy FMEA with a guided rules reduction system for prioritization of failures. International Journal of Quality & Reliability Management , 23(8): 1047 - 1066. [16] Wheeler, D. J.; Chamber, D. S. (2013); Understanding Statistical Process Control Wheeler and Chambers, 3rd Edition, SPC Press.