Chapter 3: GENERAL ONTOLOGY
3.1 Introduction
As it is described in the previous chapter, in order to develop Evolvable Assembly Systems an ontology that is process-oriented, is necessary. In this chapter what an ontology is, why it is useful in the assembly and EAS context and why it must be process-oriented is explained. Afterwards, the former version ( developed within the Eupass project ) is shown, highlighting weak points. Finally, the new version is illustrated with its classes, sub-classes and attributes; special attention is given to links among these classes and sub-classes specifying the kinds of links used and the reason why a generic couple of elements (e.g. classes) is connected by that link.
This is an important step towards the application of the EAS paradigm but it cannot be thought that this ontology is completed; it must be regularly revised and, especially, updated, in order to introduce elements that just experience and technical improvements can suggest.
3.2 Overview
3.2.1 What is in an ontology?
Before explaining why to support EAS paradigm we developed an ontology and in order to make the next understanding easier, it can be useful to give a brief description of what an ontology is and how it is structured.
Note that this description is based on “Ontology Development 101: A Guide to Creating Your First Ontology” by Natalya F. Noy and Deborah L. McGuinness.
In this context an ontology can be defined as a data model that represents a set of concepts within a domain and the relationships among those concepts. It is used to reason about the objects within that domain. Many disciplines now develop standardized ontologies that domain experts can use to share and annotate information in their fields.
Ontologies are composed of units arranged frequently in a hierarchical structure, typically related by subtype-supertype relationships, also called parent-child relationships. Developing an ontology means also defining which attributes and properties classes can have and constraints on their values. In such a subtype-supertype relationship the subtype kind of thing has, by definition, the same constraints as the supertype kind of thing plus one or more additional constraints.
The main difference between ontologies and taxonomies ( that as well as ontologies can be seen as hierarchical classifications) lies on the fact that taxonomies are seen as less broad than ontologies, as ontologies apply a larger variety of relation types; in other words, not only “is-a” relationships but also more complex links (as it will be shown in next paragraphs).
The elements constituting an ontology are classes ,attributes, relationships and instances. In this section each of these components is discussed in turn.
3.2.1.1 Classes
Classes are abstract groups, sets, or collections of objects. They may contain instances, other classes, or a combination of both. Classes are the focus of ontologies: they describe concepts in the domain. A class can have subclasses that represent concepts that are more specific than the superclass. For example, anticipating what will be discussed in the next paragraphs where the general ontology is described, “General equipment” is a class in the assembly domain composed of two sub-classes (“Manufacturing equipment” and “Assembly equipment”) that are more specific than the upper class.
3. 2.1.2 Attributes
Attributes are properties, features, characteristics, or parameters that objects (classes or instances) can have and share. This means that objects in the ontology can be described by assigning attributes to them. Each attribute has at least a name and a value, and is used to store information that is specific to the object it is attached to.
For example, again from the General Assembly Ontology, a robot has attributes such as: • Accuracy • Degrees of freedom • Manufacturer • Repeatibility • …
If an attribute is defined for a class every its sub-classes are forced to have it. For example, as the class “General Equipment” has the attribute “Manufacturer” so the sub-classes “Assembly Equipment” and “Manufacturing Equipment” ( but also “Robot” which is an “Assembly Equipment” sub-class ) have it.
Finally give attention to the fact that if you do not define attributes for the concepts you would have either a taxonomy or a controlled vocabulary. These are useful, but are not considered true ontologies.
3.2.1.3 Instances
Instances are the basic, “ground level” components of an ontology. Strictly speaking, an ontology need not include any instances, but one of the general purposes of an ontology is to provide a means of classifying individuals, even if those instances are not explicitly part of the ontology. In the General Assembly Ontology created in this thesis instances are not considered because they become to be useful later when the ontology is applied and not when it is theoretically developed. Anyway an instance could be, for example considering the class “Articulated Robot”, the actual model ABB-xxx with its characteristics.
3.2.1.4 Relationships
As said, one of the most important characteristics of ontologies is to relate objects among them to understand not just only how a certain domain is composed but also how its elements affect each other. This can be done describing which relationships there are between those
objects mentioned above. Much of the power of ontologies comes from the ability to describe these relationships. Together, the set of relationships describes the semantics of the domain. In the General Assembly Ontology there are a lot of examples; one of them is the “Has part” relationship within “Activity” class (see figure 11)
Fig. 11
Note that at this moment it is not important to understand the meaning of those relationships (it is described in the concerning part of the document). At this stage, we can briefly just describe one of them: the “is-a” relationship (or is-subclass-of). As it can be seen in the figure, this defines which objects are members of classes of objects. The addition of the “is-a” relationships creates a hierarchical taxonomy; a tree-like structure that clearly depicts how objects relate to one another: each object is the “child” of a “parent class”.
3.2.2 Why develop an ontology
In this paragraph we describe why it can be valuable, generally, to develop an ontology and then why we did it in this thesis.
On the whole the main scope is to define a common vocabulary for researchers who need to share information in a domain. Below some of the other most important reasons are shown and then explained:
To share common understanding of the structure of information among people or software agents
To enable reuse of domain knowledge To make domain assumptions explicit
To separate domain knowledge from the operational knowledge To analyse domain knowledge
Sharing common understanding of the structure of information among people or software agents is one of the more common goals in developing ontologies (Musen 1992; Gruber 1993). For example, suppose several different Web sites contain medical information or provide medical e-commerce services. If these Web sites share and publish the same underlying ontology of the terms they all use, then computer agents can extract and aggregate information from these different sites. The agents can use this aggregated information to answer user queries or as input data to other applications.
Enabling reuse of domain knowledge was one of the driving forces behind recent surge in ontology research. If one group of researchers develops such an ontology
in detail, others can simply reuse it for their domains. Additionally, if we need to build a large ontology, we can integrate several existing ontologies describing portions of the large domain. We can also reuse a general ontology and extend it to describe our domain of interest. Moreover, interoperability can be allowed introducing standards.
Making explicit domain assumptions underlying an implementation makes it possible to change these assumptions easily if our knowledge about the domain changes. Hard-coding assumptions about the world in programming-language code makes these assumptions not only hard to find and understand but also hard to change, in particular for someone without programming expertise. In addition, explicit specifications of domain knowledge are useful for new users who must learn what terms in the domain mean.
Separating the domain knowledge from the operational knowledge is another common use of ontologies: it allows to reuse domain and operational knowledge separately. For example, we can describe a task of configuring a product from its components according to a required specification and implement a program that does this configuration independent of the products and components themselves (McGuinness and Wright 1998). We can then develop
an ontology of PC-components and characteristics and apply the algorithm to configure made-to-order PCs. We can also use the same algorithm to configure elevators if we “feed” an elevator component ontology to it (Rothenfluh et al. 1996).
Analysing domain knowledge is possible once a declarative specification of the terms is available. Formal analysis of terms is extremely valuable when both attempting to reuse existing ontologies and extending them (McGuinness et al. 2000).
Often an ontology of the domain is not a goal in itself. Developing an ontology is akin to defining a set of data and their structure for other programs to use. Problem-solving methods, domain-independent applications, and software agents use ontologies and knowledge bases built from ontologies as data. For example, suppose we develop an ontology of wine and food and appropriate combinations of wine with meals. This ontology could be used as a basis for some applications in a suite of restaurant-managing tools: one application could create wine suggestions for the menu of the day or answer queries of waiters and customers. Another application could analyse an inventory list of a wine cellar and suggest which wine categories to expand and which particular wines to purchase for upcoming menus or cookbooks.
These reasons are the same ones that have led the development of the “General Assembly Ontology” later described.
From EAS point of view, firstly it was very important to provide a clarification on the main concepts required by such a big, wide, and complex domain such as assembly. Of course a mere list of definitions without any structuring would not be valuable; development of an ontology with its classes, relationships and attributes was necessary to share common understanding of the structure of information among actors involved in this project and software agents used to control modules.
Moreover, as said in the introduction, this ontology is not completed neither the only one possible, but developing an ontology in detail as we did enables reuse of domain knowledge. Of course this is the basis for future updating, but also it can be reused both for particular domains included in the general one and for building a larger ontology integrating this one (for example, if next a “General Production Ontology” will be developed).
Besides, making explicit domain assumption (as it is required by ontologies) makes it possible to change assumptions easily if the knowledge about assembly changes, but also to understand
and update quicker legacy data. This is very important at this stage (we are still in a phase where things are not definitely defined) considering that in research field, as known, assumptions can change frequently.
One more reason to develop a general ontology, as shown above, is to separate domain knowledge from the operational knowledge. One practical application is described in chapter 5 where it is explained how, from the same general ontology, two specific ontologies (related to two different products) are derived. Domain knowledge is linked with the operational knowledge (because one is obtained from the other) but, at the same time, separated and it can be used for several different applications.
Those reasons given above explain why “General Assembly Ontology” is useful in EAS project, but they do not explain how it is used and so why it is valuable. We send you back in the previous chapter where the use of this ontology is fully described, in this part we just want to remark (considering that we are describing why the ontology is developed) the importance of the ontology as the starting point of the process of choice of equipments making up the assembly system.
3.3 Necessity of a process-oriented Ontology
In the first chapter the idea to put the attention on the processes and on the modularity, instead of the product and the flexibility was introduced. As it is clarified in that part of the thesis, this approach becomes necessary in order to go over the problems found in the ones that were followed till now. In fact, focusing on processes allows to simplify the aspects linked with emplacement of assembly systems. Briefly, as explained in the former chapters, this is due to the fact that rather than developing from the beginning a new system each time a new product has to be assembled, just new processes (which are connected with certain equipment very task-specific) are found so as let the evolvability of the system. This implies advantages concerning both economical (e.g. developing time decreases) and technical (product based assembly systems that could lead to badly-adapted, complicated or even impossible processes and therefore expensive and complicated solutions are avoided) parameters.
Once explained why is important to follow the process-oriented direction, what remains to understand is how to achieve it. The ontology, as shown in chapter 1, is the basis of the
development of such systems; this means that if we want to focus our attention on processes what must be done is actually to create an ontology that is process-oriented. Once accomplished this, since the ontology is used as fundamental medium of EAS, even the assembly system will be developed according to this approach.
In next paragraphs the Eupass ontology is previously presented highlighting those elements that brought us to say that an updated version, which was more aligned with the characteristics already pointed out, was necessary. Then, finally, the new “General Ontology”, reviewed in order to get those features, is shown.
3.4 EUPASS Ontology
Both in this part and next to depict the new ontology Protégé 3.3 beta is used as ontology-editing environment, so next figures and graphs are obtained by this freeware software.
In this paragraph Eupass ontology is described. Its elements are shown pointing out weakness points found, but not how to solve them; this is done in the next chapter contextually with the description of the newest ontology. The most general important problem that was found was due to the fact that the ontology seemed to be control-oriented, built to be used just by the control system and not by who has to use it to realize the system configuration. Instead, as we said previously, this is a fundamental step towards EAS paradigm, as a process-oriented ontology is (see former chapter).
There are two reasons to show this ontology before the new one:
The new version is anyhow developed starting from the old one
Weakness points found in the Eupass ontology made the updating necessary
The description proposed, according to the general definition given above, analyses first the classes and sub-classes (how the tree is structured), then the relationships between these classes and last the attributes assigned to each class. Note that when we did not change from the original version, the description is postponed in the next paragraph. Also the explanation of some concepts is postponed in that chapter unless it is necessary to understand the problem
discovered. Moreover, just the most important elements, the more useful to understand why an updated version was necessary are introduced.
3.4.1 Classes
The Eupass ontology was organized in nine main classes (see figure 12); in this contest they do not have a different importance and the hierarchy of presentation does not have any meaning. This is an example of what is said before: from a control point of view there is no difference if a class is considered before one other, but from an emplacement point of view it becomes very important; in EAS paradigm classes are strictly in logical sequence as it is displayed in figure 5 (see chapter 1).
Fig. 12
Focusing on “Process” and “ProcessActions” classes, whose sub-classes are shown in figure 13, it is clear that they have many common elements; it seems to be useless to split these two concepts, in order to achieve as simplicity as possible.
Fig. 13
Finally “Operators” class has to be analysed. This is a tricky problem that must be treated with care. Human beings cannot be considered at the same level as general equipments, because they are certainly more intelligent but at the same time more complex also. This means that their behaviour is not linear as a general equipment one is; it could be hazardous to deal with them as they would be normal devices.
How to treat this aspect is still a discussed issue, but it is not developed here since it is not one of the topic of this thesis.
3.4.1.1 Skills
Analysing the super class “Skill” (see figure 14), the problem found was due to the “basicSkill” class. Why “change tool” is considered a basic skill and “pickPlace” not? Moreover; why “change tool” is a basic skill and “change gripper” not? The matter can be found in the fact that just the definition of “skill” is given ( Definition - Skill is the ability to perform actions), but not a definition of “basic skill” and “complex skill”. To be as clear as possible in the next chapter a solution will be illustrated enabling in this way the achievement of a classification more general and less ambiguous.
3.4.1.2 Module
Fig. 15 shows how “Module” class is structured. There are two elements that must be considered:
Fig. 15
• The fact that “FlowIn_Unit” and “FlowOut_Unit” are inserted as different sub-classes is one more example about the fact that the control aspects led the development of this ontology. This because programming languages deal with flowing in and out aspects separately (in the path of the pallet there are a certain number of stations where it can stop, and the path it has to follow is obtained by composition of information like “move to station X to station Y”, so each sub-path is composed by a flowing In and a flowing Out station), but this is not mechanical point of view also: the device used to flow elements in is the same used to flow them out, so there is no real reason to treat them as two different entities.
• In this classification specific units are considered (“Pick&Place dedicated unit” and “Milling machine”) and a sub classification is given for “Verification_Unit” class. This is again ambiguous and not general: on one hand it is not shady why some specific units are considered and some others not (and why some of them are
considered in this main class and others within “Equipment” class); on the other hand it is not clear why some of this classes are more detailed than others. The problem found seems to be the lack of uniformity and clearness in relationship to concepts and mainly about the difference between equipments and modules. As done until now the proposed solution is detailed later; a different approach is described in order to find a consistent way of classification.
3.4.1.3 Process
First of all in figure 16 can be see that two different approaches to classify the joining elements were proposed. The second one (“Joining 2”) was followed because it is more pertaining to a classification based on processes. In fact, while “Joining” approach classify its elements in function of the physical process that allow the joining, “Joining 2” splits the joining process in four sub-processes; this means that the driver of classification does not change from one level to the other avoiding ambiguity problems.
3.4.1.4 Equipment
Fig. 17 illustrates how “Equipment” class is structured in Eupass ontology; in the updated version there are some differences, but these were introduced to fulfil, or better said to improve the last version and they are not substantial. Therefore, as usual, this description is made later.
Fig. 17
3.4.2 Relationships
In the figure below the relationships among the nine main classes that belong to the Eupass ontology are shown. Again, in this section they are described in order to highlight their weak points, then starting from the problems found and trying to solve them a new way is proposed.
Fig. 18
First of all it appears, in a visual way also, that the ontology was not made to be used in EAS context. As we deeply explained in the concerning part, it should lead the emplacement of the assembly system with processes as drivers of this development and the requirements of the new product as the necessary input.
As we can see above, there are several things missing. The most important is the lack of a link between “Products” class and the rest of the classes. In fact, it is clear that without the requirements of the product the following development is not possible. Alike, “Operators” and “ProcessAction” classes are not related to the others; this is a confirmation of the fact that we did not consider these classes essential in the updated version.
Moreover, processes are not a fundamental aspect as they should be. As it is said previously describing the classes, all have the same importance and there is not a logical linear path from the product to the system. What is not clear is how this ontology should help the development of the system.
The first critique must be highlighted is due to the “collection Of*” relationship. At this step it is unthinkable that the system is completely made by modules. Necessarily there are elements that are not modules and this does not depend if they are controlled by software or not because this is considered separating them in active and passive ones. It can happen that in actual application not modularised elements are used and this must consider to achieve the generality an ontology must have.
A second aspect that must be clarified are the relationships between “Skills”, “Activity” and “Process” classes. The idea behind the ontology above is that to perform a process certain skills, which are composed of control actions, are needed. Therefore, the “Skills”-“Process” link is straight and activities are just seen as sub-steps that must be performed to obtain the skill wanted. Again, the focus seems to be put onto the control aspects. Moreover, this means that activities are considered only when the skills needed are identified.. If we really want to understand which skills are necessary for a certain process one more detailed level must be introduced: is it actually possible to understand all skills needed by a joining process? Probably it is easier to understand which are requested by an insertion operation.
Going further, one more element that is interesting to analyse is the “Activity” class. In figure 19 its sub-classes are presented. In order to understand the following clarification, some concepts and definitions, given in Eupass ontology, must be introduced.
An activity is defined as the formal definition of change over time with a defined beginning and end caused by an actor or actors. An activity is represented by a temporally ordered set of steps with different levels of complexity towards a defined goal.
The relevant aspect here is to intuit that an activity is a set of basic steps or actions. From the control point of view these actions or steps corresponds to control commands that must be issued by the controllers at different levels (cell, workstation, unit, etc). Therefore these actions or steps at different levels will be grouped and classified according to the level where they belong.
A task is an activity that facilitates a clearly definable portion of work towards the completion of a target product.
An operation is an activity that facilitates a state change of objects that are part of a target product.
An action is a fundamental activity that can be performed by an actor without the goal to directly influence an object.
Tasks, operations, and actions are related through a kind of hierarchical relationship which is modelled, in Eupass ontology, by “hasPart” relationship. In fact a task is composed of operations, which in turn are composed of actions.
Actions are therefore the most basic control actions that occur at device level. Operations are control actions that occur at unit level, and are therefore composed of the actions that must be issued to the elements or devices that compose an unit. Tasks on the other hand are control actions issued at workstation, cell, and line levels, and therefore are composed of those control actions that must be issued to the units that compose a workstation.
The focus is tightly put onto the control aspects, but we cannot forget that activities must be used to identify those skills needed by the product and so the equipments. Figure 20 shows this problem: a task is composed by operations, each of them is composed by several actions.
The orange arrows indicates this top-down approach; it must be considered in the ontology context because, as we said talking about the relationships between “Skill”, “Activity” and “Process” classes, if the equipments required must be detected, starting from the task (for example: assembly of handles) we have to pass through the operations (e.g. insertion of the pin) and so through the actions (e.g. alignment pin-hole).
On the other hand, the green arrows show the control approach. In order to complete an operation all its sub-operation (actions) must be successfully completed, if one of them fails the operation cannot be performed. If we have to check that an operation is accomplished in sooth we check that all the related actions are accomplished. Of course, the same can be said about task and operations.
3.4.3 Attributes
About attributes, in the updated version there are some differences, but these were introduced just to improve the last version and they are not substantial. Therefore, as usual, this description is made later.
3.5 General Ontology
Once those weak points were found the necessity to create a new ontology arose. The guide lines used in this updating were three:
• The ontology should be as general as possible, but at the same time not generic
• Clearness is fundamental; ambiguity must be avoided in order to let the understanding and the use of the ontology as easy as possible
• The ontology must be lean; simplicity must be looked for unless this is not contrasting with the two points above
In this section, first it is finally explained how the ontology works. It means that it is shown the compatibility between this version and EAS approach.
Then the ontology is shown, but the style of the presentation is different here because to help the whole understanding of the ontology classes must be described with their relationships and attributes and not separately. At this stage, however, the description is much deeper: all the concepts and the elements are defined and described.
In the figures 21 and 22 the main classes of the General ontology are shown and the scheme of the General Ontology is presented with relationships between them.
The sequence how this classes are introduced is not random: in EAS paradigm classes are strictly in logical sequence, as it was presented in the previous chapters and better explained later.
Fig. 22
Instead in the figure below the EAS scheme is presented again, in order to highlight the tight link among them. In the former chapters we said it was necessary to create an ontology that was functional to develop Evolvable Assembly System; in this section we illustrate why the General Ontology we worked up goes in this direction.
In figure 23 our proposal about the way to follow to identify the equipments needed is highlighted. It was explained the processes should be the drivers of the ontology and this is what we did: the requirements of the product are the necessary input to develop specific ontologies, but this does not mean that the focus is posed onto the product; it is actually posed on processes, which are the real starting point of the ontology. This issue will be clarified in the next chapter when specific ontologies are created and the key-role of processes is shown. Once processes are identified the next step is to find out the activities composing them. This must be done at different levels and so, using the terminology described in the former
paragraph, tasks, operations and actions must be detected. This way of doing is suggested because then it becomes easier to identify the skills needed (as it is described in the last paragraph again). Since each general equipment, for how it is defined in this ontology, has at least one basic skill, the identification of those that are suitable for the assembly of the product considered gets easier.
Fig. 23
This approach can be retrieve in figure 22. By the class of products the processes that make them are identified; these processes are performed by activities which need skills. These skills participate at least in one general equipment; if it is available it can be used in the Assembly system as it is or it can become a module and used in the system as an EAS module. The discussion about the strategic decision phase was done in the previous chapters and it is not useful to be proposed again here.
Looking at figure 23 there is one more topic that can be tackled about the General ontology. As it was pointed out in the introduction of this chapter, it is very important to remember that an ontology cannot be considered accomplished; we said that it must be regularly revised and,
especially, updated, in order to introduce elements that just experience and technical improvements can suggest. This is the meaning of the arrow connecting “General ontology” and “New Product ontology”: “General ontology” to “New Product ontology” direction means that specific ontologies are developed starting from the general one (as it is done in the next chapter); “New Product ontology” to “General ontology” direction means that once lacks are found dealing with new products the general ontology must be updated. Alike, once in the market new technologies arise these must be considered in the general ontology (this is the meaning of the arrow linking “Process oriented system modules” to “General ontology”).
In the following, the General ontology is described. Each main class is presented and in this context taxonomies, relationships and attributes are shown as well. Note that definitions given are taken from the document “ EUPASS Glossary and Unified Ontology”, unless the change was necessary in order to align defined elements to the approach proposed. Often these definitions are not highlighted to allow the discussion to remain focused onto the ontology aspects and to avoid this thesis to become a glossary. If some of the concepts presented are not clear we refer to the document indicated above.
3.5.1 Class of Products
Definition – Set of products that have in common the final utilization and that are based on
the same kind of technology.
It is useful to group products in the way shown above in order to make easier the next steps driven by the “General Ontology” proposed. In fact, organizing products as described means that these products share the same assembly processes; once these assembly processes (which, as explained previously, are the starting point of the methodology) are found for one of the products of the class, they are valuable (except for small inevitable changes) for the whole class.
Figure 24 illustrates the relationships among “Class of products” class and the other ones.
Fig. 24
The figure shows what explained formerly. Processes are the drivers of the ontology, they are what must be understood once a new product (done and previously grouped in a class) is given. These are the meanings of the two relationships between these two classes. “Made_By*” relationship suggests that from the product given what must be taken out to follow the approach described above are its processes (assembly or machining ones), while “Makes*” relationship highlights again that the focus is pointed on processes that are actually what make products.
3.5.2 Process
Definition 1 - A process is a naturally occurring or designed sequence of operations or events,
possibly taking up time, space, expertise or other resource, which produces some outcome. A process may be identified by the changes it creates in the properties of one or more objects under its influence.
Definition 2 - A process is an action which we see as a sequence of constituting sub-actions.
The states of the world resulting from sub-actions are referred to as stages of the process. Thus we see a process as a sequence of its stages.
Figure 25 illustrates the relationships among “Process” class and the other ones.
Fig. 25
The relationships between “Process” and “Class of Products” are just described in the previous section. What is underlined in this paragraph is the link shown between “Process” and “Activity” classes. Once the processes for the product considered are found, the activity (at different levels, as it is illustrates in the next section) must be searched out. This is the meaning of the “Performed By*” relationships: in order to find those equipments that are necessary for the assembly of the product considered it is useful to go deeper from the process (that is the most general level) to the actions (that are the lower level). On the other hand “Performs” relationship clarifies that processes are accomplished by different activities, which are necessary to the more general process. This is exactly what is discussed in the former section talking about the lacks of the Eupass Ontology where the necessity of both of these directions is illustrated: the top-down one to identify the smallest actions that compose the processes, the bottom-up one to let the upper level to be controlled.
Next, the taxonomy of this class is illustrated; it must be noticed that our scope was not to develop a glossary, therefore some of the concepts proposed are given as they are without definitions or deep explanations and shown as they would be known.
Although this thesis is focused on assembly aspects, also the machining ones are, anyhow less thoroughly, treated. Hence, the two main classes composing the “Process” class are “Machining Process” and “Assembly Process”.
Their sub-classes can be seen in the figure below.
Fig. 26
3.5.2.1 Machining Process
Definition – those processes that enable the production of manufactured goods by turning raw
materials into semi-worked or finished products.
3.5.2.1.1 Material Removal
This sub-class contains the processes are based on the removal of material. Its taxonomy is shown in the figure below.
3.5.2.1.2 Plastic Deformation
Compared with the Eupass Ontology this class was added to include the processes linked with plastic deformations, like those illustrate in the figure, in order to be more generic even if they are not specific of assembly systems.
Fig. 28
3.5.2.2 Assembly Process
Definition - the whole set of activities and skills needed to perform an assembly task or to
complete an assembly of an industrial product. The general problem of linking together materials and components in order to generate an industrial product (Assembly-Net Glossary / revised).
3.5.2.2.1 Joining
Definition - a joining process is a process necessary for the composition of two or more
separate product parts within an assembly system by appropriate positioning and fixation of the parts, with or without externally applied joining technologies.
In this ontology “Joining” class is divided in four sub-classes shown in figure 29. In the next paragraphs this classes are explained and described. As it can be seen, it is followed one of the approaches that were suggested by the Eupass Ontology. The reason, as it is clarified in the section where this issue is discussed, is that this classification, which is more process-oriented, makes easier the development of the logical sequence (processes-activities-skills-equipments) as it is presented previously.
Fig. 29
3.5.2.2.1.1 Aligning Function
Definition – the processes that let two parts that are going to be assembled to get aligned.
In this ontology we distinguish also between the alignment done utilizing equipments directly involved in the assembly process that enable the alignment thanks to their characteristics (“Passive Alignment”) and alignment obtained with external equipments that find the right alignment between the parts (“Active Alignment”).
In the figures below the taxonomies of this sub-classes are presented.
Fig. 31
3.5.2.2.1.2. Placing Function
Definition - The process of moving and placing (once aligned) one or more parts in relation to
the others, with or without the use of product based internal positioning features.
Fig. 32
All of these three processes are defined as provisory coupling of two parts in a predefined position for later joining. The differences are due to the type of movement and the use of positioning features to find the accuracy wanted.
Insertion (linear movement + force): the process of joining two parts by aligning and moving
one of the parts in relation to each other by inserting one part into the other part, until they are positioned correctly by means of product based internal positioning features.
Stacking (linear movement + force): the process of joining two parts by aligning, moving and
placing one of the parts in relation to the others, without the use of product based internal positioning features and securing the final positional accuracy by making use of a temporarily fixation process or action.
Mating (cooperative movement + force): the process of joining two parts by aligning, moving
and placing one of the parts in relation to each other, until they are positioned against product based internal positioning features and secure the final positional accuracy by making use of a temporarily fixation process or action.
3.5.2.2.1.3. Fixating Function
Definition – the processes that actually allow two parts to be joined.
The definition is voluntarily generic because in this class, as it can be seen in the figure below, many different joining methods are grouped.
Fig. 33
Next the classes that are more detailed are illustrated with their taxonomy. Again, in order to focus the attention on the ontology aspects and so to not weigh down this part of the thesis, following processes are not described since development of a glossary was not one of our scopes.
• Fastening
Definition – in this class are grouped those joining process which makes use of an added
Fig. 34
• Welding
Fig. 35
• Curing
• Painting
Fig. 37
• Deforming
Fig. 38
• Soldering
Note that soldering is distinguished from brazing by use of a lower melting-temperature filler metal; it is distinguished from welding since the base metal is not melted during the joining process. In a soldering process, heat is applied to the parts to be joined, causing the solder to melt and be drawn into the joint by capillary action and to bond to the materials to be joined by wetting action
3.5.2.2.1.4 Assisting Function
Definition – these are the processes that do not take part directly to the joining processes, but
that supporting the other ones while they are in progress are necessary in order to accomplished them.
Figure 40 shows how this class is structured.
Fig. 40
3.5.2.2.2. Auxiliary
Definition – processes that support the joining processes before and after these are performed.
The figure below illustrates the five main classes composing the “Auxiliary” class.
3.5.2.2.2.1. Handling
Definition - These are the processes required to move materials or raw materials from one
point to another bringing products or product parts to a joining process or bringing these parts into the direct vicinity of a joining process.
Figure 42 shows which sub-classes compose the one considered.
Fig. 42 • Holding
This sub-class is structured as explained previously in the “Aligning Function” section.
• Transferring
Definition - These are the processes behind the move of goods from one place to another.
Its sub-classes are presented in the figure below.
Fig. 43
The difference between the first two classes is that a transportation process is an auxiliary process which is needed for transportation of products or product parts, while a manipulation
process is an auxiliary process which is needed for aligning product or product parts, to be able to undergo another assembly process.
Instead “Reflowing” is defined as the processes that allow the return flow of incomplete assembly fixtures to a given point in the assembly sequence.
• Loading and Unloading
These classes are referred to loading (unloading) of a station. They are not more detailed.
• Feeding
Definition - the process of handling raw materials (by separation and/or transportation of
product or product parts) to be assembled.
Figure 44 highlights that considering these processes a first classification done is about quantitative and qualitative aspects. The first ones deal with the way the feeding is performed (continuously or not ), the second ones with the equipments used to accomplish it.
Below the taxonomy of “Bulk Feeding” is given.
Fig. 45
3.5.2.2.2. Logistics
Definition - logistic processes are auxiliary processes needed for regulating and controlling
logistic issues within an assembly system.
These are the classes that was found for this main class.
Fig. 46
In this context a buffering process is defined as an auxiliary process which is needed for uncoupling different processes in time and making sub-process flows possible.
More attention must be given to “Identification” processes. Its taxonomy is shown below:
Fig. 47
An identifying process is defined as an auxiliary process which is needed for identifying or marking product carriers, products or product parts for logistical purposes within an assembly system. To achieve this goal the systems described in the figure can be used.
3.5.2.2.2.3 Finalization
Definition - all the processes involved in product finalization.
Figure 48 shows that “Packaging” and “Cleaning” are the groups of processes that must be accomplished in order to finalize the product.
Fig. 48
3.5.2.2.2.4 Quality
Definition - quality processes are auxiliary processes, needed for qualifying or quantifying certain quality aspects within an assembly system.
Figure 49 describes the classification of the class.
Fig. 49
The difference among the three classes is that a measuring or a testing process is an auxiliary process which is needed for qualifying and/or quantifying certain product properties within an assembly system, while an inspection process is defined as an auxiliary process which is needed for qualifying and/or quantifying certain assembly process properties within an assembly system.
3.5.2.2.2.5 Preparation
Definition - Preparation processes are auxiliary processes necessary for preparing products or product parts to be processed by an assembly system.
The taxonomy is given below.
Fig. 50
The difference between “Cleaning” as it is presented here and as it is described previously in the “Finalization” section is that in this context the product must be cleaned to allow the next processes, while formerly it s considered as a final activity that has to be performed in order to obtain the final product as it is given to the customer.
3.5.3. Activity
Definition - An activity is the formal definition of change over time with a defined beginning
and end caused by an actor or actors. An activity is represented by a temporally ordered set of steps with different levels of complexity towards a defined goal.
Figure 51 shows the relationships among “Activity” class and the other ones.
Fig. 51
In the former paragraph we discussed about the “Activity” – “Process” relationships. In the next one, since to understand why those links are chosen and what they mean some concepts illustrated there must be introduced, the relationships between “Activity” and “Skill” is explained.
Therefore in this section the focus is posed on “Activity” class which is detailed in the figure below. This issue was already discussed when the approach about this aspect in the Eupass ontology was shown. In that part sub-classes was defined and these definitions are still valid. In order to solve the problems found there (substantially due to the fact that just the top-down relationships were introduced) the following proposition is given:
Fig. 52
“Actions”, “Operation” and “Task” are still activities and the hierarchical tree is still the same: a task is composed of operations, which in turn are composed of actions (“ConsistingOf*” relationship). It must be noticed that even operation (task) can be considered as composition
of smaller operations (tasks). On the contrary actions, being defined as a fundamental activity, cannot composed of actions: a sum of actions becomes an operation.
This relationship described is the one necessary to go deeper finding the actions that must be performed in order to accomplish the tasks given. It is the top-down relationship that was also presented in the Eupass ontology.
What is added here is the bottom-up relationship necessary for the reasons explained previously. An action takes part in an operation, which takes part in a task. Again, an operation (task) can have part in a bigger operation (task), but not an action (“Has_Parts” relationship).
Of course, since these concepts are defined as said, also activities are composed of smaller activities and take part in bigger activities.
3.5.4. Skill
Definition – “Skill” is the ability to perform activity, which are needed by a process to be
supported.
Figure 53 illustrates the relationships among “Skill” class and the other ones.
Fig. 53
In particular, it is shown what is said in the definition: skills are what let activities to be performed (and so processes, which are performed by activities-relationship “needs*” and the inverse one “Needed_By*”).
The “”ControlAction” relationship is kept from the former version to stress the fact that every skill is composed of control actions which are grouped under “Activity”. In fact Skills will be connected not only to activities but might be connected to sub-activities such as tasks, operations, or actions, depending on the type of skill that is being considered.
One of the biggest change done comparing with the Eupass ontology concerns how skills are considered and, in particular, the interrelation between this class and “General Equipment” one. As in the former version, skills are divided in “Basic skill” and “Complex skill”. The definition given to these sub-classes is the following:
• “Basic skill”: this is the most basic skill for what a general equipment is designed for. To each general equipment can be assigned at least one basic skill. This means that, for example, the basic skill for a robot is “move”. This because that is actually its most basic one; if the robot is able to weld is just because a welding torch (different equipment with a different basic skill) is attached to its arm, what it actually does is just moving the end effector.
• “Complex skill”: these are those skills composed by basic skills. For example, “assembly” is a complex skill because to perform it we need many basic skills such as “move”, “grab”, “feed”.
The definition above is better explained by the figure below, where the relationship between “Basic Skill” and “Complex Skill” is highlighted. In particular, we want to underline again that complex skills are just a combination of basic skills.
Fig. 54
The reason why it was decided to define the skills in this way is that it allows to understand what an equipment can really do and so how it can be used and in which tasks. Highlighting
the most basic skill of a device the system can understand if it could be useful in tasks which are different from its normal ones. This is an important step to manage those Emergent behaviours which are one of the most important aspects of EAS.
Below, the taxonomies of “Skill” sub-classes are shown:
Fig. 55
Fig. 56
As it can be seen, all the skills belonged to “Basic Skill” class are general and very basic (a sensor, in its more general meaning, is designed to control; a robot to move; a fixture to hold; a warehouse to store; a feeder to feed; a gripper to grab…).This means that we need just one device to perform a basic skill and more to accomplished a complex skill.
An aspect must now be remarked. We defined basic skills as the most basic skill for what a general equipment is designed for; if an equipment is designed to perform a skill that we consider in our ontology as complex, in that case and just in that case must be consider as basic. To clarify this concept we can take the “Pick&Place” skill into account: it can be performed by a robot with its gripper or by a pick and place device. In the first case it must be consider as a complex skill since it involves at least two basic skills (move and grab) and two equipments (robot and gripper); in the second case it must be consider as a basic skill since it
involves just the pick and place device which is just designed to perform those kind of operations.
Once clarified these concepts the relationship between “Skill” and “General Equipment” becomes clear: each equipment has a skill (which one is illustrated later, when the “General Equipment class is described”) [“Has Skill” relationship] and the skill is what really characterized an equipment, since the choice of the useful (for a particular application) ones is done on the basis of the skills found following the sequence illustrated above [“Participate In*” relationship].
3.5.5 General Equipment
Definition 1 – General Equipment are non modular entities which are openly available and
not EAS specific.
Definition 2 - Any kind of device, equipment, machine or system used to perform, assist,
monitor or control one or more processes or operations related to the assembly of a product.
Figure 57 illustrates the relationships among “General Equipment” class and the other ones.
The relationship between “General Equipment” and “Skill” has been already introduced. The one with “EAS Module” is more understandable once the concept of EAS module is defined, so this description is postponed in the next paragraph. Alike, the relationships with “Assembly System” class is postponed, since it involves also the “EAS Module” class.
Talking about equipments, an aspect that must be analysed are the attributes given to them. The figure below illustrates those assigned to the “General Equipment” class. As said in the introduction, an attribute at the upper level is found also at the lower level. This means that the ones shown above, belonging to the most general class, belong to all sub-classes as well. Later, when the taxonomy of this class is described, the particular attributes of sub-classes are highlighted.
Fig. 58
Those that have “Class” as “Type” are the relationships just discussed. The others are general attributes that can be considered available for every equipments:
• Manufacturer: it is the name of the manufacturer and therefore has “String” as “Type” and “Single” as “Cardinality” (an equipment can have just one manufacturer) • SerialNumber: it is the serial number of the equipment; for the same reason as above
the “Type” is “String” and the “Cardinality” is “Single”
• SpatialRepresentation: it represents the volumetric information, necessary for lay-out reasons; it is a number so its “Type” is “Float” and its “Cardinality” is “Single” • Typemodel: it indicates the model; this means that its “Type” must be “String” and
its “Cardinality” “Single”
• Weight: this is the mass of the equipment; so its “Type” is “Float” and its “Cardinality” is “Single”
Note that “multiple” cardinality indicates a one-to-many relationship; in fact, for example, the “Has Skill” relationship means that at least an equipment has a skill, but they can be more (e.g. the equipment “laser gun” has two basic skills: heat and lightning).
In this section, since the scope is to classify any kind of device, equipment, machine or system, the taxonomy plays a fundamental role. First of all, even if we are considering just the assembly aspects, in order to be more general as possible (as said in the introduction of this ontology) we do not consider only the assembly equipments but also the manufacturing ones. This because even in assembly systems could happen that small manufacturing activities are performed for technical or economical reasons for example. In the next figures the taxonomies of this sub-classes are shown.
3.5.5.1 Manufacturing Equipment
Fig. 59
In the following paragraphs these sub-classes with their attributes are analysed.
• Water-jet gun
Below the attributes given to the equipment “Water-jet gun” are shown. It must be noticed that when the slot is enclosed in parenthesis means that attribute belongs also to the upper class. Hence, “Manufacturer” is an attribute that, as seen before, belongs to “General Equipment”. The attributes that are not between brackets are those specific of the class
analysed and so the ones that are described in these sections. Moreover, the symbol means that the slot considered is overridden. Overriding a slot at the class level allows to be more restrictive about the slot facets relative to that class. In this case it allows to assign one (or more) of the skills belonging to the inherent class to the equipment taken.
Fig. 60
There are two particular attributes identified to describe a water-jet gun:
• Diameter of the nozzle [mm] • Operating pressure [bar]
Being a dimension that characterize these attributes, both of them have “Single” as cardinality and “Float” as type.
The skill assigned to water-jet guns is “Remove Material” although it is considered as a complex skill. This because water-jet systems are actually designed to increase water pressure. But from the point of view of systems analysed it is more important to consider the complex skill “Remove Material”.
• Laser gun
Considering the equipment “Laser gun”, its attributes are the ones listed below.
Fig. 61
• Divergence of the beam [mrad]
• ExitBeamDiameter: the diameter of the laser beam before the focalization optics [mm]
• Heating time [sec]
• Laser source: it is the name of the laser source (e.g. CO2) • MaxPower [W]: this is the maximum power given off
• Regime: it can be continuous or pulsed (one or the other, so the cardinality is “Single”)
• WaveLength [µm]
The skill assigned to laser guns are “Heat” and “Lightning” which are considered as basic skills. The reason is that a laser gun actually performs those two skill (depending on the power of the laser, for example a low power one may be used to highlight where a high-power one, which could be dangerous, is). If a laser gun makes an hole basically it is caused by the heat produced.
• Other Manufacturing Equipments
To the other Manufacturing Equipments shown in figure 62 (“Milling Machine”, “Lathe”, “Drill” and “Pressing Tool”) the following attributes were given.
Fig. 62
• Corrector D: this is the corrector used to indicate the measure of the diameter (or equivalent dimension) of the tool [mm]
• Corrector L: this is the corrector used to indicate the length of the tool [mm] • ToolCode: it is a standard code to describe the geometric features of the tool
The skill “Remove Material” is assigned to “Milling Machine”, “Lathe” and “Drill” equipments because it is clear that kind of devices are designed to remove material from the product given.
On the other hand the “Pressing tool” equipment is not utilized for this reason but to join. This is one more example of what said above: “Join” is considered as a complex skill but since pressing tools are designed to join in this context it becomes a basic skill.
3.5.5.2 Assembly Equipment
Fig. 63
Next, the taxonomies of each of the sub-classes of the “Assembly Equipment” class are depicted with their own attributes.
3.5.5.2.1. Tool
Fig. 64
A) Gripper
The taxonomy of the sub-class ”Gripper” with its attributes is presented in the figures 65 and 66.
Fig. 66
• GrippingArea: this value describes the maximum contact area gripper-product [mm2] • MaximumForceAllowed: it is the maximum force allowed on the vertical axis [N] • Mi: it is the i axis moment [N·mm]
• WorkPieceWeight: this is the maximum weight of the object the gripper can hold [Kg]
A.1 ) Mechanical Gripper
To this particular kind of grippers some specific slots are added:
Fig. 67
• ClosingTime: this is the time required to close the gripper [sec]
• Max(Min)Aperture: This two values describes the aperture of the gripper and the maximum one it can achieve [mm]
• Max(Min)OperatingPressure: it depends on the force applied [bar] • Number of fingers: it is set that at least the fingers must be two • OpeningTime: the time required to open the gripper [sec]
A.2) Other kinds of Grippers
To the other sub-classes of grippers (“Magnetic gripper”, “Vacuum gripper” and “Special gripper”), regarding the list of attributes as they are shown in figure 66 just one was added:
This because, talking about these kind of grippers and the way they work, what is said about “Mechanical Gripper” is not valid anymore. In fact, while a mechanical gripper grabs the object by opening and then closing its fingers, a magnetic gripper, for instance, performs this operation thanks to the properties of the product and the gripper itself. The same can be observed about the other two classes above, hence “GrippingTime” (measured in seconds) is an attribute that can describe the performance of the gripper analysed about this aspect.
Concerning the class “O-ring Gripper”, one more slot was inserted:
It describes [mm] the maximum diameter of the O-ring that can be grabbed by the gripper at issue.
B) Painting tool
In the figure below the tree of the “Painting Tool” class is presented.
Fig. 68
About attributes, these are the same ones described analysing the “General Equipment” class (see figure 58). What must be underlined is the skill given to this equipment. Painting was considered as a particular sort of joining where paint is taken as a component to be joined (by chemical processes) to the rest of the product. So the skill given to “Painting Tool” is “Join”.
C) Other kinds of Tools
Regarding the other tool listed in figure 64, they do not have more sub-classes and their attributes are the same assigned to the main class “Tool”. As pointed out above, what is important to highlight is the skill given to these equipments.
We just discussed about Laser and Water-Jet guns and why their skills are “Heat” and “Lightning” for the first one and “Remove Material” for the second one. They still remain the same ones even if we are dealing with assembly aspects.
Alike, to the equipment “Welding Torch” and “Soldering Gun” can be given the skill “Heat”; in fact welding of two parts is essentially consequence of the heat brought about that lets the two parts (or the filler material) to be fused. Soldering is distinguished from welding just since the base metal is not melted during the joining process, but this does not change its basic skill. Instead, due to clear reasons, the skill of the class “Finger” is “Grab”.
The other tools found are proposed again below:
• Gluing gun • Riveting gun • Screwing gun
In different ways, but each of them has as basic skill the one of joining.
3.5.5.2.2 Actuator
Definition - A mechanical device that converts various types of energy such as electric
energy, chemical energy into kinematic movement and / or force to perform mechanical work. The term is often used as a collective term for different kinds of motors, cylinders, pumps and drives.
The class “Actuator” is divided in two sub-classes: “Linear actuator” and “Circular Actuator”. Each of them is then detailed as it is shown in the figure below, where six types of actuators (classified in function of the physical principle that let them to work) are depicted.
Note that in order to avoid redundancy this six classes are not repeated in the figure for “Circular Actuator” class, even if they actually belong to that class as well.
Fig. 69
As usual, in the figure 70 the slots related to this class are proposed:
Fig. 70
Those, which are specific to “Actuator” class, are now described. Note that these are the same ones assigned to the sub-classes and no more are given to them.
• Accuracy: it is the average error made reaching a certain position done [mm]
• Maximum(Minimum)Speed: this is the maximum (minimum) speed the actuator considered can reach [m/s]
• MaximumTravel: it is the longest path the actuator is designed for [mm]
• Repeatability: this dimension describes the ability of the actuator to reach accurately the same point in different times. In particular, it can be statistically obtained as described below:
The skill assigned to this class, as it can be seen in the figure above, as it is deducible is “Move”.
3.5.5.2.3. Assembly Entity
Definition - Those equipments that perform the actual assembly activities
Fig. 71
The attributes given to this class are the same assigned to the upper one (“Assembly Equipment”). A sub-class deeper analysed is “Robot” (“automatically controlled, reprogrammable, multipurpose manipulator programmable in three or more axes (ISO)”), whose slots are the ones below:
Accuracy and Repeatability are described in the section above and their meaning does not change in this context. The other attributes are explained:
• DegreesOf Freedom: the number of joints belonged to the robot considered; it is set that, at least, one degree of freedom must be given (concerning “SCARA Robot” also the maximum number of degrees of freedom is set: four)
• MaxWorkingSpeed: the maximum working speed that can be reached by the robot [m/s] • MaximumEnvelope: the volume of space encompassing the maximum designed
movements of all robot parts, including the end effector, workpiece and attachments [m3]
• RestrictedEnvelope: that portion of the maximum envelope to which a robot is restricted by limiting devices. The maximum distance that the robot can travel after the limiting device is actuated defines the boundaries of the restricted envelope of the robot [m3] • OperatinEnvelope: that portion of the restricted envelope that is actually used by the
robot while performing its programmed motions [m3] • PayLoad: the maximum weight the robot can hold [kg]
As skill “Move” is given, because the robot has this skill as the basic one. What then it is able to do actually depends on the end-effector attached to its wrist.
Finally, a notation about “Pick&Place Dedicated Unit” must be done. These equipments are defined as “modular devices (usually with pneumatic actuators), not programmable by software used for pick and place operations”. Since they are so defined it is clear that they are designed to perform those kind of activities and so, coherently with the definition of “Basic Skill” given, in this ontology the skill assigned to this equipment is “Pick&Place” and it is considered as basic.
3.5.5.2.4. Transporter
Definition - Equipment used for transporting or conveying parts, subassemblies, products or
other goods from one place to another.
Figure below illustrates the taxonomy of the class.
Fig. 73
The “Reflow” sub-class identifies those equipments that allow the return flow of incomplete assembly fixtures to a given point in the assembly sequence.
Instead, the “Material Handling” class groups those equipments used to move products from one cell to the other. In other words, the equipments used to achieve continuous movement of product fixtures or products in a production-line operation.
The attributes given to this class, again, are the same ones assigned to “Assembly Equipment”. The skill, obviously, is “Move”.
Next, the sub-classes of “Material Handling” class are shown and described (when necessary).
