# Knowledge and Information Structuring in Reverse Engineering of Mechanical Systems

Mohamed Islem Ouamer Ali, Florent Laroche, Sébastien Remy, Alain Bernard

► To cite this version:

Mohamed Islem Ouamer Ali, Florent Laroche, Sébastien Remy, Alain Bernard. Knowledge and Information Structuring in Reverse Engineering of Mechanical Systems. 12th IFIP International Conference on Product Lifecycle Management (PLM), Oct 2015, Doha, Qatar. pp.418-427, 10.1007/978-3-319-33111-9_39. hal-01377469

HAL Id: hal-01377469

https://inria.hal.science/hal-01377469

Submitted on 7 Oct 2016

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Knowledge and Information Structuring in Reverse Engineering of Mechanical Systems

Mohamed Islem OUAMER ALI¹, Florent LAROCHE¹, Sébastien REMY², Alain BERNARD¹

¹IRCCyN, Ecole Centrale de Nantes, Nantes, France
m.ouamerali@irccyn.ec-nantes.fr
florent.laroche@irccyn.ec-nantes.fr
alain.bernard@irccyn.ec-nantes.fr

²ICD, Université de Technologie de Troyes, Troyes, France
sebastien.remy@utt.fr

**Abstract.** In an increasingly competitive environment in the manufacturing industry, the control of time, cost and performance enables companies to stand out and take the lead. We are witnessing the proliferation of design aiding solutions that support the designer in his work, and it is through these solutions that developers and researchers aim to improve product development, and control all the aspects of project raised above. One of the activities that are used in product development is Reverse Engineering. This activity allows the extraction of information from an existing physical product. In industry, we may use this activity in order to maintain long-life products, or make a re-design, re-engineering, re-manufacturing, etc. In this paper, we propose an approach that will allow the management of a global reverse engineering process for complex mechanical assemblies.

**Keywords:** Reverse engineering, product models, knowledge management, knowledge representation, PLM.

## 1 Introduction

In order to present a comprehensive and robust methodological approach of reverse engineering, a first exploration of different methodologies was made. [1] We find in the literature, different definitions and methods of reverse engineering, however, the dependence of these methods to contexts of use, and the lack of knowledge use (other than topological and geometrical) makes methods and tools local, and non-robust. We are aiming to fill these gaps through the integration of knowledge of different types, and the use of heterogeneous data that can be found on the analysed products. It is therefore natural that one of the main issues is knowledge management in overall, from its capture to its use in the process. In this article, we will focus more on the aspect of knowledge and information structuring, implementation and use. The structuring part will concern the implementation of a knowledge base for the identification of different products. This knowledge base will be based on an adequate
product model that will allow us to take into account all knowledge and information
in a product. As for the use, it will concern the final reconstitution of the product.
At first, a presentation of the state of the art required to build our approach will be
made in section 2, and the definition of reverse engineering in our perspective and
what will help us develop our approach to offer a global methodology will be
discussed in section 3. Finally we conclude the results and future work.

## 2 State of the art

### 2.1 Reverse Engineering

**Definitions**

Reverse engineering was developed as an alternative to set or reset objects or products [2]. It is the reverse of the design process. It consists of the rebuilt of a design model based on an actual product. [3] The main goal of reverse engineering is going back to the results of the original design process of a part or an assembly in order to create a copy of it, as shown in Fig.1.

According to Chikofsky [4] the Reverse Engineering process can also be defined as a
process for analysing a system to:

* Identify system components and their relationships.

* Create representations of the system in another form or another level of abstraction.

**Phases of reverse engineering**

Reverse engineering has a strong presence in mechanical design. There are several
solutions that have been developed in this area. However, these solutions are often
very contextualised, partial and incomplete [5] [6].

Generally in the literature, four main actions are identified in the reverse engineering
process and which are:

1. Scan Product and Data Acquisition

2. Segmentation of the data acquired during the scan

3. Knowledge Extraction (i.e. Manufacturing features recognition – geometric and topologic knowledge in most cases).

4. Reconstruction of the 3D model updated
<figure><img src="image_2.png" /><figcaption>Fig. 1. The link between product lifecycle and the reverse engineering process.</figcaption></figure>

It is worthy to note that knowledge used in these solutions (if so) is restricted to
only topological and geometric shapes, and therefore, these reverse engineering
methods could restrict the scope of the designer, whereas other types of knowledge
[7] integrated in the process could have made it semantically richer allow the user to
have more freedom in it.

