=Paper=
{{Paper
|id=Vol-1824/ldq_paper_3
|storemode=property
|title=An Ontology-based Validation Approach to Resolve Conflicts in the Manufacturing Design Process
|pdfUrl=https://ceur-ws.org/Vol-1824/ldq_paper_3.pdf
|volume=Vol-1824
|authors=Kazunari Hashimoto,Yohei Yamane,Seiji Suzuki,Motoyuki Takaai,Masao Watanabe,Hiroshi Umemoto
|dblpUrl=https://dblp.org/rec/conf/esws/HashimotoYSTWU17
}}
==An Ontology-based Validation Approach to Resolve Conflicts in the Manufacturing Design Process==
https://ceur-ws.org/Vol-1824/ldq_paper_3.pdf
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