In design process of manufacturing, designers analyze the factor of phenomena and apply solutions to phenomena (such as resizing, changing electrical circuits, and modi cation of mass). There may be often con icts 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 process. To validate designers' solutions, we propose an algorithm to detect con icts 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.
The phases of the manufacturing design process are as follows: Phase 1
detecting 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 [
Designers' works based on the design process for a product (hereinafter, referred to as design cases), can be used to determine the con ict between solutions of design cases through communications such as documents and meetings. Conicts mean potential contradictions between solutions such as resizing, changing electrical circuits, and modi cation of mass and, as mentioned above, designers often cannot recognize con icts 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 con rm that the applied solution for a given design case does not con ict 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 con icts between possible solutions by inferring the trace of instance in stage. Finally, we introduce an approach to product development and demonstrate the efficacy and practicability of our proposed ontology. 2
There are multiple dependencies on the state of components among phenomena, solution, and components. The state of components indicates the structural relation between components and the functional relationship between components such as power transmission or transmission of movement. Phenomena and solution are represented by these component states. Factor analysis and application of solution are both represented by the state of components.
We propose an ontology that represents these multiple dependencies in the design process. Fig.1 illustrates the simpli ed 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 process class, state of components class, fact analysis class, application of solution class, and in uences between solutions class as sub classes. State of components class represents the dependence between component classes. Fact analysis class, application of Solution class, and in uences 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 analysis class, and application of solution class. In uences 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 CompcDC and SolcDC represent components and a solution in the design case c. The instances of CompcDK and SolcDK represent components and a solution in design knowledge , corresponding to CompcDC and SolcDC . Via instances of state of components, CompcDC is linked to SolcDC and CompcDK is linked to SolcDK . The application of solution means linking SolcDC to SolcDK and linking CompcDC to CompcDK .
Designers must validate that the solution for the current case does not conict with the solutions for existing cases. Therefore, we propose the following algorithm for detecting con icts between solutions:
For case cA and case cB, an algorithm for detecting the con ict between SolcDAP and SolcDBP is as follows: Step1 Inferring the solution trace SolT racecDAK cB from SolcDAK to SolcDBK .
SolT racecDAK cB is composed of instances of solution class and in uences between solutions class. It is sufficient that at least one instance of in uences between solutions class represents a contradiction relation. Therefore a conict exists between SolcDAK and SolcDBK .
Step2 Inferring the component trace CompT racecDAK cB from CompcDAK to CompcDBK .
CompT racecDAK cB is composed of instances of component class and state of components class, linked to SolT racecDAK cB.
Step3 Inferring the component trace CompT racecDAC cB from CompcDAC to CompcDBC .
It is sufficient that each instance of CompT racecDAK cB is linked to an instance of CompT racecDAC cB for component class.
The proposed algorithm enables us to detect con icts by inferring the
contradiction trace from chain relations, which the proposed ontology represents in
stages. The inference process in each step is implemented using Jena API [
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) (C21). When the component trace from (C10) to (C20) existed, the con ict between (S10) and (S20) was indicated.
As mentioned above, this case study clearly shows that the proposed method can detect con icts between solutions and represent the potential chain relation which designers could not identify. This chain relation was de ned as follows: (S10) (S11) (IS13) (S31) (IS32) (S20). As a result, our method could detect potential con icts between the solutions of 10 design cases.
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 con icts between 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 con ict 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 con icts which designers can grasp are not detected by the proposed algorithm, 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.