## 2.2 Knowledge

### Definitions

In order to define knowledge, several authors propose to highlight the differences
between data, information, and knowledge.

Data is gross figures and facts, while information is processed data. Finally,
knowledge is authenticated and contextualized information [8]. Knowledge exists
outside of an intelligent system only as information (Knowledge is personalized
information on facts, procedures, concepts, interpretations, ideas, observations, and
judgments [8]), since they are the result of a cognitive process that leads to the
binding of different pieces of information to others by means of semantic links,
creating a global information schema.

Still according to [8], if we were to establish a hierarchy among these three concepts,
two approaches are identified:

1. The first is where the existence of knowledge is conditioned by the existence of information, which itself is conditioned by the existence of data, so: data (low level) and information (Average level) and knowledge (high level).

2. The second is where knowledge allows us to formulate the information, and therefore to measure the data.

What one can declare, is that the three concepts are related and condition the
existence of each other where without data there is no information (and therefore no
knowledge), and without knowledge there is no sense to data.
## Knowledge typology

In order to address knowledge in the best way and represent it, it is necessary to make a classification by type of knowledge, and thus define the domain of definition of each type of knowledge.

<figure><img src="image_3.png" /><figcaption>Fig. 2. Knowledge Typology by Nonaka [9].</figcaption></figure>

As shown in Fig.2, knowledge types can be classified in three different dimensions. Therefore, each classification has its own axis [9]:

1. **Formal / Tacit:** Formal knowledge is integrated in the documents of the product, the structure and functions description of the product, etc. And tacit knowledge is knowledge related to experience, implicit rules, intuition, etc. [10].

2. **Product / Process:** Product knowledge takes into account the information and knowledge about the evolution of the product throughout its life cycle. The process knowledge can be classified as follows: knowledge of the design process, project knowledge, and knowledge of the manufacturing process.

3. **Compiled / Dynamic:** The compiled knowledge is mainly obtained from the experience that can be compiled into rules, plans, scripts, etc. The solutions are explicit. Dynamic knowledge uses knowledge that can generate additional knowledge structures, which are not taken into account by the compiled knowledge.

## Knowledge representation

The collaborative engineering implies sharing knowledge between actors from different working groups of the same project. Sharing this knowledge follows mechanisms where knowledge should be made explicit. Hence, the need to represent knowledge in order to facilitate communication between actors.

In [11] knowledge representation is described as having 5 roles:

1. Substitution of an external entity (real world) which is carried out by an internal process.

2. A set of ontological commitments.

3. A fragmentary theory (partial view) of an intelligent reasoning.
4. An effective way of reasoning (artificial intelligence).

5. A means of human expression (communication).

It is also important to note that the existence of different types of knowledge implies a difference in the representation of these types in different modes and tools.

## Knowledge representation modes

Knowledge representation can be classified. In [12], one proposes 5 categories of knowledge representation: pictorial, symbolic, linguistic, virtual, and algorithmic.

In [9] Based on the above categories of representation, we propose a scheme of knowledge representation in product design.

In fig.3 different tools of product design used in the different phases of the design process are matched with knowledge representation modes. This match is more detailed in fig.4.

<figure><img src="image_4.png" /><figcaption>Fig. 3. Knowledge representation modes in product lifecycle [].</figcaption></figure>

<table><caption>Fig. 4. Design tools according to knowledge representation modes [].</caption><thead><tr><th>Pictorial</th><th>Symbolic</th><th>Linguistic</th><th>Virtual</th><th>Algorithmic</th></tr></thead><tbody><tr><td>Sketches<br>Detailed drawings<br>Charts<br>Photographs<br>CAD model views</td><td>Decision tables<br>Production rules<br>Flow charts<br>FMEA diagram<br>Assembly tree<br>Fishbone diagrams<br>Ontologies</td><td>Customer Requirements<br>Design Rules, constraints<br>Analogies<br>Customer feedback<br>Verbal communication</td><td>CAD Models<br>CAE Simulations<br>Virtual Reality simulations<br>Virtual prototypes<br>Animations<br>Multimedia</td><td>Mathematical Equations<br>Parametrizations<br>Constraint Solvers<br>Computer Algorithms<br>Design/ operational procedures</td></tr></tbody></table>

