An Ontology-based Validation Approach to Resolve Conflicts in Manufacturing Design Process Kazunari Hashimoto, Motoyuki Takaai, Yohei Yamane, Seiji Suzuki, Masao Watanabe, and Hiroshi Umemoto Research and Technology Group, Fuji Xerox Co., Ltd. 6-1 Minatomirai, Nishi-ku Yokohama-shi Kanagawa 220-8668 Japan {Kazunari.Hashimoto,Motoyuki.Takaai,Yohei.Yamane, Seiji.Suzuki,Masao.Watanabe,Hiroshi.Umemoto}@fujixerox.co.jp Abstract. In design process of manufacturing, designers analyze the factor of phenomena and apply solutions to phenomena (such as resiz- ing, changing electrical circuits, and modification of mass). There may be often conflicts based on chain relations among solutions which designers cannot recognize. We focus on validating these solutions. In this paper, we propose an ontology for representing chain relations in design pro- cess. To validate designers’ solutions, we propose an algorithm to detect conflicts between a given solution and those for other design cases. In our case study, we introduce our approach to product development and demonstrate the efficacy and practicability of our proposed ontology. Keywords: Validating, Design Process, Design Knowledge, Fault Tree Analysis, Failure Mode and Effect Analysis, SPARQL 1 Introduction The phases of the manufacturing design process are as follows: Phase 1 de- tecting phenomena, Phase 2 factor analysis of phenomena, Phase 3 application of solutions based on those factors, and Phase 4 implementation of solutions. In this paper, phenomena means troubles which occurs in product design, and solution means designers’s approach improving their troubles. Designers need to share design knowledge to enhance the efficiency of the design process. To prevent problems arising in design process, Failure Mode and Effects Analysis (FMEA) and Fault Tree Analysis (FTA) are often employed. There are previous studies based on FMEA and/or FTA for managing the design knowledge with semantic web technology which employ several different methods; i.e., capturing and modeling functional knowledge [1], modeling the process of FMEA [2], and constructing an ontology-based FTA system for applying industrial process [3] [4] [5]. Most of these studies are focused on relations between phenomena, and generally do not examine the relationships between phenomena and solutions, or relations between solutions. 2 Kazunari Hashimoto et al. Designers’ works based on the design process for a product (hereinafter, re- ferred to as design cases), can be used to determine the conflict between solutions of design cases through communications such as documents and meetings. Con- flicts mean potential contradictions between solutions such as resizing, changing electrical circuits, and modification of mass and, as mentioned above, designers often cannot recognize conflicts due to chain relations between solutions and components for a particular product. This can mean that the effect of solution is halved, or a solution produces the opposite of its intended effect. Therefore, it is crucial that designers confirm that the applied solution for a given design case does not conflict with the solutions of other design cases. In this paper, we propose an ontology for representing chain relations in design process. We then propose an algorithm for detecting conflicts between possible solutions by inferring the trace of instance in stage. Finally, we intro- duce an approach to product development and demonstrate the efficacy and practicability of our proposed ontology. 2 Proposed Approach Fig. 1. The simplified version of proposed ontology 2.1 The Architecture of Ontology There are multiple dependencies on the state of components among phenomena, solution, and components. The state of components indicates the structural re- lation between components and the functional relationship between components such as power transmission or transmission of movement. Phenomena and solu- tion are represented by these component states. Factor analysis and application of solution are both represented by the state of components. An Ontology-based Validation Approach to Resolve Conflicts 3 We propose an ontology that represents these multiple dependencies in the design process. Fig.1 illustrates the simplified version of the proposed ontology. Independent entity class represents an independent concept with phenomena class, solution class, and component class as sub classes. Dependent entity class represents the dependence between Independent entity classes with design pro- cess class, state of components class, fact analysis class, application of solution class, and influences between solutions class as sub classes. State of components class represents the dependence between component classes. Fact analysis class, application of Solution class, and influences between solutions class represent dependencies among phenomena class, solution class and state of components class. Design process class is represented by links to phenomena class, fact anal- ysis class, and application of solution class. Influences between solutions class can represent the chain relation between solutions and validate solutions by the following algorithm. 2.2 Validating Solutions We assume that designers validate the solutions which they apply to phenomena. Let DC be design case, and DK be design knowledge. Let Comp be instances of component class, and Sol be instances of solution class. The instances of CompDC c and SolcDC represent components and a solution in the design case c. The instances of CompDK c and SolcDK represent components and a solution in design knowledge , corresponding to CompDC c and SolcDC . Via instances of state of components, CompDC c is linked to Sol DC c and CompDK c is linked to SolcDK . The application of solution means linking SolcDC to SolcDK and linking CompDC c to CompDK c . Designers must validate that the solution for the current case does not con- flict with the solutions for existing cases. Therefore, we propose the following algorithm for detecting conflicts between solutions: For case cA and case cB, an algorithm for detecting the conflict between DP DP SolcA and SolcB is as follows: Step1 Inferring the solution trace SolT raceDK DK DK cA−cB from SolcA to SolcB . DK SolT racecA−cB is composed of instances of solution class and influences be- tween solutions class. It is sufficient that at least one instance of influences between solutions class represents a contradiction relation. Therefore a con- DK DK flict exists between SolcA and SolcB . Step2 Inferring the component trace CompT raceDK DK cA−cB from CompcA to CompcB . DK DK CompT racecA−cB is composed of instances of component class and state of components class, linked to SolT raceDKcA−cB . Step3 Inferring the component trace CompT raceDC DC cA−cB from CompcA to CompcB . DC DK It is sufficient that each instance of CompT racecA−cB is linked to an instance of CompT raceDC cA−cB for component class. The proposed algorithm enables us to detect conflicts by inferring the con- tradiction trace from chain relations, which the proposed ontology represents in stages. The inference process in each step is implemented using Jena API [6] and SPQRQL query. 4 Kazunari Hashimoto et al. 3 Case Study The proposed method was introduced to one design case of our developing prod- uct. In Phase 1, the designer found phenomena in which the component Cable 50 extends out of the component Sensor 20. In Phase 2, the designer analyzed factors which indicated that the capacity of Sensor 20 was too small. In Phase 3, the designer applied the solution of decreasing the thickness of Sensor 20, thereby increasing its capacity. The designer then validated the conflict between the solution of the current case and the solutions of existing cases. Fig.2 illus- trates a use-case for detecting the conflict between solutions using our proposed method. Results showed that our proposed method could accurately detect the conflict between (S10) decreasing the thickness of Sensor 20 and (S20) increasing the mass of Frame 10. Fig. 2. A use-case of detecting the conflict between solutions using proposed approach In Step1, our method inferred the solution trace of design knowledge as follows: (S11) decreasing thickness of component → (IS13) → (S31) → (IS32) → (S21)Increasing Mass of Component. It was sufficient that this solution trace included the contradiction relation (IS32)Reverse Effect. In Step2, corresponding to the above solution trace, our method inferred the component trace of design knowledge as follows: (C11) → (SC13) → (C31) → (SC32) → (C21). In Step3, corresponding to the above component trace, our method inferred the component trace of the design case as follows: (C10) →... → (C20). Finally, the link (C21) → (C20) was inferred using (C31) → (C10), (C31) → (C32) → An Ontology-based Validation Approach to Resolve Conflicts 5 (C21). When the component trace from (C10) to (C20) existed, the conflict between (S10) and (S20) was indicated. As mentioned above, this case study clearly shows that the proposed method can detect conflicts between solutions and represent the potential chain relation which designers could not identify. This chain relation was defined as follows: (S10) → (S11) → (IS13) → (S31) → (IS32) → (S20). As a result, our method could detect potential conflicts between the solutions of 10 design cases. 4 Conclusion In this paper, we focused on validating solutions in design cases for product manufacturing. We proposed an ontology for representing chain relations among solutions and components, and proposed an algorithm for detecting conflicts be- tween their solutions. Our method realizes detecting the potential contradiction among designers’ solution in the initial design phase, so that they can reduce design troubles in the post-process, and the entire design man-hour is reduced. In our case study, the proposed method was applied to our developing product and could detect potentials conflict between the solutions of 10 design cases. Designers must continuously enhance their design knowledge, and we believe our our proposed method is a useful tool for the enhancement of that knowledge. When conflicts which designers can grasp are not detected by the proposed algo- rithm, the area between solutions includes either erroneous instances or missing instances. Designers can then identify the areas which require enhancement in terms of design knowledge. It is hoped that the proposed method presented in this paper will contribute to improved solution validation in manufacturing design. References 1. Yoshinobu, Kitamura.: Roles of Ontologies of Engineering Artifacts for Design Knowledge Modeling, International Seminar and Workshop Engineering Design in Integrated Product Development, 59–69, (2006) 2. Zobia, Rehman., Claudiu, V, Kifor.: An Ontology to Support Semantic Manage- ment of FMEA Knowledge, International Journal of Computers Communications & Control, 11(4):507–521, (2016) 3. Ioannis, M, Dokas., Cork, Ireland.: Ontology to Support Knowledge Representation and Risk Analysis for the Development of Early Warning System in Solid Waste Management Operations, International Symposium on Environment Software Sys- tems, (2007) 4. Martin, Melik-Merkumians., Alois, Zoitl.: Ontology-based Fault Diagnosis for In- dustrial Control Applications, IEEE conference on ETFA, (2010) 5. Allan, Venceslau., Raphaela, Lima., Luiz, Affonso, Guedes., Ivanovitch, Silva.: On- tology for Computer-aided Fault Tree Synthesis, IEEE Conference on ETFA (2014) 6. Apache Jena. https://jena.apache.org/documentation/inference/index.html