The reasoning mechanism is critical to the knowledge system for design conflict solving, since it determines the effectiveness and usability of the conflict solving method proposed in this research. The reasoning mechanism in this knowledge system involves three parts, i.e. the generalised design conflict, the knowledge repository and the semantic similarity analysis and synthesis.
The reasoning method is critical to finding candidate solutions to design conflicts arising from design change propagation analysis. It builds up the connection between generalised design conflicts and the knowledge repository to find semantically similar general solutions and then retrieve related design cases as reference solutions from the design case database. A reasoning algorithm is developed to compare semantic similarities between design conflicts and general solutions since both of them are formalised by the same set of ontology definition. The general process of design conflict solving is depicted in Figure 4-13 which is explained below in detail.
-85-
Figure 4-13 Reasoning approach to design conflict solving (by Author)
The reasoning process is composed of three steps:
(1) Finding similar general problems by using the semantic reasoning algorithm. As described above, design conflicts arising from change propagation analysis are formalised by pre-defined ontology. Problems or requirements for design cases are also generalised and formalised by the same set of ontology. Each element of the formalised design conflicts and the general problems has semantic tag attached, which makes it possible to compare the semantic similarities. Therefore, when an engineer has a design conflict to solve, he formalises it first using the proposed formalisation method and then submits the formalised design conflict to the knowledge repository. The knowledge repository employs the reasoning algorithm to calculate semantic similarities with each of the stored general problems. A prioritised list is then generated with the most semantically similar solution at the top.
(2) Selecting the most similar solutions and retrieving related design cases from the company’s database. From the prioritised list generated in the last step, engineers need to select the most similar solutions and the system retrieves design cases, which are related to the selected general solutions, from the company’s database. The engineer needs to find and select design cases as reference solutions which can help to solve the design conflict. Since it is not guaranteed that there would be technically suitable reference solutions, engineers may need to move further down on the list to check more general solutions with lower similarities and their related design cases, until he is satisfied with selected reference solutions. However, it is also possible that there is no suitable design case found if the design conflict is a new type which has no similar
-86-
design cases having been done before or there is no suitable design cases being formalised and stored in the database.
(3) Evaluating retrieved reference solutions and finding the most viable ones. In this knowledge-based method, reference solutions work as examples for engineers so that they can work out real solutions for the target design conflict based on information from reference solutions. However, even if real solutions are found technically viable to solve the design conflict, it does not mean they are truly viable since these solutions generated from the design change analysis need to be evaluated by some other factors which are important to the success of the product design such as development time, development cost and reliability. The evaluation method is proposed in section 4.6 (page 90).
In the proposed reasoning methodology, one of the most important steps is to analyse semantic similarities between generalised design conflicts and general solutions stored in the knowledge repository. As described above, design conflicts are generalised by predefined ontology and also previous design cases are formalised using the same set of predefined ontology. If a design conflict is defined as a concept (C) and all of the stored general solutions are defined as a set { }, the first step is to find the most similar solutions from the set of general solutions. Both the design conflicts and the general solutions are formalised by the same set of ontology. Each element of the design conflict and the design case is tagged by an ontological definition of the predefined set of ontology. The algorithm for calculating the semantic similarities between a generalised design conflict and general solutions is comparing the semantic similarity of each corresponding element (e.g. the flow type of the changed incoming flow in Figure 4-11) and then adding them up to get an overall semantic similarity.
-87-
Figure 4-14 Comparison of semantic meanings between concepts (By Author)
Figure 4-14(a) represents hierarchically ontological definitions of a group of entities. The higher the level of an ontological definition, the more general semantic meaning it represents. While in lower levels, the semantic meaning of an ontological definition is more specific. In Figure 4-14(b), IC(S1) represents the semantic meaning of the ontological definition S1. Since S1 is the parent of S11 and S12, S1 has a wider semantic meaning than S11 and S12, which means:
( ) ( ) ( ) ( ) (4.1)
The following equation can represent how S11 (a child) is semantically similar to S1 (a parent) by comparing scales of semantic meaning of each ontological definition:
( ) ( ) ( ) (4.2)
While the similarity of S11 (a brother) to S12 (a brother) can be represented as:
( ) ( ( ) ( )) ( ) (4.3)
Thus, the similarity of two definitions (for example, S111 and S22) can be represented as:
-88-
( ) { ( ) ( ) ( )
( )} (4.4)
Based on the idea of calculating similarities between ontological definitions, the generalised deign conflict can be compared with general solutions in the knowledge repository, since both of them are formalised using the same set of ontology. The formalisation of general problems that general solutions are intended to solve is the same as for design conflict formalisation. So the similarity between a generalised design conflict and a general problem can be described as:
( ) ( ) ( )
( ) ( ) (4.5)
Where DC represents design conflict, GD represents generalised design case, CF represents general problem, CF represents changed flow, and AF represents affected flow. Similarity between changed flows can be represented as:
( ) ( ) ( ) (4.6)
Similarity between affected flows can be represented as:
( ) ( ) ( )
(4.7)
By comparing the overall similarities between the generalised deign conflict and general problems, a set of prioritised similarity values are generated:
{ ( ) ( ) ( )} (4.8)
By exploring and reviewing design cases associated with general problems (corresponding to general solutions) from cases with higher priority to those with
-89-
lower priority, the suitable design cases are chosen as reference solutions for the target design conflict.