The implementation of an approach based on knowledge management requires a good comprehension of the concepts. Thus, defining the right knowledge typology with the right knowledge representation modes would put a basis for structuring knowledge through a complete product model taking into account all information and knowledge covered in the case of reverse engineering, and maybe conventional design.
## 2.3 Product models

A product model is a model that is used to structure the product of a specific vision. There are several models 'product' in the scientific literature.

For purposes of exemplification, we chose the FBS model shown in fig.5.

### 1) The FBS model

This model categorizes the object in 3 aspects: [13]

* Function: Or, What is the purpose?

* Behaviour: Or, as the subject?

* Structure: Or, what is the object?

<figure><img src="image_5.png" /><figcaption>Fig. 5. A view of the FBS product model [13].</figcaption></figure>

The definitions presented by Gero in this model are not clear. We note the absence of a stable definition of the function, and the double objective description of the current design and prescription of improved design. [14]

The contribution of a model produced in our approach is a comprehensive organization of information to facilitate its use, and the establishment of a solid foundation on which is based our work for a global reverse engineering methodology. This is one of the most important parts in the elaboration of our approach, and the product model that will be implemented will depend on the types of knowledge and information taken into account and their representation modes.

## 3 New approach of reverse engineering

Considering the definition of Chikofsky [4], we can give the following proposition: "Reverse engineering is a process of moving from one level of abstraction to another," from a low level to a higher one, and therefore, we can move from the concrete to the abstract product produced and have the results of the design. This definition is consistent with the fact that reverse engineering is the reverse process of design. Indeed, the design allows us to start from the idea (most abstract form of the product) to the product itself (the most concrete form of the product). We can see in
fig.6 the qualitative representation of the correlation between levels of abstraction and product development cycle. The green arrow represents the reverse engineering process. We could also put an arrow in the opposite direction relative to the normal design cycle.

<figure><img src="image_6.png" /><figcaption>Fig. 6. Relationship between product lifecycle and abstraction levels [13].</figcaption></figure>

It would be interesting to consider the abstraction of information as an important aspect in the implementation of a reverse engineering process to track its status.

**3.1 Information abstraction levels**

This concept has recently been introduced in the field of mechanical engineering in general, and has never been used in reverse engineering. It is in the field of IT that we tried to identify the levels of abstractions of information: we find for example in [15] the following levels:

* **Objective level:** represents the context in which the product is placed and its objective. For example for a gear, the objective is the transmission of motion between two coaxial shafts.

* **Conceptual level:** represents a first definition of the product through information deduced from its objective (goal). For example, the input and output parameters in the process of motion transmission.

* **Functional level:** represents the functions that would be accomplished by the product. For example, the gear transmits power through its cogs, follows the movement of the shaft through a spline, etc.

* **Logical level:** represents information related to the product's behaviour. For example, the relationship between the geometry of a cog in a gear, the material used and the torque limit.

* **Physical level:** represents the most concrete level with topological and geometrical information. For example the shape of a gear's cogs in a CAD model.

Based on the levels defined above, we can identify a first correspondence between the abstraction levels and different aspects of product models. For example there are the aspects of the FBS model in the last 3 levels of abstraction: functional level (Function in FBS), logical level (Behaviour in FBS), and Physical level (Structure in FBS).
However, we find the limit of the FBS model that does not take into account other levels of abstraction (Such as objective and conceptual levels) that are just as important in defining a product.

Indeed, the objective level takes into account the context in which emerged the idea of the product, and in which is defined the objective to which it should respond. And the conceptual level sets up a first segmentation that will determine the rest of the product development.

## 3.2 Representation modes

The inclusion of representation modes in reverse engineering allows to not only to communicate information related to knowledge represented differently, but also provides a classification of different knowledge according to their representation.

One could imagine the combination of knowledge representation with the levels of abstraction to define the state of knowledge at a time T of the product lifecycle. So, this would define a space in which each point represents a state of knowledge with as characteristics, level of abstraction and representation mode. This would allow the establishment of a methodological approach to reverse engineering, which would take into account all possible aspects of knowledge related to the product by implementing a product model that corresponds to the levels of abstraction.

## 3.3 Knowledge state

The definition that could be given to the state of knowledge is that it represents knowledge at a certain point in time (represented by the product lifecycle), and a specific level of abstraction. One could imagine as in fig.7 where the points P, Q and R represent different states of knowledge on a product, where P is a representation of the product technical specifications, Q is its behaviour and R its functions.

<figure><img src="image_7.png" /><figcaption>Fig. 7. Knowledge states in the states space represented by abstraction levels, representation modes and product lifecycle.</figcaption></figure>
Reverse engineering by definition is the transition from an abstraction level to another, so we can say that this is a change of state of knowledge, which would mean that reverse engineering is a process which allows us to move from one point to another as shown in fig.8

<figure><img src="image_8.png" /><figcaption>Fig. 7. Knowledge states in the states space represented by abstraction levels, representation</figcaption></figure>

Finally, the space in which the states of knowledge are located could be used to map all the activities that contribute in the reverse engineering process.

# 4 Conclusion and future work

To establish a comprehensive methodology of reverse engineering, a new definition was proposed: reverse engineering is the process of knowledge state transformation that allows us to move from a state 'A' where knowledge is represented in a representation mode and level of abstraction at a certain point of time 'T', to a state B where one or more of the three aspects of the status changes (ie, the time, the level of abstraction, and the mode of representation).

A clarification should be made regarding the different states of knowledge and the various state changes to be considered in the reverse engineering process.

Concerning the possible implementation of this new approach, an adequate product model should be proposed in order to take into account all aspects of information and knowledge required for reverse engineering process. It will also identify the correspondence between the different types of knowledge initially defined, and the state of knowledge.

# References

1. M.I.Ouamer-Ali, F.Laroche, A.Bernard, & S.Remy. (2014). Toward a methodological knowledge based approach for partial automation of reverse engineering. Procedia CIRP, 21, 270-275.
2. Bernard (1999), Reverse engineering for rapid product development: a state of the art, in Proceedings of SPIE- The International Society for Optical Engineering, Three dimensional

3. P. Benko, T. Varad. "Segmentation methods for smooth point regions of conventional engineering objects". Computer Aided Design, Vol. N°52, 2004, pp.36-511.

4. E.J.Chikofsky, J.H.CROSS, et al. Reverse engineering and design recovery: A taxonomy. Software, IEEE, 1990, vol. 7, no 1, p. 13-17.

5. S. Remy, G. Ris, O. Nartz, A. Bernard (2003), Reverse engineering of a 1935 Delahaye radiator cap, European Virtual Engineering Network conference 2003, Dublin, Irlande, pp.107-115, ISBN 0-947974-15-6.

6. A. Bernard, O. Nartz, S. Remy, G. Ris, Y. F. Zhang, H.T. Loh, Y.S. Wong (2002), Reverse engineering and rapid prototyping, chapter 9 of the book untitled "Software solutions for Rapid Prototyping", pp. 283-339, Coordinator : Ian Gibson, ISBN No. 1-86058-360-1, publishing Ed., UK.

7. N.Troussier, M.Bricogne, A.Durupt, F.Belkadi, G.Ducellier (2010). A knowledge-based reverse engineering process for CAD models management. Proceedings of IDMME-Virtual Concept.

8. M.Alavi, & D.E.Leidner, (2001). Review: Knowledge management and knowledge management systems: Conceptual foundations and research issues. MIS quarterly, 107-136.

9. S.K.Chandrasegaran, K.Ramani, R.D.Sriram, et al. The evolution, challenges, and future of knowledge representation in product design systems. Computer-Aided Design, 2013, vol. 45, no 2, p. 204-228.

10. I.Nonaka, N.Konno (1998). The concept of "ba". Building a foundation for knowledge creation. California management review, n°40-3, pp.40-54.

11. R.Davis, H.Schrobe, P.Szolovits. What is a knowledge representation? AI Magazine 1993; 14(1):17-33.

12. R.Owen, I.Horváth. Towards product-related knowledge asset warehousing in enterprises. In: Proceedings of the 4th international symposium on tools and methods of competitive engineering, TMCE 2002; 2002. p. 155-70.

13. J.S.Gero, & M.A.Rosenman. (1990). A conceptual framework for knowledge-based design research at Sydney University's Design Computing Unit. Artificial Intelligence in Engineering, 5(2), 65-77.

14. P.E. Vermaas, & K. Dorst, (2007). On the conceptual framework of John Gero's FBS-model and the prescriptive aims of design methodology. Design studies, 28(2), 133-157.

15. J.Rasmussen (1985). The role of hierarchical knowledge representation in decision making and system management. Systems, Man and Cybernetics, IEEE Transactions on, (2), 234-243.